diff --git a/404.html b/404.html
index a112bac06b..3c7e9868b8 100644
--- a/404.html
+++ b/404.html
@@ -264,7 +264,7 @@ <h1>404</h1>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/algolia.json b/algolia.json
index b008d12d78..0e17a41d8d 100644
--- a/algolia.json
+++ b/algolia.json
@@ -1 +1 @@
-[{"date":1704008961,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1704008961,"objectID":"d869fb48cb9acba03dc639481524ee80","permalink":"https://blog.johtani.info/blog/2023/12/31/review-2023/","publishdate":"2023-12-31T07:49:21Z","readingtime":5,"relpermalink":"/blog/2023/12/31/review-2023/","section":"post","summary":"今年も振り返りブログをリビングで書いています（ドミノ倒しすごいな）。 FMVのキーボードで書いているのでタイポがつらい。。。 振り返り（2022","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2023）","type":"post","url":"/blog/2023/12/31/review-2023/","weight":0,"wordcount":2323},{"date":1702566000,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":6900,"kind":"page","lang":"ja","lastmod":1702566000,"objectID":"476e17b6f854414033d5cec1470774ee","permalink":"https://blog.johtani.info/blog/2023/12/15/introduce-orama-to-blog/","publishdate":"2023-12-15T00:00:00+09:00","readingtime":14,"relpermalink":"/blog/2023/12/15/introduce-orama-to-blog/","section":"post","summary":"この記事は、情報検索・検索技術 Advent Calendar 2023の15日目の記事です。 昨年に続き2回目の情報検索のAdvent Calendar参戦です。 今年は、夏","tags":["orama","search"],"title":"Oramaという検索エンジンでブログ検索を作ってみた","type":"post","url":"/blog/2023/12/15/introduce-orama-to-blog/","weight":0,"wordcount":6835},{"date":1701961200,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":3200,"kind":"page","lang":"ja","lastmod":1701961200,"objectID":"516a7aa07f8faa6b7aa38beb5010cf8c","permalink":"https://blog.johtani.info/blog/2023/12/08/smarthome-bot/","publishdate":"2023-12-08T00:00:00+09:00","readingtime":7,"relpermalink":"/blog/2023/12/08/smarthome-bot/","section":"post","summary":"PySpaアドベントカレンダーの12/08のエントリーです。昨日は渋川さんのアンラーニングで失敗した話でした。 私は、今年は昨年の続きっぽい話","tags":["misc","music","bot"],"title":"GoでSlackのボットを作った話","type":"post","url":"/blog/2023/12/08/smarthome-bot/","weight":0,"wordcount":3195},{"date":1695612744,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1695612744,"objectID":"7f78b02c531f09602ba4e140132d26a2","permalink":"https://blog.johtani.info/blog/2023/09/25/read-search-raking-guide/","publishdate":"2023-09-25T03:32:24Z","readingtime":5,"relpermalink":"/blog/2023/09/25/read-search-raking-guide/","section":"post","summary":"「機械学習による検索ランキング改善ガイド」を読みました。 著者の鈴木さんより献本いただいたのを読み終わったのでレビューと、あとおまけです。 紹介","tags":["読書","elasticsearch"],"title":"機械学習による検索ランキング改善ガイドを読みました","type":"post","url":"/blog/2023/09/25/read-search-raking-guide/","weight":0,"wordcount":2401},{"date":1692768764,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1692768764,"objectID":"8f58cbe5f2ce85c22569af765de3f8d3","permalink":"https://blog.johtani.info/blog/2023/08/23/search-ui-and-searchkit/","publishdate":"2023-08-23T05:32:44Z","readingtime":5,"relpermalink":"/blog/2023/08/23/search-ui-and-searchkit/","section":"post","summary":"趣味？（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書いています。 ベクトル検索などの確認なども含めて、Jupyter N","tags":["searchkit","search-ui","画面"],"title":"search-UIとSearchkitと検索画面","type":"post","url":"/blog/2023/08/23/search-ui-and-searchkit/","weight":0,"wordcount":2384},{"date":1690420969,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1690420969,"objectID":"f9e847ee886bdb9ab5583eeb6eabbd51","permalink":"https://blog.johtani.info/blog/2023/07/27/container-name-in-devcontainer/","publishdate":"2023-07-27T01:22:49Z","readingtime":2,"relpermalink":"/blog/2023/07/27/container-name-in-devcontainer/","section":"post","summary":"いくつかある環境をDev Containerで動くように変えていますが、最初に導入した時に疑問点だった「コンテナ名」について解消したのでメモを","tags":["dev container"],"title":"VS CodeとDev Container(コンテナ名の指定)","type":"post","url":"/blog/2023/07/27/container-name-in-devcontainer/","weight":0,"wordcount":642},{"date":1690189832,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1690189832,"objectID":"7884b62c561b999b9358d52779a18218","permalink":"https://blog.johtani.info/blog/2023/07/24/introduce-dev-container-to-hugo-env/","publishdate":"2023-07-24T09:10:32Z","readingtime":3,"relpermalink":"/blog/2023/07/24/introduce-dev-container-to-hugo-env/","section":"post","summary":"このブログの生成には、Hugoを利用しています。 ブログ移行日記（その1）に書いてありますが、当時はbrewでインストールしていました。 また、","tags":["hugo","dev container"],"title":"ブログ記述環境としてのDev Container","type":"post","url":"/blog/2023/07/24/introduce-dev-container-to-hugo-env/","weight":0,"wordcount":1500},{"date":1690180128,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1690180128,"objectID":"ed431877ce11fe403fee77f7d26ce637","permalink":"https://blog.johtani.info/blog/2023/07/24/move-distribution-to-another-disk/","publishdate":"2023-07-24T06:28:48Z","readingtime":6,"relpermalink":"/blog/2023/07/24/move-distribution-to-another-disk/","section":"post","summary":"WSL2にUbuntuを入れて、開発とかはこちらを利用しています。 また、Docker DesktopもWSL2のバックエンドエンジンを利用して","tags":["wsl","windows"],"title":"WSL2のディストリビューションの環境移行","type":"post","url":"/blog/2023/07/24/move-distribution-to-another-disk/","weight":0,"wordcount":2776},{"date":1689902010,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":4100,"kind":"page","lang":"ja","lastmod":1689902010,"objectID":"086b4fd5f77021a0a2aa6b0e90061486","permalink":"https://blog.johtani.info/blog/2023/07/21/multi-containers-with-dev-container/","publishdate":"2023-07-21T10:13:30+09:00","readingtime":8,"relpermalink":"/blog/2023/07/21/multi-containers-with-dev-container/","section":"post","summary":"前回の記事で、VS Code＋Dev Containerを導入しました。 残課題として「マルチコンテナ化」があるという話もしました。今回はDev C","tags":["python","dev container"],"title":"VS CodeとDev Container（docker-compose.yml対応）","type":"post","url":"/blog/2023/07/21/multi-containers-with-dev-container/","weight":0,"wordcount":4006},{"date":1689254123,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":3500,"kind":"page","lang":"ja","lastmod":1689254123,"objectID":"a12474027c91fad5a861aa9919817d72","permalink":"https://blog.johtani.info/blog/2023/07/13/introduce-vs-code-and-dev-container/","publishdate":"2023-07-13T22:15:23+09:00","readingtime":7,"relpermalink":"/blog/2023/07/13/introduce-vs-code-and-dev-container/","section":"post","summary":"前回の記事で、pre-commitとPyCharmとWindowsの組み合わせで困っていることを書きました。 これについて、知り合いとチャット","tags":["python","dev container"],"title":"VS CodeとDev Containerの導入（まだ途中）","type":"post","url":"/blog/2023/07/13/introduce-vs-code-and-dev-container/","weight":0,"wordcount":3461},{"date":1688954148,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":4000,"kind":"page","lang":"ja","lastmod":1688954148,"objectID":"698cf3cbd796161d82c9ac438ebab5d2","permalink":"https://blog.johtani.info/blog/2023/07/10/pre-commit-and-python/","publishdate":"2023-07-10T10:55:48+09:00","readingtime":8,"relpermalink":"/blog/2023/07/10/pre-commit-and-python/","section":"post","summary":"最近、趣味（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書き始めました。 きちんとPythonのプログラムをプロジェクト","tags":["python"],"title":"pre-commitとvenvとPyCharm（困ったな？）","type":"post","url":"/blog/2023/07/10/pre-commit-and-python/","weight":0,"wordcount":3921},{"date":1687278645,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":4000,"kind":"page","lang":"ja","lastmod":1687278645,"objectID":"9335522f4c8dbc7256a42a091e6e00bc","permalink":"https://blog.johtani.info/blog/2023/06/21/attend-berlin-buzzwords-2023/","publishdate":"2023-06-21T01:30:45+09:00","readingtime":8,"relpermalink":"/blog/2023/06/21/attend-berlin-buzzwords-2023/","section":"post","summary":"今年もこの季節がやってきました。 Berlin Buzzwordsにオンラインで出張してました。 今年もハイブリッド開催をしてくれたので、オンラインで参加で","tags":["conference","belin buzzwords"],"title":"今年もオンラインでBerlin Buzzwordsに参加した","type":"post","url":"/blog/2023/06/21/attend-berlin-buzzwords-2023/","weight":0,"wordcount":3992},{"date":1672486684,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":2100,"kind":"page","lang":"ja","lastmod":1672486684,"objectID":"df30d810068e4656498e5972c6de7e3d","permalink":"https://blog.johtani.info/blog/2022/12/31/review-2022/","publishdate":"2022-12-31T20:38:04+09:00","readingtime":5,"relpermalink":"/blog/2022/12/31/review-2022/","section":"post","summary":"今年もなんとか振り返りブログを書いてます（時間大丈夫かな？w）。紅白をリアタイで見ながら。 振り返り（2021年に書いた抱負から） まずは振り返","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2022）","type":"post","url":"/blog/2022/12/31/review-2022/","weight":0,"wordcount":2099},{"date":1671030358,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":4100,"kind":"page","lang":"ja","lastmod":1671030358,"objectID":"67c2ae6761e89be0fa66db9623b40d30","permalink":"https://blog.johtani.info/blog/2022/12/15/music-server-on-mac-mini/","publishdate":"2022-12-15T00:05:58+09:00","readingtime":9,"relpermalink":"/blog/2022/12/15/music-server-on-mac-mini/","section":"post","summary":"PySpaアドベントカレンダーの12/15のエントリーです。昨日はtaichiさんでした。 今年はDIYではなく、PCにまつわる話を。 仕事中は","tags":["misc","music"],"title":"仕事中のBGM環境","type":"post","url":"/blog/2022/12/15/music-server-on-mac-mini/","weight":0,"wordcount":4080},{"date":1670516125,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":3100,"kind":"page","lang":"ja","lastmod":1670516125,"objectID":"9693a1e77dee5785b1dc61ccffd2e906","permalink":"https://blog.johtani.info/blog/2022/12/09/open-search-serverless/","publishdate":"2022-12-09T01:15:25+09:00","readingtime":7,"relpermalink":"/blog/2022/12/09/open-search-serverless/","section":"post","summary":"本記事は情報検索・検索技術 Advent Calendar 2022の9日目の記事です。 だいぶ間が空いてしまいましたが、日本語のオートコンプリートに関する記事の続きです。","tags":["elasticsearch","opensearch"],"title":"ElasticsearchのアーキテクチャとStateless / Serverless","type":"post","url":"/blog/2022/12/09/open-search-serverless/","weight":0,"wordcount":3054},{"date":1660099802,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":3800,"kind":"page","lang":"ja","lastmod":1660099802,"objectID":"73279888a8fe482c836fb19ca23318dc","permalink":"https://blog.johtani.info/blog/2022/08/10/jp-auto-completion-2/","publishdate":"2022-08-10T11:50:02+09:00","readingtime":8,"relpermalink":"/blog/2022/08/10/jp-auto-completion-2/","section":"post","summary":"前回は日本語用オートコンプリートのためのAnalyzerとして、どうやって使うのかを簡単に紹介しました。 今回はもう少し、いろんなパターンを試","tags":["elasticsearch","lucene"],"title":"ローマ字入力のゆれと読み（JapaneseCompletionAnalyzerその2）","type":"post","url":"/blog/2022/08/10/jp-auto-completion-2/","weight":0,"wordcount":3778},{"date":1660028402,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":4800,"kind":"page","lang":"ja","lastmod":1660028402,"objectID":"6639ec6f88c4976f8ca20fa840f169e3","permalink":"https://blog.johtani.info/blog/2022/08/09/japanese-auto-completion/","publishdate":"2022-08-09T16:00:02+09:00","readingtime":10,"relpermalink":"/blog/2022/08/09/japanese-auto-completion/","section":"post","summary":"風のうわさで、日本語用のオートコンプリートのためのTokenFilterとAnalyzerがLuceneに取り込まれたと聞きました（LUCE","tags":["lucene","elasticsearch"],"title":"日本語用オートコンプリートのためのAnalyzer","type":"post","url":"/blog/2022/08/09/japanese-auto-completion/","weight":0,"wordcount":4746},{"date":1659689954,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":2200,"kind":"page","lang":"ja","lastmod":1659689954,"objectID":"167a7c9d579ce6f2cebf64a6f6329ecb","permalink":"https://blog.johtani.info/blog/2022/08/05/upgrade-hugo-accidentally/","publishdate":"2022-08-05T17:59:14+09:00","readingtime":5,"relpermalink":"/blog/2022/08/05/upgrade-hugo-accidentally/","section":"post","summary":"Hugoを0.84から0.92にアップデートをする際に、これまでのブログ記事やレイアウトファイルを修正したので個人的にメモを残しておきます。","tags":["hugo"],"title":"Hugoをアップデートした","type":"post","url":"/blog/2022/08/05/upgrade-hugo-accidentally/","weight":0,"wordcount":2156},{"date":1658300650,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":1900,"kind":"page","lang":"ja","lastmod":1658300650,"objectID":"3384ea6bb47d70f8ca94b4510813f36a","permalink":"https://blog.johtani.info/blog/2022/07/20/querqy-architecture/","publishdate":"2022-07-20T16:04:10+09:00","readingtime":4,"relpermalink":"/blog/2022/07/20/querqy-architecture/","section":"post","summary":"今回はQuerqyのElasticsearchのプラグインがどんなつくりになっているか？をちょっとだけ調べてみました。 SolrでもElast","tags":["elasticsearch"],"title":"Querqyの調査（その2：アーキテクチャ）","type":"post","url":"/blog/2022/07/20/querqy-architecture/","weight":0,"wordcount":1813},{"date":1658285563,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":3500,"kind":"page","lang":"ja","lastmod":1658285563,"objectID":"779e444b4bc720a9eed97f19c41e8773","permalink":"https://blog.johtani.info/blog/2022/07/20/intro-querqy/","publishdate":"2022-07-20T11:52:43+09:00","readingtime":7,"relpermalink":"/blog/2022/07/20/intro-querqy/","section":"post","summary":"Querqyというクエリのリライト用のプラグインがあるのでどんなものかを調べてみました。とりあえずは概要をドキュメントから追いかけてみた感じ","tags":["elasticsearch"],"title":"Querqyの調査（その１）","type":"post","url":"/blog/2022/07/20/intro-querqy/","weight":0,"wordcount":3401},{"date":1655283615,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":3700,"kind":"page","lang":"ja","lastmod":1655283615,"objectID":"f56c19442484b3e4f47875b58b3f72b2","permalink":"https://blog.johtani.info/blog/2022/06/15/ttend-berlin-buzzwords-online/","publishdate":"2022-06-15T18:00:15+09:00","readingtime":8,"relpermalink":"/blog/2022/06/15/ttend-berlin-buzzwords-online/","section":"post","summary":"今年もBerlin Buzzwordsにオンライン出張してました。 今年はハイブリッドな開催だったようで、現地で再開している人もいるようでした。","tags":["conference","berlin buzzwords"],"title":"今年もオンラインでBerlin Buzzwordsに参加した","type":"post","url":"/blog/2022/06/15/ttend-berlin-buzzwords-online/","weight":0,"wordcount":3642},{"date":1655119446,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1655119446,"objectID":"5eebdf85fd1726db301194bfeeee4377","permalink":"https://blog.johtani.info/blog/2022/06/13/new-elasticsearch-java-client/","publishdate":"2022-06-13T20:24:06+09:00","readingtime":6,"relpermalink":"/blog/2022/06/13/new-elasticsearch-java-client/","section":"post","summary":"7.16で正式リリースされましたが、Elasticsearchの新しいJavaのクライアントが出ています。 使ってみたので、ちょっとだけ紹介で","tags":["elasticsearch","java"],"title":"Elasticsearchの新しいJavaクライアント","type":"post","url":"/blog/2022/06/13/new-elasticsearch-java-client/","weight":0,"wordcount":2677},{"date":1652856857,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":2100,"kind":"page","lang":"ja","lastmod":1652856857,"objectID":"7cc21814165879f72529e91682ece5c6","permalink":"https://blog.johtani.info/blog/2022/05/18/index-alias-in-azure-cognitive-search/","publishdate":"2022-05-18T15:54:17+09:00","readingtime":5,"relpermalink":"/blog/2022/05/18/index-alias-in-azure-cognitive-search/","section":"post","summary":"Azure Cognitive Searchで2月に新しい機能が公開されました。 「Index Alias」（インデックスの別名）です。まだ、パブリックプレビューの段階です","tags":["azure search"],"title":"インデックスエイリアス - Azure Cognitive Searchの新機能","type":"post","url":"/blog/2022/05/18/index-alias-in-azure-cognitive-search/","weight":0,"wordcount":2015},{"date":1641980462,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":3000,"kind":"page","lang":"ja","lastmod":1641980462,"objectID":"0645bdb1cdf88ec74288d503eb71839c","permalink":"https://blog.johtani.info/blog/2022/01/12/reading-xmc-for-semantic-search-in-prod/","publishdate":"2022-01-12T18:41:02+09:00","readingtime":6,"relpermalink":"/blog/2022/01/12/reading-xmc-for-semantic-search-in-prod/","section":"post","summary":"年末までに知り合いと次の論文を読んだので軽くまとめておきます。 Extreme Multi-label Learning for Semantic Matching in Product Search なんで読んだの？ 前回読んだ理由と一緒ですが、Semantic","tags":["search","paper"],"title":"Extreme Multi-label Learning for Semantic Matching in Product Searchという論文を読んだ","type":"post","url":"/blog/2022/01/12/reading-xmc-for-semantic-search-in-prod/","weight":0,"wordcount":2978},{"date":1640957359,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":1900,"kind":"page","lang":"ja","lastmod":1640957359,"objectID":"104b8ee17a8bf1f7043d236659680493","permalink":"https://blog.johtani.info/blog/2021/12/31/looking-back-2021/","publishdate":"2021-12-31T22:29:19+09:00","readingtime":4,"relpermalink":"/blog/2021/12/31/looking-back-2021/","section":"post","summary":"今年も振り返りブログです。録画した紅白をオッかけ再生して気になるアーティストだけ見ながら書ています。 振り返り（2020年に書いた抱負から） ま","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2021）","type":"post","url":"/blog/2021/12/31/looking-back-2021/","weight":0,"wordcount":1878},{"date":1640784504,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":2200,"kind":"page","lang":"ja","lastmod":1640784504,"objectID":"218e2c36d5945ece02fdc55d6cbcbc38","permalink":"https://blog.johtani.info/blog/2021/12/29/best-buy-2021/","publishdate":"2021-12-29T22:28:24+09:00","readingtime":5,"relpermalink":"/blog/2021/12/29/best-buy-2021/","section":"post","summary":"2021年もあと少しですが、今年買って良かったものをリストアップしておこうかと思います。 今年買ったといいながら、昨年このネタを書くといいつつ","tags":["misc"],"title":"2021年かって良かったもの","type":"post","url":"/blog/2021/12/29/best-buy-2021/","weight":0,"wordcount":2169},{"date":1640141671,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":600,"kind":"page","lang":"ja","lastmod":1640141671,"objectID":"f0fdc140e18514362a4e52376a6fecba","permalink":"https://blog.johtani.info/blog/2021/12/22/azure-search-schema-json2csv/","publishdate":"2021-12-22T11:54:31+09:00","readingtime":2,"relpermalink":"/blog/2021/12/22/azure-search-schema-json2csv/","section":"post","summary":"Azure Cognitive Searchのスキーマの確認をするときに、Azureのポータルでは次のようにフィールドの一覧として見ることができます。 ただ、実際のインデ","tags":["azure search","misc"],"title":"Azure Cognitive SearchのIndex Schema JSONをCSVで見たくなる","type":"post","url":"/blog/2021/12/22/azure-search-schema-json2csv/","weight":0,"wordcount":595},{"date":1638889200,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":2900,"kind":"page","lang":"ja","lastmod":1638889200,"objectID":"26e44dfd16a2963d4c18e99806c26fd7","permalink":"https://blog.johtani.info/blog/2021/12/08/controller-rack/","publishdate":"2021-12-08T00:00:00+09:00","readingtime":6,"relpermalink":"/blog/2021/12/08/controller-rack/","section":"post","summary":"今年もアドベントカレンダーの季節になってしまいました。 今年で2回目となる、pyspa Advent Calendar 2021の投稿です。 昨年に引き続きDIYがらみの投稿","tags":["DIYキーボード","misc"],"title":"今年のDIYキーボードとコントローラーラック","type":"post","url":"/blog/2021/12/08/controller-rack/","weight":0,"wordcount":2857},{"date":1636522396,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":2300,"kind":"page","lang":"ja","lastmod":1636522396,"objectID":"35200cbf0b5b45d7f5f0b343cb18868b","permalink":"https://blog.johtani.info/blog/2021/11/10/reading-ms-biomedical-search-paper/","publishdate":"2021-11-10T14:33:16+09:00","readingtime":5,"relpermalink":"/blog/2021/11/10/reading-ms-biomedical-search-paper/","section":"post","summary":"Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだので軽くメモを残しておきます。論文自体はリンクから参照してください。 読んだ理由 Azure Cognitive S","tags":["search","paper"],"title":"Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだ","type":"post","url":"/blog/2021/11/10/reading-ms-biomedical-search-paper/","weight":0,"wordcount":2247},{"date":1626160103,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":3300,"kind":"page","lang":"ja","lastmod":1626160103,"objectID":"10a7f69bd03d2632722300194f01e93d","permalink":"https://blog.johtani.info/blog/2021/07/13/attend-mices-2021/","publishdate":"2021-07-13T16:08:23+09:00","readingtime":7,"relpermalink":"/blog/2021/07/13/attend-mices-2021/","section":"post","summary":"今年もMICESにも参加してました。 昨年はBerlin Buzzwordsと共同開催でしたが、今年は別開催（別日程）でした。 MICESは201","tags":["conference","berlin buzzwords","MICES"],"title":"今年もMICESにオンライン出張してた","type":"post","url":"/blog/2021/07/13/attend-mices-2021/","weight":0,"wordcount":3240},{"date":1625815493,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":3000,"kind":"page","lang":"ja","lastmod":1625815493,"objectID":"59b7b60e6bbf4858d72643d22ad90451","permalink":"https://blog.johtani.info/blog/2021/07/09/berlin-buzzwords-2021-1/","publishdate":"2021-07-09T16:24:53+09:00","readingtime":6,"relpermalink":"/blog/2021/07/09/berlin-buzzwords-2021-1/","section":"post","summary":"今年もBerlin Buzzwordsにオンライン出張してました。 今年の開催は6月14日から17日まででした。 どんなカンファレンスなのかは昨年","tags":["conference","berlin buzzwords"],"title":"今年もBerlin Buzzwordsにオンライン出張してた","type":"post","url":"/blog/2021/07/09/berlin-buzzwords-2021-1/","weight":0,"wordcount":2903},{"date":1625130583,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":10800,"kind":"page","lang":"ja","lastmod":1625130583,"objectID":"43caef5d41c4e74826e4a8d82088739d","permalink":"https://blog.johtani.info/blog/2021/07/01/semantic-search-in-azure-cognitive-search/","publishdate":"2021-07-01T18:09:43+09:00","readingtime":22,"relpermalink":"/blog/2021/07/01/semantic-search-in-azure-cognitive-search/","section":"post","summary":"Azure Cognitive Searchで新機能「Semantic Search（セマンティック検索）」という機能の日本語対応が発表されました。 実際にはPublic P","tags":["azure search"],"title":"Azure Cognitive Searchの新機能、Semantic Searchを試してみた","type":"post","url":"/blog/2021/07/01/semantic-search-in-azure-cognitive-search/","weight":0,"wordcount":10723},{"date":1619709972,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":3300,"kind":"page","lang":"ja","lastmod":1619709972,"objectID":"f4baa43cc7ca712d83b99a794c4e2dbd","permalink":"https://blog.johtani.info/blog/2021/04/30/build-lunakey-mini-ble/","publishdate":"2021-04-30T00:26:12+09:00","readingtime":7,"relpermalink":"/blog/2021/04/30/build-lunakey-mini-ble/","section":"post","summary":"Sofle v2を長らく使っていましたが、コンパクトなのもやっぱりいいよなぁというときにKochi KeyboardからLunakey Miniが発売して","tags":["DIYキーボード","misc"],"title":"Lunakey Miniを組み立てて、BLE+LPME-IO化してみた #DIYキーボード","type":"post","url":"/blog/2021/04/30/build-lunakey-mini-ble/","weight":0,"wordcount":3274},{"date":1617615911,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":1700,"kind":"page","lang":"ja","lastmod":1617615911,"objectID":"f41d4fde94cbd7bbd28808dc080a2019","permalink":"https://blog.johtani.info/blog/2021/04/05/intro-marp/","publishdate":"2021-04-05T18:45:11+09:00","readingtime":4,"relpermalink":"/blog/2021/04/05/intro-marp/","section":"post","summary":"みなさんは、スライドの作成には何を使っていますか？ Keynote？Powerpoint？Google Slides？ 私は、Macでスライドを作","tags":["勉強会"],"title":"スライド作成の環境をMarpにしてみた","type":"post","url":"/blog/2021/04/05/intro-marp/","weight":0,"wordcount":1667},{"date":1617200894,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1617200894,"objectID":"ce426b7f3190c8a4a47d45ac799e91a4","permalink":"https://blog.johtani.info/blog/2021/03/31/search-tech-jp-slack/","publishdate":"2021-03-31T23:28:14+09:00","readingtime":2,"relpermalink":"/blog/2021/03/31/search-tech-jp-slack/","section":"post","summary":"新型コロナウィルスの影響もあり、オフラインで集まって勉強会も開催できなくなっています。 検索技術勉強会も、もう1年以上開催できていないです。 ス","tags":["勉強会"],"title":"検索技術に関する情報交換を目的としたSlackができました！","type":"post","url":"/blog/2021/03/31/search-tech-jp-slack/","weight":0,"wordcount":642},{"date":1614756213,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":4300,"kind":"page","lang":"ja","lastmod":1614756213,"objectID":"eced95e5f301a8340e83d81d3c0d5c0d","permalink":"https://blog.johtani.info/blog/2021/03/03/phrase-query-in-japanese/","publishdate":"2021-03-03T16:23:33+09:00","readingtime":9,"relpermalink":"/blog/2021/03/03/phrase-query-in-japanese/","section":"post","summary":"Azure Cognitive SearchにはOData式という書式で条件が書ける仕組みがあります。 ODataは検索条件（$filter）やソート条件（$orderb","tags":["azure search","elasticsearch"],"title":"OData式と日本語の検索(NGram)とフレーズ検索","type":"post","url":"/blog/2021/03/03/phrase-query-in-japanese/","weight":0,"wordcount":4269},{"date":1614246182,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":2900,"kind":"page","lang":"ja","lastmod":1614246182,"objectID":"fcb0105fa6b5777a133f247784b9d930","permalink":"https://blog.johtani.info/blog/2021/02/25/update-working-facility/","publishdate":"2021-02-25T18:43:02+09:00","readingtime":6,"relpermalink":"/blog/2021/02/25/update-working-facility/","section":"post","summary":"自宅の環境がいろいろと変わったのですが、書いていなかったので更新版です。 前回のブログ(2020/09)、前々回のブログ(2020/03)はそ","tags":["misc"],"title":"自宅の作業環境(2021/02)","type":"post","url":"/blog/2021/02/25/update-working-facility/","weight":0,"wordcount":2802},{"date":1612515120,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":4500,"kind":"page","lang":"ja","lastmod":1612515120,"objectID":"931b2ebd9bfaeb5dcf1973e724a1f8d0","permalink":"https://blog.johtani.info/blog/2021/02/05/autocomplete-and-suggest-on-azure-search/","publishdate":"2021-02-05T17:52:00+09:00","readingtime":9,"relpermalink":"/blog/2021/02/05/autocomplete-and-suggest-on-azure-search/","section":"post","summary":"Azure Cognitive SearchにSuggestやAutocompleteの機能があるのを見つけたので、どんな挙動なのかを調べてログとして残しておきます。 公","tags":["azure search"],"title":"Azure Cognitive Searchでオートコンプリートやサジェストをしてみる","type":"post","url":"/blog/2021/02/05/autocomplete-and-suggest-on-azure-search/","weight":0,"wordcount":4446},{"date":1612424444,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":600,"kind":"page","lang":"ja","lastmod":1612424444,"objectID":"aa61b4543e8a7c67fccabee27a6e99cd","permalink":"https://blog.johtani.info/blog/2021/02/04/reading-elements-of-computing-systems/","publishdate":"2021-02-04T16:40:44+09:00","readingtime":2,"relpermalink":"/blog/2021/02/04/reading-elements-of-computing-systems/","section":"post","summary":"オライリー・ジャパンから出ている「コンピュータシステムの理論と実装」を読み始めたのでメモを取ることに。 原著はオライリーじゃないのかというのが","tags":["輪読","Nand2Tetris"],"title":"「コンピュータシステムの理論と実装」を読み始めた #Nand2Tetris","type":"post","url":"/blog/2021/02/04/reading-elements-of-computing-systems/","weight":0,"wordcount":564},{"date":1612106122,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":4000,"kind":"page","lang":"ja","lastmod":1612106122,"objectID":"d95522c691013bfe66dd46ded85a98ed","permalink":"https://blog.johtani.info/blog/2021/02/01/apply-ble-to-sofle/","publishdate":"2021-02-01T00:15:22+09:00","readingtime":8,"relpermalink":"/blog/2021/02/01/apply-ble-to-sofle/","section":"post","summary":"Corne使ってましたが、数字キーがあるとどうなのかな？というのがやはり気になって。 そこに、Kochi KeyboardさんからSofle Keyboard v","tags":["DIYキーボード","misc"],"title":"Sofle v2を組み立てて、BLE+LPME-IO化してみた #DIYキーボード","type":"post","url":"/blog/2021/02/01/apply-ble-to-sofle/","weight":0,"wordcount":3955},{"date":1610332951,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1610332951,"objectID":"4ad8239a37f641bcd17abeb96106314e","permalink":"https://blog.johtani.info/blog/2021/01/11/apply-ble-and-lpme-to-corne/","publishdate":"2021-01-11T11:42:31+09:00","readingtime":6,"relpermalink":"/blog/2021/01/11/apply-ble-and-lpme-to-corne/","section":"post","summary":"メインマシンとMacは下記のサンワサプライのUSB接続のKVMスイッチを使っていますが、もう一台ノートPCがありここに接続しているCorne","tags":["DIYキーボード","misc"],"title":"Corne Light v2のBLE+LPME-IO対応 #DIYキーボード","type":"post","url":"/blog/2021/01/11/apply-ble-and-lpme-to-corne/","weight":0,"wordcount":2753},{"date":1609422526,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1609422526,"objectID":"64a421c2367372c3199c66a6420faf89","permalink":"https://blog.johtani.info/blog/2020/12/31/diy-pc/","publishdate":"2020-12-31T22:48:46+09:00","readingtime":4,"relpermalink":"/blog/2020/12/31/diy-pc/","section":"post","summary":"振り返りブログにも書きましたが、デスクトップPCを自作(DIY)しました。 組み立てたに使ったパーツのアフィリンクを貼っておきます。 10月くら","tags":["misc"],"title":"PCもDIYしました","type":"post","url":"/blog/2020/12/31/diy-pc/","weight":0,"wordcount":1772},{"date":1609406004,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":3100,"kind":"page","lang":"ja","lastmod":1609406004,"objectID":"a5b2ee641e10d3e4db8f888217ab9ecc","permalink":"https://blog.johtani.info/blog/2020/12/31/looking-back-2020/","publishdate":"2020-12-31T18:13:24+09:00","readingtime":7,"relpermalink":"/blog/2020/12/31/looking-back-2020/","section":"post","summary":"今年も振り返りブログ書いてます。カタンの航海者版を購入して家族とやってましたが、負けてしまいました。 振り返り（2019年に書いた抱負から） ま","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2020）","type":"post","url":"/blog/2020/12/31/looking-back-2020/","weight":0,"wordcount":3020},{"date":1608216955,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":7400,"kind":"page","lang":"ja","lastmod":1608216955,"objectID":"c6fc88bd57a0e57ddf22e2eb1bef892c","permalink":"https://blog.johtani.info/blog/2020/12/17/index_template_v2/","publishdate":"2020-12-17T23:55:55+09:00","readingtime":15,"relpermalink":"/blog/2020/12/17/index_template_v2/","section":"post","summary":"Elastic stack (Elasticsearch) Advent Calendar 2020の18日目の記事になります。 本日の勉強会でLTをしましたが、しゃべり足りなかったんで。 Elasticsearch 7.8でこっそりとリリースされたI","tags":["elasticsearch"],"title":"Index Template V2","type":"post","url":"/blog/2020/12/17/index_template_v2/","weight":0,"wordcount":7377},{"date":1607004824,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":4200,"kind":"page","lang":"ja","lastmod":1607004824,"objectID":"a46c601d03a3a26bc418d0096fe83a42","permalink":"https://blog.johtani.info/blog/2020/12/03/build_corne_choc/","publishdate":"2020-12-03T23:13:44+09:00","readingtime":9,"relpermalink":"/blog/2020/12/03/build_corne_choc/","section":"post","summary":"はじめまして、pyspa。 ということで、pyspa Advent Calendar 2020の4日目(大谷コンビの2号)の投稿になります。 コンビそろってキーボード記事です","tags":["DIYキーボード","misc"],"title":"Corne Chocolateを組み立てた #DIYキーボード","type":"post","url":"/blog/2020/12/03/build_corne_choc/","weight":0,"wordcount":4126},{"date":1604503527,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":5500,"kind":"page","lang":"ja","lastmod":1604503527,"objectID":"b16bddd1a6d3e5f4136446bebe7ffbc7","permalink":"https://blog.johtani.info/blog/2020/11/05/build-corne-light-v2/","publishdate":"2020-11-05T00:25:27+09:00","readingtime":11,"relpermalink":"/blog/2020/11/05/build-corne-light-v2/","section":"post","summary":"前回のブログのまとめに書いたように、セパレートタイプのキーボードであるCorne Light v2を作成したのでそのビルドログです。DIYキーボードとし","tags":["DIYキーボード","misc"],"title":"Corne Light v2を作成した #DIYキーボード","type":"post","url":"/blog/2020/11/05/build-corne-light-v2/","weight":0,"wordcount":5459},{"date":1603029710,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":3500,"kind":"page","lang":"ja","lastmod":1603029710,"objectID":"188c1ee5132a6752dfce5a0235354070","permalink":"https://blog.johtani.info/blog/2020/10/18/restart-windows-no1/","publishdate":"2020-10-18T23:01:50+09:00","readingtime":7,"relpermalink":"/blog/2020/10/18/restart-windows-no1/","section":"post","summary":"ヒゲが不評だったのでいつも通りの長さに切りました。 前回「Windowsをお試し中」と書きましたが、いくつかソフトをインストールしたりしたので","tags":["misc","windows"],"title":"Windowsへの移行（その１）","type":"post","url":"/blog/2020/10/18/restart-windows-no1/","weight":0,"wordcount":3425},{"date":1602727442,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1602727442,"objectID":"de37d9fae011687eb1eb5a127fcb89e3","permalink":"https://blog.johtani.info/blog/2020/10/15/restart-windows/","publishdate":"2020-10-15T11:04:02+09:00","readingtime":4,"relpermalink":"/blog/2020/10/15/restart-windows/","section":"post","summary":"ヒゲが伸びてきて(試しに伸ばしてる)不評を買っている今日このごろです。 自宅で作業することが多くなってきたので、自作PCでもと思っていますが、","tags":["misc","windows"],"title":"Windowsをお試し中","type":"post","url":"/blog/2020/10/15/restart-windows/","weight":0,"wordcount":1756},{"date":1602428006,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":3600,"kind":"page","lang":"ja","lastmod":1602428006,"objectID":"c377351433a941a927aab543931f6026","permalink":"https://blog.johtani.info/blog/2020/10/11/build-dozen0/","publishdate":"2020-10-11T23:53:26+09:00","readingtime":8,"relpermalink":"/blog/2020/10/11/build-dozen0/","section":"post","summary":"今年の春くらいから、セパレートタイプのキーボードが気になっています。 また、なんか知らないですが、Twitterのタイムラインが自作キーボード","tags":["DIYキーボード","misc"],"title":"Dozen0を作成した #DIYキーボード","type":"post","url":"/blog/2020/10/11/build-dozen0/","weight":0,"wordcount":3554},{"date":1601865378,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":4600,"kind":"page","lang":"ja","lastmod":1601865378,"objectID":"15932a656f7acfac897d27766eadc9e2","permalink":"https://blog.johtani.info/blog/2020/10/05/switch-fst-2-da/","publishdate":"2020-10-05T11:36:18+09:00","readingtime":10,"relpermalink":"/blog/2020/10/05/switch-fst-2-da/","section":"post","summary":"2020/10/06 11:00くらいにマージされました。 @minoru_osuka さんが開発を引き継いだLinderaというKuromojiのRustクローンがあります(リポジトリ)","tags":["Rust","Lindera"],"title":"LinderaのFSTをDoubleArrayTrieに変更した話","type":"post","url":"/blog/2020/10/05/switch-fst-2-da/","weight":0,"wordcount":4521},{"date":1600136614,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":3100,"kind":"page","lang":"ja","lastmod":1600136614,"objectID":"b2c4cf0fb96d02d37f03668caaecbc57","permalink":"https://blog.johtani.info/blog/2020/09/15/improve-search-no3/","publishdate":"2020-09-15T11:23:34+09:00","readingtime":6,"relpermalink":"/blog/2020/09/15/improve-search-no3/","section":"post","summary":"先日は「検索システムを構成するパーツ」ということで検索システムを構成しているパーツについて書いてみました。 大体、検索がうまくヒットしないとい","tags":["検索"],"title":"検索対象のデータとデータソース(検索システムに関する妄想その3)","type":"post","url":"/blog/2020/09/15/improve-search-no3/","weight":0,"wordcount":3003},{"date":1599531445,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":4200,"kind":"page","lang":"ja","lastmod":1599531445,"objectID":"d08a3fdc040bbbdd81c9927ce296318c","permalink":"https://blog.johtani.info/blog/2020/09/08/update-working-facility/","publishdate":"2020-09-08T11:17:25+09:00","readingtime":9,"relpermalink":"/blog/2020/09/08/update-working-facility/","section":"post","summary":"自宅環境に少しアップデートがあったので更新版です。 お客さんのおかげで相変わらず自宅で作業させてもらってるのもあり、昨今のコロナウイルスの影響","tags":["misc"],"title":"自宅の作業環境(2020/09)","type":"post","url":"/blog/2020/09/08/update-working-facility/","weight":0,"wordcount":4132},{"date":1599487900,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":3000,"kind":"page","lang":"ja","lastmod":1599487900,"objectID":"827de2d7a9d231f6bcb44caf35896c1f","permalink":"https://blog.johtani.info/blog/2020/09/07/intro-metered-rs/","publishdate":"2020-09-07T23:11:40+09:00","readingtime":6,"relpermalink":"/blog/2020/09/07/intro-metered-rs/","section":"post","summary":"Rustで便利なクレートを見つけたので、紹介がてら、自分のメモのためにブログに残しておきます。 そもそもの問題 Rustで処理を書いていて、なん","tags":["Rust"],"title":"meteredクレートの紹介","type":"post","url":"/blog/2020/09/07/intro-metered-rs/","weight":0,"wordcount":2974},{"date":1599445027,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1599445027,"objectID":"3c5d4d351e0fb9e33e0e8b6d1d43c0f2","permalink":"https://blog.johtani.info/blog/2020/09/07/reboot-nlp100-ch04/","publishdate":"2020-09-07T11:17:07+09:00","readingtime":6,"relpermalink":"/blog/2020/09/07/reboot-nlp100-ch04/","section":"post","summary":"Rustで言語処理100本ノックの第4章です。 前回はこちら。 今回は早めに続きをやりました。 「形態素解析」ですしね。 第4章の概要 吾輩は猫である","tags":["Rust","nlp100"],"title":"第4章終了(言語処理100本ノック2020)","type":"post","url":"/blog/2020/09/07/reboot-nlp100-ch04/","weight":0,"wordcount":2537},{"date":1599230785,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2300,"kind":"page","lang":"ja","lastmod":1599230785,"objectID":"eb2a5824e03996c1966bee38866ce349","permalink":"https://blog.johtani.info/blog/2020/09/04/reboot-nlp100-ch03/","publishdate":"2020-09-04T23:46:25+09:00","readingtime":5,"relpermalink":"/blog/2020/09/04/reboot-nlp100-ch03/","section":"post","summary":"Rustで言語処理100本ノックの第3章です。 前回はこちら。 少し間が空きましたが、再開しました。 間が空いた理由は。。。「正規表現」ですかね。","tags":["Rust","nlp100"],"title":"第3章終了(言語処理100本ノック2020)","type":"post","url":"/blog/2020/09/04/reboot-nlp100-ch03/","weight":0,"wordcount":2276},{"date":1597742807,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1597742807,"objectID":"f5effd616a3f8db6193b482caec37912","permalink":"https://blog.johtani.info/blog/2020/08/18/azure-search-with-terraform/","publishdate":"2020-08-18T18:26:47+09:00","readingtime":4,"relpermalink":"/blog/2020/08/18/azure-search-with-terraform/","section":"post","summary":"負荷を計測するために、数回、Azure Cognitive Searchのクラスターを起動したり、停止したりしてました。 これは、Terraformでやると楽でき","tags":["azure search"],"title":"TerraformでAzure Cognitive Searchのクラスターを起動","type":"post","url":"/blog/2020/08/18/azure-search-with-terraform/","weight":0,"wordcount":1957},{"date":1595907282,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":3400,"kind":"page","lang":"ja","lastmod":1595907282,"objectID":"11a61827e80739a6065960eb188d5758","permalink":"https://blog.johtani.info/blog/2020/07/28/improve-search-no2/","publishdate":"2020-07-28T12:34:42+09:00","readingtime":7,"relpermalink":"/blog/2020/07/28/improve-search-no2/","section":"post","summary":"先日は「システムの特徴と検索機能について」という感じでふんわり書きました。 まぁ、頭の中でぼんやり考えてることを文章にしてみた感じです。 他にも","tags":["検索"],"title":"検索システムを構成するパーツ(検索システムに関する妄想その2)","type":"post","url":"/blog/2020/07/28/improve-search-no2/","weight":0,"wordcount":3308},{"date":1595842134,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":4900,"kind":"page","lang":"ja","lastmod":1595842134,"objectID":"9da845cd31310b8952efd1be1881e651","permalink":"https://blog.johtani.info/blog/2020/07/27/improve-search-no1/","publishdate":"2020-07-27T18:28:54+09:00","readingtime":10,"relpermalink":"/blog/2020/07/27/improve-search-no1/","section":"post","summary":"今年の頭からシステムの検索周りを手伝う仕事をフリーランスとしてやっています。 検索の仕組みを知れば知るほど面白くなってきたからという理由になる","tags":["検索"],"title":"システムの特徴と検索機能について(検索システムに関する妄想その1)","type":"post","url":"/blog/2020/07/27/improve-search-no1/","weight":0,"wordcount":4875},{"date":1594288778,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1594288778,"objectID":"208a8c072ea521c813b86ca7730eb880","permalink":"https://blog.johtani.info/blog/2020/07/09/hap15-rust-the-book/","publishdate":"2020-07-09T18:59:38+09:00","readingtime":2,"relpermalink":"/blog/2020/07/09/hap15-rust-the-book/","section":"post","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第15章","type":"post","url":"/blog/2020/07/09/hap15-rust-the-book/","weight":0,"wordcount":864},{"date":1594005164,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":4000,"kind":"page","lang":"ja","lastmod":1594005164,"objectID":"e5cb2e5d501d3db2db5d8f14984a66d4","permalink":"https://blog.johtani.info/blog/2020/07/06/attend-berlin-buzzwords/","publishdate":"2020-07-06T12:12:44+09:00","readingtime":8,"relpermalink":"/blog/2020/07/06/attend-berlin-buzzwords/","section":"post","summary":"6月7日の週に開催されたBerlin Buzzwordsにオンライン出張してました。 Berlin Buzzwordsとは? ベルリンで開催されている、Big","tags":["conference","berlin buzzwords"],"title":"Berlin Buzzwordsにオンライン出張してた","type":"post","url":"/blog/2020/07/06/attend-berlin-buzzwords/","weight":0,"wordcount":3970},{"date":1593050518,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1593050518,"objectID":"bbd2824ff0d5b801bb6f5da3a2a1a888","permalink":"https://blog.johtani.info/blog/2020/06/25/analyzer-perf-test-with-luceneutil/","publishdate":"2020-06-25T11:01:58+09:00","readingtime":6,"relpermalink":"/blog/2020/06/25/analyzer-perf-test-with-luceneutil/","section":"post","summary":"luceneutil - マニアックなツールのセットアップの続きです。 今回も誰得?なブログなので興味ない場合は飛ばしましょう。 一応、luceneutilのREAD","tags":["lucene"],"title":"luceneutil - Analyzer性能テストへのkuromojiの追加","type":"post","url":"/blog/2020/06/25/analyzer-perf-test-with-luceneutil/","weight":0,"wordcount":2698},{"date":1592917109,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1592917109,"objectID":"8a1ea5d5cf843bc5955a94cfcc321e92","permalink":"https://blog.johtani.info/blog/2020/06/23/how-to-use-luceneutil/","publishdate":"2020-06-23T21:58:29+09:00","readingtime":4,"relpermalink":"/blog/2020/06/23/how-to-use-luceneutil/","section":"post","summary":"LuceneのFSTの修正に関連して、Kuromojiのパフォーマンス問題が出ているようです。 この問題自体はLucene 8.6.0以降で直る","tags":["lucene"],"title":"luceneutil - マニアックなツールのセットアップ","type":"post","url":"/blog/2020/06/23/how-to-use-luceneutil/","weight":0,"wordcount":1711},{"date":1591692240,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2900,"kind":"page","lang":"ja","lastmod":1591692240,"objectID":"82a115ab8d617e4e96813587fe3a6049","permalink":"https://blog.johtani.info/blog/2020/06/09/difference-analyzers-in-azure-search/","publishdate":"2020-06-09T17:44:00+09:00","readingtime":6,"relpermalink":"/blog/2020/06/09/difference-analyzers-in-azure-search/","section":"post","summary":"Azure Cognitive Searchで日本語を扱うときに、形態素解析器を使いたい場合、2種類のAnalyzerが用意されています。今回はこれらの違いがどんなもの","tags":["azure search","kuromoji"],"title":"Azure Cognitive Searchでの日本語向けAnalyzerの違い","type":"post","url":"/blog/2020/06/09/difference-analyzers-in-azure-search/","weight":0,"wordcount":2827},{"date":1591259849,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1591259849,"objectID":"e74d071363645a588f858b35231128c4","permalink":"https://blog.johtani.info/blog/2020/06/04/chap13-rust-the-book/","publishdate":"2020-06-04T17:37:29+09:00","readingtime":3,"relpermalink":"/blog/2020/06/04/chap13-rust-the-book/","section":"post","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第13章","type":"post","url":"/blog/2020/06/04/chap13-rust-the-book/","weight":0,"wordcount":1045},{"date":1590656815,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1590656815,"objectID":"163beeae9620c1a6a46a38aa7ebd9663","permalink":"https://blog.johtani.info/blog/2020/05/28/chap10-rust-the-book/","publishdate":"2020-05-28T18:06:55+09:00","readingtime":4,"relpermalink":"/blog/2020/05/28/chap10-rust-the-book/","section":"post","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第10章","type":"post","url":"/blog/2020/05/28/chap10-rust-the-book/","weight":0,"wordcount":1519},{"date":1590481367,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":4900,"kind":"page","lang":"ja","lastmod":1590481367,"objectID":"36dd94159e3e60076c0c6098086e255f","permalink":"https://blog.johtani.info/blog/2020/05/26/logging-azure-search-request/","publishdate":"2020-05-26T17:22:47+09:00","readingtime":10,"relpermalink":"/blog/2020/05/26/logging-azure-search-request/","section":"post","summary":"今回はAzure Cognitive SearchのSDKを利用したアプリケーションが、実際にAzure Cognitive Searchに対して送信しているリクエストのパラメータ","tags":["azure search",".net"],"title":"Azure Cognitive Searchのリクエストのロギング","type":"post","url":"/blog/2020/05/26/logging-azure-search-request/","weight":0,"wordcount":4847},{"date":1590117041,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1590117041,"objectID":"21982f43bc435f22efef22b309a48c66","permalink":"https://blog.johtani.info/blog/2020/05/22/watching-azure-cognirive-search-session-at-ms-build/","publishdate":"2020-05-22T12:10:41+09:00","readingtime":2,"relpermalink":"/blog/2020/05/22/watching-azure-cognirive-search-session-at-ms-build/","section":"post","summary":"Mircosoft Buildというイベントが今週ありました(MSの方やお客さんに教えてもらった)。 そこで、Azure Cognitive Searchのセッション(MyBuil","tags":["azure search"],"title":"Microsoft Build(2020)のAzure Cognirive Searchのセッションを見たのでメモ","type":"post","url":"/blog/2020/05/22/watching-azure-cognirive-search-session-at-ms-build/","weight":0,"wordcount":860},{"date":1589509037,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":3000,"kind":"page","lang":"ja","lastmod":1589509037,"objectID":"306cecb32320ead508346ad8fed3394d","permalink":"https://blog.johtani.info/blog/2020/05/15/elastic-stack-7_7/","publishdate":"2020-05-15T11:17:17+09:00","readingtime":6,"relpermalink":"/blog/2020/05/15/elastic-stack-7_7/","section":"post","summary":"ElasticのWorkplace Searchを触ってみています(その1、その2)が、Elastic Stackの7.7.0がリリースされてし","tags":["elastic stack"],"title":"Elastic Stack 7.7がリリースされた","type":"post","url":"/blog/2020/05/15/elastic-stack-7_7/","weight":0,"wordcount":2961},{"date":1589449406,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":400,"kind":"page","lang":"ja","lastmod":1589449406,"objectID":"1e220a934e16fd941bd804ca03865b60","permalink":"https://blog.johtani.info/blog/2020/05/14/chap9-rust-the-book/","publishdate":"2020-05-14T18:43:26+09:00","readingtime":1,"relpermalink":"/blog/2020/05/14/chap9-rust-the-book/","section":"post","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第9章","type":"post","url":"/blog/2020/05/14/chap9-rust-the-book/","weight":0,"wordcount":397},{"date":1589253809,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2300,"kind":"page","lang":"ja","lastmod":1589253809,"objectID":"09155bf417a93847b538ad607f78cca2","permalink":"https://blog.johtani.info/blog/2020/05/12/reboot-nlp100-ch02-12to19/","publishdate":"2020-05-12T12:23:29+09:00","readingtime":5,"relpermalink":"/blog/2020/05/12/reboot-nlp100-ch02-12to19/","section":"post","summary":"Rustで言語処理100本ノックの第2章の残りです。 前回はこちら。 ちなみに、標準入力から受け取る処理は書いてないです。 出力に関してはファイル","tags":["Rust","nlp100"],"title":"第2章の12から19まで(言語処理100本ノック2020)","type":"post","url":"/blog/2020/05/12/reboot-nlp100-ch02-12to19/","weight":0,"wordcount":2237},{"date":1588948640,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1588948640,"objectID":"c098c6f0901979bd914ed7a345200f90","permalink":"https://blog.johtani.info/blog/2020/05/08/rebootnlp100-ch02-10to11/","publishdate":"2020-05-08T23:37:20+09:00","readingtime":4,"relpermalink":"/blog/2020/05/08/rebootnlp100-ch02-10to11/","section":"post","summary":"気づいたら1ヶ月サボってました、ごめんなさい。。。 Rustで言語処理100本ノックの第2章をはじめました。 前回はこちら。 確認用のUnixコマ","tags":["Rust","nlp100"],"title":"第2章の10から11まで(言語処理100本ノック2020)","type":"post","url":"/blog/2020/05/08/rebootnlp100-ch02-10to11/","weight":0,"wordcount":1531},{"date":1588923657,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1588923657,"objectID":"2c3270f8797ace2fb37402ea6a09d126","permalink":"https://blog.johtani.info/blog/2020/05/08/reboot-nlp100-finish-ch01/","publishdate":"2020-05-08T16:40:57+09:00","readingtime":2,"relpermalink":"/blog/2020/05/08/reboot-nlp100-finish-ch01/","section":"post","summary":"Rustで言語処理100本ノックのリファクタリングの続き。 前回はこちら。 とっくに終わってたのに、ブログ書いてなかった。。。 08. 暗号文 pub fn cipher(text: \u0026amp;str) -\u0026gt;","tags":["Rust","nlp100"],"title":"第1章の08から09まで(言語処理100本ノック2020)","type":"post","url":"/blog/2020/05/08/reboot-nlp100-finish-ch01/","weight":0,"wordcount":828},{"date":1588818770,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":3300,"kind":"page","lang":"ja","lastmod":1588818770,"objectID":"44db1f1fefc97cd28d55d443f2bd2b63","permalink":"https://blog.johtani.info/blog/2020/05/07/install-workplace-search/","publishdate":"2020-05-07T11:32:50+09:00","readingtime":7,"relpermalink":"/blog/2020/05/07/install-workplace-search/","section":"post","summary":"前回はWorkplace Searchの概要について書きましたが、今回はインストールと構成要素について説明します。なお、2020/5/7時点で","tags":["elasticsearch","workplace search"],"title":"ElasticのWorkplace Searchを触ってみる - その2 - インストールと起動","type":"post","url":"/blog/2020/05/07/install-workplace-search/","weight":0,"wordcount":3222},{"date":1588318144,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1700,"kind":"page","lang":"ja","lastmod":1588318144,"objectID":"4d71d2a23c85fb7af20e8d1e8b3e0de8","permalink":"https://blog.johtani.info/blog/2020/05/01/intro-workplace-search/","publishdate":"2020-05-01T16:29:04+09:00","readingtime":4,"relpermalink":"/blog/2020/05/01/intro-workplace-search/","section":"post","summary":"2月のElastic社のブログですが、Enterprise Searchとこれまで呼んでいた製品をWorkplace Searchという製品名に","tags":["elasticsearch","workplace search"],"title":"ElasticのWorkplace Searchを触ってみる - その1","type":"post","url":"/blog/2020/05/01/intro-workplace-search/","weight":0,"wordcount":1696},{"date":1587951855,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":4000,"kind":"page","lang":"ja","lastmod":1587951855,"objectID":"be2c49ea5816e7daa6d3b3ff45353291","permalink":"https://blog.johtani.info/blog/2020/04/27/note-updating-dictionary/","publishdate":"2020-04-27T10:44:15+09:00","readingtime":8,"relpermalink":"/blog/2020/04/27/note-updating-dictionary/","section":"post","summary":"先日、Elasticsearchでのカスタム辞書の利用方法についてブログを書きました。 辞書の設定方法について記載しましたが、今回は辞書の更新","tags":["elasticsearch"],"title":"辞書の更新についての注意点","type":"post","url":"/blog/2020/04/27/note-updating-dictionary/","weight":0,"wordcount":3938},{"date":1587519056,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1587519056,"objectID":"15357b6978e83daa2d97692c861dc177","permalink":"https://blog.johtani.info/blog/2020/04/22/custom-dictionary-after-7-4/","publishdate":"2020-04-22T10:30:56+09:00","readingtime":4,"relpermalink":"/blog/2020/04/22/custom-dictionary-after-7-4/","section":"post","summary":"Elasticsearchで日本語を扱うときに、カスタム辞書を使いたいという要望がよくあります。 AWSのElasticsearch Servi","tags":["elasticsearch"],"title":"Kuromojiのカスタム辞書をインデックスの設定で指定","type":"post","url":"/blog/2020/04/22/custom-dictionary-after-7-4/","weight":0,"wordcount":1910},{"date":1587028650,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1587028650,"objectID":"f488aa62d39194824861a134567cadb8","permalink":"https://blog.johtani.info/blog/2020/04/16/chap8-rust-the-book/","publishdate":"2020-04-16T18:17:30+09:00","readingtime":4,"relpermalink":"/blog/2020/04/16/chap8-rust-the-book/","section":"post","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 第8章 7章はパ","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第8章","type":"post","url":"/blog/2020/04/16/chap8-rust-the-book/","weight":0,"wordcount":1744},{"date":1586423695,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1586423695,"objectID":"9a687babb0f44db51dc389b75bdaa19d","permalink":"https://blog.johtani.info/blog/2020/04/09/reboot-nlp100-ch01-03to05/","publishdate":"2020-04-09T18:14:55+09:00","readingtime":2,"relpermalink":"/blog/2020/04/09/reboot-nlp100-ch01-03to05/","section":"post","summary":"Rustで言語処理100本ノックのリファクタリングの続き。 前回はこちら。 コードも載せたほうが見やすいかなぁ? 03. 円周率 2年前はこちら。 どちらか","tags":["Rust","nlp100"],"title":"第1章の03から06まで(言語処理100本ノック2020)","type":"post","url":"/blog/2020/04/09/reboot-nlp100-ch01-03to05/","weight":0,"wordcount":812},{"date":1586338425,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1586338425,"objectID":"dc9580308938069159c5afc55b2f3b96","permalink":"https://blog.johtani.info/blog/2020/04/08/reboot-nlp10-with-rust/","publishdate":"2020-04-08T18:33:45+09:00","readingtime":3,"relpermalink":"/blog/2020/04/08/reboot-nlp10-with-rust/","section":"post","summary":"今回もツイートから。 言語処理100本ノックの2020年版を公開しました。最近の自然言語処理の研究動向を反映し、深層ニューラルネットワークに関","tags":["Rust","nlp100"],"title":"言語処理100本ノック、再び","type":"post","url":"/blog/2020/04/08/reboot-nlp10-with-rust/","weight":0,"wordcount":1013},{"date":1586255231,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1586255231,"objectID":"4fbdc9c57a37781dc5dd86f470c61d04","permalink":"https://blog.johtani.info/blog/2020/04/07/chap6-rust-the-book/","publishdate":"2020-04-07T19:27:11+09:00","readingtime":2,"relpermalink":"/blog/2020/04/07/chap6-rust-the-book/","section":"post","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 第6章 Enumです。matc","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第6章","type":"post","url":"/blog/2020/04/07/chap6-rust-the-book/","weight":0,"wordcount":721},{"date":1586143600,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1586143600,"objectID":"6fbf7c3d0f4f89e415e89cec28811a94","permalink":"https://blog.johtani.info/blog/2020/04/06/update-kuromoji-cli/","publishdate":"2020-04-06T12:26:40+09:00","readingtime":3,"relpermalink":"/blog/2020/04/06/update-kuromoji-cli/","section":"post","summary":"Kuromoji-CLIの使い方などについては過去のブログを御覧ください。 KuromojiのCLIコマンドとpicocliとGraalVM G","tags":["misc"],"title":"KuromojiのCLIコマンドにJSON出力とラティス出力を追加","type":"post","url":"/blog/2020/04/06/update-kuromoji-cli/","weight":0,"wordcount":1470},{"date":1585807758,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1200,"kind":"page","lang":"ja","lastmod":1585807758,"objectID":"8d9c3760395e8e0eb40e335b22750b68","permalink":"https://blog.johtani.info/blog/2020/04/02/chap5-rust-the-book/","publishdate":"2020-04-02T15:09:18+09:00","readingtime":3,"relpermalink":"/blog/2020/04/02/chap5-rust-the-book/","section":"post","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 第5章 構造体です。勝手知ったるなんとやら?","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第5章","type":"post","url":"/blog/2020/04/02/chap5-rust-the-book/","weight":0,"wordcount":1128},{"date":1585217511,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1585217511,"objectID":"3f431bf71ee866f626daf42bc915fa3f","permalink":"https://blog.johtani.info/blog/2020/03/26/working-facility/","publishdate":"2020-03-26T19:11:51+09:00","readingtime":6,"relpermalink":"/blog/2020/03/26/working-facility/","section":"post","summary":"すもけさんが在宅勤務環境をブログに書いてておもしろそうだな(あと、アフィリンク貼れるな)と思ったので自分の環境も書いてみようかなと。 私自身は","tags":["misc"],"title":"自宅の作業環境(2020)","type":"post","url":"/blog/2020/03/26/working-facility/","weight":0,"wordcount":2703},{"date":1585210331,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1585210331,"objectID":"7fded0345c258eea966c0b5ee1b7c7aa","permalink":"https://blog.johtani.info/blog/2020/03/26/chap4-rust-the-book/","publishdate":"2020-03-26T17:12:11+09:00","readingtime":3,"relpermalink":"/blog/2020/03/26/chap4-rust-the-book/","section":"post","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた 第4章 第4章です。たぶん、これがいちばん大事な概念だと思","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第4章","type":"post","url":"/blog/2020/03/26/chap4-rust-the-book/","weight":0,"wordcount":1028},{"date":1585102205,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2100,"kind":"page","lang":"ja","lastmod":1585102205,"objectID":"a7f0e85fcad4f5bc5ae5c18c10de4f9e","permalink":"https://blog.johtani.info/blog/2020/03/25/vsc-es-analzye-plugin/","publishdate":"2020-03-25T11:10:05+09:00","readingtime":5,"relpermalink":"/blog/2020/03/25/vsc-es-analzye-plugin/","section":"post","summary":"先日、Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)というブログを書きました。 このプラグインを作ってたタイミン","tags":["elasticsearch","visual studio code"],"title":"ElasticsearchのAnalyze APIのVisual Studio Codeのクライアントプラグイン","type":"post","url":"/blog/2020/03/25/vsc-es-analzye-plugin/","weight":0,"wordcount":2031},{"date":1584928642,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1584928642,"objectID":"48b5ab9805919736382ffea5a9554c02","permalink":"https://blog.johtani.info/blog/2020/03/23/start-reading-rust-the-book/","publishdate":"2020-03-23T10:57:22+09:00","readingtime":3,"relpermalink":"/blog/2020/03/23/start-reading-rust-the-book/","section":"post","summary":"自転車本を読み始めましたが、その前にRust the bookを読んだほうが良いかも?と知り合いと話をしていてなったので、先にRust the bookを読","tags":["rust","読書","rust-the-book"],"title":"Rust the Bookを読み始めた","type":"post","url":"/blog/2020/03/23/start-reading-rust-the-book/","weight":0,"wordcount":1359},{"date":1584582615,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2300,"kind":"page","lang":"ja","lastmod":1584582615,"objectID":"c9d257aba54475c20b3737ce7c779e55","permalink":"https://blog.johtani.info/blog/2020/03/19/azure-search-analyze-plugin/","publishdate":"2020-03-19T10:50:15+09:00","readingtime":5,"relpermalink":"/blog/2020/03/19/azure-search-analyze-plugin/","section":"post","summary":"動機 Azure Cognitive Searchを検索エンジンに使っているお客さんを手伝っています。 そこで、検索の基本的な話をさせていただきました(もともとJJUGナイ","tags":["azure search","visual studio code"],"title":"Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)","type":"post","url":"/blog/2020/03/19/azure-search-analyze-plugin/","weight":0,"wordcount":2288},{"date":1583140813,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":400,"kind":"page","lang":"ja","lastmod":1583140813,"objectID":"6f47cb314fd780c122adb8cc1f44f785","permalink":"https://blog.johtani.info/blog/2020/03/02/finish-bicycle-book-chap3/","publishdate":"2020-03-02T18:20:13+09:00","readingtime":1,"relpermalink":"/blog/2020/03/02/finish-bicycle-book-chap3/","section":"post","summary":"これまで 実践Rust入門はじめました 実践Rust入門の3章を読んでるところ 3章終了 3章の終わりまで読み終えた。 いきなり実践的なプログラムで少","tags":["rust","読書"],"title":"実践Rust入門の3章を読み終わった","type":"post","url":"/blog/2020/03/02/finish-bicycle-book-chap3/","weight":0,"wordcount":388},{"date":1582858179,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1582858179,"objectID":"d710a073be2da219a388a150eb7b6b6a","permalink":"https://blog.johtani.info/blog/2020/02/28/kuromoji-cli/","publishdate":"2020-02-28T11:49:39+09:00","readingtime":4,"relpermalink":"/blog/2020/02/28/kuromoji-cli/","section":"post","summary":"Kuromoji-CLI Rust初心者がRust製の日本語形態素解析器の開発を引き継いでみたという記事にありますが、LinderaというRust製の日本語形態素解","tags":["misc"],"title":"KuromojiのCLIコマンドとpicocliとGraalVM","type":"post","url":"/blog/2020/02/28/kuromoji-cli/","weight":0,"wordcount":1910},{"date":1582443437,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1582443437,"objectID":"71cf83ae0f45e9ede3a3f979b9c74933","permalink":"https://blog.johtani.info/blog/2020/02/23/bicycle-book-chap3/","publishdate":"2020-02-23T16:37:17+09:00","readingtime":2,"relpermalink":"/blog/2020/02/23/bicycle-book-chap3/","section":"post","summary":"これまでのはこちら。読書メモなので、本と合わせて読んでいただくのが良いです。 実践Rust入門はじめました 3章のクイックツアーを読んでます。 バ","tags":["rust","読書"],"title":"実践Rust入門の3章を読んでるところ","type":"post","url":"/blog/2020/02/23/bicycle-book-chap3/","weight":0,"wordcount":747},{"date":1582272302,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1582272302,"objectID":"daa3fe935b0be9f31b6b362ad9e0d2d6","permalink":"https://blog.johtani.info/blog/2020/02/21/best-buy-2019/","publishdate":"2020-02-21T17:05:02+09:00","readingtime":5,"relpermalink":"/blog/2020/02/21/best-buy-2019/","section":"post","summary":"もう2020年2月になってしまってますが、2019年に買って便利だったもの良かったものをいくつか記録に残しとこうかなと。 BRAVIA KJ-55X9500G Amazon | ソニー SONY 49","tags":["買い物"],"title":"2019年に買ってよかったもの","type":"post","url":"/blog/2020/02/21/best-buy-2019/","weight":0,"wordcount":2394},{"date":1582254240,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1900,"kind":"page","lang":"ja","lastmod":1582254240,"objectID":"ef8a399c9679ce4e9710c7c6ecf8bcc7","permalink":"https://blog.johtani.info/blog/2020/02/21/import-jugem-posts/","publishdate":"2020-02-21T12:04:00+09:00","readingtime":4,"relpermalink":"/blog/2020/02/21/import-jugem-posts/","section":"post","summary":"ブログ移行日記(その5)です。前回まではこちら ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4","tags":["hugo","ブログ"],"title":"ブログ移行日記(その5) - Jugemのブログを移行","type":"post","url":"/blog/2020/02/21/import-jugem-posts/","weight":0,"wordcount":1807},{"date":1582080481,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":5000,"kind":"page","lang":"ja","lastmod":1582080481,"objectID":"c3053579ae25e2fb9b967076a06373af","permalink":"https://blog.johtani.info/blog/2020/02/19/research-azure-cognitive-search/","publishdate":"2020-02-19T11:48:01+09:00","readingtime":10,"relpermalink":"/blog/2020/02/19/research-azure-cognitive-search/","section":"post","summary":"お手伝いしているお客さんがAzure Cognitive Searchを利用してます。 検索周り=Azure Cognitive Searchに関する手伝いをする形で入っており、 いく","tags":["azure search"],"title":"Azure Cognitive Searchでインデックスを作って検索","type":"post","url":"/blog/2020/02/19/research-azure-cognitive-search/","weight":0,"wordcount":4968},{"date":1581344427,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1581344427,"objectID":"7b080dc43fce482af14de61c6ab819a5","permalink":"https://blog.johtani.info/blog/2020/02/10/explore-search-system/","publishdate":"2020-02-10T23:20:27+09:00","readingtime":3,"relpermalink":"/blog/2020/02/10/explore-search-system/","section":"post","summary":"また、ツイートから始まるお話です。 まだまだ、検索システムってどんなものかを勉強したいしということで、こんなのをツイートしてました。 「検索シス","tags":["検索システム探訪"],"title":"「検索システム探訪」したいな=\u003eやりました","type":"post","url":"/blog/2020/02/10/explore-search-system/","weight":0,"wordcount":1481},{"date":1580558694,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1580558694,"objectID":"90f9355781403b92e844de8568863ae8","permalink":"https://blog.johtani.info/blog/2020/02/01/intro-board-game/","publishdate":"2020-02-01T21:04:54+09:00","readingtime":6,"relpermalink":"/blog/2020/02/01/intro-board-game/","section":"post","summary":"年末、何種類かのボードゲームを家族で楽しみました。 家族の感想を交えて簡単に紹介しようかと思います。 家族や知人でボードゲームを購入するときの参","tags":["ゲーム"],"title":"ボードゲーム紹介","type":"post","url":"/blog/2020/02/01/intro-board-game/","weight":0,"wordcount":2587},{"date":1580475492,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1580475492,"objectID":"7fcfaa8dd34dbd508f19e8ca0fcfda0f","permalink":"https://blog.johtani.info/blog/2020/01/31/start-reading-bicycle-book/","publishdate":"2020-01-31T21:58:12+09:00","readingtime":2,"relpermalink":"/blog/2020/01/31/start-reading-bicycle-book/","section":"post","summary":"実践Rust入門という本を買っていた(去年の7月だ。。。)のですが、積んであったので、時間を作って読み始めようかと。 実践Rust入門[言語仕","tags":["rust","読書"],"title":"実践Rust入門はじめました","type":"post","url":"/blog/2020/01/31/start-reading-bicycle-book/","weight":0,"wordcount":793},{"date":1580470659,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1580470659,"objectID":"c61a5bda3f1667498626ae52ad0362e0","permalink":"https://blog.johtani.info/blog/2020/01/31/start-freelance/","publishdate":"2020-01-31T20:37:39+09:00","readingtime":2,"relpermalink":"/blog/2020/01/31/start-freelance/","section":"post","summary":"12月に退職しますブログを書きましたが、その後どうなったのか?という話をしてないなと思ったので、一応現在の状況を書き留めておこううかと。 結論","tags":["転職"],"title":"フリーランスはじめました(仮)","type":"post","url":"/blog/2020/01/31/start-freelance/","weight":0,"wordcount":615},{"date":1580186404,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":3500,"kind":"page","lang":"ja","lastmod":1580283604,"objectID":"d9018f459d3c94a91e92b459e152f7e7","permalink":"https://blog.johtani.info/blog/2020/01/28/introduce-algolia/","publishdate":"2020-01-28T13:40:04+09:00","readingtime":7,"relpermalink":"/blog/2020/01/28/introduce-algolia/","section":"post","summary":"ブログ移行日記(その4)です。その他の記事はこちら。 ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(","tags":["ブログ"],"title":"ブログ移行日記(その4) - 検索機能(Algolia)の導入","type":"post","url":"/blog/2020/01/28/introduce-algolia/","weight":0,"wordcount":3425},{"date":1579853081,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":3000,"kind":"page","lang":"ja","lastmod":1579853081,"objectID":"99c9c80a6532e4ea3b535c5a92d07a25","permalink":"https://blog.johtani.info/blog/2020/01/24/setting-hugo/","publishdate":"2020-01-24T17:04:41+09:00","readingtime":6,"relpermalink":"/blog/2020/01/24/setting-hugo/","section":"post","summary":"ブログ移行日記(その3)です。その他の記事はこちら。 ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その4) ブログ移行日記(","tags":["ブログ"],"title":"ブログ移行日記(その3) - Hugoの設定と微調整(テーマに合わせた)","type":"post","url":"/blog/2020/01/24/setting-hugo/","weight":0,"wordcount":2970},{"date":1579775514,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1579775514,"objectID":"018b365b00dd3a6ad17c813d21590549","permalink":"https://blog.johtani.info/blog/2020/01/23/convert-md-from-octopress-to-hugo/","publishdate":"2020-01-23T19:31:54+09:00","readingtime":3,"relpermalink":"/blog/2020/01/23/convert-md-from-octopress-to-hugo/","section":"post","summary":"その他の記事はこちら ブログ移行日記(その1) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) ブログ移行日記(その2)","tags":["ブログ"],"title":"ブログ移行日記(その2) - Markdownファイルの変換","type":"post","url":"/blog/2020/01/23/convert-md-from-octopress-to-hugo/","weight":0,"wordcount":1287},{"date":1579659814,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1579659814,"objectID":"a65bd31d4c3dab0a41712823a5d6002b","permalink":"https://blog.johtani.info/blog/2020/01/22/intro-hugo-and-theme/","publishdate":"2020-01-22T11:23:34+09:00","readingtime":4,"relpermalink":"/blog/2020/01/22/intro-hugo-and-theme/","section":"post","summary":"その他の記事はこちら ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) 起因 いつものツイートから","tags":["ブログ"],"title":"ブログ移行日記(その1) - Hugoとテーマ","type":"post","url":"/blog/2020/01/22/intro-hugo-and-theme/","weight":0,"wordcount":1586},{"date":1579166617,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":300,"kind":"page","lang":"ja","lastmod":1579166617,"objectID":"3c299a4d77be8b4f886ce9fcd23a2561","permalink":"https://blog.johtani.info/blog/2020/01/16/moving-to-hugo/","publishdate":"2020-01-16T18:23:37+09:00","readingtime":1,"relpermalink":"/blog/2020/01/16/moving-to-hugo/","section":"post","summary":"5年くらい、Octopressを使用していましたが、更新されなくなっているのと、コンテンツの生成に時間がかかることもあり、 ほかのプラットフォ","tags":["hugo","ブログ","octopress"],"title":"OctopressからHugoへ移行中(まだ途中)","type":"post","url":"/blog/2020/01/16/moving-to-hugo/","weight":0,"wordcount":288},{"date":1577764743,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":2900,"kind":"page","lang":"ja","lastmod":1577764743,"objectID":"35aa9e09db936aee7ec407c431816573","permalink":"https://blog.johtani.info/blog/2019/12/31/looking-back-2019/","publishdate":"2019-12-31T12:59:03+09:00","readingtime":6,"relpermalink":"/blog/2019/12/31/looking-back-2019/","section":"post","summary":"今年も振り返りブログ書いてます。Sasukeがついてる。 振り返り（2018年に書いた抱負から） まずは去年の抱負を元に。 TOEIC 受けました。 お。TO","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2019）","type":"post","url":"/blog/2019/12/31/looking-back-2019/","weight":0,"wordcount":2844},{"date":1577063679,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":2200,"kind":"page","lang":"ja","lastmod":1577063679,"objectID":"1a1a8cc0040b356d06eacd22e0526476","permalink":"https://blog.johtani.info/blog/2019/12/23/whats-window-group-of-terminal/","publishdate":"2019-12-23T10:14:39+09:00","readingtime":5,"relpermalink":"/blog/2019/12/23/whats-window-group-of-terminal/","section":"post","summary":"このブログ書こうと思って、これまでMacのセットアップしてたんだった。。。 普段、macOSの標準ターミナルを使ってます。 で、ターミナルを使う","tags":["misc"],"title":"macOS標準のターミナルのウィンドウグループが便利","type":"post","url":"/blog/2019/12/23/whats-window-group-of-terminal/","weight":0,"wordcount":2170},{"date":1576624266,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1576624266,"objectID":"80c8fca02ebfecc7a931dad1ec38466e","permalink":"https://blog.johtani.info/blog/2019/12/18/introduce-homeshick/","publishdate":"2019-12-18T08:11:06+09:00","readingtime":2,"relpermalink":"/blog/2019/12/18/introduce-homeshick/","section":"post","summary":"ドットファイル系（.emacsとか）をこれまでは、PCを引っ越すたびにコピーしてたんですが、いいかげん、GitHubとかで管理したいなと。 で","tags":["misc"],"title":"homeshick導入","type":"post","url":"/blog/2019/12/18/introduce-homeshick/","weight":0,"wordcount":879},{"date":1576542903,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1576542903,"objectID":"f3ef819656f68b87a91c53afbd441fec","permalink":"https://blog.johtani.info/blog/2019/12/17/move-to-zsh/","publishdate":"2019-12-17T09:35:03+09:00","readingtime":3,"relpermalink":"/blog/2019/12/17/move-to-zsh/","section":"post","summary":"Macbook Proが新しくなり、OSがCatalinaになっちゃいました。 これまで使ってた、.bash_profileをコピーしてターミナルを立ち上げ","tags":["misc"],"title":"zshへの移行","type":"post","url":"/blog/2019/12/17/move-to-zsh/","weight":0,"wordcount":1298},{"date":1576458061,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1576458061,"objectID":"1abc586d67f0b6c05fd5e60f25492340","permalink":"https://blog.johtani.info/blog/2019/12/16/dockernize-octopress/","publishdate":"2019-12-16T10:01:01+09:00","readingtime":3,"relpermalink":"/blog/2019/12/16/dockernize-octopress/","section":"post","summary":"最近使っていたPCが手元からなくなったので、16インチ Macbook Proをセットアップしているところです。 で、時間もあるのでこれまでほったらかしてきた","tags":["octopress"],"title":"Octopress環境のDockerイメージ化","type":"post","url":"/blog/2019/12/16/dockernize-octopress/","weight":0,"wordcount":1503},{"date":1575615090,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":400,"kind":"page","lang":"ja","lastmod":1575615090,"objectID":"1bbf2ef67f096960e13d8578fa544536","permalink":"https://blog.johtani.info/blog/2019/12/06/leaving-elastic/","publishdate":"2019-12-06T15:51:30+09:00","readingtime":1,"relpermalink":"/blog/2019/12/06/leaving-elastic/","section":"post","summary":"本日、Elasticでの最終出社日でした。実際の退職日はまだ先ですが、有休消化という感じです。 思い返せばもう5年と5ヶ月も前ですが、Elas","tags":["転職"],"title":"退職します","type":"post","url":"/blog/2019/12/06/leaving-elastic/","weight":0,"wordcount":369},{"date":1575385200,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":2100,"kind":"page","lang":"ja","lastmod":1575385200,"objectID":"c2d39f2f7fe6cb69fc8efb6c5495c932","permalink":"https://blog.johtani.info/blog/2019/12/04/about-lucene-4056/","publishdate":"2019-12-04T00:00:00+09:00","readingtime":5,"relpermalink":"/blog/2019/12/04/about-lucene-4056/","section":"post","summary":"これは、情報検索・検索エンジン Advent Calendar 2019 の 4 日目の記事です。 1日目から、質の高いエントリーが続いていましたが、一旦休憩して頂く感じの記事になって","tags":["Lucene"],"title":"Apache LuceneのKuromojiのUniDicビルド対応パッチについて","type":"post","url":"/blog/2019/12/04/about-lucene-4056/","weight":0,"wordcount":2082},{"date":1575126000,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":3200,"kind":"page","lang":"ja","lastmod":1575126000,"objectID":"78da47d61c91c82809a3c97a791d26d2","permalink":"https://blog.johtani.info/blog/2019/12/01/whats-happen-at-elastic-in-2019/","publishdate":"2019-12-01T00:00:00+09:00","readingtime":7,"relpermalink":"/blog/2019/12/01/whats-happen-at-elastic-in-2019/","section":"post","summary":"Elastic stack (Elasticsearch) Advent Calendar 2019の1日目の記事になります。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみようと思います。毎年恒例ですね、","tags":["elasticsearch"],"title":"2019年のElastic StackとElastic","type":"post","url":"/blog/2019/12/01/whats-happen-at-elastic-in-2019/","weight":0,"wordcount":3116},{"date":1572000002,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":4000,"kind":"page","lang":"ja","lastmod":1572000002,"objectID":"11b3a28b536f34d3606427f835bd3ddf","permalink":"https://blog.johtani.info/blog/2019/10/25/bonefire-01/","publishdate":"2019-10-25T19:40:02+09:00","readingtime":8,"relpermalink":"/blog/2019/10/25/bonefire-01/","section":"post","summary":"Bonfire Data \u0026amp; Science #1にブログ枠で参加してきました。 ということで、メモです。 日時 : 2019/10/25 19:00 - 21:30 場所 : Yahoo! Japan サイト : https://yj-meetup.connpass.com/event/148121/ ハッシュタグ: #yjbonfire 概要 Data \u0026amp; Scienceと","tags":["勉強会"],"title":"Bonfire Data \u0026 Science #1に参加しました","type":"post","url":"/blog/2019/10/25/bonefire-01/","weight":0,"wordcount":3934},{"date":1570690589,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1570690589,"objectID":"d8041ae308961666b15aa1e57b0f9f35","permalink":"https://blog.johtani.info/blog/2019/10/10/review-es-next-step-2/","publishdate":"2019-10-10T15:56:29+09:00","readingtime":2,"relpermalink":"/blog/2019/10/10/review-es-next-step-2/","section":"post","summary":"この間のElasticsearch勉強会でAcroquest Technologyの人たちが技術書展7で販売されていた書籍を頂いてしまいました","tags":["書籍"],"title":"Elasticsearch NEXT STEP 2を頂きました","type":"post","url":"/blog/2019/10/10/review-es-next-step-2/","weight":0,"wordcount":860},{"date":1560939044,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1560939044,"objectID":"d96f80f23543850a2ee9fff8cd2cc53f","permalink":"https://blog.johtani.info/blog/2019/06/19/qr-code-with-meetup-dot-com/","publishdate":"2019-06-19T19:10:44+09:00","readingtime":6,"relpermalink":"/blog/2019/06/19/qr-code-with-meetup-dot-com/","section":"post","summary":"Twitterで「Meetup.comに切り替えたらー」みたいな話があったので、 受付用アプリとかなくてという話になったので、普段Elasti","tags":["勉強会"],"title":"勉強会の受付自作？アプリ？HTMLについて","type":"post","url":"/blog/2019/06/19/qr-code-with-meetup-dot-com/","weight":0,"wordcount":2729},{"date":1556204526,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1556204526,"objectID":"538e38fbc3f78cd61e1841d8141ddcc1","permalink":"https://blog.johtani.info/blog/2019/04/26/meetup-organizer-drinkup/","publishdate":"2019-04-26T00:02:06+09:00","readingtime":3,"relpermalink":"/blog/2019/04/26/meetup-organizer-drinkup/","section":"post","summary":"Elasticsearch勉強会や検索技術勉強会やってるんだけど、独学で勉強会やってるなーと思い、みんなはどうやってるんだろうとツイートして","tags":["勉強会"],"title":"勉強会運営座談会ってのをやってみた","type":"post","url":"/blog/2019/04/26/meetup-organizer-drinkup/","weight":0,"wordcount":1018},{"date":1551191880,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1551191880,"objectID":"b27bdabd8e1a6b7dc06886867331ceb3","permalink":"https://blog.johtani.info/blog/2019/02/26/start-search-engineering-tech-talk/","publishdate":"2019-02-26T23:38:00+09:00","readingtime":3,"relpermalink":"/blog/2019/02/26/start-search-engineering-tech-talk/","section":"post","summary":"どーも、johtaniです。 Search Engineering Tech Talkという勉強会に運営として参加して、第1回の勉強会を開始しました。 本日（2/26）は第1回目だったの","tags":["勉強会","検索"],"title":"Search Engineering Tech Talk(検索技術勉強会)の運営として参加して始めてみました。","type":"post","url":"/blog/2019/02/26/start-search-engineering-tech-talk/","weight":0,"wordcount":1012},{"date":1546240485,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":3800,"kind":"page","lang":"ja","lastmod":1546240485,"objectID":"6c226ee1519fbf910197cc1d5c5a5756","permalink":"https://blog.johtani.info/blog/2018/12/31/looking-back-2018/","publishdate":"2018-12-31T16:14:45+09:00","readingtime":8,"relpermalink":"/blog/2018/12/31/looking-back-2018/","section":"post","summary":"今年も振り返りブログをかけてます。よかったw 振り返り（2017年に書いた抱負から） まずは去年の抱負を元に。 もっと英語の継続＆TOEIC まぁ、","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2018）","type":"post","url":"/blog/2018/12/31/looking-back-2018/","weight":0,"wordcount":3757},{"date":1545663601,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1545663601,"objectID":"ee62cb0b9a97f990df1ed0266a7027e2","permalink":"https://blog.johtani.info/blog/2018/12/25/whats-new-in-elastic-stack-7/","publishdate":"2018-12-25T00:00:01+09:00","readingtime":4,"relpermalink":"/blog/2018/12/25/whats-new-in-elastic-stack-7/","section":"post","summary":"Elastic stack (Elasticsearch) Advent Calendar 2018の25日目の記事になります。 今年最後のAdvent Calendarです！来年も忘れてなければやるはず！ 今日は、すでにalp","tags":["elasticsearch"],"title":"Elastic Stack 7.0で入ってくる新機能をちょっと紹介","type":"post","url":"/blog/2018/12/25/whats-new-in-elastic-stack-7/","weight":0,"wordcount":1529},{"date":1543628918,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":3900,"kind":"page","lang":"ja","lastmod":1543628918,"objectID":"ba45ddd3042dad59a12e5937644f7246","permalink":"https://blog.johtani.info/blog/2018/12/01/whats-happen-at-elastic-in-2018/","publishdate":"2018-12-01T10:48:38+09:00","readingtime":8,"relpermalink":"/blog/2018/12/01/whats-happen-at-elastic-in-2018/","section":"post","summary":"Elastic stack (Elasticsearch) Advent Calendar 2018の1日目の記事になります。 ちょっと遅れちゃいました。。。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみよ","tags":["elasticsearch"],"title":"2018年のElastic StackとElastic","type":"post","url":"/blog/2018/12/01/whats-happen-at-elastic-in-2018/","weight":0,"wordcount":3863},{"date":1539794095,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1539794095,"objectID":"3fd9052870778e14ab4a5acbc8c24af4","permalink":"https://blog.johtani.info/blog/2018/10/18/items-for-long-businesstrip/","publishdate":"2018-10-18T01:34:55+09:00","readingtime":4,"relpermalink":"/blog/2018/10/18/items-for-long-businesstrip/","section":"post","summary":"（転職する少し前までパスポートすら持ってなかったのに）今の会社に転職してから、半年に1度の割合で海外への出張が発生する生活を送っています。 4","tags":["misc"],"title":"新規導入した長期出張用のアイテムをいくつか紹介","type":"post","url":"/blog/2018/10/18/items-for-long-businesstrip/","weight":0,"wordcount":1514},{"date":1539765230,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":1200,"kind":"page","lang":"ja","lastmod":1539765230,"objectID":"d3fa23c9066f943f10e8883de9340dea","permalink":"https://blog.johtani.info/blog/2018/10/17/26th-elasticsearch-tokyo-meetup/","publishdate":"2018-10-17T17:33:50+09:00","readingtime":3,"relpermalink":"/blog/2018/10/17/26th-elasticsearch-tokyo-meetup/","section":"post","summary":"毎月開催の2回目になります。 今回は日経さんの会場をお借りしての開催となりました。 前回から、スピーカーの募集をhttp://bit.ly/Sp","tags":["elasticsearch","勉強会"],"title":"第25回Elasticsearch勉強会を開催しました。","type":"post","url":"/blog/2018/10/17/26th-elasticsearch-tokyo-meetup/","weight":0,"wordcount":1103},{"date":1532843130,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1532843130,"objectID":"10ae016e19fff6ae9cfaeb8534fa47f9","permalink":"https://blog.johtani.info/blog/2018/07/29/apm-java-at-jjug/","publishdate":"2018-07-29T14:45:30+09:00","readingtime":3,"relpermalink":"/blog/2018/07/29/apm-java-at-jjug/","section":"post","summary":"7/25にJJUGナイトセミナーでElastic Stackの紹介とAPMのJava Agentの紹介をしたので、補足のブログです。 （久々に書く","tags":["勉強会"],"title":"JJUGナイトセミナーで話しました","type":"post","url":"/blog/2018/07/29/apm-java-at-jjug/","weight":0,"wordcount":1386},{"date":1524205801,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1524205801,"objectID":"04d818cbaac08b2915db15e0bffdcb5b","permalink":"https://blog.johtani.info/blog/2018/04/20/directory-layout-and-architecture/","publishdate":"2018-04-20T15:30:01+09:00","readingtime":6,"relpermalink":"/blog/2018/04/20/directory-layout-and-architecture/","section":"post","summary":"第2回から少し間が空いてしまいましたが、templateで作成したプラグインのディレクトリ構成とどういう流れでデータがやり取りされるかについ","tags":["Kibana","plugin"],"title":"Analyze UIとKibanaのプラグインの作成方法（第3回）","type":"post","url":"/blog/2018/04/20/directory-layout-and-architecture/","weight":0,"wordcount":2719},{"date":1521867012,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1521867012,"objectID":"8cc6b19cd410e638f4beaf1642f4f52a","permalink":"https://blog.johtani.info/blog/2018/03/24/how-to-find-conferences/","publishdate":"2018-03-24T13:50:12+09:00","readingtime":2,"relpermalink":"/blog/2018/03/24/how-to-find-conferences/","section":"post","summary":"#MANABIYA のブースでセッション時間の合間はお客さん少ないので、ブログを書いてみたり。 ここ数年、スポンサーとして色々なカンファレンスに参加してるんです","tags":["カンファレンス","スポンサー"],"title":"カンファレンス情報の探し方（CfP、スポンサー応募、開催期間など）？","type":"post","url":"/blog/2018/03/24/how-to-find-conferences/","weight":0,"wordcount":874},{"date":1521549285,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1521549285,"objectID":"d791eaca9375ca1b36a987af22ee71dd","permalink":"https://blog.johtani.info/blog/2018/03/20/nlp100-ch01-05to06/","publishdate":"2018-03-20T21:34:45+09:00","readingtime":3,"relpermalink":"/blog/2018/03/20/nlp100-ch01-05to06/","section":"post","summary":"Rustで言語処理100本ノックの続きで、05と06です。 05. n-gram 問題はこちら。 みんな大好きn-gramです。単語と文字があるので、それぞれ別関","tags":["Rust","nlp100"],"title":"第1章の05から06までやってみた（言語処理100本ノック）","type":"post","url":"/blog/2018/03/20/nlp100-ch01-05to06/","weight":0,"wordcount":1227},{"date":1519032848,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1519032848,"objectID":"e6684944c37dbdd4c08d978af9e47bed","permalink":"https://blog.johtani.info/blog/2018/02/19/nlp100-ch01-03to04/","publishdate":"2018-02-19T18:34:08+09:00","readingtime":3,"relpermalink":"/blog/2018/02/19/nlp100-ch01-03to04/","section":"post","summary":"Rustで言語処理100本ノックの続きで、03と04です。 03. 円周率 問題はこちら。 入力文字列を.split_whitespace()で分割して","tags":["Rust","nlp100"],"title":"第1章の03から04までやってみた（言語処理100本ノック）","type":"post","url":"/blog/2018/02/19/nlp100-ch01-03to04/","weight":0,"wordcount":1306},{"date":1518699541,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1518699541,"objectID":"bbe1deec11d459bdb348051b970abdaf","permalink":"https://blog.johtani.info/blog/2018/02/15/nlp100-ch01-00to02/","publishdate":"2018-02-15T21:59:01+09:00","readingtime":2,"relpermalink":"/blog/2018/02/15/nlp100-ch01-00to02/","section":"post","summary":"「鉄は熱いうちに打て」ということで、言語処理100本ノックの第1章の00から02を実装してみました。 さて、これが効率がいいのかどうかはさてお","tags":["Rust","nlp100"],"title":"第1章の00から02までやってみた（言語処理100本ノック）","type":"post","url":"/blog/2018/02/15/nlp100-ch01-00to02/","weight":0,"wordcount":659},{"date":1518605551,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":500,"kind":"page","lang":"ja","lastmod":1518605551,"objectID":"a673b3829e62477e01abc75465416b86","permalink":"https://blog.johtani.info/blog/2018/02/14/start-nlp100-with-rust/","publishdate":"2018-02-14T19:52:31+09:00","readingtime":1,"relpermalink":"/blog/2018/02/14/start-nlp100-with-rust/","section":"post","summary":"ども。新しいもの始めないと頭が退化する。。。ということで、こちら（ happy new year and new language - katsyoshiのめもみたいなもの）のブログに触発されて、","tags":["Rust","nlp100"],"title":"言語処理100本ノックはじめました(Rust)","type":"post","url":"/blog/2018/02/14/start-nlp100-with-rust/","weight":0,"wordcount":451},{"date":1518167857,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":3500,"kind":"page","lang":"ja","lastmod":1518167857,"objectID":"7b6cb59a177abe9767fd22da5a03b1e6","permalink":"https://blog.johtani.info/blog/2018/02/09/getting-started-template-kibana-plugin/","publishdate":"2018-02-09T18:17:37+09:00","readingtime":7,"relpermalink":"/blog/2018/02/09/getting-started-template-kibana-plugin/","section":"post","summary":"第1回では、Analyze UIというプラグインの紹介をしました、ごく簡単にですが。 第2回では、Kibanaのプラグインの作成方法を順を追って","tags":["Kibana","plugin"],"title":"Analyze UIとKibanaのプラグインの作成方法（第2回）","type":"post","url":"/blog/2018/02/09/getting-started-template-kibana-plugin/","weight":0,"wordcount":3461},{"date":1516343806,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1516343806,"objectID":"4afcb20d4d95bcd1bde3aa6b7f552660","permalink":"https://blog.johtani.info/blog/2018/01/19/how-to-make-kibana-plugin-example-analysis-ui/","publishdate":"2018-01-19T15:36:46+09:00","readingtime":3,"relpermalink":"/blog/2018/01/19/how-to-make-kibana-plugin-example-analysis-ui/","section":"post","summary":"あけましておめでとうございます。今年はサボりがちだったブログをちょっとずつ復活させようかと。 ということで、第1弾として、昨年少し作っていたK","tags":["Kibana","plugin"],"title":"Analyze UIとKibanaのプラグインの作成方法（第1回）","type":"post","url":"/blog/2018/01/19/how-to-make-kibana-plugin-example-analysis-ui/","weight":0,"wordcount":1461},{"date":1514723443,"dir":"post/2017/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1514723443,"objectID":"7c21b70f9e9c782c1f5153268e0cc1c1","permalink":"https://blog.johtani.info/blog/2017/12/31/looking-back-2017/","publishdate":"2017-12-31T21:30:43+09:00","readingtime":6,"relpermalink":"/blog/2017/12/31/looking-back-2017/","section":"post","summary":"今年は紅白を見ながら書いてます。 今年はいろんなところに出張に行ったなぁ。 振り返り（2016年に書いた抱負から） まずは去年の抱負を元に。 もちろ","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2017）","type":"post","url":"/blog/2017/12/31/looking-back-2017/","weight":0,"wordcount":2712},{"date":1514124616,"dir":"post/2017/","expirydate":-62135596800,"fuzzywordcount":1200,"kind":"page","lang":"ja","lastmod":1514124616,"objectID":"f3a9b931b7f552a4f9dfa61ce4f39f0e","permalink":"https://blog.johtani.info/blog/2017/12/24/elastic-2018/","publishdate":"2017-12-24T23:10:16+09:00","readingtime":3,"relpermalink":"/blog/2017/12/24/elastic-2018/","section":"post","summary":"Merry Christmas! Elastic Stack Advent Calendar 2017の24日目の記事になります。 ちょっとですが、2018年のElasticについて書いてみようかと思います。 イベント いくつか","tags":["elasticsearch"],"title":"2018年のElasticは？","type":"post","url":"/blog/2017/12/24/elastic-2018/","weight":0,"wordcount":1161},{"date":1512054000,"dir":"post/2017/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1512054000,"objectID":"fa0486610d8a02cea245c13c85b6de27","permalink":"https://blog.johtani.info/blog/2017/12/01/whats-happen-at-elastic-in-2017/","publishdate":"2017-12-01T00:00:00+09:00","readingtime":6,"relpermalink":"/blog/2017/12/01/whats-happen-at-elastic-in-2017/","section":"post","summary":"Elastic stack (Elasticsearch) Advent Calendar 2017の1日目の記事になります。 まだ、1ヶ月を残していますが、簡単に今年起こったことを振り返ってみようかと思います。思った以上に","tags":["elasticsearch"],"title":"2017年のElastic StackとElastic","type":"post","url":"/blog/2017/12/01/whats-happen-at-elastic-in-2017/","weight":0,"wordcount":2742},{"date":1510280089,"dir":"post/2017/","expirydate":-62135596800,"fuzzywordcount":1200,"kind":"page","lang":"ja","lastmod":1510280089,"objectID":"c20d71627e66a044b21780f56f2f9504","permalink":"https://blog.johtani.info/blog/2017/11/10/welcome-swiftype/","publishdate":"2017-11-10T11:14:49+09:00","readingtime":3,"relpermalink":"/blog/2017/11/10/welcome-swiftype/","section":"post","summary":"Swiftypeでサイト内検索？ プレスリリース：Elasticがサイト内検索サービス最大手のSwiftypeを買収が出ましたが、Swifty","tags":null,"title":"Swiftypeがジョインしたので触ってみました","type":"post","url":"/blog/2017/11/10/welcome-swiftype/","weight":0,"wordcount":1139},{"date":1505955750,"dir":"post/2017/","expirydate":-62135596800,"fuzzywordcount":400,"kind":"page","lang":"ja","lastmod":1505955750,"objectID":"4f88f3eebe44285ded812939553ef94c","permalink":"https://blog.johtani.info/blog/2017/09/21/release-intro-logging-analysis-system/","publishdate":"2017-09-21T10:02:30+09:00","readingtime":1,"relpermalink":"/blog/2017/09/21/release-intro-logging-analysis-system/","section":"post","summary":"久々に執筆しました。といっても、以前の書籍の更新版です。 まぁ、更新版といっても、私以外の方々は結構な量を書き直しor新規書き起こしされてます","tags":["elasticsearch","kibana","本"],"title":"データ分析基盤構築入門 を一部執筆しました。","type":"post","url":"/blog/2017/09/21/release-intro-logging-analysis-system/","weight":0,"wordcount":370},{"date":1495639453,"dir":"post/2017/","expirydate":-62135596800,"fuzzywordcount":600,"kind":"page","lang":"ja","lastmod":1495639453,"objectID":"29b4c2b5adcd80ced1612128b3ca95a9","permalink":"https://blog.johtani.info/blog/2017/05/25/search-meetup/","publishdate":"2017-05-25T00:24:13+09:00","readingtime":2,"relpermalink":"/blog/2017/05/25/search-meetup/","section":"post","summary":"久々のブログ。 Elasticsearch勉強会を主催してますが、 プロダクトを超えて、検索で共通してある課題とか、悩みとか、あるかなぁと。 その","tags":["勉強会"],"title":"検索座談会ってのをやってみた","type":"post","url":"/blog/2017/05/25/search-meetup/","weight":0,"wordcount":565},{"date":1483190534,"dir":"post/2016/","expirydate":-62135596800,"fuzzywordcount":2200,"kind":"page","lang":"ja","lastmod":1483190534,"objectID":"16f1046144ad9ee7bb96214ba7ae7516","permalink":"https://blog.johtani.info/blog/2016/12/31/looking-back-2016/","publishdate":"2016-12-31T22:22:14+09:00","readingtime":5,"relpermalink":"/blog/2016/12/31/looking-back-2016/","section":"post","summary":"今年はRioのプレイバック\u000e見ながら書いてます。 今年はなんか長い一年だった気が。 振り返り（2015年に書いた抱負から） まずは去年の抱負を元に","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2016）","type":"post","url":"/blog/2016/12/31/looking-back-2016/","weight":0,"wordcount":2199},{"date":1482591830,"dir":"post/2016/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1482591830,"objectID":"002d980d74d19b43ff4e2446665e2fe5","permalink":"https://blog.johtani.info/blog/2016/12/25/elasticsearch-6-features/","publishdate":"2016-12-25T00:03:50+09:00","readingtime":5,"relpermalink":"/blog/2016/12/25/elasticsearch-6-features/","section":"post","summary":"Merry Christmas! Elastic stack Advent Calendar 2016 最終日の記事になります。 簡単に今年の変遷を振り返ってみます。 Elasticsearch 2.2 (2月) Elasticsearch 2.2.0、2.1.2、1.7.5リリース クエリプロ","tags":["elasticsearch"],"title":"2016年のElastic Stack","type":"post","url":"/blog/2016/12/25/elasticsearch-6-features/","weight":0,"wordcount":2347},{"date":1480581270,"dir":"post/2016/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1480581270,"objectID":"550becdd08d00fb1e7fd00c2adc3d3d6","permalink":"https://blog.johtani.info/blog/2016/12/01/elasticsearch-5-dot-0-highlight/","publishdate":"2016-12-01T17:34:30+09:00","readingtime":3,"relpermalink":"/blog/2016/12/01/elasticsearch-5-dot-0-highlight/","section":"post","summary":"Elastic stack Advent Calendar 1日目の記事になります。 Elasticsearch 5.0が10月末にリリースされました。 リリースのブログでいくつか紹介されているのですが、そこでは紹介されて","tags":["elasticsearch"],"title":"Elasticsearch 5.0の便利機能紹介？","type":"post","url":"/blog/2016/12/01/elasticsearch-5-dot-0-highlight/","weight":0,"wordcount":1330},{"date":1469161616,"dir":"post/2016/","expirydate":-62135596800,"fuzzywordcount":3800,"kind":"page","lang":"ja","lastmod":1469161616,"objectID":"a62186ea292d6db03a087bd5dfcc3f1e","permalink":"https://blog.johtani.info/blog/2016/07/22/making-ingest-processor-plugin-with-cookiecutter/","publishdate":"2016-07-22T13:26:56+09:00","readingtime":8,"relpermalink":"/blog/2016/07/22/making-ingest-processor-plugin-with-cookiecutter/","section":"post","summary":"久しぶりに、技術的なブログ書いてます。 Ingest Processorのプラグインを作ってみたくなったので、書いてみました。 ただ書いてみるんじゃ3番煎じ","tags":["elasticsearch","plugin"],"title":"Lucene Kuromoji for NEologdで指定した品詞の単語を抜き出すIngest Pluginを書いてみた #elasticsearchjp","type":"post","url":"/blog/2016/07/22/making-ingest-processor-plugin-with-cookiecutter/","weight":0,"wordcount":3710},{"date":1467251858,"dir":"post/2016/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1467251858,"objectID":"167e2a6833d49ce198cb3b88f521991e","permalink":"https://blog.johtani.info/blog/2016/06/30/broken-something-in-this-year/","publishdate":"2016-06-30T10:57:38+09:00","readingtime":2,"relpermalink":"/blog/2016/06/30/broken-something-in-this-year/","section":"post","summary":"なんか、今年はよく物が壊れる、厄年だからかなぁ？ ということで、記念に何が壊れたかをブログに残しておこうかと。 腕時計（壊れてないかな） 電波腕時","tags":["misc"],"title":"よく物が壊れる年","type":"post","url":"/blog/2016/06/30/broken-something-in-this-year/","weight":0,"wordcount":654},{"date":1467089755,"dir":"post/2016/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1467089755,"objectID":"993e58f132740b464ecf06ee289dc7b2","permalink":"https://blog.johtani.info/blog/2016/06/28/16th-elasticsearch-meetup/","publishdate":"2016-06-28T13:55:55+09:00","readingtime":4,"relpermalink":"/blog/2016/06/28/16th-elasticsearch-meetup/","section":"post","summary":"第16回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第16回Elasticsearch勉強会を開催しました。 #elasticsearchjp","type":"post","url":"/blog/2016/06/28/16th-elasticsearch-meetup/","weight":0,"wordcount":1952},{"date":1458186180,"dir":"post/2016/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1458186180,"objectID":"c56a76ef8f604a8d87be2a32b1f81fac","permalink":"https://blog.johtani.info/blog/2016/03/17/15th-elasticsearch-jp/","publishdate":"2016-03-17T12:43:00+09:00","readingtime":3,"relpermalink":"/blog/2016/03/17/15th-elasticsearch-jp/","section":"post","summary":"第15回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第15回Elasticsearch勉強会を開催しました。 #elasticsearchjp","type":"post","url":"/blog/2016/03/17/15th-elasticsearch-jp/","weight":0,"wordcount":1302},{"date":1457962452,"dir":"post/2016/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1457962452,"objectID":"3fc7462a83fa55885067fee629287e8a","permalink":"https://blog.johtani.info/blog/2016/03/14/review-basics-and-tech-of-nlp/","publishdate":"2016-03-14T22:34:12+09:00","readingtime":2,"relpermalink":"/blog/2016/03/14/review-basics-and-tech-of-nlp/","section":"post","summary":"久々のポスト。。。 久々に、技術書読んでます。「自然言語処理の基本と技術」という本です。 監修の方のツイートを見て気になったので、買ってみました","tags":["本"],"title":"「自然言語処理の基本と技術」を読んでる","type":"post","url":"/blog/2016/03/14/review-basics-and-tech-of-nlp/","weight":0,"wordcount":746},{"date":1452220496,"dir":"post/2016/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1452220496,"objectID":"4b0a768585da8f9f8f8db1ca409e7ebd","permalink":"https://blog.johtani.info/blog/2016/01/08/14th-elasticcsearch-jp/","publishdate":"2016-01-08T11:34:56+09:00","readingtime":5,"relpermalink":"/blog/2016/01/08/14th-elasticcsearch-jp/","section":"post","summary":"あけましておめでとうございます、johtaniです。 第14回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆","tags":["elasticsearch","勉強会"],"title":"第14回Elasticsearch勉強会を開催しました。 #elasticsearchjp","type":"post","url":"/blog/2016/01/08/14th-elasticcsearch-jp/","weight":0,"wordcount":2488},{"date":1451565182,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1451565182,"objectID":"c54909ecf4fb3e9afeea36200fe95dce","permalink":"https://blog.johtani.info/blog/2015/12/31/looking-back-2015/","publishdate":"2015-12-31T21:33:02+09:00","readingtime":3,"relpermalink":"/blog/2015/12/31/looking-back-2015/","section":"post","summary":"今年は紅白見ながら書いてます。 早い一年だったなぁ。 振り返り(2014年に書いた抱負から) まずは去年の抱負を元に振り返りをば。 英語の継続 海外の","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2015）","type":"post","url":"/blog/2015/12/31/looking-back-2015/","weight":0,"wordcount":1383},{"date":1451017794,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1451017794,"objectID":"d819cea5197e9b8673d6c0b16659a5ea","permalink":"https://blog.johtani.info/blog/2015/12/25/about-elasticsearch-in-2015/","publishdate":"2015-12-25T13:29:54+09:00","readingtime":6,"relpermalink":"/blog/2015/12/25/about-elasticsearch-in-2015/","section":"post","summary":"今年最後のAdvent Calendarとなります。 この記事はElasticsearch Advent Calendar 2015の最終日のエントリです。 簡単に今年の変遷を","tags":["elasticsearch"],"title":"2015年のElasticsearch","type":"post","url":"/blog/2015/12/25/about-elasticsearch-in-2015/","weight":0,"wordcount":2634},{"date":1448936891,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1900,"kind":"page","lang":"ja","lastmod":1448936891,"objectID":"1b56132638912a1ca54fcf7cd38b8e23","permalink":"https://blog.johtani.info/blog/2015/12/01/introduction-timelion/","publishdate":"2015-12-01T11:28:11+09:00","readingtime":4,"relpermalink":"/blog/2015/12/01/introduction-timelion/","section":"post","summary":"こんにちは、@johtaniです。 早いもので、師走です。今年もあと少しとなりました（今月が一番忙しかったりしますが。。。）。 ということで、A","tags":["kibana","timelion"],"title":"Timelionの紹介 - Elasticsearch Advent Calendar 2015 1日目","type":"post","url":"/blog/2015/12/01/introduction-timelion/","weight":0,"wordcount":1858},{"date":1447143778,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1447143778,"objectID":"2ea86ae5093670df1d4502ea82efa1ac","permalink":"https://blog.johtani.info/blog/2015/11/10/13th-elasticsearch-jp/","publishdate":"2015-11-10T17:22:58+09:00","readingtime":4,"relpermalink":"/blog/2015/11/10/13th-elasticsearch-jp/","section":"post","summary":"第13回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第13回Elasticsearch勉強会を開催しました。#elasticsearchjp","type":"post","url":"/blog/2015/11/10/13th-elasticsearch-jp/","weight":0,"wordcount":1765},{"date":1446195306,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":3700,"kind":"page","lang":"ja","lastmod":1446195306,"objectID":"5912529cfd6ce14c5ede5c6c83dae7e8","permalink":"https://blog.johtani.info/blog/2015/10/30/sense-2-0-0-beta1-ja/","publishdate":"2015-10-30T17:55:06+09:00","readingtime":8,"relpermalink":"/blog/2015/10/30/sense-2-0-0-beta1-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：The Story of Sense - Announcing Sense 2.0.0-beta1 誕生 よくある良いプロジェクト同様、Senseもビールを飲みながら考","tags":["elasticsearch","sense"],"title":"Senseの歴史 - Sense 2.0.0-beta1の紹介(日本語訳)","type":"post","url":"/blog/2015/10/30/sense-2-0-0-beta1-ja/","weight":0,"wordcount":3643},{"date":1446189691,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":3200,"kind":"page","lang":"ja","lastmod":1446189691,"objectID":"15700442e957951307bbcec5fff8643d","permalink":"https://blog.johtani.info/blog/2015/10/30/shield-watcher-and-marvel-2-0-ga-released-ja/","publishdate":"2015-10-30T16:21:31+09:00","readingtime":7,"relpermalink":"/blog/2015/10/30/shield-watcher-and-marvel-2-0-ga-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Shield, Watcher, and Marvel 2.0.0 GA Released 本日（10/28）Shield、WatcherおよびMarv","tags":["elasticsearch","shield","watcher","marvel"],"title":"Shield、Watcher、Marvel 2.0.0 GAリリース（日本語訳）","type":"post","url":"/blog/2015/10/30/shield-watcher-and-marvel-2-0-ga-released-ja/","weight":0,"wordcount":3122},{"date":1446103243,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":3500,"kind":"page","lang":"ja","lastmod":1446103243,"objectID":"018e32a8010960eb17e368a6fdd5a51b","permalink":"https://blog.johtani.info/blog/2015/10/29/elasticsearch-2-0-0-released-ja/","publishdate":"2015-10-29T16:20:43+09:00","readingtime":7,"relpermalink":"/blog/2015/10/29/elasticsearch-2-0-0-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0 GA released Elasticsearch 1.0.0のリリース以降、 477のコミッター2,79","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0リリース(日本語訳)","type":"post","url":"/blog/2015/10/29/elasticsearch-2-0-0-released-ja/","weight":0,"wordcount":3449},{"date":1446103219,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1446103219,"objectID":"e159a35d1b9a46e03072a3d54780edcb","permalink":"https://blog.johtani.info/blog/2015/10/29/kibana-4-2-0-ja/","publishdate":"2015-10-29T16:20:19+09:00","readingtime":3,"relpermalink":"/blog/2015/10/29/kibana-4-2-0-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Kibana 4.2.0 released Elasticsearch 2.0 + Kibana 4.2 = 💚 Elasticsearch 2.0サポートのKibanaの最初のリリースです。 これ","tags":["elastic","kibana"],"title":"Kibana 4.2.0リリース（日本語訳）","type":"post","url":"/blog/2015/10/29/kibana-4-2-0-ja/","weight":0,"wordcount":1079},{"date":1446103197,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1446103197,"objectID":"cc64c2fcdecdb505b3797e1aaaa59adc","permalink":"https://blog.johtani.info/blog/2015/10/29/logstash-2-0-0-released-ja/","publishdate":"2015-10-29T16:19:57+09:00","readingtime":5,"relpermalink":"/blog/2015/10/29/logstash-2-0-0-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Logstash 2.0.0 released Logstash 2.0.0が本日（10/28）リリースされました。 このリリースは","tags":["elastic","logstash"],"title":"Logstash 2.0.0リリース（日本語訳）","type":"post","url":"/blog/2015/10/29/logstash-2-0-0-released-ja/","weight":0,"wordcount":2478},{"date":1446095939,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1446095939,"objectID":"4cc08ca51ecf0f963035f039de6194c5","permalink":"https://blog.johtani.info/blog/2015/10/29/release-we-have-ja/","publishdate":"2015-10-29T14:18:59+09:00","readingtime":4,"relpermalink":"/blog/2015/10/29/release-we-have-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Relase, we have ※画像に関しては原文をご覧ください。 Elasticにとって大きな1日","tags":["elasticsearch","kibana","logstash"],"title":"Release, we have（日本語訳）","type":"post","url":"/blog/2015/10/29/release-we-have-ja/","weight":0,"wordcount":1542},{"date":1442565101,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1442565101,"objectID":"4b227d61f33182579cd3edd0ac6c7c44","permalink":"https://blog.johtani.info/blog/2015/09/18/elasticsearch-2-0-0-beta2-released-ja/","publishdate":"2015-09-18T17:31:41+09:00","readingtime":4,"relpermalink":"/blog/2015/09/18/elasticsearch-2-0-0-beta2-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0-beta2 released 本日（9/17）、Lucene 5.2.1ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0-beta2リリース（日本語訳）","type":"post","url":"/blog/2015/09/18/elasticsearch-2-0-0-beta2-released-ja/","weight":0,"wordcount":1932},{"date":1440730890,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1440730890,"objectID":"0de0edbf2a506143c1739b12e94c0ef9","permalink":"https://blog.johtani.info/blog/2015/08/28/elasticsearch-unplugged-ja/","publishdate":"2015-08-28T12:01:30+09:00","readingtime":4,"relpermalink":"/blog/2015/08/28/elasticsearch-unplugged-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch unplugged - Networking changes in 2.0 Elasticsearchをローカルのマシンで起","tags":["elasticsearch"],"title":"Elasticsearch unplugged - 2.0におけるネットワークの変更(日本語訳)","type":"post","url":"/blog/2015/08/28/elasticsearch-unplugged-ja/","weight":0,"wordcount":1904},{"date":1440638952,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1440638952,"objectID":"744554499cb7880086fbd9b1f080e7e1","permalink":"https://blog.johtani.info/blog/2015/08/27/elasticsearch-2-0-0-beta1-released-ja/","publishdate":"2015-08-27T10:29:12+09:00","readingtime":4,"relpermalink":"/blog/2015/08/27/elasticsearch-2-0-0-beta1-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0-beta1 released 本日（8/26）、Lucene 5.2.1ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0-beta1リリース（日本語訳）","type":"post","url":"/blog/2015/08/27/elasticsearch-2-0-0-beta1-released-ja/","weight":0,"wordcount":1935},{"date":1440044644,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1440044644,"objectID":"5a9e950f4ac186925e5de978c5f72062","permalink":"https://blog.johtani.info/blog/2015/08/20/core-delete-by-query-is-a-plugin-ja/","publishdate":"2015-08-20T13:24:04+09:00","readingtime":3,"relpermalink":"/blog/2015/08/20/core-delete-by-query-is-a-plugin-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：The Delete by Query API Is now a plugin Elasticsearchの2.0.0-beta1では、これまで","tags":["elasticsearch"],"title":"Delete by Query APIはプラグインへ（日本語訳）","type":"post","url":"/blog/2015/08/20/core-delete-by-query-is-a-plugin-ja/","weight":0,"wordcount":1468},{"date":1438321313,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2200,"kind":"page","lang":"ja","lastmod":1438321313,"objectID":"73b8194ad8fce0cabb01cd21d5e18500","permalink":"https://blog.johtani.info/blog/2015/07/31/11th-elasticsearch-jp/","publishdate":"2015-07-31T14:41:53+09:00","readingtime":5,"relpermalink":"/blog/2015/07/31/11th-elasticsearch-jp/","section":"post","summary":"第11回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第11回Elasticsearch勉強会を開催しました。#elasticsearchjp","type":"post","url":"/blog/2015/07/31/11th-elasticsearch-jp/","weight":0,"wordcount":2119},{"date":1438173353,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1438173353,"objectID":"100c0a69bea7f02a0f4540ecaa37d0e3","permalink":"https://blog.johtani.info/blog/2015/07/29/elasticsearch-1-7-1-and-1-6-2-released-ja/","publishdate":"2015-07-29T21:35:53+09:00","readingtime":2,"relpermalink":"/blog/2015/07/29/elasticsearch-1-7-1-and-1-6-2-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.1 and 1.6.2 released 本日（7/29）、Lucene 4.10.4ベースのE","tags":["elasticsearch"],"title":"Elasticsearch 1.7.1 および 1.6.2リリース（日本語訳）","type":"post","url":"/blog/2015/07/29/elasticsearch-1-7-1-and-1-6-2-released-ja/","weight":0,"wordcount":601},{"date":1437546817,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1437546817,"objectID":"809925e891b0456231c374b09cbe4a90","permalink":"https://blog.johtani.info/blog/2015/07/22/elasticsearch-1-7-0-and-1-6-1-released-ja/","publishdate":"2015-07-22T15:33:37+09:00","readingtime":6,"relpermalink":"/blog/2015/07/22/elasticsearch-1-7-0-and-1-6-1-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.0 and 1.6.1 released 本日（7/16）、Lucene 4.10.4ベースのE","tags":["elasticsearch"],"title":"Elasticsearch 1.7.0 および 1.6.1リリース（日本語訳）","type":"post","url":"/blog/2015/07/22/elasticsearch-1-7-0-and-1-6-1-released-ja/","weight":0,"wordcount":2518},{"date":1437010857,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1437010857,"objectID":"dd6c32a722dc815273cd9ed8cd6c671b","permalink":"https://blog.johtani.info/blog/2015/07/16/kansai-1st-elasticsearch-jp/","publishdate":"2015-07-16T10:40:57+09:00","readingtime":4,"relpermalink":"/blog/2015/07/16/kansai-1st-elasticsearch-jp/","section":"post","summary":"東京以外での勉強会の第2弾として、関西で勉強会を開催してきました。 Elasticsearch勉強会 in 大阪 Elasticsearch勉強会 in 京","tags":["勉強会","elasticsearch"],"title":"大阪と京都でElasticsearch勉強会を開催しました。 #elasticsearchjp","type":"post","url":"/blog/2015/07/16/kansai-1st-elasticsearch-jp/","weight":0,"wordcount":1960},{"date":1436346691,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":6700,"kind":"page","lang":"ja","lastmod":1436346691,"objectID":"ee4ff9e4e8a1948795e26af2f3f8a30f","permalink":"https://blog.johtani.info/blog/2015/07/08/great-mapping-refactoring-ja/","publishdate":"2015-07-08T18:11:31+09:00","readingtime":14,"relpermalink":"/blog/2015/07/08/great-mapping-refactoring-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：The Great Mapping Refactoring Elasticsearchのユーザの悩みの最も大きなものの一つは、 タイプと","tags":["elasticsearch"],"title":"Mappingのすばらしいリファクタリング（日本語訳）","type":"post","url":"/blog/2015/07/08/great-mapping-refactoring-ja/","weight":0,"wordcount":6652},{"date":1436250300,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1436250300,"objectID":"f887e1aabf801e351bfb39698f208af1","permalink":"https://blog.johtani.info/blog/2015/07/07/elasticsearch-2-dot-0-0-dot-beta1-coming-soon-ja/","publishdate":"2015-07-07T15:25:00+09:00","readingtime":6,"relpermalink":"/blog/2015/07/07/elasticsearch-2-dot-0-0-dot-beta1-coming-soon-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0.beta1 coming soon! Elasticsearch 2.0.0.beta1のリリースの準備をしています。","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0.beta1リリース間近（日本語訳）","type":"post","url":"/blog/2015/07/07/elasticsearch-2-dot-0-0-dot-beta1-coming-soon-ja/","weight":0,"wordcount":2676},{"date":1436250000,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1436250000,"objectID":"9cc2a0b6c8be1405cddcdeb4487c59fe","permalink":"https://blog.johtani.info/blog/2015/07/07/we-just-made-found-more-awesome-ja/","publishdate":"2015-07-07T15:20:00+09:00","readingtime":3,"relpermalink":"/blog/2015/07/07/we-just-made-found-more-awesome-ja/","section":"post","summary":"4ヶ月前に、Found joined our team at Elasticをアナウンスしました。 Foundの素晴らしいチームと一緒に仕事をしていますが、彼らによって、より","tags":["elasticsearch","found.no"],"title":"さらに進化したFound（日本語訳）","type":"post","url":"/blog/2015/07/07/we-just-made-found-more-awesome-ja/","weight":0,"wordcount":1451},{"date":1436147341,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1200,"kind":"page","lang":"ja","lastmod":1436147341,"objectID":"18b7998a871950ebc36c415a53630477","permalink":"https://blog.johtani.info/blog/2015/07/06/attend-justsystem-techtalk-no2/","publishdate":"2015-07-06T10:49:01+09:00","readingtime":3,"relpermalink":"/blog/2015/07/06/attend-justsystem-techtalk-no2/","section":"post","summary":"JustTechTalk#02 形態素解析のあれやこれや@ジャストシステム に参加してきました。 ジャストシステムさんの形態素解析器JMATの話とKagome、Janome、","tags":["勉強会"],"title":"JustTechTalk#02 形態素解析のあれやこれや@ジャストシステムに参加しました。","type":"post","url":"/blog/2015/07/06/attend-justsystem-techtalk-no2/","weight":0,"wordcount":1164},{"date":1434468093,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1434468093,"objectID":"ddab6357ff522c0c956ebd7669e83454","permalink":"https://blog.johtani.info/blog/2015/06/17/attend-hatena-engineer-seminar-5/","publishdate":"2015-06-17T00:21:33+09:00","readingtime":3,"relpermalink":"/blog/2015/06/17/attend-hatena-engineer-seminar-5/","section":"post","summary":"ひさびさに、勉強会メモ。 Hatena Engineer Seminar #5 @ Tokyoに当選したので行ってきました。 いつもは近寄らないオシャレな街をドキドキしながら行ってきました。 と","tags":["勉強会"],"title":"Hatena Engineer Seminar #5 @ Tokyoに参加しました。 #hatenatech","type":"post","url":"/blog/2015/06/17/attend-hatena-engineer-seminar-5/","weight":0,"wordcount":1294},{"date":1433910662,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":4700,"kind":"page","lang":"ja","lastmod":1433910662,"objectID":"55188a318c5998989255253e15ccc1f6","permalink":"https://blog.johtani.info/blog/2015/06/10/elasticsearch-1-6-0-released-ja/","publishdate":"2015-06-10T13:31:02+09:00","readingtime":10,"relpermalink":"/blog/2015/06/10/elasticsearch-1-6-0-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.6.0 released 本日（6/9）、Lucene 4.10.4ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 1.6.0リリース（日本語訳）","type":"post","url":"/blog/2015/06/10/elasticsearch-1-6-0-released-ja/","weight":0,"wordcount":4693},{"date":1433225196,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":3000,"kind":"page","lang":"ja","lastmod":1433225196,"objectID":"75d9268739fe7787ac02d389ac605feb","permalink":"https://blog.johtani.info/blog/2015/06/02/10th-elasticsearch-jp/","publishdate":"2015-06-02T15:06:36+09:00","readingtime":6,"relpermalink":"/blog/2015/06/02/10th-elasticsearch-jp/","section":"post","summary":"第10回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさ","tags":["elasticsearch","勉強会"],"title":"第10回Elasticsearch勉強会を開催しました。#elasticsearchjp","type":"post","url":"/blog/2015/06/02/10th-elasticsearch-jp/","weight":0,"wordcount":2943},{"date":1432624090,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1900,"kind":"page","lang":"ja","lastmod":1432624090,"objectID":"23a22d1411afb787810d68210e6fad4f","permalink":"https://blog.johtani.info/blog/2015/05/26/reindex-elasticsearch-with-logstash-ja/","publishdate":"2015-05-26T16:08:10+09:00","readingtime":4,"relpermalink":"/blog/2015/05/26/reindex-elasticsearch-with-logstash-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Reindex Elasticsearch With Logstash Thanks David! マッピングを変更したり、インデックスの設定を変更したり、あるサ","tags":["logstash","elasticsearch"],"title":"Logstashを使ったElasticsearchの再インデックス（日本語訳）","type":"post","url":"/blog/2015/05/26/reindex-elasticsearch-with-logstash-ja/","weight":0,"wordcount":1844},{"date":1432197903,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1432197903,"objectID":"615db1a24f36d19a8eaf18d4dceed6b2","permalink":"https://blog.johtani.info/blog/2015/05/21/join-the-conversation-ja/","publishdate":"2015-05-21T17:45:03+09:00","readingtime":2,"relpermalink":"/blog/2015/05/21/join-the-conversation-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Join the Conversation: Discuss.Elastic.Co 3つのOSSプロジェクトの開発をスケールアップし始め、 コミュニティサポー","tags":null,"title":"discuss.elastic.co にぜひ参加を","type":"post","url":"/blog/2015/05/21/join-the-conversation-ja/","weight":0,"wordcount":723},{"date":1430201648,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1700,"kind":"page","lang":"ja","lastmod":1430201648,"objectID":"8d7caf84b3a51cca27291c1f7cfc2d40","permalink":"https://blog.johtani.info/blog/2015/04/28/elasticsearch-1-5-2-and-1-4-5-released-ja/","publishdate":"2015-04-28T15:14:08+09:00","readingtime":4,"relpermalink":"/blog/2015/04/28/elasticsearch-1-5-2-and-1-4-5-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.2 Released 本日（4/27）、Lucene 4.10.4ベースのEla","tags":["elasticsearch"],"title":"Elasticsearch 1.5.2 および 1.4.5リリース（日本語訳）","type":"post","url":"/blog/2015/04/28/elasticsearch-1-5-2-and-1-4-5-released-ja/","weight":0,"wordcount":1651},{"date":1429249314,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1429249314,"objectID":"7249710187cc2d983709e044dbc78d9d","permalink":"https://blog.johtani.info/blog/2015/04/17/9th-elasticsearch-jp/","publishdate":"2015-04-17T14:41:54+09:00","readingtime":3,"relpermalink":"/blog/2015/04/17/9th-elasticsearch-jp/","section":"post","summary":"第9回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第9回Elasticsearch勉強会を開催しました。#elasticsearchjp","type":"post","url":"/blog/2015/04/17/9th-elasticsearch-jp/","weight":0,"wordcount":1334},{"date":1428892471,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1428892471,"objectID":"563864a949924c505985a168191dcb84","permalink":"https://blog.johtani.info/blog/2015/04/13/elasticsearch-1-5-1-released-ja/","publishdate":"2015-04-13T11:34:31+09:00","readingtime":2,"relpermalink":"/blog/2015/04/13/elasticsearch-1-5-1-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.1 Released 本日（4/9）、Lucene 4.10.4ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 1.5.1リリース（日本語訳）","type":"post","url":"/blog/2015/04/13/elasticsearch-1-5-1-released-ja/","weight":0,"wordcount":828},{"date":1428108439,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1428108439,"objectID":"24357fe145c869ec82fdfc8134a1a6d1","permalink":"https://blog.johtani.info/blog/2015/04/04/elasticsearch-study-session-at-nagoya/","publishdate":"2015-04-04T09:47:19+09:00","readingtime":4,"relpermalink":"/blog/2015/04/04/elasticsearch-study-session-at-nagoya/","section":"post","summary":"Elasticsearch勉強会 in 名古屋を開催しました。 初の東京以外での勉強会です。 企画、セッションなどお手伝いいただいた@smogamiさ","tags":["elasticsearch","勉強会"],"title":"Elasticsearch勉強会 in 名古屋を開催しました。#elasticsearch #elasticsearchjp","type":"post","url":"/blog/2015/04/04/elasticsearch-study-session-at-nagoya/","weight":0,"wordcount":1527},{"date":1427859496,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":3000,"kind":"page","lang":"ja","lastmod":1427859496,"objectID":"19ecbaa5e12f7a9ebcff703c79534a52","permalink":"https://blog.johtani.info/blog/2015/04/01/elasticsearch-1-5-0-released-ja/","publishdate":"2015-04-01T12:38:16+09:00","readingtime":6,"relpermalink":"/blog/2015/04/01/elasticsearch-1-5-0-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.0 Released 本日（3/23）、Lucene 4.10.4ベースのEla","tags":["elasticsearch"],"title":"Elasticsearch 1.5.0リリース（日本語訳）","type":"post","url":"/blog/2015/04/01/elasticsearch-1-5-0-released-ja/","weight":0,"wordcount":2965},{"date":1426059991,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1426059991,"objectID":"ced9df0d8c8ed14de91c509b31b4c4ae","permalink":"https://blog.johtani.info/blog/2015/03/11/attend-elasticon/","publishdate":"2015-03-11T16:46:31+09:00","readingtime":2,"relpermalink":"/blog/2015/03/11/attend-elasticon/","section":"post","summary":"サンフランシスコからこんにちは。 今、私は、弊社初のユーザカンファレンスelastic{ON}に 参加するために、初のアメリカ出張中です。 初のユ","tags":["elastic","elasticon"],"title":"#elasticon に参加中","type":"post","url":"/blog/2015/03/11/attend-elasticon/","weight":0,"wordcount":806},{"date":1425030596,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":7100,"kind":"page","lang":"ja","lastmod":1425030596,"objectID":"cb13b64d0127c13bb466c4d4677a7b8a","permalink":"https://blog.johtani.info/blog/2015/02/27/you-know-for-security-shield-goes-ga-ja/","publishdate":"2015-02-27T18:49:56+09:00","readingtime":15,"relpermalink":"/blog/2015/02/27/you-know-for-security-shield-goes-ga-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：you know, for security: shield goes ga 1/27にShield 1.0 をリリースしました。 Elasticsearc","tags":["elasticsearch","shield"],"title":"セキュリティ向けプラグインShieldのリリース（日本語訳）","type":"post","url":"/blog/2015/02/27/you-know-for-security-shield-goes-ga-ja/","weight":0,"wordcount":7044},{"date":1425024629,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":300,"kind":"page","lang":"ja","lastmod":1425024629,"objectID":"f2cbe07bf2ff16d5a5860b4d6edbc5e8","permalink":"https://blog.johtani.info/blog/2015/02/27/2nd-tokyo-training/","publishdate":"2015-02-27T17:10:29+09:00","readingtime":1,"relpermalink":"/blog/2015/02/27/2nd-tokyo-training/","section":"post","summary":"4月13日から3日間、ElasticsearchのCoreトレーニングが東京で開催されます。 Early Birdということで、3/14までに申し込みす","tags":["elasticsearch"],"title":"Elasticsearch Coreトレーニング開催","type":"post","url":"/blog/2015/02/27/2nd-tokyo-training/","weight":0,"wordcount":251},{"date":1424408752,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1424408752,"objectID":"eee039f49a5b570599cf459c55c649f3","permalink":"https://blog.johtani.info/blog/2015/02/20/kibana-4-literally-ja/","publishdate":"2015-02-20T14:05:52+09:00","readingtime":5,"relpermalink":"/blog/2015/02/20/kibana-4-literally-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：kibana 4. literally. Kibana 4は現在、文字通り、抽象的に、概念的に、精神的に、そしてとても楽しく","tags":["elasticsearch","kibana4"],"title":"Kibana 4（日本語訳）","type":"post","url":"/blog/2015/02/20/kibana-4-literally-ja/","weight":0,"wordcount":2342},{"date":1424408734,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1424408734,"objectID":"ddd3e6f6e298d3884abc4d888a043664","permalink":"https://blog.johtani.info/blog/2015/02/20/elasticsearch-1-4-4-and-1-3-9-released-ja/","publishdate":"2015-02-20T14:05:34+09:00","readingtime":2,"relpermalink":"/blog/2015/02/20/elasticsearch-1-4-4-and-1-3-9-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.4 and 1.3.9 released 本日（2/20）、Elasticsearch 1.4.","tags":["elasticsearch"],"title":"Elasticsearch 1.4.4および1.3.9リリース（日本語訳）","type":"post","url":"/blog/2015/02/20/elasticsearch-1-4-4-and-1-3-9-released-ja/","weight":0,"wordcount":618},{"date":1424240573,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":500,"kind":"page","lang":"ja","lastmod":1424240573,"objectID":"5b97ead91c0dd0bad57b4f43a89149a2","permalink":"https://blog.johtani.info/blog/2015/02/18/preparing-elasticsearch-meetup-in-nagoya/","publishdate":"2015-02-18T15:22:53+09:00","readingtime":1,"relpermalink":"/blog/2015/02/18/preparing-elasticsearch-meetup-in-nagoya/","section":"post","summary":"来る、4月4日の土曜日の午後に名古屋でElasticsearch勉強会を開催予定です。 「初」の東京以外の勉強会です。 Twitterでこのよう","tags":["elasticsearch","勉強会"],"title":"名古屋でElasticsearch勉強会を開催します","type":"post","url":"/blog/2015/02/18/preparing-elasticsearch-meetup-in-nagoya/","weight":0,"wordcount":477},{"date":1424066543,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2200,"kind":"page","lang":"ja","lastmod":1424066543,"objectID":"997acc135d01b54f7de77a432fb9133f","permalink":"https://blog.johtani.info/blog/2015/02/16/8th-elasticsearch-jp/","publishdate":"2015-02-16T15:02:23+09:00","readingtime":5,"relpermalink":"/blog/2015/02/16/8th-elasticsearch-jp/","section":"post","summary":"第8回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第8回Elasticsearch勉強会を開催しました。#elasticsearchjp","type":"post","url":"/blog/2015/02/16/8th-elasticsearch-jp/","weight":0,"wordcount":2116},{"date":1423721589,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1423721589,"objectID":"1fed22e99b0e11a50eb7b92cb1644e8a","permalink":"https://blog.johtani.info/blog/2015/02/12/running-groovy-scripts-without-dynamic-scripting-ja/","publishdate":"2015-02-12T15:13:09+09:00","readingtime":6,"relpermalink":"/blog/2015/02/12/running-groovy-scripts-without-dynamic-scripting-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：running groovy scripts without dynamic scripting Elasticsearch1.3.8と1.4.3のリリースによ","tags":["elasticsearch"],"title":"Groovyスクリプトをダイナミックスクリプトなしで実行(日本語訳)","type":"post","url":"/blog/2015/02/12/running-groovy-scripts-without-dynamic-scripting-ja/","weight":0,"wordcount":2744},{"date":1423712393,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1423712393,"objectID":"5badf61ecb9cfadd7d6af58712fa5f6f","permalink":"https://blog.johtani.info/blog/2015/02/12/elasticsearch-1-4-3-and-1-3-8-released-ja/","publishdate":"2015-02-12T12:39:53+09:00","readingtime":4,"relpermalink":"/blog/2015/02/12/elasticsearch-1-4-3-and-1-3-8-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElas","tags":["elasticsearch"],"title":"Elasticsearch　1.4.3および1.3.8リリース（日本語訳）","type":"post","url":"/blog/2015/02/12/elasticsearch-1-4-3-and-1-3-8-released-ja/","weight":0,"wordcount":1576},{"date":1422500368,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1422500368,"objectID":"fe6ba10cc6c9509b4b22e9d59e029775","permalink":"https://blog.johtani.info/blog/2015/01/29/talk-at-cross2015/","publishdate":"2015-01-29T11:59:28+09:00","readingtime":3,"relpermalink":"/blog/2015/01/29/talk-at-cross2015/","section":"post","summary":"今年もCROSS参加しました。そして、話もしてきました。 今年は横浜の大さん橋でした。横浜はあんまりこないので、乗り換えでおたおたしてしまいま","tags":["勉強会","elasticsearch"],"title":"CROSS 2015で話をしてきました #cross2015","type":"post","url":"/blog/2015/01/29/talk-at-cross2015/","weight":0,"wordcount":1309},{"date":1420026086,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1420026086,"objectID":"b36abffbe5d6a0de73a9968604a1a3f9","permalink":"https://blog.johtani.info/blog/2014/12/31/looking-back-2014/","publishdate":"2014-12-31T20:41:26+09:00","readingtime":4,"relpermalink":"/blog/2014/12/31/looking-back-2014/","section":"post","summary":"今年は大晦日になってしまいました。しかも、ちょっと飲んでたり。。。 第9流しながら書いてます。 振り返り(2013年に書いた抱負から) まずは昨年","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2014）","type":"post","url":"/blog/2014/12/31/looking-back-2014/","weight":0,"wordcount":1722},{"date":1419490380,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1900,"kind":"page","lang":"ja","lastmod":1419490380,"objectID":"cb9649eca3dfbd356527ffc88f1dcb94","permalink":"https://blog.johtani.info/blog/2014/12/25/pickup-elasticsearch-2-0-0-labels/","publishdate":"2014-12-25T15:53:00+09:00","readingtime":4,"relpermalink":"/blog/2014/12/25/pickup-elasticsearch-2-0-0-labels/","section":"post","summary":"この記事はElasticsearch Advent Calndar 2014の25日目のエントリです。 あっという間に最終日です。来年につなげるという意味で、Elasti","tags":["elasticsearch"],"title":"Elasticsearch 2.0系のIssueの紹介","type":"post","url":"/blog/2014/12/25/pickup-elasticsearch-2-0-0-labels/","weight":0,"wordcount":1842},{"date":1418890008,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1700,"kind":"page","lang":"ja","lastmod":1418890008,"objectID":"7dea465ad52758b10cbceb08c81d1760","permalink":"https://blog.johtani.info/blog/2014/12/18/marvel-1-3-0-released-ja/","publishdate":"2014-12-18T17:06:48+09:00","readingtime":4,"relpermalink":"/blog/2014/12/18/marvel-1-3-0-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：marvel 1.3.0 released 12/17に、Elasticsearch Marvel 1.3.0をリリースしました","tags":["elasticsearch","marvel"],"title":"Marvel 1.3.0リリース（日本語訳）","type":"post","url":"/blog/2014/12/18/marvel-1-3-0-released-ja/","weight":0,"wordcount":1689},{"date":1418880374,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1418880374,"objectID":"bce2fa6458f39a75e2713f3d687271a1","permalink":"https://blog.johtani.info/blog/2014/12/18/elasticsearch-1-4-2-released-ja/","publishdate":"2014-12-18T14:26:14+09:00","readingtime":2,"relpermalink":"/blog/2014/12/18/elasticsearch-1-4-2-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElas","tags":["elasticsearch"],"title":"Elasticsearch 1.4.2および1.3.7リリース（日本語訳）","type":"post","url":"/blog/2014/12/18/elasticsearch-1-4-2-released-ja/","weight":0,"wordcount":987},{"date":1418809314,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1418809314,"objectID":"e5390751969ab21df280b7591854b89f","permalink":"https://blog.johtani.info/blog/2014/12/17/jjug-night-seminar-dec-2014/","publishdate":"2014-12-17T18:41:54+09:00","readingtime":4,"relpermalink":"/blog/2014/12/17/jjug-night-seminar-dec-2014/","section":"post","summary":"「【東京】JJUG ナイト・セミナー「機械学習・自然言語処理特集！」12/17（水）開催」でLuceneの話をしてきました。 本当にごく簡単な入","tags":["elasticsearch","jjug"],"title":"JJUG ナイトセミナーでLuceneの簡単な紹介をしてきました。#JJUG","type":"post","url":"/blog/2014/12/17/jjug-night-seminar-dec-2014/","weight":0,"wordcount":1741},{"date":1418698892,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":400,"kind":"page","lang":"ja","lastmod":1418698892,"objectID":"05330c3703d0e2c96cfe657ab33f130c","permalink":"https://blog.johtani.info/blog/2014/12/16/a-coffee-break/","publishdate":"2014-12-16T12:01:32+09:00","readingtime":1,"relpermalink":"/blog/2014/12/16/a-coffee-break/","section":"post","summary":"たまには、他愛のないブログを。 仕事しながら、コーヒーを飲んでます。 最近は、サムライズムさんのオフィスに入り浸って仕事してます。 オフィスには、","tags":["misc","coffee"],"title":"コーヒーブレイク","type":"post","url":"/blog/2014/12/16/a-coffee-break/","weight":0,"wordcount":348},{"date":1418486440,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":4300,"kind":"page","lang":"ja","lastmod":1418486440,"objectID":"4a3c42c9c5ac29db268010bbebf4f579","permalink":"https://blog.johtani.info/blog/2014/12/14/plugin-ecosystem-changes/","publishdate":"2014-12-14T01:00:40+09:00","readingtime":9,"relpermalink":"/blog/2014/12/14/plugin-ecosystem-changes/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：exciting logstash plugin ecosystem changes Logstash 1.5.0 Beta 1(お試しはこちら)のリリースで、 プラグインのインストー","tags":["logstash"],"title":"Logstashプラグインのエコシステムの変更（日本語訳）","type":"post","url":"/blog/2014/12/14/plugin-ecosystem-changes/","weight":0,"wordcount":4229},{"date":1418372246,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":3800,"kind":"page","lang":"ja","lastmod":1418372246,"objectID":"1bc36080b2493aab78c26e4f2152542c","permalink":"https://blog.johtani.info/blog/2014/12/12/logstash-1-5-0-beta1-released-ja/","publishdate":"2014-12-12T17:17:26+09:00","readingtime":8,"relpermalink":"/blog/2014/12/12/logstash-1-5-0-beta1-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：logstash 1.5.0.beta1 released Logstash 1.5.0 Beta1をリリースしました。こちらのページからダウンロードで","tags":["logstash"],"title":"Logstash 1.5.0 Beta1リリース(日本語訳)","type":"post","url":"/blog/2014/12/12/logstash-1-5-0-beta1-released-ja/","weight":0,"wordcount":3756},{"date":1417424748,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":3700,"kind":"page","lang":"ja","lastmod":1417424748,"objectID":"2de582c67fca31500621ecd6d3917a07","permalink":"https://blog.johtani.info/blog/2014/12/01/about-elasticsearch-in-2014/","publishdate":"2014-12-01T18:05:48+09:00","readingtime":8,"relpermalink":"/blog/2014/12/01/about-elasticsearch-in-2014/","section":"post","summary":"早いもので、師走です。今年もあと少しとなりました。ということで、Advent Calendarの季節が始まりました。 この記事はElastics","tags":["elasticsearch"],"title":"2014年のElasticsearch","type":"post","url":"/blog/2014/12/01/about-elasticsearch-in-2014/","weight":0,"wordcount":3655},{"date":1417056212,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1417056212,"objectID":"0a8183ced0e9e3e895b41286e54e8e4d","permalink":"https://blog.johtani.info/blog/2014/11/27/elasticsearch-1-4-1-released-ja/","publishdate":"2014-11-27T11:43:32+09:00","readingtime":4,"relpermalink":"/blog/2014/11/27/elasticsearch-1-4-1-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.1 and 1.3.6 released 本日、Lucene 4.10.2をベースにしたElas","tags":["elasticsearch"],"title":"Elasticsearch 1.4.1および1.3.6リリース（日本語訳）","type":"post","url":"/blog/2014/11/27/elasticsearch-1-4-1-released-ja/","weight":0,"wordcount":1718},{"date":1416900346,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":3200,"kind":"page","lang":"ja","lastmod":1416900346,"objectID":"4d8f5e581eee602c7fd21da8eb68df9a","permalink":"https://blog.johtani.info/blog/2014/11/25/import-apache-accesslog-using-logstash-2/","publishdate":"2014-11-25T16:25:46+09:00","readingtime":7,"relpermalink":"/blog/2014/11/25/import-apache-accesslog-using-logstash-2/","section":"post","summary":"前回の「Logstashを利用したApacheアクセスログのインポート」の続きです。 前回の記事では、Logstashの設定ファイルについて説","tags":["logstash","kibana","elasticsearch"],"title":"インデックステンプレートとLogstash","type":"post","url":"/blog/2014/11/25/import-apache-accesslog-using-logstash-2/","weight":0,"wordcount":3101},{"date":1416558639,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":4400,"kind":"page","lang":"ja","lastmod":1416558639,"objectID":"937a597a8b399fd32caba88a3c1c7bc4","permalink":"https://blog.johtani.info/blog/2014/11/21/import-apache-accesslog-using-logstash/","publishdate":"2014-11-21T17:30:39+09:00","readingtime":9,"relpermalink":"/blog/2014/11/21/import-apache-accesslog-using-logstash/","section":"post","summary":"JJUG CCCや第7回Elasticsearch勉強会のKibana4のデモにアクセスログを利用しました。 ただ、セッションでは、どうやってElas","tags":["logstash","kibana","elasticsearch"],"title":"Logstashを利用したApacheアクセスログのインポート","type":"post","url":"/blog/2014/11/21/import-apache-accesslog-using-logstash/","weight":0,"wordcount":4322},{"date":1416363547,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1416363547,"objectID":"2a8412aa50d07330f1298f0243fa79d3","permalink":"https://blog.johtani.info/blog/2014/11/19/hold-on-7th-elasticsearch-jp/","publishdate":"2014-11-19T11:19:07+09:00","readingtime":5,"relpermalink":"/blog/2014/11/19/hold-on-7th-elasticsearch-jp/","section":"post","summary":"第7回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第7回Elasticsearch勉強会を開催しました。#elasticsearchjp","type":"post","url":"/blog/2014/11/19/hold-on-7th-elasticsearch-jp/","weight":0,"wordcount":2466},{"date":1415205033,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1415205033,"objectID":"d266a2023c67b7a20c3bd01055b223bc","permalink":"https://blog.johtani.info/blog/2014/11/06/elasticsearch-1-4-0-ja/","publishdate":"2014-11-06T01:30:33+09:00","readingtime":4,"relpermalink":"/blog/2014/11/06/elasticsearch-1-4-0-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch-1.4.0 and 1.3.5 released 本日、Lucene 4.10.2をベースにし","tags":["elasticsearch"],"title":"Elasticsearch 1.4.0および1.3.5リリース（日本語訳）","type":"post","url":"/blog/2014/11/06/elasticsearch-1-4-0-ja/","weight":0,"wordcount":1902},{"date":1414402951,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1414402951,"objectID":"bc2709406a9bb19e8d83a78f81e36244","permalink":"https://blog.johtani.info/blog/2014/10/27/how-to-use-validate-api/","publishdate":"2014-10-27T18:42:31+09:00","readingtime":6,"relpermalink":"/blog/2014/10/27/how-to-use-validate-api/","section":"post","summary":"久しぶりに翻訳ではないブログを。書こうと思いながらかけてなかったので。。。 今回はvalidate APIの紹介です。 背景 Elasticsear","tags":["elasticsearch"],"title":"validate APIの利用","type":"post","url":"/blog/2014/10/27/how-to-use-validate-api/","weight":0,"wordcount":2576},{"date":1413354368,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1413354368,"objectID":"998eda745d07fd8608f251138384a0b9","permalink":"https://blog.johtani.info/blog/2014/10/15/versioning-of-sonatype/","publishdate":"2014-10-15T15:26:08+09:00","readingtime":2,"relpermalink":"/blog/2014/10/15/versioning-of-sonatype/","section":"post","summary":"Elasticsearch 1.4.0.Beta1がリリースされました。 個人でelasticsearch-extended-analyzeというプラグインを開発してま","tags":["Elasticsearch","plugin","sonatype"],"title":"Sonatypeのバージョン番号で困ったので","type":"post","url":"/blog/2014/10/15/versioning-of-sonatype/","weight":0,"wordcount":657},{"date":1412244840,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":5400,"kind":"page","lang":"ja","lastmod":1412244840,"objectID":"853cac0f2d1f90b7c986e7d1dcdbbfde","permalink":"https://blog.johtani.info/blog/2014/10/02/elasticsearch-1-4-0-beta-released-ja/","publishdate":"2014-10-02T19:14:00+09:00","readingtime":11,"relpermalink":"/blog/2014/10/02/elasticsearch-1-4-0-beta-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.0.beta1 released 本日、Lucene 4.10.1をベースにした、Elast","tags":["Elasticsearch"],"title":"elasticsearch 1.4.0.Beta1のリリース","type":"post","url":"/blog/2014/10/02/elasticsearch-1-4-0-beta-released-ja/","weight":0,"wordcount":5399},{"date":1410927720,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2100,"kind":"page","lang":"ja","lastmod":1410927720,"objectID":"4616fbea6a6dbc1074bc3f1016bbc73b","permalink":"https://blog.johtani.info/blog/2014/09/17/hold-on-6th-elasticsearch-jp/","publishdate":"2014-09-17T13:22:00+09:00","readingtime":4,"relpermalink":"/blog/2014/09/17/hold-on-6th-elasticsearch-jp/","section":"post","summary":"第6回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第6回Elasticsearch勉強会を開催しました。#elasticsearchjp","type":"post","url":"/blog/2014/09/17/hold-on-6th-elasticsearch-jp/","weight":0,"wordcount":2002},{"date":1410841260,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1410841260,"objectID":"f15702ae9e55bad42182cf18724d1863","permalink":"https://blog.johtani.info/blog/2014/09/16/book-publication-event/","publishdate":"2014-09-16T13:21:00+09:00","readingtime":2,"relpermalink":"/blog/2014/09/16/book-publication-event/","section":"post","summary":"先日2014年9月9日(火)に『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』 出版記念！執筆者が語る大講演会！で、 「elastics","tags":["勉強会","本"],"title":"elasticsearch.もうちょっと入門という話をしてきました #gihyo_efk","type":"post","url":"/blog/2014/09/16/book-publication-event/","weight":0,"wordcount":906},{"date":1410250260,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":7100,"kind":"page","lang":"ja","lastmod":1410250260,"objectID":"77d965afaebd7193badc746d52b4173f","permalink":"https://blog.johtani.info/blog/2014/09/09/performance-considerations-for-elasticsearch-indexing/","publishdate":"2014-09-09T17:11:00+09:00","readingtime":15,"relpermalink":"/blog/2014/09/09/performance-considerations-for-elasticsearch-indexing/","section":"post","summary":"Elasticsearchのインデキシングに関するパフォーマンス検討 原文：performance considerations for elasticsearch indexing Elasticsearchユーザは様","tags":["Elasticsearch"],"title":"Elasticsearchのインデキシングに関するパフォーマンス検討","type":"post","url":"/blog/2014/09/09/performance-considerations-for-elasticsearch-indexing/","weight":0,"wordcount":7072},{"date":1407156840,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1407156840,"objectID":"bdea71d64cdfcc405e65e750fe8d9b86","permalink":"https://blog.johtani.info/blog/2014/08/04/release-magazine-book-of-log-aggs-and-viz/","publishdate":"2014-08-04T21:54:00+09:00","readingtime":2,"relpermalink":"/blog/2014/08/04/release-magazine-book-of-log-aggs-and-viz/","section":"post","summary":"懲りずにまた、執筆してみました。みなさん「買って」から感想をいただけるとうれしいです！ 本書について 共著者の方々のブログが詳しいので、そちらを","tags":["elasticsearch","kibana","本"],"title":"サーバ/インフラエンジニア養成読本 ログ収集~可視化編 を手伝いました","type":"post","url":"/blog/2014/08/04/release-magazine-book-of-log-aggs-and-viz/","weight":0,"wordcount":803},{"date":1406874240,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1406874240,"objectID":"7cc605e721fdd1d2ccc16f5b6490e830","permalink":"https://blog.johtani.info/blog/2014/08/01/plugin-using-under-proxy-env/","publishdate":"2014-08-01T15:24:00+09:00","readingtime":3,"relpermalink":"/blog/2014/08/01/plugin-using-under-proxy-env/","section":"post","summary":"Proxy環境で働いている方も結構いると思います。 Twitter上で、Elasticsearchのpluginコマンドでプラグインがインスト","tags":["elasticsearch","plugin"],"title":"プロキシ環境でのpluginコマンドの実行","type":"post","url":"/blog/2014/08/01/plugin-using-under-proxy-env/","weight":0,"wordcount":1363},{"date":1406604120,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1406604120,"objectID":"fb1da4a6ed74705ad98bb60ad4badaf2","permalink":"https://blog.johtani.info/blog/2014/07/29/elasticsearch-1-3-1-release/","publishdate":"2014-07-29T12:22:00+09:00","readingtime":2,"relpermalink":"/blog/2014/07/29/elasticsearch-1-3-1-release/","section":"post","summary":"原文：Elasticsearch 1.3.1 Releasedを日本語に翻訳したものです。 バグフィックス版のElasticsearch 1.3.1をリリー","tags":["elasticsearch","release"],"title":"Elasticsearch 1.3.1 リリース（日本語訳）","type":"post","url":"/blog/2014/07/29/elasticsearch-1-3-1-release/","weight":0,"wordcount":742},{"date":1406524740,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":5600,"kind":"page","lang":"ja","lastmod":1406524740,"objectID":"0c1821d1069578551d0e3c7d9275f16b","permalink":"https://blog.johtani.info/blog/2014/07/28/curator-2-0-and-1-1/","publishdate":"2014-07-28T14:19:00+09:00","readingtime":11,"relpermalink":"/blog/2014/07/28/curator-2-0-and-1-1/","section":"post","summary":"Curatorの1.2.0がリリースされました。 前回のCuratorの記事が古くなってしまった（1.1.0からコマンドのI/Fが変更された）","tags":["elasticsearch","curator"],"title":"Curator 1.2および1.1について","type":"post","url":"/blog/2014/07/28/curator-2-0-and-1-1/","weight":0,"wordcount":5505},{"date":1405774320,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1405774320,"objectID":"e3e146469ed4318eaa2ffbca3510c054","permalink":"https://blog.johtani.info/blog/2014/07/19/hold-on-5th-elasticsearch-jp/","publishdate":"2014-07-19T21:52:00+09:00","readingtime":5,"relpermalink":"/blog/2014/07/19/hold-on-5th-elasticsearch-jp/","section":"post","summary":"第5回Elasticsearch勉強会を開催しました。 遅くなってしまいましたが、まとめてみました。 今回は、Elasticsearchに入って","tags":["elasticsearch","勉強会"],"title":"第5回Elasticsearch勉強会を開催しました。#elasticsearchjp","type":"post","url":"/blog/2014/07/19/hold-on-5th-elasticsearch-jp/","weight":0,"wordcount":2350},{"date":1404181800,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1404181800,"objectID":"21a8e6324e9330d4f8ebade604c62b6e","permalink":"https://blog.johtani.info/blog/2014/07/01/join-elasticsearch/","publishdate":"2014-07-01T11:30:00+09:00","readingtime":2,"relpermalink":"/blog/2014/07/01/join-elasticsearch/","section":"post","summary":"ということで、転職しました。 どーしてもやりたいことが出てきたので、無理を言って転職することにしてみました。 サムライズムではなく、Elasti","tags":["転職"],"title":"転職しました","type":"post","url":"/blog/2014/07/01/join-elasticsearch/","weight":0,"wordcount":745},{"date":1404137940,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":100,"kind":"page","lang":"ja","lastmod":1404137940,"objectID":"40abea0a87a64bd832a1fad69458b293","permalink":"https://blog.johtani.info/blog/2014/06/30/resignation/","publishdate":"2014-06-30T23:19:00+09:00","readingtime":1,"relpermalink":"/blog/2014/06/30/resignation/","section":"post","summary":"退職しました。 色々と書きたいんですが、時差ボケで頭痛いので、このくらいです。 余裕出たら書くかも。 ほしい物リストはこちら 新天地についてはまた明","tags":["転職"],"title":"退職しました","type":"post","url":"/blog/2014/06/30/resignation/","weight":0,"wordcount":72},{"date":1402908420,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1700,"kind":"page","lang":"ja","lastmod":1402908420,"objectID":"916bda59bc7621d5c1790c040572a3c0","permalink":"https://blog.johtani.info/blog/2014/06/16/first-impression-elasticsearch-server-2nd-edition/","publishdate":"2014-06-16T17:47:00+09:00","readingtime":4,"relpermalink":"/blog/2014/06/16/first-impression-elasticsearch-server-2nd-edition/","section":"post","summary":"Elasticsearch server 2nd editionが発売されています。 私が翻訳したのは前のバージョンですが。。。 まずは、目次を元にどのくらい変わってるかを見てみました。 （","tags":["elasticsearch","本"],"title":"Elasticsearch server 2nd editionのファーストインプレッション","type":"post","url":"/blog/2014/06/16/first-impression-elasticsearch-server-2nd-edition/","weight":0,"wordcount":1650},{"date":1401884100,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1401884100,"objectID":"5bb6f8322cdbda7a21e4aecbe04462b7","permalink":"https://blog.johtani.info/blog/2014/06/04/attending-visualize-study/","publishdate":"2014-06-04T21:15:00+09:00","readingtime":3,"relpermalink":"/blog/2014/06/04/attending-visualize-study/","section":"post","summary":"可視化ツール現状確認会に参加して、カジュアルウォーターじゃなくて可視化ツールの現状を確認してきました。 ということで、いつものメモです。 Mackerel と Graphite","tags":["勉強会"],"title":"可視化ツール現状確認会に参加してきました。#可視化","type":"post","url":"/blog/2014/06/04/attending-visualize-study/","weight":0,"wordcount":1082},{"date":1400840280,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1400840280,"objectID":"a578acf825a595ce95fe8f804b7208f0","permalink":"https://blog.johtani.info/blog/2014/05/23/attending-drecom-infra-study/","publishdate":"2014-05-23T19:18:00+09:00","readingtime":3,"relpermalink":"/blog/2014/05/23/attending-drecom-infra-study/","section":"post","summary":"今月2回目の目黒で、初のドリコムさんです。 「最新インフラエンジニア技術勉強～Fluentd, Elasticsearch,Chefの実践実例～","tags":["勉強会","elasticsearch"],"title":"最新インフラエンジニア技術勉強に参加しました。","type":"post","url":"/blog/2014/05/23/attending-drecom-infra-study/","weight":0,"wordcount":1274},{"date":1400143800,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1400143800,"objectID":"706c033b4483b6d062b66d6e4ea0236a","permalink":"https://blog.johtani.info/blog/2014/05/15/amazon-cloud-seaarch-study-session/","publishdate":"2014-05-15T17:50:00+09:00","readingtime":3,"relpermalink":"/blog/2014/05/15/amazon-cloud-seaarch-study-session/","section":"post","summary":"どうやら、中身がSolrベース？Luceneベース？になったらしいということで、 今日は「AWSプロダクトシリーズ｜よくわかるAmazon Cl","tags":["勉強会","CloudSearch","AWS"],"title":"「よくわかるAmazon #CloudSearch 」に行ってきました！","type":"post","url":"/blog/2014/05/15/amazon-cloud-seaarch-study-session/","weight":0,"wordcount":1448},{"date":1399999440,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1399999440,"objectID":"72df0bf7853e05560d94208817b83468","permalink":"https://blog.johtani.info/blog/2014/05/14/spiritual-entry1/","publishdate":"2014-05-14T01:44:00+09:00","readingtime":2,"relpermalink":"/blog/2014/05/14/spiritual-entry1/","section":"post","summary":"酔っ払ってなんとなく書きたくなったスピリチュアルなブログなので、流していただければと。 最近、勉強会やTwitterで知り合いになって話をする","tags":["スピリチュアル"],"title":"外の世界を知るということ","type":"post","url":"/blog/2014/05/14/spiritual-entry1/","weight":0,"wordcount":741},{"date":1399563900,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1399563900,"objectID":"91fe03f994e8e85cede4e3bd62f4d6b7","permalink":"https://blog.johtani.info/blog/2014/05/09/reading-agile-data-science/","publishdate":"2014-05-09T00:45:00+09:00","readingtime":4,"relpermalink":"/blog/2014/05/09/reading-agile-data-science/","section":"post","summary":"「アジャイルデータサイエンス」の見本をいただいてしまいました。 なので、感想文でも書いてみようかと。 どんな本？ 想像以上に薄かったです、物理的に","tags":["感想文","オライリー"],"title":"アジャイルデータサイエンスが届きました","type":"post","url":"/blog/2014/05/09/reading-agile-data-science/","weight":0,"wordcount":1549},{"date":1399456620,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1399456620,"objectID":"ed4f5a398056eef1cf6caa90786b340a","permalink":"https://blog.johtani.info/blog/2014/05/07/aggregation-example/","publishdate":"2014-05-07T18:57:00+09:00","readingtime":6,"relpermalink":"/blog/2014/05/07/aggregation-example/","section":"post","summary":"こんなツイートを見つけたので、Aggregationのサンプルでも書こうかなと。（前から書こうと思ってたんですが。。。） @elasticsearch Hi, Would you please tell me the way to","tags":["elasticsearch"],"title":"Aggregations - ファセットよりも柔軟な集計","type":"post","url":"/blog/2014/05/07/aggregation-example/","weight":0,"wordcount":2683},{"date":1399132860,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":600,"kind":"page","lang":"ja","lastmod":1399132860,"objectID":"2824bef72110575c78aeb979170212b8","permalink":"https://blog.johtani.info/blog/2014/05/04/intro-elasticsearch-kopf-alias-percolator/","publishdate":"2014-05-04T01:01:00+09:00","readingtime":2,"relpermalink":"/blog/2014/05/04/intro-elasticsearch-kopf-alias-percolator/","section":"post","summary":"今日はelasticsearch-kopfのAnalysis画面の紹介です。 （簡単なところから。。。その３） ちょっとあいだが開いてしまいまし","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（aliases画面）","type":"post","url":"/blog/2014/05/04/intro-elasticsearch-kopf-alias-percolator/","weight":0,"wordcount":503},{"date":1398341460,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2200,"kind":"page","lang":"ja","lastmod":1398341460,"objectID":"e396cbf9274b590a1d94ee43d823a0bd","permalink":"https://blog.johtani.info/blog/2014/04/24/usage-stream2es/","publishdate":"2014-04-24T21:11:00+09:00","readingtime":5,"relpermalink":"/blog/2014/04/24/usage-stream2es/","section":"post","summary":"kopfの記事の続きも書く必要があるんだけど、こんなツイートを見つけてしまったので。。。 ElasticsearchのBulk APIの仕様、J","tags":["elasticsearch","stream2es"],"title":"stream2esと複数データの登録","type":"post","url":"/blog/2014/04/24/usage-stream2es/","weight":0,"wordcount":2154},{"date":1398077040,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":3300,"kind":"page","lang":"ja","lastmod":1398077040,"objectID":"50562b09417cd8c4a2348a0a5aabe754","permalink":"https://blog.johtani.info/blog/2014/04/21/hold-on-4th-elasticsearch-jp/","publishdate":"2014-04-21T19:44:00+09:00","readingtime":7,"relpermalink":"/blog/2014/04/21/hold-on-4th-elasticsearch-jp/","section":"post","summary":"第4回Elsticsearch勉強会を開催しました。 今回から、遅刻厳禁にしてみました。 それほど困った人もいないと思うので、次回からも遅刻厳禁","tags":["elasticsearch","勉強会"],"title":"第4回Elasticsearch勉強会を開催しました。#elasticsearchjp","type":"post","url":"/blog/2014/04/21/hold-on-4th-elasticsearch-jp/","weight":0,"wordcount":3217},{"date":1397011260,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1397011260,"objectID":"76a1fb7f21fda9eddb95426b65124517","permalink":"https://blog.johtani.info/blog/2014/04/09/intro-elasticsearch-kopf-analysis/","publishdate":"2014-04-09T11:41:00+09:00","readingtime":2,"relpermalink":"/blog/2014/04/09/intro-elasticsearch-kopf-analysis/","section":"post","summary":"今日はelasticsearch-kopfのAnalysis画面の紹介です。 （簡単なところから。。。その２） メニューのanalysisを選択","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（analysis画面）","type":"post","url":"/blog/2014/04/09/intro-elasticsearch-kopf-analysis/","weight":0,"wordcount":944},{"date":1396866240,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1396866240,"objectID":"299abcee56b05b312ed5700f686f79b8","permalink":"https://blog.johtani.info/blog/2014/04/07/attend-jvm-casual-1/","publishdate":"2014-04-07T19:24:00+09:00","readingtime":5,"relpermalink":"/blog/2014/04/07/attend-jvm-casual-1/","section":"post","summary":"JVM Operation Casual Talksに参加しました。 あんまり、運用とかやってないので、ついていけるか不安ですが、楽しそうだったので。 懇親会は予定されてないらしい","tags":["JVM","Java","勉強会"],"title":"JVM Operation Casual Talksに参加しました #jvmcasual","type":"post","url":"/blog/2014/04/07/attend-jvm-casual-1/","weight":0,"wordcount":2447},{"date":1396837440,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1396837440,"objectID":"670744b945088de05866864f7d57bee7","permalink":"https://blog.johtani.info/blog/2014/04/07/intro-elasticsearch-kopf-rest/","publishdate":"2014-04-07T11:24:00+09:00","readingtime":2,"relpermalink":"/blog/2014/04/07/intro-elasticsearch-kopf-rest/","section":"post","summary":"今日はelasticsearch-kopfのREST画面の紹介です。 （簡単なところから。。。） メニューのrestを選択すると、次のような画面","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（rest画面）","type":"post","url":"/blog/2014/04/07/intro-elasticsearch-kopf-rest/","weight":0,"wordcount":937},{"date":1396707480,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1396707480,"objectID":"c1241374502f200cf9fc49c8d6fb5822","permalink":"https://blog.johtani.info/blog/2014/04/05/intro-elasticsearch-kopf-1/","publishdate":"2014-04-05T23:18:00+09:00","readingtime":3,"relpermalink":"/blog/2014/04/05/intro-elasticsearch-kopf-1/","section":"post","summary":"なんだか、ドタバタしてて久しぶりの更新です。 ベルリンの旅行記みたいなのも書きたいのですが、まずはこちらかと。 elasticsearch-ko","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（概要）","type":"post","url":"/blog/2014/04/05/intro-elasticsearch-kopf-1/","weight":0,"wordcount":1288},{"date":1395722580,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1395722580,"objectID":"d51032bef3e7117a94336fea18a3fad7","permalink":"https://blog.johtani.info/blog/2014/03/25/release-elasticsearch-server-ja-ebook/","publishdate":"2014-03-25T13:43:00+09:00","readingtime":2,"relpermalink":"/blog/2014/03/25/release-elasticsearch-server-ja-ebook/","section":"post","summary":"先日、「ElasticSearch Serverを翻訳しました」という記事を書きました。 この中で電子版も出ますよと書いていましたが、電子版も発","tags":["elasticsearch"],"title":"ElasticSearch Server日本語版（電子版も）が発売されました","type":"post","url":"/blog/2014/03/25/release-elasticsearch-server-ja-ebook/","weight":0,"wordcount":717},{"date":1395151860,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1395151860,"objectID":"65453a1ae403679bd2e47398a04205ca","permalink":"https://blog.johtani.info/blog/2014/03/18/attend-goto-night-elasticsearch/","publishdate":"2014-03-18T23:11:00+09:00","readingtime":2,"relpermalink":"/blog/2014/03/18/attend-goto-night-elasticsearch/","section":"post","summary":"GOTO Night elasticsearchに参加しました。 初の海外の勉強会です（海外自体が初だし）。 ベルリンにあるWoogaという会社で開催された勉強会","tags":["elasticsearch","勉強会"],"title":"GOTO Night elasticsearchに参加しました","type":"post","url":"/blog/2014/03/18/attend-goto-night-elasticsearch/","weight":0,"wordcount":867},{"date":1394916660,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":300,"kind":"page","lang":"ja","lastmod":1394916660,"objectID":"abc5ca9856a61831fd4ed06b402875d2","permalink":"https://blog.johtani.info/blog/2014/03/16/post-from-berlin/","publishdate":"2014-03-16T05:51:00+09:00","readingtime":1,"relpermalink":"/blog/2014/03/16/post-from-berlin/","section":"post","summary":"Berlinからおはようございます。 ということで、人生で初めての海外に来ています。 人生初の海外なのに、一人で乗り換えがあるようなBerlin","tags":["misc","travel"],"title":"Berlinからおはようございます","type":"post","url":"/blog/2014/03/16/post-from-berlin/","weight":0,"wordcount":226},{"date":1394515380,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1394515380,"objectID":"386dc9d1b647a9f3965f1fbe29c7dfb9","permalink":"https://blog.johtani.info/blog/2014/03/11/es-plugin-installed-to-my-env/","publishdate":"2014-03-11T14:23:00+09:00","readingtime":4,"relpermalink":"/blog/2014/03/11/es-plugin-installed-to-my-env/","section":"post","summary":"elasticsearchに、このへん入れるときっと幸せになれるはず・たぶん。\u0026#10;elasticsearch/elasticsearc","tags":["elasticsearch","plugin"],"title":"いつも入れているElasticsearchのプラグイン","type":"post","url":"/blog/2014/03/11/es-plugin-installed-to-my-env/","weight":0,"wordcount":1509},{"date":1393836900,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1393836900,"objectID":"9ad72c2a5157f21741bd4581a562dfc7","permalink":"https://blog.johtani.info/blog/2014/03/03/release-elasticsearch-server-japanese-edition/","publishdate":"2014-03-03T17:55:00+09:00","readingtime":3,"relpermalink":"/blog/2014/03/03/release-elasticsearch-server-japanese-edition/","section":"post","summary":"第3回Elasticsearch勉強会で、軽く触れていましたが、ElasticSearch Server日本語版が発売されます。 ツイートなども","tags":["elasticsearch"],"title":"ElasticSearch Serverを翻訳しました","type":"post","url":"/blog/2014/03/03/release-elasticsearch-server-japanese-edition/","weight":0,"wordcount":1468},{"date":1393231920,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1393231920,"objectID":"f55d33371dcff207fd7d201128df2ea3","permalink":"https://blog.johtani.info/blog/2014/02/24/strange-behavior-of-field-in-nested-obj/","publishdate":"2014-02-24T17:52:00+09:00","readingtime":5,"relpermalink":"/blog/2014/02/24/strange-behavior-of-field-in-nested-obj/","section":"post","summary":"今年初の「突撃！隣のElasticsearch」ということで、Wantedlyさんにおじゃましました。 ※写真を自分でも撮ったのですが、画像が","tags":["elasticsearch"],"title":"Nested Objectのフィールドの奇妙な動作","type":"post","url":"/blog/2014/02/24/strange-behavior-of-field-in-nested-obj/","weight":0,"wordcount":2330},{"date":1391787720,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1700,"kind":"page","lang":"ja","lastmod":1391787720,"objectID":"229b7fc784707b1d2c702fbeba080e86","permalink":"https://blog.johtani.info/blog/2014/02/08/hold-3rd-elasticsaerch-meetup-in-tokyo/","publishdate":"2014-02-08T00:42:00+09:00","readingtime":4,"relpermalink":"/blog/2014/02/08/hold-3rd-elasticsaerch-meetup-in-tokyo/","section":"post","summary":"今回はたまたま日本にいたElasticsearchの人をスペシャルゲストに呼べたので、大満足ですｗ 英語の通訳とかちゃんと勉強しないとなぁ。。","tags":["elasticsearch","勉強会"],"title":"第3回elasticsearch勉強会を開催しました！ #elasticsearchjp","type":"post","url":"/blog/2014/02/08/hold-3rd-elasticsaerch-meetup-in-tokyo/","weight":0,"wordcount":1671},{"date":1391695740,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2100,"kind":"page","lang":"ja","lastmod":1391695740,"objectID":"c98cbc333fb7d95c6c9fc4924b0526e1","permalink":"https://blog.johtani.info/blog/2014/02/06/es-cluster-start-using-vagrant-and-puppet/","publishdate":"2014-02-06T23:09:00+09:00","readingtime":5,"relpermalink":"/blog/2014/02/06/es-cluster-start-using-vagrant-and-puppet/","section":"post","summary":"すずけんさんがVagrant+puppet使って、VM起動してElasticsearchのクラスタを組んでる記事を書いているのを見て、試して","tags":["elasticsearch","vagrant","puppet","marvel"],"title":"すずけんさんのメモを元にVagrantでElasticsearchクラスタを起動してみた","type":"post","url":"/blog/2014/02/06/es-cluster-start-using-vagrant-and-puppet/","weight":0,"wordcount":2095},{"date":1390988760,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1200,"kind":"page","lang":"ja","lastmod":1390988760,"objectID":"c6107ff57e96a1373c019d252c00ad84","permalink":"https://blog.johtani.info/blog/2014/01/29/hold-to-japan-solr-meetup/","publishdate":"2014-01-29T18:46:00+09:00","readingtime":3,"relpermalink":"/blog/2014/01/29/hold-to-japan-solr-meetup/","section":"post","summary":"改訂新版Solr入門出版記念ということで、第13回Solr勉強会 #SolrJP 新Solr本出版記念を開催しました。 出版記念なので、技術評論社様より、プレ","tags":["Solr","勉強会"],"title":"第13回Solr勉強会を開催しました","type":"post","url":"/blog/2014/01/29/hold-to-japan-solr-meetup/","weight":0,"wordcount":1107},{"date":1390983240,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1390983240,"objectID":"f6debed350f20a2b3aa4d970e3227411","permalink":"https://blog.johtani.info/blog/2014/01/29/simple-introduction-and-first-impression-es-marvel/","publishdate":"2014-01-29T17:14:00+09:00","readingtime":6,"relpermalink":"/blog/2014/01/29/simple-introduction-and-first-impression-es-marvel/","section":"post","summary":"昨晩、Elasticsearchから初のプロダクトとなるMarvelがリリースされました。ということで、さっそく触ってみて、簡単な紹介と感想","tags":["elasticsearch","marvel"],"title":"Elasticsearch Marvelの紹介と第一印象","type":"post","url":"/blog/2014/01/29/simple-introduction-and-first-impression-es-marvel/","weight":0,"wordcount":2551},{"date":1390880040,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":600,"kind":"page","lang":"ja","lastmod":1390880040,"objectID":"c4e7199a586a308352b7a881add7e356","permalink":"https://blog.johtani.info/blog/2014/01/28/release-lucene-gosen-4-dot-6-1/","publishdate":"2014-01-28T12:34:00+09:00","readingtime":2,"relpermalink":"/blog/2014/01/28/release-lucene-gosen-4-dot-6-1/","section":"post","summary":"Lucene/Solr 4.6.1がリリースされそう(バイナリ配布待ち)lucene-gosenの4.6.1対応版をリリースしました。 ライブラリのインタフェースな","tags":["Solr","Lucene","lucene-gosen"],"title":"lucene-gosen 4.6.1のリリースに関する注意点","type":"post","url":"/blog/2014/01/28/release-lucene-gosen-4-dot-6-1/","weight":0,"wordcount":574},{"date":1390542480,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":4500,"kind":"page","lang":"ja","lastmod":1390542480,"objectID":"15f501351d482ffd73985a50f5c89d1f","permalink":"https://blog.johtani.info/blog/2014/01/24/curator-tending-your-time-series-indices-in-japanese/","publishdate":"2014-01-24T14:48:00+09:00","readingtime":9,"relpermalink":"/blog/2014/01/24/curator-tending-your-time-series-indices-in-japanese/","section":"post","summary":"Elasticsearchのcuratorのブログ記事を読んで、日本語でツイートしたところ、Aaron Mildensteinさんから日本語（","tags":["elasticsearch","curator"],"title":"Curator: 時系列インデックスの管理(日本語訳)","type":"post","url":"/blog/2014/01/24/curator-tending-your-time-series-indices-in-japanese/","weight":0,"wordcount":4441},{"date":1390317360,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1390317360,"objectID":"6425af51edead39c0e439073986043fb","permalink":"https://blog.johtani.info/blog/2014/01/22/release-extended-plugin-for-1-0-0rc1/","publishdate":"2014-01-22T00:16:00+09:00","readingtime":2,"relpermalink":"/blog/2014/01/22/release-extended-plugin-for-1-0-0rc1/","section":"post","summary":"あけましておめでとうございます。今年もSolrやElasticsearchについて色々と頑張っていく所存です。 とまぁ、お決まりの挨拶はおいて","tags":["elasticsearch"],"title":"Extended-Analyze 1.0.0RC1をリリースしました","type":"post","url":"/blog/2014/01/22/release-extended-plugin-for-1-0-0rc1/","weight":0,"wordcount":902},{"date":1388406000,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":3600,"kind":"page","lang":"ja","lastmod":1388406000,"objectID":"10c715f70de25ccb493bbbb532b78ced","permalink":"https://blog.johtani.info/blog/2013/12/30/looking-back-2013/","publishdate":"2013-12-30T21:20:00+09:00","readingtime":8,"relpermalink":"/blog/2013/12/30/looking-back-2013/","section":"post","summary":"昨年は、大晦日に書いてました。 ちょっと進歩したかも。 振り返り(2012年に書いた抱負から) ということで、まずは昨年書いた抱負からの振り返りで","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2013）","type":"post","url":"/blog/2013/12/30/looking-back-2013/","weight":0,"wordcount":3551},{"date":1387524240,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1387524240,"objectID":"c18b12fff24dc87e7f1039bd17c0c6aa","permalink":"https://blog.johtani.info/blog/2013/12/20/release-elasticsearch-0-90-8/","publishdate":"2013-12-20T16:24:00+09:00","readingtime":2,"relpermalink":"/blog/2013/12/20/release-elasticsearch-0-90-8/","section":"post","summary":"昨夜、Elasticsearchの0.90.8がリリースされました。 リリースされた内容などについては、本家のブログ「0.90.8 releas","tags":["elasticsearch","kuromoji"],"title":"Elasticsearch 0.90.8がリリースされました＆注意点（2013/12/20追記）","type":"post","url":"/blog/2013/12/20/release-elasticsearch-0-90-8/","weight":0,"wordcount":867},{"date":1387447740,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1387447740,"objectID":"cb5b6f7ab4d36e90d2619cb907ebb956","permalink":"https://blog.johtani.info/blog/2013/12/19/add-jar-file-to-solr/","publishdate":"2013-12-19T19:09:00+09:00","readingtime":3,"relpermalink":"/blog/2013/12/19/add-jar-file-to-solr/","section":"post","summary":"Solr本が出てから、質問を受けてブログ書くと言いながら書いてなかったことを思い出しました。。。 プラグインの配置方法についてこんな質問を受け","tags":["Solr"],"title":"Solrへのプラグインの配置方法について","type":"post","url":"/blog/2013/12/19/add-jar-file-to-solr/","weight":0,"wordcount":1008},{"date":1387249860,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1387249860,"objectID":"a0a00c23556fcc5dbfb7b7f43fbbb61d","permalink":"https://blog.johtani.info/blog/2013/12/17/release-es-extended-analyze-plugin-to-maven-and-sonatype/","publishdate":"2013-12-17T12:11:00+09:00","readingtime":2,"relpermalink":"/blog/2013/12/17/release-es-extended-analyze-plugin-to-maven-and-sonatype/","section":"post","summary":"ども。 プラグインのインストールに長いURL入れるの辛いですよね？ね？ ということで、MavenでリリースしてMaven Repositoryから","tags":["elasticsearch"],"title":"elasticsearch-extended-analyzeプラグインをMavenとSonatypeにリリース","type":"post","url":"/blog/2013/12/17/release-es-extended-analyze-plugin-to-maven-and-sonatype/","weight":0,"wordcount":770},{"date":1386554880,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":200,"kind":"page","lang":"ja","lastmod":1386554880,"objectID":"d9560caeb797b302191f667b4264da40","permalink":"https://blog.johtani.info/blog/2013/12/09/release-introduction-solr-ebook/","publishdate":"2013-12-09T11:08:00+09:00","readingtime":1,"relpermalink":"/blog/2013/12/09/release-introduction-solr-ebook/","section":"post","summary":"少し遅くなってしまいましたが、12/05に電子書籍も発売されました。 技術評論社の電子書籍サイトから購入可能です。 書籍のページへのリンク PDF","tags":["Solr"],"title":"改訂版Solr入門のPDF版も発売","type":"post","url":"/blog/2013/12/09/release-introduction-solr-ebook/","weight":0,"wordcount":190},{"date":1385436420,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1385436420,"objectID":"a2012a3c9cdb1d6fd69afdbadc1e76b6","permalink":"https://blog.johtani.info/blog/2013/11/26/introduction-to-solr-new-edition/","publishdate":"2013-11-26T12:27:00+09:00","readingtime":2,"relpermalink":"/blog/2013/11/26/introduction-to-solr-new-edition/","section":"post","summary":"勉強会で宣伝もしましたが、改めて。 Solr入門の改訂版を執筆しました。 考えてみれば、もう3年も前なんですね、Solr入門は。 Solr勉強会な","tags":["Solr"],"title":"改訂版Solr入門を執筆しました","type":"post","url":"/blog/2013/11/26/introduction-to-solr-new-edition/","weight":0,"wordcount":638},{"date":1384419300,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1384419300,"objectID":"13684d16fdd07d5f0584e29265a270e7","permalink":"https://blog.johtani.info/blog/2013/11/14/release-elasticsearch-extended-analyze-0-dot-5/","publishdate":"2013-11-14T17:55:00+09:00","readingtime":5,"relpermalink":"/blog/2013/11/14/release-elasticsearch-extended-analyze-0-dot-5/","section":"post","summary":"どーも。以前の記事で開発中としていたプラグインですが、とりあえず、pluginコマンドでインストール出来る形にしてみました。 インストールなど","tags":["elasticsearch","plugin"],"title":"elasticsearch-extended-analyzeを公開？","type":"post","url":"/blog/2013/11/14/release-elasticsearch-extended-analyze-0-dot-5/","weight":0,"wordcount":2368},{"date":1384247760,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1384247760,"objectID":"66f43ab4b823d67f52735bbbe6ba65b0","permalink":"https://blog.johtani.info/blog/2013/11/12/elasticsearch-japan-user-meetup-no2/","publishdate":"2013-11-12T18:16:00+09:00","readingtime":4,"relpermalink":"/blog/2013/11/12/elasticsearch-japan-user-meetup-no2/","section":"post","summary":"第2回を開催しました！ すごい、140人くらいくらいの参加登録者（参加者は１００人ちょっと！）がいて、びっくりです。 ステキな会場を提供していた","tags":["elasticsearch","kibana","fluentd","勉強会"],"title":"第2回elasticsearch勉強会を開催しました！ #elasticsearchjp","type":"post","url":"/blog/2013/11/12/elasticsearch-japan-user-meetup-no2/","weight":0,"wordcount":1717},{"date":1383786660,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1383786660,"objectID":"a106d7c1b1b277538367f9c8140e3a75","permalink":"https://blog.johtani.info/blog/2013/11/07/cloudera-world-tokyo-2013/","publishdate":"2013-11-07T10:11:00+09:00","readingtime":5,"relpermalink":"/blog/2013/11/07/cloudera-world-tokyo-2013/","section":"post","summary":"Cloudera World Tokyo 2013に参加してきました。 午前中はあいにくの雨でしたが、それでも結構な人数が最初の基調講演から参加されてました。 私が参加したセッショ","tags":["Cloudera","Hadoop","Norikra"],"title":"Cloudera World Tokyo 2013に参加しました！ #cwt2013 ","type":"post","url":"/blog/2013/11/07/cloudera-world-tokyo-2013/","weight":0,"wordcount":2455},{"date":1383746460,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1383746460,"objectID":"9dca844d353efed03fbaddfc0fab7c76","permalink":"https://blog.johtani.info/blog/2013/11/06/riak-meetup-tokyo-no3/","publishdate":"2013-11-06T23:01:00+09:00","readingtime":2,"relpermalink":"/blog/2013/11/06/riak-meetup-tokyo-no3/","section":"post","summary":"またまた、Riak Meetup Tokyo #3に参加してきました。Riak2.0のYokozunaの話があると聞いたので。 ということで、いつものように個人メモで","tags":["Riak","Yokozuna"],"title":"Riak Meetup #3 #riakjp に参加しました。","type":"post","url":"/blog/2013/11/06/riak-meetup-tokyo-no3/","weight":0,"wordcount":952},{"date":1383570720,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":600,"kind":"page","lang":"ja","lastmod":1383570720,"objectID":"b5c628b0c1dbf857a475c4be5de4690d","permalink":"https://blog.johtani.info/blog/2013/11/04/improve-output-extended-analyze/","publishdate":"2013-11-04T22:12:00+09:00","readingtime":2,"relpermalink":"/blog/2013/11/04/improve-output-extended-analyze/","section":"post","summary":"開発中ですと書きました、elasticsearch-extended-analyzeですが、改良しました。 改良と変更は以下のとおりです。 ソー","tags":["elasticsearch","plugin"],"title":"elasticsearch-extended-analyzeの改良","type":"post","url":"/blog/2013/11/04/improve-output-extended-analyze/","weight":0,"wordcount":536},{"date":1382695560,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1382695560,"objectID":"0302e8a57a5e8604342a925b2dc60737","permalink":"https://blog.johtani.info/blog/2013/10/25/developing-es-extended-analyze-plugin/","publishdate":"2013-10-25T19:06:00+09:00","readingtime":5,"relpermalink":"/blog/2013/10/25/developing-es-extended-analyze-plugin/","section":"post","summary":"お久しぶりです。 気づいたらまた、結構ブログを書いてなかったです。。。 今回は、今開発しているElasticsearchのプラグインに関するお話","tags":["elasticsearch","plugin"],"title":"elasticsearch-extended-analyzeプラグインを開発中","type":"post","url":"/blog/2013/10/25/developing-es-extended-analyze-plugin/","weight":0,"wordcount":2302},{"date":1381372500,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1900,"kind":"page","lang":"ja","lastmod":1381372500,"objectID":"76e127a44931bfefab991be3dd7a08b7","permalink":"https://blog.johtani.info/blog/2013/10/10/solr-meetup-memo/","publishdate":"2013-10-10T11:35:00+09:00","readingtime":4,"relpermalink":"/blog/2013/10/10/solr-meetup-memo/","section":"post","summary":"不定期開催ですが第12回Solr勉強会を主催しました。 今回は、前回ほどの過熱ぶりでは無かったですが、70人ほどの参加者の方がいらっしゃったか","tags":["Solr","Riak","Yokozuna","ManifoldCF"],"title":"第12回Solr勉強会を主催しました。#SolrJP","type":"post","url":"/blog/2013/10/10/solr-meetup-memo/","weight":0,"wordcount":1842},{"date":1379906820,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1379906820,"objectID":"e1870dde155be1a375f155dd1f7ead13","permalink":"https://blog.johtani.info/blog/2013/09/23/intro-elasticsearch-inquisitor/","publishdate":"2013-09-23T12:27:00+09:00","readingtime":6,"relpermalink":"/blog/2013/09/23/intro-elasticsearch-inquisitor/","section":"post","summary":"今日は、ElasticSearchのMLで見つけたelasticsearch-inquisitorプラグインの紹介です。 ElasticSea","tags":["elasticsearch","plugin"],"title":"elasticsearch-inquisitorプラグインの紹介","type":"post","url":"/blog/2013/09/23/intro-elasticsearch-inquisitor/","weight":0,"wordcount":2694},{"date":1378921080,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1378921080,"objectID":"d2e805472f79f0b558f75b90b5e7b4ee","permalink":"https://blog.johtani.info/blog/2013/09/12/question-river-wikipedia/","publishdate":"2013-09-12T02:38:00+09:00","readingtime":6,"relpermalink":"/blog/2013/09/12/question-river-wikipedia/","section":"post","summary":"river-wikipediaの前々回の記事で書きましたが、bulk_sizeに関連して登録件数がやけにきりが良いのが気になると書いていまし","tags":["elasticsearch","wikipedia"],"title":"elasticsearch-river-wikipediaの疑問点","type":"post","url":"/blog/2013/09/12/question-river-wikipedia/","weight":0,"wordcount":2628},{"date":1378138500,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1378138500,"objectID":"79e647a3f8b36a1221897f5837c84aff","permalink":"https://blog.johtani.info/blog/2013/09/03/ja-wikipedia-with-kuromoji/","publishdate":"2013-09-03T01:15:00+09:00","readingtime":3,"relpermalink":"/blog/2013/09/03/ja-wikipedia-with-kuromoji/","section":"post","summary":"前々回紹介した、日本語Wikipediaのデータをインデックス登録する記事の続きです。 今回は、Kuromojiのアナライザを利用してインデッ","tags":["elasticsearch","kuromoji","wikipedia"],"title":"日本語Wikipediaをインデクシング（Kuromojiバージョン）","type":"post","url":"/blog/2013/09/03/ja-wikipedia-with-kuromoji/","weight":0,"wordcount":1323},{"date":1377798120,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1377798120,"objectID":"5931f8e3acdac724742c4ee0960d8d40","permalink":"https://blog.johtani.info/blog/2013/08/30/hold-first-elasticsearch-meetup-in-japan/","publishdate":"2013-08-30T02:42:00+09:00","readingtime":5,"relpermalink":"/blog/2013/08/30/hold-first-elasticsearch-meetup-in-japan/","section":"post","summary":"ElasticSearch勉強会 第1回を主催しました。 昨年のpyfesでなんちゃって資料で喋って、1年たちました。 ElasticSearch","tags":["elasticsearch","勉強会"],"title":"第1回ElasticSearch勉強会を開催しました！ #elasticsearchjp","type":"post","url":"/blog/2013/08/30/hold-first-elasticsearch-meetup-in-japan/","weight":0,"wordcount":2451},{"date":1377226920,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1377226920,"objectID":"3931327ed463d1568868c5ab8e839148","permalink":"https://blog.johtani.info/blog/2013/08/23/index-wikipedia-ja-to-elasticsearch/","publishdate":"2013-08-23T12:02:00+09:00","readingtime":6,"relpermalink":"/blog/2013/08/23/index-wikipedia-ja-to-elasticsearch/","section":"post","summary":"久々のブログはElasticSearchネタです。勉強会開催する予定だったりすので、もう少し触っておきたいなと。 お手軽に検索するデータとして","tags":["elasticsearch","wikipedia"],"title":"ElasticSearchにプラグインで日本語Wikipediaデータを入れてみました","type":"post","url":"/blog/2013/08/23/index-wikipedia-ja-to-elasticsearch/","weight":0,"wordcount":2705},{"date":1375434120,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1900,"kind":"page","lang":"ja","lastmod":1375434120,"objectID":"33e01e2271be22b5ed330045fe6aff50","permalink":"https://blog.johtani.info/blog/2013/08/02/morphlines-loadsolr/","publishdate":"2013-08-02T18:02:00+09:00","readingtime":4,"relpermalink":"/blog/2013/08/02/morphlines-loadsolr/","section":"post","summary":"宿題その2？かな。Solr勉強会でCloudera Searchのスキーマ周りってどうなってるの？という質問が出てて、 なんか調べることになって","tags":["Cloudera Search","Morphlines","Solr"],"title":"MorphlinesのloadSolrをちょっとだけ調べてみた","type":"post","url":"/blog/2013/08/02/morphlines-loadsolr/","weight":0,"wordcount":1850},{"date":1375364280,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1375364280,"objectID":"cd9ba1f582642d9cbe500f018afab341","permalink":"https://blog.johtani.info/blog/2013/08/01/replace-xperia-z/","publishdate":"2013-08-01T22:38:00+09:00","readingtime":3,"relpermalink":"/blog/2013/08/01/replace-xperia-z/","section":"post","summary":"今朝起きたら、Xperia Zが故障してしまいました。 電源ボタンを押してもスリープにならないんです。しかも、スリープからの復帰もできない。。。","tags":["Xperia Z"],"title":"Xperia Zが故障したので交換したのでメモ","type":"post","url":"/blog/2013/08/01/replace-xperia-z/","weight":0,"wordcount":1431},{"date":1375265520,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1900,"kind":"page","lang":"ja","lastmod":1375265520,"objectID":"b875f24d3d444fdda82b6bbfb75a4c92","permalink":"https://blog.johtani.info/blog/2013/07/31/introduction-morphlines/","publishdate":"2013-07-31T19:12:00+09:00","readingtime":4,"relpermalink":"/blog/2013/07/31/introduction-morphlines/","section":"post","summary":"Morphlinesについてちょっとだけ、さらに調べました。 誤解 Solr勉強会でなんとなく私の認識を話しましたが、ちょっと誤解してたみたいで","tags":["Cloudera Search","Morphlines","Solr"],"title":"Morphlines入門？","type":"post","url":"/blog/2013/07/31/introduction-morphlines/","weight":0,"wordcount":1888},{"date":1375107300,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1375107300,"objectID":"59d1b7206e7664e76672d3de4dc9a8ed","permalink":"https://blog.johtani.info/blog/2013/07/29/study-of-solr/","publishdate":"2013-07-29T23:15:00+09:00","readingtime":6,"relpermalink":"/blog/2013/07/29/study-of-solr/","section":"post","summary":"不定期開催ですが第11回Solr勉強会を主催しました。 今回も大入り90人くらい？の参加者の皆さんがいらっしゃいました。ありがたいことです！（","tags":["Solr","Cloudera Search","ManifoldCF"],"title":"第11回Solr勉強会を主催しました。#SolrJP","type":"post","url":"/blog/2013/07/29/study-of-solr/","weight":0,"wordcount":2518},{"date":1374685860,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1374685860,"objectID":"1b9c5ae60ec46be64a1877f0c6920edc","permalink":"https://blog.johtani.info/blog/2013/07/25/hadoop-hive-publication-party/","publishdate":"2013-07-25T02:11:00+09:00","readingtime":3,"relpermalink":"/blog/2013/07/25/hadoop-hive-publication-party/","section":"post","summary":"Hadoopとか離れちゃってるし、Hive触ったこと無いにもかかわらず参加しました！ （たまたま近くにいるからって理由なのは内緒で） 玉川さんの","tags":["Hadoop","Hive","Cloudera","オライリー"],"title":"『プログラミング Hive』 『Hadoop 第3版』刊行記念セミナーに参加しました！ #oreilly0724","type":"post","url":"/blog/2013/07/25/hadoop-hive-publication-party/","weight":0,"wordcount":1016},{"date":1373474580,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":600,"kind":"page","lang":"ja","lastmod":1373474580,"objectID":"50557b455cba1a3ce9b4555fc3fd5433","permalink":"https://blog.johtani.info/blog/2013/07/11/yokozuna-check-point/","publishdate":"2013-07-11T01:43:00+09:00","readingtime":2,"relpermalink":"/blog/2013/07/11/yokozuna-check-point/","section":"post","summary":"Yokozunaの気になる点というか、自分だったらこのへん調べるだろうなって観点を上げてみます。 別に調べるわけじゃないので、完全に自己満足な","tags":["Riak","Solr","Yokozuna"],"title":"Yokozunaの気になる点というかなんというか","type":"post","url":"/blog/2013/07/11/yokozuna-check-point/","weight":0,"wordcount":505},{"date":1373450220,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2100,"kind":"page","lang":"ja","lastmod":1373450220,"objectID":"146e8ca40c0d37f36eecea822028dd9e","permalink":"https://blog.johtani.info/blog/2013/07/10/riak-meetup-tokyo-no2/","publishdate":"2013-07-10T18:57:00+09:00","readingtime":4,"relpermalink":"/blog/2013/07/10/riak-meetup-tokyo-no2/","section":"post","summary":"先日、Bashoさんにおじゃましたのもあり、Riak Meetup Tokyo #2に参加しました。 Yokozunaの話も聞けるということで。 懇親会も参加しました。","tags":["Riak","Yokozuna","Solr"],"title":"Riak Meetup Tokyo #2に参加しました。#riakjp","type":"post","url":"/blog/2013/07/10/riak-meetup-tokyo-no2/","weight":0,"wordcount":2002},{"date":1372867920,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2900,"kind":"page","lang":"ja","lastmod":1372867920,"objectID":"a98d42be181c01b8077e060b1b5080ec","permalink":"https://blog.johtani.info/blog/2013/07/04/schemaless-example/","publishdate":"2013-07-04T01:12:00+09:00","readingtime":6,"relpermalink":"/blog/2013/07/04/schemaless-example/","section":"post","summary":"Solr 4.4に取り込まれる予定のチケットで、気になるものを見つけたのでいつものごとく調べてみました。 元となるチケットはこちら。SOLR-4897","tags":["Solr"],"title":"スキーマレスモード？（SOLR-4897）を調べて見ました。","type":"post","url":"/blog/2013/07/04/schemaless-example/","weight":0,"wordcount":2854},{"date":1372318080,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1372318080,"objectID":"ecf3ac80454654d990d9c07d33d35d1c","permalink":"https://blog.johtani.info/blog/2013/06/27/upload-docs-solr-admin/","publishdate":"2013-06-27T16:28:00+09:00","readingtime":3,"relpermalink":"/blog/2013/06/27/upload-docs-solr-admin/","section":"post","summary":"SolrのチケットをML経由で眺めてるんですが、便利そうなチケットが流れてきたのでブログを書いてみみようかと。 元になってるチケットはこちらで","tags":["Solr"],"title":"Solrの管理画面でデータ登録","type":"post","url":"/blog/2013/06/27/upload-docs-solr-admin/","weight":0,"wordcount":1461},{"date":1371652980,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":4100,"kind":"page","lang":"ja","lastmod":1371652980,"objectID":"26c47355cbe966a94826cbe2fbf2b355","permalink":"https://blog.johtani.info/blog/2013/06/19/introduction-kibana3/","publishdate":"2013-06-19T23:43:00+09:00","readingtime":9,"relpermalink":"/blog/2013/06/19/introduction-kibana3/","section":"post","summary":"前回は3番煎じぐらいでしたが、今回は初記事かな？（だといいな） Kibanaには、前回の記事で書いたものとは別に開発中のKibana3というの","tags":["elasticsearch","kibana"],"title":"Kibana3というのもありまして","type":"post","url":"/blog/2013/06/19/introduction-kibana3/","weight":0,"wordcount":4039},{"date":1371603780,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1371603780,"objectID":"33919e866426ce8e7b2ce06f19bbf889","permalink":"https://blog.johtani.info/blog/2013/06/19/visited-basho/","publishdate":"2013-06-19T10:03:00+09:00","readingtime":2,"relpermalink":"/blog/2013/06/19/visited-basho/","section":"post","summary":"ちょくちょく書こうと言いながら、前の記事が1週間以上前になってる。。。 昨日は、Basho Japanに遊びに行って来ました。 （Riak触ったこ","tags":["Riak","Basho","Yokozuna","Solr"],"title":"Basho Japanに遊びに行きました","type":"post","url":"/blog/2013/06/19/visited-basho/","weight":0,"wordcount":987},{"date":1370945460,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1200,"kind":"page","lang":"ja","lastmod":1370945460,"objectID":"78292d953eafbdf9e57cc4bbbe6e8964","permalink":"https://blog.johtani.info/blog/2013/06/11/new-solr-xml/","publishdate":"2013-06-11T19:11:00+09:00","readingtime":3,"relpermalink":"/blog/2013/06/11/new-solr-xml/","section":"post","summary":"Lucene/Solr 4.3.1のRCのVoteが始まっていますが、そのMLできになったコトがあり、ちょっと調べたので メモを残しておきます。 マルチコアの設定ファ","tags":["Solr"],"title":"新しいsolr.xmlとCore探索ロジック","type":"post","url":"/blog/2013/06/11/new-solr-xml/","weight":0,"wordcount":1168},{"date":1370874840,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1370874840,"objectID":"c4d3a917f623f58646ce93015d79e8e0","permalink":"https://blog.johtani.info/blog/2013/06/10/fluent-es-kibana/","publishdate":"2013-06-10T23:34:00+09:00","readingtime":6,"relpermalink":"/blog/2013/06/10/fluent-es-kibana/","section":"post","summary":"もう何番煎じだ？ってくらい書かれてますが、コリもせず書いてみました。 Elasticsearch＋Kibanaの環境を作って、タムタムさんのロ","tags":["kibana","elasticsearch","fluentd"],"title":"apache-loggen + fluentd + elasticsearch + kibana = ログ検索デモ","type":"post","url":"/blog/2013/06/10/fluent-es-kibana/","weight":0,"wordcount":2777},{"date":1370527200,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1370527200,"objectID":"d12c1c2a68be4c7fda5a7737d5493b4d","permalink":"https://blog.johtani.info/blog/2013/06/06/aws-summit-tokyo-day2/","publishdate":"2013-06-06T23:00:00+09:00","readingtime":6,"relpermalink":"/blog/2013/06/06/aws-summit-tokyo-day2/","section":"post","summary":"昨日に引き続き、AWS Summit Tokyo 2013に行ってきました。 @ryu_kobayashiさんからパシリを仰せつかるなどあり、忙しかったのですが楽しか","tags":["AWS","勉強会"],"title":"AWS Summit Tokyo 2013に行って来ました。(Day2) #awssummit","type":"post","url":"/blog/2013/06/06/aws-summit-tokyo-day2/","weight":0,"wordcount":2717},{"date":1370489160,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1370489160,"objectID":"f45069216cd934b80ce882c9a2f2a08a","permalink":"https://blog.johtani.info/blog/2013/06/06/cloudera-search-memo2/","publishdate":"2013-06-06T12:26:00+09:00","readingtime":3,"relpermalink":"/blog/2013/06/06/cloudera-search-memo2/","section":"post","summary":"ざっとインストールガイドとかCloudera Searchのソース眺めて、テキトーにメモを書いてみました。 （ユーザガイドはまだ読んでないです。","tags":["Cloudera Search","Hadoop","Solr"],"title":"Cloudera Searchメモ（妄想版）","type":"post","url":"/blog/2013/06/06/cloudera-search-memo2/","weight":0,"wordcount":1419},{"date":1370424600,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1370424600,"objectID":"1fe14e2e02b6e65e6e6e2ae3d8ddcc9f","permalink":"https://blog.johtani.info/blog/2013/06/05/aws-summit-tokyo-day1/","publishdate":"2013-06-05T18:30:00+09:00","readingtime":5,"relpermalink":"/blog/2013/06/05/aws-summit-tokyo-day1/","section":"post","summary":"AWS Summit Tokyo 2013に行って来ました。 @cocoatomoさんに行き掛けに出会ったので、アンデルセンの講演を一緒に聞いてました。 TDブースの@ry","tags":["勉強会","AWS"],"title":"AWS Summit Tokyo 2013に行って来ました。(Day1) #awssummit","type":"post","url":"/blog/2013/06/05/aws-summit-tokyo-day1/","weight":0,"wordcount":2453},{"date":1370412720,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1370412720,"objectID":"e30258aeb8475d4c27f7935945671856","permalink":"https://blog.johtani.info/blog/2013/06/05/cloudera-search-modules/","publishdate":"2013-06-05T15:12:00+09:00","readingtime":3,"relpermalink":"/blog/2013/06/05/cloudera-search-modules/","section":"post","summary":"Cloudera Searchは次のようなモジュールから構成されています。 これはCloudera Searchのモジュールで、さらにこれらがSolrとかを使っ","tags":["Cloudera","Hadoop","Solr","Cloudera Search"],"title":"Cloudera Searchのモジュールたち","type":"post","url":"/blog/2013/06/05/cloudera-search-modules/","weight":0,"wordcount":1467},{"date":1370412300,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1370412300,"objectID":"cd90bce912f5743226af94c1efaaa4a7","permalink":"https://blog.johtani.info/blog/2013/06/05/what-is-cloudera-search/","publishdate":"2013-06-05T15:05:00+09:00","readingtime":2,"relpermalink":"/blog/2013/06/05/what-is-cloudera-search/","section":"post","summary":"AWS Summitに来ていたのですが、TLでは、Cloudera Searchが賑わってました。 ということで、軽くどんなものか読んだり調べたりした","tags":["Cloudera","Hadoop","Solr","Cloudera Search"],"title":"Cloudera Searchってのが出たらしい（とりあえず、雑感？）","type":"post","url":"/blog/2013/06/05/what-is-cloudera-search/","weight":0,"wordcount":898},{"date":1370234580,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2100,"kind":"page","lang":"ja","lastmod":1370234580,"objectID":"494557db52824555864d1106278cd1f0","permalink":"https://blog.johtani.info/blog/2013/06/03/fluent-plugin-zoomdata-0-0-1/","publishdate":"2013-06-03T13:43:00+09:00","readingtime":5,"relpermalink":"/blog/2013/06/03/fluent-plugin-zoomdata-0-0-1/","section":"post","summary":"憧れ？のfluentを使ってみました。 こちらの記事で紹介したZoomdataを最近触っているのですが、お試しにfluentdでデータ流し込む","tags":["Zoomdata","fluentd"],"title":"fluent-plugin-zoomdata作りました＋悩み事とか","type":"post","url":"/blog/2013/06/03/fluent-plugin-zoomdata-0-0-1/","weight":0,"wordcount":2063},{"date":1370228038,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":400,"kind":"page","lang":"ja","lastmod":1370228038,"objectID":"16f10764f0ccce42d5be8cfeac36b446","permalink":"https://blog.johtani.info/blog/2013/06/03/octopress%E3%82%92%E8%A9%A6%E3%81%97%E4%B8%AD/","publishdate":"2013-06-03T11:53:58+09:00","readingtime":1,"relpermalink":"/blog/2013/06/03/octopress%E3%82%92%E8%A9%A6%E3%81%97%E4%B8%AD/","section":"post","summary":"最近、Markdownで文章を書くのに慣れてきました。 ということで、ブログをMarkdownで書けないかなぁと思い、TLの人たちのブログを見","tags":["misc"],"title":"Octopressを試し中(Jugemより移植)","type":"post","url":"/blog/2013/06/03/octopress%E3%82%92%E8%A9%A6%E3%81%97%E4%B8%AD/","weight":0,"wordcount":361},{"date":1370098620,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":400,"kind":"page","lang":"ja","lastmod":1370098620,"objectID":"dbcc4002c15afefef853a08a0804ba3a","permalink":"https://blog.johtani.info/blog/2013/06/01/first-octopress/","publishdate":"2013-06-01T23:57:00+09:00","readingtime":1,"relpermalink":"/blog/2013/06/01/first-octopress/","section":"post","summary":"昨年から、ブログをどうしようかって話をしていて、そのままになっていたのですが、Octopress＋Github Pagesというのがあるらしい","tags":["octopress","misc"],"title":"Octopress始めました","type":"post","url":"/blog/2013/06/01/first-octopress/","weight":0,"wordcount":356},{"date":1367850324,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":500,"kind":"page","lang":"ja","lastmod":1367850324,"objectID":"11d4726484be418849e1f4200ade9535","permalink":"https://blog.johtani.info/blog/2013/05/06/lucene-gosen4-3-0%E3%82%92%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Flucene-solr4-3-0%E4%BB%A5%E4%B8%8A%E3%81%A7%E3%81%AE%E5%88%A9%E7%94%A8%E3%81%8C%E5%8F%AF%E8%83%BD%E3%81%A7%E3%81%99/","publishdate":"2013-05-06T23:25:24+09:00","readingtime":1,"relpermalink":"/blog/2013/05/06/lucene-gosen4-3-0%E3%82%92%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Flucene-solr4-3-0%E4%BB%A5%E4%B8%8A%E3%81%A7%E3%81%AE%E5%88%A9%E7%94%A8%E3%81%8C%E5%8F%AF%E8%83%BD%E3%81%A7%E3%81%99/","section":"post","summary":"Lucene/Solr 4.3.0がリリースされた（LuceneのChanges、SolrのChanges）ので、lucene-gosen 4.3.0をリリースしま","tags":["lucene-gosen"],"title":"lucene-gosen4.3.0をリリースしました。（Lucene/Solr4.3.0以上での利用が可能です）(Jugemより移植)","type":"post","url":"/blog/2013/05/06/lucene-gosen4-3-0%E3%82%92%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Flucene-solr4-3-0%E4%BB%A5%E4%B8%8A%E3%81%A7%E3%81%AE%E5%88%A9%E7%94%A8%E3%81%8C%E5%8F%AF%E8%83%BD%E3%81%A7%E3%81%99/","weight":0,"wordcount":484},{"date":1367592139,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1367592139,"objectID":"db97311c24809f103575d8a7fee19680","permalink":"https://blog.johtani.info/blog/2013/05/03/%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E5%9B%9E%E3%81%97%E3%81%A6%E3%81%BE%E3%81%99%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF%E5%85%A5%E9%96%80%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2013-05-03T23:42:19+09:00","readingtime":6,"relpermalink":"/blog/2013/05/03/%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E5%9B%9E%E3%81%97%E3%81%A6%E3%81%BE%E3%81%99%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF%E5%85%A5%E9%96%80%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"アジャイルな時間管理術 ポモドーロテクニック入門 ポモドーロテクニック入門という本を読みました。 きっかけは、Twitter上で何度か「ポモドーロ","tags":["読書"],"title":"ポモドーロ回してます。（ポモドーロテクニック入門読みました）(Jugemより移植)","type":"post","url":"/blog/2013/05/03/%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E5%9B%9E%E3%81%97%E3%81%A6%E3%81%BE%E3%81%99%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF%E5%85%A5%E9%96%80%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":2600},{"date":1366856040,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":3100,"kind":"page","lang":"ja","lastmod":1366856040,"objectID":"286a9a4ee373398d7d2c93862c5f6661","permalink":"https://blog.johtani.info/blog/2013/04/25/solr4-3-0%E3%81%AEchanges%E3%82%92%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/","publishdate":"2013-04-25T11:14:00+09:00","readingtime":7,"relpermalink":"/blog/2013/04/25/solr4-3-0%E3%81%AEchanges%E3%82%92%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/","section":"post","summary":"まだ、Vote公開されていない、Solr 4.3（2013/04/25 11:00現在）ですが、 ひさびさに訳してみた。詳細まで追っていないので、","tags":["solr"],"title":"Solr4.3.0のChangesを訳してみた。(Jugemより移植)","type":"post","url":"/blog/2013/04/25/solr4-3-0%E3%81%AEchanges%E3%82%92%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/","weight":0,"wordcount":3038},{"date":1366786800,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1366786800,"objectID":"99f5219da22485d0872a2529599c8440","permalink":"https://blog.johtani.info/blog/2013/04/24/lucene-4-3-0%E3%81%AEchanges%E3%81%AB%E3%81%82%E3%82%8Bchanges-in-backwards-compatibility-policy%E3%81%8C%E6%B0%97%E3%81%AB%E3%81%AA%E3%81%A3%E3%81%9F%E3%81%AE%E3%81%A7%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/","publishdate":"2013-04-24T16:00:00+09:00","readingtime":3,"relpermalink":"/blog/2013/04/24/lucene-4-3-0%E3%81%AEchanges%E3%81%AB%E3%81%82%E3%82%8Bchanges-in-backwards-compatibility-policy%E3%81%8C%E6%B0%97%E3%81%AB%E3%81%AA%E3%81%A3%E3%81%9F%E3%81%AE%E3%81%A7%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/","section":"post","summary":"現在、RC3のVoteをやっている最中（2013/04/24 16:00時点）で、まだリリースされていない、4.3.0についてです。 開発者ML","tags":["solr"],"title":"Lucene 4.3.0のChangesにあるChanges in backwards compatibility policyが気になったので訳してみた。(Jugemより移植)","type":"post","url":"/blog/2013/04/24/lucene-4-3-0%E3%81%AEchanges%E3%81%AB%E3%81%82%E3%82%8Bchanges-in-backwards-compatibility-policy%E3%81%8C%E6%B0%97%E3%81%AB%E3%81%AA%E3%81%A3%E3%81%9F%E3%81%AE%E3%81%A7%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/","weight":0,"wordcount":1286},{"date":1366717542,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1366717542,"objectID":"36ff37ced0d3211db95a5ac0daac0c35","permalink":"https://blog.johtani.info/blog/2013/04/23/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass--tecomp--vol-2-%E4%BA%BA%E6%B0%97web%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9%E6%95%99%E3%81%88%E3%81%BE%E3%81%99%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2013-04-23T20:45:42+09:00","readingtime":3,"relpermalink":"/blog/2013/04/23/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass--tecomp--vol-2-%E4%BA%BA%E6%B0%97web%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9%E6%95%99%E3%81%88%E3%81%BE%E3%81%99%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"第2回目も参加しました。 とりあえずメモ。 自分には欠けてる視点の話しなので面白かった。 ちょっと寒かったなぁ。 エンジニアのためのスキルアップ勉強","tags":["勉強会"],"title":"エンジニアのためのスキルアップ勉強会『Tech Compass』 #tecomp ― Vol.2 「人気Webサービスの作り方教えます！」に参加しました。(Jugemより移植)","type":"post","url":"/blog/2013/04/23/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass--tecomp--vol-2-%E4%BA%BA%E6%B0%97web%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9%E6%95%99%E3%81%88%E3%81%BE%E3%81%99%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":1439},{"date":1366639648,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2100,"kind":"page","lang":"ja","lastmod":1366639648,"objectID":"1ca04e5339ed1826c12fe61fd984e949","permalink":"https://blog.johtani.info/blog/2013/04/22/jira%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E3%82%92s3%E3%81%B8%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97/","publishdate":"2013-04-22T23:07:28+09:00","readingtime":5,"relpermalink":"/blog/2013/04/22/jira%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E3%82%92s3%E3%81%B8%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97/","section":"post","summary":"だいぶ、ブログを書くペースが落ちてきてて、危機感を感じている今日このごろです。。。 今回は、個人的に利用しているJIRAのバックアップについて","tags":["備忘録"],"title":"JIRAのデータをS3へバックアップ(Jugemより移植)","type":"post","url":"/blog/2013/04/22/jira%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E3%82%92s3%E3%81%B8%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97/","weight":0,"wordcount":2096},{"date":1365128443,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2100,"kind":"page","lang":"ja","lastmod":1365128443,"objectID":"73d2fce4efa52675b35a11ee97bc2db0","permalink":"https://blog.johtani.info/blog/2013/04/05/heroku-meetup--8-treasuredata--waza-report-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/","publishdate":"2013-04-05T11:20:43+09:00","readingtime":5,"relpermalink":"/blog/2013/04/05/heroku-meetup--8-treasuredata--waza-report-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/","section":"post","summary":"HerokuではじめるRailsプログラミング入門 heroku気になってるのに使ってなくて、TDのアカウント作ってデータアップしてない軟弱者","tags":["勉強会"],"title":"Heroku Meetup #8 TreasureData + Waza Report!! に参加しました。#herokujp(Jugemより移植)","type":"post","url":"/blog/2013/04/05/heroku-meetup--8-treasuredata--waza-report-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/","weight":0,"wordcount":2020},{"date":1364300160,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":5000,"kind":"page","lang":"ja","lastmod":1364300160,"objectID":"26d0c0d8c465087cf160a3bdc479f2b4","permalink":"https://blog.johtani.info/blog/2013/03/26/%E7%AC%AC10%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/","publishdate":"2013-03-26T21:16:00+09:00","readingtime":10,"relpermalink":"/blog/2013/03/26/%E7%AC%AC10%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/","section":"post","summary":"記念すべき！？第10回のSolr勉強会です。 発表者が無事あつまり（本当にありがとうございました！）、今回も盛況な感じでほぼ満員でした。 ツイー","tags":["勉強会"],"title":"第10回Solr勉強会を主催しました。#SolrJP(Jugemより移植)","type":"post","url":"/blog/2013/03/26/%E7%AC%AC10%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/","weight":0,"wordcount":4937},{"date":1363765380,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1363765380,"objectID":"f5f28f42ad234b4389af4cbea54ff60d","permalink":"https://blog.johtani.info/blog/2013/03/20/elasticsearch-analysis-kuromoji%E3%81%A7%E3%83%A6%E3%83%BC%E3%82%B6%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%88%A9%E7%94%A8%E6%96%B9%E6%B3%95/","publishdate":"2013-03-20T16:43:00+09:00","readingtime":3,"relpermalink":"/blog/2013/03/20/elasticsearch-analysis-kuromoji%E3%81%A7%E3%83%A6%E3%83%BC%E3%82%B6%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%88%A9%E7%94%A8%E6%96%B9%E6%B3%95/","section":"post","summary":"なんか、とても久しぶりにイベント参加メモ以外の投稿です。 elastic searchのMLを見てたら、KuromojiのAnalyzerを使うときにユーザ","tags":["elasticsearch"],"title":"elasticsearch-analysis-kuromojiでユーザ辞書の利用方法(Jugemより移植)","type":"post","url":"/blog/2013/03/20/elasticsearch-analysis-kuromoji%E3%81%A7%E3%83%A6%E3%83%BC%E3%82%B6%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%88%A9%E7%94%A8%E6%96%B9%E6%B3%95/","weight":0,"wordcount":1211},{"date":1363692480,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1363692480,"objectID":"5412fb82160d0f6093e4b6670f505c13","permalink":"https://blog.johtani.info/blog/2013/03/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass%E7%AB%B9%E6%A9%8B--vol1-%E3%82%B9%E3%83%9E%E3%83%9B%E6%99%82%E4%BB%A3%E5%88%B0%E6%9D%A5%E3%81%93%E3%81%AE%E5%85%88%E7%94%9F%E3%81%8D%E3%81%AE%E3%81%93%E3%82%8B%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%A8%E3%81%AF%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-tecomp/","publishdate":"2013-03-19T20:28:00+09:00","readingtime":3,"relpermalink":"/blog/2013/03/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass%E7%AB%B9%E6%A9%8B--vol1-%E3%82%B9%E3%83%9E%E3%83%9B%E6%99%82%E4%BB%A3%E5%88%B0%E6%9D%A5%E3%81%93%E3%81%AE%E5%85%88%E7%94%9F%E3%81%8D%E3%81%AE%E3%81%93%E3%82%8B%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%A8%E3%81%AF%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-tecomp/","section":"post","summary":"久々にブログ＋イベント参加です。 知り合いが開催＋出演したので参加してみました。 「スマホ」ってキーワードはあまりなかったけど、面白かったです。","tags":["勉強会"],"title":"エンジニアのためのスキルアップ勉強会『Tech Compass』＠竹橋 ― Vol1 「スマホ時代到来、この先生きのこるエンジニアとは！？」に参加しました。#tecomp(Jugemより移植)","type":"post","url":"/blog/2013/03/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass%E7%AB%B9%E6%A9%8B--vol1-%E3%82%B9%E3%83%9E%E3%83%9B%E6%99%82%E4%BB%A3%E5%88%B0%E6%9D%A5%E3%81%93%E3%81%AE%E5%85%88%E7%94%9F%E3%81%8D%E3%81%AE%E3%81%93%E3%82%8B%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%A8%E3%81%AF%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-tecomp/","weight":0,"wordcount":1412},{"date":1360687980,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1360687980,"objectID":"b051fd352847c06e748b345e8ed0738b","permalink":"https://blog.johtani.info/blog/2013/02/13/xperia-z%E8%B2%B7%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2013-02-13T01:53:00+09:00","readingtime":4,"relpermalink":"/blog/2013/02/13/xperia-z%E8%B2%B7%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"技術ブログから離れていってますが。。。 Xperia Zを購入しました。 前に使っていたのはXperia arcになります。 もうすぐ２年だったのですが、容量不","tags":["備忘録"],"title":"Xperia Z買いました(Jugemより移植)","type":"post","url":"/blog/2013/02/13/xperia-z%E8%B2%B7%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":1712},{"date":1358783400,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":4000,"kind":"page","lang":"ja","lastmod":1358783400,"objectID":"bf4f86812812dab8d39db9aaefe94a78","permalink":"https://blog.johtani.info/blog/2013/01/22/hadoop-conference-japan-2013-winter%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hcj13w/","publishdate":"2013-01-22T00:50:00+09:00","readingtime":8,"relpermalink":"/blog/2013/01/22/hadoop-conference-japan-2013-winter%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hcj13w/","section":"post","summary":"金曜日に引き続き、イベントに参加して来ました。（仕事。。。これも仕事だよ。） 「Hadoop Conference Japan 2013 Winter」です。 普段、Hadoopを触る","tags":["勉強会"],"title":"Hadoop Conference Japan 2013 Winterに参加しました。#hcj13w(Jugemより移植)","type":"post","url":"/blog/2013/01/22/hadoop-conference-japan-2013-winter%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hcj13w/","weight":0,"wordcount":3960},{"date":1358600940,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1358600940,"objectID":"322264a17ef7182eb1475bd2eaebc2eb","permalink":"https://blog.johtani.info/blog/2013/01/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88cross-2013%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%8A%E6%89%8B%E4%BC%9D%E3%81%84%E3%83%A2%E3%83%87%E3%83%AC%E3%83%BC%E3%82%BF%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--cross2013/","publishdate":"2013-01-19T22:09:00+09:00","readingtime":6,"relpermalink":"/blog/2013/01/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88cross-2013%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%8A%E6%89%8B%E4%BC%9D%E3%81%84%E3%83%A2%E3%83%87%E3%83%AC%E3%83%BC%E3%82%BF%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--cross2013/","section":"post","summary":"1/18（金）に開催された、エンジニアサポートCROSS 2013で「検索CROSS」セッションのセッションオーナー（モデレータ）をやって来ま","tags":["勉強会"],"title":"エンジニアサポートCROSS 2013に参加（＋お手伝い＋モデレータ）しました #cross2013(Jugemより移植)","type":"post","url":"/blog/2013/01/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88cross-2013%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%8A%E6%89%8B%E4%BC%9D%E3%81%84%E3%83%A2%E3%83%87%E3%83%AC%E3%83%BC%E3%82%BF%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--cross2013/","weight":0,"wordcount":2560},{"date":1358267340,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":500,"kind":"page","lang":"ja","lastmod":1358267340,"objectID":"20110c8f8da8304b6d9d3c2845a38128","permalink":"https://blog.johtani.info/blog/2013/01/16/%E3%81%84%E3%81%BE%E3%81%95%E3%82%89%E3%81%A7%E3%81%99%E3%81%8Ccross-2013%E3%81%A7%E6%A4%9C%E7%B4%A2cross%E3%81%A8%E3%81%84%E3%81%86%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E6%8B%85%E5%BD%93%E3%81%97%E3%81%BE%E3%81%99/","publishdate":"2013-01-16T01:29:00+09:00","readingtime":1,"relpermalink":"/blog/2013/01/16/%E3%81%84%E3%81%BE%E3%81%95%E3%82%89%E3%81%A7%E3%81%99%E3%81%8Ccross-2013%E3%81%A7%E6%A4%9C%E7%B4%A2cross%E3%81%A8%E3%81%84%E3%81%86%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E6%8B%85%E5%BD%93%E3%81%97%E3%81%BE%E3%81%99/","section":"post","summary":"いまさら感満載ですが、今週の金曜日(1/18)に開催されるCROSS 2013というイベントで「検索CROSS」のセッションを担当することにな","tags":["勉強会"],"title":"いまさらですが、CROSS 2013で検索CROSSというセッションを担当します(Jugemより移植)","type":"post","url":"/blog/2013/01/16/%E3%81%84%E3%81%BE%E3%81%95%E3%82%89%E3%81%A7%E3%81%99%E3%81%8Ccross-2013%E3%81%A7%E6%A4%9C%E7%B4%A2cross%E3%81%A8%E3%81%84%E3%81%86%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E6%8B%85%E5%BD%93%E3%81%97%E3%81%BE%E3%81%99/","weight":0,"wordcount":436},{"date":1357658880,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1357658880,"objectID":"992a00c30242b6217243f3c387ea18b7","permalink":"https://blog.johtani.info/blog/2013/01/09/%E3%82%B3%E3%83%BC%E3%83%89%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AA%E3%82%B7%E3%83%86%E3%82%A3%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9Fkindle-paperwhite%E3%81%AE%E4%BD%BF%E3%81%84%E5%8B%9D%E6%89%8B%E3%81%AE%E7%A2%BA%E8%AA%8D%E3%82%82%E5%85%BC%E3%81%AD%E3%81%A6/","publishdate":"2013-01-09T00:28:00+09:00","readingtime":4,"relpermalink":"/blog/2013/01/09/%E3%82%B3%E3%83%BC%E3%83%89%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AA%E3%82%B7%E3%83%86%E3%82%A3%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9Fkindle-paperwhite%E3%81%AE%E4%BD%BF%E3%81%84%E5%8B%9D%E6%89%8B%E3%81%AE%E7%A2%BA%E8%AA%8D%E3%82%82%E5%85%BC%E3%81%AD%E3%81%A6/","section":"post","summary":"年末から年始にかけて、「コード・シンプリシティ」を読みました。 先日の記事にも書きましたが、Kindle paperwhiteを思いかけず入手で","tags":["読書"],"title":"「コード・シンプリシティ」を読みました。（Kindle paperwhiteの使い勝手の確認も兼ねて）(Jugemより移植)","type":"post","url":"/blog/2013/01/09/%E3%82%B3%E3%83%BC%E3%83%89%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AA%E3%82%B7%E3%83%86%E3%82%A3%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9Fkindle-paperwhite%E3%81%AE%E4%BD%BF%E3%81%84%E5%8B%9D%E6%89%8B%E3%81%AE%E7%A2%BA%E8%AA%8D%E3%82%82%E5%85%BC%E3%81%AD%E3%81%A6/","weight":0,"wordcount":1537},{"date":1356908460,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1356908460,"objectID":"4c08b67e0c1fdeef50b1fdcc32cdcee2","permalink":"https://blog.johtani.info/blog/2012/12/31/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A02012/","publishdate":"2012-12-31T08:01:00+09:00","readingtime":6,"relpermalink":"/blog/2012/12/31/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A02012/","section":"post","summary":"書こうと思いながら、気づいたら大晦日。 よくないですね、思いついた時に書かないと。 昨年も書いたので、昨年書いた抱負から振り返りをと。 Mongo","tags":["備忘録"],"title":"今年の振り返りと来年の抱負（2012）(Jugemより移植)","type":"post","url":"/blog/2012/12/31/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A02012/","weight":0,"wordcount":2557},{"date":1356002280,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1356002280,"objectID":"4a30eeb083acec8460150068ba0c6743","permalink":"https://blog.johtani.info/blog/2012/12/20/jira%E3%81%AEdb%E7%A7%BB%E8%A1%8Chsqldb%E3%81%8B%E3%82%89postgresql%E3%81%B8-augj/","publishdate":"2012-12-20T20:18:00+09:00","readingtime":6,"relpermalink":"/blog/2012/12/20/jira%E3%81%AEdb%E7%A7%BB%E8%A1%8Chsqldb%E3%81%8B%E3%82%89postgresql%E3%81%B8-augj/","section":"post","summary":"Atlassian Advent Calendar 2012の20日目。（急遽参戦） （某イケメンにMT（改変リツイート）されたので書いてみました） 久々に、勉強会以外のエントリです。（So","tags":["JIRA"],"title":"JIRAのDB移行（HSQLDBからPostgreSQLへ）#augj(Jugemより移植)","type":"post","url":"/blog/2012/12/20/jira%E3%81%AEdb%E7%A7%BB%E8%A1%8Chsqldb%E3%81%8B%E3%82%89postgresql%E3%81%B8-augj/","weight":0,"wordcount":2558},{"date":1355228520,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":3000,"kind":"page","lang":"ja","lastmod":1355228520,"objectID":"898d25a2ab9c0ba1fa9bad462405e475","permalink":"https://blog.johtani.info/blog/2012/12/11/%E7%AC%AC%E4%B8%80%E5%9B%9E-jetbrains%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97--jbugj-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-12-11T21:22:00+09:00","readingtime":6,"relpermalink":"/blog/2012/12/11/%E7%AC%AC%E4%B8%80%E5%9B%9E-jetbrains%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97--jbugj-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"イケメンが主催した「第一回 JetBrainsユーザーグループ #jbugj」に参加してきました。 いろんな製品があるんだなぁと。入り口には良いイ","tags":["勉強会"],"title":"第一回 JetBrainsユーザーグループ #jbugj に参加してきました(Jugemより移植)","type":"post","url":"/blog/2012/12/11/%E7%AC%AC%E4%B8%80%E5%9B%9E-jetbrains%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97--jbugj-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":2992},{"date":1354122000,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1354122000,"objectID":"e01e01d18582c7f69e1b0db7e1b111a0","permalink":"https://blog.johtani.info/blog/2012/11/29/dsirnlp-3-5%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Femacs%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80%E3%82%92%E9%A0%82%E3%81%84%E3%81%A1%E3%82%83%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-11-29T02:00:00+09:00","readingtime":6,"relpermalink":"/blog/2012/11/29/dsirnlp-3-5%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Femacs%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80%E3%82%92%E9%A0%82%E3%81%84%E3%81%A1%E3%82%83%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"ヒカリエに行ってみたいという不純な理由で参加してきました。 新しいということもあり、おしゃれで綺麗なカフェでした。 入り口にはおっきな人形も立っ","tags":["勉強会"],"title":"#DSIRNLP 3.5に参加しました。＆「Emacs実践入門」を頂いちゃいました！(Jugemより移植)","type":"post","url":"/blog/2012/11/29/dsirnlp-3-5%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Femacs%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80%E3%82%92%E9%A0%82%E3%81%84%E3%81%A1%E3%82%83%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":2682},{"date":1353923040,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":3800,"kind":"page","lang":"ja","lastmod":1353923040,"objectID":"7e23419e4fc69b5b533815681c9bb1a9","permalink":"https://blog.johtani.info/blog/2012/11/26/%E7%AC%AC9%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/","publishdate":"2012-11-26T18:44:00+09:00","readingtime":8,"relpermalink":"/blog/2012/11/26/%E7%AC%AC9%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/","section":"post","summary":"第9回Solr勉強会に参加しました。 皆勤賞です！というか、主催者になってしまいました。 まだ不定期の開催になると思いますが、話をされたい方など","tags":["勉強会"],"title":"第9回Solr勉強会を主催しました。#SolrJP(Jugemより移植)","type":"post","url":"/blog/2012/11/26/%E7%AC%AC9%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/","weight":0,"wordcount":3710},{"date":1352477220,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":3800,"kind":"page","lang":"ja","lastmod":1352477220,"objectID":"98c640616f997a323af625e34ba34850","permalink":"https://blog.johtani.info/blog/2012/11/10/aws-%E3%83%93%E3%83%83%E3%82%B0%E3%83%87%E3%83%BC%E3%82%BF%E6%B4%BB%E7%94%A8%E4%BA%8B%E4%BE%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-jawsug/","publishdate":"2012-11-10T01:07:00+09:00","readingtime":8,"relpermalink":"/blog/2012/11/10/aws-%E3%83%93%E3%83%83%E3%82%B0%E3%83%87%E3%83%BC%E3%82%BF%E6%B4%BB%E7%94%A8%E4%BA%8B%E4%BE%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-jawsug/","section":"post","summary":"初目黒（たぶん）で、初Amazonな感じで、流行りの「ビッグデータ」のセミナーに参加してきました。 とりあえず、いつもの自分用のメモを残してお","tags":["勉強会"],"title":"AWS ビッグデータ活用事例セミナーに参加しました。#jawsug(Jugemより移植)","type":"post","url":"/blog/2012/11/10/aws-%E3%83%93%E3%83%83%E3%82%B0%E3%83%87%E3%83%BC%E3%82%BF%E6%B4%BB%E7%94%A8%E4%BA%8B%E4%BE%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-jawsug/","weight":0,"wordcount":3740},{"date":1350031500,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1350031500,"objectID":"922cc71fd28b1dac8f407f1d517f5595","permalink":"https://blog.johtani.info/blog/2012/10/12/lucene-solr-4-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9lucene-gosen%E3%81%AE4-0%E5%AF%BE%E5%BF%9C/","publishdate":"2012-10-12T17:45:00+09:00","readingtime":2,"relpermalink":"/blog/2012/10/12/lucene-solr-4-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9lucene-gosen%E3%81%AE4-0%E5%AF%BE%E5%BF%9C/","section":"post","summary":"##Lucene/Solr 4.0.0リリース ついに、Lucene/Solr4.0.0がリリースされました。 MLで流れていましたが、3年越しのリリースだったようです。","tags":["lucene-gosen"],"title":"Lucene/Solr 4.0.0リリース＆lucene-gosenの4.0対応(Jugemより移植)","type":"post","url":"/blog/2012/10/12/lucene-solr-4-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9lucene-gosen%E3%81%AE4-0%E5%AF%BE%E5%BF%9C/","weight":0,"wordcount":742},{"date":1348650492,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1348650492,"objectID":"43501cdf0de25278a208cbb9aad80012","permalink":"https://blog.johtani.info/blog/2012/09/26/lucid%E3%81%AEgrant-ingersoll%E3%81%95%E3%82%93%E3%81%AE%E8%AC%9B%E6%BC%94%E3%82%92%E8%81%9E%E3%81%84%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-09-26T18:08:12+09:00","readingtime":4,"relpermalink":"/blog/2012/09/26/lucid%E3%81%AEgrant-ingersoll%E3%81%95%E3%82%93%E3%81%AE%E8%AC%9B%E6%BC%94%E3%82%92%E8%81%9E%E3%81%84%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"このイベントにウチダスペクトラムの枠でMahoutのコミッターである、Grant Ingersollさんが講演されるということで、興味があった","tags":["勉強会"],"title":"LucidのGrant Ingersollさんの講演を聞いてきました(Jugemより移植)","type":"post","url":"/blog/2012/09/26/lucid%E3%81%AEgrant-ingersoll%E3%81%95%E3%82%93%E3%81%AE%E8%AC%9B%E6%BC%94%E3%82%92%E8%81%9E%E3%81%84%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":1512},{"date":1348214700,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":4500,"kind":"page","lang":"ja","lastmod":1348214700,"objectID":"89abaa7f21cf788ce4744e3e61173291","permalink":"https://blog.johtani.info/blog/2012/09/21/pfi%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC2012%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pfiopen2012/","publishdate":"2012-09-21T17:05:00+09:00","readingtime":9,"relpermalink":"/blog/2012/09/21/pfi%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC2012%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pfiopen2012/","section":"post","summary":"PFIオープンセミナー2012に参加してきました。 対象から微妙に外れてたり、話の内容についていけるか自信がありませんでしたが、参加してきまし","tags":["勉強会"],"title":"PFIオープンセミナー2012に参加してきました。 #pfiopen2012(Jugemより移植)","type":"post","url":"/blog/2012/09/21/pfi%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC2012%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pfiopen2012/","weight":0,"wordcount":4432},{"date":1346650440,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1346650440,"objectID":"7604edf307a5e96120606c8dda06458f","permalink":"https://blog.johtani.info/blog/2012/09/03/%E3%83%A1%E3%82%A4%E3%83%B3mba%E3%82%92mountain-lion%E3%81%AB%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88%E3%81%84%E3%82%8D%E3%81%84%E3%82%8D%E7%A2%BA%E8%AA%8D%E4%B8%AD/","publishdate":"2012-09-03T14:34:00+09:00","readingtime":6,"relpermalink":"/blog/2012/09/03/%E3%83%A1%E3%82%A4%E3%83%B3mba%E3%82%92mountain-lion%E3%81%AB%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88%E3%81%84%E3%82%8D%E3%81%84%E3%82%8D%E7%A2%BA%E8%AA%8D%E4%B8%AD/","section":"post","summary":"友人にお値打価格で購入したMac miniはMountain Lionにアップデートしてたのですが、手元のAirはまだアップデートしていませんで","tags":["備忘録"],"title":"メインMBAをMountain Lionにアップデート（いろいろ確認中）(Jugemより移植)","type":"post","url":"/blog/2012/09/03/%E3%83%A1%E3%82%A4%E3%83%B3mba%E3%82%92mountain-lion%E3%81%AB%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88%E3%81%84%E3%82%8D%E3%81%84%E3%82%8D%E7%A2%BA%E8%AA%8D%E4%B8%AD/","weight":0,"wordcount":2545},{"date":1345657200,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":3200,"kind":"page","lang":"ja","lastmod":1345657200,"objectID":"775894425f5a7436f56fc5a3b4a2cfaa","permalink":"https://blog.johtani.info/blog/2012/08/23/fluentd-meetup-in-japan--2--fluentd-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-08-23T02:40:00+09:00","readingtime":7,"relpermalink":"/blog/2012/08/23/fluentd-meetup-in-japan--2--fluentd-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"興味をもちつつ、触っていない軟弱者ですが、興味があるので今回も話を聞きに行って来ました。 まずは、作者古橋さんによるFluentdの魅力や次期","tags":["勉強会"],"title":"Fluentd meetup in Japan #2 #fluentd に参加しました。(Jugemより移植)","type":"post","url":"/blog/2012/08/23/fluentd-meetup-in-japan--2--fluentd-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":3130},{"date":1343875800,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2200,"kind":"page","lang":"ja","lastmod":1343875800,"objectID":"8a29f62d1bebfe7b8008d7f264b56b4e","permalink":"https://blog.johtani.info/blog/2012/08/02/twitter-%E5%8B%89%E5%BC%B7%E4%BC%9A--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-08-02T11:50:00+09:00","readingtime":5,"relpermalink":"/blog/2012/08/02/twitter-%E5%8B%89%E5%BC%B7%E4%BC%9A--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"またまた飲みに行って参加してきました。 今回は、Rails、iOSでのTwitter連携の話から、ツイート分析、クライアントアプリの開発の苦労","tags":["勉強会"],"title":"Twitter 勉強会 #twtr_hack に参加しました。(Jugemより移植)","type":"post","url":"/blog/2012/08/02/twitter-%E5%8B%89%E5%BC%B7%E4%BC%9A--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":2168},{"date":1343466900,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2200,"kind":"page","lang":"ja","lastmod":1343466900,"objectID":"7fa2f0877831b4c924438396760f1841","permalink":"https://blog.johtani.info/blog/2012/07/28/python-developers-festa-2012-07%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%97%E3%82%83%E3%81%B9%E3%81%A3%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pyfes/","publishdate":"2012-07-28T18:15:00+09:00","readingtime":5,"relpermalink":"/blog/2012/07/28/python-developers-festa-2012-07%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%97%E3%82%83%E3%81%B9%E3%81%A3%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pyfes/","section":"post","summary":"ということで、ステッカー欲しさ？に勉強中の話を恥ずかしげもなく偉そうにしゃべってきました。 #pyfesは以前から、気になっていたんですが、タ","tags":["勉強会"],"title":"Python Developers Festa 2012.07に参加してしゃべってきました #pyfes(Jugemより移植)","type":"post","url":"/blog/2012/07/28/python-developers-festa-2012-07%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%97%E3%82%83%E3%81%B9%E3%81%A3%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pyfes/","weight":0,"wordcount":2194},{"date":1342177320,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":3300,"kind":"page","lang":"ja","lastmod":1342177320,"objectID":"68a8f34c240a42ab521d2f885f7aa33c","permalink":"https://blog.johtani.info/blog/2012/07/13/partial-update%E3%81%A8copyfield%E3%81%AE%E3%83%90%E3%82%B0solr-4-0-alpha/","publishdate":"2012-07-13T20:02:00+09:00","readingtime":7,"relpermalink":"/blog/2012/07/13/partial-update%E3%81%A8copyfield%E3%81%AE%E3%83%90%E3%82%B0solr-4-0-alpha/","section":"post","summary":"今日はSolr 4.0 ALPHAの興味深い機能があったので紹介です。 数日前に「Solr 4.0: Partial documents update」という記事を見つけました。 Solrには、","tags":["solr"],"title":"Partial UpdateとcopyFieldのバグ【Solr 4.0 ALPHA】(Jugemより移植)","type":"post","url":"/blog/2012/07/13/partial-update%E3%81%A8copyfield%E3%81%AE%E3%83%90%E3%82%B0solr-4-0-alpha/","weight":0,"wordcount":3293},{"date":1342111298,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1342111298,"objectID":"9ac7bb94e60dc30a023ce433de027364","permalink":"https://blog.johtani.info/blog/2012/07/13/mir%E8%BC%AA%E8%AA%AD%E4%BC%9A%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-07-13T01:41:38+09:00","readingtime":2,"relpermalink":"/blog/2012/07/13/mir%E8%BC%AA%E8%AA%AD%E4%BC%9A%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"Modern Information Retrieval: The Concepts and Technology behind Search (2nd Edition) (ACM Press Books) いやぁ、蒸し暑くてなかなか寝れない日がはじまりましたね。（あんまり関係ないですね。。。） Modern Information Retrieval 2nd Editionを","tags":["勉強会"],"title":"MIR輪読会始めました(Jugemより移植)","type":"post","url":"/blog/2012/07/13/mir%E8%BC%AA%E8%AA%AD%E4%BC%9A%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":632},{"date":1341457909,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":200,"kind":"page","lang":"ja","lastmod":1341457909,"objectID":"dcc2e24df32287e89ee3b0f64d617f57","permalink":"https://blog.johtani.info/blog/2012/07/05/lucene-gosen%E3%81%AElucene-solr4-0-alpha%E5%AF%BE%E5%BF%9C/","publishdate":"2012-07-05T12:11:49+09:00","readingtime":1,"relpermalink":"/blog/2012/07/05/lucene-gosen%E3%81%AElucene-solr4-0-alpha%E5%AF%BE%E5%BF%9C/","section":"post","summary":"Lucene/Solrの4.0.0-ALPHAが7/3にリリースされました。 これに伴い、lucene-goenの4xブランチのjarファイル","tags":["lucene-gosen"],"title":"lucene-gosenのLucene/Solr4.0-ALPHA対応(Jugemより移植)","type":"post","url":"/blog/2012/07/05/lucene-gosen%E3%81%AElucene-solr4-0-alpha%E5%AF%BE%E5%BF%9C/","weight":0,"wordcount":187},{"date":1341402000,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":3100,"kind":"page","lang":"ja","lastmod":1341402000,"objectID":"8acc78be63e27e938ee53ec2c0b90c61","permalink":"https://blog.johtani.info/blog/2012/07/04/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--solrjp/","publishdate":"2012-07-04T20:40:00+09:00","readingtime":7,"relpermalink":"/blog/2012/07/04/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--solrjp/","section":"post","summary":"またまた参加しました。いまだ皆勤賞です。 感想などはあとで。とりあえず、メモとったので第一弾です。 ということで、感想です。 まずは、参加人数。 今","tags":["勉強会"],"title":"Solr勉強会第8回に参加しました。 #SolrJP(Jugemより移植)","type":"post","url":"/blog/2012/07/04/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--solrjp/","weight":0,"wordcount":3071},{"date":1340642460,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":4500,"kind":"page","lang":"ja","lastmod":1340642460,"objectID":"9f29c6d9719fc6bc09a2981057642b69","permalink":"https://blog.johtani.info/blog/2012/06/26/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC10%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/","publishdate":"2012-06-26T01:41:00+09:00","readingtime":9,"relpermalink":"/blog/2012/06/26/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC10%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/","section":"post","summary":"Hadoopからはちょっと離れているのに、面白そうなネタなので参加しました。 Data Science Summit、HBaseCon、Hadoop Summitのイ","tags":[],"title":"Hadoopソースコードリーディング第10回に参加しました。#hadoopreading(Jugemより移植)","type":"post","url":"/blog/2012/06/26/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC10%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/","weight":0,"wordcount":4433},{"date":1340028180,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1340028180,"objectID":"d13aa56e27fe71ef40ff153c093ecdf8","permalink":"https://blog.johtani.info/blog/2012/06/18/lucene-gosen%E3%81%AEunidic%E5%AF%BE%E5%BF%9C/","publishdate":"2012-06-18T23:03:00+09:00","readingtime":3,"relpermalink":"/blog/2012/06/18/lucene-gosen%E3%81%AEunidic%E5%AF%BE%E5%BF%9C/","section":"post","summary":"Issue 32で上がってきたlucee-gosenのUniDic対応の最初のパッチを書いたので、ブログに残しておきます。 ###UniDicとは___","tags":["lucene-gosen"],"title":"lucene-gosenのUniDic対応(Jugemより移植)","type":"post","url":"/blog/2012/06/18/lucene-gosen%E3%81%AEunidic%E5%AF%BE%E5%BF%9C/","weight":0,"wordcount":1457},{"date":1339772520,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":4300,"kind":"page","lang":"ja","lastmod":1339772520,"objectID":"9ccda414c322ebcdf875eacbba2e4b7e","permalink":"https://blog.johtani.info/blog/2012/06/16/zipkin%E3%81%AEreadme%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%81%9D%E3%81%AE%EF%BC%92%E6%AE%8B%E3%82%8A/","publishdate":"2012-06-16T00:02:00+09:00","readingtime":9,"relpermalink":"/blog/2012/06/16/zipkin%E3%81%AEreadme%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%81%9D%E3%81%AE%EF%BC%92%E6%AE%8B%E3%82%8A/","section":"post","summary":"「鉄は熱いうちに打て」ということで、残りも勢いでメモ。 まだ、見直しとかしてない状態なのでおかしいところとかありますが。。。 図とか入れるのはま","tags":["Zipkin"],"title":"ZipkinのReadme読んでる（その２、残り）(Jugemより移植)","type":"post","url":"/blog/2012/06/16/zipkin%E3%81%AEreadme%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%81%9D%E3%81%AE%EF%BC%92%E6%AE%8B%E3%82%8A/","weight":0,"wordcount":4255},{"date":1339721820,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1339721820,"objectID":"69f755dd5b9e90a99c3086543790541c","permalink":"https://blog.johtani.info/blog/2012/06/15/zipkin%E3%81%AEreadme%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E5%91%A8%E3%82%8A%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-06-15T09:57:00+09:00","readingtime":3,"relpermalink":"/blog/2012/06/15/zipkin%E3%81%AEreadme%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E5%91%A8%E3%82%8A%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","section":"post","summary":"ZipkinのGithubにあるReadmeを読んでます。 せっかくというか、頭が悪いので読みながら内容をメモ。 まずは、アーキテクチャとトレー","tags":["Zipkin"],"title":"ZipkinのReadmeを読んでる（クライアント周りについて）(Jugemより移植)","type":"post","url":"/blog/2012/06/15/zipkin%E3%81%AEreadme%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E5%91%A8%E3%82%8A%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","weight":0,"wordcount":1402},{"date":1339603740,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1339603740,"objectID":"277f7f2177e2a265a62680ea0158f9b9","permalink":"https://blog.johtani.info/blog/2012/06/14/autogeneratephrasequeries%E3%81%AE%E3%83%87%E3%83%95%E3%82%A9%E3%83%AB%E3%83%88%E5%80%A4%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-06-14T01:09:00+09:00","readingtime":2,"relpermalink":"/blog/2012/06/14/autogeneratephrasequeries%E3%81%AE%E3%83%87%E3%83%95%E3%82%A9%E3%83%AB%E3%83%88%E5%80%A4%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","section":"post","summary":"久々にSolrの話です。 といっても、結構前からの話でして。。。 schema.xmlのfieldTypeの設定に「autoGeneratePh","tags":["solr"],"title":"autoGeneratePhraseQueriesのデフォルト値について(Jugemより移植)","type":"post","url":"/blog/2012/06/14/autogeneratephrasequeries%E3%81%AE%E3%83%87%E3%83%95%E3%82%A9%E3%83%AB%E3%83%88%E5%80%A4%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","weight":0,"wordcount":645},{"date":1339515600,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1339515600,"objectID":"ee48516e57684c5a4c22adccac34be92","permalink":"https://blog.johtani.info/blog/2012/06/13/twitter%E3%81%8C%E5%85%AC%E9%96%8B%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%B3%E3%82%B0%E8%BF%BD%E8%B7%A1%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0zipkin/","publishdate":"2012-06-13T00:40:00+09:00","readingtime":3,"relpermalink":"/blog/2012/06/13/twitter%E3%81%8C%E5%85%AC%E9%96%8B%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%B3%E3%82%B0%E8%BF%BD%E8%B7%A1%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0zipkin/","section":"post","summary":"すでに読まれた方もいるかも知れませんが、気になったのでメモを書いてみようかと。 先週の木曜日にTwitterのエンジニアブログでZipkinと","tags":["OSS"],"title":"Twitterが公開した分散トレーシング（追跡？）システム、Zipkin(Jugemより移植)","type":"post","url":"/blog/2012/06/13/twitter%E3%81%8C%E5%85%AC%E9%96%8B%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%B3%E3%82%B0%E8%BF%BD%E8%B7%A1%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0zipkin/","weight":0,"wordcount":1009},{"date":1339059234,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":300,"kind":"page","lang":"ja","lastmod":1339059234,"objectID":"216db319052b5742fc68862cb2f39905","permalink":"https://blog.johtani.info/blog/2012/06/07/lucene-gosen-2-0-2%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E5%91%A8%E3%82%8A%E3%81%AE%E6%94%B9%E5%96%84%E3%81%AA%E3%81%A9/","publishdate":"2012-06-07T17:53:54+09:00","readingtime":1,"relpermalink":"/blog/2012/06/07/lucene-gosen-2-0-2%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E5%91%A8%E3%82%8A%E3%81%AE%E6%94%B9%E5%96%84%E3%81%AA%E3%81%A9/","section":"post","summary":"lucene-gosenの最新版（2.0.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、@haruy","tags":["lucene-gosen"],"title":"lucene-gosen 2.0.2リリース（リソース周りの改善など）(Jugemより移植)","type":"post","url":"/blog/2012/06/07/lucene-gosen-2-0-2%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E5%91%A8%E3%82%8A%E3%81%AE%E6%94%B9%E5%96%84%E3%81%AA%E3%81%A9/","weight":0,"wordcount":222},{"date":1338913260,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1338913260,"objectID":"cbf9587a8187985725963b8bfc67004d","permalink":"https://blog.johtani.info/blog/2012/06/06/issue32%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A64096%E3%81%AE%E5%A3%81/","publishdate":"2012-06-06T01:21:00+09:00","readingtime":3,"relpermalink":"/blog/2012/06/06/issue32%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A64096%E3%81%AE%E5%A3%81/","section":"post","summary":"昨晩に引き続き、情けない内容のブログになってしまいますが。。。 昨晩、書いた記事の調査をしていた時に気づいた、問題になるケースがあったので調査","tags":["lucene-gosen"],"title":"Issue32について（4096の壁）(Jugemより移植)","type":"post","url":"/blog/2012/06/06/issue32%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A64096%E3%81%AE%E5%A3%81/","weight":0,"wordcount":1454},{"date":1338827340,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1338827340,"objectID":"0dcb6d0f17794bbca56b6cdb9e20b932","permalink":"https://blog.johtani.info/blog/2012/06/05/trunk%E3%81%AE%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E5%B7%AE%E3%81%97%E6%9B%BF%E3%81%88lucene-solr3-6-0%E3%81%A8%E3%83%A9%E3%83%B3%E3%83%80%E3%83%A0%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E5%A4%B1%E6%95%97%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-06-05T01:29:00+09:00","readingtime":3,"relpermalink":"/blog/2012/06/05/trunk%E3%81%AE%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E5%B7%AE%E3%81%97%E6%9B%BF%E3%81%88lucene-solr3-6-0%E3%81%A8%E3%83%A9%E3%83%B3%E3%83%80%E3%83%A0%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E5%A4%B1%E6%95%97%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","section":"post","summary":"久々にlucene-gosenを触っています。 trunkのlibにある、jarファイルが3.5ベースだったので、3.6ベースにしてテストをし","tags":["lucene-gosen"],"title":"trunkのライブラリ差し替え（Lucene/Solr3.6.0）とランダムテストの失敗について(Jugemより移植)","type":"post","url":"/blog/2012/06/05/trunk%E3%81%AE%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E5%B7%AE%E3%81%97%E6%9B%BF%E3%81%88lucene-solr3-6-0%E3%81%A8%E3%83%A9%E3%83%B3%E3%83%80%E3%83%A0%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E5%A4%B1%E6%95%97%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","weight":0,"wordcount":1064},{"date":1338394320,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1338394320,"objectID":"ffdbd6a7d28c9a63976e9eec38cab0f5","permalink":"https://blog.johtani.info/blog/2012/05/31/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%B8%E3%81%AE%E8%B2%A2%E7%8C%AE%E3%81%AE%E3%82%B9%E3%82%B9%E3%83%A1/","publishdate":"2012-05-31T01:12:00+09:00","readingtime":2,"relpermalink":"/blog/2012/05/31/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%B8%E3%81%AE%E8%B2%A2%E7%8C%AE%E3%81%AE%E3%82%B9%E3%82%B9%E3%83%A1/","section":"post","summary":"録画してたEテレのスーパープレゼンテーションを見ててふと書きたくなったので、書いてます。 あとから読んだら恥ずかしくなりそうだけど。。。 「\u0026l","tags":["misc"],"title":"オープンソースへの貢献のススメ(Jugemより移植)","type":"post","url":"/blog/2012/05/31/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%B8%E3%81%AE%E8%B2%A2%E7%8C%AE%E3%81%AE%E3%82%B9%E3%82%B9%E3%83%A1/","weight":0,"wordcount":966},{"date":1338259500,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":5200,"kind":"page","lang":"ja","lastmod":1338259500,"objectID":"de734259dfb9addebe2b226d96b4f744","permalink":"https://blog.johtani.info/blog/2012/05/29/jjug-ccc-2012-spring%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-05-29T11:45:00+09:00","readingtime":11,"relpermalink":"/blog/2012/05/29/jjug-ccc-2012-spring%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"JJUG CCC 2012 Springに参加してきました。 昨年のFallに続き、2回目です。 概要や、タイムテーブルはこちらを御覧ください。 今回は、午後一から参加","tags":["勉強会"],"title":"JJUG CCC 2012 Springに参加してきました。(Jugemより移植)","type":"post","url":"/blog/2012/05/29/jjug-ccc-2012-spring%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":5189},{"date":1337151314,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1337151314,"objectID":"78f002cc3d512ea302c900d1da4dfeec","permalink":"https://blog.johtani.info/blog/2012/05/16/playframework-2-0-java%E3%81%AE%E6%96%B9-%E3%82%92%E8%A7%A6%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%A6%E3%82%8B/","publishdate":"2012-05-16T15:55:14+09:00","readingtime":2,"relpermalink":"/blog/2012/05/16/playframework-2-0-java%E3%81%AE%E6%96%B9-%E3%82%92%E8%A7%A6%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%A6%E3%82%8B/","section":"post","summary":"PlayFramework2.0を触ってみてます。 ちょっとコーディングしたくなったのと、最近のアプリの作成の調査も兼ねて。 まぁ、せっかくなの","tags":["備忘録"],"title":"PlayFramework 2.0(Javaの方)を触ってみてる(Jugemより移植)","type":"post","url":"/blog/2012/05/16/playframework-2-0-java%E3%81%AE%E6%96%B9-%E3%82%92%E8%A7%A6%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%A6%E3%82%8B/","weight":0,"wordcount":949},{"date":1336494900,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":200,"kind":"page","lang":"ja","lastmod":1336494900,"objectID":"c4b418764dca70aebfc965899a3fa7e5","permalink":"https://blog.johtani.info/blog/2012/05/09/lucene-gosen-2-0-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9java7%E5%AF%BE%E5%BF%9C/","publishdate":"2012-05-09T01:35:00+09:00","readingtime":1,"relpermalink":"/blog/2012/05/09/lucene-gosen-2-0-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9java7%E5%AF%BE%E5%BF%9C/","section":"post","summary":"lucene-gosenの最新版（2.0.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、Java7で","tags":["lucene-gosen"],"title":"lucene-gosen 2.0.1リリース（Java7対応）(Jugemより移植)","type":"post","url":"/blog/2012/05/09/lucene-gosen-2-0-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9java7%E5%AF%BE%E5%BF%9C/","weight":0,"wordcount":171},{"date":1335794635,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":600,"kind":"page","lang":"ja","lastmod":1335794635,"objectID":"95c0a5b8a66950b5f22dd82a8dfe0ce5","permalink":"https://blog.johtani.info/blog/2012/04/30/id%E3%81%AE%E7%A7%98%E5%AF%86%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-04-30T23:03:55+09:00","readingtime":2,"relpermalink":"/blog/2012/04/30/id%E3%81%AE%E7%A7%98%E5%AF%86%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"IDの秘密 (丸善ライブラリー―情報研シリーズ) 非常に面白く読めました。 バーコードの話に始まり、最後はシステムで付与するIDに関する考慮点まで","tags":["読書"],"title":"「IDの秘密」を読みました。(Jugemより移植)","type":"post","url":"/blog/2012/04/30/id%E3%81%AE%E7%A7%98%E5%AF%86%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":547},{"date":1334935380,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1334935380,"objectID":"c92c12a28fa219ad1aab60865046ff05","permalink":"https://blog.johtani.info/blog/2012/04/21/heroku-jp-meetup-4%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/","publishdate":"2012-04-21T00:23:00+09:00","readingtime":6,"relpermalink":"/blog/2012/04/21/heroku-jp-meetup-4%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/","section":"post","summary":"WebSolrの話があるらしいというのを嗅ぎつけて、初めてHeroku JP Meetupに参加しました。 herokuもWebSolrも知りつつ、","tags":["勉強会"],"title":"Heroku JP Meetup ＃4に参加しました。#herokujp(Jugemより移植)","type":"post","url":"/blog/2012/04/21/heroku-jp-meetup-4%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/","weight":0,"wordcount":2606},{"date":1334592971,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1334592971,"objectID":"12d1e0cf7396dd33a9bbbca8da4cbc68","permalink":"https://blog.johtani.info/blog/2012/04/17/solr-3-6-0%E3%81%AEcjk%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%81%A8synonymfilterfactory%E3%81%AE%E6%B0%97%E3%81%AB%E3%81%AA%E3%82%8B%E7%82%B9/","publishdate":"2012-04-17T01:16:11+09:00","readingtime":2,"relpermalink":"/blog/2012/04/17/solr-3-6-0%E3%81%AEcjk%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%81%A8synonymfilterfactory%E3%81%AE%E6%B0%97%E3%81%AB%E3%81%AA%E3%82%8B%E7%82%B9/","section":"post","summary":"先日、Solr入門のサンプルschema.xmlの3.6.0対応版の作成をしていて、気になったことがあったので、 メモとして残しておきます。 S","tags":["solr"],"title":"Solr 3.6.0のCJKの設定とSynonymFilterFactoryの気になる点(Jugemより移植)","type":"post","url":"/blog/2012/04/17/solr-3-6-0%E3%81%AEcjk%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%81%A8synonymfilterfactory%E3%81%AE%E6%B0%97%E3%81%AB%E3%81%AA%E3%82%8B%E7%82%B9/","weight":0,"wordcount":958},{"date":1334339880,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1334339880,"objectID":"d77cdb466c5063b99c5aea58e6da4d32","permalink":"https://blog.johtani.info/blog/2012/04/14/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C2%E7%AB%A04%E7%AB%A0/","publishdate":"2012-04-14T02:58:00+09:00","readingtime":3,"relpermalink":"/blog/2012/04/14/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C2%E7%AB%A04%E7%AB%A0/","section":"post","summary":"先日の続きです。「Apache Solr入門」の2章から4章の説明について、Solr3.6.0で動作させる時の変更点を以下に書いていきます。 な","tags":["solr"],"title":"「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（2章～4章）(Jugemより移植)","type":"post","url":"/blog/2012/04/14/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C2%E7%AB%A04%E7%AB%A0/","weight":0,"wordcount":1201},{"date":1334339100,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1334339100,"objectID":"904b07170a0ce481b7491e7fecce4f79","permalink":"https://blog.johtani.info/blog/2012/04/14/lucene-solr-3-6-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9---apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0/","publishdate":"2012-04-14T02:45:00+09:00","readingtime":5,"relpermalink":"/blog/2012/04/14/lucene-solr-3-6-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9---apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0/","section":"post","summary":"以前より、アナウンスしていた、Kuromojiという日本語形態素解析が含まれるLucene/Solr 3.6.0がリリースされました。 以下、各","tags":["solr"],"title":"Lucene/Solr 3.6.0リリース / 「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（1章）(Jugemより移植)","type":"post","url":"/blog/2012/04/14/lucene-solr-3-6-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9---apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0/","weight":0,"wordcount":2331},{"date":1334241069,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1334241069,"objectID":"bed3b7fcc1294e23639057435ac8756a","permalink":"https://blog.johtani.info/blog/2012/04/12/%E3%83%A1%E3%83%A2amazon-cloudsearch%E3%81%8C%E5%87%BA%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F%E3%82%88/","publishdate":"2012-04-12T23:31:09+09:00","readingtime":2,"relpermalink":"/blog/2012/04/12/%E3%83%A1%E3%83%A2amazon-cloudsearch%E3%81%8C%E5%87%BA%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F%E3%82%88/","section":"post","summary":"Twitterでこのブログ流れてきて、気になったので、流し読みして簡単にメモ。 Amazonのサービスでスケールする検索サービスみたい。 主に、","tags":["備忘録"],"title":"【メモ】Amazon CloudSearchが出てきましたよ(Jugemより移植)","type":"post","url":"/blog/2012/04/12/%E3%83%A1%E3%83%A2amazon-cloudsearch%E3%81%8C%E5%87%BA%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F%E3%82%88/","weight":0,"wordcount":683},{"date":1333698660,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":7400,"kind":"page","lang":"ja","lastmod":1333698660,"objectID":"56d5711303378bd333ddb611a53ece94","permalink":"https://blog.johtani.info/blog/2012/04/06/java-one-tokyo-2012-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-javaonejp/","publishdate":"2012-04-06T16:51:00+09:00","readingtime":15,"relpermalink":"/blog/2012/04/06/java-one-tokyo-2012-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-javaonejp/","section":"post","summary":"JavaOne Tokyo 2012に参加してきました。 4/4-4/5の2日間開催されていたのですが、子供が体調を崩してしまい、4/5のみの参加となりました。 4/4","tags":["勉強会"],"title":"Java One Tokyo 2012 に参加しました。#JavaOneJp(Jugemより移植)","type":"post","url":"/blog/2012/04/06/java-one-tokyo-2012-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-javaonejp/","weight":0,"wordcount":7363},{"date":1333552800,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1333552800,"objectID":"c7937b6b4bde2a96191dc31db913e1ab","permalink":"https://blog.johtani.info/blog/2012/04/05/lucene-gosen%E3%81%AEjava7%E3%81%A7%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E5%A4%B1%E6%95%97%E5%95%8F%E9%A1%8C%E3%81%AE%E5%AF%BE%E5%BF%9C/","publishdate":"2012-04-05T00:20:00+09:00","readingtime":2,"relpermalink":"/blog/2012/04/05/lucene-gosen%E3%81%AEjava7%E3%81%A7%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E5%A4%B1%E6%95%97%E5%95%8F%E9%A1%8C%E3%81%AE%E5%AF%BE%E5%BF%9C/","section":"post","summary":"先日、2.0.0リリースの記事にも記載しましたが、Java7でテストケースが失敗する問題がありました。 @haruyamaさんと@hideak","tags":["lucene-gosen"],"title":"lucene-gosenのJava7でのテスト失敗問題の対応(Jugemより移植)","type":"post","url":"/blog/2012/04/05/lucene-gosen%E3%81%AEjava7%E3%81%A7%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E5%A4%B1%E6%95%97%E5%95%8F%E9%A1%8C%E3%81%AE%E5%AF%BE%E5%BF%9C/","weight":0,"wordcount":840},{"date":1333362120,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1333362120,"objectID":"06731164684f90f33ce4017eca9d8ec1","permalink":"https://blog.johtani.info/blog/2012/04/02/%E9%87%8D%E8%A6%81lucene-gosen-2-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2012-04-02T19:22:00+09:00","readingtime":3,"relpermalink":"/blog/2012/04/02/%E9%87%8D%E8%A6%81lucene-gosen-2-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","section":"post","summary":"先日、宣言したとおり、lucene-gosenのパッケージ名＋クラス名の変更を行ったlucene-gosen 2.0.0をリリースしました。 Lucene/Solr","tags":["lucene-gosen"],"title":"【重要】lucene-gosen 2.0.0リリース(Jugemより移植)","type":"post","url":"/blog/2012/04/02/%E9%87%8D%E8%A6%81lucene-gosen-2-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","weight":0,"wordcount":1096},{"date":1332783540,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1332783540,"objectID":"f8327953a0f0b80011b939111807999a","permalink":"https://blog.johtani.info/blog/2012/03/27/%E9%87%8D%E8%A6%81lucene-gosen%E3%81%AE%E6%AC%A1%E6%9C%9F%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-03-27T02:39:00+09:00","readingtime":2,"relpermalink":"/blog/2012/03/27/%E9%87%8D%E8%A6%81lucene-gosen%E3%81%AE%E6%AC%A1%E6%9C%9F%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","section":"post","summary":"lucene-gosenを利用して頂いてる皆様に連絡があります。 連絡事項 次期lucene-gosenのリリース（2.0を予定）にて、org.","tags":["lucene-gosen"],"title":"【重要】lucene-gosenの次期リリースについて(Jugemより移植)","type":"post","url":"/blog/2012/03/27/%E9%87%8D%E8%A6%81lucene-gosen%E3%81%AE%E6%AC%A1%E6%9C%9F%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","weight":0,"wordcount":952},{"date":1332618420,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1200,"kind":"page","lang":"ja","lastmod":1332618420,"objectID":"8b76101d185700a8efed148d8722d926","permalink":"https://blog.johtani.info/blog/2012/03/25/%E4%B9%85%E3%80%85%E3%81%ABmac-mini%E3%81%AE%E3%81%93%E3%81%A8%E3%81%A7%E3%82%82/","publishdate":"2012-03-25T04:47:00+09:00","readingtime":3,"relpermalink":"/blog/2012/03/25/%E4%B9%85%E3%80%85%E3%81%ABmac-mini%E3%81%AE%E3%81%93%E3%81%A8%E3%81%A7%E3%82%82/","section":"post","summary":"子供の寝かしつけしてたら、寝かしつけされてしまって、２時に目が覚めてしまいました。 TSUTAYAでCD借りてきてウォークマンに入れようと思っ","tags":["備忘録"],"title":"久々にMac Miniのことでも(Jugemより移植)","type":"post","url":"/blog/2012/03/25/%E4%B9%85%E3%80%85%E3%81%ABmac-mini%E3%81%AE%E3%81%93%E3%81%A8%E3%81%A7%E3%82%82/","weight":0,"wordcount":1140},{"date":1332343680,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1332343680,"objectID":"16b3c9445539e9274282a612dea354c2","permalink":"https://blog.johtani.info/blog/2012/03/22/%E7%AC%AC5%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%B8%8B%E8%B0%B7--twtr_hack/","publishdate":"2012-03-22T00:28:00+09:00","readingtime":6,"relpermalink":"/blog/2012/03/22/%E7%AC%AC5%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%B8%8B%E8%B0%B7--twtr_hack/","section":"post","summary":"はい。またまた、Twitter API勉強会に参加してきました。（今回から開催回数の記載がなくなった？） 今回は直前でタイムテーブルが変わってし","tags":["勉強会"],"title":"第5回 Twitter API勉強会 @渋谷 #twtr_hack(Jugemより移植)","type":"post","url":"/blog/2012/03/22/%E7%AC%AC5%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%B8%8B%E8%B0%B7--twtr_hack/","weight":0,"wordcount":2547},{"date":1332253920,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1332253920,"objectID":"ee623aaa99b429863f89da313fffed97","permalink":"https://blog.johtani.info/blog/2012/03/20/%E8%87%AA%E5%88%86%E3%81%AE%E5%B0%8F%E3%81%95%E3%81%AA%E7%AE%B1%E3%81%8B%E3%82%89%E8%84%B1%E5%87%BA%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-03-20T23:32:00+09:00","readingtime":2,"relpermalink":"/blog/2012/03/20/%E8%87%AA%E5%88%86%E3%81%AE%E5%B0%8F%E3%81%95%E3%81%AA%E7%AE%B1%E3%81%8B%E3%82%89%E8%84%B1%E5%87%BA%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"TLで面白いと見かけて、Amazonで買ってしまいました。 SEやってるのに、つい最近Amazonを使い始めた軟弱者です。 それにしてもAmaz","tags":["読書"],"title":"「自分の小さな「箱」から脱出する方法」を読みました。(Jugemより移植)","type":"post","url":"/blog/2012/03/20/%E8%87%AA%E5%88%86%E3%81%AE%E5%B0%8F%E3%81%95%E3%81%AA%E7%AE%B1%E3%81%8B%E3%82%89%E8%84%B1%E5%87%BA%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":732},{"date":1331652421,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1331652421,"objectID":"116c9be6d760b4befa6d51ce9e96604c","permalink":"https://blog.johtani.info/blog/2012/03/14/scala%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-03-14T00:27:01+09:00","readingtime":2,"relpermalink":"/blog/2012/03/14/scala%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"えーと、ブログ更新してないなぁとふと思ったので。 １年前くらいからずーっと、つぶやいてましたが、やっとScalaを始めました。 長かった。。。 と","tags":["Scala"],"title":"Scala始めました(Jugemより移植)","type":"post","url":"/blog/2012/03/14/scala%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":713},{"date":1331230200,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1331230200,"objectID":"4d6c95b0b3ea2ddb30fdd3edf3b82391","permalink":"https://blog.johtani.info/blog/2012/03/09/%E7%AC%AC0%E5%9B%9E-twitter-hack--twtr_hack-%E3%81%AB%E9%81%8A%E3%81%B3%E3%81%AB%E8%A1%8C%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-03-09T03:10:00+09:00","readingtime":4,"relpermalink":"/blog/2012/03/09/%E7%AC%AC0%E5%9B%9E-twitter-hack--twtr_hack-%E3%81%AB%E9%81%8A%E3%81%B3%E3%81%AB%E8%A1%8C%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"森ビルに行ったことなかったので、参加してみました。 あと、最近まともにコーディングしてないので、そのへんを矯正するためにもと思って。 （まぁ、遊","tags":["勉強会"],"title":"第0回 Twitter Hack #twtr_hack に遊びに行きました。(Jugemより移植)","type":"post","url":"/blog/2012/03/09/%E7%AC%AC0%E5%9B%9E-twitter-hack--twtr_hack-%E3%81%AB%E9%81%8A%E3%81%B3%E3%81%AB%E8%A1%8C%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":1734},{"date":1330704840,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1330704840,"objectID":"10eb415a232ad4be7d05c57eb850036c","permalink":"https://blog.johtani.info/blog/2012/03/03/clean-coder%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A0/","publishdate":"2012-03-03T01:14:00+09:00","readingtime":3,"relpermalink":"/blog/2012/03/03/clean-coder%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A0/","section":"post","summary":"Clean Coder プロフェッショナルプログラマへの道 Clean Coderを読みました。 理由はTwitterで「Clean Code」がいい本だと流れてきたためです。","tags":["読書"],"title":"Clean Coderを読んだ(Jugemより移植)","type":"post","url":"/blog/2012/03/03/clean-coder%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A0/","weight":0,"wordcount":1021},{"date":1330186800,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1330186800,"objectID":"627a0c45dd07150343c81d856855590e","permalink":"https://blog.johtani.info/blog/2012/02/26/%E8%A6%AA%E5%AD%90%E3%81%A7%E6%A5%BD%E3%81%97%E3%82%81%E3%82%8B-%E7%B5%B5%E6%9C%AC%E3%81%A7%E8%8B%B1%E8%AA%9E%E3%82%92%E3%81%AF%E3%81%98%E3%82%81%E3%82%8B%E6%9C%AC/","publishdate":"2012-02-26T01:20:00+09:00","readingtime":2,"relpermalink":"/blog/2012/02/26/%E8%A6%AA%E5%AD%90%E3%81%A7%E6%A5%BD%E3%81%97%E3%82%81%E3%82%8B-%E7%B5%B5%E6%9C%AC%E3%81%A7%E8%8B%B1%E8%AA%9E%E3%82%92%E3%81%AF%E3%81%98%E3%82%81%E3%82%8B%E6%9C%AC/","section":"post","summary":"親子で楽しめる 絵本で英語をはじめる本 Twitterでこの本について書かれたブログ記事が流れてきて、購入しました。 最近、英語を身につけておいた","tags":["読書"],"title":"親子で楽しめる 絵本で英語をはじめる本(Jugemより移植)","type":"post","url":"/blog/2012/02/26/%E8%A6%AA%E5%AD%90%E3%81%A7%E6%A5%BD%E3%81%97%E3%82%81%E3%82%8B-%E7%B5%B5%E6%9C%AC%E3%81%A7%E8%8B%B1%E8%AA%9E%E3%82%92%E3%81%AF%E3%81%98%E3%82%81%E3%82%8B%E6%9C%AC/","weight":0,"wordcount":808},{"date":1330015800,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1330015800,"objectID":"966fe8d32b86121f8a465a21b95f7e5c","permalink":"https://blog.johtani.info/blog/2012/02/24/%E7%AC%AC4%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E3%83%8F%E3%83%AA%E3%82%A6%E3%83%83%E3%83%89--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-02-24T01:50:00+09:00","readingtime":6,"relpermalink":"/blog/2012/02/24/%E7%AC%AC4%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E3%83%8F%E3%83%AA%E3%82%A6%E3%83%83%E3%83%89--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"今週も勉強会に参加しました。 @yusukey さんが開催してるTwitter API勉強会です。 前回とは会場が異なりましたが、広くて大画面で良い会場でした。駅","tags":["勉強会"],"title":"第4回 Twitter API勉強会 @デジタルハリウッド #twtr_hack に参加しました。(Jugemより移植)","type":"post","url":"/blog/2012/02/24/%E7%AC%AC4%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E3%83%8F%E3%83%AA%E3%82%A6%E3%83%83%E3%83%89--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":2746},{"date":1329756060,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1329756060,"objectID":"4e7b945feca199bd486653fea1d0e39c","permalink":"https://blog.johtani.info/blog/2012/02/21/lucene-gosen%E3%81%A8synonymfilter%E3%82%92%E5%88%A9%E7%94%A8%E3%81%99%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AE%E6%B3%A8%E6%84%8F%E7%82%B9%E5%95%8F%E9%A1%8C%E7%82%B9%E7%B7%A8/","publishdate":"2012-02-21T01:41:00+09:00","readingtime":4,"relpermalink":"/blog/2012/02/21/lucene-gosen%E3%81%A8synonymfilter%E3%82%92%E5%88%A9%E7%94%A8%E3%81%99%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AE%E6%B3%A8%E6%84%8F%E7%82%B9%E5%95%8F%E9%A1%8C%E7%82%B9%E7%B7%A8/","section":"post","summary":"久々にlucene-gosenの話です。 しかも、あんまり嬉しくない話しです。 すでにissueをアップしていますが、lucene-gosenと","tags":["lucene-gosen"],"title":"lucene-gosenとSynonymFilterを利用するときの注意点（問題点編）(Jugemより移植)","type":"post","url":"/blog/2012/02/21/lucene-gosen%E3%81%A8synonymfilter%E3%82%92%E5%88%A9%E7%94%A8%E3%81%99%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AE%E6%B3%A8%E6%84%8F%E7%82%B9%E5%95%8F%E9%A1%8C%E7%82%B9%E7%B7%A8/","weight":0,"wordcount":1973},{"date":1328716980,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":3300,"kind":"page","lang":"ja","lastmod":1328716980,"objectID":"fa16213d24273d386d22332cd01ce774","permalink":"https://blog.johtani.info/blog/2012/02/09/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/","publishdate":"2012-02-09T01:03:00+09:00","readingtime":7,"relpermalink":"/blog/2012/02/09/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/","section":"post","summary":"また、勉強会ログです、すみません。。。 直接業務とは関係ないのですが、今回はリクルートの中野さんが話しをされるというので顔を出してきました。 も","tags":["勉強会"],"title":"Hadoopソースコードリーディング第8回に参加しました。#hadoopreading(Jugemより移植)","type":"post","url":"/blog/2012/02/09/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/","weight":0,"wordcount":3263},{"date":1328367780,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":7700,"kind":"page","lang":"ja","lastmod":1328367780,"objectID":"a2679a7d860a0bfb2645809ed92ce138","permalink":"https://blog.johtani.info/blog/2012/02/05/fluentd-meetup-japan%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-02-05T00:03:00+09:00","readingtime":16,"relpermalink":"/blog/2012/02/05/fluentd-meetup-japan%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"Fluentd meetup in Japanに参加しました。いつも面白そうな話を聞いてばっかりなので、役に立つためにスタッフとしても参加してみました。 まずは、会場が綺麗","tags":["勉強会"],"title":"Fluentd Meetup Japanに参加しました。(Jugemより移植)","type":"post","url":"/blog/2012/02/05/fluentd-meetup-japan%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":7610},{"date":1327596641,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1327596641,"objectID":"58e83fb33c120db338132d23b9112805","permalink":"https://blog.johtani.info/blog/2012/01/27/%E4%BB%8A%E8%88%88%E5%91%B3%E3%81%8C%E3%81%82%E3%82%8B%E3%81%93%E3%81%A8/","publishdate":"2012-01-27T01:50:41+09:00","readingtime":3,"relpermalink":"/blog/2012/01/27/%E4%BB%8A%E8%88%88%E5%91%B3%E3%81%8C%E3%81%82%E3%82%8B%E3%81%93%E3%81%A8/","section":"post","summary":"昨年末に今年の抱負について書いたのですが、 他にも興味あるものが増えたので備忘録＆公約？を兼ねてブログに書いておきます。 （興味あるものがあれば","tags":["備忘録"],"title":"今興味があること(Jugemより移植)","type":"post","url":"/blog/2012/01/27/%E4%BB%8A%E8%88%88%E5%91%B3%E3%81%8C%E3%81%82%E3%82%8B%E3%81%93%E3%81%A8/","weight":0,"wordcount":1374},{"date":1327593155,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2200,"kind":"page","lang":"ja","lastmod":1327593155,"objectID":"c6dc6e6567d673436ac41ebc8e79a9ec","permalink":"https://blog.johtani.info/blog/2012/01/27/%E3%83%A2%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%8E%E3%83%AD%E3%82%B8%E3%83%BC2012-1%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-01-27T00:52:35+09:00","readingtime":5,"relpermalink":"/blog/2012/01/27/%E3%83%A2%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%8E%E3%83%AD%E3%82%B8%E3%83%BC2012-1%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"ということで、いつものように勉強会に参加したメモです。 http://atnd.org/events/23608 日時 :2012/01/26 19:00 to 22:00 会場 :アカデミーヒルズ(六本木ヒルズ内) 49階（タワーホールA） （港区六","tags":["勉強会"],"title":"モーショノロジー2012#1に参加しました。(Jugemより移植)","type":"post","url":"/blog/2012/01/27/%E3%83%A2%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%8E%E3%83%AD%E3%82%B8%E3%83%BC2012-1%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":2189},{"date":1326988680,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":3100,"kind":"page","lang":"ja","lastmod":1326988680,"objectID":"7198e10ebcf1bb88dc479b5c5b9f2c15","permalink":"https://blog.johtani.info/blog/2012/01/20/mapr%E4%B8%AD%E8%BA%AB%E8%AA%AC%E6%98%8E%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-01-20T00:58:00+09:00","readingtime":7,"relpermalink":"/blog/2012/01/20/mapr%E4%B8%AD%E8%BA%AB%E8%AA%AC%E6%98%8E%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"日時：2012/01/19 18:30-20:30 場所：ベルサール三田Room2シアター Inside MapR デモ＋内部のお話。 ・自己紹介 Susheel Kaushik 元YahooのHadoop系の人。製品","tags":["勉強会"],"title":"MapR中身説明会に参加しました。(Jugemより移植)","type":"post","url":"/blog/2012/01/20/mapr%E4%B8%AD%E8%BA%AB%E8%AA%AC%E6%98%8E%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":3086},{"date":1326941184,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":500,"kind":"page","lang":"ja","lastmod":1326941184,"objectID":"a4462529ab493676987d946019a14945","permalink":"https://blog.johtani.info/blog/2012/01/19/ossaj%E3%81%AE%E3%83%9F%E3%83%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%A7%E8%A9%B1%E3%81%97%E3%82%92%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-01-19T11:46:24+09:00","readingtime":1,"relpermalink":"/blog/2012/01/19/ossaj%E3%81%AE%E3%83%9F%E3%83%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%A7%E8%A9%B1%E3%81%97%E3%82%92%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"お久しぶりです。インフルエンザで一家全滅という最悪の状況に陥っていた我が家でした。 流行してるみたいなのでみなさんも気をつけてください。 さて、","tags":["勉強会"],"title":"OSSAJのミニセミナーで話しをしてきました(Jugemより移植)","type":"post","url":"/blog/2012/01/19/ossaj%E3%81%AE%E3%83%9F%E3%83%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%A7%E8%A9%B1%E3%81%97%E3%82%92%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":400},{"date":1326033660,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":600,"kind":"page","lang":"ja","lastmod":1326033660,"objectID":"f7df7b85af230b2623d3a827b0cbddd2","permalink":"https://blog.johtani.info/blog/2012/01/08/lucene-gosen%E3%81%AElucene-solr4-0%E5%AF%BE%E5%BF%9C%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%9B%B4%E6%96%B0/","publishdate":"2012-01-08T23:41:00+09:00","readingtime":2,"relpermalink":"/blog/2012/01/08/lucene-gosen%E3%81%AElucene-solr4-0%E5%AF%BE%E5%BF%9C%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%9B%B4%E6%96%B0/","section":"post","summary":"先日のSolr勉強会でLucene/Solr4.x系のlucene-gosenについて質問を受けていたのを忘れないように（年越しちゃいました","tags":["lucene-gosen"],"title":"lucene-gosenのLucene/Solr4.0対応ブランチ更新(Jugemより移植)","type":"post","url":"/blog/2012/01/08/lucene-gosen%E3%81%AElucene-solr4-0%E5%AF%BE%E5%BF%9C%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%9B%B4%E6%96%B0/","weight":0,"wordcount":561},{"date":1325735817,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":200,"kind":"page","lang":"ja","lastmod":1325735817,"objectID":"cc573488dec311655890a205aad4fb65","permalink":"https://blog.johtani.info/blog/2012/01/05/%E3%81%82%E3%81%91%E3%81%BE%E3%81%97%E3%81%A6%E3%81%8A%E3%82%81%E3%81%A7%E3%81%A8%E3%81%86%E3%81%94%E3%81%96%E3%81%84%E3%81%BE%E3%81%99%E4%BC%9A%E7%A4%BE%E3%81%AE%E3%83%96%E3%83%AD%E3%82%B0%E6%9B%B4%E6%96%B0/","publishdate":"2012-01-05T12:56:57+09:00","readingtime":1,"relpermalink":"/blog/2012/01/05/%E3%81%82%E3%81%91%E3%81%BE%E3%81%97%E3%81%A6%E3%81%8A%E3%82%81%E3%81%A7%E3%81%A8%E3%81%86%E3%81%94%E3%81%96%E3%81%84%E3%81%BE%E3%81%99%E4%BC%9A%E7%A4%BE%E3%81%AE%E3%83%96%E3%83%AD%E3%82%B0%E6%9B%B4%E6%96%B0/","section":"post","summary":"あけましておめでとうございます。（もう5日ですが。。。） 今年もlucene-gosenを中心に色々と記事を書いていきますので、ツッコミ、コメ","tags":["misc"],"title":"あけましておめでとうございます＋会社のブログ更新(Jugemより移植)","type":"post","url":"/blog/2012/01/05/%E3%81%82%E3%81%91%E3%81%BE%E3%81%97%E3%81%A6%E3%81%8A%E3%82%81%E3%81%A7%E3%81%A8%E3%81%86%E3%81%94%E3%81%96%E3%81%84%E3%81%BE%E3%81%99%E4%BC%9A%E7%A4%BE%E3%81%AE%E3%83%96%E3%83%AD%E3%82%B0%E6%9B%B4%E6%96%B0/","weight":0,"wordcount":190},{"date":1325006100,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1325006100,"objectID":"7164823f504286e3a762ee612ff0a988","permalink":"https://blog.johtani.info/blog/2011/12/28/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A0/","publishdate":"2011-12-28T02:15:00+09:00","readingtime":6,"relpermalink":"/blog/2011/12/28/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A0/","section":"post","summary":"他の方たちよりひと足はやいですが、今年の仕事が終わりました。 せっかくブログを始めたので、振り返りと来年の抱負など書いてみようかなと。 今年の振","tags":["misc"],"title":"今年の振り返りと来年の抱負？(Jugemより移植)","type":"post","url":"/blog/2011/12/28/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A0/","weight":0,"wordcount":2639},{"date":1324485660,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1324485660,"objectID":"da67e2f049b5b6babcf7906b85653399","permalink":"https://blog.johtani.info/blog/2011/12/22/%E7%AC%AC2-1%E5%9B%9E-twitter-api-%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%9D%B1%E4%BA%AC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-22T01:41:00+09:00","readingtime":4,"relpermalink":"/blog/2011/12/22/%E7%AC%AC2-1%E5%9B%9E-twitter-api-%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%9D%B1%E4%BA%AC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"@yusukeyさんにサインをもらう目的で勉強会に参加してきました。前回もらいそびれたのでｗ 残念ながら、まだTwitter APIを触ってない","tags":["勉強会"],"title":"第2.1回 Twitter API 勉強会 @東京に参加しました。(Jugemより移植)","type":"post","url":"/blog/2011/12/22/%E7%AC%AC2-1%E5%9B%9E-twitter-api-%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%9D%B1%E4%BA%AC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":1973},{"date":1324437339,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":200,"kind":"page","lang":"ja","lastmod":1324437339,"objectID":"584b2b145f362098fc5fc1e634d57de5","permalink":"https://blog.johtani.info/blog/2011/12/21/1-2-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-21T12:15:39+09:00","readingtime":1,"relpermalink":"/blog/2011/12/21/1-2-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"lucene-gosenの最新版（1.2.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、特定文字列で","tags":["lucene-gosen"],"title":"1.2.1リリースしました(Jugemより移植)","type":"post","url":"/blog/2011/12/21/1-2-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":140},{"date":1324311660,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1324311660,"objectID":"c6696a730f7498efb66f5ba3a8b35d08","permalink":"https://blog.johtani.info/blog/2011/12/20/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC%EF%BC%97%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F%E7%99%BA%E8%A1%A8%E3%82%82%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-20T01:21:00+09:00","readingtime":6,"relpermalink":"/blog/2011/12/20/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC%EF%BC%97%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F%E7%99%BA%E8%A1%A8%E3%82%82%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"いつものようにSolr勉強会に参加してきました。 皆勤賞を継続中です。（暇人というはなしも。。。） 今回は話しを聞きたいですねぇといったら、いや","tags":["勉強会"],"title":"Solr勉強会第７回に参加しました。（発表もしました）(Jugemより移植)","type":"post","url":"/blog/2011/12/20/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC%EF%BC%97%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F%E7%99%BA%E8%A1%A8%E3%82%82%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":2677},{"date":1323529475,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":4700,"kind":"page","lang":"ja","lastmod":1323529475,"objectID":"16fa0e4aefe18e1446bf6baefd3ba400","permalink":"https://blog.johtani.info/blog/2011/12/11/%E7%AC%AC2%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-11T00:04:35+09:00","readingtime":10,"relpermalink":"/blog/2011/12/11/%E7%AC%AC2%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"ということで、懲りずに#DSIRNLPに参加してきました。 基礎的な部分をおろそかにしたくないけど、TokyoNLPとかWebMiningでは","tags":[],"title":"第2回 データ構造と情報検索と言語処理勉強会に参加しました(Jugemより移植)","type":"post","url":"/blog/2011/12/11/%E7%AC%AC2%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":4675},{"date":1322668828,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1322668828,"objectID":"6e970d0818d58ff2d50c5bf037b1a565","permalink":"https://blog.johtani.info/blog/2011/12/01/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%95%E3%81%A8mac-mini2009late%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E3%81%A8%E3%81%9D%E3%81%AE%E4%BB%96%E3%81%8F%E3%81%A0%E3%82%89%E3%81%AA%E3%81%84%E8%A9%B1/","publishdate":"2011-12-01T01:00:28+09:00","readingtime":4,"relpermalink":"/blog/2011/12/01/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%95%E3%81%A8mac-mini2009late%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E3%81%A8%E3%81%9D%E3%81%AE%E4%BB%96%E3%81%8F%E3%81%A0%E3%82%89%E3%81%AA%E3%81%84%E8%A9%B1/","section":"post","summary":"ひさびさに、MBAのお話です。 セットアップといっても、物理的な方ですね。 以前、ケース（カバー）について記載しました。 この記事にも書いてあった","tags":["備忘録"],"title":"MBAセットアップ備忘録その５とMac Mini（2009late）セットアップとその他くだらない話(Jugemより移植)","type":"post","url":"/blog/2011/12/01/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%95%E3%81%A8mac-mini2009late%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E3%81%A8%E3%81%9D%E3%81%AE%E4%BB%96%E3%81%8F%E3%81%A0%E3%82%89%E3%81%AA%E3%81%84%E8%A9%B1/","weight":0,"wordcount":1993},{"date":1322542620,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1322542620,"objectID":"0ebe78077c8b48410cf52a0bccdff866","permalink":"https://blog.johtani.info/blog/2011/11/29/%E3%81%A9%E3%82%93%E3%81%AA%E6%9C%AC%E3%81%A7%E3%82%82%E5%A4%A7%E9%87%8F%E3%81%AB%E8%AA%AD%E3%82%81%E3%82%8B%E9%80%9F%E8%AA%AD%E3%81%AE%E6%9C%AC%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-29T13:57:00+09:00","readingtime":2,"relpermalink":"/blog/2011/11/29/%E3%81%A9%E3%82%93%E3%81%AA%E6%9C%AC%E3%81%A7%E3%82%82%E5%A4%A7%E9%87%8F%E3%81%AB%E8%AA%AD%E3%82%81%E3%82%8B%E9%80%9F%E8%AA%AD%E3%81%AE%E6%9C%AC%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"どんな本でも大量に読める「速読」の本 Twitterで知り合った方がこの本について書かれていたブログ記事を読んで興味を持ち、読みました。 書籍（","tags":["読書"],"title":"「どんな本でも大量に読める「速読」の本」を読みました(Jugemより移植)","type":"post","url":"/blog/2011/11/29/%E3%81%A9%E3%82%93%E3%81%AA%E6%9C%AC%E3%81%A7%E3%82%82%E5%A4%A7%E9%87%8F%E3%81%AB%E8%AA%AD%E3%82%81%E3%82%8B%E9%80%9F%E8%AA%AD%E3%81%AE%E6%9C%AC%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":832},{"date":1322499060,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":3800,"kind":"page","lang":"ja","lastmod":1322499060,"objectID":"924727b6f380cf3cdfe5650163e92054","permalink":"https://blog.johtani.info/blog/2011/11/29/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC7%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-29T01:51:00+09:00","readingtime":8,"relpermalink":"/blog/2011/11/29/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC7%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"Hadoopソースコードリーディング第7回に参加しました。 いつものごとく、自分用のメモをとっていたので。 第6回（2010/12）には参加して","tags":["勉強会"],"title":"Hadoopソースコードリーディング第7回に参加しました。(Jugemより移植)","type":"post","url":"/blog/2011/11/29/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC7%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":3734},{"date":1322244000,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1322244000,"objectID":"26d48d68b28f927bfebad454658f9425","permalink":"https://blog.johtani.info/blog/2011/11/26/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AElucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0%E3%81%8B%E3%82%894%E7%AB%A0/","publishdate":"2011-11-26T03:00:00+09:00","readingtime":4,"relpermalink":"/blog/2011/11/26/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AElucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0%E3%81%8B%E3%82%894%E7%AB%A0/","section":"post","summary":"先週末から勤労感謝の日まで風邪で寝こんでました。。。 みなさん、朝晩、冷え込みが激しいので風邪には気をつけてください。 季節の言葉も入れたので本","tags":["lucene-gosen"],"title":"「Apache Solr入門」のサンプルのlucene-gosen対応（1章から4章）(Jugemより移植)","type":"post","url":"/blog/2011/11/26/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AElucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0%E3%81%8B%E3%82%894%E7%AB%A0/","weight":0,"wordcount":1906},{"date":1321376880,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":3600,"kind":"page","lang":"ja","lastmod":1321376880,"objectID":"bda9a5da86ec9790262e14f953bbadcb","permalink":"https://blog.johtani.info/blog/2011/11/16/mongodb%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC7%E5%9B%9E%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-16T02:08:00+09:00","readingtime":8,"relpermalink":"/blog/2011/11/16/mongodb%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC7%E5%9B%9E%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"今回は、触ろうと思って触れていないMongoDBの勉強会に行って来ました。 2週連続の渋谷で、さすがに今回は出口をすんなりでれました。 今回は初","tags":["勉強会"],"title":"MongoDB勉強会（第7回）に行って来ました。(Jugemより移植)","type":"post","url":"/blog/2011/11/16/mongodb%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC7%E5%9B%9E%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":3524},{"date":1320822000,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1320822000,"objectID":"cc1a3b2f107510ac664e491d5f2412aa","permalink":"https://blog.johtani.info/blog/2011/11/09/splunk-live%E3%81%AE%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-09T16:00:00+09:00","readingtime":5,"relpermalink":"/blog/2011/11/09/splunk-live%E3%81%AE%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"Solr本の武田さんから教えていただいたSplunkの イベントに行って来ました。 Splunkとは様々な機器のログなどを一箇所に集めてリアルタ","tags":["misc"],"title":"Splunk Live!のイベントに行って来ました。(Jugemより移植)","type":"post","url":"/blog/2011/11/09/splunk-live%E3%81%AE%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":2492},{"date":1320724920,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1320724920,"objectID":"d9c6ab5c6630a4a84e242c5765103d2d","permalink":"https://blog.johtani.info/blog/2011/11/08/lucene-eurocon-2011-barcelona-%E3%81%AE%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%89%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-08T13:02:00+09:00","readingtime":5,"relpermalink":"/blog/2011/11/08/lucene-eurocon-2011-barcelona-%E3%81%AE%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%89%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"最近忘れやすいので、記録しておこうかと。 読んだスライドの簡単な内容と感想です。 ちなみに、スライドの一覧はこちらです。 ※スライドへのリンクはす","tags":["solr"],"title":"Lucene Eurocon 2011 Barcelona のスライド読みました(Jugemより移植)","type":"post","url":"/blog/2011/11/08/lucene-eurocon-2011-barcelona-%E3%81%AE%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%89%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":2336},{"date":1320225060,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1700,"kind":"page","lang":"ja","lastmod":1320225060,"objectID":"7a9609a971a8f31685e88da563eea5ce","permalink":"https://blog.johtani.info/blog/2011/11/02/bookscan%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-02T18:11:00+09:00","readingtime":4,"relpermalink":"/blog/2011/11/02/bookscan%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"Bookscanというサービスがあります。 書籍を電子化（PDF）して原本を破棄してくれるサービスです。 電子書籍にはずっと興味を持っていました","tags":["misc"],"title":"Bookscanを使ってみました(Jugemより移植)","type":"post","url":"/blog/2011/11/02/bookscan%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":1679},{"date":1320043560,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":200,"kind":"page","lang":"ja","lastmod":1320043560,"objectID":"14cf6e75aec1ead888e7101d3d94d28a","permalink":"https://blog.johtani.info/blog/2011/10/31/1-2-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2011-10-31T15:46:00+09:00","readingtime":1,"relpermalink":"/blog/2011/10/31/1-2-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","section":"post","summary":"lucene-gosenの最新版（1.2.0）をリリースしました。 プロジェクトページよりダウンロードが可能です。 新規追加機能についてはこちら","tags":["lucene-gosen"],"title":"1.2.0リリース(Jugemより移植)","type":"post","url":"/blog/2011/10/31/1-2-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","weight":0,"wordcount":113},{"date":1319559120,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2900,"kind":"page","lang":"ja","lastmod":1319559120,"objectID":"14a6d294550c9760aec57ba29682a750","permalink":"https://blog.johtani.info/blog/2011/10/26/%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%A4%96%E9%83%A8%E5%8C%96%E3%81%A8lucene-solr3-4%E5%AF%BE%E5%BF%9C/","publishdate":"2011-10-26T01:12:00+09:00","readingtime":6,"relpermalink":"/blog/2011/10/26/%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%A4%96%E9%83%A8%E5%8C%96%E3%81%A8lucene-solr3-4%E5%AF%BE%E5%BF%9C/","section":"post","summary":"すぐやりますと言いつつ、はや1ヶ月。。。 腰が重い、ダメエンジニアですね。。。 すみませんでした。。。 ようやくtrunkにコミットしました。 すぐ","tags":["lucene-gosen"],"title":"辞書の外部化とLucene/Solr3.4対応(Jugemより移植)","type":"post","url":"/blog/2011/10/26/%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%A4%96%E9%83%A8%E5%8C%96%E3%81%A8lucene-solr3-4%E5%AF%BE%E5%BF%9C/","weight":0,"wordcount":2803},{"date":1318922443,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":3300,"kind":"page","lang":"ja","lastmod":1318922443,"objectID":"5d827a1e8ea70edb11d946b54f076cae","permalink":"https://blog.johtani.info/blog/2011/10/18/jjug-ccc-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-10-18T16:20:43+09:00","readingtime":7,"relpermalink":"/blog/2011/10/18/jjug-ccc-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"JJUG CCC 2011 Fallに参加してきました。 個人的にはかなり久々のJavaのカンファレンスです。（※あくまで「Javaの」という話で。SolrやHad","tags":["備忘録"],"title":"JJUG CCC 2011 Fallに参加してきました。(Jugemより移植)","type":"post","url":"/blog/2011/10/18/jjug-ccc-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":3248},{"date":1318389420,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1700,"kind":"page","lang":"ja","lastmod":1318389420,"objectID":"b9d4f73fa7ca8ef66891554b66b2cded","permalink":"https://blog.johtani.info/blog/2011/10/12/lucene-gosen%E3%81%A7%E6%96%87%E7%AB%A0%E3%81%8B%E3%82%89%E3%82%AD%E3%83%BC%E3%83%AF%E3%83%BC%E3%83%89%E6%8A%BD%E5%87%BA%E3%82%A4%E3%83%AC%E3%82%AE%E3%83%A5%E3%83%A9%E3%83%BC/","publishdate":"2011-10-12T12:17:00+09:00","readingtime":4,"relpermalink":"/blog/2011/10/12/lucene-gosen%E3%81%A7%E6%96%87%E7%AB%A0%E3%81%8B%E3%82%89%E3%82%AD%E3%83%BC%E3%83%AF%E3%83%BC%E3%83%89%E6%8A%BD%E5%87%BA%E3%82%A4%E3%83%AC%E3%82%AE%E3%83%A5%E3%83%A9%E3%83%BC/","section":"post","summary":"昨日、文章から特定の単語（リストあり）を探したいという話を聞き、lucene-gosenでもできるねぇという話になりました。 まぁ、考えてみれ","tags":["lucene-gosen"],"title":"lucene-gosenで文章からキーワード抽出（イレギュラー？）(Jugemより移植)","type":"post","url":"/blog/2011/10/12/lucene-gosen%E3%81%A7%E6%96%87%E7%AB%A0%E3%81%8B%E3%82%89%E3%82%AD%E3%83%BC%E3%83%AF%E3%83%BC%E3%83%89%E6%8A%BD%E5%87%BA%E3%82%A4%E3%83%AC%E3%82%AE%E3%83%A5%E3%83%A9%E3%83%BC/","weight":0,"wordcount":1646},{"date":1317990120,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1317990120,"objectID":"dc962e34780f0374b7eb3d583f6d7eb6","permalink":"https://blog.johtani.info/blog/2011/10/07/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-1%E6%97%A5%E7%9B%AE/","publishdate":"2011-10-07T21:22:00+09:00","readingtime":5,"relpermalink":"/blog/2011/10/07/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-1%E6%97%A5%E7%9B%AE/","section":"post","summary":"ちょっと間があいてしまったが、ようやくIoの1日目を終了。 なれない感じの言語なので苦労しました。 今回もセルフスタディの私の回答が最後の方に記","tags":[],"title":"「7つの言語　7つの世界」 Io 1日目(Jugemより移植)","type":"post","url":"/blog/2011/10/07/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-1%E6%97%A5%E7%9B%AE/","weight":0,"wordcount":2433},{"date":1317968700,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1317968700,"objectID":"de1ab82817c0fb24e591b9a89a82f736","permalink":"https://blog.johtani.info/blog/2011/10/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%94/","publishdate":"2011-10-07T15:25:00+09:00","readingtime":3,"relpermalink":"/blog/2011/10/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%94/","section":"post","summary":"久々に、MBAの備忘録です。 あれから色々入れました。 なので、入れたソフトの一覧を追加。 AIR：TweetDeckをインストールするのに必要だ","tags":["備忘録"],"title":"MBAセットアップ備忘録その４(Jugemより移植)","type":"post","url":"/blog/2011/10/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%94/","weight":0,"wordcount":1476},{"date":1317811380,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1317811380,"objectID":"09677934e13a5d728f00c6ed7c8870a9","permalink":"https://blog.johtani.info/blog/2011/10/05/solr%E3%81%AE%E6%96%B0%E3%81%97%E3%81%84%E7%AE%A1%E7%90%86%E7%94%BB%E9%9D%A2solr4-x-trunk%E7%B3%BB/","publishdate":"2011-10-05T19:43:00+09:00","readingtime":4,"relpermalink":"/blog/2011/10/05/solr%E3%81%AE%E6%96%B0%E3%81%97%E3%81%84%E7%AE%A1%E7%90%86%E7%94%BB%E9%9D%A2solr4-x-trunk%E7%B3%BB/","section":"post","summary":"Lucene/SolrのMLでSolrの管理画面を新しくするというチケットが流れていたのでちょっと触って見ました。 ほんとにちょっと触っただけ","tags":["solr"],"title":"Solrの新しい管理画面（Solr4.x trunk系）(Jugemより移植)","type":"post","url":"/blog/2011/10/05/solr%E3%81%AE%E6%96%B0%E3%81%97%E3%81%84%E7%AE%A1%E7%90%86%E7%94%BB%E9%9D%A2solr4-x-trunk%E7%B3%BB/","weight":0,"wordcount":1508},{"date":1317720720,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":10300,"kind":"page","lang":"ja","lastmod":1317720720,"objectID":"7052598d2355984237d126afea2f6e88","permalink":"https://blog.johtani.info/blog/2011/10/04/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE2/","publishdate":"2011-10-04T18:32:00+09:00","readingtime":21,"relpermalink":"/blog/2011/10/04/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE2/","section":"post","summary":"遅くなりましたが、続きです。 さらに英語力のなさを痛感して凹んでいるところですが、何かの役に立てばと恥を晒すところです。。。 一応、訳してみたの","tags":["solr"],"title":"New SolrCloud Designの翻訳（その2）(Jugemより移植)","type":"post","url":"/blog/2011/10/04/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE2/","weight":0,"wordcount":10212},{"date":1317210300,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":3600,"kind":"page","lang":"ja","lastmod":1317210300,"objectID":"927612b57ba01ca878b2d7edce52a563","permalink":"https://blog.johtani.info/blog/2011/09/28/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE%EF%BC%91/","publishdate":"2011-09-28T20:45:00+09:00","readingtime":8,"relpermalink":"/blog/2011/09/28/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE%EF%BC%91/","section":"post","summary":"ちょっと興味があるので、訳してみました。（Wikiのページはこちら） 更新されているようなので、もとの文章も残しておきます。（ページ下部の続き","tags":["solr"],"title":"New SolrCloud Designの翻訳（その１）(Jugemより移植)","type":"post","url":"/blog/2011/09/28/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE%EF%BC%91/","weight":0,"wordcount":3516},{"date":1317113460,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":10000,"kind":"page","lang":"ja","lastmod":1317113460,"objectID":"97402287d8c6c03f0b63848e17e9d944","permalink":"https://blog.johtani.info/blog/2011/09/27/hadoop-conference-japan-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-09-27T17:51:00+09:00","readingtime":20,"relpermalink":"/blog/2011/09/27/hadoop-conference-japan-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"Hadoop Conference Japan 2011 Fallに行ってきました。 まずは、ユーザ会の方々、運営の方々、発表された方々お疲れ様でした。こんな機会を用意していただき、ありがとう","tags":["hadoop"],"title":"Hadoop Conference Japan 2011 Fallに参加してきました。(Jugemより移植)","type":"post","url":"/blog/2011/09/27/hadoop-conference-japan-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":9985},{"date":1316716440,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1316716440,"objectID":"62f31128a21b0e240bdb7b3d5b121c04","permalink":"https://blog.johtani.info/blog/2011/09/23/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-0%E6%97%A5%E7%9B%AE/","publishdate":"2011-09-23T03:34:00+09:00","readingtime":3,"relpermalink":"/blog/2011/09/23/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-0%E6%97%A5%E7%9B%AE/","section":"post","summary":"台風15号すごかったですね。幸いにも（？）夏休みだったので、通勤などでひどい目に合わずにすみました。 風雨はすごくてちょっと怖かったですが。。","tags":["読書"],"title":"「7つの言語　7つの世界」 Io 0日目(Jugemより移植)","type":"post","url":"/blog/2011/09/23/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-0%E6%97%A5%E7%9B%AE/","weight":0,"wordcount":1386},{"date":1316046660,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":300,"kind":"page","lang":"ja","lastmod":1316046660,"objectID":"54da1b916f49ef40c822fab61d37cf66","permalink":"https://blog.johtani.info/blog/2011/09/15/lucene-solr-3-4%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/","publishdate":"2011-09-15T09:31:00+09:00","readingtime":1,"relpermalink":"/blog/2011/09/15/lucene-solr-3-4%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/","section":"post","summary":"Solr/Lucene 3.4がリリースされました。（速報） 以下、各サイトへのリンクです。 Solrリリースのお知らせ Luceneリリースのお知らせ ちなみに、先日の","tags":["solr"],"title":"Lucene/Solr 3.4リリース（速報）(Jugemより移植)","type":"post","url":"/blog/2011/09/15/lucene-solr-3-4%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/","weight":0,"wordcount":252},{"date":1315992060,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1315992060,"objectID":"41b811063b9425de1934e77d89118022","permalink":"https://blog.johtani.info/blog/2011/09/14/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-3%E6%97%A5%E7%9B%AE%E6%9C%80%E7%B5%82%E6%97%A5/","publishdate":"2011-09-14T18:21:00+09:00","readingtime":4,"relpermalink":"/blog/2011/09/14/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-3%E6%97%A5%E7%9B%AE%E6%9C%80%E7%B5%82%E6%97%A5/","section":"post","summary":"ということで、Rubyの最終日の感想。 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大","tags":["読書"],"title":"「7つの言語　7つの世界」 Ruby 3日目（最終日）(Jugemより移植)","type":"post","url":"/blog/2011/09/14/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-3%E6%97%A5%E7%9B%AE%E6%9C%80%E7%B5%82%E6%97%A5/","weight":0,"wordcount":1583},{"date":1315810980,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":6300,"kind":"page","lang":"ja","lastmod":1315810980,"objectID":"37b622eaad1f79e759a722aacebf48ec","permalink":"https://blog.johtani.info/blog/2011/09/12/%E7%AC%AC6%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-09-12T16:03:00+09:00","readingtime":13,"relpermalink":"/blog/2011/09/12/%E7%AC%AC6%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"「第6回Solr勉強会」に参加しました。 なんだかんだと第6回で、今のところ皆勤賞です。 ということで、主に自分用ですが、メモなどとったので。 概","tags":["勉強会"],"title":"第6回Solr勉強会に参加しました。(Jugemより移植)","type":"post","url":"/blog/2011/09/12/%E7%AC%AC6%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":6272},{"date":1315588260,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":3700,"kind":"page","lang":"ja","lastmod":1315588260,"objectID":"73262345214f9b7794f2cc4a612b15e8","permalink":"https://blog.johtani.info/blog/2011/09/10/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-2%E6%97%A5%E7%9B%AE/","publishdate":"2011-09-10T02:11:00+09:00","readingtime":8,"relpermalink":"/blog/2011/09/10/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-2%E6%97%A5%E7%9B%AE/","section":"post","summary":"ということで、Ruby2日目の感想（2日目だけで2日間かかったのは内緒。。。） 今回もセルフスタディの私の回答が最後の方に記載されてます。見た","tags":["読書"],"title":"「7つの言語　7つの世界」 Ruby 2日目(Jugemより移植)","type":"post","url":"/blog/2011/09/10/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-2%E6%97%A5%E7%9B%AE/","weight":0,"wordcount":3673},{"date":1315545120,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1315545120,"objectID":"9baedcd033169611a42c3cfd58b3ae03","permalink":"https://blog.johtani.info/blog/2011/09/09/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-1%E6%97%A5%E7%9B%AE/","publishdate":"2011-09-09T14:12:00+09:00","readingtime":5,"relpermalink":"/blog/2011/09/09/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-1%E6%97%A5%E7%9B%AE/","section":"post","summary":"実に3年ぶりくらいにゆっくりできる日々が訪れたので、積読状態の本を消化しようと「7つの言語 7つの世界」を読み始めました。 せっかくブログも始め","tags":["読書"],"title":"「7つの言語　7つの世界」 Ruby 1日目(Jugemより移植)","type":"post","url":"/blog/2011/09/09/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-1%E6%97%A5%E7%9B%AE/","weight":0,"wordcount":2375},{"date":1315329480,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1315329480,"objectID":"f23ca2aa066b1ee0fa4df1f2f865be4c","permalink":"https://blog.johtani.info/blog/2011/09/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%93/","publishdate":"2011-09-07T02:18:00+09:00","readingtime":2,"relpermalink":"/blog/2011/09/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%93/","section":"post","summary":"現在の出先でMBAを使えないので、なかなか進んでいないMBAのセットアップです。。。 とりあえず、Eclipse、homebrewをインストー","tags":["備忘録"],"title":"MBAセットアップ備忘録その３(Jugemより移植)","type":"post","url":"/blog/2011/09/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%93/","weight":0,"wordcount":930},{"date":1315328188,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":500,"kind":"page","lang":"ja","lastmod":1315328188,"objectID":"3c2523e65ff953fd73579aaaf5d7ce36","permalink":"https://blog.johtani.info/blog/2011/09/07/%E8%BE%9E%E6%9B%B8%E5%88%86%E9%9B%A2%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E3%82%B1%E3%83%BC%E3%82%B9%E8%BF%BD%E5%8A%A0%E3%81%A8%E6%AE%8B%E3%82%BF%E3%82%B9%E3%82%AF/","publishdate":"2011-09-07T01:56:28+09:00","readingtime":1,"relpermalink":"/blog/2011/09/07/%E8%BE%9E%E6%9B%B8%E5%88%86%E9%9B%A2%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E3%82%B1%E3%83%BC%E3%82%B9%E8%BF%BD%E5%8A%A0%E3%81%A8%E6%AE%8B%E3%82%BF%E3%82%B9%E3%82%AF/","section":"post","summary":"すぐにテストケース追加しますといいつつ、はや一週間。 ようやく仕事が落ち着いたので、テストケースを追記しました。まだパッチの段階です。 一応、異","tags":["lucene-gosen"],"title":"辞書分離のテストケース追加と残タスク(Jugemより移植)","type":"post","url":"/blog/2011/09/07/%E8%BE%9E%E6%9B%B8%E5%88%86%E9%9B%A2%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E3%82%B1%E3%83%BC%E3%82%B9%E8%BF%BD%E5%8A%A0%E3%81%A8%E6%AE%8B%E3%82%BF%E3%82%B9%E3%82%AF/","weight":0,"wordcount":454},{"date":1314668040,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1314668040,"objectID":"88a8e608108be939da9aab5a9a8af7d1","permalink":"https://blog.johtani.info/blog/2011/08/30/%E8%A4%87%E6%95%B0%E8%BE%9E%E6%9B%B8%E3%81%AE%E8%AA%AD%E3%81%BF%E8%BE%BC%E3%81%BF%E6%A9%9F%E8%83%BD%E8%BF%BD%E5%8A%A0%E4%BB%AE/","publishdate":"2011-08-30T10:34:00+09:00","readingtime":3,"relpermalink":"/blog/2011/08/30/%E8%A4%87%E6%95%B0%E8%BE%9E%E6%9B%B8%E3%81%AE%E8%AA%AD%E3%81%BF%E8%BE%BC%E3%81%BF%E6%A9%9F%E8%83%BD%E8%BF%BD%E5%8A%A0%E4%BB%AE/","section":"post","summary":"先日、辞書のjarファイルからの分離についてパッチと記事を書きました。 IssueにあげていたパッチをRobertさんが見ていたらしく、次のよ","tags":["lucene-gosen"],"title":"複数辞書の読み込み機能追加（仮）(Jugemより移植)","type":"post","url":"/blog/2011/08/30/%E8%A4%87%E6%95%B0%E8%BE%9E%E6%9B%B8%E3%81%AE%E8%AA%AD%E3%81%BF%E8%BE%BC%E3%81%BF%E6%A9%9F%E8%83%BD%E8%BF%BD%E5%8A%A0%E4%BB%AE/","weight":0,"wordcount":1034},{"date":1314062760,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1314062760,"objectID":"2f1ec795216d5bafa33a810af3421942","permalink":"https://blog.johtani.info/blog/2011/08/23/%E8%BE%9E%E6%9B%B8%E3%81%AEjar%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%8B%E3%82%89%E3%81%AE%E5%88%86%E9%9B%A2/","publishdate":"2011-08-23T10:26:00+09:00","readingtime":4,"relpermalink":"/blog/2011/08/23/%E8%BE%9E%E6%9B%B8%E3%81%AEjar%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%8B%E3%82%89%E3%81%AE%E5%88%86%E9%9B%A2/","section":"post","summary":"ひさびさに、lucene-gosenの話題です。 lucene-gosenはjarファイルに辞書も同梱されており、jarファイルをクラスパスに","tags":["lucene-gosen"],"title":"辞書のjarファイルからの分離(Jugemより移植)","type":"post","url":"/blog/2011/08/23/%E8%BE%9E%E6%9B%B8%E3%81%AEjar%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%8B%E3%82%89%E3%81%AE%E5%88%86%E9%9B%A2/","weight":0,"wordcount":1747},{"date":1313369460,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1313369460,"objectID":"ce0aea06d44878b4a373efe090a66a62","permalink":"https://blog.johtani.info/blog/2011/08/15/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%92/","publishdate":"2011-08-15T09:51:00+09:00","readingtime":3,"relpermalink":"/blog/2011/08/15/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%92/","section":"post","summary":"すみません、また、MBA関連の記事になってしまいました。 ということで、備忘録その２です。 前回からいくつかインストールや環境の設定をしたので、","tags":["備忘録"],"title":"MBAセットアップ備忘録その２(Jugemより移植)","type":"post","url":"/blog/2011/08/15/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%92/","weight":0,"wordcount":1263},{"date":1312904760,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1312904760,"objectID":"c0e423f9ac41cc5b265c95a3e97e3fcb","permalink":"https://blog.johtani.info/blog/2011/08/10/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2/","publishdate":"2011-08-10T00:46:00+09:00","readingtime":3,"relpermalink":"/blog/2011/08/10/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2/","section":"post","summary":"Mac Book Airのセットアップ関連の備忘録 （今回は備忘録なので、文体も変かも） インストールしたもの（順不同）だいたい、このサイトを参考にした。 Evernote Dropbox","tags":["備忘録"],"title":"MBAセットアップ備忘録(Jugemより移植)","type":"post","url":"/blog/2011/08/10/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2/","weight":0,"wordcount":1365},{"date":1312389240,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1312389240,"objectID":"7ed1d2efa3e0f0ed6b77eb4eff3d86b3","permalink":"https://blog.johtani.info/blog/2011/08/04/apple%E6%95%99%E3%81%AB%E5%85%A5%E4%BF%A1%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-08-04T01:34:00+09:00","readingtime":3,"relpermalink":"/blog/2011/08/04/apple%E6%95%99%E3%81%AB%E5%85%A5%E4%BF%A1%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"個人用のPCを８年ぶりに新調しました。 前回購入した家のデスクトップPCがもう８年ものになりつつあるということで、 さすがに今年はPCを買おうと","tags":["備忘録"],"title":"Apple教に入信しました(Jugemより移植)","type":"post","url":"/blog/2011/08/04/apple%E6%95%99%E3%81%AB%E5%85%A5%E4%BF%A1%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":1407},{"date":1311737580,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":4900,"kind":"page","lang":"ja","lastmod":1311737580,"objectID":"3811b40721f7ca651887aac4eb17f9f0","permalink":"https://blog.johtani.info/blog/2011/07/27/%E7%AC%AC1%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-07-27T12:33:00+09:00","readingtime":10,"relpermalink":"/blog/2011/07/27/%E7%AC%AC1%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"かなり遅くなりましたが、第1回 データ構造と情報検索と言語処理勉強会 #DSIRNLPに参加しました。 帰ってから２日半ほど寝込んでしまい、更新が","tags":["勉強会"],"title":"第1回 データ構造と情報検索と言語処理勉強会に参加しました。(Jugemより移植)","type":"post","url":"/blog/2011/07/27/%E7%AC%AC1%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":4841},{"date":1311132540,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1311132540,"objectID":"5a765f9668608a39333fa90cf462657e","permalink":"https://blog.johtani.info/blog/2011/07/20/kuromoji%E3%82%92%E8%AA%BF%E3%81%B9%E3%81%A6%E3%81%BF%E3%81%9F/","publishdate":"2011-07-20T12:29:00+09:00","readingtime":3,"relpermalink":"/blog/2011/07/20/kuromoji%E3%82%92%E8%AA%BF%E3%81%B9%E3%81%A6%E3%81%BF%E3%81%9F/","section":"post","summary":"以前から春山さんのブログ（リンク）や勉強会で耳にはしていたのですがソースは読んでいませんでした。 先日、Luceneにcontributeされ","tags":["形態素解析"],"title":"Kuromojiを調べてみた(Jugemより移植)","type":"post","url":"/blog/2011/07/20/kuromoji%E3%82%92%E8%AA%BF%E3%81%B9%E3%81%A6%E3%81%BF%E3%81%9F/","weight":0,"wordcount":1219},{"date":1310432760,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1310432760,"objectID":"c70b78fd0b5dffcd38322355e9c2471e","permalink":"https://blog.johtani.info/blog/2011/07/12/naist-jdic-for-mecab%E3%81%AEpreprocessor%E3%81%AE%E5%AE%9F%E8%A3%85%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E5%82%99%E5%BF%98%E9%8C%B2/","publishdate":"2011-07-12T10:06:00+09:00","readingtime":3,"relpermalink":"/blog/2011/07/12/naist-jdic-for-mecab%E3%81%AEpreprocessor%E3%81%AE%E5%AE%9F%E8%A3%85%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E5%82%99%E5%BF%98%E9%8C%B2/","section":"post","summary":"忘れてしまうので、備忘録を残しておきます。 一応、ソースには少しずつコメントをいれてはいるのですが。 私は残念ながら、自然言語処理は初心者に毛が","tags":["lucene-gosen"],"title":"NAIST-JDic for MeCabのPreprocessorの実装に関する備忘録(Jugemより移植)","type":"post","url":"/blog/2011/07/12/naist-jdic-for-mecab%E3%81%AEpreprocessor%E3%81%AE%E5%AE%9F%E8%A3%85%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E5%82%99%E5%BF%98%E9%8C%B2/","weight":0,"wordcount":1464},{"date":1309777240,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":100,"kind":"page","lang":"ja","lastmod":1309777240,"objectID":"229975f1e84b5088e819cd5f2dc43080","permalink":"https://blog.johtani.info/blog/2011/07/04/lucene-gosen-1-1-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2011-07-04T20:00:40+09:00","readingtime":1,"relpermalink":"/blog/2011/07/04/lucene-gosen-1-1-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","section":"post","summary":"lucene-gosen 1.1.1をリリースしました。 先日お知らせしたバグ修正を取り込んだjarを用意いしました。 ダウンロードはこちらから","tags":["lucene-gosen"],"title":"lucene-gosen 1.1.1リリース(Jugemより移植)","type":"post","url":"/blog/2011/07/04/lucene-gosen-1-1-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","weight":0,"wordcount":58},{"date":1309501779,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":100,"kind":"page","lang":"ja","lastmod":1309501779,"objectID":"10eb1e7dc64d8ca3dad92641dadb5de7","permalink":"https://blog.johtani.info/blog/2011/07/01/lucene-solr-3-3%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/","publishdate":"2011-07-01T15:29:39+09:00","readingtime":1,"relpermalink":"/blog/2011/07/01/lucene-solr-3-3%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/","section":"post","summary":"Solr/Lucene 3.3がリリースされました。（速報） 以下、各サイトへのリンクです。 Solrリリースのお知らせ Luceneリリースのお知らせ リリースのタイミ","tags":["solr"],"title":"Lucene/Solr 3.3リリース（速報）(Jugemより移植)","type":"post","url":"/blog/2011/07/01/lucene-solr-3-3%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/","weight":0,"wordcount":86},{"date":1309356600,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":5100,"kind":"page","lang":"ja","lastmod":1309356600,"objectID":"49ba23148db9effdc3979aa0fe5876ea","permalink":"https://blog.johtani.info/blog/2011/06/29/hadoop%E3%82%92%E4%B8%AD%E5%BF%83%E3%81%A8%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E7%92%B0%E5%A2%83%E3%81%A7%E3%81%AE%E9%96%8B%E7%99%BA%E6%96%B9%E6%B3%95%E8%AB%96%E3%83%A2%E3%83%87%E3%83%AA%E3%83%B3%E3%82%B0%E8%A8%AD%E8%A8%88%E6%89%8B%E6%B3%95%E7%AD%89%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E5%BA%A7%E8%AB%87%E4%BC%9A-%E7%AC%AC5%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-06-29T23:10:00+09:00","readingtime":11,"relpermalink":"/blog/2011/06/29/hadoop%E3%82%92%E4%B8%AD%E5%BF%83%E3%81%A8%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E7%92%B0%E5%A2%83%E3%81%A7%E3%81%AE%E9%96%8B%E7%99%BA%E6%96%B9%E6%B3%95%E8%AB%96%E3%83%A2%E3%83%87%E3%83%AA%E3%83%B3%E3%82%B0%E8%A8%AD%E8%A8%88%E6%89%8B%E6%B3%95%E7%AD%89%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E5%BA%A7%E8%AB%87%E4%BC%9A-%E7%AC%AC5%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"「Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）」に参加しました。300名入るイベントルー","tags":["hadoop"],"title":"Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）に参加しました。(Jugemより移植)","type":"post","url":"/blog/2011/06/29/hadoop%E3%82%92%E4%B8%AD%E5%BF%83%E3%81%A8%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E7%92%B0%E5%A2%83%E3%81%A7%E3%81%AE%E9%96%8B%E7%99%BA%E6%96%B9%E6%B3%95%E8%AB%96%E3%83%A2%E3%83%87%E3%83%AA%E3%83%B3%E3%82%B0%E8%A8%AD%E8%A8%88%E6%89%8B%E6%B3%95%E7%AD%89%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E5%BA%A7%E8%AB%87%E4%BC%9A-%E7%AC%AC5%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":5050},{"date":1309232160,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":400,"kind":"page","lang":"ja","lastmod":1309232160,"objectID":"f6dff70097776e24c2a7c9c0f2514f79","permalink":"https://blog.johtani.info/blog/2011/06/28/compositeposcompositetokenfilter%E3%81%AE%E3%83%90%E3%82%B0%E4%BF%AE%E6%AD%A3/","publishdate":"2011-06-28T12:36:00+09:00","readingtime":1,"relpermalink":"/blog/2011/06/28/compositeposcompositetokenfilter%E3%81%AE%E3%83%90%E3%82%B0%E4%BF%AE%E6%AD%A3/","section":"post","summary":"以前、こちらで話題に上がっていた「未知語」に関するcompositePOSのエラーの件を調査しました。（Twitterでも流れてました。） 次","tags":["lucene-gosen"],"title":"compositePOS（CompositeTokenFilter）のバグ修正(Jugemより移植)","type":"post","url":"/blog/2011/06/28/compositeposcompositetokenfilter%E3%81%AE%E3%83%90%E3%82%B0%E4%BF%AE%E6%AD%A3/","weight":0,"wordcount":310},{"date":1308609480,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1308609480,"objectID":"991285e3967c3295b4ff2dcd835f7c61","permalink":"https://blog.johtani.info/blog/2011/06/21/naist-jdic-for-mecab%E5%AF%BE%E5%BF%9C%E7%89%88%E4%BB%AE%E5%AE%9F%E8%A3%85/","publishdate":"2011-06-21T07:38:00+09:00","readingtime":2,"relpermalink":"/blog/2011/06/21/naist-jdic-for-mecab%E5%AF%BE%E5%BF%9C%E7%89%88%E4%BB%AE%E5%AE%9F%E8%A3%85/","section":"post","summary":"lucene-gosenのtrunkbranches/impl-mecab-dicにNAIST-JDic for MeCabの辞書を利用出来るPre","tags":["lucene-gosen"],"title":"NAIST-JDic for MeCab対応版（仮実装）(Jugemより移植)","type":"post","url":"/blog/2011/06/21/naist-jdic-for-mecab%E5%AF%BE%E5%BF%9C%E7%89%88%E4%BB%AE%E5%AE%9F%E8%A3%85/","weight":0,"wordcount":977},{"date":1307977200,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1307977200,"objectID":"50f43b1726cf61066ef8656477b226be","permalink":"https://blog.johtani.info/blog/2011/06/14/compositepos%E3%81%AE%E5%88%A9%E7%94%A8%E4%BE%8Bnaist-chasen%E3%81%A7%E3%81%AE%E8%8B%B1%E5%8D%98%E8%AA%9E%E3%81%AE%E5%87%BA%E5%8A%9B%E6%96%B9%E6%B3%95%E4%BE%8B/","publishdate":"2011-06-14T00:00:00+09:00","readingtime":4,"relpermalink":"/blog/2011/06/14/compositepos%E3%81%AE%E5%88%A9%E7%94%A8%E4%BE%8Bnaist-chasen%E3%81%A7%E3%81%AE%E8%8B%B1%E5%8D%98%E8%AA%9E%E3%81%AE%E5%87%BA%E5%8A%9B%E6%96%B9%E6%B3%95%E4%BE%8B/","section":"post","summary":"前回、naist-chasenではアルファベットが別々の単語としてanalyzeされてしまうという話をしました。 ただ、これだと、英単語が含ま","tags":["lucene-gosen"],"title":"compositePOSの利用例（naist-chasenでの英単語の出力方法例）(Jugemより移植)","type":"post","url":"/blog/2011/06/14/compositepos%E3%81%AE%E5%88%A9%E7%94%A8%E4%BE%8Bnaist-chasen%E3%81%A7%E3%81%AE%E8%8B%B1%E5%8D%98%E8%AA%9E%E3%81%AE%E5%87%BA%E5%8A%9B%E6%96%B9%E6%B3%95%E4%BE%8B/","weight":0,"wordcount":1509},{"date":1307934480,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":300,"kind":"page","lang":"ja","lastmod":1307934480,"objectID":"eeef60efe889349870426d10edc694be","permalink":"https://blog.johtani.info/blog/2011/06/13/lucene-gosen-1-1-0-%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2011-06-13T12:08:00+09:00","readingtime":1,"relpermalink":"/blog/2011/06/13/lucene-gosen-1-1-0-%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","section":"post","summary":"lucene-gosenの1.1.0がリリースされました。 大きな目玉はJapaneseTokenizerが出力する形態素に関するデータを遅延","tags":["lucene-gosen"],"title":"lucene-gosen 1.1.0 リリース(Jugemより移植)","type":"post","url":"/blog/2011/06/13/lucene-gosen-1-1-0-%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","weight":0,"wordcount":214},{"date":1307344980,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1200,"kind":"page","lang":"ja","lastmod":1307344980,"objectID":"4b046ac6a4796fb1338f0481dbd4003d","permalink":"https://blog.johtani.info/blog/2011/06/06/lucene-gosen%E3%81%AEtokenfilter%E3%81%9F%E3%81%A1/","publishdate":"2011-06-06T16:23:00+09:00","readingtime":3,"relpermalink":"/blog/2011/06/06/lucene-gosen%E3%81%AEtokenfilter%E3%81%9F%E3%81%A1/","section":"post","summary":"lucene-gosenをSolr/Luceneで利用する場合、TokenFilterを利用してTokenizerが出力したToken対して","tags":["lucene-gosen"],"title":"lucene-gosenのTokenFilterたち(Jugemより移植)","type":"post","url":"/blog/2011/06/06/lucene-gosen%E3%81%AEtokenfilter%E3%81%9F%E3%81%A1/","weight":0,"wordcount":1118},{"date":1307002560,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1307002560,"objectID":"b2621497b3313c97855ed951f0d9b291","permalink":"https://blog.johtani.info/blog/2011/06/02/%E8%BE%9E%E6%9B%B8%E3%81%A8%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E8%BE%9E%E6%9B%B8%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2011-06-02T17:16:00+09:00","readingtime":5,"relpermalink":"/blog/2011/06/02/%E8%BE%9E%E6%9B%B8%E3%81%A8%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E8%BE%9E%E6%9B%B8%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","section":"post","summary":"辞書の特性について 現在lucene-gosenでは以下の2つの辞書が利用可能です。 簡単に違いについて説明します。 IPAdicの辞書について バ","tags":["lucene-gosen"],"title":"辞書とカスタム辞書について(Jugemより移植)","type":"post","url":"/blog/2011/06/02/%E8%BE%9E%E6%9B%B8%E3%81%A8%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E8%BE%9E%E6%9B%B8%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","weight":0,"wordcount":2405},{"date":1306398840,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1306398840,"objectID":"ff1441a42144a7de9a3eaf9f5e7cfea9","permalink":"https://blog.johtani.info/blog/2011/05/26/%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%8B%E3%82%89%E3%81%AE%E3%83%93%E3%83%AB%E3%83%89%E3%81%A8%E6%A7%8B%E6%88%90/","publishdate":"2011-05-26T17:34:00+09:00","readingtime":3,"relpermalink":"/blog/2011/05/26/%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%8B%E3%82%89%E3%81%AE%E3%83%93%E3%83%AB%E3%83%89%E3%81%A8%E6%A7%8B%E6%88%90/","section":"post","summary":"今回はソースのダウンロードとビルドについてです。 最新版のソースを利用したり、JavaDocを見たい場合はソースをダウンロードしてからビルドす","tags":["lucene-gosen"],"title":"ソースからのビルドと構成(Jugemより移植)","type":"post","url":"/blog/2011/05/26/%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%8B%E3%82%89%E3%81%AE%E3%83%93%E3%83%AB%E3%83%89%E3%81%A8%E6%A7%8B%E6%88%90/","weight":0,"wordcount":1046},{"date":1306130400,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":600,"kind":"page","lang":"ja","lastmod":1306130400,"objectID":"5988b62a0c0785a303b77c74608e8b55","permalink":"https://blog.johtani.info/blog/2011/05/23/lucene-gosen%E3%81%A8%E3%81%AF/","publishdate":"2011-05-23T15:00:00+09:00","readingtime":2,"relpermalink":"/blog/2011/05/23/lucene-gosen%E3%81%A8%E3%81%AF/","section":"post","summary":"概要： Lucene/SolrのコミッターであるRobert Muirさんが始めたプロジェクト 歴史： MeCabのJava移植版としてスタートした","tags":["lucene-gosen"],"title":"lucene-gosenとは(Jugemより移植)","type":"post","url":"/blog/2011/05/23/lucene-gosen%E3%81%A8%E3%81%AF/","weight":0,"wordcount":542},{"date":1305859440,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":200,"kind":"page","lang":"ja","lastmod":1305859440,"objectID":"94b85ba716dbb7c20b230e69248b8208","permalink":"https://blog.johtani.info/blog/2011/05/20/%E3%83%96%E3%83%AD%E3%82%B0%E3%81%AF%E3%81%98%E3%82%81%E3%81%BE%E3%81%99/","publishdate":"2011-05-20T11:44:00+09:00","readingtime":1,"relpermalink":"/blog/2011/05/20/%E3%83%96%E3%83%AD%E3%82%B0%E3%81%AF%E3%81%98%E3%82%81%E3%81%BE%E3%81%99/","section":"post","summary":"今さらですが、ブログをはじめてみようかと。今さらですが… はじめてみようと思った一番の理由は、自分で調べたことをメモがわりに残すためです。 あと","tags":["misc"],"title":"ブログはじめます(Jugemより移植)","type":"post","url":"/blog/2011/05/20/%E3%83%96%E3%83%AD%E3%82%B0%E3%81%AF%E3%81%98%E3%82%81%E3%81%BE%E3%81%99/","weight":0,"wordcount":162}]
\ No newline at end of file
+[{"date":1706175053,"dir":"post/2024/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1706175053,"objectID":"c4dba56f2db4851cd31b561d92dc5e35","permalink":"https://blog.johtani.info/blog/2024/01/25/kagome-bot-as-a-user-service/","publishdate":"2024-01-25T09:30:53Z","readingtime":2,"relpermalink":"/blog/2024/01/25/kagome-bot-as-a-user-service/","section":"post","summary":"日常でよく、形態素解析したくなることがありますよね？ そして、Slackも日常的に立ち上がってますよね？ ということは、Slackのボットとして","tags":["go"],"title":"kagome-botのユーザーサービス化","type":"post","url":"/blog/2024/01/25/kagome-bot-as-a-user-service/","weight":0,"wordcount":952},{"date":1704008961,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1704008961,"objectID":"d869fb48cb9acba03dc639481524ee80","permalink":"https://blog.johtani.info/blog/2023/12/31/review-2023/","publishdate":"2023-12-31T07:49:21Z","readingtime":5,"relpermalink":"/blog/2023/12/31/review-2023/","section":"post","summary":"今年も振り返りブログをリビングで書いています（ドミノ倒しすごいな）。 FMVのキーボードで書いているのでタイポがつらい。。。 振り返り（2022","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2023）","type":"post","url":"/blog/2023/12/31/review-2023/","weight":0,"wordcount":2323},{"date":1702566000,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":6900,"kind":"page","lang":"ja","lastmod":1702566000,"objectID":"476e17b6f854414033d5cec1470774ee","permalink":"https://blog.johtani.info/blog/2023/12/15/introduce-orama-to-blog/","publishdate":"2023-12-15T00:00:00+09:00","readingtime":14,"relpermalink":"/blog/2023/12/15/introduce-orama-to-blog/","section":"post","summary":"この記事は、情報検索・検索技術 Advent Calendar 2023の15日目の記事です。 昨年に続き2回目の情報検索のAdvent Calendar参戦です。 今年は、夏","tags":["orama","search"],"title":"Oramaという検索エンジンでブログ検索を作ってみた","type":"post","url":"/blog/2023/12/15/introduce-orama-to-blog/","weight":0,"wordcount":6835},{"date":1701961200,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":3200,"kind":"page","lang":"ja","lastmod":1701961200,"objectID":"516a7aa07f8faa6b7aa38beb5010cf8c","permalink":"https://blog.johtani.info/blog/2023/12/08/smarthome-bot/","publishdate":"2023-12-08T00:00:00+09:00","readingtime":7,"relpermalink":"/blog/2023/12/08/smarthome-bot/","section":"post","summary":"PySpaアドベントカレンダーの12/08のエントリーです。昨日は渋川さんのアンラーニングで失敗した話でした。 私は、今年は昨年の続きっぽい話","tags":["misc","music","bot"],"title":"GoでSlackのボットを作った話","type":"post","url":"/blog/2023/12/08/smarthome-bot/","weight":0,"wordcount":3195},{"date":1695612744,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1695612744,"objectID":"7f78b02c531f09602ba4e140132d26a2","permalink":"https://blog.johtani.info/blog/2023/09/25/read-search-raking-guide/","publishdate":"2023-09-25T03:32:24Z","readingtime":5,"relpermalink":"/blog/2023/09/25/read-search-raking-guide/","section":"post","summary":"「機械学習による検索ランキング改善ガイド」を読みました。 著者の鈴木さんより献本いただいたのを読み終わったのでレビューと、あとおまけです。 紹介","tags":["読書","elasticsearch"],"title":"機械学習による検索ランキング改善ガイドを読みました","type":"post","url":"/blog/2023/09/25/read-search-raking-guide/","weight":0,"wordcount":2401},{"date":1692768764,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1692768764,"objectID":"8f58cbe5f2ce85c22569af765de3f8d3","permalink":"https://blog.johtani.info/blog/2023/08/23/search-ui-and-searchkit/","publishdate":"2023-08-23T05:32:44Z","readingtime":5,"relpermalink":"/blog/2023/08/23/search-ui-and-searchkit/","section":"post","summary":"趣味？（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書いています。 ベクトル検索などの確認なども含めて、Jupyter N","tags":["searchkit","search-ui","画面"],"title":"search-UIとSearchkitと検索画面","type":"post","url":"/blog/2023/08/23/search-ui-and-searchkit/","weight":0,"wordcount":2384},{"date":1690420969,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1690420969,"objectID":"f9e847ee886bdb9ab5583eeb6eabbd51","permalink":"https://blog.johtani.info/blog/2023/07/27/container-name-in-devcontainer/","publishdate":"2023-07-27T01:22:49Z","readingtime":2,"relpermalink":"/blog/2023/07/27/container-name-in-devcontainer/","section":"post","summary":"いくつかある環境をDev Containerで動くように変えていますが、最初に導入した時に疑問点だった「コンテナ名」について解消したのでメモを","tags":["dev container"],"title":"VS CodeとDev Container(コンテナ名の指定)","type":"post","url":"/blog/2023/07/27/container-name-in-devcontainer/","weight":0,"wordcount":642},{"date":1690189832,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1690189832,"objectID":"7884b62c561b999b9358d52779a18218","permalink":"https://blog.johtani.info/blog/2023/07/24/introduce-dev-container-to-hugo-env/","publishdate":"2023-07-24T09:10:32Z","readingtime":3,"relpermalink":"/blog/2023/07/24/introduce-dev-container-to-hugo-env/","section":"post","summary":"このブログの生成には、Hugoを利用しています。 ブログ移行日記（その1）に書いてありますが、当時はbrewでインストールしていました。 また、","tags":["hugo","dev container"],"title":"ブログ記述環境としてのDev Container","type":"post","url":"/blog/2023/07/24/introduce-dev-container-to-hugo-env/","weight":0,"wordcount":1500},{"date":1690180128,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1690180128,"objectID":"ed431877ce11fe403fee77f7d26ce637","permalink":"https://blog.johtani.info/blog/2023/07/24/move-distribution-to-another-disk/","publishdate":"2023-07-24T06:28:48Z","readingtime":6,"relpermalink":"/blog/2023/07/24/move-distribution-to-another-disk/","section":"post","summary":"WSL2にUbuntuを入れて、開発とかはこちらを利用しています。 また、Docker DesktopもWSL2のバックエンドエンジンを利用して","tags":["wsl","windows"],"title":"WSL2のディストリビューションの環境移行","type":"post","url":"/blog/2023/07/24/move-distribution-to-another-disk/","weight":0,"wordcount":2776},{"date":1689902010,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":4100,"kind":"page","lang":"ja","lastmod":1689902010,"objectID":"086b4fd5f77021a0a2aa6b0e90061486","permalink":"https://blog.johtani.info/blog/2023/07/21/multi-containers-with-dev-container/","publishdate":"2023-07-21T10:13:30+09:00","readingtime":8,"relpermalink":"/blog/2023/07/21/multi-containers-with-dev-container/","section":"post","summary":"前回の記事で、VS Code＋Dev Containerを導入しました。 残課題として「マルチコンテナ化」があるという話もしました。今回はDev C","tags":["python","dev container"],"title":"VS CodeとDev Container（docker-compose.yml対応）","type":"post","url":"/blog/2023/07/21/multi-containers-with-dev-container/","weight":0,"wordcount":4006},{"date":1689254123,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":3500,"kind":"page","lang":"ja","lastmod":1689254123,"objectID":"a12474027c91fad5a861aa9919817d72","permalink":"https://blog.johtani.info/blog/2023/07/13/introduce-vs-code-and-dev-container/","publishdate":"2023-07-13T22:15:23+09:00","readingtime":7,"relpermalink":"/blog/2023/07/13/introduce-vs-code-and-dev-container/","section":"post","summary":"前回の記事で、pre-commitとPyCharmとWindowsの組み合わせで困っていることを書きました。 これについて、知り合いとチャット","tags":["python","dev container"],"title":"VS CodeとDev Containerの導入（まだ途中）","type":"post","url":"/blog/2023/07/13/introduce-vs-code-and-dev-container/","weight":0,"wordcount":3461},{"date":1688954148,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":4000,"kind":"page","lang":"ja","lastmod":1688954148,"objectID":"698cf3cbd796161d82c9ac438ebab5d2","permalink":"https://blog.johtani.info/blog/2023/07/10/pre-commit-and-python/","publishdate":"2023-07-10T10:55:48+09:00","readingtime":8,"relpermalink":"/blog/2023/07/10/pre-commit-and-python/","section":"post","summary":"最近、趣味（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書き始めました。 きちんとPythonのプログラムをプロジェクト","tags":["python"],"title":"pre-commitとvenvとPyCharm（困ったな？）","type":"post","url":"/blog/2023/07/10/pre-commit-and-python/","weight":0,"wordcount":3921},{"date":1687278645,"dir":"post/2023/","expirydate":-62135596800,"fuzzywordcount":4000,"kind":"page","lang":"ja","lastmod":1687278645,"objectID":"9335522f4c8dbc7256a42a091e6e00bc","permalink":"https://blog.johtani.info/blog/2023/06/21/attend-berlin-buzzwords-2023/","publishdate":"2023-06-21T01:30:45+09:00","readingtime":8,"relpermalink":"/blog/2023/06/21/attend-berlin-buzzwords-2023/","section":"post","summary":"今年もこの季節がやってきました。 Berlin Buzzwordsにオンラインで出張してました。 今年もハイブリッド開催をしてくれたので、オンラインで参加で","tags":["conference","belin buzzwords"],"title":"今年もオンラインでBerlin Buzzwordsに参加した","type":"post","url":"/blog/2023/06/21/attend-berlin-buzzwords-2023/","weight":0,"wordcount":3992},{"date":1672486684,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":2100,"kind":"page","lang":"ja","lastmod":1672486684,"objectID":"df30d810068e4656498e5972c6de7e3d","permalink":"https://blog.johtani.info/blog/2022/12/31/review-2022/","publishdate":"2022-12-31T20:38:04+09:00","readingtime":5,"relpermalink":"/blog/2022/12/31/review-2022/","section":"post","summary":"今年もなんとか振り返りブログを書いてます（時間大丈夫かな？w）。紅白をリアタイで見ながら。 振り返り（2021年に書いた抱負から） まずは振り返","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2022）","type":"post","url":"/blog/2022/12/31/review-2022/","weight":0,"wordcount":2099},{"date":1671030358,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":4100,"kind":"page","lang":"ja","lastmod":1671030358,"objectID":"67c2ae6761e89be0fa66db9623b40d30","permalink":"https://blog.johtani.info/blog/2022/12/15/music-server-on-mac-mini/","publishdate":"2022-12-15T00:05:58+09:00","readingtime":9,"relpermalink":"/blog/2022/12/15/music-server-on-mac-mini/","section":"post","summary":"PySpaアドベントカレンダーの12/15のエントリーです。昨日はtaichiさんでした。 今年はDIYではなく、PCにまつわる話を。 仕事中は","tags":["misc","music"],"title":"仕事中のBGM環境","type":"post","url":"/blog/2022/12/15/music-server-on-mac-mini/","weight":0,"wordcount":4080},{"date":1670516125,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":3100,"kind":"page","lang":"ja","lastmod":1670516125,"objectID":"9693a1e77dee5785b1dc61ccffd2e906","permalink":"https://blog.johtani.info/blog/2022/12/09/open-search-serverless/","publishdate":"2022-12-09T01:15:25+09:00","readingtime":7,"relpermalink":"/blog/2022/12/09/open-search-serverless/","section":"post","summary":"本記事は情報検索・検索技術 Advent Calendar 2022の9日目の記事です。 だいぶ間が空いてしまいましたが、日本語のオートコンプリートに関する記事の続きです。","tags":["elasticsearch","opensearch"],"title":"ElasticsearchのアーキテクチャとStateless / Serverless","type":"post","url":"/blog/2022/12/09/open-search-serverless/","weight":0,"wordcount":3054},{"date":1660099802,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":3800,"kind":"page","lang":"ja","lastmod":1660099802,"objectID":"73279888a8fe482c836fb19ca23318dc","permalink":"https://blog.johtani.info/blog/2022/08/10/jp-auto-completion-2/","publishdate":"2022-08-10T11:50:02+09:00","readingtime":8,"relpermalink":"/blog/2022/08/10/jp-auto-completion-2/","section":"post","summary":"前回は日本語用オートコンプリートのためのAnalyzerとして、どうやって使うのかを簡単に紹介しました。 今回はもう少し、いろんなパターンを試","tags":["elasticsearch","lucene"],"title":"ローマ字入力のゆれと読み（JapaneseCompletionAnalyzerその2）","type":"post","url":"/blog/2022/08/10/jp-auto-completion-2/","weight":0,"wordcount":3778},{"date":1660028402,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":4800,"kind":"page","lang":"ja","lastmod":1660028402,"objectID":"6639ec6f88c4976f8ca20fa840f169e3","permalink":"https://blog.johtani.info/blog/2022/08/09/japanese-auto-completion/","publishdate":"2022-08-09T16:00:02+09:00","readingtime":10,"relpermalink":"/blog/2022/08/09/japanese-auto-completion/","section":"post","summary":"風のうわさで、日本語用のオートコンプリートのためのTokenFilterとAnalyzerがLuceneに取り込まれたと聞きました（LUCE","tags":["lucene","elasticsearch"],"title":"日本語用オートコンプリートのためのAnalyzer","type":"post","url":"/blog/2022/08/09/japanese-auto-completion/","weight":0,"wordcount":4746},{"date":1659689954,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":2200,"kind":"page","lang":"ja","lastmod":1659689954,"objectID":"167a7c9d579ce6f2cebf64a6f6329ecb","permalink":"https://blog.johtani.info/blog/2022/08/05/upgrade-hugo-accidentally/","publishdate":"2022-08-05T17:59:14+09:00","readingtime":5,"relpermalink":"/blog/2022/08/05/upgrade-hugo-accidentally/","section":"post","summary":"Hugoを0.84から0.92にアップデートをする際に、これまでのブログ記事やレイアウトファイルを修正したので個人的にメモを残しておきます。","tags":["hugo"],"title":"Hugoをアップデートした","type":"post","url":"/blog/2022/08/05/upgrade-hugo-accidentally/","weight":0,"wordcount":2156},{"date":1658300650,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":1900,"kind":"page","lang":"ja","lastmod":1658300650,"objectID":"3384ea6bb47d70f8ca94b4510813f36a","permalink":"https://blog.johtani.info/blog/2022/07/20/querqy-architecture/","publishdate":"2022-07-20T16:04:10+09:00","readingtime":4,"relpermalink":"/blog/2022/07/20/querqy-architecture/","section":"post","summary":"今回はQuerqyのElasticsearchのプラグインがどんなつくりになっているか？をちょっとだけ調べてみました。 SolrでもElast","tags":["elasticsearch"],"title":"Querqyの調査（その2：アーキテクチャ）","type":"post","url":"/blog/2022/07/20/querqy-architecture/","weight":0,"wordcount":1813},{"date":1658285563,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":3500,"kind":"page","lang":"ja","lastmod":1658285563,"objectID":"779e444b4bc720a9eed97f19c41e8773","permalink":"https://blog.johtani.info/blog/2022/07/20/intro-querqy/","publishdate":"2022-07-20T11:52:43+09:00","readingtime":7,"relpermalink":"/blog/2022/07/20/intro-querqy/","section":"post","summary":"Querqyというクエリのリライト用のプラグインがあるのでどんなものかを調べてみました。とりあえずは概要をドキュメントから追いかけてみた感じ","tags":["elasticsearch"],"title":"Querqyの調査（その１）","type":"post","url":"/blog/2022/07/20/intro-querqy/","weight":0,"wordcount":3401},{"date":1655283615,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":3700,"kind":"page","lang":"ja","lastmod":1655283615,"objectID":"f56c19442484b3e4f47875b58b3f72b2","permalink":"https://blog.johtani.info/blog/2022/06/15/ttend-berlin-buzzwords-online/","publishdate":"2022-06-15T18:00:15+09:00","readingtime":8,"relpermalink":"/blog/2022/06/15/ttend-berlin-buzzwords-online/","section":"post","summary":"今年もBerlin Buzzwordsにオンライン出張してました。 今年はハイブリッドな開催だったようで、現地で再開している人もいるようでした。","tags":["conference","berlin buzzwords"],"title":"今年もオンラインでBerlin Buzzwordsに参加した","type":"post","url":"/blog/2022/06/15/ttend-berlin-buzzwords-online/","weight":0,"wordcount":3642},{"date":1655119446,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1655119446,"objectID":"5eebdf85fd1726db301194bfeeee4377","permalink":"https://blog.johtani.info/blog/2022/06/13/new-elasticsearch-java-client/","publishdate":"2022-06-13T20:24:06+09:00","readingtime":6,"relpermalink":"/blog/2022/06/13/new-elasticsearch-java-client/","section":"post","summary":"7.16で正式リリースされましたが、Elasticsearchの新しいJavaのクライアントが出ています。 使ってみたので、ちょっとだけ紹介で","tags":["elasticsearch","java"],"title":"Elasticsearchの新しいJavaクライアント","type":"post","url":"/blog/2022/06/13/new-elasticsearch-java-client/","weight":0,"wordcount":2677},{"date":1652856857,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":2100,"kind":"page","lang":"ja","lastmod":1652856857,"objectID":"7cc21814165879f72529e91682ece5c6","permalink":"https://blog.johtani.info/blog/2022/05/18/index-alias-in-azure-cognitive-search/","publishdate":"2022-05-18T15:54:17+09:00","readingtime":5,"relpermalink":"/blog/2022/05/18/index-alias-in-azure-cognitive-search/","section":"post","summary":"Azure Cognitive Searchで2月に新しい機能が公開されました。 「Index Alias」（インデックスの別名）です。まだ、パブリックプレビューの段階です","tags":["azure search"],"title":"インデックスエイリアス - Azure Cognitive Searchの新機能","type":"post","url":"/blog/2022/05/18/index-alias-in-azure-cognitive-search/","weight":0,"wordcount":2015},{"date":1641980462,"dir":"post/2022/","expirydate":-62135596800,"fuzzywordcount":3000,"kind":"page","lang":"ja","lastmod":1641980462,"objectID":"0645bdb1cdf88ec74288d503eb71839c","permalink":"https://blog.johtani.info/blog/2022/01/12/reading-xmc-for-semantic-search-in-prod/","publishdate":"2022-01-12T18:41:02+09:00","readingtime":6,"relpermalink":"/blog/2022/01/12/reading-xmc-for-semantic-search-in-prod/","section":"post","summary":"年末までに知り合いと次の論文を読んだので軽くまとめておきます。 Extreme Multi-label Learning for Semantic Matching in Product Search なんで読んだの？ 前回読んだ理由と一緒ですが、Semantic","tags":["search","paper"],"title":"Extreme Multi-label Learning for Semantic Matching in Product Searchという論文を読んだ","type":"post","url":"/blog/2022/01/12/reading-xmc-for-semantic-search-in-prod/","weight":0,"wordcount":2978},{"date":1640957359,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":1900,"kind":"page","lang":"ja","lastmod":1640957359,"objectID":"104b8ee17a8bf1f7043d236659680493","permalink":"https://blog.johtani.info/blog/2021/12/31/looking-back-2021/","publishdate":"2021-12-31T22:29:19+09:00","readingtime":4,"relpermalink":"/blog/2021/12/31/looking-back-2021/","section":"post","summary":"今年も振り返りブログです。録画した紅白をオッかけ再生して気になるアーティストだけ見ながら書ています。 振り返り（2020年に書いた抱負から） ま","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2021）","type":"post","url":"/blog/2021/12/31/looking-back-2021/","weight":0,"wordcount":1878},{"date":1640784504,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":2200,"kind":"page","lang":"ja","lastmod":1640784504,"objectID":"218e2c36d5945ece02fdc55d6cbcbc38","permalink":"https://blog.johtani.info/blog/2021/12/29/best-buy-2021/","publishdate":"2021-12-29T22:28:24+09:00","readingtime":5,"relpermalink":"/blog/2021/12/29/best-buy-2021/","section":"post","summary":"2021年もあと少しですが、今年買って良かったものをリストアップしておこうかと思います。 今年買ったといいながら、昨年このネタを書くといいつつ","tags":["misc"],"title":"2021年かって良かったもの","type":"post","url":"/blog/2021/12/29/best-buy-2021/","weight":0,"wordcount":2169},{"date":1640141671,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":600,"kind":"page","lang":"ja","lastmod":1640141671,"objectID":"f0fdc140e18514362a4e52376a6fecba","permalink":"https://blog.johtani.info/blog/2021/12/22/azure-search-schema-json2csv/","publishdate":"2021-12-22T11:54:31+09:00","readingtime":2,"relpermalink":"/blog/2021/12/22/azure-search-schema-json2csv/","section":"post","summary":"Azure Cognitive Searchのスキーマの確認をするときに、Azureのポータルでは次のようにフィールドの一覧として見ることができます。 ただ、実際のインデ","tags":["azure search","misc"],"title":"Azure Cognitive SearchのIndex Schema JSONをCSVで見たくなる","type":"post","url":"/blog/2021/12/22/azure-search-schema-json2csv/","weight":0,"wordcount":595},{"date":1638889200,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":2900,"kind":"page","lang":"ja","lastmod":1638889200,"objectID":"26e44dfd16a2963d4c18e99806c26fd7","permalink":"https://blog.johtani.info/blog/2021/12/08/controller-rack/","publishdate":"2021-12-08T00:00:00+09:00","readingtime":6,"relpermalink":"/blog/2021/12/08/controller-rack/","section":"post","summary":"今年もアドベントカレンダーの季節になってしまいました。 今年で2回目となる、pyspa Advent Calendar 2021の投稿です。 昨年に引き続きDIYがらみの投稿","tags":["DIYキーボード","misc"],"title":"今年のDIYキーボードとコントローラーラック","type":"post","url":"/blog/2021/12/08/controller-rack/","weight":0,"wordcount":2857},{"date":1636522396,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":2300,"kind":"page","lang":"ja","lastmod":1636522396,"objectID":"35200cbf0b5b45d7f5f0b343cb18868b","permalink":"https://blog.johtani.info/blog/2021/11/10/reading-ms-biomedical-search-paper/","publishdate":"2021-11-10T14:33:16+09:00","readingtime":5,"relpermalink":"/blog/2021/11/10/reading-ms-biomedical-search-paper/","section":"post","summary":"Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだので軽くメモを残しておきます。論文自体はリンクから参照してください。 読んだ理由 Azure Cognitive S","tags":["search","paper"],"title":"Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだ","type":"post","url":"/blog/2021/11/10/reading-ms-biomedical-search-paper/","weight":0,"wordcount":2247},{"date":1626160103,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":3300,"kind":"page","lang":"ja","lastmod":1626160103,"objectID":"10a7f69bd03d2632722300194f01e93d","permalink":"https://blog.johtani.info/blog/2021/07/13/attend-mices-2021/","publishdate":"2021-07-13T16:08:23+09:00","readingtime":7,"relpermalink":"/blog/2021/07/13/attend-mices-2021/","section":"post","summary":"今年もMICESにも参加してました。 昨年はBerlin Buzzwordsと共同開催でしたが、今年は別開催（別日程）でした。 MICESは201","tags":["conference","berlin buzzwords","MICES"],"title":"今年もMICESにオンライン出張してた","type":"post","url":"/blog/2021/07/13/attend-mices-2021/","weight":0,"wordcount":3240},{"date":1625815493,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":3000,"kind":"page","lang":"ja","lastmod":1625815493,"objectID":"59b7b60e6bbf4858d72643d22ad90451","permalink":"https://blog.johtani.info/blog/2021/07/09/berlin-buzzwords-2021-1/","publishdate":"2021-07-09T16:24:53+09:00","readingtime":6,"relpermalink":"/blog/2021/07/09/berlin-buzzwords-2021-1/","section":"post","summary":"今年もBerlin Buzzwordsにオンライン出張してました。 今年の開催は6月14日から17日まででした。 どんなカンファレンスなのかは昨年","tags":["conference","berlin buzzwords"],"title":"今年もBerlin Buzzwordsにオンライン出張してた","type":"post","url":"/blog/2021/07/09/berlin-buzzwords-2021-1/","weight":0,"wordcount":2903},{"date":1625130583,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":10800,"kind":"page","lang":"ja","lastmod":1625130583,"objectID":"43caef5d41c4e74826e4a8d82088739d","permalink":"https://blog.johtani.info/blog/2021/07/01/semantic-search-in-azure-cognitive-search/","publishdate":"2021-07-01T18:09:43+09:00","readingtime":22,"relpermalink":"/blog/2021/07/01/semantic-search-in-azure-cognitive-search/","section":"post","summary":"Azure Cognitive Searchで新機能「Semantic Search（セマンティック検索）」という機能の日本語対応が発表されました。 実際にはPublic P","tags":["azure search"],"title":"Azure Cognitive Searchの新機能、Semantic Searchを試してみた","type":"post","url":"/blog/2021/07/01/semantic-search-in-azure-cognitive-search/","weight":0,"wordcount":10723},{"date":1619709972,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":3300,"kind":"page","lang":"ja","lastmod":1619709972,"objectID":"f4baa43cc7ca712d83b99a794c4e2dbd","permalink":"https://blog.johtani.info/blog/2021/04/30/build-lunakey-mini-ble/","publishdate":"2021-04-30T00:26:12+09:00","readingtime":7,"relpermalink":"/blog/2021/04/30/build-lunakey-mini-ble/","section":"post","summary":"Sofle v2を長らく使っていましたが、コンパクトなのもやっぱりいいよなぁというときにKochi KeyboardからLunakey Miniが発売して","tags":["DIYキーボード","misc"],"title":"Lunakey Miniを組み立てて、BLE+LPME-IO化してみた #DIYキーボード","type":"post","url":"/blog/2021/04/30/build-lunakey-mini-ble/","weight":0,"wordcount":3274},{"date":1617615911,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":1700,"kind":"page","lang":"ja","lastmod":1617615911,"objectID":"f41d4fde94cbd7bbd28808dc080a2019","permalink":"https://blog.johtani.info/blog/2021/04/05/intro-marp/","publishdate":"2021-04-05T18:45:11+09:00","readingtime":4,"relpermalink":"/blog/2021/04/05/intro-marp/","section":"post","summary":"みなさんは、スライドの作成には何を使っていますか？ Keynote？Powerpoint？Google Slides？ 私は、Macでスライドを作","tags":["勉強会"],"title":"スライド作成の環境をMarpにしてみた","type":"post","url":"/blog/2021/04/05/intro-marp/","weight":0,"wordcount":1667},{"date":1617200894,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1617200894,"objectID":"ce426b7f3190c8a4a47d45ac799e91a4","permalink":"https://blog.johtani.info/blog/2021/03/31/search-tech-jp-slack/","publishdate":"2021-03-31T23:28:14+09:00","readingtime":2,"relpermalink":"/blog/2021/03/31/search-tech-jp-slack/","section":"post","summary":"新型コロナウィルスの影響もあり、オフラインで集まって勉強会も開催できなくなっています。 検索技術勉強会も、もう1年以上開催できていないです。 ス","tags":["勉強会"],"title":"検索技術に関する情報交換を目的としたSlackができました！","type":"post","url":"/blog/2021/03/31/search-tech-jp-slack/","weight":0,"wordcount":642},{"date":1614756213,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":4300,"kind":"page","lang":"ja","lastmod":1614756213,"objectID":"eced95e5f301a8340e83d81d3c0d5c0d","permalink":"https://blog.johtani.info/blog/2021/03/03/phrase-query-in-japanese/","publishdate":"2021-03-03T16:23:33+09:00","readingtime":9,"relpermalink":"/blog/2021/03/03/phrase-query-in-japanese/","section":"post","summary":"Azure Cognitive SearchにはOData式という書式で条件が書ける仕組みがあります。 ODataは検索条件（$filter）やソート条件（$orderb","tags":["azure search","elasticsearch"],"title":"OData式と日本語の検索(NGram)とフレーズ検索","type":"post","url":"/blog/2021/03/03/phrase-query-in-japanese/","weight":0,"wordcount":4269},{"date":1614246182,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":2900,"kind":"page","lang":"ja","lastmod":1614246182,"objectID":"fcb0105fa6b5777a133f247784b9d930","permalink":"https://blog.johtani.info/blog/2021/02/25/update-working-facility/","publishdate":"2021-02-25T18:43:02+09:00","readingtime":6,"relpermalink":"/blog/2021/02/25/update-working-facility/","section":"post","summary":"自宅の環境がいろいろと変わったのですが、書いていなかったので更新版です。 前回のブログ(2020/09)、前々回のブログ(2020/03)はそ","tags":["misc"],"title":"自宅の作業環境(2021/02)","type":"post","url":"/blog/2021/02/25/update-working-facility/","weight":0,"wordcount":2802},{"date":1612515120,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":4500,"kind":"page","lang":"ja","lastmod":1612515120,"objectID":"931b2ebd9bfaeb5dcf1973e724a1f8d0","permalink":"https://blog.johtani.info/blog/2021/02/05/autocomplete-and-suggest-on-azure-search/","publishdate":"2021-02-05T17:52:00+09:00","readingtime":9,"relpermalink":"/blog/2021/02/05/autocomplete-and-suggest-on-azure-search/","section":"post","summary":"Azure Cognitive SearchにSuggestやAutocompleteの機能があるのを見つけたので、どんな挙動なのかを調べてログとして残しておきます。 公","tags":["azure search"],"title":"Azure Cognitive Searchでオートコンプリートやサジェストをしてみる","type":"post","url":"/blog/2021/02/05/autocomplete-and-suggest-on-azure-search/","weight":0,"wordcount":4446},{"date":1612424444,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":600,"kind":"page","lang":"ja","lastmod":1612424444,"objectID":"aa61b4543e8a7c67fccabee27a6e99cd","permalink":"https://blog.johtani.info/blog/2021/02/04/reading-elements-of-computing-systems/","publishdate":"2021-02-04T16:40:44+09:00","readingtime":2,"relpermalink":"/blog/2021/02/04/reading-elements-of-computing-systems/","section":"post","summary":"オライリー・ジャパンから出ている「コンピュータシステムの理論と実装」を読み始めたのでメモを取ることに。 原著はオライリーじゃないのかというのが","tags":["輪読","Nand2Tetris"],"title":"「コンピュータシステムの理論と実装」を読み始めた #Nand2Tetris","type":"post","url":"/blog/2021/02/04/reading-elements-of-computing-systems/","weight":0,"wordcount":564},{"date":1612106122,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":4000,"kind":"page","lang":"ja","lastmod":1612106122,"objectID":"d95522c691013bfe66dd46ded85a98ed","permalink":"https://blog.johtani.info/blog/2021/02/01/apply-ble-to-sofle/","publishdate":"2021-02-01T00:15:22+09:00","readingtime":8,"relpermalink":"/blog/2021/02/01/apply-ble-to-sofle/","section":"post","summary":"Corne使ってましたが、数字キーがあるとどうなのかな？というのがやはり気になって。 そこに、Kochi KeyboardさんからSofle Keyboard v","tags":["DIYキーボード","misc"],"title":"Sofle v2を組み立てて、BLE+LPME-IO化してみた #DIYキーボード","type":"post","url":"/blog/2021/02/01/apply-ble-to-sofle/","weight":0,"wordcount":3955},{"date":1610332951,"dir":"post/2021/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1610332951,"objectID":"4ad8239a37f641bcd17abeb96106314e","permalink":"https://blog.johtani.info/blog/2021/01/11/apply-ble-and-lpme-to-corne/","publishdate":"2021-01-11T11:42:31+09:00","readingtime":6,"relpermalink":"/blog/2021/01/11/apply-ble-and-lpme-to-corne/","section":"post","summary":"メインマシンとMacは下記のサンワサプライのUSB接続のKVMスイッチを使っていますが、もう一台ノートPCがありここに接続しているCorne","tags":["DIYキーボード","misc"],"title":"Corne Light v2のBLE+LPME-IO対応 #DIYキーボード","type":"post","url":"/blog/2021/01/11/apply-ble-and-lpme-to-corne/","weight":0,"wordcount":2753},{"date":1609422526,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1609422526,"objectID":"64a421c2367372c3199c66a6420faf89","permalink":"https://blog.johtani.info/blog/2020/12/31/diy-pc/","publishdate":"2020-12-31T22:48:46+09:00","readingtime":4,"relpermalink":"/blog/2020/12/31/diy-pc/","section":"post","summary":"振り返りブログにも書きましたが、デスクトップPCを自作(DIY)しました。 組み立てたに使ったパーツのアフィリンクを貼っておきます。 10月くら","tags":["misc"],"title":"PCもDIYしました","type":"post","url":"/blog/2020/12/31/diy-pc/","weight":0,"wordcount":1772},{"date":1609406004,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":3100,"kind":"page","lang":"ja","lastmod":1609406004,"objectID":"a5b2ee641e10d3e4db8f888217ab9ecc","permalink":"https://blog.johtani.info/blog/2020/12/31/looking-back-2020/","publishdate":"2020-12-31T18:13:24+09:00","readingtime":7,"relpermalink":"/blog/2020/12/31/looking-back-2020/","section":"post","summary":"今年も振り返りブログ書いてます。カタンの航海者版を購入して家族とやってましたが、負けてしまいました。 振り返り（2019年に書いた抱負から） ま","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2020）","type":"post","url":"/blog/2020/12/31/looking-back-2020/","weight":0,"wordcount":3020},{"date":1608216955,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":7400,"kind":"page","lang":"ja","lastmod":1608216955,"objectID":"c6fc88bd57a0e57ddf22e2eb1bef892c","permalink":"https://blog.johtani.info/blog/2020/12/17/index_template_v2/","publishdate":"2020-12-17T23:55:55+09:00","readingtime":15,"relpermalink":"/blog/2020/12/17/index_template_v2/","section":"post","summary":"Elastic stack (Elasticsearch) Advent Calendar 2020の18日目の記事になります。 本日の勉強会でLTをしましたが、しゃべり足りなかったんで。 Elasticsearch 7.8でこっそりとリリースされたI","tags":["elasticsearch"],"title":"Index Template V2","type":"post","url":"/blog/2020/12/17/index_template_v2/","weight":0,"wordcount":7377},{"date":1607004824,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":4200,"kind":"page","lang":"ja","lastmod":1607004824,"objectID":"a46c601d03a3a26bc418d0096fe83a42","permalink":"https://blog.johtani.info/blog/2020/12/03/build_corne_choc/","publishdate":"2020-12-03T23:13:44+09:00","readingtime":9,"relpermalink":"/blog/2020/12/03/build_corne_choc/","section":"post","summary":"はじめまして、pyspa。 ということで、pyspa Advent Calendar 2020の4日目(大谷コンビの2号)の投稿になります。 コンビそろってキーボード記事です","tags":["DIYキーボード","misc"],"title":"Corne Chocolateを組み立てた #DIYキーボード","type":"post","url":"/blog/2020/12/03/build_corne_choc/","weight":0,"wordcount":4126},{"date":1604503527,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":5500,"kind":"page","lang":"ja","lastmod":1604503527,"objectID":"b16bddd1a6d3e5f4136446bebe7ffbc7","permalink":"https://blog.johtani.info/blog/2020/11/05/build-corne-light-v2/","publishdate":"2020-11-05T00:25:27+09:00","readingtime":11,"relpermalink":"/blog/2020/11/05/build-corne-light-v2/","section":"post","summary":"前回のブログのまとめに書いたように、セパレートタイプのキーボードであるCorne Light v2を作成したのでそのビルドログです。DIYキーボードとし","tags":["DIYキーボード","misc"],"title":"Corne Light v2を作成した #DIYキーボード","type":"post","url":"/blog/2020/11/05/build-corne-light-v2/","weight":0,"wordcount":5459},{"date":1603029710,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":3500,"kind":"page","lang":"ja","lastmod":1603029710,"objectID":"188c1ee5132a6752dfce5a0235354070","permalink":"https://blog.johtani.info/blog/2020/10/18/restart-windows-no1/","publishdate":"2020-10-18T23:01:50+09:00","readingtime":7,"relpermalink":"/blog/2020/10/18/restart-windows-no1/","section":"post","summary":"ヒゲが不評だったのでいつも通りの長さに切りました。 前回「Windowsをお試し中」と書きましたが、いくつかソフトをインストールしたりしたので","tags":["misc","windows"],"title":"Windowsへの移行（その１）","type":"post","url":"/blog/2020/10/18/restart-windows-no1/","weight":0,"wordcount":3425},{"date":1602727442,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1602727442,"objectID":"de37d9fae011687eb1eb5a127fcb89e3","permalink":"https://blog.johtani.info/blog/2020/10/15/restart-windows/","publishdate":"2020-10-15T11:04:02+09:00","readingtime":4,"relpermalink":"/blog/2020/10/15/restart-windows/","section":"post","summary":"ヒゲが伸びてきて(試しに伸ばしてる)不評を買っている今日このごろです。 自宅で作業することが多くなってきたので、自作PCでもと思っていますが、","tags":["misc","windows"],"title":"Windowsをお試し中","type":"post","url":"/blog/2020/10/15/restart-windows/","weight":0,"wordcount":1756},{"date":1602428006,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":3600,"kind":"page","lang":"ja","lastmod":1602428006,"objectID":"c377351433a941a927aab543931f6026","permalink":"https://blog.johtani.info/blog/2020/10/11/build-dozen0/","publishdate":"2020-10-11T23:53:26+09:00","readingtime":8,"relpermalink":"/blog/2020/10/11/build-dozen0/","section":"post","summary":"今年の春くらいから、セパレートタイプのキーボードが気になっています。 また、なんか知らないですが、Twitterのタイムラインが自作キーボード","tags":["DIYキーボード","misc"],"title":"Dozen0を作成した #DIYキーボード","type":"post","url":"/blog/2020/10/11/build-dozen0/","weight":0,"wordcount":3554},{"date":1601865378,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":4600,"kind":"page","lang":"ja","lastmod":1601865378,"objectID":"15932a656f7acfac897d27766eadc9e2","permalink":"https://blog.johtani.info/blog/2020/10/05/switch-fst-2-da/","publishdate":"2020-10-05T11:36:18+09:00","readingtime":10,"relpermalink":"/blog/2020/10/05/switch-fst-2-da/","section":"post","summary":"2020/10/06 11:00くらいにマージされました。 @minoru_osuka さんが開発を引き継いだLinderaというKuromojiのRustクローンがあります(リポジトリ)","tags":["Rust","Lindera"],"title":"LinderaのFSTをDoubleArrayTrieに変更した話","type":"post","url":"/blog/2020/10/05/switch-fst-2-da/","weight":0,"wordcount":4521},{"date":1600136614,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":3100,"kind":"page","lang":"ja","lastmod":1600136614,"objectID":"b2c4cf0fb96d02d37f03668caaecbc57","permalink":"https://blog.johtani.info/blog/2020/09/15/improve-search-no3/","publishdate":"2020-09-15T11:23:34+09:00","readingtime":6,"relpermalink":"/blog/2020/09/15/improve-search-no3/","section":"post","summary":"先日は「検索システムを構成するパーツ」ということで検索システムを構成しているパーツについて書いてみました。 大体、検索がうまくヒットしないとい","tags":["検索"],"title":"検索対象のデータとデータソース(検索システムに関する妄想その3)","type":"post","url":"/blog/2020/09/15/improve-search-no3/","weight":0,"wordcount":3003},{"date":1599531445,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":4200,"kind":"page","lang":"ja","lastmod":1599531445,"objectID":"d08a3fdc040bbbdd81c9927ce296318c","permalink":"https://blog.johtani.info/blog/2020/09/08/update-working-facility/","publishdate":"2020-09-08T11:17:25+09:00","readingtime":9,"relpermalink":"/blog/2020/09/08/update-working-facility/","section":"post","summary":"自宅環境に少しアップデートがあったので更新版です。 お客さんのおかげで相変わらず自宅で作業させてもらってるのもあり、昨今のコロナウイルスの影響","tags":["misc"],"title":"自宅の作業環境(2020/09)","type":"post","url":"/blog/2020/09/08/update-working-facility/","weight":0,"wordcount":4132},{"date":1599487900,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":3000,"kind":"page","lang":"ja","lastmod":1599487900,"objectID":"827de2d7a9d231f6bcb44caf35896c1f","permalink":"https://blog.johtani.info/blog/2020/09/07/intro-metered-rs/","publishdate":"2020-09-07T23:11:40+09:00","readingtime":6,"relpermalink":"/blog/2020/09/07/intro-metered-rs/","section":"post","summary":"Rustで便利なクレートを見つけたので、紹介がてら、自分のメモのためにブログに残しておきます。 そもそもの問題 Rustで処理を書いていて、なん","tags":["Rust"],"title":"meteredクレートの紹介","type":"post","url":"/blog/2020/09/07/intro-metered-rs/","weight":0,"wordcount":2974},{"date":1599445027,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1599445027,"objectID":"3c5d4d351e0fb9e33e0e8b6d1d43c0f2","permalink":"https://blog.johtani.info/blog/2020/09/07/reboot-nlp100-ch04/","publishdate":"2020-09-07T11:17:07+09:00","readingtime":6,"relpermalink":"/blog/2020/09/07/reboot-nlp100-ch04/","section":"post","summary":"Rustで言語処理100本ノックの第4章です。 前回はこちら。 今回は早めに続きをやりました。 「形態素解析」ですしね。 第4章の概要 吾輩は猫である","tags":["Rust","nlp100"],"title":"第4章終了(言語処理100本ノック2020)","type":"post","url":"/blog/2020/09/07/reboot-nlp100-ch04/","weight":0,"wordcount":2537},{"date":1599230785,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2300,"kind":"page","lang":"ja","lastmod":1599230785,"objectID":"eb2a5824e03996c1966bee38866ce349","permalink":"https://blog.johtani.info/blog/2020/09/04/reboot-nlp100-ch03/","publishdate":"2020-09-04T23:46:25+09:00","readingtime":5,"relpermalink":"/blog/2020/09/04/reboot-nlp100-ch03/","section":"post","summary":"Rustで言語処理100本ノックの第3章です。 前回はこちら。 少し間が空きましたが、再開しました。 間が空いた理由は。。。「正規表現」ですかね。","tags":["Rust","nlp100"],"title":"第3章終了(言語処理100本ノック2020)","type":"post","url":"/blog/2020/09/04/reboot-nlp100-ch03/","weight":0,"wordcount":2276},{"date":1597742807,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1597742807,"objectID":"f5effd616a3f8db6193b482caec37912","permalink":"https://blog.johtani.info/blog/2020/08/18/azure-search-with-terraform/","publishdate":"2020-08-18T18:26:47+09:00","readingtime":4,"relpermalink":"/blog/2020/08/18/azure-search-with-terraform/","section":"post","summary":"負荷を計測するために、数回、Azure Cognitive Searchのクラスターを起動したり、停止したりしてました。 これは、Terraformでやると楽でき","tags":["azure search"],"title":"TerraformでAzure Cognitive Searchのクラスターを起動","type":"post","url":"/blog/2020/08/18/azure-search-with-terraform/","weight":0,"wordcount":1957},{"date":1595907282,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":3400,"kind":"page","lang":"ja","lastmod":1595907282,"objectID":"11a61827e80739a6065960eb188d5758","permalink":"https://blog.johtani.info/blog/2020/07/28/improve-search-no2/","publishdate":"2020-07-28T12:34:42+09:00","readingtime":7,"relpermalink":"/blog/2020/07/28/improve-search-no2/","section":"post","summary":"先日は「システムの特徴と検索機能について」という感じでふんわり書きました。 まぁ、頭の中でぼんやり考えてることを文章にしてみた感じです。 他にも","tags":["検索"],"title":"検索システムを構成するパーツ(検索システムに関する妄想その2)","type":"post","url":"/blog/2020/07/28/improve-search-no2/","weight":0,"wordcount":3308},{"date":1595842134,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":4900,"kind":"page","lang":"ja","lastmod":1595842134,"objectID":"9da845cd31310b8952efd1be1881e651","permalink":"https://blog.johtani.info/blog/2020/07/27/improve-search-no1/","publishdate":"2020-07-27T18:28:54+09:00","readingtime":10,"relpermalink":"/blog/2020/07/27/improve-search-no1/","section":"post","summary":"今年の頭からシステムの検索周りを手伝う仕事をフリーランスとしてやっています。 検索の仕組みを知れば知るほど面白くなってきたからという理由になる","tags":["検索"],"title":"システムの特徴と検索機能について(検索システムに関する妄想その1)","type":"post","url":"/blog/2020/07/27/improve-search-no1/","weight":0,"wordcount":4875},{"date":1594288778,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1594288778,"objectID":"208a8c072ea521c813b86ca7730eb880","permalink":"https://blog.johtani.info/blog/2020/07/09/hap15-rust-the-book/","publishdate":"2020-07-09T18:59:38+09:00","readingtime":2,"relpermalink":"/blog/2020/07/09/hap15-rust-the-book/","section":"post","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第15章","type":"post","url":"/blog/2020/07/09/hap15-rust-the-book/","weight":0,"wordcount":864},{"date":1594005164,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":4000,"kind":"page","lang":"ja","lastmod":1594005164,"objectID":"e5cb2e5d501d3db2db5d8f14984a66d4","permalink":"https://blog.johtani.info/blog/2020/07/06/attend-berlin-buzzwords/","publishdate":"2020-07-06T12:12:44+09:00","readingtime":8,"relpermalink":"/blog/2020/07/06/attend-berlin-buzzwords/","section":"post","summary":"6月7日の週に開催されたBerlin Buzzwordsにオンライン出張してました。 Berlin Buzzwordsとは? ベルリンで開催されている、Big","tags":["conference","berlin buzzwords"],"title":"Berlin Buzzwordsにオンライン出張してた","type":"post","url":"/blog/2020/07/06/attend-berlin-buzzwords/","weight":0,"wordcount":3970},{"date":1593050518,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1593050518,"objectID":"bbd2824ff0d5b801bb6f5da3a2a1a888","permalink":"https://blog.johtani.info/blog/2020/06/25/analyzer-perf-test-with-luceneutil/","publishdate":"2020-06-25T11:01:58+09:00","readingtime":6,"relpermalink":"/blog/2020/06/25/analyzer-perf-test-with-luceneutil/","section":"post","summary":"luceneutil - マニアックなツールのセットアップの続きです。 今回も誰得?なブログなので興味ない場合は飛ばしましょう。 一応、luceneutilのREAD","tags":["lucene"],"title":"luceneutil - Analyzer性能テストへのkuromojiの追加","type":"post","url":"/blog/2020/06/25/analyzer-perf-test-with-luceneutil/","weight":0,"wordcount":2698},{"date":1592917109,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1592917109,"objectID":"8a1ea5d5cf843bc5955a94cfcc321e92","permalink":"https://blog.johtani.info/blog/2020/06/23/how-to-use-luceneutil/","publishdate":"2020-06-23T21:58:29+09:00","readingtime":4,"relpermalink":"/blog/2020/06/23/how-to-use-luceneutil/","section":"post","summary":"LuceneのFSTの修正に関連して、Kuromojiのパフォーマンス問題が出ているようです。 この問題自体はLucene 8.6.0以降で直る","tags":["lucene"],"title":"luceneutil - マニアックなツールのセットアップ","type":"post","url":"/blog/2020/06/23/how-to-use-luceneutil/","weight":0,"wordcount":1711},{"date":1591692240,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2900,"kind":"page","lang":"ja","lastmod":1591692240,"objectID":"82a115ab8d617e4e96813587fe3a6049","permalink":"https://blog.johtani.info/blog/2020/06/09/difference-analyzers-in-azure-search/","publishdate":"2020-06-09T17:44:00+09:00","readingtime":6,"relpermalink":"/blog/2020/06/09/difference-analyzers-in-azure-search/","section":"post","summary":"Azure Cognitive Searchで日本語を扱うときに、形態素解析器を使いたい場合、2種類のAnalyzerが用意されています。今回はこれらの違いがどんなもの","tags":["azure search","kuromoji"],"title":"Azure Cognitive Searchでの日本語向けAnalyzerの違い","type":"post","url":"/blog/2020/06/09/difference-analyzers-in-azure-search/","weight":0,"wordcount":2827},{"date":1591259849,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1591259849,"objectID":"e74d071363645a588f858b35231128c4","permalink":"https://blog.johtani.info/blog/2020/06/04/chap13-rust-the-book/","publishdate":"2020-06-04T17:37:29+09:00","readingtime":3,"relpermalink":"/blog/2020/06/04/chap13-rust-the-book/","section":"post","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第13章","type":"post","url":"/blog/2020/06/04/chap13-rust-the-book/","weight":0,"wordcount":1045},{"date":1590656815,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1590656815,"objectID":"163beeae9620c1a6a46a38aa7ebd9663","permalink":"https://blog.johtani.info/blog/2020/05/28/chap10-rust-the-book/","publishdate":"2020-05-28T18:06:55+09:00","readingtime":4,"relpermalink":"/blog/2020/05/28/chap10-rust-the-book/","section":"post","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第10章","type":"post","url":"/blog/2020/05/28/chap10-rust-the-book/","weight":0,"wordcount":1519},{"date":1590481367,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":4900,"kind":"page","lang":"ja","lastmod":1590481367,"objectID":"36dd94159e3e60076c0c6098086e255f","permalink":"https://blog.johtani.info/blog/2020/05/26/logging-azure-search-request/","publishdate":"2020-05-26T17:22:47+09:00","readingtime":10,"relpermalink":"/blog/2020/05/26/logging-azure-search-request/","section":"post","summary":"今回はAzure Cognitive SearchのSDKを利用したアプリケーションが、実際にAzure Cognitive Searchに対して送信しているリクエストのパラメータ","tags":["azure search",".net"],"title":"Azure Cognitive Searchのリクエストのロギング","type":"post","url":"/blog/2020/05/26/logging-azure-search-request/","weight":0,"wordcount":4847},{"date":1590117041,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1590117041,"objectID":"21982f43bc435f22efef22b309a48c66","permalink":"https://blog.johtani.info/blog/2020/05/22/watching-azure-cognirive-search-session-at-ms-build/","publishdate":"2020-05-22T12:10:41+09:00","readingtime":2,"relpermalink":"/blog/2020/05/22/watching-azure-cognirive-search-session-at-ms-build/","section":"post","summary":"Mircosoft Buildというイベントが今週ありました(MSの方やお客さんに教えてもらった)。 そこで、Azure Cognitive Searchのセッション(MyBuil","tags":["azure search"],"title":"Microsoft Build(2020)のAzure Cognirive Searchのセッションを見たのでメモ","type":"post","url":"/blog/2020/05/22/watching-azure-cognirive-search-session-at-ms-build/","weight":0,"wordcount":860},{"date":1589509037,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":3000,"kind":"page","lang":"ja","lastmod":1589509037,"objectID":"306cecb32320ead508346ad8fed3394d","permalink":"https://blog.johtani.info/blog/2020/05/15/elastic-stack-7_7/","publishdate":"2020-05-15T11:17:17+09:00","readingtime":6,"relpermalink":"/blog/2020/05/15/elastic-stack-7_7/","section":"post","summary":"ElasticのWorkplace Searchを触ってみています(その1、その2)が、Elastic Stackの7.7.0がリリースされてし","tags":["elastic stack"],"title":"Elastic Stack 7.7がリリースされた","type":"post","url":"/blog/2020/05/15/elastic-stack-7_7/","weight":0,"wordcount":2961},{"date":1589449406,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":400,"kind":"page","lang":"ja","lastmod":1589449406,"objectID":"1e220a934e16fd941bd804ca03865b60","permalink":"https://blog.johtani.info/blog/2020/05/14/chap9-rust-the-book/","publishdate":"2020-05-14T18:43:26+09:00","readingtime":1,"relpermalink":"/blog/2020/05/14/chap9-rust-the-book/","section":"post","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第9章","type":"post","url":"/blog/2020/05/14/chap9-rust-the-book/","weight":0,"wordcount":397},{"date":1589253809,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2300,"kind":"page","lang":"ja","lastmod":1589253809,"objectID":"09155bf417a93847b538ad607f78cca2","permalink":"https://blog.johtani.info/blog/2020/05/12/reboot-nlp100-ch02-12to19/","publishdate":"2020-05-12T12:23:29+09:00","readingtime":5,"relpermalink":"/blog/2020/05/12/reboot-nlp100-ch02-12to19/","section":"post","summary":"Rustで言語処理100本ノックの第2章の残りです。 前回はこちら。 ちなみに、標準入力から受け取る処理は書いてないです。 出力に関してはファイル","tags":["Rust","nlp100"],"title":"第2章の12から19まで(言語処理100本ノック2020)","type":"post","url":"/blog/2020/05/12/reboot-nlp100-ch02-12to19/","weight":0,"wordcount":2237},{"date":1588948640,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1588948640,"objectID":"c098c6f0901979bd914ed7a345200f90","permalink":"https://blog.johtani.info/blog/2020/05/08/rebootnlp100-ch02-10to11/","publishdate":"2020-05-08T23:37:20+09:00","readingtime":4,"relpermalink":"/blog/2020/05/08/rebootnlp100-ch02-10to11/","section":"post","summary":"気づいたら1ヶ月サボってました、ごめんなさい。。。 Rustで言語処理100本ノックの第2章をはじめました。 前回はこちら。 確認用のUnixコマ","tags":["Rust","nlp100"],"title":"第2章の10から11まで(言語処理100本ノック2020)","type":"post","url":"/blog/2020/05/08/rebootnlp100-ch02-10to11/","weight":0,"wordcount":1531},{"date":1588923657,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1588923657,"objectID":"2c3270f8797ace2fb37402ea6a09d126","permalink":"https://blog.johtani.info/blog/2020/05/08/reboot-nlp100-finish-ch01/","publishdate":"2020-05-08T16:40:57+09:00","readingtime":2,"relpermalink":"/blog/2020/05/08/reboot-nlp100-finish-ch01/","section":"post","summary":"Rustで言語処理100本ノックのリファクタリングの続き。 前回はこちら。 とっくに終わってたのに、ブログ書いてなかった。。。 08. 暗号文 pub fn cipher(text: \u0026amp;str) -\u0026gt;","tags":["Rust","nlp100"],"title":"第1章の08から09まで(言語処理100本ノック2020)","type":"post","url":"/blog/2020/05/08/reboot-nlp100-finish-ch01/","weight":0,"wordcount":828},{"date":1588818770,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":3300,"kind":"page","lang":"ja","lastmod":1588818770,"objectID":"44db1f1fefc97cd28d55d443f2bd2b63","permalink":"https://blog.johtani.info/blog/2020/05/07/install-workplace-search/","publishdate":"2020-05-07T11:32:50+09:00","readingtime":7,"relpermalink":"/blog/2020/05/07/install-workplace-search/","section":"post","summary":"前回はWorkplace Searchの概要について書きましたが、今回はインストールと構成要素について説明します。なお、2020/5/7時点で","tags":["elasticsearch","workplace search"],"title":"ElasticのWorkplace Searchを触ってみる - その2 - インストールと起動","type":"post","url":"/blog/2020/05/07/install-workplace-search/","weight":0,"wordcount":3222},{"date":1588318144,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1700,"kind":"page","lang":"ja","lastmod":1588318144,"objectID":"4d71d2a23c85fb7af20e8d1e8b3e0de8","permalink":"https://blog.johtani.info/blog/2020/05/01/intro-workplace-search/","publishdate":"2020-05-01T16:29:04+09:00","readingtime":4,"relpermalink":"/blog/2020/05/01/intro-workplace-search/","section":"post","summary":"2月のElastic社のブログですが、Enterprise Searchとこれまで呼んでいた製品をWorkplace Searchという製品名に","tags":["elasticsearch","workplace search"],"title":"ElasticのWorkplace Searchを触ってみる - その1","type":"post","url":"/blog/2020/05/01/intro-workplace-search/","weight":0,"wordcount":1696},{"date":1587951855,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":4000,"kind":"page","lang":"ja","lastmod":1587951855,"objectID":"be2c49ea5816e7daa6d3b3ff45353291","permalink":"https://blog.johtani.info/blog/2020/04/27/note-updating-dictionary/","publishdate":"2020-04-27T10:44:15+09:00","readingtime":8,"relpermalink":"/blog/2020/04/27/note-updating-dictionary/","section":"post","summary":"先日、Elasticsearchでのカスタム辞書の利用方法についてブログを書きました。 辞書の設定方法について記載しましたが、今回は辞書の更新","tags":["elasticsearch"],"title":"辞書の更新についての注意点","type":"post","url":"/blog/2020/04/27/note-updating-dictionary/","weight":0,"wordcount":3938},{"date":1587519056,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1587519056,"objectID":"15357b6978e83daa2d97692c861dc177","permalink":"https://blog.johtani.info/blog/2020/04/22/custom-dictionary-after-7-4/","publishdate":"2020-04-22T10:30:56+09:00","readingtime":4,"relpermalink":"/blog/2020/04/22/custom-dictionary-after-7-4/","section":"post","summary":"Elasticsearchで日本語を扱うときに、カスタム辞書を使いたいという要望がよくあります。 AWSのElasticsearch Servi","tags":["elasticsearch"],"title":"Kuromojiのカスタム辞書をインデックスの設定で指定","type":"post","url":"/blog/2020/04/22/custom-dictionary-after-7-4/","weight":0,"wordcount":1910},{"date":1587028650,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1587028650,"objectID":"f488aa62d39194824861a134567cadb8","permalink":"https://blog.johtani.info/blog/2020/04/16/chap8-rust-the-book/","publishdate":"2020-04-16T18:17:30+09:00","readingtime":4,"relpermalink":"/blog/2020/04/16/chap8-rust-the-book/","section":"post","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 第8章 7章はパ","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第8章","type":"post","url":"/blog/2020/04/16/chap8-rust-the-book/","weight":0,"wordcount":1744},{"date":1586423695,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1586423695,"objectID":"9a687babb0f44db51dc389b75bdaa19d","permalink":"https://blog.johtani.info/blog/2020/04/09/reboot-nlp100-ch01-03to05/","publishdate":"2020-04-09T18:14:55+09:00","readingtime":2,"relpermalink":"/blog/2020/04/09/reboot-nlp100-ch01-03to05/","section":"post","summary":"Rustで言語処理100本ノックのリファクタリングの続き。 前回はこちら。 コードも載せたほうが見やすいかなぁ? 03. 円周率 2年前はこちら。 どちらか","tags":["Rust","nlp100"],"title":"第1章の03から06まで(言語処理100本ノック2020)","type":"post","url":"/blog/2020/04/09/reboot-nlp100-ch01-03to05/","weight":0,"wordcount":812},{"date":1586338425,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1586338425,"objectID":"dc9580308938069159c5afc55b2f3b96","permalink":"https://blog.johtani.info/blog/2020/04/08/reboot-nlp10-with-rust/","publishdate":"2020-04-08T18:33:45+09:00","readingtime":3,"relpermalink":"/blog/2020/04/08/reboot-nlp10-with-rust/","section":"post","summary":"今回もツイートから。 言語処理100本ノックの2020年版を公開しました。最近の自然言語処理の研究動向を反映し、深層ニューラルネットワークに関","tags":["Rust","nlp100"],"title":"言語処理100本ノック、再び","type":"post","url":"/blog/2020/04/08/reboot-nlp10-with-rust/","weight":0,"wordcount":1013},{"date":1586255231,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1586255231,"objectID":"4fbdc9c57a37781dc5dd86f470c61d04","permalink":"https://blog.johtani.info/blog/2020/04/07/chap6-rust-the-book/","publishdate":"2020-04-07T19:27:11+09:00","readingtime":2,"relpermalink":"/blog/2020/04/07/chap6-rust-the-book/","section":"post","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 第6章 Enumです。matc","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第6章","type":"post","url":"/blog/2020/04/07/chap6-rust-the-book/","weight":0,"wordcount":721},{"date":1586143600,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1586143600,"objectID":"6fbf7c3d0f4f89e415e89cec28811a94","permalink":"https://blog.johtani.info/blog/2020/04/06/update-kuromoji-cli/","publishdate":"2020-04-06T12:26:40+09:00","readingtime":3,"relpermalink":"/blog/2020/04/06/update-kuromoji-cli/","section":"post","summary":"Kuromoji-CLIの使い方などについては過去のブログを御覧ください。 KuromojiのCLIコマンドとpicocliとGraalVM G","tags":["misc"],"title":"KuromojiのCLIコマンドにJSON出力とラティス出力を追加","type":"post","url":"/blog/2020/04/06/update-kuromoji-cli/","weight":0,"wordcount":1470},{"date":1585807758,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1200,"kind":"page","lang":"ja","lastmod":1585807758,"objectID":"8d9c3760395e8e0eb40e335b22750b68","permalink":"https://blog.johtani.info/blog/2020/04/02/chap5-rust-the-book/","publishdate":"2020-04-02T15:09:18+09:00","readingtime":3,"relpermalink":"/blog/2020/04/02/chap5-rust-the-book/","section":"post","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 第5章 構造体です。勝手知ったるなんとやら?","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第5章","type":"post","url":"/blog/2020/04/02/chap5-rust-the-book/","weight":0,"wordcount":1128},{"date":1585217511,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1585217511,"objectID":"3f431bf71ee866f626daf42bc915fa3f","permalink":"https://blog.johtani.info/blog/2020/03/26/working-facility/","publishdate":"2020-03-26T19:11:51+09:00","readingtime":6,"relpermalink":"/blog/2020/03/26/working-facility/","section":"post","summary":"すもけさんが在宅勤務環境をブログに書いてておもしろそうだな(あと、アフィリンク貼れるな)と思ったので自分の環境も書いてみようかなと。 私自身は","tags":["misc"],"title":"自宅の作業環境(2020)","type":"post","url":"/blog/2020/03/26/working-facility/","weight":0,"wordcount":2703},{"date":1585210331,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1585210331,"objectID":"7fded0345c258eea966c0b5ee1b7c7aa","permalink":"https://blog.johtani.info/blog/2020/03/26/chap4-rust-the-book/","publishdate":"2020-03-26T17:12:11+09:00","readingtime":3,"relpermalink":"/blog/2020/03/26/chap4-rust-the-book/","section":"post","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた 第4章 第4章です。たぶん、これがいちばん大事な概念だと思","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第4章","type":"post","url":"/blog/2020/03/26/chap4-rust-the-book/","weight":0,"wordcount":1028},{"date":1585102205,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2100,"kind":"page","lang":"ja","lastmod":1585102205,"objectID":"a7f0e85fcad4f5bc5ae5c18c10de4f9e","permalink":"https://blog.johtani.info/blog/2020/03/25/vsc-es-analzye-plugin/","publishdate":"2020-03-25T11:10:05+09:00","readingtime":5,"relpermalink":"/blog/2020/03/25/vsc-es-analzye-plugin/","section":"post","summary":"先日、Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)というブログを書きました。 このプラグインを作ってたタイミン","tags":["elasticsearch","visual studio code"],"title":"ElasticsearchのAnalyze APIのVisual Studio Codeのクライアントプラグイン","type":"post","url":"/blog/2020/03/25/vsc-es-analzye-plugin/","weight":0,"wordcount":2031},{"date":1584928642,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1584928642,"objectID":"48b5ab9805919736382ffea5a9554c02","permalink":"https://blog.johtani.info/blog/2020/03/23/start-reading-rust-the-book/","publishdate":"2020-03-23T10:57:22+09:00","readingtime":3,"relpermalink":"/blog/2020/03/23/start-reading-rust-the-book/","section":"post","summary":"自転車本を読み始めましたが、その前にRust the bookを読んだほうが良いかも?と知り合いと話をしていてなったので、先にRust the bookを読","tags":["rust","読書","rust-the-book"],"title":"Rust the Bookを読み始めた","type":"post","url":"/blog/2020/03/23/start-reading-rust-the-book/","weight":0,"wordcount":1359},{"date":1584582615,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2300,"kind":"page","lang":"ja","lastmod":1584582615,"objectID":"c9d257aba54475c20b3737ce7c779e55","permalink":"https://blog.johtani.info/blog/2020/03/19/azure-search-analyze-plugin/","publishdate":"2020-03-19T10:50:15+09:00","readingtime":5,"relpermalink":"/blog/2020/03/19/azure-search-analyze-plugin/","section":"post","summary":"動機 Azure Cognitive Searchを検索エンジンに使っているお客さんを手伝っています。 そこで、検索の基本的な話をさせていただきました(もともとJJUGナイ","tags":["azure search","visual studio code"],"title":"Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)","type":"post","url":"/blog/2020/03/19/azure-search-analyze-plugin/","weight":0,"wordcount":2288},{"date":1583140813,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":400,"kind":"page","lang":"ja","lastmod":1583140813,"objectID":"6f47cb314fd780c122adb8cc1f44f785","permalink":"https://blog.johtani.info/blog/2020/03/02/finish-bicycle-book-chap3/","publishdate":"2020-03-02T18:20:13+09:00","readingtime":1,"relpermalink":"/blog/2020/03/02/finish-bicycle-book-chap3/","section":"post","summary":"これまで 実践Rust入門はじめました 実践Rust入門の3章を読んでるところ 3章終了 3章の終わりまで読み終えた。 いきなり実践的なプログラムで少","tags":["rust","読書"],"title":"実践Rust入門の3章を読み終わった","type":"post","url":"/blog/2020/03/02/finish-bicycle-book-chap3/","weight":0,"wordcount":388},{"date":1582858179,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1582858179,"objectID":"d710a073be2da219a388a150eb7b6b6a","permalink":"https://blog.johtani.info/blog/2020/02/28/kuromoji-cli/","publishdate":"2020-02-28T11:49:39+09:00","readingtime":4,"relpermalink":"/blog/2020/02/28/kuromoji-cli/","section":"post","summary":"Kuromoji-CLI Rust初心者がRust製の日本語形態素解析器の開発を引き継いでみたという記事にありますが、LinderaというRust製の日本語形態素解","tags":["misc"],"title":"KuromojiのCLIコマンドとpicocliとGraalVM","type":"post","url":"/blog/2020/02/28/kuromoji-cli/","weight":0,"wordcount":1910},{"date":1582443437,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1582443437,"objectID":"71cf83ae0f45e9ede3a3f979b9c74933","permalink":"https://blog.johtani.info/blog/2020/02/23/bicycle-book-chap3/","publishdate":"2020-02-23T16:37:17+09:00","readingtime":2,"relpermalink":"/blog/2020/02/23/bicycle-book-chap3/","section":"post","summary":"これまでのはこちら。読書メモなので、本と合わせて読んでいただくのが良いです。 実践Rust入門はじめました 3章のクイックツアーを読んでます。 バ","tags":["rust","読書"],"title":"実践Rust入門の3章を読んでるところ","type":"post","url":"/blog/2020/02/23/bicycle-book-chap3/","weight":0,"wordcount":747},{"date":1582272302,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1582272302,"objectID":"daa3fe935b0be9f31b6b362ad9e0d2d6","permalink":"https://blog.johtani.info/blog/2020/02/21/best-buy-2019/","publishdate":"2020-02-21T17:05:02+09:00","readingtime":5,"relpermalink":"/blog/2020/02/21/best-buy-2019/","section":"post","summary":"もう2020年2月になってしまってますが、2019年に買って便利だったもの良かったものをいくつか記録に残しとこうかなと。 BRAVIA KJ-55X9500G Amazon | ソニー SONY 49","tags":["買い物"],"title":"2019年に買ってよかったもの","type":"post","url":"/blog/2020/02/21/best-buy-2019/","weight":0,"wordcount":2394},{"date":1582254240,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1900,"kind":"page","lang":"ja","lastmod":1582254240,"objectID":"ef8a399c9679ce4e9710c7c6ecf8bcc7","permalink":"https://blog.johtani.info/blog/2020/02/21/import-jugem-posts/","publishdate":"2020-02-21T12:04:00+09:00","readingtime":4,"relpermalink":"/blog/2020/02/21/import-jugem-posts/","section":"post","summary":"ブログ移行日記(その5)です。前回まではこちら ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4","tags":["hugo","ブログ"],"title":"ブログ移行日記(その5) - Jugemのブログを移行","type":"post","url":"/blog/2020/02/21/import-jugem-posts/","weight":0,"wordcount":1807},{"date":1582080481,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":5000,"kind":"page","lang":"ja","lastmod":1582080481,"objectID":"c3053579ae25e2fb9b967076a06373af","permalink":"https://blog.johtani.info/blog/2020/02/19/research-azure-cognitive-search/","publishdate":"2020-02-19T11:48:01+09:00","readingtime":10,"relpermalink":"/blog/2020/02/19/research-azure-cognitive-search/","section":"post","summary":"お手伝いしているお客さんがAzure Cognitive Searchを利用してます。 検索周り=Azure Cognitive Searchに関する手伝いをする形で入っており、 いく","tags":["azure search"],"title":"Azure Cognitive Searchでインデックスを作って検索","type":"post","url":"/blog/2020/02/19/research-azure-cognitive-search/","weight":0,"wordcount":4968},{"date":1581344427,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1581344427,"objectID":"7b080dc43fce482af14de61c6ab819a5","permalink":"https://blog.johtani.info/blog/2020/02/10/explore-search-system/","publishdate":"2020-02-10T23:20:27+09:00","readingtime":3,"relpermalink":"/blog/2020/02/10/explore-search-system/","section":"post","summary":"また、ツイートから始まるお話です。 まだまだ、検索システムってどんなものかを勉強したいしということで、こんなのをツイートしてました。 「検索シス","tags":["検索システム探訪"],"title":"「検索システム探訪」したいな=\u003eやりました","type":"post","url":"/blog/2020/02/10/explore-search-system/","weight":0,"wordcount":1481},{"date":1580558694,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1580558694,"objectID":"90f9355781403b92e844de8568863ae8","permalink":"https://blog.johtani.info/blog/2020/02/01/intro-board-game/","publishdate":"2020-02-01T21:04:54+09:00","readingtime":6,"relpermalink":"/blog/2020/02/01/intro-board-game/","section":"post","summary":"年末、何種類かのボードゲームを家族で楽しみました。 家族の感想を交えて簡単に紹介しようかと思います。 家族や知人でボードゲームを購入するときの参","tags":["ゲーム"],"title":"ボードゲーム紹介","type":"post","url":"/blog/2020/02/01/intro-board-game/","weight":0,"wordcount":2587},{"date":1580475492,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1580475492,"objectID":"7fcfaa8dd34dbd508f19e8ca0fcfda0f","permalink":"https://blog.johtani.info/blog/2020/01/31/start-reading-bicycle-book/","publishdate":"2020-01-31T21:58:12+09:00","readingtime":2,"relpermalink":"/blog/2020/01/31/start-reading-bicycle-book/","section":"post","summary":"実践Rust入門という本を買っていた(去年の7月だ。。。)のですが、積んであったので、時間を作って読み始めようかと。 実践Rust入門[言語仕","tags":["rust","読書"],"title":"実践Rust入門はじめました","type":"post","url":"/blog/2020/01/31/start-reading-bicycle-book/","weight":0,"wordcount":793},{"date":1580470659,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1580470659,"objectID":"c61a5bda3f1667498626ae52ad0362e0","permalink":"https://blog.johtani.info/blog/2020/01/31/start-freelance/","publishdate":"2020-01-31T20:37:39+09:00","readingtime":2,"relpermalink":"/blog/2020/01/31/start-freelance/","section":"post","summary":"12月に退職しますブログを書きましたが、その後どうなったのか?という話をしてないなと思ったので、一応現在の状況を書き留めておこううかと。 結論","tags":["転職"],"title":"フリーランスはじめました(仮)","type":"post","url":"/blog/2020/01/31/start-freelance/","weight":0,"wordcount":615},{"date":1580186404,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":3500,"kind":"page","lang":"ja","lastmod":1580283604,"objectID":"d9018f459d3c94a91e92b459e152f7e7","permalink":"https://blog.johtani.info/blog/2020/01/28/introduce-algolia/","publishdate":"2020-01-28T13:40:04+09:00","readingtime":7,"relpermalink":"/blog/2020/01/28/introduce-algolia/","section":"post","summary":"ブログ移行日記(その4)です。その他の記事はこちら。 ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(","tags":["ブログ"],"title":"ブログ移行日記(その4) - 検索機能(Algolia)の導入","type":"post","url":"/blog/2020/01/28/introduce-algolia/","weight":0,"wordcount":3425},{"date":1579853081,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":3000,"kind":"page","lang":"ja","lastmod":1579853081,"objectID":"99c9c80a6532e4ea3b535c5a92d07a25","permalink":"https://blog.johtani.info/blog/2020/01/24/setting-hugo/","publishdate":"2020-01-24T17:04:41+09:00","readingtime":6,"relpermalink":"/blog/2020/01/24/setting-hugo/","section":"post","summary":"ブログ移行日記(その3)です。その他の記事はこちら。 ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その4) ブログ移行日記(","tags":["ブログ"],"title":"ブログ移行日記(その3) - Hugoの設定と微調整(テーマに合わせた)","type":"post","url":"/blog/2020/01/24/setting-hugo/","weight":0,"wordcount":2970},{"date":1579775514,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1579775514,"objectID":"018b365b00dd3a6ad17c813d21590549","permalink":"https://blog.johtani.info/blog/2020/01/23/convert-md-from-octopress-to-hugo/","publishdate":"2020-01-23T19:31:54+09:00","readingtime":3,"relpermalink":"/blog/2020/01/23/convert-md-from-octopress-to-hugo/","section":"post","summary":"その他の記事はこちら ブログ移行日記(その1) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) ブログ移行日記(その2)","tags":["ブログ"],"title":"ブログ移行日記(その2) - Markdownファイルの変換","type":"post","url":"/blog/2020/01/23/convert-md-from-octopress-to-hugo/","weight":0,"wordcount":1287},{"date":1579659814,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1579659814,"objectID":"a65bd31d4c3dab0a41712823a5d6002b","permalink":"https://blog.johtani.info/blog/2020/01/22/intro-hugo-and-theme/","publishdate":"2020-01-22T11:23:34+09:00","readingtime":4,"relpermalink":"/blog/2020/01/22/intro-hugo-and-theme/","section":"post","summary":"その他の記事はこちら ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) 起因 いつものツイートから","tags":["ブログ"],"title":"ブログ移行日記(その1) - Hugoとテーマ","type":"post","url":"/blog/2020/01/22/intro-hugo-and-theme/","weight":0,"wordcount":1586},{"date":1579166617,"dir":"post/2020/","expirydate":-62135596800,"fuzzywordcount":300,"kind":"page","lang":"ja","lastmod":1579166617,"objectID":"3c299a4d77be8b4f886ce9fcd23a2561","permalink":"https://blog.johtani.info/blog/2020/01/16/moving-to-hugo/","publishdate":"2020-01-16T18:23:37+09:00","readingtime":1,"relpermalink":"/blog/2020/01/16/moving-to-hugo/","section":"post","summary":"5年くらい、Octopressを使用していましたが、更新されなくなっているのと、コンテンツの生成に時間がかかることもあり、 ほかのプラットフォ","tags":["hugo","ブログ","octopress"],"title":"OctopressからHugoへ移行中(まだ途中)","type":"post","url":"/blog/2020/01/16/moving-to-hugo/","weight":0,"wordcount":288},{"date":1577764743,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":2900,"kind":"page","lang":"ja","lastmod":1577764743,"objectID":"35aa9e09db936aee7ec407c431816573","permalink":"https://blog.johtani.info/blog/2019/12/31/looking-back-2019/","publishdate":"2019-12-31T12:59:03+09:00","readingtime":6,"relpermalink":"/blog/2019/12/31/looking-back-2019/","section":"post","summary":"今年も振り返りブログ書いてます。Sasukeがついてる。 振り返り（2018年に書いた抱負から） まずは去年の抱負を元に。 TOEIC 受けました。 お。TO","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2019）","type":"post","url":"/blog/2019/12/31/looking-back-2019/","weight":0,"wordcount":2844},{"date":1577063679,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":2200,"kind":"page","lang":"ja","lastmod":1577063679,"objectID":"1a1a8cc0040b356d06eacd22e0526476","permalink":"https://blog.johtani.info/blog/2019/12/23/whats-window-group-of-terminal/","publishdate":"2019-12-23T10:14:39+09:00","readingtime":5,"relpermalink":"/blog/2019/12/23/whats-window-group-of-terminal/","section":"post","summary":"このブログ書こうと思って、これまでMacのセットアップしてたんだった。。。 普段、macOSの標準ターミナルを使ってます。 で、ターミナルを使う","tags":["misc"],"title":"macOS標準のターミナルのウィンドウグループが便利","type":"post","url":"/blog/2019/12/23/whats-window-group-of-terminal/","weight":0,"wordcount":2170},{"date":1576624266,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1576624266,"objectID":"80c8fca02ebfecc7a931dad1ec38466e","permalink":"https://blog.johtani.info/blog/2019/12/18/introduce-homeshick/","publishdate":"2019-12-18T08:11:06+09:00","readingtime":2,"relpermalink":"/blog/2019/12/18/introduce-homeshick/","section":"post","summary":"ドットファイル系（.emacsとか）をこれまでは、PCを引っ越すたびにコピーしてたんですが、いいかげん、GitHubとかで管理したいなと。 で","tags":["misc"],"title":"homeshick導入","type":"post","url":"/blog/2019/12/18/introduce-homeshick/","weight":0,"wordcount":879},{"date":1576542903,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1576542903,"objectID":"f3ef819656f68b87a91c53afbd441fec","permalink":"https://blog.johtani.info/blog/2019/12/17/move-to-zsh/","publishdate":"2019-12-17T09:35:03+09:00","readingtime":3,"relpermalink":"/blog/2019/12/17/move-to-zsh/","section":"post","summary":"Macbook Proが新しくなり、OSがCatalinaになっちゃいました。 これまで使ってた、.bash_profileをコピーしてターミナルを立ち上げ","tags":["misc"],"title":"zshへの移行","type":"post","url":"/blog/2019/12/17/move-to-zsh/","weight":0,"wordcount":1298},{"date":1576458061,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1576458061,"objectID":"1abc586d67f0b6c05fd5e60f25492340","permalink":"https://blog.johtani.info/blog/2019/12/16/dockernize-octopress/","publishdate":"2019-12-16T10:01:01+09:00","readingtime":3,"relpermalink":"/blog/2019/12/16/dockernize-octopress/","section":"post","summary":"最近使っていたPCが手元からなくなったので、16インチ Macbook Proをセットアップしているところです。 で、時間もあるのでこれまでほったらかしてきた","tags":["octopress"],"title":"Octopress環境のDockerイメージ化","type":"post","url":"/blog/2019/12/16/dockernize-octopress/","weight":0,"wordcount":1503},{"date":1575615090,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":400,"kind":"page","lang":"ja","lastmod":1575615090,"objectID":"1bbf2ef67f096960e13d8578fa544536","permalink":"https://blog.johtani.info/blog/2019/12/06/leaving-elastic/","publishdate":"2019-12-06T15:51:30+09:00","readingtime":1,"relpermalink":"/blog/2019/12/06/leaving-elastic/","section":"post","summary":"本日、Elasticでの最終出社日でした。実際の退職日はまだ先ですが、有休消化という感じです。 思い返せばもう5年と5ヶ月も前ですが、Elas","tags":["転職"],"title":"退職します","type":"post","url":"/blog/2019/12/06/leaving-elastic/","weight":0,"wordcount":369},{"date":1575385200,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":2100,"kind":"page","lang":"ja","lastmod":1575385200,"objectID":"c2d39f2f7fe6cb69fc8efb6c5495c932","permalink":"https://blog.johtani.info/blog/2019/12/04/about-lucene-4056/","publishdate":"2019-12-04T00:00:00+09:00","readingtime":5,"relpermalink":"/blog/2019/12/04/about-lucene-4056/","section":"post","summary":"これは、情報検索・検索エンジン Advent Calendar 2019 の 4 日目の記事です。 1日目から、質の高いエントリーが続いていましたが、一旦休憩して頂く感じの記事になって","tags":["Lucene"],"title":"Apache LuceneのKuromojiのUniDicビルド対応パッチについて","type":"post","url":"/blog/2019/12/04/about-lucene-4056/","weight":0,"wordcount":2082},{"date":1575126000,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":3200,"kind":"page","lang":"ja","lastmod":1575126000,"objectID":"78da47d61c91c82809a3c97a791d26d2","permalink":"https://blog.johtani.info/blog/2019/12/01/whats-happen-at-elastic-in-2019/","publishdate":"2019-12-01T00:00:00+09:00","readingtime":7,"relpermalink":"/blog/2019/12/01/whats-happen-at-elastic-in-2019/","section":"post","summary":"Elastic stack (Elasticsearch) Advent Calendar 2019の1日目の記事になります。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみようと思います。毎年恒例ですね、","tags":["elasticsearch"],"title":"2019年のElastic StackとElastic","type":"post","url":"/blog/2019/12/01/whats-happen-at-elastic-in-2019/","weight":0,"wordcount":3116},{"date":1572000002,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":4000,"kind":"page","lang":"ja","lastmod":1572000002,"objectID":"11b3a28b536f34d3606427f835bd3ddf","permalink":"https://blog.johtani.info/blog/2019/10/25/bonefire-01/","publishdate":"2019-10-25T19:40:02+09:00","readingtime":8,"relpermalink":"/blog/2019/10/25/bonefire-01/","section":"post","summary":"Bonfire Data \u0026amp; Science #1にブログ枠で参加してきました。 ということで、メモです。 日時 : 2019/10/25 19:00 - 21:30 場所 : Yahoo! Japan サイト : https://yj-meetup.connpass.com/event/148121/ ハッシュタグ: #yjbonfire 概要 Data \u0026amp; Scienceと","tags":["勉強会"],"title":"Bonfire Data \u0026 Science #1に参加しました","type":"post","url":"/blog/2019/10/25/bonefire-01/","weight":0,"wordcount":3934},{"date":1570690589,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1570690589,"objectID":"d8041ae308961666b15aa1e57b0f9f35","permalink":"https://blog.johtani.info/blog/2019/10/10/review-es-next-step-2/","publishdate":"2019-10-10T15:56:29+09:00","readingtime":2,"relpermalink":"/blog/2019/10/10/review-es-next-step-2/","section":"post","summary":"この間のElasticsearch勉強会でAcroquest Technologyの人たちが技術書展7で販売されていた書籍を頂いてしまいました","tags":["書籍"],"title":"Elasticsearch NEXT STEP 2を頂きました","type":"post","url":"/blog/2019/10/10/review-es-next-step-2/","weight":0,"wordcount":860},{"date":1560939044,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1560939044,"objectID":"d96f80f23543850a2ee9fff8cd2cc53f","permalink":"https://blog.johtani.info/blog/2019/06/19/qr-code-with-meetup-dot-com/","publishdate":"2019-06-19T19:10:44+09:00","readingtime":6,"relpermalink":"/blog/2019/06/19/qr-code-with-meetup-dot-com/","section":"post","summary":"Twitterで「Meetup.comに切り替えたらー」みたいな話があったので、 受付用アプリとかなくてという話になったので、普段Elasti","tags":["勉強会"],"title":"勉強会の受付自作？アプリ？HTMLについて","type":"post","url":"/blog/2019/06/19/qr-code-with-meetup-dot-com/","weight":0,"wordcount":2729},{"date":1556204526,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1556204526,"objectID":"538e38fbc3f78cd61e1841d8141ddcc1","permalink":"https://blog.johtani.info/blog/2019/04/26/meetup-organizer-drinkup/","publishdate":"2019-04-26T00:02:06+09:00","readingtime":3,"relpermalink":"/blog/2019/04/26/meetup-organizer-drinkup/","section":"post","summary":"Elasticsearch勉強会や検索技術勉強会やってるんだけど、独学で勉強会やってるなーと思い、みんなはどうやってるんだろうとツイートして","tags":["勉強会"],"title":"勉強会運営座談会ってのをやってみた","type":"post","url":"/blog/2019/04/26/meetup-organizer-drinkup/","weight":0,"wordcount":1018},{"date":1551191880,"dir":"post/2019/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1551191880,"objectID":"b27bdabd8e1a6b7dc06886867331ceb3","permalink":"https://blog.johtani.info/blog/2019/02/26/start-search-engineering-tech-talk/","publishdate":"2019-02-26T23:38:00+09:00","readingtime":3,"relpermalink":"/blog/2019/02/26/start-search-engineering-tech-talk/","section":"post","summary":"どーも、johtaniです。 Search Engineering Tech Talkという勉強会に運営として参加して、第1回の勉強会を開始しました。 本日（2/26）は第1回目だったの","tags":["勉強会","検索"],"title":"Search Engineering Tech Talk(検索技術勉強会)の運営として参加して始めてみました。","type":"post","url":"/blog/2019/02/26/start-search-engineering-tech-talk/","weight":0,"wordcount":1012},{"date":1546240485,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":3800,"kind":"page","lang":"ja","lastmod":1546240485,"objectID":"6c226ee1519fbf910197cc1d5c5a5756","permalink":"https://blog.johtani.info/blog/2018/12/31/looking-back-2018/","publishdate":"2018-12-31T16:14:45+09:00","readingtime":8,"relpermalink":"/blog/2018/12/31/looking-back-2018/","section":"post","summary":"今年も振り返りブログをかけてます。よかったw 振り返り（2017年に書いた抱負から） まずは去年の抱負を元に。 もっと英語の継続＆TOEIC まぁ、","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2018）","type":"post","url":"/blog/2018/12/31/looking-back-2018/","weight":0,"wordcount":3757},{"date":1545663601,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1545663601,"objectID":"ee62cb0b9a97f990df1ed0266a7027e2","permalink":"https://blog.johtani.info/blog/2018/12/25/whats-new-in-elastic-stack-7/","publishdate":"2018-12-25T00:00:01+09:00","readingtime":4,"relpermalink":"/blog/2018/12/25/whats-new-in-elastic-stack-7/","section":"post","summary":"Elastic stack (Elasticsearch) Advent Calendar 2018の25日目の記事になります。 今年最後のAdvent Calendarです！来年も忘れてなければやるはず！ 今日は、すでにalp","tags":["elasticsearch"],"title":"Elastic Stack 7.0で入ってくる新機能をちょっと紹介","type":"post","url":"/blog/2018/12/25/whats-new-in-elastic-stack-7/","weight":0,"wordcount":1529},{"date":1543628918,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":3900,"kind":"page","lang":"ja","lastmod":1543628918,"objectID":"ba45ddd3042dad59a12e5937644f7246","permalink":"https://blog.johtani.info/blog/2018/12/01/whats-happen-at-elastic-in-2018/","publishdate":"2018-12-01T10:48:38+09:00","readingtime":8,"relpermalink":"/blog/2018/12/01/whats-happen-at-elastic-in-2018/","section":"post","summary":"Elastic stack (Elasticsearch) Advent Calendar 2018の1日目の記事になります。 ちょっと遅れちゃいました。。。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみよ","tags":["elasticsearch"],"title":"2018年のElastic StackとElastic","type":"post","url":"/blog/2018/12/01/whats-happen-at-elastic-in-2018/","weight":0,"wordcount":3863},{"date":1539794095,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1539794095,"objectID":"3fd9052870778e14ab4a5acbc8c24af4","permalink":"https://blog.johtani.info/blog/2018/10/18/items-for-long-businesstrip/","publishdate":"2018-10-18T01:34:55+09:00","readingtime":4,"relpermalink":"/blog/2018/10/18/items-for-long-businesstrip/","section":"post","summary":"（転職する少し前までパスポートすら持ってなかったのに）今の会社に転職してから、半年に1度の割合で海外への出張が発生する生活を送っています。 4","tags":["misc"],"title":"新規導入した長期出張用のアイテムをいくつか紹介","type":"post","url":"/blog/2018/10/18/items-for-long-businesstrip/","weight":0,"wordcount":1514},{"date":1539765230,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":1200,"kind":"page","lang":"ja","lastmod":1539765230,"objectID":"d3fa23c9066f943f10e8883de9340dea","permalink":"https://blog.johtani.info/blog/2018/10/17/26th-elasticsearch-tokyo-meetup/","publishdate":"2018-10-17T17:33:50+09:00","readingtime":3,"relpermalink":"/blog/2018/10/17/26th-elasticsearch-tokyo-meetup/","section":"post","summary":"毎月開催の2回目になります。 今回は日経さんの会場をお借りしての開催となりました。 前回から、スピーカーの募集をhttp://bit.ly/Sp","tags":["elasticsearch","勉強会"],"title":"第25回Elasticsearch勉強会を開催しました。","type":"post","url":"/blog/2018/10/17/26th-elasticsearch-tokyo-meetup/","weight":0,"wordcount":1103},{"date":1532843130,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1532843130,"objectID":"10ae016e19fff6ae9cfaeb8534fa47f9","permalink":"https://blog.johtani.info/blog/2018/07/29/apm-java-at-jjug/","publishdate":"2018-07-29T14:45:30+09:00","readingtime":3,"relpermalink":"/blog/2018/07/29/apm-java-at-jjug/","section":"post","summary":"7/25にJJUGナイトセミナーでElastic Stackの紹介とAPMのJava Agentの紹介をしたので、補足のブログです。 （久々に書く","tags":["勉強会"],"title":"JJUGナイトセミナーで話しました","type":"post","url":"/blog/2018/07/29/apm-java-at-jjug/","weight":0,"wordcount":1386},{"date":1524205801,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1524205801,"objectID":"04d818cbaac08b2915db15e0bffdcb5b","permalink":"https://blog.johtani.info/blog/2018/04/20/directory-layout-and-architecture/","publishdate":"2018-04-20T15:30:01+09:00","readingtime":6,"relpermalink":"/blog/2018/04/20/directory-layout-and-architecture/","section":"post","summary":"第2回から少し間が空いてしまいましたが、templateで作成したプラグインのディレクトリ構成とどういう流れでデータがやり取りされるかについ","tags":["Kibana","plugin"],"title":"Analyze UIとKibanaのプラグインの作成方法（第3回）","type":"post","url":"/blog/2018/04/20/directory-layout-and-architecture/","weight":0,"wordcount":2719},{"date":1521867012,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1521867012,"objectID":"8cc6b19cd410e638f4beaf1642f4f52a","permalink":"https://blog.johtani.info/blog/2018/03/24/how-to-find-conferences/","publishdate":"2018-03-24T13:50:12+09:00","readingtime":2,"relpermalink":"/blog/2018/03/24/how-to-find-conferences/","section":"post","summary":"#MANABIYA のブースでセッション時間の合間はお客さん少ないので、ブログを書いてみたり。 ここ数年、スポンサーとして色々なカンファレンスに参加してるんです","tags":["カンファレンス","スポンサー"],"title":"カンファレンス情報の探し方（CfP、スポンサー応募、開催期間など）？","type":"post","url":"/blog/2018/03/24/how-to-find-conferences/","weight":0,"wordcount":874},{"date":1521549285,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1521549285,"objectID":"d791eaca9375ca1b36a987af22ee71dd","permalink":"https://blog.johtani.info/blog/2018/03/20/nlp100-ch01-05to06/","publishdate":"2018-03-20T21:34:45+09:00","readingtime":3,"relpermalink":"/blog/2018/03/20/nlp100-ch01-05to06/","section":"post","summary":"Rustで言語処理100本ノックの続きで、05と06です。 05. n-gram 問題はこちら。 みんな大好きn-gramです。単語と文字があるので、それぞれ別関","tags":["Rust","nlp100"],"title":"第1章の05から06までやってみた（言語処理100本ノック）","type":"post","url":"/blog/2018/03/20/nlp100-ch01-05to06/","weight":0,"wordcount":1227},{"date":1519032848,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1519032848,"objectID":"e6684944c37dbdd4c08d978af9e47bed","permalink":"https://blog.johtani.info/blog/2018/02/19/nlp100-ch01-03to04/","publishdate":"2018-02-19T18:34:08+09:00","readingtime":3,"relpermalink":"/blog/2018/02/19/nlp100-ch01-03to04/","section":"post","summary":"Rustで言語処理100本ノックの続きで、03と04です。 03. 円周率 問題はこちら。 入力文字列を.split_whitespace()で分割して","tags":["Rust","nlp100"],"title":"第1章の03から04までやってみた（言語処理100本ノック）","type":"post","url":"/blog/2018/02/19/nlp100-ch01-03to04/","weight":0,"wordcount":1306},{"date":1518699541,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1518699541,"objectID":"bbe1deec11d459bdb348051b970abdaf","permalink":"https://blog.johtani.info/blog/2018/02/15/nlp100-ch01-00to02/","publishdate":"2018-02-15T21:59:01+09:00","readingtime":2,"relpermalink":"/blog/2018/02/15/nlp100-ch01-00to02/","section":"post","summary":"「鉄は熱いうちに打て」ということで、言語処理100本ノックの第1章の00から02を実装してみました。 さて、これが効率がいいのかどうかはさてお","tags":["Rust","nlp100"],"title":"第1章の00から02までやってみた（言語処理100本ノック）","type":"post","url":"/blog/2018/02/15/nlp100-ch01-00to02/","weight":0,"wordcount":659},{"date":1518605551,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":500,"kind":"page","lang":"ja","lastmod":1518605551,"objectID":"a673b3829e62477e01abc75465416b86","permalink":"https://blog.johtani.info/blog/2018/02/14/start-nlp100-with-rust/","publishdate":"2018-02-14T19:52:31+09:00","readingtime":1,"relpermalink":"/blog/2018/02/14/start-nlp100-with-rust/","section":"post","summary":"ども。新しいもの始めないと頭が退化する。。。ということで、こちら（ happy new year and new language - katsyoshiのめもみたいなもの）のブログに触発されて、","tags":["Rust","nlp100"],"title":"言語処理100本ノックはじめました(Rust)","type":"post","url":"/blog/2018/02/14/start-nlp100-with-rust/","weight":0,"wordcount":451},{"date":1518167857,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":3500,"kind":"page","lang":"ja","lastmod":1518167857,"objectID":"7b6cb59a177abe9767fd22da5a03b1e6","permalink":"https://blog.johtani.info/blog/2018/02/09/getting-started-template-kibana-plugin/","publishdate":"2018-02-09T18:17:37+09:00","readingtime":7,"relpermalink":"/blog/2018/02/09/getting-started-template-kibana-plugin/","section":"post","summary":"第1回では、Analyze UIというプラグインの紹介をしました、ごく簡単にですが。 第2回では、Kibanaのプラグインの作成方法を順を追って","tags":["Kibana","plugin"],"title":"Analyze UIとKibanaのプラグインの作成方法（第2回）","type":"post","url":"/blog/2018/02/09/getting-started-template-kibana-plugin/","weight":0,"wordcount":3461},{"date":1516343806,"dir":"post/2018/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1516343806,"objectID":"4afcb20d4d95bcd1bde3aa6b7f552660","permalink":"https://blog.johtani.info/blog/2018/01/19/how-to-make-kibana-plugin-example-analysis-ui/","publishdate":"2018-01-19T15:36:46+09:00","readingtime":3,"relpermalink":"/blog/2018/01/19/how-to-make-kibana-plugin-example-analysis-ui/","section":"post","summary":"あけましておめでとうございます。今年はサボりがちだったブログをちょっとずつ復活させようかと。 ということで、第1弾として、昨年少し作っていたK","tags":["Kibana","plugin"],"title":"Analyze UIとKibanaのプラグインの作成方法（第1回）","type":"post","url":"/blog/2018/01/19/how-to-make-kibana-plugin-example-analysis-ui/","weight":0,"wordcount":1461},{"date":1514723443,"dir":"post/2017/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1514723443,"objectID":"7c21b70f9e9c782c1f5153268e0cc1c1","permalink":"https://blog.johtani.info/blog/2017/12/31/looking-back-2017/","publishdate":"2017-12-31T21:30:43+09:00","readingtime":6,"relpermalink":"/blog/2017/12/31/looking-back-2017/","section":"post","summary":"今年は紅白を見ながら書いてます。 今年はいろんなところに出張に行ったなぁ。 振り返り（2016年に書いた抱負から） まずは去年の抱負を元に。 もちろ","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2017）","type":"post","url":"/blog/2017/12/31/looking-back-2017/","weight":0,"wordcount":2712},{"date":1514124616,"dir":"post/2017/","expirydate":-62135596800,"fuzzywordcount":1200,"kind":"page","lang":"ja","lastmod":1514124616,"objectID":"f3a9b931b7f552a4f9dfa61ce4f39f0e","permalink":"https://blog.johtani.info/blog/2017/12/24/elastic-2018/","publishdate":"2017-12-24T23:10:16+09:00","readingtime":3,"relpermalink":"/blog/2017/12/24/elastic-2018/","section":"post","summary":"Merry Christmas! Elastic Stack Advent Calendar 2017の24日目の記事になります。 ちょっとですが、2018年のElasticについて書いてみようかと思います。 イベント いくつか","tags":["elasticsearch"],"title":"2018年のElasticは？","type":"post","url":"/blog/2017/12/24/elastic-2018/","weight":0,"wordcount":1161},{"date":1512054000,"dir":"post/2017/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1512054000,"objectID":"fa0486610d8a02cea245c13c85b6de27","permalink":"https://blog.johtani.info/blog/2017/12/01/whats-happen-at-elastic-in-2017/","publishdate":"2017-12-01T00:00:00+09:00","readingtime":6,"relpermalink":"/blog/2017/12/01/whats-happen-at-elastic-in-2017/","section":"post","summary":"Elastic stack (Elasticsearch) Advent Calendar 2017の1日目の記事になります。 まだ、1ヶ月を残していますが、簡単に今年起こったことを振り返ってみようかと思います。思った以上に","tags":["elasticsearch"],"title":"2017年のElastic StackとElastic","type":"post","url":"/blog/2017/12/01/whats-happen-at-elastic-in-2017/","weight":0,"wordcount":2742},{"date":1510280089,"dir":"post/2017/","expirydate":-62135596800,"fuzzywordcount":1200,"kind":"page","lang":"ja","lastmod":1510280089,"objectID":"c20d71627e66a044b21780f56f2f9504","permalink":"https://blog.johtani.info/blog/2017/11/10/welcome-swiftype/","publishdate":"2017-11-10T11:14:49+09:00","readingtime":3,"relpermalink":"/blog/2017/11/10/welcome-swiftype/","section":"post","summary":"Swiftypeでサイト内検索？ プレスリリース：Elasticがサイト内検索サービス最大手のSwiftypeを買収が出ましたが、Swifty","tags":null,"title":"Swiftypeがジョインしたので触ってみました","type":"post","url":"/blog/2017/11/10/welcome-swiftype/","weight":0,"wordcount":1139},{"date":1505955750,"dir":"post/2017/","expirydate":-62135596800,"fuzzywordcount":400,"kind":"page","lang":"ja","lastmod":1505955750,"objectID":"4f88f3eebe44285ded812939553ef94c","permalink":"https://blog.johtani.info/blog/2017/09/21/release-intro-logging-analysis-system/","publishdate":"2017-09-21T10:02:30+09:00","readingtime":1,"relpermalink":"/blog/2017/09/21/release-intro-logging-analysis-system/","section":"post","summary":"久々に執筆しました。といっても、以前の書籍の更新版です。 まぁ、更新版といっても、私以外の方々は結構な量を書き直しor新規書き起こしされてます","tags":["elasticsearch","kibana","本"],"title":"データ分析基盤構築入門 を一部執筆しました。","type":"post","url":"/blog/2017/09/21/release-intro-logging-analysis-system/","weight":0,"wordcount":370},{"date":1495639453,"dir":"post/2017/","expirydate":-62135596800,"fuzzywordcount":600,"kind":"page","lang":"ja","lastmod":1495639453,"objectID":"29b4c2b5adcd80ced1612128b3ca95a9","permalink":"https://blog.johtani.info/blog/2017/05/25/search-meetup/","publishdate":"2017-05-25T00:24:13+09:00","readingtime":2,"relpermalink":"/blog/2017/05/25/search-meetup/","section":"post","summary":"久々のブログ。 Elasticsearch勉強会を主催してますが、 プロダクトを超えて、検索で共通してある課題とか、悩みとか、あるかなぁと。 その","tags":["勉強会"],"title":"検索座談会ってのをやってみた","type":"post","url":"/blog/2017/05/25/search-meetup/","weight":0,"wordcount":565},{"date":1483190534,"dir":"post/2016/","expirydate":-62135596800,"fuzzywordcount":2200,"kind":"page","lang":"ja","lastmod":1483190534,"objectID":"16f1046144ad9ee7bb96214ba7ae7516","permalink":"https://blog.johtani.info/blog/2016/12/31/looking-back-2016/","publishdate":"2016-12-31T22:22:14+09:00","readingtime":5,"relpermalink":"/blog/2016/12/31/looking-back-2016/","section":"post","summary":"今年はRioのプレイバック\u000e見ながら書いてます。 今年はなんか長い一年だった気が。 振り返り（2015年に書いた抱負から） まずは去年の抱負を元に","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2016）","type":"post","url":"/blog/2016/12/31/looking-back-2016/","weight":0,"wordcount":2199},{"date":1482591830,"dir":"post/2016/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1482591830,"objectID":"002d980d74d19b43ff4e2446665e2fe5","permalink":"https://blog.johtani.info/blog/2016/12/25/elasticsearch-6-features/","publishdate":"2016-12-25T00:03:50+09:00","readingtime":5,"relpermalink":"/blog/2016/12/25/elasticsearch-6-features/","section":"post","summary":"Merry Christmas! Elastic stack Advent Calendar 2016 最終日の記事になります。 簡単に今年の変遷を振り返ってみます。 Elasticsearch 2.2 (2月) Elasticsearch 2.2.0、2.1.2、1.7.5リリース クエリプロ","tags":["elasticsearch"],"title":"2016年のElastic Stack","type":"post","url":"/blog/2016/12/25/elasticsearch-6-features/","weight":0,"wordcount":2347},{"date":1480581270,"dir":"post/2016/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1480581270,"objectID":"550becdd08d00fb1e7fd00c2adc3d3d6","permalink":"https://blog.johtani.info/blog/2016/12/01/elasticsearch-5-dot-0-highlight/","publishdate":"2016-12-01T17:34:30+09:00","readingtime":3,"relpermalink":"/blog/2016/12/01/elasticsearch-5-dot-0-highlight/","section":"post","summary":"Elastic stack Advent Calendar 1日目の記事になります。 Elasticsearch 5.0が10月末にリリースされました。 リリースのブログでいくつか紹介されているのですが、そこでは紹介されて","tags":["elasticsearch"],"title":"Elasticsearch 5.0の便利機能紹介？","type":"post","url":"/blog/2016/12/01/elasticsearch-5-dot-0-highlight/","weight":0,"wordcount":1330},{"date":1469161616,"dir":"post/2016/","expirydate":-62135596800,"fuzzywordcount":3800,"kind":"page","lang":"ja","lastmod":1469161616,"objectID":"a62186ea292d6db03a087bd5dfcc3f1e","permalink":"https://blog.johtani.info/blog/2016/07/22/making-ingest-processor-plugin-with-cookiecutter/","publishdate":"2016-07-22T13:26:56+09:00","readingtime":8,"relpermalink":"/blog/2016/07/22/making-ingest-processor-plugin-with-cookiecutter/","section":"post","summary":"久しぶりに、技術的なブログ書いてます。 Ingest Processorのプラグインを作ってみたくなったので、書いてみました。 ただ書いてみるんじゃ3番煎じ","tags":["elasticsearch","plugin"],"title":"Lucene Kuromoji for NEologdで指定した品詞の単語を抜き出すIngest Pluginを書いてみた #elasticsearchjp","type":"post","url":"/blog/2016/07/22/making-ingest-processor-plugin-with-cookiecutter/","weight":0,"wordcount":3710},{"date":1467251858,"dir":"post/2016/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1467251858,"objectID":"167e2a6833d49ce198cb3b88f521991e","permalink":"https://blog.johtani.info/blog/2016/06/30/broken-something-in-this-year/","publishdate":"2016-06-30T10:57:38+09:00","readingtime":2,"relpermalink":"/blog/2016/06/30/broken-something-in-this-year/","section":"post","summary":"なんか、今年はよく物が壊れる、厄年だからかなぁ？ ということで、記念に何が壊れたかをブログに残しておこうかと。 腕時計（壊れてないかな） 電波腕時","tags":["misc"],"title":"よく物が壊れる年","type":"post","url":"/blog/2016/06/30/broken-something-in-this-year/","weight":0,"wordcount":654},{"date":1467089755,"dir":"post/2016/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1467089755,"objectID":"993e58f132740b464ecf06ee289dc7b2","permalink":"https://blog.johtani.info/blog/2016/06/28/16th-elasticsearch-meetup/","publishdate":"2016-06-28T13:55:55+09:00","readingtime":4,"relpermalink":"/blog/2016/06/28/16th-elasticsearch-meetup/","section":"post","summary":"第16回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第16回Elasticsearch勉強会を開催しました。 #elasticsearchjp","type":"post","url":"/blog/2016/06/28/16th-elasticsearch-meetup/","weight":0,"wordcount":1952},{"date":1458186180,"dir":"post/2016/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1458186180,"objectID":"c56a76ef8f604a8d87be2a32b1f81fac","permalink":"https://blog.johtani.info/blog/2016/03/17/15th-elasticsearch-jp/","publishdate":"2016-03-17T12:43:00+09:00","readingtime":3,"relpermalink":"/blog/2016/03/17/15th-elasticsearch-jp/","section":"post","summary":"第15回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第15回Elasticsearch勉強会を開催しました。 #elasticsearchjp","type":"post","url":"/blog/2016/03/17/15th-elasticsearch-jp/","weight":0,"wordcount":1302},{"date":1457962452,"dir":"post/2016/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1457962452,"objectID":"3fc7462a83fa55885067fee629287e8a","permalink":"https://blog.johtani.info/blog/2016/03/14/review-basics-and-tech-of-nlp/","publishdate":"2016-03-14T22:34:12+09:00","readingtime":2,"relpermalink":"/blog/2016/03/14/review-basics-and-tech-of-nlp/","section":"post","summary":"久々のポスト。。。 久々に、技術書読んでます。「自然言語処理の基本と技術」という本です。 監修の方のツイートを見て気になったので、買ってみました","tags":["本"],"title":"「自然言語処理の基本と技術」を読んでる","type":"post","url":"/blog/2016/03/14/review-basics-and-tech-of-nlp/","weight":0,"wordcount":746},{"date":1452220496,"dir":"post/2016/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1452220496,"objectID":"4b0a768585da8f9f8f8db1ca409e7ebd","permalink":"https://blog.johtani.info/blog/2016/01/08/14th-elasticcsearch-jp/","publishdate":"2016-01-08T11:34:56+09:00","readingtime":5,"relpermalink":"/blog/2016/01/08/14th-elasticcsearch-jp/","section":"post","summary":"あけましておめでとうございます、johtaniです。 第14回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆","tags":["elasticsearch","勉強会"],"title":"第14回Elasticsearch勉強会を開催しました。 #elasticsearchjp","type":"post","url":"/blog/2016/01/08/14th-elasticcsearch-jp/","weight":0,"wordcount":2488},{"date":1451565182,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1451565182,"objectID":"c54909ecf4fb3e9afeea36200fe95dce","permalink":"https://blog.johtani.info/blog/2015/12/31/looking-back-2015/","publishdate":"2015-12-31T21:33:02+09:00","readingtime":3,"relpermalink":"/blog/2015/12/31/looking-back-2015/","section":"post","summary":"今年は紅白見ながら書いてます。 早い一年だったなぁ。 振り返り(2014年に書いた抱負から) まずは去年の抱負を元に振り返りをば。 英語の継続 海外の","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2015）","type":"post","url":"/blog/2015/12/31/looking-back-2015/","weight":0,"wordcount":1383},{"date":1451017794,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1451017794,"objectID":"d819cea5197e9b8673d6c0b16659a5ea","permalink":"https://blog.johtani.info/blog/2015/12/25/about-elasticsearch-in-2015/","publishdate":"2015-12-25T13:29:54+09:00","readingtime":6,"relpermalink":"/blog/2015/12/25/about-elasticsearch-in-2015/","section":"post","summary":"今年最後のAdvent Calendarとなります。 この記事はElasticsearch Advent Calendar 2015の最終日のエントリです。 簡単に今年の変遷を","tags":["elasticsearch"],"title":"2015年のElasticsearch","type":"post","url":"/blog/2015/12/25/about-elasticsearch-in-2015/","weight":0,"wordcount":2634},{"date":1448936891,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1900,"kind":"page","lang":"ja","lastmod":1448936891,"objectID":"1b56132638912a1ca54fcf7cd38b8e23","permalink":"https://blog.johtani.info/blog/2015/12/01/introduction-timelion/","publishdate":"2015-12-01T11:28:11+09:00","readingtime":4,"relpermalink":"/blog/2015/12/01/introduction-timelion/","section":"post","summary":"こんにちは、@johtaniです。 早いもので、師走です。今年もあと少しとなりました（今月が一番忙しかったりしますが。。。）。 ということで、A","tags":["kibana","timelion"],"title":"Timelionの紹介 - Elasticsearch Advent Calendar 2015 1日目","type":"post","url":"/blog/2015/12/01/introduction-timelion/","weight":0,"wordcount":1858},{"date":1447143778,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1447143778,"objectID":"2ea86ae5093670df1d4502ea82efa1ac","permalink":"https://blog.johtani.info/blog/2015/11/10/13th-elasticsearch-jp/","publishdate":"2015-11-10T17:22:58+09:00","readingtime":4,"relpermalink":"/blog/2015/11/10/13th-elasticsearch-jp/","section":"post","summary":"第13回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第13回Elasticsearch勉強会を開催しました。#elasticsearchjp","type":"post","url":"/blog/2015/11/10/13th-elasticsearch-jp/","weight":0,"wordcount":1765},{"date":1446195306,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":3700,"kind":"page","lang":"ja","lastmod":1446195306,"objectID":"5912529cfd6ce14c5ede5c6c83dae7e8","permalink":"https://blog.johtani.info/blog/2015/10/30/sense-2-0-0-beta1-ja/","publishdate":"2015-10-30T17:55:06+09:00","readingtime":8,"relpermalink":"/blog/2015/10/30/sense-2-0-0-beta1-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：The Story of Sense - Announcing Sense 2.0.0-beta1 誕生 よくある良いプロジェクト同様、Senseもビールを飲みながら考","tags":["elasticsearch","sense"],"title":"Senseの歴史 - Sense 2.0.0-beta1の紹介(日本語訳)","type":"post","url":"/blog/2015/10/30/sense-2-0-0-beta1-ja/","weight":0,"wordcount":3643},{"date":1446189691,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":3200,"kind":"page","lang":"ja","lastmod":1446189691,"objectID":"15700442e957951307bbcec5fff8643d","permalink":"https://blog.johtani.info/blog/2015/10/30/shield-watcher-and-marvel-2-0-ga-released-ja/","publishdate":"2015-10-30T16:21:31+09:00","readingtime":7,"relpermalink":"/blog/2015/10/30/shield-watcher-and-marvel-2-0-ga-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Shield, Watcher, and Marvel 2.0.0 GA Released 本日（10/28）Shield、WatcherおよびMarv","tags":["elasticsearch","shield","watcher","marvel"],"title":"Shield、Watcher、Marvel 2.0.0 GAリリース（日本語訳）","type":"post","url":"/blog/2015/10/30/shield-watcher-and-marvel-2-0-ga-released-ja/","weight":0,"wordcount":3122},{"date":1446103243,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":3500,"kind":"page","lang":"ja","lastmod":1446103243,"objectID":"018e32a8010960eb17e368a6fdd5a51b","permalink":"https://blog.johtani.info/blog/2015/10/29/elasticsearch-2-0-0-released-ja/","publishdate":"2015-10-29T16:20:43+09:00","readingtime":7,"relpermalink":"/blog/2015/10/29/elasticsearch-2-0-0-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0 GA released Elasticsearch 1.0.0のリリース以降、 477のコミッター2,79","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0リリース(日本語訳)","type":"post","url":"/blog/2015/10/29/elasticsearch-2-0-0-released-ja/","weight":0,"wordcount":3449},{"date":1446103219,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1446103219,"objectID":"e159a35d1b9a46e03072a3d54780edcb","permalink":"https://blog.johtani.info/blog/2015/10/29/kibana-4-2-0-ja/","publishdate":"2015-10-29T16:20:19+09:00","readingtime":3,"relpermalink":"/blog/2015/10/29/kibana-4-2-0-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Kibana 4.2.0 released Elasticsearch 2.0 + Kibana 4.2 = 💚 Elasticsearch 2.0サポートのKibanaの最初のリリースです。 これ","tags":["elastic","kibana"],"title":"Kibana 4.2.0リリース（日本語訳）","type":"post","url":"/blog/2015/10/29/kibana-4-2-0-ja/","weight":0,"wordcount":1079},{"date":1446103197,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1446103197,"objectID":"cc64c2fcdecdb505b3797e1aaaa59adc","permalink":"https://blog.johtani.info/blog/2015/10/29/logstash-2-0-0-released-ja/","publishdate":"2015-10-29T16:19:57+09:00","readingtime":5,"relpermalink":"/blog/2015/10/29/logstash-2-0-0-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Logstash 2.0.0 released Logstash 2.0.0が本日（10/28）リリースされました。 このリリースは","tags":["elastic","logstash"],"title":"Logstash 2.0.0リリース（日本語訳）","type":"post","url":"/blog/2015/10/29/logstash-2-0-0-released-ja/","weight":0,"wordcount":2478},{"date":1446095939,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1446095939,"objectID":"4cc08ca51ecf0f963035f039de6194c5","permalink":"https://blog.johtani.info/blog/2015/10/29/release-we-have-ja/","publishdate":"2015-10-29T14:18:59+09:00","readingtime":4,"relpermalink":"/blog/2015/10/29/release-we-have-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Relase, we have ※画像に関しては原文をご覧ください。 Elasticにとって大きな1日","tags":["elasticsearch","kibana","logstash"],"title":"Release, we have（日本語訳）","type":"post","url":"/blog/2015/10/29/release-we-have-ja/","weight":0,"wordcount":1542},{"date":1442565101,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1442565101,"objectID":"4b227d61f33182579cd3edd0ac6c7c44","permalink":"https://blog.johtani.info/blog/2015/09/18/elasticsearch-2-0-0-beta2-released-ja/","publishdate":"2015-09-18T17:31:41+09:00","readingtime":4,"relpermalink":"/blog/2015/09/18/elasticsearch-2-0-0-beta2-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0-beta2 released 本日（9/17）、Lucene 5.2.1ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0-beta2リリース（日本語訳）","type":"post","url":"/blog/2015/09/18/elasticsearch-2-0-0-beta2-released-ja/","weight":0,"wordcount":1932},{"date":1440730890,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1440730890,"objectID":"0de0edbf2a506143c1739b12e94c0ef9","permalink":"https://blog.johtani.info/blog/2015/08/28/elasticsearch-unplugged-ja/","publishdate":"2015-08-28T12:01:30+09:00","readingtime":4,"relpermalink":"/blog/2015/08/28/elasticsearch-unplugged-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch unplugged - Networking changes in 2.0 Elasticsearchをローカルのマシンで起","tags":["elasticsearch"],"title":"Elasticsearch unplugged - 2.0におけるネットワークの変更(日本語訳)","type":"post","url":"/blog/2015/08/28/elasticsearch-unplugged-ja/","weight":0,"wordcount":1904},{"date":1440638952,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1440638952,"objectID":"744554499cb7880086fbd9b1f080e7e1","permalink":"https://blog.johtani.info/blog/2015/08/27/elasticsearch-2-0-0-beta1-released-ja/","publishdate":"2015-08-27T10:29:12+09:00","readingtime":4,"relpermalink":"/blog/2015/08/27/elasticsearch-2-0-0-beta1-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0-beta1 released 本日（8/26）、Lucene 5.2.1ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0-beta1リリース（日本語訳）","type":"post","url":"/blog/2015/08/27/elasticsearch-2-0-0-beta1-released-ja/","weight":0,"wordcount":1935},{"date":1440044644,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1440044644,"objectID":"5a9e950f4ac186925e5de978c5f72062","permalink":"https://blog.johtani.info/blog/2015/08/20/core-delete-by-query-is-a-plugin-ja/","publishdate":"2015-08-20T13:24:04+09:00","readingtime":3,"relpermalink":"/blog/2015/08/20/core-delete-by-query-is-a-plugin-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：The Delete by Query API Is now a plugin Elasticsearchの2.0.0-beta1では、これまで","tags":["elasticsearch"],"title":"Delete by Query APIはプラグインへ（日本語訳）","type":"post","url":"/blog/2015/08/20/core-delete-by-query-is-a-plugin-ja/","weight":0,"wordcount":1468},{"date":1438321313,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2200,"kind":"page","lang":"ja","lastmod":1438321313,"objectID":"73b8194ad8fce0cabb01cd21d5e18500","permalink":"https://blog.johtani.info/blog/2015/07/31/11th-elasticsearch-jp/","publishdate":"2015-07-31T14:41:53+09:00","readingtime":5,"relpermalink":"/blog/2015/07/31/11th-elasticsearch-jp/","section":"post","summary":"第11回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第11回Elasticsearch勉強会を開催しました。#elasticsearchjp","type":"post","url":"/blog/2015/07/31/11th-elasticsearch-jp/","weight":0,"wordcount":2119},{"date":1438173353,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1438173353,"objectID":"100c0a69bea7f02a0f4540ecaa37d0e3","permalink":"https://blog.johtani.info/blog/2015/07/29/elasticsearch-1-7-1-and-1-6-2-released-ja/","publishdate":"2015-07-29T21:35:53+09:00","readingtime":2,"relpermalink":"/blog/2015/07/29/elasticsearch-1-7-1-and-1-6-2-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.1 and 1.6.2 released 本日（7/29）、Lucene 4.10.4ベースのE","tags":["elasticsearch"],"title":"Elasticsearch 1.7.1 および 1.6.2リリース（日本語訳）","type":"post","url":"/blog/2015/07/29/elasticsearch-1-7-1-and-1-6-2-released-ja/","weight":0,"wordcount":601},{"date":1437546817,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1437546817,"objectID":"809925e891b0456231c374b09cbe4a90","permalink":"https://blog.johtani.info/blog/2015/07/22/elasticsearch-1-7-0-and-1-6-1-released-ja/","publishdate":"2015-07-22T15:33:37+09:00","readingtime":6,"relpermalink":"/blog/2015/07/22/elasticsearch-1-7-0-and-1-6-1-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.0 and 1.6.1 released 本日（7/16）、Lucene 4.10.4ベースのE","tags":["elasticsearch"],"title":"Elasticsearch 1.7.0 および 1.6.1リリース（日本語訳）","type":"post","url":"/blog/2015/07/22/elasticsearch-1-7-0-and-1-6-1-released-ja/","weight":0,"wordcount":2518},{"date":1437010857,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1437010857,"objectID":"dd6c32a722dc815273cd9ed8cd6c671b","permalink":"https://blog.johtani.info/blog/2015/07/16/kansai-1st-elasticsearch-jp/","publishdate":"2015-07-16T10:40:57+09:00","readingtime":4,"relpermalink":"/blog/2015/07/16/kansai-1st-elasticsearch-jp/","section":"post","summary":"東京以外での勉強会の第2弾として、関西で勉強会を開催してきました。 Elasticsearch勉強会 in 大阪 Elasticsearch勉強会 in 京","tags":["勉強会","elasticsearch"],"title":"大阪と京都でElasticsearch勉強会を開催しました。 #elasticsearchjp","type":"post","url":"/blog/2015/07/16/kansai-1st-elasticsearch-jp/","weight":0,"wordcount":1960},{"date":1436346691,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":6700,"kind":"page","lang":"ja","lastmod":1436346691,"objectID":"ee4ff9e4e8a1948795e26af2f3f8a30f","permalink":"https://blog.johtani.info/blog/2015/07/08/great-mapping-refactoring-ja/","publishdate":"2015-07-08T18:11:31+09:00","readingtime":14,"relpermalink":"/blog/2015/07/08/great-mapping-refactoring-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：The Great Mapping Refactoring Elasticsearchのユーザの悩みの最も大きなものの一つは、 タイプと","tags":["elasticsearch"],"title":"Mappingのすばらしいリファクタリング（日本語訳）","type":"post","url":"/blog/2015/07/08/great-mapping-refactoring-ja/","weight":0,"wordcount":6652},{"date":1436250300,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1436250300,"objectID":"f887e1aabf801e351bfb39698f208af1","permalink":"https://blog.johtani.info/blog/2015/07/07/elasticsearch-2-dot-0-0-dot-beta1-coming-soon-ja/","publishdate":"2015-07-07T15:25:00+09:00","readingtime":6,"relpermalink":"/blog/2015/07/07/elasticsearch-2-dot-0-0-dot-beta1-coming-soon-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0.beta1 coming soon! Elasticsearch 2.0.0.beta1のリリースの準備をしています。","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0.beta1リリース間近（日本語訳）","type":"post","url":"/blog/2015/07/07/elasticsearch-2-dot-0-0-dot-beta1-coming-soon-ja/","weight":0,"wordcount":2676},{"date":1436250000,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1436250000,"objectID":"9cc2a0b6c8be1405cddcdeb4487c59fe","permalink":"https://blog.johtani.info/blog/2015/07/07/we-just-made-found-more-awesome-ja/","publishdate":"2015-07-07T15:20:00+09:00","readingtime":3,"relpermalink":"/blog/2015/07/07/we-just-made-found-more-awesome-ja/","section":"post","summary":"4ヶ月前に、Found joined our team at Elasticをアナウンスしました。 Foundの素晴らしいチームと一緒に仕事をしていますが、彼らによって、より","tags":["elasticsearch","found.no"],"title":"さらに進化したFound（日本語訳）","type":"post","url":"/blog/2015/07/07/we-just-made-found-more-awesome-ja/","weight":0,"wordcount":1451},{"date":1436147341,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1200,"kind":"page","lang":"ja","lastmod":1436147341,"objectID":"18b7998a871950ebc36c415a53630477","permalink":"https://blog.johtani.info/blog/2015/07/06/attend-justsystem-techtalk-no2/","publishdate":"2015-07-06T10:49:01+09:00","readingtime":3,"relpermalink":"/blog/2015/07/06/attend-justsystem-techtalk-no2/","section":"post","summary":"JustTechTalk#02 形態素解析のあれやこれや@ジャストシステム に参加してきました。 ジャストシステムさんの形態素解析器JMATの話とKagome、Janome、","tags":["勉強会"],"title":"JustTechTalk#02 形態素解析のあれやこれや@ジャストシステムに参加しました。","type":"post","url":"/blog/2015/07/06/attend-justsystem-techtalk-no2/","weight":0,"wordcount":1164},{"date":1434468093,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1434468093,"objectID":"ddab6357ff522c0c956ebd7669e83454","permalink":"https://blog.johtani.info/blog/2015/06/17/attend-hatena-engineer-seminar-5/","publishdate":"2015-06-17T00:21:33+09:00","readingtime":3,"relpermalink":"/blog/2015/06/17/attend-hatena-engineer-seminar-5/","section":"post","summary":"ひさびさに、勉強会メモ。 Hatena Engineer Seminar #5 @ Tokyoに当選したので行ってきました。 いつもは近寄らないオシャレな街をドキドキしながら行ってきました。 と","tags":["勉強会"],"title":"Hatena Engineer Seminar #5 @ Tokyoに参加しました。 #hatenatech","type":"post","url":"/blog/2015/06/17/attend-hatena-engineer-seminar-5/","weight":0,"wordcount":1294},{"date":1433910662,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":4700,"kind":"page","lang":"ja","lastmod":1433910662,"objectID":"55188a318c5998989255253e15ccc1f6","permalink":"https://blog.johtani.info/blog/2015/06/10/elasticsearch-1-6-0-released-ja/","publishdate":"2015-06-10T13:31:02+09:00","readingtime":10,"relpermalink":"/blog/2015/06/10/elasticsearch-1-6-0-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.6.0 released 本日（6/9）、Lucene 4.10.4ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 1.6.0リリース（日本語訳）","type":"post","url":"/blog/2015/06/10/elasticsearch-1-6-0-released-ja/","weight":0,"wordcount":4693},{"date":1433225196,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":3000,"kind":"page","lang":"ja","lastmod":1433225196,"objectID":"75d9268739fe7787ac02d389ac605feb","permalink":"https://blog.johtani.info/blog/2015/06/02/10th-elasticsearch-jp/","publishdate":"2015-06-02T15:06:36+09:00","readingtime":6,"relpermalink":"/blog/2015/06/02/10th-elasticsearch-jp/","section":"post","summary":"第10回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさ","tags":["elasticsearch","勉強会"],"title":"第10回Elasticsearch勉強会を開催しました。#elasticsearchjp","type":"post","url":"/blog/2015/06/02/10th-elasticsearch-jp/","weight":0,"wordcount":2943},{"date":1432624090,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1900,"kind":"page","lang":"ja","lastmod":1432624090,"objectID":"23a22d1411afb787810d68210e6fad4f","permalink":"https://blog.johtani.info/blog/2015/05/26/reindex-elasticsearch-with-logstash-ja/","publishdate":"2015-05-26T16:08:10+09:00","readingtime":4,"relpermalink":"/blog/2015/05/26/reindex-elasticsearch-with-logstash-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Reindex Elasticsearch With Logstash Thanks David! マッピングを変更したり、インデックスの設定を変更したり、あるサ","tags":["logstash","elasticsearch"],"title":"Logstashを使ったElasticsearchの再インデックス（日本語訳）","type":"post","url":"/blog/2015/05/26/reindex-elasticsearch-with-logstash-ja/","weight":0,"wordcount":1844},{"date":1432197903,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1432197903,"objectID":"615db1a24f36d19a8eaf18d4dceed6b2","permalink":"https://blog.johtani.info/blog/2015/05/21/join-the-conversation-ja/","publishdate":"2015-05-21T17:45:03+09:00","readingtime":2,"relpermalink":"/blog/2015/05/21/join-the-conversation-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Join the Conversation: Discuss.Elastic.Co 3つのOSSプロジェクトの開発をスケールアップし始め、 コミュニティサポー","tags":null,"title":"discuss.elastic.co にぜひ参加を","type":"post","url":"/blog/2015/05/21/join-the-conversation-ja/","weight":0,"wordcount":723},{"date":1430201648,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1700,"kind":"page","lang":"ja","lastmod":1430201648,"objectID":"8d7caf84b3a51cca27291c1f7cfc2d40","permalink":"https://blog.johtani.info/blog/2015/04/28/elasticsearch-1-5-2-and-1-4-5-released-ja/","publishdate":"2015-04-28T15:14:08+09:00","readingtime":4,"relpermalink":"/blog/2015/04/28/elasticsearch-1-5-2-and-1-4-5-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.2 Released 本日（4/27）、Lucene 4.10.4ベースのEla","tags":["elasticsearch"],"title":"Elasticsearch 1.5.2 および 1.4.5リリース（日本語訳）","type":"post","url":"/blog/2015/04/28/elasticsearch-1-5-2-and-1-4-5-released-ja/","weight":0,"wordcount":1651},{"date":1429249314,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1429249314,"objectID":"7249710187cc2d983709e044dbc78d9d","permalink":"https://blog.johtani.info/blog/2015/04/17/9th-elasticsearch-jp/","publishdate":"2015-04-17T14:41:54+09:00","readingtime":3,"relpermalink":"/blog/2015/04/17/9th-elasticsearch-jp/","section":"post","summary":"第9回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第9回Elasticsearch勉強会を開催しました。#elasticsearchjp","type":"post","url":"/blog/2015/04/17/9th-elasticsearch-jp/","weight":0,"wordcount":1334},{"date":1428892471,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1428892471,"objectID":"563864a949924c505985a168191dcb84","permalink":"https://blog.johtani.info/blog/2015/04/13/elasticsearch-1-5-1-released-ja/","publishdate":"2015-04-13T11:34:31+09:00","readingtime":2,"relpermalink":"/blog/2015/04/13/elasticsearch-1-5-1-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.1 Released 本日（4/9）、Lucene 4.10.4ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 1.5.1リリース（日本語訳）","type":"post","url":"/blog/2015/04/13/elasticsearch-1-5-1-released-ja/","weight":0,"wordcount":828},{"date":1428108439,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1428108439,"objectID":"24357fe145c869ec82fdfc8134a1a6d1","permalink":"https://blog.johtani.info/blog/2015/04/04/elasticsearch-study-session-at-nagoya/","publishdate":"2015-04-04T09:47:19+09:00","readingtime":4,"relpermalink":"/blog/2015/04/04/elasticsearch-study-session-at-nagoya/","section":"post","summary":"Elasticsearch勉強会 in 名古屋を開催しました。 初の東京以外での勉強会です。 企画、セッションなどお手伝いいただいた@smogamiさ","tags":["elasticsearch","勉強会"],"title":"Elasticsearch勉強会 in 名古屋を開催しました。#elasticsearch #elasticsearchjp","type":"post","url":"/blog/2015/04/04/elasticsearch-study-session-at-nagoya/","weight":0,"wordcount":1527},{"date":1427859496,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":3000,"kind":"page","lang":"ja","lastmod":1427859496,"objectID":"19ecbaa5e12f7a9ebcff703c79534a52","permalink":"https://blog.johtani.info/blog/2015/04/01/elasticsearch-1-5-0-released-ja/","publishdate":"2015-04-01T12:38:16+09:00","readingtime":6,"relpermalink":"/blog/2015/04/01/elasticsearch-1-5-0-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.0 Released 本日（3/23）、Lucene 4.10.4ベースのEla","tags":["elasticsearch"],"title":"Elasticsearch 1.5.0リリース（日本語訳）","type":"post","url":"/blog/2015/04/01/elasticsearch-1-5-0-released-ja/","weight":0,"wordcount":2965},{"date":1426059991,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1426059991,"objectID":"ced9df0d8c8ed14de91c509b31b4c4ae","permalink":"https://blog.johtani.info/blog/2015/03/11/attend-elasticon/","publishdate":"2015-03-11T16:46:31+09:00","readingtime":2,"relpermalink":"/blog/2015/03/11/attend-elasticon/","section":"post","summary":"サンフランシスコからこんにちは。 今、私は、弊社初のユーザカンファレンスelastic{ON}に 参加するために、初のアメリカ出張中です。 初のユ","tags":["elastic","elasticon"],"title":"#elasticon に参加中","type":"post","url":"/blog/2015/03/11/attend-elasticon/","weight":0,"wordcount":806},{"date":1425030596,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":7100,"kind":"page","lang":"ja","lastmod":1425030596,"objectID":"cb13b64d0127c13bb466c4d4677a7b8a","permalink":"https://blog.johtani.info/blog/2015/02/27/you-know-for-security-shield-goes-ga-ja/","publishdate":"2015-02-27T18:49:56+09:00","readingtime":15,"relpermalink":"/blog/2015/02/27/you-know-for-security-shield-goes-ga-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：you know, for security: shield goes ga 1/27にShield 1.0 をリリースしました。 Elasticsearc","tags":["elasticsearch","shield"],"title":"セキュリティ向けプラグインShieldのリリース（日本語訳）","type":"post","url":"/blog/2015/02/27/you-know-for-security-shield-goes-ga-ja/","weight":0,"wordcount":7044},{"date":1425024629,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":300,"kind":"page","lang":"ja","lastmod":1425024629,"objectID":"f2cbe07bf2ff16d5a5860b4d6edbc5e8","permalink":"https://blog.johtani.info/blog/2015/02/27/2nd-tokyo-training/","publishdate":"2015-02-27T17:10:29+09:00","readingtime":1,"relpermalink":"/blog/2015/02/27/2nd-tokyo-training/","section":"post","summary":"4月13日から3日間、ElasticsearchのCoreトレーニングが東京で開催されます。 Early Birdということで、3/14までに申し込みす","tags":["elasticsearch"],"title":"Elasticsearch Coreトレーニング開催","type":"post","url":"/blog/2015/02/27/2nd-tokyo-training/","weight":0,"wordcount":251},{"date":1424408752,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1424408752,"objectID":"eee039f49a5b570599cf459c55c649f3","permalink":"https://blog.johtani.info/blog/2015/02/20/kibana-4-literally-ja/","publishdate":"2015-02-20T14:05:52+09:00","readingtime":5,"relpermalink":"/blog/2015/02/20/kibana-4-literally-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：kibana 4. literally. Kibana 4は現在、文字通り、抽象的に、概念的に、精神的に、そしてとても楽しく","tags":["elasticsearch","kibana4"],"title":"Kibana 4（日本語訳）","type":"post","url":"/blog/2015/02/20/kibana-4-literally-ja/","weight":0,"wordcount":2342},{"date":1424408734,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1424408734,"objectID":"ddd3e6f6e298d3884abc4d888a043664","permalink":"https://blog.johtani.info/blog/2015/02/20/elasticsearch-1-4-4-and-1-3-9-released-ja/","publishdate":"2015-02-20T14:05:34+09:00","readingtime":2,"relpermalink":"/blog/2015/02/20/elasticsearch-1-4-4-and-1-3-9-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.4 and 1.3.9 released 本日（2/20）、Elasticsearch 1.4.","tags":["elasticsearch"],"title":"Elasticsearch 1.4.4および1.3.9リリース（日本語訳）","type":"post","url":"/blog/2015/02/20/elasticsearch-1-4-4-and-1-3-9-released-ja/","weight":0,"wordcount":618},{"date":1424240573,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":500,"kind":"page","lang":"ja","lastmod":1424240573,"objectID":"5b97ead91c0dd0bad57b4f43a89149a2","permalink":"https://blog.johtani.info/blog/2015/02/18/preparing-elasticsearch-meetup-in-nagoya/","publishdate":"2015-02-18T15:22:53+09:00","readingtime":1,"relpermalink":"/blog/2015/02/18/preparing-elasticsearch-meetup-in-nagoya/","section":"post","summary":"来る、4月4日の土曜日の午後に名古屋でElasticsearch勉強会を開催予定です。 「初」の東京以外の勉強会です。 Twitterでこのよう","tags":["elasticsearch","勉強会"],"title":"名古屋でElasticsearch勉強会を開催します","type":"post","url":"/blog/2015/02/18/preparing-elasticsearch-meetup-in-nagoya/","weight":0,"wordcount":477},{"date":1424066543,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2200,"kind":"page","lang":"ja","lastmod":1424066543,"objectID":"997acc135d01b54f7de77a432fb9133f","permalink":"https://blog.johtani.info/blog/2015/02/16/8th-elasticsearch-jp/","publishdate":"2015-02-16T15:02:23+09:00","readingtime":5,"relpermalink":"/blog/2015/02/16/8th-elasticsearch-jp/","section":"post","summary":"第8回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第8回Elasticsearch勉強会を開催しました。#elasticsearchjp","type":"post","url":"/blog/2015/02/16/8th-elasticsearch-jp/","weight":0,"wordcount":2116},{"date":1423721589,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1423721589,"objectID":"1fed22e99b0e11a50eb7b92cb1644e8a","permalink":"https://blog.johtani.info/blog/2015/02/12/running-groovy-scripts-without-dynamic-scripting-ja/","publishdate":"2015-02-12T15:13:09+09:00","readingtime":6,"relpermalink":"/blog/2015/02/12/running-groovy-scripts-without-dynamic-scripting-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：running groovy scripts without dynamic scripting Elasticsearch1.3.8と1.4.3のリリースによ","tags":["elasticsearch"],"title":"Groovyスクリプトをダイナミックスクリプトなしで実行(日本語訳)","type":"post","url":"/blog/2015/02/12/running-groovy-scripts-without-dynamic-scripting-ja/","weight":0,"wordcount":2744},{"date":1423712393,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1423712393,"objectID":"5badf61ecb9cfadd7d6af58712fa5f6f","permalink":"https://blog.johtani.info/blog/2015/02/12/elasticsearch-1-4-3-and-1-3-8-released-ja/","publishdate":"2015-02-12T12:39:53+09:00","readingtime":4,"relpermalink":"/blog/2015/02/12/elasticsearch-1-4-3-and-1-3-8-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElas","tags":["elasticsearch"],"title":"Elasticsearch　1.4.3および1.3.8リリース（日本語訳）","type":"post","url":"/blog/2015/02/12/elasticsearch-1-4-3-and-1-3-8-released-ja/","weight":0,"wordcount":1576},{"date":1422500368,"dir":"post/2015/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1422500368,"objectID":"fe6ba10cc6c9509b4b22e9d59e029775","permalink":"https://blog.johtani.info/blog/2015/01/29/talk-at-cross2015/","publishdate":"2015-01-29T11:59:28+09:00","readingtime":3,"relpermalink":"/blog/2015/01/29/talk-at-cross2015/","section":"post","summary":"今年もCROSS参加しました。そして、話もしてきました。 今年は横浜の大さん橋でした。横浜はあんまりこないので、乗り換えでおたおたしてしまいま","tags":["勉強会","elasticsearch"],"title":"CROSS 2015で話をしてきました #cross2015","type":"post","url":"/blog/2015/01/29/talk-at-cross2015/","weight":0,"wordcount":1309},{"date":1420026086,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1420026086,"objectID":"b36abffbe5d6a0de73a9968604a1a3f9","permalink":"https://blog.johtani.info/blog/2014/12/31/looking-back-2014/","publishdate":"2014-12-31T20:41:26+09:00","readingtime":4,"relpermalink":"/blog/2014/12/31/looking-back-2014/","section":"post","summary":"今年は大晦日になってしまいました。しかも、ちょっと飲んでたり。。。 第9流しながら書いてます。 振り返り(2013年に書いた抱負から) まずは昨年","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2014）","type":"post","url":"/blog/2014/12/31/looking-back-2014/","weight":0,"wordcount":1722},{"date":1419490380,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1900,"kind":"page","lang":"ja","lastmod":1419490380,"objectID":"cb9649eca3dfbd356527ffc88f1dcb94","permalink":"https://blog.johtani.info/blog/2014/12/25/pickup-elasticsearch-2-0-0-labels/","publishdate":"2014-12-25T15:53:00+09:00","readingtime":4,"relpermalink":"/blog/2014/12/25/pickup-elasticsearch-2-0-0-labels/","section":"post","summary":"この記事はElasticsearch Advent Calndar 2014の25日目のエントリです。 あっという間に最終日です。来年につなげるという意味で、Elasti","tags":["elasticsearch"],"title":"Elasticsearch 2.0系のIssueの紹介","type":"post","url":"/blog/2014/12/25/pickup-elasticsearch-2-0-0-labels/","weight":0,"wordcount":1842},{"date":1418890008,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1700,"kind":"page","lang":"ja","lastmod":1418890008,"objectID":"7dea465ad52758b10cbceb08c81d1760","permalink":"https://blog.johtani.info/blog/2014/12/18/marvel-1-3-0-released-ja/","publishdate":"2014-12-18T17:06:48+09:00","readingtime":4,"relpermalink":"/blog/2014/12/18/marvel-1-3-0-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：marvel 1.3.0 released 12/17に、Elasticsearch Marvel 1.3.0をリリースしました","tags":["elasticsearch","marvel"],"title":"Marvel 1.3.0リリース（日本語訳）","type":"post","url":"/blog/2014/12/18/marvel-1-3-0-released-ja/","weight":0,"wordcount":1689},{"date":1418880374,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1418880374,"objectID":"bce2fa6458f39a75e2713f3d687271a1","permalink":"https://blog.johtani.info/blog/2014/12/18/elasticsearch-1-4-2-released-ja/","publishdate":"2014-12-18T14:26:14+09:00","readingtime":2,"relpermalink":"/blog/2014/12/18/elasticsearch-1-4-2-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElas","tags":["elasticsearch"],"title":"Elasticsearch 1.4.2および1.3.7リリース（日本語訳）","type":"post","url":"/blog/2014/12/18/elasticsearch-1-4-2-released-ja/","weight":0,"wordcount":987},{"date":1418809314,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1418809314,"objectID":"e5390751969ab21df280b7591854b89f","permalink":"https://blog.johtani.info/blog/2014/12/17/jjug-night-seminar-dec-2014/","publishdate":"2014-12-17T18:41:54+09:00","readingtime":4,"relpermalink":"/blog/2014/12/17/jjug-night-seminar-dec-2014/","section":"post","summary":"「【東京】JJUG ナイト・セミナー「機械学習・自然言語処理特集！」12/17（水）開催」でLuceneの話をしてきました。 本当にごく簡単な入","tags":["elasticsearch","jjug"],"title":"JJUG ナイトセミナーでLuceneの簡単な紹介をしてきました。#JJUG","type":"post","url":"/blog/2014/12/17/jjug-night-seminar-dec-2014/","weight":0,"wordcount":1741},{"date":1418698892,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":400,"kind":"page","lang":"ja","lastmod":1418698892,"objectID":"05330c3703d0e2c96cfe657ab33f130c","permalink":"https://blog.johtani.info/blog/2014/12/16/a-coffee-break/","publishdate":"2014-12-16T12:01:32+09:00","readingtime":1,"relpermalink":"/blog/2014/12/16/a-coffee-break/","section":"post","summary":"たまには、他愛のないブログを。 仕事しながら、コーヒーを飲んでます。 最近は、サムライズムさんのオフィスに入り浸って仕事してます。 オフィスには、","tags":["misc","coffee"],"title":"コーヒーブレイク","type":"post","url":"/blog/2014/12/16/a-coffee-break/","weight":0,"wordcount":348},{"date":1418486440,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":4300,"kind":"page","lang":"ja","lastmod":1418486440,"objectID":"4a3c42c9c5ac29db268010bbebf4f579","permalink":"https://blog.johtani.info/blog/2014/12/14/plugin-ecosystem-changes/","publishdate":"2014-12-14T01:00:40+09:00","readingtime":9,"relpermalink":"/blog/2014/12/14/plugin-ecosystem-changes/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：exciting logstash plugin ecosystem changes Logstash 1.5.0 Beta 1(お試しはこちら)のリリースで、 プラグインのインストー","tags":["logstash"],"title":"Logstashプラグインのエコシステムの変更（日本語訳）","type":"post","url":"/blog/2014/12/14/plugin-ecosystem-changes/","weight":0,"wordcount":4229},{"date":1418372246,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":3800,"kind":"page","lang":"ja","lastmod":1418372246,"objectID":"1bc36080b2493aab78c26e4f2152542c","permalink":"https://blog.johtani.info/blog/2014/12/12/logstash-1-5-0-beta1-released-ja/","publishdate":"2014-12-12T17:17:26+09:00","readingtime":8,"relpermalink":"/blog/2014/12/12/logstash-1-5-0-beta1-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：logstash 1.5.0.beta1 released Logstash 1.5.0 Beta1をリリースしました。こちらのページからダウンロードで","tags":["logstash"],"title":"Logstash 1.5.0 Beta1リリース(日本語訳)","type":"post","url":"/blog/2014/12/12/logstash-1-5-0-beta1-released-ja/","weight":0,"wordcount":3756},{"date":1417424748,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":3700,"kind":"page","lang":"ja","lastmod":1417424748,"objectID":"2de582c67fca31500621ecd6d3917a07","permalink":"https://blog.johtani.info/blog/2014/12/01/about-elasticsearch-in-2014/","publishdate":"2014-12-01T18:05:48+09:00","readingtime":8,"relpermalink":"/blog/2014/12/01/about-elasticsearch-in-2014/","section":"post","summary":"早いもので、師走です。今年もあと少しとなりました。ということで、Advent Calendarの季節が始まりました。 この記事はElastics","tags":["elasticsearch"],"title":"2014年のElasticsearch","type":"post","url":"/blog/2014/12/01/about-elasticsearch-in-2014/","weight":0,"wordcount":3655},{"date":1417056212,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1417056212,"objectID":"0a8183ced0e9e3e895b41286e54e8e4d","permalink":"https://blog.johtani.info/blog/2014/11/27/elasticsearch-1-4-1-released-ja/","publishdate":"2014-11-27T11:43:32+09:00","readingtime":4,"relpermalink":"/blog/2014/11/27/elasticsearch-1-4-1-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.1 and 1.3.6 released 本日、Lucene 4.10.2をベースにしたElas","tags":["elasticsearch"],"title":"Elasticsearch 1.4.1および1.3.6リリース（日本語訳）","type":"post","url":"/blog/2014/11/27/elasticsearch-1-4-1-released-ja/","weight":0,"wordcount":1718},{"date":1416900346,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":3200,"kind":"page","lang":"ja","lastmod":1416900346,"objectID":"4d8f5e581eee602c7fd21da8eb68df9a","permalink":"https://blog.johtani.info/blog/2014/11/25/import-apache-accesslog-using-logstash-2/","publishdate":"2014-11-25T16:25:46+09:00","readingtime":7,"relpermalink":"/blog/2014/11/25/import-apache-accesslog-using-logstash-2/","section":"post","summary":"前回の「Logstashを利用したApacheアクセスログのインポート」の続きです。 前回の記事では、Logstashの設定ファイルについて説","tags":["logstash","kibana","elasticsearch"],"title":"インデックステンプレートとLogstash","type":"post","url":"/blog/2014/11/25/import-apache-accesslog-using-logstash-2/","weight":0,"wordcount":3101},{"date":1416558639,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":4400,"kind":"page","lang":"ja","lastmod":1416558639,"objectID":"937a597a8b399fd32caba88a3c1c7bc4","permalink":"https://blog.johtani.info/blog/2014/11/21/import-apache-accesslog-using-logstash/","publishdate":"2014-11-21T17:30:39+09:00","readingtime":9,"relpermalink":"/blog/2014/11/21/import-apache-accesslog-using-logstash/","section":"post","summary":"JJUG CCCや第7回Elasticsearch勉強会のKibana4のデモにアクセスログを利用しました。 ただ、セッションでは、どうやってElas","tags":["logstash","kibana","elasticsearch"],"title":"Logstashを利用したApacheアクセスログのインポート","type":"post","url":"/blog/2014/11/21/import-apache-accesslog-using-logstash/","weight":0,"wordcount":4322},{"date":1416363547,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1416363547,"objectID":"2a8412aa50d07330f1298f0243fa79d3","permalink":"https://blog.johtani.info/blog/2014/11/19/hold-on-7th-elasticsearch-jp/","publishdate":"2014-11-19T11:19:07+09:00","readingtime":5,"relpermalink":"/blog/2014/11/19/hold-on-7th-elasticsearch-jp/","section":"post","summary":"第7回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第7回Elasticsearch勉強会を開催しました。#elasticsearchjp","type":"post","url":"/blog/2014/11/19/hold-on-7th-elasticsearch-jp/","weight":0,"wordcount":2466},{"date":1415205033,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1415205033,"objectID":"d266a2023c67b7a20c3bd01055b223bc","permalink":"https://blog.johtani.info/blog/2014/11/06/elasticsearch-1-4-0-ja/","publishdate":"2014-11-06T01:30:33+09:00","readingtime":4,"relpermalink":"/blog/2014/11/06/elasticsearch-1-4-0-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch-1.4.0 and 1.3.5 released 本日、Lucene 4.10.2をベースにし","tags":["elasticsearch"],"title":"Elasticsearch 1.4.0および1.3.5リリース（日本語訳）","type":"post","url":"/blog/2014/11/06/elasticsearch-1-4-0-ja/","weight":0,"wordcount":1902},{"date":1414402951,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1414402951,"objectID":"bc2709406a9bb19e8d83a78f81e36244","permalink":"https://blog.johtani.info/blog/2014/10/27/how-to-use-validate-api/","publishdate":"2014-10-27T18:42:31+09:00","readingtime":6,"relpermalink":"/blog/2014/10/27/how-to-use-validate-api/","section":"post","summary":"久しぶりに翻訳ではないブログを。書こうと思いながらかけてなかったので。。。 今回はvalidate APIの紹介です。 背景 Elasticsear","tags":["elasticsearch"],"title":"validate APIの利用","type":"post","url":"/blog/2014/10/27/how-to-use-validate-api/","weight":0,"wordcount":2576},{"date":1413354368,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1413354368,"objectID":"998eda745d07fd8608f251138384a0b9","permalink":"https://blog.johtani.info/blog/2014/10/15/versioning-of-sonatype/","publishdate":"2014-10-15T15:26:08+09:00","readingtime":2,"relpermalink":"/blog/2014/10/15/versioning-of-sonatype/","section":"post","summary":"Elasticsearch 1.4.0.Beta1がリリースされました。 個人でelasticsearch-extended-analyzeというプラグインを開発してま","tags":["Elasticsearch","plugin","sonatype"],"title":"Sonatypeのバージョン番号で困ったので","type":"post","url":"/blog/2014/10/15/versioning-of-sonatype/","weight":0,"wordcount":657},{"date":1412244840,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":5400,"kind":"page","lang":"ja","lastmod":1412244840,"objectID":"853cac0f2d1f90b7c986e7d1dcdbbfde","permalink":"https://blog.johtani.info/blog/2014/10/02/elasticsearch-1-4-0-beta-released-ja/","publishdate":"2014-10-02T19:14:00+09:00","readingtime":11,"relpermalink":"/blog/2014/10/02/elasticsearch-1-4-0-beta-released-ja/","section":"post","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.0.beta1 released 本日、Lucene 4.10.1をベースにした、Elast","tags":["Elasticsearch"],"title":"elasticsearch 1.4.0.Beta1のリリース","type":"post","url":"/blog/2014/10/02/elasticsearch-1-4-0-beta-released-ja/","weight":0,"wordcount":5399},{"date":1410927720,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2100,"kind":"page","lang":"ja","lastmod":1410927720,"objectID":"4616fbea6a6dbc1074bc3f1016bbc73b","permalink":"https://blog.johtani.info/blog/2014/09/17/hold-on-6th-elasticsearch-jp/","publishdate":"2014-09-17T13:22:00+09:00","readingtime":4,"relpermalink":"/blog/2014/09/17/hold-on-6th-elasticsearch-jp/","section":"post","summary":"第6回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第6回Elasticsearch勉強会を開催しました。#elasticsearchjp","type":"post","url":"/blog/2014/09/17/hold-on-6th-elasticsearch-jp/","weight":0,"wordcount":2002},{"date":1410841260,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1410841260,"objectID":"f15702ae9e55bad42182cf18724d1863","permalink":"https://blog.johtani.info/blog/2014/09/16/book-publication-event/","publishdate":"2014-09-16T13:21:00+09:00","readingtime":2,"relpermalink":"/blog/2014/09/16/book-publication-event/","section":"post","summary":"先日2014年9月9日(火)に『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』 出版記念！執筆者が語る大講演会！で、 「elastics","tags":["勉強会","本"],"title":"elasticsearch.もうちょっと入門という話をしてきました #gihyo_efk","type":"post","url":"/blog/2014/09/16/book-publication-event/","weight":0,"wordcount":906},{"date":1410250260,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":7100,"kind":"page","lang":"ja","lastmod":1410250260,"objectID":"77d965afaebd7193badc746d52b4173f","permalink":"https://blog.johtani.info/blog/2014/09/09/performance-considerations-for-elasticsearch-indexing/","publishdate":"2014-09-09T17:11:00+09:00","readingtime":15,"relpermalink":"/blog/2014/09/09/performance-considerations-for-elasticsearch-indexing/","section":"post","summary":"Elasticsearchのインデキシングに関するパフォーマンス検討 原文：performance considerations for elasticsearch indexing Elasticsearchユーザは様","tags":["Elasticsearch"],"title":"Elasticsearchのインデキシングに関するパフォーマンス検討","type":"post","url":"/blog/2014/09/09/performance-considerations-for-elasticsearch-indexing/","weight":0,"wordcount":7072},{"date":1407156840,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1407156840,"objectID":"bdea71d64cdfcc405e65e750fe8d9b86","permalink":"https://blog.johtani.info/blog/2014/08/04/release-magazine-book-of-log-aggs-and-viz/","publishdate":"2014-08-04T21:54:00+09:00","readingtime":2,"relpermalink":"/blog/2014/08/04/release-magazine-book-of-log-aggs-and-viz/","section":"post","summary":"懲りずにまた、執筆してみました。みなさん「買って」から感想をいただけるとうれしいです！ 本書について 共著者の方々のブログが詳しいので、そちらを","tags":["elasticsearch","kibana","本"],"title":"サーバ/インフラエンジニア養成読本 ログ収集~可視化編 を手伝いました","type":"post","url":"/blog/2014/08/04/release-magazine-book-of-log-aggs-and-viz/","weight":0,"wordcount":803},{"date":1406874240,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1406874240,"objectID":"7cc605e721fdd1d2ccc16f5b6490e830","permalink":"https://blog.johtani.info/blog/2014/08/01/plugin-using-under-proxy-env/","publishdate":"2014-08-01T15:24:00+09:00","readingtime":3,"relpermalink":"/blog/2014/08/01/plugin-using-under-proxy-env/","section":"post","summary":"Proxy環境で働いている方も結構いると思います。 Twitter上で、Elasticsearchのpluginコマンドでプラグインがインスト","tags":["elasticsearch","plugin"],"title":"プロキシ環境でのpluginコマンドの実行","type":"post","url":"/blog/2014/08/01/plugin-using-under-proxy-env/","weight":0,"wordcount":1363},{"date":1406604120,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1406604120,"objectID":"fb1da4a6ed74705ad98bb60ad4badaf2","permalink":"https://blog.johtani.info/blog/2014/07/29/elasticsearch-1-3-1-release/","publishdate":"2014-07-29T12:22:00+09:00","readingtime":2,"relpermalink":"/blog/2014/07/29/elasticsearch-1-3-1-release/","section":"post","summary":"原文：Elasticsearch 1.3.1 Releasedを日本語に翻訳したものです。 バグフィックス版のElasticsearch 1.3.1をリリー","tags":["elasticsearch","release"],"title":"Elasticsearch 1.3.1 リリース（日本語訳）","type":"post","url":"/blog/2014/07/29/elasticsearch-1-3-1-release/","weight":0,"wordcount":742},{"date":1406524740,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":5600,"kind":"page","lang":"ja","lastmod":1406524740,"objectID":"0c1821d1069578551d0e3c7d9275f16b","permalink":"https://blog.johtani.info/blog/2014/07/28/curator-2-0-and-1-1/","publishdate":"2014-07-28T14:19:00+09:00","readingtime":11,"relpermalink":"/blog/2014/07/28/curator-2-0-and-1-1/","section":"post","summary":"Curatorの1.2.0がリリースされました。 前回のCuratorの記事が古くなってしまった（1.1.0からコマンドのI/Fが変更された）","tags":["elasticsearch","curator"],"title":"Curator 1.2および1.1について","type":"post","url":"/blog/2014/07/28/curator-2-0-and-1-1/","weight":0,"wordcount":5505},{"date":1405774320,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1405774320,"objectID":"e3e146469ed4318eaa2ffbca3510c054","permalink":"https://blog.johtani.info/blog/2014/07/19/hold-on-5th-elasticsearch-jp/","publishdate":"2014-07-19T21:52:00+09:00","readingtime":5,"relpermalink":"/blog/2014/07/19/hold-on-5th-elasticsearch-jp/","section":"post","summary":"第5回Elasticsearch勉強会を開催しました。 遅くなってしまいましたが、まとめてみました。 今回は、Elasticsearchに入って","tags":["elasticsearch","勉強会"],"title":"第5回Elasticsearch勉強会を開催しました。#elasticsearchjp","type":"post","url":"/blog/2014/07/19/hold-on-5th-elasticsearch-jp/","weight":0,"wordcount":2350},{"date":1404181800,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1404181800,"objectID":"21a8e6324e9330d4f8ebade604c62b6e","permalink":"https://blog.johtani.info/blog/2014/07/01/join-elasticsearch/","publishdate":"2014-07-01T11:30:00+09:00","readingtime":2,"relpermalink":"/blog/2014/07/01/join-elasticsearch/","section":"post","summary":"ということで、転職しました。 どーしてもやりたいことが出てきたので、無理を言って転職することにしてみました。 サムライズムではなく、Elasti","tags":["転職"],"title":"転職しました","type":"post","url":"/blog/2014/07/01/join-elasticsearch/","weight":0,"wordcount":745},{"date":1404137940,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":100,"kind":"page","lang":"ja","lastmod":1404137940,"objectID":"40abea0a87a64bd832a1fad69458b293","permalink":"https://blog.johtani.info/blog/2014/06/30/resignation/","publishdate":"2014-06-30T23:19:00+09:00","readingtime":1,"relpermalink":"/blog/2014/06/30/resignation/","section":"post","summary":"退職しました。 色々と書きたいんですが、時差ボケで頭痛いので、このくらいです。 余裕出たら書くかも。 ほしい物リストはこちら 新天地についてはまた明","tags":["転職"],"title":"退職しました","type":"post","url":"/blog/2014/06/30/resignation/","weight":0,"wordcount":72},{"date":1402908420,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1700,"kind":"page","lang":"ja","lastmod":1402908420,"objectID":"916bda59bc7621d5c1790c040572a3c0","permalink":"https://blog.johtani.info/blog/2014/06/16/first-impression-elasticsearch-server-2nd-edition/","publishdate":"2014-06-16T17:47:00+09:00","readingtime":4,"relpermalink":"/blog/2014/06/16/first-impression-elasticsearch-server-2nd-edition/","section":"post","summary":"Elasticsearch server 2nd editionが発売されています。 私が翻訳したのは前のバージョンですが。。。 まずは、目次を元にどのくらい変わってるかを見てみました。 （","tags":["elasticsearch","本"],"title":"Elasticsearch server 2nd editionのファーストインプレッション","type":"post","url":"/blog/2014/06/16/first-impression-elasticsearch-server-2nd-edition/","weight":0,"wordcount":1650},{"date":1401884100,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1401884100,"objectID":"5bb6f8322cdbda7a21e4aecbe04462b7","permalink":"https://blog.johtani.info/blog/2014/06/04/attending-visualize-study/","publishdate":"2014-06-04T21:15:00+09:00","readingtime":3,"relpermalink":"/blog/2014/06/04/attending-visualize-study/","section":"post","summary":"可視化ツール現状確認会に参加して、カジュアルウォーターじゃなくて可視化ツールの現状を確認してきました。 ということで、いつものメモです。 Mackerel と Graphite","tags":["勉強会"],"title":"可視化ツール現状確認会に参加してきました。#可視化","type":"post","url":"/blog/2014/06/04/attending-visualize-study/","weight":0,"wordcount":1082},{"date":1400840280,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1400840280,"objectID":"a578acf825a595ce95fe8f804b7208f0","permalink":"https://blog.johtani.info/blog/2014/05/23/attending-drecom-infra-study/","publishdate":"2014-05-23T19:18:00+09:00","readingtime":3,"relpermalink":"/blog/2014/05/23/attending-drecom-infra-study/","section":"post","summary":"今月2回目の目黒で、初のドリコムさんです。 「最新インフラエンジニア技術勉強～Fluentd, Elasticsearch,Chefの実践実例～","tags":["勉強会","elasticsearch"],"title":"最新インフラエンジニア技術勉強に参加しました。","type":"post","url":"/blog/2014/05/23/attending-drecom-infra-study/","weight":0,"wordcount":1274},{"date":1400143800,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1400143800,"objectID":"706c033b4483b6d062b66d6e4ea0236a","permalink":"https://blog.johtani.info/blog/2014/05/15/amazon-cloud-seaarch-study-session/","publishdate":"2014-05-15T17:50:00+09:00","readingtime":3,"relpermalink":"/blog/2014/05/15/amazon-cloud-seaarch-study-session/","section":"post","summary":"どうやら、中身がSolrベース？Luceneベース？になったらしいということで、 今日は「AWSプロダクトシリーズ｜よくわかるAmazon Cl","tags":["勉強会","CloudSearch","AWS"],"title":"「よくわかるAmazon #CloudSearch 」に行ってきました！","type":"post","url":"/blog/2014/05/15/amazon-cloud-seaarch-study-session/","weight":0,"wordcount":1448},{"date":1399999440,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1399999440,"objectID":"72df0bf7853e05560d94208817b83468","permalink":"https://blog.johtani.info/blog/2014/05/14/spiritual-entry1/","publishdate":"2014-05-14T01:44:00+09:00","readingtime":2,"relpermalink":"/blog/2014/05/14/spiritual-entry1/","section":"post","summary":"酔っ払ってなんとなく書きたくなったスピリチュアルなブログなので、流していただければと。 最近、勉強会やTwitterで知り合いになって話をする","tags":["スピリチュアル"],"title":"外の世界を知るということ","type":"post","url":"/blog/2014/05/14/spiritual-entry1/","weight":0,"wordcount":741},{"date":1399563900,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1399563900,"objectID":"91fe03f994e8e85cede4e3bd62f4d6b7","permalink":"https://blog.johtani.info/blog/2014/05/09/reading-agile-data-science/","publishdate":"2014-05-09T00:45:00+09:00","readingtime":4,"relpermalink":"/blog/2014/05/09/reading-agile-data-science/","section":"post","summary":"「アジャイルデータサイエンス」の見本をいただいてしまいました。 なので、感想文でも書いてみようかと。 どんな本？ 想像以上に薄かったです、物理的に","tags":["感想文","オライリー"],"title":"アジャイルデータサイエンスが届きました","type":"post","url":"/blog/2014/05/09/reading-agile-data-science/","weight":0,"wordcount":1549},{"date":1399456620,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1399456620,"objectID":"ed4f5a398056eef1cf6caa90786b340a","permalink":"https://blog.johtani.info/blog/2014/05/07/aggregation-example/","publishdate":"2014-05-07T18:57:00+09:00","readingtime":6,"relpermalink":"/blog/2014/05/07/aggregation-example/","section":"post","summary":"こんなツイートを見つけたので、Aggregationのサンプルでも書こうかなと。（前から書こうと思ってたんですが。。。） @elasticsearch Hi, Would you please tell me the way to","tags":["elasticsearch"],"title":"Aggregations - ファセットよりも柔軟な集計","type":"post","url":"/blog/2014/05/07/aggregation-example/","weight":0,"wordcount":2683},{"date":1399132860,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":600,"kind":"page","lang":"ja","lastmod":1399132860,"objectID":"2824bef72110575c78aeb979170212b8","permalink":"https://blog.johtani.info/blog/2014/05/04/intro-elasticsearch-kopf-alias-percolator/","publishdate":"2014-05-04T01:01:00+09:00","readingtime":2,"relpermalink":"/blog/2014/05/04/intro-elasticsearch-kopf-alias-percolator/","section":"post","summary":"今日はelasticsearch-kopfのAnalysis画面の紹介です。 （簡単なところから。。。その３） ちょっとあいだが開いてしまいまし","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（aliases画面）","type":"post","url":"/blog/2014/05/04/intro-elasticsearch-kopf-alias-percolator/","weight":0,"wordcount":503},{"date":1398341460,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2200,"kind":"page","lang":"ja","lastmod":1398341460,"objectID":"e396cbf9274b590a1d94ee43d823a0bd","permalink":"https://blog.johtani.info/blog/2014/04/24/usage-stream2es/","publishdate":"2014-04-24T21:11:00+09:00","readingtime":5,"relpermalink":"/blog/2014/04/24/usage-stream2es/","section":"post","summary":"kopfの記事の続きも書く必要があるんだけど、こんなツイートを見つけてしまったので。。。 ElasticsearchのBulk APIの仕様、J","tags":["elasticsearch","stream2es"],"title":"stream2esと複数データの登録","type":"post","url":"/blog/2014/04/24/usage-stream2es/","weight":0,"wordcount":2154},{"date":1398077040,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":3300,"kind":"page","lang":"ja","lastmod":1398077040,"objectID":"50562b09417cd8c4a2348a0a5aabe754","permalink":"https://blog.johtani.info/blog/2014/04/21/hold-on-4th-elasticsearch-jp/","publishdate":"2014-04-21T19:44:00+09:00","readingtime":7,"relpermalink":"/blog/2014/04/21/hold-on-4th-elasticsearch-jp/","section":"post","summary":"第4回Elsticsearch勉強会を開催しました。 今回から、遅刻厳禁にしてみました。 それほど困った人もいないと思うので、次回からも遅刻厳禁","tags":["elasticsearch","勉強会"],"title":"第4回Elasticsearch勉強会を開催しました。#elasticsearchjp","type":"post","url":"/blog/2014/04/21/hold-on-4th-elasticsearch-jp/","weight":0,"wordcount":3217},{"date":1397011260,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1397011260,"objectID":"76a1fb7f21fda9eddb95426b65124517","permalink":"https://blog.johtani.info/blog/2014/04/09/intro-elasticsearch-kopf-analysis/","publishdate":"2014-04-09T11:41:00+09:00","readingtime":2,"relpermalink":"/blog/2014/04/09/intro-elasticsearch-kopf-analysis/","section":"post","summary":"今日はelasticsearch-kopfのAnalysis画面の紹介です。 （簡単なところから。。。その２） メニューのanalysisを選択","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（analysis画面）","type":"post","url":"/blog/2014/04/09/intro-elasticsearch-kopf-analysis/","weight":0,"wordcount":944},{"date":1396866240,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1396866240,"objectID":"299abcee56b05b312ed5700f686f79b8","permalink":"https://blog.johtani.info/blog/2014/04/07/attend-jvm-casual-1/","publishdate":"2014-04-07T19:24:00+09:00","readingtime":5,"relpermalink":"/blog/2014/04/07/attend-jvm-casual-1/","section":"post","summary":"JVM Operation Casual Talksに参加しました。 あんまり、運用とかやってないので、ついていけるか不安ですが、楽しそうだったので。 懇親会は予定されてないらしい","tags":["JVM","Java","勉強会"],"title":"JVM Operation Casual Talksに参加しました #jvmcasual","type":"post","url":"/blog/2014/04/07/attend-jvm-casual-1/","weight":0,"wordcount":2447},{"date":1396837440,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1396837440,"objectID":"670744b945088de05866864f7d57bee7","permalink":"https://blog.johtani.info/blog/2014/04/07/intro-elasticsearch-kopf-rest/","publishdate":"2014-04-07T11:24:00+09:00","readingtime":2,"relpermalink":"/blog/2014/04/07/intro-elasticsearch-kopf-rest/","section":"post","summary":"今日はelasticsearch-kopfのREST画面の紹介です。 （簡単なところから。。。） メニューのrestを選択すると、次のような画面","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（rest画面）","type":"post","url":"/blog/2014/04/07/intro-elasticsearch-kopf-rest/","weight":0,"wordcount":937},{"date":1396707480,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1396707480,"objectID":"c1241374502f200cf9fc49c8d6fb5822","permalink":"https://blog.johtani.info/blog/2014/04/05/intro-elasticsearch-kopf-1/","publishdate":"2014-04-05T23:18:00+09:00","readingtime":3,"relpermalink":"/blog/2014/04/05/intro-elasticsearch-kopf-1/","section":"post","summary":"なんだか、ドタバタしてて久しぶりの更新です。 ベルリンの旅行記みたいなのも書きたいのですが、まずはこちらかと。 elasticsearch-ko","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（概要）","type":"post","url":"/blog/2014/04/05/intro-elasticsearch-kopf-1/","weight":0,"wordcount":1288},{"date":1395722580,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1395722580,"objectID":"d51032bef3e7117a94336fea18a3fad7","permalink":"https://blog.johtani.info/blog/2014/03/25/release-elasticsearch-server-ja-ebook/","publishdate":"2014-03-25T13:43:00+09:00","readingtime":2,"relpermalink":"/blog/2014/03/25/release-elasticsearch-server-ja-ebook/","section":"post","summary":"先日、「ElasticSearch Serverを翻訳しました」という記事を書きました。 この中で電子版も出ますよと書いていましたが、電子版も発","tags":["elasticsearch"],"title":"ElasticSearch Server日本語版（電子版も）が発売されました","type":"post","url":"/blog/2014/03/25/release-elasticsearch-server-ja-ebook/","weight":0,"wordcount":717},{"date":1395151860,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1395151860,"objectID":"65453a1ae403679bd2e47398a04205ca","permalink":"https://blog.johtani.info/blog/2014/03/18/attend-goto-night-elasticsearch/","publishdate":"2014-03-18T23:11:00+09:00","readingtime":2,"relpermalink":"/blog/2014/03/18/attend-goto-night-elasticsearch/","section":"post","summary":"GOTO Night elasticsearchに参加しました。 初の海外の勉強会です（海外自体が初だし）。 ベルリンにあるWoogaという会社で開催された勉強会","tags":["elasticsearch","勉強会"],"title":"GOTO Night elasticsearchに参加しました","type":"post","url":"/blog/2014/03/18/attend-goto-night-elasticsearch/","weight":0,"wordcount":867},{"date":1394916660,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":300,"kind":"page","lang":"ja","lastmod":1394916660,"objectID":"abc5ca9856a61831fd4ed06b402875d2","permalink":"https://blog.johtani.info/blog/2014/03/16/post-from-berlin/","publishdate":"2014-03-16T05:51:00+09:00","readingtime":1,"relpermalink":"/blog/2014/03/16/post-from-berlin/","section":"post","summary":"Berlinからおはようございます。 ということで、人生で初めての海外に来ています。 人生初の海外なのに、一人で乗り換えがあるようなBerlin","tags":["misc","travel"],"title":"Berlinからおはようございます","type":"post","url":"/blog/2014/03/16/post-from-berlin/","weight":0,"wordcount":226},{"date":1394515380,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1394515380,"objectID":"386dc9d1b647a9f3965f1fbe29c7dfb9","permalink":"https://blog.johtani.info/blog/2014/03/11/es-plugin-installed-to-my-env/","publishdate":"2014-03-11T14:23:00+09:00","readingtime":4,"relpermalink":"/blog/2014/03/11/es-plugin-installed-to-my-env/","section":"post","summary":"elasticsearchに、このへん入れるときっと幸せになれるはず・たぶん。\u0026#10;elasticsearch/elasticsearc","tags":["elasticsearch","plugin"],"title":"いつも入れているElasticsearchのプラグイン","type":"post","url":"/blog/2014/03/11/es-plugin-installed-to-my-env/","weight":0,"wordcount":1509},{"date":1393836900,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1393836900,"objectID":"9ad72c2a5157f21741bd4581a562dfc7","permalink":"https://blog.johtani.info/blog/2014/03/03/release-elasticsearch-server-japanese-edition/","publishdate":"2014-03-03T17:55:00+09:00","readingtime":3,"relpermalink":"/blog/2014/03/03/release-elasticsearch-server-japanese-edition/","section":"post","summary":"第3回Elasticsearch勉強会で、軽く触れていましたが、ElasticSearch Server日本語版が発売されます。 ツイートなども","tags":["elasticsearch"],"title":"ElasticSearch Serverを翻訳しました","type":"post","url":"/blog/2014/03/03/release-elasticsearch-server-japanese-edition/","weight":0,"wordcount":1468},{"date":1393231920,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1393231920,"objectID":"f55d33371dcff207fd7d201128df2ea3","permalink":"https://blog.johtani.info/blog/2014/02/24/strange-behavior-of-field-in-nested-obj/","publishdate":"2014-02-24T17:52:00+09:00","readingtime":5,"relpermalink":"/blog/2014/02/24/strange-behavior-of-field-in-nested-obj/","section":"post","summary":"今年初の「突撃！隣のElasticsearch」ということで、Wantedlyさんにおじゃましました。 ※写真を自分でも撮ったのですが、画像が","tags":["elasticsearch"],"title":"Nested Objectのフィールドの奇妙な動作","type":"post","url":"/blog/2014/02/24/strange-behavior-of-field-in-nested-obj/","weight":0,"wordcount":2330},{"date":1391787720,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1700,"kind":"page","lang":"ja","lastmod":1391787720,"objectID":"229b7fc784707b1d2c702fbeba080e86","permalink":"https://blog.johtani.info/blog/2014/02/08/hold-3rd-elasticsaerch-meetup-in-tokyo/","publishdate":"2014-02-08T00:42:00+09:00","readingtime":4,"relpermalink":"/blog/2014/02/08/hold-3rd-elasticsaerch-meetup-in-tokyo/","section":"post","summary":"今回はたまたま日本にいたElasticsearchの人をスペシャルゲストに呼べたので、大満足ですｗ 英語の通訳とかちゃんと勉強しないとなぁ。。","tags":["elasticsearch","勉強会"],"title":"第3回elasticsearch勉強会を開催しました！ #elasticsearchjp","type":"post","url":"/blog/2014/02/08/hold-3rd-elasticsaerch-meetup-in-tokyo/","weight":0,"wordcount":1671},{"date":1391695740,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2100,"kind":"page","lang":"ja","lastmod":1391695740,"objectID":"c98cbc333fb7d95c6c9fc4924b0526e1","permalink":"https://blog.johtani.info/blog/2014/02/06/es-cluster-start-using-vagrant-and-puppet/","publishdate":"2014-02-06T23:09:00+09:00","readingtime":5,"relpermalink":"/blog/2014/02/06/es-cluster-start-using-vagrant-and-puppet/","section":"post","summary":"すずけんさんがVagrant+puppet使って、VM起動してElasticsearchのクラスタを組んでる記事を書いているのを見て、試して","tags":["elasticsearch","vagrant","puppet","marvel"],"title":"すずけんさんのメモを元にVagrantでElasticsearchクラスタを起動してみた","type":"post","url":"/blog/2014/02/06/es-cluster-start-using-vagrant-and-puppet/","weight":0,"wordcount":2095},{"date":1390988760,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1200,"kind":"page","lang":"ja","lastmod":1390988760,"objectID":"c6107ff57e96a1373c019d252c00ad84","permalink":"https://blog.johtani.info/blog/2014/01/29/hold-to-japan-solr-meetup/","publishdate":"2014-01-29T18:46:00+09:00","readingtime":3,"relpermalink":"/blog/2014/01/29/hold-to-japan-solr-meetup/","section":"post","summary":"改訂新版Solr入門出版記念ということで、第13回Solr勉強会 #SolrJP 新Solr本出版記念を開催しました。 出版記念なので、技術評論社様より、プレ","tags":["Solr","勉強会"],"title":"第13回Solr勉強会を開催しました","type":"post","url":"/blog/2014/01/29/hold-to-japan-solr-meetup/","weight":0,"wordcount":1107},{"date":1390983240,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1390983240,"objectID":"f6debed350f20a2b3aa4d970e3227411","permalink":"https://blog.johtani.info/blog/2014/01/29/simple-introduction-and-first-impression-es-marvel/","publishdate":"2014-01-29T17:14:00+09:00","readingtime":6,"relpermalink":"/blog/2014/01/29/simple-introduction-and-first-impression-es-marvel/","section":"post","summary":"昨晩、Elasticsearchから初のプロダクトとなるMarvelがリリースされました。ということで、さっそく触ってみて、簡単な紹介と感想","tags":["elasticsearch","marvel"],"title":"Elasticsearch Marvelの紹介と第一印象","type":"post","url":"/blog/2014/01/29/simple-introduction-and-first-impression-es-marvel/","weight":0,"wordcount":2551},{"date":1390880040,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":600,"kind":"page","lang":"ja","lastmod":1390880040,"objectID":"c4e7199a586a308352b7a881add7e356","permalink":"https://blog.johtani.info/blog/2014/01/28/release-lucene-gosen-4-dot-6-1/","publishdate":"2014-01-28T12:34:00+09:00","readingtime":2,"relpermalink":"/blog/2014/01/28/release-lucene-gosen-4-dot-6-1/","section":"post","summary":"Lucene/Solr 4.6.1がリリースされそう(バイナリ配布待ち)lucene-gosenの4.6.1対応版をリリースしました。 ライブラリのインタフェースな","tags":["Solr","Lucene","lucene-gosen"],"title":"lucene-gosen 4.6.1のリリースに関する注意点","type":"post","url":"/blog/2014/01/28/release-lucene-gosen-4-dot-6-1/","weight":0,"wordcount":574},{"date":1390542480,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":4500,"kind":"page","lang":"ja","lastmod":1390542480,"objectID":"15f501351d482ffd73985a50f5c89d1f","permalink":"https://blog.johtani.info/blog/2014/01/24/curator-tending-your-time-series-indices-in-japanese/","publishdate":"2014-01-24T14:48:00+09:00","readingtime":9,"relpermalink":"/blog/2014/01/24/curator-tending-your-time-series-indices-in-japanese/","section":"post","summary":"Elasticsearchのcuratorのブログ記事を読んで、日本語でツイートしたところ、Aaron Mildensteinさんから日本語（","tags":["elasticsearch","curator"],"title":"Curator: 時系列インデックスの管理(日本語訳)","type":"post","url":"/blog/2014/01/24/curator-tending-your-time-series-indices-in-japanese/","weight":0,"wordcount":4441},{"date":1390317360,"dir":"post/2014/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1390317360,"objectID":"6425af51edead39c0e439073986043fb","permalink":"https://blog.johtani.info/blog/2014/01/22/release-extended-plugin-for-1-0-0rc1/","publishdate":"2014-01-22T00:16:00+09:00","readingtime":2,"relpermalink":"/blog/2014/01/22/release-extended-plugin-for-1-0-0rc1/","section":"post","summary":"あけましておめでとうございます。今年もSolrやElasticsearchについて色々と頑張っていく所存です。 とまぁ、お決まりの挨拶はおいて","tags":["elasticsearch"],"title":"Extended-Analyze 1.0.0RC1をリリースしました","type":"post","url":"/blog/2014/01/22/release-extended-plugin-for-1-0-0rc1/","weight":0,"wordcount":902},{"date":1388406000,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":3600,"kind":"page","lang":"ja","lastmod":1388406000,"objectID":"10c715f70de25ccb493bbbb532b78ced","permalink":"https://blog.johtani.info/blog/2013/12/30/looking-back-2013/","publishdate":"2013-12-30T21:20:00+09:00","readingtime":8,"relpermalink":"/blog/2013/12/30/looking-back-2013/","section":"post","summary":"昨年は、大晦日に書いてました。 ちょっと進歩したかも。 振り返り(2012年に書いた抱負から) ということで、まずは昨年書いた抱負からの振り返りで","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2013）","type":"post","url":"/blog/2013/12/30/looking-back-2013/","weight":0,"wordcount":3551},{"date":1387524240,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1387524240,"objectID":"c18b12fff24dc87e7f1039bd17c0c6aa","permalink":"https://blog.johtani.info/blog/2013/12/20/release-elasticsearch-0-90-8/","publishdate":"2013-12-20T16:24:00+09:00","readingtime":2,"relpermalink":"/blog/2013/12/20/release-elasticsearch-0-90-8/","section":"post","summary":"昨夜、Elasticsearchの0.90.8がリリースされました。 リリースされた内容などについては、本家のブログ「0.90.8 releas","tags":["elasticsearch","kuromoji"],"title":"Elasticsearch 0.90.8がリリースされました＆注意点（2013/12/20追記）","type":"post","url":"/blog/2013/12/20/release-elasticsearch-0-90-8/","weight":0,"wordcount":867},{"date":1387447740,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1387447740,"objectID":"cb5b6f7ab4d36e90d2619cb907ebb956","permalink":"https://blog.johtani.info/blog/2013/12/19/add-jar-file-to-solr/","publishdate":"2013-12-19T19:09:00+09:00","readingtime":3,"relpermalink":"/blog/2013/12/19/add-jar-file-to-solr/","section":"post","summary":"Solr本が出てから、質問を受けてブログ書くと言いながら書いてなかったことを思い出しました。。。 プラグインの配置方法についてこんな質問を受け","tags":["Solr"],"title":"Solrへのプラグインの配置方法について","type":"post","url":"/blog/2013/12/19/add-jar-file-to-solr/","weight":0,"wordcount":1008},{"date":1387249860,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1387249860,"objectID":"a0a00c23556fcc5dbfb7b7f43fbbb61d","permalink":"https://blog.johtani.info/blog/2013/12/17/release-es-extended-analyze-plugin-to-maven-and-sonatype/","publishdate":"2013-12-17T12:11:00+09:00","readingtime":2,"relpermalink":"/blog/2013/12/17/release-es-extended-analyze-plugin-to-maven-and-sonatype/","section":"post","summary":"ども。 プラグインのインストールに長いURL入れるの辛いですよね？ね？ ということで、MavenでリリースしてMaven Repositoryから","tags":["elasticsearch"],"title":"elasticsearch-extended-analyzeプラグインをMavenとSonatypeにリリース","type":"post","url":"/blog/2013/12/17/release-es-extended-analyze-plugin-to-maven-and-sonatype/","weight":0,"wordcount":770},{"date":1386554880,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":200,"kind":"page","lang":"ja","lastmod":1386554880,"objectID":"d9560caeb797b302191f667b4264da40","permalink":"https://blog.johtani.info/blog/2013/12/09/release-introduction-solr-ebook/","publishdate":"2013-12-09T11:08:00+09:00","readingtime":1,"relpermalink":"/blog/2013/12/09/release-introduction-solr-ebook/","section":"post","summary":"少し遅くなってしまいましたが、12/05に電子書籍も発売されました。 技術評論社の電子書籍サイトから購入可能です。 書籍のページへのリンク PDF","tags":["Solr"],"title":"改訂版Solr入門のPDF版も発売","type":"post","url":"/blog/2013/12/09/release-introduction-solr-ebook/","weight":0,"wordcount":190},{"date":1385436420,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1385436420,"objectID":"a2012a3c9cdb1d6fd69afdbadc1e76b6","permalink":"https://blog.johtani.info/blog/2013/11/26/introduction-to-solr-new-edition/","publishdate":"2013-11-26T12:27:00+09:00","readingtime":2,"relpermalink":"/blog/2013/11/26/introduction-to-solr-new-edition/","section":"post","summary":"勉強会で宣伝もしましたが、改めて。 Solr入門の改訂版を執筆しました。 考えてみれば、もう3年も前なんですね、Solr入門は。 Solr勉強会な","tags":["Solr"],"title":"改訂版Solr入門を執筆しました","type":"post","url":"/blog/2013/11/26/introduction-to-solr-new-edition/","weight":0,"wordcount":638},{"date":1384419300,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1384419300,"objectID":"13684d16fdd07d5f0584e29265a270e7","permalink":"https://blog.johtani.info/blog/2013/11/14/release-elasticsearch-extended-analyze-0-dot-5/","publishdate":"2013-11-14T17:55:00+09:00","readingtime":5,"relpermalink":"/blog/2013/11/14/release-elasticsearch-extended-analyze-0-dot-5/","section":"post","summary":"どーも。以前の記事で開発中としていたプラグインですが、とりあえず、pluginコマンドでインストール出来る形にしてみました。 インストールなど","tags":["elasticsearch","plugin"],"title":"elasticsearch-extended-analyzeを公開？","type":"post","url":"/blog/2013/11/14/release-elasticsearch-extended-analyze-0-dot-5/","weight":0,"wordcount":2368},{"date":1384247760,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1384247760,"objectID":"66f43ab4b823d67f52735bbbe6ba65b0","permalink":"https://blog.johtani.info/blog/2013/11/12/elasticsearch-japan-user-meetup-no2/","publishdate":"2013-11-12T18:16:00+09:00","readingtime":4,"relpermalink":"/blog/2013/11/12/elasticsearch-japan-user-meetup-no2/","section":"post","summary":"第2回を開催しました！ すごい、140人くらいくらいの参加登録者（参加者は１００人ちょっと！）がいて、びっくりです。 ステキな会場を提供していた","tags":["elasticsearch","kibana","fluentd","勉強会"],"title":"第2回elasticsearch勉強会を開催しました！ #elasticsearchjp","type":"post","url":"/blog/2013/11/12/elasticsearch-japan-user-meetup-no2/","weight":0,"wordcount":1717},{"date":1383786660,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1383786660,"objectID":"a106d7c1b1b277538367f9c8140e3a75","permalink":"https://blog.johtani.info/blog/2013/11/07/cloudera-world-tokyo-2013/","publishdate":"2013-11-07T10:11:00+09:00","readingtime":5,"relpermalink":"/blog/2013/11/07/cloudera-world-tokyo-2013/","section":"post","summary":"Cloudera World Tokyo 2013に参加してきました。 午前中はあいにくの雨でしたが、それでも結構な人数が最初の基調講演から参加されてました。 私が参加したセッショ","tags":["Cloudera","Hadoop","Norikra"],"title":"Cloudera World Tokyo 2013に参加しました！ #cwt2013 ","type":"post","url":"/blog/2013/11/07/cloudera-world-tokyo-2013/","weight":0,"wordcount":2455},{"date":1383746460,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1383746460,"objectID":"9dca844d353efed03fbaddfc0fab7c76","permalink":"https://blog.johtani.info/blog/2013/11/06/riak-meetup-tokyo-no3/","publishdate":"2013-11-06T23:01:00+09:00","readingtime":2,"relpermalink":"/blog/2013/11/06/riak-meetup-tokyo-no3/","section":"post","summary":"またまた、Riak Meetup Tokyo #3に参加してきました。Riak2.0のYokozunaの話があると聞いたので。 ということで、いつものように個人メモで","tags":["Riak","Yokozuna"],"title":"Riak Meetup #3 #riakjp に参加しました。","type":"post","url":"/blog/2013/11/06/riak-meetup-tokyo-no3/","weight":0,"wordcount":952},{"date":1383570720,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":600,"kind":"page","lang":"ja","lastmod":1383570720,"objectID":"b5c628b0c1dbf857a475c4be5de4690d","permalink":"https://blog.johtani.info/blog/2013/11/04/improve-output-extended-analyze/","publishdate":"2013-11-04T22:12:00+09:00","readingtime":2,"relpermalink":"/blog/2013/11/04/improve-output-extended-analyze/","section":"post","summary":"開発中ですと書きました、elasticsearch-extended-analyzeですが、改良しました。 改良と変更は以下のとおりです。 ソー","tags":["elasticsearch","plugin"],"title":"elasticsearch-extended-analyzeの改良","type":"post","url":"/blog/2013/11/04/improve-output-extended-analyze/","weight":0,"wordcount":536},{"date":1382695560,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1382695560,"objectID":"0302e8a57a5e8604342a925b2dc60737","permalink":"https://blog.johtani.info/blog/2013/10/25/developing-es-extended-analyze-plugin/","publishdate":"2013-10-25T19:06:00+09:00","readingtime":5,"relpermalink":"/blog/2013/10/25/developing-es-extended-analyze-plugin/","section":"post","summary":"お久しぶりです。 気づいたらまた、結構ブログを書いてなかったです。。。 今回は、今開発しているElasticsearchのプラグインに関するお話","tags":["elasticsearch","plugin"],"title":"elasticsearch-extended-analyzeプラグインを開発中","type":"post","url":"/blog/2013/10/25/developing-es-extended-analyze-plugin/","weight":0,"wordcount":2302},{"date":1381372500,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1900,"kind":"page","lang":"ja","lastmod":1381372500,"objectID":"76e127a44931bfefab991be3dd7a08b7","permalink":"https://blog.johtani.info/blog/2013/10/10/solr-meetup-memo/","publishdate":"2013-10-10T11:35:00+09:00","readingtime":4,"relpermalink":"/blog/2013/10/10/solr-meetup-memo/","section":"post","summary":"不定期開催ですが第12回Solr勉強会を主催しました。 今回は、前回ほどの過熱ぶりでは無かったですが、70人ほどの参加者の方がいらっしゃったか","tags":["Solr","Riak","Yokozuna","ManifoldCF"],"title":"第12回Solr勉強会を主催しました。#SolrJP","type":"post","url":"/blog/2013/10/10/solr-meetup-memo/","weight":0,"wordcount":1842},{"date":1379906820,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1379906820,"objectID":"e1870dde155be1a375f155dd1f7ead13","permalink":"https://blog.johtani.info/blog/2013/09/23/intro-elasticsearch-inquisitor/","publishdate":"2013-09-23T12:27:00+09:00","readingtime":6,"relpermalink":"/blog/2013/09/23/intro-elasticsearch-inquisitor/","section":"post","summary":"今日は、ElasticSearchのMLで見つけたelasticsearch-inquisitorプラグインの紹介です。 ElasticSea","tags":["elasticsearch","plugin"],"title":"elasticsearch-inquisitorプラグインの紹介","type":"post","url":"/blog/2013/09/23/intro-elasticsearch-inquisitor/","weight":0,"wordcount":2694},{"date":1378921080,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1378921080,"objectID":"d2e805472f79f0b558f75b90b5e7b4ee","permalink":"https://blog.johtani.info/blog/2013/09/12/question-river-wikipedia/","publishdate":"2013-09-12T02:38:00+09:00","readingtime":6,"relpermalink":"/blog/2013/09/12/question-river-wikipedia/","section":"post","summary":"river-wikipediaの前々回の記事で書きましたが、bulk_sizeに関連して登録件数がやけにきりが良いのが気になると書いていまし","tags":["elasticsearch","wikipedia"],"title":"elasticsearch-river-wikipediaの疑問点","type":"post","url":"/blog/2013/09/12/question-river-wikipedia/","weight":0,"wordcount":2628},{"date":1378138500,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1378138500,"objectID":"79e647a3f8b36a1221897f5837c84aff","permalink":"https://blog.johtani.info/blog/2013/09/03/ja-wikipedia-with-kuromoji/","publishdate":"2013-09-03T01:15:00+09:00","readingtime":3,"relpermalink":"/blog/2013/09/03/ja-wikipedia-with-kuromoji/","section":"post","summary":"前々回紹介した、日本語Wikipediaのデータをインデックス登録する記事の続きです。 今回は、Kuromojiのアナライザを利用してインデッ","tags":["elasticsearch","kuromoji","wikipedia"],"title":"日本語Wikipediaをインデクシング（Kuromojiバージョン）","type":"post","url":"/blog/2013/09/03/ja-wikipedia-with-kuromoji/","weight":0,"wordcount":1323},{"date":1377798120,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1377798120,"objectID":"5931f8e3acdac724742c4ee0960d8d40","permalink":"https://blog.johtani.info/blog/2013/08/30/hold-first-elasticsearch-meetup-in-japan/","publishdate":"2013-08-30T02:42:00+09:00","readingtime":5,"relpermalink":"/blog/2013/08/30/hold-first-elasticsearch-meetup-in-japan/","section":"post","summary":"ElasticSearch勉強会 第1回を主催しました。 昨年のpyfesでなんちゃって資料で喋って、1年たちました。 ElasticSearch","tags":["elasticsearch","勉強会"],"title":"第1回ElasticSearch勉強会を開催しました！ #elasticsearchjp","type":"post","url":"/blog/2013/08/30/hold-first-elasticsearch-meetup-in-japan/","weight":0,"wordcount":2451},{"date":1377226920,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1377226920,"objectID":"3931327ed463d1568868c5ab8e839148","permalink":"https://blog.johtani.info/blog/2013/08/23/index-wikipedia-ja-to-elasticsearch/","publishdate":"2013-08-23T12:02:00+09:00","readingtime":6,"relpermalink":"/blog/2013/08/23/index-wikipedia-ja-to-elasticsearch/","section":"post","summary":"久々のブログはElasticSearchネタです。勉強会開催する予定だったりすので、もう少し触っておきたいなと。 お手軽に検索するデータとして","tags":["elasticsearch","wikipedia"],"title":"ElasticSearchにプラグインで日本語Wikipediaデータを入れてみました","type":"post","url":"/blog/2013/08/23/index-wikipedia-ja-to-elasticsearch/","weight":0,"wordcount":2705},{"date":1375434120,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1900,"kind":"page","lang":"ja","lastmod":1375434120,"objectID":"33e01e2271be22b5ed330045fe6aff50","permalink":"https://blog.johtani.info/blog/2013/08/02/morphlines-loadsolr/","publishdate":"2013-08-02T18:02:00+09:00","readingtime":4,"relpermalink":"/blog/2013/08/02/morphlines-loadsolr/","section":"post","summary":"宿題その2？かな。Solr勉強会でCloudera Searchのスキーマ周りってどうなってるの？という質問が出てて、 なんか調べることになって","tags":["Cloudera Search","Morphlines","Solr"],"title":"MorphlinesのloadSolrをちょっとだけ調べてみた","type":"post","url":"/blog/2013/08/02/morphlines-loadsolr/","weight":0,"wordcount":1850},{"date":1375364280,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1375364280,"objectID":"cd9ba1f582642d9cbe500f018afab341","permalink":"https://blog.johtani.info/blog/2013/08/01/replace-xperia-z/","publishdate":"2013-08-01T22:38:00+09:00","readingtime":3,"relpermalink":"/blog/2013/08/01/replace-xperia-z/","section":"post","summary":"今朝起きたら、Xperia Zが故障してしまいました。 電源ボタンを押してもスリープにならないんです。しかも、スリープからの復帰もできない。。。","tags":["Xperia Z"],"title":"Xperia Zが故障したので交換したのでメモ","type":"post","url":"/blog/2013/08/01/replace-xperia-z/","weight":0,"wordcount":1431},{"date":1375265520,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1900,"kind":"page","lang":"ja","lastmod":1375265520,"objectID":"b875f24d3d444fdda82b6bbfb75a4c92","permalink":"https://blog.johtani.info/blog/2013/07/31/introduction-morphlines/","publishdate":"2013-07-31T19:12:00+09:00","readingtime":4,"relpermalink":"/blog/2013/07/31/introduction-morphlines/","section":"post","summary":"Morphlinesについてちょっとだけ、さらに調べました。 誤解 Solr勉強会でなんとなく私の認識を話しましたが、ちょっと誤解してたみたいで","tags":["Cloudera Search","Morphlines","Solr"],"title":"Morphlines入門？","type":"post","url":"/blog/2013/07/31/introduction-morphlines/","weight":0,"wordcount":1888},{"date":1375107300,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1375107300,"objectID":"59d1b7206e7664e76672d3de4dc9a8ed","permalink":"https://blog.johtani.info/blog/2013/07/29/study-of-solr/","publishdate":"2013-07-29T23:15:00+09:00","readingtime":6,"relpermalink":"/blog/2013/07/29/study-of-solr/","section":"post","summary":"不定期開催ですが第11回Solr勉強会を主催しました。 今回も大入り90人くらい？の参加者の皆さんがいらっしゃいました。ありがたいことです！（","tags":["Solr","Cloudera Search","ManifoldCF"],"title":"第11回Solr勉強会を主催しました。#SolrJP","type":"post","url":"/blog/2013/07/29/study-of-solr/","weight":0,"wordcount":2518},{"date":1374685860,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1374685860,"objectID":"1b9c5ae60ec46be64a1877f0c6920edc","permalink":"https://blog.johtani.info/blog/2013/07/25/hadoop-hive-publication-party/","publishdate":"2013-07-25T02:11:00+09:00","readingtime":3,"relpermalink":"/blog/2013/07/25/hadoop-hive-publication-party/","section":"post","summary":"Hadoopとか離れちゃってるし、Hive触ったこと無いにもかかわらず参加しました！ （たまたま近くにいるからって理由なのは内緒で） 玉川さんの","tags":["Hadoop","Hive","Cloudera","オライリー"],"title":"『プログラミング Hive』 『Hadoop 第3版』刊行記念セミナーに参加しました！ #oreilly0724","type":"post","url":"/blog/2013/07/25/hadoop-hive-publication-party/","weight":0,"wordcount":1016},{"date":1373474580,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":600,"kind":"page","lang":"ja","lastmod":1373474580,"objectID":"50557b455cba1a3ce9b4555fc3fd5433","permalink":"https://blog.johtani.info/blog/2013/07/11/yokozuna-check-point/","publishdate":"2013-07-11T01:43:00+09:00","readingtime":2,"relpermalink":"/blog/2013/07/11/yokozuna-check-point/","section":"post","summary":"Yokozunaの気になる点というか、自分だったらこのへん調べるだろうなって観点を上げてみます。 別に調べるわけじゃないので、完全に自己満足な","tags":["Riak","Solr","Yokozuna"],"title":"Yokozunaの気になる点というかなんというか","type":"post","url":"/blog/2013/07/11/yokozuna-check-point/","weight":0,"wordcount":505},{"date":1373450220,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2100,"kind":"page","lang":"ja","lastmod":1373450220,"objectID":"146e8ca40c0d37f36eecea822028dd9e","permalink":"https://blog.johtani.info/blog/2013/07/10/riak-meetup-tokyo-no2/","publishdate":"2013-07-10T18:57:00+09:00","readingtime":4,"relpermalink":"/blog/2013/07/10/riak-meetup-tokyo-no2/","section":"post","summary":"先日、Bashoさんにおじゃましたのもあり、Riak Meetup Tokyo #2に参加しました。 Yokozunaの話も聞けるということで。 懇親会も参加しました。","tags":["Riak","Yokozuna","Solr"],"title":"Riak Meetup Tokyo #2に参加しました。#riakjp","type":"post","url":"/blog/2013/07/10/riak-meetup-tokyo-no2/","weight":0,"wordcount":2002},{"date":1372867920,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2900,"kind":"page","lang":"ja","lastmod":1372867920,"objectID":"a98d42be181c01b8077e060b1b5080ec","permalink":"https://blog.johtani.info/blog/2013/07/04/schemaless-example/","publishdate":"2013-07-04T01:12:00+09:00","readingtime":6,"relpermalink":"/blog/2013/07/04/schemaless-example/","section":"post","summary":"Solr 4.4に取り込まれる予定のチケットで、気になるものを見つけたのでいつものごとく調べてみました。 元となるチケットはこちら。SOLR-4897","tags":["Solr"],"title":"スキーマレスモード？（SOLR-4897）を調べて見ました。","type":"post","url":"/blog/2013/07/04/schemaless-example/","weight":0,"wordcount":2854},{"date":1372318080,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1372318080,"objectID":"ecf3ac80454654d990d9c07d33d35d1c","permalink":"https://blog.johtani.info/blog/2013/06/27/upload-docs-solr-admin/","publishdate":"2013-06-27T16:28:00+09:00","readingtime":3,"relpermalink":"/blog/2013/06/27/upload-docs-solr-admin/","section":"post","summary":"SolrのチケットをML経由で眺めてるんですが、便利そうなチケットが流れてきたのでブログを書いてみみようかと。 元になってるチケットはこちらで","tags":["Solr"],"title":"Solrの管理画面でデータ登録","type":"post","url":"/blog/2013/06/27/upload-docs-solr-admin/","weight":0,"wordcount":1461},{"date":1371652980,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":4100,"kind":"page","lang":"ja","lastmod":1371652980,"objectID":"26c47355cbe966a94826cbe2fbf2b355","permalink":"https://blog.johtani.info/blog/2013/06/19/introduction-kibana3/","publishdate":"2013-06-19T23:43:00+09:00","readingtime":9,"relpermalink":"/blog/2013/06/19/introduction-kibana3/","section":"post","summary":"前回は3番煎じぐらいでしたが、今回は初記事かな？（だといいな） Kibanaには、前回の記事で書いたものとは別に開発中のKibana3というの","tags":["elasticsearch","kibana"],"title":"Kibana3というのもありまして","type":"post","url":"/blog/2013/06/19/introduction-kibana3/","weight":0,"wordcount":4039},{"date":1371603780,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1371603780,"objectID":"33919e866426ce8e7b2ce06f19bbf889","permalink":"https://blog.johtani.info/blog/2013/06/19/visited-basho/","publishdate":"2013-06-19T10:03:00+09:00","readingtime":2,"relpermalink":"/blog/2013/06/19/visited-basho/","section":"post","summary":"ちょくちょく書こうと言いながら、前の記事が1週間以上前になってる。。。 昨日は、Basho Japanに遊びに行って来ました。 （Riak触ったこ","tags":["Riak","Basho","Yokozuna","Solr"],"title":"Basho Japanに遊びに行きました","type":"post","url":"/blog/2013/06/19/visited-basho/","weight":0,"wordcount":987},{"date":1370945460,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1200,"kind":"page","lang":"ja","lastmod":1370945460,"objectID":"78292d953eafbdf9e57cc4bbbe6e8964","permalink":"https://blog.johtani.info/blog/2013/06/11/new-solr-xml/","publishdate":"2013-06-11T19:11:00+09:00","readingtime":3,"relpermalink":"/blog/2013/06/11/new-solr-xml/","section":"post","summary":"Lucene/Solr 4.3.1のRCのVoteが始まっていますが、そのMLできになったコトがあり、ちょっと調べたので メモを残しておきます。 マルチコアの設定ファ","tags":["Solr"],"title":"新しいsolr.xmlとCore探索ロジック","type":"post","url":"/blog/2013/06/11/new-solr-xml/","weight":0,"wordcount":1168},{"date":1370874840,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1370874840,"objectID":"c4d3a917f623f58646ce93015d79e8e0","permalink":"https://blog.johtani.info/blog/2013/06/10/fluent-es-kibana/","publishdate":"2013-06-10T23:34:00+09:00","readingtime":6,"relpermalink":"/blog/2013/06/10/fluent-es-kibana/","section":"post","summary":"もう何番煎じだ？ってくらい書かれてますが、コリもせず書いてみました。 Elasticsearch＋Kibanaの環境を作って、タムタムさんのロ","tags":["kibana","elasticsearch","fluentd"],"title":"apache-loggen + fluentd + elasticsearch + kibana = ログ検索デモ","type":"post","url":"/blog/2013/06/10/fluent-es-kibana/","weight":0,"wordcount":2777},{"date":1370527200,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1370527200,"objectID":"d12c1c2a68be4c7fda5a7737d5493b4d","permalink":"https://blog.johtani.info/blog/2013/06/06/aws-summit-tokyo-day2/","publishdate":"2013-06-06T23:00:00+09:00","readingtime":6,"relpermalink":"/blog/2013/06/06/aws-summit-tokyo-day2/","section":"post","summary":"昨日に引き続き、AWS Summit Tokyo 2013に行ってきました。 @ryu_kobayashiさんからパシリを仰せつかるなどあり、忙しかったのですが楽しか","tags":["AWS","勉強会"],"title":"AWS Summit Tokyo 2013に行って来ました。(Day2) #awssummit","type":"post","url":"/blog/2013/06/06/aws-summit-tokyo-day2/","weight":0,"wordcount":2717},{"date":1370489160,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1370489160,"objectID":"f45069216cd934b80ce882c9a2f2a08a","permalink":"https://blog.johtani.info/blog/2013/06/06/cloudera-search-memo2/","publishdate":"2013-06-06T12:26:00+09:00","readingtime":3,"relpermalink":"/blog/2013/06/06/cloudera-search-memo2/","section":"post","summary":"ざっとインストールガイドとかCloudera Searchのソース眺めて、テキトーにメモを書いてみました。 （ユーザガイドはまだ読んでないです。","tags":["Cloudera Search","Hadoop","Solr"],"title":"Cloudera Searchメモ（妄想版）","type":"post","url":"/blog/2013/06/06/cloudera-search-memo2/","weight":0,"wordcount":1419},{"date":1370424600,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1370424600,"objectID":"1fe14e2e02b6e65e6e6e2ae3d8ddcc9f","permalink":"https://blog.johtani.info/blog/2013/06/05/aws-summit-tokyo-day1/","publishdate":"2013-06-05T18:30:00+09:00","readingtime":5,"relpermalink":"/blog/2013/06/05/aws-summit-tokyo-day1/","section":"post","summary":"AWS Summit Tokyo 2013に行って来ました。 @cocoatomoさんに行き掛けに出会ったので、アンデルセンの講演を一緒に聞いてました。 TDブースの@ry","tags":["勉強会","AWS"],"title":"AWS Summit Tokyo 2013に行って来ました。(Day1) #awssummit","type":"post","url":"/blog/2013/06/05/aws-summit-tokyo-day1/","weight":0,"wordcount":2453},{"date":1370412720,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1370412720,"objectID":"e30258aeb8475d4c27f7935945671856","permalink":"https://blog.johtani.info/blog/2013/06/05/cloudera-search-modules/","publishdate":"2013-06-05T15:12:00+09:00","readingtime":3,"relpermalink":"/blog/2013/06/05/cloudera-search-modules/","section":"post","summary":"Cloudera Searchは次のようなモジュールから構成されています。 これはCloudera Searchのモジュールで、さらにこれらがSolrとかを使っ","tags":["Cloudera","Hadoop","Solr","Cloudera Search"],"title":"Cloudera Searchのモジュールたち","type":"post","url":"/blog/2013/06/05/cloudera-search-modules/","weight":0,"wordcount":1467},{"date":1370412300,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1370412300,"objectID":"cd90bce912f5743226af94c1efaaa4a7","permalink":"https://blog.johtani.info/blog/2013/06/05/what-is-cloudera-search/","publishdate":"2013-06-05T15:05:00+09:00","readingtime":2,"relpermalink":"/blog/2013/06/05/what-is-cloudera-search/","section":"post","summary":"AWS Summitに来ていたのですが、TLでは、Cloudera Searchが賑わってました。 ということで、軽くどんなものか読んだり調べたりした","tags":["Cloudera","Hadoop","Solr","Cloudera Search"],"title":"Cloudera Searchってのが出たらしい（とりあえず、雑感？）","type":"post","url":"/blog/2013/06/05/what-is-cloudera-search/","weight":0,"wordcount":898},{"date":1370234580,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2100,"kind":"page","lang":"ja","lastmod":1370234580,"objectID":"494557db52824555864d1106278cd1f0","permalink":"https://blog.johtani.info/blog/2013/06/03/fluent-plugin-zoomdata-0-0-1/","publishdate":"2013-06-03T13:43:00+09:00","readingtime":5,"relpermalink":"/blog/2013/06/03/fluent-plugin-zoomdata-0-0-1/","section":"post","summary":"憧れ？のfluentを使ってみました。 こちらの記事で紹介したZoomdataを最近触っているのですが、お試しにfluentdでデータ流し込む","tags":["Zoomdata","fluentd"],"title":"fluent-plugin-zoomdata作りました＋悩み事とか","type":"post","url":"/blog/2013/06/03/fluent-plugin-zoomdata-0-0-1/","weight":0,"wordcount":2063},{"date":1370228038,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":400,"kind":"page","lang":"ja","lastmod":1370228038,"objectID":"16f10764f0ccce42d5be8cfeac36b446","permalink":"https://blog.johtani.info/blog/2013/06/03/octopress%E3%82%92%E8%A9%A6%E3%81%97%E4%B8%AD/","publishdate":"2013-06-03T11:53:58+09:00","readingtime":1,"relpermalink":"/blog/2013/06/03/octopress%E3%82%92%E8%A9%A6%E3%81%97%E4%B8%AD/","section":"post","summary":"最近、Markdownで文章を書くのに慣れてきました。 ということで、ブログをMarkdownで書けないかなぁと思い、TLの人たちのブログを見","tags":["misc"],"title":"Octopressを試し中(Jugemより移植)","type":"post","url":"/blog/2013/06/03/octopress%E3%82%92%E8%A9%A6%E3%81%97%E4%B8%AD/","weight":0,"wordcount":361},{"date":1370098620,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":400,"kind":"page","lang":"ja","lastmod":1370098620,"objectID":"dbcc4002c15afefef853a08a0804ba3a","permalink":"https://blog.johtani.info/blog/2013/06/01/first-octopress/","publishdate":"2013-06-01T23:57:00+09:00","readingtime":1,"relpermalink":"/blog/2013/06/01/first-octopress/","section":"post","summary":"昨年から、ブログをどうしようかって話をしていて、そのままになっていたのですが、Octopress＋Github Pagesというのがあるらしい","tags":["octopress","misc"],"title":"Octopress始めました","type":"post","url":"/blog/2013/06/01/first-octopress/","weight":0,"wordcount":356},{"date":1367850324,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":500,"kind":"page","lang":"ja","lastmod":1367850324,"objectID":"11d4726484be418849e1f4200ade9535","permalink":"https://blog.johtani.info/blog/2013/05/06/lucene-gosen4-3-0%E3%82%92%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Flucene-solr4-3-0%E4%BB%A5%E4%B8%8A%E3%81%A7%E3%81%AE%E5%88%A9%E7%94%A8%E3%81%8C%E5%8F%AF%E8%83%BD%E3%81%A7%E3%81%99/","publishdate":"2013-05-06T23:25:24+09:00","readingtime":1,"relpermalink":"/blog/2013/05/06/lucene-gosen4-3-0%E3%82%92%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Flucene-solr4-3-0%E4%BB%A5%E4%B8%8A%E3%81%A7%E3%81%AE%E5%88%A9%E7%94%A8%E3%81%8C%E5%8F%AF%E8%83%BD%E3%81%A7%E3%81%99/","section":"post","summary":"Lucene/Solr 4.3.0がリリースされた（LuceneのChanges、SolrのChanges）ので、lucene-gosen 4.3.0をリリースしま","tags":["lucene-gosen"],"title":"lucene-gosen4.3.0をリリースしました。（Lucene/Solr4.3.0以上での利用が可能です）(Jugemより移植)","type":"post","url":"/blog/2013/05/06/lucene-gosen4-3-0%E3%82%92%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Flucene-solr4-3-0%E4%BB%A5%E4%B8%8A%E3%81%A7%E3%81%AE%E5%88%A9%E7%94%A8%E3%81%8C%E5%8F%AF%E8%83%BD%E3%81%A7%E3%81%99/","weight":0,"wordcount":484},{"date":1367592139,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1367592139,"objectID":"db97311c24809f103575d8a7fee19680","permalink":"https://blog.johtani.info/blog/2013/05/03/%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E5%9B%9E%E3%81%97%E3%81%A6%E3%81%BE%E3%81%99%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF%E5%85%A5%E9%96%80%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2013-05-03T23:42:19+09:00","readingtime":6,"relpermalink":"/blog/2013/05/03/%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E5%9B%9E%E3%81%97%E3%81%A6%E3%81%BE%E3%81%99%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF%E5%85%A5%E9%96%80%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"アジャイルな時間管理術 ポモドーロテクニック入門 ポモドーロテクニック入門という本を読みました。 きっかけは、Twitter上で何度か「ポモドーロ","tags":["読書"],"title":"ポモドーロ回してます。（ポモドーロテクニック入門読みました）(Jugemより移植)","type":"post","url":"/blog/2013/05/03/%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E5%9B%9E%E3%81%97%E3%81%A6%E3%81%BE%E3%81%99%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF%E5%85%A5%E9%96%80%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":2600},{"date":1366856040,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":3100,"kind":"page","lang":"ja","lastmod":1366856040,"objectID":"286a9a4ee373398d7d2c93862c5f6661","permalink":"https://blog.johtani.info/blog/2013/04/25/solr4-3-0%E3%81%AEchanges%E3%82%92%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/","publishdate":"2013-04-25T11:14:00+09:00","readingtime":7,"relpermalink":"/blog/2013/04/25/solr4-3-0%E3%81%AEchanges%E3%82%92%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/","section":"post","summary":"まだ、Vote公開されていない、Solr 4.3（2013/04/25 11:00現在）ですが、 ひさびさに訳してみた。詳細まで追っていないので、","tags":["solr"],"title":"Solr4.3.0のChangesを訳してみた。(Jugemより移植)","type":"post","url":"/blog/2013/04/25/solr4-3-0%E3%81%AEchanges%E3%82%92%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/","weight":0,"wordcount":3038},{"date":1366786800,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1366786800,"objectID":"99f5219da22485d0872a2529599c8440","permalink":"https://blog.johtani.info/blog/2013/04/24/lucene-4-3-0%E3%81%AEchanges%E3%81%AB%E3%81%82%E3%82%8Bchanges-in-backwards-compatibility-policy%E3%81%8C%E6%B0%97%E3%81%AB%E3%81%AA%E3%81%A3%E3%81%9F%E3%81%AE%E3%81%A7%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/","publishdate":"2013-04-24T16:00:00+09:00","readingtime":3,"relpermalink":"/blog/2013/04/24/lucene-4-3-0%E3%81%AEchanges%E3%81%AB%E3%81%82%E3%82%8Bchanges-in-backwards-compatibility-policy%E3%81%8C%E6%B0%97%E3%81%AB%E3%81%AA%E3%81%A3%E3%81%9F%E3%81%AE%E3%81%A7%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/","section":"post","summary":"現在、RC3のVoteをやっている最中（2013/04/24 16:00時点）で、まだリリースされていない、4.3.0についてです。 開発者ML","tags":["solr"],"title":"Lucene 4.3.0のChangesにあるChanges in backwards compatibility policyが気になったので訳してみた。(Jugemより移植)","type":"post","url":"/blog/2013/04/24/lucene-4-3-0%E3%81%AEchanges%E3%81%AB%E3%81%82%E3%82%8Bchanges-in-backwards-compatibility-policy%E3%81%8C%E6%B0%97%E3%81%AB%E3%81%AA%E3%81%A3%E3%81%9F%E3%81%AE%E3%81%A7%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/","weight":0,"wordcount":1286},{"date":1366717542,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1366717542,"objectID":"36ff37ced0d3211db95a5ac0daac0c35","permalink":"https://blog.johtani.info/blog/2013/04/23/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass--tecomp--vol-2-%E4%BA%BA%E6%B0%97web%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9%E6%95%99%E3%81%88%E3%81%BE%E3%81%99%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2013-04-23T20:45:42+09:00","readingtime":3,"relpermalink":"/blog/2013/04/23/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass--tecomp--vol-2-%E4%BA%BA%E6%B0%97web%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9%E6%95%99%E3%81%88%E3%81%BE%E3%81%99%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"第2回目も参加しました。 とりあえずメモ。 自分には欠けてる視点の話しなので面白かった。 ちょっと寒かったなぁ。 エンジニアのためのスキルアップ勉強","tags":["勉強会"],"title":"エンジニアのためのスキルアップ勉強会『Tech Compass』 #tecomp ― Vol.2 「人気Webサービスの作り方教えます！」に参加しました。(Jugemより移植)","type":"post","url":"/blog/2013/04/23/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass--tecomp--vol-2-%E4%BA%BA%E6%B0%97web%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9%E6%95%99%E3%81%88%E3%81%BE%E3%81%99%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":1439},{"date":1366639648,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2100,"kind":"page","lang":"ja","lastmod":1366639648,"objectID":"1ca04e5339ed1826c12fe61fd984e949","permalink":"https://blog.johtani.info/blog/2013/04/22/jira%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E3%82%92s3%E3%81%B8%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97/","publishdate":"2013-04-22T23:07:28+09:00","readingtime":5,"relpermalink":"/blog/2013/04/22/jira%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E3%82%92s3%E3%81%B8%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97/","section":"post","summary":"だいぶ、ブログを書くペースが落ちてきてて、危機感を感じている今日このごろです。。。 今回は、個人的に利用しているJIRAのバックアップについて","tags":["備忘録"],"title":"JIRAのデータをS3へバックアップ(Jugemより移植)","type":"post","url":"/blog/2013/04/22/jira%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E3%82%92s3%E3%81%B8%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97/","weight":0,"wordcount":2096},{"date":1365128443,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2100,"kind":"page","lang":"ja","lastmod":1365128443,"objectID":"73d2fce4efa52675b35a11ee97bc2db0","permalink":"https://blog.johtani.info/blog/2013/04/05/heroku-meetup--8-treasuredata--waza-report-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/","publishdate":"2013-04-05T11:20:43+09:00","readingtime":5,"relpermalink":"/blog/2013/04/05/heroku-meetup--8-treasuredata--waza-report-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/","section":"post","summary":"HerokuではじめるRailsプログラミング入門 heroku気になってるのに使ってなくて、TDのアカウント作ってデータアップしてない軟弱者","tags":["勉強会"],"title":"Heroku Meetup #8 TreasureData + Waza Report!! に参加しました。#herokujp(Jugemより移植)","type":"post","url":"/blog/2013/04/05/heroku-meetup--8-treasuredata--waza-report-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/","weight":0,"wordcount":2020},{"date":1364300160,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":5000,"kind":"page","lang":"ja","lastmod":1364300160,"objectID":"26d0c0d8c465087cf160a3bdc479f2b4","permalink":"https://blog.johtani.info/blog/2013/03/26/%E7%AC%AC10%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/","publishdate":"2013-03-26T21:16:00+09:00","readingtime":10,"relpermalink":"/blog/2013/03/26/%E7%AC%AC10%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/","section":"post","summary":"記念すべき！？第10回のSolr勉強会です。 発表者が無事あつまり（本当にありがとうございました！）、今回も盛況な感じでほぼ満員でした。 ツイー","tags":["勉強会"],"title":"第10回Solr勉強会を主催しました。#SolrJP(Jugemより移植)","type":"post","url":"/blog/2013/03/26/%E7%AC%AC10%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/","weight":0,"wordcount":4937},{"date":1363765380,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1363765380,"objectID":"f5f28f42ad234b4389af4cbea54ff60d","permalink":"https://blog.johtani.info/blog/2013/03/20/elasticsearch-analysis-kuromoji%E3%81%A7%E3%83%A6%E3%83%BC%E3%82%B6%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%88%A9%E7%94%A8%E6%96%B9%E6%B3%95/","publishdate":"2013-03-20T16:43:00+09:00","readingtime":3,"relpermalink":"/blog/2013/03/20/elasticsearch-analysis-kuromoji%E3%81%A7%E3%83%A6%E3%83%BC%E3%82%B6%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%88%A9%E7%94%A8%E6%96%B9%E6%B3%95/","section":"post","summary":"なんか、とても久しぶりにイベント参加メモ以外の投稿です。 elastic searchのMLを見てたら、KuromojiのAnalyzerを使うときにユーザ","tags":["elasticsearch"],"title":"elasticsearch-analysis-kuromojiでユーザ辞書の利用方法(Jugemより移植)","type":"post","url":"/blog/2013/03/20/elasticsearch-analysis-kuromoji%E3%81%A7%E3%83%A6%E3%83%BC%E3%82%B6%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%88%A9%E7%94%A8%E6%96%B9%E6%B3%95/","weight":0,"wordcount":1211},{"date":1363692480,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1363692480,"objectID":"5412fb82160d0f6093e4b6670f505c13","permalink":"https://blog.johtani.info/blog/2013/03/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass%E7%AB%B9%E6%A9%8B--vol1-%E3%82%B9%E3%83%9E%E3%83%9B%E6%99%82%E4%BB%A3%E5%88%B0%E6%9D%A5%E3%81%93%E3%81%AE%E5%85%88%E7%94%9F%E3%81%8D%E3%81%AE%E3%81%93%E3%82%8B%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%A8%E3%81%AF%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-tecomp/","publishdate":"2013-03-19T20:28:00+09:00","readingtime":3,"relpermalink":"/blog/2013/03/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass%E7%AB%B9%E6%A9%8B--vol1-%E3%82%B9%E3%83%9E%E3%83%9B%E6%99%82%E4%BB%A3%E5%88%B0%E6%9D%A5%E3%81%93%E3%81%AE%E5%85%88%E7%94%9F%E3%81%8D%E3%81%AE%E3%81%93%E3%82%8B%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%A8%E3%81%AF%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-tecomp/","section":"post","summary":"久々にブログ＋イベント参加です。 知り合いが開催＋出演したので参加してみました。 「スマホ」ってキーワードはあまりなかったけど、面白かったです。","tags":["勉強会"],"title":"エンジニアのためのスキルアップ勉強会『Tech Compass』＠竹橋 ― Vol1 「スマホ時代到来、この先生きのこるエンジニアとは！？」に参加しました。#tecomp(Jugemより移植)","type":"post","url":"/blog/2013/03/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass%E7%AB%B9%E6%A9%8B--vol1-%E3%82%B9%E3%83%9E%E3%83%9B%E6%99%82%E4%BB%A3%E5%88%B0%E6%9D%A5%E3%81%93%E3%81%AE%E5%85%88%E7%94%9F%E3%81%8D%E3%81%AE%E3%81%93%E3%82%8B%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%A8%E3%81%AF%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-tecomp/","weight":0,"wordcount":1412},{"date":1360687980,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1360687980,"objectID":"b051fd352847c06e748b345e8ed0738b","permalink":"https://blog.johtani.info/blog/2013/02/13/xperia-z%E8%B2%B7%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2013-02-13T01:53:00+09:00","readingtime":4,"relpermalink":"/blog/2013/02/13/xperia-z%E8%B2%B7%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"技術ブログから離れていってますが。。。 Xperia Zを購入しました。 前に使っていたのはXperia arcになります。 もうすぐ２年だったのですが、容量不","tags":["備忘録"],"title":"Xperia Z買いました(Jugemより移植)","type":"post","url":"/blog/2013/02/13/xperia-z%E8%B2%B7%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":1712},{"date":1358783400,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":4000,"kind":"page","lang":"ja","lastmod":1358783400,"objectID":"bf4f86812812dab8d39db9aaefe94a78","permalink":"https://blog.johtani.info/blog/2013/01/22/hadoop-conference-japan-2013-winter%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hcj13w/","publishdate":"2013-01-22T00:50:00+09:00","readingtime":8,"relpermalink":"/blog/2013/01/22/hadoop-conference-japan-2013-winter%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hcj13w/","section":"post","summary":"金曜日に引き続き、イベントに参加して来ました。（仕事。。。これも仕事だよ。） 「Hadoop Conference Japan 2013 Winter」です。 普段、Hadoopを触る","tags":["勉強会"],"title":"Hadoop Conference Japan 2013 Winterに参加しました。#hcj13w(Jugemより移植)","type":"post","url":"/blog/2013/01/22/hadoop-conference-japan-2013-winter%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hcj13w/","weight":0,"wordcount":3960},{"date":1358600940,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1358600940,"objectID":"322264a17ef7182eb1475bd2eaebc2eb","permalink":"https://blog.johtani.info/blog/2013/01/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88cross-2013%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%8A%E6%89%8B%E4%BC%9D%E3%81%84%E3%83%A2%E3%83%87%E3%83%AC%E3%83%BC%E3%82%BF%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--cross2013/","publishdate":"2013-01-19T22:09:00+09:00","readingtime":6,"relpermalink":"/blog/2013/01/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88cross-2013%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%8A%E6%89%8B%E4%BC%9D%E3%81%84%E3%83%A2%E3%83%87%E3%83%AC%E3%83%BC%E3%82%BF%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--cross2013/","section":"post","summary":"1/18（金）に開催された、エンジニアサポートCROSS 2013で「検索CROSS」セッションのセッションオーナー（モデレータ）をやって来ま","tags":["勉強会"],"title":"エンジニアサポートCROSS 2013に参加（＋お手伝い＋モデレータ）しました #cross2013(Jugemより移植)","type":"post","url":"/blog/2013/01/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88cross-2013%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%8A%E6%89%8B%E4%BC%9D%E3%81%84%E3%83%A2%E3%83%87%E3%83%AC%E3%83%BC%E3%82%BF%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--cross2013/","weight":0,"wordcount":2560},{"date":1358267340,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":500,"kind":"page","lang":"ja","lastmod":1358267340,"objectID":"20110c8f8da8304b6d9d3c2845a38128","permalink":"https://blog.johtani.info/blog/2013/01/16/%E3%81%84%E3%81%BE%E3%81%95%E3%82%89%E3%81%A7%E3%81%99%E3%81%8Ccross-2013%E3%81%A7%E6%A4%9C%E7%B4%A2cross%E3%81%A8%E3%81%84%E3%81%86%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E6%8B%85%E5%BD%93%E3%81%97%E3%81%BE%E3%81%99/","publishdate":"2013-01-16T01:29:00+09:00","readingtime":1,"relpermalink":"/blog/2013/01/16/%E3%81%84%E3%81%BE%E3%81%95%E3%82%89%E3%81%A7%E3%81%99%E3%81%8Ccross-2013%E3%81%A7%E6%A4%9C%E7%B4%A2cross%E3%81%A8%E3%81%84%E3%81%86%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E6%8B%85%E5%BD%93%E3%81%97%E3%81%BE%E3%81%99/","section":"post","summary":"いまさら感満載ですが、今週の金曜日(1/18)に開催されるCROSS 2013というイベントで「検索CROSS」のセッションを担当することにな","tags":["勉強会"],"title":"いまさらですが、CROSS 2013で検索CROSSというセッションを担当します(Jugemより移植)","type":"post","url":"/blog/2013/01/16/%E3%81%84%E3%81%BE%E3%81%95%E3%82%89%E3%81%A7%E3%81%99%E3%81%8Ccross-2013%E3%81%A7%E6%A4%9C%E7%B4%A2cross%E3%81%A8%E3%81%84%E3%81%86%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E6%8B%85%E5%BD%93%E3%81%97%E3%81%BE%E3%81%99/","weight":0,"wordcount":436},{"date":1357658880,"dir":"post/2013/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1357658880,"objectID":"992a00c30242b6217243f3c387ea18b7","permalink":"https://blog.johtani.info/blog/2013/01/09/%E3%82%B3%E3%83%BC%E3%83%89%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AA%E3%82%B7%E3%83%86%E3%82%A3%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9Fkindle-paperwhite%E3%81%AE%E4%BD%BF%E3%81%84%E5%8B%9D%E6%89%8B%E3%81%AE%E7%A2%BA%E8%AA%8D%E3%82%82%E5%85%BC%E3%81%AD%E3%81%A6/","publishdate":"2013-01-09T00:28:00+09:00","readingtime":4,"relpermalink":"/blog/2013/01/09/%E3%82%B3%E3%83%BC%E3%83%89%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AA%E3%82%B7%E3%83%86%E3%82%A3%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9Fkindle-paperwhite%E3%81%AE%E4%BD%BF%E3%81%84%E5%8B%9D%E6%89%8B%E3%81%AE%E7%A2%BA%E8%AA%8D%E3%82%82%E5%85%BC%E3%81%AD%E3%81%A6/","section":"post","summary":"年末から年始にかけて、「コード・シンプリシティ」を読みました。 先日の記事にも書きましたが、Kindle paperwhiteを思いかけず入手で","tags":["読書"],"title":"「コード・シンプリシティ」を読みました。（Kindle paperwhiteの使い勝手の確認も兼ねて）(Jugemより移植)","type":"post","url":"/blog/2013/01/09/%E3%82%B3%E3%83%BC%E3%83%89%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AA%E3%82%B7%E3%83%86%E3%82%A3%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9Fkindle-paperwhite%E3%81%AE%E4%BD%BF%E3%81%84%E5%8B%9D%E6%89%8B%E3%81%AE%E7%A2%BA%E8%AA%8D%E3%82%82%E5%85%BC%E3%81%AD%E3%81%A6/","weight":0,"wordcount":1537},{"date":1356908460,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1356908460,"objectID":"4c08b67e0c1fdeef50b1fdcc32cdcee2","permalink":"https://blog.johtani.info/blog/2012/12/31/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A02012/","publishdate":"2012-12-31T08:01:00+09:00","readingtime":6,"relpermalink":"/blog/2012/12/31/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A02012/","section":"post","summary":"書こうと思いながら、気づいたら大晦日。 よくないですね、思いついた時に書かないと。 昨年も書いたので、昨年書いた抱負から振り返りをと。 Mongo","tags":["備忘録"],"title":"今年の振り返りと来年の抱負（2012）(Jugemより移植)","type":"post","url":"/blog/2012/12/31/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A02012/","weight":0,"wordcount":2557},{"date":1356002280,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1356002280,"objectID":"4a30eeb083acec8460150068ba0c6743","permalink":"https://blog.johtani.info/blog/2012/12/20/jira%E3%81%AEdb%E7%A7%BB%E8%A1%8Chsqldb%E3%81%8B%E3%82%89postgresql%E3%81%B8-augj/","publishdate":"2012-12-20T20:18:00+09:00","readingtime":6,"relpermalink":"/blog/2012/12/20/jira%E3%81%AEdb%E7%A7%BB%E8%A1%8Chsqldb%E3%81%8B%E3%82%89postgresql%E3%81%B8-augj/","section":"post","summary":"Atlassian Advent Calendar 2012の20日目。（急遽参戦） （某イケメンにMT（改変リツイート）されたので書いてみました） 久々に、勉強会以外のエントリです。（So","tags":["JIRA"],"title":"JIRAのDB移行（HSQLDBからPostgreSQLへ）#augj(Jugemより移植)","type":"post","url":"/blog/2012/12/20/jira%E3%81%AEdb%E7%A7%BB%E8%A1%8Chsqldb%E3%81%8B%E3%82%89postgresql%E3%81%B8-augj/","weight":0,"wordcount":2558},{"date":1355228520,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":3000,"kind":"page","lang":"ja","lastmod":1355228520,"objectID":"898d25a2ab9c0ba1fa9bad462405e475","permalink":"https://blog.johtani.info/blog/2012/12/11/%E7%AC%AC%E4%B8%80%E5%9B%9E-jetbrains%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97--jbugj-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-12-11T21:22:00+09:00","readingtime":6,"relpermalink":"/blog/2012/12/11/%E7%AC%AC%E4%B8%80%E5%9B%9E-jetbrains%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97--jbugj-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"イケメンが主催した「第一回 JetBrainsユーザーグループ #jbugj」に参加してきました。 いろんな製品があるんだなぁと。入り口には良いイ","tags":["勉強会"],"title":"第一回 JetBrainsユーザーグループ #jbugj に参加してきました(Jugemより移植)","type":"post","url":"/blog/2012/12/11/%E7%AC%AC%E4%B8%80%E5%9B%9E-jetbrains%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97--jbugj-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":2992},{"date":1354122000,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1354122000,"objectID":"e01e01d18582c7f69e1b0db7e1b111a0","permalink":"https://blog.johtani.info/blog/2012/11/29/dsirnlp-3-5%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Femacs%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80%E3%82%92%E9%A0%82%E3%81%84%E3%81%A1%E3%82%83%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-11-29T02:00:00+09:00","readingtime":6,"relpermalink":"/blog/2012/11/29/dsirnlp-3-5%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Femacs%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80%E3%82%92%E9%A0%82%E3%81%84%E3%81%A1%E3%82%83%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"ヒカリエに行ってみたいという不純な理由で参加してきました。 新しいということもあり、おしゃれで綺麗なカフェでした。 入り口にはおっきな人形も立っ","tags":["勉強会"],"title":"#DSIRNLP 3.5に参加しました。＆「Emacs実践入門」を頂いちゃいました！(Jugemより移植)","type":"post","url":"/blog/2012/11/29/dsirnlp-3-5%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Femacs%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80%E3%82%92%E9%A0%82%E3%81%84%E3%81%A1%E3%82%83%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":2682},{"date":1353923040,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":3800,"kind":"page","lang":"ja","lastmod":1353923040,"objectID":"7e23419e4fc69b5b533815681c9bb1a9","permalink":"https://blog.johtani.info/blog/2012/11/26/%E7%AC%AC9%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/","publishdate":"2012-11-26T18:44:00+09:00","readingtime":8,"relpermalink":"/blog/2012/11/26/%E7%AC%AC9%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/","section":"post","summary":"第9回Solr勉強会に参加しました。 皆勤賞です！というか、主催者になってしまいました。 まだ不定期の開催になると思いますが、話をされたい方など","tags":["勉強会"],"title":"第9回Solr勉強会を主催しました。#SolrJP(Jugemより移植)","type":"post","url":"/blog/2012/11/26/%E7%AC%AC9%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/","weight":0,"wordcount":3710},{"date":1352477220,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":3800,"kind":"page","lang":"ja","lastmod":1352477220,"objectID":"98c640616f997a323af625e34ba34850","permalink":"https://blog.johtani.info/blog/2012/11/10/aws-%E3%83%93%E3%83%83%E3%82%B0%E3%83%87%E3%83%BC%E3%82%BF%E6%B4%BB%E7%94%A8%E4%BA%8B%E4%BE%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-jawsug/","publishdate":"2012-11-10T01:07:00+09:00","readingtime":8,"relpermalink":"/blog/2012/11/10/aws-%E3%83%93%E3%83%83%E3%82%B0%E3%83%87%E3%83%BC%E3%82%BF%E6%B4%BB%E7%94%A8%E4%BA%8B%E4%BE%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-jawsug/","section":"post","summary":"初目黒（たぶん）で、初Amazonな感じで、流行りの「ビッグデータ」のセミナーに参加してきました。 とりあえず、いつもの自分用のメモを残してお","tags":["勉強会"],"title":"AWS ビッグデータ活用事例セミナーに参加しました。#jawsug(Jugemより移植)","type":"post","url":"/blog/2012/11/10/aws-%E3%83%93%E3%83%83%E3%82%B0%E3%83%87%E3%83%BC%E3%82%BF%E6%B4%BB%E7%94%A8%E4%BA%8B%E4%BE%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-jawsug/","weight":0,"wordcount":3740},{"date":1350031500,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1350031500,"objectID":"922cc71fd28b1dac8f407f1d517f5595","permalink":"https://blog.johtani.info/blog/2012/10/12/lucene-solr-4-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9lucene-gosen%E3%81%AE4-0%E5%AF%BE%E5%BF%9C/","publishdate":"2012-10-12T17:45:00+09:00","readingtime":2,"relpermalink":"/blog/2012/10/12/lucene-solr-4-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9lucene-gosen%E3%81%AE4-0%E5%AF%BE%E5%BF%9C/","section":"post","summary":"##Lucene/Solr 4.0.0リリース ついに、Lucene/Solr4.0.0がリリースされました。 MLで流れていましたが、3年越しのリリースだったようです。","tags":["lucene-gosen"],"title":"Lucene/Solr 4.0.0リリース＆lucene-gosenの4.0対応(Jugemより移植)","type":"post","url":"/blog/2012/10/12/lucene-solr-4-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9lucene-gosen%E3%81%AE4-0%E5%AF%BE%E5%BF%9C/","weight":0,"wordcount":742},{"date":1348650492,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1348650492,"objectID":"43501cdf0de25278a208cbb9aad80012","permalink":"https://blog.johtani.info/blog/2012/09/26/lucid%E3%81%AEgrant-ingersoll%E3%81%95%E3%82%93%E3%81%AE%E8%AC%9B%E6%BC%94%E3%82%92%E8%81%9E%E3%81%84%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-09-26T18:08:12+09:00","readingtime":4,"relpermalink":"/blog/2012/09/26/lucid%E3%81%AEgrant-ingersoll%E3%81%95%E3%82%93%E3%81%AE%E8%AC%9B%E6%BC%94%E3%82%92%E8%81%9E%E3%81%84%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"このイベントにウチダスペクトラムの枠でMahoutのコミッターである、Grant Ingersollさんが講演されるということで、興味があった","tags":["勉強会"],"title":"LucidのGrant Ingersollさんの講演を聞いてきました(Jugemより移植)","type":"post","url":"/blog/2012/09/26/lucid%E3%81%AEgrant-ingersoll%E3%81%95%E3%82%93%E3%81%AE%E8%AC%9B%E6%BC%94%E3%82%92%E8%81%9E%E3%81%84%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":1512},{"date":1348214700,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":4500,"kind":"page","lang":"ja","lastmod":1348214700,"objectID":"89abaa7f21cf788ce4744e3e61173291","permalink":"https://blog.johtani.info/blog/2012/09/21/pfi%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC2012%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pfiopen2012/","publishdate":"2012-09-21T17:05:00+09:00","readingtime":9,"relpermalink":"/blog/2012/09/21/pfi%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC2012%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pfiopen2012/","section":"post","summary":"PFIオープンセミナー2012に参加してきました。 対象から微妙に外れてたり、話の内容についていけるか自信がありませんでしたが、参加してきまし","tags":["勉強会"],"title":"PFIオープンセミナー2012に参加してきました。 #pfiopen2012(Jugemより移植)","type":"post","url":"/blog/2012/09/21/pfi%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC2012%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pfiopen2012/","weight":0,"wordcount":4432},{"date":1346650440,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1346650440,"objectID":"7604edf307a5e96120606c8dda06458f","permalink":"https://blog.johtani.info/blog/2012/09/03/%E3%83%A1%E3%82%A4%E3%83%B3mba%E3%82%92mountain-lion%E3%81%AB%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88%E3%81%84%E3%82%8D%E3%81%84%E3%82%8D%E7%A2%BA%E8%AA%8D%E4%B8%AD/","publishdate":"2012-09-03T14:34:00+09:00","readingtime":6,"relpermalink":"/blog/2012/09/03/%E3%83%A1%E3%82%A4%E3%83%B3mba%E3%82%92mountain-lion%E3%81%AB%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88%E3%81%84%E3%82%8D%E3%81%84%E3%82%8D%E7%A2%BA%E8%AA%8D%E4%B8%AD/","section":"post","summary":"友人にお値打価格で購入したMac miniはMountain Lionにアップデートしてたのですが、手元のAirはまだアップデートしていませんで","tags":["備忘録"],"title":"メインMBAをMountain Lionにアップデート（いろいろ確認中）(Jugemより移植)","type":"post","url":"/blog/2012/09/03/%E3%83%A1%E3%82%A4%E3%83%B3mba%E3%82%92mountain-lion%E3%81%AB%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88%E3%81%84%E3%82%8D%E3%81%84%E3%82%8D%E7%A2%BA%E8%AA%8D%E4%B8%AD/","weight":0,"wordcount":2545},{"date":1345657200,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":3200,"kind":"page","lang":"ja","lastmod":1345657200,"objectID":"775894425f5a7436f56fc5a3b4a2cfaa","permalink":"https://blog.johtani.info/blog/2012/08/23/fluentd-meetup-in-japan--2--fluentd-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-08-23T02:40:00+09:00","readingtime":7,"relpermalink":"/blog/2012/08/23/fluentd-meetup-in-japan--2--fluentd-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"興味をもちつつ、触っていない軟弱者ですが、興味があるので今回も話を聞きに行って来ました。 まずは、作者古橋さんによるFluentdの魅力や次期","tags":["勉強会"],"title":"Fluentd meetup in Japan #2 #fluentd に参加しました。(Jugemより移植)","type":"post","url":"/blog/2012/08/23/fluentd-meetup-in-japan--2--fluentd-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":3130},{"date":1343875800,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2200,"kind":"page","lang":"ja","lastmod":1343875800,"objectID":"8a29f62d1bebfe7b8008d7f264b56b4e","permalink":"https://blog.johtani.info/blog/2012/08/02/twitter-%E5%8B%89%E5%BC%B7%E4%BC%9A--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-08-02T11:50:00+09:00","readingtime":5,"relpermalink":"/blog/2012/08/02/twitter-%E5%8B%89%E5%BC%B7%E4%BC%9A--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"またまた飲みに行って参加してきました。 今回は、Rails、iOSでのTwitter連携の話から、ツイート分析、クライアントアプリの開発の苦労","tags":["勉強会"],"title":"Twitter 勉強会 #twtr_hack に参加しました。(Jugemより移植)","type":"post","url":"/blog/2012/08/02/twitter-%E5%8B%89%E5%BC%B7%E4%BC%9A--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":2168},{"date":1343466900,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2200,"kind":"page","lang":"ja","lastmod":1343466900,"objectID":"7fa2f0877831b4c924438396760f1841","permalink":"https://blog.johtani.info/blog/2012/07/28/python-developers-festa-2012-07%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%97%E3%82%83%E3%81%B9%E3%81%A3%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pyfes/","publishdate":"2012-07-28T18:15:00+09:00","readingtime":5,"relpermalink":"/blog/2012/07/28/python-developers-festa-2012-07%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%97%E3%82%83%E3%81%B9%E3%81%A3%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pyfes/","section":"post","summary":"ということで、ステッカー欲しさ？に勉強中の話を恥ずかしげもなく偉そうにしゃべってきました。 #pyfesは以前から、気になっていたんですが、タ","tags":["勉強会"],"title":"Python Developers Festa 2012.07に参加してしゃべってきました #pyfes(Jugemより移植)","type":"post","url":"/blog/2012/07/28/python-developers-festa-2012-07%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%97%E3%82%83%E3%81%B9%E3%81%A3%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pyfes/","weight":0,"wordcount":2194},{"date":1342177320,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":3300,"kind":"page","lang":"ja","lastmod":1342177320,"objectID":"68a8f34c240a42ab521d2f885f7aa33c","permalink":"https://blog.johtani.info/blog/2012/07/13/partial-update%E3%81%A8copyfield%E3%81%AE%E3%83%90%E3%82%B0solr-4-0-alpha/","publishdate":"2012-07-13T20:02:00+09:00","readingtime":7,"relpermalink":"/blog/2012/07/13/partial-update%E3%81%A8copyfield%E3%81%AE%E3%83%90%E3%82%B0solr-4-0-alpha/","section":"post","summary":"今日はSolr 4.0 ALPHAの興味深い機能があったので紹介です。 数日前に「Solr 4.0: Partial documents update」という記事を見つけました。 Solrには、","tags":["solr"],"title":"Partial UpdateとcopyFieldのバグ【Solr 4.0 ALPHA】(Jugemより移植)","type":"post","url":"/blog/2012/07/13/partial-update%E3%81%A8copyfield%E3%81%AE%E3%83%90%E3%82%B0solr-4-0-alpha/","weight":0,"wordcount":3293},{"date":1342111298,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1342111298,"objectID":"9ac7bb94e60dc30a023ce433de027364","permalink":"https://blog.johtani.info/blog/2012/07/13/mir%E8%BC%AA%E8%AA%AD%E4%BC%9A%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-07-13T01:41:38+09:00","readingtime":2,"relpermalink":"/blog/2012/07/13/mir%E8%BC%AA%E8%AA%AD%E4%BC%9A%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"Modern Information Retrieval: The Concepts and Technology behind Search (2nd Edition) (ACM Press Books) いやぁ、蒸し暑くてなかなか寝れない日がはじまりましたね。（あんまり関係ないですね。。。） Modern Information Retrieval 2nd Editionを","tags":["勉強会"],"title":"MIR輪読会始めました(Jugemより移植)","type":"post","url":"/blog/2012/07/13/mir%E8%BC%AA%E8%AA%AD%E4%BC%9A%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":632},{"date":1341457909,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":200,"kind":"page","lang":"ja","lastmod":1341457909,"objectID":"dcc2e24df32287e89ee3b0f64d617f57","permalink":"https://blog.johtani.info/blog/2012/07/05/lucene-gosen%E3%81%AElucene-solr4-0-alpha%E5%AF%BE%E5%BF%9C/","publishdate":"2012-07-05T12:11:49+09:00","readingtime":1,"relpermalink":"/blog/2012/07/05/lucene-gosen%E3%81%AElucene-solr4-0-alpha%E5%AF%BE%E5%BF%9C/","section":"post","summary":"Lucene/Solrの4.0.0-ALPHAが7/3にリリースされました。 これに伴い、lucene-goenの4xブランチのjarファイル","tags":["lucene-gosen"],"title":"lucene-gosenのLucene/Solr4.0-ALPHA対応(Jugemより移植)","type":"post","url":"/blog/2012/07/05/lucene-gosen%E3%81%AElucene-solr4-0-alpha%E5%AF%BE%E5%BF%9C/","weight":0,"wordcount":187},{"date":1341402000,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":3100,"kind":"page","lang":"ja","lastmod":1341402000,"objectID":"8acc78be63e27e938ee53ec2c0b90c61","permalink":"https://blog.johtani.info/blog/2012/07/04/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--solrjp/","publishdate":"2012-07-04T20:40:00+09:00","readingtime":7,"relpermalink":"/blog/2012/07/04/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--solrjp/","section":"post","summary":"またまた参加しました。いまだ皆勤賞です。 感想などはあとで。とりあえず、メモとったので第一弾です。 ということで、感想です。 まずは、参加人数。 今","tags":["勉強会"],"title":"Solr勉強会第8回に参加しました。 #SolrJP(Jugemより移植)","type":"post","url":"/blog/2012/07/04/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--solrjp/","weight":0,"wordcount":3071},{"date":1340642460,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":4500,"kind":"page","lang":"ja","lastmod":1340642460,"objectID":"9f29c6d9719fc6bc09a2981057642b69","permalink":"https://blog.johtani.info/blog/2012/06/26/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC10%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/","publishdate":"2012-06-26T01:41:00+09:00","readingtime":9,"relpermalink":"/blog/2012/06/26/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC10%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/","section":"post","summary":"Hadoopからはちょっと離れているのに、面白そうなネタなので参加しました。 Data Science Summit、HBaseCon、Hadoop Summitのイ","tags":[],"title":"Hadoopソースコードリーディング第10回に参加しました。#hadoopreading(Jugemより移植)","type":"post","url":"/blog/2012/06/26/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC10%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/","weight":0,"wordcount":4433},{"date":1340028180,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1340028180,"objectID":"d13aa56e27fe71ef40ff153c093ecdf8","permalink":"https://blog.johtani.info/blog/2012/06/18/lucene-gosen%E3%81%AEunidic%E5%AF%BE%E5%BF%9C/","publishdate":"2012-06-18T23:03:00+09:00","readingtime":3,"relpermalink":"/blog/2012/06/18/lucene-gosen%E3%81%AEunidic%E5%AF%BE%E5%BF%9C/","section":"post","summary":"Issue 32で上がってきたlucee-gosenのUniDic対応の最初のパッチを書いたので、ブログに残しておきます。 ###UniDicとは___","tags":["lucene-gosen"],"title":"lucene-gosenのUniDic対応(Jugemより移植)","type":"post","url":"/blog/2012/06/18/lucene-gosen%E3%81%AEunidic%E5%AF%BE%E5%BF%9C/","weight":0,"wordcount":1457},{"date":1339772520,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":4300,"kind":"page","lang":"ja","lastmod":1339772520,"objectID":"9ccda414c322ebcdf875eacbba2e4b7e","permalink":"https://blog.johtani.info/blog/2012/06/16/zipkin%E3%81%AEreadme%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%81%9D%E3%81%AE%EF%BC%92%E6%AE%8B%E3%82%8A/","publishdate":"2012-06-16T00:02:00+09:00","readingtime":9,"relpermalink":"/blog/2012/06/16/zipkin%E3%81%AEreadme%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%81%9D%E3%81%AE%EF%BC%92%E6%AE%8B%E3%82%8A/","section":"post","summary":"「鉄は熱いうちに打て」ということで、残りも勢いでメモ。 まだ、見直しとかしてない状態なのでおかしいところとかありますが。。。 図とか入れるのはま","tags":["Zipkin"],"title":"ZipkinのReadme読んでる（その２、残り）(Jugemより移植)","type":"post","url":"/blog/2012/06/16/zipkin%E3%81%AEreadme%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%81%9D%E3%81%AE%EF%BC%92%E6%AE%8B%E3%82%8A/","weight":0,"wordcount":4255},{"date":1339721820,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1339721820,"objectID":"69f755dd5b9e90a99c3086543790541c","permalink":"https://blog.johtani.info/blog/2012/06/15/zipkin%E3%81%AEreadme%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E5%91%A8%E3%82%8A%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-06-15T09:57:00+09:00","readingtime":3,"relpermalink":"/blog/2012/06/15/zipkin%E3%81%AEreadme%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E5%91%A8%E3%82%8A%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","section":"post","summary":"ZipkinのGithubにあるReadmeを読んでます。 せっかくというか、頭が悪いので読みながら内容をメモ。 まずは、アーキテクチャとトレー","tags":["Zipkin"],"title":"ZipkinのReadmeを読んでる（クライアント周りについて）(Jugemより移植)","type":"post","url":"/blog/2012/06/15/zipkin%E3%81%AEreadme%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E5%91%A8%E3%82%8A%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","weight":0,"wordcount":1402},{"date":1339603740,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1339603740,"objectID":"277f7f2177e2a265a62680ea0158f9b9","permalink":"https://blog.johtani.info/blog/2012/06/14/autogeneratephrasequeries%E3%81%AE%E3%83%87%E3%83%95%E3%82%A9%E3%83%AB%E3%83%88%E5%80%A4%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-06-14T01:09:00+09:00","readingtime":2,"relpermalink":"/blog/2012/06/14/autogeneratephrasequeries%E3%81%AE%E3%83%87%E3%83%95%E3%82%A9%E3%83%AB%E3%83%88%E5%80%A4%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","section":"post","summary":"久々にSolrの話です。 といっても、結構前からの話でして。。。 schema.xmlのfieldTypeの設定に「autoGeneratePh","tags":["solr"],"title":"autoGeneratePhraseQueriesのデフォルト値について(Jugemより移植)","type":"post","url":"/blog/2012/06/14/autogeneratephrasequeries%E3%81%AE%E3%83%87%E3%83%95%E3%82%A9%E3%83%AB%E3%83%88%E5%80%A4%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","weight":0,"wordcount":645},{"date":1339515600,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1339515600,"objectID":"ee48516e57684c5a4c22adccac34be92","permalink":"https://blog.johtani.info/blog/2012/06/13/twitter%E3%81%8C%E5%85%AC%E9%96%8B%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%B3%E3%82%B0%E8%BF%BD%E8%B7%A1%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0zipkin/","publishdate":"2012-06-13T00:40:00+09:00","readingtime":3,"relpermalink":"/blog/2012/06/13/twitter%E3%81%8C%E5%85%AC%E9%96%8B%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%B3%E3%82%B0%E8%BF%BD%E8%B7%A1%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0zipkin/","section":"post","summary":"すでに読まれた方もいるかも知れませんが、気になったのでメモを書いてみようかと。 先週の木曜日にTwitterのエンジニアブログでZipkinと","tags":["OSS"],"title":"Twitterが公開した分散トレーシング（追跡？）システム、Zipkin(Jugemより移植)","type":"post","url":"/blog/2012/06/13/twitter%E3%81%8C%E5%85%AC%E9%96%8B%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%B3%E3%82%B0%E8%BF%BD%E8%B7%A1%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0zipkin/","weight":0,"wordcount":1009},{"date":1339059234,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":300,"kind":"page","lang":"ja","lastmod":1339059234,"objectID":"216db319052b5742fc68862cb2f39905","permalink":"https://blog.johtani.info/blog/2012/06/07/lucene-gosen-2-0-2%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E5%91%A8%E3%82%8A%E3%81%AE%E6%94%B9%E5%96%84%E3%81%AA%E3%81%A9/","publishdate":"2012-06-07T17:53:54+09:00","readingtime":1,"relpermalink":"/blog/2012/06/07/lucene-gosen-2-0-2%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E5%91%A8%E3%82%8A%E3%81%AE%E6%94%B9%E5%96%84%E3%81%AA%E3%81%A9/","section":"post","summary":"lucene-gosenの最新版（2.0.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、@haruy","tags":["lucene-gosen"],"title":"lucene-gosen 2.0.2リリース（リソース周りの改善など）(Jugemより移植)","type":"post","url":"/blog/2012/06/07/lucene-gosen-2-0-2%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E5%91%A8%E3%82%8A%E3%81%AE%E6%94%B9%E5%96%84%E3%81%AA%E3%81%A9/","weight":0,"wordcount":222},{"date":1338913260,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1338913260,"objectID":"cbf9587a8187985725963b8bfc67004d","permalink":"https://blog.johtani.info/blog/2012/06/06/issue32%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A64096%E3%81%AE%E5%A3%81/","publishdate":"2012-06-06T01:21:00+09:00","readingtime":3,"relpermalink":"/blog/2012/06/06/issue32%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A64096%E3%81%AE%E5%A3%81/","section":"post","summary":"昨晩に引き続き、情けない内容のブログになってしまいますが。。。 昨晩、書いた記事の調査をしていた時に気づいた、問題になるケースがあったので調査","tags":["lucene-gosen"],"title":"Issue32について（4096の壁）(Jugemより移植)","type":"post","url":"/blog/2012/06/06/issue32%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A64096%E3%81%AE%E5%A3%81/","weight":0,"wordcount":1454},{"date":1338827340,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1338827340,"objectID":"0dcb6d0f17794bbca56b6cdb9e20b932","permalink":"https://blog.johtani.info/blog/2012/06/05/trunk%E3%81%AE%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E5%B7%AE%E3%81%97%E6%9B%BF%E3%81%88lucene-solr3-6-0%E3%81%A8%E3%83%A9%E3%83%B3%E3%83%80%E3%83%A0%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E5%A4%B1%E6%95%97%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-06-05T01:29:00+09:00","readingtime":3,"relpermalink":"/blog/2012/06/05/trunk%E3%81%AE%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E5%B7%AE%E3%81%97%E6%9B%BF%E3%81%88lucene-solr3-6-0%E3%81%A8%E3%83%A9%E3%83%B3%E3%83%80%E3%83%A0%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E5%A4%B1%E6%95%97%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","section":"post","summary":"久々にlucene-gosenを触っています。 trunkのlibにある、jarファイルが3.5ベースだったので、3.6ベースにしてテストをし","tags":["lucene-gosen"],"title":"trunkのライブラリ差し替え（Lucene/Solr3.6.0）とランダムテストの失敗について(Jugemより移植)","type":"post","url":"/blog/2012/06/05/trunk%E3%81%AE%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E5%B7%AE%E3%81%97%E6%9B%BF%E3%81%88lucene-solr3-6-0%E3%81%A8%E3%83%A9%E3%83%B3%E3%83%80%E3%83%A0%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E5%A4%B1%E6%95%97%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","weight":0,"wordcount":1064},{"date":1338394320,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1338394320,"objectID":"ffdbd6a7d28c9a63976e9eec38cab0f5","permalink":"https://blog.johtani.info/blog/2012/05/31/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%B8%E3%81%AE%E8%B2%A2%E7%8C%AE%E3%81%AE%E3%82%B9%E3%82%B9%E3%83%A1/","publishdate":"2012-05-31T01:12:00+09:00","readingtime":2,"relpermalink":"/blog/2012/05/31/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%B8%E3%81%AE%E8%B2%A2%E7%8C%AE%E3%81%AE%E3%82%B9%E3%82%B9%E3%83%A1/","section":"post","summary":"録画してたEテレのスーパープレゼンテーションを見ててふと書きたくなったので、書いてます。 あとから読んだら恥ずかしくなりそうだけど。。。 「\u0026l","tags":["misc"],"title":"オープンソースへの貢献のススメ(Jugemより移植)","type":"post","url":"/blog/2012/05/31/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%B8%E3%81%AE%E8%B2%A2%E7%8C%AE%E3%81%AE%E3%82%B9%E3%82%B9%E3%83%A1/","weight":0,"wordcount":966},{"date":1338259500,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":5200,"kind":"page","lang":"ja","lastmod":1338259500,"objectID":"de734259dfb9addebe2b226d96b4f744","permalink":"https://blog.johtani.info/blog/2012/05/29/jjug-ccc-2012-spring%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-05-29T11:45:00+09:00","readingtime":11,"relpermalink":"/blog/2012/05/29/jjug-ccc-2012-spring%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"JJUG CCC 2012 Springに参加してきました。 昨年のFallに続き、2回目です。 概要や、タイムテーブルはこちらを御覧ください。 今回は、午後一から参加","tags":["勉強会"],"title":"JJUG CCC 2012 Springに参加してきました。(Jugemより移植)","type":"post","url":"/blog/2012/05/29/jjug-ccc-2012-spring%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":5189},{"date":1337151314,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1337151314,"objectID":"78f002cc3d512ea302c900d1da4dfeec","permalink":"https://blog.johtani.info/blog/2012/05/16/playframework-2-0-java%E3%81%AE%E6%96%B9-%E3%82%92%E8%A7%A6%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%A6%E3%82%8B/","publishdate":"2012-05-16T15:55:14+09:00","readingtime":2,"relpermalink":"/blog/2012/05/16/playframework-2-0-java%E3%81%AE%E6%96%B9-%E3%82%92%E8%A7%A6%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%A6%E3%82%8B/","section":"post","summary":"PlayFramework2.0を触ってみてます。 ちょっとコーディングしたくなったのと、最近のアプリの作成の調査も兼ねて。 まぁ、せっかくなの","tags":["備忘録"],"title":"PlayFramework 2.0(Javaの方)を触ってみてる(Jugemより移植)","type":"post","url":"/blog/2012/05/16/playframework-2-0-java%E3%81%AE%E6%96%B9-%E3%82%92%E8%A7%A6%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%A6%E3%82%8B/","weight":0,"wordcount":949},{"date":1336494900,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":200,"kind":"page","lang":"ja","lastmod":1336494900,"objectID":"c4b418764dca70aebfc965899a3fa7e5","permalink":"https://blog.johtani.info/blog/2012/05/09/lucene-gosen-2-0-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9java7%E5%AF%BE%E5%BF%9C/","publishdate":"2012-05-09T01:35:00+09:00","readingtime":1,"relpermalink":"/blog/2012/05/09/lucene-gosen-2-0-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9java7%E5%AF%BE%E5%BF%9C/","section":"post","summary":"lucene-gosenの最新版（2.0.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、Java7で","tags":["lucene-gosen"],"title":"lucene-gosen 2.0.1リリース（Java7対応）(Jugemより移植)","type":"post","url":"/blog/2012/05/09/lucene-gosen-2-0-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9java7%E5%AF%BE%E5%BF%9C/","weight":0,"wordcount":171},{"date":1335794635,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":600,"kind":"page","lang":"ja","lastmod":1335794635,"objectID":"95c0a5b8a66950b5f22dd82a8dfe0ce5","permalink":"https://blog.johtani.info/blog/2012/04/30/id%E3%81%AE%E7%A7%98%E5%AF%86%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-04-30T23:03:55+09:00","readingtime":2,"relpermalink":"/blog/2012/04/30/id%E3%81%AE%E7%A7%98%E5%AF%86%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"IDの秘密 (丸善ライブラリー―情報研シリーズ) 非常に面白く読めました。 バーコードの話に始まり、最後はシステムで付与するIDに関する考慮点まで","tags":["読書"],"title":"「IDの秘密」を読みました。(Jugemより移植)","type":"post","url":"/blog/2012/04/30/id%E3%81%AE%E7%A7%98%E5%AF%86%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":547},{"date":1334935380,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1334935380,"objectID":"c92c12a28fa219ad1aab60865046ff05","permalink":"https://blog.johtani.info/blog/2012/04/21/heroku-jp-meetup-4%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/","publishdate":"2012-04-21T00:23:00+09:00","readingtime":6,"relpermalink":"/blog/2012/04/21/heroku-jp-meetup-4%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/","section":"post","summary":"WebSolrの話があるらしいというのを嗅ぎつけて、初めてHeroku JP Meetupに参加しました。 herokuもWebSolrも知りつつ、","tags":["勉強会"],"title":"Heroku JP Meetup ＃4に参加しました。#herokujp(Jugemより移植)","type":"post","url":"/blog/2012/04/21/heroku-jp-meetup-4%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/","weight":0,"wordcount":2606},{"date":1334592971,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1334592971,"objectID":"12d1e0cf7396dd33a9bbbca8da4cbc68","permalink":"https://blog.johtani.info/blog/2012/04/17/solr-3-6-0%E3%81%AEcjk%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%81%A8synonymfilterfactory%E3%81%AE%E6%B0%97%E3%81%AB%E3%81%AA%E3%82%8B%E7%82%B9/","publishdate":"2012-04-17T01:16:11+09:00","readingtime":2,"relpermalink":"/blog/2012/04/17/solr-3-6-0%E3%81%AEcjk%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%81%A8synonymfilterfactory%E3%81%AE%E6%B0%97%E3%81%AB%E3%81%AA%E3%82%8B%E7%82%B9/","section":"post","summary":"先日、Solr入門のサンプルschema.xmlの3.6.0対応版の作成をしていて、気になったことがあったので、 メモとして残しておきます。 S","tags":["solr"],"title":"Solr 3.6.0のCJKの設定とSynonymFilterFactoryの気になる点(Jugemより移植)","type":"post","url":"/blog/2012/04/17/solr-3-6-0%E3%81%AEcjk%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%81%A8synonymfilterfactory%E3%81%AE%E6%B0%97%E3%81%AB%E3%81%AA%E3%82%8B%E7%82%B9/","weight":0,"wordcount":958},{"date":1334339880,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1334339880,"objectID":"d77cdb466c5063b99c5aea58e6da4d32","permalink":"https://blog.johtani.info/blog/2012/04/14/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C2%E7%AB%A04%E7%AB%A0/","publishdate":"2012-04-14T02:58:00+09:00","readingtime":3,"relpermalink":"/blog/2012/04/14/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C2%E7%AB%A04%E7%AB%A0/","section":"post","summary":"先日の続きです。「Apache Solr入門」の2章から4章の説明について、Solr3.6.0で動作させる時の変更点を以下に書いていきます。 な","tags":["solr"],"title":"「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（2章～4章）(Jugemより移植)","type":"post","url":"/blog/2012/04/14/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C2%E7%AB%A04%E7%AB%A0/","weight":0,"wordcount":1201},{"date":1334339100,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1334339100,"objectID":"904b07170a0ce481b7491e7fecce4f79","permalink":"https://blog.johtani.info/blog/2012/04/14/lucene-solr-3-6-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9---apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0/","publishdate":"2012-04-14T02:45:00+09:00","readingtime":5,"relpermalink":"/blog/2012/04/14/lucene-solr-3-6-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9---apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0/","section":"post","summary":"以前より、アナウンスしていた、Kuromojiという日本語形態素解析が含まれるLucene/Solr 3.6.0がリリースされました。 以下、各","tags":["solr"],"title":"Lucene/Solr 3.6.0リリース / 「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（1章）(Jugemより移植)","type":"post","url":"/blog/2012/04/14/lucene-solr-3-6-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9---apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0/","weight":0,"wordcount":2331},{"date":1334241069,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":700,"kind":"page","lang":"ja","lastmod":1334241069,"objectID":"bed3b7fcc1294e23639057435ac8756a","permalink":"https://blog.johtani.info/blog/2012/04/12/%E3%83%A1%E3%83%A2amazon-cloudsearch%E3%81%8C%E5%87%BA%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F%E3%82%88/","publishdate":"2012-04-12T23:31:09+09:00","readingtime":2,"relpermalink":"/blog/2012/04/12/%E3%83%A1%E3%83%A2amazon-cloudsearch%E3%81%8C%E5%87%BA%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F%E3%82%88/","section":"post","summary":"Twitterでこのブログ流れてきて、気になったので、流し読みして簡単にメモ。 Amazonのサービスでスケールする検索サービスみたい。 主に、","tags":["備忘録"],"title":"【メモ】Amazon CloudSearchが出てきましたよ(Jugemより移植)","type":"post","url":"/blog/2012/04/12/%E3%83%A1%E3%83%A2amazon-cloudsearch%E3%81%8C%E5%87%BA%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F%E3%82%88/","weight":0,"wordcount":683},{"date":1333698660,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":7400,"kind":"page","lang":"ja","lastmod":1333698660,"objectID":"56d5711303378bd333ddb611a53ece94","permalink":"https://blog.johtani.info/blog/2012/04/06/java-one-tokyo-2012-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-javaonejp/","publishdate":"2012-04-06T16:51:00+09:00","readingtime":15,"relpermalink":"/blog/2012/04/06/java-one-tokyo-2012-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-javaonejp/","section":"post","summary":"JavaOne Tokyo 2012に参加してきました。 4/4-4/5の2日間開催されていたのですが、子供が体調を崩してしまい、4/5のみの参加となりました。 4/4","tags":["勉強会"],"title":"Java One Tokyo 2012 に参加しました。#JavaOneJp(Jugemより移植)","type":"post","url":"/blog/2012/04/06/java-one-tokyo-2012-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-javaonejp/","weight":0,"wordcount":7363},{"date":1333552800,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1333552800,"objectID":"c7937b6b4bde2a96191dc31db913e1ab","permalink":"https://blog.johtani.info/blog/2012/04/05/lucene-gosen%E3%81%AEjava7%E3%81%A7%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E5%A4%B1%E6%95%97%E5%95%8F%E9%A1%8C%E3%81%AE%E5%AF%BE%E5%BF%9C/","publishdate":"2012-04-05T00:20:00+09:00","readingtime":2,"relpermalink":"/blog/2012/04/05/lucene-gosen%E3%81%AEjava7%E3%81%A7%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E5%A4%B1%E6%95%97%E5%95%8F%E9%A1%8C%E3%81%AE%E5%AF%BE%E5%BF%9C/","section":"post","summary":"先日、2.0.0リリースの記事にも記載しましたが、Java7でテストケースが失敗する問題がありました。 @haruyamaさんと@hideak","tags":["lucene-gosen"],"title":"lucene-gosenのJava7でのテスト失敗問題の対応(Jugemより移植)","type":"post","url":"/blog/2012/04/05/lucene-gosen%E3%81%AEjava7%E3%81%A7%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E5%A4%B1%E6%95%97%E5%95%8F%E9%A1%8C%E3%81%AE%E5%AF%BE%E5%BF%9C/","weight":0,"wordcount":840},{"date":1333362120,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1333362120,"objectID":"06731164684f90f33ce4017eca9d8ec1","permalink":"https://blog.johtani.info/blog/2012/04/02/%E9%87%8D%E8%A6%81lucene-gosen-2-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2012-04-02T19:22:00+09:00","readingtime":3,"relpermalink":"/blog/2012/04/02/%E9%87%8D%E8%A6%81lucene-gosen-2-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","section":"post","summary":"先日、宣言したとおり、lucene-gosenのパッケージ名＋クラス名の変更を行ったlucene-gosen 2.0.0をリリースしました。 Lucene/Solr","tags":["lucene-gosen"],"title":"【重要】lucene-gosen 2.0.0リリース(Jugemより移植)","type":"post","url":"/blog/2012/04/02/%E9%87%8D%E8%A6%81lucene-gosen-2-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","weight":0,"wordcount":1096},{"date":1332783540,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1332783540,"objectID":"f8327953a0f0b80011b939111807999a","permalink":"https://blog.johtani.info/blog/2012/03/27/%E9%87%8D%E8%A6%81lucene-gosen%E3%81%AE%E6%AC%A1%E6%9C%9F%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-03-27T02:39:00+09:00","readingtime":2,"relpermalink":"/blog/2012/03/27/%E9%87%8D%E8%A6%81lucene-gosen%E3%81%AE%E6%AC%A1%E6%9C%9F%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","section":"post","summary":"lucene-gosenを利用して頂いてる皆様に連絡があります。 連絡事項 次期lucene-gosenのリリース（2.0を予定）にて、org.","tags":["lucene-gosen"],"title":"【重要】lucene-gosenの次期リリースについて(Jugemより移植)","type":"post","url":"/blog/2012/03/27/%E9%87%8D%E8%A6%81lucene-gosen%E3%81%AE%E6%AC%A1%E6%9C%9F%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","weight":0,"wordcount":952},{"date":1332618420,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1200,"kind":"page","lang":"ja","lastmod":1332618420,"objectID":"8b76101d185700a8efed148d8722d926","permalink":"https://blog.johtani.info/blog/2012/03/25/%E4%B9%85%E3%80%85%E3%81%ABmac-mini%E3%81%AE%E3%81%93%E3%81%A8%E3%81%A7%E3%82%82/","publishdate":"2012-03-25T04:47:00+09:00","readingtime":3,"relpermalink":"/blog/2012/03/25/%E4%B9%85%E3%80%85%E3%81%ABmac-mini%E3%81%AE%E3%81%93%E3%81%A8%E3%81%A7%E3%82%82/","section":"post","summary":"子供の寝かしつけしてたら、寝かしつけされてしまって、２時に目が覚めてしまいました。 TSUTAYAでCD借りてきてウォークマンに入れようと思っ","tags":["備忘録"],"title":"久々にMac Miniのことでも(Jugemより移植)","type":"post","url":"/blog/2012/03/25/%E4%B9%85%E3%80%85%E3%81%ABmac-mini%E3%81%AE%E3%81%93%E3%81%A8%E3%81%A7%E3%82%82/","weight":0,"wordcount":1140},{"date":1332343680,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2600,"kind":"page","lang":"ja","lastmod":1332343680,"objectID":"16b3c9445539e9274282a612dea354c2","permalink":"https://blog.johtani.info/blog/2012/03/22/%E7%AC%AC5%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%B8%8B%E8%B0%B7--twtr_hack/","publishdate":"2012-03-22T00:28:00+09:00","readingtime":6,"relpermalink":"/blog/2012/03/22/%E7%AC%AC5%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%B8%8B%E8%B0%B7--twtr_hack/","section":"post","summary":"はい。またまた、Twitter API勉強会に参加してきました。（今回から開催回数の記載がなくなった？） 今回は直前でタイムテーブルが変わってし","tags":["勉強会"],"title":"第5回 Twitter API勉強会 @渋谷 #twtr_hack(Jugemより移植)","type":"post","url":"/blog/2012/03/22/%E7%AC%AC5%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%B8%8B%E8%B0%B7--twtr_hack/","weight":0,"wordcount":2547},{"date":1332253920,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1332253920,"objectID":"ee623aaa99b429863f89da313fffed97","permalink":"https://blog.johtani.info/blog/2012/03/20/%E8%87%AA%E5%88%86%E3%81%AE%E5%B0%8F%E3%81%95%E3%81%AA%E7%AE%B1%E3%81%8B%E3%82%89%E8%84%B1%E5%87%BA%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-03-20T23:32:00+09:00","readingtime":2,"relpermalink":"/blog/2012/03/20/%E8%87%AA%E5%88%86%E3%81%AE%E5%B0%8F%E3%81%95%E3%81%AA%E7%AE%B1%E3%81%8B%E3%82%89%E8%84%B1%E5%87%BA%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"TLで面白いと見かけて、Amazonで買ってしまいました。 SEやってるのに、つい最近Amazonを使い始めた軟弱者です。 それにしてもAmaz","tags":["読書"],"title":"「自分の小さな「箱」から脱出する方法」を読みました。(Jugemより移植)","type":"post","url":"/blog/2012/03/20/%E8%87%AA%E5%88%86%E3%81%AE%E5%B0%8F%E3%81%95%E3%81%AA%E7%AE%B1%E3%81%8B%E3%82%89%E8%84%B1%E5%87%BA%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":732},{"date":1331652421,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":800,"kind":"page","lang":"ja","lastmod":1331652421,"objectID":"116c9be6d760b4befa6d51ce9e96604c","permalink":"https://blog.johtani.info/blog/2012/03/14/scala%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-03-14T00:27:01+09:00","readingtime":2,"relpermalink":"/blog/2012/03/14/scala%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"えーと、ブログ更新してないなぁとふと思ったので。 １年前くらいからずーっと、つぶやいてましたが、やっとScalaを始めました。 長かった。。。 と","tags":["Scala"],"title":"Scala始めました(Jugemより移植)","type":"post","url":"/blog/2012/03/14/scala%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":713},{"date":1331230200,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1331230200,"objectID":"4d6c95b0b3ea2ddb30fdd3edf3b82391","permalink":"https://blog.johtani.info/blog/2012/03/09/%E7%AC%AC0%E5%9B%9E-twitter-hack--twtr_hack-%E3%81%AB%E9%81%8A%E3%81%B3%E3%81%AB%E8%A1%8C%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-03-09T03:10:00+09:00","readingtime":4,"relpermalink":"/blog/2012/03/09/%E7%AC%AC0%E5%9B%9E-twitter-hack--twtr_hack-%E3%81%AB%E9%81%8A%E3%81%B3%E3%81%AB%E8%A1%8C%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"森ビルに行ったことなかったので、参加してみました。 あと、最近まともにコーディングしてないので、そのへんを矯正するためにもと思って。 （まぁ、遊","tags":["勉強会"],"title":"第0回 Twitter Hack #twtr_hack に遊びに行きました。(Jugemより移植)","type":"post","url":"/blog/2012/03/09/%E7%AC%AC0%E5%9B%9E-twitter-hack--twtr_hack-%E3%81%AB%E9%81%8A%E3%81%B3%E3%81%AB%E8%A1%8C%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":1734},{"date":1330704840,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1330704840,"objectID":"10eb415a232ad4be7d05c57eb850036c","permalink":"https://blog.johtani.info/blog/2012/03/03/clean-coder%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A0/","publishdate":"2012-03-03T01:14:00+09:00","readingtime":3,"relpermalink":"/blog/2012/03/03/clean-coder%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A0/","section":"post","summary":"Clean Coder プロフェッショナルプログラマへの道 Clean Coderを読みました。 理由はTwitterで「Clean Code」がいい本だと流れてきたためです。","tags":["読書"],"title":"Clean Coderを読んだ(Jugemより移植)","type":"post","url":"/blog/2012/03/03/clean-coder%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A0/","weight":0,"wordcount":1021},{"date":1330186800,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1330186800,"objectID":"627a0c45dd07150343c81d856855590e","permalink":"https://blog.johtani.info/blog/2012/02/26/%E8%A6%AA%E5%AD%90%E3%81%A7%E6%A5%BD%E3%81%97%E3%82%81%E3%82%8B-%E7%B5%B5%E6%9C%AC%E3%81%A7%E8%8B%B1%E8%AA%9E%E3%82%92%E3%81%AF%E3%81%98%E3%82%81%E3%82%8B%E6%9C%AC/","publishdate":"2012-02-26T01:20:00+09:00","readingtime":2,"relpermalink":"/blog/2012/02/26/%E8%A6%AA%E5%AD%90%E3%81%A7%E6%A5%BD%E3%81%97%E3%82%81%E3%82%8B-%E7%B5%B5%E6%9C%AC%E3%81%A7%E8%8B%B1%E8%AA%9E%E3%82%92%E3%81%AF%E3%81%98%E3%82%81%E3%82%8B%E6%9C%AC/","section":"post","summary":"親子で楽しめる 絵本で英語をはじめる本 Twitterでこの本について書かれたブログ記事が流れてきて、購入しました。 最近、英語を身につけておいた","tags":["読書"],"title":"親子で楽しめる 絵本で英語をはじめる本(Jugemより移植)","type":"post","url":"/blog/2012/02/26/%E8%A6%AA%E5%AD%90%E3%81%A7%E6%A5%BD%E3%81%97%E3%82%81%E3%82%8B-%E7%B5%B5%E6%9C%AC%E3%81%A7%E8%8B%B1%E8%AA%9E%E3%82%92%E3%81%AF%E3%81%98%E3%82%81%E3%82%8B%E6%9C%AC/","weight":0,"wordcount":808},{"date":1330015800,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2800,"kind":"page","lang":"ja","lastmod":1330015800,"objectID":"966fe8d32b86121f8a465a21b95f7e5c","permalink":"https://blog.johtani.info/blog/2012/02/24/%E7%AC%AC4%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E3%83%8F%E3%83%AA%E3%82%A6%E3%83%83%E3%83%89--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-02-24T01:50:00+09:00","readingtime":6,"relpermalink":"/blog/2012/02/24/%E7%AC%AC4%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E3%83%8F%E3%83%AA%E3%82%A6%E3%83%83%E3%83%89--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"今週も勉強会に参加しました。 @yusukey さんが開催してるTwitter API勉強会です。 前回とは会場が異なりましたが、広くて大画面で良い会場でした。駅","tags":["勉強会"],"title":"第4回 Twitter API勉強会 @デジタルハリウッド #twtr_hack に参加しました。(Jugemより移植)","type":"post","url":"/blog/2012/02/24/%E7%AC%AC4%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E3%83%8F%E3%83%AA%E3%82%A6%E3%83%83%E3%83%89--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":2746},{"date":1329756060,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1329756060,"objectID":"4e7b945feca199bd486653fea1d0e39c","permalink":"https://blog.johtani.info/blog/2012/02/21/lucene-gosen%E3%81%A8synonymfilter%E3%82%92%E5%88%A9%E7%94%A8%E3%81%99%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AE%E6%B3%A8%E6%84%8F%E7%82%B9%E5%95%8F%E9%A1%8C%E7%82%B9%E7%B7%A8/","publishdate":"2012-02-21T01:41:00+09:00","readingtime":4,"relpermalink":"/blog/2012/02/21/lucene-gosen%E3%81%A8synonymfilter%E3%82%92%E5%88%A9%E7%94%A8%E3%81%99%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AE%E6%B3%A8%E6%84%8F%E7%82%B9%E5%95%8F%E9%A1%8C%E7%82%B9%E7%B7%A8/","section":"post","summary":"久々にlucene-gosenの話です。 しかも、あんまり嬉しくない話しです。 すでにissueをアップしていますが、lucene-gosenと","tags":["lucene-gosen"],"title":"lucene-gosenとSynonymFilterを利用するときの注意点（問題点編）(Jugemより移植)","type":"post","url":"/blog/2012/02/21/lucene-gosen%E3%81%A8synonymfilter%E3%82%92%E5%88%A9%E7%94%A8%E3%81%99%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AE%E6%B3%A8%E6%84%8F%E7%82%B9%E5%95%8F%E9%A1%8C%E7%82%B9%E7%B7%A8/","weight":0,"wordcount":1973},{"date":1328716980,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":3300,"kind":"page","lang":"ja","lastmod":1328716980,"objectID":"fa16213d24273d386d22332cd01ce774","permalink":"https://blog.johtani.info/blog/2012/02/09/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/","publishdate":"2012-02-09T01:03:00+09:00","readingtime":7,"relpermalink":"/blog/2012/02/09/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/","section":"post","summary":"また、勉強会ログです、すみません。。。 直接業務とは関係ないのですが、今回はリクルートの中野さんが話しをされるというので顔を出してきました。 も","tags":["勉強会"],"title":"Hadoopソースコードリーディング第8回に参加しました。#hadoopreading(Jugemより移植)","type":"post","url":"/blog/2012/02/09/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/","weight":0,"wordcount":3263},{"date":1328367780,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":7700,"kind":"page","lang":"ja","lastmod":1328367780,"objectID":"a2679a7d860a0bfb2645809ed92ce138","permalink":"https://blog.johtani.info/blog/2012/02/05/fluentd-meetup-japan%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-02-05T00:03:00+09:00","readingtime":16,"relpermalink":"/blog/2012/02/05/fluentd-meetup-japan%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"Fluentd meetup in Japanに参加しました。いつも面白そうな話を聞いてばっかりなので、役に立つためにスタッフとしても参加してみました。 まずは、会場が綺麗","tags":["勉強会"],"title":"Fluentd Meetup Japanに参加しました。(Jugemより移植)","type":"post","url":"/blog/2012/02/05/fluentd-meetup-japan%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":7610},{"date":1327596641,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1327596641,"objectID":"58e83fb33c120db338132d23b9112805","permalink":"https://blog.johtani.info/blog/2012/01/27/%E4%BB%8A%E8%88%88%E5%91%B3%E3%81%8C%E3%81%82%E3%82%8B%E3%81%93%E3%81%A8/","publishdate":"2012-01-27T01:50:41+09:00","readingtime":3,"relpermalink":"/blog/2012/01/27/%E4%BB%8A%E8%88%88%E5%91%B3%E3%81%8C%E3%81%82%E3%82%8B%E3%81%93%E3%81%A8/","section":"post","summary":"昨年末に今年の抱負について書いたのですが、 他にも興味あるものが増えたので備忘録＆公約？を兼ねてブログに書いておきます。 （興味あるものがあれば","tags":["備忘録"],"title":"今興味があること(Jugemより移植)","type":"post","url":"/blog/2012/01/27/%E4%BB%8A%E8%88%88%E5%91%B3%E3%81%8C%E3%81%82%E3%82%8B%E3%81%93%E3%81%A8/","weight":0,"wordcount":1374},{"date":1327593155,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":2200,"kind":"page","lang":"ja","lastmod":1327593155,"objectID":"c6dc6e6567d673436ac41ebc8e79a9ec","permalink":"https://blog.johtani.info/blog/2012/01/27/%E3%83%A2%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%8E%E3%83%AD%E3%82%B8%E3%83%BC2012-1%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-01-27T00:52:35+09:00","readingtime":5,"relpermalink":"/blog/2012/01/27/%E3%83%A2%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%8E%E3%83%AD%E3%82%B8%E3%83%BC2012-1%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"ということで、いつものように勉強会に参加したメモです。 http://atnd.org/events/23608 日時 :2012/01/26 19:00 to 22:00 会場 :アカデミーヒルズ(六本木ヒルズ内) 49階（タワーホールA） （港区六","tags":["勉強会"],"title":"モーショノロジー2012#1に参加しました。(Jugemより移植)","type":"post","url":"/blog/2012/01/27/%E3%83%A2%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%8E%E3%83%AD%E3%82%B8%E3%83%BC2012-1%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":2189},{"date":1326988680,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":3100,"kind":"page","lang":"ja","lastmod":1326988680,"objectID":"7198e10ebcf1bb88dc479b5c5b9f2c15","permalink":"https://blog.johtani.info/blog/2012/01/20/mapr%E4%B8%AD%E8%BA%AB%E8%AA%AC%E6%98%8E%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-01-20T00:58:00+09:00","readingtime":7,"relpermalink":"/blog/2012/01/20/mapr%E4%B8%AD%E8%BA%AB%E8%AA%AC%E6%98%8E%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"日時：2012/01/19 18:30-20:30 場所：ベルサール三田Room2シアター Inside MapR デモ＋内部のお話。 ・自己紹介 Susheel Kaushik 元YahooのHadoop系の人。製品","tags":["勉強会"],"title":"MapR中身説明会に参加しました。(Jugemより移植)","type":"post","url":"/blog/2012/01/20/mapr%E4%B8%AD%E8%BA%AB%E8%AA%AC%E6%98%8E%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":3086},{"date":1326941184,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":500,"kind":"page","lang":"ja","lastmod":1326941184,"objectID":"a4462529ab493676987d946019a14945","permalink":"https://blog.johtani.info/blog/2012/01/19/ossaj%E3%81%AE%E3%83%9F%E3%83%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%A7%E8%A9%B1%E3%81%97%E3%82%92%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-01-19T11:46:24+09:00","readingtime":1,"relpermalink":"/blog/2012/01/19/ossaj%E3%81%AE%E3%83%9F%E3%83%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%A7%E8%A9%B1%E3%81%97%E3%82%92%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"お久しぶりです。インフルエンザで一家全滅という最悪の状況に陥っていた我が家でした。 流行してるみたいなのでみなさんも気をつけてください。 さて、","tags":["勉強会"],"title":"OSSAJのミニセミナーで話しをしてきました(Jugemより移植)","type":"post","url":"/blog/2012/01/19/ossaj%E3%81%AE%E3%83%9F%E3%83%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%A7%E8%A9%B1%E3%81%97%E3%82%92%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":400},{"date":1326033660,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":600,"kind":"page","lang":"ja","lastmod":1326033660,"objectID":"f7df7b85af230b2623d3a827b0cbddd2","permalink":"https://blog.johtani.info/blog/2012/01/08/lucene-gosen%E3%81%AElucene-solr4-0%E5%AF%BE%E5%BF%9C%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%9B%B4%E6%96%B0/","publishdate":"2012-01-08T23:41:00+09:00","readingtime":2,"relpermalink":"/blog/2012/01/08/lucene-gosen%E3%81%AElucene-solr4-0%E5%AF%BE%E5%BF%9C%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%9B%B4%E6%96%B0/","section":"post","summary":"先日のSolr勉強会でLucene/Solr4.x系のlucene-gosenについて質問を受けていたのを忘れないように（年越しちゃいました","tags":["lucene-gosen"],"title":"lucene-gosenのLucene/Solr4.0対応ブランチ更新(Jugemより移植)","type":"post","url":"/blog/2012/01/08/lucene-gosen%E3%81%AElucene-solr4-0%E5%AF%BE%E5%BF%9C%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%9B%B4%E6%96%B0/","weight":0,"wordcount":561},{"date":1325735817,"dir":"post/2012/","expirydate":-62135596800,"fuzzywordcount":200,"kind":"page","lang":"ja","lastmod":1325735817,"objectID":"cc573488dec311655890a205aad4fb65","permalink":"https://blog.johtani.info/blog/2012/01/05/%E3%81%82%E3%81%91%E3%81%BE%E3%81%97%E3%81%A6%E3%81%8A%E3%82%81%E3%81%A7%E3%81%A8%E3%81%86%E3%81%94%E3%81%96%E3%81%84%E3%81%BE%E3%81%99%E4%BC%9A%E7%A4%BE%E3%81%AE%E3%83%96%E3%83%AD%E3%82%B0%E6%9B%B4%E6%96%B0/","publishdate":"2012-01-05T12:56:57+09:00","readingtime":1,"relpermalink":"/blog/2012/01/05/%E3%81%82%E3%81%91%E3%81%BE%E3%81%97%E3%81%A6%E3%81%8A%E3%82%81%E3%81%A7%E3%81%A8%E3%81%86%E3%81%94%E3%81%96%E3%81%84%E3%81%BE%E3%81%99%E4%BC%9A%E7%A4%BE%E3%81%AE%E3%83%96%E3%83%AD%E3%82%B0%E6%9B%B4%E6%96%B0/","section":"post","summary":"あけましておめでとうございます。（もう5日ですが。。。） 今年もlucene-gosenを中心に色々と記事を書いていきますので、ツッコミ、コメ","tags":["misc"],"title":"あけましておめでとうございます＋会社のブログ更新(Jugemより移植)","type":"post","url":"/blog/2012/01/05/%E3%81%82%E3%81%91%E3%81%BE%E3%81%97%E3%81%A6%E3%81%8A%E3%82%81%E3%81%A7%E3%81%A8%E3%81%86%E3%81%94%E3%81%96%E3%81%84%E3%81%BE%E3%81%99%E4%BC%9A%E7%A4%BE%E3%81%AE%E3%83%96%E3%83%AD%E3%82%B0%E6%9B%B4%E6%96%B0/","weight":0,"wordcount":190},{"date":1325006100,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1325006100,"objectID":"7164823f504286e3a762ee612ff0a988","permalink":"https://blog.johtani.info/blog/2011/12/28/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A0/","publishdate":"2011-12-28T02:15:00+09:00","readingtime":6,"relpermalink":"/blog/2011/12/28/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A0/","section":"post","summary":"他の方たちよりひと足はやいですが、今年の仕事が終わりました。 せっかくブログを始めたので、振り返りと来年の抱負など書いてみようかなと。 今年の振","tags":["misc"],"title":"今年の振り返りと来年の抱負？(Jugemより移植)","type":"post","url":"/blog/2011/12/28/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A0/","weight":0,"wordcount":2639},{"date":1324485660,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1324485660,"objectID":"da67e2f049b5b6babcf7906b85653399","permalink":"https://blog.johtani.info/blog/2011/12/22/%E7%AC%AC2-1%E5%9B%9E-twitter-api-%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%9D%B1%E4%BA%AC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-22T01:41:00+09:00","readingtime":4,"relpermalink":"/blog/2011/12/22/%E7%AC%AC2-1%E5%9B%9E-twitter-api-%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%9D%B1%E4%BA%AC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"@yusukeyさんにサインをもらう目的で勉強会に参加してきました。前回もらいそびれたのでｗ 残念ながら、まだTwitter APIを触ってない","tags":["勉強会"],"title":"第2.1回 Twitter API 勉強会 @東京に参加しました。(Jugemより移植)","type":"post","url":"/blog/2011/12/22/%E7%AC%AC2-1%E5%9B%9E-twitter-api-%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%9D%B1%E4%BA%AC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":1973},{"date":1324437339,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":200,"kind":"page","lang":"ja","lastmod":1324437339,"objectID":"584b2b145f362098fc5fc1e634d57de5","permalink":"https://blog.johtani.info/blog/2011/12/21/1-2-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-21T12:15:39+09:00","readingtime":1,"relpermalink":"/blog/2011/12/21/1-2-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"lucene-gosenの最新版（1.2.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、特定文字列で","tags":["lucene-gosen"],"title":"1.2.1リリースしました(Jugemより移植)","type":"post","url":"/blog/2011/12/21/1-2-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":140},{"date":1324311660,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2700,"kind":"page","lang":"ja","lastmod":1324311660,"objectID":"c6696a730f7498efb66f5ba3a8b35d08","permalink":"https://blog.johtani.info/blog/2011/12/20/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC%EF%BC%97%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F%E7%99%BA%E8%A1%A8%E3%82%82%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-20T01:21:00+09:00","readingtime":6,"relpermalink":"/blog/2011/12/20/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC%EF%BC%97%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F%E7%99%BA%E8%A1%A8%E3%82%82%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"いつものようにSolr勉強会に参加してきました。 皆勤賞を継続中です。（暇人というはなしも。。。） 今回は話しを聞きたいですねぇといったら、いや","tags":["勉強会"],"title":"Solr勉強会第７回に参加しました。（発表もしました）(Jugemより移植)","type":"post","url":"/blog/2011/12/20/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC%EF%BC%97%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F%E7%99%BA%E8%A1%A8%E3%82%82%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":2677},{"date":1323529475,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":4700,"kind":"page","lang":"ja","lastmod":1323529475,"objectID":"16fa0e4aefe18e1446bf6baefd3ba400","permalink":"https://blog.johtani.info/blog/2011/12/11/%E7%AC%AC2%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-11T00:04:35+09:00","readingtime":10,"relpermalink":"/blog/2011/12/11/%E7%AC%AC2%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"ということで、懲りずに#DSIRNLPに参加してきました。 基礎的な部分をおろそかにしたくないけど、TokyoNLPとかWebMiningでは","tags":[],"title":"第2回 データ構造と情報検索と言語処理勉強会に参加しました(Jugemより移植)","type":"post","url":"/blog/2011/12/11/%E7%AC%AC2%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":4675},{"date":1322668828,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1322668828,"objectID":"6e970d0818d58ff2d50c5bf037b1a565","permalink":"https://blog.johtani.info/blog/2011/12/01/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%95%E3%81%A8mac-mini2009late%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E3%81%A8%E3%81%9D%E3%81%AE%E4%BB%96%E3%81%8F%E3%81%A0%E3%82%89%E3%81%AA%E3%81%84%E8%A9%B1/","publishdate":"2011-12-01T01:00:28+09:00","readingtime":4,"relpermalink":"/blog/2011/12/01/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%95%E3%81%A8mac-mini2009late%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E3%81%A8%E3%81%9D%E3%81%AE%E4%BB%96%E3%81%8F%E3%81%A0%E3%82%89%E3%81%AA%E3%81%84%E8%A9%B1/","section":"post","summary":"ひさびさに、MBAのお話です。 セットアップといっても、物理的な方ですね。 以前、ケース（カバー）について記載しました。 この記事にも書いてあった","tags":["備忘録"],"title":"MBAセットアップ備忘録その５とMac Mini（2009late）セットアップとその他くだらない話(Jugemより移植)","type":"post","url":"/blog/2011/12/01/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%95%E3%81%A8mac-mini2009late%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E3%81%A8%E3%81%9D%E3%81%AE%E4%BB%96%E3%81%8F%E3%81%A0%E3%82%89%E3%81%AA%E3%81%84%E8%A9%B1/","weight":0,"wordcount":1993},{"date":1322542620,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":900,"kind":"page","lang":"ja","lastmod":1322542620,"objectID":"0ebe78077c8b48410cf52a0bccdff866","permalink":"https://blog.johtani.info/blog/2011/11/29/%E3%81%A9%E3%82%93%E3%81%AA%E6%9C%AC%E3%81%A7%E3%82%82%E5%A4%A7%E9%87%8F%E3%81%AB%E8%AA%AD%E3%82%81%E3%82%8B%E9%80%9F%E8%AA%AD%E3%81%AE%E6%9C%AC%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-29T13:57:00+09:00","readingtime":2,"relpermalink":"/blog/2011/11/29/%E3%81%A9%E3%82%93%E3%81%AA%E6%9C%AC%E3%81%A7%E3%82%82%E5%A4%A7%E9%87%8F%E3%81%AB%E8%AA%AD%E3%82%81%E3%82%8B%E9%80%9F%E8%AA%AD%E3%81%AE%E6%9C%AC%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"どんな本でも大量に読める「速読」の本 Twitterで知り合った方がこの本について書かれていたブログ記事を読んで興味を持ち、読みました。 書籍（","tags":["読書"],"title":"「どんな本でも大量に読める「速読」の本」を読みました(Jugemより移植)","type":"post","url":"/blog/2011/11/29/%E3%81%A9%E3%82%93%E3%81%AA%E6%9C%AC%E3%81%A7%E3%82%82%E5%A4%A7%E9%87%8F%E3%81%AB%E8%AA%AD%E3%82%81%E3%82%8B%E9%80%9F%E8%AA%AD%E3%81%AE%E6%9C%AC%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":832},{"date":1322499060,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":3800,"kind":"page","lang":"ja","lastmod":1322499060,"objectID":"924727b6f380cf3cdfe5650163e92054","permalink":"https://blog.johtani.info/blog/2011/11/29/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC7%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-29T01:51:00+09:00","readingtime":8,"relpermalink":"/blog/2011/11/29/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC7%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"Hadoopソースコードリーディング第7回に参加しました。 いつものごとく、自分用のメモをとっていたので。 第6回（2010/12）には参加して","tags":["勉強会"],"title":"Hadoopソースコードリーディング第7回に参加しました。(Jugemより移植)","type":"post","url":"/blog/2011/11/29/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC7%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":3734},{"date":1322244000,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2000,"kind":"page","lang":"ja","lastmod":1322244000,"objectID":"26d48d68b28f927bfebad454658f9425","permalink":"https://blog.johtani.info/blog/2011/11/26/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AElucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0%E3%81%8B%E3%82%894%E7%AB%A0/","publishdate":"2011-11-26T03:00:00+09:00","readingtime":4,"relpermalink":"/blog/2011/11/26/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AElucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0%E3%81%8B%E3%82%894%E7%AB%A0/","section":"post","summary":"先週末から勤労感謝の日まで風邪で寝こんでました。。。 みなさん、朝晩、冷え込みが激しいので風邪には気をつけてください。 季節の言葉も入れたので本","tags":["lucene-gosen"],"title":"「Apache Solr入門」のサンプルのlucene-gosen対応（1章から4章）(Jugemより移植)","type":"post","url":"/blog/2011/11/26/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AElucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0%E3%81%8B%E3%82%894%E7%AB%A0/","weight":0,"wordcount":1906},{"date":1321376880,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":3600,"kind":"page","lang":"ja","lastmod":1321376880,"objectID":"bda9a5da86ec9790262e14f953bbadcb","permalink":"https://blog.johtani.info/blog/2011/11/16/mongodb%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC7%E5%9B%9E%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-16T02:08:00+09:00","readingtime":8,"relpermalink":"/blog/2011/11/16/mongodb%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC7%E5%9B%9E%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"今回は、触ろうと思って触れていないMongoDBの勉強会に行って来ました。 2週連続の渋谷で、さすがに今回は出口をすんなりでれました。 今回は初","tags":["勉強会"],"title":"MongoDB勉強会（第7回）に行って来ました。(Jugemより移植)","type":"post","url":"/blog/2011/11/16/mongodb%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC7%E5%9B%9E%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":3524},{"date":1320822000,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1320822000,"objectID":"cc1a3b2f107510ac664e491d5f2412aa","permalink":"https://blog.johtani.info/blog/2011/11/09/splunk-live%E3%81%AE%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-09T16:00:00+09:00","readingtime":5,"relpermalink":"/blog/2011/11/09/splunk-live%E3%81%AE%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"Solr本の武田さんから教えていただいたSplunkの イベントに行って来ました。 Splunkとは様々な機器のログなどを一箇所に集めてリアルタ","tags":["misc"],"title":"Splunk Live!のイベントに行って来ました。(Jugemより移植)","type":"post","url":"/blog/2011/11/09/splunk-live%E3%81%AE%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":2492},{"date":1320724920,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1320724920,"objectID":"d9c6ab5c6630a4a84e242c5765103d2d","permalink":"https://blog.johtani.info/blog/2011/11/08/lucene-eurocon-2011-barcelona-%E3%81%AE%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%89%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-08T13:02:00+09:00","readingtime":5,"relpermalink":"/blog/2011/11/08/lucene-eurocon-2011-barcelona-%E3%81%AE%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%89%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"最近忘れやすいので、記録しておこうかと。 読んだスライドの簡単な内容と感想です。 ちなみに、スライドの一覧はこちらです。 ※スライドへのリンクはす","tags":["solr"],"title":"Lucene Eurocon 2011 Barcelona のスライド読みました(Jugemより移植)","type":"post","url":"/blog/2011/11/08/lucene-eurocon-2011-barcelona-%E3%81%AE%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%89%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":2336},{"date":1320225060,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1700,"kind":"page","lang":"ja","lastmod":1320225060,"objectID":"7a9609a971a8f31685e88da563eea5ce","permalink":"https://blog.johtani.info/blog/2011/11/02/bookscan%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-02T18:11:00+09:00","readingtime":4,"relpermalink":"/blog/2011/11/02/bookscan%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"Bookscanというサービスがあります。 書籍を電子化（PDF）して原本を破棄してくれるサービスです。 電子書籍にはずっと興味を持っていました","tags":["misc"],"title":"Bookscanを使ってみました(Jugemより移植)","type":"post","url":"/blog/2011/11/02/bookscan%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":1679},{"date":1320043560,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":200,"kind":"page","lang":"ja","lastmod":1320043560,"objectID":"14cf6e75aec1ead888e7101d3d94d28a","permalink":"https://blog.johtani.info/blog/2011/10/31/1-2-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2011-10-31T15:46:00+09:00","readingtime":1,"relpermalink":"/blog/2011/10/31/1-2-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","section":"post","summary":"lucene-gosenの最新版（1.2.0）をリリースしました。 プロジェクトページよりダウンロードが可能です。 新規追加機能についてはこちら","tags":["lucene-gosen"],"title":"1.2.0リリース(Jugemより移植)","type":"post","url":"/blog/2011/10/31/1-2-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","weight":0,"wordcount":113},{"date":1319559120,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2900,"kind":"page","lang":"ja","lastmod":1319559120,"objectID":"14a6d294550c9760aec57ba29682a750","permalink":"https://blog.johtani.info/blog/2011/10/26/%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%A4%96%E9%83%A8%E5%8C%96%E3%81%A8lucene-solr3-4%E5%AF%BE%E5%BF%9C/","publishdate":"2011-10-26T01:12:00+09:00","readingtime":6,"relpermalink":"/blog/2011/10/26/%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%A4%96%E9%83%A8%E5%8C%96%E3%81%A8lucene-solr3-4%E5%AF%BE%E5%BF%9C/","section":"post","summary":"すぐやりますと言いつつ、はや1ヶ月。。。 腰が重い、ダメエンジニアですね。。。 すみませんでした。。。 ようやくtrunkにコミットしました。 すぐ","tags":["lucene-gosen"],"title":"辞書の外部化とLucene/Solr3.4対応(Jugemより移植)","type":"post","url":"/blog/2011/10/26/%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%A4%96%E9%83%A8%E5%8C%96%E3%81%A8lucene-solr3-4%E5%AF%BE%E5%BF%9C/","weight":0,"wordcount":2803},{"date":1318922443,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":3300,"kind":"page","lang":"ja","lastmod":1318922443,"objectID":"5d827a1e8ea70edb11d946b54f076cae","permalink":"https://blog.johtani.info/blog/2011/10/18/jjug-ccc-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-10-18T16:20:43+09:00","readingtime":7,"relpermalink":"/blog/2011/10/18/jjug-ccc-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"JJUG CCC 2011 Fallに参加してきました。 個人的にはかなり久々のJavaのカンファレンスです。（※あくまで「Javaの」という話で。SolrやHad","tags":["備忘録"],"title":"JJUG CCC 2011 Fallに参加してきました。(Jugemより移植)","type":"post","url":"/blog/2011/10/18/jjug-ccc-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":3248},{"date":1318389420,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1700,"kind":"page","lang":"ja","lastmod":1318389420,"objectID":"b9d4f73fa7ca8ef66891554b66b2cded","permalink":"https://blog.johtani.info/blog/2011/10/12/lucene-gosen%E3%81%A7%E6%96%87%E7%AB%A0%E3%81%8B%E3%82%89%E3%82%AD%E3%83%BC%E3%83%AF%E3%83%BC%E3%83%89%E6%8A%BD%E5%87%BA%E3%82%A4%E3%83%AC%E3%82%AE%E3%83%A5%E3%83%A9%E3%83%BC/","publishdate":"2011-10-12T12:17:00+09:00","readingtime":4,"relpermalink":"/blog/2011/10/12/lucene-gosen%E3%81%A7%E6%96%87%E7%AB%A0%E3%81%8B%E3%82%89%E3%82%AD%E3%83%BC%E3%83%AF%E3%83%BC%E3%83%89%E6%8A%BD%E5%87%BA%E3%82%A4%E3%83%AC%E3%82%AE%E3%83%A5%E3%83%A9%E3%83%BC/","section":"post","summary":"昨日、文章から特定の単語（リストあり）を探したいという話を聞き、lucene-gosenでもできるねぇという話になりました。 まぁ、考えてみれ","tags":["lucene-gosen"],"title":"lucene-gosenで文章からキーワード抽出（イレギュラー？）(Jugemより移植)","type":"post","url":"/blog/2011/10/12/lucene-gosen%E3%81%A7%E6%96%87%E7%AB%A0%E3%81%8B%E3%82%89%E3%82%AD%E3%83%BC%E3%83%AF%E3%83%BC%E3%83%89%E6%8A%BD%E5%87%BA%E3%82%A4%E3%83%AC%E3%82%AE%E3%83%A5%E3%83%A9%E3%83%BC/","weight":0,"wordcount":1646},{"date":1317990120,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1317990120,"objectID":"dc962e34780f0374b7eb3d583f6d7eb6","permalink":"https://blog.johtani.info/blog/2011/10/07/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-1%E6%97%A5%E7%9B%AE/","publishdate":"2011-10-07T21:22:00+09:00","readingtime":5,"relpermalink":"/blog/2011/10/07/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-1%E6%97%A5%E7%9B%AE/","section":"post","summary":"ちょっと間があいてしまったが、ようやくIoの1日目を終了。 なれない感じの言語なので苦労しました。 今回もセルフスタディの私の回答が最後の方に記","tags":[],"title":"「7つの言語　7つの世界」 Io 1日目(Jugemより移植)","type":"post","url":"/blog/2011/10/07/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-1%E6%97%A5%E7%9B%AE/","weight":0,"wordcount":2433},{"date":1317968700,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1317968700,"objectID":"de1ab82817c0fb24e591b9a89a82f736","permalink":"https://blog.johtani.info/blog/2011/10/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%94/","publishdate":"2011-10-07T15:25:00+09:00","readingtime":3,"relpermalink":"/blog/2011/10/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%94/","section":"post","summary":"久々に、MBAの備忘録です。 あれから色々入れました。 なので、入れたソフトの一覧を追加。 AIR：TweetDeckをインストールするのに必要だ","tags":["備忘録"],"title":"MBAセットアップ備忘録その４(Jugemより移植)","type":"post","url":"/blog/2011/10/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%94/","weight":0,"wordcount":1476},{"date":1317811380,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1317811380,"objectID":"09677934e13a5d728f00c6ed7c8870a9","permalink":"https://blog.johtani.info/blog/2011/10/05/solr%E3%81%AE%E6%96%B0%E3%81%97%E3%81%84%E7%AE%A1%E7%90%86%E7%94%BB%E9%9D%A2solr4-x-trunk%E7%B3%BB/","publishdate":"2011-10-05T19:43:00+09:00","readingtime":4,"relpermalink":"/blog/2011/10/05/solr%E3%81%AE%E6%96%B0%E3%81%97%E3%81%84%E7%AE%A1%E7%90%86%E7%94%BB%E9%9D%A2solr4-x-trunk%E7%B3%BB/","section":"post","summary":"Lucene/SolrのMLでSolrの管理画面を新しくするというチケットが流れていたのでちょっと触って見ました。 ほんとにちょっと触っただけ","tags":["solr"],"title":"Solrの新しい管理画面（Solr4.x trunk系）(Jugemより移植)","type":"post","url":"/blog/2011/10/05/solr%E3%81%AE%E6%96%B0%E3%81%97%E3%81%84%E7%AE%A1%E7%90%86%E7%94%BB%E9%9D%A2solr4-x-trunk%E7%B3%BB/","weight":0,"wordcount":1508},{"date":1317720720,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":10300,"kind":"page","lang":"ja","lastmod":1317720720,"objectID":"7052598d2355984237d126afea2f6e88","permalink":"https://blog.johtani.info/blog/2011/10/04/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE2/","publishdate":"2011-10-04T18:32:00+09:00","readingtime":21,"relpermalink":"/blog/2011/10/04/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE2/","section":"post","summary":"遅くなりましたが、続きです。 さらに英語力のなさを痛感して凹んでいるところですが、何かの役に立てばと恥を晒すところです。。。 一応、訳してみたの","tags":["solr"],"title":"New SolrCloud Designの翻訳（その2）(Jugemより移植)","type":"post","url":"/blog/2011/10/04/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE2/","weight":0,"wordcount":10212},{"date":1317210300,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":3600,"kind":"page","lang":"ja","lastmod":1317210300,"objectID":"927612b57ba01ca878b2d7edce52a563","permalink":"https://blog.johtani.info/blog/2011/09/28/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE%EF%BC%91/","publishdate":"2011-09-28T20:45:00+09:00","readingtime":8,"relpermalink":"/blog/2011/09/28/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE%EF%BC%91/","section":"post","summary":"ちょっと興味があるので、訳してみました。（Wikiのページはこちら） 更新されているようなので、もとの文章も残しておきます。（ページ下部の続き","tags":["solr"],"title":"New SolrCloud Designの翻訳（その１）(Jugemより移植)","type":"post","url":"/blog/2011/09/28/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE%EF%BC%91/","weight":0,"wordcount":3516},{"date":1317113460,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":10000,"kind":"page","lang":"ja","lastmod":1317113460,"objectID":"97402287d8c6c03f0b63848e17e9d944","permalink":"https://blog.johtani.info/blog/2011/09/27/hadoop-conference-japan-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-09-27T17:51:00+09:00","readingtime":20,"relpermalink":"/blog/2011/09/27/hadoop-conference-japan-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"Hadoop Conference Japan 2011 Fallに行ってきました。 まずは、ユーザ会の方々、運営の方々、発表された方々お疲れ様でした。こんな機会を用意していただき、ありがとう","tags":["hadoop"],"title":"Hadoop Conference Japan 2011 Fallに参加してきました。(Jugemより移植)","type":"post","url":"/blog/2011/09/27/hadoop-conference-japan-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":9985},{"date":1316716440,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1316716440,"objectID":"62f31128a21b0e240bdb7b3d5b121c04","permalink":"https://blog.johtani.info/blog/2011/09/23/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-0%E6%97%A5%E7%9B%AE/","publishdate":"2011-09-23T03:34:00+09:00","readingtime":3,"relpermalink":"/blog/2011/09/23/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-0%E6%97%A5%E7%9B%AE/","section":"post","summary":"台風15号すごかったですね。幸いにも（？）夏休みだったので、通勤などでひどい目に合わずにすみました。 風雨はすごくてちょっと怖かったですが。。","tags":["読書"],"title":"「7つの言語　7つの世界」 Io 0日目(Jugemより移植)","type":"post","url":"/blog/2011/09/23/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-0%E6%97%A5%E7%9B%AE/","weight":0,"wordcount":1386},{"date":1316046660,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":300,"kind":"page","lang":"ja","lastmod":1316046660,"objectID":"54da1b916f49ef40c822fab61d37cf66","permalink":"https://blog.johtani.info/blog/2011/09/15/lucene-solr-3-4%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/","publishdate":"2011-09-15T09:31:00+09:00","readingtime":1,"relpermalink":"/blog/2011/09/15/lucene-solr-3-4%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/","section":"post","summary":"Solr/Lucene 3.4がリリースされました。（速報） 以下、各サイトへのリンクです。 Solrリリースのお知らせ Luceneリリースのお知らせ ちなみに、先日の","tags":["solr"],"title":"Lucene/Solr 3.4リリース（速報）(Jugemより移植)","type":"post","url":"/blog/2011/09/15/lucene-solr-3-4%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/","weight":0,"wordcount":252},{"date":1315992060,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1315992060,"objectID":"41b811063b9425de1934e77d89118022","permalink":"https://blog.johtani.info/blog/2011/09/14/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-3%E6%97%A5%E7%9B%AE%E6%9C%80%E7%B5%82%E6%97%A5/","publishdate":"2011-09-14T18:21:00+09:00","readingtime":4,"relpermalink":"/blog/2011/09/14/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-3%E6%97%A5%E7%9B%AE%E6%9C%80%E7%B5%82%E6%97%A5/","section":"post","summary":"ということで、Rubyの最終日の感想。 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大","tags":["読書"],"title":"「7つの言語　7つの世界」 Ruby 3日目（最終日）(Jugemより移植)","type":"post","url":"/blog/2011/09/14/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-3%E6%97%A5%E7%9B%AE%E6%9C%80%E7%B5%82%E6%97%A5/","weight":0,"wordcount":1583},{"date":1315810980,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":6300,"kind":"page","lang":"ja","lastmod":1315810980,"objectID":"37b622eaad1f79e759a722aacebf48ec","permalink":"https://blog.johtani.info/blog/2011/09/12/%E7%AC%AC6%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-09-12T16:03:00+09:00","readingtime":13,"relpermalink":"/blog/2011/09/12/%E7%AC%AC6%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"「第6回Solr勉強会」に参加しました。 なんだかんだと第6回で、今のところ皆勤賞です。 ということで、主に自分用ですが、メモなどとったので。 概","tags":["勉強会"],"title":"第6回Solr勉強会に参加しました。(Jugemより移植)","type":"post","url":"/blog/2011/09/12/%E7%AC%AC6%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":6272},{"date":1315588260,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":3700,"kind":"page","lang":"ja","lastmod":1315588260,"objectID":"73262345214f9b7794f2cc4a612b15e8","permalink":"https://blog.johtani.info/blog/2011/09/10/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-2%E6%97%A5%E7%9B%AE/","publishdate":"2011-09-10T02:11:00+09:00","readingtime":8,"relpermalink":"/blog/2011/09/10/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-2%E6%97%A5%E7%9B%AE/","section":"post","summary":"ということで、Ruby2日目の感想（2日目だけで2日間かかったのは内緒。。。） 今回もセルフスタディの私の回答が最後の方に記載されてます。見た","tags":["読書"],"title":"「7つの言語　7つの世界」 Ruby 2日目(Jugemより移植)","type":"post","url":"/blog/2011/09/10/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-2%E6%97%A5%E7%9B%AE/","weight":0,"wordcount":3673},{"date":1315545120,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2400,"kind":"page","lang":"ja","lastmod":1315545120,"objectID":"9baedcd033169611a42c3cfd58b3ae03","permalink":"https://blog.johtani.info/blog/2011/09/09/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-1%E6%97%A5%E7%9B%AE/","publishdate":"2011-09-09T14:12:00+09:00","readingtime":5,"relpermalink":"/blog/2011/09/09/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-1%E6%97%A5%E7%9B%AE/","section":"post","summary":"実に3年ぶりくらいにゆっくりできる日々が訪れたので、積読状態の本を消化しようと「7つの言語 7つの世界」を読み始めました。 せっかくブログも始め","tags":["読書"],"title":"「7つの言語　7つの世界」 Ruby 1日目(Jugemより移植)","type":"post","url":"/blog/2011/09/09/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-1%E6%97%A5%E7%9B%AE/","weight":0,"wordcount":2375},{"date":1315329480,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1315329480,"objectID":"f23ca2aa066b1ee0fa4df1f2f865be4c","permalink":"https://blog.johtani.info/blog/2011/09/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%93/","publishdate":"2011-09-07T02:18:00+09:00","readingtime":2,"relpermalink":"/blog/2011/09/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%93/","section":"post","summary":"現在の出先でMBAを使えないので、なかなか進んでいないMBAのセットアップです。。。 とりあえず、Eclipse、homebrewをインストー","tags":["備忘録"],"title":"MBAセットアップ備忘録その３(Jugemより移植)","type":"post","url":"/blog/2011/09/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%93/","weight":0,"wordcount":930},{"date":1315328188,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":500,"kind":"page","lang":"ja","lastmod":1315328188,"objectID":"3c2523e65ff953fd73579aaaf5d7ce36","permalink":"https://blog.johtani.info/blog/2011/09/07/%E8%BE%9E%E6%9B%B8%E5%88%86%E9%9B%A2%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E3%82%B1%E3%83%BC%E3%82%B9%E8%BF%BD%E5%8A%A0%E3%81%A8%E6%AE%8B%E3%82%BF%E3%82%B9%E3%82%AF/","publishdate":"2011-09-07T01:56:28+09:00","readingtime":1,"relpermalink":"/blog/2011/09/07/%E8%BE%9E%E6%9B%B8%E5%88%86%E9%9B%A2%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E3%82%B1%E3%83%BC%E3%82%B9%E8%BF%BD%E5%8A%A0%E3%81%A8%E6%AE%8B%E3%82%BF%E3%82%B9%E3%82%AF/","section":"post","summary":"すぐにテストケース追加しますといいつつ、はや一週間。 ようやく仕事が落ち着いたので、テストケースを追記しました。まだパッチの段階です。 一応、異","tags":["lucene-gosen"],"title":"辞書分離のテストケース追加と残タスク(Jugemより移植)","type":"post","url":"/blog/2011/09/07/%E8%BE%9E%E6%9B%B8%E5%88%86%E9%9B%A2%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E3%82%B1%E3%83%BC%E3%82%B9%E8%BF%BD%E5%8A%A0%E3%81%A8%E6%AE%8B%E3%82%BF%E3%82%B9%E3%82%AF/","weight":0,"wordcount":454},{"date":1314668040,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1314668040,"objectID":"88a8e608108be939da9aab5a9a8af7d1","permalink":"https://blog.johtani.info/blog/2011/08/30/%E8%A4%87%E6%95%B0%E8%BE%9E%E6%9B%B8%E3%81%AE%E8%AA%AD%E3%81%BF%E8%BE%BC%E3%81%BF%E6%A9%9F%E8%83%BD%E8%BF%BD%E5%8A%A0%E4%BB%AE/","publishdate":"2011-08-30T10:34:00+09:00","readingtime":3,"relpermalink":"/blog/2011/08/30/%E8%A4%87%E6%95%B0%E8%BE%9E%E6%9B%B8%E3%81%AE%E8%AA%AD%E3%81%BF%E8%BE%BC%E3%81%BF%E6%A9%9F%E8%83%BD%E8%BF%BD%E5%8A%A0%E4%BB%AE/","section":"post","summary":"先日、辞書のjarファイルからの分離についてパッチと記事を書きました。 IssueにあげていたパッチをRobertさんが見ていたらしく、次のよ","tags":["lucene-gosen"],"title":"複数辞書の読み込み機能追加（仮）(Jugemより移植)","type":"post","url":"/blog/2011/08/30/%E8%A4%87%E6%95%B0%E8%BE%9E%E6%9B%B8%E3%81%AE%E8%AA%AD%E3%81%BF%E8%BE%BC%E3%81%BF%E6%A9%9F%E8%83%BD%E8%BF%BD%E5%8A%A0%E4%BB%AE/","weight":0,"wordcount":1034},{"date":1314062760,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1800,"kind":"page","lang":"ja","lastmod":1314062760,"objectID":"2f1ec795216d5bafa33a810af3421942","permalink":"https://blog.johtani.info/blog/2011/08/23/%E8%BE%9E%E6%9B%B8%E3%81%AEjar%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%8B%E3%82%89%E3%81%AE%E5%88%86%E9%9B%A2/","publishdate":"2011-08-23T10:26:00+09:00","readingtime":4,"relpermalink":"/blog/2011/08/23/%E8%BE%9E%E6%9B%B8%E3%81%AEjar%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%8B%E3%82%89%E3%81%AE%E5%88%86%E9%9B%A2/","section":"post","summary":"ひさびさに、lucene-gosenの話題です。 lucene-gosenはjarファイルに辞書も同梱されており、jarファイルをクラスパスに","tags":["lucene-gosen"],"title":"辞書のjarファイルからの分離(Jugemより移植)","type":"post","url":"/blog/2011/08/23/%E8%BE%9E%E6%9B%B8%E3%81%AEjar%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%8B%E3%82%89%E3%81%AE%E5%88%86%E9%9B%A2/","weight":0,"wordcount":1747},{"date":1313369460,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1313369460,"objectID":"ce0aea06d44878b4a373efe090a66a62","permalink":"https://blog.johtani.info/blog/2011/08/15/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%92/","publishdate":"2011-08-15T09:51:00+09:00","readingtime":3,"relpermalink":"/blog/2011/08/15/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%92/","section":"post","summary":"すみません、また、MBA関連の記事になってしまいました。 ということで、備忘録その２です。 前回からいくつかインストールや環境の設定をしたので、","tags":["備忘録"],"title":"MBAセットアップ備忘録その２(Jugemより移植)","type":"post","url":"/blog/2011/08/15/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%92/","weight":0,"wordcount":1263},{"date":1312904760,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1400,"kind":"page","lang":"ja","lastmod":1312904760,"objectID":"c0e423f9ac41cc5b265c95a3e97e3fcb","permalink":"https://blog.johtani.info/blog/2011/08/10/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2/","publishdate":"2011-08-10T00:46:00+09:00","readingtime":3,"relpermalink":"/blog/2011/08/10/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2/","section":"post","summary":"Mac Book Airのセットアップ関連の備忘録 （今回は備忘録なので、文体も変かも） インストールしたもの（順不同）だいたい、このサイトを参考にした。 Evernote Dropbox","tags":["備忘録"],"title":"MBAセットアップ備忘録(Jugemより移植)","type":"post","url":"/blog/2011/08/10/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2/","weight":0,"wordcount":1365},{"date":1312389240,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1312389240,"objectID":"7ed1d2efa3e0f0ed6b77eb4eff3d86b3","permalink":"https://blog.johtani.info/blog/2011/08/04/apple%E6%95%99%E3%81%AB%E5%85%A5%E4%BF%A1%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-08-04T01:34:00+09:00","readingtime":3,"relpermalink":"/blog/2011/08/04/apple%E6%95%99%E3%81%AB%E5%85%A5%E4%BF%A1%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"個人用のPCを８年ぶりに新調しました。 前回購入した家のデスクトップPCがもう８年ものになりつつあるということで、 さすがに今年はPCを買おうと","tags":["備忘録"],"title":"Apple教に入信しました(Jugemより移植)","type":"post","url":"/blog/2011/08/04/apple%E6%95%99%E3%81%AB%E5%85%A5%E4%BF%A1%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":1407},{"date":1311737580,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":4900,"kind":"page","lang":"ja","lastmod":1311737580,"objectID":"3811b40721f7ca651887aac4eb17f9f0","permalink":"https://blog.johtani.info/blog/2011/07/27/%E7%AC%AC1%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-07-27T12:33:00+09:00","readingtime":10,"relpermalink":"/blog/2011/07/27/%E7%AC%AC1%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"かなり遅くなりましたが、第1回 データ構造と情報検索と言語処理勉強会 #DSIRNLPに参加しました。 帰ってから２日半ほど寝込んでしまい、更新が","tags":["勉強会"],"title":"第1回 データ構造と情報検索と言語処理勉強会に参加しました。(Jugemより移植)","type":"post","url":"/blog/2011/07/27/%E7%AC%AC1%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":4841},{"date":1311132540,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1300,"kind":"page","lang":"ja","lastmod":1311132540,"objectID":"5a765f9668608a39333fa90cf462657e","permalink":"https://blog.johtani.info/blog/2011/07/20/kuromoji%E3%82%92%E8%AA%BF%E3%81%B9%E3%81%A6%E3%81%BF%E3%81%9F/","publishdate":"2011-07-20T12:29:00+09:00","readingtime":3,"relpermalink":"/blog/2011/07/20/kuromoji%E3%82%92%E8%AA%BF%E3%81%B9%E3%81%A6%E3%81%BF%E3%81%9F/","section":"post","summary":"以前から春山さんのブログ（リンク）や勉強会で耳にはしていたのですがソースは読んでいませんでした。 先日、Luceneにcontributeされ","tags":["形態素解析"],"title":"Kuromojiを調べてみた(Jugemより移植)","type":"post","url":"/blog/2011/07/20/kuromoji%E3%82%92%E8%AA%BF%E3%81%B9%E3%81%A6%E3%81%BF%E3%81%9F/","weight":0,"wordcount":1219},{"date":1310432760,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1500,"kind":"page","lang":"ja","lastmod":1310432760,"objectID":"c70b78fd0b5dffcd38322355e9c2471e","permalink":"https://blog.johtani.info/blog/2011/07/12/naist-jdic-for-mecab%E3%81%AEpreprocessor%E3%81%AE%E5%AE%9F%E8%A3%85%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E5%82%99%E5%BF%98%E9%8C%B2/","publishdate":"2011-07-12T10:06:00+09:00","readingtime":3,"relpermalink":"/blog/2011/07/12/naist-jdic-for-mecab%E3%81%AEpreprocessor%E3%81%AE%E5%AE%9F%E8%A3%85%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E5%82%99%E5%BF%98%E9%8C%B2/","section":"post","summary":"忘れてしまうので、備忘録を残しておきます。 一応、ソースには少しずつコメントをいれてはいるのですが。 私は残念ながら、自然言語処理は初心者に毛が","tags":["lucene-gosen"],"title":"NAIST-JDic for MeCabのPreprocessorの実装に関する備忘録(Jugemより移植)","type":"post","url":"/blog/2011/07/12/naist-jdic-for-mecab%E3%81%AEpreprocessor%E3%81%AE%E5%AE%9F%E8%A3%85%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E5%82%99%E5%BF%98%E9%8C%B2/","weight":0,"wordcount":1464},{"date":1309777240,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":100,"kind":"page","lang":"ja","lastmod":1309777240,"objectID":"229975f1e84b5088e819cd5f2dc43080","permalink":"https://blog.johtani.info/blog/2011/07/04/lucene-gosen-1-1-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2011-07-04T20:00:40+09:00","readingtime":1,"relpermalink":"/blog/2011/07/04/lucene-gosen-1-1-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","section":"post","summary":"lucene-gosen 1.1.1をリリースしました。 先日お知らせしたバグ修正を取り込んだjarを用意いしました。 ダウンロードはこちらから","tags":["lucene-gosen"],"title":"lucene-gosen 1.1.1リリース(Jugemより移植)","type":"post","url":"/blog/2011/07/04/lucene-gosen-1-1-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","weight":0,"wordcount":58},{"date":1309501779,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":100,"kind":"page","lang":"ja","lastmod":1309501779,"objectID":"10eb1e7dc64d8ca3dad92641dadb5de7","permalink":"https://blog.johtani.info/blog/2011/07/01/lucene-solr-3-3%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/","publishdate":"2011-07-01T15:29:39+09:00","readingtime":1,"relpermalink":"/blog/2011/07/01/lucene-solr-3-3%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/","section":"post","summary":"Solr/Lucene 3.3がリリースされました。（速報） 以下、各サイトへのリンクです。 Solrリリースのお知らせ Luceneリリースのお知らせ リリースのタイミ","tags":["solr"],"title":"Lucene/Solr 3.3リリース（速報）(Jugemより移植)","type":"post","url":"/blog/2011/07/01/lucene-solr-3-3%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/","weight":0,"wordcount":86},{"date":1309356600,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":5100,"kind":"page","lang":"ja","lastmod":1309356600,"objectID":"49ba23148db9effdc3979aa0fe5876ea","permalink":"https://blog.johtani.info/blog/2011/06/29/hadoop%E3%82%92%E4%B8%AD%E5%BF%83%E3%81%A8%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E7%92%B0%E5%A2%83%E3%81%A7%E3%81%AE%E9%96%8B%E7%99%BA%E6%96%B9%E6%B3%95%E8%AB%96%E3%83%A2%E3%83%87%E3%83%AA%E3%83%B3%E3%82%B0%E8%A8%AD%E8%A8%88%E6%89%8B%E6%B3%95%E7%AD%89%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E5%BA%A7%E8%AB%87%E4%BC%9A-%E7%AC%AC5%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-06-29T23:10:00+09:00","readingtime":11,"relpermalink":"/blog/2011/06/29/hadoop%E3%82%92%E4%B8%AD%E5%BF%83%E3%81%A8%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E7%92%B0%E5%A2%83%E3%81%A7%E3%81%AE%E9%96%8B%E7%99%BA%E6%96%B9%E6%B3%95%E8%AB%96%E3%83%A2%E3%83%87%E3%83%AA%E3%83%B3%E3%82%B0%E8%A8%AD%E8%A8%88%E6%89%8B%E6%B3%95%E7%AD%89%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E5%BA%A7%E8%AB%87%E4%BC%9A-%E7%AC%AC5%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","section":"post","summary":"「Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）」に参加しました。300名入るイベントルー","tags":["hadoop"],"title":"Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）に参加しました。(Jugemより移植)","type":"post","url":"/blog/2011/06/29/hadoop%E3%82%92%E4%B8%AD%E5%BF%83%E3%81%A8%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E7%92%B0%E5%A2%83%E3%81%A7%E3%81%AE%E9%96%8B%E7%99%BA%E6%96%B9%E6%B3%95%E8%AB%96%E3%83%A2%E3%83%87%E3%83%AA%E3%83%B3%E3%82%B0%E8%A8%AD%E8%A8%88%E6%89%8B%E6%B3%95%E7%AD%89%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E5%BA%A7%E8%AB%87%E4%BC%9A-%E7%AC%AC5%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","weight":0,"wordcount":5050},{"date":1309232160,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":400,"kind":"page","lang":"ja","lastmod":1309232160,"objectID":"f6dff70097776e24c2a7c9c0f2514f79","permalink":"https://blog.johtani.info/blog/2011/06/28/compositeposcompositetokenfilter%E3%81%AE%E3%83%90%E3%82%B0%E4%BF%AE%E6%AD%A3/","publishdate":"2011-06-28T12:36:00+09:00","readingtime":1,"relpermalink":"/blog/2011/06/28/compositeposcompositetokenfilter%E3%81%AE%E3%83%90%E3%82%B0%E4%BF%AE%E6%AD%A3/","section":"post","summary":"以前、こちらで話題に上がっていた「未知語」に関するcompositePOSのエラーの件を調査しました。（Twitterでも流れてました。） 次","tags":["lucene-gosen"],"title":"compositePOS（CompositeTokenFilter）のバグ修正(Jugemより移植)","type":"post","url":"/blog/2011/06/28/compositeposcompositetokenfilter%E3%81%AE%E3%83%90%E3%82%B0%E4%BF%AE%E6%AD%A3/","weight":0,"wordcount":310},{"date":1308609480,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1000,"kind":"page","lang":"ja","lastmod":1308609480,"objectID":"991285e3967c3295b4ff2dcd835f7c61","permalink":"https://blog.johtani.info/blog/2011/06/21/naist-jdic-for-mecab%E5%AF%BE%E5%BF%9C%E7%89%88%E4%BB%AE%E5%AE%9F%E8%A3%85/","publishdate":"2011-06-21T07:38:00+09:00","readingtime":2,"relpermalink":"/blog/2011/06/21/naist-jdic-for-mecab%E5%AF%BE%E5%BF%9C%E7%89%88%E4%BB%AE%E5%AE%9F%E8%A3%85/","section":"post","summary":"lucene-gosenのtrunkbranches/impl-mecab-dicにNAIST-JDic for MeCabの辞書を利用出来るPre","tags":["lucene-gosen"],"title":"NAIST-JDic for MeCab対応版（仮実装）(Jugemより移植)","type":"post","url":"/blog/2011/06/21/naist-jdic-for-mecab%E5%AF%BE%E5%BF%9C%E7%89%88%E4%BB%AE%E5%AE%9F%E8%A3%85/","weight":0,"wordcount":977},{"date":1307977200,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1600,"kind":"page","lang":"ja","lastmod":1307977200,"objectID":"50f43b1726cf61066ef8656477b226be","permalink":"https://blog.johtani.info/blog/2011/06/14/compositepos%E3%81%AE%E5%88%A9%E7%94%A8%E4%BE%8Bnaist-chasen%E3%81%A7%E3%81%AE%E8%8B%B1%E5%8D%98%E8%AA%9E%E3%81%AE%E5%87%BA%E5%8A%9B%E6%96%B9%E6%B3%95%E4%BE%8B/","publishdate":"2011-06-14T00:00:00+09:00","readingtime":4,"relpermalink":"/blog/2011/06/14/compositepos%E3%81%AE%E5%88%A9%E7%94%A8%E4%BE%8Bnaist-chasen%E3%81%A7%E3%81%AE%E8%8B%B1%E5%8D%98%E8%AA%9E%E3%81%AE%E5%87%BA%E5%8A%9B%E6%96%B9%E6%B3%95%E4%BE%8B/","section":"post","summary":"前回、naist-chasenではアルファベットが別々の単語としてanalyzeされてしまうという話をしました。 ただ、これだと、英単語が含ま","tags":["lucene-gosen"],"title":"compositePOSの利用例（naist-chasenでの英単語の出力方法例）(Jugemより移植)","type":"post","url":"/blog/2011/06/14/compositepos%E3%81%AE%E5%88%A9%E7%94%A8%E4%BE%8Bnaist-chasen%E3%81%A7%E3%81%AE%E8%8B%B1%E5%8D%98%E8%AA%9E%E3%81%AE%E5%87%BA%E5%8A%9B%E6%96%B9%E6%B3%95%E4%BE%8B/","weight":0,"wordcount":1509},{"date":1307934480,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":300,"kind":"page","lang":"ja","lastmod":1307934480,"objectID":"eeef60efe889349870426d10edc694be","permalink":"https://blog.johtani.info/blog/2011/06/13/lucene-gosen-1-1-0-%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2011-06-13T12:08:00+09:00","readingtime":1,"relpermalink":"/blog/2011/06/13/lucene-gosen-1-1-0-%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","section":"post","summary":"lucene-gosenの1.1.0がリリースされました。 大きな目玉はJapaneseTokenizerが出力する形態素に関するデータを遅延","tags":["lucene-gosen"],"title":"lucene-gosen 1.1.0 リリース(Jugemより移植)","type":"post","url":"/blog/2011/06/13/lucene-gosen-1-1-0-%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","weight":0,"wordcount":214},{"date":1307344980,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1200,"kind":"page","lang":"ja","lastmod":1307344980,"objectID":"4b046ac6a4796fb1338f0481dbd4003d","permalink":"https://blog.johtani.info/blog/2011/06/06/lucene-gosen%E3%81%AEtokenfilter%E3%81%9F%E3%81%A1/","publishdate":"2011-06-06T16:23:00+09:00","readingtime":3,"relpermalink":"/blog/2011/06/06/lucene-gosen%E3%81%AEtokenfilter%E3%81%9F%E3%81%A1/","section":"post","summary":"lucene-gosenをSolr/Luceneで利用する場合、TokenFilterを利用してTokenizerが出力したToken対して","tags":["lucene-gosen"],"title":"lucene-gosenのTokenFilterたち(Jugemより移植)","type":"post","url":"/blog/2011/06/06/lucene-gosen%E3%81%AEtokenfilter%E3%81%9F%E3%81%A1/","weight":0,"wordcount":1118},{"date":1307002560,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":2500,"kind":"page","lang":"ja","lastmod":1307002560,"objectID":"b2621497b3313c97855ed951f0d9b291","permalink":"https://blog.johtani.info/blog/2011/06/02/%E8%BE%9E%E6%9B%B8%E3%81%A8%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E8%BE%9E%E6%9B%B8%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2011-06-02T17:16:00+09:00","readingtime":5,"relpermalink":"/blog/2011/06/02/%E8%BE%9E%E6%9B%B8%E3%81%A8%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E8%BE%9E%E6%9B%B8%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","section":"post","summary":"辞書の特性について 現在lucene-gosenでは以下の2つの辞書が利用可能です。 簡単に違いについて説明します。 IPAdicの辞書について バ","tags":["lucene-gosen"],"title":"辞書とカスタム辞書について(Jugemより移植)","type":"post","url":"/blog/2011/06/02/%E8%BE%9E%E6%9B%B8%E3%81%A8%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E8%BE%9E%E6%9B%B8%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","weight":0,"wordcount":2405},{"date":1306398840,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":1100,"kind":"page","lang":"ja","lastmod":1306398840,"objectID":"ff1441a42144a7de9a3eaf9f5e7cfea9","permalink":"https://blog.johtani.info/blog/2011/05/26/%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%8B%E3%82%89%E3%81%AE%E3%83%93%E3%83%AB%E3%83%89%E3%81%A8%E6%A7%8B%E6%88%90/","publishdate":"2011-05-26T17:34:00+09:00","readingtime":3,"relpermalink":"/blog/2011/05/26/%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%8B%E3%82%89%E3%81%AE%E3%83%93%E3%83%AB%E3%83%89%E3%81%A8%E6%A7%8B%E6%88%90/","section":"post","summary":"今回はソースのダウンロードとビルドについてです。 最新版のソースを利用したり、JavaDocを見たい場合はソースをダウンロードしてからビルドす","tags":["lucene-gosen"],"title":"ソースからのビルドと構成(Jugemより移植)","type":"post","url":"/blog/2011/05/26/%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%8B%E3%82%89%E3%81%AE%E3%83%93%E3%83%AB%E3%83%89%E3%81%A8%E6%A7%8B%E6%88%90/","weight":0,"wordcount":1046},{"date":1306130400,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":600,"kind":"page","lang":"ja","lastmod":1306130400,"objectID":"5988b62a0c0785a303b77c74608e8b55","permalink":"https://blog.johtani.info/blog/2011/05/23/lucene-gosen%E3%81%A8%E3%81%AF/","publishdate":"2011-05-23T15:00:00+09:00","readingtime":2,"relpermalink":"/blog/2011/05/23/lucene-gosen%E3%81%A8%E3%81%AF/","section":"post","summary":"概要： Lucene/SolrのコミッターであるRobert Muirさんが始めたプロジェクト 歴史： MeCabのJava移植版としてスタートした","tags":["lucene-gosen"],"title":"lucene-gosenとは(Jugemより移植)","type":"post","url":"/blog/2011/05/23/lucene-gosen%E3%81%A8%E3%81%AF/","weight":0,"wordcount":542},{"date":1305859440,"dir":"post/2011/","expirydate":-62135596800,"fuzzywordcount":200,"kind":"page","lang":"ja","lastmod":1305859440,"objectID":"94b85ba716dbb7c20b230e69248b8208","permalink":"https://blog.johtani.info/blog/2011/05/20/%E3%83%96%E3%83%AD%E3%82%B0%E3%81%AF%E3%81%98%E3%82%81%E3%81%BE%E3%81%99/","publishdate":"2011-05-20T11:44:00+09:00","readingtime":1,"relpermalink":"/blog/2011/05/20/%E3%83%96%E3%83%AD%E3%82%B0%E3%81%AF%E3%81%98%E3%82%81%E3%81%BE%E3%81%99/","section":"post","summary":"今さらですが、ブログをはじめてみようかと。今さらですが… はじめてみようと思った一番の理由は、自分で調べたことをメモがわりに残すためです。 あと","tags":["misc"],"title":"ブログはじめます(Jugemより移植)","type":"post","url":"/blog/2011/05/20/%E3%83%96%E3%83%AD%E3%82%B0%E3%81%AF%E3%81%98%E3%82%81%E3%81%BE%E3%81%99/","weight":0,"wordcount":162}]
\ No newline at end of file
diff --git a/atom.xml b/atom.xml
index 1ca337447f..507d2caba1 100644
--- a/atom.xml
+++ b/atom.xml
@@ -7,7 +7,61 @@
     <description>Recent content on @johtaniの日記 3rd</description>
     <generator>Hugo -- gohugo.io</generator>
     <language>ja</language>
-    <lastBuildDate>Sun, 31 Dec 2023 07:49:21 +0000</lastBuildDate><atom:link href="https://blog.johtani.info/index.xml" rel="self" type="application/rss+xml" />
+    <lastBuildDate>Thu, 25 Jan 2024 09:30:53 +0000</lastBuildDate><atom:link href="https://blog.johtani.info/index.xml" rel="self" type="application/rss+xml" />
+    <item>
+      <title>kagome-botのユーザーサービス化</title>
+      <link>https://blog.johtani.info/blog/2024/01/25/kagome-bot-as-a-user-service/</link>
+      <pubDate>Thu, 25 Jan 2024 09:30:53 +0000</pubDate>
+      
+      <guid>https://blog.johtani.info/blog/2024/01/25/kagome-bot-as-a-user-service/</guid>
+      <description>日常でよく、形態素解析したくなることがありますよね？ そして、Slackも日常的に立ち上がってますよね？ ということは、Slackのボットとして</description>
+      <content:encoded>&lt;p&gt;日常でよく、形態素解析したくなることがありますよね？
+そして、Slackも日常的に立ち上がってますよね？
+ということは、Slackのボットとして常駐してもらえばできるのでは？&lt;/p&gt;
+&lt;h2 id=&#34;kagome-bot&#34;&gt;kagome-bot&lt;/h2&gt;
+&lt;p&gt;知り合いが&lt;a href=&#34;https://github.com/ikawaha/kagome&#34;&gt;kagome&lt;/a&gt;という形態素解析ライブラリを開発しています。
+その知り合いが、ボットにもしてくれています（複数辞書対応してみたかったので、PR作って取り込んでもらいました）。&lt;/p&gt;
+&lt;ul&gt;
+&lt;li&gt;&lt;a href=&#34;https://github.com/ikawaha/kagome-bot&#34;&gt;https://github.com/ikawaha/kagome-bot&lt;/a&gt;&lt;/li&gt;
+&lt;/ul&gt;
+&lt;p&gt;ただ、デプロイはしてなかったので、我が家にあるUbuntuのサーバーにデプロイして動かすことにしました。
+ボットについては、上記のリポジトリを見てもらえればいいかなと。&lt;/p&gt;
+&lt;p&gt;とりあえず動けばいいや、ということで、適当なshell scriptに&lt;code&gt;nohup&lt;/code&gt;で起動していたのですが、Ubuntuの更新後の再起動で毎回ログインしてスクリプトの実行はめんどくさいな？ということでググって調べてみました。&lt;/p&gt;
+&lt;h2 id=&#34;systemdでユーザーのサービスとして登録&#34;&gt;systemdでユーザーのサービスとして登録&lt;/h2&gt;
+&lt;p&gt;参考ブログにある手順ほぼそのままでした。知見ありがたいです。&lt;/p&gt;
+&lt;p&gt;サービスの登録自体は、指定のディレクトリにファイルを作るのではなく、systemdコマンドをしようしました。&lt;/p&gt;
+&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;$ systemctl --user --force --full edit kagome
+&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;これで、参考ブログにあるように&lt;code&gt;kagome.service&lt;/code&gt;というファイルが&lt;code&gt;~/.config/systemd/user/&lt;/code&gt;ディレクトリに作られます。
+ファイルの内容などはほぼ参考ブログにある通りです。こんなかんじ。&lt;/p&gt;
+&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;[Unit]
+Description=kagome bot
+
+[Service]
+ExecStart=/home/johtani/kagome-bot/start_kagomebot_service.sh
+ExecStop=/bin/kill ${MAINPID}
+Restart=always
+
+[Install]
+WantedBy=default.target
+&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;&lt;code&gt;start_kagomebot_service.sh&lt;/code&gt;の中で、kagome-botコマンドを実行しますが、こちらは絶対パスで記述しておきました。
+サービス起動時のパスは&lt;code&gt;~/&lt;/code&gt;のようなのですが、念のために。&lt;/p&gt;
+&lt;p&gt;あとは、次の手順でサービスを登録して開始します。&lt;/p&gt;
+&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;$ systemctl --user enable kagome
+$ systemctl --user start kagome
+&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;ログを見るのは&lt;code&gt;journalctl&lt;/code&gt;コマンドです。&lt;/p&gt;
+&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;$ journalctl --user -u kagome
+&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;あとは、以下のコマンドを実行しないと、マシン再起動後にログインするまでサービスが起動しないので忘れないようにしましょう。
+（忘れてログインしてみて起動してるじゃん？というコントみたいなことをしてしまいました）。&lt;/p&gt;
+&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;$ sudo loginctl enable-linger username
+&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;参考ブログ本当にありがたいですね。
+備忘録のついでにブログにしておきます。&lt;/p&gt;
+&lt;h2 id=&#34;参考ブログ&#34;&gt;参考ブログ&lt;/h2&gt;
+&lt;ul&gt;
+&lt;li&gt;&lt;a href=&#34;https://pyopyopyo.hatenablog.com/entry/2021/04/30/233755&#34;&gt;ユーザー権限で systemd のサービスを稼働させる方法 - pyopyopyo - Linuxとかプログラミングの覚え書き -&lt;/a&gt;&lt;/li&gt;
+&lt;/ul&gt;
+</content:encoded>
+    </item>
+    
     <item>
       <title>今年の振り返りと来年の抱負（2023）</title>
       <link>https://blog.johtani.info/blog/2023/12/31/review-2023/</link>
diff --git "a/blog/2011/05/20/\343\203\226\343\203\255\343\202\260\343\201\257\343\201\230\343\202\201\343\201\276\343\201\231/index.html" "b/blog/2011/05/20/\343\203\226\343\203\255\343\202\260\343\201\257\343\201\230\343\202\201\343\201\276\343\201\231/index.html"
index 7e96f0b9a8..3bbc4f8c31 100644
--- "a/blog/2011/05/20/\343\203\226\343\203\255\343\202\260\343\201\257\343\201\230\343\202\201\343\201\276\343\201\231/index.html"
+++ "b/blog/2011/05/20/\343\203\226\343\203\255\343\202\260\343\201\257\343\201\230\343\202\201\343\201\276\343\201\231/index.html"
@@ -406,6 +406,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -795,7 +797,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/05/23/lucene-gosen\343\201\250\343\201\257/index.html" "b/blog/2011/05/23/lucene-gosen\343\201\250\343\201\257/index.html"
index 886968e26f..da473ba06e 100644
--- "a/blog/2011/05/23/lucene-gosen\343\201\250\343\201\257/index.html"
+++ "b/blog/2011/05/23/lucene-gosen\343\201\250\343\201\257/index.html"
@@ -441,6 +441,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -830,7 +832,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/05/26/\343\202\275\343\203\274\343\202\271\343\201\213\343\202\211\343\201\256\343\203\223\343\203\253\343\203\211\343\201\250\346\247\213\346\210\220/index.html" "b/blog/2011/05/26/\343\202\275\343\203\274\343\202\271\343\201\213\343\202\211\343\201\256\343\203\223\343\203\253\343\203\211\343\201\250\346\247\213\346\210\220/index.html"
index cc966c354e..7ce44f0165 100644
--- "a/blog/2011/05/26/\343\202\275\343\203\274\343\202\271\343\201\213\343\202\211\343\201\256\343\203\223\343\203\253\343\203\211\343\201\250\346\247\213\346\210\220/index.html"
+++ "b/blog/2011/05/26/\343\202\275\343\203\274\343\202\271\343\201\213\343\202\211\343\201\256\343\203\223\343\203\253\343\203\211\343\201\250\346\247\213\346\210\220/index.html"
@@ -456,6 +456,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -845,7 +847,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/06/02/\350\276\236\346\233\270\343\201\250\343\202\253\343\202\271\343\202\277\343\203\240\350\276\236\346\233\270\343\201\253\343\201\244\343\201\204\343\201\246/index.html" "b/blog/2011/06/02/\350\276\236\346\233\270\343\201\250\343\202\253\343\202\271\343\202\277\343\203\240\350\276\236\346\233\270\343\201\253\343\201\244\343\201\204\343\201\246/index.html"
index d5210f5c5a..67133eb4d0 100644
--- "a/blog/2011/06/02/\350\276\236\346\233\270\343\201\250\343\202\253\343\202\271\343\202\277\343\203\240\350\276\236\346\233\270\343\201\253\343\201\244\343\201\204\343\201\246/index.html"
+++ "b/blog/2011/06/02/\350\276\236\346\233\270\343\201\250\343\202\253\343\202\271\343\202\277\343\203\240\350\276\236\346\233\270\343\201\253\343\201\244\343\201\204\343\201\246/index.html"
@@ -571,6 +571,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -960,7 +962,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/06/06/lucene-gosen\343\201\256tokenfilter\343\201\237\343\201\241/index.html" "b/blog/2011/06/06/lucene-gosen\343\201\256tokenfilter\343\201\237\343\201\241/index.html"
index 295fa87ff4..0d6d39e749 100644
--- "a/blog/2011/06/06/lucene-gosen\343\201\256tokenfilter\343\201\237\343\201\241/index.html"
+++ "b/blog/2011/06/06/lucene-gosen\343\201\256tokenfilter\343\201\237\343\201\241/index.html"
@@ -449,6 +449,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -838,7 +840,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/06/13/lucene-gosen-1-1-0-\343\203\252\343\203\252\343\203\274\343\202\271/index.html" "b/blog/2011/06/13/lucene-gosen-1-1-0-\343\203\252\343\203\252\343\203\274\343\202\271/index.html"
index 366e33dc39..4339aa5544 100644
--- "a/blog/2011/06/13/lucene-gosen-1-1-0-\343\203\252\343\203\252\343\203\274\343\202\271/index.html"
+++ "b/blog/2011/06/13/lucene-gosen-1-1-0-\343\203\252\343\203\252\343\203\274\343\202\271/index.html"
@@ -413,6 +413,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -802,7 +804,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/06/14/compositepos\343\201\256\345\210\251\347\224\250\344\276\213naist-chasen\343\201\247\343\201\256\350\213\261\345\215\230\350\252\236\343\201\256\345\207\272\345\212\233\346\226\271\346\263\225\344\276\213/index.html" "b/blog/2011/06/14/compositepos\343\201\256\345\210\251\347\224\250\344\276\213naist-chasen\343\201\247\343\201\256\350\213\261\345\215\230\350\252\236\343\201\256\345\207\272\345\212\233\346\226\271\346\263\225\344\276\213/index.html"
index 49d01e1730..cb9e331ace 100644
--- "a/blog/2011/06/14/compositepos\343\201\256\345\210\251\347\224\250\344\276\213naist-chasen\343\201\247\343\201\256\350\213\261\345\215\230\350\252\236\343\201\256\345\207\272\345\212\233\346\226\271\346\263\225\344\276\213/index.html"
+++ "b/blog/2011/06/14/compositepos\343\201\256\345\210\251\347\224\250\344\276\213naist-chasen\343\201\247\343\201\256\350\213\261\345\215\230\350\252\236\343\201\256\345\207\272\345\212\233\346\226\271\346\263\225\344\276\213/index.html"
@@ -479,6 +479,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -868,7 +870,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/06/21/naist-jdic-for-mecab\345\257\276\345\277\234\347\211\210\344\273\256\345\256\237\350\243\205/index.html" "b/blog/2011/06/21/naist-jdic-for-mecab\345\257\276\345\277\234\347\211\210\344\273\256\345\256\237\350\243\205/index.html"
index bcc70e9c99..5e291934c8 100644
--- "a/blog/2011/06/21/naist-jdic-for-mecab\345\257\276\345\277\234\347\211\210\344\273\256\345\256\237\350\243\205/index.html"
+++ "b/blog/2011/06/21/naist-jdic-for-mecab\345\257\276\345\277\234\347\211\210\344\273\256\345\256\237\350\243\205/index.html"
@@ -432,6 +432,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -821,7 +823,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/06/28/compositeposcompositetokenfilter\343\201\256\343\203\220\343\202\260\344\277\256\346\255\243/index.html" "b/blog/2011/06/28/compositeposcompositetokenfilter\343\201\256\343\203\220\343\202\260\344\277\256\346\255\243/index.html"
index a0727822bc..47dc15948d 100644
--- "a/blog/2011/06/28/compositeposcompositetokenfilter\343\201\256\343\203\220\343\202\260\344\277\256\346\255\243/index.html"
+++ "b/blog/2011/06/28/compositeposcompositetokenfilter\343\201\256\343\203\220\343\202\260\344\277\256\346\255\243/index.html"
@@ -418,6 +418,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -807,7 +809,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/06/29/hadoop\343\202\222\344\270\255\345\277\203\343\201\250\343\201\227\343\201\237\345\210\206\346\225\243\347\222\260\345\242\203\343\201\247\343\201\256\351\226\213\347\231\272\346\226\271\346\263\225\350\253\226\343\203\242\343\203\207\343\203\252\343\203\263\343\202\260\350\250\255\350\250\210\346\211\213\346\263\225\347\255\211\343\201\253\343\201\244\343\201\204\343\201\246\343\201\256\345\272\247\350\253\207\344\274\232-\347\254\2545\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2011/06/29/hadoop\343\202\222\344\270\255\345\277\203\343\201\250\343\201\227\343\201\237\345\210\206\346\225\243\347\222\260\345\242\203\343\201\247\343\201\256\351\226\213\347\231\272\346\226\271\346\263\225\350\253\226\343\203\242\343\203\207\343\203\252\343\203\263\343\202\260\350\250\255\350\250\210\346\211\213\346\263\225\347\255\211\343\201\253\343\201\244\343\201\204\343\201\246\343\201\256\345\272\247\350\253\207\344\274\232-\347\254\2545\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
index a19f4ce7c9..b045717ad4 100644
--- "a/blog/2011/06/29/hadoop\343\202\222\344\270\255\345\277\203\343\201\250\343\201\227\343\201\237\345\210\206\346\225\243\347\222\260\345\242\203\343\201\247\343\201\256\351\226\213\347\231\272\346\226\271\346\263\225\350\253\226\343\203\242\343\203\207\343\203\252\343\203\263\343\202\260\350\250\255\350\250\210\346\211\213\346\263\225\347\255\211\343\201\253\343\201\244\343\201\204\343\201\246\343\201\256\345\272\247\350\253\207\344\274\232-\347\254\2545\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2011/06/29/hadoop\343\202\222\344\270\255\345\277\203\343\201\250\343\201\227\343\201\237\345\210\206\346\225\243\347\222\260\345\242\203\343\201\247\343\201\256\351\226\213\347\231\272\346\226\271\346\263\225\350\253\226\343\203\242\343\203\207\343\203\252\343\203\263\343\202\260\350\250\255\350\250\210\346\211\213\346\263\225\347\255\211\343\201\253\343\201\244\343\201\204\343\201\246\343\201\256\345\272\247\350\253\207\344\274\232-\347\254\2545\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
@@ -717,6 +717,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1106,7 +1108,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/07/01/lucene-solr-3-3\343\203\252\343\203\252\343\203\274\343\202\271\351\200\237\345\240\261/index.html" "b/blog/2011/07/01/lucene-solr-3-3\343\203\252\343\203\252\343\203\274\343\202\271\351\200\237\345\240\261/index.html"
index f054a12912..4be43a663a 100644
--- "a/blog/2011/07/01/lucene-solr-3-3\343\203\252\343\203\252\343\203\274\343\202\271\351\200\237\345\240\261/index.html"
+++ "b/blog/2011/07/01/lucene-solr-3-3\343\203\252\343\203\252\343\203\274\343\202\271\351\200\237\345\240\261/index.html"
@@ -416,6 +416,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -805,7 +807,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/07/04/lucene-gosen-1-1-1\343\203\252\343\203\252\343\203\274\343\202\271/index.html" "b/blog/2011/07/04/lucene-gosen-1-1-1\343\203\252\343\203\252\343\203\274\343\202\271/index.html"
index 609650d896..fcc8d83f3c 100644
--- "a/blog/2011/07/04/lucene-gosen-1-1-1\343\203\252\343\203\252\343\203\274\343\202\271/index.html"
+++ "b/blog/2011/07/04/lucene-gosen-1-1-1\343\203\252\343\203\252\343\203\274\343\202\271/index.html"
@@ -411,6 +411,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -800,7 +802,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/07/12/naist-jdic-for-mecab\343\201\256preprocessor\343\201\256\345\256\237\350\243\205\343\201\253\351\226\242\343\201\231\343\202\213\345\202\231\345\277\230\351\214\262/index.html" "b/blog/2011/07/12/naist-jdic-for-mecab\343\201\256preprocessor\343\201\256\345\256\237\350\243\205\343\201\253\351\226\242\343\201\231\343\202\213\345\202\231\345\277\230\351\214\262/index.html"
index 815e8b9417..bde9e2d787 100644
--- "a/blog/2011/07/12/naist-jdic-for-mecab\343\201\256preprocessor\343\201\256\345\256\237\350\243\205\343\201\253\351\226\242\343\201\231\343\202\213\345\202\231\345\277\230\351\214\262/index.html"
+++ "b/blog/2011/07/12/naist-jdic-for-mecab\343\201\256preprocessor\343\201\256\345\256\237\350\243\205\343\201\253\351\226\242\343\201\231\343\202\213\345\202\231\345\277\230\351\214\262/index.html"
@@ -489,6 +489,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -878,7 +880,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/07/20/kuromoji\343\202\222\350\252\277\343\201\271\343\201\246\343\201\277\343\201\237/index.html" "b/blog/2011/07/20/kuromoji\343\202\222\350\252\277\343\201\271\343\201\246\343\201\277\343\201\237/index.html"
index d7a7e1e640..d3e08de68e 100644
--- "a/blog/2011/07/20/kuromoji\343\202\222\350\252\277\343\201\271\343\201\246\343\201\277\343\201\237/index.html"
+++ "b/blog/2011/07/20/kuromoji\343\202\222\350\252\277\343\201\271\343\201\246\343\201\277\343\201\237/index.html"
@@ -481,6 +481,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -870,7 +872,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/07/27/\347\254\2541\345\233\236-\343\203\207\343\203\274\343\202\277\346\247\213\351\200\240\343\201\250\346\203\205\345\240\261\346\244\234\347\264\242\343\201\250\350\250\200\350\252\236\345\207\246\347\220\206\345\213\211\345\274\267\344\274\232\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2011/07/27/\347\254\2541\345\233\236-\343\203\207\343\203\274\343\202\277\346\247\213\351\200\240\343\201\250\346\203\205\345\240\261\346\244\234\347\264\242\343\201\250\350\250\200\350\252\236\345\207\246\347\220\206\345\213\211\345\274\267\344\274\232\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
index 8a05a7a299..e0c3925b14 100644
--- "a/blog/2011/07/27/\347\254\2541\345\233\236-\343\203\207\343\203\274\343\202\277\346\247\213\351\200\240\343\201\250\346\203\205\345\240\261\346\244\234\347\264\242\343\201\250\350\250\200\350\252\236\345\207\246\347\220\206\345\213\211\345\274\267\344\274\232\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2011/07/27/\347\254\2541\345\233\236-\343\203\207\343\203\274\343\202\277\346\247\213\351\200\240\343\201\250\346\203\205\345\240\261\346\244\234\347\264\242\343\201\250\350\250\200\350\252\236\345\207\246\347\220\206\345\213\211\345\274\267\344\274\232\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
@@ -712,6 +712,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1101,7 +1103,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/08/04/apple\346\225\231\343\201\253\345\205\245\344\277\241\343\201\227\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2011/08/04/apple\346\225\231\343\201\253\345\205\245\344\277\241\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
index 87799b6dc5..857be5188c 100644
--- "a/blog/2011/08/04/apple\346\225\231\343\201\253\345\205\245\344\277\241\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2011/08/04/apple\346\225\231\343\201\253\345\205\245\344\277\241\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
@@ -464,6 +464,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -853,7 +855,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/08/10/mba\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\345\202\231\345\277\230\351\214\262/index.html" "b/blog/2011/08/10/mba\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\345\202\231\345\277\230\351\214\262/index.html"
index b8bca66687..16b268ad2f 100644
--- "a/blog/2011/08/10/mba\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\345\202\231\345\277\230\351\214\262/index.html"
+++ "b/blog/2011/08/10/mba\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\345\202\231\345\277\230\351\214\262/index.html"
@@ -455,6 +455,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -844,7 +846,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/08/15/mba\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\345\202\231\345\277\230\351\214\262\343\201\235\343\201\256\357\274\222/index.html" "b/blog/2011/08/15/mba\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\345\202\231\345\277\230\351\214\262\343\201\235\343\201\256\357\274\222/index.html"
index 11606414c9..6c76a62033 100644
--- "a/blog/2011/08/15/mba\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\345\202\231\345\277\230\351\214\262\343\201\235\343\201\256\357\274\222/index.html"
+++ "b/blog/2011/08/15/mba\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\345\202\231\345\277\230\351\214\262\343\201\235\343\201\256\357\274\222/index.html"
@@ -452,6 +452,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -841,7 +843,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/08/23/\350\276\236\346\233\270\343\201\256jar\343\203\225\343\202\241\343\202\244\343\203\253\343\201\213\343\202\211\343\201\256\345\210\206\351\233\242/index.html" "b/blog/2011/08/23/\350\276\236\346\233\270\343\201\256jar\343\203\225\343\202\241\343\202\244\343\203\253\343\201\213\343\202\211\343\201\256\345\210\206\351\233\242/index.html"
index 8d1a7ab6ac..f57985a6fa 100644
--- "a/blog/2011/08/23/\350\276\236\346\233\270\343\201\256jar\343\203\225\343\202\241\343\202\244\343\203\253\343\201\213\343\202\211\343\201\256\345\210\206\351\233\242/index.html"
+++ "b/blog/2011/08/23/\350\276\236\346\233\270\343\201\256jar\343\203\225\343\202\241\343\202\244\343\203\253\343\201\213\343\202\211\343\201\256\345\210\206\351\233\242/index.html"
@@ -458,6 +458,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -847,7 +849,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/08/30/\350\244\207\346\225\260\350\276\236\346\233\270\343\201\256\350\252\255\343\201\277\350\276\274\343\201\277\346\251\237\350\203\275\350\277\275\345\212\240\344\273\256/index.html" "b/blog/2011/08/30/\350\244\207\346\225\260\350\276\236\346\233\270\343\201\256\350\252\255\343\201\277\350\276\274\343\201\277\346\251\237\350\203\275\350\277\275\345\212\240\344\273\256/index.html"
index 408f887031..6e9ee76709 100644
--- "a/blog/2011/08/30/\350\244\207\346\225\260\350\276\236\346\233\270\343\201\256\350\252\255\343\201\277\350\276\274\343\201\277\346\251\237\350\203\275\350\277\275\345\212\240\344\273\256/index.html"
+++ "b/blog/2011/08/30/\350\244\207\346\225\260\350\276\236\346\233\270\343\201\256\350\252\255\343\201\277\350\276\274\343\201\277\346\251\237\350\203\275\350\277\275\345\212\240\344\273\256/index.html"
@@ -442,6 +442,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -831,7 +833,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/09/07/mba\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\345\202\231\345\277\230\351\214\262\343\201\235\343\201\256\357\274\223/index.html" "b/blog/2011/09/07/mba\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\345\202\231\345\277\230\351\214\262\343\201\235\343\201\256\357\274\223/index.html"
index b4518a6b3b..0bbe6ddb35 100644
--- "a/blog/2011/09/07/mba\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\345\202\231\345\277\230\351\214\262\343\201\235\343\201\256\357\274\223/index.html"
+++ "b/blog/2011/09/07/mba\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\345\202\231\345\277\230\351\214\262\343\201\235\343\201\256\357\274\223/index.html"
@@ -437,6 +437,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -826,7 +828,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/09/07/\350\276\236\346\233\270\345\210\206\351\233\242\343\201\256\343\203\206\343\202\271\343\203\210\343\202\261\343\203\274\343\202\271\350\277\275\345\212\240\343\201\250\346\256\213\343\202\277\343\202\271\343\202\257/index.html" "b/blog/2011/09/07/\350\276\236\346\233\270\345\210\206\351\233\242\343\201\256\343\203\206\343\202\271\343\203\210\343\202\261\343\203\274\343\202\271\350\277\275\345\212\240\343\201\250\346\256\213\343\202\277\343\202\271\343\202\257/index.html"
index 2d38ce599a..fa8d20b42f 100644
--- "a/blog/2011/09/07/\350\276\236\346\233\270\345\210\206\351\233\242\343\201\256\343\203\206\343\202\271\343\203\210\343\202\261\343\203\274\343\202\271\350\277\275\345\212\240\343\201\250\346\256\213\343\202\277\343\202\271\343\202\257/index.html"
+++ "b/blog/2011/09/07/\350\276\236\346\233\270\345\210\206\351\233\242\343\201\256\343\203\206\343\202\271\343\203\210\343\202\261\343\203\274\343\202\271\350\277\275\345\212\240\343\201\250\346\256\213\343\202\277\343\202\271\343\202\257/index.html"
@@ -423,6 +423,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -812,7 +814,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/09/09/7\343\201\244\343\201\256\350\250\200\350\252\236-7\343\201\244\343\201\256\344\270\226\347\225\214-ruby-1\346\227\245\347\233\256/index.html" "b/blog/2011/09/09/7\343\201\244\343\201\256\350\250\200\350\252\236-7\343\201\244\343\201\256\344\270\226\347\225\214-ruby-1\346\227\245\347\233\256/index.html"
index cc87379ca0..7e024745ab 100644
--- "a/blog/2011/09/09/7\343\201\244\343\201\256\350\250\200\350\252\236-7\343\201\244\343\201\256\344\270\226\347\225\214-ruby-1\346\227\245\347\233\256/index.html"
+++ "b/blog/2011/09/09/7\343\201\244\343\201\256\350\250\200\350\252\236-7\343\201\244\343\201\256\344\270\226\347\225\214-ruby-1\346\227\245\347\233\256/index.html"
@@ -550,6 +550,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -939,7 +941,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/09/10/7\343\201\244\343\201\256\350\250\200\350\252\236-7\343\201\244\343\201\256\344\270\226\347\225\214-ruby-2\346\227\245\347\233\256/index.html" "b/blog/2011/09/10/7\343\201\244\343\201\256\350\250\200\350\252\236-7\343\201\244\343\201\256\344\270\226\347\225\214-ruby-2\346\227\245\347\233\256/index.html"
index 399447f15f..25bcd778a1 100644
--- "a/blog/2011/09/10/7\343\201\244\343\201\256\350\250\200\350\252\236-7\343\201\244\343\201\256\344\270\226\347\225\214-ruby-2\346\227\245\347\233\256/index.html"
+++ "b/blog/2011/09/10/7\343\201\244\343\201\256\350\250\200\350\252\236-7\343\201\244\343\201\256\344\270\226\347\225\214-ruby-2\346\227\245\347\233\256/index.html"
@@ -611,6 +611,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1000,7 +1002,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/09/12/\347\254\2546\345\233\236solr\345\213\211\345\274\267\344\274\232\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2011/09/12/\347\254\2546\345\233\236solr\345\213\211\345\274\267\344\274\232\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
index 121947fdaf..fa2e8d7bd6 100644
--- "a/blog/2011/09/12/\347\254\2546\345\233\236solr\345\213\211\345\274\267\344\274\232\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2011/09/12/\347\254\2546\345\233\236solr\345\213\211\345\274\267\344\274\232\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
@@ -767,6 +767,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1156,7 +1158,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/09/14/7\343\201\244\343\201\256\350\250\200\350\252\236-7\343\201\244\343\201\256\344\270\226\347\225\214-ruby-3\346\227\245\347\233\256\346\234\200\347\265\202\346\227\245/index.html" "b/blog/2011/09/14/7\343\201\244\343\201\256\350\250\200\350\252\236-7\343\201\244\343\201\256\344\270\226\347\225\214-ruby-3\346\227\245\347\233\256\346\234\200\347\265\202\346\227\245/index.html"
index 9c6f903e32..0884ab10aa 100644
--- "a/blog/2011/09/14/7\343\201\244\343\201\256\350\250\200\350\252\236-7\343\201\244\343\201\256\344\270\226\347\225\214-ruby-3\346\227\245\347\233\256\346\234\200\347\265\202\346\227\245/index.html"
+++ "b/blog/2011/09/14/7\343\201\244\343\201\256\350\250\200\350\252\236-7\343\201\244\343\201\256\344\270\226\347\225\214-ruby-3\346\227\245\347\233\256\346\234\200\347\265\202\346\227\245/index.html"
@@ -540,6 +540,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -929,7 +931,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/09/15/lucene-solr-3-4\343\203\252\343\203\252\343\203\274\343\202\271\351\200\237\345\240\261/index.html" "b/blog/2011/09/15/lucene-solr-3-4\343\203\252\343\203\252\343\203\274\343\202\271\351\200\237\345\240\261/index.html"
index 122e1743e8..2c01384abb 100644
--- "a/blog/2011/09/15/lucene-solr-3-4\343\203\252\343\203\252\343\203\274\343\202\271\351\200\237\345\240\261/index.html"
+++ "b/blog/2011/09/15/lucene-solr-3-4\343\203\252\343\203\252\343\203\274\343\202\271\351\200\237\345\240\261/index.html"
@@ -416,6 +416,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -805,7 +807,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/09/23/7\343\201\244\343\201\256\350\250\200\350\252\236-7\343\201\244\343\201\256\344\270\226\347\225\214-io-0\346\227\245\347\233\256/index.html" "b/blog/2011/09/23/7\343\201\244\343\201\256\350\250\200\350\252\236-7\343\201\244\343\201\256\344\270\226\347\225\214-io-0\346\227\245\347\233\256/index.html"
index ade9b95c20..1c5564f58d 100644
--- "a/blog/2011/09/23/7\343\201\244\343\201\256\350\250\200\350\252\236-7\343\201\244\343\201\256\344\270\226\347\225\214-io-0\346\227\245\347\233\256/index.html"
+++ "b/blog/2011/09/23/7\343\201\244\343\201\256\350\250\200\350\252\236-7\343\201\244\343\201\256\344\270\226\347\225\214-io-0\346\227\245\347\233\256/index.html"
@@ -322,8 +322,6 @@ <h3 id="罠その３">罠その３</h3>
 <h3>See Also by Hugo</h3>
 <ul>
  
- <li><a href="/blog/2014/08/01/plugin-using-under-proxy-env/">プロキシ環境でのpluginコマンドの実行</a></li>
- 
  <li><a href="/blog/2013/07/11/yokozuna-check-point/">Yokozunaの気になる点というかなんというか</a></li>
  
  <li><a href="/blog/2011/08/15/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%92/">MBAセットアップ備忘録その２(Jugemより移植)</a></li>
@@ -454,6 +452,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -843,7 +843,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/09/27/hadoop-conference-japan-2011-fall\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2011/09/27/hadoop-conference-japan-2011-fall\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html"
index 1513369094..06d27caca9 100644
--- "a/blog/2011/09/27/hadoop-conference-japan-2011-fall\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2011/09/27/hadoop-conference-japan-2011-fall\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html"
@@ -919,6 +919,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1308,7 +1310,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/09/28/new-solrcloud-design\343\201\256\347\277\273\350\250\263\343\201\235\343\201\256\357\274\221/index.html" "b/blog/2011/09/28/new-solrcloud-design\343\201\256\347\277\273\350\250\263\343\201\235\343\201\256\357\274\221/index.html"
index 85531f675b..d0fefafead 100644
--- "a/blog/2011/09/28/new-solrcloud-design\343\201\256\347\277\273\350\250\263\343\201\235\343\201\256\357\274\221/index.html"
+++ "b/blog/2011/09/28/new-solrcloud-design\343\201\256\347\277\273\350\250\263\343\201\235\343\201\256\357\274\221/index.html"
@@ -592,6 +592,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -981,7 +983,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/10/04/new-solrcloud-design\343\201\256\347\277\273\350\250\263\343\201\235\343\201\2562/index.html" "b/blog/2011/10/04/new-solrcloud-design\343\201\256\347\277\273\350\250\263\343\201\235\343\201\2562/index.html"
index cb01a23318..322007358c 100644
--- "a/blog/2011/10/04/new-solrcloud-design\343\201\256\347\277\273\350\250\263\343\201\235\343\201\2562/index.html"
+++ "b/blog/2011/10/04/new-solrcloud-design\343\201\256\347\277\273\350\250\263\343\201\235\343\201\2562/index.html"
@@ -776,6 +776,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1165,7 +1167,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/10/05/solr\343\201\256\346\226\260\343\201\227\343\201\204\347\256\241\347\220\206\347\224\273\351\235\242solr4-x-trunk\347\263\273/index.html" "b/blog/2011/10/05/solr\343\201\256\346\226\260\343\201\227\343\201\204\347\256\241\347\220\206\347\224\273\351\235\242solr4-x-trunk\347\263\273/index.html"
index 0d668133b7..9994de7421 100644
--- "a/blog/2011/10/05/solr\343\201\256\346\226\260\343\201\227\343\201\204\347\256\241\347\220\206\347\224\273\351\235\242solr4-x-trunk\347\263\273/index.html"
+++ "b/blog/2011/10/05/solr\343\201\256\346\226\260\343\201\227\343\201\204\347\256\241\347\220\206\347\224\273\351\235\242solr4-x-trunk\347\263\273/index.html"
@@ -536,6 +536,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -925,7 +927,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/10/07/7\343\201\244\343\201\256\350\250\200\350\252\236-7\343\201\244\343\201\256\344\270\226\347\225\214-io-1\346\227\245\347\233\256/index.html" "b/blog/2011/10/07/7\343\201\244\343\201\256\350\250\200\350\252\236-7\343\201\244\343\201\256\344\270\226\347\225\214-io-1\346\227\245\347\233\256/index.html"
index 6895898c34..16f456cb22 100644
--- "a/blog/2011/10/07/7\343\201\244\343\201\256\350\250\200\350\252\236-7\343\201\244\343\201\256\344\270\226\347\225\214-io-1\346\227\245\347\233\256/index.html"
+++ "b/blog/2011/10/07/7\343\201\244\343\201\256\350\250\200\350\252\236-7\343\201\244\343\201\256\344\270\226\347\225\214-io-1\346\227\245\347\233\256/index.html"
@@ -629,6 +629,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1018,7 +1020,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/10/07/mba\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\345\202\231\345\277\230\351\214\262\343\201\235\343\201\256\357\274\224/index.html" "b/blog/2011/10/07/mba\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\345\202\231\345\277\230\351\214\262\343\201\235\343\201\256\357\274\224/index.html"
index 8932a22c27..6b19703ca8 100644
--- "a/blog/2011/10/07/mba\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\345\202\231\345\277\230\351\214\262\343\201\235\343\201\256\357\274\224/index.html"
+++ "b/blog/2011/10/07/mba\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\345\202\231\345\277\230\351\214\262\343\201\235\343\201\256\357\274\224/index.html"
@@ -452,6 +452,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -841,7 +843,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/10/12/lucene-gosen\343\201\247\346\226\207\347\253\240\343\201\213\343\202\211\343\202\255\343\203\274\343\203\257\343\203\274\343\203\211\346\212\275\345\207\272\343\202\244\343\203\254\343\202\256\343\203\245\343\203\251\343\203\274/index.html" "b/blog/2011/10/12/lucene-gosen\343\201\247\346\226\207\347\253\240\343\201\213\343\202\211\343\202\255\343\203\274\343\203\257\343\203\274\343\203\211\346\212\275\345\207\272\343\202\244\343\203\254\343\202\256\343\203\245\343\203\251\343\203\274/index.html"
index 90e88c6665..df57720c8e 100644
--- "a/blog/2011/10/12/lucene-gosen\343\201\247\346\226\207\347\253\240\343\201\213\343\202\211\343\202\255\343\203\274\343\203\257\343\203\274\343\203\211\346\212\275\345\207\272\343\202\244\343\203\254\343\202\256\343\203\245\343\203\251\343\203\274/index.html"
+++ "b/blog/2011/10/12/lucene-gosen\343\201\247\346\226\207\347\253\240\343\201\213\343\202\211\343\202\255\343\203\274\343\203\257\343\203\274\343\203\211\346\212\275\345\207\272\343\202\244\343\203\254\343\202\256\343\203\245\343\203\251\343\203\274/index.html"
@@ -496,6 +496,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -885,7 +887,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/10/18/jjug-ccc-2011-fall\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2011/10/18/jjug-ccc-2011-fall\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html"
index 215564d155..aecad3a30a 100644
--- "a/blog/2011/10/18/jjug-ccc-2011-fall\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2011/10/18/jjug-ccc-2011-fall\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html"
@@ -574,6 +574,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -963,7 +965,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/10/26/\350\276\236\346\233\270\343\201\256\345\244\226\351\203\250\345\214\226\343\201\250lucene-solr3-4\345\257\276\345\277\234/index.html" "b/blog/2011/10/26/\350\276\236\346\233\270\343\201\256\345\244\226\351\203\250\345\214\226\343\201\250lucene-solr3-4\345\257\276\345\277\234/index.html"
index 0dfa3965ef..334ba38f29 100644
--- "a/blog/2011/10/26/\350\276\236\346\233\270\343\201\256\345\244\226\351\203\250\345\214\226\343\201\250lucene-solr3-4\345\257\276\345\277\234/index.html"
+++ "b/blog/2011/10/26/\350\276\236\346\233\270\343\201\256\345\244\226\351\203\250\345\214\226\343\201\250lucene-solr3-4\345\257\276\345\277\234/index.html"
@@ -535,6 +535,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -924,7 +926,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/10/31/1-2-0\343\203\252\343\203\252\343\203\274\343\202\271/index.html" "b/blog/2011/10/31/1-2-0\343\203\252\343\203\252\343\203\274\343\202\271/index.html"
index 62fc7f8d1a..4d97ca484f 100644
--- "a/blog/2011/10/31/1-2-0\343\203\252\343\203\252\343\203\274\343\202\271/index.html"
+++ "b/blog/2011/10/31/1-2-0\343\203\252\343\203\252\343\203\274\343\202\271/index.html"
@@ -411,6 +411,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -800,7 +802,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/11/02/bookscan\343\202\222\344\275\277\343\201\243\343\201\246\343\201\277\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2011/11/02/bookscan\343\202\222\344\275\277\343\201\243\343\201\246\343\201\277\343\201\276\343\201\227\343\201\237/index.html"
index 0fad6de605..57c3f74454 100644
--- "a/blog/2011/11/02/bookscan\343\202\222\344\275\277\343\201\243\343\201\246\343\201\277\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2011/11/02/bookscan\343\202\222\344\275\277\343\201\243\343\201\246\343\201\277\343\201\276\343\201\227\343\201\237/index.html"
@@ -442,6 +442,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -831,7 +833,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/11/08/lucene-eurocon-2011-barcelona-\343\201\256\343\202\271\343\203\251\343\202\244\343\203\211\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2011/11/08/lucene-eurocon-2011-barcelona-\343\201\256\343\202\271\343\203\251\343\202\244\343\203\211\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237/index.html"
index dd1d7a0a94..640890ceb6 100644
--- "a/blog/2011/11/08/lucene-eurocon-2011-barcelona-\343\201\256\343\202\271\343\203\251\343\202\244\343\203\211\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2011/11/08/lucene-eurocon-2011-barcelona-\343\201\256\343\202\271\343\203\251\343\202\244\343\203\211\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237/index.html"
@@ -476,6 +476,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -865,7 +867,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/11/09/splunk-live\343\201\256\343\202\244\343\203\231\343\203\263\343\203\210\343\201\253\350\241\214\343\201\243\343\201\246\346\235\245\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2011/11/09/splunk-live\343\201\256\343\202\244\343\203\231\343\203\263\343\203\210\343\201\253\350\241\214\343\201\243\343\201\246\346\235\245\343\201\276\343\201\227\343\201\237/index.html"
index a5630e447a..224b76811b 100644
--- "a/blog/2011/11/09/splunk-live\343\201\256\343\202\244\343\203\231\343\203\263\343\203\210\343\201\253\350\241\214\343\201\243\343\201\246\346\235\245\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2011/11/09/splunk-live\343\201\256\343\202\244\343\203\231\343\203\263\343\203\210\343\201\253\350\241\214\343\201\243\343\201\246\346\235\245\343\201\276\343\201\227\343\201\237/index.html"
@@ -491,6 +491,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -880,7 +882,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/11/16/mongodb\345\213\211\345\274\267\344\274\232\347\254\2547\345\233\236\343\201\253\350\241\214\343\201\243\343\201\246\346\235\245\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2011/11/16/mongodb\345\213\211\345\274\267\344\274\232\347\254\2547\345\233\236\343\201\253\350\241\214\343\201\243\343\201\246\346\235\245\343\201\276\343\201\227\343\201\237/index.html"
index 7dc8605421..c577fc2453 100644
--- "a/blog/2011/11/16/mongodb\345\213\211\345\274\267\344\274\232\347\254\2547\345\233\236\343\201\253\350\241\214\343\201\243\343\201\246\346\235\245\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2011/11/16/mongodb\345\213\211\345\274\267\344\274\232\347\254\2547\345\233\236\343\201\253\350\241\214\343\201\243\343\201\246\346\235\245\343\201\276\343\201\227\343\201\237/index.html"
@@ -548,6 +548,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -937,7 +939,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/11/26/apache-solr\345\205\245\351\226\200\343\201\256\343\202\265\343\203\263\343\203\227\343\203\253\343\201\256lucene-gosen\345\257\276\345\277\2341\347\253\240\343\201\213\343\202\2114\347\253\240/index.html" "b/blog/2011/11/26/apache-solr\345\205\245\351\226\200\343\201\256\343\202\265\343\203\263\343\203\227\343\203\253\343\201\256lucene-gosen\345\257\276\345\277\2341\347\253\240\343\201\213\343\202\2114\347\253\240/index.html"
index d57f92b48d..ab85dbe236 100644
--- "a/blog/2011/11/26/apache-solr\345\205\245\351\226\200\343\201\256\343\202\265\343\203\263\343\203\227\343\203\253\343\201\256lucene-gosen\345\257\276\345\277\2341\347\253\240\343\201\213\343\202\2114\347\253\240/index.html"
+++ "b/blog/2011/11/26/apache-solr\345\205\245\351\226\200\343\201\256\343\202\265\343\203\263\343\203\227\343\203\253\343\201\256lucene-gosen\345\257\276\345\277\2341\347\253\240\343\201\213\343\202\2114\347\253\240/index.html"
@@ -478,6 +478,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -867,7 +869,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/11/29/hadoop\343\202\275\343\203\274\343\202\271\343\202\263\343\203\274\343\203\211\343\203\252\343\203\274\343\203\207\343\202\243\343\203\263\343\202\260\347\254\2547\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2011/11/29/hadoop\343\202\275\343\203\274\343\202\271\343\202\263\343\203\274\343\203\211\343\203\252\343\203\274\343\203\207\343\202\243\343\203\263\343\202\260\347\254\2547\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
index d8eefc9770..9309ce2159 100644
--- "a/blog/2011/11/29/hadoop\343\202\275\343\203\274\343\202\271\343\202\263\343\203\274\343\203\211\343\203\252\343\203\274\343\203\207\343\202\243\343\203\263\343\202\260\347\254\2547\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2011/11/29/hadoop\343\202\275\343\203\274\343\202\271\343\202\263\343\203\274\343\203\211\343\203\252\343\203\274\343\203\207\343\202\243\343\203\263\343\202\260\347\254\2547\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
@@ -573,6 +573,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -962,7 +964,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/11/29/\343\201\251\343\202\223\343\201\252\346\234\254\343\201\247\343\202\202\345\244\247\351\207\217\343\201\253\350\252\255\343\202\201\343\202\213\351\200\237\350\252\255\343\201\256\346\234\254\343\202\222\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2011/11/29/\343\201\251\343\202\223\343\201\252\346\234\254\343\201\247\343\202\202\345\244\247\351\207\217\343\201\253\350\252\255\343\202\201\343\202\213\351\200\237\350\252\255\343\201\256\346\234\254\343\202\222\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237/index.html"
index cee6444ae5..55b13aa727 100644
--- "a/blog/2011/11/29/\343\201\251\343\202\223\343\201\252\346\234\254\343\201\247\343\202\202\345\244\247\351\207\217\343\201\253\350\252\255\343\202\201\343\202\213\351\200\237\350\252\255\343\201\256\346\234\254\343\202\222\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2011/11/29/\343\201\251\343\202\223\343\201\252\346\234\254\343\201\247\343\202\202\345\244\247\351\207\217\343\201\253\350\252\255\343\202\201\343\202\213\351\200\237\350\252\255\343\201\256\346\234\254\343\202\222\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237/index.html"
@@ -435,6 +435,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -824,7 +826,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/12/01/mba\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\345\202\231\345\277\230\351\214\262\343\201\235\343\201\256\357\274\225\343\201\250mac-mini2009late\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\343\201\250\343\201\235\343\201\256\344\273\226\343\201\217\343\201\240\343\202\211\343\201\252\343\201\204\350\251\261/index.html" "b/blog/2011/12/01/mba\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\345\202\231\345\277\230\351\214\262\343\201\235\343\201\256\357\274\225\343\201\250mac-mini2009late\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\343\201\250\343\201\235\343\201\256\344\273\226\343\201\217\343\201\240\343\202\211\343\201\252\343\201\204\350\251\261/index.html"
index 63683c8c53..03278b7724 100644
--- "a/blog/2011/12/01/mba\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\345\202\231\345\277\230\351\214\262\343\201\235\343\201\256\357\274\225\343\201\250mac-mini2009late\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\343\201\250\343\201\235\343\201\256\344\273\226\343\201\217\343\201\240\343\202\211\343\201\252\343\201\204\350\251\261/index.html"
+++ "b/blog/2011/12/01/mba\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\345\202\231\345\277\230\351\214\262\343\201\235\343\201\256\357\274\225\343\201\250mac-mini2009late\343\202\273\343\203\203\343\203\210\343\202\242\343\203\203\343\203\227\343\201\250\343\201\235\343\201\256\344\273\226\343\201\217\343\201\240\343\202\211\343\201\252\343\201\204\350\251\261/index.html"
@@ -462,6 +462,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -851,7 +853,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/12/11/\347\254\2542\345\233\236-\343\203\207\343\203\274\343\202\277\346\247\213\351\200\240\343\201\250\346\203\205\345\240\261\346\244\234\347\264\242\343\201\250\350\250\200\350\252\236\345\207\246\347\220\206\345\213\211\345\274\267\344\274\232\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2011/12/11/\347\254\2542\345\233\236-\343\203\207\343\203\274\343\202\277\346\247\213\351\200\240\343\201\250\346\203\205\345\240\261\346\244\234\347\264\242\343\201\250\350\250\200\350\252\236\345\207\246\347\220\206\345\213\211\345\274\267\344\274\232\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
index df3ca88d1d..10d6499185 100644
--- "a/blog/2011/12/11/\347\254\2542\345\233\236-\343\203\207\343\203\274\343\202\277\346\247\213\351\200\240\343\201\250\346\203\205\345\240\261\346\244\234\347\264\242\343\201\250\350\250\200\350\252\236\345\207\246\347\220\206\345\213\211\345\274\267\344\274\232\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2011/12/11/\347\254\2542\345\233\236-\343\203\207\343\203\274\343\202\277\346\247\213\351\200\240\343\201\250\346\203\205\345\240\261\346\244\234\347\264\242\343\201\250\350\250\200\350\252\236\345\207\246\347\220\206\345\213\211\345\274\267\344\274\232\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
@@ -623,6 +623,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1012,7 +1014,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/12/20/solr\345\213\211\345\274\267\344\274\232\347\254\254\357\274\227\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237\347\231\272\350\241\250\343\202\202\343\201\227\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2011/12/20/solr\345\213\211\345\274\267\344\274\232\347\254\254\357\274\227\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237\347\231\272\350\241\250\343\202\202\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
index 452dfb9bcc..323ca88ebd 100644
--- "a/blog/2011/12/20/solr\345\213\211\345\274\267\344\274\232\347\254\254\357\274\227\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237\347\231\272\350\241\250\343\202\202\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2011/12/20/solr\345\213\211\345\274\267\344\274\232\347\254\254\357\274\227\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237\347\231\272\350\241\250\343\202\202\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
@@ -550,6 +550,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -939,7 +941,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/12/21/1-2-1\343\203\252\343\203\252\343\203\274\343\202\271\343\201\227\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2011/12/21/1-2-1\343\203\252\343\203\252\343\203\274\343\202\271\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
index e3f0dffb12..6529fd74b9 100644
--- "a/blog/2011/12/21/1-2-1\343\203\252\343\203\252\343\203\274\343\202\271\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2011/12/21/1-2-1\343\203\252\343\203\252\343\203\274\343\202\271\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
@@ -411,6 +411,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -800,7 +802,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/12/22/\347\254\2542-1\345\233\236-twitter-api-\345\213\211\345\274\267\344\274\232--\346\235\261\344\272\254\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2011/12/22/\347\254\2542-1\345\233\236-twitter-api-\345\213\211\345\274\267\344\274\232--\346\235\261\344\272\254\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
index 30cfe5b208..38e7022bda 100644
--- "a/blog/2011/12/22/\347\254\2542-1\345\233\236-twitter-api-\345\213\211\345\274\267\344\274\232--\346\235\261\344\272\254\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2011/12/22/\347\254\2542-1\345\233\236-twitter-api-\345\213\211\345\274\267\344\274\232--\346\235\261\344\272\254\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
@@ -518,6 +518,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -907,7 +909,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2011/12/28/\344\273\212\345\271\264\343\201\256\346\214\257\343\202\212\350\277\224\343\202\212\343\201\250\346\235\245\345\271\264\343\201\256\346\212\261\350\262\240/index.html" "b/blog/2011/12/28/\344\273\212\345\271\264\343\201\256\346\214\257\343\202\212\350\277\224\343\202\212\343\201\250\346\235\245\345\271\264\343\201\256\346\212\261\350\262\240/index.html"
index 6d54761b66..c844917e5c 100644
--- "a/blog/2011/12/28/\344\273\212\345\271\264\343\201\256\346\214\257\343\202\212\350\277\224\343\202\212\343\201\250\346\235\245\345\271\264\343\201\256\346\212\261\350\262\240/index.html"
+++ "b/blog/2011/12/28/\344\273\212\345\271\264\343\201\256\346\214\257\343\202\212\350\277\224\343\202\212\343\201\250\346\235\245\345\271\264\343\201\256\346\212\261\350\262\240/index.html"
@@ -481,6 +481,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -870,7 +872,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/01/05/\343\201\202\343\201\221\343\201\276\343\201\227\343\201\246\343\201\212\343\202\201\343\201\247\343\201\250\343\201\206\343\201\224\343\201\226\343\201\204\343\201\276\343\201\231\344\274\232\347\244\276\343\201\256\343\203\226\343\203\255\343\202\260\346\233\264\346\226\260/index.html" "b/blog/2012/01/05/\343\201\202\343\201\221\343\201\276\343\201\227\343\201\246\343\201\212\343\202\201\343\201\247\343\201\250\343\201\206\343\201\224\343\201\226\343\201\204\343\201\276\343\201\231\344\274\232\347\244\276\343\201\256\343\203\226\343\203\255\343\202\260\346\233\264\346\226\260/index.html"
index e2e3d5a308..4c0da29c5d 100644
--- "a/blog/2012/01/05/\343\201\202\343\201\221\343\201\276\343\201\227\343\201\246\343\201\212\343\202\201\343\201\247\343\201\250\343\201\206\343\201\224\343\201\226\343\201\204\343\201\276\343\201\231\344\274\232\347\244\276\343\201\256\343\203\226\343\203\255\343\202\260\346\233\264\346\226\260/index.html"
+++ "b/blog/2012/01/05/\343\201\202\343\201\221\343\201\276\343\201\227\343\201\246\343\201\212\343\202\201\343\201\247\343\201\250\343\201\206\343\201\224\343\201\226\343\201\204\343\201\276\343\201\231\344\274\232\347\244\276\343\201\256\343\203\226\343\203\255\343\202\260\346\233\264\346\226\260/index.html"
@@ -276,8 +276,6 @@ <h2>目次</h2>
 <h3>See Also by Hugo</h3>
 <ul>
  
- <li><a href="/blog/2021/12/31/looking-back-2021/">今年の振り返りと来年の抱負（2021）</a></li>
- 
  <li><a href="/blog/2020/12/31/looking-back-2020/">今年の振り返りと来年の抱負（2020）</a></li>
  
  <li><a href="/blog/2017/12/01/whats-happen-at-elastic-in-2017/">2017年のElastic StackとElastic</a></li>
@@ -286,6 +284,8 @@ <h3>See Also by Hugo</h3>
  
  <li><a href="/blog/2013/06/03/octopress%E3%82%92%E8%A9%A6%E3%81%97%E4%B8%AD/">Octopressを試し中(Jugemより移植)</a></li>
  
+ <li><a href="/blog/2011/12/28/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A0/">今年の振り返りと来年の抱負？(Jugemより移植)</a></li>
+ 
 </ul>
 
                 <hr/>
@@ -412,6 +412,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -801,7 +803,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/01/08/lucene-gosen\343\201\256lucene-solr4-0\345\257\276\345\277\234\343\203\226\343\203\251\343\203\263\343\203\201\346\233\264\346\226\260/index.html" "b/blog/2012/01/08/lucene-gosen\343\201\256lucene-solr4-0\345\257\276\345\277\234\343\203\226\343\203\251\343\203\263\343\203\201\346\233\264\346\226\260/index.html"
index 9eed77e4e0..24d8dc9034 100644
--- "a/blog/2012/01/08/lucene-gosen\343\201\256lucene-solr4-0\345\257\276\345\277\234\343\203\226\343\203\251\343\203\263\343\203\201\346\233\264\346\226\260/index.html"
+++ "b/blog/2012/01/08/lucene-gosen\343\201\256lucene-solr4-0\345\257\276\345\277\234\343\203\226\343\203\251\343\203\263\343\203\201\346\233\264\346\226\260/index.html"
@@ -416,6 +416,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -805,7 +807,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/01/19/ossaj\343\201\256\343\203\237\343\203\213\343\202\273\343\203\237\343\203\212\343\203\274\343\201\247\350\251\261\343\201\227\343\202\222\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2012/01/19/ossaj\343\201\256\343\203\237\343\203\213\343\202\273\343\203\237\343\203\212\343\203\274\343\201\247\350\251\261\343\201\227\343\202\222\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html"
index 914544c16f..7b9afc4107 100644
--- "a/blog/2012/01/19/ossaj\343\201\256\343\203\237\343\203\213\343\202\273\343\203\237\343\203\212\343\203\274\343\201\247\350\251\261\343\201\227\343\202\222\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2012/01/19/ossaj\343\201\256\343\203\237\343\203\213\343\202\273\343\203\237\343\203\212\343\203\274\343\201\247\350\251\261\343\201\227\343\202\222\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html"
@@ -415,6 +415,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -804,7 +806,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/01/20/mapr\344\270\255\350\272\253\350\252\254\346\230\216\344\274\232\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2012/01/20/mapr\344\270\255\350\272\253\350\252\254\346\230\216\344\274\232\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
index 12e7421f07..61d8852c16 100644
--- "a/blog/2012/01/20/mapr\344\270\255\350\272\253\350\252\254\346\230\216\344\274\232\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2012/01/20/mapr\344\270\255\350\272\253\350\252\254\346\230\216\344\274\232\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
@@ -526,6 +526,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -915,7 +917,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/01/27/\343\203\242\343\203\274\343\202\267\343\203\247\343\203\216\343\203\255\343\202\270\343\203\2742012-1\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2012/01/27/\343\203\242\343\203\274\343\202\267\343\203\247\343\203\216\343\203\255\343\202\270\343\203\2742012-1\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
index a7a697c8d8..aca91e4f73 100644
--- "a/blog/2012/01/27/\343\203\242\343\203\274\343\202\267\343\203\247\343\203\216\343\203\255\343\202\270\343\203\2742012-1\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2012/01/27/\343\203\242\343\203\274\343\202\267\343\203\247\343\203\216\343\203\255\343\202\270\343\203\2742012-1\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
@@ -531,6 +531,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -920,7 +922,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/01/27/\344\273\212\350\210\210\345\221\263\343\201\214\343\201\202\343\202\213\343\201\223\343\201\250/index.html" "b/blog/2012/01/27/\344\273\212\350\210\210\345\221\263\343\201\214\343\201\202\343\202\213\343\201\223\343\201\250/index.html"
index 1b5ef777a9..b906c0468d 100644
--- "a/blog/2012/01/27/\344\273\212\350\210\210\345\221\263\343\201\214\343\201\202\343\202\213\343\201\223\343\201\250/index.html"
+++ "b/blog/2012/01/27/\344\273\212\350\210\210\345\221\263\343\201\214\343\201\202\343\202\213\343\201\223\343\201\250/index.html"
@@ -448,6 +448,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -837,7 +839,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/02/05/fluentd-meetup-japan\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2012/02/05/fluentd-meetup-japan\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
index 83356f3e91..e4dcf15a89 100644
--- "a/blog/2012/02/05/fluentd-meetup-japan\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2012/02/05/fluentd-meetup-japan\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
@@ -701,6 +701,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1090,7 +1092,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/02/09/hadoop\343\202\275\343\203\274\343\202\271\343\202\263\343\203\274\343\203\211\343\203\252\343\203\274\343\203\207\343\202\243\343\203\263\343\202\260\347\254\2548\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-hadoopreading/index.html" "b/blog/2012/02/09/hadoop\343\202\275\343\203\274\343\202\271\343\202\263\343\203\274\343\203\211\343\203\252\343\203\274\343\203\207\343\202\243\343\203\263\343\202\260\347\254\2548\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-hadoopreading/index.html"
index 78a6112153..77f3950983 100644
--- "a/blog/2012/02/09/hadoop\343\202\275\343\203\274\343\202\271\343\202\263\343\203\274\343\203\211\343\203\252\343\203\274\343\203\207\343\202\243\343\203\263\343\202\260\347\254\2548\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-hadoopreading/index.html"
+++ "b/blog/2012/02/09/hadoop\343\202\275\343\203\274\343\202\271\343\202\263\343\203\274\343\203\211\343\203\252\343\203\274\343\203\207\343\202\243\343\203\263\343\202\260\347\254\2548\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-hadoopreading/index.html"
@@ -534,6 +534,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -923,7 +925,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/02/21/lucene-gosen\343\201\250synonymfilter\343\202\222\345\210\251\347\224\250\343\201\231\343\202\213\343\201\250\343\201\215\343\201\256\346\263\250\346\204\217\347\202\271\345\225\217\351\241\214\347\202\271\347\267\250/index.html" "b/blog/2012/02/21/lucene-gosen\343\201\250synonymfilter\343\202\222\345\210\251\347\224\250\343\201\231\343\202\213\343\201\250\343\201\215\343\201\256\346\263\250\346\204\217\347\202\271\345\225\217\351\241\214\347\202\271\347\267\250/index.html"
index b3fcd1ad54..5660ffc6aa 100644
--- "a/blog/2012/02/21/lucene-gosen\343\201\250synonymfilter\343\202\222\345\210\251\347\224\250\343\201\231\343\202\213\343\201\250\343\201\215\343\201\256\346\263\250\346\204\217\347\202\271\345\225\217\351\241\214\347\202\271\347\267\250/index.html"
+++ "b/blog/2012/02/21/lucene-gosen\343\201\250synonymfilter\343\202\222\345\210\251\347\224\250\343\201\231\343\202\213\343\201\250\343\201\215\343\201\256\346\263\250\346\204\217\347\202\271\345\225\217\351\241\214\347\202\271\347\267\250/index.html"
@@ -473,6 +473,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -862,7 +864,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/02/24/\347\254\2544\345\233\236-twitter-api\345\213\211\345\274\267\344\274\232--\343\203\207\343\202\270\343\202\277\343\203\253\343\203\217\343\203\252\343\202\246\343\203\203\343\203\211--twtr_hack-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2012/02/24/\347\254\2544\345\233\236-twitter-api\345\213\211\345\274\267\344\274\232--\343\203\207\343\202\270\343\202\277\343\203\253\343\203\217\343\203\252\343\202\246\343\203\203\343\203\211--twtr_hack-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
index fd716cefa4..0129430b31 100644
--- "a/blog/2012/02/24/\347\254\2544\345\233\236-twitter-api\345\213\211\345\274\267\344\274\232--\343\203\207\343\202\270\343\202\277\343\203\253\343\203\217\343\203\252\343\202\246\343\203\203\343\203\211--twtr_hack-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2012/02/24/\347\254\2544\345\233\236-twitter-api\345\213\211\345\274\267\344\274\232--\343\203\207\343\202\270\343\202\277\343\203\253\343\203\217\343\203\252\343\202\246\343\203\203\343\203\211--twtr_hack-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
@@ -508,6 +508,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -897,7 +899,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/02/26/\350\246\252\345\255\220\343\201\247\346\245\275\343\201\227\343\202\201\343\202\213-\347\265\265\346\234\254\343\201\247\350\213\261\350\252\236\343\202\222\343\201\257\343\201\230\343\202\201\343\202\213\346\234\254/index.html" "b/blog/2012/02/26/\350\246\252\345\255\220\343\201\247\346\245\275\343\201\227\343\202\201\343\202\213-\347\265\265\346\234\254\343\201\247\350\213\261\350\252\236\343\202\222\343\201\257\343\201\230\343\202\201\343\202\213\346\234\254/index.html"
index f94767decb..1d665c3669 100644
--- "a/blog/2012/02/26/\350\246\252\345\255\220\343\201\247\346\245\275\343\201\227\343\202\201\343\202\213-\347\265\265\346\234\254\343\201\247\350\213\261\350\252\236\343\202\222\343\201\257\343\201\230\343\202\201\343\202\213\346\234\254/index.html"
+++ "b/blog/2012/02/26/\350\246\252\345\255\220\343\201\247\346\245\275\343\201\227\343\202\201\343\202\213-\347\265\265\346\234\254\343\201\247\350\213\261\350\252\236\343\202\222\343\201\257\343\201\230\343\202\201\343\202\213\346\234\254/index.html"
@@ -436,6 +436,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -825,7 +827,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/03/03/clean-coder\343\202\222\350\252\255\343\202\223\343\201\240/index.html" "b/blog/2012/03/03/clean-coder\343\202\222\350\252\255\343\202\223\343\201\240/index.html"
index ee57b36609..2abb1bd2c9 100644
--- "a/blog/2012/03/03/clean-coder\343\202\222\350\252\255\343\202\223\343\201\240/index.html"
+++ "b/blog/2012/03/03/clean-coder\343\202\222\350\252\255\343\202\223\343\201\240/index.html"
@@ -439,6 +439,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -828,7 +830,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/03/09/\347\254\2540\345\233\236-twitter-hack--twtr_hack-\343\201\253\351\201\212\343\201\263\343\201\253\350\241\214\343\201\215\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2012/03/09/\347\254\2540\345\233\236-twitter-hack--twtr_hack-\343\201\253\351\201\212\343\201\263\343\201\253\350\241\214\343\201\215\343\201\276\343\201\227\343\201\237/index.html"
index df1ff733d6..b3a62ef3db 100644
--- "a/blog/2012/03/09/\347\254\2540\345\233\236-twitter-hack--twtr_hack-\343\201\253\351\201\212\343\201\263\343\201\253\350\241\214\343\201\215\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2012/03/09/\347\254\2540\345\233\236-twitter-hack--twtr_hack-\343\201\253\351\201\212\343\201\263\343\201\253\350\241\214\343\201\215\343\201\276\343\201\227\343\201\237/index.html"
@@ -483,6 +483,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -872,7 +874,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/03/14/scala\345\247\213\343\202\201\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2012/03/14/scala\345\247\213\343\202\201\343\201\276\343\201\227\343\201\237/index.html"
index bdf1379f72..93a2b18c1c 100644
--- "a/blog/2012/03/14/scala\345\247\213\343\202\201\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2012/03/14/scala\345\247\213\343\202\201\343\201\276\343\201\227\343\201\237/index.html"
@@ -447,6 +447,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -836,7 +838,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/03/20/\350\207\252\345\210\206\343\201\256\345\260\217\343\201\225\343\201\252\347\256\261\343\201\213\343\202\211\350\204\261\345\207\272\343\201\231\343\202\213\346\226\271\346\263\225\343\202\222\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2012/03/20/\350\207\252\345\210\206\343\201\256\345\260\217\343\201\225\343\201\252\347\256\261\343\201\213\343\202\211\350\204\261\345\207\272\343\201\231\343\202\213\346\226\271\346\263\225\343\202\222\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237/index.html"
index 889c739f9b..d75a2a710b 100644
--- "a/blog/2012/03/20/\350\207\252\345\210\206\343\201\256\345\260\217\343\201\225\343\201\252\347\256\261\343\201\213\343\202\211\350\204\261\345\207\272\343\201\231\343\202\213\346\226\271\346\263\225\343\202\222\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2012/03/20/\350\207\252\345\210\206\343\201\256\345\260\217\343\201\225\343\201\252\347\256\261\343\201\213\343\202\211\350\204\261\345\207\272\343\201\231\343\202\213\346\226\271\346\263\225\343\202\222\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237/index.html"
@@ -454,6 +454,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -843,7 +845,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/03/22/\347\254\2545\345\233\236-twitter-api\345\213\211\345\274\267\344\274\232--\346\270\213\350\260\267--twtr_hack/index.html" "b/blog/2012/03/22/\347\254\2545\345\233\236-twitter-api\345\213\211\345\274\267\344\274\232--\346\270\213\350\260\267--twtr_hack/index.html"
index 0b02c4dca0..a3b0e402f1 100644
--- "a/blog/2012/03/22/\347\254\2545\345\233\236-twitter-api\345\213\211\345\274\267\344\274\232--\346\270\213\350\260\267--twtr_hack/index.html"
+++ "b/blog/2012/03/22/\347\254\2545\345\233\236-twitter-api\345\213\211\345\274\267\344\274\232--\346\270\213\350\260\267--twtr_hack/index.html"
@@ -553,6 +553,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -942,7 +944,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/03/25/\344\271\205\343\200\205\343\201\253mac-mini\343\201\256\343\201\223\343\201\250\343\201\247\343\202\202/index.html" "b/blog/2012/03/25/\344\271\205\343\200\205\343\201\253mac-mini\343\201\256\343\201\223\343\201\250\343\201\247\343\202\202/index.html"
index b3fd1ddfb3..d561263f68 100644
--- "a/blog/2012/03/25/\344\271\205\343\200\205\343\201\253mac-mini\343\201\256\343\201\223\343\201\250\343\201\247\343\202\202/index.html"
+++ "b/blog/2012/03/25/\344\271\205\343\200\205\343\201\253mac-mini\343\201\256\343\201\223\343\201\250\343\201\247\343\202\202/index.html"
@@ -433,6 +433,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -822,7 +824,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/03/27/\351\207\215\350\246\201lucene-gosen\343\201\256\346\254\241\346\234\237\343\203\252\343\203\252\343\203\274\343\202\271\343\201\253\343\201\244\343\201\204\343\201\246/index.html" "b/blog/2012/03/27/\351\207\215\350\246\201lucene-gosen\343\201\256\346\254\241\346\234\237\343\203\252\343\203\252\343\203\274\343\202\271\343\201\253\343\201\244\343\201\204\343\201\246/index.html"
index e77eb79ef2..5e5a7a2665 100644
--- "a/blog/2012/03/27/\351\207\215\350\246\201lucene-gosen\343\201\256\346\254\241\346\234\237\343\203\252\343\203\252\343\203\274\343\202\271\343\201\253\343\201\244\343\201\204\343\201\246/index.html"
+++ "b/blog/2012/03/27/\351\207\215\350\246\201lucene-gosen\343\201\256\346\254\241\346\234\237\343\203\252\343\203\252\343\203\274\343\202\271\343\201\253\343\201\244\343\201\204\343\201\246/index.html"
@@ -446,6 +446,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -835,7 +837,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/04/02/\351\207\215\350\246\201lucene-gosen-2-0-0\343\203\252\343\203\252\343\203\274\343\202\271/index.html" "b/blog/2012/04/02/\351\207\215\350\246\201lucene-gosen-2-0-0\343\203\252\343\203\252\343\203\274\343\202\271/index.html"
index 3db4fa2659..bb34dfd279 100644
--- "a/blog/2012/04/02/\351\207\215\350\246\201lucene-gosen-2-0-0\343\203\252\343\203\252\343\203\274\343\202\271/index.html"
+++ "b/blog/2012/04/02/\351\207\215\350\246\201lucene-gosen-2-0-0\343\203\252\343\203\252\343\203\274\343\202\271/index.html"
@@ -552,6 +552,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -941,7 +943,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/04/05/lucene-gosen\343\201\256java7\343\201\247\343\201\256\343\203\206\343\202\271\343\203\210\345\244\261\346\225\227\345\225\217\351\241\214\343\201\256\345\257\276\345\277\234/index.html" "b/blog/2012/04/05/lucene-gosen\343\201\256java7\343\201\247\343\201\256\343\203\206\343\202\271\343\203\210\345\244\261\346\225\227\345\225\217\351\241\214\343\201\256\345\257\276\345\277\234/index.html"
index 0c0896d829..a3d61bd4b7 100644
--- "a/blog/2012/04/05/lucene-gosen\343\201\256java7\343\201\247\343\201\256\343\203\206\343\202\271\343\203\210\345\244\261\346\225\227\345\225\217\351\241\214\343\201\256\345\257\276\345\277\234/index.html"
+++ "b/blog/2012/04/05/lucene-gosen\343\201\256java7\343\201\247\343\201\256\343\203\206\343\202\271\343\203\210\345\244\261\346\225\227\345\225\217\351\241\214\343\201\256\345\257\276\345\277\234/index.html"
@@ -422,6 +422,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -811,7 +813,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/04/06/java-one-tokyo-2012-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-javaonejp/index.html" "b/blog/2012/04/06/java-one-tokyo-2012-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-javaonejp/index.html"
index a31ca3355e..972b7d1807 100644
--- "a/blog/2012/04/06/java-one-tokyo-2012-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-javaonejp/index.html"
+++ "b/blog/2012/04/06/java-one-tokyo-2012-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-javaonejp/index.html"
@@ -713,6 +713,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1102,7 +1104,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/04/12/\343\203\241\343\203\242amazon-cloudsearch\343\201\214\345\207\272\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237\343\202\210/index.html" "b/blog/2012/04/12/\343\203\241\343\203\242amazon-cloudsearch\343\201\214\345\207\272\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237\343\202\210/index.html"
index 4159fee5da..50540d086b 100644
--- "a/blog/2012/04/12/\343\203\241\343\203\242amazon-cloudsearch\343\201\214\345\207\272\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237\343\202\210/index.html"
+++ "b/blog/2012/04/12/\343\203\241\343\203\242amazon-cloudsearch\343\201\214\345\207\272\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237\343\202\210/index.html"
@@ -423,6 +423,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -812,7 +814,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/04/14/apache-solr\345\205\245\351\226\200\343\201\256\343\202\265\343\203\263\343\203\227\343\203\253\343\201\256kuromoji\343\201\250lucene-gosen\345\257\276\345\277\2342\347\253\2404\347\253\240/index.html" "b/blog/2012/04/14/apache-solr\345\205\245\351\226\200\343\201\256\343\202\265\343\203\263\343\203\227\343\203\253\343\201\256kuromoji\343\201\250lucene-gosen\345\257\276\345\277\2342\347\253\2404\347\253\240/index.html"
index 910ceb2adb..9f01b663c3 100644
--- "a/blog/2012/04/14/apache-solr\345\205\245\351\226\200\343\201\256\343\202\265\343\203\263\343\203\227\343\203\253\343\201\256kuromoji\343\201\250lucene-gosen\345\257\276\345\277\2342\347\253\2404\347\253\240/index.html"
+++ "b/blog/2012/04/14/apache-solr\345\205\245\351\226\200\343\201\256\343\202\265\343\203\263\343\203\227\343\203\253\343\201\256kuromoji\343\201\250lucene-gosen\345\257\276\345\277\2342\347\253\2404\347\253\240/index.html"
@@ -491,6 +491,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -880,7 +882,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/04/14/lucene-solr-3-6-0\343\203\252\343\203\252\343\203\274\343\202\271---apache-solr\345\205\245\351\226\200\343\201\256\343\202\265\343\203\263\343\203\227\343\203\253\343\201\256kuromoji\343\201\250lucene-gosen\345\257\276\345\277\2341\347\253\240/index.html" "b/blog/2012/04/14/lucene-solr-3-6-0\343\203\252\343\203\252\343\203\274\343\202\271---apache-solr\345\205\245\351\226\200\343\201\256\343\202\265\343\203\263\343\203\227\343\203\253\343\201\256kuromoji\343\201\250lucene-gosen\345\257\276\345\277\2341\347\253\240/index.html"
index 8cfeef7595..347bc14512 100644
--- "a/blog/2012/04/14/lucene-solr-3-6-0\343\203\252\343\203\252\343\203\274\343\202\271---apache-solr\345\205\245\351\226\200\343\201\256\343\202\265\343\203\263\343\203\227\343\203\253\343\201\256kuromoji\343\201\250lucene-gosen\345\257\276\345\277\2341\347\253\240/index.html"
+++ "b/blog/2012/04/14/lucene-solr-3-6-0\343\203\252\343\203\252\343\203\274\343\202\271---apache-solr\345\205\245\351\226\200\343\201\256\343\202\265\343\203\263\343\203\227\343\203\253\343\201\256kuromoji\343\201\250lucene-gosen\345\257\276\345\277\2341\347\253\240/index.html"
@@ -462,6 +462,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -851,7 +853,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/04/17/solr-3-6-0\343\201\256cjk\343\201\256\350\250\255\345\256\232\343\201\250synonymfilterfactory\343\201\256\346\260\227\343\201\253\343\201\252\343\202\213\347\202\271/index.html" "b/blog/2012/04/17/solr-3-6-0\343\201\256cjk\343\201\256\350\250\255\345\256\232\343\201\250synonymfilterfactory\343\201\256\346\260\227\343\201\253\343\201\252\343\202\213\347\202\271/index.html"
index cc35a964f5..b4c3a5b854 100644
--- "a/blog/2012/04/17/solr-3-6-0\343\201\256cjk\343\201\256\350\250\255\345\256\232\343\201\250synonymfilterfactory\343\201\256\346\260\227\343\201\253\343\201\252\343\202\213\347\202\271/index.html"
+++ "b/blog/2012/04/17/solr-3-6-0\343\201\256cjk\343\201\256\350\250\255\345\256\232\343\201\250synonymfilterfactory\343\201\256\346\260\227\343\201\253\343\201\252\343\202\213\347\202\271/index.html"
@@ -445,6 +445,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -834,7 +836,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/04/21/heroku-jp-meetup-4\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-herokujp/index.html" "b/blog/2012/04/21/heroku-jp-meetup-4\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-herokujp/index.html"
index 4c5fec5896..81ed16adfd 100644
--- "a/blog/2012/04/21/heroku-jp-meetup-4\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-herokujp/index.html"
+++ "b/blog/2012/04/21/heroku-jp-meetup-4\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-herokujp/index.html"
@@ -509,6 +509,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -898,7 +900,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/04/30/id\343\201\256\347\247\230\345\257\206\343\202\222\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2012/04/30/id\343\201\256\347\247\230\345\257\206\343\202\222\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237/index.html"
index 7bba721227..07541247a4 100644
--- "a/blog/2012/04/30/id\343\201\256\347\247\230\345\257\206\343\202\222\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2012/04/30/id\343\201\256\347\247\230\345\257\206\343\202\222\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237/index.html"
@@ -423,6 +423,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -812,7 +814,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/05/09/lucene-gosen-2-0-1\343\203\252\343\203\252\343\203\274\343\202\271java7\345\257\276\345\277\234/index.html" "b/blog/2012/05/09/lucene-gosen-2-0-1\343\203\252\343\203\252\343\203\274\343\202\271java7\345\257\276\345\277\234/index.html"
index 62e3d57624..0b73082394 100644
--- "a/blog/2012/05/09/lucene-gosen-2-0-1\343\203\252\343\203\252\343\203\274\343\202\271java7\345\257\276\345\277\234/index.html"
+++ "b/blog/2012/05/09/lucene-gosen-2-0-1\343\203\252\343\203\252\343\203\274\343\202\271java7\345\257\276\345\277\234/index.html"
@@ -412,6 +412,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -801,7 +803,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/05/16/playframework-2-0-java\343\201\256\346\226\271-\343\202\222\350\247\246\343\201\243\343\201\246\343\201\277\343\201\246\343\202\213/index.html" "b/blog/2012/05/16/playframework-2-0-java\343\201\256\346\226\271-\343\202\222\350\247\246\343\201\243\343\201\246\343\201\277\343\201\246\343\202\213/index.html"
index 1ecdf53d19..1b7217ce4c 100644
--- "a/blog/2012/05/16/playframework-2-0-java\343\201\256\346\226\271-\343\202\222\350\247\246\343\201\243\343\201\246\343\201\277\343\201\246\343\202\213/index.html"
+++ "b/blog/2012/05/16/playframework-2-0-java\343\201\256\346\226\271-\343\202\222\350\247\246\343\201\243\343\201\246\343\201\277\343\201\246\343\202\213/index.html"
@@ -427,6 +427,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -816,7 +818,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/05/29/jjug-ccc-2012-spring\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2012/05/29/jjug-ccc-2012-spring\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html"
index e77ee18856..4e40aacc5e 100644
--- "a/blog/2012/05/29/jjug-ccc-2012-spring\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2012/05/29/jjug-ccc-2012-spring\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html"
@@ -656,6 +656,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1045,7 +1047,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/05/31/\343\202\252\343\203\274\343\203\227\343\203\263\343\202\275\343\203\274\343\202\271\343\201\270\343\201\256\350\262\242\347\214\256\343\201\256\343\202\271\343\202\271\343\203\241/index.html" "b/blog/2012/05/31/\343\202\252\343\203\274\343\203\227\343\203\263\343\202\275\343\203\274\343\202\271\343\201\270\343\201\256\350\262\242\347\214\256\343\201\256\343\202\271\343\202\271\343\203\241/index.html"
index 0bf62fc683..e42602cce5 100644
--- "a/blog/2012/05/31/\343\202\252\343\203\274\343\203\227\343\203\263\343\202\275\343\203\274\343\202\271\343\201\270\343\201\256\350\262\242\347\214\256\343\201\256\343\202\271\343\202\271\343\203\241/index.html"
+++ "b/blog/2012/05/31/\343\202\252\343\203\274\343\203\227\343\203\263\343\202\275\343\203\274\343\202\271\343\201\270\343\201\256\350\262\242\347\214\256\343\201\256\343\202\271\343\202\271\343\203\241/index.html"
@@ -425,6 +425,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -814,7 +816,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/06/05/trunk\343\201\256\343\203\251\343\202\244\343\203\226\343\203\251\343\203\252\345\267\256\343\201\227\346\233\277\343\201\210lucene-solr3-6-0\343\201\250\343\203\251\343\203\263\343\203\200\343\203\240\343\203\206\343\202\271\343\203\210\343\201\256\345\244\261\346\225\227\343\201\253\343\201\244\343\201\204\343\201\246/index.html" "b/blog/2012/06/05/trunk\343\201\256\343\203\251\343\202\244\343\203\226\343\203\251\343\203\252\345\267\256\343\201\227\346\233\277\343\201\210lucene-solr3-6-0\343\201\250\343\203\251\343\203\263\343\203\200\343\203\240\343\203\206\343\202\271\343\203\210\343\201\256\345\244\261\346\225\227\343\201\253\343\201\244\343\201\204\343\201\246/index.html"
index cec130c990..a47cd29487 100644
--- "a/blog/2012/06/05/trunk\343\201\256\343\203\251\343\202\244\343\203\226\343\203\251\343\203\252\345\267\256\343\201\227\346\233\277\343\201\210lucene-solr3-6-0\343\201\250\343\203\251\343\203\263\343\203\200\343\203\240\343\203\206\343\202\271\343\203\210\343\201\256\345\244\261\346\225\227\343\201\253\343\201\244\343\201\204\343\201\246/index.html"
+++ "b/blog/2012/06/05/trunk\343\201\256\343\203\251\343\202\244\343\203\226\343\203\251\343\203\252\345\267\256\343\201\227\346\233\277\343\201\210lucene-solr3-6-0\343\201\250\343\203\251\343\203\263\343\203\200\343\203\240\343\203\206\343\202\271\343\203\210\343\201\256\345\244\261\346\225\227\343\201\253\343\201\244\343\201\204\343\201\246/index.html"
@@ -451,6 +451,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -840,7 +842,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/06/06/issue32\343\201\253\343\201\244\343\201\204\343\201\2464096\343\201\256\345\243\201/index.html" "b/blog/2012/06/06/issue32\343\201\253\343\201\244\343\201\204\343\201\2464096\343\201\256\345\243\201/index.html"
index c704a9512d..2be8844525 100644
--- "a/blog/2012/06/06/issue32\343\201\253\343\201\244\343\201\204\343\201\2464096\343\201\256\345\243\201/index.html"
+++ "b/blog/2012/06/06/issue32\343\201\253\343\201\244\343\201\204\343\201\2464096\343\201\256\345\243\201/index.html"
@@ -445,6 +445,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -834,7 +836,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/06/07/lucene-gosen-2-0-2\343\203\252\343\203\252\343\203\274\343\202\271\343\203\252\343\202\275\343\203\274\343\202\271\345\221\250\343\202\212\343\201\256\346\224\271\345\226\204\343\201\252\343\201\251/index.html" "b/blog/2012/06/07/lucene-gosen-2-0-2\343\203\252\343\203\252\343\203\274\343\202\271\343\203\252\343\202\275\343\203\274\343\202\271\345\221\250\343\202\212\343\201\256\346\224\271\345\226\204\343\201\252\343\201\251/index.html"
index c97f878c2a..ae570016b7 100644
--- "a/blog/2012/06/07/lucene-gosen-2-0-2\343\203\252\343\203\252\343\203\274\343\202\271\343\203\252\343\202\275\343\203\274\343\202\271\345\221\250\343\202\212\343\201\256\346\224\271\345\226\204\343\201\252\343\201\251/index.html"
+++ "b/blog/2012/06/07/lucene-gosen-2-0-2\343\203\252\343\203\252\343\203\274\343\202\271\343\203\252\343\202\275\343\203\274\343\202\271\345\221\250\343\202\212\343\201\256\346\224\271\345\226\204\343\201\252\343\201\251/index.html"
@@ -412,6 +412,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -801,7 +803,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/06/13/twitter\343\201\214\345\205\254\351\226\213\343\201\227\343\201\237\345\210\206\346\225\243\343\203\210\343\203\254\343\203\274\343\202\267\343\203\263\343\202\260\350\277\275\350\267\241\343\202\267\343\202\271\343\203\206\343\203\240zipkin/index.html" "b/blog/2012/06/13/twitter\343\201\214\345\205\254\351\226\213\343\201\227\343\201\237\345\210\206\346\225\243\343\203\210\343\203\254\343\203\274\343\202\267\343\203\263\343\202\260\350\277\275\350\267\241\343\202\267\343\202\271\343\203\206\343\203\240zipkin/index.html"
index fbb11ed3c0..45a486b5d5 100644
--- "a/blog/2012/06/13/twitter\343\201\214\345\205\254\351\226\213\343\201\227\343\201\237\345\210\206\346\225\243\343\203\210\343\203\254\343\203\274\343\202\267\343\203\263\343\202\260\350\277\275\350\267\241\343\202\267\343\202\271\343\203\206\343\203\240zipkin/index.html"
+++ "b/blog/2012/06/13/twitter\343\201\214\345\205\254\351\226\213\343\201\227\343\201\237\345\210\206\346\225\243\343\203\210\343\203\254\343\203\274\343\202\267\343\203\263\343\202\260\350\277\275\350\267\241\343\202\267\343\202\271\343\203\206\343\203\240zipkin/index.html"
@@ -422,6 +422,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -811,7 +813,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/06/14/autogeneratephrasequeries\343\201\256\343\203\207\343\203\225\343\202\251\343\203\253\343\203\210\345\200\244\343\201\253\343\201\244\343\201\204\343\201\246/index.html" "b/blog/2012/06/14/autogeneratephrasequeries\343\201\256\343\203\207\343\203\225\343\202\251\343\203\253\343\203\210\345\200\244\343\201\253\343\201\244\343\201\204\343\201\246/index.html"
index 2735879788..032a0c793e 100644
--- "a/blog/2012/06/14/autogeneratephrasequeries\343\201\256\343\203\207\343\203\225\343\202\251\343\203\253\343\203\210\345\200\244\343\201\253\343\201\244\343\201\204\343\201\246/index.html"
+++ "b/blog/2012/06/14/autogeneratephrasequeries\343\201\256\343\203\207\343\203\225\343\202\251\343\203\253\343\203\210\345\200\244\343\201\253\343\201\244\343\201\204\343\201\246/index.html"
@@ -420,6 +420,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -809,7 +811,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/06/15/zipkin\343\201\256readme\343\202\222\350\252\255\343\202\223\343\201\247\343\202\213\343\202\257\343\203\251\343\202\244\343\202\242\343\203\263\343\203\210\345\221\250\343\202\212\343\201\253\343\201\244\343\201\204\343\201\246/index.html" "b/blog/2012/06/15/zipkin\343\201\256readme\343\202\222\350\252\255\343\202\223\343\201\247\343\202\213\343\202\257\343\203\251\343\202\244\343\202\242\343\203\263\343\203\210\345\221\250\343\202\212\343\201\253\343\201\244\343\201\204\343\201\246/index.html"
index 88e0d06ed7..0ab4606d44 100644
--- "a/blog/2012/06/15/zipkin\343\201\256readme\343\202\222\350\252\255\343\202\223\343\201\247\343\202\213\343\202\257\343\203\251\343\202\244\343\202\242\343\203\263\343\203\210\345\221\250\343\202\212\343\201\253\343\201\244\343\201\204\343\201\246/index.html"
+++ "b/blog/2012/06/15/zipkin\343\201\256readme\343\202\222\350\252\255\343\202\223\343\201\247\343\202\213\343\202\257\343\203\251\343\202\244\343\202\242\343\203\263\343\203\210\345\221\250\343\202\212\343\201\253\343\201\244\343\201\204\343\201\246/index.html"
@@ -474,6 +474,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -863,7 +865,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/06/16/zipkin\343\201\256readme\350\252\255\343\202\223\343\201\247\343\202\213\343\201\235\343\201\256\357\274\222\346\256\213\343\202\212/index.html" "b/blog/2012/06/16/zipkin\343\201\256readme\350\252\255\343\202\223\343\201\247\343\202\213\343\201\235\343\201\256\357\274\222\346\256\213\343\202\212/index.html"
index 704f6941bd..85219d06ac 100644
--- "a/blog/2012/06/16/zipkin\343\201\256readme\350\252\255\343\202\223\343\201\247\343\202\213\343\201\235\343\201\256\357\274\222\346\256\213\343\202\212/index.html"
+++ "b/blog/2012/06/16/zipkin\343\201\256readme\350\252\255\343\202\223\343\201\247\343\202\213\343\201\235\343\201\256\357\274\222\346\256\213\343\202\212/index.html"
@@ -564,6 +564,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -953,7 +955,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/06/18/lucene-gosen\343\201\256unidic\345\257\276\345\277\234/index.html" "b/blog/2012/06/18/lucene-gosen\343\201\256unidic\345\257\276\345\277\234/index.html"
index 021da01f6c..a6a446cce1 100644
--- "a/blog/2012/06/18/lucene-gosen\343\201\256unidic\345\257\276\345\277\234/index.html"
+++ "b/blog/2012/06/18/lucene-gosen\343\201\256unidic\345\257\276\345\277\234/index.html"
@@ -459,6 +459,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -848,7 +850,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/06/26/hadoop\343\202\275\343\203\274\343\202\271\343\202\263\343\203\274\343\203\211\343\203\252\343\203\274\343\203\207\343\202\243\343\203\263\343\202\260\347\254\25410\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-hadoopreading/index.html" "b/blog/2012/06/26/hadoop\343\202\275\343\203\274\343\202\271\343\202\263\343\203\274\343\203\211\343\203\252\343\203\274\343\203\207\343\202\243\343\203\263\343\202\260\347\254\25410\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-hadoopreading/index.html"
index 62ee8b1a58..2b1bddb596 100644
--- "a/blog/2012/06/26/hadoop\343\202\275\343\203\274\343\202\271\343\202\263\343\203\274\343\203\211\343\203\252\343\203\274\343\203\207\343\202\243\343\203\263\343\202\260\347\254\25410\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-hadoopreading/index.html"
+++ "b/blog/2012/06/26/hadoop\343\202\275\343\203\274\343\202\271\343\202\263\343\203\274\343\203\211\343\203\252\343\203\274\343\203\207\343\202\243\343\203\263\343\202\260\347\254\25410\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-hadoopreading/index.html"
@@ -627,6 +627,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1016,7 +1018,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/07/04/solr\345\213\211\345\274\267\344\274\232\347\254\2548\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237--solrjp/index.html" "b/blog/2012/07/04/solr\345\213\211\345\274\267\344\274\232\347\254\2548\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237--solrjp/index.html"
index 6f9a4f6edc..7cd9d29ef5 100644
--- "a/blog/2012/07/04/solr\345\213\211\345\274\267\344\274\232\347\254\2548\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237--solrjp/index.html"
+++ "b/blog/2012/07/04/solr\345\213\211\345\274\267\344\274\232\347\254\2548\345\233\236\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237--solrjp/index.html"
@@ -556,6 +556,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -945,7 +947,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/07/05/lucene-gosen\343\201\256lucene-solr4-0-alpha\345\257\276\345\277\234/index.html" "b/blog/2012/07/05/lucene-gosen\343\201\256lucene-solr4-0-alpha\345\257\276\345\277\234/index.html"
index 084b4effb2..24cafa31a4 100644
--- "a/blog/2012/07/05/lucene-gosen\343\201\256lucene-solr4-0-alpha\345\257\276\345\277\234/index.html"
+++ "b/blog/2012/07/05/lucene-gosen\343\201\256lucene-solr4-0-alpha\345\257\276\345\277\234/index.html"
@@ -412,6 +412,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -801,7 +803,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/07/13/mir\350\274\252\350\252\255\344\274\232\345\247\213\343\202\201\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2012/07/13/mir\350\274\252\350\252\255\344\274\232\345\247\213\343\202\201\343\201\276\343\201\227\343\201\237/index.html"
index 546c69bb6f..a4bb0dde71 100644
--- "a/blog/2012/07/13/mir\350\274\252\350\252\255\344\274\232\345\247\213\343\202\201\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2012/07/13/mir\350\274\252\350\252\255\344\274\232\345\247\213\343\202\201\343\201\276\343\201\227\343\201\237/index.html"
@@ -439,6 +439,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -828,7 +830,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/07/13/partial-update\343\201\250copyfield\343\201\256\343\203\220\343\202\260solr-4-0-alpha/index.html" "b/blog/2012/07/13/partial-update\343\201\250copyfield\343\201\256\343\203\220\343\202\260solr-4-0-alpha/index.html"
index 91bbd80f24..ce9078c23e 100644
--- "a/blog/2012/07/13/partial-update\343\201\250copyfield\343\201\256\343\203\220\343\202\260solr-4-0-alpha/index.html"
+++ "b/blog/2012/07/13/partial-update\343\201\250copyfield\343\201\256\343\203\220\343\202\260solr-4-0-alpha/index.html"
@@ -521,6 +521,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -910,7 +912,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/07/28/python-developers-festa-2012-07\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\227\343\202\203\343\201\271\343\201\243\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237--pyfes/index.html" "b/blog/2012/07/28/python-developers-festa-2012-07\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\227\343\202\203\343\201\271\343\201\243\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237--pyfes/index.html"
index a91df2b801..2c8201a5af 100644
--- "a/blog/2012/07/28/python-developers-festa-2012-07\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\227\343\202\203\343\201\271\343\201\243\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237--pyfes/index.html"
+++ "b/blog/2012/07/28/python-developers-festa-2012-07\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\227\343\202\203\343\201\271\343\201\243\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237--pyfes/index.html"
@@ -539,6 +539,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -928,7 +930,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/08/02/twitter-\345\213\211\345\274\267\344\274\232--twtr_hack-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2012/08/02/twitter-\345\213\211\345\274\267\344\274\232--twtr_hack-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
index e7d241a156..8c8d72be00 100644
--- "a/blog/2012/08/02/twitter-\345\213\211\345\274\267\344\274\232--twtr_hack-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2012/08/02/twitter-\345\213\211\345\274\267\344\274\232--twtr_hack-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
@@ -502,6 +502,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -891,7 +893,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/08/23/fluentd-meetup-in-japan--2--fluentd-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2012/08/23/fluentd-meetup-in-japan--2--fluentd-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
index 89de724861..72485d666f 100644
--- "a/blog/2012/08/23/fluentd-meetup-in-japan--2--fluentd-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2012/08/23/fluentd-meetup-in-japan--2--fluentd-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
@@ -554,6 +554,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -943,7 +945,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/09/03/\343\203\241\343\202\244\343\203\263mba\343\202\222mountain-lion\343\201\253\343\202\242\343\203\203\343\203\227\343\203\207\343\203\274\343\203\210\343\201\204\343\202\215\343\201\204\343\202\215\347\242\272\350\252\215\344\270\255/index.html" "b/blog/2012/09/03/\343\203\241\343\202\244\343\203\263mba\343\202\222mountain-lion\343\201\253\343\202\242\343\203\203\343\203\227\343\203\207\343\203\274\343\203\210\343\201\204\343\202\215\343\201\204\343\202\215\347\242\272\350\252\215\344\270\255/index.html"
index af10485b14..956fa731a7 100644
--- "a/blog/2012/09/03/\343\203\241\343\202\244\343\203\263mba\343\202\222mountain-lion\343\201\253\343\202\242\343\203\203\343\203\227\343\203\207\343\203\274\343\203\210\343\201\204\343\202\215\343\201\204\343\202\215\347\242\272\350\252\215\344\270\255/index.html"
+++ "b/blog/2012/09/03/\343\203\241\343\202\244\343\203\263mba\343\202\222mountain-lion\343\201\253\343\202\242\343\203\203\343\203\227\343\203\207\343\203\274\343\203\210\343\201\204\343\202\215\343\201\204\343\202\215\347\242\272\350\252\215\344\270\255/index.html"
@@ -459,6 +459,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -848,7 +850,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/09/21/pfi\343\202\252\343\203\274\343\203\227\343\203\263\343\202\273\343\203\237\343\203\212\343\203\2742012\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237--pfiopen2012/index.html" "b/blog/2012/09/21/pfi\343\202\252\343\203\274\343\203\227\343\203\263\343\202\273\343\203\237\343\203\212\343\203\2742012\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237--pfiopen2012/index.html"
index fc929441d2..02047bdc37 100644
--- "a/blog/2012/09/21/pfi\343\202\252\343\203\274\343\203\227\343\203\263\343\202\273\343\203\237\343\203\212\343\203\2742012\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237--pfiopen2012/index.html"
+++ "b/blog/2012/09/21/pfi\343\202\252\343\203\274\343\203\227\343\203\263\343\202\273\343\203\237\343\203\212\343\203\2742012\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237--pfiopen2012/index.html"
@@ -594,6 +594,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -983,7 +985,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/09/26/lucid\343\201\256grant-ingersoll\343\201\225\343\202\223\343\201\256\350\254\233\346\274\224\343\202\222\350\201\236\343\201\204\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2012/09/26/lucid\343\201\256grant-ingersoll\343\201\225\343\202\223\343\201\256\350\254\233\346\274\224\343\202\222\350\201\236\343\201\204\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html"
index 33643302ae..cc9983aac9 100644
--- "a/blog/2012/09/26/lucid\343\201\256grant-ingersoll\343\201\225\343\202\223\343\201\256\350\254\233\346\274\224\343\202\222\350\201\236\343\201\204\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2012/09/26/lucid\343\201\256grant-ingersoll\343\201\225\343\202\223\343\201\256\350\254\233\346\274\224\343\202\222\350\201\236\343\201\204\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html"
@@ -497,6 +497,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -886,7 +888,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/10/12/lucene-solr-4-0-0\343\203\252\343\203\252\343\203\274\343\202\271lucene-gosen\343\201\2564-0\345\257\276\345\277\234/index.html" "b/blog/2012/10/12/lucene-solr-4-0-0\343\203\252\343\203\252\343\203\274\343\202\271lucene-gosen\343\201\2564-0\345\257\276\345\277\234/index.html"
index 719455e015..5c02fff2ef 100644
--- "a/blog/2012/10/12/lucene-solr-4-0-0\343\203\252\343\203\252\343\203\274\343\202\271lucene-gosen\343\201\2564-0\345\257\276\345\277\234/index.html"
+++ "b/blog/2012/10/12/lucene-solr-4-0-0\343\203\252\343\203\252\343\203\274\343\202\271lucene-gosen\343\201\2564-0\345\257\276\345\277\234/index.html"
@@ -425,6 +425,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -814,7 +816,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/11/10/aws-\343\203\223\343\203\203\343\202\260\343\203\207\343\203\274\343\202\277\346\264\273\347\224\250\344\272\213\344\276\213\343\202\273\343\203\237\343\203\212\343\203\274\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-jawsug/index.html" "b/blog/2012/11/10/aws-\343\203\223\343\203\203\343\202\260\343\203\207\343\203\274\343\202\277\346\264\273\347\224\250\344\272\213\344\276\213\343\202\273\343\203\237\343\203\212\343\203\274\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-jawsug/index.html"
index 2afbda0c4f..231f3a3d33 100644
--- "a/blog/2012/11/10/aws-\343\203\223\343\203\203\343\202\260\343\203\207\343\203\274\343\202\277\346\264\273\347\224\250\344\272\213\344\276\213\343\202\273\343\203\237\343\203\212\343\203\274\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-jawsug/index.html"
+++ "b/blog/2012/11/10/aws-\343\203\223\343\203\203\343\202\260\343\203\207\343\203\274\343\202\277\346\264\273\347\224\250\344\272\213\344\276\213\343\202\273\343\203\237\343\203\212\343\203\274\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-jawsug/index.html"
@@ -601,6 +601,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -990,7 +992,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/11/26/\347\254\2549\345\233\236solr\345\213\211\345\274\267\344\274\232\343\202\222\344\270\273\345\202\254\343\201\227\343\201\276\343\201\227\343\201\237-solrjp/index.html" "b/blog/2012/11/26/\347\254\2549\345\233\236solr\345\213\211\345\274\267\344\274\232\343\202\222\344\270\273\345\202\254\343\201\227\343\201\276\343\201\227\343\201\237-solrjp/index.html"
index 86ddc6a5a5..b27743ce15 100644
--- "a/blog/2012/11/26/\347\254\2549\345\233\236solr\345\213\211\345\274\267\344\274\232\343\202\222\344\270\273\345\202\254\343\201\227\343\201\276\343\201\227\343\201\237-solrjp/index.html"
+++ "b/blog/2012/11/26/\347\254\2549\345\233\236solr\345\213\211\345\274\267\344\274\232\343\202\222\344\270\273\345\202\254\343\201\227\343\201\276\343\201\227\343\201\237-solrjp/index.html"
@@ -557,6 +557,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -946,7 +948,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/11/29/dsirnlp-3-5\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237emacs\345\256\237\350\267\265\345\205\245\351\226\200\343\202\222\351\240\202\343\201\204\343\201\241\343\202\203\343\201\204\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2012/11/29/dsirnlp-3-5\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237emacs\345\256\237\350\267\265\345\205\245\351\226\200\343\202\222\351\240\202\343\201\204\343\201\241\343\202\203\343\201\204\343\201\276\343\201\227\343\201\237/index.html"
index 76214ffd99..c34e60337f 100644
--- "a/blog/2012/11/29/dsirnlp-3-5\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237emacs\345\256\237\350\267\265\345\205\245\351\226\200\343\202\222\351\240\202\343\201\204\343\201\241\343\202\203\343\201\204\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2012/11/29/dsirnlp-3-5\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237emacs\345\256\237\350\267\265\345\205\245\351\226\200\343\202\222\351\240\202\343\201\204\343\201\241\343\202\203\343\201\204\343\201\276\343\201\227\343\201\237/index.html"
@@ -546,6 +546,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -935,7 +937,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/12/11/\347\254\254\344\270\200\345\233\236-jetbrains\343\203\246\343\203\274\343\202\266\343\203\274\343\202\260\343\203\253\343\203\274\343\203\227--jbugj-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2012/12/11/\347\254\254\344\270\200\345\233\236-jetbrains\343\203\246\343\203\274\343\202\266\343\203\274\343\202\260\343\203\253\343\203\274\343\203\227--jbugj-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html"
index ae6eecee48..7fdbd916c0 100644
--- "a/blog/2012/12/11/\347\254\254\344\270\200\345\233\236-jetbrains\343\203\246\343\203\274\343\202\266\343\203\274\343\202\260\343\203\253\343\203\274\343\203\227--jbugj-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2012/12/11/\347\254\254\344\270\200\345\233\236-jetbrains\343\203\246\343\203\274\343\202\266\343\203\274\343\202\260\343\203\253\343\203\274\343\203\227--jbugj-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\246\343\201\215\343\201\276\343\201\227\343\201\237/index.html"
@@ -530,6 +530,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -919,7 +921,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/12/20/jira\343\201\256db\347\247\273\350\241\214hsqldb\343\201\213\343\202\211postgresql\343\201\270-augj/index.html" "b/blog/2012/12/20/jira\343\201\256db\347\247\273\350\241\214hsqldb\343\201\213\343\202\211postgresql\343\201\270-augj/index.html"
index 02df65bc4f..5f6e32d681 100644
--- "a/blog/2012/12/20/jira\343\201\256db\347\247\273\350\241\214hsqldb\343\201\213\343\202\211postgresql\343\201\270-augj/index.html"
+++ "b/blog/2012/12/20/jira\343\201\256db\347\247\273\350\241\214hsqldb\343\201\213\343\202\211postgresql\343\201\270-augj/index.html"
@@ -574,6 +574,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -963,7 +965,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2012/12/31/\344\273\212\345\271\264\343\201\256\346\214\257\343\202\212\350\277\224\343\202\212\343\201\250\346\235\245\345\271\264\343\201\256\346\212\261\350\262\2402012/index.html" "b/blog/2012/12/31/\344\273\212\345\271\264\343\201\256\346\214\257\343\202\212\350\277\224\343\202\212\343\201\250\346\235\245\345\271\264\343\201\256\346\212\261\350\262\2402012/index.html"
index 95a51f6f36..042ea1f657 100644
--- "a/blog/2012/12/31/\344\273\212\345\271\264\343\201\256\346\214\257\343\202\212\350\277\224\343\202\212\343\201\250\346\235\245\345\271\264\343\201\256\346\212\261\350\262\2402012/index.html"
+++ "b/blog/2012/12/31/\344\273\212\345\271\264\343\201\256\346\214\257\343\202\212\350\277\224\343\202\212\343\201\250\346\235\245\345\271\264\343\201\256\346\212\261\350\262\2402012/index.html"
@@ -495,6 +495,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -884,7 +886,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2013/01/09/\343\202\263\343\203\274\343\203\211\343\202\267\343\203\263\343\203\227\343\203\252\343\202\267\343\203\206\343\202\243\343\202\222\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237kindle-paperwhite\343\201\256\344\275\277\343\201\204\345\213\235\346\211\213\343\201\256\347\242\272\350\252\215\343\202\202\345\205\274\343\201\255\343\201\246/index.html" "b/blog/2013/01/09/\343\202\263\343\203\274\343\203\211\343\202\267\343\203\263\343\203\227\343\203\252\343\202\267\343\203\206\343\202\243\343\202\222\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237kindle-paperwhite\343\201\256\344\275\277\343\201\204\345\213\235\346\211\213\343\201\256\347\242\272\350\252\215\343\202\202\345\205\274\343\201\255\343\201\246/index.html"
index 5e86717083..86e7808e50 100644
--- "a/blog/2013/01/09/\343\202\263\343\203\274\343\203\211\343\202\267\343\203\263\343\203\227\343\203\252\343\202\267\343\203\206\343\202\243\343\202\222\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237kindle-paperwhite\343\201\256\344\275\277\343\201\204\345\213\235\346\211\213\343\201\256\347\242\272\350\252\215\343\202\202\345\205\274\343\201\255\343\201\246/index.html"
+++ "b/blog/2013/01/09/\343\202\263\343\203\274\343\203\211\343\202\267\343\203\263\343\203\227\343\203\252\343\202\267\343\203\206\343\202\243\343\202\222\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237kindle-paperwhite\343\201\256\344\275\277\343\201\204\345\213\235\346\211\213\343\201\256\347\242\272\350\252\215\343\202\202\345\205\274\343\201\255\343\201\246/index.html"
@@ -444,6 +444,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -833,7 +835,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2013/01/16/\343\201\204\343\201\276\343\201\225\343\202\211\343\201\247\343\201\231\343\201\214cross-2013\343\201\247\346\244\234\347\264\242cross\343\201\250\343\201\204\343\201\206\343\202\273\343\203\203\343\202\267\343\203\247\343\203\263\343\202\222\346\213\205\345\275\223\343\201\227\343\201\276\343\201\231/index.html" "b/blog/2013/01/16/\343\201\204\343\201\276\343\201\225\343\202\211\343\201\247\343\201\231\343\201\214cross-2013\343\201\247\346\244\234\347\264\242cross\343\201\250\343\201\204\343\201\206\343\202\273\343\203\203\343\202\267\343\203\247\343\203\263\343\202\222\346\213\205\345\275\223\343\201\227\343\201\276\343\201\231/index.html"
index 9b3b662b9f..3da4550ee9 100644
--- "a/blog/2013/01/16/\343\201\204\343\201\276\343\201\225\343\202\211\343\201\247\343\201\231\343\201\214cross-2013\343\201\247\346\244\234\347\264\242cross\343\201\250\343\201\204\343\201\206\343\202\273\343\203\203\343\202\267\343\203\247\343\203\263\343\202\222\346\213\205\345\275\223\343\201\227\343\201\276\343\201\231/index.html"
+++ "b/blog/2013/01/16/\343\201\204\343\201\276\343\201\225\343\202\211\343\201\247\343\201\231\343\201\214cross-2013\343\201\247\346\244\234\347\264\242cross\343\201\250\343\201\204\343\201\206\343\202\273\343\203\203\343\202\267\343\203\247\343\203\263\343\202\222\346\213\205\345\275\223\343\201\227\343\201\276\343\201\231/index.html"
@@ -416,6 +416,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -805,7 +807,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2013/01/19/\343\202\250\343\203\263\343\202\270\343\203\213\343\202\242\343\202\265\343\203\235\343\203\274\343\203\210cross-2013\343\201\253\345\217\202\345\212\240\343\201\212\346\211\213\344\274\235\343\201\204\343\203\242\343\203\207\343\203\254\343\203\274\343\202\277\343\201\227\343\201\276\343\201\227\343\201\237--cross2013/index.html" "b/blog/2013/01/19/\343\202\250\343\203\263\343\202\270\343\203\213\343\202\242\343\202\265\343\203\235\343\203\274\343\203\210cross-2013\343\201\253\345\217\202\345\212\240\343\201\212\346\211\213\344\274\235\343\201\204\343\203\242\343\203\207\343\203\254\343\203\274\343\202\277\343\201\227\343\201\276\343\201\227\343\201\237--cross2013/index.html"
index 686c26df6c..7b2aea08ac 100644
--- "a/blog/2013/01/19/\343\202\250\343\203\263\343\202\270\343\203\213\343\202\242\343\202\265\343\203\235\343\203\274\343\203\210cross-2013\343\201\253\345\217\202\345\212\240\343\201\212\346\211\213\344\274\235\343\201\204\343\203\242\343\203\207\343\203\254\343\203\274\343\202\277\343\201\227\343\201\276\343\201\227\343\201\237--cross2013/index.html"
+++ "b/blog/2013/01/19/\343\202\250\343\203\263\343\202\270\343\203\213\343\202\242\343\202\265\343\203\235\343\203\274\343\203\210cross-2013\343\201\253\345\217\202\345\212\240\343\201\212\346\211\213\344\274\235\343\201\204\343\203\242\343\203\207\343\203\254\343\203\274\343\202\277\343\201\227\343\201\276\343\201\227\343\201\237--cross2013/index.html"
@@ -528,6 +528,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -917,7 +919,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2013/01/22/hadoop-conference-japan-2013-winter\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-hcj13w/index.html" "b/blog/2013/01/22/hadoop-conference-japan-2013-winter\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-hcj13w/index.html"
index f7d305b67c..4e5bfd2d2e 100644
--- "a/blog/2013/01/22/hadoop-conference-japan-2013-winter\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-hcj13w/index.html"
+++ "b/blog/2013/01/22/hadoop-conference-japan-2013-winter\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-hcj13w/index.html"
@@ -637,6 +637,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1026,7 +1028,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2013/02/13/xperia-z\350\262\267\343\201\204\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2013/02/13/xperia-z\350\262\267\343\201\204\343\201\276\343\201\227\343\201\237/index.html"
index 13d659caf6..53f30b84c8 100644
--- "a/blog/2013/02/13/xperia-z\350\262\267\343\201\204\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2013/02/13/xperia-z\350\262\267\343\201\204\343\201\276\343\201\227\343\201\237/index.html"
@@ -454,6 +454,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -843,7 +845,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2013/03/19/\343\202\250\343\203\263\343\202\270\343\203\213\343\202\242\343\201\256\343\201\237\343\202\201\343\201\256\343\202\271\343\202\255\343\203\253\343\202\242\343\203\203\343\203\227\345\213\211\345\274\267\344\274\232tech-compass\347\253\271\346\251\213--vol1-\343\202\271\343\203\236\343\203\233\346\231\202\344\273\243\345\210\260\346\235\245\343\201\223\343\201\256\345\205\210\347\224\237\343\201\215\343\201\256\343\201\223\343\202\213\343\202\250\343\203\263\343\202\270\343\203\213\343\202\242\343\201\250\343\201\257\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-tecomp/index.html" "b/blog/2013/03/19/\343\202\250\343\203\263\343\202\270\343\203\213\343\202\242\343\201\256\343\201\237\343\202\201\343\201\256\343\202\271\343\202\255\343\203\253\343\202\242\343\203\203\343\203\227\345\213\211\345\274\267\344\274\232tech-compass\347\253\271\346\251\213--vol1-\343\202\271\343\203\236\343\203\233\346\231\202\344\273\243\345\210\260\346\235\245\343\201\223\343\201\256\345\205\210\347\224\237\343\201\215\343\201\256\343\201\223\343\202\213\343\202\250\343\203\263\343\202\270\343\203\213\343\202\242\343\201\250\343\201\257\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-tecomp/index.html"
index 8b6a17a92a..f2d4f0cffd 100644
--- "a/blog/2013/03/19/\343\202\250\343\203\263\343\202\270\343\203\213\343\202\242\343\201\256\343\201\237\343\202\201\343\201\256\343\202\271\343\202\255\343\203\253\343\202\242\343\203\203\343\203\227\345\213\211\345\274\267\344\274\232tech-compass\347\253\271\346\251\213--vol1-\343\202\271\343\203\236\343\203\233\346\231\202\344\273\243\345\210\260\346\235\245\343\201\223\343\201\256\345\205\210\347\224\237\343\201\215\343\201\256\343\201\223\343\202\213\343\202\250\343\203\263\343\202\270\343\203\213\343\202\242\343\201\250\343\201\257\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-tecomp/index.html"
+++ "b/blog/2013/03/19/\343\202\250\343\203\263\343\202\270\343\203\213\343\202\242\343\201\256\343\201\237\343\202\201\343\201\256\343\202\271\343\202\255\343\203\253\343\202\242\343\203\203\343\203\227\345\213\211\345\274\267\344\274\232tech-compass\347\253\271\346\251\213--vol1-\343\202\271\343\203\236\343\203\233\346\231\202\344\273\243\345\210\260\346\235\245\343\201\223\343\201\256\345\205\210\347\224\237\343\201\215\343\201\256\343\201\223\343\202\213\343\202\250\343\203\263\343\202\270\343\203\213\343\202\242\343\201\250\343\201\257\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-tecomp/index.html"
@@ -489,6 +489,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -878,7 +880,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2013/03/20/elasticsearch-analysis-kuromoji\343\201\247\343\203\246\343\203\274\343\202\266\350\276\236\346\233\270\343\201\256\345\210\251\347\224\250\346\226\271\346\263\225/index.html" "b/blog/2013/03/20/elasticsearch-analysis-kuromoji\343\201\247\343\203\246\343\203\274\343\202\266\350\276\236\346\233\270\343\201\256\345\210\251\347\224\250\346\226\271\346\263\225/index.html"
index 4da0b66ce7..8b699823ac 100644
--- "a/blog/2013/03/20/elasticsearch-analysis-kuromoji\343\201\247\343\203\246\343\203\274\343\202\266\350\276\236\346\233\270\343\201\256\345\210\251\347\224\250\346\226\271\346\263\225/index.html"
+++ "b/blog/2013/03/20/elasticsearch-analysis-kuromoji\343\201\247\343\203\246\343\203\274\343\202\266\350\276\236\346\233\270\343\201\256\345\210\251\347\224\250\346\226\271\346\263\225/index.html"
@@ -475,6 +475,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -864,7 +866,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2013/03/26/\347\254\25410\345\233\236solr\345\213\211\345\274\267\344\274\232\343\202\222\344\270\273\345\202\254\343\201\227\343\201\276\343\201\227\343\201\237-solrjp/index.html" "b/blog/2013/03/26/\347\254\25410\345\233\236solr\345\213\211\345\274\267\344\274\232\343\202\222\344\270\273\345\202\254\343\201\227\343\201\276\343\201\227\343\201\237-solrjp/index.html"
index 0013a10ddb..92c0db216f 100644
--- "a/blog/2013/03/26/\347\254\25410\345\233\236solr\345\213\211\345\274\267\344\274\232\343\202\222\344\270\273\345\202\254\343\201\227\343\201\276\343\201\227\343\201\237-solrjp/index.html"
+++ "b/blog/2013/03/26/\347\254\25410\345\233\236solr\345\213\211\345\274\267\344\274\232\343\202\222\344\270\273\345\202\254\343\201\227\343\201\276\343\201\227\343\201\237-solrjp/index.html"
@@ -600,6 +600,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -989,7 +991,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2013/04/05/heroku-meetup--8-treasuredata--waza-report-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-herokujp/index.html" "b/blog/2013/04/05/heroku-meetup--8-treasuredata--waza-report-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-herokujp/index.html"
index 47c86479e2..125ddf8a51 100644
--- "a/blog/2013/04/05/heroku-meetup--8-treasuredata--waza-report-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-herokujp/index.html"
+++ "b/blog/2013/04/05/heroku-meetup--8-treasuredata--waza-report-\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237-herokujp/index.html"
@@ -522,6 +522,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -911,7 +913,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2013/04/22/jira\343\201\256\343\203\207\343\203\274\343\202\277\343\202\222s3\343\201\270\343\203\220\343\203\203\343\202\257\343\202\242\343\203\203\343\203\227/index.html" "b/blog/2013/04/22/jira\343\201\256\343\203\207\343\203\274\343\202\277\343\202\222s3\343\201\270\343\203\220\343\203\203\343\202\257\343\202\242\343\203\203\343\203\227/index.html"
index 5fbd2b91f8..35625514b0 100644
--- "a/blog/2013/04/22/jira\343\201\256\343\203\207\343\203\274\343\202\277\343\202\222s3\343\201\270\343\203\220\343\203\203\343\202\257\343\202\242\343\203\203\343\203\227/index.html"
+++ "b/blog/2013/04/22/jira\343\201\256\343\203\207\343\203\274\343\202\277\343\202\222s3\343\201\270\343\203\220\343\203\203\343\202\257\343\202\242\343\203\203\343\203\227/index.html"
@@ -497,6 +497,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -886,7 +888,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2013/04/23/\343\202\250\343\203\263\343\202\270\343\203\213\343\202\242\343\201\256\343\201\237\343\202\201\343\201\256\343\202\271\343\202\255\343\203\253\343\202\242\343\203\203\343\203\227\345\213\211\345\274\267\344\274\232tech-compass--tecomp--vol-2-\344\272\272\346\260\227web\343\202\265\343\203\274\343\203\223\343\202\271\343\201\256\344\275\234\343\202\212\346\226\271\346\225\231\343\201\210\343\201\276\343\201\231\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2013/04/23/\343\202\250\343\203\263\343\202\270\343\203\213\343\202\242\343\201\256\343\201\237\343\202\201\343\201\256\343\202\271\343\202\255\343\203\253\343\202\242\343\203\203\343\203\227\345\213\211\345\274\267\344\274\232tech-compass--tecomp--vol-2-\344\272\272\346\260\227web\343\202\265\343\203\274\343\203\223\343\202\271\343\201\256\344\275\234\343\202\212\346\226\271\346\225\231\343\201\210\343\201\276\343\201\231\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
index 34ffd3c22e..722cb42e1b 100644
--- "a/blog/2013/04/23/\343\202\250\343\203\263\343\202\270\343\203\213\343\202\242\343\201\256\343\201\237\343\202\201\343\201\256\343\202\271\343\202\255\343\203\253\343\202\242\343\203\203\343\203\227\345\213\211\345\274\267\344\274\232tech-compass--tecomp--vol-2-\344\272\272\346\260\227web\343\202\265\343\203\274\343\203\223\343\202\271\343\201\256\344\275\234\343\202\212\346\226\271\346\225\231\343\201\210\343\201\276\343\201\231\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2013/04/23/\343\202\250\343\203\263\343\202\270\343\203\213\343\202\242\343\201\256\343\201\237\343\202\201\343\201\256\343\202\271\343\202\255\343\203\253\343\202\242\343\203\203\343\203\227\345\213\211\345\274\267\344\274\232tech-compass--tecomp--vol-2-\344\272\272\346\260\227web\343\202\265\343\203\274\343\203\223\343\202\271\343\201\256\344\275\234\343\202\212\346\226\271\346\225\231\343\201\210\343\201\276\343\201\231\343\201\253\345\217\202\345\212\240\343\201\227\343\201\276\343\201\227\343\201\237/index.html"
@@ -479,6 +479,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -868,7 +870,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2013/04/24/lucene-4-3-0\343\201\256changes\343\201\253\343\201\202\343\202\213changes-in-backwards-compatibility-policy\343\201\214\346\260\227\343\201\253\343\201\252\343\201\243\343\201\237\343\201\256\343\201\247\350\250\263\343\201\227\343\201\246\343\201\277\343\201\237/index.html" "b/blog/2013/04/24/lucene-4-3-0\343\201\256changes\343\201\253\343\201\202\343\202\213changes-in-backwards-compatibility-policy\343\201\214\346\260\227\343\201\253\343\201\252\343\201\243\343\201\237\343\201\256\343\201\247\350\250\263\343\201\227\343\201\246\343\201\277\343\201\237/index.html"
index dc7345225c..08d9eba2eb 100644
--- "a/blog/2013/04/24/lucene-4-3-0\343\201\256changes\343\201\253\343\201\202\343\202\213changes-in-backwards-compatibility-policy\343\201\214\346\260\227\343\201\253\343\201\252\343\201\243\343\201\237\343\201\256\343\201\247\350\250\263\343\201\227\343\201\246\343\201\277\343\201\237/index.html"
+++ "b/blog/2013/04/24/lucene-4-3-0\343\201\256changes\343\201\253\343\201\202\343\202\213changes-in-backwards-compatibility-policy\343\201\214\346\260\227\343\201\253\343\201\252\343\201\243\343\201\237\343\201\256\343\201\247\350\250\263\343\201\227\343\201\246\343\201\277\343\201\237/index.html"
@@ -419,6 +419,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -808,7 +810,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2013/04/25/solr4-3-0\343\201\256changes\343\202\222\350\250\263\343\201\227\343\201\246\343\201\277\343\201\237/index.html" "b/blog/2013/04/25/solr4-3-0\343\201\256changes\343\202\222\350\250\263\343\201\227\343\201\246\343\201\277\343\201\237/index.html"
index 204f09f3f3..61c7ad86ae 100644
--- "a/blog/2013/04/25/solr4-3-0\343\201\256changes\343\202\222\350\250\263\343\201\227\343\201\246\343\201\277\343\201\237/index.html"
+++ "b/blog/2013/04/25/solr4-3-0\343\201\256changes\343\202\222\350\250\263\343\201\227\343\201\246\343\201\277\343\201\237/index.html"
@@ -458,6 +458,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -847,7 +849,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2013/05/03/\343\203\235\343\203\242\343\203\211\343\203\274\343\203\255\345\233\236\343\201\227\343\201\246\343\201\276\343\201\231\343\203\235\343\203\242\343\203\211\343\203\274\343\203\255\343\203\206\343\202\257\343\203\213\343\203\203\343\202\257\345\205\245\351\226\200\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237/index.html" "b/blog/2013/05/03/\343\203\235\343\203\242\343\203\211\343\203\274\343\203\255\345\233\236\343\201\227\343\201\246\343\201\276\343\201\231\343\203\235\343\203\242\343\203\211\343\203\274\343\203\255\343\203\206\343\202\257\343\203\213\343\203\203\343\202\257\345\205\245\351\226\200\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237/index.html"
index 30e8a37809..f11342d05e 100644
--- "a/blog/2013/05/03/\343\203\235\343\203\242\343\203\211\343\203\274\343\203\255\345\233\236\343\201\227\343\201\246\343\201\276\343\201\231\343\203\235\343\203\242\343\203\211\343\203\274\343\203\255\343\203\206\343\202\257\343\203\213\343\203\203\343\202\257\345\205\245\351\226\200\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237/index.html"
+++ "b/blog/2013/05/03/\343\203\235\343\203\242\343\203\211\343\203\274\343\203\255\345\233\236\343\201\227\343\201\246\343\201\276\343\201\231\343\203\235\343\203\242\343\203\211\343\203\274\343\203\255\343\203\206\343\202\257\343\203\213\343\203\203\343\202\257\345\205\245\351\226\200\350\252\255\343\201\277\343\201\276\343\201\227\343\201\237/index.html"
@@ -492,6 +492,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -881,7 +883,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2013/05/06/lucene-gosen4-3-0\343\202\222\343\203\252\343\203\252\343\203\274\343\202\271\343\201\227\343\201\276\343\201\227\343\201\237lucene-solr4-3-0\344\273\245\344\270\212\343\201\247\343\201\256\345\210\251\347\224\250\343\201\214\345\217\257\350\203\275\343\201\247\343\201\231/index.html" "b/blog/2013/05/06/lucene-gosen4-3-0\343\202\222\343\203\252\343\203\252\343\203\274\343\202\271\343\201\227\343\201\276\343\201\227\343\201\237lucene-solr4-3-0\344\273\245\344\270\212\343\201\247\343\201\256\345\210\251\347\224\250\343\201\214\345\217\257\350\203\275\343\201\247\343\201\231/index.html"
index 3ed0fcb161..35b9b95298 100644
--- "a/blog/2013/05/06/lucene-gosen4-3-0\343\202\222\343\203\252\343\203\252\343\203\274\343\202\271\343\201\227\343\201\276\343\201\227\343\201\237lucene-solr4-3-0\344\273\245\344\270\212\343\201\247\343\201\256\345\210\251\347\224\250\343\201\214\345\217\257\350\203\275\343\201\247\343\201\231/index.html"
+++ "b/blog/2013/05/06/lucene-gosen4-3-0\343\202\222\343\203\252\343\203\252\343\203\274\343\202\271\343\201\227\343\201\276\343\201\227\343\201\237lucene-solr4-3-0\344\273\245\344\270\212\343\201\247\343\201\256\345\210\251\347\224\250\343\201\214\345\217\257\350\203\275\343\201\247\343\201\231/index.html"
@@ -415,6 +415,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -804,7 +806,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/06/01/first-octopress/index.html b/blog/2013/06/01/first-octopress/index.html
index a72e2638a8..b66e02b7d8 100644
--- a/blog/2013/06/01/first-octopress/index.html
+++ b/blog/2013/06/01/first-octopress/index.html
@@ -421,6 +421,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -810,7 +812,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/06/03/fluent-plugin-zoomdata-0-0-1/index.html b/blog/2013/06/03/fluent-plugin-zoomdata-0-0-1/index.html
index c712047f74..9c4f9339b8 100644
--- a/blog/2013/06/03/fluent-plugin-zoomdata-0-0-1/index.html
+++ b/blog/2013/06/03/fluent-plugin-zoomdata-0-0-1/index.html
@@ -519,6 +519,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -908,7 +910,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/blog/2013/06/03/octopress\343\202\222\350\251\246\343\201\227\344\270\255/index.html" "b/blog/2013/06/03/octopress\343\202\222\350\251\246\343\201\227\344\270\255/index.html"
index fa34fe845f..f7aa0cd46f 100644
--- "a/blog/2013/06/03/octopress\343\202\222\350\251\246\343\201\227\344\270\255/index.html"
+++ "b/blog/2013/06/03/octopress\343\202\222\350\251\246\343\201\227\344\270\255/index.html"
@@ -417,6 +417,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -806,7 +808,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/06/05/aws-summit-tokyo-day1/index.html b/blog/2013/06/05/aws-summit-tokyo-day1/index.html
index 21e1708284..83e2ea38c4 100644
--- a/blog/2013/06/05/aws-summit-tokyo-day1/index.html
+++ b/blog/2013/06/05/aws-summit-tokyo-day1/index.html
@@ -609,6 +609,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -998,7 +1000,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/06/05/cloudera-search-modules/index.html b/blog/2013/06/05/cloudera-search-modules/index.html
index c3b0ab5957..50c7432a08 100644
--- a/blog/2013/06/05/cloudera-search-modules/index.html
+++ b/blog/2013/06/05/cloudera-search-modules/index.html
@@ -483,6 +483,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -872,7 +874,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/06/05/what-is-cloudera-search/index.html b/blog/2013/06/05/what-is-cloudera-search/index.html
index 439cce7013..eb53c153dc 100644
--- a/blog/2013/06/05/what-is-cloudera-search/index.html
+++ b/blog/2013/06/05/what-is-cloudera-search/index.html
@@ -469,6 +469,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -858,7 +860,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/06/06/aws-summit-tokyo-day2/index.html b/blog/2013/06/06/aws-summit-tokyo-day2/index.html
index 011e744aff..8f83560265 100644
--- a/blog/2013/06/06/aws-summit-tokyo-day2/index.html
+++ b/blog/2013/06/06/aws-summit-tokyo-day2/index.html
@@ -640,6 +640,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1029,7 +1031,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/06/06/cloudera-search-memo2/index.html b/blog/2013/06/06/cloudera-search-memo2/index.html
index 18bee64c4b..74e3255bc1 100644
--- a/blog/2013/06/06/cloudera-search-memo2/index.html
+++ b/blog/2013/06/06/cloudera-search-memo2/index.html
@@ -482,6 +482,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -871,7 +873,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/06/10/fluent-es-kibana/index.html b/blog/2013/06/10/fluent-es-kibana/index.html
index dd1a05ec5f..d3952d7140 100644
--- a/blog/2013/06/10/fluent-es-kibana/index.html
+++ b/blog/2013/06/10/fluent-es-kibana/index.html
@@ -561,6 +561,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -950,7 +952,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/06/11/new-solr-xml/index.html b/blog/2013/06/11/new-solr-xml/index.html
index 874b44c8fa..69f84a3aad 100644
--- a/blog/2013/06/11/new-solr-xml/index.html
+++ b/blog/2013/06/11/new-solr-xml/index.html
@@ -460,6 +460,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -849,7 +851,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/06/19/introduction-kibana3/index.html b/blog/2013/06/19/introduction-kibana3/index.html
index 7e075d4a7b..0aa6914d7e 100644
--- a/blog/2013/06/19/introduction-kibana3/index.html
+++ b/blog/2013/06/19/introduction-kibana3/index.html
@@ -704,6 +704,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1093,7 +1095,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/06/19/visited-basho/index.html b/blog/2013/06/19/visited-basho/index.html
index 921182bafa..d4363ab7cc 100644
--- a/blog/2013/06/19/visited-basho/index.html
+++ b/blog/2013/06/19/visited-basho/index.html
@@ -451,6 +451,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -840,7 +842,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/06/27/upload-docs-solr-admin/index.html b/blog/2013/06/27/upload-docs-solr-admin/index.html
index 122a3a783c..64274f389f 100644
--- a/blog/2013/06/27/upload-docs-solr-admin/index.html
+++ b/blog/2013/06/27/upload-docs-solr-admin/index.html
@@ -477,6 +477,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -866,7 +868,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/07/04/schemaless-example/index.html b/blog/2013/07/04/schemaless-example/index.html
index 5580fad775..619de9bf67 100644
--- a/blog/2013/07/04/schemaless-example/index.html
+++ b/blog/2013/07/04/schemaless-example/index.html
@@ -629,6 +629,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1018,7 +1020,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/07/10/riak-meetup-tokyo-no2/index.html b/blog/2013/07/10/riak-meetup-tokyo-no2/index.html
index 37f85c04d6..58d2a71c71 100644
--- a/blog/2013/07/10/riak-meetup-tokyo-no2/index.html
+++ b/blog/2013/07/10/riak-meetup-tokyo-no2/index.html
@@ -593,6 +593,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -982,7 +984,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/07/11/yokozuna-check-point/index.html b/blog/2013/07/11/yokozuna-check-point/index.html
index f7fc539703..173d40a409 100644
--- a/blog/2013/07/11/yokozuna-check-point/index.html
+++ b/blog/2013/07/11/yokozuna-check-point/index.html
@@ -445,6 +445,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -834,7 +836,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/07/25/hadoop-hive-publication-party/index.html b/blog/2013/07/25/hadoop-hive-publication-party/index.html
index 1bfc56c9a7..adc1b3573a 100644
--- a/blog/2013/07/25/hadoop-hive-publication-party/index.html
+++ b/blog/2013/07/25/hadoop-hive-publication-party/index.html
@@ -487,6 +487,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -876,7 +878,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/07/29/study-of-solr/index.html b/blog/2013/07/29/study-of-solr/index.html
index f6ffd3e0db..b5d2242730 100644
--- a/blog/2013/07/29/study-of-solr/index.html
+++ b/blog/2013/07/29/study-of-solr/index.html
@@ -619,6 +619,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1008,7 +1010,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/07/31/introduction-morphlines/index.html b/blog/2013/07/31/introduction-morphlines/index.html
index ab67e8a9bb..65f1af2d76 100644
--- a/blog/2013/07/31/introduction-morphlines/index.html
+++ b/blog/2013/07/31/introduction-morphlines/index.html
@@ -527,6 +527,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -916,7 +918,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/08/01/replace-xperia-z/index.html b/blog/2013/08/01/replace-xperia-z/index.html
index 95022c0d43..a5cbc547e2 100644
--- a/blog/2013/08/01/replace-xperia-z/index.html
+++ b/blog/2013/08/01/replace-xperia-z/index.html
@@ -450,6 +450,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -839,7 +841,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/08/02/morphlines-loadsolr/index.html b/blog/2013/08/02/morphlines-loadsolr/index.html
index e90f108bdb..a38a72521b 100644
--- a/blog/2013/08/02/morphlines-loadsolr/index.html
+++ b/blog/2013/08/02/morphlines-loadsolr/index.html
@@ -458,6 +458,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -847,7 +849,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/08/23/index-wikipedia-ja-to-elasticsearch/index.html b/blog/2013/08/23/index-wikipedia-ja-to-elasticsearch/index.html
index 75d915245a..bfb04575af 100644
--- a/blog/2013/08/23/index-wikipedia-ja-to-elasticsearch/index.html
+++ b/blog/2013/08/23/index-wikipedia-ja-to-elasticsearch/index.html
@@ -632,6 +632,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1021,7 +1023,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/08/30/hold-first-elasticsearch-meetup-in-japan/index.html b/blog/2013/08/30/hold-first-elasticsearch-meetup-in-japan/index.html
index eef394a449..c65f664675 100644
--- a/blog/2013/08/30/hold-first-elasticsearch-meetup-in-japan/index.html
+++ b/blog/2013/08/30/hold-first-elasticsearch-meetup-in-japan/index.html
@@ -539,6 +539,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -928,7 +930,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/09/03/ja-wikipedia-with-kuromoji/index.html b/blog/2013/09/03/ja-wikipedia-with-kuromoji/index.html
index 1b318d3f3b..5b624588f1 100644
--- a/blog/2013/09/03/ja-wikipedia-with-kuromoji/index.html
+++ b/blog/2013/09/03/ja-wikipedia-with-kuromoji/index.html
@@ -477,6 +477,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -866,7 +868,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/09/12/question-river-wikipedia/index.html b/blog/2013/09/12/question-river-wikipedia/index.html
index 8450c4f0f9..06b6c9d1cd 100644
--- a/blog/2013/09/12/question-river-wikipedia/index.html
+++ b/blog/2013/09/12/question-river-wikipedia/index.html
@@ -527,6 +527,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -916,7 +918,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/09/23/intro-elasticsearch-inquisitor/index.html b/blog/2013/09/23/intro-elasticsearch-inquisitor/index.html
index 67d7c555ed..8f5f67c1a6 100644
--- a/blog/2013/09/23/intro-elasticsearch-inquisitor/index.html
+++ b/blog/2013/09/23/intro-elasticsearch-inquisitor/index.html
@@ -527,6 +527,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -916,7 +918,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/10/10/solr-meetup-memo/index.html b/blog/2013/10/10/solr-meetup-memo/index.html
index f3b130e9ea..5b26b08d6d 100644
--- a/blog/2013/10/10/solr-meetup-memo/index.html
+++ b/blog/2013/10/10/solr-meetup-memo/index.html
@@ -524,6 +524,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -913,7 +915,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/10/25/developing-es-extended-analyze-plugin/index.html b/blog/2013/10/25/developing-es-extended-analyze-plugin/index.html
index 22e8561892..55b7867a76 100644
--- a/blog/2013/10/25/developing-es-extended-analyze-plugin/index.html
+++ b/blog/2013/10/25/developing-es-extended-analyze-plugin/index.html
@@ -612,6 +612,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1001,7 +1003,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/11/04/improve-output-extended-analyze/index.html b/blog/2013/11/04/improve-output-extended-analyze/index.html
index a44678a859..e90a78456b 100644
--- a/blog/2013/11/04/improve-output-extended-analyze/index.html
+++ b/blog/2013/11/04/improve-output-extended-analyze/index.html
@@ -431,6 +431,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -820,7 +822,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/11/06/riak-meetup-tokyo-no3/index.html b/blog/2013/11/06/riak-meetup-tokyo-no3/index.html
index 6525b46951..ee70f11961 100644
--- a/blog/2013/11/06/riak-meetup-tokyo-no3/index.html
+++ b/blog/2013/11/06/riak-meetup-tokyo-no3/index.html
@@ -517,6 +517,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -906,7 +908,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/11/07/cloudera-world-tokyo-2013/index.html b/blog/2013/11/07/cloudera-world-tokyo-2013/index.html
index a1d8b17990..b3bafb8a74 100644
--- a/blog/2013/11/07/cloudera-world-tokyo-2013/index.html
+++ b/blog/2013/11/07/cloudera-world-tokyo-2013/index.html
@@ -689,6 +689,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1078,7 +1080,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/11/12/elasticsearch-japan-user-meetup-no2/index.html b/blog/2013/11/12/elasticsearch-japan-user-meetup-no2/index.html
index 7a128ae929..8d2554bf39 100644
--- a/blog/2013/11/12/elasticsearch-japan-user-meetup-no2/index.html
+++ b/blog/2013/11/12/elasticsearch-japan-user-meetup-no2/index.html
@@ -522,6 +522,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -911,7 +913,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/11/14/release-elasticsearch-extended-analyze-0-dot-5/index.html b/blog/2013/11/14/release-elasticsearch-extended-analyze-0-dot-5/index.html
index 8ee9c760a1..625a1ee15b 100644
--- a/blog/2013/11/14/release-elasticsearch-extended-analyze-0-dot-5/index.html
+++ b/blog/2013/11/14/release-elasticsearch-extended-analyze-0-dot-5/index.html
@@ -491,6 +491,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -880,7 +882,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/11/26/introduction-to-solr-new-edition/index.html b/blog/2013/11/26/introduction-to-solr-new-edition/index.html
index 7960fe8cce..39b77046f2 100644
--- a/blog/2013/11/26/introduction-to-solr-new-edition/index.html
+++ b/blog/2013/11/26/introduction-to-solr-new-edition/index.html
@@ -441,6 +441,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -830,7 +832,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/12/09/release-introduction-solr-ebook/index.html b/blog/2013/12/09/release-introduction-solr-ebook/index.html
index c36efe4667..152283a197 100644
--- a/blog/2013/12/09/release-introduction-solr-ebook/index.html
+++ b/blog/2013/12/09/release-introduction-solr-ebook/index.html
@@ -411,6 +411,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -800,7 +802,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/12/17/release-es-extended-analyze-plugin-to-maven-and-sonatype/index.html b/blog/2013/12/17/release-es-extended-analyze-plugin-to-maven-and-sonatype/index.html
index 2a598f1b9e..80ba708533 100644
--- a/blog/2013/12/17/release-es-extended-analyze-plugin-to-maven-and-sonatype/index.html
+++ b/blog/2013/12/17/release-es-extended-analyze-plugin-to-maven-and-sonatype/index.html
@@ -436,6 +436,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -825,7 +827,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/12/19/add-jar-file-to-solr/index.html b/blog/2013/12/19/add-jar-file-to-solr/index.html
index 08c0e65877..89553a4f0f 100644
--- a/blog/2013/12/19/add-jar-file-to-solr/index.html
+++ b/blog/2013/12/19/add-jar-file-to-solr/index.html
@@ -439,6 +439,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -828,7 +830,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/12/20/release-elasticsearch-0-90-8/index.html b/blog/2013/12/20/release-elasticsearch-0-90-8/index.html
index a1d91c09a3..f057d7d7b6 100644
--- a/blog/2013/12/20/release-elasticsearch-0-90-8/index.html
+++ b/blog/2013/12/20/release-elasticsearch-0-90-8/index.html
@@ -433,6 +433,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -822,7 +824,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2013/12/30/looking-back-2013/index.html b/blog/2013/12/30/looking-back-2013/index.html
index 51c5087e6d..d5a6104d2b 100644
--- a/blog/2013/12/30/looking-back-2013/index.html
+++ b/blog/2013/12/30/looking-back-2013/index.html
@@ -525,6 +525,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -914,7 +916,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/01/22/release-extended-plugin-for-1-0-0rc1/index.html b/blog/2014/01/22/release-extended-plugin-for-1-0-0rc1/index.html
index 875a56e59d..b65cfb601d 100644
--- a/blog/2014/01/22/release-extended-plugin-for-1-0-0rc1/index.html
+++ b/blog/2014/01/22/release-extended-plugin-for-1-0-0rc1/index.html
@@ -436,6 +436,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -825,7 +827,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/01/24/curator-tending-your-time-series-indices-in-japanese/index.html b/blog/2014/01/24/curator-tending-your-time-series-indices-in-japanese/index.html
index bfc13d88b8..979a6a3ff0 100644
--- a/blog/2014/01/24/curator-tending-your-time-series-indices-in-japanese/index.html
+++ b/blog/2014/01/24/curator-tending-your-time-series-indices-in-japanese/index.html
@@ -571,6 +571,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -960,7 +962,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/01/28/release-lucene-gosen-4-dot-6-1/index.html b/blog/2014/01/28/release-lucene-gosen-4-dot-6-1/index.html
index 9812a99474..c3997faa1c 100644
--- a/blog/2014/01/28/release-lucene-gosen-4-dot-6-1/index.html
+++ b/blog/2014/01/28/release-lucene-gosen-4-dot-6-1/index.html
@@ -446,6 +446,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -835,7 +837,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/01/29/hold-to-japan-solr-meetup/index.html b/blog/2014/01/29/hold-to-japan-solr-meetup/index.html
index 960e095628..ffccabdf39 100644
--- a/blog/2014/01/29/hold-to-japan-solr-meetup/index.html
+++ b/blog/2014/01/29/hold-to-japan-solr-meetup/index.html
@@ -496,6 +496,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -885,7 +887,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/01/29/simple-introduction-and-first-impression-es-marvel/index.html b/blog/2014/01/29/simple-introduction-and-first-impression-es-marvel/index.html
index 5041c81623..401e974ab5 100644
--- a/blog/2014/01/29/simple-introduction-and-first-impression-es-marvel/index.html
+++ b/blog/2014/01/29/simple-introduction-and-first-impression-es-marvel/index.html
@@ -643,6 +643,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1032,7 +1034,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/02/06/es-cluster-start-using-vagrant-and-puppet/index.html b/blog/2014/02/06/es-cluster-start-using-vagrant-and-puppet/index.html
index fbe0d7990d..52e7ae3a51 100644
--- a/blog/2014/02/06/es-cluster-start-using-vagrant-and-puppet/index.html
+++ b/blog/2014/02/06/es-cluster-start-using-vagrant-and-puppet/index.html
@@ -538,6 +538,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -927,7 +929,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/02/08/hold-3rd-elasticsaerch-meetup-in-tokyo/index.html b/blog/2014/02/08/hold-3rd-elasticsaerch-meetup-in-tokyo/index.html
index 2121fc337b..87d5956b08 100644
--- a/blog/2014/02/08/hold-3rd-elasticsaerch-meetup-in-tokyo/index.html
+++ b/blog/2014/02/08/hold-3rd-elasticsaerch-meetup-in-tokyo/index.html
@@ -531,6 +531,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -920,7 +922,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/02/24/strange-behavior-of-field-in-nested-obj/index.html b/blog/2014/02/24/strange-behavior-of-field-in-nested-obj/index.html
index fe37617154..be3f35ea84 100644
--- a/blog/2014/02/24/strange-behavior-of-field-in-nested-obj/index.html
+++ b/blog/2014/02/24/strange-behavior-of-field-in-nested-obj/index.html
@@ -627,6 +627,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1016,7 +1018,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/03/03/release-elasticsearch-server-japanese-edition/index.html b/blog/2014/03/03/release-elasticsearch-server-japanese-edition/index.html
index 31bbfe676a..ea902e1e16 100644
--- a/blog/2014/03/03/release-elasticsearch-server-japanese-edition/index.html
+++ b/blog/2014/03/03/release-elasticsearch-server-japanese-edition/index.html
@@ -468,6 +468,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -857,7 +859,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/03/11/es-plugin-installed-to-my-env/index.html b/blog/2014/03/11/es-plugin-installed-to-my-env/index.html
index 23be896c38..23dea40c54 100644
--- a/blog/2014/03/11/es-plugin-installed-to-my-env/index.html
+++ b/blog/2014/03/11/es-plugin-installed-to-my-env/index.html
@@ -473,6 +473,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -862,7 +864,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/03/16/post-from-berlin/index.html b/blog/2014/03/16/post-from-berlin/index.html
index fc4824db8d..213ba8ccd7 100644
--- a/blog/2014/03/16/post-from-berlin/index.html
+++ b/blog/2014/03/16/post-from-berlin/index.html
@@ -416,6 +416,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -805,7 +807,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/03/18/attend-goto-night-elasticsearch/index.html b/blog/2014/03/18/attend-goto-night-elasticsearch/index.html
index daa84679be..66d255a6c9 100644
--- a/blog/2014/03/18/attend-goto-night-elasticsearch/index.html
+++ b/blog/2014/03/18/attend-goto-night-elasticsearch/index.html
@@ -445,6 +445,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -834,7 +836,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/03/25/release-elasticsearch-server-ja-ebook/index.html b/blog/2014/03/25/release-elasticsearch-server-ja-ebook/index.html
index eab612455c..fb8a470527 100644
--- a/blog/2014/03/25/release-elasticsearch-server-ja-ebook/index.html
+++ b/blog/2014/03/25/release-elasticsearch-server-ja-ebook/index.html
@@ -441,6 +441,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -830,7 +832,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/04/05/intro-elasticsearch-kopf-1/index.html b/blog/2014/04/05/intro-elasticsearch-kopf-1/index.html
index c36b57a5eb..d0896e37ae 100644
--- a/blog/2014/04/05/intro-elasticsearch-kopf-1/index.html
+++ b/blog/2014/04/05/intro-elasticsearch-kopf-1/index.html
@@ -481,6 +481,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -870,7 +872,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/04/07/attend-jvm-casual-1/index.html b/blog/2014/04/07/attend-jvm-casual-1/index.html
index 3557ef2071..bad29ced23 100644
--- a/blog/2014/04/07/attend-jvm-casual-1/index.html
+++ b/blog/2014/04/07/attend-jvm-casual-1/index.html
@@ -620,6 +620,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1009,7 +1011,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/04/07/intro-elasticsearch-kopf-rest/index.html b/blog/2014/04/07/intro-elasticsearch-kopf-rest/index.html
index 96a601b6f2..3e0e3246ea 100644
--- a/blog/2014/04/07/intro-elasticsearch-kopf-rest/index.html
+++ b/blog/2014/04/07/intro-elasticsearch-kopf-rest/index.html
@@ -476,6 +476,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -865,7 +867,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/04/09/intro-elasticsearch-kopf-analysis/index.html b/blog/2014/04/09/intro-elasticsearch-kopf-analysis/index.html
index 23b26bd489..b481f4ff4c 100644
--- a/blog/2014/04/09/intro-elasticsearch-kopf-analysis/index.html
+++ b/blog/2014/04/09/intro-elasticsearch-kopf-analysis/index.html
@@ -467,6 +467,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -856,7 +858,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/04/21/hold-on-4th-elasticsearch-jp/index.html b/blog/2014/04/21/hold-on-4th-elasticsearch-jp/index.html
index c6d9744e6f..d3a9e96744 100644
--- a/blog/2014/04/21/hold-on-4th-elasticsearch-jp/index.html
+++ b/blog/2014/04/21/hold-on-4th-elasticsearch-jp/index.html
@@ -521,6 +521,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -910,7 +912,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/04/24/usage-stream2es/index.html b/blog/2014/04/24/usage-stream2es/index.html
index 6255513fe3..ac4b0b99bd 100644
--- a/blog/2014/04/24/usage-stream2es/index.html
+++ b/blog/2014/04/24/usage-stream2es/index.html
@@ -579,6 +579,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -968,7 +970,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/05/04/intro-elasticsearch-kopf-alias-percolator/index.html b/blog/2014/05/04/intro-elasticsearch-kopf-alias-percolator/index.html
index f0e72dbb83..9406041e11 100644
--- a/blog/2014/05/04/intro-elasticsearch-kopf-alias-percolator/index.html
+++ b/blog/2014/05/04/intro-elasticsearch-kopf-alias-percolator/index.html
@@ -440,6 +440,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -829,7 +831,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/05/07/aggregation-example/index.html b/blog/2014/05/07/aggregation-example/index.html
index 16fd5a32d2..2aad95df03 100644
--- a/blog/2014/05/07/aggregation-example/index.html
+++ b/blog/2014/05/07/aggregation-example/index.html
@@ -683,6 +683,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1072,7 +1074,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/05/09/reading-agile-data-science/index.html b/blog/2014/05/09/reading-agile-data-science/index.html
index 1505a3e80e..bbdb00be6e 100644
--- a/blog/2014/05/09/reading-agile-data-science/index.html
+++ b/blog/2014/05/09/reading-agile-data-science/index.html
@@ -470,6 +470,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -859,7 +861,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/05/14/spiritual-entry1/index.html b/blog/2014/05/14/spiritual-entry1/index.html
index 7cae37dfc5..c0e38f39e5 100644
--- a/blog/2014/05/14/spiritual-entry1/index.html
+++ b/blog/2014/05/14/spiritual-entry1/index.html
@@ -427,6 +427,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -816,7 +818,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/05/15/amazon-cloud-seaarch-study-session/index.html b/blog/2014/05/15/amazon-cloud-seaarch-study-session/index.html
index 1889038dd3..7cabe1655f 100644
--- a/blog/2014/05/15/amazon-cloud-seaarch-study-session/index.html
+++ b/blog/2014/05/15/amazon-cloud-seaarch-study-session/index.html
@@ -555,6 +555,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -944,7 +946,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/05/23/attending-drecom-infra-study/index.html b/blog/2014/05/23/attending-drecom-infra-study/index.html
index cd9c3c0c82..a52e165a8e 100644
--- a/blog/2014/05/23/attending-drecom-infra-study/index.html
+++ b/blog/2014/05/23/attending-drecom-infra-study/index.html
@@ -517,6 +517,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -906,7 +908,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/06/04/attending-visualize-study/index.html b/blog/2014/06/04/attending-visualize-study/index.html
index 53fa2cb795..be15929fe5 100644
--- a/blog/2014/06/04/attending-visualize-study/index.html
+++ b/blog/2014/06/04/attending-visualize-study/index.html
@@ -530,6 +530,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -919,7 +921,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/06/16/first-impression-elasticsearch-server-2nd-edition/index.html b/blog/2014/06/16/first-impression-elasticsearch-server-2nd-edition/index.html
index 2252a285d7..33af6bb0fa 100644
--- a/blog/2014/06/16/first-impression-elasticsearch-server-2nd-edition/index.html
+++ b/blog/2014/06/16/first-impression-elasticsearch-server-2nd-edition/index.html
@@ -482,6 +482,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -871,7 +873,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/06/30/resignation/index.html b/blog/2014/06/30/resignation/index.html
index 58e424b668..ef6373beca 100644
--- a/blog/2014/06/30/resignation/index.html
+++ b/blog/2014/06/30/resignation/index.html
@@ -411,6 +411,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -800,7 +802,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/07/01/join-elasticsearch/index.html b/blog/2014/07/01/join-elasticsearch/index.html
index 8c20f0a2ec..fa759abd65 100644
--- a/blog/2014/07/01/join-elasticsearch/index.html
+++ b/blog/2014/07/01/join-elasticsearch/index.html
@@ -445,6 +445,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -834,7 +836,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/07/19/hold-on-5th-elasticsearch-jp/index.html b/blog/2014/07/19/hold-on-5th-elasticsearch-jp/index.html
index 011ba08116..f24933fc92 100644
--- a/blog/2014/07/19/hold-on-5th-elasticsearch-jp/index.html
+++ b/blog/2014/07/19/hold-on-5th-elasticsearch-jp/index.html
@@ -505,6 +505,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -894,7 +896,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/07/28/curator-2-0-and-1-1/index.html b/blog/2014/07/28/curator-2-0-and-1-1/index.html
index 79c4efe3f4..a8291b0951 100644
--- a/blog/2014/07/28/curator-2-0-and-1-1/index.html
+++ b/blog/2014/07/28/curator-2-0-and-1-1/index.html
@@ -638,6 +638,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1027,7 +1029,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/07/29/elasticsearch-1-3-1-release/index.html b/blog/2014/07/29/elasticsearch-1-3-1-release/index.html
index 76593e39e6..f04b2708ed 100644
--- a/blog/2014/07/29/elasticsearch-1-3-1-release/index.html
+++ b/blog/2014/07/29/elasticsearch-1-3-1-release/index.html
@@ -438,6 +438,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -827,7 +829,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/08/01/plugin-using-under-proxy-env/index.html b/blog/2014/08/01/plugin-using-under-proxy-env/index.html
index 3bf77b6d9f..806340362d 100644
--- a/blog/2014/08/01/plugin-using-under-proxy-env/index.html
+++ b/blog/2014/08/01/plugin-using-under-proxy-env/index.html
@@ -459,6 +459,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -848,7 +850,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/08/04/release-magazine-book-of-log-aggs-and-viz/index.html b/blog/2014/08/04/release-magazine-book-of-log-aggs-and-viz/index.html
index 1c75f7ca66..73b675dc10 100644
--- a/blog/2014/08/04/release-magazine-book-of-log-aggs-and-viz/index.html
+++ b/blog/2014/08/04/release-magazine-book-of-log-aggs-and-viz/index.html
@@ -447,6 +447,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -836,7 +838,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/09/09/performance-considerations-for-elasticsearch-indexing/index.html b/blog/2014/09/09/performance-considerations-for-elasticsearch-indexing/index.html
index 2ba4efcc26..4a2feab1d0 100644
--- a/blog/2014/09/09/performance-considerations-for-elasticsearch-indexing/index.html
+++ b/blog/2014/09/09/performance-considerations-for-elasticsearch-indexing/index.html
@@ -509,6 +509,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -898,7 +900,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/09/16/book-publication-event/index.html b/blog/2014/09/16/book-publication-event/index.html
index bad7e9d59b..4c6b69cc59 100644
--- a/blog/2014/09/16/book-publication-event/index.html
+++ b/blog/2014/09/16/book-publication-event/index.html
@@ -443,6 +443,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -832,7 +834,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/09/17/hold-on-6th-elasticsearch-jp/index.html b/blog/2014/09/17/hold-on-6th-elasticsearch-jp/index.html
index 57dd3fdeed..38b2cf47ec 100644
--- a/blog/2014/09/17/hold-on-6th-elasticsearch-jp/index.html
+++ b/blog/2014/09/17/hold-on-6th-elasticsearch-jp/index.html
@@ -502,6 +502,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -891,7 +893,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/10/02/elasticsearch-1-4-0-beta-released-ja/index.html b/blog/2014/10/02/elasticsearch-1-4-0-beta-released-ja/index.html
index ab4344ed73..80a4205f9e 100644
--- a/blog/2014/10/02/elasticsearch-1-4-0-beta-released-ja/index.html
+++ b/blog/2014/10/02/elasticsearch-1-4-0-beta-released-ja/index.html
@@ -591,6 +591,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -980,7 +982,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/10/15/versioning-of-sonatype/index.html b/blog/2014/10/15/versioning-of-sonatype/index.html
index d0f4611fde..6395d7fb5e 100644
--- a/blog/2014/10/15/versioning-of-sonatype/index.html
+++ b/blog/2014/10/15/versioning-of-sonatype/index.html
@@ -435,6 +435,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -824,7 +826,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/10/27/how-to-use-validate-api/index.html b/blog/2014/10/27/how-to-use-validate-api/index.html
index fcfc59a819..194a85895f 100644
--- a/blog/2014/10/27/how-to-use-validate-api/index.html
+++ b/blog/2014/10/27/how-to-use-validate-api/index.html
@@ -616,6 +616,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1005,7 +1007,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/11/06/elasticsearch-1-4-0-ja/index.html b/blog/2014/11/06/elasticsearch-1-4-0-ja/index.html
index c53556db32..a537121851 100644
--- a/blog/2014/11/06/elasticsearch-1-4-0-ja/index.html
+++ b/blog/2014/11/06/elasticsearch-1-4-0-ja/index.html
@@ -462,6 +462,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -851,7 +853,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/11/19/hold-on-7th-elasticsearch-jp/index.html b/blog/2014/11/19/hold-on-7th-elasticsearch-jp/index.html
index 6ba9644861..6437619910 100644
--- a/blog/2014/11/19/hold-on-7th-elasticsearch-jp/index.html
+++ b/blog/2014/11/19/hold-on-7th-elasticsearch-jp/index.html
@@ -525,6 +525,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -914,7 +916,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/11/21/import-apache-accesslog-using-logstash/index.html b/blog/2014/11/21/import-apache-accesslog-using-logstash/index.html
index 1af4e07c0d..186c042b88 100644
--- a/blog/2014/11/21/import-apache-accesslog-using-logstash/index.html
+++ b/blog/2014/11/21/import-apache-accesslog-using-logstash/index.html
@@ -666,6 +666,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1055,7 +1057,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/11/25/import-apache-accesslog-using-logstash-2/index.html b/blog/2014/11/25/import-apache-accesslog-using-logstash-2/index.html
index 6ecc525913..8075aa5343 100644
--- a/blog/2014/11/25/import-apache-accesslog-using-logstash-2/index.html
+++ b/blog/2014/11/25/import-apache-accesslog-using-logstash-2/index.html
@@ -656,6 +656,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1045,7 +1047,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/11/27/elasticsearch-1-4-1-released-ja/index.html b/blog/2014/11/27/elasticsearch-1-4-1-released-ja/index.html
index f2616ed997..922a4d40cc 100644
--- a/blog/2014/11/27/elasticsearch-1-4-1-released-ja/index.html
+++ b/blog/2014/11/27/elasticsearch-1-4-1-released-ja/index.html
@@ -459,6 +459,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -848,7 +850,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/12/01/about-elasticsearch-in-2014/index.html b/blog/2014/12/01/about-elasticsearch-in-2014/index.html
index 8f17155c60..fdd52184e5 100644
--- a/blog/2014/12/01/about-elasticsearch-in-2014/index.html
+++ b/blog/2014/12/01/about-elasticsearch-in-2014/index.html
@@ -577,6 +577,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -966,7 +968,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/12/12/logstash-1-5-0-beta1-released-ja/index.html b/blog/2014/12/12/logstash-1-5-0-beta1-released-ja/index.html
index ff28b533d3..85501cd884 100644
--- a/blog/2014/12/12/logstash-1-5-0-beta1-released-ja/index.html
+++ b/blog/2014/12/12/logstash-1-5-0-beta1-released-ja/index.html
@@ -521,6 +521,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -910,7 +912,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/12/14/plugin-ecosystem-changes/index.html b/blog/2014/12/14/plugin-ecosystem-changes/index.html
index 49cf367160..f931426750 100644
--- a/blog/2014/12/14/plugin-ecosystem-changes/index.html
+++ b/blog/2014/12/14/plugin-ecosystem-changes/index.html
@@ -565,6 +565,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -954,7 +956,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/12/16/a-coffee-break/index.html b/blog/2014/12/16/a-coffee-break/index.html
index d9a3becdd3..67e91ba9d3 100644
--- a/blog/2014/12/16/a-coffee-break/index.html
+++ b/blog/2014/12/16/a-coffee-break/index.html
@@ -422,6 +422,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -811,7 +813,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/12/17/jjug-night-seminar-dec-2014/index.html b/blog/2014/12/17/jjug-night-seminar-dec-2014/index.html
index a867fb8e03..85778de3b7 100644
--- a/blog/2014/12/17/jjug-night-seminar-dec-2014/index.html
+++ b/blog/2014/12/17/jjug-night-seminar-dec-2014/index.html
@@ -526,6 +526,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -915,7 +917,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/12/18/elasticsearch-1-4-2-released-ja/index.html b/blog/2014/12/18/elasticsearch-1-4-2-released-ja/index.html
index 97fcf72789..3147cd00b0 100644
--- a/blog/2014/12/18/elasticsearch-1-4-2-released-ja/index.html
+++ b/blog/2014/12/18/elasticsearch-1-4-2-released-ja/index.html
@@ -451,6 +451,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -840,7 +842,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/12/18/marvel-1-3-0-released-ja/index.html b/blog/2014/12/18/marvel-1-3-0-released-ja/index.html
index 40c00e99ac..6ad0ae07d9 100644
--- a/blog/2014/12/18/marvel-1-3-0-released-ja/index.html
+++ b/blog/2014/12/18/marvel-1-3-0-released-ja/index.html
@@ -524,6 +524,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -913,7 +915,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/12/25/pickup-elasticsearch-2-0-0-labels/index.html b/blog/2014/12/25/pickup-elasticsearch-2-0-0-labels/index.html
index f4647047da..bc5df861cc 100644
--- a/blog/2014/12/25/pickup-elasticsearch-2-0-0-labels/index.html
+++ b/blog/2014/12/25/pickup-elasticsearch-2-0-0-labels/index.html
@@ -471,6 +471,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -860,7 +862,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2014/12/31/looking-back-2014/index.html b/blog/2014/12/31/looking-back-2014/index.html
index 5d0b1dac51..7dfd5e877c 100644
--- a/blog/2014/12/31/looking-back-2014/index.html
+++ b/blog/2014/12/31/looking-back-2014/index.html
@@ -478,6 +478,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -867,7 +869,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/01/29/talk-at-cross2015/index.html b/blog/2015/01/29/talk-at-cross2015/index.html
index ae5219e29a..a4984f5de1 100644
--- a/blog/2015/01/29/talk-at-cross2015/index.html
+++ b/blog/2015/01/29/talk-at-cross2015/index.html
@@ -497,6 +497,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -886,7 +888,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/02/12/elasticsearch-1-4-3-and-1-3-8-released-ja/index.html b/blog/2015/02/12/elasticsearch-1-4-3-and-1-3-8-released-ja/index.html
index 6c53ccf8bd..37cbf39fb4 100644
--- a/blog/2015/02/12/elasticsearch-1-4-3-and-1-3-8-released-ja/index.html
+++ b/blog/2015/02/12/elasticsearch-1-4-3-and-1-3-8-released-ja/index.html
@@ -461,6 +461,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -850,7 +852,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/02/12/running-groovy-scripts-without-dynamic-scripting-ja/index.html b/blog/2015/02/12/running-groovy-scripts-without-dynamic-scripting-ja/index.html
index eb0d3ce4b0..a4568f0e3b 100644
--- a/blog/2015/02/12/running-groovy-scripts-without-dynamic-scripting-ja/index.html
+++ b/blog/2015/02/12/running-groovy-scripts-without-dynamic-scripting-ja/index.html
@@ -549,6 +549,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -938,7 +940,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/02/16/8th-elasticsearch-jp/index.html b/blog/2015/02/16/8th-elasticsearch-jp/index.html
index cd089ae1f6..c99c0062cd 100644
--- a/blog/2015/02/16/8th-elasticsearch-jp/index.html
+++ b/blog/2015/02/16/8th-elasticsearch-jp/index.html
@@ -496,6 +496,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -885,7 +887,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/02/18/preparing-elasticsearch-meetup-in-nagoya/index.html b/blog/2015/02/18/preparing-elasticsearch-meetup-in-nagoya/index.html
index 7e0613b11b..2f1058578a 100644
--- a/blog/2015/02/18/preparing-elasticsearch-meetup-in-nagoya/index.html
+++ b/blog/2015/02/18/preparing-elasticsearch-meetup-in-nagoya/index.html
@@ -425,6 +425,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -814,7 +816,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/02/20/elasticsearch-1-4-4-and-1-3-9-released-ja/index.html b/blog/2015/02/20/elasticsearch-1-4-4-and-1-3-9-released-ja/index.html
index 23b22e3273..0b5159c561 100644
--- a/blog/2015/02/20/elasticsearch-1-4-4-and-1-3-9-released-ja/index.html
+++ b/blog/2015/02/20/elasticsearch-1-4-4-and-1-3-9-released-ja/index.html
@@ -431,6 +431,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -820,7 +822,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/02/20/kibana-4-literally-ja/index.html b/blog/2015/02/20/kibana-4-literally-ja/index.html
index efe54f7781..73d0072036 100644
--- a/blog/2015/02/20/kibana-4-literally-ja/index.html
+++ b/blog/2015/02/20/kibana-4-literally-ja/index.html
@@ -550,6 +550,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -939,7 +941,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/02/27/2nd-tokyo-training/index.html b/blog/2015/02/27/2nd-tokyo-training/index.html
index ed4440dd1e..331e60ac51 100644
--- a/blog/2015/02/27/2nd-tokyo-training/index.html
+++ b/blog/2015/02/27/2nd-tokyo-training/index.html
@@ -416,6 +416,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -805,7 +807,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/02/27/you-know-for-security-shield-goes-ga-ja/index.html b/blog/2015/02/27/you-know-for-security-shield-goes-ga-ja/index.html
index e87f251a48..fb0e518b2e 100644
--- a/blog/2015/02/27/you-know-for-security-shield-goes-ga-ja/index.html
+++ b/blog/2015/02/27/you-know-for-security-shield-goes-ga-ja/index.html
@@ -672,6 +672,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1061,7 +1063,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/03/11/attend-elasticon/index.html b/blog/2015/03/11/attend-elasticon/index.html
index fed7f9d223..ccdeaea30b 100644
--- a/blog/2015/03/11/attend-elasticon/index.html
+++ b/blog/2015/03/11/attend-elasticon/index.html
@@ -470,6 +470,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -859,7 +861,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/04/01/elasticsearch-1-5-0-released-ja/index.html b/blog/2015/04/01/elasticsearch-1-5-0-released-ja/index.html
index 3e909c772c..5909f613df 100644
--- a/blog/2015/04/01/elasticsearch-1-5-0-released-ja/index.html
+++ b/blog/2015/04/01/elasticsearch-1-5-0-released-ja/index.html
@@ -567,6 +567,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -956,7 +958,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/04/04/elasticsearch-study-session-at-nagoya/index.html b/blog/2015/04/04/elasticsearch-study-session-at-nagoya/index.html
index fa1c422d7d..1b790a2801 100644
--- a/blog/2015/04/04/elasticsearch-study-session-at-nagoya/index.html
+++ b/blog/2015/04/04/elasticsearch-study-session-at-nagoya/index.html
@@ -529,6 +529,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -918,7 +920,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/04/13/elasticsearch-1-5-1-released-ja/index.html b/blog/2015/04/13/elasticsearch-1-5-1-released-ja/index.html
index 1fc72ea944..d156f38130 100644
--- a/blog/2015/04/13/elasticsearch-1-5-1-released-ja/index.html
+++ b/blog/2015/04/13/elasticsearch-1-5-1-released-ja/index.html
@@ -432,6 +432,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -821,7 +823,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/04/17/9th-elasticsearch-jp/index.html b/blog/2015/04/17/9th-elasticsearch-jp/index.html
index 3a9ef5f476..ae98b6858d 100644
--- a/blog/2015/04/17/9th-elasticsearch-jp/index.html
+++ b/blog/2015/04/17/9th-elasticsearch-jp/index.html
@@ -483,6 +483,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -872,7 +874,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/04/28/elasticsearch-1-5-2-and-1-4-5-released-ja/index.html b/blog/2015/04/28/elasticsearch-1-5-2-and-1-4-5-released-ja/index.html
index 362f444afa..23df84e53b 100644
--- a/blog/2015/04/28/elasticsearch-1-5-2-and-1-4-5-released-ja/index.html
+++ b/blog/2015/04/28/elasticsearch-1-5-2-and-1-4-5-released-ja/index.html
@@ -464,6 +464,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -853,7 +855,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/05/21/join-the-conversation-ja/index.html b/blog/2015/05/21/join-the-conversation-ja/index.html
index a28a1cf173..40d09a5f91 100644
--- a/blog/2015/05/21/join-the-conversation-ja/index.html
+++ b/blog/2015/05/21/join-the-conversation-ja/index.html
@@ -416,6 +416,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -805,7 +807,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/05/26/reindex-elasticsearch-with-logstash-ja/index.html b/blog/2015/05/26/reindex-elasticsearch-with-logstash-ja/index.html
index 2ec151255d..81db6a8082 100644
--- a/blog/2015/05/26/reindex-elasticsearch-with-logstash-ja/index.html
+++ b/blog/2015/05/26/reindex-elasticsearch-with-logstash-ja/index.html
@@ -854,6 +854,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1243,7 +1245,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/06/02/10th-elasticsearch-jp/index.html b/blog/2015/06/02/10th-elasticsearch-jp/index.html
index 8505faeb6c..15e1193646 100644
--- a/blog/2015/06/02/10th-elasticsearch-jp/index.html
+++ b/blog/2015/06/02/10th-elasticsearch-jp/index.html
@@ -511,6 +511,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -900,7 +902,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/06/10/elasticsearch-1-6-0-released-ja/index.html b/blog/2015/06/10/elasticsearch-1-6-0-released-ja/index.html
index 9c900dc3b9..88679acb92 100644
--- a/blog/2015/06/10/elasticsearch-1-6-0-released-ja/index.html
+++ b/blog/2015/06/10/elasticsearch-1-6-0-released-ja/index.html
@@ -595,6 +595,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -984,7 +986,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/06/17/attend-hatena-engineer-seminar-5/index.html b/blog/2015/06/17/attend-hatena-engineer-seminar-5/index.html
index 6afec23387..771e798e11 100644
--- a/blog/2015/06/17/attend-hatena-engineer-seminar-5/index.html
+++ b/blog/2015/06/17/attend-hatena-engineer-seminar-5/index.html
@@ -513,6 +513,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -902,7 +904,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/07/06/attend-justsystem-techtalk-no2/index.html b/blog/2015/07/06/attend-justsystem-techtalk-no2/index.html
index 53f84c9ac2..fe8068adc4 100644
--- a/blog/2015/07/06/attend-justsystem-techtalk-no2/index.html
+++ b/blog/2015/07/06/attend-justsystem-techtalk-no2/index.html
@@ -432,9 +432,9 @@ <h3>Related by prelims-cli</h3>
     
     <li><a href="https://blog.johtani.info/blog/2020/04/27/note-updating-dictionary/">辞書の更新についての注意点</a></li>
     
-    <li><a href="https://blog.johtani.info/blog/2011/07/20/kuromoji%E3%82%92%E8%AA%BF%E3%81%B9%E3%81%A6%E3%81%BF%E3%81%9F/">Kuromojiを調べてみた(Jugemより移植)</a></li>
+    <li><a href="https://blog.johtani.info/blog/2011/07/27/%E7%AC%AC1%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/">第1回 データ構造と情報検索と言語処理勉強会に参加しました。(Jugemより移植)</a></li>
     
-    <li><a href="https://blog.johtani.info/blog/2011/06/02/%E8%BE%9E%E6%9B%B8%E3%81%A8%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E8%BE%9E%E6%9B%B8%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/">辞書とカスタム辞書について(Jugemより移植)</a></li>
+    <li><a href="https://blog.johtani.info/blog/2011/07/20/kuromoji%E3%82%92%E8%AA%BF%E3%81%B9%E3%81%A6%E3%81%BF%E3%81%9F/">Kuromojiを調べてみた(Jugemより移植)</a></li>
     
   </ul>
 </div>
@@ -545,6 +545,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -934,7 +936,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/07/07/elasticsearch-2-dot-0-0-dot-beta1-coming-soon-ja/index.html b/blog/2015/07/07/elasticsearch-2-dot-0-0-dot-beta1-coming-soon-ja/index.html
index 20422f3dc8..3c426eb327 100644
--- a/blog/2015/07/07/elasticsearch-2-dot-0-0-dot-beta1-coming-soon-ja/index.html
+++ b/blog/2015/07/07/elasticsearch-2-dot-0-0-dot-beta1-coming-soon-ja/index.html
@@ -521,6 +521,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -910,7 +912,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/07/07/we-just-made-found-more-awesome-ja/index.html b/blog/2015/07/07/we-just-made-found-more-awesome-ja/index.html
index 063052694d..d22efed7b2 100644
--- a/blog/2015/07/07/we-just-made-found-more-awesome-ja/index.html
+++ b/blog/2015/07/07/we-just-made-found-more-awesome-ja/index.html
@@ -459,6 +459,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -848,7 +850,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/07/08/great-mapping-refactoring-ja/index.html b/blog/2015/07/08/great-mapping-refactoring-ja/index.html
index fadc2dee53..fc5a65533b 100644
--- a/blog/2015/07/08/great-mapping-refactoring-ja/index.html
+++ b/blog/2015/07/08/great-mapping-refactoring-ja/index.html
@@ -669,6 +669,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1058,7 +1060,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/07/16/kansai-1st-elasticsearch-jp/index.html b/blog/2015/07/16/kansai-1st-elasticsearch-jp/index.html
index 8708f5f485..c9db9486b5 100644
--- a/blog/2015/07/16/kansai-1st-elasticsearch-jp/index.html
+++ b/blog/2015/07/16/kansai-1st-elasticsearch-jp/index.html
@@ -542,6 +542,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -931,7 +933,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/07/22/elasticsearch-1-7-0-and-1-6-1-released-ja/index.html b/blog/2015/07/22/elasticsearch-1-7-0-and-1-6-1-released-ja/index.html
index cc8a11a63e..aae0acab2e 100644
--- a/blog/2015/07/22/elasticsearch-1-7-0-and-1-6-1-released-ja/index.html
+++ b/blog/2015/07/22/elasticsearch-1-7-0-and-1-6-1-released-ja/index.html
@@ -511,6 +511,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -900,7 +902,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/07/29/elasticsearch-1-7-1-and-1-6-2-released-ja/index.html b/blog/2015/07/29/elasticsearch-1-7-1-and-1-6-2-released-ja/index.html
index 55a03795d8..e8ab7a1487 100644
--- a/blog/2015/07/29/elasticsearch-1-7-1-and-1-6-2-released-ja/index.html
+++ b/blog/2015/07/29/elasticsearch-1-7-1-and-1-6-2-released-ja/index.html
@@ -428,6 +428,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -817,7 +819,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/07/31/11th-elasticsearch-jp/index.html b/blog/2015/07/31/11th-elasticsearch-jp/index.html
index 24127adb90..c1e6a65754 100644
--- a/blog/2015/07/31/11th-elasticsearch-jp/index.html
+++ b/blog/2015/07/31/11th-elasticsearch-jp/index.html
@@ -522,6 +522,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -911,7 +913,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/08/20/core-delete-by-query-is-a-plugin-ja/index.html b/blog/2015/08/20/core-delete-by-query-is-a-plugin-ja/index.html
index 764e4c92f9..738781ac2c 100644
--- a/blog/2015/08/20/core-delete-by-query-is-a-plugin-ja/index.html
+++ b/blog/2015/08/20/core-delete-by-query-is-a-plugin-ja/index.html
@@ -447,6 +447,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -836,7 +838,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/08/27/elasticsearch-2-0-0-beta1-released-ja/index.html b/blog/2015/08/27/elasticsearch-2-0-0-beta1-released-ja/index.html
index 647eadd7b5..59d11df835 100644
--- a/blog/2015/08/27/elasticsearch-2-0-0-beta1-released-ja/index.html
+++ b/blog/2015/08/27/elasticsearch-2-0-0-beta1-released-ja/index.html
@@ -489,6 +489,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -878,7 +880,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/08/28/elasticsearch-unplugged-ja/index.html b/blog/2015/08/28/elasticsearch-unplugged-ja/index.html
index ebde4cbb47..a14ccea1b7 100644
--- a/blog/2015/08/28/elasticsearch-unplugged-ja/index.html
+++ b/blog/2015/08/28/elasticsearch-unplugged-ja/index.html
@@ -464,6 +464,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -853,7 +855,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/09/18/elasticsearch-2-0-0-beta2-released-ja/index.html b/blog/2015/09/18/elasticsearch-2-0-0-beta2-released-ja/index.html
index cb89d07c47..0d8d36bd8f 100644
--- a/blog/2015/09/18/elasticsearch-2-0-0-beta2-released-ja/index.html
+++ b/blog/2015/09/18/elasticsearch-2-0-0-beta2-released-ja/index.html
@@ -489,6 +489,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -878,7 +880,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/10/29/elasticsearch-2-0-0-released-ja/index.html b/blog/2015/10/29/elasticsearch-2-0-0-released-ja/index.html
index dc13b79425..2a72e32df2 100644
--- a/blog/2015/10/29/elasticsearch-2-0-0-released-ja/index.html
+++ b/blog/2015/10/29/elasticsearch-2-0-0-released-ja/index.html
@@ -565,6 +565,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -954,7 +956,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/10/29/kibana-4-2-0-ja/index.html b/blog/2015/10/29/kibana-4-2-0-ja/index.html
index ae0d4ef16a..89070ef7ae 100644
--- a/blog/2015/10/29/kibana-4-2-0-ja/index.html
+++ b/blog/2015/10/29/kibana-4-2-0-ja/index.html
@@ -461,6 +461,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -850,7 +852,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/10/29/logstash-2-0-0-released-ja/index.html b/blog/2015/10/29/logstash-2-0-0-released-ja/index.html
index b831a2fe71..c2d5af9e61 100644
--- a/blog/2015/10/29/logstash-2-0-0-released-ja/index.html
+++ b/blog/2015/10/29/logstash-2-0-0-released-ja/index.html
@@ -520,6 +520,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -909,7 +911,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/10/29/release-we-have-ja/index.html b/blog/2015/10/29/release-we-have-ja/index.html
index eb7e821e97..6683348790 100644
--- a/blog/2015/10/29/release-we-have-ja/index.html
+++ b/blog/2015/10/29/release-we-have-ja/index.html
@@ -465,6 +465,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -854,7 +856,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/10/30/sense-2-0-0-beta1-ja/index.html b/blog/2015/10/30/sense-2-0-0-beta1-ja/index.html
index 0e6951d6d1..9e8bc1c410 100644
--- a/blog/2015/10/30/sense-2-0-0-beta1-ja/index.html
+++ b/blog/2015/10/30/sense-2-0-0-beta1-ja/index.html
@@ -567,6 +567,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -956,7 +958,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/10/30/shield-watcher-and-marvel-2-0-ga-released-ja/index.html b/blog/2015/10/30/shield-watcher-and-marvel-2-0-ga-released-ja/index.html
index 263288c13e..8843d8b202 100644
--- a/blog/2015/10/30/shield-watcher-and-marvel-2-0-ga-released-ja/index.html
+++ b/blog/2015/10/30/shield-watcher-and-marvel-2-0-ga-released-ja/index.html
@@ -555,6 +555,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -944,7 +946,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/11/10/13th-elasticsearch-jp/index.html b/blog/2015/11/10/13th-elasticsearch-jp/index.html
index 1fccad9964..8845cf1f5f 100644
--- a/blog/2015/11/10/13th-elasticsearch-jp/index.html
+++ b/blog/2015/11/10/13th-elasticsearch-jp/index.html
@@ -487,6 +487,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -876,7 +878,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/12/01/introduction-timelion/index.html b/blog/2015/12/01/introduction-timelion/index.html
index 7d676fb12f..b0c770e9c3 100644
--- a/blog/2015/12/01/introduction-timelion/index.html
+++ b/blog/2015/12/01/introduction-timelion/index.html
@@ -538,6 +538,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -927,7 +929,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/12/25/about-elasticsearch-in-2015/index.html b/blog/2015/12/25/about-elasticsearch-in-2015/index.html
index 6e4ba4d875..a515a9e3c9 100644
--- a/blog/2015/12/25/about-elasticsearch-in-2015/index.html
+++ b/blog/2015/12/25/about-elasticsearch-in-2015/index.html
@@ -541,6 +541,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -930,7 +932,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2015/12/31/looking-back-2015/index.html b/blog/2015/12/31/looking-back-2015/index.html
index 42aff66ba6..90e386a38d 100644
--- a/blog/2015/12/31/looking-back-2015/index.html
+++ b/blog/2015/12/31/looking-back-2015/index.html
@@ -474,6 +474,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -863,7 +865,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2016/01/08/14th-elasticcsearch-jp/index.html b/blog/2016/01/08/14th-elasticcsearch-jp/index.html
index 41c9a73352..c87e21ff69 100644
--- a/blog/2016/01/08/14th-elasticcsearch-jp/index.html
+++ b/blog/2016/01/08/14th-elasticcsearch-jp/index.html
@@ -540,6 +540,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -929,7 +931,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2016/03/14/review-basics-and-tech-of-nlp/index.html b/blog/2016/03/14/review-basics-and-tech-of-nlp/index.html
index 8f0e6e5288..23d6eb18f4 100644
--- a/blog/2016/03/14/review-basics-and-tech-of-nlp/index.html
+++ b/blog/2016/03/14/review-basics-and-tech-of-nlp/index.html
@@ -435,6 +435,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -824,7 +826,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2016/03/17/15th-elasticsearch-jp/index.html b/blog/2016/03/17/15th-elasticsearch-jp/index.html
index 67d54df874..7bfd50660b 100644
--- a/blog/2016/03/17/15th-elasticsearch-jp/index.html
+++ b/blog/2016/03/17/15th-elasticsearch-jp/index.html
@@ -484,6 +484,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -873,7 +875,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2016/06/28/16th-elasticsearch-meetup/index.html b/blog/2016/06/28/16th-elasticsearch-meetup/index.html
index 6bc1eaa0f0..a63158d686 100644
--- a/blog/2016/06/28/16th-elasticsearch-meetup/index.html
+++ b/blog/2016/06/28/16th-elasticsearch-meetup/index.html
@@ -533,6 +533,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -922,7 +924,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2016/06/30/broken-something-in-this-year/index.html b/blog/2016/06/30/broken-something-in-this-year/index.html
index 67ae92d52f..5d5bbe75cf 100644
--- a/blog/2016/06/30/broken-something-in-this-year/index.html
+++ b/blog/2016/06/30/broken-something-in-this-year/index.html
@@ -436,6 +436,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -825,7 +827,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2016/07/22/making-ingest-processor-plugin-with-cookiecutter/index.html b/blog/2016/07/22/making-ingest-processor-plugin-with-cookiecutter/index.html
index 654a48fe49..cafa9433ec 100644
--- a/blog/2016/07/22/making-ingest-processor-plugin-with-cookiecutter/index.html
+++ b/blog/2016/07/22/making-ingest-processor-plugin-with-cookiecutter/index.html
@@ -644,6 +644,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1033,7 +1035,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2016/12/01/elasticsearch-5-dot-0-highlight/index.html b/blog/2016/12/01/elasticsearch-5-dot-0-highlight/index.html
index eaf05f44ca..ebb1b0a7e2 100644
--- a/blog/2016/12/01/elasticsearch-5-dot-0-highlight/index.html
+++ b/blog/2016/12/01/elasticsearch-5-dot-0-highlight/index.html
@@ -476,6 +476,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -865,7 +867,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2016/12/25/elasticsearch-6-features/index.html b/blog/2016/12/25/elasticsearch-6-features/index.html
index a1c23def16..82b6159be3 100644
--- a/blog/2016/12/25/elasticsearch-6-features/index.html
+++ b/blog/2016/12/25/elasticsearch-6-features/index.html
@@ -503,6 +503,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -892,7 +894,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2016/12/31/looking-back-2016/index.html b/blog/2016/12/31/looking-back-2016/index.html
index 96bc3e2291..99247cf125 100644
--- a/blog/2016/12/31/looking-back-2016/index.html
+++ b/blog/2016/12/31/looking-back-2016/index.html
@@ -512,6 +512,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -901,7 +903,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2017/05/25/search-meetup/index.html b/blog/2017/05/25/search-meetup/index.html
index 5395a31cd0..638e5285cc 100644
--- a/blog/2017/05/25/search-meetup/index.html
+++ b/blog/2017/05/25/search-meetup/index.html
@@ -346,7 +346,7 @@ <h3>Related by prelims-cli</h3>
     
     <li><a href="https://blog.johtani.info/blog/2020/07/27/improve-search-no1/">システムの特徴と検索機能について(検索システムに関する妄想その1)</a></li>
     
-    <li><a href="https://blog.johtani.info/blog/2019/02/26/start-search-engineering-tech-talk/">Search Engineering Tech Talk(検索技術勉強会)の運営として参加して始めてみました。</a></li>
+    <li><a href="https://blog.johtani.info/blog/2013/01/16/%E3%81%84%E3%81%BE%E3%81%95%E3%82%89%E3%81%A7%E3%81%99%E3%81%8Ccross-2013%E3%81%A7%E6%A4%9C%E7%B4%A2cross%E3%81%A8%E3%81%84%E3%81%86%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E6%8B%85%E5%BD%93%E3%81%97%E3%81%BE%E3%81%99/">いまさらですが、CROSS 2013で検索CROSSというセッションを担当します(Jugemより移植)</a></li>
     
   </ul>
 </div>
@@ -457,6 +457,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -846,7 +848,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2017/09/21/release-intro-logging-analysis-system/index.html b/blog/2017/09/21/release-intro-logging-analysis-system/index.html
index fee2659846..bf8b9ffde9 100644
--- a/blog/2017/09/21/release-intro-logging-analysis-system/index.html
+++ b/blog/2017/09/21/release-intro-logging-analysis-system/index.html
@@ -425,6 +425,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -814,7 +816,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2017/11/10/welcome-swiftype/index.html b/blog/2017/11/10/welcome-swiftype/index.html
index 3f7e707ec7..2a3066a1cd 100644
--- a/blog/2017/11/10/welcome-swiftype/index.html
+++ b/blog/2017/11/10/welcome-swiftype/index.html
@@ -513,6 +513,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -902,7 +904,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2017/12/01/whats-happen-at-elastic-in-2017/index.html b/blog/2017/12/01/whats-happen-at-elastic-in-2017/index.html
index 4fbc968776..001c055959 100644
--- a/blog/2017/12/01/whats-happen-at-elastic-in-2017/index.html
+++ b/blog/2017/12/01/whats-happen-at-elastic-in-2017/index.html
@@ -491,6 +491,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -880,7 +882,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2017/12/24/elastic-2018/index.html b/blog/2017/12/24/elastic-2018/index.html
index 9ef6981294..813be83e69 100644
--- a/blog/2017/12/24/elastic-2018/index.html
+++ b/blog/2017/12/24/elastic-2018/index.html
@@ -476,6 +476,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -865,7 +867,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2017/12/31/looking-back-2017/index.html b/blog/2017/12/31/looking-back-2017/index.html
index 8d2783805e..708cab4d78 100644
--- a/blog/2017/12/31/looking-back-2017/index.html
+++ b/blog/2017/12/31/looking-back-2017/index.html
@@ -514,6 +514,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -903,7 +905,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2018/01/19/how-to-make-kibana-plugin-example-analysis-ui/index.html b/blog/2018/01/19/how-to-make-kibana-plugin-example-analysis-ui/index.html
index 62a27592c1..f822742200 100644
--- a/blog/2018/01/19/how-to-make-kibana-plugin-example-analysis-ui/index.html
+++ b/blog/2018/01/19/how-to-make-kibana-plugin-example-analysis-ui/index.html
@@ -520,6 +520,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -909,7 +911,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2018/02/09/getting-started-template-kibana-plugin/index.html b/blog/2018/02/09/getting-started-template-kibana-plugin/index.html
index aa2a6278ed..b95abc911a 100644
--- a/blog/2018/02/09/getting-started-template-kibana-plugin/index.html
+++ b/blog/2018/02/09/getting-started-template-kibana-plugin/index.html
@@ -542,6 +542,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -931,7 +933,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2018/02/14/start-nlp100-with-rust/index.html b/blog/2018/02/14/start-nlp100-with-rust/index.html
index 6e1eb5e762..fdd2412299 100644
--- a/blog/2018/02/14/start-nlp100-with-rust/index.html
+++ b/blog/2018/02/14/start-nlp100-with-rust/index.html
@@ -424,6 +424,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -813,7 +815,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2018/02/15/nlp100-ch01-00to02/index.html b/blog/2018/02/15/nlp100-ch01-00to02/index.html
index 4f03b46987..a05ef6c2e2 100644
--- a/blog/2018/02/15/nlp100-ch01-00to02/index.html
+++ b/blog/2018/02/15/nlp100-ch01-00to02/index.html
@@ -450,6 +450,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -839,7 +841,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2018/02/19/nlp100-ch01-03to04/index.html b/blog/2018/02/19/nlp100-ch01-03to04/index.html
index bf7d495435..8c31c3717c 100644
--- a/blog/2018/02/19/nlp100-ch01-03to04/index.html
+++ b/blog/2018/02/19/nlp100-ch01-03to04/index.html
@@ -451,6 +451,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -840,7 +842,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2018/03/20/nlp100-ch01-05to06/index.html b/blog/2018/03/20/nlp100-ch01-05to06/index.html
index 434dbe2acc..06c081d115 100644
--- a/blog/2018/03/20/nlp100-ch01-05to06/index.html
+++ b/blog/2018/03/20/nlp100-ch01-05to06/index.html
@@ -456,6 +456,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -845,7 +847,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2018/03/24/how-to-find-conferences/index.html b/blog/2018/03/24/how-to-find-conferences/index.html
index a8552b0006..b839ba45a6 100644
--- a/blog/2018/03/24/how-to-find-conferences/index.html
+++ b/blog/2018/03/24/how-to-find-conferences/index.html
@@ -439,6 +439,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -828,7 +830,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2018/04/20/directory-layout-and-architecture/index.html b/blog/2018/04/20/directory-layout-and-architecture/index.html
index f73818d7be..a7d2336fea 100644
--- a/blog/2018/04/20/directory-layout-and-architecture/index.html
+++ b/blog/2018/04/20/directory-layout-and-architecture/index.html
@@ -639,6 +639,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1028,7 +1030,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2018/07/29/apm-java-at-jjug/index.html b/blog/2018/07/29/apm-java-at-jjug/index.html
index 6b8a1ac8a3..2d0eada720 100644
--- a/blog/2018/07/29/apm-java-at-jjug/index.html
+++ b/blog/2018/07/29/apm-java-at-jjug/index.html
@@ -485,6 +485,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -874,7 +876,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2018/10/17/26th-elasticsearch-tokyo-meetup/index.html b/blog/2018/10/17/26th-elasticsearch-tokyo-meetup/index.html
index 2f3cf16585..6461c446bb 100644
--- a/blog/2018/10/17/26th-elasticsearch-tokyo-meetup/index.html
+++ b/blog/2018/10/17/26th-elasticsearch-tokyo-meetup/index.html
@@ -490,6 +490,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -879,7 +881,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2018/10/18/items-for-long-businesstrip/index.html b/blog/2018/10/18/items-for-long-businesstrip/index.html
index 64122818dc..5df8c78097 100644
--- a/blog/2018/10/18/items-for-long-businesstrip/index.html
+++ b/blog/2018/10/18/items-for-long-businesstrip/index.html
@@ -471,6 +471,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -860,7 +862,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2018/12/01/whats-happen-at-elastic-in-2018/index.html b/blog/2018/12/01/whats-happen-at-elastic-in-2018/index.html
index 5593a394dc..fc2e7b74e6 100644
--- a/blog/2018/12/01/whats-happen-at-elastic-in-2018/index.html
+++ b/blog/2018/12/01/whats-happen-at-elastic-in-2018/index.html
@@ -543,6 +543,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -932,7 +934,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2018/12/25/whats-new-in-elastic-stack-7/index.html b/blog/2018/12/25/whats-new-in-elastic-stack-7/index.html
index 293de2e85b..fb5f3a0864 100644
--- a/blog/2018/12/25/whats-new-in-elastic-stack-7/index.html
+++ b/blog/2018/12/25/whats-new-in-elastic-stack-7/index.html
@@ -471,6 +471,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -860,7 +862,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2018/12/31/looking-back-2018/index.html b/blog/2018/12/31/looking-back-2018/index.html
index a5c07a4476..be0bccc283 100644
--- a/blog/2018/12/31/looking-back-2018/index.html
+++ b/blog/2018/12/31/looking-back-2018/index.html
@@ -533,6 +533,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -922,7 +924,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2019/02/26/start-search-engineering-tech-talk/index.html b/blog/2019/02/26/start-search-engineering-tech-talk/index.html
index 0a05b986b4..481a3c5678 100644
--- a/blog/2019/02/26/start-search-engineering-tech-talk/index.html
+++ b/blog/2019/02/26/start-search-engineering-tech-talk/index.html
@@ -445,6 +445,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -834,7 +836,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2019/04/26/meetup-organizer-drinkup/index.html b/blog/2019/04/26/meetup-organizer-drinkup/index.html
index 2e7d22ba71..252dd1a9b4 100644
--- a/blog/2019/04/26/meetup-organizer-drinkup/index.html
+++ b/blog/2019/04/26/meetup-organizer-drinkup/index.html
@@ -463,6 +463,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -852,7 +854,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2019/06/19/qr-code-with-meetup-dot-com/index.html b/blog/2019/06/19/qr-code-with-meetup-dot-com/index.html
index b5d5cfbd10..c9edbfad08 100644
--- a/blog/2019/06/19/qr-code-with-meetup-dot-com/index.html
+++ b/blog/2019/06/19/qr-code-with-meetup-dot-com/index.html
@@ -551,6 +551,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -940,7 +942,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2019/10/10/review-es-next-step-2/index.html b/blog/2019/10/10/review-es-next-step-2/index.html
index 5905b414eb..35bf301729 100644
--- a/blog/2019/10/10/review-es-next-step-2/index.html
+++ b/blog/2019/10/10/review-es-next-step-2/index.html
@@ -434,6 +434,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -823,7 +825,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2019/10/25/bonefire-01/index.html b/blog/2019/10/25/bonefire-01/index.html
index ec6195fba4..04d52d35c0 100644
--- a/blog/2019/10/25/bonefire-01/index.html
+++ b/blog/2019/10/25/bonefire-01/index.html
@@ -876,6 +876,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1265,7 +1267,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2019/12/01/whats-happen-at-elastic-in-2019/index.html b/blog/2019/12/01/whats-happen-at-elastic-in-2019/index.html
index 26e3bff50c..1514d84108 100644
--- a/blog/2019/12/01/whats-happen-at-elastic-in-2019/index.html
+++ b/blog/2019/12/01/whats-happen-at-elastic-in-2019/index.html
@@ -498,6 +498,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -887,7 +889,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2019/12/04/about-lucene-4056/index.html b/blog/2019/12/04/about-lucene-4056/index.html
index c81a960c1a..c35c5d33bb 100644
--- a/blog/2019/12/04/about-lucene-4056/index.html
+++ b/blog/2019/12/04/about-lucene-4056/index.html
@@ -476,6 +476,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -865,7 +867,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2019/12/06/leaving-elastic/index.html b/blog/2019/12/06/leaving-elastic/index.html
index cc2e916d08..159f2c06e1 100644
--- a/blog/2019/12/06/leaving-elastic/index.html
+++ b/blog/2019/12/06/leaving-elastic/index.html
@@ -423,6 +423,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -812,7 +814,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2019/12/16/dockernize-octopress/index.html b/blog/2019/12/16/dockernize-octopress/index.html
index 2589e6c173..5b575e29f6 100644
--- a/blog/2019/12/16/dockernize-octopress/index.html
+++ b/blog/2019/12/16/dockernize-octopress/index.html
@@ -465,6 +465,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -854,7 +856,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2019/12/17/move-to-zsh/index.html b/blog/2019/12/17/move-to-zsh/index.html
index e9b9925b82..a531b30f79 100644
--- a/blog/2019/12/17/move-to-zsh/index.html
+++ b/blog/2019/12/17/move-to-zsh/index.html
@@ -457,6 +457,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -846,7 +848,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2019/12/18/introduce-homeshick/index.html b/blog/2019/12/18/introduce-homeshick/index.html
index cb9525a4d1..d5012e8850 100644
--- a/blog/2019/12/18/introduce-homeshick/index.html
+++ b/blog/2019/12/18/introduce-homeshick/index.html
@@ -445,6 +445,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -834,7 +836,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2019/12/23/whats-window-group-of-terminal/index.html b/blog/2019/12/23/whats-window-group-of-terminal/index.html
index e7c8656fa8..df851839f0 100644
--- a/blog/2019/12/23/whats-window-group-of-terminal/index.html
+++ b/blog/2019/12/23/whats-window-group-of-terminal/index.html
@@ -540,6 +540,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -929,7 +931,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2019/12/31/looking-back-2019/index.html b/blog/2019/12/31/looking-back-2019/index.html
index f066cb1feb..f487681249 100644
--- a/blog/2019/12/31/looking-back-2019/index.html
+++ b/blog/2019/12/31/looking-back-2019/index.html
@@ -502,6 +502,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -891,7 +893,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/01/16/moving-to-hugo/index.html b/blog/2020/01/16/moving-to-hugo/index.html
index e4be73af24..f7deb0630a 100644
--- a/blog/2020/01/16/moving-to-hugo/index.html
+++ b/blog/2020/01/16/moving-to-hugo/index.html
@@ -467,6 +467,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -856,7 +858,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/01/22/intro-hugo-and-theme/index.html b/blog/2020/01/22/intro-hugo-and-theme/index.html
index 0e8e835397..50ff8a2785 100644
--- a/blog/2020/01/22/intro-hugo-and-theme/index.html
+++ b/blog/2020/01/22/intro-hugo-and-theme/index.html
@@ -509,6 +509,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -898,7 +900,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/01/23/convert-md-from-octopress-to-hugo/index.html b/blog/2020/01/23/convert-md-from-octopress-to-hugo/index.html
index 7cfb42cf93..b397b5f655 100644
--- a/blog/2020/01/23/convert-md-from-octopress-to-hugo/index.html
+++ b/blog/2020/01/23/convert-md-from-octopress-to-hugo/index.html
@@ -478,6 +478,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -867,7 +869,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/01/24/setting-hugo/index.html b/blog/2020/01/24/setting-hugo/index.html
index b4b07807c6..b8efb34671 100644
--- a/blog/2020/01/24/setting-hugo/index.html
+++ b/blog/2020/01/24/setting-hugo/index.html
@@ -572,6 +572,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -961,7 +963,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/01/28/introduce-algolia/index.html b/blog/2020/01/28/introduce-algolia/index.html
index abe0f12514..e40237e224 100644
--- a/blog/2020/01/28/introduce-algolia/index.html
+++ b/blog/2020/01/28/introduce-algolia/index.html
@@ -588,6 +588,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -977,7 +979,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/01/31/start-freelance/index.html b/blog/2020/01/31/start-freelance/index.html
index 49321be7fa..5ff1841ec8 100644
--- a/blog/2020/01/31/start-freelance/index.html
+++ b/blog/2020/01/31/start-freelance/index.html
@@ -428,6 +428,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -817,7 +819,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/01/31/start-reading-bicycle-book/index.html b/blog/2020/01/31/start-reading-bicycle-book/index.html
index ee2cd95bc9..2076515b75 100644
--- a/blog/2020/01/31/start-reading-bicycle-book/index.html
+++ b/blog/2020/01/31/start-reading-bicycle-book/index.html
@@ -469,6 +469,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -858,7 +860,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/02/01/intro-board-game/index.html b/blog/2020/02/01/intro-board-game/index.html
index 9963f7a239..e42e40ee8d 100644
--- a/blog/2020/02/01/intro-board-game/index.html
+++ b/blog/2020/02/01/intro-board-game/index.html
@@ -646,6 +646,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1035,7 +1037,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/02/10/explore-search-system/index.html b/blog/2020/02/10/explore-search-system/index.html
index 7693f5c239..7aefea6139 100644
--- a/blog/2020/02/10/explore-search-system/index.html
+++ b/blog/2020/02/10/explore-search-system/index.html
@@ -564,6 +564,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -953,7 +955,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/02/19/research-azure-cognitive-search/index.html b/blog/2020/02/19/research-azure-cognitive-search/index.html
index 1308dbac08..dce7f0386e 100644
--- a/blog/2020/02/19/research-azure-cognitive-search/index.html
+++ b/blog/2020/02/19/research-azure-cognitive-search/index.html
@@ -696,6 +696,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1085,7 +1087,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/02/21/best-buy-2019/index.html b/blog/2020/02/21/best-buy-2019/index.html
index 40a63388c1..76671d0efc 100644
--- a/blog/2020/02/21/best-buy-2019/index.html
+++ b/blog/2020/02/21/best-buy-2019/index.html
@@ -601,6 +601,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -990,7 +992,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/02/21/import-jugem-posts/index.html b/blog/2020/02/21/import-jugem-posts/index.html
index 6f80cf51ae..4196d72128 100644
--- a/blog/2020/02/21/import-jugem-posts/index.html
+++ b/blog/2020/02/21/import-jugem-posts/index.html
@@ -486,6 +486,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -875,7 +877,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/02/23/bicycle-book-chap3/index.html b/blog/2020/02/23/bicycle-book-chap3/index.html
index 7546ea3587..50bc6d1e49 100644
--- a/blog/2020/02/23/bicycle-book-chap3/index.html
+++ b/blog/2020/02/23/bicycle-book-chap3/index.html
@@ -458,6 +458,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -847,7 +849,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/02/28/kuromoji-cli/index.html b/blog/2020/02/28/kuromoji-cli/index.html
index 54a5335e3b..d2675bdda5 100644
--- a/blog/2020/02/28/kuromoji-cli/index.html
+++ b/blog/2020/02/28/kuromoji-cli/index.html
@@ -483,6 +483,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -872,7 +874,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/03/02/finish-bicycle-book-chap3/index.html b/blog/2020/03/02/finish-bicycle-book-chap3/index.html
index 68b259452b..bc2cfe655e 100644
--- a/blog/2020/03/02/finish-bicycle-book-chap3/index.html
+++ b/blog/2020/03/02/finish-bicycle-book-chap3/index.html
@@ -430,6 +430,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -819,7 +821,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/03/19/azure-search-analyze-plugin/index.html b/blog/2020/03/19/azure-search-analyze-plugin/index.html
index 3b2d2bbf1a..8392f7fbe0 100644
--- a/blog/2020/03/19/azure-search-analyze-plugin/index.html
+++ b/blog/2020/03/19/azure-search-analyze-plugin/index.html
@@ -527,6 +527,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -916,7 +918,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/03/23/start-reading-rust-the-book/index.html b/blog/2020/03/23/start-reading-rust-the-book/index.html
index fd0bdae0c6..74a57de172 100644
--- a/blog/2020/03/23/start-reading-rust-the-book/index.html
+++ b/blog/2020/03/23/start-reading-rust-the-book/index.html
@@ -527,6 +527,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -916,7 +918,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/03/25/vsc-es-analzye-plugin/index.html b/blog/2020/03/25/vsc-es-analzye-plugin/index.html
index 9f56ada34c..7e9581512c 100644
--- a/blog/2020/03/25/vsc-es-analzye-plugin/index.html
+++ b/blog/2020/03/25/vsc-es-analzye-plugin/index.html
@@ -480,6 +480,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -869,7 +871,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/03/26/chap4-rust-the-book/index.html b/blog/2020/03/26/chap4-rust-the-book/index.html
index 51dc8eaa8b..50e1365493 100644
--- a/blog/2020/03/26/chap4-rust-the-book/index.html
+++ b/blog/2020/03/26/chap4-rust-the-book/index.html
@@ -507,6 +507,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -896,7 +898,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/03/26/working-facility/index.html b/blog/2020/03/26/working-facility/index.html
index 86595f5d2a..0f10920235 100644
--- a/blog/2020/03/26/working-facility/index.html
+++ b/blog/2020/03/26/working-facility/index.html
@@ -640,6 +640,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1029,7 +1031,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/04/02/chap5-rust-the-book/index.html b/blog/2020/04/02/chap5-rust-the-book/index.html
index d9733d77d2..4cf88a5471 100644
--- a/blog/2020/04/02/chap5-rust-the-book/index.html
+++ b/blog/2020/04/02/chap5-rust-the-book/index.html
@@ -545,6 +545,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -934,7 +936,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/04/06/update-kuromoji-cli/index.html b/blog/2020/04/06/update-kuromoji-cli/index.html
index b532afbdc7..580d225590 100644
--- a/blog/2020/04/06/update-kuromoji-cli/index.html
+++ b/blog/2020/04/06/update-kuromoji-cli/index.html
@@ -525,6 +525,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -914,7 +916,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/04/07/chap6-rust-the-book/index.html b/blog/2020/04/07/chap6-rust-the-book/index.html
index 08127470d1..80baffe173 100644
--- a/blog/2020/04/07/chap6-rust-the-book/index.html
+++ b/blog/2020/04/07/chap6-rust-the-book/index.html
@@ -486,6 +486,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -875,7 +877,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/04/08/reboot-nlp10-with-rust/index.html b/blog/2020/04/08/reboot-nlp10-with-rust/index.html
index 16ac2b069b..18a5f586a2 100644
--- a/blog/2020/04/08/reboot-nlp10-with-rust/index.html
+++ b/blog/2020/04/08/reboot-nlp10-with-rust/index.html
@@ -453,6 +453,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -842,7 +844,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/04/09/reboot-nlp100-ch01-03to05/index.html b/blog/2020/04/09/reboot-nlp100-ch01-03to05/index.html
index bafb80ba37..05f6875e37 100644
--- a/blog/2020/04/09/reboot-nlp100-ch01-03to05/index.html
+++ b/blog/2020/04/09/reboot-nlp100-ch01-03to05/index.html
@@ -458,6 +458,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -847,7 +849,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/04/16/chap8-rust-the-book/index.html b/blog/2020/04/16/chap8-rust-the-book/index.html
index 2818275897..c650a56a37 100644
--- a/blog/2020/04/16/chap8-rust-the-book/index.html
+++ b/blog/2020/04/16/chap8-rust-the-book/index.html
@@ -561,6 +561,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -950,7 +952,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/04/22/custom-dictionary-after-7-4/index.html b/blog/2020/04/22/custom-dictionary-after-7-4/index.html
index 4efcee7276..3f0041ec44 100644
--- a/blog/2020/04/22/custom-dictionary-after-7-4/index.html
+++ b/blog/2020/04/22/custom-dictionary-after-7-4/index.html
@@ -566,6 +566,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -955,7 +957,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/04/27/note-updating-dictionary/index.html b/blog/2020/04/27/note-updating-dictionary/index.html
index 348697cac0..aff06fdfed 100644
--- a/blog/2020/04/27/note-updating-dictionary/index.html
+++ b/blog/2020/04/27/note-updating-dictionary/index.html
@@ -546,6 +546,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -935,7 +937,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/05/01/intro-workplace-search/index.html b/blog/2020/05/01/intro-workplace-search/index.html
index 69da72a171..f564a57cc2 100644
--- a/blog/2020/05/01/intro-workplace-search/index.html
+++ b/blog/2020/05/01/intro-workplace-search/index.html
@@ -448,6 +448,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -837,7 +839,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/05/07/install-workplace-search/index.html b/blog/2020/05/07/install-workplace-search/index.html
index ae28dee531..161262576c 100644
--- a/blog/2020/05/07/install-workplace-search/index.html
+++ b/blog/2020/05/07/install-workplace-search/index.html
@@ -634,6 +634,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1023,7 +1025,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/05/08/reboot-nlp100-finish-ch01/index.html b/blog/2020/05/08/reboot-nlp100-finish-ch01/index.html
index 88acf052f3..6a86a9c190 100644
--- a/blog/2020/05/08/reboot-nlp100-finish-ch01/index.html
+++ b/blog/2020/05/08/reboot-nlp100-finish-ch01/index.html
@@ -479,6 +479,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -868,7 +870,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/05/08/rebootnlp100-ch02-10to11/index.html b/blog/2020/05/08/rebootnlp100-ch02-10to11/index.html
index 43289f7490..e140250dbd 100644
--- a/blog/2020/05/08/rebootnlp100-ch02-10to11/index.html
+++ b/blog/2020/05/08/rebootnlp100-ch02-10to11/index.html
@@ -486,6 +486,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -875,7 +877,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/05/12/reboot-nlp100-ch02-12to19/index.html b/blog/2020/05/12/reboot-nlp100-ch02-12to19/index.html
index 7a9fb6e38e..c7bdc8f1d7 100644
--- a/blog/2020/05/12/reboot-nlp100-ch02-12to19/index.html
+++ b/blog/2020/05/12/reboot-nlp100-ch02-12to19/index.html
@@ -650,6 +650,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1039,7 +1041,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/05/14/chap9-rust-the-book/index.html b/blog/2020/05/14/chap9-rust-the-book/index.html
index ae02578389..924a1ef75e 100644
--- a/blog/2020/05/14/chap9-rust-the-book/index.html
+++ b/blog/2020/05/14/chap9-rust-the-book/index.html
@@ -456,6 +456,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -845,7 +847,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/05/15/elastic-stack-7_7/index.html b/blog/2020/05/15/elastic-stack-7_7/index.html
index cf6a95455e..052b50182d 100644
--- a/blog/2020/05/15/elastic-stack-7_7/index.html
+++ b/blog/2020/05/15/elastic-stack-7_7/index.html
@@ -604,6 +604,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -993,7 +995,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/05/22/watching-azure-cognirive-search-session-at-ms-build/index.html b/blog/2020/05/22/watching-azure-cognirive-search-session-at-ms-build/index.html
index b2952db5d7..b588b3be64 100644
--- a/blog/2020/05/22/watching-azure-cognirive-search-session-at-ms-build/index.html
+++ b/blog/2020/05/22/watching-azure-cognirive-search-session-at-ms-build/index.html
@@ -455,6 +455,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -844,7 +846,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/05/26/logging-azure-search-request/index.html b/blog/2020/05/26/logging-azure-search-request/index.html
index 0ab508159c..5df3504fce 100644
--- a/blog/2020/05/26/logging-azure-search-request/index.html
+++ b/blog/2020/05/26/logging-azure-search-request/index.html
@@ -765,6 +765,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1154,7 +1156,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/05/28/chap10-rust-the-book/index.html b/blog/2020/05/28/chap10-rust-the-book/index.html
index e138b4a02e..9a1d2b05fe 100644
--- a/blog/2020/05/28/chap10-rust-the-book/index.html
+++ b/blog/2020/05/28/chap10-rust-the-book/index.html
@@ -512,6 +512,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -901,7 +903,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/06/04/chap13-rust-the-book/index.html b/blog/2020/06/04/chap13-rust-the-book/index.html
index aeb33b4f7a..374adb4a91 100644
--- a/blog/2020/06/04/chap13-rust-the-book/index.html
+++ b/blog/2020/06/04/chap13-rust-the-book/index.html
@@ -495,6 +495,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -884,7 +886,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/06/09/difference-analyzers-in-azure-search/index.html b/blog/2020/06/09/difference-analyzers-in-azure-search/index.html
index ce02ef937f..fadae7eb53 100644
--- a/blog/2020/06/09/difference-analyzers-in-azure-search/index.html
+++ b/blog/2020/06/09/difference-analyzers-in-azure-search/index.html
@@ -580,6 +580,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -969,7 +971,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/06/23/how-to-use-luceneutil/index.html b/blog/2020/06/23/how-to-use-luceneutil/index.html
index 8615df329c..0a222546f8 100644
--- a/blog/2020/06/23/how-to-use-luceneutil/index.html
+++ b/blog/2020/06/23/how-to-use-luceneutil/index.html
@@ -491,6 +491,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -880,7 +882,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/06/25/analyzer-perf-test-with-luceneutil/index.html b/blog/2020/06/25/analyzer-perf-test-with-luceneutil/index.html
index 41c9e9944a..ce923cd07a 100644
--- a/blog/2020/06/25/analyzer-perf-test-with-luceneutil/index.html
+++ b/blog/2020/06/25/analyzer-perf-test-with-luceneutil/index.html
@@ -513,6 +513,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -902,7 +904,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/07/06/attend-berlin-buzzwords/index.html b/blog/2020/07/06/attend-berlin-buzzwords/index.html
index 6c9929960a..d67bf5a6ac 100644
--- a/blog/2020/07/06/attend-berlin-buzzwords/index.html
+++ b/blog/2020/07/06/attend-berlin-buzzwords/index.html
@@ -561,6 +561,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -950,7 +952,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/07/09/hap15-rust-the-book/index.html b/blog/2020/07/09/hap15-rust-the-book/index.html
index 8841324da4..e98c0e2219 100644
--- a/blog/2020/07/09/hap15-rust-the-book/index.html
+++ b/blog/2020/07/09/hap15-rust-the-book/index.html
@@ -550,6 +550,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -939,7 +941,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/07/27/improve-search-no1/index.html b/blog/2020/07/27/improve-search-no1/index.html
index ac01ffdd62..dce4ac4c56 100644
--- a/blog/2020/07/27/improve-search-no1/index.html
+++ b/blog/2020/07/27/improve-search-no1/index.html
@@ -541,6 +541,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -930,7 +932,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/07/28/improve-search-no2/index.html b/blog/2020/07/28/improve-search-no2/index.html
index 006d27bde6..0002c3474c 100644
--- a/blog/2020/07/28/improve-search-no2/index.html
+++ b/blog/2020/07/28/improve-search-no2/index.html
@@ -573,6 +573,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -962,7 +964,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/08/18/azure-search-with-terraform/index.html b/blog/2020/08/18/azure-search-with-terraform/index.html
index 64b9d01348..a0dfaad6d7 100644
--- a/blog/2020/08/18/azure-search-with-terraform/index.html
+++ b/blog/2020/08/18/azure-search-with-terraform/index.html
@@ -504,6 +504,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -893,7 +895,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/09/04/reboot-nlp100-ch03/index.html b/blog/2020/09/04/reboot-nlp100-ch03/index.html
index ccd8a0efda..3a0a0e62b9 100644
--- a/blog/2020/09/04/reboot-nlp100-ch03/index.html
+++ b/blog/2020/09/04/reboot-nlp100-ch03/index.html
@@ -552,6 +552,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -941,7 +943,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/09/07/intro-metered-rs/index.html b/blog/2020/09/07/intro-metered-rs/index.html
index 46614e0caa..442c088f08 100644
--- a/blog/2020/09/07/intro-metered-rs/index.html
+++ b/blog/2020/09/07/intro-metered-rs/index.html
@@ -673,6 +673,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1062,7 +1064,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/09/07/reboot-nlp100-ch04/index.html b/blog/2020/09/07/reboot-nlp100-ch04/index.html
index e8da914ced..7431ba8d73 100644
--- a/blog/2020/09/07/reboot-nlp100-ch04/index.html
+++ b/blog/2020/09/07/reboot-nlp100-ch04/index.html
@@ -590,6 +590,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -979,7 +981,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/09/08/update-working-facility/index.html b/blog/2020/09/08/update-working-facility/index.html
index 9e17924da1..673395fe07 100644
--- a/blog/2020/09/08/update-working-facility/index.html
+++ b/blog/2020/09/08/update-working-facility/index.html
@@ -716,6 +716,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1105,7 +1107,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/09/15/improve-search-no3/index.html b/blog/2020/09/15/improve-search-no3/index.html
index 973aededfe..e57a956760 100644
--- a/blog/2020/09/15/improve-search-no3/index.html
+++ b/blog/2020/09/15/improve-search-no3/index.html
@@ -506,6 +506,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -895,7 +897,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/10/05/switch-fst-2-da/index.html b/blog/2020/10/05/switch-fst-2-da/index.html
index d5f44391d1..57f122d6eb 100644
--- a/blog/2020/10/05/switch-fst-2-da/index.html
+++ b/blog/2020/10/05/switch-fst-2-da/index.html
@@ -574,6 +574,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -963,7 +965,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/10/11/build-dozen0/index.html b/blog/2020/10/11/build-dozen0/index.html
index 16fb6cd366..b9758e6fed 100644
--- a/blog/2020/10/11/build-dozen0/index.html
+++ b/blog/2020/10/11/build-dozen0/index.html
@@ -631,6 +631,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1020,7 +1022,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/10/15/restart-windows/index.html b/blog/2020/10/15/restart-windows/index.html
index 16a3cae3e4..46542d8cb8 100644
--- a/blog/2020/10/15/restart-windows/index.html
+++ b/blog/2020/10/15/restart-windows/index.html
@@ -633,6 +633,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1022,7 +1024,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/10/18/restart-windows-no1/index.html b/blog/2020/10/18/restart-windows-no1/index.html
index c049bc1bfa..30a9e5a686 100644
--- a/blog/2020/10/18/restart-windows-no1/index.html
+++ b/blog/2020/10/18/restart-windows-no1/index.html
@@ -579,6 +579,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -968,7 +970,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/11/05/build-corne-light-v2/index.html b/blog/2020/11/05/build-corne-light-v2/index.html
index 3f8e5fc355..d70eebe3ba 100644
--- a/blog/2020/11/05/build-corne-light-v2/index.html
+++ b/blog/2020/11/05/build-corne-light-v2/index.html
@@ -682,6 +682,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1071,7 +1073,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/12/03/build_corne_choc/index.html b/blog/2020/12/03/build_corne_choc/index.html
index 4f850d381b..95483c4e7b 100644
--- a/blog/2020/12/03/build_corne_choc/index.html
+++ b/blog/2020/12/03/build_corne_choc/index.html
@@ -684,6 +684,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1073,7 +1075,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/12/17/index_template_v2/index.html b/blog/2020/12/17/index_template_v2/index.html
index 9feeeb11cb..3fd21f6a57 100644
--- a/blog/2020/12/17/index_template_v2/index.html
+++ b/blog/2020/12/17/index_template_v2/index.html
@@ -923,6 +923,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1312,7 +1314,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/12/31/diy-pc/index.html b/blog/2020/12/31/diy-pc/index.html
index 2027657215..49aed0128c 100644
--- a/blog/2020/12/31/diy-pc/index.html
+++ b/blog/2020/12/31/diy-pc/index.html
@@ -679,6 +679,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1068,7 +1070,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2020/12/31/looking-back-2020/index.html b/blog/2020/12/31/looking-back-2020/index.html
index 92c9b58ec1..0b9eb1212e 100644
--- a/blog/2020/12/31/looking-back-2020/index.html
+++ b/blog/2020/12/31/looking-back-2020/index.html
@@ -544,6 +544,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -933,7 +935,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2021/01/11/apply-ble-and-lpme-to-corne/index.html b/blog/2021/01/11/apply-ble-and-lpme-to-corne/index.html
index a618028cdb..ed3762b809 100644
--- a/blog/2021/01/11/apply-ble-and-lpme-to-corne/index.html
+++ b/blog/2021/01/11/apply-ble-and-lpme-to-corne/index.html
@@ -611,6 +611,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1000,7 +1002,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2021/02/01/apply-ble-to-sofle/index.html b/blog/2021/02/01/apply-ble-to-sofle/index.html
index 6747280897..07ed8e89f5 100644
--- a/blog/2021/02/01/apply-ble-to-sofle/index.html
+++ b/blog/2021/02/01/apply-ble-to-sofle/index.html
@@ -633,6 +633,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1022,7 +1024,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2021/02/04/reading-elements-of-computing-systems/index.html b/blog/2021/02/04/reading-elements-of-computing-systems/index.html
index 4c72fe4c08..6f6521e73c 100644
--- a/blog/2021/02/04/reading-elements-of-computing-systems/index.html
+++ b/blog/2021/02/04/reading-elements-of-computing-systems/index.html
@@ -414,6 +414,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -803,7 +805,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2021/02/05/autocomplete-and-suggest-on-azure-search/index.html b/blog/2021/02/05/autocomplete-and-suggest-on-azure-search/index.html
index a2127885c7..415d8fa78c 100644
--- a/blog/2021/02/05/autocomplete-and-suggest-on-azure-search/index.html
+++ b/blog/2021/02/05/autocomplete-and-suggest-on-azure-search/index.html
@@ -799,6 +799,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1188,7 +1190,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2021/02/25/update-working-facility/index.html b/blog/2021/02/25/update-working-facility/index.html
index 73e7faa6fa..7a2dba086e 100644
--- a/blog/2021/02/25/update-working-facility/index.html
+++ b/blog/2021/02/25/update-working-facility/index.html
@@ -658,6 +658,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1047,7 +1049,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2021/03/03/phrase-query-in-japanese/index.html b/blog/2021/03/03/phrase-query-in-japanese/index.html
index 30dd59a391..6e70ef44a6 100644
--- a/blog/2021/03/03/phrase-query-in-japanese/index.html
+++ b/blog/2021/03/03/phrase-query-in-japanese/index.html
@@ -600,6 +600,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -989,7 +991,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2021/03/31/search-tech-jp-slack/index.html b/blog/2021/03/31/search-tech-jp-slack/index.html
index 732d91ab01..cda0abd544 100644
--- a/blog/2021/03/31/search-tech-jp-slack/index.html
+++ b/blog/2021/03/31/search-tech-jp-slack/index.html
@@ -427,6 +427,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -816,7 +818,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2021/04/05/intro-marp/index.html b/blog/2021/04/05/intro-marp/index.html
index 4be4601105..47ad1ef552 100644
--- a/blog/2021/04/05/intro-marp/index.html
+++ b/blog/2021/04/05/intro-marp/index.html
@@ -523,6 +523,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -912,7 +914,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2021/04/30/build-lunakey-mini-ble/index.html b/blog/2021/04/30/build-lunakey-mini-ble/index.html
index 721a89f16c..95694d4850 100644
--- a/blog/2021/04/30/build-lunakey-mini-ble/index.html
+++ b/blog/2021/04/30/build-lunakey-mini-ble/index.html
@@ -567,6 +567,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -956,7 +958,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2021/07/01/semantic-search-in-azure-cognitive-search/index.html b/blog/2021/07/01/semantic-search-in-azure-cognitive-search/index.html
index a17302f69f..cd82550c31 100644
--- a/blog/2021/07/01/semantic-search-in-azure-cognitive-search/index.html
+++ b/blog/2021/07/01/semantic-search-in-azure-cognitive-search/index.html
@@ -1205,6 +1205,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1594,7 +1596,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2021/07/09/berlin-buzzwords-2021-1/index.html b/blog/2021/07/09/berlin-buzzwords-2021-1/index.html
index 3b99aef22f..70b9a894a5 100644
--- a/blog/2021/07/09/berlin-buzzwords-2021-1/index.html
+++ b/blog/2021/07/09/berlin-buzzwords-2021-1/index.html
@@ -502,6 +502,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -891,7 +893,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2021/07/13/attend-mices-2021/index.html b/blog/2021/07/13/attend-mices-2021/index.html
index 30ad11d4fb..6dfb73ecb8 100644
--- a/blog/2021/07/13/attend-mices-2021/index.html
+++ b/blog/2021/07/13/attend-mices-2021/index.html
@@ -486,6 +486,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -875,7 +877,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2021/11/10/reading-ms-biomedical-search-paper/index.html b/blog/2021/11/10/reading-ms-biomedical-search-paper/index.html
index e84fbe1994..a590882325 100644
--- a/blog/2021/11/10/reading-ms-biomedical-search-paper/index.html
+++ b/blog/2021/11/10/reading-ms-biomedical-search-paper/index.html
@@ -512,6 +512,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -901,7 +903,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2021/12/08/controller-rack/index.html b/blog/2021/12/08/controller-rack/index.html
index 663175ad34..d375429b9f 100644
--- a/blog/2021/12/08/controller-rack/index.html
+++ b/blog/2021/12/08/controller-rack/index.html
@@ -658,6 +658,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1047,7 +1049,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2021/12/22/azure-search-schema-json2csv/index.html b/blog/2021/12/22/azure-search-schema-json2csv/index.html
index 8b142f82f2..04176f3af5 100644
--- a/blog/2021/12/22/azure-search-schema-json2csv/index.html
+++ b/blog/2021/12/22/azure-search-schema-json2csv/index.html
@@ -446,6 +446,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -835,7 +837,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2021/12/29/best-buy-2021/index.html b/blog/2021/12/29/best-buy-2021/index.html
index 074e50cfef..cc775241ce 100644
--- a/blog/2021/12/29/best-buy-2021/index.html
+++ b/blog/2021/12/29/best-buy-2021/index.html
@@ -610,6 +610,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -999,7 +1001,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2021/12/31/looking-back-2021/index.html b/blog/2021/12/31/looking-back-2021/index.html
index 3ef5c8a77d..20f8008ab5 100644
--- a/blog/2021/12/31/looking-back-2021/index.html
+++ b/blog/2021/12/31/looking-back-2021/index.html
@@ -502,6 +502,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -891,7 +893,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2022/01/12/reading-xmc-for-semantic-search-in-prod/index.html b/blog/2022/01/12/reading-xmc-for-semantic-search-in-prod/index.html
index 69ccbfbf19..4a44484e1b 100644
--- a/blog/2022/01/12/reading-xmc-for-semantic-search-in-prod/index.html
+++ b/blog/2022/01/12/reading-xmc-for-semantic-search-in-prod/index.html
@@ -533,6 +533,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -922,7 +924,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2022/05/18/index-alias-in-azure-cognitive-search/index.html b/blog/2022/05/18/index-alias-in-azure-cognitive-search/index.html
index 16d92802c5..368e3cb31f 100644
--- a/blog/2022/05/18/index-alias-in-azure-cognitive-search/index.html
+++ b/blog/2022/05/18/index-alias-in-azure-cognitive-search/index.html
@@ -503,6 +503,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -892,7 +894,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2022/06/13/new-elasticsearch-java-client/index.html b/blog/2022/06/13/new-elasticsearch-java-client/index.html
index a2b677f17f..5b2023dfff 100644
--- a/blog/2022/06/13/new-elasticsearch-java-client/index.html
+++ b/blog/2022/06/13/new-elasticsearch-java-client/index.html
@@ -511,6 +511,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -900,7 +902,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2022/06/15/ttend-berlin-buzzwords-online/index.html b/blog/2022/06/15/ttend-berlin-buzzwords-online/index.html
index c0d8ae0f40..2388b0ec37 100644
--- a/blog/2022/06/15/ttend-berlin-buzzwords-online/index.html
+++ b/blog/2022/06/15/ttend-berlin-buzzwords-online/index.html
@@ -530,6 +530,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -919,7 +921,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2022/07/20/intro-querqy/index.html b/blog/2022/07/20/intro-querqy/index.html
index 40a9bf029a..c6123f2f86 100644
--- a/blog/2022/07/20/intro-querqy/index.html
+++ b/blog/2022/07/20/intro-querqy/index.html
@@ -550,6 +550,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -939,7 +941,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2022/07/20/querqy-architecture/index.html b/blog/2022/07/20/querqy-architecture/index.html
index 81718ad85d..ef82accbc1 100644
--- a/blog/2022/07/20/querqy-architecture/index.html
+++ b/blog/2022/07/20/querqy-architecture/index.html
@@ -461,6 +461,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -850,7 +852,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2022/08/05/upgrade-hugo-accidentally/index.html b/blog/2022/08/05/upgrade-hugo-accidentally/index.html
index 9b66b395e1..c504542710 100644
--- a/blog/2022/08/05/upgrade-hugo-accidentally/index.html
+++ b/blog/2022/08/05/upgrade-hugo-accidentally/index.html
@@ -489,6 +489,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -878,7 +880,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2022/08/09/japanese-auto-completion/index.html b/blog/2022/08/09/japanese-auto-completion/index.html
index c2e97cf36d..5b5289d5b1 100644
--- a/blog/2022/08/09/japanese-auto-completion/index.html
+++ b/blog/2022/08/09/japanese-auto-completion/index.html
@@ -863,6 +863,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1252,7 +1254,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2022/08/10/jp-auto-completion-2/index.html b/blog/2022/08/10/jp-auto-completion-2/index.html
index 70070f574a..e498c7ee71 100644
--- a/blog/2022/08/10/jp-auto-completion-2/index.html
+++ b/blog/2022/08/10/jp-auto-completion-2/index.html
@@ -1006,6 +1006,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1395,7 +1397,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2022/12/09/open-search-serverless/index.html b/blog/2022/12/09/open-search-serverless/index.html
index eec770df97..c18d305a51 100644
--- a/blog/2022/12/09/open-search-serverless/index.html
+++ b/blog/2022/12/09/open-search-serverless/index.html
@@ -506,6 +506,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -895,7 +897,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2022/12/15/music-server-on-mac-mini/index.html b/blog/2022/12/15/music-server-on-mac-mini/index.html
index 164e2f8457..f9454cc918 100644
--- a/blog/2022/12/15/music-server-on-mac-mini/index.html
+++ b/blog/2022/12/15/music-server-on-mac-mini/index.html
@@ -555,6 +555,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -944,7 +946,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2022/12/31/review-2022/index.html b/blog/2022/12/31/review-2022/index.html
index a04dcb1b8e..c016a7f064 100644
--- a/blog/2022/12/31/review-2022/index.html
+++ b/blog/2022/12/31/review-2022/index.html
@@ -491,6 +491,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -880,7 +882,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2023/06/21/attend-berlin-buzzwords-2023/index.html b/blog/2023/06/21/attend-berlin-buzzwords-2023/index.html
index 8db02f11cb..cb6b0a9549 100644
--- a/blog/2023/06/21/attend-berlin-buzzwords-2023/index.html
+++ b/blog/2023/06/21/attend-berlin-buzzwords-2023/index.html
@@ -553,6 +553,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -942,7 +944,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2023/07/10/pre-commit-and-python/index.html b/blog/2023/07/10/pre-commit-and-python/index.html
index 9a9affbd93..6a90fd5bcc 100644
--- a/blog/2023/07/10/pre-commit-and-python/index.html
+++ b/blog/2023/07/10/pre-commit-and-python/index.html
@@ -518,6 +518,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -907,7 +909,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2023/07/13/introduce-vs-code-and-dev-container/index.html b/blog/2023/07/13/introduce-vs-code-and-dev-container/index.html
index 5248faf39a..558ab4e2ba 100644
--- a/blog/2023/07/13/introduce-vs-code-and-dev-container/index.html
+++ b/blog/2023/07/13/introduce-vs-code-and-dev-container/index.html
@@ -528,6 +528,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -917,7 +919,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2023/07/21/multi-containers-with-dev-container/index.html b/blog/2023/07/21/multi-containers-with-dev-container/index.html
index fcefc4681c..1304ed32b9 100644
--- a/blog/2023/07/21/multi-containers-with-dev-container/index.html
+++ b/blog/2023/07/21/multi-containers-with-dev-container/index.html
@@ -538,6 +538,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -927,7 +929,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2023/07/24/introduce-dev-container-to-hugo-env/index.html b/blog/2023/07/24/introduce-dev-container-to-hugo-env/index.html
index 6d7eb244c8..62741d8cfc 100644
--- a/blog/2023/07/24/introduce-dev-container-to-hugo-env/index.html
+++ b/blog/2023/07/24/introduce-dev-container-to-hugo-env/index.html
@@ -498,6 +498,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -887,7 +889,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2023/07/24/move-distribution-to-another-disk/index.html b/blog/2023/07/24/move-distribution-to-another-disk/index.html
index 7a5af34f35..89e98806ca 100644
--- a/blog/2023/07/24/move-distribution-to-another-disk/index.html
+++ b/blog/2023/07/24/move-distribution-to-another-disk/index.html
@@ -499,6 +499,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -888,7 +890,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2023/07/27/container-name-in-devcontainer/index.html b/blog/2023/07/27/container-name-in-devcontainer/index.html
index 43edf69835..d2e067f5bc 100644
--- a/blog/2023/07/27/container-name-in-devcontainer/index.html
+++ b/blog/2023/07/27/container-name-in-devcontainer/index.html
@@ -422,6 +422,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -811,7 +813,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2023/08/23/search-ui-and-searchkit/index.html b/blog/2023/08/23/search-ui-and-searchkit/index.html
index 8520d0ca6f..c2ef8f486c 100644
--- a/blog/2023/08/23/search-ui-and-searchkit/index.html
+++ b/blog/2023/08/23/search-ui-and-searchkit/index.html
@@ -513,6 +513,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -902,7 +904,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2023/09/25/read-search-raking-guide/index.html b/blog/2023/09/25/read-search-raking-guide/index.html
index 5405e61413..4a6c2fff75 100644
--- a/blog/2023/09/25/read-search-raking-guide/index.html
+++ b/blog/2023/09/25/read-search-raking-guide/index.html
@@ -490,6 +490,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -879,7 +881,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2023/12/08/smarthome-bot/index.html b/blog/2023/12/08/smarthome-bot/index.html
index ba2ad56176..2e24ff8c16 100644
--- a/blog/2023/12/08/smarthome-bot/index.html
+++ b/blog/2023/12/08/smarthome-bot/index.html
@@ -468,12 +468,12 @@ <h3>Related by prelims-cli</h3>
     
     
     
+    <li><a href="https://blog.johtani.info/blog/2024/01/25/kagome-bot-as-a-user-service/">kagome-botのユーザーサービス化</a></li>
+    
     <li><a href="https://blog.johtani.info/blog/2023/12/31/review-2023/">今年の振り返りと来年の抱負（2023）</a></li>
     
     <li><a href="https://blog.johtani.info/blog/2022/12/15/music-server-on-mac-mini/">仕事中のBGM環境</a></li>
     
-    <li><a href="https://blog.johtani.info/blog/2021/02/25/update-working-facility/">自宅の作業環境(2021/02)</a></li>
-    
   </ul>
 </div>
 
@@ -583,6 +583,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -972,7 +974,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2023/12/15/introduce-orama-to-blog/index.html b/blog/2023/12/15/introduce-orama-to-blog/index.html
index 3551429610..d935e993fe 100644
--- a/blog/2023/12/15/introduce-orama-to-blog/index.html
+++ b/blog/2023/12/15/introduce-orama-to-blog/index.html
@@ -631,6 +631,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -1020,7 +1022,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2023/12/31/review-2023/index.html b/blog/2023/12/31/review-2023/index.html
index a8037e569b..8351a1fc9c 100644
--- a/blog/2023/12/31/review-2023/index.html
+++ b/blog/2023/12/31/review-2023/index.html
@@ -315,6 +315,11 @@ <h2 id="来年の抱負">来年の抱負</h2>
                     </li>
                     
                     
+                    <li class="next">
+                        <a href="https://blog.johtani.info/blog/2024/01/25/kagome-bot-as-a-user-service/" data-toggle="tooltip" data-placement="top" title="kagome-botのユーザーサービス化">Next
+                            Post &rarr;</a>
+                    </li>
+                    
                 </ul>
 
                 
@@ -486,6 +491,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -875,7 +882,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/blog/2024/01/25/kagome-bot-as-a-user-service/index.html b/blog/2024/01/25/kagome-bot-as-a-user-service/index.html
new file mode 100644
index 0000000000..3db2d2dba8
--- /dev/null
+++ b/blog/2024/01/25/kagome-bot-as-a-user-service/index.html
@@ -0,0 +1,911 @@
+<!DOCTYPE html>
+<html lang="ja">
+<head>
+    <meta charset="utf-8">
+    <meta http-equiv="X-UA-Compatible" content="IE=edge">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+
+    
+    <meta property="og:site_name" content="@johtaniの日記 3rd">
+    <meta property="og:type" content="article">
+
+    
+    <meta property="og:image" content="https://blog.johtani.info/images/header3.jpg">
+    <meta property="twitter:image" content="https://blog.johtani.info/images/header3.jpg" />
+    
+
+    
+    <meta name="title" content="kagome-botのユーザーサービス化" />
+    <meta property="og:title" content="kagome-botのユーザーサービス化" />
+    <meta property="twitter:title" content="kagome-botのユーザーサービス化" />
+    
+
+    
+    <meta name="description" content="johtaniの日記です。技術とか、他愛のないことを書き連ねていくブログです。 | johtani&#39;s blog site that includes topics, e.g. technical, life, hobby, etc.">
+    <meta property="og:description" content="johtaniの日記です。技術とか、他愛のないことを書き連ねていくブログです。 | johtani&#39;s blog site that includes topics, e.g. technical, life, hobby, etc." />
+    <meta property="twitter:description" content="johtaniの日記です。技術とか、他愛のないことを書き連ねていくブログです。 | johtani&#39;s blog site that includes topics, e.g. technical, life, hobby, etc." />
+    
+
+    
+    <meta property="twitter:card" content="summary" />
+    
+    
+
+    <meta name="keyword"  content="johtani elasticsearch kibana search 検索 ">
+    <link rel="shortcut icon" href="/img/favicon.ico">
+
+    <title>kagome-botのユーザーサービス化 | @johtaniの日記 3rd | @johtani&#39;s blog 3rd edition </title>
+
+    <link rel="canonical" href="/blog/2024/01/25/kagome-bot-as-a-user-service/">
+
+    
+    
+    
+    <link rel="stylesheet" href="/css/bootstrap.min.css">
+
+    
+    <link rel="stylesheet" href="/css/hugo-theme-cleanwhite.min.css">
+
+    
+    <link rel="stylesheet" href="/css/zanshang.css">
+
+    
+    <link rel="stylesheet" href="/css/font-awesome.all.min.css">
+
+    
+    <link rel="stylesheet" href="https://blog.johtani.info/css/custom-font.css"><link rel="stylesheet" href="https://blog.johtani.info/css/amazon.css">
+
+    
+    <script src="/js/jquery.min.js"></script>
+
+    
+    <script src="/js/bootstrap.min.js"></script>
+
+    
+    <script src="/js/hux-blog.min.js"></script>
+
+    
+    <script src="/js/lazysizes.min.js"></script>
+
+    
+    
+
+</head>
+
+
+
+<script async src="https://www.googletagmanager.com/gtag/js?id=G-ZCZYDMJX3V"></script>
+<script>
+var doNotTrack = false;
+if (!doNotTrack) {
+	window.dataLayer = window.dataLayer || [];
+	function gtag(){dataLayer.push(arguments);}
+	gtag('js', new Date());
+	gtag('config', 'G-ZCZYDMJX3V', { 'anonymize_ip': false });
+}
+</script>
+
+
+
+
+
+
+<nav class="navbar navbar-default navbar-custom navbar-fixed-top">
+
+    <div class="container-fluid">
+        
+        <div class="navbar-header page-scroll">
+            <button type="button" class="navbar-toggle">
+                <span class="sr-only">Toggle navigation</span>
+                <span class="icon-bar"></span>
+                <span class="icon-bar"></span>
+                <span class="icon-bar"></span>
+            </button>
+            <a class="navbar-brand" href="/">@johtaniの日記 3rd</a>
+        </div>
+
+        
+        
+        <div id="huxblog_navbar">
+            <div class="navbar-collapse">
+                <ul class="nav navbar-nav navbar-right">
+                    <li>
+                        <a href="/">All Posts</a>
+                    </li>
+                    
+                        
+                    
+		            
+                    <li><a href="/top/about//">ABOUT</a></li>
+                    
+                    <li><a href="/orama/">Orama Search</a></li>
+                    
+                    
+		            <li>
+                        <a href="/search"><i class="fa fa-search"></i></a>
+		           </li>
+                </ul>
+            </div>
+        </div>
+        
+    </div>
+    
+</nav>
+<script>
+    
+    
+    
+    var $body   = document.body;
+    var $toggle = document.querySelector('.navbar-toggle');
+    var $navbar = document.querySelector('#huxblog_navbar');
+    var $collapse = document.querySelector('.navbar-collapse');
+
+    $toggle.addEventListener('click', handleMagic)
+    function handleMagic(e){
+        if ($navbar.className.indexOf('in') > 0) {
+        
+            $navbar.className = " ";
+            
+            setTimeout(function(){
+                
+                if($navbar.className.indexOf('in') < 0) {
+                    $collapse.style.height = "0px"
+                }
+            },400)
+        }else{
+        
+            $collapse.style.height = "auto"
+            $navbar.className += " in";
+        }
+    }
+</script>
+
+
+
+
+<style type="text/css">
+    header.intro-header {
+        background-image: url('/images/header3.jpg')
+    }
+</style>
+<header class="intro-header">
+    <div class="container">
+        <div class="row">
+            <div class="col-lg-8 col-lg-offset-2 col-md-10 col-md-offset-1">
+                <div class="post-heading">
+                    <div class="tags">
+                        
+                        <a class="tag" href="/tags/go" title="go">
+                            go
+                        </a>
+                        
+                    </div>
+                    <h1>kagome-botのユーザーサービス化</h1>
+                    <h2 class="subheading"></h2>
+                    <span class="meta">
+                        Posted by 
+                        
+                            johtani
+                         
+                        on 
+                        Thursday, January 25, 2024
+                        
+                        
+                        
+                    </span>
+                </div>
+            </div>
+        </div>
+    </div>
+</header>
+
+
+
+
+<article>
+    <div class="container">
+        <div class="row">
+
+            
+            <div class="
+                col-lg-8 col-lg-offset-2
+                col-md-10 col-md-offset-1
+                post-container">
+
+                
+                <header>
+                    <h2>目次</h2>
+                </header>
+                <nav id="TableOfContents">
+  <ul>
+    <li><a href="#kagome-bot">kagome-bot</a></li>
+    <li><a href="#systemdでユーザーのサービスとして登録">systemdでユーザーのサービスとして登録</a></li>
+    <li><a href="#参考ブログ">参考ブログ</a></li>
+  </ul>
+</nav>
+                
+                <p>日常でよく、形態素解析したくなることがありますよね？
+そして、Slackも日常的に立ち上がってますよね？
+ということは、Slackのボットとして常駐してもらえばできるのでは？</p>
+<h2 id="kagome-bot">kagome-bot</h2>
+<p>知り合いが<a href="https://github.com/ikawaha/kagome">kagome</a>という形態素解析ライブラリを開発しています。
+その知り合いが、ボットにもしてくれています（複数辞書対応してみたかったので、PR作って取り込んでもらいました）。</p>
+<ul>
+<li><a href="https://github.com/ikawaha/kagome-bot">https://github.com/ikawaha/kagome-bot</a></li>
+</ul>
+<p>ただ、デプロイはしてなかったので、我が家にあるUbuntuのサーバーにデプロイして動かすことにしました。
+ボットについては、上記のリポジトリを見てもらえればいいかなと。</p>
+<p>とりあえず動けばいいや、ということで、適当なshell scriptに<code>nohup</code>で起動していたのですが、Ubuntuの更新後の再起動で毎回ログインしてスクリプトの実行はめんどくさいな？ということでググって調べてみました。</p>
+<h2 id="systemdでユーザーのサービスとして登録">systemdでユーザーのサービスとして登録</h2>
+<p>参考ブログにある手順ほぼそのままでした。知見ありがたいです。</p>
+<p>サービスの登録自体は、指定のディレクトリにファイルを作るのではなく、systemdコマンドをしようしました。</p>
+<pre tabindex="0"><code>$ systemctl --user --force --full edit kagome
+</code></pre><p>これで、参考ブログにあるように<code>kagome.service</code>というファイルが<code>~/.config/systemd/user/</code>ディレクトリに作られます。
+ファイルの内容などはほぼ参考ブログにある通りです。こんなかんじ。</p>
+<pre tabindex="0"><code>[Unit]
+Description=kagome bot
+
+[Service]
+ExecStart=/home/johtani/kagome-bot/start_kagomebot_service.sh
+ExecStop=/bin/kill ${MAINPID}
+Restart=always
+
+[Install]
+WantedBy=default.target
+</code></pre><p><code>start_kagomebot_service.sh</code>の中で、kagome-botコマンドを実行しますが、こちらは絶対パスで記述しておきました。
+サービス起動時のパスは<code>~/</code>のようなのですが、念のために。</p>
+<p>あとは、次の手順でサービスを登録して開始します。</p>
+<pre tabindex="0"><code>$ systemctl --user enable kagome
+$ systemctl --user start kagome
+</code></pre><p>ログを見るのは<code>journalctl</code>コマンドです。</p>
+<pre tabindex="0"><code>$ journalctl --user -u kagome
+</code></pre><p>あとは、以下のコマンドを実行しないと、マシン再起動後にログインするまでサービスが起動しないので忘れないようにしましょう。
+（忘れてログインしてみて起動してるじゃん？というコントみたいなことをしてしまいました）。</p>
+<pre tabindex="0"><code>$ sudo loginctl enable-linger username
+</code></pre><p>参考ブログ本当にありがたいですね。
+備忘録のついでにブログにしておきます。</p>
+<h2 id="参考ブログ">参考ブログ</h2>
+<ul>
+<li><a href="https://pyopyopyo.hatenablog.com/entry/2021/04/30/233755">ユーザー権限で systemd のサービスを稼働させる方法 - pyopyopyo - Linuxとかプログラミングの覚え書き -</a></li>
+</ul>
+
+
+                
+
+                <hr>
+                <ul class="pager">
+                    
+                    <li class="previous">
+                        <a href="https://blog.johtani.info/blog/2023/12/31/review-2023/" data-toggle="tooltip" data-placement="top" title="今年の振り返りと来年の抱負（2023）">&larr;
+                            Previous Post</a>
+                    </li>
+                    
+                    
+                </ul>
+
+                
+
+
+<div id="disqus-comment"></div>
+<div id="disqus_thread"></div>
+<script>
+    window.disqus_config = function () {
+    
+    
+    
+    };
+    (function() {
+        if (["localhost", "127.0.0.1"].indexOf(window.location.hostname) != -1) {
+            document.getElementById('disqus_thread').innerHTML = 'Disqus comments not available by default when the website is previewed locally.';
+            return;
+        }
+        var d = document, s = d.createElement('script'); s.async = true;
+        s.src = '//' + "johtaniblog2nd" + '.disqus.com/embed.js';
+        s.setAttribute('data-timestamp', +new Date());
+        (d.head || d.body).appendChild(s);
+    })();
+</script>
+<noscript>Please enable JavaScript to view the <a href="https://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript>
+<a href="https://disqus.com" class="dsq-brlink">comments powered by <span class="logo-disqus">Disqus</span></a>
+
+
+
+                <hr/>
+                
+
+<h3>See Also by Hugo</h3>
+<ul>
+ 
+ <li><a href="/blog/2020/01/23/convert-md-from-octopress-to-hugo/">ブログ移行日記(その2) - Markdownファイルの変換</a></li>
+ 
+</ul>
+
+                <hr/>
+                
+<div class="article-widget content-widget-hr">
+  <h3>Related by prelims-cli</h3>
+  <ul>
+    
+    
+    
+    
+    <li><a href="https://blog.johtani.info/blog/2023/12/31/review-2023/">今年の振り返りと来年の抱負（2023）</a></li>
+    
+    <li><a href="https://blog.johtani.info/blog/2023/12/08/smarthome-bot/">GoでSlackのボットを作った話</a></li>
+    
+    <li><a href="https://blog.johtani.info/blog/2023/07/24/move-distribution-to-another-disk/">WSL2のディストリビューションの環境移行</a></li>
+    
+  </ul>
+</div>
+
+            </div>
+            
+            <div class="
+                col-lg-8 col-lg-offset-2
+                col-md-10 col-md-offset-1
+                sidebar-container">
+
+                
+                
+                <section>
+                    <hr class="hidden-sm hidden-xs">
+                    <h5><a href="/tags/">FEATURED TAGS</a></h5>
+                    <div class="tags">
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/aws" title="aws">
+                            aws
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/azure-search" title="azure-search">
+                            azure-search
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/berlin-buzzwords" title="berlin-buzzwords">
+                            berlin-buzzwords
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/cloudera" title="cloudera">
+                            cloudera
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/cloudera-search" title="cloudera-search">
+                            cloudera-search
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/conference" title="conference">
+                            conference
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/curator" title="curator">
+                            curator
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/dev-container" title="dev-container">
+                            dev-container
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/diy%E3%82%AD%E3%83%BC%E3%83%9C%E3%83%BC%E3%83%89" title="diyキーボード">
+                            diyキーボード
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/elastic" title="elastic">
+                            elastic
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/elasticsearch" title="elasticsearch">
+                            elasticsearch
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/fluentd" title="fluentd">
+                            fluentd
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/hadoop" title="hadoop">
+                            hadoop
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/hugo" title="hugo">
+                            hugo
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/java" title="java">
+                            java
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/kibana" title="kibana">
+                            kibana
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/kuromoji" title="kuromoji">
+                            kuromoji
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/logstash" title="logstash">
+                            logstash
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/lucene" title="lucene">
+                            lucene
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/lucene-gosen" title="lucene-gosen">
+                            lucene-gosen
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/manifoldcf" title="manifoldcf">
+                            manifoldcf
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/marvel" title="marvel">
+                            marvel
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/misc" title="misc">
+                            misc
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/morphlines" title="morphlines">
+                            morphlines
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/music" title="music">
+                            music
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/nlp100" title="nlp100">
+                            nlp100
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/octopress" title="octopress">
+                            octopress
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/paper" title="paper">
+                            paper
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/plugin" title="plugin">
+                            plugin
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/python" title="python">
+                            python
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/riak" title="riak">
+                            riak
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/rust" title="rust">
+                            rust
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/rust-the-book" title="rust-the-book">
+                            rust-the-book
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/search" title="search">
+                            search
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/shield" title="shield">
+                            shield
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/solr" title="solr">
+                            solr
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/visual-studio-code" title="visual-studio-code">
+                            visual-studio-code
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/wikipedia" title="wikipedia">
+                            wikipedia
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/windows" title="windows">
+                            windows
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/workplace-search" title="workplace-search">
+                            workplace-search
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/yokozuna" title="yokozuna">
+                            yokozuna
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/zipkin" title="zipkin">
+                            zipkin
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/%E3%82%AA%E3%83%A9%E3%82%A4%E3%83%AA%E3%83%BC" title="オライリー">
+                            オライリー
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/%E3%83%96%E3%83%AD%E3%82%B0" title="ブログ">
+                            ブログ
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/%E5%82%99%E5%BF%98%E9%8C%B2" title="備忘録">
+                            備忘録
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/%E5%8B%89%E5%BC%B7%E4%BC%9A" title="勉強会">
+                            勉強会
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A" title="振り返り">
+                            振り返り
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/%E6%9C%AC" title="本">
+                            本
+                        </a>
+                        
+                        
+                        
+                        <a href="/tags/%E6%A4%9C%E7%B4%A2" title="検索">
+                            検索
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/%E8%AA%AD%E6%9B%B8" title="読書">
+                            読書
+                        </a>
+                        
+                        
+                        
+                        
+                        
+                        <a href="/tags/%E8%BB%A2%E8%81%B7" title="転職">
+                            転職
+                        </a>
+                        
+                        
+                        
+                        
+                    </div>
+                </section>
+                
+
+                
+                
+            </div>
+        </div>
+    </div>
+</article>
+
+
+
+
+<footer>
+    <div class="container">
+        <div class="row">
+            <div class="col-lg-8 col-lg-offset-2 col-md-10 col-md-offset-1">
+                <ul class="list-inline text-center">
+                   
+                   <li>
+                       <a href='' rel="alternate" type="application/rss+xml" title="@johtaniの日記 3rd" >
+                           <span class="fa-stack fa-lg">
+                               <i class="fas fa-circle fa-stack-2x"></i>
+                               <i class="fas fa-rss fa-stack-1x fa-inverse"></i>
+                           </span>
+                       </a>
+                   </li>
+                   
+                    
+
+                    
+                    <li>
+                        <a href="https://twitter.com/johtani">
+                            <span class="fa-stack fa-lg">
+                                <i class="fas fa-circle fa-stack-2x"></i>
+                                <i class="fab fa-twitter fa-stack-1x fa-inverse"></i>
+                            </span>
+                        </a>
+                    </li>
+                    
+                    
+                    
+
+                    
+
+		    
+                    
+                    
+                    <li>
+                        <a target="_blank" href="https://github.com/johtani">
+                            <span class="fa-stack fa-lg">
+                                <i class="fas fa-circle fa-stack-2x"></i>
+                                <i class="fab fa-github fa-stack-1x fa-inverse"></i>
+                            </span>
+                        </a>
+                    </li>
+		    
+                    
+                    
+                    
+                    <li>
+                        <a target="_blank" href="https://www.linkedin.com/in//jun-ohtani-254a634a">
+                            <span class="fa-stack fa-lg">
+                                <i class="fas fa-circle fa-stack-2x"></i>
+                                <i class="fab fa-linkedin fa-stack-1x fa-inverse"></i>
+                            </span>
+                        </a>
+                    </li>
+		    
+                    
+                    
+                    
+                    
+                    
+            
+            
+            
+                </ul>
+		<p class="copyright text-muted">
+                    Copyright &copy; @johtaniの日記 3rd 2024
+                    <br>
+                    <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
+                    <iframe
+                        style="margin-left: 2px; margin-bottom:-5px;"
+                        frameborder="0" scrolling="0" width="100px" height="20px"
+                        src="https://ghbtns.com/github-btn.html?user=zhaohuabing&repo=hugo-theme-cleanwhite&type=star&count=true" >
+                    </iframe>
+                </p>
+            </div>
+        </div>
+    </div>
+</footer>
+
+
+
+
+<script>
+    function async(u, c) {
+      var d = document, t = 'script',
+          o = d.createElement(t),
+          s = d.getElementsByTagName(t)[0];
+      o.src = u;
+      if (c) { o.addEventListener('load', function (e) { c(null, e); }, false); }
+      s.parentNode.insertBefore(o, s);
+    }
+</script>
+
+
+
+
+
+
+<script>
+    
+    if($('#tag_cloud').length !== 0){
+        async("/js/jquery.tagcloud.js",function(){
+            $.fn.tagcloud.defaults = {
+                
+                color: {start: '#bbbbee', end: '#0085a1'},
+            };
+            $('#tag_cloud a').tagcloud();
+        })
+    }
+</script>
+
+
+<script>
+    async("https://cdnjs.cloudflare.com/ajax/libs/fastclick/1.0.6/fastclick.js", function(){
+        var $nav = document.querySelector("nav");
+        if($nav) FastClick.attach($nav);
+    })
+</script>
+
+
+
+
+
+
+<script async src="https://www.googletagmanager.com/gtag/js?id=G-ZCZYDMJX3V"></script>
+<script>
+var doNotTrack = false;
+if (!doNotTrack) {
+	window.dataLayer = window.dataLayer || [];
+	function gtag(){dataLayer.push(arguments);}
+	gtag('js', new Date());
+	gtag('config', 'G-ZCZYDMJX3V', { 'anonymize_ip': false });
+}
+</script>
+
+
+
+</body>
+</html>
diff --git a/categories/index.html b/categories/index.html
index 96266d99f7..2051ddf219 100644
--- a/categories/index.html
+++ b/categories/index.html
@@ -323,6 +323,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                         hadoop
                         </a>
@@ -712,7 +714,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/elasticsearch.json b/elasticsearch.json
index 0a7bb89019..6160bf9d33 100644
--- a/elasticsearch.json
+++ b/elasticsearch.json
@@ -1 +1 @@
-[{"contents":"今年も振り返りブログをリビングで書いています（ドミノ倒しすごいな）。 FMVのキーボードで書いているのでタイポがつらい。。。\n振り返り（2022年に書いた抱負から） まずは振り返りをと。\nフリーランス継続 今年も個人事業主として乗り越えられました。 ZOZOさんには今年も引き続きお世話になっている感じです。 そのほかにベクトル検索のお手伝いをしたり、OpenSearchを調べたりといった仕事を手伝っています。 今年も完全にリモートで作業していましたが、イベントに出かけたりできました。 来年はもう少し出かける感じになるかな？ 今年はすこしのんびり仕事をしていたので、来年はもう少し仕事探さないとかな（営業しないとなあ）\nプログラミング 今年はプログラムを書いたほうかなと。 Goで個人用ですが、Slackのボットを書いてみたり（GoでSlackのボットを作った話 | @johtaniの日記 3rd | @johtani\u0026rsquo;s blog 3rd edition）、公開されているAmazonのプロダクトデータを使って検索アプリを書いてみたり。 プロダクト用のアプリを書いているわけではないですが、ちょっとずつコードを読んだり書いたりしています。\nベクトル検索まわりをさわる がっつりとまではいかないですが、Elasticsearchのベクトル検索の調査をやったりしました。 Amazonのプロダクトデータを使ってもうちょっとやろうと思いつつ、そこまでは手が回せてない感じですが。 速度という面でどうやって折り合いをつけつつ導入するのか？ どういうシーンでつかうのがいいのか？ どのモデル選ぶのか？とか気になることだらけ。 なんか、みなさんがどうしてるのか気になってしょうがないので、話をしてもいいよという方は連絡をもらえるとうれしいかもなぁ。 ベクトル検索とかLLMの周りの動きがはやすぎてついていけてるのかどうか。。。\n本を読む 今年は比較的読んだかも？\n単体テストの考え方/使い方 ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティング ザ・ダークパターン ユーザーの心や行動をあざむくデザイン これまでの仕事 これからの仕事 機械学習による検索ランキング改善ガイド ソフトウェア設計のトレードオフと誤り 初めてのGo言語 買って読んでない本ももっとあるんですが。。。\n振り返り(今年あったできごと) ここからは今年の出来事を。 今年もずっと自宅でしごとしてました。 あとは少し仕事が少なめだったのでゲームが多くなってしまったかも？（本読めばいいのに。。。）\nゲーム（ONI、ゼルダ、FactorioのSpace Exploration） Dev container導入 検索技術勉強会の再開 ゼルダの新作面白かったですね。年初はOxigen Not Includedをやっていたのに、ゼルダが出てからはご無沙汰中です。ゼルダが終わった後は、ゼルダロスになってPythonを書いたりしていたのですが、うっかりFactorioのSpace Explorationを始めてしまい大変なことに。。。 全然終わる気配がないｗ\nローカルでの開発環境などをDev containerにちょっとずつしています。 Slackのボット、検索の遊び場、このブログ環境など。Dockerが必要にはなりますが、VSCodeとDev containerで環境を隔離できるし、VSCodeの拡張もコンテナごとに入れるのもできたりと便利です。\n最後は、検索技術勉強会を再開したことです。再始動という感じで4年ぶり？に再開しました（12月に開催した時のページ）。残念ながら私は裏方をしてただけで、当日は参加できてないのですが、次回（たぶん4月くらい）は参加するつもりです。再開の声を上げてくれた@takuya_aさんありがとう。絶賛スピーカーを募集中です。\n来年の抱負 さて、来年の抱負です。\nフリーランス継続 プログラミング継続 ベクトル検索の使い方をいろいろ試す 本を読んだブログを書く 今年もなんとかフリーランスを継続できましたが、そろそろ営業をしないといけないのかも？ ということで、外でしゃべったりもしていかないとなぁと。 あとは、検索ってどうやって導入すればいいのか？検索どうすれば改善できる？みたいなところのお手伝いをもっとしたいと思っています。 昨年出したこの本もあるので（『検索システム ― 実務者のための開発改善ガイドブック』 – 技術書出版と販売のラムダノート）、勉強会をやろうとしているところに顔を出したりしたいなあ。 外部の人を呼んで社内勉強会とかをできるというところがあれば参加したいので、声をかけてもらえればと。\nプログラミングはGo言語を触ったし、今年後半には検索の画面回りのプロダクトを触ってTypeScriptを勉強していこうかなという気になっています（なっているだけかもしれない？）。\nベクトル検索の使い方は、LLMだったりRAGだったりが世の中を席巻しているのもあり、いろんな記事が出てきて全然追いつけていません。だれか、少人数で勉強会とかやると興味ある人とかいるかなぁ？ こんなブログ見つけたよ、こんな論文があったよ、こんな使い方したらよかったよとかの共有をやるとみんな楽になったりしないかなぁ？\n今年は時々出かけて移動するタイミングで書籍を読んでいました。 読んだだけになってるのもあるので、少しでもいいからブログか何かに残しとかないとな。\nさて、今年は少しゆっくりできたので、来年はもうちょっといろんなところに顔を出しつつ、新しい仕事もできるといいなぁ。 勉強会もスピーカー集めをがんばるぞと。\nということで、今年もあと少しというところで無事書き終わりました。 来年もよろしくお願いいたします。よいお年をー\n","date":1704008961,"dir":"post/2023/","id":"d869fb48cb9acba03dc639481524ee80","lang":"ja","lastmod":1704008961,"permalink":"https://blog.johtani.info/blog/2023/12/31/review-2023/","publishdate":"2023-12-31T07:49:21Z","summary":"今年も振り返りブログをリビングで書いています（ドミノ倒しすごいな）。 FMVのキーボードで書いているのでタイポがつらい。。。 振り返り（2022","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2023）"},{"contents":"この記事は、情報検索・検索技術 Advent Calendar 2023の15日目の記事です。\n昨年に続き2回目の情報検索のAdvent Calendar参戦です。\n今年は、夏にオンライン参加したBerlin Buzzwordsの「The Debate Returns (with more vectors) Which Search Engine?」というセッションでPhilippさんが話題に出したOrama searchという検索エンジンを紹介してみようと思います（Oramaが正式名称なのかな？）。\nOramaという検索エンジン 公式サイトのトップにも記載がありますが、エッジで動作する全文検索＆ベクトル検索エンジンというもののようです。 なにそれ？という感じがしますが、オープンソース版のドキュメントを見るともう少しわかりやすい説明になっています。\nOrama is a fast, batteries-included, full-text and vector search engine entirely written in TypeScript, with zero dependencies.\nOramaはTypeScriptで書かれた、依存なしで利用できる検索エンジンということです（batteries-includedって初めて見たかも。「必要なものがそろってる」とかいう意味みたい（参考：英語のWikipedia））。\n以下は公式サイトにあるサンプルです。\ncreateでスキーマの定義をした検索エンジンのインスタンスを生成します。 insertで先ほど生成した検索エンジンにデータをインデックスします（後で紹介しますが、一括でインデックスするメソッドも用意されています）。 searchで検索し、検索した結果が返ってきます。 以上です。あとは、必要に応じてGUIを用意するだけです。\nimport { create, insert, search } from \u0026#39;@orama/orama\u0026#39; const db = await create({ schema: { title: \u0026#39;string\u0026#39;, director: \u0026#39;string\u0026#39;, isFavorite: \u0026#39;boolean\u0026#39;, year: \u0026#39;number\u0026#39; } }) await insert(db, { title: \u0026#39;The Prestige\u0026#39;, director: \u0026#39;Christopher Nolan\u0026#39;, isFavorite: true, year: 2006 }) const searchResults = await search(db, { term: \u0026#39;prestige\u0026#39;, where: { isFavorite: true, year: { between: [2000, 2008] } } }) サクッと動きそうですよね？依存関係がなくTypeScriptで書かれているということは静的なサイトなどでコンテンツを検索するのに使えるのでは？\nということで、自分のブログに組み込んでみました。 今回は組み込んだ時の流れと気になった点などを紹介します。 Hugoに組み込む際になるべく簡単にしたかったので、unpkg.comで公開されているJavaScriptだけを利用する形で検索ページを作ってみました。 JavaScriptやTypeScriptは不慣れなので効率がよくなかったり、間違っている点があればコメントなどをいただけると嬉しいです。\n構成 私のブログサイトはHugoで生成（参考：Hugo導入時の記事）して、GitHub Pagesとして公開しています。 現在のブログ検索にはAlgoliaを利用しているのですが、テスト目的としてOramaも使えるようにしてみました（右上のメニューでOramaをクリックすると以下で説明するOramaによる検索を試すことができます。\n今回実装してみたのは次のような流れです（日本語検索対応については後で説明します）。\nHugoでJSONのリストを生成（これまでと一緒） 1.で生成したリストをもとにNodeのスクリプトでOramaのインデックスファイルを作成 2.で作成したファイルを公開 画面で3.のファイルをダウンロードして検索 1. HugoでJSONのリストを生成（これまでと一緒） HugoでJSONのリストを生成します。Algoliaに記事を登録するのにも利用している仕組みです。 検索に利用する記事の情報を1記事を1つのオブジェクトとして出力します。1つの配列に記事ごとのオブジェクトが入っているJSONファイルになります。\n少しだけ特殊なことをしています。 ブログ記事にTagsというフィールドのありなしで処理を分岐しています。 Oramaが配列にNullを受け取った場合にうまく動かなかったので出力するJSON側で調整しています（あとで再確認してIssueあげておかないと）\n2. 1.で生成したリストをもとにNodeのスクリプトでOramaのインデックスファイルを作成 最初に紹介した公式のサンプルの場合、毎回Oramaのインスタンスを生成した後にインデックス登録の処理を行わなければいけません。 ただ、Hugoで生成したコンテンツは特に動的に更新があるわけでもないので、検索画面を表示するたびにインデックス登録するのも無駄が多い気がします。 Orama単体で最初に実装した時には、1.で作成した記事一覧のJSONをOramaで実装した検索ページのスクリプトが呼ばれたタイミングでフェッチし、insertMultiple（複数登録用のメソッド）を呼び出す実装にしていました。\nOramaでは、あらかじめ作成したOramaのデータベースを永続化・リストアするためのData Persistenceプラグインが提供されています。 インデックスに登録する処理コストはHugoでコンテンツを生成した直後に行い、検索画面では作成済みのインデックスファイルをフェッチしてリストアする形にすることにしました。インデックスと記事のJSONデータを含んだファイルになるので、元の記事一覧のJSONよりはファイルサイズが大きくなってしまいますが、処理時間も含めて考えると許容できるサイズではないかなと。\n次のスクリプトは1.で生成したJSONファイルを読み込んで、Oramaでインデックスした後にdpackというバイナリ形式でファイルに保存しています。 こののプラグインで選択できる形式は現時点ではjson、binary（デフォルト＝msgpack）、dpackの3種類になります。 残念ながら今回試したところ、binaryではエラーが発生したので、dpackを使用しました。\n3. 2.で作成したファイルを公開 単にGitHub Pagesに公開しているだけです。 ブラウザが2.で作成したインデックスファイルをフェッチしてから利用するためです。\n4. 画面で3.のファイルをダウンロードして検索 あとは検索画面です（長すぎるので、styleの部分は省略しています）。\nまず、必要なライブラリなどを読み込みます（下のソースコードの1行目から14行目）。\nOramaだけであれば問題ないのですが、OramaのプラグインがOramaをモジュールとして参照しているため、importmapとして定義しています。 Oramaのプラグインがいくつか利用しているものがあったので、まとめてimportmapに定義してあります。\n次に、検索窓（search-searchbar）や検索結果（search-hits）などのHTMLタグを用意します。 ヒット件数と検索にかかった時間も取れるので、表示する場所としてstatsも用意してあります。\n22行目からが実際の処理になります。\n28行目で、手順2.で作成したインデックスのファイルをフェッチします。 32行目でフェッチしたファイルから取り出した文字列をリストアして、Oramaのインスタンスを生成します。 34行目のtokenizerに関しては日本語対応で説明します。\n48行目のquery関数がクエリの組み立て＋検索の処理です。search-inputで入力されたテキストをtermとして渡して検索をしています（56行目）。 検索した結果のリストをもとに検索結果のHTMLタグを組み上げていきます。 検索結果には後述する@orama/highlightのモジュールを利用してスニペットを追加しています。\n日本語対応 残念ながらOramaは公式には日本語をサポートしていません（サポートしているスキーマに設定できるlanguageの一覧（＝STEMMERSにあるものだけ指定可能）。一覧と実装分けたほうがいい気がするけど？）。 ただ、tokenize関数を変更できるようにしてくれています。これを利用して、少しトリッキーな形で日本語対応しました。\n先ほどの手順2.でOramaのcreate関数として、componentsに次のtokenizerを渡します。\nlanguageはenglishですが、日本語をtokenizeする処理に次のように書き換えました。 stemmingは今回は行わない（＝用意されているstemmerを使えない）のでfalse、normalizationCacheは空のMapを用意しておかないとエラーが出るので、new Map()しています。 この設定を使ってcreateすることで、\ncomponents: { tokenizer: { language: \u0026#34;english\u0026#34;, stemming: false, normalizationCache: new Map(), tokenize: (raw) =\u0026gt; { return tokenize(raw) }, }, }, 少しわかりにくいですが、tokenizerのtokenize関数の中で呼び出しているreturn tokenize(raw)の部分はwakachigakiというライブラリのtokenize関数となっています。\nwakachigakiというライブラリ Elasticsearchなどのサーバー上で動作させる検索エンジンではkuromojiなどの辞書を内包した形態素解析器を利用するのが通常です。 ただ、今回はブラウザだけで完結した簡単な検索を行う仕組みをOramaを使って提供しようと考えました（kuromoji.jsというのもありますが、辞書のサイズがそこそこのサイズです）。 ですので、辞書ファイルのない軽量の形態素解析ライブラリとして、wakachigakiというライブラリ（＝6.2Kbの軽量日本語分かち書きライブラリ）を利用してみました。\n最初はTinySegmenterの利用をしていたのですが、wakachigakiのサイトにもあるように、TypeScriptやES Moduleでも利用できる形式となっていたのでこちらに切り替えました。\n辞書もっていないため、品詞でのフィルタリングや読みを利用した処理はできませんが、日本語の文章を分かち書きしてくれます。\ntokenize関数の設定 OramaのTokenizerインタフェースのtokenizeは入力の文字列をstring[]として返すことを期待しています。 wakachigakiのtokenizeも文字列を引数にとり、string[]を返すので、そのまま呼び出すだけにしてあります。\nただ、今回のブログ検索の実装では、検索窓に入力された文字列も特に何も処理せずにtokenizeに渡す形にしています。 クエリパーサーなどを考える場合は、検索窓に入力された文字列を前処理したりする必要がありますが今回はいったんこれで。。。\ndata-persistenceはcomponentsはpersistしない 手順2.で導入した、data-persistenceプラグインですが、現在の実装ではOramaが生成したデータベース（転置インデックス）だけを永続化しています。 独自に設定したtokenizerは残念ながら含まれていませんでした。 手順4.の検索画面のコードの34行目の部分（下記）で、フェッチしたインデックスデータからrestoreした後のOramaのインスタンスのtokenizerに手順2.と同じ設定のtokenizerを設定することで検索時にも同じトークナイズがされるようになります（今の仕組みだと修正した場合には、両方のソースコードを修正しないといけないのがちょっと面倒かも？）。\ndb.tokenizer = { language: \u0026#34;english\u0026#34;, stemming: false, normalizationCache: new Map(), tokenize: (raw) =\u0026gt; { return tokenize(raw) }, } tokenizerはOramaの検索エンジンのインスタンスに紐づく設定となっているので、フィールドごとに切り替えるといったことも現在では想定されていない気がします。\nハイライト ハイライトのために、インデックスデータに単語のポジションを保存するためのプラグインも提供されています。 このポジションは検索の単語がヒットしドキュメントのどの位置に出てくるのか？をあらかじめデータとして保存しておくことで、ハイライトのたびに単語の位置を毎回計算しなくてもよくするためのものと思われます。\nこれを利用してもよかったのですが、今回は@orama/highlightというモジュールを利用することにしました。 検索にヒットしたドキュメントの元の文章と検索のキーワードを入力すると検索キーワードの周りにハイライトのHTMLタグを埋め込んでくれるライブラリを利用しました。これは普通に他でも便利かも？\n余力があればプラグインを利用した時のインデックスのサイズの違いや検索時の速度の違いを調べてみるのもいいかもしれないです。\nそのほかの機能 今回は利用していませんが、Oramaにはそのほかの機能も用意されています（公式ドキュメントの検索の紹介のページ）。詳細は公式ドキュメントをご覧ください。\nTypo tolerance Facet/Filter Vector Search Geo Search Grouping Threshold Preflight Oramaで（まだ？）できないこと 今回触ってみて、現在のOramaの実装ではできなそうなことがいくつかあったので書き出しておきます。 あくまでも現時点のことです。今後実装される可能性もあります。\nデフォルトでは、searchのtermに渡した文字列をtokenizeし、出力されたトークン列（単語の配列）のそれぞれのトークン（単語）にヒットしたドキュメントが全て検索結果に含まれます。 検索結果のドキュメントはBM25でスコアリングされるので、多くのトークンが含まれるものが上位に来る可能性が高いです。\nただ、特定の単語を含まない検索、ANDやOR検索など凝ったクエリは現在は書けないようです（Issueがある）。\nfilterは別途用意されているので、例えばファセットで表示したカテゴリで絞り込んだ状態にするといったことはできそうです。\n残課題 とりあえず日本語をなんとなく検索できるようにすることはできました。 が、気になることもいっぱいありました。 時間を見つけてTypeScriptなどを勉強しながら探っていく感じでしょうか。\nインデックスを小さくする方法 今回はブログ記事のサマリー（Hugoで生成されるSummary）でインデックスを作ったので、インデックスのサイズはまだ小さくなっています（といっても1MB超えてるけど）。ブログ記事全体を検索できるようにする場合は、インデックスファイルが大きくなります。\nこれは、OramaがデフォルトではインデックスしたJSON自体もインデックス（ドキュメントストア）に保存しているためです。 ですので、Oramaに登録したJSONデータ＋検索用のインデックスがインデックスファイルとなります。 ただ、検索だけができればよい場合は、出来上がったインデックスがあればドキュメントのIDは取得できます。\n公式ドキュメントでもそのことに触れているページがあります（参考：Remote document storing）。\nまだちゃんと実装を見ていませんが、ブログ記事本体の文字列はドキュメントストアに保存しないようにすれば検索はできるが、容量が大きくならないといった工夫ができそうです。\nただ、検索結果にハイライトを含んだスニペットを表示したい場合は、コンテンツ文字列が必要になってくるので、代わりに何かしらの仕組みを考える必要が出てきます（例えばサマリー部分の文字列だけ保存しておいて、ハイライトはそこだけを対象とするなど）。\nそのほか そのほかに思いつくのはこの辺でしょうか？\nオートコンプリート：Oramaというよりも、JavaScriptやTypeScriptでうまく実装できるのか？という話のような気がしますが。。。 ファセット対応：機能としては存在していますが、今回は実装が間に合いませんでした。 Vector Search：検索キーワードのベクトルをどうやって作るのか？という問題が残りそう。コンテンツのベクトルだけで関連ページの表示みたいなことはできるかも？（動的にやる必要がないので、事前計算して各ページに埋め込むほうがよさそうだけど） Geo Search：緯度経度があるデータを探し出してこないと？ relevanceの処理の変更：BM25以外に切り替えることができるかどうか（Oramaのソースとにらめっこしないといけなそう） tokenizeの改良：辞書を利用する形態素解析ライブラリやAPIを利用してみたり、「てにをは」といった1文字のひらがなを削ることで、無駄な検索ヒットを減らしてみたり。大文字小文字の正規化も必要。 検索ログの解析：検索ログを保存する仕組みなどはないので、Google AnalyticsやほかのAPIなどを用意する？ まとめ ということで、Oramaという検索エンジン？ライブラリ？を利用して日本語のブログ検索を実装してみました。 まだ、機能が少ない部分もありますが、少数のデータをブラウザだけで簡単に検索できる仕組みをGitHub Pagesだけで提供することができそうです。 今回は静的なファイルだけで完結する形にしましたが、TypeScriptで利用できる簡単な検索エンジンライブラリとして使ってみるとまた別の面白さもあるかもしれないです。 まだ触っていない機能は思いついたこと（＝残課題に書いたこと）もあるので、ちょっと試行錯誤してみようかなぁ。\n","date":1702566000,"dir":"post/2023/","id":"476e17b6f854414033d5cec1470774ee","lang":"ja","lastmod":1702566000,"permalink":"https://blog.johtani.info/blog/2023/12/15/introduce-orama-to-blog/","publishdate":"2023-12-15T00:00:00+09:00","summary":"この記事は、情報検索・検索技術 Advent Calendar 2023の15日目の記事です。 昨年に続き2回目の情報検索のAdvent Calendar参戦です。 今年は、夏","tags":["orama","search"],"title":"Oramaという検索エンジンでブログ検索を作ってみた"},{"contents":"PySpaアドベントカレンダーの12/08のエントリーです。昨日は渋川さんのアンラーニングで失敗した話でした。\n私は、今年は昨年の続きっぽい話を。\n音楽の再生とか停止とか 今年もリモートで仕事を継続しています。 昨年、OwnToneという音楽サーバーを導入しましたが、ミーティング開始時や終了後に音楽の停止や再生をするのに、ブラウザで操作するのはちょっと面倒です。 加えて、ミーティングする際には実際には\n音楽を止める 電気をつける といったことをっやります。 音楽再生についても\n音楽を再生する アンプの音は音楽再生用の音量にする といった複数のことを行います。\n基本的にPCの前にいるし、Slackを常に開いているからSlackのBotを作ると便利になるのでは？ ということで、自分専用のSlack Botを作ってみました。\nGitHubリポジトリ 全く誰の役にも立たないけど、公開しています。\nhttps://github.com/johtani/smarthome Goで実装 知り合いに勧められたということもあり、Goをあまり触ったことがなかったので、Goでやってみました。時々新しい言語を触ってみたくなるので。。。\nコマンドパターンのような作りで、コマンド（操作）を増やしていく感じで実装してはみたのですが、この書き方がいいのかはまだよくわかっていないです。\nActionという単体の操作(例：OwnToneの一時停止)を、操作したい機器の操作ごとに作成しています。 インターフェースとしてはRunだけを定義しています。\ntype Action interface { Run() (string, error) } それらの操作（Action）をひとまとめにしたものをSubcommandという形で定義して、SlackのBotにはSubcommandの名前を送って処理を実行する形にしています。\ntype Subcommand struct { Definition actions []action.Action ignoreError bool } やりたいことを追加するタイミングで時々リファクタしたりもしていますが、基本はこんな感じです。 細かな実装はさておき、今回ボットを作るときの観点をいくつか。\n宅内ネットワーク 音楽サーバーのOwnToneもですが、YAMAHAのアンプのAPIも見つけたのでこれらの操作をボットから行っています。どちらも自宅のネットワークにあるので、今回作成したボットも同じネットワークで動作します。\n外部に公開されたHTTPのエンドポイントがあればよいのですが、今回は用意していません。 SlackのAPIではこれに対応したアプリを作るときのためにSocket Modeを用意してくれています。\nドキュメントがしっかりしているのもあり、チュートリアルなどを見つつ特に迷うことなく構築できました。\n基本的には「特定のチャンネルでボットがメンションされたら動作する」という挙動だけしか実装していないので、特に今回はこれで困ることもありませんでした（世の中の人たちはもっとすごいSlackの使い方をしていそうだけど。。。）。\n対象となるものたち ボットから操作しているのは今のところ3種類です。\nSwitchBot OwnTone YAMAHAのアンプ SwitchBot SwitchBotについては、go-siwtchbotを利用しています。 電気、エアコン、空気清浄機、サーキュレーターのオンオフをSwitchBot経由でやっています。\n室内灯の明るさのために、SwitchBot側でシーンを設定している（一番暗い明るさで電気をつける）ので、そこが少しと特殊でしょうか？\nあとは、SwitchBotの温湿度計を3つ（室内2つ、室外1つ）おいてあるので、これらの温度を表示するコマンドも用意しました。\nそれぞれの機器の電池残量（電池の絵文字の右側）を表示してます（書斎が2つあるように見えますが、温湿度計の名前なので、同じ部屋においてあります。。。温度が高いほうがデスクトップPCの近くにある）。 防水の温湿度計があるので、外の気温もわかるのは便利です。\nOwnTone JSONのAPIが用意されていますが、特にクライアントライブラリなどは用意されていません。 今回は、用意されているAPIのごく一部だけを利用するので、net/httpのClientでJSONを投げています。 必要になったらowntone/clientにメソッドを追加していく感じです。\nhttps://github.com/johtani/smarthome/blob/master/subcommand/action/owntone/client.go#L45 再生、一時停止、プレイリストの取得、音量指定あたりを実装しています。 音の出力先はAirPlay（次に出てくるYamahaのアンプ）になっています。\nあと、JSON APIのサンプルをChatGPTに渡して、「このJSONをレスポンスに受け取る処理をGoで書いてください」と聞いて処理を書いたりしました（細かいのはどう聞いたか覚えてないけど）。\nYAMAHAのアンプ ググって探してきましたが、利用しているYAMAHAのアンプにYXC（Yamaha Extented Control）と呼ばれるAPIが用意されていました。 PDFでAPIの仕様が公開されていたので、この資料とにらめっこしながら、必要そうなAPIを実行するクライアントを実装しました。 こちらは、OwnToneのAPIの処理をすでに書いた後だったので、それをもとに必要な実装を追加しただけです。\nちなみに、アンプの電源をONにするAPIは実装していません。\nOwnToneで音楽を再生する(AirPlayで信号が送られるみたい) シーン選択（Nintendo SwitchやPS5のシーンを用意している）のAPIを呼び出す という処理をすると自動で電源がONになりました。スタンバイしている状態でもAPIはリクエストを受け付ける状態になっているようです。 また、PS5のシーンを呼び出したら、PS5自体も起動するのが便利だったりします。HDMI経由で信号が飛んでるのかな？ 「ミーティング開始」や「音楽停止」コマンドではアンプの電源をオフするAPIを呼び出すようにしています。\nタイポ対応 「入力間違いしちゃうんです、人間だもの。。。」\nということで、10月にタイポ対応の処理を入れてみました。 タイポ対応前の実装では、入力された文字列がコマンドの文字列と完全一致した場合にだけ、コマンドが実行される形になっていました。 結構タイポしちゃうので、完全一致で見つからない場合の処理として、入力された文字列とコマンド名のレーベンシュタイン距離が2以下のものを探し、その中で距離が一番小さな値のコマンドを実行する形にしてみました。 コマンド数はたかが知れているのでコマンドのリストを全部チェックする形にしています。 タイポするとこんな感じ。\nレーベンシュタイン距離の計算にはGo-edlibを利用しています。OSS便利ですね。\nやってよかったこと ミーティング開始時などのいくつかの手順が簡素化できたので満足しています。 SwitchBotの操作もスマホをわざわざ操作しなくてもいいですし（仕事してるとキーボードとSlackは常に使ってるし）。 また、副次的な効果として、部屋の外から電源を切り忘れていたり、エアコンの切り忘れなどの場合に、スマホから遠隔でまとめた処理ができるのが便利です。\n今後やってみたいこと こういうのがあるともうちょっと便利かもなぁ？というのもあるので今後も気が向いたらコマンドなどを追加していく予定です。 今のところこんなことやりたいなというのがいくつかあります。\nキーワードに関連する曲の再生 OwnTone自体に検索の仕組みがついているので、キーワードを受け付けてそれに関する曲を流す Flexispotの操作 ミーティングの時は立ち上がっているので、机をスタンディングの状態にしたい 電子工作しないとだめかも？ Webカメラ用ライトの点灯 ミーティング時に明かりが必要なのですが、物理スイッチのOn/Off これも電子工作かな？ 定期的に温度をBotに表示させるとと面白いかも？ まとめ ということで、新しいプログラミング言語にも触れたし、作業環境も便利になって一石二鳥でした。 新しいプログラミング言語触るのはやっぱたのしいですね。\n","date":1701961200,"dir":"post/2023/","id":"516a7aa07f8faa6b7aa38beb5010cf8c","lang":"ja","lastmod":1701961200,"permalink":"https://blog.johtani.info/blog/2023/12/08/smarthome-bot/","publishdate":"2023-12-08T00:00:00+09:00","summary":"PySpaアドベントカレンダーの12/08のエントリーです。昨日は渋川さんのアンラーニングで失敗した話でした。 私は、今年は昨年の続きっぽい話","tags":["misc","music","bot"],"title":"GoでSlackのボットを作った話"},{"contents":"「機械学習による検索ランキング改善ガイド」を読みました。\n著者の鈴木さんより献本いただいたのを読み終わったのでレビューと、あとおまけです。\n紹介とレビュー どんな本なのか？は打田さんが書かれたブログ、「ブックレビュー：『機械学習による検索ランキング改善ガイド』 - Tomoko Uchida - Medium」に詳しく書かれているので、そちらも参考にしてもらうほうがわかりやすいと思います（丸投げ）。\n読みながらいくつかツイートしていたので、そちらも参考のために貼っておきいます。\nオライリーの検索ランキング本、負荷テストのことも書いてある、すごいhttps://t.co/YPnB6kxFY2\n\u0026mdash; Jun Ohtani (@johtani) August 28, 2023 私のレビュー わかりやすく検索の基本を紹介しつつ、本書のメインであるランキング改善について全体の流れが書かれています。 ランキング改善のやり方といっても、手法の話だけではなく、プロジェクトとしてどの様に進めていくべきなのか？また、関係するものはどんなものがあり（システムだけではなくチームについても書かれていたり）、どういう判断をもちながら運用していくのか？、負荷テストにまで言及されています。\n読んでいて特に私が気に入ったのは以下のような話でした\nランキング改善を進める前にきちんと解ける問題なのか？それ以前にやることはないのかを考えましょう マッチング改善についても少しだけ触れられているが、メインはランキングについてだと明記されている 実際に体験されたのであろう落とし穴の話 負荷テストについて1章設けてある！ ハンズオンのパートでもレイテンシの話がされている 付録としてベクトル検索についても触れてある 日本語でまとまって読める本があるのは本当に幸せですよね。\nおまけ 書籍ではハンズオンで、Elasticsearchとランキング学習のプラグインであるelasticsearch-learning-to-rankを利用しています（GitHubにサンプルが公開されています）。 書籍ではElasticsearchが7.13.4、プラグインが1.5.7-es7.13.4というバージョンになっていました。\nブログを書いている時点でのElasticsearchは8.x系になっています。せっかくなので、書籍を読みながら現時点で最新のものに置き換えてみるというのをやってみました。\nElasticsearchは8.10.2が最新なのですが、ランキング学習のプラグインはサードパティ製で、1.5.8-es8.8.2が最新版となっています。 ハンズオンのサンプルコードをフォークして、以下の構成にして動くようにしてみました。\nElasticsearch : 8.8.2 learning-to-rankプラグイン : 1.5.8-es8.8.2 Kibana : 8.8.2 Python : 3.10 Elasticsearch、プラグイン、Kibanaのアップグレード Elastic社が提供しているDockerイメージが利用されているので、バージョン番号を書き換えました。 あとは、learning-to-rankプラグインのバージョンを書き換えるついでに、elasticsearch-pluginコマンドで直接ダウンロードさせる形に書き換えました。\nhttps://github.com/johtani/building-search-app-w-ml/blob/es8/part2/app/search-engine/Dockerfile\nPython3.10にアップグレード 本当は必要なかったのですが、Pythonのイメージもついでに3.10にしました。 ただ、このおかげでインストールされるXGBoostのバージョンも1系から2系に上がってしまい、XGBoostを利用してモデル生成をする処理でエラーが出るようになってしまいました。。。\n2系へのアップグレードは手間がかかりそうだということで、pipコマンドでのインストールでのバージョンを\u0026lt;2として、1系をインストールすることで回避しました。\nhttps://github.com/johtani/building-search-app-w-ml/blob/es8/part2/app/workspace/Dockerfile\nelasticsearch-pyのアップグレード Elasticsearchを8系にしたので、クライアントライブラリ側も8系に書き換えました（元は7.17以下に固定されていた）。 pipで7系に固定されていたものを外して最新のもの（8系）をインストールするようにしました。 これだけでも特に問題なく動いたのですが、「DeprecationWarning」が出ている部分が1か所だけあります（サンプルではDeprecationWarningが出力されない形になっていましたが、出力するように変更しました）。\nElastic公式のドキュメントにMigrate to 8.0というページが公開されています。Pythonクライアントのアップグレードを行う際はこちらを参考にすると指針が記載されています。\n今回のサンプルコードではsearchの時の引数としてbodyを渡していたのですが、8系のクライアントライブラリからこちらが廃止になり、queryやrescoreなど個別の引数を渡す形に変更されています（search APIのリファレンス）。 ですので、bodyを**bodyでアンパックして渡すようにしただけです。サンプルコードがわかりやすく書かれているので変更も少しで済みました。\nhttps://github.com/johtani/building-search-app-w-ml/blob/es8/part2/app/workspace/collect_responses.py#L59\n一応、これでエラーが出ないで動きました。 すべて適用した、フォークして修正したブランチはhttps://github.com/johtani/building-search-app-w-ml/tree/es8で公開しています。\nまとめ すごくわかりやすいうえに、手を動かしながらどんなデータを使ってどんなことをやるのかが体験できる良い本でした。 理論的な話だけでなく、システムとしてどういうものが必要で、どういうことをやらないといけないのか？というのがわかるのがイメージできるのは重要だと思います。\n最後は広告ですが、ランキング改善以外の検索システムについて学べる本を検索システム ― 実務者のための開発改善ガイドブック – 技術書出版と販売のラムダノート出していますので、こちらも参考書として読んでいただけるとうれしいです。\n","date":1695612744,"dir":"post/2023/","id":"7f78b02c531f09602ba4e140132d26a2","lang":"ja","lastmod":1695612744,"permalink":"https://blog.johtani.info/blog/2023/09/25/read-search-raking-guide/","publishdate":"2023-09-25T03:32:24Z","summary":"「機械学習による検索ランキング改善ガイド」を読みました。 著者の鈴木さんより献本いただいたのを読み終わったのでレビューと、あとおまけです。 紹介","tags":["読書","elasticsearch"],"title":"機械学習による検索ランキング改善ガイドを読みました"},{"contents":"趣味？（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書いています。 ベクトル検索などの確認なども含めて、Jupyter Notebookで簡単なAPIの呼び出しを書いていましたが、検索はやはり画面があるほうがにぎやかでいいですよね。 ということで、画面周りで調べものをしていた時のことを後日の自分のためのメモとして残しておきます。\nSearch UIとSearchkit ということで、それほど手がかからないで検索の画面をサクッと作る方法がないか？ということでちょっとだけ探してみました。 最初にElasticsearchを利用していることもあり、すぐに検索の画面を作れるライブラリ・フレームワーク・コンポーネントがないかな？ということで思いついたのが次の2つでした。\nElastic Search UI Searchkit どちらも直接Elasticsearchに接続して検索をすることができるコンポーネントです。 Elasticsearchだけで完結していればそれでおしまいだったのですが、今回はバックエンド経由でElasticsearchに検索を書ける必要があります（ベクトル検索の仕組みもデモをしたいため、クエリの文字列をLLMなどでベクトルにしてからknn検索をすることになります）。\nSearch UIの構成 もともとSearch UIはElasticのApp SearchのGUI構築向けのコンポーネントとして作られました。 最近になって、直接Elasticsearchに接続できるコネクターを提供しています（ベータだけど）。 このコネクターを利用した場合は、ざっくりですが、このような流れになります。\nまた、Search UIはCustom Connectorの仕組みも用意しており（ConnectorのAPIが宣言されているのでそのAPIで独自実装が可能）、これを利用することで、ブラウザではなくバックエンド（Node）でElasticsearch Connectorを利用するような構成も取れるようになっています。\n改めて要件をまとめると ということで、やりたいことは\n簡単にUIが作れる バックエンドはPythonを経由して検索したい となります。 Searchkitも調べようかと思いましたが、いったんはSearch UIのCustom ConnectorでPythonでFastAPIでバックエンドのAPIを実装して、Search UIの想定しているリクエスト・レスポンスに変換すればいいかな？ということにしました。\nとりあえずSearch UI＋Custom Connectorからのリクエスト・レスポンス（フロントからバックエンドへの出入りの部分）を記録し、 Search UI＋Elasticsearch Connectorのときのリクエスト・レスポンス（バックエンドからEsへのの出入りの部分）も記録して、 参考にしながらバックエンドを実装しようと試みました。 Search UIのCustom Connectorのサンプルとなっていた、Node上でElasticsearch Connectorを動かしている部分をPythonで簡単に再実装しようという試みです（まったく同じ実装にする必要はなく、必要最低限の機能（検索窓、ファセット、ページング）が動作するところを目指します）。\nElasticsearch API connectorの調査 方針が決まったので、Search UIがElasticsearch API Connectorに渡しているリクエストをブラウザのデバッグ機能を使って追いかけてみると。。。 内部でSearchkitを読んでいる？？ことがわかりました。\nElasticsearch API Connectorがリクエストを変換しているのかと思っていたのですが、実は内部にもう一段変換が行われていました。\n方針を決めたつもりが、Searchkitが出てきてしまったので、Searchkitも調べてみることに。。。 なお、Search UIにElasticsearch API Connectorを導入したのがどうやら、Searchkitの作者で、現在はElasticのエンジニアになられているようです。\nSearchkitとは？ Search UIが利用しているSearchkitは、3.0ですが、Searchkit本家のリポジトリを見ると4.x.0となっています。\nどうして新しいものをSearch UIで使っていないのかな？と思いつつ調べてみたところ、Searchkit V4のブログを発見しました。\nSearchkit V4 integrates with Algolia’s Instantsearch library, which is a Search UI library built by Algolia. Instantsearch is an amazing library, and it’s been used by many companies and supports many frameworks like React, Vue and Angular. ブログより引用\nどうやら、V4ではコンセプトをガラッと変更されたようで、Algoliaがオープンソースとして開発しているInstantSearchのコネクター（アダプター）としてSearchkit V4を開発しているようです。 これは最近出てきている検索エンジンのTypesenseやMeilisearchの戦略にもなっています。\nなお、SearchkitのGitHubリポジトリやSearch UIのリポジトリを見ていると、Search UIの開発（およびSearchkitの3系）は現在は活発に行われていないように見えました。 Searchkit V4はちょっとずつ開発が進んでいるようです。\nまとめ？ 一応Searchkit V4の現状やInstantSearchもすこしだけ見てみたのですが、今回の私のプロジェクトでは検索画面はまだそこまで重要度は高くないので、いったん調べていたSearch UI＋Pythonのバックエンドの構成で動作する最小限を実装したところで終わりにしました。 なので、Searchkit V4＋InstantSearchの構成はまた今度という感じです。\nなお、Search UIの方は5月からコミットがされていないようです。どうも開発しているチームが別件で忙しそうだなというのを感じました。\n","date":1692768764,"dir":"post/2023/","id":"8f58cbe5f2ce85c22569af765de3f8d3","lang":"ja","lastmod":1692768764,"permalink":"https://blog.johtani.info/blog/2023/08/23/search-ui-and-searchkit/","publishdate":"2023-08-23T05:32:44Z","summary":"趣味？（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書いています。 ベクトル検索などの確認なども含めて、Jupyter N","tags":["searchkit","search-ui","画面"],"title":"search-UIとSearchkitと検索画面"},{"contents":"いくつかある環境をDev Containerで動くように変えていますが、最初に導入した時に疑問点だった「コンテナ名」について解消したのでメモを残しておきます。\nコンテナ名の指定 最初のDev Container導入の記事で、起動したコンテナの名前が自動で付与されて、ランダムに変わるという疑問点を書いていました。\ndocker-compose.yml対応の記事ではdocker-compose.ymlを利用すると、コンテナ名はファイル内で定義されたサービス名で起動されて見やすくなると気づきました。\nやはり、Dev Containerでイメージを指定している場合もわかりやすいコンテナ名がいいなと思ったところで、「runArgs」を思い出しました。 Dev Containerからコンテナを起動するときに渡す引数が書けるじゃないですか。そういえば、むかしdockerコマンドを使う時に名前を指定した記憶があったなと。ということで、Google検索です。「docker command args container name」で検索しましたｗ\n--nameというオプションで起動時のコンテナの名前の指定ができます。ということで、このブログを生成するためのdevcontainer.jsonに\u0026quot;runArgs\u0026quot;でコンテナ名を指定してコンテナ起動ができるようになりました（「ブログ記述環境としてのDev Container」という記事のdevcontainer.jsonにrunArgsの行を追加しただけ）。\n{ \u0026#34;name\u0026#34;: \u0026#34;Hugo - blog generator\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;mcr.microsoft.com/devcontainers/javascript-node:16\u0026#34;, \u0026#34;runArgs\u0026#34;: [\u0026#34;--name\u0026#34;, \u0026#34;blog_generator\u0026#34;], \u0026#34;postCreateCommand\u0026#34;: \u0026#34;/bin/sh ./.devcontainer/postCreateCommand.sh\u0026#34;, ... ","date":1690420969,"dir":"post/2023/","id":"f9e847ee886bdb9ab5583eeb6eabbd51","lang":"ja","lastmod":1690420969,"permalink":"https://blog.johtani.info/blog/2023/07/27/container-name-in-devcontainer/","publishdate":"2023-07-27T01:22:49Z","summary":"いくつかある環境をDev Containerで動くように変えていますが、最初に導入した時に疑問点だった「コンテナ名」について解消したのでメモを","tags":["dev container"],"title":"VS CodeとDev Container(コンテナ名の指定)"},{"contents":"このブログの生成には、Hugoを利用しています。 ブログ移行日記（その1）に書いてありますが、当時はbrewでインストールしていました。 また、Windowsに移行したタイミングで、WSL2のUbuntuにaptでhugoをインストールして利用していました。 WSL2の環境が壊れなければこのままでもいいのですが、最近Dev Containerを触っていたので、このブログを書く環境（おもにHugo）もDev Containerにできるのでは？と気づきました。\nということで、Hugo＋αの環境をDev Container化したので、そのメモです。\n必要なもの ブログを書いて、記事を構築して、公開するところまでに利用するのは次のようなものです。\ngit Hugo node atomic-algolia GitHubのプライベートリポジトリでHugoのプロジェクトを管理しています。 また、GitHub Pagesで公開しており、生成したHTMLもgitコマンドを利用してGitHubにpushしています。 このため、gitコマンドが必要です。\nコンテンツの生成はHugoコマンドを利用します（テーマの適用とかいろいろ）。\nあと、Algoliaでブログを検索できるようにしており（ブログ移行日記（その4）参照）、Algoliaへドキュメントのデータをアップロードするために、atomic-algoliaを利用しています。こちらは、nodeのモジュールであるので、nodeの環境も必要です。\nベースにするイメージ Dev Container Templatesというリポジトリが公開されています。 こちらを探すと、元となるdevcontainer.jsonが見つかることがあります。 Hugoのものがあるか探してみましたが、残念ながら見つかったのはJekyllのテンプレートでした。 今回は、nodeの環境が必要なのでjavascript-nodeを元に編集していきます。\n手元のUbuntuのnodeのバージョンが16だったので、バージョン16のイメージを指定します(devcontainer.jsonは後述)。\nHugoの追加 Hugoのテンプレートはなかったのですが、Dev Container FeaturesにHugoのfeatureが用意されていました。 featuresに1行追加するだけでコンテナにHugoをインストールしてくれる便利ものです。\nMarkdownの環境 Dev Container Templatesを探索していて見つけたMarkdownのテンプレートも参考にしてみました。 VS CodeのMarkdown向けの拡張機能がいくつかリストアップされていたので、ついでに追加です。 markdown-all-in-oneやmarkdownlintはこれまでも利用していたので、他のものも便利だろうということで。 他の物はどんなものかを後で調べてみる予定です。\n作った.devcontainerの設定はこちら ということで、出来上がった設定は以下の通りです。\ndevcontainer.json { \u0026#34;name\u0026#34;: \u0026#34;Hugo - blog generator\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;mcr.microsoft.com/devcontainers/javascript-node:16\u0026#34;, \u0026#34;postCreateCommand\u0026#34;: \u0026#34;/bin/sh ./.devcontainer/postCreateCommand.sh\u0026#34;, \u0026#34;features\u0026#34;: { \u0026#34;ghcr.io/devcontainers/features/hugo:1\u0026#34;: {} }, \u0026#34;customizations\u0026#34;: { \u0026#34;vscode\u0026#34;: { \u0026#34;extensions\u0026#34;: [ \u0026#34;yzhang.markdown-all-in-one\u0026#34;, \u0026#34;streetsidesoftware.code-spell-checker\u0026#34;, \u0026#34;DavidAnson.vscode-markdownlint\u0026#34;, \u0026#34;shd101wyy.markdown-preview-enhanced\u0026#34;, \u0026#34;bierner.github-markdown-preview\u0026#34; ] } } } postCreateCommand.shでは、npm installで、必要なモジュールのインストールをコンテナビルド後に実行できるようにしました。 （apt updateはなくてもいいな）\npostCreateCommand.sh #!/bin/sh # postCreateCommand.sh echo \u0026#34;START Install\u0026#34; sudo apt update sudo chown -R vscode:vscode . npm install echo \u0026#34;FINISH Install\u0026#34; まとめ ということで、ここ最近Dev Containerについて色々調べていたのでサクッとDev Container化ができました。 まぁ、HugoのFeatureが用意されていて、他に大したことをやっていないというのが大きいのですが。 このブログは今回構築したDev Containerで生成して公開した記事になります。\n","date":1690189832,"dir":"post/2023/","id":"7884b62c561b999b9358d52779a18218","lang":"ja","lastmod":1690189832,"permalink":"https://blog.johtani.info/blog/2023/07/24/introduce-dev-container-to-hugo-env/","publishdate":"2023-07-24T09:10:32Z","summary":"このブログの生成には、Hugoを利用しています。 ブログ移行日記（その1）に書いてありますが、当時はbrewでインストールしていました。 また、","tags":["hugo","dev container"],"title":"ブログ記述環境としてのDev Container"},{"contents":"WSL2にUbuntuを入れて、開発とかはこちらを利用しています。 また、Docker DesktopもWSL2のバックエンドエンジンを利用しています。\n知り合いとの話で、Ubuntuの外付けのSSDをマウントしたという話が出てきて、それだと遅くない？Ubuntu自体を移動できるんじゃないかな？という 流れになりました。 知り合いは、特に移動とかは考えてなかったのですが、自分のディスクの容量が今どのくらい使われているのかが気になり、調べてみると、 Cドライブの使用率が90%を超えてるじゃないですか。\nWizTreeというソフトを前回入れていたのを思い出して、再度調べてみたところUbuntuらしきvhdxファイルのサイズが171GB、Docker Desktopのデータ領域のvhdxファイルのサイズが81GBと、結構な割合です。\n前回は、Hyper-V管理ツールで仮想ディスクの圧縮処理を行ったのですが、Dドライブに移行したほうが安心できそうな気がしたので、移動の方法を調べました。\nWSLコマンドのドキュメントが公式で公開されています。こちらのコマンドを元に作業をしました。 また、ググって出てきた記事も参考にさせていただきました。ありがとうございます。\nwsl をDドライブに入れ直してディスク拡張する | blog.ojisan.io WSL2環境をコピー（複製）する方法 - Qiita まずは確認と停止 WSL2で使っているディストリビューションを確認します。コマンドは以下の通り。 実行した結果も含まれています。コマンドの実行にはコマンドプロンプトを使用しました。公式ドキュメントのドキュメントではスニペットはPower Shellと書かれてますが、コマンドプロンプトでも大丈夫そうでした。\nD:\\\u0026gt;wsl -l -v NAME STATE VERSION * Ubuntu Running 2 docker-desktop Running 2 docker-desktop-data Running 2 残念ながら、wslのコマンドでは実体がどこにあるのかを調べることができなかったですが、WizTreeでディレクトリ名などを見ていたのでなんとなう予測ができました。 （これ、他に知る方法あるのかなぁ？）\nディストリビューションの移動は次のような手順になります。\nwslのshutdown エクスポート（ディストリビューションのコピー） 今あるディストリビューションを削除 インポート（今ある名前で2.のファイルをインポート） まずは停止です。これをやらないとエクスポートができないので。\nD:\\\u0026gt;wsl --shutdown エクスポート 次にエクスポートです。 今回は以下の2種類の仮想環境をエクスポートします。\nUbuntu docker-desktop-data エクスポートでは、元のディストリビューションのファイル（Cドライブにあるファイル）が消えることはありません。 また、エクスポートの形式として、tarとvhdxの2種類が指定できます。 エクスポートのコマンドのデフォルトはtar形式ですが、エクスポート元のファイルがvhdxなので、vhdxでエクスポートしたほうがCPUにやさしかったです。 ちなみに、docker-desktop-dataはtar形式でエクスポートしてインポートしました。tar形式の場合は、ディスクのサイズが小さくなる可能性があるみたいです（不要なデータがvhdxの中に残っていたりする影響かと）。\nコマンドは以下の通りです（詳細は公式ドキュメントを参照してください）。出力ディレクトリはあらかじめ作っておきました（作ってない場合の挙動は未確認です。）\nD:\\\u0026gt;wsl --export Ubuntu .\\wsl\\Ubuntu\\ext4.vhdx --vhd docker-desktop-dataはtar形式です。\nD:\\\u0026gt;wsl --export docker-desktop-data .\\Docker\\ docker-desktop-data.tar ディストリビューションの削除（こわい？） 今ついているディストリビューション名を利用したいので、いったん、Cドライブ上にあるディストリビューションを削除する必要があります。 コマンドは公式ドキュメントにある--unregisterオプションを利用します。 以下のコマンドはUbuntuですが、docker-desktop-dataもやりました。\nD:\\\u0026gt;wsl --unregister Ubuntu ちなみに、このコマンドを実行すると、Cドライブの容量がいきなり空きました。 コマンドいっぱつでなくなりました。きちんとエクスポートしてから実行しましょう。 （なんなら、一度、別名でインポートして動作確認するのもいいかもしれないです。私はしましたｗ）\nインポート インポートするオプションも2種類あります。vhdxファイルの場合は、インプレースでのインポート（vhdxファイルをそのまま利用する形式）が可能です。 Ubuntuについてはこちらを利用しました。この場合、vhdxファイルがそのまま利用されるため、バックアップとしては利用できなくなります。今回は170GBもあるので、これでいいかと。\nD:\\\u0026gt;wsl --import-in-place Ubuntu .\\wsl\\Ubuntu\\ext4.vhdx tarファイル（docker-desktop-data）の場合は、通常のインポートを行いました。\nwsl --import docker-desktop-data D:\\Docker\\docker-desktop-data\\ D:\\Docker\\docker-desktop-data.tar この場合、tarファイルは残ったままで、新たにD:\\Docker\\docker-desktop-data\\ディレクトリにext4.vhdxファイルが作られました。 バックアップも取りつつ移行したい場合は--importがいいかもしれません。 また、WSLはバージョン1とバージョン2があり、インポートの際にこの部分も気にする必要があるようです。 今回はすべてバージョン2で、かつ、wslのデフォルトのバージョンを2にしてあったので特に意識していません。\nUbuntu起動ユーザーの指定と注意点 公式ドキュメントに、既存のユーザーを変更するコマンドの記載があります。 インポートしたディストリビューションは、デフォルトユーザーがrootになっていることがあるようなので、Ubuntuのユーザーを次のようなコマンドで変更しました。\nubuntu config --default-user johtani 公式ドキュメントの警告にもありますが、実行可能ランチャーがない場合があります。 今回のubuntuは、WSL2でUbuntuをインストールした時に作成されたコマンドで、unregisterした後にimportしてもきちんと動いたので問題にはなりませんでした。これは、インポートするときに、既存のディストリビューション名を利用したためと思われます。\nエクスポートやインポートの検証するために、NewUbuntuという名前で別途インポートした時には、NewUbuntuという実行可能ランチャーは作成されず、上記のデフォルトユーザーの設定は別の方法が必要になります（罠だ）\ndocker-desktop-dataのほうは、特に変更してないけど動いてそうだからいいのかな？ 前の設定の確認とかやっておくのがいいんだろうな、本当は。。。\nまとめ ということで、Cドライブに300GB近い空きができて、心の余裕もできました。 今回は、同じPC内で別のドライブへの移動でしたが、他のPCにもこれで移行ができそうですね。 たまにはバックアップをとっておくのもいいのかも？と思いました（やるかどうかはまた別の話）\n","date":1690180128,"dir":"post/2023/","id":"ed431877ce11fe403fee77f7d26ce637","lang":"ja","lastmod":1690180128,"permalink":"https://blog.johtani.info/blog/2023/07/24/move-distribution-to-another-disk/","publishdate":"2023-07-24T06:28:48Z","summary":"WSL2にUbuntuを入れて、開発とかはこちらを利用しています。 また、Docker DesktopもWSL2のバックエンドエンジンを利用して","tags":["wsl","windows"],"title":"WSL2のディストリビューションの環境移行"},{"contents":"前回の記事で、VS Code＋Dev Containerを導入しました。 残課題として「マルチコンテナ化」があるという話もしました。今回はDev Containerのdocker-compose.yml対応をした話をメモとして残しておきます。 実際、VS Code + Dev Containerに移行した後に、Esを起動してアプリからつなげるというのがうまくいかないというのがあったので対応がんばりました。。。\nDev Containerのdocker compose設定 この記事ではすでにdocker-compose.ymlが存在している状態の話をします。 変更する前は、devcontainer.jsonでベースのコンテナイメージの指定、マウントの設定などを行っていましたが、docker-compose.ymlにいくつかを移動しないといけません。 対応した時の作業の流れは以下のような感じです。\nワークスペース用のDockerfileの作成 docker-compose.ymlにワークスペース用のサービスを追加 devcontainer.jsonをdokcer-compose.ymlを利用する形に書き換え アプリでの接続文字列をlocalhostからdocker-compose.ymlのサービス名に変更 参考：対応した時のコミットです。差分などはこちらをごらんください。\ndevcontainerのリポジトリにPython+PostgreSQLのサンプルが公開されており、こちらを参考にしながら作業をしました。\n1. Dockerfileの作成 docker-compose.ymlだけでも完結するのかもしれないですが、いろいろやりたいことも出てくるかもしれないので別のファイルに切り出しました。 といっても、コンテナのイメージはdevcontainer.jsonに記述していたものを使っています。\nARG VARIANT=3.11-bookworm FROM mcr.microsoft.com/devcontainers/python:${VARIANT} ENV PYTHONUNBUFFERED 1 ENV TZ Asia/Tokyo TZはdevcontainer.jsonで指定していたものを、こちらに移行した形になります。 PYTHONUNBUFFEREDは参考にしたDockerfileの記載です。標準出力・エラーをバッファリングしない指定になっています。\n2. dokcer-compose.ymlにサービス追加 backendという名前のサービスをdevcontainer（VS Code）から接続するコンテナのサービス名にしています。\nservices: backend: build: context: . dockerfile: .devcontainer/Dockerfile init: true environment: - TZ=Asia/Tokyo command: sleep infinity volumes: - .:/workspace/search-research:cached - venv-search-research-backend:/workspace/search-research/.venv ... volumes: venv-search-research-backend: 1.で作成したDockerfileを利用します。docker-compose.ymlファイル自体は、プロジェクトのルートディレクトリに配置していますが、Dockerfileは.devcontainerディレクトリに入れたため、contextとdockerfileはこのような指定になっています。\ninitは、devcontainer.jsonで指定していた\u0026quot;runArgs\u0026quot;: [\u0026quot;--init\u0026quot;],の設定になります。\ncommandの部分は、コンテナが起動したままにしておくための設定です。\nvolumesでは2つのボリュームに関しての指定があります。 1つ目の/workspace...は、VS Codeがコンテナにプロジェクトをマウントする場所の指定です。 devcontainer.jsonだけを利用していた場合は意識していませんでしたが、/workspace/プロジェクト名というディレクトリにプロジェクトがマウントされていました。 docker-compose.ymlを利用する場合は、明示的に指定が必要です。 2つ目のvenv-...は.venvのディレクトリをコンテナの中だけのものにする設定を移植したものになります。 前回の記事ではコンテナIDをボリューム名に含めていましたが、こちらのほうがわかりやすいかと思い、プロジェクトの名前とサービス名をつけるようにしてみました。 Dev Containerで起動した場合はsearch-research_venv-search-research-backendという名前がついています（最初の部分はDev Containerがつけてるのかな？）\n3. dovcontainer.jsonの変更 devcountainer.jsonから呼び出すものの準備ができたので、devcontainer.jsonを書き換えます。 公式のドキュメントとしてDocker Compose向けのプロパティが紹介されています。 変更したものは次のような形です。\n{ \u0026#34;name\u0026#34;: \u0026#34;search-research\u0026#34;, \u0026#34;dockerComposeFile\u0026#34;: \u0026#34;../docker-compose.yml\u0026#34;, \u0026#34;service\u0026#34;: \u0026#34;backend\u0026#34;, \u0026#34;workspaceFolder\u0026#34;: \u0026#34;/workspace/search-research\u0026#34;, \u0026#34;postCreateCommand\u0026#34;: \u0026#34;/bin/sh ./.devcontainer/postCreateCommand.sh\u0026#34;, \u0026#34;customizations\u0026#34;: { ... dockerComposeFile : 利用するdocker-compose.ymlのファイルパス service：VS Codeが利用するワークスペース用のサービス名 workspaceFoldeer：VS Codeがコンテナに接続したときに開くフォルダのパス を指定します。これで、VS Codeでこのプロジェクトを開いた時に、Dev Containerがdocker-compose.ymlを使ってコンテナの起動（ビルドとか）を行ってくれます。\n4. アプリの接続文字列の書き換え こちらはおまけです。 PythonのアプリからElasticsearchに接続するときの文字列として、Dev Container化の前は、http://localhost:9200と指定をしていました。 Elasticsearch用のサービス（es）で、ポートフォワードをしていたためです。\nアプリ側もコンテナ化したので、Docker Composeが名前の解決をしてくれるので、http://es:9200という接続文字列で接続ができるようになりました。\nということで、ここまでで、VS Codeでプロジェクトを開くと、2つのコンテナ（backendとes）が起動してVS Code上でPythonアプリからEsへの接続ができるようになりました。\n追加の変更 参考のプルリクでは、上記まででしたがさらにいくつかの変更をそのあとやっています。\n起動するサービスの指定(開発だけするときはEsを起動したくない) devcontainer.jsonでrunServicesを使って指定できます（公式ドキュメント） GPUをコンテナから利用できるように devcontainer.jsonでfeaturesのnvidia-cudaを指定し、docker-compose.ymlでnvidiaのドライバーなどを設定することで対応しました。 nvidiaが公開しているcuda対応のコンテナイメージでもよかったのですが、こちらのほうが楽そうだったという理由です。featuresとコンテナのビルド、postCreateCommandの順序などはもうちょっと勉強しないといけない気がしています。 これらの対応はこちらのコミットで対応しています。\nGPUの対応は、私個人の環境はこれでいいのですが、複数の人がこのリポジトリを使う場合はどうやって切り替えたりするんだろう？という疑問が残っています。。。 今回はrinna/japanese-clipのモデルを使って、テキストからベクトルを生成する部分の処理のためにGPUを使いたいというモチベーションがあり、コンテナでもGPUを使えるようにしています（CPUだと時間がすごくかかる。。。）。\nサービス起動の新たな問題点 runServicesで起動するサービス名を指定したのはよかったのですが、Elasticsearchのサービスを起動して、データ登録や検索の確認を行おうと思った時に、EsのコンテナをVS Codeだけで起動する方法がまだわかっていません。。。 一度コンテナをビルドした後なら、「Remote Explorer」でOther Containerというくくりで表示され、右クリックで起動や停止ができそうなのだけど、新規サービスをdocker-compose.ymlに追加した場合は、自分でターミナルなどでコンテナのビルドをしないといけないかもしれないです。もうちょっと調べてみないとなぁ。\n副次的な効果 Docker Compose対応をしたことで、前回の記事での疑問点のうち、「コンテナ名」「VolumeのID」については懸念点がなくなりました。\n「コンテナ名」は、docker-compose.ymlのサービス名がコンテナ起動時に名前として利用されるため、Docker Desktopで見た時などの探しにくさはなくなりました。 ただ、「イメージ名」については、いまだに2つできています。「-uid」がつかないものの代わりに、search-research-backendというイメージが作られています。 ただし、実際に利用されるのは前回の記事に書いたようなvsc-search-research-bf04371c017c8d2f1dd5ad2529841b02e9ea1d1aaa4354c19edf53cef3f0c13b-uidという名前のイメージです。\n「VolumeのID」については、docker-compose.ymlのファイルで自分で名前をつけるようにしたので、コンテナのIDが利用されなくなったという次第です。 代わりに、プロジェクト名である「search-research」という名前を直接記述しているので、変数などで置き換えたほうがいいのかも？という気がしています。\nまとめ ということで、複数のコンテナを利用するプロジェクトでVS Code+Dev Container対応ができそうだということがわかりました。 ついでに、GPU対応もできたのでこれで、やっと他の検索エンジン対応などができる気がしています。 （その前にpre-commitを保存時にチェックする形に変更かなぁ） やりたいことからちょっとずつ外れている気もするけれど、新しいことを調べるのは楽しいですね。\n","date":1689902010,"dir":"post/2023/","id":"086b4fd5f77021a0a2aa6b0e90061486","lang":"ja","lastmod":1689902010,"permalink":"https://blog.johtani.info/blog/2023/07/21/multi-containers-with-dev-container/","publishdate":"2023-07-21T10:13:30+09:00","summary":"前回の記事で、VS Code＋Dev Containerを導入しました。 残課題として「マルチコンテナ化」があるという話もしました。今回はDev C","tags":["python","dev container"],"title":"VS CodeとDev Container（docker-compose.yml対応）"},{"contents":"前回の記事で、pre-commitとPyCharmとWindowsの組み合わせで困っていることを書きました。 これについて、知り合いとチャットで話をしていて、それほどPyCharmにこだわりもないよなぁということになり、 であれば、ISIDのブログ（Dev Containerを使ってステップバイステップで作るPythonアプリケーション開発環境 - ISID テックブログ）を試してみるとすっきりするかもしれないとなり、Dev Container対応をブログを参考に行ってみました。\n順を追ってブログで説明されているので、どういう仕組みなのか、どの設定が何を意味しているのか？がとてもよくわかりやすくすんなり対応することができました。\nブログの手順をなぞっているところでいくつか固有の手順や疑問点が出てきたのでブログに書き記しておきます。 結果は、コミットしてあるものを見てください。\nブログとは違う手順 まずはISIDのブログとは違う点をいくつか。\n.venvはいったん削除 ブログでは新規のプロジェクトを作成していく過程で、コンテナ化した環境を作った後に.venvをDockerコンテナのボリュームにして、最後に仮想環境のPythonを生成していました。 私の場合は、すでにホストOS（実際にはWSL2のUbuntuだけど）で.venvのディレクトリを作成してある状態だったので、いったん削除する必要がありました。 すでに存在する.venvがbindマウントされてしまっている状態になるため、Dockerのボリュームとの整合性が取れなくなるようです。\nこの作業を行う前か、途中でDev Containerを停止した状態で、.venvを削除することで問題なくDockerのボリュームに仮想環境のPythonが登録されるようになります。\npostCreateCommand.shの呼び出し方 ファイルに実行権限がないと、実行権限エラーが出ました。 実行権限を与えるか、次のような記述で動くようになりました。 今は、ファイルに実行権限をつけるのではなく、次のような記述にしていますが、何か問題あるかな？\n\u0026#34;postCreateCommand\u0026#34;: \u0026#34;/bin/sh ./.devcontainer/postCreateCommand.sh\u0026#34;, 実際に動作しているログを見ると\n/bin/sh -c /bin/sh ./.devcontainer/postCreateCommand.sh\nとなっているので、少し気持ち悪いのだけれども。。。\npostCreateCommand.shの追加処理 今回Dev Containerを適用したプロジェクトでは、sentencepieceを利用します。 この、sentencepieceをpoetryがインストールするタイミングで、cmakeを要求してきました。 今回利用しているDocker Imageにはcmakeは含まれていないため、以下の処理を追加しています。\nsudo apt update sudo apt-get install cmake -y また、rinna/japanese-clipも利用しているのですが、こちらは、poetryで追加してインストールでは依存するパッケージがインストールされないため、pipコマンドを利用するようにしています。\npip install git+https://github.com/rinnakk/japanese-clip.git コンテナイメージを作った後にやりたいことを、自由にスクリプトで書けるのは便利ですね。\npre-commitのスクリプトの再生成 こちらも、既存の環境が残っているとPythonへのパスの違いの問題が出たので、作り直しました。 .git/hooks/pre-commitのファイルを削除し、pre-commit installをやったものをリポジトリにコミットしてあります。\n疑問点 作業をしていて疑問点もいくつか出てきたのでメモを残しておきます。ちなみに、これらの疑問について実際に調べるまでには至っていません。 時間を見て解決できればなぁと（できるのか？）。\nImageが2つ Dev Containerの設定を書いた後に、コンテナをビルドすると、Docker DesktopのImagesにイメージが出来上がります。 この時、イメージが2つできあがっています（なぜ？）。\nREPOSITORY TAG IMAGE ID CREATED SIZE vsc-search-research-bf04371c017c8d2f1dd5ad2529841b02e9ea1d1aaa4354c19edf53cef3f0c13b-features-uid latest 25c7e23416ec 3 days ago 1.69GB vsc-search-research-bf04371c017c8d2f1dd5ad2529841b02e9ea1d1aaa4354c19edf53cef3f0c13b-features latest fcf9eaeb2187 3 days ago 1.69GB こんな感じで、最後に-uidがついているかいないかの違いです。 実際にコンテナ起動時に利用されるのは-uidがついているものになります。 なぜ2つになっているのか、1つにする設定などがあるのか？といったところが気になるところです。\nContainerの名前 devcontainer.jsonの設定を書き換えて、コンテナをリビルドすると起動したコンテナの名前が自動で割り振られているようです。 今は、fervent_hopperとなっています。ランダムにつけられているようなのですが、名前を付ける方法はないのかなぁ？と。\ndevcontainer.jsonにはnameというプロパティもあるのですが、この値がどこで使われているのかはよくわかっていません。 Remote Explorerでコンテナの一覧が見えますが、ここでは、リポジトリ名が利用されているようです。\nVolumeのIDはどこから？ devcontainer.jsonで次のような記述で、.venvのディレクトリようにDockerにボリュームを作っています。\n\u0026#34;mounts\u0026#34;: [ \u0026#34;source=venv-${devcontainerId},target=${containerWorkspaceFolder}/.venv,type=volume\u0026#34; ], 実際にコンテナでマウントされている情報を見ると\n/workspaces/search-research/.venv /var/lib/docker/volumes/venv-04emir9hi2caivtjunfe3l17452hkbb3hdut1qflbrn8n924ho5c/_data となっています。 04emir9hi2caivtjunfe3l17452hkbb3hdut1qflbrn8n924ho5cがdevcontainerIdに相当するのだとは思うのですが、誰がつけたものかなどがまだよくわかっていません。 もうちょっとわかりやすいものが使えるほうが嬉しいかも？と思っていたりします。 （複数Dev Containerを使い始めると、Docker Desktopで見ると、どのボリュームがどのDev Containerに紐づいているかがぱっと見ではわからない）\n.vscodeディレクトリどうしよう？ たぶん、VS Codeを触っている過程で、何かの設定をしてしまったのだとは思うのですが、 .vscode/settings.jsonというファイルができており、次のような内容になっています。\n{ \u0026#34;git.ignoreLimitWarning\u0026#34;: true } 何か意味があるかも？ということで、コミットしてリポジトリに入れたのですが、いらないのかもしれないなぁと。\n残作業 とりあえず、VS CodeでPython環境ができて、VS CodeのTerminalでPythonのプログラムが実行できるのはわかった段階です。 いくつか、今後調べながらやる必要があるものが残っているのでメモとして残しておきます。\nマルチコンテナ化 今回Dev Containerに対応したプロジェクトでは、検索エンジンもDockerのコンテナとして起動して、Pythonのプログラムから接続したいと思っています。 となると、docker composeでいろいろと起動するほうがネットワークなどの設定も楽になるのでは？と思っているところです。 Dev Containerのテンプレートがいくつか用意されており、その中に「Python 3 \u0026amp; PostgreSQL (postgres)」というのを見つけたので、このあたりが参考になるのでは？と考えているところです。\npre-commitではなく、保存時にフォーマット pre-commit＋localのコマンドも動くようにはなったのですが、保存時にフォーマットなどをかける設定もISIDのブログで記載がありました。 コミットしようとして、怒られるよりも、保存時に怒られたりするほうがいいかも？という気分になってきています。 どこまでが切り替え可能なのか？なども見ながら対応してみようかなと。\nもう少し開発してみて改善点を探っていく とりあえず動いたという段階です。 PyCharmとの違いがあるはずで（たとえば、git周りのGUIの違いとか）、そのあたりでどんな違いがあり、どんなものがあると嬉しいのか？といったものを調べる必要もあるかなと考えています。 TerminalでCtrl+rがうまく使えなかったり(Auto Hot Keyで検索のショートカットに割り当ててしまっているから。。。)などもあるので、この辺も調べていきたいなと。 Windows Terminalを使えたりするのかなぁ？\nまとめ さて、とりあえず、VS CodeでPythonのDev Container環境を作って動くところまでは来ました。 PyCharmを使いこなしていなかったのもあり、それほど違和感なく移行できるような気がしています。 調べることはまだまだあるし、プログラム書くつもりが、環境を整える方向に話がずれている気もしますが、まぁ面白いのでよしとするかなぁ。 いろいろまだまだ知らないことだらけです。。。\n","date":1689254123,"dir":"post/2023/","id":"a12474027c91fad5a861aa9919817d72","lang":"ja","lastmod":1689254123,"permalink":"https://blog.johtani.info/blog/2023/07/13/introduce-vs-code-and-dev-container/","publishdate":"2023-07-13T22:15:23+09:00","summary":"前回の記事で、pre-commitとPyCharmとWindowsの組み合わせで困っていることを書きました。 これについて、知り合いとチャット","tags":["python","dev container"],"title":"VS CodeとDev Containerの導入（まだ途中）"},{"contents":"最近、趣味（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書き始めました。\nきちんとPythonのプログラムをプロジェクトとして書いたことがないので、 Pythonのプロジェクトのディレクトリ構成などを手探りで進めているところです。 コードのフォーマットとかもやらないとなぁ？と知り合いのいるSlackでつぶやいたところ、gitのpre-commitフェーズでblackなどのフォーマットやスタイルを修正してくれるツールを実行する方法を教えてもらいました（PRまで送ってもらえたのでありがたい）。\nで、pre-commit周りの設定などを変えている段階で遭遇した問題点についてログを残しておこうと重いブログを書いています。 残念ながら現時点では解決してないんですけどね。。。\n手元の環境 簡単に環境を書いておくとこんな感じです。\nWindows上のPyCharmを開発で使用 プロジェクトのディレクトリはWSL2のUbuntu上 Python、gitはUbuntuのものを利用 プロジェクトのルートディレクトリにある.venvにvenvでPythonの仮想環境を作成してある 問題点 遭遇したpre-commitの問題点は次の通りです。\npre-commitの設定でrepo:localでローカルのプロジェクトにインストールしたコマンドを利用するように変更 すると、PyCharmでコミットすると、blackなどのコマンドが見つからない ターミナルでコミットするときはきちんと動作する 色々調べて試行錯誤した結果、現在はrepo:localでのローカルコマンドを使用する方法はあきらめました。 移行は、作業記録みたいなものです。どういう流れでpre-commitを取り込み、ローカルに切り替え、切り戻したかという話です。\npre-commitとpre-commit 最初に少し戸惑ったのは、pre-commitというツールとgitのpre-commitフックです。 gitのpre-commitのフックのために作られたPython製のpre-commitというツールがあります。\nこのPython製のツールを利用することで、プロジェクトに.pre-commit-config.yamlという設定ファイルを置けば設定に記述されたツールをgit commitのタイミングで実行してくれます。 実際には、pre-commitというツールの初期設定のタイミングでpre-commit installというコマンドを実行して .git/hooks/pre-commitというスクリプトが生成されます。 gitコマンドはcommitされた時に（commit前のフェーズ）でこのスクリプトを実行し、そこで.pre-commit-config.yamlが参照されています。\n.pre-commit-config.yamlの記述は次のようなものになります（最初にもらったPRより）。\nrepos: - repo: https://github.com/psf/black rev: 23.3.0 hooks: - id: black args: [\u0026#34;--line-length\u0026#34;, \u0026#34;120\u0026#34;, \u0026#34;.\u0026#34;] - repo: https://github.com/pycqa/flake8 rev: 6.0.0 hooks: - id: flake8 - repo: https://github.com/pycqa/isort rev: 5.12.0 hooks: - id: isort args: [\u0026#34;--profile\u0026#34;, \u0026#34;black\u0026#34;, \u0026#34;--filter-files\u0026#34;, \u0026#34;--multi-line\u0026#34;, \u0026#34;3\u0026#34;] - repo: https://github.com/pre-commit/mirrors-mypy rev: v1.4.1 hooks: - id: mypy 実際に、PRを取り込んで動かしてみたところ、blackなどが動いて行末のスーペースの除去や未使用のimportについて指摘をしてくれました。 便利だなと思ったのですが、ここで疑問が。\n今回は対象とするプロジェクトはpoetryで依存パッケージの管理を行っています。 今回、上記を動かすためにpoetryに追加されたものはpre-commitだけでした。 「あれ？blackとかはどこにあって、どうやって動いてるんだ？」という疑問が出てきます。 コンフィグファイルにはパスなどの記載をせず、それぞれのgithubリポジトリの記載とバージョンがあるからです。\npre-commitが使用するツールのインストール先 調べてみたところ、どうやらホームディレクトリにある.cache/pre-commitにblackなどのコマンドが見つかりました。 pre-commitツールが設定ファイルを基に、必要なコマンドをgithubからダウンロードしてきて実行時に利用しているようです。 pre-commitは便利なのだけど、せっかくPythonのプロジェクトだしそれぞれのツールはpoetryでpyproject.tomlでバージョンや設定を管理したほうがすっきりするのではないか？ということで、少し調べてみました。\n同じようなことを考えている方がブログを残していてくれました（Pythonレポジトリ用のpre-commit環境を整える）。 設定をpyproject.tomlに移行し、そのあと、ローカルのpetryでblackなどのコマンド類をインストールして利用する設定に書き換えています。 先人の肩に乗っかって、手元で同じようにpre-commitの設定ファイルのrepoをlocalに書き換えていき（その時のコミット）、ターミナルでpoetry run pre-commit run -aで動作確認できました。\nPyCharmでコミットしたらエラー ですが、実際に変更した状態でPyCharmからコミットしたら、コマンドが見つかりませんというエラーが出ます。。。 WSL2のターミナルでgit commitした場合は問題ありません。 どうして？となりますよね。。。。\n.git/hooks/pre-commitはPyCharm、ターミナルのどちらからも実行されています。 ですが、PyCharmではblackなどが見つからないというエラーが出ました。\n.git/hooks/pre-commitを見てみると、python実行するためのpythonのパスはプロジェクトにある.venv/bin/pythonを指定しています。 デバッグのために、このスクリプトにecho $PATHを差し込んで、git commitをPyCharmとターミナルからそれぞれ実行してみたところ、大きな違いがあります。\nターミナルで実行した場合は、\u0026lt;プロジェクトのディレクトリ\u0026gt;/.venv/binもPATH環境変数に存在していました。このため、.venv/binにあるblackなどを実行できています。\nPyCharmはWindowsから起動しています。プロジェクトのインタプリタとしては、WSL2のUbuntuにある.venv/bin/pythonを指定しているためもあり（？）、出力されたパスは/mnt/c/などのWindowsのパスなども入っていたりしますが、\u0026lt;プロジェクトのディレクトリ\u0026gt;/.venv/binは見つかりません。\nここからはソースコードは読んでいないので憶測ですが、.git/hooks/pre-commitで呼び出されているpre-commitツール（Python製）は、設定ファイルで指定されたコマンド（blackなど）を、コマンドとして今の呼び出されたコンテキストで実行しているのではないかということです。 実際、ターミナル上でもsource .venv/bin/activateを実行していない状態だとコマンドが見つからないというエラーが出ました。\n対処方法は？ ということで、今考えられる対処方法としては次の通りです。\n.git/hooks/pre-commitのスクリプトを修正して、\u0026lt;プロジェクトのディレクトリ\u0026gt;/.venv/binのパスを見えるようにする PyCharmで何かしらの設定を探す PyCharmではgit操作しない repo:localはあきらめて、.pre-commit-config.yamlでblackなどは管理して、pyproject.tomlからは除外する 1.ですが、.git/hooks/pre-commitはprecommit intallを実行すると自動で生成されるスクリプトです。自分の環境で書き換えたとしても他の人が同じ環境を作るときにパッチを当てるなどをしないといけなくなります。\n2.はそれらしい設定を見つけることができませんでした。\n3.はめんどくさいですよね。。。ターミナルでgitのコメントを日本語で書くためにいくつか他の設定を考えないといけないです。。。\nということで、今回は4.の対処をとりました。やりたいことは、ツールや環境をそろえるのではなく、プロジェクトでやりたいことをやることなので。。。\nまとめ 最終的には元に戻ってしまいました（pyproject.tomlに設定周りは移動した）。 Windows環境がちょっとややこしくしてるかもな？というのと、個人のプロジェクトなのでそこまで気にしなくてもいいのでは？というのもありそうです。 それにしても、世の中の皆さんはフォーマッターとかどのタイミングで動かしてるんだろう？とかどういう環境構築してるんだろう？とか気になってます。 最近だとこういうディレクトリ構造にする、こういうツールを使うと便利などあれば、コメントいただけると嬉しいです。\n教えてもらったISIDのブログ（Dev Containerを使ってステップバイステップで作るPythonアプリケーション開発環境 - ISID テックブログ）も参考にさせてもらおうと思ってるところです。Pythonの環境をコンテナに移動したいなぁというのもあるので。ただ、PyCharmだからこのブログの通りには行かないけど（VS Codeに移るのも検討したほうがいいのかなぁ）。\n参考サイト Git - Git フック pre-commit Pythonレポジトリ用のpre-commit環境を整える Dev Containerを使ってステップバイステップで作るPythonアプリケーション開発環境 - ISID テックブログ ","date":1688954148,"dir":"post/2023/","id":"698cf3cbd796161d82c9ac438ebab5d2","lang":"ja","lastmod":1688954148,"permalink":"https://blog.johtani.info/blog/2023/07/10/pre-commit-and-python/","publishdate":"2023-07-10T10:55:48+09:00","summary":"最近、趣味（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書き始めました。 きちんとPythonのプログラムをプロジェクト","tags":["python"],"title":"pre-commitとvenvとPyCharm（困ったな？）"},{"contents":"今年もこの季節がやってきました。 Berlin Buzzwordsにオンラインで出張してました。 今年もハイブリッド開催をしてくれたので、オンラインで参加できました。 現地ではブースが出たり、朝食なども用意されているようでした。今年は昨年と違いマスク必須でもなくなったようです。 MICESも去年同様、現地開催のみのようです（今見たら、昨年のビデオとスライドが公開されてるので、時間見つけてみてみよう）。\n今年はうれしいことに検索に絡むセッションが大多数でした。世の中的にChatGPTの盛り上がりやベクトル検索がいろんな検索エンジンで使えるようになってきたこともあり、 大規模言語モデルと検索エンジン、ベクトルデータベースに関する話がたくさんありました（昨年まではKafkaやストリーム処理の話も多かったんですが）。\nということで、今年もセッションを見ながら残したメモを公開しておきます。\n簡単にメモ What defines the “open” in “open AI”? セッションページ：What defines the “open” in “open AI”? 動画： Jennifer Ding - What defines the \u0026ldquo;open\u0026rdquo; in \u0026ldquo;open AI\u0026rdquo;? - YouTube \u0026ldquo;OpenAI\u0026quot;の話ではなく、オープンなAIとは？という話で、ライセンスの話であったり、コミュニティ（データセットの公開とかベンチマークの共有とか）に関する話であったり。 後半は気を抜いてしまって話をうまく聞き取れてないので、興味がある方はビデオで。。。\nVectorize Your Open Source Search Engine セッションページ：Vectorize Your Open Source Search Engine 動画： Atita Arora - Vectorize Your Open Source Search Engine - YouTube ベクトル検索が流行ってきてるけど、これまでの検索（エンジン）に対して、どうやってベクトル検索を取り入れる？という話です。 ベクトル検索ってどんなもので、どういうことの助けになりそうか？じゃあ、どうやって、これまでの検索が改善したかを見ていくのか？ という、これからベクトル検索を取り入れようとしている時にどのようなアーキテクチャにして、 どのような考慮するポイント（モデルの選択とかスケーラビリティとか）にどんなものがあるのか？といった紹介でした。 ざっくりですが、ベクトル検索やるのにどんなことをやっていけばよいのか？という地図になるようなセッションでした。\nSupercharging your transformers with synthetic query generation and lexical search セッションページ： Supercharging your transformers with synthetic query generation and lexical search 動画： Milind Shyani - Supercharging your transformers with synthetic query generation and lexical search - YouTube AWSの人の話でした。こちらもトランスフォーマーが検索に使えると便利だよねという話なのですが。 LLMを使うと高コストでサイズがどんどん大きくなっていて、小さな学習済みのモデルだといまいちな精度でだし、 ファインチューニングしたい場合、ドメインに特化したデータはなかなかないよね。とくにデータ（検索したいもの）はあるけど、クエリがないということがよくあるよね。 そこで、LLMを使って、データからクエリを作って、正解データを作り、それでファインチューニングすればいいのでは？ ということで、やってみました、どうでしたという話でした。\nブログなどもあるので参考にすると面白いかも\nThe Debate Returns (with more vectors) Which Search Engine? セッションページ：The Debate Returns (with more vectors) Which Search Engine? 動画：Charlie Hull - The Debate Returns (with more vectors) Which Search Engine? - YouTube 今年も検索エンジンの人を集めてパネルディスカッションです。今年は次の方たちが参加してディスカッションでした。\n参加者 Jo：Vespaの人。ランキングとかがよくできてるからVespa好き Alessandro：Apache Solrの人。SolrのPMCメンバー。なんでSolr？Pure OSSだし。スケーラブルだ Etienne：Weaviateの人。新しいAI nativeなベクトルデータベース Philipp：Elasticの人。 Kacper：Qdrantの人。 質問は次のようなものでした。\n最初の質問：スケールの話。スケールアウトかな？ 2つ目の質問：どんなアプリケーションが適していないか？ 3つ目の質問：どうやってAIをサポートできるの？ 4つ目の質問：どうやってコミュニティにアプローチしてる？ 5つ目の質問：自分の検索エンジンが使えない時に何を使う？ 6つ目の質問：今後に何が面白そう？ 最後の質問：あなたの検索エンジンが使われてるユースケースで一番好きなものは？ 2つ目や5つ目の質問が面白いですよね。実際の内容はぜひビデオを見ていただくのがいいかと（メモも取ったけど、聞いてもらうほうが面白そうだし）。\nWhat\u0026rsquo;s coming next with Apache Lucene? セッションページ：What\u0026rsquo;s coming next with Apache Lucene? 動画：Uwe Schindler - What\u0026rsquo;s coming next with Apache Lucene? - YouTube 毎年恒例Uweさん。今年Luceneが25周年という話で、これまでの進化の話を駆け足でしてくれました。 あとは、後半は来週9.7が出るよということで、9.7で入ってくるベクトルの距離計算の最適化に関して説明してくれています。 次のバージョンのElasticsearchでもこの最適化が使えるようになるという話もされていましたので、ベクトル検索を使ってる方は、次のバージョンも楽しみですね。\nBuilding MLOps Infrastructure at Japan\u0026rsquo;s Largest C2C E-Commerce Site セッションページ：Building MLOps Infrastructure at Japan\u0026rsquo;s Largest C2C E-Commerce Site 動画：Berlin Buzzwords 2023： Building MLOps Infrastructure at Japan\u0026rsquo;s Largest C2C E-Commerce Site - YouTube メルカリの検索システムに関係しているMLOps周りがどうやって進化してきたのか？という話でした。 英語にいらすとやの絵があるスライドがドイツで使われているのがとても新鮮ですｗ\nHighly Available Search at Shopify セッションページ：Highly Available Search at Shopify 動画：Khosrow Ebrahimpour - Highly Available Search at Shopify - YouTube Shopifyの検索プラットフォームチームの人の、Shopifyの検索プラットフォームがどういったものか？（EsとKafka使ってる）どんな工夫をしているか？という話です。 Kubeconでも他の同僚の方が話をされている見たいで、そちらも参考になるとのことでした（動画）。 スキーマ変更時の話とかもあり、実践的でした。最後に将来的な話でやはりベクトル検索というキーワードが出てきていました。あとは、データ量が大きいのでスケーリングの挑戦もあるとのこと。\nUsing Dense Vector search at the EU Publications Office セッションページ：Using Dense Vector search at the EU Publications Office 動画：Martin Bayton - Using Dense Vector search at the EU Publications Office - YouTube EUのPublication Office（日本だと公文書館とかになるのかなぁ？）の検索サービスで、Googleみたいなこと（検索結果の上にスニペットが出たり、そこにハイライトされたり）をやってみたいよね？という話みたいでした。実際公開してるかはわからないですが、途中からはPureinsightsという会社のプラットフォームで似たようなことをやるデモになってました。\nGoogleでも12%のクエリが、質問の自然文になっているという話で、検索結果にナレッジグラフからの情報（スニペットとか、質問に対する答えとか、地図とか）が出るようになってきていますと。 それをPublication Officeのデータで再現したデモを行った後に、どんな感じのアーキテクチャなのか？という概略を説明されています。国会図書館とかの検索サービスやってる方が興味を持ったりするかもなーと思ったり、思わなかったり？\nLearning to hybrid search セッションページ：Learning to hybrid search 動画：Berlin Buzzwords 2023： Learning to hybrid search - YouTube これまたキーワード検索とセマンティック検索のハイブリッドの話です。 よくハイブリッド検索というのを聞きますが、データだったりベンチマークなどの話があまりないですよね？昨年AmazonがECSIというデータセットを公開したりしています（rejasupotaroさんが年末に書かれた記事にも出てきていました）。 これにLearn to Rankとかもテストできるようなデータ（レビューや評価、カテゴリーとか）を拡張したものを作って、それをもとにいろいろとハイブリッド検索で精度を測ってみたというお話でした。 Metarankというリランキングエンジンの会社の方たちで、Metarankを使ってハイブリッドな検索結果のリランキングで精度がどのように上げられるか？という話です。 今年のTRECのProduct Search Trackの話もされていました。 これが元ネタのブログかな？\nCatch the fraud — with observability and analytics セッションページ：Catch the fraud — with observability and analytics 動画：まだ？ 最後は元同僚のセッションです。こちらは検索ではなく、ちょっと自虐的なネタをもとにしたオブザバビリティおよび分析のお話です。 コミュニティの人たちの貢献（ブログ書いたりプルリク送ったり、どこかで話をしたり）を計測して、年間の貢献者に対してプレゼントを上げるというのをやっているみたいです。 で、昨年の最も貢献した人にMac Bookをプレゼントするというすばらしい（暴挙）話で、チートしようとした人がいてそれを分析した話でしたｗ 締め切り直前に信じられない量の貢献したという登録がブラジルからあり、何かおかしいよね？ということで、Elastic Stackのオブザバビリティの機能などを元に分析してチートした人を除外していったよという話でした。 Kibanaが使いやすくなってるのがわかるセッションで面白かったです。\nまとめ 検索がまたすごく盛り上がってきたなーという時間があるカンファレンスでした。みんな似たような話（ベクトル検索、LLM、AIなど）だったりしますが、 知らないプロダクトで興味が出てくるものもあったし、Amazonのデータセットがあるからいろいろ試してみることもできそうだなぁと。\nすでにビデオが公開されはじめているので、気になったセッションのビデオも見てから後日またブログを書こうとおもいます （たぶん、一覧が作成されるので後日リンクを貼っておきます）。\n来年の予定（6月11日から開催）も公開されていましたし。来年も楽しみですね。 来年はプロダクションでベクトル検索やってみた話とかがさらに出てくるのかなぁ？\n","date":1687278645,"dir":"post/2023/","id":"9335522f4c8dbc7256a42a091e6e00bc","lang":"ja","lastmod":1687278645,"permalink":"https://blog.johtani.info/blog/2023/06/21/attend-berlin-buzzwords-2023/","publishdate":"2023-06-21T01:30:45+09:00","summary":"今年もこの季節がやってきました。 Berlin Buzzwordsにオンラインで出張してました。 今年もハイブリッド開催をしてくれたので、オンラインで参加で","tags":["conference","belin buzzwords"],"title":"今年もオンラインでBerlin Buzzwordsに参加した"},{"contents":"今年もなんとか振り返りブログを書いてます（時間大丈夫かな？w）。紅白をリアタイで見ながら。\n振り返り（2021年に書いた抱負から） まずは振り返りをと。\nフリーランス継続 ありがたいことに個人事業主として今年も１年乗り越えられました。 ZOZOさんには引き続きお世話になっている感じです。 10月からは今月末まで別のお客さんを手伝っていたりという感じでした（アップグレードの手伝いとか）。 相変わらず完全リモートで作業をさせていただいてます。\nただ、来年は今の所、余力がある感じになっているので、新しい仕事を見つけたいところだなあという感じです。 検索で何かお手伝いできることあれば、気軽にお声がけいただければと。\nプログラミング Linderaの大須賀さんのおかげで、レビューは定期的にやらせていただいてますw 業務がっつりというほどではないのですが、検証用のコードを書いたりはしています。\n個人用では、BGM環境のためにシェルを書いたり、文字化けしてるデータを解析したりするのにコードを書いてますが、もうちょっと量を増やしたいところです。 コードがっつり書く仕事をやらせてもらうのとかやらせてもらうのがいいかもなぁ。\n書くよりもどうしても読むほうが多くなってる気がします。\nブッチャー本ちゃんと読む 全部ではないですが、ZOZOさんで輪読をしたりしていました。 が、自分で全部読むといったところまではできてないです。\n読んだ本のブログを書く これはできてないですね。 読むのはちょとちゃってるんですが、ブログを書くところまではできてない。 メモとりながら読みたいですね。\n振り返り(今年あったできごと) ここからは今年の出来事を。 今年もずっと自宅で仕事した。来年は出張とかできるのかなあ？\n自宅環境 今年もDIY 検索ペンギン本が出版された 仕事場を模様替えしました。 今年もずっとWindows環境をメインで仕事をしていました。 年末まではM1 Macを借りて作業するという経験もできたのでよかったです。 今年仕事の環境は少し変わって、AVアンプ（譲り受けたもの）＋Polk Audioのスピーカーで音が良くなりましたw あと、机の天板を大きくして、作業がやりやすくなりました。写真はそのうち。\n仕事場の模様替えにもなるのですが、今年のDIYはラブリコ＋有孔ボードでケーブルやキーボードをすっきり片付けられる環境を作ってみました。 壁を有効活用できるのはよかったです。こちらについては、別途ブログを書こうと思います。\n今年最大のニュースは検索ペンギン本を出版したことです。 声をかけていただいた打田さんには感謝です。著者の皆さん検索システムを色々と手掛けられているので良い本になったと思います。\n『検索システム ― 実務者のための開発改善ガイドブック』 – 技術書出版と販売のラムダノート おー、届いたー pic.twitter.com/RbY5tOe9GB\n\u0026mdash; Jun Ohtani (@johtani) May 17, 2022 いろんなところで輪読も開催されているようで、顔を出してみたいなぁ。 輪読やってます！外部の人を呼んでもOKという方がいたら、参加してみたいのでTwitterでメンションしてもらえると嬉しいです。\n来年の抱負 ということで、来年の抱負です。\nフリーランス継続 プログラミング ベクトル検索まわりをさわる 本を読む 今年もありがたいことに仕事を継続していただけて、乗り越えられました。 来年も価値を提供できるように頑張っていきます。 もっといろんな会社の検索システムを見てみたいですし、検索エンジン入れてみたけどここからどうすればいい？という方も増えて来ているような気がするので、気軽に声をかけていただければと。\nプログラミングは、家の音楽ファイルの文字化けを直すプログラムをもう少しちゃんと書いてからブログを書きたいなと。まぁ、個人的なプログラムなので誰も嬉しくないかもですが（色々検討した結果Javaで書いてる）。 あとは、オライリーさんの初めてのGo言語を買ったのもあるので、前にRustで書いたElasticsearchへのBulk登録のツールをGoで書いてみようかなと考えているところです。みんなはデータ登録するときはどうしてるんだろう？\nNLPでBERTなどによる目まぐるしい進歩の影響もあり、ベクトル検索やセマンティック検索といった検索技術が各社から出て来ています。 ElasticsearchでもGAされたのもあり、今後ますます注目を浴びる技術になるのだろうなと。 ただ、これまでの検索とどう組み合わせるのがいいのか？どう言ったメリットデメリットがあるのか？向き不向きは？といったものもあるので、仕組みを調べながら色々と試行錯誤してみたいと思っています。\nさいごは、毎年書いてる気もしますが、本を読むのもやらんとなぁ。 あたらしいネタを仕入れては実践できる時間もとりつつ、他のことにも目を向けたいと思っています。\n今年は仕事の変化も少し出て来ているので、来年は新しいことをいくつかやってみたいところです。 あとは、外に出る機会が増やせるといいなぁ、少しずつ人から刺激をもらいたいと思っています。\nさて、今年は年内に無事描き終わりました。 来年もよろしくお願いいたします、良い年にしたいなー。\n","date":1672486684,"dir":"post/2022/","id":"df30d810068e4656498e5972c6de7e3d","lang":"ja","lastmod":1672486684,"permalink":"https://blog.johtani.info/blog/2022/12/31/review-2022/","publishdate":"2022-12-31T20:38:04+09:00","summary":"今年もなんとか振り返りブログを書いてます（時間大丈夫かな？w）。紅白をリアタイで見ながら。 振り返り（2021年に書いた抱負から） まずは振り返","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2022）"},{"contents":"PySpaアドベントカレンダーの12/15のエントリーです。昨日はtaichiさんでした。 今年はDIYではなく、PCにまつわる話を。\n仕事中はBGMが基本 フリーランスを始めて（2020年初頭）からすぐに、自宅で仕事をする情勢になりました。 打合せをしていないとき、カンファレンスの発表などの動画を見ていないときは基本的にBGMをかけて作業をしています。 音源としては、CDなどから音楽ファイルにしたり、AmazonやSonyのサイトで購入した音楽ファイルなどがNASにあります。\n今年10月までの環境 2020年の後半に次のような環境を構築して今年の10月まで使っていました。\nLibreELECをラズパイ4に入れて、Kodiのリモコンをスマホに入れたら快適になった\n\u0026mdash; Jun Ohtani (@johtani) October 20, 2020 KODIと呼ばれるマルチメディアセンター？のようなソフトで、それを動かす最小限のOSとして、LibreELECが公開されています。 これをラズパイ4に入れて、NASからファイルをSSDにコピーしてそれをラズパイに接続して音楽を聞いていました。 毎回ラズパイの画面を見に行くのも面倒なので、再生などの操作にはAndroid用のKodiのリモコンアプリを使っていました。\n場所も取らないのでよかったのですが、使っているといくつか問題点が。\n時々調子悪（音が出ない、リモコンからつながらない、無反応など）くなって、ラズパイ再起動 音楽ファイルを購入して増えた時に、外付けSSDを取り外してPCでコピーしたり スマホじゃないと再生できない（PCのクライアントもあったのかもだけど調べてなかった） Ubuntu on Mac mini 10月に模様替えをして、2012年製のMac Miniが宙ぶらりんになりました。 さすがに古いしメインマシンがWindowsになっているのもあり、macOSである必要も特にないので、Ubuntu 22.04を入れて何かに使えるのでは？と。 また、1TBのSSDに内臓ディスクを乗せ換えていたのもあり、音楽再生に使ってみようということに。 なので、Kodiの環境で困っていた点も考慮して、ほしい機能を元にちょっと探してみました。\n音楽再生 on Ubuntu 音楽再生でほしい要件としては次のようなものです。\nUbuntuで音楽再生できるソフト（あたりまえ） PCから操作したい（できればブラウザ） 音楽ファイルの更新（ローカルでもいいけどNASからもってきたり） 日本語の曲情報も表示 対象音楽ファイルが豊富（そんなに制限があるものはないだろうなぁ） 上記の要件をもとに適当にググって見つけてきたのがOwnToneというソフトでした。\nOwnTone OwnToneの説明は公式サイトを見ていただくとして、OwnToneにしてよかったなというのが以下の点です。\nインストールが簡単（apt-getでインストールできる） サポートフォーマットが豊富 Web UIがついてる（ブラウザで見えるし、スマホでもOK。どのブラウザから見ても今の状況も分かる） 簡単だけど検索できる プレイリスト対応（ファイルパスを入れるだけ） サムネイルとかも出てくる（どうやってんだろう？ｗ） AirPlayで再生できる（AVアンプを利用しており、そこにAirPlayで再生できてる） OSS（まだソースは見たことないですがｗ） 再生画面例\nやっぱ検索も気になるよね？\n日本語も検索できるな。 pic.twitter.com/EF6WHkJKli\n\u0026mdash; Jun Ohtani (@johtani) October 19, 2022 とりあえず、インストールして画面もすぐに出て操作も簡単で、便利な世の中になったなーと感動しましたｗ\nただ、音がヘッドフォン端子に刺したアナログ出力先のスピーカーではなく、本体のスピーカーで最初はなってしまいましたｗｗ Linuxの音周りが全然わかってない問題が発覚。\n幸い、先週のPyspa Advent Calendarのエントリーを書いていたaodag先生に助言をいただき、alsamixerで音の設定を見たところ、ヘッドフォン端子がミュートされていたので、ミュートを外して無事再生できました。 インストール当初はYAMAHAのアクティブスピーカーにJust Mixer経由でヘッドフォン端子（アナログ）で出力して音楽再生をしていました。 今は（この記事を書いてる現時点で）、AVアンプのAirPlayにOwnToneから音を流している形で聞いています（便利なんだけど、当初の想定とは異なる、理由は後述）。\nファイルのコピーとか さて、上にも書きましたが、NASにバックアップもかねて音楽ファイルを保存してあります。 新しく買ったファイルもここに置くようになっています。 OwnToneのMac MiniからNASをネットワーク経由で見に行くのもいいのですが、できればローカルにあったほうがネットに影響も出ないなと。\nということで、定期的にNASをウォッチしてMac Miniにファイルをコピーするようなプログラム（Bashスクリプト）を書いてみました。 毎回購入後に手で実行もめんどくさいので毎日夜中にcron実行するような設定になっています。\nスクリプトの中身は次のような感じです。\nfindコマンドで特定の日時（最近コピーしたファイルの日付）以降(-newermtオプション)のファイルのリスト（音楽ファイルの拡張子に限定）を取得 取得したリストをもとに以下の操作 ファイルをコピー コピーしたファイルをコピーした日付のプレイリストを作って入れる（プレイリストはパスだけ書けばOK） mp4形式だと聞けない端末もあるので、soundconverterコマンドでmp3に変換してNASに戻す 最新のファイルの日付を保存（次回のfindコマンド） ファイルがあったら、OwnToneの再読み込みのエンドポイントをcurlでキック NASはSambaでマウントして、見えるようにしてあります。 やっぱり、自動化便利ですねぇ。 気に入った曲を買ってNASに入れとけば聞けるようになるのは本当に便利。\n他にもスマートプレイリストとかもあるので、活用しないとな。\n今後の課題 さて、すごく便利になったのですが、課題も残っています。\n音声出力問題 アナログ出力はaodag先生の助言ですぐに解決したのですが、takabowから譲り受けたAVアンプを導入してから実は音の出力がうまくいっていません。\nHDMI、光端子出力でAVアンプにつなごうとしたのですが、私のUbuntu力（Linux力？）が全然不足しているのでうまくいっていません。ググりつつ、HDMI、光出力でamixerというコマンドで音声ファイルを鳴らすところまでは行ったのですが、OwnToneに設定するとうまくいかない状況です。 結局、解決してないのですが、AVアンプのAirPlayのレシーバー経由で音楽再生ができてしまったので、とりあえずAirPlayで運用することにしました。時間を見つけてaodag先生の記事を読み直して再チャレンジしないとな（けど、鳴ってるしなぁ、音ｗ）。\n文字化け問題 これは、OwnToneというよりはもともとあった問題です。 古い音楽ファイルだったり、Wav形式のファイルなど、様々な形式のファイルを持っています。 音楽サーバーとは別に、音楽ファイルの検索をできるようにしつつ、付加的な情報（Wikimediaなどのデータとか）を付与して、検索できるようにしてみようと思い、音楽ファイルからメタデータを抜き出して、ElasticのApp Searchにいれるデータを作るツールを書いたりしています。 この時にも文字化けに遭遇しました。\n様々な音楽ファイルにはメタデータを付与することができる仕様が決まっています（ID3タグ - Wikipediaなど）。 ただ、文字コードの情報が入っていなかったり、デフォルトとは違う文字コードでデータを付与したファイルがあったり、いろいろな原因で文字化けしているものがあります。 昨年Amazonで購入したmp3の中にも文字化けしているものもあったりします。Wavファイルに付与されたタグなどは、容赦なくShift-JISだったりしますが、読み込むソフトはUTF-8で読もうとしたり。。。\n検索サーバーにデータを抜き出して入れるツールを書いているときは、元のファイルを変更することなく、抜き出す時点でいくつかの文字化けに対応した処理を書いたのですが、今回のOwnToneで曲を流すと結局、元のファイルをきれいにしないとダメだということに気づきました（すぐわかるだろ。。。）\nということで、書いている途中のツールをもとに、根本的な文字化けのファイルのメタデータをきれいにするプログラムを書かないといけないなぁと。\nちなみに、メタデータの抜き出しにはJavaでプログラムを書いており、JAudiotaggerというライブラリを利用しています。 Pythonや他のJavaのライブラリを試そうとしたのですが、文字コードが決め打ちで抜かれているものが多く、ライブラリから読みだした時点ですでにどうしようもない状態のものが多いといった問題からこのライブラリにたどり着きました（まぁ、まだちゃんとしたものができていないんですけどね）。\n検索サーバー OwnToneのUIはブラウザでうごきます。 検索窓もついています。 が、先ほども書いたように、他にもデータを追加して、いろんな検索をしてみたいなぁと（ドラマに使われてたとか、CMにつかわれてたとかとか）。 検索が好きでいろいろとやってるので、その辺も遊んでみたいなぁと思っているところです（実際、ElasticのApp SearchにWikidataから生成した類義語を入れてみたりしている）。\nこうやってブログにしてしまったので、課題をつぶしていなかったら、Twitterなどでつついてくださいｗ\nまとめ 構成図とかは書かなかったですが、OwnToneを使うと簡単にWeb UIが入った音楽サーバーが使えるようになって、仕事がはかどりますよという記事でした。 他にもこれに関するネタを募集してますので、コメントもらえるとうれしいです（Twitterでメンションも大歓迎）。\n","date":1671030358,"dir":"post/2022/","id":"67c2ae6761e89be0fa66db9623b40d30","lang":"ja","lastmod":1671030358,"permalink":"https://blog.johtani.info/blog/2022/12/15/music-server-on-mac-mini/","publishdate":"2022-12-15T00:05:58+09:00","summary":"PySpaアドベントカレンダーの12/15のエントリーです。昨日はtaichiさんでした。 今年はDIYではなく、PCにまつわる話を。 仕事中は","tags":["misc","music"],"title":"仕事中のBGM環境"},{"contents":"本記事は情報検索・検索技術 Advent Calendar 2022の9日目の記事です。\nだいぶ間が空いてしまいましたが、日本語のオートコンプリートに関する記事の続きです。 という感じで、Suggesterのデータ構造とか仕組みを書こうと思っていたのですが、思ったよりも調べないといけないことが多くて挫折しました。。。 （これの続きは年末年始で調べて書くはず？）\nということで、代わりにElasticsearch/OpenSearchのアーキテクチャの変更に関してさらっとまとめてお茶を濁してみようと思います。\n発端はElasticON Tokyo？ 先週の11月30日に、ElasticのオフラインイベントであるElasticON Tokyoが開催され参加しました。 参加しようと思ったのは、10月の頭にElasticのブログで公開された「Stateless — your new state of find with Elasticsearch」というアーキテクチャの変更がきっかけです。\n（図はElasticのブログから引用）\nElasticsearchはLuceneのインデックスを分散したシステムとしてスケールアウトできるようにするという目的でリリースされました。 インデックスをシャードという単位で複数のElasticsearchのノードにデータを保存し、レプリカを作ることで分散する仕組みを実装していました。 Elasticsearchでは、インデックスのレプリカは、作成したインデックスを定期的にコピーするのではなく、登録するデータがElasticsearchのクラスターにやってきた時に、 データ自体をコピー先にも配り、プライマリーやレプリカとなるシャードがあるノード上でそれぞれインデックスに登録する処理を行うという処理の流れです（古いけど、わかりやすい説明はこちら）。 この場合、インデックスにデータを登録する処理（転置インデックスのデータ構造に変換する処理など）は、レプリカの数だけ同じ処理がクラスター上で発生します。\nこの基本的なアーキテクチャをもとに、保持するデータの鮮度（新しいデータのほうが検索頻度が高い、インデックス登録する時はマシンは多く、古くなったデータが入ったインデックスはコストが低いマシンになど）などを元に、クラスター内のノードの特性を異なるものが混在するような複雑な仕組みを作ってきました。 いろいろなデータの持ち方などで多くのデータなどを保持できるようにしてきたのですが、クラスター全体としては、検索の負荷のピークをさばけるような構成を基本的に保持しておくというかんがえです。\nただ、昨今は必要に応じてスケールアウト（リクエストが増えたりデータ量が増えた時）、スケールイン（夜中は利用者が少ないからクラスターを小さくしたい時）できるような仕組みのほうが求められています。 そこで、発表されたのが上記のブログであり、上図の新しいアーキテクチャです。 計算処理（データを登録、検索する処理）とストレージを分離し、さらに登録する処理と検索する処理も分離した構成です。 このようなアーキテクチャにすることで、登録処理の演算コストがレプリカごとに必要ではなくなり、検索の部分だけだったり、登録の部分だけをスケールアウト・インできるような自由度が手に入ります。 また、ストレージ部分でレプリカを担保（S3とかのオブジェクトストレージで冗長性を担保）できれば、レプリカのストレージコストも必要なくなります。\nというブログが発表されたのですが、詳細などはまだよくわからなかったのでElasticON Tokyoに参加して詳しい話が聞けるのかなぁと期待していました。\n参加当日の朝のびっくりするニュース 11月30日の朝に起きて、出かけようかと思っていたところに、AWSのre:Inventで発表されたニュースが舞い込んできました。\nほー（まだタイトルしか読んでない）https://t.co/KK22duaBNH\n\u0026mdash; Jun Ohtani (@johtani) November 29, 2022 Amazon OpenSearchがServerlessオプションを発表というニュースです。 （Amazon OpenSearchとは、AWSがElasticsearchをフォークして始めた検索エンジンで、Amazon OpenSearch Serviceというのは、AWSがそれをSaaSとして提供しているものです）\nまぁ、気になりますよね、「Serverless」ってキーワードに。 ElasticON Tokyoに向かう電車でブログを読んだり、どんな仕組みかを調べたので、それを簡単にまとめておきます。\nプレビュー段階（Tokyoリージョンではもう試せる） これまでのAmazon OpenSearch Serviceとは別（オンザフライで移行はできない？） 「コレクション」という単位でクラスターを管理（スケールインとかアウトとか） コレクションにはタイプがあり、タイムシリーズ（ログとか）か検索のユースケースなのかで使い分ける（公式ドキュメント） インデックス処理と検索処理で計算ユニット（OCU）が別々にスケールできる（下図） 作成されたインデックスはAmazon S3に保存され、そこで冗長性は担保される。（下図） 検索処理のユニットはS3のデータをローカルに持ってきて処理をできる データ登録とかのAPIは基本的にServerlessかどうかで違いはなさそう(これまで通りのクライアントでアクセスとかで競う) 設定した範囲でいいかんじにスケールアウトインしてくれそう（ほんとかな？） もちろん、いくつか制限がある（サポートしてないプラグインとか操作もある） （図はAWSのドキュメントより引用）\n発表時のブログでは詳しくはわからないのですが、公式ドキュメントではさらに詳しく説明がありました。 こちらを読むほうが仕組みがわかると思います。 今後もどんどんドキュメントは充実していくんだろうなと。今ならまだサクッと読める量ですｗ\nただ、「サーバーレス」という定義が私はよくわかりませんでした。 公式ドキュメントを読むとコレクションを作ると少なくとも4つのOCUが起動しているみたいで課金されると記載があります。\nまぁ、Elasticの発表と同様に、これまでは最大負荷の時を元にクラスターを維持せずとも、より柔軟に検索だけ、登録処理だけを一時的にスケールできるとコストを下げられそうですね。 すぐに誰かが使ってみたブログなどを出してくれると思うので、細かな使用感などはそのうちわかってくるかと。\n今後は？ ElasticもAWSも考え方の基本となっているのは、Berlin BuzzwordsでAmazonのMikeさん（Luceneのコミッター）が2019年に発表されたものだと思っています。 アーキテクチャの変更がどんな影響が出るかはわからないですが、少なくとも検索のユースケースでよりスケールアウトしやすくなるだろうなと。 どちらもSaaSとしての仕組みとして提供するので、検索エンジンそのものの機能として公開されるかはわからないです。 ですが、そのほかの検索エンジンも出てきていますし、今後も検索エンジンから目をはなせないです。 今回は残念ながら触っていませんが、時間を見つけて使ってみたいです（Elasticも早く出してくれないかなー）\nということで、当初の予定とは違うブログになってしまいました。。。 技術的な深い話はまたどこかで。。。\n参考文献 Stateless — your new state of find with Elasticsearch | Elastic Blog Preview： Amazon OpenSearch Serverless – Run Search and Analytics Workloads without Managing Clusters | AWS News Blog Berlin Buzzwords 2019： Michael Sokolov \u0026amp; Mike McCandless–E-Commerce search at scale on Apache Lucene - YouTube ","date":1670516125,"dir":"post/2022/","id":"9693a1e77dee5785b1dc61ccffd2e906","lang":"ja","lastmod":1670516125,"permalink":"https://blog.johtani.info/blog/2022/12/09/open-search-serverless/","publishdate":"2022-12-09T01:15:25+09:00","summary":"本記事は情報検索・検索技術 Advent Calendar 2022の9日目の記事です。 だいぶ間が空いてしまいましたが、日本語のオートコンプリートに関する記事の続きです。","tags":["elasticsearch","opensearch"],"title":"ElasticsearchのアーキテクチャとStateless / Serverless"},{"contents":"前回は日本語用オートコンプリートのためのAnalyzerとして、どうやって使うのかを簡単に紹介しました。\n今回はもう少し、いろんなパターンを試してみたいと思います。\nローマ字入力のゆれ 前回のサンプルでも「吾輩\u0026hellip;」のデータをサジェストするためのサンプルとして、「wagah」という「わがはい」をローマ字にしたものを利用しました。\nちなみにローマ字というとどんなものを思い起こしますか？ 普通は学校で習ったヘボン式あたりだと思います。 Kuromojiの読みでローマ字出力するには通常、kuromoji_readingformでuse_romajiをtrueにします。 以下、「吾輩」のサンプルです。\nGET _analyze { \u0026#34;text\u0026#34;: [\u0026#34;吾輩\u0026#34;], \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji_tokenizer\u0026#34;, \u0026#34;filter\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;kuromoji_readingform\u0026#34;, \u0026#34;use_romaji\u0026#34;: true } ] } レスポンス { \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;wagahai\u0026#34;, \u0026#34;start_offset\u0026#34;: 0, \u0026#34;end_offset\u0026#34;: 2, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 0 } ] } 「吾輩」の場合は特に問題ないのですが、ローマ字による日本語入力の場合、次のような単語を入力するときに、ゆれが生じます。\nシャボン＝「shabon」 新橋＝「shimbashi」 括弧内はkuromoji_readingformで出力したもの（＝ヘボン式のローマ字）です。 ですが、ローマ字入力の場合は「syabon」や「shabon」と入力したり、「sinbasi」や「sinnbasi」と入力すると思います。 JapaneseCompletionAnalyzerを利用したCompletion Suggesterの場合、これらのゆれも考慮してサジェストしてくれるようになっています。 前回のサンプルデータを用いると次のような感じです。\nGET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;sha\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } } } GET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;sya\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } } } これらのリクエストは、「しゃ」について2パターンになっていますが、結果はどちらも次のものが返ってきます（このレスはsyaのレスになります）。\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;sya\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 3, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;シャドウ・ワーク\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;000739\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;シャドウ・ワーク\u0026#34;, \u0026#34;朝倉 克彦\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;シャボン玉\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;045054\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;シャボン玉\u0026#34;, \u0026#34;豊島 与志雄\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;上海\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;050899\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;上海\u0026#34;, \u0026#34;横光 利一\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;斜坑\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;002095\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;斜坑\u0026#34;, \u0026#34;夢野 久作\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;社会事情と科学的精神\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;053864\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;社会事情と科学的精神\u0026#34;, \u0026#34;石原 純\u0026#34; ] } } ] } ] } } 「sinnba」や「shinba」も試してみました。\nGET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;sinnba\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } }, \u0026#34;_source\u0026#34;: [\u0026#34;suggest_ja\u0026#34;] } GET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;shinba\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } }, \u0026#34;_source\u0026#34;: [\u0026#34;suggest_ja\u0026#34;] } これらも同じ結果です。\n{ \u0026#34;took\u0026#34;: 0, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;shinba\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 6, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;しんばい\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;044942\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;しんばい\u0026#34;, \u0026#34;村山 籌子\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;新橋\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;002409\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;新橋\u0026#34;, \u0026#34;北原 白秋\u0026#34; ] } } ] } ] } } 入力されるパターンを想定した実装がされているので対応できている形です。 使い方が楽なだけでなく、より使いやすくなってるのは便利ですね。\nうまくいかないパターン 万事OKかというと残念ながらそうでもありません。 うまくいかないパターンもあります（これが本当にうまくいかないかは難しい話な気がしますが）。 「日本」という漢字ですが、「にほん」「にっぽん」どちらとも読めますよね？ これらを試してみると次のようになります（リクエストは省略します）。\nまず「にほん」\n{ \u0026#34;took\u0026#34;: 0, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;にほん\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 3, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;日本橋\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;004565\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本橋\u0026#34;, \u0026#34;泉 鏡花\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本橋\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;045357\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本橋\u0026#34;, \u0026#34;牧野 信一\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本橋あたり\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;047648\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本橋あたり\u0026#34;, \u0026#34;長谷川 時雨\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本橋附近\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;055666\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本橋附近\u0026#34;, \u0026#34;田山 花袋\u0026#34; ] } } ] } ] } } 次に「にっぽん」\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;にっぽん\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 4, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;日本アルプスの五仙境\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;056269\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本アルプスの五仙境\u0026#34;, \u0026#34;木暮 理太郎\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本出版協会論\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;049436\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本出版協会論\u0026#34;, \u0026#34;嶋中 雄作\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化と科学的思想\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;055750\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化と科学的思想\u0026#34;, \u0026#34;石原 純\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化のために\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;003183\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化のために\u0026#34;, \u0026#34;宮本 百合子\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化の特殊性\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;055290\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化の特殊性\u0026#34;, \u0026#34;戸坂 潤\u0026#34; ] } } ] } ] } } 最後に「日本」\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;日本\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 2, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;日本アルプスの五仙境\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;056269\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本アルプスの五仙境\u0026#34;, \u0026#34;木暮 理太郎\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本出版協会論\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;049436\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本出版協会論\u0026#34;, \u0026#34;嶋中 雄作\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化とは何ぞや（其二）\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;002940\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化とは何ぞや（其二）\u0026#34;, \u0026#34;内藤 湖南\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化と科学的思想\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;055750\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化と科学的思想\u0026#34;, \u0026#34;石原 純\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化のために\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;003183\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化のために\u0026#34;, \u0026#34;宮本 百合子\u0026#34; ] } } ] } ] } } 最初の「にほん」は「日本橋」がヒットしているようです。返ってきたoptionsの数は4件しかなく、どうやらこれがすべてのようです（取得件数はデフォルト5件）。 2番目の「にっぽん」は「日本」という単語から始まるものがヒットしていますが、「日本橋」はなさそうでした。 最後に「日本」という漢字を入力にした場合は2つの合計が帰ってきているようです（今回のレスポンス例にはありませんが、サイズを大きくすると「日本橋」が帰ってきていました）。\nどうしてそうなるの？ JapaneseCompletionAnalyzerの基本的な動作としては、\nKuromojiが単語に区切る 区切られた単語ごとに読みを持っている 元の単語と読みをローマ字にしたものが最終的に出てくる というような動きです。 この時、単語には「1つ」の読みが対応しています。 読みから単語を探そうとすると、読みの違い（ゆれ）を吸収することはできないためです。 JapaneseCompletionAanlyzerは3点目のローマ字のゆれに対応していますが、入力となる読みのゆれまでは対応できないです。 対応しているといいかどうかというのも難しい判断になる気もします。。。\nそのほかの例としては次のようなものもあります。 これは、今回のオートコンプリートの話とは少しずれてるかもしれませんが、1番目の処理の結果が変わってくる例です。 「南方熊楠」という名前の間にスペースがあるかないかで、出力される読みが変わってくる例です。\nGET _analyze { \u0026#34;text\u0026#34;: [\u0026#34;南方 熊楠\u0026#34;], \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji_tokenizer\u0026#34;, \u0026#34;filter\u0026#34;: [\u0026#34;kuromoji_readingform\u0026#34;] } GET _analyze { \u0026#34;text\u0026#34;: [\u0026#34;南方熊楠\u0026#34;], \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji_tokenizer\u0026#34;, \u0026#34;filter\u0026#34;: [\u0026#34;kuromoji_readingform\u0026#34;] } # GET _analyze { \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;ナンポウ\u0026#34;, \u0026#34;start_offset\u0026#34;: 0, \u0026#34;end_offset\u0026#34;: 2, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;クマグス\u0026#34;, \u0026#34;start_offset\u0026#34;: 3, \u0026#34;end_offset\u0026#34;: 5, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 1 } ] } # GET _analyze { \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;ミナカタ\u0026#34;, \u0026#34;start_offset\u0026#34;: 0, \u0026#34;end_offset\u0026#34;: 2, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;クマグス\u0026#34;, \u0026#34;start_offset\u0026#34;: 2, \u0026#34;end_offset\u0026#34;: 4, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 1 } ] } 人名や地名は1つの漢字に対して多くの読みが存在しているので大変です。。。 どうしてこれは出てこないんだろう？と不思議に思った場合は、_analyze APIを使ってどういう動きなのかを見てみるのがいいかと。\nまとめ ということで、少しだけですが、こんなことができるよ、できないよというのを書いてみました。 挙動をしっていれば、なんでこうなってるんだっけ？といったことを調べる役に立つかと思います。 入力された文字をもとにどれをサジェストするかなどについてはもう少し違う動きなので、中の仕組みをそろそろ書かないとなぁ。\n参考 同形異音語 - Wikipedia ","date":1660099802,"dir":"post/2022/","id":"73279888a8fe482c836fb19ca23318dc","lang":"ja","lastmod":1660099802,"permalink":"https://blog.johtani.info/blog/2022/08/10/jp-auto-completion-2/","publishdate":"2022-08-10T11:50:02+09:00","summary":"前回は日本語用オートコンプリートのためのAnalyzerとして、どうやって使うのかを簡単に紹介しました。 今回はもう少し、いろんなパターンを試","tags":["elasticsearch","lucene"],"title":"ローマ字入力のゆれと読み（JapaneseCompletionAnalyzerその2）"},{"contents":"風のうわさで、日本語用のオートコンプリートのためのTokenFilterとAnalyzerがLuceneに取り込まれたと聞きました（LUCENE-10102）。 Elasticsearchでも使えるかなぁ？ということで調べたところ（調べた？聞いた？）、どうやら8.1から利用できるようになっている（GitHub Issue #81858）みたいです（まだ、公式ドキュメントには記載がないのですが）。\n8/17追記\n作者の打田さんがブログ書いてたの見落としてた（もしくは見たけど忘れてた）ので貼っておきます。マルチテナンシー下での Query Auto Completion 設計・運用戦略 - LegalForce Engineering Blog\nということで、こんな感じで使えるよというのを試してみました。\nどういうもの？ 日本語入力方法を考慮したオートコンプリート用のトークンを生成してくれるTokenFilterと、 それをLuceneのSuggesterで動くようにしたAnalyzerが用意されています。 Elasticsearchでは、Kuromojiプラグインにそれらを使えるようになっています（バージョン8.1.0以降）。 KuromojiTokenizerと一緒に利用する前提の仕組みとなります。\nオートコンプリートとは？ 検索窓などでキー入力をしていると、入力した文字で始まる単語の一覧が現れることがあると思います。 あの機能がオートコンプリートと呼ばれるものです。search-as-you-typeとも呼ばれることもあります。 （検索ペンギン本にも書いてあるので興味のある方はぜひ！（ステマ）） 入力された文字列を含むパターンもありますが、今回紹介するものは入力された文字で始まる単語を見つけてくる機能になります。\n何がなんで追加されたの？ 日本語の入力方法は、かな入力の人もいればローマ字入力の人もいます。 ですので、オートコンプリートでの入力として、「しゃ」という入力が来る場合もあれば、「sha」というローマ字入力途中のものが来る場合もあります。 これらを考慮したトークンの扱いができるように、 JapaneseCompletionFilterというクラスが追加されています。 内部的にはKuromojiTokenizerでトークンに分割された後に、もともとのトークンと同じポジションで読みをローマ字にしたものを出力します。 JapaneseCompletionAnalyzerは上記Filterをすぐに使えるようにしたAnalyzerです。\n動かし方 百聞は一見に如かずということで、Elasticsearchでの使い方を見たほうが分かりやすいので、簡単に動かしてみることにします。\nインストールとインデックスの用意 Elasticsearch（8.1以上）とKuromojiのプラグインをインストールします（今回試したのは8.3.1）。\nサンプルデータ なにかいいデータはないものか？と思っていたところ夏休みだというのを思い出しました。 夏休みといえば読書感想文だ、ということで、書籍のタイトルがいいかもなと。 青空文庫の著者名と書籍のタイトルの一覧を見つけたのでそちらのデータを使って試してみました。\nCSV to JSON CSVファイルは最後の参考にある青空文庫のページから、「公開中　作家別作品一覧：全て(CSV形式、zip圧縮）」をダウンロードしたものを利用しました。 CSVファイルだったので、jqコマンドで必要な部分だけをNDJSONの形でとりあえずファイルに出力します。\ncat list_person_all_utf8.csv | tr -d \u0026#39;\u0026#34;\u0026#39; | jq -c -R \u0026#39;split(\u0026#34;,\u0026#34;) | {\u0026#34;auth_id\u0026#34;: .[0] | tonumber, \u0026#34;author\u0026#34;: .[1], \u0026#34;id\u0026#34;: .[2] , \u0026#34;title\u0026#34;: .[3], \u0026#34;suggest_ja\u0026#34;: [.[3], .[1]]}\u0026#39; 次のようなJSONが1行ずつ出力されます。\n{\u0026#34;auth_id\u0026#34;:1257,\u0026#34;author\u0026#34;:\u0026#34;アーヴィング ワシントン\u0026#34;,\u0026#34;id\u0026#34;:\u0026#34;056078\u0026#34;,\u0026#34;title\u0026#34;:\u0026#34;駅伝馬車\u0026#34;,\u0026#34;suggest_ja\u0026#34;:[\u0026#34;駅伝馬車\u0026#34;,\u0026#34;アーヴィング ワシントン\u0026#34;]} suggest_jaがオートコンプリートの対象となるデータになります。今回は著作と著者にしてみました。 あとは次に紹介するスキーマでインデックスを作成して、適当なプログラムを使ってBulkでElasticsearchに登録しましょう（私は個人作のツールで入れました）。\nインデックス オートコンプリート用のSuggesterを利用するための特殊なフィールド（completion）を利用したフィールドを用意します。 ちなみに、今回はLUCENE-10102に記載があった設定をそのまま使わせていただきました。 そのほかのフィールドは今回は特に必要はないのでおまけです。\nPUT aozora_index { \u0026#34;mappings\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;completion\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;japanese_completion_index\u0026#34;, \u0026#34;search_analyzer\u0026#34;: \u0026#34;japanese_completion_query\u0026#34;, \u0026#34;preserve_separators\u0026#34;: false, \u0026#34;preserve_position_increments\u0026#34;: true, \u0026#34;max_input_length\u0026#34;: 50 }, \u0026#34;auth_id\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;author\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;text\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;keyword\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;keyword\u0026#34;, \u0026#34;ignore_above\u0026#34;: 256 } }, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34; }, \u0026#34;author_id\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;integer\u0026#34; }, \u0026#34;id\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;integer\u0026#34; }, \u0026#34;title\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;text\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;keyword\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;keyword\u0026#34;, \u0026#34;ignore_above\u0026#34;: 256 } }, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34; } } }, \u0026#34;settings\u0026#34;: { \u0026#34;index\u0026#34;: { \u0026#34;number_of_shards\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;analysis\u0026#34;: { \u0026#34;analyzer\u0026#34;: { \u0026#34;japanese_completion_index\u0026#34;: { \u0026#34;mode\u0026#34;: \u0026#34;index\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;kuromoji_completion\u0026#34; }, \u0026#34;japanese_completion_query\u0026#34;: { \u0026#34;mode\u0026#34;: \u0026#34;query\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;kuromoji_completion\u0026#34; } } } } } } 動作確認 ここまでで、インデックスとデータの用意ができました。 オートコンプリートを実現するためにはElasticsearchのSuggesterという機能の、Completion Suggesterを利用します。検索の仕方が通常のものとは少し異なります。 ちなみに、速度重視のためにインメモリで動いているとの記載がドキュメントにあります。\nCompletion Suggesterのクエリ Suggester用のクエリがあるのでこちらを使います。 例えば、「wagah」という入力がある時に、サジェストする内容を取得するには次のようなリクエストになります。\nGET aozora_index/_search { \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;wagah\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } }, \u0026#34;_source\u0026#34;: [\u0026#34;title\u0026#34;, \u0026#34;author\u0026#34;] } 最初の「suggest」がsuggest用のパラメータを意味しています。 次の「title-suggest」は好きな名前をつけられます。レスポンスにこの名前がついた配列がサジェストの結果になります（同時に3. 複数suggestを呼び出せるので、対応した結果が分かるように名前が付けられます）。 「prefix」に入力の文字列を渡します。 「completion」がsuggesterのタイプの指定です。今回はCompletion Suggesterなので「completion」を指定します。その中に「field」でcompletionに利用するフィールド名を指定します。先ほどのスキーマでcompletionタイプを指定したフィールドです。今回は「suggest_ja」になります。 「_source」は結果を見やすくするために、ヒットしたデータの一部だけ取得するオプションです。 すると、次のような結果が返ってきます。\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;wagah\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 5, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;『吾輩は猫である』中篇自序\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;002671\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;『吾輩は猫である』中篇自序\u0026#34;, \u0026#34;夏目 漱石\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;わが俳諧修業\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;003771\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;わが俳諧修業\u0026#34;, \u0026#34;芥川 竜之介\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;わが母をおもう\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;003997\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;わが母をおもう\u0026#34;, \u0026#34;宮本 百合子\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;わが母を語る\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;049723\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;わが母を語る\u0026#34;, \u0026#34;上村 松園\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;吾輩は猫である\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;000789\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;吾輩は猫である\u0026#34;, \u0026#34;夏目 漱石\u0026#34; ] } } ] } ] } } 「suggest」の「title-suggest」がCompletion Suggesterのレスポンスになります。 最初の「text」は入力の「prefix」の値です。「offset」、「length」もこの文字に関する情報なので特に気にしなくてもいいかと。 「options」がサジェストされた内容になります。それぞれの「text」がサジェストされた文字列になります。「suggest_ja」には著作と著者名を入れましたが、今回は著作が「text」に帰ってきていることがわかります。 次に著者名でもやってみましょう。 「太宰」という入力が来たものとしてリクエストを投げます。\nGET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;太宰\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } } } レスポンスは次のようになります。\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;太宰\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 2, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;000236\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;ア、秋\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;001572\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;I can speak\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;001578\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;愛と美について\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;046597\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;青森\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;004357\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;青森\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } } ] } ] } } 先ほどとは異なり、「options」の中の個々の「text」はすべて「太宰 治」になってしまいました。 登録したデータは著作の一覧ですが、「suggest_ja」には著作と著者名を入れたためです。 これでは、実際に検索窓に実装したときに同じものが並んでしまいます。 こんな時のためのオプション「skip_duplicates」が用意されています。 先ほどのリクエストに「\u0026ldquo;skip_duplicates\u0026rdquo;: true」を追加します。\nGET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;太宰\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34;, \u0026#34;skip_duplicates\u0026#34;: true } } }, \u0026#34;_source\u0026#34;: [\u0026#34;suggest_ja\u0026#34;] } するとレスポンスは次のように変化します。\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;太宰\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 2, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;000236\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;ア、秋\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰治との一日\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;042582\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;太宰治との一日\u0026#34;, \u0026#34;豊島 与志雄\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰治情死考\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;043137\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;太宰治情死考\u0026#34;, \u0026#34;坂口 安吾\u0026#34; ] } } ] } ] } } 「options」は3つに減り、重複していないことがわかります。 「text」が同じ場合は最初に出てきたものを返すようです（注意：結果から観測しているだけで、実装はまだ見ていません）。 （なお、今回は説明を省きますが、入力データでスコアを指定することも可能になっています）。 そのほかにもCompletion Suggesterにはいくつか仕組みが用意されているのですが、それはまた今度にでも。\nまとめ ということで、Luceneコミッターの打田さんに感謝です。 便利な仕組みが簡単に使えるようになるのはとてもありがたいですね。\nまずは簡単にどういうものかとどうやって使うのかを記事にしてみました。 中の動きや、注意点、これまでとの違いなどは次の記事にしようと思います。 そういえば、公式ドキュメントにはまだ出てきてないな、それを書こうと思ってついでに動かしてみたんだけど、追加するのはまた後日かな。。。\n参考資料 青空文庫 - 公開中　作家リスト：全て ［LUCENE-10102］ Add JapaneseCompletionFilter for Input Method-aware auto-completion - ASF JIRA Expose Japanese completion filter to kuromoji analysis plugin by mocobeta · Pull Request #81858 · elastic/elasticsearch Suggesters | Elasticsearch Guide ［8.3］ | Elastic ","date":1660028402,"dir":"post/2022/","id":"6639ec6f88c4976f8ca20fa840f169e3","lang":"ja","lastmod":1660028402,"permalink":"https://blog.johtani.info/blog/2022/08/09/japanese-auto-completion/","publishdate":"2022-08-09T16:00:02+09:00","summary":"風のうわさで、日本語用のオートコンプリートのためのTokenFilterとAnalyzerがLuceneに取り込まれたと聞きました（LUCE","tags":["lucene","elasticsearch"],"title":"日本語用オートコンプリートのためのAnalyzer"},{"contents":"Hugoを0.84から0.92にアップデートをする際に、これまでのブログ記事やレイアウトファイルを修正したので個人的にメモを残しておきます。\nなんでアップデート？ うっかり魔がさして、メインのWSL2のUbuntuを20.04から22.04にアップグレードしました。。。 新規に22.04を落としてきて移行ではなく。 皆さんはまねしないほうがいいですよ！ アップデートした後にGitの環境がおかしくなったりと大変でした。 WSL2のUbuntuではHugoでブログのビルド、いろんな確認のためのElasticsearchの起動、個人的なプログラムとかを書く環境として利用しています。\nで、Ubuntuを上げたところ無事（？）Hugoもアップデートされたわけです。 最初はGitでfetchが出来なくなって修正していましたが、そのほかの動作確認を行なう段階でHugoでブログがビルドできなくなっていることが判明しました。\nバージョンアップに伴う修正 hugoコマンドを実行すると、いくつかのERRORとWARNが出力されました。 次のようなものです。\nhugo v0.92.2+extended linux/amd64 BuildDate=2022-02-23T16:47:50Z VendorInfo=ubuntu:0.92.2-1 ERROR 2022/08/05 13:22:32 Page.URL is deprecated and will be removed in Hugo 0.93.0. Use .Permalink or .RelPermalink. If what you want is the front matter URL value, use .Params.url WARN 2022/08/05 13:22:32 The \u0026#34;tweet\u0026#34; shortcode will soon require two named parameters: user and id. See \u0026#34;/home/johtani/blog_generator/content/post/2020/2020-12-04-build_corne_choc.md:46:1\u0026#34; ... ERROR 2022/08/05 13:22:33 Failed to get JSON resource \u0026#34;https://publish.twitter.com/oembed?dnt=fa... If you feel that this should not be logged as an ERROR, you can ignore it by adding this to your site config: ignoreErrors = [\u0026#34;error-remote-getjson\u0026#34;] ERROR 2022/08/05 18:44:11 Page.UniqueID is deprecated and will be removed in Hugo 0.93.0. Use .File.UniqueID ERROR 2022/08/05 18:44:11 Page.Dir is deprecated and will be removed in Hugo 0.93.0. Use .File.Dir Page.URLなどがdeprecatedに 最初と最後2行のERRORがこちらになります。 どうやら、Pageオブジェクトの変数に変更があったようです（まだdeprecatedであり、存在はしていそう？）。 レイアウト（テンプレート）ファイルで「Previous Post」や「Next Post」といったリンクを作ったり、 Algoliaに登録するためのJSONファイルを生成するところでURL文字列を取得するために参照していました。\nログ出力でどのように変更すればよいのか？という記載があるので便利ですね。 ただ、どのファイルにこの記述があるのかはログに出てなかったので少しだけ苦労しました。\n実際には「UniqueID」という文字列でディレクトリ内を検索してあたりを付けた感じです。 利用させていただいているテーマ（Clean White）がすでにアップデートに対応されていたのでそちらが参考になりました。\nいくつか、テーマをもとに修正したテンプレートがlayoutsディレクトリにあったので、それらを修正した形です（参考のリンクはテーマのファイルになります）。\n.URLを.Permalinkに変更（参考：single.html） .UniqueIDを.File.UniqueIDに変更（参考：list.algolia.json） tweetのshortcodeの引数が増えた これまでは以下のようにIDだけで良かったのですが、userとidという2つの引数が必須になるという変更が入ったようです。\n変更前：\n{{ \u0026lt;tweet 1449214872143609860\u0026gt; }} 変更後：\n{{ \u0026lt;tweet user=\u0026#34;johtani\u0026#34; id=\u0026#34;1449214872143609860\u0026#34;\u0026gt; }} WARNにはファイル名、行番号が出力されていたので、1つずつ修正していきました。 結構な量があったので、地味に大変でした、 公開しているブログを見ながら、該当するツイートを見つけてはuserを指定していく部分が特に。 自分のツイート以外もブログに貼っていたので画一的には対処できなくて。。。\nなにかプログラムで機械的に対応ができたかもなぁ。\n鍵付きツイートによるエラー tweetのshortcode対応を行なった後でもビルドがエラーになっており、次のようなエラーが消えないままでした（エラーの一部は省略しています）。 （幸いにも）1つのツイートだけ、ブログ記事を書いた後で鍵付きになってしまった方のツイートがあったようで、ツイート用のJSONが取得できなくてエラーになっていました。\nERROR 2022/08/05 13:22:33 Failed to get JSON resource \u0026#34;https://publish.twitter.com/oembed?dnt=fa... If you feel that this should not be logged as an ERROR, you can ignore it by adding this to your site config: ignoreErrors = [\u0026#34;error-remote-getjson\u0026#34;] こちらもログに対処方法が出ています。 config.tomlにignoreErrors = [\u0026quot;error-remote-getjson\u0026quot;]を追加すれば、エラーが出力されなくなりビルドも成功するようになります。 ただ、tweet以外でもエラーが出る可能性がありそうで、その場合に、ブログに書いたつもりが一部が出力されないまま公開されそうな気がします。 なので、今回はconfig.tomlに該当の設定を追加するのではなく、ブログ記事から該当のツイートを消す対応をしました。 幸いにも、ツイートを消してもブログ記事自体には影響がありませんでした。\n.hugo_build.lockファイルが生成される これは、エラーではないのですがgit addしようとした際に、ファイルが増えていたのでどういったファイルなのかを調べました。 0.89.0から追加されたロックファイルのようです（参考：0.89.0のリリースノート）。 こちらは特に保管する必要もなさそうなので.gitignoreに追加して対処しました。\nまとめ ということで、気軽にUbuntuをアップグレードしないほうがいいですね。。。 期せずしてHugoのアップグレードができたのは良かったかもなｗ\n参考 【WSL2】Ubuntu 20.04.4 LTS を 22.04 LTS へアップグレードした ","date":1659689954,"dir":"post/2022/","id":"167a7c9d579ce6f2cebf64a6f6329ecb","lang":"ja","lastmod":1659689954,"permalink":"https://blog.johtani.info/blog/2022/08/05/upgrade-hugo-accidentally/","publishdate":"2022-08-05T17:59:14+09:00","summary":"Hugoを0.84から0.92にアップデートをする際に、これまでのブログ記事やレイアウトファイルを修正したので個人的にメモを残しておきます。","tags":["hugo"],"title":"Hugoをアップデートした"},{"contents":"今回はQuerqyのElasticsearchのプラグインがどんなつくりになっているか？をちょっとだけ調べてみました。 SolrでもElasticsearchでも使えるという形なので、どんなつくりになっているのかな？と思ったのが発端です。\nGitHubのリポジトリ GitHubにリポジトリが公開されています。 2つのリポジトリに分かれています。\nEs向けのプラグイン コアのライブラリ どちらもJavaのライブラリで、ビルドシステムとしてはMavenを利用しています。 コアのライブラリのリポジトリにはさらに、以下の2つが存在しています。\nlucene向けライブラリ（Solr向けのモジュールもこちらに含まれる） コアライブラリ pom.xmlを読んだところ、次のような依存関係になっています（それ以外にも使ってるライブラリはあるけど）。\nEsプラグイン -\u0026gt; Lucene向けライブラリ -\u0026gt; コアライブラリ Esプラグイン Es向けのエンドポイントの実装、Esのクエリの組み立てを行なっています。 Rewriterの実装については、Lucene向けライブラリ、コアライブラリを利用する形になります。\nquerqy用のQueryBuilderを実装しており、EsがクエリをパースするタイミングでRewriterなどを呼び出してクエリの書き換えを行う仕組みです。 なお、Es向けのクエリの組み立てと書きましたが、ほとんどLuceneのクエリの組み立てになっています（そりゃそうだ）。 実際にquerqyのクエリ組み立て処理を行っているのは、Lucene向けライブラリのQueryParsingControllerになります。 いくつかのRewriterは、生のEsクエリをルールなどとして登録することができるようになっています。 これらのクエリのパースをEs側にやらせる処理の部分もこちらで定義されている感じです。\nそのほかに、ドキュメントには記載がないエンドポイントが2つ用意されていました。 インデックスに登録してあるRewriterの設定を各ノードでキャッシュする仕組みがあって、そのキャッシュの操作（クリア、リロード）用みたいです。 これらは、Rewriterの追加、削除のアクションの内部で呼び出されているので、ユーザー側で呼び出す必要はなさそうです。\nLucene向けライブラリ Luceneに関連する処理がまとめられています。 Es内部ではLuceneを使って検索処理が行なわれるため、Luceneのクエリを組み立てる必要があります。 querqyとしてLuceneのクエリを組み立てるときに必要なクラスがこのライブラリに含まれています。\nまた、Word Break Rewriterの実装はコアライブラリではなくこちらのライブラリに実装されています。 これは、Luceneのタームディクショナリを活用したRewriterになっているため、Lucene必須となっているからのようです。 （まだちゃんと実装を見ていないので、どんな活用の仕方をしているのかまではわかっていませんが。。。）\nコアライブラリ Rewriterの設定のパース処理、クエリのリライト処理の実装がまとめられています。 querqyのクエリが、Rewriterの処理に基づいて、querqyとして定義されたクエリのモデルに一旦変換される作りになっています。 Lucene向けライブラリやEs向けプラグインはこの内部のクエリモデルになったものをもとに、Lucene向けのクエリに書き換えていくというながれになっています。\nまとめ ざっくりですが、どんな構成なのかを見てみました。 Esのプラグインとなっているのですが、プラグインではなく、外部に出すことってできるのかな？と思いつつ、なんとなくソースを読んでみました。 パターンとしては、Lucene向けのクエリからEs向けのクエリを組み立てるとかの無駄な努力が必要になる気もするけど。。。 Luceneを使っていない検索エンジンに対しては、コアライブラリをもとに、それぞれの検索エンジンむけのクエリを組み立てる仕組みを作る形になると思います。 その際、Rewriterの設定を保持する仕組み、querqyが置き換えたクエリのマッピングができるか？といった点を考える必要がありそうです。 デバッグとかするときに、EsのクエリDSLのJSONとして見れるといいなぁと思ってたけど、そんなことできるかなぁ？\n","date":1658300650,"dir":"post/2022/","id":"3384ea6bb47d70f8ca94b4510813f36a","lang":"ja","lastmod":1658300650,"permalink":"https://blog.johtani.info/blog/2022/07/20/querqy-architecture/","publishdate":"2022-07-20T16:04:10+09:00","summary":"今回はQuerqyのElasticsearchのプラグインがどんなつくりになっているか？をちょっとだけ調べてみました。 SolrでもElast","tags":["elasticsearch"],"title":"Querqyの調査（その2：アーキテクチャ）"},{"contents":"Querqyというクエリのリライト用のプラグインがあるのでどんなものかを調べてみました。とりあえずは概要をドキュメントから追いかけてみた感じです。対応しているのはSolrとElasticsearch（以降、Es）になります。手元にはEsの環境があるのでそちらで試してみました。\nなにもの？ EsやSolrのプラグインで、ルールやパラメータを利用して、クエリの書き換えをEsやSolr側で行えるプラグインです。 なお、本記事ではEsのプラグインを説明します。 今回はドキュメントを読みながらメモを取った感じなので、詳細については公式ドキュメントを見ていただくのが良いかと。 手元では動作させてみましたが、今回の記事ではざっとメモを取っただけになります。\nインストール Esのpluginコマンドでインストール可能ですが、Mavenにアップロードされているバージョンは限定的なので、必要に応じて自分でビルドする必要があります。 対応しているかは、公式ドキュメントのInstallationのプルダウンが参考になります。\nどうやって使うの？ Query DSLにquerqyというクエリが追加されるので、あとはドキュメントをもとにクエリを組み立てるクエリを書いていきます。 すると、プラグインが指定されたルールに従い、EsのQueryに書き換え、実際の検索が実行して結果が返ってきます。 普通にmatchなどの既存のQueryと同レベルのものになるので、既存のEsのクエリと組み合わせた使い方もできるようです。\nサンプルとして紹介されている短めのクエリ（このクエリではルールによるクエリの書き換えはない）。\nGET ecommerce/_search { \u0026#34;query\u0026#34;: { \u0026#34;querqy\u0026#34;: { \u0026#34;matching_query\u0026#34;: { \u0026#34;query\u0026#34;: \u0026#34;notebook\u0026#34; }, \u0026#34;query_fields\u0026#34;: [ \u0026#34;title^3.0\u0026#34;, \u0026#34;brand^2.1\u0026#34;, \u0026#34;short_description\u0026#34;] } } } また、書き換え（Rewriter）の設定をElasticsearchに対して保存できるエンドポイント_querqy/rewriterが用意されています。\nSynonymの書き換えを行なうサンプル（後述するCommon Rules Rewriterの設定）。\nPUT /_querqy/rewriter/common_rules { \u0026#34;class\u0026#34;: \u0026#34;querqy.elasticsearch.rewriter.SimpleCommonRulesRewriterFactory\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;rules\u0026#34; : \u0026#34;notebook =\u0026gt;\\nSYNONYM: laptop\u0026#34; } } どんな書き換えができるの？ 用意されているRewriterは2022年7月時点では次のようなものになります（がんばれば、Javaで実装すれば自作もできそう）。\nCommon Rules Rewriter Replace Rewriter Number Unit Rewriter Word Break Rewriter また、複数のRewriterをチェインして使うこともできる。記述した順番で適用されます。 それぞれのRewriterについて簡単にメモを。\nCommon Rules Rewriter シノニム、結果のブースト、フィルター、結果に対して追加情報を付与したりできます。\nrulesにルールを記載していきます。 以下のようなフォーマットになっています。 クエリが入力に合致したら、ルールが適用される形です。プロパティは後述しますが、ルールの適用する順序などをハンドリングするために使用します。\n入力 =\u0026gt; ルール ルール @プロパティ @プロパティ 入力部分に関する書式 ルールの左辺に該当する部分で、クエリに入力された文字列がマッチするかどうかで、右辺のルールを適用するかがきまります。\n入力の一致の条件は次のような感じです。 完全一致、前方一致、後方一致の使い分けが可能。ダブルクォート\u0026quot;で制御 デフォルトでは、大文字小文字の区別なし（後述するオプションで変更可能） 単語の末尾にワイルドカード*で1文字以上にマッチ。入力の最後にだけ利用可能 書き換えの命令（ルール） 右辺に利用できる命令で、次のようなものがあります。\nSYNONYM 同義語展開するための命令です。Synonym Token Filterとの違いは、複数のルールを同時に適用できます。 フィールドに依存しない設定なのでメンテナンスが楽になるとのこと。 ただし、双方向の設定はないため、例えば\u0026quot;personal computer\u0026quot;と\u0026quot;pc\u0026quot;の場合、2つの設定を個別に定義する必要があります。 また、ステミングなどには未対応なので、\u0026ldquo;personal computers\u0026quot;も対応する場合はこれも追加する必要があります。 類義語ごとに重みを変えることが可能になっています。同列ではなく、同義語のスコアを下げるなどで、リコールを増加させつつ、入力語のスコアを上位にすると行ったことが可能です。\nUP/DOWN 入力文字列がマッチした場合に、追加のクエリを正か負のブーストをしつつ追加できます。 例えば、「iphone」と検索された場合に、「apple」もクエリとして追加しつつスコアをブーストし、「case」のクエリをスコアを下げるように追加できます。 これにより、アクセサリーではなく本体が検索結果の上位に出てくるような仕組みを提供できます。\nFILTER UP/DOWNではクエリとして追加されていたが、こちらはフィルターとして追加されます（＝スコアで調整ではなく、結果から除外される）。\nDELETE クエリからキーワードを削除できます。 単語自体をそのまま削除することも、入力された単語に合わせて他の単語を削除することもできます。\nDECORATE 2022年7月時点でEsでは利用不可で、Solrのみで利用可能です（なので読み飛ばしました）。\nプロパティ 各ルールの設定にタグをつけられるような機能です。 このプロパティを利用して、ルールのソートやフィルタリングなどが可能になります。 複数のルールにクエリがマッチした場合に、優先度が最高のものだけを適用したり、プロパティに特定の値を持っているものだけを採用したりできます。 なお、プロパティは命令のあとに記述する必要があります（パーサーの関係かな？）。\nReplace Rewriter クエリタームの置き換え用のRewriterです。クエリの正規化処理として、他のRewriterの前処理に利用したりできます。 サンプルではタイポの修正などに利用したり、不要な語の除去などがあげてありました。\nWord Break Rewriter クエリトークンを分解・結合します。 たとえばドイツ語は、複合語と呼ばれる個別の意味の単語を結合した1つの単語を持っているため、個別の意味に分解して検索すると便利なことがあります。 そういった単語を辞書を基にして分割できるようにする機能です。 辞書とは実際のインデックスのタームディクショナリのことと思われます（要調査。どのインデックスのフィールドを指し示すのかなど、設定とドキュメントではよくわからない）。 なお、利用可能な形態素解析を基にした実装はドイツ語のみとなっており、また、分解の時には形態素解析を考慮しますが結合時には考慮しません。\nNumber-Unit Rewriter クエリの数値と単位を判別し、対象となるフィールドにマッチさせます。範囲での一致や完全一致やブーストが可能です。 単位をもとにして、特定のフィールドに対する数値のクエリに書き換えることができます。\nShingle Rewriter Solrのみで利用可能なので読み飛ばしました。\nルールはどこに保存されるの？ .querqyというインデックスが内部で作成され、そこに保存されます（公式ドキュメントより）。 （ちなみに、Mappingはこんな感じみたいです）。 現状、プラグインでは設定したRewriterの取得ができないようなので、自分で登録した設定がどんなものかは、このインデックスを検索する必要がありそうです。\n気になった点・改善点？ 気になった点があったので。\nRewriterのエンドポイントは、登録・更新・削除のみ対応しており、登録したものの確認は直接インデックスを見に行くしかなさそうです（Issueは作られてた）。 [要検証]書き換えられたクエリがどんなものか？は残念ながら確認できなそうで、_validate/queryで最終的なLuceneレベルのクエリで確認するしかなさそう？ スキーマ側で定義したものと、Querqyで定義したものの兼ね合いがどういう形になるのか？などを気にする必要があるのが注意点かも。組み合わせたときの副作用などがどんなことになりそうか？が予測がつきにくそう。 Rewriterの定義自体のテストはどうしたものか？ まとめ とりあえず、ざっとドキュメントを見ながらメモを取った感じです。 設定などの記述が独自のものなので、そこに慣れていく必要がありそうです（特にルールの改行の部分とか）。 次は実際にどんな感じで使えそうか、既存の仕組みとの違いは？みたいなところをもう少し見ていきたいとおもいます。\n参考文献 querqy/querqy： Query preprocessor for Java-based search engines (Querqy Core and Solr implementation) Getting started with Querqy — querqy.org documentation ","date":1658285563,"dir":"post/2022/","id":"779e444b4bc720a9eed97f19c41e8773","lang":"ja","lastmod":1658285563,"permalink":"https://blog.johtani.info/blog/2022/07/20/intro-querqy/","publishdate":"2022-07-20T11:52:43+09:00","summary":"Querqyというクエリのリライト用のプラグインがあるのでどんなものかを調べてみました。とりあえずは概要をドキュメントから追いかけてみた感じ","tags":["elasticsearch"],"title":"Querqyの調査（その１）"},{"contents":"今年もBerlin Buzzwordsにオンライン出張してました。 今年はハイブリッドな開催だったようで、現地で再開している人もいるようでした。 ブースもあったみたいです。ちなみに、現地で参加する人はマスク必須のようでした（Health \u0026amp; Safetyというページが用意されていました）。 昨年オンラインだったMICESは現地のみでの開催みたいで見ることはできなかったです（録画公開されないかなぁ）。\nさて、いくつか見たセッションで面白かったものがあったので簡単にメモを。 すでにセッションのビデオがYouTubeで公開されているので、興味のある方は見てみてください。\n面白かったセッション The future of Lucene\u0026rsquo;s MMapDirectory: Why use it and what\u0026rsquo;s coming with Java 19 and later? セッションページ： The future of Lucene\u0026rsquo;s MMapDirectory： Why use it and what\u0026rsquo;s coming with Java 19 and later? ：： Berlin Buzzwords 2022 動画：Uwe Schindler – The future of Lucene\u0026rsquo;s MMapDirectory： Why use it \u0026amp; what\u0026rsquo;s coming with Java19 \u0026amp; later - YouTube 毎年恒例になってる気も？ 前半は昨年も話をした内容で、後半はJava 19がリリースされたら、Previewという形でフラグを立てて使えるようになるようです。 使えるようにするから、テストしてみて！という感じで終わっていますｗ\nScaling an online search engine to thousands of physical stores セッションページ：Scaling an online search engine to thousands of physical stores ：： Berlin Buzzwords 2022 ：： pretalx 動画：Aline Paponaud – Scaling an online search engine to thousands of physical stores - YouTube 数千の実店舗の商品をオンラインで検索できるようにしつつ、オンラインのマーケットプレイスのような検索も一緒にできるようにしたというお話でした。 インデックスの構成をどう工夫したのか？とかどういうクラスター構成にして、どんなことをモニタリングしてるよ？というお話です。 実際の店舗がどんなものかなどは出てこなかったので、少しイメージは沸きにくかったのですが、どんなことを考えながらインデックスの構成とか考慮したよという話はおもしろかったです。 実際に検索したときに、実店舗のデータがどんな感じで結果として表示されたりするのか？といった点はわからなかったので、そのあたりの話をもうちょっと聞いてみたかったなぁ。\nOffline Ranking Validation - Predicting A/B Test Results セッションページ：Offline Ranking Validation - Predicting A/B Test Results ：： Berlin Buzzwords 2022 ：： pretalx 動画：Andrea Schütt \u0026amp; Yunus Lutz – Offline Ranking Validation - Predicting A/B Test Results - YouTube otto.deというECサイトでのランキングをどうやって改善していくか？という話。 現在はマニュアルなチューニングをコンテキストごとにやっているけど、リクエスト量とかデータとかが増えてきてて、このままマニュアルで改善していくのも大変なので、 モデルベースのランキングを開発できないか？というのをはじめていますよと。 そのために、これまでのデータから、A/Bテストの結果を予測できるモデルが作れないか？というのをやっていますという話。 いくつかわからない単語も出てきたので、誰か詳しい人教えて！\nAI-powered Semantic Search; A story of broken promises? セッションページ：AI-powered Semantic Search; A story of broken promises? ：： Berlin Buzzwords 2022 ：： pretalx 動画：Jo Kristian Bergum – AI-powered Semantic Search; A story of broken promises? - YouTube Vespaの開発にかかわってる方の、Semantic Searchに関する話。 Semantic Searchが流行り始めていて、どうやればできるのか？という話が出てきています。 けど、どういうものでどういう点に気を付けたほうがいい？という話でした。 LtRってこんなもの、そのあとに出てきたLLM（Large Language Model）でどうやって検索の改善に使えるの？というのが分かりやすく説明されていました。 それらの説明の後、BEIRという論文を紹介しつつ、LLMを使うときの注意点の話がありました。\nBERTとかをちょっと勉強してたのもあり、なんとなくそうだよなぁと思っていた結論と同じ結論が出てきたので面白いと感じました。 BEIRの論文は時間を見つけて読んでみないとな。\nHybrid search \u0026gt; sum of its parts? セッションページ： Hybrid search \u0026gt; sum of its parts? ：： Berlin Buzzwords 2022 ：： pretalx 動画：Lester Solbakken – Hybrid search： Greater than the sum of its parts? - YouTube こちらもVespaの人の話。 先ほどのSemantic Searchの話では、Semantic Searchがどんなものか？という話でした。 が、それだけで検索ができるわけでもないので、キーワードサーチとSemantic Searchの両方をうまく活用するには？というのがこのセッションでした。 最終的にはVespaを使うとうまくハイブリッドできるよという話ですが、考え方は参考になるかなと。 Vespaも触ってみたいなぁ。\nThe life of a search engine administrator セッションページ：The life of a search engine administrator ：： Berlin Buzzwords 2022 ：： pretalx 動画：Lucian Precup \u0026amp; Vincent Bréhin – The life of a search engine administrator - YouTube 検索システムの管理者ってどんなことやるの？それにはどんなことができるツールがあるといいの？という話です。 まぁ、ツールについてはこの会社の人たちのツールの宣伝なのですが、検索システムを作って育てていくのにどんなことを考えたりするのか？という参考になるかなぁと。\nShould we stop using distance in our location-based data recommendation models? セッションページ：Should we stop using distance in our location-based data recommendation models? ：： Berlin Buzzwords 2022 ：： pretalx 動画：Charlie Davies – Should we stop using distance in our location-based data recommendation models? - YouTube TravelTimeという会社を立ち上げた人の話。 位置に関する情報って重要だし、検索するときに利用しますよね？例えば、ホテル決めたりとか、仕事探したりするときに。 ということで、位置情報を検索エンジンで利用する方法（Bounding Box、ポリゴン、距離）をまず紹介して、どんなユースケースで使えるかという話があります。 また、それとは別に検索速度（いかに検索を速く返すか）も重要だという話があります（ウォルマートはページロード時間を1秒早くしてコンバージョンが2%あがったとか）。 で、実際に検索結果に距離とかでるけど、実際に知りたいのはどのくらいの時間で行けるのか？という話だったりしませんか？と。 公共交通機関を使ったりする場合に、実際に45分で移動できる距離というのは半径5マイルとかできまるものではないのに、単純に位置情報を利用した距離だけでソートしていいの？という問いかけから、 その辺を考慮した検索ができるAPIを開発しているよ、検索速度もはやいよというお話でした。 残念ながら具体的にどうやって作っているのか？というのはなかったですが、観点がおもしろかったです。\nWord2Vec model to generate synonyms on the fly in Apache Lucene セッションページ：Word2Vec model to generate synonyms on the fly in Apache Lucene ：： Berlin Buzzwords 2022 ：： pretalx 動画：Daniele Antuzi \u0026amp; Ilaria Petreti – Word2Vec model to generate synonyms on the fly in Apache Lucene - YouTube Word2Vecのモデルを使った、Apache LuceneのSynonym Filterを開発中だよという話 DeepLearning4Jを使ってみたが、遅くて使えなかったんだけど、最近Luceneに入ったkNNを使うことでそれなりの速度で使えそうなものができるかもよ？って感じでした。 モデル学習用のツールも作ってて、イタリア語のWikipediaで学習したものでちょっと動かしたらそれっぽい感じになってるという話でした。 まだ途中でいくつかやりたいことがあるという話で、実用はまだ先のようでした。例えば、1単語のSynonymにしか対応してないとか、モデルをインメモリでしか動かせないとか。\nQAでも出たのですが、Word2Vecだと対義語も類似していると判定されてしまうと思うので、その辺がどうなっているのかなぁ？という疑問があります。 ルールベースの類義語ではないので、調整するのはどうやるのかなぁ、学習用のコーパスをいい感じにするとかなのかな？とか、気になるところです。\nNrtSearch: Yelp’s fast, scalable, and cost-effective open source search engine セッションページ：NrtSearch： Yelp’s fast, scalable, and cost-effective open source search engine ：： Berlin Buzzwords 2022 ：： pretalx 動画：Umesh Dangat – NrtSearch： Yelp’s fast, scalable, and cost-effective open source search engine - YouTube YelpがLuceneベースで開発をしているNrtSearchというOSSの話です。 Elasticsearchを使っていたんだけど、どういった点が問題点になってどういうモチベーションでNrtSearchを開発したのか？を説明しています。 アーキテクチャがどんなもので、実際に動かしてみてどんな利点があって、どんな点が問題として出てきているか、将来どんなことをやろうとしているかがわかります。 QAでもいろんな質問が出ていて面白いです。\nまとめ ということで、簡単でしたがセッションの感想でした。 Neural/Semantic Searchというのがセッションのタイトルなどに入っているのが多くなってるなぁという感想です（ちょっとやってみたい気はしてるんだよなぁ）。 すでにYouTubeに動画が公開されているので興味があるセッションを見つけてみてください。 Berlin Buzzwordsの次の日に開催されたMICESも観てみたかったですが、オンラインでも参加できる形式で海外のカンファレンスが開催されるのはとても助かりますね（ヨーロッパだと時差もそれほど大変じゃないし）。 けど、落ち着いたらまたオフラインで参加してみたいなぁ。\n","date":1655283615,"dir":"post/2022/","id":"f56c19442484b3e4f47875b58b3f72b2","lang":"ja","lastmod":1655283615,"permalink":"https://blog.johtani.info/blog/2022/06/15/ttend-berlin-buzzwords-online/","publishdate":"2022-06-15T18:00:15+09:00","summary":"今年もBerlin Buzzwordsにオンライン出張してました。 今年はハイブリッドな開催だったようで、現地で再開している人もいるようでした。","tags":["conference","berlin buzzwords"],"title":"今年もオンラインでBerlin Buzzwordsに参加した"},{"contents":"7.16で正式リリースされましたが、Elasticsearchの新しいJavaのクライアントが出ています。 使ってみたので、ちょっとだけ紹介でもしてみようかな。\nこのクライアントが出るまでは、ElasticsearchのJavaクライアント（REST版）はElasticsearch本体の一部として実装・管理されていました（Elasticsearchのリポジトリにあるclientディレクトリ）。\nHTTP経由でElasticsearchにアクセスするクライアントだったのですが、Elasticsearch本体のリポジトリで管理されていることもあり、Elasticsearch本体で利用されているクラスを使用していました。 このため、クライアントライブラリなのですが、Elasticsearch本体のJarが必要になりサイズが大きくなっていました。 また、JavaのObjectへの詰め替えなどの機能も備えておらず、すこし古臭い感じでもあります。 この辺りを刷新する目的もあり新しいクライアントが公開されたようです。 3月くらいに触った時はまだ、ドキュメントが揃ってなかったのですが利用方法などが増えているので移行も楽になってきているようです。 根本的に作り直されたため、これまでのREST Clientとは使い方が違います。ですので、jarだけの差し替えでこれまで動いていたプログラムを移行ができるわけではないので注意が必要です。\nどの辺が便利？ 順次移行が可能 これまでのRESTクライアントとはパッケージ名もjarも別モノになっています。 ですので、少しずつ新しいJava Clientに切り替えていくことが可能になっています。 根本的に使い方が変わっているので、大きなシステムのクライアントを全部切り替えるのは結構大変かと思います。 ですので、Indexをしている部分だけとか、検索部分だけなどといった部分的な置き換えをしつつ新しいクライアントに慣れていくことができます。\nラムダっぽく書ける 検索のクエリのサンプルを見るとわかりますが、こんな感じでクエリが書けます(公式ドキュメントより抜粋)。\nSearchResponse\u0026lt;Product\u0026gt; response = esClient.search(s -\u0026gt; s .index(\u0026#34;products\u0026#34;) .query(q -\u0026gt; q .match(t -\u0026gt; t .field(\u0026#34;name\u0026#34;) .query(searchText) ) ), Product.class ); また、最後で渡しているProduct.classは、検索結果をどのクラスのインスタンスにして返すかの指定です。 Elasticsearchのレスポンス（JSON）から値をコピーして返してくれるようになっています。 ですので、値を入れ替える処理を書く必要がなくなっています。\nJSON文字列をそのまま使える 触り始めてからリリース（7.17.2より後なら使える）された、JSON文字列からリクエストを作る機能もあります。\nこれまでのREST Clientだと、Elasticsearchへのリクエストを必ずJavaのメソッドで構築する必要がありました。 今回のこの機能を利用すると、JSON文字列（やファイル）からリクエストオブジェクトを作るためのメソッド.withJson()が提供されています。 例えば、スキーマや設定変更用のリクエストのJSONなどは、Kibanaやcurlから試験的に投げたリクエスト（JSON）と同じものを使いたいことが多いです。また、ElasticsearchのAPIは数が多く、ドキュメントを見ながら利用方法を調べてJSONでまず試行錯誤することが多いです。 このwithJsonメソッドを利用することで、動作確認などをしたJSONがそのままソースにも利用できるので、リクエスト変更時の確認なども容易になると思います。\n使ってみて困ったのは？ 便利な面も多いのですが、使っていて少し困ったこともあったのでそれもメモを残しておきます。\nどんなリクエストを投げているかが不明 先ほども書きましたが、Elasticsearchのリクエストを試行錯誤するときは公式ドキュメントを見ながら、Kibanaなどを利用して試すことが多いです。 ですので、自分がやりたいことのJSONは手元にあることが多いです。 ただ、プログラムでクエリを組み立てる必要も出てきます。この時、実際にRESTリクエストとしてどんなJSONを投げているのかを知りたいことがあります（実際、検索クエリ作っててメソッドの使い方がうまくいかなくて四苦八苦してました）。 4月時点では簡単にリクエストで投げているJSONを文字列としてログに出すメソッドなどは用意されていないようでした。 デバッグ用に次のようなメソッドを書いてみました。 Elasticsearchへ投げるRequestのクラス（例：CreateTemplateRequestとか）を引数に渡すことで、JSON文字列に変換できるようになっています（StringWriterに書き出されてる）。 ここのLoggerはサンプルです。writer.toString()で取り出せる文字列がJSON文字列になっているので、ログに出してみるなり、ファイルに落とすなりしてデバッグのお供にしてください。\nimport java.io.StringWriter; import co.elastic.clients.elasticsearch._types.RequestBase; import co.elastic.clients.json.SimpleJsonpMapper; import jakarta.json.stream.JsonGenerator; ... private void printRequestBodyJsonForDebug(RequestBase request) { //for debug Logger.log(\u0026#34;** Debug print start **\u0026#34;); StringWriter writer = new StringWriter(); SimpleJsonpMapper mapper = new SimpleJsonpMapper(); JsonGenerator generator = mapper.jsonProvider().createGenerator(writer); mapper.serialize(request, generator); generator.close(); Logger.log(writer.toString()); Logger.log(\u0026#34;** Debug print finish **\u0026#34;); } プラグインなどで提供されるクエリが書けない LtRプラグインなどは、Elasticsearchの検索クエリを拡張しています。 残念ながら、現時点（2022/06/13）ではカスタムクエリを新しいJavaクライアントで利用しようとした場合、エラーが発生してしまいます（知らないJSONだと判断されてしまいます）。\nGitHubのIssueとして「［roadmap］ Add support for plugin-defined custom components · Issue #252 · elastic/elasticsearch-java」があります。 これに対応されたら、拡張されたクエリも利用できるようになるでしょう。 プラグインなどで拡張されているものを使いたい場合は、残念ながら既存のRESTクライアントを当面は使うことになりそうです。\nまとめ 新しいElasticsearchのJavaクライアントを簡単ですが触ってみて、気になった点を記事にしました。 JavaのObjectに詰め替えてくれる機能など便利になっているので使ってみてください。 ドキュメントもちょっとずつ増えているようで、使い方も分かりやすくなっていました（触った時はレスポンスの扱い方などがJavaDocしか用意されてなかったんです）。 説明が欲しいなぁと思うことがあれば、GitHubにIssueを上げてみるといいかもです。\n参考 公式ドキュメント Java Clientチームの人がカンファレンスで利用したスライド ","date":1655119446,"dir":"post/2022/","id":"5eebdf85fd1726db301194bfeeee4377","lang":"ja","lastmod":1655119446,"permalink":"https://blog.johtani.info/blog/2022/06/13/new-elasticsearch-java-client/","publishdate":"2022-06-13T20:24:06+09:00","summary":"7.16で正式リリースされましたが、Elasticsearchの新しいJavaのクライアントが出ています。 使ってみたので、ちょっとだけ紹介で","tags":["elasticsearch","java"],"title":"Elasticsearchの新しいJavaクライアント"},{"contents":"Azure Cognitive Searchで2月に新しい機能が公開されました。 「Index Alias」（インデックスの別名）です。まだ、パブリックプレビューの段階ですが、ドキュメントなどが公開されていたのでどんな機能かを調べてみました。なお、本ブログの内容は2022/05/18時点での内容となります、ご注意ください。\n公式ドキュメント まずは公式ドキュメントです。1つ目の「インデックスの別名を作成する」の冒頭で別名（エイリアス）がどんなものかを説明しています。\nインデックスの別名を作成する - Azure Cognitive Search | Microsoft Docs エイリアスの作成または更新 (2021-04-30-Preview) - Azure Cognitive Search | Microsoft Docs Alias Operations (2021-04-30-Preview) - Azure Cognitive Search | Microsoft Docs REST APIのドキュメント（2022/05/18現在、日本語のページだと左のメニューが壊れているため、どんなAPIがあるかがわかりにくいため、Alias Operationsのページは英語のリンクになっています）\nインデックスエイリアスってどんなもの？ 文字通り、インデックスにエイリアス（別名）をつけることができるようになります。 Azure Cognitive Searchでは残念ながらインデックスを作成するタイミング以外ではインデックスの名前を変更できません。 このため、インデックスのスキーマ（Analyzerの設定変更など）を変更したい場合、新しいインデックスを作成します。 新しいインデックスの名前はこれまでのものとは別の名前になってしまうため、アプリケーションで指定しているインデックス名も書き換える必要が出てきます。 利用しているアプリが複数ある場合は、すべて変更が必要です。\n今回出てきたエイリアスを利用することで、アプリケーションではエイリアスを指定することで、アプリケーション側の変更なくインデックスを入れ替えることができるようになります。\nエイリアスの操作方法 公式ドキュメントにAPIの一覧や利用方法の記載があるので詳細はそちらをご覧ください。 本ブログでは、いくつか利用するときに気になった点を書き残しておきます。\n作成 aliasesというエンドポイントにエイリアスの名前とインデックス名をPOSTすることで作成できます。 以下のサンプルは公式ドキュメントの例です。\nPOST /aliases?api-version=2021-04-30-preview { \u0026#34;name\u0026#34;: \u0026#34;my-alias\u0026#34;, \u0026#34;indexes\u0026#34;: [\u0026#34;hotel-samples-index\u0026#34;] } ちなみに、インデックスの指定がindexesで配列になっていますが、公式ドキュメントに以下の記述があり、複数の指定はできないです（エラーが返ってきます）。\nindexes 配列に指定できるインデックスの名前は 1 つだけです。\nまた、1つのインデックスに対して複数のエイリアスをつけることは問題ありません。\n確認 エイリアスのリストも取得できます。\nGET /aliases?api-version=2021-04-30-preview 現在どんなエイリアスが、どのインデックスに対して付与されているかがリストで取得できます。 きちんと作成されたかどうかなどの確認にも使えるかと思います（もちろんエイリアス名を指定したGETも可能です）\n検索での利用 検索のREST APIでインデックス名を指定していた部分をエイリアス名に置き換えるだけです。\nPOST /indexes/my-alias/docs/search?api-version=2021-04-30-preview { \u0026#34;search\u0026#34;: \u0026#34;pool spa +airport\u0026#34;, \u0026#34;searchMode\u0026#34;: any, \u0026#34;queryType\u0026#34;: \u0026#34;simple\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;HotelId, HotelName, Category, Description\u0026#34;, \u0026#34;count\u0026#34;: true } 更新 エイリアスの更新（インデックスの入れ替え）は作成と同じリクエストです。 更新が成功すれば204のステータスコードが返ってきます（エイリアス初回作成時は201） なお、ドキュメントには以下のような記述があります。入れ替え時の注意点になるかと（入れ替えのタイミングをきちんと制御したい場合は、少しだけアプリケーションを停止するなどが必要かと思います）。\n別名に対する更新がシステムに反映されるまでに最大 10 秒かかります。以前その別名が対応付けられていたインデックスを削除するのは、10 秒以上待ってからにしてください。\n削除 もちろん削除もできます。\nDELETE /aliases/my-alias エイリアスを利用する場合の注意点 便利なエイリアスですが、エイリアスが使用できない場合もあるので注意が必要です。\nデータ登録のAPIと検索のAPIでのみエイリアス名を利用可能 インデックスの設定変更やAnalyze Text APIではこれまで通りインデックス名を指定します。 また、エイリアス名はインデクサー機能でtargetIndexNameにも指定できません。 エイリアス名がついているインデックスは削除不可 エイリアスがついているインデックスを削除しようとした場合はエラーが出るようになっています。 まずはエイリアスを削除してからインデックスを削除するという手順になります。 まとめ 簡単ですが、インデックスのエイリアスに関しての紹介でした。まだパブリックプレビューなので正式リリース時点では利用方法が変わっている可能性もあります。こちらは注意してください。\n正式公開されればですが、今後Azure Cognitive Searchを使ったアプリを開発する場合はインデックスエイリアスを利用することを基本にするのがいいかもなと思います （ちなみに、Elasticsearchにもインデックスエイリアスの機能がありますが、異なる点が多いので同じものとは思わないほうがよさそうです）。\n","date":1652856857,"dir":"post/2022/","id":"7cc21814165879f72529e91682ece5c6","lang":"ja","lastmod":1652856857,"permalink":"https://blog.johtani.info/blog/2022/05/18/index-alias-in-azure-cognitive-search/","publishdate":"2022-05-18T15:54:17+09:00","summary":"Azure Cognitive Searchで2月に新しい機能が公開されました。 「Index Alias」（インデックスの別名）です。まだ、パブリックプレビューの段階です","tags":["azure search"],"title":"インデックスエイリアス - Azure Cognitive Searchの新機能"},{"contents":"年末までに知り合いと次の論文を読んだので軽くまとめておきます。\nExtreme Multi-label Learning for Semantic Matching in Product Search なんで読んだの？ 前回読んだ理由と一緒ですが、Semantic Searchに絡んだ検索の論文であり、Amazonの製品検索での話も関係していたので読みました。\nどんな論文？ Amazonの製品検索でセマンティックマッチングを利用する方法、レイテンシを低くしつつ再現率を改善できるような仕組みを検討して評価した論文です。 実際には商品検索のマッチングを大規模なマルチラベル問題（Extreme Multi-label Classification：以下ではXMC問題とする）として定義して、その問題を効率よく解く方法について検討評価しています。\n検索には大きく2つのフェーズがあります。マッチング（クエリにヒットした文書の集合を求める）とランキング（マッチングのデータを関連性の高い順序で並べる）です。 前回のMSの論文では、マッチング後のランキングのフェーズで言語モデルを利用した並び替えを行う話でした。 今回の論文ではマッチングに関してセマンティックサーチを有効活用できないか？という論文になります。 転置インデックスベースの（語彙による）検索では、スペルミスや類義語などを検索することが難しいです。 語彙以外のデータ（クリックや購入といったユーザーの行動や製品の意味的表現など）を学習できる埋め込みベースのニューラルモデルを活用して、マッチングを補完する方法を検討しています。 下図のようにあくまで転置インデックスベースの検索の補完として利用するみたいです（論文に掲載されていたアーキテクチャ）。\nXMC問題とは？ セマンティックサーチを行なう場合、埋め込みベースのニューラルモデル（例えばBERTとか）を利用することが多いですが、 クエリトークンを埋め込み空間にベクトル化する部分が推論のボトルネック（レイテンシが高くなる）になることが多いです。 これは、ニューラルネットワークの複雑さに依存します。 低レイテンシになるように、複雑ではないエンコーダーを用いることもありますが今度は性能（精度）が良くなくなります。\nそこで、この論文ではセマンティックマッチングをXMC問題として定義し、これを効率よく解くための手法を提案しています。 ここで、XMCの問題とは、入力（今回はクエリ）に対して、最も関連性の高い複数のラベル（今回は製品）を出力することとなります。 Amazonでの製品なのでほんとに大規模（ラベル＝製品＝1億件）です。\n従来のXMC問題を解くための手法として、疎な線形モデルの手法、パーティションベースの手法、グラフベースの手法などが列挙されています。 疎な線形モデルの手法では、ナイーブなOVR(one-versus-rest)だと出力となるラベルの数に対して線形に推論時間も大きくなるため、今回の用途には適しません。 この論文ではパーティションベースの手法として、推論時間を短くできるツリーベースで疎な線形モデルの手法を評価しています。\nどういう仕組み？ ツリーベースのモデルは次のような感じです。 PECOSのXR-Linearモデルを利用しています。 モデルに関する詳細についてはこちらの論文に詳しく載っているようです（まだ読んでいないです、、、）。\n一番上に入力として与えられるxがクエリ（ベクトル）で一番下の四角が製品にあたるラベル（Y={1,...,l,...L}）です。 これらが与えられたときに最も関連性の高い上位k件のラベル（製品）を出力するモデルを生成します。 モデルのパラメータは、学習データとして(x, y)(ここで、y∈{0, 1}^𝐿、すなわちクエリに製品がマッチするかしないかの二値)を使って調整します。\nこれは、ツリーのそれぞれの階層のノードで、その下の層に関連するデータがあるかどうか？という分類を学習すればよいことになります。 学習データとしては、入力と最下層のラベルにマッチするかどうかというデータです。 これをもとに、ツリーの最下層のデータをもとにひとつ上の層の分類器の学習をすればよいことになります。\n推論は出来上がったツリーベースのモデルに対して、ビームサーチで行ないます。 この時、それぞれの層のノードの分類器では推論の効率化のために枝刈りの閾値を設定しています。 本論文で閾値の違いによる精度とレイテンシの比較も行われています。 また、ビームサーチのビームサイズを変化させた場合の性能についても実験しています。\nどうやって検証した？ 次のようなデータを用いてAWS上にモデル構築、推論のシステムを用意し実験しています。\n10億件以上のポジティブなクエリ-商品ペアのデータセット クエリ：2億4千万、商品：1億 ポジティブなペアとは、クリック数や購入数の集計値が閾値以上。ただし、データセットとしては集計値は利用していない。 トレーニングセット：12か月分の検索ログ 評価用テストセット：1か月分の検索ログ（12％の製品はトレーニングセットには出てこない） というデーセットをもとに上記のモデルを学習しています。 特徴量はクエリテキストと製品のタイトルをもとにTF-IDFをいくつかのパターンで導出したものが使われています。 詳しくは論文の結果に関する表などを見ていただくとして。。。\n結果として、1億件の商品カタログで60.9%のRecall@100を1.25ミリ秒/リクエストという低レイテンシで達成したとなっています。\n気になる点は？ 知り合いと3人で読んでいて次のような気になる点が出てきました。\nツリーの構築をするときに、製品のラベルの並び順（製品のクラスタリング？に他製品が似た場所に来る感じ）が推論の効率の良し悪しに影響するんじゃないの？＝Amazonではないところではうまくいかない？ PECOSの論文読まないといけない？ 製品が増えたときにモデルの組み換えとかどうするの？ コールドスタート問題という形で今後の課題として書かれていたので、今後に期待 転置インデックスでのマッチングの補完として利用しているということだったけど、ランキングはどうしてるんだろう？ 別のランキング用の指標があるのかな？上位k件とした場合にどうやって、決めているのか？ モデル更新のタイミングはどのくらいのスパンなんだろう？ まとめ＆感想 セマンティック検索の処理を分類問題に置き換えてその手法を用いて行い、実際のシステムに適用できそうな速度と精度を出しているのが面白かったです。 セマンティック検索にもいろんな手法があるのだなと（そして、いろいろ勉強しないといけないんだなと。。。）。\n気になる点にも書きましたが、ツリーの作り方になにかコツがあるのか？他の検索結果と組み合わせるときに、どのような基準で上位を選択しているのか？など疑問点も残っています。 個人的には特にどのように既存のシステムにくっつけていくのかというところが気になっています。 論文の続編でその辺の話が出てくるのかなぁ？\nツリーの作り方に関するPECOSの論文を誰か解説してくれると嬉しいかもなぁと思いつつ、とりあえずブログに書き残してみました。参考になるかなぁ。。。\n参考文献 Extreme Multi-label Learning for Semantic Matching in Product Search - ACM Extreme multi-label learning for semantic matching in product search - Amazon Science PECOS： Prediction for Enormous and Correlated Output Spaces 数えきれないほどの分類を行うExtreme Classification - Technical Hedgehog ","date":1641980462,"dir":"post/2022/","id":"0645bdb1cdf88ec74288d503eb71839c","lang":"ja","lastmod":1641980462,"permalink":"https://blog.johtani.info/blog/2022/01/12/reading-xmc-for-semantic-search-in-prod/","publishdate":"2022-01-12T18:41:02+09:00","summary":"年末までに知り合いと次の論文を読んだので軽くまとめておきます。 Extreme Multi-label Learning for Semantic Matching in Product Search なんで読んだの？ 前回読んだ理由と一緒ですが、Semantic","tags":["search","paper"],"title":"Extreme Multi-label Learning for Semantic Matching in Product Searchという論文を読んだ"},{"contents":"今年も振り返りブログです。録画した紅白をオッかけ再生して気になるアーティストだけ見ながら書ています。\n振り返り（2020年に書いた抱負から） まずは去年の抱負を元に書きます。今年もコロナウィルスの影響が年末まで続き、ほとんどで書けなかったです。\nフリーランス継続? ありがたいことに個人事業主として無事1年を終えられました。 夏頃は5社ほどお手伝いをさせていただき、年末時点では3社をお手伝いさせていただいています。\n昨年の振り返りで書いた2社はありがたいことに継続していただいています。\n今年も完全リモートで仕事が終わりました。オミクロン株が来ているし、来年春くらいにはミーティングに出かけられるかなぁ。 相変わらず検索のお手伝いをしています。手伝いをしつつ勉強させていただいている感じです。 ありがたし。\nプログラミング ちょっとペースダウンしています。。。\nextract-kana-java 新しく書いたのはこれくらいかな。 SudachiやNeologdのkuromojiでフリガナを出力して違いを見るというコマンドツールです。 ちょっと比較してみたくなったので書いて公開しました。\nあとは、Sudachiをいろいろと触り始めています。 来年はそのへんをもうちょっと何かできるかなぁ。 コーディングしないとよくないなぁと思っているので、強制的になんかやらないとだ。\n検索の勉強 仕事でやってます。ブッチャー本は昨年買って手を付けてませんが。。。 来年は少しずつやる予定です。 あとは、Azure Cognitive SearchのSemantic Searchを触った関係でSemantic Searchに関する論文を探してちょっとずつ読んでいます。 知り合いと読んでいたAmazonの論文をブログにまとめるのは来年早々に。。。\n検索のポッドキャスト? これはできませんでした。重い腰が上がらない。 公開しないまでも雑談したいなぁ。\n振り返り(今年あったできごと) ここからは今年の出来事を。\n自宅環境 キーボード以外もDIY 検索Slack爆誕 車買い替えた WindowsノートPC買った 今年もずっと自宅で仕事でした。 昨年だいぶそろえていたのでそれほど変更はないですが。\n2月バージョン 切り替えてからずっとWindowsです。Macもブラウズ用に使ってはいますが。 ただ、Windowsといっても、プログラムなどに関する環境はほぼWSL2になっています。コマンドプロンプトは触ってないなぁ。 今年最後に更新された自宅環境は椅子になります。 詳しくは昨日のブログをご覧ください。\nキーボードもDIYしましたが、今年はほかにも少しDIYしました。\n今年のDIYキーボードとコントローラーラック このブログにも書きましたが、来年はキーマップやファーム関連を触っていきたいなと。あとロータリーエンコーダー。。。 BLE化は快適で、3台のPCの切り替えがとっても便利です。\ntakuya_aさんの鶴の一声で検索のSlackが爆誕しました。 検索に関連する情報交換ができる場として楽しませてもらってます。 年末には検索100本ノックの話が立ち上がってきています。 来年も面白い話が聞けそうでワクワクしています。\nあとは、車を買い替えました。初のハイブリッドです。 まだまだ慣れないですが、燃費とかがとても楽しみです。\n結局まだ出かけていませんが、出かけられるようにFMV Zeroを購入しました。 このブログもリビングでFMV Zeroで書いています（まだちゃんとセットアップしていないので、実際にはリモートデスクトップでデスクトップにつないでそこのVSCodeで書いちゃってますが。。。）。 ブログ書いたりコード書ける程度の環境は作らないとな。\n来年の抱負 ということで、来年の抱負です。\nフリーランス継続 プログラミング ブッチャー本ちゃんと読む 読んだ本のブログを書く 今年もありがたいことに仕事を継続していただけて、乗り越えられました。 来年も価値を提供できるように頑張っていきます。\nプログラミングは失速気味のでなにかテーマを見つけないとなあ。\nブッチャー本は読み始めます。必ずｗ\nブログのペースが落ちていたり、本を読むペースが落ちているので、 本を読んで自分のためにもブログを書こうと思います。 書いてないって思ったら叱咤してください。。。\n今年も出かけられませんでしたが、仕事も安定してあり、無事乗り切れました。 人と話をする機会は減っているので雑談したいな、オンラインなどで。 相手をしてやってもいいぞという方はぜひ連絡ください。\nさて、来年（もう年あけちゃったけど）は出かけられるかなぁ。 何はともあれ、今年もよろしくお願いします！\n","date":1640957359,"dir":"post/2021/","id":"104b8ee17a8bf1f7043d236659680493","lang":"ja","lastmod":1640957359,"permalink":"https://blog.johtani.info/blog/2021/12/31/looking-back-2021/","publishdate":"2021-12-31T22:29:19+09:00","summary":"今年も振り返りブログです。録画した紅白をオッかけ再生して気になるアーティストだけ見ながら書ています。 振り返り（2020年に書いた抱負から） ま","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2021）"},{"contents":"2021年もあと少しですが、今年買って良かったものをリストアップしておこうかと思います。 今年買ったといいながら、昨年このネタを書くといいつつ書いてないので、昨年の分も入っているかも？ Amazonのアフィリンクを貼っていますが、急いでないものはAliExpressで購入したりもしています。\n象印のポット Amazon | 象印 電気ケトル 1.0L コーヒードリップ用機能付き ホワイト CK-AX10-WA | 象印マホービン(ZOJIRUSHI) いわゆる電気ケトルというやつです。これが来るまでは鍋で湯を沸かしていました。 水を入れてボタンを押し、湯を沸かしている間に他のことができるのはやはり便利です。 また、コーヒーを入れるためのコーヒードリップモードがあるので、ドリップするためにわざわざ湯を他のものに入れたり、 専用のヤカンを使わなくても簡単にドリップができるのがさらに便利で重宝しています。\nウォータードリップコーヒーサーバー Amazon | iwaki(イワキ) コーヒーサーバー SNOWTOP ウォータードリップ ここ数年、冬以外は水出しコーヒーを飲んでいます。 麦茶のポットのような水出しコーヒー用ポットを使っていたのですが、滴下式のほうがえぐみが少ないというのを見かけてウォータードリップのサーバーに変えてみました。 このひとつ前に水のタンクの部分がプラスチックのものを利用していたのですが、ドリップする部分を壊してしまったので、部品を購入することができるこちらに切り替えました。 朝、仕事をする前に豆を挽いて仕込んでおくと、昼にはコーヒーが落ちています。 夏は入れ終わったポットごと冷蔵庫に入れておくと氷を入れなくてもアイスコーヒーが飲めるので気に入っています。\neufyの掃除機 Amazon | Anker Eufy HomeVac H11（ハンディクリーナー） USB充電 仕事に使っている机でプラモデルを作ったり、DIYキーボードの工作をしたりと細かなごみが出る作業を行ないます。 ちょっとごみを吸いたいだけなのに、掃除機を毎回取りに行くのも面倒なので充電式のクリーナーを買ってみました。 仕組みも簡単だし、USBで充電できるのでおすすめです。アタッチメントを利用してキーボードの掃除なんかもしています。\n電動精密ドライバー Amazon | Wowstick 1F\u0026#43; 69in1 電動精密ドライバー ビット56種セット ケース USB充電式 LEDライト付き [並行輸入品] キースイッチを付け替えたり、工作したりでねじの開け閉めを頻繁に行います。 思ったよりも頻度が高くなってきたので、電動の精密ドライバーを試しに使ってみたらすごく楽ができました。 電池の入れ替えなどでもねじの開け閉めは行なうので、すごく役に立っています。 ビットが56種類もついていますが、プラスとマイナス以外はまだ使ってないかも。。。\n磁石のUSBケーブル Amazon | SUNTAIHO マグネット充電ケーブル DIYキーボード、エネループの充電器、上記のドライバーや掃除機など、USBで充電したり、接続するものが結構あります。 毎回ケーブルを差し替えるのも大変なのですが、@ymotongpooに教えてもらった磁石のUSBケーブルがお気に入りです。 先端部分（USB-C、micro）とケーブル部分が別々になっており、また、ケーブルと先端は磁石でくっつく構造なので、充電したい機器に先端部分を刺しておきます。 充電や接続したいときにケーブルを近づけると磁石でくっついてくれるのでケーブルの抜き差しが必要なくなります。 先端部分だけを個別に購入できたので、色々な機器にあらかじめつけてあります。\nMaker hart Just Mixer 5 Amazon | Maker hart Just Mixer 5 ステレオ5入力音声ミキサー/Bluetoothオーディオ入力対応 3台のPC＋音楽サーバーとしてラズパイを主に利用しており、通知音などを1つのスピーカーから聞きたいので、ミキサーを導入しました。 5つの入力個別に音量調節できるので打ち合わせの時だけ他の音源を小さくしたりなど重宝しています。 ただ、入力が増えるとノイズが乗っている気もしますが。。。\nリストレスト（アームレスト） Amazon | エレコム リストレスト アームレスト 肘起き 扇形 左右で使える2個セット ブラック MOH-EL01BK 扇形のものを分割キーボードの手間においてリストレストとして使っています。 使用例の写真を見ると肘を置いていますが、手のひらをおくのにちょうどいいです。 これまでいくつかパームレストを試してみましたが、凹凸もなく適度な硬さで気に入っています。\nコンテッサセコンダ Amazon | オカムラ オフィスチェア コンテッサ セコンダ 10月に注文してクリスマスに届きました。部品が不足しているようで年内に届かないかもといわれていたのですが。 2003年くらいからアーロンチェアを使っていたのですが、さすがに買い替えるかということで奮発しました。 アーロンチェアは座面がメッシュなのですが、ももが疲れるのもあり、クッション座面のものにしてみました。 冬寒くないのがいいですねｗまだ届いたばかりなので調整しないと。\nKindle paperwhite Amazon | Kindle Paperwhite - 大きくなった6.8インチディスプレイ 防水機能搭載 wifi 8GB 電子書籍リーダー 車の点検などでちょっとした待ち時間があるようなときに新書や小説が読めるようにセールで安くなったタイミングで購入しました。 健康診断で読書がはかどりました。もっと本を読まないとなぁ。\nということで、ここ数年で買って便利なものをまとめてみました。 他にもある気がするけど、とりあえずこの辺で。\n","date":1640784504,"dir":"post/2021/","id":"218e2c36d5945ece02fdc55d6cbcbc38","lang":"ja","lastmod":1640784504,"permalink":"https://blog.johtani.info/blog/2021/12/29/best-buy-2021/","publishdate":"2021-12-29T22:28:24+09:00","summary":"2021年もあと少しですが、今年買って良かったものをリストアップしておこうかと思います。 今年買ったといいながら、昨年このネタを書くといいつつ","tags":["misc"],"title":"2021年かって良かったもの"},{"contents":"Azure Cognitive Searchのスキーマの確認をするときに、Azureのポータルでは次のようにフィールドの一覧として見ることができます。\nただ、実際のインデックス定義はJSON形式でやり取りする形になっています（JSONの例：Create Index | Microsoft Docs）。 上記のスクリーンショットのようにフィールド数が少ない場合はそれほど気にならないのですが、フィールド数が大きくなると一覧で見たくなることがあります。 また、ポータルを自分で確認できない場合にJSONファイルを受け取って確認することもあります。 こういう時は、Excel（CSV）って便利ですよね？\nということで、サクッと確認するときには、次のようなjqコマンドをWSL2上で利用して、CSVに変換して確認しています。\necho \u0026#34;Name\u0026#34;, \u0026#34;Type\u0026#34;, \u0026#34;Searchable\u0026#34;, \u0026#34;Facetable\u0026#34;, \u0026#34;Filterable\u0026#34;, \u0026#34;Retrievable\u0026#34;, \u0026#34;Sortable\u0026#34;, \u0026#34;Analyzer\u0026#34;, \u0026#34;IndexAnalyzer\u0026#34;, \u0026#34;SearchAnalyzer\u0026#34; \u0026gt; index_schema.csv cat index_schema.json | jq -r \u0026#39;.fields[]|[.name, .type, .searchable, .facetable, .filterable, .retrievable, .sortable, .analyzer, .indexAnalyzer, .searchAnalyzer]|@csv\u0026#39; \u0026gt;\u0026gt; index_schema.csv 例えばこんな感じになります（上記のポータルのスクショとは別のスキーマですが。。。）。\nどんなフィールドオプションが利用されているか？などをExcelで開いてフィルターなどを活用してチェックするのには便利かなと。 jqコマンドをもっとうまく使うと、ヘッダ行ももっとスマートに出せるかもしれないんですが。。。\nちなみに、上記のコマンドでは残念ながらEdm.ComplexType（参考： 複合データ型をモデル化する方法 - Azure Cognitive Search | Microsoft Docs）には対応していません。 必要になった時に考えるかな。。。\n","date":1640141671,"dir":"post/2021/","id":"f0fdc140e18514362a4e52376a6fecba","lang":"ja","lastmod":1640141671,"permalink":"https://blog.johtani.info/blog/2021/12/22/azure-search-schema-json2csv/","publishdate":"2021-12-22T11:54:31+09:00","summary":"Azure Cognitive Searchのスキーマの確認をするときに、Azureのポータルでは次のようにフィールドの一覧として見ることができます。 ただ、実際のインデ","tags":["azure search","misc"],"title":"Azure Cognitive SearchのIndex Schema JSONをCSVで見たくなる"},{"contents":"今年もアドベントカレンダーの季節になってしまいました。 今年で2回目となる、pyspa Advent Calendar 2021の投稿です。 昨年に引き続きDIYがらみの投稿です。\nコントローラーラック 3つのコントローラーがあるのですが、結構場所を取ります。 また、それぞれ充電しないといけません。\n充電しつつ、邪魔にならない置き方はできないものか？と思っていたところ次のようなコントローラーラックを見つけました。\nAmazon | 山崎実業(Yamazaki) ゲームコントローラー収納ラック これそのものは場所を取るので購入は見送りましたが、エレクターの棚にワイヤーネットをつけると似たようなものができるのでは？ということで、DIYしてみることにしました。\n材料 材料は以下の通りです。 書いていない材料としてあとは、結束バンドがあります。\nワイヤーネット４４×２９．５ｃｍ オフホワイトＢ２８ | 【公式】DAISO（ダイソー）ネットストア スリム型ネットフック５０ｍｍ ２本入り | 【公式】DAISO（ダイソー）ネットストア クロームメッキワイヤーフック（２連、Ｕ字、２個） | 【公式】DAISO（ダイソー）ネットストア Amazon | マグネット 充電ケーブル SUNTAIHO USBケーブル LEDインジケーター付き Amazon | Anker PowerPort Atom III Slim （PD 充電器 65W 4ポート USB-C） 設置 まずは、2連のワイヤーフックでワイヤーネットをエレクターの棚にぶら下げました。\nそのままでは固定されないので、下のエレクターの棚とワイヤーネットを結束バンドで固定。 これで、コントローラーを置いたり取ったりしてもぐらぐらしません。\n固定したワイヤーネットの表（コントローラーを配置する側）に、ネットフック50mmをコントローラーの数だけ配置しました（上の写真でフックとコントローラーの関係がわかります）。\n前から見るとこのような形です。 裏側に、2連フックを使って、Ankerの充電器を固定し、USBのケーブルをコントローラーの上に来るように配置します（写真ではPS4とPS5のコントローラーの上の部分にぶら下がる形です）。\nコントローラーには磁石の端子をコントローラーに差し込んでおきます。\n磁石のUSBケーブルを利用していることで、コントローラーを取り出すときは少し力を入れて引っ張るだけ、収めるときは、ケーブルに近づけて充電できる状態にした後にフックに載せるだけとなりました。 ケーブルの抜き差しをしなくてもよいのでとても便利。 全体像は次の写真のようになっています。一番上のコントローラーはエネループを利用しているのでケーブルは不要になっています。\n磁石のUSBケーブルをpyspaでとんぷーに教えてもらって思いついたアイデアです。 磁石の端子は色々と使い勝手が良いので、DIYキーボードやテンキー、MX Ergo、Kindleなど色々なところに使っています。\n今年のDIYキーボード キーボードを作ったのは2つですが、改造を色々やってました。 ブログに記載したものはリンクだけにしておきます。\nケーブル自作 自作ケーブルキット – 遊舎工房 ケーブルも自作できるみたいなので作ってみました。 現在はテンキーの配置の問題もあって、メインでは利用はしていませんが工作としては面白かったです。 熱収縮チューブを処理するための道具を持っていなかったので、チューブの固定が甘いのが失敗でした。ドライヤーくらいの熱では足りないので作ろうと思っている方は要注意かと。\nCorne Light v2のBLE+LPME-IO対応 詳細はブログ記事を。Corneはこれ以外に、キースイッチの付け替えも行ないました。ルブしたGateronクリアをハンダでつけなおしました。\nCorne Light v2のBLE+LPME-IO対応 #DIYキーボード Sofle keyboard v2のBLE+LPME-IO対応 詳細はブログ記事を。このブログはSofleで書いています。現在メインに利用しているキーボードです。\nSofle v2を組み立てて、BLE+LPME-IO化してみた #DIYキーボード 10月には電池モジュールを次のものに付け替えました。家で主に使用するのもあり、充電池のほうが使い勝手がよさそうだという判断です。スイッチのON/OFFもしやすくなって満足しています。\n単4電池昇圧モジュール - のぎけす屋 - BOOTH Sofleの電池モジュールをボタン電池から単4電池用に差し替えた。 pic.twitter.com/TUizwr2qmw\n\u0026mdash; Jun Ohtani (@johtani) October 16, 2021 Lunakey Miniの組み立てとBLE+LPME-IO対応 詳細はブログ記事を。Sofleと時々入れ替えて使っています。小指のあたりのずれの大きさ、親指のキーの多さが使い勝手のよいキーボードです。コンパクトなのもあり、こちらは持ち運びにも利用できるかなと考えています。\nLunakey Miniを組み立てて、BLE+LPME-IO化してみた #DIYキーボード Soyuzの組み立て（Numpadキット） Soyuz （黒基板） – 遊舎工房 自宅の作業環境(2021/02)の写真にもありますが、分割したキーボードとは別にテンキーを利用しています。 WindowsのログインでPinコードを入力したり、色々な場面で数字の入力をすることがあるためです。 Soyuzを組み立てる前は素 - Shiro – 遊舎工房を利用していたのですが、これでは「⁺」や「Enter」など、電卓のような利用方法の場合にはキーが足りません。 かゆいところに手が届かないので、きちんとしたNumpadをということでSoyuzを組み立てました。\nShiroよりもだいぶ存在感があります。\nGK21S（Numpad） USB Type C充電器付きの滑らかな交換用キーボードキット (Gk21s/k21),スイッチ,デュアルモードPCB|Keyboards| - AliExpress 最後は独身の日のセールで見つけたNumpadキットです。キットといってもこちらは、基盤からケースまで組み立てが終わっているキットで、キースイッチを差し込んで、キーキャップを付けるだけというものになります。 現在はこれをメインに利用しています。通常のNumpadの上に1列キーが多く、Backspaceなどを割り当てられるのが便利です。 ドライバーソフトも用意されており、キーマップのカスタマイズも可能です（まだそこまでやってないけど）。\nお気に入りキースイッチ Kailh Box Silent ピンク軸 5個 | Kochi Keyboard Input Club Hako スイッチ（10個入り） – 遊舎工房 最後はキースイッチの紹介です。 現時点ではこの2種類を組み合わせるのが私の好みに合っているようです（今のところ）。 Box Silentのピンクをアルファベットのキーに、Input Club HakoのVioletをCtrlやShift、Enterなどのキーに割り当てて使っています（下の写真の左側で、キーキャップをつけている部分がHako Violetになっています）。\nまとめ ということで、pyspa Advent Calendar 2021の8日目の記事でした。 それほど作ったりしてないなと思っていたのですが、記事にしてみると今年も色々とDIYしてたみたいです。 キースイッチやキーキャップも自分の好みが固まってきたので、来年はファームウェアやキーマップ周りをいじっていきたいと思っています。\n","date":1638889200,"dir":"post/2021/","id":"26e44dfd16a2963d4c18e99806c26fd7","lang":"ja","lastmod":1638889200,"permalink":"https://blog.johtani.info/blog/2021/12/08/controller-rack/","publishdate":"2021-12-08T00:00:00+09:00","summary":"今年もアドベントカレンダーの季節になってしまいました。 今年で2回目となる、pyspa Advent Calendar 2021の投稿です。 昨年に引き続きDIYがらみの投稿","tags":["DIYキーボード","misc"],"title":"今年のDIYキーボードとコントローラーラック"},{"contents":"Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだので軽くメモを残しておきます。論文自体はリンクから参照してください。\n読んだ理由 Azure Cognitive SearchでSemantic Searchが利用可能になったこともあり、「Semantic Search」に関するMSのリサーチチームが発表している論文をたまたま見つけたためです。 Elasticsearchとニューラルモデルを利用したランカーでのリランクする仕組みがSemantic Searchと似ていたので読んでみました。\nざっくりメモ どんなもの？ クリックログなどで関連度を改善できないような場合に、ドメイン固有の言語モデルを利用して検索結果の改善をする方法が提案されているので、バイオメディカル検索で実際に評価してみたという論文です。 特定分野の大量の文書から検索をするときに、ドメイン固有の事前学習した言語モデルを用意して、さらにファインチューニングする方法を評価しています。 言語モデルの生成に利用されたのはBERTになります。\n技術や手法のキモはどこ？ 医療分野のデータを利用して評価していますが、ほかのドメインにも一般化できる可能性があることや、実際のシステムを提示している部分が肝になりそうです。\n論文から引用した言語モデルを用いてランキングを行う仕組みを構築する部分の構成です。\n左半分が、ドメイン固有の事前学習についてです。Wikipediaなどを利用したBERTのモデルが公開されたりしていますが、大量のドメイン固有データが用意できるのであれば、ドメイン固有のデータで事前学習することが有効であるという主張です（参考文献。これもMS Researchでした。同じチームなのかな？）。 この論文ではBERTの学習データとして、ドメイン固有のテキストを用いています。 実際にはPubMedBERTを利用しています。\n右半分がドメイン固有のデータで生成された言語モデルを利用して、ドメイン固有のニューラルランカー（検索結果のランキングを行なう仕組み）をファインチューニングする処理です。 MS MARCOと呼ばれるMSが公開している機械学習向けのデータセットのうち、ドメイン固有のサブセットを取り出して利用しているようです。\nこの論文では、L1検索（第1段階の検索）にBM25を利用して、L2検索にここで作成したニューラルランカーを利用し、検索結果を返す仕組みとなっています。 これは、Azure Cognitive SearchのSemantic Searchのシステムに似ています。\nこの論文では、BM25で検索した結果の上位60件の結果がL2のランカーの入力となっています。\n以下の2つが主な論文の成果となっています。\nドメイン固有の事前学習を利用することで、高度な学習コンポーネントなどの追加することなく高い精度が出た。 既存のBM25の検索エンジンと組み合わせてニューラルランカーを使うことで、計算コストを下げつつより良い上位の検索結果を返す仕組みを構築した。 どうやって有効だと検証した？ TREC-COVIDデータセットを用いて評価して、TREC-COVIDに参加しているシステムと論文で提案している構成のシステムとの比較をしています。 また、ドメイン固有の事前学習が、一般ドメインなどの事前学習と比較して影響があるかどうかの評価もしています。\n実際にAzure上で構築した仕組みをMicrosoft Biomedical Searchとして公開しているようです。 上記のシステム構成のように、Elasticsearchで検索して、ニューラルランカーはKubernetes上に展開されたGPUで計算をしています。 論文には使用しているマシンの構成や台数なども記載があります。\n実際に構築したシステムをユーザーに利用して体験したもらった結果としては、 複雑な意図を持った長いクエリに対してはPubMedなどの他の検索ツールとしても良い結果が返ってきたことが確認されたとなっています。 ただし、一般的な短いクエリの場合は十分な結果にならない場合があったとのことです。\n議論はある？ 実際にほかのドメイン（金融、法律、小売りなど）で適用してもうまくいくかは今後の研究に期待だと思います。 また、ファインチューニングするときに利用できるデータが今回の論文にあるようにMS MARCOのサブセットとして抽出できればよさそうです。\n他に読むべき論文は？ TREC-COVIDに参加しているほかのシステムがどのような学習や仕組みが必要なのかを見ることで、どのくらいの手間・コストが軽減しているのかがわかるはずです。\n感想 ということで、読んでみました。 細かなほかの手法については調べていませんが、システム構成としてはAzure Cognitive SearchのSemantic Searchの仕組みと同じだと思われます。 違いは、ドメイン固有の事前学習のモデルではないことでしょうか。 ある程度のドメイン固有のモデルを利用できる仕組みができると、さらにSemantic Searchがうまく使えるようになるのかもしれません（前回書いたブログではWikipediaのデータを利用してみましたが、思ったほど良い感じはしなかったです。。。ファインチューニングの仕組みもないしなぁ）。 また、短いクエリでは芳しくない結果もあったというのは、おそらくニューラルランカーで評価するための情報が少なくなってしまうのだと思います。Semantic Searchに向いているクエリの作り方とかが出てくるのかな？\n","date":1636522396,"dir":"post/2021/","id":"35200cbf0b5b45d7f5f0b343cb18868b","lang":"ja","lastmod":1636522396,"permalink":"https://blog.johtani.info/blog/2021/11/10/reading-ms-biomedical-search-paper/","publishdate":"2021-11-10T14:33:16+09:00","summary":"Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだので軽くメモを残しておきます。論文自体はリンクから参照してください。 読んだ理由 Azure Cognitive S","tags":["search","paper"],"title":"Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだ"},{"contents":"今年もMICESにも参加してました。 昨年はBerlin Buzzwordsと共同開催でしたが、今年は別開催（別日程）でした。\nMICESは2017年から始まったe-commerceの検索にフォーカスしたカンファレンスです。 ECに関連する話に特化されていますが、話題は多岐にわたっています。色々やることありますねぇ、ECも。\n参加したセッション 参加したセッションの個人メモを今回も残しておきます。 セッション個別のリンクは用意されていないみたいですが、公式サイトにタイムテーブルがあり、セッションのタイトル、概要に加えて、スライドのPDFもリンクがあります。動画が公開されているものもあります。\nDreaming Search ビデオが公開されています。スライドがざっくりしたものなので最初に聞いた時にはしっくりこなかったので、聞き直してのメモです。 GDPRのような話で、個人の情報を自分たちで管理しようと流れがあります。 それぞれのECサイトなどでのユーザーのイベント（何を検索して、何をクリックした）情報はそれぞれのサイトで閉じた情報になっています。このため、自分の興味のある情報が断片化された情報でそれぞれのサイトで管理されてしまい、パーソナライゼーションされるもの（ランキングだったりレコメンドだったり）がいまいちな場合があります。 この個人の情報（ユーザーのイベント）をユーザー自身がハンドリングして、どの情報までをどこまで公開できるようにするというように管理できる仕組みができないか？という話のようでした。実際にそのための仕組み（もっと大きな話の仕様）を検討しているプロジェクトがあり、それに関連して検索という観点で夢を語っているセッションです。\nざっくり私が理解したのをまとめましたが、empathy.coという会社としてはいくつかPoCなども実施されているようでした。 個人の情報の扱い方に関する話は新鮮で面白かったです。 仕組みが出来上がり、各サイトが対応するとより個人が欲しい情報が集まりやすくなるのかなぁ？\nForget Facets, welcome Refinements (TM) Berlin BuzzwordsでいくつかLTをやられていた方によるファセットとその応用（彼らはRefinementsと名前をつけたみたい）についての話でした（ビデオとスライドが公開済み。）。 検索エンジンとファセットの関係の歴史から始まって、Kibanaでの使い方、モバイルや音声検索・チャットボットでのファセットは難しいよね？という話につながります。 ということで、Refinementsとして、ファセットを提示してユーザーに選んでもらうだけでなく状況に応じて、提案するための情報としてファセットを使うといいのでは？という話でした。例えば、チャットボットや音声検索での結果の場合、検索結果数が多くなるとユーザーが望んだものが返せるとは限らないです。その時に、ファセットの情報をもとに絞り込み条件を聞き返すネタに使うのはどうか？というような話でした。オートサジェスト（検索があいまいな時に、追加のキーワードを提案するもの）のような形でブランド名だったり、カテゴリーなどを表示する仕組みです。 実際の実装の話は、彼らが過去にBerlin Buzzwordsなどで話をしているのでそちらが参考になるとのことでした（参考：berlin buzzwords 2019 / Heystack 2019）\nReinforcement learning in search 検索における強化学習の話みたいです。ビデオとスライドが公開されています。ビジネス的に検索のランキングが重要だが、そのランキングをどうやって良くしていくのか？という話です。 ランキングでデフォルトのBM25から始まり、LtRを導入し、A/Bテストなどをしつつ、モデルの変化がどのようにビジネスに影響するかをはかるのが難しくなります。 LtRに対するオンライン機械学習のアプローチについて実際に直面した課題の話などがされている（はず？）です（どうも、実際にCTRなどを用いたところまでは行ってなさそう）。\n多腕バンディットなどの強化学習の話が続いたあたりでギブアップしてしまいました。。。\nBetter Search through Query Understanding - Panel Query Understandingに関するパネルとして3社の人がそれぞれどういった取り組みをしてるか？という話をしたあと質問などに答えていく形式でした。残念ながらビデオはまだ公開されていませんが、スライドが公開されています。QA部分も結構な時間だったのでビデオの公開がされるといいなぁ。\nUnderstanding queries by analysing user interaction / Andrea Schütt (OTTO) OTTOというECサイトでのQuery Understandingの紹介と、LtR導入にまつわる話。 データサイエンスとして最初はQuery Understandingやってたけど、スケールしないのでLtR導入して色々と試行錯誤しているところのようだった。\nQuery Understanding AI search eBayの方の発表。Query Understanding = ユーザーの興味をクエリから類推するという定義から、クエリを分類する、同定するためにどうしているか？という話でっした。 単語の表面的な文字としての近さだけでは、語順が変わると意味が変わるものや、ステミングのせいで同じになってしまうものといった例を紹介しつつ、クエリをベクトルにして表現（コンバージョン、クリックなどの情報を元にプロダクトのベクトルにしてみたり）し似ているかどうか？を判断している話です。\nCase study : Autocomplete Search Suggestions Digitec Galaxusというサイトでのオートコンプリートをもっと使いやすくするためにどんなデータを集めて、どうやって表示しているか？という話でした。 とりあえず入力されたものにヒットしたものを出すような実装だった場合に、サジェストされる量が多く、ノイズも多いので使いにくかったものをどうやって改善して行ったかという処理の流れなどの説明もありました。\nThe need for an open web search in Europe - The approach of the Open Search Foundation and its implications for E-Commerce-Companies Speaker: Alexander Decker / OPEN SEARCH FOUNDATION\nもっとオープンな検索システムを作っていこうという団体の話でした。 AWSが最近1.0をリリースしたやつとは別物です。 Googleでみんな検索しているけど、ブラックボックスなのでバイアスがかかっている。 もっとバイアスフリーなインデックスを提供できると、使いやすくなるよね？みんなでそういうインデックスを作っていかないか？という話でした。 ECとの直接の関係はセッションからは読み取れませんでした。 どうやって、集めるデータの基準（入れるべき、入れるべきではないなど）を作るんだろう？という疑問が残っています。公共的なものやオープンデータについてはあるとよさそうかもなぁ。\n101 hints to improving the customer satisfaction on search engines in the retail industry Speaker: Marion Hemery (Carrefour France) \u0026amp; Lucian Precup (a// \u0026amp; Adelean)\nカルフールのECサイトでの検索に関する顧客満足度の改善についての話です。 どんなものをどうやって図るのか、フィードバックを取るための仕組みは？ そこからわかったものをどうやってシステムに優先度をつけながら取り込んでいくのか？ というのをどんなものを使っているかという説明を交えながらのセッションです。 スライドが結構細かく書かれているのでスライドを見るだけでもわかりやすいかな。\n“An ounce of prevention is worth a pound of cure”: establishing a gold standard-based evaluation in customer projects Speaker: Bertram Sändig \u0026amp; Cornelia Werk / NEOFONIE\n検索の性能指標（速度ではないほうの性能）をきちんと評価する仕組みが重要だよというセッションです。 検索の仕組みを変更（例ではステミングを導入するはなしをしてました）した場合に、現行システムにどういう影響が出るのか？それをどうやって図るのか、どうやってテストしていくのか？という話です。 ステミングを導入したら、検索にヒットしやすくなったものも出てきたけどその弊害として今までよかった検索の結果にノイズが増え多という話をもとに、検索結果としてこうあってほしいというゴールデンスタンダードをきちんと作って育てていくべきですよという話でした。完ぺきなものなどないので少しずつやっていきましょうと。\nということで、見ていないもの（LTや最後のワークショップ）もありますが、見たものに関してメモを残してみました。\n","date":1626160103,"dir":"post/2021/","id":"10a7f69bd03d2632722300194f01e93d","lang":"ja","lastmod":1626160103,"permalink":"https://blog.johtani.info/blog/2021/07/13/attend-mices-2021/","publishdate":"2021-07-13T16:08:23+09:00","summary":"今年もMICESにも参加してました。 昨年はBerlin Buzzwordsと共同開催でしたが、今年は別開催（別日程）でした。 MICESは201","tags":["conference","berlin buzzwords","MICES"],"title":"今年もMICESにオンライン出張してた"},{"contents":"今年もBerlin Buzzwordsにオンライン出張してました。 今年の開催は6月14日から17日まででした。 どんなカンファレンスなのかは昨年のブログ記事をごらんください。\n今年はHAYSTACKは共同開催で、MICESは別開催でした。 MICESにも参加していたので、また後日にブログ記事を公開する予定です。\n参加したセッション 参加したセッションの個人用のメモを取ってあるので、簡単にまとめておきます。 セッションページに動画やスライドも追加されつつあります。興味のある方はそちらをご覧いただければと。 （今のところYouTubeに上がっているビデオは69本あります。再生リストはこちら） 気になっていたセッションもあるので、ビデオを見てまたメモを公開すると思いますが、まずは第1弾を。 ちなみに、検索をメインに見ています。Berlin Buzzwords自体はオブザバビリティやOSSコミュニティ、データのストリーミングの話などの話題もあるので、この辺りも興味があれば探してみても面白いかもです。\nHow to measure Diversity of Search Results セッションページ： How to measure Diversity of Search Results | Berlin Buzzwords 2021 従来の検索では、クエリに対して精度の高い検索結果を1件または数件返すのはどうするか？というものだったが、最近、あるユースケース（ほかの物の発見を促したいケース）では 検索結果の多様性を高めつつ、精度もある程度確保したいという場合があります。\nざっくりした検索クエリ（例えば自転車）の場合に、自転車だけが1ページ目にある場合よりも自転車とは別に自転車グッズも表示された場合のほうがクリック率やGMV（Gross Merchandice Value?）が上がったという話が紹介されていました。 この時どのくらい混ぜればいいのか？というのを、シャノンのエントロピーを使って、検索結果の多様性を保つための具体的なヒントについて話をされています。 実際にこういう計算をしてやれますねという紹介がされています。\nFrom text search and recommendation to ads and online dating; approximate nearest neighbors in real world applications セッションページ: From text search and recommendation to ads and online dating; approximate nearest neighbors in real world applications | Berlin Buzzwords 2021 Vespa.ai（OSS）の紹介でANNの話でした。通常、ANNを用いた検索の場合に他の検索条件（地理情報、日付など）をANNの結果に対して適用すると、望んでいる数がとれないです。その場合に、Vespaは内部でいい感じの動きをしますよという紹介でした。\n\u0026ldquo;Are You Sure?\u0026quot;： blending product comparisons and recommendations with A.I. セッションページ: \u0026ldquo;Are You Sure?\u0026quot;： blending product comparisons and recommendations with A.I. | Berlin Buzzwords 2021 Amazonの製品ページにある、類似商品との比較一覧のような一覧をどうやって実現するか？という話でした。比較一覧に掲載する商品を選出するパイプラインをこうやれますよね?という話でした。ログ（クリックやカートに入れたかどうかなど）を元にkNNで似ているデータを洗い出し、どの商品、どの項目を比較一覧として選ぶかという流れでした（セッションではもっと詳しい話がされています）。オフライン実験の話までがセッションでされています。\nThe future of Lucene\u0026rsquo;s MMapDirectory： Why use it and what\u0026rsquo;s coming with Java 16 and later? セッションページ: The future of Lucene\u0026rsquo;s MMapDirectory： Why use it and what\u0026rsquo;s coming with Java 16 and later? | Berlin Buzzwords 2021 Apache Lucene PMCのUweさんによるLuceneのMMapDirectoryの話です。 ファイルシステムとJavaに関する歴史と、なぜMMapなのか、現在のMMapの実装の問題点とJDK 16でどうなっているか（どんな感触か）、さらにその先（JDK17）は？という話です。 Luceneでの利用方法からJDKへのフィードバックが行われている話や、そのフィードバックをもとに今後どのようにしていくのか?という話がされています。\nSearch and Sushi; Freshness Counts セッションページ: Search and Sushi; Freshness Counts | Berlin Buzzwords 2021 こちらもVespa.aiの紹介です（今年はスポンサーしてるから多いのかも？）。Yahoo!とVerizon Mediaで利用している話をしたあと、Vespaでのリアルタイムインデキシングに関するアーキテクチャの紹介でした。内部で転置インデックスやそれ以外のデータをどのように保持しているのか？どういったことができるのか？というのをアーキテクチャ、ストレージの観点から紹介しています。\nEncores? - Going beyond matching and ranking of search results セッションページ(動画がまだない): Encores? - Going beyond matching and ranking of search results | Berlin Buzzwords 2021 検索のマッチングやランキング以外のいくつかの機能についての紹介をワークショップ形式で行うセッションです。ファセット、クエリオートコンプリート、スペル訂正、クエリリラクゼーションについて、データとSolrのクエリを基準に説明をしてくれます。\nThe Invasion of Transformers - Boosting Search with Latest NLP セッションページ: The Invasion of Transformers - Boosting Search with Latest NLP | Berlin Buzzwords 2021 deepsetという会社のCTOの方で、自社で作っているOSSのhaystackという製品の紹介です。 最近のGoogleの検索結果にはいろんなもの（問いかけに関する答えそのもの、またそのプレビューやサマリー）が出てきているという話から、Transformersを使って検索ができないかということで自社のOSSの仕組みを紹介しています。\n参考 Google： BERT now used on almost every English query deepset-ai/haystack： End-to-end Python framework for building natural language search interfaces to data. Leverages Transformers and the State-of-the-Art of NLP. Supports DPR, Elasticsearch, Hugging Face’s Hub, and much more! Learning to Judge セッションページ: Learning to Judge | Berlin Buzzwords 2021 otto.deというECサイトでLtRを導入し、そのLtRにどんな特徴を利用しどうやって実験したかというセッションでした。Apache Solrで検索ができていて、これまでは検索の管理を人手で行っていたがスケールしない（扱う商品などは増えているのに）のでLtRを導入し始めたという感じでした。LtRの導入の過程でどういう仮定を置いて、どうモデルを決め、それをどうやってテストしてどう分析したか?という流れでした。\nText categorization with Apache Lucene セッションページ: Text categorization with Apache Lucene | Berlin Buzzwords 2021 LTなので短めです。BBCのデータセットをインデックスに登録し、そのデータをもとにLucene（デモではKibana＋Esを利用していた）でテキスト分類を行なう方法について紹介しています。BBCのデータセットは記事（テキスト）とカテゴリ（タグ）というデータです。 このデータが登録されているインデックスに対して、More Like Thisクエリに分類したい文章を与え、ヒットしたデータをもとにAggregationでカテゴリを取得し、上位のカテゴリが分類された結果になるというデモでした。 テキストフィールドにはEdge N-Gramを利用していること、Aggregationのソートの条件はMore Like Thisクエリでのスコアの平均を利用していることというのがこの方法がうまくいくことのようでした（なるほど！）。ただ、日本語でもこれが使えるかな？というのはやってみないとわからないかなぁと（やってないです）。\nとりあえず、メモしておいたのはこの辺でした。 他にもセッション一覧を眺めながら面白そうな話をピックアップしてメモを取っていこうかなぁ？気になるセッション、メモがおかしいなどあればコメントいただければと。\n","date":1625815493,"dir":"post/2021/","id":"59b7b60e6bbf4858d72643d22ad90451","lang":"ja","lastmod":1625815493,"permalink":"https://blog.johtani.info/blog/2021/07/09/berlin-buzzwords-2021-1/","publishdate":"2021-07-09T16:24:53+09:00","summary":"今年もBerlin Buzzwordsにオンライン出張してました。 今年の開催は6月14日から17日まででした。 どんなカンファレンスなのかは昨年","tags":["conference","berlin buzzwords"],"title":"今年もBerlin Buzzwordsにオンライン出張してた"},{"contents":"Azure Cognitive Searchで新機能「Semantic Search（セマンティック検索）」という機能の日本語対応が発表されました。 実際にはPublic Previewという状態ではありますが、どんな機能か気になったので調べてみました。 なお、本ブログは2021年6月時点での内容となります。\n公式ドキュメント 公式ドキュメントでいろいろと説明されています。まずは公式ドキュメントを見ていただくのが良いかなと。最初のドキュメントには10分ちょっとの紹介ビデオもあります。ピックアップしたのは概要、クエリ、レスポンスの構造、紹介ブログになります。ブログ以外は日本語（たぶん機械翻訳？）になっています(新機能の紹介の日本語ページにはまだ記載がありません)。\nSemantic search - Azure Cognitive Search | Microsoft Docs Create a semantic query - Azure Cognitive Search | Microsoft Docs Structure a semantic response - Azure Cognitive Search | Microsoft Docs The science behind semantic search： How AI from Bing is powering Azure Cognitive Search - Microsoft Research 簡単にですがデータを入れて試してみたので、どんな仕組みなのかどういう挙動なのかを紹介します。\nSemantic Searchとは？ 言語理解、セマンティック関連性などを提供する機能です。BingとMSリサーチにより開発されて、Azure Cognitive Searchに導入されました。 クエリの書き方を少し変更する必要がありますが、再インデックスや設定変更などは必要ないという仕組みになっています。\n検索クエリからコンテキストを読み取って、検索し、リランクするアルゴリズム(Semantic Ranker) 関連する一節を強調表示（Semantic Caption） クエリに対するセマンティック回答(Semantic Answer) スペルチェック機能 言語によって利用できる機能が異なります。\nSemantic Searchの利点は先ほどの紹介にも書きましたが、インデキシング時に特殊処理をする必要がないことかなと。 すでに登録してあるデータ（制限がありますが）でもすぐに試すことができます。\n仕組み https://docs.microsoft.com/ja-jp/azure/search/media/semantic-search-overview/semantic-query-architecture.png\nスペル修正機能 クエリパース スコアリング 上位50件に対してSemantic Rankerにより再評価（検索ヒットが50件以上の場合でも上位50件のみがリランクの対象） 言語表現モデルを利用 結果の要約として最適な部分をキャプションとして抽出。 クエリが質問形式の場合は一番よさそうな場所を回答として選択 1および4番目の処理が今回新しく使えるSemantic Searchの機能になります。スペルチェックは日本語がまだ対象外なので、4番目の機能について紹介します。\n利用できる環境と制限 冒頭でも書きましたが、Public Previewの段階です。実際に利用するにはリクエストページから申し込みが必要になっています。\n利用リクエスト時に利用するAzure Cognitive Searchのサービス名が必要になるので、あらかじめ起動しておかなければいけません。 また、利用できるリージョンが限定されているのでサービス起動時のリージョンには気を付けてください。\n利用できるリージョン 米国中北部、米国西部、米国西部 2、米国東部 2、北ヨーロッパ、西ヨーロッパ 利用できるTier セマンティック検索はStandardレベル スペルチェックはレベル制限なし 価格（セマンティック検索のみ） 7月初旬までは25万クエリで500ドル Analyzerの制限 Azure Cognitive Searchが提供する言語アナライザーが対象（Custom Analyzerでは利用不可） サービス起動後にプレビュープログラムを申請すると、利用できるようになるとメールが届きます。そこから利用ができるようになります。\n今回は日本語のWikipediaのデータをいれてどんな機能なのかを確認してみました。\nWikipediaのデータを入れて試してみた 日本語のWikipedia（あとで英語も入れました）を一部（10万件程度）登録してSemantic Search（主にRanker）の動きを確認してみました。\nデータの登録には自作ツールを利用。\nJSONデータ生成ツール：https://github.com/johtani/wiki-extractor-rs JSONデータ登録ツール：https://github.com/johtani/wiki-json-loader 日本語Wikipediaの2020年6月のデータ、英語Wikipediaの2021年6月のデータを利用。上記ツールで生成したもののうち約10万件をAzure Cognitive Searchに登録して動作確認をしました（英語のデータでJSONデータ生成ツールでバグがあるのですが修正していません。。。）。 また、クエリの実行にはVisual Studio CodeのREST Client拡張(どんなものかは以前のブログをご覧ください)を使いました。簡単にREST APIを呼び出せるのはすばらしい。\n日本語のWikipedia 日本語のWikipediaのデータを「96,344件」登録し実験しました。 スキーマは次のような形です（説明に必要なものだけ抽出してあります）。自然分が入っているtitle、contents、headingsの3つのフィールドを今回はSemantic Searchの対象にしてみるので、AnalyzerをLuceneベースの日本語Analyzerであるja.luceneを設定しました。\nフィールド名 : タイプ / Analyzer id : Edm.String / keyword categories : Collection(Edm.String) / keyword title : Edm.String / ja.lucene contents : Edm.String / ja.lucene headings : Edm.String / ja.lucene Analyzerに言語Analyzerを設定するくらいで、他の設定は特に必要ありません。\nクエリとデータの確認 デモの動画や説明のサンプルを見たところ英語で「Where was Alan Turing born?」や「What\u0026rsquo;s the capital of France?」のような自然文のクエリが出てきたので、次のようなクエリで試してみました。\nフランスの首都はどこですか？ 実際にパリのページがインデックスに存在していることは以下のクエリで確認しました。\nパリ：3047件 POST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;パリ\u0026#34;, \u0026#34;top\u0026#34;: 10, \u0026#34;searchFields\u0026#34;: \u0026#34;title, categories, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id, contents\u0026#34; } ※ここで{{host}}などはREST Client拡張で変数として定義したものです。\nhost : Azure Cognitive Searchのサービス名 index-name : インデックス名 api-key : 接続のためのAPIキー URLパラメータのapi-version=2020-06-30-PreviewがPreview機能を呼び出すための指定になっています。\n3047件の1件目が「パリ」のページで以下のようなWikipediaの文章をセクションごとに文字列としてページ全体を配列に入れてcontentsに登録してあります。\n\u0026#34;パリ（、巴里）は、フランス北部、イル＝ド＝フランス地域圏にある都市。フランスの首都であり、イル＝ド＝フランス地域圏の首府である。\\nフランス最大の都市であり、同国の政治、経済、文化などの中心である。ロンドンと共に欧州を代表する世界都市。行政上では、1コミューン単独で県を構成する特別市であり、ルーヴル美術館を含む1区を中心に、時計回りに20の行政区が並ぶ（エスカルゴと形容される）。\u0026#34;, このインデックスに対して「フランスの首都はどこですか？」というクエリを、セマンティック検索のクエリと通常のクエリの2パターンで検索をしてみました。\nこれまでのクエリ（セマンティックではない検索） まずは通常のクエリです。 searchがクエリ文字列、searchFieldsが検索対象フィールドになります。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;フランスの首都はどこですか？\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34; } クエリを実行するとヒット件数が'13996\u0026rsquo;件で、トップ5件のデータは次のようになりました。\n\u0026#34;@odata.count\u0026#34;: 13996, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 17.059355, \u0026#34;id\u0026#34;: \u0026#34;462\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;首都\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 16.086372, \u0026#34;id\u0026#34;: \u0026#34;21053\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;首都圏\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 15.059893, \u0026#34;id\u0026#34;: \u0026#34;71414\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;どこでもドア\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 14.086605, \u0026#34;id\u0026#34;: \u0026#34;51972\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;首都機能移転\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.996841, \u0026#34;id\u0026#34;: \u0026#34;3877\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;首都の一覧\u0026#34; }, 見るとわかりますが、「首都」「どこ」といった単語を含むデータが上位に入っています。「フランス」を含むデータは8件目と10件目に「フランス植民地帝国」、「ラ・フランス」といったデータが出てきます。\n{ \u0026#34;@search.score\u0026#34;: 12.705561, \u0026#34;id\u0026#34;: \u0026#34;129279\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランス植民地帝国\u0026#34; }, ... { \u0026#34;@search.score\u0026#34;: 12.036648, \u0026#34;id\u0026#34;: \u0026#34;3173\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ラ・フランス\u0026#34; }, 残念ながら望んでいる結果にはほど遠いかと。\nどんな検索になっているのでしょうか？まずは、クエリの解釈から。 デフォルトで、Azure Cognitive Searchはデフォルトでは、入力された文字列をtype=simple、mode=anyで検索します（クエリパラメータ参照）。 対象となるフィールドはsearchFieldsで今回は指定してあるので、これらのフィールドに対して、入力された文字列を渡してAnalyzerで単語分割し（今回はsimpleクエリ用の特殊文字が入っていないため文字列として扱われる）、 出てきた単語で（mode=anyだから）OR検索します。 ja.luceneのAnalyzerが出力する単語列がどんなものかは以下のリクエストを実行するとわかります。\nPOST https://{{host}}/indexes/{{index-name}}/analyze?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;analyzer\u0026#34;:\u0026#34;ja.lucene\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;フランスの首都はどこですか？\u0026#34; } 結果は以下の通りです。\n\u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;フランス\u0026#34;, \u0026#34;startOffset\u0026#34;: 0, \u0026#34;endOffset\u0026#34;: 4, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;首都\u0026#34;, \u0026#34;startOffset\u0026#34;: 5, \u0026#34;endOffset\u0026#34;: 7, \u0026#34;position\u0026#34;: 2 }, { \u0026#34;token\u0026#34;: \u0026#34;どこ\u0026#34;, \u0026#34;startOffset\u0026#34;: 8, \u0026#34;endOffset\u0026#34;: 10, \u0026#34;position\u0026#34;: 4 } ] これで、どのような単語が出てきているかがわかりました。 それぞれのフィールドでどのようなスコアになっているかまではわからないですが、検索結果には上記3つの単語のいずれかがsearchFieldsにヒットすれば出てきます。おそらく、ヒットした単語数が多い、短い文字列のフィールドがより高いスコアになるというような動きになっていると思われます（BM25になってるはず）。\nセマンティック検索 では、セマンティック検索のクエリに変更してみましょう。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;フランスの首都はどこですか？\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34;, \u0026#34;queryType\u0026#34;: \u0026#34;semantic\u0026#34;, \u0026#34;queryLanguage\u0026#34;: \u0026#34;ja-jp\u0026#34; } queryType、queryLanguageがセマンティック検索のクエリを実行するためのパラメータになります（公式ガイド参照）。 今回は日本語のデータであるため、日本語のモデルを利用するようにqueryLanguageを指定します（許可されていない文字列を渡すとエラーになる）。 この2つを追加するだけです。簡単ですね。\n結果は次のようになります（上位5件抜粋）。\n\u0026#34;@odata.count\u0026#34;: 13996, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 12.036648, \u0026#34;@search.rerankerScore\u0026#34;: 2.3456064984202385, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;ラ・フランス\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;ラ・フランス\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;3173\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ラ・フランス\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 11.144733, \u0026#34;@search.rerankerScore\u0026#34;: 2.3173404783010483, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;ラン (フランス)\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;ラン\u0026lt;/em\u0026gt; (\u0026lt;em\u0026gt;フランス)\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;108094\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ラン (フランス)\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 11.144793, \u0026#34;@search.rerankerScore\u0026#34;: 2.1937477812170982, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;ブレスト (フランス)\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;ブレスト\u0026lt;/em\u0026gt; (\u0026lt;em\u0026gt;フランス)\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;116154\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ブレスト (フランス)\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 10.199907, \u0026#34;@search.rerankerScore\u0026#34;: 2.1590753793716431, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;フランス・ハルス\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;フランス・ハルス\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;81566\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランス・ハルス\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 11.273148, \u0026#34;@search.rerankerScore\u0026#34;: 2.1434053033590317, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;バカロレア (フランス)\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;バカロレア\u0026lt;/em\u0026gt; (\u0026lt;em\u0026gt;フランス\u0026lt;/em\u0026gt;)\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;54514\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;バカロレア (フランス)\u0026#34; }, 検索結果数を見ると、通常のクエリと同じ値です。 これは、公式ドキュメントのセマンティック検索に説明があるように、 セマンティック検索が通常のクエリで実行した後の検索結果に対して、上位50件のデータだけに対してsemantic rankerによってスコアを再計算するという仕様のためです（ドキュメントからの推測）。\n実際に検索結果の50件目、51件目は次のようになっていました。50件目までのデータには@search.rerankerScoreというスコア（と@search.captions）が追加されています。 51件目のデータについては、前の通常のクエリの51件目のデータと同じデータでした。\n{ \u0026#34;@search.score\u0026#34;: 10.909212, \u0026#34;@search.rerankerScore\u0026#34;: 0.07321979058906436, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;首都高速埼玉大宮線\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;67667\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;首都高速埼玉大宮線\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 10.049902, \u0026#34;id\u0026#34;: \u0026#34;68569\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;スタッド・ド・フランス\u0026#34; }, 上位5件のデータに戻ります。 これらは、通常のクエリとは異なる結果となりました。 見ると@search.captionsというところにハイライトされた項目が表示されています。 検索クエリをもとにそれっぽい部分がキャプションという形で返ってくる仕組みです。\n結果を見るとわかりますが、残念ながら「パリ」のページは返ってきませんでした。 もともと通常のクエリを実行したときの「326」番目の結果として返ってきているため、セマンティック検索の対象とはならなかったためです。 ただ、「首都」「どこ」といった単語よりも「フランス」に関するドキュメントが通常の検索よりも上位に来ています。 クエリに存在する単語で「フランス」がより重要であると判断されているようです。\nSemantic Rankerに処理させてみる ちなみに、今回登録したデータにはWikipediaのカテゴリも登録してあります。 「ヨーロッパの首都」というカテゴリで絞り込んでから検索してみるとどうなるかもやってみました。 filterのパラメータが絞り込み条件です。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;フランスの首都はどこですか？\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34;, \u0026#34;queryType\u0026#34;: \u0026#34;semantic\u0026#34;, \u0026#34;queryLanguage\u0026#34;: \u0026#34;ja-jp\u0026#34;, \u0026#34;filter\u0026#34;: \u0026#34;search.ismatch(\u0026#39;ヨーロッパの首都\u0026#39;, \u0026#39;categories\u0026#39;)\u0026#34; } 結果は次の通りです。カテゴリで絞り込みをしているので検索結果数は39件となります。このため、すべてのデータがSemantic Rankerの対象です。 ですが、「パリ」のページは11件目に出てきました。\n\u0026#34;@odata.count\u0026#34;: 39, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 3.8405614, \u0026#34;@search.rerankerScore\u0026#34;: 2.0472740978002548, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;ウィーン\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;9465\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ウィーン\u0026#34; }, ... { \u0026#34;@search.score\u0026#34;: 4.8915977, \u0026#34;@search.rerankerScore\u0026#34;: 1.8480307757854462, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;レイキャヴィーク\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;レイキャヴィーク\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;112253\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;レイキャヴィーク\u0026#34; }, ... { \u0026#34;@search.score\u0026#34;: 7.277628, \u0026#34;@search.rerankerScore\u0026#34;: 1.7982495501637459, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;パリ\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;パリ\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;31\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;パリ\u0026#34; }, キャプションは入力された単語だけではなく、クエリが持っている単語をもとにした何かしらの基準（おそらく言語モデルで近い単語？）で選択されていると思われます。首都というカテゴリーで絞り込んでしまったので、ヒットした文章が似たようなものが多くなったせいか、残念ながらそこまでSemantic Rankerが意図を汲み取るところまでは行きませんでした。\nフランスの歴史 視点を変えてみましょう。質問そのものの答えではなく、クエリの意図に近いものが出てくるかを見てみましょう。 ここまでのクエリでフランスに関するクエリを投げていました。今回のインデックスに「フランスの歴史」で検索すると「30820」件のドキュメントがヒットし、上位にはフランスには関係ない「歴史」のページや「フランス」の文学、都市など「フランスの歴史」とは少し離れた意味のものが上位に来ています。\n\u0026#34;@odata.count\u0026#34;: 30820, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 12.888079, \u0026#34;id\u0026#34;: \u0026#34;17875\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;スコットランドの歴史\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.718105, \u0026#34;id\u0026#34;: \u0026#34;10665\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;世界の歴史\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.701981, \u0026#34;id\u0026#34;: \u0026#34;31397\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ベトナムの歴史\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.579847, \u0026#34;id\u0026#34;: \u0026#34;22433\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランス文学\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.524254, \u0026#34;id\u0026#34;: \u0026#34;34667\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランスの国旗\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.52136, \u0026#34;id\u0026#34;: \u0026#34;108094\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ラン (フランス)\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.41088, \u0026#34;id\u0026#34;: \u0026#34;20717\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;歴史小説\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.388911, \u0026#34;id\u0026#34;: \u0026#34;56229\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;演劇の歴史\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.343941, \u0026#34;id\u0026#34;: \u0026#34;39669\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;イギリスの歴史\u0026#34; }, このクエリをセマンティッククエリで検索すると次のようになりました。\n\u0026#34;@odata.count\u0026#34;: 30820, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 12.274498, \u0026#34;@search.rerankerScore\u0026#34;: 1.482184374704957, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;自由フランス\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;自由フランス\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;96475\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;自由フランス\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 11.446766, \u0026#34;@search.rerankerScore\u0026#34;: 1.3535655084997416, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;フランスの地域圏\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;フランスの地域圏\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;51845\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランスの地域圏\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 10.926437, \u0026#34;@search.rerankerScore\u0026#34;: 1.3261859538033605, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;フランス第一帝政\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;フランス第一帝政\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;57573\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランス第一帝政\u0026#34; }, 上位には「フランスの歴史」に関連しそうなタイトルが上がってきています。 また、先ほど「歴史」という単語でヒットして上位に来ていた「スコットランドの歴史」は@search.rerankerScoreの値が低くなっていました（31件目に出現）。\n{ \u0026#34;@search.score\u0026#34;: 12.888079, \u0026#34;@search.rerankerScore\u0026#34;: 0.42768346797674894, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;スコットランドの歴史\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;17875\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;スコットランドの歴史\u0026#34; }, 考察 日本語のWikipediaを約10万件入れたインデックスでセマンティック検索を試してみました。 デモや説明などでクエリが自然文の質問だったこともあり、質問の回答になりそうなページが上に来るかと期待しましたが、期待しすぎました。\nこれは、Azure Cognitive Searchのセマンティック検索の仕組みを考えると納得のいくものです。 説明を読んだ時にも感じたのですが、入力された文字列でまず検索をし、上位50件をセマンティック検索の対象としています。\nですので、そもそもクエリの文章に出てくる単語が含まれたデータだけが対象となります。 このため、クエリに出てこない単語のみで構成されているものは残念ながら対象とできません。 また、上位50件だけがSemantic Rankerの対象となっているため、検索にヒットしたとしても上位に食い込まなければ言語モデルによるランキングの対象にもなりません。 セマンティック検索といっても、残念ながらドキュメントに出てこない単語（似た単語、質問に対するそのものの回答）まで読み取る機能はありません。\nただ、「フランスの歴史」の検索で見たようにそれぞれの単語だけで検索をしていた場合とは異なり、 クエリの意味に沿ったスコアづけにより、通常の検索よりも意図したものに近いデータが出ていることが確認できました。 複数の単語で構成されるクエリの場合に、単語だけでスコアを計算した場合よりもよさそうな結果が上位に出てくることがわかりました。\nただし、重要なのは「上位50件」までしかSemantic Rankerの対象にはならない点です。\n英語のWikipedia セマンティックは英語対応が一番最初にリリースされているので、英語のWikipediaについてもデータを登録してみました。\n英語のWikipediaのデータを「111,649件」登録しました。 スキーマは以下の通り（今回の調査に利用していないものは省略）です。日本語と異なる点はAnalyzerがen.luceneになっていることぐらいです。\nフィールド名 : タイプ / Analyzer id : Edm.String / keyword categories : Collection(Edm.String) / keyword title : Edm.String / en.lucene contents : Edm.String / en.lucene headings : Edm.String / en.lucene クエリとデータの確認 日本語同様に首都に関する質問形式にしてみました。\nWhat\u0026rsquo;s the capital of Italy? 実際にRomeのページがインデックスに存在していることは以下のクエリで確認済みです。\nRome：2302件\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;Rome\u0026#34;, \u0026#34;top\u0026#34;: 10, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id, contents\u0026#34; } 以下のようなWikipediaの文章をセクションごとに文字列としてページ全体を配列に入れてcontentsに登録してあります（これも日本語と同じです）。\n\u0026#34;\u0026#34;\\n\\nRome (Italian and Latin: Roma ) is the capital city and a special comune of Italy (named Comune di Roma Capitale), as well as the capital of the Lazio region. The city has been a major human settlement for almost three millennia. With 2,860,009 residents in , it is also the country\u0026#39;s most populated comune...\u0026#34;, このデータ群に対して「What\u0026rsquo;s the capital of Italy?」というクエリを、Semantic Searchのクエリと通常のクエリの2パターンで検索をしてみる。\nこれまでのクエリ（セマンティックではない検索） まずは、Semantic Searchではないクエリです。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;What\u0026#39;s the capital of Italy?\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34; } ヒット件数は18049件で、トップ5件は次のような形です。\n\u0026#34;@odata.count\u0026#34;: 18049, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 17.870815, \u0026#34;id\u0026#34;: \u0026#34;14532\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Italy\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 16.596167, \u0026#34;id\u0026#34;: \u0026#34;14702\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Economy of Italy\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 16.180624, \u0026#34;id\u0026#34;: \u0026#34;183878\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Louis II of Italy\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 15.917025, \u0026#34;id\u0026#34;: \u0026#34;29665\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;State capitalism\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 15.88901, \u0026#34;id\u0026#34;: \u0026#34;215741\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Capitalization\u0026#34; }, 日本語の場合よりもItalyに関連するものが上位に多く含まれます。 ただ、Rome自体のページは上位50件には出てきていませんでした。 また、capitalとは意味の異なるcapitalizationやcapitalismが上位に来ています。 日本語の場合と同様にクエリがどのように解釈されているのか？も見てみます。\nPOST https://{{host}}/indexes/{{index-name}}/analyze?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;analyzer\u0026#34;:\u0026#34;en.lucene\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;What\u0026#39;s the capital of Italy?\u0026#34; } 結果は以下の通りです。\n\u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;what\u0026#34;, \u0026#34;startOffset\u0026#34;: 0, \u0026#34;endOffset\u0026#34;: 6, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;capit\u0026#34;, \u0026#34;startOffset\u0026#34;: 11, \u0026#34;endOffset\u0026#34;: 18, \u0026#34;position\u0026#34;: 2 }, { \u0026#34;token\u0026#34;: \u0026#34;itali\u0026#34;, \u0026#34;startOffset\u0026#34;: 22, \u0026#34;endOffset\u0026#34;: 27, \u0026#34;position\u0026#34;: 4 } ] 日本語とあまり変わってはいません。ただ、単語が入力されたものとは少し変わっています。 これは、en.luceneの処理で、stemmingが行われているためだと思われます。たとえば、「capital」の場合、Stemmingにより「capital」「capitalize」などの単語が元になりますが、動詞、名詞などの違いなく検索できるようにするためにこのようなStemmingの処理が行われます。 ということで、これらの単語を含むドキュメントがヒットしています。Italyが一番上に来ているのはItalyという単語が多く含まれるからのようです。\nSemantic Searchクエリ では、Semantic Searchのクエリに変更してみましょう。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;What\u0026#39;s the capital of Italy?\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34;, \u0026#34;queryType\u0026#34;: \u0026#34;semantic\u0026#34;, \u0026#34;queryLanguage\u0026#34;: \u0026#34;en_us\u0026#34; } queryType、queryLanguageがsemantic searchのクエリを実行するためのパラメータになります（公式ガイド参照）。 今回は英語のデータであるため、英語のモデルを利用するようにqueryLanguageを指定します（許可されていない文字列を渡すとエラーになる）。\n結果は次のようになります（上位5件抜粋）。\n\u0026#34;@odata.count\u0026#34;: 18049, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 17.870815, \u0026#34;@search.rerankerScore\u0026#34;: 1.9688458815217018, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Italy\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;14532\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Italy\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 14.239678, \u0026#34;@search.rerankerScore\u0026#34;: 1.9419755563139915, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Capital city\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;181337\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Capital city\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 10.181764, \u0026#34;@search.rerankerScore\u0026#34;: 1.8902588561177254, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Lepontii\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;325133\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Lepontii\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 10.865718, \u0026#34;@search.rerankerScore\u0026#34;: 1.875102698802948, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;ItalY\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;14482\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ItalY\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 11.689348, \u0026#34;@search.rerankerScore\u0026#34;: 1.8201303631067276, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Savoy\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;27885\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Savoy\u0026#34; }, 日本語で見てきたように、検索結果数を見ると、通常のクエリと同じ値で、残念ながら50件までにRomeは入っていないため、Semantic Rankerによるブーストもかかりませんでした。 ただし、「Capitalization」や「State capitalism」といった別の意味（地理に関するものではない単語）のものが上位に出てこなくなっています。 これは、capitalという単語が地理に関する意味を持っていると判断された結果のように見えます。 Capitalizationの@search.rerankerScoreは上位のスコアに比べて小さいものとなっています。\n{ \u0026#34;@search.score\u0026#34;: 15.88901, \u0026#34;@search.rerankerScore\u0026#34;: 0.93921028636395931, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Capitalization\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;215741\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Capitalization\u0026#34; }, What\u0026rsquo;s the capital of Finland? 上位50件以内(20件目)に「Helsinki」のページが出てくるクエリでセマンティック検索をしてみました。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;What\u0026#39;s the captial of Finland?\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34;, \u0026#34;queryType\u0026#34;: \u0026#34;semantic\u0026#34;, \u0026#34;queryLanguage\u0026#34;: \u0026#34;en-us\u0026#34; } 結果としては、2件目にHelsinkiが返ってきていたので、Semantic Rankerがによる並び替えがうまくいきました。 （下記の結果は上位3件を抜粋したものです）。\n\u0026#34;@odata.count\u0026#34;: 16673, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 14.026371, \u0026#34;@search.rerankerScore\u0026#34;: 2.42378556355834, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Vanaja (Finland)\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;7132102\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Vanaja (Finland)\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.434971, \u0026#34;@search.rerankerScore\u0026#34;: 2.383675143122673, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Helsinki\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;13696\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Helsinki\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 13.380153, \u0026#34;@search.rerankerScore\u0026#34;: 2.2026549801230431, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Rauma, Finland\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;178635\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Rauma, Finland\u0026#34; }, 考察 今回の英語のクエリではSemantic Rankerがある程度の役割をはたしていそうだということはわかりました。 Capitalがいくつもの意味を持っていることもあり、文章をもとにより意味の近いドキュメントが上位に来たということです。 ただ、英語の場合も基本的には上位50件以内のデータに対して処理が行われるので上位50件以内にデータが入らなければうまくいかないようです。\nまとめ Azure Cognitive Searchの新機能であるセマンティック検索について調べてみました。 まだPublic Previewですが、簡単に使えるような仕組み（データの再登録なし、クエリでパラメータを追加するだけ）が用意されているのは便利でした。 ただ、最初に想像していたもの（私の早とちりもありますが）ほどのセマンティック検索とは行きませんでした。 似たような言葉の意味を持ったものを探してくれたり、答えそのもののページのスコアがすごく高くなるといったものではありませんでした。\n仕組み上、クエリに含まれる単語で検索し、上位50件以内のデータだけが対象になる(残念ながら現時点ではこの件数の変更はできません。)ため、これまでの検索とは劇的に変化するものではないことはわかりました（銀の弾丸はないんですけどね）。\nある程度の挙動をわかっていれば、Wikipediaのようなデータでもそれなりの結果は取得できそうだということはわかりました。\n「言語モデル」でクエリとヒットしたデータをもとにスコア計算をし直しているようですが、この部分がどのようなデータ・クエリだと有効活用できるのか？というのをもう少しいろいろな角度で試してみる必要がある気がします（適材適所が何なのか？）。 あとは、上位50件までが対象なので、それ以上の件数のデータの並びに関してはこれまでと同様の結果となる点は注意しないといけません。 また、今回試していないほかの機能（スペルチェック、Semantic Answerなど）にメリットがあるのかもしれません。\nざっくりですがセマンティック検索について調べてみました。 こんなデータだとどうなの？ここの考え方が間違ってるのでは？などの指摘がありましたら、コメント欄またはTwitter（@johtani）でコメントを頂けたらと。\n","date":1625130583,"dir":"post/2021/","id":"43caef5d41c4e74826e4a8d82088739d","lang":"ja","lastmod":1625130583,"permalink":"https://blog.johtani.info/blog/2021/07/01/semantic-search-in-azure-cognitive-search/","publishdate":"2021-07-01T18:09:43+09:00","summary":"Azure Cognitive Searchで新機能「Semantic Search（セマンティック検索）」という機能の日本語対応が発表されました。 実際にはPublic P","tags":["azure search"],"title":"Azure Cognitive Searchの新機能、Semantic Searchを試してみた"},{"contents":"Sofle v2を長らく使っていましたが、コンパクトなのもやっぱりいいよなぁというときにKochi KeyboardからLunakey Miniが発売していました。 小指のあたりの傾斜が使いやすいかも？ということで、組み立ててみました。\nもちろん購入はKochi Keyboardさんからです（購入はこちらから）。\nLunakey Miniビルドガイド 作者のYoichiroさんが公開しているビルドガイドが詳細まで書かれています。 こちらをまずは参照してください。\nLunakey Mini ビルドガイド (Rev.4以降) ビルドログ（主にツイート） 私の組み立てについては、Twitterでツイートしていたものがありますので、そちらを貼っておきます。 ちなみに、ツイートしていて躓いているときに、作者のYoichiroさんからたびたびコメントをいただきました。 ありがとうございました！！\n間にいくつかコメントを差し込んでいます。\n結局両方のダイオードつけてしまいました。今日はここまで pic.twitter.com/3qLI6EpfXB\n\u0026mdash; Jun Ohtani (@johtani) April 12, 2021 ハンダはつけた pic.twitter.com/ySE9SA3gZn\n\u0026mdash; Jun Ohtani (@johtani) April 13, 2021 コンスルー問題 左手じゃん、T。Tのダイオード浮いてた。右手も一回全部見直すか\n\u0026mdash; Jun Ohtani (@johtani) April 13, 2021 ここで問題が発覚。右手（ツイートではぼけていて、左手と書いています）についてはダイオードが1か所浮いていただけなので、はんだ付けですぐ直りました。 左手側が大問題です。そもそも右手につけたProMicroへの書き込みができませんでした。 キーボードによっては、ダイオードなどを付ける前からまず、リセットボタンを付けて、ProMicroを指して書き込みをする場合もあります。 ただ、その書き込みができない。 （ちなみにこのタイミングでテスターをつけっぱなしにしていたのが発覚し、9V電池切れのため翌日に持ち越した。。。）\nさて、デバッグのお時間です pic.twitter.com/CaEOv4E5Bg\n\u0026mdash; Jun Ohtani (@johtani) April 14, 2021 ただ、ProMicro刺した状態で、リセットボタン、リセットボタンの足をショートさせても書き込みはできず、ProMicroのGndとResetの足のショートでは書き込みができる。\n\u0026mdash; Jun Ohtani (@johtani) April 14, 2021 テスターで調べてみたところ、リセットボタンとProMicroがうまく通電していません。\nだいぶ進んだけど、Eの列がおかしいなぁ。さて、どこの接触だ？ pic.twitter.com/5tci12Vk05\n\u0026mdash; Jun Ohtani (@johtani) April 14, 2021 どうも、左手の基盤のProMicroの足の穴がコンスルーとの接触が悪いみたいでした。 コンスルーの足を無理やりまげて（3個のコンスルーの足を折りました。。。）、通電できるようにして解決（結局あとでいくつかの足についてははんだ付けしました）。\n終わった。LEDの予備はんだまでやってからおしまいにしよ\n\u0026mdash; Jun Ohtani (@johtani) April 16, 2021 LED実装 鬼門の表面実装ですが、LEDを1個破損するだけで乗り切りました。ちょっと色はおかしかったですが、これはおそらくProMicroの足のせい。\n一個逆につけてしまい、お亡くなりになりましたが、まぁ、良いかな。まずは右手 pic.twitter.com/zldu6fRsXR\n\u0026mdash; Jun Ohtani (@johtani) April 18, 2021 ソケットの実装x2 ロープロファイル（Kailh choc v1）のキースイッチも試してみたいので、MXと両方のソケットをはんだ付けしました。 両方利用できるのは便利ですね。はんだ付けも楽しいし。\nソケットを片手だけ(両方のソケットつけるのでまだ、1/4) pic.twitter.com/7XFRDx0D0I\n\u0026mdash; Jun Ohtani (@johtani) April 18, 2021 キースイッチ設置 親指以外にはKailh Box Silentのピンク軸（Kochi Keyboardから）、親指にはKailh Input Club Hako Violet（AliExpressで購入したもの。リンクは遊舎工房のもの）をつけました。 どちらもそれほどぶれもないものです。Silent ピンクはリニアで静かでそれほど力がいらないスイッチになっています。 親指はタクタイルで小気味のいい音が気に入っています。Sofleもこのキースイッチになってます。\n残りのソケットつけて、キースイッチも設置して、動確してボトムプレートも装着。残りはキーキャップ。 pic.twitter.com/hGc1TtI6fu\n\u0026mdash; Jun Ohtani (@johtani) April 25, 2021 キーキャップ＋キーマップ お試しにXDAのキーキャップをはめてみたのですが、キーの境目がわかりにくく、タイプミスが多かったです。 その後のツイートにあるようにOEMに切り替えています。\nキーマップについては、Lunakey Miniの作者のYoichiroさんが作ったRemapというブラウザベースでキーマップの書き換えができるツールで楽々変更ができました。JISキーまで対応しているのでJISベースでキーマップを作成している私にはうってつけでした。 Remapの利用方法についてはサリチル酸さんのブログが詳しく書いてあります（本当に頭が下がります）。\nRemap使ってキーマップいじったら、すごく楽だった。\n\u0026mdash; Jun Ohtani (@johtani) April 26, 2021 BLE + LPME-IO化 ここまでで、USB接続で動作はしていたのですが、Sofle同様に3台をBluetoothで切り替えながら使いたかったので、 Corne Light v2につけていたBLE+LPME-IO(Corneの実装などは前のブログを参照)を抜き取って、Lunakey Miniに移植してみました。\nBLE ProMicro化は作者の方のブログで行われていたので、LPME-IO対応も何とかなるだろうと。\nBLE+LPMEに変えた。後でブログ書こう pic.twitter.com/mGePN52v6k\n\u0026mdash; Jun Ohtani (@johtani) April 29, 2021 LPME-IOへの対応はCorneとSofleの時に行なったこともあり、なんとなくあたりがついていました。 流れとしては、以下の通りです。\nBLE Micro Pro用の設定ファイルを作成 BLE Micro Proのサイトの「キーボードの設定ファイルを編集する」のコマンドでコンフィグファイルを生成 LPME-IOのジャンパをはんだでブリッジ 1.で生成したコンフィグから、Corne Lightと同じ個所のジャンプをすれば良いとわかったので今回はスキップ TRRSのI2C対応 Corne LightのLPME-IO対応の時と同様にSDAとSCLをTRRSの足にショートカット ただ、今回右手側は、下記ツイートのようにOLEDの足からTRRSの足にショートカットしました。Corneの基盤を見ていた時にこれでも行けそうだな？と思っていたので、試してみた次第です。ちなみに、左手はCorneの時と同じPro Microから長い銅線を引っ張っています（電池基盤があったので、外すのがめんどくさかったため）。 BLE Micro Proにファームウェア書き込み BLE Micro Proのサイトの手順に従います。 設定ファイルには1.で出力されているLPME用のファイルを使用。 といった感じです。キーマップが設定されていないので、Remapで設定しなおしました。 Remapは、キーマップをPDFで出力する機能までついていて、すごくいいですね。サイコー\nあと、足。 pic.twitter.com/W0Wpf5k5SE\n\u0026mdash; Jun Ohtani (@johtani) April 29, 2021 傾斜がつくように奥側に高さを出すためのゴム足を貼り付けました。 あとは、3台のPCにBluetoothで接続すれば終了です。 （AD_WO_Lのキーを利用して追加していくのを毎回忘れる。。。）\n疑問点 ちょっとだけ疑問点がありますが、時間があればそのうち調べるかな。\nRemapはクラウドに設定ファイルをセーブできるけど、json形式で手元にダウンロードしたりはできないのかなぁ？ LEDは有線じゃないと点かないみたいだけど、音はどうなんだろう？ 音が出せそうなら、Bluetoothの接続切り替えするときに音の出方を変えるとかをやってみたいなぁ。 まとめ ということで、Lunakey Miniを組み立てて、BLE+LPME-IO対応してみました。 はんだ付けはだいぶ慣れてきましたし、今回もトラブルがあったおかげでテスターを利用して、どのあたりがおかしいかという調査をするのも慣れてきました。 あとは、キーの配置の違いを体感して、どれが自分に合ってるかなぁ？というのを試したり仕様と思います。 ロープロファイルも試してみようかな。\nあ。もちろん、このブログは組み立ててBluetoothで接続したLunakey Mini Rev5、Kailh Box Silentピンク軸＋Input Club Hako Violetで書きました！！久々に数字列がないので記号入力とかがちょっとバタバタしましたｗ\n","date":1619709972,"dir":"post/2021/","id":"f4baa43cc7ca712d83b99a794c4e2dbd","lang":"ja","lastmod":1619709972,"permalink":"https://blog.johtani.info/blog/2021/04/30/build-lunakey-mini-ble/","publishdate":"2021-04-30T00:26:12+09:00","summary":"Sofle v2を長らく使っていましたが、コンパクトなのもやっぱりいいよなぁというときにKochi KeyboardからLunakey Miniが発売して","tags":["DIYキーボード","misc"],"title":"Lunakey Miniを組み立てて、BLE+LPME-IO化してみた #DIYキーボード"},{"contents":"みなさんは、スライドの作成には何を使っていますか？ Keynote？Powerpoint？Google Slides？\n私は、Macでスライドを作るときは前職ではテンプレートもあったのでKeynoteでしたが、ちょっとしたものはMarkdownベースのDecksetを利用していました（買い切りタイプの有料ソフト）。\nフリーランスになってもこちらを利用していたのですが、Windows環境に切り替えたので使えなくなってしまいました。 一度はGoogle Slidesで作ったのですが（第39回Es勉強会スライド）、既存の資産を流用したくなりどうしたものかと悩んでい(ツイートし)たら。\nMacの頃はDecksetってアプリでMarkdownで書いてたんだけど、Winに移動したのでこのタイミングでGoogle Slidesにでもしようかなと考えてるところ。Markdownでスライド作るのほかになんかあるか探すほうがいいかなぁ？\n\u0026mdash; Jun Ohtani (@johtani) March 18, 2021 僕はこれ使ってますhttps://t.co/sFaAmKZY6V\n\u0026mdash; miyake | ZEN (@kazuyukimiyake) March 18, 2021 ということで、利用してみようかなとなりました。\nMarpとは？ Markdownでプレゼンテーションのスライドを作ることができるOSS?になります。\nMarp公式サイト といっても、これ自体を使わなくても、VS Code上でプレビューしたりHTML形式で動作するスライドを吐き出すことが可能です。 なので、VS Code用のプラグインを利用しています。\nサンプル この間利用したスライドはこんな感じのMarkdownになってます。 ---でページを区切りつつ、記述していく形です。\n--- marp: true theme: poster --- \u0026lt;!-- _class: big-center --\u0026gt; # 本当にその検索は\u0026lt;br/\u0026gt;自分が想像している検索に\u0026lt;br/\u0026gt;なってますか？ \u0026lt;br/\u0026gt; \u0026lt;br/\u0026gt; \u0026gt; 2021/03 \u0026gt; Jun Ohtani / @johtani --- ![bg right:40% 40%](johtani_face.jpg) # 自己紹介 - フリーランスエンジニア - 検索技術勉強会主催者 - Apache Solr入門(第2版まで)や データ分析基盤構築入門の著者の一人 --- プレビューで見るとこんな感じです。\nプラグイン Marp for VS Code プラグインをインストールするのも簡単ですよね。 マーケットプレイスからインストールすれば完了です。\n機能については上記のページにあるように、プレビューとスライドの出力です。 プレビューでは、Markdownのプレビューみたいな形で、スライドが表示できます。\n先日この機能を利用して作成して、HTMLで出力して利用しました。 PDFとかPPTX出も出せるようなので、今後試してみようかなと。\nDecksetのスライドとの違い ページの区切りなども同じだったので、大筋ではそれほど違いはありませんでした。 ただ、画像周りとスタイルの設定は細かく修正をしました。\n変更した点としては、以下のようなものがあります。\nヘッダ部分の変更 上のサンプルにありますが、marp: trueを含む部分がMarp独自の記述です。 ページごとのちょっとした変更 ページごとにスタイルの変更ができるみたいで（Decksetではできなかったはず？）、タイトルページのスタイルを変えてあります。 画像の指定 画像の読み込み自体は違いはないのですが、画像の配置についての指定方法は カスタムテーマ用CSSの作成 デフォルトではなく、Decksetで用意されているような感じのスタイルに変更してみてます。 カスタムテーマはCSSで設定できるので、CSSファイルを用意して、VS Codeの拡張機能の設定からファイルパスを指定する形です。\nということで、当面はMarpでスライドを作っていくことになるかと思います。 まぁ、ただ、スライドを作るいこと自体が減ってきてはいるのですが。 ほかの配色を試したり、ヘッダフッタとかも試してみるのもいいかもな。\n気が向いたら、CSSをどこかにアップロードするかもです。\n※今回のブログはGateronサイレントクリア軸をルブしてみた、Corne Light v2で最後の数行を書いてみました。 キースイッチだけだとこすれる音が減った気がしてましたが、キーキャップを付けたら少しこすれる音が気になる感じです。\n","date":1617615911,"dir":"post/2021/","id":"f41d4fde94cbd7bbd28808dc080a2019","lang":"ja","lastmod":1617615911,"permalink":"https://blog.johtani.info/blog/2021/04/05/intro-marp/","publishdate":"2021-04-05T18:45:11+09:00","summary":"みなさんは、スライドの作成には何を使っていますか？ Keynote？Powerpoint？Google Slides？ 私は、Macでスライドを作","tags":["勉強会"],"title":"スライド作成の環境をMarpにしてみた"},{"contents":"新型コロナウィルスの影響もあり、オフラインで集まって勉強会も開催できなくなっています。 検索技術勉強会も、もう1年以上開催できていないです。\nスピーカーの人にオンラインでしゃべってもらうのもありだとは思うのですが、 懇親会とセットでその価値があったかもなぁと思うところもあり、オンラインでの開催に乗り気になれないまま時間がたってしまいました。 (配信周りを調べるのがめんどくさいなぁというのもあったかも（反省）)\nそんな中、takuya-aさんと話をしていて、エンジニア同士のゆるいつながりができる場所が欲しいですねぇということに。\nはー、検索技術勉強会、オフラインでできないまま１年以上たってしまったのか。オンライン勉強会とかはスピーカーの人の負担とかもあるし、Discordみたいなオープンな場だけ用意してみるのありかなぁ？ただ、活発に話がされるのかどうかわからんし、ROMな人ばかりだとアレなんだけどなぁ。\n\u0026mdash; Jun Ohtani (@johtani) March 30, 2021 そこからの、このツイートです。 ちらほらと興味のありそうな人が出てきたねという話をしていたら、Slackのワークスペースが出来上がってましたｗ\n検索技術に関する情報交換を目的とした Slack を立ち上げました！こちらの招待リンクからご参加ください。 https://t.co/Tca70vuMff\n\u0026mdash; takuya-a (@takuya_b) March 31, 2021 ありがとう、takuya-aさん！\nということで、検索周りでわいわいできる場になればいいなぁと。 盛り上がってくれば、オンラインでの勉強会とかもありかもしれないですね！ 興味のある方は、上記ツイート内のリンクからご参加下さい！！\n","date":1617200894,"dir":"post/2021/","id":"ce426b7f3190c8a4a47d45ac799e91a4","lang":"ja","lastmod":1617200894,"permalink":"https://blog.johtani.info/blog/2021/03/31/search-tech-jp-slack/","publishdate":"2021-03-31T23:28:14+09:00","summary":"新型コロナウィルスの影響もあり、オフラインで集まって勉強会も開催できなくなっています。 検索技術勉強会も、もう1年以上開催できていないです。 ス","tags":["勉強会"],"title":"検索技術に関する情報交換を目的としたSlackができました！"},{"contents":"Azure Cognitive SearchにはOData式という書式で条件が書ける仕組みがあります。 ODataは検索条件（$filter）やソート条件（$orderby）、取得する項目名の指定（$select）です。\n私は、Luceneの構文に慣れているので、普通のsearchパラメータを利用しようとします。 が、OData式として特殊な書き方がいくつかあるようなのでこちらの利用方法も調べてみました。 その時、N-Gram（よくやるのはN=2）で陥る問題の話もあるのでこちらについても言及します。\nOData式で検索 次のような3件のドキュメント(フィールド名はbodyとします)をN-Gramで登録していたとします。\nミルクティを飲みたいです。 マティーニはカクテルですが、ミルクセーキは？ 風呂上がりのミルクは最高です。 この時、OData式でミルクティという単語で検索してみましょう。\n検索条件は$filterで指定します。 フルテキスト検索用に関数が用意されており、こちらに単語を指定します。\n$filter=search.ismatchscoring(\u0026#39;ミルクティ\u0026#39;) こんな感じ。フィールドの指定がない場合、対象のフィールドは検索可能なフィールドすべてが検索対象になります（公式ガイドのクエリパラメータのqueryTypeに説明あり）。\nでは、実行してみましょう。で返ってくるのは？1だけかな？と思う人が多いかもしれません。 が、結果は3件とも帰ってきます。\n問題点は？ では問題点はどこでしょう？ ismatchscoringのオプションなどを見る前に、転置インデックスを用いた検索エンジンの挙動をおさらいしましょう。 転置インデックスの仕組みを理解することで、なぜそんな挙動になるのか？というのがわかりやすくなります。 おさらいにはElasticsearchをベースに話をしますが、Azure Cognitive Searchでも同じような挙動になります。\n転置インデックスとトークナイザー（アナライザー）の関係（おさらい） 昨年、オンラインで開催されたOSC広島で発表した資料（録画あり）でもざっくりと説明しています。\nView 本当にその検索は自分が想像している検索になってますか？ on Notist.\nざっくりですが、おさらいです。\n検索エンジンでは、入力された文章を、ある規則（アナライザー）で単語に分割し、その単語ごとにどのドキュメントに出現したのか？というリストが作られます。 このリストが転置インデックスです。書籍の後ろにある索引を想像するとどんなものかがわかりやすいです。 単語に対してその単語が出てくるページ番号がわかるという仕組みです（下図は本の索引の一例）。\n書籍の索引は著者や編集の方により厳選された単語のみが採用されています。 が、検索エンジンでは文章を単語に区切る機能が存在します。 この「ある規則」で単語を区切る仕組みが「アナライザー（トークナイザー）」と呼ばれる機能です。 例えば英語用のアナライザーに英語の文章が入力されたとき、文章はこのように単語に区切られたもの（単語列）を出力します（下図）。\n今回はNGramの話なので、NGramのAnalyzerを利用してみるとこんな感じになります。\n実際に出来上がる転置インデックスは次のような形になります。 検索の仕組み（おさらい） 出来上がっている転置インデックスに対して検索をする場合、入力文字列（検索条件）に対して、転置インデックス作成時と同様にAnalyzerが動作します。 処理としては、\nクエリのパース フィールドのAnalyzerで処理 転置インデックスを検索 という形です。 例えばこんな感じ。\n同じAnalyzerの処理が入ることで、転置インデックスに採用されているのと同じ単語が出てくるため、検索がきちんとできるということになります。\n英語と日本語（NGram）の違い 英語と日本語の違いは、スペースの意味になります。 英語の場合は、スペースが単語の区切りになりますが、日本語の場合スペースでは区切られていません。\nですので、検索窓に入力された文字列は、英語の場合、クエリのパースの時点で単語に区切られます。そのあとにAnalyzerになるので、基本的には単語単位でAnalyzerの処理が動きます。そのあと、転置インデックスへの検索となります。なので、多くの場合はAnalyzerの出力は1単語です（類義語などを利用していたりする場合は異なりますが）。\n日本語の場合、スペースでは区切られていないので、クエリのパースの時点で入力された文字列がそのままAnalyzerにわたります。 今回はAnalyzer（NGram）が単語に分割し、それをもとに検索処理が実行されます。\nismatchscoringの問題点は？（やっと帰ってきました） さて、回り道をし、簡単ですが転置インデックスやAnalyzerについて説明しました。 では本題です。\n$filter=search.ismatchscoring(\u0026#39;ミルクティ\u0026#39;) このismatchscoring関数ですが、そのほかにも引数の指定が可能で、省略した場合にデフォルトで採用される値がいくつかあります。 公式のドキュメントにパラメータの意味が掲載されています。\n今回は、第4引数のsearchModeの値が問題点です。デフォルトでは、anyが指定されます。 この、anyは検索語（今回はミルクティ）の任意の検索語句が一致する必要があることになります。 「検索語句」？なんでしょう？これが、ここまで回り道をして説明してきた、Analyzerの出力した単語になります。 「ミルクティ」はNGram（N=2）のAnalyzerを通すと、\n「ミル」「ルク」「クテ」「ティ」\nという4つの単語が出力されます。 これが、「検索語句」です。「任意の」とあるので、上記4つの2文字のどれか？が出現すれば検索条件にヒットしたこととなります。\nですので、以下のように（一部のみ色を変えてます）3つの文章にはそれぞれの文字が含まれているため、先ほどの条件では3件の結果が返ってくることになります。\nミルクティを飲みたいです。 マティーニはカクテルですが、ミルクセーキは？ 風呂上がりのミルクは最高です。 NGramで一部分の単語だけで一致したものがヒットしてしまうと違和感があるので、allに変更します。\n$filter=search.ismatchscoring(\u0026#39;ミルクティ\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;all\u0026#39;) 今度はどうなるでしょう？\nミルクティを飲みたいです。 マティーニはカクテルですが、ミルクセーキは？ 先ほどよりもマシになりました。 3がヒットしなくなっています。3の文章には「ティ」などが出てこないためです。 ただ、感覚的に2番目がヒットするのは少し違和感がありますよね？ 確かに4つの単語がすべて出てきていますが、「ミルクティ」とは少し遠いです。\nさらに「ミルクティ」にヒットさせるにはフレーズ検索にする必要があります。 Elastic社のブログの日本語の検索に関する記事でも出てきますが、フレーズで検索することで「ミルクティ」だけにヒットさせることができます。\n「フレーズ検索＝語順を保証する検索」となります。 ですので、\n「ミル」「ルク」「クテ」「ティ」\nこの順序で出てきた場合のみ、検索にヒットしたことになります。 OData式でフレーズ検索する場合は、単語をダブルクォート\u0026quot;でくくる必要があります（公式ドキュメントの例に記載あり）。\n$filter=search.ismatchscoring(\u0026#39;\u0026#34;ミルクティ\u0026#34;\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;all\u0026#39;) これで結果は以下の1件だけとなります。\nミルクティを飲みたいです。 これでNGramで部分一致のような挙動で日本語の検索ができるようになりました。\nちなみに、フレーズにした場合は第4引数はanyに変更しても1件だけの検索結果となります。 フレーズ検索には「すべての語が含まれる」、「すべての語が順番に現れる」という2つの条件が含まれるためです。\n$filter=search.ismatchscoring(\u0026#39;\u0026#34;ミルクティ\u0026#34;\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;any\u0026#39;) この例の引数をミルクティを\u0026quot;ミルク\u0026quot; \u0026quot;最高\u0026quot;のような検索条件に変えた場合、「\u0026ldquo;ミルク\u0026rdquo;」「\u0026ldquo;最高\u0026rdquo;」の2つの条件をanyで扱うため、 「\u0026ldquo;ミルク\u0026rdquo;」「\u0026ldquo;最高\u0026rdquo;」のどちらかが出てくれば良い結果となり、3件の結果が返ってきます。 第4引数をallに変更すると、「\u0026ldquo;ミルク\u0026rdquo;」「\u0026ldquo;最高\u0026rdquo;」の両方が出てこなければならないため、3件目のデータのみが返ってきます。\n$filter=search.ismatchscoring(\u0026#39;\u0026#34;ミルクティ\u0026#34; \u0026#34;最高\u0026#34;\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;all\u0026#39;) これは、\n$filter=search.ismatchscoring(\u0026#39;\u0026#34;ミルクティ\u0026#34;\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;any\u0026#39;) and search.ismatchscoring(\u0026#39;\u0026#34;最高\u0026#34;\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;any\u0026#39;) と同じ意味となります。 少し長くはなりますが、後者の書き方をプログラムで書くと思います、私の場合は。 検索窓に入力された単語に必ず\u0026quot;を追加する処理を書くために、画面入力の文字列を一旦パースをすることになるからです。\nまとめ 簡単？にですが、OData式でのフルテキスト検索と、NGramでのフレーズ検索について説明しました。 英語の場合、もともとスペースで区切られているので、フレーズといわれてピンときますが、日本語の場合はAnalyzerの挙動をわかっていないと「？」となるかと思います。 なぜフレーズ検索が必要なのか？というのが少しでもわかっていただければと。 ちなみに、NGramのTokenizerには別の落とし穴もありますが、その話はまた後日にでも。\n参考として日本語関連の検索に関する記事のリンクを残しておきます。\n参考 Elasticsearch日本語でフレーズ検索が必要なわけ NGramも含め、Elasticsearchでの日本語の検索の設定やクエリについては、Elastic社のブログで日本語で書かれた記事が詳しいのでこちらをご覧いただくのがいいです。 ","date":1614756213,"dir":"post/2021/","id":"eced95e5f301a8340e83d81d3c0d5c0d","lang":"ja","lastmod":1614756213,"permalink":"https://blog.johtani.info/blog/2021/03/03/phrase-query-in-japanese/","publishdate":"2021-03-03T16:23:33+09:00","summary":"Azure Cognitive SearchにはOData式という書式で条件が書ける仕組みがあります。 ODataは検索条件（$filter）やソート条件（$orderb","tags":["azure search","elasticsearch"],"title":"OData式と日本語の検索(NGram)とフレーズ検索"},{"contents":"自宅の環境がいろいろと変わったのですが、書いていなかったので更新版です。 前回のブログ(2020/09)、前々回のブログ(2020/03)はそれぞれリンクをたどってください。\n現状のデスクトップはこんな感じ\nPC 別のブログにまとめましたが、Windowsメインに切り替えました。 ハードの話以外に、Windows OSに切り替えたときにいくつか入れたものもあります。 それは、移行のブログに少しだけ書いてあります。\nひさびさにWindowsに戻ってきていますが、だいぶ慣れました。 まぁ、それほど大したことをやってないというのもあるかもですが。。。\nメインPC以外にこれまでのmacをブラウジング用にサブディスプレイにつなぎ、マウスをLogicool Flowで行き来できるようにし、 キーボードはKVMスイッチで切り替えてやりくりしていました（最新環境はキーボードのところを参照してください）。\nAmazon | サンワダイレクト USB切替器 キーボード・マウス用 KVMスイッチ キーボード いくつかDIYしましたが、今はメインでSofle Keyboard v2を利用しています（Kochi Keyboardさんで購入できます）\nSofle keyboard v2を有線で使っていましたが、最近Bluetooth対応して無線化しました（その時のブログはこちら）。 ですので、PCとの接続の切り替えはキーボード上で特定のキーの組み合わせを押すことで、切り替えられるようになっています。 KVMとは異なり、Bluetoothの接続が切り替わるのにタイムラグがある＋どこにつながっているのか？というのがわからないので、想定していないところでキーが入力されていることがあります。 これは、何とかしたいかもなぁと考えてはいるところ。\nマイク＆オーディオインターフェース 基本的に自宅でリモート作業をしています（ありがとうございます）。 なので、ミーティングもオンラインです。 となるとやはり、音がいいほうがお客さんにも喜ばれるかなぁと。 2020年3月時点ではSAMSONのGoMicを利用していました。 これもいい音なのですが、大きいマイクでもいいかなと。 あとは、ほかの使い道もあるかも？ということで、オーディオテクニカのマイク（＋ポップガード）とフォーカスライトのオーディオインターフェースに変えてみました。 自分は実感ないですが、きっと役に立っていると思いますｗ\nAmazon | audio-technica サイドアドレス コンデンサーマイクロホン AT2050 | コンデンサ | 楽器 Amazon | AUDIO-TECHNICA AT-PF2 ポップフィルター | マイクアクセサリ | 楽器 Amazon | Focusrite フォーカスライト オーディオインターフェイス 2イン/2アウト 24bit/192kHz Scarlett Solo (3rd Gen) ステッカー付きセット 【国内正規品】 | 楽器・音響機器 | 楽器 ディスプレイ 以前は、MacBookProの16インチで、メインディスプレイの下に2枚目のディスプレイも兼ねて開いて利用していました（前回のブログ参照）。 自作PCに切り替えたので、ディスプレイがなくなってしまうので、同じような大きさのモバイルモニターを利用しています。 今のところは据え置きになっていますが、持ち運べるので、ほかの部屋や外出時にも使えるんではないかなと。 ディスプレイの足などはないので、邪魔にもならず便利ですね。\nAmazon | モバイルモニター モバイルディスプレイ 4K 15.6インチ cocoparスイッチ用モニター 非光沢IPSパネル 薄い 軽量HDRモード/FreeSync対応/ブルーライト機能 3840x2160 UHD/USB Type-C/標準HDMI/mini DP/カバー付3年保証付 | cocopar | ディスプレイ 通販 音楽再生環境 サブディスプレイにサンダーボルトディスプレイを使用していたので、Mac Miniを接続していましたがサンダーボルトディスプレイには退役してもらいました。 それに伴って、Mac Miniも別の場所に移動しました。音楽再生環境にラズパイ４を復活させました。 以前購入したセットについていたケースではファンの音が気になっていたので、ヒートシンク型に変えました。 結構重いですが、冷えてそうです。\nAmazon | Geekworm Raspberry Pi(ラズベリーパイ) 4 B 用アーマー金属ケース パッシブ冷却/シェル熱放散 ラズベリーパイ4 コンピュ ータモデルB適用 (アーマーケース（ファン無し）) | Geekworm | 冷却パーツ・ファン 通販 Webカメラ カメラ自体に変更はないですが、付属品をいくつか。 Webカメラではないカメラもつけてみたいなと思い、モニターアームにカメラを付けられるものを付けてみました。 ただ、おっさんの顔をきれいに映してもなぁという結論に至ったので、Webカメラが乗っかっています。。。 あとは、デスクトップPCになり、カメラのケーブルだけではPCまで届かなくなってしまったのでUSB Type-Cの延長コードを買ってみました。実はこれ2本目ですが。。。 スタンディングデスクの昇降でケーブルに負荷がかかってしまったことがなんどかあり、1本目の延長コードは接触が悪くなってしまいました。。。時々外したりしていて、ケーブルの配置がおかしいときがあるので、気を付けるようにしています。\nAmazon | 長尾製作所 モニターアーム用 VESA カメラ＆マイクマウント NB-MV001MH | 長尾製作所 | モニタアーム\u0026amp;スタンド 通販 Amazon | iVANKY USB Type C 延長ケーブル USB 3.1 Gen 2(4K@60Hz/1.0m/オス－メス)10Gbps高速データ転送 3A急速充電 usb-c 変換 Huawei MateBook13, iPad Pro11, Nintendo Switch, MacBook等対応 | IVANKY | USBケーブル 通販 照明 裸の蛍光管だったのですが、リモコンで点灯したり、照度を変えられるようにしたかったので、 パナソニックの照明に変えました。\nAmazon | パナソニック LEDシーリングライト 調光・調色タイプ リモコン付 6畳 3, 699lm HH-CD0620AZ 【Amazon.co.jp限定】 | パナソニック(Panasonic) | ホーム＆キッチン 変えたのはよかったのですが、部屋が長細い＋Webカメラの位置（自分から見て左にカメラを置いて、部屋の奥への画角？になっている）のせいで、右半分の顔が暗くなる場合がありました。 幸い、右にはスチールラックが組んであるので、そこにつけられる照明を購入して女優ライトみたいな感じで使っています（頻繁ではないですが）\nAmazon｜ルミナス メタルラック用 LEDライト 磁石で簡単設置 連結可能 幅60cm 昼白色 LED60R-N｜メタルラックパーツ オンライン通販 フットレスト 昨年3月くらいに配置して、座っているときに足を置くのに便利に使っていました。 が、1台だと幅が足りないので最近2つ目を購入して並べて使っています。 片足ずつ載せられるのは便利ですね（基本ガニ股なので。。。）。\nAmazon | サンワダイレクト フットレスト スチール製 角度10° 幅40×奥行30cm 足置き台 100-FR011 | フットレスト | 文房具・オフィス用品 ということで、最近はこんな環境で仕事をしています。 当分これで更新しないんじゃないかなぁ。 （サブディスプレイが左に寄っているので、局面ディスプレイが気になっているところですが。。。）\n","date":1614246182,"dir":"post/2021/","id":"fcb0105fa6b5777a133f247784b9d930","lang":"ja","lastmod":1614246182,"permalink":"https://blog.johtani.info/blog/2021/02/25/update-working-facility/","publishdate":"2021-02-25T18:43:02+09:00","summary":"自宅の環境がいろいろと変わったのですが、書いていなかったので更新版です。 前回のブログ(2020/09)、前々回のブログ(2020/03)はそ","tags":["misc"],"title":"自宅の作業環境(2021/02)"},{"contents":"Azure Cognitive SearchにSuggestやAutocompleteの機能があるのを見つけたので、どんな挙動なのかを調べてログとして残しておきます。\n公式ドキュメント 日本語で公式ドキュメントが公開されています。使い方や流れについてはこちらをまずは見れば使えると思います。\n本ブログでは、ざっくりとした機能の紹介と内部がどんな挙動をしていそうか？、日本語だとどういう感じになるのか？という点を紹介しようと思います。\nどんな機能？ 検索窓でよく、キーワードを入力しているときに検索キーワードの候補が表示されることがあります。 このキーワードの候補を表示するための機能が今回紹介するSuggesterと呼ばれる機能です（日本語の公式ドキュメントでは「先行入力エクスペリエンス」）。 Suggesterには、以下の2つの機能が用意されています。\nAutocomplete：キー入力しているときに、入力されている文字列で始まる単語で、検索できるもの（転置インデックスに登録されている単語）をリストで返す機能 Suggestion：入力した文字列で始まるキーワードを含む、元のデータを返す機能 利用方法 Suggesterの機能を利用するにはインデックスに設定を追加する必要があります（新規、既存どちらでも可）。 ただ、既存のインデックスに設定を追加した場合、内部にすでに存在するドキュメント（データ）については、このSuggesterのデータは作られません。 ですので、既存データを再度登録しなおすといった作業が必要となるので注意が必要です。\n本ブログでは、いくつかAzure Cognitive Searchのサンプルのリクエストが出てきます。Visual Studio CodeのREST Client Extensionの書式となります。拡張機能の簡単な紹介は昨年のブログをご覧ください。\n設定編 Suggesterの設定では、主に以下の2つを設定する必要があります。\nname: suggesterの名称。クエリ時に指定します。 sourceFields: 入力データのもととなるフィールド名。 String型のみ指定可能。また、Azureで用意されたアナライザーだけが利用可能です。自分で用意するカスタムアナライザーは利用できないので注意が必要です（制限についてはこちら）。 今回使用するサンプルのインデックス設定は次の通りです。\nインデックス作成のリクエスト（@host、@api-keyはご自身のものに置き換えてください。）\n## 設定 @host = 名前.search.windows.netと記載 @api-key = APIキーを入力 ### Create index with suggester POST https://{{host}}/indexes/?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;name\u0026#34;:\u0026#34;suggester-test\u0026#34;, \u0026#34;fields\u0026#34;:[ { \u0026#34;name\u0026#34;:\u0026#34;id\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;Edm.String\u0026#34;, \u0026#34;key\u0026#34;:true, \u0026#34;searchable\u0026#34;:false }, { \u0026#34;name\u0026#34;:\u0026#34;name\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;Edm.String\u0026#34;, \u0026#34;searchable\u0026#34;:true, \u0026#34;analyzer\u0026#34;:\u0026#34;ngram_analyzer\u0026#34; }, { \u0026#34;name\u0026#34;:\u0026#34;category\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;Edm.String\u0026#34;, \u0026#34;filterable\u0026#34;:true, \u0026#34;facetable\u0026#34;: true } ], \u0026#34;suggesters\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;name_suggester\u0026#34;, \u0026#34;searchMode\u0026#34;: \u0026#34;analyzingInfixMatching\u0026#34;, \u0026#34;sourceFields\u0026#34;: [ \u0026#34;name\u0026#34; ] } ] } 公式ドキュメントのサンプルでは日本語がないので、日本語のデータも入力しています。\nデータ登録リクエスト\n### Index data POST https://{{host}}/indexes/suggester-test/docs/index?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;value\u0026#34;: [ { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Microsoft Office\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;microsoft\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Microsoft Azure\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;microsoft\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;3\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;GitHub Enterprise\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;github\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;4\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;GitHub dot com\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;github\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;5\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Bluetooth Mic\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;hardware\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;6\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;東京スカイツリー\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;japanese\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;7\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;東京タワー\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;japanese\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;8\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;東京特許許可局\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;japanese\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;9\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;グランメゾン東京\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;japanese\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;10\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;東京都庁\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;japanese\u0026#34; } ] } 以上が事前準備です。データ登録時に内部でSuggester用のデータを内部で生成しているようです（公式ドキュメント）。\nクエリ編 最初に説明しましたが、Suggesterの中ではAutocompleteとSuggestionという2種類の機能が用意されています。それぞれについて例をもとに説明していきます。\nAutocomplete API 検索窓に入力された文字を元に、前方一致でどのような単語で検索できるか？という候補を表示するための機能です（2単語も対応していますが今回は省略。APIの仕様はこちら）。\nたとえば、micという文字が入力されているところでAutocomplete APIを呼び出す時は、次のようなリクエストです。searchというパラメータに入力値を与えます。suggesterNameはインデックス作成時につけた名前になります。\nPOST https://{{host}}/indexes/suggester-test/docs/autocomplete?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;mic\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } レスポンスとして、次のようなJSONが返ってきます。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;microsoft\u0026#34;, \u0026#34;queryPlusText\u0026#34;: \u0026#34;microsoft\u0026#34; }, { \u0026#34;text\u0026#34;: \u0026#34;mic\u0026#34;, \u0026#34;queryPlusText\u0026#34;: \u0026#34;mic\u0026#34; } ] } サンプルデータとして登録したデータにcategoryというフィールドを入れていました。 Autocompleteは条件を絞り込んで結果を返すこともできます。 filterにODataの書式で条件を書けます。 categoryフィールドにmicrosoftが設定されているデータだけを取得するということができます。\n### Autocomplete with filter POST https://{{host}}/indexes/suggester-test/docs/autocomplete?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;mic\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34;, \u0026#34;filter\u0026#34;: \u0026#34;category eq \u0026#39;microsoft\u0026#39;\u0026#34; } レスポンスはこちら。先ほどとは違い、micというデータは返ってきていません。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;microsoft\u0026#34;, \u0026#34;queryPlusText\u0026#34;: \u0026#34;microsoft\u0026#34; } ] } 英語の場合、「単語」の単位は字面の通りです。スペースで単語が区切られているのでわかりやすいです。 日本語の場合は普通の人には少し想像しにくいです。 東京という文字を入力してみます。\n### Autocomplete in Japanese POST https://{{host}}/indexes/suggester-test/docs/autocomplete?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;東京\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } すると返ってくるのは以下の通り「東京」だけになります。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;東京\u0026#34;, \u0026#34;queryPlusText\u0026#34;: \u0026#34;東京\u0026#34; } ] } 入っているデータは「東京スカイツリー」、「東京タワー」などです。 普通に考えると、これらがそのまま返ってくると思うかもしれませんが、違います。\nこれは、Suggesterの元となるフィールドのAnalyzerの挙動によります。 今回のインデックスのnameフィールドのanalyzerにはja.luceneです。これは、日本語用のアナライザー（Kuromoji）になります。いわゆる形態素解析器で日本語の文字列を「単語」に分割します。 英語についてはスペース区切りで分割しますが、日本語についてはKuromojiが内部の辞書とアルゴリズムに基づいて単語に分割してくれます。 Azure Cognitive Searchでは、Analyzerの挙動を確認するためのAPIも用意してあるので実行しみると、\n### Autocomplete in Japanese POST https://{{host}}/indexes/suggester-test/analyze?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;text\u0026#34;: \u0026#34;東京スカイツリー\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;ja.lucene\u0026#34; } このような結果が返ってきます。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;東京\u0026#34;, \u0026#34;startOffset\u0026#34;: 0, \u0026#34;endOffset\u0026#34;: 2, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;スカイ\u0026#34;, \u0026#34;startOffset\u0026#34;: 2, \u0026#34;endOffset\u0026#34;: 5, \u0026#34;position\u0026#34;: 1 }, { \u0026#34;token\u0026#34;: \u0026#34;ツリー\u0026#34;, \u0026#34;startOffset\u0026#34;: 5, \u0026#34;endOffset\u0026#34;: 8, \u0026#34;position\u0026#34;: 2 } ] } ja.luceneのAnalyzerによって、3つの単語に分割されているのがわかります。 Autocomplete APIの実行結果も、このAnalyzerによって分割された単語をもとに、候補となる単語を前方一致で検索して結果を返しているのです。 ですので、「東」と入れても「東京」が返ってくるのがわかります。 一方で、「東京ス」と入力した場合は次のような結果となります。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;スカイ\u0026#34;, \u0026#34;queryPlusText\u0026#34;: \u0026#34;東京スカイ\u0026#34; } ] } これは、autocompleteModeと呼ばれるパラメータの挙動となります。 デフォルトでは、oneTermという設定で、最後の単語（例の「東京ス」の場合は「東京」「ス」と区切られるので「ス」という文字を単語とみなす）にマッチする単語（例では「スカイ」）が返ってきます。 queryPlusTextについては、入力された文字にtextで返ってきた単語をくっつけたものが取得できます。\n英語であれば、スペースで区切られており、単語が切れているのが簡単にイメージできますが、日本語の場合は少し違和感が出るかと。\nこのように、入力された文字が含まれる「単語」を基本的に返す動作をするのがAutocomplete APIです。\nSuggest API では、もうひとつのSuggest APIはどういったものでしょうか？ autocomplete APIに似ていますが、返ってくるデータが登録されたデータそのものになります。\nたとえば、micという文字列を入力とした場合、\nPOST https://{{host}}/indexes/suggester-test/docs/suggest?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;mic\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } 次のような結果が返ってきます。Autocompleteの時は単語でしたが、こちらは入力データがそのまま返ってきています。 入力データの中にmicで始まる単語が含まれたものが候補となっています。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.text\u0026#34;: \u0026#34;Bluetooth Mic\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;5\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;Microsoft Office\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;Microsoft Azure\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;2\u0026#34; } ] } 日本語の場合、Autocompleteとは異なり、その単語を含むものがサジェストされるので、「東京」をsearchに指定すると「東京」を含むデータが出てきます。\n### Suggest in Japanese POST https://{{host}}/indexes/suggester-test/docs/suggest?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;東京\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } レスポンスはこちら。単語を含む元の文字列が返ってきます。ここまでは違和感はありません。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.text\u0026#34;: \u0026#34;東京タワー\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;7\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;グランメゾン東京\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;9\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;東京都庁\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;10\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;東京スカイツリー\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;6\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;東京特許許可局\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;8\u0026#34; } ] } では、「東京」「特許」という2つの単語をスペースで区切ったものが入力されたとするとどうでしょう？\n### Suggest in Japanese POST https://{{host}}/indexes/suggester-test/docs/suggest?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;東京 特許\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } スペースがありますが、内部処理では形態素解析器が分割した後でこの単語の順番で出てくるものを探しているので、出てくることになります。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.text\u0026#34;: \u0026#34;東京特許許可局\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;8\u0026#34; } ] } なお、このSuggestのAPIは、単語の語順を気を付ける必要があります。 「特許」「東京」と順序を入れ替えたスペース区切りの場合は、\n### Suggest in Japanese POST https://{{host}}/indexes/suggester-test/docs/suggest?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;特許 東京\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } 結果は返ってこないです。おそらく内部では、フレーズクエリで、最後の単語だけを前方一致で検索するような仕組みが動いているのだと思われます。 スペースで区切られてはいるが、順序があるので少し違和感を感じるかもしれません。英語だとフレーズの部分のイメージは沸きやすいのですが。\n短い文章のデータ（例：本のタイトルやランドマーク名など）では、このSuggestAPIを利用するとデータそのものが返却されるので、便利かもしれません。\nまとめ ということで、Azure Cognitive SearchのSuggesterの簡単な紹介でした。APIのページにはそのほかのパラメータについても説明があるので、使ってみようと思う方は目を通していただくのがよいかと。\n今回のブログは裏の仕組みがどんな感じなのか？を想像しながらAPIについて調べた形になります。日本語の場合に、少し違和感を覚える人もいそうだろうなということでブログを書いてみました。 今回は書いていませんが日本語でAutocompleteをやりたい場合は、読み仮名でも漢字が表示されるほうがよいという場合もあると思います。 その場合は、用意されている機能では難しいので、独自実装するといった方法になりそうです。 英語や、読みを利用しない場合は、挙動を理解していれば役に立つ場面もありそうです。\n","date":1612515120,"dir":"post/2021/","id":"931b2ebd9bfaeb5dcf1973e724a1f8d0","lang":"ja","lastmod":1612515120,"permalink":"https://blog.johtani.info/blog/2021/02/05/autocomplete-and-suggest-on-azure-search/","publishdate":"2021-02-05T17:52:00+09:00","summary":"Azure Cognitive SearchにSuggestやAutocompleteの機能があるのを見つけたので、どんな挙動なのかを調べてログとして残しておきます。 公","tags":["azure search"],"title":"Azure Cognitive Searchでオートコンプリートやサジェストをしてみる"},{"contents":"オライリー・ジャパンから出ている「コンピュータシステムの理論と実装」を読み始めたのでメモを取ることに。\n原著はオライリーじゃないのかというのが、まず最初の気づきでした。\nNANDからテトリス コンピュータのハードウェアからOS、さらにその上で動くアプリケーションまでを動作させるというのを少しずつやっていくという書籍みたいです。 イントロと1章を読みましたが、1章では論理回路の話でした。\n実際に物理的に作るわけではなく、シミュレーターなどのソフトウェアが用意されており、 そのソフトウェア上で動くものを作っていくことになります。 ソフトウェアのために専用のサイトが用意されて、ダウンロードもできるようになっているので、実際に手を動かしながら理解を進める感じになるのかと。\n目次を見ていただくとわかりますが、すごく幅が広いです。 1年で読み終われるかなぁ？まぁ、のんびりやっていこうかなと。\n用意されているソフトウェアなどで便利だなと思ったのは、どの章からでも興味のある部分から始められるようになっているようです（まだ始めてなくて。。。） 内部ではすべてのパーツがそろえてあるけど、章ごとのプロジェクトでは、個別に自分で実装したものがあればそちらが動くという挙動のようです。\nということで、ちょっとずつやっていこうかなと。 ほんとにテトリス動くのかなぁ？\n","date":1612424444,"dir":"post/2021/","id":"aa61b4543e8a7c67fccabee27a6e99cd","lang":"ja","lastmod":1612424444,"permalink":"https://blog.johtani.info/blog/2021/02/04/reading-elements-of-computing-systems/","publishdate":"2021-02-04T16:40:44+09:00","summary":"オライリー・ジャパンから出ている「コンピュータシステムの理論と実装」を読み始めたのでメモを取ることに。 原著はオライリーじゃないのかというのが","tags":["輪読","Nand2Tetris"],"title":"「コンピュータシステムの理論と実装」を読み始めた #Nand2Tetris"},{"contents":"Corne使ってましたが、数字キーがあるとどうなのかな？というのがやはり気になって。 そこに、Kochi KeyboardさんからSofle Keyboard v2というのが発売されたので組み立ててみました（去年末に）。また、先日Corne Light v2のBLE化に成功したので、Sofle keyboard v2のBLE Pro Micro + LPME-IO化にもチャレンジしてみました。\nSofle keyboard v2 ビルドログ 自分で書くよりもすごくよくできたビルドログがKochi Keyboardさんで公開されているので、そちらを参考にしてください。\nSofle Keyboard v2ビルドガイド すごく詳しく書いてあります。なので、こちらを見ていただければ問題ないかなと。 ただ、自分ではいくつか失敗したので自戒を込めてログを残しておきます。\nOLED用のジャンパをはんだ付けし忘れ 単にビルドログを流し読みしたツケが。。。 Sofleは同じ基盤を左右で利用します。なので、右手と左手で、同じ基盤の表と裏を利用します。 OLED用のジャンパする部分は両面に用意されていますが、はんだでジャンプするのはPro Microが実装される面となります。\n両面にジャンプ用のランドがあるとは気づかないで、左手の裏面をジャンプしてすべて実装し終わってから、OLEDが表示されないことに気づいてしまいました（ビルドログ用にと思って撮った写真に証拠が残ってますねｗ）。。。\nということで、またはんダッシュ太郎くんのお世話になりました（Pro Microを外してジャンプしました）。本当に有能ですよ彼は。。。\nAmazon | サンハヤト はんだシュッ太郎NEO 45Wタイプ HSK-300 | ハンダゴテパーツ ソケットのはんだ付け甘すぎ あとは、慣れてきたなぁと思っていたところに天罰が。 キースイッチのソケットを付けるの慣れてきたなーと思って、サクサクとつけていたのですが、 いざキースイッチをはめるときにボロボロとはがれていきましたｗ 半分くらいは外れたんじゃないかな？ちゃんとはんだ付けした後にピンセットなどで軽くいじってみるべきですね。。。\n滑り止め 利用しているキーキャップがOEMプロファイルということもあり、数字キー側を少し高くしたほうが入力しやすいです。そのために、少し大きめのソフトクッションを購入しました。\nAmazon | WAKI ソフトクッションCN-020 クリアータイプ: 産業・研究開発用品 上の左右の角に貼り付けると、がたつきがあったので少しずらして貼り付けて安定させています。 OLEDのプレートの部分を押すと手前が浮き上がってしまいますが、そこにはキーはないので問題ないかと。\nということで、毎回気づきがあって面白いですね。。。\nSofle keyboardのBLE化 Corne LightのBLE化がうまくいったので、もうひとセットのぎけす屋さんから購入しました。 BLE Micro ProやLPME-IO、電池基盤などについては前回のCorneのBLE化の記事を参照してください。\nハードウェア編 Sofle keyboard v2は残念ながらせきごんさんの公式ページの対応キーボード一覧には掲載されていません。 が、Sofle KeyboardのGitHubのページには次のような記載があります。\nSofle is 6×4+5 keys column-staggered split keyboard with encoder support. Based on Lily58, Corne and Helix keyboards.\n基盤の写真のPro Micro周りもCorneに似ています。 ということで、おそらくBLE + LPME-IO化が行けるのでは？と予測して作業に取り掛かりました。\nPCBの確認 Sofle Keyboardの基盤の設計図はGitHub上に公開されています。 この設計図を見る方法をまずは探しました。\n自作キーボードについて探すにはまずはサリチル酸さんのブログ「自作キーボード温泉街の歩き方」です。 回路図なので、設計ノウハウあたりのカテゴリーにあるだろうと探したところ見つかりました。\n（設計者向け）オートルーターを使って睡眠時間を確保しよう 配線のテクニックというブログですが、回路図を書くためのツールKiCadについて記載があります。 このブログにある以下の記事をもとに、KiCadのインストールや使い方をちょっとだけ勉強しました。\nfoostanさんのMeishi Keyboardの開発者向けガイド(JP) KiCadことはじめ KiCadの中の回路図エディタ「Eeschema」でSofle keyboardのPCBのフォルダを開くと回路図が開きます。 実際の基盤になる前に、Pro Microのどの足と何がつながっているのか？などが見て取れます。 前回のCorneのBLE化でLPME-IO対応したときに、学習しましたが、 TRRSの足とPro MicroのSDAとSCLをつなぐことで、LPME-IOを使うことができるようになるというのがわかっています。 それをもとに回路図を見たところ、以下のような記述がありました。\nどうも、JP9とJP10というはんだでジャンプする場所を用意してくれていそうです。 先を見越した設計本当にありがたいですね。\nJP9とJP10のはんだ付け 今ついているPro Microを外し（またはんダッシュ太郎が活躍）、基板を確認したところ対象の個所がありました。下の写真は左手の裏側です。\nこれらをはんだでジャンプします。\n右手は表側にあるので、Pro Microを外した後にジャンプしました。 左手は裏側です。 Corne Lightでは、Pro Microの足から導線を使ってTRRSの足につなぎましたが、今回はすっきり実装できました。 ジャンプした後はBLE Micro Proをはんだ付けします（はんだ付けせずに動作確認しようとしましたが、うまく通電しなくてちゃんと動かなかったです）。\nLPME-IOのジャンパ LPME-IOのGitHubページにあるように、利用するキーボードによって、いくつかはんだでジャンプする必要があります。 これは、BLE Micro Pro用のConfigファイルを見て、対象を決める必要があります。 が、Sofleは事前に用意されたものがありません。\nConfigファイルの生成 用意されていないConfigファイルが、QMKの設定ファイルから生成することができるようななっています（本当に感謝しかないですね）。 手順はBLE Micro Proのドキュメントにありました。\n新しいキーボード用の設定を作成する - QMK用の設定から変換する この変換スクリプトで３種類のconfig（右手用、左手用、LPME-IO用）が生成されます。 私の場合はLPMEを利用するので、lpmeという名前の入ったconfigを利用します。 中を見るとcol以下の記載が以下の通りだったので、8からDをジャンプします。\n\u0026#34;col_pins\u0026#34;:[18, 17, 16, 15, 14, 13, 18, 17, 16, 15, 14, 13], ここまででハードウェア側が終了です。\nファームウェア・設定編 ハードウェアの実装が終わったので、ファームウェアおよびアプリの設定です。\nファームウェアのセットアップ キーボードをUSBで接続し、BLE Micro Pro Web Configuratorのページにアクセスすると、 セットアップ初期画面が出てきます。\n公式ページの「キーボードを選ぶ」を参考にファームウェア、アプリのアップデートを行います。 「設定ファイルの書き込み」のタイミングでupload your ownを選択すると、ファイル選択画面が出てくるので、変換スクリプトで生成したJSONファイルを選択します。 このとき、Mas Storage Classとしてキーボードが認識されている状態だとうまく書き込めなかったので、キーボードのドライブを「取り出し」してからファイルをアップロードしました。\nキーマップの設定 BLE Micro Proのアプリが設定をきちんと認識すれば、あとはWeb Configuratorでキーマップの設定が可能になります。 これまた、残念なことに、BLE化する前のキーマップをJSONファイルで保存してなかったので（泣きそうｗ）、QMKのkeymap.cのファイルをもとに、ブラウザ上でがんばって設定しましたｗ また、新しい設定ではBLE関連のキーをマッピングとして追加しています。\nBluetooth接続 あとは、接続確認です。 MacとWin２台と接続するのですが、Win→Mac→Winの順番でBluetoothの接続をやっていたら、なぜか３つ目のWindowsで接続候補に出てくるけど、接続しようとするとタイムアウトをするという現象に遭遇しました。 MacのBluetoothの設定を一旦削除してから、Win→Win→Macの順番でペアリングしたところ問題なく接続できました。ただ、これが本当の対処なのかどうかは不明です。３番目だと接続できなかったWindowsマシンは再起動もしてみたのですがダメでした。この辺よくわかってないなぁ。\nまとめ ということで、Corne Lightに引き続き、Sofle Keyboard v2もBLE＋LPME化に成功しました。 導線なども使わずにLPME対応ができたので見た目もすっきりしています。 これで、KVMスイッチだと２台までしか切り替えできなかったのが、３台をひとつのキーボードで操ることができるようになりました。 だいぶ楽になりそうな予感がしています。\nまだ、完ぺきではないので、次のような対応をやっていく予定です。\nロータリーエンコーダー対応：BLE以前はQMKのkeymap.cの中でロータリーエンコーダーの動作を記述していたので、BLE Micro Proでどうやるのかを調べたい。encorder.jsonというファイルがあったのでその辺ではないかな？ OLED対応：Corne Lightの時と同様に、OLEDが点かなくなったのでこの辺りを調べたい。 ということで、とりあえずキー入力するのには困らない程度にはできたので、より便利にする方法を時間を見つけて模索する感じになりそうです。 あと、KiCadも面白そうなのでこっちもちょっと触ってみたくなってきたかも？\n","date":1612106122,"dir":"post/2021/","id":"d95522c691013bfe66dd46ded85a98ed","lang":"ja","lastmod":1612106122,"permalink":"https://blog.johtani.info/blog/2021/02/01/apply-ble-to-sofle/","publishdate":"2021-02-01T00:15:22+09:00","summary":"Corne使ってましたが、数字キーがあるとどうなのかな？というのがやはり気になって。 そこに、Kochi KeyboardさんからSofle Keyboard v","tags":["DIYキーボード","misc"],"title":"Sofle v2を組み立てて、BLE+LPME-IO化してみた #DIYキーボード"},{"contents":"メインマシンとMacは下記のサンワサプライのUSB接続のKVMスイッチを使っていますが、もう一台ノートPCがありここに接続しているCorne（初めてのDIYキーボード）が長いUSBケーブルでつながっています。\nAmazon | サンワダイレクト USB切替器 キーボード・マウス用 KVMスイッチ 時々必要になって、デスクにキーボードだけ引っ張ってきて利用するのですが、ケーブルの取り回しがまぁ邪魔で。。。 BLE対応（BLE Micro Pro）をしてみようかなということに。\nBLE + LPME-IO対応 分割キーボードをBLE対応(それぞれにBLE Micro Proを実装)すると、キーボード間のつながりがいまいちになることもあるというのをちらほら見ていたので、BLE Micro Pro + LPME-IOという構成で、 Corneのキーボード同士はTRRSケーブルで接続し、PCとCorne間をBluetoothで接続する構成にしてみました。\nBLE Micro Proについては、公式ドキュメントにいろいろと記載があります。\n材料 ということで、材料は以下の通り。セット販売は売り切れていたので、個別に購入しました。 コンスルーと電池以外は１つずつです。\nBLE Micro Pro(のぎけす屋) x 1 LPME-IO(のぎけす屋) x 1 BLE Micro Pro用電池基盤(遊舎工房) x 1 コンスルー(Kochi Keyboard) x 4 CR1632ボタン電池（近所のスーパー） x 2 実装 まずは、それぞれ組み立てです。\n電池基盤 以下の記事を参考にはんだ付けしました。\nQiita: 自作キーボードビルドログ：その２「ErgoDash」無線化対応 ハードウェア編 - 電池基盤の組み立て・半田付け yfuku docs - Claw44 / 無線接続について 注意点は以下の通りです。\n基盤が軽いので固定が必要（マスキングテープでマットに貼り付けたらましになった） 電池ホルダーが変形しやすい（設置して、足を折るために上から押さえつけたら、本体が曲がってしまった。。。） 部品が細かいので大変（老眼だから？） BLE Micro Proとの接続は参考にしたyfuku docsにある方法（余っていたピンヘッダを１本ずつ使ってはんだ付け）を採用しました。 （パッと見大丈夫そうだったので電池基盤の裏に絶縁テープは貼ってないです貼ってないです）\nBLE Micro Pro（もげ対策） BLE Micro Pro自体はコンスルーをはんだ付けするだけですが、今回はもげ対策として、ダイソーで買ってきたグルーガンで ちょっとだけ補強してみました。 初グルーガンだったので不細工だけど。これ難しいな。\n効き目あればいいけど？\nLPME-IO対応 いくつかのジャンパをはんだでブリッジ まずは、LPME-IOのREADMEのページの導入手順を読み、いくつかのピンをジャンプしました。 せきごんさんのBLE-Micro-Proのリポジトリに、CorneのLPME用コンフィグファイルを見ると、ジャンプするのは20, 19, 18, 17, 16, 15に対応している、F,E,D,C,B,Aの６つです（写真撮り忘れた。。。）。\nTRRSのI2C対応（って言い方であってるのかなぁ？） ジャンプだけでいけないかなぁ？と思いましたがダメでした（USBでつないでみたけど、左手（BLE-Micro-Proがついている側）だけ入力可能です。\nBLE Micro Proの公式サイトにLPME-IOについても記載があります。 実績のあるキーボード一覧にCorne Lightの記載もあったので、試してみようと思ったのが発端です。\nただ、LPME-IOの欄に注意書きが。\n*LPME-IOを使うには改造が必要\nまた、一覧の最初にも記載があります。\nLPME-IOを使うにはキーボードの左右の有線通信がI2Cである必要があります。とくにOLEDに対応しているキーボード等の場合は、I2C用のピンをTRRSジャックに接続する改造を施すことでI2C化できる場合があります。\nまだ、自作キーボードの仕組みをがっつり理解しているわけではない初心者なので、まぁ、ちょっとわからないかなと。。。 BLE Micro Proのはじめにのページを見ると、 Self Made keyboard in JapanのDiscordに専用チャネルがあるようで、過去ログを検索してみました。 検索したところ、Corneの場合Micro ProのSDA(写真の青い線)とSCL(写真の黄色い線)（参考：Corneの基盤の図）をそれぞれ、TRRSの２つのピンに接続する必要がありそうだというコメントがありました。\nCorne Cherry v2の場合は、接続するためのショートカットが用意されていましたが、Corne Light v2だと見当たりませんでした。 ということで、線を使って物理ショートカットしました。ちなみに、ショートカットは両手ともに必要なようです。\nUSB-Cで接続テスト 上記対応が終わって、基板に設置してUSB-Cケーブルで接続したところ、外部ドライブとして見えるようになりました。\nキーマップの書き換えとか 公式ドキュメントのBLE Micro Pro Web Configuratorを使うの手順通りに書き込みを行っていくと、特に問題なく接続できました。 便利すぎですね。キーマップの変更は、これまでのCorneのキーマップJSONファイルからコピペして書き込んだだけです。 （この後、BLE用のキーマップを書き足すためにもう一度変更しますが）\nLPME-IO対応なので、Micro Proは片側しかないので、書き換えも楽々でした。\nBLEで接続テスト 今回の目的だったWindowsにBluetoothで接続できるようにしてみました。 最初はサリチル酸さんの記事を見ていたのですが、キーコードがちょっと変わっているようでした。\nで、よくよく見ると、BLE Micro Pro Web ConfiguratorにBLE関連のキーも用意されているじゃないですか。。。\nBLE関連のキーを割り当てた後は、USBをオフにして、Bluetoothをオン、BTNEWで新しくペアリングするようにすれば接続完了でした。\n課題 これまでと違い、すんなり実装ができましたがまだいくつか気になる点が。\n複数の機器とペアリングして切り替え Macともペアリングしてみようとしたのですが、切り替えがうまくいかないようで。。。 OLEDつけるにはどうするんだろう？ 左手側は電池が乗っているのですが、右手側はLPME-IOだけなので、上にOLEDを載せる余裕があります。 なので載せてみましたが点かないですね。ファームウェアを何かしないといけないんじゃないかな？調べないとなぁ。 という感じです。 まだちゃんと長時間使っていないので、他の問題点も出てくるかもしれませんが、まぁとりあえず使ってみてからかな。 うまくいくようなら、メインマシンにBluetoothモジュール追加してみるのもありかと考えているところです。\n調べながら、自分なりに対応してみましたが他にもいい方法とかあれば教えてもらえると助かります。\n","date":1610332951,"dir":"post/2021/","id":"4ad8239a37f641bcd17abeb96106314e","lang":"ja","lastmod":1610332951,"permalink":"https://blog.johtani.info/blog/2021/01/11/apply-ble-and-lpme-to-corne/","publishdate":"2021-01-11T11:42:31+09:00","summary":"メインマシンとMacは下記のサンワサプライのUSB接続のKVMスイッチを使っていますが、もう一台ノートPCがありここに接続しているCorne","tags":["DIYキーボード","misc"],"title":"Corne Light v2のBLE+LPME-IO対応 #DIYキーボード"},{"contents":"振り返りブログにも書きましたが、デスクトップPCを自作(DIY)しました。 組み立てたに使ったパーツのアフィリンクを貼っておきます。\n10月くらいにPC組もうと思って、組み上がったのは11月半ばでした。 最初はもうちょっと小さいPCにしようと思ってたのに気づいたらATXになってました。 パーツの選定の基準は以下のツイートです。影響されやすいなぁ。\nタワーってほど大きくなくていいと思いますが、NZXT H510 ぐらいの大きさは欲しいですね。https://t.co/s1c1fOnPyI\n単純に、スペースがないと組みにくいのと冷えにくい、買ってきたものがやっぱりこれだと入らない、というリスクがかなり減るので。\n\u0026mdash; さぼてん（さぼ福）🌵 (@cactusman) October 9, 2020 今年3台作りました。ノートPC使えない体になります。 pic.twitter.com/8zDmeRwNkS\n\u0026mdash; miyake | ZEN (@kazuyukimiyake) October 9, 2020 白いケースいいなぁという感じで、ケースとCPUクーラーが決まったんで、ググってこちらのHAKKAさんのYouTube見ながら妄想してました。 パーツがなかなか揃わなくて。 そして、PCが光るのどうなの?と思ってたのに、気づいたら光ってました(なぜ?)。\nグラボがない状態(CPU内蔵GPU)で12月頭までは動作してました。\n購入自体はTSUKUMO、ビックカメラオンライン、パソコンSHOPアーク、イートレンドオンラインショップでオンラインで購入しました。\nPCケース Amazon | NZXT H510i White CA-H510I-W1 CS7946 | NZXT | PCバッグ・ケース・スリーブ 電源 Amazon | NZXT E850 デジタル電源ユニット 80 Plus Gold 認証 [ 定格 850W 出力 ] NP-1PM-E850A-JP NP-1PM-E850A-JP SP947 | NZXT | パソコン・周辺機器 通販 マザーボード Amazon | ASRock AMD Ryzen 3000シリーズ CPU(Soket AM4)対応 X570チップセット搭載 ATX マザーボード X570 Steel Legend | ASROCK CPU AMD Ryzen 4750G\nCPUクーラー Amazon | NZXT KRAKEN Z63 簡易水冷CPUクーラー 液晶モニタ搭載 RGB対応 280mm RL-KRZ63-01 FN1441 | NZXT | CPUファン 通販 メモリ Amazon | G.SKILL 128GB（4 x 32GB）Trident Z NeoシリーズDDR4 SDRAM 3200MHz PC4-25600デスクトップメモリモデルF4-3200C16Q-128GTZN | G.Skill | メモリ 通販 SSD Amazon | Seagate FireCuda 520 M.2 1TB PCIe Gen4x4 内蔵SSD M.2 2280 3D TLC ZP1000GM3A002 | SEAGATE グラボ Amazon | GIGABYTE NVIDIA GeForce RTX3080搭載 グラフィックボード GDDR6X 10GB ホワイトモデル【国内正規代理店品】GV-N3080VISION OC-10GD | 日本ギガバイト 拡張カード Amazon | ASRock 拡張インターフェースボード Thunderbolt 3 AIC R2.0 | ASROCK | インターフェースカード 通販 拡張カードは実は差し込んだら最初うまく動かなくてサポートに連絡しました。同じ構成の検証機を用意して解決方法を見つけてもらいました。しかも数日で。サイコーのエクスペリエンスでした!\n日本語でサポートしてもらえてしかも数日で解決してもらった。ASRockのサポートすばらしかったです！ https://t.co/8FasCInIqt\n\u0026mdash; Jun Ohtani (@johtani) December 8, 2020 その他 ケースのフロントパネルのUSB-Cポートを使えるようにするために。\nAmazon | Cablecc USB 3.1フロントパネルソケットType-E-マザーボード用USB 3.0 20ピンヘッダーオス拡張アダプター | cablecc | PCアクセサリ・サプライ 通販 最近のPCパーツはUSBでモニタリングできるみたいで、マザボのUSBポートが足りなかったので拡張しました。\nAmazon | マザーボードのUSB 9ピン 増設 内部用4ポートUSB2.0 HUB | ノーブランド品 | USBハブ 通販 白いケースだし、「映え」のために白いケーブルを。\nAmazon | Novonest 電源専用延長スリーブ 補助電源モジュラーケーブル 長さ300mm 6本1セット スリーブガイド24点セット付き 【SC304】 | ｎｏｖｏｎｅｓｔ | 電源ユニット 通販 組み立て中 手元にあったCPUでBiosアップデート(Ryzen 5000シリーズにしたかったから。まだできてないけど)。\n応急処置でBiosアップデートしてる pic.twitter.com/mXf2B5kwqB\n\u0026mdash; Jun Ohtani (@johtani) November 8, 2020 さーて、頑張るぞー pic.twitter.com/HmlGqREjmP\n\u0026mdash; Jun Ohtani (@johtani) November 13, 2020 さて、仮起動実験ですよと pic.twitter.com/5HP3cbs6SH\n\u0026mdash; Jun Ohtani (@johtani) November 13, 2020 きたきたー pic.twitter.com/4sL3ymecEo\n\u0026mdash; Jun Ohtani (@johtani) November 13, 2020 コネクター刺しまくらないと pic.twitter.com/Soye3lS4M9\n\u0026mdash; Jun Ohtani (@johtani) November 13, 2020 完成はこんなかんじ 初期構成\n組み上がったよー pic.twitter.com/sBwpvLsZh3\n\u0026mdash; Jun Ohtani (@johtani) November 14, 2020 グラボデプロイ\n設置完了してこんな感じ。なんかベンチマーク走らせるかなぁ。何がいいだろ pic.twitter.com/aZufAE9fJA\n\u0026mdash; Jun Ohtani (@johtani) December 4, 2020 グラボのおまけも付けてみた。\nまぁ、せっかくついてきたので取り付けてみました（グラボ下の光ってるパネル）。 pic.twitter.com/068IxaV1ps\n\u0026mdash; Jun Ohtani (@johtani) December 4, 2020 とまぁ、こんな感じでした。 メモリは多分使い切れないだろうなぁと思いながら、やってみたかったという感じです。。。\n","date":1609422526,"dir":"post/2020/","id":"64a421c2367372c3199c66a6420faf89","lang":"ja","lastmod":1609422526,"permalink":"https://blog.johtani.info/blog/2020/12/31/diy-pc/","publishdate":"2020-12-31T22:48:46+09:00","summary":"振り返りブログにも書きましたが、デスクトップPCを自作(DIY)しました。 組み立てたに使ったパーツのアフィリンクを貼っておきます。 10月くら","tags":["misc"],"title":"PCもDIYしました"},{"contents":"今年も振り返りブログ書いてます。カタンの航海者版を購入して家族とやってましたが、負けてしまいました。\n振り返り（2019年に書いた抱負から） まずは去年の抱負を元に書きますが、3月以降はコロナウィルスの影響でいろいろと生活が変わってしまいましたね。\n職につく 厳密には達成してないことになるのかな？\n1月末にフリーランスはじめました(仮)という記事を書きましたが、 そのまま、現時点では個人事業主でフリーランスとして4社ほどお手伝いさせていただいています。\nお手伝いしてるお客さんの事例が出てた。直接的に類似画像検索の部分を手伝ってるわけではないんですが、Azure Cognitive Searchの調査とかやってます。 / 「ハッカソン」で社外の知見を積極的に活用! 富士フイルムソフトウエアが実践するサービス開発の理想形 - https://t.co/yDIwYmYDBM\n\u0026mdash; Jun Ohtani (@johtani) June 19, 2020 名前出てた。ZOZOさんの手伝いさせていただいております。 / ZOZOTOWNにおける検索速度改善までの道のり - ZOZO Technologies TECH BLOG - https://t.co/OqaFMYe0TY\n\u0026mdash; Jun Ohtani (@johtani) August 20, 2020 こんな感じです。 コロナウィルスの影響もあり、完全リモートで仕事をさせていただいています。 感謝しかないです。\nブログプラットフォームの移行 昨年の振り返りの時点で目を付けていたHugoへの乗り換えを行いました。 乗り換えについてもまとめてあります。\nOctopressからHugoへ移行中(まだ途中) ブログ移行日記(その1) - Hugoとテーマ ブログ移行日記(その2) - Markdownファイルの変換 ブログ移行日記(その3) - Hugoの設定と微調整(テーマに合わせた) ブログ移行日記(その4) - 検索機能(Algolia)の導入 ブログ移行日記(その5) - Jugemのブログを移行 無事移行できて、特に困ってない感じです。\nプログラミング 昨年よりは書いた気がしています。 まぁ、書きなぐって放置してるのもありますが。。。\n細々としたツールがいくつか。\nfrom-octopress-to-hugo bulk2es-rs azure-search-analyze-client wiki-extractor-rs kuromoji-graphviz-output kuromoji-cli あとは、Linderaという形態素解析も手伝ってみました。 ちょっと後半は忙しくなり、コーディングが減ってるんで、また復活させないと。\nRust再入門 Tantivyは結局触れてないけど、Linderaを手伝えました。あとは、ちょっとしたツール(bulk2es-rs)なども作りました。 知り合いとやっていたRust the bookを読むのも一通り終わりました。 Linderaまわりのリファクタとかを年明けにやろうかな?\n検索の勉強 仕事になりました。というか、しました。 ブッチャー本も買ったんですが、手を付けられてないので、年明けから心機一転、よみ始めようと思います。\n検索技術勉強会の継続 残念ながらだめでした。 年初にスピーカーの方に連絡は入れて履いたのですが、コロナウイルスの影響で 今年はオフラインの勉強会は無理だろうとい事で延期したままです。 オンラインの勉強会もいくつか開催されていましたが、検索技術勉強会は残念ながらモチベーションもわかずのまま今年も終わってしまいました。 単に話を聴くセミナーのようなものよりは、Podcastのような形を取るのがいいのかもなぁとは思っているのですが。。。 だれか、サクッと話したい人いたらやってみませんか?\n振り返り(今年あったできごと) さて、ここからは今年の出来事を。\n自宅環境の改善 Windowsへの移行 キーボードDIY フリーランス ブログ書いたなぁ 3月以降はずーっと自宅で仕事してました。 ということで、自宅の環境がどんどんアップデートされていった1年でした。 最終バージョンは年内に間に合わなくて、年明けに書きますが。。。 途中経過はこんな感じでした。今は更に変わっていますが。\n3月バージョン 9月バージョン 12月バージョンでも書きますが、ずっと自宅で作業だったのもあり、自作PCをやりたくなったので、久々にWindowsに帰ってきました。Ubuntuもチョット検討しましたが、Windowsに今は落ち着いています。自作PCはこんな感じ。 自作PCブログも後で書きますね。\n設置完了してこんな感じ。なんかベンチマーク走らせるかなぁ。何がいいだろ pic.twitter.com/aZufAE9fJA\n\u0026mdash; Jun Ohtani (@johtani) December 4, 2020 Windowsをお試し中 Windowsへの移行（その１） AutoHotKeyで色々と弄っているので、素のWindowsは触れる気がしないけど。。。\n自作つながりで、キーボードもDIYしました。\nDozen0を作成した Corne Light v2を作成した Corne Chocolateを組み立てた Sofle Keyboardも組み立てた(けど、ビルドブログはまだ) 分離キーボードには昨年から興味があったのですが、手を付けていませんでした。 今年は自宅でずっと作業でしたから、これを機会に作ってみました。 既製品(Moonlander)も気になってはいたのですが、DIYキーボードはプラモデル感覚で作れそうだし面白そうだなと。 今年一番ハマったものかもしれないです。 知り合いが始めたKochi Keyboardで最初に発売されたのがCorne Light v2だったので、これが初めての分割キーボードです。 40%キーボードからいきなり入ったので最初はかなり大変でしたが、なれると入力が早くなる気がします。ホームポジションからほぼ動かないのはいいですね。最初は数字列がないのでアホか???と思っていましたが。 今は、Sofle(60%キーボード)がメインになっています。40%から60%に移行すると 数字のキーが遠いなと思ってしまいますねw\nどうなるものかと思いつつ、フリーランスを続けています。 最初に仕事をいただいた富士フイルムソフトウェアさんには非常にお世話になっています(今もお手伝いさせてもらっています、ありがたい)。来年も精進していきます!\n今年はブログを書きました、最後はちょっと息切れしてる感じになってるけど。。。 もっとカジュアルに書くようにしないとなぁ。 年明けにまだ書いてないブログを書いていかないと。「自作PCブログ」「Sofleのビルドブログ」「2020年買ってよかったブログ」とか。\n来年の抱負 ということで、来年の抱負です。\nフリーランス継続? プログラミング 検索の勉強 検索のポッドキャスト? とりあえず今年は乗り切れました。来年も食べていくためにもフリーランスを継続できるように、お手伝いさせて頂いてる各社に 継続してもらえるように精進していきます。色々と勉強させて頂いてるのでほんとうにありがたいです。\nプログラミングは今年の後半はスローダウンしてしまったのでがんばらないと。 検証用のコードやちょっとしたツールを書くほうが多いので、もう少し継続してメンテナンスするようなものも書きたいなぁと。\n検索の勉強はまずはブッチャー本を買ってしまったので、ここからでしょうか。 値段も厚みもすごいので、コツコツ元を取れるようにがんばります。。。\n来年もまだまだ自宅で仕事が続きそうなので、勉強会というよりもポッドキャストみたいなものをやるのがいいのかもなと。 2020年初にやらせていただいた、「検索システム探訪」をポッドキャスト風にやるのもありなのかもなぁ。 興味ある人いたら連絡ください。公開しない雑談とかもありだと思ってるので。\n今年は色々ありましたが、無事に乗り切れました。 気軽にランチなどで遊びに行けない状況ですが、雑談相手になっていいなと思う方、連絡お待ちしています。\nさて、来年はどんなキーボード作るのかなぁ(え?また作るの??)。 今後もよろしくおねがいしまーす!\n","date":1609406004,"dir":"post/2020/","id":"a5b2ee641e10d3e4db8f888217ab9ecc","lang":"ja","lastmod":1609406004,"permalink":"https://blog.johtani.info/blog/2020/12/31/looking-back-2020/","publishdate":"2020-12-31T18:13:24+09:00","summary":"今年も振り返りブログ書いてます。カタンの航海者版を購入して家族とやってましたが、負けてしまいました。 振り返り（2019年に書いた抱負から） ま","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2020）"},{"contents":"Elastic stack (Elasticsearch) Advent Calendar 2020の18日目の記事になります。\n本日の勉強会でLTをしましたが、しゃべり足りなかったんで。 Elasticsearch 7.8でこっそりとリリースされたIndex Template V2について調べたのでどんなものかをまとめてみます。 リリースブログには出てきてない（7.8のEsのページのWhat\u0026rsquo;s newには出てた）ので気づいてない人も多いのではないでしょうか？\nIndex Templateとは？ まずはIndex Templateがどんなものかを説明しましょう。\nIndexの設定やマッピングはデフォルト値以外を設定したい場合に、毎回\u0026quot;mappings\u0026quot;や\u0026quot;settings\u0026quot;の設定を指定してIndexを作成するのは手間がかかります。 そこで便利な機能として提供されているのがIndex Templateです。このIndex TemplateはCluster Stateに保管されます。\nIndex Templateを利用するときの流れは以下の通りです。\nIndex Templateの作成 Indexの作成 例えば、3ノード構成のクラスターでインデックスを作成するときに常に\u0026quot;number_of_shards: 3\u0026quot;を設定したいとします。 Index Templateは次のような感じになります。\nPUT _template/blog_num_shards { \u0026#34;index_patterns\u0026#34;: \u0026#34;blog_*\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;index\u0026#34;: { \u0026#34;number_of_shards\u0026#34;: 3 } } } または日本語のシンプルな形態素解析のアナライザーの設定を\u0026quot;jp_\u0026ldquo;という名前でるようできるようにしたい場合には次のような感じになります。\nPUT _template/jp_simple_kuromoji { \u0026#34;index_patterns\u0026#34;: \u0026#34;jp_\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;index\u0026#34;: { \u0026#34;analysis\u0026#34;: { \u0026#34;simple_jp\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji\u0026#34; } } } } } インデックステンプレートの登録が終われば、インデックスを作成するタイミングでIndex Templateが適用されます。 例えば、blog_2020というインデックスを作成すると、number_of_shards: 3のインデックスが作成されます（デフォルトは1）。 jp_blog_2020というインデックスを作成すると、simple_jpというAnalyzerが設定されています。 このように、インデックス名を意識するだけで設定が適用されていくのが利点です。\nちなみに、Index TemplateはIndex作成時に適用されるだけなので、Index Templateを変更してもこれまでのインデックスへは影響はありません。\nこれまでのIndex Templateの問題点 と、Index Templateが便利なのはわかりましたが、ではなぜ今回V2がリリースされたのでしょうか？ 先ほどの例を見るとわかりますが、これまでのIndex Templateは部品化が難しいのが問題でした。 Index Templateはそれぞれがインデックスの作成時に適用されます。 が、Index TemplateにIndex Templateを組み込むことはできません。 例えば、先ほどサンプルとして作成したjp_simple_kuromojiのIndex Templateはjp_で始まるインデックスにしか適用できません。\nでは、blog_で始まるインデックスにもkuromojiのシンプルなアナライザーを使いたくなった場合はどうなるでしょう？ 残念ながら、jp_simple_kuromojiと同じ設定をblog_num_shardsのテンプレートに追加するか、jp_simple_kuromojiのindex_patternsの部分だけを書き換えた新しいテンプレートを用意するか、jp_simple_kuromojiのindex_patternsにjp_を追加する方法です。 いずれにしてもIndex Templateの継承（複数のテンプレートを1つのインデックスに紐づける）が必要となります。 この時、複数のIndex Templateが適用されるため、適用する順番が出てきます。 この順番をIndex Templateのorderパラメータで指定できます。\nただ、これも問題のもととなっていました。 複数あるIndex Templateのどれがどの順番で適用されるのか？それはインデックスを作成時にようやくわかります。 使いたい側（インデックス）が、使いたいもの（テンプレート）を指定するのではなく、その逆（使いたいものに使いたい側の情報を設定しなくてはならない（index_patternsやorder））になっているのでわかりにくくなっていました。\nということで解決策としてリリースされたのがIndex Template V2です（ちなみに名前にV2とは言ってるわけではなく、現在のIndex Templateの機能がlegacy index templateという名前になり、Deprecatedになっています（まだログには出ない））。\nIndex Template V2 7.8のWhat\u0026rsquo;s newドキュメントではComposable Index Templateと紹介されています。 大きく3つのエンドポイントが提供されます。\nComponent Template 用API テンプレートのコンポーネントという単位で管理するためのAPI。 登録更新、削除、取得が可能 Index Template 用API Index Templateを管理するためのAPI 登録更新、削除、取得が可能 Simulate index template API(Experimental) Index Template Legacy Index Templateとの大きな違いは、\nテンプレートをコンポーネントにできる 1つのインデックスに適用されれるテンプレートは1つだけ という点です。これまでとは挙動が異なるので注意が必要です。\n新しいIndex Templateを利用する際の流れは次のようになります。\nComponent Templateの作成 Index Templateの作成 作成したIndex Templateの挙動を確認 実際にIndex名を指定してIndex Templateの挙動を確認 という形です。では、それぞれの機能を見ていきましょう。\nCoponent Template API テンプレートコンポーネントを管理するためのAPIです。 具体的なAPIごとに説明していきます。\nPUT _component_template コンポーネントを登録、変更するためのAPIです。公式ドキュメントはこちらです。 先ほどのkuromojiのAnalzyerをコンポーネントとして登録してみましょう。\nPUT _component_template/jp_simple_kuromoji { \u0026#34;template\u0026#34;: { \u0026#34;settings\u0026#34;: { \u0026#34;index\u0026#34;: { \u0026#34;analysis\u0026#34;: { \u0026#34;analyzer\u0026#34;: { \u0026#34;simple_jp\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji_tokenizer\u0026#34; } } } } } }, \u0026#34;version\u0026#34;: 1, \u0026#34;_meta\u0026#34;: { \u0026#34;description\u0026#34;: \u0026#34;simpleなKuromoji analyzer\u0026#34; } } 先ほどと特に違いはありません。templateという階層が1段増え、index_patternsがなくなりました。 template部分はIndexに設定するsettings、mappings、aliasesが指定可能です。 ちなみに、\u0026ldquo;template\u0026quot;の中身をそのままIndex作成時に使用した場合にエラーにならない設定である必要があります。 ここは注意が必要です。例えば、component Aでkuromojiのアナライザーの設定をし、component Bでそのアナライザーを使用するフィールドのmappingだけを記述した場合、component Bでエラーが発生します。上記のようなシチュエーションでは、Index Templateで利用するフィールドを定義し、component Aを利用する宣言をすれば問題ありません。\nそのほかに使えるパラメータで便利なものを紹介しておきます。\nクエリパラメータ\ncreate: URLに指定するパラメータ。trueを指定することで、既に存在する場合にエラーを返してくれる。更新も同じAPIなので間違わないようにするために利用すると便利。デフォルトはfalse リクエストボディ\n_meta: テンプレートにメタ情報を付与できる。_metaの中は自由に記述可能。コメントなどを書いておくとあとでわかりやすい GET _component_template コンポーネントを取得するためのAPIです。公式ドキュメントはこちらです。 一覧での取得とリストでの取得が可能です。\n一覧取得サンプル\nGET /_component_template GET /_component_template/* これ以外に、IDを指定して取得することも可能です。\nGET _component_template/jp_simple_kuromoji *を利用して複数取得も可能です。\nGET _component_template/jp* GET _component_template/j*_* DELETE _component_template コンポーネントを削除するためのAPIです。公式ドキュメントはこちらです。 IDを指定してコンポーネントを削除できます。\nDELETE /_component_template/jp_simple_kuromoji ID指定以外に*を利用することも可能ですが気を付けて使用しましょう。\nDELETE /_component_template/jp_* DELETE /_component_template/* ちなみにIndex Templateで利用されているコンポーネントを削除しようとした場合はエラー（ステータスコード400）が返ってきます。 *などを使用して削除しようとした場合は、ひとつでも利用されているものが含まれている場合は削除は実行されずにエラーだけが返ってくるようになっています。\nIndex Template API Index Templateを管理するためのAPIです。 Component Template APIで定義したコンポーネントを利用してテンプレートを作成できます。コンポーネントを利用しないで単体で完結したテンプレートも作成可能です。 具体的なAPIごとに説明していきます。\nPUT _index_template Index Templateを登録・更新するためのAPIです。公式ドキュメントはこちらです。\nこれまでのLegacy Index TemplateのAPIのエンドポイント(_template)ではなく、(_index_template)というエンドポイントになっていることにまず注意してください。 先ほど作成したjp_simple_kuromojiコンポーネントと、追加で作成した3_shardsというコンポーネントを利用して blog_で始まるインデックスに適用できるIndex Templateを作成してみましょう。\nPUT _index_template/blog_template { \u0026#34;index_patterns\u0026#34;: [\u0026#34;blog_*\u0026#34;], \u0026#34;template\u0026#34;: { \u0026#34;mappings\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;hoge\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;text\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;simple_jp\u0026#34; } } } }, \u0026#34;priority\u0026#34;: 100, \u0026#34;composed_of\u0026#34;: [\u0026#34;jp_simple_kuromoji\u0026#34;, \u0026#34;3_shards\u0026#34;] } composed_ofというパラメータに利用したいコンポーネントを配列で記述していきます。 Index Templateが適用される時に、ここに記述されている順番でコンポーネントが適用されていきます。 ですので、最後に書いてあるテンプレートが一番強いことになります。 これは例えば、同じ設定値number_of_shardsを2つのコンポーネントが設定している場合に、最後に設定した値がインデックスに採用されるという意味です (公式ドキュメントにサンプルが掲載されています)。 なお、存在しないコンポーネントをcomposed_ofに指定した場合は400エラーが返ってきます。同じコンポーネントを複数重複して指定した場合は特にエラーにはなりませんでした。 composed_ofを指定しなければ、単体で完結したテンプレートを定義可能です。\n次に重要な設定はpriorityです。これまでのテンプレート機能と異なる点で説明しましたが、\n1つのインデックスに適用されれるテンプレートは1つだけ となっています。 この1つを決めるための値がpriorityになります。 インデックス名によってはindex_patternの定義によって、複数のIndex Templateにマッチします。例えばblog_*と*_2020のIndex Templateがあった場合にblog_2020というインデックスを作った場合です。 この時、Elasticsearchはpriorityの大きい値を持ったIndex Templateだけを適用します。 blog_*のIndex Templateのpropertyが10、*_2020のIndex Templateのpropertyが100だった場合、*_2020のテンプレートが適用されます。Legacy Index Templateではorderという似たパラメータがありましたが、こちらは適用する順序を決定するためのものでした。挙動が違うので注意しましょう。\nちなみに、blog_*と*_2020のpropertyがどちらも10というIndex TemplateをPUTしようとした場合、2番目にIndex TemplateをPUTするタイミングでエラーが返ってきます。\nそのほかに使えるパラメータで便利なものはPUT _component_templateと同様にcreateと_metaです。\nGET _index_template Index Templateを取得するためのAPIです。公式ドキュメントはこちらです。 一覧での取得とリストでの取得が可能です。\n一覧取得サンプル\nGET /_index_template GET /_index_template/* これ以外に、IDを指定して取得することも可能です。\nGET _index_template/blog_template *を利用して複数取得も可能です。\nGET _index_template/blog_* GET _index_template/b*_* DELETE _index_template Index Templateを削除するためのAPIです。公式ドキュメントはこちらです。\nIDを指定してコンポーネントを削除できます。\nDELETE /_component_template/jp_simple_kuromoji ID指定以外に*を利用することも可能ですが気を付けて使用しましょう。\nDELETE /_component_template/jp_* DELETE /_component_template/* 最後のサンプルを実行すると、Elasticのツールなどが登録したIndex Template以外はすべて削除されてしまうので本当に気を付けましょう。\nSimulalte API さて、コンポーネントとテンプレートを作成したので確認をしましょう。 Legacy Index Templateでは確認するためには実際にインデックスを作成するしかありませんでしたが、V2ではSimulate APIが用意されています。 このSimulate APIには2つのAPIがあります。\nPOST /_index_template/_simulate/\u0026lt;テンプレート名\u0026gt; POST /_index_template/_simulate_index/\u0026lt;インデックス名\u0026gt; Index Templateの確認のためのAPIとインデックス名を指定したときに出来上がるIndexの設定を確認するためのAPIです。 Indexを実際に作成しなくても確認できるのは便利ですね。\n例えば先ほど作成したblog_templateを試してみましょう。\n_index_template/_simulate API POST _index_template/_simulate/blog_template レスポンスはこんな感じです。\n{ \u0026#34;template\u0026#34; : { \u0026#34;settings\u0026#34; : { \u0026#34;index\u0026#34; : { \u0026#34;analysis\u0026#34; : { \u0026#34;analyzer\u0026#34; : { \u0026#34;simple_jp\u0026#34; : { \u0026#34;filter\u0026#34; : [ \u0026#34;kuromoji_readingform\u0026#34; ], \u0026#34;type\u0026#34; : \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34; : \u0026#34;kuromoji_tokenizer\u0026#34; } } }, \u0026#34;number_of_shards\u0026#34; : \u0026#34;3\u0026#34; } }, \u0026#34;mappings\u0026#34; : { \u0026#34;properties\u0026#34; : { \u0026#34;hoge\u0026#34; : { \u0026#34;type\u0026#34; : \u0026#34;text\u0026#34;, \u0026#34;analyzer\u0026#34; : \u0026#34;simple_jp\u0026#34; } } }, \u0026#34;aliases\u0026#34; : { } }, \u0026#34;overlapping\u0026#34; : [ { \u0026#34;name\u0026#34; : \u0026#34;blog_template2\u0026#34;, \u0026#34;index_patterns\u0026#34; : [ \u0026#34;blog_*\u0026#34; ] } ] } templateにコンポーネントがマージされた結果が出力されます。 overlappingはindex_patternsがかぶる可能性があるIndex Templateの情報が出力されます。 サンプル用にblog_template2という、同じindex_patternsでpriorityが低いものを登録してあるためです。 index_patternsが完全に同じではなくとも、重複する可能性があるものはここに出力されます。 例えば、index_patternsがb*という別のIndex Templateを作成してからSimulate APIを実行すると、overlappingにそのIndex Templateも出力されます。\nSimulate Index Template APIのもう一つの機能は登録前のIndex Templateの確認です。 リクエストのURLのテンプレート名をなくし、PUT _index_templateと同じJSONをリクエストボディとして送信した場合、コンポーネントをマージしたテンプレートがどんなものかを確認できます。\nPOST _index_template/_simulate { \u0026#34;index_patterns\u0026#34;: [\u0026#34;blog_*\u0026#34;], \u0026#34;template\u0026#34;: { \u0026#34;mappings\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;hoge\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;text\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;simple_jp\u0026#34; } } } }, \u0026#34;priority\u0026#34;: 10, \u0026#34;composed_of\u0026#34;: [\u0026#34;jp_simple_kuromoji\u0026#34;] } このリクエストを送信すると、コンポーネントがマージされた結果が返ってきます。index_patternsがかぶるものがある場合はoverlappingも一緒に返却されます。\n_index_template/_simulate_index API 今度はインデックス名を指定するSimulate APIを試してみましょう。\nPOST _index_template/_simulate_index/blog_2021 これだけです。\n{ \u0026#34;template\u0026#34; : { \u0026#34;settings\u0026#34; : { \u0026#34;index\u0026#34; : { \u0026#34;analysis\u0026#34; : { \u0026#34;analyzer\u0026#34; : { \u0026#34;simple_jp\u0026#34; : { \u0026#34;filter\u0026#34; : [ \u0026#34;kuromoji_readingform\u0026#34; ], \u0026#34;type\u0026#34; : \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34; : \u0026#34;kuromoji_tokenizer\u0026#34; } } }, \u0026#34;number_of_shards\u0026#34; : \u0026#34;3\u0026#34; } }, \u0026#34;mappings\u0026#34; : { \u0026#34;properties\u0026#34; : { \u0026#34;hoge\u0026#34; : { \u0026#34;type\u0026#34; : \u0026#34;text\u0026#34;, \u0026#34;analyzer\u0026#34; : \u0026#34;simple_jp\u0026#34; } } }, \u0026#34;aliases\u0026#34; : { } }, \u0026#34;overlapping\u0026#34; : [ { \u0026#34;name\u0026#34; : \u0026#34;fuga\u0026#34;, \u0026#34;index_patterns\u0026#34; : [ \u0026#34;b*\u0026#34; ] }, { \u0026#34;name\u0026#34; : \u0026#34;2021\u0026#34;, \u0026#34;index_patterns\u0026#34; : [ \u0026#34;*_2021\u0026#34; ] } ] } 例で作成したblog_templateが適用されていますが、それ以外にindex_patternsに合致したがpriorityが低くて適用されなかったものがoverlappingに出力されています。 実際に適用されたテンプレートの名前も別途出力してくれるとわかりやすいかもしれないですね。 (*_2021というインデックスパターンのテンプレートを試しに作ってみたのですが、これはバグがありそうです。2021に合致するインデックス名をSimulateしたらoverlappingに合致しないものがたくさん出てきました。バグ報告しとくか)。\nKibana対応 ここまで、Index Template V2のAPIの説明でしたが、Kibanaでの対応についても調べてみました。\nIndex Management（Stack Management機能。Elasticライセンスが必要だが無償の機能） 7.9からKibanaのIndex管理画面でComposable Templateが利用できるようになっています（GitHub Issue）。 画面のスクショを一通り貼っておきます。残念ながら、それぞれのJSONの編集部分では補完などはサポートされていないようでした。 頑張って自分でsettingsやmappingsのJSONを記述していく感じになります。JSONとして正しいかどうかはチェックしてくれます。 Index Templateのウィザードでは、ボタンでコンポーネントを追加したり削除したり、順序を入れ替えたりといった作業が可能になっています。 また、プレビュー表示が可能なので、composed_ofで選択したものが今どのように適用されているか？といったのも確認できるようになっていました。 結構便利に管理できそうです。ちなみにスクショは7.10の画面になります。\nComponent Template周り 一覧表示とウィザード Index Template周り 一覧表示とウィザード Console(Dev Tools。OSSで利用可能) リクエストを実行は可能ですが、自動補完機能は一部のみ対応しているようです(GitHub Issue)。\n対応済みの機能\nDELETE _component_template (ただし、ここまで。存在するコンポーネント名は補完されない) 上記以外はまだ未対応のようです。 プルリクエストチャンスかも？\n参考 Composable Templates · Issue #53101 · elastic/elasticsearch What’s new in 7.8 | Elasticsearch Reference ［7.8］ | Elastic Index management | Elasticsearch Reference ［7.10］ | Elastic ［Composable template］ Create / Edit wizard by sebelga · Pull Request #70220 · elastic/kibana ［Console］ Support suggesting index templates v2 · Issue #75967 · elastic/kibana まとめ ちょっと長くなってしまいましたが、新しいIndex Templateについての紹介でした。 これまでと違い、複数のテンプレートが適用されない点があるのでそこは注意が必要そうです。 コンポーネントをうまく使えば、管理が簡易化はされそうですね。\n","date":1608216955,"dir":"post/2020/","id":"c6fc88bd57a0e57ddf22e2eb1bef892c","lang":"ja","lastmod":1608216955,"permalink":"https://blog.johtani.info/blog/2020/12/17/index_template_v2/","publishdate":"2020-12-17T23:55:55+09:00","summary":"Elastic stack (Elasticsearch) Advent Calendar 2020の18日目の記事になります。 本日の勉強会でLTをしましたが、しゃべり足りなかったんで。 Elasticsearch 7.8でこっそりとリリースされたI","tags":["elasticsearch"],"title":"Index Template V2"},{"contents":"はじめまして、pyspa。 ということで、pyspa Advent Calendar 2020の4日目(大谷コンビの2号)の投稿になります。 コンビそろってキーボード記事ですね。\n今年はDIYキーボードにはまった（はめられた？）年でした。 もともと分割キーボードには興味があり、自宅で作業するのが基本となったのもあり手を出した次第です。 まだまだ使いこなすところまでは来てないかもしれないですが、組み立てたり、問題点のキリ分けしたり、試行錯誤するのは楽しいなと。\n今回はCorne Chocolateというキーボードを組み立てたのでそちらのビルドログ（かつ今後のための教訓）になります。 LEDを使ったキーボードがどんなものなのか＋薄いキーボードも気になるなということで取り組んでみました。 今回もいくつか失敗をしつつ、リカバリーして動くものができました。\nパーツ（材料） 基本のパーツは今回もKochi Keyboardさんから購入しました。\nキット : Corne Chocolate（ベースキット） キースイッチ : Kailh Choc v1 Blue (25gf リニア) 5個 キーキャップ : Kailhロープロ刻印キーキャップ ケーブル類は家に転がっていたケーブルを利用しました。 キースイッチセットもあるのですが、軽いキータッチが好みなので、一番軽いKailh ChocのBlueを試してみたくキースイッチを個別に選択しました。 キーキャップはShiroを作るときに調達していたものを利用した形です。\n今回も公式のビルドガイドにざっと目を通してから着手しました。\n準備 ビルドログにもあるようにPCBがリバーシルブなので、作業中に迷子にならないようにこんな感じで表にマスキングテープで目印をつけておきました。\n今回から耐熱ワーキングマットで作業をすることにしました。机の天板に傷つくの嫌だし。 気兼ねなくはんだできるのでおすすめです。\nhttps://t.co/0qntPD8qIa\n2ヶ月ぐらいにここで買いました！\n\u0026mdash; 西田和史(k.bigwheel) 開発基盤EM (@k_bigwheel) November 11, 2020 ダイオード、OLEDソケット、コンスルー、TRRSソケット、 こちらは前回のCorneとほぼ同様だったのでビルドガイド通りに進めます（写真撮り損ねました。。。） 前回との違いはダイオードの形です。 表面実装するタイプのダイオードなので向きに気を付けつつ、つけていきます。\nビルドガイドに向きやダイオードのつけ方が紹介されています。 拡大鏡とピンセット必須ですね。 前回同様に、ここまででいったんqmk_toolsでファームウェアをインストールして、ピンセットを使いながらキーの認識とOLEDの動作確認を行いました。 今使っているファームウェアがあるのでそれを入れて問題ないかを確認しました。\nLED実装 今回のメインイベントです（そして苦杯をなめたイベントでもあります）。 ビルドガイドにも記載がありますが、信号が流れる順番があるようなので1番から取り付けていきます。 また、ビルドガイドにLEDに関する注意事項もいくつか掲載されています。必ず読みましょう。\nこの1～6までのLEDがすごく大変でした。。。\n表面実装のLED（Underglow LED）で四苦八苦 いくつかのブログを参考にしながら作業を進めました。\nコルネキーボードを作りました ～LED取り付けに四苦八苦記～ | キオクノロンダリング SK6812miniの仕様などについて書いてあります。デバッグするのにすごく役に立ちました。 Corne Chocolateビルドログ - nokの雑記 手書きでどんな感じでやればいいのかを解説してくれています。最終的にはこの方法が一番だったのかも？ 自作キーボードキット「Corne Cherry」のレビュー - 自作キーボード温泉街の歩き方 あとで出てきますが、リカバリ方法の参考になりました。 皆さん苦労されてますね、そして私も苦労しました。。。\n試してみた方法、考察は次の通りです。\nLEDチェック用のファームウェアをインストールして1つつけては動作確認 HelixのLEDテスト用ファームウェアをインストールしました。 白光 1C型こて先 失敗した後にリカバリするために購入しました。 LEDのランドなどが2Cよりも面積が小さいので、そのサイズに合わせたこて先のほうがよかったようです。 はんだの温度（温調できるはんだごて必須） 最初は250℃でやっていましたが、なかなかはんだが溶けません。そのせいで焦りも出てきます。 最終的には270度で作業しましたが、温度のせいでLEDが壊れたのはなかった気がします。1Cのこて先だったので無事だったのかもしれません。 フラックスなし あると楽だったのかも？残念ながら試してないです。 予備はんだ手法（だめっぽかった） 基盤のランド4か所に予備はんだをし、はんだを温めつつLEDを乗せる方法 LEDの裏にも予備はんだ どちらも試してみましたが、温めている個所以外のはんだと高さの違いが出てしまい、LEDが浮いてしまいます。4か所を同時に温めることはできないので、すこしずつ調整しているうちにLEDを物理的に壊してしまうことがありました。。。 ちょっとコツが分かったかも？ pic.twitter.com/ruwrmEWCAe\n\u0026mdash; Jun Ohtani (@johtani) November 19, 2020 わかった気になっていますが結局失敗しました。。。\n結局最後までこれというコツはわかってない気がします。結局3つか4つのLEDがお亡くなりになりました。 うまくいかなかった原因は、予備はんだで傾きなどができ、それを修正していくうちに基盤やLEDにダメージを与えてしまったのだと思います。\nよく見ると基盤が一部剥がれかけてるのがわかるかなぁと。\nリカバリー 右手側の表面実装の4番と5番が失敗しました。\n4番目（以下のツイート右側画像の上） こちらは、1度付けたLEDをはがすときにはんだを取り除くのが不十分な状態でLEDをはがしたために、基板のランドごとはがれてしまいました。 なのでここはLEDはつかないです。。。 5番目(以下のツイート右側画像の真ん中あたりの黄色い線がつながっているLED) LED自体はつけてありますが、青色しか発光しなくなっています。 4番目が完全に死んでしまったので、無事な3番目のLEDのDINに流れている信号を 5番目のLEDのDINにも流れるようにするために10芯コードでショートカットさせました。 （リカバリ方法は先ほど紹介したブログが非常に参考になりました、先人の知恵ありがたし）。 黒い線も売っていたのですが、自戒も込めて目立つ色にしてみました。\n勉強させていただきました、、、 pic.twitter.com/Zp16fJKziM\n\u0026mdash; Jun Ohtani (@johtani) November 22, 2020 ちなみに、左側のショートカットのコードはつけた後に1か所LEDの向きが違うことに気づき必要なくなっています （上記の基盤が傷ついている画像をよく見ると上下が逆になってるのがわかる人にはわかるかも）。\n片方は導線なくて良くなった。表から見たら向きが違うのに気がついたわ、、、 pic.twitter.com/7TSDMPPxlX\n\u0026mdash; Jun Ohtani (@johtani) November 22, 2020 最終的に2か所おかしいLEDにはなりましたが、幸いにもアンダーグローです。 Kochi Keyboardさんで購入したキットのボトムプレートはFR4なのでほぼ見えません！（負け惜しみ）\nソケット さて、気を取り直してソケットをつけていきます。 Dozen0にて経験済みなのでそれほど手間はかかりませんでした。 LEDの失敗の時に1Cのこて先を購入していたため、ソケットの横の隙間からこて先が差し込めたのが便利でした（LEDでダメージを受けていたのもあり写真撮り忘れ）。\n完成 ということで完成です。デフォルトで赤く光ってます。キーキャップがLEDを透過してくれるタイプだったのがこれまたよかったですね。 作る前は光らなくてもなんて思ってたのに。\nキーマップ(v2) Corne Lightで作業を数週間ほどして、いくつか入力しにくい部分があったのでマッピングを少しだけ変えました。 相変わらず日本語キーボードベースですが、数字のレイヤーにいくつかの記号を使えるように割り当てました。 コーディングをするときに、ライブラリのバージョン（例：7.10.0とか）やIPアドレスを入力していてレイヤー切り替えのためのキーを押したり話したりするのは効率が悪すぎたためです。 数字との組み合わせでよく使いそうな以下のキーを数字のレイヤーに移動しました。\nセミコロン（JP_SCLN） コロン（KC_QUOT） アンダースコア（JP_UNDS） コンマ（KC_COMM） ピリオド（KC_DOT） スラッシュ（KC_SLSH） #include \u0026#34;keymap_jp.h\u0026#34; const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = { [0] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_TAB, KC_Q, KC_W, KC_E, KC_R, KC_T, KC_Y, KC_U, KC_I, KC_O, KC_P, JP_MINS, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, KC_A, KC_S, KC_D, KC_F, KC_G, KC_H, KC_J, KC_K, KC_L, JP_SCLN, KC_QUOT, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, KC_Z, KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_COMM, KC_DOT, KC_SLSH, KC_RSFT, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, MO(1), KC_SPC, KC_ENT, MO(2), KC_RALT //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [1] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_ESC, KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0, KC_BSPC, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, KC_LEFT, KC_DOWN, KC_UP,KC_RIGHT, JP_SCLN, KC_QUOT, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, JP_UNDS, XXXXXXX, KC_COMM, KC_DOT, KC_SLSH, XXXXXXX, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, _______, KC_SPC, KC_ENT, MO(3), KC_RALT\\ //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [2] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_TAB, JP_EXLM, JP_DQUO, JP_HASH, JP_DLR, JP_PERC, JP_AMPR, JP_QUOT, JP_LPRN, JP_RPRN, JP_CIRC, KC_BSPC, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, JP_MINS, JP_EQL, JP_LBRC, JP_RBRC, JP_YEN, JP_AT, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, JP_UNDS, JP_PLUS, JP_LCBR, JP_RCBR, JP_PIPE, JP_TILD, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, MO(3), KC_SPC, KC_ENT, _______, KC_RALT //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [3] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. RESET, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| RGB_TOG, RGB_HUI, RGB_SAI, RGB_VAI, RGB_SPI, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| RGB_MOD, RGB_HUD, RGB_SAD, RGB_VAD, RGB_SPD, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, _______, KC_SPC, KC_ENT, _______, KC_RALT\\ //`--------------------------\u0026#39; `--------------------------\u0026#39; ) }; LEDの色が変えられる！（気づくの遅い） あと、キーマップを変更しているときに4つ目のレイヤーにRGBなどのボタンがあるのに気付いて押してみたら、LEDのパターンや色を変えることができるのに気付きました。 （遅すぎでは。。。）\nキーキャップが白いのもありこんな感じの色にしてみています。\nユニコーンガンダムっぽくなった pic.twitter.com/vHxZkMrYyP\n\u0026mdash; Jun Ohtani (@johtani) November 28, 2020 まとめ ということで、失敗も多々ありましたがキーボードとしてはちゃんと動くできたものができたので安心しました。 今後、状況が落ち着いてきて自宅以外で仕事をするときにはCorne ChocolateをPCと一緒に持ち歩くと思います。 薄くて邪魔にならなくてよさそうです。\n今回もはんだっしゅ太郎大活躍でした。本当に買ってよかった。 LEDがつかないときはちょっと落ち込みましたが、これのおかげで立ち直れたのもありますし。 あとは、試行錯誤しつつLEDとかの理解ができたのも楽しかったです。 キーマップの変更時にLEDの変更などができるのに気づいたのはちょっと遅すぎたので、qmkの仕組みや割り当てられるキーにどんなものがあるのかをもう少し研究したいなと思います。\nさて、次はどんなことを試すかなぁ。\n","date":1607004824,"dir":"post/2020/","id":"a46c601d03a3a26bc418d0096fe83a42","lang":"ja","lastmod":1607004824,"permalink":"https://blog.johtani.info/blog/2020/12/03/build_corne_choc/","publishdate":"2020-12-03T23:13:44+09:00","summary":"はじめまして、pyspa。 ということで、pyspa Advent Calendar 2020の4日目(大谷コンビの2号)の投稿になります。 コンビそろってキーボード記事です","tags":["DIYキーボード","misc"],"title":"Corne Chocolateを組み立てた #DIYキーボード"},{"contents":"前回のブログのまとめに書いたように、セパレートタイプのキーボードであるCorne Light v2を作成したのでそのビルドログです。DIYキーボードとしては2つ目になります。\nまとめで書いていたお店が開店したので、購入してみました。 購入したのはこちらのKOCHI KEYBOARDさんです。 ついこの間オープンしたばっかりのお店です！\nなんで作ったの？ スプリット型（セパレートタイプ？どっちが正しいんだろう？）のキーボードに興味があって、KOCHI KEYBOARDさんで買えたのがこれだったというのが大きな理由です。こういうのってタイミングだと思うので。 あとは、組み立てていくのがプラモデルみたいで面白いというのもあります。 基本的にここのところ自宅で仕事をしているので、ノートPCのキーボードにこだわる必要もないなというのも理由ですね。今後も当面は自宅で仕事になると思いますので。\nCorne Light v2 foostanさんが設計された（って言い方であってるのかな？）、3x6のサイズに親指の3キーが配置された分離型のキーボードの一種です。 シリーズ？の名前としてはCorne Keyboardと呼ばれています。 （そういえば、由来は何だろう？自作キーボードがどうやって設計されていくのかという流れがまとめられた作者の方のブログがおもしろいです。） また、基板の設計などがGitHub上でMITライセンスで公開されています。 オープンソースなハードウェアというのも面白いです。\nビルドログ 作者の方がビルドガイドを公開してくれています。ですので、こちらに沿って作業をしていきます。 ちなみに、私は今回Gateronのクリア軸を選択してみました。さらさらと入力できるのが好きなので。 サイレント軸にも興味はあるのですが、今回は実際にスプリット型のキーボードを早く触ってみたいというのが勝ちました。キーキャップについては後述します。 ツイートに都度、写真をアップしていたので組み立ては画像でお楽しみください（時々取り忘れてるけどｗ）。\nうむ pic.twitter.com/svW9WdzaZv\n\u0026mdash; Jun Ohtani (@johtani) October 21, 2020 刺して曲げる pic.twitter.com/M0jfQJg2k8\n\u0026mdash; Jun Ohtani (@johtani) October 22, 2020 両方できたと。ハンダまでやって今日はおしまいにすっか pic.twitter.com/HgsSrxqpcg\n\u0026mdash; Jun Ohtani (@johtani) October 22, 2020 写真取り忘れたけど、ProMicroつけた pic.twitter.com/RS4z0lqsUZ\n\u0026mdash; Jun Ohtani (@johtani) October 22, 2020 OLEDもついたと。今日はここまで pic.twitter.com/p6Z8MMP0Xz\n\u0026mdash; Jun Ohtani (@johtani) October 22, 2020 ここまでは順調です。\nOLEDがつかない？ ビルドガイドに従って、この後キースイッチをつけちゃうと問題の切り分けが難しくなるということで、 ここまでの段階でQMK Toolboxを使ってProMicroにファームウェアを書き込んで、それぞれのキーのソケットの取り付け部をピンセットでショートさせつつ、キーが入力されるかどうかを見ていきます。 QMK Toolboxについてはサリチル酸さんのブログがわかりやすいので参考にさせていただきました（わかりやすい記事をありがとうございます）。 で、ビルドガイドにあるように動いてるかを確認しようとしたのですが。。。\nさて、ファームウェア書き込んだけど、OLEDがつかないな。どっかつながってないのか？\n\u0026mdash; Jun Ohtani (@johtani) October 24, 2020 ビルドガイドのようにはいかず。。。 USBでPCとつないだ状態で、QMK Configuratorをサイトで開いて、キーボード入力テストを開くと、ショートさせたキーがPC側で認識されているかのテストができます。 これで、一通りキーは認識できていそうだというのはピンセットでショートさせながら確認しました。 ただ、OLEDには何も表示されないんです。。。\n前回Dozen0を組み立てた時に、ソケットのはんだ付けが甘かったというのもあったので、 OLEDやソケットのはんだを温めなおしたりしてみて、何度か確認してみたものの特に進展がなしです。 （ちなみにうまくいかないのもあって、ぼけたツイートしたりもしてます。）\nまぁ、OLEDはビルドガイドを見てもオプション扱いなので、それよりも触ってみたい衝動に駆られて、 キースイッチをはんだ付けしていきます。\nちなみに昨晩、OLEDはとりあえず置いといてって感じでキースイッチつけてた。キーキャップはまだない pic.twitter.com/SzLmzNg60Y\n\u0026mdash; Jun Ohtani (@johtani) October 26, 2020 それも終わって、問題点の切り分けに何かできないかな？と思ってやったのがOLED単体でArduinoと接続してみて動くかどうかです。 Qiitaにちょうどいい感じの記事を見つけたのでこれまた参考にさせていただきました(4本のジャンパー線を一人で持ちながら確認するの大変だったｗ)。\nはんだでの修正にしっぱい で、自分の中での結論として、「OLEDソケットのはんだ付けが怪しい」となりました。 そこで、まずは外してみようかと思ったのが間違いでした。 はんだごてとはんだ吸い取り線で何とか外せるだろうと思っちゃったんですよ。 OLEDピンソケットは足が4本あって、とりあえずとれるところまではんだ吸い取り線で吸い取ってみましたが、 さすがに基盤の穴に流れ込んだはんだまでは吸い取れず、頑張って温めながらソケットを抜こうとがんばって、 ラジオペンチでピンソケットを引っ張りながら引き抜きました。かろうじて引き抜きはできたのですが、ソケットは足が折れてしまいました。\n作者登場（OLED問題の解決） そんなところにCorneの作者の方がツイートを拾ってくれたみたいで以下のような返信を頂きました。\nOLEDが点かないのはファームのせいかもしれません(最近以前のファームで動かない新しいタイプのOLEDモジュールが出回るようになりました)。お手数ですが、https://t.co/vfSBfIeeJX のブランチのものを試して頂けますか？(ただいまPRレビュー中でまだマージされていない状態です)\n\u0026mdash; c7s (@foostan) October 25, 2020 暗闇に光明とはこのことです。 教えていただいたブランチを手元でビルドしてファームウェアを書き込むと、\nすごい、出ました！右側のディスプレイにロゴが。ありがとうございます（左側のOLEDはソケットのはんだ付け直し失敗したのでもうちょっと先になりますが）！\n\u0026mdash; Jun Ohtani (@johtani) October 26, 2020 なんと、ファームウェア書き込んだ瞬間にOLEDが点くじゃないですか。 感謝感激ってやつです。お礼を言うのに便乗してOLEDの問題の切り分けの方法についても聞いてしまいました。\nOLEDリベンジ 片側は無事だったのですが、もう一方は修復が困難になったので救世主を発注します。 自作キーボードの作成に便利なものリストとして、いくつかのブログに上がっていたのですが、必要ないだろうと見送っていたツールです。\nAmazon | サンハヤト はんだシュッ太郎NEO 45Wタイプ HSK-300 | ハンダゴテパーツ 本当にすごく使いやすかったです。 OLEDのピンソケットが修復不可能だったのですが、ProMicro用に付属して余っているピンヘッダがちょうどいい長さでした。 なので、これを4本分切り取り、OLEDモジュールにつけてしまったOLEDヘッダピンを抜き取って、代わりに切り取ったピンヘッダをつかって、OLEDと基盤を直接はんだ付けすれば修復できそうだと判断しました。\nはんだシュッ太郎君を使ってOLEDについてるヘッダピンをまずは除去。 そのあとはこんな感じで繋げました。\n見にくいかもだけど pic.twitter.com/YAHoxjgppN\n\u0026mdash; Jun Ohtani (@johtani) November 5, 2020 取り外しにくくはなったけど、無事両方のOLEDが点くのも確認できました。やったー。\nヤッター、両方のOLEDがついたよー pic.twitter.com/6KLDWvnaEC\n\u0026mdash; Jun Ohtani (@johtani) October 28, 2020 キースイッチがご機嫌斜め キーキャップは別途、AliExpressで発注をかけたのですが、ここまで来たら待ちきれないですよね？ ということで、手元にあった上海問屋のキーボードのキーキャップが同じMXキースイッチ用のものだったので移植しました。キーキャップ付けてみないとわかならいものですね、1つだけキースイッチがうまくはまっておらず、斜めについているのがこの時点で判明しました（ボトムプレート付けた後だったので、プレート外してから、はんだで修正）。\nちなみにキーキャップはめてる途中で、一箇所キースイッチが斜めにはんだ付けされちゃってるのを発見して慌てて直しました。 pic.twitter.com/qofHp3o4Pc\n\u0026mdash; Jun Ohtani (@johtani) October 30, 2020 無事使えるようになりました。\nアンスコが打てない＆Escどこ？ キーキャップ付けたので仮運用ということで、まずはデフォルトのキーマップをもとにどんな感じで入力できるのかを試してみました。 ここにも罠がｗ ブラウザでQMK Configuratorを開いてデフォルトのキーマップを確認しながら試し打ちをしていたのですが、どうも思ったのと違う動きをしているキーが。\nまずBASEレイヤー（レイヤー0）の右側のシフトと、LOWERレイヤーやRAISEレイヤーのEscです。 入力しているとどうも、右のシフトがEscで、レイヤーを切り替えてもTabのままだなと。 しょうがないので、OLEDが出なくてもいいのでQMK Toolboxでダウンロードしてきたものを利用したら想定通りなのにと。 きちんとqmk_firmwareの構成を理解しないままやってたつけでしたね。 結論としては、OLED用に教えてもらったブランチではキーマップが書き換わっていたようでした。 make crkbd:defautでビルドした時に利用されるkeymap.cがキーマップの定義が書いてあるファイルです。 qmk/qmk_firmwareのリポジトリにあるkeymap.cとfoostanさんにもらったブランチでは差分があったみたいでした。\nおかげで、qmk_firmwareのkeymap.cの仕組みがわかったし結果オーライです。 問題があって調べるとどんな作りになってるかとかちゃんと確認できますしね。 手順通りにやってるだけで問題が起きないと、どんな仕組みになってるのかがわからないので人に聞きまくるしかできなくなっちゃいますしね。\nこれでEsc問題は解決したのですが、アンスコがどうしても入力できません。 自作キーボード以外はすべて日本語配列のキーボードを使用しているのもあり、 日本語配列のキーボードだとどうもキーのマッピングが異なるようだと。\nググって参考にしたのはこの辺でした。\n【QMK】JPキーコードでキーマップを定義する - 天高工房 自作キーボードキット「Corne Cherry」のレビュー - 自作キーボード温泉街の歩き方 そのほかにもVIAのファームなども試したのですが、どれもうまくいかず。 色々ググってみて最終的な解決策はkeymap.cでkeymap_jp.hというファイルが読み込まれていないので、日本語用の設定とかを読み込んでみたつもりがうまく反映されていないという感じでした。\nJISにする場合、keymap_jp.hっていうヘッダファイル読み込んだほうがいいです\n\u0026mdash; Yoshi Yamaguchi (@ymotongpoo) November 3, 2020 今の時点ではこんなキーマップにしてあります。 今後も日本語配列のキーボードをベースに考えていくつもりです。\n#include QMK_KEYBOARD_H #include \u0026#34;keymap_jp.h\u0026#34; const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = { [0] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_TAB, KC_Q, KC_W, KC_E, KC_R, KC_T, KC_Y, KC_U, KC_I, KC_O, KC_P, JP_MINS, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, KC_A, KC_S, KC_D, KC_F, KC_G, KC_H, KC_J, KC_K, KC_L, JP_SCLN, KC_QUOT, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, KC_Z, KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_COMM, KC_DOT, KC_SLSH, KC_RSFT, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, MO(1), KC_SPC, KC_ENT, MO(2), KC_RALT //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [1] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_ESC, KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0, KC_BSPC, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, KC_LEFT, KC_DOWN, KC_UP,KC_RIGHT, XXXXXXX, XXXXXXX, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, _______, KC_SPC, KC_ENT, MO(3), KC_RALT\\ //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [2] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_TAB, JP_EXLM, JP_DQUO, JP_HASH, JP_DLR, JP_PERC, JP_AMPR, JP_QUOT, JP_LPRN, JP_RPRN, JP_CIRC, KC_BSPC, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, JP_MINS, JP_EQL, JP_LBRC, JP_RBRC, JP_YEN, JP_AT, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, JP_UNDS, JP_PLUS, JP_LCBR, JP_RCBR, JP_PIPE, JP_TILD, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, MO(3), KC_SPC, KC_ENT, _______, KC_RALT //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [3] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. RESET, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| RGB_TOG, RGB_HUI, RGB_SAI, RGB_VAI, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| RGB_MOD, RGB_HUD, RGB_SAD, RGB_VAD, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, _______, KC_SPC, KC_ENT, _______, KC_RALT\\ //`--------------------------\u0026#39; `--------------------------\u0026#39; ) }; キーキャップが待ちきれなくて この右下のトンガリがちょっと気になる pic.twitter.com/W0A0z67cns\n\u0026mdash; Jun Ohtani (@johtani) October 30, 2020 キーキャップが待ちきれなくて上海問屋のキーキャップを付けてみて、いろいろ試行錯誤してみました。\nあー。上下関係ないのか。だからみんなこんな感じにしてるのか？ pic.twitter.com/KTBlPLespr\n\u0026mdash; Jun Ohtani (@johtani) October 30, 2020 どのくらい離すのが良いか実験中 pic.twitter.com/ozK4WyBXY8\n\u0026mdash; Jun Ohtani (@johtani) November 2, 2020 キーキャップもいろいろあるのね 届いた。 pic.twitter.com/jccNW1ZcEM\n\u0026mdash; Jun Ohtani (@johtani) November 2, 2020 もう一個 pic.twitter.com/9y6qat4JiN\n\u0026mdash; Jun Ohtani (@johtani) November 2, 2020 とりあえずセミコロンの位置につけてみた。 pic.twitter.com/TDk5213IHi\n\u0026mdash; Jun Ohtani (@johtani) November 3, 2020 今はこのDSAプロファイルの青いグラデーションのキーキャップを使っています（Dukeはここにはいないですｗ）。 キーキャップのプロファイルはこれまた、サリチル酸さんのブログがわかりやすく書かれています（ほんとすごいなぁ。）。\n高さ調節 そのまま使っていたのですが、やはりもうちょっと奥側に高さがほしいなと。 ダイソーなどで打っているケーブルクリップがお試しには良さそうだったのでこんな感じで内側がちょっとだけ高くなるような感じにして使っています。\nこうなった。とりあえず仮運用 pic.twitter.com/VkhjawdhLM\n\u0026mdash; Jun Ohtani (@johtani) November 4, 2020 まとめ ということで、駆け足ですがCorne Light v2のビルドログでした。 いきなりフルキーボードから40％キーボードかつ異なる並びにしたので、 混乱しっぱなしですが、いい頭の運動になっているし、なにより作って動かすまでの間に いろいろと調べたり試行錯誤できたのがすごく楽しかったです。\nあとは、スプリット型＋Column Staggeredになったので「c」や「b」を間違えまくっていますが、 いい気付きでした。まだまだ記号とかの入力に慣れていないですが、ちょっとずつ身に着けていけたらなと。\nただ、もう次のキーボードをDIYしたい気持ちも出てきているので困っているところです。\n書ききれてないこともあるかと思うので、ここはどうしてるの？これはどうやったの？などあれば、Tweetなりコメントなりを頂けたらなと思います。いやぁ、DIYキーボード楽しいわ。\n","date":1604503527,"dir":"post/2020/","id":"b16bddd1a6d3e5f4136446bebe7ffbc7","lang":"ja","lastmod":1604503527,"permalink":"https://blog.johtani.info/blog/2020/11/05/build-corne-light-v2/","publishdate":"2020-11-05T00:25:27+09:00","summary":"前回のブログのまとめに書いたように、セパレートタイプのキーボードであるCorne Light v2を作成したのでそのビルドログです。DIYキーボードとし","tags":["DIYキーボード","misc"],"title":"Corne Light v2を作成した #DIYキーボード"},{"contents":"ヒゲが不評だったのでいつも通りの長さに切りました。\n前回「Windowsをお試し中」と書きましたが、いくつかソフトをインストールしたりしたので現状を忘れないようにブログに残しておきます（また同じ作業する予定なので）\nインストールしたものたち 今のところインストールしたのはこの辺。 特にコメントしたいものについてこのあと明記します。\nドライバインストール from CD MX Ergoのソフトインストール。接続はコネクター Windowsアップデート Chrome Visual Studio ビルドツール(Lindera用) JetBrains Toolbox IntelliJ CLion Rider Visual Studio Code Slack Teams Google Drive共有 Gitter Divvy for Windows Zoom DeepL Sophos Twitter for Windows Office 365 AutoHotKey WSL2 - Ubuntu Windows Terminal Rustup Git for Windows wsl-ssh-agent PeaZip Speccy Hugo (WSL2のUbuntuにapt-get install hugoした) PowerToys AutoHotKey 前回のブログに書いたように、カーソル系のEmacsショートカットが体に染みついて離れないのです。 そこで、ググって見つけた記事はこちら。 AutoHotKeyというツールが Windowsに常駐して、特定のキー入力の時に、別の操作を実行してくれるツールです。\n見つけた記事にあった、https://github.com/lintaro-jp/gtk-emacs-theme-like.ahkのキーマップをもとに、いくつか変更したものを使用させていただいています。\n書き換えたのは、以下の通りです。\nCtrl+\\でIMEの切り替え（Wnn風） Ctrl+kをEmacsと同じ挙動に（もとにしたキーマップでは、カーソルから行末までが削除されてしまう） Win+sでもファイル保存（Ctrl+sと同じ挙動に。デフォルトではCortanaが起動して邪魔くさいので） すごく快適です。そのうち、もう少し自分が使いやすいようにキーマップを追加していったりするかもしれません。 特に、Macのショートカットがしみついているものについてなどです（仮想デスクトップ切り替えとか？）\nPowerToys Divvyをインストールしたのですが、グローバルショートカットがうまく動かなくていまいちでした（なんでだろ？） そこでググって見つけたのが@ITのPowerToysの記事でした。 PowerToysはMS製のOSSツールで、GitHub上で公開されています。 中には「ColorPicker」、「FancyZones」、「File Explowrer Add-ons」など、複数のツールが入っています。 「FancyZones」です。\nWindowsでは、デフォルトで、アプリにフォーカスしているときにWin＋カーソルでウィンドウの配置場所をいくつか（左右どちらかに半分、4分の1(右上、左上など)）に配置してくれるAero Snapというものが動いています。が、上半分などデフォルトにない柔軟な配置を設定することができません。 MacではDivvyというツールをいれて、それを実施していたのですが、先ほど書いたようにWindows版はあるものの、なぜかグローバルショートカットが動かず、システムタスクトレイのアイコンをクリックしなければいけませんでした。\nそれを解消してくれるのがFancyZonesです。 FancyZonesの設定項目で、自分で画面上にどのような割り当て領域を作るかを設定できます。さらに、マルチディスプレイ、仮想デスクトップを使っている場合、それぞれのディスプレイかつ仮想デスクトップで個別にレイアウトが設定できるようになります。 レイアウトを設定した後は、Shiftキーを押しながらウィンドウを移動すると、設定した領域が出てきて、あとは、割り当てたい領域にウィンドウを移動するだけでその領域いっぱいにウィンドウをリサイズしてくれます。 また、設定を変えることで、Shiftキーを押さなくてもウィンドウ移動するだけで領域にリサイズすることも可能です。また、Aero Snapの機能をオーバーライドしてWin＋カーソルで動作させることも可能になります。\nWSL2 + Windows Terminal 三宅さんからコメントを頂いたので。\nもう少し幅広い感じですかね。あわせて Windows Terminal 使うとわりと快適です。\n\u0026mdash; miyake | ZEN (@kazuyukimiyake) October 15, 2020 なんとなく噂は聞いていましたがということで、MSのドキュメントを見ながらインストールしました。クイックスタートに則って作業するだけで特に問題なくUbuntuまで無事インストールできました。 Windows Terminalも同様です（クイックスタートで入れることになる）。\nGit for Windows + wsl-ssh-agent 少してこずったのがこちらです。 チュートリアルに記述はあったのですが、どちらで作業するのか？などが少しわかりにくかったので。ググって出てきた記事をもとに作用しました。\nRustのプロジェクトファイルをMacから丸ごとコピーしていたのですが、Git for Windowsを入れるまでは、CLion+Rust pluginの環境では、.gitファイルをきちんと認識してくれませんでした（この時WSL2と少し混同してた）。\n無事環境は用意できました。 作業の手順は以下のような感じです。 Macで使用していた.sshのディレクトリを持ってきて作業しました。\nWindows側での作業 Macから.sshディレクトリをc:\\\\Users\\johta\\にコピー Git for Windowsのインストール OpenSSHクライアントの設定 管理者権限でコマンドプロンプトを起動して sc config ssh-agent start=auto sc start ssh-agent [wsl-ssh-agent(https://github.com/rupor-github/wsl-ssh-agent)のインストール ダウンロードして.7zファイルを展開 wsl-ssh-agent-gui.exeとnpiperelay.exeをc:\\\\Users\\johta\\binに移動 c:\\\\Users\\johta\\bin\\wsl-ssh-agent-gui.exeのショートカットをスタートアップに作成 作成したスタートアップのリンク先に -setenv -envname=WSL_AUTH_SOCKを追加 Git BashでOpenSSHを利用するように設定 setx GIT_SSH C:\\\\Windows\\system32\\OpenSSH\\ssh.exe ssh-addで秘密鍵を登録 ssh-add .ssh/id_rsa WSL2のUbuntuでの作業 Ubuntuはgitがすでに入っていたのでインストールはスキップ git config --global user.name \u0026quot;Jun Ohtani\u0026quot; git config --global user.email \u0026quot;メールアドレス\u0026quot; mkdir .ssh .bashrcの最後行にwsl-ssh-agentのWSL2 compatibilityにあるexportからfiまでをコピー。この時、パスを自分のパスに変更すること(私の場合$HOME/winhome/.wslの部分を/mnt/c/Users/johta/binに書き換えました) これで、WSL2側では.sshのファイルを管理しなくても、Windows側のOpenSSHに接続してssh周りの処理をしてくれるようになりました。\nPeaZip wsl-ssh-agentが.7z形式で圧縮されていたので、ダウンロードしました。 とりあえずこれを入れてみたのですが、ほかにお勧めがあれば教えてほしいです。\nSpeccy CPUの温度やスレッドごとのCPU使用率などを見てみたいので入れてみました。 これもとりあえず入れてみた感じなので、ほかにお勧めのソフトがあれば教えてもらえればと。 リソースマネージャーでもスレッドごとのCPU使用率は見れたのですが、温度が見れなかったので。\nHugo + WSL2にあるUbuntuにsudo apt-get install hugoしてインストールしました。\nそこで、VS Code の Remote Extension です。WSL2 から ‘code’ で起動できます😎\n\u0026mdash; Daiyu Hatakeyama@Microsoft, Hack in ChatGPT (@dahatake) October 17, 2020 あとは、畠山さんに教えてもらったVSCodeのRemote - WSLを入れて、 WLSに接続した状態でVSCodeを起動して記事のMarkdownを書くと、VSCodeのターミナルを開くとWSL2に接続してくれて、hugoコマンドが実行できます。\nまとめ とりあえず、ブログが書ける環境ができました。 Mac上にあった各種プロジェクトのディレクトリをコピーして、Rustの開発もできるようになりました。\n今後も環境構築は続いていきます。Javaとか入ってないし。 SDKMan使ってたけど、切り替えどうしよう？とか。\nそういえばSDKMAN!をJDK切替に使ってたけど、結局windows側のパスは通らんので自力インストールになった。scoopがよさげ\n\u0026mdash; きしだൠ(K1S) (@kis) October 17, 2020 IDE系から呼び出すターミナルはWSL2がいいなぁとか。\nhttps://t.co/X4Jj4tih1I\n\u0026mdash; そーだい@初代ALF (@soudai1025) October 17, 2020 ほかにもおすすめなどがあれば教えてください！\n","date":1603029710,"dir":"post/2020/","id":"188c1ee5132a6752dfce5a0235354070","lang":"ja","lastmod":1603029710,"permalink":"https://blog.johtani.info/blog/2020/10/18/restart-windows-no1/","publishdate":"2020-10-18T23:01:50+09:00","summary":"ヒゲが不評だったのでいつも通りの長さに切りました。 前回「Windowsをお試し中」と書きましたが、いくつかソフトをインストールしたりしたので","tags":["misc","windows"],"title":"Windowsへの移行（その１）"},{"contents":"ヒゲが伸びてきて(試しに伸ばしてる)不評を買っている今日このごろです。\n自宅で作業することが多くなってきたので、自作PCでもと思っていますが、OSをどうしようか悩み中。 とりあえず、試しにWindowsにしてみるかということで、10年ぶりくらいにWindowsに帰ってきました (この文章はMacで入力してますが)。\nむかしむかし もともとはWindowsを使っていたのですが、Win7くらいに32bitと64bit混在の時期に、 Xkeymacsを利用するときに少し手間がかかるなぁと思ったのもあり、Macに移行しました。 Macだと自分がよく使うEmacsっぽいショートカットがデフォルトいろんなアプリで使用できる利点があったからです。\nただ、最近、TL上で光るPCとかを見てしまったのもあり、 自作PC(どちらかというとDIYかな?)熱が復活しました。 まだ、OSをWindows、Ubuntuのどちらをメインにしようかな?と悩んでいるところではありますが、まずはWndowsをちょっと試してみるかなと。\nまずは、やりたいことをちょっとリストアップしておこうかなと思います(きっと、先人の知見が集まってくるはず!)。\nどうしてもほしい機能 大学の頃にSunOSやSolarisを使用し、Emacsでメールを読んだしていたせいで、Emacsのショートカット操作が体から抜けない状態です(抜こうとしてないという話もあるが)。 ですので、社会人になってからWindowsを利用していたときはXkeymacsというソフトのお世話になっていました(神アプリでした。まだあるのかな?)。\nショートカット操作とか カーソル移動(必須) 上下左右：Ctrl+n、p、f、b 行頭、行末：Ctrl+a、e 編集 デリートキー：Ctrl+d Ctrl+hがバックスペースだけど使わないな、そういえば カーソルから行末までをカット：Ctrl+k 必須! カーソル移動がホームポジションから移動しなくてもいいのもあって、多用してしまっています。 これ、WindowsとかUbuntuでいい感じにできるのあるのかな? できれば、IMEやブラウザのURLのサジェストなどもこのカーソル移動で移動できると嬉しいです。 (昔はM-%とかで置換などもやってたけど最近はやらないな。)\nデスクトップ操作系 仮想デスクトップ やることごとにデスクトップを切り替えて使うので ウィンドウのリサイズ? DivvyというアプリをmacOSで利用中 自分で登録したサイズ(例：画面右半分)にウィンドウサイズを変更などがショートカットで可能 仮想デスクトップはあると思うけど、ウィンドウのリサイズの便利なツールあるかなぁ?\n利用するアプリ SNS、オンラインミーティング Twitter macOSではTweetDeckと夜フクロウを使用 Slack ネイティブアプリ Gitter ネイティブアプリ Chatwork ブラウザ Teams ネイティブアプリ Zoom ネイティブアプリ Google Meet ブラウザ Discord ネイティブアプリ(最近使ってないな) 色々使ってますが、最悪ブラウザで使う感じかな?\nオンラインストレージ Google Drive 同期アプリ使ってる Dropbox あんまり使ってない 開発系 JetBrainsのIDE Toolbox App IntelliJ CLion + Rust plugin Rider zsh macOSで標準になったから コマンド系 git SDKman ant gradle JDK Rust Hugo Jasper GitHubのIssueとかを見るネイティブアプリ 自分が関連しているIssueとかが楽に見える(メールだと埋もれてしまう) エディタ Visual Studio Code 開発系では?と思われるかもだけど、Markdownエディタとして使ってる Emacs by Homebrew 最近は起動してない その他 カレンダー macOSのカレンダーで複数のGoogleカレンダーを取り込んでる ScanSnap Ubuntuで使えるやつあるのかな? Mac miniにつないであるので、画面共有とかで入れればそれでOK 画面共有 winやubuntuからMac miniとか見えるかな? キーボード共有 macも使うので、KVMスイッチとかかな? マウス共有 MX ErgoのFlowを使うと行き来が簡単にできたので良さそう。 ただし、Ubuntuだとどうなるのか? システム監視系 CPUの温度とかCPU、メモリの使用率とか まとめ とりあえずこんなところです。カーソル移動系が一番重要なので、そのへんから色々とちょっとずつ試していく予定。 ぜひオススメアプリとかあれば教えていただければと。\n","date":1602727442,"dir":"post/2020/","id":"de37d9fae011687eb1eb5a127fcb89e3","lang":"ja","lastmod":1602727442,"permalink":"https://blog.johtani.info/blog/2020/10/15/restart-windows/","publishdate":"2020-10-15T11:04:02+09:00","summary":"ヒゲが伸びてきて(試しに伸ばしてる)不評を買っている今日このごろです。 自宅で作業することが多くなってきたので、自作PCでもと思っていますが、","tags":["misc","windows"],"title":"Windowsをお試し中"},{"contents":"今年の春くらいから、セパレートタイプのキーボードが気になっています。 また、なんか知らないですが、Twitterのタイムラインが自作キーボード(DIYキーボード)で盛り上がってる気がします。 (たぶん、気になってるから余計目についてる)。 これとか。このスライドから、自分がやってるのは「まだ」DIYキーボードだなということで、タイトルに使ってみました。\n#toruby \u0026quot;DIYキーボードは実質Ruby\u0026quot; 本日のスライドです! とちぎでこの話をできてよかった!!!q: https://t.co/RJot71Ngu9\n\u0026mdash; Kakutani Shintaro (@kakutani) September 12, 2020 セパレートタイプのキーボード 今年の夏まではMac Book Pro 16インチのキーボードを利用していました(参考:自宅の作業環境(2020))。 これまで、自宅で作業することよりも、外で仕事をすることが多く、また、外といっても様々な場所(サムライズムだったり、オフィスだったり、カフェだったり)で作業をすることが多かったので、ノートPCのキーボードにしていました。流石にキーボードを持って歩くほどは気にしていなかったので。\nただ、コロナウイルスの影響もあり、ほぼ自宅で作業することとなりました。 となると、前から気になっていたセパレートタイプのキーボードが俄然気になり始めます。 (といいつつ、寄り道してたりしますが)\n気になっていたのはこのあたりなのですが、\nErgodox EZ Moonlander Mark I 流石にいきなり行くにはちょっと気が引けるなぁと(なかなかいいお値段)。 また、自分が日本語キーボードを利用しているというのもちょっとあります。\nキースイッチの感触を知りたくて ただ、日々、楽しそうな自作キーボードの記事や画像が流れてきます。 で、思い出したのが自分の趣味。プラモデルです。色を塗ったりはしないですが、組み立てるのは楽しいなと。 じゃあ、趣味と実益を兼ねればいいのでは?(ほんとか?)となり、作る気になってきました。\nただ、全く知らない世界だし、どんなものなんだろう?と。 市販のキーボードでも、キーの押し具合が色々合ったり、形もまちまちです。 また、このご時世ですので、自宅からあまり出ていないので遊舎工房さんなどに遊びにも行けず。\nそんなところに流れてきたのがキースイッチのテスターでした(世の中誘惑だらけ)。\nスイッチテスター人気スイッチ詰め合わせ 18個セット 「なるほど、これでどんな感触かわかるじゃないか!」と、気づけばポチッと押していました。。。 届いて、「ふむふむ、これがこういう感触なのか。なるほど」ポチポチ押しながら、さらに自作キーボードについて調べていきます。\nいろんな感触なんだなぁ pic.twitter.com/PaGDMIRJiv\n\u0026mdash; Jun Ohtani (@johtani) September 22, 2020 キースイッチのストロークの深さを知りたくて まぁ、当たり前なのですが、先程のキースイッチテスターどこにもつながっていません。 キーボード触ってるとわかりますが、ストロークが違いがあるんですよ。 ただ、これだとわからない。けど知りたい。\nで、ググっているとArduinoを使ってLチカやってる人とか、キー入力させている人がいるじゃないですか。 これでは?そういえば、Arduinoもどきうちにもあるぞ?と。 で、準備をしていたときに見かけてしまったのがこのツイートでした。。。\nhttps://t.co/ALl7OcRVRa 高機能テスターとしてもおすすめ\n\u0026mdash; Kakutani Shintaro (@kakutani) October 4, 2020 やられてしまいました。。。\ndozen0作りました ということで、前置き長かったですが、Dozen0というキーボード(マクロパッド?)を遊舎工房さんから購入して作ってみました。 手順はビルドガイドという形でまとまっています。\n基本的にはこれに沿って作成しました。\nパーツと手順の確認 さてと。 pic.twitter.com/GTBJ7zDleN\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 まずは入っているパーツがきちんとあるか確認します。 また、ビルドガイドでどんな作業があるのかをざっと眺めておきます。 まぁ、プラモデルといっしょですよね。\nキットにはキースイッチとキーキャップは含まれていません。これはご注意ください。 私は、キースイッチテスターとして入手していたキースイッチとキーキャップがどんな押し具合なのかを確認したかったので特に問題ありません。\nハンダづけ Amazon | 白光 ダイヤル式温度制御はんだこて FX600 | ハンダゴテ Amazon | 白光 こて先 2C型 T18-C2 | ハンダゴテパーツ Amazon | 白光(HAKKO) セラミックヒーターはんだこて専用こて台 クリーニングスポンジ付き FH300-81 | ハンダゴテパーツ Amazon | goot(グット) 高密度集積基板用 鉛入りはんだ Φ0.6mm スズ60%/鉛40% ヤニ入り SD-60 | ハンダゴテ はんだ付け用に揃えた道具です。「自作キーボード ハンダゴテ」とかでググると出てきたものがこれだったので。 デフォルトのコテ先ではなく、2Cのコテ先に付け替えてから作業を開始しました。\n私の持っていたソケットはCherry MX系なのですが、気が向いたらKailh Chocも試したくなるかも?ということで、 すべてはんだ付けしました。本格的にはんだ付けしたのは大学以来だからもう20年近く経ってますね。 ソケットの足をプリント基板にはんだ付けするのですが、2Cのコテ先が大きくなかなか手こずりました(これがこのあと問題を引き起こしました)。\nソケット、リセットスイッチ、ProMicroをはんだ付けすればはんだの作業は終了です。\npic.twitter.com/jjUo162n54\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 pic.twitter.com/p5atvtHfFN\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 スイッチの取付と組みたて 試したいキースイッチを選んでトッププレートにつけていきます。\nキーテスターからスイッチとキーキャップ持ってきて完成。動作確認はまだなのでまた、最初に戻るかもだけど、、、 pic.twitter.com/ZmBd3bgOKI\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 組み立ても終わり次は実際の動作確認です(ツイートしていますが、予想通りの展開でした)。\nファームウェアの書き込み USBで接続して、ファームウェアの書き込みです。 書き込み手順はビルドガイドにありますが、QMK Toolboxの使い方やQMK Configuratorの使い方は以下のサリチル酸さんのブログがわかりやすかったです。\n（初心者編）自作キーボードにファームウェアを書き込む （初心者編）QMK Configuratorを使ってキーマップを書き換えよう 実際に書き込んで動かしてみると。。。。\nうーん、上半分が死んでる気がするなぁ。\nデフォルトキーマップの書き込みはできたけど、カーソルの上とかバックスペースが入らないw\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 とりあえず、もう一回確認してみた。デフォルトのキーマップで、「Cut」「Paste」が強く押さないと入力されない。UpとDeleteは動くようになってた。CopyとBkSpがうんともすんとも言わない。下段のキーは全部動く。https://t.co/zEyINdAK6t\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 といった具合に上半分が動作があやしいです。\n再度、はんだ付け ということで、ネジを外して上の段のソケットをはんだで温めてみると、片側だけ温めるとはずれるじゃないですか。 どうやら、うまくソケットの足が基盤にはんだ付けできていなかったようです。 この時、最初に作業したときに2C型のコテ先が大きくて、ソケットの足に入らなかったのを思い出したので、 最初にはんだごてについていたコテ先に戻してから作業をしました。 これだとソケットの足の隙間に入るんです。ということで、挙動のおかしい上段のソケットをすべてつけ直したところ無事動作しました。\n上の段、全体的にソケットがうまくはんだ付けできてなかったみたいだった。今回はMX系のスイッチしかないので、Kailh Chocのソケットの導通は未確認。ざっとブログにまとめるか。\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 現在のキーマップ これが今のキーマップです。仕事中のBGMをラズパイ4の音楽プレーヤーで流していますが、 部屋から出るときや、打ち合わせがあるときに音楽の停止、開始などを画面共有経由でやっています。 が、わざわざマウス移動するのもめんどくさいなと。これに使えそうだというのもあったので、Dozen0を購入したというのがあります。 残念ながら、Prev Trackとかがうまく動かないので、ショートカットを調べてキーマップ書き換える予定ですが、非常に便利になりました。\nまとめ ということで、Dozen0を作ってみましたが、楽しかったです。すんなりと行かなかったのがまた良かったです。 試行錯誤して動いたときの喜びが何倍もありました。また、キースイッチの感触も知ることができました。 たぶんGateron Silentクリア軸もしくは赤軸くらいが良さそうだなぁと(こうやって沼へ。。。)。 キーマップの仕組みを調べたり、もっと面白い使い方できないかな?と探りつつ、次のステップに進もうかなと。\n次は本格的なセパレートタイプのキーボードを作る予定です。が、お店のオープンを待ってからということになってます。はやくオープンしないかなぁ!!\nがんばって!!\n\u0026mdash; Jun Ohtani (@johtani) September 29, 2020 ","date":1602428006,"dir":"post/2020/","id":"c377351433a941a927aab543931f6026","lang":"ja","lastmod":1602428006,"permalink":"https://blog.johtani.info/blog/2020/10/11/build-dozen0/","publishdate":"2020-10-11T23:53:26+09:00","summary":"今年の春くらいから、セパレートタイプのキーボードが気になっています。 また、なんか知らないですが、Twitterのタイムラインが自作キーボード","tags":["DIYキーボード","misc"],"title":"Dozen0を作成した #DIYキーボード"},{"contents":" 2020/10/06 11:00くらいにマージされました。\n@minoru_osuka さんが開発を引き継いだLinderaというKuromojiのRustクローンがあります(リポジトリ) 。 最近趣味でRustを勉強しているので、こちらを少し手伝っています。\nRustの勉強仲間である@takuya_bさんや@ikawahaさんと話をしているときに、FST部分をDouble Array Trieに置き換えると速度が向上するのでは?という話が出まして、@takuya_bさんがDouble Array Trieを作るらしいという話になったので、下準備などをしつつ、作ってもらったライブラリyadaを組み込んでみたという話です。\nベンチマークの追加 下準備として、今のLindera(FST実装)がどのくらいの性能なのか?というのを計っておく必要があります。 幸いにも、Linderaのオリジナルの開発者の方が、criterion.rsというライブラリを使ったベンチマークプログラムを作成してくれていました。\nただ、1種類だけだと少し心もとないなというのと、長い文章やパターンを増やしたほうが良さそうだなということで、 ベンチマーク自体をいくつか追加しました(追加したときのPR)。\n種類としては、5種類のベンチマークです。\nシステム辞書のみのTokenizerのコンストラクタ呼び出し カスタム辞書ありのTokenizerのコンストラクタ呼び出し システム辞書のみのTokenizerのtokenize処理の呼び出し カスタム辞書ありのTokenizerのtokenize処理の呼び出し 青空文庫の坊っちゃんのテキストをシステム辞書のみのTokenizerでtokenize 1,2はコンストラクタ部分だけの処理をベンチマークテストする目的で作成しました。 LinderaはTokenizerがtokenize処理するのに利用するデータをいくつか内部で保持しています。 これらはファイルにシリアライズされており、Tokenizerのオブジェクト生成時に読み込みやデシリアライズ処理が発生します。 この部分だけも速度を計測したい目的でコンストラクタだけを切り出しました。\n3,4はTokenizerのメインの処理です。コンストラクタはベンチマークの対象外にしました。 純粋にtokenizeの処理だけを切り出して計測するためです。 カスタム辞書がある場合、ない場合は念の為切り出した形になっています。\n5は長い文章(文章が多いのでバリエーションも増える)を扱いたいために別にしました。\nこれで、一応下準備が完了です。 ちなみに、Criterionは賢くて、前のベンチマークの結果と最新の結果を比較してくれる機能があります。 どんな感じで出てくるかはベンチマーク結果をご覧ください。\nyadaの組み込み ベンチマークの準備をしていたところyadaがリリースされたので、Linderaへの組み込みを検討し始めました。\nというわけで、またダブル配列を書いてしまったので crate として公開しました。フィードバックお待ちしております！ https://t.co/As7h0tfmjf\n\u0026mdash; takuya-a (@takuya_b) September 20, 2020 中身の理解 lindera-fstを利用して、prefix searchしている処理があるので、そこで利用しているFSTをyadaに置き換えれば良さそうだと判断して、 処理を読んでいきます。\nTokenizerは、PrefixDictという構造体でlindera-fstを利用している prefixメソッドが入力文字列を元に、FSTを前方一致検索して、ヒットした単語の情報をIteratorとして取り出せる(単語の情報は「入力文字列の先頭からの文字数」と「ヒットした単語のWordEntry構造体」) PrefixDictのfstは辞書(例：ipadic)ごとにlindera-\u0026lt;辞書名\u0026gt;-builderで生成される システム辞書としては、デフォルトではlindera-ipadic-builderでfstを構築している 構築処理はこの辺 という感じです。 また、辞書周りのファイルがそれぞれどんな役割なのか、どんなデータの持ち方をしているのか?といった点を、変更点の調査のついでに書き出してみました。lindera-dictionary/FILES.md。TODOになっている部分も追記が終わっています(PR)\n変更点 実際に変更したプログラムの詳細についてはのPRを見ていただくとして、簡単には以下の点になります。\nRustのバージョンを1.46.0に(おもにREADME.md) yadaが利用している機能に1.46.0で導入された機能があるため lindera-fstをyadaに変更(lindera-core/Cargo.toml, lindera-ipadic-builder/Cargo.toml) 合わせて、dict.fstというファイル名をdict.daに変更 dict.daに関して構築部分と検索部分を変更 FSTではFSTから返ってくる値(入力文字列に出てきた単語に関連する値)はu64だったが、yadaのDoubleArrayがu32しか扱えないため、u32に変更。テストの記述はしていないが、扱うデータ的にu32で問題なさそうだったので。 検索部分：PrefixDict構造体のprefixメソッドでDoubleArrayのprefix_common_searchを使用 DoubleArray自体がprefix_common_searchのメソッドを持っていたので、処理が簡単に置き換え可能だった。FSTはprefixメソッド内で独自で前方一致検索を実装していた。 構築部分：lindera-ipadic-builder/src/lib.rsのbuild_dictとbuild_user_dictのdict.da構築処理 ipadicのCSVファイルを読み込んで、見出し語をキーに、辞書にある単語情報のベクタを値とするBTreeMapを生成し、このBTreeMapに基づいてFSTを構築していた部分をDoubleArray構築処理に置き換えた。 シフト演算などで、実際の値(dict.vals)へのポインタを作っていたのだが、ここの処理を読み解くためにFILES.mdを書き出した。 という感じです。そもそもデータ構造がどうなっているのか?から読み解いて、変更部分を洗い出して変更していった形になります。 取り込み作業中にいくつかyadaに要望(このへん)を上げて、変更を取り込んでもらい、最終的にyadaのバージョン0.3.2で問題なく動きそうだという形になりました。@takuya_bさん、対応ありがとうございました。\nエッジケースバグの発見 作っててよかった、テストケースでした(実際にはベンチマークテストですが)。 取り込み作業中に、Lindera本体のcargo testはすべてOKになるが、ベンチマークを取ろうとしたときに、坊っちゃんの文字列を入力にしたベンチマークが失敗するという事象が発生しました(PRのコメント参照)。 切り分けのために、入力の文章のどこでおかしくなるのか?DoubleArrayのbuildメソッドに渡している値がおかしくないか?などをすこしずつ調べていくと次のバグが判明したという感じです。\n特定のデータ(ipadicの見出し語一覧)をDoubleArrayに入れて、特定の文字列(「は相」)をcommon_prefix_searchにいれたら、 返ってくる情報(0から何バイト目の文字が一覧に存在した)が、不正な値が返ってくるというバグでした。 @takuya_bさんに見てもらいつつ(DoubleArrayの中身わからん。。。)、修正してもらいました。素早い対応ありがとうございます。\nyada 0.3.1 をリリースしています。特定の条件で不正な遷移を許すダブル配列が構築されてしまうバグを修正しています。このエッジケースは @johtani さんが見つけてくださいました。ありがとうございました！ https://t.co/CiftZi5GDn\n\u0026mdash; takuya-a (@takuya_b) September 30, 2020 やはり、いろんな文字列入れてテストしてみるの重要ですね。 ということで、ベンチマークだけでなく、テストケースとしても坊っちゃんのファイルを読み込んでトークナイズするようにPRでテストケースを追加しています。\nベンチマーク結果 yadaを利用した変更が終わったので、再度cargo benchを実行して計測です。 計測としては、masterブランチでまずcargo benchを実行し、yadaの実装をしたブランチに切り替えてからcargo benchを実行します。 すると、Criterion? cargo benchが、最終的な結果に前回との差分でどのくらい性能が改善、改悪したかも合わせて出力してくれます。 実行環境と結果は以下のとおりです。\nMacBook Pro 16インチ CPU：Core i7 6コア 2.6GHz メモリ：32GB コンストラクタのベンチマークについては10%ほど性能が悪くなっています。 これは、FSTよりもDoubleArrayTrieのほうがデータが大きくなってしまうためだと思われます。 実際にファイルのサイズは次のようになりました。yada(DoubleArrayTrie)のほうが2倍以上大きいことがわかります。 また、このファイル以外にもLinderaが利用しているデータはありますが、それらは今回変更の対象にはなっていません。 なので、単純にこのファイルの読み込みの処理に時間がかかっているのだと想像できます。\n2147765 / FST / dict.fst 5425152 / yada / dict.da tokenizeのベンチマークについては、11%〜28%の改善が見られました。 文章から、内部に保持している辞書に存在する単語を見つけ出す処理に利用されるのがFST、DoubleArrayTrieです。 今回の変更では、この処理に利用しているデータ構造だけを変更しました。 実際には\nDoubleArrayTrieを用いた単語の検索処理 見つかった単語の持つ値(data.valsのオフセット情報)を元にシフト演算 といった処理が実行されます。シフト演算はu64だったものがu32に変更されたくらいなので、大した処理量ではないかと。 大部分はDoubleArrayTrieを利用したルックアップ処理が速度向上に寄与していると思います。\nまとめ 最近Linderaに加えた変更、作ったPRについて少しブログにまとめてみました。 ちなみに、まだPRの段階でレビュー\u0026amp;リリース待ちという感じです。\n実際には作ってもらったライブラリを組み込んでみたというだけなのですが、速度が向上した結果が見れたのは面白いです。 また、基本的なデータ構造とかアルゴリズムの勉強にもなりました(2次元配列を1次元配列に押し込むとか)。このへんも今後も勉強していきたいです。\n組み込む際に色々と協力していただいた@takuya_bさん、@ikawahaさん、巻き込んでくれた@minoru_osukaさんに改めて感謝いたします。\nRustや形態素解析のプログラムの勉強を兼ねて、今後もなにか改善できる部分がないかなどを見ていこうと思っています。 Rustで形態素解析をしたいという人がどのくらいいるかはわかりませんが、おかしなところや疑問点などあればコメントください。\n","date":1601865378,"dir":"post/2020/","id":"15932a656f7acfac897d27766eadc9e2","lang":"ja","lastmod":1601865378,"permalink":"https://blog.johtani.info/blog/2020/10/05/switch-fst-2-da/","publishdate":"2020-10-05T11:36:18+09:00","summary":"2020/10/06 11:00くらいにマージされました。 @minoru_osuka さんが開発を引き継いだLinderaというKuromojiのRustクローンがあります(リポジトリ)","tags":["Rust","Lindera"],"title":"LinderaのFSTをDoubleArrayTrieに変更した話"},{"contents":"先日は「検索システムを構成するパーツ」ということで検索システムを構成しているパーツについて書いてみました。\n大体、検索がうまくヒットしないといった場合に、問題になるのがコンテンツ自体のデータもしくは、転置インデックスのキーワードだったりします。 そこで今回は、前回のパーツの「データソース・コンテンツ」周りについて少し書いてみようと思います。言葉の定義、それぞれがどんなことをやるのか、とりあえず導入したあとにコンテンツ周りでどんな改善ができるかなどを書いてみます。\n言葉の定義 コンテンツ 実際に検索させたいデータになります。 コンテンツにはWebページ、データベースのレコード(CMSで登録されたデータなど)、ファイルサーバーにある文書(PDF、Word、Excelなど)などになります。\nデータソース コンテンツのマスタデータが保存されている先です。 よくあるデータソースとしては以下のものが考えられます。\nWebサイト - 自社もしくはインターネットに存在しているWebサイトです。 ファイルサーバー - ローカルネットワーク上のファイルサーバーもありますが、最近ではGoogle DriveやDropboxといった外部のWebサービスもあります。 RDB - CMSや自社システムでのデータの保存先です。 クローラー コンテンツをデータソースから収集してくるプログラムのことです。 Webサイトやファイルサーバーからコンテンツを収集して検索エンジンに登録するところまでを担当します。 RDBにあるデータを検索エンジンに登録する場合はクローラーがデータを登録するというよりは、RDBにデータを登録するシステムが検索エンジンに登録する機能を持っていることが多いです。\nデータの収集と登録 収集 クローラーを使用した収集の場合は、サービスの特性とデータソースによって、どの程度の頻度でクロールするのか、クロール対象はどこまでか?といったものを決める必要が出てきます。 これらが決まれば収集ができるかと(他に権限とかもありますが。)。 収集コンテンツは、そのままでは利用しにくかったり、利用できないことがあるので、次はデータの変換を行います。\nデータ変換 コンテンツはそのままの形では検索エンジンには扱いにくいデータ形式である場合があります。\nWebページの場合 Webページの場合、コンテンツにはHTMLタグが入っていたり、JavaScriptなど検索対象にはしたくないデータなどが入っています。これらを除去して、検索させたいものを取り出す必要があります。 また、Titleタグなど、いくつかメタデータとして扱えるものがHTMLで規定されているので、これらを別の項目として取り出して個別に検索できるようにすると便利です。 HTMLをパースしてデータを抜き出す処理ができるライブラリなどがあるので活用します。\nファイル PDFファイルなど、ファイルの場合もメタデータと呼ばれるファイル自体が持っている情報が存在します。作成者、更新日時、ファイル名、パスなどです。 これらも検索時に有効な情報になります。 また、ファイルから文字列を抜き出す処理も必要になります。 それぞれデータフォーマットが異なりますので、そのフォーマットに合わせて文章データを抜き出す処理が必要です。OSSや製品がありますので、それらを利用して、ファイルから文章を抜き出します。\nRDB RDBのデータの場合、データが正規化されています。 検索エンジンでは、非正規化のデータを登録して検索することが基本となるため、まずは非正規化して取り出す必要が出てきます。\n例えば、ジャンルやカテゴリ、各種IDなどが実際のコンテンツのレコードに入っていると思いますが、これらをユーザーが入力したキーワードで検索したい場合などは、IDではなく表示名を取り出して、検索エンジンに登録する必要が出てきます。\nその他 データごとの変換処理について説明しました。 その他に、データのクリーニング処理などと言ったことも必要になってきます。例えば、HTMLのタイトルに必ずサイト名が入っているが、除去したいといった場合や、検索エンジン固有のデータの前処理などもあります。\n登録 最後は検索エンジンへの登録です。 最近の検索エンジンはJSON形式でデータを受け取る場合が多いので、JSONに変換することが多いです。 基本的には各種プログラミング言語のライブラリが用意されているのでこれらを利用するのが基本となります。\n検索したい項目、検索させたい方法などを洗い出し、必要なデータを作成して検索エンジンに登録します。 登録と書いていますが、更新、削除などもここでの対象となります。\nここまでの流れで、データソースからコンテンツを取得し、変換して、検索エンジンへの登録が終わりました。\n検索の改善 検索のログから分析して改善していくのが良いですが、ユーザーからの質問や意見などからも改善すべき点が見えてくると思います。 検索ログでは、次のようなものを元に、検索がうまく行かないものを見つけ出します。\n0件ヒット 0件クリック ヒットしていない検索ワードがある場合、コンテンツに問題がある場合があります。まずはこのあたりをとってみるのが良いかと。 そもそも、入力されたキーワードにマッチするコンテンツを扱っていないこともわかりますし、入力されたキーワードに似た単語を持ったコンテンツなども存在するはずです。 類義語の辞書を用意して、検索にヒットできるようにするといった分析と改善にも利用できます。\nあとは、検索エンジン側の話ですが、形態素解析器などを利用している場合に、意図した区切りになっていないために、うまくキーワードがヒットしないと言ったこともあります。\nコンテンツの理解 実はこれが一番だったりします。 どんなコンテンツを自分たちが扱っているのか?どんなデータがどういった項目でコンテンツに入っているのか?といったところから、 コンテンツのデータを元に検索にヒットさせる方法が改善できます。\nCMSなど人が入力したデータをコンテンツとして扱う場合、入力画面を改良することで、望んでいるデータを入れてもらえたり、不要なデータが入らなくなる可能性があります。 例えば、ECサイトなどで商品の説明文やタイトルにいろいろなキーワードが入っている場合などがあります。むりやりどんなキーワードでもヒットさせたいという入力者の意図もあるのですが、検索しているユーザーにはノイズになることも多いです。適切にカテゴリやジャンル、属性といった項目に分けることでおかしな入力データを減らすことも可能です。\nWebサイトなどをクローリングしたものの場合は、サイトごとに文章の特徴があったり、重複している部分などが合ったりする場合があります。 これらもコンテンツをよく調べることで、不要な情報を除去したりといったことが可能になります。\nまとめ 簡単ですが、検索のデータソースやコンテンツにまつわる話を紹介しました。 もちろんここでは紹介しきれていない項目がいっぱいあります。 また、具体例ではなく概略をざっくりと書いているのでわかりにくい場合もあるかもしれません。 すこしユースケースを絞り込んで書いたほうがわかりやすくなるのかも?\n次はUIとか書くかも?\n不明点とか疑問点、指摘事項などあればコメントしていただければと。 要望などもお待ちしております。\n","date":1600136614,"dir":"post/2020/","id":"b2c4cf0fb96d02d37f03668caaecbc57","lang":"ja","lastmod":1600136614,"permalink":"https://blog.johtani.info/blog/2020/09/15/improve-search-no3/","publishdate":"2020-09-15T11:23:34+09:00","summary":"先日は「検索システムを構成するパーツ」ということで検索システムを構成しているパーツについて書いてみました。 大体、検索がうまくヒットしないとい","tags":["検索"],"title":"検索対象のデータとデータソース(検索システムに関する妄想その3)"},{"contents":"自宅環境に少しアップデートがあったので更新版です。 お客さんのおかげで相変わらず自宅で作業させてもらってるのもあり、昨今のコロナウイルスの影響で出かけることもないので、自室の作業環境が更新されている感じです。 前回のブログはこちらです。 前回のまとめで触れていた2点について更新されています。\nまずは、現状のデスクの上の写真です。\n基本的には前回紹介したものと大きくは変わっていません(?)。 変わったものについて紹介していきます。\nデスク 先程の写真ではちょっとわかりにくいですが、スタンディングデスクになりました。\nタイマーついてるの便利 pic.twitter.com/E9engTIMnM\n\u0026mdash; Jun Ohtani (@johtani) April 30, 2020 Flexispotの天板と足の組み合わせにしました。 前のElectaの天板が明るめの色だったのもあって、メープルの天板です。 組み立てはちょっと大変でした。 足が重たいのと、天板にはネジ穴がなく電動ドライバーもないので、ネジ締めと机を起こすのがちょっと大変です。子供に手伝ってもらいながら組み立て設置をしました。 オンラインミーティングなどのときには基本、立って作業しています。 あとは、デフォルトのタイマー設定のままですが、45分ごとに立ったり座ったりを数回繰り返す感じです。\nAmazon | FLEXISPOT オフィスデスク用天板 スタンディングデスク120×60cm Amazon | FLEXISPOT スタンディングデスク 電動式 昇降デスク メモリー機能付き ブラック EN1B（天板別売り） スタンディングデスクマット フローリングに45分立ちっぱなしだと結構、足の裏がつかれるんですよ。なので、クッション性が高いフロアマットを立ってるときは利用しています。ちょっとめんどくさいのですが、椅子のときは壁に立て掛けて、立つときにマットを敷くようにして使っています。\nちなみに、ウレタン素材なので開封直後はすごい匂いでした。。。 数日は陰干しみたいなのが必要です、ご注意を。 ただ、これを利用してから膝やかかとが痛いことはなくなっています。\nAmazon | 疲労軽減マット スタンディングデスクマット 滑り止め加工 立ち仕事 耐水 耐油 耐菌 (ブラック, 75cm*50cm*2cm) ケーブルトレー スタンディングデスクだとケーブルをぶら下げた状態だと危なそうだなということで、ケーブルトレーも机の下に追加してあります。電源タップを配置して、ディスプレイなどの電源はこちらから取るようにして、ケーブルトレーからは電源タップとスタンディングデスクの電源コードを垂らすという感じです。実際にはLANケーブルも伸びてたりはしますが。。。 また、後で出てくるラズパイ+SSDも最近こちらに移設しました。 最初にチャコールグレーを発注したのですが、配送日が未定になったので、Lサイズのシルバーを発注するという慌てようでした。 結局、今は両方使っています。テーブルタップにラズパイと、結構乗せるものがあるんですよね。見えない場所だし、色が揃ってないのは気にならないかなと。\nAmazon | プラス Garage ワイヤーケーブルトレー Lサイズ 幅63.7cm シルバー Amazon | プラス Garage 配線ケーブルトレー 幅40cm チャコールグレー キーボード+パームレスト 10数年ぶりに外付けキーボードじゃないかな? 少なくともMacに移行してからは、ずっとMac bookのキーボードを使ってました(極稀にMac mini起動後とかにMagic Keyboard使うくらい)。 外出して仕事をすることが多かったのもあり、体をキーボードに合わせる感じでした。\nが、ずっと在宅で仕事をしていますし、ふるさと納税でRealforce(リンクは楽天)がということで、申し込んでみました。2週間ちょっとで到着。 箱が厳重でびっくりしました。\nAmazon | 東プレ REALFORCE SA for Mac ホワイト R2SA-JP3M-WH | Realforce まだ深いキーに慣れつつあると言った感じです。 付属の2mmのキースペーサーでAPCを2.2mmの設定で使用しています。最初は3mm+APC 1.5mmでやっていたのですが、流石にキーが敏感すぎてちょっとキーボードに手をおいたまま考え事をしているだけで「lllllllllll」のようになってしまったので現在の組み合わせに落ち着いています。\nあと、特殊な設定としてはスペースの横のeng/kanaキーを設定でキーロックして使えなくしました。どうも、ご入力の原因になっているようだったので。 日本語の入力切替は、昨日まではCtrl+Spaceを使用していましたが、このブログを書き始めてからCtrl+\\に変更しています。 むかーし、使っていたIME切り替えのショートカットです(知っている人は知っているやつ)。\nマウスは使用しておらず、キーボードの手前にトラックパッドをおいて使っています。パームレストの部分は、サムライズムさんのトラックパッドがきれいに入るmagicTrayPalmです。 Mac book Proと同じような感じでトラックパッドが使えるのがいいですね。 興味がある方は、侍割のリンクをたどってもらうと、初めてサムライズムさんで買い物をする方に限り割引がつくようになってるみたいです(なんと、私もなんか割引になる!)。\nディスプレイアーム 外付けキーボードになったのですが、Mac Book Proの画面も活用したく、さらに上下での配置がやはり目線の移動距離が少ないので気に入っていました。ただ、前回のブログで紹介したアームでは少し高さが足りず。。。 思案しながらAmazonを回遊していたら、同じ会社の新しいアームがあり、調べると高さが取れそうだということで付け替えました。 アーム2本ありますが、今のところ1本だけを使っています。 2本目のアームにカメラを乗せるのもあり?と思いながらまだ試していませんが。玉突き式に前に使っていたアームがサンダーボルトディスプレイ(縦置き)のアームになっています。前にサンダーボルトにつけていたアームは重量オーバーで悲鳴を上げていたので。。。\nAmazon | HUANUO 2画面 アーム デュアル ガススプリング式 スマホ充電器 寝室で利用していた斜めに立てかけるタイプのワイヤレス充電器を作業デスクに持ってきました。 実は部屋に時計がなく、Pixel 3 XLを使っているので、スマホの画面に常に表示されている時計を置き時計の代わりに使えそうだなと (スマホで写真を撮っているので上の画像ではスマホがありませんが)。 結構便利です。ちょっと時間を確認したいときに、メニューバーの時計では流石に小さすぎるのでw\nAmazon | Anker PowerWave 7.5 Stand, Qi ワイヤレス充電器 ミキサー 音声のミキサーです。Yamahaのスピーカーは入力が2系統あるのですが、入力したい音声は3系統あります(ラズパイ4、Mac mini、メインディスプレイ)。2入力を1系統にまとめるプラグを試しに買ってみて、Mac miniとラズパイをまとめてみたのですが、残念ながら切り替わるときに数分無音状態が続くという問題が発生しました。 USB給電できるタイプを購入しました。スライダーとかいらないなと思っていたのですが、電話やミーティング時にBGMの音を下げたりするのに地味に便利だったりします。 ただ、スライダーを動かそうとすると本体も動いてしまっていたので、本体裏に滑り止めを貼ってあります。\nAmazon | Maker hart Just Mixer ステレオ3入力音声ミキサー/電池とUSB電源可能 Webカメラ おっさんの顔がきれいに写っても仕方ないんですが、下からのアングルよりはいいかなぁということと、今後の勉強会で使えそうかな?ということで、購入してみました。 縦でも横でも使える便利なカメラです。また、あんまりないのですが、部屋の中などを写すときにカメラを持ち回せるの便利ですね。 ディスプレイの上に置いてしまうと高さがありすぎるということで、スピーカーの上に乗っけています。仮置きなのですが、このままになるんじゃないかな? 打ち合わせ中は画面共有してることが多いのでオンライン飲み会などで主に活躍してる気も。。。\nAmazon | ロジクール ウェブカメラ フルHD 1080P 60FPS StreamCam C980OW オフホワイト USB-C接続 Mac miniのSSD化 見えないところですが、Mac miniのHDDをSSDに差し替えました。 性能検証用のマシンとしてMac miniを利用し始めたのですが、 計測するたびに速度の差がありすぎるのでおかしいな?と。 よくよく考えてみると、このMac miniはFusion Driveだったんです。。。 開発などで使う分には大容量だし便利だったのですが、負荷計測に利用する場合は挙動をハンドリングできないので、弊害でしかないです。。。 ということで、頑張って差し替えました。想像以上の大手術でした。 「Mac mini HDD 交換」などでググると換装している方たちがいらっしゃいます。興味ある方はググってみてください。\nさて、復路 pic.twitter.com/SwndXPoKqn\n\u0026mdash; Jun Ohtani (@johtani) July 25, 2020 Amazon | シリコンパワー SSD 1TB SATA3 6Gb/s 2.5インチ ラズパイ4 Mac miniの負荷検証マシン化のため+Linuxを触りたかったというのもあり、ラズパイ4を追加しました。 Mac miniは主な使用用途が音楽再生だったのでラズパイ4で肩代わりできるだろう+その他の検証にもラズパイ4が使えそうだと。 現在はUbuntuをインストールして、画面共有で操作しています。\nAmazon | LABISTS Raspberry Pi 4 4B MicroSDHCカード64G まとめ かなり快適になりました。キーボードもうるさくないですし、熱くもありません。マイクのポップガードは意味がなさそうなので外しました。\nまだいくつか気になってるものもあるので、また更新するかもしれません。\n分離式キーボード - 胸を広げた状態でキーを打ったほうがいいのでは?という気がしています。ただ、最近はずっと日本語キーボードを使っているので選択肢が少ないんですよね。。。\nサンダーボルト?USB-C?ドック - MacBook Proのポートがすべて埋まっているし、もう少しケーブルを減らせると幸せになれそうなきが。。。\nモバイルディスプレイ - MacBook Proのディスプレイを使っているのですが、キーボードの上にかぶってるんですよね、結構。。。クラムシェルにしてiPadもしくはモバイルディスプレイに置き換えたほうがスッキリはしそうかなと。ただ、Touch IDが使えなくなったり、クラムシェル状態でMacBook Proの電源を入れられないというはなしなので、あまり意味がなさそうだなというのもあります。\n","date":1599531445,"dir":"post/2020/","id":"d08a3fdc040bbbdd81c9927ce296318c","lang":"ja","lastmod":1599531445,"permalink":"https://blog.johtani.info/blog/2020/09/08/update-working-facility/","publishdate":"2020-09-08T11:17:25+09:00","summary":"自宅環境に少しアップデートがあったので更新版です。 お客さんのおかげで相変わらず自宅で作業させてもらってるのもあり、昨今のコロナウイルスの影響","tags":["misc"],"title":"自宅の作業環境(2020/09)"},{"contents":"Rustで便利なクレートを見つけたので、紹介がてら、自分のメモのためにブログに残しておきます。\nそもそもの問題 Rustで処理を書いていて、なんかちょっと遅いな?どこの処理で時間がかかってるんだろう? ということがありませんか?ありますよね?\nというのを調べるために、最初に思いつくのは自分で計測する方法です。 流石にそれはなぁ、と思ったのでググって出てきた方法を最初は使っていました。\nRustで実行時間計測 3年前の記事ですが、とりあえず計測する分には問題なかったのでこちらの方が書いていたマクロを拝借していました。 が、ちょっと面倒なのが戻り値がある処理などのときに、このマクロを挟むのが結構めんどくさいなと。 また、処理の時間を測りたいのは基本的にはメソッドや関数単位であることが多いです。\nで、さらにググっていて見つけたのが、meteredでした。\nどんなもの? 計測したい部分に#[metric]のようなアノテーションを追加することで計測対象としてくれます。 あとは、計測したものを保存するレジストリという場所を指定するだけです。 処理が終わったタイミングなどで、そのレジストリの内容を出力することで、次の情報を計測することができます。\nHitCount : 実行された回数 ErrorCount : エラーを返した数(Resultを戻り値にしているメソッドが対象) InFlight : 処理中の回数かな? ResponseTime : レスポンスタイム(処理に何秒かかったか) Throughput : スループット(1秒あたり何回呼ばれたか) とりあえず試してみたのは、ResponseTimeとThroughputです。他のメトリクスはまた後日(機会があれば)。 また、metered::metric::Metricトレイトというものが用意されているようで、これを実装した独自のメトリクスも扱うことができるようです。\n使い方 使い方としては次のようになります。\n計測対象となるメソッドがある構造体に、メトリクスを保持するためのレジストリを用意 計測対象にしたい構造体のメソッドに#[measure]を追加(このとき、計測したいものも指定する。) あとは、実行したあとに構造体をダンプするとメトリクスが出力されます。\nレジストリの用意 #[derive(Default, Debug, Serialize)] pub struct NekoParser { metric_reg: NekoParserMetricRegistry, } NekoParserMetricRegistryという型はこのあとのimplのアノテーションで指定する名前になります。 実際にはこの型の構造体を自分で定義する必要はありません。 構造体のderiveでDefaultを指定します。構造体のインスタンス化のときにdefault()メソッドを呼び出して初期化したいためです(おそらくレジストリの初期化をやってくれるのだと思う(要確認))。 レジストリの用意はこれだけです。\nレジストリの指定と計測対象の指定 計測対象側です。少し長いですが、NekoParserのメソッドすべてを掲載しました。 まずは、1行目でレジストリの名前の指定(registry = NekoParserMetricRegistry)、レジストリのフィールド名(registry_expr = self.metric_reg)、レジストリの可視性(visibility = pub(self))を定義します。 2行目では、implブロック全体で計測したいメトリクスを指定しています。今回は、スループットとレスポンスタイムを計測したかったので #measure([ResponseTime, Throughput])]と2種類を指定しています。 メトリクスが2種類のため配列で指定していますが、1種類だけの場合は[]の記号は必要ありません。\nあとは、計測したい各メソッドに#[measure]をつけるだけです。 なお、メソッドごとに#[measure(ErrorCount)]といったかたちで個別にメトリクスを指定することも可能です。 今回はお試しということもあり、すべて#[measure]だけになっています。 アノテーションを付けただけで、メソッド自体を変更はしていません。\n#[metered(registry = NekoParserMetricRegistry, registry_expr = self.metric_reg, visibility = pub(self))] #[measure([ResponseTime, Throughput])] impl NekoParser { #[measure] pub fn load_and_parse_neko(\u0026amp;self) { let file_path = \u0026#34;./data/chap04/neko.txt\u0026#34;; let file = File::open(file_path).unwrap(); let buf = BufReader::new(file); let mut out = File::create(\u0026#34;./data/chap04/neko.txt.lindera.json\u0026#34;).unwrap(); buf.lines().filter_map(|item| item.ok()).for_each(|line| { let tokens = self.tokenize(line.as_str()); self.output_tokens(\u0026amp;tokens, \u0026amp;mut out); }); } #[measure] pub fn output_tokens(\u0026amp;self, tokens: \u0026amp;Vec\u0026lt;Token\u0026gt;, buf: \u0026amp;mut File) { writeln!(buf, \u0026#34;{}\u0026#34;, serde_json::to_string(tokens).unwrap()) .expect(\u0026#34;Error during output json\u0026#34;); } #[measure] pub fn tokenize(\u0026amp;self, line: \u0026amp;str) -\u0026gt; Vec\u0026lt;Token\u0026gt; { let mut tokenizer = lindera::tokenizer::Tokenizer::new(\u0026#34;normal\u0026#34;, \u0026#34;\u0026#34;); let lindera_tokens = tokenizer.tokenize(line); let tokens = lindera_tokens .iter() .map(|lindera_token| { let surface = lindera_token.text.to_string(); let pos = lindera_token.detail[0].to_string(); let pos1 = if pos != \u0026#34;UNK\u0026#34; { lindera_token.detail[1].to_string() } else { String::new() }; let base = if pos != \u0026#34;UNK\u0026#34; { lindera_token.detail[6].to_string() } else { String::new() }; Token { surface, base, pos, pos1, } }) .collect(); return tokens; } } 計測結果の出力 最後は計測結果の出力です。 今回はテストメソッドで実行して結果を出力する処理を書きました。\nlet parser = NekoParser::default();で構造体をインスタンス化します。 あとは、処理をそのまま実行します。\n最後に出力結果をJSON形式の文字列にしてから出力しました。 let serialized ... println!(\u0026quot;{}\u0026quot;, serialized);という形です。 簡単ですね!\n#[cfg(test)] mod tests { use crate::chapter04::answer::NekoParser; use std::path::Path; #[test] fn success_output_tokenlists() { let parser = NekoParser::default(); parser.load_and_parse_neko(); let serialized = serde_json::to_string(\u0026amp;parser).unwrap(); println!(\u0026#34;{}\u0026#34;, serialized); assert!(Path::new(\u0026#34;./data/chap04/neko.txt.lindera.json\u0026#34;).exists()); } } 出力結果 ここまで紹介したものの実行結果は次のような形でした。 レスポンスタイム、スループットともに、最小、最大、99パーセンタイルなどを出力してくれます。 出力はメソッド名ごとにくくられているのでとても便利です。\n{ \u0026#34;metric_reg\u0026#34;: { \u0026#34;load_and_parse_neko\u0026#34;: { \u0026#34;response_time\u0026#34;: { \u0026#34;samples\u0026#34;: 1, \u0026#34;min\u0026#34;: 176128, \u0026#34;max\u0026#34;: 177151, \u0026#34;mean\u0026#34;: 176640.0, \u0026#34;stdev\u0026#34;: 0.0, \u0026#34;90%ile\u0026#34;: 177151, \u0026#34;95%ile\u0026#34;: 177151, \u0026#34;99%ile\u0026#34;: 177151, \u0026#34;99.9%ile\u0026#34;: 177151, \u0026#34;99.99%ile\u0026#34;: 177151 }, \u0026#34;throughput\u0026#34;: { \u0026#34;samples\u0026#34;: 0, \u0026#34;min\u0026#34;: 0, \u0026#34;max\u0026#34;: 0, \u0026#34;mean\u0026#34;: 0.0, \u0026#34;stdev\u0026#34;: 0.0, \u0026#34;90%ile\u0026#34;: 0, \u0026#34;95%ile\u0026#34;: 0, \u0026#34;99%ile\u0026#34;: 0, \u0026#34;99.9%ile\u0026#34;: 0, \u0026#34;99.99%ile\u0026#34;: 0 } }, \u0026#34;output_tokens\u0026#34;: { \u0026#34;response_time\u0026#34;: { \u0026#34;samples\u0026#34;: 9964, \u0026#34;min\u0026#34;: 0, \u0026#34;max\u0026#34;: 143, \u0026#34;mean\u0026#34;: 0.03592934564431955, \u0026#34;stdev\u0026#34;: 1.5152489085107463, \u0026#34;90%ile\u0026#34;: 0, \u0026#34;95%ile\u0026#34;: 0, \u0026#34;99%ile\u0026#34;: 0, \u0026#34;99.9%ile\u0026#34;: 6, \u0026#34;99.99%ile\u0026#34;: 143 }, \u0026#34;throughput\u0026#34;: { \u0026#34;samples\u0026#34;: 174, \u0026#34;min\u0026#34;: 39, \u0026#34;max\u0026#34;: 71, \u0026#34;mean\u0026#34;: 57.103448275862064, \u0026#34;stdev\u0026#34;: 3.8417981983375835, \u0026#34;90%ile\u0026#34;: 60, \u0026#34;95%ile\u0026#34;: 61, \u0026#34;99%ile\u0026#34;: 64, \u0026#34;99.9%ile\u0026#34;: 71, \u0026#34;99.99%ile\u0026#34;: 71 } }, \u0026#34;tokenize\u0026#34;: { \u0026#34;response_time\u0026#34;: { \u0026#34;samples\u0026#34;: 9964, \u0026#34;min\u0026#34;: 12, \u0026#34;max\u0026#34;: 79, \u0026#34;mean\u0026#34;: 16.897230028101177, \u0026#34;stdev\u0026#34;: 2.331145559054724, \u0026#34;90%ile\u0026#34;: 19, \u0026#34;95%ile\u0026#34;: 20, \u0026#34;99%ile\u0026#34;: 24, \u0026#34;99.9%ile\u0026#34;: 46, \u0026#34;99.99%ile\u0026#34;: 79 }, \u0026#34;throughput\u0026#34;: { \u0026#34;samples\u0026#34;: 174, \u0026#34;min\u0026#34;: 39, \u0026#34;max\u0026#34;: 71, \u0026#34;mean\u0026#34;: 57.103448275862064, \u0026#34;stdev\u0026#34;: 3.819293076427424, \u0026#34;90%ile\u0026#34;: 60, \u0026#34;95%ile\u0026#34;: 61, \u0026#34;99%ile\u0026#34;: 64, \u0026#34;99.9%ile\u0026#34;: 71, \u0026#34;99.99%ile\u0026#34;: 71 } } } } 出力内容で気になったのはoutput_tokensとtokenizeのthroughputが全く同じ結果が出ていることです。 なにかバグを踏んでいる気がします。。。(時間を見つけてソースコード読んでみるか。)\n気をつけること meteredの導入時にわかりにくいコンパイルエラーが出たので備忘録として残しておきます。 (下からコンパイルエラーを読んでしまうくせがあったのが問題なのですが。。。) エラーメッセージは次のとおりです。\nerror[E0412]: cannot find type `ResponseTime` in this scope --\u0026gt; src/chapter04/answer.rs:13:12 | 13 | #[measure([ResponseTime, Throughput])] | ^^^^^^^^^^^^ not found in this scope | help: consider importing one of these items | 1 | use metered::ResponseTime; | 1 | use metered::common::ResponseTime; | error[E0283]: type annotations needed --\u0026gt; src/chapter04/answer.rs:12:1 | 12 | #[metered(registry = NekoParserMetricRegistry, /* default = self.metrics */ registry_expr = self.metric_reg)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type | = note: cannot satisfy `_: std::default::Default` = note: required by `std::default::Default::default` = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info) 最初のメッセージにはわかりやすく出ていますが、ResponseTimeをuseせずに利用しようとした場合に以下のようなエラーが出ていました。 ターミナル画面が狭かったのでE0283のエラーが目に入り、何を言ってるんだろう?という状態になってしまいました。 スクロールアップしたら、答えが載っているのに。。。\nコード全体 元ネタはNLP100本ノックの第4章です。 コードの全体はGitHubのソースをご覧ください。\nまとめ meteredを簡単ですが紹介してみました。 導入自体も簡単で、想像していたような使い方ができたので満足しています。 ほかにもプロファイラなどはあるのかもしれませんが、まずはこれを使っていこうかと思っています。\nバグらしきものがありそうだったりするので、そのへんは今後調査してみようかと。 まだ、ちょっと試してみただけなので、metered自体のオーバーヘッドや、独自のメトリクスの実装方法、メソッドではなく関数に対して利用する場合にはどうするのか?などいくつか疑問点があるので、今後試してみてまたブログに残しておこうと思います。\n","date":1599487900,"dir":"post/2020/","id":"827de2d7a9d231f6bcb44caf35896c1f","lang":"ja","lastmod":1599487900,"permalink":"https://blog.johtani.info/blog/2020/09/07/intro-metered-rs/","publishdate":"2020-09-07T23:11:40+09:00","summary":"Rustで便利なクレートを見つけたので、紹介がてら、自分のメモのためにブログに残しておきます。 そもそもの問題 Rustで処理を書いていて、なん","tags":["Rust"],"title":"meteredクレートの紹介"},{"contents":"Rustで言語処理100本ノックの第4章です。\n前回はこちら。\n今回は早めに続きをやりました。 「形態素解析」ですしね。\n第4章の概要 吾輩は猫であるの文章が用意されていて、MaCabで形態素解析した結果をファイルに保存したところからが開始となります。\nが、せっかくRustでやっているのでKuromojiのRust版であるLinderaを利用して形態素解析した結果を保存する部分から作成しました。 3章に引き続き、大きな流れのところの説明だけにしておきます。\n形態素解析 もとのneko.txtが文章が1行ごとになっているので、そのまま1行ずつ読みならが、形態素解析していきます。読み込みの部分は3章とあまり変わらないので割愛します。 以下は、形態素解析の処理と形態素解析結果用の構造体です。\n#[derive(Clone, Debug, Serialize, Deserialize)] struct Token { surface: String, base: String, pos: String, pos1: String, } まずは構造体です。今回の問題では、必要な情報は4種類だったのでそれを構造体にしました。\n表層形（surface） 基本形（base） 品詞（pos） 品詞細分類1（pos1） deriveでSerialize、Deserializeを付与しているのは、形態素解析の結果をJSON文字列として保存し、あとのそれぞれの課題で読み出すためにserde_jsonを利用するためです。\nfn tokenize(line: \u0026amp;str) -\u0026gt; Vec\u0026lt;Token\u0026gt; { let mut tokenizer = lindera::tokenizer::Tokenizer::new(\u0026#34;normal\u0026#34;, \u0026#34;\u0026#34;); let lindera_tokens = tokenizer.tokenize(line); let tokens = lindera_tokens .iter() .map(|lindera_token| { let surface = lindera_token.text.to_string(); let pos = lindera_token.detail[0].to_string(); let pos1 = if pos != \u0026#34;UNK\u0026#34; { lindera_token.detail[1].to_string() } else { String::new() }; let base = if pos != \u0026#34;UNK\u0026#34; { lindera_token.detail[6].to_string() } else { String::new() }; Token { surface, base, pos, pos1, } }) .collect(); return tokens; } 次が形態素解析の処理です。 入力に1行分の文章を受け取り、出力として、さきほどの構造体をベクタに入れたものVec\u0026lt;Token\u0026gt;を返します。 内部ではLinderaのTokenizerをnormalモードでインスタンス化してそのtokenizer()メソッドを叩いているだけです。 インスタンス化のときの第2引数は辞書のディレクトリですが、今回はデフォルト辞書(IPADIC)を利用しています。 戻り値はLinderaが用意したToken構造体なので、これを今回作成したToken構造体に詰め替えているだけです。\n注意点としてLinderaはMeCabとは異なり、未知語(辞書に出てこない単語)の処理が実装されていないので、品詞が\u0026quot;UNK\u0026quot;の場合にはその他の情報が取得できないので、空文字を構造体に設定するようにしました。\n結果の保存 形態素解析の結果はJSONで保存しました。 もとのファイルが1文が1行になっていたので、 1行を読み込み、形態素解析し、それをVecで取り出して、1行1配列JSONの形で保存するようにしてあります。\nfn output_tokens(tokens: \u0026amp;Vec\u0026lt;Token\u0026gt;, buf: \u0026amp;mut File) { writeln!(buf, \u0026#34;{}\u0026#34;, serde_json::to_string(tokens).unwrap()).expect(\u0026#34;Error during output json\u0026#34;); } serde_json::to_stringにVec\u0026lt;Token\u0026gt;を渡しているだけですが、構造体にderiveをつけているのでよしなにやってくれます(便利ー)。\nJSONの読み込み処理 1行1JSONの読み込み処理です。 今回も3章のように読み込みながら、各文章ごとの形態素解析結果に対して処理を実施するために、処理を実行するためのtraitをCommandとして用意し、それぞれの問題で形態素解析結果に対して処理を書くような実装にしました。また、設問37で「猫」と共起している単語を処理するという課題があるので、文章に「猫」が入っているものだけを処理できるようにするためのFilterも用意し、これをJSONの読み込み処理のイテレータのfilterにわたすようにしています。 特にフィルタリングが必要ない場合ように、NonFilterを予め実装済みです。\ntrait Command { fn execute(\u0026amp;mut self, tokens: \u0026amp;Vec\u0026lt;Token\u0026gt;); } trait Filter { fn is_target(\u0026amp;self, line: \u0026amp;str) -\u0026gt; bool; } struct NonFilter {} impl Filter for NonFilter { fn is_target(\u0026amp;self, line: \u0026amp;str) -\u0026gt; bool { true } } // ch04-30. 形態素解析結果の読み込み fn load_json\u0026lt;T: Command\u0026gt;(cmd: \u0026amp;mut T) { load_json_with_filter(cmd, \u0026amp;NonFilter {}); } fn load_json_with_filter\u0026lt;T: Command, U: Filter\u0026gt;(cmd: \u0026amp;mut T, filter: \u0026amp;U) { let file = File::open(\u0026#34;./data/chap04/neko.txt.lindera.json\u0026#34;).unwrap(); let buf = BufReader::new(file); buf.lines() .filter_map(|item| item.ok()) .filter(|line| filter.is_target(line)) .for_each(|line| { let tokens = parse_line_json(line.as_str()); cmd.execute(\u0026amp;tokens); }); } output_tokensではserde_json::to_stringを呼び出してましたが、読み込みでは、serde_json::from_strを使うと構造体にしてくれます。\nfn parse_line_json(line: \u0026amp;str) -\u0026gt; Vec\u0026lt;Token\u0026gt; { return serde_json::from_str(line).unwrap(); } あとは、設問ごとにCommandトレイトを実装していく形です。 たとえば、32.の動詞の原形を出力する場合は次のようになります。\nstruct ExtractVerbBase { out: File, } impl Command for ExtractVerbBase { fn execute(\u0026amp;mut self, tokens: \u0026amp;Vec\u0026lt;Token\u0026gt;) { tokens .iter() .filter(|token| token.pos == \u0026#34;動詞\u0026#34;) .for_each(|token| { writeln!(self.out, \u0026#34;{}\u0026#34;, token.base).expect(\u0026#34;Error during writeln\u0026#34;); println!(\u0026#34;{}\u0026#34;, token.base); }) } } 標準出力とは別にファイルにも出力できるようにExtractVerbBaseにoutでファイルを保持しています。\n34. 名詞の連接 「名詞の連接（連続して出現する名詞）を最長一致で抽出せよ．」という課題だったのですが、最初は読み間違えて、名詞の連接の最も長いものだけを出力するようにしてました。。。 やっぱり、出力結果とかのサンプルは用意しといてほしいなぁ。。。\nimpl Command for ExtractMaxConjunctionNoun { fn execute(\u0026amp;mut self, tokens: \u0026amp;Vec\u0026lt;Token\u0026gt;) { let mut nouns = vec![]; // TODO 参照保持でどうにかしたいけどなぁ。 tokens.iter().map(|token| token.clone()).for_each(|token| { if token.pos == \u0026#34;名詞\u0026#34; { nouns.push(token); } else { if nouns.len() \u0026gt; 1 { self.buffer.push(nouns.clone()); } nouns = vec![] } }); } } 名詞の場合に、nounsにバッファリングしつつ、違う品詞が来たら出力するという処理になっています。 cloneを呼び出していますが、これを参照を引き回す感じにできるといいのかもなぁ(結構めんどくさい)。\n36. 頻度上位10語 頻度を数えるのにはBTreeMapを利用しています。 数えながら、Top10を保持する方法がいい気がしたのですが、いい入れ物を見つけられなかったので、数え上げたあとにBTreeMapのIteratorを回しながら、キーバリューのVecをまず生成します。 その生成したVecに値でソートし、その後Iteratorから最初の10件を取得して表示する方法にしました。\nソートして取り出すという処理がついでにかかっています。。。 BinaryHeapがなにか使えそうな気もしたのですが、いい方法が思いつきませんでした。\nfn print_top10(\u0026amp;mut self) { let mut key_values: Vec\u0026lt;(\u0026amp;String, \u0026amp;u32)\u0026gt; = self.terms_count.iter().collect::\u0026lt;Vec\u0026lt;(\u0026amp;String, \u0026amp;u32)\u0026gt;\u0026gt;(); key_values.sort_by(|x, y| y.1.cmp(\u0026amp;x.1)); key_values.iter().take(10).for_each(|(key, value)| { writeln!(\u0026amp;self.out, \u0026#34;{}, {}\u0026#34;, key, value).expect(\u0026#34;Error during writeln\u0026#34;); println!(\u0026#34;{}, {}\u0026#34;, key, value); }); } まとめ 形態素解析結果をちゃんと眺めてはいないですが、処理としてはこんなところかなと。 グラフはめんどくさいのでスキップしてしまいました。。。 Kibana/Esに食わせて見てみるのもありかなぁ?\n次は係り受け解析です。Rustで使えるライブラリとかあるかなぁ?\n","date":1599445027,"dir":"post/2020/","id":"3c5d4d351e0fb9e33e0e8b6d1d43c0f2","lang":"ja","lastmod":1599445027,"permalink":"https://blog.johtani.info/blog/2020/09/07/reboot-nlp100-ch04/","publishdate":"2020-09-07T11:17:07+09:00","summary":"Rustで言語処理100本ノックの第4章です。 前回はこちら。 今回は早めに続きをやりました。 「形態素解析」ですしね。 第4章の概要 吾輩は猫である","tags":["Rust","nlp100"],"title":"第4章終了(言語処理100本ノック2020)"},{"contents":"Rustで言語処理100本ノックの第3章です。\n前回はこちら。\n少し間が空きましたが、再開しました。 間が空いた理由は。。。「正規表現」ですかね。。。 苦手なんです、正規表現。 なので、28はちょっとギブアップしてしまいました。\n第3章の概要 個別に説明はせずに大きな流れのところだけ。 それぞれの問題の解についてはリポジトリを御覧ください(興味ある人いるのかなぁ?)\n第3章はNDJSON(new line delimited JSON)という、 1行に1JSONという形式のデータを格納したファイルがgzipで圧縮された状態で提供されます。 まずは、このJSONファイルからJSONを読み込むのが主な処理になります。\n読み込んだデータに「イギリス」のWikipediaの記事が入っているので、そこから正規表現で必要なデータを抽出します。\n最後の問題が少し特殊で、抜き出した情報の「国旗」のファイル名を元に、MediaWikiのREST APIを叩いて、結果を取得し、その一部の情報を抜き出すというものです。\nJSONの読み込み処理 gzipファイルを読み込んでから、1行ずつ抜き出してVecに入れる処理が次のようになります。 今回のgzipファイルは大した量が入っていないので、全部先に抜き出す処理としてまとめました。 もっと巨大なファイルの場合は個別のJSONに対する処理を buf.lines().map()のmapのなかで実行する形にすると思います。 gzipのファイルを開くのにflate2というクレート(ライブラリ)を利用しました。便利なのは、BufReaderにlines()というメソッドがあるところですかね。\n// https://docs.rs/flate2/1.0.14/flate2/read/struct.GzDecoder.html pub fn extract_ndjson_from_gzip(input_file_name: \u0026amp;str) -\u0026gt; Vec\u0026lt;String\u0026gt; { let f = File::open(input_file_name).expect(\u0026#34;file not found?\u0026#34;); let gz = GzDecoder::new(f); let buf = BufReader::new(gz); let lines: Vec\u0026lt;String\u0026gt; = buf.lines().map(|l| l.unwrap()).collect(); return lines; } こちらは、上記のメソッドで抜き出したVecを元に、記事の情報を抜き出す処理をしています。 JSONをパースして構造体Articleにデシリアライズするために、serdeというライブラリを使用しています。 serde自体は様々なデータ形式(JSON、YAMLなど)をパースするためのフレームワークです。今回はJSONなので、serde_jsonの実装を利用しています。 また、JSON文字列から構造体にデシリアライズするのを簡単にできるように構造体に#[derive(Deserialize)]をつけています。 あとは、let article: Article = serde_json::from_str(json.as_str())という処理を実行すればserde_jsonがJSONをパースして構造体に変換してくれます。形式がわかっているJSONの扱いはこれが楽ですね。変数に型を明記してあるので、型の推論もしてくれてるようです。\n#[derive(Deserialize)] pub struct Article { title: String, text: String, } // ch03-20. JSONデータの読み込み // https://serde.rs/ pub fn load_json(input_file_name: \u0026amp;str, target_title: \u0026amp;str) -\u0026gt; Vec\u0026lt;Article\u0026gt; { let mut results = vec![]; let ndjson = extract_ndjson_from_gzip(input_file_name); for json in ndjson { let article: Article = serde_json::from_str(json.as_str()).expect(\u0026#34;json parse error\u0026#34;); if article.title == target_title { results.push(article); } } return results; } 後続の処理ではパースしたArticleから記事情報を取得して色々と処理をしています。\n正規表現 正規表現用のクレートregexがRustに用意されています。Regex::new(正規表現)で、正規表現をコンパイルし、あとは、この構造体のメソッドを利用して文字列を処理していきます。 問題では、マッチするかどうか、マッチした一部の文字列を抜き出す、不要なタグを削除するといった処理を正規表現で行いました(Rust書くよりも正規表現の書き方とかを調べるのに大半の時間をもっていかれてます。。。)。\npub fn extract_category_lines(article: \u0026amp;Article) -\u0026gt; Vec\u0026lt;String\u0026gt; { let re = Regex::new(r\u0026#34;\\[\\[Category:(.*)\\]\\]\u0026#34;).expect(\u0026#34;syntax error in regex\u0026#34;); let mut lines = vec![]; article.lines_from_text().iter().for_each(|line| { if re.is_match(line) { lines.push(line.to_string()); } }); return lines; } MediaWiki APIリクエスト処理 最後の問題で国旗のファイル名を元にMediaWiki APIを叩いて、URLの文字列を取得しましょうという問題がありました。 ファイル名をREST APIの引数に渡してHTTP経由でリクエストを送信し、返ってくるJSONレスポンスからURLを抜き出すという処理です。\nHTTPのリクエストの送受信にreqwestというクレートを利用しました。 ちょっと長いけど、APIコールしている箇所はこんな形です。\nこの関数にはasyncとついています。非同期処理の関数です。内部で2回ほど(リクエスト送信の結果待ちとレスポンスのパース待ち).awaitがあります。\nclientに.get(URL)やquery(\u0026amp;[])といったメソッドが用意されているので、URLやクエリパラメータを用意してsend()でリクエスト送信します。\nasync fn call_api(file_name: \u0026amp;str) -\u0026gt; Result\u0026lt;String, String\u0026gt; { let client = reqwest::Client::new(); let file_name2 = format!(\u0026#34;File:{}\u0026#34;, file_name); //let mut file_name2 = file_name.to_string().replace(\u0026#34; \u0026#34;, \u0026#34;_\u0026#34;); let query = [ (\u0026#34;action\u0026#34;, \u0026#34;query\u0026#34;), (\u0026#34;format\u0026#34;, \u0026#34;json\u0026#34;), (\u0026#34;prop\u0026#34;, \u0026#34;imageinfo\u0026#34;), (\u0026#34;iiprop\u0026#34;, \u0026#34;url\u0026#34;), (\u0026#34;titles\u0026#34;, file_name2.as_str()), ]; let result = client .get(\u0026#34;https://en.wikipedia.org/w/api.php\u0026#34;) .query(\u0026amp;query) .send() .await; match result { Ok(response) =\u0026gt; match response.status() { StatusCode::OK =\u0026gt; { let body = response.json::\u0026lt;MediaWikiResponse\u0026gt;().await; match body { Ok(obj) =\u0026gt; match obj.get_url() { Some(url) =\u0026gt; Ok(url), None =\u0026gt; Err(String::from(\u0026#34;Cannot get url...\u0026#34;)), }, Err(error) =\u0026gt; Err(error.to_string()), } } _ =\u0026gt; Err(String::from(format!( \u0026#34;Status code is {}.\u0026#34;, response.status() ))), }, Err(error) =\u0026gt; { let error_msg = format!(\u0026#34;Error occurred... {:?}\u0026#34;, error); println!(\u0026#34;{}\u0026#34;, error_msg.as_str()); Err(error_msg) } } } あとは、呼び出し元で非同期の処理を実行するために、tokioというクレートを利用しています。 block_on()でcall_api()の実行をして、結果が返ってくるのを待ち受けています。結果が返ってきて、問題なければ、call_apiの戻り値Result\u0026lt;String, String\u0026gt;の左側のStringの値が取り出され、get_image_urlの戻り値となります。\nfn get_image_url(file_name: \u0026amp;str) -\u0026gt; String { let mut _rt = tokio::runtime::Runtime::new().expect(\u0026#34;Fail initializing runtime\u0026#34;); let task = call_api(file_name); _rt.block_on(task).expect(\u0026#34;Something wrong...\u0026#34;) } 一応、非同期に関して説明してみましたが、合っているのかどうか。。。 クレートの関係などはまだちょっと自身がないです。。。 あとは、エラーの処理の仕方とかももうちょっと勉強したいかな。\nまとめ 一応、3章を終わらせました。だいぶ強引かつ1つスキップしましたが。。。 次は第4章の形態素解析です。\n","date":1599230785,"dir":"post/2020/","id":"eb2a5824e03996c1966bee38866ce349","lang":"ja","lastmod":1599230785,"permalink":"https://blog.johtani.info/blog/2020/09/04/reboot-nlp100-ch03/","publishdate":"2020-09-04T23:46:25+09:00","summary":"Rustで言語処理100本ノックの第3章です。 前回はこちら。 少し間が空きましたが、再開しました。 間が空いた理由は。。。「正規表現」ですかね。","tags":["Rust","nlp100"],"title":"第3章終了(言語処理100本ノック2020)"},{"contents":"負荷を計測するために、数回、Azure Cognitive Searchのクラスターを起動したり、停止したりしてました。 これは、Terraformでやると楽できるのでは?と思ったので、やってみました。 1パーティションのクラスターなので、全然大したことはないのですが、メモを残しておくためにブログに書いておきます。\n基本的にはTerraformの公式ドキュメントにあったものを自分用に変数を抽出しただけです。\nファイルたち 単にクラスターを起動するためだけなので、2種類のファイルだけ作成しました(1個でもいいかも)。\nvariables.tf - 変数用のファイル。いくつかの設定を変数として定義しました。 terraform.tf - Terraform本体のファイル。 variables.tf まずはvariables.tfです(ファイル内の並びは異なりますが。。。)。terraform.tfで利用する5つの変数です。\nresource_group - リソースグループ名。既存とは異なるリソースグループ名にしました(変に壊してもいいので)。 machine_type - 価格レベル(SKU)。公式ドキュメントに設定できる値の一覧があります。今回はWikipediaのデータを登録していたのでそれが入るサイズにしています。 region - 場所(リージョン)。リージョンの一覧はどこにあるんだろう?これを参考にしましたが。 partition_size - パーティションのサイズ(=Elasticsearchでのシャードかな?)です。今回は1つでの性能を計測したかったので1にしてあります。 search_cluster_name - Azure Cognitive Searchのサービス名。search.windows.net名前空間で一意である必要があったので、他の人が使わなそうな名前をつけています。 variable \u0026#34;machine_type\u0026#34; { default = \u0026#34;standard\u0026#34; } variable \u0026#34;region\u0026#34; { default = \u0026#34;East Asia\u0026#34; } variable \u0026#34;resource_group\u0026#34; { default = \u0026#34;johtani-wiki-test\u0026#34; } variable \u0026#34;search_cluster_name\u0026#34; { default = \u0026#34;johtani-wikipedia\u0026#34; } variable \u0026#34;partition_size\u0026#34; { default = 1 } terraform.tf terraform.tfは以下の通り。Terraformの公式ドキュメントにある例にproviderを追加しただけのものになります。\nprovider - プロバイダーの設定。Azureを利用するという宣言です。features {}がないとエラーになります。空でも必ず指定が必要です。認証周りについては、azure-cli経由で認証する方式を採用しました。azure-cliはHomebrewでインストールしています。 azurerm_resource_group - リソースグループの設定。variables.tfのresource_groupとregionを利用しています。必須項目はこの2種類だけです。 azurerm_search_service - Azure Cognitive Searchの設定。partition_count以外は必須項目です。variables.tfとazurerm_resource_groupの設定を利用しています。今回は利用していませんが、レプリカ数なども指定できるようになっています。 # Azureのproviderを指定。 provider \u0026#34;azurerm\u0026#34; { features {} } # リソースグループの設定 resource \u0026#34;azurerm_resource_group\u0026#34; \u0026#34;wiki-test\u0026#34; { name = var.resource_group location = var.region } # Azure Cognitive Searchの設定 resource \u0026#34;azurerm_search_service\u0026#34; \u0026#34;search_service\u0026#34; { name = var.search_cluster_name resource_group_name = azurerm_resource_group.wiki-test.name location = azurerm_resource_group.wiki-test.location sku = var.machine_type partition_count = var.partition_size } 以上がファイルです。ほぼ公式ドキュメントのサンプル通りですねw\nデプロイとか ファイルの準備ができたら実際にデプロイします。 Azureの環境への認証にはAzure CLIを利用して、事前にログインした状態にします。 実際にデプロイするまでの手順は次のようになります。\naz login - Azureの認証。ブラウザが起動してログイン画面が表示されます。無事認証がOKなら、azコマンドでAzure Cloudの情報が取得できます。 terraform init - 初回だけです。Terraformのワーキングディレクトリの初期化処理を実行します。 terraform plan - Terraform \u0026lt; 0.12の場合は実行。最新版だともういらないみたいだ。 terraform apply - 実際にAzure上にクラスターを起動します。Terraformが隠蔽してくれているので、実際にどんなことをやっているかはわかってないですが。 以上で、Azure Cognitive Searchのクラスターが起動します。 すごく簡単です。Webコンソールでチェックすれば、起動していることも確認できます。\nこの状態では、クラスターが起動しただけなので、あとは必要に応じてデータをロードしたり、アプリから検索したりと行ったことが可能になります。 そのへんの話はまた機会があれば。\nDestroy 今回は負荷テスト用にクラスターを起動していましたので、必要なくなれば、クラスターを削除します。Terraformを導入したもう一つの理由がこの簡略化です。 terraform destroyを実行するだけで、Azure Cognitive Searchのクラスターおよび、リソースグループが削除されます。\nまとめ ということで、ほぼ公式ドキュメントのままですが、TerraformでAzure Cognitive Searchのクラスターを起動する方法の紹介でした。 ブログを書いていて、1点気になったのは、ロケーション(リージョン)の一覧はどこにあるんだろう?という点です。azコマンドとかで出てくるのかなぁ?\n","date":1597742807,"dir":"post/2020/","id":"f5effd616a3f8db6193b482caec37912","lang":"ja","lastmod":1597742807,"permalink":"https://blog.johtani.info/blog/2020/08/18/azure-search-with-terraform/","publishdate":"2020-08-18T18:26:47+09:00","summary":"負荷を計測するために、数回、Azure Cognitive Searchのクラスターを起動したり、停止したりしてました。 これは、Terraformでやると楽でき","tags":["azure search"],"title":"TerraformでAzure Cognitive Searchのクラスターを起動"},{"contents":"先日は「システムの特徴と検索機能について」という感じでふんわり書きました。 まぁ、頭の中でぼんやり考えてることを文章にしてみた感じです。 他にもぼんやりしてるものはいくつかあるので今日も書いてみることに。 検索システム?みたいなツイートも見かけたので、検索システムってこんなイメージですというブログを書いてみました。\n検索システム(機能)を構成するパーツ 今回はシステムに組み込まれる検索機能を構成するパーツについて書き出してみようかなと思います。 パーツといってもユーザー、UI、コンテンツなども入れています。\nユーザー 検索UI 検索窓 オートコンプリート 検索結果画面 ファセット ソート ハイライト 詳細画面 レコメンド 検索エンジン コンテンツ 検索ログ クリックログとかも サービス提供者 ざっくり書くとこんな感じです。 システム構成だったり、機能だったり、アクターだったりといろいろなものが混ざってしまっていますが、登場するものはこんなものです。\nざっくりした繋がりの図はこんな感じです。\nそれぞれの役割について見ていきましょう。\nユーザー サイト、システムのユーザーです。 検索UIを経由して望んだコンテンツを探します。 探す目的は、サイトによって異なります。 「何かを購入(ECサイトやオークション)する」だったり、「情報(レシピや社内文書)を見つける」だったりします。 図では「キーワード」と記載しましたが、最近では自然文(文章)を受け付ける検索もあります。\n検索UI サイト、システムが提供するUIです。ユーザーはこのUIにキーワード(質問)を入力し、検索結果を取得します。 UIにはいくつものパーツがさらに存在します。簡単に例を上げると以下のようなものです。\n検索窓 - キーワードを入れるための入力ボックスです。 オートコンプリート(自動補完) - サイトによっては、検索窓に何かを入力すると、キーワードを保管したりサジェストしたりしてくれます。 検索結果画面 - 質問にマッチしたコンテンツの一覧を表示する画面です。一覧以外にもいくつか情報が表示されます。 検索結果一覧 - コンテンツの一覧です。何かしらの基準(日付順や人気順など)によってソートされたものが表示されます。 ファセット - 検索結果が持っている属性(価格帯、カテゴリ、メーカー名など)の一覧で、絞り込み検索のヒントです。 ハイライト - 入力したキーワードがどこにマッチしたかがわかるように、強調表示されたスニペット(情報の一部)が出ます。 検索APIとUIに分かれている場合が多いでしょうか? 処理の流れとしては、検索窓に入力されたキーワードを検索エンジンに問い合わせができるクエリに書き換えてからリクエストを投げます。 あとは、検索エンジンからのレスポンスにある検索結果を表示できる形に変換して表示するのが役割です。 また、検索ログの出力もこの部分で担当することが多いです(もしくは、検索エンジン自体がログ出力の機能を持っている場合もあります)。\n検索エンジン 検索に特化したデータ構造を内部に持っているサーバーもしくはサービスです。 ElasticsearchやApache Solr、Azure Cognitive Searchなどは転置インデックスと呼ばれるデータ構造になっています。 検索エンジンの検索処理に対しての主な役割は次の2つです。\nクエリにマッチするコンテンツの集合を決定する マッチしたコンテンツを特定の条件で並び替える(ランキング) クエリを受け取り、検索結果のリストを返すのが処理の大きな流れです。 その他に、ファセット、ハイライトといった付加的な処理を実行することがあります。\nまた、データ登録(インデキシング/インデクシング)の処理もあります。\n登録するコンテンツを検索に特化したデータ構造にして格納する 転置インデックスの場合は、入力されたデータ(文章)から単語列を作り出して、単語からコンテンツのIDが判別できる形にする処理になります。\nAlgoliaやElastic App SearchのようなSaaSであったり、RDBの機能を利用するといった選択肢もあります。\nデータソース・コンテンツ 実際に提供したいコンテンツになります。 コンテンツが保存されている場所は、サイトによって異なります。\nWebの検索サイト - インターネット上のホームページ ECサイト - データベースに格納されているアイテムのデータ 社内文書検索 - ファイルサーバーやWikiなどのファイル、文書 といった感じです。 実際には、データソースからコンテンツを検索エンジンに登録する場合は、いくつかの処理(いわゆる前処理)が必要になります。 社内文書検索やWebの検索サイトの場合は、データを収集するためのクローラーが必要ですし、 収集したデータから、検索エンジンに登録するデータを加工したり(HTMLタグを除去したり、メタデータ(URL、収集日、タイトル)を付与したり)もします(ETL処理とか言われる)。\n検索ログ 検索を提供するだけであれば、必要ありません。 が、実際に検索がどのような使われ方をしているか?を知るために必要な機能になります。 この検索ログがユーザーのニーズを読み解くための情報になります。 検索ログには次のような情報が入ります。\n検索窓に入力された文字列 入力された文字列でヒットした件数 検索結果を出したタイミングでのログです。他にも実際にヒットしたコンテンツのIDなどをログに残したり、他のユーザーと区別をつけるために、ユーザーのセッションごとにIDを発行してログに残したりもします。\nまた、検索に満足してもらえているかを見るために、実際に検索結果のどのコンテンツに興味をもったのか?という情報も検索ログとして残すことがあります。クリックログなどとも呼ばれます。検索結果のどのドキュメントが実際にクリックされたか(詳細画面に遷移したか)という情報です。1回の検索結果に対してクリックされるごとにログが残ります。 もちろん、結果に満足しない場合は、クリックされずに、キーワードを変えたり、絞り込み条件がクリックされたりします。\nECサイトなどの場合は更に、実際に購入されたかどうかといった情報もユーザーのニーズを読み解くための情報となります。 詳細画面へのクリックログや購入ログについては、検索以外からの流れ(広告やDMだったり、レコメンドだったり)なども考えられます。 これらのログを元に、検索を改善していくことになります。\nサービス提供者 サイト・システムの提供者です。 コンテンツの準備、検索UIにはどんな物が必要なのか、サイト・システムにとって良い検索とはなにか?、検索ログからユーザーのニーズを分析して何を改善していくのか?といったことを考えます。 例としては次のようなことです。\n検索結果に表示するコンテンツとはなにか? コンテンツの持っている項目・属性の何を検索対象とするか? 検索結果の並び順(ランキング)がどんなものがよいのか? 検索UIにはどんなものを表示するのか? 検索機能を作るときの流れ 検索機能を構成するパーツにどんなものがあるかを紹介しました。 実際にシステムに検索機能を追加する場合は、最低限、次のものが必要になります。\n検索UI 検索エンジン(RDB?SaaS?ミドルウェア?) データソース・コンテンツ とりあえずこれらがあれば、検索機能を作ることはできるかと。 ただ、作っただけでは、いいか悪いかの判断がつかないので、どういった使われ方をしているかを知るために検索ログをとったりして、 改善をしていく必要が出てきます。\nまとめ わかってるよそんなことはと言われそうな感じになったかもしれないですが、 検索の機能を構成するパーツについて紹介してみました。 細かなはなしは色々とありますが、大まかにはこのような役割のパーツがあります。\n実際にはこれらのパーツを用意すればよいわけではなく、それぞれで検索を良くしていくためにどんなことを考えていくのか?などが出てきます。そのあたりの話はまた、別のブログで書いていく感じでしょうか。こんな感じで書いてくと、終わらない気がしてきたけど。。。 次はどんなはなしを書くかなぁ。\n","date":1595907282,"dir":"post/2020/","id":"11a61827e80739a6065960eb188d5758","lang":"ja","lastmod":1595907282,"permalink":"https://blog.johtani.info/blog/2020/07/28/improve-search-no2/","publishdate":"2020-07-28T12:34:42+09:00","summary":"先日は「システムの特徴と検索機能について」という感じでふんわり書きました。 まぁ、頭の中でぼんやり考えてることを文章にしてみた感じです。 他にも","tags":["検索"],"title":"検索システムを構成するパーツ(検索システムに関する妄想その2)"},{"contents":"今年の頭からシステムの検索周りを手伝う仕事をフリーランスとしてやっています。 検索の仕組みを知れば知るほど面白くなってきたからという理由になるのかな? LuceneやSolr、Elasticsearchなどを長く触っているというのもあるかと思います。\nということで、検索についていつも考えています。 頭の中でまとまっていない状況ですが、システムにおける検索機能についていくつか頭の中にあることを書き出して、 いろんな方にダメ出しやコメントをもらいたいなと思ったので、色々と書いてみようかと。 思いつきのままに書いているので、はなしがあちこち飛ぶ可能性もありますが、あしからず。\n検索って難しい 「「検索」とは、データの集合から目的のデータを探し出すこと」By Wikipedia\n一言で「検索」といっても、使う人、ユースケースによっていろいろな「検索」があります。 例えば、新しいスマホを買ったときに、スクリーンロックの時間を設定する機能を「検索」したりします。 また、PCで仕事をしているときに、ファイルの中身をある文字列で「検索」したりもします。 TSUTAYAに行って、欲しかった本がおいてあるかどうか店内の端末で「検索」もします。 Rustを書いていて、こんなことをやるライブラリありそうだよな?と思ってGoogleでウェブの検索をしたりもします。\n私が特にそうだと思いますが、なにかあったらまず検索をするという生活をしています。 ただ、このとき、「検索」といっても望んでいる挙動が違ったりするものです。 以下は自分が「検索」しているときに想定していることになります。\nファイル内の検索をしているときはgrep的な検索を想定していることが多い。 書籍の検索をしているときは、特定の項目(著者など)に対してgrep的な検索を想定しているが、名前の読みなどでも検索されることを想定している(漢字覚えてなかったりする。。。)。 Rustを書いているときに機能をGoogleで検索するときは、いい感じに検索してくれることを望んでいる(入力するキーワードが曖昧なことが多々ある。例えば、そのものズバリの名前をしらないときとか) あくまでも私が想像している挙動です。他の人とは違う可能性もあります。 なので、「検索」といってもさまざまな要素があるし、想定しているシーンも異なるので「難しい」なと思っています。 また、そんな「検索」ですが、世の中的にはあって当たり前だと思われていたり、お金や時間がかかるものと思われてなかったりもします。ま、けどそういったことも含めてやればやるほど面白いなと感じている今日このごろです。\n前置きはこのくらいにして、今回はシステムの特徴と検索機能について感じていることを書いてみようと思います。\nシステムの特徴と検索機能 先ほども書きましたが、検索は今やシステムに欠かせない機能となっています。 が、あればいいというものでもないのではないかなと。とりあえず検索できるべきだということで 検索機能を追加しても使いにくいものや、想定している動きをしない場合は使われないものになってしまいます。\nシステムでの検索機能は特に、「情報検索」(Wikipediaはこちら)と呼ばれたりもします。Wikipediaによるとこんな説明です。\n情報検索（じょうほうけんさく）とは、コンピュータを用いて大量のデータ群から目的に合致したものを取り出すこと。検索の対象となるデータには文書や画像、音声、映像、その他さまざまなメディアやその組み合わせとして記録されたデータなどが含まれる。\n「目的」と呼ばれるものは「ユーザーのニーズ」と呼ばれたりもします。 「合致したもの」というのがシステムが返す「検索結果」になります。検索結果は大体の場合、何かしらの順序でソートされていることが多いです。 ざっくり話をすると、「ユーザーのニーズ」を元に「(何かしらの順序でソートされている)検索結果」を返すという処理です。\nただ、この「ユーザーのニーズ」や「何かしらの順序でソートされている検索結果」はシステムの特性、特徴によってぜんぜん違うものになります。検索エンジンを入れただけで解決するものではありません。\nまた、システムは提供する側のニーズもあります。 ECサイトであればより多くのユーザーに購買してもらったり、 コミュニティサイトの場合は利用ユーザーを増やしてコンテンツや広告の収入を増やしたりといったニーズがあります。\nこれらの両方のニーズが検索機能に影響を与えたりもします。\nいくつか例を上げてみましょう。\n書籍の検索の場合 ユーザーのニーズは、「ある本を探す」ことです。そのためにユーザーがクエリを入力します。 クエリは、例にも出しましたがタイトルや著者名の読みだったりします。 検索窓が1つしかないというよりは、著者やタイトル、出版社などそれぞれの項目ごとに検索できるほうが便利だったりしますよね。 検索結果については、完全一致したものが一番最初に出てきてほしいこともあれば、出版年月日の降順で並べたいことなど、 その時々でやりたいことが変わったりもします。\n場合によっては、説明文などでも検索できると嬉しいこともあります。また、システムからは離れますが、図書館や書店で時々、「〇〇について書かれている本ありますか?」といった聞き方をしたりもします。\nまた、書店としては、探している本を見つけてもらうために検索端末などを用意しますが、そ れ以外の本も買ってもらえるといいですよね。 オンラインの書店などでは、検索結果や書籍詳細の画面に関連書籍が出ていることもあります。\n検索とは少し異なり、探索(なにか面白い本とかないかな?というようなニーズ)をしに、書店に行くこともあります。 書店で平積みされた本やポップなどを見て新しい本に興味を持つこともあります。\nオークションサイトやECサイトでの検索の場合 ユーザーのニーズは、「欲しい物を探す」ことです。 ユーザーが入力するクエリは、幅広いものになると思います。製品の型番を入力する人もいれば、 メーカー名や製品名だったり、ジャンルで絞り込んで検索することもあります。\n探されるもの(コンテンツ、アイテム)も多数に渡ります。 検索窓は1つかもしれませんが、検索結果には、絞り込み条件(ファセット)がいくつか並んで、絞り込んでいける仕組みが用意されていることが多いです。\n検索結果のソートは、価格順だったり人気順だったりします。 ただ、オークションサイトの場合は新しいもの順や、終了日時の早い物順だったりします。\nサイト提供者のニーズとしては、より多くのアイテムを購入してもらうこと(売上)です。 また、オークションサイトの場合は、アイテムを提供している人のニーズも影響してくるでしょう。 売りたい人はより多くの人の目に止まってほしいと思うはずなので、 様々な情報を付与していかに目にとまるか?といったことを考えてくると思います。\nまた、様々な商品を扱うECサイトの場合は、さらに色々と大変になってきます。たとえば、「iPhone」で検索されたときに、 iPhoneそのものが上位に来るべきなのか、ケースなどの周辺商品なのかだったりといった問題が出てきます。 商品の提供者が多数に渡る場合は、同一商品でもさまざまなお店から提供されてしまうために、検索結果一覧に多数同じ商品が並んだりもしますよね。\nレシピサイトでの検索の場合 ユーザーのニーズは「レシピを探す」です。が、探し方はユーザーによって様々です。 冷蔵庫にある材料を入力して検索することもあれば、食べたいものが決まっていてそのレシピを検索することもあります。 このとき、重要なのは類義語だったりするでしょう。食材やレシピは同じものでも様々な名前(例:パクチー、コリアンダー、シャンツァイ(香菜)など)を持っていたりします。また、部位や形によっても名前が変わったりもします。\n検索結果は人気順で並ぶことが多いでしょうか? ただ、レシピの提供がユーザーによるものなのか、サイト運営者が提供しているものかによっても変わってくるでしょう。\nサイト提供者のニーズとしては、レシピコミュニティサイトの場合は、ユーザー数の増加や広告の売上などがあるでしょう。 調味料などのメーカーがレシピサイトをやっている場合は、調味料の売上だったりします。この場合は、検索がどの程度売上に寄与しているのか?などを測ることが難しかったりしそうです。\n社内文書検索の場合 ユーザーのニーズは「文書を探す」です。探し方はファイル名であったり、ファイルのなかに出てくる単語だったりします。 社内用語・略語のような特殊な単語で検索されることもあるでしょう。ユーザーによっては、ぼんやりとした「こんな資料を探している」といったふんわりとした検索をしたくなることもあります。\n検索結果の表示順は「それっぽいもの」が上位に出てくることが望まれそうです。 ただ、古い文書が出てきても役に立たないこともあります。新しい文書のほうが役に立つことが多いので、最近作られたものというのも重要な情報になります。ただし、権限によっては見ることができなかったり、そもそも探すこともNGだったりもします。\n社内文書検索の提供者は、素早く検索できるものを提供することで仕事の効率を上げてもらったり、無駄を省くことができることを期待しているでしょう。\n昔からですが、社内の文書は様々な場所に散らばっていることが多いです。顧客管理システム、ファイルサーバー、Wiki、ウェブサイトなどこれらをまとめて検索できるシステムなどが望まれていることも多いです(使われるかはまた別ですが。。。)。\nスマートスピーカーの場合 ちょっと特殊な面白い例かなと思ってます。 音声で検索(というかお願い?)します。 システムとしては、ユーザーのニーズを理解するのに2段階あるのかなと。\n音声認識 認識した文章・キーワードで検索(場合によってはコマンド発行) これだけでも難易度が増します。\nさらに、画面のないスピーカーの場合は、結果は1件だけになります。これって結構難しいことだと思うんです。 画面があれば、検索結果を上位10件などのリストで表示して、あとはユーザーに選んでもらうことができますが、 音声の場合は1件だけしか返せません。 また、レスポンスタイムもシビアなものだと想定されます。ずっとスピーカーに黙っていられると困りますよね? きっと大変なんだろうなぁ(妄想)。\nこのように、検索と言っても、システムごとに要求・想定されるものは変わってきます。\nまとめ 例をいくつか上げましたが、ざっくりしすぎて発散してますかね。。。 想像している部分もあるので、この通りではないと思います。 ただ、システムによって、「検索」といってもシステムの特性上、 さまざまな物事、思惑が絡んでくるというのは想像してもらえたと思います?(思いたい)。\nシステムに検索機能を追加すると言っても、探したいものが何なのか?、探してもらうものはどういったものなのか?、 検索機能を追加することで何を達成したいのか?など考えることは色々あります。 どうやって、検索機能を実装するのか、その検索機能を実装するためにはどんな情報が必要なのか?などの検索機能のコアな部分を考えるだけでなく、提供しているシステム、コンテンツがどんなものかなど、システム全体を考えながら検索機能を考えていく事が検索をより良いものとして行くことだと思います。\nまた、検索されるものも検索する人もシステムが成長するのに合わせて変化していきいます。システム同様、一度作ればおしまいというものではないので、やることはいっぱいあるのかなと。\n次は、検索のパーツについてなにか書こうかなぁ。\nボヤキ もう少しまとめてから書いたほうがいいのかもなぁ。 もしくは、出てくる要素を整理するとか。 ユーザー、コンテンツ、コンテンツ提供者とかで。 ふんわりとしたブログになってしまった。 個別のシステムごとにもっと書けることもありそう。\n","date":1595842134,"dir":"post/2020/","id":"9da845cd31310b8952efd1be1881e651","lang":"ja","lastmod":1595842134,"permalink":"https://blog.johtani.info/blog/2020/07/27/improve-search-no1/","publishdate":"2020-07-27T18:28:54+09:00","summary":"今年の頭からシステムの検索周りを手伝う仕事をフリーランスとしてやっています。 検索の仕組みを知れば知るほど面白くなってきたからという理由になる","tags":["検索"],"title":"システムの特徴と検索機能について(検索システムに関する妄想その1)"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章 Rust the book - 第9章 Rust the book - 第10章 Rust the book - 第13章 14章は飛ばして、15章です(Cargoはまた別途調べればいいかな?と思って)。\n第15章 スマートポインタ たぶん、これを理解すれば、参照とベクタや構造体とかの組み合わせがもう少し効率よく使えるようになるのかなぁ?\nポインタの強い版? 参照カウント方式のスマートポインタ型 - Luceneとかで実装されてた気がするなぁ 複数の所有者!? DerefとDropトレイトを実装している構造体 ヒープのデータを指すBoxを使用する これはコンパイルエラー。let yのタイミングで借用してるので、書き換えでエラーになる。\nfn main() { let mut x = 5; let y = \u0026amp;x; assert_eq!(5, x); assert_eq!(5, *y); x = 6; assert_eq!(6, x); assert_eq!(6, *y); } こっちはOK。\nfn main() { let mut x = 5; // in stack let y = Box::new(x); // in heap assert_eq!(5, x); assert_eq!(5, *y); x = 6; assert_eq!(6, x); assert_eq!(6, *y); } 余談:コンパイラが変なワーニングを出してくれた。\nuse std::ops::Deref; impl\u0026lt;T, Z\u0026gt; Deref for MyBox\u0026lt;T, Z\u0026gt; { type Target = T; fn deref(\u0026amp;self) -\u0026gt; \u0026amp;T { \u0026amp;self.0 } } struct MyBox\u0026lt;T, Z\u0026gt;(T, Z); impl\u0026lt;T, Z\u0026gt; MyBox\u0026lt;T, Z\u0026gt; { fn new(x: T, y: Z) -\u0026gt; MyBox\u0026lt;T, Z\u0026gt; { MyBox(x, y) } } fn main() { let x = 5; let z = \u0026#34;10\u0026#34;; let y = MyBox::new(x, z); assert_eq!(5, x); assert_eq!(5, *y); } Derefトレイトでスマートポインタを普通の参照のように扱う 参照外し型強制 : 日本語ムズカシイネ Derefを自分で実装しないといけない場面がちょっと想像できてない。たぶん、Boxとかの説明に必要なので出てきたって感じなんだろうけど。 Dropトレイトで片付け時にコードを走らせる こっちは、リソース開放とかでいい感じにできそうだってのはわかった。 Dropはどんなときに実装するんだろう?Tantivyだとオブジェクトプールとかで使ってた。 Rcは、参照カウント方式のスマートポインタ これ、ここで作ったConsのリストを追っかけるためのサンプルも書いてほしい。 #[derive(Debug)] enum List { Cons(i32, Rc\u0026lt;List\u0026gt;), Nil, } fn print_typename\u0026lt;T\u0026gt;(_: T) { println!(\u0026#34;{}\u0026#34;, std::any::type_name::\u0026lt;T\u0026gt;()); } use List::{Cons, Nil}; use std::rc::Rc; use std::borrow::Borrow; fn main() { let z = Cons(5, Rc::new(Cons(10, Rc::new(Nil)))); let a = Rc::new(z); let _b = Cons(3, Rc::clone(\u0026amp;a)); let _c = Cons(4, Rc::clone(\u0026amp;a)); match \u0026amp;(*a) { Cons(v1, v2) =\u0026gt; { print_typename(v2); println!(\u0026#34;{}, {:?}\u0026#34;, v1, v2); }, Nil =\u0026gt; println!(\u0026#34;Nil!!\u0026#34;) }; } RefCellと内部可変性パターン 循環参照は、メモリをリークすることもある ","date":1594288778,"dir":"post/2020/","id":"208a8c072ea521c813b86ca7730eb880","lang":"ja","lastmod":1594288778,"permalink":"https://blog.johtani.info/blog/2020/07/09/hap15-rust-the-book/","publishdate":"2020-07-09T18:59:38+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第15章"},{"contents":"6月7日の週に開催されたBerlin Buzzwordsにオンライン出張してました。\nBerlin Buzzwordsとは? ベルリンで開催されている、Big Data、Scarability、Storage and Searchabilityに関するカンファレンスです。 今年はコロナウイルスの影響で、オンラインで開催されました。 また、同時期に検索に関する他のカンファレンス(以下の2つ)もベルリンで毎年開催されているのですが、今年はこれら3つのカンファレンスが1つのチケットで参加できる形で開催されました。\nMICES - MIX-CAMP E-COMMERCE SEARCH HAYSTACK - The Search Relevance Conference! sponsored by OpenSource Connections MICES、HAYSTACKは初参加ですが、検索に関するいくつかのトピックが聞けたので楽しかったです。\n6/7から6/12まで(がんばって)参加したので、その感想などをブログにとどめておきます。\nオンラインってどんな感じで開催されてた? まずは、オンライン開催がどのような感じだったのかをメモしておきます。\n有料のオンラインカンファレンス(事前にチケット購入が必要) 参加者用Slack カンファレンス数日前まではここで連絡とか質問が可能だった(もちろん、メールも来ましたけど)。 基本的なプラットフォームはBrellaのバーチャルイベントプラットフォーム 参加者同士のSNS機能 - 参加者同士の興味によって参加登録時に似たような人ですよとマッチングしたり。ビデオチャット機能もあり。 カンファレンスのスケジュール確認 - セッションのスケジュールの他に、参加者同士でのチャットのスケジュールも可能。一番便利だったのは自分のタイムゾーンも表示してくれること。 ストリームチャネル - セッションが行われている場所への誘導 スピーカー・スポンサーのリスト - スピーカーやスポンサーを探せる機能。スポンサー企業からは参加者も見ることができる セッションはYouTubeライブ ストリーム中だったらちょっと戻ったり、ポーズもできるので、便利だった セッション後の質疑応答にはJitsiというオープンソース!?のビデオカンファレンスの部屋が用意されてた(GitHubで公開されてるのか。https://github.com/jitsi)。 2日目、3日目はLTとかが終わったあとに、オンライン飲み会やってたっぽい(不参加) 主催者側も初めてだとは思うのですが、目立ったトラブルはなかったです。 ちょっとだけ遅れたりしてましたが、それほど影響はなかったです。 オンラインでの開催の一番のネックは、日本だと時差が辛いということです。 ベルリンが開催地なのですが、スピーカーや参加者はアメリカからの方が結構います。 そのため、開始時間が日本の23時といった具合になりました。\n面白かった\u0026amp;気になったセッション いくつか面白かった\u0026amp;もう一度見ないとなと思ったセッションと感想を。\nNatural Language queries at Salesforce scale セッションのページはこちら(2020年7月現在) Salesforceでどのような自然言語のようなクエリに対して書き換え、サジェストのようなことをやっているか?という話です。 Salesforceはテナント(企業)ごとに、データ構造などがカスタマイズ可能なため、 それぞれ個別に入力クエリ(例: new leads in sf)に対して、どういったパーツ(時間?場所?状態?)なのか?、どのフィールドへの条件なのか?といったものをNERのディープラーニングモデルとして捉えて解析しているという話でした。 企業毎にパーソナライズもされていると。実際にはパイプラインの一部でこの処理をやっており、それ以外にも処理はされているという話もありました。評価の話もされています。\nAMA - AI-Powered Search セッションのページはこちら(2020年7月現在) ManningでMEAP(絶賛書いているところ)のAI-Powered Searchの著者2名がAMA形式でいろんな質問に答えていく感じのやつです。 最初は近況報告(Treyさんがカンファレンス直前に転職してた)と、書籍がどんなものかを簡単に紹介したあと、質問に答えていく形式で2時間あります。ディープラーニングのモデルに関する話なども出てきています。 もう一度見たいと思ってたやつなので見ないとな。。。 (パネルっぽいセッションは、ヒントがなにもないので結構辛い)\nAsk Me Anything: Lucene 9 セッションのページはこちら(2020年7月現在) LuceneのPMCメンバーのUweさんが今後のLucene/Solrのいくつかの質問に答える感じのAMAです。 出てきた話(質問の前の)としては、Lucene 8の現状(Bloc-Max WANDとか)や、Java 11対応になるよとかです。 QAでは、SIMDの話、Approximate Nearest Neighborがどんな感じか?などの話でした。\nFrom commercial search to owned search セッションのページはこちら(2020年7月現在) カルフールスペインがECの検索をどのように導入したかという概要レベルの話でした。 モノリシックなものをマイクロサービスでk8s上に載せ替えたという大きなアーキテクチャ以降の話です。 Empathy.coが提供しているものを最終的には使用したみたいだけど、 どんな検索がされているのかといったニーズの調査ができるようになり、検索に絡んだKPIが改善した話でした。 COVID-19に絡んだクエリの変化についてもちょっと話が出てました。\nNeural Search in Practice セッションのページはこちら(2020年7月現在) Zalandoの検索の一部でNIR(Neural IRモデル)を利用してクエリの改善をやって、それをどうやってトレーニングして、テストしたかなどの話。 NIRを利用することで、複数の言語に対して改善が見られたという話だった。 今までは、クエリをいくつかの処理を元に翻訳して、入力された単語がカテゴリーに対するものなのか、スタイルに関するものなのか?などを判別して、クエリの補強?を行っている手法だった。 これに対して、ディープラーニングでクエリに対するクリックデータを元にトレーニングして、どういうクエリに対してどんなアイテムを出すのか?というモデルで検索を改善していた。 ヒット件数が0件だったり少ないものを対象にして上記の処理を入れているらしい。 (ということで、ディープラーニングをしっかり勉強しないといけないみたいなので、どうにかしたい。。。)\nTop 10 Lessons learned in search projects the past 10 years セッションのページはこちら(2020年7月現在) 10年検索プロジェクトをやってきた10個の気づきという感じのセッション。 ごく当たり前のことなんだけど、検索の導入・改善に関して、こういう事あって、何も考えないとこうなっちゃうよね。 だから、こんなことをやるべきだよね?という話です。 たとえば、検索窓はあるけど分析すらしていない状況(レッスン1)だとまずはこういうのやらないとね。とか、 検索クエリの分析・改善ばかりして、コンテンツの分析・改善を怠っていないか?という当たり前の話です。 当たり前なんだけどまとめてくれてるのは、やはりいいなぁと。\nClick logs and insights: Putting the search experts in your audience to work セッションのページはこちら(2020年7月現在) 検索ログとクリックログがあったときに、どういったことに使えるのかを料理のレシピに見立ててデモをするセッションで説明が面白かったです。 「こんなログがあったときに、ログのこの項目とこの項目を材料にすると、こんなのができますね」というのを、Elasticsearchにログを取り込んで、JupyterNotebookでデモをしていました。やはり動くものがあるとわかりやすいですねぇ。\nMixing and Matching: Diversifying Search Results セッションのページはこちら(2020年7月現在) これまたパネルセッションです。 検索結果の多様性に関するディスカッションでした。 これは、ECだからこその課題でもあるのかなと。検索自体は「何かを見つける」ための手段です。 普通に考えた場合は、ピンポイントで探していたものが見つかるのが嬉しいです。 が、例えば、ユーザーが検索した単語そのものが入っているだけのものが見つかるよりも、似たような商品も一緒に出てきてほしいことありますよね?また、ECサイトだと、回遊してほしいというのもあります。ということで、それぞれの方がどんな観点で多様性を考えているのかという話をするディスカッションになっていました。\nThought Vectors, Knowledge Graphs, and Curious Death(?) of Keyword Search セッションのページはこちら(2020年7月現在) AI-Powered Searchの著者の一人、Treyさんのセッション。ベクトルを検索にどうやって使うのか、 ベクトルで表現できるものはどんなものがあるのか?どんな検索エンジンで使えるのか?という話でした。 歴史的な話も交えつつ、検索だとこのへんで使えるんじゃないか?というような話でした。\n録画は? 気になったセッションをいくつか書き出してみました。 ちなみに、全セッションのビデオが公開されています。興味がある方は、ご覧いただければと。\nThe recordings from this year\u0026#39;s Berlin Buzzwords / MICES / Haystack joint event are now online. You can watch them all on our YouTube channel. Thank you once again to all of our wonderful speakers. https://t.co/hTRDmKNdpd\n\u0026mdash; @berlinbuzzwords@floss.social (@berlinbuzzwords) July 6, 2020 感想そして来年は? 楽しかったです。検索に関する話が色々聞けるのはやっぱ楽しいですね。サイトの特性(ECなのか、Wikipediaなのかなど)によっても「良い検索」の定義も変わるので、サービスなどがどんなものか、そしてそれを良くするためには検索はどんなことができるのか?といった話や、技術的な濃い話までいろいろな話を聞けました。 ただ、パネルは英語の聞き取りが辛いですね。。。あと、時差が。日本にいながらにして時差ボケは辛い。。。 オンライン飲み会には流石に参加できませんでした(4時とか5時から始まるし)。\n来年もオンラインで開催されたら間違いなく参加します。 オフラインのみだった場合はどうなるかなぁ。。。\n","date":1594005164,"dir":"post/2020/","id":"e5cb2e5d501d3db2db5d8f14984a66d4","lang":"ja","lastmod":1594005164,"permalink":"https://blog.johtani.info/blog/2020/07/06/attend-berlin-buzzwords/","publishdate":"2020-07-06T12:12:44+09:00","summary":"6月7日の週に開催されたBerlin Buzzwordsにオンライン出張してました。 Berlin Buzzwordsとは? ベルリンで開催されている、Big","tags":["conference","berlin buzzwords"],"title":"Berlin Buzzwordsにオンライン出張してた"},{"contents":"luceneutil - マニアックなツールのセットアップの続きです。 今回も誰得?なブログなので興味ない場合は飛ばしましょう。\n一応、luceneutilのREADMEにあるlocalrun.pyを動かせるところまでいったんですが、そこで一旦本題を思い返してみました。\nKuromojiの性能が落ちてるらしいし、Analyzer系のベンチマーク測ってるグラフに載せたほうがいいよね。\nこれが、そもそも動かしてみようと思った本題です。 READMEに書いてある手順で動いたんですが、よくよく調べてみると、Analyzer系の性能テストをやってるのは、別物っぽいぞと。 なんとなく、「ソフトウェア考古学」っぽくなってきましたね。\nAnalyzerの性能テストやってるのは? Analyzerのパフォーマンステストのグラフに出てきたTokenizerの名前を元にluceneutilのリポジトリを検索してみました。 EgdeNGrams当たりで検索するとヒットしたのが以下のファイルです。\nsrc/main/perf/TestAnalyzerPerf.java src/main/perf/TestAnalyzerPerf4x.java src/python/sumAnalyzerPerf.py 本命はsrc/main/perf/TestAnalyzerPerf.javaっぽいですね。 これを動かしている人はどれかな?ということで、今度はこのファイル名で検索します。\nsrc/python/runAnalyzerPerf.py どうやら、このPythonのファイルが先程のJavaファイルを実行して、性能を計測しているみたいです。 最初に出てきた、sumAnalyzerPerf.pyはrunAnalyzerPerf.pyの実行結果をAnalyzerの計測結果のグラフに追加する処理をしているようだということまでがわかりました。\nKuromojiをTestAnalyzerPerfに追加してみる 動かす対象がわかったので、あとは、やることを追加しましょうと。\nKuromojiの実行をTestAnalyzerPerfに追加 引数を追加して日本語版のWikipediaのファイルも読み込むようにする runAnalyzerPerf.pyに引数の追加とクラスパスの追加 JapaneseAnalyzerはlucene/analysis/kuromojiにビルドされるのでクラスパスを追加 引数に日本語版のWikipediaのファイルを追加 日本語版のWikipediaのデータの用意 こんなものかな?と。\n1と2はそれほど大変ではないので、3をまずはというところから始めてみました。\nWikipediaのXMLから1行1データのTSVファイルに まずは、どんなファイルを想定して動いているのかな?ということで、英語版のファイルがどんなものかを探してみることに。\nTestAnalyzerPerf.javaでは入力ファイルから1行ずつ文字列を読み込んでAnalyzerに処理させているだけというのがわかっています。なので、とりあえず、1行ずつ読めるような形式だと。 次に、runAnalyzerPerf.pyの55行目でenwiki-20130102-lines.txtというものを読み込んでいます。 が、これがよくわからないw\n前回とりあえず動いたときに、src/python/constants.pyにいろんなファイルへのパスとかが記載されていたのを覚えていたので、その当たりから調べてみます。 52行目に約665万件のドキュメントだというような記載があります。 前回のlocalrun.pyのファイルと似たような構造(1行に1記事が埋め込まれたTSVファイル)だろうと判断して、それを作りそうなプログラムを探してみました。 Wikiとかで検索して見つけたのがこのソースたちでした。\nsrc/python/wikiXMLToText.py - それっぽい名前ですよね? 中身を見ると、第1引数のファイル(XML)からpageタグごとにデータを抜き出し、処理をしてからタブ区切りで第2引数のファイルに書き出してます。 src/python/WikipediaExtractor.py - これもそれっぽいですね。 WikipediaExtractory.pyは界隈では有名なhttps://github.com/attardi/wikiextractorみたいです。こっちはなんとなく使い方はわかっています。 src/python/combineWikiFiles.py - これまたそれっぽい。 中身を見ると、1番目のコードで出力したデータに、2番めのコードで出力されたデータを元になにかしら処理をして、引数で与えられたファイルに出力する感じになってます。 ということで、完全に憶測ですが、日本語のWikipediaのXMLファイルを元に次のような流れでファイル作ってみればいいのかな?と。\njawiki-20200620-pages-articles.xml.bz2をwikimediaからダウンロードして、unbzip2で展開 python src/python/wikiXMLToText.py jawiki-20200620-pages-articles.xml jawiki-lines.txtで、1行ごとのデータを作る ちなみに、このプログラムは2箇所ほど修正しました。usernameタグが存在しないpageが出力されなさそうなので、デフォルトでusername: \u0026quot;\u0026quot;みたいなデータをattrってディクショナリに設定しました。 cat jawiki-20200620-pages-articles.xml | python -u src/python/WikipediaExtractor.py -b102400m -o extractedで別途XMLからデータを抽出 python src/python/combineWikiFiles.py jawiki-lines.txt extracted/AA/wiki_00 jawiki-20200620-lines.txtで2と3の出力をかけ合わせる で、まぁ、一応ファイルはできたんですが。。。 前回のブログ記事でセットアップしたときにダウンロードされたファイルはtitle、日付、本文の3つのカラムしかないんですが、上記の手順で作り出したファイルにはいろんなカラムが存在するんですよね(2が出力する項目が結構ある)。。。\n性能テスト用プログラムの書き換え 入力ファイルは出来上がったので、あとは、性能テストを走らせる部分の修正です。 修正部分はプルリク見たほうが明確なので省略で。\n実行してみた で、実行してみました。 せっかくなので、ブランチをbranch_8_5とmasterを対象にしてやってみました。 実際にはsrc/python/runAnalyzerPerf.pyにディレクトリ名やブランチ名が直書きされてたので書き換えつつ実施した結果はこちら。\n他の英語系のAnalyzerと同じグラフに載せてみたのですが、遅いので、下の方に表示されてます。 で、下に凹んだ部分(23 Juneのところ)がbranch_8_5で実行したときの性能値でした。 実際に遅くなってますね。ただ、他のAnalyzerの振れ幅も大きいので、別のグラフにしたほうがわかりやすくなるのかもなぁと思った次第です。\nということで、一応動いたんでプルリク出してみました。 採用されるかなぁ?\n一応誰得ブログはこれでおしまい。 Noriとかもこの感じで対応できるんじゃないかな?\n","date":1593050518,"dir":"post/2020/","id":"bbd2824ff0d5b801bb6f5da3a2a1a888","lang":"ja","lastmod":1593050518,"permalink":"https://blog.johtani.info/blog/2020/06/25/analyzer-perf-test-with-luceneutil/","publishdate":"2020-06-25T11:01:58+09:00","summary":"luceneutil - マニアックなツールのセットアップの続きです。 今回も誰得?なブログなので興味ない場合は飛ばしましょう。 一応、luceneutilのREAD","tags":["lucene"],"title":"luceneutil - Analyzer性能テストへのkuromojiの追加"},{"contents":"LuceneのFSTの修正に関連して、Kuromojiのパフォーマンス問題が出ているようです。 この問題自体はLucene 8.6.0以降で直る予定のようなのです(Elasticsearchへの影響範囲についてはこれが参考になるかな?)。 で、これに関連して、ベンチマーク計らないとねという話が出ていて、 昔から、LuceneのMikeさんがやっているベンチマークのグラフに載せるのがいいよねという話になっていました。 どうも、これについては、Luceneの中にあるbenchmarkというプロジェクトではなく、MikeさんのGitHubリポジトリにあるプログラムで計測しているようです。\nじゃあ、手元でこれどうやって動かすんだろう?ということでやってみたブログになります。 おそらく、99.99%の人は興味ないと思うのでスルーしていただくのがいいと思います。備忘録のために書いてます。\nとりあえずgit clone 公開されているリポジトリはこちらです。\n手順通りに? とりあえず、READMEにセットアップなどのやり方があったんで追っていくことに。 とりあえず動くまでの手順は以下のとおりです。\nディレクトリを決める $LUCENE_BENCH_HOMEが起点になります。名前は何でもいいみたいです。 cd $LUCENE_BENCH_HOME リポジトリをクローン - git clone https://github.com/mikemccand/luceneutil.git utilです。 コレ自体は問題なし。 cd util セットアップスクリプトを実行 - python src/python/setup.py -download ここがすごく時間かかります。6GBのファイルをゆっくりダウンロードしてきますので、一晩置いておきましょう(起きたら終わってた) $LUCENE_BENCH_HOME/dataにenwiki-20120502-lines-1k.txt.lzmaとwikimedium500.tasksいうファイルがダウンロードされている。 ダウンロードした圧縮ファイルを展開 - unlzma enwiki-20120502-lines-1k.txt.lzma macOSにlzmaのコマンド入ってるんですね。知らなかった。 終わったらcd ../で$LUCENE_BENCH_HOMEに戻っておく ベンチマーク対象となるLuceneを用意 - git clone https://github.com/apache/lucene-solr.git READMEにはlucene_candidateとlucene_baselineって名前でって書いてあったのですが、これだと、この後の実行フェーズでエラーになりました。 trunkとpatchというディレクトリにそれぞれ変更しました。localrun.pyを実行したらこのディレクトリ名だったので(相変わらず、自分、行きあたりばったりな対応してるなぁ。。。) とりあえず動くかどうかを確認したかったので、trunkとpatchはどちらもリポジトリをcloneしたものになってます。動いたのを確認したら、タグを指定して比較したいブランチをチェックアウトする予定。 trunkとpatchをビルド - ant jar * localrun.pyを実行 - cd utilそして。。。 5.で記述したディレクトリ以外に1箇所Pythonのコードを書き換えた。 src/python/benchUtil.py内部にhppc-0.8.1.jarのファイルの存在チェックをしているのだが、2020/06/23時点でのLuceneのリポジトリの依存関係だとhppc-0.8.2.jarになっており、ファイルが見つからないエラーが出たため、0.8.2に書き換えた。970行目付近。 改めて実行したら成功した。 まだ途中 とりあえず、実行するところまではできましたが、結果の見方とかちゃんと調べないとなぁ。 いくつかローカルで対応したものについてはあとでGitHubにIssue立てとくべきだな。\nと、動くのを確認したので、日本語周りの準備をしてみてるところです。\n終わったこと\n日本語のWikipediaのデータjawiki-20200620-pages-articles.xml.bz2をダウンロードして展開 試している途中\nWikipediaExtractorでXMLからデータを抽出 - cat ~/tmp/wiki/jawiki-20200620-pages-articles.xml | python -u src/python/WikipediaExtractor.py -b102400m -o extracted これは手順が違うかも???? python src/python/wikiXMLToText.py ~/tmp/wiki/20200620-pages-articles.xml ./hoge.txt これで、title、日付、本文が抜き出せそう? この後にcombineWikiFiles.pyの実行かな? って感じです。 誰得だろうこれ???\n","date":1592917109,"dir":"post/2020/","id":"8a1ea5d5cf843bc5955a94cfcc321e92","lang":"ja","lastmod":1592917109,"permalink":"https://blog.johtani.info/blog/2020/06/23/how-to-use-luceneutil/","publishdate":"2020-06-23T21:58:29+09:00","summary":"LuceneのFSTの修正に関連して、Kuromojiのパフォーマンス問題が出ているようです。 この問題自体はLucene 8.6.0以降で直る","tags":["lucene"],"title":"luceneutil - マニアックなツールのセットアップ"},{"contents":"Azure Cognitive Searchで日本語を扱うときに、形態素解析器を使いたい場合、2種類のAnalyzerが用意されています。今回はこれらの違いがどんなものかを見ていくことにします。\nAnalyzerとは? まずは、その前にAnalyzerとは何者か?というのを少しだけ。 Azure Cognitive Searchは転置インデックスを内部で作成して、検索を行っています。 この、転置インデックスは、「単語」がどのドキュメントに入っているか?を素早く見つけることができるデータ構造となっています。\nAzure Cognitive Searchは、この「単語」を入力された文章から生成するときに、Analyzerというものを利用します。 Analyzerは入力された文章をある規則に則って単語に分割する機能です。 この「ある規則」が、各種言語や用途によって様々に用意されています。 今回はこの中のja.luceneとja.microsoftという2種類のAnalyzerについて違いを見ていきます。\n2種類のAnalyzerの違いはどんなもの? このAnalyzerの挙動を見るためのエンドポイントとしてanalyzeというAPIがあります(詳細は昔のブログを参照)。\nこのAPIを利用して、Wikipediaのいくつかの文章を単語に区切って見て、 ja.microsoftがどんな動きをしているのか想像してみます(残念ながらja.microsoftの仕様?や挙動についてはページが見つからないため)。\nもとの文章と解析結果(一部抜粋) 文章は、手元のElasticsearchに登録したjawikiのデータからランダムに抽出しています。また、自前のツールで生成したWikipediaのデータなので、まだ一部、見苦しい文字列になっています(そっちもなおさないと)。\n1. 砂川（熊本県） thumb|250px|right|上砂川橋より上流方砂川（すながわ）は、熊本県宇城市・八代郡氷川町を流れる二級河川。\nこの文字列から抽出された単語で特徴的なものを一部抜粋しました。\nja.microsoft ja.lucene 250px 250 px 上砂 上, 上砂川 川橋 砂川 橋 宇城 宇 市 城市 二級 二 ^ 級 まず、最初の250pxですが、ja.microsoftでは、pxが単位であると判定しているのか、数値と合わせた単語として抽出されています。この場合、250で検索しても、この文字列はヒットしない形になるので、ノイズが減ることが考えられるかと。\n上砂川橋という文字は、分割の仕方が別れました。 ja.luceneでは、上砂川という単語が地名として辞書に存在するために、このような分割になっています。ja.microsoftのデータは品詞の情報が取れないのですが、上砂、川橋ともに、名詞として辞書に存在しているのではないかなと。ja.luceneには川橋という単語は存在していないようでした。\n宇城市(うきし)については、2005年に合併でできた市のようで、ja.luceneが利用している辞書には存在しない可能性があり、宇城という文字が抽出できてないと思われます。\n最後は二級です。ja.luceneでは、数字と助数詞として分割されています。こちらも何かしらのロジックにより、二級という1単語でヒットできるように数字と単位?が合わせた単語で出てくる仕組みがja.microsoftなのかなと。\n2. UEFA U-18女子選手権2000 UEFA U-18女子選手権2000は第3回目のUEFA U-18女子選手権である。決勝トーナメントは2000年7月27日から8月4日までフランスで行われ、ドイツが初優勝を果たした。\nこの文字列から抽出された単語で特徴的なものを一部抜粋しました。\nja.microsoft ja.lucene u-18, u u 18, nn18 18 第3回目 第 3 回 目 トーナメント, トナメント トーナメント 2000年 2000 年 7月 7 月 27日 27 日 数字を含む単語第3回目や2000年、7月などは、ja.microsoftは先程と同様、数字と単位の組み合わせを1単語として出力しています。\nまた、トーナメントという単語をトナメントという形で、長音を除去した形で出力しています。 今回の文字列ではないですが、この他に、センターをセンターとセンタの2パターンの単語で出力するといったことを行っています。 ja.luceneの場合、単語の最後に長音がある場合だけセンタとして、長音を除去した単語が出力されます。 これは、長音の表記ゆれに対応するためではないかなと。たとえば、インターフェースとインタフェース、インターフェイスのように、人や文章によって、間にでてくる長音を使ったり使わなかったりという表記ゆれに対応するためだと思われます。 その他にも、イプロゥヴェトをイプロゥベトに、ネクストをネキストに、バラエティをバラエチにも変換するなどといった処理をしてくれるようです。カタカナの表記ゆれには強そうですね(これどうやってるんだろう?)。\nja.microsoftでは、nn18というちょっと変わった単語も出てきていました。純粋な数字の場合はnnと入力してくれるようで、数字だけで検索したい場合に利用できるのかな?これはドキュメントに書いておいてほしいかも?\n共通点 ja.lucene、ja.microsoftともに、共通している動作として、「てにをは」といった単語は除去されていました。違いがあるものとしては、「より」(助詞-格助詞-一般)、「されている」(動詞-自立、動詞-接尾、助詞-接続助詞、動詞-非自立)、「ある」(助動詞)といったものはja.microsoftでは除去されずに出てきていました。 ストップワード的に「てにをは」あたりを除去をしている感じでしょうか?\nアルファベットで構成されている単語についても、基本はそのまま出力される挙動のようでした。\nじゃあどっちがいいの? 残念ながらどちらがいいかは、一長一短かなぁと。 ja.luceneに関しては、Luceneの仕組みを利用しているので、Elasticsearchなどを使えば、個別の単語についてより詳細の情報を取得することが可能です(品詞、読みなど)。ja.microsoftについては、残念ながら手の入れようがないので、そういう動きのものだという割り切った使い方になるでしょうか? ただ、長音の除去による表記ゆれなどについては、便利な機能なので、そのあたりの問題に対応したい場合は、ja.microsoftを活用するのも良いかと思います。\n個人的には、より細かい単語としてインデックスに登録できるもののほうが、柔軟な検索には対応できるのではないかなぁと考えています(Kuromojiの辞書をUniDicにするとか?も考えますが、これはAzure Searchではできないですが)。\nまとめ Wikipediaのデータをいくつか使って、ja.microsoftとja.luceneの違いについて、考察してみました。何かの役に立てばと。 他に、これはどんな感じになるの?などありましたら、コメントいただければと。\n","date":1591692240,"dir":"post/2020/","id":"82a115ab8d617e4e96813587fe3a6049","lang":"ja","lastmod":1591692240,"permalink":"https://blog.johtani.info/blog/2020/06/09/difference-analyzers-in-azure-search/","publishdate":"2020-06-09T17:44:00+09:00","summary":"Azure Cognitive Searchで日本語を扱うときに、形態素解析器を使いたい場合、2種類のAnalyzerが用意されています。今回はこれらの違いがどんなもの","tags":["azure search","kuromoji"],"title":"Azure Cognitive Searchでの日本語向けAnalyzerの違い"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章 Rust the book - 第9章 Rust the book - 第10章 11章、12章はちょっと飛ばして、13章です。\n第13章 イテレータ、クロージャです。 12章の話もちょっと出てくるのか。\nクロージャ 基本的に、「変数には値が束縛されている」という固定観念がずっと頭にこびりついたままなので、クロージャに慣れないんだろうなぁ。そろそろこの固定概念をどうにかしないと。\n匿名関数で、変数に保存したり引数に渡せる ちょっと面白い話(ワークアウト)で実際に考えられる手法の説明がいくつか行われる 関数でリファクタリング これが自分がよくやるパターンかなぁ。クロージャになれてないので。。。 クロージャーを変数に束縛 呼び出しは関数みたいな感じ(ここで少し混乱) これだと、結局呼び出されたタイミングが複数回あるよね? -\u0026gt; あはりそうだった ここで、閑話休題で、クロージャの型推論とか注釈の話。 クロージャは狭い文脈だし、外に公開しているものでもないので、戻り値なども定義してなくてもいいよねとのこと。書くことも可能?なので、書いてわかりやすくするのもありなんだろうな。\n推論についてはこれまで通りで、2回異なる型の変数で呼び出すと、2回目で怒られていた。\n遅延評価(クロージャを保持する構造体!?) Fnトレイト トレイトとMatchの組み合わせだからこのへんで説明する形になるのか。 これを真似すれば、いくつか処理を簡素化できるかもしれないなぁ、たしかに。 なければ実行するみたいな処理を書きたいことがよくあるし。Javaだとnullで定義しといて、nullだったらみたいなのがあるから。 Cacherはサンプルだからこの名前でいいけど、自分だと、どんな名前にするかなぁ?\n振る舞いは難しくなるのか。Cacher実装の限界を読むと。\n関数にするとスコープが変わるのでアクセスできなくなると。。。コンパイラが教えてくれるのは便利だな。\n環境から値をキャプチャする3つの方法\n多分この話が一番クロージャに意味がある話なんだと思う。 イテレータ 回しましょう。\n便利。ただ、こういう書き方に自分が慣れてないので、そっちを補正しないとなぁ。 どれがイテレータ?っていうのを判別するのがちょっとむずかしい(慣れの問題かなぁ) イテレータアダプタ便利。どんなのがあるのか?とかがやっとわかってきた。 パフォーマンスに関しては、うーん、どうなんだろう?という感想だった。 ","date":1591259849,"dir":"post/2020/","id":"e74d071363645a588f858b35231128c4","lang":"ja","lastmod":1591259849,"permalink":"https://blog.johtani.info/blog/2020/06/04/chap13-rust-the-book/","publishdate":"2020-06-04T17:37:29+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第13章"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章 Rust the book - 第9章 第10章 ジェネリック、トレイト、ライフタイムです。 手強そう。\nいきなり関数の切り出し方みたいな話が始まって面食らいました。\nジェネリックなデータ型 ジェネリックはJavaにもあるので、それほど理解に苦しむことはなかったです。 また、OptionやResultですでに経験済みでしたし。\nただ、impl\u0026lt;T\u0026gt; Point\u0026lt;T\u0026gt;{、このメソッド定義は少し最初は戸惑いました。 言われてみれば、なるほどなんですけど。\nコンパイル時にコンパイラが単相化を行うことにより、必要最低限なコードを生成してくるというのは理にかなっているなぁと。\nトレイト: 共通の振る舞いを定義する 出だしにもありますが、「インターフェイス」という機能に類似していると考えると割とすんなりと理解が進みました。 ただ、Javaだと、インターフェースはクラスとセットなため、トレイとの実装に関する記述方法は少し戸惑いが。\nデフォルト実装との組み合わせはAbstractに似た処理になるなと考えながら読みすすめました。\n「トレイト境界」という日本語には少し違和感を覚えましたが、線引をして、制限をかけるという理解でいいのかな?\n実際には#[derive()]などで、トレイトを自分で実装する必要がないなどの、便利機能も用意されており、このあたりのコードの追い方がまだ少し慣れていないかもなぁと。便利なんですけど。。。\n少しだけ気になったので、動作確認したのは次の実装です。\nトレイトで宣言されている関数と構造体が独自に実装する関数の名前がかぶるとどうなるのかという実験です。 構造体独自のメソッドが優先される感じになりそう。\npub struct Tweet { pub username: String, pub content: String, pub reply: bool, pub retweet: bool, } pub trait Summary { fn summarize_author(\u0026amp;self) -\u0026gt; String; fn summarize(\u0026amp;self) -\u0026gt; String { // {}さんからもっと読む format!(\u0026#34;(Read more from {}...)\u0026#34;, self.summarize_author()) } } impl Tweet { fn summarize_author(\u0026amp;self) -\u0026gt; String { format!(\u0026#34;hoge {}\u0026#34;, self.username) } fn to_string(\u0026amp;self) -\u0026gt; String { format!(\u0026#34;fuga\u0026#34;) } } impl Summary for Tweet { fn summarize_author(\u0026amp;self) -\u0026gt; String { format!(\u0026#34;@{}\u0026#34;, self.username) } } pub fn summary\u0026lt;T: Summary\u0026gt;(hoge: \u0026amp;T) { println!(\u0026#34;{}\u0026#34;, hoge.summarize_author()); } pub fn main() { let tweet = Tweet { username: String::from(\u0026#34;horse_ebooks\u0026#34;), content: String::from(\u0026#34;of course, as you probably already know, people\u0026#34;), reply: false, retweet: false, }; println!(\u0026#34;{}\u0026#34;, tweet.summarize_author()); summary(\u0026amp;tweet); println!(\u0026#34;{}\u0026#34;, Summary::summarize_author(\u0026amp;tweet)); } ライフタイムで参照を有効化する 言われてみればそうですが、プログラマが色々考えないとまぁ、行けないんですねという感想。\nただ、借用チェッカーが賢くやってくれるおかげで、全てにライフタイム注釈をつけなくて良くなっているというのがわかりました。 逆に言うと、なんとなくRustを書き始めてしまったので、それを知らずに書いたせいで、コンパイラに怒られてても「?」となっていたのかと。。。\n疑問点がいくつかあって、\n通常はどんなライフタイム注釈をみんな書いてるんだろう?'aとかざっくりしすぎてる? 1つのメソッド、関数にライフタイム注釈が大量に出てくるような書き方をした場合は設計がおかしいのでは?って考えたほうがいいのかも? ジェネリックな型とライフタイム引数の順序を入れ替えてみても動くだろ?とおもって入れ替えてみたら怒られた。 あとは、構造体+ジェネリックが絡んできたら少しこんがらがってきそうっという感じです。 まぁ、これから先は実際に書いてみないことにはわからないんだろうなと。\nまとめ 読みました。 実際にはプログラムを書きながら慣れていく感じだろうなぁと。 まだまだ、あれ?ジェネリックってどう書くんだっけ?とか、ライフタイム注釈どうやって付けて、使うときはどうすんだ?みたいになりながら、 出てくるサンプルを少し変えてみてはどうやって動くんだろうこの場合?みたいなことをやってました。 次は、11章、12章を少しだけ自習しつつ、13章に入る予定です(知り合いと一緒に読みすすめてる)。\n","date":1590656815,"dir":"post/2020/","id":"163beeae9620c1a6a46a38aa7ebd9663","lang":"ja","lastmod":1590656815,"permalink":"https://blog.johtani.info/blog/2020/05/28/chap10-rust-the-book/","publishdate":"2020-05-28T18:06:55+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第10章"},{"contents":"今回はAzure Cognitive SearchのSDKを利用したアプリケーションが、実際にAzure Cognitive Searchに対して送信しているリクエストのパラメータとボディをログに保存する方法について紹介します。\n動機 アプリケーションでリクエストを組み立てて、SDK経由で送信していると、最終的にAzure Cognitive Searchに対して送信されているリクエストのパラメータや検索条件などをひと目で見たいことがあります。 アプリケーションでは、ソート条件や、クエリ文字列の組み立てなどの処理は異なる場所で行われたりしますので。\nまた、公式リファレンスでは、機能の説明はRest APIの使い方と組み合わせで説明されることが多いです。\nということで、SDKを利用しているアプリからAzure Searchへ送信されているリクエストをログに保存する方法を調べてみました。\n方法 調べてみるといくつかの手段を取ることができそうだとわかりました。実際に調べて実装する方法を4種類ほど試してみたのでブログに残しておきます。なお、2020年4月時点でのSDKとAzureの仕組みに基づいたブログになります。最新版ではお手軽な方法があるかもしれません。\nDelegatingHandlerを利用する ServiceClientTracingの機能を利用する Azure Application Insightsを活用する Azure Cognitive Searchのコンソールにある診断情報の機能を利用する 1、2はAzure Cognitive SearchのSDKのリファレンスから当たりを付けて見つけた方法です。 3はApplication Insights、4はAzure Cognitive Searchの機能になります。 これらの方法について個別に説明していきます。\n1. DelegatingHandleを利用する まずは、SDKでロギングの機能がないかを調べて見つけた機能がこちらです。 SDKのSearchServiceClientのコンストラクタの引数にDelegatingHandlerというものが渡せることを発見しました。\nこれは、.NET FrameworkのHttpのAPIに存在するクラスで、HTTPのクライアントがHTTPの送受信時に、処理を挟むことができる機能です。フレームワーク側で、LoggingHttpMessaggeHandlerというクラスを用意してくれていましたが、残念ながらこちらは、リクエストとレスポンスのヘッダのみをロギングするクラスでした。 ということで、リクエストボディをログに出力したい場合は独自に拡張してやる必要があります。なお、ロギングにはMicrosoft.Extensions.LoggingのILoggerを使用します。\nまた、Azure Cognitive SearchのSDK側に違う問題点もありました。チュートリアルにあるように、検索するときには、SDKは次のような使い方を想定しています。\n// Create a service and index client. _serviceClient = new SearchServiceClient(searchServiceName, new SearchCredentials(queryApiKey)); _indexClient = _serviceClient.Indexes.GetClient(\u0026#34;hotels\u0026#34;); インデックス用のクライアントを取得するために、GetClient(インデックス名)というメソッドを使用します。このGetClientメソッドのバリエーションとして、DelegatingHandlerを受け取るメソッドがないのです。。。\nということで、DelegationHandlerを活用する方法としては、以下の2つを実装する必要があります。\nCustomなLoggingHttpMessageHandlerクラスを実装 GetClientと同等の処理をDelegatingHandlerを引数にしたものを実装する 以上の2つを実装し、アプリケーション側から2で作成したGetClientを呼び出すことで、リクエストをボディも含めてログ出力することが可能になります。以下は実装例です。\nCustomHttpMessageHandlerクラス。\nusing System; using System.Collections.Generic; using System.Diagnostics; using System.Net.Http; using System.Net.Http.Headers; using System.Text; using System.Threading; using System.Threading.Tasks; using Microsoft.Extensions.Logging; namespace AzureSearchSample { public class CustomLoggingHttpMessageHandler : DelegatingHandler { private readonly ILogger _logger; private readonly bool _logContent = false; public CustomLoggingHttpMessageHandler(ILogger logger, bool logContent) { if (logger == null) { throw new ArgumentNullException(nameof(logger)); } this._logger = logger; this._logContent = logContent; } protected override async Task\u0026lt;HttpResponseMessage\u0026gt; SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) { if (request == null) { throw new ArgumentNullException(nameof(request)); } await Log.RequestStart(this._logger, request, this._logContent); var stopwatch = new Stopwatch(); HttpResponseMessage response = await base.SendAsync(request, cancellationToken).ConfigureAwait(false); stopwatch.Stop(); await Log.RequestEnd(this._logger, response, stopwatch.Elapsed); return response; } private static class Log { private static class EventIds { public static readonly EventId RequestStart = new EventId(100, \u0026#34;RequestStart\u0026#34;); public static readonly EventId RequestEnd = new EventId(101, \u0026#34;RequestEnd\u0026#34;); } public static async Task RequestStart(ILogger logger, HttpRequestMessage request, bool logContent) { StringBuilder message = new StringBuilder(); message.AppendLine($\u0026#34;Sending HTTP request {request.Method} {request.RequestUri}\u0026#34;); if (logger.IsEnabled(LogLevel.Trace)) { LogHttpHeaders(message, request.Headers); await LogHttpContent(message, request.Content, logContent); logger.Log( LogLevel.Trace, EventIds.RequestStart, message, null, (state, ex) =\u0026gt; state.ToString()); } } public static async Task RequestEnd(ILogger logger, HttpResponseMessage response, TimeSpan duration) { StringBuilder message = new StringBuilder(); message.AppendLine( $\u0026#34;Recieving HTTP response after {duration.TotalMilliseconds}ms - {response.StatusCode}\u0026#34;); if (logger.IsEnabled(LogLevel.Trace)) { LogHttpHeaders(message, response.Headers); await LogHttpContent(message, response.Content, false); logger.Log( LogLevel.Trace, EventIds.RequestEnd, message, null, (state, ex) =\u0026gt; state.ToString() ); } } private static void LogHttpHeaders(StringBuilder message, HttpHeaders headers) { if (headers == null) throw new ArgumentNullException(nameof(headers)); foreach (KeyValuePair\u0026lt;string, IEnumerable\u0026lt;string\u0026gt;\u0026gt; header in headers) { foreach (string value in header.Value) { message.AppendLine($\u0026#34;{header.Key}: {value}\u0026#34;); } } } private static async Task LogHttpContent(StringBuilder message, HttpContent content, bool logContent) { if (content != null) { foreach (KeyValuePair\u0026lt;string,IEnumerable\u0026lt;string\u0026gt;\u0026gt; header in content.Headers) { foreach (string value in header.Value) { message.AppendLine($\u0026#34;{header.Key}: {value}\u0026#34;); } } if (logContent) { string contentBody = await content.ReadAsStringAsync(); message.AppendLine(contentBody); } } } } } } GetClientの実装\nprivate ISearchIndexClient GetClient(string indexName, params DelegatingHandler[] handlers) { var rootHandler = _searchServiceClient.HttpMessageHandlers.OfType\u0026lt;HttpClientHandler\u0026gt;().SingleOrDefault(); var indexClient = new SearchIndexClient(_searchServiceClient.SearchServiceName, indexName, _searchServiceClient.SearchCredentials, rootHandler, handlers) { SearchDnsSuffix = _searchServiceClient.SearchDnsSuffix }; indexClient.HttpClient.Timeout = _searchServiceClient.HttpClient.Timeout; return indexClient; } 出力されるログ例\n2020/04/14 19:17:53.591|TRACE|Sending HTTP request POST https://サービス名.search.windows.net/indexes(\u0026#39;インデックス名\u0026#39;)/docs/search.post.search?api-version=2019-05-06 client-request-id: be02140f-3a07-48cc-b018-d8aa5e819bc3 Accept-Language: en-US Accept: application/json; odata.metadata=none api-key: APIキー User-Agent: FxVersion/4.700.20.11803 User-Agent: OSName/MacOs User-Agent: OSVersion/Darwin.19.4.0.Darwin.Kernel.Version.19.4.0.Wed.Mar.4.22.28.40.PST.2020.root.xnu.6153.101.6.15RELEASE.X86.64 User-Agent: Microsoft.Azure.Search.SearchIndexClient/10.100.19.52907 Content-Type: application/json; charset=utf-8 { \u0026#34;count\u0026#34;: false, \u0026#34;facets\u0026#34;: [], \u0026#34;queryType\u0026#34;: \u0026#34;simple\u0026#34;, \u0026#34;scoringParameters\u0026#34;: [], \u0026#34;search\u0026#34;: \u0026#34;azure\u0026#34;, \u0026#34;searchMode\u0026#34;: \u0026#34;any\u0026#34; } |AzureSearchSample.SearchService|EventId_Id=100, EventId_Name=RequestStart, EventId=RequestStart メリット、デメリット Azure Cognitive Searchの検索の処理だけを対象にリクエストのログを出力することが可能です。また、影響範囲はアプリケーションだけに閉じていますので、デバッグ目的などでログ出力したい場合に、自分だけの手元でログの確認が可能になります。\nデメリットとしては、独自に実装しなければいけない範囲が広いことです。\n2. ServiceClientTracingの機能を利用する Microsoft.Rest.ClientRuntimeというライブラリをAzure Cognitive Searchは利用しています。 このライブラリにServiceClientTracingというクラスが存在します。 なにやら、クライアントの処理のトレースができそうです。\nAzure Cognitive SearchのSDKの実装がGitHubに公開されており、検索リクエストの処理を投げる直前に、このトレースの仕組がONになっていると、ServiceClientTracing.SendRequestメソッドを呼び出していました。\n実際にSendRequestメソッドに送られたものに対して何かしらの処理を行うのは、IServiceClientTracingIntercepterインターフェースを実装したクラスになります。 このインターフェースの実装がLog4Netに存在します。Log4Netを利用している場合は、これを活用すれば楽ができます。\n実際にServiceClientTracingを有効にするには、以下の2行を呼び出すだけです。\nServiceClientTracing.IsEnabled = true; ServiceClientTracing.AddTracingInterceptor(new Log4NetTracingInterceptor()); あとは、Rest.ClientRuntimeがよしなにやってくれます。 1とは異なり、トレースログなので、リクエストのボディについても出力してくれます。\n2020-05-26 19:09:04,058 [1] DEBUG Microsoft.Rest.Tracing.Log4Net.Log4NetTracingInterceptor [(null)] - invocationId: 1 instance: Microsoft.Azure.Search.DocumentsProxyOperations method: SearchPost parameters: {searchRequest=Microsoft.Azure.Search.Models.SearchRequest,clientRequestId=,cancellationToken=System.Threading.CancellationToken} 2020-05-26 19:09:04,164 [1] DEBUG Microsoft.Rest.Tracing.Log4Net.Log4NetTracingInterceptor [(null)] - invocationId: 1 request: Method: POST, RequestUri: \u0026#39;https://サービス名.search.windows.net/indexes(\u0026#39;インデックス名\u0026#39;)/docs/search.post.search?api-version=2019-05-06\u0026#39;, Version: 2.0, Content: System.Net.Http.StringContent, Headers: { client-request-id: 591cb14f-e5c2-4a85-977d-01d1f6431ddc Accept-Language: en-US Accept: application/json; odata.metadata=none api-key: APIキー Content-Type: application/json; charset=utf-8 } Body: { { \u0026#34;count\u0026#34;: false, \u0026#34;facets\u0026#34;: [], \u0026#34;queryType\u0026#34;: \u0026#34;simple\u0026#34;, \u0026#34;scoringParameters\u0026#34;: [], \u0026#34;search\u0026#34;: \u0026#34;azure\u0026#34;, \u0026#34;searchMode\u0026#34;: \u0026#34;any\u0026#34; } } 2020-05-26 19:09:04,459 [Thread Pool Worker] DEBUG Microsoft.Rest.Tracing.Log4Net.Log4NetTracingInterceptor [(null)] - invocationId: 1 response: StatusCode: 200, ReasonPhrase: \u0026#39;OK\u0026#39;, Version: 1.1, Content: System.Net.Http.StreamContent, Headers: { Cache-Control: no-cache Pragma: no-cache request-id: 591cb14f-e5c2-4a85-977d-01d1f6431ddc elapsed-time: 72 OData-Version: 4.0 Preference-Applied: odata.include-annotations=\u0026#34;*\u0026#34; Strict-Transport-Security: max-age=15724800; includeSubDomains Date: Tue, 26 May 2020 10:09:04 GMT Content-Type: application/json; odata.metadata=none Expires: -1 Content-Length: 376 } メリット、デメリット Log4Netを利用しているアプリの場合、2行だけを追加することで実装が完了するのがお手軽な点です。\n難点としては、Rest Client全てにたいしてトレース処理が入ってしまうので、Azure Cognitive Search以外にもRestクライアントを利用しているものが存在した場合、ログの量が増えてしまいます。また、検索以外の処理でもトレースされてしまうのもデメリットになります。\nLog4Net以外のログ機構を使用している場合は、自分でIServiceClientTracingInterceptorを実装する必要も出てきます(参考:StackOverflow)。\n3. Azure Application Insightsを活用する ここから紹介する3と4については、ログの出力先がAzure上になります。\nAzureのApplication Insightsを利用する方法です。 Azure?.NET?のアプリケーションパフォーマンスモニタリングのサービスです。\nApplication Insightsを自分のアプリケーションに設定することで、アプリケーションのパフォーマンス監視に関する情報がAzure上のApplication Insightsリソースに送信されるようになります。\nただ、Application Insightsのデフォルトの機能では、URL程度の情報だけが送信されます(参考:しばやんさんのブログ)\nこちらも拡張機能が用意されており、ITelemetryInitializerのインターフェースを実装したクラスを用意することで、独自の情報をApplication Insightsに出力することが可能となります。詳細についてはしばやんさんのブログを参考にしてもらうのが良いかと。\nHttpリクエストを出力する実装例は次のとおりです。ただ、ちょっとうまく行かないパターンがあったので、コメントアウトとして残してあったりします(なんでだろう?)\nusing System.Collections.Generic; using System.Net.Http; using System.Net.Http.Headers; using Microsoft.ApplicationInsights.Channel; using Microsoft.ApplicationInsights.DataContracts; using Microsoft.ApplicationInsights.Extensibility; namespace AzureSearchWebSample.ApplicationInsights { public class HttpRequestInitializer : ITelemetryInitializer { public void Initialize(ITelemetry telemetry) { if (!(telemetry is DependencyTelemetry dependency)) { return; } HttpRequestMessage requestMessage = null; HttpRequestHeaders requestHeaders; if (dependency.TryGetOperationDetail(\u0026#34;HttpRequest\u0026#34;, out var details) \u0026amp;\u0026amp; details is HttpRequestMessage request) { requestMessage = request; requestHeaders = request.Headers; if (requestMessage.Method == HttpMethod.Post) { string contentBody = requestMessage.Content.ReadAsStringAsync().GetAwaiter().GetResult(); dependency.Properties.Add(\u0026#34;RequestBody\u0026#34;,contentBody); } } else if (dependency.TryGetOperationDetail(\u0026#34;HttpRequestHeaders\u0026#34;, out details) \u0026amp;\u0026amp; details is HttpRequestHeaders headers) { requestHeaders = headers; } else { return; } foreach (KeyValuePair\u0026lt;string,IEnumerable\u0026lt;string\u0026gt;\u0026gt; header in requestHeaders) { foreach (string value in header.Value) { dependency.Properties.Add(header.Key, value); } } //この実装の場合は出力されなかった。なぜ? // if (requestMessage != null \u0026amp;\u0026amp; requestMessage.Method == HttpMethod.Post) // { // string contentBody = requestMessage.Content.ReadAsStringAsync().GetAwaiter().GetResult(); // dependency.Properties.Add(\u0026#34;RequestBody\u0026#34;,contentBody); // } } } } メリット、デメリット すでにApplication Insightsを利用している場合はついでに情報が出力されるので便利です。かつ、常にリクエストログを見れるようにしておく場合はとても便利だと思います。\nApplication Insightsを利用していない場合は、そこから導入しなければならなくなるので、手間が増えるかもしれないです。\n4. Azure Cognitive Searchのコンソールにある診断情報の機能を利用する。 最後はAzure Cognitive Searchの診断ログを有効にする方法です。 ここまで説明してきた方法の中で、一番お手軽な方法です。。。\nこれまでは、リクエストボディを出力する方法を考えていましたが、Azure Cognitive Search側の診断ログを有効にすると、リクエストボディで送信したものが、Azure Cognitive Search側で、クエリパラーメータとして、診断ログに出力されます(診断ログのQuery_s)。\nあとは、Azureのコンソールで当該時間のログを見ればよいだけです。以下は出力されたログの一部です。Description_sにはURLのパスが記載されています。\n診断ログ例(一部)\nDescription_s POST /indexes(\u0026#39;multi-field-test\u0026#39;)/docs/search.post.search Query_s ?api-version=2019-05-06\u0026amp;searchMode=Any\u0026amp;search=azure\u0026amp;queryType=Simple\u0026amp;$count=false メリット、デメリット アプリケーション側に手を入れる必要がなのでお手軽です。 一度設定しておけばコンソール側でログをいつでも見れるので便利です。\nリクエスト量が多くなってしまうと、ログの量も多くなり、費用がかさむ恐れがあります。また、複数の人が触る環境の場合は自分で送信したリクエストがどれだったのか?といった状況に陥る可能性はあります。\nその他は? Azureに対してではないですが、昔似たようなことをやるときにやっていた方法として、ローカルにプロキシサーバーを起動し、そのプロキシサーバー経由でアプリケーションから、Azureに接続することで、リクエストを保存する方法もあります。 ざんねんながら、未調査ですがアプリなどにはそれほど手を入れる必要はないかと思います。\nまとめ ちょっと送信リクエストの内容が見てみたいという話でしたが、いろいろな手段が存在しました。 自分の状況、環境に合わせて手段を選択肢てみるのがいいかと思います。 まずは、簡単な診断ログあたりからでしょうか?\n","date":1590481367,"dir":"post/2020/","id":"36dd94159e3e60076c0c6098086e255f","lang":"ja","lastmod":1590481367,"permalink":"https://blog.johtani.info/blog/2020/05/26/logging-azure-search-request/","publishdate":"2020-05-26T17:22:47+09:00","summary":"今回はAzure Cognitive SearchのSDKを利用したアプリケーションが、実際にAzure Cognitive Searchに対して送信しているリクエストのパラメータ","tags":["azure search",".net"],"title":"Azure Cognitive Searchのリクエストのロギング"},{"contents":"Mircosoft Buildというイベントが今週ありました(MSの方やお客さんに教えてもらった)。\nそこで、Azure Cognitive Searchのセッション(MyBuild - Cognitive Search： The pocket-knife for knowledge mining)があったので、見てみました。 内容がどんなものかをメモっておきます。 最初はCognitive Searchがどんなものよという説明でした。\nビルトインスキルの拡充の話 データソースからデータを取り出し、エンリッチし、検索エンジンに保存するという、パイプラインが組めるようになっています。\nこのパイプラインで利用できる処理のことがスキルと呼ばれています。ここで利用できるビルトインスキルが拡充されますよという話でした。ちょっとだけ抜き出すと以下のとおりです。\nAzure Machine Learning Text translation Brand detection Object detection スキルのリファレンスには載ってるものと載ってないものがあるので、今後追加されてくのかな? Brand detectionがどんなものなんだろう?ってのがちょっと気になりました。どっかにデモとかあるかなぁ?\nスキルセットのための新機能 : Debug Sessionのデモ 上記のスキルを組み合わせてパイプラインを組んで、データソースから取り出したデータをエンリッチしてから、検索エンジンに入れる処理をかけるのですが、その処理のデバッグ用に新しいGUIの機能が追加されてますよという紹介とデモでした。\nTutorial： Use Debug sessions to diagnose, fix, and commit changes to your skillset - Azure Cognitive Search | Microsoft Docs Manage Identityの話 Azure Cognitive Searchにデータを登録するパイプランの最初の段階で、各種データソースにアクセスが必要です。 このアクセス時にコネクションの設定にアカウントキーなども含めてましたが、これをコネクション設定ではなく、専用の管理機能が用意されましたよという話でした。\nSet up a connection to a data source using a managed identity (preview) - Azure Cognitive Search | Microsoft Docs QA Similarityとかの話 BM25になってるよとか SDKの話とか ほかにRelevancyの話 Analyzerをデフォルトのままじゃなくてちゃんと考えて使いましょう(例:各言語用のAnalyzerがいっぱいあるよとか) こんな感じでした。\n","date":1590117041,"dir":"post/2020/","id":"21982f43bc435f22efef22b309a48c66","lang":"ja","lastmod":1590117041,"permalink":"https://blog.johtani.info/blog/2020/05/22/watching-azure-cognirive-search-session-at-ms-build/","publishdate":"2020-05-22T12:10:41+09:00","summary":"Mircosoft Buildというイベントが今週ありました(MSの方やお客さんに教えてもらった)。 そこで、Azure Cognitive Searchのセッション(MyBuil","tags":["azure search"],"title":"Microsoft Build(2020)のAzure Cognirive Searchのセッションを見たのでメモ"},{"contents":"ElasticのWorkplace Searchを触ってみています(その1、その2)が、Elastic Stackの7.7.0がリリースされてしまいました。\n簡単ですが、リリースブログを見ながら気になった点をメモしとこうかと。\n本家のリリースブログ いっぱいあるんですよ、これが。まぁ、内容かぶってるのもあるんですが。\nElastic Stack Elastic Stack 7.7.0をリリース Elasticsearch 7.7.0 released Kibana 7.7.0 released Logstash 7.7.0 released Enterprise Search系 Elastic Enterprise Search 7.7 released, featuring Workplace Search GA | Elastic Blog Elastic App Search updates： Scale your way with new configuration options | Elastic Blog Elastic Workplace Search： 新しい、統合された働き方へ Observability系 Elastic Observability 7.7 released | Elastic Blog\nElastic APM 7.7.0 released with service maps, async profiler, and more | Elastic Blog\nElastic Logs 7.7.0 released with PCF support, MQTT support, and more | Elastic Blog\nElastic Metrics 7.7.0 released with enhanced Prometheus integration and PCF support, | Elastic Blog\nElastic Uptime Monitoring 7.7.0 released with alerting, anomaly detection and more | Elastic Blog\nNew alerting framework released for Observability, Security and the Elastic Stack | Elastic Blog\nIntroducing Elastic Security 7.7.0 | Elastic Blog\n個人的に気になったもの で、全部読んだわけではないのですが、個人的に気になった機能についてメモを残しておきます。 多分に検索によっている可能性がありますが、お気になさらず。 また、ブログとドキュメントを元に気になるところをピックアップしてます。 実際の実装とか動作に関してはまだ未調査の段階です。\nAsync Search - Elasticsearch ElasticsearchのAPIとして非同期に検索できるAPIが実装されました (公式リファレンス)。 大量データを検索が終了してから検索結果を返すのではなく、クエリは実行しつつわかったところまでは都度取得したいという要望だったり、Coldインデックスのように遅いストレージ上にあるデータへの検索でも少しずつ取得できるようにという具合だと思います。ログとか大量に扱う場合にまぁ、ほしいですよね。今回はEsのリリースがメインで、今後はKibanaなどとの連携だったり色々改善していくよという話みたいです(Kibanaの一部の機能は利用しているみたい)。\nライセンスとサブスクリプションのレベル Elastic License Basic 気になるところ(と、予想とか) 仕組みがどうなっているか? Search APIと同等のリクエストパラメータが使える。が、いくつか制約はありそう おそらくTask Manageerで検索してる処理が管理され、レスポンスにはIDが発行されて、そのIDで処理の進み具合を取得する感じ。 Shard単位?Segment単位? 内部的にはShard単位で検索処理を扱ってるので、Shard単位がとりあえず楽そう? Aggsとかも? 対象の模様 Sortは? 有効。ソートのフィールドがインデックス対象だった場合は、そのデータの統計値を使ってShardをソートするっぽい(公式リファレンスのNOTE参照) 関連しそうなGitHubのIssuesとか まだ読んでない\nAsync search · Issue #49091 · elastic/elasticsearch Add a listener to track the progress of a search request locally by jimczi · Pull Request #49471 · elastic/elasticsearch Pre-sort shards based on the max/min value of the primary sort field by jimczi · Pull Request #49092 · elastic/elasticsearch Async search： store intermediate results · Issue #55464 · elastic/elasticsearch Reduced consumption of heap - Elasticsearch ヒープの使用量が7.7で減ってるよというブログも別途ありました。\n元になっているLuceneの実装に関するIssueが「［LUCENE-8635］ Lazy loading Lucene FST offheap using mmap - ASF JIRA」です。ヒープ上に展開していたデータをmmapで扱えるようにすることで、ヒープのメモリを削減してる。\nで関連して、これがLuceneで操作できるようになって(「Use reader attributes to control term dict memory useage by s1monw · Pull Request #42838 · elastic/elasticsearch」)、そこからEsに取り込まれたと。\n_idをoff-heapにする話は[ここ](Move the terms index of _id off-heap. by jpountz · Pull Request #52405 · elastic/elasticsearch)にあった。\nこれに関連して、ヒープサイズの推奨について再考が必要かも?というIssue(Reconsider our recommendations for heap size? · Issue #52561 · elastic/elasticsearch)も上がってる。\nPainless Lab - Kibana ほんとにPainless?と言う話はさておき、_script APIでexecuteはできていましたが、やはりもう少し楽に実行したいですよね?ということで画面ができたみたいです。\nシンタックスハイライトとかもできるので、より簡単に使えるようになってますね。 まだ、ベータなので足りないContextとかもあるっぽいけど。\nライセンスとサブスクリプションのレベル Elastic License Basic? まだベータだからか、サブスクリプションのページにはなかった。 公式ドキュメントとGitHubのリポジトリから、Elastic Licenseであることは判明。\n気になるところ(と、予想とか?) 制限事項がどんなものか? 使えるContextがまだ少ない?まだGAではない サジェストがどのくらい効くのか? シンタックスハイライトはあるけど。まだかなぁ? その他Elasticsearch関連 7.7リリースのハイライトが別途用意されています。\n7.7.0 release highlights | Elasticsearch Reference ［7.7］ | Elastic こっちで気になるのは、ClassificationとかTransformsあたりかなぁ。ML関連の機能で。\nWorkplace Search GA これは別のブログに書くかな。\n気になるところ Betaと何が変わったのか? APIとかどういう形で提供されるのか?そもそも提供されるのか? どんな機能?みたいなのも書く予定です。\nData VisualizerでFilebeatのConfigをサジェスト - Kibana and Filebeat Kibanaの画面からデータをちょっと?(100MB)だけアップロードして、Elasticsearchにサクッとデータ登録できる機能が実はあります。この機能の拡張として、Filebeatの設定だとこんな感じに作れるよ?というのを提示してくれるようになったみたいです。 手元にあるファイルを定期的に読み込むときに、設定を書く下地ができるのは便利じゃないかな?\nライセンスとサブスクリプションのレベル Elastic License Basic Data Visualizerってどんなもの?というのはここにブログがあります。残念ながらKibanaとかの公式リファレンスには使い方のページがないんだよなぁ。\nAPMのサービスマップ - APM and Kibana アプリケーションアーキテクチャのどこでAPMが動作しているか、どこと通信しているかという、APMのエージェントが入っているアプリ間のつながりをKibana上で可視化できる機能っぽいです。まだ、ベータみたいですが、面白そう。Azure Application Insightのアプリケーションマップに似てる気がします。\nライセンスとサブスクリプションのレベル Elastic License Platinum 気になるところ どうやって作ってる(つながりをどうやて判断してる)のか? 分散トレーシングのデータを元に誰がどこと通信してるってのは取れるんじゃなかろうか? Log categorization and contextual examples - Kibana and Elasticsearch 7.6から入ってたっぽいですが、ログの分類をMLの機能を使ってできるものが、LogsのUIとかでさらに使いやすくなった模様。\nライセンスとサブスクリプションのレベル Elastic License Platinum 気になるところ 7.6の機能から追いかけないとなぁ。。。 似たようなログをカテゴリーごとに分析できるようになるので、プラスMLの仕組みでこれまでとは異なる種類のログが出始めたみたいなことが分析できそう。 まとめ 眺めるだけで時間かかりましたが、まぁ、相変わらずいっぱいありますね。 興味のあるところの濃淡が出た感じになりましたが、気になる点をピックアップしてみました。 おかしなところとか、ここはどういう意味?などあればツッコミお願いします。\n","date":1589509037,"dir":"post/2020/","id":"306cecb32320ead508346ad8fed3394d","lang":"ja","lastmod":1589509037,"permalink":"https://blog.johtani.info/blog/2020/05/15/elastic-stack-7_7/","publishdate":"2020-05-15T11:17:17+09:00","summary":"ElasticのWorkplace Searchを触ってみています(その1、その2)が、Elastic Stackの7.7.0がリリースされてし","tags":["elastic stack"],"title":"Elastic Stack 7.7がリリースされた"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章 第9章 エラー処理です。 NLP100とか、いくつかのプログラムを書いていて、なんとなくは扱っていますが、きちんと勉強しないと。\nとりあえず、「Rustには例外は存在しません。」が一番知っておくことかな。\npanic!で回復不能なエラー panic!マクロでスタックを巻き戻して掃除をして終了。 異常終了(panic = 'abort')にもできる。 「RUST_BACKTRACEを0以外の変数にセットして実行」 * Resultで回復可能なエラー expect()は気持ち悪い名前じゃないかなぁ? ここでio::Errorではないものもエラーが発生する場合には panic!すべきかするまいか まとめ 「Rustには例外は存在しない」ので、回復不能か可能かを考えつつ処理を書こうと。\n","date":1589449406,"dir":"post/2020/","id":"1e220a934e16fd941bd804ca03865b60","lang":"ja","lastmod":1589449406,"permalink":"https://blog.johtani.info/blog/2020/05/14/chap9-rust-the-book/","publishdate":"2020-05-14T18:43:26+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第9章"},{"contents":"Rustで言語処理100本ノックの第2章の残りです。\n前回はこちら。\nちなみに、標準入力から受け取る処理は書いてないです。 出力に関してはファイル分割、保存と支持があるもの以外は文字列として取り出すところで終わっています。\n12. 1列目をcol1.txtに，2列目をcol2.txtに保存 pub fn extract_column(input_file_name: \u0026amp;str, num: usize, output_file_name: \u0026amp;str) { let input_f = File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;); let read_buf = BufReader::new(input_f); let mut output_f = OpenOptions::new() .write(true) .create(true) .open(output_file_name) .expect(format!(\u0026#34;can\u0026#39;t open file[{}] with write option\u0026#34;, output_file_name).as_str()); read_buf.lines().for_each(|line| match line { Ok(line) =\u0026gt; { let columns: Vec\u0026lt;_\u0026gt; = line.split(\u0026#39;\\t\u0026#39;).collect(); writeln!(output_f, \u0026#34;{}\u0026#34;, columns[num]); output_f.flush().expect(\u0026#34;Error during flush\u0026#34;); } Err(_) =\u0026gt; panic!(\u0026#34;parse error \u0026#34;), }); } 13で出力結果を利用するので入力として出力ファイル名も受け取るようにしました。 問題としては、1列目と2列目を別々に出力すればいいので、1回の処理で書いても良かったのですが、1回1ファイルの出力という形で実装しました(効率は悪い)。\n改行コードあたりを考えるのがめんどくさかったのでwriteln!マクロでファイルに書き出しています。が、普通にwriteメソッドで改行コードを追加しても良かったのかなと。\nあとは、出力先ファイルが存在しない場合だけopenするようにOpenOptionsを利用してみています。\nflushを呼び出すべきなのかどうか?を調べないとな。。。\n13. col1.txtとcol2.txtをマージ pub fn merge_files(col1_file: \u0026amp;str, col2_file: \u0026amp;str, output_file_name: \u0026amp;str) { let col1_buf = BufReader::new(File::open(col1_file).expect(\u0026#34;file not found\u0026#34;)); let col2_buf = BufReader::new(File::open(col2_file).expect(\u0026#34;file not found\u0026#34;)); let mut output_f = OpenOptions::new() .write(true) .create(true) .open(output_file_name) .expect(format!(\u0026#34;can\u0026#39;t open file[{}] with write option\u0026#34;, output_file_name).as_str()); col1_buf .lines() .zip(col2_buf.lines()) .for_each(|(col1, col2)| { let col1 = col1.expect(\u0026#34;parse error col1\u0026#34;); let col2 = col2.expect(\u0026#34;parse error col2\u0026#34;); writeln!(output_f, \u0026#34;{}\\t{}\u0026#34;, col1, col2); output_f.flush().expect(\u0026#34;Error during flush\u0026#34;); }); } 2つのファイル名を入力として受け取り、タブでくっつけて出力します。 zipを利用することで、2つのイテレーターを同時に回しています。\n14. 先頭からN行を出力 pub fn head(input_file_name: \u0026amp;str, lines: usize) -\u0026gt; String { let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); let mut head = String::new(); buf.lines().take(lines).for_each(|line| { head.push_str(format!(\u0026#34;{}\\n\u0026#34;, line.expect(\u0026#34;parse error\u0026#34;)).as_str()); }); return head; } イテレーターのメソッドにtakeがあります。 これを利用することで、引数に指定した数のエレメントが取得できるので、これでheadが実現できます。\n15. 末尾のN行を出力 pub fn tail(input_file_name: \u0026amp;str, lines: usize) -\u0026gt; String { let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); let mut tail = String::new(); let line_count = word_count(input_file_name); buf.lines().skip(line_count - lines).for_each(|line| { tail.push_str(format!(\u0026#34;{}\\n\u0026#34;, line.expect(\u0026#34;parse error\u0026#34;)).as_str()); }); return tail; } tailの場合は少し複雑で、11で作成した行数をカウントするメソッドで総行数を取り出し、そこから引数で指定された行数を引き算した数(=出力しない行数)を、イテレーターのskipメソッドの引数に渡しています。これにより、指定された数のエレメントをスキップしたあとの処理がかけます。\n16. ファイルをN分割する pub fn split_files( input_file_name: \u0026amp;str, num: usize, output_file_prefix: \u0026amp;str, output_file_suffix: \u0026amp;str, ) { let total = word_count(input_file_name) as f64; let lines_in_file = total / num as f64; let lines_in_file = lines_in_file.ceil() as usize; // let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); let output_files: Vec\u0026lt;File\u0026gt; = create_file_vec(output_file_prefix, num, output_file_suffix); println!(\u0026#34;split file each {} lines.\u0026#34;, lines_in_file); let mut lines = buf.lines(); for mut output_f in output_files { let mut current = 1; while current \u0026lt; lines_in_file + 1 { let line = lines.next(); if let Some(line_rs) = line { if let Ok(line_str) = line_rs { writeln!(output_f, \u0026#34;{}\u0026#34;, line_str); } } current = current + 1; } output_f.flush().expect(\u0026#34;error during flush\u0026#34;); } } fn create_file_vec(output_file_prefix: \u0026amp;str, num: usize, output_file_suffix: \u0026amp;str) -\u0026gt; Vec\u0026lt;File\u0026gt; { let mut files = Vec::with_capacity(num); for i in 0..num { let output_file_name = format!(\u0026#34;{}{}{}\u0026#34;, output_file_prefix, i + 1, output_file_suffix); let output_f = OpenOptions::new() .write(true) .create(true) .open(output_file_name.as_str()) .expect(format!(\u0026#34;can\u0026#39;t open file[{}] with write option\u0026#34;, output_file_name).as_str()); files.push(output_f); } return files; } ちょっと長いですね。\n入力としては、分割するファイル数Nが指定されます。まずは、総行数/Nで各ファイルに保存されるべき行数を計算します。 次に、2つ目の関数をつかって、必要な数のファイルオブジェクトをベクトルとして生成します。\nファイルオブジェクトのベクトルの要素を元にしたfor文を回しつつ、それぞれのファイルに必要な行数を出力している処理になっています。\n総行数がNで割り切れない場合にceilで切り上げした行数にするというちょっとした処理を入れてあります。\n17. １列目の文字列の異なり pub fn count_uniq_words(input_file_name: \u0026amp;str, col: usize) -\u0026gt; usize { let mut words = HashSet::new(); let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); buf.lines().for_each(|line| match line { Ok(line_str) =\u0026gt; { let columns: Vec\u0026lt;_\u0026gt; = line_str.split(\u0026#39;\\t\u0026#39;).collect(); words.insert(columns[col].to_string()); } Err(_) =\u0026gt; panic!(\u0026#34;parse error \u0026#34;), }); return words.len(); } HashSetを利用することでユニーク性を担保して、最後はHashSetの数を数え上げれば終了です。\n18. 各行を3コラム目の数値の降順にソート pub fn sort_on_col3(input_file_name: \u0026amp;str) -\u0026gt; String { let mut lines: BTreeSet\u0026lt;Line\u0026gt; = BTreeSet::new(); let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); buf.lines().for_each(|line| match line { Ok(line_str) =\u0026gt; { let columns: Vec\u0026lt;_\u0026gt; = line_str.split(\u0026#39;\\t\u0026#39;).collect(); let num: u32 = columns[2].parse().expect(\u0026#34;parse error\u0026#34;); let line = Line { line: line_str, num, }; lines.insert(line); } Err(_) =\u0026gt; panic!(\u0026#34;parse error\u0026#34;), }); let mut sorted = String::new(); lines.iter().for_each(|line| { sorted.push_str(format!(\u0026#34;{}\\n\u0026#34;, line.line).as_str()); }); return sorted; } #[derive(Eq)] struct Line { line: String, num: u32, } impl Ord for Line { fn cmp(\u0026amp;self, other: \u0026amp;Self) -\u0026gt; Ordering { let ord = other.num.cmp(\u0026amp;self.num); if let Ordering::Equal = ord { other.line.cmp(\u0026amp;self.line) } else { ord } } } impl PartialOrd for Line { fn partial_cmp(\u0026amp;self, other: \u0026amp;Self) -\u0026gt; Option\u0026lt;Ordering\u0026gt; { Some(self.cmp(other)) } } impl PartialEq for Line { fn eq(\u0026amp;self, other: \u0026amp;Self) -\u0026gt; bool { self.eq(other) } } Lineという、行の文章と第3カラム目の値をもった構造体を作成しました。そこにEq、Ord、PartialOrd、PartialEqを実装し、3カラム目での大小比較できるようにしました。 この構造体をBTeeSetに格納していき、イテレーターで回すことで、ソートされた状態にしてあります。 同一数値の場合は行の降順でソートできるようにOrdを実装してあります。\n19. 各行の1コラム目の文字列の出現頻度を求め，出現頻度の高い順に並べる pub fn sort_on_frequency(input_file_name: \u0026amp;str) -\u0026gt; String { let mut names: HashMap\u0026lt;String, u32\u0026gt; = HashMap::new(); let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); buf.lines().for_each(|line| match line { Ok(line_str) =\u0026gt; { let columns: Vec\u0026lt;_\u0026gt; = line_str.split(\u0026#39;\\t\u0026#39;).collect(); let name_str = columns[0].to_string(); let count = names.entry(name_str).or_insert(0); *count += 1; } Err(_) =\u0026gt; panic!(\u0026#34;parse error\u0026#34;), }); let mut sorted = String::new(); let mut sorted_names: Vec\u0026lt;(\u0026amp;String, \u0026amp;u32)\u0026gt; = names.iter().collect(); sorted_names.sort_by(|(aname, acount), (bname, bcount)| { let ord = bcount.cmp(acount); if let Ordering::Equal = ord { bname.cmp(aname) } else { ord } }); sorted_names.iter().for_each(|(name, count)| { sorted.push_str(format!(\u0026#34;{} {}\\n\u0026#34;, count, name).as_str()); }); return sorted; } もうすこしうまくできる気がしますが、いったんこれで。 数え上げのためにまずはHashMapに第1カラムの文字列, 個数という組み合わせでデータを入れていきます。 出来上がったHashMapをタプルのベクターに変換し、変換したベクターのsort_byメソッドに比較用の関数を渡すことで個数の降順に並べています。同一個数の場合は文字列の降順になっています。 で、最後に並びかわったベクターのイテレーターを使って出力しておしまいです。 内部的には最悪3回回る感じでしょうか? 最初からベクトルに入れつつソートできる仕組みにするようなのがいいのかなぁ?\nまとめ Unixコマンドの勉強になりましたw あとは、HashMapなどの勉強にもなりました。 最後の方は効率がいまいち良くない気もしてはいますが、とりあえず第3章に進もうかと思います。\n","date":1589253809,"dir":"post/2020/","id":"09155bf417a93847b538ad607f78cca2","lang":"ja","lastmod":1589253809,"permalink":"https://blog.johtani.info/blog/2020/05/12/reboot-nlp100-ch02-12to19/","publishdate":"2020-05-12T12:23:29+09:00","summary":"Rustで言語処理100本ノックの第2章の残りです。 前回はこちら。 ちなみに、標準入力から受け取る処理は書いてないです。 出力に関してはファイル","tags":["Rust","nlp100"],"title":"第2章の12から19まで(言語処理100本ノック2020)"},{"contents":"気づいたら1ヶ月サボってました、ごめんなさい。。。\nRustで言語処理100本ノックの第2章をはじめました。\n前回はこちら。\n確認用のUnixコマンド 確認用のファイルを先に生成して置きました。 これで、Rustでコードを書いて、作成済みの確認ファイルを元にassert_eq!でチェックするという方式を取ろうかと。\nで、コマンド群はこちらです。\nUnix/Linuxコマンド、昔から使っています。が、なにかちょっとした文字列処理やファイル処理をやるときは、Javaのプログラム(最近だとPython)を書くというのが基本になってるので、結構、使ったことの無いコマンドが今回ありました。使ったことがなかったのはこちらです。\nsed tr expand paste cut split sedとかは普通さわってるだろ?って思われそうですね。。。\nで、コマンドをmanで調べつつやりました、macOS上で。 これがまたいくつか罠があったので書き残しておきます(自分が知らないだけかもしれないので、おかしいところがあったらツッコミお願いします。)。\nsedコマンドでのタブの扱い ## sed command for macOS. If using Linux, use \u0026#34;\\t\u0026#34; for tab character cat $INPUT_FILE_NAME | sed -e \u0026#39;s/\t/ /g\u0026#39; \u0026gt; $OUTPUT_DIR/11_sed.txt \\tで行けると思ったのですが、うまく動きませんでした。\u0026lt;tab\u0026gt;みたいな書き方もあると思うのですが、これも駄目で、結局タブ文字をそのまま打ち込みました。。。 これ、めんどくさくないですか??? ちなみに、ターミナルで動作確認して、GitHubにあげてあるシェルファイルにコピペしてたのですが、CLionに貼り付けたらタブ文字がスペースに変換されてしまってて20分くらい悩みました。。。\nsplitコマンドに-nオプションがない LINES=`cat $OUTPUT_DIR/10.txt` SPLIT_LINES=`echo $LINES/$N | bc` split -a 1 -l $SPLIT_LINES $INPUT_FILE_NAME $OUTPUT_DIR/16_ splitコマンドについてググると、-nで指定した数のファイルに分割できるという記事がいくつも出てくるのですが、man splitをターミナル上でやるとそんなオプションがないと。。。 macOSがBSD系だからっぽいです。 ということで、行数を元に、指定した数(N)で行数を割ってから、指定行数ごとにファイルを分割する方式にしました。\nこれらのコマンドの違いはHomebrewとかでインストールするとなくなるのかなぁ?(めんどくさいので確認してないですが。。。)\nってことで、2章のそれぞれの課題の正解ファイルの生成はこれでできたはずです。\n10. 行数のカウント wc -lですね。\n// ch02-10 行数のカウント pub fn word_count(file_name: \u0026amp;str) -\u0026gt; usize { let f = File::open(file_name).expect(\u0026#34;file not found\u0026#34;); let buf = BufReader::new(f); return buf.lines().count(); } ファイルを読み込んで行数を数えます。 文字列として読み込んで改行コードの数を数えるというのもありかな?と思いましたが、RustのBufReaderにlines()という行のイテレータ?が取れることがわかったので、それでカウントを取りました。\n11. タブをスペースに置換 // ch02-11 タブをスペースに置換 pub fn tab_2_space(file_name: \u0026amp;str) -\u0026gt; String { let mut f = File::open(file_name).expect(\u0026#34;file not found\u0026#34;); let mut contents= String::new(); f.read_to_string(\u0026amp;mut contents).expect(\u0026#34;read error\u0026#34;); return contents.replace(\u0026#34;\\t\u0026#34;, \u0026#34; \u0026#34;); } こっちはファイル全体を文字列に読み込んでしまってから、文字列のreplaceで置換するという方式です。 ファイルが大きい場合にこれでいいのか?という問題がある気がしますが、まずはこの実装にしました。 やるとしたら、readメソッドとbufferを用意して、少しずつ読みながら、置換して吐き出す感じでしょうか? ちゃんとした文字コードの区切りで取れるかどうかを気にしないと行けないと思うので、思ったよりはめんどくさくなりそう。\nBufReaderをつかってread_lineのほうがましかも?\nまとめ ということで、サボっていたのを再開しました。 Rustのコードを書く前に、Unixコマンドの処理に結構悩みましたw\nRustのコードとしてはファイル処理なので、今後も役立つ気がしてます。 ということで、頑張っていくぞと。\n","date":1588948640,"dir":"post/2020/","id":"c098c6f0901979bd914ed7a345200f90","lang":"ja","lastmod":1588948640,"permalink":"https://blog.johtani.info/blog/2020/05/08/rebootnlp100-ch02-10to11/","publishdate":"2020-05-08T23:37:20+09:00","summary":"気づいたら1ヶ月サボってました、ごめんなさい。。。 Rustで言語処理100本ノックの第2章をはじめました。 前回はこちら。 確認用のUnixコマ","tags":["Rust","nlp100"],"title":"第2章の10から11まで(言語処理100本ノック2020)"},{"contents":"Rustで言語処理100本ノックのリファクタリングの続き。\n前回はこちら。\nとっくに終わってたのに、ブログ書いてなかった。。。\n08. 暗号文 pub fn cipher(text: \u0026amp;str) -\u0026gt; String { return String::from_iter(text.chars().map(|x| { if x.is_ascii_alphanumeric() \u0026amp;\u0026amp; x.is_lowercase() { let mut b = [0; 4]; x.encode_utf8(\u0026amp;mut b); b[0] = 219 - b[0]; char::from(b[0]) } else { x } })); } Rustの文字列はUTF-8でエンコードされたテキストを保持しているので、文字コード自体は意識していないです。 chars()でUnicodeスカラー値のイテレータが返ってくるので、1文字ずつ扱えるようになります。\nただ、1文字をバイトとして扱うのに手こずりました。 encode_utf8というメソッドを利用して1バイトだけ取り出して、計算するというのをやっています。 文字種の判別のメソッドが用意されているのは便利ですね。\nなんかもうちょっとスマートにできないのかな?と思いつつ動いたのでこれになってます。\n09. Typoglycemia pub fn typoglycemia(text: \u0026amp;str) -\u0026gt; String { return text .split_whitespace() .map(|word| { if word.len() \u0026lt;= 4 { word.to_string() } else { let original = word.chars().collect::\u0026lt;Vec\u0026lt;char\u0026gt;\u0026gt;(); let first = original.get(0).unwrap(); let last = original.last().unwrap(); let mut typo = original[1..original.len() - 1] .iter() .map(|x| x.clone()) .collect::\u0026lt;Vec\u0026lt;char\u0026gt;\u0026gt;(); let mut rng = thread_rng(); typo.shuffle(\u0026amp;mut rng); let mut typo = String::from_iter(typo.iter()); typo.insert(0, first.clone()); typo.push(last.clone()); typo } }) .collect::\u0026lt;Vec\u0026lt;String\u0026gt;\u0026gt;() .join(\u0026#34; \u0026#34;); } 一応、1行で記述できたかな? まずは、スペースで単語ごとに区切った後に、word(単語)の長さによって、処理を分岐し、単語が5文字以上の場合にランダムに並び替えを行うというのをやっています。 文字単位で処理を行うために、chars()で1文字ずつ取り出しています。 最初と最後の文字だけはそのままに、間の文字をランダムにシャッフルするというのをやるのに、もとのwordのスライスからコピーした文字列を作り出してから組み立て直すということをやっています。\nコピーしないでゴニョゴニョする方法ってあるのかなぁ? 思いつかなかったので、結構泥臭い感じの実装になってしまいました。\nまとめ めんどくさいので、コードをGitHubのソースコードからではなく、ブログにコードスニペットとしてコピペしました。Hugoでいい感じにGitHubのコードスニペット表示するのないかなぁ?\nということで、2年越しで1章が終了しました。 2章もやらないとなぁ。\n","date":1588923657,"dir":"post/2020/","id":"2c3270f8797ace2fb37402ea6a09d126","lang":"ja","lastmod":1588923657,"permalink":"https://blog.johtani.info/blog/2020/05/08/reboot-nlp100-finish-ch01/","publishdate":"2020-05-08T16:40:57+09:00","summary":"Rustで言語処理100本ノックのリファクタリングの続き。 前回はこちら。 とっくに終わってたのに、ブログ書いてなかった。。。 08. 暗号文 pub fn cipher(text: \u0026amp;str) -\u0026gt;","tags":["Rust","nlp100"],"title":"第1章の08から09まで(言語処理100本ノック2020)"},{"contents":"前回はWorkplace Searchの概要について書きましたが、今回はインストールと構成要素について説明します。なお、2020/5/7時点での情報を元に本記事は書いていますのでご注意ください。基本的にはインストールと起動方法についての手順を元に書いています。所々に考察を挟んだ形の記事になっていますので、気になるところだけ呼んでいただければと。\n記事一覧 ElasticのWorkplace Searchを触ってみる - その1 インストール インストール方法は公式リファレンスもしくはダウンロードページに記載があります。 現時点ではMacもしくはLinuxが対象でWindowsはまだサポート対象外となっています。\n必要なもの インストールに必要なものは以下になります。\nElasticsearch 7.6.x + Platinum license Elastic CloudのElasticsearch Service もしくは ダウンロードしてローカルで起動 enterprise-search-7.6.0.tar.gz ダウンロードページはこちら Java 8もしくは11 Long Term Supportの対象であるJavaです。2020/5/7時点では8か11 今回はローカルにElasticsearchの7.6.2をインストールしてから試してみます。30日間のトライアルライセンスが有効になっているので、Platinumの機能を試すことができます。\nJavaの8か11が必要になります。Elasticsearchには7.xからJDKが同梱されるようになりましたが、Workplace SearchがJettyを元に動作しているからです(enterprise-search-7.6.0.tar.gzにjettyというフォルダあり)。\nインストール手順 大まかには以下の3つです。\nJava 8もしくは11のインストール 14でも大丈夫でした(ローカルにはSDKMANでインストールした14.0.1が利用された)。 Elasticsearchのインストール(Elastic Cloudの場合はクラスタの起動) 今回はローカルにインストール Workplace Searchのインストール Javaはもともとインストールされていたので、今回は2と3をインストールしました。どちらもローカルで起動するので、2つをダウンロードしてtar.gzファイルを展開するだけになります。\n起動方法と設定 起動方法に起動前の設定の手順も記載があります。 設定しながら起動していきます。\nElasticsearchの起動 既存のElasticsearchのクラスターがあり、Platinumのライセンスが有効になっている場合はこの手順は必要ありません。\nElasticsearchの設定ファイルでSecurity機能をオンに 7.1から基本的なセキュリティ機能はベーシックの機能に含まれています。 Elasticsearchを起動 まずは起動(パスワードなどを設定するために必要) Elasticsearchのパスワードの設定 Elasticsearchでデフォルトで用意されているユーザーのパスワードを設定してします。手順では自動で生成させる方法ですが、独自に設定することも可能です。 Workplace Searchの起動 Elasticsearchが起動したらWorkplace Searchの設定をして起動します。\nEsへの接続設定をconfig/enterprise-search.ymlに指定 Esのパスワード設定時に生成されたelasticというユーザーのパスワードをここで指定。 yamlファイルに記載があるが、${ELASTICSEARCH_PASSWORD:changeme}という記述をした場合に環境変数を読み込める allow_es_settings_modification: trueをconfig/enterprise-search.yml ここに記載があるような変更をWorkplace SearchがEsのクラスターに対して実行する模様。Workplace Search以外でも使用しているElasticsearchクラスターの場合はallow_es_settings_modificationを有効にする代わりに、リンク先にあるような設定を自分で追加する。 secret_management.encryption_keysを複数設定 Encryption Keysのガイドに少し詳しい説明がある。 opensslコマンドとかで作ればいいかな?? 1.と同じような設定をしようとしたがうまくいかなかったので、ファイルにキーを設定する方式にしました(バグ?) 起動するときにデフォルトユーザーパスワードを指定 指定しなければ勝手に生成してコンソールに出力してくれるので、そちらの方がいいかと。 今回は手順通りに指定した。 起動確認のためhttp://localhost:3002にアクセス 起動するとログが流れ、問題がなければ次のようにデフォルトユーザーの情報が出力されます。\n######################################################### *** Default user credentials have been setup. These are only printed once, so please ensure they are recorded. *** username: enterprise_search password: pas...ple ######################################################### そして無事起動に成功したことも出力されます。\n######################################################### Success! Elastic Workplace Search is starting successfully. In a few moments, you\u0026#39;ll be able to login at the following address: * URL: http://localhost:3002 * If this is your first time starting Workplace Search, check the console output above for your user authentication credentials. * Visit the documentation: https://swiftype.com/documentation/enterprise-search Secret session key has been generated. Set the key in your config file to persist user sessions through process restarts: secret_session_key: c23...3 ######################################################### ブラウザで画面にアクセスすると、次のような画面が表示されました。\n起動時のエラー いくつかのパターンも試してどんなエラーが出るのかを見てみました。 おまけですね。\nElasticsearchが見つからないエラー Esを起動しないでWorkplace Searchを起動してみました。\n200秒間アクセスしようと試みて駄目だったらエラーで終了みたいです。\n[2020-05-07T03:48:33.645+00:00][13709][2002][app-server][INFO]: Failed to connect to Elasticsearch backend. Make sure it is running. ... [2020-05-07T03:51:54.038+00:00][13709][2002][app-server][INFO]: Could not connect to Elasticsearch backend after 200s. Terminating... [2020-05-07T03:51:54.039+00:00][13709][2002][app-server][ERROR]: -------------------------------------------------------------------------------- Error: Workplace Search is unable to connect to Elasticsearch. Ensure a healthy Elasticsearch cluster is running at http://127.0.0.1:9200 for user elastic. -------------------------------------------------------------------------------- ElasticsearchのSecurityがオフのときのエラー ちなみにSecurityをオフにしたままWorkplace Searchを起動した場合は以下のようなエラーが出ました。\n[2020-05-07T03:46:53.474+00:00][13567][2002][app-server][ERROR]: -------------------------------------------------------------------------------- Elastic Workplace Search requires Elasticsearch security features to be enabled. Please enable Elasticsearch security features as outlined here: https://www.elastic.co/guide/en/workplace-search/current/workplace-search-install.html -------------------------------------------------------------------------------- 構成要素 ここまでインストールして起動してきました。 では、Workplace Searchがどういったコンポーネントから構成されているかを予測してみましょう(あくまで外から見た予想となります。そのうちElastic社のウェビナーとかイベントで内部の発表とかあるかも?)。\nインストールページの記載から インストールページに最小ハードウェアという記載があり、そこで何が動く可能性があるかというのがわかります。\n起動するものはこんな感じみたいです。\nElasticsearch - 外部でもOK App Server - Workplace SearchのWeb機能 Worker - クローラーとかかな? Filebeat - Workplace Searchのログ収集用 その他プロセス - なんだろ? という具合です。\n設定などからの予想 次は設定項目や起動時のログなどからの予想です。\nWorklpace Search配下のセキュアなデータストア - アクセストークンなどの管理のため JRubyアプリケーション - App ServerはJRuby上で動いているRailsアプリ Filebeatも起動している - Workplace Searchのログ収集のため? Filebeatの接続設定はWorkplace Searchの設定値を利用 では構成要素は? ということで、現時点でわかった構成要素は以下のとおりです。\nElasticsearch Workplace Search App Server - Railsアプリ on JRuby Webアプリとは別に(内部?で)、いくつかのワーカーが存在する 管理画面と検索画面の2種類が存在 Filebeat - ログ収集 といった感じです。 まだ起動したばかりなのでこのくらいでしょうか。ログを見るともう少しわかりそうな気がします。\n基本的には、EsをバックエンドにしたRailsのミドルウェアになります。コネクターや検索画面はすべてWorkplace Searchのミドルウェア経由でアクセスする形になりますので、普通に検索で利用するユーザーにはElasticsearchの存在は見えない作りになっています。\n次は? Getting Startedを元に、どんなアクターがいて、どんな機能が提供されているのか、どんな利用方法なのか?というのを見ていこうと思います。\n","date":1588818770,"dir":"post/2020/","id":"44db1f1fefc97cd28d55d443f2bd2b63","lang":"ja","lastmod":1588818770,"permalink":"https://blog.johtani.info/blog/2020/05/07/install-workplace-search/","publishdate":"2020-05-07T11:32:50+09:00","summary":"前回はWorkplace Searchの概要について書きましたが、今回はインストールと構成要素について説明します。なお、2020/5/7時点で","tags":["elasticsearch","workplace search"],"title":"ElasticのWorkplace Searchを触ってみる - その2 - インストールと起動"},{"contents":"2月のElastic社のブログですが、Enterprise Searchとこれまで呼んでいた製品をWorkplace Searchという製品名に変更し、App Searchなどを含む製品群をEnterprise Searchという名前に変更しました(ちょっとややこしい)。 Workplace Search自体はまだβ版という位置づけですが、ダウンロードして試すことが可能です。\nきちんと触ったことがないので、ちょっと触って見ようかなと思い、何回かに分けてブログを書いてみます。まずは概要とかから。\nWorkplace Searchとは? Elasticsearchをバックエンドに利用するElastic社が提供するアプリケーション(ミドルウェア?)の1つです。\nもともとはSwiftypeという会社が作っていた、Site Search、App Searchと同じような系列で開発されている統合検索の検索エンジンミドルウェアという感じです。 製品ページを見るとわかりますが、様々なデータソースから、データをクロールしてElasticsearchに保存することで、統合された検索を提供することができるようになる製品です。 最近は会社のドキュメントがさまざまな場所(Google Drive、Saleseforce、GitHub、Dropboxなど)に保存されています。 それぞれで検索窓などはありますが、1箇所で検索することで横断的に検索でき、仕事の効率があがりますよね?ということで作られている製品です。\n提供(利用)方法は? 今後の提供方法としては、Elastic Cloudで利用できるSaaS形式のものと、独自に(クラウドのコンピューティングエンジンやオンプレのサーバーなどで)Workplace Searchのアプリを起動する方法(オンプレ版)があります。後者の場合は、Elasticsearchのクラスターを用意する必要があります。なお、後者の場合、Elasticsearchのサブスクリプションのプラチナライセンスが必要になるようです(ダウンロードページに記載あり)\nまだ、β版という位置づけなので、今後どのように変更されるかはわかりませんが、今回は2020年5月1日時点でのベータ版(7.6.0)を元にどんなものかを紹介します。現時点で利用できるのはβ版のオンプレ版で、MacやLinuxで利用可能です。\nダウンロードとインストール ダウンロードページにインストール方法などの記載があります。\nインストールして触って見るところはまた後日。\nライセンス、価格は? まだ不明です。SaaS版の提供はまだです。 オンプレ版については少なくとも、Elasticのサブスクリプションのプラチナが必要になります。こちらは、価格は公開されていません。Elastich社もしくはパートナー企業での問い合わせが必要になります。 (たぶん、ドキュメントレベルのセキュリティとかSSOとかの仕組みがプラチナで提供されているのでそのあたりを使っているのでは?と想像してます。)\n想定できそうな用途は? 社内の文書検索でしょうか。ただ、いわゆる昔ながらのエンタープライズサーチと呼ばれている、社内のファイルサーバーなどの文書検索ではなく、クラウドサービスを複数利用している会社が利用する想定になっています。\n例えば、開発者は社内Wiki(Confluence)で社内文書を書き、Issue管理にはJIRAやGitHubを活用しており、ただ、社内での説明にはGoogle Driveを利用しているといった場合です。こういう場合、あの機能についての説明や資料ってどこだっけ?というので、あちこち探し回ったりしないといけないです。また、営業部門やサポート、マーケティングなどが絡んでくると更に、SalesforceやZendeskといったデータソースも出てきます。 情報が散らばっていて、それらを探し出したりまとめるだけで時間を取られている場合などに便利かもしれません。\n次は? 実際にインストールしてから起動して、どんな感じで使えるのかといったところを見て、どんな機能が提供されているのかを見ていこうと思います。\n","date":1588318144,"dir":"post/2020/","id":"4d71d2a23c85fb7af20e8d1e8b3e0de8","lang":"ja","lastmod":1588318144,"permalink":"https://blog.johtani.info/blog/2020/05/01/intro-workplace-search/","publishdate":"2020-05-01T16:29:04+09:00","summary":"2月のElastic社のブログですが、Enterprise Searchとこれまで呼んでいた製品をWorkplace Searchという製品名に","tags":["elasticsearch","workplace search"],"title":"ElasticのWorkplace Searchを触ってみる - その1"},{"contents":"先日、Elasticsearchでのカスタム辞書の利用方法についてブログを書きました。\n辞書の設定方法について記載しましたが、今回は辞書の更新について書いていなかったので、書いてみようと思います。 ここで「辞書」としているのは、Kuromojiのユーザー辞書、Synonym Graph Token FilterのSynonym辞書(いわゆる類義語辞書)のことになります。サードパーティのAnalyzer等に関する話ではありません。\n辞書更新に関する制限事項 辞書の更新について、大原則と制限事項が存在します。\n大原則(辞書の更新=データも更新) ElasticsearchはAnalyzerが切り出した単語を元に転置インデックスを作成して、検索を行っています(この仕組みに関するスライドはこちらを参照のこと)。 Analyzerが辞書を持っている場合、その辞書を元に単語を切り出して転置インデックスに利用します。 また、検索クエリの単語に対してもこのAnalyzerの辞書が利用されます。\n辞書に新しい単語を追加するということは、その単語に関連するドキュメントも更新しないと行けないということになります。\n例えば、Kuromojiを利用していて、「グランベリーパーク」という単語「グランベリー」「パーク」という単語に分割できるような新しい単語として辞書に追加する場合を考えてみましょう。ユーザーが「グランベリー」で検索しても検索結果として出てきてほしいという場合です。\n辞書に「グランベリーパーク」を登録していない頃に登録されたドキュメントは「グランベリーパーク」という1単語として転置インデックスの見出し語を切り出します(Kuromojiはカタカナの連続している文字列については未知語として1単語にし、「名詞-一般」の品詞を付与)。\n更新前でのドキュメントのAnalyze結果\n「グランベリーパーク」「で」「ショッピング」 もし、辞書に「グランベリーパーク」を「グランベリー」「パーク」から構成される新規の単語として登録しそれを使用した場合、辞書を更新したあとから、「グランベリーパーク」という単語がAnalyzerからは出てこなくなります。\n更新後でのドキュメントのAnalyze結果\n「グランベリー」「パーク」「で」「ショッピング」 ということは、辞書更新以前のドキュメントは「グランベリーパーク」という見出し語に対して登録されているので、辞書更新以前に登録されているドキュメントは検索にヒットしなくなります。\nこのように転置インデックスを利用している検索エンジンでは、単語の区切りが変更されるような辞書の更新があった場合、最低でも影響があるドキュメントについては再登録が必要となるわけです。\nこれが大原則(辞書更新=データも更新)となります。 基本的には辞書の更新を行った場合は、ドキュメントの再インデックス(再登録)が必要となります。\nElasticsearchでの制限事項 Elasticsearchでは、辞書の更新に関して実装上の制限事項が存在しています。 内部的な実装として、ElasticsearchではAnalyzerのインスタンス(正確にはAnalyzerのFactoryのインスタンス)の生成がインデックスに関する内部のインスタンスが生成されたタイミングの1回のみとなっています。\nこのインスタンスの生成時に設定ファイル(辞書を含む)を読み込んでいます。\n言い換えると、辞書(ファイル、インデックス設定に関わらず)の読み込みは、インデックスが作られたタイミングのみということになります。 なおここで言う「インデックスが作られたタイミング」というのは、以下の2パターンです。\nインデックス新規作成時 インデックスオープン時 では、ここから辞書を更新してそれを既存のインデックスに適用する方法について説明しましょう。\n辞書の更新方法(ファイル編) 前回のブログで説明しましたが、Elasticsearch 7.4よりも古いバージョンでは、ファイルでKuromojiのユーザー辞書を設定していました。まずはこちらの方法について説明します。前提として、すでにユーザー辞書を設定したKuromoji Tokenizerがインデックスに設定されているものとします(ユーザー辞書の設定方法については公式リファレンスを御覧ください)。\n辞書ファイルに新規にエントリーを追加しただけでは、設定は読み込まれていません。新規辞書を反映させるためには以下の手順が必要となります。\n更新した辞書ファイルの配布 複数ノードでElasticsearchのクラスターを構成している場合はすべてのノードに更新した辞書ファイルを配布する必要があります。 インデックスのクローズ(公式リファレンス) 設定ファイルを再読込させるために一度インデックスをクローズします。 クローズするので、書き込み、検索などの処理を停止する必要があります。もし停止していない場合はクライアント側ではインデックスがクローズされているという旨のエラーを受け取ります(400で、index_closed_exception)。 インデックスのオープン(公式リファレンス) 設定ファイルを読み込みます。これで、新規追加された単語が読み込まれます。 再インデックス _update_by_queryを利用することで、対象のインデックスのデータを再インデックスすることができます。条件無しでAPIを呼び出すとすべてのデータが再度登録されます。 _sourceがfalseの場合は_update_by_queryは利用できません。元データをもう一度外部からElasticsearchに対して登録する必要があります。 Kibanaでの手順をGistにしてあります。手順はこちらをご覧ください。\n辞書の更新方法(インデックス設定編) ファイルの場合とは少し手順が異なります。 インデックスの設定としてユーザー辞書を登録しているため、ファイルをElasticsearchのクラスターにあるノードに配布する必要がありません。 また、辞書の設定はインデックスの設定に指定してありますが、こちらは動的に設定変更できる項目ではないため、インデックスを先にクローズする必要があります。\nインデックスのクローズ(公式リファレンス) 辞書の設定を更新するにはインデックスをクローズする必要があります。辞書の設定は動的に更新できる項目にはなっていないためです。 オープンしているインデックスで更新しようとした場合はillegal_argument_exceptionでCan't update non dynamic settings...というメッセージが返ってきます。 辞書の更新(公式リファレンス:インデックス設定の更新) user_dictionary_rulesに単語と追加します。 インデックスのオープン(公式リファレンス) 設定ファイルを読み込みます。これで、新規追加された単語が読み込まれます。 再インデックス _update_by_queryを利用することで、対象のインデックスのデータを再インデックスすることができます。条件無しでAPIを呼び出すとすべてのデータが再度登録されます。 _sourceがfalseの場合は_update_by_queryは利用できません。元データをもう一度外部からElasticsearchに対して登録する必要があります。 Kibanaでの手順をGistにしてあります。手順はこちらをご覧ください。\n第3の方法(新規インデックス作成) ここまで、インデックスのクローズ、オープンで既存のインデックスに対して辞書を更新する方法について説明しました。 ただ、残念なことにAmazon Elasticsearch ServiceではElasticsearchが提供しているすべてのAPIが利用できるわけではありません(Amazon ESの利用可能なAPIの一覧はこちら)。 (_closeは駄目だけど_openは呼べるのかな???)\nということで、新規にインデックスを作成して、新しい辞書の設定を反映したインデックスを用意し、そこにデータをコピーもしくは登録するという方法になります(Amazon ESのカスタム辞書のドキュメントに手順がありますね)。\n手順としては以下のとおりです。\n辞書の更新(用意) 新しい単語などを登録した辞書を用意します。 ファイル、インデックス設定どちらでもOKです。 ファイルの場合は、既存のファイル名とは異なるファイル名にしたほうが混乱がなくなります。 新規インデックス作成 1.で作成した辞書を元に新規インデックスを作成します。 新規インデックスにデータコピー _reindex APIを利用するとデータコピーが簡単です。sourceとdestを指定するだけです。 _sourceがfalseの場合は_update_by_queryは利用できません。元データをもう一度外部からElasticsearchに対して登録する必要があります。 アプリケーション側で新規インデックスを利用するように変更 _aliasを使用しておくと切り替えが簡単です(公式リファレンスはこのあたり)。 考慮すべき点としては、サービスを提供しながら行う場合は、3.の_reindexを実行し始めたタイミング以降の登録・更新データの扱いについてでしょうか。\nまとめ 辞書の更新に関する大原則、制限事項、手順などについて説明しました。 辞書の変更は検索に大きく影響がでます。そのあたりをきちんと考慮しながら更新しましょう。 ユーザー辞書、カスタム辞書を扱う際の参考にしていただければと。 他にもユーザー辞書で気をつけないといけないこともありますが、今日はこのあたりで。\n","date":1587951855,"dir":"post/2020/","id":"be2c49ea5816e7daa6d3b3ff45353291","lang":"ja","lastmod":1587951855,"permalink":"https://blog.johtani.info/blog/2020/04/27/note-updating-dictionary/","publishdate":"2020-04-27T10:44:15+09:00","summary":"先日、Elasticsearchでのカスタム辞書の利用方法についてブログを書きました。 辞書の設定方法について記載しましたが、今回は辞書の更新","tags":["elasticsearch"],"title":"辞書の更新についての注意点"},{"contents":"Elasticsearchで日本語を扱うときに、カスタム辞書を使いたいという要望がよくあります。 AWSのElasticsearch Serviceでカスタム辞書ファイルを読み込める機能が発表されたようです。\n実は、Elasticsearchの7.4からファイルを使用しなくても日本語のTokenizerでカスタム辞書を利用することができるようになっています。\nカスタム辞書をインデックスの設定で指定 やり方はドキュメントに記載があります。\nトークナイザーの設定をインデックスの設定に記述しますが、このときに user_dictionary_rulesという設定を利用することでカスタム辞書を指定できます。\nPUT custom_dic_sample { \u0026#34;settings\u0026#34;: { \u0026#34;index\u0026#34;: { \u0026#34;analysis\u0026#34;: { \u0026#34;tokenizer\u0026#34;: { \u0026#34;kuromoji_user_dict\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;kuromoji_tokenizer\u0026#34;, \u0026#34;mode\u0026#34;: \u0026#34;extended\u0026#34;, \u0026#34;user_dictionary_rules\u0026#34;: [ \u0026#34;グランベリーパーク,グランベリー パーク,グランベリー パーク,カスタム名詞\u0026#34;, \u0026#34;高輪ゲートウェイ,高輪 ゲートウェイ,タカナワ ゲートウェイ,カスタム名詞\u0026#34;] } }, \u0026#34;analyzer\u0026#34;: { \u0026#34;my_analyzer\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji_user_dict\u0026#34; } } } } } } 辞書の内部は\u0026quot;単語,出てきてほしい単語列(スペース区切り),読みの単語列(スペース区切り),品詞名\u0026quot;になります。配列で設定可能で、複数の単語を登録したい場合は、カンマ区切りで登録していきます(上記例では2つの単語を登録しています)。\n_analyzeを利用して設定の確認 実際に上記の設定がうまく動作するかは_analyzeのエンドポイントを利用します。\nGET custom_dic_sample/_analyze { \u0026#34;text\u0026#34;: \u0026#34;グランベリーパークがオープンしました。\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;my_analyzer\u0026#34; } 出力は以下のようになります。\n{ \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;グランベリー\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 6, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 0 }, { \u0026#34;token\u0026#34; : \u0026#34;パーク\u0026#34;, \u0026#34;start_offset\u0026#34; : 6, \u0026#34;end_offset\u0026#34; : 9, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 1 }, { \u0026#34;token\u0026#34; : \u0026#34;が\u0026#34;, \u0026#34;start_offset\u0026#34; : 9, \u0026#34;end_offset\u0026#34; : 10, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 2 }, { \u0026#34;token\u0026#34; : \u0026#34;オープン\u0026#34;, \u0026#34;start_offset\u0026#34; : 10, \u0026#34;end_offset\u0026#34; : 14, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 3 }, ...(省略) ] } ちなみに、デフォルトのkuromojiを利用した場合は、グランベリーパークが1単語として出力されます。\nGET _analyze { \u0026#34;text\u0026#34;: \u0026#34;グランベリーパークがオープンしました。\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34; } ## レスポンス { \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;グランベリーパーク\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 9, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 0 }, { \u0026#34;token\u0026#34; : \u0026#34;オープン\u0026#34;, \u0026#34;start_offset\u0026#34; : 10, \u0026#34;end_offset\u0026#34; : 14, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 2 } ] } これで、カスタム辞書を使用することでグランベリーで検索された場合に、グランベリーパークもヒットするという仕組みです。\n_analyzeはexplainというパラメータも持っており、こちらを利用することで、単語の品詞情報なども取得できます。これを使うことで、実際に設定がきちんと動作しているかの確認に利用できます。\nGET custom_dic_sample/_analyze { \u0026#34;text\u0026#34;: \u0026#34;グランベリーパークがオープンしました。\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;my_analyzer\u0026#34;, \u0026#34;explain\u0026#34;: true } ## レスポンス(一部のみ) { \u0026#34;detail\u0026#34; : { \u0026#34;custom_analyzer\u0026#34; : true, \u0026#34;charfilters\u0026#34; : [ ], \u0026#34;tokenizer\u0026#34; : { \u0026#34;name\u0026#34; : \u0026#34;kuromoji_user_dict\u0026#34;, \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;グランベリー\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 6, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 0, \u0026#34;baseForm\u0026#34; : null, \u0026#34;bytes\u0026#34; : \u0026#34;[e3 82 b0 e3 83 a9 e3 83 b3 e3 83 99 e3 83 aa e3 83 bc]\u0026#34;, \u0026#34;inflectionForm\u0026#34; : null, \u0026#34;inflectionForm (en)\u0026#34; : null, \u0026#34;inflectionType\u0026#34; : null, \u0026#34;inflectionType (en)\u0026#34; : null, \u0026#34;partOfSpeech\u0026#34; : \u0026#34;カスタム名詞\u0026#34;, \u0026#34;partOfSpeech (en)\u0026#34; : null, \u0026#34;positionLength\u0026#34; : 1, \u0026#34;pronunciation\u0026#34; : null, \u0026#34;pronunciation (en)\u0026#34; : null, \u0026#34;reading\u0026#34; : \u0026#34;グランベリー\u0026#34;, \u0026#34;reading (en)\u0026#34; : \u0026#34;guramberi\u0026#34;, \u0026#34;termFrequency\u0026#34; : 1 }, { partOfSpeechにカスタム辞書で設定したカスタム名詞が出力されていますね。 _analyzeのAPIはこのように、アナライザーの挙動の確認に非常に便利なので是非活用してみてください。\nKibanaでこのAPIを使うためのプラグインも開発していますので、こちらも合わせて利用してみてください。\n注意点 ちなみに、user_dictionaryとuser_dictionary_rulesを両方指定した場合はエラーとなります。 ファイルをベースにしつつ、追加の設定をするという使い方はできないので、注意しましょう。\nインデックスの設定で書くことにより、バックアップ・リストアは楽になるかな。ただ、クラスターステートに取り込まれるから、あまりにも巨大なカスタム辞書だと心配かなぁ。ファイルの場合はクラスターステートには取り込まれないので、そこは圧迫しない。\n\u0026mdash; Jun Ohtani (@johtani) April 22, 2020 それ以外の注意点については、別途ブログを書きました。 「辞書の更新についての注意点」、こちらも合わせてご覧ください。\nまとめ カスタム辞書をファイルではなくインデックスの設定値として設定する方法を紹介しました。こちらは、Elasticsearch 7.4で導入された機能になります。7.4以降を利用している場合はこちらを利用することも検討してはいかがでしょうか? また、_analyze APIも便利なので合わせて活用してみてください。\n","date":1587519056,"dir":"post/2020/","id":"15357b6978e83daa2d97692c861dc177","lang":"ja","lastmod":1587519056,"permalink":"https://blog.johtani.info/blog/2020/04/22/custom-dictionary-after-7-4/","publishdate":"2020-04-22T10:30:56+09:00","summary":"Elasticsearchで日本語を扱うときに、カスタム辞書を使いたいという要望がよくあります。 AWSのElasticsearch Servi","tags":["elasticsearch"],"title":"Kuromojiのカスタム辞書をインデックスの設定で指定"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 第8章 7章はパッケージなので後回しにして、8章に入ります。 8章はコレクションです。\nベクタ型 ベクタは同じ型の値だけ保持可能。 ジェネリクスで型を指定可能 - Vec\u0026lt;i32\u0026gt;とか。 vec!マクロで初期値とか設定すると便利。 ベクタに値を追加するのはpush。もちろん値が変わるので元のベクタにはmutが必要 ベクタのスコープ(ライフサイクル)は要素に対する参照があるのとないので話が変わってくる メモリの確保などの影響で、ベクタ全体に対して借用の規則が矯正されると。 ベクタの値を読むのはいくつか方法あり getメソッドはOptionを返す \u0026amp;v[2]の添字記法の場合はパニックの可能性あり 走査(唐突に参照外しが出てきた) 単純に値を取り出す場合はfor - in \u0026amp;v Enumをベクタにいれることで、異なる型も保持可能(まぁ、Enumの型では固定されるけど)。 これだけのためにEnumを使うことってあるのかな? トレイとオブジェクトに関する文章はちょっとわかりにくい。。。 説明以外のメソッドなどについてはAPIドキュメント見ましょうと(リンクも張ってくれてると嬉しいなぁと思ったり。まぁ、バージョンとかの絡みがあるから難しいか)。\n文字列型 文字列はUTF-8でエンコードされた文字を扱うための型。\nstrは文字列データへの参照。\nString型は言語のコアではなく、標準ライブラリに入っている文字列型。\n他にもあるのか。。。OsStringとか。。。 文字リテラルはDisplayトレイトを実装していると。\n.to_string() = String::from\nStringはコレクションだから追加とかが可能なのか、なるほど。\npush_strとpush\n+演算子での参照。\n\u0026amp;Stringは\u0026amp;strに型強制(キャスト?)してくれる。してくれる場合としてくれない場合もあるのかな?s2の所有権は奪わない形で扱うのでs2はこのあとも使えていると。 ここでは、s1を変更したあとに所有権がs3に持っていかれてる? format!を使うとどの所有権も奪わないので、これを使うほうが考え方は簡単そう。ただし、効率がいいかはわからん。 添字記法でのアクセスをStringは許容していない\n文字の境界が必ずしも1バイトとは限らないから。 スライスも同様。 基本的には.chars()で文字としてアクセスするのが良い。\n逆にバイト表現を得る方法はどうするんだろう?\nNLP100本ノックではencode_utf8メソッド使ったけど。 ハッシュマップ いろんな呼び方あるよね。Rustではハッシュマップだよ。 ハッシュマップはuseしないと使えない キーは1つの型、値も1つの型 タプルのベクタからcollectで生成。なるほど。 タプルのベクタだと、タプルの中身は同じものであることが言える? -\u0026gt; 言える。エレメント数が異なるとコンパイルエラーになった 所有権周りの話。 これ、ベクタのときに話してほしい感じがした。 値を渡すか参照を渡すかによって話が変わってくる。詳しくは10章 このあたりが自分が混乱していた元だ。 entryとinsertの違い entryの戻り値はEntryというenumでor_insertというメソッドがありそれを使うと存在しない場合だけinsertが呼ばれる。 これ便利だ。毎回existあたりで存在チェックしてた気がする。 or_insertは可変参照\u0026amp;mut Vを返す。 これをlet countで束縛するときに、中身が可変かどうかをcountには指定しないのか。。。 まとめ 一応、大学などで習ってた(はず)ですが、 スタックとヒープを意識して考えないといけないなぁというのを何度か意識させられた感じです。\nあと、これはRustに限らずですが、それぞれがどんな関数を持っているか、どんなメソッドを持っているか、どんなマクロが存在するかなどを探すときにみんなどうしてるんだろう? 人に教えてもらっているのか、APIリファレンスを探すのか、そういったところをみんながどういう感じにプログラミング言語を勉強しているか、業務で書いているのかと言うのが気になりました。\n","date":1587028650,"dir":"post/2020/","id":"f488aa62d39194824861a134567cadb8","lang":"ja","lastmod":1587028650,"permalink":"https://blog.johtani.info/blog/2020/04/16/chap8-rust-the-book/","publishdate":"2020-04-16T18:17:30+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 第8章 7章はパ","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第8章"},{"contents":"Rustで言語処理100本ノックのリファクタリングの続き。\n前回はこちら。\nコードも載せたほうが見やすいかなぁ?\n03. 円周率 2年前はこちら。 どちらかというとJavaっぽい書き方かな? 入れ物を用意して、入力を整形して、それからループを回す感じで書いてました。\n今回は1行で収めてみました。 Rustっぽく、returnを省略してみました。 あとは、Iteratorを組み合わせる感じでやってます。 アルファベットの文字数ということで、is_alphabetic()メソッドでfilterしてます。\n04. 元素記号 2年前はこちら。 エラー処理が多いのと、文字の扱いがちょっと\nここまで同様に極力イテレータを利用するという方針でリファクタリングしました。 あとは、エラー処理を除去してます。 正常系だけのテストなのでスッキリさせました。\nこういった、ストリーム系?の書き方の場合にエラー処理をどう入れるかってところはちょっと悩みどころになるんじゃないかなぁ?と思いつつ、イレギュラーなものは後回しで(あとにやるのかなぁ?)\n05. n-gram 2年前はこちら。 これまでと同じく、入れ物を作ってから処理をしてます。\n同じく、極力イテレータを利用する形で実装しました。 いくつか型の変換が必要なので、.map()を呼び出して詰め替えたりしています。\n06. 集合 2年前はこちら。 独自に実装しています。\nせっかく05で文字n-gramの配列を返す処理を実装しているので、 そちらを呼び出して、Setに入れるという処理に書き換えました。 その後の集合に対する処理については特にリファクタリングしてないです。\nまとめ 2年前にやってたところまでは追いつきました。 07は特にリファクタリングする必要がないので、次は08からの予定です。\nリファクタリングしているときになるのは、速度とかでしょうか。 実装の違いでなにか差が出るのかどうかはちょっと気になるところですが、 今回の目的ではないので、目をつぶって進める予定です。\n","date":1586423695,"dir":"post/2020/","id":"9a687babb0f44db51dc389b75bdaa19d","lang":"ja","lastmod":1586423695,"permalink":"https://blog.johtani.info/blog/2020/04/09/reboot-nlp100-ch01-03to05/","publishdate":"2020-04-09T18:14:55+09:00","summary":"Rustで言語処理100本ノックのリファクタリングの続き。 前回はこちら。 コードも載せたほうが見やすいかなぁ? 03. 円周率 2年前はこちら。 どちらか","tags":["Rust","nlp100"],"title":"第1章の03から06まで(言語処理100本ノック2020)"},{"contents":"今回もツイートから。\n言語処理100本ノックの2020年版を公開しました。最近の自然言語処理の研究動向を反映し、深層ニューラルネットワークに関する問題を追加しました。留学生も一緒に取り組めるように多言語化を進め、その第１弾として英訳を部分公開しています（40番以降は順次公開予定）。 https://t.co/52h362PIQQ\n\u0026mdash; Naoaki Okazaki (@chokkanorg) April 6, 2020 言語処理100本ノックが2020年版になったそうです。 そうです、2年前に初めて、準備運動で止まっていたんです!(衝撃的な続かなさ。。。)\nということで、Rust the bookも読んでいることだし、過去のプログラムをチェックしつつ再開しようかなと。 ということで、いくつかリファクタリングしてみました。\nソースはリポジトリを御覧ください。\n00. 文字列の逆順 2年前の実装では、chars()メソッドで取り出したあとに、collect()でVecにしていたのですが、RustのIteratorトレイトにrev()という便利なメソッドが存在していました。\nということで、これを取り出すと、最初の文字列の逆順で文字を取り出すIteratorが取得できます。 あとは、Stringが実装してくれているfrom_iterに渡せば文字列が出来上がります。\n01. 「パタトクカシーー」 ストリーム処理っぽい書き方に変更しました。 2年前はIteratorを取り出して、詰替していましたが、 enumerate()で添字と文字のタプルのイテレータに変換し、 filterで添字が偶数のときだけフィルタリングして、 mapで対象の文字をまとめたイテレータにします。 で、最後はそれを元に文字列を生成することにしました。 iterを使わないでそのままString::from_iterの引数に渡すことも可能ですね。\n02. 「パトカー」＋「タクシー」＝「パタトクカシーー」 2年前は2つのIteratorをloopで回して頑張って結合してました。 ではなく、zip()を使って、2つのイテレータを組み合わせる方法に替えてみました。 このとき、2つの文字列が違う文字数の場合の処理として、長い方から取り出した文字をあとに結合する処理を追加で記述しました。 ちょっとスマートな感じになりましたかね?\nzipしたあとに出てきたタプルの文字列を結合するのにformat!マクロを使いましたが、他にいい方法有るかなぁ?\nまとめ とりあえず最初の3つをリファクタリングしてみました。 残りもやりつつ、準備運動以降もがんばるぞと。\n","date":1586338425,"dir":"post/2020/","id":"dc9580308938069159c5afc55b2f3b96","lang":"ja","lastmod":1586338425,"permalink":"https://blog.johtani.info/blog/2020/04/08/reboot-nlp10-with-rust/","publishdate":"2020-04-08T18:33:45+09:00","summary":"今回もツイートから。 言語処理100本ノックの2020年版を公開しました。最近の自然言語処理の研究動向を反映し、深層ニューラルネットワークに関","tags":["Rust","nlp100"],"title":"言語処理100本ノック、再び"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 第6章 Enumです。match式に大活躍\nEnumを定義する 列挙型は取りうる値をすべて列挙できる。これが名前の由来 列挙型と列挙子 2連コロン(::)で列挙子を指定可能 列挙子にデータ(構造体も)が格納可能。 標準ライブラリに実装例あり。 疑問:Write(String)とかはタプルの表現になるのかな? と思ったが、タプルでは1つだけの変数を持つものは定義(正確には定義できるが、内部で普通の変数にもどされてるっぽい)できなかった。 メソッド定義も可能 関連関数もできる? -\u0026gt; できる Optionの紹介 Rustにnullはない。代わりにOptionがある Noneを指定する場合に型が必要。Someの場合はすでに値が入るから推測可能なため。 match制御フロー演算子 アーム -\u0026gt; matchしたときの処理のこと 短い場合は波括弧は不要 returnなしでmatchが書いてあるだけだと、慣れない場合に値を返していることに気づかないかも(実際気づけてないかも) Enumが値を持っているときに、値の束縛がmatch式で可能 すべての列挙子を網羅していないことをコンパイラが検知してくれるのはすごく助かる。 ただし、_を利用していなければだけど if letで簡潔な制御フロー enumで1つのパターンのときに処理をしたい場合に使えるmatchの糖衣構文 elseもかけるよ。 まとめ enumに慣れていないので、値や構造体を持つenumを利用するという想像ができないことがありそうだなぁと読みながら思いました。 それになれると、色々とプログラムがシンプルに書ける部分が多くなりそうかな。\n","date":1586255231,"dir":"post/2020/","id":"4fbdc9c57a37781dc5dd86f470c61d04","lang":"ja","lastmod":1586255231,"permalink":"https://blog.johtani.info/blog/2020/04/07/chap6-rust-the-book/","publishdate":"2020-04-07T19:27:11+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 第6章 Enumです。matc","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第6章"},{"contents":"Kuromoji-CLIの使い方などについては過去のブログを御覧ください。\nKuromojiのCLIコマンドとpicocliとGraalVM GitHubリポジトリ Issueだけ上げていたJSON出力対応をしました。 また、ラティス(後述)の出力対応もしました。\nJSON出力 LinderaがJSON出力に対応してるのでそれを真似しました。 -o jsonで指定していただくと、次のようなJSONが出力されます。\n% echo \u0026#34;春眠暁を覚えず\u0026#34; | build/graal/kuromoji -o json [ { \u0026#34;text\u0026#34;: \u0026#34;春眠\u0026#34;, \u0026#34;detail\u0026#34;: [ \u0026#34;名詞\u0026#34;, \u0026#34;一般\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;春眠\u0026#34;, \u0026#34;シュンミン\u0026#34;, \u0026#34;シュンミン\u0026#34; ] }, { \u0026#34;text\u0026#34;: \u0026#34;暁\u0026#34;, \u0026#34;detail\u0026#34;: [ \u0026#34;名詞\u0026#34;, \u0026#34;一般\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;暁\u0026#34;, \u0026#34;アカツキ\u0026#34;, \u0026#34;アカツキ\u0026#34; ] }, { \u0026#34;text\u0026#34;: \u0026#34;を\u0026#34;, \u0026#34;detail\u0026#34;: [ \u0026#34;助詞\u0026#34;, \u0026#34;格助詞\u0026#34;, \u0026#34;一般\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;を\u0026#34;, \u0026#34;ヲ\u0026#34;, \u0026#34;ヲ\u0026#34; ] }, { \u0026#34;text\u0026#34;: \u0026#34;覚え\u0026#34;, \u0026#34;detail\u0026#34;: [ \u0026#34;動詞\u0026#34;, \u0026#34;自立\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;一段\u0026#34;, \u0026#34;未然形\u0026#34;, \u0026#34;覚える\u0026#34;, \u0026#34;オボエ\u0026#34;, \u0026#34;オボエ\u0026#34; ] }, { \u0026#34;text\u0026#34;: \u0026#34;ず\u0026#34;, \u0026#34;detail\u0026#34;: [ \u0026#34;助動詞\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;特殊・ヌ\u0026#34;, \u0026#34;連用ニ接続\u0026#34;, \u0026#34;ぬ\u0026#34;, \u0026#34;ズ\u0026#34;, \u0026#34;ズ\u0026#34; ] } ] Viterbiラティス出力 Kuromojiが内部でトークンをどのように切り出すかを計算するためのViterbiのラティスです。これをGraphvizというツールのDOTフォーマットのファイルとして出力できるメソッドがデバッグ用ですが、Kuromojiに用意されています。 こちらを呼び出して出力するオプション-v(もしくは--viterbi)を追加しました。 注意点として、このオプションを指定すると、DOTファイルが標準出力に出力され、トークンの結果は標準エラーに出力されます。\necho \u0026#34;春眠暁を覚えず\u0026#34; | build/graal/kuromoji -v \u0026gt; viterbi.dot .dotファイル自体は画像ではないので、Graphvizのdotコマンドにて画像ファイルに変換する必要があります。\ndot -Tpng viterbi.dot -oviterbi.png これで、PNGファイルが出来上がります。出来上がったファイルはこんな感じです。\n画像を見ていただくと、緑色のパスがあるのがわかります。 こちらが、Kuromojiが実際に採用した形態素のリストです。それ以外のパスは不採用だったパスとなります。\nちなみに、macOSで1行で画像表示まで行うにはこんな感じで実行します。 openコマンドでpreviewアプリを指定することで画像が表示できます。 Windowsは。。。わかりません、すみません。\n% echo \u0026#34;春眠暁を覚えず\u0026#34; | build/graal/kuromoji -v -o json | dot -Tpng | open -f -a preview.app まとめ これ以前に複数辞書対応などもしていました。 今回は2つの出力形式を追加してみました。 特にViterbiラティス出力については、内部的にどのようなコスト計算で最終的な結果が出てきているかという理解に役立ちます。想定していない切れ方の場合は、そもそも想定している形態素になっていないか、コスト計算で不採用だったかなどを確認できますので、使ってみると面白いかもです。\n","date":1586143600,"dir":"post/2020/","id":"6fbf7c3d0f4f89e415e89cec28811a94","lang":"ja","lastmod":1586143600,"permalink":"https://blog.johtani.info/blog/2020/04/06/update-kuromoji-cli/","publishdate":"2020-04-06T12:26:40+09:00","summary":"Kuromoji-CLIの使い方などについては過去のブログを御覧ください。 KuromojiのCLIコマンドとpicocliとGraalVM G","tags":["misc"],"title":"KuromojiのCLIコマンドにJSON出力とラティス出力を追加"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 第5章 構造体です。勝手知ったるなんとやら?オブジェクト指向的な部分は問題ないかなぁと。\n定義とインスタンス化 structで定義 インスタンスの生成は引数は順不同でOK 構造体のインスタンスを可変にするとフィールドの値も変更可能 特定のフィールドのみ可変にすることは不可能 インスタンス化する関数の最後でreturnなしでインスタンスの返却を暗黙にできる(return書いてほしいな。。。) インスタンス化時にフィールド初期化省略記法が可能(これはちょっと便利?) 構造体更新記法..user1のように、明示的に設定されていない他のフィールドをコピーしてくれる機能あり タプル構造体 タプル構造体!? struct Color(i32, i32, i32); いつ使うんだろう? ユニット様構造体 ユニット様構造体 = フィールドのない構造体。トレイトを実装したいけどインスタンスで持つ値はない場合に利用 ライフタイム 構造体が参照を持つときにライフタイムという話が出てくる。なるほど。 ライフタイム指定子が必要になる -\u0026gt; 10章での話 プログラム例 タプルを引数かぁ。タプルは慣れないので構造体作りそう Debugトレイトと{:?}という書き方 derive(Debug)でデバッグ用のトレイトを自動で実装=継承してくれる {:#?}だとpretty printになる(改行とか入る) この辺の便利なトレイとは付録Cにあるらしい。この辺はやりながら覚えるしかないか。\nメソッド記法 最初の引数は必ずself implは構造体とは別の場所に書く = Javaのクラスとは違う struct Rectangle { width: u32, height: u32, } impl Rectangle { fn area(\u0026amp;self) -\u0026gt; u32 { self.width * self.height } } 参照じゃないselfも使えるらしい。どういうときに使うんだろう? 関連関数 selfなしの関数をimplにかける。Javaのスタティックメソッドみたいな感じ その他 implブロックがあちこちにかける。これはつらいな。。。 2つにわかれたimplブロックに同じメソッドを書いてみたら、CLionのプラグインではエラーを検知してもらえなかった。 cargo buildではきちんとエラーが表示された。 複数のimplブロックが有用になるケースは第10章で見ますが、そこではジェネリック型と、トレイトについて議論します。\n人の構造体に自分のトレイトを適用したりもできる。 実験 スコープとかどうなりそう?って実験もしてみた。\nfn main() { trait Hoge { fn trim(\u0026amp;self); } impl Hoge for String { fn trim(\u0026amp;self) { println!(\u0026#34;hogehoge {}\u0026#34;, \u0026amp;self); } } let c = String::from(\u0026#34;hoge\u0026#34;); c.trim(); println!(\u0026#34;{}\u0026#34;, fuga(\u0026amp;c)); } fn fuga(d: \u0026amp;String) -\u0026gt; \u0026amp;str { d.trim() } 出力はこんな感じ\nhogehoge hoge hoge まとめ 気になったのは以下の点。そのうち分かるようになってくるのかな。\n構造体更新記法はどういったときに使うのを想定して作ったんだろう?とか 可変長引数はマクロじゃないとだめ ","date":1585807758,"dir":"post/2020/","id":"8d9c3760395e8e0eb40e335b22750b68","lang":"ja","lastmod":1585807758,"permalink":"https://blog.johtani.info/blog/2020/04/02/chap5-rust-the-book/","publishdate":"2020-04-02T15:09:18+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 第5章 構造体です。勝手知ったるなんとやら?","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第5章"},{"contents":"すもけさんが在宅勤務環境をブログに書いてておもしろそうだな(あと、アフィリンク貼れるな)と思ったので自分の環境も書いてみようかなと。\n私自身は昨今の新型コロナウイルスの影響というのではなく、もう10年以上自宅でも作業ができる環境を整えています。 前前職の頃から家でも仕事をすることがよくあったので。今は、お客さんに恵まれていてリモートができる形で働かせていただいてます。\n机周りはこんな感じです。机はこれも15年以上前から使用しているエレクターの机です。椅子も15年以上前から使っているアーロンチェア(購入時は高いと思ったけど、これだけ使えているので大満足)です。\nメインのPCはMac Book Pro16インチを使っています。それとは別にMac miniがMac bookの後ろに隠れています。こっちはブラウジングや音楽を聞いたりするために使っています。\nまずはディスプレイ周りから。\nディスプレイ周り ディスプレイ Acerの31インチディスプレイです。昨年の夏に購入しました。28インチの4Kディスプレイを探していたのですが、セールか何かで2-3000円の違いでこのサイズが買えたので、このサイズになっちゃいました。Mac Book ProはDisplay port-USB-Cケーブルで接続し、PS4をHDMIで接続しています。 【Amazon.co.jp 限定】Acer モニター ディスプレイ ET322QKwmiipx 31.5インチ マイクの左側に写っているのはAppleのサンダーボルトディスプレイです。縦にしてブラウザやミュージックプレイヤーなどで音楽かけながら仕事をしています。 サブディスプレイって感じです。 Mac Book ProとMac miniの両方を操作するのですが、できれば同じキーボード+トラックパッドがいいなということで、Synergyというソフトを使って、Mac Book Proのキーボードとマウスでネットワーク越しにMac miniを操作しています。ただ、マシンの再起動後などにこのソフトが起動していない場合もあるので、Mac Book Proの右側にMac miniのためのトラックパッドがおいてあります。\nディスプレイアーム ディスプレイはそれぞれディスプレイアームを使っています。写真のようにMac Book Proを下に、外部ディスプレイを上にという上下で作業をしています。 16インチの画面だと普通のディスプレイの足だとメインディスプレイにかぶってしまうので、アームに切り替えました。 最初はグリーンハウスの激安を使っていたのですが、31インチのディスプレイだとアームの高さが足りなかったので、2つ目のガススプリング式のアームを追加で購入しました。ガススプリング式なのに5千円しないので、かなりお得感があります。ただ、ディスプレイは基本的に動かさないので、どちらかというとディスプレイの足の部分を効率良く使うことが目的です。\nAmazon | グリーンハウス 液晶ディスプレイアーム 4軸 クランプ式 Amazon | HUANUO PC モニター アーム 液晶ディスプレイ アーム ガススプリング式 サウンド関連 スピーカー 基本、音楽を聞きながら作業をするので、小型だけどしっかりと音がでるスピーカーを買いました。スタイルもいいし気に入ってます。 入力が2系統あるので、31インチディスプレイのヘッドフォン出力とMac miniのからの出力の2つをつないでいます。 仕事中はMac miniで音楽流しつつ、テレカンやゲームのときはメインディスプレイからの音が出る形です。 Amazon | ヤマハ パワードスピーカー NX-50 マイク 前職がDeveloper Advocateということで、インタビューなどに行くこともあるかも?ということで小さめのも運びができるコンデンサマイクを購入してました。結局それほど持ち運びはしてないのですが、値段の割には音がいいんじゃないかな?一応、無指向と単一指向の2種類を切り替えることが可能です。\nAmazon | SAMSON マイク ポータブル USB コンデンサ Go Mic | コンデンサ | 楽器 マイクスタンド マイクはあったのですが、クリップ式でした。PCのディスプレイにクリップしていると、打鍵音を拾ってしまうので、マイクスタンドを最近導入しました。やすかったです。 前まではヘッドフォンのケーブルに付いているマイクで喋っていたのですが、服によってはマイクに擦れてしまい、ノイズが載っていました。 マイクスタンド+スピーカーでもスピーカーの音をマイクが拾わないので、最近はヘッドフォンを使用しないで気楽に話ができるようになっています。 Amazon | Luling Arts マイクスタンド アーム その他 モニタスタンド Mac Book Proの後ろで見えにくいですが、Mac miniが下に入っていて、上にMac mini用のキーボード、スピーカー、Qiの充電パッドが載せてあります。 Mac miniのキーボードをじゃまにならないように置きたいという目的で購入しました。3次元で空間が利用できるので結構重宝してます。 Amazon | サンワサプライ 机上液晶モニタスタンド(D200・黒) MR-LC303BK 充電関連 スマホ充電用にスピーカーの横においてあります。ただ、スイートスポットを探すのがちょっと大変で、時々充電できてないことがあったりします。。。 Amazon | DesertWest Qi 急速充電ワイヤレス充電器 【Qi認証済み/PSEマーク付き】15W USBでの様々な充電用にはMercariさんのカンファレンスでいただいたAnkerの充電器をおいてあります。Mi Band 4、キーボードなどの充電向けです。 Amazon | Anker PowerPort 6(60W 6ポート USB急速充電器) まとめ 簡単ですが作業環境でした。だいたい満足しています。もうちょっと改善したいなと思っているのは次の点です。\nUSB-Cドック?ハブ?みたいなものがほしい 充電ケーブル、マイク、ディスプレイケーブル、有線LANの4つのケーブルがMac Book Proに刺さっており、ポートが全滅です。出先から帰ったときにつなぐのも少し面倒なので、1つか2つのポートでまとめられるといいなぁと思っています。が、ドック系はいい値段するのでまだ置き換わっていない感じです。 スタンディングデスクが気になる 自宅でずっと座っているのはやはり気になるもので。スタンディングデスクにして時々たって作業したいなぁと思うことがあります。ただ、使ったことがないので、どれがいいのかわからず手を出せない状況です。 ウェブカメラいる? Mac Book Proのカメラでオンラインミーティングなどしています。気にするほどのことではないとは思いますが、メインディスプレイを見ながらしゃべると下からカメラで撮影されている形になります。。。 今のところはこんな形です。なにかの参考になればと。 あと、なにかおすすめのもの(特にスタンディングデスク)があれば教えて下さい!\n","date":1585217511,"dir":"post/2020/","id":"3f431bf71ee866f626daf42bc915fa3f","lang":"ja","lastmod":1585217511,"permalink":"https://blog.johtani.info/blog/2020/03/26/working-facility/","publishdate":"2020-03-26T19:11:51+09:00","summary":"すもけさんが在宅勤務環境をブログに書いてておもしろそうだな(あと、アフィリンク貼れるな)と思ったので自分の環境も書いてみようかなと。 私自身は","tags":["misc"],"title":"自宅の作業環境(2020)"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた 第4章 第4章です。たぶん、これがいちばん大事な概念だと思います、Rustの。 そして、つまみ食いしながらRust書いてましたが、ここがきちんと理解できないまま書いてたってのもあります。。。\n所有権とは? drop関数ってのがあって、明示的に呼ぶことも可能。次のような感じで。2つ目のprintln!はエラーになる。sがもう無いのに借用しようとしてるから。 fn main() { let mut s = String::from(\u0026#34;hello\u0026#34;); s.push_str(\u0026#34;, world!\u0026#34;); println!(\u0026#34;{}\u0026#34;, s); drop(s); println!(\u0026#34;{}\u0026#34;, s); } ムーブ - shallow copyではない。以下の2行目がムーブ。 let s1 = String::from(\u0026#34;hello\u0026#34;); let s2 = s1; println!(\u0026#34;{}, world!\u0026#34;, s1); スタックとヒープの話が絡んでくる。あんまり意識すること無いよなぁ。 スタック = 固定長のデータを入れる場所。ポインタ、数値など ヒープ = 可変長のデータが入る場所。可変の文字列とか。\nクローン - ヒープのデータをコピーすること。 コピー - スタックに収まるデータの場合はクローンが必要なくコピーで事足りる。 CopyトレイととDropトレイとは同居できない。 タプルのコピーはややこしそう 所有権と関数でまた、スタックに入れられるような変数と可変のオブジェクトの違いが出てくる。 takes_ownership(s: String)が参照を受け取れば問題なく、このあとも使える。 戻り値でもムーブが発生 参照と借用 借用 - 関数の引数に参照を取ること 可変な参照\u0026amp;mutは1つ(不変な参照も含めて1つ)しか許さない データの競合を防ぐため。 不変な参照を複数用いるのはOK 実際に変更が実行されるタイミングでエラーと判定される場合もある。 let mut s = String::from(\u0026#34;hello\u0026#34;); { let r1 = \u0026amp;mut s; } // r1はここでスコープを抜けるので、問題なく新しい参照を作ることができる let r2 = \u0026amp;mut s; ダングリング参照はテスト書くときとかにやってるかも。。。 fn dangle() -\u0026gt; \u0026amp;String { // dangleはStringへの参照を返す let s = String::from(\u0026#34;hello\u0026#34;); // sは新しいString \u0026amp;s // String sへの参照を返す } // ここで、sはスコープを抜け、ドロップされる。そのメモリは消される。 // 危険だ スライス型 部分的な参照。開始位置+長さで構成されているっぽい \u0026amp;strの説明がよくわからなかった。 引数としての文字列スライスのテクニックは色々と使いまわせそう。\nまとめ 所有権、これまで特に難しいと思ってたのは、固定長の変数と、可変長の変数の違いを意識してなかったのが原因っぽい。 まぁ、Vecとかがどうなるのかとか、他にもいくつか気になるところはあるので、もうちょっとやらないといけないなと思いました。\n","date":1585210331,"dir":"post/2020/","id":"7fded0345c258eea966c0b5ee1b7c7aa","lang":"ja","lastmod":1585210331,"permalink":"https://blog.johtani.info/blog/2020/03/26/chap4-rust-the-book/","publishdate":"2020-03-26T17:12:11+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた 第4章 第4章です。たぶん、これがいちばん大事な概念だと思","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第4章"},{"contents":"先日、Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)というブログを書きました。 このプラグインを作ってたタイミングで、Elasticの河村さん経由で、Microsoft Open Tech Night #9 w/ ElasticでなにかLTしませんか?という打診がありました。\n仕組み的には似たようなものだし、Elasticsearch用の拡張機能も作れるし、発表のネタにもなるし一石二鳥では?ということで、LTを快諾し、昨日発表してきました。\n資料とか 発表資料やGitHubのリポジトリなどは、以下のとおりです。\n発表資料 : Analyze APIのVS Codeプラグインを作ってみた GitHub Repository : https://github.com/johtani/vs-code-es-analyze-client Visual Studio Code Marketplaceページ 機能 まだ、必要最低限の機能を実装した感じです。\nAnalyze APIのパラメータ入力用のエディタ起動(Elasticsearch Analyze Client: Create Elasticsearch Analyze Request) Esにリクエストを送信して結果の表示 インストールからリクエスト送信して結果が出てくるまでのデモです。\n1点LTのデモのときに話すのを忘れていましたが、.esanalyzeという拡張子のファイルであれば、このプラグインが入力値を見つけ出して、「Analyze text with analyzers」というコマンド送信用のリンクをエディタ画面に表示する機能があります。 ですので、パラメータ入力用のエディタを起動し、値を設定したあとにファイルをhoge.esanalyzeというような名前で保存してもらえれば、後日そのファイルを開くことでリクエストが再送できます。\nAzure Search版との機能の違い 先日のAzure Search向けのクライアントとの違いがいくつかあります。 ElasticsearchのAnalyze APIの方が多機能であるため、プラグインとしても違いがあったほうがいいかなと。\n入力がJSON形式 結果画面に詳細表示切り替えボタンを追加 現時点では対応していませんが、Analyze APIはカスタムのtokenizer、filter、char_filterの設定を入力として受け付けることが可能です。そのときに指定するのはJSON形式でtokenizerなどの設定を記述します。 今後、これらの対応をすることを考えると、入力全体をJSON形式で読み込めるほうがわかりやすいかなということで、入力はJSON形式で入力してもらうことを想定しました。\n結果画面に詳細表示切り替えボタンを追加したのは、2つの理由があります。1つはAzure SearchのAnalyze APIよりもTokenの情報としていくつか他の情報も存在するためです。複数のAnalyzerとの比較をする場合は、単語列だけを比較したいですが、Analyzer個別の詳細情報を見たい場合もあるので、切り替えができたほうがよいかなと。 2つ目の理由はまだ実装していませんが、explainパラメータの出力への対応のためです。 explainパラメータを指定すると、カスタムAnalyzerの場合に、Analyzerの設定にあるchar_filter、tokenizer、token_filterのそれぞれのステップでの単語列の出力が結果として返ってきます。この結果には標準の出力よりもさらに多くのtokenの情報(例えば、kuromojiだと品詞情報、読み、原型など)が追加されてきます。これらの表示を切り替えることができたほうがよいかと。\nこれらは、実はKibanaのプラグインとしてすでに実装済みになっています。 同等の機能は実装できるかなという目論見もあり、そちらに合わせた感じにしてあります。\n今後の対応 現時点では、Analyzer名の指定のみが可能となっています。Kibanaのプラグインと同程度の機能はGitHubのIssueとして登録してみました。\nexplainパラメータ対応 fieldパラメータ対応 custom analyzer対応 その他に、インデックス名やアナライザ名の自動補完みたいな機能があると便利かも?と妄想していたりします(実装が大変かもですが。。。)。Kibanaのプラグインの場合は、Mappingやインデックス名を調べるときに、KibanaのConsoleからチェックすればよかったのですが、このプラグイン単体だとそのあたりの情報の取得に他のツール(Kibanaだったり、REST API Clientだったり)を使わないといけないという問題点はあるかなぁと。\nあとは、結果画面がこのままで本当に見やすいかどうか?なども気になってはいます。\nまとめ まだまだ、作ってみたというレベルのプラグインです。 どのくらいの人に使ってもらえるかもわかりませんが、こんな機能あるといい?など要望があればリクエストいただければと。 Twitterで聞いていただいてもいいですし、GitHubのIssueとして登録していただいても構いません。 そもそもいらないなぁなんて意見でももちろん大歓迎です。フィードバックお待ちしてます!\n","date":1585102205,"dir":"post/2020/","id":"a7f0e85fcad4f5bc5ae5c18c10de4f9e","lang":"ja","lastmod":1585102205,"permalink":"https://blog.johtani.info/blog/2020/03/25/vsc-es-analzye-plugin/","publishdate":"2020-03-25T11:10:05+09:00","summary":"先日、Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)というブログを書きました。 このプラグインを作ってたタイミン","tags":["elasticsearch","visual studio code"],"title":"ElasticsearchのAnalyze APIのVisual Studio Codeのクライアントプラグイン"},{"contents":"自転車本を読み始めましたが、その前にRust the bookを読んだほうが良いかも?と知り合いと話をしていてなったので、先にRust the bookを読み始めてます。 コツコツ読むってのが苦手なので、知り合いと小規模オンライン読書会しながら読むことになりました(基本的になにか書きながら、使い方を調べるので、存在そのものを知らない記述や使用法などがあったりする)。\n日本語版Rust the book Rust the book 基本は日本語版を読んでいます。まずは1章から3章あたり。\n気になった点などを。自分用のメモなので、読みやすさとかは考えてないです(あとで自分が死ぬパターン?)。\n1章 rustfmt便利。\nCLionのRustプラグインでは、保存時にrustfmtするというオプションがある。デフォルトはオフ。\u0026ldquo;Run rustfmt on Save\u0026rdquo; cargoの--binオプション。意識してつけたことなかった=デフォルトだった。\nライブラリにするときは--lib 2章 「変数を値に束縛」という言い回しにまだ慣れない。 「代入」という言い方に慣れているから? ただ、エラーにはassignってあるな。\u0026ldquo;error[E0384]: cannot assign twice to immutable variable x\u0026rdquo; preludeというのがデフォルトで読み込まれる型が存在する場所。 .expect()により、Resultが評価済みになる マクロがまだ慣れない extern crate rand;が最新版だと要らなくなっている。 rand::Rngはgen_rangeのためにuseしている。CLionだとかってにuseを推測して追加してくれた。 matchはswitch文みたいな感じ。けど、defaultが必ず実行されるって感じではないな。 ただし、全て網羅しないと怒られるのが便利。 アームという呼び方が新鮮 単一の式のときは{}が省略できる ブロック{}のときは、終わりにカンマを入力するとrustfmtが除去する(最後の条件かどうかは関係ない)。 シャドーイングは面白い。 よく、hoge_strやhoge_intのような変数を書くので、ありがたい。 ただし、コードを読むときに少し混乱しそう? let ... matchで変数への束縛でmatchが使えるのは便利(これまで知らなかったので、変数宣言して条件つけて束縛する処理書いてた)。 シャドーイング? fn main() { let x = 5; let x = x + 1; let x = x * 2; println!(\u0026#34;The value of x is: {}\u0026#34;, x); } とか\nlet spaces = \u0026#34; \u0026#34;; let spaces = spaces.len(); みたいに、同一変数名を使い回せること。再代入ではない\n3章 constは型注釈が必須 100_000のような記述が便利(Javaもできるって言われてびっくりしたw) タプルの中身を一部だけ書き換え可能。(mutを指定すれば) tup.0 = 20;のような感じで。 配列は固定長でかつ、同一の型のものだけが入る 文末にセミコロンがない場合に四季になるというのはちょっと射にくいので辛いのでは。。。 自分は明示的にreturnを書きたくなる。が、returnだと動かない場合もある。。。 let ... ifのような記述もできる。 (1..4)はRange型 おまけ フィボナッチ数列計算してみろというのがまとめにあったので。こんな感じでいいのかな?\nfn calc_fibonacci(n: usize) -\u0026gt; usize { if n == 0 { return 0; } else if n==1 { return 1; } else { return calc_fibonacci(n-1) + calc_fibonacci(n-2); } } その他 知り合いと読みすすめると、人が不思議に思ったところが、自分が理解が曖昧だったことなどに気づけて便利です。\n","date":1584928642,"dir":"post/2020/","id":"48b5ab9805919736382ffea5a9554c02","lang":"ja","lastmod":1584928642,"permalink":"https://blog.johtani.info/blog/2020/03/23/start-reading-rust-the-book/","publishdate":"2020-03-23T10:57:22+09:00","summary":"自転車本を読み始めましたが、その前にRust the bookを読んだほうが良いかも?と知り合いと話をしていてなったので、先にRust the bookを読","tags":["rust","読書","rust-the-book"],"title":"Rust the Bookを読み始めた"},{"contents":"動機 Azure Cognitive Searchを検索エンジンに使っているお客さんを手伝っています。 そこで、検索の基本的な話をさせていただきました(もともとJJUGナイトセミナーでしゃべる予定だったスライドがベース)。\nで、Elasticsearchなどの転置インデックスを利用している検索エンジンで検索の基本的な動作がどうなっているかを理解するのに、 個人的には一番重要だと思っているのがAnalysis(Analyze)の機能です。 転置インデックスの単語の切り出し方がどうなっているかによって、望んだ単語でうまく検索できているかいないかなどがわかります。\nAzure Cognitive SearchもAnalyze TextというAPIを提供してくれています(内部的にはElasticsearchだし)。 APIはあるのですが、返ってくる結果はJSONです。また、他のAnalyzerの設定との違いなどをみたくなったりもします。 やはり、普段使っているツールなどで簡単にどういう単語が出てくるかがわかるとうれしんじゃないかなぁ?と。\nということで、最初はPythonでちょっとAPI呼び出して、カンマ区切りで出力するものを作ってみたのですが、GUIとかあると便利かなぁという話になりました。 最近、ブログ書いたりするのにVisual Studio Codeを使い始めているので、これなら使いやすいかなと。 ということで、Visual Studio Codeの拡張機能(プラグイン?)としてインストールできるツールを作ってみました。 Azure Cognitive Searchを使っている人向けなので、ニッチなツールですが。。。\n余談 Elastic Stack(Elasticsearch)向けにはKibanaのプラグインでAnalyze APIを可視化するツールを作ってます。 analyze-api-ui-pluginです。Elastic Stack、特にKibanaを必ず利用する方はこちらを使うと便利かもです。\n概要と機能 GitHub リポジトリ Visual Studio Marketplaceのページ Marketplaceに公開しているので、johtaniやAzure Search Analyze Clientなどで検索してもらえれば出てきてインストールができます。\n機能としては、以下の2つです。\nテンプレートから入力値設定用のドキュメントを作成(Untitled-1というドキュメントをエディタに新しく開く) Azure Cognitive SearchのAnalyze Text APIを呼び出して、結果をHTMLのテーブル形式で表示 入力値設定用のドキュメント作成 APIの呼び出しに必要な情報を記入してもらうのに、いくつか案を考えました。\nプラグインの設定に記入してもらう 環境変数とかを読み出す テキストとして保存したファイルを使う 設定や環境変数だと、異なる環境に接続したりするときに、わざわざ設定し直すのがめんどくさいかもと。 で、愛用していたREST API Clientを真似するのが良いかもという結論になり、.analyzeという拡張子のファイルから必要な項目を読み出して、APIを呼び出す形にしてあります。\nCommand Palette(左下の歯車マークもしくは、メニューのViewから開ける)からAzure Search Analyze Client: Create Azure Search Analyze Requestというコマンドを選びます。\nすると、以下のようなファイルがエディタに開きます。\nこれらの項目をまずは埋めていきます。 それぞれの値がどういったものかはGitHubのREADMEを御覧ください。\n入力値エラー(存在チェックしかしていない)がある場合は、ダイアログが表示されます。\n結果表示 値を入力したら、設定値と###の間に表示されているAnalyze text with analyzersというグレーの文字をクリックします。すると、APIにリクエストを送信し、結果が返ってきて、別のパネルとして表示されます。\n複数のAnalyzerを入力値に設定すると、それぞれがどのような区切り方をするかがわかります。 文字の下にある[0:2]は、その単語がもとの文章の何文字目から何文字目までに出現しているかというオフセットの表示になります。\nもし、Analyzer名の設定ミスなどで指定されたAnalyzerがない場合は、結果画面にエラーが表示されるようにしています。\n以上が簡単な機能の説明です。 簡単なと言いつつ、これだけしか機能がありませんが。\nVisual Studio Codeのプラグインの作り方 プラグイン自体の作り方に関してはVisual Studio CodeのGetting Startedがわかりやすかったです。 APIや機能が豊富なので、最初はちょっと戸惑いましたが、サンプルもGitHubで多数公開されています。\nあとは、REST API Clientを参考にさせていただきました。\nGetting Startedを一通り読むことで、なんとなくプラグインの作成からMarketplaceへのリリースまでが完了できました。 (TypeScriptに慣れていないのがあるので、プログラミング自体は手間取りましたが。。。)\n今後の対応? いまのところ、こんなところを考えていますが、こんな機能がほしい、バグが有るなどあれば、GitHubにIssueを上げていただければと(使う人すくないだろうけど)。\nいろいろなエラーに関する対応 Readmeに画像をアップ アイコン作成? 自動補完機能? まとめ Visual Studio Codeの拡張機能を作ってみました。 Yeomanによるプロジェクトテンプレートが用意されているので、とりあえず、Hello worldを作るのは簡単でした。 試行錯誤しつつTypeScriptを書いたので、TypeScriptっぽくないところなどもあるかもですが、誰かの役に立つツールになってくれれば良いなぁと。\n","date":1584582615,"dir":"post/2020/","id":"c9d257aba54475c20b3737ce7c779e55","lang":"ja","lastmod":1584582615,"permalink":"https://blog.johtani.info/blog/2020/03/19/azure-search-analyze-plugin/","publishdate":"2020-03-19T10:50:15+09:00","summary":"動機 Azure Cognitive Searchを検索エンジンに使っているお客さんを手伝っています。 そこで、検索の基本的な話をさせていただきました(もともとJJUGナイ","tags":["azure search","visual studio code"],"title":"Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)"},{"contents":"これまで\n実践Rust入門はじめました 実践Rust入門の3章を読んでるところ 3章終了 3章の終わりまで読み終えた。\nいきなり実践的なプログラムで少し面食らっていたが、ステップを追って所有権周りの話まで来たので、 なんとなくRustのいいところが理解できたような気がする。\nただ、最後のsplit_at_mutが実際には内部でどういう形に変換することによって、コンパイルエラーにならずに、 借用がうまく行っているのかあたりは、まだきちんと理解できていない。\nこれは、どの言語にも言えるんだけど、リファレンスをうまく読み解きながら、 自分がやりたい処理ができるかどうかを考えるのって結構むずかしいなぁと思う。\nbenchmark.rsはコピペして実行しただけなので、またあとで読み返してみるかな。\nということで、ここから先は、基本を勉強する感じで4章から読みつつ、なんかプログラムをまた書いてみるか。\n","date":1583140813,"dir":"post/2020/","id":"6f47cb314fd780c122adb8cc1f44f785","lang":"ja","lastmod":1583140813,"permalink":"https://blog.johtani.info/blog/2020/03/02/finish-bicycle-book-chap3/","publishdate":"2020-03-02T18:20:13+09:00","summary":"これまで 実践Rust入門はじめました 実践Rust入門の3章を読んでるところ 3章終了 3章の終わりまで読み終えた。 いきなり実践的なプログラムで少","tags":["rust","読書"],"title":"実践Rust入門の3章を読み終わった"},{"contents":"Kuromoji-CLI Rust初心者がRust製の日本語形態素解析器の開発を引き継いでみたという記事にありますが、LinderaというRust製の日本語形態素解析が出てきました。KuromojiのRustクローンみたいなものです。 で、作者の人とのチャットの中で、「MeCabみたいなKuromojiのCLIないですかね？誰か知りませんか？」という話になりました。\n自分は普段はKuromojiの確認をするのは、Elasticsearch関連もしくは、Azure Searchなどだったりするので、 当たり前のようにKibanaを立ち上げたり、REST APIを叩いてましたが、たしかにコマンドラインインタフェースあると便利かも? と思い、作ってみるかということに。\npicocli いま、JavaでかんたんなCLI作るとなったら何がおすすめ？\n\u0026mdash; Jun Ohtani (@johtani) February 26, 2020 で、いつものツイートです。で、picocliという返信がありました。 JavaでCLIのプログラムを書くのが簡単になりそうだと。 ドキュメントもしっかりしてます。サンプルも載ってるし。\nAnnotationで、コマンドの説明などパラメータ、オプションなどが記述でき、必須チェックなども可能です。\nまた、オプションの説明文に関しては、テンプレートを用いることで、取りうる値をEnumの値で出力してくれたりといった便利機能まで備わっていました。\nGraalVM また、GRAALVMとPICOCLIでJAVAのネイティブコマンドラインアプリを作ろうというスライドも教えてもらい、ネイティブコマンドまで作れるらしいと。 なんて便利なんでしょう!ってことで、こちらもチャレンジしてみました。 GraalVMがどんなものかはなんとなくは知ってたのですが、何者だろう?とツイートしたところ、これまた返信が。\nっ 資料はかなり古いので現行版と乖離はあるけど概念は変わってないので..https://t.co/KRQjhNdD9f\n\u0026mdash; たむたむ🏫 (@tamtam180) February 26, 2020 本当に、Twitter便利ですね。\nGraalVMがどんなものかもいただいた資料でサクッと理解できました。 ただ、picocliが実はものすごく良くできており、自分でインストールする必要も実はありませんでした。\ngradle-graalというGradleのプラグインと、 Picocli Code Generationを利用することで、 以下のコマンドを実行することで、ネイティブコマンドアプリが作成できました。\ngradle nativeImage build.gradleファイルに記述したのは、以下のような項目です。\npluginの利用 picocli-codegenをannotationProcessorとして呼び出し jarに関する記述(メインクラスと依存するJarを含める設定) ネイティブコマンドの名前とか(gradle-graalの設定) 辞書が読み込めなかった で、native imageを作って実行しましたが、Kuromojiが内包している辞書ファイルが読み込めませんでした。 どうやら、picocli-codegenの自動生成では対応できない、リソース関連設定が必要らしいと。\npicocli-godegenの設定を見ていて見つけたのが、other.resource.patternsというオプションでした。\nkuromoji-cliのbuild.gradleに、その設定を加えたら辞書が読み込めるようになりました。\nこの設定をどうやって書くのか?というのを探すのにちょっと時間がかかりました。Picocli作者のRemko Popmaさんのサンプルリポジトリに設定を利用したbuild.gradleがありました。サンプル本当にありがたいですね。\n完成 出来上がったのは、kuromoji-cliというリポジトリになります。 内部で利用しているのはAtilikaのKuromojiです。LuceneのKuromojiではないのでご注意を(LuceneのKuromojiで最初やってみたのですが、リフレクションなどが多用されてて、Single Imageにするのが手間がかかりそうだった)。 コマンドのポータビリティはそれほど無いと理解してる(あってる?)ので、利用してみたい方は、リポジトリをクローンしてからビルドしてみてください。\n参考資料 kuromoji Picocliドキュメント Getting Started GraalVM / GraalVM超入門 一体何モノなの? GraalVM入門編 / GraalVM for beginners まだ途中? ほかにもあると便利かも?という機能があればIssueやPRを上げてください。 とりあえず、頭にあるのは以下のとおりです。\nJSONの出力はまだ未対応 いろんな辞書をAtilikaのKuromojiはサポートしてるのでそのへんも対応してみる? ","date":1582858179,"dir":"post/2020/","id":"d710a073be2da219a388a150eb7b6b6a","lang":"ja","lastmod":1582858179,"permalink":"https://blog.johtani.info/blog/2020/02/28/kuromoji-cli/","publishdate":"2020-02-28T11:49:39+09:00","summary":"Kuromoji-CLI Rust初心者がRust製の日本語形態素解析器の開発を引き継いでみたという記事にありますが、LinderaというRust製の日本語形態素解","tags":["misc"],"title":"KuromojiのCLIコマンドとpicocliとGraalVM"},{"contents":"これまでのはこちら。読書メモなので、本と合わせて読んでいただくのが良いです。\n実践Rust入門はじめました 3章のクイックツアーを読んでます。 バイトニックソート自体の理解はちょっとおいておいて、読み進めています。 いくつか疑問に思ったことがあったので、またメモを。 まだ、3.5.7の手前ですが。\n疑問点 3.4.1のジェネリクス対応のテストケースの部分で、既存のu32用のテストケースの入力のデータ列にVec\u0026lt;u32\u0026gt;という型注釈をつけるのですが、 追加した文字列の入力データには注釈をここではつけないのはなんでなんだろう?ちなみに、なくても動いた。バージョンの違いとかあるのかしら?\n3.4.6のmatch文\nmatch文の引数?が*orderになっていたが、orderでも実行できた。引数にくるのが参照だから*が付いてるんだとも運だが、なくても動くのはコンパイラがよしなに解釈してくれてるからかな? 便利なツール Rust標準のツールの説明がいくつか3章で紹介されてて便利だったのでメモ。\nrustfmt フォーマッター。デフォルトでフォーマット機能が付いてるの便利ですね。言語として決まってると、プロジェクトごとに悩まなくていいってのがありますし。\nrustfmt ファイル名 という形で使えるみたい。 プロジェクトごとだとcargo fmtのほうが楽そうかな。\n標準ライブラリAPIドキュメントをブラウザで閲覧 rustup doc --std これでデフォルトブラウザでRustの公式ドキュメントが開きます。 しかもローカルファイルだからサクサク。検索バーもついてて便利です。\nエラーのドキュメントを閲覧 rustc --explain 308 コンパイル時にエラーが出たときに、error[E0308]のようにコンソールに出てきます。 ヒントも出てくるのですが、詳細が上記のコマンドで読めるみたいです。\n","date":1582443437,"dir":"post/2020/","id":"71cf83ae0f45e9ede3a3f979b9c74933","lang":"ja","lastmod":1582443437,"permalink":"https://blog.johtani.info/blog/2020/02/23/bicycle-book-chap3/","publishdate":"2020-02-23T16:37:17+09:00","summary":"これまでのはこちら。読書メモなので、本と合わせて読んでいただくのが良いです。 実践Rust入門はじめました 3章のクイックツアーを読んでます。 バ","tags":["rust","読書"],"title":"実践Rust入門の3章を読んでるところ"},{"contents":"もう2020年2月になってしまってますが、2019年に買って便利だったもの良かったものをいくつか記録に残しとこうかなと。\nBRAVIA KJ-55X9500G Amazon | ソニー SONY 49V型 液晶 テレビ ブラビア 4Kチューナー内蔵 テレビをやっと買い替えました。 前に使っていたのはプラズマディスプレイで、10年以上たったもので、パネルの一部が赤い残像が残ってたりしました。 もう流石にいいでしょうということで、買い替えたのがSonyのテレビです。 4Kのチューナーもついているし、アップコンバーターもついているので普通の地上波でもきれいです。 まぁ、10年前のテレビに比べればたくさんいいことがありますよねw\n新しいTV買って一番活躍してるのはYouTubeボタンだったりします。 最近はミュージックビデオがYouTubeにたくさんあるので、King Gnuなどの音楽流したりするのに便利です(テレビなのに)。 今は、プライムビデオボタンがより活用される感じになってきてます(テレビなのにw)。\nSodastream Amazon｜スピリット ワンタッチ ホワイト スターターキット ここ数年、炭酸を普段飲んでます。甘いもの飲まないようにって意味でも。。。 で、これを買うまでは、サントリーの天然水スパークリングレモンとかを、箱買いしてました。 が、まぁ、ペットボトルのゴミが半端ないんですよ。場所も取るし。\nソーダストリームのことは知ってたのですが、自分で炭酸の量を考えながら、入れないといけないので避けていました。\nが、今回購入したものは、水の入ったボトルを指して、ボタン一つで3段階の炭酸を入れることができるんです!買って本当に重宝してます。うちでは1Lのボトルを1本追加して、2本で運用してます。 家族はなっちゃんのオレンジとかを炭酸割りしたり、カルピスソーダ作ったりして楽しんでます。 ワンタッチということで、簡単に入れられるので家族も重宝してます。\nNature Remo + Chromecast Amazon | Nature スマートリモコン Nature Remo mini Remo-2W1 Google Home miniがキャンペーンで手に入ったので、ベッドルームの照明やクーラーの操作もできそうなのでNature Remoを導入しました。 Chromecastは余っている液晶モニターにつないで、スマホからキャストできるようにしたり、音楽聞けるようにしてあります。\nNature Remoは温度計などもついているので、部屋の温度に合わせてエアコンのオンオフなども可能で、 暑い夏にとても便利でした。寝る時間にはクーラーが入っているのですんなり寝れたりと。 スマホから電源オンオフできるのも便利ですね。 Chromecastはモニターにつなぎましたが、今は、Google Music Playのプレーヤーになってます。 (最近、家にあるCDを読み込んでGoogle Play Musicにアップしてる)。\nただ、それ以上のことには使えてないので、もうちょっと面白いことしてみないとなぁ。\nモニターアーム Amazon | HUANUO PC モニター アーム 液晶ディスプレイ アーム ガススプリング式 Amazon | グリーンハウス 液晶ディスプレイアーム 4軸 クランプ式 ディスプレイがふるくなってたので、4Kディスプレイに買い替えた(27インチで4万切るとかで安い。。。)んですが、Mac Book Pro 15インチ(今は16インチ)を使っていて、Macの画面がディスプレイにかぶるので モニターアームを買いました。 1つ目がガススプリング式のアームです。なのに、5000円を切ってるんですよ。おそるべし。 2つ目はクランプ式です。アームにしたものの特に動かすことはなく、高さを出したいだけってことがあるので、クランプ式のも使ってます(家ではディスプレイ2枚使ってる)。 コスパ最高です。\nAnker PowerCore 10000 PD Amazon | Anker PowerCore 10000 PD（10000mAh PD対応最小最軽量 大容量 モバイルバッテリー） Pixel 3にしてから、電池の持ちはよくはなってるんですが、もしもの時のためにモバイルバッテリーは話せないですよね。 PD対応なので、Pixel 3に急速充電ができるし、サイズもそれほどじゃまにならないサイズなので便利です。USB-Aもついているので、このあと紹介するイヤホンの充電ケーブルなんかも差し込めて大活躍です。\nサウンドピーツのイヤホン Amazon | SOUNDPEATS(サウンドピーツ) Q35HD ワイヤレス イヤホン 高音質・低遅延 IPX8防水 私が持ってるのはこの前のバージョンで、micro-USBで充電充電するタイプですが、こちらもコスパ最高です。 冬は防寒も兼ねてヘッドフォンをしているのですが、春から秋にかけてはこれまで、優先のイヤホンを使ってました。もしくは、Bluetoothのレシーバーに優先のイヤホンつけてました。電池切れたら、イヤホンさして使う感じで。 が、Pixel 3はイヤホンジャックがありません。ということで、ワイヤレスイヤホンに移行するかということで選んだのがこちらです。 世の中的には、完全ワイヤレスイヤホンが流行っていますが、片方無くなってしまうイメージしかわかなくて。。。 これが壊れても、完全ワイヤレスではなくつながったワイヤレスイヤホンを使うと思います。\nヘッドルーペ Amazon | Tumao ヘッドルーペ ルーペ メガネ LED付拡大鏡 眼鏡の上装着 メガネゴムバンド両用 5レンズ交換調節 プラモデルをちょいちょい作るんですが、もう年ですね。。。細かいところが見にくくて。 ガンダムのRG系のプラモデルだと、1/144なんですよ。小さいんですよ。見えないんですよ。。。\n完成しましたー！ pic.twitter.com/S9QTS4kJDI\n\u0026mdash; Jun Ohtani (@johtani) February 16, 2020 ということで、ヘッドルーペ導入してみました。 最初は、卓上に置けるルーペにしてみたんですが、自分がルーペがあるところに動かないといけないの結構つらくて。 これのおかげで、プラモデル作成に問題はなくなりました。老眼とは関係なく、ちょっと猫背になっちゃうのが今は悩みの種ですが。。。こたつで作ってるからなぁ。\nまとめ ということで、いくつかよかったものを紹介してみました。 今年はちゃんと年末に書こう。。。\n","date":1582272302,"dir":"post/2020/","id":"daa3fe935b0be9f31b6b362ad9e0d2d6","lang":"ja","lastmod":1582272302,"permalink":"https://blog.johtani.info/blog/2020/02/21/best-buy-2019/","publishdate":"2020-02-21T17:05:02+09:00","summary":"もう2020年2月になってしまってますが、2019年に買って便利だったもの良かったものをいくつか記録に残しとこうかなと。 BRAVIA KJ-55X9500G Amazon | ソニー SONY 49","tags":["買い物"],"title":"2019年に買ってよかったもの"},{"contents":"ブログ移行日記(その5)です。前回まではこちら\nブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4) 今回はこれまでとは異なる特殊な話です。\n最初にブログを書き始めたときに利用していたのがJugemのブログでした。 その後、Octopressに移行して、今年、Hugoに移行したという流れです。\nで、よくよく考えると、Jugemのブログも移行できるんじゃないか?となりました。 じゃあ、やってみるかと。なので、今回のブログは自分の備忘録です(興味のない人が大多数じゃないかな)。 一応、Pythonで書いたプログラムはGitHubに上がっています。文字列置換と正規表現のオンパレードです。\nJugemからExport まずは、移行元のデータが取り出せるかどうかを調べたところ、text形式もしくはXML形式でエクスポートが可能でした。\n変換処理が必要なはずなので、XMLでダウンロードします。 独自のXMLですが、記事ごとにXMLのタグ(\u0026lt;entry\u0026gt;)でまとめられているので、処理が楽です。\nXMLをMarkdownに \u0026lt;entry\u0026gt;タグの下に次のような項目が入っているので、抜き出します。\nヘッダ部 title - 記事タイトル author - 著者 category - タグ date - 投稿日付 description : 本文(先頭部分) sequel : 本文(つづき) titleからdateまでをHugoのMarkdownのヘッダ部分として出力します。 日付は形式が違うので合わせるように変換し、 titleは(Jugemより移植)という文字列を追加しました。\nまた、Hugoの個別のコンテンツにするためにそれぞれをMarkdownのファイルに変換しています。 ファイル名は変換後のdateの先頭10文字(yyyy-MM-dd)に-を付け加えて、 タイトルを追加しました。ホントは英語のファイル名にしたかったんですが、ちょっと手抜き。ファイル名に使用できないような文字は-に置換しています。\n本文 本文部分はもう少し複雑です。 まずは、descriptionとsequelから抜き出した文字列を結合します。\nで、内部の文字列に次のようなものがあるので、それぞれMarkdownに変換したりという処理を書いてます。\nHTMLのheadingタグをMarkdown形式に br、hr、del、strongなどのタグもMarkdown形式に aタグの処理 Amazonのアフィリエイトタグの処理 ul、olタグの処理 などです。 アフィリエイトタグは、数行に渡るの複数のHTMLタグで記述されているので、 ASINと商品タイトルだけを抜き出しています。 Hugoでアフィリエイトのリンクを作るために、hugo-amazon-jpという公開されているshortcodeを元に、カスタマイズしたものを使っています。 これ用に、必要なASINとタイトルを別ファイルに出力したりしています。\nまた、いくつか画像を使っている記事があったのですが、これが曲者でした。 XMLに入っているimgタグに画像へのURLがあるのですが、アクセスしても存在しないURL担っています。。。 ブログで公開している画像のファイル名に似たものがXMLに入っていたので、URLを組み直して、ダウンロードするという処理も書いています。\nあとは、昔ちょっと凝った書き方(spanタグで章みたいなことやってた)をしていた部分の処理を加えて完成です。\nまとめ 元のXMLを見たり、抜き出したファイルを見ながら、トライアンドエラーでプログラムを書きました。 なんとなく変換できたなかっていうところで、取り込んで公開しました。 まだ、全部の記事をチェックしてないですが、なんとなく移植できたので一旦これでいいかなと。 昔の記事を見たときにおかしい場所があったら手で治すつもりでいます。\nなんか、もうちょっとうまくプログラムかけた気もしますが、書き捨てのプログラムだと思うのでこんなもんかな。\n1点気になっているところは、コメントの部分です。 ブログにコメントをいただいていたのですが、その部分は移植できてないです。\nOctopresに移植していこうは、Disqusのサービスでコメント部分を提供しています。ここに移植するのも変な話だなぁと思っているので、本文にコメントを取り込む感じかなぁ？\nもともとのJugemのサイトもそのまままだ残してあるので、そのうち気が向いたらで。\n","date":1582254240,"dir":"post/2020/","id":"ef8a399c9679ce4e9710c7c6ecf8bcc7","lang":"ja","lastmod":1582254240,"permalink":"https://blog.johtani.info/blog/2020/02/21/import-jugem-posts/","publishdate":"2020-02-21T12:04:00+09:00","summary":"ブログ移行日記(その5)です。前回まではこちら ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4","tags":["hugo","ブログ"],"title":"ブログ移行日記(その5) - Jugemのブログを移行"},{"contents":"お手伝いしているお客さんがAzure Cognitive Searchを利用してます。 検索周り=Azure Cognitive Searchに関する手伝いをする形で入っており、 いくつか触った感触をブログにまとめてみようかと(お客さんからはOKいただいてます)。\nAzure Cognitive Searchとは？ 公式サイト 「AIを活用した」クラウド検索サービスと紹介されています。\n昔はAzure Searchと呼ばれていましたが、ここ最近はAzure Cognitive Searchと呼ばれているみたいです(Microsoft Igniteで発表された話がまとまっているページもあります)。 もともと、検索エンジンのSaaSサービス(キーワード検索、あいまい検索、オートサジェスト、スコアリングなどの機能)として作られていた部分に、データの登録パイプラインにCognitive Serviceの便利な機能を簡単に使えるようにしたものというイメージでしょうか。\nバックエンドはElasticsearchのはずです。変わってなければ。 昔、Elastic社主催のユーザーカンファレンスでMSの方が公演された資料が公開されていたりします。 ちなみに質問が多いのでしょうか、Azure Cognitive SearchとElasticsearchの違いはなんですか?というページがよくある質問のページに用意されていました。参考までに。\n今回はちょっとしたインデックスをつくって検索する部分を紹介してみようかと思います (Cognitiveなところは機会があればまた)。\n普通の使い方については、Azureのドキュメントなどを読んで頂く形にします。 ポータルと呼ばれるブラウザ上でAzureのサービスを触ることができる画面が用意されています。 ここで、簡単な操作(インデックス作成、フィールドの追加)\nAPIを使ってインデックス(特にAnalyzer)の設定をしたり、データをいれて、クエリしてみるというところをサクッと紹介しようと思います。\nインデックスの作り方 インデックス作成に関するドキュメントも用意されています。最初はポータル(GUI)でインデックスを作成する方法が紹介されています。 ですが、今回はn-gram(n=2)のAnalyzerを利用したかったので、GUIではなくAPIでインデックスを作成しました。 カスタムアナライザーを利用する場合、REST APIを利用しなければ行けないということになっています。 n-gramのAnalyzerを含むインデックス生成のREST APIは以下のとおりです。こちらを実行することで、インデックスが作成されます(JSONの記述ミスなどがある場合はエラーが返ってきます)。\n@host = \u0026lt;サーチのサービス名\u0026gt;.search.windows.net @api-key = \u0026lt;APIキー\u0026gt; ### POST https://{{host}}/indexes/?api-version=2019-05-06 Content-Type: application/json api-key: {{api-key}} { \u0026#34;name\u0026#34;:\u0026#34;ngram-test\u0026#34;, \u0026#34;fields\u0026#34;:[ { \u0026#34;name\u0026#34;:\u0026#34;id\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;Edm.String\u0026#34;, \u0026#34;key\u0026#34;:true, \u0026#34;searchable\u0026#34;:false }, { \u0026#34;name\u0026#34;:\u0026#34;ngram\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;Edm.String\u0026#34;, \u0026#34;searchable\u0026#34;:true, \u0026#34;analyzer\u0026#34;:\u0026#34;bi_gram_analyzer\u0026#34; } ], \u0026#34;analyzers\u0026#34;:[ { \u0026#34;name\u0026#34;:\u0026#34;bi_gram_analyzer\u0026#34;, \u0026#34;@odata.type\u0026#34;:\u0026#34;#Microsoft.Azure.Search.CustomAnalyzer\u0026#34;, \u0026#34;tokenizer\u0026#34;:\u0026#34;bi_gram_tokenizer\u0026#34;, \u0026#34;tokenFilters\u0026#34;:[ \u0026#34;lowercase\u0026#34; ] } ], \u0026#34;tokenizers\u0026#34;:[ { \u0026#34;name\u0026#34;:\u0026#34;bi_gram_tokenizer\u0026#34;, \u0026#34;@odata.type\u0026#34;:\u0026#34;#Microsoft.Azure.Search.NGramTokenizer\u0026#34;, \u0026#34;minGram\u0026#34;:2, \u0026#34;maxGram\u0026#34;:2 } ] } なんだかどこかで見たことのある記述のようなそうでないような。。。 Analyzerは、charFilters(0以上複数可)、tokenizer(1つ必須)、tokenFilters(0以上複数可)から構成されます。 フィールドで指定するのはAnalyzerなので、まずanalyzersにCustomAnalyzerの設定を行います。 名前はbi_gram_analyzerにしました(好きに付けてください)。 tokenizerにはこのあと設定するtokenizerの名前を設定します。ここでは、bi_gram_tokenizerという名前にしています。 また、大文字小文字を気にせずに検索したいため、tokenFiltersにlowercaseを指定しています。こちらはすでに定義済みのため、定義済みの名前で呼び出すだけで使用できます。\n次が、bi_gram_tokenizerの設定です。 n=2としたいので、tokenizers配下にTokenizerの設定をします。 @odata.type\u0026quot;:\u0026quot;#Microsoft.Azure.Search.NGramTokenizerがTokenizerの名前です(ちょっと独特な名前ですね)。 Tokenizerごとにオプションがあり、NGramTokenizerの場合は、minGram、maxGramがオプションに相当します。 今回は2文字ごとにトークンを出力したいので、minとmaxをそれぞれ2としています。\nこれで、あとは、フィールドでanalyzerという設定にbi_gram_analyzerを指定すればそのフィールドはbi_gram_analyzerを使用してアナライズされるようになります(このへんはElasticsearchといっしょですね)。 フィールドは文字列を扱うので、Edm.Stringというタイプにしてあります。データ型については、フィールドコレクションとフィールド属性というドキュメントを参考に設定しましょう。\n閑話休題 - REST Client Exstension for Visual Studio Code なお、今回のサンプルはREST Clinet Extention for Visual Studio Codeを利用する想定の記述になっています。\nVisual Studio Codeで.restもしくは.httpというファイルに以下のAPIを記述すると、Send RequestというリンクがURLの上部に出てくるような拡張機能です。REST APIにリクエストするときに便利なツールになっています。 変数も使えるので、APIのキーやURLの一部をこのように共通化して、他の環境でも使いやすくできるのは素晴らしいなと。\nアナライザーの挙動の確認 設定したAnalyzerがきちんと機能しているかというのを確認する必要があります。 入力した文字列がきちんと想定している単語として切り出されて、転置インデックスの見出し語に使われるかというのが重要になるからです。\nAzure Cognitive Searchでもアナライザーのテスト用APIが用意されています。 使い方はこちら。 APIの仕様のページもありました。 「アナライザーの挙動はどんな感じ？」という文字列が、作成したインデックスの定義したアナライザーbi_gram_analyzerにより、 どのように分割されるかを確認するAPIの呼び出しは以下のとおりです。\n### POST https://{{host}}/indexes/ngram-test/analyze?api-version=2019-05-06 Content-Type: application/json api-key: {{api-key}} { \u0026#34;analyzer\u0026#34;:\u0026#34;bi_gram_analyzer\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;アナライザーの挙動はどんな感じ？\u0026#34; } レスポンスはこんな形です。ヘッダ部分は省略してあります。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;https://{{host}}.search.windows.net/$metadata#Microsoft.Azure.Search.V2019_05_06.AnalyzeResult\u0026#34;, \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;アナ\u0026#34;, \u0026#34;startOffset\u0026#34;: 0, \u0026#34;endOffset\u0026#34;: 2, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;ナラ\u0026#34;, \u0026#34;startOffset\u0026#34;: 1, \u0026#34;endOffset\u0026#34;: 3, \u0026#34;position\u0026#34;: 1 }, { \u0026#34;token\u0026#34;: \u0026#34;ライ\u0026#34;, \u0026#34;startOffset\u0026#34;: 2, \u0026#34;endOffset\u0026#34;: 4, \u0026#34;position\u0026#34;: 2 }, { \u0026#34;token\u0026#34;: \u0026#34;イザ\u0026#34;, \u0026#34;startOffset\u0026#34;: 3, \u0026#34;endOffset\u0026#34;: 5, \u0026#34;position\u0026#34;: 3 }, { \u0026#34;token\u0026#34;: \u0026#34;ザー\u0026#34;, \u0026#34;startOffset\u0026#34;: 4, \u0026#34;endOffset\u0026#34;: 6, \u0026#34;position\u0026#34;: 4 }, { \u0026#34;token\u0026#34;: \u0026#34;ーの\u0026#34;, \u0026#34;startOffset\u0026#34;: 5, \u0026#34;endOffset\u0026#34;: 7, \u0026#34;position\u0026#34;: 5 }, { \u0026#34;token\u0026#34;: \u0026#34;の挙\u0026#34;, \u0026#34;startOffset\u0026#34;: 6, \u0026#34;endOffset\u0026#34;: 8, \u0026#34;position\u0026#34;: 6 }, { \u0026#34;token\u0026#34;: \u0026#34;挙動\u0026#34;, \u0026#34;startOffset\u0026#34;: 7, \u0026#34;endOffset\u0026#34;: 9, \u0026#34;position\u0026#34;: 7 }, { \u0026#34;token\u0026#34;: \u0026#34;動は\u0026#34;, \u0026#34;startOffset\u0026#34;: 8, \u0026#34;endOffset\u0026#34;: 10, \u0026#34;position\u0026#34;: 8 }, { \u0026#34;token\u0026#34;: \u0026#34;はど\u0026#34;, \u0026#34;startOffset\u0026#34;: 9, \u0026#34;endOffset\u0026#34;: 11, \u0026#34;position\u0026#34;: 9 }, { \u0026#34;token\u0026#34;: \u0026#34;どん\u0026#34;, \u0026#34;startOffset\u0026#34;: 10, \u0026#34;endOffset\u0026#34;: 12, \u0026#34;position\u0026#34;: 10 }, { \u0026#34;token\u0026#34;: \u0026#34;んな\u0026#34;, \u0026#34;startOffset\u0026#34;: 11, \u0026#34;endOffset\u0026#34;: 13, \u0026#34;position\u0026#34;: 11 }, { \u0026#34;token\u0026#34;: \u0026#34;な感\u0026#34;, \u0026#34;startOffset\u0026#34;: 12, \u0026#34;endOffset\u0026#34;: 14, \u0026#34;position\u0026#34;: 12 }, { \u0026#34;token\u0026#34;: \u0026#34;感じ\u0026#34;, \u0026#34;startOffset\u0026#34;: 13, \u0026#34;endOffset\u0026#34;: 15, \u0026#34;position\u0026#34;: 13 }, { \u0026#34;token\u0026#34;: \u0026#34;じ？\u0026#34;, \u0026#34;startOffset\u0026#34;: 14, \u0026#34;endOffset\u0026#34;: 16, \u0026#34;position\u0026#34;: 14 } ] } このAzure SearchのAnalyze API、使用できるオプションはすくないですが、ElasticsearchのAnalyze APIと似ています。\nデータの登録の仕方 データ登録もAPIからできます(あたりまえですね)。 APIは1件ずつではなく、バルクで登録できる形で提供されています。\nサンプルとしては、以下のような形です。 @search.actionの部分(searchがあるとわかりにくい気がするけど。。。)が、ドキュメントの登録、更新、削除の命令を書き込むところになります。 今回は単純に登録するだけなので、uploadを指定しました。 ほかにもいくつかアクションが用意されています。用途に合わせて指定する感じになります。 id、ngramはそれぞれフィールド名です。ドキュメントに登録したい値を記述します。\nPOST https://{{host}}/indexes/ngram-test/docs/index?api-version=2019-05-06 Content-Type: application/json api-key: {{api-key}} { \u0026#34;value\u0026#34;: [ { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;ngram\u0026#34;: \u0026#34;新しいAzure Searchの使い方\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;ngram\u0026#34;: \u0026#34;Elasticsearchの紹介\u0026#34; } ] } 検索クエリ 最後は検索クエリです。 検索クエリはいくつかのオプションがあります。 ざっくりだと、queryTypeがsimpleとfullという2種類が用意されており、ちょっとした検索を作る場合はsimpleで事足りそうという感じです。 入力された単語(スペース区切りで複数扱い)をフィールド(複数可)に対していずれかの単語を含むもしくは、すべての単語を含むという検索に行くというパターンですね。 このときの、「いずれか」か「すべて」の設定がsearchModeというパラメータになります。 anyの場合、Googleの検索と同様に、どれかの単語が入っているドキュメントが対象に、allの場合すべての単語が含まれるドキュメントだけがたいしょうになるといった形です。\nqueryType=fullの場合はLuceneの構文でクエリがかけます。ElasticsearchのQuery String Queryみたいな形です。\n簡単なサンプルは次のような感じです。このサンプル\nPOST https://{{host}}/indexes/multi-field-test/docs/search?api-version=2019-05-06 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#39;ngram:\u0026#34;使い方\u0026#34; ngram:\u0026#34;紹介\u0026#34;\u0026#39;, \u0026#34;queryType\u0026#34;: \u0026#34;full\u0026#34;, \u0026#34;searchMode\u0026#34;: \u0026#34;any\u0026#34; } すこしだけクエリの補足を。 searchに入力された単語をダブルクォートで囲んでいます。これは、「使い方」という文字がbi_gram_analyzerにより「使い」「い方」に 分割されるのですが、必ずこの順序で出現したものだけを検索対象にしたい(フレーズ検索)という意味になります(*bi_*gramなので、「紹介」に関してはダブルクォートは厳密には必要ないです)。\nあと、レスポンスは今回記載していませんが、@search.scoreという項目で、スコアが返ってきます。 デフォルトのスコア計算には何を使ってるんだろう?ドキュメントにはTF-IDFとの記述があるのですが。。。カスタマイズもできそうです。\n少しオモシロイと思ったのは、スキーマ(インデックスの設定)に定義されているが、ドキュメントとしては登録していない項目についても、 Azure Cognitive Searchはドキュメントのフィールドがnullという形で返ってくるようでした。 そもそもフィールドが存在しないドキュメントとフィールドの値がnullのものの違いは無いようです。\n簡単ですが、インデックスの設定、ドキュメントの登録、検索の方法の紹介でした。\nちょっと触った感想 一番売りである、Cognitiveの部分はまだ触っていないです、すみません(こっちが売りな気もするんですが)。 検索エンジンの部分としては、Elasticsearchを知っていると、「あー、そんな感じね」という気持ちになれるサービスです。 個々のAPIやデータの形式は異なるので、きちんとAPIのリファレンスなどを確認しつつという形になりますが、なんとなくこういうAPIなどがありそうだな?と予測しつつ使えるかなと。 内部的にはElasticsearchだと思いますが、独自のAPIでラップされているおかげで、バージョンの違いなどを意識せずに使えるのではないかと思います。\nまた、今回は紹介していませんが、マイクロソフト独自の各言語のアナライザー(日本語も含む)があります。 Luceneのアナライザーとマイクロソフトのアナライザーのどちらも利用できますので、ここの違いを見てみるのも面白そうだなと思いました。 緯度経度を利用した検索、フィルター検索(スコア計算対象にならない)、ファセット、スコア調整の機能なども備えているようです。\nなんにせよ、利用する場合やドキュメントを読む場合に、全文検索の仕組みをなんとなく知っておいたほうが読みやすいんじゃないかなというのが感想です。\nここ数年はElasticsearchがメインでほかはほぼ触っていない状況だったので新しい製品に触れるのは面白いですね。 時間があったら、アナライザーの違いなども調べてみたいなと思います。\n","date":1582080481,"dir":"post/2020/","id":"c3053579ae25e2fb9b967076a06373af","lang":"ja","lastmod":1582080481,"permalink":"https://blog.johtani.info/blog/2020/02/19/research-azure-cognitive-search/","publishdate":"2020-02-19T11:48:01+09:00","summary":"お手伝いしているお客さんがAzure Cognitive Searchを利用してます。 検索周り=Azure Cognitive Searchに関する手伝いをする形で入っており、 いく","tags":["azure search"],"title":"Azure Cognitive Searchでインデックスを作って検索"},{"contents":"また、ツイートから始まるお話です。 まだまだ、検索システムってどんなものかを勉強したいしということで、こんなのをツイートしてました。\n「検索システム探訪」みたいな名前がいいかな? https://t.co/sG7BDdGI9h\n\u0026mdash; Jun Ohtani (@johtani) February 6, 2020 検索について知り合いとお茶をしながら話をしていて、こういう話を聞くの面白いなぁと思ったので。 どんなことを個人的には聞きたいかな?というのをまとめといたほうがいいかと思いブログを書いています。 こんなことも面白そうだよね?\nどんなこと聞きたいかな? いまのところ思いついた内容はこんな感じかな? こんなのも聞くと面白そうだよね?などありましたら、コメント欄に書いてもらえればと。\n利用しているシステム・サービスは? 構成やどこのサービスなのか？ 検索ユーザーはどんな人？ ユーザーの種類 ユーザーの検索ニーズ 検索対象データはどんなもの？ データ件数はどのくらい？ 属性、項目がどのくらいあるか？ 検索結果として出したいものは？ ソートはどんなものがあるの？ ランキングで重要なものは？ UI/UXはどんな感じ? ハイライト、ソート、ファセット(Aggs) キーワードサジェスト、オートコンプリート 検索システムの監視(オブザバビリティ??) ビジネス的な指標 クエリログ、クリック(ユーザーに関する情報) システムメトリクス 困っていることは？ ランキング クエリ 検索システム分析 第1回やりました。 ちなみに、最初のツイートに対して、すぐに返事をくれた方がいました。\nうちでよければご説明します！\n\u0026mdash; Kizashi （令和もRailsエンジニア募集中） (@kizashi1122) February 6, 2020 Twitter本当にありがとうございますという感じです。\nで、早速話を聞かせていただきました。大阪の方だったので、テレカンでやらせていただきました。 移動時間とか気にせずにできるので、テレカン形式いいですよね。\n内容は、非常に面白かったです。 使ってるシステムについて、どんなところで、どのようなように検索エンジンをつかっているのか、 どんなことで困っているのかなどをお聞きすることができました。\n2020/02/13 追記 対応していただいたIngageの永田さんから、内容を公開しても良いという承諾をいただいたので、メモを公開します。\nサービス : Re:lation 問い合わせメールなどのチームで対応する対応 利用している検索エンジン Elasticsearch (AWS Es) ノード数 8 - 3 master + 5 data データ データ数 : 約1億5千万 親子関係 : チケット - メール(=1ドキュメント) - コメント 画面としてはチケットの一覧=aggsでチケットIDの一覧を生成してリスト表示 インデックス数 : 5 = テナントごとに振り分けしてる。 8シャード - スケールアウトした場合も対応できるので。 PostgreSQLにマスターは保存 データの単位はメール。コメントはtextの配列でメールに保存されている。 EsはIDの一覧を返す。ただし、チケットのIDの一覧 機能 ハイライト Esではなく独自実装。 クエリ n-gramでやってる = kuromoji使ってない min=1, max=2 悩み事 EBS上だったものをローカルにしたので速くなった。 期間が長いと、検索結果一覧の表示が遅い aggsが遅いのかな? 検索結果一覧はチケットが持っているメールの日付の降順。結果一覧はチケットの一覧。 詳細検索はDB、左のステータスもファセットも現在はDBから生成 Es使ったほうが早いかも? マルチテナントのつらさ 検索ログ 独自ログはとっていない = アプリのログから判別 今後 アドレス帳検索 お誘いお待ちしております! 今後もこれやっていきたいなぁ。話してもいいよ!という方がいらっしゃいましたら、@johtaniまでDMもしくはメンションをください。お待ちしております!\n","date":1581344427,"dir":"post/2020/","id":"7b080dc43fce482af14de61c6ab819a5","lang":"ja","lastmod":1581344427,"permalink":"https://blog.johtani.info/blog/2020/02/10/explore-search-system/","publishdate":"2020-02-10T23:20:27+09:00","summary":"また、ツイートから始まるお話です。 まだまだ、検索システムってどんなものかを勉強したいしということで、こんなのをツイートしてました。 「検索シス","tags":["検索システム探訪"],"title":"「検索システム探訪」したいな=\u003eやりました"},{"contents":"年末、何種類かのボードゲームを家族で楽しみました。 家族の感想を交えて簡単に紹介しようかと思います。 家族や知人でボードゲームを購入するときの参考に参考にしてもらえたらと。 それぞれのゲームの詳細については、それぞれWikipediaなどのリンクを張っておくので、参考にしていただけたらと。 結構有名なボードゲームが多いのかな?\nカタン Amazon | カタン スタンダード版 | ボードゲーム | おもちゃ 簡単な紹介 プレーヤー数 : 3-4名 (拡張版を追加すると5-6名でもプレイできるみたい) 対象年齢 : 10歳以上 種類 : 対戦型 紹介 : 大航海時代に発見された無人島を複数の入植者たちが開拓していき、もっとも繁栄したプレイヤーが勝利するという内容のボードゲーム(Wikipediaより)。 特徴 : 5種類の資源を元に、道を作ったり、開拓地や都市を作ったり、サイコロを使った運も必要ですが、プレーヤー同士で手持ちの資源を交渉することも可能なゲームです。 感想 最初の配置が重要な気がします。資源の組み合わせによってできることが変わってくるので、何をやりたいかというのを元に考えて配置するのが重要そうです(私はまだうまくできてませんがw)。 プレーヤー同士の交渉も1つの手段なので、会話しながら、自然と交渉術も身についてきそうです。 戦略だけじゃなくサイコロを使った運もあるので、子供と大人が混ざっていても偏った結果にはならないです。 自分の道や町が発展していくのも楽しみの1つです。 お化け屋敷の宝石ハンター Amazon | お化け屋敷の宝石ハンター FBH20 | おもちゃ | おもちゃ 簡単な紹介 プレーヤー数 : 2-4名 対象年齢 : 8歳以上 種類 : 協力型 紹介 : お化け屋敷がおばけでいっぱいになる前に、みんなで協力して８つの宝石をみつけて、屋敷から脱出しよう！(メーカーホームページより)。 特徴 : 対戦ではなくプレーヤーみんなで協力してやるボードゲーム。おばけのフィギュアも可愛いです。サイコロを利用した運もありますが、みんなでどういった戦略で宝石を取り出すかなど会話も進むゲームです。上級編という難しめのルールも用意されているので、ハラハラ・ドキドキしながらプレイできます。 感想 負けて悔しくなったり機嫌が悪くなることがないのがいいですね。 普通のルールだと少し物足りない感じですが、上級編のルールはより、みんなで協力する必要が出てきます。 また、上級編のルールは絶妙な難易度で、もう一度やりたいと思わせるのが良い仕組みです。 ラビリンス Amazon | ラビリンス (Labyrinth) ボードゲーム | ボードゲーム | おもちゃ 簡単な紹介 プレーヤー数 : 1-4名 対象年齢 : 8歳以上 種類 : 対戦型 紹介 : 動く迷路で宝探し！通路が動く不思議な迷路の中に、「宝物」や「奇妙な生き物」が隠されています。プレイヤーはこれらを集めてこなければなりませんが、そのためには、巧みに迷路を動かさなければなりません。(メーカーホームページより)。 特徴 : サイコロがないボードゲームです。先を予測しながら人のじゃまをしつつ、自分に有利に進めていくゲームです。プレーヤー個別に難易度を変えられる仕組みがあります(子供だけに有利なルール設定が可能)。 感想 子供ルールがあるので、1度のゲームで別々の難易度が設定できるのがいいです。左右盲の人には子供ルールとかもありです。 ラビリンスが得意な人は地図を読むのが得意な人だと思います。 頭も使うけど、自分が望んだ道ができた時の快感があります。 モノポリー Amazon | ハズブロ ボードゲーム モノポリー クラシック C1009 正規品 | ボードゲーム | おもちゃ 簡単な紹介 プレーヤー数 : 2-6名 対象年齢 : 8歳以上 種類 : 対戦型 紹介 : プレイヤーは双六の要領で盤上を周回しながら他プレイヤーと盤上の不動産を取引することにより同一グループを揃え、家やホテルを建設することで他のプレイヤーから高額なレンタル料を徴収して自らの資産を増やし、最終的に他のプレイヤーを全て破産させることを目的とする。モノポリーとは英語で「独占」を意味する。(Wikipediaより)。 特徴 : 資本主義とは?みたいなのを体験できるゲーム。すごろく型ですが、ゴールがあるわけではなく、決着がつくまでぐるぐる回る感じです。 感想 資本主義を象徴しているゲーム展開。真剣勝負間違いなしです。 負けると途中退場ってのがちょっとつらいです。。。 カタンとは違った感じの交渉術になります。 コマが色んな種類があってかわいいです。 パンデミック Amazon | パンデミック:新たなる試練 (Pandemic) 日本語版 ボードゲーム | ボードゲーム | おもちゃ 簡単な紹介 プレーヤー数 : 2-4名 対象年齢 : 8歳以上 種類 : 協力型 紹介 : 『パンデミック』（Pandemic）は、プレイヤーが新型ウイルス対策チームの一員となり、協力しあい感染症の世界的流行（パンデミック）に立ち向かうというボードゲームである。(Wikipediaより)。 特徴 : プレーヤーが個別のロール(役割)を持っており、よりみんなで協力をしないとウイルスに打ち勝てない感じです。 感想 ルールが結構複雑で、理解しながらだと少し時間かかりました。 8歳以上になっていますが、少しむずかしい印象でした。 戦略、戦術が問われる形のゲームなのでしっかり理解すると楽しそう。 世界地図上で、ウイルスと戦っていく感じは臨場感があって面白いです。 ナインタイル Amazon | ナインタイル | カードゲーム・トランプ | おもちゃ 簡単な紹介 プレーヤー数 : 2-4名 対象年齢 : 6歳以上 種類 : スピード対戦型 紹介 : 「ナインタイル」の基本ルールは、それぞれの手元にある、９枚のタイルを自由に動かしたりひっくり返したりして、誰よりも早くお題どおりに並べるだけ。(公式サイトより)。 特徴 : ボードゲームというか、カードゲーム。ルールは簡単ですが、記憶力と素早さが重要です。 感想 脳トレに良さそう(子供に勝てませんでした。。。)。 瞬発力+記憶力が重要。 デザインがきれい じゃあ、家族の人気は? ラビリンス、カタン、モノポリーあたりが人気です。 ゲーム性もありますが、デザインとしてもきれいなものが多かったです。\nテレビゲームも面白いですが、ワイワイ喋りながらボードゲームをやるのも楽しかったです。 今回紹介したボードゲームはどれもある程度ルールを理解するところから始めないといけないですが、理解力や説明力なども必要になってくるので色んな楽しみがあるかなと思います。\n","date":1580558694,"dir":"post/2020/","id":"90f9355781403b92e844de8568863ae8","lang":"ja","lastmod":1580558694,"permalink":"https://blog.johtani.info/blog/2020/02/01/intro-board-game/","publishdate":"2020-02-01T21:04:54+09:00","summary":"年末、何種類かのボードゲームを家族で楽しみました。 家族の感想を交えて簡単に紹介しようかと思います。 家族や知人でボードゲームを購入するときの参","tags":["ゲーム"],"title":"ボードゲーム紹介"},{"contents":"実践Rust入門という本を買っていた(去年の7月だ。。。)のですが、積んであったので、時間を作って読み始めようかと。\n実践Rust入門[言語仕様から開発手法まで] | κeen, 河野 達也, 小松 礼人 |本 | 通販 | Amazon 経緯 もともとは、言語処理100本ノックはじめました(Rust)という感じで、触っていたのですが、場当たり的にやってても時間を持っていかれるだけだなということに気づいたのが最初です。\n今年の目標は、覚えられなので、ちょっとずつでもアウトプットしていこうってのもあり、 読書記録をつけつつ、読んでいこうかなぁと。\nどこまで読んだ? 2章の2-2-5までです。 前回、Rustの環境はセットアップしていたのですが、新PCに切り替わったので、rustupからはじめました。\nrustup rustupではデフォルト設定のままではなく、PATH変数の書き換えだけはしない形でインストールを行いました。\nPATH変数は.zshrcファイルで変更したかったためです(rustupコマンドに変更して貰う場合は.profileなどのファイルが変更されそうだったため)。\nインストールが終わったあとに.zshrcに以下の行を追加しました。\n### For Rust env source $HOME/.cargo/env 疑問点 ここまで読んだ疑問点です。\ncargo new helloしたあとにmain.rsに以下のmain()関数が出来上がっている!? fn main() { println!(\u0026#34;Hello, world!\u0026#34;); } 驚きましたが、cargo new hogeってやっても、おなじmain.rsができてました。デフォルトで出来上がるんですね。どんな超能力!?と思ってしまいましたw\ncargo new helloして出来上がったCargo.tomlに著者名が入力されていた。 authors = [\u0026#34;Jun Ohtani \u0026lt;メアド\u0026gt;\u0026#34;] なんで?と思いました。まだ解明してないです。 本を読んでいけばわかるかな?\n予想:gitの設定(~/.gitconfig)に氏名とメアドが設定されているので、これを利用しているのかな? ","date":1580475492,"dir":"post/2020/","id":"7fcfaa8dd34dbd508f19e8ca0fcfda0f","lang":"ja","lastmod":1580475492,"permalink":"https://blog.johtani.info/blog/2020/01/31/start-reading-bicycle-book/","publishdate":"2020-01-31T21:58:12+09:00","summary":"実践Rust入門という本を買っていた(去年の7月だ。。。)のですが、積んであったので、時間を作って読み始めようかと。 実践Rust入門[言語仕","tags":["rust","読書"],"title":"実践Rust入門はじめました"},{"contents":"12月に退職しますブログを書きましたが、その後どうなったのか?という話をしてないなと思ったので、一応現在の状況を書き留めておこううかと。\n結論 実際にはフリーランスとして働き始めてます。検索周りをお手伝いするお仕事を。読解いとこあれば所属するつもりでもいるし。\n\u0026mdash; Jun Ohtani (@johtani) January 27, 2020 フリーランスとして最初の仕事はElasticsearchではなく、Azure Cognitive Searchの支援だったりします。Esで困ってる方の手伝いもしますので、興味ある方はDMください。\n\u0026mdash; Jun Ohtani (@johtani) January 31, 2020 2020年1月24日が、正式なElasticの退職日でした(有給休暇消化してた)。 で、現在のステータスはこのツイートです。\n現在の心境 どこかに就職してガッツリ検索もやりたいし、いろんな会社の検索やElastic Stackに関するお手伝いをするのにも興味があるし、どちらにも興味がある状況です。まぁ、検索に興味が尽きないというのだけは決まってますかね。\n悩んでいるところに、幸いにもAzure Search周りで手伝ってほしいという話が舞い込んできたので、フリーランスとしてお手伝いをさせていただいてます(現時点で、半稼働で、が3月末まで)。\nElastic Stackなどの知見もあるのでのお手伝いをするというのもありかなぁと。お仕事発注してもいいな?という方があれば、TwitterのDMなど、連絡をいただければと。\n現在の状況でした。\n副業ができる会社に就職するのがどっちもできていいのかも?\n","date":1580470659,"dir":"post/2020/","id":"c61a5bda3f1667498626ae52ad0362e0","lang":"ja","lastmod":1580470659,"permalink":"https://blog.johtani.info/blog/2020/01/31/start-freelance/","publishdate":"2020-01-31T20:37:39+09:00","summary":"12月に退職しますブログを書きましたが、その後どうなったのか?という話をしてないなと思ったので、一応現在の状況を書き留めておこううかと。 結論","tags":["転職"],"title":"フリーランスはじめました(仮)"},{"contents":"ブログ移行日記(その4)です。その他の記事はこちら。\nブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その5) 前回までで、なんとなく移行は終わってます。 今回はテーマで使えるようになっているブログの検索機能の導入の話です。\n検索サービスはAlgoliaを利用します。 OctopressのころはElastic社のサービスであるElastic Site Searchの機能を利用して、クローリングしてから検索できるようにしていましたが、Hugoで導入できるモジュール?があったので、今回からこちらに移行しました。\n参考記事 Clean White ThemeのREADME(Algoliaの設定方法) 参考ブログ:hugoで作ったblogにalgoliaで全文検索機能を追加する Algoliaとは? 検索のas-a-serviceをやっている会社です。Wikipediaによると本社はサンフランシスコにあるみたいですね(フランスの会社のイメージでした。起業された方がフランス出身だからかなぁ?)。 クラウドで検索インデックスを保持でき、API経由で検索したり登録したりできる感じのサービスです。内部で使われているのはOSSではない独自の検索エンジンです。\nクラウドで提供されているサービスなのでサクッと検索を使い始めることができるのがいい点ですね。 また、小さな非商用のプロジェクトにフリーで利用できるプランも提供されているようです(2020年1月現在)。\nAlgoliaのサービス登録からインデックス作成 私が利用しているテーマで設定する方法の記載があったので手順の通りにやってみました。 大きく2つの作業(Algolia側とHugo側)が必要です。まずは、Algoliaで必要な作業から。作業の流れだけ記載しておきます。詳細は「Static site search with Hugo + Algolia」の3)を確認してください。\nAlgoliaのサインアップ(すでにアカウントがあれば不要) New Applicationの作成(名前とプランの指定) リージョンの指定 インデックス名の指定 APIキーを確認 です。これで、Algolia側の準備は完了です。\n今回は関係ないですが、Algoliaの管理画面で、利用状況(データ登録などの操作回数、クエリの回数、インデックスに保存されているレコード数)の確認が可能です。 ほかにも有料プランを利用するとAnalyticsなどもできるようです。\nHugo側で必要な設定 今度はHugo側です。Hugoのサイトのディレクトリに移動してからの作業です。\n仕組みとしては、\nHugoのoutput機能でAlgolia向けのJSONファイルを生成する Node.jsのライブラリを使用してAlgoliaに1.で生成したJSONを登録、更新する 検索画面の作成 という流れになります。 ですので、作業としては以下のとおりです。\nOutput出力の設定(すでにテーマ側で設定されているので、特に作業は必要なし) npm環境の構築(Hugoのconfig.tomlと同じディレクトリ階層) Node.jsのインストール(必要であれば) npm環境の初期化 npmでatomic-algoliaのインストール atomic-algolia向けの設定(登録のためのAPI関連の設定) Algolia向けJSONの出力設定 検索関連の設定 content/search/placeholder.mdの作成 検索用のAPIキーなどを設定 npm関連の作業 以下、npm関連の作業です。\nNode.jsのインストール(必要であれば) 割愛します。環境に合わせてインストールしてください。私はnvm経由でインストールしています。 npm環境の初期化 Hugoのディレクトリでnvm initを実行 npmでatomic-algoliaのインストール Hugoのディレクトリでnpm install atomic-algolia --save atomic-algolia向けの設定(登録のためのAPI関連の設定) Hugoのディレクトリに.envファイルを作成し、以下を設定します。 Algolia向けJSONの出力設定 特に変更なし(config.tomlに少し設定があります)。 ALGOLIA_APP_ID=AlgoliaのApplication ID ALGOLIA_ADMIN_KEY=AlgoliaのAdmin API Key ALGOLIA_INDEX_NAME=先程作ったインデックス名 ALGOLIA_INDEX_FILE=public/algolia.json 最後のALGOLIA_INDEX_FILEは固定文字列でいいと思います。 hugoコマンドを実行するとpublicディレクトリ配下にalgolia.jsonというファイルが生成され、Algolia登録用のJSONが出力されています。\n余談 : algolia.jsonの出力の設定は、config.tomlに記載があります。また、JSONファイルのテンプレート自体はthemes/hugo-theme-cleanwhite/layouts/_default/list.algolia.jsonにあります。Algoliaに登録するデータの構造など変更をする場合はこのテンプレートをカスタマイズすれば良さそうです。\n検索関連の設定 実際に検索の画面を表示するために、検索用の画面と、検索用のAPIの設定が必要です。\ncontent/search/placeholder.mdの作成 /search/が検索用のページになります。空のファイルです。実際にはJavaScriptが検索用の窓を表示したりしてくれます(これが必要な理由がまだ不明だなぁ)。 検索用のAPIキーなどを設定 検索のためのAPIキーなどの設定が必要となります。テーマ作者の方のサンプルのconfig.tomlにパラメータは用意されています。 以下の値を設定します。\nalgolia_search = true algolia_appId = \u0026#34;AlgoliaのApplication ID\u0026#34; algolia_indexName = \u0026#34;作成したインデックス名\u0026#34; algolia_apiKey = \u0026#34;AlgoliaのSearch-Only API Key\u0026#34; 以上でAlgolia関連の設定などの作業が終了です。\nAlgoliaへのデータ登録方法 最後に、実際にデータを登録する必要があります。 手順は、以下のとおりです。\nhugoコマンドの実行(htmlと一緒に登録データのalgolia.jsonを生成) npm run algoliaコマンドの実行(atomic-algoliaを利用してAlgoliaにデータを登録) 設定などが問題なければ、Algoliaの管理画面で登録ができているはずです。 実際にブログのデプロイにはdeploy.shというファイルをこちらを元に作成して使っています。このなかで、hugoコマンド実行後にnpm run algoliaを実行するようにしいます。\n今後の課題 Hugoで生成された記事はそれぞれのブログポスト以外に、タグごとのページも生成されています。 こちらも実はAlgoliaのインデックスに登録されていて、タグを入力すると、タグ名のリンクが出てきます。\nこちらはelasticsearchで検索したときの検索結果です。1件目はタグページです。\nこれらのページはAlgoliaに登録しないようにするのが良さそうかな?と考えているところです(考えてるだけ)。\n2020/01/29更新\nlist.algolia.jsonを編集して、記事だけをインデックスするように修正しました。 テーマに存在するlayouts/_default/list.algolia.jsonを、自分のところにコピーし、次のように変更しました。if文を1行追加して、postという種類のものだけを出力するようにしました。\n{{/* Generates a valid Algolia search index */}} {{- $.Scratch.Add \u0026#34;index\u0026#34; slice -}} {{- $section := $.Site.GetPage \u0026#34;section\u0026#34; .Section }} {{- range .Site.AllPages -}} {{- if or (and (.IsDescendant $section) (and (not .Draft) (not .Params.private))) $section.IsHome -}} {{- if (and (eq .Section \u0026#34;post\u0026#34;) (ne .URL \u0026#34;/post/\u0026#34;)) -}} {{- $.Scratch.Add \u0026#34;index\u0026#34; (dict \u0026#34;objectID\u0026#34; .UniqueID \u0026#34;date\u0026#34; .Date.UTC.Unix \u0026#34;description\u0026#34; .Description \u0026#34;dir\u0026#34; .Dir \u0026#34;expirydate\u0026#34; .ExpiryDate.UTC.Unix \u0026#34;fuzzywordcount\u0026#34; .FuzzyWordCount \u0026#34;keywords\u0026#34; .Keywords \u0026#34;kind\u0026#34; .Kind \u0026#34;lang\u0026#34; .Lang \u0026#34;lastmod\u0026#34; .Lastmod.UTC.Unix \u0026#34;permalink\u0026#34; .Permalink \u0026#34;publishdate\u0026#34; .PublishDate \u0026#34;readingtime\u0026#34; .ReadingTime \u0026#34;relpermalink\u0026#34; .RelPermalink \u0026#34;html\u0026#34; .Params.Description \u0026#34;title\u0026#34; .Title \u0026#34;type\u0026#34; .Type \u0026#34;url\u0026#34; .URL \u0026#34;weight\u0026#34; .Weight \u0026#34;wordcount\u0026#34; .WordCount \u0026#34;section\u0026#34; .Section \u0026#34;tags\u0026#34; .Params.Tags \u0026#34;categories\u0026#34; .Params.Categories \u0026#34;author\u0026#34; .Params.authors \u0026#34;content\u0026#34; .Params.Description \u0026#34;excerpt_html\u0026#34; .Params.Description \u0026#34;excerpt_text\u0026#34; .Params.Description \u0026#34;summary\u0026#34; .Summary)}} {{- end -}} {{- end -}} {{- end -}} {{- $.Scratch.Get \u0026#34;index\u0026#34; | jsonify -}} まとめ これで、ブログ内記事検索ができるようになります。 Algoliaは個人の非商用利用の場合、フリープランが用意されているのがありがたいですね。 まだ、Hugoと連携しただけで、Algolia自体でどんな機能があって、どんなことができそうかといったところは調べていませんが、簡単に利用できるのはとても助かります。\nまぁ、個人ブログの検索機能ってそんなに使う人はいないんですが、自分としては便利かなぁと。\n","date":1580186404,"dir":"post/2020/","id":"d9018f459d3c94a91e92b459e152f7e7","lang":"ja","lastmod":1580283604,"permalink":"https://blog.johtani.info/blog/2020/01/28/introduce-algolia/","publishdate":"2020-01-28T13:40:04+09:00","summary":"ブログ移行日記(その4)です。その他の記事はこちら。 ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(","tags":["ブログ"],"title":"ブログ移行日記(その4) - 検索機能(Algolia)の導入"},{"contents":"ブログ移行日記(その3)です。その他の記事はこちら。\nブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その4) ブログ移行日記(その5) 今回は、Hugoの設定とテーマの一部変更した点について記載します。\n設定ファイル(config.toml) Hugoの設定ファイルはconfig.tomlになります。hogo new siteコマンドで生成したディレクトリの中にデフォルトで含まれていますが、こちらではなく、テーマの作者が用意してくれたconfig.tomlを元に変更を加えました。\nちなみにテーマの作者の方が設定とコンテンツを含めたサンプルも公開してくれています。設定やディレクトリの構成はこちらを参考にしました。\n設定ファイルで変更した項目は以下のとおりです。\nサイトのタイトルや説明など 特記することはありません。好きなように変えました。\nbaseurl title SEOTitle description keyword slogan sidebar_about_descrption 画像関連(ヘッダーや著者近影) 画像の置き場はstatic/images/ディレクトリですが、設定ファイルには images/から設定します。\nheader_image : ブログのヘッダー背景 sidebar_avatar : 著者近影 言語周り(特に多言語対応する予定は無いのですが) languageCode = \u0026ldquo;ja\u0026rdquo; defaultContentLanguage = \u0026ldquo;ja\u0026rdquo; オフにした機能、削除した項目 freands = false bookmarks = false 上記の設定変更以外に、[[params.bookmark_link]]や[[params.friend_link]]も削除。\n中国のサービスや、特化した設定など。\nBaidu Analytics関連 Disqus proxy関連 Reward(wechat pay \u0026amp; alipay関連) params.social関連 rss = true twitter linkedin github ほかはすべてコメントアウト。\n外部サービス関連 disqusShortname : Disqusのショートネーム googleAnalytics : Gooogle AnalyticsのトラッキングID algolia関連 : 別のブログ記事として、設定方法などを書きます。 追加した設定(昨日のブログで説明済み) Octopressと同じ形のパーマリンク [permalinks] post = \u0026#34;/blog/:year/:month/:day/:slug\u0026#34; Markdownファイル中のHTMLタグ表示 [markup.goldmark.renderer] unsafe = true 以上が設定ファイル関連です。\nテーマの変更点 テーマそのままでは問題があったり、独自に変更したいという点があったので、いくつか変更をしています。\nフォントの変更 そのままテーマを適用するだけでうまく行けばよかったのですが、フォントの問題が発生しました。テーマの作者の方が中国の方だから?かどうかはわかりませんが、デフォルトのままだと中華フォントになってしまいました。\nあー、中華フォントだな。 pic.twitter.com/OvHpY4LSp1\n\u0026mdash; Jun Ohtani (@johtani) January 16, 2020 config.tomlにcustom_cssという設定があり、こちらで指定したCSSのファイルがテーマのlayouts/partials/head.htmlから読み込まれる仕組みがあるようなので、フォントに関するCSSをこの機能を使用して指定するようにしました。\nconfig.tomlの設定は次のとおりです(リスト)になっているので、複数のファイルに分割して、読み込ませることも可能なのかな?。\ncustom_css = [\u0026#34;css/custom-font.css\u0026#34;] cssファイルについては、static/css/custom-font.cssというファイルを作成し、次のような記載になっています。 フォントの指定と右側サイドバーの自己紹介の部分の文字色を変更するためのものです。\nbody, h1, h2, h3, h4, h5, h6, .navbar-custom { font-family: Helvetica,\u0026#34;Sawarabi Gothic\u0026#34;,Meiryo,\u0026#34;メイリオ\u0026#34;,\u0026#34;Hiragino Kaku Gothic ProN\u0026#34;, \u0026#34;ヒラギノ角ゴ ProN\u0026#34;,YuGothic,\u0026#34;游ゴシック\u0026#34;,Arial,sans-serif; } .sidebar-container { color: #404040; font-size: 14px; } faviconの変更 テーマにfavicon.icoが含まれていたのですが、せっかくなので独自のものに変えてみようかと。 ただ、残念ながら、こちらはパスおよびファイル名がlayouts/partials/head.htmlに直書きされていました。\n画像はimages配下にと思っていたのですが、このパスだけを変更するためにhead.htmlを自分の配下にコピーしてカスタマイズするのもどうかと思った(テーマに変更やバグ修正が入るたびに手動でコピーするのはなぁと思った)ので、static/img/favicon.icoファイルを作成しました。\nテーマよりもHugoのプロジェクトにあるファイルを優先するようなので、ファイルだけをプロジェクトに作成しました。\n記事一覧のテンプレート 記事の一覧で表示される、作成者と作成日時が英語表記でかつ、冗長な感じがしたので、スッキリさせるために、layouts/partials/post_list.htmlをテーマからコピーして、次のように変更しました。\n元の形式は : Posted by author Monday, January 2, 2006 現在の形式 : 2006-01-02 by author 記事のテンプレート 今回採用したテーマでは、記事の先頭に記事のセクションを元に目次を生成してくれるものでした。\n目次をコンテンツから自動で作ってくれるの便利だな。 pic.twitter.com/9bU3sLnUrm\n\u0026mdash; Jun Ohtani (@johtani) January 16, 2020 とても便利です。ただ、表示が「TOC」なんです。 英語でしかも「ToC」という表記ならまだ気にならなかったかもですが、大文字だと流石に気になったので、プロジェクトのlayouts/_default/single.htmlにコピーして「目次」という日本語に書き換えました。 このHTMLにテーマで修正が入った場合はどうしようかなぁ。。。というのが目下の悩みです。。。\nArchetypeテンプレートの追加 最後は新規記事を書くときに生成されるMarkdownのメタデータの追加です。 HugoにはArchetypesというのが存在します。\nHugoではhugo new 記事としたときに、記事の種類(content/ディレクトリ名=記事のタイプ)によって、作成するmarkdownファイルをテンプレートから生成する機能があります。この生成時に使われるのがarchetypesというディレクトリにあるファイルです。\n私のブログサイトでは、今のところcontent/postというブログの記事だけを書く予定ですので、archetypes/post.mdというファイルを作って以下のようなメタデータをhugo newしたときに自動で生成するようにしました(テーマにあったpost.mdファイルの代わり)。\n--- layout: post title: \u0026#34;{{ replace .Name \u0026#34;-\u0026#34; \u0026#34; \u0026#34; | title }}\u0026#34; slug: \u0026#34;{{ substr .Name 11 }}\u0026#34; author: johtani date: {{ .Date }} comments: true tags: [] draft: true --- タイトルはファイル名のハイフンを空白に変換したもの(実際にはファイル名は英語にしているので、使いませんが。。。) slugはファイル名の先頭からYYYY-MM-DD-という11文字を除いたもの。これは、OctopressのURLに合わせるために使用するURLの一部の文字列です。 author: johtani : 著者は私だけだから固定文字列 comments: true : ブログ記事にはDisqusのコメント機能を利用 tags: [] : 各内容によってタグを付けるが、生成時には空 draft: true : 明示的にこの行を消すまではドラフト記事としたいため という感じです。ほかにどのよなメタデータがあるのかまではまだ調べていないので、今後また適宜変更していくと思います。\nまとめ Hugoの設定や、テーマそのままではなく独自の変更を加えた部分を思い出して書き出してみました。\nこれで、Algoliaに関する部分以外はだいたい思い出して書いたと思います。 次は、Algoliaの使い方と設定について書き残す予定です。\n","date":1579853081,"dir":"post/2020/","id":"99c9c80a6532e4ea3b535c5a92d07a25","lang":"ja","lastmod":1579853081,"permalink":"https://blog.johtani.info/blog/2020/01/24/setting-hugo/","publishdate":"2020-01-24T17:04:41+09:00","summary":"ブログ移行日記(その3)です。その他の記事はこちら。 ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その4) ブログ移行日記(","tags":["ブログ"],"title":"ブログ移行日記(その3) - Hugoの設定と微調整(テーマに合わせた)"},{"contents":"その他の記事はこちら\nブログ移行日記(その1) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) ブログ移行日記(その2)です。前回はHugoとは?というのと、自分が選んだテーマについて記載しました。 本家の手順などを参考にすると、Hugoにテーマを適用し、でHTMLを生成して、表示するところまでできるはずです。\n今回は、OctopressのmarkdownファイルをHugo用に変換する方法について紹介します。お手製ですが、Pythonスクリプトを作ったので、そちらも合わせて簡単に紹介する予定です。\n参考ブログ 「Octopress Hugo 移行」でググるといくつか出てきます。先人の知恵ありがたいですね。 ということで、私はこちらの2つのブログを参考にさせていただきました。ありがとうございます。\nOctopress から Hugo へ移行した - iriya-ufo\u0026rsquo;s blog OctopressからHugoへ移行する方法 | gam0022.net 画像のコピー 画像はそのまま上記参考ブログを元にsource/imagesからstatic/imagesにコピーしました。特にディレクトリ構造の変更とかもしませんでした。\nコンテンツのコピー こちらは、コピーのタイミングでいくつか変換などの処理を行いました。 ファイルの変換にはPythonのスクリプトを書きました。 自分向けの移行ツールなんで、ディレクトリ名とか引数にすらしてないです。。。\n参考ブログと同様の変換\nメタデータの日付変換 categoriesをtagsに変換 画像タグの変換 タイトル、画像のサイズなどに合わせていくつか分岐があります。 参考ブログとは異なる変換、変更\nコードブロックは無変換 0.60.0からCode Fencesに対応したみたいなので不要でした。 ディレクトリ構造の変更 ファイルを年ごとのディレクトリに格納(これまでは、全てのファイルが同一ディレクトリにあった) 拡張子の変更 (.markdown -\u0026gt; .md) メタデータにauthorの追加(自分しか書かないんですけどね) URLをOctopressに合わせる Google検索からの流入もあり、これまでのURLに変更はかけたくないなと。 こちらも参考ブログに記載があるので、そのまま参考にさせていただきました。\nslugについては、移行ツールでファイル名を元に追加する処理を書きました。\nHTMLを含んだMarkdownの対応 TweetやAmazonのアフィリエイトのリンクがHTMLタグでいくつかの記事に含まれており、デフォルトの設定だと表示されません。 config.tomlファイルに以下の設定を追記することで、出力されるようになりました。\n[markup.goldmark.renderer] unsafe = true 名前がunsafeなので、ちょっと気になりますが。。。 すべての記事を表示してチェックしてみたわけではないので、おかしな記事を見つけた方は連絡をいただけると助かります。\nまとめ OctopressのファイルをHugo用にコピーや変換した方法を思い出しながら書いてみました。基本的には参考ブログに上げた2つのブログを真似したものになります。\n次は、利用したテーマのサンプル設定を元に、自分用に変更した点などについて書き残しておこうかな?\n","date":1579775514,"dir":"post/2020/","id":"018b365b00dd3a6ad17c813d21590549","lang":"ja","lastmod":1579775514,"permalink":"https://blog.johtani.info/blog/2020/01/23/convert-md-from-octopress-to-hugo/","publishdate":"2020-01-23T19:31:54+09:00","summary":"その他の記事はこちら ブログ移行日記(その1) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) ブログ移行日記(その2)","tags":["ブログ"],"title":"ブログ移行日記(その2) - Markdownファイルの変換"},{"contents":"その他の記事はこちら\nブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) 起因 いつものツイートから始まる私の行動です。\n(もしかしたら前に一度おすすめしたかもですが) Goのtemplate構文に拒絶反応がなければHugo割と良いですよ〜。\n\u0026mdash; Nobuyuki Kubota (@nobu_k) October 10, 2019 ってことで、Hugo勧められたし、テーマが豊富だしということで、乗り換えた次第です。\n(元)同僚に教えてもらった記事を見てる。Gatsbyも気になるんだけど、デザインセンスないし、テーマが豊富なのがいいなぁ。/ Comparison of Gatsby vs Jekyll vs Hugo | GatsbyJS - https://t.co/yUbKiBmtMS\n\u0026mdash; Jun Ohtani (@johtani) January 9, 2020 一応Gatsbyのサイトにあった比較も見たのですが、テーマの豊富さが勝ちました。デザインを自分でやれるほどではないので。\n理由 乗り換えるに至ったのは主に2つの理由です。\nOctopressが更新されていない ページが増えてきてサイトの生成に時間がかかる 前に使っていたOctopressもJekyllというものがベースになっていました。 Jekyllは今でも更新があるのですが、Octopressが更新されなくなってしまったのと、Rubyがベースになっているため?なのかはわかりませんが、 ブログのページ数が増えてきて、サイトのビルドに時間がかかってくるようになりました。\n結果 まだ、改良点があるかもですが、とりあえず公開できる感じになったと思ったんで切り替えました。\n前のブログはこんな感じで、\n移行後はこんな感じです。\nHugoとは? 公式サイト こちらにあるように、Go言語で実装されているウェブサイト構築フレームワークです。 Go言語で実装されているのもあり、インストールが簡単でした。 Macを使っていますが、Homebrewでインストールができてしまいます。 他の方法もあるようでしたが、Emacsをインストールするのにbrewを入れているので、brewでインストールしました。\n使い方は色んな人が書いてるし、公式ドキュメントを見ていただけばいいかな。\nテーマとは? Hugoのサイトにテーマの一覧があります。 一応、個人のブログなので、それなりにデザインを入れつつ、他の人と違う感じにしたいなと。 テーマ一覧をざっと眺めて良さそうなのをピックアップしたら、最終的にこちらのテーマになりました。\nClean White それなりに更新されてますし、DisqusとSearch(Algolia)が使えるのでこのテーマに決めました。 テーマのインストール方法などはGitHubのREADMEの「Quick Start」に記載があります。\n私は、Hugo自体の設定などをGitHubで管理したかったので、git submoduleを利用して、次のような構成になりました。\nhugo - main repository ├── archetypes ├── content ├── data ├── layouts ├── public - github.com/johtani/johtani.github.io ├── resources ├── static └── themes └── hugo-theme-cleanwhite - github.com/zhaohuabing/hugo-theme-cleanwhite.git hugo : hugo new siteコマンドで作成されたディレクトリです。このディレクトリでまずgit initしました(このリポジトリはプライベートで管理してます)。 themes/hugo-theme-cleanwhite : テーマのQuick Startにあるgit submodule addコマンドでサブモジュールとしてテーマをインストールしました。 public : hugoが生成するHTMLのトップのディレクトリがこちらです。私はGitHub pagesを利用してブログを公開しているので、git submodule addでjohtani.github.ioをサブモジュールにしました。 Hugoで生成したHTMLなどをGitHub pagesで公開するときの手順などはHugoのドキュメントに記載がありました。\nまとめ Hugoに移行した理由や、Hugoとテーマの簡単な紹介でした。 テーマが豊富なのはデザイン力(りょく)がない身としてはありがたいですよね。 次はOctopressのmarkdownファイルをHugo用に変換したり、それに関する設定周りの話を書く予定です。\n","date":1579659814,"dir":"post/2020/","id":"a65bd31d4c3dab0a41712823a5d6002b","lang":"ja","lastmod":1579659814,"permalink":"https://blog.johtani.info/blog/2020/01/22/intro-hugo-and-theme/","publishdate":"2020-01-22T11:23:34+09:00","summary":"その他の記事はこちら ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) 起因 いつものツイートから","tags":["ブログ"],"title":"ブログ移行日記(その1) - Hugoとテーマ"},{"contents":"5年くらい、Octopressを使用していましたが、更新されなくなっているのと、コンテンツの生成に時間がかかることもあり、 ほかのプラットフォームを使用するように変更しました。\nとりあえず、今回の移行で参考にした記事とかURLをリストアップしてみました。 詳細についてはまた明日以降で。\n参考記事 移行関連 : https://iriya-ufo.net/blog/2018/12/27/octopress-to-hugo/#github-pages- 移行関連 : https://gam0022.net/blog/2016/09/25/migrated-from-octopress-to-hugo/ Hugo自体の日本語紹介記事 : https://knowledge.sakura.ad.jp/22908/ Hugo概要 https://gohugo.io/ テーマ 一覧 : https://themes.gohugo.io/ 利用したテーマ : https://github.com/zhaohuabing/hugo-theme-cleanwhite データ移行 作ったスクリプト : https://github.com/johtani/from-octopress-to-hugo favicon 作ったサイト : http://emblemmatic.org/markmaker/#/ Algoliaセッティング 参考 : https://blog.uni-3.app/2019/01/02/hugo-algolia-search/ GitHub Pagesでの運用 https://gohugo.io/hosting-and-deployment/hosting-on-github/#types-of-github-pages 残タスク Amazonのアフィリンクをきれいに表示するlayoutか何かを用意する?　","date":1579166617,"dir":"post/2020/","id":"3c299a4d77be8b4f886ce9fcd23a2561","lang":"ja","lastmod":1579166617,"permalink":"https://blog.johtani.info/blog/2020/01/16/moving-to-hugo/","publishdate":"2020-01-16T18:23:37+09:00","summary":"5年くらい、Octopressを使用していましたが、更新されなくなっているのと、コンテンツの生成に時間がかかることもあり、 ほかのプラットフォ","tags":["hugo","ブログ","octopress"],"title":"OctopressからHugoへ移行中(まだ途中)"},{"contents":"今年も振り返りブログ書いてます。Sasukeがついてる。\n振り返り（2018年に書いた抱負から） まずは去年の抱負を元に。\nTOEIC 受けました。\nお。TOEICの点上がってた（まだまだだけど。。。）\n\u0026mdash; Jun Ohtani (@johtani) October 21, 2019 無事、上がってました。テストの点数を上げるのが目的ではなく、今の実力が どんな感じかというのを確認するために受けました。 前回までが低かったのもあるんですが。 また、数年後に受けてみるのかな?\nCfP見つけて応募 \u0026amp; いろんな場所に顔を出す 色んな所には顔を出しました。 CfPはそれほど出せていなく、とちぎRubyとDevRelJPで喋った程度かと。 12月に最終出社日を迎えたので、今後は顔を出したりCfP見つけて応募も、 一旦休憩に入る予定です。\nもっとブログ！ 12月に入ってから、一気に増えてますねw Elasticでは結局それほどかけなかったなぁ。\nRustの継続 こっちは、書籍も買ったのに手がついてないです。 来年に書籍を読みながら再入門する予定です。\n開発の継続 一応ほそぼそと続けてますが、メンテナンスですね。 Analyzer向けのKibanaのプラグインのバージョンアップにだけ対応していたり。 年初にReact化には着手しました。 あとは、Luceneにちょっとしたパッチ(Lukeの画面とKuromojiのUniDic対応)を送った感じかな。もっとLucene周りやりたいかな。\n日本でエンジニア獲得! トレーナーやエンジニアが入社してくれました! が、私が退職してしまいますが。。。 私自体が次のステップに移らないとなぁと。 Elasticに興味がある人いたら、中の人を紹介できるので声をかけてください!\n振り返り(今年あったできごと) さて、ここからは今年の出来事を。\n検索技術勉強会発足 勉強会運営座談会 初フロリダ 初カナダ\u0026amp;初ナイアガラの滝 退職(予定) 検索技術勉強会ってのをはじめました(はじめましたブログはこちら)。 やっぱり検索の話を聞いたり考えたりするのが好きなので、もっといろんな話を聞く機会がほしいなぁと。ツイートすると何人かの知り合いが手を上げてくれたので、初めて見たのが2月でした。 所属会社もあったので、自分が全面に出ない形で運営に協力するという形式でやっています。なんだかんだでもう4回も開催できています。スピーカーへの声掛けなど、複数人で運営するとそのあたりが多様性が出るし、楽になるのですごくいいなぁと。 来年も2月か3月にやりたいねと話をしているところです。興味のある方は、ぜひスピーカーを!\nで、その流れで、他の勉強会の運営ってみんなどうしてるんだろう? という疑問も出てきたので、勉強会運営座談会なるものもやってみました。少人数で集まって、勉強会の運営ってどんなやり方してます?どんなことに困ってます?みたいなのを共有してみました。 自分自身がそれほど、ほかの勉強会の運営に顔を出してたわけでもなく、やり方をみんなはどうやって共有してるのかなぁ?というのが気になったので。 思った以上に属人化してるのかもなぁというのが感想でした。 ドタバタしてたので、あれからやってませんが、共有する勉強会みたいなのも面白いのかも?\n今年も2回ほどElasticの社内イベントで海外に行かせてもらいました。 5月にフロリダと11月にトロントでした。 フロリダでは、NASAにも行けたし、トロントでは足を伸ばしてナイアガラの滝を見に行くなどもしてみました。こういう機会が定期的にあるのは、いいですよねぇ。\n最後は、退職イベントですね。5年5ヶ月勤めたElasticでの仕事が、12/6で最終出社日でした。実際の退職日は1/24となっています(現在有給休暇消化中)。長かったような、短かったような。日本で1人目で入社してさまざまなことをやらせてもらい、本当に色んな経験ができました。英語も上達したし。 ただ、外にいることでできることがありそうだなと感じたこともあってのこの決断でした。\n最終出社日以降、色んな人とランチさせてもらったりしています。 次に何をやろうかな?ってのんびり考えながら休んでいるところなので。 やっぱり、検索周りのことをやりたいなぁというのが念頭にあるので、そのあたりで模索中という感じです。 が、せっかくの機会なので、少しのんびりしようかなとも思ってます。 なので、プラモデルの作成や配達業(デス・ストランディング)をやってみたり、16インチMacbookのセットアップしながらブログ書いたりしています。 年明けに入ったら、プログラミングもちょっとやりたいな。\nあとこの場を借りて、ブログの欲しい物リストのものを送っていただいた皆様に感謝を述べさせていただきます。本当にありがとうございました!この感謝はまた何かの機会にでも!\n来年の抱負 ということで、来年の抱負です。\n職につく ブログプラットフォームの移行 プログラミング Rust再入門 検索の勉強 検索技術勉強会の継続 まぁ、まずは職につかないとですね。どこかに在籍しつつ、副業で検索周りのこととかやるのもありかもなぁと考えたりしています(プラモデルつくりながらw)。\nブログのプラットフォームをOctopressからHugoあたりに移行しようかなと思ってます。Octopress自体がもう開発がされてないようですし。Hugoだとテンプレート?テーマ?がそれなりにありそうなので良さそうかなぁと。移行プログラムも書かないとかな。新しいものを調べるのって楽しいですよね。\nプログラミングも復活させたいなと。どうしてもこれまでは、しゃべるのをメインにしていたので、後回しにしてしまっていたのもあります。まぁ、向いてないのかもと思ったりもしますが、下手の横好きなりに少しずつでも何かを改善したり作ったりしたいなと。 勉強会の運営周りですこし楽をするためのプログラム書いたりもしているので、この辺もブログに書こうかな?\nRustはTantivyというプロダクトも出てきているし、勉強しようと思って、自転車本を買いつつ、Kindleの肥やしにしているので、手を動かそうとおもいます。 ブログ書いてサボった場合の可視化しないとなw\n検索の勉強もやりたいなと。これまではElasticsearchに注力していましたが、ほかのプロダクトやサービスも調べてみたいなと。教えを請いに皆さんのところにお邪魔するかもしれないので、そのときは優しくしてください。\n今年始めた検索技術勉強会を今後も継続できるようにしたいなと。 で、運営周りを楽にできるような仕組みをもう少し導入できればなぁと考えていきたいなと思います。\nさて、嵐の曲も始まったし終わりです。\n今年も様々な方々に助けていただきました。また、最終出社日以降にランチを一緒にさせていただいたり、遊びに行かせていただいたりとありがとうございました。年明けもひましてるので、ぜひランチしましょうw\n来年はなにやってるんだろうなぁ? 今後も皆さんよろしくおねがいします!!\n","date":1577764743,"dir":"post/2019/","id":"35aa9e09db936aee7ec407c431816573","lang":"ja","lastmod":1577764743,"permalink":"https://blog.johtani.info/blog/2019/12/31/looking-back-2019/","publishdate":"2019-12-31T12:59:03+09:00","summary":"今年も振り返りブログ書いてます。Sasukeがついてる。 振り返り（2018年に書いた抱負から） まずは去年の抱負を元に。 TOEIC 受けました。 お。TO","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2019）"},{"contents":"このブログ書こうと思って、これまでMacのセットアップしてたんだった。。。\n普段、macOSの標準ターミナルを使ってます。 で、ターミナルを使うシーンは次のような感じです。\nブログのデプロイ（参考：Octopress環境のDockerイメージ化） ElasticsearchとKibanaの動作確認 Elasticsearchの起動用ターミナル Kibanaの起動用ターミナル プラグインの開発(elasticsearch-ingest-csv と analyze_api_ui) elasticsearchのリポジトリ kibanaのリポジトリ ingest-csvのリポジトリ analyze_api_uiのリポジトリ 上記のように1.以外については複数のターミナルをそれぞれのディレクトリで起動して使っています。 これらの3つのパターンのときに、毎回ターミナル(シーンによっては複数のウィンドウ)を開いて、ディレクトリに移動って大変だなと。\nウィンドウグループって？ そこで、ターミナルに便利な機能がないのかな?と思い、メニューを見ていたところ「ウィンドウグループ」というのがあったので調べて、現在の使い方に至っています。\nウィンドウグループの使い方の説明はこちらです。\n使い方にあるようにウィンドウの場所、設定、タブなどを保存できます。 そして、「ウィンドウグループを開く」というメニューから保存しておいたグループを開くと、簡単に作業環境が再現可能になります。\n開くときのメニューはこんな感じです。\n作り方 ウィンドウグループの使い方に載ってます。 まずは、保存したいターミナルを開いて、開いたときに移動していたいディレクトリに移動します。 複数のタブやウィンドウを開いた状態にしたい場合は、複数ターミナルを起動して、それぞれ移動したいディレクトリに移動しておきます。\nグループとしてまとめたいウィンドウが起動できたら、あとは、「ウィンドウ」メニューの「ウィンドウをグループとして保存」を選択します。\nこれだけです。あとは、使いたくなったときに開くだけです。 簡単ですよね?\n作るときの注意点としては、複数のウィンドウグループを作りたいときは、 それぞれグループごとに作成しては、個別にやる必要があります。 現在開いているターミナルのうち、あれとこれをウィンドウにしたいというやり方はできないので、そこだけ注意点です。 環境ごとにプロファイル(バックグラウンドの色やテーマ)を覚えさせることができるので、1.のシーンだとIceberg、2.のシーンではBasic、3.のシーンではHomevrewで設定していたりします。 (ただ、Preztoのテーマをagnosterにしてしまったので、Basicだとプロンプトが見にくくてしょうがないのですが。。。)\n設定はどんな感じ？？ ウィンドウグループの管理については、ターミナルの「環境設定」に管理用の画面があります。\nこの画面でいらないグループを削除したり、設定のエクスポート/インポートも可能です。\n私の使い方 3つの利用シーンは説明しました。 すべてのウィンドウグループを変更するたびにインポート/エクスポートしてます。 上記1.と3.のユースケースはほぼ変更がないので、エクスポートしたものを移植用に管理していますが、2.のユースケースについては、頻繁に更新しています(ElasticsearchとKibanaのバージョンをアップしないといけないので)。\nこのとき、MacのGUIで毎回設定をしているわけではありません。 エクスポートしたファイルは、.terminalという名のXMLファイルになっています。\nその中に、次のようなパスが記述されています。このバージョン番号の部分をアップデートのたびにemacsなどで変更し、ターミナルの管理画面で、削除してからインポートし直すだけで、バージョンアップに対応している感じです。\n\u0026lt;key\u0026gt;Tab Working Directory URL\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;file://johtani-mac-15.local/Users/johtani/tmp/elastic_stack/v7.5/elasticsearch-7.5.1/\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Tab Working Directory URL String\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;file://johtani-mac-15.local/Users/johtani/tmp/elastic_stack/v7.5/elasticsearch-7.5.1\u0026lt;/string\u0026gt; まとめ ということで、標準ターミナルのウィンドウグループを使うと、よく開くディレクトリやウィンドウ、タブを覚えて置かせることができるので、それぞれの環境向けのターミナルを、好きなときに開くことができるようになります。 私は、ウィンドウは1つで複数のタブをウィンドウグループという形で覚えさせておくことで、各シーンの切り替え、もしくは併用を閉じたり開いたりを簡単にできるようにしています。\n他のターミナルソフトを使うと似たようなことが簡単にできたりするのかな? みなさんがどうやってこのような作業やってるのかな?ってのはちょっと気になるところです。\n余談（いつものようにツイートとその反応） ちなみに、みんなどんなターミナル環境なんだろう？と思いツイートしてみた結果はこちらです。 (コメントRTってうまいことひろえないのかなぁ？)\nMac標準のターミナル使ってる人ってどのくらいいるんだろ？iTermとか入れてるのかな？tmuxとか？\n\u0026mdash; Jun Ohtani (@johtani) December 11, 2019 Iterm2使ってtmux使って今はIterm2だなー\ncommand2回押すだけでターミナル出すくせが抜けん https://t.co/P8o4M1HSoj\n\u0026mdash; GO☆ | TAFDATA (@_gogoponz) December 11, 2019 Alacritty + tmux やなー。標準はもう使ってない。 https://t.co/HI7hPCg3uo\n\u0026mdash; Ryo HIGASHIGAWA (@biwakonbu) December 11, 2019 標準です https://t.co/W27e2pcq3j\n\u0026mdash; shin higuchi @Acroquest (@shin0higuchi) December 11, 2019 Macを買って以来、ずっと結局標準ターミナル以外使っていない感じ。珍しかったのか。。 https://t.co/Zjz32SgjC6\n\u0026mdash; Kazuhiro Hara™ (@kara_d) December 11, 2019 ","date":1577063679,"dir":"post/2019/","id":"1a1a8cc0040b356d06eacd22e0526476","lang":"ja","lastmod":1577063679,"permalink":"https://blog.johtani.info/blog/2019/12/23/whats-window-group-of-terminal/","publishdate":"2019-12-23T10:14:39+09:00","summary":"このブログ書こうと思って、これまでMacのセットアップしてたんだった。。。 普段、macOSの標準ターミナルを使ってます。 で、ターミナルを使う","tags":["misc"],"title":"macOS標準のターミナルのウィンドウグループが便利"},{"contents":"ドットファイル系（.emacsとか）をこれまでは、PCを引っ越すたびにコピーしてたんですが、いいかげん、GitHubとかで管理したいなと。\nで、ツイートしたところ（こればっかりだなｗ）、homeshick(homesick)が便利だよとの情報を得たので使ってみました。\nhomesick、正確にいうとhomeshickを使ってます。悪くないです\n\u0026mdash; 🤓k.bigwheel🤓 (@k_bigwheel) December 10, 2019 使い方とか 実物はGitHubで公開されていました。\nhttps://github.com/andsens/homeshick\n何者かというと、ホームディレクトリにあるドットファイル(.zshrcなど)をgitコマンドで管理するのを楽にしてくれるシェルの関数群みたいです。 インストールは至ってかんたんで、git cloneで持ってくるだけです。homeshickのリポジトリのREADMEに記載があります。\n使い方はTutorialsにあります。\nhomeshick generate ほげほげで管理する単位（castle）を作ります。ほげほげが名称です。今回私はdotfilesにしました。 homeshick track ほげほげ .zshrcで管理したいファイルを指定します。すると、homeshickが対象のファイル（ここでは.zshrc）をcastleの保存先ディレクトリにコピーしてから、シンボリックリンクをホームディレクトリ上に作ってくれます。 homeshick cd ほげほげで、castleの実際のディレクトリに移動します。実態は.homeshick/repos/ほげほげです。 git remoteコマンドでcastleとGitHubの関連をつけて、あとは、普通にgitコマンドでコミットしたりすればOKです。 すごく簡単に導入できました。あとは、実際にtrackしたいファイルを追加していく感じです。 現状は、.zshrc、.gitconfigあたりを管理しています。 ついでに、homebrewでインストールしたものもbrew bundle dumpで出力して、homeshickで管理することで、brewでインストールしたものの管理もできそう（参考）。\nってことで、至極かんたんでした。すばらしい。\n参考 homeshick Tutorials Qiita : homeshickを使ったdotfilesの管理 ","date":1576624266,"dir":"post/2019/","id":"80c8fca02ebfecc7a931dad1ec38466e","lang":"ja","lastmod":1576624266,"permalink":"https://blog.johtani.info/blog/2019/12/18/introduce-homeshick/","publishdate":"2019-12-18T08:11:06+09:00","summary":"ドットファイル系（.emacsとか）をこれまでは、PCを引っ越すたびにコピーしてたんですが、いいかげん、GitHubとかで管理したいなと。 で","tags":["misc"],"title":"homeshick導入"},{"contents":"Macbook Proが新しくなり、OSがCatalinaになっちゃいました。 これまで使ってた、.bash_profileをコピーしてターミナルを立ち上げたところ、 なんか色々と設定が動いてないな？と思ったら、zshがデフォルトに切り替わってました。\nということで、デフォルト変わったし、時間あるしzshってどんな感じなのか調べてみようと。\n準備前（ツイート） で、ツイートをしたところ、海外の方？より返信が来ました。\nI have a series of posts explaining the transition: https://t.co/dz8QNjxxGf\n\u0026mdash; Scripting OS X (@scriptingosx) December 10, 2019 おもしろそうなので、ざっくりと読んでみました。zshを利用されているTwitterの知り合いの何人かからはzsh + oh-my-zshがいいよとコメント頂いてたんですが、\nMoving to zsh Catalinaからzshがデフォルトになるからと、手元の環境を変更するための話をブログにまとめてくれてます。\nMoving to zsh\nサラッと読んだので、いくつか抜粋すると\nbashでいくつか今設定しているものがあるのでその説明 alias - ファイルをそれぞれの拡張子ごとにアプリを切り替えてる（openコマンドの利用例があって参考になりました）。 functions - manコマンドのときに新しいWindowひらいたりとか shell settings - 大文字小文字関係なくファイル名をTabで候補を表示したり、historyをターミナル個別ではなく共有できるような設定にしたり prompt - 現在のディレクトリがどこかとか表示したり zshの設定ファイル群の説明 shellオプションの抜粋 といった感じでした（途中で読むのやめましたが。。。）\n面白かったのは、Suffix Aliasesです。 ファイル名だけをターミナルで指定すると、拡張子に応じて起動するコマンドを切り替えたりできると（結局まだ採用はしてないですがｗ）\n結局？ 結局、上記ブログを読んでいろんなオプションあるんだなぁ。と思ったのですが、手っ取り早く試すためにPreztoをインストールしました。 以下のような構成になってます。\nなるほど、これがzsh + prezto + powerline fontか。前までgit-promptを拾ってきてbashに組み込んでたけど、ブランチ表示されるし便利だな。 pic.twitter.com/Z2ArBgRZey\n\u0026mdash; Jun Ohtani (@johtani) December 12, 2019 Mac標準ターミナル Iceberg プロファイル Powerline font Prezto agnoster theme - prompt agnoster or ~/.zpreztorc の変更 .zshrcにいくつかaliasなどを追加。参考:gist Preztoのデフォルトでlessなどからエディタを立ち上げるとnanoが起動したので、vimに変更 Preztoが作る設定と自分の設定を混ぜたくなかったので、.zshrcでinit.zshを呼び出し になりました。フォントサイズだけはちょっと大きくしました（老眼ェ。。。） ターミナルの参考にさせていただいたブログは「preztoでzsh構築した時のメモ 」です。\nターミナルソフト(余談？) terminalも人によっては、色んなものを使ってたなと思いツイートしました。 結構みなさん標準のterminalを使ってるみたいでした。ただ、私が聞いたこともないターミナルソフトもちらほらあったので、色々あるんだなぁと。\nMac標準のターミナル使ってる人ってどのくらいいるんだろ？iTermとか入れてるのかな？tmuxとか？\n\u0026mdash; Jun Ohtani (@johtani) December 11, 2019 ","date":1576542903,"dir":"post/2019/","id":"f3ef819656f68b87a91c53afbd441fec","lang":"ja","lastmod":1576542903,"permalink":"https://blog.johtani.info/blog/2019/12/17/move-to-zsh/","publishdate":"2019-12-17T09:35:03+09:00","summary":"Macbook Proが新しくなり、OSがCatalinaになっちゃいました。 これまで使ってた、.bash_profileをコピーしてターミナルを立ち上げ","tags":["misc"],"title":"zshへの移行"},{"contents":"最近使っていたPCが手元からなくなったので、16インチ Macbook Proをセットアップしているところです。 で、時間もあるのでこれまでほったらかしてきた、このブログの環境をちょっと変更しようかなと。\nまずは、変更するにしても、Octopressのブログの環境自体は必要です。 実際に、移行する前のこの記事自体も書いているわけですし。\nただ、今後なくなる環境をローカル環境にセットアップするのもどうかと思い、Docker環境にしてみました。\n参考 \u0026ldquo;Octopress Docker image\u0026quot;でググって出てきたサイトを参考にしました。\n参考ブログ：Octopress in a Docker Container\nセットアップからDockerイメージのビルドまで Docker for Mac自体もインストールしていなかったので、インストールしておきます。 参考ブログの方がGitHubのリポジトリにDockerfileをアップしてくれているので、手順に従い、cloneします。 cloneしたDockerfileの3行目にENV LC_ALL C.UTF-8を追加します（UTF-8でブログを書いており、previewした場合にエラーが出たため） 参考ブログにある「Build the docker image」の手順に従い、Gemfile、.gitconfigをコピーしてイメージをビルドします。 参考ブログの「Rakefile」にあるように、自分のoctopress/RakefileのProcess.spawn(...)にアドレスを追加します（Dockerコンテナの外からアクセスできるように） 自分のoctopressにあるGemfile.lockを削除しました（ビルドしたイメージにはいるGemと一部バージョンが異なる記載のものがあったため） ここまでで、\nDocker run 実際にコンテナを実行するためのスクリプトを書きました（書いたと言っても参考ブログにある起動コマンドを叩いてるだけですが。。。）\nlaunch-octopress-docker.shというファイル名で以下のコマンドを実行してるだけです。\n!/bin/sh docker run -p 4000:4000 --rm --volume /Users/johtani/projects/blog/octopress:/octopress --volume /Users/johtani/.ssh:/home/blogger/.ssh -ti blog/octopress /bin/bash このシェルを起動すると、Dockerコンテナにbashで接続し、/octopressディレクトリにログインしています。 あとは、いつものようにrake new_post[\u0026quot;....\u0026quot;]で新規記事のテンプレートを作成したりすればOKです。\nrake generate; rake previewと実行してからローカルのブラウザでhttp://localhost:4000に接続すればプレビューも可能。\nということで、このDockerファイルとかを持っておけば、他の環境でもかんたんにOctopressの環境が再現できそうです。 先人の知恵有り難し。 これで、クリーンなまま他のブログ環境に移行できそう。\n追記(2019/12/17) Docker環境でいくつか問題があったので、追記しておきます。\nDocker for Macが再起動しない Docker for MacがCatalina環境だと問題があるみたいでした。 CPUの数やメモリの数を変更してDockerを再起動したところ、ずっとStartingのまま。\n解決方法としては、launchctlの設定に$PATHを追加するみたい。これで、問題なく起動するようになった気がする\nsshの設定ファイルの問題 .ssh/configにMacのKeyChainを利用する設定を記載してるんですが、Ubuntu上だとこの設定のせいで、エラーが出てしまいます。 IgnoreUnknownという設定で、知らないオプションがあったら無視するという設定になる模様。ということで、Dockerコンテナ上でrake deployのときにエラーが出てたのが解消できました。\n","date":1576458061,"dir":"post/2019/","id":"1abc586d67f0b6c05fd5e60f25492340","lang":"ja","lastmod":1576458061,"permalink":"https://blog.johtani.info/blog/2019/12/16/dockernize-octopress/","publishdate":"2019-12-16T10:01:01+09:00","summary":"最近使っていたPCが手元からなくなったので、16インチ Macbook Proをセットアップしているところです。 で、時間もあるのでこれまでほったらかしてきた","tags":["octopress"],"title":"Octopress環境のDockerイメージ化"},{"contents":"本日、Elasticでの最終出社日でした。実際の退職日はまだ先ですが、有休消化という感じです。\n思い返せばもう5年と5ヶ月も前ですが、Elastic（当時はElasticsearchって社名だった）に参加しました。\n社名も変わりましたし、プロダクトの数も増えたし、IPOもしました。 初の外資＋スタートアップということもあり、ものすごくエキサイティングな5年半でした。 Elasticを離れはしますが、検索自体にはまだまだ興味があるので、LuceneやElasticsearchになにかしら関わる感じのことをする予定です。 検索技術勉強会も今後もやっていきますし。\nただ、激動の5年半だったので、退職日までちょっとゆっくりしようと思っています。 次にどんなことをするのかはまた、別の機会にでも。\nおまけ ということで、まぁお約束です。\nほしい物リストはこちら\n","date":1575615090,"dir":"post/2019/","id":"1bbf2ef67f096960e13d8578fa544536","lang":"ja","lastmod":1575615090,"permalink":"https://blog.johtani.info/blog/2019/12/06/leaving-elastic/","publishdate":"2019-12-06T15:51:30+09:00","summary":"本日、Elasticでの最終出社日でした。実際の退職日はまだ先ですが、有休消化という感じです。 思い返せばもう5年と5ヶ月も前ですが、Elas","tags":["転職"],"title":"退職します"},{"contents":"これは、情報検索・検索エンジン Advent Calendar 2019 の 4 日目の記事です。\n1日目から、質の高いエントリーが続いていましたが、一旦休憩して頂く感じの記事になってます。気軽に読んでくださいw。Advent Calendarつくらないの？と煽ったのもあり、穴を埋めようかなと。　発端 ちょっと先ですがこういうのやります。実装寄りの話やOSS開発に興味がある方，きてください～ / Lucene 版 #Kuromoji のコードを読む会（辞書ビルダー編） https://t.co/NgEmUohoPo #kuromoji\n\u0026mdash; Tomoko Uchida (@moco_beta) September 6, 2019 「Lucene 版 #Kuromoji のコードを読む会（辞書ビルダー編）」という勉強会があり、参加したところ、UniDicの辞書のビルドがコケるという話を聞いたんで、ちょっとやってみるかと。\nちなみに、Kuromojiとは、Apache Luceneに入っている、日本語向けの形態素解析ライブラリです。IPAdicの辞書を内包しており、SolrやElasticsearchといった、Apache Luceneを利用している検索エンジンで手軽に使える形態素解析ライブラリになっています。が、対応している辞書がデフォルトだとIPAdicなのです。\n問題点 LUCENE-4056というIssueが上がっています。\nbuild.xmlには記載はないけど、辞書のビルダーは対応していそうな雰囲気を醸し出しているので、試してみたというのが発端？かと。で、実際に動かしてみると動かない点がありましたと。\nまた、Issueの会話で出ていたUniDicの辞書のライセンスの話もありました。 ただ、UniDicがライセンスを変更したので、このあたりはクリアできそうかなと。\nパッチ ということで、動かしてみていくつか修正してパッチを作りました。\nhttps://github.com/apache/lucene-solr/pull/935\n最近のLuceneはGitHubでプルリク遅れるのが便利ですね。 そんなに大したことはやってないです。以下の点が問題だったので直しています。\nIPAdicとUniDicで語彙定義ファイルのCSVの形式（カラムの数）が異なる unk.defのカラム数も異なる あとは、辞書のダウンロードの部分やbuild.xmlでの処理を追加した形です。 このプルリクを適用したlucene-solrのソースディレクトリを持ってきて、手元でjarをビルドすれば普通はIPAdicの辞書を内包したkuromojiのjarファイルが出来上がります。\nlucene/analysis/kuromoji/build.xmlファイルを、このGistにあるように変更して、ant build-dictとやれば辞書のビルドが可能です。 また、cd lucene/;ant jarとすれば、UniDicの辞書を内包したjarファイルもビルドできます(lucene/build/analysis/kuromojiの下にjarファイルができあがります)。\n確認？ 一応、パッチは動くのですが、パッチ自体はUniDicの辞書をビルドする仕組みはオフのままです。なので、テストをどうやろう？というところでやなんで止まっています。。。\nただ、実際に作ったパッチできちんとIPAdicとUniDicがそれぞれビルドできているかの確認はしないとなと。\nということで、2つのjarファイルを読み込んで、それぞれトークナイズして、その出力を表示するツールを作ってみました。\n上記パッチを適用したlucene-solrのソースを持ってきて、IPAdicの辞書を内包したkuromojiのjarファイルと、UniDicの辞書を内包したjarファイルを用意し、ツールの支持に従って、ファイルをディレクトリに配置して、実行すれば以下のような出力がされるようになっています（とりあえず作ったものなので、Javaファイルにトークナイズしたいテキストを書かないといけないのですが）。\nたとえば、「自転車と自動車の違いはなんでしょう？」という文字列を入力すると、以下のような出力になりました。\n+++ ipadic ++++++++++++++ token[0] is [自転車] token[1] is [と] token[2] is [自動車] token[3] is [の] token[4] is [違い] token[5] is [は] token[6] is [なん] token[7] is [でしょ] token[8] is [う] +++ unidic ++++++++++++++ token[0] is [自転] token[1] is [車] token[2] is [と] token[3] is [自動] token[4] is [車] token[5] is [の] token[6] is [違い] token[7] is [は] token[8] is [なん] token[9] is [でしょう] UniDicは[短単位]で語彙が扱われるため、「自転車」や「自動車」がそれぞれ「自転」「車」、「自動」「車」という形でトークナイズされていることがわかります。\nどちらがより便利なのか？というのは用途によっても変わってくるかと思いますが、検索の転置インデックスとしては、より短い単語で区切られている方が、より多くの文書にヒットする可能性が高くなるので、便利な可能性が高いです。\nまとめ ということで、パッチを作ってみたものの、まだ取り込まれていない状況です。 着地点をどうするかって話かなと思っています。興味があれば遊んでみていただければと。\n将来的には、辞書をjarから切り離して別のディレクトリやjarとして使えるようにしようというIssueも作られています。こちらがすすめば、UniDicだけでなく、その他の辞書を切り替えながら使えるようになる日が来るのではないでしょうか？\n","date":1575385200,"dir":"post/2019/","id":"c2d39f2f7fe6cb69fc8efb6c5495c932","lang":"ja","lastmod":1575385200,"permalink":"https://blog.johtani.info/blog/2019/12/04/about-lucene-4056/","publishdate":"2019-12-04T00:00:00+09:00","summary":"これは、情報検索・検索エンジン Advent Calendar 2019 の 4 日目の記事です。 1日目から、質の高いエントリーが続いていましたが、一旦休憩して頂く感じの記事になって","tags":["Lucene"],"title":"Apache LuceneのKuromojiのUniDicビルド対応パッチについて"},{"contents":"Elastic stack (Elasticsearch) Advent Calendar 2019の1日目の記事になります。\nまだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみようと思います。毎年恒例ですね、ここ数年。\nElastic Stack 6.6.0リリース(1月) リリース記事はこちら\nElastic APMが6.6のリリースと同時にElastic CloudでAPM Serverが無料で利用できるようになったのが地味に便利でした。APMのデモをやるために、それまでは手元にAPM Serverの起動が必要だったので。。。\nユーザーの方たちにはIndex Lifecycle Management（インデックスライフサイクル管理：ILM）がリリースされたのが便利だったと思います。 まだ、ベータでしたが、インデックスの世代管理を格段に便利にしてくれるツールになり、現在では必須アイテムとなっています。 もう一つ、地味に便利なのは、KibanaからElasticsearchへの接続を複数指定できるようになった点かと思います。\nElatic Common Schemaのベータリリース(2月) リリース記事はこちら\nElastic Stackではメトリック、APM、ログなど、様々なデータを一元的に可視化することができるという利点があります。ただ、一元的にデータを可視化、検索するためには異なるデータセットに統一されたフィールド名が欠かせません。そのための手段としてElasticが公開したのがElastic Common Schemaです。 各種データの項目名、型などを共通化する仕様をGitHub上で公開しています。最近のBeatsのモジュールはこのElastic Common Schemaに則ってデータが定義されるようになってきています。これにより、ログからメトリックへ、APMからログデータへというシームレスな移動ができるようになっています。\nElastic Stack 6.7.0リリース(3月) リリース記事はこちら\nElastic MapsやUptimeといった、これまでの可視化とは異なる便利なアプリが増え始めました。Mapsでは地図の表現が格段にアップしたので、コレまで以上に地理情報と合わせた可視化が楽しくなりました。\nもちろん、基本的に必要な技術が着実にGAされていくのもElastic Stackの素晴らしい点です。\nIndex Lifecycle Management(ILM)がGA Cross Cluster Replication(CCR)がGA CanvasがGA Logs \u0026amp; Infra UIがGA Elastic Stack 7.0.0リリース(4月) リリース記事はこちら\nメジャーバージョンのリリースです。 KibanaのUIが刷新されたり、Elasticsearchのクラスター管理の機能が新規に構築されたり、様々な改善がこのリリースでも入っています。また、メジャーバージョンのリリースのタイミングが、さまざまな大きな仕様の変更や改善が入るタイミングでもあります。これまで以上にパフォーマンスが改善（Top-Nクエリ高速化など）されたり、新しい機能の追加（ナノ秒のサポート）されたりしました。\nElasticsearchのセキュリティの主要な機能が無料に(5月) リリース記事はこちら\n6.8.0および7.1.0のリリースはこの機能の無償提供となりました。 結構衝撃的な話だったのではないかなぁと。これ以前は有償の機能だったセキュリティの以下の機能をElastic License配下で無料で提供する形に変わりました。まだ、ご存知でない方は、データの安全のためにもセキュリティ機能を利用することをおすすめします。\nTLSによる通信暗号化 ユーザー作成と管理にファイルおよびネイティブのレルム認証を使用可能 クラスターAPIとインデックスに対するユーザーアクセスの管理にロールベースのアクセス制御を使用可能、またSpaces機能でKibanaのマルチテナンシーの安全性を向上 Elastic{ON}19開催(5月) 今年も東京で開催しました。ビデオなどはこちらで公開されています。 https://www.elastic.co/elasticon/tour/2019/tokyo\n今回も偉そうにElatic Stackの新しくなった点を紹介するなどしてました。。。\nElastic Stack 7.2.0リリース(6月) リリース記事はこちら\nElastic SIEMがベータリリースされたのがこのタイミングです。 2月の発表したElastic Common Schemaをフルに活用していると言ってもいいのがこの機能になります。まだ今後もどんどん改善が入るであろうきのうになります。\nまた、Elasticsearchをバックエンドにした検索ミドルウェアとして利用いただけるElastic App Searchのセルフマネージド版もこのタイミングでリリースされています。\nさらに、このリリースの直前にはElastic Cloud on Kuberunetes(ECK)というものベータリリースされました。少しわかりにくいかもですが、ElasticsearchやKibanaをKubernetesのOperatorとして利用できるようになっています。こちらもElastic Licenseでリリースされているのでk8s上でKibanaやEsを管理しようとしている方は触ってみると面白いかもです。\nElastic Cloud Elasticsearch ServiceがGCP日本で利用可能に(7月) リリース記事はこちら\nElastic Cloudもプラットフォームが拡大した年でした。 Google Cloud Platformの東京リージョンを選択できるようになりました。さらなる統合（支払いをGCP経由にまとめたり、GCPのコンソールから利用できたりなど）も進んでいます。\nElastic Stack 7.3.0リリース(8月) リリース記事はこちら\nデータフレームと呼ばれるデータ取り込み時のピボット機能が導入されました。また、MapsのGAリリース、Elastic APMの.NETエージェント正式リリースなど、細かいですが様々なものがリリースされています。\nElastic Cloud Elasticsearch ServiceがAzureで利用可能に(9月) リリース記事はこちら\nMicrosoft Azureへのデプロイも可能になりました。残念ながらまだ日本リージョンには来ていないですが、今後出てくるはずです！さまざまなクラウドベンダーのサポートにより、より多くの人に使っていただけるようになるのかと。\nElastic Stack 7.4.0リリース(10月) リリース記事はこちら\nもう7.4.2まで出ていますが、いい感じの間隔で7.0、7.2、7.3と来ていますね。 7.4では、スナップショットリストアがKibanaから簡単に行えるようになりました。これまではKibanaのConsoleでJSONを見ながら管理されていたかもですが、GUIにより今どんなスナップショットがあるのか、どれをリストアするのかといった操作が簡単にできるようになっています。\nKibanaについてはPKI認証のサポートなども始まり、様々な認証方式でより便利にKibanaが使えるようになっています。\n12月？ 12月ですし、Elasticsearch勉強会では「LT＆忘年会」ということで、懇親会がメインの勉強会として12/6に開催します。悪路クエストの緑川さん、吉岡さんに主体となっていただき、マイクロソフトさんを会場に借りて開催予定です。興味のある方はぜひご参加ください。 LTもおまちしています！\nまとめ 駆け足でしたが今年を振り返ってみました。 今年も色々ありました。残すところあと1ヶ月です！\nさて、Elastic Stack Advent Calendar 2019は今日から25日まで続きます。今年はその2もできています！こらからの記事を楽しみにしています！ 本日はその2で[kaibadash@github]さんが「5分でできるElastic stack環境構築」というのを書いてくれてるはずです！\nということで、次はKunihikoKidoさんの「 Elastic Cloud を使うようになって設計方針やら変わったことについて書きます。」になります。お楽しみに！\n","date":1575126000,"dir":"post/2019/","id":"78da47d61c91c82809a3c97a791d26d2","lang":"ja","lastmod":1575126000,"permalink":"https://blog.johtani.info/blog/2019/12/01/whats-happen-at-elastic-in-2019/","publishdate":"2019-12-01T00:00:00+09:00","summary":"Elastic stack (Elasticsearch) Advent Calendar 2019の1日目の記事になります。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみようと思います。毎年恒例ですね、","tags":["elasticsearch"],"title":"2019年のElastic StackとElastic"},{"contents":"Bonfire Data \u0026amp; Science #1にブログ枠で参加してきました。 ということで、メモです。\n日時 : 2019/10/25 19:00 - 21:30 場所 : Yahoo! Japan サイト : https://yj-meetup.connpass.com/event/148121/ ハッシュタグ: #yjbonfire 概要 Data \u0026amp; Scienceとは？ データとサイエンスに関わる人達の情報共有のための勉強会/交流会\nサイトから引用です。\n第1回のテーマは「画像検索」です！ 最近EC系のサイトで類似画像検索が出来るようになったけどどうやってるの？ 画像検索のモデルってどうしてるの？ 画像検索のインフラはどうしてるの？ 私たちの会社でも画像検索を用いたサービスを構築できるだろうか？ こういった疑問に答えたり、いま抱えている悩みを解決するヒントを得る場になればと思っています。 今回は、画像検索を行なっているヤフー, メルカリ, ZOZOテクノロジーズの3社に事例と基盤技術について登壇いただきます。 QAはこちら。https://app.sli.do/event/w3wayjmv/live/questions\nMercari画像検索について(仮) 発表者：荒瀬晃介(株式会社メルカリ / AIエンジニアリングチーム)\nAIエンジニアチーム\n写真検索プロジェクトのTech Lead\niOSのみで提供の写真検索\nシステムオーバービュー\nMobileNet v2で特徴抽出 ANNのインデックスを使ってDBに入れる 論文も発表済み（3本）\n今日の発表はこの内の2本を元に話をします。 C2Cでの問題点 商品は床やテーブル上で撮影 クエリは着用（着ている）画像が使われやすい。 人が写ってる写真が結果に多いと業者が出展しているように見えてしまう。 提案手法 人が写ってるものから人の代表ベクトルを抜き取る (クエリ時にのみ処理を実施しているので変更が容易) 特徴変換ベクトル トップスなど、分類ごとに学習させてからベクトルを構成 なんでMobileNet v2? エッジデバイスでの処理を見据えて選択 インフラ Docker + k8s\nCRDを使ってる？\ntraining\nコンテナベースパイプライン いくつかのバッチ処理を工程ごとにパイプライン化 バッチ実行情報をカスタムリソースとしている＝再実行が簡単（復旧作業が容易） 画像を扱う＝ダウンロードが時間がかかる -\u0026gt; 復旧しやすいようにPVにある程度キャッシュさせている Serving\u0026hellip;\nGCP側 なぜ2つに別れてるんだろう？実際のサービスも2つに分かれてたりするんだろうか？\n将来の展望 Realtime Image Search カメラでものを写している状態でそれが何かを検索できる。 物体検出＋特徴抽出をエッジで行うためできる エッジの性能により違いが出てきたりするっぽい QA Q: 業者が想定されると、購入意欲を下げるというのは実験した結果？それとも想像？ A: 実験はしていないが、e-commerceにおいての研究がある Q: どういう理由でマルチクラウドにしたんでしょう? A: 画像のマスターがAWS。メルカリのマイクロサービスはGKEなので、サービング環境がGCP Q: 画像の内、服のエリアが大部分で体の面積が少ない場合と、メガネや帽子のように、アイテムの方の面積が少ない場合で、トレーニングに必要なデータ数は変わりましたか？ A: カテゴリによる性質の違うはある。ので、改善は必要。 ZOZO画像検索について(仮) 発表者：平田拓也(株式会社ZOZO / AIエンジニアリングチーム)\n(聞き逃した。。。)\nWEAR\nマルチサイズ\nチーム構成 研究所＋ML Opsチーム 使用しているアルゴリズム 物体検出アルゴリズム 特徴量抽出アルゴリズム 近似最近傍探索（approximate nearest neighbor, ANN） インフラ GCPを採用。 BigQuery上にデータ基盤がある Managed GPUが必要 なんでk8s? コンテナ Cloud Runがなかった アーキテクチャ マイクロサービス化されている Google Cloud Next 2019 Tokyoでsonotsさんの発表があるよ 監視項目 CPUなどは見ていない レスポンスタイムとステータス監視 リクエスト数 APM 使ってるものStackdriver + Datadog + Sentry Warningが30分で続けたら通知などができるのがStackdriver 画像検索の改善のためにやっていること 課題 レイテンシーが大きい 推論が大変？ 急激なトラフィックの増加に対応できない GPUのスケールアウトが問題 -\u0026gt; 先行投資が必要 流れ キャッシュありなし 物体検出 (GPU) 特徴量抽出 (GPU) 近似最近傍探索 DBから取得 2と3が問題\n2と3を特徴量DBという形でデータが登録された時点で特徴量などを計算してしまうことでGPUへの依存をなくした。 Apache AirFlowが便利？ Cloud ComposerとApache AirFlow Cloud Composerに関するいくつかのTipsがありました。\nQA Q: 推論をCPUでやったらどれぐらい遅いんだろう A: GPUインスタンス代金 \u0026lt; それと同等の速度を出すためのCPUインスタンス代金 Q: k8sスケールアウト時のリソース割当を最適化する為、resource limit / request標準化 or 時系列分析などから自動調整するなどはされていますか？ A: \u0026hellip;聞き逃した Q: (TCOを考慮したクラスタ構成) Cloud Composerの値段が高いようなパプリッククラウド利用の課題対策としてプライベートクラウドとのハイブリッド構成にされているのでしょうか？もしハイブリッド構成でしたら、パブリック or クラウドを切り分ける基準はございますか。 A: GKEオンリー Q: cloud composerでairflowを使う辛い点は？ A: 不安定さ。。。 Yahoo!ショッピングにおける画像検索(仮) 発表者：佐藤 純一(ヤフー株式会社) 商品検索APIの開発とか検索エンジンの保守とか 類似画像検索システムの開発が直近の仕事 類似画像検索 ヤフーショッピング 3億の商品 ファッション系はビジュアルが重要＝言語による表現が難しい iOSとAndroid Androidだとカメラで撮影してから検索みたいなことも可能 システム概要 物体検出 ノイズ除去 特徴抽出 インデックス(NGT) -\u0026gt; https://github.com/yahoojapan/NGT 1000万件を超える 検索 アプリの画像をAPIに投げてベクトルから、近いものn件を取得 ベクトル化/インデックス更新 GPUマシン Kafka使ってる クラウドストレージに日次？バックアップみたいに保存 差分更新の仕組みがある メンズとレディースは分けている 絞り込み検索のために分離（インデックスのメタデータとしてタグがある） システム構成 Python Kafka TensolflowServing 可視化？監視？はGrafana＋Prometheus 開発を通しての学び 自動デプロイとかテスト 検索精度の確認ツールを作る コレ重要だよね。何が変更してるかとか、何が正しいかってのが必要だし。。。 復旧可能、早期復旧の仕組みを容易 今後の方針 対象商品の拡大 物体検出特徴抽出モデルの性能改善 NGTの検索システムをValdに移行 Vald k8s上で動作、分散検索、分散インデキシングなどの機能を提供予定 QA Q: iOS(既存の画像)とAndroid(カメラで撮る)で画像検索の方式が違うのはなぜ？ A: アプリの違い Q: 1枚の写真に沢山写っている中で、対象の商品をどう識別しているんでしょう。靴もトップスもボトムスも写っていたら、かなり難しそう A: Yahooブラウザの場合は1番大きな領域のものを選択。Yahoo shoppingだと選択可能 NGTについて(仮) 発表者：岩崎 雅二郎(ヤフー株式会社) 類似画像検索を20年くらいやってる 近傍検索ライブラリ https://github.com/yahoojapan/NGT\n高次元ベクトルの近傍検索 ツリーとグラフによるインデックス 近傍検索とは?\n距離空間上でのクエリの近傍のオブジェクトを取得 k最近傍検索（通常はこっち） 範囲検索（あんまり使われない） NGTの特徴\n世界トップレベルの高速高精度な近似近傍検索 OSS 追加削除が可能（削除がとくに難しいらしい） 多様な利用形態（Python、C++、C、Go、コマンドライン） サーバ版NGT（ngtd、vald）を提供 共有メモリ版でメモリサイズ以上のデータ登録可能 量子化版NGT（NGTQ）により。。。 ANNベンチマークによりテスト\n実行環境が決められているらしい。誰が実行しても比較可能 グラフベースの検索の仕組みのほうが性能がいいというのがベンチマーク結果からわかる なんではやいの？ インデックス生成 ツリー（グラフの探索起点の取得に利用する。DVP-tree） グラフ（ANNG） ノードを逐次追加しつつ、近傍ノードを検索してから接続するというのを繰り返している 検索 ツリーから絞り込みつつ、グラフを検索する ANNGに課題があるのでONNG（Optimized Nearest Neighbors Graph）に ノード単位の次数（入出）を最適化 データセットによって有効な次数が違う。。。 NGTを利用した深層学習で。。。 Yahoo!ラボ FavNavi 特徴量の構成（低次特徴量（300次元）、カテゴリ特徴量（128次元）、領域アスペクト比（1次元）） 個別の特徴量だけだとイマイチな結果になるが、組み合わせるといい感じになる モデル性西洋学習データ スライドがあればいいなぁ（表書くの大変だし。。。）\nQA Q: 実際のお客さまの利用を考えると、近似近隣の密度が異なるので、近いものばかりの検索結果や遠いものも含んでしまった検索結果が出ると思うのですが、遠いものが含まれてしまうと、閾値でフィルタしたりするのでしょうか? A: NGTは近いものしかないので、外れ値ってなんでしょう。。。 検索のフィルタリングをある程度している（カテゴリとか）。 まとめ 慣れない分野の話を聞きながらざっとメモを取ったものなので役に立つかはわかりませんが。。。\nアルゴリズムとかまでは得意ではないんですが、画像「検索」ということで参加してみました。 実際に画像検索の仕組みがどんな感じでできているのか、どんな技術がつかわれているのか？ってのがわかったのは 面白かったです。確かに検索のためのキーワードって出てこないことあるしなぁと。 あー、こんなかばんほしいとか、これなんだろ？みたいなのあるからなぁ。\n","date":1572000002,"dir":"post/2019/","id":"11b3a28b536f34d3606427f835bd3ddf","lang":"ja","lastmod":1572000002,"permalink":"https://blog.johtani.info/blog/2019/10/25/bonefire-01/","publishdate":"2019-10-25T19:40:02+09:00","summary":"Bonfire Data \u0026amp; Science #1にブログ枠で参加してきました。 ということで、メモです。 日時 : 2019/10/25 19:00 - 21:30 場所 : Yahoo! Japan サイト : https://yj-meetup.connpass.com/event/148121/ ハッシュタグ: #yjbonfire 概要 Data \u0026amp; Scienceと","tags":["勉強会"],"title":"Bonfire Data \u0026 Science #1に参加しました"},{"contents":"この間のElasticsearch勉強会でAcroquest Technologyの人たちが技術書展7で販売されていた書籍を頂いてしまいました。なので、軽く読んでの感想と宣伝です（これ、電子版とかで買えないのかな？）。\nElasticのパートナーとしても活躍していただいてますが、こういう感じでさまざまなところでElastic Stackを広めていただいていて感謝しかありません。\n章立てとしては以下の通りです。\nElasticsearchでエンタープライズサーチを実現する 同僚が作成、メンテナンスしているFSCrawlerを使った例も書かれています。ローカルのファイル（PDFやJSONとか）をサクッとElasticsearchにインストールしたりするのには便利です。 Kibana Canvasによる柔軟な可視化 Canvasについてどんなものなのか？というのとelasticcofeeというサンプルを元に、その変更の仕方などが説明されています。 Elastic APMによるアプリケーションパフォーマンス監視 Go AgentとAPM自体の使い方の説明です。最近強化されている他の機能との連携（AlertingやMachine Learning）についても触れてくれています。 Kubernetesクラスタのメトリクス・ログ・性能情報の可視化 Azure上でAzure Kubernetes Serviceの上で動いているアプリなどをBeats、APMでデータを取りつつ、他のAzure上にAzure Marketplaceのテンプレートを用いて起動したElasticsearchとKibanaの環境を用いて可視化する方法が説明されています。 ということで、薄い本ですが、手順をおって説明されていたり、7.3と新しいバージョンで書かれているのですばらしいなぁと。 前作の「Elasticsearch NEXT STEP」に引き続きインプレスさんから出たりするのかなぁ？\nちなみに、Elastic APMのRubyに関して興味がある方は、私が前に発表したときの資料がありますので、こちらを参考にしてみてください。\n","date":1570690589,"dir":"post/2019/","id":"d8041ae308961666b15aa1e57b0f9f35","lang":"ja","lastmod":1570690589,"permalink":"https://blog.johtani.info/blog/2019/10/10/review-es-next-step-2/","publishdate":"2019-10-10T15:56:29+09:00","summary":"この間のElasticsearch勉強会でAcroquest Technologyの人たちが技術書展7で販売されていた書籍を頂いてしまいました","tags":["書籍"],"title":"Elasticsearch NEXT STEP 2を頂きました"},{"contents":"Twitterで「Meetup.comに切り替えたらー」みたいな話があったので、 受付用アプリとかなくてという話になったので、普段Elasticsearch勉強会で使用している QRコード生成の仕組みを紹介してみようかと。\nHTMLだけで済むようにQRコードを生成するjquery.qrcode.min.jsってのを使用してます。\nHTMLコードはこちら。\n仕組み 1枚だけのHTMLを生成 MeetupのOAuth2の仕組みを利用(consumer keyを発行する必要あり。) Meetup APIを利用してユーザー情報取得 取得したユーザー情報をGoogle Formに埋め込んだ形で表示するURLを組み立てる 組み立てたURLをQRコードにしてHTMLに表示 受付で、QRコードリーダーを使って、QRコードを読み込むとGoogle Formが開くので、「送信」ボタンを押す 1. HTMLの作成 QRコードを表示するためのHTMLを作成します。Gistに貼り付けてあるので、参考にしてもらえれば。 いくつか埋め込まないといけないものがあるので、個別にそれは説明します。\n2. Google Formの準備 Elasticsearch勉強会では、出席者の情報として、IDと氏名をリストとして保存しています。 目的としては、何人実際に参加したかを計測するのが目的です。 ですので、参加者リストのGoogle Formを作成します。 で、作成した後に、プレビューを表示する。こんな感じ。\nこの時のプレビューのURLをQRコードのURLとして使いたいので、このURLをQRコード表示のHTMLに埋め込みます。\nfunction createGoogleFormURL(data) { var obj = { \u0026#34;entry.1744035444\u0026#34; : data.id, \u0026#34;entry.2031666715\u0026#34; : data.name }; return \u0026#34;https://docs.google.com/forms/d/e/\u0026lt;GOOGLE_FORM_ID\u0026gt;/viewform?\u0026#34; + $.param(obj); } ここら辺です。 returnに書いてあるhttpsで始まる文字列をまず、先ほどのURLで置き換えます。 次に、プレビューのHTMLの中から\u0026lt;input\u0026gt;タグを探して、nameの値を抜き出します。 それをobjのキーに利用します。entry.で始まる文字列が該当します。\nこれで、このURLをQRコードにすれば、値（ここだとIDと氏名）が埋め込まれた形のGoogle Formがスマホのブラウザで起動します。\n3. Meetup APIの準備 MeetupのAPIを利用できるようにします。Meetup.comにログインするとみれるAPIのページがあります。 https://secure.meetup.com/meetup_api\nまず、OAuthを利用するためのConsumer Keyを発行します。\nメニューのOAuth Consumersをクリックして、\n\u0026ldquo;Create New Consumer\u0026quot;をクリックします。 すると、次のような画面が開きます。\nConsumer nameとRedirect URIが重要です。\nConsumer nameはユーザーがMeetup経由で認証するときに、その認証画面で表示される名前になります。 わかりやすい名前を表示してあげると良いかと。\nRedirect URIが一番重要です。実際にOAuthで認証が通った後に表示するHTMLを提供しているURLを指定します。 Elasticsearch勉強会の場合は、私のドメインにwwwをつけた\u0026quot;https://www.johtani.info\u0026quot;を指定しています。 実際にQRコード表示用のHTMLを配置するHTTPサーバーのトップのURLを指定します。 （ちなみに、私のウェブサーバーはS3で運用してます。ですので、HTMLをS3のバケットにアップロードしてあるだけです）\n必須項目を入力したあと、最下部にあるRegister Consumerボタンを押せばキーが生成されます。 生成されたキーがOAuth2のURLのパラメータに必要になります。\nこれで、リダイレクトの準備が整いました。\nOAuth2のURLには、Implicit Flowを利用します。 これで、リダイレクト先のHTMLにトークンがわたるので、Meetup APIにこのトークンが使えるようになります。\n認証用のURLはこちらです。このURLを参加者宛のメールに入れて毎回送信しています。\nhttps://secure.meetup.com/ja-JP/oauth2/authorize?response_type=token\u0026amp;redirect_uri=\u0026lt;QRコード表示HTMLのURL\u0026gt;\u0026amp;client_id=\u0026lt;コンシューマーキー\u0026gt; 参加者はこのリンクをクリックすることで、次のような画面が出てきます。 ログインしていない場合はLog in画面が表示され、まずはログインを促されます。\nで、Allowをクリックすれば、redirect_uriに指定されているページが表示されるわけです。\nQRコード表示用のHTMLでは、次のAPIを使用して、ログインしているユーザーの情報を取得してきています。\nfunction getMemberId() { $.getJSON(\u0026#39;https://api.meetup.com/2/member/self/?only=id,name\u0026amp;access_token=\u0026#39;+ getToken(), displayQRCode); } ここで取れた値が、先ほどの「2. Google Formの準備」で説明したコードのdataの部分に渡ってくるわけです。\nfunction createGoogleFormURL(data) { var obj = { \u0026#34;entry.1744035444\u0026#34; : data.id, \u0026#34;entry.2031666715\u0026#34; : data.name }; return \u0026#34;https://docs.google.com/forms/d/e/\u0026lt;GOOGLE_FORM_ID\u0026gt;/viewform?\u0026#34; + $.param(obj); } 4. QRコードの表示 あとは、jquery.qrcode.min.jsを使用してURLを表示するだけです。\nfunction displayQRCode(data) { $(\u0026#39;#qrcode\u0026#39;).qrcode({width: 128,height: 128, text:createGoogleFormURL(data)}); } サイズとURLを指定するだけですね。\nまとめ あとは、受付で、参加者の方が表示してくれたQRコードをスマホのQRコードリーダーやカメラで読み込めばGoogle Formが開いて必要な情報は入っているので、「送信ボタン」を押せば参加者リストが出来上がっていくという形になります。\n毎回勉強会の前日に、前回のGoogle Formを「コピー」してから、各回の勉強会の登録者フォームを作成しています。 コピーすることにより、Google Formの\u0026lt;input\u0026gt;タグに使用されるnameもそのままコピーされるので、 QRコード生成用のHTMLを書き換える部分の手間が減る形になっています（気づくまで数回かかったw）。\nですので、QRコードのHTMLの中身としては、「勉強会のページへのリンク」、「Google Formへのリンク」の2つを書き換えてから毎回アップロードしているだけとなっています。\nこのやり方が、スマートかどうかはわからないですが、受付アプリがない中、Meetup.comから取得した参加者リストのExcelやプリントアウトしたリストを元に参加者をチェックするよりは、手間が省けてるんじゃないかなぁと。\n残念ながら、QRコードの存在を知らないでそのまま勉強会にくる人がいるので、受付で最低一人はMeetup.comの参加者リストから、 名前を検索してチェックするという作業もやってもらってます。 QRコードを持ってきた方がすんなり受付を通過できるようになってますので、ぜひQRコードを持って勉強会にきてもらえればと。\n","date":1560939044,"dir":"post/2019/","id":"d96f80f23543850a2ee9fff8cd2cc53f","lang":"ja","lastmod":1560939044,"permalink":"https://blog.johtani.info/blog/2019/06/19/qr-code-with-meetup-dot-com/","publishdate":"2019-06-19T19:10:44+09:00","summary":"Twitterで「Meetup.comに切り替えたらー」みたいな話があったので、 受付用アプリとかなくてという話になったので、普段Elasti","tags":["勉強会"],"title":"勉強会の受付自作？アプリ？HTMLについて"},{"contents":"Elasticsearch勉強会や検索技術勉強会やってるんだけど、独学で勉強会やってるなーと思い、みんなはどうやってるんだろうとツイートしてみたところ。\nあー、勉強会運営座談会したい。\n\u0026mdash; Jun Ohtani (@johtani) 2019年4月2日 面白そう\n\u0026mdash; 機械の体を手に入れるのよ鉄郎 (@tetsuroito) 2019年4月2日 やってみるか。\n\u0026mdash; Jun Ohtani (@johtani) 2019年4月2日 やりましょう\n\u0026mdash; 機械の体を手に入れるのよ鉄郎 (@tetsuroito) 2019年4月2日 ってことで、何人か釣れたので、勉強会運営座談会をやってみました。 会場提供していただいた、Classiさんありがとうございました！\n参加してくれた人たちはまぁ、勉強会のサイトを見ていただければなんとなくわかるかなと。 自己紹介とどんな勉強会、読書会運営してますってとこから始めて、次のようなトピックについてピザ食いながら3時間くらい話しました。\nスピーカーの募集方法 運営側から声かけてる？それとも公募してる？ 登壇時間とかどうしてる？ スピーカーになってもらうためになんかやってる？ スケジュール管理 会場探し、スピーカー探し、イベントページ作るタイミングは？ 複数拠点開催したことある？ ハンズオンとかはどうしてる？ 土日開催？平日開催？ アンケートとってますか？ 使用してるイベントサイトは？ ドタキャン対応どうしてる？出欠とったりしてる？懇親会の規模とかどうやって見積もってる？ 運営費用関連はどうしてる？ グッズとか、ツールとか、スピーカーへの謝礼とか 運営って複数でやってる？ その時のツールは？ 運営メンバーにはどうやってなってもらう？ 録画配信とかまで手が回る？ 会場探すの大変じゃない？ 会場の部屋の使い方はどうしてる？ 行動規範とかどうしてる？ 読書会の場合に人が減ってったりしない？ まぁ、こんな感じです。色々話してメモしてたんですが、まぁトピックくらいで。\nそもそもは、勉強会の運営って本業ではない（はずな）ので、いかに楽をしつつうまく運営できるかってのを知りたいのと、 他の人どうやってるかってのからアイデアもらえるといいなーと思ったんでやってみました。 他のツールがどんなものかとか知れたし、あー、そういうやり方すればいいのねーみたいなのも知れたので、次回以降の勉強会に活かせればなーと。 自分がやってるやり方とかもブログ書くといいのかなぁ？\n残念です！次回もやるかもしれないので、 @johtani さんに期待してください！\n\u0026mdash; 機械の体を手に入れるのよ鉄郎 (@tetsuroito) 2019年4月25日 次回やるのかなぁ？興味ある人いるのかなぁ？\n","date":1556204526,"dir":"post/2019/","id":"538e38fbc3f78cd61e1841d8141ddcc1","lang":"ja","lastmod":1556204526,"permalink":"https://blog.johtani.info/blog/2019/04/26/meetup-organizer-drinkup/","publishdate":"2019-04-26T00:02:06+09:00","summary":"Elasticsearch勉強会や検索技術勉強会やってるんだけど、独学で勉強会やってるなーと思い、みんなはどうやってるんだろうとツイートして","tags":["勉強会"],"title":"勉強会運営座談会ってのをやってみた"},{"contents":"どーも、johtaniです。\nSearch Engineering Tech Talkという勉強会に運営として参加して、第1回の勉強会を開始しました。 本日（2/26）は第1回目だったので、ブログを残しておこうかと。\n勉強会自体の資料については第1回の勉強会のページにあるし、勉強会の感想とかブログはツイートやみんながブログを書いてくれると思うので、勉強会開催の経緯などについてブログを残しておこうかと。\nなんで始めたの？ 私自身が古くはFAST Searchに始まり、何か縁があって、 検索のシステムに長く携わってきたこと（Apache Solrの本書いたり、Elasticsearch勉強会始めたり）もあり、 検索が面白いなと日々思ってます（思ってるだけかもしれないが）。\nで、これまでElasticsearch勉強会をやっているのですが、検索エンジン固有の話ではない、 いわゆる検索の共通の課題というのがあるなぁと。 そういう課題やノウハウって、製品に限らず共有できれば面白いことがもっとできるんじゃないだろうか？ と感じることが多々ありまして。 オープンソースのコミュニティをソースコードをベースではなく、共通の課題・話題を中心としたコミュニティが あってもいいんじゃないかなぁと。\nまぁ、要は、私がみんなの検索で困ってることとか、どうやって検索システム考えてるのかが聞きたかったわけですよ。\nということで、一人でやっても面白くないので、興味ありそうな人を募ってやってみようということを始めたのが2018年12月くらいです。\n運営とかどうしてるの？ まずは、共同主催者（コアメンバー）を募集してみようということで、Googleフォーム作って、 興味ありそうな人がいる場所に投稿してみました。（TwitterとかFBとか） で集まったのが今回紹介したメンバー（スライド参照）です。 ユーザー企業の人もいれば、私みたいな検索エンジンの人もいるので面白い感じにできたかなぁと。 で、スピーカーを運営や知り合いに声をかけて第1回をやってみたという感じです。\n今後どうするの？ 残念ながら次回はまだ未定です。 2ヶ月に1回くらいのペースで開催できればなーと思ってますが、スピーカーが集まるかなどによるかなぁと。 ということで、勉強会のグループのページにスピーカー応募フォームのリンクがありますので、スピーカーに興味がある方は入力していただければと。\nもちろん第2回はやりたいので、勉強会のページからの連絡をお待ちください！！\n","date":1551191880,"dir":"post/2019/","id":"b27bdabd8e1a6b7dc06886867331ceb3","lang":"ja","lastmod":1551191880,"permalink":"https://blog.johtani.info/blog/2019/02/26/start-search-engineering-tech-talk/","publishdate":"2019-02-26T23:38:00+09:00","summary":"どーも、johtaniです。 Search Engineering Tech Talkという勉強会に運営として参加して、第1回の勉強会を開始しました。 本日（2/26）は第1回目だったの","tags":["勉強会","検索"],"title":"Search Engineering Tech Talk(検索技術勉強会)の運営として参加して始めてみました。"},{"contents":"今年も振り返りブログをかけてます。よかったw\n振り返り（2017年に書いた抱負から） まずは去年の抱負を元に。\nもっと英語の継続＆TOEIC まぁ、継続してます。英会話も続けてますし、海外TVドラマや映画見てます。 ただ、昨年書いたTOEICはイベントが被りまくってて受けれてないです。。。 来年は受けれればいいが。 ちなみに見たドラマはこの辺。あんまり見てないなぁ。 「はじまりのうた」は飛行機の中で見たんですが、よかったです。 最近は音楽系の映画が好きなのかなぁ。グレーテストマンショー（ミュージカル風）とかもハマったし。\nGame of Thrones はじまりのうた BEGIN AGAIN (映画) 24 シーズン4まで 今は、ボキャブラリのなさに苦しんでる感じです。キクタンとかするべきなのかもなぁ。 基本勉強が下手だからなー。\n継続的にイベントに登壇 ＆ CfPもっと出すぞ！ OSCには出てました。あとは、いくつかに呼ばれて出たりでしょうか。 CfPはJJUGしか出せてない気がするんで、もっと出さないとですね。。。 春のJJUGでは20分で短すぎた「オープンソースとビジネスモデル」の話（同僚のネタ）が 今年面白かった内容かなぁと。 もっと話を作るのをうまくしないとだろうなぁ。 ユースケースが増えてるんで、もっといろんなところに出ていかないとなぁと。 ブースの出し方とかもちょっと考えないといけないかもなーと思ってたり。 マンネリになってきてる気がするんで、なんか取り入れないとなぁ。\nもっとブログ！ 出だしはよかったんですが、途中でRustネタのブログも止まってしまいましたね。。。 業務が忙しくなったのを言い訳にして時間が取れなくなってるんで、 もっと習慣つけないとなぁ。\n雑誌やWeb系雑誌で記事を。 できてないです。。。どうすっかなぁ。 重い腰上げないのが問題なんですけどね。。。 自社のウェビナーとかはそこそこやってましたが。\nコミュニティを別の方法で盛り上げ フォーラムは皆さんのおかげで盛り上がってきてる気がしてます。 別の方法ではなく、勉強会を9月から毎月開催にして、ユースケースごとに切り替えてみました。 あとは、スピーカー登録用のフォームの用意とかして、継続的に楽にスピーカーの人たちが見つけられるようにと。 私は「全然」関わってないんですが、技術書典でいろんな方に書籍を書いていただきました。 また、Elasticloverという毎週いろんな記事をまとめていただけ助かりました。 少しでも感謝をということで、コミュニティランチというイベントで、フォーラムで回答していただいてる方や、書籍を出していただいた方を招いてCEOのShayとランチするというイベントもやってみました。 少しは盛り上げられたかなぁ。 次は、ハッカソンみたいなのとかやってみるのもありなのかなぁ？（サポートしきれない気がするんだよなぁ）\nElasticsearchなど検索系の開発にも参加 開発。。。 Analyzer向けのKibanaのプラグインの開発は継続してますが、あんまり開発してないですねぇ（GitHubの草をみながら)。 ちょっとしたPRはやったりしてますが、もっとやりたい。。。 とりあえず、来年しょっぱなは、検索系じゃないですが、KibanaのプラグインのReact化をやらないとなぁと。\n振り返り(今年あったできごと) さて、反省が多かったですが、ここからは今年の出来事を。\n初スノーシュー in US オフィス引越し パリで料理w K8sとde:code QNAPとか IPO! 初のオンライン登壇 初アイルランド! Pixel3 XL 今年も初モノがちらほら。\nアメリカでスノーシューやりました。昨年は釣りでしたが、今年はスノーシューでした。 スノーシューはすごくよかったんですが、サンフランシスコから社内ミーティングのある場所までの 移動に10時間バスに缶詰という変な初モノもありました。。。 スノーリゾートのある山の上にバスで移動だったんですが、前日までの天候の生でチェーン規制が出てしまい、登りかけた山を降りて、違う経路で登り直すという長旅でした。。。 途中からずっとゲームオブスローンズみてました。。。\nオフィスが引っ越しました。人数が増えてきたのもあり、銀座のWeWorkに引っ越しました（私はあんまり行かなかったりしますがw）。 ただ、すでに手狭になってきて、来年はまた引っ越してるかもなぁ。 今年の終わりで日本のメンバーが22名に増えました！すごい！4年半前の22倍！\nパリで料理もしましたwセールスのキックオフミーティングがパリで開催され、なぜか参加してきました。 そこで、DevRelチームのミーティング＆ディナーがあったんですが、ディナーがアクティビティ付きで、チームのみんなとパリで料理やカクテル作ってきました。 まさか、パリで手巻き寿司作るとは思わなかった（怖くて食べてないですw）\n今年はイベントが連続することが多かったです。パリから帰ってすぐにde:codeでMSの川崎さんと登壇したりしました。Kubernetesを触る機会ができたんでよかったですが、時差ボケは辛かったw今年は他にもカンファレンス直後にトレーニングだったりと、夏に喉やられちゃいました。喉に負担をかけない話し方の練習すべきなんだろうなぁ。\n自宅の環境もちょっと整えました。10年前から使ってた、TeraStationをQNAPに刷新。快適に検索できるわ、クラウドにバックアップとれるわで、すごく快適です。 あとは、自室のディスプレイをディスプレイアームにつけたり、壊れたモニタースピーカーをYamahaのパワードスピーカーに買い替えたりと。 ちょこちょこ自宅で作業したりするんで、快適です。\n今年はめでたいことに会社がIPOしました。ニューヨーク証券取引所で株式公開しました。 転職して4年、初体験なんで何がどうってのはいまいち実感わかないんですが、順調にきてるのは嬉しい限りです。今後も頑張りますよ！\n自社のウェビナーでは、オンライン登壇してたんですが、インフラ勉強会でオンライン登壇させていただきました。 Elastic Stackの入門的な話をさせていただいたので、興味があればみていただければと。 こういうのにはマイクが非常に重要だなというのが結論です。ウェビナーで使ってるShureのマイクで話したので聞き取りやすかったです。 来年はもっと手軽にちょっとしたウェビナーとかポッドキャストやろうかな、ということで、持ち運び用にSAM SONGo Micを購入してみたのでどっかで試してみたいなー。\nアイルランド（ダブリン）にも行きました。これまた、社内のミーティングなんですけどね。半年に1度エンジニアが集まる社内イベントがあるので、いろんなところに旅をさせてもらっていて、すごく楽しいです。 みんなにも会えるし。ただ、アイルランドの英語はきつかった。。。\n最後はPixel3です。SonyのXperiaをここ数年は使ってたんですが、電池の持ちなどが悪くなったんで、気になってたPixel3に変えました。すごくいい。いらないものが入ってないのもいい。あとカメラがすごくいい。他の機能をまだちゃんと調べてないんで、誰か便利機能知ってたら教えてくださいw\nとまぁ、こんな感じでした。\n来年の抱負 最後は来年の抱負を。\nTOEIC CfP見つけて応募 \u0026amp; いろんな場所に顔を出す もっとブログ！ Rustの継続 開発の継続 日本でエンジニア獲得! まぁ、英語ですね。これは地道にやるしかないんだろうなと思いつつ、コツコツが苦手でw とりあえず、今年はどこかでTOEIC受けないとな。\nいつも行かないけど、弊社プロダクトに関係のあるカンファレンスのCfPを見つけ出して、 応募しまくって、少しでもしゃべらないとなぁ。喋れなくても、Elasticsearchがらみで登壇していただいてる方がいるカンファレンスには顔を出していきたいなぁと。 登壇される方いたら、ぜひ連絡ください！あとは、CfPのサイトを探す仕組みを作らないとなぁ。 検索サイト作るかなぁ。 あとは、カンファレンスではなく、いろんな会社に遊びにいきたいと思ってます。 入門的な話をしてほしいような方、こんな使い方してますっていう話をしていただける方、大募集です。 これもGoogle Formでも作ってみるか。\nブログなぁ。小さな習慣を読んだのに、習慣化できてないので、なんとかしないとという意味で。。。が、頑張ります。。。\nRustの継続＆開発の継続もですね。Java歴が長いので、他の言語を勉強しようと思ってRustやってますがなかなか身についてないというか、時間を取れてない。これもコツコツやらないとなー 検索関連の開発もちょっとずつやりたいなと思ってるんで、LukeへContributeしようかな。\n切実なんですが、日本に弊社のエンジニアを増やしたいなと。特に人前で喋ってもらえる人が増えると助かるんです。弊社最近、ユースケースが増えてきてて、追いつかなくてwダレカタスケテーw\nさーて、そろそろ紅白のサザンが始まるんで終わりです。\n今年も様々な方々に様々な面で助けていただきました。本当にお世話になりました。 この場を借りてお礼申し上げます。\n来年ももちろん、助けてもらうんで、よろしくお願いいたします！ あと、話聞きたい方、声かけてくださーい。\n","date":1546240485,"dir":"post/2018/","id":"6c226ee1519fbf910197cc1d5c5a5756","lang":"ja","lastmod":1546240485,"permalink":"https://blog.johtani.info/blog/2018/12/31/looking-back-2018/","publishdate":"2018-12-31T16:14:45+09:00","summary":"今年も振り返りブログをかけてます。よかったw 振り返り（2017年に書いた抱負から） まずは去年の抱負を元に。 もっと英語の継続＆TOEIC まぁ、","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2018）"},{"contents":"Elastic stack (Elasticsearch) Advent Calendar 2018の25日目の記事になります。 今年最後のAdvent Calendarです！来年も忘れてなければやるはず！\n今日は、すでにalpha2までリリースされた7系でどんな変更が入るのかをちょっとだけ紹介します。 ほんとにちょっとだけですよ。\nKibanaのk7 design (kibana) Kibanaの新デザインです。K7って呼ぶのかな？\nまだ、メニューと一部が実装されているだけですが、7.0.0でガラッと変わりそうです。 そのほかの画面のIssueはこちらです。 \u0026ldquo;k7\u0026quot;で検索しただけですが。メタIssueが見つからなかったんで。例えば、こんな感じでアプリとかのスイッチとかがこんな感じになるよというデザイン案が観れたりします。\nZen2 (elasticsearch) Elasticsearchの新しいクラスター管理機構アルゴリズムになります。 Zenと呼ばれる独自実装のものを6系までは使っていましたが、7系向けに変更がかかりました。 実際には、Nodeを探す仕組み、Masterの選出アルゴリズム、クラスター状態の管理などを行います。 上記のリンクにあるようにドキュメントも詳しくなりました。 信頼性をさらに向上し、設定ミスを起こしにくくして、より使いやすくという目的で様々な変更が加えられています。 これが、メタIssueかな？ アルゴリズムの変更や、クラスターの状態の管理の方法などの変更に関するIssueやPRにリンクが貼ってあります。\n新しいデータタイプ (elasticsearch) Feature/Feature vector datatype ドキュメントはこちらとこちら\nfeature queryと合わせて使用するためのフィールドで、しかもクエリのスコア計算「のみ」に使用するフィールドになります。 検索条件やソート、Aggregationの対象ではなく、クエリのスコアに影響させたい値を入れておくためのフィールドです。 6から追加された機能の「track_total_hits」をfalseにした時と合わせると、function_scoreなどで計算をしていた場合よりも、検索性能が上がるという利点まであります。 ちなみに、「track_total_hits」は検索ヒット数を計算しないで、上位のデータを取得する時にクエリを早くするといったことができる機能になります。 Index Sortingと組み合わせることで威力が発揮できる仕組みになるはずです。\nFilebeat supports NetFlow (beats) NetFlowが入力として追加されます。 Filebeatと言いつつ、File以外の入力が徐々に増えてきてますね（UDPやTCPにも対応しましたし）。 ネットワーク機器などの監視を行う方などにはさらに便利になってくるのではないでしょうか？ （私はこの辺りは不得手なので、誰か使ってみてもらえればと！）\nまとめ まだ、序の口って感じですが、今年はこの辺で。7系ではここであげた以外にも様々な機能が追加されています（もしくは予定です）。 Elasticのドキュメントの良いところは、masterブランチのドキュメントも公開されていることです。 ドキュメントのバージョンを7.0.0-alpha2にすれば、masterブランチで追加されたページが見れるので、 興味のある方は眺めてみていただければと。物によって、リリースノートが書かれていなかったりするので注意は必要ですが。\n今年もあと数日になりましたが、Advent Calendarへの参加ありがとうございました！ 来年ももちろんやりますので、年始からネタを考えてくださいね。\n来年一発目は、第28回Elasticsearch勉強会 - 6.5機能紹介 -になります。ウェビナーでも紹介しましたが、6.5で入った様々な新機能をデモありで紹介する予定です。 興味のある方はぜひご参加ください。\nでは、来年もよろしくお願いいたします。\n","date":1545663601,"dir":"post/2018/","id":"ee62cb0b9a97f990df1ed0266a7027e2","lang":"ja","lastmod":1545663601,"permalink":"https://blog.johtani.info/blog/2018/12/25/whats-new-in-elastic-stack-7/","publishdate":"2018-12-25T00:00:01+09:00","summary":"Elastic stack (Elasticsearch) Advent Calendar 2018の25日目の記事になります。 今年最後のAdvent Calendarです！来年も忘れてなければやるはず！ 今日は、すでにalp","tags":["elasticsearch"],"title":"Elastic Stack 7.0で入ってくる新機能をちょっと紹介"},{"contents":"Elastic stack (Elasticsearch) Advent Calendar 2018の1日目の記事になります。\nちょっと遅れちゃいました。。。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみようと思います。毎年恒例ですね、ここ数年。\nElastic Stack 6.2.0リリース(2月) リリース記事はこちら\nAPMがGAリリースされ、Beats monitoring UIも追加されました。Stackとしての統一度がちょっとずつ上がってきた感じですね。 Kibanaのホーム画面（左メニューのKibanaアイコンをクリックした時）にデータ登録のチュートリアル的な画面が追加されています。 特にBeatsを利用する時の流れが簡単にわかるのがいい感じです。Metricsなどはローカルでちょっと試すのにも簡単な流れですので、ぜひ一度やってみてもらいたいなと。 個人的にはtermsを使ったパイチャートで、その他の数値がどのくらいあるかといった表示ができるようになって、やっと帰ってきた！（Kibana 3の頃にはあった機能）という印象でした。\nElastic{ON}18開催(2月) 第4回目のユーザーカンファレンスがSFで開催されました。 今年のキーノートが今年最大のニュースですね。 X-Packのコードの公開が発表されたのがこの時でした。 個人的に今後もオープンソースに携わっていきたいと思いながら日々働いていますが、 Elasticのオープンソースへのこだわりと、シンプルな考え方を再確認して素晴らしい会社で働けてるなーと。 商用のソースコードを公開してユーザーや顧客の皆さんとより良いものを作っていきたいという形ですので、今後もよろしくお願いします！ キーノートの動画はこちらからご覧いただけます。\nそのほかにも次のような発表が行われました。\nSQL for elasticsearch Canvas Elastic App Search(旧Swiftype) Elastic Stack 6.3.0リリース(6月) リリース記事はこちら\n2月末のElastic{ON}で発表されたX-Packのコードの公開にはやはり時間がかかりました。 有償コードのリポジトリとの統合やライセンスの変更、テスト環境などなど、色々大変だったみたいです。 ようやく公開され、ベーシックのライセンスの扱いなども変わり、より使いやすくなったのがこのタイミングです。\nX-Packをプラグインとしてのインストールが不要に ベーシックライセンスがデフォルトでONに。6.3から登録などが不要に。 Apache 2.0ライセンスの部分のみのディストリビューションも別途ダウンロードできるようになどなど 日本でもリリースウェビナーをやりました。ご覧いただけましたかね？\nElastic Cloud Elasticsearch Serviceがより使いやすく(8月) リリース記事はこちら\nこれまでは、メモリとストレージの比率だけしか指定できなかったのですが、 このリリースで様々なユースケースに応じた組み合わせが可能になりました。 CPUやメモリリソースよりもストレージを大きくしたりなどです。 専用マスターノードを追加できたり、待望の機械学習（Machine Learning）が提供されたりと色々と変更があり使いやすくなったかと。 昔からよく聞かれる、Kuromojiなどのカスタム辞書を登録する機能もあるので、Elastic Cloud便利です。 ご存知ない方は、14日間のトライアルもありますので試していただければと！\nElastic Stack 6.4.0リリース(8月) リリース記事はこちら\nフィールドエイリアスや韓国語のアナライザーがElasticsearchに追加されました。 Kibanaはデザインがここからさらに少しずつ変更が入ってたりします。 Elastic UIフレームワークと呼ばれるデザイン用のライブラリが、ElasticのプロダクトのUIに取り込まれていってる感じです。統一感が取れてきてますよね。私が開発しているAnalyze UIのプラグインにも取り込みました。 あとは、マイクロソフトのde:codeで話をさせていただいた、Logstash向けのAzure Moduleがリリースされたのもこのバージョンでした。AzureのEvent Hubからデータを取り込んで、SQLデータベースのモニタリングや、ユーザーの認証などをとってKibanaで可視化するものです。\nもっとも気に入っているのはサンプルデータの登録が簡単になったことです。これまでは、KibanaとElasticsearchを用意した後に、データを入れるためにFilebeatなどを使ってから、ようやくKibanaで遊べるという形でした。 6.4からは、ElasticsearchとKibanaを立ち上げて、Kibanaのホーム画面の「Sample Data」のリンクを押した後に、「Sample flght data」の「Add」ボタンを押せばKibanaからデータが登録されます（サンプルデータについてはこちら）。とりあえず触ってみたいという方への敷居がさらに下がったのではないかなぁと。\nElastic認定エンジニア第1号(8月) ブログ記事はこちら\n認定制度も始まりました。Elasticsearchの知識、経験を問われるテストを受けていただき、合格すると認定されるというやつです。 なんと、社外で世界初の認定エンジニアがアクロクエストの吉岡さんでした（上記ブログ参照）。 私もトレーナーやってるのもあり、慌てて認定をとったりしましたw。 認定テストは筆記ではなく、実際に作業をするテストなので実践的です。 トレーニングの受講が必須ではないのも面白いなぁと思いました。 トレーニングや認定エンジニアに興味がある方は、Elasticのトレーニングのサイトをご覧ください。 1月末にはまた、日本語でElasticsearchのトレーニングも開催されます！\nElastic Cloud Enterprise 2.0リリース(9月) リリース記事はこちら\nElastic Cloud Enterpriseをご存知ない方もいらっしゃるかもしれません。 Elastic Cloudの裏側で利用しているクラスターの起動などの仕組みを製品として提供しているのがこちらになります。 Elastic Cloudで機械学習や様々な構成ができるようになったものがリリースされたのがこの2.0です。 複数のElasticsearchクラスターを管理したい場合には、こちらが便利なツールになってるんじゃないかなぁと。 部署ごとにクラスターを提供するといったことが可能になるので、乱立する前に利用するのも便利かなーと。\nニューヨーク証券取引所で株式を公開(10月) ブログ記事\n日本語でブログ(10月) Elasticsearchの運用に関する典型的な4つの誤解というブログを書きました。4年も働いてるのに、会社のブログに翻訳以外で書いたことなかったので。。。 Twitterや勉強会、ブログ記事などで見かけるよくある誤解に関する記事を書いてみました。 Elasticは英語のブログも活発に書かれているのですが、今後もこのような形で日本語でのブログも頑張りますので、 読んでみたいものなどあればコメントいただければと。\nまぁ、弊社の大輪は色々書いてるんで、私がもっと頑張れって話ですかね。。。\nElastic Stack 6.5.0リリース(11月) リリース記事はこちら\n昨日（11/30）のウェビナーでも話をさせていただきましたが、Elastic Stack 6.5は「本当にマイナーリリース？？？」と思うほど盛りだくさんの機能がリリースされました。\nインフラUI、ログUI Elastic APMの分散トレーシング対応 Java \u0026amp; Go APM Agent GAリリース Cross Cluster Replication ODBCドライバー Kibana Canvas Kibana Spaces Data Visualizer for files Functionbeat LogstashのApp Search output リストアップしただけでもこれです。45分のウェビナーでは伝えきれてないなぁとも思ってますので、何か検討しようと思います！\nElasticsearch勉強会(3月から12月) Elasticsearch勉強会ページ\n今年は、6回の勉強会を開催（1つは12月19日開催）しました。 9月からは、ユースケースなど、もっと参加者の皆さんの興味があることにフォーカスしながら開催をしてみ始めました。 参加しやすくなってればいいのですが。。。 そろそろまたアンケートをとったりして、参加しやすいか、どんな改善がしてほしいかなどを聞きたいなと思っています。\n12月はもっと皆さんと喋りたいなということで、スピーカーなしの「LT\u0026amp;忘年会」にしてみました。 私やElasticのものも参加するので、ぜひ色々聞いたり、他のコミュニティの方達の使い方を聞き出して、 新しい発見をしていただければなーと思います。LTでスピーカーの練習をするってものありですよ！（まだ誰も応募してくれてない。。。） 発表することで、フィードバックがもらえて、自分の使い方に自信が持てたり、その他の視点を得ることができると思いますので、 ぜひ発表してみていただければと。\n12月のjohtani出没イベント 12月は以下のイベントにブースを出してます。イベントに参加される方ははぜひブースにお立ち寄りください！！\n12/4-5 : Japan Container Days - 東京 12/8 : OSC福岡 - 福岡 12/15 : JJUG CCC 2018 Fall - 東京 12/19 : 第27回Elasticsearch勉強会 - 東京 なんか、忙しそうだな。。。\nまとめ 駆け足でしたが今年を振り返ってみました。 今年も色々ありましたが、今後もよろしくお願いいたします。\nさて、Elastic Stack Advent Calendar 2018は今日から25日まで続きます。こらからの記事を楽しみにしています！\nということで、次はkaibadash@githubさんの「ぼくの考えた最強のElasticsearch index設定を最強にわかりやすく書くぞ！！！」になります。お楽しみに！\n","date":1543628918,"dir":"post/2018/","id":"ba45ddd3042dad59a12e5937644f7246","lang":"ja","lastmod":1543628918,"permalink":"https://blog.johtani.info/blog/2018/12/01/whats-happen-at-elastic-in-2018/","publishdate":"2018-12-01T10:48:38+09:00","summary":"Elastic stack (Elasticsearch) Advent Calendar 2018の1日目の記事になります。 ちょっと遅れちゃいました。。。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみよ","tags":["elasticsearch"],"title":"2018年のElastic StackとElastic"},{"contents":"（転職する少し前までパスポートすら持ってなかったのに）今の会社に転職してから、半年に1度の割合で海外への出張が発生する生活を送っています。 4年目になりますが、今回いくつか新しいガジェット？アイテム？を出張用に導入したので感想を書いておこうかなと。\nとりあえず、以下の4つです。\nFelimoa ネック ピロー これまでは、無印で購入した「フィットするネックピロー」を使ってました。 特に使ってる間は問題ないのですが、どうしてもかさばります。。。 そんな時、FBで見かけたのがこちら。\n厚みがないので、持ち運びが便利でした（商品紹介の中にありますが、リュックにつけると邪魔にならない）。 飛行機の中で使うので、それほど暑くない場所なので、ムレる感じでもなく。 ただ、ヘッドフォン＋真横にフレームがくる形になるとヘッドフォンに干渉するので、 私はフレームを顎の下の方に寄せた形で使ってました。 軽さと場所を取らないのがよかったです。\nノイズキャンセリングヘッドフォン これまでは、SONYのNW-A847という ノイズキャンセリング機能付きのウォークマン＋アクセサリーで外部入力を取り込む形で、飛行機で映画を見ていました。 これ自体が8年前の製品ですね。。。 これとは別に、冬の寒い時期は防寒も兼ねてヘッドフォンを使用しています。 MDR-10Rを使ってたんですが、昨年こんな感じになりまして。。。\n応急処置 pic.twitter.com/uDErZWpPVC\n\u0026mdash; Jun Ohtani (@johtani) 2017年11月10日 で、ヘッドフォンの買い替えを検討してたんです。 そこへ飛び込んできたのがSonyの新しいノイズキャンセリングヘッドフォンでしたと。\nせっかく買い換えるし、今度はいいものを長くということでフライト前日に購入してしまいました。 結論としては高いけど買ってよかったと。よかった点はこんな感じです。\n軽い イヤーパッドが耳を抑えることがないので長時間でも気にならない 人の声だけノイズキャンセリングをオフにする（騒音などはキャンセルしてくれる） バッテリーが長時間 ヘッドフォンを外さないでも案内を聞くことができる「クイックアテンションモード」 などなど。行きのフライトで5時間も遅れが出ましたが、空港、飛行機内で非常に快適に過ごせました。 大事に使おう。。。\ncw-x 知り合いがFBにアップしてて、立ちっぱなしの仕事だったり、長時間のフライトでも足が疲れないという噂を聞いて購入しました。\n長時間のフライトの後に、ホテルで1泊しても足の疲れって結構残ってるんです。 今回、12時間のフライトでズボンの下に履いて行きましたが、足の疲れがほぼありませんでした。 デブになりつつあり、足太くなって来てるので、履くのはちょっと苦労しますが。。。もともときつめに作ってるんじゃないかなぁ（希望的観測）。 帰りも使用しましたが、帰りはフライト前に1万歩ほどダブリンの街中を歩き回ってたので、流石に疲れが出てます。。。 今度は、カンファレンスのブースなどで立つことが多いシーンでも使ってみて、疲れがどうなるかを試してみようと思います。\n携帯ウォシュレット 初めて購入しました。海外のホテルで1週間とか連泊するんですが、トイレットペーパーがやはり硬めなのが気になって。。。\n世界に誇る日本の技術の一つだと確信してますw ドイツに長期出張してた友人が便利だよと言ってたので、思い切って購入して持って行きました。 硬めのトイレットペーパーも気にならなくなるのでとても幸せな気分ですw\nまとめ とりあえず、今回はこんな感じです。 総じて導入してよかったなという感じでした。 他にもおすすめ出張グッズとかあればコメントいただけると嬉しいです。\n普段使ってるものとか、どういうものを持っていってるとか興味ある人いるかなぁ？ ではでは。\n","date":1539794095,"dir":"post/2018/","id":"3fd9052870778e14ab4a5acbc8c24af4","lang":"ja","lastmod":1539794095,"permalink":"https://blog.johtani.info/blog/2018/10/18/items-for-long-businesstrip/","publishdate":"2018-10-18T01:34:55+09:00","summary":"（転職する少し前までパスポートすら持ってなかったのに）今の会社に転職してから、半年に1度の割合で海外への出張が発生する生活を送っています。 4","tags":["misc"],"title":"新規導入した長期出張用のアイテムをいくつか紹介"},{"contents":"毎月開催の2回目になります。 今回は日経さんの会場をお借りしての開催となりました。\n前回から、スピーカーの募集をhttp://bit.ly/SpeakerElasticTokyoMeetup で行なっております。 ぜひ皆さんのノウハウを共有していただけると助かります。 また、次回もすでにスケジュール済みです。次回は「ログ/メトリック分析」回になります。\n以下は、個人的なメモになります。\nメディアコンテンツ向け記事検索DBとして使うElasticsearch / Future Architect 株式会社 村田 靖拓さん (twitter: @famipapamart) メディア記事コンテンツ検索 全ての情報が1indexに入っているようにすること。 typeは少し悩んだ。 範囲検索にはならない場合がある。（文字列で登録してWildcard検索できるようにした） kuromojiで基本対応 異体字についてはchar filterでマッピング 細かな設定とかもスライドにて公開予定。 基本的なプラグインだけで対応した Dynamic Field mappingを有効にしたまま対応 パフォーマンス検証 初回のインデックスのロードはこの辺かなぁ？。 自力でQueryのoffset-limitを構築するのかぁ。 ソート条件が固定らしいのでできる方法 minne での検索運用(仮) / @_shiro16 さん ハンドメイドなものをマーケットプレイスがminne SolrからElasticsearchに切り替えた話 2016/02以降はEs 昔は、DBからSolrへ同期 Es版ではDBからの同期ではなく、Workerに対してリクエストを入れる 現状は独自にEC2で運用中 ユーザーが求めているものがきちんとでているかを計測している 行動ログはどんな感じ？ TDにログを入れて、CTRとかを計算してre:dashで可視化 A/Bテストも実施 指標はキャンペーンなどが実施されている場合にブレる場合もある トレンドをログから知ることができる Function Scoreでスコアを変更してる 季節的な単語でスコアを変更したりする ドリンクの対応などをして聴けてないところが。。。 query_stringのはなし / 加藤遼さん　(日本経済新聞社) 電池が切れそう＋ピザとかの手配をしていたらメモが取れず。\n苦労が滲み出る感じのセッションでした。 query_string queryが実際にどんなクエリになっているかの説明を交えて説明してもらえたのはすごくよかったんじゃないかと。 まとめ 検索は話してくれる人が多いし話題に事欠かないなぁという印象でした。 今回も、スピーカーの皆さん、会場提供をしていただいた日経さんありがとうございました。\n他のユースケースのスピーカーも募集してます。ぜひMeetup.comの概要に記載してあるリンクからスピーカーの応募をお願いします！\n","date":1539765230,"dir":"post/2018/","id":"d3fa23c9066f943f10e8883de9340dea","lang":"ja","lastmod":1539765230,"permalink":"https://blog.johtani.info/blog/2018/10/17/26th-elasticsearch-tokyo-meetup/","publishdate":"2018-10-17T17:33:50+09:00","summary":"毎月開催の2回目になります。 今回は日経さんの会場をお借りしての開催となりました。 前回から、スピーカーの募集をhttp://bit.ly/Sp","tags":["elasticsearch","勉強会"],"title":"第25回Elasticsearch勉強会を開催しました。"},{"contents":"7/25にJJUGナイトセミナーでElastic Stackの紹介とAPMのJava Agentの紹介をしたので、補足のブログです。 （久々に書くな。。。）\nスライドとサンプルアプリのリポジトリはこちら。\nスライド：https://speakerdeck.com/johtani/intro-elastic-stack-and-elastic-apm-java リポジトリ：https://github.com/johtani/apm-beats-kubernetes-demo/tree/master サンプルアプリ 勉強会の頭でサンプルアプリへのアクセス用QRコードを用意して質問してもらう感じにしました。\nアプリ自体が質問の受付と、そこにある質問に対して聞きたいかどうかのVoteができる仕組みになっています。 セッション最後にこの画面をみながら答えました。 手を挙げていただくよりも、匿名（名前入れるようになってますが、実名である必要はない）で登録できるし、 みんなが聞きたいかどうかもわかるので便利だなぁと。\n元は、Elastic{ON} 2018であった「Docker \u0026amp; Kubernetes Log Collection and Monitoring with Beats and Elasticsearch」のサンプルアプリです。 これをSpring Bootに移植して、ちょっとだけサンプルコードを追加したものになります。\n構成とかの補足 スライド、GitHubのリポジトリのREADMEにある図は、k8s上のサンプルアプリケーションの構成だけでした。 ElasticsearchとKibanaを含めた図はこんな感じです。\nk8s上の各種Beats、APM Serverは一旦Elastic CLoud Elasticsearch Service（AWS Tokyoリージョンにデプロイ）に対してデータを投げます。 で、KibanaはGKE(k8s on GCP)で動かして、実際に勉強会ではkubectl proxyで接続してから表示していました。 この構成にしている理由は次の理由です。\nElastic CloudのElasticsearchクラスターにデータを投げている理由 クラスターの起動が簡単。 データを永続化したい。k8sのアプリは必要がなくなったらデータを削除したいから。 k8sのdeploymentを書く手間を省く 普段使ってるので。。。 KibanaをGKEで動かした理由 Elastic Cloudでは*「現時点(7/29現在)」*で、KibanaでAPM専用のUIを起動できない ローカルである必要はない といったところです。 Elastic Cloudのインスタンスを起動したままにしておけば、デモをしなくても、このタイミングのログ、メトリクスを 再利用して話をすることも可能です。\nまとめ ということで、簡単ですが、構成の補足でした。 勉強会では告知したのですが、今後の勉強会はトピックスごとでやりたいなと。ということで、どんなトピックスに興味があるのか、スピーカーの応募にはどんなツールが話しやすいかなどといったことのアンケートを集めております。ぜひご協力ください！ また、アンケート、このブログに関する質問がある場合は、@johtani、もしくはブログへのコメントでお願い致します。\n今後の勉強会のやり方などについてアンケートを実施中です。https://t.co/XU15CHro0n 皆さん是非ご協力ください。ここにない項目については返信をお願いします。 #elasticsearchjp\n\u0026mdash; Jun Ohtani (@johtani) 2018年7月23日 ","date":1532843130,"dir":"post/2018/","id":"10ae016e19fff6ae9cfaeb8534fa47f9","lang":"ja","lastmod":1532843130,"permalink":"https://blog.johtani.info/blog/2018/07/29/apm-java-at-jjug/","publishdate":"2018-07-29T14:45:30+09:00","summary":"7/25にJJUGナイトセミナーでElastic Stackの紹介とAPMのJava Agentの紹介をしたので、補足のブログです。 （久々に書く","tags":["勉強会"],"title":"JJUGナイトセミナーで話しました"},{"contents":"第2回から少し間が空いてしまいましたが、templateで作成したプラグインのディレクトリ構成とどういう流れでデータがやり取りされるかについてみていきます。 （2018/02月時点で作成したディレクトリ構成にしたがって説明します） ちなみに、JavaScriptの優れた開発者ではないので、誤解している点や、効率の悪い書き方などがあるかもしれません。見つけた場合は、連絡をいただければと思います。\nでは、まずは作成したディレクトリ構成についてみていきましょう。\nディレクトリ構成 simple-sample-kibana-pluginがプラグインのプロジェクトのトップディレクトリになります。このディレクトリに次のような構成でサブディレクトリが存在します(なお、画像はIntelliJに取り込んだ後のディレクトリになっているので、.imlなど、不要なファイル/ディレクトリが存在しています)。\n主要なディレクトリ、ファイルについて簡単に一覧で説明します(順不同)。\nファイル/ディレクトリ名 説明 index.js プラグインの本体。Kibanaはこのファイルのオブジェクトを読み込みプラグインを起動。設定などの読み込みもこちら。 package.json npm/yarnのパッケージに関する情報を定義するファイル README.md README。プラグインの説明などを記載する。インストール方法なども記載すると便利 public ブラウザ側に配布されるプログラムや画像一式 public/less/main.less LESS用のファイル。アプリ固有のスタイルなどを記載 public/app.js ブラウザ側で読み込まれるプラグインのモジュールなど。 public/template/index.html HTMLのテンプレート。ブラウザ上での描画に利用 server/routes Kibanaサーバー側で動作するプラグイン。hapi.jsを利用してREST APIを実装する 重要なファイルについて少しだけ説明します。\npackage.json npmやyarnでビルドなどをするときに使用するパッケージ情報を記載するためのファイルです。 プラグインの名前、バージョン、説明などを記載します。 Kibanaのバージョンについてもこちらで管理します。この情報を また、ライブラリなどの依存関係についてもこちらで記載しています。 以下、抜粋。\n{ \u0026#34;name\u0026#34;: \u0026#34;simple-sample-kibana-plugin\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;0.0.0\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;Sample plugin for explaining how to make kibana app\u0026#34;, \u0026#34;main\u0026#34;: \u0026#34;index.js\u0026#34;, \u0026#34;kibana\u0026#34;: { \u0026#34;version\u0026#34;: \u0026#34;6.2.1\u0026#34;, \u0026#34;templateVersion\u0026#34;: \u0026#34;7.2.4\u0026#34; }, \u0026#34;scripts\u0026#34;: { \u0026#34;lint\u0026#34;: \u0026#34;eslint **/*.js\u0026#34;, ... }, \u0026#34;devDependencies\u0026#34;: { \u0026#34;@elastic/eslint-config-kibana\u0026#34;: \u0026#34;^0.14.0\u0026#34;, \u0026#34;@elastic/eslint-import-resolver-kibana\u0026#34;: \u0026#34;^0.9.0\u0026#34;, \u0026#34;@elastic/plugin-helpers\u0026#34;: \u0026#34;^7.1.3\u0026#34;, ... \u0026#34;expect.js\u0026#34;: \u0026#34;^0.3.1\u0026#34; } } ちなみに私は、versionなどをリリースするたびに変更しています。\nindex.js 最初にKibanaに読み込まれるオブジェクトになります。 Kibanaのアプリの名前や、必要なモジュールなどを記載します。\nまた、kibana.ymlから設定など読み込む処理なども書くことができます。\n2行目のexampleRouteはサーバー側のAPIとして利用するhapi.js用のファイルのパスになります。\nuiExportsはこのアプリの画面に関する設定などの記載になります。 appの部分が実際にアプリの情報で、 mainがあとで説明するこのプラグインのUIのためのJavaScriptファイル(public/app.js)になります。mainですので、最初に読み込まれる処理が記載されているものを指定します。app.jsというファイル名を変更する場合は、こちらのappの部分を変更したファイルに合わせましょう。\nconfig(Joi)の関数が設定ファイルの読み込みなどの処理を記載する場所です。\ninit(server, options)の関数が初期化処理を記載する場所になります。 このサンプルアプリでは、2行目のimportで読み込んだhapi.js用のファイルの関数を呼び出しています。引数で渡しているserverがhapi.jsのserverオブジェクトになります。 routeメソッドを使用して作成しているプラグイン用のREST APIを追加しています。\nimport { resolve } from \u0026#39;path\u0026#39;; import exampleRoute from \u0026#39;./server/routes/example\u0026#39;; export default function (kibana) { return new kibana.Plugin({ require: [\u0026#39;elasticsearch\u0026#39;], name: \u0026#39;simple-sample-kibana-plugin\u0026#39;, uiExports: { app: { title: \u0026#39;Simple Sample Kibana Plugin\u0026#39;, description: \u0026#39;Sample plugin for explaining how to make kibana app\u0026#39;, main: \u0026#39;plugins/simple-sample-kibana-plugin/app\u0026#39; }, ... }, config(Joi) { return Joi.object({ enabled: Joi.boolean().default(true), }).default(); }, init(server, options) { // Add server routes and initialize the plugin here exampleRoute(server); } }); }; public/app.js 画面用のモジュールです。 uiRoutesという機能を使用して、アプリの呼び出しURLを定義します。テンプレートで作成したばかりの場合は、/というURLが追加されるのみです。\n実際に画面を表示する際に動くコントローラーの部分はその下の uiModules.controllerに指定してあるfunctionが画面描画の 処理を書く部分になります。 templateで作成したプラグインでは、\u0026ldquo;title\u0026quot;など表示に必要なデータを$scopeというオブジェクトに詰め込んでいます。 これはAngularJS(1系)でのモデルオブジェクトになります。\nimport moment from \u0026#39;moment\u0026#39;; import { uiModules } from \u0026#39;ui/modules\u0026#39;; import uiRoutes from \u0026#39;ui/routes\u0026#39;; import \u0026#39;ui/autoload/styles\u0026#39;; import \u0026#39;./less/main.less\u0026#39;; import template from \u0026#39;./templates/index.html\u0026#39;; uiRoutes.enable(); uiRoutes .when(\u0026#39;/\u0026#39;, { template, resolve: { ... } }); uiModules .get(\u0026#39;app/simple-sample-kibana-plugin\u0026#39;, []) .controller(\u0026#39;simpleSampleKibanaPluginHelloWorld\u0026#39;, function ($scope, $route, $interval) { $scope.title = \u0026#39;Simple Sample Kibana Plugin\u0026#39;; $scope.description = \u0026#39;Sample plugin for explaining how to make kibana app\u0026#39;; ... $scope.$watch(\u0026#39;$destroy\u0026#39;, unsubscribe); }); server/routes/example.js hapi.jsというNode.jsのためのサーバーフレームワークです。 このフレームワークをKibanaは使っており、Kibanaのサーバーとブラウザとのやり取りに使用するREST APIを記述するために使用しています。 例えば、Elasticsearchとのやり取りを実際に行うAPIなどをこのREST API内部で記述します。\nexport default function (server) { server.route({ path: \u0026#39;/api/simple-sample-kibana-plugin/example\u0026#39;, method: \u0026#39;GET\u0026#39;, handler(req, reply) { reply({ time: (new Date()).toISOString() }); } }); } pathの部分がブラウザ側からアクセスするURLになります。 実際にElasticsearchとやり取りする処理の書き方については、次回の記事で説明します。\nアーキテクチャ（簡易版） ざっくりですが、ファイルやディレクトリについて説明しました。 簡単なデータのやり取りについての流れを説明します。\nKibana自体はNode.jsで実装されサーバーとして動作していますが、ブラウザでアクセスすることで画面を描画しています。 簡単なコンポーネントを並べるとデータのやり取りはこのような形です。\nすごく簡易で大雑把な絵ですが。。。\n実際のプラグインとしては大きく、2つの処理があります。\nブラウザ上の処理 クリックなどのイベント処理 HTMLなどのレンダリング処理 Kibanaサーバー上の処理(Elasticsearchなどとの通信が必要な場合) 外部との通信処理 ブラウザ上では重い処理 絵に記載しましたが、ブラウザ上の処理についてはAngularJSが主なフレームワークで、サーバー上の処理についてはhapi.jsがフレームワークとなっています。\nまとめ ということで、今回はディレクトリ構造とファイルの説明、どういったフレームワークが使われ、データのやり取りがどのように行われているか説明しました。\n次回からは、実際に私が作成したAnalyze UIを元にElasticsearchとのデータのやり取りなどについて紹介していきます。\n","date":1524205801,"dir":"post/2018/","id":"04d818cbaac08b2915db15e0bffdcb5b","lang":"ja","lastmod":1524205801,"permalink":"https://blog.johtani.info/blog/2018/04/20/directory-layout-and-architecture/","publishdate":"2018-04-20T15:30:01+09:00","summary":"第2回から少し間が空いてしまいましたが、templateで作成したプラグインのディレクトリ構成とどういう流れでデータがやり取りされるかについ","tags":["Kibana","plugin"],"title":"Analyze UIとKibanaのプラグインの作成方法（第3回）"},{"contents":"#MANABIYA のブースでセッション時間の合間はお客さん少ないので、ブログを書いてみたり。 ここ数年、スポンサーとして色々なカンファレンスに参加してるんですが、それについてちょっと気なることがあったので。\nスポンサー情報ってどうやって探してます？ 職業柄、カンファレンスにCfP出してセッションしてみたり（落ちること多いけど）、スポンサーとしてブースを出したりしています。\nで、疑問があるんですが、みなさんどうやってカンファレンスの情報をゲットしてます？\n数年やって来て、検索したりして見つけてスポンサーした結果、 これまでスポンサーしていたので、情報が流れてくるという感じになりました。 それ以外だと、@yusuke さんに教えてもらったりと言うのがあったんですが。。。\n自分が知らない、自分のTwitterで流れてこないという情報をどうやったら集められるかな？と言うのが今の課題になってます。 と言うことで、ブログを書いてみました。\nカンファレンスを検索できるサイトとか便利？ で、私の会社は検索エンジンの会社なんで、検索できると便利では？と考えるんです。\nCfPの応募期間で絞り込みできたり、場所で検索できたり、スポンサー情報を取得する方法が載ってたりすると便利なのではないかなと。 便利に思うのが自分だけでは？と言うのがあるんですが。。。\nあると嬉しい人、データを掲載したいなと言う人いますでしょうか？ Google Formなどで入力してもらえるようにして何か作るのもありかなぁと考えているところです。 それとも、スポンサーを募っているカンファレンスのスタッフや企業の人は、こういう情報は特定の人にだけ知ってもらったりしたいでしょうか？\n自分だけではわからないことが多いので、懸念事項や、それダメでしょ？ あると便利！などのフィードバックをいただけると助かります。\nそれ以外に、カンファレンス自体の場所、開催日程、サイトへのURLなどが検索できると便利だったりするかも？というのもあります。\nとりあえず、自分が知ってるものだけ、個人的に検索できるようにしたりするのがいいかなぁ。。。 コメントお待ちしてます！\n","date":1521867012,"dir":"post/2018/","id":"8cc6b19cd410e638f4beaf1642f4f52a","lang":"ja","lastmod":1521867012,"permalink":"https://blog.johtani.info/blog/2018/03/24/how-to-find-conferences/","publishdate":"2018-03-24T13:50:12+09:00","summary":"#MANABIYA のブースでセッション時間の合間はお客さん少ないので、ブログを書いてみたり。 ここ数年、スポンサーとして色々なカンファレンスに参加してるんです","tags":["カンファレンス","スポンサー"],"title":"カンファレンス情報の探し方（CfP、スポンサー応募、開催期間など）？"},{"contents":"Rustで言語処理100本ノックの続きで、05と06です。\n05. n-gram 問題はこちら。\nみんな大好きn-gramです。単語と文字があるので、それぞれ別関数として実装しました。問題はbi-gramとn=2だったのですが、一応、nを引数に取る形にして実装しました。\nまずは、単語です。\n前に実装した時は、自分で頑張って、先頭から数えたりしてたんですが、Rustにはwindows(n)という便利なメソッドがsliceにあり、これを利用したらこんな簡単になりました。 sliceは特定のシーケンス（配列）に対してある特定のサイズのViewを作ってくれます（説明あってる？）。 ということで、文字列から、単語の配列（スペース区切りで単語にしている）を作り出して、windows(n)メソッドを通すと、 nで指定した数字の個数だけの単語の配列を先頭から、1単語ずつずらして作ってくれます。まさに、n-gram! 戻り値は配列の配列です。 1点だけ疑問点があるのは、「空白で区切ったものが単語」という考え方で良いかどうか？という点です。特に問題文にはそれが明示されていなかったので、このような前提を置いてあります。\ninvalid_n(text, n)はnの値や入力された文字列をチェックする関数です。入力チェックですね。nが1よりも小さい場合、入力文字列が空文字の場合は、warningでメッセージを出して、空の配列を返す仕組みになっています。\n次は、文字です。\n単語とほぼ一緒ですが、入力文字列を、1文字ずつの配列にしているところが異なります。 また、windowsメソッドで取り出された、1文字ずつのn個の配列を文字列に修正してから、結果の配列に入れています。 ここでも疑問は空白をどう扱うか？になります。 現時点では、空白も1文字とカウントして扱うことにしてあります。 どっちがいいのかなぁ？\n06. 集合 問題はこちら。\nまずは、文字n-gramで出てきた文字列をSetに入れる関数から。\nn-gramの問題で実装した文字n-gramの関数の戻り値を配列ではなく、BTreeSetに変えたものになります。比較などがしやすいように？と思い、BTreeSetを利用していますが、実装としてはHashSetでも問題ないかと。 この関数の集合（Set）を元に、和集合、積集合、差集合を求める関数を実装しました。\nSetのメソッドとして、それぞれ、union＝和集合、intersection＝積集合、difference＝差集合のメソッドが用意されているので、特に困ることはなかったです。 差集合については、1-2と2-1で結果が異なるはずなので、それぞれをテストケース、main.rsで出力するようにしてあります。\n所感 今回は、Rustがすでに実装してくれているメソッドがあったので楽ができました。 やりたいことに相当するメソッドがあるかどうかを調べるためにリファレンスを探さないといけないのがちょっと苦労しましたが。。。 ということで、今日はこの辺りまで。\n","date":1521549285,"dir":"post/2018/","id":"d791eaca9375ca1b36a987af22ee71dd","lang":"ja","lastmod":1521549285,"permalink":"https://blog.johtani.info/blog/2018/03/20/nlp100-ch01-05to06/","publishdate":"2018-03-20T21:34:45+09:00","summary":"Rustで言語処理100本ノックの続きで、05と06です。 05. n-gram 問題はこちら。 みんな大好きn-gramです。単語と文字があるので、それぞれ別関","tags":["Rust","nlp100"],"title":"第1章の05から06までやってみた（言語処理100本ノック）"},{"contents":"Rustで言語処理100本ノックの続きで、03と04です。\n03. 円周率 問題はこちら。\n入力文字列を.split_whitespace()で分割しておいて、単語ごとのベクタを作り出し、そこに対して文字を数えました。「アルファベットの」という注意書きがあるので\u0026quot;,\u0026ldquo;や\u0026rdquo;.\u0026ldquo;は含めずに数えるのかなということで、 charの.is_alphabetic()でA-zまでの判定をしつつ、文字のベクタを作ってから、そのベクタの長さを詰め込むという感じでやりました。\nこれ、ひょっとして、collectでベクタにしなくても、i32とかの変数でカウントするとベクタ作らなくてもいいなじゃにか？というのに書きながら気づいた。。。 必要じゃないオブジェクトを作ってるよなぁ。\n.filter().mapとかかな？この辺りの操作がイマイチ苦手。Javaでもまだ馴染めてないところなんだよなぁ。頭固すぎ。\n04. 元素記号 問題はこちら。\n大作ですね。何だろう、大作。。。 最終的に連想配列（辞書型もしくはマップ型）」ということだったので、BTreeMapに詰め込んでます。 HashMapでもいいんですが、文字列で出力した時にキーが並んで見やすいからという理由で、BTreeMap使いました。それ以上の理由はないです。普通にやるなら、HashMapかな？\n入力として、1文字だけの出力をする場所（インデックス番号）の配列を受け取ってます。1点だけ、チェックしていない、けど入力値の想定をしていて、idx_one_symbolsがソートされていて、小さいものから順番に出てくるものとしてます。関数作って、チェックすべきかな？\nで、指定された場所の最後のものが入力文字列よりも大きいかどうかというチェックもしています。（あー、テストケース書いてないな）この辺りのせいでちょっと長めになってます。\n単語の配列を作るのは03の時と同じやり方です。 回しかたがちょっと違って、.iter().enumerate()で回して、添字と値をタプル？でとりだしてます。添字を見ながら1文字取り出すのか、2文字取り出すのかの判断が必要だからです。あとは一緒ですね。1文字取り出すときは、.first()を使って見ました。 実は、2文字取り出す時と、1文字の時と同じロジック使った方が共通化できて、短くなった？？？\nということで、こんな感じでした。いつものようにツッコミお待ちしてます。\n所感 問題それぞれについてではなく、 やってて思ったのですが、問題に対して想定される結果が記載されていると嬉しいなと思いました。 ロジックについては、各自実装者に寄ったり、言語によって違いが出たりするし、議論するベースになっていいかなと思うんですが、 問題で想定されている結果（出力）があると、自分の実装にケアが足りないところがないのか？とか、ケアしなくていい点とかがわかるのかもなぁと。 ユニットテスト相当のものがあると楽かなぁと。\nこのケースどうするんだろ？みたいなのが、ところどころコメントに残ったりしてます。 出題の意図としては、その部分も議論の対象ということなのかな？\n","date":1519032848,"dir":"post/2018/","id":"e6684944c37dbdd4c08d978af9e47bed","lang":"ja","lastmod":1519032848,"permalink":"https://blog.johtani.info/blog/2018/02/19/nlp100-ch01-03to04/","publishdate":"2018-02-19T18:34:08+09:00","summary":"Rustで言語処理100本ノックの続きで、03と04です。 03. 円周率 問題はこちら。 入力文字列を.split_whitespace()で分割して","tags":["Rust","nlp100"],"title":"第1章の03から04までやってみた（言語処理100本ノック）"},{"contents":"「鉄は熱いうちに打て」ということで、言語処理100本ノックの第1章の00から02を実装してみました。\nさて、これが効率がいいのかどうかはさておき。\n00. 文字列の逆順 問題はこちら。\n最初、Vecのreverse()で逆順にして0からlen()まで回してたんですが、pop()がいい感じに後ろから取れることがわかったんで、切り替えました。 シンプルかな？\n01. 「パタトクカシーー」 問題はこちら。\n1文字ずつ取り出して、インデックスの番号が2で割ってあまりが0なら文字列に追加していくってのでやってみました。 （ブログ書いてるところで、i in 0..char_array.len()じゃなくて、(i, x) in char_array.iter().enumerate()に切り替えました。） matchとか使って綺麗に書けたりするのかなぁ？\n02. 「パトカー」＋「タクシー」＝「パタトクカシーー」 問題はこちら。\nだいぶ思考錯誤してる感じがソースに現れてます。 とりあえず、両方の文字列をcharsの配列にして個々のイテレータを回しながら、next()の戻り値があれば追加していく感じにして、 終了条件が両方Noneを通ったらにしてるけど、、、 なんか、もっと綺麗にできないのかなぁ。。。 next()のタプル返す関数作って、とかでなんかできたりするかなぁ？\ngist-it 関係ないですが、GitHubのコードを貼り付けるのに便利なサービスがあるみたいです。\nhttp://gist-it.appspot.com\nこれほんと便利だな。行数指定もできるし。 説明するのが簡単だ。\nとりあえず、今日はこの辺まで。なんか、いい知恵あれば教えてください！\n","date":1518699541,"dir":"post/2018/","id":"bbe1deec11d459bdb348051b970abdaf","lang":"ja","lastmod":1518699541,"permalink":"https://blog.johtani.info/blog/2018/02/15/nlp100-ch01-00to02/","publishdate":"2018-02-15T21:59:01+09:00","summary":"「鉄は熱いうちに打て」ということで、言語処理100本ノックの第1章の00から02を実装してみました。 さて、これが効率がいいのかどうかはさてお","tags":["Rust","nlp100"],"title":"第1章の00から02までやってみた（言語処理100本ノック）"},{"contents":"ども。新しいもの始めないと頭が退化する。。。ということで、こちら（ happy new year and new language - katsyoshiのめもみたいなもの）のブログに触発されて、言語処理100本ノックをはじめてみました。\n言語処理100本ノックとは、自然言語処理になるのかな、東北大学の研究室の先生が公開している言語処理に関する実践的な課題をベースにプログラミングなどのスキルを学んでいくための問題集です。 元々はPythonを対象とされているようですが、Rustでやってみようかと。 まぁ、先ほどあげたブログの二番煎じです。。。 ちなみに、インスパイアされた元のブログの方はRust book 2nd editionを読み終えたらしいですが、私はかじった程度です（ダメかも？）。\nNLPもRustもかじった程度なので、苦戦しそうですが、ちょっとずつやっていこうかなと。 ということで、準備運動の第1章から始めようかと。 GitHubにちょっとずつあげていく予定です。 https://github.com/johtani/nlp100-rust\nまぁ、まずは宣言のブログを書いてみただけです。 続いてなかったら、叱咤激励してください。叱咤だけかも？\n","date":1518605551,"dir":"post/2018/","id":"a673b3829e62477e01abc75465416b86","lang":"ja","lastmod":1518605551,"permalink":"https://blog.johtani.info/blog/2018/02/14/start-nlp100-with-rust/","publishdate":"2018-02-14T19:52:31+09:00","summary":"ども。新しいもの始めないと頭が退化する。。。ということで、こちら（ happy new year and new language - katsyoshiのめもみたいなもの）のブログに触発されて、","tags":["Rust","nlp100"],"title":"言語処理100本ノックはじめました(Rust)"},{"contents":"第1回では、Analyze UIというプラグインの紹介をしました、ごく簡単にですが。\n第2回では、Kibanaのプラグインの作成方法を順を追って見ていこうと思います。今回は、プラグインのプロジェクトの作り方を説明します。 どんなファイルがあるのかなどについては第3回で説明します（2018/02月現在の方法になります。残念ながら、Kibanaのプラグイン作成自体はまだExperimentalな話になっていますので、変更がある可能性があります）。\n実はそれほど難しいというわけではありません。Kibanaのプラグインを作成するためのテンプレートが用意されています。template-kiban-pluginです。 テンプレートのリポジトリのREADMEに作業手順の記載があります。\nKibanaのリポジトリをClone、Checkout Node.jsの環境を用意する Kibanaを起動できるようにする SAOのインストール テンプレートによるプロジェクトファイルの生成 順を追って説明します。 PLUGIN_DEV_DIRというディレクトリ配下で作業をしている想定になります。\n1. KibanaのリポジトリをClone、Checkout 開発環境として、Kibanaが必要です。Kibanaのプラグインを作るので。 手順などはKibanaのCONTRIBUTING.mdに記載があります。 ということで、まずはKibanaのリポジトリをCloneします。\ncd PLUGIN_DEV_DIR git clone git@github.com:elastic/kibana.git このままだと、masterブランチなので、開発したい対象のKibanaのバージョンのブランチもしくはタグをcloneします。今回は6.2.1向けということで、次のようになります。\ngit checkout v6.2.1 これで、ソースが6.2.1向けになりました。\n2. Node.jsの環境を用意する Node.jsをインストールします。 Kibanaのリポジトリに.node-versionというファイルがあります。 こちらにNode.jsのバージョンが記載されています。 Kibanaが使用しているNode.jsを利用できるようにします。ローカルではnvm利用してインストールしました。後から、切り替えが可能だからです。 nvm自体のインストールについてはnvmのサイトをご覧ください。 nvmがインストールできたら、次のコマンドで、Kibanaが使用しているバージョンをインストールします。\ncd kibana nvm install \u0026#34;$(cat .node-version)\u0026#34; すでにnvmを利用している場合などは、Kibana起動時にKibanaのバージョンに合わせたNode.jsに切り替えるようにしてください。\n3. Kibanaを起動できるようにする Kibanaではyarnというjavascript向けのパッケージマネージャーを利用して起動やビルドなどを行います。まずはyarnをインストールします。最近npmからyarnに切り替えたようです。 私はMacだったので、brewでインストールしました。 インストールできたら、次のコマンドを実行します。\nyarn これにより、package.jsonから必要なライブラリなどをダウンロードして来てくれます。 問題なければ「✨ Done in 439.30s.」というような表示がされます（結構時間かかりますね）。 では、Kibanaを起動できるか確認してみましょう。 さらに、Elasticsearchも起動してみます。 Kibanaのpackage.jsonの中にはElasticsearchを起動するためのスクリプトも用意されています。実際にはgruntを利用してタスクを実行しているようです。Elasticsearchの起動にはJavaが必要になります。 今回は6.2.1なので、JDK 8以降がインストールされている必要があります。 こちらはインストールされているものとします。\nyarn elasticsearch で起動できます。\n\u0026gt;\u0026gt; Started 1 Elasticsearch nodes. という表示が出てればOKです。 次にKibanaです。別のTerminalを起動して、以下のコマンドで起動できます。\nyarn start これだけです。\nserver log [06:58:56.930] [info][listening] Server running at http://localhost:5603 この辺りが出てればKibanaのServerは起動済みです。また、Elasticsearchに接続できていれば、次のログが出ているはずです。\nserver log [07:02:18.010] [info][status][plugin:elasticsearch@6.2.1] Status changed from red to green - Ready Elasticsearch接続用のKibanaのプラグインの状態になります。 これで、Kibanaの環境が整ったことが確認できました。 もちろん、Elasticsearchに関しては、yarnで起動せずに、tar.gzなどでダウンロードして来たElasticsearchを起動しておき、アクセスするといったことも可能です。プラグインなどをElasticsearchにもいれてテストしたい場合などはそちらの方が便利かもしれません。\n4. SAOのインストール では、一度、ElasticsearchとKibanaを停止しましょう。フォワグラウンドで起動しているので、それぞれのTerminalでCtrl+Cで停止できます。 Kibanaのプラグイン作成むけに、テンプレートが作られています。sao.jsというGitHubのリポジトリやnpmのパッケージをテンプレートとして使うことができるツールを利用してプラグインのプロジェクト（リポジトリ）を作成します。 実際にテンプレートとなるリポジトリはtemplate-kibana-pluginになります。 まずはSaoのインストールです。\nnpm install -g sao プラグインのテンプレートのページには上記のようにnpmを利用したインストール方法になっていますが、次のようにyarnでも可能です。\nyarn global add sao これで、saoがインストールできました。\n5. テンプレートによるプロジェクトファイルの生成 あとは、テンプレートを元にプロジェクトを作成します。 PLUGIN_DEV_DIRディレクトリ配下に、kibanaと同じ階層で作成するプラグイン用のディレクトリを作成します。\nmkdir simple-sample-kibana-plugin 以下のような構成になります。\nkibana simple-sample-kibana-plugin 次にテンプレートを適用していきます。\ncd simple-sample-kibana-plugin sao kibana-plugin@7.2.4 2行目がsaoを利用してプロジェクトを作成しているコマンドになります。 すると、次のような質問が出て来ます。 これらに答えるとプロジェクトに必要なファイル（package.jsonやREADME.mdなど）に入力した情報を適用したものを作ってくれます。\n? Name of your plugin? ? Provide a short description ? What Kibana version are you targeting? ? Should an app component be generated? ? Should translation files be generated? ? Should an hack component be generated? ? Should a server API be generated? 実際に答えた内容はこちら。\n? Name of your plugin? simple-sample-kibana-plugin ? Provide a short description Sample plugin for explaining how to make kibana app ? What Kibana version are you targeting? 6.2.1 ? Should an app component be generated? Yes ? Should translation files be generated? Yes ? Should an hack component be generated? Yes ? Should a server API be generated? Yes プラグインの名前などは、ディレクトリ名と同じものを入力補完してくれているので、そのままEnterでもOKです。 Descriptionについてはわかりやすいものを入力しましょう。 バージョンは、先ほどのKibanaのリポジトリに合わせて、6.2.1にしてあります。 あとは、作るプラグインの種類に応じて、必要なコンポーネントを作るかどうかの質問にYes/Noで答えます。 今回はサンプルの説明ということもあるので、全てYesで答えました。 ちなみに、私が実際に作成したanalyze-api-ui-pluginでは、appとtranslationとserverの3つを作成しました。 ただし、translationについては現在はテンプレートで作成したままのファイルが入っており、実際には利用してないです。\n完了したら、プラグインのサンプル入りのプロジェクトが完成です。 もう一度、Elasticsearchを立ち上げて、プラグインのプロジェクトからKibanaを起動してアクセスしてみます。まずは、PLUGIN_DEV_DIR/kibanaディレクトリの下で、Elasticsearchを起動します。\nyarn elasticsearch 次に、PLUGIN_DEV_DIR/simple-sample-kibana-pluginディレクトリの下で、以下のコマンドを実行し、プラグインが入った状態のKibanaを起動します。\nyarn start 問題なく起動すれば、ブラウザでアクセスすると次のような画面が表示されるはずです。\n左側にメニューが1つ増えています。 クリックすると、上記画像のような画面が表示されるはずです。\nこれで、カスタムプラグインの開発ができる環境ができました！ 次回は、プロジェクトのディレクトリ構成や、どんなツールが内部で使用されてデータのやり取りが行われているかについて説明します。お楽しみに。\n","date":1518167857,"dir":"post/2018/","id":"7b6cb59a177abe9767fd22da5a03b1e6","lang":"ja","lastmod":1518167857,"permalink":"https://blog.johtani.info/blog/2018/02/09/getting-started-template-kibana-plugin/","publishdate":"2018-02-09T18:17:37+09:00","summary":"第1回では、Analyze UIというプラグインの紹介をしました、ごく簡単にですが。 第2回では、Kibanaのプラグインの作成方法を順を追って","tags":["Kibana","plugin"],"title":"Analyze UIとKibanaのプラグインの作成方法（第2回）"},{"contents":"あけましておめでとうございます。今年はサボりがちだったブログをちょっとずつ復活させようかと。 ということで、第1弾として、昨年少し作っていたKibanaのプラグインを何度かに分けて紹介したいと思います。\n今回はAnalyze UIというプラグインの紹介です。\n今回はインストール方法と簡単な機能紹介です。 細かな紹介は個別にやりたいと思います。\nAnalyze UI pluginとは？ Elasticsearchの_analyzeというAPI\u0002(個人的に好きなAPIです)をご存知でしょうか？\nElasticsearchは全文検索エンジンで、データの検索には転置インデックスというものを使用します。 Elasticsearchにデータを登録する際に、text型のデータの場合、この転置インデックスのキーとなる単語を決める処理のことをAnalysisと呼びます（Analysisの詳細については割愛します。後日説明するかも？）。 このAnalysisの処理が、入力されたデータの文字列に対してどのように行われて、結果としてどんな単語がキーとして用いられているかを確認できる機能が_analyze APIです。検索で単語がうまくヒットしないな？とか、なんで、こんなので検索結果に出てくるんだ？といった場合、このAPIを利用すると、どのような単語で転置インデックスが作られているかがわかるので、検索にヒットしない/する理由を見つけることができます。\nElasticsearchの便利な点はRESTfulなAPI＋JSONでやりとりができる点なのですが、_analyze APIの結果をJSONで受け取っても、見るのにちょっと苦労します。。。こんな感じ。\nリクエスト：\nPOST _analyze { \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;今年はブログをいっぱい書きますよ！\u0026#34; } レスポンス：\n{ \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;今年\u0026#34;, \u0026#34;start_offset\u0026#34;: 0, \u0026#34;end_offset\u0026#34;: 2, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;ブログ\u0026#34;, \u0026#34;start_offset\u0026#34;: 3, \u0026#34;end_offset\u0026#34;: 6, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 2 }, { \u0026#34;token\u0026#34;: \u0026#34;いっぱい\u0026#34;, \u0026#34;start_offset\u0026#34;: 7, \u0026#34;end_offset\u0026#34;: 11, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 4 }, { \u0026#34;token\u0026#34;: \u0026#34;書く\u0026#34;, \u0026#34;start_offset\u0026#34;: 11, \u0026#34;end_offset\u0026#34;: 13, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 5 } ] } このくらいの量であればまだなんとかなりますが、文章が長くなると辛いですよね。\nということで、GUIがあると便利だろうなぁと。で、作ってみましたというのが今日紹介するKibana用のAnalyze UIプラグインです。 こんな感じで、Kibanaのアプリの一部として動作しブラウザ上で、入力テキストの文字列がどのようにanalyzeされて、単語になるかがわかります。\n（先ほどのAPIのサンプルと同じものを画面で入力した結果になります）。\nインストール方法 現時点の最新版Kibana（6.1.2）に対応しています。 Kibanaのディレクトリでkibana-pluginコマンドを利用してインストールします。\n./bin/kibana-plugin install https://github.com/johtani/analyze-api-ui-plugin/releases/download/6.1.2/analyze-api-ui-plugin-6.1.2.zip これだけです。 で、Kibanaを起動していただくと、左のメニューに「Analyze UI」という項目が増えています。\nクリックすると、Analyze UIが表示されます。\n初期画面は入力された文字を特定のAnalyzerで処理した場合の結果を見るための画面です。綱目の説明は画像をご覧ください。\n先ほどのJSONよりは見やすくなったかと思います。 そのほかにもいくつか画面や機能があるのですが、今日はこの辺りで。 「_analyze API便利なんだけど、JSONは。。。」とか「検索うまくできないなぁなんでだろう？」と思っている方は、ぜひ試して見ていただければと。 問題点などありましたら、GitHubのIssueを登録してください。\n","date":1516343806,"dir":"post/2018/","id":"4afcb20d4d95bcd1bde3aa6b7f552660","lang":"ja","lastmod":1516343806,"permalink":"https://blog.johtani.info/blog/2018/01/19/how-to-make-kibana-plugin-example-analysis-ui/","publishdate":"2018-01-19T15:36:46+09:00","summary":"あけましておめでとうございます。今年はサボりがちだったブログをちょっとずつ復活させようかと。 ということで、第1弾として、昨年少し作っていたK","tags":["Kibana","plugin"],"title":"Analyze UIとKibanaのプラグインの作成方法（第1回）"},{"contents":"今年は紅白を見ながら書いてます。 今年はいろんなところに出張に行ったなぁ。\n振り返り（2016年に書いた抱負から） まずは去年の抱負を元に。\nもちろん英語の継続 もちろん継続してます。英会話しながら海外TVドラマや映画を見てます。 ちょっとずつ英語字幕でも見ようとしてますが、まだまだだなぁ。 あと、TOEICを受けてないんで、それは受けないと。 見たドラマはこの辺です。\nER ウォーキング・デッド Agent of Shield SUITS Mr.Robot(いまいち話の展開についていけなかった) 継続的にイベントに登壇 OSCに今年もブース出してセッション持ってました。 勉強会ももちろんやりました。 あと、外部のカンファレンス（FOSS4G、BigData Analytics、db tech showcaseなど）や 勉強会(monitoring勉強会やCA.ioなど)にも登壇させていただきました。 もっと外部から読んでいただいたり、CfPに応募して通過できるようにしないとなぁ。\nもっと開発＆ブログ ブログはすみません。。。来年頑張ります。。。 ブログの代わりに書籍を出せました。データ分析基盤系の書籍になるので、興味のある方はのぞいて見ていただければ。\n開発はちょっとやってます。今年後半はKibanaのプラグインとかをちょっと書いてました。 Ingest-CSVもちょこちょこバージョンアップに追従してたりします。\nサポートエンジニア獲得！ 獲得しました！（自分の成果かどうかはわかりませんが。。。） 今は3名体制でサポートしてもらってます。おかげさまでだいぶサポートする機会が減ってきました。 開発は世界各地どこでも募集中だったりしますので、ぜひ連絡いただければと。\n個人的な検索勉強会の再開 再開しました。検索エンジン自作入門を知人と隔週くらいで読んでます。読んでるだけではあれなんで、実装もしてたり。全然違う言語でトライして見ようと思ったのでRustで書き始めてます。まずは、単純なところからと思ったんですが、 Rustの書き方の違いにだいぶ戸惑ってます。。。\n振り返り(今年あったできごと) ここからは今年の出来事を。\n初アメリカで釣り Nintendo Switch! 初Japanチームオフサイト チーム変更 初Berlin Buzzword! 母校（大学）訪問 Kibanaプラグイン開発 今年も初モノがちらほらとありますね。 今年もカレンダー振り返ってたら「え？これ今年だったの？」ってのがちらほらありました。。。\nアメリカで釣りやりました。自社のカンファレンスElastic{ON}のあとに、エンジニアが集まるミーティングがあるんですが、そこで1日Fun Dayがあって、そこで釣りをやりました。 魚群探知機とかで魚探すんですね、最近のは。2、3匹釣ったので非常に楽しかったです。 来年はスノーシューにチャレンジする予定。\nNintendo Switch買って、ゼルダやりました。今はイカやってます。 イカ欲はちょっと減ってるかもなぁ、1に比べると。 あとは、子供に買ったマリオやったりしてるかな。\nここ10年くらい行きたいと思っていたカンファレンス、Berlin Buzzwordに行ってきました！ これが今年一番嬉しかった出来事です。Luceneコミッターの方々にも会えたし。特にPoliceman JenkinsのUweさんに会えたのが本当に感激でした。。。 来年も行けるといいなぁ。。。\n今年も出張が多めだったのであちこち飛び回ってたなぁ。 そんな飛び回っている中で、故郷である広島（出身地？）に出張で行ったので、母校に顔を出してきました。 変わってなかった。。。自分が一期生なので、自分が入学した時はまだクレーンとか立ってるような新校舎だったんだけど、それが20年くらい経て、だいぶ古くなってました。。。 広島市内は港近くに高速道路とか出ててだいぶ様変わりしてました。 ただ、小学校も高校も変わってなかったなぁ。久々に高校の同級生にも会えたし。 また、機会があればぜひ行きたいなと。帰省する場所ではなくなったので、行く機会がないんですよね。。。\n開発もちょっとやってます。Kibanaのプラグインに挑戦して見てます。 いまだにJavaScriptは苦手なんですが。。。 ちょっとずつ改良して、ひょっとすると本体とかに取り込めるかな？ あとは、今年始めたRustをちょっとずつ継続して行きたいなと。\n来年の抱負 最後は来年の抱負を。\nもっと英語の継続＆TOEIC 継続的にイベントに登壇 CfPもっと出すぞ！ もっとブログ！ 雑誌やWeb系雑誌で記事を。 コミュニティを別の方法で盛り上げ Elasticsearchなど検索系の開発にも参加 英語はもちろんですね。今年は12月の自社イベントに合わせて多くのAPJチームの人が来て、 チームで会話できたし、もっと英語やらないとなぁと。前よりもちょっとは喋れるようになった気がしてます（気がしてるだけで、喋れてるかどうかは不明）。あとは、TOEIC受けて、実力チェックしてみないとなぁ。\nイベント登壇はまぁ、DevRelですから、一応。 来年もとりあえず、3月までは毎月どこかでブース出してます。 Ask Me Anything的なブースの出し方を今年はしてみようかなと思ってるので、 ちょっと使い始めたけど、この辺よくわからないと思ってる方、ぜひ質問しに来てください。 ブース出すだけじゃなくて、スピーカーとしていろんな場所で喋れるようにしないとなぁと。 もっと幅広く知ってもらえるように雑誌とかで連載できるようにしたいなぁと思ってます。 また、日本語の入り口の情報を増やすためにブログも書かないとなぁ。\n勉強会も継続しますが、別の方法でも盛り上げて行きたいなぁと。 勉強会はどうしても聞く人が多くて、ユーザーの間での交流や情報交換とまでは行ってない気がするし、discuss.elastic.coというフォーラムで質問は増えて来てるけど、もう少し交流しやすい場があると使ってもらえるかなぁ？と思っていたり。 何かおすすめとかあれば、連絡ください。 meetup.comの勉強会のページにも掲示板はついてるんだけど交流しにくそうだし。\n来年は自分が最も興味のある検索系の開発にも参加したいなぁと。 Elasticsearchをちょっとずつ時間見つけてやってたりはしますが、もう少し首を突っ込んで行きたいなぁと。Swiftypeもジョインしたし。もっと検索やって行きたい気持ちが強いので。\nさて、ということで、今年もあと1時間なくなりました。 今年も様々な面で色々な方々に助けていただけました。本当にお世話になりました。 この場を借りてお礼申し上げます。\n来年ももちろん、色々な方に助けてもらうと思いますが、よろしくお願いいたします！\n","date":1514723443,"dir":"post/2017/","id":"7c21b70f9e9c782c1f5153268e0cc1c1","lang":"ja","lastmod":1514723443,"permalink":"https://blog.johtani.info/blog/2017/12/31/looking-back-2017/","publishdate":"2017-12-31T21:30:43+09:00","summary":"今年は紅白を見ながら書いてます。 今年はいろんなところに出張に行ったなぁ。 振り返り（2016年に書いた抱負から） まずは去年の抱負を元に。 もちろ","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2017）"},{"contents":"Merry Christmas! Elastic Stack Advent Calendar 2017の24日目の記事になります。\nちょっとですが、2018年のElasticについて書いてみようかと思います。\nイベント いくつか出展が決まっているイベントがあるのでまずは宣伝を。\nOSC Osaka 2018 まずは、1月25日、26日にOSC Osaka 2018に出展し、話をします。参加者がいそうであれば、25日や26日の夜に勉強会もありかなぁと思っています。 セッションでは入門的な話をする予定です。ブースにいますので、色々質問がある関西の方はぜひご参加ください。\nDeveloper Summit 2018 2月15日、16日はDeveloper Summit 2018に出展します。 こちらでもブースにいますので、AMA（Ask Me Anything）的に使っていただくのもいいかなと。 デブサミに参加される方はぜひお立ち寄りください。\nManabiya 3月23日、24日はManabiyaに出展します。 こちらでもAMAのつもりでブースを出す予定です。質問がある方はぜひお立ち寄りください。 こちらのイベントは初めての開催になるようなので、どんなイベントになるか楽しみにしています。\nイベント回りはこの辺りで。 また、1月末に勉強会を予定しています。決まり次第またMeetup.comの方々にメールを出す予定です。\nElastic Stackの2018年は？ Canvas! 昨年のElastic{ON}でみなさんをCanvasがリリースされるかなぁと。 現在、みなさんにテストしてもらえるようにcanvas.elastic.coというサイトを公開中で、実際にインストールして試すことができるようになっています。 ぜひ、触って、全く新しいUIを体験して見てください。\nSQL? こちらも昨年のElastic{ON}でみなさんから反響があったものです。 もう直ぐでてくるのではないかなぁと。\nその他は？ いくつか面白そうで、取り込み済みのものをピックアップしておきます。\nAdd ranking evaluation API 検索クエリなどに対して検索結果のランクのクオリティを評価するためのAPIの追加（7.0予定） JDK9サポート？ 6.2でサポートされそうです。が、LTSのJDK8が推奨のままの予定です。 High-level REST ClientでいくつかAPIが追加 https://github.com/elastic/elasticsearch/pull/27574、https://github.com/elastic/elasticsearch/pull/27351 APM正式リリース？ ベータ版がリリースされているので、秒読み段階？ ということで より詳しく知りたい方は、サンフランシスコで開催されるElastic{ON} 2018に参加するのが一番です！（ステマ） 私も参加予定ですので、ぜひ、現地でお会いし、色々な情報をゲットしましょう。\n明日で、今年のAdvent Calendarも最後です。micci184さんの記事を楽しみにしましょう！\n","date":1514124616,"dir":"post/2017/","id":"f3a9b931b7f552a4f9dfa61ce4f39f0e","lang":"ja","lastmod":1514124616,"permalink":"https://blog.johtani.info/blog/2017/12/24/elastic-2018/","publishdate":"2017-12-24T23:10:16+09:00","summary":"Merry Christmas! Elastic Stack Advent Calendar 2017の24日目の記事になります。 ちょっとですが、2018年のElasticについて書いてみようかと思います。 イベント いくつか","tags":["elasticsearch"],"title":"2018年のElasticは？"},{"contents":"Elastic stack (Elasticsearch) Advent Calendar 2017の1日目の記事になります。\nまだ、1ヶ月を残していますが、簡単に今年起こったことを振り返ってみようかと思います。思った以上に色々ありましたね。。。\nElastic Stack 5.2.0リリース (1月) リリース記事はこちら\nHeatmapがKibanaで追加されたり、Heartbeatがベータですが追加されました。 個人的には、Terms aggregationのFiltering Valuesによるパーティションが便利になったと思います。Terms Aggsでページングに似たことができるようになりました。\nElastic{ON}17開催 (3月) 第3回目のユーザカンファレンスが開催されました。 バレーダンサーの踊りから始まったキーノート、様々なユーザ企業によるユースケース発表などいろいろありました。 セッションはこちらのサイトからから録画を見ることができます。 SQL for ElasticsearchやAwardが目を引いたと思います。SQL対応まだ出てきていないですが、もうすぐじゃないかと！\nElastic Stack 5.3.0リリース (3月) リリース記事はこちら\nFilebeat moduleが導入され、ログファイルを取り込んでKibanaで可視化するまでの手順がより簡単になりました。Elasticの目指しているものの一つに、シンプルな使い方、簡単にはじめられることといったものがあります。KibanaのTimepickerもより便利になったのも、このバージョンからです。\nShayがCEOに (5月) 2月にすでに発表されていましたが、Elasticsearchの生みの親のShay BanonがCEOに正式に就任しました。CEOになってさらに、精力的に様々なことをやっていて、本当にすごいなと思います。\nElastic Stack 5.4.0、6.0.0-alpha1リリース (5月) 5.4.0リリース記事はこちら、6.0.0-alpha1リリース記事はこちら\n5.4.0は節目になるリリースでした。Machine Learningがベータリリースとして、X-Packに追加されましたし、ElasticsearchではCross Cluster Searchの改善が進みました。LogstashではPersistent QueueがGAになりましたし、KibanaにはTime Series Visual BuilderやEvent Contextなどが追加されますます使いやすくなりました。\nまた、6.0.0のalpha版も同時にリリースされ、様々な方からのフィードバックが集まり始めました。\nElastic Cloud Enterprise GAリリース (5月) Elastic Cloudのバックエンドの技術を製品に採用したものになります。 多くのElasticsearchクラスタを管理しないといけない方には朗報でした。\nOpbeatがJoin (6月) Opbeatチームがジョインしたのが6月です。Elastic StackがAPM\u0002(Application Performance Monitoring)でも活躍することになりそうです。APMの仕組みとしては、APM Agentをアプリ側に配置し、APM Serverへデータを送信し、Elasticsearchに保存、Kibanaで可視化するという流れになります。\nElastic Stack 5.5.0リリース (7月) リリース記事はこちら\nMachime LearningがGAリリースになったのが5.5.0です。色々な方から質問を受けました。それ以外にも、ElasticsearchのWindows MSI InstallerやKibanaのFilter editorなどが追加されました。Filter editorはこれまで検索条件を記述するのが難しいと感じていたKibanaユーザにとても喜んでもらえたものじゃないかなと。 GrokDebuggerが導入されたのもこのタイミングです。\nElastic Stack 5.6.0リリース (9月) リリース記事はこちら\n5系最後のマイナーリリースであり、6へのアップグレードが楽になる様々な仕組みが用意されたのがこのバージョンです。ElasticsearchのJava High level REST clientが導入されたのもこのバージョンです。本当に様々な機能が次のメジャーバージョンとの互換性のために組み込まれています。。。\nElastic Cloud on GCP (9月) リリース記事はこちら\nこれまで、AWS上のみで展開していたElastic CloudがGCP上でも展開されることになりました。残念ながら、日本リージョンはまだありませんが、問い合わせなどが増えれば今後サポートされる可能性が高くなると思います！\nElastic APM alpha (9月) リリース記事はこちら\nOpbeatチームによりElastic StackのAPMがAlphaですがリリースされました。APMがOpen Sourceで利用できるんです！Agentがもっと増えてくると色々なことに使えるようになると思います。ぜひAgentを作成してみてください！\nElastic Stack 6.0.0リリース (11月) リリース記事はこちら\n待ちに待った6.0.0のリリースです。新機能については本日(12/1)の昼に行われるウェビナーをご覧ください！\nSwiftypeがJoin (11月) ニュースリリースはこちら\nSwiftypeと呼ばれる検索のSaaSを提供している会社がジョインしました。 個人的には今年一番嬉しいニュースです。やはり、検索が好きなので。 簡単にSite Searchを構築できる仕組みは非常に面白いものです。 興味のある方は、ぜひ触ってみてください。日本語固有の機能などはまだないので、今後関わっていければなーと。\nElastic{ON} Tour Tokyo開催 (12月) まだ開催前ですが、今年も東京で1dayイベントを開催します。 残念ながら、もうSold outなので、キャンセル待ちになってしまっているみたいですが。私もスピーカーとして喋りますし、AMAブースにも立っています。 参加される方はぜひ声をかけていただければと思います。\nOSC 2017.Enterprise (12月) オープンソースカンファレンスで今年も様々な都市に出張しました。 今年の締めくくりということで、12/8に渋谷で開催されるカンファレンスに出展します。時間のある方は、ぜひブースに遊びに来てください。入門者向けのセッションもあるので、こちらもお待ちしております。\nまとめ 超駆け足ですが、今年を振り返ってみました。 今年もいろんなことがありました。書くのが大変だったw。 OSCなどイベントで声をかけていただいた皆様、ありがとうございました。\nさて、Elastic Stack Advent Calendar 2017は始まったばかりです。これからの記事を楽しみにしています！\nということで、 次はaeroastroさんの「Elasticsearchのインデックスを本当の意味で無停止再構築する方法」（Advent Calendarのページはこちら）になります、お楽しみに！\n","date":1512054000,"dir":"post/2017/","id":"fa0486610d8a02cea245c13c85b6de27","lang":"ja","lastmod":1512054000,"permalink":"https://blog.johtani.info/blog/2017/12/01/whats-happen-at-elastic-in-2017/","publishdate":"2017-12-01T00:00:00+09:00","summary":"Elastic stack (Elasticsearch) Advent Calendar 2017の1日目の記事になります。 まだ、1ヶ月を残していますが、簡単に今年起こったことを振り返ってみようかと思います。思った以上に","tags":["elasticsearch"],"title":"2017年のElastic StackとElastic"},{"contents":"Swiftypeでサイト内検索？ プレスリリース：Elasticがサイト内検索サービス最大手のSwiftypeを買収が出ましたが、SwiftypeチームがElasticにジョインしました！\n自分のブログ検索に導入してみる？ SwiftypeはSite Searchをサービスとして提供しています。 実際に指定したサイトのデータをクロールして、インデキシングし、検索できるようになります。 ものは試しということで、自分のブログを登録してみました。検索窓はつけてないですが。 14日間のFree trialがあるのでそちらで試してみましょう。 検索窓はデモとか作れたらかな。\nということで、Free trialへ まずはユーザ登録です。Googleのアカウントと連携するか、Swiftypeにメルアドを登録するかが選択できます。 登録できたら、次にどちらのプロダクトを使うかという選択画面が出てきます。 今回はサイト検索して見たいので、「Site Search」の「START FREE TRIAL」をクリックします。\nEngineの指定 Web Crawlerを利用するか、独自にSwiftypeのAPIを利用してデータを登録するかを選択します。\n今回は、お手軽な方のCrawlerを選択します。 すると次に、クロールしたいURLの指定画面が出てきます。\n今回は自分のブログなので、\u0026lsquo;http://blog.johtani.info\u0026rsquo;を指定します。\nで少し待つと、URLのチェック（存在チェックとか、接続チェックとか）が終わり、今回作成するEngineに名前をつける画面が出てきます。 「My Blog search」という名前にしてみました。\nsitemapがあるかどうかをCrawlerがチェックしています。 私のBlogはOctopressでできていて、sitemap.xmlも作ってくれているので、これを元にCrawlerはクロールをしてくれます。そのほかにもRSSやAtomサポートもあるみたいですね。 「COMPLETE SETUP」を押すと、Engineの管理画面が出てきます。\n「CRAWLING」という表示が出ています。クロールしている最中です。これが終われば、「PREVIEW」に代わり、検索できる準備ができたことになります。 実際にPREVIEWして見ると、次のような検索ができるようになります。\nそのほかにはWeightの調整画面などもありますね。フィールド毎に重み付けを変えて見たりもできます。\n日本語独自のAnalyzerなどはまだないので、そのあたりができてくるともっと便利になりそうです。 とりあえず、気になる方は触って見てはいかがでしょうか？ 個人的は検索に関するサービスが出てきたのですごく楽しみにしています！\n","date":1510280089,"dir":"post/2017/","id":"c20d71627e66a044b21780f56f2f9504","lang":"ja","lastmod":1510280089,"permalink":"https://blog.johtani.info/blog/2017/11/10/welcome-swiftype/","publishdate":"2017-11-10T11:14:49+09:00","summary":"Swiftypeでサイト内検索？ プレスリリース：Elasticがサイト内検索サービス最大手のSwiftypeを買収が出ましたが、Swifty","tags":null,"title":"Swiftypeがジョインしたので触ってみました"},{"contents":"久々に執筆しました。といっても、以前の書籍の更新版です。 まぁ、更新版といっても、私以外の方々は結構な量を書き直しor新規書き起こしされてますが。。。\nということで、みなさん「買って」から感想をいただけるとうれしいです！\u0002（以下の画像でAmazonにジャンプできます！Kindle版も発売中です。）\n今回もElasticsearchの章を担当しました。 5.4ベースで書きましたが、ちょっとずつ6でどう変わるかなども記載してあります。 また、付録ではLogstashやBeatsにもちょっと触れています。 また、自分が一番好きなKibanaの機能であるDev ToolsのConsoleについても記載してあります。こちらも合わせて目を通していただければと。\nみなさんのフィードバック（ツイート、ブログ、Amazonのコメントなどなど）をお待ちしております！\n","date":1505955750,"dir":"post/2017/","id":"4f88f3eebe44285ded812939553ef94c","lang":"ja","lastmod":1505955750,"permalink":"https://blog.johtani.info/blog/2017/09/21/release-intro-logging-analysis-system/","publishdate":"2017-09-21T10:02:30+09:00","summary":"久々に執筆しました。といっても、以前の書籍の更新版です。 まぁ、更新版といっても、私以外の方々は結構な量を書き直しor新規書き起こしされてます","tags":["elasticsearch","kibana","本"],"title":"データ分析基盤構築入門 を一部執筆しました。"},{"contents":"久々のブログ。 Elasticsearch勉強会を主催してますが、 プロダクトを超えて、検索で共通してある課題とか、悩みとか、あるかなぁと。 その辺りを話す場所を考えてみるのいいかもと思い、検索座談会ってのを5人でやってみた。\nとりあえず、初めてなので、5名ほどで。プロダクトはかぶってない感じでした。\n話した議題はこの辺り。 形態素解析の辞書は何を使ってる？有償のもの？ そもそも形態素解析？ 辞書の更新とかは？ シノニムってどうしてる？ サジェストとかのデータはどう作ってる？どうしてる？ 検索ログとかから作ってる？ 検索結果のランキングって検索結果だけで決めるの？ 検索漏れとかキーワードのミスマッチとかどうしてる？ 今後話したい内容はこの辺かな？ 緯度経度系の検索 画像検索、音声検索 検索のキーワードの調査とかしてる人とかいるかな？ どんな機能が欲しい？ 前処理としてはどんなことをしてる？ このあとどうしていくかはまだ考え中。知り合いを捕まえて、どんなことしてるかを聞きにいくのもいいし、議題みたいなことを決めて、それを話してくれそうな人にコンタクトして議論するのもありかなぁ。 普通の勉強会みたいなのにするかもしれないし。 とりあえず、どのくらい興味を持ってる人がいるのかがわからないので。。。\nもちろん、Elasticsearch勉強会は別でやっていきますよ。\n","date":1495639453,"dir":"post/2017/","id":"29b4c2b5adcd80ced1612128b3ca95a9","lang":"ja","lastmod":1495639453,"permalink":"https://blog.johtani.info/blog/2017/05/25/search-meetup/","publishdate":"2017-05-25T00:24:13+09:00","summary":"久々のブログ。 Elasticsearch勉強会を主催してますが、 プロダクトを超えて、検索で共通してある課題とか、悩みとか、あるかなぁと。 その","tags":["勉強会"],"title":"検索座談会ってのをやってみた"},{"contents":"今年はRioのプレイバック\u000e見ながら書いてます。 今年はなんか長い一年だった気が。\n振り返り（2015年に書いた抱負から） まずは去年の抱負を元に。\n英語の継続 継続してます。まぁ当たり前ですが。もう少し話す機会増やさないとだなぁと思いつつ。英会話しながら、海外TVドラマ見ながら。 見たドラマはこの辺かな？\nER SUITS メンタリスト Numb3rs エレメンタリー Agent of Shield あと、映画も見てます。とりあえず、耳を慣らすために字幕ありで見てるので、 英語だけでとは行きませんが。。。 そろそろ同じ映画を英語字幕で見るとかしたほうがいいのかもなぁ。\nもっとElasticsearchの開発に参加 一応参加してます。ちょっとずつですが。 イベントが重なるとできなくなるので、小さなPRとかを細々とって感じですが。。。\n人員の倍増？ 倍増したかな？現時点で日本は8名になりました。そのうち1人は完全リモートです。 来年も倍増とは行かないだろうなぁ。取り急ぎ、サポートエンジニアが足りてないのでそこを埋めないと。。。\n日本語情報発信 これはちょっと足踏みしてるかも。ブログの翻訳とかはやってるんですが、もう少しなんとかしないとなぁ。ブログも書かないと。。。\nSplatoon S+? なりました！とりあえずS+とSを行ったり来たりしてる感じです。 メインはノヴァネオですが、Sに落ちたら違う武器でS+に上がるまでチャレンジするってのをやってます。わかば、バケスロソーダ、プライム、ワサビくらいはやったかな？ そろそろまた違う武器かなぁ。S+99は無理そうなんで。。。\n振り返り(今年あったできごと) その他の今年の出来事。\n初香港 初プラハ OSCなど、東京以外でのカンファレンス参加 厄年 東京オフィス！ BBLとかトレーニング lucene-gosenをちょっとメンテ Podcastデビュー？ 初モノ今年も多いかな。 今年は、昨年よりは長く感じた一年でした。 月1くらいで出張してたのもあるのかなぁ？ 香港、プラハはもちろん会社のイベントです。 香港はジャッキーチェンの映画を彷彿とさせるところがちょくちょくあって面白かったです。 ビルとかの補修の足場が竹竿とか。 プラハも面白かったです。やっぱりヨーロッパの古い町は歴史のある建物が多くて楽しいです。\nOSCなどのイベントも色々行きました。福岡、名古屋、大阪、京都、札幌と回りました。 それとは別に大阪、福岡も行ったかな。 来年は沖縄と広島に行きたいなぁ。。。 出張のついで？じゃないですが、御朱印集めし始めました。神社仏閣もいいですよねぇ。\n厄年はきつかった。。。たまたまだとは思うけど、お祓いに行ったのが効いたのかなぁ。後半は特に問題なかったかな。腕時計無くしたと思ったら見つかったりしたし。\n弊社東京オフィスができました。（あんまり行ってないけど） ときどきアクロクエストさんがセミナーを開いたりしてます。 昨年のTour Tokyo後のMeetupでもイベントスペースを使って、Drinkup（勉強会の懇親会だけバージョン）もやりました。 今後もちょこちょことイベントをやってみようかな？\nBBLも始めました。あまりきちんと宣伝してないからそれほど依頼は来てないですが。 あとは、今年も2回日本語でトレーニングしました。 前回はほぼ満席にまでなりました。 来年も頑張りたいかな。ショートカットするためにもいいと思うんで、トレーニングを受けて欲しいんです。。。\nlucene-gosenのメンテもしました。 といってもプログラムではなく、ビルドシステムをAntからGradleに変更したんですが。 来年もちょっとずつ触りたいな。機能面で拡充するかはわからないですが。。。\nPodcastにもデビューさせていただきました。 wyukawaさんのPodcastです。「johtaniさんとElasticsearchについて話しました」楽しかったです。 また出たいなぁというか、喋るの面白かった！\n来年の抱負 もちろん英語の継続 継続的にイベントに登壇 もっと開発＆ブログ サポートエンジニア獲得！ 個人的な検索勉強会の再開 英語はまぁ、当たり前ですね。会社の人つかまえてもっと喋る時間増やさないとだな。\n来年もいろんなカンファレンスなどに出てブース出したり、セッション持ったりして もっともっと広めていかないとなぁ。 あとは、勉強会とMeetupもやっていかないと。入門編と上級編みたいに分けてみるのもありかなぁと考えて見たり。 スピーカー、ご意見募集しております。\n開発に時間をさくための時間の活用をしていかないとなぁと。 どうも時間の使い方がまだ上手くないので。ブログも一緒ですね。。。 月1くらいのペースではかきたいな。。。 ブログもそうだけど書籍もかな？？？？ あと、外資系の他の会社の人ともまた飲みたいなー。\n開発の時間を確保という面ではサポートエンジニアも募集中です。 最近、クライアントが増えて来てチケットが増えて来てるんで、サポートしたりもしてるんです。。。 自分の時間を増やすためにもサポートエンジニアを確保しないと。誰かいい人いないかなぁ。\n個人的にやってた勉強会を忙しいって言って中断してるので、再開しないと。。。\nということで、今年もあと數十分になってしまいました。 今年も色々な方に助けていただけました。お世話になりました。 この場を借りてお礼申し上げます。\n来年もいろんな方々に助けてもらうと思いますが、よろしくお願いいたします。\n","date":1483190534,"dir":"post/2016/","id":"16f1046144ad9ee7bb96214ba7ae7516","lang":"ja","lastmod":1483190534,"permalink":"https://blog.johtani.info/blog/2016/12/31/looking-back-2016/","publishdate":"2016-12-31T22:22:14+09:00","summary":"今年はRioのプレイバック\u000e見ながら書いてます。 今年はなんか長い一年だった気が。 振り返り（2015年に書いた抱負から） まずは去年の抱負を元に","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2016）"},{"contents":"Merry Christmas! Elastic stack Advent Calendar 2016 最終日の記事になります。\n簡単に今年の変遷を振り返ってみます。\nElasticsearch 2.2 (2月) Elasticsearch 2.2.0、2.1.2、1.7.5リリース クエリプロファイラやGeo系の性能改善などが取り込まれました。 また、同時期にリリースされたKibana 4.4ではColor pickerやShare用のURLの短縮化機能なども追加されました。\n第2回目のユーザカンファレンス、Elastic{ON}開催（2月） サンフランシスコで、弊社第2回目のカンファレンスが開催されました。 2015年の会場よりも大きくなり、多数の方に参加いただきました。 ここで、以下の発表がありました。\nElastic StackとX-Packの紹介 これまで、ELK stackと呼ばれて意味明日が、Beatsチームの参加により、ELKだけではなくなったこともあり、Elastic Stackと呼び名を変える事になりました。 また、Marvel、Shield、Watcherなどの商用の拡張機能についても、 単体の名称ではなく、X（Extension）-Packと1つの名前になる事に。 詳細については公式のブログをご覧ください。\nElastic CloudとElastic Cloud Enterpriseの発表 2015年にElasticにジョインし、 これまでFound.no（Found）と呼ばれていた弊社のElasticsearch as a ServiceがElastic Cloudと名称変更しました。 また、Elastic Cloudで培っているノウハウを詰め込んだElastic Cloud Enterpriseも発表しました。実際に利用可能になるまでには まだもう少しかかってしまいますが、アルファ版が公開されていますので、興味のある方は触ってみてください。\nElastic{ON}2016で撮影された、「Elasticsearchがないあなたの人生はどうなりますか？」 といった面白い動画も公開されています。\nElasticsearch 2.3リリース（3月） Elasticsearch 2.3.0および2.2.2をリリース Reindex APIが登場し、Mappingの変更やShard数の変更など、色々とデータの更新などがやりやすくなりました。 また、Task Managementの機能も追加され、長時間かかる処理を間違った場合などの対処が楽になりました。 個人的には、Deprecation Loggingの機能が導入されたことが嬉しいこととなります。次期メジャーバージョンで廃止される機能についてログに出力されるようになりました。 実際に運用されているアプリで利用している機能が今後なくなるかどうかをログを見るとわかるという仕組みです。\nRally登場（4月） Rally登場：Elasticsearchのベンチマークツール Elasticsearchのベンチマークツールがリリースされました。 定期的にElasticsearchの性能を計測することは問題点を見つける事に役に立ちます。そういった手助けをしてくれるツールが公開されることは非常に便利なことかと。\nElastic Stack 5 alpha1 リリース（4月） Elastic Stack 5.0.0 alpha 1 リリース Ingest NodeやLucene 6、新しいKibanaのUIなど多くのものが詰まっていました。ここから多くのユーザにテストしてもらい、5.0の正式リリースを迎えることができました。\nElasticsearch 2.4.0リリース（8月） 2.xの最後のマイナーバージョンリリースです。 Reportingなどの追加とドットつきフィールド名の復活がありました。\nElastic Stack 5.0.0 beta1 リリース（9月） Elastic Stack Release - 5.0.0-beta1 ついにベータです。Painlessがスクリプトのデフォルトになったり、TimelionがKibanaに取り込まれるなど、正式リリースまであと少し！\nPrelertチームジョイン（9月） Welcome Prelert to the Elastic Team Machine Learningエンジンを開発し、Elasticsearch,Kibanaとの組み合わせの製品をリリースしていたPrelertという会社がジョインしました。 Elasticsearchに保存された多くのデータをより活用していただくことができるかと思います。 Elastic{ON} Tour 2016 Tokyoで弊社SAの大輪の発表も人気があるものでした。まだベータ段階ですが、利用して見ることも可能です。 ビデオなどが公開されたらまたツイートしようと思います。\nElastic{ON} Tour Tokyo 2016開催（12月） 今年で2回目のTokyoローカルの1日イベントでした。 ブログは「まだ」書いてませんが、、、今回も盛りだくさんのイベントになりました。 早朝のトレーニング（ハンズオンではない）にも80名近くの方に参加していただけましたし、私はKibanaのキーノート＋デモという大役をもらいましたし、ちょっと大変でした。 今年もAMA（Ask Me Anything）ブースが大盛況でした。 色々な方から、弊社のサポート、開発者が色々な質問を受け、それに答えるという形です。楽しんでいただけたかと思います。 来年もぜひ開催したいなと思っています。\nまた、Elastic{ON}17のセッションもいくつか発表されています。 ぜひ、サンフランシスコで行われる本場のカンファレンスにもご参加ください！\n来年は？ 1月後半か2月にElasticsearch勉強会を検討しようと思っています。スピーカーに興味のある方は連絡いただければと。\n会社としては、Elastic{ON}2017が3月にまた開催されます。これで3回目となります。もちろん私も参加予定なので、参加される方は、現地で会いましょう！\nそのほかにもBIG DATA ANALYTICS TOKYOやオープンソースカンファレンス（大阪）、デブサミといったカンファレンスに参加（登壇・ブースなど）予定です。 参加される方は、ぜひブースまでお越しください。\nでは、また来年のAdvent Calendarでお会いしましょう！\n","date":1482591830,"dir":"post/2016/","id":"002d980d74d19b43ff4e2446665e2fe5","lang":"ja","lastmod":1482591830,"permalink":"https://blog.johtani.info/blog/2016/12/25/elasticsearch-6-features/","publishdate":"2016-12-25T00:03:50+09:00","summary":"Merry Christmas! Elastic stack Advent Calendar 2016 最終日の記事になります。 簡単に今年の変遷を振り返ってみます。 Elasticsearch 2.2 (2月) Elasticsearch 2.2.0、2.1.2、1.7.5リリース クエリプロ","tags":["elasticsearch"],"title":"2016年のElastic Stack"},{"contents":"Elastic stack Advent Calendar 1日目の記事になります。\nElasticsearch 5.0が10月末にリリースされました。 リリースのブログでいくつか紹介されているのですが、そこでは紹介されていない機能について2、3紹介しようと思います。\nその前に、5.0、あれ？その前は2.xじゃなかったっけ？？と困惑されている方もいるかと思うので、簡単に5となった経緯の紹介をしようかと。\nバージョン番号 なぜ2から5に飛んだのかという話ですが、このスライドがその紹介になっています。\nhttps://speakerdeck.com/johtani/elastic-stack-5-dot-0-alpha1-alpha5?slide=5\nElastic{ON} 2016のキーノートでも紹介がありましたが、KibanaやLogstashとElasticsearchを組み合わせて使うときにバージョンのミスマッチで動かないというユーザの声が上がっていました。 2.xのリリースから、同じ日にKibana、Logstash、Beatsもリリースするようになったのですが、 やはり、バージョン番号が異なるため、ミスマッチで動かないというユーザが時々いました。\nElastic Stackという名称にもなったため、バージョン番号をそろえようという事になり、 Elasticsearch、Kibana、Logstash、Beats全てが5.0.0としてリリースされ、 今後は同じバージョン番号になります。\nちなみに、「5」になった理由はKibanaのメジャーバージョンが「4」だったためです。\nさて、では、いくつか機能の紹介を。\nReindex from remote cluster Reindexが2.3から導入されました。データの再登録ができるようになり、マッピングの変更や Shardの数の変更などが柔軟に行えるようになりました。 便利でしたが、あくまでも同一のクラスタでデータを登録し直す形でした。\n5.0からはこの機能に加えて、異なるクラスタからデータを取得してReindexを行うことができるようになりました。 こんな形になります。\nPOST _reindex { \u0026#34;source\u0026#34;: { \u0026#34;remote\u0026#34;: { \u0026#34;host\u0026#34;: \u0026#34;http://otherhost:9200\u0026#34;, \u0026#34;username\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;password\u0026#34;: \u0026#34;pass\u0026#34; }, \u0026#34;index\u0026#34;: \u0026#34;source\u0026#34;, \u0026#34;query\u0026#34;: { \u0026#34;match\u0026#34;: { \u0026#34;test\u0026#34;: \u0026#34;data\u0026#34; } } }, \u0026#34;dest\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;dest\u0026#34; } } usernameとpasswordはリモートのクラスタに認証の気候が存在する場合に利用できるオプションです。 また、ReindexのAPIはクエリを使用して、必要なデータだけを取得することが可能です。 この機能により、1.xや2.xのクラスタからデータを移行することが可能になります。\nCustom analyzer test using Analyze API もう一つ、ちょっとだけ便利な機能を紹介します。 独自にAnalyzerを定義（TokenizerとToken Filterなどを個別に設定）して、その挙動を確認するとき、2.xまでは、インデックスを作成してそのインデックスに対して_analyze APIを呼び出す必要がありました。\n5.xからは_analyze APIの読み出しのパラメータで指定できるようになりました。 こんな感じです。ここでは、lowercaseフィルタのあとに、{...}でstopフィルタを パラメータの中で、指定しています。\ncurl -XGET \u0026#39;localhost:9200/_analyze\u0026#39; -d \u0026#39; { \u0026#34;tokenizer\u0026#34; : \u0026#34;whitespace\u0026#34;, \u0026#34;filter\u0026#34; : [\u0026#34;lowercase\u0026#34;, {\u0026#34;type\u0026#34;: \u0026#34;stop\u0026#34;, \u0026#34;stopwords\u0026#34;: [\u0026#34;a\u0026#34;, \u0026#34;is\u0026#34;, \u0026#34;this\u0026#34;]}], \u0026#34;text\u0026#34; : \u0026#34;this is a test\u0026#34; }\u0026#39; ちょっとだけですが、Analyzerなどを試すのが楽になるのではないでしょうか？\nということで、以上が1日目の記事でした。 Logstashなど、他の5.0.0に関する記事もAdvent Calendarに空きがあるようなので、個別にかこうかなと思います。お楽しみに！\n","date":1480581270,"dir":"post/2016/","id":"550becdd08d00fb1e7fd00c2adc3d3d6","lang":"ja","lastmod":1480581270,"permalink":"https://blog.johtani.info/blog/2016/12/01/elasticsearch-5-dot-0-highlight/","publishdate":"2016-12-01T17:34:30+09:00","summary":"Elastic stack Advent Calendar 1日目の記事になります。 Elasticsearch 5.0が10月末にリリースされました。 リリースのブログでいくつか紹介されているのですが、そこでは紹介されて","tags":["elasticsearch"],"title":"Elasticsearch 5.0の便利機能紹介？"},{"contents":"久しぶりに、技術的なブログ書いてます。\nIngest Processorのプラグインを作ってみたくなったので、書いてみました。 ただ書いてみるんじゃ3番煎じになりそうなので、cookiecutterを使ってみました。\nと言っても、同僚のAlexがcookiecutter-elasticsearch-ingest-processorと言うテンプレートを作ってくれているのを使っただけですが。（https://discuss.elastic.co に投稿された記事で、使い方がアニメgifで説明されててわかりやすいです）\ncookiecutterとは、コマンドラインで質問に答えると、テンプレートからプロジェクトが生成できるツールです。 Elasticでは、カスタムBeatを作る時に利用する例がいつかの日本語ブログや発表資料で話題になっていました。 これのIngest Processorのプラグインバージョンです。\n今回は、NEologdも使ってみたかったので、Lucene Kuromoji for NEologdを利用して 指定した品詞の単語だけを抽出するProcessorを作ってみました。\nGitHubのプロジェクト：https://github.com/johtani/elasticsearch-ingest-kuromoji-pos-extract\nCookiecutterの使い方 Cookiecutterのインストールはサイトをご覧ください。\ncookiecutter gh:spinscale/cookiecutter-elasticsearch-ingest-processor あとは、出てくる以下の項目を指定するだけです。\nprocessor_type : Ingest Processorのタイプ名です。kuromoji_part_of_speech_extractとしました。（Alexのだと_を使うとちょっと問題があるので後述） description : readme.mdに利用されます。 developer_name : 名前を記載。Javaのファイルのヘッダに利用 elasticsearch_version : デフォルトで5.0.0-alpha4が指定されているので、特に指定せず 以上の質問に答えたら、プロジェクトのディレクトリ構造が出来上がってます。 プロジェクトのビルドなどにはGradleを利用します。\nプロジェクトのIntelliJ IDEA用のファイルを生成 build.gradleファイルでGradleのideaプラグインがapplyされているので、以下のコマンドを叩けばIntelliJ IDEAのプロジェクトファイル（？）が生成され、IntelliJで開けばすぐに開発ができる状態にできます。\ngradle idea コーディング あとは、必要処理をコーディングします。 実際にコーディングするクラスはorg.elasticsearch.plugin.ingest.kuromoji_part_of_speech_extractのパッケージにある以下の2つです。（パッケージ名にはprocessor_typeの名前が指定されている）\nIngestKuromojiPartOfSpeechExtractPlugin KuromojiPartOfSpeechExtractProcessor IngestKuromojiPartOfSpeechExtractPlugin Pluginというクラスは、プラグインをNodeのModuleとして登録する処理を書くクラスとなります。 生成してすぐは、次のような形になっています。（※importやクラス定義の部分は省略しています。）\n... public static final Setting\u0026lt;String\u0026gt; YOUR_SETTING = new Setting\u0026lt;\u0026gt;(\u0026#34;ingest.kuromoji_part_of_speech_extract.setting\u0026#34;, \u0026#34;foo\u0026#34;, (value) -\u0026gt; value, Setting.Property.NodeScope); @Override public List\u0026lt;Setting\u0026lt;?\u0026gt;\u0026gt; getSettings() { return Arrays.asList(YOUR_SETTING); } public void onModule(NodeModule nodeModule) throws IOException { nodeModule.registerProcessor(KuromojiPartOfSpeechExtractProcessor.TYPE, (registry) -\u0026gt; new KuromojiPartOfSpeechExtractProcessor.Factory()); } ... YOUR_SETTINGプロパティとgetSettings()メソッドはelasticsearch.ymlで指定したい設定を記述する場合の例になります。今回は特に必要ないので両方削除しました。 最終系はGitHubのコードをご覧ください。\nKuromojiPartOfSpeechExtractProcessor Processorは実際にIngest Nodeで行う処理を書くところです。\npublic static final String TYPE = \u0026#34;kuromoji_part_of_speech_extract\u0026#34;; private final String field; private final String targetField; public KuromojiPartOfSpeechExtractProcessor(String tag, String field, String targetField) throws IOException { super(tag); this.field = field; this.targetField = targetField; } @Override public void execute(IngestDocument ingestDocument) throws Exception { String content = ingestDocument.getFieldValue(field, String.class); // TODO implement me! ingestDocument.setFieldValue(targetField, content); } @Override public String getType() { return TYPE; } public static final class Factory extends AbstractProcessorFactory\u0026lt;KuromojiPartOfSpeechExtractProcessor\u0026gt; { @Override public KuromojiPartOfSpeechExtractProcessor doCreate(String processorTag, Map\u0026lt;String, Object\u0026gt; config) throws Exception { String field = readStringProperty(TYPE, processorTag, config, \u0026#34;field\u0026#34;); String targetField = readStringProperty(TYPE, processorTag, config, \u0026#34;target_field\u0026#34;, \u0026#34;default_field_name\u0026#34;); return new KuromojiPartOfSpeechExtractProcessor(processorTag, field, targetField); } } TYPEがIngest APIのPipelineでProcessorを指定するときに使う名前になります。ここは、cookiecutterの時にprocessor_typeに入力した文字列になっています。 kuromoji_part_of_speech_extractだと長いので、kuromoji_pos_extractに変えました。\nexecute()メソッドに// TODO implement me!とあります。 この部分に実際の処理を記述していきます。\nあとは、FactoryクラスでIngest APIで指定された設定項目を読み込みます。 今回作成したelasticsearch-ingest-kuromoji-pos-extractでは品詞を指定する必要があるので、pos_tagsを指定できるように処理を追加しました。\n私が実装したものの説明をするとちょっと長くなりそうなので、GitHubのコードをご覧ください。\nテストのコーディング テストのクラスもテンプレートで生成されています。\nKuromojiPartOfSpeechExtractProcessorTests KuromojiPartOfSpeechExtractRestIT KuromojiPartOfSpeechExtractProcessorTests Processorクラスのテストになります。生成直後は次のような感じです。\npublic void testThatProcessorWorks() throws Exception { Map\u0026lt;String, Object\u0026gt; document = new HashMap\u0026lt;\u0026gt;(); document.put(\u0026#34;source_field\u0026#34;, \u0026#34;fancy source field content\u0026#34;); IngestDocument ingestDocument = RandomDocumentPicks.randomIngestDocument(random(), document); KuromojiPartOfSpeechExtractProcessor processor = new KuromojiPartOfSpeechExtractProcessor(randomAsciiOfLength(10), \u0026#34;source_field\u0026#34;, \u0026#34;target_field\u0026#34;); processor.execute(ingestDocument); Map\u0026lt;String, Object\u0026gt; data = ingestDocument.getSourceAndMetadata(); assertThat(data, hasKey(\u0026#34;target_field\u0026#34;)); assertThat(data.get(\u0026#34;target_field\u0026#34;), is(\u0026#34;fancy source field content\u0026#34;)); // TODO add fancy assertions here } テストメソッドも実装されていますが、パラメータの追加の設定処理やアサーションが書かれてません。 実装に合わせて、アサーションや設定処理を追加しましょう。\nKuromojiPartOfSpeechExtractRestIT こちらはIntegration Testになります。 実際にElasticsearchに対して外部からAPIを叩くような感じです。 APIを叩くときに利用するJSONの設定やアサーションはsrc/test/resourcesにyamlファイルがあります。\n10_basic.yaml 20_kuromoji_part_of_speech_extract_processor.yaml 10_basic.yamlはプラグインがインストールされているかの確認のテストです。特に変更する必要はないです。\n20_kuromoji_part_of_speech_extract_processor.yamlは実際にコーディングしたProcessorが動くかどうかのテストです。\nテストの内容については、GitHubのコードをご覧ください。\nテストの実行とZipの生成 テストの実行とZipの生成は次のコマンドを実行すればOKです。\ngradle check テストに問題があった場合は、コケますし、問題なければSUCCESSと表示が出ます。 成功した場合はbuild/distributions/というディレクトリにzipファイルができています。 これをElasticsearchのpluginコマンドでインストールすれば動きます。\nbin/plugin install file:///path/to/elasticsearch-ingest-kuromoji-pos-extract/build/distribution/ingest-kuromoji_part_of_speech_extract-0.0.1-SNAPSHOT.zip kuromoji_pos_extractの利用方法 Ingest APIには便利なSimulate Pipeline APIがあります。\nということで、mecab-ipadic-NEologdにあったサンプルの文章を使って、使い方の説明です。\nPOST _ingest/pipeline/_simulate { \u0026#34;pipeline\u0026#34; : { \u0026#34;description\u0026#34; : \u0026#34;kuromoji neologd extract test\u0026#34;, \u0026#34;processors\u0026#34; : [ { \u0026#34;kuromoji_pos_extract\u0026#34; : { \u0026#34;field\u0026#34; : \u0026#34;body\u0026#34;, \u0026#34;target_field\u0026#34; : \u0026#34;noun_field\u0026#34;, \u0026#34;pos_tags\u0026#34; : [ \u0026#34;名詞-固有名詞-組織\u0026#34;, \u0026#34;名詞-固有名詞-一般\u0026#34;, \u0026#34;名詞-固有名詞-人名-一般\u0026#34;, \u0026#34;名詞-固有名詞-地域-一般\u0026#34;, \u0026#34;名詞-固有名詞-地域-国\u0026#34; ] } } ] }, \u0026#34;docs\u0026#34; : [ { \u0026#34;_index\u0026#34;: \u0026#34;index\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;type\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;id\u0026#34;, \u0026#34;_source\u0026#34;: { \u0026#34;body\u0026#34; : \u0026#34;10日放送の「中居正広のミになる図書館」（テレビ朝日系）で、SMAPの中居正広が、篠原信一の過去の勘違いを明かす一幕があった。\u0026#34; } } ] } 結果はこちら。\n{ \u0026#34;docs\u0026#34;: [ { \u0026#34;doc\u0026#34;: { \u0026#34;_index\u0026#34;: \u0026#34;index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;id\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;type\u0026#34;, \u0026#34;_source\u0026#34;: { \u0026#34;noun_field\u0026#34;: [ \u0026#34;10日\u0026#34;, \u0026#34;中居正広のミになる図書館\u0026#34;, \u0026#34;テレビ朝日\u0026#34;, \u0026#34;SMAP\u0026#34;, \u0026#34;中居正広\u0026#34;, \u0026#34;篠原信一\u0026#34; ], \u0026#34;body\u0026#34;: \u0026#34;10日放送の「中居正広のミになる図書館」（テレビ朝日系）で、SMAPの中居正広が、篠原信一の過去の勘違いを明かす一幕があった。\u0026#34; }, \u0026#34;_ingest\u0026#34;: { \u0026#34;timestamp\u0026#34;: \u0026#34;2016-07-22T06:18:49.007+0000\u0026#34; } } } ] } noun_fieldに固有名詞の単語が抜き出せているのがわかるかと思います。\nAlexのテンプレートで困った点 テンプレートは便利だったのですが、processor_typeに_を使用したタイプ名を指定すると次のような問題（？）が発生しました。\nクラス名がKuromoji_part_of_speech_extractProcessorとなってしまう 深刻な問題ではないのですが、JavaだとCamel Caseが普通なのでちょっと気になって。 ということで、プルリク作って出してみました。まだ取り込まれてないかな。\n取り込み前に使いたい方は以下のコマンドを実行してください。 processor_class_nameという項目が増えています。 デフォルトだとprocessor_typeの_の部分を取り除きつつCamel Caseにしたものが入ります。\ncookiecutter gh:johtani/cookiecutter-elasticsearch-ingest-processor まとめ ということで、とりあえず作ってみましたというものになります。 特徴的な単語（固有名詞だけ）を抜き出して、別のフィールドにできるので、タグみたいなものをこれを使って前処理で作れるようになるかなぁと。\n参考ブログ（元ネタ？） インスパイア元となったブログです。\nUser Agentを解析するIngest Pluginを書いてみた Elasticsearch 5.0.0のIngest Node用プラグインを書いた話 ","date":1469161616,"dir":"post/2016/","id":"a62186ea292d6db03a087bd5dfcc3f1e","lang":"ja","lastmod":1469161616,"permalink":"https://blog.johtani.info/blog/2016/07/22/making-ingest-processor-plugin-with-cookiecutter/","publishdate":"2016-07-22T13:26:56+09:00","summary":"久しぶりに、技術的なブログ書いてます。 Ingest Processorのプラグインを作ってみたくなったので、書いてみました。 ただ書いてみるんじゃ3番煎じ","tags":["elasticsearch","plugin"],"title":"Lucene Kuromoji for NEologdで指定した品詞の単語を抜き出すIngest Pluginを書いてみた #elasticsearchjp"},{"contents":"なんか、今年はよく物が壊れる、厄年だからかなぁ？\nということで、記念に何が壊れたかをブログに残しておこうかと。\n腕時計（壊れてないかな） 電波腕時計を使ってたんだけど、電池がへたってたのでオーバーホールしてもらった。 Moto 360（壊れたというか。。。） 何度かバージョンアップしてるんだけど、数ヶ月前から、ちょっと触っただけで電源が落ちる現象が。ファームウェアのせいかAndroid Wearのバージョンアップのせいかわからないけど。。。挙げ句の果てに、電源を入れるために充電器にセットしないといけないと言う酷い仕様。。。 自転車前輪 自転車で車道を横切る側溝の蓋の間に前輪がはまってすっ転んでしまい、タイヤのスポークがちょっと曲がってしまう ジーンズその1 自転車で転んだ時に、膝とかこすって破れる ジーンズその2 福岡出張中に雨で滑って派手に転んで、膝に大きな穴が。。。 リュック あー、怪しいなと思ってたんだけど、やっぱりこわれた、、、 pic.twitter.com/CD2Y7t6AOD\n\u0026mdash; Jun Ohtani (@johtani) 2016年6月16日 怪しいとは思ってたんだけど。。。 ということで、リュックを新調しつつ修理に出してるところ。 5. Xperia Z3 * 先週金曜日にカメラのレンズが結露してるなぁと思ったら、電源が入らなくなった。補償サービスに入ってたんで、新しいZ3を次の日に送付してもらい復旧。いろいろなアプリがログインしないといけないのでかなり大変だった。。。\nまだ、半年残ってるので他にも壊れるのかなぁ。。。 お祓いしてもらったので、何もなければいいんだけど。\nということで、なんとなく欲しいものリストを貼っておきますね。\n","date":1467251858,"dir":"post/2016/","id":"167e2a6833d49ce198cb3b88f521991e","lang":"ja","lastmod":1467251858,"permalink":"https://blog.johtani.info/blog/2016/06/30/broken-something-in-this-year/","publishdate":"2016-06-30T10:57:38+09:00","summary":"なんか、今年はよく物が壊れる、厄年だからかなぁ？ ということで、記念に何が壊れたかをブログに残しておこうかと。 腕時計（壊れてないかな） 電波腕時","tags":["misc"],"title":"よく物が壊れる年"},{"contents":"第16回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 今回は、司会だけに注力してみました（）。\nチェックイン数など チェックインした人：141名 キャンセルしなかった人：67名 でした。\n今回は、参加希望者が多くて、当日にも100名近いキャンセル待ちの方がいたので、 240名まで、参加者枠を増枠（会場キャパ190名程度）して対応しました。 まぁ、読み通り、1/3の方はキャンセルしない形でした。 天気も良く電車の遅延などもなさそうだったので、ちょっとドキドキしてたのですが。\n以下は簡単なメモです。\n「LogstashとElasticsearchで作るEnterprise Search Platform」/ Elastic Kosho Owa スライド：https://speakerdeck.com/kosho/enabling-enterprise-search-platform-with-elastic-stack\n使ってるLogstashの設定ファイルを elastic-japan at elastic dot co に送るとTシャツがもらえるらしい。 Logstashのfilter-rubyはここで、evalしてcallしてるから、特にforkとかしてないかと。 「企業・業界情報プラットフォームSPEEDAにおけるElasticsearchの活用」 / 株式会社ユーザベース 北内 啓さん スライド：http://www.slideshare.net/tau3000/speedaelasticsearch-63510388\nアルゴリズム関連の開発担当 企業データをいろんな軸で検索したい データ数が約70億レコードになりそう（通貨 x MySQL） 300万企業データ＋Nestedとかで持ってる。 11万フィールド？？？ 10台の物理サーバに24仮想マシン 企業名の検索 recall重視 NewsPicksの検索機能 「日本 化粧品 売上高」業界のデータとかも観れるのかな？有料会員向け機能 登録済みキーワードかどうかをRDB＋Esに検索して、ID化するっぽい ID（Analyze必要ない）検索だから、termクエリだった、サンプルが。 ノードの役割分担 更新はMasterNode経由でDataNodeへ。 検索はClientNode経由でDataNodeへ。 1.xかぁ。。。 「Elasticsearchベースの全文検索システムFess」 / 株式会社エヌツーエスエム 菅谷信介さん スライド：http://www.slideshare.net/shinsuke/elasticsearchfess\n10.xからSolrをやめてElasticsearchへ。 日本語検索 bigram＋形態素（1文字検索とかに対応するため） NeologDに対応したkuromojiを利用 DBFluteをESFluteとしてEs対応 KOPFを組み込んで使ってる configをREST API経由で更新できるプラグインあり LT 「ElasticsearchとGCPのネットワークでハマった話」 株式会社サイバーエージェント 平田大地 さん @daichild スライド：https://speakerdeck.com/daic_h/gcpfalsenetutowakudehamatutahua\nhhkb2 2刀流！ networkのKeep-alive周りで困ったよというお話。 後で聞いたけど、GCE Cloud Pluginは使ってるそうです。 06/28 17:00追記\nPingを定期的に実行させることで回避も出来るようです。 transport.ping_scheduleに時間を指定します。通常のNode（Transport以外）は\u0026rsquo;-1\u0026rsquo;が指定してあり、動作してません。 「スクリプトフィールドで作るランキングみたいな何か」iwag さん スライド：https://speakerdeck.com/iwag/elasticsearch-dezuo-rurankingu\n1.xかぁ。。。 あとは、function_scoreとかも面白いですよ！ その他、感想などのブログ 第16回elasticsearch勉強会に参加してきた 第16回Elasticsearch勉強会に参加してきた まとめ＋宣伝？ 1.xがまだまだいますねぇ、早く2.xにアップしましょう！（5.0ももう直ぐだし）。懇親会でも色々と話しましたが、https://discuss.elastic.co というフォーラムあるので、ぜひ活用してください。\n次回は8月末か9月頭かでしょうか。 7月末にOSC京都に出没するので、京都で勉強会やりたいと思ってます！ 会場とかスピーカーとか興味ある人連絡ください。\n東京の勉強会のスピーカーも随時募集中ですので、連絡ください。\n","date":1467089755,"dir":"post/2016/","id":"993e58f132740b464ecf06ee289dc7b2","lang":"ja","lastmod":1467089755,"permalink":"https://blog.johtani.info/blog/2016/06/28/16th-elasticsearch-meetup/","publishdate":"2016-06-28T13:55:55+09:00","summary":"第16回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第16回Elasticsearch勉強会を開催しました。 #elasticsearchjp"},{"contents":"第15回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 今回は、Elastic{on} 2016開催直後ということで、大半はElastic{on}に関する話でした。\nチェックイン数など チェックインした人：114名 キャンセルしなかった人：62名 でした。 今回は、少しおそめで1時間前にキャンセル待ちがいない状態にしました。 まぁ、いつもの感じでしょうか。数値も安定してきた感じですかね。\n\u0026ldquo;Elasticsearchと機械学習を実際に連携させる\u0026rdquo; / Preferred Networks America, Inc. CTO 久保田展行(Kubota Nobuyuki) さん スライド：Elasticsearchと機械学習を実際に連携させる\n前回の続きの話で、今回が本題でした。\n勉強会直前に発表されたSensorBeeをElasticsearchと一緒に使うとどんなことができるかというお話です。 まぁ、前処理重要ですよねというのが、いつものことですが、印象的でした。 いつものようにわかりやすい説明だったので、使ってブログを書いて欲しいなと。\n発表の中で、説明に出てきたデモとか。\nCES2016でロボットカーのデモを展示してきました \u0026ldquo;Elastic{ON} 2016レポート\u0026rdquo; / Elastic Jun Ohtani スライド：elastic{on} 2016 レポート\n写真多めで、キーノートをメインに話をしました。\n簡単なまとめとしては\nプロダクトロゴができました。ロゴ画像などはこちら 次のメインバージョンは全て5.0。（5.0に関する通知が欲しい人はこちらで登録できます） elastic{on} 2016のビデオなどはこちら BBL始めます。連絡ください \u0026ldquo;Elastic{ON}の過ごし方\u0026rdquo; / クラスメソッド株式会社 藤本 真司 さん スライド：Elastic{ON}の過ごし方\n印象に残ったのは\n「自他共に認めるブログの会社」 4/12にSAPさんに会場を借りてElastic＆クラスメソッドでイベントやります。 やっぱりご飯が美味しいんですねぇ。 早速ブログが書かれてました。\n\u0026ldquo;Elastic{ON} 2016 見るべきセッション資料 7選\u0026rdquo; / Acroquest Technology株式会社 谷本 心 さん スライド：Elastic{ON} 2016 見るべきセッション資料 7選 #elasticsearchjp\n印象に残ったのは\n東京でハンズオンやる会場提供者募集中！ Ingest Node（参考：Ingest Nodeのドキュメントは公開中。） Reindex API（参考：Backport reindex to 2.x ） その他、感想などのブログ 第15回elasticsearch勉強会にLTで登壇しました #elasticsearch #elasticsearchjp 第15回elasticsearch勉強会に参加してきました #elasticsearch #elasticsearchjp まとめ＋宣伝 来年のElastic{ON}に参加したいと思っていただけたらよかったなと。\n4/12にクラスメソッドさんとイベントを行います。また、ツイートすると思います。\n次回はいつも通りだと5月中旬になるかと思います（大丈夫かな？OSC 2016 Nagoyaでしゃべったり、ブース出したりとかするけど）。 5末に名古屋に出没します。名古屋で勉強会できればやりたいと思ってます。会場とかスピーカーとか興味がある方は連絡ください。\n","date":1458186180,"dir":"post/2016/","id":"c56a76ef8f604a8d87be2a32b1f81fac","lang":"ja","lastmod":1458186180,"permalink":"https://blog.johtani.info/blog/2016/03/17/15th-elasticsearch-jp/","publishdate":"2016-03-17T12:43:00+09:00","summary":"第15回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第15回Elasticsearch勉強会を開催しました。 #elasticsearchjp"},{"contents":"久々のポスト。。。\n久々に、技術書読んでます。「自然言語処理の基本と技術」という本です。\n監修の方のツイートを見て気になったので、買ってみました。 書籍のサイトの説明はこんな感じでした。\n本書は、この未来に不可欠となるに違いない自然言語処理の、技術的、ビジネス的基礎知識をくまなくコンパクトに図解した一冊です。 著者陣もそれぞれの分野の第一線で活躍するエキスパート揃い！\n確かに著者陣がすごいです。\nまだ、「はじめに」と自分に関係のある「情報検索」の章を流し読みしただけなんですが、次のような特徴がある本です。\n平易な単語で説明してある（難しい専門用語が少ない） 数式が出てこない（多分。少なくとも読んだ部分では見てない） 説明には例と図解がある 情報検索の章で言うと、全文検索でよく使われる転置インデックス（索引という単語が使われてる）がなぜ必要なのか、どういう感じで作られるのか、 転置インデックスに利用する索引の単語をどうやって作るのか（文字N-Gramや形態素解析）、単語の正規化（ステミングやストップワード）などの説明が 本当にわかりやすく書かれています。 スコアリングについても触れられています。\nElasticsearchも転置インデックスを用いた検索を行っており、 MappingでAnalyzerの指定をしている理由などの理解に役に立つと思います。\n全文検索システムがどのように検索を処理しているかをざっくり理解するのにはもってこいじゃないかと。 1点残念だなと思ったのは、書籍に「索引」がありませんでした（本の索引を思い浮かべてくださいっていう説明あったんだけど）。。。 Kindle版を購入すれば「検索」できるのかな？\nということで、まだ、流し読みしただけなんですが、「すごく」オススメです。 購入はこちらから！\n","date":1457962452,"dir":"post/2016/","id":"3fc7462a83fa55885067fee629287e8a","lang":"ja","lastmod":1457962452,"permalink":"https://blog.johtani.info/blog/2016/03/14/review-basics-and-tech-of-nlp/","publishdate":"2016-03-14T22:34:12+09:00","summary":"久々のポスト。。。 久々に、技術書読んでます。「自然言語処理の基本と技術」という本です。 監修の方のツイートを見て気になったので、買ってみました","tags":["本"],"title":"「自然言語処理の基本と技術」を読んでる"},{"contents":"あけましておめでとうございます、johtaniです。\n第14回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 今年もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\nチェックイン数など チェックインした人：122名 キャンセルしなかった人：58名 でした。 今回も当日の昼の時点でキャンセル待ちがない状態にしていました。 いくつか電車が止まっていたという話を聞いていたので、開始を5分遅らせ、 受付は45分くらいまで開けておくという対応をしてもらいました。\n\u0026ldquo;ココが辛いよelasticsearch\u0026rdquo; / 株式会社リクルートテクノロジー @tatakaba さん スライド：ココが辛いよelasticsearch\n実際にいくつかのサービスで運用されている内容とどういった機能を利用しているか、 どういったものを独自に作っているかという話をしていただきました。\n独自PluginでA/Bテストしてる Snapshotの活用 Index作成は環境に合わせて行っている。 バージョンは混在 PusnaRSのバージョンアップの話。 2つのバージョンのクラスタを用意してリアルタイムに切り替え。 Elasticsearchの活用 QueryのRewrite： SolrのリクエストをEsで受け付けたり。 辛い話。 バージョンアップが辛い Riverなくなるのつらい データずれるのつらい 補足：\nバージョンアップについて 1.x系から2.x系にアップされるのであれば、こちらを必ず試してください。\nhttps://github.com/elastic/elasticsearch-migration\n「.」が使えなくなるという話は、Solrとの大きな違いになるのかもなぁと。 ネスト構造のデータの表記を「.」で行うというのを厳密に行えるように、 「.」を使えなくしたというのがあるかと。\nRiverについて Riverがなくなった理由については、https://www.elastic.co/blog/deprecating-rivers で記載があります。 便利なのですが、負荷が偏ったり、スケールしないとかいう問題点があるかなと。\n良いサンプルとしては、JDBC Riverなどは、Javaのプログラムとして起動できるように変更されていたりします。\nhttps://github.com/jprante/elasticsearch-jdbc/wiki/jdbc-plugin-feeder-mode-as-an-alternative-to-the-deprecated-elasticsearch-river-api\n（個人的 には、SolrのDIHもRiverもあんまり好きではなかったです。データの変換処理と、ロード処理は別々にしたい人だったので。）\nデータのズレなど 耐障害性とか信頼性に関しては、どういった問題点があるのか、どういった対応をしているのかというのがまとめられたページが用意されています。\nhttps://www.elastic.co/guide/en/elasticsearch/resiliency/current/index.html\n「機械学習を利用したちょっとリッチな検索」 / Preferred Networks America, Inc. CTO 久保田展行(Kubota Nobuyuki) さん スライド：機械学習を利用したちょっとリッチな検索\n来日していただき、機械学習と検索の話をしてもらいました。 本編は次回の発表かもw\n機械学習を元に、検索対象の情報を元の情報から増やしてあげる。 増えた情報を検索できるようにする 今日のゴール： 機械学習とはどういうものか？ データの集め方とか、アノテーションとか 学習の方法（ツールやライブラリに依存） Esでの活用方法 オフラインで学習させて、情報を付与した後に、Elasticsearchに入れる Jubatus＋fluentdで ChainerサポートのOSSのツールを公開予定 「ここからが本当の地獄だ。。。」ってのが聴きたいw\n「Lucene Query 再考 - Domain Specific Query 実装 -」 / Supership株式会社 インフラ事業開発本部検索グループ 大川真吾 さん スライド：Lucene Query 再考 - Domain Specific Query 実装 -\nLuceneのクエリに関する話と、クエリパーサーに関する話でした。 こういった濃い話も勉強会でしてもらえると、色々な参加者に楽しんでいただけるかなぁと。 次回も続きを話してもらう予定です。\n補足：\n参考までにですが、Elasticsearchに入門したての人向けに、 Analyzerとか転置インデックスとかの話をした時のスライドになります。 https://speakerdeck.com/johtani/lucenetori-ben-yu-falsejian-suo\nLT: Fluentd meets Beats / @repeatedly さん スライド：http://www.slideshare.net/repeatedly/fluentpluginbeats-at-elasticsearch-meetup-14\n参考Qiita：http://qiita.com/repeatedly/items/77af41788f0b3ccdefd2\nBeatsの説明をTDの人からしてもらうなどw FluentdにBeatsからのデータを流し込めるようにしたプラグインが出たという話でした。\nfilebeatの性能の件は社内で聞いてみようかと。\nElasticsearchインデクシングのパフォーマンスを測ってみた / 日本IBM　黒澤亮二さん スライド：Elasticsearchインデクシングのパフォーマンスを測ってみた\n参考Qiita：http://qiita.com/rjkuro/items/e79eec7ffb0511b7c678\n細かな性能測定の結果を駆け足で話してもらいました。 皆さんもこの指標をもとに、手元の環境を計測してみたりしてみてもらえればと。\nあとは、2.x系になってるので、同じ方法で計測してもらってまた 発表してもらえると嬉しいなー（棒）\nその他、感想などのブログ Elasticsearch勉強会　第14回フィードバック まとめ＋宣伝 久々に（初めてかな？）、ゲストがいないのに自分が喋りませんでした。 次回は3月中旬を予定してます。 次回は、Elastic{ON}16の報告をする予定です。いろいろと発表あるだろうし。\nあと、今月末の1/29にオープンソースカンファレンス 2016.enterprise@Osakaにブース出展します。 セミナー枠でも弊社OSSプロダクトの概要を話しする予定です。 関西の方は、ぜひ参加していただければと。ブースでお待ちしております。\nまた、スピーカーや場所が用意できたら、出張勉強会もまたやりたいなと思っています。 興味ある方は、連絡ください！\n","date":1452220496,"dir":"post/2016/","id":"4b0a768585da8f9f8f8db1ca409e7ebd","lang":"ja","lastmod":1452220496,"permalink":"https://blog.johtani.info/blog/2016/01/08/14th-elasticcsearch-jp/","publishdate":"2016-01-08T11:34:56+09:00","summary":"あけましておめでとうございます、johtaniです。 第14回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆","tags":["elasticsearch","勉強会"],"title":"第14回Elasticsearch勉強会を開催しました。 #elasticsearchjp"},{"contents":"今年は紅白見ながら書いてます。 早い一年だったなぁ。\n振り返り(2014年に書いた抱負から) まずは去年の抱負を元に振り返りをば。\n英語の継続 海外のイベントへの参加 多岐にわたるイベントでのスピーカー 日本の人員の倍増！？ Elasticsearchに関する日本語の情報発信 Elasticsearch座談会みたいなものの開催 英語はまぁ、継続してます。亀の歩みですが。。。\n海外のイベントへの参加は、自社のイベントだけでした。来年のElastic{ON}ももちろん参加です。来年こそBerlin Buzzwords行きたいな。。。\n多岐にわたるイベントとまではいってないですかね。。。来年はOSC(大阪や東京)に出没予定です。参加される方は、声をかけていただければと。\n人員は倍増しました！営業の方が参画されたのがかなり助かってます。 今現在で4名です！来年も倍増できるかなぁ？\n日本語の情報発信はリリースブログの翻訳が多めでした。来年は独自コンテンツも増やさないとなぁ。 あとやっぱ書籍かなぁ。。。座談会は来年の課題に。。。\n振り返り(今年あったできごと) その他の今年の出来事。\n初渡米 初バルセロナ 東京以外で勉強会 初自社イベント（日本で） 初トレーナー 不惑 今年も初モノ多いですね。今年も楽しい一年でした。 自社イベントでアメリカやバルセロナなどに行きました。40年近く、海外に行ったことないせいか、海外に行って経験することが面白いです。\n東京以外での勉強会もやりました。名古屋、大阪、京都、北海道と。 来年もOSCで訪れた場所で勉強会を開催したいなぁと。\n自社のイベント（Elastic{ON} Tour Tokyo）も東京でやりました。 どうなることかと思っていましたが、朝から大勢の方に来ていただけてホッとしました。 自分のトークがどうだったのかという反応も気になりますが。。。 せっかくShayたちが来ていたので、もっとブースに話しに来てもらえるともっと嬉しかったかもなぁと。\nTour Tokyoを挟んで自社の公式トレーニングのトレーナーもやりました。 日本で3回目にして、初の日本語でのトレーニングでした。前の2回は逐次通訳だったんですが。 トレーニングって大変だなぁと思ったのと、やはり日本語でトレーニングを受けられるとだいぶ違うだろうなという実感がありました。 来年もできればいいなと。トレーニング自体があったことを知らない人もいたのかなぁ？\n来年の抱負 英語の継続 もっとElasticsearchの開発に参加 人員の倍増？ 日本語情報発信 Splatoon S+? 英語あいかわらず出来てないので、頑張らないと。 もっと喋ったりしないとなんだろうなぁ。\n来年は開発をもっとやりたいなと。 来年1月にはセールスのエンジニアが加入するので、開発にもっと時間を割きたいなと。\n人員は倍増できるように頑張りたいです。少なくとも、2人が1月に入ることは決まってるんで、後二人！\nブログももっと書かないとですね。新機能とかこんな使い方できるよとか。 どんな記事が欲しいかとかコメントもらえると楽なので、突っ込みくださいw\n最後は、完全に私用ですね。Splatoonにはまってますw SとA+を行ったり来たりで。。。\nということで、今年はあと、数時間ですが、色々とお世話になりました。 この場を借りてお礼申し上げます。\n来年も、いろんな方に絡んでいくとは思いますが、よろしくお願いいたします。\n","date":1451565182,"dir":"post/2015/","id":"c54909ecf4fb3e9afeea36200fe95dce","lang":"ja","lastmod":1451565182,"permalink":"https://blog.johtani.info/blog/2015/12/31/looking-back-2015/","publishdate":"2015-12-31T21:33:02+09:00","summary":"今年は紅白見ながら書いてます。 早い一年だったなぁ。 振り返り(2014年に書いた抱負から) まずは去年の抱負を元に振り返りをば。 英語の継続 海外の","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2015）"},{"contents":"今年最後のAdvent Calendarとなります。\nこの記事はElasticsearch Advent Calendar 2015の最終日のエントリです。\n簡単に今年の変遷を、Elasticsearchをベースに振り返ってみようかと思います。\nKibana 4リリース（2月） Kibana 4（日本語訳） いきなり、Elasticsearchではない話題ですが。 AggregationベースのKibanaがリリースされました。 画面が黒くないというので、話題になりましたw 12月末時点では、4.3.1になっています。 Sub Aggregationによる強力なグラフ表示や異なるインデックスに対するグラフを 一つのダッシュボードに表示できるといったことができるようになりました。\nセキュリティ向けプラグインShieldのリリース（2月） セキュリティ向けプラグインShieldのリリース（日本語訳） 商用向けのプラグインの第2弾です。 セキュリティ強化のためのプラグインで、いろいろなところで引き合いがあったりします。\n初のユーザカンファレンス、Elastic{ON}開催（3月） #elasticon に参加中 サンフランシスコで、弊社初のカンファレンスが開催されました。（来年（2016年）もサンフランシスコで開催されます。） また、ここで、以下の2点の発表がありました。\nロゴ及びドメイン名などの変更 Foundのジョイン 約1300名が参加する大イベントでした。 初の渡米で楽しんできましたが、ドメインの切り替えなどは大変でした。。。 まだ、ロゴを変えて1年経ってないということが実感できてないです。\nFoundのジョインはまだまだ、日本で知名度が出てないかもなぁと。 もっと広めないと。 利点としては以下の通りです。\n新バージョンがすぐに利用可能に。また、バージョンアップも画面で指定可能 公式プラグイン＋その他いくつかのプラグインが利用可能 Elasticsearch 1.5 リリース（4月） Elasticsearch 1.5.0リリース（日本語訳） 主に、resiliencyに関する改良になります。 毎リリースで信頼性向上につながる改良が含まれる形になっています。 このリリースの近くで初の東京の外での勉強会を名古屋で開催したりもしました。\ndiscuss.elastic.coをオープン（5月） https://discuss.elastic.co これまでは、Google Groupsを使っていましたが、Elasticが提供しているプロダクトが 別々のグループであったために、プロダクトにまたがった質問がやりにくかったり、検索がしにくかったりという問題点がありました。 今では、過去のGoogle Groupsのデータも移行されているので、是非参加して、質問・回答してみてください。 日本語でやりとりできるカテゴリもあるので、どんどん、やりとりしていただければ。\nElasticsearch 1.6 リリース（6月） Elasticsearch 1.6.0リリース（日本語訳） 2.0に向けたUpgrade APIが含まれるなど、次期リリースに向けた準備が整いつつあるリリースでした。 他にもsynced flushの取り込みやレスポンスのJSONのフィルタリングなど細かな改善も取り込まれています。\nFound PremiumとStandardリリース（7月） さらに進化したFound（日本語訳） Foundに弊社のサポートチームがサポートできるプレミアムが追加されました。 これにより、商用プラグインとして提供しているShieldが（現在はWatcherも）利用できるなど、 より便利になりました。また、Kibana 4も無料で提供されていたりします。\n小さなサイズのものですと、無料で試していただけるものもあるので、試してみてもらえればと。\nElasticsearch 1.7 リリース（7月） Elasticsearch 1.7.0 および 1.6.1リリース（日本語訳） 1.x系、最後のリリースでした。 小さい改善ですが、セキュリティフィックス、クラスタの安定化に寄与する機能改善が含まれています。\nこのリリース直前に大阪、京都で勉強会も開催してみました。\nElasticsearch 2.0.0-beta1 リリース（8月） Elasticsearch 2.0.0-beta1リリース（日本語訳） 待ちに待った、Lucene 5ベースのElasticsearchの登場でした。 doc_valuesがデフォルトになったり、エラーが構造化されて見やすくなったり、 Pipeline Aggregationが導入されたりしています。 また、問題点の洗い出しも兼ねて、ベータリリースとして、本リリースまでに多くのIssueをあげていただきました。\nElasticsearch 2.0.0 リリース（10月） 2.0の本リリースです。リリースまでに、beta1、2及び、rc1がリリースされました。\n追加された機能や目玉の改善については「Elasticsearch 2.0の紹介」のスライドを参考にしていただければと。\nまた、Elasticsearch 2.0のリリースに合わせて、商用プラグインやLogstash、Kibanaの新しいバージョンがリリースされました。 Kibanaなどは、プラットフォームとしての機能を備え、SenseやTimelionと言ったプラグインアプリもリリースされています。\nLogstash 2.0.0リリース（日本語訳） Kibana 4.2.0リリース（日本語訳） Senseの歴史 - Sense 2.0.0-beta1の紹介(日本語訳) Shield、Watcher、Marvel 2.0.0 GAリリース（日本語訳） Elasticsearch 2.1.0 リリース（11月） Elasticsearch 2.1.0 and 2.0.1 released Beats 1.0.0のリリース（11月） The Beats 1.0.0 Go言語で書かれた軽量データシッパーになります。 パケットをキャプチャしてElasticsearchに送るPacketbeat、 topコマンドで取れるデータなどをTopbeat、 ログファイルなどを取り込み配送するFilebeatがリリースされました。\nlibbeatと呼ばれる、 ベースとなるライブラリを元にしたプロダクトで、Logstashのエージェントのような使い方もできるようになっています。\nGo言語に興味のある方などは、調べてみてはいかがでしょう？\n来年は？ 日本では、1/7に第14回Elasticsearch勉強会を開催します。 すでに、38名のキャンセル待ちとなっていますが、おそらく、年明けにキャンセルがそこそこ出ると思うので、まだ間に合うんじゃないかなぁと。\n会社としては、Elastic{ON}16が控えています。参加される方は、ぜひ現地で声をかけてください！！\nその他にもイベント、オープンソースカンファレンス（まずは、大阪、東京）などに出没する予定ですので、こちらも参加していただければと。\nでは、また来年のAdvent Calendarでお会いしましょう！\n","date":1451017794,"dir":"post/2015/","id":"d819cea5197e9b8673d6c0b16659a5ea","lang":"ja","lastmod":1451017794,"permalink":"https://blog.johtani.info/blog/2015/12/25/about-elasticsearch-in-2015/","publishdate":"2015-12-25T13:29:54+09:00","summary":"今年最後のAdvent Calendarとなります。 この記事はElasticsearch Advent Calendar 2015の最終日のエントリです。 簡単に今年の変遷を","tags":["elasticsearch"],"title":"2015年のElasticsearch"},{"contents":"こんにちは、@johtaniです。\n早いもので、師走です。今年もあと少しとなりました（今月が一番忙しかったりしますが。。。）。 ということで、Advent Calendarの季節が始まりました。\nこの記事はElasticsearch Advent Calendar 2015の1日目のエントリです。\n今日は、最近公開されたTimelionの紹介をしたいと思います。\nTimelion? 11/12に公開されたばかりのアプリになります。（公式のブログはこちら。ブログでは動画による説明もあり）\nKibanaにプラグインとしてインストールすることで使用することができるようになるアプリです。 Timelionと書いて「Timeline」と読むようです。 Kibanaとは異なるグラフ描画のプラグインになっています。\nKibana 4.2からプラットフォーム化 Kibana 4.2から、Kibanaにプラグイン機構が導入されました。 Kibanaとしての機能以外にも、プラグインとして、アプリを追加できるようになっています。 Timelionもその一つです。\nインストール Timelionを試してみるには、ElasticsearchとKibanaが必要になります。（こちらは、すでにインストールされているとして。。。）\nKibanaのコマンドを利用して、プラグインをインストールします。\nbin/kibana plugin -i kibana/timelion インストールしたら、Kibanaにアクセスして、Timelionを呼び出します。\nTimelionへアクセス ブラウザでlocalhost:5601にアクセスすると、Kibanaが出てきます。 Kibanaのプラグイン選択のアイコンをクリックし、Timelionのアイコンをクリックします。\nすると、初期画面はこんな感じです。 直近15分のElasticsearchに入っているデータがが全部出てきます。 チュートリアルも出てきてます（初回起動時に出たはず）\nKibanaでの検索窓の部分に関数を指定していくことで、グラフが描画できるツールになっています。\nサンプル：気温データを可視化 百聞は一見に如かずということで、 気象庁のデータを使って、 ちょっとしたグラフを書いてみました。 1年間の気温の推移と日照時間になります。\n上のグラフが那覇、下グラフが札幌の気温のグラフになります。\n赤いライン：最高気温 青いライン：最低気温 黄色い棒グラフ：日照時間 最低気温と日照時間はグラフは次のような式で描画しています。\n青いラインの最低気温 気温のグラフになります。\n.es(index=\u0026#39;tenki2\u0026#39;, q=\u0026#39;city:naha\u0026#39;, metric=\u0026#39;avg:temperature_min\u0026#39;).label(\u0026#39;min\u0026#39;), .es()がelasticsearchに対するデータ取得の関数です。 引数は次のような意味になります。\nindex：対象とするインデックス名 q：検索クエリ。ここでは、cityというフィールドにnahaで検索。 metric：描画対象となっているデータの入ったフィールド。temperature_minというフィールドの1日毎の平均値を取得 最低気温と最高気温は別々のフィールドに格納してあります。最高気温の場合は（temperature_max）を指定します。\n.label(min)で、グラフの凡例の指定です。 残念ながら、日本語の指定は現時点（2015年12月01日時点）ではうまくいかなかったです。（https://github.com/elastic/timelion/issues/17）\nデフォルトでは、線グラフが選択されているので、グラフの種類は特に指定はしていません。 明確に指定する場合はlines()を指定します。\n黄色い棒グラフの日照時間 .es(index=\u0026#39;tenki2\u0026#39;, q=\u0026#39;city:naha\u0026#39;, metric=\u0026#39;avg:sunlight\u0026#39;).label(sunlight).bars() .es()に関しては最低気温のグラフとほぼ一緒です。異なるのは、metricの取得対象のフィールド名です。\n.label()で凡例を指定しています。先程と同様です。\n最後に、棒グラフにしたいため、.bars()を指定しています。\nその他に用意されている関数について知りたい場合は、Timelionのヘルプを表示すると説明が出てきます。 cusum()のような値を累積して表示するような関数も用意されています。\nまとめ Kibanaとは少し違うアプローチで時系列データを描画するためのツールとなっています。 線グラフと棒グラフを一つのグラフに描画したりもできますし、 累積のグラフなんかも描画できるようになっています。\n実験的なプロジェクトである、Timelionの紹介でした。 ここでのノウハウがkibanaにフィードバックされると色々と面白いことになるんじゃないかなと。\nということで、 明日は、zoetroさんの「Kibanaのプラグインの話」になります。 お楽しみに！\n","date":1448936891,"dir":"post/2015/","id":"1b56132638912a1ca54fcf7cd38b8e23","lang":"ja","lastmod":1448936891,"permalink":"https://blog.johtani.info/blog/2015/12/01/introduction-timelion/","publishdate":"2015-12-01T11:28:11+09:00","summary":"こんにちは、@johtaniです。 早いもので、師走です。今年もあと少しとなりました（今月が一番忙しかったりしますが。。。）。 ということで、A","tags":["kibana","timelion"],"title":"Timelionの紹介 - Elasticsearch Advent Calendar 2015 1日目"},{"contents":"第13回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 来年もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n7月同様、サムライズムの@yusukeさんに テキスト翻訳していただき、大変助かりました。\nチェックイン数など チェックインした人：100名 キャンセルしなかった人：36名 でした。 今回は当日の時点でキャンセル待ちがない状態にしていました。 雨もあって、これなかった人もいるのでしょうか。\n\u0026ldquo;Beyond the basics with Elasticsearch\u0026rdquo; / Honza Král / Elastic スライド：https://speakerdeck.com/elasticsearch/beyond-the-basics-with-elasticsearch\n参考ビデオ（別のカンファレンスで話した時のビデオ）：https://www.youtube.com/watch?v=yIixWzjTNog\nPycon HKでアジアに来ていたHonzaに、ついでに日本で話をしてもらうという企画で、 前回から1カ月足らずでの開催となりました。 Elasticsearchの基本的な検索機能とは別の機能に関して少し話をしてもらった感じです。 PercolatorとAggregationの話でした。\n詳しくはビデオやスライドを見てもらうのがいいかなと。\n\u0026ldquo;How did we use Found.no for our services?\u0026rdquo; / 株式会社アイリッジ　Takuya Noguchi さん @tn961ir スライド：未定\nFoundユーザー。1.7までの話。 社内で独自にクラスタを構築していたが、managed serviceを利用したいと思っていた。 Found用のACLがShieldに マルチバイトのインデックス名とかも使いたいが、Nginxとの連携でちょっと。。。 セキュリティ関連の話も。Securityに関する報告はこういうものも用意されてるので、こちらに相談してもらうのがいいかも。https://www.elastic.co/community/security 要望がいくつか。 \u0026ldquo;ログ収集の仕組みを再考しよう！　あとマウンテンビューに行ってきました。\u0026rdquo; / Acroquest Technology株式会社 谷本 心さん @cero_t スライド：http://www.slideshare.net/shintanimoto/lets-reconsider-about-collecting-logs-plus-visiting-elasticmoutain-view\nログの小話から始まり、ログに関する考え方とかを披露してもらいました。 さらに踏み込んだログの活用の方法の話になるかと思いきや、 思いっきり話が飛んで、マウンテンビューのElasticオフィスに遊びに行った写真が出てきましたw\n写真の後は、弊社のTanya（来月のElastic{ON} Tour Tokyoで来日予定）から 聞いた弊社製品に関する話をしていただきました。 きっと、Beatsに関して次は話してくれるんだろうなぁ（棒）。 流れ的には、来年の2月にサンフランシスコで開催されるElastic{ON}16につながりそうだったので、ここで宣伝しときますね。 今年3月に開催されたイベントには残念ながら日本の方はいなかったので、次回は日本の方がいると嬉しいなぁと。\nLT \u0026ldquo;「Elasticsearch を使った単語共起頻度の計算」\u0026rdquo; / 株式会社はてな　id:takuya-a さん スライド：未定\n一風変わったElasticsearchの使い方的な話でした。 検索用にデータを登録してあるElasticsearchから単語の頻度情報を抜き出して、 別のインデックスに登録するという感じでしょうか。 こういうのが、実は、Elasticsearchに機能としてあると便利だったりするのかもなぁと思ってみたり。\nLTよりはちょっと長かったですかねw\nその他、感想などのブログ elasticsearch勉強会 まとめ＋宣伝 今回も@yusukeさんのテキスト翻訳に助けていただきました。ほんとありがとうございます。 今年の勉強会はこれがラストになります。 来月は、トレーニングとElastic{ON} Tour Tokyoがあるので忙しくなりそうですが、 参加予定の方は楽しみにしていてください！\nOperations : http://training.elastic.co/class/Operations/Japan/Dec Developer : http://training.elastic.co/class/Developer/Japan/Dec ","date":1447143778,"dir":"post/2015/","id":"2ea86ae5093670df1d4502ea82efa1ac","lang":"ja","lastmod":1447143778,"permalink":"https://blog.johtani.info/blog/2015/11/10/13th-elasticsearch-jp/","publishdate":"2015-11-10T17:22:58+09:00","summary":"第13回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第13回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：The Story of Sense - Announcing Sense 2.0.0-beta1\n誕生 よくある良いプロジェクト同様、Senseもビールを飲みながら考えつきました。 Amstelでの手漕ぎボートのセッションの後で。 友人のJasperと私はJasperの会社で毎年行われる ハッカソンについて話をしていました。 このハッカソンはどのようなアイデアでどんなチームで行うかを聞き取りされる、厳密なハッカソンです。 その時、私とJasperはChromeブラウザに別のヒストリーを表示するという作業をやるとAnne Velingに話をしていました。\nJasperと私はElasticsearchのユーザでしたが、リッチなREST APIにリクエストを送信するための 便利なツールがないと知っていました。 恥ずべきことに、cURLコマンドを利用するターミナルがその時の一番良いツールでした。 皆さん、ターミナルでボディつきのリクエストをサブミットするのがどのくらい不便かというのをわかるために、 5秒ほどターミナルで実行してみてください。 タイプミスのような単純なことでさえ、すべてのコマンドを再タイプしなければならなかったり、 複数行サポートのターミナルと戦ったりです。 ウェブベースのJSONエディタを見つけ出して、それをベースにすることが必要でした。\n終わりなきウィークエンド リサーチをして、Anneに電話しました。 私は彼に、History Pageのプロジェクトにもコミットするが、 Elasticsearchユーザなので、便利なコンソールを開発する時間も欲しいという話をしました。 私たちは、Aceオンラインエディタを利用して、 自動でAPIを認識するナレッジベースを構築し、 コンテキストに沿ったサジェストを大なうようにしました。 Anneはすぐに、それが素晴らしいと同意してくれました。 しかし、彼は、ハッカソンの基本的なルール（週末にそれが終わる必要がある）に違反しているので、 そのアイデアを却下するしかありませんでした。 確かに、私たちが提案していたものは行えませんでした。 最後に、私たちは、ChromeのHistory Pageの素晴らしい置き換えについて実装しました。\nそれでも、私はチャレンジし、それが終わるであろうことを終わるであろうことを証明しなければなりませんでした。 次の週末（といくつかの終業後 :)）に、私はそれを作りました。 Senseの誕生です。 それは、まだバグだらけでしたが、動きました。 これを見せるとみんな興奮しました。\n初期 Knowledge Baseの拡張とバグのフィックスで数日を過ごしました。 Senseは広まり始め、ずっと古いバグのあるバージョンを利用しないといけないのかと私は恐れました。 SenseをChromeのExtentionとしてリリースすることを決め、リリースすると自動的に更新されるようにしました。 History Panelのような機能を一つづつ追加するようにしました。\nElasticにジョインしてから、会社の人たちがSenseを使用しているということを聞き、とても幸せでした。 特に、Clintと話をしたときのことを覚えています。 彼は、\u0026ldquo;You know what Sense should do? It should use this format and allow you to have multiple requests in the editor\u0026rdquo; 「Senseになにをすべきかわかる？フォーマットを使うべきだし、エディタで複数のリクエストを持つようにするべきだ」 と言いました。 もちろん、その他のチャレンジも行いました。これは、簡単なものではなく、Aceの詳細を知る必要がありました。 それは新しいAceモード（Aceによって利用されているハイライティングロジック）です。 これは、Senseのサジェストエンジンに密に統合されました。\n次のものが古いSenseのスクリーンショットです。\n画像あり。Figure 1. Sense 0.7 ※画像に関しては原文をご覧ください。\nAPIのURLを入力すると、JSONのボディが入力されます。 うまく切り離すことができ、AceのスタンダードJSONモードを使っていました。 しかし、ここで、次のようなフォーマットをどうやってサポートするか考える必要がありました。\nGET _cluster/health POST index/_settings { \u0026#34;index\u0026#34;: { \u0026#34;number_of_replicas\u0026#34;: 3 } } これは、Aceが3つの異なるものをどうやってパースするかを知る必要があるということです。 HTTPメソッドとURLとJSONボディです。 また、困ったことに、前に説明した前に説明した通り、明らかに別々にはならないものでした。 JSONボディが完全であることを知る唯一の方法はかっこを数えることです。 それは、いくつかの作業とAceのカスタマイズが必要でしたが、それらを切り離すことができました。 そして、Senseのシンタックスが生まれたのです（Thanks Clint!）\nMarvel時代 就業時間中、私の優先すべき仕事はMarvelの開発になりました。 これは、Elasticsearchのための管理と監視のためのソリューションです。 （side note: Marvelは生まれ変わっています。（\u0026quot;Shield, Watcher, and Marvel 2.0.0 GA Released\u0026quot;）） Marvelは開発環境ではフリーなので、MarvelにSenseを組み込むことにしました。 これにより、Senseの開発が日中も行えるようになり、多くのユーザに利用され始めました。 また、Senseは実際に真のJavaScript開発者によって開発されました。 彼は、コードをクリーンにし、ブラウザにおける最新の技術を私に教えてくれました。\nこの期間のSenseは数回書き換えられています。 最も顕著なものは、個別のURLとJSONのサジェストエンジンを書き換えて、 1つのサジェストエンジンにしこれらのコンテキストで動作するようにし、さらに3つ目のコンテキスト（URLパラメータ）を追加したことです。\n新しいエンジンはまた、複数のサジェストコンテキストをメンテナンスするのが簡単になりました。 例えば、_search APIのソートパラメータを考えます。\nGET _search { \u0026#34;sort\u0026#34;: [ \u0026#34;timestamp\u0026#34;: \u0026#34;desc\u0026#34;, \u0026#34;price\u0026#34;: { \u0026#34;order\u0026#34;: \u0026#34;desc\u0026#34;. \u0026#34;missing\u0026#34;: \u0026#34;last\u0026#34; }, \u0026#34;nested_filter\u0026#34;: { \u0026#34;term\u0026#34;: { ... }}, \u0026#34;_score\u0026#34; ] } ユーザがどこにいるかによって、Senseは単純な値（_scoreのような）か、 複雑な構造（orderとmissingのような）やフィルタ（nested_filterのような）も サジェストする必要があります。 これらのサジェストのパスが一度に処理され、無関係なものは除外されます。\nSense 2.0の紹介！ Marvel 1.xはKibana 3.0をベースにしていました。 これは、データの探索やダッシュボードツールとして素晴らしいものでした。 しかし、Kibanaチームはさらに素晴らしいものを出しました。 Kibana 4.xはElasticsearchをバックエンドとするUIアプリを簡単に構築することができる プラットフォームとして設計されています。 実際に、Marvel 2.0はKibanaの プラットフォームで利用できる最初のアプリです。\nSenseの話に戻します。 ElasticsearchのAPIとやりとりする一般的なコンソールです。 これをKibanaのアプリぴったりだと気付きました。 ということで、Sense 2.0をKibanaアプリとしてオープンソースで公開しました。 開発及び本番環境で利用してください。\nFigure 2. Screenshot Sense 2.0 ※画像に関しては原文をご覧ください。\nリリースのハイライト Sense 2.0の新しい機能をここで簡単に紹介します。 （すべての変更点についてはこちらをご覧ください。）\nElasticsearch 2.0 SenseのナレッジベースをElasticsearch 2.0サポートに更新しました。 新しいPipeline aggregationにも対応しています。\n複数リクエストの実行 テストやいくつかの一連のコマンドを繰り返し実行したい時があるでしょう。 その時に、それら全てをSenseに記述し、 実行したいリクエストを選択状態にしてElasticsearchにリクエストできます。\nFigure 3. Submit multiple requests ※画像に関しては原文をご覧ください。\nSenseは、Elasticsearchにリクエストを一つずつ送信し、それぞれの出力結果を右のパネルに表示します。 これは、問題のデバッグや複数のシナリオでのクエリの組み合わせの実行に非常に便利です。\n複数リクエストのコピーペースト 複数リクストを選択し、フォーマットしたり、cURLのコマンドとしてコピーすることも可能です。\nFigure 4. Copy multiple requests as cURL ※画像に関しては原文をご覧ください。\n# Delete all data in the `website` index curl -XDELETE \u0026#34;http://localhost:9200/website\u0026#34; # Create a document with ID 123 curl -XPUT \u0026#34;http://localhost:9200/website/blog/123\u0026#34; -d\u0026#39; { \u0026#34;title\u0026#34;: \u0026#34;My first blog entry\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;Just trying this out...\u0026#34;, \u0026#34;date\u0026#34;: \u0026#34;2014/01/01\u0026#34; }\u0026#39; もちろん、複数のcURLコマンドをコピーしてSenseにペースとすると、Senseはそれらをパースしてくれます。\nまとめ Sense 2.0.0のベータリリースです。 実際に多くの作業が終わった認識です。すぐにGAが出るでしょう。\nSense 2.0を知り、試していただくために、新しいドキュメントを参考にしてください。 バグやリクエストがある場合は、フォーラムやGitHubのIssueに登録をお願いします。\n","date":1446195306,"dir":"post/2015/","id":"5912529cfd6ce14c5ede5c6c83dae7e8","lang":"ja","lastmod":1446195306,"permalink":"https://blog.johtani.info/blog/2015/10/30/sense-2-0-0-beta1-ja/","publishdate":"2015-10-30T17:55:06+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：The Story of Sense - Announcing Sense 2.0.0-beta1 誕生 よくある良いプロジェクト同様、Senseもビールを飲みながら考","tags":["elasticsearch","sense"],"title":"Senseの歴史 - Sense 2.0.0-beta1の紹介(日本語訳)"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Shield, Watcher, and Marvel 2.0.0 GA Released\n本日（10/28）Shield、WatcherおよびMarvel 2.0をリリースしました。 これが、Elasticsearch 2.0に対応したこれらのプラグインの最初のリリースです。\nElasticsearch 2.0対応のほかに、ShieldとWatcher 2.0は、 セキュリティとアラートを拡張するいくつかの新しい素敵な機能も備えています。\nShield 拡張可能なレルム - Sheild 1.xはユーザ認証のコア的なものを定義するのにフォーカスし 3つの認証メカニズム（esusers、LDAP/AD、PKI）を提供しました。 これらを提供することで、多くのユーザおよびユースケースをカバー出来ましたが、 追加の認証メカニズムを統合する必要があることもわかっていました。 ということで、Shieldのレルムベースの認証システムをユーザが利用、拡張できるようにオープンにし、 ユーザ認証を扱うためのレルム実装をプラグインとして拡張できるようにしました。 特定もしくはプロプライエタリな認証メカニズムが必要なユーザもShieldの強力な セキュリティ機能（ロールベースの認証、セキュアな通信など）をフルに活用できるようになりました。 カスタムレルムの詳細については、こちらをご覧ください。\nフィールドとドキュメントのACL - Shield 2.0はフィールドとドキュメントレベルのアクセス制御機能を提供します。 これは、ロールごとにアクセス可能なフィールドやドキュメントを定義できます。 この新しい機能は、設定の変更するよりも便利です。 このアクセス制御はElasticsearchのLuceneインデックスという最も低レベルで実装されています。 その結果として、このメンテナンスがより簡単であるだけでなく、より良くなっています。 詳細についてはこちらをご覧ください。\nユーザなりすまし - Shield 2.0で、ユーザなりすましの機能が実装されました。 これは、ユーザ（適切なパーミッションを持った）が、他のユーザになることができ、 それらのユーザのためにリクエストを実行できます。 これは、Elasticsearch上に構築されたアプリケーションがすでにユーザ認証を行いますが、 認可はElasticsearchサイドで行う必要があるような場合に有用です。 このシナリオで、アプリケーションの\u0026quot;main\u0026quot;ユーザを設定でき、正しくなりすましを割り当て、 ElasticsearchにアプリケーションユーザとしてリクエストをElasticsearchに実行させることができます。 詳細については、こちらをご覧ください。\nWatcher SlackとHipChatインテグレーション - SlackとHipChatはチーム/グループコラボレーションツールです。 これらは、急速に主流になり、組織の主な内部コミュニケーションハブとなっています。 Watcher 2.0はチャンネル/ルームやユーザにこれらのコミュニケーションチャネル経由で、Watchの通知を行うことができるアクションを 実装しました。 slackやhipchatアクションについてはドキュメントをご覧ください。\nArray Compare Condition - 新しいconditionはタイムシリーズのデータのスパイクを検知するのを簡単にします。 compare conditionは1.xで導入されましたが、このコンディションはElasticsearchのダイナミックスクリプト機能を有効にする必要がアンク使えます。 詳細についてはarray_compare conditionをご覧ください。\nWatchの有効・無効化 - ユーザからの多かったリクエストとして、Watchの無効化がありました。 1.xには、登録済みのWatchを無効にする機能がありませんでした。 これは、Watchを消すか、Watchのトリガーを変更することで回避していました。 これは、全体としてはWatchを管理するのを難しくする回避方法でしかありません。 2.0では、APIを呼び出すだけで、Watchの変更をすることなく、簡単にWatchの有効化・無効化が可能になりました。 これは1.0からあるべき基本的な機能でしたが、ついにこの問題を解決しました。 詳細はこちらをご覧ください。\nMarvel Marvel 2.0を紹介するのに興奮しています。 Kibana 4をベースとした、再設計されたUIを持っています。 Marvel 1.xで学んだ多くのことを導入し、より使いやすく監視しやすいUIになっています。 ShieldとWatcherと同様に、最初のMarvelのリリースは将来的な成長の基盤となり Elasticsearch2.0を効率的に管理するための主要なメトリックにフォーカスしています。\n画像あり。 ※画像に関しては原文をご覧ください。\n再設計により、インタフェースを6ページに減らしています。\nCluster list 画像あり。 ※画像に関しては原文をご覧ください。\nユーザやカスタマーの多くは複数のクラスタを利用しています。 新しいMarvelはそれらを集中的にモニタリングする一つのクラスタからそれらを簡単に監視できます。 各クラスタのデータ送信先をこのモニタリングクラスタにするだけです。\nCluster Overview 画像あり。 ※画像に関しては原文をご覧ください。\nクラスタオーバービューはある一つのクラスタの主要な性能メトリックを見ることができ、 素早くスパイクを発見できます。 このページはまた、アクティブなシャードのリカバリやリロケーションも見ることができます。\nIndices List 画像あり。 ※画像に関しては原文をご覧ください。\nインデックスのリストにはクラスタにあるすべてのインデックスとその属性が表示されます。 テーブルはライブでアップデートされ、フィルタリングやソートも可能です。 一番大きなインデックスは？といったことも調べられます。\nIndex Detail 画像あり。 ※画像に関しては原文をご覧ください。\nインデックス詳細ページはインデックスの主な性能メトリックを見ることができ、シャードの配置についても表示します。\nNodes List 画像あり。 ※画像に関しては原文をご覧ください。\nノードリストはクラスタにあるノードとその主な性能メトリックを見ることができます。 テーブルはライブでアップデートされ、フィルタリングも可能です。 高いCPU利用率やディスクの残り容量なども簡単にわかるようになっています。\nNode Detail 画像あり。 ※画像に関しては原文をご覧ください。\nノード詳細ページは個別のノードに関する主な性能メトリックを見ることができ、ノードにあるシャードのリストも見ることができます。\n新しいMarvelはKibana 4の上に構築されたので、管理方法が変わっています。 Marvelのインストールは2つのステップがあります。 marvel-agentとmarvel user interfaceです。\nMarvel Agent marvel-agentはElasticsearchクラスタにプラグインとしてインストールします。 主なパフォーマンス情報を取得し、ローカルもしくは分離されたモニタリングクラスタにデータを保存・送信します。\nMarvel User Interface Marvel UIはKibanaのプラグインとしてインストールします。 これは、Kibana 4.2の新しいプラグインインフラを利用し、 Marvel Appとして、Kibanaのインタフェースとは個別に提供されます。 Kibanaのアプリの切り替えは次の画像の通りです。\n画像あり。 ※画像に関しては原文をご覧ください。\n2.0リリースは私たちのプロダクトの大きな一歩です。またユーザの意見を常にお待ちしています。 ぜひ、Webフォーラム（https://discuss.elastic.co）やメール（info@elastic.co）でご意見を。\n","date":1446189691,"dir":"post/2015/","id":"15700442e957951307bbcec5fff8643d","lang":"ja","lastmod":1446189691,"permalink":"https://blog.johtani.info/blog/2015/10/30/shield-watcher-and-marvel-2-0-ga-released-ja/","publishdate":"2015-10-30T16:21:31+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Shield, Watcher, and Marvel 2.0.0 GA Released 本日（10/28）Shield、WatcherおよびMarv","tags":["elasticsearch","shield","watcher","marvel"],"title":"Shield、Watcher、Marvel 2.0.0 GAリリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 2.0.0 GA released\nElasticsearch 1.0.0のリリース以降、 477のコミッター2,799のpull requestがあった、 **Elasticsearch 2.0.0 GA（Lucene 5.2.1ベース）**をリリースしました。\nそれだけでなく、Shield（セキュリティプラグイン）とWatcher（アラーティングプラグイン）、 新しくなったMarvel（モニタリングプラグイン）（プロダクション環境でフリー！）、 また、新しくオープンソースとなったSense editorの2.0.0もリリースしました。\nElasticsearch 2.0.0のダウンロードはこちらから。 また、2.0.0での重要な変更点についてはこちらをご覧ください。 全ての変更点については、次をご覧ください。\nChanges list for Elasticsearch 2.0.0 Changes list for Elasticsearch 2.0.0-rc1 Changes list for Elasticsearch 2.0.0-beta2 Changes list for Elasticsearch 2.0.0-beta1 商用プラグインについてはこちらです。\nShield 2.0.0 change logs Watcher 2.0.0 change logs Elasticsearchの新機能 Elasticsearch 2.0.0には素晴らしい新機能があります。\nPipeline Aggregations Aggregationsで導関数や移動平均のような他のAggregationの結果に対する計算が可能となります。 この機能はクライアントサイドで実装しなければなりませんでしたが、 Elasticsearchに計算させることで、より強力な解析のクエリを簡単に組み立て、クライアントのコードを簡略化できます。 これは、予測解析や予測解析や例外検知といった可能性をもたらします。 Pipeline Aggregationについては次をご覧ください。\nOut of this world aggregations. Staying in Control with Moving Averages - Part 1. Staying in Control with Moving Averages - Part 2. Query/Filter merging フィルタはもうありません。 全てのフィルタ条件はクエリとなりました。 クエリコンテキストで使用した場合、関連度のスコアに影響し、フィルタコンテキストで使用した場合、 これまでのフィルタのように、ヒットしなかったドキュメントを除外するだけとなります。 この変更はクエリの実行時に自動的に最も効率的な順序で実行するように最適化されることを意味します。 例えば、遅いクエリ（フレーズやgeo）の最初の実行は速い近似フェーズで実行され、 それから、遅い正確なフェーズで結果を修正します。 フィルタコンテキストでは、直近でよく使われた条件が自動的にキャッシュされます。 詳細については、\u0026quot;Better query execution coming to Elasticsearch 2.0\u0026ldquo;をご覧ください。\n設定可能な圧縮率 _sourceのようなStored fieldsは高速なLZ4（デフォルト）で圧縮するか、インデックスサイズを小さくできるDEFLATE で圧縮できます。 これは、特にロギングのケースで便利です。 古いインデックスをオプティマイズする前にbest_compressionに変更することができます。 詳細については\u0026rdquo;Store compression in Lucene and Elasticsearch\u0026ldquo;をご覧ください。\n堅牢に 新しいElasticsearchはJava Security Managerの元で実行されます。 これは、セキュリティの観点で大きな前進です。 Seciruty ManagerはElastcsearchにより制限をかけ、ハッカーによりシステムに対して何でもできるようなものを制限します。 Elasticsearchはまた、インデキシングの観点でも堅牢になっています。\nドキュメントはインデキシングリクエストに答える前に、耐久性のためにディスクにfsyncされます。 すべてのファイルはチェックサムにより、早期に障害を検知します。 すべてのファイルはどんなファイルへの書き込みもアトミックです 最後に、システム管理者から要請の多かった変更として、 設定されて居ないノードがパブリックなネットワークから参加しないようになりました。 Elasticsearchはデフォルトではローカルホストのみにバインドします。マルチキャストは無くなりました。（プラグインとして残っています。）\nパフォーマンスと信頼性 上記以外にも細かな修正がElasticsearchとLuceneにはあります。 より安定し、信頼性をあげ、簡単に設定できるようにするものです。例えば、次のようなものです。\nヒープの使用率の低減（doc valuesがデフォルト、マージ時のメモリ使用率の削減、 roaring bitsetsによるフィルタキャッシュ） 構造化され読みやすくなった例外 設定の代わりに、フィードバックループを使用した自動調整 安全で明確で信頼性のあるタイプマッピングの大きな修正 クラスタ状態の差分変更による伝搬の高速化および、大きなクラスタでのより安定的に normsの圧縮の改善。これまではヒープスペースを大きく利用していた。 マージの自動的な調整（不可解な設定の微調整が必要ない） より詳細なLuceneのメモリリポート 最適化されたクエリ実行を活用するためにParent/childを書き換え コアプラグイン 公式にサポートされたコアプラグインはElasticsearchと同じバージョン番号で同じタイミングでリリースされます。 インストールするプラグインとElasticsearchの複雑なバージョンの対応表に悩まされる必要はもうありません。 コアプラグインのインストールは次のように簡略化されています。\nbin/plugin install analysis-icu ShieldとWatcherの新機能 商用プラグインも新しい機能をリリースしました。\nShield フィールドおよびドキュメントレベルのアクセス制御 ユーザのなりすまし カスタム拡張可能な認証レルム Watcher 個別のWatchを有効/無効に SlackやHipChatへの通知 これらの詳細については“Shield, Watcher, and Marvel 2.0.0 GA Released”をご覧ください。\nコアプラグイン同様、商用プラグインもElasticsearchのバージョンと同じものが同時にリリースされます。 インストールは次の通りです。\nbin/plugin install license bin/plugin install shield bin/plugin install watcher Marvel 2.0.0はプロダクションでの利用もフリーに Marvelモニタリングプラグインはカスタマに非常に価値のあるもので、 ユーザの発展とともに問題を診断したり見つけたりするのに役に立ってきました。 私たちは、何を改善でき、Mαrvelを一から書き直すことで、いろいろとわかったことがあります。\nMarvel UIを新しいKibanaプラットフォーム上に構築 ダッシュボードにはより簡単に問題を発見するために、最も重要なメトリックを可視化 1つのインストールで、複数のクラスタのモニタリングをサポート（商用サポート対象） 一番良い点はMarvelがすべてのElasticsearchユーザに対してプロダクション環境でフリーになったことです！ ライセンスが必要ですが、課金の必要はありません。 もし、マルチクラスタモニタリングサポートが必要な場合、それは商用サポート対象となります。\n詳細に関しては“Shield, Watcher, and Marvel 2.0.0 GA Released”をご覧ください。\nSense editorがオープンソースに Sense（ブラウザベースのElasticsearchリクエストとDSL向けのエディタ）を Kibanaプラットフォームのアプリとして、オープンソースにしました。 また、このリリースで新しい機能が追加されています。\n複数のcURLリクエストをペースとすると、Sense表記に変更 複数のSenseリクエストをcURL表記にしてコピー 複数のリクエストを一度に実行可能 Elasticsearch 2.0サポートとなった自動補完機能 SenseはKibanaのアプリとして次のようにインストールします。\n./bin/kibana plugin --install elastic/sense Senseの詳細については、\u0026quot;The Story of Sense - Announcing Sense 2.0.0-beta1\u0026ldquo;をご覧ください。\nElasticsearch Migration Plugin Elasticsearch Migration PluginはElasticsearch 1.xから2.0にアップグレードする時の良い出発点となります。 1.xのElasticsearchクラスタにサイトプラグインとしてインストールすると、 アップグレードする前に解決すべき問題があるかどうかを検知してくれます。 （例えば、Lucene 3のような古いインデックスや、2.0.0にした場合に動作しない問題のある マッピング（The Great Mapping Refactoring）のような問題）\nプラグインに関してElasticsearch Migration repositoryをご覧ください。\nまとめ ぜひ、Elasticsearch 2.0.0をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)やWebフォーラムなどで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1446103243,"dir":"post/2015/","id":"018e32a8010960eb17e368a6fdd5a51b","lang":"ja","lastmod":1446103243,"permalink":"https://blog.johtani.info/blog/2015/10/29/elasticsearch-2-0-0-released-ja/","publishdate":"2015-10-29T16:20:43+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0 GA released Elasticsearch 1.0.0のリリース以降、 477のコミッター2,79","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0リリース(日本語訳)"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Kibana 4.2.0 released\nElasticsearch 2.0 + Kibana 4.2 = 💚 Elasticsearch 2.0サポートのKibanaの最初のリリースです。 これが何を意味するでしょう？ 速さ、安定さ、新しい機能。 試してみたい方は、いますぐダウンロードしてください。 そうでない方は、Kibana 4.2の楽しい機能について読んでみてください。\n暗黒面は怖い？ そんなことありません。 私たちは常にチャートチャートとダッシュボードを組み立てている組み立てている間は明るいバックグラウンドを使うことを推奨してきましたが、 時々、巨大なスクリーンで暗い部屋で誰も明るい画面から目を背けないようにしたいでしょう。 その影響を小さくするためにダークモードを導入しました。 あなたは、NOCや天文台、その他の暗い場所でKibanaのダッシュボードを楽しむことができます。\n画像あり。 ※画像に関しては原文をご覧ください。\n地図のカスタマイズ Kibanaの地図は素晴らしいですが、もっと多くのオプションが望まれていると聞きました。 もし地図に関して知識があるなら、Kibana 4.2のWMSバックグラウンド地図サポートを試してみてください。 WMSは非常に強力で、US Geological Surveyを含む多くの無料サービスがあります。 http://viewer.nationalmap.gov/example/services/serviceList.html\n画像あり。 ※画像に関しては原文をご覧ください。\nシナリオは？ 何かおかしい時、何が起こっているかを正しく知ってもらいたいので、Kibanaがそのタイミングで注目したいコンポーネントがあるなら、 どのように動いているかという概要を知るためのサーバステータスページを作りました。 もちろん、全てがOKであるというのを知りたいだけの場合でも、settingメニューのStatusタブからいつでも呼び出せます。\n画像あり。 ※画像に関しては原文をご覧ください。\n全てにおいて速く ブラウザリフレッシュはKibana 4.2の新しいコードビルディングシステムのおかげで、さらに早くなりました。 また、メモリを覚えてます？Pepperidge FarmKibanaが覚えています。 Kibana 4.2は小さな小さな小さなメモリフットプリントを管理している間、長い長い長い時間実行されているダッシュボードを見ることができるような 大きなメモリのクリーンアップも含んでいます。\nもっとありますが。。。 小さな微調整がいくつもあります。また、今後紹介する本当に刺激的なものの基礎を気づき上げてきました。 これからもElasticのブログ、Twitter、KibanaのGitHubリポジトリに注目し、モンスタートラックアナリティクスの瞬間に立ち会ってください。\n","date":1446103219,"dir":"post/2015/","id":"e159a35d1b9a46e03072a3d54780edcb","lang":"ja","lastmod":1446103219,"permalink":"https://blog.johtani.info/blog/2015/10/29/kibana-4-2-0-ja/","publishdate":"2015-10-29T16:20:19+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Kibana 4.2.0 released Elasticsearch 2.0 + Kibana 4.2 = 💚 Elasticsearch 2.0サポートのKibanaの最初のリリースです。 これ","tags":["elastic","kibana"],"title":"Kibana 4.2.0リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Logstash 2.0.0 released\nLogstash 2.0.0が本日（10/28）リリースされました。 このリリースは いくつかの設定に関する重要な変更があります。 詳細については、changelogまたは、新しいbreaking changesドキュメントをご覧下さい。\nこれまでの2.0.0直前のリリースに関する変更点はこちらをご覧ください。\nbeta1 beta2 beta3 RC ここでは、2.0の主な変更点の概要を説明します。\nElasticsearch 2.0との互換性 多くの機能および改善を含んだElasticsearch 2.0がリリースされました。 Logstash 2.0はこのリリースに対応しています。 Logstashのこれまでのリリースでは、デフォルトで、Javaの node clientをElasticsearchとの通信として 使用してきました。 2.0では、HTTPクライアントがデフォルトになります。 これにより、シームレスにユーザのデータを取り込み、付加価値をつけ、Elasticsearchに保存して解析することができます。\nHTTPは他のプロトコル（nodeやtransport）同等の機能を持っていますが、 単一のクライアントに接続する時に、少しだけ遅いですが、管理や動作がより簡単です。 HTTPプロトコルを使うことで、Elasticsearchのバージョンのアップグレードが、Logstashのアップグレードすることなく 行うことができます。 デフォルトをHTTPに変更したさらに詳しい情報についてはbeta1のブログをご覧ください。\n他のプロトコル（nodeとtransport）もサポートしますが、これらを利用する場合には、 プラグインを別途インストールする必要があります。\nbin/plugin install --version 2.0.0 logstash-output-elasticsearch_java 互換性のマトリックス LogstashとElasticsearchのバージョンの互換性は次のようになります。\n画像あり。 ※画像に関しては原文をご覧ください。 #Image https://www.elastic.co/assets/bltde5b69e2164aa82f%2Fcompat_matrix.png\nShield 2.0との互換性 このリリースはShield 2.0リリースにも対応しています。 HTTPプロトコルで、追加のプラグインは必要ありません。 こちらのドキュメントをご覧ください。 transportプロトコルでは、Shield 2.0対応のプラグインを個別にインストールする必要があります。\nbin/plugin install --version 2.0.0 logstash-output-elasticsearch_java_shield パフォーマンスの改善 このリリースはまた、多くの部分のパフォーマンスの改善を含んでおり、Logstashを利用してデータをより早く処理することができます。 いくつかをここで説明します。\nUserAgentとGeoIPフィルタ：これらのフィルタで、LRUキャッシュを追加して改善しています。 これにより、IPとユーザエージェントがまとまって現れるというWebリクエストの特性を用いています。 ユーザエージェントフィルタのケースでは、サンプルデータセットにおいて3.7倍ほど早くなりました。 GeoIPでは、1.69倍早くなっています。\nJSONプロセシング：LogstashでJSONのsiriaraizu/でシリアライズに利用しているJrJacksonを新しいバージョンにしました。 これにより、JSONの処理が改善されています。\nフィルタワーカーのより良い値をデフォルトに：以前のリリースでは、filter_workersの設定は1がデフォルトでした。 これは、フィルタの処理を行うワーカーが1つであるという意味です。 filter_workersの設定のデフォルト値はCPUコア数の半分の値を設定します。フィルタ実行の並列性が上がります。 ですので、複雑なgrokパターンやuseragentフィルタの処理がにとっては重要です。\nFilebeat Support Filebeatのベータバージョンを先日リリースしました。 これは、Logstash Forwarderの次期バージョンです。 Filebeatはファイルベースのログをさらに処理するためにLogstashに送るためのエージェントです。 2.0.0はlogstash-input-beatsプラグインを使えばFilebeat 1.0.0-beta4とすぐに動作します。\nシャットダウン操作 これまでのLogstashでは、シャットダウンが開始した時に、例外の機構でシャットダウンが開始したことを プラグインに通知していました。 この処理はサードパーティのコードを使ったプラグインで問題を起こしていました。 Logstashはどの例外を処理するか知らないため、予期しない動作をしていました。 これを修正するためにAPI呼び出し（例えばstop）を各プラグインにシャットダウンのイベントを通知し、 プラグイン自身がきちんと停止するようにしました。 これは、200以上のプラグインに新しいAPIを利用するように修正しないといけないことを意味しました。 しかし、Logstashの停止についてはまだ完全にはフィックスしていません。 とちゅうでおわっているoutputがシャットダウンを遅らせる可能性があるからです。 2.0でAPIの破壊的な変更は適切なリリースでの変更を繰り返すことができる出発点です。\nプラグインの開発者へ：もし、Logstash　1.5のプラグインを開発しているなら、 シャットダウンに関する新しいAPIのリストに関するbreaking changesのドキュメントに助言をください。 また、example inputリポジトリにて、新しいシャットダウンメカニズムの使い方のサンプルコードを提供しています。\nドキュメント 2.0に更新されたドキュメントはこちらです。設定の変更についてもこちらをご覧ください。\n2.0へのアップデート 2.0へアップデートする前に、アップデートガイドもご覧ください。\nフィードバック 2.0のリリースできたことに、多くのコントリビューター、ユーザに感謝しています。 このリリースに含まれている多くのパッチと全てのプレリリースのテストにも感謝しています。 将来の修正やリリースなどについてはロードマップをご覧ください。 2.0は今日リリースされました。 ご意見ご感想はWebフォーラムで！\n","date":1446103197,"dir":"post/2015/","id":"cc64c2fcdecdb505b3797e1aaaa59adc","lang":"ja","lastmod":1446103197,"permalink":"https://blog.johtani.info/blog/2015/10/29/logstash-2-0-0-released-ja/","publishdate":"2015-10-29T16:19:57+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Logstash 2.0.0 released Logstash 2.0.0が本日（10/28）リリースされました。 このリリースは","tags":["elastic","logstash"],"title":"Logstash 2.0.0リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Relase, we have ※画像に関しては原文をご覧ください。\nElasticにとって大きな1日（社内では「release bonanza」と呼んでいる）です。 多くの主要なプロダクトを新たにリリースしました。 そして、本日、それらを一緒に利用する時にそれらを一緒に利用する時にユーザの体験についてまとめてみました。\n次の通りです。\nElasticsearch 2.0リリース。 大きなマイルストーン、チームによる改善、そして、コミュニティからの素晴らしい貢献。 Pipeline Aggsと呼ばれる新しいタイプのaggregations、 クエリとフィルタのコンセプトを統合することにより簡素化されたクエリDSL、 better compressionオプション、 JavaのSecurity Managerを有効にすることによる強化されたセキュリティ、 FSの挙動に関する強化（fsync、checksum、atmicなリネーム）、 パフォーマンス、マッピングの挙動の一貫性などなどです。 また、我々のチームによる改善も含まれているLucene 5ベースにアップグレードしています。\nKibana 4.2リリース。 Elasticsearch 2.0対応、ダークテーマ、カスタマイズ可能な地図、多くの改善。 Kibana 4.2の多くに作業については外部プラグインサポートといった、内蔵に関するものでした。 この後の説明に続きます。\nMarvel 2.0リリース。 Elasticsearch 2.0対応、合理化されたメトリックス、簡素化されたUI、 多くはKibanaプラグイン（Kibanaプラットフォーム上に構築）としての書き換えです。 このKibana拡張の最初の努力は、Kibanaのプラグインをどうやって書くか、 Kibanaユーザに公式に何をする必要があるかといったものを特定するのに役立ちました。 おっと、忘れるところでした、Marvelを全てのユーザにフリーで使えるようにしました。 マルチクラスタサポートについては有償となります。\nSense 2.0リリース。 2つ目のKibanaプラグインがこれです。 SenseをKibanaプラグインとして書き換えました。 Elasticsearch 2.0サポート、複数リクエストの実行、 curlへのコピーなどです。 おっと、忘れるところでした。オープンソースとすることにしました！\nShield + Watcher 2.0リリース。ElasticsearchのためのセキュリティプラグインであるShieldと、アラート管理のためのプラグインであるWatcherにも 多くの結果が入っています。 最も要求のあった機能である、フィールドお呼びドキュメントレベルでのセキュリティについて、Luceneに落とし込んで実装しました。 また、セキュリティの操作についてプラガブルに実装できるように変更しました。 Watcherは監視の無効化、SlackやHipChatへの通知（bot ops向け）が可能です。\nLogstash 2.0リリース。 Elasticsearch 2.0のサポート、クリーンな停止、全面的なパフォーマンス改善、Beatsサポート。\nご覧の通り、すべてのプロダクトに関する大きな結果です。 チーム間およびFoundの開発者との間での密な連携に感謝します。 これらが私たちが公式にElasticsearch / KibanaをホストしているFoundで 利用可能です。\nひゅう、息切れしました。 チームがしてきたことは、感動的で、謙虚で、刺激的です！ Elasticが会社として、全てのユーザ、コントリビュータがどのように私たちの大きなミッションに対する結果をもたらしたかという素晴らしい良い例です。 ユーザに愛され、楽しまれ、成功に導き、革新させる製品を是非ご利用ください。ありがとうございます。\n\u0026ldquo;A Lion, in Africa?\u0026rdquo; - まだまだ終わりではありません。この文言で終わりにしますが、すぐに（本当にすぐに）戻ってきます。;)\n","date":1446095939,"dir":"post/2015/","id":"4cc08ca51ecf0f963035f039de6194c5","lang":"ja","lastmod":1446095939,"permalink":"https://blog.johtani.info/blog/2015/10/29/release-we-have-ja/","publishdate":"2015-10-29T14:18:59+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Relase, we have ※画像に関しては原文をご覧ください。 Elasticにとって大きな1日","tags":["elasticsearch","kibana","logstash"],"title":"Release, we have（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 2.0.0-beta2 released\n本日（9/17）、Lucene 5.2.1ベースのElasticsearch 2.0.0-beta2をリリースしました。 本リリースが2.0.0のRCの前の最後のベータリリースになります。\n注意事項 本リリースはベータリリースであり、テストを目的としたものとなります。 Elasticsearch 2.0.0-beta2はElasticsearch 2.0.0-beta1と互換がありません。 また、Elasticsearch 2.0.0 GAと互換性があるかどうかの保証はありません。\n本番環境には利用しないでください。\nElasticsearch 2.0.0-beta2のダウンロードおよび、すべての変更についてはリンクをごらんください。\n2.0.0-beta1をテストし、問題点を報告していただいた皆様、ありがとうございます。 2.0.0-beta1のあとのElasticsearchのコアの部分の修正のほとんどはバグフィックスになりますが、 geo_shapeフィールドのpoints_only最適化のようなちょっとした改善も含んでいます。\nまた、本リリースでは、商用プラグインの重要な新機能もあります。 こちらについてはShield and Watcher 2.0.0-beta2 releasedをごらんください。 簡単な紹介は次の通りです。\nShieldの新機能 ドキュメントおよびフィールドレベルのセキュリティ Shieldは、クエリを利用したインデックスにあるドキュメントへのアクセスを制御するためのロールを定義できるようになりました。 また、ドキュメントにある特定のフィールドに関するアクセス制限も可能です。 フィルタされたエイリアスのような形ではなく、ドキュメントを検索したり、IDで取得したりする場合にこれらの制限が利用できます。 詳細はField- and Document-level Securityをごらんください\nユーザなりすまし 特定のユーザーに他のユーザーに扮して、彼らのためにリクエストを実行する能力を与えることが、現在できます。 これは、認証がアプリケーションによって実行される場合に便利です。 そして、それは、ユーザの許可レベルを考慮するようにElasticsearchにリクエストします。 詳細はSubmitting Requests for Other Usersをごらんください。\nプラガブルな認証レルム このリリースで、サードパーティの拡張のための認証レルムのインフラを公開しました。 もし、特定の認証要求があり、Shieldがサポートしていない（が、内部の認証管理システムを使いたいような）場合、 これらの要求に見合う新しい認証レルムを利用するプラグインを作成可能です。 詳細はCustom Realmsをごらんください。\nWatcherの新機能 監視の一時 新しく、active / inactive の状態がwatchに追加されました。 これらは、Watchを中断したり、要求に応じて再開させたりできます。 詳しくは、Active Stateをごらんください。\nチャットのための新しいアクション slackとhipchatアクションが追加されました。 これは、Watcherが通知を、SlackやHipchatのユーザに直接送ったり、 チームのチャットルームに送ったりすることが出来るようにします。 詳細については、Slack actionおよび、Hipchat actionをごらんください。\n2.0に関するこれまでのブログ記事 これまでのリリースについての情報はこれらのブログ記事をごらんください。\n\u0008* Elasticsearch 2.0.0.beta1 released\nElasticsearch 2.0.0.beta1 coming soon! The Great Mapping Refactoring Store compression in Lucene and Elasticsearch Better query execution coming to Elasticsearch 2.0 Out of this world aggregations Staying in Control with Moving Averages - Part 1 Staying in Control with Moving Averages - Part 2 The Delete by Query API Is now a plugin Elasticsearch unplugged - Networking changes in 2.0 また、Elasticsearch 2.0.0-beta2のドキュメントや2.0のbreaking changesのリストもごらんください。\nElsticsearch Migration Plugin Elasticsearch Migration Pluginは、既存のインデックスをアップグレードする 必要があるか、他に必要な行動がないかについて、Elasticsearch 2.0.0-beta2を試す前に確認する助けとなります。 Lucene 3のような古いインデックスや、2.0.0にした場合に動作しない問題のある マッピングのような問題を発見できます。\nプラグインの動作に関しては[Elasticsearch Migration repository](Elasticsearch Migration repository)をごらんください。\nテストしましょう！ Elasticsearch 2.0.0 GAをすぐにリリースできるようにより多くのベータテスターをお待ちしています。\nぜひ、Elasticsearch 2.0.0-beta2をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)やWebフォーラムなどで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1442565101,"dir":"post/2015/","id":"4b227d61f33182579cd3edd0ac6c7c44","lang":"ja","lastmod":1442565101,"permalink":"https://blog.johtani.info/blog/2015/09/18/elasticsearch-2-0-0-beta2-released-ja/","publishdate":"2015-09-18T17:31:41+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0-beta2 released 本日（9/17）、Lucene 5.2.1ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0-beta2リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch unplugged - Networking changes in 2.0\nElasticsearchをローカルのマシンで起動します。 そして、昨日試したデータを削除するためにDELETE *を実行します。 すると、悲しそうな叫びを同僚が発していることに気づき、なぜそんなことになっているのか不思議に思うでしょう。。。\nElasticsearchはいつも、親しみやすいものでした。 複数ノードのクラスタがどのように機能するのかをテストするには、 ローカルのマシンでいくつかのElasticsearchのインスタンスを起動するだけでした。 起動したインスタンスはマルチキャストを利用して自動的にお互いを見つけて、1つのクラスタになり、負荷を共有し始めます。 しかし、これは親しみやすすぎました。 カンファレンスなどで、ローカルのマシンでElasticsearchを起動してみてください。 すると100ノードのクラスタに参加しているのがすぐにわかるでしょう。\nもうすぐリリースされる、2.0.0-beta1では、Elasticsearchが通信先を選択するネットワークの機能に関する変更があります。 ただし、これまで通り、簡単に開発者が経験できる機能も残っています。\nlocalhostへのバインド 以前、Elasticsearchはデフォルトで、利用可能なネットワークインタフェース全てにバインドしていました。 そこから、一番適したインタフェースをpublish_hostとして選択しようとします。 このアドレスはElasticsearchがクラスタの他のノードとやりとりするためのアドレスです。\nElasticsearch 2.0では、デフォルトでは、localhostにのみバインドします。 127.0.0.1（IPv4）と[::1]（IPv6）の両方にバインドしようとします。 また、どちらかのみの環境でも動作します。 この変更は、特に指定がない限り、Elasticsearchがネットワーク上の他のノードと接続しません。 本番環境に移行する場合は、network.hostパラメータを使って設定しましょう。 設定は、elasticsearch.ymlに記述するか、コマンドラインで指定します。\nbin/elasticsearch --network.host 192.168.1.5 bin/elasticsearch --network.host _non_loopback_ network.hostの全てのオプションについては、network settingsのドキュメントをごらんください。\nマルチキャストは廃止 Elasticsearch 1.xはネットワークの他のノードに接続・探索するためにマルチキャストを使用しました。 マルチキャストは魔法のような挙動です。。。 残念ながら、マルチキャストのサポートは良くも悪くもあります。 Linuxはローカルホストでマルチキャストの待ち受けをしていません。 OS/Xは構成されたアドレスの全てのインタフェースにマルチキャストで配信できます。 また、ネットワークによってはマルチキャストはデフォルトでは使用できなくなっています。\nElasticsearch 2.0は異なるアプローチを採用しました。 マルチキャストを廃止します（ただし、新たにプラグインとして提供します）。 代わりに、ローカルホストでは、Elasticsearchはtransport.tcp.portで指定されている範囲（デフォルトは9300-9400）の最初の5ポートに対してユニキャストを使用できるようにします。\nこれは、開発者のための、設定することなく自動的にクラスタを組むという機能を残しています。 しかし、本番に移行するときは、unicast hostsで次のようにリストを指定する必要があります。\ndiscovery.zen.ping.unicast.hosts: [ 192.168.1.2, 192.168.1.3 ] unicast hostsとしてクラスタにあるノードの全てのリストを指定する必要はありません。 少なくとも、マスタノードとして選出されるべきものを指定します。 巨大なクラスタでは、3つの専用のマスタノードを持っており、この3つをunicast hostsとして設定することを推奨しています。\nこれにより、開発の知識・経験が、私たちの推奨する本番でのネットワーク設定に、より近いものとなります。\nノード情報の変更 最後に、inet[/127.0.0.1:9200]といったシンタックスを廃止します。 これは、Elasticsearchがnodes-info APIなどで、使用していたIPアドレスのためのシンタックスです。 今は、RFCに準拠した形で表示します。 127.0.0.1:9200（IPv4）や[::1]:9200（IPv6）のようにです。\n質問がある場合は、ElasticsearchのWebフォーラムで質問してください。ベータはもうすぐです！（翻訳した時点で、すでにベータリリースされています。）\n","date":1440730890,"dir":"post/2015/","id":"0de0edbf2a506143c1739b12e94c0ef9","lang":"ja","lastmod":1440730890,"permalink":"https://blog.johtani.info/blog/2015/08/28/elasticsearch-unplugged-ja/","publishdate":"2015-08-28T12:01:30+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch unplugged - Networking changes in 2.0 Elasticsearchをローカルのマシンで起","tags":["elasticsearch"],"title":"Elasticsearch unplugged - 2.0におけるネットワークの変更(日本語訳)"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 2.0.0-beta1 released\n本日（8/26）、Lucene 5.2.1ベースのElasticsearch 2.0.0-beta1をリリースしました。 本リリースは469名のコミッターからの2,500以上ものpull requestを含んでいます。 pull requestのうち、約850が2.0のための新規のものとなります。\n注意事項 本リリースはベータリリースであり、テストを目的としたものとなります。 Elasticsearch 2.0.0-beta1は Elasticsearch 2.0.0 GAと互換性があるかどうかの保証はありません。\n本番環境には利用しないでください。\nElasticsearch 2.0.0-beta1のダウンロードおよび、すべての変更についてはリンクをごらんください。\nElasticsearch 2.0.0-beta1には次の新しい変更が含まれています。\nPipeline Aggregations：これは、他のaggregationsの結果に対するAggregationを実行できます（導関数、移動平均、Holt Winter予測アルゴリズムなども含む） ディスクやファイルシステムキャッシュにより適したより良いデータの圧縮 doc-valuesがデフォルトになったこと、マージ実行時のメモリ使用量の低減、フィルターキャッシュのためのroaring bitsetsなどにより、ヒープの使用率がより効率的に。 構造化された例外 最適化されたクエリ実行順序、フィルタの自動キャッシュ、より高速なクエリに書き換えられたparent-child 設定の代わりに、フィードバックループを使用した自動調整 トランザクションログへの書き込みがデフォルトで、アトミックでかつ冗長に 安全で明確で信頼性のあるタイプマッピング デフォルトでローカルホストでのみクラスタを構成 クラスタ状態の差分によりより高速に変更を伝搬 上記の変更以外にも、多くのElasticsearchおよびLuceneに対する継続的な変更が含まれています。 これらは、Elasticsearch 2.0をより安全に、より簡単に、より良いものにしています。 本リリースに関するより詳しい情報が次のブログにあるので、参考にしてください。\nElasticsearch 2.0.0.beta1 coming soon! The Great Mapping Refactoring Store compression in Lucene and Elasticsearch Better query execution coming to Elasticsearch 2.0 Out of this world aggregations Staying in Control with Moving Averages - Part 1 Staying in Control with Moving Averages - Part 2 The Delete by Query API Is now a plugin Elasticsearch unplugged - Networking changes in 2.0 また、Elasticsearch 2.0.0-beta1のドキュメントも参考になります。 特に、2.0での重大な変更点については必ずごらんください。\nCore plugins コアプラグインの開発の方法を変更しました。 公式にサポートしているプラグインは、現在elasticsearchのリポジトリに含まれています。 これにより、コアと一緒にテストされ、Elasticsearchと同じタイミングでリリースされます。 コアプラグインはElasticsearchと同じバージョン番号隣ます。 インストールは次のようになります。\nsudo bin/plugin install analysis-icu プラグインの新しいドキュメントは私たちのWebサイトのGuideにあります。\nCommercial plugins 私たちの商用プラグインもElasticsearchと同じバージョン番号となり、Elasticsearchと一緒にリリースされます。 ShieldやWatcherはすでに2.0.0-beta1が利用可能です。 インストールのコマンドはは次のようになります。\nsudo bin/plugin install license sudo bin/plugin install shield sudo bin/plugin install watcher MarvelおよびSenseに関する新しい情報もありますが、もう少しお待ちください。\n2.0.0-beta1の商用プラグインに関するドキュメントは次のリンクからごらんください。\nShield 2.0.0-beta1 Watcher 2.0.0-beta1 Elasticsearch Migration plugin Elasticsearch 2.0.0-beta1を試す前に、 既存のインデックスのアップグレードするためになにか行う必要があるかどうかを確認するためのElasticsearch Migration Pluginもリリースしました。 2.0.0では機能しない、問題のあるマッピングなどを見つけるために便利なプラグインです。\nこのプラグインの利用方法についてはElasticsearch Migration repositoryをごらんください。\n既知の問題 同じインデックスの異なるタイプに、同じ名前のipタイプのフィールドを追加した時に、問題があることがわかっています。 この問題は次のリリースでフィックスされます。詳細は#13112をごらんください。\nテストしましょう！ Elasticsearch 2.0.0 GAをすぐにリリースできるようにより多くのベータテスターをお待ちしています。\nぜひ、Elasticsearch 2.0.0-beta1をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)やWebフォーラムなどで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1440638952,"dir":"post/2015/","id":"744554499cb7880086fbd9b1f080e7e1","lang":"ja","lastmod":1440638952,"permalink":"https://blog.johtani.info/blog/2015/08/27/elasticsearch-2-0-0-beta1-released-ja/","publishdate":"2015-08-27T10:29:12+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0-beta1 released 本日（8/26）、Lucene 5.2.1ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0-beta1リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：The Delete by Query API Is now a plugin\nElasticsearchの2.0.0-beta1では、これまであった Delete by Query APIが削除され、 新しく Delete by Query pluginに置き換えられています。\nもし、Delete by Query を利用する場合、2.0にアップグレードしたあとは、プラグインをインストールし、ドキュメントに従ってください。\nbin/plugin install delete-by-query なぜプラグインに？ ElasticsearchのコアなAPIの品質を保つためであり、以前のDelete by Queryの実装は簡単にはフィックスできない大きな問題がありました。\n各リクエストのあとに、refreshを実行します。これは、削除されたデータが想定外に検索に出てこないようにするためです。\nまた、セグメントが大量にでき、マージが大量に発生し、ヒープが大量に消費されてインデキシングが劇的にスローダウンし、クラスタの複数のノードがクラッシュしてしまう状況も引き起こしました。 このクエリは、プライマリ、レプリカの両方で実行されるため、ことなるドキュメントを削除し、矛盾したレプリカ（データの破損）を引き起こしました。 アップグレードが不安定になります。これは、Delete by Queryリクエストがトランザクションログの中にクエリとして残るためです。そのため、アップグレードのあとに正確にパースされなかったり正確に実行されないかもしれません。例えば、インデックスエイリアスに対するリクエストで、それが削除された後の場合にこのようなバグが発生します。 対照的に、新しいプラグインは、安全な実装です。 scanとscrollリクエストでクエリにマッチしたIDを見つけ、そのIDを使って、bulk indexing APIで削除します。\nこの実装は、遅い必要があります。特に、クエリが多くのドキュメントを削除する場合です。 もし、多くのドキュメントをこのAPIを利用して削除する場合、アプリケーションをテストしてください。 そして、代わりにインデックス全体を消すようなアプローチに切り替えることができないか検討してください。\nDelete by Query pluginのドキュメントに、新しい実装についての違いなどのより詳しい説明があります。\nElasticsearch coreを最小限に プラグインに切り替えることは、簡単な決断ではありませんでした。 多くのユーザは問題なく、Delete by Queryを利用していました。 しかし、危険が常にそこにあり、些細とは言い切れない数のユーザが上記のような深刻な問題に遭遇していました。\nさらに、Elsticsearchのコアは信頼できるものでなければなりません。 他のコアAPIを利用して実装できる機能は、コアに含みません。特に、それがバグを含んでいる場合。 コアのすべての機能は強固であるべきで、Delete by Queryは人気があり、高性能ですが、そうではありませんでした。\n必要に応じて、このような難しいトレードオフの末、信頼性と品質を選びます。\nマッピングの削除の廃止 タイプのマッピングを削除する機能も2.0で廃止されます。 これは、同じフィールド名を、異なるフィールドのタイプで再利用した場合に、インデックスの破損を引き起こす可能性があるためです。\nしかし、Match All Queryで、Delete by Queryプラグインに対してタイプを指定することで、タイプのすべてのドキュメントを削除することはできます。 または、1つのインデックスに異なるタイプを複数含める代わりに、個別のインデックスに分割するようなアプローチに変更することを検討してください。\n","date":1440044644,"dir":"post/2015/","id":"5a9e950f4ac186925e5de978c5f72062","lang":"ja","lastmod":1440044644,"permalink":"https://blog.johtani.info/blog/2015/08/20/core-delete-by-query-is-a-plugin-ja/","publishdate":"2015-08-20T13:24:04+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：The Delete by Query API Is now a plugin Elasticsearchの2.0.0-beta1では、これまで","tags":["elasticsearch"],"title":"Delete by Query APIはプラグインへ（日本語訳）"},{"contents":"第11回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズさん、そして、Shayありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n今回は、CTOのShayが来日していたので、英語でいろいろと喋ってもらいました。 4月同様、サムライズムの@yusukeさんに テキスト翻訳していただき、大変助かりました。 今回はQAベースのトークだったのでちょっときつかったですね、申し訳ない。。。\nチェックイン数など チェックインした人：141名 キャンセルしなかった人：51名 でした。 今回はあらかじめ220名（全員が来たらキャパオーバー）としていたので、キャンセル待ちの人は 当日の午後にはいなくなっていた状態です。まぁ、こんなもんかな。結構入りましたね。ありがたいです。\nLT 今回は、少し趣向を変えて、4社の方達にLTをしていただきました。 Shayが来日しているのもあり、事前に英語でスライドを作っていただけると助かりますとお願いさせていただきました。 英語でスライドを作っていただいていたので、伝わりやすくて助かりました、スピーカーの方々ありがとうございました！\n（海外のユーザにもリンクを紹介しやすいので、英語でスライド作ってもらえるといろいろと知ってもらえるのかも。）\nElasticsearch and Recruit Technologies Co., Ltd. / 株式会社リクルートテクノロジーズ　守谷 純之介さん スライド：未定\nN-Gramと形態素のハイブリッドの話などをしていただきました。 @ITで連載もされてますね。ありがとうございます。\nリクルート全社検索基盤のアーキテクチャ、採用技術、開発体制はどうなっているのか (1/2) ElasticsearchとKuromojiを使った形態素解析とN-Gramによる検索の適合率と再現率の向上 (1/3) Shayからは、elasticsearch-hadoopがあるから検討してねと質問（お願い？）がありましたw。\nElasticsearch as a DMP / 株式会社インティメート・マージャー　松田和樹さん　@mats116 スライド：Elasticsearch as a DMP\nいくつかのデータソースからAEROSPIKE経由でelasticsearchにデータを登録しているようです。 Data Management Platformのエンジンの一部として、elasticsearchを利用しているようです。\nShayからの質問：「どの機能を使って関心のある単語を抽出していますか？」\n回答：「Significant Term Aggregation」です。\nShay：「おぉ、チェックしてみますw」。\nReal-time social big data analytics using elasticsearch / 株式会社ホットリンク宮田洋毅さん　@kakka_jp スライド：未定\nソーシャルメディアのデータを解析するのにelasticsearchにデータを入れて解析。 時間軸での解析やテキストマイニングなんかをしているみたいでした。 いろいろと独自のプラグインを作ってるようです。（興味あるなぁ）\nShayからの質問：「ノード数は？」「30ノードで30シャード」\nElasticsearch in Hatena Bookmark / 株式会社はてな　id:skozawa スライド：Elasticsearch in Hatena Bookmark\nはてなブックマークの検索の歴史（MySQL -\u0026gt; Sedue -\u0026gt; Solr -\u0026gt; Elasticsearch） はてなブックマークの検索（ユーザが利用）と社内利用と、ログ解析で利用してる Shayからの質問：「昨年会いましたよね？今はクラスタのサイズはどのくらいのサイズですか？」「メインクラスタは9データノード」\nOpen QA with Shay 思い出せるものだけ。。。（あとで追記します）\nElasticsearch 2.0の話 Pipeline Aggregationとか。 Spark Streaming対応してる？ まだ検討中 elasticsearch-hadoopってどんなもの？HDFSにインデックス作ったりするの？ いえ、Hadoopの入出力先としてelasticsearchが使える感じ 個人的にAWSのCloudSearchとAWSでElasticsearchはどっちがいい？ 時系列データはCloudSearchだと難しいだろうし、AWS上ならfound.noがあるよ！ PostgreSQLみたいに信頼性の高いデータストアを目指してる（まだ、プライマリデータストアには使わないで） その他、感想などのブログ Elasticsearch勉強会でLTしてきました | Intimate Merger Engineer Blog 『第11回elasticsearch勉強会』のまとめ #elasticsearchjp \u0008* [Elasticsearch] 第11回 Elasticsearch 勉強会へ参加してきた - 雑文発散(2015-07-28) 第11回 Elasticsearch 勉強会に参加したら英語力に危機感を覚えて最高だった まとめ 今回はShayが来日したので特別バージョンでした。 もっと英語を翻訳するサポートしないとですね、反省してます。。。ぜんぜん流暢じゃないしw\n次回は9月に開催予定ですが、12月にまたShayが再度来日する予定です。 丸1日のイベントを検討中で、Shay以外にも開発者が来日すると思います。 どんな話が聞きたい、どんな人と話をしたいなどあれば、コメントいただければ（対応できるかは。。。）\n勉強会のスピーカーは随時募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1438321313,"dir":"post/2015/","id":"73b8194ad8fce0cabb01cd21d5e18500","lang":"ja","lastmod":1438321313,"permalink":"https://blog.johtani.info/blog/2015/07/31/11th-elasticsearch-jp/","publishdate":"2015-07-31T14:41:53+09:00","summary":"第11回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第11回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.7.1 and 1.6.2 released\n本日（7/29）、Lucene 4.10.4ベースのElasticsearch 1.7.1およびElasticsearch 1.6.2 のバグフィックス版をリリースしました。 これらのリリースは稀ですが、データの欠損が発生する重要なバグのフィックスを含んでいます。 すべてのユーザにアップグレードを推奨します。\nダウンロードおよびすべての変更については次のリンクをごらんください。\n最新安定版：Elasticsearch 1.7.1 1.6系バグフィックス：Elasticsearch 1.6.2 問題のバグ(#12487)は、 同時に複数のノードが故障またはリスタートをした場合の非常にまれな状況で、 シャードのすべてのコピーがクラスタから削除されてしまう状況を発生させます。 このバグは1.5.0から含まれています。\nこのリリースはまた、IPv4アドレスのCIDRマスクのバグのフィックス、 Shieldユーザがmore-like-this APIを利用できないバグのフィックスなど、 いくつかの変更も含んでいます（詳細は更新リストをごらんください）。\nぜひ、Elasticsearch 1.7.1をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1438173353,"dir":"post/2015/","id":"100c0a69bea7f02a0f4540ecaa37d0e3","lang":"ja","lastmod":1438173353,"permalink":"https://blog.johtani.info/blog/2015/07/29/elasticsearch-1-7-1-and-1-6-2-released-ja/","publishdate":"2015-07-29T21:35:53+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.1 and 1.6.2 released 本日（7/29）、Lucene 4.10.4ベースのE","tags":["elasticsearch"],"title":"Elasticsearch 1.7.1 および 1.6.2リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.7.0 and 1.6.1 released\n本日（7/16）、Lucene 4.10.4ベースのElasticsearch 1.7.0およびElasticsearch 1.6.1 のバグフィックス版をリリースしました。 これらのリリースはセキュリティフィックスを含んでおり、すべてのユーザにアップグレードを推奨します。\nダウンロードおよびすべての変更については次のリンクをごらんください。\n最新安定版：Elasticsearch 1.7.0 1.6系バグフィックス：Elasticsearch 1.6.1 1.7.0が1.x系の最後のリリースとなります。 今後の新機能については、Elasticsearch 2.0以降で取り込まれる予定です。\nElasticsearch 1.7.0は小さなリリースですが、2つの重要なセキュリティフィックスと クラスタの安定化とリカバリに関する2つの重要な機能を含んでいます。\nセキュリティフィックス シャードアロケーションを遅らせる インデックスリカバリの優先度 セキュリティフィックス Elasticsearch 1.6.1 と 1.7.0 は次の2つのセキュリティフィックスを含んでいます。\nリモートコード実行の脆弱性 Elasticsearch 1.6.1より前のバージョンには、transport protocol（ノードとJavaクライアント間での通信に利用）により、 リモートでコードが実行される脆弱性があります。 これは、CVE-2015-3253でのGroovyに関係しています。\nGroovyのダイナミックスクリプティングがオフでも脆弱性があります。 アップグレードをしないユーザは、transport protocol のポート（デフォルトで9300）信頼したエージェントからのみの アクセスに限定することで、脆弱性から保護できます。\nこの問題をCVE-2015-5377としました。\nディレクトリ探索の脆弱性 Elasticsearch 1.0.0から1.6.0までのバージョンで、ElasticsearchのJVMプロセスによって読み込みが可能なファイルを 取得することができるディレクトリ探索攻撃の脆弱性があります。 アップグレードをしないユーザは、信頼できない場所からのSnapshot-Restore APIの呼び出しを防ぐためにファイアウォール、リバースプロキシやShieldを使用することができます。\nこの問題をCVE-2015-5531としました。\nシャードアロケーションを遅らせる Elasticsearch 1.6.0でSynced Flushingが導入されました。 これは、ノードのリスタート時に、更新が止まっているシャードのリカバリを劇的にスピードアップします。 しかし、この変更は、シャードの配置を無効にしている環境でのみうまく実行されます。 ノードが一時的にクラスタから外れている場合や予期せぬリブートの場合には役に立ちません。\nこのシナリオとは次のようなものです。\nノードの想定外のシャットダウン マスタがたのノードにシャードを再配置 各シャードが新しい場所にネットワーク越しにコピー その間に、外れていたノードが再度クラスタにジョイン マスタは新しいノードにシャードを再配置。新しいノードに存在する既存のシャードが全く再利用されない可能性がある ノードレベルとクラスタレベルの両方の並列的なリカバリを抑制しても、 この\u0026quot;シャードシャッフル\u0026quot;がクラスタに対して負荷をかける可能性があります。 これは、外れたノードが再度ジョインするのを単に待つことにより防げるかもしれません。\n待ちましょう！ Elasticsearch 1.7.0はindex.unassigned.node_left.delayed_timeout設定を追加しました。デフォルトでは1分です。 これは、ノードがクラスタから外れたとき、ほかのノードにこれらのノードを再配置するまでマスタが1分待つということです。 ノードがこの1分の間に復帰した場合、マスタはローカルにあるシャードを再度配置します。\nなぜ1分？ ノードがシャットダウンし、リスタートし、復帰するために十分な時間が1分だからです。 しかし、ノードが復帰しない場合にはまだ再配置が発生することを意味します。 デフォルト値を決定するのは難しいです。 この設定をどのくらいに減らすか、増やすかを決める必要があるかもしれません。\nこのデフォルト値は、config/elasticsearch.ymlファイルに設定できますが、インデックス設定の更新APIを使って設定することも可能です。\nこのデフォルトに関する知見をぜひフィードバックしてください。\nインデックスリカバリの優先度 1.7.0の2つ目の重要な機構はフルクラスタリスタートのような後に、 どの順番でインデックスをリカバリするかという優先度をつけることができるという機能です。\n電源故障による、ロギング用のクラスタのダウンを想像してください。 クラスタが普及した場合、500個のインデックスをリカバリするような場合、499個のインデックスのデータは古く、 500番目のインデックスが重要です。 もっとも最近作成されたインデックスがリカバリされるまで、インデキシングを待つというようなことはできません。\nこれまでは、インデックスはランダムな順序でリカバリされ、重要なインデックスがリカバリされるまで待つしかありませんでした。 1.7.0では、インデックスは優先度の順番でリカバリされます。 この優先度は次のプロパティで指定できます。\nindex.priority設定（大きな値が優先度が高い） インデックス作成日（新しいものが優先度が高い） インデックス名 既存のクラスタについて特に変更せずとも、最も最近作成されたインデックスが古いものよりも復旧されます。 古いインデックスの優先度を上げるためには、index.priority設定に0よりも大きな値を設定します。\nPUT important_index/_settings { \u0026#34;index.priority\u0026#34;: 5 } この設定は、存在するインデックスに対して更新できます。リカバリ中にもです。\nまとめ ぜひ、Elasticsearch 1.7.0をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1437546817,"dir":"post/2015/","id":"809925e891b0456231c374b09cbe4a90","lang":"ja","lastmod":1437546817,"permalink":"https://blog.johtani.info/blog/2015/07/22/elasticsearch-1-7-0-and-1-6-1-released-ja/","publishdate":"2015-07-22T15:33:37+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.0 and 1.6.1 released 本日（7/16）、Lucene 4.10.4ベースのE","tags":["elasticsearch"],"title":"Elasticsearch 1.7.0 および 1.6.1リリース（日本語訳）"},{"contents":"東京以外での勉強会の第2弾として、関西で勉強会を開催してきました。\nElasticsearch勉強会 in 大阪 Elasticsearch勉強会 in 京都 会場提供をしていただいた、Yahoo!大阪、はてなのみなさん、ご協力ありがとうございました！\nここからはいつものメモです。 ちなみに、大阪の勉強会に、@takuya_aさんと@5kozawaさんの両名にお越しいただき話をしていただきました。 なので、勉強会の内容はほぼ同一になります。\nIntroduction Elastic @johtani スライド：Introduction Elasticsearch\n初めての関西での勉強会ということで、ElasticsearchのOSSおよび商用プラグインの紹介をしてきました。 もちろん、Kibanaのデモもちょっとだけ。スプラトゥーンに関するデータをKibanaでちょっとだけ。 突貫でデータをかき集めたのでもう少し改良しないとですが。\nElasticsearch での類似文書検索と More Like This API 詳解 / 株式会社はてな　id:takuya-a スライド：Elasticsearch での類似文書検索と More Like This Query API 詳解\nElasticsearchのMore Like Thisのソースコードリーディングみたいな感じで、 内部でどうやって処理されているかの説明を詳しくしてもらいました。\n前のはてなエンジニアセミナーで話をされていた検索精度の件に絡んだ内容になっているかと。 （大阪で発表してもらった時より京都での発表が分かりやすくなってました。1日で改善されたのすごい！） MoreLikeThisだとチューニングつらいので、自分で作るためにTermVectorAPIでやってみたという流れかと。\n以下は発表後に出てきた質問のいくつかです。\nQ:MoreLikeThisに対してTermVectorで柔軟にできる？ A:TermVectorのAPIで統計情報が取れるので、それを使うことでさらなるデータの更新ができる。\nQ:TFとかの統計情報が必要なら、すべてインデックスをしたあとじゃないとちゃんとした値はとれないのでは？ A:TermVectorで取得したものをどうやって使うか\nQ:TermVectorAPi\u0026hellip;聞こえなかった A:。。。\nElasticsearchを用いたはてなブックマークのトピック生成 / 株式会社はてな　id:skozawa スライド：Elasticsearchを用いたはてなブックマークのトピック生成\nSignificant Terms Aggregationを活用してる話。 トピックページの生成のために、Significant Terms Aggregationをどうやって利用しているかなどのお話でした。\nトピックの集合の重複だったり、精度の判定方法とかいろいろ詳しく説明していただきました。\nQ:2011年と12年で11年の方が多いのは？ A:ブックマークの件数に比例\nQ:Significant terms aggsのsizeはいくつをつかってますか？ A:20を指定してます。\nQ:Yahooとかニュースをストップワードとしてますが、Yahoo自体のニュースに関してはどーしてるんですか？ A:本文とタイトルから別々に作っていて、タイトルからは弾かれますが、本文から作った時に出てきます。\nはてなブックマークにおける Elasticsearch の運用まわりの話 / 株式会社はてな　id:hagihala スライド：未定（おそらく公開される）\n体調が回復しきっていない中の発表ありがとうございました。 大幅に修正された資料が出てくるかなと。（ツイートできない数値がちらほらあったので）\nElasticsearchのクラスタの構成、どういった点で困ってたのでどういう調べ方をしたのか、どういった対処をしたのか。 どのあたりが次の課題かなどの話もありました。\n感想・反省点など 大阪、京都ともに30名弱の方の参加をしていただきました。ありがとうございました。 反省点としては、ハッシュタグを告知し忘れてました。。。\n勉強会はやはり、東京が異常に活発で、大阪や京都はまだそれほどでもないのかなぁとも。 大阪はエンジニアの人や会社も多い気がするんですが。私の告知の仕方もあるかもなぁと。 次回があれば、大阪での事例も聞きたいので、スピーカーをもっと探さないとなと。\n関連ブログなど 見つけたら、リンク追加していきます。\nElasticsearch勉強会 in 大阪/京都で発表しました \u0008* 「Elasticsearch での類似文書検索と More Like This Query API 詳解」というタイトルで発表しました その他（余談） 大阪のYahoo!さんは立地条件（梅田のすぐそば）がよく、\n夜景も綺麗でした。大阪城とかも見えてました。（夜景じゃないけど。。。）\n京都は祇園祭の真っ最中。\n水曜日はお休みをいただいて、観光してました。ちょっと日焼けが。。。 おかげで、リフレッシュできました。三十三間堂とか良かった:)\nあまり、関西に縁がない（大阪15年ぶり、京都10年ぶり）ので、 もっとユーザが増えて勉強会の機運が高まると嬉しいなと。:)\n","date":1437010857,"dir":"post/2015/","id":"dd6c32a722dc815273cd9ed8cd6c671b","lang":"ja","lastmod":1437010857,"permalink":"https://blog.johtani.info/blog/2015/07/16/kansai-1st-elasticsearch-jp/","publishdate":"2015-07-16T10:40:57+09:00","summary":"東京以外での勉強会の第2弾として、関西で勉強会を開催してきました。 Elasticsearch勉強会 in 大阪 Elasticsearch勉強会 in 京","tags":["勉強会","elasticsearch"],"title":"大阪と京都でElasticsearch勉強会を開催しました。 #elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：The Great Mapping Refactoring\nElasticsearchのユーザの悩みの最も大きなものの一つは、 タイプとフィールドのマッピングに関する多義性です。 この多義性は、インデックス時の例外やクエリ時の例外、 正しくない結果、リクエストからリクエストへ変化する結果、 また、インデックスの故障やデータのロスを結果として引き起こします。\nElasticsearchをより強固で予測可能な振る舞いをするようにする作業において、 フィールドやタイプのマッピングをより厳格でより信頼性を高くするかといったことに 多くの変更を費やしました。 多くのケースで、Elasticsearch v2.0で新しいインデックスを作るときにのみ、 新しいルールを強制し、これまでのインデックスに関しては後方互換性を保つようにします。\nしかし、幾つかのケースでは、先ほど説明したようなフィールドマッピングの コンフリクトなどが存在するため、それらを利用できないです。\nコンフリクトしたフィールドのマッピングをもつインデックスはElasticsearch v2.0にはアップグレードできません。\nもし、これらのインデックスのデータが必要ない場合は、インデックスを消せばいいです。 そうでない場合はマッピングを正しくして再度インデックスする必要があるでしょう。\nマッピングを正しく変更することは、私たちが簡単に決めることではありません。 ここからは、現在ある問題点と、私たちがどのように実装して解決したかについて説明します。\nフィールドマッピングのコンフリクト あいまいなフィールドのルックアップ タイプのメタフィールド アナライザ設定 index_nameとpath 同期的なマッピングの更新 マッピングの削除 2.0のための準備 フィールドマッピングのコンフリクト これまで、わたしたちはドキュメントのタイプは「データベースのテーブルのようなもの」と説明していました。 タイプの目的を説明する簡単な方法だったからです。 しかし、残念なことにこれは、真実ではありません。 「同じ」インデックスの「異なるタイプ」にある同じ名前のフィールドは、 内部的に、Luceneのフィールド名が同じものになります。\nもしerrorフィールドとして、ドキュメントタイプがapacheのものには数値（integer）を、 ドキュメントタイプがnginxのものには文字列（string）を割り当てた場合、 Elasticsearchは同じLuceneのフィールドに数値と文字列のデータをもつことになります。 このフィールドに対して、検索やaggregationを行う場合、おかしな結果を受け取るか、例外が帰ってくるか、 インデックスが破損することになります。\nこの問題を解決するために、まず、ドキュメントタイプの名前をフィールドの名前の前に追加することを考えました。 各フィールドは完全に別のものとなります。 このアプローチの利点はドキュメントタイプが実際のテーブルのようになることです。\nしかし、この方法には多くの欠点があります。\nフィールドは常に、他のタイプとは異なるものであると区別するためもしくは、複数のタイプに同じフィールドのクエリのためにワイルドカードをつけた場合、 ドキュメントタイプを前につける必要があります。 複数のドキュメントタイプに対して同じフィールド名で検索する場合、クエリを個別に発行しなければならなく遅くなります。 多くの検索で、既存の多くのクエリを壊してしまうために、単純なmatchやtermクエリの代わりに、multi-fieldクエリを使う必要があります。 圧縮の効率の悪さから、ヒープ利用量、ディスク使用量、I/Oなどが、増加します。 複数のドキュメントタイプに対するaggregationは、global ordinalの利点を利用できなくなるために、遅くなり、メモリの使用量も増えます。 解決方法 最終的に、同じインデックスの同じ名前を持つ全てのフィールドは、同じマッピングを持つ必要があるというルールを採用することに決めました。 ただ、copy_toやenabledのようなパラメータはタイプごとに指定することができるようになっています。 これにより、データの破損、クエリ時の例外そして、おかしな結果が発生する問題を防ぎます。 クエリとaggregationは現在でも高速なままで、圧縮率を最大化し、ヒープ使用量やディスク使用率の低減させます。\nこの解決方法の欠点は、個別のテーブルとしてタイプを扱いたいユーザが彼らの考え方を変える必要があるということです。 これは、思ったよりも問題ではありません。 実際には、多くのフィールド名はデータの明確なタイプを表現しています。 created_dateは常に、日付ですし、number_of_hitsフィールドはいつも数値です。 フィールドマッピングがコンフリクトしているユーザはデータを失ったり、おかしなデータを受け取ったり、データを欠損させています。 ベストプラクティスにユーザが従っているかどうかによらず、インデックス時に正しい振る舞いを強制することが現在の違いです。\nユーザの多くがコンフリクトしていないフィールドマッピングをもっていれば、 コンフリクトが起きた場合、技術がこれらのシチュエーションを扱うことが可能になると思いませんか？ そこにはいくつかの解決方法があります。\nタイプの代わりにインデックスを別々に 最も簡単な解決方法です。インデックスを別々のインデックスとし、実際のデータベーステーブルのようにします。 インデックスをまたいだ検索はタイプをまたいだ検索のように動作しますし、 ソートやaggregationも同じデータタイプへのクエリのように動作します。これまでと同じ制限です。\nコンフリクトしたフィールドの名前の変更 コンフリクトがごくわずかな場合、（Logstashやアプリケーションで使っているものも一緒に）よりわかりやすいフィールド名に変更することで解決できます。 例えば、2つのerrorフィールドがあった場合に、error_codeとerror_messageに変更します。\ncopy_toもしくはmulti-fieldsを利用 異なるドキュメントタイプのフィールドは別々のcopy_toを設定できます。 元のerrorフィールドはindexの設定にnoが設定してあり、全てのドキュメントタイプで無効化されていますが、 特定のタイプだけ、errorフィールドの値を数値のerror_codeフィールドにコピーすることができます。\nPUT my_index/_mapping/mapping_one { \u0026#34;properties\u0026#34;: { \u0026#34;error\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;no\u0026#34;, \u0026#34;copy_to\u0026#34;: \u0026#34;error_code\u0026#34; }, \u0026#34;error_code\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;integer\u0026#34; } } } 他のタイプでは文字列のerror_messageにコピーします。\nPUT my_index/_mapping/mapping_two { \u0026#34;properties\u0026#34;: { \u0026#34;error\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;no\u0026#34;, \u0026#34;copy_to\u0026#34;: \u0026#34;error_message\u0026#34; }, \u0026#34;error_message\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } 同様の解決方法としてmulti-fieldも使えます。\n各データタイプに対してネストしたフィールドに ときどき、Elasticsearchに送ったドキュメントやドキュメントがもっているフィールドを制御できない場合があります。 部分的なコンフリクトに加え、闇雲に、ユーザが送ってきたフィールドを受け入れると、マッピングが肥大化します。 タイムスタンプやIPアドレスをフィールド名に使うようなドキュメントがあると考えてください。\nnested フィールドにすることで、str_val、int_val、date_valというような各データタイプを利用できます。\nこのアプローチによって、次のドキュメントは\n{ \u0026#34;message\u0026#34;: \u0026#34;some string\u0026#34;, \u0026#34;count\u0026#34;: 1, \u0026#34;date\u0026#34;: \u0026#34;2015-06-01\u0026#34; } アプリケーションによって、次のようにフォーマットしなおす必要があります。\n{ \u0026#34;data\u0026#34;: [ {\u0026#34;key\u0026#34;: \u0026#34;message\u0026#34;, \u0026#34;str_val\u0026#34;: \u0026#34;some_string\u0026#34; }, {\u0026#34;key\u0026#34;: \u0026#34;count\u0026#34;, \u0026#34;int_val\u0026#34;: 1 }, {\u0026#34;key\u0026#34;: \u0026#34;date\u0026#34;, \u0026#34;date_val\u0026#34;: \u0026#34;2015-06-01\u0026#34; } ] } この解決方法は、アプリケーションサイドでより多くの作業が必要ですが、コンフリクトの問題とマッピングの肥大化の問題を同時に解決します。\nあいまいなフィールドのルックアップ 現在、フィールドの指定には\u0026quot;short name\u0026quot;、フルパス、ドキュメントタイプを前につけたフルパスが利用できます。 これらのオプションがあいまいさをもたらしています。 サンプルとして次のマッピングをご覧ください。\n{ \u0026#34;mappings\u0026#34;: { \u0026#34;user\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;title\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;blog\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;title\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;user\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;object\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;title\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } } } } } titleはuser.title、blog.title、blog.user.titleのどれでしょう？ user.titleはuser.titleまたはblog.user.titleのどちらでしょう？ 答えは「場合によります。」です。Elasticsearchが最初に見つけたものになります。 フィールドはリクエストごとに変わるため、各ノードでマッピングがどのようにシリアライズされたかに依存します。\n2.0では、フィールドを指定する時に、ドキュメントタイプを除いたフルパス名を使用するべきでしょう。\nuser.titleは、blogタイプのuser.titleを意味します。 titleは、userとblogタイプのtitleフィールドを意味します。 *titleはuser.titleとtitleフィールドの両方にマッチします。 userタイプのtitleフィールドとblogタイプのtitleの違いはどのように指定するのでしょう？\n指定できません。フィールドマッピングのコンフリクトで説明した変更により、 titleフィールドは両方のタイプで同じフィールドになります。 本質的にtitleと呼ばれる1つのフィールドになります。\nuser.やblog.のようなタイプのプレフィックスはタイプを指定することによるフィルタリングで効果があります。 クエリのblog.titleフィールドはblogタイプのドキュメントだけを検索し、userタイプのドキュメントを検索しません。 このシンタックスは誤解を招きやすいです。なぜなら、いつでも動作するわけではないからです。 aggregationやsuggestionはすべてのタイプに関する結果を含みます。 この利用のため、上記の例のあいまいさがあるので、タイプのプレフィックスはサポートしません。\n重要 short nameやタイププレフィックスを利用したpercolatorは更新する必要があります。\nタイプのメタフィールド すべてのタイプはメタフィールドを持っています。_id、_index、_routing、_parent、_timestampなどです。 これらのほとんどはindex、store、pathのような幾つかの設定をサポートしています。 これらの設定について次のようにシンプルにしました。\n_idと_typeは変更不可 _indexは、ドキュメントのもつインデックスを保存するためにenabled _routingはrequiredのみを指定 _sizeはenabledのみ _timestampはデフォルトで保存される _boostと_analyzerは廃止。古いインデックスのものは無視される ドキュメントのフィールドから_idと_routingと_timestampの値を抽出することができました。 この機能は廃止されます。これは、ドキュメントのパースとコンフリクトを起こすためです。 代わりに、これらの値はURLもしくはquery stringで指定可能です。\n_boostと_analyzerフィールドは例外で、すでにあるメタフィールドの設定は古いインデックスのものが採用されます。\nアナライザ設定 これまで、indexとsearchのアナライザがインデックス、タイプ、フィールド、ドキュメント（_analyzerフィールドで）の それぞれのレベルで指定可能でした。 同じフィールドに対して異なるanalysis chainの組み合わせができることにより、おかしな関連度を引き起こしていました。 フィールドマッピングのコンフリクトを解消することに加え、アナライザの設定も簡略化します。\nAnalyzedな文字列フィールドは、analyzer設定とsearch_analyzer設定（analyzer設定の値をデフォルトとする）を指定できます。index_analyzer設定はanalyzerとなります。 複数のタイプで同じ名前のフィールドがある場合、フィールドはすべて、同じアナライザの設定を持たなければなりません。 タイプレベルのデフォルト設定のanalyzer、index_analyzer、search_analyzer設定は廃止されます。 デフォルトアナライザはインデックスごとにインデックスのanalysis設定で設定します。これらはdefaultもしくはdefault_searchという名前で設定します。 ドキュメントごとの_analyzerフィールドはサポートしません。既存のインデックスのものは無視されます。 index_nameとpath index_nameとpath設定は（Elasticsearch v1.0.0から利用できる）copy_toによって置き換わりました。 既存のインデックスについてはこれらは機能しますが、新しいインデックスでは指定できません。\n同期的なマッピングの更新 現在、これまで存在していないフィールドを含むドキュメントをインデキシングするとき、 フィールドはローカルのマッピングに追加され、それから、マスターに変更（新しいマッピングをすべてのシャードに適用する更新）が送信されていました。 同時に2つのシャードに同じフィールドを追加することができます。 また、そのとき、異なる2つのマッピングがある可能性があります。 1つはdoubleでもう1つはlongだったり、stringとdateだったりと。\nこのような場合、マスターに最初に届いたマッピングが採用されます。 しかし、「負けた」マッピングをもつシャードでは、すでに異なるデータのタイプを利用しているため、 これを利用し続けます。 そのご、ノードをリスタートしたときに、シャードが別のノードに移動し、マスターにあるマッピングを適用します。 このとき、インデックスが破損したりデータを失ったりします。\nこれを防ぐために、シャードはインデキシングを続ける前に、新しいマッピングがマスターによって採用されるかどうかを待つようになりました。 これはすべてのマッピングが安全に更新されます。 新しいフィールドをもっているドキュメントをインデキシングすると、前よりも処理が遅くなるでしょう。 受け入れられることを待つ必要があるためです。 しかし、クラスタの状態の更新処理のスピードが次の2つの新しい機能によって大きく改善されています。\nクラスタ状態の差分：可能であれば、クラスタの状態の変更はクラスタ状態全体の変更ではなく、部分的なものとする。 シャードへのリクエストの非同期化：シャードアロケーション処理中に、マスタノードは、 割り当てられていないシャードのコピーの日付が最新のものを持っているかを見つけるために、リクエストをデータノードに対して送信します。 ここで、クラスタ状態を変更する呼び出しがブロッキングで行われていました。v1.6.0から、このリクエストはバックグラウンドで非同期で実行されます。 これにより、マッピング更新のようなペンディングタスクをより早く処理できるようになります。 マッピングの削除 （そのタイプのドキュメントがある場合）タイプマッピングを削除できないようにします。 マッピングを削除した後に、削除されたフィールドの情報は、Luceneレベルでは存在し続け、 もし、後から同じ名前のフィールドが追加されたときにインデックスの破損を引き起こします。 そのようなマッピングは残しておくか、新しいインデックスに再インデックスすることができます。\n2.0のための準備 マッピングがコンフリクトしているかどうかを決めることは、手動で行うには慎重に行う必要があります。 私たちは、Elasticsearch Migration Pluginを提供します。 これは、2.0で非推奨になったり廃止された機能を利用しているかどうかを見つけるために役に立つでしょう。\nもし、コンフリクトしたマッピングを持っている場合、 正しいマッピングを持つ新しいインデックスにデータを再インデックスするか、 必要ないなら削除します。 これらのコンフリクトを解決しない限り2.0にはアップグレードできないでしょう。\n","date":1436346691,"dir":"post/2015/","id":"ee4ff9e4e8a1948795e26af2f3f8a30f","lang":"ja","lastmod":1436346691,"permalink":"https://blog.johtani.info/blog/2015/07/08/great-mapping-refactoring-ja/","publishdate":"2015-07-08T18:11:31+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：The Great Mapping Refactoring Elasticsearchのユーザの悩みの最も大きなものの一つは、 タイプと","tags":["elasticsearch"],"title":"Mappingのすばらしいリファクタリング（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 2.0.0.beta1 coming soon!\nElasticsearch 2.0.0.beta1のリリースの準備をしています。 これは、Lucene 5.2.1に含まれる多くの改善が利用できるようになります。 このリリースに関するいくつかの機能は次のようなものです。\nPipeline Aggregations 差分や移動平均、他のAggregationsの結果に対する series arithmeticのようなaggregationが利用可能になります。 この機能は、これまでは、クライアントサイドで実行する必要がありました。 しかし、この計算をより強力な解析クエリを構築してElasticsearchで 実行することができるようになります。 クライアントのコードをより簡潔にすることができます。 これにより、予測解析や異常検知のようなことができるようになります。\nQuery/Filter merging Filterはなくなります。全てのフィルタは、クエリになります。 クエリコンテキストで利用されると、効率的に関連度スコアを計算し、 フィルタコンテキストで利用されると、単に、 マッチしていないドキュメントを除外する（今のフィルタのようなもの）だけです この変更は、クエリ実行が自動的に、より効率的な順番で実行されるように 最適化されることを意味します。 例えば、フレーズやgeoクエリのような遅いクエリは まず、近似フェーズを実行し、それから、より遅い実際のフェーズが 結果に対して行われます。 フィルタコンテキストにおいて、頻繁に利用される条件は自動的にキャッシュされます。\nConfigurable store compression index.codec設定により、高速化のためのLZ4圧縮（default）か インデックスサイズを小さくするためのDEFLATE（best_compression）を 選択できます。これは、ロギングでとくに役に立ちます。 これにより、古いインデックスオプティマイズする前にbest_compressionに 変更できます。\nこれらに関するブログ記事がすぐに公開されるでしょう。\nPerformance and resilience 以降では、新しいメジャーリリースに関して簡単に紹介します。 2.0の変更の多くは内部の機能に関するものであり、 直接ユーザに関連するわけではないからです。\n新しいメジャーバージョンのテーマは、パフォーマンス、安定性、 堅牢性、予測可能性、そして使い勝手の良さです。\n物事が予測した通りに動作する 何か問題があった場合に、Elasticsearchから役立つフィードバックがある ローレベルの設定を扱う必要はなく、Elasticsearchが良い設定を決定する これらに加え、データがより安全に これらの目標は完全ではありません。 まだ、多くの改善があります。しかし、2.xブランチで、 すでに500コミットを超える大きな改善が実施されています。\non-diskの doc valuesをデフォルトで利用（これまではfielddata）。 ヒープ使用量を減らして、スケーラビリティを向上 セグメントマージ処理中のメモリ使用量の削減 normsの圧縮率の改善。ヒープスペースを利用している大きな処理のひとつだったため。 全てのリクエストの後に、transaction logをfsyncすることで、デフォルトで耐久性を向上 全てのファイル変更をアトミックに（部分的なファイルの書き出しはなし） マージを自動で制限 フレーズクエリやスパンクエリを高速化 フィルタキャッシュをより効率化するための圧縮されたビットセット クラスタ状態の差分更新 構造化されたJSON形式の例外 よりきめ細かいLuceneのメモリレポート デフォルトではlocalhostにのみバインド。開発のノードが他のクラスタにジョインするのを防ぐ parent/childのクエリ実行最適化のためにリライト Java Security Managerで必要最小限なパーミッションで実行 全てのコアなプラグインをelasticsearchリポジトリに移行し、Elasticsearchのバージョンに同期してリリースされる予定 アップグレード前に メジャーバージョンのアップグレードは問題のあるものを一掃する機会を与えてくれます。 できる限り、これらの変更をアップグレードするために、簡単な方法を提供しようとしています。 しかし、Elasticsearch 2.0にアップグレードする前に、必要な処理が2つあります。\n1つ目は、フィールドとタイプマッピングに関することです。 mapping APIは、現在、それほど厳密ではありません。 内蔵された保護機構を提供する代わりに、ユーザがベストプラクティスを知っていると信頼していました。 2.0では、mappingはより厳密で安全ですが、いくつかの変更では、後方互換性を保っていません。 詳細についてはThe Great Mapping Recatoringをごらんください。\n2つ目はElasticsearch 0.20以前のユーザに関する変更です。 これは、Lucene 3.xを使っています。 Elasticsearch 2.xはLucene 5をベースにしています。 Lucene 5はLucene 4.xによって作成されたインデックスの読み込みはサポートしていますが、 Lucene 3.xに関してはサポートしていません。\nElasticsearch 0.20以前のバージョンによって生成されたインデックスを持っている場合、 Elasticsearch 2.xのクラスタをスタートすることはできません。 これらの古いインデックスを削除するか、Elaticsearch 1.6.0以上に含まれている upgrade APIを使用してアップグレードする必要があります。\nupgrade APIの実行は2つのジョブを実行します。\n古いLuceneフォーマットのセグメントを最新のフォーマットで書き換えます Elasticsearch 2.xによって読み込めるようという印をインデックスに追加します 全てのセグメントを最新バージョンにアップグレードするのも良い案ですが、 アップグレード前に必要な処理を最小限に抑えることも可能です。 （Lucene 3.xのセグメントだけをアップグレード） その場合は、only_ancient_segmentsパラメータを指定します。\nElasticsearch Migration Plugin Elasticsearch 2.0 に移行する前に、インデックスがアップグレードが必要なのか、 ほかになにかするべきことがあるのかをチェックする助けになる Elasticsearch Migration Pluginをリリースしました。\nまず、プラグインをインストールします\n./bin/plugin -i elastic/elasticsearch-migration プラグインのインストール後はノードのリスタートは必要ありません。\n以下のリンクをブラウザで開きます。\nhttp://localhost:9200/_plugin/migration\n（localhost:9200はインストールしたホスト名に変更してください。）\nMigration pluginに関してバグやご意見がある場合は、GitHubのIssueにお願いします。\n","date":1436250300,"dir":"post/2015/","id":"f887e1aabf801e351bfb39698f208af1","lang":"ja","lastmod":1436250300,"permalink":"https://blog.johtani.info/blog/2015/07/07/elasticsearch-2-dot-0-0-dot-beta1-coming-soon-ja/","publishdate":"2015-07-07T15:25:00+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0.beta1 coming soon! Elasticsearch 2.0.0.beta1のリリースの準備をしています。","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0.beta1リリース間近（日本語訳）"},{"contents":"4ヶ月前に、Found joined our team at Elasticをアナウンスしました。 Foundの素晴らしいチームと一緒に仕事をしていますが、彼らによって、より素晴らしい hosted Elasticsearchを提供することになりました。\n私たちがともに密接に働くことにより、本日（2015/7/1）、 新しい2つのFoundを提供することになりました。 Found StandardはこれまでのFoundの機能に加え、さらに低価格を提供します。 Found Premiumは、SLAサポートと、ShieldやWatcherを将来Found上で提供します。\nFound Standard Foundは素晴らしいです。専用のElasticsearchクラスタ、簡単なスケール、 ビルトインのセキュリティそして、時間単位での課金などを持っています。 私たちは、hosted Elasticsearchを探している方に、 Foundが適したソリューションであると思っていますし、 すべての方に利用できて手頃な価格であるということを確信したいと思っています。\n本日（2015/07/01）からFoundの価格をかなり低価格にし、 月額50ドル以下でhosted Elasticsearchを簡単に試してもらえるようにしました。\n価格を下げることは正しい重要なステップですが、 Foundを利用している全ての人に、より良い経験を持っていただきたいと考えています。 低価格化と一緒に、free backupsとbuilt in SSDもFoundで提供を始めることになります。\nFoundの重要な特徴の一つが、高可用性のために、クラスタをいくつのデータセンターに持つかを 選択できることです。 データは重要です。これが正しい選択でユーザの助けになると考えています。 これにより、私たちの価格は、複数のデータセンターにより安価に配置することができます。\nまた、KibanaもElasticsearchのデータを可視化する素晴らしい方法だと考えています。 Kibana 4が最新バージョンですが、 これは、サーバサイドコンポーネントを持っています。 これは、サービスとしてこれを提供するために、追加の料金がかかることを意味します。 Foundチームが築いた素晴らしい基盤とKibanaチームの努力により、 hosted Elasticsearchクラスタで無料のKibana 4を7月15日より提供することになりました。\nFound Premium また、私たちは、オープンソースプロダクトに関してサブスクリプションを提供していますが、 Found Standardに対しても提供することになりました。 これが、Found Premiumです。\nフォーラムベースのサポートよりもSLAベースのサポートを望んでいる場合、 プロダクトを開発しているチームからのサポートを受けることができるオプションを 提供し始めました。 クリティカルなイベントを持っていたり、私たちのプロダクトに関する 問題を予測するためのベストなヘルプやガイダンス、アドバイスを探しているような場合にサポートします。\nさらに近い将来、サブスクリプションの一部として、Shield（Elasticasearchのセキュリティプラグイン）やWatcher（アラーティングプラグイン）が利用できるようになります。\n私たちのチームがともに働き、多くのことを可能にし、すばらしい仕事をユーザに提供したかを 将来も楽しみです。 私は非常に誇りに思っていますし、気に入っていただけたらと思っています。 ぜひ、7/15のWebnarに参加してくわしい話を聞いていただき、疑問を解消してください。\n","date":1436250000,"dir":"post/2015/","id":"9cc2a0b6c8be1405cddcdeb4487c59fe","lang":"ja","lastmod":1436250000,"permalink":"https://blog.johtani.info/blog/2015/07/07/we-just-made-found-more-awesome-ja/","publishdate":"2015-07-07T15:20:00+09:00","summary":"4ヶ月前に、Found joined our team at Elasticをアナウンスしました。 Foundの素晴らしいチームと一緒に仕事をしていますが、彼らによって、より","tags":["elasticsearch","found.no"],"title":"さらに進化したFound（日本語訳）"},{"contents":"JustTechTalk#02 形態素解析のあれやこれや@ジャストシステム\nに参加してきました。 ジャストシステムさんの形態素解析器JMATの話とKagome、Janome、Kuromoji.js、ssslaの開発者の パネルディスカッションでした。\nということで、いつものメモです。\nジャストシステムの形態素解析その２（機械学習編） JMATの話\n前回は辞書の話 今回は学習の話 教師あり/教師なし\nJMATは教師あり 教師なしは研究段階 ラティス構造を辞書ベースで構築して、コストの総和が最小の経路を求める\n連接、単語生成とか。 学習は3フェーズ\nベース、能動、部分アノテーション ベース 300万文のコーパスから1万文のみを利用（なぜ？今から説明） 64GBマシン買ってみたけど、複数実験するには追いつかない オンライン学習がメジャーでない時代に作り始めたので、つかってない CRF学習器を改善 結果として50万文くらいで精度が良くなる 辞書チームからNGがでて、方向転換 方向転換した結果が3つのフェーズらしい ピタジョブに採用？ 疑問 \u0008* JMATって、Webの検索の前処理とか分類とかに主に利用するのかな？\nATOKでもこのノウハウって利用してるんかな？ 辞書もあるらしいけど、辞書更新されると学習器のデータとかどーなるんだろ？ 形態素解析器の実装言語Talkについて kuromoji.jsの@takuya_aさん\nTyped Arrayサポートが高速にできてる理由でもあるらしい Kagomeの@ikawahaさん\nGoはいろいろないらしい Janomeの@moco_betaさん\nsssla（茶筌のRuby clone）\nなんで作ったの？\n形態素解析のライブラリ「解析部分」はNLPのHelloWorldだから なんで、その言語？\nPython 3系は文字列とバイト配列の扱いがすごく楽！ その言語で困った点は？\nGoだと、辞書を内包するのが大変 JSは苦労したところしかない（1hくらいしゃべれるぞ！）。基本的なデータ構造とかもない Pythonはパフォーマンスを考えないと Ruby（1.6だったので）もパフォーマンスが その言語を開発するときに必須のものは？\nGoはとくにない。エディタはどれでもOK browserifyが便利 \u0008* ほかの人たちの言語をdisってください * JSは論外。Pythonのコードフォーマッターが揺れるのが。。。Rubyはバージョンが。。。 * Goはブラウザで動かない。Pythonもブラウザで動かない。Rubyも(ry * ほかのは触ったことないので。。。 * Pythonは2.xか3.xか決めてくれ！\nなんで、Kuromojiベースなの？ Java読みやすいから。 MeCabとKuromojiの違いは？ 未知語の処理が結構違う 感想 きれいなロビーで良かったのですが、マイクがあると嬉しかったかもしれません。 前回の辞書の話も聞いてみたかったかも。\n","date":1436147341,"dir":"post/2015/","id":"18b7998a871950ebc36c415a53630477","lang":"ja","lastmod":1436147341,"permalink":"https://blog.johtani.info/blog/2015/07/06/attend-justsystem-techtalk-no2/","publishdate":"2015-07-06T10:49:01+09:00","summary":"JustTechTalk#02 形態素解析のあれやこれや@ジャストシステム に参加してきました。 ジャストシステムさんの形態素解析器JMATの話とKagome、Janome、","tags":["勉強会"],"title":"JustTechTalk#02 形態素解析のあれやこれや@ジャストシステムに参加しました。"},{"contents":"ひさびさに、勉強会メモ。 Hatena Engineer Seminar #5 @ Tokyoに当選したので行ってきました。\nいつもは近寄らないオシャレな街をドキドキしながら行ってきました。\nということで、簡単なメモです。\nはてなブックマーク全文検索の精度改善 id:takuya-a 問題：検索精度がよくない 京都で検索 →　「ポーランドの京都」「京都大学のまるまる教授」のようなもんがヒット 京都っぽいエントリが出て欲しい。 京都っぽい？？？ 問題点をブレイクダウン 課題 クエリ考えるの大変だよね 順序が新着順なのが辛い 適合率と再現率の両立 そして（ドラムロール）、できました！（さすが）\nアイデア：はてブのタグを利用する。 関連キーワードを抽出して、クエリ拡張する。\n関連キーワードとは？ タグ検索する 検索にヒットしたTerm Vectorsを取得 特徴語をTop25件取得 もっともスコアが高いタームを特徴語とする 英語のストップワードとかが問題点となってたり。 →Dynamic stop word listというのを利用して排除（IDF、RIDF、Gain） 今後の課題 再現率の向上 解析用のフィールド・辞書を追加（精度向上や解析ミスなど） トークに出てきた機能など トークに出てきたElasticsearchの機能については、こんなツイートをしてたので、参考にしてもらえれば。\nこれのkuromoji_stemmerを使ってるっぽい？ #hatenatech / elastic/elasticsearch-analysis-kuromoji - https://t.co/3F2sBYXLPH\n\u0026mdash; Jun Ohtani (@johtani) 2015, 6月 16 #hatenatech Term Vectors APIのドキュメントはこちら - https://t.co/HhBmTDr46i\n\u0026mdash; Jun Ohtani (@johtani) 2015, 6月 16 #hatenatech min_score - https://t.co/Sc0exzJRC1\n\u0026mdash; Jun Ohtani (@johtani) 2015, 6月 16 個人的な疑問 Q：クエリにヒットするタグがそもそもなかったら？\nはてなブックマークに基づく関連記事レコメンドエンジンの開発 id:skozawa 課題：一部のエントリに対して関連記事が出ない タグがない記事について関連エントリが出ない＝既存はタグを利用している 例：レシピで考える\n現行システム ユーザがつけたタグ情報を利用してMoreLikeThisで計算 新規システム 類似記事検索 特徴語の抽出 特徴語を分類 関連記事検索 関連記事をスコアリング 個人的な疑問 Q：毎回計算してるのかな？記事登録とかされたタイミングでやってるのかな？ Q：Termの精度などどうなんだろ？\n『BrandSafe はてな』のアドベリフィケーションのしくみ id:tarao BrandSafeはてな：とか。 広告の配信先をフィルタリング\n複数の素朴なフィルタの組み合わせ→AdaBoost\n個人的な疑問 Q：海外とかもいけるのかな？\nまとめと感想 ということで、簡単なメモでした。ピザごちそうさまでした！ 聞いてて少し思ったのは、データ量があるサイトだからうまくいく手法だというのもあるんだろうなというところでした。 あとは、クエリを暗に改善するのとは別に、サジェスト的に表示するのにも使えたりするかも？と思ってみたり。 できるかどうかはわからないですが。。。\nElasticsearchをいろいろと活用してもらってるのがわかって、楽しい勉強会でした。 もっともっといろんなところで宣伝してくださいw\n今日の勉強会を聞いて、俄然、京都・大阪でElasticsearch勉強会を開催したい気になってきました。 特に大阪に知り合いがいないので、だれか紹介してもらえると嬉しいです。 お待ちしてます。\n","date":1434468093,"dir":"post/2015/","id":"ddab6357ff522c0c956ebd7669e83454","lang":"ja","lastmod":1434468093,"permalink":"https://blog.johtani.info/blog/2015/06/17/attend-hatena-engineer-seminar-5/","publishdate":"2015-06-17T00:21:33+09:00","summary":"ひさびさに、勉強会メモ。 Hatena Engineer Seminar #5 @ Tokyoに当選したので行ってきました。 いつもは近寄らないオシャレな街をドキドキしながら行ってきました。 と","tags":["勉強会"],"title":"Hatena Engineer Seminar #5 @ Tokyoに参加しました。 #hatenatech"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.6.0 released\n本日（6/9）、Lucene 4.10.4ベースのElasticsearch 1.6.0をリリースしました。 このリリースはElasticsearchの最新の安定バージョンとなります。 また、素晴らしい新機能がいくつか追加されています。\nsynced flushによるリスタートの高速化 \u0008* シャード配置は保留中のタスクをブロックしない レスポンスボディのJSONのフィルタリング 共有ファイルシステムリポジトリに対するセキュリティフィックス 古いインデックスのためのUpgrade API Kibanaユーザのためのハイライトの強化 Windowsユーザのためのmlockall より詳細なスクリプト設定 すべての変更リストとダウンロードはこちらをごらんください。\nsynced flushによるリスタートの高速化 1.6.0より前のバージョンでは、メンテナンスやローリングアップグレード時の ノードの再起動で、必要であるかどうかに関わらず、多くの場合、 ノードのすべてのシャードのすべてのデータを再度コピーする必要がありました。 この新しいsynced flush機能により、 sync-flushされたインデックスに対して、既存のデータを再利用し、 より早くクラスタを正常な状態にすることができるようにします。\nここで、この変更以前にどのように動いていたかを説明します。 すでにあるレプリカシャードは、ノードがリスタートした後に、 プライマリから復元するときに、 最初のステップはプライマリにあるセグメントとレプリカにあるセグメントを 比較することです。そして、セグメントに違いがあった場合にコピーされます。 問題は、セグメントプライマリのセグメントのマージと レプリカのセグメントのマージが別々に起こっており、 各シャードのセグメントが完全に異なるが、 それらが同じデータを持っているという点です。\n新しいsynced-flush機能では、sync_idがプライマリと レプリカシャードに、シャードのコンテンツが同一であるという判別するために、 書き込まれます。これは、リカバリがセグメントの比較のステップを スキップできることを意味します。 リカバリのスピードを高速にします。\nsynced flushはアイドル状態のインデックスで自動的に実行されます。 直前の5分間でデータが登録、更新削除されていないインデックスに対してです。 これは、ロギングのユースケースで特に役に立ちます。 機能のインデックスはインデキシングがストップしたあとの5分で自動的に syncされるでしょう。\nノードのリスタートやクラスタのリスタートが必要で、 自動的に発生するsyncを待てない場合は次のようなことが可能です。\nインデキシングを停止（実行中のリクエストが停止するのも待つ） シャードのアロケーションを停止 synced-flushリクエストの発行 ノードのリスタート シャードのアロケーションの再開 クラスタの状態がグリーンになるまで待つ インデキシングの再開 NOTE: \u0026ldquo;シャードのアロケーションを停止\u0026quot;のステップが必要です。 これがない場合、Elasticsearchはノードの再起動が始まると、 異なるノードにシャードの再配置を始めます。 これは、新しいノードにシャードデータの全てをコピーする必要があります。\nドキュメントのインデキシング、更新、削除のあとに最初のフラッシュが 発生したときに、 シャードのsync_idが自動的に無効化されます。 詳細については#11336と#11179をごらんください。\nシャード配置は保留中のタスクをブロックしない 多数のノードやインデックスを持っているユーザは クラスタ全体のリスタートのあとのシャードのリカバリで、 長い間、リカバリが止まって見えることに気づいたかもしれません。 これらのリカバリが止まって見える間は、クラスタ設定の更新のような軽微なアクションでさえ、 例外が発生したり、その設定が反映されるまでに長時間かかるといったことが起きていました。 この問題の兆候は保留中のタスクのキューが大きくなることです。\nこれらの遅延の原因はシャードの配置のプロセスにあります。 配置されるべきシャードのコピーを 持っているのがどのノードかを全てのデータノードに聞きます。 多くのシャードや遅いディスクを持ったデータノードは 反応するのに時間がかかります。 特に、シャードのリカバリがすでにI/Oを利用しているような時です。 このバージョン以前のものは、シャード情報のためのリクエストを 同期的に処理していました。 クラスタ状態の更新はアロケーションプロセスを続けるために 必要な情報を待っている間、ブロックされます。\n#11262での変更は この情報のためのリクエストを非同期にします。 クラスタ状態の更新はこのタスクによってブロックされません。 これは、保留中のタスクがより早く処理でき、 クラスタが変更に対してより早く反応できます。 処理中のshard infoリクエストの数は number_of_in_flight_fetchキーとしてcluster-health APIで取得できます。\nさらに、シャードがある理由で復旧に失敗すると、 クラスタは、シャードのリカバリが成功するまで、同じノードに対して シャードをアロケーションしないようにします。\nレスポンスボディのJSONのフィルタリング Elasticsearchは全ての情報を返します。 例えば、検索リクエストは_index、_type、_id、 _score、_sourceを返します。 しかし、全ての情報が必要でない場合があります。 また、これらのデータを遅いネットワークで転送することは 遅延の原因となります。\nユーザはこの検索メタデータを無効にするための特殊な設定を 行ったり、他のAPIのレスポンスのフォーマットを コントロールするための設定があります。 #10980の変更で、任意のレスポンスボディのJSONに対して、 必要な要素だけを取得する機能が追加されました。 filter_pathパラメータを使用します。\n例えば、検索リクエストからはtotal数と、各要素のhitsの配列を欲しい場合、 次のように指定します。\nGET _search?filter_path=hits.total,hits.hits nodes-info APIから各ノードのhttp_addressだけを取得したい場合は、 ノード名の部分にワイルドカード(*)を使用します。\nGET _nodes?filter_path=nodes.*.http_address 単一の*がJSON階層の1つの階層に対しての ワイルドカードとして機能します。 2つの**は複数階層に対してとなります。 複数のフィルタはカンマ区切りで指定可能です。 詳細についてResponse filteringをごらんください。\n共有ファイルシステムリポジトリに対するセキュリティフィックス 本リリースはsnapshot-restoreで使われる 共有ファイルシステムリポジトリに関するセキュリティ強化の変更が含まれます。 現在、Elasticsearchのユーザは、Elasticsearchプロセスによって書き込み可能 任意のディレクトリに.snapshotファイルを書き込むことができます。 #11284の変更で、リポジトリのために使用できるディレクトリを 強制的に指定できるようになりました。 適切なディレクトリがconfig/elasticsearch.yml設定ファイルの path.repoに指定される必要があります。\n次のように設定されたElasticsearchインスタンスはこのセキュリティ問題に対して影響を受けにくいです。\nrootではなくelasticsearchユーザとしてElasticsearchを実行 elasticsearchユーザがdataディレクトリに対してのみ 書き込み権限を持っていて、共有ファイルシステムリポジトリに対しても利用できる ファイアウォールやプロキシ、Shieldを使って、snapshot APIの実行を任意のユーザから実行されるのを防いでいる この問題をCVE-2015-4165としています。\n古いインデックスのためのUpgrade API Elasticsearch 2.0以降では、 Lucene 5ベースとなり、Lucene 3 （Elasticsearchのバージョンでは0.90以前） によって書き出されたセグメントを含んだインデックスを読み込むことが できなくなります。 これらの「古いインデックス」はLucene 4にアップグレードする必要があり、 2.0-compatibleとして印をつける必要があります。 そうしなければ、Elasticsearch 2.0に以降できないでしょう。\nupgrade APIは 、最新のLuceneフォーマットにインデックスにある全てのセグメントを アップグレードするためにすでに利用できます。 また、最新のフォーマットは性能向上やバグフィックスといった利点もあります。 さらに、2.0-compatibleとして古いインデックスをマークする設定も 書き込むことができます。 さらに、upgrade_only_ancient_segmentsオプションが Lucene 3のセグメントだけをアップグレードするために利用でき、 移行前の必要な処理を減らすことができます。\nKibanaユーザのためのハイライトの強化 KibanaユーザはElasticsearchのハイライトについて2つの点で問題を見つけていました。\nワイルドカードでフィールド名を指定した場合に、ハイライトに適さないフィールドも帰ってくる（日付や数値のフィールドなど） 古いインデックスが非常に大きなターム（\u0026gt; 32kB）を含んでいて、ハイライトが失敗する。 最近のバージョンでは、これらの大きなタームはインデックス時に除去される #11364の変更で これらの問題が修正されました。 ワイルドカードを利用したフィールド名では、stringフィールドのみを返し、非常に長いタームによる例外は無視するようになります。\nWindowsユーザのためのmlockall 速いGCはノードの安定性と性能について重要です。 小さなバイトのヒープでさえ、ディスクにスワップすることを許可してしまうと、GCに対して大きな影響が出てしまいます。 ですので、これらのコストは排除されるべきです。\nLinuxユーザはbootstrap.mloclall設定による恩恵を受けています。 これは、RAMにJVMのヒープを起動時にロックします。 #10887では、同様の機能をWindowsユーザにも提供します。\nより詳細なスクリプト設定 Scriptsはリクエストにインラインで指定できます。 .scriptsインデックスにインデックスもでき、config/ディレクトリ配下にファイルとして保存もできます。 これまでは、インラインかインデックスされたスクリプトの両方を同時に有効無効にすることが選択できましたが、 .scriptsインデックスをプロキシやShieldで保護することもできました。\n#10116で追加されたより詳細なスクリプトの設定で、インラインか、インデックスされたものか、ファイル化を個別に言語ごとに設定できるようになりました。 また、例えば、search APIではスクリプトを許可するが、update APIでは許可しないといったような設定も可能です。\n最後に ぜひ、Elasticsearch 1.6.0を試してみてください。 そして、感想をTwitter(@elastic)やWebフォーラムなどで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1433910662,"dir":"post/2015/","id":"55188a318c5998989255253e15ccc1f6","lang":"ja","lastmod":1433910662,"permalink":"https://blog.johtani.info/blog/2015/06/10/elasticsearch-1-6-0-released-ja/","publishdate":"2015-06-10T13:31:02+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.6.0 released 本日（6/9）、Lucene 4.10.4ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 1.6.0リリース（日本語訳）"},{"contents":"第10回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n今回も新規の方が結構いたような気がしました。 最終的に、124人がアプリでチェックインした形になりました。 直前にキャンセル待ちから繰り上がると来れない人がいますよねぇ。 多少キャパシティオーバーするくらいの人数で募集するのがいいのでしょうか。 あと、カードが2枚不明で。。。心あたりある人いないでしょうか？\nさて、いつもの通り簡単なメモです。\nElastic{ON}報告＋有償プラグインの紹介　Elastic Jun Ohtani @johtani スライド：elastic{ON}報告と商用プラグインの紹介\n少し時間が経ってしまいましたが、弊社初のカンファレンスelastic{ON}の紹介をしました。 約1300名の方に参加していただいたカンファレンスで、非常に盛り上がりました。 Microsoft、GitHubなど、いろいろな会社の方が話をしたり、弊社のエンジニアが濃い話をしたりと。 今回は、日本の方はいなかったですが、次回は日本からも参加してもらえると嬉しいです！\nあとは、5月に弊社にも日本の営業の人が入社したので、有償プラグインについて簡単ですが説明をしました。 プラグインなどに興味があるかたがいらっしゃいましたら、Twitterなどで連絡いただければと。 もちろん、弊社サイトからの問い合わせでも大丈夫です。\nカンファレンスの資料やビデオが弊社サイトで公開されています。 ぜひ一度見ていただければと。\nAWSで実現するelasticsearchの大規模運用 株式会社インティメート・マージャー　松田和樹さん　@mats116 スライド：第10回elasticsearch勉強会 公開用資料\nパブリックDMPのサービスの裏側でElasticsearchを利用しているというお話でした。 AWS Auto Scalingに詳しくないので、勉強しないといけないんですが、 リバランスがどのくらいの頻度で発生するのかはちょっと気になります。\nSSDを利用したり、doc valuesを利用したりと、性能を気にしながら利用されている点、負荷試験を行って検証されていたりと、 参考になる話でした。 今回はインフラ側の話に寄っていたので、今度はアプリ側でどんな使い方をしているかといった話を聞いてみたいですね！\nSpark in small or middle scale data processing with Elasticsearch　株式会社ビズリーチ 島本　多可子さん @chibochibo03 スライド：Spark in small or middle scale data processing with Elasticsearch\nScalaとSparkとElasticsearchで検索サービスを作っている話でした。 サービスのアーキテクチャの選別についての説明を順を追って説明していただきました。 失敗と言われていたアーキテクチャを見た時に、「あー、それは。。。」と思っていたら、 思った通りの改善案のアーキテクチャが出てきたので少しホッとしましたw\nJSONのクエリが辛いという話がありましたが、validate APIなどを利用してもらって、事前にチェックをしてもらうと 少しは改善できるかもなぁと。\nSparkをぼんやりとしかわかってないので、もう一度話を聴きたいなぁと思ったので、 押しかけて話を聴きたいと思います。\n話の中で出てきた自作のScalaのElasticsearchクライアントがHTTPのクライアントになった理由が知りたかったです。\nLT Elasticsearchのサジェスト機能を使った話　株式会社アイスタイル　渡邊 紘太朗さん @ktaro_w スライド：Elasticsearchのサジェスト機能を使った話\nぴったり5分でしたwまだ2年目なのにこんなにうまく話をしていただけるとは。。。\nGatling便利そうですね。サーバが1台しかないので、単一インデックスの方が性能が出るだろうなと。 Elasticsearchは1インデックスに対してデフォルトだと5シャードで、シャード単位でLuceneのインデックスが作成されます。 この話で行くと、18インデックスを作ると、かなりの数のファイルI/Oが発生するので、いろいろなインデックスに検索をすると キツいだろうなと。\nサジェストについての日本語の資料が少ないという事だったので、ブログを書いてもらえると嬉しいですw\nElasticsearchで作る形態素解析サーバ　株式会社エヌツーエスエム　菅谷信介さん スライド：Elasticsearchで作る形態素解析サーバ\nいつも発表ありがとうございます。私以外の最多発表者じゃないかという話でした。 今回はElasticsearchを形態素解析サーバにしてしまおうという話で、ちょっと面白い話でした。 Elasticsearch以外の場所で形態素解析したい場合には手軽に使えるかもしれないですし、Elasticsearchと同じ解析結果を別の場所で欲しい場合にも便利かも。\nextended analyze APIの紹介までしていただいて。。。\nちなみに、今は、extended analyze プラグインも指定したAttributeの情報だけ返せるようになってたり、 マルチバリューへの対応もしていたりします。 そのうち本家のanalyze APIに機能を取り込む予定です。（早くしないと）\n開発効率UP! Elasticsearch Client Tool 作ってみた　ナレッジワークス株式会社　木戸国彦さん @9215 スライド：開発効率アップ!Elasticsearch Client Tool 作ってみた\nHello Elasticsearch!にはお世話になっている人が多いんじゃないかなと。 今回はSublime Textのプラグインのお話でした。（すみません、Sublime Text使ってなくて。。。） AtomとかIntellijのプラグインもあるとうれしいなー\n変わり種プラグインの作り方　日本IBM　黒澤亮二さん スライド：変わり種プラグインの作り方\nElasticsearchの拡張ポイントの話と、簡単なプラグインの作り方と少しElasticsearch内部の話をしていただきました。 Foundの資料が上がってました。さすが。あそこのブログは面白い話が多いんですよね。 社内で実際に使われてる話とかも聞いてみたい！\nその他、感想などのブログ 第10回 Elasticsearch 勉強会へ参加してきた昨日の話 第10回elasticsearch勉強会 #elasticsearch #elasticsearchjp 第10回elasticsearch勉強会に行ってきました elasticsearch勉強会に登壇してきました まとめ 懇親会で24Fに移動していただくということで、少し手間をかけてしまいました、すみませんでした。 今回も初参加の方がそこそこいたんじゃないかなと。 あとは、AWSサミットがあるために上京してて参加しましたという方もいらっしゃいました。 大きなカンファレンスの期間の前後に行うとこんなメリットもあるんですね、今後の参考にしたいと思います。 次回は7/27を予定しています。CTOのShayが来日予定です！\nあと、東京以外の勉強会も検討しつつあります。興味のある方はコメントやTwitterで反応をいただけると嬉しいです。\nスピーカーは随時募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1433225196,"dir":"post/2015/","id":"75d9268739fe7787ac02d389ac605feb","lang":"ja","lastmod":1433225196,"permalink":"https://blog.johtani.info/blog/2015/06/02/10th-elasticsearch-jp/","publishdate":"2015-06-02T15:06:36+09:00","summary":"第10回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさ","tags":["elasticsearch","勉強会"],"title":"第10回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Reindex Elasticsearch With Logstash\nThanks David!\nマッピングを変更したり、インデックスの設定を変更したり、あるサーバから他のサーバや、 あるクラスタから他のクラスタ（例えば複数のデータセンターのような場合）にデータを再インデックスしたくなることがあるでしょう。\n後者のような場合はSnapshotやRestoreの機能を利用することもできますが、インデックスの設定を変更をしたい場合は その他の方法が必要になります。\nLogstash 1.5.0で、 elasticsearch inputとelasticsearch outputを使うことで、とても簡単に再インデックスができます。\nではやってみましょう。\n古いクラスタ elasticsearch 1.5.2 はすでにダウンロード済みとして、localhost:9200でoldという名前のクラスタを起動します。\nbin/elasticsearch --cluster.name=old クラスタにpersonという名前のインデックスが存在します。 これは、5シャードで、100万件のドキュメントを持っています。\n新しいクラスタ 次に新しいクラスタを起動します。 localhost:9201でnewという名前のクラスタを起動します。\nbin/elasticsearch --cluster.name=new こちらは、空です。\ncurl -XGET \u0026#34;http://localhost:9201/person\u0026#34; { \u0026#34;error\u0026#34;: \u0026#34;IndexMissingException[[person] missing]\u0026#34;, \u0026#34;status\u0026#34;: 404 } Logstashのインストール 次に、Logstash 1.5.0をダウンロードして、インストールします。\nwget http://download.elastic.co/logstash/logstash/logstash-1.5.0.tar.gz tar xzf logstash-1.5.0.tar.gz cd logstash-1.5.0 logstashの設定ファイルlogstash.confを次のように設定します。\ninput { # We read from the \u0026#34;old\u0026#34; cluster elasticsearch { hosts =\u0026gt; [ \u0026#34;localhost\u0026#34; ] port =\u0026gt; \u0026#34;9200\u0026#34; index =\u0026gt; \u0026#34;person\u0026#34; size =\u0026gt; 500 scroll =\u0026gt; \u0026#34;5m\u0026#34; docinfo =\u0026gt; true } } output { # We write to the \u0026#34;new\u0026#34; cluster elasticsearch { host =\u0026gt; \u0026#34;localhost\u0026#34; port =\u0026gt; \u0026#34;9201\u0026#34; protocol =\u0026gt; \u0026#34;http\u0026#34; index =\u0026gt; \u0026#34;%{[@metadata][_index]}\u0026#34; index_type =\u0026gt; \u0026#34;%{[@metadata][_type]}\u0026#34; document_id =\u0026gt; \u0026#34;%{[@metadata][_id]}\u0026#34; } # We print dots to see it in action stdout { codec =\u0026gt; \u0026#34;dots\u0026#34; } } 実行と修正 実行します。\nbin/logstash -f logstash.conf ドキュメントのチェックと修正 何が起きたでしょう？\ncurl -XGET \u0026#34;http://localhost:9200/person/person/AU1wqyQWZJKU8OibfxgH\u0026#34; { \u0026#34;_index\u0026#34;: \u0026#34;person\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;person\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;AU1wqyQWZJKU8OibfxgH\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;Tali Elyne\u0026#34;, \u0026#34;dateOfBirth\u0026#34;: \u0026#34;1955-05-03\u0026#34;, \u0026#34;gender\u0026#34;: \u0026#34;female\u0026#34;, \u0026#34;children\u0026#34;: 2, \u0026#34;marketing\u0026#34;: { \u0026#34;cars\u0026#34;: null, \u0026#34;shoes\u0026#34;: null, \u0026#34;toys\u0026#34;: null, \u0026#34;fashion\u0026#34;: null, \u0026#34;music\u0026#34;: null, \u0026#34;garden\u0026#34;: null, \u0026#34;electronic\u0026#34;: null, \u0026#34;hifi\u0026#34;: null, \u0026#34;food\u0026#34;: 846 }, \u0026#34;address\u0026#34;: { \u0026#34;country\u0026#34;: \u0026#34;Germany\u0026#34;, \u0026#34;zipcode\u0026#34;: \u0026#34;0099\u0026#34;, \u0026#34;city\u0026#34;: \u0026#34;Bonn\u0026#34;, \u0026#34;countrycode\u0026#34;: \u0026#34;DE\u0026#34;, \u0026#34;location\u0026#34;: [ 7.075943707068682, 50.72883500730124 ] } } } もう一方のクラスタと比較してみましょう。\ncurl -XGET \u0026#34;http://localhost:9201/person/person/AU1wqyQWZJKU8OibfxgH\u0026#34; { \u0026#34;_index\u0026#34;: \u0026#34;person\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;person\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;AU1wqyQWZJKU8OibfxgH\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;Tali Elyne\u0026#34;, \u0026#34;dateOfBirth\u0026#34;: \u0026#34;1955-05-03\u0026#34;, \u0026#34;gender\u0026#34;: \u0026#34;female\u0026#34;, \u0026#34;children\u0026#34;: 2, \u0026#34;marketing\u0026#34;: { \u0026#34;cars\u0026#34;: null, \u0026#34;shoes\u0026#34;: null, \u0026#34;toys\u0026#34;: null, \u0026#34;fashion\u0026#34;: null, \u0026#34;music\u0026#34;: null, \u0026#34;garden\u0026#34;: null, \u0026#34;electronic\u0026#34;: null, \u0026#34;hifi\u0026#34;: null, \u0026#34;food\u0026#34;: 846 }, \u0026#34;address\u0026#34;: { \u0026#34;country\u0026#34;: \u0026#34;Germany\u0026#34;, \u0026#34;zipcode\u0026#34;: \u0026#34;0099\u0026#34;, \u0026#34;city\u0026#34;: \u0026#34;Bonn\u0026#34;, \u0026#34;countrycode\u0026#34;: \u0026#34;DE\u0026#34;, \u0026#34;location\u0026#34;: [ 7.075943707068682, 50.72883500730124 ] }, \u0026#34;@version\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;@timestamp\u0026#34;: \u0026#34;2015-05-20T09:53:44.089Z\u0026#34; } } Logstashは@versionと@timestampフィールドを追加してしました。 これらを除去したいので、Mutate filter pluginのremove_fieldを使います。\nfilter { mutate { remove_field =\u0026gt; [ \u0026#34;@timestamp\u0026#34;, \u0026#34;@version\u0026#34; ] } } マッピングのチェックと修正 実際に、logstashは_sourceフィールドを既存のドキュメントから読み込み、 それらを新しいクラスタに直接投入しています。 しかし、logstashはマッピングについてはケアしていません。\n古いマッピングと新しいマッピングを比較するために、マッピングを取得してみましょう。\ncurl -XGET \u0026#34;http://localhost:9200/person/person/_mapping\u0026#34; { \u0026#34;person\u0026#34;: { \u0026#34;mappings\u0026#34;: { \u0026#34;person\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;address\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;city\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;country\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;countrycode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;location\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;geo_point\u0026#34; }, \u0026#34;zipcode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;children\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;dateOfBirth\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;date\u0026#34;, \u0026#34;format\u0026#34;: \u0026#34;dateOptionalTime\u0026#34; }, \u0026#34;gender\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;marketing\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;cars\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;electronic\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;fashion\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;food\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;garden\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;hifi\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;music\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;shoes\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;toys\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; } } }, \u0026#34;name\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } } } } curl -XGET \u0026#34;http://localhost:9201/person/person/_mapping\u0026#34; { \u0026#34;person\u0026#34;: { \u0026#34;mappings\u0026#34;: { \u0026#34;person\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;address\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;city\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;country\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;countrycode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;location\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;double\u0026#34; }, \u0026#34;zipcode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;children\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;dateOfBirth\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;date\u0026#34;, \u0026#34;format\u0026#34;: \u0026#34;dateOptionalTime\u0026#34; }, \u0026#34;gender\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;marketing\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;cars\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;electronic\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;fashion\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;food\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;garden\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;hifi\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;music\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;shoes\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;toys\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; } } }, \u0026#34;name\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } } } } これにより、いくつかの相違を発見できます。\n\u0026#34;location\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;geo_point\u0026#34; } \u0026#34;location\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;double\u0026#34; } データをインデックスする「前」に、実際に利用したいマッピングでインデックスを作成しておくことで、 この問題に対処できます。 この時点で、オリジナルのマッピングを望んだ形に変更することができます。例えば、アナライザを変更したりです。 また、インデックスの設定を新しく定義することもできます。 デフォルトでは、Elasticsearchは5つのシャードと各シャードに対して1つのレプリカを作成します。 しかし、この時点でもう一度変更することが可能です。\ncurl -XDELETE \u0026#34;http://localhost:9201/person\u0026#34; curl -XPUT \u0026#34;http://localhost:9201/person\u0026#34; -d\u0026#39; { \u0026#34;settings\u0026#34;: { \u0026#34;number_of_shards\u0026#34;: 1, \u0026#34;number_of_replicas\u0026#34;: 0 } }\u0026#39; curl -XPUT \u0026#34;http://localhost:9201/person/person/_mapping\u0026#34; -d\u0026#39; { \u0026#34;person\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;address\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;city\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;country\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;countrycode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;location\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;geo_point\u0026#34; }, \u0026#34;zipcode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;children\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;dateOfBirth\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;date\u0026#34;, \u0026#34;format\u0026#34;: \u0026#34;dateOptionalTime\u0026#34; }, \u0026#34;gender\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;marketing\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;cars\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;electronic\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;fashion\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;food\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;garden\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;hifi\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;music\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;shoes\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;toys\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; } } }, \u0026#34;name\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } }\u0026#39; さて、もう一度再インデックスしましょう！\nbin/logstash -f logstash.conf インデックスやタイプ名の変更 もちろん、インデックス名やタイプ名、IDを変更したい場合も変更が可能です！:)\nelasticsearch { host =\u0026gt; \u0026#34;localhost\u0026#34; port =\u0026gt; \u0026#34;9201\u0026#34; protocol =\u0026gt; \u0026#34;http\u0026#34; index =\u0026gt; \u0026#34;europe_people\u0026#34; index_type =\u0026gt; \u0026#34;someone\u0026#34; document_id =\u0026gt; \u0026#34;%{[@metadata][_id]}\u0026#34; } ","date":1432624090,"dir":"post/2015/","id":"23a22d1411afb787810d68210e6fad4f","lang":"ja","lastmod":1432624090,"permalink":"https://blog.johtani.info/blog/2015/05/26/reindex-elasticsearch-with-logstash-ja/","publishdate":"2015-05-26T16:08:10+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Reindex Elasticsearch With Logstash Thanks David! マッピングを変更したり、インデックスの設定を変更したり、あるサ","tags":["logstash","elasticsearch"],"title":"Logstashを使ったElasticsearchの再インデックス（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Join the Conversation: Discuss.Elastic.Co\n3つのOSSプロジェクトの開発をスケールアップし始め、 コミュニティサポートのために必要なやりとりに対してメーリングリストでは難しいということがわかってきました。 私たちは複数のメーリングリストを持っています。Elasticsearch、Logstash、そして英語以外の様々な言語のメーリングリストです。 このような状況では、あたらしい人たちはどこで質問をするのが良いのか混乱します。\nまた、メーリングリストの流量が増え、「参考になる話題」を見つけるのが難しくなってきました。 様々なユーザに採用してもらい、様々なユースケースが出てくることで、様々な質問が出てきています。 汎用的なメーリングリストではノイズの中から望んだ情報を見つけるのは難しいです。 また、ユーザ全てがメーリングリスト満足しているわけではありません。\nElasticは、ユーザの問題を解くことが大好きです。 コミュニティのメンバー皆さんに気に入っていただけるであろうソリューションを見つけ、フォーラムを https://discuss.elastic.co に移すことにしました。 ぜひ参加して、この新しいツールについてのご意見を聞かせてください。\nメーリングリストは好きだけど、ウェブフォーラムは苦手？問題ありません。 フォーラムにユーザプロファイル（GitHub、Facebook、Twitter、Google Appsのアカウントと連携するか、emailアドレスを利用すれば簡単に作れます）を作り、 email通知の設定をすればOKです。 これで、emailでのやりとりができるようになります。\n利用して、議論を楽しんでください。 もちろん、改善案などにかんするご意見もお待ちしています！\n","date":1432197903,"dir":"post/2015/","id":"615db1a24f36d19a8eaf18d4dceed6b2","lang":"ja","lastmod":1432197903,"permalink":"https://blog.johtani.info/blog/2015/05/21/join-the-conversation-ja/","publishdate":"2015-05-21T17:45:03+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Join the Conversation: Discuss.Elastic.Co 3つのOSSプロジェクトの開発をスケールアップし始め、 コミュニティサポー","tags":null,"title":"discuss.elastic.co にぜひ参加を"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.5.2 Released\n本日（4/27）、Lucene 4.10.4ベースのElasticsearch 1.5.1およびElasticsearch 1.4.5 をセキュリティバグフィックス版をリリースしました。 ダウンロードおよびすべての変更については次のリンクをごらんください。\n最新安定版：Elasticsearch 1.5.2 1.4系バグフィックス：Elasticsearch 1.4.5 本リリースはディレクトリトラバーサルの脆弱性のフィックスです。すべてのユーザにアップグレードを勧めます。\n過去のリリースに関するブログは以下のリンクを参照してください。\n1.5:1.4.1, 1.5.0 1.4:1.4.4,1.4.3, 1.4.2,1.4.1, 1.4.0, 1.4.0.Beta1 すべての1.5.2および1.4.5の変更についてはリンクをごらんください。以下では、セキュリティの問題について紹介します。\nディレクトリトラバーサル脆弱性の発見 1.5.2および1.4.5以前の全バージョンのElasticsearchで、ディレクトリトラバーサル攻撃に対する脆弱性がみつかりました。 攻撃者はElasticsearchを実行しているサーバからファイルを取得することができます。 この脆弱性はインストールしたばかりのElasticsearchには存在しません。 この脆弱性は\u0026quot;site plugin\u0026quot;がインストールされると露呈します。 ElasticのMarvelプラグインおよびコミュニティサポートの多くのプラグイン（例：Kopf、BigDesk、Head）がsite pluginです。 Elastic Shield、Licensing、Cloud-AWS、Cloud-GCE、Cloud-Azure、analysis pluginおよびriverプラグインはsite pluginではありません。\nこの問題をCVE-2015-3337としました。\nバージョン1.5.2と1.4.5はこの脆弱性に対して対策済みで、私たちはすべてのユーザにアップグレードを勧めています。\nアップグレードを望まないユーザはいくつかの方法でこの脆弱性に対して対応可能ですが、これらの方法はsite pluginを動作させなくします。\nsite pluginをインストールしているノードのelasticsearch.ymlのhttp.disable_sitesをtrueに設定し、Elasticsearchのノードを再起動 ファイアウォールもしくはプロキシを利用して、/_pluginへのHTTPリクエストをブロック すべてのsite pluginをすべてのElasticsearchノードからアンインストール この問題を報告していただいた、DocuSignのJohn Heasmanに感謝いたします。\n他の変更について インデックスされたスクリプトおよびテンプレートを上書きもしくは削除時に、キャッシュからも完全に削除する。 geo-shapeの多数のフィックス（distance_error_pctを利用した場合の、重要なprecisionに関するフィックスを含む） インデックステンプレートのデフォルトマッピングがバルクインデキシング中にも考慮するように修正 Shadowレプリカがファイルシステムの遅延に対する対障害性を向上し、プライマリシャードのよりスムーズなリロケーションをサポート geo-contextsをcompletion suggesterで使用した場合のマッピングのリフレッシュループを改善 いくつかの重要な変更がv1.4.5にバックポートされています。\n大きなシャードのリカバリを早くするためのシャードリカバリ中のマージを可能に \u0008* truncated translogsの操作をグレースフルに マージが遅くなる場合に、delete-by-queryを減速 ぜひ、Elasticsearch 1.5.2をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1430201648,"dir":"post/2015/","id":"8d7caf84b3a51cca27291c1f7cfc2d40","lang":"ja","lastmod":1430201648,"permalink":"https://blog.johtani.info/blog/2015/04/28/elasticsearch-1-5-2-and-1-4-5-released-ja/","publishdate":"2015-04-28T15:14:08+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.2 Released 本日（4/27）、Lucene 4.10.4ベースのEla","tags":["elasticsearch"],"title":"Elasticsearch 1.5.2 および 1.4.5リリース（日本語訳）"},{"contents":"第9回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n今回はトレーニングで来日していたIgorとNathanによる特別公演でした。 昨年同様、サムライズムの@yusukeさんに テキスト翻訳していただき、大変助かりました。ほんとうにすごかった。。。\nチェックイン数など 今回はチェックインした人：119名 キャンセルしなかった人：45名 でした。今回はキャンセル待ちのまま当日を迎えた人もいなかったので良かったかなと。 今回から懇親会ページを別にしてみました。本編の勉強会に参加登録していた方には何度かメールを出していたので、 見つけていなかった人は以内とは思うのですが、勉強会のページと間違える人がいたらしいという話を聞きました。 Doorkeeperで1イベントで複数のチケットにそれぞれの参加者数を設定できるようになると嬉しいかもなぁ。\nさて、いつもの通り簡単なメモです。 本当に簡単にですが。\nResiliency in Elasticsearch and Lucene / Igor Motov スライド：https://speakerdeck.com/elastic/resiliency-in-elasticsearch-and-lucene\n※上記スライドは少し古いバージョンです。公開されたら差し替える予定です。\nサンフランシスコで行われたElastic{ON}（弊社初のカンファレンス）で行われたセッションの 改良版といったところでしょうか。 話の中で登場した機能などのリンクをざっとアップしておきます。\nFielddata Doc Values Resiliency Status Kibana4: What\u0026rsquo;s New ? / Nathan Zamecnik スライド：未定\nKibana4の紹介をデモを交えてという感じでした。 こちらは、スライドよりもデモを見てもらうのが一番いいのですが。。。\nいくつかQAがあったので補足を。ちなみに、Issueのラベルに実装される予定のバージョンが付与されてたりします。\nQ：グラフをPDFでエクスポートとかできますか？ A：4.3.0で実装される予定です。関連Issueはこちら。https://github.com/elastic/kibana/issues/509 Q：巨大な数値の場合にKB、MBなどといった表示は可能ですか？ A：4.1.0で実装される予定です。関連Issueはこちら。https://github.com/elastic/kibana/issues/1543 Q：地図のズームを固定することはできますか？ A：4.1.0で実装される予定です。関連Issueはこちら。https://github.com/elastic/kibana/issues/1442 その他、感想などのブログ [Elasticsearch] 第9回 Elasticsearch 勉強会へ参加してきた まとめ 今回は特別バージョンでした。かなり詳しい話だったので面白かったと思います。 Kibanaはデモを見ていただけましたし。また、海外から人を呼べるといいなぁ。\n次回は6月ごろをめどに計画しようかと。 スピーカーは随時募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1429249314,"dir":"post/2015/","id":"7249710187cc2d983709e044dbc78d9d","lang":"ja","lastmod":1429249314,"permalink":"https://blog.johtani.info/blog/2015/04/17/9th-elasticsearch-jp/","publishdate":"2015-04-17T14:41:54+09:00","summary":"第9回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第9回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.5.1 Released\n本日（4/9）、Lucene 4.10.4ベースのElasticsearch 1.5.1 をリリースしました。 このリリースはElasticsearchの最新の安定バージョンとなります。\nすべての変更についてはdownload Elasticsearch 1.5.1 hereをごらんください。\n本リリースはシャードを新しいノードに配置するスピードを改善するためのバグフィックスを含んでいます。 シャードのリカバリーの最初のフェーズで、コピー元のノードからコピー先のノードへすべてのセグメントをコピーします。 このフェーズ中には登録、更新削除のリクエストはトランザクションログに記録され、リカバリが終了したあとに コピー先のノードでトランザクションログが再生されます。 シャードが大きい場合、トランザクションログに多数のイベントがたまってしまいます。\n以前では、新しいセグメントのマージはリカバリ中のコピー先のノードでは、実行できませんでした。 大きなトランザクションログは結果として、小さな新しいセグメントを多く生成し、リカバリのスピードに非常に影響を与えます。 Issue #10463は リカバリ中のコピー先のシャードのマージを可能にする変更です。\nその他の注目すべきバグフィックスは次のものになります。\n多くの削除によりバージョンマップがいっぱいになった場合にrefreshを実行するように変更(#10312) 多数のスナップショットを含んだリポジトリの管理の改善(#10366) 実験的な機能であるinner hitsのバグフィックス(#10388, #10353, #10309, #10235) 最後に、Riverが非推奨となりました、まだ見ていない場合は記事をご覧ください。\nぜひ、Elasticsearch 1.5.1をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1428892471,"dir":"post/2015/","id":"563864a949924c505985a168191dcb84","lang":"ja","lastmod":1428892471,"permalink":"https://blog.johtani.info/blog/2015/04/13/elasticsearch-1-5-1-released-ja/","publishdate":"2015-04-13T11:34:31+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.1 Released 本日（4/9）、Lucene 4.10.4ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 1.5.1リリース（日本語訳）"},{"contents":"Elasticsearch勉強会 in 名古屋を開催しました。 初の東京以外での勉強会です。 企画、セッションなどお手伝いいただいた@smogamiさん、@mzpさんありがとうございました！\nElasticsearch/ELK stack紹介 @johtani スライド：Introduction Elasticsearch\n初回（次回があるかはわかりませんが。。。）ということもあり、Elasticsearchの説明を行いました。 あと、LogstashとKibanaも。 Kibanaについては、手元の環境でいつものアクセスログのデモやなどを行いました。 また、LTの後に時間があったので、前回の勉強会で利用したチェックリストの説明なども。\nスタンドファームにおけるElasticsearch導入事例 @mzp さん スライド：後日アップ？\n\u0008* 使ってるのはKibana3\nアクセスログが保存されてたけど、活用できてなかった。 Fluentd、Elasticsearch、Kibanaをいれて、可視化してみた。 普通にログ検索が簡単にできて嬉しい システムのレスポンスの性能値などを可視化できるようにして性能改善中 Kibanaでログ分析を1年続けてみたら業務システムの保守と運用が捗った(仮) @smogami さん スライド：「Kibanaでログ分析を1年続けてみたら業務システムの保守と運用が捗った」\n名古屋でJavaの勉強会を主催してみたり（最近できてないけど） 導入するのになかなか大変だった（ファイアウォールだったりが）。。。 Kibanaを使ってどんなことをしてるのか？\n既存システムなどの機能の実行回数やレスポンス時間の推移 曜日ごとにもチェック どの機能がよく使われるのか？ 対象となっているシステムはJavaのシステム。 QA\nQ：ログの出力は新規に追加したのか？ A : ログの出力自体はLog4Jの設定を変更しただけ。もともと、各メソッドの開始と終了にそれぞれ時間が出力される仕組みがある。\nログの読み込み自体は自作ツールを利用。 飛び込みLT @dabits さん スライド：未定\nKibanaの使い道\nKPIツール エゴサーチツール - Twitterや2chなどのデータを解析ソーシャル分析みたいな感じ？ \u0008* ダッシュボードを用意してあげる場合もあるが、触っていろんな機能を試す人も。 感想・反省点など 30名弱の方に参加していただきました。ありがとうございました。 東京の勉強会でもそうですが、半分くらいが検索、半分くらいがログ解析関連に興味がある感じでした。 飛び込みLTもしていただけましたし。会場内限定の話もいくつか。\n場所 場所が少しわかりにくかったかなと。。。建物の入り口に看板がないので、1名に看板役として立っていただきました。 ただ、設備は充実していましたし、室内も綺麗でよかったです。\n懇親会 11名（+私）でした。美味しい手羽先などをいただきながら、Elasticsearch以外のことでも盛り上がりましたw。 また、名古屋の観光名所なども教えてもらったりと有意義な時間でしたw。\nということで、少しでもElasticsearch、Kibana、Logstashなどのユーザが増えてくれればうれしいかなと。 私抜きでも勉強会はできると思うので、今後も開いてもらえるとうれしいかぎりです。 初めての東京以外での勉強会でどんな感じの方が利用しているのか、興味があるのかといったことも知ることができました。\n関連ブログなど Kibana4活用事例を話しました その他（余談） コンパルという喫茶店のアイスコーヒー。ちょっと新鮮な体験でした。 あとは、日曜日に観光場所として教えてもらった、トヨタ産業技術記念館にも行ってみました。 一人だったけど、非常に楽しめました。実演とかあって、わかりやすいし。 トヨタが自動織機の会社が始まりだってのは知らなかった。\n","date":1428108439,"dir":"post/2015/","id":"24357fe145c869ec82fdfc8134a1a6d1","lang":"ja","lastmod":1428108439,"permalink":"https://blog.johtani.info/blog/2015/04/04/elasticsearch-study-session-at-nagoya/","publishdate":"2015-04-04T09:47:19+09:00","summary":"Elasticsearch勉強会 in 名古屋を開催しました。 初の東京以外での勉強会です。 企画、セッションなどお手伝いいただいた@smogamiさ","tags":["elasticsearch","勉強会"],"title":"Elasticsearch勉強会 in 名古屋を開催しました。#elasticsearch #elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.5.0 Released\n本日（3/23）、Lucene 4.10.4ベースのElasticsearch 1.5.0 をリリースしました。 このリリースはElasticsearchの最新の安定バージョンとなります。 多くのresiliency(復元性、弾力性) enhancementとバグフィックスを含んでおり、 すべてのユーザにアップグレードを推奨しています。\nすべての変更についてはdownload Elasticsearch 1.5.0 hereをごらんください。\n460PRという大量の変更を含む本リリースは、Elasticsearchをよりresilient(弾力のあるもの)にするために 費やされています。\nInner hits 本リリースで追加された、Elasticsearchに最もリクエストされたものの一つがinner hitsです。 これは、has_childもしくはnestedクエリにマッチした子のドキュメントを、各親ドキュメントと一緒に返すことができます。\n例えば、blogという親ドキュメントとcommentという子ドキュメントを持っているとします。 この時、\u0026ldquo;full text search\u0026quot;というコメントを持ったブログ記事を検索したいとします。\nGET /my_index/blog/_search { \u0026#34;query\u0026#34;: { \u0026#34;has_child\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;comment\u0026#34;, \u0026#34;score_mode\u0026#34;: \u0026#34;sum\u0026#34;, \u0026#34;query\u0026#34;: { \u0026#34;match\u0026#34;: { \u0026#34;body\u0026#34;: \u0026#34;full text search\u0026#34; } } } } } 上記のリクエストは、親のblogドキュメントを返します。 しかし、どのコメントが関係しているのかはわかりません。 関連しているコメントを検索して親ごとにグルーピングするために、 少し手間のかかる2回目のクエリを実行する必要があります。\nInner hitsがこれを変えてくれます。 inner_hitsパラメータを次のように、上記のクエリに追加するだけです！\nGET /my_index/blog/_search { \u0026#34;query\u0026#34;: { \u0026#34;has_child\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;comment\u0026#34;, \u0026#34;score_mode\u0026#34;: \u0026#34;sum\u0026#34;, \u0026#34;query\u0026#34;: { \u0026#34;match\u0026#34;: { \u0026#34;body\u0026#34;: \u0026#34;full text search\u0026#34; } }, \u0026#34;inner_hits\u0026#34;: {} } } } 検索結果の各blog記事に、inner_hitsという項目があり、そこに検索にヒットしたコメントの 上位3件（デフォルト値）が返ってきます。\n... \u0026#34;hits\u0026#34;: [ { \u0026#34;_index\u0026#34;: \u0026#34;my_index\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;blog\u0026#34;, \u0026#34;_id\u0026#34;: 1, \u0026#34;_score\u0026#34;: 3.68, \u0026#34;_source\u0026#34;: { ... }, \u0026#34;inner_hits\u0026#34;: { \u0026#34;comment\u0026#34;: { \u0026#34;total\u0026#34;: 16, \u0026#34;hits\u0026#34;: [ { \u0026#34;_type\u0026#34;: \u0026#34;comment\u0026#34;, \u0026#34;_id\u0026#34;: 5, \u0026#34;_score\u0026#34;: 2.79, \u0026#34;_source\u0026#34;: { \u0026#34;body\u0026#34;: \u0026#34;Full text search is the bomb\u0026#34; } }, { ... }, { ... } ] } } } ] ... inner_hits部分は、第2の検索リクエストに似ています。 sizeやfromパラメータを含めるくことで、挙動をカスタマイズできます。 また、検索から想像するであろう、ページネーション、ソート、ハイライト、_sourceフィルタリングなどといった機能もサポートします。\nInner hitsはparent-childおよび、nestedドキュメントをサポートします。 この機能は、現時点ではexperimentalラベルが付与されています。 このラベルは、この機能が将来変更されたり、削除されたりする可能性があるかもしれないことを意味します。 詳細については、Inner Hits documentationをごらんください。\nShadow replicas Elasticsearchはそれ自身の冗長性に常に気をつけています。 それは、レプリカシャード（各プライマリシャードの冗長なコピー）を持っています。 これは、プライマリシャードを失った時に、データをロスしないようにするためのものです。 レプリカシャードはまた、検索のスループットをスケールアウトするためにも利用できます。 多くのレプリカ（ノードを伴うことで。）はスループットを増加させます。\nしかし、ユーザによってはElsticsearchを分散ファイルシステム上でホスティングしており、すでに、 ファイルシステムがレプリケーションと冗長性を担当しています。 ファイルシステムが同じことしているので、各シャードのコピーを複数持つことはあまり意味がありません。\nShadowレプリカはノードを追加することによる検索スループットをスケールアウトすることが、 余分なストレージやインデキシングのコストを払うことなく、可能になります。 代わりに、各シャドーレプリカはプライマリシャードを持っている共有ファイルシステムにread-onlyでアクセスします。 Shadowレプリカは定期的にファイルシステムのビューをリフレッシュし、プライマリシャードのどんな変更も検知するでしょう。\nプライマリシャードが失敗したら、Shadowレプリカがプライマリに昇格し、 失敗したプライマリによって書き込まれたトランザクションログを読み込みリプレイできます。\nこの機能はexperimentalマークが付いています。詳細についてはShadow Replicas documentationをごらんください。\nResiliency improvements Elasticsearch 1.1 から 1.3では、インデックスのすべてのファイルのチェックサムを追加し、 それらのファイルが壊れているかどうかをチェックするために利用することにフォーカスしました。 1.4では、Zen discoveryと分散モデルについて大きな改良を加えました。\nこれらの変更にともなう、より詳細な統計情報やより詳細なロギングがElasticsearchやLuceneの以前のバージョンに存在した 未知の問題を明るみに出しました。 Elasticsearch 1.5.0では、これらの問題の多くに対処しています。\nElasticsearchとLuceneの以前のバージョンにあるバグがインデックスの故障を引き起こしていました。\nチェックサムコードのおかげで、これらを発見できました。現在は、Elasticsearchの起動時に自動的にLucene3.x\n(Elasticsearch 0.20.x以前)が作成したセグメントを検知して、シャードをオープンする前に、新しいフォーマットを使って、 新しいコミットポイントを書き出します。(#9899)\n1.3.xもしくは以前のバージョンからローリングアップグレードは、ローカルのシャードデータを再利用しようとせずに、\nシャード全体をコピーしようとします。1.3.2と以前のバージョンが実行されているノードからローリングアップグレードすることは 圧縮をオフにしない限りできなくなりました。(#9925)\n1.3.xやそれ以前のバージョンからアップグレードする場合、ローリングアップデートする代わりにクラスタの再起動を考えたほうがいいかもしれません。\n非同期環境は予測することが難しいです。時に、最も予測していないことが起きるからです。\nシャード配置、リカバリ、削除のコードの多くが単純化され、状態変更をよりアトミックで決定的にするための変更によりリファクタリングされました。\n(#8720, #9799, #9784, #9801, #9083, #8579, #8436, #8092, #9902, #6644, #8350, #9770, #9616, #9439, #8350, #8494)\n同様に、変更はクラスタ状態の更新が常に前進するということを確実にしました。更新の受け取り順序が順不同であったり、\nマスターだったノードからの更新を受け取った場合に混乱させていました。 (#9632, #9541, #9503)\nチェックサムとチェックサムのバリデーションの強化(#8723,\n#8599, #8587, #8407, #8010, #8018)\ndisk threshold allocation deciderを速く(#8803)、賢く(#7785)、自動化(#8270)\nauto-generated IDの利用時のインデキシングのスピードアップのためのに追加された最適化を除去。\nたまにドキュメントを重複して登録するため(#7729)\nDownload now ぜひ、Elasticsearch 1.5.0をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1427859496,"dir":"post/2015/","id":"19ecbaa5e12f7a9ebcff703c79534a52","lang":"ja","lastmod":1427859496,"permalink":"https://blog.johtani.info/blog/2015/04/01/elasticsearch-1-5-0-released-ja/","publishdate":"2015-04-01T12:38:16+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.0 Released 本日（3/23）、Lucene 4.10.4ベースのEla","tags":["elasticsearch"],"title":"Elasticsearch 1.5.0リリース（日本語訳）"},{"contents":"サンフランシスコからこんにちは。\n今、私は、弊社初のユーザカンファレンスelastic{ON}に 参加するために、初のアメリカ出張中です。 初のユーザカンファレンスですが、世界各国から約1300人！の登録がありました。\n本日が初日（Welcome Receptionが昨晩開催されましたが）です。 初日のキーノートで重要な発表が2つありました。\nブランド名の変更（Elastic: For - You Know, More Than Search） Found.noの加入（Welcome Found） です。\n昨日までは、elasticsearchでした。 本日からは、elasticになります。 ブランド名の変更と同時にサイト、ロゴなども変更されました。\nもう一つのビッグニュースがFoundの加入です。 found.noはElasticsearchをクラウドサービスとして提供している会社です。 彼らがジョインすることで、elasticsearchをより気軽に利用できるような環境ができてきます。\nKeynoteでの驚きのニュースこれらでした。 もちろん、このカンファレンスはそれだけには止まりません。\nNetflixやGitHub、Verison Mobile、WikimediaといったElasticsearch,ELKスタックのユーザの話や、 弊社の人たちによる今後のロードマップや私たちの考え方など多岐にわたる話を聞くことができます。\nこのような機会を今後も提供できるような会社になれるよう、頑張っていきたいなと思っています。\nちなみに、弊社のカンファレンスは私がこれまで経験したことのないカンファレンスになっています。 DJや各種ゲーム（ビリヤードとかパックマンとか）が楽しめるようなパーティが 懇親会として開催されたり、スポンサーブースでウェルカムレセプションが行われたりと、 面白い取り組みにあふれています。 次回開催されることがあれば、ぜひ日本の方達にも参加してもらえたらうれしいなと。\n","date":1426059991,"dir":"post/2015/","id":"ced9df0d8c8ed14de91c509b31b4c4ae","lang":"ja","lastmod":1426059991,"permalink":"https://blog.johtani.info/blog/2015/03/11/attend-elasticon/","publishdate":"2015-03-11T16:46:31+09:00","summary":"サンフランシスコからこんにちは。 今、私は、弊社初のユーザカンファレンスelastic{ON}に 参加するために、初のアメリカ出張中です。 初のユ","tags":["elastic","elasticon"],"title":"#elasticon に参加中"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：you know, for security: shield goes ga\n1/27にShield 1.0 をリリースしました。 Elasticsearch向けの私たちのセキュリティプラグインの最初のリリースです。 11月にShieldについてアナウンスしてから、Elsaticsearchのためのセキュリティの機能は、 一般的に望まれているものから始まり、具体的な考えと実行できる計画へと変遷し、それが、いま現実となりました。\n十分にセキュアな環境に、Elasticsearchクラスタをセキュアな状態でデプロイできるようにするため、 私たちは継続的にカスタマーやユーザーからのリクエストを受け取り、統合されたソリューションになるようにしてきました。\n私たちは、そのようなプロダクトがどうあるべきか調査することから始め、 カスタマーとユーザが必要とするセキュリティとはどんなものかを理解するために多くの時間を費やしました。 その結果がShieldです。 Shieldは、ElasticsearchクラスタをセキュアにするElasticsearchの有償プラグインです。 私たちは、ShieldをDev、Gold、Platinumサブスクリプションの一部として、追加料金なしで提供します。\n最初のリリースでは、基本的な機能と基盤にフォーカスしています。 Elasticsearch自身に対しても、セキュリティに対して準備してきました。 拡張性の側面だけでなく、Elasticsearchにあるデータフローについても再考してきました。 Elasticsearchクラスタをセキュアにする場合に、具体的な価値を即座に届けるだけでなく、素早く拡張できるようにも開発しました。\n機能 Shield 1.0は次の5つにフォーカスしています。\n認証(Authentication) 認可(Authorization) 暗号化通信とノードの認可(Encrypted Communication \u0026amp; Node Authentication) IPフィルタリング 監査証跡(Audit Trail) 認証(Authentication) セキュリティの大部分はアイデンティティについてです（例えば、だれがこのAPIを呼び出したのか？システムに何のサービスが接続するか？など） サービスのライフタイムのある時点で、サブジェクト（例えばユーザー）を現在実行中のサブプロセスなどに結びつけることです。 この関係性を持つためには、サブプロセスを実行する前にユーザの身元を確認するように命じます。 ユーザの身元の確認のプロセスをAuthenticationと呼び、ElasticsearchのすべてのAPIコールでそれが実行されます。\n認証の手法は多くの異なるものがあります。 それぞれの手法は、ユーザが認証されたという資格（Authentication Token）を、それぞれのタイプで提供するようにユーザに要求します。 Shield 1.0ではシンプルに、必要なauthentication tokenをユーザ/パスワードペアとしています。 （これは、Shieldの認証基盤が簡単に拡張でき、将来は異なるauthentication tokenもサポートできることを意味します。）\nユーザの資格を受け取ることだけでは不十分で、次に、それらをチェックする必要があります。 Shieldでは、これはレルムの責務です。 レルムは認証プロバイダ/サービスとしてみることができます。 妥当なユーザであると判断/解決されたか、 authentication tokenが適切な資格を持っていない/単に知らないユーザであるということで、拒否されたかです。 Shieldの認証メカニズムでは、複数のレルムを設定でき、さらに、あるレルムの戻り値を扱う他のレルム、というようなchainとすることもできます。 Shield 1.0は3つのレルムをサポートします。\nesusers - Elasticsearchによって管理されるファイルベースのレルムです。 これは、ファイルにユーザを定義することができます。（Apacheサーバのhtpasswdファイルのようなもの） このレルムは外部への依存はなく、Shieldをインストールすれば、デフォルトで使用できます。 このレルムは配置が簡単で、マルチテナントなElasticsearchクラスタに対して使用できます。 マルチテナントなElasticsearchクラスタとは、クラスタを複数のアプリでシェアすることをテナントと言います。 また、すべてのユーザがパスワードを忘れてしまうような\u0026quot;emergency\u0026quot;な代替レルムも対応可能です。 (誰もシステムに入れないような状況のことです) LDAP - 外部のLDAPサーバでユーザを認証するレルムです。 このレルムは組織のLDAPサーバで管理/保存されているユーザをすでに持っている組織を対象としています。 Active Directory - LDAPのタイプの1つで、Active Directoryに対する設定になります。 レルムはelasticsearch.yml設定ファイルで、次のように設定可能です。\nshield.authc realms:\nesuser: type: esusers order: 0 ldap: type: ldap order: 1 url: ldaps://url/to/ldap1/server ldap_fallback: type: ldap order: 2 url: ldaps://url/to/ldap2/server 上記のようにrealmsが一つのチェインとして参照されます。 レルムごとに、設定された順序で、それらは参照されます。\nNOTE : Shieldには、esusersファイルに保存されたユーザを管理するためのコマンドラインツールもあります。\n認可(authorization) 認可(Authorization)は保護されたリソースにアクセスするユーザを許可するか拒否するかということです。 モダンなシステムは、ユーザのパーミッションのために、ロールベースのアクセスコントロール（RBAC）モデルを利用します。 このモデルでは、各ユーザはロールの集合に関連していて、それぞれのロールには、パーミッションの集合が定義されています。 これは、洗練された設定で、パーミッションを機能的なグループで共有させることができます。 例えば、次のようなロールを定義したとします。\nemployee - すべての従業員は部門をまたいだ会社のデータへアクセスできます（例えば、コンタクトやディレクトリ情報など） sales - すべての営業職は営業データにアクセスできる（例えば、流通ルート、ルート、顧客） finace - すべての財務の従業員は財務データにアクセスできる（例えば、予算、経費、伝票） 財務部門のAnnは従業員と財務のロールを持っており、会社のディレクトリと財務データにアクセスでできます。\n認可プロセスはユーザがリクエストに関連したユーザが必要で、このプロセスのために、認証フェーズの後に直接実行されます。\nShieldは2つのタイプのリソースを定義します。クラスタとインデックスです。 これらは、すべてのAPIコールで保護されます。 さらに、それらに関連したパーミッションとロールも定義できます。 一度定義をすると、ロールはユーザもしくはLDAP/ADのグループに関係します。 ロールはroles.yml設定ファイルで定義されます。 設定のサンプルは次のようになります。\nadmin: cluster: all indices: \u0026#39;*\u0026#39; : all monitor: cluster: monitor indices: \u0026#39;*\u0026#39;: monitor employee: indices: \u0026#39;company_directory\u0026#39; : read sales: indices: \u0026#39;opportunities\u0026#39; : read, write \u0026#39;accounts\u0026#39; : read, write finance: indices: \u0026#39;expenses\u0026#39; : read, write \u0026#39;purchases\u0026#39; : read, write 上記のサンプルで、次の5つのロールを定義しています。\nadmin - 管理者のロールで、すべてのクラスターレベルの操作とすべてのインデックスに対してすべてのインデックスレベルの操作を実行可能です。 (¥*インデックスはすべてのインデックスにマッチするワイルドカード) monitor - システム/クラスタのモニタリングのためのロール。このロールのユーザはすべてのクラスタとインデックスレベルの情報の読み取りの APIにアクセス可能だが、インデックスのデータへの読み書きや設定の更新は不能 employee - compnay_directoryにあるすべてのデータへの読み取りアクセスを与えられたロール。このロールはクラスタレベルへのアクセスやデータの書き込みアクセスは持っていない (特にcompany。洗濯されたグループの人々はcompanyディレクトリの更新は可能だが、employeeは読み取りのみが可能) sales - opportunitiesとaccountsインデックスの読み書きができるロール finance - expensesとpurchasesの両方に読み書きができるロール 上記のサンプルで定義されているallとreadとwriteとして名前がつけられた権限です。 これらは、予約語で、Elasticsearchのローレベルのアクションを複数含んだ権限です。 （writeはindex, delete, delete_by_query, bulk, updateの操作を含んでいます。） 多くのケースで、これらのハイレベルの名前が付けられた権限で十分ですが、特定のロールに特定のアクションを明示的に指定することもできます。 次のようになります。\nhr: indices: \u0026#39;company_directory\u0026#39; : indices:data/write/index, indices:data/write/update ここまで説明した認可のレルムは、各ユーザに関連するロールを識別するためのものです。 内部のesuserレルムでは、提供されるesuserコマンドラインツールを使ってロールはユーザに割り当てたり変更したりもできます。 LDAPやActive Directoryでは、LDAP/ADグループにShieldのロールを割り当てることができます。\n認証と認可の両方を用いることで、ユーザリクエストに対して、ユーザごとに許可/不許可をすることができます。\n暗号化通信 認可はElasticsearchのデータを機能的な観点（許可されたユーザだけが操作を可能にする）で保護しますが、 クライアントからElasticsearchクラスタへ、もしくはクラスタのノード間では暗号化されていないデータを送るためまだ危険があります。 第三者が登頂したり、オンザフライでデータを書き換えたりといった可能性やクラスタを壊すことができます。\nShield 1.0はElasticsearchのすべての通信チャネルをセキュアにすることができます。 クラスタ内のノード間のチャネルやクライアントに公開されているチャネルです。 これは、SSL/TLS通信を導入して実現します。\nShieldで使えるSSLはElasticsearchのtransportサービスをSSL/TLSで通信できるものに置き換えます。 これは、ノード間通信チャネルと、HTTP transport（REST APIを提供するもの）のそれぞれに設定可能です。\nShieldのSSL/TLSは、スタンダードなJavaのものとkeystoreとtruststoreを基本にしたものが利用可能です。 SSL/TLSを設定すると、各ノードのキーストアに証明書をインポートする必要があります。 CAがサインした証明書を使うことも、CAが信頼したものとして許可許諾されたものを使うことが可能です。 これは、信頼されたすべてのCAとして知られているtrust storeが必要です。 新しいノードをクラスタに追加するときに、すべての必要な少なくとも一つの信頼されたCAから発行されてサインされたものが必要になります。 クラスタで個別のノードがすべてのkeystore/truststoreを更新する必要性なしに。？？\n通信チャネルを安全にする方法やSSL/TLS設定をどのように行うかはShieldのドキュメントをご覧ください。\nノード間認証 強く推奨しますが、許可されたノードだけがクラスタに接続できるようにするために、ノードの認証をSSL transportに設定することができます。 これは、shield.transport.client.authにtrueを設定することで可能です。 設定した場合、ノード間でSSLハンドシェイクが行われ、接続されたノードが接続に来たノードのクライアント認証を要求しチェックします。 もし、チェックに失敗した場合は、SSLシェイクハンドが失敗し接続が拒否されます。\nSSLクライアント認証 transportレベルでノード認証が必要なようなら、次のような疑問がわくでしょう。 Elasticsearchはクラスタに接続するTransportクライアントを使うときはどのように振る舞うのか？ Transportクライアントはクラスタの他のノードと同じチャネルを使うため、コネクションを確立するときに、ノードが他のノードと異なるかどうかを見極めることはできません。\nこの時、もっとも単純な解決は、Transportクライアントも同様に許可を与えることです。 それは、認証を解決するときに、他の問題（潜在的な悪意）を引き起こします。 Transportクライアントが他のクラスタのノードを偽装しようとすることです。これは望んでいません。\n幸いなことに、良い解決方法があります。 トランスポートプロファイルです。 Elasticsearch 1.4で導入されたトランスポートプロファイルは、トランスポートレイヤー（異なるホスト/ポートにバインドされる）のために複数のネットワークチャネルを設定することができます。 Shieldはこのサポートを、プロファイルごとに異なるSSL設定をできるように拡張します。 また、ノードのタイプとクライアントプロファイルタイプの間に明確な違いを設定することも可能です。 これを用いると、2つのプロファイルを設定できるようになります。 ひとつは、クライアントのためのもので、もうひとつはクラスタのノードのためのものです。 これにより、クライアントのための認証の問題が必要なくなり、Shieldはクライアントプロファイルをもった限定されたクライアントからのリクエストを保証します。\nIPフィルタリング これは、厳密には、認証カテゴリではありませんが関係しています。 Shieldはそれ自身がIPフィルタリングのメカニズムを持っています。 これは、許可/不許可のIPのリストを設定することができます。 これらのフィルタリングのルールは複数のレベルで設定可能です。 transportチャネル、transportプロファイルレベル、そして、HTTPチャネルです。 次の設定は、それらの設定のサンプルです。（設定ファイルはelasticsearch.ymlになります）\nshield: transport.filter: allow: - \u0026#39;127.0.0.1\u0026#39; - \u0026#39;2001:0db8:1234:0000:0000:8a2e:0370:73 deny: - \u0026#39;10.0.0.0/8\u0026#39; - \u0026#39;2001:0db8:1234::/48\u0026#39; - \u0026#39;*.google.com\u0026#39; http.filter: allow: [ \u0026#39;10.0.0.0/8\u0026#39; ] deny: [ \u0026#39;127.0.0.1\u0026#39; ] transport.profiles: client: shield.filter.deny: [ \u0026#39;_all\u0026#39; ] このように、IPv4とIPv6、CIDR、ホスト名、ワイルドカードが利用できます。 また、この機能はホストOSのIPテーブルに設定することで追加できるが、Shieldにそれを保持し、それらの設定を単純化し、 デプロイの全体から除去できることにも注意してください（詳細はドキュメントのIPフィルタリングをご覧ください）。\n監査証跡（Audit Trail） セキュアなシステムの必須機能の一つで、監査硝石により、Elasticsearchに発生した重要なイベントをトラッキングすることが可能です。 これらのイベントを保存することは、Elasticsearchクラスタの重要なアクティビティの証拠を提供でき、 不審な/悪意のある可能性のあるイベントを追跡するときの診断ツールにもなります。\nShield 1.0.0で、監査証跡は監査/アクセスlogを一般的なElasticsearchのログとは個別に保存します。 それらは、構造化されているため、読んだりパースするのが容易で、イベントのタイプも分類されています。 また、情報のレベルを設定することができ、各イベントをlogレベルの設定で書き出すことができます。 以下が、イベントのリストです。\nanonymous_access_denied - 認証トークンがないユーザからのリクエストがあった時のログ authentication_failed - リクエストされたユーザの認証に失敗した時のログ access_denied - 認証されたユーザが許可されていない操作を実行した時のログ access_granted - 認証されたユーザが許可された操作を実行した時のログ tampered_request - 不正に書き換えられたリクエストが到着したのを検知した時のログ connection_granted - ノードもしくはtransportクライアントがIPフィルタのルールにパスした時のログ connection_denied - ノードもしくはtransportクライアントがIPフィルタリングルールの制限により却下された時のログ Shieldの監査証跡についてより詳しく知りたい方は、ドキュメントをごらんください。\n次のバージョンでは？ ここまで紹介したように、これはまだ始まりにすぎません。 Shieldに追加される多くの機能があり、しっかりとした基盤を構築したところです。 Shieldの次のバージョンでは、以下の機能の追加にフォーカスするでしょう。（これらだけに限ったわけではありません。）\nAPIによる設定、管理 より拡張され、柔軟なLDAP/Active Directoryサポート レルムタイプの追加（kerberos、anonymous、certificatesなどなど） セッションベースの認証 ShieldはElasticsearch社の2番目の（Marvelに続く）商用プロダクトです。 ダウンロードして開発環境で評価してください。 インストールは他のプラグインと同様の方法です（インストール方法についての詳細はこちら）。 一度インストールすると、30日の試用ライセンスが始まります。 もし、さらに時間が必要な場合は、sales@elasticsearch.comまで連絡してください。\n私たちのすべてのプロダクトについてフィードバックをお待ちしています。 Shieldの商用利用、機能、ロードマップ、その他のセキュリティに関するトピックなど、質問がありましたら、 サイトからご連絡ください。\n","date":1425030596,"dir":"post/2015/","id":"cb13b64d0127c13bb466c4d4677a7b8a","lang":"ja","lastmod":1425030596,"permalink":"https://blog.johtani.info/blog/2015/02/27/you-know-for-security-shield-goes-ga-ja/","publishdate":"2015-02-27T18:49:56+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：you know, for security: shield goes ga 1/27にShield 1.0 をリリースしました。 Elasticsearc","tags":["elasticsearch","shield"],"title":"セキュリティ向けプラグインShieldのリリース（日本語訳）"},{"contents":"4月13日から3日間、ElasticsearchのCoreトレーニングが東京で開催されます。 Early Birdということで、3/14までに申し込みすると割引があります。 興味のある方は、見ていただければと。\nまた、4/15にElasticsearch勉強会を開催します。 トレーニングに弊社のエンジニアが来日しますので、なにか話をしてもらう予定です。\n募集は後日、Elasticsearch勉強会のDoorkeeperで行います。 興味のある方は、登録しておいていただければと。\nトレーニングや勉強会でお待ちしております。\n","date":1425024629,"dir":"post/2015/","id":"f2cbe07bf2ff16d5a5860b4d6edbc5e8","lang":"ja","lastmod":1425024629,"permalink":"https://blog.johtani.info/blog/2015/02/27/2nd-tokyo-training/","publishdate":"2015-02-27T17:10:29+09:00","summary":"4月13日から3日間、ElasticsearchのCoreトレーニングが東京で開催されます。 Early Birdということで、3/14までに申し込みす","tags":["elasticsearch"],"title":"Elasticsearch Coreトレーニング開催"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：kibana 4. literally.\nKibana 4は現在、文字通り、抽象的に、概念的に、精神的に、そしてとても楽しく、プロダクションレディになりました。 1週間前に準備はできていましたが、満足できるものであるという確信を得たいと思っていました。 そして、Kibana 4.0.0 GAをリリースしました。 次のものはサンプルのスクリーンショットと前日譚です。 これらに興奮してしまった方のために、2ステップのプランを用意しました。\nダウンロードする：Kibana 4 downloadsページからダウンロードします。 理解する：Kibana 4 docsページを読んで理解します。 Tip : もし、まだ、あなたのクラスタがElasticsearch 1.4.4でない場合は、アップグレードする必要があります。\nTip2 : Kibana 4 RC1からアップグレードする場合は、configを移行する必要があります。こちらのgistを参照\n前日譚 - the back story Kibanaはすでに問題解決のためのツールになっています。 なぜ、毎晩2時に呼び出されるんでしょう？ そのコードがプロダクションに入ったのはいつですか？ その結果、何を壊しました？ 私たちはそれらを解決しました。 世界的に、長い間、だれも夜中の2時に呼び出されませんでした。知ってます？。\n*しかし、ここには落とし穴があります。*答えが簡単になれば、問題が難しくなります。 楽な勝利は簡単でした。では、難しい問題（深さが3層の問題）を解きましょう。 複数の要素、複数のフィールドそして、複数のデータソースを分析する必要がある問題を解きましょう。 Kibana 4は少ない時間と労力で最も難しい問題を解決してくれます。\nKibana 3で学んだことをKibana 4に取り込みました。 なぜ10億のデータを持っているのに、地図には1000個しかプロットできないのでしょう？ 1つのチャートに1つのフィールドなんでしょう？ なぜ、1つのパネルに1つのチャートなんでしょう？ なぜ、1つのダッシュボードに1つのインデックスなんでしょう？ 5つのシナリオを用意し、2つのフィールドにまたがったデータを比較し、 1つのダッシュボードに3つのインデックスのデータを表示してみましょう。 さぁ、やりましょう。終わったらアイスクリーム（トッピング付きの）を取りに行きましょう。\nthe plot アイスクリームのように、問題には多くの種類があります。 そのために、Kibanaをナポリ風アイスクリーム（3色アイス）のように分割しました。 嫌いな種類は除いて。 もし、あなたがKibanaのユーザ歴が長い場合、最初のタブのDiscoverがホームであることが正しく感じるでしょう。 これにより、短時間で、検索し、レコードを見つけ、簡単な問題を解決できます。 簡単な問題とは、すべてを物語る1行のデータを見つけることによって解決する問題です。\n物事が簡単な検索で説明できるものよりも複雑になった時、チャートとグラフで魔法を作る時間です。 Visualizeタブを開き、Elasticsearchのaggregationの力を利用してデータを解析しましょう。 Visualizeは複数の次元の性質のデータを見せ、今まで尋ねたことがないような質問に対して素早く回答するチャートやテーブル、 地図を作成できます。 あなたが最初に尋ねる質問は「先週サイトが遅かったのはなぜ？」でした。 しかし、データによって明らかにされた質問は「なぜ、クリスマスに東京からの平均ファイルサイズリクエストがスパイクしたのか？」です。\n最後に、Dashboardでこれらを1つにします。\n大きなスクリーンに配置して、こう言います。 「あなたの答えはこのリンクにあります。また、Wikiに埋め込んで、データをCSVにエクスポートしてメールしました。 アイスクリームを食べた後に、自叙伝の第1章を書きました。もっとアイスを持ってきてください。かき混ぜますから。」\nそれぞれのタブで見てきた詳細については、Kibana 4 Beta 1 : Releasedをごらんください。\nto be continued\u0026hellip; 居眠りをする時間はあります？いいえ、Kibana 4.1についてすでに作業中で、将来の大きなプランを持っています。 多くの労力はKibana 4の土台の安定と実用性を構築することに使われました。 また、Elasticsearchアプリケーションの将来を構築するプラットフォームを作りました。 すべてのものは拡張できるように設計されています。 例えば、可視化はより良くなるように構築されています。 オープンソースは私たちのGitHubアカウント以上のものです。 それは、新しく素晴らしいものを誰もが作ることができる構造を作ることが私たちの約束です。\nKibanaでグラフなどを構築したり、Elasticsearchを利用したアプリケーションを作成するために、 私たち開発者のブログを参考にしてください。 ちょっと見てみたいですか？ Elastic{ON}15のSpencer Algerのトークをチェックしてください。\nあなた方なしでは、私たちはここにはいないですし、あなた方の助けがなければ何もできません。 ぜひ、GitHubでのissueや提案、貢献をお待ちしています。 もしくは、IRCでFreenodeの#kibanaに参加してください。\nextra credit Kibana 4のすべての話に興味がありますか？私たちのKibana 4ベータに関する過去のブログをチェックしてください。\nKibana 4 Beta 1: Released Kibana 4 Beta 2: Get it now Kibana 4 Beta 3: Now more filtery Kibana 4 RC1: Freshly baked 最後に、Kibanaの利用に関する話をお持ちなら、ぜひ聞かせてください。 stories at elasticsearch dot comもしくは@elasticsearchに連絡をください。 あなたの話を世界にどのようにシェアしているかごらんください。\n","date":1424408752,"dir":"post/2015/","id":"eee039f49a5b570599cf459c55c649f3","lang":"ja","lastmod":1424408752,"permalink":"https://blog.johtani.info/blog/2015/02/20/kibana-4-literally-ja/","publishdate":"2015-02-20T14:05:52+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：kibana 4. literally. Kibana 4は現在、文字通り、抽象的に、概念的に、精神的に、そしてとても楽しく","tags":["elasticsearch","kibana4"],"title":"Kibana 4（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch 1.4.4 and 1.3.9 released\n本日（2/20）、Elasticsearch 1.4.4とElasticsearch 1.3.9をリリースしました。 これはバグフィックスリリースとなります。 主に、Lucene expression scriptsを使う場合のRPMとDEBパッケージの パッケージング問題のフィックスをしたものです。 1.4.4のダウンロードこちらのリンクからアクセスできます。\nfixes 1.4.3のRPMおよびDEBパッケージにはAntlrとASMの依存関係の不足がありました。 この依存はElasticsearchでLucene expression scriptsを利用する場合に必要になります。 Groovyに関する1.4.3の変更により、多くのユーザがLucene explression scriptsを利用することが予想されるため、すぐに、1.4.4をリリースしました。\nまた、このリリースには、クラスタの保留タスクに関するいくつかのバグフィックスも含まれています。 さらに、date histogramで負のインターバルの場合にOutOfMemoryErrorを引き起こすバグも 修正されています。\nすべての変更については1.4.4のリリースノートおよび1.3.9のリリースノートをごらんください。\nフィードバック 私たちはフィードバックをお待ちしています。 Twitter(@elasticsearch)もしくはGitHub issues pageで教えてください。\n","date":1424408734,"dir":"post/2015/","id":"ddd3e6f6e298d3884abc4d888a043664","lang":"ja","lastmod":1424408734,"permalink":"https://blog.johtani.info/blog/2015/02/20/elasticsearch-1-4-4-and-1-3-9-released-ja/","publishdate":"2015-02-20T14:05:34+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.4 and 1.3.9 released 本日（2/20）、Elasticsearch 1.4.","tags":["elasticsearch"],"title":"Elasticsearch 1.4.4および1.3.9リリース（日本語訳）"},{"contents":"来る、4月4日の土曜日の午後に名古屋でElasticsearch勉強会を開催予定です。 「初」の東京以外の勉強会です。\nTwitterでこのようなツイートを見かけまして。\n名古屋でElasticsearchの勉強会やりたい機運（今のところ2人）。\n\u0026mdash; mogami (@smogami) 2015, 2月 4 これは！ということで、名古屋で勉強会をやろうかと思います。30名程度の場所を借りて実施予定です。 募集はいつもの、elasticsearch勉強会のDoorkeeperで行う予定です。 ページの準備まで少々待ちください。（おそらく、3月中旬くらい） 私自身はElasticsearchやELKについて話をしようと思っています。そのほかに、2,3名のスピーカーの方を予定しています。 LTなど興味がある人がいたら、連絡ください。\nこれを機に（？）他の場所でも勉強会を開催したいと考えています。 ニーズがどのくらいありそうなのかが、まだよくわかっていませんが、関西などでニーズがあるんじゃないかと期待していたり。\n興味のある方は、コメント欄、Twitterなどでコンタクトしてもらえればと。 （連絡来るとうれしいなぁ。）\n","date":1424240573,"dir":"post/2015/","id":"5b97ead91c0dd0bad57b4f43a89149a2","lang":"ja","lastmod":1424240573,"permalink":"https://blog.johtani.info/blog/2015/02/18/preparing-elasticsearch-meetup-in-nagoya/","publishdate":"2015-02-18T15:22:53+09:00","summary":"来る、4月4日の土曜日の午後に名古屋でElasticsearch勉強会を開催予定です。 「初」の東京以外の勉強会です。 Twitterでこのよう","tags":["elasticsearch","勉強会"],"title":"名古屋でElasticsearch勉強会を開催します"},{"contents":"第8回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n今回は出足が好調で、早々に180人の枠を超えるという嬉しい事態でしたが、 キャンセル待ちが残っているにもかからわらず、来られていない方が67名もいるということで、キャンセル待ちの方には申し訳なかったです。 もうすこし、キャンセルをしてもらえると嬉しいんですが。。。 今回はメールを当日に1度しか打ってないからかなぁ。\nさて、いつもの通り簡単なメモです。 本当に簡単にですが。\n「Elasticsearch導入チェックリスト？」 Elasticsearch株式会社 Jun Ohtani @johtani スライド：Elasticsearch導入チェックリスト？\nElasticsearchを開発環境や本番に導入する前に気にかけて欲しいことについて発表しました。 元ネタはelasticsearch pre-flight checklistです。 少々古いのですが、私が今回話した内容以外にもモニタリングなどについての話も盛り込まれています。 時間がある方は、見ていただければと。\n「Elasticsearch クエリとスキーマ定義のすごい細かい話」株式会社ドワンゴ 藤堂淳也 さん スライド：Elasticsearch クエリとスキーマ定義のすごい細かい話\nフィールドのチェックを別途インデキシングするアプリで行っている。利用できるものだけElasticsearchに投げる 実際に本番環境で利用しているマッピングに対してフィールドを追加する手順について 「これもドキュメントに書いてあるんですが」という感じでドキュメントに色々書いてあるので読みましょうというありがたい発表でした。 実際に試行錯誤したり検証するときに行ったことを喋ってもらえたので、どういった点を気にしながら運用、設計するかというのがわかりやすかったです。\n「ElasticsearchとKibanaで実現する、30億req/dayのリアルタイム分析」株式会社サイバーエージェント　山田直行さん　@satully スライド：ElasticsearchとKibanaで実現する、30億req/dayのリアルタイム分析\n会場が21時までしか抑えられていないという失態で、ドタバタしてて前半は聞けてないです。。。\n前回の発表では30日分Elasticsearchに入れていたが、今は3日分のみ保存 レポートなどにはRedshift＋Tableauを利用 Kibana3をメインに使っているが、Kibana4も検討予定？ QA\nQ：なぜ、ELBを挟んでいるのか？ A：特に考えておいているわけではない。 Q：インデックスの構成は？ A：1日に2つのインデックス。Bitされたもの、入札されないもの Q：searchのnodeをやめたのは？ A：前回発表した勉強会での懇親会で話を聞いたり、他の方と話を聞いて、不要と判断したため 「はてなのメディア面を支えるElasticsearch」株式会社はてな　山家雄介さん　@yanbe スライド：未定。おそらく、開発者ブログに公開されるかと。\n\u0008* アドテク系にもやってるらしい。BrandSafeはてな\nはてなブックマークのデータを魅せ方を変える機能などで大活躍。B!KUMAとか その日の話題の見出し自動生成機能。Significant Terms Aggregationsを利用。 こちらの「自然言語処理技術を用いたはてなブックマークの新機能「トピック」をベータリリースしました」エントリに関係あるのかな？ 記事の魅せ方を検索できる管理画面ではElasticsearchのクエリDSLを活用されているとのことでした。 検索専門の人でなくても検索式を簡単にくみたてられる画面を用意して、ElasticsearchのクエリDSLに変換するようにしていると。 確かに、クエリをそのまま組み立ててもらうよりも利用しやすい画面がある方がいいですよね。バックエンドはJSとPerlのライブラリとのことでした。\nその他、感想などのブログ 2015-02-13 第8回 elasticsearch 勉強会 @ 丸の内 リクルート 41Fアカデミーホール [Elasticsearch] 第8回 elasticsearch 勉強会へ参加してきた 第8回elasticsearch勉強会 #elasticsearch #elasticsearchjp 第8回 Elasticsearch 勉強会に行ってきた #elasticsearch #elasticsearchjp 勉強会メモ - 第8回elasticsearch勉強会 まとめ 今回も検索からログまでいろんな話になったので、面白かったかと。 参加された方は新しい方が多かったんじゃないかなぁと。（集計結果で見れないのかな、Doorkeeper）。\n今回は、みなさんに21時に41Fから33Fへ移動していただくという大失態があったので、大変申し訳なかったです。 次回（4月中旬）は、このようなことがないように気をつけますので、今後もよろしくお願いいたします。\nあと、東京以外の勉強会も検討しつつあります。興味のある方はコメントやTwitterで反応をいただけると嬉しいです。\nスピーカーは随時募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1424066543,"dir":"post/2015/","id":"997acc135d01b54f7de77a432fb9133f","lang":"ja","lastmod":1424066543,"permalink":"https://blog.johtani.info/blog/2015/02/16/8th-elasticsearch-jp/","publishdate":"2015-02-16T15:02:23+09:00","summary":"第8回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第8回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：running groovy scripts without dynamic scripting\nElasticsearch1.3.8と1.4.3のリリースにより、デフォルトで、リクエストに含まれるGroovyスクリプトや インデックスに保存されたスクリプトを動的に実行する機能をオフにしました。 しかし、Groovyはまだデフォルトのスクリプト言語です。 本ブログ記事では、少しだけダイナミックだが、サンドボックスではない言語のためのスクリプトを どのように使い続けるかを説明します。\n本ブログ記事は、それが何を意味し、さらに重要なのは、安全に重要なタスクを実行させるためにスクリプトを どのように使用し続けるかを理解する助けとなるはずです。\nダイナミックスクリプトとは？ Elasticsearchに詳しくない方のために、Elasticsearchでは、 さまざまなリクエストの一部としてスクリプトを送信することができます。 search、aggregation、update、upsert、delete by queryなどです。 あなたのユースケースのために、通常の動作よりも拡張した動作をさせるためにスクリプトを追加できます。\n例えば、以下のリクエストは、ダイナミックスクリプトを含んでいます。 field1とfield2 + shiftが同じ値を持っている時だけドキュメントを返します。\nGET /_search { \u0026#34;query\u0026#34;:{ \u0026#34;filtered\u0026#34;:{ \u0026#34;filter\u0026#34;:{ \u0026#34;script\u0026#34;:{ \u0026#34;script\u0026#34;:\u0026#34;doc[\u0026#39;field1\u0026#39;].value == (doc[\u0026#39;field2\u0026#39;].value + shift)\u0026#34;, \u0026#34;lang\u0026#34;:\u0026#34;groovy\u0026#34;, \u0026#34;params\u0026#34;:{ \u0026#34;shift\u0026#34;:3 } } } } } } 言語を変えることもできます。 それは、当然、シンタックスが変わったり、制限が追加（例えば、Groovyスクリプトの代わりにLucene　Expressionsに変更）されることもあります。 langパラメータによって言語を指定できます。\nなぜそれはダイナミック？ 上記の例はダイナミックスクリプトです。 それは、実際のスクリプトの部分はサーバサイドで動的に解釈されコンパイルされる必要があるからです。 ダイナミックスクリプトはElasticsearchのAPIによってデータノードに送信されます。 これは、インデックスされたスクリプト(indexed script)も含みます。\n言い換えると、もし、スクリプトがデータノード全てに保存されていなければ、 それは、ダイナミックスクリプトとして扱われます。\ndynamic scriptingをオフにするとどうなるか？ 最新のリリースでの変更により、Groovyのdynaic scriptingはデフォルトでオフになりました。 先ほどのスクリプトについても同様で、もし、先ほどのリクエストを実行すると、次のようなエラーが発生します。 (一部省略してあります。)\n{ \u0026#34;error\u0026#34;:\u0026#34;SearchPhaseExecutionException[Failed to execute phase [query], all shards failed; shardFailures {[8FJ02MofSnqVvOQ10BXxhQ][test][0]: SearchParseException[[test][0]: from[-1],size[-1]: Parse Failure [Failed to parse source [{...}]]]; nested: ScriptException[dynamic scripting for [groovy] disabled]...\u0026#34;, \u0026#34;status\u0026#34;:400 } エラーメッセージの重要な箇所は「ScriptException[dynamic scripting for [groovy] disabled]」です。\nスクリプティングを使い続けるには？ Elasticsearchでスクリプトを実行するには3つの方法があります。 2つのダイナミックな方法は、リクエストごとのスクリプト（上述）かインデックスされた スクリプト(indexed script)を使う方法です。 インデックスされたスクリプトを使うことは、Elasticsearch自身にGroovyスクリプトを保管することで 利用で、それらを要求に応じて利用することです。 （これは、実際には十分機能しますが、これではまだ、信頼できないユーザに対して彼らのスクリプトを実行できます） RDBのように保存されたプロシージャとして同じ方法で実行させるものと同様です。 前もって、スクリプトを記述しておき、リクエストの一部として後から、名前で呼び出して実行可能です。\nGET /_search { \u0026#34;query\u0026#34;:{ \u0026#34;filtered\u0026#34;:{ \u0026#34;filter\u0026#34;:{ \u0026#34;script\u0026#34;:{ \u0026#34;script_id\u0026#34;:\u0026#34;your_custom_script\u0026#34;, \u0026#34;lang\u0026#34;:\u0026#34;groovy\u0026#34;, \u0026#34;params\u0026#34;:{ \u0026#34;shift\u0026#34;:3 } } } } } } あまり変わっていないことに気づくでしょう。 scriptの部分が、前もって記述されたスクリプトの名前script_idに変更されただけです。\nElasticsearchにスクリプトを提供するダイナミックではない方法はインデックスに保存する代わりに、 ディスクにファイルとしてスクリプトを保存することです。 そうすることで、各スクリプトを設定として保存します。 これは、どのようなスクリプト言語に対してもダイナミックスクリプティングをオフにしたまま、 サンドボックス化されないスクリプトを使い続けることができる方法です。\n最初のサンプルで、Groovyスクリプトはdoc['field1'].value == doc['field2'].value + shiftでした。 これを、.groovy拡張子を持ったファイルとして書き出すことができます。\ndoc[\u0026#39;field1\u0026#39;].value == (doc[\u0026#39;field2\u0026#39;].value + shift) もし、このファイルにyour_custom_script.groovyちう名前をつけて、 Elasticsearchのすべてのデータノードのconfig/scriptsディレクトリに保存すると、 Elasticsearchは60秒（elasticsearch.ymlのwatcher.intervalで変更可能）でこのスクリプトを認識し、今後のリクエストに利用できるようにプリコンパイルするでしょう。 そのファイルはElasticsearch実行ユーザによって読み込みができる必要があります。 これをディスクに書き込んだ後、あなたの設定ディレクトリは次のようになっています。\nconfig/ elasticsearch.yml logging.yml scripts/ your_custom_script.groovy これは、各リクエストやインデックスされたスクリプトをスクリプトとして動的に送信しませんが、 信頼された環境にスクリプトを追加することでダイナミックスクリプトとなることを許します。\nディスクに書かれたスクリプトを使用する スクリプトは、ロードされたスクリプトになるまでは、利用できません。 ログファイルに次のようなログが表示されるまではです。\n[2015-02-11 11:14:47,066][INFO ][script ] [Sergei Kravinoff] compiling script file [/path/to/elasticsearch-1.4.3/config/scripts/your_custom_script.groovy] すべてのElasticsearchのデータノードでスクリプトが読み込まれたら、 それを利用することができます。 利用するために、file（script_idではありません！）としてスクリプト名を指定します。\nGET /_search { \u0026#34;query\u0026#34;:{ \u0026#34;filtered\u0026#34;:{ \u0026#34;filter\u0026#34;:{ \u0026#34;script\u0026#34;:{ \u0026#34;file\u0026#34;:\u0026#34;your_custom_script\u0026#34;, \u0026#34;lang\u0026#34;:\u0026#34;groovy\u0026#34;, \u0026#34;params\u0026#34;:{ \u0026#34;shift\u0026#34;:3 } } } } } } Note:langは必須ではありません。Groovyがデフォルトの言語のためです。 もし、違うスクリプト言語を使いたい、もしくは、デフォルトの言語を（例えば、Lucene Expressionsへ） 変更したい場合、言語が正しいスクリプトを見つけるために提供されている必要があります。 一番良い方法は、アプリケーションがlangパラメータを含んでいることを勧めます。 これは、将来、デフォルトのスクリプト言語が変更されても、問題ないからです。\n質問？ もし、質問があれば、遠慮なくTwitter(@elasticsearch)で教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1423721589,"dir":"post/2015/","id":"1fed22e99b0e11a50eb7b92cb1644e8a","lang":"ja","lastmod":1423721589,"permalink":"https://blog.johtani.info/blog/2015/02/12/running-groovy-scripts-without-dynamic-scripting-ja/","publishdate":"2015-02-12T15:13:09+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：running groovy scripts without dynamic scripting Elasticsearch1.3.8と1.4.3のリリースによ","tags":["elasticsearch"],"title":"Groovyスクリプトをダイナミックスクリプトなしで実行(日本語訳)"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch 1.4.3 and 1.3.8 released\n本日、Lucene 4.10.3をベースにしたElasticsearch 1.4.3と、セキュリティとバグフィックスリリースである、Elasticsearch 1.3.8をリリースしました。 ダウンロードおよび変更リストはそれぞれ次のリンクからアクセスできます。\n最新ステーブルリリース：Elasticsearch 1.4.3 1.3.x系バグフィックス：Elasticsearch 1.3.8 過去のリリースに関するブログ（公式）はこちら。\n1.4:1.4.2, 1.4.1, 1.4.0, 1.4.0.Beta1 1.3:1.3.7, 1.3.6, 1.3.5, 1.3.4, 1.3.3, 1.3.2, 1.3.1, 1.3.0. すべての変更については1.4.3のリリースノートおよび1.3.8のリリースノートをごらんください。 以下では、セキュリティの問題について紹介します。\ngroovy scripting の脆弱性 Elasticsearchのバージョン1.3.0から1.3.7および1.4.0から1.4.2で、Groovyスクリプトエンジンに脆弱性が発見されました。 脆弱性は、攻撃者がGroovyスクリプトをサンドボックスを避けて構築でき、 ElasticsearchのJava VMを実行しているユーザとしてシェルコマンドを実行できます。\nこの問題をCVE-2015-1427として報告済みです。\nバージョン1.3.8と1.4.3では、デフォルトで、Groovyに対してのサンドボックスをオフにしました。 結果として、ダイナミックスクリプトの実行はGroovyに対してもオフとなります。\nもし、脆弱性のあるバージョンで実行している場合、v1.3.8かv1.4.3にアップグレードするか、ダイナミックなGroovyスクリプトをクラスタの すべてのノードに対して次の設定を追加することで、オフにします。\nscript.groovy.sandbox.enabled: false これは、Groovyのサンドボックスをオフにし、リクエストの一部としてインラインで受け付けるダイナミックなGroovyスクリプトや 特殊な.scriptsインデックスに保存されているスクリプトを実行しません。\nそれまでは、各データノードのconfig/scriptsディレクトリにファイルとして保存されたGroovyスクリプトは まだ、利用可能です。詳細の情報についてはRunning scripts without dynamic scriptingをごらんください。\nfuture scripting plans 安全なダイナミックスクリプティング言語としてGroovyを失うことは、Elasticsearchにとって痛手です。 update APIやsearch APIやaggregationsフレームワークの一部としてScriptを使います。 それらは、静的なAPIでは簡単に表現できない、カスタムなトリックをユーザに実行できるようにします。\n残念ながら、Groovyチームとこの問題を議論した後、Groovy言語もサンドボックスによってきちんと保護されている というにはあまりにもダイナミックであるという結論に達しました。 Groovyは、デフォルトでは利用できなくなります。 利用可能なダイナミックスクリプト言語としてはLucene Expressions言語のみとなります。 Expressionsははやいですが、それらは非常に限定されています。数値のフィールドでのみ実行可能で、ループをサポートしていません。\nより強力で（しかし安全な）ミニ言語になるようにExpressionsを拡張することを調査しています。 これは、Scriptユーザが現在持っている最も一般的なユースケースを少なくとも助けるでしょう。 この拡張は長期間のプロジェクトであり、進化には時間がかかるでしょう。\nぜひ、Elasticsearch 1.4.3をダウンロードして、試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1423712393,"dir":"post/2015/","id":"5badf61ecb9cfadd7d6af58712fa5f6f","lang":"ja","lastmod":1423712393,"permalink":"https://blog.johtani.info/blog/2015/02/12/elasticsearch-1-4-3-and-1-3-8-released-ja/","publishdate":"2015-02-12T12:39:53+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElas","tags":["elasticsearch"],"title":"Elasticsearch　1.4.3および1.3.8リリース（日本語訳）"},{"contents":"今年もCROSS参加しました。そして、話もしてきました。 今年は横浜の大さん橋でした。横浜はあんまりこないので、乗り換えでおたおたしてしまいましたが。。。\nなかなかいい景色でした。（寒いけど） 「おおさんばし」って読むんですね。「だいさんばし」だと思ってた。。。\n以下はいつもの、自分用メモです。\n俺はどうしてそのデータストアを選択したのか 〜銀河と小宇宙を語る会〜 http://2015.cross-party.com/program/c1\n遅れて入ったので、ちゃんと聴けてないです。\n最近注目しているデータストアは？ Postgresql。JSON型が気になってる。 AiroSpike。データ型のあるデータストアが気になってる。 MongoDB。JSON使いたいなら、これじゃないの？ AWSのAurora。インスタンスタイプを選ばなくていい（選ばないといけないらしい）とか、勝手にスケールしてくれるし、MySQL互換。 今こそ語るエンジニアの幸せな未来 http://2015.cross-party.com/program/x3\n「無職初日です。」 Web系の人？とか質問されて、自分が何系かいつもわからなくなるなぁ。 「働きがいは会社が提供するのか、個人が見つけるのか？」 個人かなぁ。会社がなにをやってるかにもよる気がするかなぁ。 「辞めると伝えると、やりたいようにやれって言われるw」 リモートできるかできないか。 「働きがい」というキーワードが出てると普通は怪しい会社w 今は、働きやすさを高くしないと人が雇えなくなってきている。 欧米のミドルウェアだと、35歳定年説はない。→日本でもそうじゃないですか？ 漫然と進んでるとダメ。→そりゃそうだ。 全文検索エンジン群雄割拠〜あなたが使うべきはどれだ！〜 http://2015.cross-party.com/program/c4\nスライド：https://speakerdeck.com/johtani/elasticsearchfalseshao-jie-tote-zheng-cross-2015\n楽しんでいただけましたでしょうか？ ちょっと話が長くなってしまい、あとの方の時間が少なかった気がしますが。。。\nKibanaのバックエンドとして認識されている人もいたので、検索エンジンですよというのをアピールするいい機会になったので良かったです。 もちろん、Kibanaとの組み合わせも面白いので、少しでも興味をもっていただき、触っていただけたらなぁと。\n話をする機会を用意していただいた、やまかつさん、その他のスピーカーのみなさん、ありがとうございました！。\nElasticsearchに関して何か興味質問などありましたら、気軽にコンタクトしてください。Twitterとかブログコメントなどで。\nプレモルタイム以降 プレモルの写真撮るの忘れてました。。。重要なのに。。。\n美味しくプレモルをいただきながら、何人かの方に声をかけていただき、話をすることができました。 こういう時間がとってあるのがいいですよね。 色々なところでElasticsearchを使っていただいているようで、うれしい限りです。 DMMの方とも話ができたし。\nまとめ 今年はプレモルを飲みに行くだけかなぁと思っていたのですが、話をする人になってました。（おかしいなぁ） 来年もあれば、きっと参加するかなぁと。ではまた来年！\n夜景きれいですね。（端っこに写ってる船は飛鳥IIでした。）\n","date":1422500368,"dir":"post/2015/","id":"fe6ba10cc6c9509b4b22e9d59e029775","lang":"ja","lastmod":1422500368,"permalink":"https://blog.johtani.info/blog/2015/01/29/talk-at-cross2015/","publishdate":"2015-01-29T11:59:28+09:00","summary":"今年もCROSS参加しました。そして、話もしてきました。 今年は横浜の大さん橋でした。横浜はあんまりこないので、乗り換えでおたおたしてしまいま","tags":["勉強会","elasticsearch"],"title":"CROSS 2015で話をしてきました #cross2015"},{"contents":"今年は大晦日になってしまいました。しかも、ちょっと飲んでたり。。。 第9流しながら書いてます。\n振り返り(2013年に書いた抱負から) まずは昨年書いた抱負からの振り返りです。\nElasticsearch勉強会の継続、Solr勉強会の継続＋ミックスした検索勉強会の開催 IDEAのさらなる活用 もっと開発(プラグインとか) AWSをもう少し活用 海外のイベントに行ってみたい 読書と英語を継続 AWS活用できてないです、、、 ミックスした勉強会は、ドタバタしててできませんでした。\nIDEAはさらなる活用までいってるかは不明ですが、最近は隣にとても詳しい人が座っているので色々と教えてもらってます。 開発については、ちょっとずつですが、PR書いたりしてます。\n振り返り(今年あったできごと) 初海外（ベルリンとアムステルダム） Elasticsearchに転職 初献本? Elasticsearch勉強会の定期開催 ElasticSearch Serverの翻訳 サーバ/インフラエンジニア養成読本の執筆 勉強会以外でもスピーカー 英語の継続（切実） 初ものが多かったです。 初の海外の会社、初の海外旅行（仕事）、初の献本（著者の人から、多分、初）、初の翻訳本、初のムック本執筆などなど。\n初の海外でした。なのに、夏には海外の会社に転職してみてるとか、ちょっと自分でも信じられません。 ベルリンでは、海外の勉強会にも参加できて非常に有意義でした。 ヨーロッパの街並みは、日本では経験できない雰囲気で、向こうの方には普通の街並みも自分にはとても新鮮でした。\n転職自体は2回目ですが、海外の会社というのは初めてです。日々、英語\u0008の勉強になりますし、いろんな刺激を受けています。 英語の勉強自体も継続中です。英語力が不足しているのは自覚してるので、少しでも英語に触れるようにDLifeで海外ドラマを録画して、通勤時間帯にみるなどを試みてます。\n書籍には、昨年につづき関わることができました。来年も何かしらの書籍に関われることができればなと。 （\u0008気になる人は以下のリンクから。。。）\n分かりきったことですが、Elasticsearchな1年でした。 転職してあっという間の半年です。まだまだやりたいことがいっぱいあるので、来年もバランスよく頑張らないと。\n来年の抱負 英語の継続 海外のイベントへの参加 多岐にわたるイベントでのスピーカー 日本の人員の倍増！？ Elasticsearchに関する日本語の情報発信 Elasticsearch座談会みたいなものの開催 英語の継続については書くまでもないですね。 海外のイベントへの参加もかなぁ。3月にサンフランシスコに行くとは思います。 そのほかには、今度こそBerlin Buzzwordsに行きたいです。\nElasticsearch勉強会以外のイベントでもElasticsearchを広めるべく色々なところでスピーカーをしたいなと思っています。 検索、ログ解析で少しは知名度が上がってきていますが、別の言語のコミュニティやイベントでは、まだまだ、elasticsearch自体を知らない人もいると思います。まずは知ってもらうところからかなと。\n日本の人員の倍増については、今年も達成してます（一人が二人になりましたw）。 来年も倍増できればうれしいなと。同じ母国語の同僚がいるのはやっぱりうれしいし、心強いですから。\n来年は（も）、日本語での情報をどんどん発信していきます。サイトやガイドなども 日本語にしたいなと。 あとは、これまで、勉強会でスピーカーをしていただいた人だけを集めた座談会のようなものも開催したいなと考えています。 私自身も色々と聞きたいことがありますし。 そのほかにも色々と要望をお待ちしています。Twitterやブログのコメント欄などで気軽にコンタクトしていただければと。\n最後は、いつものようにですが、来年も勉強会やいろんなイベントに参加する予定です。 ブログも週1程度で書く努力しないとなぁ。 こんな話を書いてくださいとかのリクエストもお待ちしています。\n今年はあと、数時間ですが、色々とお世話になりました。 この場を借りてお礼申し上げます。\n来年も、いろんな方に絡んでいくとは思いますが、よろしくお願いいたします。\n","date":1420026086,"dir":"post/2014/","id":"b36abffbe5d6a0de73a9968604a1a3f9","lang":"ja","lastmod":1420026086,"permalink":"https://blog.johtani.info/blog/2014/12/31/looking-back-2014/","publishdate":"2014-12-31T20:41:26+09:00","summary":"今年は大晦日になってしまいました。しかも、ちょっと飲んでたり。。。 第9流しながら書いてます。 振り返り(2013年に書いた抱負から) まずは昨年","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2014）"},{"contents":"この記事はElasticsearch Advent Calndar 2014の25日目のエントリです。\nあっという間に最終日です。来年につなげるという意味で、Elasticsearchの2系のIssueをいくつかピックアップして紹介してみます。\n現在、ElasticsearchのGitHubリポジトリは、大きく3つのブランチで作業しています。 master、1.x、1.4です。masterと1.xの大きな違いとしては、masterはLuceneの5.x系を採用している点です。\nなお、これから紹介するIssueは現在、確定していない項目も含んでいます。実際に2.0がリリースされるタイミングでは 採用されない場合もあります。\nUpgrade master to lucene 5.0 snapshot #8347 (closed) https://github.com/elasticsearch/elasticsearch/pull/8347\n先ほど書きましたが、Luceneの5に対応するためのPRです。 Lucene 5に関してはLuceneのコミッターのMikeさんのブログ記事も参考になります。\nLucene 5に変更することで、BitSetに関する改善が多く含まれることになります。 メモリの利用量、圧縮などの改善が多く含まれています。 もう1点大事な点としては、Lucene 5系ではLucene 3系のインデックスを読み込むことができなくなる点です。 Luceneの下位互換の範囲は1つ前のメジャーバージョン（5.x系の場合は4.xまでが対象）となっています。\nFilter cache: add a _cache: auto option and make it the default.（closed） https://github.com/elasticsearch/elasticsearch/pull/8573\nFilter cacheは、trueもしくはfalseの設定が利用できますが、filterの種類にも依存します。 その辺りの条件を加味しつつ、よしなにCacheをコントロールしてくれます。\nRemove and/or/not in favour of bool filter #8960（open / discuss） https://github.com/elasticsearch/elasticsearch/issues/8960\n似ているが少し異なるand、or、notフィルタとboolフィルタが存在しています。 これらをわかりやすくするために、boolフィルタに統一しましょうという話し合いをしています。\nInput validation #9059（open / discuss） https://github.com/elasticsearch/elasticsearch/issues/9059\n色々な入力に関するチェックを追加しようというIssueです。 たとえば、ディレクトリ名やファイル名、URLのパスやクエリストリング、フィールドのパスやスクリプトなどです。 Validationがあると、変な設定をして頭をかかえることもなくなるかなぁと。\nRefactor analysis framework #8961（open） https://github.com/elasticsearch/elasticsearch/issues/8961\n新しくAnalyzerを作った場合に、色々な場所に登録必要があったりします。インデックスレベルとノードレベルです。（Kuromojiプラグインなどが参考になります。） また、インデックスごとにカスタムのAnalyzerを設定するので、1つのノードに同じAnalyzerを何度も設定しないといけません。 よりシンプルにするために、Analyzerをノード単位で設定しようという提案です。\nRemove possibility for conflicting field definitions and ambiguous field resolution #8870（open） https://github.com/elasticsearch/elasticsearch/issues/8870\n同じインデックスに、異なるtypeで、同じフィールド名があった場合、いろいろと良くないことがあったりします。 たとえば、フィールドのタイプがintegerとstringと異なる場合に、インデックスレベルで検索を行うとうまく検索できなかったりと。 この問題を解消するために、より明確にしようというIssueです。 たとえば、フィールド名を指定するためには、フルパスで記述をするだとか、フィールドマッピングに関してはインデックスレベルで内部で保持をするなど。\nValidation of mappings request to reject unsupported fields #7205（closed） https://github.com/elasticsearch/elasticsearch/issues/7205\n1.xでも取り込まれますが、嬉しい機能なので紹介します。 これまでは、mappingsでスペルミスをした場合（たとえば、field設定で\u0026quot;indexx\u0026quot;といったミス）には、その項目は単に無視されるだけでした。 これが、v1.xでは、エラーに\nまとめ ということで、簡単ですが、v2.0.0に向けたIssueをピックアップして紹介してみました。 上記以外にも多くの改善、提案が2.0に向けて行われています。 興味のある方は、v2.0.0ラベルでIssueを検索してみてはいかがでしょうか？\n今年もあとわずかとなりました。 今年の2月にElasticsearchの1.0がリリースされ、あっという間に1.4なりました。まだまだ改善しています。\n来年もElasticsearchに興味をもっていただければ嬉しいです。 Elasticsearch初のユーザカンファレンスのサイトもオープンしました。 Elasticsearchに関するいろいろな話が聞ける機会だと思います。登録をお待ちしています。\n","date":1419490380,"dir":"post/2014/","id":"cb9649eca3dfbd356527ffc88f1dcb94","lang":"ja","lastmod":1419490380,"permalink":"https://blog.johtani.info/blog/2014/12/25/pickup-elasticsearch-2-0-0-labels/","publishdate":"2014-12-25T15:53:00+09:00","summary":"この記事はElasticsearch Advent Calndar 2014の25日目のエントリです。 あっという間に最終日です。来年につなげるという意味で、Elasti","tags":["elasticsearch"],"title":"Elasticsearch 2.0系のIssueの紹介"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：marvel 1.3.0 released\n12/17に、Elasticsearch Marvel 1.3.0をリリースしました。 Marvelの以前のリリースから、Elasticsearchでは様々なことがありました（Elasticsearch 1.4のリリースなど）。 このバージョンでは、モニタリングにクエリキャッシュや新しいcircuit breakerなどのような機能を追加してあります。 Senseのナレッジベースは最新のAPIを含むものに拡張されています。 また、Shieldのリリースに向けた準備として、HTTPsのサポートも追加しました。\nアップグレードのために、Elasticsearchの全てのノードに最新版のMarvelプラグインをインストールする必要があります。 また、他のJavaプラグインと同様に、Marvelの新バージョンを有効にするために、各ノードを（1台ずつ）リスタートする必要があるでしょう。 アップグレードプロセスについての詳細は、Marvelドキュメントをごらんください。\nまとめとして、ここに本リリースに関する改善点をいかにリストアップしておきます。\nagent 追加： httpsのサポート デフォルトのMarvelの設定（以前は常に9200）ではなく、ローカルノードのポートを自動的に検出 改善： marvelインデックステンプレートに関するエラーチェックと耐障害性(それに対するチェックと追加時のチェック) エラーログに関するくり返しの抑制 URLパラメータによるインデックス名を指定する_bulk exportコマンド。これは、rest.action.multi.allow_explicit_indexがfalseに設定されているときに有用 修正： ES 1.4.0のtribe nodeがMarvelのインストール時に初期化されない問題 削除： UIで表示されないoptional shard level statsを除去 monitoring ui 追加： ES 1.4.0で導入された新しいcircuit breakerを追加 circuit breakerのlimitをグラフにプロット QueryCacheのグラフを追加 index throttlingのグラフの追加 Index writerとバージョンのmapのメモリ使用量のグラフの追加 修正： Network Transport Bytes Receivedグラフに実際の送信量を表示 Node Statsダッシュボードでいくつかのスレッドプールの不足 sense 追加：\nmappingsをインデックスでオートコンプリートするしないの設定を可能に Cluster Reroute API Search APIのQuery Cacheパラメータ Analyze API Validate Query API Put Percolator API cluster.routing.allocation.*設定 Function Scoreクエリのweightパラメータ Flush API Terms Aggregationのshow_term_doc_count_errorパラメータ Update API _geo_distanceソートオプション Significant Terms aggregationを1.4.0にアップデート Mapping APIにメタデータフィールドを追加 Get Index API Scripted Metric Aggregation simple_query_stringクエリ More Like Thisクエリを1.4.0にアップデート has_childクエリ/フィルタのmin_childrenとmax_childrenオプション terms aggs/significant terms aggsのヒントオプション Mappings APIのtransform インデックスされたscriptとtemplate \u0008* Geo Bounds aggregation Top Hits aggregation Terms aggregationのcollect_modeオプション Percentiles Rank aggregation Disk Threshold Allocator設定 修正：\nURLオートコンプリートの挙動（プロトコルとホストのような組み合わせ） nested typeマッピングのinclude_in_parentとinclude_in_rootの不足 Rangeフィルタでのgt、gte、lt、lte Existsフィルタのオートコンプリート Snapshot、Restore APIのリポジトリ設定の時オートコンプリートの失敗 いつものように、Elasticsearch Marvelを改善するために、フィードバックをお待ちしています。 ElasticsearchユーザMLやTwitterに質問や意見お送りください。\n","date":1418890008,"dir":"post/2014/","id":"7dea465ad52758b10cbceb08c81d1760","lang":"ja","lastmod":1418890008,"permalink":"https://blog.johtani.info/blog/2014/12/18/marvel-1-3-0-released-ja/","publishdate":"2014-12-18T17:06:48+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：marvel 1.3.0 released 12/17に、Elasticsearch Marvel 1.3.0をリリースしました","tags":["elasticsearch","marvel"],"title":"Marvel 1.3.0リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch 1.4.3 and 1.3.8 released\n本日、Lucene 4.10.3をベースにしたElasticsearch 1.4.3と、セキュリティフィックスとバグフィックスリリースである、Elasticsearch 1.3.8をリリースしました。 ダウンロードおよび変更リストはそれぞれ次のリンクからアクセスできます。\n最新ステーブルリリース：Elasticsearch 1.4.3 1.3.x系バグフィックス：Elasticsearch 1.3.8 過去のリリースに関するブログ（公式）はこちら。\n1.4:1.4.1, 1.4.0, 1.4.0.Beta1 1.3:1.3.6, 1.3.5, 1.3.4, 1.3.3, 1.3.2, 1.3.1, 1.3.0. すべての変更については1.4.2のリリースノートおよび1.3.7のリリースノートをごらんください。 以下では、重要な変更について紹介します。\nbug fixes Elasticsearchに対して広範囲にわたってランダムなテストを行っています。以下の問題を見つけ、修正するのに役立っています。\nプライマリシャードを持つnodeがレプリカシャードをプライマリから復旧している間に、リスタートした場合に、プライマリ上のトランザクションログが削除されデータをロスする(#8917) scriptインデックスが普及した場合に、ScriptService全体がデッドロック(#8901) Index Writerのロックを強制的に解放することによるシャードの破損(#8892) パフォーマンス改善 複雑な設定をもつ大きめのクラスタをもつユーザは、小さなスケールではわからない性能ボトルネックに直面します。 彼らの報告が次の改善をもたらす助けとなりました。\n使用可能なディスク空間に基づいてシャードの配置を決定する、disk allocation deciderの速度改善とクラスタリスタート後のリカバリ速度の改善(#8803) 以前よりも高速な共有ファイルシステムでのSnapshot生成(#8749) 不要なクラスタ状態変更の削減とそれによるネットワークトラフィックの削減およびリカバリの速度向上(#8933, #8413) index stats APIはシャードリカバリによるブロックしない(#8910) 試してみてください。 ぜひ、Elasticsearch 1.4.2をダウンロードして、試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1418880374,"dir":"post/2014/","id":"bce2fa6458f39a75e2713f3d687271a1","lang":"ja","lastmod":1418880374,"permalink":"https://blog.johtani.info/blog/2014/12/18/elasticsearch-1-4-2-released-ja/","publishdate":"2014-12-18T14:26:14+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElas","tags":["elasticsearch"],"title":"Elasticsearch 1.4.2および1.3.7リリース（日本語訳）"},{"contents":"「【東京】JJUG ナイト・セミナー「機械学習・自然言語処理特集！」12/17（水）開催」でLuceneの話をしてきました。 本当にごく簡単な入門です。 Luceneをさわるきっかけにしてもらえたら嬉しいです。\nそのほかにも面白い話が聞けましたので、簡単ですがメモを。\nJJUGの2014年振り返り だいたい、毎月ナイトセミナーかCCCを開催 イベント系に、のべ3100名が参加 Java でカジュアルにはじめる機械学習 小宮 篤史さん(スマートニュース株式会社) スライド：#JJUG - Java でカジュアルにはじめる機械学習\nブログ：#JJUG ナイトセミナー「機械学習・自然言語処理特集！」で Java でカジュアルに機械学習する話をしてきました\nガチの人は寝ててください。 機械学習でできること 分類・識別 予測・回帰 パターンマイニング・アソシエーションルール クラスタリング 上2つは教師あり学習/下2つは教師なし学習 データとしては、日構造では扱えないので、「特徴量」を抽出して「特徴ベクトル」を作って、処理をするのが機械学習 得られた結果の正しさの測定などなど\n機械学習の実装は辛いので、車輪の再発明をやめましょう！ \u0008Javaで使える機械学習\nWeka：とりあえず使ってみるならこれ？ MLlib：Sparkで使われてる Mahout：オワコン？ SAMOA：Stormの上で利用できる Jubatus：Javaクライアントあり。 h2o：Deep learningをJavaでやるなら、これ。 ほかにもあったけど、スライド見ていただければ。 機械学習をはじめるのに使えるデータセット\nUCI Machine learning repository\nIris（アヤメデータ）は機械学習界のHello world Wekaを使ったサンプルコード\nSpark/MLlibではじめるスケーラブルな機械学習 猿田 浩輔さん(株式会社エヌ・ティ・ティ・データ) スライド：（後日、リンクがあれば更新予定）\n\u0008* Spark+MLlibを語る上で外せない話題\nHadoopとの違い？\nまずはHadoopの話\nHadoopによるK-meansのデモ\nHadoopの問題点に対するSparkの解決策\nSpark 1.0系からJava8で書ける\nQA：\nQ： データをキャッシュできるという話でしたが、キャッシュするということは、ジョブが途中で失敗した場合は最初からやり直しになるのでしょうか？ A： キャッシュしたデータが残っている場合は、途中から再開出来ます。キャッシュしたデータを持ったマシンがこけたら、最初からやり直しです。\nLuceneと日本語の検索 自分 スライド：Luceneと日本語の検索 サンプルのリポジトリ：jjug-example\n自然言語処理にからめて何か話をしてくださいと話を受けていたのですが、自然言語処理については「形態素解析」くらいしか出てこなかったですけど。。。 Luceneがどんなものかを超概要で話をしてみました。少しでもLuceneがどんなものかをわかってもらえたら嬉しいです。\nもっと詳しく知りたい方は、スライドにある参考資料などを見ていただければと。\nJavaで書くのもいいんですが、もっと簡単に検索したい場合はElasticsearchを使うのが便利ですよ！で締めくくりたかったのですが、発表では失敗してしまいました。。。 Elasticsearchの起動からデータ登録、検索まではこちらのスライドを見ていただければ簡単さがわかると思います。\nまた、Kuromojiを利用した時に、Tokenizerなどが出力するTokenの品詞情報を見たい場合に便利なElasticsearch用プラグインも作っています。 こちらも、Elasticsearchと一緒に使ってみてください。\nまとめ 機械学習に関していろんなツールがあるのだなぁと。 懇親会でもちょっと話しましたが、アルゴリズムの選定とか、アルゴリズムに適したデータの作成など、前処理のノウハウとかが大変そうだなぁといつも思います。 機械学習はいつもぼやーっとしか理解してないので。。。\nJJUGさんはYouTubeの動画もあるようなので、過去の面白そうなセミナーも合わせてみてみると面白いと思います。\n毎度のことですが、なんでも良いので、発表した後のフィードバックをいただけるとうれしいです。 今後の励みや改善につながるので。\n","date":1418809314,"dir":"post/2014/","id":"e5390751969ab21df280b7591854b89f","lang":"ja","lastmod":1418809314,"permalink":"https://blog.johtani.info/blog/2014/12/17/jjug-night-seminar-dec-2014/","publishdate":"2014-12-17T18:41:54+09:00","summary":"「【東京】JJUG ナイト・セミナー「機械学習・自然言語処理特集！」12/17（水）開催」でLuceneの話をしてきました。 本当にごく簡単な入","tags":["elasticsearch","jjug"],"title":"JJUG ナイトセミナーでLuceneの簡単な紹介をしてきました。#JJUG"},{"contents":"たまには、他愛のないブログを。\n仕事しながら、コーヒーを飲んでます。\n最近は、サムライズムさんのオフィスに入り浸って仕事してます。 オフィスには、コーヒーミル付きのコーヒーメーカーがあるんです。\n↓こんな感じ（現物は違うけど）\nで、近所のコーヒー問屋で豆を買ってきてます。 そこのマスターに、いつもサジェストされるんです。\n「この豆は、日が経つにつれて、細かく挽いて飲んでください。」\n「この豆は、細かめに挽いて飲むのがオススメです。」\nなどなど。 オススメされるんですが、全自動のコーヒーメーカーは残念ながらここまでやってくれません。\nということで、手動のミルを買ってみました。家でも使えるし。\nちょっと考え事しながらとか、頭の切り替えに、ミルを回すのもいいかなと。 気持ち、美味しいコーヒーな気がします（気のせいかも）\n","date":1418698892,"dir":"post/2014/","id":"05330c3703d0e2c96cfe657ab33f130c","lang":"ja","lastmod":1418698892,"permalink":"https://blog.johtani.info/blog/2014/12/16/a-coffee-break/","publishdate":"2014-12-16T12:01:32+09:00","summary":"たまには、他愛のないブログを。 仕事しながら、コーヒーを飲んでます。 最近は、サムライズムさんのオフィスに入り浸って仕事してます。 オフィスには、","tags":["misc","coffee"],"title":"コーヒーブレイク"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：exciting logstash plugin ecosystem changes\nLogstash 1.5.0 Beta 1(お試しはこちら)のリリースで、 プラグインのインストール、管理、公開の方法を変更しています。 ユーザやコミュニティからフィードバックをもらいました。 その目的は、プラグインの利用や開発をより簡単にすることです。 このプロジェクトは始まったばかりです。プラグインのコミュニティを探し、 共有するためのワンストップソリューションを提供するこのアイデアを改善していく予定です。 このブログで、この決定を行った理由を説明し、新しいワークフローをと今後のロードマップを説明します。\nプラグインがあります！ Logstashは、プラグイン（input、filter、output、codec）が豊富にあります。 これらは、Elasticsearchにより開発されたものと、コミュニティからコントリビュートされたものです。 Logstashの主な特長の1つは、これらのプラグインの有効性と動作を拡張するプラグインを追加するのが簡単なことです。 現在、165以上のプラグインがエコシステムにあり、これらは、2つのプロジェクトに分かれています。\nlogstash-coreは最もよく使われるプラグインで、Logstashにデフォルトで含まれます logstash-contribはコミュニティにより開発されたプラグインを含み、別途ダウンロードできます 新プラグインエコシステムの変更 1.5.0では、全てのプラグインは、Logstashコアから分離され、rubygemsを使って個別にパッケージングされます。 rubygemsを選択したのは、依存関係のあるライブラリの配布とパッケージングがパワフルで一般的なものだからです。 さらに、rubygems.orgプラットフォームは配布や探索に影響があります。 また、Logstashにプラグインをインストール、アップデート、削除するのが簡単な基盤も追加しました。 contribプロジェクトは徐々に終了します。全てのプラグインは個別のプロジェクトになります。\nプラグインエコシステム変更の理由 多数のプラグインをもっていると、配布と公開に関して難題が出てきます。 私たちが変更するに至った理由は次のようなものです。\n現在は、プラグインの更新に伴い、Logstashの新バージョンのリリースが必要 開発者は、Logstashのリリース間隔とは別に、新バージョンをリリースをしたい プラグイン開発者は、外部依存を記述できるようにしたい Logstashコアの配布パッケージのダウンロードサイズを小さくし、ユーザは必要なプラグインのみインストール logstash-contribを1つのリポジトリとして管理するのは難しい 詳細： ソースコードの場所 Logstashのソースコードは、今後も現在のGitHubのリポジトリのままです。 しかし、プラグインに関するコードやテストコードは含まなくなります。 この分離により、個別のプラグインの改善と同様にコアの改善に集中できます。 これにより、Logstashプロジェクトの全体の品質も向上します。\n全プラグインのソースコードは、新しいGitHub organization、logstash-pluginsにて管理します。 各プラグインは個別のリポジトリとして、ここに配置されます。 一見すると、これはメンテナンスが難しくなるように思えます。しかし、テスト、Issue、依存関係を明確にすることができます。 私たちの目的は、テスト、ドキュメント、gemの公開の自動化であり、これを簡単にするためのツールを追加します。\nしかし、プラグインの開発者はプラグインのソースコードソースコードをlogstash-pluginsに置く必要はありません。 ー コミュニティで利用可能にするために、rubygems.orgでそれを公開するだけで良いです。\nワークフロー ここで、新プラグインエコシステムのやりとり/ワークフローについて、いくつかの観点から説明します。\nlogstashユーザ: ユーザは、これまでのリリース同様にLogstashのバイナリをダウンロードします。 Logstash 1.5.0は、1.4.2でパッケージされていたプラグインと同等のものが含まれています。 新しいシステムに簡単に移行できるようにです。 そして、ユーザは、最初のデプロイの後に、Logstashプラグインのをインストール、アップグレードできるようになります。\n$LS_HOME/bin/pluginスクリプトがプラグイン操作に関連するコマンドになります。\nプラグインのインストール プラグインのほとんどはgemとしてrubygems.orgにアップロードされます。 例えば、もしユーザがApache Kafka outputプラグインをインストールする場合、次のコマンドを実行します。\nbin/plugin install logstash-output-kafka または、ファイルをダウンロード済みの場合は次のコマンドとなります。\nbin/plugin install /path/to/logstash-output-kafka-1.0.0.gem プラグインの削除 bin/plugin uninstall logstash-output-kafka 1つまた全プラグインのアップデート bin/plugin update bin/plugin update logstash-output-kafka プラグインのリストアップ bin/plugin list bin/plugin list elasticsearch ( List all plugins containing a name ) bin/plugin list --group output ( list all outputs ) ドキュメント プラグインが個別に管理されても、全プラグインのドキュメントは1カ所です。\nlogstash plugin開発者: プラグイン開発者と作者は、Logstashエコシステムのためにプラグインを公開することができます。 プラグインは、gemやJavaライブラリの依存関係を宣言できます。 より重要なのは、Logstashのリリース間隔に関係なく、プラグインの改善版をリリースできます。\nRubygemsテクノロジはパッケージングシステム、依存関係管理、ホスティングのために選択されてきました。 Rubyのgemを公開することに慣れている開発者は、Logstashプラグインを簡単に公開することができます。 Elasticsearchはこれらの機能に関して開発者を支援するために、ツールを提供、メンテナンスします。\n開発およびローカルでのテスト JRuby 1.7.16がプラグインを開発するための唯一の前提条件です。 プラグインにパッチを提供するのは以前と同様です。 例えば、logstash-output-kafkaにパッチを送るのは次のようになります。\ngit clone https://github.com/logstash-plugins/logstash-output-kafka.git 変更 プラグインをローカルでテスト bundle install bundle exec rspec Logstashの他のバージョンもしくはローカルでテストする場合、Gemfileを編集し、 次のように別のロケーションを加えます。gem \u0026quot;logstash\u0026quot;, :github =\u0026gt; \u0026quot;elasticsearch/logstash\u0026quot;, :ref =\u0026gt; \u0026quot;master\u0026quot; 新しいPull Requestをlogstash-output-kafkaに対して作成 コミュニティでコードレビューを受け、Elasticsearchがパッチを受け入れ バージョン バージョン情報は、それぞれのプラグインの.gemspecで管理します。 例えば、Apache Kafka outputのgemspecはこちらです。 バージョニングはsemantic versioningのルールに従い、 Logstashのバージョニングとは別に、プラグインの開発者によって管理されます。 Logstash 1.5.0がリリースされると、マイルストーン1のプラグインはバージョン1.0.0となり、マイルストーン2のプラグインはバージョン2.0.0となるでしょう。\n公開 開発者が変更を加えプラグインを公開したいと思った時、.gemspecのバージョン番号を変更します。 全テストが成功した時、Elasticsearchはrubygems.orgにプラグインを手動で公開します。 もし、テストが失敗した場合、プラグインは公開されません。 長期的には、プラグインの公開の自動化を行いたいと思っています。 この変更は新しいため、公開の自動化を提供する前に、自動化についてより理解し、プラグインのテスト基盤を改良したいと思っています。\nIssue Issueは、各プラグインのGitHubリポジトリに対してオープンなければなりません。 Logstashコアのリポジトリは、コアのパイプラインや共通的な機能に関連するIssueについて扱います。\nドキュメント プラグインのドキュメントはソースコード自体から生成されます。 それぞれのプラグインのドキュメントは、そのプラグインのリポジトリに含まれます。 Elasticsearchは elasticsearch.org/guideに全てのプラグインのドキュメントを集め生成できる基盤を提供します。\n移行 全ての新しいpull requestとissueはlogstash-plugin organisation配下にある各プラグインのリポジトリに対してオープンする必要があります。\nすでにあるPRはどうすれば良いですか？ 気にしないでください。すでにあるpull requestは開発者によって移行する必要はありません。 LogstashチームがLogstashコアリポジトリに対してのPRを、個別の関連するプラグインのリポジトリに対してマージします。\ngit clone … # clone the specific plugin repo # now apply the patch curl -s https://github.com/elasticsearch/logstash/pull/XXXX | git am --3way git push Note:このプロセスはすでにあるPRに対してgit historyを管理します\nGitHub Issue 現在、LogstashリポジトリにオープンされているIssueは、それぞれのプラグインのリポジトリに移行します。 Logstashチームがgithub.com APIを利用してこの処理を自動的に行います。 安心してください。私たちが個別のプラグインに対する既存のIssueを移行します。\n今後のロードマップ これは、最初のステップであり、これらの変更は、ユーザや開発者に対してエコシステムをよりよくするために、 しっかりとした基盤を提供します。\n短期的には、開発者のためにpull requestのフィードバックでテスト自動化を提供する基盤を追加していきます。 プラグインリポジトリのブートストラップや管理のためのツールも提供していきます。\n長期的には、すべてのLogstashプラグインを探し、公開するためのコミュニティポータルを提供したいと思っています。 このアイデアは、Puppet ForgeやAWS marketplaceのようなものです。\nLogstash 1.5.0 Beta 1をリリースし、これは新しいエコシステムを提供します。 ぜひ、試していただき、これらの変更に関して感じたことを教えてください。 あなたのフィードバック(TwitterもしくはGitHub)はとても貴重です！\n","date":1418486440,"dir":"post/2014/","id":"4a3c42c9c5ac29db268010bbebf4f579","lang":"ja","lastmod":1418486440,"permalink":"https://blog.johtani.info/blog/2014/12/14/plugin-ecosystem-changes/","publishdate":"2014-12-14T01:00:40+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：exciting logstash plugin ecosystem changes Logstash 1.5.0 Beta 1(お試しはこちら)のリリースで、 プラグインのインストー","tags":["logstash"],"title":"Logstashプラグインのエコシステムの変更（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：logstash 1.5.0.beta1 released\nLogstash 1.5.0 Beta1をリリースしました。こちらのページからダウンロードできます。\nNote: ベータリリースです。本番環境では使用しないでください。\n1.5.0の主な変更点は？ 1.5.0の主なテーマはプラグイン管理、パフォーマンス改善、Apache Kafkaインテグレーションです。Logstashの主な特徴の1つは プラグインを利用できることであり、パイプラインの動作を拡張するためにプラグインを追加するのが簡単なことです。 このリリースで、プラグインの開発、管理、公開がより簡単になります。 また、Logstashの速度をより良くしたため、より多くのデータを短時間に処理することができます。 興味ありませんか？では、詳細を見ていきましょう。\nplugin ecosystemの変更 Logstashは165ものプラグイン(inputs、filters、outputs、codecs)を持っており、 これらはElasticsearchとコミュニティからのコントリビュートで開発されています。 多くのプラグインを管理することは、使いやすさと素早さの間のトレードオフがあります。 Logstashの全てのプラグインをまとめることは使いやすさがある一方、プラグインの更新を取り込むために Logstashの新しいリリースを待ってもらうことになります。 Logstashからプラグインを分離して個別に配布する場合、更新は簡単になりますが、使いやすさ（特に新しいユーザに）に影響が出ます。\n私たちは、プロジェクトを前進させるために、これらのバランスをとることを考えました。 これまで、全ての利用可能なプラグインは’core’と\u0026rsquo;contrib\u0026rsquo;の2つに分割していました。 \u0026lsquo;core\u0026rsquo;にあるよく使われるプラグインは、Logstashに含めていました。 コミュニティによりコントリビュートされたプラグインは\u0026rsquo;contrib\u0026rsquo;パッケージとして分離して配布していました。 1.5.0のリリースで、ユーザに対してより良いプラグイン管理をできるように変更しました。 全てのプラグインは、それ自身によるパッケージに移行しました。 パッケージングフレームワークとしてrubygemsを使い、rubygem.org経由でこれらのプラグインを配布、公開します。 また、Logstashにプラグインのインストール、更新、削除を簡単にするための構造も追加しました。\n例えば、S3 output pluginをインストールするには、以下のコマンドを実行します。\n$LS_HOME/bin/plugin install logstash-output-s3 それだけです！Logstashがgemと依存するgemをrubygems.orgからダウンロードし、インストールします。 あなたは、S3にデータを送ることができるようになります。\nダウンロード可能なLogstashリリースはプラグインをまだ多く含んでいますが、 いつでも、個別にプラグインをアップグレードし、インストールすることができます。 プラグインエコシステムの変更に関する詳細のブログ記事をお待ち下さい。\nパフォーマンス改善 Logstash 1.5.0はより高速になっています。パフォーマンスが改善された2カ所について説明します。\ngrok filter Grok filterはLogstashで、構造化データを抽出するためにパターンを記述するのに使われます。 本リリースで、人気のある幾つかのパターンのgrok filterのスループットを100%に改善しました。 言い換えると、grok filterを使うときに、Logstashを通してより多くのデータを処理することができます。\n私たちのベンチマークテストで、1.5.0と1.4.2のスループットの比較をしました。 利用したデータは690万件のApache Webアクセスlogで、COMBINEDAPACHELOGのgrok patternです。 1.5.0で、スループットは34,000 event per sec(eps)から50,000 epsに増加しました。 両方のテストを8コアのマシンでLogstashで8つのワーカーを実行しました。 これらのテストで、一つのgrok filterを実行し、 stdinとstdoutを使ったパイプラインでイベントのスループットを計測しました。 全体的なパフォーマンスは、様々なハードウェアやLogstashのコンフィグによって変化することに注意してください。\njson serialization / deserialization JSONのシリアライズ/でシリアライズをJrJacksonライブラリを利用して実装しました。 これにより、100%以上のスループットの改善がありました。 先ほど説明したパフォーマンステストにおいて、1.3KBのサイズの500,00 JSONイベントを送信し、 16,000 epsから30,000 epsにスループットが改善しました。 45,000サイズのイベントで、850 epsから3500 epsにスループットが増加しました。 すばらしいです。\napache kafka integration いまでは、Apache Kafkaが大規模スケールデータ処理システムでよく利用されます。 Logstashの配備のスケーリングにおいて、Kafkaもまた、shippingインスタンスとindexingインスタンス間の データを保存するための中間メッセージバッファとして使うことができます。\n1.5.0で、Logstash Kafkaのinputとoutputのプラグインのビルトインサポートを追加しました。 これは、Joseph Lawsonによって最初に開発されました。 私たちは、これらのプラグインにインテグレーションテストとドキュメントを追加することにより改良し、 新しいKafkaの機能を開発し続けます。 また、Apache Avro codecを追加することで、Kafkaに保存されたイベントを 簡単に取得でき、ELKスタックを使ってそれらを解析できるようにしました。\nKafka inputを追加するのは次のコマンドです。\n$LS_HOME/bin/plugin install logstash-input-kafka Kafka outputは次のコマンドです。\n$LS_HOME/bin/plugin install logstash-output-kafka セキュリティに関する改善 認証と経路暗号化のサポートを追加し、Elasticsearchのoutput、input、filterのセキュリティを改良しました。 例えば、HTTPプロトコルでSSL/TLSにより暗号化を有効にでき、 HTTPベーシック認証をユーザ名とパスワードをリクエストに与えることで設定できます。 これらの機能は、時期にリリースされるElasticsearch ShieldセキュリティプロダクトとLogstashを統合できます。\nドキュメント これまで、Logstashのドキュメントは[logstash.net])(http://logstash.net/)に置いてあり、 他のELKスタックと一緒に動かす時に、情報を探すのが厄介でした。 1.5.0および、今後のバージョンのドキュメントはelasticsearch.orgのLogstash Guideに移行します。 この移行でelasticsearch.org/guideにELKスタックを利用、 学習するためにドキュメントが1つになりました。 このベータリリースのイテレーションで、私たちはプレゼンテーションとドキュメントの品質を改善することに活発に取り組んでいきます。 (過去のLogstashのドキュメントの全てはいままでのlogstash.netで引き続き公開していく予定です。)\nバグフィックスと改善 ここまでの新しい機能に加えて、Logstash 1.5.0では、多くのバグフィックスと多くの機能改善があります。 ここで、これらのいくつかを紹介します。\n出力しない\u0026rsquo;metadata\u0026rsquo;をイベントに格納可能に。これは、例えば、date filterに使う中間フィールドのために必要。(#1834, #LOGSTASH-1798) HTTPを利用しているときのファイルデスクリプタリークの修正。Logstashがストールするのを防ぎ、OOMエラーからクラッシュするケースも防ぎます。(#1604) Twitter input:full_tweetオプションの追加、Twitter rate limitingエラーのハンドリング(#1471) イベントを生成するfilter(multiline、clone、split、metrics)により、 後続の条件文にこれらのイベントを正しく伝搬(#1431) Elasticsearch output:Logstashはデフォルトでmessage.rawフィールドを作成しない。messageフィールドはElasticsearch によりnot_analyzedでマルチフィールドとして追加される。マルチフィールドはディスクスペースが2倍必要だが、利点がない。 bin/logstashの複数のサブコマンドを除去(#1797) これらの機能、改善、バグフィックスについては、Logstash 1.5.0.Beta1 のchangelogをごらんください。\n試してみてください！ ぜひ、Logstash 1.5.0 Beta 1をダウンロードして試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1418372246,"dir":"post/2014/","id":"1bc36080b2493aab78c26e4f2152542c","lang":"ja","lastmod":1418372246,"permalink":"https://blog.johtani.info/blog/2014/12/12/logstash-1-5-0-beta1-released-ja/","publishdate":"2014-12-12T17:17:26+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：logstash 1.5.0.beta1 released Logstash 1.5.0 Beta1をリリースしました。こちらのページからダウンロードで","tags":["logstash"],"title":"Logstash 1.5.0 Beta1リリース(日本語訳)"},{"contents":"早いもので、師走です。今年もあと少しとなりました。ということで、Advent Calendarの季節が始まりました。\nこの記事はElasticsearch Advent Calndar 2014の1日目のエントリです。\n1日目ということで、簡単に今年の変遷を振り返りつつ、今年導入された新機能についてピックアップしてみようかと思います。\n1.0リリース(Lucene 4.6.0) 今年一番の目玉と思いますが、1月にRCが公開されて、1.0.0が2月にリリースされました。 （ElasticSearch Serverの翻訳が昨年末に終わってレビューをしていた段階での発表だったので個人的にはきついタイミングでした） 1.0の主な変更点はこちら。\nElasticsearch（Sが小文字に） 1.0からSが小文字になりました。(#4634) 0.90以前のバージョンについては、Sが大文字になっています。 ややこしいですが、今年の3月に出版された黒いElasticSearch Server日本語版は原著が0.20で日本語版にするタイミングで0.90に対応しました。 このため、こちらの書籍のタイトルはSが大文字となっています。 （なお、原著の2nd Editionは小文字になっています）\nSnapshot/Restoreの導入とGatewayの廃止 0.90以前のバージョンでは、gatewayというモジュールで、S3などにインデックスのメタデータなどを保存する機能がありました。 この機能は、0.20からlocal以外はdeprecatedとなりました。\nインデックスのバックアップ、リストアのために、1.0で実装されたのがSnapshot/Restoreです。 Snapshot/Restoreでは、インデックスごと、もしくはクラスタ全体をリモートにあるリポジトリにスナップショットを取ることが可能となりました。 初期リリースの段階では、共有ファイルシステムのみでしたが、現在は、S3やHDFSなどに保存が可能となっています。\nAggregation Facetをより強力にしたものです。Facetでは、指定したフィールドの集計のみでした。 データの解析などを行うには、独自で集計する必要がありました。 この機能をより柔軟に行えるように実装したのがAggregationです。\nたとえば、アクセスログを日毎に集計し、さらに日毎の集計に対して国別の集計やユーザエージェントごとの集計をさらに行うといった感じです。 Facetの場合は、日毎の検索結果に対して個別に集計するのみでしたが、Aggregationを使うことで、1週間の検索結果に対して、 日毎に国別の集計を行うといったことが可能になっっています。\ncat API \u0026ldquo;=^.^=\u0026ldquo;猫が出てくるAPIです。(違う)\nElasticsearchでは、クラスタの状態などが全てREST APIで取得でき、JSONで結果が帰ってきていました。 JSONはプログラムなどで処理を行う場合は便利ですが、コンソールで確認したり、管理系のツールでメールで通知する場合などは見にくいことがあります。 これを解消したのが_cat APIです。（公式の紹介ブログはこちら）\nCircuit Breaker OOMが発生しそうなfielddataの読み込みを検知して、事前に防ぐ機構になります。 初期段階ではFielddataに対してのものから実装されました。\n1.1リリース(Lucene 4.6.1) 3月にリリースされました。Elasticsearchはまだまだ発展しているため、リリースのサイクルが短いのが特徴です。\n1.x系では、Rolling Upgradeが導入されました。このため、クラスタ全体を停止することなく、クラスタのアップグレードが可能になりました。\nsearch templates 検索クエリをテンプレートとして登録することができるsearch templatesです。 JSONでクエリを記述できるのは便利ですが、毎回組み立てるのは大変かもしれません。 特に、固定のクエリをプログラムから利用するような場合などです。 テンプレートとして登録しておくことで、検索時に値を埋め込むだけで検索ができるようになりました。\nAggregationの強化 Aggregationの種類が増えました。\ncardinality：ユニークユーザ数の集計などが行えるaggregationです。HyperLogLog++アルゴリズムを利用した実装になっています。 significant_terms：単語の数による集計ではなく、コレクション全体に対する単語の頻度と、検索結果に対する単語の頻度を計算することで、重要度を計ることができます。 percentiles：パーセンタイル値を計算できます。 1.2リリース(Lucene 4.8系) Java 7必須 利用しているLuceneがJava 7必須となったためです。また、Java 6のEOLも切れてますし。\ndynamic scriptingがデフォルトオフ 採用していたMVELがサンドボックス化に対応していないため、危険を回避するためにオフとなりました。\nインデキシングとマージング インデキシングとマージ処理に関するさまざまな改善。\nflushのthreasholdを操作回数ではなく、サイズや時間によるものに変更 デフォルトをConcurrentMergeSchedulerに変更 1.3リリース(Lucene 4.9.0系) セキュリティ関連 JSONPのデフォルトオフ MVELの非推奨化（1.4で削除）＋script.disable_dynamicのデフォルト値がsandbox aggregationの強化 top hits：Field Collapsing/combiningと呼ばれる機能です。たとえば、いくつかのサイトのHTMLを収集して検索機能を提供する場合に、ドメインごとに1件ずつ検索結果に出したい場合などに利用できる機能です。 その他にも以下のaggregationが追加されています。\npercentile ranks geo bounds mappingのtransform Mappingにtransform機能が追加されました。 mappingにドキュメントの値を元に、インデキシング時に変換処理を記述できます。 たとえば、特定のフィールドにある値がある場合にだけ、あるフィールドに値を入れるなどといったことが可能になります。\nディスク関連 disk based shard allocation deciderが導入されました。ノードのディスクの使用率を元に、シャードを配置しても良いかといった決定を行う機構です。 チェックサムによるファイルのチェック（Lucene4.9で導入されたコードへの切り替え） 1.4リリース(Lucene 4.10系) ベータ版が出されるほど、多くの改善が入っています。\nresiliency メモリ使用量の低下によるノードの安定性向上 DocValues、リクエストごとのcircuit breakerなど discoveryアルゴリズムの改善によるクラスタの安定性向上 チェックサムの導入による破損したデータの検知 セキュリティ関連 CORSをデフォルト無効 Groovyがデフォルトのスクリプト言語に。 Aggregationの強化 以下のaggregationが追加されています。\nfilter、children、scripted_metric Upgrade API インデックスを最新のバージョンのものにアップグレードするためのAPIです。 Luceneは下位互換を保ってくれているため、古いバージョンのインデックスも読み込むことが可能です。 ただ、最新バージョンで使える機能が制限されていたりということもあります。 クラスタにあるインデックスをアップグレードするのにかかる時間や必要かどうかといったことを取得できる仕組みも提供します。\nまた、Lucene自体は、1つ前のメジャーバージョン（4.x系だと3.x系まで）までの互換性は提供していますが、 2つ前のメジャーバージョンの互換性がなくなります。 Luceneも5.x系のブランチが作成されており、5系のリリースにより、3系との互換性がなくなります。 5系のリリースに対応する場合にも、こちらのAPIが助けになるかと。\n1.4.1 11\u0008/27に1.4.1がリリースされました。 シャードの配置やparent/child、nestedドキュメントの改善などが行われています。\nまとめ ということで、駆け足で、1月から11月までのElasticsearchの流れを追ってみました。 1.0で大きな機能追加、改善が行われ、その後も活発に開発が行われています。 要望などがあれば、MLで聞いてみたりやGitHubに登録するなどを行っていただければと。\nあと、今年から来年にかけての大きなイベントとして、 Elasticsearch初のユーザカンファレンスのサイトがオープンしました。 Elasticsearchに関するいろいろな話が聞ける機会だと思うので、興味のある方は見ていただければと。\nでは、また次のAdvent Calendarで！（最終日の予定ですが、空きがあるのでなにか書くかも）\n","date":1417424748,"dir":"post/2014/","id":"2de582c67fca31500621ecd6d3917a07","lang":"ja","lastmod":1417424748,"permalink":"https://blog.johtani.info/blog/2014/12/01/about-elasticsearch-in-2014/","publishdate":"2014-12-01T18:05:48+09:00","summary":"早いもので、師走です。今年もあと少しとなりました。ということで、Advent Calendarの季節が始まりました。 この記事はElastics","tags":["elasticsearch"],"title":"2014年のElasticsearch"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch 1.4.1 and 1.3.6 released\n本日、Lucene 4.10.2をベースにしたElasticsearch 1.4.1と、バグフィックスリリースである、Elasticsearch 1.3.6をリリースしました。 ダウンロードおよび変更リストはそれぞれ次のリンクからアクセスできます。\n最新ステーブルリリース：Elasticsearch 1.4.1 1.3.x系バグフィックス：Elasticsearch 1.3.6 過去のリリースに関するブログ（公式）はこちら。\n1.4:1.4.0, 1.4.0.Beta1 1.3:1.3.5, 1.3.4, 1.3.3, 1.3.2, 1.3.1, 1.3.0. すべての変更については1.4.1のリリースノートおよび1.3.6のリリースノートをごらんください。 以下では、重要な変更について紹介します。\nshard allocation Elasticsearch 1.3.0で、disk based shard allocationが デフォルトで有効になっています。 もし、ノードのディスクの使用量がlawで指定された値（85%）を超えた場合、ノードにはシャードが配置されません。 また、highで指定された値（90%）を超えた場合、シャードを他のノードへ移動します。\nElasticsearch 1.4.1では、disk based shard allocationに3つの改良が追加されました。\nディスク使用量のチェックはシャードがクラスタに配置されるタイミングでのみ実施していた。現在は60秒ごとに使用量をチェック。(#8270) ディスクフルメッセージはDEBUGレベルでログに出力されていました。なぜ、新しいシャードが配置されないのかを説明するのが困難でした。現在はWARNレベルで30秒ごとにログに出力されます。(#8382) 以前は、シャードをもう一つのノードへ動かすべきかどうか決めるとき、allocation deciderはノードにあるシャードのサイズを考慮するだけでした。現在は、動かされるシャードのサイズも考慮します。これにより、必要最小限のシャードの移動量となります。(#8569) parent/child and nested documents Elasticsearch 1.4.0で、parent/childとnestedドキュメントに対して（新しいセグメントを開くときに）固定長ビットセットフィルタを構築しキャッシュしました。クエリ、フィルタおよびAggregationを常に速くするためにです。 多くのnestedフィールドを持つユーザにとっては、以前のバージョンよりもヒープの使用量が大きくなってしまいました。\nnested aggregationによって処理されるドキュメントの順序を変更すること(#8454)によって、固定長ビットセットフィルタが子のドキュメントに対して必要でなくなりました。 現在は、親のドキュメント（つまり、nestedではないドキュメント）を表すフィルタのみをキャッシュしています。これにより必要なキャッシュ空間のサイズを減少しました。(#8414、#8440)\ndate ranges 2つの日付範囲に関する問題がこのリリースで修正されました。 1つ目は、日付を丸めるかというものです。例えば、timestampフィールドに1秒の解像度の値があるとします。 {\u0026quot;lt\u0026quot;: \u0026quot;2014/11/26||/d\u0026quot;}というrangeフィルタは2014/11/26 00:00:00未満のタイムスタンプのデータを結果として返しました。 しかし、ltをlteに変更した場合、2014/11/27 00:00:00以外の値も含めたいです。\n以前は、lteは2014/11/27 00:00:00のタイムスタンプも含めてしまっていました。現在は、想定通りの動作をします。(#8556)\n2つ目のバグは日付の範囲条件にnow()を利用したaliasとpercolatorフィルタです。 now()の値を、フィルタが作成したタイミングで決定していました。フィルタが実行されるたびに更新せずにです。 #8534で、now()はaliasとpercolatorで想定通りの動作をします。\n試してみてください。 ぜひ、Elasticsearch 1.4.1をダウンロードして、試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1417056212,"dir":"post/2014/","id":"0a8183ced0e9e3e895b41286e54e8e4d","lang":"ja","lastmod":1417056212,"permalink":"https://blog.johtani.info/blog/2014/11/27/elasticsearch-1-4-1-released-ja/","publishdate":"2014-11-27T11:43:32+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.1 and 1.3.6 released 本日、Lucene 4.10.2をベースにしたElas","tags":["elasticsearch"],"title":"Elasticsearch 1.4.1および1.3.6リリース（日本語訳）"},{"contents":"前回の「Logstashを利用したApacheアクセスログのインポート」の続きです。 前回の記事では、Logstashの設定ファイルについて説明しました。 今回は「Elasticsearchに設定するインデックステンプレート」について説明します。\nテンプレートの設定 Elasticsearchでは、登録するデータの特性に合わせてMappingを定義する方がデータを効率良く扱うことができる場合があります。 この場合、通常ですと、インデックス作成時にMappingを指定します。\nただ、今回は、インデックス名に「年」を含める形で指定してあります。 「年」はLogstashで処理したデータによって決まります。このため、あらかじめMappingを指定してインデックスを作成するのは難しいです。\nこのような場合に便利な機能として、「インデックステンプレート」があります。\nインデックステンプレートとは 実際のテンプレートの説明に入る前に、少しだけ説明を。 インデックステンプレートとは、インデックスが作成されるタイミングで自動的に適用される設定をテンプレートとして登録できる機能のことです。 実際にテンプレートが適用されるかどうかは、インデックス名で判断されます。\n例えば、大して重要でもなく、データ量も少ないインデックス用のテンプレートとして、シャード数が1、レプリカ数が0、\u0026quot;_source\u0026quot;を保存しない設定のテンプレートを登録する場合、 次のようになります。\ncurl -XPUT localhost:9200/_template/template_1 -d \u0026#39; { \u0026#34;template\u0026#34; : \u0026#34;te*\u0026#34;, \u0026#34;settings\u0026#34; : { \u0026#34;number_of_shards\u0026#34; : 1, \u0026#34;number_of_replicas\u0026#34; : 0 }, \u0026#34;mappings\u0026#34; : { \u0026#34;type1\u0026#34; : { \u0026#34;_source\u0026#34; : { \u0026#34;enabled\u0026#34; : false } } } } \u0026#39; _templateがインデックステンプレートを登録するためのエンドポイントです。 template_1がこのテンプレートのIDです。削除などについては、このIDを利用します。\nそして、重要なのは、\u0026quot;template\u0026ldquo;の設定です。 \u0026ldquo;template\u0026ldquo;には、このテンプレートが適用されるべきインデックス名を記載します。 上記サンプルではte*となっているため、teで始まる名前のインデックスを作成した場合にテンプレートにある設定が適用されます。\n今回利用するテンプレート 私がJJUG CCCや第7回Elasticsearch勉強会のKibana4のデモで利用したインデックスのテンプレートは次のものになります。 \u0026ldquo;template\u0026ldquo;には、前回の記事で紹介したoutput/elasticsearchの設定 に合致するnew_demo_access_log-*を指定しています。\ncurl -XPUT localhost:9200/_template/new_access_log_for_demo -d \u0026#39; { \u0026#34;template\u0026#34;: \u0026#34;new_demo_access_log-*\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;number_of_shards\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;number_of_replicas\u0026#34;: \u0026#34;0\u0026#34; }, \u0026#34;mappings\u0026#34;: { \u0026#34;_default_\u0026#34;: { \u0026#34;dynamic_templates\u0026#34;: [ { \u0026#34;string_template\u0026#34;: { \u0026#34;mapping\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;match_mapping_type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;match\u0026#34;: \u0026#34;*\u0026#34; } } ], \u0026#34;properties\u0026#34;: { \u0026#34;path\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;multi_field\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;no_analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;referer\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;multi_field\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;no_analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;agent\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;multi_field\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;no_analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;geoip\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;object\u0026#34;, \u0026#34;properties\u0026#34;: { \u0026#34;location\u0026#34;: { \u0026#34;geohash\u0026#34;: true, \u0026#34;geohash_precision\u0026#34;: 10, \u0026#34;type\u0026#34;: \u0026#34;geo_point\u0026#34;, \u0026#34;lat_lon\u0026#34;: true, \u0026#34;geohash_prefix\u0026#34;: true } } }, \u0026#34;response\u0026#34;: { \u0026#34;copy_to\u0026#34;: \u0026#34;response_int\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;bytes\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;response_int\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;integer\u0026#34; } } } } } \u0026#39; settings設定 デモ用であり、手元で2台のノードを起動するということもあり、number_of_shardsに2を、number_of_replicasに0を指定してあります。\nmappings設定 インデックスのタイプ Mappingsの指定は通常、特定のタイプを指定します。 今回のデモでは、1種類しかないのですが、タイプ名を特に意識しないために、_default_を使用しました。 この場合、任意のタイプに適用されることとなります。 タイプを指定してMappingの設定を行う場合は_default_の部分に特定のタイプ名を記入します。\n\u0026#34;mappings\u0026#34;: { \u0026#34;_default_\u0026#34;: { ... ダイナミックテンプレート 次はダイナミックテンプレートです。 インデックステンプレートはインデックスの設定をテンプレート化しました。ダイナミックテンプレートはフィールドに対してテンプレートを設定できます。\n以下のダイナミックテンプレートでは、stringタイプのフィールドのデフォルト設定を変更しています。 通常、stringタイプのフィールドはanalyzedとなりますが、not_analyzedに変更してあります。 詳しく検索したいフィールドの方が少ないためです。\n... \u0026#34;dynamic_templates\u0026#34;: [ { \u0026#34;string_template\u0026#34;: { \u0026#34;mapping\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;match_mapping_type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;match\u0026#34;: \u0026#34;*\u0026#34; } } ], ... multi_field指定 検索もしたいし、Terms Aggregationでも利用したいフィールドについては、multi_fieldを利用して、 analyzedとnot_analyzedの2種類のフィールドを用意しています。 multi_field設定を用いることで、1つのJSONのデータから、異なる形のフィールドを用意することが可能です。\n今回のテンプレートでは、path、referer、agentにmulti_fieldを指定しました。\n... \u0026#34;path\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;multi_field\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;no_analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, ... 例えば、上記の設定の場合、入力のJSONはpathというデータのみですが、インデックス上にはpath.no_analyzedと path.analyzedというフィールドができあがります。 実際に検索する場合は、path.analyzed:検索したい文字列という形で検索をすることで、いわゆる部分一致のような検索が可能です。 また、完全一致をしたい場合はpath.no_analyzed:検索したい文字列という指定になります。 用途を考えると、requestも指定したほうが良いかもしれません。\ngeoip Logstashでgeoipデータを付与していました。 このgeoipのデータをKibana4で利用するために、geoデータとして登録する必要があります。\n\u0026#34;geoip\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;object\u0026#34;, \u0026#34;properties\u0026#34;: { \u0026#34;location\u0026#34;: { \u0026#34;geohash\u0026#34;: true, \u0026#34;geohash_precision\u0026#34;: 10, \u0026#34;type\u0026#34;: \u0026#34;geo_point\u0026#34;, \u0026#34;lat_lon\u0026#34;: true, \u0026#34;geohash_prefix\u0026#34;: true } } }, 上記の設定がgeoデータの指定です。 typeにobjectが指定してありますが、これは、geoipのデータがネストしているためです。 geoipオブジェクトのうち、緯度経度のデータはlocationに入っているため、こちらに緯度経度関係の設定を指定します。\n\u0026quot;type\u0026quot;: \u0026quot;geo_point\u0026quot;：geo_pointタイプであることを指定 \u0026quot;geohash\u0026quot;: true：緯度経度のデータをもとに、geohashの値もインデックス \u0026quot;geohash_precision\u0026quot;: 10：geohashの精度の指定 \u0026quot;lat_lon\u0026quot;: true：緯度経度を個別の.lat、.lonというフィールドにもインデックス \u0026quot;geohash_prefix\u0026quot;: true：該当するgeohashのみでなく、その親にあたるgeohashについてもインデックスする response、response_int、bytes 最後は、response、response_int、bytesです。\nresponseには、HTTPステータスコードが入ります。 文字列としても扱いたいですが、integerとして、Renge Aggregationなどを行いたいので、 response_intというフィールドにも値を入れています。 multi_fieldでも可能ですが、ここでは、copy_toを利用しました。 copy_toを用いることで、異なるフィールドに値をコピーすることができます。\nbytesについては、longで扱いたいとういう理由だけです。\n\u0026#34;response\u0026#34;: { \u0026#34;copy_to\u0026#34;: \u0026#34;response_int\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;bytes\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;response_int\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;integer\u0026#34; } まとめ 今回はデモに利用したインデックスてプレートについて説明しました。 前回の、Logstashの設定とこのインデックステンプレートを用いることで、Kibanaで解析するデータの準備ができます。 実際の操作などについては、また次回の記事で説明しようかと思います。\n不明な点、誤植などありましたら、コメント欄へお願いします。\n","date":1416900346,"dir":"post/2014/","id":"4d8f5e581eee602c7fd21da8eb68df9a","lang":"ja","lastmod":1416900346,"permalink":"https://blog.johtani.info/blog/2014/11/25/import-apache-accesslog-using-logstash-2/","publishdate":"2014-11-25T16:25:46+09:00","summary":"前回の「Logstashを利用したApacheアクセスログのインポート」の続きです。 前回の記事では、Logstashの設定ファイルについて説","tags":["logstash","kibana","elasticsearch"],"title":"インデックステンプレートとLogstash"},{"contents":"JJUG CCCや第7回Elasticsearch勉強会のKibana4のデモにアクセスログを利用しました。\nただ、セッションでは、どうやってElasticsearchに投入したのかという詳しい話をしていませんでした。 本記事では、データ取り込み時に利用したLogstashの設定ファイルについて説明します。\nLogstashの設定の説明に入る前に、全体の流れを。 「ApacheアクセスログをKibana4により可視化」です。\n材料の準備 「ApacheアクセスログをKibana4により可視化」に必要な材料は次の通りです。 （今回は起動するところまでいかないので、実際に必要なのは次回以降になります。）\nJava 7（u55以上を1つ） Logstash 1.4.2（1つ） Elasticsearch 1.4.0（1つ） Kibana4 Beta2（1つ） Apacheのアクセスログ（適量） Apacheのアクセスログ以外は、公式サイトからダウンロードできます。 それぞれをダウンロードして、起動できるようにしておきましょう。\n※1台のマシン上で行う場合は、アクセスログの量を少なめにするなどの対策をとりましょう。 ※今回は、1台のマシン（Mac）上で、VMなどを利用せず、それぞれ直接起動するものとします。\n可視化の手順と流れ 可視化の流れとしては、\nLogstashでファイルを読み込み、各種処理（パースしたり、情報を追加したり、切り出したり） Elasticsearchに保存 Kibanaでグラフを作ったり、検索してみたり です。\n今回は、1のLogstashでファイルを読み込んだりする設定ファイルの説明です。\nLogstashの設定 Logstashの基本 まずは、Logstashの設定ですが、簡単にLogstashの説明を。 Logstashは大きく3つのパーツに分かれています。\ninput：データの入力処理 filter：inputで読み込んだデータに対する操作など output：データの出力処理 inputでデータを読み込み（複数可）、filterでデータに対して各種処理を行い、outputでデータを指定されたところに出力（複数可）します。\nアクセスログの読み込み設定 アクセスログの読み込み処理は大まかに次のようなものとなります。\nアクセスログを読み込む（input/file） 読み取ったアクセスログを各フィールド（IPアドレス、ユーザエージェントなど）に分割（filter/grok） 日付のパース（filter/date） クライアントIPアドレスにgeoipの情報を付加（filter/geoip） リクエストのパスの第1階層の抽出（filter/grok） ユーザエージェントのパース（filter/useragent） Elasticsearchへの出力（output/elasticsearch） 設定ファイルは次のようなものになります。\ninput { file { path =\u0026gt; \u0026#34;/Users/johtani/demo_access_log/*/*.log\u0026#34; start_position =\u0026gt; \u0026#34;beginning\u0026#34; } } filter { grok { match =\u0026gt; { \u0026#34;message\u0026#34; =\u0026gt; \u0026#34;%{COMBINEDAPACHELOG}\u0026#34; } break_on_match =\u0026gt; false tag_on_failure =\u0026gt; [\u0026#34;_message_parse_failure\u0026#34;] } date { match =\u0026gt; [\u0026#34;timestamp\u0026#34;, \u0026#34;dd/MMM/YYYY:HH:mm:ss Z\u0026#34;] locale =\u0026gt; en } geoip { source =\u0026gt; [\u0026#34;clientip\u0026#34;] } grok { match =\u0026gt; { \u0026#34;request\u0026#34; =\u0026gt; \u0026#34;^/%{WORD:first_path}/%{GREEDYDATA}$\u0026#34; } tag_on_failure =\u0026gt; [\u0026#34;_request_parse_failure\u0026#34;] } useragent { source =\u0026gt; \u0026#34;agent\u0026#34; target =\u0026gt; \u0026#34;useragent\u0026#34; } } output { elasticsearch { host =\u0026gt; \u0026#34;localhost\u0026#34; index =\u0026gt; \u0026#34;new_demo_access_log-%{year}\u0026#34; cluster =\u0026gt; \u0026#34;demo_cluster\u0026#34; protocol =\u0026gt; \u0026#34;http\u0026#34; } } 1. アクセスログを読み込む（input/file） inputのfileモジュール(a)を使用してアクセスログのファイルを読み込みます。 pathでアクセスログのファイルのパスを指定します。 今回利用したアクセスログはdemo_access_log/2010/access20100201.logといった日毎のファイルに分割されていたため、 *を利用してファイルのパスを指定しました。 また、今回は既存のファイルの読み込みだけのため、start_positionにbeginningを指定してあります。 デフォルトではendが指定されるため、Logstashを起動後に追記されたログから対象になってしまうためです。 その他の設定については、公式ガイドをご覧ください。\ninput { file { # a path =\u0026gt; \u0026#34;/Users/johtani/demo_access_log/*/*.log\u0026#34; # b start_position =\u0026gt; \u0026#34;beginning\u0026#34; # c } } Logstashでは、ファイルをどこまで読み込んだかという情報を保持するために、sincedbを利用しています。 設定変更後に同じファイルを最初から読み込みたい場合などは、こちらのファイルを一旦削除するなどの対応が必要です。\nちなみに、読み込んだデータは次のようなJSONになっています。\n{ \u0026#34;message\u0026#34;: \u0026#34;読み込んだアクセスログ\u0026#34;, \u0026#34;@version\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;@timestamp\u0026#34;:\u0026#34;2014-11-21T06:16:21.644Z\u0026#34;, \u0026#34;host\u0026#34;:\u0026#34;jupiter.local\u0026#34;, \u0026#34;path\u0026#34;:\u0026#34;/Users/johtani/demo_access_log/2010/access20100201.log\u0026#34;} } 特に指定がない場合は、messageに読み込んだデータが入ってきます。 @timestampがLogstashが読み込んだ時刻、hostはLogstashが動作しているホスト名です。 pathはfileモジュールが読み込んだファイルのパスを設定しています。 この後の処理で、どこの項目に対して処理を行うかといったことが重要になるので、\n2. 読み取ったアクセスログを各フィールド（IPアドレス、ユーザエージェントなど）に分割（filter/grok） 2.〜6.の処理は、inputで読み込んだ1アクセスログに対する処理となります。\nここでは、grokフィルタを使用して Apacheのアクセスログを各フィールドに分割します。 Logastashでは、簡単に使えるようにいくつかのパターンが用意されています。 Apacheのログのために、COMBINEDAPACHELOGというのが用意されています。 今回はこちらを使用しています。その他にも日付などパターンが用意されているので、試してみてください。\nmessageにアクセスログが入っているので、こちらの項目に対してCOMBINEDAPACHELOGのパターンを matchで適用してフィールドに抜き出します。 tag_on_failureは、matchでパースに失敗した場合に、tagというフィールドに指定した文字列を出力する機能になります。 デフォルトだと_grokparsefailureが付与されますが、ここでは、どの処理で失敗したがを判別するために文字列を変更しています。\nfilter { grok { match =\u0026gt; { \u0026#34;message\u0026#34; =\u0026gt; \u0026#34;%{COMBINEDAPACHELOG}\u0026#34; } break_on_match =\u0026gt; false tag_on_failure =\u0026gt; [\u0026#34;_message_parse_failure\u0026#34;] } ... clientip、ident、auth、timestamp、verb、request、httpversion、response、bytes、referrer、agentがgrokフィルタにより抜き出された項目です。\n{ \u0026#34;message\u0026#34;:\u0026#34;アクセスログ\u0026#34;, \u0026#34;@version\u0026#34;:\u0026#34;1\u0026#34;, \u0026#34;@timestamp\u0026#34;:\u0026#34;2014-11-21T07:20:54.387Z\u0026#34;, \u0026#34;host\u0026#34;:\u0026#34;jupiter.local\u0026#34;, \u0026#34;path\u0026#34;:\u0026#34;/Users/johtani/demo_access_log/2010/access20100201.log\u0026#34;, \u0026#34;clientip\u0026#34;:\u0026#34;クライアントのIPアドレス\u0026#34;, \u0026#34;ident\u0026#34;:\u0026#34;-\u0026#34;, \u0026#34;auth\u0026#34;:\u0026#34;-\u0026#34;, \u0026#34;timestamp\u0026#34;:\u0026#34;01/Feb/2010:00:00:26 +0900\u0026#34;, \u0026#34;verb\u0026#34;:\u0026#34;GET\u0026#34;, \u0026#34;request\u0026#34;:\u0026#34;/images/favicon.ico\u0026#34;, \u0026#34;httpversion\u0026#34;:\u0026#34;1.1\u0026#34;, \u0026#34;response\u0026#34;:\u0026#34;200\u0026#34;, \u0026#34;bytes\u0026#34;:\u0026#34;318\u0026#34;, \u0026#34;referrer\u0026#34;:\u0026#34;\\\u0026#34;-\\\u0026#34;\u0026#34;, \u0026#34;agent\u0026#34;:\u0026#34;\\\u0026#34;Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)\\\u0026#34;\u0026#34; } 3. 日付のパース（filter/date） Logstashは特に指定がない場合、inputでデータを取り出した日付が@timestampとなります。 そして、このフィールドが特に指定がない場合は、Elasticsearchのデータの日付となり、Kibanaで利用する日付となります。\nリアルタイムにアクセスログを読み込む場合は、読み込んだ日時でもほぼ問題はありませんが、過去データの場合はそうもいきません。 そこで、dateフィルタを使用して、@timestampの値を書き換えます。\ndate { match =\u0026gt; [\u0026#34;timestamp\u0026#34;, \u0026#34;dd/MMM/YYYY:HH:mm:ss Z\u0026#34;] locale =\u0026gt; en } 上記では、timestampという項目に対してdd/MMM/YYYY:HH:mm:ss Zという日付パターンの場合に値を書き換える設定となります。 なお、日付の月の部分がFebとなっているため、localeにenを指定しています。Logstashが動作するマシンのlocaleがjaなどの場合にパースに失敗するためです。\n4. クライアントIPアドレスにgeoipの情報を付加（filter/geoip） どの国からのアクセスかなどを判別したいので、IPアドレスを元にgeoipを利用してより詳細な情報を付与します。 Logstashでもこの機能が用意されており、簡単に利用ができます。\ngeoip { source =\u0026gt; [\u0026#34;clientip\u0026#34;] } これだけです。対象とするIPアドレスのフィールドを指定しているだけです。 geoipというフィールドが追加され、次のような情報が付与されます。 国名、緯度経度、タイムゾーンなどです。\n{ ... \u0026#34;geoip\u0026#34;: { \u0026#34;ip\u0026#34;: \u0026#34;IPアドレス\u0026#34;, \u0026#34;country_code2\u0026#34;: \u0026#34;JP\u0026#34;, \u0026#34;country_code3\u0026#34;: \u0026#34;JPN\u0026#34;, \u0026#34;country_name\u0026#34;: \u0026#34;Japan\u0026#34;, \u0026#34;continent_code\u0026#34;: \u0026#34;AS\u0026#34;, \u0026#34;latitude\u0026#34;: 36, \u0026#34;longitude\u0026#34;: 138, \u0026#34;timezone\u0026#34;: \u0026#34;Asia/Tokyo\u0026#34;, \u0026#34;location\u0026#34;: [ 138, 36 ] } ... } 5. リクエストのパスの第1階層の抽出（filter/grok） リクエストされたURLはrequestフィールドにありますが、個別のURLだと、大まかな集計が大変です。 もちろん、クエリで処理することもできますが、Logstashで処理するついでに、第1階層のディレクトリ名を抽出しておくことで、 検索や集計を行いやすくしておきます。\ngrok { match =\u0026gt; { \u0026#34;request\u0026#34; =\u0026gt; \u0026#34;^/%{WORD:first_path}/%{GREEDYDATA}$\u0026#34; } tag_on_failure =\u0026gt; [\u0026#34;_request_parse_failure\u0026#34;] } また、grokフィルタの登場です。 今回は、WORD:first_pathという記述方法で、WORDパターンにマッチした文字列をfirst_pathというフィールドに展開する指定をしています。\n例えば、サイトのスクリプトなどがscriptsというディレクトリにある場合は、first_pathの値を利用して、 後続のフィルタでログデータを出力しないといった処理にも使えます。\n6. ユーザエージェントのパース（filter/useragent） Logstashではユーザエージェントの文字列から、いくつかの情報を付与するフィルタも用意されています。 useragentフィルタです。\nuseragent { source =\u0026gt; \u0026#34;agent\u0026#34; target =\u0026gt; \u0026#34;useragent\u0026#34; } agentというフィールドにユーザエージェントの文字列があるので、このフィールドに対してフィルタを適用します。 元の文字列も取っておきたいので、useragentという別のフィールドに出力するように指定してあります。\n\u0026#34;useragent\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;Firefox\u0026#34;, \u0026#34;os\u0026#34;: \u0026#34;Windows XP\u0026#34;, \u0026#34;os_name\u0026#34;: \u0026#34;Windows XP\u0026#34;, \u0026#34;device\u0026#34;: \u0026#34;Other\u0026#34;, \u0026#34;major\u0026#34;: \u0026#34;17\u0026#34;, \u0026#34;minor\u0026#34;: \u0026#34;0\u0026#34; }, このように、OS名やバージョン名などが抽出できます。\n7. Elasticsearchへの出力（output/elasticsearch） 最後は、Elasticsearchへのデータの出力設定です。\nindexにて、出力するindex名を指定してあります。 また、年毎のインデックス名にするために%{year}を利用しています。 sprintf formatです。\nelasticsearch { host =\u0026gt; \u0026#34;localhost\u0026#34; index =\u0026gt; \u0026#34;new_demo_access_log-%{year}\u0026#34; cluster =\u0026gt; \u0026#34;demo_cluster\u0026#34; protocol =\u0026gt; \u0026#34;http\u0026#34; } まとめ ということで、今回はアクセスログをLogstashにて読み込む時の設定について説明してきました。 次回は、実際にLogstashを起動してElasticsearchにデータを登録するところまでを説明します。\nJJUG CCCや勉強会のデモに用いたデータは、 Elasticsearchにデータを登録する前にテンプレートも設定してありました。こちらについても、次回説明しようと思います。\n不明な点、誤植などありましたら、コメント欄へお願いします。\n","date":1416558639,"dir":"post/2014/","id":"937a597a8b399fd32caba88a3c1c7bc4","lang":"ja","lastmod":1416558639,"permalink":"https://blog.johtani.info/blog/2014/11/21/import-apache-accesslog-using-logstash/","publishdate":"2014-11-21T17:30:39+09:00","summary":"JJUG CCCや第7回Elasticsearch勉強会のKibana4のデモにアクセスログを利用しました。 ただ、セッションでは、どうやってElas","tags":["logstash","kibana","elasticsearch"],"title":"Logstashを利用したApacheアクセスログのインポート"},{"contents":"第7回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n昨日も紹介しましたが、Elasticsearch Advent Calendar 2014を用意してみました。まだ、空きがありますので、登録お待ちしております！\n今回は出足が好調で、早々に180人の枠を超えるという嬉しい事態でした。 最終的な参加人数は130名程度で、懇親会参加者が50名弱といったところです。\n「Kibana4」 Elasticsearch Inc. Jun Ohtani @johtani スライド：Kibana4\nということで、Kibana4の紹介と、Kibana4のBeta2を利用したデモを行いました。 デモの開始のところで少し環境がうまく動いてなくて手間取ってしまいましたが。。。\n発表で1点だけ修正があります。JRubyを選択しているのがElasticsearchのライブラリを使用するためという説明をしましたが、 こちらは、Logstashに関する話でした。Kibana4は現時点では、ElasticsearchへのProxyとしての動作が主なものとなります。Rubyでも動作可能です。 bin/kibanaについてはJavaを使った起動になります。 参考：https://github.com/elasticsearch/kibana/tree/master/src/server\n発表でも主張しましたが、ダウンロードして、Elasticsearchを用意すれば簡単に動作させることが可能です。 ぜひ、ローカルで試して見てもらえればと思います。 今回のデモのデータを入れるのに利用したLogstashの設定などについては、ブログで記事を書こうと思います。\nniconicoの検索を支えるElasticsearch 株式会社ドワンゴ 伊藤 祥 さん スライド：niconicoの検索を支えるElasticsearch\nリアルタイム検索の実現、新しい検索への対応 検索のアーキテクチャとか。 Capistranoでデプロイとかを管理 1.4.1が出たら、クラスタを更新予定 ということで、実際に導入した話から、現在の運用の仕方、クラスタのアップグレードなど多岐にわたる内容でおもしろかったです。 遭遇した問題点とかもあったので。 Marvel便利なのでぜひ導入を検討してもらえればw\nElasticsearch at CrowdWorks\u2028株式会社クラウドワークス 九岡 佑介 さん @mumoshu スライド：Elasticsearch at CrowdWorks\n会社の紹介 仕事が検索対象 検索時間が1桁減少！ Graceful Degradationで失敗したら、InnoDB FTSで代替：Gracefully found.noのサービスを利用 elasticsearch-modelの拡張を作成してOSSとして公開：elasticsearch-model-extensions Gracefullyで切り替えとかは面白いなと思いました。 検索での利用の話でしたが、他のシーンでも使えそうですよね。 日本にFoundユーザがいるのも初めて知りました。 彼らの開発者ブログも質の良い情報が載っているので、参考になりますよね。\n次は、どんなMappingで運用しているのかとか、どういった工夫をしているかといった点を詳しく聞きたいなと思いました。 またお待ちしております。\n1分で作るElasticsearchプラグイン 株式会社エヌツーエスエム 菅谷 信介 さん スライド：Elasticsearchプラグインの作り方\n\u0008\u0008* プラグインの作り方とか。\n十数個のプラグインの紹介。プラグインはこちらで公開中。https://github.com/codelibs/ 実際に、業務で必要なものから作成 まだまだ作りたいものがある コミュニティ還元できるものはPR送ってもらえるとうれしいです。 前よりは体制も増えてるので、PRも目にとまるようになってるはずです。\nあとは、使ってみたいと思う方も多数いると思うので、ぜひ、OSSなので、貢献しましょう！ フィードバックがあるだけで、OSS活動やってるものにとってはやる気につながると思いますし。\nLT：GISとして活用するElasticsearch\u2028船戸 隆さん スライド：GISとして活用するElasticsearch\u2028java-jaからIngressの青（Registance）の勧誘に来られた方w APIをハックして、情報を取得し、Kibanaで可視化 残念ながら、APIが変更されて見れなくなったらしい。 Ingress実際にやったことはないのですが、おもしろそうでした。 発表される方の会社の採用紹介ではなく、Ingressの勧誘をされるとは想定外でしたw\n興味のあるデータをKibanaで可視化するのも面白い例だと思うので、活用してもらえればと思います。\nその他、感想などのブログ 適当に見つけたブログを列挙してあります。これもあるよ！などあれば、教えてください。\n勉強会メモ - 第7回elasticsearch勉強会 第7回elasticsearch勉強会 #elasticsearch #elasticsearchjp まとめ JJUGの時とは違い、Elasticsearch勉強会ではさすがに、企業としてのElasticsearchの知名度が高かったのはありがたいことでした。 自分の発表のために始めた勉強会でもありますが、まだまだ、発表するときは緊張しますし、分かりにくいんじゃないかなぁと思うことも多々あります。 この辺がわかりにくかった、この辺をもっと知りたいなど、フィードバックをお待ちしております。\n冒頭にも書きましたが、Elasticsearch Advent Calendar 2014の登録をお待ちしております。どんなことでも歓迎なので、Elasticsearch、Kibana、Logstashなどについて書いてもらえるとうれしいです。\n次回ももちろん2ヶ月後くらいに行います。 スピーカー募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1416363547,"dir":"post/2014/","id":"2a8412aa50d07330f1298f0243fa79d3","lang":"ja","lastmod":1416363547,"permalink":"https://blog.johtani.info/blog/2014/11/19/hold-on-7th-elasticsearch-jp/","publishdate":"2014-11-19T11:19:07+09:00","summary":"第7回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第7回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch-1.4.0 and 1.3.5 released\n本日、Lucene 4.10.2をベースにしたElasticsearch 1.4.0と、バグフィックスリリースである、Elasticsearch 1.3.5をリリースしました。 ダウンロードおよび変更リストはそれぞれ次のリンクからアクセスできます。\n最新ステーブルリリース：Elasticsearch 1.4.0 1.3.x系バグフィックス：Elasticsearch 1.3.5 1.3ブランチに関する過去のリリースについてのブログは次のとおりです：1.3.4, 1.3.3, 1.3.2, 1.3.1, 1.3.0.\nBeta1リリースでも言及しましたが、1.4.0の主なテーマは*resiliency(復元性、弾力性)*です。 Elasticsearchをより安定し信頼性のあるものにし、メモリ管理を改善し、ディスカバリアルゴリズムを改善し、破損したデータの検知を改善しました。 Beta1リリースからのハイライトも含んでいます。\nDoc values (インデックス時にディスクに保存されるfielddata)がヒープ利用率を激減 Request circuit breaker: メモリを消費しすぎる検索リクエストの中断 Bloom filterのデフォルト無効、高速なインデキシングのためにもはや必要とされないため。 ノードディスカバリ、シャードリカバリの数多くのバグフィックス及び改善 データ破損の早期検知のためのチェックサムのさらなる利用 GroovyをMVELの代わりにデフォルトスクリプト言語に CORSをデフォルト無効に。XSS攻撃防止の為。 クエリキャッシュ、変更されていないシャードからすぐにaggregation結果を返す 新しいAggregation：filter(ドキュメント)、children(ドキュメント)、scripted_metric(ドキュメント) 新しいGET /indexAPI。インデックスのsettings、mappings、warmers、aliasesを1回のリクエストで返却(ドキュメント) 自動付与ドキュメントIDのためのFlake ID。プライマリキーの探索パフォーマンスの改善。 ドキュメントに変更のない更新によるドキュメントの再インデックスの防止 function_scoreクエリの関数でweightパラメータによる個別の改善を可能に。(ドキュメント) 詳細については1.4.0.Beta1のブログ(英語)(日本語訳)をご覧ください。\nBeta1以降の1.4.0の変更の全てについては、1.4.0 release notesでご覧いただけます。 以下では、2つの主な変更について紹介します。\nHTTP Pipelining HTTP pipeliningは複数のリクエストを1回のコネクションで、関連するレスポンスを待つことなく送信することができます。 そして、レスポンスは、受け取ったリクエストと同じ順序で返却されます。 HTTP/1.1の仕様で、pipeliningのサポートが必要です。ElasticsearchはHTTP/1.1であるとしてきましたが、pipeliningはサポートしていませんでした。この問題は.NETユーザで問題を引き起こしました。\n現在、HTTP pipeliningは公式にサポート済みで、デフォルトで利用できます。#8299をご覧ください。\nUpgrade API Luceneのすべてのリリースではバグフィックスや最適化が提供されます。しかし、多くのユーザは古いバージョンのLuceneで作成されたインデックスを持っており、より最新の改善による利点を利用できないことがあります。 新しいupgradeAPIは、あなたのインデックスすべてもしくは一部を最新のLuceneフォーマットに透過的にアップグレードできます。\nGET _upgradeリクエストは、インデックスのアップグレードが必要かどうかを提示し、アップグレードに必要なセグメントのサイズをリポートすることによって、どのくらいの時間が必要かの目安を提供します。 POST _upgradeコマンドはバックグラウンドでインデックスを最新のLuceneフォーマットに書き換えます。\nより詳しい情報はupgradeAPIドキュメントをご覧ください。\n試してみてください。 Beta1リリースを利用し、経験・体験を報告していただいたベータテスターの方々に感謝します。 1.4.0がこれまでの最高のリリースになると確信しています。 ぜひ、Elasticsearch 1.4.0をダウンロードして、試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1415205033,"dir":"post/2014/","id":"d266a2023c67b7a20c3bd01055b223bc","lang":"ja","lastmod":1415205033,"permalink":"https://blog.johtani.info/blog/2014/11/06/elasticsearch-1-4-0-ja/","publishdate":"2014-11-06T01:30:33+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch-1.4.0 and 1.3.5 released 本日、Lucene 4.10.2をベースにし","tags":["elasticsearch"],"title":"Elasticsearch 1.4.0および1.3.5リリース（日本語訳）"},{"contents":"久しぶりに翻訳ではないブログを。書こうと思いながらかけてなかったので。。。\n今回はvalidate APIの紹介です。\n背景 ElasticsearchのクエリはQuery DSLというJSONで クエリを定義できるものを提供しています。 これは、様々なクエリ、フィルタを定義するために必要です。\n自分の望んでいる条件を記述するために、JSONのネストと格闘することも必要となります。。。 また、クエリ、フィルタには様々なパラメータが用意されています。 これらのパラメータをすべて覚えるのは無理でしょうし、タイプミスなどもありますよね。 タイプミスやカッコのミスマッチなどで格闘して1時間が経過してしまったなどもあると思います。\nそんな時に便利なAPIとして用意されているのがvalidate APIです。\n利用方法 APIが用意されています。\nhttp://ホスト名:ポート番号/インデックス名/タイプ名/_validate/query インデックス名やタイプ名は省略可能ですが、マッピングが異なると思うので、タイプ名まで指定するほうが良いと思います。 上記のAPIに対してクエリを送信するだけです。\nクエリの確認 たとえば、こちらのGistにあるようなマッピングのインデックスに対して 検索クエリを組み立てていて、エラーが出るとします。 ※このクエリはmatch_allのところをmatch_alと、lが1文字足りないクエリになっています。\n検索クエリのリクエスト（エラーあり）\nGET pref_aggs/_search { \u0026#34;query\u0026#34;: { \u0026#34;match_al\u0026#34;: {} } } 実行結果のレスポンス\n{ \u0026#34;error\u0026#34;: \u0026#34;SearchPhaseExecutionException[Failed to execute phase [query], all shards failed; shardFailures {[rwkb01chTZq2V7FD0Tlwrw][pref_aggs][0]: SearchParseException[[pref_aggs][0]: from[-1],size[-1]: Parse Failure [Failed to parse source [{\\n \\\u0026#34;query\\\u0026#34;: {\\n \\\u0026#34;match_al\\\u0026#34;: { }\\n }\\n}\\n]]]; nested: QueryParsingException[[pref_aggs] No query registered for [match_al]]; }{[rwkb01chTZq2V7FD0Tlwrw][pref_aggs][1]: SearchParseException[[pref_aggs][1]: from[-1],size[-1]: Parse Failure [Failed to parse source [{\\n \\\u0026#34;query\\\u0026#34;: {\\n \\\u0026#34;match_al\\\u0026#34;: { }\\n }\\n}\\n]]]; nested: QueryParsingException[[pref_aggs] No query registered for [match_al]]; }]\u0026#34;, \u0026#34;status\u0026#34;: 400 } とこんなかんじで、エラーが帰っては来るのですが、非常に読みづらいです。\nそこで、validate APIを利用します。 リクエスト先を/_searchから/_validate/queryに変更します。\nvalidate API\nGET pref_aggs/_validate/query { \u0026#34;query\u0026#34;: { \u0026#34;match_al\u0026#34;: {} } } validate APIのレスポンス\n{ \u0026#34;valid\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 } } すると、非常にシンプルな結果が返ってきます。 \u0026quot;valid\u0026quot;: falseとなっているため、クエリに問題があることがわかります。\nエラーの詳細 問題がある事自体はわかりましたが、エラーの内容も知りたいですよね？ その場合は、explainというパラメータを追加します。 （正しくはexplain=trueを追加しますが、=trueを省略可能です。）\nvalidate API(explainあり、クエリ自体は省略)\nGET pref_aggs/_validate/query?explain {...} validate APIのレスポンス\n{ \u0026#34;valid\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;explanations\u0026#34;: [ { \u0026#34;index\u0026#34;: \u0026#34;pref_aggs\u0026#34;, \u0026#34;valid\u0026#34;: false, \u0026#34;error\u0026#34;: \u0026#34;org.elasticsearch.index.query.QueryParsingException: [pref_aggs] No query registered for [match_al]\u0026#34; } ] } explanationsという項目が追加されました。 ここにerrorという項目として、エラーの詳細が返ってきます。_searchの時よりも見やすいですね。 今回のエラーは、match_allが正しいクエリですの、match_alというクエリは登録されていないというエラーでした。 では、クエリを修正して実行しましょう。\nvalidate API(エラー無し)\nGET pref_aggs/_validate/query?explain { \u0026#34;query\u0026#34;: { \u0026#34;match_all\u0026#34;: {} } } validate APIのレスポンス\n{ \u0026#34;valid\u0026#34;: true, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;explanations\u0026#34;: [ { \u0026#34;index\u0026#34;: \u0026#34;pref_aggs\u0026#34;, \u0026#34;valid\u0026#34;: true, \u0026#34;explanation\u0026#34;: \u0026#34;ConstantScore(*:*)\u0026#34; } ] } 今度はクエリに問題はありません。\u0026quot;valid\u0026quot;: trueです。 そして、explanationsの項目には、errorの代わりにexplanationという項目が返ってきました。 これが、実際にElasticsearch内部で実行されるクエリになります。\n実際のクエリに利用される単語の確認 この機能はこの他に、クエリの解析にも利用できます。 思ったとおりに検索にヒットしない場合があって、困ったことはないですか？ フィールドに指定されたアナライザによっては、単語を変形したりするものが存在します。\nサンプルマッピング\nPUT /validate_sample { \u0026#34;mappings\u0026#34;: { \u0026#34;several_analyzer\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;title\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;}, \u0026#34;body_ja\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34;}, \u0026#34;body_en\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;english\u0026#34;} } } } } 例えば、このようにkuromoji、english、デフォルト(standard)アナライザを利用したマッピングがあるとします。 このフィールドに対してpowerfulという単語で検索したとします。\nvalidate API\nGET /validate_sample/_validate/query?explain { \u0026#34;query\u0026#34;: { \u0026#34;multi_match\u0026#34;: { \u0026#34;fields\u0026#34;: [\u0026#34;body_en\u0026#34;,\u0026#34;body_ja\u0026#34;,\u0026#34;title\u0026#34;], \u0026#34;query\u0026#34;: \u0026#34;powerful\u0026#34; } } } この場合、レスポンスは次のとおりです。\nvalidate APIのレスポンス\n{ \u0026#34;valid\u0026#34;: true, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;explanations\u0026#34;: [ { \u0026#34;index\u0026#34;: \u0026#34;validate_sample\u0026#34;, \u0026#34;valid\u0026#34;: true, \u0026#34;explanation\u0026#34;: \u0026#34;(title:powerful | body_en:power | body_ja:powerful)\u0026#34; } ] } title、body_jaについては入力された単語がそのままクエリとして利用されています。 body_enについては、powerという単語に変換されて実行されています。 これは、englishアナライザがステミングを行った結果がクエリとして利用されるという意味です。 また、powerfulを秋葉原といった日本語に変更して実行すると次のようになります。 日本語はstandardアナライザなどでは、1文字ずつ区切られてしまうことがわかります。\nvalidate APIのレスポンス\n{ \u0026#34;valid\u0026#34;: true, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;explanations\u0026#34;: [ { \u0026#34;index\u0026#34;: \u0026#34;validate_sample\u0026#34;, \u0026#34;valid\u0026#34;: true, \u0026#34;explanation\u0026#34;: \u0026#34;((title:秋 title:葉 title:原) | (body_en:秋 body_en:葉 body_en:原) | ((body_ja:秋葉 body_ja:秋葉原) body_ja:原))\u0026#34; } ] } このように、クエリの単語がどのような単語に変換されてクエリに利用されているかなども知ることが可能です。\nまた、クエリを組み立てて、ヒットするはずが、0件となってしまうという場合にも、どのようなクエリが組み立てられているかを確認するという点で、 validate APIが役立ちます。 検索がヒットするが、望んだクエリになっていないのでは？という場合は_search APIのexplainパラメータを 利用すれば、クエリの構成がわかるのですが、検索結果が0件の場合はクエリの構成は表示されません。\n解決できない問題は？ 便利なvalidate APIですが、以下の問題に対しては残念ながら確認できません。\nquery以外の項目のvalidate不可 たとえば、_search APIのsizeなどの項目についてはチェックできないです。 存在しないフィールドの指定 上記validate_sampleのマッピングの例でクエリにbody_engという存在しないフィールドを指定してもエラーとはなりません。 まとめ 書いたクエリがうまく動かない、JSONのタグがおかしいといった場合は、 まずはこのvalidate APIで確認してみるのがオススメです。\n","date":1414402951,"dir":"post/2014/","id":"bc2709406a9bb19e8d83a78f81e36244","lang":"ja","lastmod":1414402951,"permalink":"https://blog.johtani.info/blog/2014/10/27/how-to-use-validate-api/","publishdate":"2014-10-27T18:42:31+09:00","summary":"久しぶりに翻訳ではないブログを。書こうと思いながらかけてなかったので。。。 今回はvalidate APIの紹介です。 背景 Elasticsear","tags":["elasticsearch"],"title":"validate APIの利用"},{"contents":"Elasticsearch 1.4.0.Beta1がリリースされました。\n個人でelasticsearch-extended-analyzeというプラグインを開発してます。 こちらも1.4.0.Beta1に対応するべく作業をしてて、少し戸惑ったことがあったので、メモをば。\nここ最近はプラグインのバージョン番号をElasticsearchのバージョン番号と同じものを利用していました。 （プラグインの機能追加をサボってる？？） その時に、1.4.0.Beta1という番号を指定したのですが、意味不明なエラーに悩まされてしまいまして。\nプラグインのリリースでは、以下のコマンドを実行します。\n$ mvn release:prepare $ mvn release:perform 最初のコマンド（prepare）で、パッケージングを実施し、Githubにリリースタグを打ったバージョンがpushされます。 次のコマンド（perform）で、パッケージングされたzipファイルがsonatypeのサイトに公開するためにアップロードされます。\n1.4.0.Beta1というバージョン文字列を利用した場合、prepareは問題なく実行できたのですが、 performで以下の様なエラーが返ってきました。\nReturn code is: 401, ReasonPhrase: Unauthorized. バージョン番号が1.3.0では特に問題はなかったのですが、、、 結局、バージョン番号を1.4.0-beta1に変更すると問題なくリリースが完了しました。\nmike_neckさんと話をしていて、Semantic Versioningに関係しているのかなぁという話にはなったのですが、 詳しく調べていません。。。\nそのうち調べようかなぁ。。。。\n","date":1413354368,"dir":"post/2014/","id":"998eda745d07fd8608f251138384a0b9","lang":"ja","lastmod":1413354368,"permalink":"https://blog.johtani.info/blog/2014/10/15/versioning-of-sonatype/","publishdate":"2014-10-15T15:26:08+09:00","summary":"Elasticsearch 1.4.0.Beta1がリリースされました。 個人でelasticsearch-extended-analyzeというプラグインを開発してま","tags":["Elasticsearch","plugin","sonatype"],"title":"Sonatypeのバージョン番号で困ったので"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch 1.4.0.beta1 released\n本日、Lucene 4.10.1をベースにした、Elasticsearch 1.4.0.Beta1をリリースしました。 Elasticsearch 1.4.0.Beta1からダウンロードできます。 また、すべての変更点に関してもこちらをご覧ください。\n1.4.0のテーマは*resiliency(復元性、弾力性)*です。 resiliencyとはElasticsearchをより安定し信頼性のあるものにすることを意味します。 すべての機能が正常に機能している場合は信頼することは簡単です。 予想外のことが発生した時に難しくなります：ノードでout of memoryの発生、スローGCや重いI/O、ネットワーク障害、不安定なデータの送信によるノードのパフォーマンス低下など。\n本ベータリリースは、resiliencyの主な3つの改善を含んでいます。\nメモリ使用量の低下によるノードの安定性向上 discoveryアルゴリズムの改善によるクラスタの安定性向上 チェックサムの導入による破損したデータの検知 分散システムは複雑です。 決して想像できないような状況をシミュレーションするために、ランダムなシナリオを作成する広範囲なテストスイートを持っています。 しかし、無数のエッジケース(特殊なケース)があることも認識しています。 1.4.0.Beta1はこれまで私たちが行ってきた改善のすべてを含んでいます。 これらの変更を実際にテストしていただき、何か問題があった場合は私たちに教えてください。\nメモリ管理 ヒープ空間は限られたリソースです。 上限を32GBとし、利用可能なRAMの50%をヒープの上限にすることを推奨します。 この上限を超えた場合、JVMは圧縮したポインタを使用することができず、GCが非常に遅くなります。 ノードの不安定性の主な原因は遅いGCです。それは、次のようなことから発生します。\nメモリプレッシャー スワップ(参照：memory settings) 非常に大きなヒープ 本リリースは、メモリ管理の改善し、（結果として）ノードの安定性を改善するいくつかの変更を含んでいます。\ndoc values メモリの利用の最も大きなものの1つはfielddataです aggregation、ソート、スクリプトがフィールドの値に素早くアクセスするために、フィールドの値をメモリにロードして保持します。 ヒープは貴重なため、1ビットも無駄にしないためにメモリ内のデータは高度な圧縮と最適化を行っています。 これは、ヒープスペース以上のデータをもつまでは、非常によく動作します。 これは、多くのノードを追加することによって常に解決できる問題です。 しかし、CPUやI/Oが限界に達してしまうずっと前に、ヒープ空間の容量に到達します。\n最近のリリースは、doc valuesによるサポートがあります。 基本的に、doc valuesはin-memory fielddataと同じ機能を提供します。 doc valuesの提供する利点は、それらが、非常に少量のヒープ空間しか使用しない点です。 doc valuesはメモリからではなく、ディスクから読み込まれます。 ディスクアクセスは遅いですが、doc valuesはカーネルのファイルシステムキャッシュの利点を得られます。 ファイルシステムキャッシュはJVMヒープとはことなり、32GBの制限による束縛がありません。 ヒープからファイルシステムキャッシュにfielddataを移行することによって、より小さなヒープを使うことができます。これは、GCがより早くなり、ノードが更に安定することを意味します。\n本リリースより前は、doc valuesはin-memory fielddataよりもかなり遅かったです。 本リリースに含まれる変更は、パフォーマンスをかなり向上させ、in-memory fielddataとほぼ同じくらいの速度になっています。\nin-memory fielddataの代わりにdoc valuesを利用するために必要なことは、次のように新しいフィールドをマッピングすることです。\nPUT /my_index { \u0026#34;mappings\u0026#34;: { \u0026#34;my_type\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;timestamp\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;date\u0026#34;, \u0026#34;doc_values\u0026#34;: true } } } } } このマッピングで、このフィールドに対するfielddataの利用は、メモリにフィールドをロードする代わりに、自動的にディスクからdoc valuesを利用します。 *注意：*現時点で、doc valuesはanalyzedなstringフィールドはサポートしていません。\nrequest circuit breaker fielddata circuit breakerはfielddataによって利用されるメモリの上限を制限するために追加され、OOMEの最も大きな原因の1つを防ぎました。 そして、リクエストレベルのcircuit-breakerを提供するために、コンセプトを拡張しました。 これは、単一のリクエストによって使用されるメモリの上限を制限します。\nbloom filters Bloom filters はインデキシング(前のバージョンのドキュメントが存在するかどうかのチェックのため)や、 IDによるドキュメントの検索(ドキュメントを含むセグメントがどれかを決定するため)に関する重要な性能最適化を提供しました。 しかし、もちろんそれらはコスト（メモリ）を必要とします。 現在の改善は、bloom filterの必要性を取り除きました。 現在では、Elasticsearchはまだ、インデックス時にそれらを構築します(実世界の経験がテストシナリオにそぐわない場合に備えて)。 しかし、デフォルトではメモリにはロードされません。 すべてが予定通りに運べば、将来のバージョンで完全にこれらは除去します。\nクラスタの安定性 クラスタの安定性向上のために私たちができる最も大きなことは、ノードの安定性の向上です。 もし、ノードが安定しておりタイミングよく反応すれば、クラスタが不安定になる可能性が大いに減少します。 私たちは不完全な世界に住んでいます。- 物事は予想外にうまく行きません。クラスタはデータを失うことなくこのような状況から回復できる必要があります。\n私たちは、improve_zenブランチ上で、Elasticsearchの障害からの復旧するための能力の向上に数ヶ月費やしてきました。 まず、複雑なネットワークレベルの障害を繰り返すためのテストを追加しました。 次に、各テストのための修正を追加しました。 そこには、より多くの行うことが存在します。しかし、私たちは、issue #2488(\u0026ldquo;分割が交差している場合、minimum_master_nodesはsplit-brainを防げない\u0026rdquo;)に含まれる、ユーザが経験してきた大部分の問題を私たちは解決しました。\n私たちはクラスタのresiliencyを非常に真剣に取り組んでいます。 私たちは、Elasticsearchが何ができるか、その上で何が弱点であるかを理解してほしいと思っています。 これを考慮して、私たちはResiliency Status Documentを作成しました。 このドキュメントは、私たち(または私たちユーザ)が遭遇したresiliencyの問題の、何が修正済みで、何が修正されないまま残っているかを記録します。 このドキュメントを慎重に読み、あなたのデータを保護するために適切な方法を選択してください。\nデータ破損の検知 ネットワークをまたいだシャードリカバリのチェックサムは、圧縮ライブラリのバグを発見する助けとなりました。 それは、バージョン1.3.2で修正済みです。 それ以来、私たちはElasticsearchのいたるところにチェックサムとチェックサムの確認を追加しました。\nマージ中に、あるセグメント内すべてのチェックサムの確認(#7360) インデックス再オープン時に、あるセグメント内の最も小さなファイルの完全な確認と、より大きなファイルの軽量な打ち切りチェック(LUCENE-5842) トランザクションログからイベントを再生するとき、各イベントはチェックサムを確認される(#6554) シャードのリカバリ中もしくは、スナップショットからのリストア中にElasticsearchはローカルファイルとリモートのコピーが同一であるか確認する必要がある。ファイルの長さとチェックサムのみを使うのは不十分であることが確認された。このため、現在はセグメントのすべてのファイルの同一性を確認(#7159) その他のハイライト Elasticsearch 1.4.0.Beta1のchangelogに本リリースの多くの機能、改善、バグフィックスについて読むことができます。 ここでは、特筆すべきいくつかの変更について述べます。\ngroovyによるmvelの置き換え Groovyは現在、デフォルトのscripting languageです。 以前のデフォルトはMVELで、古くなってきており、サンドボックス内で実行できないという事実は、セキュリティ問題でした。 Groovyはサンドボックスであり(それは、ボックスの外へは許可が必要)、メンテナンスされており、速いです！ 詳しくはscriptingについてのブログ記事をご覧ください。\nデフォルトでcorsはオフ Elasticsearchのデフォルト設定はクロスサイトスクリプティングに対して脆弱でした。 私たちはデフォルトでCORSをオフにすることで修正しました。 Elasticsearchにインストールされたサイトプラグインはこれまで同様に機能します。 しかし、CORSを再度オンにすることがない限り、外部のウェブサイトがリモートのクラスタにアクセスすることはできません。 ウェブサイトがあなたのクラスタにアクセス可能に制御できるように、さらにCORS settingsを追加しました。 詳しくはsecurity pageをご覧ください。\nクエリキャッシュ 新しい試験的なshardレベルのクエリキャッシュは、静的なインデックスのアグリゲーションをほとんど即座に反応できます。 ウエブサイトのアクセスの日毎のページビュー数を見るダッシュボードを持っていると想像してみてください。 これらの数値は古いインデックスでは変更がありません。しかし、アグリゲーションはダッシュボードのリフレッシュのたびに再計算されます。 新しいクエリキャッシュを利用すると、シャードのデータが変更されない限り、アグリゲーションの結果はキャッシュから直接返却されます。 キャッシュから古い結果を決して取得することはありません。それは、常に、キャッシュされていないリクエストと同じ結果を返します。\n新しいaggregations 3つの新しいaggregationsがあります。\nfilters\nこれはfilter aggregationの拡張です。複数のバケットを定義し、バケット毎に異なるフィルタを利用できます。 children\nnestedアグリゲーションの親子版。children aggは親のドキュメントに属する子のドキュメントを集計できる scripted_metric\nこのaggregationは、データによって計算されたメトリックを完全にコントロールできます。これは、初期化フェーズ、ドキュメント収集フェーズ、shardレベル結合フェーズ、global reduceフェーズを提供します。 get /index api 以前、ある1つのインデックスのaliases、mappings、settings、warmersを取得出来ました。しかし、それらを個別にです。 get-index API はこれらのすべてもしくは一部を、複数もしくはひとつのインデックスに対して一緒に取得できます。 これは、既存のインデックスと同一もしくはほぼ同一であるインデックスを作成したいときに非常に役に立ちます。\n登録と更新 ドキュメントの登録と更新にいくつかの改善があります。\n現在、ドキュメントIDの自動生成のためにFlake IDを使用しています。これは、プライマリキー探索時に素晴らしい性能向上を提供します。 detect_noopにtrueを設定すると、ドキュメントに変更を与えない更新が軽量になります。この設定を有効にすると、_sourceフィールドのコンテンツを変更する更新リクエストだけ、ドキュメントの新しいバージョンを書き込みます。 更新はスクリプトから完全に操作できます。以前は、スクリプトはドキュメントがすでに存在しているときだけ実行可能で、それ以外は、upsertドキュメントで登録しました。script_upsertパラメータでスクリプトから直接ドキュメントの作成が操作できます。 function score すでに非常に便利なfunction_scoreクエリが、新しくweightパラメータをサポートします。 これは、それぞれの指定された関数の影響をチューニングするのに使われます。 これは、人気度よりも更新日時により重みをかけたり、地理情報よりも価格により重みをかけるといったことを可能にします。 また、random_score機能はセグメントマージによる影響を受けません。これにより、より一貫した順序が提供されます。\n試してみてください。 ぜひ、Elasticsearch 1.4.0.Beta1をダウンロードして、試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1412244840,"dir":"post/2014/","id":"853cac0f2d1f90b7c986e7d1dcdbbfde","lang":"ja","lastmod":1412244840,"permalink":"https://blog.johtani.info/blog/2014/10/02/elasticsearch-1-4-0-beta-released-ja/","publishdate":"2014-10-02T19:14:00+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.0.beta1 released 本日、Lucene 4.10.1をベースにした、Elast","tags":["Elasticsearch"],"title":"elasticsearch 1.4.0.Beta1のリリース"},{"contents":"第6回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。 今回は、スタッフが私を含めて3，4名ということで、ドタバタしてしまってスミマセンでした。\n今回はキャンセルが多く、最終的には90人弱の参加となりましたが、今回も多数の方にお集まりいただきありがとうございました。 同じ日に他の勉強会もあった影響でしょうか？\n「Aggregationあれこれ」Elasticsearch Inc. Jun Ohtani @johtani スライド：Aggregationあれこれ\nちょっと長かったですかね。。。 Aggregationの概要、内部動作、種類などを簡単に紹介してみました。 個々のAggregationもいろいろなオプションなどがあるので、色々と試してみていただければと思います。 アニメーション入りのスライドになってましたが、UpしてあるスライドはPDF版になります。 「秒間3万の広告配信ログをElasticSearchでリアルタイム集計してきた戦いの記録」 株式会社サイバーエージェント　山田直行さん　@satully スライド：秒間3万の広告配信ログをElasticSearchでリアルタイム集計してきた戦いの記録\nディスプレイ広告配信DSPの話 システム: Fluentd、S3、Elasticsearch、Redis、MySQL 7月に秒間3万〜4万のリクエストをさばいている。 なぜElasticsearchを選んだのか、今の構成など 実際に苦労された点なども交えて話していただき面白かったです。 7月時点のお話ということで、現時点ではまた違う構成っぽかったので、また話を聞きたいなぁ。 「Elasticsearch 日本語スキーマレス環境構築と、ついでに多言語対応」ナレッジワークス株式会社　木戸国彦さん @9215 スライド：Elasticsearch 日本語スキーマレス環境構築と、ついでに多言語対応\nDynamic TemplateやIndex Templateの説明 日本語や多言語化するときのMappingのサンプルになりそうなものがゴロゴロ紹介されてました。 いくつかの例があって、後で見直したいなと。 途中で出てきた、fielddata（インデックスに入っている単語区切りのデータ）を見るのに使ってたクエリはfield data fieldsだったかな。 「elasticsearchソースコードを読みはじめてみた」@furandon_pig さん スライド：elasticsearchソースコードを読みはじめてみた\nリクエストを受けて検索してる部分から読むといいって言われたらしいが、起動スクリプトから読み始めてみた。 時間かかりそうｗ ただ、人がどんな感じでソースを読んだり理解してるかがわかりやすかったので面白かったです。 定期的に続きを聞いてみたいです。 LT 「reroute APIを使用してシャード配置を制御する」 株式会社富士通ソフトウェアテクノロジーズ 滝田聖己さん @pisatoshi スライド：reroute APIを使用してシャード配置を制御する\nシャードの再配置が自動で行われるので、それをオフにしないと、せっかく移動しても無駄になることがというあるあるネタ Bonsaiロゴを作成するLT 実際にいくら掛かったのかが知りたかった。 「検索のダウンタイム0でバックアップからIndexをリストアする方法」株式会社ドワンゴモバイル 西田和史さん スライド：検索のダウンタイム0でバックアップからIndexをリストアする方法\n擬似無停止のやりかた。 aliasを活用して、かつ、Restoreで再構築するという方法。 aliasまで一緒にリストアされるので注意が必要っていうのは、実際にやってみたからわかることという感じですね。 その他、感想などのブログ 適当に見つけたブログを列挙してあります。これもあるよ！などあれば、教えてください。\n第6回elasticsearch勉強会に行ってきましたのでそのメモ elasticsearch 勉強会 第6回 まとめ 今回も、ためになる話がいっぱい聞けたかなと。 個人的な印象としては、いつものメンバーよりも新しい方が多かった印象です。 また、ほとんどの方が、Elasticsearchをご存知でした。 そこそこ知名度は上がってきているようで嬉しい限りです。（東京以外での知名度なども知りたいかなと。）\nあと、懇親会の部屋の案内が遅くなってしまってスミマセンでした。 さすがにスタッフ3名はきつかったです。。。\n19時半開始にしてみましたが、懇親会の時間がやはり短めになってしまうなぁという印象でした。\n次回ももちろん2ヶ月後くらいに行います。 スピーカー募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1410927720,"dir":"post/2014/","id":"4616fbea6a6dbc1074bc3f1016bbc73b","lang":"ja","lastmod":1410927720,"permalink":"https://blog.johtani.info/blog/2014/09/17/hold-on-6th-elasticsearch-jp/","publishdate":"2014-09-17T13:22:00+09:00","summary":"第6回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第6回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"先日2014年9月9日(火)に『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』　出版記念！執筆者が語る大講演会！で、 「elasticsearch.もうちょっと入門」というタイトルで発表してきました。 会場のGMOのみなさま、Treasure Data、技術評論社のみなさま、どうもありがとうございました。\n書籍に興味のある方は、右のリンクから購入してもらえるとうれしいです。Kindle版も用意されています。\n提供のTDの方に目をつぶってもらいながらLogstashについての発表となってしまいましたが、楽しんでいただけたかなぁと。 書籍では主にKibana3をメインにしたElasticsearchの使い方だったので、それ以外の機能ということで、Aggregationについて説明してみました。\nそのあとは、おそらく初めてですが、パネルディスカッションにも参加しました。 @naoya_itoさんをモデレーターに、rebuild.fm風に進めていただき、話しやすかったかなと。 （少なくとも私は楽しめました！） ただ、私だけバックグラウンドが少し異なることもあり、話をうまく繋げられなかったかもと気にしていたりもしますが。。。\nパネルディスカッションでもありましたが、エンジニアが「趣味」で入れて試してみるのにはもってこいのツール群だと思います。 ちょっと入れてみて、可視化をしてみるといろいろと発見があると思います。 何かを発見するためにもまず試してみるのが何事も重要かなと最近思ってるのもあるので、気軽に試してみてもらえればと。\n不明点などあれば、著者陣に気軽に聞いていただけると良いかと思います（いいですよね、みなさんｗ）。 Fluentd（もちろん、Logstashも）、Elasticsearch、Kibanaを利用して、データについて試行錯誤してもらって、 システムやビジネスに必要なものを探索して見てください。\n参考 他の方々のブログをメモとして。\nサービス改善とログデータ解析について発表してきました Kibanaではじめるダッシュボードについて発表してきました #gihyo_efk Fluentdのお勧めシステム構成パターンについて発表しました ","date":1410841260,"dir":"post/2014/","id":"f15702ae9e55bad42182cf18724d1863","lang":"ja","lastmod":1410841260,"permalink":"https://blog.johtani.info/blog/2014/09/16/book-publication-event/","publishdate":"2014-09-16T13:21:00+09:00","summary":"先日2014年9月9日(火)に『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』 出版記念！執筆者が語る大講演会！で、 「elastics","tags":["勉強会","本"],"title":"elasticsearch.もうちょっと入門という話をしてきました #gihyo_efk"},{"contents":"Elasticsearchのインデキシングに関するパフォーマンス検討\n原文：performance considerations for elasticsearch indexing\nElasticsearchユーザは様々な楽しいユースケースを持っています。小さなログを追加することから、Webスケールの大きなドキュメントの集合をインデキシングするようなことまでです。また、インデキシングのスループットを最大化することが重要で一般的な目標となります。 「典型的な」アプリケーションに対して良いデフォルト値を設定するようにしていますが、次のちょっとした簡単なベストプラクティスによってインデキシングのパフォーマンスをすぐに改善することができます。それらについて記述します。\n第一に、制御できないならば、巨大なJavaヒープを使用しない：必要なサイズ（マシンの持つRAMの半分以下）のheapだけを設定しましょう。Elasticsearchの利用方法のために必要な全体量を設定します。これは、OSにIOキャッシュを制御するためのRAMを残すことを意味します。OSがjavaプロセスをスワップアウトしていないことも確認しましょう。\n最新バージョン（現時点では1.3.2）のElasticsearchにアップグレードしましょう：多数のインデキシングに関連する問題点が最新リリースで修正されています。\n詳細に入る前に警告：ここで述べるすべての情報は現時点での最新（1.3.2）の情報です。しかし、Elasticsearchの更新は日々行われています。この情報をあなたが見た時点では最新ではなく、正確ではなくなっているかもしれません。自信がない場合はユーザメーリングリストで質問してください。\nクラスタのインデキシングスループットをチューニングする場合、Marvelは非常に有用なツールです：ここで述べている各設定を継続的に試し、変更の影響がクラスタの挙動をどのように変更されたかを簡単に可視化することが可能です。\nクライアントサイド bulk APIを常に使いましょう。1リクエストで複数のドキュメントをインデキシングでき、各バルクリクエストで送るのに良いドキュメント数を試しましょう。最適なサイズは多くの要因に依存しますが、最適サイズからずれるならば多すぎるよりも少なすぎる方が良いでしょう。クライアントサイドのスレッドで並列にbulkリクエストを使うか、個別の非同期リクエストを使ってください。\nインデキシングが遅いと結論付ける前に、クラスタのハードウェアの性能を引き出せているかを確認して下さい：すべてのノードでCPUやIOが溢れていないかを確認するためにiostatやtop、psといったツールを使いましょう。もし、溢れていなければ、より多くの並列なリクエストが必要です。しかし、javaクライアントからのEsRejectedExecutionExceptionや、RESTリクエストのHTTPレスポンスとしてTOO_MANY_REQUESTS (429)が返ってきた場合は並列リクエストを多く送りすぎています。もしMarvelを利用しているなら、Node Statistics DashboardのTHREAD POOLS - BULKにリジェクトされた数が表示されます。bulkスレッドプールサイズ（デフォルト値はコア数）を増やすのは得策ではありません。インデキシングスループットを減少させるでしょう。クライアントサイドの並列度を下げるか、ノードを増やすのが良い選択です。\nここでは、1シャードに対してインデキシングスループットを最大化する設定に注目します。1つのLuceneインデックスのドキュメントの容量を測定するために、単一ノード（単一シャード、レプリカなし）で最初にテストをして最適化し、クラスタ全体にスケールする前にチューニングを繰り返します。これはまた、インデキシングスループットの要件を見つけるために、クラスタ全体にどのくらいのノードが必要かをラフに見積もるためのベースラインを与えてくれます。\n単一シャードが十分機能したら、Elasticsearchのスケーラビリティの最大の利点や、クラスタでの複数ノードによるレプリカ数やシャード数の増加の利点が得られます。\n結論を導き出す前に、ある程度の時間（60分）くらいクラスタ全体の性能を計測しましょう。このテストは、巨大なマージ、GCサイクル、シャードの移動、OSのIOキャッシュ、予期しないスワップの可能性などのイベントのライフサイクルをカバーできます。\nストレージデバイス 当然ながらインデックスを保存するストレージデバイスはインデキシングの性能に多大な影響を及ぼします：\nSSDを利用する：これらは最も速いHDDよりも速いです。ランダムアクセスのための消費電力が低いだけでなく、シーケンシャルIOアクセスも高いです。また、同時に発生するインデキシング、マージや検索のための並列的なIOも高速です。 インデックスをリモートマウントされたファイルシステム（例：NFSやSMB/CIFS）上に配置しない：代わりにローカルストレージを使う 仮想化されたストレージ（AmazonのElastic Block Storageなど）に注意：仮想化されたストレージはElasticsearchで十分に動作します。また、十分早く簡単に用意できることから魅力的です。しかし、残念なことに、ローカルストレージと比較すると本質的に遅いです。最近の非公式なテストでは、最高の性能を持つプロビジョニングされたIOPSのSSDオプションのEBSでさえ、ローカルインスタンスにあるSSDよりも遅いです。ローカルインスタンスにあるSSDは物理マシン上のすべての仮想マシンから共有されてアクセスされます。もし他の仮想マシンが急にIOが集中した場合に不可解なスローダウンとなることがあることを覚えておいてください。 複数のSSDを複数のpath.dataディレクトリにインデックスをストライピング（RAID0のように）：2つは同様で、ファイルブロックレベルでストライピングする代わりに、個別にインデックスファイルレベルでElasticsearchの\u0026quot;stripes\u0026quot;となります。これらのアプローチは、いづれかのSSDの故障によりインデックスが壊れるという、1シャードが故障する(IO性能を高速化することとトレードオフ)というリスクを増加させることに注意してください。これは、一般的に行うのに良いトレードオフです：単一シャードで最大のパフォーマンスを最適化し、異なるノード間でレプリカを追加すると、ノードの故障への冗長化ができます。また、snapshotやrestoreを使って保険のためにインデックスのバックアップを取ることもできます。 セグメントとマージ 新しくインデキシングされたドキュメントは最初にLuceneのIndexWriterによってRAMに保存されます。RAMバッファがいっぱいになった時もしくは、Elasticsearchがflushもしくはrefreshを実行した時など定期的にこれらのドキュメントはディスクに新しいセグメントとして書き込まれます。最後に、セグメントが多くなった時に、Merge PolicyとSuchedulerによってそれらがマージされます。このプロセスは連続的に生じます：マージされたセグメントはより大きなセグメントとなり、小さなマージが幾つか実行され、また、大きなセグメントにマージされます。これらがどのように動作するかをわかりやすく可視化したブログはこちらです。\nマージ、特に大きなマージは非常に時間がかかります。これは、通常は問題ありません。そのようなマージはレアで全体のインデックスのコストと比べればささいなものです。しかし、マージすることがインデキシングについていけない場合、インデックスに非常に多くのセグメントがあるような深刻な問題を防ぐために、Elasticsearchはやってくるインデキシングリクエストを単一スレッド(1.2以降)に制限します。\nもし、INFOレベルのログメッセージにnow throttling indexingと表示されていたり、Marvelでのセグメント数が増加しているを見た場合、マージが遅れているとわかります。MarvelはIndex Statistics dashboardのMANAGEMENT EXTENDEDの部分にセグメント数をプロットしており、それは、非常にゆっくりと指数対数的に増加しており、大きなマージが終了したところがのこぎりの歯のような形で見て取れます。\nセグメント数 なぜマージが遅れるのでしょう？デフォルトでElasticsearchはすべてのマージの書き込みのバイト数をわずか20MB/secに制限しています。スピニングディスク（HDD）に対して、これはマージによって典型的なドライブのIOキャパシティを飽和させず、並列に検索を十分に実行させることを保証します。しかし、もし、インデキシング中に検索をしない場合や、検索性能がインデキシングのスループットよりも重要でない場合、インデックスの保存にSSDを使用している場合などは、index.store.throttle.typeにnoneを設定して、マージの速度制限を無効化するべきです（詳細はこちらをご覧ください）。なおバージョン1.2以前には期待以上のマージIO制限の発生といったバグが存在します。アップグレードを！\nもし、不幸にもスピニングディスク（それはSSDと同等の並列なIOを扱えません）をまだ使っている場合、index.merge.scheduler.max_thread_countに1を設定しなければなりません。そうでない場合は、（SSDを支持する）デフォルト値が多くのマージを同時に実行させるでしょう。\n活発に更新が行われているインデックスでoptimizeを実行しないでください。それは、非常にコストの高い操作(すべてのセグメントをマージ)です。しかし、もし、インデックスにドキュメントを追加が終わった直後はオプティマイズのタイミングとしては良いタイミングです。それは、検索時のリソースを減らすからです。例えば、時間ベースのインデックスを持っており、新しいインデックスに日々のログを追加している場合、過去の日付のインデックスをオプティマイズするのは良い考えです。特に、ノードが多くの日付のインデックスを持っている場合です。\n更にチューニングするための設定：\n実際に必要のないフィールドをオフにする。例えば_allフィールドをオフ。また、保持したいフィールドでは、indexedかstoredかを検討する。 もし、_sourceフィールドをオフにしたくなるかもしれないが、インデキシングコストは小さい(保存するだけで、インデキシングしない)、また、それは、将来の更新や、前のインデックスを再インデキシングするために非常に価値があり、それはディスク使用率の懸念事項がない限り、オフにする価値はあまりない。それは、ディスクが比較的安価であるので価値がない。 もし、インデックスされたドキュメントの検索までの遅延を許容できるなら、index.refresh_intervalを30sに増やすか、-1を設定して、オフにする。これは、巨大なセグメントをフラッシュし、マージのプレッシャーを減らすことができる。 Elasticsearch 1.3.2(稀に、フラッシュ時に過度のRAMを使用するという問題を修正した)にアップグレードすることで、index.translog.flush_threshold_sizeをデフォルト(200mb)から1gbに増加し、インデックスファイルのfsyncの頻度を減らす。 MarvelにIndex Statistics dashboardのMANAGEMENTにフラッシュの頻度がプロットされている。 インデックスバッファサイズ 巨大なインデックスを構築中はレプリカ数を0にし、あとから、レプリカを有効にする。レプリカが0ということは、データを失った(ステータスがred)時に冗長性がないので、ノードの故障に注意すること。もし、optimize(ドキュメントの追加をすることがないので)を計画するなら、インデキシングが終わったあとで、レプリカを作成する前に実行するのが良いでしょう。レプリカはオプティマイズされたセグメントをコピーするだけになります。詳細はインデックス設定更新を参照。\nもし、ノードがヘビーなインデキシングを行っているだけなら、アクティブなシャードのインデキシングバッファに多くてい512MBをindices.memory.index_buffer_sizeに与えてください。(超えてもインデキシングのパフォーマンスは一般的には改善されません。)Elasticsearchはその設定(Javaヒープのパーセンテージもしくはバイト数)を受けて、min_index_buffer_sizeとmax_index_buffer_sizeの値を前提にノードのアクティブシャードに均等に割り当てます；大きな値はLuceneが最初のセグメントをより大きくし、将来的なマージのプレッシャーを減らすことを意味します。\nデフォルトは10%で、それで十分です；例えば、もし、5つのアクティブなシャードがノードにあり、ヒープが25GBの場合、各シャードは25GBの10%の1/5=512MB（すでに最大値）を持っています。ヘビーなインデキシングのあと、この設定をデフォルトに下げましょう。検索時のデータ構造のために十分なRAMを確保するために。この設定はまだ動的な設定変更はできません。Issueがここにあります。\nインデックスバッファによって現在利用されているバイト数は1.3.0のindices stats APIに追加されています。indices.segments.index_writer_memoryの値を見ることができます。これはMarvelではまだプロットされていませんが、将来のバージョンで追加される予定です。しかし、自分でグラフに追加することもできます。(Marvelはデータは収集しています)\n1.4.0では、indices.segments.index_writer_max_memoryとして、indices stats APIにアクティブシャードにどのくらいのRAMバッファが割り当てられているかも表示されます。これらの値はインデックスのシャード事の値として見ることができ、http://host:9200/\u0026lt;indexName\u0026gt;/_stats?level=shardsを使ってみることができます；これは、全シャードに対する合計と、各シャードごとのstatsを返すでしょう。\nオートIDの利用もしくは良いIDの利用 もし、ドキュメントのIDがなんでも良い場合、Elasticsearchで採番することができます：これは、(1.2以降)ドキュメントIDをバージョンを探さずに保存できるように最適化され、Elasticsearchの日毎のベンチマークで異なるパフォーマンスを見ることができます。(FastとFastUpdateのグラフを比較)\nもし、IDを自身が持っていて、自分の支配下でLuceneに対して素早く選ぼうとしているなら、1.3.2にアップグレードしましょう、IDのルックアップがさらにオプティマイズされています。JavaのUUID.randomUUID()はやめましょう。それは、セグメントに対してどのようにIDを割り当てるかという予測やパターン性がないため、最悪のケースでセグメントごとのシークが発生します。\nFlake IDsを利用した時のMarvelによるインデックス性能の違い：\nflakeIDsPerf ランダムUUIDを利用した場合：\nuuidsPerf 次の1.4.0では、ElasticsearchのID自動採番をUUIDからFlake IDに変更します。\nもし、Luceneのローレベル操作がインデックスに対してなにをやっているかについて興味があるなら、lucene.iwをTRACEログレベルで出力できるようにしてみましょう(1.2から利用可能)。これは、多くの出力がありますが、LuceneのIndexWriterレベルで何が起きているかを理解するのに非常に役に立ちます。出力は非常にローレベルです：Marvelがインデックスに何が起きているかをよりリアルタイムにグラフを描画してくれます。\nスケールアウト 我々は、単一シャード(Luceneインデックス)性能のチューニングに注目してきました。しかし、一旦それに満足できたならば、Elasticsearchはクラスタ全体にわたってインデキシングや検索を簡単にスケールアウトすることに長けています。シャード数(デフォルトでは5)を増やすのは可能です。それは、マシン全体に対して並列度、巨大なインデックスのサイズ、検索時のレイテンシの低下など得ることができます。また、レプリカを1位上にすることは、ハードウェア故障に対する冗長性を持つことを意味します。\n最後に、このドキュメントを見ても問題解決しない場合はコミュニティに参加しましょう。例えば、ElasticsearchのユーザMLに投稿するなど。おそらく、修正すべきエキサイティングなバグがあるでしょう。(パッチも常に歓迎です！)\n","date":1410250260,"dir":"post/2014/","id":"77d965afaebd7193badc746d52b4173f","lang":"ja","lastmod":1410250260,"permalink":"https://blog.johtani.info/blog/2014/09/09/performance-considerations-for-elasticsearch-indexing/","publishdate":"2014-09-09T17:11:00+09:00","summary":"Elasticsearchのインデキシングに関するパフォーマンス検討 原文：performance considerations for elasticsearch indexing Elasticsearchユーザは様","tags":["Elasticsearch"],"title":"Elasticsearchのインデキシングに関するパフォーマンス検討"},{"contents":"懲りずにまた、執筆してみました。みなさん「買って」から感想をいただけるとうれしいです！\n本書について 共著者の方々のブログが詳しいので、そちらを読んでもらいつつ。 実際にログを収集して解析されている方々と一緒に書かせていただくことで色々と勉強させていただいています。\n共著者の方々のブログ @suzu_vさん：サーバ/インフラエンジニア養成読本 ログ収集~可視化編 を書きました @yoshi_kenさん：ログ収集や可視化で話題のFluentd、Elasticsearch、Kibanaを徹底解説したムック本が発売となります @harukasanさん：書きました: サーバ/インフラエンジニア養成読本 ログ収集~可視化編 どの辺を書いたの？ 「特集３：Elasticsearch入門」（なんか、入門ばっかりだなぁ）を書かせていただきました。 データストア入門ということで、ほんとうに簡単な他のデータストアを説明し、Elasticsearchってどんなものかを単語の説明をしつつ紹介してみました。\nElasticsearch自体は多くの機能を持っており、それ単体で分厚い書籍がかけるので、ログ検索に関係ありそうな部分をピックアップしてみました。 あとは、運用時に気をつける点や便利なツール（Curatorなど）の紹介をしています。\nまた、Hadoopと合わせて利用してみたい、すでにHadoopにあるデータも活用してみたいという話もありそうだということで、elasticsearch-hadoopについても簡単ですが紹介してあります。\nその他感想 個人的に、忙しい時期（参考記事）だったので、あんまり力になれてないので大変申し訳なく思っています。。。 ただ、素晴らしい出来（カラーでKibanaの解説が日本語で読めたり、Fluentdの逆引きのリストがあったり、ログを貯めて可視化する意義を説明してあったり）です。\nぜひ、読んだ感想をいただければと！\n","date":1407156840,"dir":"post/2014/","id":"bdea71d64cdfcc405e65e750fe8d9b86","lang":"ja","lastmod":1407156840,"permalink":"https://blog.johtani.info/blog/2014/08/04/release-magazine-book-of-log-aggs-and-viz/","publishdate":"2014-08-04T21:54:00+09:00","summary":"懲りずにまた、執筆してみました。みなさん「買って」から感想をいただけるとうれしいです！ 本書について 共著者の方々のブログが詳しいので、そちらを","tags":["elasticsearch","kibana","本"],"title":"サーバ/インフラエンジニア養成読本 ログ収集~可視化編 を手伝いました"},{"contents":"Proxy環境で働いている方も結構いると思います。 Twitter上で、Elasticsearchのpluginコマンドでプラグインがインストールできなくて困っている方がいたので、 調べてみたのでメモしておきます。\nプラグインコマンド Elasticsearchでは、プラグインという形でいくつかの便利な機能が公開されています。 形態素解析ライブラリのKuromojiを使うためのプラグインや、クラスタの管理がGUIで可能なkopfプラグインなどがあります。 公式、サードパーティいろいろです。\nこれらのプラグインをElasticsearchにインストールする場合、以下のコマンドを実行すれば 自動的にダウンロードしてpluginsディレクトリにインストールしてくれます。\n./bin/plugin -i elasticsearch/elasticsearch-analysis-kuromoji/2.3.0 ここで、elasticsearch/elasticsearch-analysis-kuromoji/2.3.0がプラグインのパスになります（例では、提供元/プラグイン名/プラグインバージョンとなっています。）。\nこのpluginコマンドがダウンロード元にアクセスに行くのですが、プロキシ環境だとプロキシの設定が必要になります。\nプロキシの指定（Mac/LinuxとWindowsでの違い） Mac/Linux(shコマンド) 以前の記事でプロキシのポート番号などの指定方法を 以下のように説明していました。 （※昔の記事のため、kuromojiプラグインのバージョンが古いです）\nElasticsearchのpluginコマンドはJavaで実装されています。（org.elasticsearch.common.http.client.HttpDownloadHelper） プラグインのダウンロードには、java.net.URL.openConnection()から取得URLConnectionを使用しています。\nですので、pluginのインストールを行う際に、Proxy環境にある場合は以下のようにコマンドを実行します。\n./bin/plugin -DproxyPort=ポート番号 -DproxyHost=ホスト名 -i elasticsearch/elasticsearch-analysis-kuromoji/1.5.0 LinuxやMacの環境であれば、こちらのコマンドでプロキシの指定が可能です。 ただし、Windows環境ではうまくいきません。\nElasticsearchは、環境の違いにより、ダウンロードするファイルが異なります。 Windows環境の方は、zipファイルをダウンロードしてもらうようになっています。 elasticsearchコマンドおよびpluginコマンドがbat形式で提供されているのがzipファイルとなるからです。\nWindows(batコマンド) Windows環境では次のように指定します。\nset JAVA_OPTS=\u0026#34;-DproxyHost=ホスト名 -DproxyPort=ポート番号\u0026#34; bin\\plugin -i elasticsearch/elasticsearch-analysis-kuromoji/2.3.0 コマンドの実装方法が少し異なるために、このようになっています。\nまとめ プロキシ環境で利用される場合は、プラグインコマンドは上記のように実行していただければと。\n公式ガイドには、これらの情報を追記するPRを送る予定です。 また、WindowsのコマンドでもMac/Linuxと同様にできたほうがいい気がするので、Issueをあげようと思います。\n不明点などあれば、コメントいただければと。\n","date":1406874240,"dir":"post/2014/","id":"7cc605e721fdd1d2ccc16f5b6490e830","lang":"ja","lastmod":1406874240,"permalink":"https://blog.johtani.info/blog/2014/08/01/plugin-using-under-proxy-env/","publishdate":"2014-08-01T15:24:00+09:00","summary":"Proxy環境で働いている方も結構いると思います。 Twitter上で、Elasticsearchのpluginコマンドでプラグインがインスト","tags":["elasticsearch","plugin"],"title":"プロキシ環境でのpluginコマンドの実行"},{"contents":"原文：Elasticsearch 1.3.1 Releasedを日本語に翻訳したものです。\nバグフィックス版のElasticsearch 1.3.1をリリースしました。 ダウンロードおよび変更履歴はElasticsearch 1.3.1からお願いいたします。\nこのリリースはインデックスリカバリ時の後方互換性バグ（#7055）への対応です。 このバグはデータの欠損は起こりません。 Elasticsearch 1.3.1へアップグレードすることで問題を回避できます。 このバグは、以下のElasticsearchのバージョンで作成されたセグメントを含むインデックスを1.3.0へアップグレードしようとすると発生します。\nElasticsearch 0.90.7 Elasticsearch 0.90.2 Elasticsearch 0.90.0以前のバージョン このバグは、これらの古いインデックスをレプリカからリカバリできなくします。 これらのバージョンのセグメントを持つインデックスが、レプリカは可能ですが、 ステータスがYellowのままGreenに決してなりません。 ログには次のようなExceptionが発生します。\nIllegalArgumentException[No enum constant org.apache.lucene.util.Version.x.x.x]\nLuceneの特定のバージョンではLuceneのマイナーバージョンを含んでおらず、誤ったバージョン番号がセグメントに記録されました。 LUCENE-5850のチケットがこの問題に対処するためにオープンされています。 この問題は我々の後方互換テストで見つかるべき問題ですが、Luceneで不足しているため発見されませんでした。 テストスイートは今後の可能性のために改良されます。\nこのリリースはその他に、Aggregationのマイナーバグフィックスも含まれています。 詳細はリリースノートをご覧ください\nElasticsearch 1.3.1をダウンロードし、試してください。 もし問題を見つけた場合はGitHubのIssuesへご報告をお願いいたします。\n","date":1406604120,"dir":"post/2014/","id":"fb1da4a6ed74705ad98bb60ad4badaf2","lang":"ja","lastmod":1406604120,"permalink":"https://blog.johtani.info/blog/2014/07/29/elasticsearch-1-3-1-release/","publishdate":"2014-07-29T12:22:00+09:00","summary":"原文：Elasticsearch 1.3.1 Releasedを日本語に翻訳したものです。 バグフィックス版のElasticsearch 1.3.1をリリー","tags":["elasticsearch","release"],"title":"Elasticsearch 1.3.1 リリース（日本語訳）"},{"contents":"Curatorの1.2.0がリリースされました。\n前回のCuratorの記事が古くなってしまった（1.1.0からコマンドのI/Fが変更された）ので 1.1.0および1.2.0に関する記事を翻訳しておきます。\nちなみに、Curatorとは、Elasticsearchに時系列のインデックス（例：LogstashやFluentdでログを保存）を保存している場合にそれらのインデックスを管理（削除したり、クローズしたり）するための便利なツールです。 Curatorの概要については、GitHubリポジトリか前回の記事をご覧ください。\nCurator 1.1.0リリース (2014/06/13公開) 元記事：elasticsearch curator - version 1.1.0 released\nElasticsearch 1.0.0がリリースされ、新しい機能、Snapshot \u0026amp; Restoreが利用できるようになりました。 Snapshotはある時点でのインデックスの写真を撮るように、バックアップを作成することができます。 1.0.0が発表されてすぐに、この機能に関するリクエストが寄せられるようになりました。 「Curatorにスナップショットを追加して！」もしくは「いつCuratorでスナップショットが使えるようになる？」といった感じです。 これがあなたの要望なら、それはついに叶えられました。しかも他の追加機能も一緒にです。\n新機能 Curatorの新機能は以下のとおりです。\n新CLI構造 スナップショット(Snapshot) エイリアス(Aliases) パターンによる除外インデックス指定 配置ルーティング(Allocation Routing) インデックスとスナップショットの表示 リポジトリ管理(個別のスクリプトによる) ドキュメントWiki 新コマンドライン構造 注意：コマンドライン構造の変更とは、Curator 1.1.0以前のcron記述が動作しないことを意味します。Curator 1.1.0にアップグレードする場合はコマンドも修正が必要となるので注意してください。\nシンプルにするために、commandsという概念を追加しました。 また、ヘルプの出力もわかりやすくなっています。 前のバージョンと同じタスクをCuratorは実行できますが、異なるフォーマットを用いるようになりました。\n旧コマンド：\ncurator -d 30 新コマンド：\ncurator delete --older-than 30 コマンドは、フラグとは異なりハイフンを前に付けないことに注意してください。 また、似たような名前のフラグがあることに気をつけてください。 例えば、--older-thanフラグは多くのコマンドに利用できます。 指定される値は各ケースにおいて同一です。「指定された数よりも古いインデックス」となります。\n新しいコマンドのリストは次のとおりです。\nalias allocation bloom close delete optimize show snapshot コマンドのヘルプは次のコマンドで表示されます。\ncurator [COMMAND] --help コマンドに関係あるフラグがすべて表示されます。\nスナップショット(snapshots) snapshotコマンドで、存在しているリポジトリにインデックスのスナップショットを保存することができます。\nCuratorはインデックス毎に1つのスナップショットを作成し、インデックスから名前をつけます。 例えば、インデックスの名前がlogstash-2014.06.10の場合、スナップショットの名前はlogstash-2014.06.10となります。 指定した条件を元に、シーケンシャルに、1つずつインデックスのスナップショットを作成していきます。\ncurator snapshot --older-than 20 --repository REPOSITORY_NAME このコマンドは、20日以上古いインデックスすべてのスナップショットを作成し、REPOSITORY_NAMEで指定されたリポジトリに保存します。\nes_repo_mgrと呼ばれるリポジトリ作成を支援するスクリプトがCuratorには含まれています。 ファイルシステムおよびS3タイプのリポジトリ両方の作成を支援します。\nさらに、古いインデックスのスナップショットを取ることができることに加えて、Curatorは最新のインデックスをアップロードする方法も提供します。 これは、Elasticsearch Marvelのインデックスをアップロードするときに便利です。 トラブルシューティングを目的として、パフォーマンスデータを他の人に見せる場合などです。\ncurator snapshot --most-recent 3 --prefix .marvel- --repository REPOSITORY_NAME このコマンドでは、最新の3つのMarvelインデックスのスナップショットを指定されたリポジトリに保存できます。\nエイリアス(aliases) Curatorはすでに存在するエイリアスにインデックスを追加することも、削除することもできるようになりました。 ただし、エイリアスがすでに存在している必要があります。エイリアスの作成はできません。\nlast_weekという前の一週間のインデックスのエイリアスを保持していること想像してください。 この場合、次の2つのコマンドを利用することで、エイリアスを管理できます。\ncurator alias --alias-older-than 7 --alias last_week curator alias --unalias-older-than 14 --alias last_week 新しく作られたインデックスがインデックステンプレートによって 自動的にエイリアスの一部となるようにElasticsearchに設定しておくと、さらに便利です。 この場合、新しいインデックスが自動的にthis_weekというエイリアスの一部になるようにしてあれば、以下のコマンドのみとなります。\ncurator alias --unalias-older-than 7 --alias this_week this_weekとlast_weekのエイリアスのアップデートを保持できます。\nパターンによる除外(exclude pattern) 時には、指定したインデックスを操作から除外したくなる場合もあるでしょう。 ここまでは、プレフィックスや日付によって選択されたインデックスのみを対象にしてきました。 そこで、--exclude-patternオプションです。これは、指定したインデックスを除いて処理を行うことができます。\nlogstash-2014.06.11というインデックスを決して削除したくないとします。 この場合、次のコマンドのようになります。\ncurator delete --older-than 15 --exclude-pattern 2014.06.11 Curatorはデフォルトでlogstash-というプレフィックスにマッチしますが、2014.06.11というインデックスは対象外となります。\n配置ルーティング(allocation routing) Elasticsearchはノードにタグを付けることができます。 これらのタグはインデックスやシャードをクラスタのどこに配置するかをコントロールするために役立ちます。 一般的なユースケースだと、高性能なSSDドライブを持ったノードをインデキシングのために、ハードディスクを持った性能の低いマシンは検索頻度が低い古いインデックスを配置するといった場合です。 この場合、HDDノードには、elasticsearch.ymlにnode.tag: hdd、SSDノードにはnode.tag: ssdと設定されているべきです。 Curatorはこの時、インデックスをタグに基づいてオフピークの時間帯に再配置させることができます。\nコマンド：\ncurator allocation --older-than 2 --rule tag=hdd index.routing.allocation.require.tag=hddという設定が２日よりも古いインデックスに適用されます。 これは、インデックスのシャードがnode.tag: hddというノードに再配置される必要があると、Elasticsearchに伝えます。\nインデックスとスナップショットの表示(show indices and snapshots) これは、単にあなたの持っているインデックスやスナップショットがどんなものかを表示します。\ncurator show --show-indices これは、デフォルトプレフィックスのlogstash-にマッチするすべてのインデックスを表示します。\ncurator show --show-snapshots --repository REPOSITORY_NAME これは、指定されたリポジトリにある、デフォルトプレフィックスのlogstash-にマッチするすべてのスナップショットを表示します。\nリポジトリ管理(repository management) 前に説明したとおり、es_repo_mgrと呼ばれるヘルパースクリプトをCuratorは含んでいます。 現時点では、fsとs3タイプをサポートしています。 リポジトリを作る前に利用したいタイプのドキュメントを読むようにしてください。 例えば、fsタイプのリポジトリを各ノードで使う場合は、同じ共有ファイルシステムに、同じパスでアクセスできなければなりません。 パスの指定は--locationです。\nfsタイプリポジトリの作成\nes_repo_mgr create_fs --location \u0026#39;/tmp/REPOSITORY_LOCATION\u0026#39; --repository REPOSITORY_NAME 削除\nes_repo_mgr delete --repository REPOSITORY_NAME ドキュメントWiki Curatorのドキュメントが更新され、オンラインにWiki形式でだれでも更新できるようになっています。 コマンドやフラグのより詳細の情報はこちらで見つけることができます。また、もし、興味があれば、ドキュメントを追加することもできます。\nインストールと更新 Curator 1.1.0はPyPiリポジトリにあります。 インストールは以下のとおりです。\npip install elasticsearch-curator バージョン1.0.0からアップグレードする場合は以下のとおりです。\npip uninstall elasticsearch-curator pip install elasticsearch-curator バージョン1.0.0よりも古いバージョンからのアップグレードは以下のとおりです。\npip uninstall elasticsearch-curator pip uninstall elasticsearch pip install elasticsearch-curator pip uninstall elasticsearchで、古いパイションモジュールをを削除します。 適切なバージョンが依存関係により再インストールされます。\nまとめ Curatorの新機能は素晴らしいです！このリリースは大きな改善です。 もし、トラブルや足りないものを見つけた場合はGitHub Issueに報告してください。 また、Curatorが便利だと思ったら、私たちに伝えてください。#elasticsearchタグを付けてツイートしてください！\nCuratorはまだ、始まったばかりです。Curator 2.0のロードマップを作業中です。ここまで読んでいただきありがとうございます。 Happy Curating!\nCurator 1.2.0リリース(2014/07/24) 元記事：curator 1.2.0 released\nCurator v1.1.0のリリースから、数週間が経ちました。 私たちは、Curator 1.2.0をリリースしました。\n新機能(new features) ユーザ指定の日付パターン：長い間リクエストされていた機能 ウィークリーインデックスのサポート：これも長い間リクエストされていた機能 複数のログフォーマットオプション：Logstashフォーマットが利用可能 これらの変更はCuratorドキュメントにも記載されています。\n更新(updates) ログ出力の整理：デフォルトのログ出力を整理しました。デバッグログはすべて表示されます。 ドライランのログ出力の詳細化：テスト実行時に何が起きたかをわかりやすくしました。 日付パターンと--timestring(date patterns and \u0026ndash;timestring) 前のリリースで、セパレータ文字を利用して、インデックス名のエレメントを分離することで、日付を計算しました。 この設計の決定は、プログラムが管理するために設計されたLogstashのインデックスを使うのには簡単でした。 しかし、Curatorは時系列インデックス管理に成長しています。これは、異なる命名規則のインデックスを意味しています。\nまた、インターバルによって、日付の計算が必要になる場合もあります。 --time-unitオプションが残っており、weeksという単位を指定することもできます。 デフォルトの--timestringオプションは、以前のコマンドと同様の動作をしなければなりません。次のようになります。\nTime Unit Timestring days %Y.%m.%d hours %Y.%m.%d.%H weeks %Y.%W これが意味するものは、もし、単位にhoursをした場合、--timestringを指定しなかった場合は%Y.%m.%d.%Hとなります。 これは、Pythonのstrftimeフォーマットで\u0026quot;年.月.日.時\u0026quot;を意味します。 同様に、weeksを単位に指定した場合、Curatorはデフォルトの--timestringは%Y.%Wとなります。\nこの機能は、日付の間にセパレーター文字のないインデックスでも機能します。 例えば、production-20140724のような日時インデックスがある場合、2日よりも古いインデックスに対するブルームフィルタっキャッシュのオフのコマンドは次のようになります。\ncurator bloom --prefix production- --older-than 2 --timestring %Y%m%d この例で、デフォルトの単位はdaysであることに注意してください。hourly-2014072414のような時間インデックスの場合は次のようになります。\ncurator bloom --prefix hourly- --older-than 2 --time-unit hours --timestring %Y%m%d%H --separatorの置き換え もし、Curatorの前のバージョンでカスタムセパレータ文字を利用していた場合、次のように変更すべきです。 前のコマンドでcerberus-2014-07-24のようなインデックスがある場合、コマンドを--separator -の用に置き換える必要があります。 新しいコマンドは次のとおりです。\ncurator delete --prefix cerberus- --older-than 30 --timestring %Y-%m-%d 年(％Y)と月(%m)と日(\u0026rsquo;%d\u0026rsquo;)の間にセパレータ文字を置くだけです。\nこれは、また、Curatorで以前は不可能であったことをできるようにもします。 異なるセパレータ文字の混在です。 logs-2014.07.24-14というようなインデックスを処理するときに--timestringは%Y.%m.%d-%Hのようになります.\n--timestringの詳細はCuratorのドキュメントをご覧ください。\nフィードバック これらの新しい機能はユーザのコメントやリクエストから来ています。もし、機能のリクエストやバグを発見したら、こちらまで連絡してください。\nまた、Twitterでもお待ちしています。私たちのTwitter IDは@elasticsearchです。\nHappy Curating!\n","date":1406524740,"dir":"post/2014/","id":"0c1821d1069578551d0e3c7d9275f16b","lang":"ja","lastmod":1406524740,"permalink":"https://blog.johtani.info/blog/2014/07/28/curator-2-0-and-1-1/","publishdate":"2014-07-28T14:19:00+09:00","summary":"Curatorの1.2.0がリリースされました。 前回のCuratorの記事が古くなってしまった（1.1.0からコマンドのI/Fが変更された）","tags":["elasticsearch","curator"],"title":"Curator 1.2および1.1について"},{"contents":"第5回Elasticsearch勉強会を開催しました。 遅くなってしまいましたが、まとめてみました。\n今回は、Elasticsearchに入って初の勉強会でした。タイミングが良いことに、Honza、Igor、Shayの3名がトレーニングのために 来日していたため、特別回ということにして、話をしてもらいました。\nそして、サムライズムの@yusukeさんにテキスト翻訳してもらいました。 早くて正確なタイピング＋翻訳、本当にありがとうございました。\n開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！ 参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\namazing turnout to the elasticsearch at Tokyo #elasticsearchjp pic.twitter.com/Aa88eVf5dF\n\u0026mdash; Shay Banon (@kimchy) 2014, 7月 14 動画があとで、アップされる予定です。お楽しみに。\nHonza\u0026rsquo;s talk djangoの開発者！であり、ElasticsearchのPythonクライアント、Curatorの開発者 Python Clientを利用しながら、ライブコーディングのような形で説明する方法が新鮮 Aggregationの便利さについての説明 Python Clientがクエリを組み立てるのにすごく便利そうだった Pythonユーザが結構いたので助かりましたｗ Igor\u0026rsquo;s talk スライド：elasticsearch data/\nSnapshot/Restoreの開発などを行っている開発者 Elasticsearchのデータ、ディレクトリ構造に関するお話 シャードの話から、ディレクトリ構造、メタデータに関する説明 transaction logの挙動の説明 検索のフェーズの説明 Igorは、実は私がElasticsearch社の人とコンタクトがとれた最初の人だと思います。 第1回Elasticsearch勉強会が開催する当日に帰国されるという不運だったのですが、1年越しでトークしてもらえました！\n@johtani I am so bummed! I am leaving Tokyo Thursday morning.\n\u0026mdash; Igor Motov (@imotov) 2013, 8月 27 QA ShayをメインにいくつかのQAをしてもらいました。 NetflixなどのMeetupの動画で見てたのですが、こんな形で日本でも実現できるとは。\nQ: なんで、ファイルデスクリプタの設定を大きくするの？ A: Luceneのインデックスは複数のセグメントから構成されている。メモリに作られたあと、ファイルにfsyncされる。 Q: KibanaでAggregation使いたいんだけど？ A: Kibana 4で対応するよ！異なるフィールドの値を1つのグラフにすることも出来るよ！ Q: なんでElasticsearch作ったの？ A: 暇だったからｗ奥さんのレシピ検索を作ってみようと思って作り始めて、Luceneを触って感動して。。。検索すげー、Compassってのを触ってこれもすごいと思いつつ、もっとLucene活用できるんじゃないかということでElasticsearch作ったんだ。奥さんのレシピ検索？まだ完成してないよｗ Q: 2000くらいスナップショット撮ったらパフォーマンスが悪くなっててなんで？ A: 差分でスナップショットを作るんだけど、差分の計算に昔のスナップショットを見るので、定期的に新しくしたほうがいい。もし、気になることがあったらIssue上げたりMLに投げてくれるとうれしい。\n（あとでちょっと聞いたけど、古いスナップショットを消すのも有効っぽい。差分でスナップショットを作るけど、昔のを消した場合は、新しいスナップショットが利用しているファイルは残る仕組みになっているから。） Q: Relevancyのチューニングってどうすればいい？ドキュメントが少なくない？ A: ドキュメンテーションは頑張ってるので、応援してねｗあとは、definitive guideも参考になるよ。スコアはfunction_scoreクエリがすごいのでいろいろ使ってね。MVELをGroovyに帰る予定。性能もだけど、サンドボックス的な意味もあります。 Q: 次のVisionは？現時点は検索だけど。（最後の質問がとてもナイスで、助かりましたｗ私がしたほうがいい気がするｗｗ） A: 今後はアナリティクスのプラットフォームに向かってる。Aggregationとかね。メモリ効率よくしたりしてるよ。あとは、Field-collapsionも実装中だよ。あと、マシンラーニングとかもね。データを探索するための機能を色々作ってくよ。障害性にも。チェックサム機能をLuceneに入れて、ESにも入れていく予定。Zenの機能も改善している。 まとめ 今週は、トレーニングがあったり、いろいろな打ち合わせがあったりと、テンパってたので至らない点が多かったかもしれないですが。。。 楽しんでいただけと思います。 数日、Shay、Honza、Igorと行動を共にして、本当に情熱のあるチームでユーザのことを気にかけているなと感じることができました。 少しでもその片鱗を勉強会で感じてもらえたんじゃないかと。特に、QAでのShayによる情熱が伝わったんじゃないかと。\n懇親会でも数人の方から、日本語のサポートを望んでいるという声も頂きました。 興味のある方は私までコンタクトいただければと。\nあと、@yusukeさんのテキスト翻訳が素晴らしくて、参加してもらった方たちも絶賛してました。 次回も英語スピーカーの場合に助けてもらえると嬉しいです（私もそこまで出来るように頑張ります）\nその他のブログ ブログ記事ありがとうございます！\n第5回elasticsearch勉強会にいってきました - はやさがたりない。 感想戦：aggrigation から見える検索エンジンの次 - 第5回 Elasticsearch勉強会 - よしだのブログ 「第5回elasticsearch勉強会 #elasticsearch #elasticsearchjp」（2014年07月14日）の参加メモ - uchimanajet7のメモ ","date":1405774320,"dir":"post/2014/","id":"e3e146469ed4318eaa2ffbca3510c054","lang":"ja","lastmod":1405774320,"permalink":"https://blog.johtani.info/blog/2014/07/19/hold-on-5th-elasticsearch-jp/","publishdate":"2014-07-19T21:52:00+09:00","summary":"第5回Elasticsearch勉強会を開催しました。 遅くなってしまいましたが、まとめてみました。 今回は、Elasticsearchに入って","tags":["elasticsearch","勉強会"],"title":"第5回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"ということで、転職しました。 どーしてもやりたいことが出てきたので、無理を言って転職することにしてみました。\nサムライズムではなく、Elasticsearchにジョインします。（というか、しました。）\n初出社 #サムライズム\n\u0026mdash; Jun Ohtani (@johtani) 2014, 7月 1 冗談でツイートしたのですが、その前に英語アカウントのツイートがRTされてしまっていまいちでした。。。\nスキポール空港 先週、アムステルダムに行っていたのも退職前に休みをいただき、Elasticsearchの全社会議に参加していたためです。 とてもエキサイティングな経験（英語漬けとか）ができ、もっと精進しないとなという気持ちにもなり、ますます頑張らないとなと。\nということで、今後は日本中にElasticsearchやLogstash、Kibanaを広めるべく、いろいろな場所で話をしたいと思います。 興味のある方は、声をかけていただければと。\nあと、東京でElasticsearchのCoreトレーニングが行われます。 通常は2日間ですが、通訳の方が付く関係で3日間の開催となっています。 開発者2名がトレーナーとして来日します。開発者に質問をできる良い機会ですので、興味のある方は参加してみてはいかがでしょうか。 また、CTOのShay Banonも来日する予定です。\nトレーナー2名とShayは7/14の勉強会でも話をしてくれます。 こちらも興味のある方は参加してみてください。（参加登録はこの後、すぐに開始します。）\nまだまだ、勉強しなければいけないことだらけですが、ElasticsearchのいろいろなプロダクトやOSSについて広めていきたいと思いますので、よろしくお願いいたします。\nおまけ ということで、一度やってみたかったのでリンクを貼ってみます。\nほしい物リストはこちら\n","date":1404181800,"dir":"post/2014/","id":"21a8e6324e9330d4f8ebade604c62b6e","lang":"ja","lastmod":1404181800,"permalink":"https://blog.johtani.info/blog/2014/07/01/join-elasticsearch/","publishdate":"2014-07-01T11:30:00+09:00","summary":"ということで、転職しました。 どーしてもやりたいことが出てきたので、無理を言って転職することにしてみました。 サムライズムではなく、Elasti","tags":["転職"],"title":"転職しました"},{"contents":"退職しました。\n色々と書きたいんですが、時差ボケで頭痛いので、このくらいです。 余裕出たら書くかも。\nほしい物リストはこちら\n新天地についてはまた明日。\n","date":1404137940,"dir":"post/2014/","id":"40abea0a87a64bd832a1fad69458b293","lang":"ja","lastmod":1404137940,"permalink":"https://blog.johtani.info/blog/2014/06/30/resignation/","publishdate":"2014-06-30T23:19:00+09:00","summary":"退職しました。 色々と書きたいんですが、時差ボケで頭痛いので、このくらいです。 余裕出たら書くかも。 ほしい物リストはこちら 新天地についてはまた明","tags":["転職"],"title":"退職しました"},{"contents":"Elasticsearch server 2nd editionが発売されています。\n私が翻訳したのは前のバージョンですが。。。 まずは、目次を元にどのくらい変わってるかを見てみました。 （全部まだ読んでなくて。。。）\n1章 Getting Started with the Elasticsearch Cluster 冒頭に、全文検索とは、転置インデックスとはどんなものか、 Luceneの簡単なアーキテクチャの仕組みについて説明が追加されています。 検索の仕組みを知らない人が読んでもわかりやすくなっています。\nインストール方法なども少し追記されています。 バージョニングと簡単なデータ登録と検索方法についてもここで触れられています。 検索結果の構造の説明もちょっとあります。 まず簡単に触ってみるというところまでが1章でまとめられた感じです。\n2章 Indexing Your Data 新しく、切りだされた形です。 前のバージョンでは1章で説明されていた、Mapping周りが切りだされています。 シャードやレプリカの説明もこちらです。\nIPアドレスタイプ（IPv4のみ）とtoken_countタイプの説明も追加されてます。 similarityやpostingsフォーマットなどは新しく追記されています。 また、メタフィールドと呼ばれる_typeなどはこちらに移動しているようです。 マージ処理などの説明も追記されています。このあたりは、Mastering ElasticSearchに 記載されているものが移植された感じでしょうか。\n3章 Searching Your Data 前のバージョンでは2章だった章です。 クエリについては1.0で追加されたsimple_query_stringなどが追記されています。 constant_scoreやdismaxなどもです。\nまた、前のバージョンの3章で説明されていたハイライトや8章で触れられていたvalidate APIについても 移動しています。\n4章 Extending Your Index Structure 前のバージョンの3章で触れられていた、データの構造に関する部分がこの章になります。 親子や配列、ネスト等のデータのインデックスや検索の方法です。\n5章 Make Your Search Better スクリプティングや言語判定などの仕組みが記載されています。 また、ブーストについても同様です。Synonymについてもここです。 スパンクエリについては省略されたのかな？\n6章 Beyond Full-text Searching 1.0の目玉機能の一つであるAggregationの説明から始まります。 その後、ファセットやPercolatorについてです。メモリに関する注意点もありそうです。 また、Geoについての説明がこちらに移動されていました。 scroll APIについてもこちらで説明されています。\n7章 Elasticsearch Cluster in Detail 前の7章で記載されていたElasticsearchの分散の仕組み（Node Discovery）についての記載があります。 また、1.0で追加されたcircuit breakerやスレッドプール、インデックスのリフレッシュレートなど、Mastering ElasticSearchの 内容も追記されている気がします。\nインデックスやマッピングのテンプレート機能についてもここで説明があるみたいです。\n8章 Administrating Your Cluster 1.0で追加されたsnapshot/restoreの説明から始まります。 あとは、前のバージョンの7章で説明されていたクラスタ管理用のAPIについての説明です。 いくつか（例えばcat API）、1.0で追加されています。\nまた、シャードのリバランスの話も追加されているようです。 エイリアスやプラグインの話はこちらに移動してるみたいです。\n感想 ということで、とりあえず、駆け足で目次ベースで違いを見てみました。 Mastering ElasticSearchでの 知見がフィードバックされ、しかも1.0（すでに1.3が出そうな勢いですが。。。）にバージョンアップされた内容になっています。 冒頭がわかりやすくなっているので、検索をやったことのない方にもおすすめな書籍になった気がします。 英語が苦にならなければ、おすすめの一冊だと思います。\n来月から読み進めるつもりなので、また、面白い内容があったら感想を書いていこうと思います。 （また翻訳できるといいかもなー）\n","date":1402908420,"dir":"post/2014/","id":"916bda59bc7621d5c1790c040572a3c0","lang":"ja","lastmod":1402908420,"permalink":"https://blog.johtani.info/blog/2014/06/16/first-impression-elasticsearch-server-2nd-edition/","publishdate":"2014-06-16T17:47:00+09:00","summary":"Elasticsearch server 2nd editionが発売されています。 私が翻訳したのは前のバージョンですが。。。 まずは、目次を元にどのくらい変わってるかを見てみました。 （","tags":["elasticsearch","本"],"title":"Elasticsearch server 2nd editionのファーストインプレッション"},{"contents":"可視化ツール現状確認会に参加して、カジュアルウォーターじゃなくて可視化ツールの現状を確認してきました。\nということで、いつものメモです。\nMackerel と Graphite について （y_uuk1さん） Graphite 時系列 工夫すればスケーラブル SensuやCollectdと組み合わせたり GrafanaとGrapheneでGUI Mackerel素敵だよと。 架空のわかりやすいグラフが見れた Kibana \u0026amp; Grafana \u0026amp; Influga （hakoberaさん） Kibana\nかっこいい。 JVM大変。 Grafana\nGraphiteがカッコ悪いのでKibanaをフォーク なぜか、ESが必要。 InfluxDBに浮気しそう Influga\n@haoberaさん作 InfluxDB Queryサポート 迷ったら、Kibana入れとけ。\nDistinctがKibana出できないけど、それ以外はある程度行けるらしい。\naggregationがサポートされたら、できると思う。 Kibana以外は、バックエンドがタイムシリーズなので、縛りがある\n可視化ツール紹介（仮） （showyouさん） 誰がチャートを作るの？ 誰が見るの？ 一覧化されてて、あとで眺めたい IPython Notebookのデモ R shiny Serverのデモ Pentaho CE+Saikuのデモはネットワークがダメだったので割愛 分析側の視点を見せたかったので。 可視化とは何だったのか （harukasanさん） インフラ モニタリング、アナライズ、可視化どれ？ 可視化は目的ではないよねと。 熱く、ユーザとサービスプロバイダ間の距離のお話。 ログ 生ファイルで残すのが重要 トータルで必要とか考えないといけないことがわかって面白かったｗ\nあなたの知らないrrdtool （shoichimasuharaさん） すげー！ いろいろできるらしい（ノートPCの前にいなかったｗ） D3.jsとジオマッピング （Takaki_さん） 時空間推進課！すげー！ ジオデータのおはなし。 TopoJSONとかGeoJSONとか Zipkinについて （synkさん） ものすごい数のJVMがThriftで殴りあってるらしい。 ZipkinはTwitterが作ったもの Brave、HTraceというのが、PureJava用のZipkinトレーシングプラグイン 見積もりする必要がないくらいでかいHBaseがあるので、そこにためてる。 まとめ LINEはエンジニアを大募集中 Graphiteについて (mickey19821 さん) ドリコムさんのGraphiteのおはなし Metricsの収集はCollectd Graphite-webがスケールできなくて困ってるらしい。 Graphiteで可視化ツラいｗ まとめ RRDTool最高\nあと、クックパッドの技術力がすごいという発表なんかもありました。\n","date":1401884100,"dir":"post/2014/","id":"5bb6f8322cdbda7a21e4aecbe04462b7","lang":"ja","lastmod":1401884100,"permalink":"https://blog.johtani.info/blog/2014/06/04/attending-visualize-study/","publishdate":"2014-06-04T21:15:00+09:00","summary":"可視化ツール現状確認会に参加して、カジュアルウォーターじゃなくて可視化ツールの現状を確認してきました。 ということで、いつものメモです。 Mackerel と Graphite","tags":["勉強会"],"title":"可視化ツール現状確認会に参加してきました。#可視化"},{"contents":"今月2回目の目黒で、初のドリコムさんです。 「最新インフラエンジニア技術勉強～Fluentd, Elasticsearch,Chefの実践実例～」に参加してきました。 もちろん、Elasticsearchってキーワードがあったからです。\nざっくりメモです。\nドリコムのInfrastructure as Code/ひらしーさん CM：jojoss、トレクル、など サーバ300台、クラウド○○台。月30〜50台の割合で増加中。 少人数でいかに回すか。 Chef Rubyが書ける人が多いから。 serverspec テストだよと。 すみません、色々と聞き逃しました。。。\nWinning the metrics battle/mickeyさん Graphiteとかを触っている。 1300台超えたら、色々大変だった。 失敗談 Cactiを利用して、色々と運用が大変だった。DCが別なのでProxyとか。 成功例？現行システム？ 最大値、平均値、最小値などをプロット collectdを収集、送信に採用して、独自で開発？ 受信して保存するのに、Graphite（carbon-relay、carbon-cache、DRBD、graphite-web）ってなってる。 1300台程度のサーバから、5分間隔で、問題ない。 Graphite良いツールだよ。 Q：過去データはどのくらい？ A：5分間隔で1年分。\nQ：移動平均とかを使ったグラフとか時間かかりませんか？100台だと A：100台でもほとんど時間はかからない。\nFluentd プラグイン開発講座/外山 寛さん Fluentdプラグインを作ることができると威力倍増 Elasticsearchの勉強会の話までしてくれました！ 勉強会スペース貸出しています。 未公開だけど、sedueのプラグインもあるらしい。 CHUNKとBUFFERとか覚えときましょう プラグインの作り方的なのがなかった気がしたので、今回の発表です。 gem作らなくてもディレクトリにおけば使えるよと。 td-agent使ってる人が大多数だよね。（fluentdを素で使ってる人は会場にはいなかった） エンジニア募集中 Q：エラー処理どうしてますか？ A：今は、スルーしています\nQ：単体テストの書き方は？ A：人によってバラバラみたいですね。\nMySQLと組み合わせて始める全文検索エンジン「elasticsearch」/yoshi_ken スライド：http://www.slideshare.net/y-ken/introduce-elasticsearch-mysql-importer\nElasticsearch歴は1年位です。\nMySQLを使っていて、モダンな検索がほしいですよね？ね？\nサジェスト、ファセット、位置情報、ネスト検索などなど。\nGoogleトレンドだとSolrに迫る勢いと。\n実データを用いて、手軽にElasticsearchと連携。\nBinaryLogではなく、SQLの結果を同意する方式。yamabiko\n今日は、新しいものを公開します。\nbulk import file generator as well as nested document from MySQL for elasticsearch bulk api 東京トレーニング\nElasticsearch本については、右にあるリンクをクリックしてくれるとうれしいなぁ。\n","date":1400840280,"dir":"post/2014/","id":"a578acf825a595ce95fe8f804b7208f0","lang":"ja","lastmod":1400840280,"permalink":"https://blog.johtani.info/blog/2014/05/23/attending-drecom-infra-study/","publishdate":"2014-05-23T19:18:00+09:00","summary":"今月2回目の目黒で、初のドリコムさんです。 「最新インフラエンジニア技術勉強～Fluentd, Elasticsearch,Chefの実践実例～","tags":["勉強会","elasticsearch"],"title":"最新インフラエンジニア技術勉強に参加しました。"},{"contents":"どうやら、中身がSolrベース？Luceneベース？になったらしいということで、 今日は「AWSプロダクトシリーズ｜よくわかるAmazon CloudSearch」に行ってきました。\n※ElasticSearchではありません！\nということで、いつものメモ。\nCloudSearch Overview Amazon Web Services, Inc. Pravin Muthukumar(Product Manager) / Vivek Sriram (Business Development) Introduction to Search 検索の紹介。アイアンマンのDVD？のページにいろんな項目（フィールド）があるよねと。（もちろん、Amazonのページ） ファセット、Geo、テキスト処理（Analysis処理）、Postings listとか。とかとか ランキングも Amazon CloudSearch 独自実装orRDB拡張もある。 OSSもあるよね。 Legacy Enterprise SearchとしてFASTとかもある。 Building with CloudSearch 他のサービス同様、コンソールとかあるし、色々できるし、すぐ起動できるよと。 自動で、データが増えたら、パーティションが増えると。\n日本語の形態素解析があるらしい。何を使ってるのかな？ ICUのノーマライズとかもやってくれるらしい。これかな？http://lucene.apache.org/core/4_8_0/analyzers-icu/index.html ユーザが辞書を指定できるのかな？ 備えてる機能の説明\nファセット SimpleQuery Autocomplete Highlight などなど\nMulti-AZにも対応 QA Q：NGramありますか？ A：今はないです。 Q：ユーザ辞書対応してますか？ A：今はないです。 Q：lang-detectあるか？ A：今はないので、自分で判定して、適切なフィールドに入れてね。 Expectation for CloudSearch Apache Solr contributor　大須賀　稔氏 Solr本の宣伝ありがとうございます！（右のアイコンから買ってもらえると更に嬉しいですｗ） Kinesisとかとの組み合わせとか、自然言語処理とか、いろいろとあるAWSのコンポーネントと組み合わせる例が欲しいと。 すばらしい、最後はManifoldCFがらみに持っていくとは。ACLがらみのクローリングとかあるといいじゃないでしょうかと。 Impression of using CloudSearch 吉田　匠氏　(@yoshi0309　http://blog.yoslab.com/) スライド：https://speakerdeck.com/yoshi0309/impression-of-using-cloudsearch\nお見かけしたことある気がするなぁ。 全部置き換えできる！わけではなさそう。。。 いいところ。 UIがいいし、セットアップが簡単 auto scaleがうれしい マルチドメイン、マルチスキーマがいい Luceneのdismaxサポートがいい。（edismaxじゃないのかな？） dismaxって書いてあるな。\nhttp://docs.aws.amazon.com/cloudsearch/latest/developerguide/search-api.html\nフィードの仕方に気をつけて！\nバッチサイズで課金されるので、1件ずつじゃなくて、複数件送ったほうがいい。 いきなりスケールアウトできるわけじゃない？\nウォームアップ機能がない。インスタンス上限がデフォルト50件\nVPC対応してほしい。\nインターネット経由になってしまう フィードのスピードが セキュリティグループ機能が使えない CloudSearch UseCase - SnapDish Vuzz Inc.　清田　史和氏 独自辞書をもって、Tokenizeは独自でやって、空白区切りでデータ登録している。 インデックス更新はSQSを使ってる。 古いAPIを使ってるらしい。 移行が結構大変らしい。 感想 使ったことないんですが、きめ細かい検索したい場合はちょっとテクニックが要るかもと思いました。 AWS初心者なんで、なんとも言えないんですが。。。\nといあえず、テキスト処理（アナライズ処理）で、単語がどうやって区切られるのかってのがわからないのはキツイんじゃなかろうかと。 ただ、簡単に起動できて、オートスケールできるのは素晴らしいと思います。\n","date":1400143800,"dir":"post/2014/","id":"706c033b4483b6d062b66d6e4ea0236a","lang":"ja","lastmod":1400143800,"permalink":"https://blog.johtani.info/blog/2014/05/15/amazon-cloud-seaarch-study-session/","publishdate":"2014-05-15T17:50:00+09:00","summary":"どうやら、中身がSolrベース？Luceneベース？になったらしいということで、 今日は「AWSプロダクトシリーズ｜よくわかるAmazon Cl","tags":["勉強会","CloudSearch","AWS"],"title":"「よくわかるAmazon #CloudSearch 」に行ってきました！"},{"contents":"酔っ払ってなんとなく書きたくなったスピリチュアルなブログなので、流していただければと。\n最近、勉強会やTwitterで知り合いになって話をする人が増えたりで、 その方たちに色々と教えてもらうことが多いなぁと感じてます。 また、知り合いに恵まれてきたなぁとも。\nそもそも私が勉強会に参加し始めたきっかけはSolr勉強会（第1回から参加してて、気づいたら主催者になってた）で、 そのころは、Solr初心者で色々とやってる人、知ってる人がいて無料で話が聞けるのすごいと興奮したのを覚えてます。 （もちろん、ぼっちでしたが）\nSolr勉強会が定期的に開かれて、それに参加しているうちに少しずつ知り合いもできて、 面白そうな勉強会（Hadoopとか）が他にもあるんだ、参加してみようかって思うようになってと。\nそこにプラスで、関口さんと知りあえてSolr本を書く話が出てきて、本を書いてみたら、 今度は勉強会で話してみませんかとなって。\nスピーカーやると、顔を覚えてもらえるようで、また知り合いが増えてと。\n人のつながりって大事だし、自分が発信することで教えてもらえることもあるしと。 前にも書いた気がするけど、Solr勉強会（当時の主催の方）や関口さんやElasticsearch勉強会のスタッフの方や スピーカーやってくれた方、会場提供を心よくしてくれてるVOYAGE GROUP、リクルートテクノロジーズさん、という具合にどんどん頭が上がらなくなってきてるなぁと。\nということで、外の世界を知ると色々とつながりが出来て面白いですよという、個人的な感想でした。 ま、自分が思ってるだけで、違う意見もいっぱいあると思うけど。\nあー、なんか、酔って勢いで書いてしまった。。。 脈略のない文章なきがするけど、エイヤで公開しちゃおう。\n","date":1399999440,"dir":"post/2014/","id":"72df0bf7853e05560d94208817b83468","lang":"ja","lastmod":1399999440,"permalink":"https://blog.johtani.info/blog/2014/05/14/spiritual-entry1/","publishdate":"2014-05-14T01:44:00+09:00","summary":"酔っ払ってなんとなく書きたくなったスピリチュアルなブログなので、流していただければと。 最近、勉強会やTwitterで知り合いになって話をする","tags":["スピリチュアル"],"title":"外の世界を知るということ"},{"contents":"「アジャイルデータサイエンス」の見本をいただいてしまいました。\nなので、感想文でも書いてみようかと。\nどんな本？ 想像以上に薄かったです、物理的に。 なのに、とても幅広い範囲をカバーしています。\nデータの分析にどんな人が関わっているのか、アジャイルにデータを分析する目的から始まり、 データから何かを見つけるための手順、考え方などをさらっとですが、 システムに取り込む流れから取り込んだあとに改良するという流れまで紹介してくれます。 流れはこんな感じ。\nイベント：ログとかのイベントの発生 コレクタ：イベントの収集 バルクストレージ：イベントの一時保存 バッチ処理：ストレージにあるデータに対して処理 分散ストア：処理結果をWebアプリなどで表示するために保存 Webアプリ：処理結果をユーザに提供 Webアプリでデータを見えるようにして、そこから更にフィードバックを受けることで、データの分析などを進めていくという流れです。\n私はデータサイエンス系の人ではないのでこの流れで作業をされているかはわからないのですが、 検索のシステムについてもこの流れに似ているなと感じました。\n検索システムでも、検索したいデータを収集して、加工（検索したい項目の洗い出しやファセットにする項目の選定とか）して、 インデックスを生成するといった処理が必要になるからです。\nこの本では、Python、Hadoop（Pig）、MongoDB、ElasticSearch（バージョンが0.90だから）、d3.jsなどが出てきます。 また、日本語版の付録では、Fluentd、Kibana+Elasticsearchといった組み合わせの紹介もあります。\nコードも書かれていますが、すみません、そこまでちゃんと読んでません。。。\n後半では、データを活用して行くためには順序があるという話が書かれています。\nレコード：レコード1件のアトミックな処理と表示 グラフ：レコードを元に集計したりグラフ作ったり レポート：関係性やトレンドを抽出し、インタラクティブに探求 予測：構造を利用して、推論やレコメンドとか 行動：上記の結果を元にユーザに行動を促す 前のステップがおろそかだと次のステップがうまくいかないという話です。 後半はこの流れに沿って、先ほどのシステムの流れを変更していく方法が展開されます。\n注意点 ちょっとだけ気になる点があったので。\nElasticsearch周りについては少し注意が必要かと。（Pigとかは詳しくないので不明です。） 紹介されているElasticsearchのバージョンが0.90と少し古いのと、 Hadoopとの統合（Pigで処理したデータをElasticsearchに出力）に利用されているWondordogというツールも最近更新がされていないみたいです。 おそらく、1.0系では動かないのではないかと。\n1.0系の場合は、Elasticsearchが提供しているelasticsearch-hadoopを利用するのが良いと思います。\n付録については1.0系で記載されているので問題ないかと。ただし、Elasticsearchは更新が早いので、公式サイトで最新情報を入手するのが良いと思います。\n感想 データを解析するシステムってどんなことやってるの？という全体像を 俯瞰するのに良い本なのではないかと思います。 また、データの解析を活かすために、必要な順序と疎かにできない点もあって面白かったです。\n紹介されているツール類については、OSSのトレンドや開発速度が早いので、参考程度にとどめておいて、 自分たちで使いやすいものを探してきて検討するのがいいと思います。\n付録がとても豪華です。FluentdやKibanaがわかりやすく解説されてます。\nあと、薄いのでさらっと読めます。ｗ\n","date":1399563900,"dir":"post/2014/","id":"91fe03f994e8e85cede4e3bd62f4d6b7","lang":"ja","lastmod":1399563900,"permalink":"https://blog.johtani.info/blog/2014/05/09/reading-agile-data-science/","publishdate":"2014-05-09T00:45:00+09:00","summary":"「アジャイルデータサイエンス」の見本をいただいてしまいました。 なので、感想文でも書いてみようかと。 どんな本？ 想像以上に薄かったです、物理的に","tags":["感想文","オライリー"],"title":"アジャイルデータサイエンスが届きました"},{"contents":"こんなツイートを見つけたので、Aggregationのサンプルでも書こうかなと。（前から書こうと思ってたんですが。。。）\n@elasticsearch Hi, Would you please tell me the way to do \u0026quot;Pivot Faceting\u0026quot; like Solr-4.0 in elasticsearch-1.1.1 or prior version? Thank you.\n\u0026mdash; Y.Kentaro (@yoshi_ken) 2014, 5月 2 ちなみに、Aggregationは1.0.0から導入された機能なので、ElasticSearch Server日本語版には掲載されていない機能になります。（ごめんなさい）\n公式ガイドのAggregationsのページはこちらになりますが、実例があったほうがいいかなと。\n@yoshi_ken さんから実例のサンプルの指定もいただいたので、ブログを書くのが非常に楽です。ありがとうございます。\n問題 元ネタ（gist）\n次のような不動産系のデータがあるとします。\nid 物件名 都道府県（東京、神奈川、\u0026hellip;..） 物件種別（賃貸、売買、\u0026hellip;..） この時、都道府県別に、物件種別ごとの件数を取得したいという趣旨です。\n東京 賃貸: xxx件 売買: yyy件 神奈川 賃貸: xxx件 売買: yyy件 \u0026hellip; これを、Elasticsearchでどうやって取得するかという問題です。\nインデックスとデータの登録 まずは、インデックスを作ります。 あくまでもサンプルなので、全部not_analyzedにしてますが、そのへんは適宜変更してください。\n# create index PUT /pref_aggs { \u0026#34;settings\u0026#34;: { \u0026#34;number_of_shards\u0026#34;: 2 }, \u0026#34;mappings\u0026#34;: { \u0026#34;japan\u0026#34; : { \u0026#34;_id\u0026#34; : { \u0026#34;path\u0026#34; : \u0026#34;id\u0026#34; }, \u0026#34;properties\u0026#34;: { \u0026#34;id\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;}, \u0026#34;name\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;}, \u0026#34;pref\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;}, \u0026#34;type\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;} } } } } _idを使用して、データ登録時にidフィールドにある文字列をそのままIDとして登録できるように指定してあります。\n登録するデータは次のようなものを適当に100件程度作ってりました。\n{\u0026#34;id\u0026#34;: \u0026#34;id0\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name0\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;01_北海道\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;売買\u0026#34;} {\u0026#34;id\u0026#34;: \u0026#34;id1\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name1\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;09_栃木県\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;売買\u0026#34;} {\u0026#34;id\u0026#34;: \u0026#34;id2\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name2\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;38_愛媛県\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;賃貸\u0026#34;} {\u0026#34;id\u0026#34;: \u0026#34;id3\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name3\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;40_福岡県\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;賃貸\u0026#34;} {\u0026#34;id\u0026#34;: \u0026#34;id4\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name4\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;35_山口県\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;売買\u0026#34;} {\u0026#34;id\u0026#34;: \u0026#34;id5\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name5\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;12_千葉県\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;賃貸\u0026#34;} ... データの登録には、前に紹介した方法「stream2esと複数データの登録」を用いました。\nファセット このようなデータがある場合に、まず思いつくのはファセットによる取得です。 いささか強引ですが。。。\nGET /pref_aggs/japan/_search { \u0026#34;size\u0026#34;: 0, \u0026#34;query\u0026#34;: { \u0026#34;match_all\u0026#34;: {} }, \u0026#34;facets\u0026#34;: { \u0026#34;type_賃貸\u0026#34;: { \u0026#34;terms\u0026#34;: { \u0026#34;order\u0026#34;: \u0026#34;term\u0026#34;, \u0026#34;field\u0026#34;: \u0026#34;pref\u0026#34;, \u0026#34;size\u0026#34;: 50 }, \u0026#34;facet_filter\u0026#34;: {\u0026#34;term\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;賃貸\u0026#34; }} }, \u0026#34;type_売買\u0026#34;: { \u0026#34;terms\u0026#34;: { \u0026#34;order\u0026#34;: \u0026#34;term\u0026#34;, \u0026#34;field\u0026#34;: \u0026#34;pref\u0026#34;, \u0026#34;size\u0026#34;: 50 }, \u0026#34;facet_filter\u0026#34;: {\u0026#34;term\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;売買\u0026#34; }} } } } facet_filterを使用して、typeフィールドによる個別の絞込を行っています。 あとは、prefフィールドのファセットを取得すれば、出力は次のようになります。\n{ \u0026#34;took\u0026#34;: 6, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 2, \u0026#34;successful\u0026#34;: 2, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 100, \u0026#34;max_score\u0026#34;: 0, \u0026#34;hits\u0026#34;: [] }, \u0026#34;facets\u0026#34;: { \u0026#34;type_賃貸\u0026#34;: { \u0026#34;_type\u0026#34;: \u0026#34;terms\u0026#34;, \u0026#34;missing\u0026#34;: 0, \u0026#34;total\u0026#34;: 52, \u0026#34;other\u0026#34;: 0, \u0026#34;terms\u0026#34;: [ { \u0026#34;term\u0026#34;: \u0026#34;00_北海道\u0026#34;, \u0026#34;count\u0026#34;: 1 }, { \u0026#34;term\u0026#34;: \u0026#34;01_青森県\u0026#34;, \u0026#34;count\u0026#34;: 2 }, { \u0026#34;term\u0026#34;: \u0026#34;03_宮城県\u0026#34;, \u0026#34;count\u0026#34;: 3 }, ... }, \u0026#34;type_売買\u0026#34;: { \u0026#34;_type\u0026#34;: \u0026#34;terms\u0026#34;, \u0026#34;missing\u0026#34;: 0, \u0026#34;total\u0026#34;: 48, \u0026#34;other\u0026#34;: 0, \u0026#34;terms\u0026#34;: [ { \u0026#34;term\u0026#34;: \u0026#34;00_北海道\u0026#34;, \u0026#34;count\u0026#34;: 2 }, { \u0026#34;term\u0026#34;: \u0026#34;02_岩手県\u0026#34;, \u0026#34;count\u0026#34;: 1 }, { \u0026#34;term\u0026#34;: \u0026#34;04_秋田県\u0026#34;, \u0026#34;count\u0026#34;: 1 }, ... } 望んでいた形式とは少し異なりますが、facet_filterする回数を少なくするため、 ファセットは都道府県のフィールドを指定したためです。 アプリで頑張って入れ替えてください。。。\nこの場合、\u0026rsquo;type\u0026rsquo;の個数がわかっているので、頑張ってこのような記述ができました。 ただ、typeが増えた時にアプリの修正とかが必要になりますよね。\nAggregations ということで、Aggregationsの出番です。 ファセットよりも柔軟に、検索結果に対していろいろな集計が行える機能になります。 一見に如かずということで、クエリを紹介します。\nGET /pref_aggs/japan/_search { \u0026#34;size\u0026#34;: 0, \u0026#34;query\u0026#34;: { \u0026#34;match_all\u0026#34;: {} }, \u0026#34;aggs\u0026#34;: { \u0026#34;pref\u0026#34;: { \u0026#34;terms\u0026#34;: { \u0026#34;order\u0026#34;: { \u0026#34;_term\u0026#34;: \u0026#34;asc\u0026#34; }, \u0026#34;field\u0026#34;: \u0026#34;pref\u0026#34;, \u0026#34;size\u0026#34;: 50 }, \u0026#34;aggs\u0026#34;: { \u0026#34;type\u0026#34;: { \u0026#34;terms\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;type\u0026#34;, \u0026#34;size\u0026#34;: 10 } } } } } } ファセットよりもシンプルですし、賃貸といったような値を指定していません。 aggsというのがaggregations機能を指定している部分になります。 検索結果は次のように出力されます。\n{ \u0026#34;took\u0026#34;: 4, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 2, \u0026#34;successful\u0026#34;: 2, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 100, \u0026#34;max_score\u0026#34;: 0, \u0026#34;hits\u0026#34;: [] }, \u0026#34;aggregations\u0026#34;: { \u0026#34;pref\u0026#34;: { \u0026#34;buckets\u0026#34;: [ { \u0026#34;key\u0026#34;: \u0026#34;00_北海道\u0026#34;, \u0026#34;doc_count\u0026#34;: 3, \u0026#34;type\u0026#34;: { \u0026#34;buckets\u0026#34;: [ { \u0026#34;key\u0026#34;: \u0026#34;売買\u0026#34;, \u0026#34;doc_count\u0026#34;: 2 }, { \u0026#34;key\u0026#34;: \u0026#34;賃貸\u0026#34;, \u0026#34;doc_count\u0026#34;: 1 } ] } }, { \u0026#34;key\u0026#34;: \u0026#34;01_青森県\u0026#34;, \u0026#34;doc_count\u0026#34;: 2, \u0026#34;type\u0026#34;: { \u0026#34;buckets\u0026#34;: [ { \u0026#34;key\u0026#34;: \u0026#34;賃貸\u0026#34;, \u0026#34;doc_count\u0026#34;: 2 } ] } }, ... Aggregationsの結果は、望んでいた通りの出力になっています。\nクエリの構成を見てみましょう。\n\u0026#34;aggs\u0026#34;: { \u0026#34;pref\u0026#34;: { #1 \u0026#34;terms\u0026#34;: { \u0026#34;order\u0026#34;: { \u0026#34;_term\u0026#34;: \u0026#34;asc\u0026#34; }, \u0026#34;field\u0026#34;: \u0026#34;pref\u0026#34;, \u0026#34;size\u0026#34;: 50 }, \u0026#34;aggs\u0026#34;: { #2 \u0026#34;type\u0026#34;: { \u0026#34;terms\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;type\u0026#34;, \u0026#34;size\u0026#34;: 10 } } } } } 最初の#1のprefは出力を扱いやすくするためにつけているラベルになります。好きな名前をつけることが可能です。 次のtermsがAggregationのタイプ（どのような集計をして欲しいか）になります。 今回は、prefフィールドにある単語(term)毎に、集計をしたいので、termsを指定します。 その他にどんなタイプがあるかは、公式ガイドをご覧ください。\n次に、さらにtypeフィールドで集計したいので、#2の部分で後続のAggregationを指定しています。 都道府県同様、typeフィールドにある単語毎に集計するために、termsを指定します。\nこれで、先ほどのような結果が出力できます。 ちなみに、さらにtypeの中に他の種別で集計したいという場合は、さらにaggsを追加していけばOKです。\nAggregationは非常に柔軟な集計を可能にする機能です。ただし、検索結果に対して集計処理を行っているため、 メモリやCPUなどのリソースを消費するので注意が必要です。\nAggregationの説明については、こちらのFound.noのブログ（英語）がわかりやすかったので参考にしてみてください。\nまとめ 非常に簡単ですが、Aggregationsについて紹介しました。 その他にもAggregationsでできることがあるので、後日別のサンプルを用意して説明しようかと思います。\n100件のデータやここまでの操作については、gistにあるので、興味がある方はご覧いただければと。 stream2esの操作以外は、Marvelに付属のsenseを利用しています。\n","date":1399456620,"dir":"post/2014/","id":"ed4f5a398056eef1cf6caa90786b340a","lang":"ja","lastmod":1399456620,"permalink":"https://blog.johtani.info/blog/2014/05/07/aggregation-example/","publishdate":"2014-05-07T18:57:00+09:00","summary":"こんなツイートを見つけたので、Aggregationのサンプルでも書こうかなと。（前から書こうと思ってたんですが。。。） @elasticsearch Hi, Would you please tell me the way to","tags":["elasticsearch"],"title":"Aggregations - ファセットよりも柔軟な集計"},{"contents":"今日はelasticsearch-kopfのAnalysis画面の紹介です。\n（簡単なところから。。。その３）\nちょっとあいだが開いてしまいましたが、再開です。 メニューのaliasesを選択すると、次のような画面が表示されます。\nAliases画面 Elasticsearchのaliasを画面で確認できます。\nエイリアスは、インデックスに別名をつけることができるElasticsearchの機能です。 １エイリアス＝１インデックスでも良いですが、１エイリアスに対して複数のエイリアスを付与することもできます。 この機能を利用することで、次のようなことが可能となります。\nインデックスの切り替えをアプリ側に意識させずに実施（アプリはエイリアス名に対して検索すればOKなので） 直近１週間のログを検索するためのエイリアスの作成（複数のインデックスを１つのエイリアスに割り当て可能） 特定のルーティングによる検索（特定のデータに対する検索だけに絞るためにfilterを指定する） エイリアスについて詳しく知りたい方は公式ガイドをご覧いただくのが良いかと。\n画面は非常にわかりやすい作りになっているので、特に説明必要ないんですよね。。。\n","date":1399132860,"dir":"post/2014/","id":"2824bef72110575c78aeb979170212b8","lang":"ja","lastmod":1399132860,"permalink":"https://blog.johtani.info/blog/2014/05/04/intro-elasticsearch-kopf-alias-percolator/","publishdate":"2014-05-04T01:01:00+09:00","summary":"今日はelasticsearch-kopfのAnalysis画面の紹介です。 （簡単なところから。。。その３） ちょっとあいだが開いてしまいまし","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（aliases画面）"},{"contents":"kopfの記事の続きも書く必要があるんだけど、こんなツイートを見つけてしまったので。。。\nElasticsearchのBulk APIの仕様、JSONファイルをいい感じに加工して置かなければならないしハマりどころ多い。 http://t.co/hmfycqZlqk\n\u0026mdash; Kenta Suzuki (@suzu_v) 2014, 4月 24 前に思いついたけど、放ったらかしにしてた疑問が再浮上してきたので、せっかくだから調べてみようかなと。\n複数JSONデータがある場合にもっと楽にデータを入れる方法ないかなぁと思って、これかな？というのがあったのですが、 そのまま手を動かさずに放置してたので、一念発起してブログ書いてます。\nBulk APIって？ ElasticsearchはURLにアクセスしてデータを登録できます。 基本的には次のように1件毎の登録になります。\n$ curl -XPUT http://localhost:9200/bookshop/books/1 -d \u0026#39; { \u0026#34;book_id\u0026#34; : 1, \u0026#34;title\u0026#34; : \u0026#34;ElasticSearch Server Japanese Edition\u0026#34;, \u0026#34;price\u0026#34; : 3024, \u0026#34;publisher\u0026#34; : \u0026#34;KADOKAWA\u0026#34; }\u0026#39; これでもいいのですが、大量のデータを登録するときは、Elasticsearch側での効率が悪いです。 そこで、Elasticsearchは大量データを登録するためにBulk APIというものを用意しています。\nこれは、次のような形式のJSONを作ってデータを登録します。\n{ \u0026#34;index\u0026#34; : { \u0026#34;_index\u0026#34; : \u0026#34;bookshop\u0026#34;, \u0026#34;_type\u0026#34; : \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34; : \u0026#34;1\u0026#34; } } { \u0026#34;book_id\u0026#34; : 1, \u0026#34;title\u0026#34; : \u0026#34;ElasticSearch Server Japanese Edition\u0026#34;, \u0026#34;price\u0026#34; : 3024, \u0026#34;publisher\u0026#34; : \u0026#34;KADOKAWA\u0026#34;} { \u0026#34;index\u0026#34; : { \u0026#34;_index\u0026#34; : \u0026#34;bookshop\u0026#34;, \u0026#34;_type\u0026#34; : \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34; : \u0026#34;2\u0026#34; } } { \u0026#34;book_id\u0026#34; : 2, \u0026#34;title\u0026#34; : \u0026#34;Introduction of Apache Solr\u0026#34;, \u0026#34;price\u0026#34; : 3888, \u0026#34;publisher\u0026#34; : \u0026#34;gihyo\u0026#34;} これは、次のような構成になっています。\nコマンド データ コマンド データ ... これで効率よくデータが登録できるのですが、このようなJSONデータを別途作って上げる必要が出てきます。 結局、複数のJSONがあるのに、特殊なJSONを生成しないといけないということでプログラム書いて実行することになります。 これだと、Elasticsearchへのアクセスをプログラムで書くのとあまり大差がないかもしれません。\nstream2es もっとお手軽に複数のJSONを登録できないかな？と目をつけていたのが、stream2esです。\nどんなもの？ Clojureで作られた、Elasticsearchにデータを流し込むためのツールです。 Java 7がインストールされていれば、ダウンロードしてくれば動作せることができます。\nインストール 公式ページに載っている方法そのままです。\n$ curl -O download.elasticsearch.org/stream2es/stream2es; chmod +x stream2es 実行したディレクトリにコマンドがコピーされます。 あとは、コマンドを実行すればOKです。\n実行 データは次のような形式でsample.jsonに保存してあるとします。\n{ \u0026#34;book_id\u0026#34; : 1, \u0026#34;title\u0026#34; : \u0026#34;ElasticSearch Server Japanese Edition\u0026#34;, \u0026#34;price\u0026#34; : 3024, \u0026#34;publisher\u0026#34; : \u0026#34;KADOKAWA\u0026#34;} { \u0026#34;book_id\u0026#34; : 2, \u0026#34;title\u0026#34; : \u0026#34;Introduction of Apache Solr\u0026#34;, \u0026#34;price\u0026#34; : 3888, \u0026#34;publisher\u0026#34; : \u0026#34;gihyo\u0026#34;} 先ほどのBulk APIで利用したJSONよりも、スッキリしていますね。 1行1ドキュメント1JSONです。\nあとは、次のコマンドを実行するだけです。\n$ ./stream2es stdin --target http://localhost:9200/bookshop/books \u0026lt; sample.json ファイルをstream2esに流し込んで、stream2esが1行ずつパースして、Elasticsearchに投げ込んでくれます。\n登録されたデータは次のようになります。 IDは自動で付与されています。\n{ \u0026#34;_index\u0026#34;: \u0026#34;bookstore\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;0Hvy4IJCRkKrvGb4Dgam_w\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;book_id\u0026#34;: 1, \u0026#34;title\u0026#34;: \u0026#34;ElasticSearch Server Japanese Edition\u0026#34;, \u0026#34;price\u0026#34;: 3024, \u0026#34;publisher\u0026#34;: \u0026#34;KADOKAWA\u0026#34; } }, { \u0026#34;_index\u0026#34;: \u0026#34;bookstore\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;b9M6TooFQzGYyJeix_t_WA\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;book_id\u0026#34;: 2, \u0026#34;title\u0026#34;: \u0026#34;Introduction of Apache Solr\u0026#34;, \u0026#34;price\u0026#34;: 3888, \u0026#34;publisher\u0026#34;: \u0026#34;gihyo\u0026#34; } } せっかく、book_idがあるんだし、_idをインデックスの設定に指定します。\n$ curl -XDELETE http://localhost:9200/bookshop $ curl -XPUT http://localhost:9200/bookshop -d \u0026#39; { \u0026#34;mappings\u0026#34;: { \u0026#34;books\u0026#34; : { \u0026#34;_id\u0026#34; : { \u0026#34;path\u0026#34;: \u0026#34;book_id\u0026#34; } } } }\u0026#39; あとは、登録すればbook_idが_idに採用されます。\n{ \u0026#34;_index\u0026#34;: \u0026#34;bookshop\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;book_id\u0026#34;: 1, \u0026#34;title\u0026#34;: \u0026#34;ElasticSearch Server Japanese Edition\u0026#34;, \u0026#34;price\u0026#34;: 3024, \u0026#34;publisher\u0026#34;: \u0026#34;KADOKAWA\u0026#34; } }, { \u0026#34;_index\u0026#34;: \u0026#34;bookshop\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;book_id\u0026#34;: 2, \u0026#34;title\u0026#34;: \u0026#34;Introduction of Apache Solr\u0026#34;, \u0026#34;price\u0026#34;: 3888, \u0026#34;publisher\u0026#34;: \u0026#34;gihyo\u0026#34; } } 複数ファイル ディレクトリに複数のJSONファイルが有った場合は、次のようなコマンドでOK\n$ cat sample_data/*.json |./stream2es stdin --target http://localhost:9200/bookshop/books まぁ、catして流してるだけですが。。。\nダメだったケース JSONが複数行になっているようなデータだとエラーが出てしまいました。\n（jqコマンドで1行に整形したりできるかなぁ？）\nまた、1行に2つのJSONが書いてある場合は、1つ目のJSONをパースしたら、そこでおしまいみたいで、その後に記述されたデータは登録されませんでした。\nインデックスがない場合 stream2esで登録するインデックスがElasticsearchに存在しない場合、stream2esがインデックスを作成してくれるのですが、 この時、シャード数などはstream2es内部に記述があるので注意が必要です。 以下がその設定です。\nindex.number_of_shards : 2 index.number_of_replicas : 0 index.refresh_interval : 5s 課題？ 内部的にはおそらく、Bulkでデータを登録していると思うのですが、まだよくわかっていません。 Clojureが読めないので、せっかくだから、Clojureの勉強も兼ねてちょっとソースを読んでみようかなと思います。 それほど量があるわけでもないので。\nあとは、その他にWikipediaのデータやTwitterのデータ登録、 ElasticsearchからデータをScrollで読み出しつつ、別のElasticsearchに流しこむといったこともできそうなので、そちらも試してみようかと。 他にもオプションがいくつかありそうです。\n今回は2件ほどでしたが、大量データを流し込んだ時にどうなるか（stream2esが悲鳴を上げるのか、Elasticsearchで詰まることがあったらどうなるか）なども 気になるので、なんか適当なデータで試してみるのもいいかなぁと。 （ということで、だれか、いろいろ試してみてもらえると楽できるなぁ。）\n","date":1398341460,"dir":"post/2014/","id":"e396cbf9274b590a1d94ee43d823a0bd","lang":"ja","lastmod":1398341460,"permalink":"https://blog.johtani.info/blog/2014/04/24/usage-stream2es/","publishdate":"2014-04-24T21:11:00+09:00","summary":"kopfの記事の続きも書く必要があるんだけど、こんなツイートを見つけてしまったので。。。 ElasticsearchのBulk APIの仕様、J","tags":["elasticsearch","stream2es"],"title":"stream2esと複数データの登録"},{"contents":"第4回Elsticsearch勉強会を開催しました。 今回から、遅刻厳禁にしてみました。 それほど困った人もいないと思うので、次回からも遅刻厳禁で。\nということで、今回も多数の方にお集まりいただきありがとうございました。\nスタッフの皆さん、スピーカーの皆さん、プレゼント用に書籍を用意してくれたKADOKAWAさん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！ 参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\nさて、ブログですが司会業とかやってたので、あんまり書けてないけど。。。\n134番までチケットがはけていたので＋スタッフで140〜150名くらいの参加者だったのではないかと思います。 懇親会まで残っていただいた方々も片付けなどありがとうございました。\nさて、感想とか補足です。\n「アナライズ処理の仕組みとクエリDSL」株式会社シーマーク　大谷　純　@johtani スライド：アナライズ処理の仕組みとクエリDSL※スライドはPDFです。\nプラグイン：elasticsearch-extended-analyze\nプラグインの紹介記事：http://blog.johtani.info/blog/2013/10/25/developing-es-extended-analyze-plugin/\nMarvel：http://www.elasticsearch.com/marvel/\n日本語版メーリングリスト：https://groups.google.com/forum/#!forum/elasticsearch-jp\nなんか、宣伝（本＋プラグイン）ばっかりですみません。 「プラグインの紹介記事」に簡単な使い方が書いてあります。が、情報が古いので、Elasticsearchのバージョンに合わせたバージョンを使ってください。\nまだまだ発表に慣れてないので、頑張ろ。\nアンケート取ってみましたが、ログ検索と全文検索と半々くらいで興味がある人がいるみたいでした。 あと、有料トレーニングは人気ないっすね。。。\n「elasticsearch-hadoopを使ってごにょごにょしてみる」 株式会社マーズフラッグ R\u0026amp;D部　やまかつ さん　@yamakatu スライド：elasticsearch-hadoopを使ってごにょごにょしてみる\nelasticsearch-hadoop：https://github.com/elasticsearch/elasticsearch-hadoop\nQAとして、Elasticsearchにプライマリデータを保存するのは的な話が出てました。 ESにのみデータを入れるのは個人的には考えたことないかなぁ。 どうしても、ElasticsearchのWriteが遅いんじゃないかという懸念事項を持ってる人がいるなぁと。（実際ツラいという話もちらほら）\nお腹痛い中の発表ありがとうございました。。。 次回はMapRの方に紹介してもらえそう（交渉中）なので楽しみです。やまかつさんの続きも聞きたいなぁ。\n「CouchbaseとElasticsearchが手を結んだら」株式会社アットウェア 佐竹雅央さん @madgaoh 河村康爾さん @ijokarumawak スライド：CouchbaseとElasticsearchが手を結んだら\nCouchbaseのElasticsearchに関するページ：http://docs.couchbase.com/couchbase-elastic-search/\nCouchbaseに入れたら、自動的にElasticsearchにもデータを入れてくれる。 デモがあるの、いいっすね。\n最新版はmasterを落としてきてビルドしないとダメらしい。確かに、上のページには0.90.5って書かれてる。 ここでも、やはり、Elasticsearchが詰まった時にどうするの？みたいな話が出てました。 CouchbaseのXDCRだと、後ろが詰まってる時によしなに？データを流すのを制御してくれるってのがあるみたいですが、 Elasticsearchだと悲鳴を上げているのがわかりにくいと。\nあと、Elasticsearchがインデキシングでキューを取りこぼしているのがログからわかりにくいってのも出てました。 （なにか、分かる方法があるかとかも調べてみようかなぁ。）\n自分の宿題：Transportプラグインって何かについて調べてブログに書くこと。\n「Elasticsearch at Wantedly」（タイトルあってるか不安）　Wantedly, Inc 内田誠悟さん @spesnova スライド：Elasticsearch at Wantedly\n参考文献：Elasticsearchチュートリアル\n参考文献：Elasticsearch Workshop\n参考文献：elasticsearch-rails\nWantedlyでどうやって使ってるのか。 あと、オートコンプリートでも使ってます。（この話は次回聞けるといいなぁｗ）\nデータ数は少ないので、参考にまだならないかも。\n公式のサイト見難いですよねと。 ペンギン先生のブログが素晴らしかった！ マッピングすごいｗ\n最後は、苦労して作ってもらったautocompleteの資料は放ったらかしにして、質疑応答してもらいました。 辞書とか、検索漏れとかの話は今後の課題っぽかったですね。\n「Elasticsearchのみに決めてました！」ってセリフがカッコ良かったｗ\nアクセスコントロール周りのノウハウもブログで共有してくれそうなので楽しみにしています！\nあと、「tireがretire」の話が出てましたが（この発表だっけ？）参考文献にあげてある、elasticsearch-railsが今は本流なんじゃないかなぁ？\nLT ###「ElasticsearchのScripting」株式会社富士通ソフトウェアテクノロジーズ 滝田聖己さん @pisatoshi\nスライド：ElasticsearchのScripting\n参考文献：elasticsearch-native-script-example\n色々とScriptがあるという話を説明してもらい感謝です。 もちろん、ElasticSearchServerにも書いてあるので、そちらも参考にしてください！\n「Elasticsearch 向け多言語解析プラグイン」ベイシス・テクノロジー株式会社 江口天さん スライド：Elasticsearch 向け多言語解析プラグイン\n参考文献：Elasticsearchで使えるRosette基本言語解析モジュール\n参考文献：Elasticsearch-inquisitorプラグインの紹介\nベイシステクノロジさんが提供しているRosetteをElasticsearchで活用できるモジュールみたいです。 いまなら、無料で体験できるみたいなので、どんなものか触ってみると面白いかもしれません。\nあと、デモで使用されていたプラグインについて、私が昔に書いた記事があるので、興味のある方は参考にしていただければと。 このプラグインはクエリがどのように内部でLuceneのクエリになっているか、どのフィールドでどうトークンが生成されるか？ といったものが見ることができるプラグインになっています。\n関連ブログ 適当に見つけたブログを列挙してあります。これもあるよ！などあれば、教えてください。\n勉強会メモ - 第4回elasticsearch勉強会 2014/04/21\ntogetter 第4回elasticsearch勉強会 #elasticsearchjp\n参加レポート:第4回elasticsearch勉強会 #elasticsearchjp\n第4回elasticsearch勉強会に参加しました\nまとめ しつこいくらい宣伝してしまいましたが、「ElasticSearch Server日本語版」よろしくお願いします！\n今回も楽しい話が聞けました。メモがちょっと少ないんですが。。。\n次回は6末を目処に、MapRの方などと調整して開催しようと思います。 聞きたい話とか、発表したい方とかあれば、連絡くださいー！\n","date":1398077040,"dir":"post/2014/","id":"50562b09417cd8c4a2348a0a5aabe754","lang":"ja","lastmod":1398077040,"permalink":"https://blog.johtani.info/blog/2014/04/21/hold-on-4th-elasticsearch-jp/","publishdate":"2014-04-21T19:44:00+09:00","summary":"第4回Elsticsearch勉強会を開催しました。 今回から、遅刻厳禁にしてみました。 それほど困った人もいないと思うので、次回からも遅刻厳禁","tags":["elasticsearch","勉強会"],"title":"第4回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"今日はelasticsearch-kopfのAnalysis画面の紹介です。\n（簡単なところから。。。その２）\nメニューのanalysisを選択すると、次のような画面が表示されます。\nAnalysis画面 Elasticsearchの_analyze APIを画面で確認できます。 画面で動作の確認ができるのは嬉しいですよね。\n入力文字列：入力となるドキュメントに含まれる文字列や検索キーワードを入力 フィールドの指定：対象とするインデックス名、タイプ名、フィールド名を選択 analyze：ボタンを押す トークナイズされた結果：入力文字列がどのようなトークンに分割されるか start、end：入力文字列中の文字列の位置 pos：トークンの位置 という形でElasticsearchが指定されたフィールドで入力文字をどのようにトークナイズしたかを確認することができます。\nElasticsearchは内部でこのトークナイズされた単語を元に転置インデックスを作成し、検索に利用します。 ですので、特定のデータが検索に上手くヒットしないときに、この画面でデータの文字列をトークナイズしてみるといった用途に使えます。\nフィールドの設定がどのようにして入力文字列をトークンにしているかといった点については、今度のElasticsearch勉強会で話す予定です。\nフィールドの設定を利用する以外に、アナライザを指定してどのようにトークナイズされるかを見ることもできます。 「ANALYZE BYANALYZER」をクリックすると利用できます。\nANALYZE BY ANALYZER トークナイズしたい文字列を入力し、インデックス名と、インデックスに設定されているアナライザ名を選択してanalyzeボタンを押すと 結果が表示されます。 （例では、kuromojiアナライザを利用して出力になっています。また、出力結果のposの表示位置がFIELD TYPEの時と違うのが少し気になりました。）\nただ、残念ながら、インデックスのマッピングで指定したアナライザしか利用できないみたいなので、 どのアナライザがどんな挙動かを調べたい場合は、以前紹介したelasticsearch-inquisitorを 利用したほうが良さそうです。\nということで、今日はanalysis画面の説明でした。\n","date":1397011260,"dir":"post/2014/","id":"76a1fb7f21fda9eddb95426b65124517","lang":"ja","lastmod":1397011260,"permalink":"https://blog.johtani.info/blog/2014/04/09/intro-elasticsearch-kopf-analysis/","publishdate":"2014-04-09T11:41:00+09:00","summary":"今日はelasticsearch-kopfのAnalysis画面の紹介です。 （簡単なところから。。。その２） メニューのanalysisを選択","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（analysis画面）"},{"contents":"JVM Operation Casual Talksに参加しました。 あんまり、運用とかやってないので、ついていけるか不安ですが、楽しそうだったので。 懇親会は予定されてないらしい。\n@stanaka\t15分でわかるJVMのメモリ管理 スライド：https://speakerdeck.com/stanaka/understanding-memory-management-of-javavm-in-15-minutes\nJVMの基礎知識\n某研究所で。。。\nElasticsearch、Solrの名前が！\nJVM困りどころ。ネットの情報が古いのが多いとか。\n使いこなすにはきちんと知識が必要。\nMemory Model 困ったらJava8に。。。\nHeapのチューニングが重要\nHeapの構成やGC処理の説明\nCMSでもすべて並列ではない\nOlgGenがフラグメントして確保が遅くなっていく G1GCの概念図。YoungやOld、Survivorの区別がない？\nリージョン？ リファレンスリストすばらしい。\n@oranie\tCassandra運用で実施しているJVM監視について スライド：http://www.slideshare.net/oranie/jvm-operation-casual-talks-33218856\nCassandra(1.1)で運用中。 35TBとか エンジニアブログ読め。 Cassandraの監視って何すればいいの？ GC頻度とかグラフで見れる VisualVM便利って教えてもらった。 VisualVMでどんな値があるか見ながら調べて、取りたい値を考える。 SNMPで頑張るの辛い＝JMXかな？＝Javaで叩くの？＝Jolokia どんなことやってる？ Nagios+Jenkins＋。。。あとでスライド yohoushi+GrowthForecastも便利。 @waysaku\tSpray(Akka)運用でJVMをCPUスケールさせるために行った事 スライド：http://www.slideshare.net/waysaku/jvm-operation-casual-talks\nSpray Akkaアプリケーションの運用を任されちゃった人 カットオーバー直前の負荷試験でびっくりするくらいスループットでない。。。 いろんなActorが特定のActorに処理を投げた状態で待ってるという状況。。。 スレッドダンプ追っかけてる様子を追体験してる。 ログ出力がBLOCKしてた I/Oを伴う処理は非常にセンシティブ 以下、LT @oinume\t運用に効く！JVMオプション三選 スライド：http://www.slideshare.net/oinume/jvm-operationcasualtalks20140407\nサーバに入らなくても見れるのは VisualVM 最終形Java Mission Control Flight Recorder（商用だと有償） @y_uuki1\tなにもわからないところから始めるJVMモニタリング スライド：https://speakerdeck.com/yuukit/nanimowakaranaitokorokarashi-merujvmmonitaringu\nブログ：http://yuuki.hatenablog.com/entry/2014/04/08/074507\nなんでここにいるかわかりませんが。 色んな所記事とかのリンクがある。 Graphiteに放り込んでるらしい。 @tagomoris\tNorikraのJVMチューンで苦労している話 スライド：http://www.slideshare.net/tagomoris/norikrajvm\nNorikraで困ったので開催したらみんなしゃべりに来てくれてありがたい世の中ですね。 デフォルト設定で運用。mx4096mで4ヶ月は元気に動いてた 年末に崩壊 -\u0026gt; harukaさんのQiita見ながら設定してほったからした。 3月にまた崩壊OOM SoftRefが悪さしてるのか？ nekopさんのブログにヒントが。 @shot6\tJVM的なナニカを話す、GC戦略をそえて スライド：http://www.slideshare.net/shot6/jvm-33248312\n某A社からきました。 CMSを中心が良い CPUコア少ないとCMS Incremental G1GCは6GB以上とかもっと大きい場合のほうが良さそう（雑感） 基本的に、ドキュメントに書いてあるけど、つらいので、まとめてみました。 後で見たいな、このスライドも。 @kazeburo\tWebアプリケーションとメモリ スライド：http://www.slideshare.net/kazeburo/jvm-casual\nJavaは1行も書いたことありません。 Java運用したけど、まぁ、ひどい目にあってます。 ということで、PerlとApacheの話？ bumpyなんとかってのは頭良くプロセスの処理回数とかをなんとかしてくれる JVMとかどうなの？ ということで、CA社の人が釣れたので良かったですね。 TBD\tJVMの運用について話す会(パネル) なんでJVM？\n全文検索だとJVMだなぁ。SolrとかElasticsearchとか 入社したらあった。 JVMこまったところは？\n突然Dioが出てくる JVMいいところは？\nうーん、あえて言うと。。。スレッド処理 型がある言語を調べるとJVM。というよりScala。 飛び入り参加。落ちないところ。人殺しは良くないｗ 簡単には殺せないところに使えるのは良いのでは。 チューンはどこまでやる？\n7,8割でやめたほうが良い？ そんなに突き詰めなくてもいいのかな。 Cassandraだと、FullGCが走ってる時点で再起動しかない場合が多いです。 言語のランタイムについてチューンすることってJVMの他ある？\nRubyくらい？ 自分たちで何とかできないものを相手にしている人たちは苦労してるんじゃないか\nCaなんとかさんとかHBなんとかさんは困ってる人が多い 最後に一言\nモニタリングツール参考にしたい 最後に 「やりたくなったら誰かやってください。」ということみたいです。\n基礎から監視まで結構幅広くキーワードが出てきたので楽しかったです。\nその他に話に出てきてた方のブログもリンクしとこうかな。\nnekopの日記\n","date":1396866240,"dir":"post/2014/","id":"299abcee56b05b312ed5700f686f79b8","lang":"ja","lastmod":1396866240,"permalink":"https://blog.johtani.info/blog/2014/04/07/attend-jvm-casual-1/","publishdate":"2014-04-07T19:24:00+09:00","summary":"JVM Operation Casual Talksに参加しました。 あんまり、運用とかやってないので、ついていけるか不安ですが、楽しそうだったので。 懇親会は予定されてないらしい","tags":["JVM","Java","勉強会"],"title":"JVM Operation Casual Talksに参加しました #jvmcasual"},{"contents":"今日はelasticsearch-kopfのREST画面の紹介です。\n（簡単なところから。。。）\nメニューのrestを選択すると、次のような画面が表示されます。\nElasticsearch自体が、さまざまな操作をRESTでできる仕組みになっています。 検索にも利用しますが、それ以外の設定などにつてもリクエストを送ればOKです。\nですので、リクエストや設定を自分で組み立てて送ることができる画面が用意されているととても便利です。 （もちろん、curlコマンドでもいいのですが、画面があると便利ですよね）\nREST画面 History 履歴表示画面です。 これまで、kopfのrest画面を利用して送信したリクエストが一覧で表示されます。\nHistoryという文字をクリックすることで、表示/非表示の切り替えが可能です。（最初は非表示） マウスオーバーすると、リクエストボディがポップアップで表示されます。\nHistory 履歴にあるURLはクリック可能で、クリックすると実行されます。 履歴はlocalStorageに保存されるみたいです。（ブラウザの仕様？あんまり詳しくないので。。。） たぶん、30件が上限かと（ソースで確認しただけ）\nURL rest画面でリクエストを送信する先のURLを指定します。 メソッドは右側のSELECTで選択可能です。\nリクエストパラメータも指定が可能です。\nリクエストボディ 検索や設定のJSONを記述するところです。 一応、JSON的にエラーがある場合は行数の左側にバツ印が出てきておかしなところもわかるようになっています。\nインデントなどは行ってくれますが、senseみたいな補完などはないので、少し辛いところです。\nレスポンス 送信したリクエストに対するレスポンスが返ってきます。 インデントされた状態で表示されるので読みやすいかと。 また、入れ子になっているJSONについては、閉じたり開いたりすることも可能です。 （開始のカッコの右側に-が表示されていて、クリックすると閉じることができます。閉じると+に変わります）\n簡単ですが、rest画面の説明でした。 KOPFを使っていて、ちょっとしたクエリを送ったりするのには便利だと思います。\n複雑な検索クエリなどについては、やはりsenseを使うのが良いかと思いますが。。。\n","date":1396837440,"dir":"post/2014/","id":"670744b945088de05866864f7d57bee7","lang":"ja","lastmod":1396837440,"permalink":"https://blog.johtani.info/blog/2014/04/07/intro-elasticsearch-kopf-rest/","publishdate":"2014-04-07T11:24:00+09:00","summary":"今日はelasticsearch-kopfのREST画面の紹介です。 （簡単なところから。。。） メニューのrestを選択すると、次のような画面","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（rest画面）"},{"contents":"なんだか、ドタバタしてて久しぶりの更新です。 ベルリンの旅行記みたいなのも書きたいのですが、まずはこちらかと。\nelasticsearch-kopfプラグインの紹介です。\n今回は概要の説明だけになります。機能が結構多いので。\nelasticsearch-kopfとは？ _siteプラグインの一つで、クラスタ管理用のプラグインになります。 headプラグインやHQプラグインと同様です。\nプラグインの画面 このようにシンプルな画面で、スッキリとしています。 緑を基調にした画面構成はElasticsearchの緑色を意識してるんでしょうか？\n上記の画像に簡単なコメントを入れてあります。\nメニュー KOPF：KOPF自体の設定（接続先とリフレッシュインターバルの変更） cluster：クラスタ管理、情報（デフォルト表示画面） rest：RESTリクエスト送信、結果表示画面 aliases：エイリアス管理 analysis：analysis API percolator：パーコレータ管理 warmup：ウォームアップクエリ管理 上記のようなメニューです。各メニューについては、今後のブログで少しずつ紹介しようかと。 このメニューの色が、クラスタの状態も表しています。ステータスがYELLOWなら黄色、REDなら赤色に変わります。\nインデックス インデックスは列として表示されます。先ほどの画像では、2つのインデックスが表示されている状態です。 インデックス毎に、シャードも表示されます。これは、各ノードがどのシャードを保持しているかという情報です。 色の濃いシャードがプライマリでしょう。 インデックス名やシャードの箱はクリックできるようになっていて、それぞれの情報がJSONで表示されます。 その他にもドキュメント数、サイズなども表示されます。 インデックスの各種操作（closeやdeleteなど）もここからメニューが表示されます。（これも次回詳しく）\nノード ノードの情報が行として表示されます。ノードが増えると下に追加されていきます。 node1というのが、ノード名です。（ヒーローの名前とかが出てくるやつです。）\nその他に、IPアドレス、ポート番号、負荷、ヒープサイズなども表示されています。 電源ボタンはノードのシャットダウンを行うためのボタンです。（確認用のダイアログが表示される）\nその他 その他に、クラスタの概要として、ノード数、インデックス数、シャード数、ドキュメント数なども表示されます。 インデックスの作成などは、アイコンから操作が可能です。 大規模なクラスタを管理している場合、検索ボックスを利用することで、インデックス名やノード名による絞込もできるようになっています。\n感想 シンプルな構成の画面で、個人的にはheadよりも好きな画面です。 HQよりもシャードの分散具合がわかりやすいので、今後はこのプラグインを利用していこうと考えています。\nまずは、簡単な紹介です。今後、各画面についてもう少し説明をブログに書いていこうかと考えています。 待てない方は、触ってみてもらうのが良いかと。 もちろん、続きを書いてもらってもいいですよ！！\n","date":1396707480,"dir":"post/2014/","id":"c1241374502f200cf9fc49c8d6fb5822","lang":"ja","lastmod":1396707480,"permalink":"https://blog.johtani.info/blog/2014/04/05/intro-elasticsearch-kopf-1/","publishdate":"2014-04-05T23:18:00+09:00","summary":"なんだか、ドタバタしてて久しぶりの更新です。 ベルリンの旅行記みたいなのも書きたいのですが、まずはこちらかと。 elasticsearch-ko","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（概要）"},{"contents":"先日、「ElasticSearch Serverを翻訳しました」という記事を書きました。\nこの中で電子版も出ますよと書いていましたが、電子版も発売されたので、再告知も兼ねてブログを書いています。\nなお、最近よく「ElasticsearchのSは小文字」とツイートしていますが、本書は原著のタイトルが「ElasticSearch Server」となっているため、Sは大文字になっています。原著が出版された時期にはまだSが小文字に統一されていなかったためです。\n紙の書籍はすでに書店に並んでいたり、Amazonでも発送されているようです。\n私自身が電子書籍が場所を取らなくて好きというのもあり、電子版も出版していただけるようにお願いしていました。\n電子版についてはAmazonでKindle版、達人出版会からEPUBとPDFが購入可能です。\n達人出版会のElasitcSearch Serverのページ AmazonのKindle版ページ こちらのリンク（Amazonはアフィリンク）を参考にしていただければと。\n書籍の写真入りツイートしたら、原著者の方からレスを頂きました。\n@johtani Thanks for the great work out there :)\n\u0026mdash; Rafał Kuć (@kucrafal) 2014, 3月 23 また、原著者のサイトでも紹介してもらいました（結構うれしい）。 私が窓口をやっていた関係で、私の名前しか入っていませんが。。。 編集者と翻訳者の方々のお陰で良い本が出版できたと思っています。\nThanks for sharing! / ElasticSearch Server book in Japanese | ElasticSearch Server Book Blog http://t.co/fhCP1vVBd3\n\u0026mdash; Jun Ohtani (@johtani) 2014, 3月 24 ということで、Elasticsearchの導入の手助けになればと。 感想（賛否問わず）など、あればコメント、ツイート、ブログなど書いていただければうれしいです。 （その際に、連絡してもらえるとさらにうれしいです）\n","date":1395722580,"dir":"post/2014/","id":"d51032bef3e7117a94336fea18a3fad7","lang":"ja","lastmod":1395722580,"permalink":"https://blog.johtani.info/blog/2014/03/25/release-elasticsearch-server-ja-ebook/","publishdate":"2014-03-25T13:43:00+09:00","summary":"先日、「ElasticSearch Serverを翻訳しました」という記事を書きました。 この中で電子版も出ますよと書いていましたが、電子版も発","tags":["elasticsearch"],"title":"ElasticSearch Server日本語版（電子版も）が発売されました"},{"contents":"GOTO Night elasticsearchに参加しました。 初の海外の勉強会です（海外自体が初だし）。\nベルリンにあるWoogaという会社で開催された勉強会です。\nFull house at the #gotonight about @elasticsearch in the auditorium of @wooga pic.twitter.com/r2Vx2aMcEn\n\u0026mdash; GOTO Berlin (@GOTOber) 2014, 3月 18 会場はこんな感じで、とってもおしゃれです。（なんか、写ってますね、最前列にｗ） ベルリンの古い建物をリノベーションしたオフィスみたいで、そこにこういったひな壇を用意して発表するスペースにしているみたいです。\n内容としては、Elasticsearch1.0の新機能の話として、snapshot/restore、cat、aggregationなどの話題でした。簡単にどういったものかの説明です。\n一人目の発表が終わったら、ブレイクタイムとして上のフロアに用意されている軽食＋ドリンクで軽く交流の時間が用意されていました。 ベーグルなどのサンドイッチとハイネケンやクラブマテ？と呼ばれるチープなレッドブルとかが飲めました。\nちょっと食べて談笑したあとに、次はLogstashとKibanaのお話でした。Logstashってどんなもの？という話がメインで、Kibanaは簡単な紹介という感じでしょうか。最後に、ライブデモがありました。 Kibanaを使ったライブデモはインパクトがあるなというのが感想です。 フィールド名の補完をしてくれたりと便利な機能が操作をしているところでわかるので。\nYoutubeなどでも見てても思っていた感想ですが、こちらの勉強会は質問が結構出てきます。 今日参加した勉強会も質疑応答が結構されてました。\nelasticsearchの方たちと少しだけ話しをできたので、かなり興奮気味でブログを書いています（ミーハー）。\nただ、やっぱり英語のヒアリングがまだまだだなぁとも実感出来ました。 場数踏むしかないと思うので少しずつ耳にしてなれるしかないかなぁと。 はぁ、ちゃんと高校とか大学の頃に単語を覚えとくんだったと軽く後悔。\nこんなツイートもしてもらって、興奮気味です。明日早起きしないといけないので寝ないといけないのにｗ\nMeeting @johtani finally in #berlin watching @spinscale talking about #elasticsearch\n\u0026mdash; Simon Willnauer (@s1m0nw) 2014, 3月 18 ","date":1395151860,"dir":"post/2014/","id":"65453a1ae403679bd2e47398a04205ca","lang":"ja","lastmod":1395151860,"permalink":"https://blog.johtani.info/blog/2014/03/18/attend-goto-night-elasticsearch/","publishdate":"2014-03-18T23:11:00+09:00","summary":"GOTO Night elasticsearchに参加しました。 初の海外の勉強会です（海外自体が初だし）。 ベルリンにあるWoogaという会社で開催された勉強会","tags":["elasticsearch","勉強会"],"title":"GOTO Night elasticsearchに参加しました"},{"contents":"Berlinからおはようございます。\nということで、人生で初めての海外に来ています。\n人生初の海外なのに、一人で乗り換えがあるようなBerlinに来ています。 今年はチャレンジの年になりそう。初めてづくしですが、楽しみたいなと。 会社に感謝です。ESのトレーニングを受けに来たのがメインなのです。 ついでに、Berlinでの勉強会にも参加してみようかなと。\n幸いにも時差ボケはなさそうなので、色々と見て回ろうと思います。 ただ、日曜日はお店が軒並みしまってそう。。。\n","date":1394916660,"dir":"post/2014/","id":"abc5ca9856a61831fd4ed06b402875d2","lang":"ja","lastmod":1394916660,"permalink":"https://blog.johtani.info/blog/2014/03/16/post-from-berlin/","publishdate":"2014-03-16T05:51:00+09:00","summary":"Berlinからおはようございます。 ということで、人生で初めての海外に来ています。 人生初の海外なのに、一人で乗り換えがあるようなBerlin","tags":["misc","travel"],"title":"Berlinからおはようございます"},{"contents":"elasticsearchに、このへん入れるときっと幸せになれるはず・たぶん。\u0026#10;elasticsearch/elasticsearch-analysis-kuromoji/1.6.0\u0026#10;oyrusso/elasticsearch-HQ\u0026#10;mobz/elasticsearch-head\n\u0026mdash; toshi_miura (@toshi_miura) 2014, 3月 5 こんなツイートを見かけたので、普段入れてるプラグインを簡単に紹介してみようかと。\nローカルの環境に普段入れているプラグインの紹介です。 ちゃんとクラスタを管理しているというよりは、最新版の動作などを確認するための環境になります。なので、ちょっと視点が異なるかもしれませんが参考になればと。\nelasticsearch-analysis-kuromoji URL : elasticsearch-analysis-kuromoji\nKuromojiという日本語形態素解析のTokenizerなどを使えるようにするためのプラグインです。 今度、発売される「ElasticSearch Server」日本語版には付録として、利用方法を執筆しました。参考にしていただければと。 READMEにもサンプルは掲載されてるので、こちらを参考にするのもありですが。\nelasticsearch-extended-analyze URL : elasticsearch-extended-analyze\n私が開発しているプラグインです。 ElasticsearchにはanalyzeというAPIが用意されています。 文章を渡すと指定したanalyzerなどでどのような単語に区切られるかがわかるAPIです。\nただ、analyzerの内部ではchar filter、tokenizer、token filterという個別のパーツがそれぞれ入力された文字列に対して処理を実施します。 この過程がanalyze APIではわかりません。 それをわかるようにしてみたのがelasticsearch-extended-analyzeプラグインになります。\n詳細については過去の記事を見ていただければと。 画面があると便利だよなぁと思いつつ、作ってない。。。\npolyfractal/elasticsearch-inquisitor URL : elasticsearch-inquisitor\nクエリのデバッグとかに便利なプラグイン。\nこちらも詳細は過去の記事を見ていただければと。\nmobz/elasticsearch-head URL : elasticsearch-head\nクラスタ管理に便利なプラグインです。クラスタに存在するノードに対してインデックスのデータ（シャード）がどこに配置されているかなどが一目瞭然になる便利なプラグインです。 プライマリシャードやレプリカなどもわかります。 インデックスの削除もできるし、クエリを投げることもできるし、全部入りな感じのプラグインです。\n私個人は、シャードの配置を見るのに主に利用しています。クエリを投げたりインデックスを消したりするのには殆ど使っていません。\nroyrusso/elasticsearch-HQ URL : elasticsearch-HQ\nこれも管理系のプラグインです。こっちのほうが個人的にスッキリしていて好きなプラグインです。 インデックスの管理やノードの停止などはこちらを主に使用しています。 あくまでもローカルの簡易クラスタを管理する目的というのもあります。\npolyfractal/elasticsearch-segmentspy URL : elasticsearch-segmentspy\nこちらはモニタリングでしょうか。 ElasticSearch Serverで紹介されていたのが主な理由で、入れてますがあんまり見てないかも。 インデックスのSegment単位の情報が見ることが可能です。 あと、ちょっと更新されてない感じがしますね。\nelasticsearch/marvel Elasticsearch社から提供されている、モニタリングなどに使えるプラグインです。 開発環境では無償提供という感じです。 渡しの場合、モニタリング目的ではなく、senseと呼ばれるクエリの補完をしてくれるツールの目的のために使用しています。 モニタリング部分を停止する方法とかないかなぁ。\n詳細については過去の記事を参考にしていただければと。\nまとめ？ ということで、簡単にローカルに入っているプラグインの紹介でした。 他にもいっぱいあるので、おすすめがあれば、教えてもらえると助かります。\n","date":1394515380,"dir":"post/2014/","id":"386dc9d1b647a9f3965f1fbe29c7dfb9","lang":"ja","lastmod":1394515380,"permalink":"https://blog.johtani.info/blog/2014/03/11/es-plugin-installed-to-my-env/","publishdate":"2014-03-11T14:23:00+09:00","summary":"elasticsearchに、このへん入れるときっと幸せになれるはず・たぶん。\u0026#10;elasticsearch/elasticsearc","tags":["elasticsearch","plugin"],"title":"いつも入れているElasticsearchのプラグイン"},{"contents":"第3回Elasticsearch勉強会で、軽く触れていましたが、ElasticSearch Server日本語版が発売されます。 ツイートなどもちらほらとして頂いているみたいで嬉しい限りです。\n本書は、私自身、初の翻訳本となります。\nなお、ElasticSearchはAWSのサービスではなく、全文検索・解析サーバのOSSです\n内容、概要 PacktPublishingから発売されているElasticSearch Serverの日本語版となります。 以下の点が、原著とは異なる点になっています。\n0.90.xに対応（原著は0.20） Kibana、Kuromojiに関して追記 もちろん日本語 残念ながら、つい最近、Elasticsearchについては1.0がリリースされました。 1.0で追加された機能（SnapshotやRestore、Aggregatorなど）については触れていませんが、Elasticsearchの機能を網羅的にカバーした良書となっています。 どんな機能があるのか、どんなプラグインがあるのか、どういったことに使えるのかなど、幅広くまとめられた本になっていますので、 Elasticsearchに興味がある方はぜひ読んでいただければと思います。\nまた、現段階では予定ですが電子版の出版も予定されています。電子版が気になる方は、少しお待ちいただければと。\nElasticSearch？Elasticsearch？ 1.0.0がリリースされた現在は、Elasticsearch（SearchのSは小文字）が正式な名称となっています。 ただ、原著が発売された当初（2013年2月時点）では、まだSは小文字と大文字が混在した状況でした（コミットログなどを見るとわかります。） このため、日本語版でもElasticSearchという表記に統一してあります。\n翻訳に関して 初の翻訳書ということもあり、大変でした。英語に精通しているわけではないので（むしろ苦手）。。。 他の翻訳者の方々には大変助けていただきましたし、勉強になりました。 また、監修社であるリクルートテクノロジーズにも色々とサポートしていただき、感謝の限りです。 （Elasticsearch勉強会の開場提供にも協力して頂いています。）\nわかりにくい日本語となっている部分などありましたら、ご指摘いただければ今後の参考にさせていただきます。 英語やElasticsearchについて、学ぶという目的もあって、本書の翻訳を買って出たのが本音です。\n翻訳作業について Githubのリポジトリを編集の方に用意してもらい、翻訳原稿を管理、校正していきました。 Github自体をあまり触っていなかったので、作業をしながらGithubも覚えられ一石二鳥でした。 Issueやプルリクエストによる校正、チェックも便利ですね。 他の原稿を書くようなことがあれば、またこの経験を活かしていきたいなと。 （翻訳の進め方や原稿のチェックなどについてはまた後日何か書こうかと。）\n原著について 原著のサイトが用意されています。 http://elasticsearchserverbook.com/elasticsearch-server-errata/\n原著を翻訳するにあたって見つけた、誤植などを報告し、掲載して頂いています。 原著をお持ちの場合はこちらも参考にしていただければと思います。\nご購入はこちらから ということで、簡単ですが書籍の紹介（というより宣伝！？）でした。 Elasticsearchに関する何かしらの助けになる書籍であれば嬉しい限りです。\n「ElasticSearch Server日本語版」をよろしくお願いします。 （もちろん、購入は下のリンクからですよね！）\n","date":1393836900,"dir":"post/2014/","id":"9ad72c2a5157f21741bd4581a562dfc7","lang":"ja","lastmod":1393836900,"permalink":"https://blog.johtani.info/blog/2014/03/03/release-elasticsearch-server-japanese-edition/","publishdate":"2014-03-03T17:55:00+09:00","summary":"第3回Elasticsearch勉強会で、軽く触れていましたが、ElasticSearch Server日本語版が発売されます。 ツイートなども","tags":["elasticsearch"],"title":"ElasticSearch Serverを翻訳しました"},{"contents":"今年初の「突撃！隣のElasticsearch」ということで、Wantedlyさんにおじゃましました。\n※写真を自分でも撮ったのですが、画像が壊れてたので、一緒に行ったペンギン先生の写真を拝借しました。\n第3回のElasticsearch勉強会を開催中にES使ってるってツイートを見つけたので、アタックかけて遊びに行きました。 交渉に快諾いただきありがとうございました！\nWantedlyさんがどのようにElasticsearchを使用されているかはきっと、ブログを書いてくれると思うので期待しておくとして、書いてくれました！！ 「実践！Elasticsearch」 そこで、nestedでハイライトがなんかうまくいかないって話があったので、ちょっと調べてみました。 （※まだ、調査中です）\n前提条件 再現する手順はgistにあります。（Senseに貼り付ければ動作します。ただし、elasticsearch-analysis-kuromojiが必要です。）https://gist.github.com/johtani/9184287\nなお、このマッピングやデータはWantedlyさんとは全く関係ありません。\nnestedフィールド内部のデータに対して、検索しハイライトしようとするとうまく動作しないという状況です。 マッピングは以下のとおり。\n\u0026#34;books\u0026#34; : { \u0026#34;properties\u0026#34;: { \u0026#34;book\u0026#34; : { \u0026#34;type\u0026#34;: \u0026#34;nested\u0026#34;, \u0026#34;properties\u0026#34;: { \u0026#34;title\u0026#34; : { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34;, \u0026#34;store\u0026#34;: \u0026#34;no\u0026#34;}, \u0026#34;contents\u0026#34; : {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34;, \u0026#34;store\u0026#34;: \u0026#34;yes\u0026#34;} } } } } } このマッピングの特徴は以下のとおり。\n_sourceは保存される（デフォルト値） bookがnestedなオブジェクト titleはstore : no contentsはstore : yes 動作の挙動をわかりやすくするため、titleとcontentsのstore属性に違いを持たせてあります。\n問題点 nestedクエリを使って、検索した時にハイライトが返ってきません。 次のクエリを実行するとわかります。\nGET /bookstore/books/_search { \u0026#34;_source\u0026#34; : [\u0026#34;book.title\u0026#34;,\u0026#34;book.contents\u0026#34;], \u0026#34;fields\u0026#34;: [ \u0026#34;book.title\u0026#34;, \u0026#34;book.contents\u0026#34; ], \u0026#34;query\u0026#34;: { \u0026#34;nested\u0026#34;: { \u0026#34;path\u0026#34;: \u0026#34;book\u0026#34;, \u0026#34;query\u0026#34;: { \u0026#34;query_string\u0026#34; : { \u0026#34;query\u0026#34; : \u0026#34;Solr\u0026#34;, \u0026#34;fields\u0026#34; : [\u0026#34;book.title\u0026#34;, \u0026#34;book.contents\u0026#34;] } } } }, \u0026#34;highlight\u0026#34;: { \u0026#34;pre_tags\u0026#34;: [\u0026#34;\u0026lt;b\u0026gt;\u0026#34;], \u0026#34;post_tags\u0026#34;: [\u0026#34;\u0026lt;/b\u0026gt;\u0026#34;], \u0026#34;fields\u0026#34;: { \u0026#34;*\u0026#34;: {} } } } 結果はこちら。 ハイライトがありません。\n{ \u0026#34;took\u0026#34;: 3, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 5, \u0026#34;successful\u0026#34;: 5, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;max_score\u0026#34;: 0.5, \u0026#34;hits\u0026#34;: [ { \u0026#34;_index\u0026#34;: \u0026#34;bookstore\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;_score\u0026#34;: 0.5, \u0026#34;_source\u0026#34;: { \u0026#34;book\u0026#34;: { \u0026#34;title\u0026#34;: \u0026#34;Apache Solr入門\u0026#34;, \u0026#34;contents\u0026#34;: \u0026#34;Apache Solrについて日本語で書かれた唯一の書籍です。SolrはLuceneをコアにした検索サーバです。\u0026#34; } } } ] } } 次に、ハイライトが帰ってくるパターン。 nestedクエリではなく、_allを対象としたクエリを投げます。\n{ \u0026#34;_source\u0026#34; : [\u0026#34;book.title\u0026#34;,\u0026#34;book.contents\u0026#34;], \u0026#34;fields\u0026#34;: [ \u0026#34;book.title\u0026#34;, \u0026#34;book.contents\u0026#34; ], \u0026#34;query\u0026#34;: { \u0026#34;query_string\u0026#34; : { \u0026#34;query\u0026#34; : \u0026#34;Solr\u0026#34;, \u0026#34;fields\u0026#34;: [ \u0026#34;_all\u0026#34; ] } }, \u0026#34;highlight\u0026#34;: { \u0026#34;pre_tags\u0026#34;: [\u0026#34;\u0026lt;b\u0026gt;\u0026#34;], \u0026#34;post_tags\u0026#34;: [\u0026#34;\u0026lt;/b\u0026gt;\u0026#34;], \u0026#34;fields\u0026#34;: { \u0026#34;book.title\u0026#34; : {}, \u0026#34;book.contents\u0026#34;: {} } } } この場合の結果は次の通り。\n{ \u0026#34;took\u0026#34;: 2, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 5, \u0026#34;successful\u0026#34;: 5, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;max_score\u0026#34;: 0.27063292, \u0026#34;hits\u0026#34;: [ { \u0026#34;_index\u0026#34;: \u0026#34;bookstore\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;_score\u0026#34;: 0.27063292, \u0026#34;_source\u0026#34;: { \u0026#34;book\u0026#34;: { \u0026#34;title\u0026#34;: \u0026#34;Apache Solr入門\u0026#34;, \u0026#34;contents\u0026#34;: \u0026#34;Apache Solrについて日本語で書かれた唯一の書籍です。SolrはLuceneをコアにした検索サーバです。\u0026#34; } }, \u0026#34;highlight\u0026#34;: { \u0026#34;book.title\u0026#34;: [ \u0026#34;Apache \u0026lt;b\u0026gt;Solr\u0026lt;/b\u0026gt;入門\u0026#34; ] } } ] } } ハイライトが返ってきています。\n考察（原因は未特定） 残念ながら、まだ調査してません。 まずは、現象が理解できたというだけです。 問題点が実は２つありそうです。\n問題点１：nestedクエリの場合に、ハイライトされない。 nestedクエリではハイライトが動作していないようです。 想像ですが、検索に利用されたクエリで指定されているフィールドをハイライタ（ハイライトを実行するモジュール）が認識できてないのではないかと。 なぜ認識できていないのかという点を調査する必要がありそうです。\n考察（試してみたパターン） nestedではないクエリで、ハイライトが動作しているのですが、 \u0026quot;book.title\u0026quot; : {\u0026quot;require_field_match\u0026quot; : true},にした場合は、ハイライトが返ってこないです。 このオプションは、検索対象のフィールドでマッチした文字列だけがハイライトされるオプションになります。 したがって、book.titleフィールドに対する検索でSolrという文字を検索していないことになります。 _allに対するクエリであるためです。 このため、例えば、titleだけを検索対象にしたのに、contentsにSolrという文字が入っていてもハイライトされてしまうという状況が発生します。\n問題点２ store : yesのデータがハイライトできない。 GithubにIssueをあげました。https://github.com/elasticsearch/elasticsearch/issues/5245 （2014/02/25追記）\nnestedオブジェクトにあるデータのうち、store : noのものだけがハイライト結果として返ってきました。\n考察 なぜ、store : yesのデータがハイライトされないかを調べるために、fieldsパラメータをリクエストに追加してみました。\n{ \u0026#34;_source\u0026#34; : [\u0026#34;book.title\u0026#34;,\u0026#34;book.contents\u0026#34;], \u0026#34;fields\u0026#34;: [ \u0026#34;book.title\u0026#34;, \u0026#34;book.contents\u0026#34; ], ... } すると、fieldsの戻り値は次のとおりです。\n... \u0026#34;fields\u0026#34;: { \u0026#34;book.title\u0026#34;: [ \u0026#34;Apache Solr入門\u0026#34; ] }, ... このことから、store : noのデータの場合、_sourceから値を取得して返却しているというのがわかります。 ハイライトがされない原因も、fieldsで値が取れていないのも同じ原因であると思われます。 なぜなら、ハイライトは、保存された文字列を内部で取り出し利用して、ハイライトタグを埋め込むという動作をするためです。\n参考？ これらの問題点についてですが、次のIssueが関係あるかもしれません。\nReturn matching nested inner objects per hit #3022\n今後？ 残念ながら、現時点では、問題点がどんなものかというのを理解しただけとなります。 デバッグしたりソースを追っかけたりして何が問題なのかを調べて行ってみようかなぁと。\nなにか、気づいたことなどあればコメントしてもらえると助かります。\n","date":1393231920,"dir":"post/2014/","id":"f55d33371dcff207fd7d201128df2ea3","lang":"ja","lastmod":1393231920,"permalink":"https://blog.johtani.info/blog/2014/02/24/strange-behavior-of-field-in-nested-obj/","publishdate":"2014-02-24T17:52:00+09:00","summary":"今年初の「突撃！隣のElasticsearch」ということで、Wantedlyさんにおじゃましました。 ※写真を自分でも撮ったのですが、画像が","tags":["elasticsearch"],"title":"Nested Objectのフィールドの奇妙な動作"},{"contents":"今回はたまたま日本にいたElasticsearchの人をスペシャルゲストに呼べたので、大満足ですｗ 英語の通訳とかちゃんと勉強しないとなぁ。。。\nとりあえず、てきとーなメモですが、残しておきます。 参加者数は130人＋スタッフ＋リクルートテクノロジーズ社内の人。という感じでした。アンケート集計はもう少々おまちを。\nスライドがそろったら、また、更新すると思いますが、第一報という感じで公開しておきます。 懇親会にも50名も参加していただけて、非常に楽しかったです。 話ができてない方が多数いるかもしれませんが、次回以降、声をかけていただければと。 （物覚え悪いんで、あれですが。。。） 盛り上がってきてて楽しいなぁ。 スタッフの人達の練度も上がってきてるので、すごく楽ができてます。\n至らない点とかあれば、こちらにコメントしてもらったりしていただければと。\nGeohashing with Elasticsearch Florian Schilling, Elasticsearch Inc, スライド：https://speakerdeck.com/chilling/tokyo-es-study-session-iii-geohashes\n自己紹介 Geoのスタッフ Elsticsearchの概要 転置イデックスやREST APIなどの説明 マイクの調子が良くなくて申し訳なかったっす。。。 平賀さん、通訳ありがとう！ Solr本もよろしくお願いします！！\nAWSで構築するsharding 株式会社イプロス　外山　寛さん　@toyama0919 スライド：http://toyama0919.bitbucket.org/elasticsearch.html\nAWS対応の話 ルーティングが重要だよ。（宣伝ありがとうございますｗ） type指定しないとルーティングできない。（内部でtypeも使ってハッシュ値取ってたかなぁ？） 苦労話とかいくつか。 tireはre-tire\u0026hellip; 実サービスでのElasticsearch設定・使用例（仮） 株式会社じげん　多田 雅斗さん　@tady_jp スライド：https://speakerdeck.com/tadyjp/tesutoqu-dong-jian-suo-falsesusume-at-tady-jp\n検索とは的な話がわかりやすい。 全文検索のお話。ログ検索じゃないよと。 書籍ないですよねー（ふふふ） specで検索条件記述しといて、ってのいいですよね。絶対必要だと思う Mapping変更した時にテストやり直す方法とかどうしてますか？ 特にフレームワークは使ってないです。\nMySQLユーザ視点での、小さく始めるElasticsearch 株式会社リブセンス 吉田 健太郎さん @yoshi_ken スライド：http://www.slideshare.net/y-ken/introducing-elasticsearch-for-mysql-users\nやっぱりkuromoji便利だよね MySQLとかと連携したい。 river-pluginもいまいち安定しない なので、Yamabiko作ってみました。 Geo検索とKuromojiの話をしてくれました。（作者とか開発者がいるってのを狙ってたのかすごいなぁ。） Mappingとかはちゃんと指定したほうがいろいろいいですよ。 nodeJS+DynamoDB＋Elasticsearchで全社基盤を作った話 株式会社リクルートテクノロジーズ 相野谷 直樹さん @naokiainoya スライド：http://www.slideshare.net/recruitcojp/elasticsearchnodejsdynamodb-7\nちょっと変わった使い方のElasticsearchで面白いです。 Scroll/Scanについては、Solrでもない機能なので、そういう意味でもElasticsearchなのかもしれないですね。 参加していただいた方々のブログ 第3回elasticsearch勉強会 [2014/02/07(Fri.)]に参加してきました - ほわいとぼーど\nhttp://a3no.hatenablog.com/entry/2014/02/09/022405\n第 3 回 elasticsearch 勉強会に行ってきた - ようへいの日々精進\nhttp://inokara.hateblo.jp/entry/2014/02/07/233057\nhttp://www.smokeymonkey.net/2014/02/3elasticsearch.html\n第3回elasticsearch勉強会でトークしました #elasticsearchjp\nhttp://y-ken.hatenablog.com/entry/elasticsearch-meetup-vol3\n第3回elasticsearch勉強会にいってきました #elasticsearchjp\nhttp://blog.livedoor.jp/ashibuya0128/archives/52058766.html\n","date":1391787720,"dir":"post/2014/","id":"229b7fc784707b1d2c702fbeba080e86","lang":"ja","lastmod":1391787720,"permalink":"https://blog.johtani.info/blog/2014/02/08/hold-3rd-elasticsaerch-meetup-in-tokyo/","publishdate":"2014-02-08T00:42:00+09:00","summary":"今回はたまたま日本にいたElasticsearchの人をスペシャルゲストに呼べたので、大満足ですｗ 英語の通訳とかちゃんと勉強しないとなぁ。。","tags":["elasticsearch","勉強会"],"title":"第3回elasticsearch勉強会を開催しました！ #elasticsearchjp"},{"contents":"すずけんさんがVagrant+puppet使って、VM起動してElasticsearchのクラスタを組んでる記事を書いているのを見て、試してみたくなりました。 ということで、VagrantとかPuppetなに？くらいの私ですが、クラスタを起動するところまで行ったので、その時のメモを残しておきます。\n元記事とか参考 Vagrant環境にpuppet moduleを利用してさくっとelasticsearchをインストールする Vagrant環境にpuppetを利用してさくっとelasticsearchのclusterを作成する puppet-elasticsearch なんとなくの理解 VagrantやPuppetについては、何度か勉強会で話を聞いてはいたのですが、 想像していたレベルだったので良い機会でした。 今のところの認識はこんな感じです。\nVagrant VMを起動したり、VM周りの設定をあれこれできるツール。 VMのネットワーク設定や、インスタンス名？などを指定できる。\nPuppet 起動後のVM（VMとは限らないか。）のゲストOS側の設定周りやアプリのインストールなどを 実行できるツール。\n詰まった箇所 すずけんさんのブログを元に作業をしましたが、自分がVagrantやPuppetに疎いため、以下の部分で躓いたので、備忘録のために残しておきました。\nその１：Puppetのファイルの場所 search01.vm.localのVMを設定（というか、elasticsearchのインストール？）するときに、manifests/search.appとroles/search/manifests/init.ppファイルが必要で作成します。\nこのファイルの配置場所は/vagrant配下に作成する必要がありました。 ssh search01.vm.localでVMにログインした場合は/home/vagrantにログインしており、この場所でファイルを作ってもPuppetがエラーを吐いたためです。\nと思ったのですが、あれ？これひょっとしてVagrantfileがあるところにディレクトリとファイル作ると勝手にVMにコピーしてくれるんですか？destroyして、upしたら、ファイルが勝手にコピーされてる。ひょっとして、/vagrantってディレクトリはVagrantfileがあるディレクトリを共有してたりするのかな？そのうち、Vagrantについても調べてみようかな。\nその２：ネットワーク周り curl http://192.168.10.114:9200/ をホストOSから実行してみましたがうまく行きませんでした。。。 ネットワーク周りの設定だと思うんですが。 少なくとも「sshによるログイン」「ping」コマンドの応答は返ってきてます。\nまた、VM内でcurlコマンドを実行したらレスポンスが返ってきました。\nなんで？ってツイートしたら各所から「iptables」という単語が飛んできて、 service止めたら大正解でした。まぁ、そうですよね。基本ですよね。。。\nということで、Puppetがよくわかっていませんが、ググって変更してみました。\nmanifests/search.appに以下を追加\ninclude iptables roles/iptables/manifests/init.pp\nclass iptables { service { \u0026#39;iptables\u0026#39;: enable =\u0026gt; false, ensure =\u0026gt; stopped, } } iptablesを停止するmanifests？です（良くないことなんですが、よくわかってない）。\nということで、ローカルで1個のVM起動して、elasticsearchにアクセスできることは確認できました。\nと、書いてるそばから、元記事が修正されてしまいましたｗ\nクラスタ編（変更点） クラスタを組むときに、追加でプラグインを入れたのでroles/search/manifests/init.ppは次のようにしました。\nclass search { class { \u0026#39;elasticsearch\u0026#39;: package_url =\u0026gt; \u0026#39;https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-1.0.0.RC2.noarch.rpm\u0026#39;, java_install =\u0026gt; true, config =\u0026gt; { \u0026#39;cluster\u0026#39; =\u0026gt; { \u0026#39;name\u0026#39; =\u0026gt; \u0026#39;test-es-cluster\u0026#39; }, \u0026#39;network.host\u0026#39; =\u0026gt; \u0026#39;_eth1:ipv4_\u0026#39;,, \u0026#39;marvel.agent.exporter.es.hosts\u0026#39; =\u0026gt; [\u0026#39;192.168.10.114:9200\u0026#39;,\u0026#39;192.168.10.115:9200\u0026#39;] } } elasticsearch::plugin{\u0026#39;elasticsearch/marvel/latest\u0026#39;: module_dir =\u0026gt; \u0026#39;marvel\u0026#39; } elasticsearch::plugin{\u0026#39;mobz/elasticsearch-head\u0026#39;: module_dir =\u0026gt; \u0026#39;head\u0026#39; } elasticsearch::plugin{\u0026#39;royrusso/elasticsearch-HQ\u0026#39;: module_dir =\u0026gt; \u0026#39;HQ\u0026#39; } elasticsearch::plugin{\u0026#39;elasticsearch/elasticsearch-analysis-kuromoji/2.0.0.RC1\u0026#39;: module_dir =\u0026gt; \u0026#39;analysis-kuromoji\u0026#39; } elasticsearch::plugin{\u0026#39;info.johtani/elasticsearch-extended-analyze/1.0.0.RC1\u0026#39;: module_dir =\u0026gt; \u0026#39;extended-analyze\u0026#39; } elasticsearch::plugin{\u0026#39;polyfractal/elasticsearch-inquisitor\u0026#39;: module_dir =\u0026gt; \u0026#39;inquisitor\u0026#39; } } とりあえず、今日はクラスタ組んでMarvelやプラグインの動作確認でおしまいです。\n疑問点 いくつか疑問点が。試してみてもないんでなんとも言えませんが。気が向いたら、調べて追記するかも。\n:private_networkはVirtualBox内で完結する（Macから外には影響しない）ネットワークが構築される？たぶん、VagrantというよりはVM、仮想化周りの知識なんだろうけど どこから再開可能？elasticsearch.ymlの設定を書き換えた場合に、最後のコマンドだけ実行するとちゃんとやりなしてくれたりするのかな？ VMのディスク増やすのもVagrantでできるんかな？まぁ、できると思うけど。 :forwarded_portのauto_correctとかわかってない。 JVMをSunのJVMでかつ、7u25に変更したいのだがどうしたものか？(現時点での推奨バージョン) 感想 Vagrantって便利ですね。あれ？って思ったら、destroyして、やり直すのがすごく簡単です。 元記事があるので、なんとなくですが、構成とかどうすればいいかがわかるのは本当に助かりました。 これで、あれこれと検証する環境が簡単に構築できることがわかったので、色々と楽できるかも。ありがとうございます、すずけんさん！\n","date":1391695740,"dir":"post/2014/","id":"c98cbc333fb7d95c6c9fc4924b0526e1","lang":"ja","lastmod":1391695740,"permalink":"https://blog.johtani.info/blog/2014/02/06/es-cluster-start-using-vagrant-and-puppet/","publishdate":"2014-02-06T23:09:00+09:00","summary":"すずけんさんがVagrant+puppet使って、VM起動してElasticsearchのクラスタを組んでる記事を書いているのを見て、試して","tags":["elasticsearch","vagrant","puppet","marvel"],"title":"すずけんさんのメモを元にVagrantでElasticsearchクラスタを起動してみた"},{"contents":"改訂新版Solr入門出版記念ということで、第13回Solr勉強会 #SolrJP 新Solr本出版記念を開催しました。\n出版記念なので、技術評論社様より、プレゼント用にSolr本を用意していただきました！ありがとうございます！！ 書籍をゲット出来た方は、ツイートしたりブログ書いたり書評書いたりして、宣伝してください！！！\n今回は、私は手を抜いて他の人に喋ってもらいました！\n今回は、著者陣（関口さんは特別ゲスト）でスピーカーを固めてみました。 以下は、いつもの簡単なメモです。 スライドが集まったらまた更新していきます。\n1. 「はじめての検索エンジン＆Solr」 株式会社NTTデータCCS　鈴木 教嗣さん スライド：はじめての検索エンジン＆Solr 第13回Solr勉強会\n鈴木さんの発表初めて聞きましたｗ。 趣味が多いなぁ。 ちょこちょこと、宣伝を入れてるのが流石ですｗ\n入門らしい概要 クエリの概要とかも。 スコア計算とか 導入するとうれしいところとか Solr盛り上げましょう！ 2. 「Solr SearchComponent 再訪」 株式会社ロンウイット　関口 宏司さん スライド：公開待ち\nベン図で検索の評価指標の説明 理論的なお話 Solrのサーチコンポーネントを使って何ができるか。ベン図で。 サーチコンポーネント以外にも NGramTokenizerも SynonymFilterも パーソナライズ検索 いきなり話をふられたのでちょっとびっくりしましたｗ\n3. 「自動補完(Autocomplete)ともしかして？(Did You Mean?)」 株式会社 ロンウイット　大須賀 稔さん スライド：Solr AutoComplete and Did You Mean?\nデモ：https://github.com/mosuka/solr-suggester-demo-ui\n職歴が相変わらずおもしろい 編集距離のお話 素晴らしいCM！ 候補のランキングを変更できる？ SpellcheckComponentのパラメータで指定できるものなら楽ですが。。。\n4. 「Lucene Revolution 2013 Dublin振り返り」 楽天株式会社　平賀 一昭さん スライド：公開待ち\nダブリンどこ？（間違ってベルリンって言っちゃいましたｗ） スタジアムで開催。グランドにも入れるのかなぁ？ まずはTwitter Luceneの改良版 ちょっと特殊。１４０文字とか 青いRさんのライバル。Careerbuilder 元FASTユーザ 企業向けに検索キーワードとかの解析画面を用意 検索精度の改良の話とか 転職で引っ越す意思があるかとか。 最後はLinkedIn Luceneのユーザ まとめ ということで、スピーカーの方々のスライドにもありましたが、 改訂新版Apache Solr入門は良い本なので、購入していただけると嬉しいです。\n感想、コメントなど、いつでもお待ちしています！\n","date":1390988760,"dir":"post/2014/","id":"c6107ff57e96a1373c019d252c00ad84","lang":"ja","lastmod":1390988760,"permalink":"https://blog.johtani.info/blog/2014/01/29/hold-to-japan-solr-meetup/","publishdate":"2014-01-29T18:46:00+09:00","summary":"改訂新版Solr入門出版記念ということで、第13回Solr勉強会 #SolrJP 新Solr本出版記念を開催しました。 出版記念なので、技術評論社様より、プレ","tags":["Solr","勉強会"],"title":"第13回Solr勉強会を開催しました"},{"contents":"昨晩、Elasticsearchから初のプロダクトとなるMarvelがリリースされました。ということで、さっそく触ってみて、簡単な紹介と感想を書いてみました。\nMarvelって？ Elasticsearch社が初のプロダクトとしてリリースした、Elasticsearchクラスタモニタリングツールです。 次のような特徴があります。\nplugin形式で提供 GUIがKibana メトリックスはElasticsearchに保存 SenseがChrome以外でも使える プロダクション環境で利用する場合は有料ですが、開発用途では無料で利用できます。 現時点(2014/01/29)では、0.90.9以上のバージョン(1.0.0.RC1含む)で利用が可能です。\nなにができるの？ Elasticsearchクラスタに関するメトリックスを保存、可視化できるプロダクトです。 ドキュメント数やJVMの状況、クラスタの状態など、いろいろなメトリックスが保存されます。\n保存先は、別のElasticsearchクラスタにすることも可能です。 お試しでインストールして見る場合は、同一クラスタにサービスに利用するインデックスとMarvel用のメトリックス保存先インデックスを入れても良いです。\nただ、プロダクション環境では、Marvel用インデックスはあくまでもモニタリングに使用するため、サービスのクラスタへの影響を最小にしたくなります。\nこのような場合、Marvelのプラグインの設定を変更することで、メトリックス送信用のエージェントとして動作させることができます。\n詳しくは、Marvelのドキュメントにあるinstalling a secondary monitoring clusterを御覧ください。\n1/29 16時時点で、上記ドキュメントのエージェントの送信先の設定に関する部分に誤記がありました。 おそらく、configuration optionsの記述が正だと思います。 もう、なおってました。(1/30朝時点)\nキャプチャいろいろ 日本語WikipediaのデータをRiverで登録しながら各画面の動作などを見てみました。\nMarvel Overview 日本語WikipediaをRiverで登録してる途中。Loadが高くなってることなどがわかります。\nOverview (クラスタの状態が変化) クラスタの状態が変化したところに、タグが付くみたいです。 ここでは、ノードの一つを停止、起動しました。\nインデックス終了後に、クラスタを再起動してしまい、クラスタ内のシャードの再配置が実行されてしまったため、クラスタの状態がYellowになってしまうとこんな感じ。ちょっとわかりにくいです。\nSense Chromeプラグインとしてリリースされていたクエリ実行コンソールがMarvelのサイトプラグインとして提供されています。これがあるだけで、Elasticsearchへのクエリの実行が格段に効率良くなります。\nIndex Statistics インデックスに関する情報のグラフが見れるページです。ドキュメント数の他に、容量やリクエスト数なども見れます。\nインデックス終了後のグラフはこんな感じ。\nインデックス終了後のOverviewはこんなかんじです。\nCluster Pulse クラスタで発生したイベントとイベントの詳細を見ることができるページです。各種インデックスがYELLOWからGREENに変わっていっているのがmessageで分かります。\nすべて再配置が終わったらGREENになりました。\nNode Statistics 各ノードに関する情報を見ることができる画面です。 ノードごとにグラフの色を分けることもできます。\nその他 Marvelプラグインにブラウザから接続できなくなるとこんなメッセージが出ました。\n参考までに、elasticsearch-headの画面も。こちらのほうが、シャードの再配置中であるのがひと目で分かります。\n感想 綺麗です。まぁ、Kibanaが綺麗ですから。 クラスタ内で発生したイベントが時系列で保存されるため、あとからどんなことが発生したのかといった原因の追求などには非常に役に立ちそうです。\nただ、インデックスの状態や状況（クラスタ再起動やノード追加時にshard再配置などが実行されている状況とか）はelasticsearch-headのほうがわかりやすかったです。 インデックス単位でのStatusがMarvelの画面ではわからないため、shard再配置が完了したかどうかなどのタイミングがわかりにくかったです。\nある程度、多くのノードを利用したクラスタを利用する場合に、モニタリングツールとして利用するのは便利なのではないでしょうか？ 時系列でログやイベントが保存されるので、ノードが追加されたり外れたりといった状況があとからでも追跡可能なのが便利です。\n疑問点 インデックスの情報などは、5s毎にMarvelのインデックスに保存されているようです。ただ、GUI上では5分毎のデータしか表示されません。 どうやって変更するんだろう？\nまた、Marvelのクラスタへの接続が切れた時のデータはどうなるのか？という部分も気になります。Marvelのクラスタを更新している時や、ネットワークが遮断されてしまった場合のデータがどうなるのかという点です。\n疑問点への回答(2014/01/30追記) 疑問点に対して中の人から回答を頂いたので、追記です。\nQ：GUI上で5分毎のデータしか表示されないんですが？ A：ブラウザの負荷を高くしないようにするために、1つのグラフに20のプロットしてるだけです。ズームしたりすると、もっと細かなデータが見れますよ。 Q：Marvelのクラスタへの接続が切れた時のデータはどうなるんだろう？ A：接続が切れた場合は、ローカルに保存されるけどデータは無視されます。接続が戻ると、戻った後のデータは記録されていきます。将来的には改善するかも。 ちなみに、昨日試してた環境が、足元Linux環境（監視対象のクラスタ）＋手元Mac環境（Marvelモニタリングデータ格納クラスタ）という環境でした。 確かに、出社してから、手元Mac環境を起動すると、データが流れてくるようになりました。 ただ、監視対象のクラスタでは、socket timeoutのログがずっと出てましたが。\n参考文献 リリースブログ プロダクトページ ドキュメント ","date":1390983240,"dir":"post/2014/","id":"f6debed350f20a2b3aa4d970e3227411","lang":"ja","lastmod":1390983240,"permalink":"https://blog.johtani.info/blog/2014/01/29/simple-introduction-and-first-impression-es-marvel/","publishdate":"2014-01-29T17:14:00+09:00","summary":"昨晩、Elasticsearchから初のプロダクトとなるMarvelがリリースされました。ということで、さっそく触ってみて、簡単な紹介と感想","tags":["elasticsearch","marvel"],"title":"Elasticsearch Marvelの紹介と第一印象"},{"contents":"Lucene/Solr 4.6.1がリリースされそう(バイナリ配布待ち)lucene-gosenの4.6.1対応版をリリースしました。\nライブラリのインタフェースなどは特に変更はないのですが、ライブラリのダウンロード先が変更になっているため、注意喚起です。\nGoogle Project Hostingの仕様変更により、Downloadsに新規ファイルがアップロードできなくなっています。（2014年から）\nこのため、プロジェクトの選択肢としては以下の3点となっています。\nGoogle Driveにファイルをアップロードしてダウンロードしてもらう 他のソースコード管理サイトなどを利用する。 他のダウンロードサイトを利用する 1.と3.は場所が違うだけで、方法は一緒です。 今回は、暫定的に1.を利用してダウンロードするように対応しました。\nダウンロード先はプロジェクトのページにリンクが有りますが、わかりにくいのでキャプチャを撮ってみました。\nダウンロード先 これまでのFeatured - Downloadsとは異なり、Links - External linksの下に Downloads lucene-gosen 4.6.1というリンクを用意してあります。\nフォルダとなっており、各種jarファイルがリストされていますので、こちらからダウンロードをお願いします。 今後は、この下にダウンロードリンクを追加していく予定です。\nただし、2.で述べたように「別のソースコード管理サイト」も検討中です。\n","date":1390880040,"dir":"post/2014/","id":"c4e7199a586a308352b7a881add7e356","lang":"ja","lastmod":1390880040,"permalink":"https://blog.johtani.info/blog/2014/01/28/release-lucene-gosen-4-dot-6-1/","publishdate":"2014-01-28T12:34:00+09:00","summary":"Lucene/Solr 4.6.1がリリースされそう(バイナリ配布待ち)lucene-gosenの4.6.1対応版をリリースしました。 ライブラリのインタフェースな","tags":["Solr","Lucene","lucene-gosen"],"title":"lucene-gosen 4.6.1のリリースに関する注意点"},{"contents":"Elasticsearchのcuratorのブログ記事を読んで、日本語でツイートしたところ、Aaron Mildensteinさんから日本語（ローマ字）で返信を頂きました。 せっかくなので、ブログ記事を翻訳してもいいかを尋ねたところ、快くOKを頂いたので、翻訳してみました。参考になればと。（誤訳など見つけたらコメントください。）\n@johtani Kore no hou ga ii. Nihongo de no Curator RT, arigatou gozaimasu! #elasticsearch #curator #logstash\n\u0026mdash; Aaron Mildenstein (@theuntergeek) 2014, 1月 22 curator: 時系列インデックスの管理 原文：curator: tending your time-series indices\n背景 数年前、Elasticsearch、Logstash、Kibana(ELK)を管理し、ここ30日よりも古いインデックスを自動的に削除する方法を必要としていました。 APIドキュメントを読み、#logstashや#elasticsearchのIRCチャネルのコミュニティの助けを借りて、簡単なスクリプトとcronを用意するのが簡単であることを知りました。\ncurl -XDELETE \u0026#39;localhost:9200/logstash-2014.01.01?pretty\u0026#39; もちろん、これも動作しますが、日付を生成するのがめんどくさいのでもっとエレガントな方法が欲しかったです。\n最初に pythonでスクリプトを書き始めました。特定の日数のインデックスを管理するだけのコマンドラインクリーナーを書いてコミュニティにシェアしました。他の人が、新しい機能を追加してくれました。私は、古いインデックスをoptimizeすることができる他のスクリプトも書きました。これは、シャードごとにnセグメント以上存在しないように各シャードのセグメントをマージすることです。これらのスクリプトで1つになるようにマージしたりエンハンスし、古いインデックスを管理する助けになるツールです。\ncuratorの紹介 Curatorで可能なインデックスオペレーション\n削除（日付もしくは、トータル容量による制限） インデックスのクローズ(Close) bloom filter cacheの無効化 Optimize(LuceneのforceMerge) curatorのインストール この記事を書いている時点で、Curator は0.5.1がリリースされ、0.90.10に対応しています。Curatorはまた、Elasticsearchの1.0(現在はRC1)へも対応しています。各リリースへの互換性の保証のためのテストも行っています。\n現時点では、gitリポジトリで配布しています。近い将来、pipによるインストール可能なパッケージにする予定です。利用することを恐れないでください。もし、pythonとpipがあなたのマシンにインストールされていれば、次のようにインストールは簡単です。\ngit clone https://github.com/elasticsearch/curator.git pip install -r requirements.txt インストール後の確認は次のコマンドです。\n$ ./curator.py -v curator.py 0.5.1 利用方法とサンプル サンプルを示す前に、オプションを見ておくとよいでしょう。このリストは長いですが（この記事の最後に含まれています）、どのようなことがコントロールできるかを説明しています。デフォルトがどうなっているかに注意してください。もし、デフォルト値で良い場合は、フラグを指定する必要はありません。\nでは、簡単なサンプルを見ながら、CuratorがELKスタックをどうやって管理するかを見て行きましょう。\n削除(delete) 90日以上のインデックスを保存したくないとしましょう。コマンドは次のようになります。\n$ curator.py --host my-elasticsearch -d 90 -dで日数を指定しているだけです。簡単でしょ？\n容量による削除(delete by space) これは、指定したギガバイト数を超えたインデックスを場合に(最も古いものから)削除を行う特殊なケースです。\n$ curator.py --host my-elasticsearch -C space -g 10024 -Cでspaceによるcurationであること、-gでギガバイト数(10024、10TB)であることを指定しているのがわかります。-gは1.5や0.5という数値を指定できます。\nその他のCuratorオプションはspaceによる削除と組み合わせて使用できないことに注意してください。\nクローズ(close) Open/Close Index APIにより、インデックスをクローズすることができます。\nopen/close index APIを利用すると、インデックスをクローズしたり、あとでオープンしたりすることができます。クローズされたインデックスはクラスタのオーバヘッドにほとんどならず(メタデータの管理を除く)、読み書き操作の妨げにもなりません。クローズされたインデックスは、リカバリプロセス時に、オープンされます。\nインデックスをクローズすることは、存在はするが検索できないという意味です。何が便利なのでしょう？\n90日のインデックスを保存する義務があるが、検索は過去30日のインデックスを対象にする以外は稀であるような場合を想像してください。このような状況で、価値のあるリソース(ヒープスペースなど)を節約するためにインデックスをクローズすることができます。これは、クラスタに検索やインデキシングのためのメモリを与えることができることを意味します。そして、もし、クローズしたインデックスのデータが必要になったら、APIを呼び出してインデックスをオープンすれば検索できます。\nこのような場合、今オープンしているインデックスが再び、クローズされないように、一時的にCuratorのスケジュール実行をオフにしておくのが懸命です。\n$ curator.py --host my-elasticsearch -c 30 -d 90 先ほど説明した例の実行方法です。これは、30日よりも古いインデックスはクローズし、90日より古いインデックスを削除します。本当に簡単でしょ？\nbloom filterの無効化 これは、0.90.9以降のバージョンで利用可能な機能です。(リンク先はIssue #4525)\n心配しないでください。このスクリプトは操作を行う前に、elasticsearchが利用可能なバージョンであるかをチェックします。\nbloom filterとは何でしょう？なぜ、無効化したくなるのでしょう？\nbloom filterはインデキシング操作を高速化するためにリソースを割り当てられます。時系列データで、インデキシングしている間もこれは有用です。インデックスは2日後には、日付が変わると新しいデータはおそらくインデックスされません。そのインデックスにはもはや必要のないリソースをbloom filterはまだ持っています。Curatorはこれらのリソースを開放することができます！\n$ curator.py --host my-elasticsearch -b 2 -c 30 -d 90 これで、bloom filterのリソースは少なくとも2日(1にもできます)よりも古いインデックスについては利用せず、30日より古いインデックスはクローズし、90より古いインデックスは削除します。\noptimizeというよりもforcemerge コマンドの説明をする前に、Elasticsearch APIのoptimizeを見ることは、生きているインデックスや\u0026quot;cold\u0026quot;インデックス(インデキシングがアクティブではないという意味)に実行する必要があるということを理解するために重要です。実際、optimizeはLuceneではforceMergeと名前が変えられ、インデックスを改善するためにoptimizeを呼び出す必要はなくなりました。Elasticsearchのセグメントをマージすることは利点がありますが、coldインデックス全てに対してoptimizeを開始する前に、コストを理解する必要があります。\nforceMerge操作はインデックスにある各シャードのセグメントの数を少なくします。各セグメントはオーバヘッドがあるため、セグメントが多いということは、より多くのリソースを使うという意味です。良さそうですね？リソースが少ない？\nそれは、可能ですが、merge操作を実行するには多くのディスクやネットワークI/Oが必要で、ディスクやクラスタの通常の書き込み操作に悪影響を及ぼします。もし、これが必要なら私のアドバイスを良く考えてください。(数％ほど)検索を速くし、リソースの使用量も減らすことができます。また、管理しているセグメント数が小さくなるということは、クラスタのリカバリを速くすることにもなります。1つのインデックスをoptimizeするためにはおそらく1時間以上の時間がかかります。「使用する前に目立たない場所で試してください」というクリーニングボトル(訳注：洗剤とか漂白剤かな？)の注意書きと同様に、ディスクI/Oが低い時にテストし、もし操作とリソースがあなたのクラスタのユースケースにあっているかを見てください。デフォルトでは、シャードごとに2つのセグメントにマージしますが、--max_num_segmentsフラグで変更可能です。\nここまでのサンプルは次のようなコマンドになります。\n$ curator.py --host my-elasticsearch -b 2 -o 2 -c 30 -d 90 これで、bloom filterは2日より古いインデックスでは向こうにし、2日より古いインデックスは\u0026quot;optimize\u0026quot;し、30日より古いインデックスはクローズし、90日より古いインデックスは削除されます。\n操作の順序 スクリプトは操作が衝突するのを防ぐために次の順序で実行されます。なぜ、クローズされたインデックスはoptimizeしないのでしょう？なぜ、削除予定のインデックスはクローズされないのでしょう？\nDelete (by space or time) Close Disable bloom filters Optimize 使用の検討 最後の例で、3つの操作を1つのコマンドで実行していますが、それらが連続ですべて実行されるのを望んでいないかもしれません。\n$ curator.py --host my-elasticsearch -b 2 -o 2 -c 30 -d 90 これは、次の操作と同様です。\n$ curator.py --host my-elasticsearch -d 90 $ curator.py --host my-elasticsearch -c 30 $ curator.py --host my-elasticsearch -b 2 $ curator.py --host my-elasticsearch -o 2 これらのコマンドを異なる時間に実行したり、異なるその他のオプション(特に、optimize実行で--timeout 3600を追加したり)を指定して実行するのは簡単です。\nまた、デフォルトのlogstash-とは異なるプレフィックスのインデックスを持っているかもしれません。\n$ curator.py --host my-elasticsearch --prefix logstash- -d 30 $ curator.py --host my-elasticsearch --prefix othername- -d 30 最後に Curatorは時系列インデックスの保存ポリシーを管理するのに役立ちます。豊富な設定オプションがインデックスを管理することを簡単にします。クラスタに存在するノードの数に関係なく。https://github.com/elasticsearch/curatorへのフィードバックやコントリビューションをお待ちしています！\n参考(全引数とオプション) $ curator.py -h usage: curator.py [-h] [-v] [--host HOST] [--port PORT] [-t TIMEOUT] [-p PREFIX] [-s SEPARATOR] [-C CURATION_STYLE] [-T TIME_UNIT] [-d DELETE_OLDER] [-c CLOSE_OLDER] [-b BLOOM_OLDER] [-g DISK_SPACE] [--max_num_segments MAX_NUM_SEGMENTS] [-o OPTIMIZE] [-n] [-D] [-l LOG_FILE] Curator for Elasticsearch indices. Can delete (by space or time), close, disable bloom filters and optimize (forceMerge) your indices. optional arguments: -h, --help show this help message and exit -v, --version show program version number and exit --host HOST Elasticsearch host. Default: localhost --port PORT Elasticsearch port. Default: 9200 -t TIMEOUT, --timeout TIMEOUT Elasticsearch timeout. Default: 30 -p PREFIX, --prefix PREFIX Prefix for the indices. Indices that do not have this prefix are skipped. Default: logstash- -s SEPARATOR, --separator SEPARATOR Time unit separator. Default: . -C CURATION_STYLE, --curation-style CURATION_STYLE Curate indices by [time, space] Default: time -T TIME_UNIT, --time-unit TIME_UNIT Unit of time to reckon by: [days, hours] Default: days -d DELETE_OLDER, --delete DELETE_OLDER Delete indices older than n TIME_UNITs. -c CLOSE_OLDER, --close CLOSE_OLDER Close indices older than n TIME_UNITs. -b BLOOM_OLDER, --bloom BLOOM_OLDER Disable bloom filter for indices older than n TIME_UNITs. -g DISK_SPACE, --disk-space DISK_SPACE Delete indices beyond n GIGABYTES. --max_num_segments MAX_NUM_SEGMENTS Maximum number of segments, post-optimize. Default: 2 -o OPTIMIZE, --optimize OPTIMIZE Optimize (Lucene forceMerge) indices older than n TIME_UNITs. Must increase timeout to stay connected throughout optimize operation, recommend no less than 3600. -n, --dry-run If true, does not perform any changes to the Elasticsearch indices. -D, --debug Debug mode -l LOG_FILE, --logfile LOG_FILE log file ","date":1390542480,"dir":"post/2014/","id":"15f501351d482ffd73985a50f5c89d1f","lang":"ja","lastmod":1390542480,"permalink":"https://blog.johtani.info/blog/2014/01/24/curator-tending-your-time-series-indices-in-japanese/","publishdate":"2014-01-24T14:48:00+09:00","summary":"Elasticsearchのcuratorのブログ記事を読んで、日本語でツイートしたところ、Aaron Mildensteinさんから日本語（","tags":["elasticsearch","curator"],"title":"Curator: 時系列インデックスの管理(日本語訳)"},{"contents":"あけましておめでとうございます。今年もSolrやElasticsearchについて色々と頑張っていく所存です。 とまぁ、お決まりの挨拶はおいておいてと。(もう、新年も22日ですが。。。)\nElasticsearchの1.0.0RC1がリリースされました。 ということで、私が作っているExtended-Analyzeプラグインも1.0.0RC1向けに修正してリリースしました。\n1.0.0RC1向けに修正したこと コミットログを見てもらえば、いいのですが、ロジック自体は変更しなくても良かったです。\nただ、正式に、Elasticsearchのつづりが決定したようで、クラス名が「ElasticSearchほげほげ」から、「Elasticsearchほげほげ」と、SearchのSが小文字になりっています。 この影響で、例外クラスなどの名称を幾つか変更しました。 また、バージョン番号を1.0.0RC1とし、0.x系をElasticsearchの0.90系向けのバージョンにしていく予定です。\n今後は、UIを追加したいと思っているので、Elasticsearchのバージョン番号とはずれてくるとは思いますが。。。\nElasticsearch 1.0.0RC1を利用してみて 1点だけですが。 これまでは、-fオプションを指定すると、デーモンではない動作で起動できていました。（デフォルトがデーモン起動）\nこれが、1.0.0から（0.90の最新もかな？詳しく見ていない）デフォルトの挙動が変更され、デーモン起動ではなくなりました。 代わりに、-dオプションを指定することで、デーモン起動ができるようになりました。\nこれで、手元でうっかりデーモン起動することがなくなって、ひと安心です。（他の人は困るかもしれないけど）\nということで 1.0.0RC1が出たので、少しずつ1.0系で追加されたAPIや機能について、ブログで紹介していけたらと思います。\nこんなこと調べてよ？、これわかんないんだけど？などありましたら、コメントいただければと。 気が向いたら記事を書くので。\nあと、Extended-Analyzeプラグインの感想などもお待ちしています！\n今年もよろしくお願いします！\n","date":1390317360,"dir":"post/2014/","id":"6425af51edead39c0e439073986043fb","lang":"ja","lastmod":1390317360,"permalink":"https://blog.johtani.info/blog/2014/01/22/release-extended-plugin-for-1-0-0rc1/","publishdate":"2014-01-22T00:16:00+09:00","summary":"あけましておめでとうございます。今年もSolrやElasticsearchについて色々と頑張っていく所存です。 とまぁ、お決まりの挨拶はおいて","tags":["elasticsearch"],"title":"Extended-Analyze 1.0.0RC1をリリースしました"},{"contents":"昨年は、大晦日に書いてました。 ちょっと進歩したかも。\n振り返り(2012年に書いた抱負から) ということで、まずは昨年書いた抱負からの振り返りです。\nIntelliJ IDEAをメインに使う JIRAを継続して活用 ブログの継続 elasticsearch Luceneのソースコードリーディング 何かOSSのソースを読む Macでもっと開発 読書と英語を継続 お。思ったよりもできてるかも。 IntelliJ IDEAについては、メインになりました。Eclipseを開くことはまずないです。 Macがメインの開発マシンにもなってきてるので。(開発してないんじゃないかという話も。。。)\nJIRAは一応、継続しているという感じです。\n唯一Luceneのソースコードリーディングができてないですね。。。 言い訳をすると、明示的にソースコードリーディングをしているわけではないですが、Luceneのソース自体は時々見ています。 SolrやElasticsearchを調べるとそのままLuceneにたどり着くことがあるので。\nポモドーロのタスク管理用に使っていますが、時々忘れていたり。あと、振り返りがまだちゃんとできてないので、そこをやらないとかなぁと。 読書と英語は今後も継続です。もっと習慣づけないと。\n振り返り(今年あった出来事など) CROSSでモデレータやりました Xperia Zに機種変 メニエール病 リクルートテクノロジーズさんのお手伝い Lucene In Action輪読やってる MIR輪読も継続 Solr勉強会を不定期開催 Elasticsearch勉強会を始めた Solr本の改訂版を執筆 AWSちょっと触った Elasticsearchプラグイン作ってみた Githubの活用 Octopressでブログ こんなかんじです。\nCROSSでは、モデレータをやらせていただきました。すこしは検索を面白いと思ってもらえたかなと思います。 来年のCROSS 2014ではスタッフとして盛り上げていく予定ですので、スタッフに興味ある方は声をかけてください！ 面白い話がいっぱい聞けますし、おいしい物も飲み食いできるかも！？\nXperia Zは良い買い物でした。ただ、すでに2回電源部分が故障してますが。。。 それ以外は非常に快適です。\n2月末から3月は少し休んでました。難聴→めまい→メニエール病という流れで、ちょっとしんどかったです。 ほぼ回復しましたが、原因は不明みたいなので、長く付き合ってくのかなぁと。\n4月からリクルートテクノロジーズさんの仕事を手伝っています(Solr本の著者紹介にも書いてます)。 色々と面白いことをしているATLという部署で面白い人達と仕事させて頂いてます。 来年もよろしくお願いします！(もっと価値を出さないとなぁ。。。)\nその一環で、Lucene In Actionの輪読を社内でやっていたりも。バージョンが3.x系で書かれているので、 ちょっと大変ですが、4だとどう違うかなどの話を交えつつ少しずつ読んでいます。\n輪読会といえば、MIR(Modern Information Retirieval)の輪読も続いています。 私は深いところまでわからないのですが、色々と詳しい方たちとボチボチ読んでます。教えてもらってばかりですが、来年も頑張りますよと。\nSolr勉強会も、引き継いでぼちぼちやっています。来年は1/29に開催します。Solrの入門的な話をしてもらうので、 ぜひ、触ったことがない方や興味がある人に参加していただきたいと。\nElasticsearch勉強会も主催し始めました。興味ある人がいるだろうとは思ったのですが、想像以上でびっくりしてます。 自分が理解を深め、発表するためにも、2ヶ月程度のスパンで来年も開催する予定です。 スピーカーに興味のある方は、elasticsearch-jpのMLや私にコンタクトしてください。\nSolr入門のSolr4対応版も執筆しました。今回は全体のコーディネートもやらせていただきました。 Solr活用のお役に立てていただければと。まだ購入してない方はぜひ、以下のリンクから！(PDF版もあります。) 質問などあれば、ブログにコメントをいただくか、ツイートしていただくか、技術評論社のサポートページに問い合わせていただければと思います。\nAWSをちょっとだけ触りました。 S3にバックアップ取ってるだけですが。。。来年はもう少し。。。 JIRA（さくらVPSに立ててる）のバックアップなどをやってます。\nあとは、Elasticsearchの勉強会も始めたこともあり、Elasticsearchを色々と触っています。 elasticsearch-analysis-kuromojiプラグインのREADMEを記述してコントリビュートしてみたり、 elasticsearch-extended-analysisプラグインを作ってみたり。\n勉強会のスピーカー探しも兼ねて、いろんなところに、「突撃!隣のElasticsearch」と称してElasticsearchの話を聞きに行きたいと思っていますので、使ってるよ！とか使いたいんだけど、どうすればいい？みたいな話があれば、声をかけてください。Twitterでツイート見たら勝手に、アタックすることもあるかもですが、その時はよろしくお願いします。\n来年はSolrやElaticsearchにもっと貢献できればと。\nGithub(git)もようやくまともに触り始めました。 某データの管理やプラグインの開発などでやっと触り始めました。 まだ、チーム開発ってほどではないので、チームで開発するときのやり方なども少しずつ勉強していこうかと。 プルリクとかも少しずつやってみたりしてます。\nあとは、Octopressでブログ始めました。その前はjugemだったのですが、なんとなく。 Markdownに慣れるためというのもありOctopressにしてみました。 (Solr本の原稿もMarkdownで書いてました) 昔のブログもこっちにコピーするプログラムも書いてみようかな。\n来年の抱負 Elasticsearch勉強会、Solr勉強会の継続＋ミックスした検索勉強会の開催 IDEAのさらなる活用 もっと開発(プラグインとか) AWSをもう少し活用 海外のイベントに行ってみたい 読書と英語を継続 勉強会の開催は今後も継続していく予定です。会場を毎回提供して頂いているVOYAGE GROUPさん、リクルートテクノロジーズさんには、 今後もお手数をお掛けしますが、よろしくお願い致します。勉強会の開催を通じて、色々な人のノウハウがうまく共有できて、 もっと本質的な作業（サービスの改善とか）に注力できる環境ができると面白いなぁと思ってるので。\nあと、Elasticsearch、Solrと別々の勉強会になっていますが、検索エンジン勉強会という形でそれぞれのメリット・デメリットを 共有できる勉強会も面白いかもと思っているので、春とかに開催したいなぁと考えてもいます。（まだ考えているだけで何もネタがないですが）\nIDEAは、年貢(13のサブスクリプション)を収めたので、もっと活用しないとという意味で。プラグインの開発、gitやsvnのクライアントとしては 活躍していますが、もっと開発に活用していかないとなぁと。まだ、10%くらいしか活用できてない気がするので。\nもっと開発しないとなと。毎年言ってますが。今年は書籍に注力したのもあり、ソースを読んだり英語を読んだりが多くなってました。 偉そうにしてるためか、開発する機会が減ってきているので、細かなことでもいいので、すこしずつコードを書いていこうかと。 （もっと自分で問題点を見出してそれを補完するようなコードなりプラグインなり書けばいいんだろうな。）\n開発と合わせて、AWSをもう少し触りたいなと。これも数年言っていますができてないです。。。 ネタ探すのが下手なのかなぁ。\n海外イベントにも行ってみたいです。まだ、海外行ったことないんですが。。。 Lucene Revolutionとか。その訓練も兼ねて英語でメール書いたり、プラグインのREADME書いたりしてみてます。\n最後は、毎年恒例ですが、読書と英語です。 Packtのキャンペーンで買ってしまった英語の本とか貯まっているので、読まないと。 nasneが便利で通勤時間にドラマ見てるからなぁ。ま、必要なときにボチボチと読んでいく予定です。\n最後は、いつものようにですが、来年も勉強会やいろんなイベントに参加する予定です。 ブログも週1程度で書く努力しないとなぁ。 こんな話を書いてくださいとかのリクエストもお待ちしています。\n今年もまだ、大晦日が残っていますが、色々とお世話になりました。 この場を借りてお礼申し上げます。\n来年も、いろんな方に絡んでいくとは思いますが、よろしくお願いいたします。\n","date":1388406000,"dir":"post/2013/","id":"10c715f70de25ccb493bbbb532b78ced","lang":"ja","lastmod":1388406000,"permalink":"https://blog.johtani.info/blog/2013/12/30/looking-back-2013/","publishdate":"2013-12-30T21:20:00+09:00","summary":"昨年は、大晦日に書いてました。 ちょっと進歩したかも。 振り返り(2012年に書いた抱負から) ということで、まずは昨年書いた抱負からの振り返りで","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2013）"},{"contents":"昨夜、Elasticsearchの0.90.8がリリースされました。\nリリースされた内容などについては、本家のブログ「0.90.8 released」をご覧いただくこととして。 1点注意したほうが良い点があります。\nelasticsearch-analysis-kuromojiを利用している場合は、0.90.8に対応したバージョンがリリースされるのを待つ必要があります。\nelasticsearch 0.90.8はLuceneのバージョンが4.6.0に変更されています。 Lucene 4.6.0では、TokenStreamというTokenizerのI/Fに変更があり、Tokenizerの実装を変更する必要があります。\n現時点（2013年12月19日現在）のelasticsearch-analysis-kuromojiの1.6.0にはlucene-analyzers-kuromoji-4.5.1.jarが含まれており、この部分でI/Fが異なるためエラーが発生してしまいます。 プラグインをインストールする時点ではエラーは発生せず、実際にKuromojiのTokenizerやAnalyzerを利用するタイミングでエラーが出ます。 以下、0.90.8にanalysis-kuromojiの1.6.0をインストールした状態で_analyzeを実行した時のエラー。\ncurl -XPOST \u0026#39;localhost:9200/_analyze?tokenizer=kuromoji_tokenizer\u0026amp;filters=kuromoji_baseform\u0026amp;pretty\u0026#39; -d \u0026#39;寿司が美味しかった\u0026#39; { \u0026#34;error\u0026#34; : \u0026#34;IllegalStateException[TokenStream contract violation: reset()/close() call missing, reset() called multiple times, or subclass does not call super.reset(). Please see Javadocs of TokenStream class for more information about the correct consuming workflow.]\u0026#34;, \u0026#34;status\u0026#34; : 500 } ということで、1.7.0がリリースされるのを待つか、自分でmvn packageしてビルドする必要があります。 他にも独自でTokenizerなどを造られている方は注意が必要かと。\nたぶん、すぐにリリースされるんじゃないかなぁと。\n2013/12/20追記\nとりあえず、masterブランチが0.90.8に変更されたみたいです。(と書いてるそばから、1.7.0がリリースされました) ということで、0.90.8では1.7.0を使うとエラーが出ないです。 （あと、踊り字対応のcharfilterも追加されたみたいです）\n","date":1387524240,"dir":"post/2013/","id":"c18b12fff24dc87e7f1039bd17c0c6aa","lang":"ja","lastmod":1387524240,"permalink":"https://blog.johtani.info/blog/2013/12/20/release-elasticsearch-0-90-8/","publishdate":"2013-12-20T16:24:00+09:00","summary":"昨夜、Elasticsearchの0.90.8がリリースされました。 リリースされた内容などについては、本家のブログ「0.90.8 releas","tags":["elasticsearch","kuromoji"],"title":"Elasticsearch 0.90.8がリリースされました＆注意点（2013/12/20追記）"},{"contents":"Solr本が出てから、質問を受けてブログ書くと言いながら書いてなかったことを思い出しました。。。\nプラグインの配置方法についてこんな質問を受けてたので、それっぽいエントリを書いておきます。（想像と違ってたらツッコミ入れてください）\n@johtani 追加でプラグインの配置方法とかあると便利かなと思いました\n\u0026mdash; Tsubosaka (@tsubosaka) 2013, 12月 2 改定前のSolr本では、日本語の形態素解析器をjarファイルとして追加する方法が書かれていました。 ただ、改定後のSolr本では、KuromojiがLuceneで実装されているためサンプルとしてjarファイルを追加するような方法の記載が明確にはありません。\n19ページのcollection1の説明ですこしだけ、libディレクトリについて触れています。\n独自のTokenizer（lucene-gosenなど）はjar形式でSolrに追加し、schema.xmlなどに利用するFactoryを指定してから利用します。\nこのとき、追加のjarファイルを配置する先がlibディレクトリです。\nlibディレクトリは2つの種類のスコープのディレクトリが存在します。\nSolr全体で利用可能なlibディレクトリ コア単位で利用可能なlibディレクトリ Solr全体で利用するlibディレクトリ これは、起動しているSolrにある全てのコアで利用するようなjarファイルを配置するディレクトリになります。 場所は$SOLR_HOME/libです。ここにjarファイルを配置することで、この$SOLR_HOMEを利用するすべてのコアで同じjarファイルを利用することができるようになります。\nですので、例えば、lucene-gosenはすべてのコアで利用するという場合にはここに配置すれば、1つのjarファイルを配置するだけで済むことになります。\nコア単位で利用するlibディレクトリ これは、コアごとにlibディレクトリを用意する場合です。 19ページにも記載されていますが、$SOLR_HOME/コアディレクトリ名/libとなります。\n特定のコアのみで利用するライブラリについてはこちらに配置する形になります。 他のコアで利用してほしくないjarファイルなどを配置するのに利用すればよいかと。\n簡単ですが、補足記事でした。 UIMAやlangidの利用方法などもあるとうれしですかね？ そのうち気が向けば書くかもしれません。（他の人に書いてもらうのもありかも。）\n","date":1387447740,"dir":"post/2013/","id":"cb5b6f7ab4d36e90d2619cb907ebb956","lang":"ja","lastmod":1387447740,"permalink":"https://blog.johtani.info/blog/2013/12/19/add-jar-file-to-solr/","publishdate":"2013-12-19T19:09:00+09:00","summary":"Solr本が出てから、質問を受けてブログ書くと言いながら書いてなかったことを思い出しました。。。 プラグインの配置方法についてこんな質問を受け","tags":["Solr"],"title":"Solrへのプラグインの配置方法について"},{"contents":"ども。 プラグインのインストールに長いURL入れるの辛いですよね？ね？\nということで、MavenでリリースしてMaven Repositoryからダウンロードできるようにしてみました。\n流れとしては\nSonatypeにリリースできるように申請する Sonatypeにリリースする SonatypeからMavenにSyncしてもらう という流れです。\nSonatypeにリリースするための方法はイケメンの人(@yusuke)がブログに簡単ですが残してくれてました。 あと、こちらの@vvakameさんのブログも参考にしながら作業しました。\n【最新版】Maven Central Repository へのライブラリ登録方法 #maven JsonPullParser が Maven Central Repository に入るようです pom.xmlについては、プラグインのpom.xmlを参考にしてもらえればと。 1.の作業が終わったら、リリースを実行します。\nこの時、\u0026lt;scm\u0026gt;タグにgithubの情報が記載されているため（？）、githubにタグを打つ作業もmavenコマンドがやってくれるみたいです。\nmvn release:prepare を実行すると、リリースするバージョンやタグ名などを聞いてくれます。 それらに答えると、pom.xmlにバージョンを指定してcommit\u0026amp;pushしてくれ、タグも打ってくれます。（なんて便利）\nその後、release:performにてSonatypeへのリリースが完了します。 あとは、Sonatypeの画面で作業したら、Mavenのリポジトリにそのうち同期してくれます。\nということで、次のコマンドを実行すればプラグインがインストールできるようになりました。0.6.0と0.7.0の違いは実装には差異はありません。リリース方法が変更されただけということになります。\nbin/plugin -i info.johtani/elasticsearch-extended-analyze/0.7.0 これで少しは活用してもらえるようになるかなぁ？ （どのくらいの人が使ってくれてるのかは不明。。。）\n","date":1387249860,"dir":"post/2013/","id":"a0a00c23556fcc5dbfb7b7f43fbbb61d","lang":"ja","lastmod":1387249860,"permalink":"https://blog.johtani.info/blog/2013/12/17/release-es-extended-analyze-plugin-to-maven-and-sonatype/","publishdate":"2013-12-17T12:11:00+09:00","summary":"ども。 プラグインのインストールに長いURL入れるの辛いですよね？ね？ ということで、MavenでリリースしてMaven Repositoryから","tags":["elasticsearch"],"title":"elasticsearch-extended-analyzeプラグインをMavenとSonatypeにリリース"},{"contents":"少し遅くなってしまいましたが、12/05に電子書籍も発売されました。\n技術評論社の電子書籍サイトから購入可能です。\n書籍のページへのリンク PDF版となっております。 購入の際は、技術評論社の電子書籍サイトに会員登録後購入可能となります。\n個人的には電子書籍が便利なので、こちらを普段活用しようと思っています。\nもちろん、紙の書籍も発売中です！購入の際は右の書影をクリックしていただければと！\n","date":1386554880,"dir":"post/2013/","id":"d9560caeb797b302191f667b4264da40","lang":"ja","lastmod":1386554880,"permalink":"https://blog.johtani.info/blog/2013/12/09/release-introduction-solr-ebook/","publishdate":"2013-12-09T11:08:00+09:00","summary":"少し遅くなってしまいましたが、12/05に電子書籍も発売されました。 技術評論社の電子書籍サイトから購入可能です。 書籍のページへのリンク PDF","tags":["Solr"],"title":"改訂版Solr入門のPDF版も発売"},{"contents":"勉強会で宣伝もしましたが、改めて。\nSolr入門の改訂版を執筆しました。 考えてみれば、もう3年も前なんですね、Solr入門は。 Solr勉強会などでも何度も新しいのは出ないのですか？と聞かれていましたが、やっと出ました。（お待たせしました。）\n時が立つのは早いものです。前回のSolr入門はバージョン1.4にて執筆していましたが、今回は4.4をベースにし、4.5.1への対応を行っています。\n月曜日には手元に見本が届き、今週金曜日に発売予定です！\nSolrCloud、SoftCommit、Spatial、Joinなど、多彩な機能についても記載してあります。 また、ManifoldCFというSolrにデータを登録するのに 利用できるコネクタフレームワークについても書いてあります。\nより多彩になったSolrの機能を活用するための一助となれればと思います。 （電子版も出る予定です。詳細についてはもう少々お待ちください）\nまた、出版を記念して少し時期が先になりますが、Solr勉強会を開催しようと思います。\n日時：2014年01月29日 第13回Solr勉強会 #SolrJP 新Solr本出版記念 今回はせっかくのSolr入門の書籍の出版記念ということで入門的な話をしてもらう予定です。 Solr初心者の方、Solrに興味のある方などに来ていただきたいと思っています。 （プレゼントも用意できるかも！？）\nということで、「改訂版Apache Solr入門」をよろしくお願いします。 （もちろん、購入は下のリンクからですよね！）\n","date":1385436420,"dir":"post/2013/","id":"a2012a3c9cdb1d6fd69afdbadc1e76b6","lang":"ja","lastmod":1385436420,"permalink":"https://blog.johtani.info/blog/2013/11/26/introduction-to-solr-new-edition/","publishdate":"2013-11-26T12:27:00+09:00","summary":"勉強会で宣伝もしましたが、改めて。 Solr入門の改訂版を執筆しました。 考えてみれば、もう3年も前なんですね、Solr入門は。 Solr勉強会な","tags":["Solr"],"title":"改訂版Solr入門を執筆しました"},{"contents":"どーも。以前の記事で開発中としていたプラグインですが、とりあえず、pluginコマンドでインストール出来る形にしてみました。\nインストールなどについては、READMEに記載したのでそちらを参照してもらうことにして、試行錯誤した話をメモとして残しておきます。\nプラグインの開発はしいてたのですが、やっぱりpluginコマンドでインストール出来ないと使ってもらえないよなということで、勉強会も終わったのでちょっと調べてました。\nプラグインコマンド コマンドが用意されてますが、実態はJavaで実装されてて、通常はこんなかんじでプラグインをインストールします。\n./bin/plugin -i elasticsearch/elasticsearch-analysis-kuromoji/1.6.0 この「elasticsearch/elasticsearch-analysis-kuromoji/1.6.0」という文字列ですが、「ユーザ名/リポジトリ名/バージョン」という意味になります。\nで、ダウンロードするURLは以下のものの中から選ばれます。\nelasticsearch.orgのダウンロード用サイト search.maven.org oss.sonatype.org Githubのarchive これらのサイトに先ほどのユーザ名、リポジトリ名、バージョンを利用したURLを組み立てて、ダウンロードしてくれるという仕組みになっています。\nelasticsearch.orgについては、本家の人しかアップロードできないと思うので、なし。\nmaven、sonatypeについては、Mavenのリポジトリにリリースする必要があるんじゃないかなと。 で、昔調べてググって途中で挫折したんですが、挫折してます。手順が結構手間で。。。 （参考記事：【最新版】Maven Central Repository へのライブラリ登録方法 #maven）\nということで、Githubにアップしたらなんとかなるんじゃん？ということで色々と調査して試してみました。（結果はイマイチなんですが。。。）\nその１：mvn release:prepare せっかくGithubだし、せっかくMavenなんだしなんか、pom.xmlに便利な設定したらコマンド一発でリリースできるんじゃない？という甘い気持ちで調査したググったらそれっぽい記事が見つかりました。 「MavenとGitHubの連携」って記事です。\nで、pom.xmlの設定にも他のプラグインを真似してコピペしたものに\u0026lt;scm\u0026gt;ってタグがあったなぁと。このコマンドでついでにGithubにアップロードできるんじゃないの？ということで、試してみました。\nmvn release:prepare このコマンドを叩くと、記事にあるとおりにいくつか質問をされます。 タグについては、プロジェクト名-バージョン番号という文字列がデフォルトだと指定されているので、v0.5と変更して実施してみると、Githubのreleaseにv0.5ってのができてるじゃないですか。\n※pluginコマンドはGithubを見に行く時に次のファイルをダウンロードしに行きます。\nhttps://github.com/ユーザ名/リポジトリ名/archive/vバージョン名.zip やった！と思い、早速pluginコマンドを実行してみましたが、エラーが出ました。。。\nTrying https://github.com/johtani/elasticsearch-extended-analyze/archive/v0.5.zip... Downloading ...DONE Installed johtani/elasticsearch-extended-analyze/0.5 into /Users/johtani/projects/tmp/ess_env/second_node/elasticsearch-0.90.7/plugins/extended-analyze Usage: -u, --url [plugin location] : Set exact URL to download the plugin from ...省略... Message: Error while installing plugin, reason: IllegalArgumentException: Plugin installation assumed to be site plugin, but contains source code, aborting installation. あらら、なんで？と。\nで、実際にgithubにアップされてたzipファイルをダウンロードしてみたら、githubのリポジトリにあるディレクトリ構成がそのまま入ってるじゃないですか。。。 そうですか、そうですよね。prepareだし、タグ打ってzipにかためてくれるだけなんですねと。。。\nおそらく、siteプラグインだけの場合はこの方法でpluginコマンド叩けばOKなんでしょうが、私がダウンロードしてもらいたいのは.jarファイルが入ったzipファイルなんです。\nということで、断念しました。（タグ消したりをgitコマンドで叩いて綺麗にし直すとか虚しい作業をしてました）\nその２：github.comのWebでリリース おとなしく、Sonatypeのサイトにアップロードする方向でがんばればいいんですが、とりあえず使えるようにするのが先だと思い、 github.comのページでアップロードしてしまおうと。\n「release」というタブをクリックすると、画面からアップロードできるようになります。\nzipファイルを作ってアップロードしました。（zipファイル自体はmvn packageコマンドを実行したらtarget/releaseというディレクトリに作成されてる）\nこれで行けるだろということで、またpluginコマンドを実行すると\nTrying https://github.com/johtani/elasticsearch-extended-analyze/archive/v0.5.zip... Downloading ...DONE Installed johtani/elasticsearch-extended-analyze/0.5 into /Users/johtani/projects/tmp/ess_env/second_node/elasticsearch-0.90.7/plugins/extended-analyze Usage: -u, --url [plugin location] : Set exact URL to download the plugin from ...省略... Message: Error while installing plugin, reason: IllegalArgumentException: Plugin installation assumed to be site plugin, but contains source code, aborting installation. あれ？同じエラー？なんで？jar入りのzipファイルアップロードしたのに？？？\nと。で、https://github.com/johtani/elasticsearch-extended-analyze/releasesにreleaseのページができてたので見てみると、あら。 アップロードしたファイルについては次のようなURLになってるじゃないですか。\nhttps://github.com/johtani/elasticsearch-extended-analyze/releases/download/v0.5/v0.5.zip で、よく見ると「Source code(zip)」というボタンもあるぞ？このリンクは？\nhttps://github.com/johtani/elasticsearch-extended-analyze/archive/v0.5.zip 。。。あぁ。そうですか。そういうことですか。理解してない私が悪いんですねと。\n結論？ ということで、とりあえず、releaseにjar入りファイルはアップロードできた（手動で）ので -uオプションで直接URL指定すればインストールできるだろ！と諦めました。 いい勉強になりました。。。\nREADME見ていただくとインストール方法が分かりますが、長いです。。。\n時間をとって本腰入れてSonatypeにMavenコマンドでアップロードできるようにしようかな。。。\n","date":1384419300,"dir":"post/2013/","id":"13684d16fdd07d5f0584e29265a270e7","lang":"ja","lastmod":1384419300,"permalink":"https://blog.johtani.info/blog/2013/11/14/release-elasticsearch-extended-analyze-0-dot-5/","publishdate":"2013-11-14T17:55:00+09:00","summary":"どーも。以前の記事で開発中としていたプラグインですが、とりあえず、pluginコマンドでインストール出来る形にしてみました。 インストールなど","tags":["elasticsearch","plugin"],"title":"elasticsearch-extended-analyzeを公開？"},{"contents":"第2回を開催しました！ すごい、140人くらいくらいの参加登録者（参加者は１００人ちょっと！）がいて、びっくりです。 ステキな会場を提供していただいた、リクルートテクノロジーズさん、運営していただいた方々、スピーカーの皆さん、参加者の皆さん本当にありがとうございました。 今回も素敵な看板ありがとうございます。\n今回もしっかり楽しめたので、次回も頑張ります！\n今回は、elasticsearch-jpMLの紹介とかをできたのでよかったかなぁと。 ぜひ、活用してください！どんな質問でもいいので。\nあと、スライドに入ってた例の本もよろしくです。\nということで、懇親会も盛り上がったし楽しかったです。 今後も場の提供＋自分の勉強のトリガーとして、開催していくので、ご協力お願いします！ 聞きたい話など、MLや@ツイートしていただければと。\nelasticsearchのRouting機能：株式会社シーマーク　大谷　純　（@johtani） スライド：Routing機能※スライドはPDFです。\nド緊張で、大した発表ではなかったですが。。。 どちらかと言うとSolr本の紹介だったかもなぁ。スミマセン。\n※スライドが一部文字が消えてるので、作りなおすかも。\nElasticSearchを使ったBaaS基盤の開発(仮)：株式会社富士通ソフトウェアテクノロジーズ 滝田聖己さん（@pisatoshi） スライド：https://speakerdeck.com/pisatoshi/elasticsearch-trial-and-error\n本日はお越しいただきありがとうございました！しかも静岡から！今後もよろしくお願い致します。\nEnchantMoonでシステム構成ｗ\n0.17.0から利用されていると。（スゴイ）\nプライマリのデータストア！ただし、登録元データはMySQLにもある。\n階層も深く、大きめのドキュメント。\nレプリカ１、インデックスのバックアップも取ってないと。。。\nルーティングの機能\nDynamicMappingの問題点\nマッピング定義が肥大、型がコンフリクト。。。苦労しっぱなし\nデータ登録は１台にして、１台で一気に登録してから再配置\n実際に運用とかされてるので、いろんなノウハウがまだまだありそう！\nKibana入門：水戸祐介さん（@y_310） スライド：https://speakerdeck.com/y310/kibanaru-men\n（やっぱりru-menになってるｗ）\n実は、押しかけて話してもらうように説得したのでした。今後もよろしくです。\nCOOKPADの方によるKibanaのお話。 Kibanaの利点とかなんで？とか。 画面構成の説明から ダッシュボードは必ず保存して！リロードしたら悲しい思いをしてしまうので。 sparkline便利そうだなぁ。ほんとに、データサイエンティスト系のツールを目指してるのかな 一通り、ダッシュボードに配置できるパネルの説明してもらえたのですごく参考になりました！ Tips周りが役に立ちそう。not_analyzedは重要ですよね。 LT 「データ集計用ダッシュボードブラウザとしても使えるElasticSearch＋Kibana v3を利用する際の運用ノウハウ紹介」：株式会社リブセンス Y.Kentaro さん (@yoshi_ken) さん スライド：http://www.slideshare.net/y-ken/elasticsearch-kibnana-fluentd-management-tips\nKibanaの紹介とかFluentdの紹介。 Tips満載すばらしい。 JDBC riverは0.90.6ではうまく動かないので、気をつけてと。 「Fluentd as a Kibana」：@repeatedly さん スライド(gist)？：https://gist.github.com/repeatedly/7427856\nKibanaがfluentdの中で動くと！？\n「Authプラグインでアクセスコントロール」：株式会社エヌツーエスエム 菅谷信介さん (@shinsuke_sugaya) スライド：http://www.slideshare.net/shinsuke/es-auth-plugin\nAPI毎？インデックスごと？にアクセス制御ができるプラグイン\n","date":1384247760,"dir":"post/2013/","id":"66f43ab4b823d67f52735bbbe6ba65b0","lang":"ja","lastmod":1384247760,"permalink":"https://blog.johtani.info/blog/2013/11/12/elasticsearch-japan-user-meetup-no2/","publishdate":"2013-11-12T18:16:00+09:00","summary":"第2回を開催しました！ すごい、140人くらいくらいの参加登録者（参加者は１００人ちょっと！）がいて、びっくりです。 ステキな会場を提供していた","tags":["elasticsearch","kibana","fluentd","勉強会"],"title":"第2回elasticsearch勉強会を開催しました！ #elasticsearchjp"},{"contents":"Cloudera World Tokyo 2013に参加してきました。\n午前中はあいにくの雨でしたが、それでも結構な人数が最初の基調講演から参加されてました。 私が参加したセッションは大盛況な感じでした。\nおみやげとしてカステラも頂いちゃいました！\nまた、色々なセッションに現れたこんなメッセージ画像も見つけました！\n昨日の写真データの整理をしていたら、こんなものが・・・ @shiumachi さんよ・・・ #cwt2013 pic.twitter.com/S0JsxSYXIx\n\u0026mdash; Kenichiro HAMANO (@hamaken) November 8, 2013 やっぱり、スーツの人が多いなという印象。\n名刺を毎回回収されるのはちょっとつらかったです。なにか、いい方法ないですかねぇ。\n以下はいつもの個人メモです。\n「ビッグデータプラットフォームとして進化するHadoop」 Cloudera株式会社　代表取締役　ジュセッペ小林氏 Costcoなどの写真を元にビッグデータを可視化 BigDataとHadoopの関係 検索、SQL、機会学習、数理処理、データ管理などにもHadoopの活用されつつある。 セキュリティ、データ管理、クラスタ上でのツールの実行なども増えてきてる。\n「今日ビッグデータは明日のスモールデータ」\nアーキテクチャとしてのビッグデータ 多種多様なデータを一箇所に集約し、生データを直接活用できる。 OSSとしての責任も。\nデータサイエンス Opsだけでないデータ解析にも活用\n「Clouderaのビッグデータプラットフォーム戦略」（仮） 講師：Cloudera, Inc. CTO Dr.Amr Awadallah レガシーな情報アーキテクチャ→スケールできない、可視化の限界、硬直したスキーマなどなど。\nエンタープライズデータハブとしてのHadoopとか。\nビッグデータの歴史と将来展望 講師：国立情報学研究所　アーキテクチャ科学研究系　教授　佐藤一郎氏 ビッグデータの歴史的経緯とか 最初の事例はアメリカの1880年国勢調査。\n「ビッグデータがコンピュータを生み出した」。コンピュータがビッグデータを生み出したんじゃない。\n少量データにもHadoopを\nバッチ処理のリアルタイム化とか（一晩から10分へ） 原点は検索データのインデクシング\nHadoopを使うのが目的じゃないんだから、構築には手を掛けないのがいいよね。\nプラットフォームと発展している\n分散システム研究者から見たHadoop 分散ししテムの難しさを、処理範囲を限定することで巧みに回避 データの近くで処理 研究レベルではリアルタイム化や逐次処理化が活発 全工程で逐次・リアルタイムが必要とは限らない 聞いてばかりじゃなくて、動かしてみましょう。 データサイエンス：超並列分散処理を活用した新たなビジネス価値の創出 講師：アクセンチュア株式会社　工藤卓哉氏 「日経BPのビッグデータ総覧2013」に記事書いてる。 多様化するデータ（社外のデータも）をどうやってうまく活用していくか。 データが教えてくれたこと→まず、データありき、まずデータためましょう。それから解析とかすればいいのでは？というはなし？ 競合他社さんはNGだけど、ブースでデモ？実機？が見れますと。 Hadoopデータプラットフォーム Cloudera株式会社　嶋内　翔氏 まずは宣伝 Cloudera Implaraのフリーブックの日本語版 Hadoop Operationの書籍でるよ プラットフォームを構成するもの Flume Sqoop HBase Hive Impala データ登録してBIアナリストのお仕事にどうやって役立てる？ 外部テーブル：Hiveからはテーブルのように見える仕組み。元ファイルは消えない SerDe（さーでぃー）：データをHiveレコードに変換する仕組み 生データを少し加工しましょう 圧縮したりファイル結合したりはしときましょう。 Hadoop活用のポイント 富豪的プログラミング。リソースケチるな。 ローカルでできることはローカル。むりにHadoopでやんなくてもいいですよねと。バランス重要 スケジューリング実行などはOozie使うと便利。（日次集計とか） Cloudera Searchで元データにインデックス貼れるぞと。検索しながら分析ができる クラスタ管理とか Cloudera manager便利ですよ ストレージリソースの管理。 声掛け、管理者が容量チェック、Cloudera Managerのレポート 少数精鋭でHadoop使おう＝手が回らなくなる。 みんなで使おう＝Kerberos認証とか管理をちゃんと考えないと。けど、文化が根付けば強力。Sentry、Cloudera Navigatorとか。 Hadoopシステムの全体構成図。データの流れと各製品のつながり。 We are hiring!ということで、興味のある方は@shiumachiさんにコンタクトをとりましょうとのこと。 SQLで実現するバッチ処理とストリーム処理 LINE株式会社　田籠 聡氏 資料：Batch and Stream processing with SQL\nLINEのキャラがちらほら出てきた。\nSQL好きですか？\nログの量とか。2.1TB/Day\nバッチ処理とストリーム\n速い集計のためにHadoopが重要 エラー系のログとかはストリームで処理したい\nアーキテクチャ説明\nデータ解析する人って色々。\n管理者 プログラマ サービスディレクタ 経営陣 みんなが集計用処理を理解、編集ができるほうがいい。\n顔あげたらHiveアイコンだらけだったｗ\nShibとか。\nなんでHiveに限るの？\nHiveに着目したバージョンアップだけを考えれば良くなる。 スケジュールクエリが増えてきて、つらい。\nTimeWindowを固定して集計処理をすることで、回避できる。 Norikra!! スキーマレス\nOSS。Esperベース。\nインストールが楽\nクエリの動作のお話。\nhttp://norikra.github.io\nWe Are Hiring!\nHadoop コミュニティと YARN の現状 日本電信電話株式会社　小沢 健史氏 なんでHadoop？ PostgreSQLでやってたけど、大きなデータにはHadoopを使おうという感じになってきた。 なんで使い分けるの？ スキーマ後付け NTTDocomoのモバイル位置情報の統計処理とか？ 技術的な話をするので、HiveTに着替えます！ｗ YARNのなにが嬉しいの？ ImpalaとMapReduceが同時に動くような環境の時に、リソースをうまく管理できないのがV1 そこでYARN Apache Mesosとだいたい一緒。 Apache MesosとYARNの比較 ","date":1383786660,"dir":"post/2013/","id":"a106d7c1b1b277538367f9c8140e3a75","lang":"ja","lastmod":1383786660,"permalink":"https://blog.johtani.info/blog/2013/11/07/cloudera-world-tokyo-2013/","publishdate":"2013-11-07T10:11:00+09:00","summary":"Cloudera World Tokyo 2013に参加してきました。 午前中はあいにくの雨でしたが、それでも結構な人数が最初の基調講演から参加されてました。 私が参加したセッショ","tags":["Cloudera","Hadoop","Norikra"],"title":"Cloudera World Tokyo 2013に参加しました！ #cwt2013 "},{"contents":"またまた、Riak Meetup Tokyo #3に参加してきました。Riak2.0のYokozunaの話があると聞いたので。\nということで、いつものように個人メモです。\n今日は自重して、懇親会はアルコールなしにしました。思いがけずfluentd＋elasticsearch+kibanaという組み合わせの話も聞けて大満足です。 Yokozunaのデモが見れなかったのがちょっと残念だったかなぁ。\n少しだけSolr本の宣伝もしてきちゃいました。\n古城さん@Mixi 「RiakCSとmixi プライベートクラウド環境」 プライベートクラウドとは？ 計算リソースが安い（ストレージは微妙） 開発者が好きに使える環境＋運用側のチケットに追われる毎日からの開放 Riak CSの概要 S3互換の分散ファイルストレージ 検証とか 検証時はRiak CS 1.3\n5ノードで2Mファイルを40万個\n削除は遅延で削除される\nPUT性能とか。\nRiak CSの死活監視にはRiakのstatsとか\n障害対応とか\nクラスタ クラスタは3つ。ログ、サービス（画像） 、バックアップ保存用 ログの収集にfluentd、解析にelasticsearchやkibanaを使っているらしい。 篠原＠Basho 「Riak 2.0: 分散データ型、セキュリティ、そしてより容易な運用へ」 riak 2.0 pre5をリリース アプリ向け機能強化、運用の容易性 設計ポリシーとか、1.xとか 運用、高可用性、水平拡張性 Capabilityネゴシエーションとか 2.0の機能強化 バケットタイプ キーの名前空間としてバケットがあったけど、同種のバケットをまとめて管理とかしたくなった。 データ型の導入（CRDT） Setデータ型 セキュリティとか 強い整合性\u0026hellip; 鈴木@Basho 「Yokozuna: Riak 2.0の新しい全文検索機能」 YokozunaやSolrの概要 1ノードにRiakとSolrが1プロセスずつ SolrプロセスはRiakが管理してくれる SolrCloudは使ってません。 Riakのノードに届いたデータをSolrに裏で書き込んでくれる。 検索時にはRiakのノードが分散検索をしてくれる X-Riak-Metaもインデクシングしてくれる。jsonやxmlの各要素をSolrのフィールドとして認識してくれる。 Extractor Solrは4.4で、JVMは1.7をユーザが入れるらしい。\n","date":1383746460,"dir":"post/2013/","id":"9dca844d353efed03fbaddfc0fab7c76","lang":"ja","lastmod":1383746460,"permalink":"https://blog.johtani.info/blog/2013/11/06/riak-meetup-tokyo-no3/","publishdate":"2013-11-06T23:01:00+09:00","summary":"またまた、Riak Meetup Tokyo #3に参加してきました。Riak2.0のYokozunaの話があると聞いたので。 ということで、いつものように個人メモで","tags":["Riak","Yokozuna"],"title":"Riak Meetup #3 #riakjp に参加しました。"},{"contents":"開発中ですと書きました、elasticsearch-extended-analyzeですが、改良しました。\n改良と変更は以下のとおりです。\nソースのパッケージをorg.elasticsearchからinfo.johtaniに。MLで気になったので質問したら、変えたほうがいいよとのこと。ダウンロード化については、もう少々お待ちを。 出力形式を変更。可能な限りCharFilter、Tokenizer、TokenFilterそれぞれが出力する内容を返すようにしました。 ただし、既存のAnalyzer（JapaneseAnalyzerクラスとか）に関しては、現時点では出力しません。CharFilterなどを取得するI/Fが見えないためです。（改良できるかの調査は未着手） 現時点でできてないのは以下の項目\npluginコマンドでインストール 出力したいAttributeの指定 TokenizeChainで変更されたTokenの追跡（現状はどのTokenがStopFilterで消されたかなどが不明） 画面の用意（簡単に確認できる画面） ということで、README.mdに出力サンプルは貼り付けてるので、興味のある方は試してみてください。 不明点などあれば、コメントかIssueかツイートでも。\n","date":1383570720,"dir":"post/2013/","id":"b5c628b0c1dbf857a475c4be5de4690d","lang":"ja","lastmod":1383570720,"permalink":"https://blog.johtani.info/blog/2013/11/04/improve-output-extended-analyze/","publishdate":"2013-11-04T22:12:00+09:00","summary":"開発中ですと書きました、elasticsearch-extended-analyzeですが、改良しました。 改良と変更は以下のとおりです。 ソー","tags":["elasticsearch","plugin"],"title":"elasticsearch-extended-analyzeの改良"},{"contents":"お久しぶりです。 気づいたらまた、結構ブログを書いてなかったです。。。\n今回は、今開発しているElasticsearchのプラグインに関するお話です。\nいやぁ、名前決めるの難しいですね。これで英語的に合ってるか不安ですが、elasticsearch-extended-analyzeというプラグインを作っています。\nどんなもの？ Solrの管理画面のanalysisに相当する機能が欲しくて作り始めました。\nElasticsearchにはanalyze APIというAPI（名前あってるのかなぁ?）が存在します。\nこれは、文字列を投げると、指定したアナライザやトークナイザでどのようなトークンに分割されるかを調べることができるAPIです。\n例えば、elasticsearch-analysis-kuromojiをインストールしたElasticsearchに対して、以下のcurlコマンドを実行します。\ncurl -XPOST \u0026#39;localhost:9200/_analyze?tokenizer=kuromoji_tokenizer\u0026amp;filters=kuromoji_baseform\u0026amp;pretty\u0026#39; -d \u0026#39;寿司が美味しい\u0026#39; すると、トークナイズされた結果が次のようなJSONで返ってきます。\n{ \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;寿司\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 2, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 1 }, { \u0026#34;token\u0026#34; : \u0026#34;が\u0026#34;, \u0026#34;start_offset\u0026#34; : 2, \u0026#34;end_offset\u0026#34; : 3, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 2 }, { \u0026#34;token\u0026#34; : \u0026#34;美味しい\u0026#34;, \u0026#34;start_offset\u0026#34; : 3, \u0026#34;end_offset\u0026#34; : 7, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 3 } ] } トークナイズの結果がわかるのは嬉しいのですが、どんな品詞なのかといったKuromoji固有のTokenの属性情報がなくなってしまいます。\nSolrでは、こんな画面が用意されていて、品詞情報とかが出力されます。あとは、各TokenFilterでどのトークンがなくなっているかなどもわかるようになっています。\nこれって結構役立つと思うんですよ。 ということで、Pluginも作ってみたかったので、いい機会だから作ってみようかと。\n出力サンプル まずは、その他のAttribute（品詞とか）を表示するところを実装してみました。\ncurl -XPOST \u0026#39;localhost:9200/_extended_analyze?tokenizer=kuromoji_tokenizer\u0026amp;filters=kuromoji_baseform\u0026amp;pretty\u0026#39; -d \u0026#39;寿司が美味しい\u0026#39; 先ほどとほぼ一緒のcurlコマンドを実行します。違う点は**「_analyze」が「_extended_analyze」**となっている点です。\nで、実行結果はこんな感じです。（長いですがそのまま載せてます。続きの文章がしたにあります。）\n{ \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;寿司\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 2, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 1, \u0026#34;extended_attributes\u0026#34; : [ { \u0026#34;org.apache.lucene.analysis.tokenattributes.TermToBytesRefAttribute#bytes\u0026#34; : \u0026#34;[e5 af bf e5 8f b8]\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.PositionLengthAttribute#positionLength\u0026#34; : 1 }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.BaseFormAttribute#baseForm\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech\u0026#34; : \u0026#34;名詞-一般\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech (en)\u0026#34; : \u0026#34;noun-common\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading\u0026#34; : \u0026#34;スシ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading (en)\u0026#34; : \u0026#34;sushi\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation\u0026#34; : \u0026#34;スシ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation (en)\u0026#34; : \u0026#34;sushi\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType (en)\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm (en)\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.KeywordAttribute#keyword\u0026#34; : false } ] }, { \u0026#34;token\u0026#34; : \u0026#34;が\u0026#34;, \u0026#34;start_offset\u0026#34; : 2, \u0026#34;end_offset\u0026#34; : 3, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 2, \u0026#34;extended_attributes\u0026#34; : [ { \u0026#34;org.apache.lucene.analysis.tokenattributes.TermToBytesRefAttribute#bytes\u0026#34; : \u0026#34;[e3 81 8c]\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.PositionLengthAttribute#positionLength\u0026#34; : 1 }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.BaseFormAttribute#baseForm\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech\u0026#34; : \u0026#34;助詞-格助詞-一般\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech (en)\u0026#34; : \u0026#34;particle-case-misc\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading\u0026#34; : \u0026#34;ガ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading (en)\u0026#34; : \u0026#34;ga\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation\u0026#34; : \u0026#34;ガ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation (en)\u0026#34; : \u0026#34;ga\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType (en)\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm (en)\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.KeywordAttribute#keyword\u0026#34; : false } ] }, { \u0026#34;token\u0026#34; : \u0026#34;美味しい\u0026#34;, \u0026#34;start_offset\u0026#34; : 3, \u0026#34;end_offset\u0026#34; : 7, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 3, \u0026#34;extended_attributes\u0026#34; : [ { \u0026#34;org.apache.lucene.analysis.tokenattributes.TermToBytesRefAttribute#bytes\u0026#34; : \u0026#34;[e7 be 8e e5 91 b3 e3 81 97 e3 81 84]\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.PositionLengthAttribute#positionLength\u0026#34; : 1 }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.BaseFormAttribute#baseForm\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech\u0026#34; : \u0026#34;形容詞-自立\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech (en)\u0026#34; : \u0026#34;adjective-main\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading\u0026#34; : \u0026#34;オイシイ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading (en)\u0026#34; : \u0026#34;oishii\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation\u0026#34; : \u0026#34;オイシイ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation (en)\u0026#34; : \u0026#34;oishii\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType\u0026#34; : \u0026#34;形容詞・イ段\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType (en)\u0026#34; : \u0026#34;adj-group-i\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm\u0026#34; : \u0026#34;基本形\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm (en)\u0026#34; : \u0026#34;base\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.KeywordAttribute#keyword\u0026#34; : false } ] } ] } 先ほどの結果に**「extended_attributes」**という配列のオブジェクトが追加された形になっています。 ちょっと長くなってしまいましたが。。。\nSolrの処理を真似して作ったので大したことはやってないんですが、少しは便利になるかもなぁと。\n現時点では、最終的な結果しか取得できないですが、今後は次のような機能を作っていこうかと思っています。 できるかどうかは、やってみてって感じですが。\npluginコマンドでインストール pom.xmlはありますが、まだMavenとかに登録はされていません。ですので、mvn packageしてからjarファイルをpluginsフォルダに配置しないといけません。pluginコマンドでインストールできるともっと使ってもらえるはず？ 出力したいAttributeの指定 リクエストパラメータで、出力したいAttribute名を指定するとか。 出力形式の変更 今は、Solrの真似をしていますが、せっかくJSONだったりするので、もう少し検討しようかと（同じAttributeの異なる値も1オブジェクトとして出力されてる） TokenizeChainの出力 Solr同様、CharFilter、Tokenizer、TokenFilterが動作して、最終的なTokenがインデックスに登録されます。ですので、各処理の直後のTokenがどうなっているかもわかったほうが嬉しいと思うので、それらも取得できるようにしたいなぁと 画面の用意 せっかくプラグインなんだし、画面で見れると嬉しいかなと。これは当分先になっちゃうと思いますが、Webページで確認できるような画面を作ると確認しやすくなるかなぁと。上記対応が終わってから取替かかると思いますが。 とりあえず、思いつくのはこんなかんじです。\nElasticsearchの_analyze APIを真似しただけのコードだし、テストも実装もまだまだですが、とりあえず公開してみました。\n要望などあれば、コメント、Issue、ツイート（もちろん、テストコードなども！）なんでも受け付けてますので、お気軽に。\n","date":1382695560,"dir":"post/2013/","id":"0302e8a57a5e8604342a925b2dc60737","lang":"ja","lastmod":1382695560,"permalink":"https://blog.johtani.info/blog/2013/10/25/developing-es-extended-analyze-plugin/","publishdate":"2013-10-25T19:06:00+09:00","summary":"お久しぶりです。 気づいたらまた、結構ブログを書いてなかったです。。。 今回は、今開発しているElasticsearchのプラグインに関するお話","tags":["elasticsearch","plugin"],"title":"elasticsearch-extended-analyzeプラグインを開発中"},{"contents":"不定期開催ですが第12回Solr勉強会を主催しました。\n今回は、前回ほどの過熱ぶりでは無かったですが、70人ほどの参加者の方がいらっしゃったかと。 ありがとうございます！\n今回は聞きたかったYokozunaの話をしてもらいました。あと、リベンジManifoldCF。 一部、追記しました。Bashoさんからツッコミがあったので。あと、4.5.1の話とか。\nManifoldCFのとSolrの組み合わせ（仮）株式会社 ロンウイット　大須賀　稔さん 前回お休みだったのでリベンジですw。\n英語だ。。。やっぱ英語がいいですか、スライド。。。\nManifoldCFの概要から。 最新版は1.3です。色々サポートしてるなぁ。\nデモもありました。（やっぱりちゃんと動かないので、鬼門みたいですが）\nデモ ManifoldCFのGUIで操作しながら。 いまいちちゃんと動かなかった。。。\nQA Q:Zipはうまく動かなかった A:Solr側で処理してくれてる。 Q:Notes対応するの？ A:いまのところない。 Q:ExcelとかPDFはTika？ A:Tika次第です。 Q:認証周りどこから取ってくるの？ A:クローラ側にはなくて、SharePointとかの権限をみてる。 Q:Web系の認証は？ A:まだないのでは。。。（調査します） あー、デモの続き忘れてましたね。。。\nSolrを組み込んだRiak 2.0の全文検索機能 -Yokozuna- Bashoジャパン株式会社　鈴木　一弘さん Riak色々使われてるよ！アングリーバードとか、Y!とか。 Riakで提供されている1機能としてのYokozuna。単独製品ではないですよと。\nRiakの説明。スケールするよ、いつでもRead/Writeできるよ、運用にフォーカスしてるよと。 マスターレスですよ。 Riak2.0のリリースは2013年末。Yokozunaもかな？\nダイナミックフィールド使ってるので、Yokozunaをonにするだけで簡単に使えるよ。\nRiakがSolrのプロセスを管理。\nインデックスの不整合の検知とかってどうやってるのかなぁ？ インデックス比較用のハッシュツリーをノード間でコピーしつつ検査してる。（Active Anti-Entropy）\n(デモには魔物がいるようだ。。。)\nQA Q:JSONの属性を元にしてフィールドにインデックス可能か？ A:可能です。IIJさんの発表で話が出ます。 Q:ProtocolBufferでSolrにアクセス可能？ A:そのうちできそうです。リリース時にはできるようになっています。 Q:コアのスワップは？スキーマの変更は？ A:事前に設定するのは可能。 Q:RiakのデータとSolrでデータがずれるってのはあるの？ A:可能性はありますが、極力ずれAAEで修復。 Q:復旧中のインデックスにアクセスが行かないようにする仕組みなどはある？ A:今はないです。 Yokozuna ベンチマークしました　株式会社インターネットイニシアティブ　曽我部　崇さん、田中 義久さん いいとこ取りで楽だなぁと。いうことで、試してみてます。 デモが動いてる。\nextractorでXMLやJSONをパースできる。 ベンチマーク結果。\nRiak Meetup Tokyo #2の時のQAも入ってるので助かります。素晴らしい。\nQA Q:スナップショットは両方取れるの？ A:Riakは取れますが、インデックスは今は無理です。 フォロー:0.8はYokozunaにボトルネックがあったので、0.9以降だともっと性能が出るはずですとのこと。また次回とかに発表してもらうのもありですかねぇ。 Solr 4.5の新機能など @johtani 発表資料のPDFです。\nツイート見てて誤解を招いたなと思ったのですが、7u40は4.5限定ではなく、すべてのバージョンと考えてください。 チケットを見ると分かりますが、影響バージョンの記載はありません。\n※あ、4.5のChangesを紹介しましたが、4.5.1が出るかも。このへんが困ってるらしいです。\nSOLR-5306: can not create collection when have over one config SOLR-5317: CoreAdmin API is not persisting data properly LUCENE-5263: Deletes may be silently lost if an IOException is hit and later not hit (e.g., disk fills up and then frees up) LT @haruyama さん 資料：http://haruyama.github.io/solr_20131009/#(1)\n記号が捨てられるTokenizer困るので、捨てないのを作ってみました。\nKuromojiの困ったこと。全角数字を分解しちゃう。→MappingCharFilterFactoryで全角から半角にしましょう。 lucene-gosenデフォで半角記号が未知語になってしまい、半角カナと混ざるので、記号を全角にしましょう。\n","date":1381372500,"dir":"post/2013/","id":"76e127a44931bfefab991be3dd7a08b7","lang":"ja","lastmod":1381372500,"permalink":"https://blog.johtani.info/blog/2013/10/10/solr-meetup-memo/","publishdate":"2013-10-10T11:35:00+09:00","summary":"不定期開催ですが第12回Solr勉強会を主催しました。 今回は、前回ほどの過熱ぶりでは無かったですが、70人ほどの参加者の方がいらっしゃったか","tags":["Solr","Riak","Yokozuna","ManifoldCF"],"title":"第12回Solr勉強会を主催しました。#SolrJP"},{"contents":"今日は、ElasticSearchのMLで見つけたelasticsearch-inquisitorプラグインの紹介です。\nElasticSearchはREST API形式で簡単にコマンドラインからいろいろな処理を実行できて便利ですが、 GUIがあったほうが楽なこともまた事実です。 今回紹介する、inquisitorプラグインもSiteプラグイン（Webブラウザでアクセスできるプラグイン）の1つです。 （ただし、ローカルにインストールしてローカルのElasticSearchにしか接続できませんが。。。）\nインストール プラグインですので、以下のコマンドでインストールが出来ます。インストール後はElasticSearchの再起動が必要です。\nbin/plugin -install polyfractal/elasticsearch-inquisitor ElasticSearch再起動後に、以下のURLにアクセスすればOKです。 ※ローカルでのみ動作可能なプラグインです。（内部で呼び出しているJSにlocalhostと記載があるため）\nhttp://localhost:9200/_plugin/inquisitor/#/ 何ができるの？ 自分の書いたQueryが正しく動作するかや、Analyzerによって文章がどのように、Term（Token）に分割されるかといった挙動をWebブラウザ上で確認することができます。用意されている画面は「Queries」「Analyzers」「Tokenizers」の3種類です。\nQueries クエリの確認、実行が可能な画面です。\n「Index」「Type」はプルダウンになっており、現在ElasticSearchに存在しているものが選択可能です。 その下のテキストエリアがクエリを入力する画面です。\nクエリを入力していると、入力しているクエリがValidかどうかをクエリのコンソール部分（右側上部）に表示してくれます。\n少し残念なことに、Tabを押すと、フォームのフォーカスが切り替わってしまうので、クエリを入力するのがちょっと面倒です。。。（私は通常の検索には、ChromeプラグインのSenseというものを利用してます。）\nクエリに問題がない場合は、「Query」ボタンを押すことで実際の検索が実行されます。 この時、画面真ん中のブルーのテーブル（内部で実行されるクエリ）の部分に、QueryがElasticSearch内部で解釈されたあとの、Luceneで実行されるレベルのクエリに変換されたクエリが表示されます。\nこれが便利です。JSONで記述したり、色々なタイプのクエリがElasticSearchでは実行できますが、望んだ形に単語が区切られているかなどを確認することができるため、非常に便利です。\nElasticSearchのQuery DSLではexplainをtrueにすることで、ヒットしたドキュメントのスコア計算に用いられた単語などがわかるのですが、そもそもヒットしないクエリの場合は、explainでは単語の区切られ方などがわかりません。\nその場合に、このプラグインで確認すると、想定と違う単語の区切られ方やクエリの造られ方がわかるかと思います。\nAnalyzers Analyzerによる文章のアナライズ結果の確認が出来る画面です。 ElasticSearchやSolrにあまり詳しくない場合、どんなAnalyzerが文章をどのように単語に区切って、転置インデックスのキーワードとして利用しているかがわからないと思います。\nこのAnalyzerが文章をどのように単語に区切っているかを確認することができるのがAnalyzers画面です。 こんなかんじの画面になります。\n一番上のテキストエリアが文章を入力する場所です。 文章を入力していくと、その下のテーブルの「Analyzed Text」の部分が変化していくのが分かります。 このグレーの単語が転置インデックスのキーワードとなります。\n予め用意されているAnalyzer以外に、用意されているTokenzier＋Filterの組み合わせも簡単ですが確認可能です。（Tokenizer、Filtersとあるテーブル） ただし、ここまでのどちらも細かな設定は画面上ではできません（Filterの細かな引数の指定など）\n一番下の部分が、ElasticSearchに存在しているインデックスごとに定義されたAnalyzerやフィールドを元にした解析結果を表示することができる領域です。\n自分でマッピングを記述してフィールド定義したものの動作確認や、インデックスを適当に作ったけど、うまくヒットしない場合など、ここで、単語の区切れ方を確認することで、検索になぜヒットしないのかといった問題のヒントを得ることができると思います。\nAnalyzerによっては、インデックス対象の文字として扱わない文字があったりしますので。 先ほどのQueries画面のLuceneに投げられる直前のクエリと、Analyzersでの単語の区切られ方を確認することで、検索がうまくヒットしていないことが判明すると思います。\nTokenizers 最後はTokenizers画面です。Analyzersとほぼ同様ですが、ちがいは、デフォルトで用意されているTokenizerの挙動の確認ができるというだけになります。\n簡単な確認ならここで可能かと。\n注意点は？ まだ開発途中のようで、つぎの部分が課題かと。\nローカルでのみ実行可能 Queries画面の結果の「Explain Result」リンクが未実装 Queries画面のクエリ入力が使いにくい（タブが打てないので） カスタム登録のAnalyzersはインデックスを用意しないと確認できない。（Kuromojiのプラグインを登録しただけでは確認できなかった） 細かな設定のフィールドも用意しないと、Analyzers画面では利用できない まとめ ということで、Inquisitor（読みがわからない）プラグインの簡単な説明でした。 検索にうまくヒットしないという理由は大体の場合、 クエリに入力した文字列が単語に区切られたものと、登録したデータが単語に区切られたものが異なるために検索にヒットしないというものです。\nそのクエリ、データの単語の区切られ方を確認するのに役に立つプラグインじゃないでしょうか。\nちなみに、このプラグイン自体はHTML＋JSで作成されており、実際にはElasticSearchが持っているREST APIをキックしているだけになります。 ですので、Web画面なんか要らないという方は、このプラグインが実際に送信しているリクエストを参考にするとcurlコマンドでどういったリクエストを投げればいいかというのがわかると思います。\n私は軟弱者なので画面があったほうがいいですが。\n","date":1379906820,"dir":"post/2013/","id":"e1870dde155be1a375f155dd1f7ead13","lang":"ja","lastmod":1379906820,"permalink":"https://blog.johtani.info/blog/2013/09/23/intro-elasticsearch-inquisitor/","publishdate":"2013-09-23T12:27:00+09:00","summary":"今日は、ElasticSearchのMLで見つけたelasticsearch-inquisitorプラグインの紹介です。 ElasticSea","tags":["elasticsearch","plugin"],"title":"elasticsearch-inquisitorプラグインの紹介"},{"contents":"river-wikipediaの前々回の記事で書きましたが、bulk_sizeに関連して登録件数がやけにきりが良いのが気になると書いていました。\nで、Riverの仕組みを勉强がてら、elasticsearch-river-wikipediaのソース（1.2.0）を読んでみました。\nRiverの作り Riverはorg.elasticsearch.river.Riverというinterfaceを実装することで作らています。 ただ、Riverがinterfaceとなっていますが、o.e.river.AbstractRiverComponentというクラスを継承して作られています。\nAbstractRiverComponentにはRiverの名前や設定などが用意されています。 ま、ここはそれほど重要じゃないので、軽く流してと。\nRiverの設定関連は実装したRiverクラス（ここでは、WikipediaRiverクラス）のコンストラクタで、設定値の読み取りなどの記述を記載します。 このコンストラクタが、_river/hogehoge/_metaをPUTした時のJSONを元にElasticSearchから呼ばれて、Riverのインスタンスが作成されます。（たぶん、このへんがその処理だと思う。。。このあたりはまた今度）\n実際のRiverの処理はWikipediaRiverクラスのstart()メソッド内部に記述されています。\n@Override public void start() { logger.info(\u0026#34;starting wikipedia stream\u0026#34;); try { ① client.admin().indices().prepareCreate(indexName).execute().actionGet(); } catch (Exception e) { if (ExceptionsHelper.unwrapCause(e) instanceof IndexAlreadyExistsException) { // that\u0026#39;s fine } else if (ExceptionsHelper.unwrapCause(e) instanceof ClusterBlockException) { // ok, not recovered yet..., lets start indexing and hope we recover by the first bulk // TODO: a smarter logic can be to register for cluster event listener here, and only start sampling when the block is removed... } else { logger.warn(\u0026#34;failed to create index [{}], disabling river...\u0026#34;, e, indexName); return; } } ② currentRequest = client.prepareBulk(); ③ WikiXMLParser parser = WikiXMLParserFactory.getSAXParser(url); try { ④ parser.setPageCallback(new PageCallback()); } catch (Exception e) { logger.error(\u0026#34;failed to create parser\u0026#34;, e); return; } ⑤ thread = EsExecutors.daemonThreadFactory(settings.globalSettings(), \u0026#34;wikipedia_slurper\u0026#34;).newThread(new Parser(parser)); thread.start(); } 内部では\nインデックスの作成 バルクアップデート用クライアントの設定 WikiXMLのパーサの初期化 ページごとにキックされるコールバック処理の登録 デーモンスレッドの起動と起動 といった処理の流れになっています。\nで、このスレッドの起動後は、4.で用意したparser.parse()処理がグルグル回ります。\n1ページがパースされるたびに、WikipediaRiver.PageCallbackクラスのproess()メソッドが呼ばれます。 このメソッドの最後で、processBulkIfNeeded()メソッドが呼ばれています。ここで、実際にパースしたページをインデックスに登録する処理が実行されます。\nこのメソッドの1行目が鍵でした。 bulkSize以上の件数がバルクのリクエストに貯まった時だけ、実際にインデックスに登録する処理が実行されます。 このため、スレッドが回っている間は、bulkSize以上のデータが貯まらないと、インデックスへの登録は行われないわけです。\n次に、このスレッドを止めるには、前々回書いたように、_riverにPUTした、Riverの設定をDELETEするしかありません。（あとは、ElasticSearchを停止するとかでしょうか。）\nで、DELETEが実行される呼ばれるのが、WikipediaRiverクラスのclose()メソッドです。\n@Override public void close() { logger.info(\u0026#34;closing wikipedia river\u0026#34;); closed = true; if (thread != null) { thread.interrupt(); } } 見ていただくと分かりますが、スレッド止めて終了です。\n問題点は？ ということで、\nWikipediaのXMLを読み込んでもRiverは停止しない Riverの停止を行ってもスレッドが止められるだけ。 bulkSize以下の件数がcurrentRequestに残っているけど、破棄される とまぁ、こんな流れになっているので、最後の端数のドキュメントがインデックスに登録されないようです。 （まだ、ちゃんと確認してないんですが、備忘録のため先に書いちゃいました。。。）\nじゃあ、全部うまく登録するにはどうしたもんかなぁと。 いまのところ思いついたのはこんな感じです。 他にいい案があったら教えて下さい。\n案１：close()処理の中で、スレッド停止後に、currentRequestに貯まっているデータをインデックスに登録しちゃう 案２：bulkSize以外に、定期的（指定された時間）で登録処理を実行してしまう。 簡単なのでとりあえず、案１を実装してみるかなぁと。 （さっさとコード書けよって話ですね。。。スミマセン） その前にMLで質問ですかねぇ、英語で。\nWikipediaのRiverをざっと眺めてみた感じですが、わかりやすい作りだなぁと。 他のRiverがどうなってるかをちゃんと見てませんが、他にもbulkSize指定をするRiverの場合は、このように件数がbulkSizeに満たない状態ではデータが登録されないといったことがあるかもしれません。\nElasticSearchのソースを読み始める取っ掛かりとしては面白いかと思いますので、興味ある方は読んで作ってみるといいかもしれません。（私は読んだだけですがｗ）\n追記（2013/09/13 21:00） MLで質問してみました。とりあえず、案1を。\nriver-wikipedia does not index all pages\n他のRiverでは対応してるしバグだね、Issue上げてとのことで、あげときました。 ついでにプルリクも出せばいいんでしょうが、プルリクまだやったことないヘタレです。。。\nあと、案2についても同じトピックで質問してます。 どうやら、BulkProcessorにその機能があるよと。 flushintervalというプロパティがありそうです。どうやって設定して、どうやって動くのかとか見てないので、 調査してブログorLTかな。\nbulk udpにはその値を設定できそうなのがあるんだよなぁ。\n追記その２（2013/09/16 23:50） さっそく修正版がコミット(コミットログ)されてました。 結構変わってます。BulkProcessorにflush_intervalの設定をすれば、よしなにやってくれる仕組みがすでに実装されているようです。 bulkSizeについても同様に、BulkProcessorに設定すれば良いようです。 Riverの仕組みが結構スッキリしています。 もともと実装されていた、bulkSizeごとの処理も消されています。 確かに、BulkProcessorの仕組みとして実装されている方がしっくりきますね。\nということで、考える暇もなくコミットされてしまいました。 こうやって質問しつつ、少しずつソースを読んでいこうかなと思ってるとこです。\n","date":1378921080,"dir":"post/2013/","id":"d2e805472f79f0b558f75b90b5e7b4ee","lang":"ja","lastmod":1378921080,"permalink":"https://blog.johtani.info/blog/2013/09/12/question-river-wikipedia/","publishdate":"2013-09-12T02:38:00+09:00","summary":"river-wikipediaの前々回の記事で書きましたが、bulk_sizeに関連して登録件数がやけにきりが良いのが気になると書いていまし","tags":["elasticsearch","wikipedia"],"title":"elasticsearch-river-wikipediaの疑問点"},{"contents":"前々回紹介した、日本語Wikipediaのデータをインデックス登録する記事の続きです。\n今回は、Kuromojiのアナライザを利用してインデックス登録してみます。\n余談（Proxy環境でのプラグインインストール） ElasticSearchのpluginコマンドはJavaで実装されています。（org.elasticsearch.plugins.PluginManager） プラグインのダウンロードには、java.net.URL.openConnection()から取得URLConnectionを使用しています。\nですので、pluginのインストールを行う際に、Proxy環境にある場合は以下のようにコマンドを実行します。\n./bin/plugin -DproxyPort=ポート番号 -DproxyHost=ホスト名 -i elasticsearch/elasticsearch-analysis-kuromoji/1.5.0 elasticsearch-analysis-kuromojiのインストール WikipediaのデータをKuromojiを使って、形態素解析ベースの転置インデックスを作成していきます。 まずは、Kuromojiを利用するために、Analysisプラグインのインストールです。 ElasticSearchのバージョンに対応したプラグインのバージョンがあります。（プラグインのページに対応したバージョンの記載あり） 今回はElasticSearchの0.90.3を利用しているため、1.5.0をインストールします。\n./bin/plugin -i elasticsearch/elasticsearch-analysis-kuromoji/1.5.0 インストール後は再起動しておきます。 なお、Kuromojiを利用して、Wikipediaのデータを登録するばあい、デフォルトの設定では、ヒープが足りなくなるおそれがあります。 ElasticSearchの起動時に以下のオプションを指定して、最大ヒープサイズを2Gとしておきます。\nexport ES_HEAP_SIZE=2g;./bin/elasticsearch Indexの作成（デフォルトでKuromojiのAnalyzerを利用する） Wikipediaのデータを登録する際に、Kuromojiのアナライザを利用したいのが今回の趣旨でした。 一番ラクな方法として、Wikipediaデータのインデックスの設定として、デフォルトのアナライザをKuromojiにしてしまいます。 （きちんと設計する場合は、必要に応じてフィールドごとに指定しましょう）\ncurl -XPUT \u0026#39;localhost:9200/ja-wikipedia-kuromoji\u0026#39; -d \u0026#39;{ \u0026#34;settings\u0026#34;: { \u0026#34;analysis\u0026#34;: { \u0026#34;analyzer\u0026#34;: { \u0026#34;default\u0026#34; : { \u0026#34;type\u0026#34; : \u0026#34;kuromoji\u0026#34; } } } } }\u0026#39; これでkuromojiのアナライザがデフォルトで利用される形となります。 あとは、Riverを起動して登録するだけです。\nRiverの実行 前回と一緒です。 インデックス名（_river/\u0026lt;インデックス名\u0026gt;/_meta）だけは、先ほど作成した「ja-wikipedia-kuromoji」に変更してください。\ncurl -XPUT localhost:9200/_river/ja-wikipedia-kuromoji/_meta -d \u0026#39; { \u0026#34;type\u0026#34; : \u0026#34;wikipedia\u0026#34;, \u0026#34;wikipedia\u0026#34; : { \u0026#34;url\u0026#34; : \u0026#34;file:/home/johtani/src/jawiki-latest-pages-articles.xml\u0026#34; }, \u0026#34;index\u0026#34; : { \u0026#34;bulk_size\u0026#34; : 10000 } }\u0026#39; あとは、インデックスされるのを待つだけです。\nデータ量とか 5.8gbになりました。Kuromojiを利用したため、形態素解析により単語にきちんとトークないずされた結果でしょう。 Uni-gramだと、転置インデックスのボキャブラリも単語に対してヒットするドキュメント数も大きくなるため、 インデックスサイズも大きくなっているのかと。\n検索クエリのサンプルなどはまた後日。（夜遅いので。。。）\n","date":1378138500,"dir":"post/2013/","id":"79e647a3f8b36a1221897f5837c84aff","lang":"ja","lastmod":1378138500,"permalink":"https://blog.johtani.info/blog/2013/09/03/ja-wikipedia-with-kuromoji/","publishdate":"2013-09-03T01:15:00+09:00","summary":"前々回紹介した、日本語Wikipediaのデータをインデックス登録する記事の続きです。 今回は、Kuromojiのアナライザを利用してインデッ","tags":["elasticsearch","kuromoji","wikipedia"],"title":"日本語Wikipediaをインデクシング（Kuromojiバージョン）"},{"contents":"ElasticSearch勉強会 第1回を主催しました。 昨年のpyfesでなんちゃって資料で喋って、1年たちました。\nElasticSearchの書籍（英語）も出てきて、今年はElasticSearchが面白くなりそうだし、使ってる人たちから話も聞きたいなぁということで、主催しました。\n思った以上に興味のある方がいらっしゃったようで、100人応募のところ、チケットがすぐ完売してしまうほど。。。 しかも、当日もほぼ満員ということで、大変な盛況ぶりでした。\nスピーカーの皆様、参加された皆様、会場を提供していただいたリクルートテクノロジーズさん、ありがとうございました！（たぶん、90人くらいいらっしゃってたかと。）\nこんなステキな案内板も用意してもらいました。スタッフのみなさんありがとうございます！ トゥギャっても頂きました。まとめていただいてありがとうございます！\n自分の発表や個々の発表に関する感想は以下のメモに。\nElasticSearch入門 @johtani スライド：ElasticSearch入門※スライドはPDFです。\n緊張しまくりでわかりにくかったですかね。。。 とりあえず、AWSのサービスじゃないってのだけでも覚えて帰っていただければ満足です。 途中で見せたChromeプラグインのSense わからなかった点や質問、ご意見などは、当ブログのコメント、私宛の＠ツイート、なんでもいいので、反応ください。なんでもいいので反応があると、今後の励みになりますので！ ということで、発表でも言いましたが、わからないことがアレば、@johtaniまで投げてもらえれば、「知らない」「ブログのネタにします」「ソレはこんなかんじですかねぇ？（テキトー）」みたいに答えると思います。 Elasticsearch in Actionは帰宅中に、4章追加されたよというメールが届きました。 宿題 クラスタへのノードの追加の処理方法とか、シャーディングの実装とか。 elasticsearchプラグイン入門 ～ mocksolrpluginでSolrと入れ替えてみよう 菅谷さん スライド：elasticsearchプラグイン入門　slideshare\nプラグイン構成とか（公式でまとまってるの見つけられないので助かります。） 作る上でのポイントうれしいです。 パッケージ名変えられるとか、つらい。。。 Solr APIプラグインについて（Solrの振りしてくれる便利なヤツ） 感想 まだ、プラグインを書いたことがないのですが、ちゃんとプラグインはどういう構成で書くんですよというまとまった資料って本家のサイトにもない気がしています。 なので、スライドが公開されたらすごく役に立つかと。 そのまえに、何かプラグイン書いてみます。。。\nDebugging and testing ES systems Chris Birchallさん スライド：Debugging and testing ES systems　slideshare\nテストの方法とか便利なお話（最後のほうしか聞いてなかったですが。。。。） クエリのデバッグは色々とやらないと、なんでヒットしないのってよくあるので。とくに形態素解析を利用した検索の場合、短い文章（クエリ）と長い文章（ドキュメント）で切れ目が変わってうまくヒットしないとかありますよね。 最後に少しだけ話しましたが、n-gramとKuromojiを組み合わせてOR検索とかすると良い場合があります。 インデックスが大きくなったり、OR検索なので遅くなったりというデメリットもありますが。 感想 実際に使われているノウハウを元に話をしていただいたので助かりました。 最初に席を外してたのですが、戻ってきて日本語で普通に発表されててほんとにびっくりしましたｗ テスト用プラグインがあるのとかは知らなかったです。 あと、使われてたIDEがIntelliJ IDEAでしたね！私も使ってます！\nニコニコ動画データセット 25億件を検索可能にしてみよう @PENGUINANA_ スライド：ニコニコ動画を検索可能にしてみよう　slideshare\nkibana@cookpadのお話 どういう挙動するかをやってみればいいじゃんってことで、やってみるのカッコイイ！ http://goo.gl/FYtO5T bigdeskとか。プラグインいろいろ。 感想 さすがです、ペンギン先生。大きなデータセットつかって、構築した環境に関する数値も書かれてる資料ができて素晴らしすぎです。 思った以上にサクサク動いてて、4hでインデクシングできるのもすごいなぁと。 私も見習ってこのくらいがサクッとできるようになりたい。。。 あと、発表後にムチャぶりしましたが、次回はぜひ検索側の性能とかも話してもらえたらと。\n反省点 イベントアテンドだと、キャンセル待ちができない＋どのくらいの方が興味をもっているのかわからない。 イベントページの主催者は複数指定できる方がいい。（土壇場の登録の人が管理できない。私が司会やってたから） マイクが聞こえにくかった（音量調節とかちゃんと調べないと） 懇親会は立食のほうがやはり動きやすい。 懇親会が1時間ちょっとしかできなかった 雑感 ということで、ES勉強会、主催の私が一番楽しめました。ありがとうございます。 （あと、気前よく調べて答えますと言ってしまいました。。。まぁ、いいトリガーになるので、ウェルカムですが）\nやっぱりKibanaについて興味を持ってる人も多いのかなぁという感触がしたので、次回はぜひKibana3の話をしてもらえるように頑張ります。 あと、elasticsearch-headを使われてるんだなぁと。私はelasticsearch-HQを入れて使ってみてます。大きなクラスタ管理まではまだやってないので。\nあとは、やはりいろんな人に助けられてるなぁと実感しつつ、今後も開催するので助けてください！ということで。 （もちろん、Solr勉強会もがんばりますよー）\n関連ブログ ElasticSearch勉強会 第1回 - Go ahead! タムタムの日記 - ElasticSearch勉強会 の参加メモ #elasticsearchjp 第1回ElasticSearch勉強会に行ってきた！ #elasticsearchjp - #侍ズム 第1回 ElasticSearch 勉強会に参加 #elasticsearchjp - seratch 他にもブログを書かれた方がいらっしゃいましたたら、リンクしたいので連絡いただければ。\n","date":1377798120,"dir":"post/2013/","id":"5931f8e3acdac724742c4ee0960d8d40","lang":"ja","lastmod":1377798120,"permalink":"https://blog.johtani.info/blog/2013/08/30/hold-first-elasticsearch-meetup-in-japan/","publishdate":"2013-08-30T02:42:00+09:00","summary":"ElasticSearch勉強会 第1回を主催しました。 昨年のpyfesでなんちゃって資料で喋って、1年たちました。 ElasticSearch","tags":["elasticsearch","勉強会"],"title":"第1回ElasticSearch勉強会を開催しました！ #elasticsearchjp"},{"contents":"久々のブログはElasticSearchネタです。勉強会開催する予定だったりすので、もう少し触っておきたいなと。 お手軽に検索するデータとして、よくWikipediaのデータを使っています。 ElasticSearchにはelasticsearch-river-wikipediaという便利なプラグインがあり、Wikipediaのデータを簡単に検索可能な状態にできます。このRiverを利用して日本語のWikipediaのデータを入れたので、メモを取っておきます。 まずは、river-wikipediaで日本語のデータをインデクシングしてみるまでの説明です。 日本語特有の設定（Kuromojiを利用したインデクシング）などはまた後日。\nプラグインのインストール 対象とするElasticSearchは現時点で最新版の0.90.3とします。 最新版でRiver動かないなぁとつぶやいた影響かどうかはわかりませんが、2013/08/19に最新版のElasticSearchで動作するプラグインが公開されました。\nまずはインストールです。 HPにも書いてありますが、以下のコマンドを実行すればインストールされます。\n$ ./bin/plugin -install elasticsearch/elasticsearch-river-wikipedia/1.2.0 -\u0026gt; Installing elasticsearch/elasticsearch-river-wikipedia/1.2.0... Trying http://download.elasticsearch.org/elasticsearch/elasticsearch-river-wikipedia/elasticsearch-river-wikipedia-1.2.0.zip... Downloading ..........DONE Installed river-wikipedia into /opt/elasticsearch/plugins/river-wikipedia ElasticSearchが起動している場合はプラグインをインストール後、認識させるためにElasticSearchを再起動します。\n日本語Wikipediaのインデクシング 通常は英語のWikipediaがインデクシングされますが、対象となるファイルを変更することで日本語のWikipediaもインデクシング可能です。 手元に日本語Wikipediaのダンプファイルがあるものとします。（ダウンロードはWikipediaデータベースダウンロードのページにあるpages-articles.xml.bz2のファイルです）\nファイルを指定してインデクシングするには、つぎのcurlコマンドを実行します。 コマンドを実行するとすぐにインデクシングが始まりますので注意が必要です。\ncurl -XPUT localhost:9200/_river/ja-wikipedia/_meta -d \u0026#39; { \u0026#34;type\u0026#34; : \u0026#34;wikipedia\u0026#34;, \u0026#34;wikipedia\u0026#34; : { \u0026#34;url\u0026#34; : \u0026#34;file:/home/johtani/src/jawiki-latest-pages-articles.xml\u0026#34; }, \u0026#34;index\u0026#34; : { \u0026#34;bulk_size\u0026#34; : 1000 } }\u0026#39; ここでURLに含まれる「ja-wikipedia」がインデックス名になります。 また、JSONの\u0026quot;url\u0026quot;にはファイルの場所を指定するため、file:で開始するパスを指定します。 例では、bz2を解凍したファイルを指定していますが、bz2のままのファイルでもOKです。\n上記コマンドを実行すると、_riverというインデックスにつぎのようなエントリが増えています。 (curl -XGET 'localhost:9200/_river/ja-wikipedia/_search?pretty)\n{ \u0026#34;took\u0026#34;: 5, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 2, \u0026#34;max_score\u0026#34;: 1, \u0026#34;hits\u0026#34;: [ { \u0026#34;_index\u0026#34;: \u0026#34;_river\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;ja-wikipedia\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;_status\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;ok\u0026#34;: true, \u0026#34;node\u0026#34;: { \u0026#34;id\u0026#34;: \u0026#34;gdyvwpiAR52lqUCcRhVwsg\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Blitzschlag, Baron Von\u0026#34;, \u0026#34;transport_address\u0026#34;: \u0026#34;inet[/192.168.100.7:9300]\u0026#34; } } }, { \u0026#34;_index\u0026#34;: \u0026#34;_river\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;ja-wikipedia\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;_meta\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;wikipedia\u0026#34;, \u0026#34;wikipedia\u0026#34;: { \u0026#34;url\u0026#34;: \u0026#34;file:/home/johtani/src/jawiki-latest-pages-articles.xml\u0026#34; }, \u0026#34;index\u0026#34;: { \u0026#34;bulk_size\u0026#34;: 100 } } } ] } } \u0026quot;_id\u0026quot;: \u0026quot;_meta\u0026quot;というエントリがさきほど登録したWikipediaのRiverに関する設定です。 \u0026quot;_id\u0026quot;: \u0026quot;_status\u0026quot;というエントリが起動したRiverの状態になります。\nRiverの停止 日本語Wikipediaは結構サイズが大きく、手元のAirでインデクシングするのに30分程度かかりました。（bz2圧縮されていないファイルで、何もしていない状態）\n途中でRiverを停止したくなった場合は、以下のcurlコマンドを実行します。\n$ curl -XDELETE \u0026#39;localhost:9200/_river/ja-wikipedia\u0026#39; 先ほど設定した_river/ja-wikipediaの情報を削除すると、エントリが削除されたのを検知してRiverが停止します。ログにはつぎのようなメッセージが表示されます。\n[2013-08-26 18:26:50,130][INFO ][cluster.metadata ] [Blitzschlag, Baron Von] [[_river]] remove_mapping [ja-wikipedia] [2013-08-26 18:26:50,130][INFO ][river.wikipedia ] [Blitzschlag, Baron Von] [wikipedia][ja-wikipedia] closing wikipedia river Riverを停止してもそれまでインデクシングされたデータは検索できます。 データはちょっとだけで良いという場合は、先ほどの_riverのデータを削除してください。 （◯件だけ登録したいとかできるかは調べてないです。）\nサイズとかマッピングとか サイズ インデックス前のXMLのサイズが5.7Gのとき、ElasticSearchのインデックスサイズ（Optimize後）は7.2Gとなりました。すこし古いファイルを利用しているため、最新版とはサイズが異なるかもしれません。\nあと、データ数が、1540000件とやけにきりがいいのがちょっと気になっています。。。 bulkのサイズを10000で指定してインデックスしたので、切れてるのかなぁと。\nということは、データが欠落しているような気がするのでRiverの作りの問題なのか、ElasticSearchの問題なのかはちょっと調べてみないとわからないなと。\nマッピング 出来上がったインデックスのマッピング（Solrでいうスキーマみたいなもの）は次のようになっています。\n{ \u0026#34;ja-wikipedia\u0026#34;: { \u0026#34;page\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;category\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;disambiguation\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;boolean\u0026#34; }, \u0026#34;link\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;redirect\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;boolean\u0026#34; }, \u0026#34;special\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;boolean\u0026#34; }, \u0026#34;stub\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;boolean\u0026#34; }, \u0026#34;text\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;title\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } } } Wikipediaの各種データが上記のフィールドに入っています。 また、マッピングタイプはデフォルトで「page」というタイプになっています。\n検索 先ほどのマッピングを元に検索すればOKです。例えばつぎのような感じです。\ncurl -XPOST \u0026#39;localhost:9200/ja-wikipedia/_search?pretty\u0026#39; -d \u0026#39; { \u0026#34;size\u0026#34; : 3, \u0026#34;script_fields\u0026#34;: { \u0026#34;title_only\u0026#34;: { \u0026#34;script\u0026#34;: \u0026#34;_source.title\u0026#34; } }, \u0026#34;query\u0026#34; : { \u0026#34;query_string\u0026#34;: { \u0026#34;default_field\u0026#34;: \u0026#34;title\u0026#34;, \u0026#34;query\u0026#34; : \u0026#34;千葉\u0026#34; } } }\u0026#39; 結果はこんな感じ。\n{ \u0026#34;took\u0026#34;: 51, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 5, \u0026#34;successful\u0026#34;: 5, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 8616, \u0026#34;max_score\u0026#34;: 5.8075247, \u0026#34;hits\u0026#34;: [ { \u0026#34;_index\u0026#34;: \u0026#34;ja-wikipedia\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;page\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;3582\u0026#34;, \u0026#34;_score\u0026#34;: 5.8075247, \u0026#34;fields\u0026#34;: { \u0026#34;title_only\u0026#34;: \u0026#34;千葉\u0026#34; } }, { \u0026#34;_index\u0026#34;: \u0026#34;ja-wikipedia\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;page\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;2352241\u0026#34;, \u0026#34;_score\u0026#34;: 4.94406, \u0026#34;fields\u0026#34;: { \u0026#34;title_only\u0026#34;: \u0026#34;千葉千枝子\u0026#34; } }, { \u0026#34;_index\u0026#34;: \u0026#34;ja-wikipedia\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;page\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;14020\u0026#34;, \u0026#34;_score\u0026#34;: 4.8754807, \u0026#34;fields\u0026#34;: { \u0026#34;title_only\u0026#34;: \u0026#34;千葉千恵巳\u0026#34; } } ] } } 結果を見やすくするため、タイトルだけを「title_only」という表示にしています。 ただ、この検索だと、一見「千葉」できちんとヒットしているように見えますが、ElasticSearchのフィールドの定義はstring型になっています。なので、実は「千」や「葉」だけのデータもヒットしています。 マルチバイト文字は1文字ずつインデックスされてしまい、query_stringというクエリでは、フレーズ検索などができていないためです。\nまとめ プラグインいれて、XMLファイルがあれば、検索できるデータが出来上がるので、 暇があったら、お試しで触ってみるデータを簡単に入れてみてはどうでしょうか。\nただ、いくつか気になる点も。\n日本語が検索しにくい（string型のフィールドなのでuni-gramっぽくなっている） bulk_sizeの影響で端数が登録できてない（バグ？どうなの？） ということで、ちょっと使いにくいかもなぁということで、つぎはKuromojiを利用してインデックスしてみてみようかなと。次回のエントリで書く予定です。\n","date":1377226920,"dir":"post/2013/","id":"3931327ed463d1568868c5ab8e839148","lang":"ja","lastmod":1377226920,"permalink":"https://blog.johtani.info/blog/2013/08/23/index-wikipedia-ja-to-elasticsearch/","publishdate":"2013-08-23T12:02:00+09:00","summary":"久々のブログはElasticSearchネタです。勉強会開催する予定だったりすので、もう少し触っておきたいなと。 お手軽に検索するデータとして","tags":["elasticsearch","wikipedia"],"title":"ElasticSearchにプラグインで日本語Wikipediaデータを入れてみました"},{"contents":"宿題その2？かな。Solr勉強会でCloudera Searchのスキーマ周りってどうなってるの？という質問が出てて、 なんか調べることになってたので、関係しそうなMorphlinesのLoadSolrコマンドを調べてみました。 こいつが、Solrへの書き込みを実行するコマンドみたいだったので。\n（※Cloudera Searchのスキーマの設定方法とかは調べてないです。）\n（※めんどくさかったので、パッケージ名すっ飛ばしてクラス名書いてます。githubへのリンクを代わりに貼ってます。）\nRecord＝Solrのドキュメント convert()メソッドにて、MorphlinesのRecord（コマンドの処理するデータの１単位）に格納されているKey-ValueデータをSolrInputDocumentクラスのフィールドとして格納しています。 Recordにもフィールドという概念があり、Recordのフィールド＝Solrのフィールドという事みたいです。\nということで、Solrのフィールドは事前に定義しておき、Morphlinesの処理内部でSolrのフィールド名に値を詰めていく感じでしょうか。 別途、sanitizeUnknownSolrFildsというコマンドが用意されていて、Solrのスキーマにないものはこのコマンドを使って、無視するフィールド名に変えたり、雑多なデータを入れるためのフィールド名にするといった処理ができるようです。このコマンド内部で、Solrのスキーマ設定を元に、Solrのフィールドに合致する物があるかをチェックして処理しています。\nSolrへの登録処理は？ Solrへの登録処理自体はLoadSolrクラス内部でDocumentLoaderというクラスのload()メソッドを呼び出しているだけでした。ということで、DocumentBuilderクラスを少し調査。\nDocumentLoader IFでした。。。実クラスは次の条件\nSolrMorphlineContextにDocumentLoaderがあればそちらを採用（他の種類はなにがあるんだろ？） なければ、SolrServerDocumentLoaderをnewしたものを利用 2.の場合がおそらくMapReduceではないパターンのloadSolrだと思われます。SolrServerDocumentBuilderはSolrJのAPIを利用して、Solrへデータ登録していく普通のアプリです。（対象とするSolrは外部に起動しているもののはず＝FlumeのSolrSinkではこちらを採用かな？）\nSolrへの接続情報とか設定ファイルとかSolrCloud用のZooKeeperとかはSolrLocatorクラスに設定される内容が利用されます。\n1.のパターンは、どうやら、Cloudera SearchのMapReduceIndexerToolのクラスにあるMyDocumentLoaderかなぁと。 こちらは、MapReduceを利用する場合に、利用されてるっぽいです（ちゃんと見てないけど） 内部処理は、HadoopのContext.writeメソッドにでSolrInputDocument（＝MorphlinesのRecord）を書きだして、ReducerでSolrOutputFormatでインデックス作成の流れかなと。たぶん、MorphlineMapRunnerあたりを読みこめば解読できるかと。 ちなみに、こちらは、2.とは異なり、SolrLocatorの設定は無視されそう。\n感想＋妄想？ ということで、Morphlinesのデータ流れを考える上で、現時点ではSolrのスキーマを頭の片隅に置きつつ、 Recordの中にあるデータをゴニョゴニョしてデータを形成していくって感じになりそうです。 うまく処理できなかったものとかのカウントとかもとれたりするのかなぁ？とか、また色々と気になるところが出てきますが、一旦ここまでで。。。（だれか、続きを調べて書いてみてくれてもいいんですよ！コマンドもいっぱいあるし！）\nとまぁ、こんなかんじでMorphlinesをちょっとだけ読みました。 よくよく考えたら、こんなの作ったことあるなぁと（こんなに汎用的じゃないけど）。 みんな同じ事考えるんですねぇ。 コマンドパターン？みたいな感じで、I/F決めてSolrとか別のシステムとかにデータ入れる処理を順番に記述できる的なバッチ処理良くかいてます（書いてましたのほうが正解かなぁ）。\n","date":1375434120,"dir":"post/2013/","id":"33e01e2271be22b5ed330045fe6aff50","lang":"ja","lastmod":1375434120,"permalink":"https://blog.johtani.info/blog/2013/08/02/morphlines-loadsolr/","publishdate":"2013-08-02T18:02:00+09:00","summary":"宿題その2？かな。Solr勉強会でCloudera Searchのスキーマ周りってどうなってるの？という質問が出てて、 なんか調べることになって","tags":["Cloudera Search","Morphlines","Solr"],"title":"MorphlinesのloadSolrをちょっとだけ調べてみた"},{"contents":"今朝起きたら、Xperia Zが故障してしまいました。 電源ボタンを押してもスリープにならないんです。しかも、スリープからの復帰もできない。。。\nということで、ドコモショップに行って来ました。対応も良かったです。 やっぱり、ボタンがおかしく再起動してもNGでした。 ということで、トントン拍子で交換品に変更してもらえました。\n2、3回繰り返し言われましたが、データなくなりますよ＆交換品なので、復旧はご自分でとのこと。 ドコモショップ行く前に「Sony Bridge for Mac」というSony製のアプリでバックアップ取ってたし問題ないですと回答して、交換してもらいました。 最後に使ってないオプションとか要らないのでやめたほうが安くなりますよなどの提案もいただき満足でした。 さらに、前の機種に貼ってたフィルムもきちんと張り替えてもらえたし。時間はちょっとかかったけど。\nで、先ほど帰宅して、朝とっておいたバックアップから復旧しようとしたら。\n**「そんなバックアップありません」**みたいなメッセージが表示されて復旧出来ません。。。\nえ？なにそれ？と思い、とりあえず現時点のデータをバックアップ取ってみるかと。 バックアップ取ったあとに、再度復旧しようとしたらちゃんとリストがでてくるじゃないですか。\nなんだこれ？ということで、ファイル探しです。。。\n「Sony Bridge for Mac」バックアップファイルは次の場所に保存されるみたいです。\n/Users/ユーザ名/Library/Application Support/Sony Ericsson Bridge for Mac/Backups/製品番号みたいな文字列/日付 この最後のディレクトリが製品番号？ごとのディレクトリっぽく、２つありました。 どうせ初期化された状態だしということで、古い日付フォルダを新しい製品番号のフォルダにコピーしたら復元は可能でした。 壁紙の設定は再起動したら復活しましたが、復活してないものも。。。 復活してないのは以下のものです。\nインストールしてたアプリ ホーム画面の配置 アカウント色々（Google Playとか） ということで、スマホでインストールするのもだるくなってきたので、PCで黙々とGoogle Playのサイトからインストールしてますが、これもだるいですね。。。\n必要なアプリインストールし直したら、またSonyのアプリで復旧してみて、設定が復活するのを祈って。。。\n続き インストールしなおして、ホーム画面での配置をがんばりました。 Google Playのサイトから既存アプリをインストールするときに、ブラウザバックで戻ってたのですが、 一覧から別タブにインストールしたいアプリのページを開きまくってから、インストールボタン押すのが楽でした（半分くらい終わった所で気づいた。。。）\n一通りインストールしたあとに、ホーム画面の配置をやり直して、「Sony Bridge for Mac」もう一回復元。 twiccaやブクログなど、個別にアカウントとか設定を管理しているアプリについては復活しました。\nけど、Androidがアカウントを管理するもの（例：Facebookなど）については、残念ながら、一部のものはアカウントを再登録しないといけませんでした。\n写真や音楽についてはもともとSDカードに入れていたのもあったので、まぁ、被害は少なかったかなぁと。\nただ、iPadやiPhoneの用に簡単にバックアップ（アプリの情報、配置まで）ができて復元できると助かるなぁと思いました。（今度はホーム画面のキャプチャ撮ってから修理に出すかなぁ。。。）\n","date":1375364280,"dir":"post/2013/","id":"cd9ba1f582642d9cbe500f018afab341","lang":"ja","lastmod":1375364280,"permalink":"https://blog.johtani.info/blog/2013/08/01/replace-xperia-z/","publishdate":"2013-08-01T22:38:00+09:00","summary":"今朝起きたら、Xperia Zが故障してしまいました。 電源ボタンを押してもスリープにならないんです。しかも、スリープからの復帰もできない。。。","tags":["Xperia Z"],"title":"Xperia Zが故障したので交換したのでメモ"},{"contents":"Morphlinesについてちょっとだけ、さらに調べました。\n誤解 Solr勉強会でなんとなく私の認識を話しましたが、ちょっと誤解してたみたいです。スミマセン。\n誤解：Morphlineというプラットフォーム/ミドルウェアがありそうなイメージ まぁ、書いてあるのでちゃんと読めって話ですが、Morphlineはあくまでライブラリだということでした。 私はなんとなくManifoldCFのようなミドルウェアorプラットフォームが存在して、 そこにFlumeのSinkとかMapReduceによるIndexerが動作するのかと思ってました。\nまぁ、これが間違いでした。正解のイメージはこっちですね。\n各プラットフォーム（FlumeとかHadoopとか）に組み込んむライブラリで、 それぞれ組み込んだ先でMorphlineの設定を記述することで、パイプライン処理ができるっぽいです。\nFlumeについては、MorphlineSolrSinkというクラスでMorphlineの設定ファイルを読み込み、いろいろ処理出来ます。\nMap/ReduceだとCloudera Searchに含まれてるMapReduceIndexerToolがMorphlineの設定を読み込んでコマンド実行してくれるみたいです。 MapReduceIndexerToolはまだちゃんと読んでないのですが、MapperとしてMorphlineのコマンドが実行されるのかなぁ？という感じです。 （結構入り組んでるので、ちゃんと読まないとわからない。。。）\nということで、Morphlineというプラットフォームがあって、一元的にFlumeやMap/Reduceに対するコマンドをパイプライン化するという話でありませんでした。\n※ちなみに、上の画像ですが、愛用しているNUBoardを使って書いてます。 考えをまとめるのにすごく役立つ一品です。持ち運び可能なノート型ホワイトボードです。\n疑問点 ただ、読んでてまだ不明な点があります。まぁ、ぼちぼち調べるかなぁと。。。\nSolrのschemaはどーなってんの？ MorphlineにSolrへロードするコマンド（loadSolr）があるけど、FlumeのMorphlineSolrSinkってのもSolrに書き込みそうだけど？ Map/ReduceでSolrに書き込むもMorphlineのコマンドとの違いは？（前にソースを見たときはSOLR-1301がベースになっていて、SolrOutputFormatってクラスがEmbeddedSolrServer起動してインデクシングしてた） GoLiveってなんだろ？（MapReduceIndexerToolに入ってて、M/Rでインデックス作ったあとにSolrのクラスタに配布＋マージするやつっぽい） どんなコマンドがあるの？（Cloudera Morphlines Ref Guide） 以下は、参考資料と参考資料にあるSlideshareの資料を一部訳したものになります。\n参考資料 Using Morphlines for On-the-Fly ETL(slideshare) cloudera/cdk/cdk-morphlines(github) メモ 現在のコマンドライブラリ（スライド 18-19ページ） Solrへのインテグレートとロード フレキシブルなログファイル解析 1行、複数行、CSVファイル 正規表現ベースのパターンマッチと展開 Avro、JSON、XML、HTMLのインテグレーション Hadoop シーケンスファイルのインテグレーション SolrCellとApache Tikaパーサすべてのインテグレーション Tikaを利用したバイナリデータからMIMEタイプの自動判別 動的Javaコードのスクリプティングサポート フィールドの割り当て処理、比較処理 リストやセット書式のフィールド処理 if-then-else条件分岐 簡易ルールエンジン（tryRules） 文字列とタイムスタンプの変換 slf4jロギング Yammerメトリックとカウンター ネストされたファイルフォーマットコンテナの解凍 などなど プラグインコマンド（スライド　20ページ） 簡単に新しいI/Oや変換コマンドが追加可能 サードパーティや既存機能のインテグレード CommandインタフェースかAbstractCommandのサブクラスを実装 Javaクラスパスに新規作成したものを追加 登録処理などは必要ない 新しいプラグインコマンドとして考えられるもの（22ページ） RDBやKVSやローカルファイルなどの外部データソースをレコードにjoin DNS名前解決とか短縮URLの展開とか ソーシャル・ネットワークからリンクされたメタデータのフェッチ（？？） レコードの感情分析とアノテーション？ 31ページの図がわかりやすいかも\n以上。\n","date":1375265520,"dir":"post/2013/","id":"b875f24d3d444fdda82b6bbfb75a4c92","lang":"ja","lastmod":1375265520,"permalink":"https://blog.johtani.info/blog/2013/07/31/introduction-morphlines/","publishdate":"2013-07-31T19:12:00+09:00","summary":"Morphlinesについてちょっとだけ、さらに調べました。 誤解 Solr勉強会でなんとなく私の認識を話しましたが、ちょっと誤解してたみたいで","tags":["Cloudera Search","Morphlines","Solr"],"title":"Morphlines入門？"},{"contents":"不定期開催ですが第11回Solr勉強会を主催しました。\n今回も大入り90人くらい？の参加者の皆さんがいらっしゃいました。ありがたいことです！（20時時点で最終的に補欠17人でした。）\nとりあえず、第一報です。このあと懇親会なので。\nということで、帰りの電車でいくつか感想を（忘れちゃうから）。\n小林さんの苦労話は細かいですが、結構はまりがちな点を共有していただいたので良かったかなぁと。 Solrのexampleの設定とか、ManifoldCFとかちょっとずつ罠があったりするので、あるあるネタはありがたいと思いますｗ\nCloudera Searchについては、安定の嶋内さんの喋りに圧巻でした。検索だけの視点とは異なる観点についての 話は私には足りないしてんだったりするので参考になります。 なんか、気づいたらMorphlineやスキーマ周りを調べてブログ書くことになっちゃったけど。。。 一つ質問しそこねたのがあって、Cloudera社は基本的に公開したOSSについてのトレーニングも立ち上げているイメージです。Cloudera Searchについてもトレーニングが立ち上がるのかなぁと密かに期待をしてみたり（予算の関係上参加できるかは不明ですが。。。）\n牧野さんの話は画像系について、私は詳しくないので、また関口さんのalikeと比較とかしてもらえると面白いかなぁと。とりあえず、青いロボットがちゃんと検索できるようになるといいですねｗｗ\n秀野さんの空間検索は緯度経度以外のPOLYGONなどを利用した検索で、実は私も知らない機能でしたｗ\nなとなくは知ってたんですが、そこまでちゃんと検索できるとは！地図以外にも活用できるような気がします（想像つかないんだけど。。。）\n最後は私の発表で、簡単な資料ですみませんでした。しかも発表よりも宣伝が。。。（ブログの宣伝だったりとか。。。） 最後に宣伝した「「ビッグデータ活用を支えるOSS」特集への論文投稿のご案内」もご検討ください！\n懇親会も楽しかったです。また思いついたら開催しますー\n最後に、今回の発表者の皆様、会場提供していただいたVOYAGE GROUPの皆様ありがとうございました！\n以下はいつものメモです。\nManifoldCFのとSolrの組み合わせ（仮）株式会社 ロンウイット　大須賀さん 残念ながら、発熱のため発表は次回に持ち越しに。\n##社内ファイル及びWEBコンテンツの検索システム構築時に苦労したこと ソフトバンクBB㈱　小林さん\nManifoldCF＋Solrを使って社内ファイルの検索システム構築 約1000万ドキュメント さまざまなDCにドキュメントがある クロールジョブのハング。。。 ログをDEBUGにしたら。。。ログファイル150GB。。。 一定時間ごとにAgentをリスタートするバッチを。。。（力技） MCFエラーによるジョブの停止 CONNECTORS-590 エラーが発生して止まったジョブを起動するバッチをcronで。。。 自作リアルタイムインデクシングの問題 MCF使わないでSlaveにインデックス openSearcher=falseだとautoCommitが実行されてもSearcherを再起動しないので検索にでてこない リプリケーションのNW負荷 別DCからのレプリケーションが複数が一度に実施される→ネットワーク負荷が。。。 cronで別々にレプリすることでNW負荷を分散できてるかな。。。 Cloudera Search 入門(仮) Cloudera 株式会社　嶋内さん マサカリ画像がｗ SolrのコミッターMark Millerさんもジョインしてる ClouderaとHadoop入門とか。 いろいろあるよ、エコシステム 4つの分類。 データの取り込み データの保存 データの活用 Search 検索エンジンなら数十億人が使い方を知ってる（Clouderaのチャールズ・ゼドルースキ） Cloudera Search Hadoopのためのインタラクティブな検索\nCDHとSolrの統合\nOSS！\n利点とか。\nデータ解析にも使えるよね、検索 非構造化データの検索にもいいよね 単一プラットフォームによるコスパ Cloudera Searchの事例 バイオテクノロジー企業で画像検索とか 医療系企業でいろんなログイベントの管理とか Cloudera Searchのアーキテクチャ Flumeでストリーミングで登録 HBaseデータの登録 M/Rでバッチ登録 HueのWebインタフェース Morphlines、HBaseはLinyプロジェクトのもの\nSolr使うならCDH！！\nQA Q：デモで使われたTwitterの検索のデータ料とかは？\nA：デモ環境ですので小さい。\nQ：スキーマってどうするの？\nA：スキーマは。。。私が書こうかなぁ、ブログ。。。\nコンピュータビジョン　株式会社 Curious Vehicle　牧野さん 色々やってます コンピュータビジョンの説明（某ネコ型ロボットのいろんな画像がｗ） 画像検索の流れ 特徴情報の抽出 特徴情報のクラスタリングによるword化 Solrによる画像情報の検索 1. 特徴情報の抽出 SIFT特徴点解析 グレースケールしてからSIFT 注意！SIFTは商用ライセンスが必要です 2. 特徴情報のクラスタリングによるword化 K-meansでクラスタリング クラスタ情報をヒストグラム化してSolrへ 3. Solrによる画像情報の検索 物体認識ベンチマークセット（ケンタッキー大）を使って。 やっぱり良し悪しある。データセットに特化したチューニングしてます。 つぎのステップ 文字認識とか顔認識 つぎはドラえもんじゃねぇ、検索とかも。。。 ガウシアンによる画像ぼかしの例 QA マイク回しててメモ取れず。。。\n国土交通省のデータをSolrで検索　株式会社ネクスト　秀野さん スライドはこちら\n評価の関係で。。。 Spatial検索の話 デモの想定機能 地図上の小学校を起点に物件検索 地図上をクリックしたところを中心に検索 デモ環境 Solr4.3.0、PostGIS 2.0.3、東京都のデータ 事前知識 ジオメトリーデータ（点、線、面がある） WKB/WKT、Intersects（しらなかった。こんなのもあるのか） 環境 EC2上にPostGIS＋Solrで構築 WKT形式でDIHでインポートできるらしい。 Solr＋S3をJSでGoogleMapへ Solr 4.4新機能をちょっと紹介　@johtani 紹介というよりも宣伝。。。\n","date":1375107300,"dir":"post/2013/","id":"59d1b7206e7664e76672d3de4dc9a8ed","lang":"ja","lastmod":1375107300,"permalink":"https://blog.johtani.info/blog/2013/07/29/study-of-solr/","publishdate":"2013-07-29T23:15:00+09:00","summary":"不定期開催ですが第11回Solr勉強会を主催しました。 今回も大入り90人くらい？の参加者の皆さんがいらっしゃいました。ありがたいことです！（","tags":["Solr","Cloudera Search","ManifoldCF"],"title":"第11回Solr勉強会を主催しました。#SolrJP"},{"contents":"Hadoopとか離れちゃってるし、Hive触ったこと無いにもかかわらず参加しました！\n（たまたま近くにいるからって理由なのは内緒で）\n玉川さんの四方山話を聞くのが主目的で参加しました。（ちょっと翻訳が気になってるので）\nイベントページはこちら\n刊行記念イベントにも関わらず、想像以上の人の入りでびっくりしました。Hadoop、Hive界隈はまだまだ人気なんだなぁと。\nプレゼントじゃんけん大会もあったのですが、そうそうに負けてしまったのが悔やまれます。。。\nTeam Geek欲しかったなぁ。もちろん、懇親会まで参加しました。\n以下、いつものメモです。\nHiveの正しい使い方（Cloudera 嶋内さん） 残念ながら、マサカリは持ってなかったです。\nスライドの各所に本の章番号が書いてあるのがうれしい。 Hiveロゴが回ってたのでスライドの時に集中できなかったｗ Impalaの話も出てきた。 速いけど、色々足りない。Hiveの置き換えじゃないよと。 HiveとImpalaのおいしいとこ取り（セラン　須田さん） スライド：http://www.slideshare.net/sudabon/20130724-oreilly-org\nオンプレだとCDH便利だよと教えてもらう いくつかSlideshareにImpalaの性能評価の資料を上げてある（必要になったら検索で。。。） リリースされたその日に性能評価やってレポート書くとかすごすぎ！ 翻訳の四方山話（玉川さん） 翻訳＝写経です 締め切り駆動勉強法ｗ 4page/day 自分から電突してオライリーさんに翻訳させてくださいと。 他の方の本が読めない（チェックしちゃうのでｗ） 動機があるから読めるってのはあるだろうなぁ。 選び方：わくわくするもの、仕事に活きるもの 今年もあと2冊やる予定（Hadoop Operations、Vagrantを翻訳中） 来年の候補（Chefとか） 高可用性HDFSのご紹介（Cloudera 小林さん） スライドにどの版で書いてあったかがわかりやすく書いてある。 3段階の開発フェーズを経てる QJMのお話 Cloudera UniversityとHadoop認定試験（Cloudera 川崎さん） Clouderaデータアナリスト向けトレーニング（3日間、10月日本語で開催予定） Hive、Pig、Impalaなど Data Science入門コースも準備中 出版記念！ 8月管理者向け先着20 or 30名にHadoop第3版贈呈予定 先着20名にプログラミングHive贈呈予定 ","date":1374685860,"dir":"post/2013/","id":"1b9c5ae60ec46be64a1877f0c6920edc","lang":"ja","lastmod":1374685860,"permalink":"https://blog.johtani.info/blog/2013/07/25/hadoop-hive-publication-party/","publishdate":"2013-07-25T02:11:00+09:00","summary":"Hadoopとか離れちゃってるし、Hive触ったこと無いにもかかわらず参加しました！ （たまたま近くにいるからって理由なのは内緒で） 玉川さんの","tags":["Hadoop","Hive","Cloudera","オライリー"],"title":"『プログラミング Hive』 『Hadoop 第3版』刊行記念セミナーに参加しました！ #oreilly0724"},{"contents":"Yokozunaの気になる点というか、自分だったらこのへん調べるだろうなって観点を上げてみます。 別に調べるわけじゃないので、完全に自己満足なメモですけど。\nちなみに、分散システムとかRiakの仕組みは詳しくないので、ズレてる点がいっぱいあるかも。\nというか、分散システムでテストというか、検討する点とかってまとまってる資料とかあるのかなぁ？\nスキーマ変更時の挙動 フィールド型変更とか、フィールド追加とか 既存RiakクラスタにYokozunaの機能を追加する方法と制限 タイムラグとかも Riak＋Yokozunaクラスタに対してノード追加時に発生するオーバーヘッド（ネットワークとかディスクIOとか） 性能検証のためのシナリオ（どっちが先に悲鳴をあげるかとか） Riakメインで、Yokozunaはおまけ程度に検索するというシナリオ Yokozunaメインで使うシナリオ 更新が多い場合のシナリオ Riakのみ、Riak＋Yokozunaの各種統計情報（CPU、メモリ、ディスクサイズ、ネットワークIO） 運用系（監視とか）の手法とか機能？とか バージョンアップなどの対応方法 Solrがコケた時とかの対処 とりあえず、こんな感じかなぁ。\n","date":1373474580,"dir":"post/2013/","id":"50557b455cba1a3ce9b4555fc3fd5433","lang":"ja","lastmod":1373474580,"permalink":"https://blog.johtani.info/blog/2013/07/11/yokozuna-check-point/","publishdate":"2013-07-11T01:43:00+09:00","summary":"Yokozunaの気になる点というか、自分だったらこのへん調べるだろうなって観点を上げてみます。 別に調べるわけじゃないので、完全に自己満足な","tags":["Riak","Solr","Yokozuna"],"title":"Yokozunaの気になる点というかなんというか"},{"contents":"先日、Bashoさんにおじゃましたのもあり、Riak Meetup Tokyo #2に参加しました。\nYokozunaの話も聞けるということで。 懇親会も参加しました。Vさん＆リピさんと話し込んじゃってあんまり他の人と話せなかったけど。。。\n以下はいつものメモです。\nFreakOut 久森さん 「Riak環境をプロダクションで構築＆運用してみた（仮）」 FreakOutとRTB ディスプレイ広告の新しい配信の枠の話 この人には何出すの？いくらで？みたいな感じ 純広告：表示保証、期間保証など RTB：1回の広告表示ごとに買い付け DSP（デマンド・サイト・プラットフォーム） 広告表示は大体0.1秒で表示しないといけない。この間に色々やってる。 50ms or die.で戦ってます。 RTBはCPUバウンド 多コアを安く並べたい Tokyoなんとかとか使ってた。 スケーラビリティがキツイ（クライアント側でアルゴリズム分散してる） データ解析もしたいけど、検索ができない RTBに適したRiakがうまくハマるのではと。 構成とかとか アプリはPerlなので、PerlでRiakクライアントが必要。Memcached互換とかあると嬉しい。 ProtobufサポートもPurePerlしかなかった。 ないなら、作ろうと。githubに上がってます。このへんかな？ 監視はcloudforecastとかでやってる。 課題 Redirectがつらい（haproxy？がつらい？） Setが詰まるとつらい（ケースがまだわからない） 対策１ memcached＋Riak 対応２（案） hashからpartitionに直接取りに行くとか まとめ 素のままRiakはちょっとつらい QA 聞き取れたやつだけ\nQ：1台いくら位ですか？ A：10万から11万くらい Q：どのくらいの性能ですか？ A：同時1000くらいをさばいてる？ Q：50ms以下を出すのに、ネットワーク周りで近さとかを考えることありますか？ A：国内だと10msあればなんとかなる。それよりもアプリ側のチューニングのほうがまだ重要 Q：Cassandraとか候補に挙がらなかったんですか？ A：苦しんでる人が知人にいるので。。。あと、用途的に違うので。 Q：バックエンドとしてはなにを？ A：bitcaskにしてる Q：サーバ構成、ネットワーク構成がどうなってる？ A：。。。 Q：Redirectとは？RiakがやってるRedirect？ A：はい。 Q：他に候補にあがったのは？ A：商用のaerospike（これかな？）がスケールできそうだったけど、クライアントがいまいち。。。 感想 広告業界のことをよくわかってないので、微妙にピンときてなかったりもするのですが、以下に素早く返すかって観点でどこに注力して、問題点を潰していくのかってのは面白そうだなぁと。 リクエスト処理の性能がクリアできたらつぎはスケールの観点（ノード追加時の挙動とか）で検証していくんだろうなと。次回の話も聞いてみたい感じです。\nIIJ 曽我部さん、田中さん 「Yokozuna 日本語検索性能を評価しました」 Yokozunaって？ Riak＋Solrでいいとこ取り データの登録とかはRiakのAPIで。 SolrのAPIが使える。 YokozunaがSolrの分散検索の部分を隠してくれる。 Yokozunaのインストールとか。 SolrのAPIっぽい形で検索できるし、戻りもSolrのXMLっぽいのが出てくるよ。 Wikipediaデータってstoreの性能とか。 Riakのノード32台。（Xeon、メモリ24GB、HDD。。。） yz_extractor：Riakのコンテンツタイプを見てSolrにデータを入れる処理が書いてある。 自分でschema.xmlを書いてYokozunaに指定することもできる。 スキーマの変更とか登録とか。 すでに指定済みスキーマを変更した場合の挙動ってどうなるの？ デモではSolrからid取って、Riakからその他のデータを取り出していた。 Rubyでの性能評価 ベンチマークプログラム側の問題が先に影響が出てしまった。 QA Q：Riak単体とYokozunaつかった時でディスク容量がどのくらい増えた？ A：ちゃんと調べてないが、10%くらい増えた気がする。 Q：Solr側の設定でstored=trueだけど、falseにしてもいいんじゃないの？ A：デモはfalseにしてます。 Q：スキーマってあとから変更できるんですかね？ A：まだ良くわかってないです。 Q：ノードの追加、削除時の挙動とかも気になります。 感想 今回はStore性能に関してでしたが、今後は検索性能やシナリオによる性能（KVSの処理メインで、時々全文検索とか、全文検索の処理も結構あるパターンとか）の測定とか、耐障害性とかの観点で調査を進めてもらってSolr勉強会で話をしてもらえると面白そうだなぁと勝手に思ってみたり。 Solr勉強会へのコンタクトお待ちしてます！ｗ\n","date":1373450220,"dir":"post/2013/","id":"146e8ca40c0d37f36eecea822028dd9e","lang":"ja","lastmod":1373450220,"permalink":"https://blog.johtani.info/blog/2013/07/10/riak-meetup-tokyo-no2/","publishdate":"2013-07-10T18:57:00+09:00","summary":"先日、Bashoさんにおじゃましたのもあり、Riak Meetup Tokyo #2に参加しました。 Yokozunaの話も聞けるということで。 懇親会も参加しました。","tags":["Riak","Yokozuna","Solr"],"title":"Riak Meetup Tokyo #2に参加しました。#riakjp"},{"contents":"Solr 4.4に取り込まれる予定のチケットで、気になるものを見つけたのでいつものごとく調べてみました。\n元となるチケットはこちら。SOLR-4897。\nスキーマレス？ Solrはschema.xmlにデータの定義（フィールドタイプやフィールドなど）を記述して、データを登録する全文検索システムです。 これまでのSolrではこの設定ファイルを元にデータを登録するフィールド名を決定しており、 変更を行う場合はSolrのコアを再起動するなどの手順が必要でした。（※ダイナミックフィールドはすこし特殊）\nそれだと、Solrを管理するのがめんどくさいですね？という感じで現れたのがSchemaREST APIです。（たぶん。）\nSchema REST API Solr 4.2から導入されたSolrのスキーマに関する情報を提供するためのREST APIです。 4.2で導入されたのはあくまでもschema.xmlの情報を取得するためのAPIでした。 たとえば、Fieldの一覧を取得するとか。\n4.4から、フィールドの追加（変更、削除はできない）ができるようになりました。あくまでも、フィールドの追加で、フィールドタイプなどの追加はまだできません。（できるようになるのかもわからないですが。） フィールドの追加方法などはWikiに記載がありました。\nということで、簡単に試してみることに。\n起動方法 exampleディレクトリの下にexample-schemalessというディレクトリが新設されています。 ここに、スキーマレスモード用の設定がされているファイルが入っているので、こちらを利用します。\ncd $SOLR/example java -Dsolr.solr.home=example-schemaless/solr -jar start.jar ログにいくつかWARNが出ますが、影響の内パス設定ミスなので無視してOKです。\n最初に定義されているフィールドは「id」と「_version_」のみになります。（Schema Browserなどで確認できます。あ、REST APIでもいいですね。http://localhost:8983/solr/schema/fields）\nスキーマの更新 さて、フィールドを追加してみます。 PUTを利用すると1フィールドの追加が可能です。 「fugatext」というフィールド名でフィールドを追加しています。今のところJSONのみ対応みたいです。\n$ curl -X PUT http://localhost:8983/solr/schema/fields/fugatext -H \u0026#39;Content-Type: application/json\u0026#39; -d \u0026#39;{\u0026#34;type\u0026#34;:\u0026#34;text_ja\u0026#34;,\u0026#34;stored\u0026#34;:false,\u0026#34;multiValued\u0026#34;:true}\u0026#39; { \u0026#34;responseHeader\u0026#34;:{ \u0026#34;status\u0026#34;:0, \u0026#34;QTime\u0026#34;:18}} 追加できたかどうかもREST APIで取得してみます。\n$ curl http://localhost:8983/solr/schema/fields { \u0026#34;responseHeader\u0026#34;:{ \u0026#34;status\u0026#34;:0, \u0026#34;QTime\u0026#34;:0}, \u0026#34;fields\u0026#34;:[{ \u0026#34;name\u0026#34;:\u0026#34;_version_\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;long\u0026#34;, \u0026#34;indexed\u0026#34;:true, \u0026#34;stored\u0026#34;:true}, { \u0026#34;name\u0026#34;:\u0026#34;fugatext\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;text_ja\u0026#34;, \u0026#34;multiValued\u0026#34;:true, \u0026#34;stored\u0026#34;:false}, { \u0026#34;name\u0026#34;:\u0026#34;id\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;string\u0026#34;, \u0026#34;multiValued\u0026#34;:false, \u0026#34;indexed\u0026#34;:true, \u0026#34;required\u0026#34;:true, \u0026#34;stored\u0026#34;:true, \u0026#34;uniqueKey\u0026#34;:true}]} 追加できました。 ちなみに、同じフィールド名を追加しようとするとエラーが帰ってきます。\n$ curl -X PUT http://localhost:8983/solr/schema/fields/fugatext -H \u0026#39;Content-Type: application/json\u0026#39; -d \u0026#39;{\u0026#34;type\u0026#34;:\u0026#34;text_ja\u0026#34;,\u0026#34;stored\u0026#34;:false,\u0026#34;multiValued\u0026#34;:true}\u0026#39; { \u0026#34;responseHeader\u0026#34;:{ \u0026#34;status\u0026#34;:400, \u0026#34;QTime\u0026#34;:1}, \u0026#34;error\u0026#34;:{ \u0026#34;msg\u0026#34;:\u0026#34;Field \u0026#39;fugatext\u0026#39; already exists.\u0026#34;, \u0026#34;code\u0026#34;:400}} 設定の違い example-schemalessのsolrconfig.xmlは以下の設定が通常のexampleとは異なるようです。\nschemaFactoryの設定 schemaをAPIから変更可能にする設定です。これまでの変更しない設定の場合はClassicIndexSchemaFactoryを指定します。\n... \u0026lt;schemaFactory class=\u0026#34;ManagedIndexSchemaFactory\u0026#34;\u0026gt; \u0026lt;bool name=\u0026#34;mutable\u0026#34;\u0026gt;true\u0026lt;/bool\u0026gt; \u0026lt;str name=\u0026#34;managedSchemaResourceName\u0026#34;\u0026gt;managed-schema\u0026lt;/str\u0026gt; \u0026lt;/schemaFactory\u0026gt; ... update.chainの設定 更新処理（update関連のリクエストハンドラ「/update」とか）には次のような設定が追加されていました。（1006行目あたり）\n\u0026lt;requestHandler name=\u0026#34;/update\u0026#34; class=\u0026#34;solr.UpdateRequestHandler\u0026#34;\u0026gt; \u0026lt;!-- See below for information on defining updateRequestProcessorChains that can be used by name on each Update Request --\u0026gt; \u0026lt;lst name=\u0026#34;defaults\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;update.chain\u0026#34;\u0026gt;add-unknown-fields-to-the-schema\u0026lt;/str\u0026gt; \u0026lt;/lst\u0026gt; \u0026lt;/requestHandler\u0026gt; 「add-unknown-fields-to-the-schema」というupdate.chainが指定されています。このchainの定義自体は1669行目くらいに存在します。 （長い。。。）\n\u0026lt;!-- Add unknown fields to the schema An example field type guessing update processor that will attempt to parse string-typed field values as Booleans, Longs, Doubles, or Dates, and then add schema fields with the guessed field types. This requires that the schema is both managed and mutable, by declaring schemaFactory as ManagedIndexSchemaFactory, with mutable specified as true. See http://wiki.apache.org/solr/GuessingFieldTypes --\u0026gt; \u0026lt;updateRequestProcessorChain name=\u0026#34;add-unknown-fields-to-the-schema\u0026#34;\u0026gt; \u0026lt;processor class=\u0026#34;solr.RemoveBlankFieldUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;processor class=\u0026#34;solr.ParseBooleanFieldUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;processor class=\u0026#34;solr.ParseLongFieldUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;processor class=\u0026#34;solr.ParseDoubleFieldUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;processor class=\u0026#34;solr.ParseDateFieldUpdateProcessorFactory\u0026#34;\u0026gt; \u0026lt;arr name=\u0026#34;format\u0026#34;\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ss.SSSZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ss,SSSZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ss.SSS\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ss,SSS\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ssZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ss\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mmZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ss.SSSZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ss,SSSZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ss.SSS\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ss,SSS\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ssZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ss\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mmZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026lt;/str\u0026gt; \u0026lt;/arr\u0026gt; \u0026lt;/processor\u0026gt; \u0026lt;processor class=\u0026#34;solr.AddSchemaFieldsUpdateProcessorFactory\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;defaultFieldType\u0026#34;\u0026gt;text_general\u0026lt;/str\u0026gt; \u0026lt;lst name=\u0026#34;typeMapping\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;valueClass\u0026#34;\u0026gt;java.lang.Boolean\u0026lt;/str\u0026gt; \u0026lt;str name=\u0026#34;fieldType\u0026#34;\u0026gt;booleans\u0026lt;/str\u0026gt; \u0026lt;/lst\u0026gt; \u0026lt;lst name=\u0026#34;typeMapping\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;valueClass\u0026#34;\u0026gt;java.util.Date\u0026lt;/str\u0026gt; \u0026lt;str name=\u0026#34;fieldType\u0026#34;\u0026gt;tdates\u0026lt;/str\u0026gt; \u0026lt;/lst\u0026gt; \u0026lt;lst name=\u0026#34;typeMapping\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;valueClass\u0026#34;\u0026gt;java.lang.Long\u0026lt;/str\u0026gt; \u0026lt;str name=\u0026#34;valueClass\u0026#34;\u0026gt;java.lang.Integer\u0026lt;/str\u0026gt; \u0026lt;str name=\u0026#34;fieldType\u0026#34;\u0026gt;tlongs\u0026lt;/str\u0026gt; \u0026lt;/lst\u0026gt; \u0026lt;lst name=\u0026#34;typeMapping\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;valueClass\u0026#34;\u0026gt;java.lang.Number\u0026lt;/str\u0026gt; \u0026lt;str name=\u0026#34;fieldType\u0026#34;\u0026gt;tdoubles\u0026lt;/str\u0026gt; \u0026lt;/lst\u0026gt; \u0026lt;/processor\u0026gt; \u0026lt;processor class=\u0026#34;solr.LogUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;processor class=\u0026#34;solr.RunUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;/updateRequestProcessorChain\u0026gt; 使ってるUpdateProcessorはこんな感じみたいです。最後の2つはこれ用じゃないので省略。\nプロセッサ名説明 RemoveBlankFieldUpdateProcessorFactory値がないフィールドは除去 ParseBooleanFieldUpdateProcessorFactoryスキーマに定義されていないフィールドで、値がBooleanとしてパースできたら、Boolean型とする。 ParseLongFieldUpdateProcessorFactoryスキーマに定義されていないフィールドで、値がLongとしてパースできたら、Long型とする。 ParseDoubleFieldUpdateProcessorFactoryスキーマに定義されていないフィールドで、値がDoubleとしてパースできたら、Double型とする。 ParseDateFieldUpdateProcessorFactoryスキーマに定義されていないフィールドで、値がDateとしてパースできたら、Date型とする。（パースの形式がformatで列挙されてる） AddSchemaFieldsUpdateProcessorFactory入力されたドキュメントの中でスキーマに定義されていないフィールド（静的、動的両方）を見つけた時に、フィールドの値の型を元にフィールド型をマッピングする。 とここまで見てきたところで、スキーマレスという名前の意図がちょっとわかったかも。\n定義されてないフィールドを持ったデータを登録 起動時には定義されてないフィールドをもったデータを登録してみます。 boolean型で試してみることに。以下のデータを管理画面のデータ登録画面から登録します。（http://localhost:8983/solr/#/collection1/documents） （タイトルでbooleanってわかりにくいですが）\n{\u0026#34;id\u0026#34;:\u0026#34;change.me\u0026#34;,\u0026#34;title\u0026#34;:true, \u0026#34;price\u0026#34;:1.25, \u0026#34;fuga\u0026#34;:\u0026#34;100,200\u0026#34;} エラーは出ません。で、またフィールド一覧を取得すると。\n$ curl http://localhost:8983/solr/schema/fields { \u0026#34;responseHeader\u0026#34;:{ \u0026#34;status\u0026#34;:0, \u0026#34;QTime\u0026#34;:1}, \u0026#34;fields\u0026#34;:[{ \u0026#34;name\u0026#34;:\u0026#34;_version_\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;long\u0026#34;, \u0026#34;indexed\u0026#34;:true, \u0026#34;stored\u0026#34;:true}, { \u0026#34;name\u0026#34;:\u0026#34;fuga\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;tlongs\u0026#34;}, { \u0026#34;name\u0026#34;:\u0026#34;fugatext\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;text_ja\u0026#34;, \u0026#34;multiValued\u0026#34;:true, \u0026#34;stored\u0026#34;:false}, { \u0026#34;name\u0026#34;:\u0026#34;id\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;string\u0026#34;, \u0026#34;multiValued\u0026#34;:false, \u0026#34;indexed\u0026#34;:true, \u0026#34;required\u0026#34;:true, \u0026#34;stored\u0026#34;:true, \u0026#34;uniqueKey\u0026#34;:true}, { \u0026#34;name\u0026#34;:\u0026#34;price\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;tdoubles\u0026#34;}, { \u0026#34;name\u0026#34;:\u0026#34;title\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;booleans\u0026#34;}]} おー、最後にtitleが追加されてます。他にもfugaやpriceも。（日付は手を抜きました。。。）\n感想 詳細までは追いかけてないですが、こんなかんじです。 フィールド追加が可能になるのはいいんじゃないでしょうか。SolrCloudの機能との関連もあるのかもしれません。ZooKeeperへの出力も実装されてそうなので。\nただ、機械的に出力されたschema.xml（exampleだとmanaged-schemaというファイル）には_「DO NOT EDIT」_との記述があるので、修正するとなにかおきてしまうかもしれないですねぇ。 現時点では、フィールドタイプの変更やフィールドの更新、削除に関してはSolrCoreの再起動などの手順が必要です。 あと、変なデータ（タイプミスとか）が登録されたりしないかってのは気になりますね。\n※ちなみに、別の人が気づいたんですが、ちょっとバグが有ったみたいで、代わりにチケットつくったらキリ番（SOLR-5000） ゲットしましたｗ\n","date":1372867920,"dir":"post/2013/","id":"a98d42be181c01b8077e060b1b5080ec","lang":"ja","lastmod":1372867920,"permalink":"https://blog.johtani.info/blog/2013/07/04/schemaless-example/","publishdate":"2013-07-04T01:12:00+09:00","summary":"Solr 4.4に取り込まれる予定のチケットで、気になるものを見つけたのでいつものごとく調べてみました。 元となるチケットはこちら。SOLR-4897","tags":["Solr"],"title":"スキーマレスモード？（SOLR-4897）を調べて見ました。"},{"contents":"SolrのチケットをML経由で眺めてるんですが、便利そうなチケットが流れてきたのでブログを書いてみみようかと。 元になってるチケットはこちらです。昨日だか、今朝にtrunkとbranch_4xにコミットされたみたいです。試してみたい方は、branch_4xかtrunkをチェックアウトすると触ることができます。\nデータ登録用の画面（JSON） branch_4xをチェックアウトしてexampleを起動し、Solrにアクセスします。\n管理画面に「Dcuments」という項目が追加されてます。開くとこんなかんじです。\nなんと、デフォルトはJSONになってます。これも時代の流れでしょうかｗ\nSolrでは、これまで設定ファイルやデータ登録もXMLがメインになっていました。（Apache Solr入門もXMLを基本に書いてます。このころはまだデフォルトでは対応してなかったので）\n登録するデータをテキストエリアに記述して、「Submit Document」をクリックすればデータは登録されます。基本的には単件登録の画面でしょうか。 （登録されたデータを確認するには「Query」画面を利用すればいいです。） また、JSONのデータ形式はSolrのWikiを参照してください。\nCSVやXMLも この管理画面ではJSON以外の形式でもデータの登録が可能です。 「Document Type」の項目をクリックすると以下のように選択肢があられます。\nCSV、XMLについては、先ほどのJSONの画面の用に、テキストエリアが表示されます。 テキストエリアにCSV（データの形式はこちら）やXML（データの形式はこちら）を入力してボタンを押せば登録できます。\nSolr Command形式も（JOSNかXML） Solr Command というのはXMLやJSONで登録、コミット、削除などを実行するための画面になります。 JSONのコマンドはこちら、XMLのコマンドはこちらをご覧ください。\nあと、便利なのがファイルアップロードです。 こんなかんじで、ファイルを選んでSubmitすればデータが登録出来ます。\nファイルのサイズが大きいとちょっと時間がかかりますが、コマンドを打つより簡単かもしれません。 post.jarツールと違って、デフォルトでコミットをしてくれるわけではないので、「Extracting Req. Handler Params」に「commit=true」をつけないと、データが登録されてない？と思ってしまうかもしれませんが。\n組立もできるみたい（Document Builder） 最後に紹介するのが「Document Builder」というタイプです。\nもっと簡易にデータを記述できるようにということで用意されているようです。 フィールドの情報はSolrに接続して利用できるフィールド？（ダイナミックはないのかな？）が表示されます。\n追記していくとこんなかんじになります。\n日本語のデータもちゃんと登録できました。 ただ、まだ、開発中なんでしょうがないかもしれませんが、以下の様な制約があるようです。\nmultiValuedなフィールドに値を追加できない（上書きされる） 改行が入ったデータをテキストエリアにいれると「Add Field」を押しても反応しない ダイナミックフィールドは自分で書きましょう ただ、これまでXMLでファイルを作ってコマンドで登録したり、curlコマンドでJSON書いたりして登録していたよりはお手軽にさわれるようになるかと思います。つぎの4x系のバージョンが出たときはこちらからデータを登録してみてください。\n","date":1372318080,"dir":"post/2013/","id":"ecf3ac80454654d990d9c07d33d35d1c","lang":"ja","lastmod":1372318080,"permalink":"https://blog.johtani.info/blog/2013/06/27/upload-docs-solr-admin/","publishdate":"2013-06-27T16:28:00+09:00","summary":"SolrのチケットをML経由で眺めてるんですが、便利そうなチケットが流れてきたのでブログを書いてみみようかと。 元になってるチケットはこちらで","tags":["Solr"],"title":"Solrの管理画面でデータ登録"},{"contents":"前回は3番煎じぐらいでしたが、今回は初記事かな？（だといいな）\nKibanaには、前回の記事で書いたものとは別に開発中のKibana3というのが存在します。\nKibana3って？ Kibana2はRubyで書かれていましたが、Kibana3はHTML＋JavaScriptで構成されています。 ですので、ApacheなどのWebサーバに配置することで、利用が可能となります。 ただ、HTML＋JavaScriptのため、ブラウザ上で動作するためブラウザが動作するマシンからElasticSearch（通常だとhttp://マシン名orIPアドレス:9200/とか）にアクセスできなければいけないという制限があります。\nこの条件さえクリア出来れば、Kibana3ではKibana2よりも様々なパネルが用意されていて、色々できそうなのでお勧めです。\nインストール ElasticSearchやログについては、前回の記事の環境を利用しました。 ですので、Kibana3のインストールのみです。（ApacheもCentOSのサーバに入っていたので。）\nダウンロードして、Apacheの公開ディレクトリに置いただけです。（お試し環境のため、権限とかは大目に見てください。\n$ git clone https://github.com/elasticsearch/kibana.git kibana-javascript $ cp -R kibana-javascript /var/www/html 今回はApacheとElasticSearchが同一マシン（＝同一IPアドレスでアクセス可能）で動作している＋ElasticSearchへのアクセスのポートがデフォルト（9200）のため特に設定が必要ありませんでした。\nElasticSeachサーバとKibana3のApacheのサーバが別のサーバの場合やElasticSearchサーバのポートが異なる場合はkibana-javascript/config.jsファイルの編集が必要になります。 cloneしてすぐのconfig.jsは、以下のとおりです。\n/* elasticsearch: URL to your elasticsearch server. You almost certainly don\u0026#39;t want \u0026#39;http://localhost:9200\u0026#39; here. Even if Kibana and ES are on the same host kibana_index: The default ES index to use for storing Kibana specific object such as stored dashboards modules: Panel modules to load. In the future these will be inferred from your initial dashboard, though if you share dashboards you will probably need to list them all here If you need to configure the default dashboard, please see dashboards/default */ var config = new Settings( { // By default this will attempt to reach ES at the same host you have // elasticsearch installed on. You probably want to set it to the FQDN of your // elasticsearch host elasticsearch: \u0026#34;http://\u0026#34;+window.location.hostname+\u0026#34;:9200\u0026#34;, // elasticsearch: \u0026#39;http://localhost:9200\u0026#39;, kibana_index: \u0026#34;kibana-int\u0026#34;, modules: [\u0026#39;histogram\u0026#39;,\u0026#39;map\u0026#39;,\u0026#39;pie\u0026#39;,\u0026#39;table\u0026#39;,\u0026#39;stringquery\u0026#39;,\u0026#39;sort\u0026#39;, \u0026#39;timepicker\u0026#39;,\u0026#39;text\u0026#39;,\u0026#39;fields\u0026#39;,\u0026#39;hits\u0026#39;,\u0026#39;dashcontrol\u0026#39;, \u0026#39;column\u0026#39;,\u0026#39;derivequeries\u0026#39;,\u0026#39;trends\u0026#39;,\u0026#39;bettermap\u0026#39;], } ); ポート番号が異なる場合は、1つ目の「elasticsearch:」で指定されている「9200」を環境に合わせて編集するだけになります。 Kibana3とElasticSearchのホストが異なる場合は、1つ目の「elasticsearch:」の行をコメントアウトし、2つ目を有効にしてから環境に合わせたURLに修正して保存すればOKです。\n以上で、インストールは完了します。あとは、以下のURLにアクセスするだけです。\nhttp://hogehoge/kibana-javascript/ 画面構成 アクセスすると次のような画面が表示されます。\n初期画面 左上に赤い帯で、「 Oops! Could not match index pattern to any ElasticSearch indices」とエラーが表示されました。\nKibanaはElasticSearchに「logstatsh-年.月.日」という日付ごとのインデックスが存在することが前提となっています。 Kibanaに初めてアクセスした場合、「logstash-当日日付」で始まるインデックスを描画しようとします。 これは、私が前回利用したElasticSearchの環境に古いデータ（試したのが19日、データは10日のみ）しか入っていないために出たエラーです。\n日付は「Options」というエラーが出ている付近の「Absolute」というリンクをクリックすると、特定の日付をカレンダーで指定することができるようになります。データは6/10にしか入っていないので、6/10（12時くらいから20時くらいまで）のを指定します。\n日付指定 選択すると無事データが見えるようになりました。\nデータ描画 ダッシュボードの構成（初期） Kibana3では、この画面をダッシュボードというようです。 このダッシュボードは初期状態では、以下のパーツが表示されています。（子要素があとで説明するパネル名です）\nOptions：描画対象の日付の指定やダッシュボードの保存などを行うRow timepickerパネル：日付の指定 dashcontrolパネル：ダッシュボードの制御（保存とか） Query：ログ検索式を入れるところ stringqueryパネル Graph：ヒストグラムの描画（X軸：時間、Y軸：ログ件数） histogramパネル Events：検索にヒットしたログデータの描画領域 fieldsパネル：表示するフィールドの選択（左側。チェックを入れると右側のログ表示領域のカラムが増える） tableパネル：ログデータ（右側。左側でチェックが入ったカラムだけが表示される。） あくまで初期表示です。各パーツの設定アイコン（歯車のマーク）をクリックすると色々と設定が可能です。 また、「Events」など名称はクリック可能となっていて、クリックすると、そのパーツが折りたたまれた状態にすることも可能です。\n折りたたんだ状態 ダッシュボードの設定 ダッシュボードには独自のパネルを簡単に追加することができます。 ダッシュボードの構成はページの一番上にある「Logstash Search」の設定アイコンをクリックすると設定画面が開きます。\nダッシュボード設定 「New row」にタイトル名を適当にいれて「Create Row」するとあたらしくパネルを追加することができるRowが追加されます。「Rows」の「Move」にある矢印でRow自体の表示場所を上下に移動することも可能です。\nRowの設定 追加した「Hoge」にパネルを追加する場合はHogeの上にある設定アイコンをクリックすると設定画面が開きます。\nRowの設定 ここでKibana3で用意されているパネルの追加ができます。\nPanel追加ボタン パネルを選んでボタンを押せばすぐに表示されます。\nパネルの羅列 こんな感じです。とりあえず、ポコポコと追加してみました。\n利用できるパネルの種類は以下の様なパターンです。 適当ですが、表にしてみました。\nパネル名概要 columnRowの中にパネルを配置するコンテナを用意するためのパネル dashcontrolダッシュボードの保存、保存したダッシュボードの表示などの操作ボタン textmarkdown形式などで記述が可能な文章を表示できるパネル stringquery検索クエリ入力用パネル derivequeriesフィールドと検索式がわかれた形式の検索入力用パネル timepickerログ表示の期間を指定するパネル histogramログの件数のヒストグラム表示用パネル hitsヒット件数表示用パネル pieパイチャート表示用パネル trends指定された時間でデータの増減を%表示するパネル sortソート条件指定用のプルダウン表示用パネル（変更したらtableの内容がソートされる） tableログデータ表示用パネル fieldstableパネルに表示するフィールドを選択するための補助パネル bettermapなんか地図が出てきたパネルGeoJSONデータをゴニョゴニョ（表示かな？）できるみたい mapなんか世界地図が出てきたパネル２文字の国コード（jaとかか？）かU.S.の州コードのデータを元に地図に色をつけるのかな？ これらのパネルは個々に色々と設定が可能です。他にもdebug、map2など有りそうでしたがまだ使えないみたいです。\n適当に触ってて気づいた注意点です。\ntableは１ダッシュボードで１つだけが良さそう。 ２つあると、どちらかにしか描画されない。columnに入れるとグルーピングできたりするのかなぁ？ stringquery、timepickerも１ダッシュボードで１つが良さそう。 これもtableと似たような理由です。 ダッシュボード保存し忘れて泣きそうになる JSで実装されてて、自分で色々とカスタマイズできるのですが、保存するのを忘れて泣きそうになりましたｗ カスタマイズしたダッシュボードについては、ローカルに保存する以外にElasticSearchにも保存ができるみたいです。チームで共有することもできそうです。 derivequeriesを表示するとグラフがカラフルに derivequeriesを追加したらグラフが急にカラフルになりました。 どうもderivequeriesのFieldの部分を変更すると、そのフィールドの値を元にグラフを細分化してくれるようです。色の数の上限はderivequeriesのLength属性の数値で制御出来ます。（5だと5個まで色が出る） histogramのパネルで自分でクエリを記載することも可能です。ただ、derivequeriesのフィールド変更すると書き換わっちゃいます。。。 derivequeriesを追加したらカラフルに ヒストグラムは色々なパターンのグラフを描画できました。ラインによる描画（histo1）、総数を100%としたパーセンテージでの表示（histo2）、ライン＋点による描画（histo3）などです。\nヒストグラムのいくつかのパターン 感想 ということで、適当にですが触ってみました。 Kibana2はApacheのアクセスログとかの表示しかできない感じがしましたが、Kibana3だといろいろなデータを描画できそうだなと。 logstash形式のインデックスを用意するのが前提になってるので、時系列データをグラフ描画するのに向いてるんでしょうか。 お手軽にグラフ化できるし、自分でダッシュボードをカスタマイズできるのは素敵です。 ただ、クエリとグラフの関係などはちょっと癖があるかもしれないので、色々と試してみないといけないかもしれないです。 （たとえば、特定のフィールドの値について「A、B、その他」みたいなグラフの描画とかをどうするかとか）\n地図の描画は試してみたいかなぁ。\n","date":1371652980,"dir":"post/2013/","id":"26c47355cbe966a94826cbe2fbf2b355","lang":"ja","lastmod":1371652980,"permalink":"https://blog.johtani.info/blog/2013/06/19/introduction-kibana3/","publishdate":"2013-06-19T23:43:00+09:00","summary":"前回は3番煎じぐらいでしたが、今回は初記事かな？（だといいな） Kibanaには、前回の記事で書いたものとは別に開発中のKibana3というの","tags":["elasticsearch","kibana"],"title":"Kibana3というのもありまして"},{"contents":"ちょくちょく書こうと言いながら、前の記事が1週間以上前になってる。。。\n昨日は、Basho Japanに遊びに行って来ました。 （Riak触ったことないのに。。。Erlangも。。。ゴメンナサイ）\nRiakにSolrを組み合わせたYokozunaというものの名前を最近耳にしていたので、どんなものなのかなぁと興味がありまして。Solrがどんな使い方をされているのかってのが気になったので、 情報交換したいなぁと思っていたところ、Vの人が調整してくれたので色々と有意義な話ができたかなぁと。 （Yokozunaについての最新のスライドはBerlin Buzzword 2013のものがここに） Twitter上で見かけたことのある方々と話ができたり面白かったです。（やっぱ英語で会話できたりスラスラと読めるの必要だよなぁと痛感したりもしました。。。）\nということで、遊びに行ったのに美味しいピザやこんなおみやげまでもらってしまいました。 （ピザの写真撮るの忘れてたw）\nRiak＆Bashoグッズ ちなみに、Yokozunaですが、Riakに登録したデータを裏で起動しているSolにデータを流しこんでくれるものになります。 Solrの機能としては分散検索（Distributed Search）と呼ばれる仕組みを利用しているようです。 YokozunaのI/Fとしては、Solrのインデックスの分散構成は隠してくれていて、かつ、Solr（っぽい？）リクエストを投げれば裏の分散構成に問い合わせた結果をSolrのレスポンスの形で返してくれます。 KVSに全文検索の機能がついてくるお得感が満載な気がしますw。\nRiak自身のデータの取り扱いがどんなものかをまだちゃんと理解していないので（ゴメンナサイ。Little Riak Bookは開いてるんですが読んでなくて。。。）またおじゃましてもう少し情報交換したいかなぁとｗ。\nCloudera Searchといい、Yokozunaといい、Solrを利用したものが少しずつ増えてきて嬉しい限りです。 Solrの作りがしっかりしている？活発？、だから取り込む形が多いんですかねぇ。 Solr本を書いてから数年たちますが、やっと検索のニーズが出てきたのかもしれないなぁと思ってみたり。 （流れのつながりはあまりないですが）ElasticSearchも少しずつ人気が出てきてるし、日本語の本とかのニーズあったりするかなぁ？\n","date":1371603780,"dir":"post/2013/","id":"33919e866426ce8e7b2ce06f19bbf889","lang":"ja","lastmod":1371603780,"permalink":"https://blog.johtani.info/blog/2013/06/19/visited-basho/","publishdate":"2013-06-19T10:03:00+09:00","summary":"ちょくちょく書こうと言いながら、前の記事が1週間以上前になってる。。。 昨日は、Basho Japanに遊びに行って来ました。 （Riak触ったこ","tags":["Riak","Basho","Yokozuna","Solr"],"title":"Basho Japanに遊びに行きました"},{"contents":"Lucene/Solr 4.3.1のRCのVoteが始まっていますが、そのMLできになったコトがあり、ちょっと調べたので メモを残しておきます。\nマルチコアの設定ファイルであるsolr.xmlの記述方法と、コアの探索ロジックが4.4（実装的には4.3から入っている）から変更されるようです。4.x系の最新版である、branch_4xのexampleディレクトリにあるsolr.xmlも新しい記述に変更されていました。\n参考URL 新しいCore探索（4.4以降） 新しいsolr.xml（4.4以降） 4.3までのsolr.xml ちなみに、最後のold styleと呼ばれる4.3までの記述方法はつぎの5.0ではDeprecatedになるようです。（5.0がいつ出るのかはわからないですが。）\nCore探索ロジック 4.4から、$SOLR_HOMEディレクトリ以下の探索ロジックは次のようになるようです。 以下では、「新スタイル」（4.4以降の書式）、「旧スタイル」（4.3以下の書式）として記述します。\nsolr.xmlファイルの存在チェック solr.xmlが存在しない場合→旧スタイルとして処理→3へ（旧スタイル） solr.xmlが存在し\u0026lt;cores\u0026gt;タグが存在しない場合→2へ（新スタイル） solr.xmlが存在し\u0026lt;cores\u0026gt;タグが存在する場合→3へ（旧スタイル） 新スタイルのロジック SOLR_HOMEディレクトリに存在するディレクトリについて以下の処理を繰り返す SOLR_HOME/ディレクトリ/core.propertiesファイルが存在する→後続処理へ。存在しなければ終了 SOLR_HOME/ディレクトリ/conf/solrconfig.xmlを読み込み、コアを起動 旧スタイルのロジック これまで同様、solr.xmlの\u0026lt;core\u0026gt;タグの記載内容を元にコアを起動（instanceDir以下のconf/solrconfig.xmlを使って） solr.xmlが存在しない場合はSOLR_HOME/collection1/conf/solrconfig.xmlが存在するものとしてコアを起動 このようなロジックになります。\nちなみに、以下の場合はエラーとなりSolrは起動しますがログや管理画面にエラーである表示がされます。\n2.3でsolrconfig.xmlが見つけられなかった場合 3.1で\u0026lt;core\u0026gt;タグが存在しなかった場合（この場合、ログにはエラーが出ません） propertiesに記述できる内容やsolr.xmlの記述内容については、Wikiを見てもらうということで。。。 CoreAdminHandlerでコアを生成したりした場合に、新スタイルの設定がどのように出力されるのかといった点が気になりますが、また今度にでも。\n","date":1370945460,"dir":"post/2013/","id":"78292d953eafbdf9e57cc4bbbe6e8964","lang":"ja","lastmod":1370945460,"permalink":"https://blog.johtani.info/blog/2013/06/11/new-solr-xml/","publishdate":"2013-06-11T19:11:00+09:00","summary":"Lucene/Solr 4.3.1のRCのVoteが始まっていますが、そのMLできになったコトがあり、ちょっと調べたので メモを残しておきます。 マルチコアの設定ファ","tags":["Solr"],"title":"新しいsolr.xmlとCore探索ロジック"},{"contents":"もう何番煎じだ？ってくらい書かれてますが、コリもせず書いてみました。 Elasticsearch＋Kibanaの環境を作って、タムタムさんのログ生成ツールからApacheのダミーログを流しこんで入れてみました。\n参考URL memorycraftさんのブログ Kibana Elasticsearch fluentd apache-loggen インストールと起動 今回はCentOSへのインストールです。 基本的にはmemorycraftさんのブログの流れのままです。\nelasticserchのインストールと起動 ダウンロードして、起動するだけ。 お試しということで、-fオプションにてコンソールにログ出力。\ncurl -OL https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-0.90.1.tar.gz tar zxvf elasticsearch-0.90.1.tar.gz cd elasticsearch-0.90.1 ./bin/elasticsearch -f Kibanaのインストールと起動 git cloneしてbundleインストール\ngit clone --branch=kibana-ruby https://github.com/rashidkpc/Kibana.git cd Kibana bundle install ruby kibana.rb これで、Kibana＋ESのインストール＋起動が完了。 下地が完了。\ntd-agentのインストールと起動 ログの流し込みはlogstashなのですが、fluentdのelasticsearchプラグインにて流しこむこともできます。 td.repoとしてtd-agentのリポジトリを登録してから以下を実行します。\nyum install td-agent -y /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-elasticsearch vim　/etc/td-agent/td-agent.conf /etc/init.d/td-agent start これで、td-agentがインストール出来ました。 次は設定です。\n\u0026lt;source\u0026gt; type tail format apache path /var/log/httpd/dummy_access_log tag dummy.apache.access \u0026lt;/source\u0026gt; \u0026lt;match *.apache.*\u0026gt; index_name adminpack type_name apache type elasticsearch include_tag_key true tag_key @log_name host localhost port 9200 logstash_format true flush_interval 10s \u0026lt;/match\u0026gt; 以上が設定です。td-agentはtd-agentというユーザで起動されるので、/var/log/httpdディレクトリにアクセスできるかだけ確認が必要です。\nいくつかの設定値について気になったので調べました。\nindex_name：adminpackとなってるが、elasticsearchではlogstash-xxxとなってる。 これは、logstash_formatがtrueの場合は、利用されないので、指定しなくてもいい。 type_name：Elasticsearchのタイプ名 *　これはlogstash_formatを指定しても有効。ただし、Kibana側で画面からのtype指定は不可能。KibanaConfig.rbにて指定することは可能。 logstash_format：Kibana用にlogstashフォーマットで出力するオプション この指定があるときは、index名が「logstash-YYYY.mm.dd」となる record（ログ）に@timestampとして時刻が追加される。 tag_key：include_tag_keyがtrueと指定されているため、record（ログ）にtag_keyで指定した文字列をキー、値としてtagの値（上記例だとdummy.apache.access）が付与されて登録される。 apache-loggenのインストールと起動 タムタムさんが作成されたApacheのログのダミーを生成するツールです。\ngem化されてるので、インストールは非常に簡単です。\ngem install apache-loggen で、ログを出力します。出力先は先程設定したdummy_access_logです。\napache-loggen --rate=10 --progress /var/log/httpd/dummy_access_log 秒間10アクセスログを出力してくれます。 これで、Kibanaでログが見れるようになりました。 なんて簡単なんでしょう。。。 簡単なログの検索ができてしまいました。 他の形式のログがどうなるのかとかは、また時間があれば。。。\n感想とか 非常に簡単でした。素敵です。いくつかこうなるのかな？というのを試してみたのでメモを。\nいくつか疑問点です。\n溜まったログの削除は手動？ おそらく。日付ごとにindexが出来上がっているので、削除は楽そう。「logstash-年月日」なので。 認証とかかけれるの？ ログ検索は内部でするだろうから、まぁ、なくていいのかな。ログインすらないし。 複数行のログとかってどーすんだろう？（JavaのExceptionとかが混ざるやつ） 本格的に触るようになれば調べるかなぁ。。。\nあと、ログが増えてきた時にどういった分割構成ができるだろう？って思って考えてみたのが以下になります。\n構成パターン ログを複数扱う場合は次のようなパターンがありそうかと。\nタグ（fluentdのタグ）で識別 「@log_name」という名前＝fluentdのタグにてログを識別することで、異なるログを検索することができそうです。 タグであれば、プラグインによってはログ出力時に制御も可能だと思うので、td-agentの設定を変更したりすることもなく対応が可能かと。 ただ、ログの種別ごとにKibanaのプロセスを別にして起動したいといった用途には向いてなさそうです。\ntype_nameによる識別 ElasticSearchの機能であるtypeを利用したログの識別パターンです。\nfluent-plugin-elasticsearchの設定でtype_nameを指定しました。 ここを別の名前にすることで、識別することも可能です。\nただし、この場合はKibanaの画面から指定して検索することができません。 →コメント頂きました。検索条件に「_type:タイプ名」と検索することでtypeを利用した検索が可能です。\nタグ（@log_name）でも識別できるようにするなどの工夫が必要です。 その代わり、タグ識別ではできなかったKibanaのプロセスを別にして起動することは可能になります。\nKibanaConfig.rbのTypeに値を設定することで、起動したKibanaが対象とするログを絞り込むことが可能です。 こうすることで例えば、apache用のKibanaとtomcat用のKibanaは別プロセスにして、ElasticSearchのクラスタは1つという構成も可能になります。\nElasticSearchサーバを別立て ElasticSearchサーバをそもそも別のプロセスor別のサーバで起動し、Kibanaも別々にすればログの識別も可能です。 可能ですが、色々と管理するものが増えてめんどくさそうですね。。。\nインデックス名変更 最後は、fluent-plugin-elasticsearchの設定で「logstash_format」をfalseにすれば、好きなindex_nameを付与できるので、 ログ種別ごとに名前を変更することで識別できます。\nただ、logstash形式でないインデックス名の場合、日付ローテーションができなかったり、Kibana内部で検索時に日付で検索対象を絞り込んで検索することで高速化するといった処理など、使えない機能が多々出てきてしまうのであまりおすすめじゃないかと。。。\nということで、流行りものは触っておこうということで、さわってブログ書いてみました。\n開発中に立てておいて、各サーバのログを流しこんでおくなどにも利用できるかもしれないです。 アラート通知などの機能が出てくるともっと便利かもしれないです。\n","date":1370874840,"dir":"post/2013/","id":"c4d3a917f623f58646ce93015d79e8e0","lang":"ja","lastmod":1370874840,"permalink":"https://blog.johtani.info/blog/2013/06/10/fluent-es-kibana/","publishdate":"2013-06-10T23:34:00+09:00","summary":"もう何番煎じだ？ってくらい書かれてますが、コリもせず書いてみました。 Elasticsearch＋Kibanaの環境を作って、タムタムさんのロ","tags":["kibana","elasticsearch","fluentd"],"title":"apache-loggen + fluentd + elasticsearch + kibana = ログ検索デモ"},{"contents":"昨日に引き続き、AWS Summit Tokyo 2013に行ってきました。\n@ryu_kobayashiさんからパシリを仰せつかるなどあり、忙しかったのですが楽しかったです。\n今日もすごい人出で、昼時の展示ブースは人だかりで、TDの方たち忙しそうでした。 後半はちょっとつかれたなぁ。 1日目よりも空調の温度が上がってたので快適でした。 飲物忘れたので、ちょっと喉がやられ気味でしたが。\nAWSはやっぱり勢いがあるんだなぁってのを実感しました。JAWS-UGまで残った感想です。 あとは、セルフハンズオンに参加するんだったかなぁというのもちょっとあります。あんまり触ったことないんで。\n以下はいつものメモです。\nAmazon Redshiftが切り開くクラウド・データウェアハウス 自己紹介と流れとニュース 6/5からTokyoリージョンでも利用可能に！ Redshiftどんなもの？ Redshift＝クラウド型データウェアハウス オンプレの課題 初期投資、運用管理、費用対効果 EMRと同じで、分析処理向けのサービス 簡単な利用例 各種データストア→S3→Redshift 各種データストア→EMR→Redshift Data Pipelineでデータの流れの処理がかける。 データロードはパラレルに実行可能 バックアップは管理コンソールからボタンででも可能。 クラスタのリサイズも管理コンソールからできるよ。 NRIでの評価 2012年末の限定公開してすぐに先行評価に参加\nRedshiftの性能は？\n500億件からの検索処理（1週間分のデータを抜き出して処理するSQL） 8XLノード2ノードで43秒、4ノードで27.8秒、8ノードで19秒 データロドも線形に性能が上がる 1.2億件の検索処理は4ノードより8ノードのほうが性能劣化 EMRとRedshiftの比較。1.5TB、500億件でのJOIN＋集計処理でRedshiftのほうが早かった。 Redshiftのチューニングポイント\nインデックスが存在得ず、Distribution Keyでノードに分散 Sort Keyも重要。データロード時間はSort Keyをつけると遅くなる ニガテなデータ形式もあるよ。EMRとかの組み合わせにすると安く済むこともあるよ\n簡単につくれるので、気をつけましょう。セキュリティとか。統制されないものが乱立してくるんで。\nそこでNRIですよ！（宣伝） 出てきた性能に関するものだけど、「ケース１」「ケース２」とかってなってるので、その部分の詳細が書かれたレポートが公開されないとどんなのがニガテなのかとかわからなかった。\n事例紹介とか オンプレのデータをどうやってRedshiftに持ってくの？ インフォテリアのASTERIA WARP GUIツールでデータの変換とかして、S3に持って行って、Redshiftと連携できるよと。 無料セミナーの紹介 6/21、8/2にRedshiftの無料セミナーやりますよ。 インターネット上のユーザーの行動の可視化を実現したAWSによるビックデータ解析基盤 C-Finderのサービス紹介 元オプトの方。C-Finderの紹介。 10万ユーザの行動履歴の可視化。\nサイトに来たけど、行動せずに他サイトに移動したとか、サイトに来る前の状態ってのがわからない。これをC-Finderで可視化。\n例１：自動車業界 ライバル企業の動向を自社と比較したい。 Audi、BMW、ベンツで可視化。 例２：化粧品業界 Web上での化粧品のトレンドが見たい。 @cosmeサイトのPVとかから。 ユーザって会員登録とかしてる人を追っかけてるってことなのかなぁ？ よくわかってない。。。\nレポーティングサービスしてたけど、納品まで１ヶ月かかってた。 リアルタイムにみたいという要望が多かったのでASPをTISと開発 ASPサービスの開発したよ AWSで。 可視化というタイトルだったんだけど、期待してた可視化の話ではなかった。。。\nネット選挙クラウド　～オバマ大統領選挙の事例：データ解析からネット募金まで～ ボランティアで構成ってすごいな。 本番まで１年 みんな髭の人だｗ GoogleとかFacebookとかの人がボランティアで開発に参加。 予算は抑えながら、スケールアップダウンがすぐ出来てとか。 秒間10万回のI/OのDB SQSとEC2のSoftware queueの比較。Softwareキュー選ぶと、さらにドレがいいのかってのを選ばないとい。 AWSにあるサービスなら、造らなくてもいいのではとか。 CloudSearchはつかわなかったのかなぁ？ tsunami S3に静的ページをおいて、最後のとりでにしたり。 コードとか、ノウハウってどこまで公開されてるんだろ？ 同時通訳もあったんですが、英語を聞いてみようと聞いてましたが、まだまだダメですねぇ。\nパネルディスカッション「ウェブテクノロジーをエンタープライズで活かすには？」 趣旨 B2B、B2C間でのトレンドのやり取りが加速されてるよねと。 ICTはもはやコモディティ？ TD太田さん Consumerization Of IT 色々なものがSaaSになってきてる TD：Consumerization of Data Infrastructure オンプレ＜AWS＜TD 三井物産黒田さん 三井クラウド（プライベート＆パブリック） ユビキタス これまで使ってきたものがクラウドで動くのかとかが観点 電通平川さん マーケティングダッシュボードはsalesforceでは厳しかった？ ビジネスに注力したいので、柔軟で、質実剛健なICT基盤がほしい。 ディスカッション 新しい技術に対するスタンスは？\nいかにダメな部分を潰していくか（太田さん） R\u0026amp;Dを予算化して評価して取り組んでいく。評価でダメならつぎ。（黒田さん） 消費者の方たちがネットですごい勢いで活動してる。その人達へのアプローチが重要。（平川さん） コンシューマ系技術の懸念事項は？\nセキュリティ面。レベルがある。自分の所だけじゃなく、クラウドベンダーと二人三脚が必要。丸投げはNG（黒田さん） セキュリティ面の攻撃を受けたつぎの手をどう打つかが重要。堅牢性上げると、ユーザビリティが下がる。（平川さん） 法規制的に出せないとかもある。持ちきれないデータもあるよね。（太田さん） 何を見分けてどうやって取り組むか？\nとりあえず、やってみる。そこで見える課題に対応していく。見極めるのは難しい（平川さん） ということは、すぐに出来る環境ってのは当たり前になってますよね。\n尖った技術＝セキュリティ面が弱い？みたいな印象があるのかなぁ？\nJAWS-UG AWSアップデート AmazonのCTO登場 Game Day Game Day。土曜日にやるよ。 障害を発生させて、それを復旧させる。 最もひどい壊し方をしたらかちｗ 最後はかるくボッチでした。。。 AWSあんまり使ってないからなぁ。。。\n","date":1370527200,"dir":"post/2013/","id":"d12c1c2a68be4c7fda5a7737d5493b4d","lang":"ja","lastmod":1370527200,"permalink":"https://blog.johtani.info/blog/2013/06/06/aws-summit-tokyo-day2/","publishdate":"2013-06-06T23:00:00+09:00","summary":"昨日に引き続き、AWS Summit Tokyo 2013に行ってきました。 @ryu_kobayashiさんからパシリを仰せつかるなどあり、忙しかったのですが楽しか","tags":["AWS","勉強会"],"title":"AWS Summit Tokyo 2013に行って来ました。(Day2) #awssummit"},{"contents":"ざっとインストールガイドとかCloudera Searchのソース眺めて、テキトーにメモを書いてみました。 （ユーザガイドはまだ読んでないです。）\nざっくりメモ ストリーム処理でインデックス作るときはFlume経由でSolrに SinkとEventの両方が用意されてる？（Flumeを良く知らないので、違いがわからない） FluemeからはリモートのSolrに対してインデックス登録するクラスがある。SolrServerDocumentLoaderがソレだと思う。 バッチ処理でインデックス作るときはMapReduceIndexerToolsってのを使ってSolrに SOLR-1301がベースになっている。色々と改良されてるようだけど、コアとなってる処理はSOLR-1301。 GoLiveってクラスの処理の中で、現在動作してるSolrに配布したバッチで作成されたIndexをマージする処理が書いてある。 HDFSへ出力されたインデックスはリモートのSolrからアクセスするとオーバヘッドとかどーなるのかなぁ？ 検索処理自体はHueでもできるけど、基本的にSolrCloud任せ インデキシングの処理のフローについてはCloudera Mrophlinesで定義 ということで、 2つの流れがありそう。\nHDFS→Flume→Solr HDFS→MapReduce→Solr で、まだ、わかってないですが、構成要素として\nHadoop（HDFS）：データソース Hadoop（MapReduce）：データ変換処理、バッチインデキシング Zookeeper：SolrCloudのクラスタ管理 Solr：インデキシング、検索エンジン Flume：データをストリーミングでSolrへ Coudera Morphlines：HDFSからSolrまでのETLデータ処理を定義実行する環境 って感じでしょうか。 SolrCloudのクラスタとHadoopのクラスタが同一マシン上なのか、別なのかとか。組み合わせがどんなものができるのかがまだわかってないです。 ユーザガイド読んでみたらなにか出てくるかなぁ。\nちなみに、Cloudera SearchのgithubリポジトリにあるソースはCloudera Morphlinesのコードがメインで、SolrのHDFS対応版のソースがあるわけでは無かったです。\nSolrのHdfsDirectoryってのがClouderaのリポジトリにあるSolrには追加されていて、これが、HDFSのインデックスを読み込んだりする処理が出来る仕組みっぽい。 一応、SolrCloud以外（分散検索）も考慮された形になってるっぽい。 ってとこでしょうか。\n感想 読んでて思ったんですが、Cloudera Searchの肝はじつは、検索じゃなくて、Morphlinesにあるんじゃないかなぁと。今はSolrが出力先ですが、 その他のデータ変換処理とかが増えてくると、処理の流れがMorphlinesで定義できてデータ変換処理が簡便になりそうな気が。\nその他に気になる観点 CDH経由でSolrCloudのクラスタの管理するのかな？ SolrCloud用のクラスタとCDHのクラスタって同一マシンに載るの？別マシンにもできるの？ 併存したらIOがキツそうだけど Hueで検索アプリとか組めるの？（そもそもHueがわかってないんだけど。。。） ま、とりあえず、こんなとこで。 つぎは余力があれば、ユーザガイドかなぁ。 英語力。。。\n","date":1370489160,"dir":"post/2013/","id":"f45069216cd934b80ce882c9a2f2a08a","lang":"ja","lastmod":1370489160,"permalink":"https://blog.johtani.info/blog/2013/06/06/cloudera-search-memo2/","publishdate":"2013-06-06T12:26:00+09:00","summary":"ざっとインストールガイドとかCloudera Searchのソース眺めて、テキトーにメモを書いてみました。 （ユーザガイドはまだ読んでないです。","tags":["Cloudera Search","Hadoop","Solr"],"title":"Cloudera Searchメモ（妄想版）"},{"contents":"AWS Summit Tokyo 2013に行って来ました。\n@cocoatomoさんに行き掛けに出会ったので、アンデルセンの講演を一緒に聞いてました。 TDブースの@ryu_kobayashiさんに挨拶に伺ったりも。\nすごい人で、セッション間の入れ替え時には会場前のスペースが大変なことになってました。もう少し余裕のある建物のほうが良かったのかもしれないですねぇ。\nいつものように以下はメモです。\nRoad to AWS アンデルセンサービス とてもおいしいランチボックスでした。\n広島（ここ重要！）に本社のあるパン屋さん。\n2003年に汎用機からOpenシステムに 内製ではなく外注に。複数のSIerにお願いしてるとデータセンタに マスタ管理と生産管理はオンプレ 2004年に稼動時のネットワーク整備。店舗はISDNで、設定ミスとかを防ぐためにIIJのSMFサービスに PCはレンタル契約にしたので入れ替えを強制できる→レガシーシステムの対応が必要なくなる ネットワーク広帯域化→基本システムにデータセンターに。 2009年にリース満了などで、OSの変更とかミドルの変更という移行SI費用だけで結構な値段が。ものによっては会社もない。 データセンターの月額手数料にして、機器変更などの費用を平準化。仮想化など。 けど、サイジングにどうしても安全係数をかけてしまうことに。結構値段がかかる そこで、今後の方向性 SIerどっぷりのOLTP受発注基幹システムはSIerのホスティングで それ以外のシステムは外に出したい バッチの計算を早くすることができるとノーチラスさんから提案された バッチを外部化するか、性能あげるか。IOネックなどもありスペック上げるとコストになるから、外部化したい Hadoopを組むけど、オンプレじゃなくてAWSにした。ノウハウがないので、ノーチラスさんにお任せした。 AWSのEMRを利用。4時間かかっていたものが40分で。 EDIのサーバを6ヶ月でAWSに移行 S3絡みで2度の問題が。性能劣化があった。 パッケージ開発環境がAWSにあるなら、AWSでも動くでしょ？（NTTイントラマートとか） SIerどっぷりの部分もAWSに持っていく？ アンデルセンサービスの部長さんからのAWSへの要望 メールサーバなどの基本サビスとか、コントロールパネルを充実して欲しい。 クラウド技術を活用したリアルタイム広告\u0026quot;Logicad\u0026quot;の入札・配信・ログ解析 Web広告の歴史 最初は広告主がWebサイト単位で契約 アドネットワークによる仲介 聞きそびれた。。。DSP？ アドネッエクスチェンジ SSP(Supply Side Platform) リアルタイムビッティング（RTB） RTPの仕組みを説明。 AWSとオンプレでシステムを構築してる。\nSSP事業者との取引はオンプレ 配信はAWS オンプレとAWSはAWS Direct Conectで接続 S3とHadoopの接続が安くなったり速くなったりするらしい。 オンプレミス側 Bidリクエスト：秒間数万件。。。 KVSのユーザ数は３億件。。。 AEROSPIKEというSSD向けのKVSを利用してる AWS側 ログはS3に。溜まったデータは定期的にEMRで解析。DynamoDBに入れてレポート作成 RabbitMQを使ってる。 ELBで外部からのリクエストはバランシング データセンタ間通信 遅延を複数コネクションを貼る方法で回避？ 非同期で、複数のMsgとAckをやり取りする。RabbitMQがこれに相当する機能を持ってる QueueとConsumerで多重送信が可能。 配信結果をオンプレ側に送るのにRabbitMQを使ってるのかな？ ハイブリッド構成を支えるAWSテクノロジー 聞くつもりだったんだけど、すごい人だったので、諦めて充電してた。\nAWSクラウドで構築する、ワールドクラスの分散クラウドアーキテクチャ エマージングソリューション部の部長のshot6さん。\nマルチAZ（アベイラビリティゾーン）モデル AWS固有のコンセプト。 ELBやDynamoDBやRDS、S3とか。\nマルチリージョンとは違うよと。マルチリージョンは結構難しいので。 マルチリージョンがどんなに大変かをこれから説明。\nマルチリージョンアーキテクチャ（これは別物） 複数のリージョンを利用して作る。 AWSのビルディングブロックではカバーしない範囲をカバーしないとダメとか。 リージョン間の通信は基本的に非同期 ディザスタリカバリ コストバランス見てから決めるよね。 CAP定理とかもいろいろと出てくるよね。 合意プロトコル。正確性、生存性（時間が制限されても大丈夫）、理論的にパフォーマンス出る？ 非同期レプリケーションになる（1トランザクション当たりのオーバヘッドが大きいから）けど、復旧の難しさがある。 GlusterFSとかでやってるとこもある。 NetflixはCassandraをクオラム＋Geo-Replicationでマルチリージョンを構成してる。 マルチリージョンでのデータ一貫性は維持がむずい 注意点 必要になるまで分散させない。 まずは、マルチAZを考えましょう 物理制限を考慮する 同期型だとタイムラグあるし。 複合障害の伝搬をどう抑えるか。 NetflixはHYSTRIXというのがいて遮断できるようにしている 自動化が重要。ロールバックとかロールアウトとか。 テストをどーするの？ 本番環境でアクティブ/アクティブ構成でのテスト。 ちゃんとフェイルオーバするかなどを実環境でやってる。DB落としたり。。。 障害は避けられないので、受け入れて日常に取り込むべきだよねと。\nAmazon.comではGameDay NetflixはChaos Monkey（OSS） Obama for America リカバリーオリエンテッドコンピューティングパターン\nボーアバグ：再現可能なソフトウェバグ ハイゼンバグ：通常ではありえないパターンで発生するバグで、調査が大変 ということで、マルチAZがいいよ 同期式レプリケーションを前提にできる。 アプリ開発者がアプリにフォーカスできる。分散系の難しいところはAWSが隠蔽してくれるから。 ","date":1370424600,"dir":"post/2013/","id":"1fe14e2e02b6e65e6e6e2ae3d8ddcc9f","lang":"ja","lastmod":1370424600,"permalink":"https://blog.johtani.info/blog/2013/06/05/aws-summit-tokyo-day1/","publishdate":"2013-06-05T18:30:00+09:00","summary":"AWS Summit Tokyo 2013に行って来ました。 @cocoatomoさんに行き掛けに出会ったので、アンデルセンの講演を一緒に聞いてました。 TDブースの@ry","tags":["勉強会","AWS"],"title":"AWS Summit Tokyo 2013に行って来ました。(Day1) #awssummit"},{"contents":"Cloudera Searchは次のようなモジュールから構成されています。 これはCloudera Searchのモジュールで、さらにこれらがSolrとかを使ってるみたいですね。pom.xmlを見たら何を使ってるかがわかるかな。\ncdk-morphlines search-contrib search-core search-flume search-mr search-solrcell てきとーに、README.mdみながらメモを残してみました。ソースとかはまだ読んでないです。 ざっと眺めたけど、インデキシング処理の話がメインで、検索側がどうやって動くかってのがわからなかったなぁ。 ユーザガイド（注：PDF）ってのがあるから、これを読んでみるか。。。\n各モジュールについては、以下。\ncdk-morphlines（Cloudera Morphlines） Cloudera Morphlinesという名前みたい。 検インデキシングアプリの構築、変更をラクにするためのフレームワーク。 ETLの処理チェインを簡単にCloudera Searchにデータを入れる設定（Extract/Transform/Load処理）がかけると。 バッチ処理、Near Real Timeのために使えるみたい。検索結果をさらに入れるとかもできるんかなぁ。？\nUnixパイプラインのの進化版みたいなもので、一般的なレコードに対するStream処理から、Flueme、MapReduce、Pig、Hie、SqoopのようなHadoopコンポーネントも使えるみたい。\nHadoop ETLアプリケーションのプロトタイピングにも使えて、リアルタイムで複雑なStreamやイベント処理やログファイル解析とかに使えるの？\n設定ファイルのフォーマットはHOCONフォーマット。AkkaやPlayで使われてる。\ncdk-morphlines-core Cloudera Morphlinesのコンパイラ、実行環境、コマンドのライブラリを含んでる。 ログファイル解析やsingle-lineレコード、multi-lineレコード、CSVファイル、正規表現パターンマッチ、フィールドごとの比較とか条件分岐とか、文字列変換とか色々なコマンドを含んでる。\ncdk-morphlines-avro Avroファイルやオブジェクトの抽出、変換、読み込み処理コマンド\ncdk-morphlines-tika バイナリデータからMIMEタイプを検出して、解凍するコマンド。Tikaに依存\n雑感 Cloudera Searchへのデータの流し込みを設定ファイルに記述して実行するとデータの変換処理とかが記述できるって感じかな？ Morphlinesのコマンドとして独自処理や使えそうな処理を作ることで、いろんな処理ができるって感じかなぁ。\nsearch-core Solrに対するMorphlineコマンドの上位モジュール\nsearch-solrcell Tikaパーサを使ったSolrCellを使うためのMorphlineコマンド。 HTML、XML、PDF、Wordなど、Tikaがサポートしてるものがサポート対象。\nsearch-flume Flueme Morphline Solr Sink。 Apache Flumeのイベントから検索ドキュメントを抽出、変換し、SolrにNearRealTimeで読み込むためのコマンド\nsearch-mr HDFSに保存されたファイルに含まれる大量データをMapReduceで処理してHDFS上の検索インデックスに焼きこむモジュール。\nMapReduceIndexerToolは入力ファイルの集合からSolrのインデックスシャードの集合を作るためのmorphlineのタスクで、MapReduceのバッチジョブドライバー。 HDFSにインデックスを書き込む。 動作してるSolrサーバに対して出力されたデータをマージするのもサポートしてる。\nとりあえず、Near Real Time検索するにはFlueme使って、バッチ処理でインデックス焼くのはMapReduceIndexerToolみたいだなぁ。\n","date":1370412720,"dir":"post/2013/","id":"e30258aeb8475d4c27f7935945671856","lang":"ja","lastmod":1370412720,"permalink":"https://blog.johtani.info/blog/2013/06/05/cloudera-search-modules/","publishdate":"2013-06-05T15:12:00+09:00","summary":"Cloudera Searchは次のようなモジュールから構成されています。 これはCloudera Searchのモジュールで、さらにこれらがSolrとかを使っ","tags":["Cloudera","Hadoop","Solr","Cloudera Search"],"title":"Cloudera Searchのモジュールたち"},{"contents":"AWS Summitに来ていたのですが、TLでは、Cloudera Searchが賑わってました。 ということで、軽くどんなものか読んだり調べたりしたメモを残しとこうかと。 英語力はあやしいので、おかしいとこがあったらツッコミを。\nCloudera Searchとは？ CDH4.3に対応したCDHユーザ向けの検索システム（beta版）なのかな？ CDHに統合された検索フレームワークなのかな？\n基本はLucene/Solr 4.3でHadoopのペタバイトデータを検索することができるようになるみたいです。\nどんな仕組み？ 次のものを利用しているようです。（GithubのREADMEから。）\n使ってるもの Apache Solr(4.3.0＋α？) Apache Lucene（Solrつかってるからね） Apache SolrCloud（うーん、Solrに含まれるのに別に出してるのなんで？） Apache Flume Apache Hadoop MapReduce \u0026amp; HDFS Apache Tika SolrCellとしてSolrにも組み込まれてる、いろんな文書（WordとかHTMLなどなど）からメタデータと本文データとかを取り出せるライブラリラッパー。実際にはさらにpdfboxとかを使って各文書からのデータを取り出してる。 何ができるの？ HBaseやHDFSの用にZookeeperを使ってインデックスのシャーディングや高可用性ができる。（SolrCloudがZookeeperを使ってるからね。） MapReduceのジョブの出力から自動的にSolrのインデックスにデータをマージできるらしい。 Cloudera Managerを使って、デプロイ、設定モニタリングなどが可能。\nFlumeのフィードをつかって、ストリーミングしてインデックスを作れる。FluemeがデータをSolrに流しこむのかな？ 将来的にはHiveやHBaseのテーブルをインデックスすることも可能になるらしい。Impalaクエリの結果もフィードできるのか？\nApache Blurってキーワードも出てきた。HDFSのデータからLuceneのインデックス作るのかな？ NGDataのチームがSolr/HBaseの統合とかしてるみたい。\n参考URL Cloudera社のブログ Cloudera SearchのFAQ（注：PDF） Githubのリポジトリ ","date":1370412300,"dir":"post/2013/","id":"cd90bce912f5743226af94c1efaaa4a7","lang":"ja","lastmod":1370412300,"permalink":"https://blog.johtani.info/blog/2013/06/05/what-is-cloudera-search/","publishdate":"2013-06-05T15:05:00+09:00","summary":"AWS Summitに来ていたのですが、TLでは、Cloudera Searchが賑わってました。 ということで、軽くどんなものか読んだり調べたりした","tags":["Cloudera","Hadoop","Solr","Cloudera Search"],"title":"Cloudera Searchってのが出たらしい（とりあえず、雑感？）"},{"contents":"憧れ？のfluentを使ってみました。 こちらの記事で紹介したZoomdataを最近触っているのですが、お試しにfluentdでデータ流し込むプラグインを作ってみようかなぁと。（今は、Javaでの接続も書いていて、主にそっちを使っています。） ということで、作ってみました。fluent-plugin-zoomdata。\n基本的にはtagomoris先生のfluent-plugin-growthforecastを参考（パクリ？）にさせてもらいました。 作っている最中もここわからんってツイートに反応していただき、大変助かりました。 私はベースがJavaの人間なので、手探り状態でRubyを書いています。そこおかしいんじゃないの？とかあればコメントもらえると嬉しいです。\nZoomdataのAPI ZoomdataのAPIはこんなかんじで、JSONをHTTPSでPOSTするものになります。\n指定する必要があるものは、以下の項目です。\nsource：Zoomdataのデータ保存先（Zoomdataでのデータを保存する単位。） user：Zoomdataのユーザ名 password：Zoomdataのユーザのパスワード JSONデータ：Zoomdataでグラフ化するデータ sourceはデータ保存先の名称で、この単位でZoomdataはデータを保存、描画します。fluentdのタグをこれにするとわかりやすいかなぁ？と考えていったん、実装してみています。\nで、作成したプログラムを使いつつ、Zoomdataの検証をしたかったので、つぎのような簡単なプログラムを作って動かしてみました。\nサンプルプログラムの構成 基本的にJavaの人なので、クライアントはJavaで書いてます。 CLIプログラムで適当なJSONを作って、fluent-loggerを使って、fluentdに投げ込みます。\nfluentdにfluent-plugin-zoomdataを設定して、localのZoomdataサーバに対してHTTPSでJSONをPostする仕組みです。(初keynote)\n利用しているライブラリなどのバージョンは次の通り\ntd-agent.x86_64：1.1.12-0 fluent-logger：0.2.8 Zoomdata：1.0.3 バグ？ で、Zoomdataにいろんなデータを流し込んでみたのですが、つぎのようなエラーが出て、エラーが出力されたあとはZoomdataにデータが流れ込まなくなってしまいました。\n2013-06-03 14:42:33 +0900 [warn]: emit transaction failed error=\u0026#34;SSL_connect returned=1 errno=0 state=SSLv3 read finished A: sslv3 alert handshake failure\u0026#34; 2013-06-03 14:42:33 +0900 [warn]: /usr/lib64/fluent/ruby/lib/ruby/1.9.1/net/http.rb:799:in `connect\u0026#39; 2013-06-03 14:42:33 +0900 [warn]: /usr/lib64/fluent/ruby/lib/ruby/1.9.1/net/http.rb:799:in `block in connect\u0026#39; 2013-06-03 14:42:33 +0900 [warn]: /usr/lib64/fluent/ruby/lib/ruby/1.9.1/timeout.rb:54:in `timeout\u0026#39; 全ログはこちら。\nまだきちんと問題を調査しないでブログを書いています、すみません。\n現象 ログが発生した時の症状です。\nクライアントプログラムは送信が続いており、エラーは出ない td-agent.logに先ほどのエラーが出力 別途type fileにて出力しているログも停止 想像 とりあえず、ログを見た想像、所感です。\n問題の箇所はfluent-plugin-zoomdataからZoomdataサーバへのデータ送信部分 emit処理内部で、HTTPSでデータをPOSTする処理でエラーが起きて リトライ処理とか書いてないので、emitがコケて、その後データが送信されなくなる emitで例外をつかみそこねてるのがあるから止まってる？ とまぁ、ちゃんと仕組みを理解しないでRubyとか書くからこうなるんですねぇ。 あとでちゃんと調べて考えて、改良してブログ書きます。\n悩んでいる点、今後手を入れたい点 上記バグとは別に作りの点でいくつか悩んでる点も書いてみます。\nBufferedOutputにしてみたい fluentdのバッファリングを使って、Zoomdataが落ちていても使えるようにしたいと思っているのでBufferedOutputで書くのがいいのかなぁとか。 ちょうどいいスライドがあったので、読みながらまずは中身を理解してみよう。\nZoomdataのsource、userなどの扱い 基本的には設定ファイルで切り替えるのが妥当かなぁと思っています。\nただ、Zoomdataのsourceやuserが増えるたびにfluentdの設定を書き換えて再起動するのかなぁと。userはしょうが無いにしても、sourceは設定じゃない所で切り替えたいなぁと。\nで、切り替えるのにつぎの案があるかなぁと。\nタグで指定（今実装してるもの） メッセージにメタ情報とボディ構造を設ける 設定をどんどん増やす（やりたくない） 1と3はまぁ、いいかと。2.のパターンはどうなのかなぁと。 毎回のメッセージでヘッダ部分が送信されるのはなんだか無駄だなぁというのが否めないので悩ましいところです。1、2の両方対応できるように作るのもありか。\n{ \u0026#34;header\u0026#34;: { \u0026#34;source\u0026#34;: \u0026#34;source_name\u0026#34;, \u0026#34;user\u0026#34;: \u0026#34;userid\u0026#34;, \u0026#34;password\u0026#34;: \u0026#34;userid\u0026#34;, }, \u0026#34;body\u0026#34;: { \u0026#34;label\u0026#34;: \u0026#34;label1\u0026#34;, \u0026#34;count\u0026#34;: 1 } } ということで、fluent触って遊ぶの楽しいですね。Rubyの勉強にもなりそうだし。 ちょっとずつ頑張ってみようかなぁと。 まぁ、まだ私以外にニーズは無さそうなプラグインですが。\n","date":1370234580,"dir":"post/2013/","id":"494557db52824555864d1106278cd1f0","lang":"ja","lastmod":1370234580,"permalink":"https://blog.johtani.info/blog/2013/06/03/fluent-plugin-zoomdata-0-0-1/","publishdate":"2013-06-03T13:43:00+09:00","summary":"憧れ？のfluentを使ってみました。 こちらの記事で紹介したZoomdataを最近触っているのですが、お試しにfluentdでデータ流し込む","tags":["Zoomdata","fluentd"],"title":"fluent-plugin-zoomdata作りました＋悩み事とか"},{"contents":"最近、Markdownで文章を書くのに慣れてきました。 ということで、ブログをMarkdownで書けないかなぁと思い、TLの人たちのブログを見たりしていると 「Octopress」というキーワードがあるじゃないですか。 ということで、Github Pages作って、Octopressを使ってブログを書いてみました。 こちらです。\n独自ドメインは昨年から使っているものがあったので、ついでに独自ドメインの設定もしてみました。 ケチなので、.comなどではなく、.infoですが。。。\nということで、徐々にOctopressに移行していこうと考えているところです。 こちらのブログも当面は残しておく予定です。（有料会員は解約して、広告が出る形になると思いますが。。。）\nOctopressでこんなの便利だよとかアレば教えてもらえると助かります。\n","date":1370228038,"dir":"post/2013/","id":"16f10764f0ccce42d5be8cfeac36b446","lang":"ja","lastmod":1370228038,"permalink":"https://blog.johtani.info/blog/2013/06/03/octopress%E3%82%92%E8%A9%A6%E3%81%97%E4%B8%AD/","publishdate":"2013-06-03T11:53:58+09:00","summary":"最近、Markdownで文章を書くのに慣れてきました。 ということで、ブログをMarkdownで書けないかなぁと思い、TLの人たちのブログを見","tags":["misc"],"title":"Octopressを試し中(Jugemより移植)"},{"contents":"昨年から、ブログをどうしようかって話をしていて、そのままになっていたのですが、Octopress＋Github Pagesというのがあるらしいと聞きつけて（Twitterで見かけたのかなぁ？）ちょっとやってみました。\n最近は、ドキュメントをMarkdownで記述しようとして癖をつけているのもあり、 ちょうどいい練習になるかなぁと。\nということで、まずは手始めのエントリーでした。 いくつか書きたいこともあるので、調べながら書いていこうかと。 まだ、イメージできてないこと\n画像をどうやって貼るの？ About meみたいなのも貼り付けたい bitbucketやTwitterのリンクとかも アフィリエイトも貼る（とりあえずSolr本を） 検索とかは？ デザインは？ などなど。ちょっとずつ調べていこうかなぁと。 あ、調べたことも書いてくのもありか。\n","date":1370098620,"dir":"post/2013/","id":"dbcc4002c15afefef853a08a0804ba3a","lang":"ja","lastmod":1370098620,"permalink":"https://blog.johtani.info/blog/2013/06/01/first-octopress/","publishdate":"2013-06-01T23:57:00+09:00","summary":"昨年から、ブログをどうしようかって話をしていて、そのままになっていたのですが、Octopress＋Github Pagesというのがあるらしい","tags":["octopress","misc"],"title":"Octopress始めました"},{"contents":"Lucene/Solr 4.3.0がリリースされた（LuceneのChanges、SolrのChanges）ので、lucene-gosen 4.3.0をリリースしました。（ダウンロードはこちら） なお、lucene-gosen 4.3.0ですが、Lucene/Solr 4.2.1以下のバージョンのLucene/Solrでは利用できません。 注意してください。 また、lucene-gosen 4.2.1もLucene/Solr 4.3.0では動作しませんので注意が必要です。\n現時点（2013/05/06）では、lucene-gosen 4.3.0はLucene/Solr 4.3.0でのみ利用できます。 これは、先日のエントリにも書きましたが、LuceneにてAPIの変更が行われたためとなります。 いくつかのクラスおよびメソッドが廃止されたため、下位互換が保てない変更が入っているためです。\n独自のTokenizerやTokenizerFactory、TokenFilterFactory、CharFilterFactoryを作成されている方は、Lucene/Solrのバージョンアップを行う際は注意が必要です。\n","date":1367850324,"dir":"post/2013/","id":"11d4726484be418849e1f4200ade9535","lang":"ja","lastmod":1367850324,"permalink":"https://blog.johtani.info/blog/2013/05/06/lucene-gosen4-3-0%E3%82%92%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Flucene-solr4-3-0%E4%BB%A5%E4%B8%8A%E3%81%A7%E3%81%AE%E5%88%A9%E7%94%A8%E3%81%8C%E5%8F%AF%E8%83%BD%E3%81%A7%E3%81%99/","publishdate":"2013-05-06T23:25:24+09:00","summary":"Lucene/Solr 4.3.0がリリースされた（LuceneのChanges、SolrのChanges）ので、lucene-gosen 4.3.0をリリースしま","tags":["lucene-gosen"],"title":"lucene-gosen4.3.0をリリースしました。（Lucene/Solr4.3.0以上での利用が可能です）(Jugemより移植)"},{"contents":" アジャイルな時間管理術 ポモドーロテクニック入門 ポモドーロテクニック入門という本を読みました。 きっかけは、Twitter上で何度か「ポモドーロ」という単語を何度か見ていたためです。 最初は、なんだろう？というのが発端です。 「ポモドーロ＝トマト」なのですが、実際にはトマト型のキッチンタイマーが元になっているらしいです。 このタイマーを使った時間（タスク）管理術がポモドーロ・テクニックです。\n私は、ここ数年、複数の仕事がパラで走ることが時々ありました。 このような場合に、日によって異なる複数のタスクが存在します。 このとき、異なるタスクにスイッチするのに結構な時間を取られます。。。 また、急な割り込みが入った時も同様に、以前のタスクに戻るのになにしてたっけ？となることが多々あります。 普通に自己管理ができている方なら問題ないのでしょうが、私は結構ニガテでした。 そのようなときに、Twitter上で「ポモドーロ」という単語を見かけて、軽くググってみたところ、 タスク管理、時間管理によさそうな本だったので、その点を矯正するのも兼ねて、読んだ次第です。 また、タスクに集中できるという利点もあるそうです。\n本については、少し読みにくいところがありました。 ポモドーロテクニックとはどんなものかという全体像や単語に関する説明がないままに、話が進んでいくので。。。 1度読み終わったあとに実践しながらパラパラめくっているような状況です。 実際には、個々人のやり方などを考慮しながら、改善していくべきなのもあり、型を説明してないのかもしれないですが、もうすこし概観がわかる感じのほうが良かったです。\nで、4月初旬くらいから実践してみています。 効果が実際にあるかというと、まだわからないです。\n私がポモドーロテクニックに利用しているのはキッチンタイマーではなく、pomodairoというAdobeAIR上で動くアプリになります。 ほかにもPomodoroAppというのもあるのですが、Free版だと登録できるタスクの上限があったので、pomodairoを選びました。（今見たら、3.0にバージョンが上がって、Limitがなくなってるかも） AIRだと、WinでもMacでも動作するのというも決定した要因です。\nまだ、1ヶ月経ってませんが、私が実践してきて良かった点、できてない点、うまくいってない点はつぎのような感じです。\n良かった点 目の前のタスクに集中できる。（25分スパンなので、Twitterを意識的に見なくできる。。。） 適度な休憩が挟める。25分に5分の休憩が入るので、適度な没頭になる（没頭し過ぎない） 自宅で作業するときにかなり有効。（5分の休憩時にTwitterやFB以外に漫画をパラパラ読んだりもできるので） ということで、自宅で作業するときには結構いいです。 自宅ですと、pomodairoを使っていてタイマーの音を気兼ねなく出せるので、きちんとポモドーロが回せます。\nできてない点 アクティビティ在庫管理。個人的にJIRAを使っていて、そこで管理しようと思っているのですが、うまくできてないです。pomodairoのアプリにもタスクを登録しているのもあり2重登録などを手間に思ってしまって。。。 レコーディングと今日のTodo作成。 インタラプトの記録 アクティビティ在庫管理ができてないのは、レコーディングがきちんと出来てないためでしょう。。。 二重管理になっている＋pomodairoで統計情報が出るが、当日分の統計情報がレコーディングできてないというのが痛いです。 また、このレコーディングが出来てないので、効果が出ているかがわからないという問題かと。。。 きりが悪かったりして、どうしても、仕事時間ギリギリまでタスクをこなしてしまい、レコーディング＋アクティビティ在庫の管理の時間が取れていません。 ここは意識してちゃんとやらないと意味がないよなぁと。今後の大きな課題です。\nうまくいってない点 できてない（やろうとしてできてない）点とは別に、どうもしっくり来ていないのがつぎのような点です。\nプログラミングしていると、25分のタイマーで区切りがすごく悪い時がおおい 自宅以外でのタイマー音が出せない 自宅以外での休憩の取り方 プログラミングをやっていて、乗ってきたタイミングでタイマーが鳴ってしまったり、 ちょっと頭のなかで整理していたあとの今まさに、頭のなかにある処理の流れをコードに落としている途中でタイマーがなってしまったり。 このような状況だと、休憩に入れなくて、ずるずるとコーディングを続けてしまうということが多々あります。 メモ（ソース上のコメントや手元）を残して休憩すればいいのでしょうが、どうしても今までの癖もありズルズルとやってしまい、すごく時間が経ってることが何度もあります。 ポモドーロテクニック的にはやはりNGなんでしょうが、なかなか治らない＋治したくない気もしています。 また、自宅以外の場合、基本的には自社ではなく客先に出ていることが多いのでどうしても音を出すことができません。 これもまた、切り替えができない要因になっています。 タイマーだけ携帯のアプリを使用しするという手もあるのでしょうが、この場合さらにレコーディングが出来ない状況に陥りそうで。。。 また、スマホだと電池が持たないのも問題点です。（Twitterを見るのに利用してるから電池が持たないという話もあるのですが。。。） レコーディングに関しては、手描きのメモを使うのがいいのかなぁと。本では＋や◎などの印を付けるだけにしておけば良いとありますが、アプリのタイマーだと自動でそれができるので、悩みどころです。 最後の休憩の取り方も、ネットやTwitterを見るのもありなのですが、画面から離れる休憩を取りたいなぁと思うところもあり。。。 職場だと技術書やWEB+DBのような雑誌はあるのですが、休憩にはあまり向いていないなぁと。\nつらつらと書いて来ましたが、本を読んで、1ヶ月実践してきた（できてないとこも多いが）現状をメモしておきます。 こうやってるよ、こうしたら良かったよ、こうしてみれば？などありましたら、コメントいただけると助かります。\n来週以降はとりあえず、JIRAできちんとアクティビティ在庫管理をしながら、1日の結果をレコーディングしていくのを意識していこうと思います。\n","date":1367592139,"dir":"post/2013/","id":"db97311c24809f103575d8a7fee19680","lang":"ja","lastmod":1367592139,"permalink":"https://blog.johtani.info/blog/2013/05/03/%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E5%9B%9E%E3%81%97%E3%81%A6%E3%81%BE%E3%81%99%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF%E5%85%A5%E9%96%80%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2013-05-03T23:42:19+09:00","summary":"アジャイルな時間管理術 ポモドーロテクニック入門 ポモドーロテクニック入門という本を読みました。 きっかけは、Twitter上で何度か「ポモドーロ","tags":["読書"],"title":"ポモドーロ回してます。（ポモドーロテクニック入門読みました）(Jugemより移植)"},{"contents":"まだ、Vote公開されていない、Solr 4.3（2013/04/25 11:00現在）ですが、 ひさびさに訳してみた。詳細まで追っていないので、誤訳があるかもしれないですが。 おかしいとこあったらツッコミを。\n○Solr 4.3.0のChanges ・Upgrading from Solr 4.2.0 1.schema REST APIのcopyFields、dynamicFieldsの出力パスをCamelCaseに。他も同様。（SOLR-4623） 2.Slf4j/logging jarをSolrのwarに含めないことに。すべてのlogging jarはexample/lib/extに。（SOLR-3706、SOLR-4651） 3.SolrCloudでハードコードされてたhostContextとhostPortをdeprecatedに。Solr5.0で削除する。（SOLR-4622）\n・New Features 1.SOLR-4648　PreAnalyzedUpdateProcessorFactoryでPreAnalyzedFieldの機能をほかのフィールドタイプでも使えるようにした。詳しくはJavadocとexampleを見て。 2.SOLR-4623　REST APIで現在のschemaのエレメントをすべて読めるように。REST APIの返却の形式として、XMLとJSONとschema.xmlの形式を追加REST APIのパッケージを変更。 クラス名も変更しschemaにフォーカスした機能も除去。今後のschema以外のREST APIのために。 copyFieldsとdynamicFieldsの出力パスをすべてlowercaseのものからCamelCaseに変更。他のREST APIも同様。 3.SOLR-4658　REST APIリクエストでschemaを変更できるようにするために、「managed schema」を導入。solrconfig.xmlに「\u0026lt;schemaFactory class=\u0026ldquo;ManagedSchemaFactory\u0026rdquo; mutable=\u0026ldquo;true\u0026rdquo;/\u0026gt;」を追加。REST APIリクエストでスキーマ変更が可能にするために。 4.SOLR-4656　2つのハイライトパラメータ（hl.maxMultiValuedToMatch、hl.maxMultiValuedToExamine）を追加。 hl.maxMultiValuedToMatchは指定された数のsnippetが見つかったらそれ以降の探索を停止する設定。multiValuedフィールドがどんなに離れてても探索する。 hl.maxMultiValuedToExamineは指定された数のmultiValuedのエントリ数を調査したら探索を停止する設定。 両方を指定した場合、最初のlimitに達したら停止する。ドキュメント全体をハイライトするためにコピーされるのを削減する。これらの最適化はmultiValuedフィールドに大量のエントリが存在する時に効く。。。 5.SOLR-4675　PostingsSolrHighlighterでper-field/クエリ次のパラメータ指定のサポート 6.SOLR-3755　既存のshardを動的にsplitしてshardを追加するための新コレクションAPI（shard splitting） 7.SOLR-4530　DIH：TikaのIdentityHtmlMapperを使う設定の提供 8.SOLR-4662　solr.xmlにあるSolrCoreの定義よりもディレクトリ構造で見つける。また、solr.xmlのフォーマットを変えて、solrconfig.xmlに近くする。Solrのこのバージョンは旧スタイルの例で提供するが、新しいスタイルも試すことができる。Solr 4.4では、新しいスタイルで提供し、Solr 5.0では旧スタイルは廃止する予定。 SOLR-4347　Adminハンドラで新しく生成されたコアがsolr.xmlに永続化される SOLR-1905　Adminリクエストハンドラで生成されたコアもsolr.xmlに永続化される。また、solr.solr.datadirのようなプロパティの用にsolr.xmlに永続化される問題のfix。 9.SOLR-4717/SOLR-1351　SimpleFacetで同じフィールドに異なるファセットを適用出来るlocalParamsを追加 10.SOLR-4671　CSVResponseWriterのpseudoフィールドのサポート 11.SOLR-4358　HttpSolrServerでuseMultiPartPostでstream名を送信できる ・Bug Fixes 1.SOLR-4543：solr.xml/solr.propertiesでshardHandlerFactoryの設定が動作しない 2.SOLR-4634：Java 8\u0026quot;Nashorn\u0026quot;JavaScript実装の動作に関するscripting engineのテストのfix 3.SOLR-4636：SolrIndexSearcherをオープンする時に何かの理由でreaderがオープンできない時に、ディレクトリがリリースされない 4.SOLR-4405：Admin UIのadmin-extraファイルでcore-menuが表示されない 5.SOLR-3956：group.facet=trueでfacet.limitがマイナスの時の動作 6.SOLR-4650：copyFieldでダイナミックフィールドや暗黙的なフィールドがsourceでマッチしない。4.2で入ったバグ 7.SOLR-4641：Schemaで、illegalなフィールドパラメータで例外が発生するようにする。 8.SOLR-3758：SpellCheckComponentが分散groupingで動作しない。 9.SOLR-4652：solr.xmlプラグインのresource loaderで共有ライブラリの挙動がおかしい 10.SOLR-4664：ZkStateReaderがaliasを更新しても見えない 11.SOLR-4682：CoreAdminRequest.mergeIndexが複数コアやindexDirが複数の場合にマージできない 12.SOLR-4581：Solr4.2で数値フィールドのファセットでマイナスの値があるとソートがおかしい 13.SOLR-4699：Admin Handlerでデータディレクトリの場所がファイルシステムだと思い込んでる。（RAMの場合もある） 14.SOLR-4695：non-cloudセットアップでもコア管理のSPLITが使えるように 15.SOLR-4680：exampleのspellcheck設定のqueryAnalyzerFieldTypeの修正 16.SOLR-4702：exampleの/browseの「Did you mean?」のサジェストをFix 17.SOLR-4710：Zookeeperから全ノードをアップせずにコレクションを削除できないのを修正 18.SOLR-4487：HttpSolrServerからのSolrExceptionがリモートのサーバから戻るHTTPステータスコードを含んでない 19.SOLR-4661：Admin UIのレプリケーションで現在のレプリカ可能なマスタのバージョンを正確に表示 20.SOLR-4716,SOLR-4584：SolrCloudリクエストプロキシがTomcatなどJetty出ないコンテナで動作していない 21.SOLR-4746：Distributed groupingのトップレベルグループコマンドでSimpleOrderedMapの代わりにNamedListを使う。non-distributed groupingと出力形式が異なるため。 ","date":1366856040,"dir":"post/2013/","id":"286a9a4ee373398d7d2c93862c5f6661","lang":"ja","lastmod":1366856040,"permalink":"https://blog.johtani.info/blog/2013/04/25/solr4-3-0%E3%81%AEchanges%E3%82%92%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/","publishdate":"2013-04-25T11:14:00+09:00","summary":"まだ、Vote公開されていない、Solr 4.3（2013/04/25 11:00現在）ですが、 ひさびさに訳してみた。詳細まで追っていないので、","tags":["solr"],"title":"Solr4.3.0のChangesを訳してみた。(Jugemより移植)"},{"contents":"現在、RC3のVoteをやっている最中（2013/04/24　16:00時点）で、まだリリースされていない、4.3.0についてです。 開発者MLでChangesの書き方を考えないとね、みたいなエントリーが流れてて気になっていたので、訳してみた。 lucene-gosenの実装を変更しないといけないっぽいなぁ。Lucene/Solr 4.2.1以前と4.3.0でI/Fとかが変わることになりそうです。（3.とか8.とか） （ここで力尽きて、それより下はまだ読んでないです。。。）\n○Changes in backwards compatibility policy 1.LUCENE-4810：EdgeNGramTokenFilterが同じ入力tokenから複数のngramを生成した時にpositionを増加させていないのを修正 2.LUCENE-4822：KeywordMarkerFilterがabstractクラスで、サブクラスがisKeyword()メソッドを実装する必要がある。新しく、SetKeywordTokenFilterというクラスにすでにある機能を分解した。 3.LUCENE-4642：TokenizerとサブクラスのAttributeSourceのコンストラクタを削除。代わりにAttributeFactoryをもつコンストラクタを追加。 4.LUCENE-4833：IndexWriterConfigがsetMergePolicy(null)の時にLogByteSizeMergePolicyを使っているのをデフォルトmerge policyをTieredMergePolicyに。また、nullが引数に渡されたらExceptionを返す。 5.LUCENE-4849：ParallelTaxonomyArraysをDirectoryTaxonomyWriter/Readerのためのabstractとして作成。あと、o.a.l.facet.taxonomyに移動。 6.LUCENE-4876：IndexDeletionPolicyをInterfaceではなく、abstractクラスに。IndexDeletionPolicy、MergeScheduler、InfoStreamでCloneableをimplement。 7.LUCENE-4874：FilterAtomicReaderと関連するクラス（FilterTerms、FilterDocsEnumなど）でフィルタされたインスタンスをforwardしないように。メソッドが他のabstractメソッドを実装している場合に。（？） 8.LUCENE-4642, LUCENE-4877：TokenizerFactory、TokenFilterFactory、CharFilterFactoryの実装者は、少なくともMap\u0026lt;String,String\u0026gt;（SPIフレームワーク（Solrとか）によってロードされる）を引数にするコンストラクタを提供する必要がある。さらに、TokenizerFactoryはcreate(AttributeFactory,Reader)メソッドを実装する必要もある。\n","date":1366786800,"dir":"post/2013/","id":"99f5219da22485d0872a2529599c8440","lang":"ja","lastmod":1366786800,"permalink":"https://blog.johtani.info/blog/2013/04/24/lucene-4-3-0%E3%81%AEchanges%E3%81%AB%E3%81%82%E3%82%8Bchanges-in-backwards-compatibility-policy%E3%81%8C%E6%B0%97%E3%81%AB%E3%81%AA%E3%81%A3%E3%81%9F%E3%81%AE%E3%81%A7%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/","publishdate":"2013-04-24T16:00:00+09:00","summary":"現在、RC3のVoteをやっている最中（2013/04/24 16:00時点）で、まだリリースされていない、4.3.0についてです。 開発者ML","tags":["solr"],"title":"Lucene 4.3.0のChangesにあるChanges in backwards compatibility policyが気になったので訳してみた。(Jugemより移植)"},{"contents":"第2回目も参加しました。 とりあえずメモ。 自分には欠けてる視点の話しなので面白かった。 ちょっと寒かったなぁ。\nエンジニアのためのスキルアップ勉強会『Tech Compass』 #tecomp ― Vol.2 「人気Webサービスの作り方教えます！」 ― 日時：2013/04/23 19:00 場所：パレスサイドビル9F マイナビルーム ◎自己紹介 ●株式会社Zaim／閑歳孝子 小学校3年からFMVで草の根チャットとかにつないでた。（すげー） これがいい記事ですよ。http://www.1101.com/umeda_iwata/ テレビとかで紹介されてるZaimやってます。 3つの基準　・日常的に使うもの ・普通の人が使うもの ・少なくとも自分は使うもの サービスの良さの基準 縦軸：影響の深さ 横軸：影響する人数 この面積が大きいのがいいんでは。 ●株式会社ワディット／和田裕介 いろいろ作ってます「カウントダウンチューブ」とか「君のラジオ」とか30～40くらい作ってます。 ・「ボケて」ってのやってます。 600万ボケ。アプリ120万DL　僕らがつくるための５Wについて ・なぜ？ ・サービスの根本となる「哲学」をみんなで共有できるかが重要 ・内向けのビジョンも大事 ・何を？ ・ユースケースで整理する ・いつ？ ・つくろう！すぐ作れるようにしようねって感じ ・誰と？ ・最強のチーム。意思決定がはやい。 自分主体でサービス設計して、作りなおすのをためらわない ◎ディスカッション Q：どうしてサービス作ったの？ A：エンジニアへのあこがれから、サービスを作った（閑歳さん） ものづくりという意味では、Webサービス以外もあるけど？（馬場さん） 学内のSNSのようなものを作ってて、アクセスが伸びるのが面白かった。（閑歳さん） 大学でlastfmみたいなものを研究してて。。。（和田さん） 社会に出てサービスを作るまでの話は？作って稼ごうって思ったのは？（馬場さん） あんまりなかった。（閑歳さん） すでに起業してた。サービス作ると実績として認められて仕事が入ってきてた。（和田さん） 直接あった時に反応がもらえるのが楽しい。（和田さん） Q：どうやって、チームを組み立てたりして開発とかしてきたのか？（馬場さん） A：「ボケて」まとめサイトでブレイクしたけど、アクセス数が落ちてない。 同年代の知人で色々とチームが組めてて楽しい（和田さん） はじめは一人でやってて、しかも構想とか。あとロゴだけ最初に作ってた。 ノマド的に作業してました。（閑歳さん） Q：チームがバラバラですが、困らないですか？ A：今のところ困ってないです。もっと人が増えると困るかもしれないですけど。（閑歳さん） それぞれが他に職を持ってるので特に困ってないです（和田さん） 向き不向きはあるんじゃないかなぁ。10人とかになるとどうなるか不明（閑歳さん） GoogleのMLでレスが早ければ問題ないかな。（和田さん） あとは、チームが大きくならないように上手く分割してる（？）（ふたりとも） Q：ユーザの声の吸い上げ方、サービス改善の判断材料は？ A：ユーザの声は聞くけど、全部取り込むものではない。 細かな点はユーザの声を取り込むけど、軸はブレないようにしてる（閑歳さん） 古参ユーザよりも新しいユーザを取り込むのが大事。（和田さん） nanapiのけんすうさん Q：品質はどうしてる？ A：セキュリティは絶対。（閑歳さん） 品質を気にするってのは難しい。品質を担保できる仕組みを作るとこまでいけるようにしたい。 投稿される画像はチェックしている。（和田さん） ","date":1366717542,"dir":"post/2013/","id":"36ff37ced0d3211db95a5ac0daac0c35","lang":"ja","lastmod":1366717542,"permalink":"https://blog.johtani.info/blog/2013/04/23/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass--tecomp--vol-2-%E4%BA%BA%E6%B0%97web%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9%E6%95%99%E3%81%88%E3%81%BE%E3%81%99%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2013-04-23T20:45:42+09:00","summary":"第2回目も参加しました。 とりあえずメモ。 自分には欠けてる視点の話しなので面白かった。 ちょっと寒かったなぁ。 エンジニアのためのスキルアップ勉強","tags":["勉強会"],"title":"エンジニアのためのスキルアップ勉強会『Tech Compass』 #tecomp ― Vol.2 「人気Webサービスの作り方教えます！」に参加しました。(Jugemより移植)"},{"contents":"だいぶ、ブログを書くペースが落ちてきてて、危機感を感じている今日このごろです。。。 今回は、個人的に利用しているJIRAのバックアップについて、ブログに残しておこうかと。\nさくらVPSのサーバを借りてJIRAを運用しています。 運用といっても、自分の備忘録のためというのが大半の理由です。 タスクを忘れないように管理するのと合わせて、その作業を行ったときのメモも残したいなと。\nバックアップといっても、同じサーバ内に保存しても意味がない＋AWSを触ると言いつつ1年以上経ってしまったので、 このへんで本腰を入れるという意味も込めてAWSのS3（ゆくゆくはGlacier）にバックアップを取る仕組みを作りました。 「作りました」というと凄そうですが、Cronとシェルだけで終わりました、なんて便利な世の中。 ということで、以下は作業の備忘録です。\n1.AWSのアカウント作成 アカウントを作ってください。ここは特に説明しなくてもいいかと。。。クレジットカードの登録が必要なのが注意点でしょうか。 アカウント作成後の1年間は無料枠と呼ばれる仕組みが用意されており、いろんなことが無料で行えます。 （まだ、S3しか使ってないので、他にももっと使わないと。。。）\n2.S3のバケット作成 AWSのアカウントが作成できたら、Amazon S3（Simple Storage Service）のバケットと呼ばれる、データの保存先を作成します。 作成手順はこちらの公式入門ドキュメント（英語）をそのまま行いました。 簡単な手順はこちら\nAWS Management Consoleと呼ばれるところから、S3のコンソールにアクセス 「Create Bucket」ボタンをクリック 「Bucket Name」を入力し、リージョンを選択したら「Create」ボタンをクリック 以上でバケットが作成されました。これだけです。WebのConsoleからファイルをアップロードすることも可能です。 ただ、今回はさくらVPSから定期的にバックアップしたいのでシェルでアクセスできるようにします。\n3.AWSのアクセスキーとシークレットアクセスキーの取得 次に紹介するs3cmdというツールを利用するのに、AWSのアクセスキーとシークレットキーが必要になります。 取得方法はこちらを参考にしましたが、今は日本語のページが用意されています。 セキュリティ証明書（Security Credentials）のページで、「アクセス証明書」というタブで、「新しいアクセスキーを作成する」リンクをクリックしてください。 アクセスキーIDが新しく表示されます。このアクセスキーIDとシークレットアクセスキー（表示リンククリック後に表示される）をメモしておきます。\n4.s3cmdのインストール 世の中には便利なものを作ってくれる方がいるもので。 s3cmdと呼ばれるS3へアクセスできるコマンドラインツールが存在します。 ということで、こちらをインストール。これまた、便利なものでインストール手順を書いてくれれてるブログもありました。（あれ、なんか、見たことある名前がURLにはいってるなぁ） インストールはこちら。\n# yum -y --enablerepo epel install s3cmd インストール後に、先ほど取得したアクセスキーIDを設定します。\n$ s3cmd --configure Access Key: xxxx Secret Key: xxxx 以上で、s3cmdが使えるようになりました。\n5.バックアップスクリプトの作成 つぎは、本題のJIRAのバックアップです。 バックアップ方法はこちらを参考にしました。ちょっと古いみたいですが。 おもなデータは「JIRAのXMLバックアップユーティリティ」にてバックアップするか、「データベースのバックアップツール」を利用する方法があります。 推奨は「データベースのバックアップツール」のようなので、私の場合は「pg_dump」にてJIRAのデータベースをまるごとバックアップすることにしています。 また、データベースには添付ファイルが保存されていないようなので、別途「/var/atlassian/application-data/jira/data」というディレクトリをtarコマンドで圧縮して保存すようにしました。 あとは、pg_dumpの結果と添付ファイルの保存先の圧縮したデータをまとめてディレクトリに保存して圧縮します。 さいごは、S3にアップロードすればおしまいです。 一応、ファイルが連綿と残り続けるのは嫌だなぁということで、ファイル数で世代管理することにもしました。 これまた、ググって見つけてきたサイトを参考にしただけですが。。。 ということで、こんなかんじのスクリプトを日時でcronに設定して動かしてます。\n#!/bin/sh TODAY=`date +%Y%m%d` BACKUP_HOME=\u0026#34;/var/atlassian/backups\u0026#34; S3SYNC_DIR=\u0026#34;/var/atlassian/backups/s3sync\u0026#34; AGE=7 mkdir -p ${BACKUP_HOME}/${TODAY}/ /usr/bin/pg_dump -U postgres -Fc jiradb \u0026gt; ${BACKUP_HOME}/${TODAY}/jiradb_backup.dump tar zcvf ${BACKUP_HOME}/${TODAY}/attachment.tgz /var/atlassian/application-data/jira/data tar zcvf ${S3SYNC_DIR}/jira_backup_${TODAY}.tgz ${BACKUP_HOME}/${TODAY} rm -rf ${BACKUP_HOME}/${TODAY} NUM=`ls ${S3SYNC_DIR} | wc -l` while [ ${NUM} -ge ${AGE} ] do DEL_FILE=`ls -lt ${S3SYNC_DIR} | tail -1 | awk \u0026#39;{print $9}\u0026#39;` rm -r ${S3SYNC_DIR}/${DEL_FILE} NUM=`ls ${S3SYNC_DIR} | wc -l` done s3cmd sync --delete-removed ${S3SYNC_DIR}/* s3://my_jira_backup/s3sync/ そこへんだよとかあれば、ツッコミを。 今のところ、S3へのsyncだけなので、このあとは、月1くらいでGlacierに落とすとかの仕組みも考えるかなぁ。これまた何かあるんだろうけど。 あとは、この応用で家のNASに溜まっている写真をS3経由もしくは直接Glacierにバックアップする仕組みを考える予定です。\n","date":1366639648,"dir":"post/2013/","id":"1ca04e5339ed1826c12fe61fd984e949","lang":"ja","lastmod":1366639648,"permalink":"https://blog.johtani.info/blog/2013/04/22/jira%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E3%82%92s3%E3%81%B8%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97/","publishdate":"2013-04-22T23:07:28+09:00","summary":"だいぶ、ブログを書くペースが落ちてきてて、危機感を感じている今日このごろです。。。 今回は、個人的に利用しているJIRAのバックアップについて","tags":["備忘録"],"title":"JIRAのデータをS3へバックアップ(Jugemより移植)"},{"contents":" HerokuではじめるRailsプログラミング入門 heroku気になってるのに使ってなくて、TDのアカウント作ってデータアップしてない軟弱者ですが、参加して来ました。。。 とりあえず、大事なことです。まずは、上記の書籍を買ってください（って中の人が言ってました。） イベントページはこちら。\n総じて、herokuの中のエンジニアの方たちがすごく情熱があって、ユーザと会話をしたがっているという感想だったようで、まだまだ、よくなりそうだなぁと。 私は、ベースがJavaなので、JavaやScala、Playで使ってる方の感想とか聞きたいかなぁ。 あと、herokuとS3の組み合わせだと思うんですが、料金とかはAmazonとheroku両方に別々に払うのかな？とかはちょっと気になりました。 AWSのアカウントも作ってS3にバックアップあげるの作ろうと思って手をつけてない軟弱者ですが。。。 今月は余裕がありそうなので、TDとか触ってみようと思います。。。\n懇親会ではTDのmuga-sanとお話できて、いくつか気になってた話ができたのでスッキリしました。 あと、株式会社サムライズムの名刺頂きました。写真載せろって言われたけど、また今度ｗ\n最後に、大事なことです。まずは、上記の書籍を買ってください（って中の人が言ってました。）\n以下は、いつものようなメモです。最後の方はちょっとくたばってたのでメモがおざなりになってます、すみません。\n日時：2013年04月04日(木) 18時30分 - 21時00分 場所：日本創生ビレッジ 事業開発支援オフィス 東京21cクラブ コラボレーションスペース ◯Ayumu Aizawa（Heroku, Inc.） ・■ PostgreSQLが9.2になりました。 ・◆ メモリが2倍。βテスタ向けにスケールアップ。 JavaとかJavaとかJavaとかデプロイしてもいいよね。 けど、メモリ2xは価格も2x！ ・● Heroku OAuthを提供。Experimentalだけど。 heroku-bouncer使うとOAuthが楽になる。 ◯Treasure Data and heroku Masahiro Nakagawa（TreasureData） ・会社紹介 ・フロントエンド部分の担当（fluentd） ・1500億レコード！？ ・投資家の中にHerokuの方がいる。 ・ターゲットは？ Cloud + Big Dataが対象 Hadoopは立ち上げるのはいいんだけどメンテナンスコストが。 Hadoopの処理基板を提供 ・Hadoop生ではなく、Plazmaを使っていたりする。 ・Viki herokuにtd-agent入れて、TDにデータ送って、Postgresに書き出して使ってる。 ・TDはどうやってheroku使ってるの？ Webコンソール。 http://console.treasure-data.com Webサイトは大体heroku fluentdとかも ・herokuのaddonとしてtd-agentを提供してる。 ・STDOUTからTDにデータ送るのもできるよと。 ◯Waza Report ◯吉田雄哉さん（co-meeting） ・まずは、co-meetingの紹介。 1文字ずつ送信してるよと ・Chief Talk Officerらしいｗ ・MongoDB使ってるって言ったら、herokuのPostgreSQLの人と話して、鼻で笑われたｗ ・すごく熱意のある人達がエンジニアとして働いてる ・ユーザの声をきちんと聞いてくれる体制ができてるミーティングだった。 ・「クラウド」って単語を聞いてない。勉強会のレベルもすごい。 ◯山本裕介さん（株式会社サムライズム） ・ニッチなブログ書いてます。 ・Java屋が見るWaza Tシャツプレゼント！ ・OSS好きが多い。 Java/Scala系の話が少なかった。Scala界隈では人気みたい ◯岡村純一さん（株式会社シャノン） ・スライド1枚も作らずに喋る人とかいました。 （すごい。。。） ・Django Playに似てて面白いかもと ・Ruby2.0 Matzが喋ってたとか ・クロージングはビールが出てきてた。 交流パーティみたいになってた。CROSSがそれに似てますね。日本でやってるイベント ◯小西俊司さん（株式会社フレクト） ・バックエンドの性能とかを収集して見ることができるツールがあるらしい。 ・クエリを登録しておくと監視ができるツールとか。（TDとかぶってる？） ・やっぱり、情熱的だし、OSS好きでオープンな感じのエンジニアが多い。 ◯Heroku LT 無慈悲なLTです。3分たったらケーブル引っこ抜きます。 （最後はくたばっててあまり聞けてない。。。） ◯山本 裕介（株式会社サムライズム） ・herokuでJava7！ Java6終わってますからherokuも移行してね！ ◯竹野 淳（Grow!） ・BoxTo？ ・コラボレーター募集！ ◯小西 俊司（株式会社フレクト） ・ExcelのテンプレートをアップロードしてGETでパラメータわたせばいいよみたいなの作ってる。 ◯大久保英樹（Job-Hub） ・CarrierWaveとかの注意点 ","date":1365128443,"dir":"post/2013/","id":"73d2fce4efa52675b35a11ee97bc2db0","lang":"ja","lastmod":1365128443,"permalink":"https://blog.johtani.info/blog/2013/04/05/heroku-meetup--8-treasuredata--waza-report-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/","publishdate":"2013-04-05T11:20:43+09:00","summary":"HerokuではじめるRailsプログラミング入門 heroku気になってるのに使ってなくて、TDのアカウント作ってデータアップしてない軟弱者","tags":["勉強会"],"title":"Heroku Meetup #8 TreasureData + Waza Report!! に参加しました。#herokujp(Jugemより移植)"},{"contents":"記念すべき！？第10回のSolr勉強会です。\n発表者が無事あつまり（本当にありがとうございました！）、今回も盛況な感じでほぼ満員でした。 ツイートのおかげか、キャンセル処理もちゃんと行なってもらえて助かりました。 開場直後にドタバタしてしまい、すみませんでした。。。\nとりあえず、第一報の記事をアップしておきます。 懇親会での話とか感想はまたあとで。\n関口さんの資料は実は、前もって見たことがある資料でした。 最初の発表にしては、少しむずかしいと思った方もいるかなぁと。 ただ、類義語の辞書は結構作るのが大変だし、探しても出てこないものなので、面白い話だったんではないかなぁと。 「ミスチル」はできないけど、「マツケン」ができるのは読みがあるからとかなんですかねぇ？って質問するの忘れてた。\n尾形さんの話は結構、みんな通ってきた道かもなぁと思いました。他の方も同じ経験してるんじゃないかなぁと。 ただ、一人でやるのはすごいですよね。検索って結構人数が割かれてない場合が多いのかなぁ。 あんまり使われていないというのが少し悲しい話でしたが。。。 サーバを要求すれば結構なスペックが用意してもらえるのはうらやましい限りですねぇ。 スキーマ変更については、レプリケーション機能を使うと追加などならうまくいくんじゃないでしょうか。（そんなツイートもありましたよ。togetter読み返すと出てきます。） フィールド名を変更しないで型を変更するなどしたらおかしくなると思いますが。\n野口さんの話はなかなかチャレンジングでいいなぁと思いました。よく挫けずに頑張られているなぁとｗ 試行錯誤した仮定も発表してもらえると同じ轍を踏んだ人が助かると思います。 大きな企業で本格的に横断的な社内検索が出来る仕組みが出来上がっているって話はなかなかきかないかなと。 どうしても、社内検索とかお金が出なくて手を付けられないといいう悲しい話が多いので、こういう話は共有したい情シスの方がいっぱいいるんじゃないかなぁと。 ManifoldCFが結構地雷を多く含んでいるのは大変そうですね。。。 SolrにもTikaが入っていたりしますが、個人的にはTikaがやるべき処理は前処理と思っているので、Solrとは別の場所でやりたいとか考えていたりします。 ManifoldCFがその辺りまでやってくれるかまではちゃんと調べてないんですが。 Solrは検索だけに注力させることで、役割を分割できるので、性能の対処とかを行うのが楽になるんじゃないかなぁとか。 ManifoldCFで困ってる人は他にもいるようなので、ジャンジャン使って、どんどんチケット上げて貢献してもらうといいかと。 また、定期的に発表してもらうと面白そうだなぁと。\n弘瀬さんの話は結構興味ある方がいたんじゃないかなと。 SolrCloudは壮大だなぁと思いつつ、手を出しづらいと思ってる方が多いと思います。 実際のサービスに投入して試行錯誤された話を細かな数値も上げて発表してもらえるのは検証をやる方の助けになります。 残念ながら、私もSolrCloudは興味有りつつちゃんと追っかけてないので、途中でnodeとshardとcoreの関係がわからなくなってしまいましたので。。。 もう一度勉強して、スライドを見たいと思います。。。 分散検索（1つのインデックスが複数のcoreやshardに分割された状態）が絡んでくると、複数台の検索の性能のうち、一番遅い性能が最終的な検索性能に響いてくるので、検索リクエストの偏りとかも影響が出たりするかもしれないなぁと。 そういった意味でも試行回数を3以上で計測した結果で再度発表してもらうと面白そう！（なんか、下心見え見えですがｗ）\n前回、今回も感じたのですが、もう少し質問をしてもらえると発表された方も励みになるかなぁと思いました。 質問しにくい雰囲気になってるのでしょうか？参加者が結構いるから質問しにくく感じたりするのでしょうか？ そのあたりをもう少しうまくやれるようになにかコメントもらえると嬉しいかなぁと。 運営で気になった点などもコメントやツイートをいただけると今後の改善にも役立てますので気兼ねなく連絡いただけると助かります。 開場がドタバタしすぎとか、ハッシュタグがわからなかったとか。\n今回は思ったよりも懇親会に残る方が少なめでした。 コミッターの方（LuceneやManifoldCFとかlucene-gosenとか）が複数いたり、Solrを結構触ってる方がいたりと面白い話が聞けそうだったのですが。。。 Kuromojiのユーザ辞書の改良点をチケットにあげるって約束したのでやらないとなぁ。 早く帰るつもりだったのに気づいたら23時でしたwやっぱり色々と話ができるのが楽しくて。。。 駅前の機動隊とかびっくりしながら帰りました。 今回、お話ができなかった方もいらっしゃるかと思いますが、気兼ねなく、ツイートしてもらったり、声をかけていただければと。\nあと、常に発表していただける方は歓迎しておりますので、連絡いただけると非常に助かります！ こんな話が聞きたいなどでもいいかと思いますので、連絡いただければと。\n#SolrJPもtogetterにまとめてもらいました。ありがとうございます。 以下は、いつものメモになります。\n日時：2013/03/26 19:00 to 21:00 場所：VOYAGE GROUP 会議室 1. 株式会社 ロンウイット　関口　宏司さん タイトル：Wikipediaからの類義語知識の自動獲得について 発表資料はこちら\n・「辞書型コーパス」という単語は造語かもしれません。 ・なんでこんなことを？ →類義語辞書を自動生成したいから。 ・自賠責保険、自動車賠償責任保険を例にSynonymFilterの説明。 ・Wikipediaを入力として、類義語辞書を作成するときにLuceneのインデックスを活用してる。 ・類義語候補の見つけ方 いくつかヒューリスティクスな処理とかも入れてます。 日本語Wikipedia固有なもの。 ・実際に導出された単語も載ってる。 FTPなども導出で来てる。 丸ビルとかも。 ・導出できなかったものもあります。 「十六進法」が「十進法」になってる 「ミスチル」も無理。 ・ミスもあるけど、類義語が存在しない場合になんとなく、使う辞書としては採用できるのでは？ 類義語検索対象のブーストを小さくするなどをすれば役に立つ Q：類似度にしきい値を用意したりしてますか？ A：min.scoreという値を用意し、足切りをしている。 Q：ベクトルを作るという話があったが、品詞でフィルタリングとかしてる？ A：名詞に限って処理してます。名詞に限らなくてもいいかも。。。（若干聴き逃しました） 重みの高いn件をベクトルの対象にしてます。 2. グリー株式会社　尾形　暢俊さん タイトル：GREEにおける全文検索の歴史 発表資料はこちら\n・GREEさん、検索はないがしろにされてる。。。 一人でつくって、一人でメンテナンスしてる。 ・GREEの検索は右上の検索ボックスが ・2007年はSennaつかってました。 Tritonnに移行。2009年くらいまで。 やっぱり安定しない＋MySQLのバージョンアップしたいけど、追従できない ・2012年初頭までLuceneでやってた。（結構古い） フラグメントが発生してOptimizeすると、検索サーバが使えなくなる。。。 検索しにくるサーバが1000台いるので、Optimizeかけるときに、1000台のサーバの設定を書き換えるとかしてた。。。 ・現在まではSolrをつかってる。 Luceneのバージョンも古かったので100倍くらい速くなった。 ・Solr本が必須ですよ！！！ ・Lucene+Tomcatから移行。 移行に気をつける点として、I/FをそのままSolrに置き換えると。 Solr返却のXMLをカスタマイズしたり、クエリをSolr向けに書き換えたり。 あと、メンテナンスが楽になるように。 40数台のインデックスサーバがあると。 一人でメンテナンスしてるから、楽になる方法が重要 ・レプリケーションで、Optimizeの影響が出ないように。 キューをつかって、マスタに登録して、スレーブにレプリカを配布 ・スキーマが7つ あんまり使われてなくてかなしい。。。 ・負荷のグラフもありました。 ・RangeQueryを結構使う。 ・作りこんだ部分 インデックスのMasterへ分散させる処理とか クエリの変換とか人力監視処理とかNGワードとか サーバ監視のための仕組み ・今でも大変なこと スキーマ変更が大変 スレーブをマスタに昇格とかが手動 ・今後改善したいこと 精度を上げたい 辞書を使ってみたいけど、各国語対応 あと、自動化とか 3. ソフトバンクBB株式会社　野口　勝義さん タイトル：企業内の大規模ファイルサーバ検索事例 ・情シスの企画版？という立場のかた。 ・売上に貢献したいのでクラウドサービスとして検索をオプションとして立ち上げてみた！ ・Solr＋ManifoldCFで作ってみたよと ・なんでSolr？ OSSだし、機能が充実 ・なんでManifoldCF？ Active Directory連携が使いたかったと。 社内検索ってやっぱりアクセス権がうるさいので。 ・ManifoldCFの説明はロンウイットさんの画像を使わせてもらいましたｗ ・ファイルサーバが、70TB。。。 ・困ったこと。 ・その１ ・クローラージョブの構成の最適化どうする？ ・マルチコアで、クローラーとファイルサーバを1対1の構成にしてみた。 ・その２ ・ファイル数が増えるとまた問題が。。。 ・ファイルサイズが大きい→Heapが足りないエラーとか、MCFのタイムアウトとか。。。 ファイルサイズのリミットを設けてみた。 mp4とかでエラーがでるとか。既知のエラーでしたとか。 ulimitがたりないとか。 MCFの稀に出るバグとか。。。 ファイルサーバの不良ブロックとか。。。 ・その３ ・クロールに時間がかかる ・MySQLでスロークエリとか MySQLよく知らないとか言われながらコミッターに対応してもらうなど。 SSDつかうとか考え中 ・フルクロールで1週間 差分でも1日強かかる。 ManifoldCFだけで対応できないから、ファイルの特徴を元に →ManifoldCFを経由しないリアルタイムインデックス更新のAPIを経由してMasterじゃなくて、更新かけると。（特定のクライアントからの方法） ・その４ ・本文データをstored=falseに けど、ハイライトできないから、どうにかしたい ・ユーザの要望 ・もしかして検索 類義語？じゃないよねぇ。テザリング、tezaringuとか フロント側で頑張った。（Solr諦めました） ・検索スコアも弄りたいとか 外部データでブーストとかもしたい。External Fieldとか使うといいのでは？とか。 4. 株式会社サイバーエージェント　弘瀬　健さん タイトル：SolrCloudの導入事例 発表資料はこちら\n・Webエンジニアだったのに、検索エンジニアに！ ・SolrCloudもサービスインしてると。 ・SolrCloud概要 4.0以降の機能とか。 ・SolrCloudの構成要素 概念的なもの。Collection、Shard 物理的なもの。Node、Core ・ Simplogってサービスに導入済み。 ZooKeeperが3台、6Shard、3nodeという形式 ・性能 平均レスポンスタイム50msec 思ったより出てないので、調べてみた。node数とかshard数を変えてみて調べてみた（まだ、模索中。） ・色々テストケース試したけど、試行回数が1回だけです。 詳細なデータが出てるのありがたい（全部はまだ理解できてないですｗ） ・検証まとめ ノード当たりのcore数が少ないほうが検索、更新性能がいい 1コレクション当たりのshard数が少ないほうが検索性能がいい ・まとめ ・SolrCloudの利点 クライアントが色々意識しなくていいのがうれしい。 ・SolrCloudの注意点 shardの分割機能がまだないので、大変。 コレクション情報が壊れると検索更新できないとか。4.0だとバグが有った ・性能的には素のSolrのほうがいいよと。 ","date":1364300160,"dir":"post/2013/","id":"26d0c0d8c465087cf160a3bdc479f2b4","lang":"ja","lastmod":1364300160,"permalink":"https://blog.johtani.info/blog/2013/03/26/%E7%AC%AC10%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/","publishdate":"2013-03-26T21:16:00+09:00","summary":"記念すべき！？第10回のSolr勉強会です。 発表者が無事あつまり（本当にありがとうございました！）、今回も盛況な感じでほぼ満員でした。 ツイー","tags":["勉強会"],"title":"第10回Solr勉強会を主催しました。#SolrJP(Jugemより移植)"},{"contents":"なんか、とても久しぶりにイベント参加メモ以外の投稿です。 elastic searchのMLを見てたら、KuromojiのAnalyzerを使うときにユーザ辞書使うのどうするの？という投稿を見かけました。\nKuromojiのユーザ辞書にもちょうど興味があったり、elasticsearchもちょっとずつ触りたかったのでちょっと試してみました。（返信もしてみましたが、テキトーな英語です。。。）\nelasticsearch-kuromoji-pluginのインストールなどはElasticSearch で kuromoji を使う (ES 0.90.Beta1 + kuromoji 1.2.0篇)を参考にしてください。 私もこちらに記述のある組み合わせ（elasticsearch-0.90.0Beta1 + elasticsearch-analysis-kuromoji/1.2.0）を利用しました。 KuromojiのAnalyzerはデフォルトで「kuromoji」として登録済みですが、こちらはユーザ辞書の指定がありません。 ということで、「kuromoji_user_dict」というユーザ辞書指定をしたtokenizerと、それと使う「my_analyzer」というanalyzerを登録したIndexを作成します。 定義する前に、「userdict_ja.txt」を用意して、elasticsearch-0.90.0Beta1/config/ディレクトリに配置しておきます。 （以下のサンプルでは、SOLE_HOME/example/solr/collection1/conf/lang/userdict_ja.txtをコピーして使いました）\n$ curl -XPUT \u0026#39;http://localhost:9200/kuromoji_sample/\u0026#39; -d\u0026#39; { \u0026#34;index\u0026#34;:{ \u0026#34;analysis\u0026#34;:{ \u0026#34;tokenizer\u0026#34; : { \u0026#34;kuromoji_user_dict\u0026#34; : { \u0026#34;type\u0026#34;:\u0026#34;kuromoji_tokenizer\u0026#34;, \u0026#34;user_dictionary\u0026#34;:\u0026#34;userdict_ja.txt\u0026#34; } }, \u0026#34;analyzer\u0026#34; : { \u0026#34;my_analyzer\u0026#34; : { \u0026#34;type\u0026#34; : \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34; : \u0026#34;kuromoji_user_dict\u0026#34; } } } } } \u0026#39; 「user_dictionary」というのがユーザ辞書の定義ファイルになります。 注意点としては、6行目で指定した名前「kuromoji_user_dict」を14行目の「tokenizer」に指定しないとちゃんと動かないという点でしょうか。\n上記で指定したAnalyzerを利用して「朝青龍」という単語をを解析してみます。\n$ curl -XGET \u0026#39;http://localhost:9200/kuromoji_sample/_analyze?analyzer=my_analyzer\u0026amp;pretty\u0026#39; -d \u0026#39;朝青龍\u0026#39; { \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;朝青龍\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 3, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 1 } ] 「朝青龍」という単語がユーザ辞書に登録されているので、1単語として出力されます。 ちなみに、デフォルトの「kuromoji」のanalyzerを指定すると以下の様な出力です。\n$ curl -XGET \u0026#39;http://localhost:9200/kuromoji_sample/_analyze?analyzer=kuromoji\u0026amp;pretty\u0026#39; -d \u0026#39;朝青龍\u0026#39; { \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;朝\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 1, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 1 }, { \u0026#34;token\u0026#34; : \u0026#34;青龍\u0026#34;, \u0026#34;start_offset\u0026#34; : 1, \u0026#34;end_offset\u0026#34; : 3, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 2 } ] とまぁ、こんなかんじです。 ユーザ辞書を書き換えたあとは「close/open」しないと読み込めないのかなぁ？そのへんはまたあとで調べようかな。\nちなみ、以下のページを参考にさせてもらいました。 elasticsearch kuromoji plugin - natural days ElasticSearch で kuromoji を使う (ES 0.90.Beta1 + kuromoji 1.2.0篇)\n","date":1363765380,"dir":"post/2013/","id":"f5f28f42ad234b4389af4cbea54ff60d","lang":"ja","lastmod":1363765380,"permalink":"https://blog.johtani.info/blog/2013/03/20/elasticsearch-analysis-kuromoji%E3%81%A7%E3%83%A6%E3%83%BC%E3%82%B6%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%88%A9%E7%94%A8%E6%96%B9%E6%B3%95/","publishdate":"2013-03-20T16:43:00+09:00","summary":"なんか、とても久しぶりにイベント参加メモ以外の投稿です。 elastic searchのMLを見てたら、KuromojiのAnalyzerを使うときにユーザ","tags":["elasticsearch"],"title":"elasticsearch-analysis-kuromojiでユーザ辞書の利用方法(Jugemより移植)"},{"contents":"久々にブログ＋イベント参加です。 知り合いが開催＋出演したので参加してみました。 「スマホ」ってキーワードはあまりなかったけど、面白かったです。\nとりあえず、メモ。 余力があれば感想追加します。\n日時：2013/03/19 19:00 場所：パレスサイドビル9F マイナビルーム （東京都千代田区一ツ橋1-1-1） URL：http://atnd.org/events/36966 登壇者：@naoya_ito @yusuke ◯@naoya_itoさんの発表 最近、感心してること。 ・RubyMotionやってます。 今年5月に ・AWSもやってるよ。 ・「継続的デリバリー」の話 GREEでは毎日デリバリーしてるよと。 ・Chefの話 DevOpsとか。 ・Obama for Americaの話 GitHubとか使ってた。 身に付けるべきものは？ 「変化に適応する力」が必要だよね。 最近は Ruby、クラウド、AWS、iOS開発とかやってる、どうしてこうなったｗ 先は予測してないけど、変化に適応するには5分でいいからやり続けること。 ◯@yusukeさんの発表 自己紹介が難しい ・今やってること ブログ執筆 刺さるツイート研究 ソフトウェア販売代理店 思わぬ収穫。InDesign/Illustratorのスキル、ビジネスの仕方ｗ 会社設立中。 Webサイト構築・運用 ・ハッタリが大事 ・プログラム好き プログラミング以外を仕事にしてる。 ・人と違うことがしたい。市場がない場所での差別化はしない＝トレンドに逆行し過ぎない。バランス。 ・今は種まき中。 ◯ディスカッション ・2,3年後とか何やってると思いますか？ @naoya_itoさん ドラクエやってると思ってるかもしれませんが、サービス作るコード書いてます。 将来的な見通しでやってるのか？って言われるとそうでもない。 ツールとかよりは、コミュニティとかのサービスを作るほうが好き。 @yusuke 一定の収入がありつつ、プログラミングしてたい。あわよくばサービス作ったのが当たるといいなぁ ・そもそもフリーランスをどう捉えているか？ @naoya_ito いいところ。自由に自分の時間をコントロールできる。 悪いところ。自分でコントロールしないといけない。 自分をコントロールしないと厳しい。 フリーになってわかったのは、会社は人間を働かせるための仕組みをよく考えて出来てる。 フリーでいいのは、選択した結果に自分が責任を持つというのがいい。 @yusuke セフルマネージメントできたほうがいい。 しがらみを捨てるためにフリーになるのはおすすめしない。 ・情報発信を継続してるけど、必要なことか？ @naoya_ito 必要とは思わないけど、みんな書いたらいいと思う。 検索すれば自分が助かるからｗ セルフブランディングのために重要？かなぁ。あまりそれが唯一の方法ではないと思う。 @yusuke 発信することで、何に興味を持ってるかをわかってもらえるから、便利かな。 ブログに残したほうがググって引っかかるよと。 ・技術の方向性？見つけ方？は？ @naoya_ito 直近は、クラウド流行るしiOSはまだ伸びてるしと。 そっから先はどうするの？ わからないよね。じゃあ、どうするの？って変化に対応してボトムアップで見つけてくのがいいんじゃないかなぁ。 人がやってないところを先にやらないと武器にならないけど、どうやって見つけるのか？ プログラミングやってる時に、その先に必要なこととか、気付きがあるので、手を動かさないとだめだよねと。 @yusuke トレンドを追いかけつつ、知ったかぶりするのは重要 ある程度ハッタリ＋手を動かす ","date":1363692480,"dir":"post/2013/","id":"5412fb82160d0f6093e4b6670f505c13","lang":"ja","lastmod":1363692480,"permalink":"https://blog.johtani.info/blog/2013/03/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass%E7%AB%B9%E6%A9%8B--vol1-%E3%82%B9%E3%83%9E%E3%83%9B%E6%99%82%E4%BB%A3%E5%88%B0%E6%9D%A5%E3%81%93%E3%81%AE%E5%85%88%E7%94%9F%E3%81%8D%E3%81%AE%E3%81%93%E3%82%8B%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%A8%E3%81%AF%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-tecomp/","publishdate":"2013-03-19T20:28:00+09:00","summary":"久々にブログ＋イベント参加です。 知り合いが開催＋出演したので参加してみました。 「スマホ」ってキーワードはあまりなかったけど、面白かったです。","tags":["勉強会"],"title":"エンジニアのためのスキルアップ勉強会『Tech Compass』＠竹橋 ― Vol1 「スマホ時代到来、この先生きのこるエンジニアとは！？」に参加しました。#tecomp(Jugemより移植)"},{"contents":"技術ブログから離れていってますが。。。 Xperia Zを購入しました。\n前に使っていたのはXperia arcになります。 もうすぐ２年だったのですが、容量不足に悩まされていたため＋芸の肥やし（仕事の足し）という名目で Xperia Zの購入に踏み切りました。 予約しての購入です。\nいくつか戸惑いなどを感じているので備忘録としてブログに残しておきます。 サイズが大きい___ まぁ、わかっていたことですが、5インチと大きいです。 ステータスバーを表示するのがちょっときついくらいです。 私は手が大きい方なのですがそれでもキツイので、普通の人は両手じゃないと厳しいんじゃないかと。。。 一応、ステータスバーを表示するためのアプリなんかもあるようなので、その辺を検討するのもいいかなぁと（まだインストールもしてませんが。） また、Angry Birdを演ってびっくりしたのですが、解像度が大きいため、startボタンなどが小さくて押しづらいですｗ\n移行がめんどくさい___ iPadも持っていて、ソレと比較するとひどくめんどくさかったです。 実は方法を知らないだけかもしれないんですが。。。 iPadだと、初期化したりしてもiTunesにインストールしたアプリなども覚えていてくれます。 ですので、すぐに同じ環境が出来上がります。 Xperiaに関しては、arcでインストールしてたアプリをインストール履歴を元に一つずつインストールして、 それぞれのアプリやアカウントを設定して行きました。 これが結構面倒で、まだ完全にはアプリがインストールできてないかも（他にも新しいものを入れたいなぁと思いつつ、探す手間を惜しんでます。。。おすすめアプリお待ちしてます。）\nZite、Angry Bird star warsがインストールできない___ Ziteは英語の勉強も兼ねて入れていたのですが、対応していないバージョンですと言われます。 AngryBirdもいっしょですね。 starwarsじゃない奴はインストールできたのですが、肝心のやってみたいstar warsがインストールできなくて。。。\nドコモアプリがいっぱい___ ドコモのアプリやプリインストールアプリがいっぱいあったので、どうしようか悩んでいます。 いくつかはアンインストールしました。HotpepperBeautyとか間違いなく使わないし SFA-QRというよくわからないアプリも入っていたのでこれまたアンインストールしました。\n通知に出さないアプリとか選択できない？___ 容量不足だったのも有り、TwitterクライアントにはTwiccaのみをインストールしていたのですが、今回はTwitter純正のクライアントもインストールしました。 お気に入り登録されたりといった状況も見れるので重宝するのですが、基本的にはtwiccaを使うつもりです。 ですが、通知バー（ステータスバー）に@ツイートが届いたなどといった通知は見なくてもいいと思っているんですが、なにか方法あるんでしょうか。\ndビデオが危険___ いわゆる携帯ショップで機種変更したため、いくつかのサービスに登録しないといけませんでした。 で、dビデオ（月額525円で映画とか見放題）に登録したので、せっかくだからと映画をダウンロードしてみたのですが、危険です。。。 ただでさえ、本読むのが遅かったり、コーディングしてないのにビデオ見ると更に時間ががが。。。 けど、面白くて。。。危険です。（スターシップ・トゥルーパーズ見ちゃいました。。）\nクレードルがもう一つほしい___ 防水なので、あまりキャップを開けたくないんです。 そして、dビデオとか見てるとやっぱり電池の減りがはやいんです。（ディスプレイが大きいのもあるのかなぁ。要らないサービス切るとかしないと） 結局、出先でも充電をしないといけなくて。 ただ、純正のクレードルが2100円と結構な値段でして。。。 あと、イヤホンを指すところもキャップがあるので、Bluetoothレシーバーも気になってたりします。 こちらも結構な値段でして。。。\nとまぁ、新しいものを手に入れて、色々悩んでますが、楽しいですね。購入したての色々と悩む時間がｗ おすすめアプリとかあったらコメントください\n","date":1360687980,"dir":"post/2013/","id":"b051fd352847c06e748b345e8ed0738b","lang":"ja","lastmod":1360687980,"permalink":"https://blog.johtani.info/blog/2013/02/13/xperia-z%E8%B2%B7%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2013-02-13T01:53:00+09:00","summary":"技術ブログから離れていってますが。。。 Xperia Zを購入しました。 前に使っていたのはXperia arcになります。 もうすぐ２年だったのですが、容量不","tags":["備忘録"],"title":"Xperia Z買いました(Jugemより移植)"},{"contents":"金曜日に引き続き、イベントに参加して来ました。（仕事。。。これも仕事だよ。）\n「Hadoop Conference Japan 2013 Winter」です。 普段、Hadoopを触るのも少ないのですが情報を仕入れときたいなぁということで。 今年はビッグサイトですよ。そろそろ無料のカンファレンスもキツイのではないでしょうか。。。 こちらの写真はセッション会場。今回もすごいです。。。 簡単ですが、聞いていた感想です。 全体的に、Hadoop本体の話ではなく、エコシステムと呼ばれる周辺のプロダクトの話や実際に運用している実例が増えていました。 だいぶ普及期に来たのかなぁと。そして、自分の不勉強を実感できたなぁと。 （あと、TreasureDataに絡む話が多いなぁと言うのも印象です。そういうセッションを選んで出ていたのかもしれませんが） 懇親会まで残っていたのですが、結構、すごい方たちの顔ぶれだなぁというのを今更ながらに実感するとか。 （ハチ象Tシャツを着ているすごい集団でもありましたが。。。）\n以下はいつものメモになります。だいぶ金曜日のイベント後で腑抜けてるのでメモが雑ですが。\n◯ご挨拶 Doug Cuttingさんのビデオ（あんまり聞けてない）　さすがのhamakenさんのトークの安定感。 後援はリクルートテクノロジーズさんが大半。 リクルートテクノロジーズの米谷さんが軽く発表 ◯LINEのHBaseを利用した大規模なメッセージストレージ：NHN Japan 中村 俊介 まずは、LINEの紹介が続く。 New Yearのメッセージは3倍位だったけど、何とかなっったよと。 データロスがない。 サーバ故障からのデータリカバリも自動でやってくれる 書き込み1ms、読み出し1-10msでできてる ・IDC onine migration クライアントベースで2つに書き込み Incremental replication（新データ）、BulkMigration（旧データ） 元のHBaseのレプリケータは利用してない（pushだったから。スループットコントロールしたかったから） ・NN failover 2012.10にNameNode障害発生 HA構成にしてたから問題が発生。 VIPはHDFSにつかうとリスキー 現在： 少ないダウンタイムを許容する ・Stabilizing LINE message cluster ※あとでHBase触るときに資料見直すくらいで。。。 Case1：Too many HLogs Case2：Hotspot問題 まぁ、けど1億ユーザのインフラとして使えるってすごいよな。。。　◯Hadoop meets Cloud with Multi-tenancy： Treasure Data 太田 一樹 TDもFluentdも有名だなぁ Hadoopのメンテナンスとか、つらいよねというのを見てきたのでTD作った ・なぜ、BigData+Cloud？ Hadoopだけみてもバージョンが混在してる＋ディストリビューターも多くなってる 十徳ナイフみたいになってきてるけど、必要なのはナタだよね。というのを提示するためにTD立ち上げた。 ・なぜCloud？ ・IaaSベンダーの対象としてるのはSCM。 オンプレだとHWが陳腐化してくよね→HWはクラウドが主流に ・PaaS、SaaSの対象は時は金なり バージョンアップとか大変だよねと ・TDのご紹介 唯一の解析用DBを目指して ・哲学とアーキテクチャ 解析とか運用をいかに楽にしていくかというのを主体においたサービスを提供したい？ いかに速くレポーティングシステムを簡単に構築していくかとかの話 簡単なインタフェースと目的に集中することで、価値を提供 ・AWSとの違いは？ ・アーキテクチャとか技術的な話 データを集める処理がデータ解析に実際には重要なフェーズ ・カラム指向でデータ保存 実装がどーなってるのかとか、TD内部のHadoopクラスタの運用、バージョンアップとかがどうなってるのかもきになる。（企業秘密だろうけど） ◯Amazon Elasti MapReduceとHadoopコミュニティの関わり：Amazon Web Services Peter Sirota ・３つのV Volume、Velocity、Variety ・yelpのAuto-suggestの例 カスタマーのレコメンデーションにElasticMapReduce使ってるよと。 ・razorfishの広告インプレッションの解析に使ってる ・Amazon.comでの話 AWS Public Datasetsの話 http://aws.amazon.com/jp/publicdatasets/ IonFluxのDNA解析の話 ・いろんな分野でのBig Data 事例がちらほら ※わかりやすい英語なんだけど寝不足が。。。 ◯ランチ！ サンドイッチと豚汁とあとなんとかライス。 TDブースにて、fluentdのTシャツもらったよ！ ◯Hadoop\u0026#39;s Power to Transform Business：MapR　Ted Dunning ・Mahaut＋Solrの単語が。8時間のレコメンデーションデータの作成が3分に？？ ・Stormにてリアルタイム処理と連携。バッチ処理はMRで。 ・バッチ処理とリアルタイム処理の間としてのDrill ・Drillの概観とできるところの話。 （あとでスライドで）データ解析のために機会学習の処理とかも投げられそう。 Q：ImplaraとDrillの違いは？ コミュニティベースかなどが違うよね（あまり聞き取れず） Q：Drillの開発はどのくらいすすんでるの？ A：。。。 Q.クエリ言語としてSQLがいいの？ A.No。というのも、単独の言語ですべてにベストというのはないから。SQLはわかりやすくて良いが、実行が非効率な場面も。 ◯Introduction to Impala～Hadoop用のSQLエンジン～：Cloudera　川崎 達夫 ・Impalaとは 分析に特化した低レイテンシクエリ実行基盤 Apacheライセンス バッチ処理要ではなく、データサイエンティストが試行錯誤するときに利用するのを想定 パフォーマンスが良い 実行エンジンはC＋＋とかで実装されてる MapReduceに依存してない ・MapReduceの問題点 MR直接は難しい→Hiveとか、M/Rの実装を隠して使いやすくするものが増えてきた Hiveを例に説明。MRがベースなので高レイテンシ ・Impalaのアーキテクチャ 機能制限やGA版について言及されてる資料なのが良い ・GA以降の話もあり ピンチヒッターなのに落ち着いて発表とか凄すぎです。 jdbcサポートも入ると。 プランナーはjava実装 Hiveとの互換性は？→完全互換を目指す。 開発のプロセスが見えにくいのでは？開発主体がcloudera ◯Flumeを活用したAmebaにおける大規模ログ収集システム：CyberAgent　飯島 賢志 立ち見。 Flumeのコミッターの人がCAにいたんだ。 ◯Log analysis system with Hadoop in livedoor 2013 Winter：NHN Japan　田籠さん@tagomorisさん ・NHNJapanのお話 ・Webサービスのログ解析について話していく 400+Webサービス ・2011年8月にLTしました。 ・1.5TB/day。。。 ・batchとstream Batch集計も重要だし、Stream処理も重要なので、ハイブリッドシステム ・システムーバービュー FluentdClusterを中心にして各種ツール、保存先に転送してる。 これが結構重要。だけど、今日はFluentdの話ではない ・Fluentd周りを一人でやってるのか。。。 ・処理の流れ ・ログの収集と、生ログ保存 ・パース（主にHive用に）、変換、フラグ追加（分類しておくとあとで集計したいとか、保存すべきかを処理可能に） ・Hiveにロード ・第1世代のはなし すべてbatch処理、Scribe 遅延が1時間ちょっとあるため、Hiveクエリで結果が見れないとか。 ・第2世代の話 Fluentdのstream処理にHadoop Streamingを呼び出せるようなプラグインを書いた Fluentd＋HoopServerの構成 ・第3世代 HoopをWebHDFS Fluentdでのオンライン集計 GrowthForcast、HRForcast ・第4世代（ここ1週間でやったこと） CDH4でQJMベースのNameNode（Failoverは手動） Hiveのスキーマを変更（これはブログに今度書くよ） とりあえず、現時点で改善点が思いつかない ・総括 HTTPベースでRPCベースにしたのでコンポーネント切り替えが結構楽 OSSで公開されてるからいいよね 公開することにより色々とドライブするよ！ ◯いかにしてHadoopにデータを集めるか：Treasure Data　古橋 貞之 ・自己紹介 ・ビッグデータ収集の問題点 ・壊れたデータが入ってる ・読み書きの時間がかかる ログはサブケースである。メインはサービスとかだから。 ・トライ＆エラー処理が時間かかる ・データを分割するのが基本的なアイデア 失敗した時のリトライが楽になる。さらに、それをStream処理すれば良いよねと。 ・flumeのお話 ・fluentdのお話 バッファリングは性能アップも兼ねてる 設定のクラスタへの伝搬とかインストールはpuppetとか使おうねと。 プラグインのインストールが楽 ・いくつかのプラグインの紹介 ・TDへのデータ投入のお話 ・最後にmuddydixonさんのプラグインの宣伝がw ◯Hadoopの次に考える分散システム技術：Microsoft　萩原 正義 ・CAP定理の克服をどうしていくか ・CAPのおさらい ・Lease クライアント主導、サーバ手動とか （理論重視の話で最後のセッションには辛かった。。。頭が疲れててついていけませんでした） おまけ 今回頂いたノベルティなどを写真に撮ってみました。（ランチはお腹すいてて写真取らずに食べちゃいました。。。） Hiveロゴへの愛を語ってHive Tシャツをゲット。 FluentdのTシャツももらいました！ Hiveステッカーなどもゲット あと、メッセージボードなるものがあったので書いてみました。一応、Hadoopに絡んだことですよね！？\n","date":1358783400,"dir":"post/2013/","id":"bf4f86812812dab8d39db9aaefe94a78","lang":"ja","lastmod":1358783400,"permalink":"https://blog.johtani.info/blog/2013/01/22/hadoop-conference-japan-2013-winter%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hcj13w/","publishdate":"2013-01-22T00:50:00+09:00","summary":"金曜日に引き続き、イベントに参加して来ました。（仕事。。。これも仕事だよ。） 「Hadoop Conference Japan 2013 Winter」です。 普段、Hadoopを触る","tags":["勉強会"],"title":"Hadoop Conference Japan 2013 Winterに参加しました。#hcj13w(Jugemより移植)"},{"contents":"1/18（金）に開催された、エンジニアサポートCROSS 2013で「検索CROSS」セッションのセッションオーナー（モデレータ）をやって来ました。\n@muddydixonさんに昨年の夏くらいに声をかけていただいたのがきっかけです。 こういったイベントの運営のお手伝い（ほとんど何もしてない）も初めてでしたし、セッションオーナー（モデレータ）も初めての経験で色々といい勉強をさせて頂きました（自分の足りない所とか、考慮すべき点がどういったところにあるとか）。本当にありがとうございます。\nスピーカーとして登壇していただいた久保田さん、佐藤さん、安田さんほんとうにありがとうございました。 頼りないオーナーで、モヤッとした内容を提示したにもかかわらず、意図を汲み取って話の内容をふくらませていただいてすごく助かりました。 また、会場にお越しいただいたみなさん、ありがとうございました。すこしでも検索に興味をもっていただければ、セッションは成功だったと思っています。 朝一だったのと、私の認知度の低さもあったのとで残念ながら満席とはいきませんでしたが。。。\n後日、録画されたセッションの内容を見て色々と反省しようかなぁと。。。 緊張していたので、うまくモデレートできてたのか、話ができていたのか不安ですが。 忌憚ない感想をお待ちしています。\nということで、反省終わり！ここからは、イベントの感想と聞いたセッションに関する感想です。\n###聞いたセッション\n####企業CROSS DeNA x グリー x Aiming： 大企業・ベンチャーが語る「スクラム」開発 (仮)\nGoogleの及川さん見たさで参加しました。 スクラム自体は名前くらいは聞いたことある程度だったのですが、その程度の私でもわかりやすいディスカッションで楽しかったです。 聞いていて感じたのは、次のようなこと。\n「スクラム」という開発手法の話しなんだけど目的はそこじゃなくて、どうやってうまくプロジェクトを回して（ドライブして）、目的（サービスを作るとか顧客の要望を叶えるとか）を達成するかというのが重要だなぁと。 「スクラムマスター」の仕事は子育てに似てる 「スクラムマスター」になりたい人はなかなかいないらしい 「スクラムマスター」の人は、俯瞰してプロジェクト全体を見渡して落穂拾いをしていく人なのかもなぁと 個人的には「スクラムマスター」の仕事がちょっとおもしろそうと思いました。（いつもいろんなことを面白そうと思う自分なのでなんともいえないですが。。。）\n####データ理解を助けるビジュアライゼーション\n昨年からビジュアライゼーションには興味だけ（実践とかできてない）は持っていたので、参加しました。 スピーカーの方々の対立軸がはっきりしていたのが面白かったかと。 聞いていて感じたのは、次のようなこと\nビジネスの視点からのビジュアライゼーションはコスパがどうなのかというのがまだ不明 可視化できたらおしまいじゃなくて、お金につながる可視化に心がけるのが重要そう 可視化して楽しむのも有りだとは思うけど、それは趣味だったり芸術の話かもなぁ 異なるコンテキストの人にでも誤解を与えない可視化というのが重要 何をどう可視化するかというのが実は統計学知ってると必要ないこともある 基本的にはCAの方の内容が一番しっくり来ました。やっぱりビジネス的な視点と学術的な視点は違うのかもなぁと。\n####継続的システム運用のゲンバのハナシ\n面白かったです。のっけから燃料がテーブルにならんでるしｗ 運用とかインフラはそこまで詳しくないのですが、少しは作業したりするので気になってましたが、ぶっ飛んだ話が聞けて楽しめました。 聞いていて感じたのは、次のようなこと\nサービス内容によっては夜中にアクセス数が低いものもある（cookpadは夜中はアクセス数が低い） アプリを修正することでインフラを楽にするという考えもある インフラエンジニアは実はリア充 cookpad面白い人多いw このあとは、おまちかねのプレモルタイムだったので、プレモル片手（失礼だろｗ）にTech10の池本さんに挨拶してきました。（Solr本のときはお世話になりました！） あとは、RedBull片手に知り合いの方々（Twitter上のみやいつもお世話になってる人）に挨拶をして回ってました。（プレモルも美味しかったのですが、プレモルおつまみも美味しかったです！） また、ちょっとつかれて座るために入った「体系的に学ぶ安全な利用規約の作り方」でも、面白い話を聞けました。 （利用規約をきちんと考えて変更している企業のほうが炎上をしてしまうとか無駄だしおかしいよねとか）\nイベント終了まで、会場にいて（いただけで大した手伝いしてないです、すみません。）その後打ち上げに向かって楽しみました。\n####さいごは、イベント通じて感じたことと気になったこと。（若干、意図的なものが入り込んでますが。。。）\n題材にもなってる「CROSS」ですが、ここ数年特に、エンジニアとして複数の技術や考えなどを身につけないといけないなぁと 有名人に会える！（ミーハーです。。。） プレモル美味しい！（いつも飲んでるビールが「え？」って思った） ケンタッキー美味しい！ RedBull美味しい！ いろんな技術分野に触れられる機会ができそう Wi-fiは用意してもらえると助かる。（参加者の方々が一斉にLTEとかでつなごうとするのでみんなが繋がらなくなってツイートされないとかちょっとつらいかも） 各会場が覗けるようになってたのは良かった（ただ、会場の後ろの人はざわつきを感じるためスピーカーの声が聴こえないことも） スクリーンはもう少し高い位置にあると良かった（後ろに座ると下のほうが見えないことも） 飲食の配布は会場内でできたほうが良かったのかも（NGなのかな？）。プレモルやRedBullは配ってくれたので良かったのだが、食べ物を取りに行くために入口付近が混雑してた気がした。 （これで、メッキ剥がれたかなぁ） 会場入り口の写真とか撮ってくるんだった。。。 ということで、総じて楽しかったので来年もあるならまた、手伝いたいです！\nおまけ\nプレモル！ Amebaウォーター プレモル＋プレモルおつまみ＋RedBull いただいたスタッフTシャツとプレモル！\n","date":1358600940,"dir":"post/2013/","id":"322264a17ef7182eb1475bd2eaebc2eb","lang":"ja","lastmod":1358600940,"permalink":"https://blog.johtani.info/blog/2013/01/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88cross-2013%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%8A%E6%89%8B%E4%BC%9D%E3%81%84%E3%83%A2%E3%83%87%E3%83%AC%E3%83%BC%E3%82%BF%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--cross2013/","publishdate":"2013-01-19T22:09:00+09:00","summary":"1/18（金）に開催された、エンジニアサポートCROSS 2013で「検索CROSS」セッションのセッションオーナー（モデレータ）をやって来ま","tags":["勉強会"],"title":"エンジニアサポートCROSS 2013に参加（＋お手伝い＋モデレータ）しました #cross2013(Jugemより移植)"},{"contents":"いまさら感満載ですが、今週の金曜日(1/18)に開催されるCROSS 2013というイベントで「検索CROSS」のセッションを担当することになってます。\nここ数年、検索に携わっていますが、検索は色々な技術の組み合わせ（検索用インデックス、自然言語処理、機械学習などなど）でなりったていて奥が深いなぁと感じる毎日です。 そこで、実際のサービスで検索をやられている方、検索プラットフォーム製品を開発している方、自然言語処理や検索に長けた方を招いてつぎのような話をしてもらおうかと。\n・現在の事例（検索とその周辺技術） ・今後の検索にクロスすると面白い技術\nがっつり検索をやられている方々に登壇していただきますので、検索に興味のある方はぜひ、ご参加を！ 登壇者の方々についてはこちらを御覧ください。\n検索CROSS以外にも楽しみなセッションが多数ありますので、参加をご検討いただければと。 あと、実はこっちがメインなのですが、夕方からのプレモルタイムも期待できるのでこちらへの参加だけでもぜひ！！\n","date":1358267340,"dir":"post/2013/","id":"20110c8f8da8304b6d9d3c2845a38128","lang":"ja","lastmod":1358267340,"permalink":"https://blog.johtani.info/blog/2013/01/16/%E3%81%84%E3%81%BE%E3%81%95%E3%82%89%E3%81%A7%E3%81%99%E3%81%8Ccross-2013%E3%81%A7%E6%A4%9C%E7%B4%A2cross%E3%81%A8%E3%81%84%E3%81%86%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E6%8B%85%E5%BD%93%E3%81%97%E3%81%BE%E3%81%99/","publishdate":"2013-01-16T01:29:00+09:00","summary":"いまさら感満載ですが、今週の金曜日(1/18)に開催されるCROSS 2013というイベントで「検索CROSS」のセッションを担当することにな","tags":["勉強会"],"title":"いまさらですが、CROSS 2013で検索CROSSというセッションを担当します(Jugemより移植)"},{"contents":"年末から年始にかけて、「コード・シンプリシティ」を読みました。\n先日の記事にも書きましたが、Kindle paperwhiteを思いかけず入手できたので、eBookを読みたいなぁと思いまして。 Kindleのお試しも兼ねて読んでみました。\nまずは、本の感想。 短めの書籍＋読み物なので、サクっと読めました。 題名に「コード」と書かれていますが、コードの実例が出てくる書籍ではありません。 「ソフトウェア」を以下にシンプルに保って、管理しやすくするか、機能追加、テストをやりやすくするかといった指針について書かれています。 機能追加に関して検討しないといけないバランス（先読みしすぎずと実装しすぎないとか）の話や定期的なデザインの見直しなどについても書かれています。 ソフトウェアに関しては動くこともだが、デザインが重要であること。（確かに。） すでにあるソフトウェアについて、どのように簡潔にしていくかという話もありました。 ただ、読んでいて一番重要だと思ったのは、「悪いプログラマーと良いプログラマーの違いは理解力だ」という一文です。 何をしているかを「理解」していないと、根本的な問題点の解決もできないですし、どうすればコードが簡潔になるかといったこともわからないです。 また、やっている作業がどんなもので、何のためにやっているのか、それを行うことで今後にどのような影響があるのかといったことも理解しておく必要があるかと。 ま、ある程度考えながら作業とかしましょうってことですかね。（強引なまとめかも。。。）\nで本題です。 Kindle paperwhiteとiPadの使い分けを検討するのも兼ねて本を読んでました。 iPadを持っているのもあり、Kindleはそもそも眼中になかったのですが、めっけ物でした。 やはり実際に使ってみないとわからないことありますねぇと。 paperwihteはつぎのような利点があるかと。\n読書に没頭できる。→本を読むというシンプルな目的を達成するものだけが実装されている 目が疲れない→Twitterでも話に上がったのですが、液晶とは異なり字が読みやすいです 軽いし小さい→電車で立っていても楽に持てるし、カバンからの出し入れも楽です（iPadに比べて） 複数の端末のKindleアプリで同期できる。→あまり異なる端末では読まないですが、paperwhiteで読んだところが、iPadでも同期されるのですんなり続きが読めます 電池長持ち ということで、本を読むのに没頭できるし目が疲れないと。 ただ、つぎの点では不満もあります。\nPDFは読みにくい。→画面のサイズが小さいので大きめの書籍のPDF版は読みにくいです。 PDFは読みにくい。→文字のサイズを変更できないのもキツイです。Kindle専用のmobi形式の書籍が読みやすいです ページめくりに一定時間がかかる→紙の書籍やiPadで書籍を読むのとは異なり、ページをめくるのに時間がかかります。e-inkの再描画の問題かと。パラパラと書籍を読みたい場合は厳しいです 白黒。カラーの電子書籍は読めないですねぇ ソースコードなどもキツイ→長めのコードが書いてある本だとコードが頭に入ってこないです。。。 という感想でした。 今後は基本Kindle paperwhiteを持ち歩きmobi形式の本を読むようにすると思います。 iPadは自炊本やカラーの本を読むとき、映像、ネットを見るような場合に持ち歩くことになりそうです。 私は基本的にMBAを持ち歩いているというのもあるので、paperwhiteのほうが主流になりそうです。 ネットを見るときなどは最悪、MBAを開くでしょうし。 小説とかをメインに読むのであれば断然、paperwhiteだと思います（最近読んでないなぁ）\n","date":1357658880,"dir":"post/2013/","id":"992a00c30242b6217243f3c387ea18b7","lang":"ja","lastmod":1357658880,"permalink":"https://blog.johtani.info/blog/2013/01/09/%E3%82%B3%E3%83%BC%E3%83%89%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AA%E3%82%B7%E3%83%86%E3%82%A3%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9Fkindle-paperwhite%E3%81%AE%E4%BD%BF%E3%81%84%E5%8B%9D%E6%89%8B%E3%81%AE%E7%A2%BA%E8%AA%8D%E3%82%82%E5%85%BC%E3%81%AD%E3%81%A6/","publishdate":"2013-01-09T00:28:00+09:00","summary":"年末から年始にかけて、「コード・シンプリシティ」を読みました。 先日の記事にも書きましたが、Kindle paperwhiteを思いかけず入手で","tags":["読書"],"title":"「コード・シンプリシティ」を読みました。（Kindle paperwhiteの使い勝手の確認も兼ねて）(Jugemより移植)"},{"contents":"書こうと思いながら、気づいたら大晦日。 よくないですね、思いついた時に書かないと。\n昨年も書いたので、昨年書いた抱負から振り返りをと。\nMongoDB触ってみる Scala触ってみる なんかWebサービス作ってみる（Amazonとかで） elasticsearch、IndexTankを調べてみる NewSolrCloudDesignを読み込んで自分なりにまとめる Junsaiに参加する 「7つの言語7つの世界」の続き えーと。。。できてないことばかりですねｗ MongoDBはインストールすらしてないですし、Webサービスも作ってないです。（さくらVPSは借りたんですが） Junsaiは参加したけど何もできてないし。7つの言語もそのままですね。。。 SolrCloudDesignはまとめられてないですしね。 Scalaは少しだけ触りました。結局Javaみたいな記述をしてしまうという良くないくせが出てしまうので、 見送ってしまいましたが。。。 elasticsearchは少しだけやりました。#pyfesで話をさせて貰える機会があったので。\n興味がコロコロ変わってしまうのが問題点かもしれないです。少しは地に足をつけてなんかやったほうがいいのになぁ\n###今年の振り返り 今年はこんなかんじでしょうか。\nいろんな勉強会に出没 #pyfesでelasticsearchのさわりを紹介 個人的にJIRA導入 MIR輪読会開始 Solr勉強会の主催を引き継ぐ Kindle paperwhite当たった 相変わらずいろんな勉強会に出てました。最近は勉強しに行くのもありますが、人に会いに行ってるような気がします。 勉強会から帰ってきて復習したりしないとすぐ忘れちゃうんですよね。。。\n#pyfesではelasticsearchの入門中という話をしてきました。 人の多さに緊張しまくりでよくわかりにくい発表になってしまったのが反省点かと。。。 もっと話をする機会を増やすとなれるのでしょうか。\nJIRAの導入はパラで仕事をしているとタスク管理がおろそかになってくるので導入しました。 フリーのredmineを考えていたのですが、インストールが簡単なJIRAを導入しました。 有料ですが、1-10人までなら、ダウンロード版が$10ですし。いろんな時間を買ったと考えると安いかと\n検索に関してもまだまだ初心者に近いということでModern Information Retrievalという英語の本の輪読を主催しました。 Twitterでの呼びかけに答えてくれた方々に感謝です。 まだ、半分も行ってないですが、何周かしたいと思っています。\nSolr勉強会の主催者も引き継ぎました。Atnd立てるの手伝おうか？って言ったら主催者になってましたｗ 来年も開催するので、喋りたい方、こんな話を聞きたいなどTwitterやブログでコンタクトいただければと。\nあと、会社の忘年会で思いがけずKindle paperwhiteが当たりました！（やったー！） iPadを持っていることもあり、完全に購入する気も無かったのですが。。。 使ってみると結構いいです。画面のギラツキがないのと、他のソフトがないのがいいです。 読書に没頭できます。通常はKindleを持ち歩くことになるかと。（没頭できるけど、読むスピードが遅い＋すぐ忘れるのが難点。。。）\n###来年の抱負 来年の抱負も書いておきます。 昨年の前科があるのでどこまでできるかわかりませんが。 すぐに興味が変わってしまうのもありますし\nIntelliJ IDEAをメインに使う JIRAを継続して活用 ブログの継続 elasticsearch Luceneのソースコードリーディング 何かOSSのソースを読む Macでもっと開発 読書と英語を継続 IDEA（アイデア）は11をインストールしてたのですが、使えていませんでした。 イメケンが主催したJetBrainsユーザー会で洗脳されて＋タイミング良い75%オフセールにやられて購入しました。 普段はEclipseを使っているのですが、これを機にチャレンジしようかと。 少し変化をしてかないとすぐ取り残されちゃうので。。。\nJIRAはまだタスクを登録してクローズするという初歩段階の使い方しかできてないので、少しずつ研究してフィールド追加したり、ワークフローを変更してみたりと研究したいです。\nブログは、今年後半が勉強会参加ブログしかないのを反省して来年は、もう少しSolrやLucene、lucene-gosenについて書いて行きたいです。 （すくなくとも、4.0で動かす話を書かないと。。。）\nelasticsearchはまぁ触れる環境を維持しようという話です。 どこかで導入できればいいんでしょうが、なかなか。 （勉強会開いてみるのも面白いかな？）\nLuceneソースコードリーディングは誘われてるのに、ちゃんと返事をしていなかったので。 来年2月のどこかの土日を候補日にする予定です。\n何かOSSのソースも読もうと思ってます。 「何か」はまだ決めてないですが、人のソースを実はあまり読んでないなぁと。 Vさんと話をした時に人のソースを読むのがいいですよという話になったので。 真似をするためにもなんか読みたいなぁと。Javaになるのかなぁ。\nとある事情で週4はWindowsで開発してます。 Macはちょっとしか触ってないのでMacの環境が成長していないのが難点です。 できれば、Macで開発を継続できる環境を作りたいなぁと。Kobitoとか入れてるけど触ってないし。。。 IntelliJも入れたのでMacで開発したいものです。\n最後は毎年のことですが、本を読むスピードが買うスピードに追いついてないと。。。 英語の本もかってるんですが、これまた読むスピードが。。。 ということで、ざっくり目を通す読書をもっとやりたいなぁと。 買うのはいいのですが、必要にならないと呼んだ内容を忘れてしまうので、読んだあとに実践する機会も設けたいと思ってます（思ってるだけかもしれないですが）\nあと、来年もいろんな人に会うためにいろんな勉強会に出没すると思いますので、声をかけていただければと また、不抜けているのを見かけたらカツを入れてください。（技術内容のブログ書けとか、本読んだ感想をブログにかけとか） 来年もTwitterなどで絡みまくると思いますが、よろしくです。\n","date":1356908460,"dir":"post/2012/","id":"4c08b67e0c1fdeef50b1fdcc32cdcee2","lang":"ja","lastmod":1356908460,"permalink":"https://blog.johtani.info/blog/2012/12/31/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A02012/","publishdate":"2012-12-31T08:01:00+09:00","summary":"書こうと思いながら、気づいたら大晦日。 よくないですね、思いついた時に書かないと。 昨年も書いたので、昨年書いた抱負から振り返りをと。 Mongo","tags":["備忘録"],"title":"今年の振り返りと来年の抱負（2012）(Jugemより移植)"},{"contents":"Atlassian Advent Calendar 2012の20日目。（急遽参戦） （某イケメンにMT（改変リツイート）されたので書いてみました） 久々に、勉強会以外のエントリです。（Solrとかlucene-gosenじゃないんだが。。。）\n私は、最近忘れっぽくなってきてしまったので、さくらVPSを借りてJIRAを立てて、タスク管理とかに使い始めました。 有料ツールなので、まずは、評価版から入れましたと。 評価版をインストールするときに、楽なのでHSQLDBを選択していました。が、 インストール時に「HSQLDBは評価版だけで使用してください。正式版ではサポートしてないです」みたいなことを言われていたので、PostgreSQLに切り替えようかと。 ちなみに、MySQLも選択肢としてはあったのですが、PostgreSQLのほうが触ってるし（つかいこなせてるわけではない）、補完機能になれてるというのもありPostgreSQLを選んでみました。\n作業のログとして、ブログ書いとこうと思いたったのでメモ的に残しておきます。\n作業の流れはこんなかんじでした。 （基本的にはサポートサイトのここに載ってます。サポートいいね。） この手順通りでいいみたい。\n###1. JIRAのデータのバックアップ（JIRAの管理画面からバックアップ）\nまずは管理画面へ。ページ右上に管理へのリンクがあるのでクリック。 開いた管理画面の右下あたりにエクスポート（バックアップ）へのリンクがあります。 クリックしたあとに、エクスポートのファイル指定画面が現れるので、ファイル名を指定してバックアップボタンを押します。 バックアップが完了するとバックアップファイルの場所が表示されます。 ###2. JIRAの停止\nバックアップが終わったのでJIRAを停止します。\n###3. PostgreSQLのインストール（yum） PostgreSQLが入ってないので、yum installします。（軟弱者なので）\nyum install postgresql-server ####initdbで四苦八苦 PostgreSQLはインストールしただけでは起動できません。なので、初期化をします。 yumでインストールしたPostgreSQLだとつぎのコマンドでinitdbできるようです。（これが罠でした）\nservice postgresql initdb このコマンドでinitdbすると、encodingが指定できませんでした。（私がしらないだけという話も。。。） encodingを指定できていないと、このあと4.を実行するときにエラーが出ました。（これも回避方法あるのかも。） ということで、結局、昔とった杵柄なやり方でinitdbコマンドで\u0026ndash;encoding=UTF8 \u0026ndash;no-localeを指定しました。\ninitdb --encoding=UTF8 --no-locale -D/var/lib/pgsql/data service postgresql start これで初期化が完了するので、PostgreSQLを起動します。\n###4. JIRA用DBとユーザの作成\nまずは、ユーザの作成。そして、DB作成\ncreateuser jirauser createdb -E UNICODE jiradb テーブルなど作成しません。あとの処理がやってくれます。\n###5. JIRAにJDBCドライバを入れる（必要なかった。）\nwarじゃないJIRAをインストールした場合はすでに入ってるみたいです。 ここを見るとわかります。JIRA Installation Directoryの下のlibですかね。\n/opt/atlassian/jira/lib ###6. マニュアルでPostgreSQLの接続設定（あれ、これいらないのか。）\n~~　コンソールオンリーなので、JIRAが提供してくれているツールが使えないため、手で設定。 /var/atlassian/application-data/jira にあるdbconfig.xmlを修正~~ ちゃんと英語読めってことですね。。。必要なかったです。。。\n###7. JIRAのdbconfig.xmlを削除\nDB接続の設定を初期セットアップウィザードで再設定するため、dbconfig.xmlを消します。 （一応、インストールディレクトリとホームディレクトリとかバックアップしたほうがいいみたい） 場所はここ。 中身はdbcpとかのデータソースの設定に似てました。 今は、HSQLDBのJDBCドライバが記載されてました。\nrm /var/atlassian/application-data/jira/dbconfig.xml ###8. JIRAの起動\n7.のファイルを消したあとにJIRAを起動します。\nservice jira start ###9. JIRAにアクセスとDB接続設定\nアクセスすると、インストールした時と同じDB接続の指定を行うセットアップウィザードの画面が現れます。 今回はJIRAサーバの外にあるPostgreSQLなので、「外部」を選んで四角で囲んだ部分を入力します。 入力したら、「接続テスト」を押して接続できることを確認したら「次へ」を押します。 マシンのスペックにもよると思いますが、ここでJIRAサーバがDBに接続してテーブルのCREATEなどDBのセットアップを実行してるのでちょっと時間がかかります。\n###10. バックアップしたデータのインポート\nDBのセットアップが終わったら、アプリケーションのセットアップ画面が出てきます。 新規インストールではないので、「ここ」にある「既存のデータをインポート」リンクをクリックします。 すると、インポートファイルの指定画面が現れるので、1.でバックアップしたファイル名を指定してインポートします。 すると、インポート中画面が出てきます。 で、インポートが完了すると無事JIRAにログインできますと。\nとこんなかんじです。 私の場合は、まだJIRAをインストールしてから間もないため、チケットの数が少なかったり、添付ファイルが無かったりなので、すぐにインポートが完了しました。 添付ファイルがある場合は、別途添付ファイルが保存されているディレクトリのバックアップと復旧などもあるみたいです。 最初にも書きましたが、ドキュメントのサイトに「Switching Databases」という項目があり、そのページの手順で問題なく切り替えできました。 次は、定期的にデータをバックアップするのを考えないとですかね。\nいやぁブログ書くのが、思いの外、手こずりました。 手こずった原因はスクリーンショットだったんですけどね。。。 safariでページ全体のスクリーンショットがとれなかったので、結局ChromeでAwesome Screenshotプラグイン使いました。 safariの拡張もあるんですが、ページ全体のスクリーンショットがうまく動かないみたいです。。。 ということで、備忘録でした。（次はちゃんとSolrとかの記事書かないとなー。その前に忘年ブログかな）\n","date":1356002280,"dir":"post/2012/","id":"4a30eeb083acec8460150068ba0c6743","lang":"ja","lastmod":1356002280,"permalink":"https://blog.johtani.info/blog/2012/12/20/jira%E3%81%AEdb%E7%A7%BB%E8%A1%8Chsqldb%E3%81%8B%E3%82%89postgresql%E3%81%B8-augj/","publishdate":"2012-12-20T20:18:00+09:00","summary":"Atlassian Advent Calendar 2012の20日目。（急遽参戦） （某イケメンにMT（改変リツイート）されたので書いてみました） 久々に、勉強会以外のエントリです。（So","tags":["JIRA"],"title":"JIRAのDB移行（HSQLDBからPostgreSQLへ）#augj(Jugemより移植)"},{"contents":"イケメンが主催した「第一回 JetBrainsユーザーグループ #jbugj」に参加してきました。\nいろんな製品があるんだなぁと。入り口には良いイベントだったと思います。 個人的に、WebStorm、IntelliJが気になっていたので、参加しました。（あとは、イケメンがやってるイベントだからというのもあるかも） ちなみに、MBAにしてからインストールはしていたのですが、ほぼ触っていなかったのでこれを機会にちょっと触ってみようかなぁと。\n発表は、全般的な製品紹介、ライセンスの紹介から、ライブコーディングあり、ここがいいよ！という話ありという感じでした。\nMTLさんのおしゃれな空間で発表を聞いたので、いつもとは少し違った感じでしたでしょうか。\n私自身は、発表を聞きつつ、IDEAのCEで色々やってました。 一応、Lucene/SolrのSVNからチェックアウトしたり、lucene-gosenのtrunkをチェックアウトしたり、個人のbitbucketからlucene-gosen-wikiparseとかcloneしてました。 Eclipseで作ったプロジェクトなので、cloneとかチェックアウトしたあとに、Eclipseと並行開発するとどうなるのかなぁ？というのがちょっと気になります。（普通は移行しておしまいなんだろうけど。。。） ちなみに、lucene-gosenのプロジェクトもSVNからチェックアウトしたらすんなり使えそうでした。 こんな感じ。（lucene-gosenのプロジェクト） とりあえず、見た目がカッコイイｗ\nいくつか触ったり、聞いていて気になったのはつぎのような点です。ちょっとずつ触る機会を作った時に調べてみようかなぁと\nEclipseのワーキングセット相当の機能はどうするのか？→モジュールとかでやればいいらしい。 プラグインってどんなものがあるの？探す方法とインストールの仕方 JDKの複数の切り替え方とか Eclipseでやってる人とIntelliJでやってる人の混在チームでの開発とか で、いつものごとく、懇親会に参加しました。 @mike_neckさんや@sue445さんとお話できたのですが、VCSにEclipseの設定ファイルとか挙げないほうがいいですよねとか、テストが無いプロジェクトってないわーなどの話を聞いて、やっぱり自分はまだまだなんだなぁと認識できるとか面白かったです。 lucene-gosenのSVNにはEclipseの設定ファイルとかアップされてるからなぁ。ホントはAntとかMavenのターゲットでこれらの設定ファイルができるようにしとくのがいいんでしょうねぇ。 まだまだ勉強することだらけですが、コツコツ教えてもらいます\nちなみに、イベント参加者にはショートカットキーが印字されたキートップシールや2ヶ月有効な評価ライセンスがあとからもらえるなどの特典もありました。 普段はEclipseなのですが、運良くライセンスが当たったら本気で乗り換えようかなぁｗ\nちなみに、Eclipseでもそうですが、私自身はショートカットキーをほとんど覚えてない軟弱者ですので、メニューの場所などを覚えれば乗り換え自体はこんなんじゃないかと。 Mac自体にKeyRemap４MacBookを入れていて、Emacsっぽいショートカットを使うので、覚えられないというのもありますが。 ライセンス当たらないかなぁー\n以下はいつもの通り、聴きながら自分用にメモしたものになります。\n日時：2012/12/11（火）19:00-21:00 場所：メディアテクノロジーラボ イベントサイト：http://www.zusaar.com/event/450003\n◎JetBrains製品群、ライセンス形態などの紹介 - @yusuke ・日本でヤル気あるの！？→あるある！→じゃあ、ユーザグループ立ち上げるぜー ・あくまで情報交換の場を設けるだけ。 ・アンケート結果 IntelliJが1番人気 WebStromが2番 ・ステッカー（ちょっとかっこ悪いかも。。。） ・2名限定でIDEAのライセンスプレゼント！ ブログ書いて、応募用フォームに登録してランダム抽選 ◎IntelliJの基本(インストール～プロジェクト作成、テスト、実行までのウォークスルー) @yusuke ・JetBRAINSはチェコの会社 ・IntelliJはなんでもできる（AppCodeは違うけど） ・.Net系もある（書きそびれた） ・YouTrack：課題追跡 ・TeamCity：継続インテグレーション ・読み方は「イデア」じゃなくて「アイデア」だよ！ ・Community Editionはあんまり機能がない。 OSSライセンスだと、Ultimateの機能が使えるよと。 ・仙台の人が一人アドベント・カレンダーやってます。 http://d.hatena.ne.jp/masanobuimai/20121201\n・ライブデモ 黒いインタフェースにするのどーすんだろう？ →Preferences→AppearancesでThemeで「Darcula」を選択すると黒くなる。 ・やべ、時間過ぎてたｗ終わり！ ◎IntelliJのここが気持ちいい！→普通IntelliJでしょ？ @mike_neck ・DQXやってます。 ・僕とeclipse ・新規クラス作成：3ステップかかる ・補完の素早さ： ・SprintFramework：Ultimateなら対応してるよ。 関係ないけど、TLで質問したので。 Eclipseのワーキング・セットに相当するもの。 http://d.hatena.ne.jp/masanobuimai/touch/20121024\n◎LT ◯WebStormとRubyMineについて @sue445 ・JavaScriptのIDEとして最強 jsの補完が素晴らしい。（外部のJSはプロジェクトに入れないと難しい。） jsTestDriver pluginがデフォルトで入ってる！ ・RubyMine RubyのIDE ソースを追うのが楽。 erbのインポートしたものも追っかけられるの便利。 viewからhelperクラスにも飛べる。 QA UMLとか出せるの？→出せるよ。 DBクライアントもあるよ。 ◎JetBrains発のJVM言語Kotlinの紹介 - @ngsw_taro アドベントカレンダー（一人）http://atnd.org/events/34627\n・社畜してます ・Androidアプリとか作ってる。 ・Kotlinな活動 Pull Requestしてる ・マイルストーンなど。 M4が3時間前に出た！ ・どんな言語？ 静的型付け、オブジェクト指向、関数型プログラミング的、JSへコンパイル可 産業利用目的（初めて聞いたかも、この言葉ｗ） ・Java大変だよね。 互換性問題とか ・ライブコーディング 大変そうだｗKUnitってのもあるらしい。 （ゴメンナサイ、IDEA触ってて、流してました。。。Eclipseで作ってたプロジェクトをBitbucketから落としてきて四苦八苦してた） （参考にしたサイト（ググった）：http://d.hatena.ne.jp/waman/20100506/1273166533）\n◎AppCodeについて ・IDEAには含まれないので、別途ラインセンス購入が必要。 ・XcodeとAppCodeの違いをライブコーディングで説明。 ・XCodeよりも補完が良くできてるっぽい。 GUIはXCodeで作って、コーディングはAppCodeでやるってのがいいですよ。 ※私が、iOS系のアプリの開発ってやったこと無いからよくわかってないです。。。 XCodeはコードフォーマットがないのが辛い by @yusuke ","date":1355228520,"dir":"post/2012/","id":"898d25a2ab9c0ba1fa9bad462405e475","lang":"ja","lastmod":1355228520,"permalink":"https://blog.johtani.info/blog/2012/12/11/%E7%AC%AC%E4%B8%80%E5%9B%9E-jetbrains%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97--jbugj-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-12-11T21:22:00+09:00","summary":"イケメンが主催した「第一回 JetBrainsユーザーグループ #jbugj」に参加してきました。 いろんな製品があるんだなぁと。入り口には良いイ","tags":["勉強会"],"title":"第一回 JetBrainsユーザーグループ #jbugj に参加してきました(Jugemより移植)"},{"contents":"ヒカリエに行ってみたいという不純な理由で参加してきました。 新しいということもあり、おしゃれで綺麗なカフェでした。 入り口にはおっきな人形も立ってたし。 渋谷の夜景も見下ろせて素敵な場所でした。\nで、内容です。残念ながら、本編の3回めには参加していなかったのですが、 今回も濃い話が聞けたので楽しかったです。 論文読まなかったり、基礎を勉強したのに忘れてたりと抜けてる部分が多いので、 こういう機会が与えてもらえるというだけで目からうろこです。\n@kumagiさんの「あなたの知らないハッシュテーブルの世界」はハッシュテーブルの基本的な話から、最近の論文で発表されてる内容までをカバーする幅広いお話で面白かったです。 （大学でやってると思うんだけどすっかり抜けてる自分がなんとも。。。） こういうコアな中身も知ってると、色々とプログラム書いたりするときの見方や考え方も変わってきますよね。 （そんなプログラム書いてないけど。。。） で、随分おとなしい内容だなぁ？と思いきや、途中からちゃんとLock-Freeの話も出てきてさすがと感心させられましたｗ 最後はJubatusの宣伝まで入ってたし。（某氏のすごい写真入りで。。。）\n@hitoshi_niさんの文書要約の話は、NLPに興味があるので、楽しみにしていた内容でした。 今回もなめらかによどみなく喋られる発表にただただ感心させられるばかりでした。 内容は中級編ということで、文書要約のキモになる処理の文章の短縮の話です。 係り受け木を元にする手法をわかりやすく説明されて、もうなんか、すぐに実装できちゃうんじゃないかと錯覚してしまう始末でした。 係り受け解析というと、CaboChaを思い浮かべてしまうんですが、きっと違う実装なんだろうなぁ。 入門編と次回の重要文抽出の話も聞きたいなぁと。\n最後に、技術評論社さんから「Emacs実践入門」など3冊の書籍のプレゼントまでありました。 その他の2冊は購入済みだったのですが、Emacs本は購入したいリストに入れたままでした。 ということで、欲しいですというアピールをしてゲットしてきました！ Emacsはなんだかんだで、もう10年以上使っていますが、そこまで深入りしないような使い方をしていました。 これを機に、再入門してもっと使いこなせるようになろうかと。 また、読了したタイミングでブログに感想かきます。\nということで、以下はいつもの自分用のメモになります。おかしいところ、それ書いちゃダメでしょ的なところのツッコミをいただければ。\n日時：2012年11月28日(水) 19:00 場所：渋谷ヒカリエ27F NHN Japan カフェ ◎開会、諸注意など　@overlast 人材募集、会場説明など。 前回、本をもらった人はブログ書いてね。オライリー様より 今回も本のプレゼントあり。技術評論社様より ◎あなたの知らないハッシュテーブルの世界(30分 + 質疑応答10分)　@kumagi さん ・まずは前提。 データの集合を扱いたいよね 配列でもできるね。けど、データ増えるとキツイね。 ・ハッシュ関数の話から。 リハッシュとかの話 ・ClosedAddressingとOpenAddressingの話 ・ClosedAddressingの場合、ポインタ使ってるからキャッシュミスあり。 メモリとかの話 ・OpenAddressingメモリに乗るのでキャッシュミスは少ないけど、削除データの扱いがちょっと大変 →削除がいっぱい有ると処理が面倒 ・RubyはClosedAddressing、PythonはOpenAddressing memcachedはClosedAddressing ・Cuckoo Hashing（2001） 密度50%以上になると急にコストが高くなる。 挿入がすごく遅くなる。追い出し操作が増えるから？ ・そこで、Hopscotch ググった参考ページ：http://shnya.jp/blog/?p=639 http://en.wikipedia.org/wiki/Hopscotch_hashing 密度が上がっても性能劣化がない。 ・C++でHashtableが欲しくなったら、google_sparse_hashとdense使うよと。 ・ConcurrentHashmapのお話 テーブル部分がvolatile、Chain部分はfinal insertはChainの先頭に。 削除は遅い。ReadCopyUpdate。 空でも1.7M（K？）持ってく ・ここからはLock-free系 ・Lock-Free Hash Table http://www.azulsystems.com/events/javaone_2007/2007_LockFreeHash.pdf HotSpot VMの人のもの？こんなのやってる。http://www.0xdata.com/faq.html ・（聞きそびれた） ・日立謹製Lock-free hashtable 日立のDBで使ってる部品？ ベンチマークが胡散臭い ・最後はJubatusのCM ◎文書要約入門 中級編(40分 + 質疑応答10分)　@hitoshi_ni ・画数が少ないです。 ・ヒカリエ綺麗ですね。 ・文書要約とは？ 「機械に」要約させる。 ・なんで要約？ 長い文章読みたくない。人件費の削減 ・どうやって要約？ 1.文分割：文書を文に分割 2.文短縮：就職説を削除するなどして、原文より短い文の亜種を出す。 3.重要文抽出：要約にふさわしい文を選び出す。 ・今回は文短縮について ・動機 長い文は文抽出で扱いにくい 文の中にも重要なところとそうでないとこがある ・係り受け木の剪定すると短くできると。 剪定のルール 中間ノードは落としちゃダメ 除去の時に考えること 重要度 言語 ・重要度？ 文節に点数を付ける 文書集合中の出現頻度とかを採用。訓練データからでもいいよ（ロジスティック回帰とか）。 ・言語尤度 言語としての尤もらしさ 典型的にn-gram言語モデルを使う ・そして探索 基本的には2値ラベリング ビタビアルゴリズムではだめ。係り受け制約が考慮できない ナイーブいはビームサーチをする。 ・文短縮の評価 ・人間が書いた短縮文と比較 ・ROUGE-Lという尺度などで評価（これしらないなぁ。） ・幾つかの論点 係り受け解析しない 文節じゃなくて、単語単位でもいいよねとか。 Q：硬い文章以外の要約ってやってるの？ A：あります。 技術的な話だと、係り受け解析がうまく出来ればできる。 係り受け解析がうまくいけば、そこまで大変じゃない。 Q：短さが短くなるほど難易度があがるけどどこまでやってます？ A：短くすればするほど難しい。これは情報の欠落が激しくなるから。 文法性を担保するのも難しい。 10文字くらいならできそう。 Q：実例としてどのくらいの長さをどのくらい短くしてる？ A：ある程度の長さを20文字にしてくれとか。Twitterに入るくらいにしてくれとか。 頂いちゃいました！ Emacs実践入門　～思考を直感的にコード化し、開発を加速する (WEB\u0026#43;DB PRESS plus) ","date":1354122000,"dir":"post/2012/","id":"e01e01d18582c7f69e1b0db7e1b111a0","lang":"ja","lastmod":1354122000,"permalink":"https://blog.johtani.info/blog/2012/11/29/dsirnlp-3-5%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Femacs%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80%E3%82%92%E9%A0%82%E3%81%84%E3%81%A1%E3%82%83%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-11-29T02:00:00+09:00","summary":"ヒカリエに行ってみたいという不純な理由で参加してきました。 新しいということもあり、おしゃれで綺麗なカフェでした。 入り口にはおっきな人形も立っ","tags":["勉強会"],"title":"#DSIRNLP 3.5に参加しました。＆「Emacs実践入門」を頂いちゃいました！(Jugemより移植)"},{"contents":"第9回Solr勉強会に参加しました。 皆勤賞です！というか、主催者になってしまいました。 まだ不定期の開催になると思いますが、話をされたい方などいらっしゃいましたら連絡いただければ助かります。\n今回も面白い話が聞けました。\n最初はKuromojiの開発者でSolrのコミッターでもあるChristianの発表です。 Solr勉強会では初の英語の発表だったんじゃないでしょうか。 Atilikaでやってることの紹介から、Kuromojiの紹介、今後の改良に関する話とひと通り話してもらいました。 途中でKuromoji使ってる人？などの質問があったのですが、残念ながら反応が薄かったです。 漢数字をアラビア数字でも検索できるようにするチケットなど、今後のKuromojiの発展も楽しみです。 （コメントとかパッチを送れというプレッシャーもあったので、パッチ頑張って書きます。。。）\nつぎはニコ生でのSolrのお話。結構、赤裸々（前任者がいない状態で引き取ったとか）に語っていただき、ハラハラしながら聞いてました。 やはり、新語や略語で苦労されてるんだなぁと。 複数のサービスや開発者に対してSolrの環境を提供するという話はなかなか興味深かったです。 いろんな人がSolrを触るような状況になってきてるんだなぁと。 基盤となるラッパーのようなフレームワークとかも作ってるのかなぁ？ 今後は台湾語や英語への展開も考えられているようなので、Language Detectionなどを利用してみた感想とその内容を今度発表してもらいたいですねｗ\nつぎはFacetPivotの話です。 昔から要望が出ていたのですが、4.0系でやっと使えるようになりました。 ファセットはSolrの売りの一つだと思います。 最初はこの考え方がしっくりこない人もいるかもなぁと。特にデータをどのように作れば、いいのかって悩むこともあります。 その悩んだ内容について発表してもらいました。 実際にどうやって使うかを悩んだ内容を発表してもらうのもいいなと思いました。\n最後はSolr勉強会なのに、elasticsearchの洗脳会になってましたｗ elasticsearchはSolrと同じ、Luceneをコアに採用した検索エンジンサーバーになります。 Solrとは別のアプローチでLuceneをラップし、REST APIでアクセスしやすくしたプロダクトです。 Luceneのコミッターの方もelasticsearchの開発に参加しています。 分散インデックスを念頭においた設計や、インストールが簡単なプラグイン構造といったSolrとは違ったアプローチがなされており、面白いものになっています。 残念ながら日本で利用されているという話はまだ聞いた事ないですが、だからこそ、触ってみて事例を紹介してみるのも面白いのではないでしょうか。 今回紹介したKuromojiも使えるようになっていたりしますので、日本語でもある程度使えると思います。\n以上が簡単ですが感想です。主催者だったのに、@hirotakasterさんや@ajiyoshiさんに受付などをやっていただいたので、いつもの様にしっかり話を聞いてしまいました。 発表者の方、会場提供いただいたVOYAGE GROUP、お手伝いいただいた皆さんに感謝です！\n今回初の主催でしたが、本当に助かりました。たどたどしい説明や紹介など至らない点も多々有ったかと思いますが、今後もよろしくお願いいたします。\n主催者的な立場として感じたことも書いておこうかと。 無料の勉強会で、ATNDという参加しやすい環境というのもあるかもしれないのですが、キャンセルをきちんとしていただくほうがいいなと思っています。 幸いにもSolr勉強会はここ数回は盛況で、キャンセル待ちの方が結構いらっしゃいます。 ギリギリまで業務との兼ね合いを見つつ、参加しようと思っていらっしゃる方もいると思うのですが、キャンセル待ちで行けるかな？どうかな？と思っている方もいらっしゃいます。 ドタキャンは問題ないのですが、キャンセルせずに欠席は出来れば避けていただけると助かるなぁと。 （残念ながら、きちんと集計をとれなかったので、次回からは集計取ってみようかなぁと）\n次回の開催は今のところ未定です。発表してみたい方、こんな話を聞いてみたいなど、気兼ねなく連絡いただければと思います。 このブログにコメントを頂いてもいいですし、ツイートしていただいてもいいので、反応をいただけると嬉しいです。 また、今回至らない点があったなどのツッコミ、批判も気兼ねなく言っていただければと思います。 今後の反省点にもしたいので、ぜひ反応をいただければと！\n懇親会でも色々な方とお話できました。（もう少し、Christianと英語で話す努力とかしないとなぁ。。。）\nとりあえず、メモをアップしときます。 リンクとか感想とかはまた（飲んだ）後で。。。\ntogetterでまとめてももらったみたいです。ありがたいです。\n第9回Solr勉強会 場所：VOYAGE GROUP 会議室 日時：11/26(月) 19:00～21:00 1. Atilika Inc.　Christian Moenさん タイトル：Who we are, what we do, and a little bit about Kuromoji ◎Atilikaの紹介。 会社の目指すもの ・BigData、検索、NLP ◎プロダクト Kuromoji：形態素解析エンジン Akahai：日本語クエリサジェストエンジン Keywords：日本語キーフレーズ抽出 ◎Kuromojiの紹介 3.6からデフォルトで使える。 ◎将来の改良の話。 ・踊り字対応（コミット済み） ・漢数字に関するチケット＆パッチのお話。 ・ユーザ辞書の重複エントリ改良とか（すみません、パッチ書きます。。。） 2. 株式会社ドワンゴ　吉村総一郎さん(@sifue) タイトル：Solr@ニコニコ生放送 ◎ニコニコ生放送の紹介 ・1日に10万番組。。。 ・10/17にバージョンQをリリースしたら、トップはひどい叩かれようでした。。。 ◎これまで。 Jackrabbit→Lucene→Solr→ニコ生のSolr ◎退職者と入れ替わりでSolr担当。。。 今回は資料と環境を調べて発掘した機能のお話。。。 ◎機能 キーワード検索。論理クエリ、などなど。 ◎利用してる環境 3.4ベース＋Jetty マスタスレーブ構成（スレーブ2台） 途中は分散インデックスを自分で実装？ ボトルネック自体がDBからのデータ収集だった ◎インデックス対象 ・見れるのは過去1週間と過去の公式番組すべて。 この部分だけ検索可能。 ・更新頻度の高い情報に「来場者数」「コメント数」 ◎インデックス作成 ・バッチにて更新 ◎アナライザ CJKTokenizerFactoryを利用 HTMLStripCharFilterFactory Bi-gramなので、「FF」とか「DQ」に弱い（FF1でFF13とかヒットしちゃう） 検索精度は悪いと言われてるみたい。 ◎1日のリクエスト ピーク時40QPS程度 5分おきにスパイクがある。（ユーザが作ったツールによる検索とか。。。） ◎UPDATEリクエスト ピーク時は80QPS ◎開発用のJettyのマルチテナント機能を利用したSolr環境の提供 ◎台湾語とか英語もやりたいなぁ。　3. 株式会社マーズフラッグ　柳吾朗さん(@hitode7456) タイトル：ドリルダウン色々 ◎Facetの紹介から ◎楽天でのドリルダウン例（これはFacetの紹介での例であり、実際にSolrが利用されているかはわからないです。） ◎多段ドリルダウン（ファセット）のお話。 アプリを実装するときの考え方とか。 ◎実直形、工夫形、PivotFacet Q\u0026amp;A Q：3つの性能系のコストは？ A：まだ調べてないです。残り2つは工夫形がいいですよ。と 次回、調べた結果の発表もやってほしいなぁ。 4. 兼山元太さん (@penguinana_) https://speakerdeck.com/penguinco/solrtoelasticsearchfalsebi-jiao タイトル：SolrとElasticsearchの比較 ◎クックパッド！ ◎elasticsearchの紹介 ◎比較サイトもあるよ！ http://solr-vs-elasticsearch.com ◎サンプルデータ・セット（ライブドアグルメ）でサンプル実装。 https://github.com/penguinco/ld_gourmet_search ◎APIの紹介 REST APIがちゃんと造られてますよと。 設計時点でコレクションなどがURLに含まれてるのがいいよねと。 ◎_analyzeによりアナライザーもAPIとして公開されてるよと。 ◎Kuromojiも対応してるよ！ ◎DynamicFieldよりも便利だよ。 ◎クエリのDSLが違うのでちょっとアレ。 ◎スコアリングも色々できるよ。 ◎感想 ・機能面の不足なし ・APIがいい コア追加とか、curlだけでできるのがいい。 ・習得が容易（Solrやってると機能とか似てる） ・大規模じゃなくても使えそう ◎分散検索がデザイン時に組み込まれてるのがいいよね。 write consistencyなどがインデックスごと（コレクションごと？）に設定可能なので便利。 ◎multi-tenant open/closeなどができる（時系列データとか） shard allocationなどの細かな制御も可能ですよと。 ◎plugin 色々プラグインがあるよ。管理画面もプラグインであります。 プラグインもコマンド一発で追加可能。 ◎クエリキャッシュがないので、自前でnginx、varnishなどでキャッシュが必要。 ","date":1353923040,"dir":"post/2012/","id":"7e23419e4fc69b5b533815681c9bb1a9","lang":"ja","lastmod":1353923040,"permalink":"https://blog.johtani.info/blog/2012/11/26/%E7%AC%AC9%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/","publishdate":"2012-11-26T18:44:00+09:00","summary":"第9回Solr勉強会に参加しました。 皆勤賞です！というか、主催者になってしまいました。 まだ不定期の開催になると思いますが、話をされたい方など","tags":["勉強会"],"title":"第9回Solr勉強会を主催しました。#SolrJP(Jugemより移植)"},{"contents":"初目黒（たぶん）で、初Amazonな感じで、流行りの「ビッグデータ」のセミナーに参加してきました。\nとりあえず、いつもの自分用のメモを残しておきます。 感想はまた後日。。。（たぶん、頑張れ私。。。）\nAWS ビッグデータ活用事例セミナー 日時：2012/11/09 [ 金 ] 9:30 - 12:00 場所：アマゾンデータサービスジャパン目黒オフィス ★AWSビッグデータ概要 @understeer　○Amazonの紹介 ○Amazon Web Serviceの紹介 ・オンプレミスと比べ、初期費投資が不要 ・コストダウンを促進 過去6年で21回の値下げを実施 ・IaaSだけじゃなく、PaaSもやってますよ。 ・OSより上の層は好きに選べるよ。 ○AWSのサービスだけで20ある。 ○3つのV Volume　2012年で1.2ZB。95%が非構造データ。今後も非構造データが増加 Velocity　デバイスの増加、パーソナライゼーション系の増加 Variaty 素粒子のデータの解析とか、地質学、気象予報とかいろいろやってるみたい。 ○BIG DATAの4つのプロセス。 収集、保存、分析、共有を繰り返しやりましょう。 そこで！AWS使いましょう。 ○収集 AWSへのデータアップロード オンプレにあるデータをAWS（S3）にアップロード ・インターネット経由 ・専用線サービス（AWS Direct Connect、1/10Gbps）も可能 ・AWS Import/Export（HDDを送りつけてS3にアップロードしてくれる。Tokyoリージョンにはだない） ・インターネットVPN経由も可能 ・EC2上のデータももちろんできる。 ※WAN高速化ソリューションも利用可能。 ○保存 ・AmazonS3 99.999999999%の耐久性。 同一リージョン内の3箇所以上のDCに自動複製 容量無制限で低コスト（1G 約10円/月） ・Amazon Glacier データの利用準備に3.5～4.5時間かかる。 S3の約1/10という低コスト ○分析　オンプレミスだと運用が大変。 ・Amazon EC2 スケールアップ/ダウン、アウト/インが即座に可能。ライセンス持ち込みや従量課金に対応 スペックの種類が豊富（SSDとかもあるよと） ・Elastic MapReduce Hadoopをサポートしたの仮想サーバが簡単に用意可能。 S3、Dynamoとの連携も可能 ディストリビューションも選択可能（Apache、MapR） 追加のアプリ（Hive、Pig、HBase）なども利用可能。 ジョブの大きさに合わせてクラスタサイズを適切にすることでコスパがよくなる。 →HadoopのMRのデータのローカリティとかはどうなってるんだろう？ ○共有 ・AWS RDS MySQL、Oracle、SQLServerをサポート（PostgreSQLはないのかな？） 自動バックアップ、フェイルオーバー、パッチ適用機能があるよ ・Amazon DynamoDB AmazonオリジナルなNoSQLデータベース。論文有るよ。 運用管理は気にしなくていい。 性能については客指定の性能が出せるようになる。しかも変えられるよと。 ※データサイズに応じて以下を選択しましょう RDS、HBase on EMR、DynamoDB、S3 他にもEC2上で、CassandraやmongoDB、GlusterFSを使ってる事例もありますよ。 ○以上を繰り返すのが意味があります。そこで！ ・Simple Queue Service マネージド分散キューサービス 最低1度のメッセージ到達の保証。複数DC間で複製保存 ・Simple Workflow Service 進捗などの管理も可能 NASAのCURIOSITYの制御に利用？10m前進するのに10時間のバッチ処理がある。。。 データがなくて試せない！そんなあなたに！ ○AWS Public Data Sets すぐ使えるPublic Dataが用意されてるよ。 http://aws.amazon.com/jp/publicdatasets/ ★AWSのビッグデータ事例紹介　@shot6 ○NETFLIX ・どんな会社？ 2500万人以上のストリーミング会員 500億以上のイベント ・AWSの利用は？（保存） 8TB/日のイベントデータを収集しS3に。 Cassandra上の顧客データもS3に。 1PB以上のデータがS3に保存。 ・AWSの利用は？（解析） EMRでレコメンデーション、アドホック分析、パーソナライゼーションなど。 本番クラスタ（ずっと動かしている） アドホック分析用クラスタ（必要に応じて構築） 解析用のアルゴリズムをAPIで叩けて、ジョブとして定義されてるらしい ・Cassandraを使ってるよ。 Cassandraのクラスタをマルチリージョンで対応したりもしてる。 CassandraのBackupもやってる。OSSで公開されてる？ ※HBaseのものもあるよ。 ※AWS上のCassandra事例もいくつか広告系で出てるみたい。 ・High I/O Instances for EC2（SSDのインスタンスまだ東京に無いらしい。） ・AWSスケールアウトだけでなく、スケールアップも徐々に増えています。 ○yelp ・どんな会社？ 口コミサイト。 スペルミスの自動修正、検索ワード自動補完、 ・AWSの利用は？ WebサイトのログをS3に保存。 EMRを利用してHadoopClusterで解析してS3に保存している。 EMRは処理終了後にシャットダウンしてる。 ・データ解析が日常になった ○SHAZAM ・どんな会社？ 広告配信、モバイル系の配信をやってる会社。 Super Bowlの広告配信でAWS、DynamoDBを利用。 ※マイネット・ジャパンでもDynamoDBを利用している ○CLIMATE Corporation ・どんな会社？ 天候保険の会社 ・AWSの利用は？ 200TBの地質、天候データを解析して ○THOMSON REUTERS ・どんな会社？ 情報提供の会社。データの提供が元だけど、解析した結果の情報も提供してるみたい。 ・AWSの利用は？ MarketScanという18年分の個人の医療データ（個人情報自体はないみたい）を販売する、販促ールとして利用。 1500万人分の患者データを提供。 マーケットの分析に使えるデータの提供。 KARMASPHEREとEMRの組み合わせで、ソリューションを提供していますよと。 ・事例 1.MarketScanをS3にアップロード。 2.分析官が、KARMASPHERE経由でEMRにアクセス。 3.EMRにS3からデータロードされ、結果がRDS（Oracle）に保存 4.RDSに他の人達もアクセスして使ってるよと。 ○RANGESPAN ・どんな会社？ ECサイト向けのPaaSサービスを提供してるロンドンの会社。 ・AWSの利用は？ NLP、機械学習にEMRを利用？ mongoDBのクラスタを構築してる。 ※mongoDBの日本の事例としてCAがあるらしい。 ★Huahin Framework活用事例 on AWS @ryu_kobayashi ○Cassandra本とかもやられてるみたい。 ○EMRとは PaaSなんだけど、中身を自分でいじれるらしい。 Management Consoleでは3つのバージョンが使えるが、コマンドラインからだと他にも使えるみい。 ・HBaseはAmazonのDistributionのものだけ。 ・EMRのメリットは？ インフラの面倒を見なくていい。 クラスタの立ち上げも複数あげられるので簡単。本番実行と同じ環境 ・EMRのデメリット オンプレミスにすでにデータがあるとアップロードが大変。実際に物理HDDを送ったこともある（2,3日でAWS上にアップロードされた） 外に出せないデータがあると。。。 ○EMRのTips（EMRの連載に載ってますよ！http://gihyo.jp/dev/serial/01/emr） ・Bootstrapを設定 EMRのクラスタの起動前にメモリ設定とかHadoopの設定が可能にできる。 ・ファイルサイズを適切に Map数=splitを決めるコード を指定することで、処理が早くできるのかな？ ○EMRの起動には いろいろあるけど、HuahinEManagerを使うと使いやすいよ？ ○Huahin Frameworkの構成 ・Huahinの名前の由来は？ 社内のコードはワインの産地にするという決まり。 タイの観光地Hua Hinがワインの産地。 ・他のHadoop関連のマスコットより可愛いでしょ！？ ・Huahin Core MRのプログラムを簡易化 WritableとかSecondary Sortとか書かなくていい 考え方がSQL寄り 素のMRも書ける。Pig、Hiveだとパフォーマンスが難しい Huahin UnitというMRUnitをラップしたものもある ・Huahin Tools 汎用的な処理を集めたツール群だけど、Apache Logの成形のみ。 オンプレミスHadoop、スタンドアロン環境でも動かせるようになってる。 ・Huahin Manager Jobを管理するマネージャ Jobの実行 キューを持ってるので、複数の実行が可能だよ。 EMR対応してる。bootstrapに設定するとできるらしい。 ・Huahin EManager EMRのいろいろが管理できるみたい。 初期設定20までしかインスタンスが挙げられない上限があるらしいので気をつけましょうと。 キュー登録のPOST機能は便利そうだ。（EMR触る機会まだまだないけど。。。） EMRにはJobのkillがない→Job FlowをターミネートすればOK→実際にはEMRのマスタノードにSSHすればできるよ。→めんどくさいよね。。。 EManagerなら可能ですよと。これは必須だよなぁ。 ","date":1352477220,"dir":"post/2012/","id":"98c640616f997a323af625e34ba34850","lang":"ja","lastmod":1352477220,"permalink":"https://blog.johtani.info/blog/2012/11/10/aws-%E3%83%93%E3%83%83%E3%82%B0%E3%83%87%E3%83%BC%E3%82%BF%E6%B4%BB%E7%94%A8%E4%BA%8B%E4%BE%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-jawsug/","publishdate":"2012-11-10T01:07:00+09:00","summary":"初目黒（たぶん）で、初Amazonな感じで、流行りの「ビッグデータ」のセミナーに参加してきました。 とりあえず、いつもの自分用のメモを残してお","tags":["勉強会"],"title":"AWS ビッグデータ活用事例セミナーに参加しました。#jawsug(Jugemより移植)"},{"contents":"##Lucene/Solr 4.0.0リリース ついに、Lucene/Solr4.0.0がリリースされました。 MLで流れていましたが、3年越しのリリースだったようです。 コミッターの方々、JIRAにバグ報告をした方々、お疲れ様でした。\nということで、ちょっと忙しくなりそうです。。。 4.0の機能を調べたりもしたいですし、すこしずつ紹介もしたいです。\n本家サイトのニュースはこちら\n##lucene-gosenの4.0対応版について lucene-gosenも4.0正式版のjarを利用したバージョンを公開する予定です。 branches/4xでは、すでに作業を行なっており、jarファイルの差し替えは終了しています。 お急ぎの方は、branches/4xをエクスポートして、ビルドしていただくと利用可能となっています。 なお、Lucene/Solrのバージョンが上がっているため、lucene-gosenのメジャーバージョンも変更し、lucene-gosen-4.0.0としてリリースする予定ですしました。。（順当に行けば、3.0.0ですが、Luceneのメジャーバージョンに合わせたほうがわかりやすいかと思いまして。） また、現在、trunkが3.6.x対応のソースになっていますが、このあと、現在のbranches/4xのソースをtrunkにする予定です。 3.6.x対応のlucene-gosenについては、branches/lucene-gosen-rel2.0にて作業を行うこととなります。 今後は注意してチェックアウトするようにお願いいたします。\nということで、ダウンロードできるようにしました。 lcuene-gosen-4.0.0*.jarとついているものがLucene/Solr 4.0.0に対応したライブラリになります。\n","date":1350031500,"dir":"post/2012/","id":"922cc71fd28b1dac8f407f1d517f5595","lang":"ja","lastmod":1350031500,"permalink":"https://blog.johtani.info/blog/2012/10/12/lucene-solr-4-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9lucene-gosen%E3%81%AE4-0%E5%AF%BE%E5%BF%9C/","publishdate":"2012-10-12T17:45:00+09:00","summary":"##Lucene/Solr 4.0.0リリース ついに、Lucene/Solr4.0.0がリリースされました。 MLで流れていましたが、3年越しのリリースだったようです。","tags":["lucene-gosen"],"title":"Lucene/Solr 4.0.0リリース＆lucene-gosenの4.0対応(Jugemより移植)"},{"contents":"このイベントにウチダスペクトラムの枠でMahoutのコミッターである、Grant Ingersollさんが講演されるということで、興味があったので聞いて来ました。 （この枠だけ）\nLucidWorks社が現在展開している、LucidWorks BigDataの概要とコンセプトといった話の内容でしょうか。 LucidWorks社（元Lucid Imagination）はLucene/Solrのコミッターの方々が多く在籍している会社です。 検索システムに関するノウハウを元に、発見や解析といった部分にニーズが広がってきているという話の ざっくりした概要のはなしでした。 検索システムを中核にして、ログや検索で提供しているデータの解析などの重要そうなポイントが散りばめられて いるお話でした。\nもっと詳しい話を聞きたいなぁ。\n講演では日本語の資料でしたが、サイトに英語の資料がアップされているとのことでした。 原文が読めるのは非常に助かります。他のイベントなどでもこのように英語の資料も見れるようになると嬉しいです。\n以下は、いつものメモになります。\n場所：富士ソフト　アキバプラザ5Fホール 日時：16:10- ◯サーチ技術による情報の可視化 通常、検索と言うとWebサーチだけど、ウチダスペクトラムのやっている部分はエンタープライズ向け ナイスガイ＝Grant S. Ingersollという紹介 ◯サーチからSDAへ LuceneやSolrのお陰で、検索自体は簡単になってきている。 ◯サーチの進化 ユーザとデータを結びつける意味での検索の進化が必要 ユーザインタラクションや、アクセスの方法とか ◯SDA Search, Discovery and Analytics ・ユーザからのニーズ 検索、優先順序付け、新たな気づき、フィードバックによる学習 ・ビジネスからのニーズ ナレッジの有効活用 ◯ユーザ事例 保険会社での請求に関する不正利用分析を含んだクレーム処理と分析 ◯事例：個人に最適化された医薬品 DNAをベースに検索やファセットで医薬品を検索したり。 ◯事例：通信会社における通話記録処理 ログを元に検索して、不正通話などを解析 ◯SDA基盤に必要な要素 高速で拡張性のある、検索 大規模でのコスト効率が高いストレージと処理 NLPとMLにより解析などが向上 ◯SDAのアーキテクチャ 基盤 LucidWorks Search、Hadoop、HBase、ApachePig、Mahout、 NLP、 管理 Zookeeper インフラ ZABBIX、AWS、Chef データの流し込み Twitterからのデータとか ◯検索部分にフォーカス ・LucidWorks Search SolrCloudによる簡単なshard処理 ・Hadoop ログ、生データ、中間ファイルの保存 WebHDFS 小さなファイルには向いていない ・HBase メトリック、ユーザ履歴などのストレージ 課題 どこに正式に保存する？ リアルタイム処理 vs バッチ処理 分析はどこで行われるべきか？ ◯検索の実装に関連すること 3つのポイント 性能と拡張性 関連性 オペレーション（モニタリング、フェイルオーバーなど） ビジネス側では検索結果の適合性を重要視する 開発側は性能を重視する傾向がある。 ◯適合性に関して テストが重要。 クエリ、クリック、表示したドキュメントなど、すべて保存すべき！ ◯Discoveryにフォーカス ◯MahoutによるDiscovery 3つのC ・協調フィルタリング ・クラシフィケーション ・クラスタリング 追加事項 課題 収束を伴う計算コストの高い機械学習アルゴリズム Mahout ◯余談：Experiment Management ◯Analyticsにフォーカス Rとか、うまく活用 検索エンジン自体でもできることがある。ファセット、TF、DF/IDF SearchとDiscoveryの定量化 ログ、ナビゲーション分析 ","date":1348650492,"dir":"post/2012/","id":"43501cdf0de25278a208cbb9aad80012","lang":"ja","lastmod":1348650492,"permalink":"https://blog.johtani.info/blog/2012/09/26/lucid%E3%81%AEgrant-ingersoll%E3%81%95%E3%82%93%E3%81%AE%E8%AC%9B%E6%BC%94%E3%82%92%E8%81%9E%E3%81%84%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-09-26T18:08:12+09:00","summary":"このイベントにウチダスペクトラムの枠でMahoutのコミッターである、Grant Ingersollさんが講演されるということで、興味があった","tags":["勉強会"],"title":"LucidのGrant Ingersollさんの講演を聞いてきました(Jugemより移植)"},{"contents":"PFIオープンセミナー2012に参加してきました。 対象から微妙に外れてたり、話の内容についていけるか自信がありませんでしたが、参加してきました。 PFIさんは前から面白そうなことやってる会社だなぁと思っていたので。\n面白い話がいっぱい聞けました。 電池が切れそうなので、とりあえず、まずはメモをアップしときます。 かろうじてついていけたという感じですが。 丸山先生の話はアーキテクチャの話に入る前のビッグデータの光と影の話がよかったです。 ビッグデータと言っても、まずは、サンプリングなどで小さなデータで処理できるかもしれないと考えるのも必要なのでは？という話や、相関があるからといって、因果が有るわけではないとか、おそらく、統計やってる人や、数学やってる人にしてみれば、当たり前の事なんでしょうが、その部分に警鐘を鳴らす話が聞けたのは良かったです。 もちろん、ビッグデータでなければ意味が無い解析などもありますという話もきちんと出ていました。\n伊藤さんの話は、Screwと呼ばれる、多言語解析基盤のお話です。その前にSedueの紹介で、SolrとSedueの比較の話も出ていました。（若干、強引な感じもしましたが。。。） 多言語解析基盤は、Solrでも少し入ってきています。ただ、それよりも汎用的な作りになるようなので、今後Solrと組み合わせて使うといったことも可能になるかもしれません。 まだ、対応言語などが少ないので今後に期待という感じでしょうか。 複数の言語が混ざった時の挙動がどうなるのかや、身近な文章での言語判定の正確さは少し気になります。\nサイバーセキュリティの話も面白かったのですが、話が多岐にわたるのと、スライドの情報量の多さに少しついていけませんでした。 資料が公開されたら、もう一度見直したいかなぁと。\n比戸さんの話は、Jubatusと関連のある話でした。機械学習の実際の利用の話が特に興味深かったです。 最近になって、ようやく、実際のデータを利用した話が出てきているみたいで、もっと事例が出てくると機械学習も身近になりそうだなぁと。\n最後は、日経BPの中田さんの話でした。これが、一番想像していたものと内容が違って、驚きつつ、楽しめた話でした。 ビッグデータというバズワードがいかにして生まれたのかがよく分かりました。 私は、バズワードだなぁと思う程度だったのですが、出てきた背景にある程度意味があるという考察に感心して聞き入ってしまいました。\nということで、思っていたよりも話の内容についていけたので、講演された方々の話しのされ方が良かっただと思います。\n少し無理をして参加してよかったと。\n残念だったのは、会場が地下だったため、携帯が入らなかったことでしょうか。 私はe-mobileで接続していたので大丈夫でしたが、docomoの携帯は圏外でした。 ツイートがもう少し盛り上がれば、もっと質問も出たのかもしれないです。\nhttp://preferred.jp/news/seminar/\n資料が公開されたので、リンクを貼っておきます。 PFIの方たちの資料へのリンク： http://preferred.jp/news/?id=1139\nゲスト講師の資料へのリンク： http://preferred.jp/news/?id=1159\n◯「多様化する情報を支える技術」　講師：西川徹（株式会社プリファードインフラストラクチャー　代表取締役） ・PFIの説明 VCに頼らない。製品につながるビジネスにこだわる（受託開発しない）、技術の多様性を重視 ・PFIの技術領域、ビジネス 製品開発（Sedue/Bazil/Jubatus）、自然言語処理、機械学習、分散システムなど ・”人”が生み出すデータと\u0026#34;機械\u0026#34;が生み出すデータ ビッグデータの発端はGoogleが元じゃないか？→最後の公演で解説があるよ 人：質が高いけど、量が少ない 機械：質は低いけど、量が多い ・検索システムについてのお話 社内の資料とか情報が、人によって、まちまちなデータの保存（形式、場所など）が実施されてしまう。 情報検索技術と大規模データ ・人のデータへ必要なアプローチ より検索システムを活用してもらうために、楽に整理できる仕組みなどをどう提供するか 質の高いデータなのに、形式的な共有しかできていないのはもったいない ・機械のデータへ必要なアプローチ 大量データと高度な解析が重要（CEPとか） デバイスが性能向上→流れてくるデータが大量に→蓄積するだけでも問題になってくる →蓄積したデータを扱うだけでも処理コストが高くなる 分析をオンライン化、ストリーム化すること→Jubatusで貯めずに高度な解析をしましょう。 Edge-Heavyになりつつある。　◯「ITアーキテクチャはどこへ向かうのか」 講師：丸山宏氏（統計数理研究所　副所長　モデリング研究系教授　工学博士） ・ビッグデータの光と影 「その数学が戦略を決める」という本がオススメ ・大量データでも、ランダムサンプリングでとければ、ビッグデータじゃなくてもいいよね。 もちろん、ランダムサンプリングだけじゃダメな場合もある。 ・Hadoopが解ける問題領域って少ないのでは。 ・TVを見る時間が長い人ほど、方言の使用率が高い 因果関係と相関関係の違いをきちんと理解しましょう。 ・データをきちんと理解して意思決定などをしたほうがいいよと。 ・つぎのアーキテクチャは何か？ ・コンピュータ・アーキテクチャの歴史 ConnetionMachine CM-1（1985） SPARC Transputer（CSPによる並列性、Occam） SymbolicsLispMachine Intelアーキテクチャの台頭により、アーキテクチャの研究が廃れてくる ・クラサバ、スマホ・クラウドなどのアーキテクチャの話 ・じゃあつぎは？ Edge-Heay Data＝スマホなどデータが保存される場所がEdgeになりつつある ビッグデータのほとんどが廃棄されるデータ ・Edge-Heavy Dataに特化したアーキテクチャとは？ 分散マッチング・プロトコル→サマリ情報を交換することで、絞り込みが可能 X=3とした場合、センサーとかなら、ピンポイントな値ではなく、範囲では。 分布表現を1stクラスオブジェクトとするプログラミング言語が必要では？ ・アーキテクチャの変節点を見極めよう QA： Q：スパースネス問題がランダムサンプリングやフィルタリングじゃ解けないんでは？ A：はい。ただ、その前にやることがあるはずですよねという注意喚起の意味での発表です。 価値に応じて、EdgeにあるデータをCenterに持ってくるという考え方が必要。 今は価値が見いだせないのなら、Centerにまで持ってこなくてもいいのでは。 ◯「グローバル化する情報処理」 講師：伊藤敬彦（株式会社プリファードインフラストラクチャー 研究開発部門　リサーチャー） ・Sedueの説明 NHKニュースなどで ・提供する機能 ・検索補助 レコメンド、サジェストなど ・レコメンド機能の紹介 ・Sedue/Solrの比較 サポート体制：開発チームがサポートしてくれる 安定性：GCがないのがいい 付加機能： 検索の完全性：接尾辞配列による検索 ・多言語処理の話 ・翻訳ではなく、任意の自然言語言語で動作・精度を向上させる処理の話。 ・背景 サービスのグローバル化、会社組織のグローバル化 ・複数言語を扱う場合の難しさ 多言語解析基盤Screwの開発。 1.必要な処理を順番に適用する 処理の順序は設定で。出力はJSONで。 例：言語同定、単語分割、単語正規化 →言語同定処理で 2.言語ごとに必要な処理を適用 ・疑問 ScrewはSolrとの組み合わせもできる？ 複数言語が混ざった文章の場合にどういう形で動作する？ 言語判定は独自実装？ ◯「BigData処理技術とサイバーセキュリティ」→題名変更されてた 講師：桑名栄二氏（NTTセキュアプラットフォーム研究所　所長） ・経歴 Jubatusプロジェクト立ち上げに参画 ・攻撃に関する話 原因のわかっていないケースが多い。 ・端末の初期設定のパスワードとかが狙われるケースも多い ・変化する攻撃、変化するシステム・サービス、変化するデータ ・マルウェアの分類にJubatus ・不正IPアドレスを機械学習して ・ABC 「あたりまえ」のことを「ばかみたいに」「ちゃんとやる」 ◯「先進ビッグデータ応用を支える機械学習に求められる新技術」 講師：比戸将平（株式会社プリファードインフラストラクチャー　研究開発部門　リサーチャー） ・ビッグデータ分析はより深い地検を得られるビッグデータ「解析」へ ・ビッグデータ分析プロセス Volume、Variety、Velocity 蓄積（NoSQL系）、分析（CEP）、両方やるのがHadoop ・分析から深い解析へ 予測、カテゴリ分類、レコメンド、異常検知　これを機械学習で解決する方向で ・機械学習を応用している例 クレジットカードの不正利用検知：FICO ネットワーク攻撃/侵入検出 Jeopardy!でクイズ王に勝利 医療診断支援 ・データ解析技術への過度な期待と現実とのギャップ いろいろできるみたいだけど、何が必要？ ・ビッグデータ処理系を使える人 ・データサイエンティスト ・機械学習ツール ・ビッグデータ処理系での機械学習への対応状況 Hadoop本体（YARN） MapReduce系（Mahout、AllReduce or Vowpal Wabbit、SystemML） 非MapReduce系（Spark） ・機械学習からビッグデータへの歩み寄り ベンチマーク性能への固執とか、応用との乖離を批判する論文もあるらしい。 ・機械学習の応用例 Machine Lerning for the New York City Power Grid[Rudin et al., TPAMI, 2012] 電力配電設備の障害予測・検知 実データを用いた例が今後増えていくのでは。 ・今後重要になる技術とPFIの取り組み ・データ解析の敷居を下げるためのトレーサビリティ 機械学習向けスクリプト言語は敷居が高い WekaやSPSSのようなアイコンベースのデータ処理プロセスの記述は前処理には強力だけど、機械学習とは相性が良くない 結果が見える化部分との統合が不十分。 ・Bazil Farm学習結果分析例 Tweet年齢推定、Tweet性別推定 ◯「“ビッグデータ”が話題になった理由」 講師：中田敦氏（株式会社日経BP社　記者） ・自己紹介 ・バズワードができるまで まずは、「クラウド」のバズワードの歴史 「バズワードはIT企業やThe Economist誌の煽りでなく一般企業の経営陣が納得すると生まれる」 ・なぜ経営者がビッグデータに興味を？ 「ザ・クオンツ」という書籍に金融業界のルールの変化が書かれてる。面白いよ。 Google/Amazonに対する警戒心から。 破壊的な新規産業者へ対抗して行かないといけない思うところからビッグデータが流行ってるのでは。 「買ってきたIT」は差別化要因にならないのでは？→自分で作ったITなら差別化できる。 ・競争力は自分で作るしか無い 日本のとある特殊事情 ITエンジニアの所属先が日米で割合がぜんぜん違う。米国はユーザ企業が75%、日本は25%くらい ・ビッグデータの次はなに？ 3次元プリンタがあれば、好きなモノが作れちゃう。＝消費地の近くで作成しちゃえば良くなるのでは。 ","date":1348214700,"dir":"post/2012/","id":"89abaa7f21cf788ce4744e3e61173291","lang":"ja","lastmod":1348214700,"permalink":"https://blog.johtani.info/blog/2012/09/21/pfi%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC2012%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pfiopen2012/","publishdate":"2012-09-21T17:05:00+09:00","summary":"PFIオープンセミナー2012に参加してきました。 対象から微妙に外れてたり、話の内容についていけるか自信がありませんでしたが、参加してきまし","tags":["勉強会"],"title":"PFIオープンセミナー2012に参加してきました。 #pfiopen2012(Jugemより移植)"},{"contents":"友人にお値打価格で購入したMac miniはMountain Lionにアップデートしてたのですが、手元のAirはまだアップデートしていませんでした。\n夏休み中にバックアップ＋アップデートをしてしまおうと思いMountain Lionにアップデートはしていたのですが、 本格的に触り始めると色々と動かないものがあったので、備忘録としてブログを書いておきます。 （まだ途中ですが。）\n###1.Eclipseが起動しない Java6が未インストール状態になったみたいで、Eclipseを起動すると、Java6をインストールしなさいと言われました。 で、私の記憶が確かなら、前はJavaコマンドを実行するとインストールされたんですが、ターミナルでjavaコマンドを実行するとjavaはすでにインストールされてる模様。。。 あれ？と思い、-versionを実行すると、JDK7u4と出るじゃないですか。 どうやら、Java7u4は別途入れてたものが残ってる模様。 さて、どーする？ということで、ツイートしたりぐぐってみて、「Java Preferences」なる設定用のアプリ？が有ることに気づき、とりあえず開いてみたらJava6ないからインストールしたら？と言われました。 結果オーライということで、インストール開始。 無事、インストールも終了。Eclipseも起動しました。（ただし、今度はMercurialのプラグインがPythonのライブラリが無いとエラーを出すことに） ###2.Xcodeが起動しない。 使ってはいないんですが、Javaの件を調べるのに、起動したらLionじゃないと駄目だよと。 ということで、Xcodeもインストールしなおし。 ###3. homebrewが動かない 1.で書いた方法で、Eclipse自体は起動したんですが、Mercurialのプラグインがエラーを吐き始めました。 で、見てみると、hgコマンドを実行しようとしてなんか、壊れていると。 で、hgコマンドってどうやってインストールしたか思い出さないまま、とりあえず、homebrewだっけ？と勘違いしたまま、「brew update」を実行したらエラーがでて、「brew install git」でしょ？って言われてしまいました。 コメントにもいただいていたように、Xcodeをインストールしたのだが、コマンドラインツールが入ってないというのが影響しているみたいです。。。 で、ググってみると、こんな情報が。[http://labs.torques.jp/2012/07/04/2830/](http://labs.torques.jp/2012/07/04/2830/) ただ、そこに有るようにPreferenceのダウンロードを開いてもなーんにも表示されません。 で、更にググってこちらの情報に。[http://qiita.com/items/9dd797f42e7bea674705](http://qiita.com/items/9dd797f42e7bea674705)（なんだか、TLで見かける人のお名前が！） AppleのDeveloperサイトからダウンロードかぁと思いつつダウンロード用のリンクを踏んだら、アカウント登録しろとのページが。。。 なかなか遠い道のりですね。。。 Appleのアカウント自体は持ってるので、Developerへの追加登録なんですが、日本語が文字化けしまくりの確認ページが出る始末。 もう、めんどくさいので、そのまま登録しちゃいました。 で、ダウンロードする前にもう一回XcodeのPreference見てみたらなんか、ダウンロードする候補が出てきてるじゃないですか！ 結局、XcodeのPereference画面からダウンロードすることにしました。 AppleのDeveloperに登録したからなのか、Xcodeのプロジェクトを作ろうとしてXcodeをきちんと起動したからなのかは結局わかっていません。。。 良くないよなぁ。（ご存知の方いたらコメントもらえると嬉しいです。） で、やっと「homebrew」を入れようかなぁと。 一応その前に「sudo brew update」ってやってみたらどうなる？と挑戦したら今度は動きました。 homebrewが何を判断してinstallでしょ？って言ってたのかもわかっていませんが、updateで良かったみたいです。 ついでに、upgradeもしときました。（こっちは後からインストールしたもののバージョンが上がってるものがあったら更新してくれるコマンドかなぁ？）\n###4. pipの更新 ただ、brewをupdateしても相変わらず、EclipseのMercurialのPluginはエラーを出してました。 で、ターミナルからhgコマンドを実行してみたら同じエラーが。まぁ、そうですよね。 エラーメッセージを頼りにこれまたググってみたら、同じ状況のひとがいました。[https://groups.google.com/forum/#!msg/mercurial-ja/MxY6lejLXxo/OgJA_knXV6cJ](https://groups.google.com/forum/#!msg/mercurial-ja/MxY6lejLXxo/OgJA_knXV6cJ)（ここにもTLでお世話になってる方のお名前が！！） で、書いてあるように「とりあえず pip install mercurial で解決しました. 」ということで、コマンドを実行して見ることに。 これが、また失敗します。。。（日頃の行いが悪い？？てか、日頃MBAをメンテできてないのが悪いのか。。。） そういえば、過去のMBAセットアップのメモを残してたなぁと思い出して「johtani mercurial」でググってみるとちゃんと[書いてある](http://johtani.jugem.jp/?eid=34)じゃないですかー（偉いぞ、自分） ということで、「sudo easy_install pip」でpipを更新してから「sudo pip install Mercurial」で無事、hgコマンドもインストールし直せました。 Eclipseを起動してもエラーが出ない。（まだbitbucketに接続確認まではできてないですが。。。眠さに勝てず寝てしまいました。） ","date":1346650440,"dir":"post/2012/","id":"7604edf307a5e96120606c8dda06458f","lang":"ja","lastmod":1346650440,"permalink":"https://blog.johtani.info/blog/2012/09/03/%E3%83%A1%E3%82%A4%E3%83%B3mba%E3%82%92mountain-lion%E3%81%AB%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88%E3%81%84%E3%82%8D%E3%81%84%E3%82%8D%E7%A2%BA%E8%AA%8D%E4%B8%AD/","publishdate":"2012-09-03T14:34:00+09:00","summary":"友人にお値打価格で購入したMac miniはMountain Lionにアップデートしてたのですが、手元のAirはまだアップデートしていませんで","tags":["備忘録"],"title":"メインMBAをMountain Lionにアップデート（いろいろ確認中）(Jugemより移植)"},{"contents":"興味をもちつつ、触っていない軟弱者ですが、興味があるので今回も話を聞きに行って来ました。\nまずは、作者古橋さんによるFluentdの魅力や次期バージョンのお話。 あいかわらずわかりやすいスライドで話もわかりやすくてよかったです。 どうしても実績という点を懸念事項として上げる人が多いというアンケートを元に、各社が使ってるし導入もしやすいですというお話。 ここまでしてもらってるのに触ってないなんてほんと申し訳ないです。。。\n次は楽天の方によるCloud Foundryのログの問題点解消のためのFluentd導入のお話。 EC2でもそうですが、ファイルが永続化されない？のでログが消えてしまうという問題があるので、 集約しましょうと。 いままでとは少し違う問題点からの話でした。\n次はドリコムの方（浴衣？甚平？でかっこ良く発表）のIDCをまたいだFluentdの活用と、Fluentd自体の監視などについてのお話。 実際にログが増殖して苦労された点を解決するために考えられた監視項目など、あとで見返したくなる資料でした。 実際に試行錯誤されたあとの話はやはりありがたいです。 あと、お子さんが可愛かったｗ\nつぎのCROOZの方のPCがWindowsだったため（？）プロジェクターに繋がらず、急遽QAタイム。 このあたりの@doryokujinの話のつなぎの旨さとかほんとすごいなぁと感心します。\nで、Macに乗り換えてCROOZの方の発表。 Fluentd＋TreasureDataのお話。少人数（というか一人？）でも簡単にログ収集の仕組みが作れて、しかも保存先のサーバを用意せずに簡単な解析もできるというお話。 これは、ちょっとやってみようと思う人（少なくとも、私はやろうと思った）が増えたんじゃないかなぁという発表でした。 スライドがなぜか最後のほうが見えなくなってしまったので、第３回でも発表されるということになってましたｗ 最後は新大阪から文字通り駆けつけた玉川さんのHBase本＋そのた今後の翻訳本の紹介。 つぎはHiveの本も出てくるみたいでした。 日本語の資料ってホント助かります。購入しないと翻訳本が出る機会もないみたいなので皆さん買ってくださいとのこと。 HBaseはまだ触りそうにないから９月に出るAWSの本でも買おうかなぁ。 あ、日本語で解説してあるSolrの本もあるので是非買ってください！\nその後は懇親会でした。今回もTL上でズケズケと私が勝手に絡んでいる方たちにリアルにお会いできたので楽しかったです。\n自分もフロントよりも、バックエンドに興味があるし、実際に運用されてる人の話が多く聞けるので次回も参加したいです。 それまでにどこかで触るかplugin作るかしないとなぁ。\nということで、以下はいつもの適当メモです。\n開催日時：2012/08/22 18:00 ～ 22:00 場所：グリー株式会社 14F セミナールームYosemite ◎「Fluentdの現在と未来」　Treasure Data, Inc.　古橋　貞之 (@frsyuki) ◯アンケートの内訳 ◯ドキュメント欲しい？ ※思ったより日本語のドキュメントじゃなくてもよさそうだった。 ◯loggingってなんでいるの？ いろいろな解析ってあるよね。 ◯ログの集約、保存、などの問題点について フォーマットが混在 集約するのもいろんなスクリプトが混在 ◯メリット ・プラグインアーキテクチャ in/outに合わせてプラグインが用意/開発可能 ・フォーマットがJSON アプリでの解析が楽 ・HA構成が可能 ◯実績がない？→ 誰が使ってる？ COOKPADとか、NHNとか ◯次期バージョンの構想 ・設定ファイルで色々とらくできるよ。 ・MessagePackのv5に対応 ・td-agent-lite などなど ◯QA Q：時刻にミリ秒を持つことは可能？ A：互換性も気になりますが、検討します。 Q：JSONで構造化が売りだが、Flumeとかはテキストだけど、テキスト A：ログのパース時にやるというスタンス。 Q：日本語ドキュメントがやっぱり欲しい。手伝います！ A：別ブランチで翻訳しながら公開して欲しいし、バラバラにやるよりいいので。 Q：Windowsでも動かしたいけど、cool.ioの移植とか考えてないですか。 A：次期で、fluentdのコアからはcool.ioを外す予定です。 ◎「Logging Infrastructure in PaaS by Fluentd」　Rakuten, Inc.　Yohei Sasaki (@yssk22), Waldemar Quevedo (@wallyqs) ◯Cloud Foundryの説明 ◯Cloud Foundryの問題点 解析しようにもログが消えてしまう。。。 なので、Fluentdでログを集める仕組みを作ったよと。 これかな？ https://github.com/rakutentech/dea/ ◎「Fluentdを優しく見守る監視事例」　株式会社ドリコム　外道父 ( @GedowFather ) ◯概要： Fluentdをより穏やかに安定稼働させるための監視項目と自動処理について。また，その実運用における障害例なども紹介したいと思います。 ◯目次 ◯動作環境 ・IDCもバラバラな環境のログを一箇所に集約。 グローバルなネットで、圧縮、暗号化し、VPN使ってない ・tailのプラグインを改良して利用 copy、flow counterを利用 forwardも改良 Flume OGとは比較にならないし、FlumeNGはOGと全然違うから論外だった。 ◯ローカル監視 ・monit使って監視してる。 ログを記録してるか、内容が正しいか td-agentが正しく起動してるか、Collectorに送っているか 重複起動してないかとか、起動してるかとか。 ※重複起動でログが増えてた（@mazgi濡れ衣事件） HDFSに送ってるか、保存されてるか ◯リモート監視 アラート/グラフ作成の集約 状態の可視化 Collectorのキャパシティ管理 Agentにキャパシティの心配はほぼないが、Collectorは足りなくなる可能性がある。 ◯野望 CollectorでAgentを把握したい ◯QA Q：圧縮はどうやって？ A：forwardを改造してやっている。 ◎QAタイム Q：秒間どのくらい出るの？ A；秒間8000メッセージくらいらしい。 Q：ハートビートの取りこぼしは？ A：案1：UDPじゃなくて、TCPにする。案２：TCP接続してたらハートビートのカウントとしてしまう。 Q：CollectorのCPUに影響があるのってなに？ A：ロックがCPUを食う＝ロックが影響→リクエスト量を減らす Q：Windows対応はいつ？（発生源がWindows） A：td-agent-liteをWindows対応にしたいと思ってる。 Q：F#の実装とかテストは？ A：性能値の測定までは行ってない。メッセージが送れたなぁくらい。 Q：設定のDSL化はv11ではなくなったの？ A：ホスト名は入れたい。設定はやっぱり設定だけにしたい（プログラムは入れたくない） プラグイン側がDSL対応してればDSLできるようなものは入れようかと思ってるが、 DSLは延期したい。 A（tagomoris）：DSL化したいパターンが幾つかに絞れるなぁと思ってて、それに合わせたプラグインをいくつか作ってるよー。 ◎「Fluentd \u0026amp; Treasure Data でこっそり始めるログ集計」　CROOZ 株式会社　池田 朋大（ @mikeda ） ◯概要： FluentdとTreasureDataプラットフォームを使って、1インフラエンジニアが勢いでログ集計システムを作ってみたお話です ◯アクセスログ、エラーログ、メールログ（試験中）を集めてる。 ◯TreasureData 500Gまで無料なのかー。 ◯ダマで入れてもばれないぞ！ ◯最後は心の目で見えるスライドでした。 ◎祝・O\u0026#39;Reilly HBase 訳本発売。訳者本人によるPR。　Sky株式会社 玉川 竜司　※ O\u0026#39;Reillyの新刊「HBase 」　http://www.oreilly.co.jp/books/9784873115665/ ◎懇親会 そうそう、ステッカーもらったのでアンケート書きましたｗ ","date":1345657200,"dir":"post/2012/","id":"775894425f5a7436f56fc5a3b4a2cfaa","lang":"ja","lastmod":1345657200,"permalink":"https://blog.johtani.info/blog/2012/08/23/fluentd-meetup-in-japan--2--fluentd-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-08-23T02:40:00+09:00","summary":"興味をもちつつ、触っていない軟弱者ですが、興味があるので今回も話を聞きに行って来ました。 まずは、作者古橋さんによるFluentdの魅力や次期","tags":["勉強会"],"title":"Fluentd meetup in Japan #2 #fluentd に参加しました。(Jugemより移植)"},{"contents":"またまた飲みに行って参加してきました。 今回は、Rails、iOSでのTwitter連携の話から、ツイート分析、クライアントアプリの開発の苦労？楽しい話と、 幅広い話題でこれまた面白かったです。\nRailsはあとで、もう一回資料＋ビデオがみたいかも。あと、発表者の方が言ってたけど他の言語の似たようなサンプルがあると面白いかも。（Solr入門みたいに同じ題材で違う言語のサンプルとか）\nツイート分析は、私の使い方とは異なる分析結果がちょっと意外でした。土日はあんまりツイートしないからなぁ。 利用時間帯とかは、他のSNS（Facebookとかmixiとか）の分析と比較してみると面白いのかも。 まぁ、深夜帯はそれほど利用は無いだろうけど。\nAttaccaは自社や自宅でコーディングするときに利用させてもらってます。 どうしても自分のお気に入りのリストを作ってそれを聞くので満足しちゃうんで、 他の人のお気に入りも一緒にシャッフルして再生とかできると面白いかもなぁ。 もう少し、他にも曲を発見したいんだけど、その導線がもう少しうまく行くと嬉しいかも。\nチャーハン諸島の話は開発者の原点みたいな話で面白かった。やっぱり、自分で作るの大事だよなぁと。 作りたいと思うものがあるのはいいことだし、実際作ってみないとわからないこともいっぱいありますよねぇ。 ただ、何か作ろうかなぁと思うものがあるのはちょっとうらやましいとも思いました。 なかなかサービスとか、ほしいものを作ろうと思うところまで行かないからなぁ。年取ったのかなぁ。\n懇親会では、いつものように@twtrfkさんと喋って、あと Lytroを触らせてもらいました！ 思ったよりも大きいのが第一印象。 ぱっと見で、何の変哲もないところがズームするところだったりと、インタフェースがちょっとおもしろかったです。 ピントが後から合わせられるということで、どうしても同じ構図になっちゃうのがなぁという話も聞けましたｗ けど、ちょっと欲しいかもなぁ。動くものを撮るとどんな感じなのかも聞くんだった。\n次回は9月中旬！らしいので、余力がありそうだったらまた遊びに行きます。\n日時：2012/08/01 19:00 ～ 21:00 場所：デジタルハリウッド東京本校 1Fセミナールーム\nいつもの自己紹介タイム\n@i7a16k(@_gifteeの中の人)　スライドはこちら\n「RailsでTwitter連携アプリをサクっと作る」 ・まずは、Railsの紹介 MVC+routes.rbの紹介 ・Dev Twitterの登録する必要なとことか。 ・Railsのインストールから起動まで。 ・実際にログイン画面を作成するまでの紹介 コーディングするコマンドの紹介。動画付き omniauth_twitter ってのを使うみたい。 ・サインイン、サインアウトまで。 ツイートは次回！ 録画がよくできてて、それに合わせてしゃべるのもうまいなぁ。 @teapipin(ツイッター分析シリーズ の方)　スライドはこちら\n「約173万ツイートを調査して分かったTwitterの利用動向」 ・ハンドル名は午後の紅茶からきてる？＋ピピン＠ ・ブログで色々公開してます。 ・サービス作るのに、下調べをしてみましたというお話 情報が無かったから、自分で調べてみたよと。（すばらしい） ・Streaming APIで取得 タイムゾーンとか言語設定の取得でもうまく取れない。。。 ということで、UnicodeBlockで判定してみたけど、、、 最後は手作業で不要データを除去（すごい！） ・4日間で172万ツイート （金環日食とかスカイツリーのイベントがあったので、4日間で我慢） ・上位5個で50%を占めるクライアントみたい ・日曜日が多いらしい ・携帯が60%くらい ・位置情報（Geoタグつき） 日本が多い。4sqが40%占めてる。 店舗情報や天気情報などもあるらしい。 人口と関係した相関が散布図でわかった。 そこで、ツイート内容との関係を分析 あとで資料みたいなー @i2key(#attacca の関係者)　スライドはこちら\n「iOSのTwitterFrameworkを使ってみたら・・・・」 ・Twitter4Jのほうが楽だったよー デモがいいね！ ・アーキテクチャ play!をバックエンド。Amazonとか。 iOS Twitter framework ・Reverse Authの使い方とか。 申請してから、20日間かかった。 @Mocel(チャーハン諸島 開発者)　スライドはこちら\n「(仮)Twitter クライアントの開発とかについて」 ・趣味プログラマー ・「ラーメン大陸」のクローン：「チャーハン諸島」を開発 Excel溶けこむGUI Javaで実装 コマンドライン風のTL画面もある（自分では使ってないけど） 「電力会社の電力使用量モニター」もクライアント初搭載！ ラーメン大陸のバージョンチェックも可能ｗ ・開発したことで 自分のニーズにジャストフィット 優しい気持ちになれる（苦労がわかる） Twitter APIのテストとかもすぐ試せる ・GUIアプリ開発のノウハウも手に入るからオススメ ・API利用規約は読んどこうね ・自動アップデート機能がいるよ。→バージョンごとのサポートがなくなるよ。 ・通信エラー前提で作りましょう ・鍵付きの非公式RTはやめなさい。 ・Twitterクライアントの作成はおもしろいよ！ 反応がプレッシャーになることもあるけど。 おもしろ機能をつけるのがいいよーと 話が上手で聞きやすかった。 ","date":1343875800,"dir":"post/2012/","id":"8a29f62d1bebfe7b8008d7f264b56b4e","lang":"ja","lastmod":1343875800,"permalink":"https://blog.johtani.info/blog/2012/08/02/twitter-%E5%8B%89%E5%BC%B7%E4%BC%9A--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-08-02T11:50:00+09:00","summary":"またまた飲みに行って参加してきました。 今回は、Rails、iOSでのTwitter連携の話から、ツイート分析、クライアントアプリの開発の苦労","tags":["勉強会"],"title":"Twitter 勉強会 #twtr_hack に参加しました。(Jugemより移植)"},{"contents":"ということで、ステッカー欲しさ？に勉強中の話を恥ずかしげもなく偉そうにしゃべってきました。 #pyfesは以前から、気になっていたんですが、タイミングがあわず初の参加になりました。 TwitterのプロフィールにSenseiDBに興味あると書いていたら、@voluntusさんに声をかけていただけて、 さらになぜかelasticsearchの話をすることにして話をしてきました。 まだまだ、いろんな意味（プレゼン的にも内容的にも）で至らない所だらけだったので反省しまくりですが、 これでまた経験値が稼げたかなと。次回に活かしたいと思いますです。 やっぱり、しっかり勉強して、シナリオを練ってから発表しないとダメですね。。。\n発表のスライドは一番最後にリンクを用意しておきましたので、興味があれば見てもらえればと思います。\nということで、いつものメモを残しておきます。\n日時：日本オラクル青山センター 場所：2012/07/28 10:00 - 20:00 概要：こちらにページあり\n前半（10時から15時）はハンズオンなどをやられてました。参加せずにスライドを微調整して、他の勉強会のスライドをいじったりしてました。 以下は、15時から行われたスライドのメモになります。\n◯PyConJP の宣伝　@shomah4a（LT） 9/15-17 PythonカンファレンスJapan App Engine、Django、Sphinxなどのカンファレンスも併設 遠方参加者支援制度があるらしい。 ◯elasticsearch 入門　@johtani わかりにくい話でしたかねぇ。。。 ◯たのしいうぇっぶくろーら　@tokoroten（LT） index.htmlをクロールしまくってる社畜2.0の人らしい。 ◯Sphinxを使って翻訳してたら本が出てた話　@ymotongpoo（LT） OSSでもドキュメント翻訳でお手伝いできるよ。 そしたら、いつのまにか書籍も出せたよ。 スライド\n◯iOS関連のお話　@Seasons バイナリ解析をしてゴニョゴニョする話。 解析するのに何を使ったとか思考の遷移を説明してくれるのでわかりやすい。 スライドが大きなマインドマップを切り出した形。 ◯HBaseのお話　@shiumachi HBase 分散DB 列ファミリ思考 HBaseなんで？ RDB→シャーディング→だるい。。。 シャーディング→スケールできねー nandeHBase？ 書き込みスケールできるよ。 KVS HBaseのデータ構造 キーがいろいろな情報を含んでる キーがソートされてる HBaseのテーブル構造 リージョンがシャーディングの情報もと？ リージョン見つけなど スライド\n◯PythonではじめるGit　@mkouhei GitPython LXCホスト？ GitもPythonも初心者だわー ◯勉強会を成長させる参加者になろう　@sawonya イラストレーター（スタートアップRubyのイラスト書いた人。サインもらいましたｗ）。 参加者が増えるとなにがいいの？など。 勉強会参加に向けた勉強会の講師とかやられてるらしい。 スライド\n◯IT 系勉強会ネタ(仮)　@tmmkr アジャイルサムライを読んだ情報を共有したくなって読書会を開催してみた！ ビアバッシュのケータリングとかは楽天デリバリーとか、カクヤスがいいよ。 かなり、いいスライドなので、あとで見返す。 今、読書会やったりしてるし、Solr勉強会の役にも立てそうだし。 スライド\n◯Do not invent your RNG...　@kenji_rikitake Androidの乱数のコードがすごいらしい（ひどい） Pythonの乱数ではos.urandomを使うのが安全です。 オレオレ乱数は作っちゃ駄目！ ◯分散ファイルシステム（LeoFS）　@yosukehara LeoFSの開発者の方。 Erlangで98%書いてある。 Masterノードは存在しない。SPOFになるから。 分散システムとして元にした概念とか論文ってあるんだろうか？ ◯継続的デリバリー　@troter CIとデリバリーの話。 いいこと書いてあるんだけど、実際のツールの話しがないのが辛いこともある ということで、Python周りのツールをこうして見たよというお話。 Rubyの方がものがいろいろ揃ってるらしい ◯クライアントサイドのみで作ったダッシュボード　@takufukushima RESTアクセス用のUIのフロントエンドの話？ JSのお話の？node.jsとかの話。 MVCにしたり、CSSフレームワーク使ったり。 backbone.jsつかってるらしい。 実際の画面がみたいなぁ。 現状の話なので、 ◯Meinheld　@mopemope Python3対応とかLoggerとかやってから秋くらいに出るみたい。 このあたりは未知の領域です。。。 ◯3分間で開発環境構築 @tk0miya Vagrant＋Chefみたい。 VeeWeeってのでIOSイメージからVMイメージを作ってくれる。 （githubから持ってこないといろいろ古いらしい） これ、重要だと思う。 実践するようにしよう。 手順書がわりにChefのレシピを書こうよと。 環境マニア募集中！ 継続的デリバリー座談会やってます ◯筋トレ講座　@hiroki_niinuma ジムに通い続けるのはキツイ。 成功率5% 以下の条件に ・10時間以下の仕事時間 ・ジムが近い ・ジムという環境が好き ベンチマークｗ先入観を捨てましょうとｗ ジムで筋トレとかよりも歩くのが全然いいよと。 togetterがあったのでリンク。 http://togetter.com/li/346242 http://togetter.com/li/346270\nスライドはこちら。\n** [Elasticsearch入門 pyfes 201207](http://www.slideshare.net/JunOhtani/elasticsearch-pyfes-201207) ** from **[Jun Ohtani](http://www.slideshare.net/JunOhtani)** それにしても発表するといういい機会を与えてもらえて良かったです！。 継続的にelasticsearchも調べていきたいので、興味ある人は声をかけてくださいー\n","date":1343466900,"dir":"post/2012/","id":"7fa2f0877831b4c924438396760f1841","lang":"ja","lastmod":1343466900,"permalink":"https://blog.johtani.info/blog/2012/07/28/python-developers-festa-2012-07%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%97%E3%82%83%E3%81%B9%E3%81%A3%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pyfes/","publishdate":"2012-07-28T18:15:00+09:00","summary":"ということで、ステッカー欲しさ？に勉強中の話を恥ずかしげもなく偉そうにしゃべってきました。 #pyfesは以前から、気になっていたんですが、タ","tags":["勉強会"],"title":"Python Developers Festa 2012.07に参加してしゃべってきました #pyfes(Jugemより移植)"},{"contents":"今日はSolr 4.0 ALPHAの興味深い機能があったので紹介です。 数日前に「Solr 4.0: Partial documents update」という記事を見つけました。\nSolrには、ドキュメント（RDBで言うレコード）のデータを更新したい場合には、特定のフィールドだけを更新するという機能がありませんでした。 ですので、特定の項目（例えば、priceなど）を更新したい場合、ドキュメントの全データをSolrに再度上書き登録するという処理をしなければなりませんでした。 RDBを触っていた方が、Solrを始めた場合に必ず使いづらいと思われる点だと思います。\nで、4.0でその機能がありますという、「Solr 4.0: Partial documents update」の記事を見つけました。 ただ、SolrのWikiや4.0 ALPHAの紹介のページには「partial update」という記述が見当たりません。 （あれ、これかな？Update semantics） あと、まだ完成していないので、載っていないのかもしれないです。（このチケットSOLR-139が部分更新に関するもののはず。チケット番号をみても古くから望まれている機能だということがわかります。）\nということで、調べてみました。\n###機能概要\nSolrの機能として、特定のフィールドのみを更新するという機能です。 あくまでも、Solrレベルでの機能となり、Luceneの機能を利用したものではありません。 つぎのような流れになっています。\nSolrに対して特定フィールドを更新したいという形のドキュメントを投げる Solrはドキュメントを受け取ると、内部のインデックスに保存してあるデータを取り出す 取り出したドキュメントオブジェクトに対して、更新対象フィールドの値だけデータを更新する ドキュメントオブジェクトをインデックスに保存する このような流れです。 まぁ、言われてみれば当たり前な処理です。 ただし、この機能を使う場合はいくつかの前提条件があります。\n###前提条件\n前提条件はつぎのとおりです。\nすべてのフィールドをstored=\u0026ldquo;true\u0026quot;にする 「version」という特殊なフィールドを用意する 1点目は、データの保存方法についてです。 先ほど流れに書きましたが、Solrが内部に保存してあるデータを取り出して、更新対象以外のデータを保存しなおしてくれます。 このため、stored=\u0026ldquo;true\u0026quot;にしておかないと、元のデータがSolr内部で取得できません。\n2点目の「version」というフィールドは4.0から導入されたフィールドです。 SolrCloudに必要な機能としてドキュメントのバージョン管理を行うために導入されたフィールドだと思います。（あまり詳しく調べていない。。。） SolrCloud内でレプリカの更新などに使ってるのかなぁと（そのうち調べます。） 以上の2点が前提条件です。すべてのデータをstored=\u0026ldquo;true\u0026quot;としなければならない点は、インデックスのサイズや性能に関わってくるので考えて利用するほうがいいかと思います。\n###利用方法\nSolrのサンプルデータ（exampledocs/mem.xml）を例として利用します。 部分更新を行うにはつぎのような形のデータを投げると部分更新が可能です。 （JSONでの更新のサンプルについては、こちらの記事を参考にしてください。） ####XMLのサンプル（partial_update.xmlというファイルで保存する）\n\u0026lt;add\u0026amp;gt; \u0026lt;doc\u0026amp;gt; \u0026lt;field name=\u0026#34;id\u0026#34;\u0026amp;gt;VS1GB400C3\u0026lt;/field\u0026amp;gt; \u0026lt;field name=\u0026#34;_version_\u0026#34;\u0026amp;gt;バージョン番号\u0026lt;/field\u0026amp;gt; \u0026lt;field name=\u0026#34;cat\u0026#34; update=\u0026#34;add\u0026#34;\u0026amp;gt;cats_and_dogs\u0026lt;/field\u0026amp;gt; \u0026lt;field name=\u0026#34;popularity\u0026#34; update=\u0026#34;inc\u0026#34;\u0026amp;gt;10\u0026lt;/field\u0026amp;gt; \u0026lt;!-- set empty for SOLR-3502 bug --\u0026amp;gt; \u0026lt;field name=\u0026#34;price_c\u0026#34; update=\u0026#34;set\u0026#34;\u0026amp;gt;0.0,USD\u0026lt;/field\u0026amp;gt; \u0026lt;/doc\u0026amp;gt; \u0026lt;/add\u0026amp;gt; 上記サンプルのうち、バージョン番号の部分は、現在Solrに登録してある値を指定します。（Solrの管理画面で検索すれば表示されます。） 上記ファイルを「SOLR_HOME/example/exampledocs」に保存し、同フォルダにてつぎのコマンドを実行すると、部分更新されるのがわかります。 Solrに更新であるというフィールドがわかるように、fieldタグにupdateという属性を指定してあります。\njava -Durl=http://localhost:8983/solr/update?versions=on -Dout=yes -jar post.jar partial_update.xml ちなみに、上記post.jarのオプションで、「-Durl」「-Dout」を追加してあります。 「-Durl」はverions=onというパラメータを追加したいためです。 「-Dout」はPOSTした結果をターミナルに表示するために追加しています。 これらのオプションを指定すると、データ更新後のバージョンが取得できるようになります。\n####更新に利用できるコマンド？ 部分更新にはつぎの3つのコマンド？（正式名は不明）が用意されています。fieldタグのupdate属性に指定します。\nコマンド？ 説明 add 値を追加します。multiValuedのフィールドでない場合はエラーが出ます。 set 値を新規に登録しなおします。現在入っているデータは無くなります inc 指定された数値を加算（数値形式のみ） 以上が、部分更新の機能になります。 ちなみに、登録されているバージョンと更新データに入っているバージョンが異なる場合はエラーが発生する仕組みになっているようです。 それとは別に、この機能を調べていて、copyFieldのバグにぶつかってしまいました。。。 multiValuedでない、copyFieldを利用しているしている場合には注意が必要です。\n###copyFieldのバグ（SOLR-3502）\n4.0-ALPHA（3.6.0でも再現しました。）のexampleのデータで部分更新の機能を確認できると言いました。 ただし、「price_c」というフィールドのせいで、2回部分更新を行うと2回目にエラーが発生します。 根本的な問題は、部分更新ではなくcopyFieldのバグのようです。（部分更新の処理にも問題は有るような気がしますが。。。）\nバグの内容はつぎのとおりです。\nmultiValued=\u0026ldquo;false\u0026quot;のフィールドをdestに指定 srcに指定されたフィールドに値を設定（exampleのpriceフィールドに「1」を指定） destに指定されたフィールドに値を設定（exampleのprice_cフィールドに「2,USD」を指定） 上記のように設定した場合、「price_c」フィールドに、指定された値＋「price」の値がcopyにより追加されます。 通常は「price_c」フィールドはmultiValued=\u0026ldquo;false\u0026quot;なのでエラーが出るはずなのですが、エラーが発生せず2つの値が登録されてしまいます。\nこのバグのため、exampleのデータを利用して部分更新を行うとつぎのような状態が発生します。 更新を行う対象のデータはprice、price_cフィールド以外のフィールドとします。\n1回目の登録後：priceフィールド「\u0026ldquo;185.0\u0026rdquo;」、price_cフィールド「\u0026ldquo;185.0,USD\u0026rdquo;」 2回目の登録後：priceフィールド「\u0026ldquo;185.0\u0026rdquo;」、price_cフィールド「[\u0026ldquo;185.0,USD\u0026rdquo;,\u0026ldquo;185.0,USD\u0026rdquo;]」 3回目の登録：エラーが発生 部分更新の処理で、すでに登録済みのデータをSolrが自動で取り出すため、2回目の登録処理にて「price_c」の登録済みの値がSolrから取り出され、さらにcopyField設定により、「price」の値が追加されます。 本当は2回目の登録でエラーが発生すべきなのですが、バグのためエラーが発生せずに登録できてしまいます。 部分更新の処理としては、copyフィールドのdestに指定されているフィールドの値を取り出さないほうがいいような気もしますが、きちんと考えてないのでなんとも言えないです。（制約事項とする形のほうがいいかもしれません）\n","date":1342177320,"dir":"post/2012/","id":"68a8f34c240a42ab521d2f885f7aa33c","lang":"ja","lastmod":1342177320,"permalink":"https://blog.johtani.info/blog/2012/07/13/partial-update%E3%81%A8copyfield%E3%81%AE%E3%83%90%E3%82%B0solr-4-0-alpha/","publishdate":"2012-07-13T20:02:00+09:00","summary":"今日はSolr 4.0 ALPHAの興味深い機能があったので紹介です。 数日前に「Solr 4.0: Partial documents update」という記事を見つけました。 Solrには、","tags":["solr"],"title":"Partial UpdateとcopyFieldのバグ【Solr 4.0 ALPHA】(Jugemより移植)"},{"contents":" Modern Information Retrieval: The Concepts and Technology behind Search (2nd Edition) (ACM Press Books) いやぁ、蒸し暑くてなかなか寝れない日がはじまりましたね。（あんまり関係ないですね。。。）\nModern Information Retrieval 2nd Editionを輪読会という形で読み始めました。 Solrに関わって数年ですが、昔から検索をやっていたわけではありません。 なので、そろそろ基礎的、理論的なところも勉強して行かないとなと思い、この本を買いました。 ただ、約1000ページある英語の本でして。。。 一人で読むと間違いなく挫折するし、理解不能になりそうだなと。。。\nということで、Twitterで呟いたら賛同してくれる方が現れ、輪読会を開催することにしました。 イベントの開催とか初めてなので、手さぐりしながらです。（それにしても、ほんと、Twitterは素晴らしい。賛同してもらえる人が見つかったのもTwitterのおかげだし。）\nさすがに細かく読んでいくと終わらなそうなので、１周目（できれば、２周目もやりたいなぁと思ってる。１週目が１年でも終わりそうにない感じだけど）は公開されているスライドを元に進めようと思ってます。 それにしても検索周りはいろんな技術が必要なのだなぁと分厚い書籍を見て、途方に暮れつつ、楽しみでもあるなと思いながら、輪読会後の飲みを楽しんでましたｗ\nということで、各分野の専門家もいそうなので、特別ゲストとして読んできて話に混ざってもらうのも面白いかもと夢想しつつブログを書いています。 だれかいないかなーｗ\n参考URL： 書籍のHPで公開されているスライドのページです。 http://grupoweb.upf.es/WRG/mir2ed/contents.php\n","date":1342111298,"dir":"post/2012/","id":"9ac7bb94e60dc30a023ce433de027364","lang":"ja","lastmod":1342111298,"permalink":"https://blog.johtani.info/blog/2012/07/13/mir%E8%BC%AA%E8%AA%AD%E4%BC%9A%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-07-13T01:41:38+09:00","summary":"Modern Information Retrieval: The Concepts and Technology behind Search (2nd Edition) (ACM Press Books) いやぁ、蒸し暑くてなかなか寝れない日がはじまりましたね。（あんまり関係ないですね。。。） Modern Information Retrieval 2nd Editionを","tags":["勉強会"],"title":"MIR輪読会始めました(Jugemより移植)"},{"contents":"Lucene/Solrの4.0.0-ALPHAが7/3にリリースされました。\nこれに伴い、lucene-goenの4xブランチのjarファイルも4.0-ALPHAのものに置き換え、現在のtrunkの修正もマージしました。 こちらにあります。チェックアウトしてビルドしてから利用してください。\n※さすがに、jarをダウンロードできるようにすべきかもなぁ。 あと、Maven登録も。。。\n","date":1341457909,"dir":"post/2012/","id":"dcc2e24df32287e89ee3b0f64d617f57","lang":"ja","lastmod":1341457909,"permalink":"https://blog.johtani.info/blog/2012/07/05/lucene-gosen%E3%81%AElucene-solr4-0-alpha%E5%AF%BE%E5%BF%9C/","publishdate":"2012-07-05T12:11:49+09:00","summary":"Lucene/Solrの4.0.0-ALPHAが7/3にリリースされました。 これに伴い、lucene-goenの4xブランチのjarファイル","tags":["lucene-gosen"],"title":"lucene-gosenのLucene/Solr4.0-ALPHA対応(Jugemより移植)"},{"contents":"またまた参加しました。いまだ皆勤賞です。 感想などはあとで。とりあえず、メモとったので第一弾です。\nということで、感想です。 まずは、参加人数。 今回は今までで一番、ATND登録した人が多かったんじゃないかなぁと。 埋まるのも早かったですし。やっとSolrというキーワードが多くの方に触れられるようになってきたんですかねぇ。\nmixiの事例はやはり、SSDを使った11億文書のインデックスが圧巻です。 実際にマイニングに利用していて、ネガポジ分析なども行われているようで楽しそう。 TLにもありましたが、「ヤバイ」はネガ？ポジ？など、そのへんの分析方法をもう少し詳しく聞いてみたい感じもしました。 あとは、Luceneソースコードリーディングの開催が楽しみです！（候補日知らせないと。。。）\nLucene Revolution 2012の参加レポートは、自己紹介がおもしろかったですｗ ずっと検索をやらてているのもあり、色々と理論ではなく、実践的なノウハウを持っていそうで、つぎはそのあたりの話を聞いてみるのも面白そうです（発表してくれないかなーｗ） 残念ながら、私はまだスライドを見ていないので、事例を中心にピックアップして見てみようかなぁと（時間がトレない。。。）\n最後は阿部さんの4.0の紹介です。タイムリーに、前日に4.0-ALPHAがリリースされたので、 資料がすごく参考になりそうです。 SolrCloudについても詳しく書かれてたし。（ちゃんと動くのかなぁ？）\n最後は懇親会です。最近知り合った方から、発表者、昔からの勉強会の参加者といろいろな方と今回も話ができて楽しかったです。 TL上で知り合った方にもお会いできたし。 次回もしゃべってもらえそうな人を捕まえつつあるので、また企画してもらうようにつついてみようかな。\n※そういえば、毎度のことながら4.0ベースで、書籍は出さないのかって言われましたｗ\n※ちなみに、4.0-ALPHAが出たので、lucene-gosenも4xブランチの更新作業をしています。 終わったらまたブログに書くと思います。\n第8回Solr勉強会 場所：VOYAGE GROUP 会議室 日時：7/4(水)　19:00 ～ 1. ＠haruyamaさん mixi での Solr の利用 ・mixiの全文検索 2011年以前：Hyper Etraier、Tokyo Dystopia、Senna 2011年以降：Solrを利用して新規案件の検索システムの構築、入れ替えを行なっている。 ・Anuenueの論理構成など。 ・物理構成 1マスター、2スレーブ インデックスが小さい、QPSが100以下 インデックスサイズが大きいものは今後構築予定 ・今後やりたいこと ・ログ分析 ・パーソナライズ ・外部ストレージ参照のカスタム関数 ・外部ストレージをファンクションカスタム関数クエリ FunctionQueryを活用したい。 ・上記のデモ（検討中のもの？） 現在はjar内部のファイルを読んでるよと。 速度的な面がどうなるかがきになるところ。 ・テキストマイニング mixiボイス haruyamaさん入社前：ダンプして解析してた haruyamaさん入社後：Solrに載せちゃえば 600GのSSD　約11億文書 約450GB 利用してるもの：Solr 4.0（2012/01） lucene-gosen 1.2.1 自作フィルタ haruyama/solr-filter - GitHub ・利用統計の説明。 女性が多い。 「AKB」だと20代前半が多い。男性はおっさんも頑張ってる。 ・mergeindex機能を利用して、過去データとマージしてる。 1日分だけ集計したいこともあるかもしれないから。 updateじゃなくて、mergeindexなのは、ソッチのほうが早かったから。 ・拡張してる分析 ・ポジネガ分析 形容詞＞絵文字＞顔文字でスコアが効く 機械学習して辞書を調整してる ・Luceneソースコードリーディングまたやりますよ！ 2. 楽天株式会社 大須賀 稔さん Lucene Revolution 2012 in Boston参加レポート(仮) ・まずは自己紹介。 infoseekに転職→楽天→Ask.com→楽天（そして英語） ・Lucene Revolutionってなに？ ・トレーニング Scaling Search with Big Data \u0026amp; Solr Hadoopの紹介 SolrとHadoopのMapReduceを利用したインデキシングのハンズオン Solrのスケーリング（Sharding、Replication）、マルチテナント ※http://www.lucidimagination.com/services/training/big-data-training-scaling-solr 日本ではやってない、残念。 ・カンファレンス スライドとかはlucidimaginationのサイトで見れるよと。 http://www.lucidimagination.com/devzone/events/conferences/lucene-revolution-2012 ・Lucidworks Big Dataの紹介 Hadoopとかいろいろ組み合わせて使えるよと ・Microsoftの人がAzureでSolrの紹介 IEとかWindows8の話ばっかり。 ・Kuromojiの紹介 やはり、マイノリティ。 内容は日本語勉強会ｗ 中国語とかは対応するの？日本語しか知らないです。。。 ・ErickさんのSolrCloudの話 4.0は2012年にリリースする予定 スコアリングをプラガブルに。 管理系画面がリッチだよと。 ・一番重要だなぁと思ったのは。。。 「英語」！（会社的な感想ではありません。。。） Q：これはみとけ的なスライドは？ A：Hadoop上でインデキシングして、ビットトレントとかで連携してるという例が面白かった。 Q：FASTとかと比べてSolrってどーなの？ A：ESPは洗練されてる。クローラーとか、ベイシスのトークナイザーを内包してるとか。 Solrは言語処理系が弱かったとかあるけど、そろってきてるのでは。 4.0は互角になるんじゃないかなぁ。 ESPがWindowsオンリーになるので、LinuxユーザがSolrに行きつつある。 3. 株式会社 ロンウイット　阿部さん Solr 4.0の紹介 ・Solr 4.0の主な機能の紹介 3.xは3.6が最後4.0-ALPHAが7/3に出た ・プラガブルなスコアリング BM25、Language Models、Divergence from Randomness、Information-based Models 関口さんがスライド作ってる ・FST対応 Finite State Automata/Transducer オートマトン理論を活用したもの。 TokenStreamはFSAで実装 SynonymFilterがFSTになると、オフセットが変わってくるらしいと。 ・Codecプラグイン Luceneレベルのお話。 ドキュメントをファイルに保存するときの形式をプラガブルに変更可能。 SimpleTextなどもあるらしい。テストに利用できそう。 APIレベルで、マイグレーションの必要があるかも。 ・NRT Near Real Time Search softCommitのお話 Realtime-get：IDを入れたらGETできるよと。 KVSとしても活用できるぞ～と。 ・PivotFacet Facetが階層的（？）な感じで取れる ・JOIN、pseudo-join ローカルパラメータでできるよーと。 ・SolrCloud インデックスの分散配置をやってくれる（3.6まではやってくれない） shardがダウンしたらフェイルオーバーしてくれそう Master/Slave環境 リアルタイムインデクシングとリアルタイム検索とか ・ZooKeeperIntegration実装 リーダー選出、コンフィグの管理などなど ・ManifoldCFの近況 5月にトップレベルに昇格！ http://manifoldcf.apache.org/ja_JP/index.html 0.6は7月に出そう。日本語にもなってる。すげー Alfresco Connector、ElasticSearch Connectorなども Solr Plugin for Enterprise Searchとか ","date":1341402000,"dir":"post/2012/","id":"8acc78be63e27e938ee53ec2c0b90c61","lang":"ja","lastmod":1341402000,"permalink":"https://blog.johtani.info/blog/2012/07/04/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--solrjp/","publishdate":"2012-07-04T20:40:00+09:00","summary":"またまた参加しました。いまだ皆勤賞です。 感想などはあとで。とりあえず、メモとったので第一弾です。 ということで、感想です。 まずは、参加人数。 今","tags":["勉強会"],"title":"Solr勉強会第8回に参加しました。 #SolrJP(Jugemより移植)"},{"contents":"Hadoopからはちょっと離れているのに、面白そうなネタなので参加しました。 Data Science Summit、HBaseCon、Hadoop Summitのイベント参加レポートです。\n最初の草薙さんの発表が実は一番興味を惹かれていたので、参加しました。 データの解析に関するサミットというのはなかなか聞いたことが無いのでどんな内容なのかなぁと。 ちょうどVisualizeなどに興味を持っていたり、データ解析、今後重要ですよねという話が出ていたりしていたので。 実際にデータ解析が今後重要で、どんなことに使えるのかなど、製品に偏らない内容のようで色々とためになりました。 この内容をずっと聞くのは私には無理ですw英語も数学もイマイチなので、ついていけない自信がありますｗ。 「データ分析の結果をビジネスに結び付けられる人とかが今後重要になります」という話が一番気になったキーワードでした。\nHBaseConもかなり濃い内容だったようです。 私は残念ながら、HBaseの概要の概要くらいしか知らないので、内容にはついていけてないですが。。。 Facebookがかなり活用しているようですが、残念ながらスライドが上がっていないようです。 Solrに関連する話もあったようです。HBaseとSolrを組み合わせたLilyプロジェクトに関連する話のようでした。 スライドは登録しないと見れないみたいです。\n最後はHadoop Summitの参加レポートです。 まずは、ユーザ寄りの内容を@muddydixonさんから。個人的に、Twitterの話が多いのかなぁと。 ここでも、Visualizeの話が出ていたとか。 Lucidの話もあったようです。LucidWorks BigDataの話かな？\n最後は@shiumachiさんのHadoopのプロダクト寄りのお話。 YARN（Map/Reduce2.0？）やHBaseの今後の展望など。YARNはキーワードだけ知っていたので、わかりやすい解説で、やっと理解できました。 全体を通して、HBaseが今後もっといろんな局面で使われそうだなぁと。日本語の本も7/24に出るし。（まだページが無いみたいなので、英語のほうを。）\nいつものごとく、途中でビールが入ったので後半はメモが適当ですが、楽しかったです。皆さんお疲れ様でした。\n帰り着いたら、さっそくスライドが上がってました。すごい！ スライドはこちら（2012/06/26 0時現在）\nData Science Summit / EMC Worldレポート HBaseCon 2012 参加レポート』の発表スライドをアップしました。（NTTデータ 猿田 @raspberry1123 ／岩崎） @muddydixonさんのHadoopSummit2012参加レポート @shiumachiさんのHadoopSummit2012参加レポート @muddydixonさんのブログ いろんなキーワード、特に、データサイエンス寄りの話が面白かったです。 次回はJenkins関連のようで、7/30開催みたいです。\n以下はいつものメモです。\n日　時： 2012年6月25日（月） 19:00～21:00 （受付開始 18:40） 場　所： 豊洲センタービルアネックス（NTTデータ、豊洲駅直通） ◯ Data Science Summit / EMC World レポート （EMC Japan 草薙） ・Data Science Summitのレポート 揃ってるようで揃ってないスロットの写真ｗ EMC World2012と併設 今回2回目。 ・OpeningKeynote: What We Can Predict About Prediction by Nate Silver 研究者は不確実性やリスクを包含した、現実的な予測モデルを開発すべき いろいろ ・Roundtable: Economic, Political, \u0026amp; Societal Roles of Social Data ユーザの「query-like intent」を自然言語解析と機械学習で捉える 属性だけじゃなく、活動を コンテンツからコンテキストへ、コンバージョンからカンバセーション ・Big Data Transformation - HealthMap ウィルスのアウトブレイクの検知（160日→20日）に。 ウィルス＝コンピュータじゃない方 ・Big Data Transformation - Intuit int.com？ データがあるから、こういうことが知りたいなどの新しいプロセスが 「https://www.mint.com/」 ・Big Data Transformation - InfoMotion Sports Technologies バスケのボールにセンサーつけて、試合や選手の解析に利用して、 チームが強くなったりしてるらしい。 ・Big Data Transformation - Decide.com アメリカ？の価格比較サイト ソーシャルデータを元に、買い時、売り時を予測して教えてくれる。 もうすぐ新しいモデル出るかもよ？などの噂を利用してる。 ・Analytics Maturity: Master or Novice? 2010年のアメリカの教育事情のレポート データサイエンス系の統計とかがもっと必要なんじゃないか。 ・Keynote: Navigating the Road from Business Intelligence to Data science Piyanka Jain BIの限界とか、データサイエンスの恩恵を受け入れるのに必要なもの？など システムじゃなくて、人やスキルに投資しましょう。 データ分析の結果をビジネスに結び付けられる人とか。 Panel: From Raw Data とValue Data プライバシー問題 データ品質の問題 異常値を除外するなと。最も興味深いデータになることもある。 \u0026#34;Data exhaust\u0026#34;の問題 個人が日々インターネット上で行う様々なインタラクションに関するデータの集合 相関と因果関係の区別が大変難しい。 Panel: Tapping Into the Pulse of the Data Science movement ストーリを持ってデータを語れるのが重要。 Keynote: Data Visualizeation at the Point of Influence by Adam Bly Closing Keynote: The Promise and Peril in the Human / Technology Relationship by Jonathan Harris TEDで有名な人 まとめ アメリカはこの分野での投資は回り始めている. http://www.greenplum.com/datasciencesummit/ ◯ HBaseCon レポート （NTTデータ 猿田／岩崎） ・GeneralSession HBaseの開発に参加してね。 ・レプリケーション、セキュリティ、セカンダリインデックス、スナップショット、バックアップなど特に貢献して欲しいと。 ・HBaseによりカバーできるアプリケーション領域 メッセージング、位置ベースアプリケーション、リアルタイムレコメンデーション、広告最適化 ・開発者への要望 メッセージをちゃんとして 解析用メトリクス 管理ツール ・M/Rジョブとの連携の改善 ・自動チューニングなど ・Applications ・GAPの事例 色々試してHBaseにした。 クラスタ構成、16Slave、3Master、NN Failover via NFS ※ZKはスレーブに置くと、アウト。 ・Tumblr 最初は失敗した。 OpenTSDBを経験して、Motherboy V1に。 テストフェーズまでが目的 →幾つかの知見が得られたよーと。 Motherboy V2を構築中。 ・Facebook ひと月250TBペースで増加中。。。 なんで、HBaseにしたの？ 低レイテンシ、水平スケール、一貫性重視の設計、M/Rとの親和性とか Schema V1＝Snapshot Schema Schema V2＝Split Snapshot Schema Schema V3＝Hybrid Schema HBaseのデータにさらにインデックス作ったりとか。 Schema Vertion Current＝Finer grained schema and Indexer 読み書きの単位を分析して、スキーマを分割して細かくして行っていた。 ・Operations ・HBaseで困ったよ at Facebook ・リージョンサーバに特定データ入れると連鎖的に死亡 ・サーバが死に切らないとか。 ・HBaseは落ちるときは落ちるので、しぶとく生き残れるアプリを作ってねと。 ※Facebook関連のスライドなどがあがってませんと。 ・HBaseバックアップについて Clouderaの人とFacebookの人 ・選択肢 DistCP /hbaseディレクトリまるごとコピー。一貫性が保証されない exportツール MRジョブ。1度に1つのテーブルのみ copytableツール データを別クラスタに保存 exportツールに似てる。 レプリケーション 。。。 アプリケーションから複数クラスタへの書き込み 。。。 ・ユースケース ・HBASE-5509を利用したバックアップ ・開発中バックアップ HBASE-6055スナップショット、HBASE-4618など ・Development ・HBase Schema Design　Salesforce.comの人 非正規化でやりなさいと。Joinはおすすめしないと 最後にデザインパターンが載ってると。 0.行キーの設計がすべて 1.Design for the questions, not the answers. 2.データサイズは2種類しかない。大きすぎるか、そうじゃないか。 3.コンパクトに詰め込め 4.行単位の原子性を活用する。 5.属性は行キー内に移動することができる。（Lars Georgeがfoldingと読んでいる手法） 6.エンティティをネストさせると、データを事前に集計できる。 ・HBase Performance Tuning And Organizations　Facebookの中の人 テーブルの事前スプリット オフピーク時間を設定する。（0.94で入った） コンパクション設定が効いてくるよ ・SolrのバックエンドにHBase？？？ ◯ Hadoop Summit レポート (@muddydixonさん) ・オープニングビデオは必見 ・ショーケース ・Datameerを注目した。Visualizationの専任チームがいる。 UIじゃなくて、解析部隊だけで60名 お値打価格。$2900/年 ・Azure Big Data JavaScriptで ・ショーケースLucid Solr、HBaseとかいろいろ組み合わせて。 ・Session Hadoop... 2015までにApache Hadoopに世界のデータの半分が乗るらしいと。 ・Session Realtime analytics with Storm and Hadoop フォロワのフォロワをunique処理したり。 ・Session Scalding Twitter\u0026#39;s new DSL for Hadoop ※Zipkinにも出てきたな、名前。 ・Hadoop Plugin for MongoDB ・Hadoop and Vertica The Data Analytics Platform at Twitter Twitter社でのHadoop周りのデータフローとか。 Verticaは速度がいるものの処理に利用 80-100TB/dayとか。。。 ・Keynotes ・Big data analyzing system is censor of company. ・It is difficult in blind and deaf. ・Session Large Scale Search, Discovery and Analytics with Hadoop, Mahout and Solr ※@muddydixonさんのブログにセッションに対応するスライドのリンクを公開中。http://d.hatena.ne.jp/muddydixon/20120617/1339919125 ◯Hadoop Summit レポート (@shiumachiさん) ・Hadoop1.x MapReduce 非常に安定 ・課題。。。 ・YARN（Yet Another Resource Negociator） ターゲット：6000～10000ノード 100,000以上のタスクの同時実行 10,000ジョブの同時実行 性能は倍以上 Q：これは同じプログラムを動かして？ A：。。。倍以上です！（わかんないっす。） 今後の予定 幾つかのJIRAの紹介 MAPREDUCE-4327とかHBASE-4329とか まとめ YARNは「汎用」分散処理基盤に向けて一歩踏み出したもの！ 更なる進化に注目と ・HBaseの可用性とリペア ダウンタイムを短くしよう。 障害停止7割くらい。 設定ミスが44% 不安定な機能は使うな、推奨構成を推奨！ HBase 0.92＋Hadoop 2.0 HDFS HAによる高可用性とか 将来：HBase 0.96＋Hadoop 2.x 計画停止時間削減：オンラインスキーマ変更（HBASE-1730） ローリングアップデート：バージョン間互換性が必須 HBase本読みなさい。 金があれば、サポート買ってください。 日本語HBaseトレーニング開催予定（来月） ・HBase NameNode HighAvailability ```　","date":1340642460,"dir":"post/2012/","id":"9f29c6d9719fc6bc09a2981057642b69","lang":"ja","lastmod":1340642460,"permalink":"https://blog.johtani.info/blog/2012/06/26/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC10%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/","publishdate":"2012-06-26T01:41:00+09:00","summary":"Hadoopからはちょっと離れているのに、面白そうなネタなので参加しました。 Data Science Summit、HBaseCon、Hadoop Summitのイ","tags":[],"title":"Hadoopソースコードリーディング第10回に参加しました。#hadoopreading(Jugemより移植)"},{"contents":"Issue 32で上がってきたlucee-gosenのUniDic対応の最初のパッチを書いたので、ブログに残しておきます。\n###UniDicとは___ UniDicとは、日本語テキストを単語に分割し，形態論情報を付与するための電子化辞書です。 UniDicの詳細や特長についてはHPを御覧ください。\n残念ながら、UniDicは利用者登録をして、利用規約に従うと利用が可能となります。 ですので、lucene-gosenでは、Ipadicやnaist-chasenの辞書とは異なり自動で辞書をダウンロードする機能はありません。\n###利用手順___ 以下が、Unidicの辞書を利用したjarファイルの作成方法となります。\n1. lucene-gosenをダウンロードし、パッチを当てる lucene-gosenのリポジトリからソースをエクスポートし、パッチをダウンロードし、パッチを適用します。 コマンドは以下のとおりです。\nsvn co . lucene-gosen-trunk-readonly cd lucene-gosen-trunk-readonly patch -p0 \u0026amp;gt; ...patch （パッチに関しては今後正式版をリリースされたら手順からは必要なくなります。）\n2. Unidic辞書生成のためのディレクトリを作成「$GOSEN_HOME/dictionary/unidic」\nmkdir dictionary/unidic 3. 対象となるUnidicの辞書のソースファイルをダウンロード 利用者登録をし、利用規約に同意の上、以下のファイルをダウンロードします。 「/」に添ってダウンロードページから遷移してダウンロードしてください。\n1.3.12個別ファイル/unidic-chasen/unidic-chasen1312src.tar.gz 4. ダウンロードしたtar.gzファイルを「dictionary/unidic/」にコピー\ncp .. lucene-gosen-trunk-readonly/dictionary/unidic/ 5. Antを実行してjarファイルの作成\nant -Ddictype=unidic 成功すれば、lucene-gosen-trunk-readonly/dist/lucene-gosen-2.1-dev-unidic.jarファイルが生成されます。 あとは、通常通り、SolrやLuceneで利用することが可能です。\n以上がjarファイルの作成手順となります。\n###制約事項（2012/06/18現在）___ 現在（2012/06/18）時点で公開しているパッチは、以下の制約が存在します。\nCOMPOUNDエントリー未対応 品詞情報（発音）の内容の制限 COMPOUNDエントリー未対応 Unidicの辞書のエントリーの中に1件だけ、COMPOUNDと呼ばれるエントリーが1件だけ存在します。 別々の単語を組み合わせて1単語として扱うことができるようになっているようです。 lucene-gosenでは、残念ながら、このような辞書の形式には対応していません。 1件しか存在しないデータでもあることを鑑みて、今回の辞書構築処理では、スキップするようにしました。\n品詞情報（発音）の内容の制限 lucene-gosenの実装上、単語の読みのバリエーション数と発音のバリエーション数には以下の制限が存在します。\n「読み」バリエーション数 ＜ 「発音」バリエーション数 「読み」に対応する形で、「発音」がlucene-gosenでは品詞情報としてデータ登録されています。 UniDicのデータには上記制約を満たさないデータが5件ほど存在します。 現在、これら5件のデータについて、「読み」に対応した「発音」データには空文字が表示されるようになっています。\nまだ、簡単に動作確認をしただけです。UniDicを利用していて問題など有りましたら連絡、Issueへのアップをしていただけると助かります。\n","date":1340028180,"dir":"post/2012/","id":"d13aa56e27fe71ef40ff153c093ecdf8","lang":"ja","lastmod":1340028180,"permalink":"https://blog.johtani.info/blog/2012/06/18/lucene-gosen%E3%81%AEunidic%E5%AF%BE%E5%BF%9C/","publishdate":"2012-06-18T23:03:00+09:00","summary":"Issue 32で上がってきたlucee-gosenのUniDic対応の最初のパッチを書いたので、ブログに残しておきます。 ###UniDicとは___","tags":["lucene-gosen"],"title":"lucene-gosenのUniDic対応(Jugemより移植)"},{"contents":"「鉄は熱いうちに打て」ということで、残りも勢いでメモ。 まだ、見直しとかしてない状態なのでおかしいところとかありますが。。。 図とか入れるのはまた今度。\nTransport（転送）\nZipkinとHadoopに異なるサービスからのトレースを送信するのにScribeを利用します。 ScribeはFacebookにより開発されました。 システムの各サーバで実行できるデーモンとして作成されています。 ログメッセージをListenし、カテゴリごとのcorrectレシーバーに配送します。 Zipkin collector daemon\nトレースデータがZipkinコレクターデーモンに配送されたらvalidかどうかをチェックしてから保管し、インデックスを作成します。 Storage\nストレージにはCassandraを選びました。 スケーラブルで、柔軟なスキーマをもっており、Twitter内部で大変使われています。 このコンポーネントをプラガブルにしようと試みましたが、困難なため、ここでは公開しません。 Zipkin query daemon\n保存、インデックスされたデータを探す方法が必要です。 クエリーデーモンはユーザに対して簡単なThriftAPIを公開しており、トレースを探すことが可能です。Thrift fileを見て下さい。\nUI\n多くのユーザはUI経由でデータにアクセスします。 VisualizeにD3を利用したRailsアプリケーションです。 UIの認証は実装していないことに注意してください。\nモジュール Zipkin内部のモジュール関連図\n##インストール___ Cassandra\nZipkinはCassandraをストレージにしています。Cassandraクラスタが必要になります。 1. Cassandraサイトを参考にしてクラスタを構築してください。 2. Zipkin Cassandraスキーマを利用します。つぎのコマンドでスキーマが作成できます。 bin/cassandra-cli -host localhost -port 9160 -f zipkin-server/src/schema/cassandra-schema.txt Zookeeper\nZipkinは協調のためにZooKeeperを利用します。 これは、保存すべきサーバをサンプルレートで決定し、サーバを登録します。？ 1. ZooKeeperのサイトを参考にインストールしてください。 Scribe\nScribeはトレースデータを配送するのに利用するロギングフレームワークです。 ネットワーク保存先としてZipkinコレクターデーモンを指定する必要があります。 Scribeの設定は次のようにします。 \u0026lt;store\u0026amp;gt; category=zipkin type=network remote_host=zk://zookeeper-hostname:2181/scribe/zipkin remote_port=9410 use_conn_pool=yes default_max_msg_before_reconnect=50000 allowable_delta_before_reconnect=12500 must_succeed=no \u0026lt;/store\u0026amp;gt; 注意：上記設定は、カテゴリーにより送信ホストを見つけるためにZooKeeperを利用するサポートのScribeのTwitterバージョンを使用する方法です。 コレクターのためのDNSエントリーを利用したりもできます。 Zipkinサーバ ZipkinサーバはScala 2.9.1、SBT 0.11.2そしてJDK6で開発しました。\n1. git clone https://github.com/twitter/zipkin.git 2. cd zipkin 3. cp zipkin-scribe/config/collector-dev.scala zipkin-scribe/config/collector-prod.scala 4. cp zipkin-server/config/query-dev.scala zipkin-server/config/query-prod.scala 5. Modify the configs above as needed. Pay particular attention to ZooKeeper and Cassandra server entries. 6. bin/sbt update package-dist (This downloads SBT 0.11.2 if it doesn\u0026#39;t already exist) 7. scp dist/zipkin*.zip [server] 8. ssh [server] 9. unzip zipkin*.zip 10. mkdir -p /var/log/zipkin 11. zipkin-scribe/scripts/collector.sh -f zipkin-scribe/config/collector-prod.scala 12. zipkin-server/scripts/query.sh -f zipkin-server/config/query-prod.scala SBTでコレクターとクエリサービスを起動します。 Scribeコレクターサービスの起動方法は次の通り。 bin/sbt \u0026#39;project zipkin-scribe\u0026#39; \u0026#39;run -f zipkin-scribe/config/collector-dev.scala\u0026#39; クエリサービスは次の通り bin/sbt \u0026#39;project zipkin-server\u0026#39; \u0026#39;run -f zipkin-server/config/query-dev.scala\u0026#39; Zipkin UI\nUIはRails3アプリです。 1. 設定をZooKeeperサーバでアップデートします。これはクエリデーモンを見つけるのに利用します。 2. Rails3アプリケーションサーバにデプロイします。テストの場合は次のようにすることもできます。 bundle install \u0026amp;amp;\u0026amp;amp; bundle exec rails server. zipkin-tracer gem\nzipkin-tracer gemをトレースしたいRailsアプリケーションにRack Handlerで追加します。 config.ruにつぎの記載をします。 use ZipkinTracer::RackHandler run \u0026lt;YOUR_APPLICATION\u0026gt; もし、アプリケーションのstatic assetsがRailsで提供されれば、リクエストがトレースされます。 ##　Running a Hadoop job\nScribeからHadoopにログを保存する設定をすることも可能です。 これをすると、Zipkin自身でオンザフライで簡単に作れないデータから様々なレポートが作成可能です。 ScalaでHadoopのジョブをかけるScaldingというライブラリを利用します。\n``` 1. Hadoopジョブを実行するためのfatなjarを作成します。 2. scald.rbをjarをコピーしたいホスト名とjobを実行するホスト名に書き換えます。 3. 必要なら、scald.rbのjarファイルのバージョンを更新します。 4. scald.rbスクリプトを利用してジョブを実行できます。\n./scald.rb \u0026ndash;hdfs com.twitter.zipkin.hadoop.[classname] \u0026ndash;date yyyy-mm-ddThh:mm yyyy-mm-ddThh:mm \u0026ndash;output [dir]\n##計測ライブラリの利用方法\u0026lt;hr\u0026gt; 計測のためのライブラリとプロトコルがちょっとだけあります。 しかし、もっと計測するための役に立つものを望んでいます。 開始する前にトレースデータがどんな構造なのかを知る必要があります。\n・Annotation - 値、タイムスタンプ、ホストを含みます。 ・Span - 特定のRPCに相当するAnnotationの集合 ・Trace - あるルートSpanにぶら下がるSpanの集合\nZipkinに送信するトレースデータです。\nこれらの詳細な記述は[こちら](https://github.com/twitter/zipkin/blob/master/zipkin-thrift/src/main/thrift/zipkinCore.thrift)を見て下さい。 その他にトレースデータの重要なものは、トレースされたサービス間でやり取りされる情報である、軽量なヘッダーです。 トレースヘッダは次のものから構成されます。\n・Trace Id - トレース全体のID ・Span Id - 個々のリクエストのID ・Optional Parent Span Id - このリクエストが他のリクエストの一部として生成されたら付与される ・Sampled boolean - トレースすべきかどうかを表すフラグ\nデータタイプについて、理解したので、どのように計測が行われるかを順をおってみてみましょう 例はFinagleのHTTPがどのようにトレースされるかを示しています。 他のライブラリやプロトコルはもちろん、異なりますが、基本的な部分は一緒です。\n\u0026lt;b\u0026gt;　サーバサイド\u0026lt;/b\u0026gt; 1. 到達したリクエストのトレースヘッダー存在するかどうかを調べます。存在すれば、なら、このリクエストに対して関連するIDとします。トレースヘッダーがなければ、サンプリング対象かどうかを決めて、新しいTrace Id、Span Idを生成します。参考には[HttpSererTracingFilter](https://github.com/twitter/finagle/blob/master/finagle-http/src/main/scala/com/twitter/finagle/http/Codec.scala)を見て下さい。 2. もし、現在のリクエストがサンプリングされる場合、サービス名、ホスト名、スパン名（例えば、http get/put）、その他のAnnotationのような情報を集めます。 リクエスト受信時には「server received」というAnnotationを生成し、処理が終了して結果を返すときに「server send」というAnnotationを生成します。 参考には[HttpServerTracingFilter](https://github.com/twitter/finagle/blob/master/finagle-http/src/main/scala/com/twitter/finagle/http/Codec.scala)を見てください。 3. 生成されたトレースデータはServerBuilderにより設定されたトレーサーに渡されます。 デバッグのためのConsoleTracerが例としてありますが、ZipkinTracerになります。 トレースデータを[ZipkinTracer](https://github.com/twitter/finagle/tree/master/finagle-zipkin)が受け取った時、Span Idにより集約されます。 4. ZipkinTracerが\u0026#34;end of span\u0026#34;イベント（\u0026#34;server received\u0026#34;アノテーションやタイムアウトのような）を受け取ると、Thrift構造としてデータを集約してScribeに送ります。もし、そのようなイベントが発生しない場合、ZipkinTracerはいつかそのデータを送信します？？？おかしい？。データ送信のための他の方法も追加します。 ThriftやScribeのようなものですが、JSONやHttpかもしれません？ \u0026lt;b\u0026gt;　クライアントサイド\u0026lt;/b\u0026gt; 1. リクエストを送る前にそれがトレースの一部かどうかをチェックします。 サーバで利用されているとします。　サーバは、リクエストを処理してすでに付与されているトレースIDを割り当てます。 トレースIDを再利用しますが、この新しいリクエストには新しいスパンIDを生成します。 また、親のスパンIDが存在すれば、前のスパンIDに設定します。 [ここ(TracingFilter)](https://github.com/twitter/finagle/blob/master/finagle-core/src/main/scala/com/twitter/finagle/tracing/TracingFilter.scala)や[ここ(Trace)](https://github.com/twitter/finagle/blob/master/finagle-core/src/main/scala/com/twitter/finagle/tracing/Trace.scala)が参考になります。 2. サーバサイドと同様に、送信されるHttpリクエストにトレースヘッダーを追加するための[HttpClientTracingFilter](https://github.com/twitter/finagle/blob/master/finagle-http/src/main/scala/com/twitter/finagle/http/Codec.scala)があります。 3. リクエスト送信前の「client send」やサーバからの返信を受信した「client receive」のようなアノテーションを生成します。 4. サーバサイドと同様に、データがZipkinにデータを送るZipkinTracerに到達します。 ","date":1339772520,"dir":"post/2012/","id":"9ccda414c322ebcdf875eacbba2e4b7e","lang":"ja","lastmod":1339772520,"permalink":"https://blog.johtani.info/blog/2012/06/16/zipkin%E3%81%AEreadme%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%81%9D%E3%81%AE%EF%BC%92%E6%AE%8B%E3%82%8A/","publishdate":"2012-06-16T00:02:00+09:00","summary":"「鉄は熱いうちに打て」ということで、残りも勢いでメモ。 まだ、見直しとかしてない状態なのでおかしいところとかありますが。。。 図とか入れるのはま","tags":["Zipkin"],"title":"ZipkinのReadme読んでる（その２、残り）(Jugemより移植)"},{"contents":"ZipkinのGithubにあるReadmeを読んでます。 せっかくというか、頭が悪いので読みながら内容をメモ。 まずは、アーキテクチャとトレースデータ送信のためのクライアント側あたりです。 （誤訳とかおかしいだろというツッコミ大歓迎です。） あとで、リンク貼ったり絵を入れたりするかもしれませんが、とりあえず。\n◯アーキテクチャ（図はこちら）\n・対象とするサービスからScribeでデータを収集し、ZipkinのCollectorに投げる ・CollectorはCassandraにデータを格納 ・WebUIからはQueryでCassandraに問い合わせを行なってデータ取得 ・Scripe、CollectorはZookeeperと連携している（妄想） ◯計測用ライブラリ（図はこちら。図のSと書かれた青い箱）\n・各ホストの計測用ライブラリがトレースデータを集めてZipkinに送信する。 ・ホストは他のサービスへリクエストを飛ばすときに、リクエストにトレース用のIDを付与してます こうすることで、データをあとで、束ねることが可能となります。 ◯計測ライブラリの利用方法 ・Finagle\nJVMのための非同期ネットワークスタックである。 それは、JVMベース言語（JavaやScalaなど）で非同期RPCのクライアント・サーバを構築するのに利用できる。 FinagleはTwitterの内部ですごく利用されていて、トレースサポートを実現するのに当然のポイントです。 現時点で（Finagleは）ThriftやHTTP、Memcache、Redisのクライアント・サーバサポートも持っています。 ScalaでFinagleサーバをセットアップするのはつぎのようなコードになります。 トレースを追加するには、finagle-zipkinを追加して、ServerBuilderのtraceFactory関数を呼ぶだけです。\nServerBuilder() .codec(ThriftServerFramedCodec()) .bindTo(serverAddr) .name(\u0026#34;servicename\u0026#34;) .tracerFactory(ZipkinTracer()) .build(new SomeService.FinagledService(queryService, new TBinaryProtocol.Factory())) クライアント側も同様です。 上記のようにサンプリングしたリクエストにZipkinトレーサーを指定することで 自動的にトレースできるようになります。 サービスやホストでのリクエストの開始と終了を記録できます。 さらに付加的な情報を記録したい場合は、つぎのようなコードを追加します。 Trace.record(\u0026#34;starting that extremely expensive computation\u0026#34;) 上記コードは、上記コードが実行された時間に文字列を付加できます。 キーバリュー情報を付加したい場合は次のようになります。 Trace.recordBinary(\u0026#34;http.response.code\u0026#34;, \u0026#34;500\u0026#34;) Ruby Thrift\nリクエストのトレースに利用できるgemもあります。 リクエストに対してトレースIDを生成し、リクエストに付与し、トレーサーにプッシュするのにRackHandlerのgemを利用できます。 トレーサをトレースするサンプルはzipkin-webを参照。\nRubyからトレースクライアントをコールするのに、Twitter Ruby Thrift clientを使います。 つぎのようなコードを書きます。\nclient = ThriftClient.new(SomeService::Client, \u0026#39;127.0.0.1:1234\u0026#39;) client_id = FinagleThrift::ClientId.new(:name =\u0026gt; \u0026#34;service_example.sample_environment\u0026#34;) FinagleThrift.enable_tracing!(client, client_id), \u0026#34;service_name\u0026#34;) Querulous\nQuerulousはScala用のSQLデータベースのインタフェースライブラリです。 SQLクエリの実行のタイミング情報をトレースに追加できます。 Cassie\nCassieはFinagleベースのCassandraクライアントライブラリです。 CassieのトレーサーはFinagleの例とほぼ一緒ですが、 CassieではKeyspaceBuilderに設定します。 cluster.keyspace(keyspace).tracerFactory(ZipkinTracer()) とりあえず、ここまで。___ 2012/06/22 リンクを貼って体裁を修正\n","date":1339721820,"dir":"post/2012/","id":"69f755dd5b9e90a99c3086543790541c","lang":"ja","lastmod":1339721820,"permalink":"https://blog.johtani.info/blog/2012/06/15/zipkin%E3%81%AEreadme%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E5%91%A8%E3%82%8A%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-06-15T09:57:00+09:00","summary":"ZipkinのGithubにあるReadmeを読んでます。 せっかくというか、頭が悪いので読みながら内容をメモ。 まずは、アーキテクチャとトレー","tags":["Zipkin"],"title":"ZipkinのReadmeを読んでる（クライアント周りについて）(Jugemより移植)"},{"contents":"久々にSolrの話です。 といっても、結構前からの話でして。。。\nschema.xmlのfieldTypeの設定に「autoGeneratePhraseQueries」という属性があります。 Solr3.1で導入されました。動作に関しては関口さんのブログで説明されています。 Solr 1.4までは、Analyzerがトークンを複数返してくる場合（例：lucene-gosenで「Solr入門」という文字列を入れた場合など）にフレーズクエリとして処理していました。 Lucene 3.1.0から、この処理がデフォルトfalse（つまり、フレーズクエリにならない）という挙動になりました。（詳しくは関口さんのブログで。） ただ、Solr 3.1.0では、下位互換性を考慮して、autoGeneratePhraseQueriesの設定値はデフォルトが「true」でした。\nこのデフォルト値がSolr 3.3以降で提供されているschemaのバージョン（1.4以上）からデフォルト値が「false」に変更されています。 schemaのバージョンを1.3以前のものから1.4以上に移行する場合は注意が必要です。\nとまぁ、偉そうに書きましたが、私もちゃんと追えてませんでした。 Solr勉強会第６回で、関口さんの発表できちんと説明されていて、参加してたのに聞けてなかったですし。（メモ取ってるのに、書いてない。）\nということで、Solr入門のサンプルschemaも少し修正しました。 こちらとこちらの記事に追記してありますので、参考にしてください。\n","date":1339603740,"dir":"post/2012/","id":"277f7f2177e2a265a62680ea0158f9b9","lang":"ja","lastmod":1339603740,"permalink":"https://blog.johtani.info/blog/2012/06/14/autogeneratephrasequeries%E3%81%AE%E3%83%87%E3%83%95%E3%82%A9%E3%83%AB%E3%83%88%E5%80%A4%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-06-14T01:09:00+09:00","summary":"久々にSolrの話です。 といっても、結構前からの話でして。。。 schema.xmlのfieldTypeの設定に「autoGeneratePh","tags":["solr"],"title":"autoGeneratePhraseQueriesのデフォルト値について(Jugemより移植)"},{"contents":"すでに読まれた方もいるかも知れませんが、気になったのでメモを書いてみようかと。\n先週の木曜日にTwitterのエンジニアブログでZipkinというOSSを公開したという記事がでました。 非常に興味深いシステムだったので、ちょっとずつ読み解いていきたいなという宣言（というか、ハッパをかけてもらうため）も兼ねて、まずはブログの内容をメモ程度に残しておきます。\nZipkinは分散トレースシステム（distributed tracing system）です。Twitter APIの１リクエストを構成する様々なサービスのタイミングデータ（計時データ）を集めるために作りました。 Firebugのような性能プロファイラのよなもので、しかもバックエンドのサービスもプロファイル可能です。 ZipkinはAPLv2ライセンスでOSSとしてGithubで公開しています。\nZipkinはWebのユーザインタフェースを持っています。（元記事参照） 各サービス（縦軸）でどのくらい時間がかかっているか（横軸）がわかり、クリックすることでより詳細な情報が得られます。 Zipkinはパフォーマンス改善の余地のある部分（遅いMySQLのSELECTなど）を見つけるのに役立ちます。\nZipkinはどのように動くの？ Twitterに届いたリクエストからサンプリングしたリクエストに対してトレース可能なIDを付与して、すべてのサービスに渡していきます。 全リクエストの一部をサンプリングすることで、トレースのオーバヘッドを減らし、常に本番環境で利用できるようにしています。 Zipkinコレクタ（collector）が、Scribe経由でタイミングデータを受け取り、Cassandraに保存してインデックスを作成します。 Zipkinクエリデーモンがインデックスを利用して、WebUIにトレースデータを見つけます。\nZipkinはHack Weekで開始されました。 最初はThriftに対するGoogle Dapperの論文の基本的な部分の実装から始まり、現在ではHttp、Thrift、Memcache、SQL、Redisリクエストをサポートしています。 これらはFinagleライブラリで経由で動作します。Rubyのgemも用意してあります。\nということで、ほぼ直訳ですが、何かの役に立てればと。 ちょっとずつですが、Githubのページやソースを読みながら記事を書いていこうと思っています。\n","date":1339515600,"dir":"post/2012/","id":"ee48516e57684c5a4c22adccac34be92","lang":"ja","lastmod":1339515600,"permalink":"https://blog.johtani.info/blog/2012/06/13/twitter%E3%81%8C%E5%85%AC%E9%96%8B%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%B3%E3%82%B0%E8%BF%BD%E8%B7%A1%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0zipkin/","publishdate":"2012-06-13T00:40:00+09:00","summary":"すでに読まれた方もいるかも知れませんが、気になったのでメモを書いてみようかと。 先週の木曜日にTwitterのエンジニアブログでZipkinと","tags":["OSS"],"title":"Twitterが公開した分散トレーシング（追跡？）システム、Zipkin(Jugemより移植)"},{"contents":"lucene-gosenの最新版（2.0.1）をリリースしました。\nプロジェクトページよりダウンロードが可能です。\n今回の修正では、@haruyama さんからいただいていたパッチの取り込み（リソース周りの改善など）が主な対応となっています。 また、コンパイルに利用するjarファイルがLucene/Solr3.6.0に変更になっています。（Issueはこちら） 3.6.0から追加されたテストケースにて、発生する問題への対処も施したものとなっています。\n","date":1339059234,"dir":"post/2012/","id":"216db319052b5742fc68862cb2f39905","lang":"ja","lastmod":1339059234,"permalink":"https://blog.johtani.info/blog/2012/06/07/lucene-gosen-2-0-2%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E5%91%A8%E3%82%8A%E3%81%AE%E6%94%B9%E5%96%84%E3%81%AA%E3%81%A9/","publishdate":"2012-06-07T17:53:54+09:00","summary":"lucene-gosenの最新版（2.0.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、@haruy","tags":["lucene-gosen"],"title":"lucene-gosen 2.0.2リリース（リソース周りの改善など）(Jugemより移植)"},{"contents":"昨晩に引き続き、情けない内容のブログになってしまいますが。。。\n昨晩、書いた記事の調査をしていた時に気づいた、問題になるケースがあったので調査をしていました。 Issue32に登録した内容になります。 拙い英語を振り絞って書いた英語なので、伝わらないかもしれないのでブログに残しておきます。 昨晩の問題点となったクラス（StreamTagger2.java）の内部処理についてです。 lucene-gosenのLucene向けのTokenizerの内部処理では入力文字列の処理を行うのに、「char buffer[]」を用いて 入力文字列をReaderから読み込むときにバッファリングしています。 このバッファリングにて、特定のケースにて、想定していない場所を単語の切れ目と認識してしまう問題が実装上存在しました。 Issue32に記載した内容は次のようになります。\n上記バッファは4096文字というサイズで固定になっています。 StreamTagger2クラスでは、この4096文字をオーバーするような文字列の場合に、つぎの処理により、4096文字以下の場所に文章の区切りを探そうとします。\n4096文字以上の文字列が入力される バッファに入れられるだけの文字（4096文字）をバッファにコピーする。 バッファの後ろから、つぎの5種類の文字を探索し、見つかった場合（場所をkとし、ｋ＞０の場合）は、その場所を文章の切れ目と判定して、0からk+1文字目までの文字をStringTaggerを利用して形態素解析する。 あとは、繰り返し 上記条件に合致しない場合は、4096文字を文章とみなして形態素解析を行います。 ここで、5種類の文字は以下のとおり。\n0x000D:CARRIAGE RETURN(CR) 0x000A:LINE FEED(LF) 0x0085:NEXT LINE (NEL) 0x2028:LINE SEPARATOR 0x2029:PARAGRAPH SEPARATOR 見ての通り、制御文字ばかりです。 この5文字以外は切れ目と判断してくれません。 ということで、4097文字の文字列が存在し、上記5種類の文字が一度も出てこない場合、バッファのサイズで文字列が途切れてしまい、想定しない区切り位置で区切られた文章に対して形態素解析が実行されてしまいます. HTMLから文字列を抜き出して解析したり、長い文書を解析する場合に、改行文字を削除して処理するといったことも考えられます。 上記5種類の文字列のみで文章の区切り位置を判断してしまうのは問題ではないかと。 まずは、4096文字内に「。」句点が存在した場合に、その部分を区切り位置として認識するようなパッチを記載して、Issue32に添付しました。\n「。」句点を採用した理由はつぎのとおりです。 StreamTagger2では、上記バッファリングした文字列を更に、BreakIterator.getSentenceIterator(Locale.JAPANESE)にて取得したBreakIteratorにて文節単位に区切ってから、各文節ごとに形態素解析を実施しています。 ということは、BraekIteratorにて分節の区切りとして判断される文字については、上記の文字種に追加しても問題無いという判断からです。 ただし、この修正でも、純粋に4096文字以上、句点が出てこない場合には区切り位置がおかしなことになってしまいますが。。。 もう少し、BreakIteratorの挙動を調べて、他にも利用可能な区切り文字が存在しないかを調査していく予定です。。。\n1年以上コミッターをやっているのに、こんなことも理解していないのかよいうツッコミを受けてしまいそうでなんとも情けない話です。。。 まずは、現状報告でした。\n","date":1338913260,"dir":"post/2012/","id":"cbf9587a8187985725963b8bfc67004d","lang":"ja","lastmod":1338913260,"permalink":"https://blog.johtani.info/blog/2012/06/06/issue32%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A64096%E3%81%AE%E5%A3%81/","publishdate":"2012-06-06T01:21:00+09:00","summary":"昨晩に引き続き、情けない内容のブログになってしまいますが。。。 昨晩、書いた記事の調査をしていた時に気づいた、問題になるケースがあったので調査","tags":["lucene-gosen"],"title":"Issue32について（4096の壁）(Jugemより移植)"},{"contents":"久々にlucene-gosenを触っています。 trunkのlibにある、jarファイルが3.5ベースだったので、3.6ベースにしてテストをしたところ、 いくつかある、ランダムテストで結果の不整合が検出されたので、調査していました。 先程、trunkに対応版をコミットしました。もう少しテストケースを追加してからリリースします。 おそらく、通常の使い方では問題無いと思います。\nLuceneでは、ランダムな文字列を利用したテストが実装されています。 lucene-gosenでもこのテストを利用してランダムなテストをしています。 実際にはtest/以下のorg.apache.luceneパッケージにテストケースがあります。 今回、jarファイルを差し替えた時に、このランダムなテスト実施にて、assertが失敗するケースが発生しました。\n原因究明までに、いくつかフェーズがあったので、忘れないように書いておきます。\n1.ランダムテストのテストケースにてエラーがassertが失敗するケースが発生 ※ただし、成功する場合もあり。 2.該当のテストを再現しつつデバッグ＋該当のテストがどんなものかを解読（勉強不足。。。） ※テストは、失敗した場合につぎのようなメッセージが表示され、同じテストが再現可能です。 以下、エラーの出力例。「NOTE: reproduce with: 」のあとにあるantコマンドを実行すれば、同じテストが再現可能です。\n[junit] ------------- Standard Error ----------------- [junit] TEST FAIL: useCharFilter=false text=\u0026#39;wgxznwk\u0026#39; [junit] [junit] ===\u0026gt; [junit] Uncaught exception by thread: Thread[Thread-3,5,main] [junit] org.junit.ComparisonFailure: term 0 expected:\u0026lt;w[gxznwk]\u0026gt; but was:\u0026lt;w[]\u0026gt; [junit] at org.junit.Assert.assertEquals(Assert.java:125) [junit] at org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:146) [junit] at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:565) [junit] at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:396) [junit] at org.apache.lucene.analysis.BaseTokenStreamTestCase.access$000(BaseTokenStreamTestCase.java:51) [junit] at org.apache.lucene.analysis.BaseTokenStreamTestCase$AnalysisThread.run(BaseTokenStreamTestCase.java:337) [junit] \u0026lt;=== [junit] [junit] NOTE: reproduce with: ant test -Dtestcase=TestGosenAnalyzer -Dtestmethod=testReliability -Dtests.seed=4ad9618caecb9fb2:d5476c03b8172df:-9c569f70013ffbb -Dargs=\u0026#34;-Dfile.encoding=SJIS\u0026#34; [junit] ------------- ---------------- --------------- [junit] Testcase: testReliability(org.apache.lucene.analysis.gosen.TestGosenAnalyzer):\tCaused an ERROR 3.デバッグの結果、Luceneのtest-frameworkにある「MockReaderWrapper」というクラスの影響を確認 LuceneのJIRAのLUCENE-3894にて追加されたクラスであるとわかる。 このクラス、Readerのreadメソッド内部で、ランダムな値を元に長さを途中で返すという実装のReaderになっている。 （全部で18文字の文字列なのだが、ランダムな値を元に、12文字として結果を一旦返すという仕組みが実装されている） 4.lucene-gosenの問題箇所を特定。 Readerが途切れた部分を分節として扱ってしまう実装になっていた。 該当の部分に修正をいれてコミット。 という具合です。 一応、テストを数回走らせてランダムテストが問題なく終了するのを確認はしてあります。 今回の問題に対する、個別のテストケースを追加してから近日中リリースする予定です。 対応が遅くなって申し訳ないです。。。\n","date":1338827340,"dir":"post/2012/","id":"0dcb6d0f17794bbca56b6cdb9e20b932","lang":"ja","lastmod":1338827340,"permalink":"https://blog.johtani.info/blog/2012/06/05/trunk%E3%81%AE%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E5%B7%AE%E3%81%97%E6%9B%BF%E3%81%88lucene-solr3-6-0%E3%81%A8%E3%83%A9%E3%83%B3%E3%83%80%E3%83%A0%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E5%A4%B1%E6%95%97%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-06-05T01:29:00+09:00","summary":"久々にlucene-gosenを触っています。 trunkのlibにある、jarファイルが3.5ベースだったので、3.6ベースにしてテストをし","tags":["lucene-gosen"],"title":"trunkのライブラリ差し替え（Lucene/Solr3.6.0）とランダムテストの失敗について(Jugemより移植)"},{"contents":"録画してたEテレのスーパープレゼンテーションを見ててふと書きたくなったので、書いてます。 あとから読んだら恥ずかしくなりそうだけど。。。 「\u0026ldquo;知力の余剰\u0026quot;が世界を変える」というClay Shirkyさんの話を見て思ったことです。 社会的に貢献できる仕組みが最近増えているという話の内容でした。そこで、OSSについても同じことが言えるよなぁと思った次第でして。\n昔からいろんなかたが言ってると思うし、今さら何をとおもわれるかもしれないですが、なんとなく書きたくなってしまったので。\n私はシステム開発を生業にしています。特にOSSにはお世話になっています。 実際に、OSSを利用している方はかなりいると思います。 幸いにも、私はOSSのコミッターもやっています。 OSSに色々と関わってきて常々思っていることがありまして。\nOSSは基本は有志の方々が開発やメンテナンスを行なっています。（最近では会社で行なっているところもありますが。） そんなOSSに貢献する方法はいくつかあるのかなぁと。\nバグを発見したら報告したり、こんな機能を作ってみたけどどうですか？とパッチを送ってみたりするのは素晴らしい貢献だと思います。 ただ、なかなかアクションを起こすのって勇気がいるかなぁと。 実際、私もパッチ書いたりバグ報告するのは気後れすることがありしました。 ただ、貢献する方法ってこれだけじゃないよなぁと、コミッターをやり始めて思いました。\nもちろん、バグ報告してもらえるともっとありがたいですし、新機能とかリクエストを送ってもらえるともっと嬉しいです。 MLに質問するのもありです。ただ、ちょっとハードルが高いと思うこともあります。\nそんな時は、ただ使っているよと、ツイートしたりブログを書いてくれるだけでもありがたいし、ヤル気が出るものです。 使い勝手が悪いなぁというツイートでも、なんでこんなに使いにくいんだというブログでもいいんです。 気になるなぁという形でもいいと思っています。 githubでフォローするだけでもいいかと。 反応があれば、使ったり触ってもらえていることがわかります。 なので、使っているよとかアピールしてもらえると嬉しいよなぁと。\nなんか、締りのない感じになっちゃいましたが、反応があるとうれしいので、お気楽に反応しましょうよというお話です。\n","date":1338394320,"dir":"post/2012/","id":"ffdbd6a7d28c9a63976e9eec38cab0f5","lang":"ja","lastmod":1338394320,"permalink":"https://blog.johtani.info/blog/2012/05/31/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%B8%E3%81%AE%E8%B2%A2%E7%8C%AE%E3%81%AE%E3%82%B9%E3%82%B9%E3%83%A1/","publishdate":"2012-05-31T01:12:00+09:00","summary":"録画してたEテレのスーパープレゼンテーションを見ててふと書きたくなったので、書いてます。 あとから読んだら恥ずかしくなりそうだけど。。。 「\u0026l","tags":["misc"],"title":"オープンソースへの貢献のススメ(Jugemより移植)"},{"contents":"JJUG CCC 2012 Springに参加してきました。 昨年のFallに続き、2回目です。 概要や、タイムテーブルはこちらを御覧ください。 今回は、午後一から参加しました。 色々と迷いましたが、つぎのを聞いて来ました。\nHotSpot vs JRockit ～ HotRockit到来の前に予習しよう！ Play! Framework - モダンで高速なWeb開発 Grails/Groovyの開発活用術 Scala 最新状況報告 From Swing to JavaFX SwingからJavaFXへのマイグレーションガイド JRockitは使ったことがなく（たぶん）、新鮮でした。いろいろなコマンドが用意されているなぁと。 あと、jvisualvmの使い方も知らないこともあったのでいい話が聞けました。 プレゼンに慣れているようで、プレゼン中に、コマンドラインの拡大＋コマンドのオプションに赤い下線を入れるなど、どうやってやっているのか、プレゼンの内容よりも気になってしまったのが本音です\nPlayは今回の目玉の一つでした。まだ、手元でPlayを触り始めたばかりだったので、概観がつかめたのが良かったです。 あとでスライドを見なおさないと。 頭がどうしてもServlet、JSPのため、未だにPlayに切り替えができてないので、もっと触ってみないとなぁと。 ちなみに、紆余曲折してまして、Play 1.2.4→Play 2.0（Javaアプリ）→Play 2.0（Scalaアプリ）と心変わりしまくりで、まだ完全に作ってないのに、ふらふらしてます。。。\nGrailsはGrailsを現場にどのように投入していくのがいいかという、技術よりは、政治的な話でしたが面白かったです。 実際に、あまり有名でないプロダクトを現場に導入するのに、Javaだからと無理やり説得してみたりｗ、開発コストがこれくらい下がりますという話をしてみたりと、いろいろやられているようでした。 あと、PlayのあとにGrailsということもあり、すこしPlayを意識した話もされていました。\nScalaはScalaDaysの話＋Scalaの最近の動向ということで、ある程度Scalaを知っている人がターゲットのようでした。 少し触っただけなので、何となく分かる部分もありましたが、最後の方はついていけてないです、すみません。。。 一番感じたのは、発表者の水島さんのScalaに対する愛情でしょうか。\n最後は桜庭さんのJavaFXのお話です。 一応、昔、JFreeChart＋Swingでちょっとしたものを作ったことがあるので面白かったです。 プレゼン自体もJavaFXで作成されていたり、オープニングがStarWars風だったりと凝ったプレゼンでした。 JavaFXとしては、JavaOneでも聞いたのですが、グラフやHTMLがリッチに書けるようになったことがびっくりです。\n実際のSwingアプリからJavaFXへの移行に関して、注意する点などがわかりやすく聞けました。 FXMLは確かに便利ですよねぇ。レイアウトをJavaで組むのがすごくめんどくさかったもんなぁ。\nさて、簡単ですが、感想でした。 今回一番残念だったのは、長丁場の割に電源の確保が難しかったことでしょうか。 ツイートしたり、メモ取ったりしたかったのですが、電源が乏しいので、Wi-fiオフにしてメモ取るのが限度でした。。。\n場所：オリンピック記念青少年総合センター 日時：2012/05/28 10:00 - 19:00 ◎13:10 - 14:00 C-1 HotSpot vs JRockit ～ HotRockit到来の前に予習しよう！ 谷本 心 @cero_t ◯HotSpot from Sun ◯JRockit from BEA 今は、どちらもOracle ◯違いは？ 1.歴史 2.プラットフォーム JRockitはMacではNG。Solarisは一部。 2.1Oracleさん曰く Solaris/Mac → HotSpot Windows/Linuxのサーバ → JRockit Windows/Linuxのクライアント → HotSpot 2.2谷本さんは？ WebLogic → JRockit 1.4、5の時の開発環境はJRockit 当時はJRockitの解析ツールがカッコ良かった 3.解析ツール 3.1コマンドラインツール プロセス HotSpot ： jps JRockit ： jrcmd スレッドダンプ HotSpot ：jstack JRockit ： jjrcmd \u0026lt;pid\u0026gt; print_threads ヒープ解析 HotSpot：jmap -histo \u0026lt;pid\u0026gt; JRocket：jrcmd \u0026lt;pid\u0026gt; heap_diagnostics HotSpot： JRockit：jrcmd \u0026lt;pid\u0026gt; 他にもJRockitは色いろある。 print_utf8poolとか（内部の文字列が出てくる） 3.2GUIツール HotSpot：jvisualvm　NetBeansベース JRockit：Mission Control　Eclipseベース メモリリークの解消をツールを使ってみてみましょうデモ。 ・hprofファイルを吐き出して、jvisualvmで読みこむのが楽な方法 ・jrmcはヒープダンプファイルを読み込む機能がない。 memleakというツールがある。アプリを起動してから、プロセスを右クリックして選択可能。 タイプグラフや割当てトレースみたいなものが使えるよ。 フライトレコーダーというのもあるよ。 4.HotRockitの紹介 まだいつ出るのかなぁという状態だけど、HotSpotにJRockitのツールも使えるようになるVMが出る模様。（2013？） ※デモ中に画面拡大した時に、赤線でラインを引いているのがすごく気になった。（便利なツールなのかな？そこだけ？） ◎14:15 - 15:05 C-2 Play! Framework - モダンで高速なWeb開発 池田尚史 @ikeike443 ◯自己紹介 Play!Frameworkコミッター 日本Playframeworkユーザ会 ◯アンケート メイン言語は？Java多数 触ったことある？半分くらい？ Play1？Play2？半々くらい プロダクションで使ってる人？3人 ◯Playframeworkって？ JEEではないよ。 Webだよ。 ServletとかXML使ってないよ。 ◯JEEは難しいよね。RailsとかDjangoから流れてくると。 ◯Webフレームワーク なので、Webアプリが作れればいいよね。 開発すべきものに注力して、抽象化とかを頑張らないようにと。 ◯ライブコーディング！ Play2.0のScalaアプリみたい。 プロジェクト作成～編集して起動まで。 エラーを起こして、エラーがどのように表示されるか。 エラーのリンクをクリックして、エディタを起動するということも可能みたい。 TODOとかで、まだ終わってないのも記述可能。 パラメータとControllerの関数の引数が勝手にひもづけられますよと。 ◯歴史 Servletとかもあった。 1.2からNetty、Websocket、Scalaサポート 2.0.1：Scalaで書き直し。Netty+Akkaで非同期 ◯１と２のちがいは？ ・Play1 Javaで書かれたJavaのフレームワーク。Scalaはプラグインサポート ・Play2 Scalaで書かれたScala/Javaのフレームワーク ◯Playの特徴 ステートレスとかノンブロッキングとかリアクティブとか ・高生産性 XMLがないし、unzipするとすぐ使えるよ。 ホットスワップできるよ。 CoffeeScript、LESSサポートも。assetsに入れとくとコンパイルしてくれて静的コンテンツにしてくれる。（Railsにも似たようなのあったっけか？） ・ステートレス HttpSessionがない→必要ならMemcachedとかで管理してね。 「デプロイ→ニーズ・状況に応じて即時スケールアウトという時代じゃないか？」という主張 Playはステートレス養成ギブスであり、時代の要請にマッチ ・広範囲な型安全 コンパイルしてエラー検知 ・ノンブロッキングI/O 非同期処理が手軽に書けるように考えられている。 →リアルタイムWebの時代 NettyやAkkaにより実現されてるのがいい Akkaを使ったアプリを書くと、長い処理のActorを別サーバにするなども設定で変更が可能。 ◯テスタビリティ BDDフレームワーク（Specs2？） Viewもテストできるぞと。 ◯事例 Klout：ソーシャルスコアリング イギリスのガーディアン：コンテンツAPIの実装がPlay2 MinecraftのWebサイト ◎15:20 - 16:10 C-3 Grails/Groovyの開発活用術 ～Java EE資産を活かして開発を加速する～(仮) 上原潤二 山本剛 ◯充電中のためお休み ◎16:25 - 17:15 C-4 Scala 最新状況報告 ～或いはScala Days 2012リポート～ 水島宏太 ◯自己紹介 言語を作るのが夢みたい。 ◯Scala最新状況報告 ScalaDaysの雰囲気を伝えるよと。（どっちかというと、旅行記かも） ◯Scala？ ・オブジェクト指向関数型言語 ハイブリッドじゃなくて、統合したもの ・強力な静的型付け NullPointerExceptionなども起きにくい ・超強力なコレクションフレームワーク ・Javaと同等の実行速度 ・コードが簡潔（1/4くらい） ◯Scala採用企業 Twitter、Amazon.com（どこに使ってるかは不明）、Foursquare、LinkedIn、VMWare、Klout、Tumblrなど ◯Scalaのバージョンは？ 2.10が開発版。2.9.2がステーブル版。 ◯開発体制 Typesafe＋世界のContributor Typesafeメンバの議決でいろいろ決定 githubでオープンに開発 ◯ScalaDays2012の目玉 豪華ゲスト（私は、わからなかった） Scala2.10の新機能紹介 今後のScala、多数の応用例 ◯ScalaDays2012を見ての方向性 ・All-in-oneパッケージの提供 Typesafe Stackの提供 重要なツール sbt（Simple Build Tool） gitter8（プロジェクトテンプレート生成ツール。githubを元に色々取ってくる？） Akka Play 2.0 Framework ・学習コストの削減 言語機能のモジュール化 高度な開発者が使う昨日はデフォルトOff ・バイナリ互換性問題への対処 ・Minor Release間での互換性を維持 MIMAでジドウテキに非互換性を検出 ・Major Release間では互換性は保証しない。 No more java.util.Date ソース互換性は「概ね」保証される deprecatedは次期メジャーバージョン時に削除される。 ・Scala IDEへの注力 インクリメンタルにコンパイルしてくれるから、遅いのも気にならなくなるかも。 デバッガとか、できるよと。 ・さらなるパフォーマンス改善 Value classes AnyValを継承したクラスが作成可能 該クラスのオブジェクトがインライン化 Pimp my libraryによるヒープ使用料が0に！ ◯2.10最新機能紹介 \u0026#34;1+2=#{1+2}\u0026#34;ができない s\u0026#34;1+2=${1+2}\u0026#34;ができるように String = 1 + 2 = 3 f\u0026#34;1=${1}%03d\u0026#34;もできるようにSring = 1 = 001 自分でStringコンテキストにメソッド追加できるらしい（聞き取った日本語が合ってるか？） とか。（かなり不安。。。まだまだわかってない。。。） ◎17:30 - 18:30 BOF-B-1 From Swing to JavaFX SwingからJavaFXへのマイグレーションガイド 櫻庭 祐一 ◯JavaFX 次世代のJava GUI Library Swing+Java2D+α JavaSE8から標準（JavaFX3.0） ◯サンプル クラス名がいろいろ変わってる。 ◯はまりそうなところ コンテナへの追加がちょっと違う イベントリスナは1種類のみになった。（Genericsを使うようになったよと。） ◯Bind 値が変わるとModelが勝手に検知して変わるみたい。 双方向もあり。これだとEventを書かなくても良くなりつつ有るよと。 ◯シナリオベースでマイグレーション考えましょう 1.JavaFX in Swing JavaFXにSwingを埋め込むことはできないぞと。 SwingでできないことをJavaFXでやりますよと。 おー、グラフが動く。JavaDocのHTMLも綺麗に出てる。 使い方：JFXPanelを使う シーングラフを記述可能 データのやり取りが大変。Threadが違うから。 パフォーマンスが落ちます。Java2Dで画像を書くので遅いですよと。 新規のものはJavaFXで書きましょうと。 2.Swing to JavaFX w/o FXML SwingをJavaFXに置き換える。 使い方が違うものはTableViewなど、◯Viewとついてるもの。 ちょっと考えるのはLayout Swing：コンテナ＋レイアウトマネージャー JavaFX：コンテナがレイアウトを含む BorderPaneクラスとか。 問題はTableとか Swing：TableModel JavaFX：BeanをColumnにバインド 3.Swing to JavaFX w/ FXML ・FXML GUIの構造をXMLで表す。 シーングラフを表現。 スキーマレス クラス：要素 プロパティ：属性 or 要素 アノテーションバリバリです。これで、FXMLとJavaのバインディングができるよと。 ツール Java ：NetBeans e(fx)clipseってのがあるかも。 FXML：Scene Builder ","date":1338259500,"dir":"post/2012/","id":"de734259dfb9addebe2b226d96b4f744","lang":"ja","lastmod":1338259500,"permalink":"https://blog.johtani.info/blog/2012/05/29/jjug-ccc-2012-spring%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-05-29T11:45:00+09:00","summary":"JJUG CCC 2012 Springに参加してきました。 昨年のFallに続き、2回目です。 概要や、タイムテーブルはこちらを御覧ください。 今回は、午後一から参加","tags":["勉強会"],"title":"JJUG CCC 2012 Springに参加してきました。(Jugemより移植)"},{"contents":"PlayFramework2.0を触ってみてます。 ちょっとコーディングしたくなったのと、最近のアプリの作成の調査も兼ねて。 まぁ、せっかくなので、Solr検索のアプリでも作ってみようかと言うことで触ってます。 ただ、Solr検索アプリでしかなく、今のところDBを使わないので、実はPlay Frameworkじゃなくてもいいのではないかという疑問も。。。\nまだ、触り始めたばかりなので、なんともですが。感想を。 たぶん、Ruby on Railsに似ているのかなと。 RoRは仕事で少し関わったので、なんとなく知っていますが、アプリの作成手順や、ディレクトリ構成などが似ている気がします。\nコントローラーの生成のタイミングとか、内部でオブジェクトをSingletonで保持する方法とかのイメージがまだ良くつかめていない状態で、まずは、Solr検索部分（Palyにあんまり関係ないところ）を実装しているところです。\n現状で一番の疑問点は、Eclipseプロジェクト化した時の参照ライブラリのパスに関するところでしょうか。 Play Frameworkは「play new ほげほげ」コマンドを実行するとアプリのディレクトリ構成が作成されます。 このあとに、eclipsfyというplayのコマンドを実行すると、Ecilpseのプロジェクトファイルが作成されます。 この時、PlayFrameworkが利用するjarファイルたちが参照ライブラリとしてクラスパスに設定されます。\nこのパスには、PlayFrameworkのインストールディレクトリが含まれた絶対パスが記述されるのですが、 複数人で開発するときにはどうしているのかなぁと。 あと、BitbucketやGitHubにアップするときもどうするのかなぁと。 以前、この疑問ツイートして、頂いた回答としては、環境変数として定義して、各自で設定してもらうというものでした。 私も同じ事を考えていたので、腑に落ちたのですが、他にもっといい方法があったりするんでしょうか？ クラスパスやEclipseプロジェクトのファイルをアップしないというのもあると思いますが、それもちょっとなぁと。 なにか、オススメとかあれば、教えていただけると嬉しいです。\n最近、ブログ更新してなかったのもあったので、まずは、導入編でした。\n","date":1337151314,"dir":"post/2012/","id":"78f002cc3d512ea302c900d1da4dfeec","lang":"ja","lastmod":1337151314,"permalink":"https://blog.johtani.info/blog/2012/05/16/playframework-2-0-java%E3%81%AE%E6%96%B9-%E3%82%92%E8%A7%A6%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%A6%E3%82%8B/","publishdate":"2012-05-16T15:55:14+09:00","summary":"PlayFramework2.0を触ってみてます。 ちょっとコーディングしたくなったのと、最近のアプリの作成の調査も兼ねて。 まぁ、せっかくなの","tags":["備忘録"],"title":"PlayFramework 2.0(Javaの方)を触ってみてる(Jugemより移植)"},{"contents":"lucene-gosenの最新版（2.0.1）をリリースしました。\nプロジェクトページよりダウンロードが可能です。\n今回の修正では、Java7でUnicodeのバージョン変更に伴う対応（詳細はこちらを参照）を行なっています。\nリソース周りの対応はまた後日。。。すみません。2012/05/16 遅くなりましたが、昨晩、JavaDocをアップしました。\n","date":1336494900,"dir":"post/2012/","id":"c4b418764dca70aebfc965899a3fa7e5","lang":"ja","lastmod":1336494900,"permalink":"https://blog.johtani.info/blog/2012/05/09/lucene-gosen-2-0-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9java7%E5%AF%BE%E5%BF%9C/","publishdate":"2012-05-09T01:35:00+09:00","summary":"lucene-gosenの最新版（2.0.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、Java7で","tags":["lucene-gosen"],"title":"lucene-gosen 2.0.1リリース（Java7対応）(Jugemより移植)"},{"contents":" IDの秘密 (丸善ライブラリー―情報研シリーズ) 非常に面白く読めました。 バーコードの話に始まり、最後はシステムで付与するIDに関する考慮点まで幅広くIDについて語られています。\n適度に配置されたコラムがまた面白く、ここまで書いてもいいのかな？と思いながらも楽しく読ませて頂きました。 2次元バーコードが汚れに強いのも知らなかったし、チロルチョコの話は知らなかったし、指コレクションとか面白すぎです。 また、JRのSuicaの導入に7年もかけている点などは、やはりすごい技術なのだなぁというため息混じりの感想です。 それほど長い期間のテストや設計は想像がつかないです。\n最後の2章（７，８章）については、エンジニアの以外のシステムに関わる方やエンジニアになられたばかりの方たちにぜひ読んで欲しいと思いました。 もちろん、エンジニアの方にも読んでほしい内容です。\nいくつか疑問点や気になる点もあったので。\n「静脈や指紋が人によって異なるって確率はどうやって決めたんだろう？」 Twitterの説明文のあとにFBの画面の図番号が書いてある。 日本語がデコードされたけど、QRコードの文字コードって、この中に含まれてるのかな？それとも規格で決まってるのかな？ 最後に、書影がNIIに合ったので撮影しました。写真へのリンクです。\n","date":1335794635,"dir":"post/2012/","id":"95c0a5b8a66950b5f22dd82a8dfe0ce5","lang":"ja","lastmod":1335794635,"permalink":"https://blog.johtani.info/blog/2012/04/30/id%E3%81%AE%E7%A7%98%E5%AF%86%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-04-30T23:03:55+09:00","summary":"IDの秘密 (丸善ライブラリー―情報研シリーズ) 非常に面白く読めました。 バーコードの話に始まり、最後はシステムで付与するIDに関する考慮点まで","tags":["読書"],"title":"「IDの秘密」を読みました。(Jugemより移植)"},{"contents":"WebSolrの話があるらしいというのを嗅ぎつけて、初めてHeroku JP Meetupに参加しました。 herokuもWebSolrも知りつつ、手を出していなかったので、いい機会でした。 （SignUpだけ、勉強会直前に済ませましたｗ）\nHerokuはAWS上に構築されたアプリケーションプラットフォームで、簡単にアプリをデプロイして動作させることができるようです。 Ruby on Railsを使うのが多いみたいですが、他の言語も利用できると。 で、herokuの面白いところは、アドオンとして、開発が簡単にできるようなしくみが用意されていることみたいです。 今回発表のあった、IronMQ、WebSolr、PaperTrailもアドオンとして用意されており、簡単に利用することが可能です。 IronMQはメッセージキューとして利用できます。\nWebsolrはSolrを簡単に利用できる形で提供しているものになります。 今、利用できるのは3.5.0のようで、最新版（3.6.0）になるのはまだ未定のようです。 今回の発表はWebSolrの話しもありましたが、基本は全文検索の仕組みとKuromojiの説明でした。 ただ、残念ながら、Kuromojiは3.6.0からの提供となるので、現時点では利用できないようです。 あとで、聞いた話だと、schema.xmlを自分で変更できるようです。 ただ、jarファイルを置いたりはできないようなので、lucene-gosenを利用するとかはできないみたいですが。。。 ほかにも、bonsai.ioとして、ElasticSearchの提供も行うようです。 まだ、利用はできないようですが。\n最後がPapertrailです。 こちらは、ログを保存して、検索、グラフ化（視覚化）してくれるアドオンです。 まだ、ベータのようですが、ログを保存してくれるようです。無料版もあるようです。 アドオンとしての機能もそうですが、利用しているグラフ化のツールなど、面白そうなものが利用されていました。\nLTはRuby使いの方が多かったです。\nRuby使いではないのですが、いろいろなアドオンが用意されており、サービスを簡単に提供することができそうだという印象をうけ、ちょっと使ってみたいなぁと思いました。 普段参加していない勉強会だったので、普段では知りえない興味ある話が聞けて面白かったです。\n余談ですがPapertrailの人が利用していた、slideshareのようなサービスのSpeaker Deckもよさそうなので登録してみました。 次に何か発表があった時には資料はこっちにアップしてみようかなぁと\n以下は、いつものように自分用のメモです。\n日時2012/04/20 19:00 to 21:00 会場：パソナグループ本部　呉服橋 ◎オープニング – Ayumu AIZAWA (Heroku Evangelist） ◎新入社員からの挨拶 – Koichi SASADA (Ruby Developer） 前職：大学教員 仕事：CRuby開発 Heroku使った事無いですｗRailsもよく知らないですｗ RUby2.0のリリースがゴール。2013/Feb 性能アップのことやってます。 ◎IronMQ – Chad Arimura (Iron.IO)\n「メッセージキューは涼しいです。」 （Google翻訳による日本語訳付きのスライド） Aggregation、Distribution。。。 IronMQ Elastic、RESTful heroku addon ironmq:rust 簡単にheroku上にキューが用意できるアドオンです。 Q：メッセージがキューに到達したのを確認する方法か？ A：ステータスコードが帰ってくる。 Q：データのサイズのリミットは？ A：postのリミットはある。S3とかに巨大データをおいて、ポインタを渡すとかしてほしい。 Q：キューへの到達の成功の保証は？ A：アプリケーション側で判断してください？ ◎Search \u0026amp; Indexing on Heroku – Nick Zadrozny (Websolr) スライドはこちら。\n※ツイートしてて、メモとってなかったので、ツイートをコピペ。 次はWebsolrのお話 Bonsai.io？ Bonsai by onemorecloud - http://bit.ly/JjCuaE SQLのLIKE検索はO(n)でおそいねぇと。 クエリのパースについての話。 今度は転置インデックスのお話。 Termへの分割ってどーすんの？というお話。Tokenizeのお話。 その１：N-GramというTokenizeの方法。N文字ずつ先頭からTermを切り出す。開始位置は1文字ずつずらしていくと。 N-Gramはノイズがのるし、多くのTermがでてきちゃうよと。 その２：そこで、次は形態素解析ですね。 先週、Lucene/Solr 3.6.0がリリースされて、Kuromojiという日本語向けの形態素解析器がでましたよ。 Kuromojiはこちら。（Lucene版とは少し違うけど。）http://atilika.org/ Kuromojiのサーチモードのお話。 通常は、「関西国際空港」という単語になってしまうのを、Kuromojiでは「関西」「国際」　「空港」という切り方の単語も出してくれると。 ちなみに、lucene-gosenでは、サーチモードはないんですねぇ。。。 「の」はどこに消えたんだ？？そこの説明は？ ElasticSearchやSolrのコアの部分でLuceneを使ってるよ。 ElasticSearch　http://bit.ly/qjjvWp Kuromojiはユーザ辞書をサポートしてるよ。 Q：まだ、3.5.0では？ A：もうすぐやります ◎log analysis for your Heroku app – Eric Lindvall (Papertrail)\nheroku上にログを貯めて、検索したりグラフ化したりできるようになりそうなもの。 [スライドはこちら](http://speakerdeck.com/u/lindvall/p/log-analysis-for-your-heroku-app) ログを貯めて、検索や可視化できるようにするサービスみたいです。 まだ、アイデアレベルのものも発表資料には含まれていました。 内部で利用しているツールなど、資料の最後に出てきますが、色々と面白そうなものがありました。 ◎Lightning Talks ◯Receibo ( @shu_0115 ) デザイナーｘエンジニアハッカソンでの成果らしい。 Webベースの家計簿アプリ。 買ったものの名称と料金を入れるだけ。 ◯Heroku + Pusherで作る！リアルタイムアプリケーション ( @satococoa ) WebSocketみたいなことが、Pusherでできるらしい。 http://www.slideshare.net/satococoa/heroku-pusher　◯Herokuアドオンを作ってみてわかったこと ( @takkam ) ◯heroku client のちょっと進んだ使い方 ( @hsbt ) ◯love heroku? – we love herokuのご紹介 ( @ppworks ） ","date":1334935380,"dir":"post/2012/","id":"c92c12a28fa219ad1aab60865046ff05","lang":"ja","lastmod":1334935380,"permalink":"https://blog.johtani.info/blog/2012/04/21/heroku-jp-meetup-4%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/","publishdate":"2012-04-21T00:23:00+09:00","summary":"WebSolrの話があるらしいというのを嗅ぎつけて、初めてHeroku JP Meetupに参加しました。 herokuもWebSolrも知りつつ、","tags":["勉強会"],"title":"Heroku JP Meetup ＃4に参加しました。#herokujp(Jugemより移植)"},{"contents":"先日、Solr入門のサンプルschema.xmlの3.6.0対応版の作成をしていて、気になったことがあったので、 メモとして残しておきます。\nSynonymFilterFactoryの属性「tokenizerFactory」に関連する話です。 （「Apache Solr入門」の36-37ページに記載があります。）\nSynonymFilterFactoryでは、類義語設定ファイルを読み込む際に利用するTokenizerFactoryを「tokenizerFactory」という属性で指定できます。（以下は書籍の記述を抜粋）\n\u0026lt;filter class=\u0026#34;sold.SynonymFilterFactory\u0026#34; synonyms=\u0026#34;synonyms.txt\u0026#34; ... tokenizerFactory=\u0026#34;solrbook.analysis.SenTokenizerFactory\u0026#34;/\u0026gt; このように、TokenizerFactoryが指定できます。\nただ、こちらの記事で書いたように、 Solr 3.6.0のexampleのschema.xmlではCJKのフィールドは次のように設定されています。\n\u0026lt;!-- CJK bigram (see text_ja for a Japanese configuration using morphological analysis) --\u0026gt; \u0026lt;fieldType name=\u0026#34;text_cjk\u0026#34; class=\u0026#34;solr.TextField\u0026#34; positionIncrementGap=\u0026#34;100\u0026#34;\u0026gt; \u0026lt;analyzer\u0026gt; \u0026lt;tokenizer class=\u0026#34;solr.StandardTokenizerFactory\u0026#34;/\u0026gt; \u0026lt;!-- normalize width before bigram, as e.g. half-width dakuten combine --\u0026gt; \u0026lt;filter class=\u0026#34;solr.CJKWidthFilterFactory\u0026#34;/\u0026gt; \u0026lt;!-- for any non-CJK --\u0026gt; \u0026lt;filter class=\u0026#34;solr.LowerCaseFilterFactory\u0026#34;/\u0026gt; \u0026lt;filter class=\u0026#34;solr.CJKBigramFilterFactory\u0026#34;/\u0026gt; \u0026lt;/analyzer\u0026gt; \u0026lt;/fieldType\u0026gt; 3.6.0以前は、solr.CJKTokenizerFactoryを利用していましたが、3.6.0からはCJKTokenizerFactoryがdeprecatedになってしまい、代わりにStandardTokenizerFactory＋CJKBigramFilterFactoryの組み合わせになっています。 exampleのCJKのフィールドタイプ設定を利用して、かつ、そのフィールドにSynonymFilterを利用する場合に、 StandardTokenizerFactoryを指定してしまうと、類義語が展開できなくなってしまうので注意が必要です。\nCJKのフィールドでSynonymFilterを利用する場合は、類義語の設定ファイル内の記述を自力でCJKTokenizerが分割する形で記述する（まぁ、やらないでしょうが）か、deprecatedですが、CJKTokenizerFactoryを利用するのが現時点での対応でしょうか。\nなお、これに絡んで、このようなチケットもできています。\nSyntaxHighlighterを導入してみました。 ちょっとはみやすくなってますかね？ まだ、SyntaxHighlighterの設定を調べながら使っているので、コロコロ変わるかもしれないですが、気にしないでください。 ","date":1334592971,"dir":"post/2012/","id":"12d1e0cf7396dd33a9bbbca8da4cbc68","lang":"ja","lastmod":1334592971,"permalink":"https://blog.johtani.info/blog/2012/04/17/solr-3-6-0%E3%81%AEcjk%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%81%A8synonymfilterfactory%E3%81%AE%E6%B0%97%E3%81%AB%E3%81%AA%E3%82%8B%E7%82%B9/","publishdate":"2012-04-17T01:16:11+09:00","summary":"先日、Solr入門のサンプルschema.xmlの3.6.0対応版の作成をしていて、気になったことがあったので、 メモとして残しておきます。 S","tags":["solr"],"title":"Solr 3.6.0のCJKの設定とSynonymFilterFactoryの気になる点(Jugemより移植)"},{"contents":"先日の続きです。「Apache Solr入門」の2章から4章の説明について、Solr3.6.0で動作させる時の変更点を以下に書いていきます。 なお、前回も説明しましたが、3.6.0からKuromojiという形態素解析器がSolrに同梱されるようになりました。 これから説明する2章の変更点の手順ですが、Kuromojiとlucene-gosenそれぞれの利用方法について説明します。 添付のschema.xmlについては、基本的にKuromojiを利用する形に変更してあります。 それに加えて、lucene-gosen用のフィールドを別途追加で定義しました。 これらのフィールド名については、次の表の用になります。 適宜、書籍のフィールド名と置き換えながら読み進めたり、試したりしてください。\nKuromojiフィールド lucene-gosenフィールド title title_gosen author auther_gosen summary summary_gosen intended_reader intended_reader_gosen from_author from_author_gosen toc toc_gosen 2章 2.1.3 schema.xmlのバージョン（27ページ） Solr3.xではschema.xmlのファイルの最新バージョンは**1.5**になっています。\n2.2.3 代表的なトークナイザ（35ページ） solrbook.analysis.SenTokenizerFactoryは必要ありません。 Solr 3.6.0からはKuromojiと呼ばれる形態素解析器が用意されています。 solr.JapaneseTokenizerFactoryがそれに該当します。 これとは別に、lucene-gosenを利用する場合、Solr向けのトークナイザが用意されています。 solr.GosenTokenizerFactoryがそれに該当します。\n2.2.4 代表的なトークンフィルタ（37ページ） 以下の2つについてはKuromojiが同等のトークンフィルタを提供しています。 また、lucene-gosenを利用する場合は、lucene-gosenに同等のトークンフィルタが存在します。\nsolrbook.analysis.KatakanaStemFilterFactory solrbook.analysis.POSFilterFactory 次のものがSolr 3.6.0に用意されているので、こちらを利用します。\nsolr.JapaneseKatakanaStemFilterFactory solr.JapanesePartOfSpeechStopFilterFactory それぞれ、次のものがlucene-gosenにあるので、こちらを利用します。\nsolr.GosenKatakanaStemFilterFactory solr.GosenPartOfSpeechStopFilterFactory 2章向けのschema.xmlはこちらです。その他のtxtファイルについては、特に変更はありません。\n3,4章は特に変更はありません。Solrの起動の仕方にだけ注意してください。（-Dsen.homeは必要ありません）\n以上が4章までの修正点になります。\n昨日に引き続き、眠い目をこすりながら修正したので、おかしいかも。 動かない、意味がわからないなどあれば、コメントorツイートいただければと思います。\n2012/06/14提供しているschema.xmlに関して修正を加えました。こちらの記事で説明しているautoGeneratePhraseQueriesの値をtext_gosen、text_cjkのフィールドに対してtrueを設定する記述を追記しました。\n","date":1334339880,"dir":"post/2012/","id":"d77cdb466c5063b99c5aea58e6da4d32","lang":"ja","lastmod":1334339880,"permalink":"https://blog.johtani.info/blog/2012/04/14/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C2%E7%AB%A04%E7%AB%A0/","publishdate":"2012-04-14T02:58:00+09:00","summary":"先日の続きです。「Apache Solr入門」の2章から4章の説明について、Solr3.6.0で動作させる時の変更点を以下に書いていきます。 な","tags":["solr"],"title":"「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（2章～4章）(Jugemより移植)"},{"contents":"以前より、アナウンスしていた、Kuromojiという日本語形態素解析が含まれるLucene/Solr 3.6.0がリリースされました。\n以下、各リリース内容について簡単に説明されているページへのリンクです。\nSolrリリースのお知らせ\nLuceneリリースのお知らせ\nSolr 3.6.0の変更の目玉は各言語のAnalyzer/Tokenizerの設定がexampleのschema.xmlに含まれるようになったことです。 Kuromojiという日本語用の形態素解析器もexampleを起動すればすぐに利用できる形になっています。 Kuromojiを利用する場合は、exampleのschema.xmlが参考になるでしょう。\nあと、大きな変更は、Ivyに対応した点です。ソースをダウンロードするとわかりますが、依存するjarファイルが含まれない形に変更されています。 SVNからチェックアウトした場合も同様です。ビルドにはネットワークに接続している環境が必要になりました。\nまた、このリリースに合わせて、以前書いた「Apache Solr入門」のサンプルについての記事も変更が必要かと思い、 前回の記事をベースに以下に変更した記事を書いたので、参考にしてください。 今回は、Kuromojiという日本語形態素解析がデフォルトで含まれるようになったので、 Kuromojiの利用方法とあわせて、lucene-gosenの利用方法も記載します。 サンプルのschema.xmlについては、Kuromoji、lucene-gosenが同時に利用できる形のものを用意しました。\nサンプルのschema.xmlを最新版（Solr 3.6 + lucene-gosen-2.0.0-ipadic）のものを用意しました。 なお、あくまでも、3.xでlucene-gosenを利用する場合の「Apache Solr入門」のサンプルプログラムの変更点（とりあえず、4章まで）の違いについて記述します。 申し訳ございませんが、1.4と3.xの違いについての説明はここでは行いません。\n以下では、各章でschema.xmlに関連する記載のある部分を抜粋して、変更点と変更したschema.xmlのリンクを用意しました。参考にしてもらえればと思います。\n1章 1.6.1 N-gram（17ページ） 1.6.1の手順に変更はありません。 サンプルプログラムが入っているZip「solrbook.zip」のintroduction/ngram/schema.xmlファイルの代わりに こちらのschema.xmlを利用してください。 ※なお、Solr 3.6.0から、SOLR_HOME/example/solr/conf/schema.xmlにデフォルトでN-gramで利用しているCJKTokenizerの設定が入るようになっています。 （実際にはCJKTokenizerではなく、CJKBigramFilterとCJKWidthFilterに変更されています。）\n1.6.2 形態素解析（18ページ～20ページ中盤まで） CJKと同様、exampleにKuromojiを利用した設定がすでに記述されています。text_jaというフィールドタイプになります。書籍の21ページ1行目に記載のある、 「Field」のテキストボックスに入力する文字列を「text_ja」とすると、Kuromojiを利用した形態素解析結果が表示されます。exampleですでに幾つかのフィルタも設定されているため、書籍の出力結果とは異なる表示となるはずです。\nlucene-gosenを利用する場合は手順が大きく変わります。 Senを利用する場合、Senの辞書のビルド、Senのjarファイルの配置、Senを利用するためのTokenizerクラスを含んだサンプルjarの配置という作業があります。 lucene-gosenではコンパイル済みの辞書がjarファイルに含まれています。 また、Solr向けのTokenizerもlucene-gosenのjarファイルに含まれています。 lucene-gosenを利用して形態素解析を体験するための手順は次の流れになります。 なお、schema.xmlについては上記N-gramでダウンロードしたschema.xmlに形態素解析の設定もあわせて記載してあります。\njarファイル（lucene-gosen-2.0.0-ipadic.jar）をダウンロードして、$SOLR/example/solr/lib（libディレクトリがない場合は作成）にコピーします。 コピーが終わりましたら、次のように$SOLR/exampleディレクトリでSolrを起動します。 （-Dsen.homeは必要なし）\n$ java -jar start.jar あとは、書籍の記述にしたがって管理画面のAnalysis画面で動作を確認します。 ほぼ、図1-6と同じ結果になっていると思います。 （lucene-gosenで出力される情報には本書のサンプルよりも多くの情報が含まれています。また、サンプルでは、形態素解析の後の単語に基本形を採用しているため、「な」が「だ」として出力されています。基本形を出力する場合は後述するこちらで紹介したTokenFilterを利用すれば可能です。）\n2章については後日説明することにします（眠くなってきた。。。）\n動作しないなどあれば、コメントください。\n2012/06/14追記提供しているschema.xmlに関して修正を加えました。こちらの記事で説明しているautoGeneratePhraseQueriesの値をtext_gosen、text_cjkのフィールドに対してtrueを設定する記述を追記しました。\n","date":1334339100,"dir":"post/2012/","id":"904b07170a0ce481b7491e7fecce4f79","lang":"ja","lastmod":1334339100,"permalink":"https://blog.johtani.info/blog/2012/04/14/lucene-solr-3-6-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9---apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0/","publishdate":"2012-04-14T02:45:00+09:00","summary":"以前より、アナウンスしていた、Kuromojiという日本語形態素解析が含まれるLucene/Solr 3.6.0がリリースされました。 以下、各","tags":["solr"],"title":"Lucene/Solr 3.6.0リリース / 「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（1章）(Jugemより移植)"},{"contents":"Twitterでこのブログ流れてきて、気になったので、流し読みして簡単にメモ。 Amazonのサービスでスケールする検索サービスみたい。\n主に、機能面です。価格とかはみてないです。\nデータと検索トラフィックに対して自動でスケール（※automaticってのがどういう感じかは調べてないです） CloudSearch APIsでアクセス可能。AWS管理コンソールからオペレーションできる。コマンドツールもある データ登録にHTTPSも使えますよ。データ形式はJSON、XML、SDF（Search Document Format）と呼ばれるものに準拠したもの near real-timeで検索可能になる。RAMにインデックスを保持して更新処理が早くなる（Lucene/Solrと一緒か？） ステミングとかストップワードの設定変えたらre-index ファセット、フィールド指定検索が可能。（ファセットはファセットクエリみたいなのもできるのかな？） データ量が増えたら、サーチインスタンスを追加するか、インスタンスタイプを大きくしてスケールする？ トラフィックが増えたら新しいインスタンスにデータをレプリケートしてインスタンスを追加する 簡単に実現できるよ。ファセット検索、全文検索、And/OR検索式、ランキングのカスタマイズ、フィールド指定ソート、フィールド指定検索、テキスト処理オプション（ストップワード、類義語、ステミングのような） ここから詳細のドキュメントが見れるみたいなので、また、見てみます。\nあと、WikipediaをCloudSearchで動かしてるデモとそれに関する記事もあるみたいです。これも暇を見つけて眺めてみます。\n","date":1334241069,"dir":"post/2012/","id":"bed3b7fcc1294e23639057435ac8756a","lang":"ja","lastmod":1334241069,"permalink":"https://blog.johtani.info/blog/2012/04/12/%E3%83%A1%E3%83%A2amazon-cloudsearch%E3%81%8C%E5%87%BA%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F%E3%82%88/","publishdate":"2012-04-12T23:31:09+09:00","summary":"Twitterでこのブログ流れてきて、気になったので、流し読みして簡単にメモ。 Amazonのサービスでスケールする検索サービスみたい。 主に、","tags":["備忘録"],"title":"【メモ】Amazon CloudSearchが出てきましたよ(Jugemより移植)"},{"contents":"JavaOne Tokyo 2012に参加してきました。 4/4-4/5の2日間開催されていたのですが、子供が体調を崩してしまい、4/5のみの参加となりました。 4/4はTwitterのTLを眺めて、羨ましがってました。\n7年ぶりに日本で開催されたJavaOneみたいです。 そういえば、7年前くらいに参加した記憶があるなぁと。\n会場入りして最初の感想は年齢層が高いなぁと。 最近、勉強会によく顔を出すようになったのですが、勉強会とは年齢層が少し異なりました。 まぁ、私も年齢層を上げている一人ではあるのですが。。。 Javaも熟成してきてるなぁというのが最初の感想でした。 あと、思ったよりもスーツ率は低かったと思いました。（5割はいましたが） 一番違和感を感じたのは、会場の所々の色が「赤い」ことです。。。\n以下は私が参加したセッションのカンタンな感想です。\nJava EE6 Modeling　JS2-01　#jt12_s201\nJavaEEから離れてはや数年。私が関わっていた頃はEJB2.0が出たくらいのタイミングだったので、 色々と変わってきているなぁというのが第一印象です。 CDI、Singleton EJBなど、知らない単語もちらほらと。 earではなく、warファイル1つで済む、jQueryをリソースjarとしてパッケージングしてwarファイルに入れられるなどは簡易になっていいなぁと。 web.xmlがアノテーションで記述できて要らなくなるという話は一長一短だと思いました。 一覧性があるからいいと思うこともあるので。 中国の方？の英語だったので少し特徴的でした。すこしは頑張ってみたものの、やはり同時通訳を聞いてしまって反省しています。。。\nマルチコアCPU時代のJavaプログラミング　JS2-14　#jt12_s214\nF社の方が実際に経験されてきた性能関連のプログラミングについての話でした。 現時点のJavaでマルチコアCPUで気をつけるべきプログラミングの観点をわかりやすく説明されたいいセッションでした。 詳細は下のメモを見ていただけるといいですが、色々とプログラミングで気をつけるべき点を説明されていました。 いいおさらいになりましたし、忘れていることや知らないこともあって勉強になりました。 TLでも見かけましたが、モダンJavaプログラミングみたいな、今のJavaでのプログラミングの気をつけるべき点を書いた書籍があるといいかもなぁと思いました。 あと、もうひとつ私が好印象だと思ったのは、F社の製品の紹介などがなかったからかもしれませんｗ\nサービス維持・発展を踏まえた楽天オークションのJava EEによる開発と運用　JS2-23　#jt12_s223\n楽天オークションの開発をサれている方の立ち上げから現在に至るまでの開発メンバーの管理の仕方や 実際に利用している開発手法、気をつけている点のお話です。 スライドに書いてあること以外のことを発表者の方が話をされており、もう少し、喋る内容に関連した図などを入れてもらえるとわかりやすかったかもしれません。 あとは、WebLogicの管理画面が使いやすくていいという話のあとに、GlassFishに移行していますという話があったりと、少し「？」が浮かぶ部分がありました。。。\nJSR 353: Java API for JSON Processing　JS2-33　#jt12_s233\n最近、Twitterで遊んでもらっている（勝手に絡んでいるだけという話も。。。）@yusukeyさんの発表です。 結構な数の立ち見が出るほどの盛況ぶりで、発表者の@yusukeyさんもびっくりしていました。 JSRがどういった形で実際の仕様として公開されていくのかという話がわかりやすく紹介されていて勉強になりました。 所々で笑いが入るなど、さすがの安定感でした。立ち見が出るはずです。 ようやく、JavaもJSONに関する処理を仕様として取り入れようとしているのはいい傾向かと。 ※残念ながら資料は公開されないようです。\nUI Controls and Charts: Drag-and-Drop, Filtering, Sorting, Table Hookup with Charts　JS2-42　#jt12_s242\n最近、Chartに興味を持っていたので、登録したセッションです。 内容としてはJavaFXのコンポーネントをリストアップして紹介していくというお話でした。 グラフ（Chart）周りも数種類が用意されるようです。 JavaFXをあまり知らないのですが、Swingをすこしやっていたのでなんとかついていくことが出来ました。 発表者の方が、実際にJavaFX内部の実装を行われている方だったようで、QAでいくつかこんなコンポーネントはないのか？という質問に、「私のPCでは動いているのですが、ドキュメントなどの整備が追いついていないので公開できていないです」という回答が出て、なかなか大変なのだなぁとｗ Chartに関しては、グラフの重ね合わせなどがまだできないということで、JFreeChartを触ったことがある身としてはすこし物足りなさそうだなぁというのが印象です。\nLearn how the JVM is fundamental to our architecture.　BoF2-03 #jt12_b203\n今回JavaOneに参加した一番の理由がこのセッションです。 Twitterのアーキテクチャに関するセッションでした。 思った以上に濃い内容で、ツイートしたデータがどんな流れで登録されるのか、登録されたデータを各ユーザのTimelineにどのようにアクセスして表示しているのかが説明されました。 今回は主にFinagleについての話でしたが、非同期処理をどのように活用しているかというお話でした。 負荷分散を行なっているポイントやキャッシュについての考え方などです。 メモを取るのに夢中になってしまい、英語をヒアリングするという目的を見失ってしまいましたが。。。 期待以上の話が聞けて満足しています。\nパネルディスカッション\n最後はJavaに関連するコミュニティを運営されている方々のコミュニティ運営に関するディスカッションです。 コミュニティの運営の苦労している点や、心がけている点など、運営も大変そうだなぁと。 どうしても長くやっているとメンバーが固定化してしまうという話なども出ていました。 これは難しいですよね。会社も同じことが言えますし。 一番印象に残ったのは桜庭さんの「動くものが作れるのが楽しい」という一言でした。 エンジニアをやってるのは確かにそこが面白いからだなぁと。最近忘れかけているので、もっと色々と作っていきたいですね。\n以上がカンタンな感想です。 少し残念なのですが、事前に参加登録していたセッションについては、マイページと呼ばれるところから資料がダウンロードできるものもあるみたいですが、参加登録してないものについてはダウンロードが出来ない様でした。（4/6現在） 参加できなかったセッションの資料こそ見たいと思うのが普通だと思うのですが、どうでしょう？そのうちどこかに公開されるのかなぁ。\n以下は、いつもの通り個人のメモです。\n場所：六本木ヒルズ　アカデミーヒルズ49F 日時：2012/04/05 ○Java EE6 Modeling　JS2-01　#jt12_s201 スーツ禁止。Eva好き？ ・特徴 Web Profile Pruing POJO、Annotation、Less XML Java EE6の半分のAPIは変更なし。新規が11% ・JavaEE6 Web Profile CDI、Interceptors、JSR 250 Singleton EJB JPAはEntityBeanの代わりかな？ ・パッケージングがearではなく、war一つで済むように。 war（ウォーファイル） web.xmlはアノテーションで行えるようになり、要らなくなる。 ◯マルチコアCPU時代のJavaプログラミング　JS2-14　#jt12_s214 HotSpotVM依存のお話ですよ。 ・GCとか ・java.util.concurrent.ForkJoinPool デフォルト並列数は論理CPU数 ・メモリアロケーション TLABが非効率に。先にある程度大きめにスレッドに割り当てを行うため、 スレッド数が上がるとTLABが非効率になる-\u0026gt;Eden全体では未使用領域があるんだけどGC発生とか ・JNIでの問題 GetStringCriticalとReleaseStringCritical間はGCが抑止されるため。 ・無意識のロック HashTableやStringBufferなど。 String#getBytes()も。 InetAddress#getAllByName()が内部でキャッシュを持ってる＝ロック File#renameTo()も内部でキャッシュ（ExpiringCache）持ってる。 Javaでは時間がかかる処理にはキャッシュを利用するという仕組みなので。スレッド数を増加させる場合は注意が必要 ・フェアネスロック lock = new Object(); for (int i=0;i\u0026lt;100;i++0{ synchronized(lock){ System.out.println(\u0026#34;i=\u0026#34;+i+\u0026#34;tid=\u0026#34;+Thread.currentThread().getId()); } } 上記を実行してもかたよることがあるよ。＝フェアじゃない モニターによるスレッド割り当ての説明。 RentrantLockでフェアネスになるよ。 ・性能分析 println()で区間分析。複数スレッドで実行したら実行時間にずれが。 println内部でもsynchronizedを利用している。＝ロックのせいで処理時間が遅くなるスレッドが出てきたりする。 JVMTIで性能分析する場合RawMonitorEnter,RawMonitorExitでロックとりあいなるのでもマルチスレッッドだと正しい値がでない。GetThreadLocalStrage使え。 ・まとめ： ハードウェア更改時にプログラムの変更が必要になることもあるよ。 わずかのロックが命取りに（ロックをあんまり使わない、無意識なロックを見極めなさい） ロックポリシーの選択（レスポンス重視なのか、スループット重視なのか） QA Q：事例が合ったという話でしたが、コードの修正しかないんですか？ A：はい。やっぱり治すのがいいです。あとは、チューニングですが。。。 Q：ReentrantLockが昔はスレッドダンプにでなかったのですが、今は？ A：今は出ます。 Q：各世代とJavaのバージョンのマッピングは？ A：第3世代が1.5くらいから。第2世代が1.3とか1.4？ ◯サービス維持・発展を踏まえた楽天オークションのJava EEによる開発と運用　JS2-23　#jt12_s223 ・短期で人材が参加できるようにしているというお話 ・楽天オークションの成り立ち（郵政とdocomoと楽天） ・商品、コミュニティ系（出品とか検索とか）と流通系（入出金、配送など）の2軸 ・メンバー30人くらい ミドルエンジニア エンジニア プロデューサー ・楽天市場をベースとして機能追加 ・巨大でリリースが大変に。 ・この5年で機能分解して機能ごとのリリースをめざして改善している ・JavaEEを使う理由 WebLogic上にバッチが動いているなどの仕組みをしている？ 管理機能が充実している（WebLogic） ・GlassFishへ移行中 あれ？Weblogicの管理機能がいいんじゃなかったっけ？ EJB実装はWebLogicに依存してるのでWebLogicもバージョンアップしてる。 ※メモはここまで。電池の持ちを気にして ◯ JSR 353: Java API for JSON Processing　JS2-33　#jt12_s233 ・JSONとは JavaScript Object Notation 「軽量な」データ交換フォーマット ・JSON仕様のグラフ ・XMLもあるのになんで？ シンプルで可読性が高い 属性がなく、複雑なスキーマ仕様がない。 ・コンパクト ・Twitter、GoogleMaps、YahooWebServicesなど ・JCP、JSRのお話 JSRの役割とか。 リファレンス実装の話。 ・JSR-353 http://jcp.org/en/jsr/detail?id=353 StAXやDOMに対応するよ。 ・ゴールではないもの JSONをJavaのドメインオブジェクトにバインドするとかもどすとか。 ・メンバー @yusukeyも一人 ・参加になったきっかけ 2011/10にTwitterがJCPに参加 2012/12/6にJSON JSR提出 年越しに採択 @yusukey「これTwitterで重要じゃない？」 @cra　「やりましょう」 ・JSRのコミュニケーション 世界各地の人なので、基本メールベース（今は自己紹介したくらい。。） ・既存のJSONライブラリ json.org、jackson、google-gson ・なんで、いろいろあるのにJSR？ 標準化、クラスパスにデフォ、シンプル、ライセンスで悩まないとか。 ・ロードマップ エキスパートグループ作成→アーリードラフト→パブリックレビュー→ファイナルリリース いま、アーリードラフト ・最新仕様 javax.json.* javax.json.spi.* javax.json.stream.* javax.json.tree.* メソッドチェインできるみたい。 JsonObject.create(reader);みたい JsonObject obj = …; JsonWriter writer = obj.accept(writer.) ・改善案 JSON***にしたいな。 spiはらないんじゃないかな？（いま、一個しか無い） treeもいらないんじゃないかな？（そんなに増えないし） parseじゃないかな？ メソッド追加（asStringで文字列化とか、create(String)とか） QA Q：JSONのスキーマ決めないの？バリデータとか A：JSONスキーマはあんまりもてはやされてない。一応あるのはある。 さすがの安定感。適宜笑いが入ってて楽しかったです。 ◯UI Controls and Charts: Drag-and-Drop, Filtering, Sorting, Table Hookup with Charts　JS2-42　#jt12_s242 ◯JavaFX 2.0のControls ◯Label、Button、ToggleButton、RadioButton、Hyperlink、CheckBox ◯Slider、ScrollBar、ScrollPane、ProgressIndicator、ProgressBar ◯TextField、PasswordField、TextArea ◯新しい機能 TitledPaneとAccordion TabPaneとSplitPane ◯Charts XYChartとPieChart XYChartにはLineChart、AreaChart、BarChart、ScatterChart、BubbleChartがある。 ◯Menu MenuItemの下に色々ある。 CheckMenuItem、RadioMenuItem、CustomMenuItem（SeparatorMenuItemとか) ◯ChoiceBox、ContextMenu、ToolTip ◯ListView ◯2.1の新機能 ComboBox、http://fxexperience.com/2012/03/new-in-javafx-2-1-combobox/ StackedBarChart、 StackedAreaChart MenuBarのMac OSへの対応（窓の中じゃなく、画面上部にちゃんと出る。） LCD Text QA： Q：テキストエリアの日本語入力とかは？ A：JavaFX3.0で対応 Q：FXML（Scene Builder）を使ってコードが生成されるのか？ A：ドラッグ・アンド・ドロップでやる場合はScene Builderでもできるでしょう。私はNetBeansとかでやりますけどね。 Q：Dialogはいつ対応されるんでしょうか？ A：私は使ってるんですけど、JavaFXに入れてもらえませんｗコードは出来てますｗ Q：Chartがありますが、pngやsvgでの出力は可能？ A：できません。そのうちできるかも。 Q：Chartの結合はできる？Axisの時間を便利に使うツールはありますか？ A：できないです。ありません。 Q：FX2.0でカスタムコントロール作るの大変？ A：私のマシンでは動いてるんですがｗ Q：ChartにCSSを適用することは可能？ A：可能です。データはJavaから出力されたものだけですけどね。 Q：JavaFX2.0の起動速度が上がったけど、どういう仕組？ A：私は上の方のエンジニアなのでよくわからないですが、GPUをうまく使ってるみたいです。 ◯Learn how the JVM is fundamental to our architecture.　BoF2-03 #jt12_b203 Java、Scala、Linuxのカーネルまで担当してます。 ・Twitterのアーキテクチャ ・スパイクが急にあがる場合にも対応できるスケールの話。 なでしこ、#バルス、大震災など ・Twitterはプラットフォーム ・最上位層：HTTP Proxy（Routing） ・中層：Twitter App（Models/Biz Objects、Composition） UserService、TweetService、TimelineServiceに分解（Models/Biz Objects） API（Composition） ・最下層：TimelineStorage、TweetStorage、SocialGraph、UserStorage（Storage/Retrieval） ・NEEDS サーバ負荷をハンドルできる必要がある。 言語のフレキシビリティ（JavaとかScalaとか） 成熟したコンカレンシーモデル ・Java が提供してるもの 開発者のエコシステムが素晴らしい。例：Nettyを使っている。Non-blocking I/O world class JITとコンカレンシーモデル メモリ管理 利点：メモリ管理を意識しなくていい 課題：GC。OpenJDKのコミュニティで参加してる。 複数の言語が実行可能な環境 ・OpenJDKについて ・Finagleのお話。 Netty上に作られた非同期なRPCサーバクライアントのライブラリ http://twitter.gthub.com/finagle/ ・TimelineServiceのお話 340M/day 10K/sec（イベント時） ・ツイートが入ってくる仕組み HTTP Proxy → tweet API → queue → tweet daemon → fanout （social graph）→ delivery → timeline cache → redis ・fanout 4000フォロワーごとにdeliveryにツイートが渡される。 ・Timelineを見る仕組み HTTP Proxy → timeline API（user service、） →timeline service →timeline cache ・timeline、tweets、users ・timeline serviceとtimeline cacheの関係 Finagleで負荷分散している ・timeline serviceからtimeline cacheへのリクエストを監視して、 高頻度のリクエストについては、timeline serviceのin-process cacheに入れる仕組み ・Service[Request, Response] Scalaの記述 service(request).onSuccess {response =\u0026gt; println(\u0026#34;got response! \u0026#34; + response) } ・Finagleのコンポーネント コネクション管理 プロトコルデコード　ThriftでService以降がつながってる。 分散トレース　オーバーヘッドを抑えて全体を監視（RPCトレース（呼び出しと処理時間のタイムラインチャート）） サービスディスカバリ　observability ◯パネルディスカッション ・JGGUG、JRuby、Scala、Groovyのコミュニティ運営に関係している方々によるディスカッション。 ","date":1333698660,"dir":"post/2012/","id":"56d5711303378bd333ddb611a53ece94","lang":"ja","lastmod":1333698660,"permalink":"https://blog.johtani.info/blog/2012/04/06/java-one-tokyo-2012-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-javaonejp/","publishdate":"2012-04-06T16:51:00+09:00","summary":"JavaOne Tokyo 2012に参加してきました。 4/4-4/5の2日間開催されていたのですが、子供が体調を崩してしまい、4/5のみの参加となりました。 4/4","tags":["勉強会"],"title":"Java One Tokyo 2012 に参加しました。#JavaOneJp(Jugemより移植)"},{"contents":"先日、2.0.0リリースの記事にも記載しましたが、Java7でテストケースが失敗する問題がありました。\n@haruyamaさんと@hideaki_tさんの協力により問題を解消し、trunkと4xブランチにコミットしました。\nissueにも記載しましたが、Java6からJava7にバージョンアップするタイミングで変更されたUnicodeのバージョンが原因でした。 Java6ではUnicodeのバージョンが4.0です。Java7ではUnicodeのバージョンが6.0に変更されています。 今回の問題は「・」（0x30FB）の文字列のCharacter.getType()がCONNECTOR_PUNCTUATIONからOTHER_PUNCTUATIONに変更されたのが原因です。（この変更自体はUnicode 4.1で変更されたみたい） カタカナ文字種の判別をlucene-gosenのnet.java.sen.tokenizers.ja.JapaneseTokenizerのgetCharClass(char c)メソッドで行なっています。 修正前は、ここで、charの範囲が0x30A0～0x30FFにある文字でかつ、Character.getType()がCONNECTOR_PUNCTUATIONでないものがカタカナとして判別されていました。 issueの添付ファイルにJava6とJava7で上記範囲の文字のCharacter.getType()のリストを生成して、該当する文字を探した所、「・」（0x30FB）のみであることがわかりました。 ということで、このコードの意図としては、「・」はカタカナではないと判別したかったのだと。 上記の確認を行えたので、ソースコードを修正してコミットしました。 2.0.1としてリリースするかは、Issue29のボリュームを見て考えますので、もう少しお待ちください。\n参考にしたサイト： JavaSE 7でメソッド名に使えなくなった文字 UNICODE CHARACTER DATABASEのHistory\n","date":1333552800,"dir":"post/2012/","id":"c7937b6b4bde2a96191dc31db913e1ab","lang":"ja","lastmod":1333552800,"permalink":"https://blog.johtani.info/blog/2012/04/05/lucene-gosen%E3%81%AEjava7%E3%81%A7%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E5%A4%B1%E6%95%97%E5%95%8F%E9%A1%8C%E3%81%AE%E5%AF%BE%E5%BF%9C/","publishdate":"2012-04-05T00:20:00+09:00","summary":"先日、2.0.0リリースの記事にも記載しましたが、Java7でテストケースが失敗する問題がありました。 @haruyamaさんと@hideak","tags":["lucene-gosen"],"title":"lucene-gosenのJava7でのテスト失敗問題の対応(Jugemより移植)"},{"contents":"先日、宣言したとおり、lucene-gosenのパッケージ名＋クラス名の変更を行ったlucene-gosen 2.0.0をリリースしました。 Lucene/Solr 3.6.0のリリースを待つつもりだったのですが、なかなか出ないので先にリリースを行いました。 現時点では、branches/4xについては、パッケージ名、クラス名の修正が追いついていません。 明日までに4xブランチについても修正を反映する予定です。\n参考までに、1.2.1から2.0.0への変更点について以下にまとめました。 また、変更に伴い、Solrのschema.xmlに記述するクラス名も変更になります。 schema.xmlのサンプルについてはこちらをご覧下さい。\n変更点 まずは、パッケージ名の変更点です。 左が旧パッケージ名、右が新パッケージ名となります。\n旧パッケージ名 新パッケージ名 org.apache.lucene.analysis.ja org.apache.lucene.analysis.gosen org.apache.lucene.analysis.ja.tokenAttributes org.apache.lucene.analysis.gosen.tokenAttributes また、パッケージ名とは別に、以下のクラス名も変更になっています。 まずは、org.apache.lucene.analysis.gosenのクラス名の変更点です。\n旧クラス名 新クラス名 JapaneseAnalyzer.java GosenAnalyzer.java JapaneseBasicFormFilter.java GosenBasicFormFilter.java JapaneseKatakanaStemFilter.java GosenKatakanaStemFilter.java JapanesePartOfSpeechKeepFilter.java GosenPartOfSpeechKeepFilter.java JapanesePartOfSpeechStopFilter.java GosenPartOfSpeechStopFilter.java JapanesePunctuationFilter.java GosenPunctuationFilter.java なし GosenReadingsFormFilter.java JapaneseTokenizer.java GosenTokenizer.java JapaneseWidthFilter.java GosenWidthFilter.java 次は**org.apache.solr.analysis**です。 旧クラス名 新クラス名 JapaneseBasicFormFilterFactory.java GosenBasicFormFilterFactory.java JapaneseKatakanaStemFilterFactory.java GosenKatakanaStemFilterFactory.java JapanesePartOfSpeechKeepFilterFactory.java GosenPartOfSpeechKeepFilterFactory.java JapanesePartOfSpeechStopFilterFactory.java GosenPartOfSpeechStopFilterFactory.java JapanesePunctuationFilterFactory.java GosenPunctuationFilterFactory.java なし GosenReadingsFormFilterFactory.java JapaneseTokenizerFactory.java GosenTokenizerFactory.java JapaneseWidthFilterFactory.java GosenWidthFilterFactory.java また、上記クラスに関連するテストクラスの名前も変更になっています。\n以上がクラス名、パッケージ名の対応に関する修正ついてでした。\nまた、現在、Java7にてテストケースが失敗する問題が見つかっています。 こちらの問題の対応版についても近日中にリリースを行う予定です。\n問題点、質問などありましたら、コメントしていただくと回答いたします。\n2012-04-03追記 忘れてました、すみません。今回のリリースで、以下の機能が追加されています。\nAntのパラメータにproxy.user、proxy.passwordの追加 GosenReadingsFormFilterの追加 TokenAttributeの修正（PronunciationsAttributeImpl、ReadingsAttributeImpl） Antは認証が必要なプロキシ環境で辞書のビルドを実施するときにユーザ名、パスワードを指定できるようにしました。\nGosenReadingsFormFilterは単語を読みに変換するTokenFilterになります。 よみは、辞書に登録してある読みになります。オプションとして、romanizedが指定可能です。指定をすると、よみをローマ字に変換します。\nTokenAttributeの修正は、バグフィックスになります。Issueはこちらです。\n","date":1333362120,"dir":"post/2012/","id":"06731164684f90f33ce4017eca9d8ec1","lang":"ja","lastmod":1333362120,"permalink":"https://blog.johtani.info/blog/2012/04/02/%E9%87%8D%E8%A6%81lucene-gosen-2-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2012-04-02T19:22:00+09:00","summary":"先日、宣言したとおり、lucene-gosenのパッケージ名＋クラス名の変更を行ったlucene-gosen 2.0.0をリリースしました。 Lucene/Solr","tags":["lucene-gosen"],"title":"【重要】lucene-gosen 2.0.0リリース(Jugemより移植)"},{"contents":"lucene-gosenを利用して頂いてる皆様に連絡があります。\n連絡事項 次期lucene-gosenのリリース（2.0を予定）にて、org.apache系のパッケージ名および、クラス名の変更を行います。 Lucene/Solrの次期リリース版である3.6.0以降では、lucene-gosen 2.0（予定）を利用するようにしてください。\n経緯 Twitterでは少しずつツイートしていますが、Lucene/Solr 3.6から日本語の形態素解析器がLucene/Solrにて用意されることになりました。 ベースとなっているのは、Atilika社が開発したKuromojiという形態素解析器です。 Lucene/SolrにコントリビュートされたタイミングではKuromojiAnalyzerなど、Kuromojiという名称が残った形で取り込みが行われました。 その後、LUCENE-3909にて、Kuromojiではなく、一般的な名称（Japanese*）に変更する提案が行われました。 この提案で、luene-gosenが利用しているクラス名、パッケージ名と大半のクラスが衝突してしまうこととなりましす。 今後も、lucene-gosenを利用していただけるように、lucene-gosenのIssueを発行し、 現在、lucene-gosenのtrunkにてパッケージ名の変更及びクラス名の変更作業を行なっています。 正式にリリースするタイミングになりましたら、再度連絡いたします。\nブランチなどについて 現時点ではパッケージ名、クラス名の変更はリポジトリの以下のものについてのみ作業を行う予定です。\ntrunk branches/4x 現時点でのリリース版（1.2系）のソースについてはbranches/rel-1.2にて、これまで同様のクラス名、パッケージ名のまま変更を行いません。 1.2系についてはこちらをご覧下さい。\nまた、当ブログにて、提供しているSolr入門のサンプルに利用可能なschema.xmlなどの記事についてもLucene/Solr3.6がリリースされた際には再度修正して掲載いたします。 Kuromojiの利用方法もあわせて記載したいです。\n参考： lucene-gosenとKuromojiの機能などの比較についてはこちらを参考にしてください。\n","date":1332783540,"dir":"post/2012/","id":"f8327953a0f0b80011b939111807999a","lang":"ja","lastmod":1332783540,"permalink":"https://blog.johtani.info/blog/2012/03/27/%E9%87%8D%E8%A6%81lucene-gosen%E3%81%AE%E6%AC%A1%E6%9C%9F%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-03-27T02:39:00+09:00","summary":"lucene-gosenを利用して頂いてる皆様に連絡があります。 連絡事項 次期lucene-gosenのリリース（2.0を予定）にて、org.","tags":["lucene-gosen"],"title":"【重要】lucene-gosenの次期リリースについて(Jugemより移植)"},{"contents":"子供の寝かしつけしてたら、寝かしつけされてしまって、２時に目が覚めてしまいました。 TSUTAYAでCD借りてきてウォークマンに入れようと思っていたのに。。。 ということで、今作業してます。\nMBAを買う前から使っている、もう９年目のWindows自作デスクトップで基本的にはCDの取り込みをしています。 ファイルサーバ（BuffaloのTeraStation）がLionから接続できないというのと、 X-アプリで曲管理していたのでという理由です。 あと、ウォークマンなのでMac用のソフトがなかったりというのも理由です。\nで、眠い目をこすりながらWindowsマシンを起動すると、ネットワークにつながらないじゃないですか。。。 再起動してもダメでした。\nとなってしまったので、せっかく、譲ってもらったMac miniも活用しないといけないなと思い、iTunesでアルバムを取り込んでみています。 ここ数年はWAV形式でデータを取り込んでいたので、WAVでの取り込みを設定して、iTunesで取り込みました。\nとまぁ、ここまでやってから、件のWindows機を再度、再起動したらネットワークに繋がってしまいました。。。 なので、残りのCDはWindows機で取り込みしてます。 けど、そろそろこのPCも危なそうなので、データをサルベージして、Mac miniで作業できるようにしないとなぁ。 Macでウォークマンを運用している人はどうやってるんだろう？ ちなみに私が利用しているウォークマンはNW-A847です。 エンコードはWAV形式で取り込んで、X-アプリでウォークマンに入れています。 iTunes使ってる人は、アップルのロスレスエンコードをつかってるのかなぁ？ ということで、調査・検討したい項目はこんなところですか。\n調査：TeraStationにMacからつなぐ方法（Lionで利用できそうなソフトなにかないかな？） 調査：iTunesでウォークマンに曲転送（やってみればすぐわかるだろう。。。） 調査：iTunesの曲をCDに焼く方法（車で曲聞くのにCDだから） 検討：ファイルサーバのリプレース対象となる機種（ファイルサーバは導入してまだ５年だから余裕がないと買い換えない） 検討：iPodに鞍替え（Sony好きだし、ウォークマン好きだし、買ったばっかりだからまず無い選択肢） 検討：Mac miniにVirtualBox入れて、WindowsからX-アプリ使うとか。（ファイルサーバが見えるようになるかな？） 検討：Mac miniをWindowsとして運用（もったいなさすぎる気がする） とまぁ、まだ悩んでるだけで、取り留めもない事を書いて、しかも結論が出ないままですが、ご容赦ください。 ご意見、提案を大募集してます！！\n","date":1332618420,"dir":"post/2012/","id":"8b76101d185700a8efed148d8722d926","lang":"ja","lastmod":1332618420,"permalink":"https://blog.johtani.info/blog/2012/03/25/%E4%B9%85%E3%80%85%E3%81%ABmac-mini%E3%81%AE%E3%81%93%E3%81%A8%E3%81%A7%E3%82%82/","publishdate":"2012-03-25T04:47:00+09:00","summary":"子供の寝かしつけしてたら、寝かしつけされてしまって、２時に目が覚めてしまいました。 TSUTAYAでCD借りてきてウォークマンに入れようと思っ","tags":["備忘録"],"title":"久々にMac Miniのことでも(Jugemより移植)"},{"contents":"はい。またまた、Twitter API勉強会に参加してきました。（今回から開催回数の記載がなくなった？） 今回は直前でタイムテーブルが変わってしまう波乱がありましたが、個人的には楽しめる内容でした。 Twitterの国際化や形態素解析などの話が聞けたのがすごく面白かったです。 アーキテクチャや利用されている形態素解析器の話など、また、現状の問題点なども話が聞けました。 日々、進化しているんだなぁと。 残念ながら、発表者の方が懇親会にいらっしゃらなかったので、詳しく聞けませんでしたが、挨拶だけは出来ました。 実際のテスト環境や導入方法、A/Bテストとかやってるのかなど、ブログをかきながら色々と気になることが出てきてしまいますｗ 頭の回転がよくないので、話を聞いてる間は質問があんまり思い浮かばなかったなぁ。。。\nその他にも（使ったことなくてすみません。。。）「昼会」のサービスの話、他の言語でのTwitterの活用の話も聞けました。\n途中で帰ってしまいましたが、懇親会でも数人の方とお話できて、楽しかったです。 （今回の懇親会会場はちょっと人数の割に手狭だったかもなぁ）\n次回は4月末を予定しているようでした。今度こそ、利用規約の話になるんですかね？ 忙しさを見つつ、また参加しようかと思います。\nということで、いつものメモです。\n開催日時：2012/03/21 19:00 ～ 21:00場所：ハロー会議室shibuya Zusaarのページ\n◎Twitterの日本語検索、ハッシュタグについて　@keita_f\n◯アーキテクチャ ・Twitterバックエンドの国際化 Before 各言語ごとに独自実装。 After 共通テキスト処理ライブラリ：Penguin ・アーキテクチャ：検索 Firehose → ingester → Earlybird ⇔ Blender ← ユーザの検索 Firehose：ツイートの受信 ingester：ツイート解析 Earlybird：Luceneベースのインデクサ Blender： ・アーキテクチャ：トレンド TrendsはGeo（ユーザ位置情報）を利用してるっぽい。 Term Statisticsは過去ツイートからHadoopで頻出フレーズを解析する。 今頻出しているフレーズ＋過去頻出しているフレーズ ◯日本語関連 ・ツイートの言語判定 言語判定にはIndigenous Tweets（Kevin Scannell）をベースに実装。 ５０言語サポート、Javaで実装 ・文字種チェック ・エンコーディングチェック ・Ngram（the→英語、das→ドイツ語） 問題点： ２つ以上の言語が混じってる場合 絵文字が入ってる場合 Unicodeアルファベット ・形態素解析 日本語：Gomoku 中国語：LuceneのSmartCN その他：N-Gram 問題点： 形態素が小さすぎる →そのままだと細かすぎるので品詞情報を元に大きめに区切るようにしている iPhone4Sなどが数字で区切られる →ASCIIの数字とアルファベットは連結しなおす ・フレーズ抽出 他の言語もあったけど、キー入力間に合わず 日本語の場合： トークンに分割 トークンでNgramを生成 品詞情報を使ってフィルター 最初、最後が助詞はNG、接頭詞で終わるのはNG ・やりたい事はまだまだたくさん ・形態素解析の品質向上 辞書への単語追加 韓国語、タイ語のトークなイザー ・同義語、類義語、翻訳、音訳、略語などのサポート ・フレーズ・トピックのクラスタリング ・Sentiment Analysis ・日本語のできるエンジニア募集中ｗ QA Q：顔文字を手動で抜き出すと言われたんですが、どのくらいあるんでしょうか？　A：正規表現なので、なんとも言えませんが、パターンを Q：Gomokuの選択の理由は？ A：Javaだから。jarに辞書が入るから。スピードが出るから。 ◎ランチタイム共有サービス「昼会(http://www.hirukai.jp/)」のご紹介　@setomits\n◯前提 ・ネットワーキングは重要 ・出会いも重要 ・飲み会だとコスパが悪い ◯ランチだと ・金額が限られる ・必ず食べる ということで、昼会だ！ ◯画面でサービスの説明 パブリックな昼会、プライベートな昼会がある。 ◯なんでTwitter？ LinkedInのOAuthを使ったログイン検討してた。 ビジネス目的＋ 敷居が高いのでTwitterに変更 ◯Twitterのapiで利用しているものなど ◯ユーザの声 ・DMを使ってる＝自分からのDMが気持ち悪い APIの使用制限やフォローしてもらう必要があるのが辛い。 - スパムかと思った - 乗っ取られたかと思った。 - エンジニアからは、「まぁ、こうするよね」 ・OAuthについて - ユーザ登録しなくていいのは嬉しい - イベント参加のためにOAuthでの書き込み権限まで与えたくない ◯８ヶ月経って ・新しい出会いがあった ・昼会を開催する敷居が高い ＝なかなか使ってもらえない ◯今後の計画 募集中！ QA Q：AppEngineで月額どのくらい？ A：料金改定前：数千円/１ヶ月、料金改定後：２万円くらい/１ヶ月 処理数を減らして、現時点では数千円/１ヶ月に最適化した Q：夜会はないんですか？ A：設計していたら、出会い系サイト？になりそうなので、昼にした。 ドメイン的になぁ。まだ悩み中 Q：GAE特化したもの？AWSに移行できる作り？ A：できない作りです。（pythonで書いてます。） GAEが楽なので、移行可能な作りにするのがつらい。 ◎LT ◯Twitter 4 contact　@inda_re ・広告！アジャイルサムライの道場\n・問い合わせフォームをTwitterにしちゃう 今あるHTMLにフォームを入れる方法（MySQLとPHP） githubにサンプルあるよ。 ◯PerlのTwitterモジュールについて　@xtetsuji\n・前回出席したら、ムチャぶりが！ ・いまどきのPerl 進化してるよ、古い情報が検索で出てきてしまうのがネック ・perlbrewってのがある http://perlbrew.pl/ ・AnyEvent::Twitter::Streamをよく使ってます。 ・gistにサンプルあげてあるよ！ ◯KotlinでもTwitter4J　@ngsw_taro ・Kotlinの説明 ・以下のサイトでインストールしなくても動かせるよ！ http://kotlin-demo.jetbrains.com/ ・NULL安全 Nullを許容する型、許容しない型がある。 ・一応、Twitter4Jのサンプルも作ったけど、ブログ見てね http://d.hatena.ne.jp/ngsw_taro/\n◯締め Twitter API勉強会ではスピーカーを常に募集中です。登録はこちら！\n","date":1332343680,"dir":"post/2012/","id":"16b3c9445539e9274282a612dea354c2","lang":"ja","lastmod":1332343680,"permalink":"https://blog.johtani.info/blog/2012/03/22/%E7%AC%AC5%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%B8%8B%E8%B0%B7--twtr_hack/","publishdate":"2012-03-22T00:28:00+09:00","summary":"はい。またまた、Twitter API勉強会に参加してきました。（今回から開催回数の記載がなくなった？） 今回は直前でタイムテーブルが変わってし","tags":["勉強会"],"title":"第5回 Twitter API勉強会 @渋谷 #twtr_hack(Jugemより移植)"},{"contents":"TLで面白いと見かけて、Amazonで買ってしまいました。 SEやってるのに、つい最近Amazonを使い始めた軟弱者です。 それにしてもAmazon危険です。スマートフォンにAmazonの Androidアプリを入れたのですが、これがまた、レコメンドに面白そうな本が出てきて危険です。\n話がそれてしまいましたが、面白い本でした。 久々に、小説でも技術書でもない本を短期間で読みました。 「箱」と呼ばれる概念の中と外について、とある会社に転職した管理職の人が学んでいくという物語風の作りです。 いくつか、自分の経験にカブるシーンがあったので、サクサク読めました。 今までの自分になかった考えである「箱」という視点が得られたのがよかったです。\nただ、いくつか気になる点もあるので、また少し時間を開けてからサラっと流し読みしたいと思います。\nあと、すこしだけ、キリスト教チックな考え方でもあるかなぁと思う部分もありました。（キリスト教をちゃんと勉強してるわけではないので認識が間違ってるかもしれないです）\n人によっては共感出来なかったり、読みにくかったりすると思いますが、私は面白いと思った本でした。 なんとなく、人間関係に違和感を感じていることがある場合は目を通してみるといいかもしれません。\nTwitterで読み終えたというツイートをしたら、「自分を変える気づきの瞑想法」を読むとまた面白いですという＠ツイート（これがmentionの日本語の正式名称らしい？）を@ledsunいただきました。 箱に入る原理が別の視点で書かれているようです。 読んでみたいです。（本会過ぎてる気がするので、図書館で探そうかなぁ。。。）\n自分を変える気づきの瞑想法【増補改訂版】 自分を変える気づきの瞑想法【増補改訂版】 ","date":1332253920,"dir":"post/2012/","id":"ee623aaa99b429863f89da313fffed97","lang":"ja","lastmod":1332253920,"permalink":"https://blog.johtani.info/blog/2012/03/20/%E8%87%AA%E5%88%86%E3%81%AE%E5%B0%8F%E3%81%95%E3%81%AA%E7%AE%B1%E3%81%8B%E3%82%89%E8%84%B1%E5%87%BA%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-03-20T23:32:00+09:00","summary":"TLで面白いと見かけて、Amazonで買ってしまいました。 SEやってるのに、つい最近Amazonを使い始めた軟弱者です。 それにしてもAmaz","tags":["読書"],"title":"「自分の小さな「箱」から脱出する方法」を読みました。(Jugemより移植)"},{"contents":"えーと、ブログ更新してないなぁとふと思ったので。 １年前くらいからずーっと、つぶやいてましたが、やっとScalaを始めました。 長かった。。。 とある、サンプルデータを作成するので、ついでにScalaを勉強してしまえという感じで始めました。\nScalaで学ぶ関数脳入門を買ってもう１年以上経ってました。。。 とりあえず、CSVデータからInsert文を作ってます。 書籍を見ながら、四苦八苦してるところです。 今日は、csvファイルを読み込んで適当に出力した所で終了でした。 現状を忘れないようにというのと、いくつか気になった点があったので、備忘録のため上げておきます。\nscala IDE for Eclipseを利用（もっさりしてる） classとは別にobjectというものがある点に慣れない セミコロンいらないのに、ついつい打ってしまう usingを利用しようとしたが、Eclipseに怒られた（なんで？） メソッドの戻り値を省略出来る場合とできない場合がよくわかってない Javaが混ざる（ファイル出力にBufferedWriterを使う）のがまた戸惑う ということで、四苦八苦してますｗ ７つの言語、７つの世界も参考にしつつ、コップ本をパラパラしながら、ググって書くといった感じです。 Javaだととっくにできていると思うのですが、まだ、読み込んで出力できただけです。\n新しいものに触れるのは頭を使って面白いのですが、思い通りに行かず（とくにIDEがもっさりしてたり、上手く使えなかったり）イライラもしていますｗ まぁ、ちょっとずつ勉強していきます。\n（ほかにもいろいろやらないとなぁ。。。）\nScalaスケーラブルプログラミング第2版 Scalaスケーラブルプログラミング第2版 ","date":1331652421,"dir":"post/2012/","id":"116c9be6d760b4befa6d51ce9e96604c","lang":"ja","lastmod":1331652421,"permalink":"https://blog.johtani.info/blog/2012/03/14/scala%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-03-14T00:27:01+09:00","summary":"えーと、ブログ更新してないなぁとふと思ったので。 １年前くらいからずーっと、つぶやいてましたが、やっとScalaを始めました。 長かった。。。 と","tags":["Scala"],"title":"Scala始めました(Jugemより移植)"},{"contents":"森ビルに行ったことなかったので、参加してみました。 あと、最近まともにコーディングしてないので、そのへんを矯正するためにもと思って。 （まぁ、遊びに行きたかっただけなんですけどね）\nすこし遅刻して参加です。 会場は、Twitter Japanさんの@yakitoriでした。ここだけ、撮影可でした。 で、肝心のハッカソンの中身です（ハッカソン自体、初参加！）。 Twitter APIもTwitter4Jも触ったことがありません。 なので、ソファーに座ってMac Book AirでTwitter4Jのサンプルを眺めながら、とりあえず、Solrに流しこむってのを作ってみました。 今回、Solrに用意したのはlucene-gosenによる形態素解析を行うフィールドとあとは、Solrのexampleについてるダイナミックフィールドたちです。 Twitter4Jからどんなデータが取れるかわからないので、ダイナミックフィールドで型だけ指定してSolrを起動しておきます。 次に、Twitter4Jにあるsample()にてパブリックなツイートの1%を取得（適当なのがこれくらいしか思い浮かばなかったから）。 あとは、SolrJのStreamingUpdateSolrServerを利用して、流し込みです。 あんまり時間がなかった（準備とかウォーミングアップで時間かかった）ので、結局、Screan名とツイート本文を SolrInputDocumentに無理やり詰め込んで登録しただけでした。 ほかにも色々と情報が取れるはずなので、そのへんも格納してファセットとかで遊びたかったなぁ。 とまぁ、こんな感じでタイムアップです。（コードは大したことないので文章だけでｗ） 画面も用意出来なかったので、発表はSolrのダサい管理画面で検索でした。 次回は、もう少し中身を勉強して画面もbootstrapで作ってとかやってみたいですね。 あと、自己紹介スライドに書きましたが、Scalaから使ってみるのもやってみたいです。（その前に、Scalaに入門しないといけないんですけど。。。）\nということで、個人的にいろいろと反省点があるハッカソンでした。 反省点：\n立ち上がりに時間がかかった（普段からコーディングしてないから） Twitter4Jについて事前に勉強してない（ごめんなさい） 環境面が整備しきれてない Twitter API ポケットリファレンス（右の本）を忘れた。。。 スターウォーズのピザの箱の写真取り忘れた＞＜ 普段、コーディングをしていない仇が出てしまいました。 もっと、すぐにコーディングをできる環境、体質を日頃から鍛えておかないといけないなぁと。 （SolrやTwitter4JのJavaDocをオロオロしながら探すとか情けないです。。。）\n場所や雰囲気は全然問題ありませんでした。 ピザを@yusukeyさんからごちそうになったり、飲み物、お菓子が用意されていたりと至れり尽くせりでした。 iPadで音楽も流してくれてたし。 他のハッカソンに参加したことないので比較はできないですが、集中できてよかったです。 あと、ソファーでコーディングもなかなかいいなぁと実感出来ました。（初めて！） 人数的にもこのくらいのほうが話がしやすくていいかなぁと。発表も時間かからないですし。 ただ、帰り道に誰かが言っていましたが、「マラソンというよりは短距離走だったね」というのは否めないかなぁと。 時間は限られちゃうので、準備をしっかりしないとなぁと。 私としては、土日のハッカソンだと参加しづらいので、平日開催がうれしいのですが。 いやぁ、楽しかったです。みなさんの面白いネタも見れたし。（自分のやったのは普通すぎて少し恥ずかしかったです。。。） あと、GoogleDocsの使い方（自己紹介スライドとかアンケートの集計とか）も学べたのが収穫でした。 @yusukeyありがとうございます！ 次回もありそうなので、懲りずに参加しようかな。\nさて、他の方たちのブログやtogetterは@yusukeyさんのページからたどってくださいｗ。 第0回Twitterハッカソンを開催しました #twtr_hack\n今日購入したCD聴きながらブログ書いてます。 タワレコで視聴して購入したCDです。 なかなか大人な雰囲気でオススメです。 Heaven ","date":1331230200,"dir":"post/2012/","id":"4d6c95b0b3ea2ddb30fdd3edf3b82391","lang":"ja","lastmod":1331230200,"permalink":"https://blog.johtani.info/blog/2012/03/09/%E7%AC%AC0%E5%9B%9E-twitter-hack--twtr_hack-%E3%81%AB%E9%81%8A%E3%81%B3%E3%81%AB%E8%A1%8C%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-03-09T03:10:00+09:00","summary":"森ビルに行ったことなかったので、参加してみました。 あと、最近まともにコーディングしてないので、そのへんを矯正するためにもと思って。 （まぁ、遊","tags":["勉強会"],"title":"第0回 Twitter Hack #twtr_hack に遊びに行きました。(Jugemより移植)"},{"contents":" Clean Coder プロフェッショナルプログラマへの道 Clean Coderを読みました。 理由はTwitterで「Clean Code」がいい本だと流れてきたためです。 「Clean Code」はまだ読んでいないのですが、クリーンなコード（メンテナンスしやすく、修正などもやりやすいコード？）を書くために必要な話が書いてあるのだと思います。（まだ妄想）\nそして、何も考えずに、「Clean Code”r”」という本が新しく出ていたので、新しい方に手を出しました。 まぁ、軽い勘違いですｗ（コードの構造の話などは出てこなかったです。） それほど分厚くなく、軽く読めそうだということで読み進めると軽い衝撃を受けました。 Clean Coderはプロのプログラマとして、どのような意識を持つべきか、立ち居振る舞いをするべきかなどが書かれています。 「～したい」はまず守らない約束だという話、ユニットテストを書くことはプロとして当たり前の行為だ、目的意識を明確に持つことなどなど、耳の痛いことが色々と書かれています。 これは、著者の方（パンチカードのころからコーディングをされている！）の実体験を元に、失敗した経験から導きだされているようです。 ところどころ、古くてよくわからない話やちょっとだけしっくりこない表現（ビジネス、QAといった単語）もありましたが、概ねわかりやすい話でした。\n基本的にはアジャイルなスタイルの開発を行うプログラマ（設計書に基づいてコーディングするだけの人ではない）について書かれています。 この本を読んでいて、昨年、仕事をご一緒させていただいたRubyistの方たちの開発スタイルを思い出しました。 私よりもこの本に書かれているプロに近いなぁと。 ペアプロやったり、実装方法について相談していたりと。\n勘違いでしたが、良い本に出会えて本当によかったです。 私もこの本に書かれているようなチームでのプログラミングをやりたい、またなにかコーディングをしたいという気にさせてくれました。（「～したい」じゃダメって書いてあったのに。。。） 自分を戒めるためにも、定期的に読み返したい本です。 プログラマでいたい方、ある程度プログラミングができるようになってきた方にはぜひ読んでいただきたい本です。 （この流れで、アジャイルサムライやClean Codeを読んだら理解が深まりそうだなぁ）\n参考URL： 35歳定年説をブチ破れ！「Clean Coder プロフェッショナルプログラマへの道 Robert C. Martin」 - ledsunの日記 ","date":1330704840,"dir":"post/2012/","id":"10eb415a232ad4be7d05c57eb850036c","lang":"ja","lastmod":1330704840,"permalink":"https://blog.johtani.info/blog/2012/03/03/clean-coder%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A0/","publishdate":"2012-03-03T01:14:00+09:00","summary":"Clean Coder プロフェッショナルプログラマへの道 Clean Coderを読みました。 理由はTwitterで「Clean Code」がいい本だと流れてきたためです。","tags":["読書"],"title":"Clean Coderを読んだ(Jugemより移植)"},{"contents":" 親子で楽しめる 絵本で英語をはじめる本 Twitterでこの本について書かれたブログ記事が流れてきて、購入しました。\n最近、英語を身につけておいたほうがいいなと思うことが多々あり、子供にも英語を勉強してもらいたいなと思っていたところでした。 あとは、私自身が英語が苦手というのもあり、子供をダシにして勉強したいというのもありまして。。。 サラっと読んでみましたが、参考になりました。 特に「多読」というキーワードが面白かったです。こちらが元のようですが。 多読とは、文章を分析しないで大意を把握する読書法だそうです。\n辞書を引かずに楽しめるものを読む わかるところをつなげて読む 自分が面白いと思う本を選んで読む という原則があるようで、確かにいいなと思いました。 絵本だと絵が書かれているので、辞書を引かなくても想像できそうですし、楽しめそうだなぁと。 また、多読は先日読んだ、速読の本に書かれていた本の読み方にも通じるものがあるなと。（まだ、実践できてないんですけどね）\nどうしても英語を勉強させたい！、勉強しないと！と思ってしまいがちですが、この本にも書いてあるように楽に楽しんでやったほうがやっぱいいなぁと。 楽しくないと続かないですからねぇ（実際、何度も挫折してるし、押し付けられるとヤル気がなくなるので。。。）\nということで、実践してみようと思います。（平日は子供が寝てしまってから帰宅なので、まずは土日から）子供のためというよりは、自分の英語の勉強のために。 まずは、簡単な絵本を購入して。 この本の後半半分は、著者の方の感想や説明がついた、オススメの絵本50冊が書かれています。 英語の絵本を入手するのは、結構大変（実際に売ってる店もなかなかないし、手にとって見る機会も少ない）だと思うのですごく参考になりそうです。 いくつかピックアップして、あわよくば本屋で手にとってみようかと。なければ、Amazonで購入しようかなぁと思ってる所です。\n","date":1330186800,"dir":"post/2012/","id":"627a0c45dd07150343c81d856855590e","lang":"ja","lastmod":1330186800,"permalink":"https://blog.johtani.info/blog/2012/02/26/%E8%A6%AA%E5%AD%90%E3%81%A7%E6%A5%BD%E3%81%97%E3%82%81%E3%82%8B-%E7%B5%B5%E6%9C%AC%E3%81%A7%E8%8B%B1%E8%AA%9E%E3%82%92%E3%81%AF%E3%81%98%E3%82%81%E3%82%8B%E6%9C%AC/","publishdate":"2012-02-26T01:20:00+09:00","summary":"親子で楽しめる 絵本で英語をはじめる本 Twitterでこの本について書かれたブログ記事が流れてきて、購入しました。 最近、英語を身につけておいた","tags":["読書"],"title":"親子で楽しめる 絵本で英語をはじめる本(Jugemより移植)"},{"contents":"今週も勉強会に参加しました。 @yusukey さんが開催してるTwitter API勉強会です。 前回とは会場が異なりましたが、広くて大画面で良い会場でした。駅も近いし。（デジタルハリウッドさいこー！） 今回はLT枠のbootstrapの話が聞きたくて参加しました。（ムチャぶり駆動勉強会の現場をTLで目撃してたのでｗ） あと、バーチャファイター（昔、VF目当てでセガサターンを買ったなぁ、懐かしい）の話も聞きたかったので。 （ごめんなさい、Twitter APIはまだ触る機会がなさそうです。。。） 今回も途中で参加者同士を数グループ（座席が近い人）に分けて自己紹介タイムがあり素敵でした。 ちょっと残念だったのはネームプレートが今回はなかったことでしょうか。 自己紹介でツイッターID教える＋聞くのがちょっと辛かったです。（やっぱり個人名刺作ったほうがいいかなぁ） 私はPCを開いていたのでTwitterのページを見せることで対応出来ましたが。 （次やるときはお手伝いするのでこえかけてください。）\n内容はメモをとってあり、下に書いてますので見ていただければ。\nTwitter APIの説明はいろいろ新鮮でした。今回はWebページに貼るリンクやボタンの話でした。 カスタマイズも出来るようになってるってのは知りませんでした。Webサイトやってる人は簡単にカスタマイズできるのは便利ですよね。\nバーチャファイターのTwitter連携の話は結構詳細な話が出てきてびっくりでした。（テーブル名とかまで出てきましたｗ） ゲーム筐体の前のユーザの動きまで考えてシステム作るとかすごいなぁとか。違う業界の話って面白いです。\nBootstrap入門はbootstrapの紹介だけじゃなく、Tips（bootstrap弊害とかw）やその他の便利なサイトの紹介までありました。 スライドもあとから読んでもわかるのがすごく嬉しいです。時間を見て試してみます。 TwitterSphereは懇親会でもデモが見れました。Groovyは名前を知ってるだけだったのですが、Swingとかまで動くんですね。（JVMだから当たり前なんだけどなんか新鮮。） 最後はAndroidのAPI Demoのお話。こちらも普段Android携帯使ってるのに知らないことが多くて。。。 Macでもデモが動くんですね。やっぱり動くものを作ってLTするのって素晴らしいですねぇ（なんか作るかー）\nとまぁ、最近はキーワードだけ知ってて、いろいろ触れてもいないものが多いなぁと思ってたところに、 今日の勉強会で色々見れて面白かったです。 Twitterがいろんな人に興味を持たれているのがわかります。 （けど、Twitterってどうやって儲かってるんだろう？？？） 懇親会は、入り口からは想像できない貸パーティースペースで素敵でした。 開始の乾杯の音頭を取ることもできましたし（もちろん、ムチャぶり）。 学生が多かったのですが、声をかける暇なく懇親会が終わってしまったのが少し心残りですかねぇ。 毛色が違うメンバーが居て面白いので、次回も空きがあれば参加しようと思います。 スタッフとかお手伝いもしますので。\nということで、いつものメモです。\n開催日時：2012/02/23 19:00 ～ 21:00 場所：デジタルハリウッド東京本校 1Fセミナールーム Zusaarのページはこちら。他にも学生枠とかありました。\n◯ Webサイト向けAPI @yusukey\n・Webサイト向けAPI フォローボタン、ツイートボタン、Web Intents、@Anywhere サーバサイドの実装扶養、htmlのみで構成可能 ・Twitterボタン Twitterのサイトで色々カスタマイズ可能なボタンが作れます。 ツイートのカウント表示とか。 ・Web Intents @ツイート、リツイート、お気に入りが簡単にできるものが作成可能。 ツイートの埋め込み用リンクがTwitterのWeb版のツイート詳細から生成可能。 「このツイートをサイトに埋め込む」リンクをクリックするとダイアログが出てきます。 ・@Anywhere あんまりフォローされてないけど、JavaScriptでサーバサイドなしにTwitterと連携可能。 ユーザIDを辞書的に検知してTwitterの情報をホバーで出してくれる。 ・ウィジェット（検索、プロフィール、お気に入り、リストなど） これもTwitterサイトでカスタマイズ可能。 ・ツイートボタンには公式ロゴを利用しましょう ・注意点 charsetを必ず指定しましょう。 IE/Firefoxで問題が発生します。 ◯ グルーブに分かれて簡単に自己紹介\n◯ デジタルハリウッドよりご挨拶\n◯ 「Virtua Fighter5 Final ShowdownのTwitter連動機能について」@twtrfk\n部内にAmitterというSNSを構築して自由に使ってもらって、Twitterを疑似体験してもらった。 VF5FSでの開発中はTwitter4JにAmitterのラッパーを追加してテストしてたらしい。（おもしろいなー） 当時は、筐体にツイート機能を入れることも考えていたらしい。 ツイート自体はバッチで処理してます。 ゲーム筐体にお客さんが座ってる時間もシステムの性能として考慮しないといけない。 苦労した点： テストアカウントを100個地道に作成（連番、内容がバレるアカウント名はNGだから） Twitter4Jがうまく動かなかった。。。 今後の展開： まだ未定 QA Q：FB連携とかは？ A：今は考えてないです。 ◯ LT ・ @making「Twitter Bootstrap入門」 スライドはこちら\n・Bootstrapとは？ Twtter者が提供するWebアプリケーションのフロントエンド 一般的にCSSフレームワークと呼ばれるもの 簡単にかっこいいデザインにするための枠組み ダウンロードしてきてHTMLで読み込むだけ。 ・Bootstrapのコンポーネント紹介 いろいろおしゃれなコンポーネントあるよ。（スライド見ましょう） ・Tips examplesがあるので、それをベースに作るのが簡単です！ Initializrも対応してて、こっちで作るのもいいよ！ bootstrap簡単すぎて、みんな同じデザインのサイトに（弊害） 差別化のサービスが出てきてます。 ・ @kimukou_26 「TwitterSphere of Twitter4J」\nGriffon？ codehausで作られてるGroovy製のMVCイメージのGUIフレームワーク codehausはJetty作ってるとこですね 地球儀にツイートを乗っけることができるアプリ。 Groovyの記述がちょっと新鮮。 ・ @bina1204 「ApiDemos of Twitter4J for Android」\nAPI DemosというAndroidのデモがあり、ここにTwitter4Jを仕込んでみた？ Android系は持ってるのに知らない。。。 ","date":1330015800,"dir":"post/2012/","id":"966fe8d32b86121f8a465a21b95f7e5c","lang":"ja","lastmod":1330015800,"permalink":"https://blog.johtani.info/blog/2012/02/24/%E7%AC%AC4%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E3%83%8F%E3%83%AA%E3%82%A6%E3%83%83%E3%83%89--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-02-24T01:50:00+09:00","summary":"今週も勉強会に参加しました。 @yusukey さんが開催してるTwitter API勉強会です。 前回とは会場が異なりましたが、広くて大画面で良い会場でした。駅","tags":["勉強会"],"title":"第4回 Twitter API勉強会 @デジタルハリウッド #twtr_hack に参加しました。(Jugemより移植)"},{"contents":"久々にlucene-gosenの話です。 しかも、あんまり嬉しくない話しです。\nすでにissueをアップしていますが、lucene-gosenとSynonymFilterを併用する場合に、特定の条件下でNullPointerExceptionが発生してしまいます。\n条件は以下の組み合わせになります。\nSolr 3.5.0以前 lucene-gosen1.2.0 - 1.2.1の辞書なしjar SynonymFilterFactoryにてtokenizerFactoryを指定 根本的にはSolr側の問題のようです。SOLR-2909としてissueが上がっています。\nSynonymFilterFactoryでは、類義語の設定ファイルの単語を読み込むときにtokenizerFactoryを指定できます。 このとき、SynonymFilterFactory内部でtokenizerFactoryに指定されたFactoryのクラスが読み込まれ、 インスタンス化されて、Tokenizerが作成されます。 この、Tokenizerのインスタンス化の処理シーケンスに問題があります。 schema.xmlの\u0026lt;tokenizer\u0026gt;タグで指定されたTokenizerFactoryでは、ResourceLoaderAwareインタフェースのinform(ResourceLoader loader)メソッドが実行されます。 このinform()メソッドがSynonymFilterFactoryのToeknizerのインスタンス化の場合に実行されません。 lucene-gosenのJapaneseTokenizerFactoryではこのinform()メソッドでdictionaryDirのパスの読み込みを行なっています。（このへん）\n上記の条件では、NullPointerExceptionが発生すると書きました。 辞書を内包したjarファイルを利用している場合、NullPointerExceptionが発生しなくても次のような問題点があります。こちらの問題は見た目は動いているように見えてしまうので注意が必要です。 すべて、SynonymFilterを利用する時点でも問題点になります。\ncompositePOS設定が類義語辞書読み込み時に無効 dictionaryDir設定が類義語辞書読み込み時に無効（＝jarに内包されている辞書で動作する） 一見動いているように見えるかもしれませんが、望んでいてる動作になっていない可能性があるので注意が必要です。\n解決策（まだ途中） 先程書きましたが、基本的にはSolr側の修正をするのが妥当です。 SolrのJIRAにパッチもアップされました。 こちらのパッチをSolrに適用し、SynonymFilterFactoryを次のように指定することで問題を回避することが可能になります。\n\u0026lt;tokenizer class=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; compositePOS=\u0026#34;compositePOS.txt\u0026#34; dictionaryDir=\u0026#34;dictionary/naist-chasen\u0026#34;/\u0026amp;gt; ... \u0026lt;filter class=\u0026#34;solr.SynonymFilterFactory\u0026#34; synonyms=\u0026#34;synonyms.txt\u0026#34; ignoreCase=\u0026#34;true\u0026#34; expand=\u0026#34;true\u0026#34; tokenizerFactory=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; **compositePOS=\u0026#34;compositePOS.txt\u0026#34; dictionaryDir=\u0026#34;dictionary/naist-chasen\u0026#34;**/\u0026amp;gt; ... SynonymFilterFactoryの設定にcompositePOS、dictionaryDirを追加します。 ここの設定は\u0026lt;tokenizer\u0026gt;タグで指定された設定と同じ物を指定します。以上で問題なく動作することになります。\nただし、この方法はSolrにパッチを当てなければいけません。 Solrにパッチを当てるのもなかなかな作業だと思います。 ということで、どうにかlucene-gosen側だけでも対応出来る形にしたいなぁと考えているところです。 残念ながら、まだ考えているだけですので、もう少し提供できるのは先になってしまいますが。。。 現時点では、次の方法を考え中です。\ninformメソッドを呼ぶフラグを追加して、どうにかしてinformメソッドを呼び出す SynonymFilterの修正版をlucene-gosenに内包して提供する できれば、a.にて対応できればと思っています。 最悪、b.の方法かと。 悩んでいる間にSolrの次のバージョンが出てしまわないように出来るだけ早く対応しようと思っています。 他にも問題点や気になる点があれば、日本語、英語を問わないので、気兼ねなくissueに上げてもらうか、Twitterで私宛にメンションしてもらえればと。 （あ、issue23へのパッチでもいいですよ！）\n追記： まだ、SOLR-2909のパッチを適用してからの確認はできていません。（ソース見て大丈夫だと思ってるレベル） あと、現時点での対応方法としては、「lucene-gosenとは別のjarにSynonymFilterFactoryなどを入れて提供」が妥当かなぁと考えているところです。（無理やりinformメソッド呼び出すのは骨が折れそう＋パッチが思いの外早く出て、導入されたのでlucene-gosen本体に特殊処理を入れるのはあまりメリットを感じない。）\n","date":1329756060,"dir":"post/2012/","id":"4e7b945feca199bd486653fea1d0e39c","lang":"ja","lastmod":1329756060,"permalink":"https://blog.johtani.info/blog/2012/02/21/lucene-gosen%E3%81%A8synonymfilter%E3%82%92%E5%88%A9%E7%94%A8%E3%81%99%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AE%E6%B3%A8%E6%84%8F%E7%82%B9%E5%95%8F%E9%A1%8C%E7%82%B9%E7%B7%A8/","publishdate":"2012-02-21T01:41:00+09:00","summary":"久々にlucene-gosenの話です。 しかも、あんまり嬉しくない話しです。 すでにissueをアップしていますが、lucene-gosenと","tags":["lucene-gosen"],"title":"lucene-gosenとSynonymFilterを利用するときの注意点（問題点編）(Jugemより移植)"},{"contents":"また、勉強会ログです、すみません。。。 直接業務とは関係ないのですが、今回はリクルートの中野さんが話しをされるというので顔を出してきました。 もちろん、内容も気になりましたというのもありますが。 実際には中野さんは2分くらいしか喋らなかったんですけどね。。。\n今回は、最初のセッションはちゃんとしたソースコードリーディングでした。 Hadoopの入力としてデータをHDFSじゃなくて、MongoDBから取得するときに利用するMultipleInputの実装をしてみたというお話でした。 MongoDBやHadoopを知らないと（私はあんまり知らない。。。）少しきつかったかもしれないです。 幸い、HadoopのMultipleInputについては以前、すこしだけ見たことがあったので、かろうじてついていけました。 最初の部分を聞きのがしてしまったので合っているか自信がないのですが、10genから出ているmongo-hadoopの使い勝手、効率の悪そうなところに手を入れた話しがベースになっているんでしょうか？（ツッコミあるとうれしいです） 気になったのは、MongoDBのデータをHadoopから直接取りに行くというユースケースがどういう場合に出てくるのかという点です。 ネットワークやMongoDBの負荷がHadoop処理へのボトルネックになるんじゃないかしらという懸念がありそうだなと。 発表を聞いていて感じたのは、やっぱりソース書いて動かさないとダメだよねぇ、自分も手を動かそうというところです。 リクルートさんの発表は波乱万丈（？）でした。 最後まで話しを聴いたあとに思った感想は「こんなに話して大丈夫なのかな？」「いろんな人を敵に回してない？」というものです。 実際に昨年の夏くらいからEMCの草薙さんも検証メンバーに入って、リクルート社内での活用シーンをベースにMapRの検証をいろんな項目でやられたようです。（ある程度の詳細は以下のメモ参照） で、最終的な結論はまだ出ていないのですが、最後に出てきた検討中の比較対象が某C社のCDH。 どちらかというとCDHの方に傾いてる感じに取れる終わり方で心配になりました。。。 会場が会場だからというのもあったのかなぁ？ mesosというキーワードが出てきたのが気になりました。単語だけは以前Twitterで流れてきたのを目にしてたのですが、どんなものかという概要がわかったのは収穫でした。 リクルートさんの資料はどこまで公開されるかわからないですが、もう一度見たい気がします。（mesosの部分だけでも公開して欲しい）\nということで、以下はいつもの自分用メモです。\n日時： 2012年2月8日（水） 19:00～21:30 （受付開始 18:40） 場所： 豊洲センタービルアネックス（NTTデータ、豊洲駅直通）\n◎日本OSS貢献者賞・奨励賞のご案内　@hamaken 日本OSS貢献者賞・奨励賞\n◎『オレオレMultipleInputを作る方法（仮）』@muddydixon さん http://www.slideshare.net/muddydixon/multipleinput\nhadoopからMongoDBを利用する方法を紹介 CDH3u2かu3で試しました。 10genからも出てるけど使いにくい？から作った？ MongoMultipleInputs.addInputPath で色々簡単に使えるようにしたかった。 絞り込みしてデータをMapperにとり込みたかったため。 ＝絞り込みできないと必要なデータ以外も取得できてしまいJSONのパース処理がオーバヘッドになるから。 com.mongodb.hadoop.input.DelegatingInputFormat mongodbの環境にあわせて多くのsplitを生成する。 mongosへのアクセスはメタ情報の取り出しだけ。 あとは、個々のサーバにアクセスしてるのでデータ取り出しが高速？ ◎『MapRってどうよ？ - 実際に使ってみた感触を紹介します』 - リクルート 中野さん、高林さん、大坪さん\nMapRの説明資料がなかったので、EMCの草薙さんが出てきて説明を開始。 Greenplum MRはMapRテクノロジが開発した実装のOEM版。 EMCは特に手を加えず。 ※MapRについては前回のMapR勉強会の記事を御覧くださいな。 Q：JavaのAPI互換と言われている部分はHadoopのどのバージョン？ A：CDH3u2に近いパッチが当たってるらしい。 Q：DFSIO性能の比較対象のHadoopはどのバージョン？ A：手元に資料は残念ながらないです。 ここからリクルートさん。 検証内容：性能検証 中古車サイトで利用されている3つのHiveに置き換えてみた。 結果（パーティション圧縮） MapRのほうが約1.3倍高速に（そこまで速くならなかった？） 結果（非パーティション圧縮） MapRのほうが約1.7倍高速に（そこまで速くならなかった？） ビルドイン圧縮はGzip圧縮と比較して高速 ※チューニング次第では結果変わるかもね。 機能検証：マルチテナント検証 目的： 複数ユーザに対して1つのクラスタを提供する セキュリティの担保（） 余剰リソースの有効活用 複数ユーザのJobの並列実行？ 結果１（ユーザ権限まわり） MapRのユーザはLinuxユーザに準拠。 同じmaprユーザでもUIDがずれてるとエラーが起きる。 MapR内のPermissionは内部のクラスタ、ボリュームの権限定義が可能 ※Volumeは管理者に付加的な情報を与えるような存在 Job実行はHadoopと一緒のアクセス権。 結果２（FairScheduler） MapRではデフォルトとなっている。 複数テナントからの同時ジョブ実行の動作を確認。 poolをベースにタスクを割り当ててく。 min/max値にあわせてslotが利用される模様 結果３（Load処理（Hive）、Job実行（HiveのSelect）） じゃらんPVデータ１ヶ月分をロード。 NFS→MFS 結果４（フェイルオーバー） HA機能 ノード切り替え時間、タスクの復旧までの時間とか。 結果５（DirectNFSでの転送） NFSGatewayをクライアント側にした場合との違いなど。 クライアント側に載せた場合、通信量が減るから速度が出てる。 Mesos概要 Apache IncubatorのOSS。C++により実装 効率的なリソース分離、リソース共有機能を提供するクラスタマネージャ。 Mesosでの検証 マルチテナント（ユーザ権限）硬い。 リソース制限ができない。などなど。 MapRとMesosの比較 資料期待！ リクルートとしてのMapRの評価 保守/サポート/教育が充実してるのが重要。速度だけじゃない。 けど、まだ検討中です。 Q：クラスタに対するパーミッションの権限情報はどこで管理されてるの？ どこが落ちたときにそのパーミッションの情報がとれなくなる？ A：CLDBで管理されてます。 Q：CLDB内部でのデータはバイナリ？DBを別途持ってる？ A：HDFS上にボリュームが作られてそこに吐き出されてる。 Q：Jobのスケジュールの情報とかはどこに？ A：Job管理データはJobTracker用のボリュームに保存されてる。 それを別の人が引き継ぐ。 Q：ボリュームが壊れたら？ A：さすがに壊れたら引き継げない。 けど、壊れにくくしてあるのが売り？ Q：MapRのチューニングのポイントはどんなものがあるの？ A：チューニングに関しては256Mのchunkサイズを64Mに減らした場合の化粧しかしてない。Apache Hadoopの方は若干チューニングした。 Q：DFSのシリアライズは？ボンディングとかでもできるんじゃないの？ A：そこはやってないのでやってみます。 Q：MapRでの8台構成で全部のせてみた場合、CLDBのリソースはどのくらいもっていってるの？ A：結構使ってる。CLDBを3台以上にしたらサポート対象外。 Q：CLDBを3台に制限してる理由は？ A：わからない。 Q：本番MapR、検証CDHというのはあり？ A：M3を開発環境で利用して欲しいですね。（ステマ？）開発目的だとM5を無償提供してほしいなー（EMCへのお願い？） Q：Pigの検証は？ A：リクルートではHiveを利用してたので検証してない。 次回は3月ころかなぁ？だそうです。 ","date":1328716980,"dir":"post/2012/","id":"fa16213d24273d386d22332cd01ce774","lang":"ja","lastmod":1328716980,"permalink":"https://blog.johtani.info/blog/2012/02/09/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/","publishdate":"2012-02-09T01:03:00+09:00","summary":"また、勉強会ログです、すみません。。。 直接業務とは関係ないのですが、今回はリクルートの中野さんが話しをされるというので顔を出してきました。 も","tags":["勉強会"],"title":"Hadoopソースコードリーディング第8回に参加しました。#hadoopreading(Jugemより移植)"},{"contents":"Fluentd meetup in Japanに参加しました。いつも面白そうな話を聞いてばっかりなので、役に立つためにスタッフとしても参加してみました。 まずは、会場が綺麗でびっくりしました。しかも電源タップまで用意されていてかなり充実してました。Ustはまだ見ていないのですが、Ustも録画までされていて素晴らしい運営メンバーでした。\n開発者の古橋さんほか、Treasure Data Inc.の方たち（太田さんはいなかった）が集まり、 Fluentdの仕組みから、プラグイン開発の方法、実際にプラグイン開発してしかも本番で利用してる実例まで 「パーフェクトFluentd」という本ががそのまま書けてしまうのではというくらい密度の濃い話が聞けました。 私個人は、いつものごとく興味を持ってるんだけど、仕事、私用では触っていないという腰抜けなので話についていくのが大変でしたが。。。 各セッションごとに、しっかりとしたQA時間が取られていて、質問者も質が高く、中の人や発表者の方も誠実に回答されている感じがすごく良かったです。 （残念ながらLTの時は懇親会の準備を手伝っていたので聞けてないです） 基本はログの中継サーバとして利用するという話でした。 個人的には性能系のデータやログ（遅いクエリのログに関するプラグインの話などもあった）をストレージに保存して、時間を軸にログとグラフを表示するとかいう仕組みに使うと面白いかもなぁと感じました。 今回はFluentdがメインなので、ログを集める部分の話が主だったところでしたが、懇親会直前の@doryokujinさんのスライドでも上がっていた集計後のビジュアライゼーションに関する部分のはなしも聞いてみたいなぁと思ってるところです。\nあとは、いくつか知りたかったことが。 Treasure Data Serviceというサービスをやってるみたいで、SQLライクな問い合わせやビジュアライゼーションされた画面があるみたいな話があがっていたんですが、画面が見てみたかったです。 また、@just_do_neetさんの構想図のその後を聞いてみたいですねぇ。\nそれにしても実例も構成から性能値まで上がっていたので、実際に利用する場合に参考になる資料だらけで普及にはずみがつきそうです。 Ust録画が上がっているようなので復習したいと思います。 （あ、内容とは関係ないけど、Ust録画にハッシュタグつきのツイートを時間軸で重ねて表示するサービスとか機能ってないのかな？）\nということで、以下はいつものメモ書きです。\n2012/02/04 12:30 ～ 19:00\nフューチャーアーキテクト セミナールーム\n参考URL：http://fluentd.org\n◎13:00～14:00 「What\u0026rsquo;s Fluentd? - The missing log collector」 http://www.slideshare.net/treasure-data/fluentd-meetup-in-japan-11410514 Treasure Data, Inc.　古橋 貞之 (@frsyuki)\nまずは、Fluentdの概要。syslogdみたいなもの Fileのtailで流すことが基本。 Clientライブラリから流すことも可能。 他との比較 ScribeとFluentd 構造化されたデータを扱う gemとかapt-get，yumでインストールあg可能 Rubyで書かれてるからカスタマイズもプラグインの追加も簡単。 FluentdとFlume FlumeはZKやマスタノードが必要＝セットアップが面倒 JVMだから面倒、設定も簡単。 Fluentdのアーキテクチャ Bufferプラグイン：スレッドセーフ、バッファ処理など Outputプラグイン：出力だけ out_forwardプラグイン：Cassandraと同じアルゴリズムでHeartBeatしてる out_copyプラグイン：同じ出力を別の出力先にコピー bof_fileプラグイン：バッファ先をファイルにする。Fluentdがこけても大丈夫 out_exec_filterプラグイン：外部プログラムからの入出力を使える in_tailプラグイン：ログのパーサーが内蔵されてるみたい。 開発者用API Unitテストフレームワーク（MRUnitに似てる） TailInput（パーサカスタマイズも簡単） ドキュメントとか http://fluentd.org にあります。 会社紹介！ Treasure Data Service Fluentdでは出力先がいろいろできるけど、自分で解析しないといけない ！ここで、Treasure Data Service（クラウド）に保存すると。。。 データのVisualizationとかがリアルタイムで出来る。 QA： Q：ログ転送にUDP使ってますか？ A：TCPです。UDPはハートビートに利用してます。 Q：文字コードはどういう扱い？ A：バイナリ形式であつかってます。 文字列で扱う場合はプラグインで対応しましょう。 Q：性能大丈夫？ A：Twitterで議論があがって、いろいろ対応しました。 Q：TreasureDataServiceはクラウド対応だけなの？ A：データはクラウド上で管理してるので上げても大丈夫なものだけが現在は対応。暗号化などは行なっている。 Q：TreasureDataServiceはどこで動いてる？ A：AWS上（S3にデータ保存） Q：解析プラットフォームを提供している？SQLだけ？ A：HiveのSQLで解析可能。Visualizationのツールもある。 Q：コンサルタントもあるの？ログ出力系とか。 A：あとから解析できるように。 Q：in_tailでログローテート（iノードが変わって）も大丈夫？　A：大丈夫。動かなかったら連絡ください。 Q：ファイルバッファリングされるデータの順序は保証される？ A：キュー形式なので、保証される。けど、S3とかだと出力先が遅いので、 パラレルモードで対応が可能。だけど、パラレルだと順序は保証されない。 Q：実際のシステムが投げるときにFluentd側で認証とかできる？ A：認証はないです。推奨は同一アプリサーバでFluentdを起動。 Q：Fluentd間のデータ通信のセキュリティ対応は？ A：今はない。プラグインとか作ればOK。 Q：中間層のFluentdを置くのは推奨？なしで直接ストレージ保存も可能？ A：柔軟な対応（送信先、バッファリングとか）が可能にできるように中間層を置くほうがいい。直接出すことも可能。 Q：TDAgentでのセットアップが推奨？gemは？ A：gemはOSS版でtrunkに近い。TDAgentはテストとかしっかりやってる。 バージョンの対応表はリリースノート見ないとわからない。 Q：Flumeのほうが優れているのは？ A：設定ファイルが一元管理ができる。大規模はFlumeのほうがいいかも ただし、includeでHTTPサーバ経由で設定ファイルを取得可能な機能あり。 Q：バッファサイズは指定可能？ A：可能。 Q：ストレージがずっと停止している場合にログがあふれるのを防ぎたい場合の対処法は？ A：セカンダリという機能がある。（ただし、対応できてないプラグインもある） Q：フェイルオーバーでローカルファイル出力とかはできる？ A：out_forwardは対応してる？ Q：Fluentdからのbuf_fileに出力してる部分で遅延、書き込み不可が発生したら？ A：入力と出力がスレッドで分かれてる。 入力スレッドでのエラーはinput_plugin側にException上がる ◎14:15～15:00 「Dive into Fluent Plugin」 http://www.slideshare.net/repeatedly/fluentd-meetup-dive-into-fluent-plugin Preferred Infrastructure, Inc.　Masahiro Nakagawa (@repeatedly)\n好きなプラグインとか言いましょう（発表者さん） MongoDBのプラグインをベースにプラグイン開発の説明 http://bit.ly/fluentd-with-mongo プラグイン名はfluent-plugin-xxxで統一されてます。 fluent-plugin-mongoがダウンロード数が1位に！ （scribeのプラグインがデイリーでテストが走ってダウンロード数が増えるという卑怯なカウント稼ぎしてたらしいｗ） fluentd.confの説明 fluentdの起動は以下のとおり。開発中は-vつけるといいよ fluentd -c fluentd.conf プラグインをどう作る？ Fluentdの構成図による説明 Cool.io、MessagePack、Rubyなど。 それぞれの説明を簡単に。 Cool.ioがファイル監視とかをやってくれるみたい。 プラグイン開発に関する詳細な説明 テスト、gem構成などを書いてくれてる。 QA： Q：複数行のログを扱うのはどこを作ればいい？tailプラグインの正規表現だとうまく行かなかった。 A：tailをoverrideしてparserLineを実装する。複数行のparserは難しいけどね Q：ログのアグリゲーションをやってみたいのだが、どう？CPU利用率とかを1分間バッファしてからアグリゲーションして平均出すとか。 A；fluent-plugin-aggregateってのがあって、forward-pluginを書き換えて作ってる。 TimeSlicedOutputでやると時間の期間指定とかが可能。 管理画面つくろうと思ってるので手伝ってください！@repeatedly Q：fluentd自体が処理した統計データの出力とかある？ A：古橋さんが頑張ります！協力して！=\u0026gt;@tagomoris先生が書いてる！ ◎15:15～16:00 「fluent を使った大規模ウェブサービスのロギング」 http://www.slideshare.net/hotchpotch/20120204fluent-logging COOKPAD, Inc.　舘野 祐一 (id:secondlife, @hotchpotch)\nCOOKPADでの基盤全般を見てる部署の人　PVログ＋MySQL 1日分はオンメモリにのるから高速。けど、1週間前とかになると遅くなる blackholeエンジン（MySQLの一部？）だと速い（ときどきおそくなる） データ保存でも問題 直近データしか保存できない。大きすぎて。 今後スケールしないときつくなる（1日分もメモリに載らなくなる可能性も出てくる） 他のログはMySQLへJSONでシリアライズして出力とかもしてた。 アプリでDBにログ出力はinsertのコストが厳しい。PVとかなら、1リクエスト＝1insertだけど、1リクエストで多数ログ出力とかが厳しい。 そこにFluentd登場！！！ 出力先が色々使える。（MySQL以外もOK） パフォーマンス バッファリング＋転送をやってくれるし、非同期で処理可能なのでレスポンスタイムへの影響が最小限にできてる。 安定性 プラグインはちょっと注意が必要。 バッファリングしてくれてるので、一時的に停止もできるのがうれしい。 6時間止めてもOKだったよ（テヘッｗ） 今後 PV系のログをMySQLから移行検討中 具体例！！ td-agentをrpmで入れてるし、Rubyまで入ってくれる。 構成管理はpuppetを利用してる。 td-agentの設定の注意点 「retry_limit 9」に変更してる。標準だと17なんだけど、2の16乗＝大体1日かかる。9だと大体10分くらい 中央転送用サーバ gitで設定ファイル管理してる。 よく変更するため。　gemfileで各種fluentd/pluginを利用してる。 自分たちで手を入れたソースを利用できるようにもしたいため。 テスト時にテストが書けるのが嬉しい（Rubyで出来てるアプリからもいじりやすいし、アプリのテストでも簡単に使える） ロガーへの実装追加もできる。 Tips バッファからすぐ処理させたい場合とかの説明 こんなのあったら嬉しいな。 設定ファイルの柔軟な設定記述方式 DSLにならないかなぁ（けど、やり過ぎも厳しいし。。。） ログの重要性 統計を考えられるエンジニアが重要。 どのデータにどんな価値があってそれを仕事（お金）に結び付けられるか？ QA： Q：障害対応のノウハウとか？ A：nagios、muninでサーバとか監視してる。 アラートチェックもしてる。 Fluentdの安定性は2ヶ月実際に導入してみて特に問題は出てない。 Q：MongoDBの構成は？ A：master/slave構成。PVログはS3に保存してEMRで処理。 Q：パフォーマンスの測定は？ A：40Mbit/sが処理できてたのは見てる。あとは、後ろの発表ですごいのがある！ Q：設定ミスの防止とかをどうやった？ A：今回はpuppetの設定後のリロードをチェックするような仕組みを入れた。 本来なら、データが流れてるかどうかのチェックを入れるプラグインを書いて欲しいｗ Q：データマイニングエンジニアの定義は？ A：データの価値を見いだせるエンジニア。あとは、きちんと統計学を学んできてるエンジニア。両方募集中！！ Q：DynamoDBは検討は？ A：西海岸でしか動かないのでデータ転送の時間がかかってしまった＋RESTで１件ずつ登録なので今回は見送った。スキーマレスなのでうまく使えそう。 A２（古橋さん）：バルクインポートがないので使いにくい。 Q：ログ出力の形式をFluentdにあわせて変更したとかありますか？ A：もともとアプリで出力してたから特に変更なかった。 ◎16:15～17:00　「fluentをサービスで使ってみた」 http://www.slideshare.net/naverjapan/20120204fluent-public NHN Japan株式会社　Tetsuya Ohira (@just_do_neet)\n自己紹介が面白かったｗ 実例の話。 事例１： 社内向けのログ解析に利用　Fluentd＋Hadoop データノードにFluentdで出力して、データノードからHDFSに書き込んでる。 事例２： NAVERまとめのまとめ作成者へのデータ解析 Fluentd＋Hadopo＋Azkaban Azkaban（個人的にはオススメできないｗ） flutendの負荷は全然上がってない。 監視 tcp portの監視 転送されたデータサイズのチェック。HDFS側のデータ量でチェックしてる。 なぜか半死半生の状態になった（よくわからない。） プラグインを自分で直せるので対応が楽。（Ruby力は必要だけど。） demo 準リアルタイム解析基盤の構成案（おもろそう） fluentd、MongoDB、Hadoop、Jubatus、node.js 地図にアクセス解析結果をのっけて見せる。（maptail.js？） 提案or相談： 動的に設定ファイルの内容を変更できるようにしたい log rotateのタイミングでshell実行でfluentd再起動 必要な情報だけrelayしたい フィルタープラグインみたいなものが書きたい。 fluentd自体のメトリクスを出して欲しい jubatusプラグインはー？ QA：　Q：log rotateへの対応はどーしてる？ A：今はログローテートのタイミングでfluentd再起動してる Q：Apps側のFluentdがコケたときにaccess_logをcopyしてるらしいけど、重複しないの？ A：失敗した対象のログをストレージから一旦廃棄して、再送してる。 Q：Rubyがそこまで得意じゃないのにFluentdを選んだ理由は？ A：他のモノが使いにくかった＋既存システムに手を入れなくて済む＋タイムリーだったという理由。 Q：構成案のデータの流れは？ A：MongoDB、Hadoopへは同一ログを流して、リアルタイムが重要な場合はMongoDB、大量データ回すのはHadoop？ ◎17:15～18:00 「Distributed message stream processing on fluentd」 http://www.slideshare.net/tagomoris/distributed-stream-processing-on-fluentd-fluentd NHN Japan株式会社 ウェブサービス本部　Tagomori Satoshi (@tagomoris)\nsed | grep | wc がメイン。 Hiveで集計してます。 なんでFluentd？（not Storm、Kafka or Flume?） Rubyが好き（ライブドアはJavaが入ってない環境もあるし） プラグインやTimeSlicedOutputがあるのも採用理由 ログ収集の構成図 ブログに別の勉強会の資料があるので見てください。 まだ１０日間しか動いてないので実績は少ない？ 127サーバからのログを流してる。 7万行/sec、ピーク120Mbpsが流れてる。 89 fluentd インスタンスが12ノード（4コアHT）で動いてる。 1行のログを1行のタブ区切りで出力する（Hiveでインポートしやすいから） Apacheのログに幾つか追加したデータなどが出力されてて、それをタブ区切りにするため設定一発では変換できない。 TimeSlicedOutputが重要 時刻単位でログ出力できないとキツイ（ログの流量が半端ないから） ログローテートでは時刻単位できちんと出力されてない。 ログから解析までの流れ図 以前は生ログをHadoopに書き出してたので25分くらいのタイムラグが出てしまっていた。（ノード数が少ないという理由もあるけど、お金的に増やしたくない）＋Hadoopで他のジョブが実行されてるとさらに遅くなる。。。 fluentd でログを流しながらコンバートもかけられ、Hadoopでのデータコンバートの処理遅延が少なくなってハッピーに！ ストリーミング処理の重要な点 バッチでもストリーミング処理でも同じことが可能。（out_exec_filterとHadoop Streaming） SPOFがないこと トポロジ、Fluentdの構成　ログエージェント（scribeline：お手製） pythonで書かれたscribelineというものを利用してる。 フェイルオーバーの処理（primary、secondary構成）が可能 fluentdは入れてない。（ログを拾い上げて流すだけには重い） workerノード serializerノードが必要なのは出力先の競合を減らす必要があるため。 出力先が大量のアクセスに向いてない場合があるから。 あと、ログの流れを元に監視したい項目にもここで対応可能。 watcherノード deliver、serializerからのデータを見ながら監視、統計処理を行える。 設定は自動生成してる。800行くらいになっちゃうから。 workerへの分散具合をよしなにしたいから。 remove_prefix 、add_prefixでデータの流れ先の交通整理してるのか。 GrowthForecastでグラフを出力してる。 https://github.com/kazeburo/GrowthForecast QA Q：大規模環境での移行はどうやったの？ A：もともと流すような仕組みはあって、流し先を変えたので それほど大変ではなかった。ただ、アプリ側で動いてた部分に手を入れたときは配備が大変だった。 Q：workerが1サーバ8の理由は？ A：4コアHT＝8というので8としている。 Q：deliverのカーネルパラメータをいじってたりしない？ A：ライブドア標準の設定がされてる。CentOSのデフォルトでもそれほどきびしくないかな？ Q：deliverノードでラウンドロビン＋out_forwardになってる理由は？out_forwardだけじゃだめ？ A：バッファのタイミングでの切り替えだと溢れてしまうので、最大でも1秒でラウンドロビンしてworkerを切り替える必要がある。 ※懇親会設営の手伝いのためあんまり聞けず。 ◎18:15～19:00(Plugin紹介LT)(各10分)　@shun0102: 「fluent-plugin-dstatを使ったリアルタイムクラスタモニタリング」 http://www.slideshare.net/shun0102/fluent-plugindstat\n@ixixi: 「fluent-plugin-couch」 http://www.slideshare.net/ixixi/fluent-plugins-for-couchdbamazon-sqssns\n@chobi_e: 「Fluentd \u0026amp; PHP」 http://www.slideshare.net/shuheitanuma/fluentd-and-php\n@railute:「Fluent Output Plugin for Cassandra」 https://skydrive.live.com/view.aspx?cid=D105615A0F594518\u0026amp;resid=D105615A0F594518%21333\n","date":1328367780,"dir":"post/2012/","id":"a2679a7d860a0bfb2645809ed92ce138","lang":"ja","lastmod":1328367780,"permalink":"https://blog.johtani.info/blog/2012/02/05/fluentd-meetup-japan%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-02-05T00:03:00+09:00","summary":"Fluentd meetup in Japanに参加しました。いつも面白そうな話を聞いてばっかりなので、役に立つためにスタッフとしても参加してみました。 まずは、会場が綺麗","tags":["勉強会"],"title":"Fluentd Meetup Japanに参加しました。(Jugemより移植)"},{"contents":"昨年末に今年の抱負について書いたのですが、 他にも興味あるものが増えたので備忘録＆公約？を兼ねてブログに書いておきます。 （興味あるものがあれば、シェアしたりできると楽しいので、ツイート、コメント待ってます。）\nZooKeeper SolrCloud SenseiDB Lucene 検索システムのアジャイル開発？ まずは、ZooKeeper。このなんとも言えないアイコンでお馴染みのヤツです。 こんな顔してますが（顔関係ない。。。）、いろんな所に出没します。 Katta、Lilly、SolrCloudにも出てくるんです。SenseiDBにも出てくるんです。分散処理にことごとく絡んできます。 で、これは、知っとかないとまずそうだと。\nSolrCloud。まぁ、妥当です。一応、Solrな人なんで。 昨年、NewSolrDesignを訳してみてもいます。訳しただけでほったらかし。。。 elasticsearchとかSenseiDBとかSolrに似たLuceneを利用している検索サーバがチラホラ話題になってます。 できれば、このあたりの分散の仕組みを比較しながら調べたいなと思ってみたり。 すべてをカバーするのはキツイので、SolrCloudかSenseiDBあたりを調べていきたいなぁと。\nで、SenseiDBです。先日、Publickeyで記事が出て飛びつきました。 Zookeeper使ってるし、分散だし、全文インデックスにLucene使ってるし。 なんだか興味あること、全部入りな感じです。\nLuceneも興味津津です。 Solrがコアとして使ってますし、昨年、Solrと同時にリリースされるようになりました。 Luceneも奥が深く、時々、Solr調べててLuceneのソースも見るのですが、本格的に全体像を把握したりは残念ながらできていません。 そのくせ、Zookeeper同様、いろんな所に出没するんです、これが。 ということで、足元を固めるためにもLuceneに入門しないとなぁと。\nで、最後に検索システムのアジャイル開発です。 lucene-gosenのコミッターをやらせてもらってたり、Solrに絡んだ仕事もしてますが、長期にわたってフィードバックをもらいながら検索システムを育てていくというのが最近興味が出てきてることです。 検索システムは作ったらおしまいとは行かないのが厄介なところです。 データは増加しますし、検索されるキーワードも変わってきます。 また、検索される方法も変わってきたりもします。 ユーザが検索したいものも変化があります。 思ったように検索にヒットしない場合とユーザが離れて行ってしまいますし、検索しにくい場合も同様です。 今日、クックパッドの方の話しを聞いて思い出した次第です。（前に、Solr勉強会でも同じ話しをされて、同じ思いに至ったのですが、いかんせん忘れやすくてｗ） また、ログ解析の話などをTwitterで見てることもあり、検索という側面でのログ解析ってのも重要だよなぁと。 いくつか思いつくこともあるのですが、実践出来る場も限られてます。 色々と話しをする場を設けるのも面白いかもなぁと妄想してる次第です。\n取り留めもなく、現時点で気になってることを書きだして見ました。 また、数ヶ月したら気が変わってるかもしれないですが、とりあえず書き残してみます。 興味がある方がいらっしゃったら声をかけてもらえるとうれしいですね。\n","date":1327596641,"dir":"post/2012/","id":"58e83fb33c120db338132d23b9112805","lang":"ja","lastmod":1327596641,"permalink":"https://blog.johtani.info/blog/2012/01/27/%E4%BB%8A%E8%88%88%E5%91%B3%E3%81%8C%E3%81%82%E3%82%8B%E3%81%93%E3%81%A8/","publishdate":"2012-01-27T01:50:41+09:00","summary":"昨年末に今年の抱負について書いたのですが、 他にも興味あるものが増えたので備忘録＆公約？を兼ねてブログに書いておきます。 （興味あるものがあれば","tags":["備忘録"],"title":"今興味があること(Jugemより移植)"},{"contents":"ということで、いつものように勉強会に参加したメモです。\nhttp://atnd.org/events/23608 日時 :2012/01/26 19:00 to 22:00 会場 :アカデミーヒルズ(六本木ヒルズ内) 49階（タワーホールA） （港区六本木6-10-1） ハッシュタグ :#mnlgy\n■タイムテーブル 司会：CROOZLabs株式会社 研究所 所長 代表取締役社長　小俣 泰明 モーションノロジーの説明があったけど、他のことしてました。すんません。 1. 発表者: 有限会社未来検索ブラジル　森 大二郎 概要：groongaの索引構築の実装 全文検索とは。歴史から 1971：full-text。。。というキーワードが。 現代の全文検索の課題はあんまり変わってない 全文検索の手法 いくつかあるけど、転置索引の説明だけ。groongaも転置索引 groongaはインデックスの動的構築が得意 静的構築も考慮してます。 2. 発表者：CROOZ株式会社　長谷川 博紀 概要：MeCabからの脱出？(仮 CROOZ MALLの解説 MySQLとMeCabでやってます。 Tritonnつかってるのか？ groongaとの性能比較検証やってみました。 MeCabが問題じゃなくて、辞書ありの形態素解析が問題。 辞書にない単語もうまく検索したい 辞書に単語登録したら形態素やり直し ソート用のデータが。。。（ここはわからなかった） QA Q：MeCabの代わりとなっているものは？ A：MeCabを改善してみる？ 3. 発表者 : グリー株式会社　一井 崇 概要：全文検索のちょっとちがった使い方（仮） グリーでの数値指標管理 事前集計してKVSに登録してみてみる 1億パターンのキーが存在する。。。 キーがわからなくなる問題とか事前集計できてる？とか迷子になる。 キーも全文検索に入れてみては？ 「富士山の標高は何メートル？」とかでデータが取れる。 構造化されたキーをkey stringとして全文検索する。 構造化Keyに対応したKVSがあればいいんだけど。 データストアとしての全文検索もいいのでは。 4. 発表者：株式会社クリアコード　須藤 功平 概要：rroongaによる検索サービスの実装 groongaとRubyの組み合わせでrroonga。Rubyによるインタフェース？ groongaとのつながり部分をRubyで書いたライブラリ 多段ドリルダウン機能 絞り込みによる検索結果の比較とかに利用可能 メタデータ抽出にドリルダウンが便利 例：番組説明から出演者を抽出 サジェスト機能もある コンテンツベース すぐできる。候補の精度がいい 統計情報ベース 元データがある程度必要 候補が増えるけど、精度の問題あり 5. 発表者: 株式会社ぐるなび　塩畑 公一 概要: groongaの位置情報検索関連について。 2010年4月からgroongaを利用し始めた レストラン検索、地図検索など 円形、矩形の緯度経度検索が可能。 距離算出もやってる。ソートとか用かな。 球面近似もやってる。 geoの検索速度についてパフォーマンステストしました。 Q：近似手法をいくつもサポートされてるけど必要？ A：距離計算を正確にしないと不利になるお店が出てきちゃうから 6. 発表者: クックパッド株式会社 兼山 元太 概要: Solrを使ったレシピ検索のプロトタイピング クックパッドとは？ 女性多いよ AWS上でRubyで組んであるよ プロトタイピングって？ ユーザの問題を発見してから、プロトタイピング 本番デプロイ（一部ユーザに公開） 問題を抱えているユーザーに向けてそれぞれ数十のバージョンが動いている インタビューとかしてフィードバック受ける。 本番の検索エンジンのフィールドをいっぱい追加 Solrの紹介（MySQL（Tritonn）から移植しました） ダイナミックフィールドやレプリケーションの話。 JSON型でHTTP経由で検索できるのが便利。 Solr本の紹介して頂きました！あざっす！ 気になってるSolrの新機能 not to cache SurroundQuery BloomFilter Q：全部AWS？ A：全部AWSに移行しました。 とまぁ、参加してきました。 初六本木ヒルズで、おしゃれな場所、雰囲気にやられてしまって、あんまりちゃんと聞けてないところがありますが。。。 メモを取りましたので。参考までに。 groongaについては勉強不足のため、いまいちついていけませんでした。 ちょっと英語の記事を読んでいたのもありまして。（内職良くない。。。） MeCabに関する発表に興味があり、勝手にMeCabの代わりorMeCabよりいいものを使ってます！みたいな発表かと想像していました。（ちょっと違ったみたい、妄想は良くないですね。。。）\nグリーの方の発表は興味深かったです。ログ解析とかにも確かに全文検索の技術使えるし。 検討が進んだ次の話も聞いてみたいです groongaの位置情報の話やrroongaでのgroongaの色々な機能のはなしも出てきてgroongaの理解もちょっと進んだのはありがたかったです。\n最後のクックパッドさんの話は、今回もわかりやすくて面白かったです。 検索を成長させていくという姿勢と、実際にどんな形でそれを実施されているかが楽しそうに話されててとても羨ましかったです。 次はSolrで困ってる点とか、検索のログとか利用され方をどのように解析してるのかといった話も聞きたいですね。\nどうしてもSolrに思い入れがあるので、感想が偏ってるかもしれません、すみません。 気になる点やいや、こうなんだよ！ってツッコミがあれば、ぜひコメントやTweetしてもらえるとありがたいです。\n","date":1327593155,"dir":"post/2012/","id":"c6dc6e6567d673436ac41ebc8e79a9ec","lang":"ja","lastmod":1327593155,"permalink":"https://blog.johtani.info/blog/2012/01/27/%E3%83%A2%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%8E%E3%83%AD%E3%82%B8%E3%83%BC2012-1%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-01-27T00:52:35+09:00","summary":"ということで、いつものように勉強会に参加したメモです。 http://atnd.org/events/23608 日時 :2012/01/26 19:00 to 22:00 会場 :アカデミーヒルズ(六本木ヒルズ内) 49階（タワーホールA） （港区六","tags":["勉強会"],"title":"モーショノロジー2012#1に参加しました。(Jugemより移植)"},{"contents":"日時：2012/01/19 18:30-20:30 場所：ベルサール三田Room2シアター\nInside MapR デモ＋内部のお話。 ・自己紹介 Susheel Kaushik 元YahooのHadoop系の人。製品担当責任者。 草薙さん 3台のベアボーンでMapRが動いてるデモが開始。 クラスタ管理画面の説明。 なぜか、NFSのサービスが1台落ちてますがｗ MapReduceなんかの実行結果なども出てくるのか。 ボリューム管理も画面から操作 レプリケーション、スナップショットも管理画面で操作、動作確認できますよ。 ミラー先はリードオンリーでボリュームの同期が可能。 スナップショットによりMapRのクラスタ内部にバックアップが保持可能。 NFSのHA構成可能。VIPの機能などもあるよ。 事前定義された各種Alertの発行も可能。 JobTrackerもMapRで拡張された表示がある。 例：MapTaskPrefetchCapacity：次のジョブのMapperを起動する準備可能な仕組み MapR内で独自に出力してる測定値をGangliaで見ることができるよ。 MapRはHadoopの置き換えとなる製品。 HDFS部分を重点的に性能アップさせるために主に置き換えた製品。 MapReduce部分にも手を入れてる。例：Direct Shuffle（HTTPじゃなくて、RPCでShuffleの通信を行ってるとか）ボリューム活用してるらしい。 分散NameNode、JavaGCの影響の排除、ビルトイン圧縮によるI/O削減など。 Mapperの出力をHDFSに置くと、メタデータ更新が多くなり、NameNodeがパンクする。（Apache Hadoop） Q：中間データもレプリケーションすると性能劣化しないんですか？ A：中間データボリュームは特定ノードしか保持されない（＝レプリカ数は１） ストレージプール（SP） ソフトウェアでストライピング。RAIDしなくてよい。 コンテナ（データ、ネームがある。） データブロックをグループ化したもの ※ストレージプールの数と同数のボリュームを作成すべき。 CLDBがコンテナを管理してる。 Q：トランザクション失敗するのは？ A：どこかにかければトランザクションは成功。 コンテナが復旧してきたら、データがコピーされる。復旧されない場合は別途コンテナを割り当てることもある？ Q：ノードが追加される場合の挙動は？ A：。。。聞き逃した。 トポロジ ノードを階層的にグループ化してデータ配置をコントロール。 Q：トポロジ設定などの権限設定は？ A：Permission画面があるよ。 Q：ボリューム単位のファイルシステムアクセスに関する設定は？ A：？？？聞き逃した？ ボリューム いろいろな設定が可能。 スナップショット Copy-on-Write方式による差分格納 ミラー ソースからミラーにコピー。手動orスケジュールによる起動が必要。 ミラー側はRead-only ※誤解を招きやすいので注意 読み出しが多い場合にミラーを利用することで対応が可能。 ビルトイン圧縮 LZZFの一種を高速化してる ネットワークIOにも効いてくる JobTracker HA 最大３ノードで構成可能。アクティブスタンバイ NFS HA すべてのノードで稼働可能。 NFS機能 NFSv3相当 クライアント側にNFSサービスをインストールするという構成も可能に。 Q：NFSマウントして作成したファイルもブロックサイズ分のファイルサイズになるの？ A：8Kバイト単位で内部的にはファイルを作成してる。8KB単位で圧縮して管理してるので、小さいサイズでもいい。（アロケーションサイズが8KB） Q：8KBにしてしまったために大きなブロックサイズの利点がなくなるのでは？ A：オーバーヘッド内容な構成になってる。シーケンシャルに8KBに並んでるから？ Q：NFSによるとMapReduceによるアクセスの排他制御とかは？ A：独自で頑張らないといけない。Job起動時に効果的にスナップショット取ったりはしてない。 リバランスもバックグラウンドで実行可能 Apache Hadoopが備えるJava APIは100%語幹 Q：なんで、HDFSをがりっと書き換えたの？ A：運用性も、ノード管理も。。。全部です。 なくなっても良いデータなら、別にHadoopでもいいですよね。 けど、基幹システムとかだと、信頼性が必要だし、運用の効率も必要だしいろいろ必要。 Q：実績が必要なんですが、どのような試験を行われているのかという情報が公開される？EMCでやられてるテストのプロセスを適用しているなどの裏付けは公開されないの？ A：内部で6ヶ月利用してデータロスはない。 品質については強化していく。 Q：MapRとしてHadoopコミュニティへの還元していく内容ってどんなもの？ A：Apacheコミュニティに対して1000台のクラスタを提供してスケーラビリティテストとかやってくださいとしている。 Q：このクラスタを実際にはどう使ってもらうの？ A：品質アップするためにテスト環境として使ってもらう？ Q：ApacheのAPIの互換性を死守するのが必ずしもいいとは思えない場合にどうするの？MapR独自APIとかは出さないの？ A：ApacheのAPIに準拠するのは非常に重要。他のHadoop上のアプリが動作しなくなるから。 Q：MapRを容量の大きなファイルシステムとしてだけ利用するなんて想定はありますか？MapReduceを利用しないパターンです。 A：いや、それはｗ Q：MapRはエンタープライズがターゲットだけど、Amazonはパブリッククラウドが対象。マルチテナントなパブリックサービスでMapRを利用するとかは？ A：。。。 Q：ジョブ管理にも手を入れてるの？ A：あんまり手を入れてません。 Q：EMCのストレージ製品でMapRのMapReduceない版みたいの出てない？ A：中身はMapRじゃないですよ。 想定とは異なり、日本の草薙さんが主に説明されたのですごくわかりやすかったです。 しかもかなり内部まで理解されている方だったので突っ込んだ質問にもきちんと回答されてるので更に理解が進みました。 今回利用された資料は現時点では公開の予定はないという話でした。 ただ、かなりまとまってる資料なので、後悔して欲しいものです。 普通にviとかしてるだけなのに、すごいと思うデモってなんか新鮮でした。 MapR自体を触る機会はまだまだないと思うのですが、MapRとしてHadoopに対する思想が垣間見えたのが面白かったです。 すごいメンツが質問を投げまくるのでいろいろな側面で話が聞けました。 ただ、やっぱり英語のヒアリングがダメダメだというのが露呈しました。。。今年は少し頑張らないと、先が思いやられますね。。。 あと、疑問と言うか、感想ですが、MapR自体が結構多機能で、その機能をどう扱うか、どのようなノード構成やボリューム構成を取るかといった設計が結構大事でしかも大変なんじゃないかなぁという印象を受けました。 特にマルチテナントで利用する場合などは、想定されないミラーの利用などでデータ容量が足りなくなったりといった側面も出てくるのかなぁと。\n説明会のあと、Hadoopにあんまり絡んでないのに図々しくも飲み会にまで参加してきました。 これまた濃いメンバーだったので話についていくのも大変でしたが、面白い話が聞けました。やっぱり懇親会重要ですよねぇ。\n事前にこのブログを読んでいたので話しを聞くのが楽でした。 MapR勉強するために必須のページです。（どうやら今日説明した人がかいてるきがしますが。。。）\n追記： トゥギャってくれた人に感謝。 ","date":1326988680,"dir":"post/2012/","id":"7198e10ebcf1bb88dc479b5c5b9f2c15","lang":"ja","lastmod":1326988680,"permalink":"https://blog.johtani.info/blog/2012/01/20/mapr%E4%B8%AD%E8%BA%AB%E8%AA%AC%E6%98%8E%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-01-20T00:58:00+09:00","summary":"日時：2012/01/19 18:30-20:30 場所：ベルサール三田Room2シアター Inside MapR デモ＋内部のお話。 ・自己紹介 Susheel Kaushik 元YahooのHadoop系の人。製品","tags":["勉強会"],"title":"MapR中身説明会に参加しました。(Jugemより移植)"},{"contents":"お久しぶりです。インフルエンザで一家全滅という最悪の状況に陥っていた我が家でした。 流行してるみたいなのでみなさんも気をつけてください。\nさて、そんな中、OSSAJのミニセミナーでSolrについて簡単に話しをしてきました。 人生初Ustだったのですが、ぶっ倒れている中作成した資料だったためなんとも情けない発表だった気がします。（言い訳カッコ悪いですね。。。） 関係者の皆様、申し訳ございませんでした。\n内容としては、Solrの機能を簡単に紹介する程度の資料となっています。デモなどもないのでスライドだけ見てもなんだこれという感じかもしれませんが。\nということで、恥ずかしながら、録画もされているようなので、後で見て反省しようと思います。。。\n[オープンソースソフトウェア検索サーバ Solr入門](http://www.slideshare.net/JunOhtani/solr-11146713)** View more [presentations](http://www.slideshare.net/) from [Jun Ohtani](http://www.slideshare.net/JunOhtani) ","date":1326941184,"dir":"post/2012/","id":"a4462529ab493676987d946019a14945","lang":"ja","lastmod":1326941184,"permalink":"https://blog.johtani.info/blog/2012/01/19/ossaj%E3%81%AE%E3%83%9F%E3%83%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%A7%E8%A9%B1%E3%81%97%E3%82%92%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-01-19T11:46:24+09:00","summary":"お久しぶりです。インフルエンザで一家全滅という最悪の状況に陥っていた我が家でした。 流行してるみたいなのでみなさんも気をつけてください。 さて、","tags":["勉強会"],"title":"OSSAJのミニセミナーで話しをしてきました(Jugemより移植)"},{"contents":"先日のSolr勉強会でLucene/Solr4.x系のlucene-gosenについて質問を受けていたのを忘れないように（年越しちゃいました、すみません。）先週金曜日（1/6）にissueに登録しました。 まずは忘れないようにと思って、登録だけして3連休に突入したのですが、Robertさんが1/7に対応してくれました。 Lucene/Solr 4.x系では3.x系とはパッケージやメソッドが変更されるなど少し異なる部分があります。 lucene-gosenでは、プロジェクトのページにもあるとおり、4.x系にも対応しています。 ただ、この4x系に対応したブランチが、2011年5月から放置されていました。\nということで、Lucene/Solr 4.0系でlucene-gosenを利用されている方、これから利用される方は、この4x系に対応したブランチを利用してください。 なお、このブランチにはLucene/Solrのtrunk (r1228509)のSNAPSHOT版のjarファイルが利用されています。\n今後はlucene-gosen側でバグ修正や機能追加を行った場合にも4xブランチを更新していく予定です。 ※ただし、Lucene/Solr 4.0が正式リリースされていないため、頻繁にSNAPSHOTのjarファイルを入れ替えることはこなわないと思います。\n","date":1326033660,"dir":"post/2012/","id":"f7df7b85af230b2623d3a827b0cbddd2","lang":"ja","lastmod":1326033660,"permalink":"https://blog.johtani.info/blog/2012/01/08/lucene-gosen%E3%81%AElucene-solr4-0%E5%AF%BE%E5%BF%9C%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%9B%B4%E6%96%B0/","publishdate":"2012-01-08T23:41:00+09:00","summary":"先日のSolr勉強会でLucene/Solr4.x系のlucene-gosenについて質問を受けていたのを忘れないように（年越しちゃいました","tags":["lucene-gosen"],"title":"lucene-gosenのLucene/Solr4.0対応ブランチ更新(Jugemより移植)"},{"contents":"あけましておめでとうございます。（もう5日ですが。。。） 今年もlucene-gosenを中心に色々と記事を書いていきますので、ツッコミ、コメント待ってます。\nたまには会社のブログを書かないとイカンということで、会社のブログにNearRealTime検索についての記事をアップしました。 読んでやってください。\nということで、今年もいろんな勉強会に出没しますので、よろしくお願い致します。\n","date":1325735817,"dir":"post/2012/","id":"cc573488dec311655890a205aad4fb65","lang":"ja","lastmod":1325735817,"permalink":"https://blog.johtani.info/blog/2012/01/05/%E3%81%82%E3%81%91%E3%81%BE%E3%81%97%E3%81%A6%E3%81%8A%E3%82%81%E3%81%A7%E3%81%A8%E3%81%86%E3%81%94%E3%81%96%E3%81%84%E3%81%BE%E3%81%99%E4%BC%9A%E7%A4%BE%E3%81%AE%E3%83%96%E3%83%AD%E3%82%B0%E6%9B%B4%E6%96%B0/","publishdate":"2012-01-05T12:56:57+09:00","summary":"あけましておめでとうございます。（もう5日ですが。。。） 今年もlucene-gosenを中心に色々と記事を書いていきますので、ツッコミ、コメ","tags":["misc"],"title":"あけましておめでとうございます＋会社のブログ更新(Jugemより移植)"},{"contents":"他の方たちよりひと足はやいですが、今年の仕事が終わりました。 せっかくブログを始めたので、振り返りと来年の抱負など書いてみようかなと。\n今年の振り返り まずは、今年1年を振り返ってみます。 今年の出来事はこんな感じでした。\n3月に仕事が一区切り lucene-gosenに参加 ブログを始める 色々な勉強会に参加 Twitterでつぶやきまくり Mac Book Airの購入 PSVita買いました 3月に一昨年から参加していた仕事が一区切りつきました。 もう少し色々とやり残した感がある中で区切りがついたのが少し心残りでした。 あと、3月は震災もあり、色々と大変でした。ただ、自分の中では震災の記憶が少し薄れつつあるのが気がかりです。 良くも悪くも忘れて行ってしまうのだなと。今でも頑張っている方々もいるので、少しでも心に留めておきたいものです。\n個人的に一番大きな今年の変化は「lucene-gosenへの参加」です。 関口さんとここ数年ずっと仕事をご一緒させていただいていることもあり、コミッターとして参加させてもらうことが出来ました。 英語が苦手な中、Robertさんへ自己紹介のメールを書いたり、Issueを英語で書いたりと苦労もしていますが、OSSに参加できることがとても楽しいです。 また、使っていただいている方たちからのフィードバックもいただけているのがすごく励みになります。 やはり、OSSは使ってもらってさらに良いものになっていくのかなぁという感想です。 ただ、自分の腰が重いため、なかなか対応が遅かったりといったところもあるなと反省するところも。\n勉強会にも色々と参加しました。Solr勉強会を始めとして、かねてより興味があるHadoopのカンファレンスやソースコードリーディング。MongoDBの勉強会やDSIRNLPといった少し研究よりの勉強会にも参加しました。 Solr勉強会に参加してきた経験もあり、他の勉強会にも気負わずに参加できたので本当にSolr勉強会には感謝しています。 おかげで、社外のいろいろな方と話ができ、様々な刺激をうけることが出来ました。\n勉強会以外にもTwitterで色々な方に絡みまくったのもまた社外の方とのつながりが出来るいい機会でした。 Twitter依存症じゃないかというくらい、つぶやいたり、人に絡んだりしてます。。。（迷惑だったら言ってください。） お陰で@doryokujinさんや@wyukawaさんが主催してくれたログ解析の飲み会に誘ってもらえたり、@nobu_kさんや@ IjokarumawakさんにSolr勉強会で講演してもらえたりしました。 あと、Twitterを通じて勉強会やHadoop関連の情報、lucene-gosenへのフィードバックなどももらえていてかなり助かってます。 @yusukeyさんや@repeatedlyさんに遊んでもらってるのも楽しいですｗ\n最後の大きな変化はApple製品の購入でした。 これまでもブログで書いてきましたが、私は今年の中頃までアンチApple派でした。 それがここ半年足らずでAir、Mini、iPadと3つのApple製品に囲まれています。 Emacsのショートカットが使えるのが最大の要因ですが、何ごとも毛嫌いせずためしてみるのがいいなと思いましたね。 今では、Windowsで開発したくないくらいになってきています。\n2012年の抱負 さて、来年の抱負です。 今年いくつかチャレンジしようとして挫折してるものがあります。\nMongoDB触ってみる Scala触ってみる なんかWebサービス作ってみる（Amazonとかで） elasticsearch、IndexTankを調べてみる NewSolrCloudDesignを読み込んで自分なりにまとめる Junsaiに参加する 「7つの言語7つの世界」の続き 最初の3つはセットですかね。コップ本買ったり、NoSQLの本を買ったりしてるのですが、手付かずです。。。 電子書籍の検索サービスでもつくってみようと思いつつ、腰が重い状態です。 来年は余裕を見ながらちょっとずつやりたいですね。\nelasticsearchやIndexTankは仕事がらみです。 Solr入門を書いたこともあり、検索関連には興味があります。Solrだけでも2ヶ月おきに新バージョンがリリースされたり、4.0系でいろんな機能が実装されているのですが、それ以外にもOSSの検索サーバがいくつかあります。 気になってはいるものの英語が障壁でなかなか手を出して来ませんでした。 来年はSolr以外についてももう少し知識をつけていきたいです。 個人的ですが、分散処理にも少々興味を持っています。 慣れ親しんでいるSolrでもSolrCloudという壮大な計画が上がっていて、少しずつ実装もされています。 ブログでWikiページを翻訳してもみたのですが、翻訳に注力しすぎて理解ができていないです。 このあたりをもう少し理解しつつどのような実装がされているかも調べたいところです。\nJunsaiはSolr入門の著者である武田さんが最新のMeCab（今はMeCabが新しくなってしまったので、少し前のMeCabになってしまいました）をJavaに移植したプロジェクトです。 今年頭のSolr勉強会でお披露目があり、私も一応参画しているのですが、手が出せていない状態です。 lucene-gosenで少しは経験を積んできたので、その部分を生かしつつ、こちらももっと活性化させたいところです。 最後は夏ごろにやっていた「7つの言語7つの世界」の再開です。序盤で止まってしまっています。。。 新しい技術に触れる題材としてちょうどよいので、余裕をつくって続きを再開します。 なんか、抱負と言うよりも積み残しですね。。。 他にもTwitterで情報を仕入れるとやりたいことも変わってくるかもしれませんが、それも含めてブログに少しずつでも書きためていこうと思います。\n先ほども書きましたが、今年はTwitterを通じて色々な方たちと知り合いになれた一年でした。 ここには書ききれていませんが、フォローしてもらっている方々や勝手に絡んでも相手をしてくれている方々に感謝しています。 今後も絡みますのでよろしくお願いしますｗ あと、様々な勉強会に今後も顔を出していくので、かまってやってください。 いやぁ、色々書いたけど恥ずかしいですね。。。 まぁ、何事も経験なので、恥ずかしいと思いつつ今後も色々書いていきます。\n","date":1325006100,"dir":"post/2011/","id":"7164823f504286e3a762ee612ff0a988","lang":"ja","lastmod":1325006100,"permalink":"https://blog.johtani.info/blog/2011/12/28/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A0/","publishdate":"2011-12-28T02:15:00+09:00","summary":"他の方たちよりひと足はやいですが、今年の仕事が終わりました。 せっかくブログを始めたので、振り返りと来年の抱負など書いてみようかなと。 今年の振","tags":["misc"],"title":"今年の振り返りと来年の抱負？(Jugemより移植)"},{"contents":"@yusukeyさんにサインをもらう目的で勉強会に参加してきました。前回もらいそびれたのでｗ 残念ながら、まだTwitter APIを触ってないし、利用したサービスも思いついてないんですが。。。 けど、勉強になりました。 といことで、いつものごとく、自分メモです。\n◎APIの基本と最新動向について @yusukey 資料：http://www.slideshare.net/yusukey/21twitter-api-api\n・検索APIについて http://search.twitter.com/search.json?q=*** %3Aは「:」 詳しくはリファレンスを買ってね。 ・ページ処理のベストプラクティス Pageじゃなくて、MaxIdを利用して取得すると１５００件以上のデータも取れるよ。 ・最近のTwitterAPIアップデートについて - ポケリファでの変更点 ストリーミングのエンドポイントがSSLのみに。（twitter4jは2.2.5以上） - ユーザ名が検索APIのスキーマに追加（１２月以降） - in_reply_toの追加（１２月以降） =\u0026gt;検索結果から会話を追える。 ・include_entitiesが追加 t.coの展開したリンクも取得可能。 けど、t.coリンクの飛び先はt.coリンクにしてね。パトロールとかしてるから。 ・本当にあった怖いt.co - URLのつもりじゃないのにリンクになる。 →仕様です - 日本語を含むURLがおかしくなる。 →少しずつ治ってきてる。 - リンク先のURLがわからない（クライアント依存） そのたいろいろ？ ◎Zusaarについて何か @knj77 資料：\n・特徴 - SNSアカウントでログイン トラブル抑制など - 事前決済可能。最小催行人数が決められて、払い戻しも可能。 ・利用例 旅行とか合宿に使う例がないんだけど、できるんじゃないかな？ ・イベントを依頼する機能 欲しいイベントを提案可能 http://www.zusaar.com/idea/ ・アーキテクチャ GAE/Java、Twitter4j、Yahoo APIのテキスト解析 ・SNS連携 TwitterのDMが送れない。他のSNSのアカウントが主催者とか。 なので、自分からDMが届く。 ・PayPal連携 小さいアプリほど相性がいい 固定費ゼロ、マイクロペイメント（１００円とか可能） 銀行口座の登録不要、返金可能。部分返金も可能。 ・トラブル - SNS側のエラーが適当 ステータスコードは信用できないｗ - PayPalの実装を３回変更 - GAE料金体系の変更 9$/month。追加料金はほとんど使ってない。Googleのアナウンスが下手。 - ブルーオーシャンのはずが... Q：Zusaarで返金できるポイントは？ A：主催者が主導（手動？）で返金可能。 Q：無料イベントで約束手形的に課金するのはできる？ A：やろうと思えば出来ます。ただ、システム的には１００円は手数料としてもらっている。 Q：新しいATNDに対抗意識はありますか？ A：ZusaarはCtoCをターゲットにしてる。ATNDはBtoCなので、補完できる関係だと思ってる。 Q：APIでTwitterIDとかで検索したいんですが。 A：対応予定あります。 Q：できればATNDのAPIと共通化してほしい。 A：追加してるだけのつもりです。 ◎グループに分かれて自己紹介 6人中、懇親会参加者が5人もいたｗ\n◎LT - OAuth Echoについて@tkawa 資料：http://www.slideshare.net/tkawa1/oauth-echo-20111221-10657954\ntwitpicで使ってる。 認証をServiceProviderに委譲する仕組み。 クライアントがOAuth登録してあれば、。。。 ・問題点 非公式仕様 OAuth1.0に基づいてて2.0では変わってそう。 ・Railsで実装してみたよ。 - GroovyとQuartzとTwitter4Jの甘い生活G @mike_neck 資料：\nベトナムから緊急来日らしい。 しかもむちゃぶりされたらしい。 - 認証なしで使えるAPIまとめ？@ts_3156 えごったーの作者で学生！\n- TDD (Twitter4J Driven Development) @sue445 資料：\nAZusaarの作者！ テストドリブンなはなし。 Twitter4Jを利用するときのTDDの簡単に実装できる仕組みの話。 ここにソースがあるのかな？ http:/github.com/sue445/twtrhack/ - 放射線を自動計測してTwitterにつぶやくimaocandeの紹介 @imaoca 松山の方。 とまぁ、APIの話だけでなく、実際にAPIを利用している方のサービスの話など色々と面白い話が聞けました。 厚かましくも懇親会にも参加して、そこでも今までのイベントとは違うクラスタの方たちの話が聞けたのが楽しかったです。 やはり、APIを利用して色々とやってみようと思っている方が多かったのでいつもと違う話が聞けたんですかね。 私自身はサービスを思いついたりしないタイプなので、いい刺激になりました。（まだ、特になにか作る気にはなってないですがｗ） ということで、次回も余力があれば参加したいなー。 ","date":1324485660,"dir":"post/2011/","id":"da67e2f049b5b6babcf7906b85653399","lang":"ja","lastmod":1324485660,"permalink":"https://blog.johtani.info/blog/2011/12/22/%E7%AC%AC2-1%E5%9B%9E-twitter-api-%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%9D%B1%E4%BA%AC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-22T01:41:00+09:00","summary":"@yusukeyさんにサインをもらう目的で勉強会に参加してきました。前回もらいそびれたのでｗ 残念ながら、まだTwitter APIを触ってない","tags":["勉強会"],"title":"第2.1回 Twitter API 勉強会 @東京に参加しました。(Jugemより移植)"},{"contents":"lucene-gosenの最新版（1.2.1）をリリースしました。\nプロジェクトページよりダウンロードが可能です。\n今回の修正では、特定文字列でメモリの使用量が爆発してしまうバグへの対処となっています。 1.2.1以前のバージョンを利用している場合は最新版を利用するようにしてください。\n","date":1324437339,"dir":"post/2011/","id":"584b2b145f362098fc5fc1e634d57de5","lang":"ja","lastmod":1324437339,"permalink":"https://blog.johtani.info/blog/2011/12/21/1-2-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-21T12:15:39+09:00","summary":"lucene-gosenの最新版（1.2.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、特定文字列で","tags":["lucene-gosen"],"title":"1.2.1リリースしました(Jugemより移植)"},{"contents":"いつものようにSolr勉強会に参加してきました。 皆勤賞を継続中です。（暇人というはなしも。。。） 今回は話しを聞きたいですねぇといったら、いやいや、話もしてくださいと言われてしまったので、 発表もしてきました。 発表資料はブログの最後に掲載してあります。\n日時：2011/12/19(月) 19:00～21:00 場所：Voyage Group 8階\n1.Fessについて N2SM菅谷さん 資料：http://www.slideshare.net/shinsuke/solr-fess\nマルチコアで構成されてる。 S2Robotでクロールしてますよ。 ※ごめんなさい、あまり聞けなかった。。。あとで資料を読んで質問します！ 2.lucene-gosenについて @johtani 発表しました。 3.ApacheConに参加しました @Ijokarumawak 資料：http://www.slideshare.net/KojiKawamura/apache-con-2011report\n日本-\u0026gt;カナダ-\u0026gt;ベルリン-\u0026gt;カナダ-\u0026gt;日本 50万円。。。 キーノート１： セキュアな開発について。 キーノート２： Hortonworksのコミュニティ運営大変だよねぇ、頑張るよという話。 キーノート３： 本題：Lucene 4.0の話：Simonさん ヨーロッパの方？ PostingsFormatの話。 Document内部の情報を使うためにどうする？ StoredField：あんまり効率よくないね。 FieldCache（on RAM）：インデックス作る動作の逆を行う。これも効率よくないね。 IndexDocValue：インデックス作成時に作られるので読み込み性能が１００倍！（DocValue） Document Writer Per Thread！ Automaton Query あいまい検索の処理に利用。 Solr Flair Solr同梱 Prism LucidImaginationが出してるJRubyのラッパー GitHubで公開されてるらしい。 Blacklight RoR 図書館むけのパッケージじゃなかったっけ？ VUFind PHP これも図書館向け？ TwigKit JSPのタグリブ おぉ。これ直接読んでるのかな？ Ajax Solr Ajax用 QA Q：TwigKit、Ajax Solrは直接Solrを呼んでるんですかね？ A：たぶん、そうですね。JSPのはSolrJかもしれないですが。 4.サフィックスアレイの話 @nobu_k 資料：http://www.slideshare.net/nobu_k/suffix-arraysolr\nSuffix Arrayの話 全文検索インデックスの話。 Suffix Array＝検索漏れがない。 Suffix＝接尾辞 RedBullがどの文書に入っているか！ SuffixArrayのメリット 検索漏れがない＝n-gramと同様 仕組み上n-gramよりも早くなるケースが多い。 長いクエリに対して速い THIS IS IT：全部ストップワード SuffixArrayのデメリット インデックス構築系 アルゴリズムが難しい。 メモリ上での構築はちょっとだけ楽（けど、簡単ではない） SAISなど。けど、これだとメモリがいっぱいないとキツイ HDDでの構築 ランダムアクセスを排除したアルゴリズムが必要（dc3,dc7） インデックス更新、差分更新できない。 頑張って１台100GB/day Sedueでは？ SA＆インメモリn-gramのハイブリッド 更新分はn-gramに 検索時にはn-gram＋SAの内容をマージして出力 検索 二分探索はHDDとは相性が悪い。 メモリ上で検索できればOKだけど、サイズが大きいからきびしい。 圧縮接尾辞配列なら可能だけど、低速。。。 SSDだとはやいよ！ SSD対応のクラウドはまだないけど。。。 Sedueでは最初の２０段でキャッシュしてる。 VSストップワード ストップワード込でインデックス作るみたい。 1.SAを二分探索 2.該当区間から出現位置をロード 3.出現位置をソート O(n)だけど、CPUのキャッシュミスが激しく影響 4.ソートした出現位置からヒット文書を求める。 同じくキャッシュミスがやばい ・実際にはmallocした領域のページフォルトが一番やばい SAが超活躍する場面 遺伝子の検索 n-gramとか死ぬ。形態素解析も無理。区切りがわからんｗ 5.P2P検索 ORBIS @ceeflyer 資料：http://www.slideshare.net/ceeflyer/p2p-search-engine-orbis\nORBISとは？ラテン語で「目」 ORBISとは？ リアルタイム検索エンジン 自律分散検索エンジン もともとはAmebaなうの検索のため ノード構成 比較的小規模（～１０００台）\u0026lt;=しょ、小規模ですか。すごいな。 Master-Slaveの差がなし MessagePack利用 フルメッシュネットワークを構築 インデックス フィールド： Content（形態素解析対象） Appendix（形態素解析しない） Flag（属性） ハッシュレプリケーションで登録。近いハッシュ値に登録（レプリカ数を指定できるのかな？） 単語に対して転置インデックスを一定数で固定 投稿日時が新しいものだけ検索するため。 検索： マージして結果を返す。 壊れてたら取れたものだけ返す。 QA： Q：ハッシュ値が大きくて１台しか選ばれないとかあるのでは？ A：ハッシュ値は循環しているという形で３台とか選ぶ。 Q：最大何台で稼働させてる？ A：現在はまだ５台程度 Q：障害時にレプリケーションの維持はするのか？ A：現時点はしてない。 Q；Cassandra、Lucendraとかあるけど、それをしなかった理由は？ A：単純にConfigurationができるから、１から作った。 今回はSolr以外の話も聞けたのがとても面白かったです。 やはり、Solr以外の検索エンジンについても知見があると、色々と比較の話しとかしやすいので。 それにしても、一からP2Pの検索エンジンを作っているのにはびっくりしました。 他にもSuffixArray（Sedue）の話も気になっていたのが少し氷解したし、海外旅行のノウハウがApacheConの話で聞けたしｗ やはり、発表をすると話しをしてもらえるのもあって、いい機会だなと再認識しました。 今回も紹介ネタだったので、ちゃんと事例とか測定したものも発表できるようにならねばと。。。\nということで、私の発表資料はこちらになります。疑問点とか質問事項とか、指摘事項など、コメントorTwitterで連絡いただけるとすごく嬉しいです。\n[Lucene gosenの紹介 solr勉強会第7回](http://www.slideshare.net/JunOhtani/lucene-gosen-solr7)** View more [presentations](http://www.slideshare.net/) from [Jun Ohtani](http://www.slideshare.net/JunOhtani) ","date":1324311660,"dir":"post/2011/","id":"c6696a730f7498efb66f5ba3a8b35d08","lang":"ja","lastmod":1324311660,"permalink":"https://blog.johtani.info/blog/2011/12/20/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC%EF%BC%97%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F%E7%99%BA%E8%A1%A8%E3%82%82%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-20T01:21:00+09:00","summary":"いつものようにSolr勉強会に参加してきました。 皆勤賞を継続中です。（暇人というはなしも。。。） 今回は話しを聞きたいですねぇといったら、いや","tags":["勉強会"],"title":"Solr勉強会第７回に参加しました。（発表もしました）(Jugemより移植)"},{"contents":"ということで、懲りずに#DSIRNLPに参加してきました。 基礎的な部分をおろそかにしたくないけど、TokyoNLPとかWebMiningではついていけないので。。。 今回もしがみつくのが精一杯かもしれないと思いつつ、聞いて来ました。\n0. DSIRNLPについて　@overlast 講演者が可能なら実装に関して言及する。 「こうやって作って結果を出す」系の発表をしましょう。 開催に際して協力してくださったみなさんへの感謝の辞。 1.自然言語処理はじめました　@phyllo 資料：http://www.slideshare.net/phyllo/ngram-10539181 ブログ：http://d.hatena.ne.jp/jetbead/20111210/1323499634 某Web企業の新入社員！（すごい） で、入って自然言語処理をはじめたらしい。 N-Gramの説明 Perl？ 1.ナイーブな方法 Perlでハッシュ使って数えてみたよ。これでOK？ いやいや、Nが大きくなったりデータが大きくなるとキツイでしょ 2.SuffixArrayを使う ということで、Suffix Arrayを使ってみた。 SuffixArrayのデータを作ってから、上からN文字数えれば数えられる！ （数式出てきたけど目も取れなかったｗ） これでいいじゃん？いやいや、更に大規模だとどーすんの。1TBのメモリ 3.近似カウント法 いくつかある中からLossy Countingを説明します。 ストリームデータから数えてみよう。 C++の実装？ 4.分散処理を使う方法 近似じゃダメ！正確な頻度が欲しい！ ＝＞Hadoopつかえ！ 色々やってみた感想が良かった。 SuffixArrayのメモリ使用量という話がありましたが、ディスクを使う方法もあります。 by ? 新人から自然言語やり始めたというが、自分が新人の頃にはこんなに出来なかった気がするなぁ。 発表とかもってのほかだったし。 2.AI で AI 創ってみた（LT）　@uchumik 資料： Luaプログラミングが出てきたので、 多クラスロジスティック回帰とListNetを書いて見ました。（ただし、本は読んでないよ。） 学習器のお話。 ラグナロクオンラインのAIがLuaでかけることを思い出した。 動画の途中で終了ｗ GitHubにあげなさい。ブログ書きなさい。動画もあげなさい。 by @overlast 資料の割に時間がｗ　2.5.CMコーナー 技評の方からWEB+DBのCM！（ただし、商品なし） 読者層の95%が男性ｗ 総集編買ってね！WEB+DB plusシリーズも買ってね！ 書いてor買ってね。 技評さんつぎはオライリーさんに負けないように賞品持ってきてねｗ 3.Mahout にパッチを送ってみた　@issay 資料：http://www.slideshare.net/issaymk2/mahout-10539755 人がやめていく会社で検索やHadoopやってます。 ※今日は皆既月食です。 機械学習関連 SGDはMapReduceでの分散に対応していないので、パッチを送ってみた。 MapReduce、Shuffleなどの説明 これをベースにナイーブベイズの説明をあわせて実装を見てみる。 ・単語ｗのカテゴリｃにおける確率 ・文書ｄのカテゴリｃにおける確率 -文書ｄに出てくる単語ｗの確率の積と定義 単語の相関を見ない。 ゼロ頻度問題の解説 文書頻度の逆数（IDF） カテゴリ毎の文書数のばらつきに対応するために、Complement Naive Bayes BayesFeatureDriver 次はランダムフォレスト 決定木とは？ ランダムフォレストとは？ ここでは素性。 Mahoutでの実装は？ 決定木の数だけ処理分散が可能。 Reducerは使ってない。＝Mapperで計算が終わっちゃうから？ 次はロジスティクス回帰 尤度関数、損失関数、確率的勾配降下法（SGD） 先程まではオンライン。バッチ学習もある。 Mahoutでの実装はオンラインで、MapReduceに向いてない！ Adaptive Logistic Regrettion（アダプティブロジスティクス回帰）というのも実装されてる。 送ったパッチの概要 Iterative Parameter Mixisngというのがあるので、それをSGDに適用するパッチ 今後 MapReduce以外も増えるかも。 Q:パッチがはいったバージョンはいつでる？A:3日前に送ったのでまだです Q:ナイーブベイズのMapReduceが一段ムダでは？（文書数のカウントは同時に出来るよね）A:そうですね、ぜひパッチを送ってみてください。 Q:Mahout、Hadoopの未来は明るいんでしょうか？A:HDFSのデータをMapReduce以外のフレームワークで使えるといい。 Q:Hadoopのパッチ送るの大変ですか？どのくらいかかりました？A:4,5ヶ月かかりました。 すみません、途中から頭がパンクしてしまいました。。。 ただ、MahoutがHadoopに乗っかってるからといって、MapReduce活用できてるわけじゃないという話がわかりました。 4.GraphDBのデータ構造　@kimuras 資料：http://www.slideshare.net/skimura/graphdatabase-data-structure LTみたいな資料にになっちゃいました。すみません。 mixiではMySQLだけど、いろんなDB触ってます。 なので、GraphDBに興味持ちました。 Luceneを教科書的に読んでます。 Neo4jモダンな作りでよかった。　http://www.slideshare.net/skimura/ss-8787632 ノードデータの構造 NodeManagerというのがいて、Cache系を管理してる。 プロパティのインデックス、トランザクションManagerもいて、PersistenceManager ここからNodeにアクセス（探索、）。 キャッシュとかいいね。 Soft LRU Cacheってのもあるよ。 その他色々ｗ Q:トランザクション周りでLRUのキャッシュはどうなるんでしょうか@kumagi A:きちんとロックしてました。 Q:分散はネットワーク、HDDどちらがキツイ？A:HDDがかなりきつい Q:プロパティもキャッシュに乗ってたほうがいい？A:プロパティも必要なら載せたほうがいい。メモリのしてはできたはず。 Luceneがほめられてました。Neo４Jの 5.冬のLock-free祭り　@kumagi 資料：https://docs.google.com/viewer?a=v\u0026amp;pid=explorer\u0026amp;chrome=true\u0026amp;srcid=0B72X9w6tG5q0NzMyODgwNDYtNjY4Yy00ZDgwLTliZDMtMjQwYmViMWE5NGU5\u0026amp;hl=en_US ※資料がうまく見れないのは、アニメーションガチガチって話だからかな？ http://twitter.com/#!/kumagi/status/145363169718697984 辻Lock-free活動してます。 Lock-freeとツイートすると補足されるらしい。 CPUの系譜のおさらい ポラックの系譜 最新のIntelManyCoreとか東大とかに配られてるらしい。 なんで、マルチコアのCPUがTSUKUMOとかで売ってないの？ 僕らが使いこなせてないから。＝マルチスレッドの対応がうまくできてないから。 CAS＝Compare And Swap まずは、Lock-free stack ABA問題？ Lock-free Queue QueueのEnqueueの場合は2回のCASが必要になる。 不変条件を守る。ロックだと守りやすい。 2回のCAS処理の間が危険領域 Lock-free List 色々なロックの説明。 Lock-free hash map これも気が狂ってるアルゴリズム？ ConcurrentHashMapなども話が出てきたが、説明しない＝Lock-freeじゃないからｗ Lock-free SkipList SkipList： 順序関係のあるデータをO(log n)で検索・挿入・削除ができるデータ構造（2分木ともろかぶり） DougLea先生がjava.util.concurrentに入っています。 Lock-free Btree 論文ないんですよ。簡単すぎて。 SoftwareTransactionalMemory The Art of Multiprocessor Programmingを読みましょう！ 論文のお話。 http://labs.gree.jp/Top/OpenSource/Flare.html を利用しているらしい。 The Art of Multiprocessor Programming関連サイト http://www.cs.brown.edu/courses/cs176/lectures.shtml すごくわかりやすかった。資料をもっと見たいなぁ。 Q:STMはメモリ使用量が2倍になる？A: Q:STM（Clojure）使ってみたけど残念な性能しか出なかったけど、なんで？A:Clojureのものはロックベース。でうーむ。。。 6.機械学習と最適化の基礎（仮）　@tkng PFIの徳永さん 日本語入力を支える技術（技評）2012年2月発売予定 最適化の話、機械学習の話、学習率の話。 大域的最適、局所的最適の説明。（言いにくそう、大域的最適ｗ） 凸最適化問題＝最適解が1つしかない？ 大域的最適解＝局所的最適解 機械学習なはなし。 スパムメールの例で説明 淡々と語られてましたが、わかりやすい説明でした。もっと昔にこんな形で数学の説明聞きたかった。。。 7.機械学習・言語処理技術を用いた誤り検出・訂正（LT）　@mamoruk 資料： スペル誤り訂正とかに機械学習とか使われてます。 8.神の言語による自然言語処理（LT）　@AntiBayes 資料：http://www.slideshare.net/AntiBayesian/ss-10539347# Lispさいこー Clojureさいこー lucene-gosenもいいよーｗ 9.言語判定へのいざない（LT）　@shuyo 資料： Solrで採用されたlanguage-detection libraryの紹介。 アゼルバイジャン語とか大変みたい。 12.作ろう！簡潔ビットベクトル　@echizen_tm 資料：http://www.scribd.com/doc/73565169/Lets-Impl-Sbv 入門編： 簡潔データ構造 データサイズをほぼ情報量的下限にまで小さくしたデータ構造 データは小さいし、速度速いというのがこれ。 実用化されてる。 mozc（LOUDSが使われてます） Sedue（圧縮接尾辞配列（デフォルトではなくなった by @tkng）） 種類： ビット列：ここの説明がこのあと 木構造：トライ木をLOUDSが結構で実装するケースが多い。データサイズが小さくなる 文字列：ウェーブレット木が有名。全文検索、転置インデックスにウェーブレット木を使う研究が多い。 中級編 簡潔ビットベクトル： rank(i)関数：i番目より前の立っているビットの数。 疎なデータ列の効率的な実装に使える。検索結果が少ない場合のFacetとかに使える？ select(i)関数：？ 可変長データ列の効率的な実装 上級編 ダメでした。。。ごめんなさい。。。 体力的に厳しかったです。。。けど面白いし、わかりやすい。どういった所でこれらを使うべきかを取捨選択するのがすこし難しそうです。Luceneとかの内部ソース見ると実はこのあたりで実装されてる部分があったりするのかも。 11.類似文字列検索の仕組み　@overlast 資料： 使い所のはなし 例：辞書メンテナンスコストを軽減したい 架空の事例から類似検索を適用できるというストーリー 既存データが活用されるうれしさの例？ Apporoのデータ構造とかの話かな？ 11.5.審査委員長から賞品持って帰る人の発表 @kumagi @tkng @echizen_tm の方たちでしたー 12.懇親会 いやぁ、前回も感じましたが、基礎ができてないなぁと実感できた勉強会です。 そして幅も広い。やはり、数学的な要素が時々出てくるのでその部分をもっと身につけないといけないなぁと。。。 ついていけなかったところも多々ありましたが、頭の中にキーワードが入ってればなんとかなるかなぁと。 Neo4jやLuceneのソースコードリーディングをやるのが仕事に役立ちそうなので、少しずつでもやろう。 これから懇親会なので、とりあえず、このへんで。 あとで、見返しながら、リンク貼り直したりすると思います。\n","date":1323529475,"dir":"post/2011/","id":"16fa0e4aefe18e1446bf6baefd3ba400","lang":"ja","lastmod":1323529475,"permalink":"https://blog.johtani.info/blog/2011/12/11/%E7%AC%AC2%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-11T00:04:35+09:00","summary":"ということで、懲りずに#DSIRNLPに参加してきました。 基礎的な部分をおろそかにしたくないけど、TokyoNLPとかWebMiningでは","tags":[],"title":"第2回 データ構造と情報検索と言語処理勉強会に参加しました(Jugemより移植)"},{"contents":"ひさびさに、MBAのお話です。 セットアップといっても、物理的な方ですね。 以前、ケース（カバー）について記載しました。 この記事にも書いてあったのですが、付属の滑り止めが簡易なシールで、カバンの中から出し入れすると剥がれるは、作業をしてるとずれるわで、悩んでいました。 今日、たまたま、東急ハンズに行くことがあったので、店員さんに相談してすべり止め対策のグッズを購入しました。 相談した所、カバーは傷がつきにくくなるような素材ですから、シールもつきにくいとのこと。（言われてみればそりゃそうか。） 対策としては紙ヤスリで傷つけたところに薄手のシールゴムをつければはがれにくくなりますよとのこと。 ということで、やってみました。まぁ、ゴムにホコリはつくかもしれませんが、今のところ滑らず快適！ いやぁ、ハンズの店員さんすごいですわ。 MBAについてはこんなとこです。最近また、出先に行っていてMBA使えないので、ブログを書くかメールにしか使ってないです。。。\nで、もう一つはMac Mini（2009 late：Core2Duo 2.26GHz、メモリ4G、HDD250G）です。 前職の同期から安く譲ってもらいました。音声が出力されないという問題点があるとFacebookでつぶやいているのをみて、興味を持ったらゲット出来ましたｗ で、セットアップをしたのです。 大変でした。まずつまずいたのが、キーボードとマウスでした。 これまで使っていたデスクトップのキーボードがあるのですが、これがPS/2ということで使えません。（軽いジャブ） MBAのキー配列にも慣れてきていたので、ビックカメラで悩みながらもApple純正のワイヤレスキーボードとまじっくトラックパッドを購入。 で、まずは、付属のLeopardで初期化。 このときは、ワイヤレスキーボードは認識したのですが、マジックトラックパッドはこの時代に無かったらしく、反応せず（さらに軽いジャブ） さすがに前のPCのマウスはUSBだったので、これを利用してセットアップ再開 次にSnow Leopard（これもつけてくれた）にアップグレードして最後にLionです。 Snow Leopardでソフトウェアアップデートしたところでようやくトラックパッドが認識できたと。 で、やっと使い始めたのですが、MBA（2011）に慣れていたので、思いの外もっさりした動きをしているMacMiniに 戸惑ってます。（トドメのストレート。現在ここ） ということで、どうやれば快適に使えるかアイデア募集中です。 とりあえず、Lionの設定のウィンドウ復元機能やアニメーションをオフにするなど対策してます。 HDDのSSD化とかメモリ増設とか考えないとダメかなぁ。 あと、ついでにBootcampも興味があるので、せっかくだから実験する予定です。 Windowsが前のデスクトップより快適に使えるようになるなら、Windowsマシンとするのもありかなぁと。。。\nセットアップ系はこのへんで。 あとは、最近興味が有ること2点です。（技術系ではありません） 1つ目は最近発売されたゼルダ。夜な夜なやってます。 もともとゲーム好きでゼルダも欠かさずやってきてますが、ゼルダらしさを残しつつ新しい要素やアクションも取り入れとなかなか楽しいです。 ただ、Wii全般に言えることですが難しい！まぁ、楽しんでますけどね 2つ目は前からつぶやいてるのですが、電子書籍を読むためのタブレットがすごく気になってます。 最初は財布に優しく、MBAを普段持ち歩いてるのもあるから、LenovoのA1（7インチ）で決まりだと思っていたのですが、技術書を読むのは少しキツイかもという印象。 どうしてもオライリー本などの大きめのサイズになるため、7インチの画面でPDFを表示したところ、字が小さくなってしまい拡大しないと見づらいのです。 ただ、拡大してしまうと今度はパッと見るという一覧性が下がってしまいます。。。 少々重くなってもいいので10インチにしたほうがいいのかな、けど、電車で立って読むの辛いかもなどなど考えているところで最終的な決断ができない次第です。。。 最初は毛嫌いしていたiPad2もいいかもと思う始末で困ってるとこです。 安い中華パッド（2万ちょっと）に手を出すか、7インチで我慢するか、Galaxy Tab 10.1のWifi版を輸入業者から購入するかと悩んでるところ。 ただ、長く使うのを考えると、OSのバージョンアップなどを保証してくれるiPad2が実はいいじゃないかなぁなど。 皆さんからしてみればくだらないなぁと思われるかもしれないけどずーっと悩んでつぶやいたりしております。 はぁ、こまった。（そもそもそんなにスペックいらないんじゃないかというのもあるからなぁ。メインはPDF読むことだから。） ゼルダの伝説 スカイウォードソード (期間限定生産 スペシャルCD同梱) ","date":1322668828,"dir":"post/2011/","id":"6e970d0818d58ff2d50c5bf037b1a565","lang":"ja","lastmod":1322668828,"permalink":"https://blog.johtani.info/blog/2011/12/01/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%95%E3%81%A8mac-mini2009late%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E3%81%A8%E3%81%9D%E3%81%AE%E4%BB%96%E3%81%8F%E3%81%A0%E3%82%89%E3%81%AA%E3%81%84%E8%A9%B1/","publishdate":"2011-12-01T01:00:28+09:00","summary":"ひさびさに、MBAのお話です。 セットアップといっても、物理的な方ですね。 以前、ケース（カバー）について記載しました。 この記事にも書いてあった","tags":["備忘録"],"title":"MBAセットアップ備忘録その５とMac Mini（2009late）セットアップとその他くだらない話(Jugemより移植)"},{"contents":" どんな本でも大量に読める「速読」の本 Twitterで知り合った方がこの本について書かれていたブログ記事を読んで興味を持ち、読みました。 書籍（特に技術書）が山になっていたこともあり、速読に興味を持っていたところちょうど記事を目にしたのは きっと何かのタイミングなんだろうなと。\n悪い癖で、電車で読もうと本を常に持ち歩くのですが、ついついスマートフォンやゲームで遊んでしまい、今回も読むのに時間がかかってしまいました。 ３章の途中までを今月頭に読んでいたのですが、そこから少しほったらかしで、読み終わったのが昨日でした。\n本の内容ですが、先ほどのブログにも書かれていますが、速読は技術ではない。 ### 速読　＝　速読技術　X　ストック（知識、経験、情報） であると。あとは、わからなくてもいいから、ざっと目を通す感じで繰り返し読みなさいと。 さらに、１回でわからんくてもいいから、とにかく繰り返し読むことが重要だということでした。\n確かに「速読＝１回で速く読む」、「読書＝１回で理解する」という意識がどこかにあったなぁと気付かされました。 プログラム組んだり、あることを覚えるときは繰り返しを意識してたのに、読書は１回読んで「はい、おしまい。」という気になってました。（マンガは繰り返し読むんですけどねぇ）\n他の速読の本は胡散臭いし、絶対無理だよなぁと思ってたのですが、この本に書かれている話は筋が通っているように感じました。 ただ、考えずにサラサラ読みなさいという部分の実践はなかなか難しいかな。どうしても頭の中で音読してしまうので。 私は間を開けてしまったせいで、時間がかかってしまいましたが普通なら１日あれば読める内容なので速読に関してちょっとと思ってる方は読んでみると面白いかと思います。\nちょっとだけショックだったのは、この本の論理だと電子書籍は速読に向いていないというところです。 せっかく溜まった書籍をPDF化して、タブレット購入して（まだ買ってない。。。）読もうと思っていたところなのに。。。\n","date":1322542620,"dir":"post/2011/","id":"0ebe78077c8b48410cf52a0bccdff866","lang":"ja","lastmod":1322542620,"permalink":"https://blog.johtani.info/blog/2011/11/29/%E3%81%A9%E3%82%93%E3%81%AA%E6%9C%AC%E3%81%A7%E3%82%82%E5%A4%A7%E9%87%8F%E3%81%AB%E8%AA%AD%E3%82%81%E3%82%8B%E9%80%9F%E8%AA%AD%E3%81%AE%E6%9C%AC%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-29T13:57:00+09:00","summary":"どんな本でも大量に読める「速読」の本 Twitterで知り合った方がこの本について書かれていたブログ記事を読んで興味を持ち、読みました。 書籍（","tags":["読書"],"title":"「どんな本でも大量に読める「速読」の本」を読みました(Jugemより移植)"},{"contents":"Hadoopソースコードリーディング第7回に参加しました。 いつものごとく、自分用のメモをとっていたので。 第6回（2010/12）には参加してたのですが、あれからそういえば、話が無いなぁと思っていたところに 再開するという話がTwitterに流れてきたので、即申し込みしました。 思い返せば、Hadoopに興味をもって少し触っているところで参加したのだったなぁと感慨深い思いを思い出しました。\n今回は場所を変えて豊洲のNTTデータさんで開催されました。\n日時：2011/11/28（月）19:00～22:00 場所：豊洲センタービルアネックス NTTデータ\n◎アジェンダ＋導入（NTTデータ 濱野さん） ちょっと間が空きましたが隔月で行う予定。 2012/01/12くらいに次回を予定。ネタ募集中。 ◎Hadoop World NYC 2011 参加レポート - NTTデータ 下垣 徹さん （Hadoop徹底入門著者の一人です！） ・イベント概要：2011/11/08～09にNYで開催 スポンサー企業の数がどんどん大きくなってる。 ・会場の様子 最初のキーノートは立ち見が出るほど。 個別に5並列でセッションが開催されてましたと。 ・キーノート紹介 1.Hadoop World（Michael Olson） アンケートからの概観 HadoopはNext Generation DataCenterだそうで。 2.JP Morgan（Larry Feinsmith） コスト削減＋収入増加のためにHadoopつかうぞと。 BigData分析の戦略 ユースケース１：ETL（Extract/Transfer/Load）ツールとして ユースケース２：共通データ基盤 検索頻度が低いデータの低コストストレージなどなど。 ユースケース３：データマイニング 異常値検出とか。 3.eBay（E. Williams） Cassini：オークション情報の検索エンジン 柔軟な検索＋協力なランキング機能 Hadoopで転置インデックス作成＝Luceneは使ってるってことかな？ HBaseも利用。データはHBaseに登録してる。 4.Informatica（James Markarian） データとプロセス Hadoopが賑わうからRDBMSも活気づく Hadoopはプラットフォームになるよと 5.Cloudera（Doug Cutting） Hadoopの背景と今後について BigDataを分散処理するためのカーネルになりつつあるよと。 Apacheプロジェクトの良さ 類似するプロジェクトも共存させてるよと。 Hadoopの今とこれから（0.20（今）、0.23（将来）） 0.23はHDFSの性能面改善、スケーラビリティの強化、HA MapReduce2.0 CDH4のはなし。 Hadoopコミュニティはまだまだ若い ・HadoopWorldの傾向 HBaseの利用増加 利用理由？ 小さいレコードにも強い。 ランダムアクセス 大手ベンダ参加 Oracleすげー。Hadoopの周りを固めていくぞと。 Hadoopの周りを各社がどう固めていくかというはなし。 事例が多い WibiData：HBaseの利用事例。Fonedoctor Walt Disney：Big Dataに対する機会損失があるから、導入するよと。 テーマパークの交通流解析にも使うぞ！ イケメンによる来年（2012年）のHadoop Worldの動向！？ 参加者3000人！ ラスベガスで開催？ スポンサー拡大で食事が美味しく！？ 全方位戦略vs.特化型 BIツールベンダの巻き込み 利用事例のアピール合戦 HBaseの利用事例が続々！（Salesforce.comあたりがセッション持つんじゃね？） Hadoop対抗アプリケーション、業界特化型キラーアプリケーションがますます増える？ Mahout事例の増加 データマイニング＋Web勉強会 - NTTデータ 政谷さんのHadoopNYでの発表のダイジェスト まずは印象。深く使っている人は去年より減っている。バズワードになってるからかな？ 今後もHadoopコミュニティは健全なコミュニティになりそう。（いろんな所が出てきたけど、大丈夫そうだなぁ） ・発表スライドのダイジェスト版 日本でのHadoopの盛り上がりの話。 Hadoopと他との住み分けの話。 Sqoopのお話。PostgreSQLに向けたインテグレーションの話。これはPostしてコミット待ち。 Low-Latency Serving Systemへの受け渡し（前処理はHadoopでGPGPU使ってデータをクラスタリングして処理速度をあげる） FujitsuのETERNUSにHDFS APIが用意されたという話。 MapRの話に似ているよと。小さめのクラスタの場合に有効？セッションの後に少し話題になった。 扇子を配りましたよと。 ※ビールが配られ始めた！（ビールじゃないという声もチラホラｗ） ◎『Hadoop Troubleshooting 101』 セッションレポート - Cloudera 嶋内さん （@shiumachi） Hadoopを壊す7つの方法 Hadoop設定したりしたことある人？＝結構いた。さすがソースコードリーディング Clouderaでは木曜日に重要なミーティング（ボードゲームするかFPSするか）というのがあるらしい。 チケット分析 設定ミス？ HadoopやOSの設定ファイルの変更を必要とするあらゆるチケットの事 35%が該当 問題の原因別のグラフ 1番は設定ミス 2番はバグ（これはベータ版リリースからチケット管理してるから） メモリの管理ミス Task Out Of Memory Error io.sort.mb \u0026lt; mapred.child.java.optsとなるように設定すること io.sort.mb = mapバッファのサイズ mapperとreducerを減らす。 mapper＝ノード上のコア数 これは机にはっとけ！ Total RAM = (Mappers + Reducers) * Child Task Heap + DN heap + 3GB + RS heap + ？ JobTracker Out Of Memory Error JTのメモリ使用量の合計　＞　割り当てRAM 原因は？ タスクが小さすぎ jobヒストリが多すぎ 解決は？ maximumを減らしなさい？ Unable to Create New Native Thread どういう意味？ プロセスが起動中にもかかわらずDNが障害ノードとして表示されている。 原因は？ nprocのデフォルト値が低すぎる 対応は？ /etc/seurity/limits.confの値を考えろ Too Many Fetch-Failures 元スライドの発表者はこれが大好きらしい どういう意味？ Reducerのfetch操作がmapperの出力の取得に失敗 ブラックリスト入りのTTで発生するらしい 原因は？ DNSの問題 対応は？ mapred.reduce.slowstart.completed.maps = 0.80 reducerの開始を遅らせることで対応 tasktracker.http.threads = 80 Jetty 6.1.26は使うな！CDH3u2に上げましょう。 Not Able to Place Enough Replicas 。。。きっとどっかにスライドあるからメモはこのへんでいいか。。。 ◎Hadoop World NYC 2011 参加レポート - Acroquest Technology 阪本 雄一郎さん （@frutescens） 落合 雄介さん （@taro_x） ・RとHadoopの融合（Revolution AnalyticsのDavid Champagneさん） R言語の紹介 Rとの接続点（rmr、rhdfs、？） R言語の利点がHadoopで使えるから、記述が少なくて済むよと。 統計処理がわからなくてもRが使えると分析ができるよ。（そう言われても、その分析で正しいのかとかは結局統計とかをある程度理解してないと厳しいんじゃないか？） ・Hadoopを使った衛星画像解析 スケールとかしたいからHadoopにしたけど、ジョブ起動遅いし、科学計算ライブラリが不十分 ・Hadoopをクラウド上に展開（vmware） Hadoopだけじゃなく、NoSQLとかもスケールしてから使いたいよねぇ。 ということで、vmwareの色々なものを使ってHadoopと他をうまく構築しますよ事例紹介。 マルチテナントのHadoopの話とかもありますよねと。 ◎最後はHadoopには関係ないのが多かったけどおみやげ争奪戦。 なぜか、MongoDBのシールをもらいました。 ということで、HadoopWorld2011の総括＋各スライドの紹介でした。 これまでのHadoopWorldの傾向などから、参加者などのトレンドがどうなっているかなどの話が聞けたのが面白かったです。 ClouderaのスライドはHadoopのトラブルシューティングとして必見になりそうな感じでした。 内容が濃くて、それほど触っていない私にはわからないところもチラホラ。（日本語資料の公開されるかなぁ？） 案の定、ビール（発泡酒）を飲んだので、途中から一部が飲み会状態になってたし、ピザ食べてたので、私のメモも途中から適当になってしまいました。 あとは、とある件についていろんなかたからの知見を入手できたのが良かったですね。 他にもLilyプロジェクト（Solrが利用されているOSSの話）の話もあったようなのですが（HPの方が教えてくれました）、今回の参加レポートでは含まれてなかったです。（話聞きたかったなぁ。余力があれば、スライド読むかなぁ。誰か発表してくれないかなぁ） 今日もまた、Twitterで絡んでいた方たち数人と面識が得られました。 今後は定期開催の流れになるようなので、これからもHadoopにしがみついていくためにも参加するようにがんばりますよと。\n会場提供のNTTデータのみなさん、発表者の皆さんお疲れ様でした。次回も期待してます！！\n2011/12/01追記 Togetterのまとめ\n","date":1322499060,"dir":"post/2011/","id":"924727b6f380cf3cdfe5650163e92054","lang":"ja","lastmod":1322499060,"permalink":"https://blog.johtani.info/blog/2011/11/29/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC7%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-29T01:51:00+09:00","summary":"Hadoopソースコードリーディング第7回に参加しました。 いつものごとく、自分用のメモをとっていたので。 第6回（2010/12）には参加して","tags":["勉強会"],"title":"Hadoopソースコードリーディング第7回に参加しました。(Jugemより移植)"},{"contents":"先週末から勤労感謝の日まで風邪で寝こんでました。。。 みなさん、朝晩、冷え込みが激しいので風邪には気をつけてください。\n季節の言葉も入れたので本題です。 つい最近、「Apache Solr入門」のサンプルをlucene-gosenでどうやって動かすんですかー？という質問を受けました。 確かに、「Apache Solr入門」を書いたのはSolrのバージョンが1.4が出る直前でしたし、lucene-gosenは存在せず、 当時はSenを元にした日本語の形態素解析のサンプルとなっていました。 そのSenも入手しづらくなってきており、私もlucene-gosenのプロジェクトに携わるようになってきてある程度時間が 経ちました。 せっかくなので、サンプルのschema.xmlだけでも最新版（Solr 3.4 + lucene-gosen-1.2.0-ipadic）のものを用意しました。 なお、あくまでも、3.xでlucene-gosenを利用する場合の「Apache Solr入門」のサンプルプログラムの変更点（とりあえず、4章まで）の違いについて記述します。 申し訳ございませんが、1.4と3.xの違いについての説明はここでは行いません。\n以下では、各章でschema.xmlに関連する記載のある部分を抜粋して、変更点と変更したschema.xmlのリンクを用意しました。参考にしてもらえればと思います。\n1章 1.6.1 N-gram（17ページ） 1.6.1の手順に変更はありません。 サンプルプログラムが入っているZip「solrbook.zip」のintroduction/ngram/schema.xmlファイルの代わりに こちらのschema.xmlを利用してください。\n1.6.2 形態素解析（18ページ～20ページ中盤まで） 手順が大きく変わります。 Senを利用する場合、Senの辞書のビルド、Senのjarファイルの配置、Senを利用するためのTokenizerクラスを含んだサンプルjarの配置という作業があります。 lucene-gosenではコンパイル済みの辞書がjarファイルに含まれています。 また、Solr向けのTokenizerもlucene-gosenのjarファイルに含まれています。 lucene-gosenを利用して形態素解析を体験するための手順は次の流れになります。 なお、schema.xmlについては上記N-gramでダウンロードしたschema.xmlに形態素解析の設定もあわせて記載してあります。\njarファイル（lucene-gosen-1.2.0-ipadic.jar）をダウンロードして、$SOLR/example/solr/lib（libディレクトリがない場合は作成）にコピーします。 コピーが終わりましたら、次のように$SOLR/exampleディレクトリでSolrを起動します。 （-Dsen.homeは必要なし）\n$ java -jar start.jar あとは、書籍の記述にしたがって管理画面のAnalysis画面で動作を確認します。 ほぼ、図1-6と同じ結果になっていると思います。 （lucene-gosenで出力される情報には本書のサンプルよりも多くの情報が含まれています。また、サンプルでは、形態素解析の後の単語に基本形を採用しているため、「な」が「だ」として出力されています。基本形を出力する場合は後述するこちらで紹介したTokenFilterを利用すれば可能です。）\n2章 2.1.3 schema.xmlのバージョン（27ページ） Solr3.xではschema.xmlのファイルの最新バージョンは1.4になっています。\n2.2.3 代表的なトークナイザ（35ページ） solrbook.analysis.SenTokenizerFactoryは必要ありません。 先ほども説明しましたが、lucene-gosenにはSolr向けのトークナイザが用意されています。 solr.JapaneseTokenizerFactoryがそれに該当します。\n2.2.4 代表的なトークンフィルタ（37ページ） 以下の2つについてはlucene-gosenに同等のトークンフィルタが存在します。\nsolrbook.analysis.KatakanaStemFilterFactory solrbook.analysis.POSFilterFactory それぞれ、次のものがlucene-gosenにあるので、こちらを利用します。\nsolr.JapaneseKatakanaStemFilterFactory solr.JapanesePartOfSpeechStopFilterFactory 2章向けのschema.xmlはこちらです。その他のtxtファイルについては、特に変更はありません。\n3,4章は特に変更はありません。Solrの起動の仕方にだけ注意してください。（-Dsen.homeは必要ありません）\n以上が4章までの修正点になります。 動作しないなどあれば、コメントください。 サンプルアプリについてはまた後日余裕があれば。。。\n","date":1322244000,"dir":"post/2011/","id":"26d48d68b28f927bfebad454658f9425","lang":"ja","lastmod":1322244000,"permalink":"https://blog.johtani.info/blog/2011/11/26/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AElucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0%E3%81%8B%E3%82%894%E7%AB%A0/","publishdate":"2011-11-26T03:00:00+09:00","summary":"先週末から勤労感謝の日まで風邪で寝こんでました。。。 みなさん、朝晩、冷え込みが激しいので風邪には気をつけてください。 季節の言葉も入れたので本","tags":["lucene-gosen"],"title":"「Apache Solr入門」のサンプルのlucene-gosen対応（1章から4章）(Jugemより移植)"},{"contents":"今回は、触ろうと思って触れていないMongoDBの勉強会に行って来ました。 2週連続の渋谷で、さすがに今回は出口をすんなりでれました。 今回は初のGMOさんのビルへの潜入です。 ということで、いつものごとく自分のメモを残しておきます。\n日時 :2011/11/15 14:30 to 20:00 定員 :140 人 会場 :GMO Yours （セルリアンタワー（11階）） ハッシュタグ :#mongotokyo\n1.fluentd plugins for MongoDB @doryokujin スライドはこちら。\nFluentとMongoDBのコラボレーション ・Fluentとは？ 解析対象のログについて。データ量が膨大 これまでのログの扱い方。日次でS3に送信して、ログ解析サーバにて前日分を解析する。 これではリアルタイム性がないのが問題！しかも1日分なので、データ量が半端ない。 そこでFluentにてストリーミングアプローチ。 リレーサーバ（Fluentd）にログを流すと、適宜、解析サーバに流れていく仕組みが可能。 これにより、ネットワークに負荷をあまりかけずにログを定期的（時次とか）で流せる。 ※splunkに近い考えかな。 ここで、Fluentのスライドで説明が入りました。http://www.scribd.com/doc/70897187/Fluent-event-collector-update ・Out Mongo For Local Back-Up MongoDBへの出力。 信頼性をあげるためにローカルにmongoDBを置いておき、スプールしておく。 リレーサーバにも配置してみるという仕組み。 バッファリングにMongoDBを使うので Aggregation Mongoってのを作ったらしい。そのせいで、スライドの作成が遅れたらしいw ・Aggregation Mongo Map/Reduceの集約のようなプラグイン。 fluentdのアプリを通して、特定のキーをベースに集計してから、outputする仕組み。 更に、キーに対してshufleが行われて、次のfluentdにデータが集まる。　fluentdを使ってM/Rっぽいことが可能なのかな。 QA 最終的な流れ込み先のMongoDBはCappedCollectionじゃなくしたほうがいい。検索とかしたくなるから。 2.about Server Density and MongoDB @davidmytton スライドはこちら\nQueuingシステムで利用。 MongoDBとRabbitMQとの比較？ MongoDB関連のノウハウかな。 データ量に関する話。メモリに載せたほうがいいのかとか、ログ出力の設定とか、ジャーナルとか。 HDDの見積もりに関連しそう。 健康状態の監視方法。 コネクションプールの話とか。 rs＝ReplicaSet？ mongostatってコマンドがあるのか。 ServerDensityのツールとダッシュボードなどについて。 ※英語のスライド見ながら話聞くとメモがとれない。　まとめ： Keep it in Ram インデックスはメモリに載せましょう。 Watch your Strage ストレージのサイズは監視しましょう。（ログ、データ、ジャーナルなどなど） db.serverStatus()　コマンドあるよ。これで見れるデータが重要なのかな？ rs.stats()　コマンドあるよ。これで見れるデータが重要なのかな？ QA：残念ながら聞き取れなかったっすｗ Q：MongoDBのクエリログの統計の質問。DBごと？＝コレクションごと？のクエリ統計のとり方は？ A：MongoDBにはないので、ログレベルを下げて統計取ったりする方法しかないかなぁ。 3.MongoDB: Case Study for AMN @koyhoge スライドはこちら\nサービス（アジャイルメディア・ネットワーク）で利用している実例について 広告配信に関連して利用してる。 最初にPostgreSQLにて実装。5分おきにCronで再起動するはめに。。。 PostgreSQLの次にSimpleDBへ（インサートが遅い。分散インサート） SimpleDB＋SQSに変更。1日130$で断念。 SaaSなKVSはやめてMongoDBに移行してみる。 負荷も軽いし、インサートも速い！ EC2でMongoDB。しかもレプリカを東京A、B、シンガポールAにしてみよう。 shardingは残念ながらうまく行かず。 ストレージはEBSの1TB 4.「MongoDBとHadoopの蜜月関係」 @muddydixon スライドはこちら\nお父さんエンジニアなので、土曜日の勉強会は無理です！＝同じく辛いです！ HadoopとMongoDBのつなぎについて。 MongoDBからデータを読み込んで、Hadoopで計算してMongoDBに戻すものがmongo-hadoop データロストがニュースになってて心配してる。データロストはめったにない（by @doryokujin） Hadoopを計算だけに利用できるのでクラスタが落ちても気にせず立ち上げができそう。 MongoDBからデータを取得する時点でフィルタリングが可能なので、Hadoopでの演算が楽。 AdHocなクエリをMongoDBに投げれるのがうれしいのかな？ HBaseとかHiveに入れてやったりはダメなんかな？ QA Q：なんで、みんなMongoDBにログ入れるの？@kzk_mover A：様々な形式を入れやすいから。 Q：捨てるのどーするの？ A：コンパクションが大変（ただし、2.0以降は良くなる予定） Q：MongoDBのMap/Reduceは？ A：時間がかかった上に死ぬというひどい目にあったので。。。 5.Fusion-io @hasegaw\n340の仮想マシンが4台で動きます！ すごそう。。。一回は触ってみたいかも。 Fusion-ioすげーーーって感じ。（Ustストップ） 6.MongoDB on Cloud Foundry @yssk22\nVMWare社のPaaSオファリングの名称 感想など： mongoDBに興味はあるのに、腰が引けてるおじさんになって結局触らずに会場入りしてしまいました。 会場に入っていきなり、Treasure Dataの太田さんがマグカップを売っているという場面に遭遇するというインパクトがあるスタート。（思わず1個購入） 最初はMongoDB JPの主催者でもある@doryokujinさんの話から。今熱いfluentdとmongoDBの組み合わせに関する話で、面白かったです。 途中でfluentdを作っている古橋さんのスライドを用いてfluentdの解説まで入りました。 TL上では、その古橋さんが時々フォローを入れているという贅沢な流れ。 なんとなく仕組みはスライドなどを見ていたのですが、更に理解が深まりました。 次が、イギリスから来日されていた@davidmyttonさん（なんと24歳という若さ！）のお話。 残念ながら英語のヒアリングは微妙な私なので、あまり理解できなかったのですが、どうやら、MongoDBの運用でのTipsのお話だったようです。スライドを後で見なおしたほうがいいかな。 次は、実際のMongoDBを利用した事例の紹介。PostgreSQLから試行錯誤してMongoDB＋AWSの組み合わせのお話。 やはり実例があると面白いですね。試行錯誤された部分があるので、非常にわかりやすかったです。 次が、HadoopとMongoDBの組み合わせのお話。HadoopのMap/Reduceの部分だけを利用して、データ保存先はMongoDBにしましょうという割りきった話でした。 いくつか疑問点がメモにもありますが、残念ながら質問する勇気なしという腰抜けっぷり（もうちょっと積極的にならないと。。。） で、このあとFusion-ioとCloud Foundryの話になるのですが、体力切れ＋lucene-gosenのjavadocが古いことに気づいてしまい、作業をしながら聞いていたのであまり頭に残っていません。（ほんとに申し訳ない。。。） とまぁ、最近、Twitter上でいろんな人に絡みまくってまして、@doryokujinにも絡みまくってたというのもあり、今回参加することにしたという次第でした。 懇親会にも多くの人が残っており、良いコミュニティができてるなぁというのが正直な感想です。 各セッションでも@doryokujinさんが適宜QAなどのフォローをされていて感心しっぱなしでした。 あとは、Twitter上で会話をしていた方たちとも顔合わせができたので、大収穫でした。\n次は、少しでもいいので、触ってから参加することにしようかと思います。 来年1月にはMongo Tokyo 2012というイベントも開かれるようで、ますます注目を浴びていきそうですね。主催者もミドルウェアもｗ\nあ、そうそう、そんなMongoDBの勉強会でしたが、CouchDBの話もちらほら出てまして、CouchConf TOKYOというチラシも@Ijokarumawakさんから頂きました。こちらも1月開催のようです。\n追記： 戦利品の画像です。マグカップ（500円）以外は貰い物です。 なんと、このUSBにはMongoDBのコマンドやクエリのチートシート（PDF）が入ってました。びっくり！\n","date":1321376880,"dir":"post/2011/","id":"bda9a5da86ec9790262e14f953bbadcb","lang":"ja","lastmod":1321376880,"permalink":"https://blog.johtani.info/blog/2011/11/16/mongodb%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC7%E5%9B%9E%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-16T02:08:00+09:00","summary":"今回は、触ろうと思って触れていないMongoDBの勉強会に行って来ました。 2週連続の渋谷で、さすがに今回は出口をすんなりでれました。 今回は初","tags":["勉強会"],"title":"MongoDB勉強会（第7回）に行って来ました。(Jugemより移植)"},{"contents":"Solr本の武田さんから教えていただいたSplunkの イベントに行って来ました。 Splunkとは様々な機器のログなどを一箇所に集めてリアルタイムに検索、分析できるようにするための製品です。（ざっくりした説明ですが。。。） ちなみに、データ量が小さければフリー版も用意されています。 以前、話しを聞いていて気になっていた所イベントが開催されるということだったので参加してきました。 以下に、その時取ったメモを記載しておきます。いつものごとく、自分用のメモなので、役に立つかはわかりませんが。\nSplunk Live! in toyosu\n日時：2011/11/02　10:00-12:00 場所：豊洲\n1.挨拶＋アジェンダ紹介 2.ビッグデータ取り込み、ロードマップ（Splunk Inc.）CEO Godfrey Sullivan 英語でした。。。 データの種類と量が大きくなってきてるのに、ツールが追いつかないし、回答するのもはやくしろと言われる。 非構造化データの例としてApacheのログが出ていた。 TimeSeriesのフラットファイルがsplunkのデータのインデックス。（No RDB＝スキーマいらないよと。）　※ここが重要な点かもしれない。 リアルタイムに解析できるのが売り。Jubatusとの違いとか聞くと面白いかも。 Machine Data Engine＝Splunk データの関連付けの方法がどんなものか？ 事前のスキーマが不要＝流しこむ前には定義が必要？だよね？ ？No need to filter/forward？？ デベロッパーフレームワークってなんだ？？ Splunkbaseと呼ばれる場所にSplunk Appsと呼ばれるアプリケーションがある。色々な場所、OS、アプリで利用できるものらしい。 ？自動監視も学習する仕組みがある？？ それとも定義するのか？ あくまでもMachine Dataと言っている。これは、ユーザのリレーションの解析などはないということか？ Leading Social Gaming Company＝Zynga Introscopeのログバージョンに似てるかもなぁ。 Cloudベースのアプリの解析にも利用（saleforce） 色々な利用シーンのお話。 3.適用事例（独立行政法人理化学研究所） 和光と神戸で利用。10G程度のデータを扱ってる？ ログから情報基盤を監視するのに利用している。 syslogベースでsplunkにログを送信している。 事例１：VPNに接続できない（接続数上限がある？） CISCOのログから解析 どの研究室で発生しているかも検索。 事例２：DHCPの接続ミス？（IPアドレスロスト） ここまでは問題が発生してからログを漁るという使い方。 事例３：LINK FLAPのアラート 短時間にUPDOWNを繰り返す場合にスイッチがおかしくなってるんでは？ 事例４：メール大量送信（ウィルス感染） 不特定多数のサーバに短時間でメールを配信している ※使い方としては情報基盤環境すべて（ネットワークとかサーバなど）のログを集めておいて監視＋解析に利用して障害対応などに利用している？データセンターとかに入れるのか？ あくまでも、ログを保存して、検索できる仕組みが１箇所にまとめられているという感じ。 そのログの解析について（どういった問題に対して、どういったクエリを投げるか？どういったトラップを仕込むか？）は利用する側の腕にかかっている印象。 ※実際に触ってみたいなぁ。500M/dayか。ご近所に入れてみるか？syslogで転送設定＋入れるサーバが必要。 4.最新アプリなどの紹介（Splunk Inc.） GUIがきれいだなー（最近のgoogleっぽいが。。。） リアルタイムにデータが入っているのが見えるのか。おもろいな。 どこのフィールドにヒットしたかがファセットで表示できるらしい。おもろい。 flashでできたビューがすごくおもろかったぞ。（ドキュメントどこだ？） 5.最新の取り組み（NTTデータ先端） やっぱり武田さんだった。 複数の監視システムのメッセージを統合して検索、アラートを出せるようにする。 消費電力を算出するためにログを集めて集計する。 6.QA ロードマップ ・２年以内にビジネスサイドでの利用に向けての動きを見せていく予定。 ・アプリケーションフレームワークにして、他のパートナーのアプリを載せていきたい。 ということで、感想ですが、事例紹介などを聴いた感じだと今のところはインフラ系のログを一元化して検索、監視、アラートをあげるということに活用するためのツールの用に感じました。 当初の使い方がそういったところにあるためだとは思いますが。 開発者としての視点で話しを聞いていて、活用できそうだというのは次のシーンでしょうか。\n開発時の開発環境のログ集約 性能試験などでのログ、性能データ集約 開発時点もしくは性能試験時ですが、色々なサーバ（DBやアプリサーバ）の時間を横串にして表示検索などができると思うので、問題があった時の各種サーバの状態を一元的に見れるため、どのサーバにどういった負荷がかかっていたか、 どこに問題があったかなどをグラフ化して見ることが簡単にできるのではないかなぁという感想です。 あとは、ログが一元化されているので、問題があったときにまずログを検索すればいいのが楽ですかね。\n基本的にはログが集まってるからあとは、どう使うかはご自由にという印象でした。 どのようなログを集めておき、どういったトラップでアラートさせるか、どのような検索をすれば望んでいるログが出てくるか、どのような集計をしたいかなどについては、やはり導入してからノウハウを貯めていくか、導入時にコンサルしてもらうなどが必要かと。 また、このツールを入れることでどのようなフィードバックをどのように活用できるかをイメージしていなければ、 宝の持ち腐れになりそうです。 あとは、使い方次第ですが、サーバログ以外にアプリログ（ユーザの行動履歴とか）などを入れることで、インフラ以外での使い道もありそうです。 とりあえず、保存しておいて、あとから特定の傾向を見出すのに検索できるのはちょっと面白いかも。\nあ、そうそう、ストラップとUSBメモリ（4G）のノベルティをお土産にもらいました。無料セミナーなのに。\n","date":1320822000,"dir":"post/2011/","id":"cc1a3b2f107510ac664e491d5f2412aa","lang":"ja","lastmod":1320822000,"permalink":"https://blog.johtani.info/blog/2011/11/09/splunk-live%E3%81%AE%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-09T16:00:00+09:00","summary":"Solr本の武田さんから教えていただいたSplunkの イベントに行って来ました。 Splunkとは様々な機器のログなどを一箇所に集めてリアルタ","tags":["misc"],"title":"Splunk Live!のイベントに行って来ました。(Jugemより移植)"},{"contents":"最近忘れやすいので、記録しておこうかと。 読んだスライドの簡単な内容と感想です。 ちなみに、スライドの一覧はこちらです。 ※スライドへのリンクはすべてPDFへのリンクになっていますので、注意が必要です。\nSolr 4 Highlights（PDF）\nSolrの次期バージョン4.0で採用される機能の紹介でした。 紹介されているのは次の機能。各機能について、JIRAの番号も記載があるので便利ですね。\nDirectSolrSpellChecker NRT (Near RealTime search) Realtime Get SolrCloud - search side SolrCloud - indexing side (WIP) これまでと異なるSpellChecker、Commit前のデータが検索できるNRT（なんでNRSじゃないんだろう？）、Commit前の登録済みデータを取得することが出来るRealtime Getなどの簡単な紹介です。 あと、個人的に興味のあるSolrCloud周りが絵付きで紹介されてます。ZooKeeperもちょっと出てきます。 まだ、ちゃんとまとめてないですが、NewSolrCloudDesignの翻訳したものも参考までに。（その１、その２）\nArchive-It: Scaling Beyond a Billion Archival Web-pages\nInternetArchiveの事例紹介。1996年からWebページのアーカイブを行なっているサイトですね。 その一部でSolrが利用されています。 「1,375,473,187 unique documents」との記述もあり、データ量が巨大です。 データ量が多いのに、ここでFieldCollapsing/Groupingも利用しているようで、インデックス作成、検索両方に対してカスタマイズしたものをgithubで公開している模様です。\n[**Scaling search at Trovit with Solr and Hadoop**](http://www.lucidimagination.com/sites/default/files/file/Eurocon2011/MarcSturlese_scalingsearchTrovit_eurocon2011.pdf) 次は、Trovitという会社のSolr＋Hadoopの事例紹介です。 最初はLuceneをベースに検索サーバ作ってたけど、Solrが出てきたので、Solrを使うようになったようで。 データ保存先として最初はMySQLを利用してDataImportHandlerでSolrにデータ登録してたけど、 データ量が増加するが、MySQLのShardingが面倒なので、Hadoop（Hive）でデータをパイプライン処理してSolrのインデックスを作成しましょうという流れになったようです。 私が以前、Solr勉強会で紹介したSOLR-1301のパッチをベースにMap/Reduceの処理を2段階にして性能をアップさせたという話が記載されてました。 ただ、これで早くなるのかはよくわからないんですが。。。 一応、資料では、いきなり大きなSolrのインデックスを作らずに、最初のM/Rで小さなインデックスを作成し（TaskTrackerの数＞＞Solrのshardサーバ数だから小さくしたほうが速い？）、 2段目のM/Rでインデックスをマージしてshardサーバ数のインデックスに集約する？という形みたいです。 （英語力のなさが。。。） あとは、テキスト処理を幾つかHadoopでやってますよという紹介でした。 SOLR-1301の利用者が他にもいて、違うアプローチをとっていたのが印象的。 毎回全データインデックス生成するときは、SOLR-1301を利用してshard数が増えてもすぐに対応が可能になるので、 かなり便利ですよ。\nSolr @ Etsy\nEtsyは個人の作家（編み物とかシールとか）の方が出店するためのショッピングモールのようなサイトです。 実は、最近、MacBookAirのステッカーを購入したのがここでした。 で、検索にSolrを使っています。 面白いのが、検索サーバとWebアプリ（PHPで書かれている）の間のデータのやり取りにThriftを利用していること。 Solrの前にThriftを話すサーバを別途用意しているようです。ネットワークのデータ量を減らすことが目的らしいです。 そのあとは、少しThriftのサーバでのLoadBalancingの話が続きます。 次にレプリケーションの性能問題のはなし。定期的にレプリケーションに異様に時間がかかるのが問題になったようで、 Multicast-Rsyncを試してみたけどダメでしたというはなし。 Bit Torrent + Solrという組み合わせで回避したらしいのですが、いまいち仕組みがわからなかったです。。。 こちらもgithubに公開されている模様。 あとは、QParser、Stemmerをカスタマイズしたものの話です。\nArchitecting the Future of Big Data and Search\nLuceneのカンファレンスにHortonworksが出てきてびっくりしました。 まぁ、Luceneの生みの親＝Hadoopの生みの親ですから、問題ないのかもしれないですが。 大半が予想通り、Hadoopに関する話でした。 知らないApacheのプロジェクト「Ambari」というのが出てきました。これは、HadoopConferenceJapan2011 Fallでの発表にもチラッと出てきたようです。 「Ambari is a monitoring, administration and lifecycle management project for Apache Hadoop clusters.」ということで、Hadoopクラスタの統合管理のツールになるんでしょうか？ 最後の2枚くらいにLuceneが出てきます。絡めてみたって感じですかね。\nConfiguring mahout Clustering Jobs\n今度はMahoutが出てきました。はやりのものが満載です。 まぁ、MahoutもLuceneのインデックスを利用するという話もありますので。 スライドはクラスタリングとはどういうものか、Mahoutの説明とテキストクラスタリング処理のお話、最後はstuckoverflowでのMahoutとSolrの活用の仕方について。\nということで、英語力がない中、かなり流し読みな感じですが、あとで思い出すために書きだして見ました。 何かの役に立てれば幸いです。\n他に、こんなスライドが面白かったとか、このスライドについても書いてほしいなどあれば、コメントください。\n","date":1320724920,"dir":"post/2011/","id":"d9c6ab5c6630a4a84e242c5765103d2d","lang":"ja","lastmod":1320724920,"permalink":"https://blog.johtani.info/blog/2011/11/08/lucene-eurocon-2011-barcelona-%E3%81%AE%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%89%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-08T13:02:00+09:00","summary":"最近忘れやすいので、記録しておこうかと。 読んだスライドの簡単な内容と感想です。 ちなみに、スライドの一覧はこちらです。 ※スライドへのリンクはす","tags":["solr"],"title":"Lucene Eurocon 2011 Barcelona のスライド読みました(Jugemより移植)"},{"contents":"Bookscanというサービスがあります。 書籍を電子化（PDF）して原本を破棄してくれるサービスです。\n電子書籍にはずっと興味を持っていました。 技術書を購入するのですが、技術書は３００ページ超の大きな書籍が大半です。 また、日本語の技術書については、なかなか電子書籍が見つからないもしくは、電子化されるのが遅いとうのが現状です。 海外では、Manningなど、電子書籍も同時に発売（もしくは、製本前から電子書籍が売られている）サイトがありますが、やはり英語の書籍はハードルが高いなぁと。\nそんな中、Bookscanの噂を耳にしました。 ということで、どんどん、積ん読になっていく技術書だったので、思い切って、電子化してみることにしました。 ※残念ながらまだタブレット（電子書籍端末）は持っていないのですが。。。もうすぐ発売されるlenovoの7inchタブレットを待ちかねているところです。\nBookscanでは、１冊１００円で書籍をPDFにしてくれます。（ページ数により変わってくる） この場合、あくまでも書籍をスキャンするだけで、検索などはできません。 OCR処理については別途１冊１００円（これもページ数による）のオプションが必要になります。 詳しいサービス内容はこちらを御覧ください。 基本的には書籍をBookscanに発送してから約３ヶ月ほど電子化するのに時間がかかります。 これでは、すぐに見たい場合に手元にないという状態になってしまいます。 この電子化までの時間を短くできる、「プレミアム会員」というオプションが存在します。 月額固定の費用（９９８０円）を支払うことで、５０冊（※ページ数により１冊の単位が異なります）まで無料で、「スキャン＋OCR＋書籍名をファイル名」のPDFファイルを書籍到着後１週間以内で作成してもらうことができます。 また、プレミアム会員は月単位での契約が可能なようで、１ヶ月（＝５０冊）だけ早く電子化してもらうといった利用方法もできるようです。\nで、実際にプレミアム会員となって４９冊の書籍を送付して電子化してもらいました。 先週金曜日に発送、Bookscanに書籍が到着したのが翌土曜日、電子化が完了したのが火曜日の夜という感じでした。 すごくはやい！かなり感動してます。自炊自体をしたことがないので、出来上がりが自炊と比べてという比較はできないのですが、ざっと見ている感じでは全然問題なく読めそうです。\nただ、１冊の２ページだけ、ページの端が文章の途中で切れているPDFがありました。 この書籍に関しては、サポートサービスにお願いして、再スキャンをしてもらいました。 昨日夜に頼んで今日の午後には問題なく電子化されているというサービスの質でとても満足しています。 なお、原本の破棄が電子化後から１０日後に行われるため、問題ないかの確認はそれまでに行う必要があるようです。 大量の本を送る場合は小分けに送ったほうが確認するのが楽になると思います。（送料は小分けにした分、かかってしまいますが。）\n書籍の山になっていた机がすっきりして、とても満足しています。 せっかく電子化したので、早くタブレットが欲しいなと思う今日この頃。。。 基本的には今後は電子書籍を購入するようにしていく予定なので、プレミアム会員を継続することはないと思いますが、 家に溜まっている漫画を電子化するのもありかなぁと思っているところです 漫画の場合はOCRに掛ける必要もないですし。\n個人的にはBookscanさんには悪いのですが、もっと電子書籍が増えると助かります。 技術書はページ数が多く、重たいうえ、実際に利用するときは検索したくなることが多々ありますので。 あとは、電子書籍を検索できるサイトがあるといいなと思ってもいるところです。 現在は、各出版社が個別に電子書籍のHPを持っている状況で、会社によっては検索すらできないです。 電子書籍があるかないかだけでも簡単に検索できると、いいなと思っています。（小説などはまた別なのかもしれないですが。） みんなはどう思ってるんですかねぇ？検索したくないですか？\n","date":1320225060,"dir":"post/2011/","id":"7a9609a971a8f31685e88da563eea5ce","lang":"ja","lastmod":1320225060,"permalink":"https://blog.johtani.info/blog/2011/11/02/bookscan%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-02T18:11:00+09:00","summary":"Bookscanというサービスがあります。 書籍を電子化（PDF）して原本を破棄してくれるサービスです。 電子書籍にはずっと興味を持っていました","tags":["misc"],"title":"Bookscanを使ってみました(Jugemより移植)"},{"contents":"lucene-gosenの最新版（1.2.0）をリリースしました。\nプロジェクトページよりダウンロードが可能です。\n新規追加機能についてはこちらのエントリを御覧ください。\nバグなどありましたら、容赦なく報告をいただけると助かります。\n","date":1320043560,"dir":"post/2011/","id":"14cf6e75aec1ead888e7101d3d94d28a","lang":"ja","lastmod":1320043560,"permalink":"https://blog.johtani.info/blog/2011/10/31/1-2-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2011-10-31T15:46:00+09:00","summary":"lucene-gosenの最新版（1.2.0）をリリースしました。 プロジェクトページよりダウンロードが可能です。 新規追加機能についてはこちら","tags":["lucene-gosen"],"title":"1.2.0リリース(Jugemより移植)"},{"contents":"すぐやりますと言いつつ、はや1ヶ月。。。 腰が重い、ダメエンジニアですね。。。\nすみませんでした。。。 ようやくtrunkにコミットしました。 すぐにリリース版を用意すると思います。\n1ヶ月もあいてしまったので、追加した機能に関するまとめと、 用途別の利用方法を記載しておきます。 （lucene-gosenのWikiにもそろそろ書かないとなぁ。日本語でもいいから。）\n追加した機能\nこれまでのlucene-gosenはjarに辞書を含む形でライブラリを提供していました。 ただ、この場合、カスタム辞書を利用している環境ではカスタム辞書を修正し、ビルドしなおすたびに、 jarファイルを作成しなければなりません。 また、jarファイルをSolrなどに配布する必要も出てきます。 この手間を考慮して、辞書を外部ディレクトリで指定することができるようにしたものが 今回の修正になります。 また、修正の過程で同一VM内で異なる辞書を使えるようにする機能も副産物として生まれました。 今回追加した機能は次のようなものになります。 辞書を含まないjarのビルドおよび提供 ディレクトリ指定による辞書の指定 同一VM内での複数辞書の利用 辞書リビルド用のAntターゲットの追加 Lucene/Solr jarファイルの最新化（3.4.0対応） ディレクトリ指定による辞書の指定ですが、以下のような形になります。 まずは、LuceneのTokenizerでの指定方法です。 「辞書のディレクトリ」という引数が追加になっています。 ここに、辞書ディレクトリ（*.senファイルが存在するディレクトリ）を相対/絶対パスで指定します。\n... Tokenizer tokenizer = new JapaneseTokenizer(reader, null, \u0026#34;辞書のディレクトリ\u0026#34;); ... つぎは、Solrでの設定の方法です。 schema.xmlにて次のような設定を行います。\n... \u0026lt;fieldType name=\u0026#34;text_ja\u0026#34; ...\u0026gt; \u0026lt;analyzer\u0026gt; ... \u0026lt;tokenizer class=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; compositePOS=\u0026#34;compositePOS.txt\u0026#34; dictionaryDir=\u0026#34;辞書のディレクトリ\u0026#34;/\u0026amp;gt; ... \u0026lt;/analyzer\u0026gt; \u0026lt;/fieldType\u0026gt; ... schema.xmlの設定については、example/schema.xml.snippetにも説明がありますので、こちらもあわせて参考に。 なお、Solrの設定については、先ほどのLuceneでの辞書のディレクトリの指定方法（絶対/相対パス）に加えて、 $SOLR_HOME/conf からの相対パスでの指定も可能になっています。\nAntのターゲットについて\n辞書なしjarファイルを作成するターゲットなどを追加しています。 実際に追加したターゲットは以下のとおりです。 ターゲット名 説明 nodic-jar 辞書なしのjarファイルを生成するためのターゲット。辞書のダウンロード、コンパイルは行いません。 rebuild-dic lucene-gosenのビルド済み辞書（.senファイル）を削除してから辞書のコンパイル（ビルド）を行います。-Ddictypeにより辞書のタイプ（ipadic|naist-chasen）の指定が必要です。また、-Dcustom.dicsによりカスタム辞書の指定もあわせて可能です。 build-dic-ipadic テスト用に追加。-Ddictype=ipadicを指定してbuild-dicを実行。 build-dic-naist-chasen ついでに追加。-Ddictype=naist-chasenを指定してbuild-dicを実行。 最後の２つはあまり関係ありません。内部的に有ると便利だったため、作りました。 重要なのは最初の２つです。 ひとつめの「nodic-jar」は辞書を含まないjarファイルをビルドします。 このjarファイル＋辞書の入ったディレクトリを利用することで、辞書の外部化が可能となります。\nそして、「rebuild-dic」です。こちらは、以前記事に書きましたが、カスタム辞書のコンパイルが思いの外面倒だったので、ターゲットを追加しました。 次のように指定することで、辞書のリビルドが可能です。\n$ ant -Ddictype=naist-chasen -Dcustom.dcs=\u0026#34;custom1.csv custom2.csv\u0026#34; rebuild-dic 提供されるjarファイルについて\n提供されるjarファイルは次のようになる予定です。 1番目のjarファイルが今回追加になる、辞書なしのjarファイルになります。\nlucene-gosen-1.x.x.jar lucene-gosen-1.x.x-ipadic.jar lucene-gosen-1.x.x-naist-chasen.jar 用途別の利用方法 利用用途別に利用するjarファイルやantのターゲットを利用シーンを交えて想定を書いてみます。 Solrでの利用シーンを想定します。\nお手軽に使う。辞書ありjarファイルで一発インストール。 これまでどおりの使い方になります。 辞書込みのjarファイルを利用すれば、すぐに利用可能になります。\nカスタム辞書を使い倒す。定期的に辞書をメンテナンス。 定期的にシステム固有の単語が増える（例：製品名、新語など）場合です。\n利用するjar：lucene-gosen-1.x.x.jar 辞書のコンパイル＋配置：ant -Ddictype=naist-chasen -Dcustom.dics=\u0026ldquo;custom1.csv\u0026rdquo; rebuild-dir Solrの該当コアのRELOAD Solrのマルチコア環境を利用します。なお、sharedLib設定にlucene-gosen-1.x.x.jarを配置すると、辞書の再読み込みができないので注意してください。 設定は、上記のようにTokenizerFactoryの設定でdictionaryDirにて辞書のディレクトリを設定しておきます。 カスタム辞書に単語を追加後、antにて、辞書のリビルドを行います。 リビルドした辞書ファイルを必要に応じて対象の辞書ディレクトリにコピーします。（ビルド後のディレクトリをそのまま利用している場合はコピーの必要はないです。） 最後に、Solrの該当コアのリロードを行います。（リロードの仕方はこちらを参考に。） コアのリロードにより、辞書の再読み込みが行われるので、リロード後から新しい辞書が適用されます。\n異なる辞書を使い倒す。TokenizerごとにdictionaryDir設定するぞ 1つのSolrで異なる辞書を使ったフィールドを使いたい場合です。 ipadicとnaist-chasenといった異なる場合はあまり想定できないですが、カスタム辞書の部分が異なるという形が想定できるでしょうか。（例：製品名のフィールド、企業名のフィールド。。。など）\n利用するjar：lucene-gosen-1.x.x.jar 設定：schema.xmlに異なるdictionaryDirを設定したTokenizerFactoryを設定 上記、カスタム辞書の定期更新も一緒に行うことも可能です。コアをリロードすれば、リロードしたコアで利用している 辞書がすべてリロードされます。\n最後に 遅くなってしまいましたが、ようやく、trunkにコミットしました。 できるだけ速く、リリースしますので、もう少々お待ちを。\nSolrのconfディレクトリからの指定については、＠shinobu_aokiさんにパッチを提供してもらいました。 また、trunkにコミットしていないパッチを適用して記事を書いてくれた方もいらっしゃいました。こちらもあわせて参考に。私より説明が上手です。 Java製形態素解析ライブラリ「lucene-gosen」を試してみる\n","date":1319559120,"dir":"post/2011/","id":"14a6d294550c9760aec57ba29682a750","lang":"ja","lastmod":1319559120,"permalink":"https://blog.johtani.info/blog/2011/10/26/%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%A4%96%E9%83%A8%E5%8C%96%E3%81%A8lucene-solr3-4%E5%AF%BE%E5%BF%9C/","publishdate":"2011-10-26T01:12:00+09:00","summary":"すぐやりますと言いつつ、はや1ヶ月。。。 腰が重い、ダメエンジニアですね。。。 すみませんでした。。。 ようやくtrunkにコミットしました。 すぐ","tags":["lucene-gosen"],"title":"辞書の外部化とLucene/Solr3.4対応(Jugemより移植)"},{"contents":"JJUG CCC 2011 Fallに参加してきました。 個人的にはかなり久々のJavaのカンファレンスです。（※あくまで「Javaの」という話で。SolrやHadoopとは別という意味です。）\n概要やタイムテーブルはこちら。 予定があったので、残念ながら最後の２つのセッション（Scala、Twitter）しか参加できませんでした。 Hadoopの話も聞きたかったのですが、しょうがないかと。 いつものごとく、メモを個人的に取ったので。\n★楽々Scalaプログラミング 浅海 ◎OOPからOFPへの道しるべ ・関数型の使い所、プログラミングのコツ ・つながりの部分 ◎最近の活動 モデリングからモデル駆動によるソース生成などに利用。 Scala、2008年から使い始めている ◎Scalaと他の機能との比較図 ◎Scalaの用途 ・高い生産性 体感で3倍。コード量が少なくなる。 IDEのサポートを考えるとまだ、Java+Eclipseのほうが高い！ ・DSL ドメインモデルの記述 フレームワークAPI ・並行プログラミング Many Core 消費電力的に複数のコアで動かす＝関数型のほうが並行性が上がる（スレッドさわるJavaだけだときつい） Parallel Everything Object指向＋関数型が扱いやすい。 ◎関数型言語とは ・公開関数をあつかえる 関数を値として扱える、引数と返却地に関数を渡せる。（やさしめ） ＜＝＞ 数学（ラムダ計算、圏論など）的にプログラムを記述できる（きびしめ） ある程度使えるはず。厳しめの部分も ◎関数型言語の長所と短所 長所 ・高階関数を使った技が使える List（？？？） 短所 ・メモリ、関数実行オーバーヘッド、スタックの大きさが読めない（再帰的） ◎関数型言語の系譜 純粋関数型言語 pure Lisp 伝統的関数型言語 OCaml 新世代関数型言語 Haskell Scala 型クラス 代数データ型、モナド Parametric polymorphism ◎関数型でしたいこと DSL（Domain Specific Lanuguage） 昨年の資料を参考に！ ◎準備 scalaの文法 ◎並列コレクション スレッドを利用しないで並列に動作実行させるか？ ※List().par.map(sitelen).sum これで並行実行させられる。 ◎Future （これってJavaでもあるよね？＝あるよ） 処理を非同期で先行実行し、あとから結果を取得可能 Scalaではアクターライブラリでサポート（cala.actors） 関数合成するとFutureの実行結果を取り出す所でブロックされる！！ ◎Promise Futureより強力 関数合成すると、合成関数全体が非同期実行される！ scalazを利用してた ◎5つのコツ コツ１：　y=f(x) 引数がひとつの関数が基本 関数合成のビルディングブロックになるよ 引数が複数ある関数は他の関数（map関数とか）で合成しにくい 対処方法：カリー化（関数の戻りを関数とする） addc(a: Int)(b: Int) : Int = a + b とすることで、 コツ２：分割統治 コツ３：演算は転換 flatMapとかfoldLeftとか ※永続データ構造 前に作ったデータ コツ４：オブジェクトの世界と関数の世界を分ける 更新指示書の形でObjectに渡す？ 関数型データ構造 コツ５：新しいデザインパターン 関数型プログラミングの用語 ・Functor（関手） ・Subgroup（半群） ・Monoid（モノイド） ・Monad（モナド） OOPのデザインパターン的に考えれば、数学的なところまで理解しなくてもよさそう？ ★Twitterとオープンソース　@yusukey http://dev.twitter.com http://bit.ly/tdt-ja id：twj_dev ◎OSSとの関わり 支援してます。 Apache、Eclipse、Open Invention、JCP、OpenJDK パフォーマンス系のためにもOpenJDKに参画してる ◎Twitter API オープンなAPIで無償提供 １３言語でAPIライブラリがあるよ ◎Twitter4Jのこれまで ほぼ全てをカバー APIはだいぶ落ち着いてきていて、追加変更は少なくなってる。 ◎立ち位置 Twitterはコミュニティを活発にするためにもライブラリを出さないらしい。 ◎Twitter4Jのこれから キャッシング ストリーミングAPI利用を簡単に モックテスト レートリミットの影響を受けると辛いから。。。 ツイート/ユーザの永続化機能 jClouds対応？ ライブラリからフレームワークへ 半公式ライブラリへ github/twitter/twitter4jへ JSR Social API Twitter4Jが参照実装に？？？ スケーラビリティの話。 Hadoopはユーザのデータ解析とかに使ってる。 メッセージはキューイングしている。デモ。 memcachedプロトコルなんだけど、値を取ると値が消えるよ。（memcachedとは動きが違うよねー。プロトコル的にはクライアントがいっぱいあっていいよねー） RubyのGCがきつかったのでJavaベースに変更 Kestrel（Scalaで記述。） Kestrelのフォーカス外 メッセージの順序保証（してないよ） トランザクション memcachedプロトコルの拡張１ ブロックフェッチ コンシューマから取りに行くというのが特徴 memcachedプロトコルの拡張２ リライアブルフェッチ ということで感想。\nScalaは前から気になっていて、本までかってるのになかなか手を付けられていない始末でした。 そんな時にこのJJUGの話があったので、ちょうどいいと聞きに。 関数型やScalaのぼんやりしたイメージのみを持って聴いていたのですが、思った以上にキーワードが多くてついていくのがやっとというイメージ。 で、いつものごとく、Twitterでつぶやいていた所、色々な反応が。（わからずにつぶやいたのもあり、波紋を呼んだ模様） お陰で、Scala関連の方たちをフォローできたので結果オーライでした。 話の内容自体はサラっとながす感じだったので、再度資料を見る＋Scalaをもっと勉強しないと理解出来ないなぁという印象でした。 ちなみに、資料はこちら。\n次は、最近Twitterの中の人になった山本さん（@yusukey）の話しを聞きました。 Twitter4Jの話と、TwitterのOSSへの関わりの話。あとは、実際にTwitterが作成しているOSSのひとつKestrelについて。 TwitterはRubyベースで色々と作ってきていたのだが、Java（JVM上で動く言語（Scalaなど））に徐々にシフトしているというのが一番の印象です。あとは、Lucene、Hadoopなど私の興味のあるOSSも利用しているなど。 Kestrelについてはデモを交えながら、実際の動きを説明されていたのでとてもわかり易かったです。 プレゼン中もTweetを表示しながらという、さすがTwitterの中の人という印象でした。 Twitterでは少し前から知り合いだったのですが、実際にお会いできた（イケメンでしたよ！）のも収穫でした。 次はStormの話も聞きたいかなぁ\nで、２セッション（山本さんの話のあとにLT大会にも参加）だけですが、全体の感想を。 「クロスコミュニティカンファレンス」というだけあり、Java以外の話題（CouchDBとか名前がありました）もちらほらあったようです。 ただ、最近の他の勉強会やカンファレンスに比べると人が少ない印象でした。 私が参加したセッションは比較的大きな部屋だったせいもあり、40～50人くらい入っていたと思うのですが、ガラガラな印象でした。良い意味で、Javaも安定してきているため、参加者が少なかったのかなぁと あとは、年齢層がHadoopなどに比べると高めかなぁという印象（かく言う私も年齢層を上げている一人ですが。。。）。Javaも長いですからねぇ。 午前中から参加していると違った印象だったかもしれないですが。。。 あと、初めて行った会場で、しかも大きめの施設でした。午後の途中から行ったせいもあるかもしれないですが、 案内が出ていなくて若干迷子に。。。 ただ、セッションの部屋自体は各席に机があり、電源も比較的多めにあったので、PC持ち込みでメモを取るには最適でした。\n","date":1318922443,"dir":"post/2011/","id":"5d827a1e8ea70edb11d946b54f076cae","lang":"ja","lastmod":1318922443,"permalink":"https://blog.johtani.info/blog/2011/10/18/jjug-ccc-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-10-18T16:20:43+09:00","summary":"JJUG CCC 2011 Fallに参加してきました。 個人的にはかなり久々のJavaのカンファレンスです。（※あくまで「Javaの」という話で。SolrやHad","tags":["備忘録"],"title":"JJUG CCC 2011 Fallに参加してきました。(Jugemより移植)"},{"contents":"昨日、文章から特定の単語（リストあり）を探したいという話を聞き、lucene-gosenでもできるねぇという話になりました。 まぁ、考えてみればごくごく当たり前なのですが。。。（その筋の方たちにしてみれば常識なのかもしれないですが。。。） 一応やってみたので、こんなこともできるなという一例ですということで、記録を残しておきます。\n今回の例文として野田首相の所信表明演説の一部を活用させてもらいます。 単語のリストは次のようにします。\n内閣総理大臣 正心誠意 東日本 日本 今回も結果をわかりやすくするためにSolrのanalysis画面を利用します。 作業手順は以下のとおり。\ndictionary.csvの編集 辞書のコンパイル fieldTypeの定義（Solrのschema.xmlの設定） 文章からキーワード抽出（Solrのanalysis画面） ### **1.dictionary.csvの編集** 今回はnaist-chasenディレクトリで作業します。 なお、今回利用するlucene-gosenは[ここ](http://johtani.jugem.jp/?eid=21)で紹介した辞書分離バージョンです。（はやくtrunkにコミットせねば。。。） dictionary.csvを先ほど上げた単語だけのエントリに変更します。 キーワードだけを抽出したいので、他の単語は必要ないからです。 ``` \u0026ldquo;内閣総理大臣\u0026rdquo;,1,名詞,一般,,,,,\u0026ldquo;内閣総理大臣\u0026rdquo;,\u0026ldquo;ナイカクソウリダイジン\u0026rdquo;,\u0026ldquo;ナイカクソウリダイジン\u0026rdquo; \u0026ldquo;正心誠意\u0026rdquo;,1,名詞,一般,,,,,\u0026ldquo;正心誠意\u0026rdquo;,\u0026ldquo;セイシンセイイ\u0026rdquo;,\u0026ldquo;セイシンセイイ\u0026rdquo; \u0026ldquo;東日本\u0026rdquo;,1,名詞,一般,,,,,\u0026ldquo;東日本\u0026rdquo;,\u0026ldquo;ヒガシニホン\u0026rdquo;,\u0026ldquo;ヒガシニホン\u0026rdquo; \u0026ldquo;日本\u0026rdquo;,1,名詞,一般,,,,,\u0026ldquo;日本\u0026rdquo;,\u0026ldquo;ニホン\u0026rdquo;,\u0026ldquo;ニホン\u0026rdquo;\n\u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; ### **2.辞書のコンパイル** 先ほど作成した辞書をコンパイルし、lucene-gosen用バイナリ辞書を作成します。 $ cd $LUCENE_GOSEN_HOME¥dictionary $ ant -Ddictype=naist-chasen clean-sen compile\n\u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; ### **3.fieldTypeの定義（Solrのschema.xmlの設定）** Solrのschema.xmlにlucene-gosenを利用するフィールドタイプを定義します。 追加するのは次の通り \u0026lt;fieldType name=\u0026quot;text_ja\u0026quot; class=\u0026quot;solr.TextField\u0026quot; positionIncrementGap=\u0026quot;100\u0026quot; autoGeneratePhraseQueries=\u0026quot;false\u0026quot;\u0026amp;gt; \u0026lt;analyzer\u0026amp;gt; \u0026lt;tokenizer class=\u0026quot;solr.JapaneseTokenizerFactory\u0026quot; compositePOS=\u0026quot;compositePOS.txt\u0026quot; dictionaryDir=\u0026quot;keyword-dic\u0026quot;/\u0026amp;gt; \u0026lt;filter class=\u0026quot;solr.JapanesePartOfSpeechKeepFilterFactory\u0026quot; tags=\u0026quot;keeptags_ja.txt\u0026quot; enablePositionIncrements=\u0026quot;true\u0026quot;/\u0026amp;gt; \u0026lt;/analyzer\u0026amp;gt; \u0026lt;/fieldType\u0026amp;gt; また、ここで定義しているcompositePOS.txt、keeptags_ja.txtは次のようになります。 compositePOS.txt 未知語\nkeeptags_ja.txt 名詞-一般\n未知語がバラバラに出現しないようにして見やすくするためと、必要な単語（今回は「名詞-一般」しか利用しないため。）だけを抽出したいための設定です。 \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; **### 4.文章からキーワード抽出（Solrのanalysis画面）** あとは、analysis画面で解析して見るだけになります。 ということで、辞書に登録された単語だけが抽出されてますね。 この例ではインデックスに登録となりますが。 ただし、「東日本」「日本」のような一部を含む単語の場合、「東日本」が見つかった場合は「日本」は抽出されません。 あくまでも、ベストな解が見つかるのみという形です。 すべての単語を出したい場合はもう少しやり方を考えたほうがいいかもしれません。 （まぁ、このやり方でキーワードを抽出するかも考えたほうがいいかもしれませんが。。。） \u0026lt;/div\u0026gt; 最近、頭が硬くなってきてるなぁと実感してしまいました。まぁ、こんな使い方もあるかなぁと。 もっと頭を柔らかくして問題を解けるけるようになりたいなぁと。 ","date":1318389420,"dir":"post/2011/","id":"b9d4f73fa7ca8ef66891554b66b2cded","lang":"ja","lastmod":1318389420,"permalink":"https://blog.johtani.info/blog/2011/10/12/lucene-gosen%E3%81%A7%E6%96%87%E7%AB%A0%E3%81%8B%E3%82%89%E3%82%AD%E3%83%BC%E3%83%AF%E3%83%BC%E3%83%89%E6%8A%BD%E5%87%BA%E3%82%A4%E3%83%AC%E3%82%AE%E3%83%A5%E3%83%A9%E3%83%BC/","publishdate":"2011-10-12T12:17:00+09:00","summary":"昨日、文章から特定の単語（リストあり）を探したいという話を聞き、lucene-gosenでもできるねぇという話になりました。 まぁ、考えてみれ","tags":["lucene-gosen"],"title":"lucene-gosenで文章からキーワード抽出（イレギュラー？）(Jugemより移植)"},{"contents":"ちょっと間があいてしまったが、ようやくIoの1日目を終了。 なれない感じの言語なので苦労しました。 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大募集です。コメント欄にどしどしコメントください。そこは違うだろ？こっちのほうがいいのでは？という感じで。\n感想： プロトタイプ言語であり、すべての言語はクローンだそうです。\n○手始めに スロット、オブジェクトのクローンについて。 メッセージとその送信について。 あくまでもオブジェクトだけの世界。クローンであり、クラスのインスタンスではない。（まだつかめない。。。） ### ○オブジェクト、プロトタイプ、継承 slotNamesで取れないけど、継承してる。クローンで元をコピーしてるだけか？ 頭文字が大文字かどうかがtypeかどうかの違い。大文字＝type（クラスもどき＝） オブジェクト＝スロットの入れ物 オブジェクトのクローン＝オブジェクトのチェーン？（Object ＝＞ Vehicle ＝＞ Car ＝＞ ferrari） 疑問点： 存在しないスロット名をgetSlot()で呼び出したら？＝＞nilが返る 存在しないスロットをメッセージとして送信したら？＝＞Exceptionが出る ○メソッド method()で定義 メソッドもオブジェクト＝スロットに入れることができる（まだつかめない。。。） メソッドをスロットから呼び出すと実行される。 ○リストとマップ リスト、マップは簡単。幾つか（スタックやキュー）のメソッドも用意されてる。 ○true、false、nil、singleton cloneメソッドを最定義することでsingletonの動作にする。（言われてみれば当たり前か） Object cloneをオーバーライドすることもできるが、プロセス停止などしないとダメ。（恐るべし。。。） ○インタビュー SIMD（Single Instruction Multiple Data）http://ja.wikipedia.org/wiki/SIMD やりながら感想： シンタックスが全然違うのでかなり戸惑い。 ただ、考え方はシンプル。slotとか。 まだ、予約語がわかってない（cloneとかprintとかslotNamesとか）ので。 ★セルフスタディ （探してみよう） ○Ioのいくつかの問題点の例 見つけられず。。。英語がダメダメ。。。　○質問に答えてくれるIoコミュニティ\nML：http://tech.groups.yahoo.com/group/iolanguage/ twitter：http://twitter.com/#!/iolanguage **○Ioのイディオムに関するスタイルガイド** Io Note（英語） [http://iota.flowsnake.org/](http://iota.flowsnake.org/) Ioプログラミングガイド [http://iolanguage.com/scm/io/docs/IoGuide.html](http://iolanguage.com/scm/io/docs/IoGuide.html) [http://xole.net/docs/IoGuide_ja.html](http://xole.net/docs/IoGuide_ja.html)（日本語） Ioスタイルガイド [http://en.wikibooks.org/wiki/Io_Programming/Io_Style_Guide](http://en.wikibooks.org/wiki/Io_Programming/Io_Style_Guide) [http://d.hatena.ne.jp/katzchang/20080819/p1](http://d.hatena.ne.jp/katzchang/20080819/p1)（日本語訳してくれてるブログ） （確認してみよう） ○1 + 1を評価してから、1 + \u0026ldquo;one\u0026quot;を評価する。Ioは強く型付けされた言語か？\n``` Io\u0026gt; 1 + 1 ==\u0026gt; 2 Io\u0026gt; 1 + \u0026ldquo;one\u0026rdquo;\nException: argument 0 to method \u0026lsquo;+\u0026rsquo; must be a Number, not a \u0026lsquo;Sequence\u0026rsquo; message \u0026lsquo;+\u0026rsquo; in \u0026lsquo;Command Line\u0026rsquo; on line 1\nということで、型付けは強いです。 \u0026lt;/div\u0026gt; **○0は真か偽か？空文字列はどうか？nilは真か偽か？** \u0026lt;div\u0026gt; Io\u0026gt; 0 ==\u0026gt; 0 Io\u0026gt; true and 0 ==\u0026gt; true Io\u0026gt; true and \u0026quot;\u0026rdquo; ==\u0026gt; true Io\u0026gt; \u0026quot;\u0026quot; ==\u0026gt; Io\u0026gt; true and nil ==\u0026gt; false Io\u0026gt;\n0、空文字列はtrue、nilはfalseでした。 \u0026lt;/div\u0026gt; **○プロトタイプに存在するスロットを確認するにはどうすればよいか？** \u0026lt;div\u0026gt; Io\u0026gt; Highlander := Object clone ==\u0026gt; Highlander_0x1a233a0: type = \u0026ldquo;Highlander\u0026rdquo;\nIo\u0026gt; hoge := Highlander clone ==\u0026gt; Highlander_0x1a83630:\nIo\u0026gt; hoge proto slotNames ==\u0026gt; list(type) Io\u0026gt; Highlander name := \u0026ldquo;arnold\u0026rdquo; ==\u0026gt; arnold Io\u0026gt; hoge slotNames ==\u0026gt; list() Io\u0026gt; hoge proto slotNames ==\u0026gt; list(type, name) Io\u0026gt; Highlander slotNames ==\u0026gt; list(type, name) Io\u0026gt; hoge name ==\u0026gt; arnold Io\u0026gt; hoge getSlot(\u0026ldquo;name\u0026rdquo;) ==\u0026gt; arnold\nこんな感じ。slotNamesでスロット名を確認し、スロット内部についてはgetSlotで確認できます。 \u0026lt;/div\u0026gt; **○等号（=）、コロン等号（:=）および、コロンコロン等号（::=）の違いはなにか？どのようなときに使うか？** \u0026lt;div\u0026gt; \u0026lt;table class=\u0026#34;list_view\u0026#34;\u0026gt; \u0026lt;thead\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;th\u0026gt;演算子\u0026lt;/th\u0026gt; \u0026lt;th\u0026gt;説明\u0026lt;/th\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;/thead\u0026gt; \u0026lt;tbody\u0026gt; \u0026lt;tr class=\u0026#34;spec\u0026#34;\u0026gt; \u0026lt;td\u0026gt;:::=\u0026lt;/td\u0026gt; \u0026lt;td\u0026gt;スロットへの代入＋setterの追加\u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr class=\u0026#34;specalt\u0026#34;\u0026gt; \u0026lt;td class=\u0026#34;alt\u0026#34;\u0026gt;:=\u0026lt;/td\u0026gt; \u0026lt;td class=\u0026#34;alt\u0026#34;\u0026gt;スロットへの代入\u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr class=\u0026#34;spec\u0026#34;\u0026gt; \u0026lt;td\u0026gt;=\u0026lt;/td\u0026gt; \u0026lt;td\u0026gt;スロットへの代入（ただし、スロットが存在しない場合は例外が発生）\u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;/tbody\u0026gt; \u0026lt;/table\u0026gt; とまぁ、記載したが、実際に動かして確認しました。 Io\u0026gt; Highlander := Object clone ==\u0026gt; Highlander_0x223b800: type = \u0026ldquo;Highlander\u0026rdquo;\nIo\u0026gt; hoge := Highlander clone ==\u0026gt; Highlander_0x21acd60:\nIo\u0026gt; hoge slotNames ==\u0026gt; list() Io\u0026gt; hoge name ::= \u0026ldquo;arnold\u0026rdquo; ==\u0026gt; arnold Io\u0026gt; hoge slotNames ==\u0026gt; list(setName, name) Io\u0026gt; hoge sword := \u0026ldquo;long sword\u0026rdquo; ==\u0026gt; long sword Io\u0026gt; hoge slotNames ==\u0026gt; list(setName, name, sword) Io\u0026gt; hoge clothes = \u0026ldquo;armor\u0026rdquo;\nException: Slot clothes not found. Must define slot using := operator before updating. message \u0026lsquo;updateSlot\u0026rsquo; in \u0026lsquo;Command Line\u0026rsquo; on line 1\n\u0026lt;/div\u0026gt; ### （試してみよう） **○ファイルからIoプログラムを実行せよ** \u0026lt;div\u0026gt; ファイル「great.io」を作成し、以下を入力。 Highlander := Object clone Highlander giveWarCry := \u0026ldquo;Woooooooo!!\u0026rdquo; println Highlander giveWarCry()\nで、以下のコマンドを実行する。 $ io great.io Woooooooo!!\n\u0026lt;/div\u0026gt; **○スロットの名前を指定して格納されているコードを実行せよ** \u0026lt;div\u0026gt; Io\u0026gt; Masason := Object clone ==\u0026gt; Masason_0x20ae7d0: type = \u0026ldquo;Masason\u0026rdquo;\nIo\u0026gt; Masason recieveNiceTweet := method(\u0026ldquo;やりましょう\u0026rdquo; println) ==\u0026gt; method( \u0026ldquo;やりましょう\u0026rdquo; println ) Io\u0026gt; Masason getSlot(\u0026ldquo;recieveNiceTweet\u0026rdquo;) ==\u0026gt; method( \u0026ldquo;やりましょう\u0026rdquo; println ) Io\u0026gt; Masason getSlot(\u0026ldquo;recieveNiceTweet\u0026rdquo;) call やりましょう ==\u0026gt; やりましょう\ncallとgetSlotが鍵ですね。 \u0026lt;/div\u0026gt; 1日目の途中で間があいてしまったのでシンタックスを忘れてしまう始末。。。 ただ、そんなに込み入った記述もないので、最初に勉強することは少ないかもしれないです。 まだメソッドをあとから追加とか、cloneしたあとにまたプロトタイプを変更して反映可能など、考え方になれないもところがありますが、良い頭の体操になってます。 間を置かずに3日目まで行かないと！！ ","date":1317990120,"dir":"post/2011/","id":"dc962e34780f0374b7eb3d583f6d7eb6","lang":"ja","lastmod":1317990120,"permalink":"https://blog.johtani.info/blog/2011/10/07/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-1%E6%97%A5%E7%9B%AE/","publishdate":"2011-10-07T21:22:00+09:00","summary":"ちょっと間があいてしまったが、ようやくIoの1日目を終了。 なれない感じの言語なので苦労しました。 今回もセルフスタディの私の回答が最後の方に記","tags":[],"title":"「7つの言語　7つの世界」 Io 1日目(Jugemより移植)"},{"contents":"久々に、MBAの備忘録です。 あれから色々入れました。 なので、入れたソフトの一覧を追加。\nAIR：TweetDeckをインストールするのに必要だったため TweetDeck（AIR版）：TwitterとFacebookを同じ画面で見ることができるため。 TextWrangler：テキストエディタ（まだあんまり使ってない） Skitch：Evernoteに買収されて無料に。先日のSolr管理画面の説明書きにもちょっと使用 ClamXav：フリーのセキュリティソフト。 SourceTree：Twitterで知ったMac用のgit、mercurialのクライアントソフト。AtlassianがSourceTreeを買収したのを機に一時的に無料公開されていたので。 Firefox：基本はSafariを使ってます。WindowsではChromeを使ってます。ただ、Webページを表示されていない部分もまるごとキャプチャするのにChromeのプラグインだとダメだったので入れました。今のところキャプチャ用のブラウザです。 Full Screen enable for Eclipse on Lion：Eclipseをフルスクリーン対応するためのプラグイン MercurialEclipse：bitbucketにアカウントをもっているので。 mercurial：pipを使ってインストール。MercurialEclipseでコマンドが必要だから。「sudo pip install Mercurial」 pip：mercurialをインストールするためにインストール。「sudo easy_install pip」でインストール iStat pro（ウィジェット）：CPUなどの情報を表示するウィジェット。ウィジェットがアップルのサイト（AppStoreではない）から検索できるというのを人から聞いた。ウィジェットってあんまり使われないのか？ Mac Blu-ray Player：現時点で有料ソフトはこれだけ。こちら。もともとNASのデータのバックアップ用にBlu-rayのドライブ買ったんですが、せっかくだからMacにも使ってみようと思い、MacでBlu-rayを見るために購入しました。所用で長距離移動もあったので、新幹線で映画見てました。 このくらいです。 ほんとはリンクを貼ればいいのですが、そこまでの元気がないので、ご勘弁を。\nSkitchがおすすめです。簡単に画像編集＋説明書きが入れられて、矢印などがよくある画像編集の野暮ったさがないので、画面キャプチャに説明書くのに今後活躍する予定です。\nあと、ソフトではなく、サービスなのですが、Cacooというサービスが便利です。 ここ最近、ちょっとした作図にはこのサービスを使うようにしています。オンラインで利用できるので、いろんな場所で編集できます。 また、図の作成もさることながら、図を共有することが可能です。 先日は、lucene-gosenが思ったように動かないという相談を受けて、このCacooでanalysis画面や設定をを貼ってもらったりしながら使いました。結構便利ですね。 ただ、付属のチャットを使ったのですが、このチャットの内容がテキスト形式でコピー出来なかったのが残念でした。今後の改修に期待ということで。\nあと、セットアップとは少し違いますが、ジャケット買ってつけました。 ステッカーを直接貼るのがちょっと気になったので、ジャケットつけてステッカーを貼ってます。 ただ、ステッカーは思ったよりチープな感じが。。。ジャケットの中に貼らないとダメだったかも。まぁ、それが嫌でジャケット買ったんですが。。。 エアージャケットセット for Macbook Air 13inch(クリア)PMC-81 ","date":1317968700,"dir":"post/2011/","id":"de1ab82817c0fb24e591b9a89a82f736","lang":"ja","lastmod":1317968700,"permalink":"https://blog.johtani.info/blog/2011/10/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%94/","publishdate":"2011-10-07T15:25:00+09:00","summary":"久々に、MBAの備忘録です。 あれから色々入れました。 なので、入れたソフトの一覧を追加。 AIR：TweetDeckをインストールするのに必要だ","tags":["備忘録"],"title":"MBAセットアップ備忘録その４(Jugemより移植)"},{"contents":"Lucene/SolrのMLでSolrの管理画面を新しくするというチケットが流れていたのでちょっと触って見ました。 ほんとにちょっと触っただけですが、いくつかキャプチャ撮ってみたので、アップしときます。 ※以下ではサムネイル画像に元画像（100Kくらいの画像）へのリンクが設定されています。携帯などでは見づらいかもしれませんが、ご容赦を。\nURLは旧管理画面とことなり、http://localhost:8983/solr/になります。\nまずはトップ画面 ダッシュボードと呼ばれるトップ画面。メモリの利用率や起動してからの時間、Luceneなどのバージョンが表示されます。 次は検索画面すっきりしてます。facetが指定できるようになったのは大きいかな。ただし、facet.fieldを複数指定などができないが。結果についてはとくに指定がなければXMLで帰ってきます。ただ、パラメータの追加ができなくなってる気がするなぁ ちなみに、Solrを止めて検索したらこんな感じの画面になりました。クエリの実行ならこのようにエラーがわかったのですが、停止後に左のメニューにあるSchemaなどをクリックしても白い画面が出るだけで、エラーかどうかがわかりにくいです。 Analysis画面。入力画面がシンプルになりました。フィールド名はリストで表示されるので選択するだけです。あとは、これまでどおり。サンプルはlucene-gosenの解析結果です。ハイライトもきちんと表示されます。ただし、長い文章の場合は結果部分だけがスクロールできる形になり、ちょっとわかりにくかったです。 Analysisの入力画面を表示したあとにSolrを停止して解析してみたらこんなエラー画面が出ました。ちなみに、その後、画面を切り替えずにSolrを起動して解析したら、赤い帯のエラーは出たままでした。一度別画面にすれば、元に戻りますが。 Pluginsの画面（旧管理画面のstatisticsに相当）。 キャッシュの状態が確認できます。今まであった画面と情報的には一緒かと。一段カテゴリ（CACHEとかCOREとか）の選択ができるようになり、見やすくなりました。 同じくPluginsの画面。 こちらはupdateHandlerについての情報です。commit数やoptimizeの回数、updateして、commitする前の状態のドキュメント数などが表示されます。前より表示される項目が多くなってるかな？ 最後はスキーマブラウザこの画面が一番良くなっています。旧管理画面では、フィールド名がすべて大文字で表示され、しかもソートがされていない状態だったため、ダイナミックフィールドを利用しているとフィールドを探すのが一苦労でした。 今回は、プルダウンでフィールドやフィールドタイプのリストが表示され、辞書順で並んでいます。Filterなどもわかりやすい表示になっているかと。 おまけ Solritasと呼ばれるVelocityを使った、3.x系で入ってきた新しいサンプル画面です。URLはhttp://localhost:8983/solr/browseです。ファセットなどを使った簡単なサンプル画面なので、検索結果画面でこんなことができるというデモにも使えるかと。ただ、これも旧管理画面よりはましですが、デザインが。。。 とまぁ、簡単ですが、4.x系の管理画面をいくつか触ってみて、キャプチャをとって見ました。 デザインは前よりもすっきりしています。ただ、クエリについてはパラメータの追加ができなくなっているので、もう少し改良されるといいかなぁ（自分でやれよと言われそうですが。。。）\n","date":1317811380,"dir":"post/2011/","id":"09677934e13a5d728f00c6ed7c8870a9","lang":"ja","lastmod":1317811380,"permalink":"https://blog.johtani.info/blog/2011/10/05/solr%E3%81%AE%E6%96%B0%E3%81%97%E3%81%84%E7%AE%A1%E7%90%86%E7%94%BB%E9%9D%A2solr4-x-trunk%E7%B3%BB/","publishdate":"2011-10-05T19:43:00+09:00","summary":"Lucene/SolrのMLでSolrの管理画面を新しくするというチケットが流れていたのでちょっと触って見ました。 ほんとにちょっと触っただけ","tags":["solr"],"title":"Solrの新しい管理画面（Solr4.x trunk系）(Jugemより移植)"},{"contents":"遅くなりましたが、続きです。 さらに英語力のなさを痛感して凹んでいるところですが、何かの役に立てばと恥を晒すところです。。。\n一応、訳してみたのですが、訳すのに必死になってしまい、つながりがわかっていない点もちらほら。 このあと一旦見直しつつ、再度理解する「理解編」をアップしようかと思います。 できれば、シーケンス図とかも交えつつ。（そうしないと理解ができない可能性が。。。） 前回同様、原文は最後に付加しておきます。\nBoot Strapping Cluster Startup（クラスタの起動） ノードはZookeeperのホストとポートを指定することから始めます。 クラスタの最初のノードはクラスタのschema/configとクラスタの設定を指定するとこから開始します。 最初のノードはZookeeperに設定をアップロードしてクラスタをブートします。 クラスタは「ブートストラップ」状態です。 この状態ではノード-\u0026gt;パーティションマッピングは計算されず、クラスタはクラスタ管理コマンド以外のどんなread/writeリクエストも受け付けません。\nクラスタの最初のノード集合が起動した後、クラスタ管理コマンド（TBD記述？？？）が管理者によって発行されます。このコマンドは整数「partitions」パラメータを受け取り、次のステップを実行します。\nCluster Lockを取得 「partitions」をパーティション数として割り当て 各パーティションのためのノードを取得 ZooKeeperのノード-\u0026gt;パーティションマッピングを更新 Cluster Lockをリリース 全ノードに対して最新版のノード-\u0026gt;パーティションマッピングをZooKeeper経由で更新させる Node Startup ノードが起動すると、自分がすでに存在するシャードの一部かどうかZooKeeperでチェックします。 もし、ZooKeeperがノードのレコードを持っていない、またはどのシャードの一部でもないと判断したら、 ノードは後述の「New Node」のステップを実行します。すでに存在するノードの場合は後述の「Node Restart」のステップを実行します。\nNew Node\n新しいノードはクラスタの一部ではなく、クラスタのキャパシティを増強するためのものです。\n「auto_add_new_nodes」クラスタプロパティが「false」の場合、新しいノードはZooKeeperに「idle」として登録され、他のノードが参加してくれと言うまで待機します。 そうでない場合（auto_add_new_nods=true）は次のステップを実行します。\nCluster Lockを取得します。 適切なnode-\u0026gt;partitionエントリを選び出します。 利用可能なパーティションのリストをスキャンして「replication_factor」のノード数以下のパーティションのエントリを探します。複数ある場合はノード数が最小のエントリを選びます。それも一緒ならランダムに選びます。 全パーティションが「replication_factor」以上のノードを持っている場合、ノードはパーティションが最も多いものをスキャンします。複数ある場合はパーティション内のドキュメント数が最大のエントリを選びます。ドキュメント数が同一なら任意のエントリを選びます。 もし、選んだノード-\u0026gt;パーティションエントリを現在のノードに移動させることでがクラスタのパーティション：ノード比率の最大値を小さくするなら、現在のエントリを返します。。それ以外の場合選ばれたエントリがないので、アルゴリズムは終了です。。 ZooKeeper内のノード-\u0026gt;パーティションマッピングを更新します ZooKeeper内のノードステータスを「リカバリ」状態にします Cluster Lockをリリースします 「リカバリ」はパーティションのリーダーから開始します。 リカバリが終了したら、再度、Cluster Lockを取得します。 元のエントリはZooKeeperのノード-\u0026gt;パーティションマッピングから削除されます。 Cluster Lockをリリースします 元のノードはZooKeeperからノード-\u0026gt;パーティションマッピングを更新させられます ステップ1に戻ります。 Node Restart ノードの再起動とは次のいずれかを意味しています。\nJVMがクラッシュし、手動または自動でのリスタート ノードが一時的にネットワークから切り離された。もしくは、ZooKeeperに接続できなかった（死んでいると思われた）。または、ある一定期間、リーダーからの更新を受信できなかった。 このシナリオが表す書き込み処理のライフサイクルの間にネットワークから分断された ハード故障もしくはメンテナンスウインドウによりクラスタからノードが分断され、ノードをクラスタにrejoinさせるために起動した。 ノードが各パーティションに対してメンバーであるパーティションのリストを読み、パーティションのリーダーがリカバリプロセスを実行する。その時、ノードは「auto_add_new_nods」プロパティをチェックして、「New Node」処理のステップを実行する。 これはクラスタが。。。（元の文章が切れてて意味が不明）\nクライアントは標準的なSolrの更新形式を利用して書き込みできます。 書き込み処理はクラスタの任意のノードに送信されます。 ノードはハッシュ関数を利用して、どのパーティションに所属するか決めるためにrange-パーティションマッピングを使います。 ZooKeeperはシャードのリーダーを識別して、書き込み処理をそこに送ります。 SolrJはリーダーに対して書き込みを直接送信するための拡張がされています。\nリーダーはPartitionバージョンの操作を割り当て、そのトランザクションログの操作を書き込み、シャードに属する他のノードにドキュメントバージョンハッシュを転送します。 ノードはインデックスにドキュメントハッシュを書き込み、トランザクションログに操作を記録します。 リーダーは、min_writesの最小数のノード以上のノードが「OK」とレスポンスを返したら「OK」とレスポンスを返します。 クラスタプロパティのmin_writesは書き込みリクエスト時に指定することで、異なる値を指定できます。\nクラウドモードはコミット/ロールバック操作を明示的には行いません。 コミットは特定の間隔で（commit_within）リーダーによりオートコミットにより管理されます。 また、シャードの全メンバーのコミットはトリガーにより管理されます。 ノードが利用可能な最新バージョンはコミットの時点で記録されます。\nTransaction Log トランザクションログは2つのコミットの間にインデックスに対して実行された操作全てを記録したもの コミットはそれ以前に実行された操作の耐久性を保証するために、新しいトランザクションログを開始します。 同期は調整が可能です。例えば、flush vs fsynです。fsyncがデフォルトで、JVMクラッシュに対して保証できるが、電源異常の場合には保証できないが、速度的には早いです。 Recovery 次のトリガーにより復旧が可能です。\nBootstrap パーティション分割 クラスタの再構築 ノードは自身に「recovering」というステータスを設定して復旧を開始します。 このフェーズの間、ノードは読み込みリクエストを受けることができませんが、トランザくkションログに書きこまれるすべての新しい書き込みリクエストを受け取ります。 ノードは自身が持つインデックスのバージョンを調べて、パーティションの最新バージョンのリーダーに問い合わせます。 リーダーはシャード内の残りのノードと同期する前に実行されるべき操作の集合を返します（？？？）。\n最初にインデックスをコピーし、最新のノードにあるトランザクションログをリプレイします。 もし、インデックスのコピーが必要ならば、インデックスファイルをローカルにまずコピーし、その後トランザクションログをリプレイします。 トランザクションログのリプレイは通常の書き込みリクエストの流れと同じです。 この時、ノードは新しい書き込みを受け付けるかもしれません。その書き込みはインデックスに再生されるべきです。 ある時点でノードは最新のコミットポイントに追いつき、自身のステータスを「ready」にします。 この時点で、このノードは読み込みリクエストを処理できます。\nHandling Node Failures 一時的にネットワークが分断され、幾つかのノードとZooKeeperの間の通信が遮断されるかもしれません。 クラスタはデータの再構築（リバランシング）の前にしばらく待ちが発生します。\nLeader failure\nノードが故障し、もしそれがシャードのリーダだった場合、他のメンバーがリーダー選出のプロセスを開始します。 新しいリーダーが選出されるまで、このパーティションへの書き込みは受け付けられません。 この時、これはリーダー以外の故障ステップを処理します。（？？？）\nLeader failure\nシャードの一部に新しいノードが割り当てられる前にリーダーはmin_reaction_timeの間待ちます。 リーダーはCluster Lockを取得し、シャードの新規メンバーとしてノードを割り当てるためのノード-シャード割り当てアルゴリズムを使用します。 ZooKeeperのノード-\u0026gt;パーティションマッピングが更新され、Cluster Lockがリリースされます。 新しいノードはZooKeeperからノード-\u0026gt;パーティションマッピングを強制的にリロードされます。\nSplitting partitions 明示的なクラスタ管理コマンドもしくはSolrによる自動的な分割戦略（ストラテジ）はパーティションを分割することができます。 明示的な分割コマンド（split command）は対象となるパーティションを分割するために実行されます。\nパーティションXが100から199のハッシュの範囲を持つものとし、X（100から149）、Y（150～199）に分割するとします。 Xのリーダーは、XとYの新しい値の範囲をZooKeeperに分割アクションを記録します。 ノードはこの分割アクションもしくは新しいパーティションの存在については通知を受けません。（？？？）\nXのリーダはCluster Lockを取得し、パーティションY（アルゴリズムはto be determined）を割り当てるノードを決定し、新しいパーティションを知らせ、パーティション-\u0026gt;ノードマッピングを更新します。Xのリーダはノードのレスポンスを街、新しいパーティションがコマンドを受付可能な状態になったら次の処理を実行します。 Xのリーダーは分割が完了するまですべてのコミットを停止します。 Xのリーダーは最新のコミットポイント（バージョンVとする）のIndexReaderをオープンし、同じバージョンのIndexReaderもオープンするように命じます XのリーダーはYのリーダーに対してバージョンV以降のトランザクションログのうちハッシュ値の範囲が150から199のものを流します。 Yのリーダーはトランザクションログの#2（#3の間違い？）で送られたリクエストだけを記録します？？？ Xのリーダーはステップ#2で開いたIndexReaderに対してインデックスの分割を開始します。 #5で作成されたインデックスはYのリーダーに送られ、登録されます。 Yのリーダーは「recovery」プロセスを開始するように（シャードの）他のノード命令し、インデックスのトランザクションログを再生し始めます。 パーティションYのすべてのノードがバージョンVに到達したならば YのリーダーはXのリーダーに#2で作成されたReaderの上に、ハッシュの範囲が100から149だけに属しているドキュメントを抽出するようにするFilteredIndexReaderを準備するように頼みます。 Xのリーダーは#8aのリクエストが完了したのを検知したら、YのリーダーがCluster Lockを取得し、クラスタ全体の検索/登録リクエストの受信を開始するためにレンジ-\u0026gt;パーティションマッピングを変更します。 YのリーダーはXのリーダーに検索リクエストのために#8aで作成されたFilteredIndexReaderの利用開始を頼みます YのリーダーはXのリーダーに、ZooKeeperからレンジ-\u0026gt;パーティションマッピングを矯正リフレッシュするように頼みます。この時点で#3で開始されたトランザクションログの流しこみが停止されるのが保証されます。 Xのリーダーは自身のパーティションに存在するべきでないハッシュ値をもつドキュメントを削除し、最新のコミットポイントのsearcherを再度開きます。 この時点で分割は完全に終了し、Xのリーダーはcommit_withinパラメータによるコミットをレジュームします（？？？） Notes:\n分割操作が完了するまで、commit_withinパラメータによるパーティションの分割は実行されない #8b開始から#8c終了までの間の分散検索は一貫しない検索結果を帰す場合がある（例えば：検索結果が異なる） Cluster Re-balancing クラスタは明示的なクラスタ管理コマンドにより再構築（リバランシング）できる。\nTBD （to be determined）\nCluster Re-balancing TBD （to be determined）\nConfiguration solr_cluster.properties これはクラスタ内の全ノードにわたって適用される一般的なSolr設定ファイルとは別のプロパティファイルの集合である。\nreplication_factor：クラスタによって管理されるドキュメントのレプリカの数 min_writes：書き込み操作が成功になる前の最小の書き込み？？？？。これは書き込みごとに上書き設定可能 commit_within：検索に現れるまでの書き込み操作の最大回数 hash_function：ドキュメントのハッシュ値を計算するための関数の実装 max_hash_value：ハッシュ関数が出力することができる最大値。理論的には、この値はクラスタが保持できるパーティションの最大数でもある min_reaction_time：起動、停止の後に再配分/分割にかかる時間（？？） min_replica_for_reaction：レプリカノード数がこの値以下になったら、min_reaction_timeにならなくても分割が実行される。 auto_add_new_nodes：booleanフラグ。もしtrueなら新しいノードは自動的にパーティションからレプリカを読み込む。そうでない場合は新しいノードはクラスタに「idle」状態で登録される Cluster Admin Commands すべてのクラスタ管理コマンドはすべてのノードでパス（/cluster_admin）を与えることで実行できます。 全ノードは同じコマンドを受け付けることができ、振る舞いも同じものになるでしょう。 以下のコマンドはユーザが利用できるパブリックなコマンドです。\ninit_cluster：（パラメータ：パーティション）このコマンドはノードの集合の初期化後に実施されます。このコマンドが実行されるまで、クラスタは読み込み/書き込みコマンドを受け付けません。 split_partition：（パラメータ：パーティション（任意））パーティションを2つに分割します。もしパーティションパラメータが指定されない場合は、ドキュメント数が最大の add_idle_nodes：このコマンドはauto_add_new_nodes=falseの場合に利用できます。このコマンドはクラスタに対して「idle」状態のすべてのノードを追加するトリガーとなります。 move_partition：（パラメータ：パーティション、from、to）fromのノードからtoの別のノードに引数で指定されたパーティションを移動します。 command_status：（パラメータ：completion_id（任意））上記コマンドはすべて非同期で実行され、completion_idを返します。このコマンドは特定の実行中のコマンドもしくは全ての実行中のコマンドの状態を表示するために利用できます。 status：（パラメータ：パーティション（任意））パーティションのリストを表示し各パーティションの次の情報を表示します。 リーダーノード ノードのリスト ドキュメント数 平均読み込み回数（reads/sec） 平均書き込み回数（writes/sec） 平均読み込み時間（time/read） 平均書き込み時間（time/write） Migrating from Solr to SolrCloud クラウドに移行するときに幾つかの特徴は不要かもしれないし、サポートされないかもしれません。 既存の（クラウドでない）バージョンでのすべての特徴をSolrCloudでサポートし続けなければなりません。\nレプリケーション：これは必要ありません。 CoreAdminコマンド：明示的なコアの操作は許可されません。内部にコアがあるかもしれないが、暗黙的に管理されるでしょう 複数スキーマのサポート？：単純化のため、ver1.0ではサポートしないかもしれない solr.xml：SolrCloudでほんとに必要？ Alternative to a Cluster Lock リーダーを選出する常設の調停ノード（masterはインデックスレプリケーションで利用している用語なので、「調停」とする）を持つほうが単純かもしれません。 「truth」状態をZookeeperの状態としてみなすような次のパターンでは、将来の柔軟性（クラスタを制御するためのZookeeperの状態を直接変更するような外部管理ツールのような）を考慮に入れることができます。 （毎回ロックを取得するよりも）調停ノードを持つことにより、よりスケーラブルになるかもしれません。 特定条件下でのみCluster Lockを利用するハイブリッドも意味があるでしょう。\nSingle Node Simplest Use Case 単一ノードでスタートして、ドキュメントをインデックス登録できないといけません。 また、あとで、クラスタに2番目のノードを追加できないと行けません。\n1つのノードから開始し、最初にZookeeperに設定ファイルをアップロードし、shard1にノードを作成＋登録します。 他の情報がない状態で設定が作成され、1つのシャードのシステムとなります。 いくつかのドキュメントをインデックスします 他のノードが起動し、「まだ割り当てられていない場合、レプリカの最小の数をもつshardに割り当てられ、「recovery」プロセスを開始します」というパラメータを受け取ります。 * 出来れば、同一ホスト上に同じシャードはコピーしない * この時点の後で、ノードが停止したら、再起動し、同じ役割が再開されるべきです。（Zookeeperでそれ自身であると判別されれば） 原文はこちらからです。\nBoot Strapping Cluster Startup A node is started pointing to a Zookeeper host and port. The first node in the cluster may be started with cluster configuration properties and the schema/config files for the cluster. The first node would upload the configuration into zookeeper and bootstrap the cluster. The cluster is deemed to be in the “bootstrap” state. In this state, the node -\u0026gt; partition mapping is not computed and the cluster does not accept any read/write requests except for clusteradmin commands.\nAfter the initial set of nodes in the cluster have started up, a clusteradmin command (TBD description) is issued by the administrator. This command accepts an integer “partitions” parameter and it performs the following steps:\nAcquire the Cluster Lock Allocate the “partitions” number of partitions Acquires nodes for each partition Updates the node -\u0026gt; partition mapping in ZooKeeper Release the Cluster Lock Informs all nodes to force update their own node -\u0026gt; partition mapping from ZooKeeper The Cluster Lock is acquired A suitable source (node, partition) tuple is chosen: The list of available partitions are scanned to find partitions which has less then “replication_factor” number of nodes. In case of tie, the partition with the least number of nodes is selected. In case of another tie, a random partition is chosen. If all partitions have enough replicas, the nodes are scanned to find one which has most number of partitions. In case of tie, of all the partitions in such nodes, the one which has the most number of documents is chosen. In case of tie, a random partition on a random node is chosen. If moving the chosen (node, partition) tuple to the current node will decrease the maximum number of partition:node ratio of the cluster, the chosen tuple is returned.Otherwise, no (node, partition) is chosen and the algorithm terminates The node -\u0026gt; partition mapping is updated in ZooKeeper The node status in ZooKeeper is updated to “recovery” state The Cluster Lock is released A “recovery” is initiated against the leader of the chosen partition After the recovery is complete, the Cluster Lock is acquired again The source (node, partition) is removed from the node -\u0026gt; partition map in ZooKeeper The Cluster Lock is released The source node is instructed to force refresh the node -\u0026gt; partition map from ZooKeeper Goto step #1 Node Restart A node restart can mean one of the following things:\nThe JVM crashed and was manually or automatically restarted The node was in a temporary network partition and either could not reach ZooKeeper (and was supposed to be dead) or could not receive updates from the leader for a period of time. A node restart ine node failure. Lifecycle of a Write Operation this scenario signifies the removal of the network partition. A hardware failure or maintenance window caused the removal of the node from the cluster and the node has been started again to rejoin the cluster. The node reads the list of partitions for which it is a member and for each partition, starts a recovery process from each partition’s leader respectively. Then, the node follows the steps in the New Node section without checking for the auto_add_new_nodes property. This ensures that the cluster recovers from the imbalance created by th\nWrites are performed by clients using the standard Solr update formats. A write operation can be sent to any node in the cluster. The node uses the hash_function , and the Range-Partition mapping to identify the partition where the doc belongs to. A zookeeper lookup is performed to identify the leader of the shard and the operation is forwarded there. A SolrJ enhancement may enable it to send the write directly to the leader\nThe leader assigns the operation a Partition Version and writes the operation to its transaction log and forwards the document + version + hash to other nodes belonging to the shard. The nodes write the document + hash to the index and record the operation in the transaction log. The leader responds with an ‘OK’ if at least min_writes number of nodes respond with ‘OK’. The min_writes in the cluster properties can be overridden by specifying it in the write request.\nThe cloud mode would not offer any explicit commit/rollback operations. The commits are managed by auto-commits at intervals (commit_within) by the leader and triggers a commit on all members on the shard. The latest version available to a node is recorded with the commit point.\nTransaction Log A transaction log records all operations performed on an Index between two commits Each commit starts a new transaction log because a commit guarantees durability of operations performed before it The sync can be tunable e.g. flush vs fsync by default can protect against JVM crashes but not against power failure and can be much faster Recovery A recovery can be triggered during:\nBootstrap Partition splits Cluster re-balancing The node starts by setting its status as ‘recovering’. During this phase, the node will not receive any read requests but it will receive all new write requests which shall be written to a separate transaction log. The node looks up the version of index it has and queries the ‘leader’ for the latest version of the partition. The leader responds with the set of operations to be performed before the node can be in sync with the rest of the nodes in the shard.\nThis may involve copying the index first and replaying the transaction log depending on where the node is w.r.t the state of the art. If an index copy is required, the index files are replicated first to the local index and then the transaction logs are replayed. The replay of transaction log is nothing but a stream of regular write requests. During this time, the node may have accumulated new writes, which should then be played back on the index. The moment the node catches up with the latest commit point, it marks itself as “ready”. At this point, read requests can be handled by the node.\nHandling Node Failures There may be temporary network partitions between some nodes or between a node and ZooKeeper. The cluster should wait for some time before re-balancing data.\nLeader failure\nIf node fails and if it is a leader of any of the shards, the other members will initiate a leader election process. Writes to this partition are not accepted until the new leader is elected. Then it follows the steps in non-leader failure\nNon-Leader failure\nThe leader would wait for the min_reaction_time before identifying a new node to be a part of the shard. The leader acquires the Cluster Lock and uses the node-shard assignment algorithm to identify a node as the new member of the shard. The node -\u0026gt; partition mapping is updated in ZooKeeper and the cluster lock is released. The new node is then instructed to force reload the node -\u0026gt; partition mapping from ZooKeeper.\nSplitting partitions A partition can be split either by an explicit cluster admin command or automatically by splitting strategies provided by Solr. An explicit split command may give specify target partition(s) for split.\nAssume the partition ‘X’ with hash range 100 - 199 is identified to be split into X (100 - 149) and a new partition Y (150 - 199). The leader of X records the split action in ZooKeeper with the new desired range values of X as well as Y. No nodes are notified of this split action or the existence of the new partition.\nThe leader of X, acquires the Cluster Lock and identifies nodes which can be assigned to partition Y (algorithm TBD) and informs them of the new partition and updates the partition -\u0026gt; node mapping. The leader of X waits for the nodes to respond and once it determines that the new partition is ready to accept commands, it proceeds as follows: The leader of X suspends all commits until the split is complete. The leader of X opens an IndexReader on the latest commit point (say version V) and instructs its peers to do the same. The leader of X starts streaming the transaction log after version V for the hash range 150 - 199 to the leader of Y. The leader of Y records the requests sent in #2 in its transaction log only i.e. it is not played on the index. The leader of X initiates an index split on the IndexReader opened in step #2. The index created in #5 is sent to the leader of Y and is installed. The leader of Y instructs its peers to start recovery process. At the same time, it starts playing its transaction log on the index. Once all peers of partition Y have reached at least version V: The leader of Y asks the leader of X to prepare a FilteredIndexReader on top of the reader created in step #2 which will have documents belonging to hash range 100 - 149 only. Once the leader of X acknowledges the completion of request in #8a, the leader of Y acquires the Cluster Lock and modifies the range -\u0026gt; partition mapping to start receiving regular search/write requests from the whole cluster. The leader of Y asks leader of X to start using the FilteredIndexReader created in #8a for search requests. The leader of Y asks leader of X to force refresh the range -\u0026gt; partition mapping from ZooKeeper. At this point, it is guaranteed that the transaction log streaming which started in #3 will be stopped. The leader of X will delete all documents with hash values not belonging to its partitions, commits and re-opens the searcher on the latest commit point. At this point, the split is considered complete and leader of X resumes commits according to the commit_within parameters. Notes:\nThe partition being split does not honor commit_within parameter until the split operation completes Any distributed search operation performed starting at the time of #8b and till the end of #8c can return inconsistent results i.e. the number of search results may be wrong. Cluster Re-balancing The cluster can be rebalanced by an explicit cluster admin command.\nTBD\nMonitoring TBD\nConfiguration solr_cluster.properties This are the set of properties which are outside of the regular Solr configuration and is applicable across all nodes in the cluster:\nreplication_factor : The number of replicas of a doc maintained by the cluster min_writes : Minimum no:of successful writes before the write operation is signaled as successful . This may me overridden on a per write basis commit_within : This is the max time within which write operation is visible in a search hash_function : The implementation which computes the hash of a given doc max_hash_value : The maximum value that a hash_function can output. Theoretically, this is also the maximum number of partitions the cluster can ever have min_reaction_time : The time before any reallocation/splitting is done after a node comes up or goes down (in secs) min_replica_for_reaction : If the number of replica nodes go below this threshold the splitting is triggered even if the min_reaction_time is not met auto_add_new_nodes : A Boolean flag. If true, new nodes are automatically used as read replicas to existing partitions, otherwise, new nodes sit idle until the cluster needs them. Cluster Admin Commands All cluster admin commands run on all nodes at a given path (say /cluster_admin). All nodes are capable of accepting the same commands and the behavior would be same. These are the public commands which a user can use to manage a cluster:\ninit_cluster : (params : partition) This command is issued after the initial set of nodes are started. Till this command is issued, the cluster would not accept any read/write commands split_partition : (params : partitionoptional). The partition is split into two halves. If the partition parameter is not supplied, the partition with the largest number of documents is identified as the candidate. add_idle_nodes : This can be used if auto_add_new_nodes=false. This command triggers the addition of all ‘idle’ nodes to the cluster. move_partition : (params : partition, from, to). Move the given partition from a given node from to another node command_status :(params : completion_idoptional) . All the above commands are asynchronous and returns with a completion_id . This command can be used to know the status of a particular running command or all the current running commands status : (params : partitionoptional) Shows the list of partitions and for each partition, the following info is provided leader node nodes list doc count average reads/sec average writes/sec average time/read average time/write Migrating from Solr to SolrCloud A few features may be redundant or not supported when we move to cloud such as. We should continue to support the non cloud version which supports all the existing features\nReplication. This feature is not required anymore CoreAdmin commands. Explicit manipulation of cores will not be allowed. Though cores may exist internally and they meay be managed implicitly Multiple schema support ? Should we just remove it from ver 1.0 for simplicity? solr.xml . Is there a need at all for this in the cloud mode? Alternative to a Cluster Lock It may be simpler to have a coordinator node (we avoid the term master since that is associated with traditional index replication) that is established via leader election. Following a pattern of treating the zookeeper state as the \u0026ldquo;truth\u0026rdquo; and having nodes react to changes in that state allow for more future flexibility (such as allowing an external management tool directly change the zookeeper state to control the cluster). Having a coordinator (as opposed to grabbing a lock every time) can be more scalable too. A hybrid model where a cluster lock is used only in certain circumstances can also make sense.\nSingle Node Simplest Use Case We should be able to easily start up a single node and start indexing documents. At a later point in time, we should be able to start up a second node and have it join the cluster.\nstart up a single node, upload it\u0026rsquo;s configuration (the first time) to zookeeper, and create+assign the node to shard1. in the absence of other information when the config is created, a single shard system is assumed index some documents start up another node and pass it a parameter that says \u0026ldquo;if you are not already assigned, assign yourself to any shard that has the lowest number of replicas and start recovery process\u0026rdquo; avoid replicating a shard on the same host if possible after this point, one should be able to kill the node and start it up again and have it resume the same role (since it should see itself in zookeeper)\n","date":1317720720,"dir":"post/2011/","id":"7052598d2355984237d126afea2f6e88","lang":"ja","lastmod":1317720720,"permalink":"https://blog.johtani.info/blog/2011/10/04/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE2/","publishdate":"2011-10-04T18:32:00+09:00","summary":"遅くなりましたが、続きです。 さらに英語力のなさを痛感して凹んでいるところですが、何かの役に立てばと恥を晒すところです。。。 一応、訳してみたの","tags":["solr"],"title":"New SolrCloud Designの翻訳（その2）(Jugemより移植)"},{"contents":"ちょっと興味があるので、訳してみました。（Wikiのページはこちら） 更新されているようなので、もとの文章も残しておきます。（ページ下部の続きはこちら部分以降） 全部訳そうと思ったのですが、終わらなかったので、まずは前半部分です。まだ、訳しただけで理解できてない。。。 （英語力のなさをさらけ出してしまうのですが、これも修行です。。。おかしいところはツッコミを。）\nWhat is SolrCloud? Solrクラウドはクラウドでの検索サービスとしてのSolrを管理、運用するための既存のSolrを拡張するものです。\n用語集 Cluster：クラスタは1単位として管理されるSolrノードの集合です。クラスタ全体で単一のschema、solrconfigをもたないといけません。 Node：ひとつのJVMインスタンスで起動しているSolrのこと Partition：パーティションはドキュメント集合全体のサブセット（部分集合）のことです。パーティションは部分集合のドキュメントが単一のインデックスに含まれるような形で作られます。 Shard：パーティションはn（＝replication factor）個のノードに保存される必要があります。このn個のノードすべてでひとつのshardです。1つのノードはいくつかのshardの一部にで有る場合があります。 Leader：各Shardは1つのリーダとなるノードを持っています。パーティションに登録されたドキュメントリーダーからコピーされます Replication Factor：クラスタによって保持されるレプリカの最小限の数 Transaction Log：各ノードによって保持される書き込み処理の追記ログ Partition version：これは各shardのリーダーが持っているカウンターで、書き込み処理ごとに増加し、レプリカに送られます。 Cluster Lock：これはrange（※後述されているハッシュ値の範囲のことか？）-\u0026gt;パーティションもしくはパーティション-\u0026gt;ノードのマッピングを変更するために取得しなければいけないグローバルなロックのことです。 ※用語だけだと関係がわかりづらかったので、図を書いてみました。\nドキュメントの集合とパーティションについての考え方\nクラスタ、ノード、シャードの考え方。\n処理原則 任意の処理はクラスタにある任意のノードに実行可能です。 リカバリできないSPOFはありません。 クラスタは伸縮自在（elastic）でなければならない 書き込みが失われないこと（耐久性）を保証する 書き込み順序が保証されなければならない 2つのクライアントが2つの「A」というドキュメントを同時に送信してきた場合、すべてのレプリカで一貫してどちらか一方が保存されなければならない。 クラスタの設定は中央管理されなければならない。また、クラスタのどのノードからもクラスタ設定が更新できます。 読み込み（検索）の自動的なフェイルオーバー 書き込み（インデクシング）の自動的なフェイルオーバー ノードの故障が発生しても自動的にrepcation factorの数は守られます。（故障したら動的にレプリカを再配置？） Zookeeper ZooKeeperクラスタは次のために使用されます。\nクラスタ設定の集中管理 分散同期に必要な操作のコーディネータ クラスタ構成を保存するためのシステム Partitioning クラスタは固定されたmax_hash_value＝「N」が設定されます。 max_hash_valueは1000のような大きな値が設定されます。\nhash = hash_function(doc.getKey()) % N ハッシュ値の範囲がパーティションに割り当てられ、ZooKeeperに保存されます。 次の例のような形で、パーティションに対して範囲が設定されます。\nrange : partition ------ ---------- 0 - 99 : 1 100-199: 2 200-299: 3 ハッシュはドキュメントにインデックスフィールドとして追加され、変更されない値です。 これは、インデックスを分割するときにも利用します。\nハッシュ関数はプラガブルです。これはドキュメントを受け取り、一貫した正整数ハッシュ値を返します。デフォルトのハッシュ関数として、必須でかつ変更されないフィールド（デフォルトはユニークキーフィールド）からハッシュ値を計算する関数が提供されます。\nUsing full hash range max_hash_valueは必ずしも必要ではありません。各shardはいずれにしろハッシュ値の範囲持っているので、完全な32 bitsハッシュを使うこともできます。 設定可能なmax_hash_valueを利用しないで、クライアントからの値をもとにハッシュ値を作ることができます。 例えば、電子メールの検索アプリでは次のようにハッシュ関数を作ることができます。\n(hash(user_id)\u0026lt;\u0026lt;24) | (hash(message_id)\u0026gt;\u0026gt;\u0026gt;8) ユーザIDから8bitのハッシュコードの先頭8ビットを利用することで、任意のユーザのメールがクラスタの同じ256番目（のノード？）にあるのを保証します。検索時はこの情報をもとにクラスタのその部分への問い合わせだけで情報が得られます。\nおそらく、私たちは最大値から最小値をカバーする範囲を表現するのにハッシュ空間を輪（固定のハッシュではなく）とみなしたいです。（？？？円状のハッシュ空間とすることで、クラスタ内のノード数の増減に耐えられるようにするよということかな？）\nshard naming シャードからハッシュ値の範囲へのマッピングを別々に管理するよりも、ハッシュコードによりパーティションを構成するときに実際にはハッシュの範囲をシャード名にします。 （シャード「1-1000」は1から1000の間のハッシュコードを持つドキュメントが含まれるという形）\n現時点では（コレクション1つに対してシングルコアの1Solrサーバと仮定して）solrコア名はコレクション名をつけるようになっています。 同一コレクションのためのマルチコアに対してのいい命名規則をつけるという課題が残っています。 （※コレクションに対する説明がここまでないかな？）\nShard Assignment ノード-\u0026gt;パーティションのマッピングはZooKeeperにあるCluster Lockを取得したノードによってのみ変更が可能です。 ノードの追加時に、まず、Cluster Lockを取得し、次にそれがどのパーティションを取得できるかを識別します。\nNode to a shard assignment 新しいノードを探しているノードはまずCluster Lockを取得しないといけません。 第一に、リーダーはシャードを決めます。 シャードが持つ、すべての利用可能なノード数で最小の値を持つノードが選び出されます。 もし、同値ならランダムにノードを選びます。\n原文はこちらからです。\nNew SolrCloud Design (Work in progress)\nWhat is SolrCloud? SolrCloud is an enhancement to the existing Solr to manage and operate Solr as a search service in a cloud.\nGlossary Cluster : Cluster is a set of Solr nodes managed as a single unit. The entire cluster must have a single schema and solrconfig Node : A JVM instance running Solr Partition : A partition is a subset of the entire document collection. A partition is created in such a way that all its documents can be contained in a single index. Shard : A Partition needs to be stored in multiple nodes as specified by the replication factor. All these nodes collectively form a shard. A node may be a part of multiple shards Leader : Each Shard has one node identified as its leader. All the writes for documents belonging to a partition should be routed through the leader. Replication Factor : Minimum number of copies of a document maintained by the cluster Transaction Log : An append-only log of write operations maintained by each node Partition version : This is a counter maintained with the leader of each shard and incremented on each write operation and sent to the peers Cluster Lock : This is a global lock which must be acquired in order to change the range -\u0026gt; partition or the partition -\u0026gt; node mappings. Guiding Principles Any operation can be invoked on any node in the cluster. No non-recoverable single point of failures Cluster should be elastic Writes must never be lost i.e. durability is guaranteed Order of writes should be preserved If two clients send document \u0026ldquo;A\u0026rdquo; to two different replicas at the same time, one should consistently \u0026ldquo;win\u0026rdquo; on all replicas. Cluster configuration should be managed centrally and can be updated through any node in the cluster. No per node configuration other than local values such as the port, index/logs storage locations should be required Automatic failover of reads Automatic failover of writes Automatically honour the replication factor in the event of a node failure Zookeeper A ZooKeeper cluster is used as:\nThe central configuration store for the cluster A co-ordinator for operations requiring distributed synchronization The system-of-record for cluster topology Partitioning The cluster is configured with a fixed max_hash_value (which is set to a fairly large value, say 1000) ‘N’. Each document’s hash is calculated as:\nhash = hash_function(doc.getKey()) % N Ranges of hash values are assigned to partitions and stored in Zookeeper. For example we may have a range to partition mapping as follows\nrange : partition ------ ---------- 0 - 99 : 1 100-199: 2 200-299: 3 The hash is added as an indexed field in the doc and it is immutable. This may also be used during an index split\nThe hash function is pluggable. It can accept a document and return a consistent \u0026amp; positive integer hash value. The system provides a default hash function which uses the content of a configured, required \u0026amp; immutable field (default is unique_key field) to calculate hash values.\nUsing full hash range Alternatively, there need not be any max_hash_value - the full 32 bits of the hash can be used since each shard will have a range of hash values anyway. Avoiding a configurable max_hash_value makes things easier on clients wanting related hash values next to each other. For example, in an email search application, one could construct a hashcode as follows:\n(hash(user_id)\u0026lt;\u0026lt;24) | (hash(message_id)\u0026gt;\u0026gt;\u0026gt;8) By deriving the top 8 bits of the hashcode from the user_id, it guarantees that any users emails are in the same 256th portion of the cluster. At search time, this information can be used to only query that portion of the cluster.\nWe probably also want to view the hash space as a ring (as is done with consistent hashing) in order to express ranges that wrap (cross from the maximum value to the minimum value).\nshard naming When partitioning is by hash code, rather than maintaining a separate mapping from shard to hash range, the shard name could actually be the hash range (i.e. shard \u0026ldquo;1-1000\u0026rdquo; would contain docs with a hashcode between 1 and 1000).\nThe current convention for solr-core naming is that it match the collection name (assuming a single core in a solr server for the collection). We still need a good naming scheme for when there are multiple cores for the same collection.\nShard Assignment The node -\u0026gt; partition mapping can only be changed by a node which has acquired the Cluster Lock in ZooKeeper. So when a node comes up, it first attempts to acquire the cluster lock, waits for it to be acquired and then identifies the partition to which it can subscribe to.\nNode to a shard assignment The node which is trying to find a new node should acquire the cluster lock first. First of all the leader is identified for the shard. Out of the all the available nodes, the node with the least number of shards is selected. If there is a tie, the node which is a leader to the least number of shard is chosen. If there is a tie, a random node is chosen.\n","date":1317210300,"dir":"post/2011/","id":"927612b57ba01ca878b2d7edce52a563","lang":"ja","lastmod":1317210300,"permalink":"https://blog.johtani.info/blog/2011/09/28/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE%EF%BC%91/","publishdate":"2011-09-28T20:45:00+09:00","summary":"ちょっと興味があるので、訳してみました。（Wikiのページはこちら） 更新されているようなので、もとの文章も残しておきます。（ページ下部の続き","tags":["solr"],"title":"New SolrCloud Designの翻訳（その１）(Jugemより移植)"},{"contents":"Hadoop Conference Japan 2011 Fallに行ってきました。 まずは、ユーザ会の方々、運営の方々、発表された方々お疲れ様でした。こんな機会を用意していただき、ありがとうございます。 Hadoopは昨年触っていたのですが、最近は縁がなくなってしまいました。 ただ、触っていたときに面白かったので参加してきました。 ということで、今回も自分用にメモを取ったので。（今回は英語のヒアリングがあって、メモがひどい事になってます。。。） いつものことながら、おかしいところとかあれば、ツッコミなどフィードバックをもらえると嬉しいです。\n場所：ベルサール汐留 日時：2011/09/26 10:00～18:00＋懇親会：18:30～21:00\nオープニングトーク：濱野、太田 参加者：1100名超！（実際は800名弱？） Hadoopの経験：利用経験なしな方が580名 カンファレンスの認知：Twitterよりも知人、その他が多かった。 会場提供：リクルート様 リクルート米谷様より一言。 Question VOTE！！サイトを用意。 http://mit.recruit.co.jpにて情報提供。 ※残念ながら地下だったため、E-mobileにつながらず、あと、電源確保が難しかったのでMBAをスタンドアロンにしてメモをとっていたので、 QAサイトにはアクセスしませんでした。もう少し活用したかったんですが、携帯でTwitterを追っかけるので精一杯。。。\n◎The role of the Distribution in the Apache Hadoop Ecosystem：Todd Lipcon（Cloudera）\n1.Introduction Todd Lipcon：Clouderaエンジニア Hadoop とHBaseのコミッター 2. Hadoop Overview HDFS＋MapReduceの説明 Hadoopの生まれてきた経緯　様々な形式のデータが大量に存在し、データのハンドリングが難しくなってきたため。 Flexible, Scalable Solutionが必要に。 Hadoop の2つのユースケース 1.Advanced Analytics SNS（Web）、Content Optimization（Media）、Network Analytics（Telco）、 2.Data Processing Clickstream SessionizationEngagement 3.Cloudera Overview ClouderaCustomers ・Large National Bank ・Web-Based Media click-through dataや広告のログ ・Wireless Telecom 大量のデータ 目標：大量データからビジネスを引き出すこと。 Cloudera Japan：トレーニング。NTTDと協業して開発支援も 4.CDH Overview 100% pure Apache Hadoop SCM Epress(Service \u0026amp;amp; Configuration Manager) Free なぜ、CDHを利用するの？ Linuxを利用する場合にLinux.orgからはダウンロードしないように、Hadoopも同じように提供したい。 RedHat系を目指しているみたい。 様々なパッケージの依存関係が混乱を招く。 CDHならテストが終わってるものが提供されてる。 ※SolrはLWEがLucidWorksEnterpriseがこれを目指してるのか。 5.Cloudera Enterprise Activity Monitor：Jobのパフォーマンスをリアルタイムに監視 SCM：設定のvalidateや管理。 Resource Manager：。。。 6.まとめ CDH：簡単にHadopが使えるよ。 SCM Express：簡単にHadoopの設定ができてフリーだよ Cloudera：Hadoopに関していろいろサポートしているよ。（Enterprise用ソフトやトレーニングなど） ◎About Hortonworks：Owen O\u0026rsquo;Malley（Hortonworks）\n1.About Hortonworks 2011/2月に設立 22人のYahooからのアーキテクトとコミッタにより設立 2.Credentials Yahooのクラスタの経験者がいますよ。 OSSに長けた人達によるチームです。 3.What is Apache Hadoop Hadoopの説明（別の側面が幾つかあり。） Commodity Hardwareで動く 簡単にプログラムできる 典型的なアプリケーションのタグクラウド（あとでちゃんと見る） HadoopのほとんどのソースコードはYahooで作られてるよ。 Clouderaとか目じゃないよ 4.Hadoop @ Yahoo! 各種サーバや規模など Science Hadoop Cluster \u0026lt;-\u0026amp;gt; Production Hadoop Cluster \u0026lt;-\u0026amp;gt; Serving Systems という構成で、いろいろやってます。 5.Hadoop Market ビジネス：ビッグデータを扱って色々やろうね 金融系：IT系のコストをOSSとHadoopで削減 技術系： 6.Hortonworks Strategy Hadoopを利用、管理しやすくするためのいろんなことをコミュニティに還元しますよ。 性能などについても同様。 トレーニングやテクニカルサポートやりますよ。 QA： Q：42Kのノードの管理ツールはなに？ A：手で管理してます。 Q：社名の由来は？ A：童話でHortonという名前の象の話がある。 Q：CDHはおすすめ？それともほかのものがいい？ A：※聞き取れず。。。 Q：500万Query/月はアドホックQueryもあるの？ A：幾つかのクラスタに分けて使ってる。アドホックは不明 ◎How Hadoop needs to evolve and integrate into the enterprise：Ted Dunning（MapR）\n・Quick History ・英語わからない身には辛い。。。 Zookeeperの人らしい。 Narrow Foundations HDFSとNASの間には大きな壁があり、大きなデータを移動するのはコストが掛かる。 Broad Foundation HDFSの代わりにNAS、RDBMSの下に位置するMapRを用意 ど、どんな仕組み？-\u0026amp;gt;テクニカルセッションで。 QA： Q：MapRはOSSにしないのか？ A：MapRで開発したものはApacheに還元はしますが、OSSにはしないよ。フリー版は提供するかも ここで昼食。午前中からいた人にはランチボックスが提供されました。 午後からはコミュニティトラックとテクニカルトラックの2トラックがありましたが、LTが聞きたかった（それよりも英語が辛かった？）のでコミュニティトラックのど真ん中、最前列に入り浸りました。 ★コミュニティトラック ◎Elastic MapReduce Amazonが提供するHadoop：大谷晋平（Amazon）\n・Amazonとは Eコマース 流通 AWS の3つのサービス ・AWS Low-level、High-level、Cross Service、Tools to access services、アプリケーション 色々あるなー ・Bigデータが大変な理由 ケタ違いのデータ量、異なる形式データ、即時性 現状システムはスケールしない ビジネスとして成立する？ 成立するならすぐスケールだめならすぐ縮小 ・Hadoopとは？ これまでのお話。 スケーラブル、低価格なハード 誰でも入手可能で、実績多数。 ・Amazon EMR AWS上でスケーラブルなインフラ上に構築が可能 オンプレミスからMapReduceアプリを移行可能なため、分析、解析に集中可能 S3からデータIN/OUTするので、データ欠損がない。 Hadoopそのままではチューニングやクラスタサイズ見積もりも難しい ＝＞クラスタサイズを動的に拡張伸縮可能。パフォーマンス最適化もできるよ。 0.18、0.20が利用可能。 EMRはHDFSとジョブ（タスク）トラッカーを別構成にしている。 EC2上にMaster、Core、タスクノードを展開 S3にデータを格納 SimpleDB（KVS）を利用 ・EMR注目機能 ジョブフローの高速化 ジョブの再起動無しにコスト/パフォーマンス比を変更可能。 タスクノードを動的に増やせる 柔軟なデータウェアハウスクラスタ タスクノードをバッチ実行時にのみ増やせる。 ※増減できるのはタスクノード Coreノードは増加のみ EMR＋Spotインスタンスの活用 コスト削減効果が非常に高い AWSの余剰リソースをリーズナブルに提供（Amazon的にもウハハだ） ・その他の機能 東海岸だけだけど、スパコンレベルのインスタンスも利用可能 AWS上での最適化設計など ※ちょっと時間足りなくなってきたｗ ・EMRの事例 1.Razorfish ROAS（広告費用対効果）を500%改善（すげー） 2.So-net ・EMR都市伝説 物理vs仮想 そりゃ、物理が速いよ EMRの柔軟性・拡張性がセールスポイント ビッグデータは成功/失敗が読めないのもあるので、 インフラに投資する部分を少なくできるよ。 オンプレミスが安い？ いやいや、HWの購入から設定など時間かかる。 ・Beyond Hadoop HadoopのIn/Out含めてスケーラブル、フレキシビリティが重要 運用管理の仕組みも重要 まだまだやってくよ。 QA Q：EMRは複数サービスから構築してるけど、一部がダウンするとどーなる？（例：SimpleDBが落ちてるとか） A：ジョブはReRunしてもらうか、SimpleDBの状態をみてリカバリをしてもらう。 Q：上記にともない、SLAの計算は？ A：SLAはEMRについては定義できてない。S3などはリージョン跨いで Q：S3のセキュリティが心配だが、どう考えてるか？ A：いままで脆弱性を晒してデータをロストしてない。 ユーザコントロールなどもできる。基本的には問題ない Q：EMRでS3を使う＝Hadoopのローカリティの利点が失われるのでは？ A：オーバヘッドはあるが、実際のデータはS3で守られているので、HDFSが飛んでも大丈夫。 Q：S3からのコピーオーバヘッドはどーなるか？ A：Single5で少しずつor分割して全部送るも可能 Q：EMRはマルチテナントだけど他のユーザのネットワークの影響を受けないの？ A：マルチテナントだと起こる可能性がある。 M1（？）だと内部ネットワークは専有可能らしい。 ◎LT\n・Hadoop and Subsystems in livedoor @tagomoris ピーク時に15Gbps。 10ノード（36コア） CDH3b2を利用 データマイニングではなく、ログからレポーティングをするのに利用している。 hadoop streaming + Hiveで実施 580G/dayが96サーバから来る ScribeにてHadoop Streaming（Perl）でper hourでHiveにload scribelineをWebサーバに入れててログ配送してくれる。 **　・Lightweight　@stanaka（はてなCTO：田中慎司さん）**\nEMR以前 自前20台クラスタ ジョブがあふれてきた ナマMapReduceを利用 PerlでMapper/Reducerを記述（Hadoop Streaming） EMR導入 リソース増やせて便利！ 必要な台数に伸縮可能 問題点： S3にアップしないとダメ ＝＞ログデータをS3に展開するlog2s3.plを作成。毎時実行。 起動、ジョブキック、結果改修どーする？ ＝＞Net::Amazon::EMR::Wrapperを作成した。 クラスタ起動、ジョブキック、クラスタ停止などできる 作ってみて思ったこと よかったところ： Perlでかける。Cronで実行可能。HiveQL便利。 悪かったところ。 途中で失敗してクラスタ起動しっぱなしとかがある。S3にデータを展開が大変。複雑な計算がきつい。 慣れてないエンジニアにも触れるようにしたい ＝＞Perlで書けるようにした？。 **　・HBaseでグラフ構造を扱う（開発中）：アメーバ鈴木**\n自己紹介@brfrnl69 アメーバのソーシャルグラフ 基本はMySQL マスタ分散が難しい、シャーディング管理が面倒 ＝＞HBaseでやってみるか。 目的　グラフデータに対して高速に更新追加したい。 隣接ノードが取れればいい（これを高速化したい） オンライン処理したい 運用コストの削減したい。 Not目的 マルチホップはどうでもいい。 アーキテクチャ JavaでGatewayつくってみる。 ・Large-Scale Graph Processing：井上さん（@doryokujin）さん Map/Reduceではグラフ計算だめ？ Vertex基本だとShuffleに問題ががが。 BSPの紹介 Bulk Synchronous Processing Google Pregel SSSP：MapReduce Model すごい計算時間が掛かりそう。MRの組み合わせが何回回ることやら。 枝が少ないとこっちのほうがいいのか？ SSSP：PregelModel シンプルなアルゴリズム Pregel使えるのあるの？ Hama GoldenOrb Giraph YERN？YARN？ ◎リクルート式Hadoopの使い方：石川（リクルート）\n@ground_beetle ・導入の課題点 バッチ処理時間対策のため。 ＝＞実は入れたかっただけｗ ・導入の障壁 現行システムへの影響＋開発工数 ＝＞これへの対処がこのあとの話 ・課題の克服と活用シーン Azkaban知らなかった。ジョブスケジューリングツール Hadoop単体ではなく、エコシステム（関連ツール）が魅力 ・活用シーン：Hive SQLゆーがざ多く、HiveQLがSQLライクのため導入が簡単に！ 既存機能のリプレイス系案件に活躍（低工数＋簡単に高速化） とりあえず、Hive実装 ＝＞性能アップのためにMapReduceで書きなおし Hotpepperなどのアトリビューション分析に利用 ・活用シーン：Sqoop＋Hive RDBとHadoop連携のツール：Sqoop 現行システムの横にHadoopを配置でき、RDBMSの利点も利用しつつHiveも利用できるようになる。 （※気を付けないといけないけどねぇ。） ゼクシィで活用しようとしてるところ。 ・活用シーン：Mahout マイニング用ツール カーセンサーのレコメンド（同時に閲覧される車種） アソシエーション分析＋クラスタリング ・活用シーン：BIツールの導入 何度か導入しようとして失敗してます。。。 BIツールの前処理（クレンジングなど）にHadoopを活用 ・インフラリソースは？ 全部で118台。 最小のクラスタ構成はサーバ6台で構成してる ・Hadoopで複数処理を回す方法 ここまで紹介したものを入れてますよ。Hive、Sqoop、Solr。。。 ・Azkaban TomcatにWar配置で利用可能。 LinedInのチームにより作成 ※若干マシントラブルで中断 ・今後のHadoop導入 ログ基盤 分析エンジン・レコメンドエンジンとして バッチ処理短縮＝トライアンドエラーが簡単にできるようになる。＝色々な気づきが出てくる。 アジャイル的な解析が可能に。 ・開発サイクルの短縮ができるエコシステムでビジネスが回りだす。 ・今後の展開 MapRが気になってる。 マルチテナント対応ができてうはうはできそう。 EMCと共同して検証中 QA： Q：性能監視ツールの選別の理由は？ A：Zabbix、Cactiです。今から利用しようと思っている段階。 Q：CDH、GreenPlum、Apacheをそれぞれ利用してるけど、使い分けのシーンは？比較は？ A：CDH3u0です。GreenPlumは使ってないです。理由は言うとクビが飛ぶ可能性ががが。 Q：高度なデータ分析ができる技術者はどこからヘッドハントしてるの？ A：MITに別途分析チームが存在し、高度な分析をしてくれる。 Q：NameNodeの冗長化はどーやってんの？ A：象本と一緒DRBD＋HeartBeat Q：EMRの導入を検討してる？ A：今後、サーバ数が多くなると導入の検討をしていくと思う。 現時点は、運用ノウハウも入手するために社内で使ってる。 EMRになるかRCloud（リクルート社内クラウド）になるかは不明。 Q：HBaseを利用してる？ A：してないです。スペック的にサーバが買ってもらえないと厳しいです。 ◎The history and the future of Hadoop use case at Rakuten：Tarje Marthinussen（楽天）\n・Introduction（self、rakuten） NextGeneration Search Group Norwayから来ましたよ。 ・RakutenのBigDataとは ・Hadoop at rakuten　Recommendation（2009） ProductRanking、GenreRanking、Log解析、（2010） Enhance Search。。。（2011） ・PigやHiveのようなものが簡単に利用できるようになってきた ・新しい検索プラットフォームを構築中 index 10k docs/sec search 400qps ・What\u0026#39;s Next Generation Search 20%はインデックスとQuery評価の 50%がデータの前処理（データとQuery） 30%がアナライズ ・Collecting Data？ ログの取得はバッチ処理だった。これをStreamingに（Flume） ・Flume Zookeeperを利用してFlumeを管理してる？？？ ・気になる部分があったので、改善のコーディングしてるよ。 ・セキュリティ マスタで管理できるように ・Pools Agentが送信先がコケてると他のPoolにスイッチ可能に。 ・MasterlessACKs QA Q：パッチ作成は何人でやってるの？ A：50人が働いていてOSSコミッターが何人いるかはわからんです。 Q：ログはテキストだけど、パース処理はどこで？（古橋さん） A：Flumeは各ノードでうまい構成になっていて Decorator 性能問題は？ HiveはJSONデータをうまく活用できてるよ。 Q：Masterlessとそうじゃないバージョンの性能比は？ A：ノード数が増えると Q：HBaseじゃなくてCassandraなの？ A：（※英語きつい。。。聞き取れず） ◎マーケティング向け大規模ログ解析事例紹介：原謙治（NTTコミュニケーション）\n・自己紹介 ・BizCITYというクラウドサービスを展開中 まずは、宣伝。 Bizストレージ、Bizマーケティングとして大規模データ、分散処理を実施してる。 ・Hadoop in Bizマーケティング CGMデータを解析して口コミ情報抽出 アクセスログから行動情報抽出 ・Hadoop in BuzzFinder CGM DBからHDFSにインポートして解析開始。DBはPostgreSQL 処理フローは資料参照。 リッチインデクシング技術（NTT研究所が開発した日本語解析技術） ※検索インデックスってどんなものなんだろう？ ポジネガ分析気になる。 ・Fast Map-Reduce for PaaS Services アクセス解析やマーケティング解析を行う上でShuffleコストが大きくなるため大量マシンが必要 ＝＞マシン数を減らすことが目的？ Map Multi-Reduce、PJoinはNTT研究所が開発した技術！？（子象本にないっけ？？） ＝＞Multi-Reduce。同一ノード上のMap出力をReduceすることで、shuffleフェーズに渡るデータを削減している。 ＝＞PJoin　QA Q：Map multi-reduce、PJoinはどう実現してるのか？公開するのか？ A：Hadoopの0.19に改造をしてる。 公開できるかどうかはわかりません。NTT研究所が研究しているものを試しに実装してみてるから。 なのでパッチにはなりませんかね（研究所に聞いてみないとわからないっす） Q：性能が向上したパターンはあったが、悪化する場合などはあるのか？ A：不明 Q：Map-side Joinとの違いは？ A：。。。 ※この辺で少し集中力が途切れてしまいました、すみません。（次に集中したかったので。。。） ◎ミクシィにおけるHadoopの利用：伊藤敬彦（mixi）\nLSH-Based Recommendation engine powered by hadoop ・実はmixiの話はすくないよ。 ・利用している環境。5or6台/クラスタ ・Hadoopの活用 ログデータをHDFSに保存 DBコンテンツをHDFSに入れることで、DBに負荷をかけずに解析する。 ・マイニングも検証中 検索クエリログをベースにデータマイニング では、本題。 ・LSHを利用した推薦 ・推薦とは？ mixiにはいろいろ推薦（レコメンド）を付加できるサービスがある。 ・推薦するには？ 類似インスタンス集合を抽出する。 インスタンスは文書だったりユーザだったり ・類似インスタンスとは？ 同じ特徴を持つ集合 例：同一商品購入したユーザとか同一単語を持つ文書とか ・抽出するには？ 全ユーザごとに全ユーザとの類似性をチェックすると時間がかかりすぎる！ ＝＞LSHを利用しよう！ ・LSHについて 特徴： ・速い！ ・精度はそれほどではない 事例： ・Google Newsのレコメンド（USロケール） ・LSHの処理ステップ 2つだけ。 1.インスタンスベクトルを計算（似ているデータは同じ値が返りやすい関数） 2.同一値が帰ってきたデータが類似インスタンス ・インスタンスベクトル例（あとでスライド見ようね） ・Likelikeがいち実装。Hadoopでうごくよ ・実験について トップページに表示されていない記事を知ってもらうために推薦してみるぞ！ ・実験１ 性能を測ってみた ・実験２ 精度を調べてみた。 精度はほんとにひどいな。。。 ＝＞同一カテゴリの遷移を元に計算したらそれなりになってきた。 ・今後 データソースを増やしたい。 他のアルゴリズムも実装したい ・CM 以下も作ってますよ。 Oluolu Anuenue QA Q：Mahoutは使わないんですか？ A：Likelikeを作った頃にMahoutになかったので作った。 性能比較したいと思ってる。 Q：ログサーバのデータ転送はどーやってる？ A：伊藤さんのところにはどういう仕組みかは上がって来てない。 Q：ベクトルの次元数はどのくらいまで耐えられる？ A：高次元のデータに対して耐えられるように作られてる。 次元数が低くて良い制度が欲しければ他のアルゴリズムがいいかも。 Q：ユーザのベクトルを作るテクニックは？ A：画像などであれば大変だけど、ユーザであれば、単語とかキーワードとかで Q：ニュース以外のデータは？ A：まだまだ実験中。まだやってない。 Q：推薦される記事数のばらつきはどういった理由が考えられる？ A：後ほど考察してQAサイトに入れます。 Q：LSHをMapReduceに載せたということだけど、関数の計算をさせてる？ A：Iterationはしてない。 Map側でLSH関数計算してる。Reduceにて類似インスタンスを導出してる。 Q：今後の予定の空間木とは？R-Treeだと高次元できついのでは？ A：低次元にて利用できるように用意したい。 Q：HamaとかGiraphで高速化させてみるのはどう？ A：イテレーションがいらないからあまり利用用途がないかなぁ。 ◎懇親会\nAWSを採用しない企業がいくつかあったのでそのあたりを質問してみた。 AWSは通常運用に利用すると結構なコストがかかる場合があるので、ノウハウがある企業や データ量が多い場合は、オンプレミスの場合を選択しているらしい。 やはりスポットで利用する方がお得感があるみたいだった。 Twitter上だけの知り合いだった方々と面識が持てたのが一番の収穫でした。 感想＋調べること\n感想\n会場規模とかQAサイトとかオープニングムービーとかすごかったです。しかも無料。さすがリクルートさん。 ランチボックスとか出てきたし。装飾もとても無料のカンファレンスと思えない出来でした。 午前中はHadoopをもとにした各社の戦略とCMという感じが色濃かったです。少しずつ各社の立ち位置が違いそれはそれで面白かったです。 AWSの説明を聞いてやはりAWSを扱える技術は必要だと再認識。 お金かけないで触ってみれるレベルでまずは触ってみるかなぁ。 洗脳されてるのかもしれないけど、自社or自前でHadoop運用するのは厳しそうです。（懇親会ですこし認識が変わった） カフェコーナーでは、リクルートのMITの冊子が配られていたり、映像や案内に使われていたHadoopマスコットのシールが配られていたりと小技も聞いてました。 あと、オライリーの販売コーナーも用意されていて、思わず子象本を買ってしまう罠にはまったりもしましたが。。。 mixiの伊藤さんの話は最後で疲れていたのですが、ストーリーが上手くできていて、実験や事例もあったのでわかりやすかったです。 Hadoopはエコシステムと呼ばれるHadoopを活用するツール群（Hiveの話が多かった？）、Hadoopの今後、Hadoopを活用したログ解析の話など、 話題が豊富でそれぞれの話が面白くて困ってしいまうくらいです。 いくつかのセッションで出てきたのですが、アクセスログなどをHDFS上に集めるための仕組みがまだ乱立（定番がまだない）している感じを受けました。 Flume、Scribe、MapR。。。などなど あとは、テクニカルセッションのビデオがアップされたらまた目を通さないと。。。 残念ながらHadoopから少し縁遠くなっていますが、これからもネタや参考になりそうな話には事欠かなそうなのでかじりついていこうと思います。 ※一番やらないといけないのは英語の勉強かもしれないです。。。 調べること 一応Solrの人なので、Solrに関連しそうな話に興味がいってしまいます。\nNTT研究所のリッチインデクシング技術 やっぱりAWS触ってみる。EMRまでとは言わないが。（herokuもちょっと興味あるが。） Mesos、GreenPlum、Scribe、Storm、Flume、Giraphこれらの概要 関連サイト 公式QAサイト。後日録画していたセッションがアップされるそうです Hadoop Conferene Japan Fall 2011 - 急がば回れ、選ぶなら近道 Hadoopカンファレンスが開催、本格普及を見据えた支援サービスや先進事例が充実 - ニュース：ITpro Hadoop Conference Japan 2011 fallで使用された資料 #hcj11f | インフラエンジニアのつぶやき（スライドをまとめてくれてます。）\n","date":1317113460,"dir":"post/2011/","id":"97402287d8c6c03f0b63848e17e9d944","lang":"ja","lastmod":1317113460,"permalink":"https://blog.johtani.info/blog/2011/09/27/hadoop-conference-japan-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-09-27T17:51:00+09:00","summary":"Hadoop Conference Japan 2011 Fallに行ってきました。 まずは、ユーザ会の方々、運営の方々、発表された方々お疲れ様でした。こんな機会を用意していただき、ありがとう","tags":["hadoop"],"title":"Hadoop Conference Japan 2011 Fallに参加してきました。(Jugemより移植)"},{"contents":"台風15号すごかったですね。幸いにも（？）夏休みだったので、通勤などでひどい目に合わずにすみました。 風雨はすごくてちょっと怖かったですが。。。\nさて、夏休みに進める予定が、子供の寝かしつけで一緒に寝てしまう日が続いてしまい、 間が開いてしまいました。\n0日目というタイトルになっているのは、まだ、1日目に入ってないからです。。。 Ioという未知の言語をMBAにそのままインストールするのも抵抗があり、VirtualBox上にLinuxをインストールしてから 進めようとして思いの外手こずってしまったためです。 ということで、0日目として、VirtualBox上にScientific Linux 6.1をインストールしてIoのインストールまでではまった箇所を記録として残しておきます。\n罠その１ 罠と言うよりは、私の無知に関する部類なのですが。。。 Scientific Linux 6.1のインストールは特に手こずることなくインストールでき、 起動も出来ました。 次にscpコマンドでダウンロードしてきたIoのソースをLinuxに渡そうとしてはまりました。 問題となったのはネットワーク接続が「NAT」のみだったため。 NATのため、Linux（ゲストOS）から外部への接続は可能だったのですが、Mac（ホストOS）からLinux（ゲストOS）への接続ができませんでした。 で、変更したのは以下の2点。\nVirtualBoxの環境設定-\u0026gt;ネットワーク-\u0026gt;ホストオンリーネットワークの追加 仮想マシン（Linux）の設定-\u0026gt;ネットワーク-\u0026gt;アダプタ2を有効にしてホストオンリーアダプタを割り当て 1番目のホストオンリーネットワークの追加をしておかないと、2番目のアダプタ2でホストオンリーアダプタを選択したときにエラーが出て、設定ができませんでした。割り当てるべきアダプタを先に用意しとかないとダメですよね、そりゃあ。\n罠その２ これも罠というほどではないのですが。。。 Ioのビルドにはcmakeが必要なのですが、Scientific Linux 6.1に入っているcmakeはバージョンが古い（2.6.4）ため、必要なバージョン（2.8以上）をインストールしないとダメでした。 インストール自体はcmakeのサイトにある手順通りのため割愛します。\n罠その３ これもちゃんとドキュメント読めよというレベルですが。。。 Ioのインストールは以下のコマンドを実行するという話です。 私がcmakeについて知らなかったと言われればそれまで。。。\n$ cd io $ mkdir build \u0026amp;amp;\u0026amp;amp; cd build $ ccmake .. $ make $ sudo make install 3つ目の「ccmake」の部分がIoのGetting Startedの下の方にありました。上の方に記載がある「cmake」ではエラーがでてうまく行かなかったので。 IoのGetting Startedにもありますが、ccmakeの場合はCUI上にGUIのようなものが起動するので、「c」（configure）と実行後、「g」（generate）を実行して最後に「e」（exit）でccmakeを離れます。 するとmakeが実行できるようになりました。\nあとは、/etc/ld.so.conf.d/io.confファイルを作成し、「/usr/local/lib」と記述。ldconfigを実行することで、Ioが実行可能になります。 ということで、1日目に入れず終了。。。\n明日は出来るかなぁ。\n","date":1316716440,"dir":"post/2011/","id":"62f31128a21b0e240bdb7b3d5b121c04","lang":"ja","lastmod":1316716440,"permalink":"https://blog.johtani.info/blog/2011/09/23/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-0%E6%97%A5%E7%9B%AE/","publishdate":"2011-09-23T03:34:00+09:00","summary":"台風15号すごかったですね。幸いにも（？）夏休みだったので、通勤などでひどい目に合わずにすみました。 風雨はすごくてちょっと怖かったですが。。","tags":["読書"],"title":"「7つの言語　7つの世界」 Io 0日目(Jugemより移植)"},{"contents":"Solr/Lucene 3.4がリリースされました。（速報）\n以下、各サイトへのリンクです。\nSolrリリースのお知らせ\nLuceneリリースのお知らせ\nちなみに、先日のSolr勉強会で関口さんが話されていたインデックスが壊れるバグですが、 先日のアメリカのハリケーン（Irene）で実際に電源が落ちて見つかったみたいです。\nということで、3.4がリリースされたので、3.1~3.3は利用しないほうがいいようです。\n追記： lucidimagination.jpのサイトに日本語のリリースノートが公開されていたので、リンクを記載しておきます。\n","date":1316046660,"dir":"post/2011/","id":"54da1b916f49ef40c822fab61d37cf66","lang":"ja","lastmod":1316046660,"permalink":"https://blog.johtani.info/blog/2011/09/15/lucene-solr-3-4%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/","publishdate":"2011-09-15T09:31:00+09:00","summary":"Solr/Lucene 3.4がリリースされました。（速報） 以下、各サイトへのリンクです。 Solrリリースのお知らせ Luceneリリースのお知らせ ちなみに、先日の","tags":["solr"],"title":"Lucene/Solr 3.4リリース（速報）(Jugemより移植)"},{"contents":"ということで、Rubyの最終日の感想。 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大募集です。コメント欄にどしどしコメントください。そこは違うだろ？こっちのほうがいいのでは？という感じで。\n感想： ◎メタプログラミングが特徴 例：ActiveRecordのhas_many、has_oneがいい例\n◎オープンクラス クラス定義をいつでも変更可能。 あらゆるクラスやオブジェクトをいつでも再定義できる 書きやすいコードのために再定義が可能＝何でもできるが気を付ける必要あり。 DSLの定義に便利。 確かに便利。ただ、範囲を限定しないと予期せぬ場所で問題が発生しそう。 ※解析するための手段はいいのがあるのかな？=\u0026gt;method_missingみたい\n◎method_missing 対象メソッドが見つからない場合に最後に実行されるメソッド 通常はNoMethodErrorが発行される。\n◎モジュールによるメタプログラミング defやattr_accessorなどその一例。 DSLではモジュール内にメソッドを定義してメソッド＋定数を利用 ActsAs\u0026hellip;ってそういう意味合いだったのか。 親クラスバージョン、親クラス＋マクロ、モジュールそれぞれの実装の仕方の紹介。 ※マクロもinclude同様、実行順で、メソッドの上書きが発生するのか？ ActiveRecordではメタプログラミングを利用してDBのカラム名からアクセサを追加。 シンタックスの美しさ＝読みやすさ\n感想＆疑問点： メタプログラミングはフレームワークを作成するのが便利そう。 ただし、エラーや問題が起きた時の対処をきちんと準備しておかないとひどい目に合いそう。 クラスやモジュールはわかりやすい単位で1ファイルにまとめるもの？ ファイル名の規則とかあったりする？ ディレクトリ構成でパッケージ構成が可能？ 複数のモジュール（gemとか）を組み合わせて使っている場合にincludeの順序がどのようになるかが気になる。 予期せぬ順序でincludeされて利用しようと思ったメソッドがオーバーライドされてるとかありそう。 追っかけるのがまた大変そうだ。 異なるパフォーマンス（開発者の開発速度）の観点が一番おもしろかった。ただ、なれるまでは大変そう。すんなりinjectとかコードブロックをうまく利用するイメージがわかない。 まぁ、思考については反復練習かな。これは他の言語でも一緒かな\nようやく、Rubyの世界が終わりました。楽しかった。次は未知の言語である「Io」です。\n（試してみよう：） ○eachメソッドがCsvRowオブジェクトを返すようにCSVアプリケーションを変更せよ。そのCsvRowのmethod_mmissingを使って、与えられた見出しの列の値を返すようにせよ。 モジュールにて実装してみた。 ``` module ActsAsCsv\ndef self.included(base) base.extend ClassMethods end module ClassMethods def acts_as_csv include InstanceMethods end end\nmodule InstanceMethods\ndef read @csv_rows = [] file = File.new(self.class.to_s.downcase + '.txt') headers = file.gets.chomp.split(', ') file.each do |row| @csv_rows \u0026lt;\u0026lt; CsvRow.new(headers,row.chomp.split(', ')) end end def each(\u0026amp;block) csv_rows.each(\u0026amp;block) end attr_accessor :csv_rows def initialize read end end\nclass CsvRow def initialize(headers, csv_contents) @headers = headers @csv_contents = csv_contents end\nattr_accessor :headers, :csv_contents def method_missing name, *args csv_contents.fetch(headers.find_index(name.to_s)) end end end\nここまでが実装したモジュール＋クラス。 以下は実行例。id,name,sizeというheaderをもつCSVを使ってみた。 require \u0026lsquo;acts_as_csv_module_mod.rb\u0026rsquo; =\u0026gt; true class RubyCsv include ActsAsCsv acts_as_csv end =\u0026gt; RubyCsv csv = RubyCsv.new =\u0026gt; #\u0026lt;RubyCsv:0x103c4c530 @csv_rows=[#\u0026lt;ActsAsCsv::CsvRow:0x103c4c030 @csv_contents=[\u0026ldquo;1\u0026rdquo;, \u0026ldquo;RubyCsv.class\u0026rdquo;, \u0026ldquo;20\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;, #\u0026lt;ActsAsCsv::CsvRow:0x103c4be78 @csv_contents=[\u0026ldquo;2\u0026rdquo;, \u0026ldquo;JRubyCsv.class\u0026rdquo;, \u0026ldquo;50\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;]\u0026gt; csv.each {|row| puts row.name} RubyCsv.class JRubyCsv.class =\u0026gt; [#\u0026lt;ActsAsCsv::CsvRow:0x103c4c030 @csv_contents=[\u0026ldquo;1\u0026rdquo;, \u0026ldquo;RubyCsv.class\u0026rdquo;, \u0026ldquo;20\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;, #\u0026lt;ActsAsCsv::CsvRow:0x103c4be78 @csv_contents=[\u0026ldquo;2\u0026rdquo;, \u0026ldquo;JRubyCsv.class\u0026rdquo;, \u0026ldquo;50\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;] csv.each {|row| puts row.id} (irb):8: warning: Object#id will be deprecated; use Object#object_id 2179096600 (irb):8: warning: Object#id will be deprecated; use Object#object_id 2179096380 =\u0026gt; [#\u0026lt;ActsAsCsv::CsvRow:0x103c4c030 @csv_contents=[\u0026ldquo;1\u0026rdquo;, \u0026ldquo;RubyCsv.class\u0026rdquo;, \u0026ldquo;20\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;, #\u0026lt;ActsAsCsv::CsvRow:0x103c4be78 @csv_contents=[\u0026ldquo;2\u0026rdquo;, \u0026ldquo;JRubyCsv.class\u0026rdquo;, \u0026ldquo;50\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;]\n\u0026lt;span style=\u0026#34;color:#FF0000\u0026#34;\u0026gt;※idというcsvフィールド名にしたら、object_idとかぶっているようでwarningが出てしまった。\u0026lt;/span\u0026gt; CsvRowクラスの定義がモジュールの中に入っているが、この実装でも動くみたい。ただ、パッケージみたいな感じ7日までは調査してない。。。 ","date":1315992060,"dir":"post/2011/","id":"41b811063b9425de1934e77d89118022","lang":"ja","lastmod":1315992060,"permalink":"https://blog.johtani.info/blog/2011/09/14/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-3%E6%97%A5%E7%9B%AE%E6%9C%80%E7%B5%82%E6%97%A5/","publishdate":"2011-09-14T18:21:00+09:00","summary":"ということで、Rubyの最終日の感想。 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大","tags":["読書"],"title":"「7つの言語　7つの世界」 Ruby 3日目（最終日）(Jugemより移植)"},{"contents":"「第6回Solr勉強会」に参加しました。 なんだかんだと第6回で、今のところ皆勤賞です。\nということで、主に自分用ですが、メモなどとったので。\n概要\n日時 :2011/09/12 19:00 to 21:00 定員 :110 人 会場 :株式会社 ECナビ 1.「Lucene/Solr 3.2-3.4」 by ロンウイット 関口 宏司さん ※Solr2.9.4、3.1でデグレードし、Solr3.4で修正されたバグがあります。 インデックス中にPCがシャットダウンされた場合にインデックスが壊れてしまうものあり。 Solr3.1-3.3は使用しないようにとのこと。 ○index ・IndexWriter.addDocuments(docs) 複数ドキュメントの更新が可能になった。 ※検索で話をする親子関係のNestedQuery向けの登録にも利用する。 この登録では途中でフラッシュされないため、セグメントが分割されない特徴あり。 複数だけでなく、 ・TieredMergePolicy ※Lucene3.2/Solr3.3からデフォルトになった。 新しいインデックスのマージポリシー。（amebaの開発者ブログに説明があった。） インデックスの登録順が守られていたが、このマージ処理では保証がされなくなったので注意が必要。 ・update.chain update.processorがdeprecatedに。 update.chainというパラメータに変更 ○index(cont\u0026#39;d) ・TwoPhaseCommit ・UniqFieldsUpdateProcessor 重複した値を削除するための機能。 UIMAでの提案から取り込まれた ○search ・group=on 検索グルーピング機能を使えるパラメータ ・{!term} クエリパーサを通さないでTermQueryをかける機能。 ・structured explanation debug=onの算出根拠を XMLタグで構造化されたExplanationが取得可能に ・ReloadCacheRequestHandler 関口さん担当。ExternalFileField インデックス外（外部ファイル）を元にFunctionQueryの情報を利用可能にできるのだが、 このファイルのリロードが可能になる。 ・Carrot2　3.5.0 アップグレード。 デモあり。Carrot2のworkbenchとか　○search(cont\u0026#39;d) ・hl.phraseLimit parameter FastVectorHighlighterの高速化用パラメータ。 ・{!cache=false} キャッシュを利用しないためのローカルパラメータ。fqのローカルパラメータに利用可能。 検索セッション内でキャッシュへの処理（参照・登録）をしなくなる ・BlockJoinQuery NestedDocumentQueryの名前が変更された。 （Luceneで登録されたところまで。） ○schema ・KStemFilter PoterStemmerとは別のstemmer ・ReversePathHierarchyTokenizer パスの構造化インデックスの逆バージョン ・ommitPositions=\u0026#34;true\u0026#34; 指定が可能になった。 ・version 1.4 スキーマのバージョンが新しくなった。 ○admin/tools ・action=MERGEINDEXES\u0026amp;srcCore=coreName コア名指定可能。 ・action=UNLOAD\u0026amp;deleteIndex=true UNLOAD時にインデックス削除 ・action=CREATE\u0026amp;property.name ※ぎゃーーー。打ち込み失敗。 ○ぎゃーーーー失敗。 ○技術者大募集中！！ Q\u0026amp;A Q：クラスタリングの日本語は大丈夫？入門には制限があると記載があったが。 A：analyzerが記載が簡単になってるかは不明 前処理をして別フィールドにメタデータ的にある程度単語で区切ったようなものを作成したほうがいい。 Q：グルーピングで、グルーピング後のファセット件数が取得可能か？ A：3.4ではグループ数で表示可能。 パラメータ指定で可能。 2.「Solr＠cookpad」 by ＠PENGUINANA_ さん ○COOKPADとは？ ・レシピ投稿サイト ・105万のユーザのレシピ ・30代女性の1/2が利用 ○レシピ検索 ・PC：1307万UU、1億回強/月 ・モバイルで利用が多く、スーパの店頭などで利用？ ・Androidもあるよ。 ○人気順検索（Solrですよ） ○自己紹介 ・＠PNGUINANA_ ・情報可視化＋検索が好き！！ yats、など ○Solrはどのように利用 ・レシピ検索 ・もしかして ○Tritonnから移行 同じ検索結果になるようにして徐々に移行 ○なぜ？ パフォーマンスが良い。 フィールド追加が簡単 レプリケーション-\u0026gt;ファイルベース プロトタイピングが楽 ○Solr4 nightly（on Oracle JVM） ・マルチコア利用 ・Ruby on Railsから ○簡単な構成＋説明 ・バッチからSolrへの更新をしている。 ※Analyzerを利用せず、バッチ側で分かち書き、正規化、同義語展開を行っている。 Rubyで全部かけるほうが社内に展開しやすい。 ・バッチ終了後、可能ならoptimize ※検索速度がmax20%高速になる。 ・マスタ-\u0026gt;スレーブレプリケーションはschema.xmlもレプリケート 新規フィールド追加などはレプリケーションだけで実行できて楽。 ・アプリはMySQLとSolrのSlaveにアクセス。 Solrにはidのみ。本文はMySQLから取得 インデックスサイズを小さくできる＝レプリケーション時間が短くなる オンメモリにできるため検索速度も向上 ○監視（munin） ・監視項目（コア別）： クエリ：QTime/QPS キャッシュ：hit/eviction キャッシュから漏れている数をみてキャッシュサイズを定期的に変更して無駄をなくす インデックス：サイズ/docの数 運用してから重要。開始当初は気にしてるが、そのうち気にならなくなるため。 レプリケーション：所要時間 スレーブ間でのズレを検知するため。 ※コアごとに監視することで、問題点を把握しやすくしている。 ○監視（nagios） ・監視項目（コア別）： サーバの基本的なヘルスチェック Solrが動いてるサーバのはなし。 レプリ：インデックスバージョンのチェック ズレが長いとメールが飛ぶ ○便利だった機能 ・DynamicField フィールドをあとから簡単に追加可能。 例：人気順のアルゴリズムの違うフィールド。検索用フィールド ・FacetQuery 絞り込み検索をクエリで記載可能。 現時点では社内向け検索機能で利用。 ※ファセットで簡単な解析もやってる。 例：鍋の季節ごとの登録件数。 ・HTTP経由で色々可能 検索の並列化 通常検索画面：3クエリを同時実行 あるプロトタイプ画面だと8クエリで実行したりしてる。 ・分散検索（Distributed Search） 簡単にsharding可能 思いクエリは４shardで投げる オーバヘッドが大きいので思いクエリにだけ利用しているらしい。 ○開発の流れ ・まずはステージングを更新 ・問題なければマスターも更新 例外： フィールド追加するだけだったら直接マスタへ 例：ファセット追加など。 ○パフォーマンスとか大丈夫？ 本番で複数のバージョンを持っており、 バグっていても自動フォールバックするらしい。 価値があったらパフォーマンス向上＋テスト追加 例：スニペット変更 ○気になっている機能 ・not to cache(SOLR-2429) ・SurroundQuery(Solr-2703) ・JOIN(SOLR-2272) SQLのJOINなイメージ ・BloomFilter(SOLR-1375) 単語が存在するかどうかのチェック ○Solr入門おすすめ ○おすすめ ・http://blog.sematext.com 月一で新機能が出てくる ・SolrのJIRA ・@otisg ○今後やりたいこと ・わかち書きの精度向上 ・検索セッションの分析 nDCG、クエリ分類、検索意図 ・デバイス対応 ・パーソナライズ Q\u0026amp;A Q：同義語は誰が集めている？ A：外部辞書を利用。０件キーワードから解析して取得 単語登録も一緒。 Q：プチトマトとトマトの違いはどうやってる？ A：上位、下位の概念で同義語を利用している。 本にあるよ。 Q：もしかしてはSolrの機能？ A：Solrではない。訂正候補の単語をSolrに検索してからチェックして表示する。 Q：人気順はどういった計算をしてるんですか？計算してから登録？By 大谷 A：１フィールドに外から入れている。 Q：RubyからSolrの利用方法は？独自？ライブラリ？By 大谷 A：Rsolrを利用しており、コネクション管理にだけ利用している。 あとは、ラッパーを独自で作成。 Q：4.0を利用している理由は？なかなかチャレンジャー。By関口 A：グループクエリを利用したかったため。 実際には重くて使えていない。 今は必要ないかもと思っている。年始のバージョンを利用。いつでも入れ替え可能。 マスタスレーブ構成のsolrのバージョンアップはサービスアウトしてから入れ替える。 3. 「Solrを用いた検索システムの構築」　by データセクション株式会社 高井さん いろいろな試行錯誤について ○データセクションについて 言語処理を元にデータの解析（Twitterとかブログとか）している会社。 ・昔は自社で検索サーバを構築していた ・Luceneを利用して検索サーバを構築するように変更。 ○構成（過去？） ・Lucene＋RMI 3.0から縮小で、4.0で廃止に ○SolrにするかLuceneにするか？ ・いろいろ機能があるからSolr使ってみるかｗ ○Solr導入は1.4.1から スペック マスタ： メモリ：16G Disk：2Tｘ12 スレーブ： 256GのSSDを利用 JavaVMが32bit ○ひと月分を1shardにして登録 ○検証＋手探り？ メモリが足りない。 Solrのキャッシュを全Offに。 BOBO SolrPluginってのを利用 compressオプションも利用。 各スレーブにキューを用意して1つだけしか処理しない。（なんでだ？？） ○結果 キャッシュはフィルタキャッシュのみ利用 ユーザが同じクエリを投げるのはほぼないので。 フィルタキャッシュのエントリのメモリ量の計算式（あとで資料が出てくるかなぁ。） ○問題点 ・レプリケーションでインデックスサイズの2倍の容量が必要になる。 ・レプリケーションの日時フォーマットのバグ（SOLR-1995）を踏んでしまった。 ・レプリケーション後にインデックスが消えない場合がある ○検討（1.4.1-\u0026gt;3.2） うれしい要素 レプリケーションバグがfix 省メモリや範囲検索の高速化など　かなしい要素 compressが使えなく（しかも回答してからriindexしてくれる） ○検討 余計なインデックス消す nearinfinityが出しているlucene-compressionを利用 https://github.com/nearinfinity/lucene-compression ○残った問題 facet.rangeが使えないなど。 ○じゃあ集約サーバつくっちゃえ（すごいな。） facet書き換えコンポーネントなど。 ○シャードのインデックスサイズが下がった 130GiB-\u0026gt;90GiB これはlucene-compressionの効果 ○ここまでの変更はプラグインにて対応（この一覧いいかも） ○感想 コンポーネント化されてて、簡単に追加機能が実装可能 用途次第であまりスペック高くなくても使える。 Q\u0026amp;A Q：Twitterのデータのクロール方法は？ A：HTMLをスクレイピングしている。publicなTLのみ。 Q：いきなりSolrに入れる？Solrの前処理は？ A：SolrJを利用して前処理済みのデータを登録している。 4. 「Anuenueの紹介と最近の進捗」 by @takahi_i さん（mixi） ○自己紹介 ・NAIST出身 ・ファストサーチ ・今はmixi ○mixiとは？ ○社内の緊急タスク ・内製検索エンジンをメンテナンスしやすいOSSにしたい！ -\u0026gt;Solrを選択 Anuenueも実装 ○Anuenueの作成理由は？ インデックス運用が面倒（検索（distributed search）はあるがインデックスは自前） クラスタ用のコマンドが提供されていない。 ○Anuenueが提供する機能 ・検索クラスタの簡単設定 ・クラスタ用コマンド ・もしかして機能 ○機能：Anuenueのクラスタ設定 Merger：クライアントからのクエリをMasterに分散 Master：インデックス作成側 Slave：検索用スレーブ。マスタからコピー ○クラスタの管理コマンド クラスタのコマンドを用意。 起動、コミット、登録など ○SolrCloud向けのAnuenueを検討中 branch-cloudにあります。 今後の予定 インスタンス追加削除を動的に実行できるようにしたい ○Hadoop Conferenceの宣伝ｗ Oluolu：Hadoop上で動くクエリログマイニングツール Likelike：LSHをHadoopで実装（Hadoop Conference 2011 Fallで発表） 5. LT 5.1　「solrとRの連携について」　by @yutakashino さん（BakFoo） Python本、Zope本を書いてます。 ○NHKの実証実験で利用？ ○TwitterストリームをSolrにストア facet.date ○Rでキーワード頻度グラフ Node.js、Redis、R、Solrを使ってる。しかもPython ○デモ キーワード＋日付でグラフが出てくる。 Rでプロット。 GoogleのチャートAPIを利用すると面白いことができる。 5.2　「 Apache ManifoldCF」　by 阿部さん(ロンウィット) ○Apache Incubator ○Manifold Connector Framework Solr ＜－ MCF ＜－ web＋non-web repositories すぐに利用可能。 ○概要 出力はSolr。 接続先はWeb、DB、CMS、などなどいろいろRepositoryConnectorというのがあります。 ○Crawler Agent クロールに関するJobの管理 接続先、スケジュールなど ○Windowsサーバのクロールもできる 社内のナレッジ共有などに使える。権限周りも簡単に対応可能。 JCIFS.jarによりWindowsの権限情報を取得 ○クロール設定画面もある デモ ○導入が簡単なのがおすすめ。 ○ManifoldCFの資料関連 http://www.manning.com/wright 懇親会についてはあとで記載します！！ ということで追記です。 懇親会でも色々と面白い話を聞けました。 @PENGUINANA_さんにはCOOKPADのCI関連の話を聞けました。 1日に数度リリースするという話もあるようでした。\nあとは、Rについても@yutakashinoさんから概要が聞けたのが良かったです。\nちょっとだけ追記。まだ成形する予定ですが、とりあえず。\n追記：スライドが公開され始めたので。\n関口さんのスライドはこちら 阿部さんのスライドはこちら ＠PENGUINANA_さんのスライドはこちら。 @takahi_iさんのスライドはこちらからPDFダウンロード可能。\nその他に関連するブログも見つけましたので。 「Solr@Cookpad」- Solr勉強会で発表してきました Ars longa, vita brevis: 第６回 Solr 勉強会に行ってきた\n勉強会で出てきた各製品などのリンク： 色々とURLが出てきていたので、リンクをまとめておきます。\nlucene-compression Anuenue Apache Solr のラッパー Likelike LSH (Localtiy Sensitive Hashing)の実装 OluOlu 検索ログマイニングツール @takahi_iさんのLuceneRevolution2011のスライド Kuromoji 形態素解析器 lucene-gosen 形態素解析器（Senの後継） Apache ManifoldCF ","date":1315810980,"dir":"post/2011/","id":"37b622eaad1f79e759a722aacebf48ec","lang":"ja","lastmod":1315810980,"permalink":"https://blog.johtani.info/blog/2011/09/12/%E7%AC%AC6%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-09-12T16:03:00+09:00","summary":"「第6回Solr勉強会」に参加しました。 なんだかんだと第6回で、今のところ皆勤賞です。 ということで、主に自分用ですが、メモなどとったので。 概","tags":["勉強会"],"title":"第6回Solr勉強会に参加しました。(Jugemより移植)"},{"contents":"ということで、Ruby2日目の感想（2日目だけで2日間かかったのは内緒。。。） 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大募集です。コメント欄にどしどしコメントください。そこは違うだろ？こっちのほうがいいのでは？という感じで。\n感想： ◎関数の定義：ありゃ、利用するのはダメなんだ、これじゃ。\u0026ndash;\u0026gt;単なるタイプミスでした。お恥ずかしい。。。 \u0026gt;\u0026gt; def tell_the_truth \u0026gt;\u0026gt; true \u0026gt;\u0026gt; end =\u0026gt; nil \u0026gt;\u0026gt; tell_the_trueth() NoMethodError: undefined method `tell_the_trueth\u0026#39; for main:Object from (irb):4 ◎配列：そしてシンタックスシュガー puts animalsで内容が出力されるのはうれしい。JavaだとHashCodeが出てくるから。出力メソッド書かないといけなくなる。 animals[-1]で最後の要素とかかなり便利。 animals[0..1]はRangeクラスを利用する形。Rangeはやはり便利。substringなどもできそう。 カラ配列の定義は必要。a = [] 1.9と1.8でinclude?の書き方が異なるので注意！ 配列（Array）クラスは中はObjectが入る。 多次元配列もOK。popやpushでキューとしても利用可能。\n◎ハッシュ： Mapのようなもの。任意のキーが利用可能。:付きの文字列はシンボルと呼ばれる定数値を簡単に定義する方法。 object_idという属性？関数によりObjectのハッシュコードが取れるらしい。 ブレース＝「{}」のカッコのこと。do～endでも代用可能\n◎コードブロックとyeild コードブロック＝名前なし関数。習慣では複数行の場合、do/endで、１行は{}みたい。Javaと混同しそう。 コードブロックは引数も指定可能。 「yield」予約語？を利用してコードブロック自体をメソッド内部などで呼び出し可能。 ということで、コードブロックは引数にも指定できると。コードブロック＝関数もObjectとして扱われてる感じか？ 実行遅延、分岐、共通関数とか？Javaだとabstractメソッドを利用して処理するようなイメージか？ちょっと違うなぁ。 なれると、yieldはコードを読みやすくできそう。また、シンタックスハイライトしてくれるツールがあれば、更に便利。\n◎ファイルの実行 ruby ファイル名 vi、Emacs、TextMateなどがあるよ。\n◎クラスの定義 ※数字で始まる変数は利用できない！Javaと一緒 Tree.rbとログを参考にすること。 \u0026amp;使うとブロックに名前が付けられる。yieldじゃなくてもいい？ クラス名はキャメルケース。 変数とメソッド名は「_」アンダーバーつなぎ インスタンス変数の頭は@ クラス変数は@@ 定数は大文字 ※メソッド名、変数名には違和感が。なんでこんな規則？？ 判定用関数とメソッドには「?」（if test?）をつける！！Javaでいう「is」か。\n◎Mixin（多重継承？モジュールと呼ばれるものを利用） 多重継承のような類似の振る舞いを伝搬する仕組み。 Javaではインタフェースでやること。 Rubyではモジュールといい、関数と定数の集まり。 クラスに機能を盛り込む場合はincludeする ※複数includeして、includeしたものの中に同じメソッドとかあったらどーなる？ \u0026ndash;\u0026gt;Overrideされた＝includeがあとにあるもので上書きされる Abstractにできないものをモジュール化できるの楽。 javaだとstaticメソッドだらけのUtilクラスを別途起こすイメージだけど、内部で呼ばれるメソッド（コードブロック）が同じインタフェースじゃないと行けないから、インタフェースの記述もしないと行けない。 ただし、同一名のメソッドを持ってるとややこしそう。 ※モジュールからモジュールは呼べる？\n◎モジュール、Enumerable、セット EnumerableとComparable（JavaのCollectionまわりかな。） 宇宙船演算子（\u0026lt;=\u0026gt;）Javaのequalsに似てる any?とかCollectionUtils？？に似たのあったな。 ※今利用しているクラスが何をincludeしてるかってのは分かる仕組みあるのかな？ ※そういえば、メソッドごとに戻り値があるが、全部newされてインスタンス化されてGCの対象になってるのか？irbだけ？ injectはすんなり使うイメージが出にくそう。また、ソースをぱっと見て理解出来ない。なれだろうけど。 ※injectしながらinjectとかあるんだろうな。\n（探してみよう：） ○コードブロックを使った場合と使わない場合の両方について、ファイルにアクセスするコードを書く。コードブロックの利点は？ ※コードブロックあり。 ``` File.open(\u0026ldquo;tree.rb\u0026rdquo;, \u0026lsquo;r\u0026rsquo;) {|f| f.each {|line| puts \u0026ldquo;#{f.lineno} : #{line}\u0026rdquo;}}\n※コードブロックなし f = File.open(\u0026ldquo;tree.rb\u0026rdquo;, \u0026lsquo;r\u0026rsquo;) while line = f.gets puts \u0026ldquo;#{f.lineno} : #{line}\u0026rdquo; end\nコードブロックの利点： 見通しの良さ。行数が少なくてすむ。繰り返し処理が簡単に記述できる。 ※うーん、まだきちんと理解できてないか？ \u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○ハッシュを配列に変換するにはどうすればよいか？また、逆に配列をハッシュに変換する方法は？\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt; ※間違えた。。。 h = [:key1 =\u0026gt; \u0026ldquo;hoge\u0026rdquo;, :key2 =\u0026gt; \u0026ldquo;boke\u0026rdquo;, :key3 =\u0026gt; \u0026ldquo;fuga\u0026rdquo;] h.each {|key, value| puts \u0026ldquo;#{key} is #{value}\u0026rdquo;} =\u0026gt;key1hogekey2bokekey3fuga is\nハッシュ-\u0026amp;gt;配列変換 h.to_a\n配列-\u0026amp;gt;ハッシュ変換 a = [\u0026ldquo;value1\u0026rdquo;, \u0026ldquo;valu2\u0026rdquo;, \u0026ldquo;value3\u0026rdquo;] h = {} a.each {|i| h.store(a.index(i),i) }\n※また間違い？なんでそうなる？ a.inject(h2) {|hoge, i| hoge[a.index(i).to_s] = i}\nこっちならいいみたい。まだinjectがわかってない。 a.inject(h2) {|hoge, i| hoge[a.index(i).to_s] = i;puts \u0026ldquo;#{i}\u0026rdquo;; hoge}\n\u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○ハッシュの各要素について繰り返すにはどうすればよいか？\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt; h.each {|key, value| puts \u0026ldquo;#{key} is #{value}\u0026rdquo;}\n\u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○Rubyの配列はスタックとしても使える。スタック以外に配列で実現可能なよくあるデータ構造体を挙げよ。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;キュー。 他にある？Treeとか？Treeはハッシュじゃないか？Set？順番が関係ないけど。\u0026lt;/dd\u0026gt; \u0026lt;/dl\u0026gt; ### **（試してみよう：）** \u0026lt;dl\u0026gt; \u0026lt;dt\u0026gt;○最初に、eachだけを用いて、１６個の数値と４個の数値の配列の中身を同時に出力せよ。次に、同じ事をEnumerableのeach_sliceを用いて実行せよ。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt; \u0026lt;span style=\u0026#34;color:#FF0000\u0026#34;\u0026gt;\u0026lt;em\u0026gt;※これ日本語がわからないんだが、4個ずつ出せってことか？？\u0026lt;/em\u0026gt;\u0026lt;/span\u0026gt;ということで、「16個の数字の配列の中身を4個ずつ同時に出力せよ。」と解釈して実装してみた ※each利用版 a = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16] s = [] a.each do |b| unless s.length \u0026lt; 4 puts s.inspect s.clear end s \u0026laquo; b end\n※each_slice a = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16] a.each_slice(4) {|b| puts b.inspect}\nまた、えらい違いだな。 \u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○Treeクラスは面白いクラスだったが、きれいなインタフェースを用いて新しいツリーを指定することは出来なかった。そこで、initializerにハッシュと配列が入れ子になった構造体を指定できるようにせよ。具体的には、次のようなツリーを指定できるようにしたい。{\u0026#39;grandpa\u0026#39; =\u0026amp;gt; { \u0026#39;dad\u0026#39; =\u0026amp;gt; {\u0026#39;child 1\u0026#39; =\u0026amp;gt; [], \u0026#39;child 2\u0026#39; =\u0026amp;gt; [] }, \u0026#39;uncle\u0026#39; =\u0026amp;gt; {\u0026#39;child 3\u0026#39; =\u0026amp;gt; [], \u0026#39;child 4\u0026#39; =\u0026lt; [] } } }\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;\u0026lt;span style=\u0026#34;color:#FF0000\u0026#34;\u0026gt;※root（ここではgrandpaレベル）が複数あると破綻しないのか？\u0026lt;/span\u0026gt; class Tree attr_accessor :children, :node_name\ndef initialize(name, children=[]) @children = children @node_name = name end\ndef initialize(hash) hash.each do |key, value| @node_name = key @children = value.inject([]) do |array, (child_key, child_val)| puts \u0026ldquo;inject! #{key}\u0026rdquo; [Tree.new({child_key =\u0026gt; child_val})] + array end end end\ndef visit_all(\u0026amp;block) visit \u0026amp;block children.each {|c| c.visit_all \u0026amp;block} end\ndef visit(\u0026amp;block) block.call self end end\n残念ながらちょっとカンニングしてしまいました。。。 \u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt; ○ファイル内で、あるフレーズを含む全ての行を出力する簡単なgrepをかけ。簡単な正規表現でマッチングを行い、ファイルから行を読み出す必要がある（この処理はRubyでは驚くほど簡単にかける）。必要なら行番号も出力してみると良い。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;※メソッドだけでいいな。\u0026lt;span style=\u0026#34;color:#0000FF\u0026#34;\u0026gt;ファイルクローズはこの記述の場合はコーディングブロックのendのタイミングでクローズされるのか？\u0026lt;/span\u0026gt; class RegGrep def grep(filename, regexp) File.open(filename, \u0026lsquo;r\u0026rsquo;) do |f| f.each do |line| puts \u0026ldquo;#{f.lineno} : #{line}\u0026rdquo; if line.match(regexp) end end end end\n\u0026lt;/dd\u0026gt; \u0026lt;/dl\u0026gt; ということで、2日目終了。 恥ずかしいコードだらけだけど、ぜひツッコミ入れてもらえると助かります。 数年前までは、恥ずかしいからとか見せられるレベルじゃないからと、ほとんどアウトプットしなかったのですが、 最近はそれではものすごく損をしていると思っています。 ホントは発表するとか議論するとかする場もあればいいのですが。 アウトプットすることで、フィードバックが貰えて、いろんなかたの考えが参考になり、糧となり成長していけるのかと。 （これじゃ成長できないレベルだよという話でなければいいのだが。。。） 一度、Rubyのプロフェッショナル各位に見てもらいたいなぁｗ ","date":1315588260,"dir":"post/2011/","id":"73262345214f9b7794f2cc4a612b15e8","lang":"ja","lastmod":1315588260,"permalink":"https://blog.johtani.info/blog/2011/09/10/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-2%E6%97%A5%E7%9B%AE/","publishdate":"2011-09-10T02:11:00+09:00","summary":"ということで、Ruby2日目の感想（2日目だけで2日間かかったのは内緒。。。） 今回もセルフスタディの私の回答が最後の方に記載されてます。見た","tags":["読書"],"title":"「7つの言語　7つの世界」 Ruby 2日目(Jugemより移植)"},{"contents":"実に3年ぶりくらいにゆっくりできる日々が訪れたので、積読状態の本を消化しようと「7つの言語　7つの世界」を読み始めました。\nせっかくブログも始めたので、備忘録も兼ねて感想などを書いていこうかと。\nこの本ですが、以下の7つの言語についてエッセンスがまとめられています。\nRuby Io Prolog Scala Erlang Clojure Haskell まずはRubyからです。 ここ2年ほどRuby（Rails）に関連する仕事をしていたのですが、Ruby周りはプロフェッショナルな方たちがいたので、きちんと勉強していないことがこの本を読み始めてわかりました。\nということで、前置きはそれなりな記述ですが、感想は適当になりますので、あしからず。\n感想： irbが便利。簡単に動作確認ができるのが便利。Javaだとコンパイルが必要。 変数を定義する必要がない気軽さはある。 必ず戻り値が帰ってくる「puts \u0026lsquo;hello, world\u0026rsquo;」でも。=\u0026gt;nil putsは楽かな。まぁ、Eclipse使ってると一緒か。 「4」もオブジェクトとなっている。ここもJavaと異なる。 (x \u0026lt;= 4).classという記述でTrueClassというクラスだとわかる。 unlessが結構便利。ただし、記述方法が多数あるので、可読性は落ちる？場合によってはわかりやすいか？ あと、括弧()がないのも慣れない。（まぁ、これは慣れの問題。ただし、カッコありでもOK） {}のかわりがif～endなのはわかりやすいかも。 if not はわかりやすくていい。!はだいたい間違えるから。。。 whileも１行形式で書けるのか。「x = x + 1 while x \u0026lt; 10」慣れないと厳しい。個人的には混在すると読めないなぁ。 nilとfalse以外がすべてtrueに評価されるのは厳しいのでは？型のチェックがないので、booleanが入ってると想定してない場合に挙動を読めないかも。実行時に動作が変だなーと思うことが出てきそう。 and、orの記述が使えるのは読みやすい。ただし、混在するとやっかい。 判定結果が明らかになった時点で実行が中止されるのは普通。\u0026amp;、|の挙動はJava同様。\nやりながら疑問点：\nNetBeansとかIDEでフォーマッタやcheckstyleみたいなのはあるのか？ コーディング規約はあるのか？（2日目に「習慣」があるらしいとの記載があった。） 必ず戻り値が戻ってくるのは、必ずGC対象になりうるオブジェクトが生成されるってことか？ ここまでが感想と疑問点。で、この本の面白いところは最後に調査、コーディングを行う練習問題的なものがある部分です。 一応、私なりの答えを書いておこうかと。（一覧などで見えないようにはしますが、ネタバレがあるので注意してください。）\nということで、セルフスタディの回答。\n（探してみよう） ○Ruby API http://ruby-doc.org/core/ ○Programming Ruby: The Pragmatic Programmer's Guideのオンライン版 http://www.ruby-doc.org/docs/ProgrammingRuby/参考資料：http://www.swlab.it.okayama-u.ac.jp/man/ruby/uguide/uguide00.html ○文字列の一部を置換するメソッド \"hello\".gsub(/[aeiou]/, '*') ○Rubyの正規表現に関する情報 日本語：http://www.namaraii.com/rubytips/?%A5%D1%A5%BF%A1%BC%A5%F3%A5%DE%A5%C3%A5%C1 英語の試せるサイト（irbが動けば必要ないかもね）：http://rubular.com/ ○Rubyの範囲に関する情報 日本語：http://doc.okkez.net/static/192/class/Range.html 英語：RDocのRangeクラスに相当するのかな。 （試してみよう） ○文字列\"Hello, world\"を出力する。 ``` ○文字列\"Hello, Ruby\"の中の\"Ruby\"という単語のインデックスを検索する。 ``` s = \u0026lsquo;Hello, Ruby\u0026rsquo; s.index(\u0026lsquo;Ruby\u0026rsquo;) //indexofで間違えた\n\u0026lt;dt\u0026gt;○自分の名前を10回出力する。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;``` ※まずは、正統派。 i = 0 while i \u0026lt; 10 puts \u0026#34;johtani\u0026#34; i = i + 1 end ※Rangeを利用 (1..10).each {|n| puts \u0026#34;johtani #{n}\u0026#34;} ※forもあるよね for i in 1..10 puts \u0026#34;johtani\u0026#34; end ※timesってのもある。（0始まり） 10.times {|n| puts \u0026#34;johtani #{n}\u0026#34;} ※uptoなんてのもあるのか。 1.upto(10) {|n| puts \u0026#34;johtani #{n}\u0026#34;} ※downtoも 10.downto(1) {puts \u0026#34;johtani\u0026#34;} ※stepもある。 10.step(1, -1) {puts \u0026#34;johtani\u0026#34;}//step(上限,ステップ) ```\u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○文字列\u0026#34;This is sentence number 1\u0026#34;の1を10までカウントアップしながら10回出力する。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;``` 1.upto(10) {|n| puts \u0026#34;This is sentence number #{n}\u0026#34;} ※あとは上記と一緒 ```\u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○ファイルに格納されているRubyプログラムを実行する。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;``` vi hoge.rb ※#上記処理をどれか記述 $ ruby hoge.rb ○ボーナス問題：少し物足りない人は、乱数を選択するプログラムを書いてみてほしい。プレーヤーに数字を選択してもらい、その数字が生成された乱数よりも大きいか小さいかを返す。 ``` -- coding: utf-8 -- range = (1..100) while true puts \u0026ldquo;#{range.min}から#{range.max}の数字を入力してください\u0026rdquo; n = gets n = n.to_i if range.include?(n) break; else puts \u0026ldquo;範囲外の入力値です。もう一度入力してください\u0026rdquo; end end i = rand(range.max) if i \u0026lt; n puts \u0026ldquo;入力「#{n}」は乱数「#{i}」より大きいです\u0026rdquo; elsif i == n puts \u0026ldquo;入力「#{n}」は乱数「#{i}」と等しいです\u0026rdquo; else puts \u0026ldquo;入力「#{n}」は乱数「#{i}」より小さいです\u0026rdquo; end\n\u0026lt;/dl\u0026gt; とまぁ、こんな感じ。こんな方法もあるよ、ここおかしくない？などあれば、コメント欄まで。 リアクション大募集です。 はやく、シンタックスライター導入せねば。 ","date":1315545120,"dir":"post/2011/","id":"9baedcd033169611a42c3cfd58b3ae03","lang":"ja","lastmod":1315545120,"permalink":"https://blog.johtani.info/blog/2011/09/09/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-1%E6%97%A5%E7%9B%AE/","publishdate":"2011-09-09T14:12:00+09:00","summary":"実に3年ぶりくらいにゆっくりできる日々が訪れたので、積読状態の本を消化しようと「7つの言語 7つの世界」を読み始めました。 せっかくブログも始め","tags":["読書"],"title":"「7つの言語　7つの世界」 Ruby 1日目(Jugemより移植)"},{"contents":"現在の出先でMBAを使えないので、なかなか進んでいないMBAのセットアップです。。。\nとりあえず、Eclipse、homebrewをインストールしたので、lucene-gosenの開発やビルドには支障がない程度になってきました。（肝心のSolrがまだ動く状況になかった。。。）\nあとは、Windowsで使用頻度の高いソフトを列挙して、対応するMacのアプリを探そうかと。 まずは、Windowsでよく利用するソフトのリストアップ\nEclipse Cygwin TeraTerm WinSCP meadow サクラエディタ WinMerge PDF-XChange Viewer Evernote FreeMind VMWare こんなところかな。 a.～e.についてはMacOS特に問題なし。Eclipseは入れたし、その他は標準で入ってるものでまかなえると。 f.についてもEmacsで当面対応する予定。ただ、OmmWriter やCotEditorがおすすめらしいと聞いてます。 g.についてはFileMergeなるものがあるらしいので、試してみようかと。 h.は現状Adobe Readerです。ほかにいいのあるのかしら。PDF-XChange Viewerはちなみに、Solr入門を書くときに編集の方から教えてもらったPDFのビューワです。コメントとかハイライトできるのが便利でした。 i.はMacOS版をインストールして、すでに活用中。 j.については一時期活用していたのですが、最近利用していないです。なので、保留 k.についてはVirtualBoxをインストールしてみました。フリーだったので。WindowsではVMWareだったのですが。。。\nほんとにこれくらいで大丈夫かどうかはもう少し使ってみてからかなぁと。 その他におすすめ、これがあるとかなり便利などあれば、教えてもらえると助かります。 まだ、MacOSに触り始めたところなので、細かな部分のカスタマイズなどができていないので、その辺りもオイオイ考えていこうかと。\n※余談ですが、現在「７つの言語　７つの世界」を読み始めました。いろいろな言語の特徴について学べる本のようでかなり楽しく感じています。どうしてもJavaで仕事優先だとコーディングする速度優先でJavaばかり使ってしまうので。 いい頭の体操にもなりそうなのでオススメです。（といってもまだ、最初の言語Rubyなのですが。。。）\n","date":1315329480,"dir":"post/2011/","id":"f23ca2aa066b1ee0fa4df1f2f865be4c","lang":"ja","lastmod":1315329480,"permalink":"https://blog.johtani.info/blog/2011/09/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%93/","publishdate":"2011-09-07T02:18:00+09:00","summary":"現在の出先でMBAを使えないので、なかなか進んでいないMBAのセットアップです。。。 とりあえず、Eclipse、homebrewをインストー","tags":["備忘録"],"title":"MBAセットアップ備忘録その３(Jugemより移植)"},{"contents":"すぐにテストケース追加しますといいつつ、はや一週間。\nようやく仕事が落ち着いたので、テストケースを追記しました。まだパッチの段階です。 一応、異なる辞書の読み込みのテストケースなどを追加し、テストケース追加時点で いくつか気になったところもあったので、ついでに修正を加えました。 一応、辞書の分離＋複数辞書対応については現時点ではこんなところかと。\nあと、もう１項目対応してからtrunkに取り込む予定です。 対応する項目とは以下の項目です。\nカスタム辞書ビルドの簡易化 以前の記事にも書いていますが、カスタム辞書のビルドが思いのほか手間がかかります。 辞書の外部化は対応したのですが、せっかく辞書が外部化できたのですから、コマンド（ant？）で一発で カスタム辞書を含んだビルドをしたくなるのが人情です。 辞書なしのjarファイルもあることなので、すぐに対応可能かと。 ということで、今週中には対応する予定です（宣言しないとまた先延ばしになりそう）\n忘れてそうだったらTwitterやコメントでツッコミを入れてもらえると助かります。\n","date":1315328188,"dir":"post/2011/","id":"3c2523e65ff953fd73579aaaf5d7ce36","lang":"ja","lastmod":1315328188,"permalink":"https://blog.johtani.info/blog/2011/09/07/%E8%BE%9E%E6%9B%B8%E5%88%86%E9%9B%A2%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E3%82%B1%E3%83%BC%E3%82%B9%E8%BF%BD%E5%8A%A0%E3%81%A8%E6%AE%8B%E3%82%BF%E3%82%B9%E3%82%AF/","publishdate":"2011-09-07T01:56:28+09:00","summary":"すぐにテストケース追加しますといいつつ、はや一週間。 ようやく仕事が落ち着いたので、テストケースを追記しました。まだパッチの段階です。 一応、異","tags":["lucene-gosen"],"title":"辞書分離のテストケース追加と残タスク(Jugemより移植)"},{"contents":"先日、辞書のjarファイルからの分離についてパッチと記事を書きました。\nIssueにあげていたパッチをRobertさんが見ていたらしく、次のようなコメントをもらいました。\nMaybe if we change SenFactory.getInstance to use a ConcurrentHashMap then you can easily use multiple dictionaries at the same time? 「SenFactory.getInstanceメソッドでConcurrentHashMap使ったら複数辞書対応できるんじゃない？」（訳） たしかに。。。なんで思いつかなかったのだろう。。。\nということで、実装してみました。 パッチはこちら。\n使い方ですが、先日の記事と代わりはありません。 ただし、あった制限事項が次のようになります。\nマルチコアの設定でsharedLibにlucene-gosenのjarを含まない 同一コア内で異なるdictinaryDirの指定はできない ソースの変更点ですが、ものすごく単純です。 dictionaryDirに指定された文字列をキー、その辞書ディレクトリを利用したSenFactoryのインスタンスを値に持つmapをSenFactory内に保持します。あとは、SenFactoryのgetInstance(String dictionaryDir)メソッドで取得する際にmapに対応するインスタンスがあれば、そのインスタンスをなければ、dictionaryDirから辞書を読み込んでインスタンス生成してmapにキャッシュしつつ返すという実装に変えただけです。 ということで、次のようなIPADICとNAIST-JDIC for ChaSenを同時に使う設定も可能となります。\n\u0026lt;fieldType name=\u0026#34;text_ja_ipadic\u0026#34; class=\u0026#34;solr.TextField\u0026#34; positionIncrementGap=\u0026#34;100\u0026#34;\u0026amp;gt; \u0026lt;analyzer\u0026amp;gt; \u0026lt;tokenizer class=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; dictionaryDir=\u0026#34;/tmp/lucene-gosen/dictionary/ipadic\u0026#34;/\u0026amp;gt; \u0026lt;/analyzer\u0026amp;gt; \u0026lt;/fieldType\u0026amp;gt; \u0026lt;fieldType name=\u0026#34;text_ja_naist_chasen\u0026#34; class=\u0026#34;solr.TextField\u0026#34; positionIncrementGap=\u0026#34;100\u0026#34;\u0026amp;gt; \u0026lt;analyzer\u0026amp;gt; \u0026lt;tokenizer class=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; dictionaryDir=\u0026#34;/tmp/lucene-gosen/dictionary/naist-chasen\u0026#34;/\u0026amp;gt; \u0026lt;/analyzer\u0026amp;gt; \u0026lt;/fieldType\u0026amp;gt; あと、注意事項です。 普通に考えるとわかることですが、辞書を複数読み込めるようになったことで、読み込んだ複数の辞書をメモリに保持することになります。ですので、今までよりも多くのメモリを利用するので、Heapのサイズには注意が必要です。 例のごとく（ほんとよくない。。。）テストコードを書いていない状態のパッチをまずはアップしました。 テスト書かないと。。。次回はテストコードかきましたと言う報告をしたいな\nあと、Robertさんのコメントの前に@shinobu_aokiさんからJapaneseTokenizerFactoryの設定では辞書のディレクトリを$SOLR_HOME/confからの相対パスで記述できるというパッチもいただいています。 この部分については先日と使い方が異なります。 （すみません、まだきちんとソースを見れてないです。。。）\n","date":1314668040,"dir":"post/2011/","id":"88a8e608108be939da9aab5a9a8af7d1","lang":"ja","lastmod":1314668040,"permalink":"https://blog.johtani.info/blog/2011/08/30/%E8%A4%87%E6%95%B0%E8%BE%9E%E6%9B%B8%E3%81%AE%E8%AA%AD%E3%81%BF%E8%BE%BC%E3%81%BF%E6%A9%9F%E8%83%BD%E8%BF%BD%E5%8A%A0%E4%BB%AE/","publishdate":"2011-08-30T10:34:00+09:00","summary":"先日、辞書のjarファイルからの分離についてパッチと記事を書きました。 IssueにあげていたパッチをRobertさんが見ていたらしく、次のよ","tags":["lucene-gosen"],"title":"複数辞書の読み込み機能追加（仮）(Jugemより移植)"},{"contents":"ひさびさに、lucene-gosenの話題です。\nlucene-gosenはjarファイルに辞書も同梱されており、jarファイルをクラスパスに取り込むだけで、 簡単に形態素解析器が利用できるといお手軽さがあり、便利です。\nですが、以前カスタム辞書の登録について記事を書いたように、カスタム辞書の登録は思いのほか手間がかかります。 lucene-gosenのソースをダウンロードし、lucene-gosenを一度コンパイルし、カスタム辞書のcsvファイルを作成し、カスタム辞書を取り込んだ辞書のバイナリを生成し、最後にjarファイルにするという作業です。（書くだけでいやになってきました。。。）さらに作成したjarファイルをSolrや各プログラムに再度配布するという具合です。\nそこで、辞書ファイルの外部化ができないかという話があがっていました。 すこし時間ができたので、山積みになっているissueを横目に軽く実装をしてpatchをissueにアップしました。\n機能としてはごく簡単で、JapaneseTokenizerのコンストラクタに辞書のディレクトリ（*.senファイルのあるディレクトリ）を指定可能にしただけです。 また、JapaneseTokenizerFactoryでもdictionaryDir属性で指定可能になっています。 まずは、コンパイルの方法から。 trunkをSVNでcheckoutし、issueにあるpatchをダウンロードして適用します。（svnのチェックアウトについてはこちらを参考にしてください。）\n$ cd lucene-gosen-trunk $ patch -p0 --dry-run \u0026lt; lucene-gosen-separate-dictionary.patch $ patch -p0 \u0026lt; lucene-gosen-separate-dictionary.patch 次に、antを実行し辞書なし版のjarファイルをビルドします。\n$ ant nodic-jar これで、dictディレクトリに「lucene-gosen-1.2-dev.jar」というjarファイルが出来上がります。 （※ただし、これだけでは動作しないので、別途辞書のコンパイルは必要です。）\n次に、指定の仕方です。JapaneseTokenizerのコンストラクタは第3引数に辞書のディレクトリ（フルパスor実行ディレクトリからの相対パス）を渡すだけです。\nTokenizer tokenizer = new JapaneseTokenizer(reader, compositeTokenFilter, dictionaryDir); 最後に、Solrのtokenizerタグでの指定方法です。\n\u0026lt;fieldType name=\u0026#34;text_ja\u0026#34; class=\u0026#34;solr.TextField\u0026#34; positionIncrementGap=\u0026#34;100\u0026#34;\u0026amp;gt; \u0026lt;analyzer\u0026amp;gt; \u0026lt;tokenizer class=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; dictionaryDir=\u0026#34;/hoge/dictionarydir\u0026#34;/\u0026amp;gt; \u0026lt;/analyzer\u0026amp;gt; \u0026lt;/fieldType\u0026amp;gt; 以上が、簡単な設定の仕方です。なお、辞書を内包したjarファイルでもdictionaryDirは利用可能です。優先度としては、dictionaryDirが指定されている場合はdictionaryDirを探索しファイルがなければRuntimeExceptionです。指定がnullもしくは空文字の場合はjarファイルの辞書の読み込みを行います。\n次に利用シーン、制限事項についてです。 利用シーンとしてはカスタム辞書を定期的にメンテナンス（追加更新）しながらSolrを運用するというのが想定されます。定期的に辞書の再読み込みをしたい場合です。 利用方法は次のようになります。\nSolrのマルチコア構成を利用する 各コアごとにlib/lucene-gosen-1.2-dev.jarを用意 辞書の更新が終わったらコアのRELOADを実施 コアをリロードすることで、lucene-gosenが辞書を再読み込みようになります。（現状でも再読み込みするが、jarファイルを再配置しないといけない。）あとは、定期的に辞書ファイルを更新、再構築しコアをリロードすれば、 リロード後に新しい辞書が利用できるという具合です。 （もちろん、辞書更新後に入った単語は辞書更新以前に作成したインデックスにはでてこないですが。。。） また、コアごとにdictinaryDirを別々に指定することも可能です。\n制限事項は次のようになります。\nマルチコアの設定でsharedLibにlucene-gosenのjarを含まない 同一コア内で異なるdictinaryDirの指定はできない 以上が、辞書の外部ファイル化のパッチについてでした。 少しテストケースを追加したら、trunkにコミットする予定です。興味があれば、パッチを利用してみてください。\nSyntaxHighlighterの導入をしないとソースコードが見にくいですね。。。導入を検討しないと。。。どこかにWebサーバ用意しないとダメかも\n","date":1314062760,"dir":"post/2011/","id":"2f1ec795216d5bafa33a810af3421942","lang":"ja","lastmod":1314062760,"permalink":"https://blog.johtani.info/blog/2011/08/23/%E8%BE%9E%E6%9B%B8%E3%81%AEjar%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%8B%E3%82%89%E3%81%AE%E5%88%86%E9%9B%A2/","publishdate":"2011-08-23T10:26:00+09:00","summary":"ひさびさに、lucene-gosenの話題です。 lucene-gosenはjarファイルに辞書も同梱されており、jarファイルをクラスパスに","tags":["lucene-gosen"],"title":"辞書のjarファイルからの分離(Jugemより移植)"},{"contents":"すみません、また、MBA関連の記事になってしまいました。 ということで、備忘録その２です。\n前回からいくつかインストールや環境の設定をしたので、リストアップ。\nVirtualBoxとWindowsのインストール homebrewのインストール KeyRemap4MacBookのインストール Growlのインストール Time Machine用HDDの購入と設定 VirtualBoxのインストールとWindowsXPのセットアップ。会社関連でどうしてもWindowsが必要なので、 とりあえず、VirtualBoxとWIndowsを入れました。これまでのWindows環境ではVMWareを利用してたのですが、 Macだと有償ということで、無償版が存在するVirtualBoxを選択。 MBAにはDVDのドライブがなく、また、ケチって購入しなかったので、ちょっと手間取りました。 自宅のデスクトップでXPのイメージをisoにして、MBAにコピーしてからインストールと。。。 ただ、MBAのSSDの効果なのか、XPの起動がすごく速くてびっくりです。\nhomebrewのインストールは、まだインストールしただけの状態。。。 MacPortsってのがあるというのは知っていたのですが、最近はこちらがいいとのこと。 ちなみに、MacPortsにはSolrがあるらしいです。デフォルトのため、lucene-gosenとか入れる必要がありますが。\nKeyRemap4MacBookのインストール。入れた方がいいですよと言われてたのだが、きちんと調査してなく、 キーの入れ替えができる程度だと思ってました。昨日、EmacsModeなるものが存在するというのをKeyRemap4MacBookのドキュメントを読んでいて発見し即インストール。 とりあえず、Ctrl-x,Ctrl-cでEvernoteが終了できて喜んでるところです。\nGrowlのインストール。KeyRemap4MacBookのCtrl-xを通知してくれます。ほかにも使い方があるかは調査が必要。\nあとは、昨日、ビックカメラでWDの2TBのHDDを購入してTimeMachineの設定をしてバックアップをとりました。 まだバックアップをとっただけで、差分を見たりはしていないです。帰ってからやってみようかと。\n最後に、ケースを買いました。封筒とかいろいろ考えたのですが、やはり機能重視ということで、以下のケースです。 できれば、ファスナーが２つついていて、両方からあけられるとよかったのですが。リュックとショルダーバッグを使い分けるので、横でも縦でも取り出しが楽なものがよかったので、このケースを買いました。 一応、がんばれば縦でも出せるので。あとは、PCだけもって移動することもあるため、取っ手があるのが便利かと。\nとまぁ、お盆なので、このエントリーで許してください。次回は技術的なことを書きますので。。。 CaseLogic 機能的なモバイルコンピュータケース(13~14.1インチPC対応)、MacBookやMacBook Proにも対応 ダークグレー UNS-114J-DG ","date":1313369460,"dir":"post/2011/","id":"ce0aea06d44878b4a373efe090a66a62","lang":"ja","lastmod":1313369460,"permalink":"https://blog.johtani.info/blog/2011/08/15/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%92/","publishdate":"2011-08-15T09:51:00+09:00","summary":"すみません、また、MBA関連の記事になってしまいました。 ということで、備忘録その２です。 前回からいくつかインストールや環境の設定をしたので、","tags":["備忘録"],"title":"MBAセットアップ備忘録その２(Jugemより移植)"},{"contents":"Mac Book Airのセットアップ関連の備忘録\n（今回は備忘録なので、文体も変かも）\nインストールしたもの（順不同）だいたい、このサイトを参考にした。\nEvernote Dropbox XCode Twitter YoruFukurou GNU Emacs For Mac OS X Java Office for mac 現状はこんなところ。\nまだ、キーボードの配列とショートカット、ウィンドウの切り替えなどがすぐにできないので、かなりおぼつかない状態。\nCtrl+aなどの操作は快適なのだが、ウインドウを閉じたりする場合のcommandキーの扱いがまだなれない。キー配置を切り替えたりした方がいいのか悩み中。 Windowsでは長年XKeymacsを使ってきたため、通常のOfficeなどもCtrl+x　Ctrl+sなどで閉じていたので、command＋qなどがすんなり出てこない。。。\nあとは、VirtualBoxにWindowsを入れて、Eclipseを入れればなんとか、WindowsPCからMBAへの切り替えができそう。\n残っている課題は以下の通り。\nTime Machine環境の整備USB接続のHDDの導入（ミラーリング対応にするか悩み中）※ちなみにうちで使ってるNASは古い＋NFSマウントできない機種だった。。。　対応可能だったらScientific Linux＋Netatalk環境などを用意するのも考えたんだが。 homebrewのインストール 日本語入力（GoogleIME？SKK？） ウォークマン、Xperia arcの運用方法まぁ、今まで使ってたPCで対応かな キーの配置Emacsのショートカットに変更できたりするか調査したい データの移行Windowsに入ってるデータのうち移行するものしないものの選別Macでは利用できないデータやファイルもあると思う。 解凍ツールの選別？いるのかな？ ブラウザのインストールchrome、Firefoxはいれるかな。 メーラーのインストールWindwosではBecky!を使ってたのだが、どうするか。デフォルトメーラで様子見？ ウイルス対策ソフトの導入Macってどんなソフトがあるかがわからない。。。 あと、１週間触っての感想\nまずは、良かった点。\nいろんなUIがよくできてるセットアップなどきれいな画面で説明が進むのが新鮮だった。あと、フォントのきれいさも新鮮。これは、今までのPCが古いからかもしれないが。 トラックパッドがいいまだなれてないけど、スイスイ動くのでストレスなく作業できる。スワイプとかも画面の移動が楽でいい。 静かで速いSSDのため、静かだし起動がすごく速い。会社で支給されてるPCもSSD（３年くらい前のもの）だけど、こんなに起動などがはやくない。 あとは、気になった点。\nAppStoreでページ間のスワイプができない。かなり使いづらい。Safariと同じイメージでいるので。 手首がいたい手前のエッジ部分が手首に当たってちょっといたい。 アプリインストール時にファンがうるさい動画などはまだ見てないが、Office、XCodeのインストール時にファンの排気音がうるさくなり、結構な熱を発していた ファーストインプレッションはこんな感じ。\nただ、前回も書いたようにうらやましかったのもあり、かなり満足している。 もっと触る時間が欲しいのだが、なかなかとれないのが歯がゆい。。。\n持ち歩くようになったらとりあえず、「７つの言語　７つの世界」を読み進め＋写経をやる予定。\n","date":1312904760,"dir":"post/2011/","id":"c0e423f9ac41cc5b265c95a3e97e3fcb","lang":"ja","lastmod":1312904760,"permalink":"https://blog.johtani.info/blog/2011/08/10/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2/","publishdate":"2011-08-10T00:46:00+09:00","summary":"Mac Book Airのセットアップ関連の備忘録 （今回は備忘録なので、文体も変かも） インストールしたもの（順不同）だいたい、このサイトを参考にした。 Evernote Dropbox","tags":["備忘録"],"title":"MBAセットアップ備忘録(Jugemより移植)"},{"contents":"個人用のPCを８年ぶりに新調しました。\n前回購入した家のデスクトップPCがもう８年ものになりつつあるということで、\nさすがに今年はPCを買おうと思い、年初からいろいろと調べていました。\n当初は次もデスクトップPCを購入する予定でした。ただ、次のような状況ということもあり\nデスクトップは見送ることにし、代わりにノートPCにすることに。\n通勤時間が１時間を超えること\n基本、客先に出向いての仕事\n家でPCに触る時間が少ない（家族サービスのため。）\nで、ここ数週間悩んでいたのですが、Mac Book Air 13インチを購入しました。（そのMBAから初投稿です。）\n実は、Apple製品はこれが初の購入となります。\n対抗馬としてあがっていたのはSonyのVAIO Type Zでした。\n元々ソニスト（ソニー大好き）であり、携帯（Xperia arc）、ウォークマン（Sony）、PSP go、ハンディカムなど、\nソニー製品に囲まれており、デザインもType Zのほうが好みなのですが、MBAを購入しました。\nこの理由なのですが、私が大学時代にさかのぼります。\n情報系の大学の出身で、はじめてきちんと触ったマシンがSunOS4.1（最後の数年はSolaris2.6）でした。\nその後、大学６年間は基本的にEmacsでメールをみて、Emacsで文章を書いていました。\nそのため、社会人になってからもEmacsのキーバインドから抜け出せない日々を送っていました。\n社会人ではやはりWindowsでしたが、XKeymacsというフリーソフトのおかげ（せい？）でEmacsの\nショートカットからは抜け出せないまま。（家のPCはXPで、XKeymacsがインストールされてます。）\n今までの流れだと、何も考えずにWindows7+XKeymacsの流れだったのですが。。。\n職場でWindows7のPCを使う機会があり、XKeymacsを入れてみたのですが、これまでとことなり、\nうまく機能しないことこの上なし（例：chromeのアドレスバーでCtrl+Kとかできないなど）。\nさらに、64bit版の場合、XKeymacsを32bit、64bitの２つインストールしないといけないことに。（32bit用アプリのために32bitを入れないといけない）\nで、数ヶ月使っているのですが、ちょっとずつストレスがたまっている始末。。。\n今までは、「Mac？今更恥ずかしくてかえない」「Mac？おしゃれすぎて無理」「Apple？MSにかわって独占してるの気に食わん」と公言していたのですが。。。\nやはりUnixベースであり、Ctrl+aやCtrl+kが意識せずに利用できるということでコーディングなどを行う場合のストレスよりも保守的な思考を変える方が今後のためにも良さそうだということで、心機一転MBAを購入しました。\nということで、ついにApple教へ入信です。\nまだ、１時間も触ってないですが、すでに洗脳されつつあります。。。\n新しいものに触れるのって楽しいですよね。当分は何をインストールするかなど楽しい悩みでいっぱいになれそうです。（次回はちゃんとした技術的な記事書きたいと、書けるかな、書くぞ、たぶん。。。）\nとまぁ、いろいろと理由を書いてみましたが、要は（オシャレさに）憧れてて、あまのじゃくになって思ってもないこと言ってたんです！\n理由が欲しかったんです！！\nMacかっこえーわーw\nMac miniとかiMacとかもほしーわー\n","date":1312389240,"dir":"post/2011/","id":"7ed1d2efa3e0f0ed6b77eb4eff3d86b3","lang":"ja","lastmod":1312389240,"permalink":"https://blog.johtani.info/blog/2011/08/04/apple%E6%95%99%E3%81%AB%E5%85%A5%E4%BF%A1%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-08-04T01:34:00+09:00","summary":"個人用のPCを８年ぶりに新調しました。 前回購入した家のデスクトップPCがもう８年ものになりつつあるということで、 さすがに今年はPCを買おうと","tags":["備忘録"],"title":"Apple教に入信しました(Jugemより移植)"},{"contents":"かなり遅くなりましたが、第1回 データ構造と情報検索と言語処理勉強会 #DSIRNLPに参加しました。\n帰ってから２日半ほど寝込んでしまい、更新が遅れました。。。\n初の土曜日開催の勉強会でしたが、家族を説得してなんとか参加しました。\nおかげで色々と面白そうなキーワードが拾えてよかったです。（拾っただけで理解するのはかなり時間がかかりそうですが。。。）\nということで、前回同様、個人的にメモを取ったので。誤記などあるかもしれませんが、その時はコメントいただければと。\n0.DSIRNLPについて\n※ボランティアで受付してたので聞けず。\n1.TRIEにトライ！～今日からはじめるTRIE入門～\n@echizen_tm さん\n資料：http://www.scribd.com/doc/58688141/Try-for-Trie\n1.TRIEの説明\n実装についてはあとでスライドをみればいいか。（※ボランティアで受付してたので前半聞けず）\n・パトリシア木\n・Double Array\n・LOUDS\n・XBW\n2.作ってみた\nその1　ベーシック\nQ.ノードのラベルどーする？\n・固定長（ラベル＝1文字）\n定数時間でアクセス可能\n・可変長（ラベル＝任意文字列）\nPatricia木に拡張可能\nA.拡張性を考えて可変長に！\n3.LOUDSとは？\n概要\nJacobsonが提案　Level-Order Unary Degree Sequenceの略（いつからLOUDSになったのか不明）\n構築済みTRIEからLOUDSを構築\n作業領域がO(NlogN)からO(N)に\n・ノードに幅優先で順番（Level-Order）をつける\n・子ノードの数を付ける。Unary符号で実装\n作ってみた\n・UnaryよりVerticalCodeのほうがよさそう\nhttp://d.hatena.ne.jp/echizen_tm/20100531/1275323074\n・dag_vectorを使ってもいいかもよ？\n4.QA\nQ.可変長を配列にすればいいんじゃね？\nA.単純にやると効率悪そう？\n※LOUDSをlucene-gosenに適用するとなんか嬉しいことあるかな？\n現状はDouble-Arrayだけど。\n2. ランキング学習ことはじめ（Solr系に利用できそうな予感。。。ごごご。。。むずかしい。。。）\n@sleepy_yoshi さん NTTのSuharaさん「話がうまい」\n数原　良彦\n自己紹介\n情報検索、ランキング学習をやってる。\n三浦半島在住\nねらい\nランキング学習の認知度を高める、ざっくり伝える。　ごめんなさい　「実装」についてをわすれてた。\n・ランキング学習とは？\nLearning to rank\npreference learningとは違う\n教師あり機械学習で検索ランキングに適用\n・歴史\n従来は単一ランキング\nクエリ・文書関連度（TF-IDF、BM25）\n文書の重要度（PageRank、HITS、SALSAなど）\n近代的なランキングの実装方法\n上記データを利用して関数を適用する。\n・何を正解とするのか？\n適合性評価の作成方法\n評価点数を多段階で点数化\nランキング評価方法\nランキングを正解データと比較\nNDCG（Normalized Discounted Cumulative Gain）　※分類問題におけるモデルの生成\nTraining Data＋学習アルゴリズム＝＞モデル\nランキング学習の訓練データ\n素性や評価はクエリごとに変わってくるTraining data（ここが違う）\nここまでのまとめ\n正解データは適合度至上主義！\nランキング学習手法\n３つのアプローチ\n教師あり機械学習（識別学習）≒\nどのような目的関数/損失関数を\nどのように最適化するのか\nアプローチ\n1.Pointwise手法\n単一のデータに対して損失関数を設定\n2.Pairwise手法\n同一クエリのペアに対して損失関数を設定\n3.Listwise手法\n同一クエリのリストに対して損失関数を設定\nPointwise：あまりつかえない。\n例：二値分類（適合＋１不適合－１）で学習\n補足：Perceptron\n例：PRank\nしきい値と重み両方修正する。\nPairwise：Pointwiseよりいいらしい\n文書ペアで損失を設定\nMQ2007、MQ2008データセットの結果\nPairwise手法とListwise手法を比較しても\nそんなに悪くないらしい\nIR-SVMってので偏りなどを排除できて、精度向上になるよ\nNLP2011でPARankっての発表したよ（手前味噌）\nQA\nQ.じゃんけんみたいに循環しない？（nokuno）\nA.半順序のデータだと起きるが、検索の場合は全順序なので大丈夫だよ\nListwise：Pairwiseよりいいらしい\nListNetってのあり。\nAdaRank\n検索評価指標を直接最適化するブースティング手法\n性能はいまいち？実装は簡単\nその他の話題\nClick-through logs\nQuery-dependent ranking\nFeature selection\nTransfer learning/Domain adaptation\nDiversity/Novelty\n公開Dataset\nLETOR3.0/4.0 Dataset\nMSLR-WEB Datasetなど\n実装\nRankingSVM\nStoch\u0026hellip;.\nLearning to Rank教科書\n英語の資料が今年複数出たみたい\nまとめ\n近代的な検索エンジンは多数のランキング素性を利用\n評価データを用いてランキング素性の最適な重み付けを求める方法\n。。。\n機械学習手法は論文≒実装\nなので、ソースコード見るほうが重要（論文にないノウハウがあるよ）\n3.snappy調べてみた\n@machy　町永圭吾（赤いポータルサイト）\nTopCoderなどで活躍中？\n・snappyは圧縮/伸張ライブラリ\nzlibよりサイズが大きいけど一桁はやいですぞ。\n・インストールなど\ngoogle－gflagsってのがないと動作しないよ。\n・比較してみた（zlib）\n一桁は言い過ぎだけど、はやかった。\n・比較してみた（lzo）\nHadoopで利用されているlzo\nはやかった。\n・仕組みは？\nzlib　辞書式符号化＋ハフマン符号化＝出力\nsnappy　辞書式符号化＋リテラル＝出力\n・辞書式符号化は？\n前に出てきたデータで同じ文字列の部分について端折る\n・ハフマン符号化\nよく出てくる記号を短い符号で置き換えることで圧縮する。\n・snappyの符号化\n基本バイト単位での処理にすることで、高速化してるみたい。\n・snappyの辞書参照元の探し方\nハッシュテーブル利用してマッチする位置を検索\n4byte窓でハッシュ値を計算してハッシュテーブルを更新\n・圧縮しにくいデータ（同じ単語が出てこないパターン）について\n圧縮をあきらめ始める（32回同じのが見つからないと窓の移動幅が1つずつ大きくなる）\n16KB（フラグメント内）での比較回数が1008回に抑えられる。\n・特徴\nハッシュがしょうと移したらあるはずのマッチが見つからないこともある。\nメモリ消費量を抑えるためのハッシュのサイズ？\n最悪ケースのサイズを予め確保してから処理するため、メモリの再確保が起きないのではやいぞ。\n4.類似文字列検索してますか？\n@overlast さん　Yな会社\n1.曖昧な情報を処理する能力\n曖昧な情報を解決しようとする能力が高い。\n例：お笑い芸人の芸がサンプルｗ\n画像検索は曖昧クエリに答える例。。。\nスターバックス、スタバ、SUTABA\nスータバでも画像が出てきた。-\u0026gt;女子高生とかが「スータバ」で画像をアップしてたりするから。\n文字列を使った検索は現代のインフラになってるよね。\n例：iタウンページ\nタイトルとかに「スターバックスコーヒー」って書いてないとだめ。？\n「スタバ」800件くらい　-\u0026gt;　正規化で「ー」消してるんじゃないの？\n「スータバックスコーヒー」0件　ちがうな。シノニム辞書登録してるな。\n曖昧なクエリ（キーワード）から検索できないかなぁ？\n曖昧情報の処理は文字列処理にこそ必要\nなんでヒットしたかがわかるのが正解　なんでヒットしたかわからないけど、ちゃんと出てきたから正解！\n2.ゼロ件ヒット問題（ゼロマッチ）\nピクシブ百科事典\n「ピングドラム」だと17件\n「ピンクドラム」だと0件　しかも真っ白！！\n使いにくいよね。けど、一般的な検索システムの問題だよね。\nGoogleだと出てくる「ピンクドラム」の結果の最初にはピングドラムが出てくる。\n-\u0026gt;リンクがはられているから出てきた？みんなの間違いで助けられてる\n食べログ\n「俺のハンバーグ」\n「俺はハンバーグ」で検索したら。。。「俺はハンバーグで連れは。。。」がヒット-\u0026gt;しらねーよｗ\nまとめ\nゼロ件ヒットは機会損失！！\n3.曖昧な文字列で正しい文字列を探す方法\n正しい文字列って？\n1.表記誤りがない\n2.心の底で求めている\n※異表記同義、同表記異義、異言語表記（日本語の情報を英語で検索）などもある\n正しさはユーザによって変わる。\n正しい文字列をさがす手法\nクエリ表記の正誤という軸\n誤の場合表記をヒントに似た文字列を検索してみる。\n探したい対象が正確か曖昧か\n表記意外がヒントで同じ対象に到達できる？\nどんな情報を手がかりにする？\n編集距離（レーベンシュタイン）\n検索ログ\n4.Apporoの紹介\nチョコ？いや、ロケット？いや、Approximate \u0026hellip;\nhttp://code.google.com/p/apporo/\n中小規模だと使えそう\nSimString\n今後\nよみかな、ローマ字表記に基づく類似文字列検索＋高速化の予定\n技術概要\nSuffix Array\nN-gram Searchベースの近似文字列照合\nBit Parallel Matchingによる編集距離計算\n5.検索と言語と文化（仮）\n@mizuno_takaaki さん\n放送禁止のためメモなし。\n7.自然言語処理におけるargmax操作\n@hitoshi_ni さん\n※順番変更\n・近似解法\nその１　全探索\nいや、無理でしょ、計算が。\nその２　貪欲法\n最適解が出るかは不明。\nその３　ビームサーチ\n上位kこの仮説を保持しながら幅優先探索\n・動的計画法\nすでに最大値がわかっていて、ゴールから眺めてみる。\n逆からたどるとルートがわかるんじゃないか。\nマルコフ性につけ込むことで、わかるんじゃないか。\n計算量：品詞数の2乗\n（品詞数の2乗）＊形態素数\nDPの実装\nViterbiかなぁ？\n・整数計画法（線形-\u0026gt;整数）\n自然言語処理としては整数計画法でだいたいOK。\nアルゴリズム\n・手元の解空間中から許容解を得る\n・分枝してそこから最大値を求める\n最大値＞許容解ならそちらを探索。\nプログラム実装する？\nすごく大変じゃないけど簡単でもないね。\n問題の弱点がわかってるなら実装してもいいよね。\n整数計画法の場合lp_solveなどのフリーのソフトで解くのがいいよ。エクセルでも解けるよ\nILP（整数計画法？）\n問題の切り分けに使える。\nまとめ\nILPで解けたら、いろいろ自分で考えると面白いよ。\nその他のバズワード\n参考資料\n組み合わせ最適化＝1万円超\nアリ本\n6.ソーシャルグラフ分析(導入編)\n@kimuras さん　mixiの木村さん\n・グラフ探索部分はまた今度。\n・テキストマイニングや検索エンジンまわりやってる。\n・ノードが数1千万、エッジが数億のオーダー\n・分散技術の発展によるアルゴリズムの多様化\nこれまで\nRDBからDumpしたデータをKVSに入れて頑張ってた。\nDump部分でデータ構造を毎回構築\n問題点\n変更による再実装、メンテナンスコスト、\nこれから\ngraphDBに取組中。マイニングに最適な感じ\ngraphDBの実装\nOrientDB、Neo4jとか\nNeo4jって\nACIDトランザクション可能\nEmbeddedGraphDatabaseだとAGPLｖ３だから気をつけてね。\nluceneで全文検索インデックスつくってるみたい。\nGremlinってのがquery言語を汎化してるらし。\nとあるSNSのデータを使ってみたよ。\nメモリ64G、CPUは1コアしか使えなかったよ。\nノード：15million、枝：600million\nまとめ\nということで、色々と面白い話が聞けました。特にTRIEの話はかなり興味を持ちました。\n検索周りで嫌というほど出てくるので。まだまだきちんと理解できてないので復習しないと。。。\nlucene-gosenにも関係あるので、しっかり資料をみて復習する予定です。\n基本的に検索系の話に関連があることが多くて面白く聞くことができました。\n「類似文字列検索してますか？」や「ランキング学習ことはじめ」などは身近な話（だけど、なかなかきちんと学習できてない話）でした。\nまた、「自然言語処理におけるargmax操作」では大学でやっていた線形計画法などのわかりやすい説明で10年経ってようやく理解ができた次第です。。。（もっとちゃんと勉強しとけば。。。）\n懇親会にも参加し、研究に近い分野の方が多い中でいろいろな話が聞けたのはよかったと思います。\n次回もいろいろなキーワードを拾いたいのでぜひ参加したいです。\n","date":1311737580,"dir":"post/2011/","id":"3811b40721f7ca651887aac4eb17f9f0","lang":"ja","lastmod":1311737580,"permalink":"https://blog.johtani.info/blog/2011/07/27/%E7%AC%AC1%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-07-27T12:33:00+09:00","summary":"かなり遅くなりましたが、第1回 データ構造と情報検索と言語処理勉強会 #DSIRNLPに参加しました。 帰ってから２日半ほど寝込んでしまい、更新が","tags":["勉強会"],"title":"第1回 データ構造と情報検索と言語処理勉強会に参加しました。(Jugemより移植)"},{"contents":"以前から春山さんのブログ（リンク）や勉強会で耳にはしていたのですがソースは読んでいませんでした。 先日、Luceneにcontributeされた（リンク）ので軽くソースを読んでみました。\n公式サイトはこちら\nまずはMeCabのページにある比較表（リンク）を基準に特徴を調べてみました。せっかくなので、lucene-gosenも隣に。\n\u0026nbsp; Kuromoji lucene-gosen 解析モデル なし（学習機能なし） なし（学習機能なし） コスト推定 なし（学習機能なし） なし（学習機能なし） 学習モデル なし（学習機能なし） なし（学習機能なし） 辞書引きアルゴリズム Double Array Trie Double Array Trie 解探索アルゴリズム Viterbi Viterbi 連接表の実装 2次元 Table 3次元 Table 品詞の階層 無制限多階層品詞？ipadic、unidic形式に対応 無制限多階層品詞 未知語処理 字種 (動作定義を変更可能)（おそらく。） 字種（変更不可能） 制約つき解析 たぶん、不可？ たぶん、不可？ N-best解 不可能 不可能 こうやって比較してみるとlucene-gosen（Sen）とあまりかわりはありませんが、lucene-gosenが少し古いのがわかりますね。。。\nKuromojiで利用出来る辞書は現時点ではMeCab IPADIC、UNIDICの2種類のようです。\nソースを読んでの感想ですが、やはりMeCabが偉大だということがよくわかりました。 Senよりも新しいMeCabの処理に似ている点が多いです。解探索アルゴリズムや連接コスト表が特に。 MeCab向けの辞書を利用しているためというのもあるかと思います。\nKuromojiが特徴的なのは「searchモード」と呼ばれるモードが用意されていることです。 公式サイトにある例ですと、「関西国際空港」が「関西」「国際」「空港」というTokenで出力されます。 ソースを見たところViterbiアルゴリズムで辞書を探索しているときに特定の条件でコストをカサ増しすることで、結果を変えるという処理を行っているようです。\n全て漢字の単語：3文字以上の場合に「(単語の長さ-3)*10000」をコストに加算 その他の単語：7文字以上の場合に「(単語の長さ-7)*10000」をコストに加算 このようにコストを変化させることで「空港」でも「関西国際空港」という文字を含む文章が検索できる仕組みになっています。 また、「拡張searchモード」と呼ばれるモードも存在し、こちらは、未知語をuni-gramで区切って出力を行うようです。\nソース上で確認しただけで、未確認ですが、GraphvizFormatterというクラスがあるので、Graphvizで読み込める形式で形態素解析の結果が出力されるかもしれません。（すみません、確認してなくて。）\n未知語の処理やsearchモードなど面白い機能があるので、試してみるのもいいかもしれません。lucene-gosenを考えていく上でも参考になりそうです。\n最後に余談ですが、FAQのページ（リンク）が面白いです。。。\n","date":1311132540,"dir":"post/2011/","id":"5a765f9668608a39333fa90cf462657e","lang":"ja","lastmod":1311132540,"permalink":"https://blog.johtani.info/blog/2011/07/20/kuromoji%E3%82%92%E8%AA%BF%E3%81%B9%E3%81%A6%E3%81%BF%E3%81%9F/","publishdate":"2011-07-20T12:29:00+09:00","summary":"以前から春山さんのブログ（リンク）や勉強会で耳にはしていたのですがソースは読んでいませんでした。 先日、Luceneにcontributeされ","tags":["形態素解析"],"title":"Kuromojiを調べてみた(Jugemより移植)"},{"contents":"忘れてしまうので、備忘録を残しておきます。 一応、ソースには少しずつコメントをいれてはいるのですが。 私は残念ながら、自然言語処理は初心者に毛が生えた程度（現在、鋭意勉強中）で、対応方法に問題があるかもしれません。気づいた方はコメントをいただけると助かります。\n辞書ファイルについて NAIST-JDic for MeCabの辞書ファイルは以下の構成になっています。\nファイル名 メモ char.def 文字種の設定 feature.def 辞書学習用の設定？ left-id.def左文脈IDのマスタ（左文脈ID、品詞情報） matrix.def 連接コスト表（前件文脈ID,後件文脈ID,連接コスト） pos-id.def 品詞IDのマスタ（品詞情報、ID） rewrite.def rewrite情報（左右文脈に出現した場合のそれぞれの品詞情報のrewriteルール。辞書学習で主に利用） right-id.def 右文脈IDのマスタ（右文脈ID、品詞情報） unk.def 未知語の品詞情報（文字種ごとに未知語のコスト、左右文脈ID、品詞情報が記載されている） naist-jdic.csv 単語辞書（単語、左右文脈ID、単語コスト、品詞情報、読みなど記載） 現時点では、MeCabDicPreprocessorでは以下のファイルを利用しています。\nleft-id.def matrix.def right-id.def naist-jdic.csv 上記以外のファイルは現時点では利用しない実装になっています。 ただし、rewrite.def、unk.def、char.defについては利用したほうがよりMeCabに近い結果が得られるような気がしています。（特に文字種ごとのコストを利用することは有効と思われます。）\nPreprocessorでの処理について lucene-gosenはSenの後継であり、MeCabの昔のバージョンを移植したものがベースとなっています。 lucene-gosenとMeCabの現時点での実装の大きな違いとして、連接コスト表の違いがあります。 ここからは憶測になってしまいますので、注意してください。（論文を探せばどこかにこの実装の変化の過程が記載してあるかもしれないですが、まだ探していません、すみません。） 過去のMeCabではChaSen向けの辞書を利用していました。 ChaSenでは連接コスト表が3つの項（前の前、前、後）から構成されていました。（n項まで定義可能らしい） ですので、lucene-gosenのViterbiアルゴリズムの引数も3つのノードが引数となっています。 lucene-gosen向けの連接コスト辞書も同様の作りになっています。 一方、現在のMeCabは先ほど書いたとおり、matrix.defでは2項の連接コスト表（前、後）となっています。この違いを保管するために、Preprocessorでは、matrix.defを3項にするために一番左（前の前）については任意の品詞を採用できるように「,,,,,,*」のみを設定しています。\n現時点では、Preprocessorの出力である中間ファイルを共通の形式に出力することで、DictinaryBuilder以降の処理に変更を加えることなくNAIST-JDic for MeCabへの対応を行う形を取りました。まずは使えるようにするのが先かと思いまして。 ただ、MeCabの辞書の構成から考えると中間ファイルに落とし込む処理に無駄があると感じています。 matrix.defでせっかく、IDによる連接コスト表を構成しているのに、IDを品詞情報の文字列に戻したconnection.csvを生成していますので。\nということで、備忘録でした。 あとは、テストをどうするか（正解をどう考えるか）なども考える必要があります。現時点での悩みの種です。。。アイデア募集中です。\n","date":1310432760,"dir":"post/2011/","id":"c70b78fd0b5dffcd38322355e9c2471e","lang":"ja","lastmod":1310432760,"permalink":"https://blog.johtani.info/blog/2011/07/12/naist-jdic-for-mecab%E3%81%AEpreprocessor%E3%81%AE%E5%AE%9F%E8%A3%85%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E5%82%99%E5%BF%98%E9%8C%B2/","publishdate":"2011-07-12T10:06:00+09:00","summary":"忘れてしまうので、備忘録を残しておきます。 一応、ソースには少しずつコメントをいれてはいるのですが。 私は残念ながら、自然言語処理は初心者に毛が","tags":["lucene-gosen"],"title":"NAIST-JDic for MeCabのPreprocessorの実装に関する備忘録(Jugemより移植)"},{"contents":"lucene-gosen 1.1.1をリリースしました。\n先日お知らせしたバグ修正を取り込んだjarを用意いしました。\nダウンロードはこちらから\n","date":1309777240,"dir":"post/2011/","id":"229975f1e84b5088e819cd5f2dc43080","lang":"ja","lastmod":1309777240,"permalink":"https://blog.johtani.info/blog/2011/07/04/lucene-gosen-1-1-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2011-07-04T20:00:40+09:00","summary":"lucene-gosen 1.1.1をリリースしました。 先日お知らせしたバグ修正を取り込んだjarを用意いしました。 ダウンロードはこちらから","tags":["lucene-gosen"],"title":"lucene-gosen 1.1.1リリース(Jugemより移植)"},{"contents":"Solr/Lucene 3.3がリリースされました。（速報）\n以下、各サイトへのリンクです。\nSolrリリースのお知らせ\nLuceneリリースのお知らせ\nリリースのタイミングがどんどん早くなってる。。。\n","date":1309501779,"dir":"post/2011/","id":"10eb1e7dc64d8ca3dad92641dadb5de7","lang":"ja","lastmod":1309501779,"permalink":"https://blog.johtani.info/blog/2011/07/01/lucene-solr-3-3%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/","publishdate":"2011-07-01T15:29:39+09:00","summary":"Solr/Lucene 3.3がリリースされました。（速報） 以下、各サイトへのリンクです。 Solrリリースのお知らせ Luceneリリースのお知らせ リリースのタイミ","tags":["solr"],"title":"Lucene/Solr 3.3リリース（速報）(Jugemより移植)"},{"contents":"「Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）」に参加しました。300名入るイベントルームでしたが、後ろの方まで人が埋まっていました。\nということで、主に自分用ですが、メモを取ったので。\n※二次会行きたかった。。。\n1.「鉄道システムへの誘い」\n@ayasehiro（本名無理w）\nHadoopの話はありません。\n○鉄道系基幹システムの開発\n実態：\n耐用年数：１０年以上\n開発期間：数年～５年程度\n開発規模：～10Mステップ、10k人月～\nほとんどテスト、しかも異常系が主体。\n夜間に実際に鉄道を走らせて試験したり。\n開発サイクルが長い\n人材育成が難しい、ノウハウがたまらない。\n開発自体はほとんど時間がなく、設計・製造・試験など新規技術の採用が難しい。\n開発４年前の調査・検証自体が２年程度。\nHadoopも調査中。\n○鉄道システム３大システム\nマルス（予約オンラインシステム）（1960～）\nコムトラック（運行管理システム）（1972～）\nヤックス（ヤード自動化システム）（1968～1984）\n○鉄道輸送システムとは\n用語：\n運行を計画する=\u0026gt;輸送計画\n列車を運行する=\u0026gt;運行管理\n需要想定＋営業施策＋その他（お召し列車など）＝列車ダイヤ作成\n基本計画（長期）＋短期計画（数日～四半期程度）＝列車ダイヤ（重ねあわせてできあがり）\nダイヤの計画（発車時刻など）と車両運用（車両自体の走る組み合わせ（仮の車両））の作成\n＋乗務員運用（乗務員の運用計画）\n運行管理：\nなにも起きなければすることなし。（車両故障、天候、人身事故などによる整合性を取る作業）\n＝事前に計画した輸送計画をすべて見直し\n遅延の検知は？\n昔：人による伝令\n今：システムによる検知（レールに電流流して検知）\n運転整理（実際に遅れた）：\n部分運休、折り返し駅の変更などにより対応\n元の計画になるべく近づく形で修正していく。\n新幹線、山手線、京浜東北線などは速度信号という信号が表示される。\n線路上に信号はないらしい。\n○鉄道システムを取り巻く情勢\n少子高齢化・人口減少のため凋落産業となっている。\n社会インフラの責務＝動くのが当たり前\n2007年問題（ベテランの引退）＝スジ屋さんは最近いないらしい。\n高度な判断支援をするシステムが必要\n連続稼動＝分散技術を適用できない？\n関係各所との情報共有\n計画立案のための情報支援＝最適化技術を適用できない？\n○分散処理技術の適用\n個人的な感想\n可用性（連続稼動）のための仕組み\nバッチ処理\n○分散技術の適用\n・連続稼動\nactive-active構成がメイン\n主系の出力だけを行う。問題が出れば副系の出力。\n3系統の出力を比較器にて出力もある\nmagiシステム\n問題点：\nハードが高い（H社）\nソフトウェアの作り込みが複雑＝テストが前パターンできない\n解決案：\n汎用的なハードが使いたい。\n作り込みも減らしたい\n・バッチ処理：\nAsakusa使えないかなーw\n○最適化技術の採用\nコンピュータ技術の発展\n2007年問題\n職人に言わせれば最適化はいらない、俺の言うことを聞けｗ\n・車両運用のモデリング\n車両数大=\u0026gt;組み合わせ大\n制約条件が多い\n車両運用の場合、走行累積キロの条件もある\n-\u0026gt;有向グラフにモデル化される。（ただし、グラフ化するまでが大変）\n・乗務員運用のモデリング\n車両と違い、乗務員は1回で2人とか運べる（運転士＋移動する人とか）\n・車両割当のモデリング\nやはり、グラフ化が可能\n・乗務員交番のモデリング。。。など\n結構一般的なモデルに落とし込める。ただし、落し込みが大変。\n机上研究だったものが、コンピュータの発展により実証研究になりつつある。\n○まとめ\n鉄道システムはまだまだ未到の領域が残っている。\n開発サイクルが長いため、保守的な開発になる（35年前の設計思想からあまり変わってなかったりする）\nしかし業務要件やシステム利用者の意識は変化している\n興味を持たれた方は、ぜひ、我社に！（社名は2次会でｗ）\n○Q\u0026amp;A\nQ：鉄道システムのカルチャーってイケイケ？保守的？（@okachimachiorgさん）\nA：最新技術も知らないとだめじゃないかという人が出てきている。\nコア部分（安全第一なところ）＋周辺領域（ある程度融通が効きそうな部分）と考えることができるんじゃないかって人も出てきている。\nJR九○＝先進的\nJR四○、北○道＝お金ない\nJR○海＝超保守（企業的に超保守）\nJR東、西＝うーむ？\n東京メト○（運行計画）、阪○＝先進的\n京○急行＝基本人間で進路制御w\n基本的には新しいものには興味をもつ人たちでは。\nQ：Su○caとかで分散処理は利用出来るんでは？\nA：匿名なので外側から見ていると分散処理はいろいろ使えるんでは？\nログデータからいろいろできるんじゃないの？活かすべきでないの？\n使いどころはいっぱいある。\nQ：鉄道システムでどうしようもなくなったことはあるか？\nA：保守体制が一番気になる。\nOSSとかならまだ調べられる。ミドルウェアなどの保守契約が必要。\n保守体制が確立されてればある程度の保守費用は飲み込む。\nどうしようもないことはないが、今すごく困ってることは\nExcelで帳票を出したいとかいわれること。（ちょっと前に作ったシステムでExcel2003。バージョンあげると速度が遅くなったりするｗ）\nilog社のものを使ってたが、IBMに買収されて保守費用があがってこまってるｗ\n保守が10年と長いため、サポートなどの折衝が必要。\nQ：最適化の適用範囲は？\nA：走行順序（どこで追い抜くか）の算出に活用。ほぼ完成でユーザ教育中。\n1列車の波及がかなり影響が出る。ダイヤだけ見ると列車だけだが、乗務員も関係しており、大変。\nある時点から終電までを最適化の対象としたりして割り切っている。\nまた、不足分について算出が出来れば、そこで打ち切ったりもする。\n2.「九州電力におけるHadoopの取り組みについて」\n株式会社キューデンインフォコム e－ビジネス部　@hisashi_yano\n概要：2年間関係したOSSをメインにしたシステムの話。\n○九州電力の概要\n現在風当たりが強い業界。\n東電の1/10くらい\n部門ごとに大手ベンダーが関わってる。\n○Hadoop採用の経緯\n部門ごとに個別最適なシステムを導入していてベンダーロックインされてる。\n・ホストのリプレース\n・両現用センター構成への対応\n・スマートグリッドへの対応\n問題点\n・コスト削減\n・技術革新への中の人の対応（内部でも問題を理解できるように）\n・商用パッケージのカスタマイズの限界\n・脱ベンダーロックイン（実は楽なんだけど。。。）\n○過去2年間の研究内容\n・H21年度の結果\nテーマ：クラウドの要素技術の研究\nKVM、Eucalyptus、wakame、hadoop　性能比較：VMWareとKVM-\u0026gt;ベンチマーク比較\n結論：性能的にあまり問題なし。\nMapReduceの耐障害性など\nダミーデータにより台数増加による影響を検証\n結論：台数大-\u0026gt;性能向上\nストリーミングは性能劣化する\nスループットはリニアに向上\n信頼性は？\n実行中にノードを抜いたりして検証。\n結論：問題なし。\nクラウド環境におけるシステム管理手法\n複数ハードで1アプリという構成になる。\n監視対象が膨大になる。\n障害発生時の切り離しや監視対象も膨大。\nデータセンター自体を監視する仕組みが必要では？というところで終了。\n・H22年度の結果\n分散に特化した研究\n前年度の課題\nサーバの仮想化・管理に関する課題\n分散処理に関する課題\n分散処理環境の運用監視に関する課題\n目的：\nHadoopを本番への適用（実際にはダミーデータ＋本番の仕組み）\n柔軟なサーバ統合基盤（サーバを起動-\u0026gt;バッチを起動-\u0026gt;回す仕組み）＝MonkeyMagic\nlibvirtを使ってる\n50台の仮想サーバの起動が10数分で完了。\n運用監視基盤（monkey magic）\n仮想、実サーバ混在の監視\n監視状況（サーバの状況）から判断して制御する仕組みを構築\nDSLにてルール（判断＋制御）を指定\n・ジョブの監視\n・ジョブの実行管理\n・構成管理の省力化\nvolanteと連携が可能＝AmazonWebServiceとも連携可能\n・サーバリソース＋アプリケーションの一括監視が可能\n分散バッチ処理の概要\nRDBからKV形式にして抽出し、MRで回してRDBに戻すという研究\n対象：\n配電部門（電柱の設備情報の目視検査）のデータの月間バッチ処理\n現状：\n19時間程度かかってる。\nテスト環境：\n実サーバ2台（仮想10台）\nMySQL、Javaで実装\n処理内容\n電柱104万本\n巨大バッチを分割して実装\n結果\nMySQL1台では15日以上かかる処理（現行システムで19時間）\n処理が32分で終了！他でも効果でるよね。\nバッチ短縮の理由は？\n1.データアクセスが分散された\n2.処理の並列化（多重化出来る部分がうまくできた）\n分散処理を書くのに2名死亡。。。\n適用基準の策定、開発ガイドライン、フレームワーク整備などが必要。\n・H23年度は？\nAsakusaの適用など。\n・さらに今後は？\nスマートグリッドへの適用\n-\u0026gt;メーターの交換が必要だが、10年くらいかかる\n-\u0026gt;スパンが長い（10年）ので商用製品だときつい？\nデータ量も半端ない。\nテネシー州とClouderaでOpenPDCってのやってるらしい。\n電力と気温の関係は密接な関係あり。\nエアコンが割合を占めてるから。\n過去実績と予想気温データから分析するのにHadoop使える！\n・2年間やってきて思うこと\n将来目指すべき理想像を掲げるのが重要\n新技術導入は段階を踏むことが必要\nコミュニケーション大切！\n○Q\u0026amp;A\nQ：仮想化環境のオーバヘッドは？（I/O）\nA：台数を増やしたときにどうなるか？というのを検証したかった。\nアプリ配布も考えていたので、物理サーバに縛られたくなかった。\nQ：仮想化に関して気をつけたM/RのPGで気をつけたことありますか？\nA：まったくないです。\nQ：日本でスマートグリッドははやるの？\nA：電力会社的にはやりたくない。費用対効果があまりない。\nQ：今後のスケジュールは？\nA：文書管理システムの組織名変更などの処理時間が540時間とかでてくるらしい。\nこれをHadoopで対応してみようかと思ってる。\nQ：Asakusaをどう評価していくのか？\nA：開発効率性があがるか？は検証する予定。1/3くらい楽になるんじゃないかなぁ？byのぐちさん\nバッチの種類などにもよると思うが、標準化も指標にする予定。\n結果はまたこの場で報告する予定。\nQ：Asakusa＋MonkeyMagicの連携はどんなこと考えてる？\nA：MonkeyMagicを運用基盤として行く予定。合意が取れればだけど。\n※MonkeyMagicもOSSにするよー\nまとめ\nHadoopから少しずつ離れつつありますが、やはり興味があるので、非常に楽しく話を聞けました。\nまた、今回はインフラ分野のシステムということで、システムに要求されるレベルや\n運用周りにも気を配っている話が聞けたのが収穫でした。保守期間が長いため、テストが長い＝\n運用もしっかりと考慮を入れた設計、実装が必要になるというのは最もだと思います。\nただ、少しずつ修正が入るアジャイルなども同様かと。\nMonkeyMagicが出来上がってきた背景の話を聞いて、さらに興味が湧いてきたところです。\n今後もかかわりが少ないかもしれないですが、ウォッチしていきたいと思いました。\nただ、興味あるモノが多すぎるので、優先度をつけつつこなして行かないと。。。\n少しずつでも身につけていきたいと思う今日このごろです。\n※追記：Twitterでコメントを頂いたので、忘れないように追記。\nコメントを貰えるだけでもうれしい。やはり、アウトプットしたらフィードバック貰いたいし。\nありがとうございます！\nTwitter / @cocoatomo: あの質問をまとめるとこうなるのかぁ…… 最適化そのも \u0026hellip;\nTwitter / @cocoatomo: @johtani すみません, コメントはコメント欄 \u0026hellip;\nTwitter / @cocoatomo: @johtani そこらへんの理論って最後には計算量 \u0026hellip;\nTwitter / @cocoatomo: @johtani あの話し振りだとどうもまだ本格的に \u0026hellip;\nあと、まとめも出来ていたので、ついでに。\nTogetter - 「2011/06/29_Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回） #hadoopmodeling」\n関連するブログも見つけたので。\n第5回Hadoop座談会の感想 - ひしだまの変更履歴\nHadoopモデリング座談会（第5回）へ行ってきました - 虎塚\n","date":1309356600,"dir":"post/2011/","id":"49ba23148db9effdc3979aa0fe5876ea","lang":"ja","lastmod":1309356600,"permalink":"https://blog.johtani.info/blog/2011/06/29/hadoop%E3%82%92%E4%B8%AD%E5%BF%83%E3%81%A8%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E7%92%B0%E5%A2%83%E3%81%A7%E3%81%AE%E9%96%8B%E7%99%BA%E6%96%B9%E6%B3%95%E8%AB%96%E3%83%A2%E3%83%87%E3%83%AA%E3%83%B3%E3%82%B0%E8%A8%AD%E8%A8%88%E6%89%8B%E6%B3%95%E7%AD%89%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E5%BA%A7%E8%AB%87%E4%BC%9A-%E7%AC%AC5%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-06-29T23:10:00+09:00","summary":"「Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）」に参加しました。300名入るイベントルー","tags":["hadoop"],"title":"Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）に参加しました。(Jugemより移植)"},{"contents":"以前、こちらで話題に上がっていた「未知語」に関するcompositePOSのエラーの件を調査しました。（Twitterでも流れてました。） 次のような条件の場合にエラーが発生するようです。\ncompositePOSの設定に構成品詞として「未知語」が指定されたエントリが存在する。 未知語が連続して出現する文字列をanalyzeする。（例：ニンテンドーDSi） ということで、trunkに修正版をコミットしました。 Issueはこちら。\n※お茶をにごす感じの日記になってしまいました。次回はマシな記事を書く予定です。。。\n6/29追記：恥ずかしいバグをいれこんでしましました。。。 ということで、trunkに再度修正版をコミットしました。\n","date":1309232160,"dir":"post/2011/","id":"f6dff70097776e24c2a7c9c0f2514f79","lang":"ja","lastmod":1309232160,"permalink":"https://blog.johtani.info/blog/2011/06/28/compositeposcompositetokenfilter%E3%81%AE%E3%83%90%E3%82%B0%E4%BF%AE%E6%AD%A3/","publishdate":"2011-06-28T12:36:00+09:00","summary":"以前、こちらで話題に上がっていた「未知語」に関するcompositePOSのエラーの件を調査しました。（Twitterでも流れてました。） 次","tags":["lucene-gosen"],"title":"compositePOS（CompositeTokenFilter）のバグ修正(Jugemより移植)"},{"contents":"lucene-gosenのtrunkbranches/impl-mecab-dicにNAIST-JDic for MeCabの辞書を利用出来るPreprocessorをコミットしました。\nビルド方法は次のとおりです。\n$ cd lucene-gosen-trunk $ ant -Ddictype=naist-mecab 現在のstable版で利用できる辞書は「ipadic」「naist-chasen」の2種類でした。\n[以前の記事](http://johtani.jugem.jp/?eid=4)に書きましたが、naist-chasenの辞書でも2008年の更新となっています。\n今回コミットしたPreprocessorでは[NAIST-JDicのサイト](http://sourceforge.jp/projects/naist-jdic/)で公開されているMeCab向けの辞書である「mecab-naist-jdic-0.6.3-20100801」を利用出来るようになります。\nただし、lucene-gosenは昔のMeCabから派生したSenをもとにしていますので、最新のMeCabが持っている機能は\n利用できません。\nMeCab向けの辞書のうち一部のもの（matrix.def、naist-jdic.csvなど）を利用してlucene-gosen向けの辞書の中間ファイルを生成する仕組みになっています。\nまだ、仮実装版ということで、とりあえず動作するバージョンとなっています。\nまだテストが不十分ですが。。。\n利用してみて問題などあれば、lucene-gosenの[issue](http://code.google.com/p/lucene-gosen/issues/list)に登録していただくか、コメントを頂ければと思います。\n※更新が週1回に落ちてきてるので、もう少し頑張らねば。\n※2011/07/04追記 trunkにコミットしていましたが、branchに一旦移動しました。 仮実装として一旦コミットしたので、trunkとは別でテストする必要があるかと思った次第です。 ということで、試してみたい方は、[branches/impl-mecab-dic](http://code.google.com/p/lucene-gosen/source/browse/#svn%2Fbranches%2Fimpl-mecab-dic)にありますので、触ってみてください。 ","date":1308609480,"dir":"post/2011/","id":"991285e3967c3295b4ff2dcd835f7c61","lang":"ja","lastmod":1308609480,"permalink":"https://blog.johtani.info/blog/2011/06/21/naist-jdic-for-mecab%E5%AF%BE%E5%BF%9C%E7%89%88%E4%BB%AE%E5%AE%9F%E8%A3%85/","publishdate":"2011-06-21T07:38:00+09:00","summary":"lucene-gosenのtrunkbranches/impl-mecab-dicにNAIST-JDic for MeCabの辞書を利用出来るPre","tags":["lucene-gosen"],"title":"NAIST-JDic for MeCab対応版（仮実装）(Jugemより移植)"},{"contents":"前回、naist-chasenではアルファベットが別々の単語としてanalyzeされてしまうという話をしました。\nただ、これだと、英単語が含まれた文章を形態素解析すると、英単語がアルファベット単位に区切られてしまい、 単語の意味をなさなくなってしまいます。\nlucene-gosenでは、この問題に対応するための方法が提供されています。 CompositeTokenFilter（compositePOS）という機能です。\n文字通り「トークン」を「合成」するための機能になります。\n利用するためには以下の作業が必要です。（※Solrでのの利用方法を説明します。）\ncompositePOS設定ファイル（composite_pos_ja_naist-chasen.txt）の用意 schema.xmlのtokenizerにcompositePOS設定を追加 まずは、compositePOS設定ファイルの記述方法について説明します。 compositePOS設定ファイルには１行につき１つのcompositeの設定を記述していきます。 記述方法は次のようになります。品詞名を半角スペース区切りで記述します。\n連結品詞名 構成品詞名1 構成品詞名2 ... 構成品詞名n それぞれは次のような意味を持ちます。\n連結品詞名：合成したあとのトークンの品詞として出力する品詞名 構成品詞名：合成したい品詞名（スペース区切りで複数指定可能） TokenizerのcompositePOS機能は、構成品詞に定義されたトークンが連続して出力された場合に、 結合（合成）して１つのトークン（連結品詞名）として出力します。 また、以下のように構成品詞名が１種類で連続品詞名としても利用する場合は次のように省略した記述も可能です。\n以下にcompositePOSファイルの設定例を上げます。 ※なお、現時点では#によるコメント機能はありません。ので、記述した内容がそのまま利用されます。\n名詞-数 未知語 記号-アルファベット １行目は連続した数字を1つのトークン（名詞-数）として出力する設定です。（連続品詞名＝構成品詞名として省略して記述した例になります。） 2行目は連続したアルファベットを１つのトークン（未知語）として出力する設定です。\n次にSolrのschema.xmlにlucene-gosenのtokenizerを利用するフィールドタイプの設定を記述します。 $SOLR_HOME/conf/schema.xmlに以下を追加します。\u0026lt;types\u0026gt;～\u0026lt;/types\u0026gt;タグの間に記載します。\n... \u0026lt;types\u0026amp;gt; ... \u0026lt;fieldType name=\u0026amp;quot;text_ja\u0026amp;quot; class=\u0026amp;quot;solr.TextField\u0026amp;quot; positionIncrementGap=\u0026amp;quot;100\u0026amp;quot;\u0026amp;gt; \u0026lt;analyzer\u0026amp;gt; \u0026lt;tokenizer class=\u0026amp;quot;solr.JapaneseTokenizerFactory\u0026amp;quot; compositePOS=\u0026amp;quot;composite_pos_ja_naist-chasen.txt\u0026amp;quot;/\u0026amp;gt; \u0026lt;/analyzer\u0026amp;gt; \u0026lt;/fieldType\u0026amp;gt; \u0026lt;/types\u0026amp;gt; ... 重要なのはtokenizerタグのcompositePOS属性になります。ここに1.で記載したファイルを指定します。指定したファイルはschema.xmlと同じディレクトリに配置します。 以上が利用するための設定です。\n前回同様、「このComputerは、10回に1回の割合で起動中に青い画面が表示されます。」という文章をanalyze画面で解析した結果を示します。\nとまぁ、記事を書きましたが、すでにこちらで出ている話ですね。。。\nみなさん手が早くて困ってますｗ\nちなみに、上記の設定の場合、「100,000」や「3.14」といった文字列は「100」「,」「000」という形で出力されてしまいます。これらも数字とみなしたい場合は「名詞-数 名詞-数 記号-句点 記号-読点」という設定で１つのトークンとして出力されます。ただし、「。」も「記号-句点」なので注意が必要です。\n※なお、今回はlucene-gosen-1.1.0、Solr3.2を利用した例になっています。 ","date":1307977200,"dir":"post/2011/","id":"50f43b1726cf61066ef8656477b226be","lang":"ja","lastmod":1307977200,"permalink":"https://blog.johtani.info/blog/2011/06/14/compositepos%E3%81%AE%E5%88%A9%E7%94%A8%E4%BE%8Bnaist-chasen%E3%81%A7%E3%81%AE%E8%8B%B1%E5%8D%98%E8%AA%9E%E3%81%AE%E5%87%BA%E5%8A%9B%E6%96%B9%E6%B3%95%E4%BE%8B/","publishdate":"2011-06-14T00:00:00+09:00","summary":"前回、naist-chasenではアルファベットが別々の単語としてanalyzeされてしまうという話をしました。 ただ、これだと、英単語が含ま","tags":["lucene-gosen"],"title":"compositePOSの利用例（naist-chasenでの英単語の出力方法例）(Jugemより移植)"},{"contents":"lucene-gosenの1.1.0がリリースされました。\n大きな目玉はJapaneseTokenizerが出力する形態素に関するデータを遅延ロードすることで、パフォーマンスの改善を行ったことです。\n詳しくは関口さんのブログで実測されてます。さすが、早い。。。 あと、先日リリースされたLucene/Solr 3.2への対応も行われています。\nlucene-gosen-1.1.0のダウンロードはこちらから。\nうーん、中身がない記事だ。。。\n","date":1307934480,"dir":"post/2011/","id":"eeef60efe889349870426d10edc694be","lang":"ja","lastmod":1307934480,"permalink":"https://blog.johtani.info/blog/2011/06/13/lucene-gosen-1-1-0-%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2011-06-13T12:08:00+09:00","summary":"lucene-gosenの1.1.0がリリースされました。 大きな目玉はJapaneseTokenizerが出力する形態素に関するデータを遅延","tags":["lucene-gosen"],"title":"lucene-gosen 1.1.0 リリース(Jugemより移植)"},{"contents":"lucene-gosenをSolr/Luceneで利用する場合、TokenFilterを利用してTokenizerが出力したToken対してさまざまな処理（Tokenに対する正規化や展開など）を追加することが可能です。\n今回は現在（ver. 1.0.1）用意されているTokenFilterについて説明します。 以下はTokenFilterの一覧です。 「フィルタ名」にはSolrのschema.xmlで記述するクラス名を書いてあります。\nフィルタ名(Factory名) 概要 solr.JapaneseWidthFilterFactory 全角のASCII文字を半角に、半角カタカナを全角にするフィルタ。例：「Ｃｏｍｐｕｔｅｒ」-\u0026gt;「Computer」 solr.JapanesePunctuationFilterFactory 区切り文字、記号などを除外するフィルタ。[※1](#token_filter_kome_1) solr.JapanesePartOfSpeechStopFilterFactory 設定ファイルに記載した品詞に該当するTokenを除外するフィルタ。ファイルは「tags=\"ファイル名\"」とfilterに記載。なお、ここで記述する品詞とはanalysis画面に表示される「partOfSpeech」の完全一致となります。 solr.JapanesePartOfSpeechKeepFilterFactory 設定ファイルに記載した品詞に該当するToken\"以外\"を除去フィルタ。ファイルは「tags=\"ファイル名\"」とfilterに記載。なお、ここで記述する品詞とはanalysis画面に表示される「partOfSpeech」の完全一致となります。 solr.JapaneseBasicFormFilterFactory Tokenを基本形に変換するフィルタ。例：「悲しき」-\u0026gt;「悲しい」 solr.JapaneseKatakanaStemFilterFactory カタカナの長音（ー）の正規化フィルタ。4文字以上のカタカナのみの文字列の最後の長音（ー）を除去した文字列に変換します。例：「コンピューター」-\u0026gt;「コンピュータ」、「コピー」-\u0026gt;「コピー」 上記のTokenFilterをJapanizeTokenizerを利用するフィールドタイプに設定することで 各フィルタによる機能が有効になります。 schema.xmlの記載に関する詳細についてはこちらを参考にしてください。\n※1　Characterクラスの以下の定数に相当する文字が。SPACE_SEPARATOR、LINE_SEPARATOR、PARAGRAPH_SEPARATOR、CONTROL、FORMAT、DASH_PUNCTUATION、START_PUNCTUATION、END_PUNCTUATION、CONNECTOR_PUNCTUATION、OTHER_PUNCTUATION、MATH_SYMBOL、CURRENCY_SYMBOL、MODIFIER_SYMBOL、OTHER_SYMBOL、INITIAL_QUOTE_PUNCTUATION、FINAL_QUOTE_PUNCTUATION\n","date":1307344980,"dir":"post/2011/","id":"4b046ac6a4796fb1338f0481dbd4003d","lang":"ja","lastmod":1307344980,"permalink":"https://blog.johtani.info/blog/2011/06/06/lucene-gosen%E3%81%AEtokenfilter%E3%81%9F%E3%81%A1/","publishdate":"2011-06-06T16:23:00+09:00","summary":"lucene-gosenをSolr/Luceneで利用する場合、TokenFilterを利用してTokenizerが出力したToken対して","tags":["lucene-gosen"],"title":"lucene-gosenのTokenFilterたち(Jugemより移植)"},{"contents":"辞書の特性について 現在lucene-gosenでは以下の2つの辞書が利用可能です。 簡単に違いについて説明します。\nIPAdicの辞書について\nバージョン：2.6.0（※IPAdicとして公開されている最新は2.7.0） 最終更新日：2003/06/19 登録単語数：約24万語 NAIST-Jdicができたためか、更新されていない NAIST-Jdic-for-ChaSenの辞書について\nバージョン：0.4.3（※NAISTとして公開されている最新はMeCab用の辞書0.6.3） 最終更新日：2008/07/07 登録単語数：約28万語 IPAdicの後継として整備。品詞の定義など大まかな仕様は共通。 IPAdicと異なり、アルファベットや数字が1文字ずつ単語として登録されている。 IPAdicとNAIST-Jdicで大きな違いはアルファベットと数字の扱いについてです。 次のような文章をそれぞれの辞書で解析した結果は次のようになります。(SolrのField Analysisの画面です。思いの外大きいのでサムネイルのみですが。) 「このComputerは、10回に1回の割合で起動中に青い画面が表示されます。」 ○IPAdicの場合 ○NAIST-Jdicの場合 「Computer」と「10」という単語の区切り方が異なることがわかります。 この違いは、辞書のエントリが異なるために発生します。 NAIST-Jdicでは、数字（例：「1」）やアルファベット（例：「a」）が個々のエントリで登録されているため、分割された単語として認識されます。\n※この問題への対応方法はまた後日。\nカスタム辞書について 実際のデータを形態素解析したい場合、辞書に存在しない単語を登録して、1単語として認識させたい場合があります。（固有名詞など） このような場合にカスタム辞書を利用することで、新しい単語を辞書に登録することが可能になります。 カスタム辞書を利用する手順としては次のようになります。\nカスタム辞書ファイルの作成 作成した辞書ファイルを利用したjarファイルの生成 まずは辞書ファイルの作成についてです。 以下では、naist-chasen(NAIST-Jdic)の辞書を例として説明します。（ディレクトリの違いだけで、IPAdicでも同じ方法でOKです。）\nlucene-gosenでは辞書のコンパイルに2つのフェーズが存在します。\ngosen用辞書を生成する前処理（中間csvファイルの生成） gosen用バイナリ辞書の生成 カスタム辞書は1の出力の形式(=中間csvファイル=dictionary.csv)にあわせたCSVファイルとして作成します。 CSVの各カラムは次のような意味を持っています。\n単語 単語の生起コスト 品詞 品詞細分類1 品詞細分類2 品詞細分類3 活用型 活用形 基本形 読み 発音 3カラム目以降は「素性（そせい？）」と呼ばれる項目です。ipadic、naist-jdicでは「品詞」「品詞細分類1」「品詞細分類2」「品詞細分類3」「活用型」「活用形」「基本形」「読み」「発音」となります。 ※「見出し語」「形態素生起コスト」「素性」と呼ばれる項目を表形式にする。 厳密な品詞の体系に関してはIPAdicやNAIST-Jdicのサイトをご覧ください（説明できるレベルにはまだまだなっていないので。。。） 今回は、固有名詞（人名、地名など）を追加するという例でカスタム辞書について説明します。 固有名詞として「達川」という人名を追加してみましょう。 まずは、次のようなエントリをもつ「custom-dic.csv」ファイルを作成します。ファイルはUTF-8で保存してください。 コストはすでにあるエントリで似たようなエントリのコストを真似します。（今回は固有名詞,人名で似ているものを採用）。ちなみに、コストは小さいほど単語として出てきやすくなります。 ※カスタム辞書にはSenで利用していたものが利用できます。 **\"達川\",2245,名詞,固有名詞,人名,名,*,*,\"達川\",\"タツカワ\",\"タツカワ\"** 上記ファイルを、先日紹介した$LUCENE-GOSEN/dictionary/ディレクトリにコピーします。 では、カスタム辞書を含んだlucene-gosenのjarを作成しましょう。 カスタム辞書のビルドは$LUCENE-GOSEN/dictionary/で行います。 また、カスタム辞書の指定はCSVファイル名をantの引数で指定します。次がコマンドの例になります。\n$ cd lucene-gosen-trunk $ cd dictionary $ ant -Ddictype=naist-chasen clean-sen $ ant -Ddictype=naist-chasen -Dcustom.dics=\u0026#34;../custom-dic.csv\u0026#34; compile $ cd .. $ ant -Ddictype=naist-chasen 上記コマンドの例で\u0026quot;clean-sen\u0026quot;というタスクを実行しています。これは、すでに出来上がっているgosen用のバイナリ辞書を削除するタスクになります。すでにgosen用の辞書が作成されている場合には辞書の再生成が行われないためです。 また、複数のファイルを利用したい場合は-Dcustom.dics=\u0026ldquo;custom-dic.csv custom-dic2.csv\u0026quot;という形でスペース区切りでファイル名を記述すればOKです。\nカスタム辞書を適用する前と適用後の違いは次のとおりです。 適用前 適用後 簡単ですが、以上がカスタマイズ辞書を利用する方法でした。 ちなみに、この記事を書く前にすでにカスタム辞書の件を書いているブログがありました。。。こちらも参考にしてください。 今回の例でいくつかSolrのanalysis画面を利用して説明してきました。Solrでのlucene-gosenの利用方法についてはまた後日記載したいと思います。 ※参考までに。Solrでの利用方法はこちらにも記載してあります。\nまた、IPAdicなどの辞書について記載のある書籍を見つけましたので、参考になれば。\nアプリケーションソフトの基礎 (講座ITと日本語研究) ","date":1307002560,"dir":"post/2011/","id":"b2621497b3313c97855ed951f0d9b291","lang":"ja","lastmod":1307002560,"permalink":"https://blog.johtani.info/blog/2011/06/02/%E8%BE%9E%E6%9B%B8%E3%81%A8%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E8%BE%9E%E6%9B%B8%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2011-06-02T17:16:00+09:00","summary":"辞書の特性について 現在lucene-gosenでは以下の2つの辞書が利用可能です。 簡単に違いについて説明します。 IPAdicの辞書について バ","tags":["lucene-gosen"],"title":"辞書とカスタム辞書について(Jugemより移植)"},{"contents":"今回はソースのダウンロードとビルドについてです。\n最新版のソースを利用したり、JavaDocを見たい場合はソースをダウンロードしてからビルドすることになります。 ソースのダウンロードからビルドまでの手順について説明します。\nまずはソースのダウンロードです。\n$ mkdir ~/work $ cd work $ svn co http://lucene-gosen.googlecode.com/svn/trunk/ lucene-gosen-trunk $ cd lucene-gosen-trunk ダウンロードしたソースは次のようなディレクトリ構成です。\n.classpathEclipse用ファイル .projectEclipse用ファイル .settingsEclipse用ファイル AUTHORS作者のリスト（Sen、GoSen） CHANGES.txtlucene-gosenにおける更新履歴 COPYING.LGPLライセンス README.txtReadme build.xmlAntのビルドファイル dictionary辞書コンパイル用ディレクトリ docsAPIドキュメント用ディレクトリ libライブラリ prettifyGoogle Code Prettify用ディレクトリ（APIドキュメントでの色づけ用） srcソースコード また、辞書やソースのコンパイルにはAntを利用します。 通常利用するAntのタスクには次のようなものがあります。\ncleanプロジェクトのクリーンアップ build-dic辞書のコンパイル（辞書のダウンロードも行う） jarjarファイル生成 dist配布パッケージの生成（2つのjarファイル生成） javadocJavaDocの生成 jarファイルの生成までの大まかな流れは「javaソースのコンパイル」～「辞書のダウンロード」～「辞書のプレコンパイル」～「辞書のコンパイル」～「jarファイルの生成」となります。 Antのタスク以外にjarファイルを生成する場合に利用するオプションは以下の通りです。\n-Dproxy.hostプロキシのホスト -Dproxy.portプロキシのポート -Ddictype辞書の指定（指定可能なものは次の通り。naist-chasen、ipadic） 以下はNaist-Jdicのjarファイルを生成するコマンドの実行例になります。プロキシサーバを利用する環境の場合は-Dproxy.hostと-Dproxy.portも指定してください。（※認証が必要なプロキシの場合はAntのビルドファイルを修正する必要が出てきます。）\n$ ant -Ddictype=naist-chasen jarファイルはdistディレクトリに生成されます。 これで、jarファイルが利用できるようになります。\n次回は、ipadicとNaist-chasenの辞書の違いとカスタム辞書を利用する方法について書こうと思います。\n","date":1306398840,"dir":"post/2011/","id":"ff1441a42144a7de9a3eaf9f5e7cfea9","lang":"ja","lastmod":1306398840,"permalink":"https://blog.johtani.info/blog/2011/05/26/%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%8B%E3%82%89%E3%81%AE%E3%83%93%E3%83%AB%E3%83%89%E3%81%A8%E6%A7%8B%E6%88%90/","publishdate":"2011-05-26T17:34:00+09:00","summary":"今回はソースのダウンロードとビルドについてです。 最新版のソースを利用したり、JavaDocを見たい場合はソースをダウンロードしてからビルドす","tags":["lucene-gosen"],"title":"ソースからのビルドと構成(Jugemより移植)"},{"contents":"概要： Lucene/SolrのコミッターであるRobert Muirさんが始めたプロジェクト 歴史： MeCabのJava移植版としてスタートしたSenがベースになります。 その後、辞書の構築部分をPerlからJavaに置き換えたGoSenが登場しました。 が、どちらもメンテナンスされなくなってきたので、Robertさんが引き継いでメンテナンスとLucene/Solr対応をはじめました。そして、現在にいたります。 ライセンス： LGPLライセンス（ベースになったMeCabのライセンスにならって） 特徴： 以下のような特徴があります。 ・Lucene/Solrですぐに利用可能（3.1、4.0に対応済み） ・jarファイル1つで利用可能（辞書をjarファイルに内包） ・LuceneのAttributeをベースにしたTokenの解析 ・その他（パフォーマンス改善、テスト改善など） プロジェクトのサイト： http://code.google.com/p/lucene-gosen/ ダウンロード： http://code.google.com/p/lucene-gosen/downloads/list 現時点では2つの辞書を内包したjarファイルが用意されています。 Naist-jdic 0.4.3（for ChaSen） 参考サイト：http://sourceforge.jp/projects/naist-jdic/ IpaDic 2.6.0　参考サイト：http://sourceforge.jp/projects/ipadic/ ","date":1306130400,"dir":"post/2011/","id":"5988b62a0c0785a303b77c74608e8b55","lang":"ja","lastmod":1306130400,"permalink":"https://blog.johtani.info/blog/2011/05/23/lucene-gosen%E3%81%A8%E3%81%AF/","publishdate":"2011-05-23T15:00:00+09:00","summary":"概要： Lucene/SolrのコミッターであるRobert Muirさんが始めたプロジェクト 歴史： MeCabのJava移植版としてスタートした","tags":["lucene-gosen"],"title":"lucene-gosenとは(Jugemより移植)"},{"contents":"今さらですが、ブログをはじめてみようかと。今さらですが…\nはじめてみようと思った一番の理由は、自分で調べたことをメモがわりに残すためです。 あとは、自分を追い込むためもありますが。(こっちが一番の理由かも)最近勉強してないなぁと感じているので。 ということで、まずは、lucene-gosenやsolrについて書いていく予定です。\n","date":1305859440,"dir":"post/2011/","id":"94b85ba716dbb7c20b230e69248b8208","lang":"ja","lastmod":1305859440,"permalink":"https://blog.johtani.info/blog/2011/05/20/%E3%83%96%E3%83%AD%E3%82%B0%E3%81%AF%E3%81%98%E3%82%81%E3%81%BE%E3%81%99/","publishdate":"2011-05-20T11:44:00+09:00","summary":"今さらですが、ブログをはじめてみようかと。今さらですが… はじめてみようと思った一番の理由は、自分で調べたことをメモがわりに残すためです。 あと","tags":["misc"],"title":"ブログはじめます(Jugemより移植)"}]
\ No newline at end of file
+[{"contents":"日常でよく、形態素解析したくなることがありますよね？ そして、Slackも日常的に立ち上がってますよね？ ということは、Slackのボットとして常駐してもらえばできるのでは？\nkagome-bot 知り合いがkagomeという形態素解析ライブラリを開発しています。 その知り合いが、ボットにもしてくれています（複数辞書対応してみたかったので、PR作って取り込んでもらいました）。\nhttps://github.com/ikawaha/kagome-bot ただ、デプロイはしてなかったので、我が家にあるUbuntuのサーバーにデプロイして動かすことにしました。 ボットについては、上記のリポジトリを見てもらえればいいかなと。\nとりあえず動けばいいや、ということで、適当なshell scriptにnohupで起動していたのですが、Ubuntuの更新後の再起動で毎回ログインしてスクリプトの実行はめんどくさいな？ということでググって調べてみました。\nsystemdでユーザーのサービスとして登録 参考ブログにある手順ほぼそのままでした。知見ありがたいです。\nサービスの登録自体は、指定のディレクトリにファイルを作るのではなく、systemdコマンドをしようしました。\n$ systemctl --user --force --full edit kagome これで、参考ブログにあるようにkagome.serviceというファイルが~/.config/systemd/user/ディレクトリに作られます。 ファイルの内容などはほぼ参考ブログにある通りです。こんなかんじ。\n[Unit] Description=kagome bot [Service] ExecStart=/home/johtani/kagome-bot/start_kagomebot_service.sh ExecStop=/bin/kill ${MAINPID} Restart=always [Install] WantedBy=default.target start_kagomebot_service.shの中で、kagome-botコマンドを実行しますが、こちらは絶対パスで記述しておきました。 サービス起動時のパスは~/のようなのですが、念のために。\nあとは、次の手順でサービスを登録して開始します。\n$ systemctl --user enable kagome $ systemctl --user start kagome ログを見るのはjournalctlコマンドです。\n$ journalctl --user -u kagome あとは、以下のコマンドを実行しないと、マシン再起動後にログインするまでサービスが起動しないので忘れないようにしましょう。 （忘れてログインしてみて起動してるじゃん？というコントみたいなことをしてしまいました）。\n$ sudo loginctl enable-linger username 参考ブログ本当にありがたいですね。 備忘録のついでにブログにしておきます。\n参考ブログ ユーザー権限で systemd のサービスを稼働させる方法 - pyopyopyo - Linuxとかプログラミングの覚え書き - ","date":1706175053,"dir":"post/2024/","id":"c4dba56f2db4851cd31b561d92dc5e35","lang":"ja","lastmod":1706175053,"permalink":"https://blog.johtani.info/blog/2024/01/25/kagome-bot-as-a-user-service/","publishdate":"2024-01-25T09:30:53Z","summary":"日常でよく、形態素解析したくなることがありますよね？ そして、Slackも日常的に立ち上がってますよね？ ということは、Slackのボットとして","tags":["go"],"title":"kagome-botのユーザーサービス化"},{"contents":"今年も振り返りブログをリビングで書いています（ドミノ倒しすごいな）。 FMVのキーボードで書いているのでタイポがつらい。。。\n振り返り（2022年に書いた抱負から） まずは振り返りをと。\nフリーランス継続 今年も個人事業主として乗り越えられました。 ZOZOさんには今年も引き続きお世話になっている感じです。 そのほかにベクトル検索のお手伝いをしたり、OpenSearchを調べたりといった仕事を手伝っています。 今年も完全にリモートで作業していましたが、イベントに出かけたりできました。 来年はもう少し出かける感じになるかな？ 今年はすこしのんびり仕事をしていたので、来年はもう少し仕事探さないとかな（営業しないとなあ）\nプログラミング 今年はプログラムを書いたほうかなと。 Goで個人用ですが、Slackのボットを書いてみたり（GoでSlackのボットを作った話 | @johtaniの日記 3rd | @johtani\u0026rsquo;s blog 3rd edition）、公開されているAmazonのプロダクトデータを使って検索アプリを書いてみたり。 プロダクト用のアプリを書いているわけではないですが、ちょっとずつコードを読んだり書いたりしています。\nベクトル検索まわりをさわる がっつりとまではいかないですが、Elasticsearchのベクトル検索の調査をやったりしました。 Amazonのプロダクトデータを使ってもうちょっとやろうと思いつつ、そこまでは手が回せてない感じですが。 速度という面でどうやって折り合いをつけつつ導入するのか？ どういうシーンでつかうのがいいのか？ どのモデル選ぶのか？とか気になることだらけ。 なんか、みなさんがどうしてるのか気になってしょうがないので、話をしてもいいよという方は連絡をもらえるとうれしいかもなぁ。 ベクトル検索とかLLMの周りの動きがはやすぎてついていけてるのかどうか。。。\n本を読む 今年は比較的読んだかも？\n単体テストの考え方/使い方 ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティング ザ・ダークパターン ユーザーの心や行動をあざむくデザイン これまでの仕事 これからの仕事 機械学習による検索ランキング改善ガイド ソフトウェア設計のトレードオフと誤り 初めてのGo言語 買って読んでない本ももっとあるんですが。。。\n振り返り(今年あったできごと) ここからは今年の出来事を。 今年もずっと自宅でしごとしてました。 あとは少し仕事が少なめだったのでゲームが多くなってしまったかも？（本読めばいいのに。。。）\nゲーム（ONI、ゼルダ、FactorioのSpace Exploration） Dev container導入 検索技術勉強会の再開 ゼルダの新作面白かったですね。年初はOxigen Not Includedをやっていたのに、ゼルダが出てからはご無沙汰中です。ゼルダが終わった後は、ゼルダロスになってPythonを書いたりしていたのですが、うっかりFactorioのSpace Explorationを始めてしまい大変なことに。。。 全然終わる気配がないｗ\nローカルでの開発環境などをDev containerにちょっとずつしています。 Slackのボット、検索の遊び場、このブログ環境など。Dockerが必要にはなりますが、VSCodeとDev containerで環境を隔離できるし、VSCodeの拡張もコンテナごとに入れるのもできたりと便利です。\n最後は、検索技術勉強会を再開したことです。再始動という感じで4年ぶり？に再開しました（12月に開催した時のページ）。残念ながら私は裏方をしてただけで、当日は参加できてないのですが、次回（たぶん4月くらい）は参加するつもりです。再開の声を上げてくれた@takuya_aさんありがとう。絶賛スピーカーを募集中です。\n来年の抱負 さて、来年の抱負です。\nフリーランス継続 プログラミング継続 ベクトル検索の使い方をいろいろ試す 本を読んだブログを書く 今年もなんとかフリーランスを継続できましたが、そろそろ営業をしないといけないのかも？ ということで、外でしゃべったりもしていかないとなぁと。 あとは、検索ってどうやって導入すればいいのか？検索どうすれば改善できる？みたいなところのお手伝いをもっとしたいと思っています。 昨年出したこの本もあるので（『検索システム ― 実務者のための開発改善ガイドブック』 – 技術書出版と販売のラムダノート）、勉強会をやろうとしているところに顔を出したりしたいなあ。 外部の人を呼んで社内勉強会とかをできるというところがあれば参加したいので、声をかけてもらえればと。\nプログラミングはGo言語を触ったし、今年後半には検索の画面回りのプロダクトを触ってTypeScriptを勉強していこうかなという気になっています（なっているだけかもしれない？）。\nベクトル検索の使い方は、LLMだったりRAGだったりが世の中を席巻しているのもあり、いろんな記事が出てきて全然追いつけていません。だれか、少人数で勉強会とかやると興味ある人とかいるかなぁ？ こんなブログ見つけたよ、こんな論文があったよ、こんな使い方したらよかったよとかの共有をやるとみんな楽になったりしないかなぁ？\n今年は時々出かけて移動するタイミングで書籍を読んでいました。 読んだだけになってるのもあるので、少しでもいいからブログか何かに残しとかないとな。\nさて、今年は少しゆっくりできたので、来年はもうちょっといろんなところに顔を出しつつ、新しい仕事もできるといいなぁ。 勉強会もスピーカー集めをがんばるぞと。\nということで、今年もあと少しというところで無事書き終わりました。 来年もよろしくお願いいたします。よいお年をー\n","date":1704008961,"dir":"post/2023/","id":"d869fb48cb9acba03dc639481524ee80","lang":"ja","lastmod":1704008961,"permalink":"https://blog.johtani.info/blog/2023/12/31/review-2023/","publishdate":"2023-12-31T07:49:21Z","summary":"今年も振り返りブログをリビングで書いています（ドミノ倒しすごいな）。 FMVのキーボードで書いているのでタイポがつらい。。。 振り返り（2022","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2023）"},{"contents":"この記事は、情報検索・検索技術 Advent Calendar 2023の15日目の記事です。\n昨年に続き2回目の情報検索のAdvent Calendar参戦です。\n今年は、夏にオンライン参加したBerlin Buzzwordsの「The Debate Returns (with more vectors) Which Search Engine?」というセッションでPhilippさんが話題に出したOrama searchという検索エンジンを紹介してみようと思います（Oramaが正式名称なのかな？）。\nOramaという検索エンジン 公式サイトのトップにも記載がありますが、エッジで動作する全文検索＆ベクトル検索エンジンというもののようです。 なにそれ？という感じがしますが、オープンソース版のドキュメントを見るともう少しわかりやすい説明になっています。\nOrama is a fast, batteries-included, full-text and vector search engine entirely written in TypeScript, with zero dependencies.\nOramaはTypeScriptで書かれた、依存なしで利用できる検索エンジンということです（batteries-includedって初めて見たかも。「必要なものがそろってる」とかいう意味みたい（参考：英語のWikipedia））。\n以下は公式サイトにあるサンプルです。\ncreateでスキーマの定義をした検索エンジンのインスタンスを生成します。 insertで先ほど生成した検索エンジンにデータをインデックスします（後で紹介しますが、一括でインデックスするメソッドも用意されています）。 searchで検索し、検索した結果が返ってきます。 以上です。あとは、必要に応じてGUIを用意するだけです。\nimport { create, insert, search } from \u0026#39;@orama/orama\u0026#39; const db = await create({ schema: { title: \u0026#39;string\u0026#39;, director: \u0026#39;string\u0026#39;, isFavorite: \u0026#39;boolean\u0026#39;, year: \u0026#39;number\u0026#39; } }) await insert(db, { title: \u0026#39;The Prestige\u0026#39;, director: \u0026#39;Christopher Nolan\u0026#39;, isFavorite: true, year: 2006 }) const searchResults = await search(db, { term: \u0026#39;prestige\u0026#39;, where: { isFavorite: true, year: { between: [2000, 2008] } } }) サクッと動きそうですよね？依存関係がなくTypeScriptで書かれているということは静的なサイトなどでコンテンツを検索するのに使えるのでは？\nということで、自分のブログに組み込んでみました。 今回は組み込んだ時の流れと気になった点などを紹介します。 Hugoに組み込む際になるべく簡単にしたかったので、unpkg.comで公開されているJavaScriptだけを利用する形で検索ページを作ってみました。 JavaScriptやTypeScriptは不慣れなので効率がよくなかったり、間違っている点があればコメントなどをいただけると嬉しいです。\n構成 私のブログサイトはHugoで生成（参考：Hugo導入時の記事）して、GitHub Pagesとして公開しています。 現在のブログ検索にはAlgoliaを利用しているのですが、テスト目的としてOramaも使えるようにしてみました（右上のメニューでOramaをクリックすると以下で説明するOramaによる検索を試すことができます。\n今回実装してみたのは次のような流れです（日本語検索対応については後で説明します）。\nHugoでJSONのリストを生成（これまでと一緒） 1.で生成したリストをもとにNodeのスクリプトでOramaのインデックスファイルを作成 2.で作成したファイルを公開 画面で3.のファイルをダウンロードして検索 1. HugoでJSONのリストを生成（これまでと一緒） HugoでJSONのリストを生成します。Algoliaに記事を登録するのにも利用している仕組みです。 検索に利用する記事の情報を1記事を1つのオブジェクトとして出力します。1つの配列に記事ごとのオブジェクトが入っているJSONファイルになります。\n少しだけ特殊なことをしています。 ブログ記事にTagsというフィールドのありなしで処理を分岐しています。 Oramaが配列にNullを受け取った場合にうまく動かなかったので出力するJSON側で調整しています（あとで再確認してIssueあげておかないと）\n2. 1.で生成したリストをもとにNodeのスクリプトでOramaのインデックスファイルを作成 最初に紹介した公式のサンプルの場合、毎回Oramaのインスタンスを生成した後にインデックス登録の処理を行わなければいけません。 ただ、Hugoで生成したコンテンツは特に動的に更新があるわけでもないので、検索画面を表示するたびにインデックス登録するのも無駄が多い気がします。 Orama単体で最初に実装した時には、1.で作成した記事一覧のJSONをOramaで実装した検索ページのスクリプトが呼ばれたタイミングでフェッチし、insertMultiple（複数登録用のメソッド）を呼び出す実装にしていました。\nOramaでは、あらかじめ作成したOramaのデータベースを永続化・リストアするためのData Persistenceプラグインが提供されています。 インデックスに登録する処理コストはHugoでコンテンツを生成した直後に行い、検索画面では作成済みのインデックスファイルをフェッチしてリストアする形にすることにしました。インデックスと記事のJSONデータを含んだファイルになるので、元の記事一覧のJSONよりはファイルサイズが大きくなってしまいますが、処理時間も含めて考えると許容できるサイズではないかなと。\n次のスクリプトは1.で生成したJSONファイルを読み込んで、Oramaでインデックスした後にdpackというバイナリ形式でファイルに保存しています。 こののプラグインで選択できる形式は現時点ではjson、binary（デフォルト＝msgpack）、dpackの3種類になります。 残念ながら今回試したところ、binaryではエラーが発生したので、dpackを使用しました。\n3. 2.で作成したファイルを公開 単にGitHub Pagesに公開しているだけです。 ブラウザが2.で作成したインデックスファイルをフェッチしてから利用するためです。\n4. 画面で3.のファイルをダウンロードして検索 あとは検索画面です（長すぎるので、styleの部分は省略しています）。\nまず、必要なライブラリなどを読み込みます（下のソースコードの1行目から14行目）。\nOramaだけであれば問題ないのですが、OramaのプラグインがOramaをモジュールとして参照しているため、importmapとして定義しています。 Oramaのプラグインがいくつか利用しているものがあったので、まとめてimportmapに定義してあります。\n次に、検索窓（search-searchbar）や検索結果（search-hits）などのHTMLタグを用意します。 ヒット件数と検索にかかった時間も取れるので、表示する場所としてstatsも用意してあります。\n22行目からが実際の処理になります。\n28行目で、手順2.で作成したインデックスのファイルをフェッチします。 32行目でフェッチしたファイルから取り出した文字列をリストアして、Oramaのインスタンスを生成します。 34行目のtokenizerに関しては日本語対応で説明します。\n48行目のquery関数がクエリの組み立て＋検索の処理です。search-inputで入力されたテキストをtermとして渡して検索をしています（56行目）。 検索した結果のリストをもとに検索結果のHTMLタグを組み上げていきます。 検索結果には後述する@orama/highlightのモジュールを利用してスニペットを追加しています。\n日本語対応 残念ながらOramaは公式には日本語をサポートしていません（サポートしているスキーマに設定できるlanguageの一覧（＝STEMMERSにあるものだけ指定可能）。一覧と実装分けたほうがいい気がするけど？）。 ただ、tokenize関数を変更できるようにしてくれています。これを利用して、少しトリッキーな形で日本語対応しました。\n先ほどの手順2.でOramaのcreate関数として、componentsに次のtokenizerを渡します。\nlanguageはenglishですが、日本語をtokenizeする処理に次のように書き換えました。 stemmingは今回は行わない（＝用意されているstemmerを使えない）のでfalse、normalizationCacheは空のMapを用意しておかないとエラーが出るので、new Map()しています。 この設定を使ってcreateすることで、\ncomponents: { tokenizer: { language: \u0026#34;english\u0026#34;, stemming: false, normalizationCache: new Map(), tokenize: (raw) =\u0026gt; { return tokenize(raw) }, }, }, 少しわかりにくいですが、tokenizerのtokenize関数の中で呼び出しているreturn tokenize(raw)の部分はwakachigakiというライブラリのtokenize関数となっています。\nwakachigakiというライブラリ Elasticsearchなどのサーバー上で動作させる検索エンジンではkuromojiなどの辞書を内包した形態素解析器を利用するのが通常です。 ただ、今回はブラウザだけで完結した簡単な検索を行う仕組みをOramaを使って提供しようと考えました（kuromoji.jsというのもありますが、辞書のサイズがそこそこのサイズです）。 ですので、辞書ファイルのない軽量の形態素解析ライブラリとして、wakachigakiというライブラリ（＝6.2Kbの軽量日本語分かち書きライブラリ）を利用してみました。\n最初はTinySegmenterの利用をしていたのですが、wakachigakiのサイトにもあるように、TypeScriptやES Moduleでも利用できる形式となっていたのでこちらに切り替えました。\n辞書もっていないため、品詞でのフィルタリングや読みを利用した処理はできませんが、日本語の文章を分かち書きしてくれます。\ntokenize関数の設定 OramaのTokenizerインタフェースのtokenizeは入力の文字列をstring[]として返すことを期待しています。 wakachigakiのtokenizeも文字列を引数にとり、string[]を返すので、そのまま呼び出すだけにしてあります。\nただ、今回のブログ検索の実装では、検索窓に入力された文字列も特に何も処理せずにtokenizeに渡す形にしています。 クエリパーサーなどを考える場合は、検索窓に入力された文字列を前処理したりする必要がありますが今回はいったんこれで。。。\ndata-persistenceはcomponentsはpersistしない 手順2.で導入した、data-persistenceプラグインですが、現在の実装ではOramaが生成したデータベース（転置インデックス）だけを永続化しています。 独自に設定したtokenizerは残念ながら含まれていませんでした。 手順4.の検索画面のコードの34行目の部分（下記）で、フェッチしたインデックスデータからrestoreした後のOramaのインスタンスのtokenizerに手順2.と同じ設定のtokenizerを設定することで検索時にも同じトークナイズがされるようになります（今の仕組みだと修正した場合には、両方のソースコードを修正しないといけないのがちょっと面倒かも？）。\ndb.tokenizer = { language: \u0026#34;english\u0026#34;, stemming: false, normalizationCache: new Map(), tokenize: (raw) =\u0026gt; { return tokenize(raw) }, } tokenizerはOramaの検索エンジンのインスタンスに紐づく設定となっているので、フィールドごとに切り替えるといったことも現在では想定されていない気がします。\nハイライト ハイライトのために、インデックスデータに単語のポジションを保存するためのプラグインも提供されています。 このポジションは検索の単語がヒットしドキュメントのどの位置に出てくるのか？をあらかじめデータとして保存しておくことで、ハイライトのたびに単語の位置を毎回計算しなくてもよくするためのものと思われます。\nこれを利用してもよかったのですが、今回は@orama/highlightというモジュールを利用することにしました。 検索にヒットしたドキュメントの元の文章と検索のキーワードを入力すると検索キーワードの周りにハイライトのHTMLタグを埋め込んでくれるライブラリを利用しました。これは普通に他でも便利かも？\n余力があればプラグインを利用した時のインデックスのサイズの違いや検索時の速度の違いを調べてみるのもいいかもしれないです。\nそのほかの機能 今回は利用していませんが、Oramaにはそのほかの機能も用意されています（公式ドキュメントの検索の紹介のページ）。詳細は公式ドキュメントをご覧ください。\nTypo tolerance Facet/Filter Vector Search Geo Search Grouping Threshold Preflight Oramaで（まだ？）できないこと 今回触ってみて、現在のOramaの実装ではできなそうなことがいくつかあったので書き出しておきます。 あくまでも現時点のことです。今後実装される可能性もあります。\nデフォルトでは、searchのtermに渡した文字列をtokenizeし、出力されたトークン列（単語の配列）のそれぞれのトークン（単語）にヒットしたドキュメントが全て検索結果に含まれます。 検索結果のドキュメントはBM25でスコアリングされるので、多くのトークンが含まれるものが上位に来る可能性が高いです。\nただ、特定の単語を含まない検索、ANDやOR検索など凝ったクエリは現在は書けないようです（Issueがある）。\nfilterは別途用意されているので、例えばファセットで表示したカテゴリで絞り込んだ状態にするといったことはできそうです。\n残課題 とりあえず日本語をなんとなく検索できるようにすることはできました。 が、気になることもいっぱいありました。 時間を見つけてTypeScriptなどを勉強しながら探っていく感じでしょうか。\nインデックスを小さくする方法 今回はブログ記事のサマリー（Hugoで生成されるSummary）でインデックスを作ったので、インデックスのサイズはまだ小さくなっています（といっても1MB超えてるけど）。ブログ記事全体を検索できるようにする場合は、インデックスファイルが大きくなります。\nこれは、OramaがデフォルトではインデックスしたJSON自体もインデックス（ドキュメントストア）に保存しているためです。 ですので、Oramaに登録したJSONデータ＋検索用のインデックスがインデックスファイルとなります。 ただ、検索だけができればよい場合は、出来上がったインデックスがあればドキュメントのIDは取得できます。\n公式ドキュメントでもそのことに触れているページがあります（参考：Remote document storing）。\nまだちゃんと実装を見ていませんが、ブログ記事本体の文字列はドキュメントストアに保存しないようにすれば検索はできるが、容量が大きくならないといった工夫ができそうです。\nただ、検索結果にハイライトを含んだスニペットを表示したい場合は、コンテンツ文字列が必要になってくるので、代わりに何かしらの仕組みを考える必要が出てきます（例えばサマリー部分の文字列だけ保存しておいて、ハイライトはそこだけを対象とするなど）。\nそのほか そのほかに思いつくのはこの辺でしょうか？\nオートコンプリート：Oramaというよりも、JavaScriptやTypeScriptでうまく実装できるのか？という話のような気がしますが。。。 ファセット対応：機能としては存在していますが、今回は実装が間に合いませんでした。 Vector Search：検索キーワードのベクトルをどうやって作るのか？という問題が残りそう。コンテンツのベクトルだけで関連ページの表示みたいなことはできるかも？（動的にやる必要がないので、事前計算して各ページに埋め込むほうがよさそうだけど） Geo Search：緯度経度があるデータを探し出してこないと？ relevanceの処理の変更：BM25以外に切り替えることができるかどうか（Oramaのソースとにらめっこしないといけなそう） tokenizeの改良：辞書を利用する形態素解析ライブラリやAPIを利用してみたり、「てにをは」といった1文字のひらがなを削ることで、無駄な検索ヒットを減らしてみたり。大文字小文字の正規化も必要。 検索ログの解析：検索ログを保存する仕組みなどはないので、Google AnalyticsやほかのAPIなどを用意する？ まとめ ということで、Oramaという検索エンジン？ライブラリ？を利用して日本語のブログ検索を実装してみました。 まだ、機能が少ない部分もありますが、少数のデータをブラウザだけで簡単に検索できる仕組みをGitHub Pagesだけで提供することができそうです。 今回は静的なファイルだけで完結する形にしましたが、TypeScriptで利用できる簡単な検索エンジンライブラリとして使ってみるとまた別の面白さもあるかもしれないです。 まだ触っていない機能は思いついたこと（＝残課題に書いたこと）もあるので、ちょっと試行錯誤してみようかなぁ。\n","date":1702566000,"dir":"post/2023/","id":"476e17b6f854414033d5cec1470774ee","lang":"ja","lastmod":1702566000,"permalink":"https://blog.johtani.info/blog/2023/12/15/introduce-orama-to-blog/","publishdate":"2023-12-15T00:00:00+09:00","summary":"この記事は、情報検索・検索技術 Advent Calendar 2023の15日目の記事です。 昨年に続き2回目の情報検索のAdvent Calendar参戦です。 今年は、夏","tags":["orama","search"],"title":"Oramaという検索エンジンでブログ検索を作ってみた"},{"contents":"PySpaアドベントカレンダーの12/08のエントリーです。昨日は渋川さんのアンラーニングで失敗した話でした。\n私は、今年は昨年の続きっぽい話を。\n音楽の再生とか停止とか 今年もリモートで仕事を継続しています。 昨年、OwnToneという音楽サーバーを導入しましたが、ミーティング開始時や終了後に音楽の停止や再生をするのに、ブラウザで操作するのはちょっと面倒です。 加えて、ミーティングする際には実際には\n音楽を止める 電気をつける といったことをっやります。 音楽再生についても\n音楽を再生する アンプの音は音楽再生用の音量にする といった複数のことを行います。\n基本的にPCの前にいるし、Slackを常に開いているからSlackのBotを作ると便利になるのでは？ ということで、自分専用のSlack Botを作ってみました。\nGitHubリポジトリ 全く誰の役にも立たないけど、公開しています。\nhttps://github.com/johtani/smarthome Goで実装 知り合いに勧められたということもあり、Goをあまり触ったことがなかったので、Goでやってみました。時々新しい言語を触ってみたくなるので。。。\nコマンドパターンのような作りで、コマンド（操作）を増やしていく感じで実装してはみたのですが、この書き方がいいのかはまだよくわかっていないです。\nActionという単体の操作(例：OwnToneの一時停止)を、操作したい機器の操作ごとに作成しています。 インターフェースとしてはRunだけを定義しています。\ntype Action interface { Run() (string, error) } それらの操作（Action）をひとまとめにしたものをSubcommandという形で定義して、SlackのBotにはSubcommandの名前を送って処理を実行する形にしています。\ntype Subcommand struct { Definition actions []action.Action ignoreError bool } やりたいことを追加するタイミングで時々リファクタしたりもしていますが、基本はこんな感じです。 細かな実装はさておき、今回ボットを作るときの観点をいくつか。\n宅内ネットワーク 音楽サーバーのOwnToneもですが、YAMAHAのアンプのAPIも見つけたのでこれらの操作をボットから行っています。どちらも自宅のネットワークにあるので、今回作成したボットも同じネットワークで動作します。\n外部に公開されたHTTPのエンドポイントがあればよいのですが、今回は用意していません。 SlackのAPIではこれに対応したアプリを作るときのためにSocket Modeを用意してくれています。\nドキュメントがしっかりしているのもあり、チュートリアルなどを見つつ特に迷うことなく構築できました。\n基本的には「特定のチャンネルでボットがメンションされたら動作する」という挙動だけしか実装していないので、特に今回はこれで困ることもありませんでした（世の中の人たちはもっとすごいSlackの使い方をしていそうだけど。。。）。\n対象となるものたち ボットから操作しているのは今のところ3種類です。\nSwitchBot OwnTone YAMAHAのアンプ SwitchBot SwitchBotについては、go-siwtchbotを利用しています。 電気、エアコン、空気清浄機、サーキュレーターのオンオフをSwitchBot経由でやっています。\n室内灯の明るさのために、SwitchBot側でシーンを設定している（一番暗い明るさで電気をつける）ので、そこが少しと特殊でしょうか？\nあとは、SwitchBotの温湿度計を3つ（室内2つ、室外1つ）おいてあるので、これらの温度を表示するコマンドも用意しました。\nそれぞれの機器の電池残量（電池の絵文字の右側）を表示してます（書斎が2つあるように見えますが、温湿度計の名前なので、同じ部屋においてあります。。。温度が高いほうがデスクトップPCの近くにある）。 防水の温湿度計があるので、外の気温もわかるのは便利です。\nOwnTone JSONのAPIが用意されていますが、特にクライアントライブラリなどは用意されていません。 今回は、用意されているAPIのごく一部だけを利用するので、net/httpのClientでJSONを投げています。 必要になったらowntone/clientにメソッドを追加していく感じです。\nhttps://github.com/johtani/smarthome/blob/master/subcommand/action/owntone/client.go#L45 再生、一時停止、プレイリストの取得、音量指定あたりを実装しています。 音の出力先はAirPlay（次に出てくるYamahaのアンプ）になっています。\nあと、JSON APIのサンプルをChatGPTに渡して、「このJSONをレスポンスに受け取る処理をGoで書いてください」と聞いて処理を書いたりしました（細かいのはどう聞いたか覚えてないけど）。\nYAMAHAのアンプ ググって探してきましたが、利用しているYAMAHAのアンプにYXC（Yamaha Extented Control）と呼ばれるAPIが用意されていました。 PDFでAPIの仕様が公開されていたので、この資料とにらめっこしながら、必要そうなAPIを実行するクライアントを実装しました。 こちらは、OwnToneのAPIの処理をすでに書いた後だったので、それをもとに必要な実装を追加しただけです。\nちなみに、アンプの電源をONにするAPIは実装していません。\nOwnToneで音楽を再生する(AirPlayで信号が送られるみたい) シーン選択（Nintendo SwitchやPS5のシーンを用意している）のAPIを呼び出す という処理をすると自動で電源がONになりました。スタンバイしている状態でもAPIはリクエストを受け付ける状態になっているようです。 また、PS5のシーンを呼び出したら、PS5自体も起動するのが便利だったりします。HDMI経由で信号が飛んでるのかな？ 「ミーティング開始」や「音楽停止」コマンドではアンプの電源をオフするAPIを呼び出すようにしています。\nタイポ対応 「入力間違いしちゃうんです、人間だもの。。。」\nということで、10月にタイポ対応の処理を入れてみました。 タイポ対応前の実装では、入力された文字列がコマンドの文字列と完全一致した場合にだけ、コマンドが実行される形になっていました。 結構タイポしちゃうので、完全一致で見つからない場合の処理として、入力された文字列とコマンド名のレーベンシュタイン距離が2以下のものを探し、その中で距離が一番小さな値のコマンドを実行する形にしてみました。 コマンド数はたかが知れているのでコマンドのリストを全部チェックする形にしています。 タイポするとこんな感じ。\nレーベンシュタイン距離の計算にはGo-edlibを利用しています。OSS便利ですね。\nやってよかったこと ミーティング開始時などのいくつかの手順が簡素化できたので満足しています。 SwitchBotの操作もスマホをわざわざ操作しなくてもいいですし（仕事してるとキーボードとSlackは常に使ってるし）。 また、副次的な効果として、部屋の外から電源を切り忘れていたり、エアコンの切り忘れなどの場合に、スマホから遠隔でまとめた処理ができるのが便利です。\n今後やってみたいこと こういうのがあるともうちょっと便利かもなぁ？というのもあるので今後も気が向いたらコマンドなどを追加していく予定です。 今のところこんなことやりたいなというのがいくつかあります。\nキーワードに関連する曲の再生 OwnTone自体に検索の仕組みがついているので、キーワードを受け付けてそれに関する曲を流す Flexispotの操作 ミーティングの時は立ち上がっているので、机をスタンディングの状態にしたい 電子工作しないとだめかも？ Webカメラ用ライトの点灯 ミーティング時に明かりが必要なのですが、物理スイッチのOn/Off これも電子工作かな？ 定期的に温度をBotに表示させるとと面白いかも？ まとめ ということで、新しいプログラミング言語にも触れたし、作業環境も便利になって一石二鳥でした。 新しいプログラミング言語触るのはやっぱたのしいですね。\n","date":1701961200,"dir":"post/2023/","id":"516a7aa07f8faa6b7aa38beb5010cf8c","lang":"ja","lastmod":1701961200,"permalink":"https://blog.johtani.info/blog/2023/12/08/smarthome-bot/","publishdate":"2023-12-08T00:00:00+09:00","summary":"PySpaアドベントカレンダーの12/08のエントリーです。昨日は渋川さんのアンラーニングで失敗した話でした。 私は、今年は昨年の続きっぽい話","tags":["misc","music","bot"],"title":"GoでSlackのボットを作った話"},{"contents":"「機械学習による検索ランキング改善ガイド」を読みました。\n著者の鈴木さんより献本いただいたのを読み終わったのでレビューと、あとおまけです。\n紹介とレビュー どんな本なのか？は打田さんが書かれたブログ、「ブックレビュー：『機械学習による検索ランキング改善ガイド』 - Tomoko Uchida - Medium」に詳しく書かれているので、そちらも参考にしてもらうほうがわかりやすいと思います（丸投げ）。\n読みながらいくつかツイートしていたので、そちらも参考のために貼っておきいます。\nオライリーの検索ランキング本、負荷テストのことも書いてある、すごいhttps://t.co/YPnB6kxFY2\n\u0026mdash; Jun Ohtani (@johtani) August 28, 2023 私のレビュー わかりやすく検索の基本を紹介しつつ、本書のメインであるランキング改善について全体の流れが書かれています。 ランキング改善のやり方といっても、手法の話だけではなく、プロジェクトとしてどの様に進めていくべきなのか？また、関係するものはどんなものがあり（システムだけではなくチームについても書かれていたり）、どういう判断をもちながら運用していくのか？、負荷テストにまで言及されています。\n読んでいて特に私が気に入ったのは以下のような話でした\nランキング改善を進める前にきちんと解ける問題なのか？それ以前にやることはないのかを考えましょう マッチング改善についても少しだけ触れられているが、メインはランキングについてだと明記されている 実際に体験されたのであろう落とし穴の話 負荷テストについて1章設けてある！ ハンズオンのパートでもレイテンシの話がされている 付録としてベクトル検索についても触れてある 日本語でまとまって読める本があるのは本当に幸せですよね。\nおまけ 書籍ではハンズオンで、Elasticsearchとランキング学習のプラグインであるelasticsearch-learning-to-rankを利用しています（GitHubにサンプルが公開されています）。 書籍ではElasticsearchが7.13.4、プラグインが1.5.7-es7.13.4というバージョンになっていました。\nブログを書いている時点でのElasticsearchは8.x系になっています。せっかくなので、書籍を読みながら現時点で最新のものに置き換えてみるというのをやってみました。\nElasticsearchは8.10.2が最新なのですが、ランキング学習のプラグインはサードパティ製で、1.5.8-es8.8.2が最新版となっています。 ハンズオンのサンプルコードをフォークして、以下の構成にして動くようにしてみました。\nElasticsearch : 8.8.2 learning-to-rankプラグイン : 1.5.8-es8.8.2 Kibana : 8.8.2 Python : 3.10 Elasticsearch、プラグイン、Kibanaのアップグレード Elastic社が提供しているDockerイメージが利用されているので、バージョン番号を書き換えました。 あとは、learning-to-rankプラグインのバージョンを書き換えるついでに、elasticsearch-pluginコマンドで直接ダウンロードさせる形に書き換えました。\nhttps://github.com/johtani/building-search-app-w-ml/blob/es8/part2/app/search-engine/Dockerfile\nPython3.10にアップグレード 本当は必要なかったのですが、Pythonのイメージもついでに3.10にしました。 ただ、このおかげでインストールされるXGBoostのバージョンも1系から2系に上がってしまい、XGBoostを利用してモデル生成をする処理でエラーが出るようになってしまいました。。。\n2系へのアップグレードは手間がかかりそうだということで、pipコマンドでのインストールでのバージョンを\u0026lt;2として、1系をインストールすることで回避しました。\nhttps://github.com/johtani/building-search-app-w-ml/blob/es8/part2/app/workspace/Dockerfile\nelasticsearch-pyのアップグレード Elasticsearchを8系にしたので、クライアントライブラリ側も8系に書き換えました（元は7.17以下に固定されていた）。 pipで7系に固定されていたものを外して最新のもの（8系）をインストールするようにしました。 これだけでも特に問題なく動いたのですが、「DeprecationWarning」が出ている部分が1か所だけあります（サンプルではDeprecationWarningが出力されない形になっていましたが、出力するように変更しました）。\nElastic公式のドキュメントにMigrate to 8.0というページが公開されています。Pythonクライアントのアップグレードを行う際はこちらを参考にすると指針が記載されています。\n今回のサンプルコードではsearchの時の引数としてbodyを渡していたのですが、8系のクライアントライブラリからこちらが廃止になり、queryやrescoreなど個別の引数を渡す形に変更されています（search APIのリファレンス）。 ですので、bodyを**bodyでアンパックして渡すようにしただけです。サンプルコードがわかりやすく書かれているので変更も少しで済みました。\nhttps://github.com/johtani/building-search-app-w-ml/blob/es8/part2/app/workspace/collect_responses.py#L59\n一応、これでエラーが出ないで動きました。 すべて適用した、フォークして修正したブランチはhttps://github.com/johtani/building-search-app-w-ml/tree/es8で公開しています。\nまとめ すごくわかりやすいうえに、手を動かしながらどんなデータを使ってどんなことをやるのかが体験できる良い本でした。 理論的な話だけでなく、システムとしてどういうものが必要で、どういうことをやらないといけないのか？というのがわかるのがイメージできるのは重要だと思います。\n最後は広告ですが、ランキング改善以外の検索システムについて学べる本を検索システム ― 実務者のための開発改善ガイドブック – 技術書出版と販売のラムダノート出していますので、こちらも参考書として読んでいただけるとうれしいです。\n","date":1695612744,"dir":"post/2023/","id":"7f78b02c531f09602ba4e140132d26a2","lang":"ja","lastmod":1695612744,"permalink":"https://blog.johtani.info/blog/2023/09/25/read-search-raking-guide/","publishdate":"2023-09-25T03:32:24Z","summary":"「機械学習による検索ランキング改善ガイド」を読みました。 著者の鈴木さんより献本いただいたのを読み終わったのでレビューと、あとおまけです。 紹介","tags":["読書","elasticsearch"],"title":"機械学習による検索ランキング改善ガイドを読みました"},{"contents":"趣味？（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書いています。 ベクトル検索などの確認なども含めて、Jupyter Notebookで簡単なAPIの呼び出しを書いていましたが、検索はやはり画面があるほうがにぎやかでいいですよね。 ということで、画面周りで調べものをしていた時のことを後日の自分のためのメモとして残しておきます。\nSearch UIとSearchkit ということで、それほど手がかからないで検索の画面をサクッと作る方法がないか？ということでちょっとだけ探してみました。 最初にElasticsearchを利用していることもあり、すぐに検索の画面を作れるライブラリ・フレームワーク・コンポーネントがないかな？ということで思いついたのが次の2つでした。\nElastic Search UI Searchkit どちらも直接Elasticsearchに接続して検索をすることができるコンポーネントです。 Elasticsearchだけで完結していればそれでおしまいだったのですが、今回はバックエンド経由でElasticsearchに検索を書ける必要があります（ベクトル検索の仕組みもデモをしたいため、クエリの文字列をLLMなどでベクトルにしてからknn検索をすることになります）。\nSearch UIの構成 もともとSearch UIはElasticのApp SearchのGUI構築向けのコンポーネントとして作られました。 最近になって、直接Elasticsearchに接続できるコネクターを提供しています（ベータだけど）。 このコネクターを利用した場合は、ざっくりですが、このような流れになります。\nまた、Search UIはCustom Connectorの仕組みも用意しており（ConnectorのAPIが宣言されているのでそのAPIで独自実装が可能）、これを利用することで、ブラウザではなくバックエンド（Node）でElasticsearch Connectorを利用するような構成も取れるようになっています。\n改めて要件をまとめると ということで、やりたいことは\n簡単にUIが作れる バックエンドはPythonを経由して検索したい となります。 Searchkitも調べようかと思いましたが、いったんはSearch UIのCustom ConnectorでPythonでFastAPIでバックエンドのAPIを実装して、Search UIの想定しているリクエスト・レスポンスに変換すればいいかな？ということにしました。\nとりあえずSearch UI＋Custom Connectorからのリクエスト・レスポンス（フロントからバックエンドへの出入りの部分）を記録し、 Search UI＋Elasticsearch Connectorのときのリクエスト・レスポンス（バックエンドからEsへのの出入りの部分）も記録して、 参考にしながらバックエンドを実装しようと試みました。 Search UIのCustom Connectorのサンプルとなっていた、Node上でElasticsearch Connectorを動かしている部分をPythonで簡単に再実装しようという試みです（まったく同じ実装にする必要はなく、必要最低限の機能（検索窓、ファセット、ページング）が動作するところを目指します）。\nElasticsearch API connectorの調査 方針が決まったので、Search UIがElasticsearch API Connectorに渡しているリクエストをブラウザのデバッグ機能を使って追いかけてみると。。。 内部でSearchkitを読んでいる？？ことがわかりました。\nElasticsearch API Connectorがリクエストを変換しているのかと思っていたのですが、実は内部にもう一段変換が行われていました。\n方針を決めたつもりが、Searchkitが出てきてしまったので、Searchkitも調べてみることに。。。 なお、Search UIにElasticsearch API Connectorを導入したのがどうやら、Searchkitの作者で、現在はElasticのエンジニアになられているようです。\nSearchkitとは？ Search UIが利用しているSearchkitは、3.0ですが、Searchkit本家のリポジトリを見ると4.x.0となっています。\nどうして新しいものをSearch UIで使っていないのかな？と思いつつ調べてみたところ、Searchkit V4のブログを発見しました。\nSearchkit V4 integrates with Algolia’s Instantsearch library, which is a Search UI library built by Algolia. Instantsearch is an amazing library, and it’s been used by many companies and supports many frameworks like React, Vue and Angular. ブログより引用\nどうやら、V4ではコンセプトをガラッと変更されたようで、Algoliaがオープンソースとして開発しているInstantSearchのコネクター（アダプター）としてSearchkit V4を開発しているようです。 これは最近出てきている検索エンジンのTypesenseやMeilisearchの戦略にもなっています。\nなお、SearchkitのGitHubリポジトリやSearch UIのリポジトリを見ていると、Search UIの開発（およびSearchkitの3系）は現在は活発に行われていないように見えました。 Searchkit V4はちょっとずつ開発が進んでいるようです。\nまとめ？ 一応Searchkit V4の現状やInstantSearchもすこしだけ見てみたのですが、今回の私のプロジェクトでは検索画面はまだそこまで重要度は高くないので、いったん調べていたSearch UI＋Pythonのバックエンドの構成で動作する最小限を実装したところで終わりにしました。 なので、Searchkit V4＋InstantSearchの構成はまた今度という感じです。\nなお、Search UIの方は5月からコミットがされていないようです。どうも開発しているチームが別件で忙しそうだなというのを感じました。\n","date":1692768764,"dir":"post/2023/","id":"8f58cbe5f2ce85c22569af765de3f8d3","lang":"ja","lastmod":1692768764,"permalink":"https://blog.johtani.info/blog/2023/08/23/search-ui-and-searchkit/","publishdate":"2023-08-23T05:32:44Z","summary":"趣味？（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書いています。 ベクトル検索などの確認なども含めて、Jupyter N","tags":["searchkit","search-ui","画面"],"title":"search-UIとSearchkitと検索画面"},{"contents":"いくつかある環境をDev Containerで動くように変えていますが、最初に導入した時に疑問点だった「コンテナ名」について解消したのでメモを残しておきます。\nコンテナ名の指定 最初のDev Container導入の記事で、起動したコンテナの名前が自動で付与されて、ランダムに変わるという疑問点を書いていました。\ndocker-compose.yml対応の記事ではdocker-compose.ymlを利用すると、コンテナ名はファイル内で定義されたサービス名で起動されて見やすくなると気づきました。\nやはり、Dev Containerでイメージを指定している場合もわかりやすいコンテナ名がいいなと思ったところで、「runArgs」を思い出しました。 Dev Containerからコンテナを起動するときに渡す引数が書けるじゃないですか。そういえば、むかしdockerコマンドを使う時に名前を指定した記憶があったなと。ということで、Google検索です。「docker command args container name」で検索しましたｗ\n--nameというオプションで起動時のコンテナの名前の指定ができます。ということで、このブログを生成するためのdevcontainer.jsonに\u0026quot;runArgs\u0026quot;でコンテナ名を指定してコンテナ起動ができるようになりました（「ブログ記述環境としてのDev Container」という記事のdevcontainer.jsonにrunArgsの行を追加しただけ）。\n{ \u0026#34;name\u0026#34;: \u0026#34;Hugo - blog generator\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;mcr.microsoft.com/devcontainers/javascript-node:16\u0026#34;, \u0026#34;runArgs\u0026#34;: [\u0026#34;--name\u0026#34;, \u0026#34;blog_generator\u0026#34;], \u0026#34;postCreateCommand\u0026#34;: \u0026#34;/bin/sh ./.devcontainer/postCreateCommand.sh\u0026#34;, ... ","date":1690420969,"dir":"post/2023/","id":"f9e847ee886bdb9ab5583eeb6eabbd51","lang":"ja","lastmod":1690420969,"permalink":"https://blog.johtani.info/blog/2023/07/27/container-name-in-devcontainer/","publishdate":"2023-07-27T01:22:49Z","summary":"いくつかある環境をDev Containerで動くように変えていますが、最初に導入した時に疑問点だった「コンテナ名」について解消したのでメモを","tags":["dev container"],"title":"VS CodeとDev Container(コンテナ名の指定)"},{"contents":"このブログの生成には、Hugoを利用しています。 ブログ移行日記（その1）に書いてありますが、当時はbrewでインストールしていました。 また、Windowsに移行したタイミングで、WSL2のUbuntuにaptでhugoをインストールして利用していました。 WSL2の環境が壊れなければこのままでもいいのですが、最近Dev Containerを触っていたので、このブログを書く環境（おもにHugo）もDev Containerにできるのでは？と気づきました。\nということで、Hugo＋αの環境をDev Container化したので、そのメモです。\n必要なもの ブログを書いて、記事を構築して、公開するところまでに利用するのは次のようなものです。\ngit Hugo node atomic-algolia GitHubのプライベートリポジトリでHugoのプロジェクトを管理しています。 また、GitHub Pagesで公開しており、生成したHTMLもgitコマンドを利用してGitHubにpushしています。 このため、gitコマンドが必要です。\nコンテンツの生成はHugoコマンドを利用します（テーマの適用とかいろいろ）。\nあと、Algoliaでブログを検索できるようにしており（ブログ移行日記（その4）参照）、Algoliaへドキュメントのデータをアップロードするために、atomic-algoliaを利用しています。こちらは、nodeのモジュールであるので、nodeの環境も必要です。\nベースにするイメージ Dev Container Templatesというリポジトリが公開されています。 こちらを探すと、元となるdevcontainer.jsonが見つかることがあります。 Hugoのものがあるか探してみましたが、残念ながら見つかったのはJekyllのテンプレートでした。 今回は、nodeの環境が必要なのでjavascript-nodeを元に編集していきます。\n手元のUbuntuのnodeのバージョンが16だったので、バージョン16のイメージを指定します(devcontainer.jsonは後述)。\nHugoの追加 Hugoのテンプレートはなかったのですが、Dev Container FeaturesにHugoのfeatureが用意されていました。 featuresに1行追加するだけでコンテナにHugoをインストールしてくれる便利ものです。\nMarkdownの環境 Dev Container Templatesを探索していて見つけたMarkdownのテンプレートも参考にしてみました。 VS CodeのMarkdown向けの拡張機能がいくつかリストアップされていたので、ついでに追加です。 markdown-all-in-oneやmarkdownlintはこれまでも利用していたので、他のものも便利だろうということで。 他の物はどんなものかを後で調べてみる予定です。\n作った.devcontainerの設定はこちら ということで、出来上がった設定は以下の通りです。\ndevcontainer.json { \u0026#34;name\u0026#34;: \u0026#34;Hugo - blog generator\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;mcr.microsoft.com/devcontainers/javascript-node:16\u0026#34;, \u0026#34;postCreateCommand\u0026#34;: \u0026#34;/bin/sh ./.devcontainer/postCreateCommand.sh\u0026#34;, \u0026#34;features\u0026#34;: { \u0026#34;ghcr.io/devcontainers/features/hugo:1\u0026#34;: {} }, \u0026#34;customizations\u0026#34;: { \u0026#34;vscode\u0026#34;: { \u0026#34;extensions\u0026#34;: [ \u0026#34;yzhang.markdown-all-in-one\u0026#34;, \u0026#34;streetsidesoftware.code-spell-checker\u0026#34;, \u0026#34;DavidAnson.vscode-markdownlint\u0026#34;, \u0026#34;shd101wyy.markdown-preview-enhanced\u0026#34;, \u0026#34;bierner.github-markdown-preview\u0026#34; ] } } } postCreateCommand.shでは、npm installで、必要なモジュールのインストールをコンテナビルド後に実行できるようにしました。 （apt updateはなくてもいいな）\npostCreateCommand.sh #!/bin/sh # postCreateCommand.sh echo \u0026#34;START Install\u0026#34; sudo apt update sudo chown -R vscode:vscode . npm install echo \u0026#34;FINISH Install\u0026#34; まとめ ということで、ここ最近Dev Containerについて色々調べていたのでサクッとDev Container化ができました。 まぁ、HugoのFeatureが用意されていて、他に大したことをやっていないというのが大きいのですが。 このブログは今回構築したDev Containerで生成して公開した記事になります。\n","date":1690189832,"dir":"post/2023/","id":"7884b62c561b999b9358d52779a18218","lang":"ja","lastmod":1690189832,"permalink":"https://blog.johtani.info/blog/2023/07/24/introduce-dev-container-to-hugo-env/","publishdate":"2023-07-24T09:10:32Z","summary":"このブログの生成には、Hugoを利用しています。 ブログ移行日記（その1）に書いてありますが、当時はbrewでインストールしていました。 また、","tags":["hugo","dev container"],"title":"ブログ記述環境としてのDev Container"},{"contents":"WSL2にUbuntuを入れて、開発とかはこちらを利用しています。 また、Docker DesktopもWSL2のバックエンドエンジンを利用しています。\n知り合いとの話で、Ubuntuの外付けのSSDをマウントしたという話が出てきて、それだと遅くない？Ubuntu自体を移動できるんじゃないかな？という 流れになりました。 知り合いは、特に移動とかは考えてなかったのですが、自分のディスクの容量が今どのくらい使われているのかが気になり、調べてみると、 Cドライブの使用率が90%を超えてるじゃないですか。\nWizTreeというソフトを前回入れていたのを思い出して、再度調べてみたところUbuntuらしきvhdxファイルのサイズが171GB、Docker Desktopのデータ領域のvhdxファイルのサイズが81GBと、結構な割合です。\n前回は、Hyper-V管理ツールで仮想ディスクの圧縮処理を行ったのですが、Dドライブに移行したほうが安心できそうな気がしたので、移動の方法を調べました。\nWSLコマンドのドキュメントが公式で公開されています。こちらのコマンドを元に作業をしました。 また、ググって出てきた記事も参考にさせていただきました。ありがとうございます。\nwsl をDドライブに入れ直してディスク拡張する | blog.ojisan.io WSL2環境をコピー（複製）する方法 - Qiita まずは確認と停止 WSL2で使っているディストリビューションを確認します。コマンドは以下の通り。 実行した結果も含まれています。コマンドの実行にはコマンドプロンプトを使用しました。公式ドキュメントのドキュメントではスニペットはPower Shellと書かれてますが、コマンドプロンプトでも大丈夫そうでした。\nD:\\\u0026gt;wsl -l -v NAME STATE VERSION * Ubuntu Running 2 docker-desktop Running 2 docker-desktop-data Running 2 残念ながら、wslのコマンドでは実体がどこにあるのかを調べることができなかったですが、WizTreeでディレクトリ名などを見ていたのでなんとなう予測ができました。 （これ、他に知る方法あるのかなぁ？）\nディストリビューションの移動は次のような手順になります。\nwslのshutdown エクスポート（ディストリビューションのコピー） 今あるディストリビューションを削除 インポート（今ある名前で2.のファイルをインポート） まずは停止です。これをやらないとエクスポートができないので。\nD:\\\u0026gt;wsl --shutdown エクスポート 次にエクスポートです。 今回は以下の2種類の仮想環境をエクスポートします。\nUbuntu docker-desktop-data エクスポートでは、元のディストリビューションのファイル（Cドライブにあるファイル）が消えることはありません。 また、エクスポートの形式として、tarとvhdxの2種類が指定できます。 エクスポートのコマンドのデフォルトはtar形式ですが、エクスポート元のファイルがvhdxなので、vhdxでエクスポートしたほうがCPUにやさしかったです。 ちなみに、docker-desktop-dataはtar形式でエクスポートしてインポートしました。tar形式の場合は、ディスクのサイズが小さくなる可能性があるみたいです（不要なデータがvhdxの中に残っていたりする影響かと）。\nコマンドは以下の通りです（詳細は公式ドキュメントを参照してください）。出力ディレクトリはあらかじめ作っておきました（作ってない場合の挙動は未確認です。）\nD:\\\u0026gt;wsl --export Ubuntu .\\wsl\\Ubuntu\\ext4.vhdx --vhd docker-desktop-dataはtar形式です。\nD:\\\u0026gt;wsl --export docker-desktop-data .\\Docker\\ docker-desktop-data.tar ディストリビューションの削除（こわい？） 今ついているディストリビューション名を利用したいので、いったん、Cドライブ上にあるディストリビューションを削除する必要があります。 コマンドは公式ドキュメントにある--unregisterオプションを利用します。 以下のコマンドはUbuntuですが、docker-desktop-dataもやりました。\nD:\\\u0026gt;wsl --unregister Ubuntu ちなみに、このコマンドを実行すると、Cドライブの容量がいきなり空きました。 コマンドいっぱつでなくなりました。きちんとエクスポートしてから実行しましょう。 （なんなら、一度、別名でインポートして動作確認するのもいいかもしれないです。私はしましたｗ）\nインポート インポートするオプションも2種類あります。vhdxファイルの場合は、インプレースでのインポート（vhdxファイルをそのまま利用する形式）が可能です。 Ubuntuについてはこちらを利用しました。この場合、vhdxファイルがそのまま利用されるため、バックアップとしては利用できなくなります。今回は170GBもあるので、これでいいかと。\nD:\\\u0026gt;wsl --import-in-place Ubuntu .\\wsl\\Ubuntu\\ext4.vhdx tarファイル（docker-desktop-data）の場合は、通常のインポートを行いました。\nwsl --import docker-desktop-data D:\\Docker\\docker-desktop-data\\ D:\\Docker\\docker-desktop-data.tar この場合、tarファイルは残ったままで、新たにD:\\Docker\\docker-desktop-data\\ディレクトリにext4.vhdxファイルが作られました。 バックアップも取りつつ移行したい場合は--importがいいかもしれません。 また、WSLはバージョン1とバージョン2があり、インポートの際にこの部分も気にする必要があるようです。 今回はすべてバージョン2で、かつ、wslのデフォルトのバージョンを2にしてあったので特に意識していません。\nUbuntu起動ユーザーの指定と注意点 公式ドキュメントに、既存のユーザーを変更するコマンドの記載があります。 インポートしたディストリビューションは、デフォルトユーザーがrootになっていることがあるようなので、Ubuntuのユーザーを次のようなコマンドで変更しました。\nubuntu config --default-user johtani 公式ドキュメントの警告にもありますが、実行可能ランチャーがない場合があります。 今回のubuntuは、WSL2でUbuntuをインストールした時に作成されたコマンドで、unregisterした後にimportしてもきちんと動いたので問題にはなりませんでした。これは、インポートするときに、既存のディストリビューション名を利用したためと思われます。\nエクスポートやインポートの検証するために、NewUbuntuという名前で別途インポートした時には、NewUbuntuという実行可能ランチャーは作成されず、上記のデフォルトユーザーの設定は別の方法が必要になります（罠だ）\ndocker-desktop-dataのほうは、特に変更してないけど動いてそうだからいいのかな？ 前の設定の確認とかやっておくのがいいんだろうな、本当は。。。\nまとめ ということで、Cドライブに300GB近い空きができて、心の余裕もできました。 今回は、同じPC内で別のドライブへの移動でしたが、他のPCにもこれで移行ができそうですね。 たまにはバックアップをとっておくのもいいのかも？と思いました（やるかどうかはまた別の話）\n","date":1690180128,"dir":"post/2023/","id":"ed431877ce11fe403fee77f7d26ce637","lang":"ja","lastmod":1690180128,"permalink":"https://blog.johtani.info/blog/2023/07/24/move-distribution-to-another-disk/","publishdate":"2023-07-24T06:28:48Z","summary":"WSL2にUbuntuを入れて、開発とかはこちらを利用しています。 また、Docker DesktopもWSL2のバックエンドエンジンを利用して","tags":["wsl","windows"],"title":"WSL2のディストリビューションの環境移行"},{"contents":"前回の記事で、VS Code＋Dev Containerを導入しました。 残課題として「マルチコンテナ化」があるという話もしました。今回はDev Containerのdocker-compose.yml対応をした話をメモとして残しておきます。 実際、VS Code + Dev Containerに移行した後に、Esを起動してアプリからつなげるというのがうまくいかないというのがあったので対応がんばりました。。。\nDev Containerのdocker compose設定 この記事ではすでにdocker-compose.ymlが存在している状態の話をします。 変更する前は、devcontainer.jsonでベースのコンテナイメージの指定、マウントの設定などを行っていましたが、docker-compose.ymlにいくつかを移動しないといけません。 対応した時の作業の流れは以下のような感じです。\nワークスペース用のDockerfileの作成 docker-compose.ymlにワークスペース用のサービスを追加 devcontainer.jsonをdokcer-compose.ymlを利用する形に書き換え アプリでの接続文字列をlocalhostからdocker-compose.ymlのサービス名に変更 参考：対応した時のコミットです。差分などはこちらをごらんください。\ndevcontainerのリポジトリにPython+PostgreSQLのサンプルが公開されており、こちらを参考にしながら作業をしました。\n1. Dockerfileの作成 docker-compose.ymlだけでも完結するのかもしれないですが、いろいろやりたいことも出てくるかもしれないので別のファイルに切り出しました。 といっても、コンテナのイメージはdevcontainer.jsonに記述していたものを使っています。\nARG VARIANT=3.11-bookworm FROM mcr.microsoft.com/devcontainers/python:${VARIANT} ENV PYTHONUNBUFFERED 1 ENV TZ Asia/Tokyo TZはdevcontainer.jsonで指定していたものを、こちらに移行した形になります。 PYTHONUNBUFFEREDは参考にしたDockerfileの記載です。標準出力・エラーをバッファリングしない指定になっています。\n2. dokcer-compose.ymlにサービス追加 backendという名前のサービスをdevcontainer（VS Code）から接続するコンテナのサービス名にしています。\nservices: backend: build: context: . dockerfile: .devcontainer/Dockerfile init: true environment: - TZ=Asia/Tokyo command: sleep infinity volumes: - .:/workspace/search-research:cached - venv-search-research-backend:/workspace/search-research/.venv ... volumes: venv-search-research-backend: 1.で作成したDockerfileを利用します。docker-compose.ymlファイル自体は、プロジェクトのルートディレクトリに配置していますが、Dockerfileは.devcontainerディレクトリに入れたため、contextとdockerfileはこのような指定になっています。\ninitは、devcontainer.jsonで指定していた\u0026quot;runArgs\u0026quot;: [\u0026quot;--init\u0026quot;],の設定になります。\ncommandの部分は、コンテナが起動したままにしておくための設定です。\nvolumesでは2つのボリュームに関しての指定があります。 1つ目の/workspace...は、VS Codeがコンテナにプロジェクトをマウントする場所の指定です。 devcontainer.jsonだけを利用していた場合は意識していませんでしたが、/workspace/プロジェクト名というディレクトリにプロジェクトがマウントされていました。 docker-compose.ymlを利用する場合は、明示的に指定が必要です。 2つ目のvenv-...は.venvのディレクトリをコンテナの中だけのものにする設定を移植したものになります。 前回の記事ではコンテナIDをボリューム名に含めていましたが、こちらのほうがわかりやすいかと思い、プロジェクトの名前とサービス名をつけるようにしてみました。 Dev Containerで起動した場合はsearch-research_venv-search-research-backendという名前がついています（最初の部分はDev Containerがつけてるのかな？）\n3. dovcontainer.jsonの変更 devcountainer.jsonから呼び出すものの準備ができたので、devcontainer.jsonを書き換えます。 公式のドキュメントとしてDocker Compose向けのプロパティが紹介されています。 変更したものは次のような形です。\n{ \u0026#34;name\u0026#34;: \u0026#34;search-research\u0026#34;, \u0026#34;dockerComposeFile\u0026#34;: \u0026#34;../docker-compose.yml\u0026#34;, \u0026#34;service\u0026#34;: \u0026#34;backend\u0026#34;, \u0026#34;workspaceFolder\u0026#34;: \u0026#34;/workspace/search-research\u0026#34;, \u0026#34;postCreateCommand\u0026#34;: \u0026#34;/bin/sh ./.devcontainer/postCreateCommand.sh\u0026#34;, \u0026#34;customizations\u0026#34;: { ... dockerComposeFile : 利用するdocker-compose.ymlのファイルパス service：VS Codeが利用するワークスペース用のサービス名 workspaceFoldeer：VS Codeがコンテナに接続したときに開くフォルダのパス を指定します。これで、VS Codeでこのプロジェクトを開いた時に、Dev Containerがdocker-compose.ymlを使ってコンテナの起動（ビルドとか）を行ってくれます。\n4. アプリの接続文字列の書き換え こちらはおまけです。 PythonのアプリからElasticsearchに接続するときの文字列として、Dev Container化の前は、http://localhost:9200と指定をしていました。 Elasticsearch用のサービス（es）で、ポートフォワードをしていたためです。\nアプリ側もコンテナ化したので、Docker Composeが名前の解決をしてくれるので、http://es:9200という接続文字列で接続ができるようになりました。\nということで、ここまでで、VS Codeでプロジェクトを開くと、2つのコンテナ（backendとes）が起動してVS Code上でPythonアプリからEsへの接続ができるようになりました。\n追加の変更 参考のプルリクでは、上記まででしたがさらにいくつかの変更をそのあとやっています。\n起動するサービスの指定(開発だけするときはEsを起動したくない) devcontainer.jsonでrunServicesを使って指定できます（公式ドキュメント） GPUをコンテナから利用できるように devcontainer.jsonでfeaturesのnvidia-cudaを指定し、docker-compose.ymlでnvidiaのドライバーなどを設定することで対応しました。 nvidiaが公開しているcuda対応のコンテナイメージでもよかったのですが、こちらのほうが楽そうだったという理由です。featuresとコンテナのビルド、postCreateCommandの順序などはもうちょっと勉強しないといけない気がしています。 これらの対応はこちらのコミットで対応しています。\nGPUの対応は、私個人の環境はこれでいいのですが、複数の人がこのリポジトリを使う場合はどうやって切り替えたりするんだろう？という疑問が残っています。。。 今回はrinna/japanese-clipのモデルを使って、テキストからベクトルを生成する部分の処理のためにGPUを使いたいというモチベーションがあり、コンテナでもGPUを使えるようにしています（CPUだと時間がすごくかかる。。。）。\nサービス起動の新たな問題点 runServicesで起動するサービス名を指定したのはよかったのですが、Elasticsearchのサービスを起動して、データ登録や検索の確認を行おうと思った時に、EsのコンテナをVS Codeだけで起動する方法がまだわかっていません。。。 一度コンテナをビルドした後なら、「Remote Explorer」でOther Containerというくくりで表示され、右クリックで起動や停止ができそうなのだけど、新規サービスをdocker-compose.ymlに追加した場合は、自分でターミナルなどでコンテナのビルドをしないといけないかもしれないです。もうちょっと調べてみないとなぁ。\n副次的な効果 Docker Compose対応をしたことで、前回の記事での疑問点のうち、「コンテナ名」「VolumeのID」については懸念点がなくなりました。\n「コンテナ名」は、docker-compose.ymlのサービス名がコンテナ起動時に名前として利用されるため、Docker Desktopで見た時などの探しにくさはなくなりました。 ただ、「イメージ名」については、いまだに2つできています。「-uid」がつかないものの代わりに、search-research-backendというイメージが作られています。 ただし、実際に利用されるのは前回の記事に書いたようなvsc-search-research-bf04371c017c8d2f1dd5ad2529841b02e9ea1d1aaa4354c19edf53cef3f0c13b-uidという名前のイメージです。\n「VolumeのID」については、docker-compose.ymlのファイルで自分で名前をつけるようにしたので、コンテナのIDが利用されなくなったという次第です。 代わりに、プロジェクト名である「search-research」という名前を直接記述しているので、変数などで置き換えたほうがいいのかも？という気がしています。\nまとめ ということで、複数のコンテナを利用するプロジェクトでVS Code+Dev Container対応ができそうだということがわかりました。 ついでに、GPU対応もできたのでこれで、やっと他の検索エンジン対応などができる気がしています。 （その前にpre-commitを保存時にチェックする形に変更かなぁ） やりたいことからちょっとずつ外れている気もするけれど、新しいことを調べるのは楽しいですね。\n","date":1689902010,"dir":"post/2023/","id":"086b4fd5f77021a0a2aa6b0e90061486","lang":"ja","lastmod":1689902010,"permalink":"https://blog.johtani.info/blog/2023/07/21/multi-containers-with-dev-container/","publishdate":"2023-07-21T10:13:30+09:00","summary":"前回の記事で、VS Code＋Dev Containerを導入しました。 残課題として「マルチコンテナ化」があるという話もしました。今回はDev C","tags":["python","dev container"],"title":"VS CodeとDev Container（docker-compose.yml対応）"},{"contents":"前回の記事で、pre-commitとPyCharmとWindowsの組み合わせで困っていることを書きました。 これについて、知り合いとチャットで話をしていて、それほどPyCharmにこだわりもないよなぁということになり、 であれば、ISIDのブログ（Dev Containerを使ってステップバイステップで作るPythonアプリケーション開発環境 - ISID テックブログ）を試してみるとすっきりするかもしれないとなり、Dev Container対応をブログを参考に行ってみました。\n順を追ってブログで説明されているので、どういう仕組みなのか、どの設定が何を意味しているのか？がとてもよくわかりやすくすんなり対応することができました。\nブログの手順をなぞっているところでいくつか固有の手順や疑問点が出てきたのでブログに書き記しておきます。 結果は、コミットしてあるものを見てください。\nブログとは違う手順 まずはISIDのブログとは違う点をいくつか。\n.venvはいったん削除 ブログでは新規のプロジェクトを作成していく過程で、コンテナ化した環境を作った後に.venvをDockerコンテナのボリュームにして、最後に仮想環境のPythonを生成していました。 私の場合は、すでにホストOS（実際にはWSL2のUbuntuだけど）で.venvのディレクトリを作成してある状態だったので、いったん削除する必要がありました。 すでに存在する.venvがbindマウントされてしまっている状態になるため、Dockerのボリュームとの整合性が取れなくなるようです。\nこの作業を行う前か、途中でDev Containerを停止した状態で、.venvを削除することで問題なくDockerのボリュームに仮想環境のPythonが登録されるようになります。\npostCreateCommand.shの呼び出し方 ファイルに実行権限がないと、実行権限エラーが出ました。 実行権限を与えるか、次のような記述で動くようになりました。 今は、ファイルに実行権限をつけるのではなく、次のような記述にしていますが、何か問題あるかな？\n\u0026#34;postCreateCommand\u0026#34;: \u0026#34;/bin/sh ./.devcontainer/postCreateCommand.sh\u0026#34;, 実際に動作しているログを見ると\n/bin/sh -c /bin/sh ./.devcontainer/postCreateCommand.sh\nとなっているので、少し気持ち悪いのだけれども。。。\npostCreateCommand.shの追加処理 今回Dev Containerを適用したプロジェクトでは、sentencepieceを利用します。 この、sentencepieceをpoetryがインストールするタイミングで、cmakeを要求してきました。 今回利用しているDocker Imageにはcmakeは含まれていないため、以下の処理を追加しています。\nsudo apt update sudo apt-get install cmake -y また、rinna/japanese-clipも利用しているのですが、こちらは、poetryで追加してインストールでは依存するパッケージがインストールされないため、pipコマンドを利用するようにしています。\npip install git+https://github.com/rinnakk/japanese-clip.git コンテナイメージを作った後にやりたいことを、自由にスクリプトで書けるのは便利ですね。\npre-commitのスクリプトの再生成 こちらも、既存の環境が残っているとPythonへのパスの違いの問題が出たので、作り直しました。 .git/hooks/pre-commitのファイルを削除し、pre-commit installをやったものをリポジトリにコミットしてあります。\n疑問点 作業をしていて疑問点もいくつか出てきたのでメモを残しておきます。ちなみに、これらの疑問について実際に調べるまでには至っていません。 時間を見て解決できればなぁと（できるのか？）。\nImageが2つ Dev Containerの設定を書いた後に、コンテナをビルドすると、Docker DesktopのImagesにイメージが出来上がります。 この時、イメージが2つできあがっています（なぜ？）。\nREPOSITORY TAG IMAGE ID CREATED SIZE vsc-search-research-bf04371c017c8d2f1dd5ad2529841b02e9ea1d1aaa4354c19edf53cef3f0c13b-features-uid latest 25c7e23416ec 3 days ago 1.69GB vsc-search-research-bf04371c017c8d2f1dd5ad2529841b02e9ea1d1aaa4354c19edf53cef3f0c13b-features latest fcf9eaeb2187 3 days ago 1.69GB こんな感じで、最後に-uidがついているかいないかの違いです。 実際にコンテナ起動時に利用されるのは-uidがついているものになります。 なぜ2つになっているのか、1つにする設定などがあるのか？といったところが気になるところです。\nContainerの名前 devcontainer.jsonの設定を書き換えて、コンテナをリビルドすると起動したコンテナの名前が自動で割り振られているようです。 今は、fervent_hopperとなっています。ランダムにつけられているようなのですが、名前を付ける方法はないのかなぁ？と。\ndevcontainer.jsonにはnameというプロパティもあるのですが、この値がどこで使われているのかはよくわかっていません。 Remote Explorerでコンテナの一覧が見えますが、ここでは、リポジトリ名が利用されているようです。\nVolumeのIDはどこから？ devcontainer.jsonで次のような記述で、.venvのディレクトリようにDockerにボリュームを作っています。\n\u0026#34;mounts\u0026#34;: [ \u0026#34;source=venv-${devcontainerId},target=${containerWorkspaceFolder}/.venv,type=volume\u0026#34; ], 実際にコンテナでマウントされている情報を見ると\n/workspaces/search-research/.venv /var/lib/docker/volumes/venv-04emir9hi2caivtjunfe3l17452hkbb3hdut1qflbrn8n924ho5c/_data となっています。 04emir9hi2caivtjunfe3l17452hkbb3hdut1qflbrn8n924ho5cがdevcontainerIdに相当するのだとは思うのですが、誰がつけたものかなどがまだよくわかっていません。 もうちょっとわかりやすいものが使えるほうが嬉しいかも？と思っていたりします。 （複数Dev Containerを使い始めると、Docker Desktopで見ると、どのボリュームがどのDev Containerに紐づいているかがぱっと見ではわからない）\n.vscodeディレクトリどうしよう？ たぶん、VS Codeを触っている過程で、何かの設定をしてしまったのだとは思うのですが、 .vscode/settings.jsonというファイルができており、次のような内容になっています。\n{ \u0026#34;git.ignoreLimitWarning\u0026#34;: true } 何か意味があるかも？ということで、コミットしてリポジトリに入れたのですが、いらないのかもしれないなぁと。\n残作業 とりあえず、VS CodeでPython環境ができて、VS CodeのTerminalでPythonのプログラムが実行できるのはわかった段階です。 いくつか、今後調べながらやる必要があるものが残っているのでメモとして残しておきます。\nマルチコンテナ化 今回Dev Containerに対応したプロジェクトでは、検索エンジンもDockerのコンテナとして起動して、Pythonのプログラムから接続したいと思っています。 となると、docker composeでいろいろと起動するほうがネットワークなどの設定も楽になるのでは？と思っているところです。 Dev Containerのテンプレートがいくつか用意されており、その中に「Python 3 \u0026amp; PostgreSQL (postgres)」というのを見つけたので、このあたりが参考になるのでは？と考えているところです。\npre-commitではなく、保存時にフォーマット pre-commit＋localのコマンドも動くようにはなったのですが、保存時にフォーマットなどをかける設定もISIDのブログで記載がありました。 コミットしようとして、怒られるよりも、保存時に怒られたりするほうがいいかも？という気分になってきています。 どこまでが切り替え可能なのか？なども見ながら対応してみようかなと。\nもう少し開発してみて改善点を探っていく とりあえず動いたという段階です。 PyCharmとの違いがあるはずで（たとえば、git周りのGUIの違いとか）、そのあたりでどんな違いがあり、どんなものがあると嬉しいのか？といったものを調べる必要もあるかなと考えています。 TerminalでCtrl+rがうまく使えなかったり(Auto Hot Keyで検索のショートカットに割り当ててしまっているから。。。)などもあるので、この辺も調べていきたいなと。 Windows Terminalを使えたりするのかなぁ？\nまとめ さて、とりあえず、VS CodeでPythonのDev Container環境を作って動くところまでは来ました。 PyCharmを使いこなしていなかったのもあり、それほど違和感なく移行できるような気がしています。 調べることはまだまだあるし、プログラム書くつもりが、環境を整える方向に話がずれている気もしますが、まぁ面白いのでよしとするかなぁ。 いろいろまだまだ知らないことだらけです。。。\n","date":1689254123,"dir":"post/2023/","id":"a12474027c91fad5a861aa9919817d72","lang":"ja","lastmod":1689254123,"permalink":"https://blog.johtani.info/blog/2023/07/13/introduce-vs-code-and-dev-container/","publishdate":"2023-07-13T22:15:23+09:00","summary":"前回の記事で、pre-commitとPyCharmとWindowsの組み合わせで困っていることを書きました。 これについて、知り合いとチャット","tags":["python","dev container"],"title":"VS CodeとDev Containerの導入（まだ途中）"},{"contents":"最近、趣味（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書き始めました。\nきちんとPythonのプログラムをプロジェクトとして書いたことがないので、 Pythonのプロジェクトのディレクトリ構成などを手探りで進めているところです。 コードのフォーマットとかもやらないとなぁ？と知り合いのいるSlackでつぶやいたところ、gitのpre-commitフェーズでblackなどのフォーマットやスタイルを修正してくれるツールを実行する方法を教えてもらいました（PRまで送ってもらえたのでありがたい）。\nで、pre-commit周りの設定などを変えている段階で遭遇した問題点についてログを残しておこうと重いブログを書いています。 残念ながら現時点では解決してないんですけどね。。。\n手元の環境 簡単に環境を書いておくとこんな感じです。\nWindows上のPyCharmを開発で使用 プロジェクトのディレクトリはWSL2のUbuntu上 Python、gitはUbuntuのものを利用 プロジェクトのルートディレクトリにある.venvにvenvでPythonの仮想環境を作成してある 問題点 遭遇したpre-commitの問題点は次の通りです。\npre-commitの設定でrepo:localでローカルのプロジェクトにインストールしたコマンドを利用するように変更 すると、PyCharmでコミットすると、blackなどのコマンドが見つからない ターミナルでコミットするときはきちんと動作する 色々調べて試行錯誤した結果、現在はrepo:localでのローカルコマンドを使用する方法はあきらめました。 移行は、作業記録みたいなものです。どういう流れでpre-commitを取り込み、ローカルに切り替え、切り戻したかという話です。\npre-commitとpre-commit 最初に少し戸惑ったのは、pre-commitというツールとgitのpre-commitフックです。 gitのpre-commitのフックのために作られたPython製のpre-commitというツールがあります。\nこのPython製のツールを利用することで、プロジェクトに.pre-commit-config.yamlという設定ファイルを置けば設定に記述されたツールをgit commitのタイミングで実行してくれます。 実際には、pre-commitというツールの初期設定のタイミングでpre-commit installというコマンドを実行して .git/hooks/pre-commitというスクリプトが生成されます。 gitコマンドはcommitされた時に（commit前のフェーズ）でこのスクリプトを実行し、そこで.pre-commit-config.yamlが参照されています。\n.pre-commit-config.yamlの記述は次のようなものになります（最初にもらったPRより）。\nrepos: - repo: https://github.com/psf/black rev: 23.3.0 hooks: - id: black args: [\u0026#34;--line-length\u0026#34;, \u0026#34;120\u0026#34;, \u0026#34;.\u0026#34;] - repo: https://github.com/pycqa/flake8 rev: 6.0.0 hooks: - id: flake8 - repo: https://github.com/pycqa/isort rev: 5.12.0 hooks: - id: isort args: [\u0026#34;--profile\u0026#34;, \u0026#34;black\u0026#34;, \u0026#34;--filter-files\u0026#34;, \u0026#34;--multi-line\u0026#34;, \u0026#34;3\u0026#34;] - repo: https://github.com/pre-commit/mirrors-mypy rev: v1.4.1 hooks: - id: mypy 実際に、PRを取り込んで動かしてみたところ、blackなどが動いて行末のスーペースの除去や未使用のimportについて指摘をしてくれました。 便利だなと思ったのですが、ここで疑問が。\n今回は対象とするプロジェクトはpoetryで依存パッケージの管理を行っています。 今回、上記を動かすためにpoetryに追加されたものはpre-commitだけでした。 「あれ？blackとかはどこにあって、どうやって動いてるんだ？」という疑問が出てきます。 コンフィグファイルにはパスなどの記載をせず、それぞれのgithubリポジトリの記載とバージョンがあるからです。\npre-commitが使用するツールのインストール先 調べてみたところ、どうやらホームディレクトリにある.cache/pre-commitにblackなどのコマンドが見つかりました。 pre-commitツールが設定ファイルを基に、必要なコマンドをgithubからダウンロードしてきて実行時に利用しているようです。 pre-commitは便利なのだけど、せっかくPythonのプロジェクトだしそれぞれのツールはpoetryでpyproject.tomlでバージョンや設定を管理したほうがすっきりするのではないか？ということで、少し調べてみました。\n同じようなことを考えている方がブログを残していてくれました（Pythonレポジトリ用のpre-commit環境を整える）。 設定をpyproject.tomlに移行し、そのあと、ローカルのpetryでblackなどのコマンド類をインストールして利用する設定に書き換えています。 先人の肩に乗っかって、手元で同じようにpre-commitの設定ファイルのrepoをlocalに書き換えていき（その時のコミット）、ターミナルでpoetry run pre-commit run -aで動作確認できました。\nPyCharmでコミットしたらエラー ですが、実際に変更した状態でPyCharmからコミットしたら、コマンドが見つかりませんというエラーが出ます。。。 WSL2のターミナルでgit commitした場合は問題ありません。 どうして？となりますよね。。。。\n.git/hooks/pre-commitはPyCharm、ターミナルのどちらからも実行されています。 ですが、PyCharmではblackなどが見つからないというエラーが出ました。\n.git/hooks/pre-commitを見てみると、python実行するためのpythonのパスはプロジェクトにある.venv/bin/pythonを指定しています。 デバッグのために、このスクリプトにecho $PATHを差し込んで、git commitをPyCharmとターミナルからそれぞれ実行してみたところ、大きな違いがあります。\nターミナルで実行した場合は、\u0026lt;プロジェクトのディレクトリ\u0026gt;/.venv/binもPATH環境変数に存在していました。このため、.venv/binにあるblackなどを実行できています。\nPyCharmはWindowsから起動しています。プロジェクトのインタプリタとしては、WSL2のUbuntuにある.venv/bin/pythonを指定しているためもあり（？）、出力されたパスは/mnt/c/などのWindowsのパスなども入っていたりしますが、\u0026lt;プロジェクトのディレクトリ\u0026gt;/.venv/binは見つかりません。\nここからはソースコードは読んでいないので憶測ですが、.git/hooks/pre-commitで呼び出されているpre-commitツール（Python製）は、設定ファイルで指定されたコマンド（blackなど）を、コマンドとして今の呼び出されたコンテキストで実行しているのではないかということです。 実際、ターミナル上でもsource .venv/bin/activateを実行していない状態だとコマンドが見つからないというエラーが出ました。\n対処方法は？ ということで、今考えられる対処方法としては次の通りです。\n.git/hooks/pre-commitのスクリプトを修正して、\u0026lt;プロジェクトのディレクトリ\u0026gt;/.venv/binのパスを見えるようにする PyCharmで何かしらの設定を探す PyCharmではgit操作しない repo:localはあきらめて、.pre-commit-config.yamlでblackなどは管理して、pyproject.tomlからは除外する 1.ですが、.git/hooks/pre-commitはprecommit intallを実行すると自動で生成されるスクリプトです。自分の環境で書き換えたとしても他の人が同じ環境を作るときにパッチを当てるなどをしないといけなくなります。\n2.はそれらしい設定を見つけることができませんでした。\n3.はめんどくさいですよね。。。ターミナルでgitのコメントを日本語で書くためにいくつか他の設定を考えないといけないです。。。\nということで、今回は4.の対処をとりました。やりたいことは、ツールや環境をそろえるのではなく、プロジェクトでやりたいことをやることなので。。。\nまとめ 最終的には元に戻ってしまいました（pyproject.tomlに設定周りは移動した）。 Windows環境がちょっとややこしくしてるかもな？というのと、個人のプロジェクトなのでそこまで気にしなくてもいいのでは？というのもありそうです。 それにしても、世の中の皆さんはフォーマッターとかどのタイミングで動かしてるんだろう？とかどういう環境構築してるんだろう？とか気になってます。 最近だとこういうディレクトリ構造にする、こういうツールを使うと便利などあれば、コメントいただけると嬉しいです。\n教えてもらったISIDのブログ（Dev Containerを使ってステップバイステップで作るPythonアプリケーション開発環境 - ISID テックブログ）も参考にさせてもらおうと思ってるところです。Pythonの環境をコンテナに移動したいなぁというのもあるので。ただ、PyCharmだからこのブログの通りには行かないけど（VS Codeに移るのも検討したほうがいいのかなぁ）。\n参考サイト Git - Git フック pre-commit Pythonレポジトリ用のpre-commit環境を整える Dev Containerを使ってステップバイステップで作るPythonアプリケーション開発環境 - ISID テックブログ ","date":1688954148,"dir":"post/2023/","id":"698cf3cbd796161d82c9ac438ebab5d2","lang":"ja","lastmod":1688954148,"permalink":"https://blog.johtani.info/blog/2023/07/10/pre-commit-and-python/","publishdate":"2023-07-10T10:55:48+09:00","summary":"最近、趣味（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書き始めました。 きちんとPythonのプログラムをプロジェクト","tags":["python"],"title":"pre-commitとvenvとPyCharm（困ったな？）"},{"contents":"今年もこの季節がやってきました。 Berlin Buzzwordsにオンラインで出張してました。 今年もハイブリッド開催をしてくれたので、オンラインで参加できました。 現地ではブースが出たり、朝食なども用意されているようでした。今年は昨年と違いマスク必須でもなくなったようです。 MICESも去年同様、現地開催のみのようです（今見たら、昨年のビデオとスライドが公開されてるので、時間見つけてみてみよう）。\n今年はうれしいことに検索に絡むセッションが大多数でした。世の中的にChatGPTの盛り上がりやベクトル検索がいろんな検索エンジンで使えるようになってきたこともあり、 大規模言語モデルと検索エンジン、ベクトルデータベースに関する話がたくさんありました（昨年まではKafkaやストリーム処理の話も多かったんですが）。\nということで、今年もセッションを見ながら残したメモを公開しておきます。\n簡単にメモ What defines the “open” in “open AI”? セッションページ：What defines the “open” in “open AI”? 動画： Jennifer Ding - What defines the \u0026ldquo;open\u0026rdquo; in \u0026ldquo;open AI\u0026rdquo;? - YouTube \u0026ldquo;OpenAI\u0026quot;の話ではなく、オープンなAIとは？という話で、ライセンスの話であったり、コミュニティ（データセットの公開とかベンチマークの共有とか）に関する話であったり。 後半は気を抜いてしまって話をうまく聞き取れてないので、興味がある方はビデオで。。。\nVectorize Your Open Source Search Engine セッションページ：Vectorize Your Open Source Search Engine 動画： Atita Arora - Vectorize Your Open Source Search Engine - YouTube ベクトル検索が流行ってきてるけど、これまでの検索（エンジン）に対して、どうやってベクトル検索を取り入れる？という話です。 ベクトル検索ってどんなもので、どういうことの助けになりそうか？じゃあ、どうやって、これまでの検索が改善したかを見ていくのか？ という、これからベクトル検索を取り入れようとしている時にどのようなアーキテクチャにして、 どのような考慮するポイント（モデルの選択とかスケーラビリティとか）にどんなものがあるのか？といった紹介でした。 ざっくりですが、ベクトル検索やるのにどんなことをやっていけばよいのか？という地図になるようなセッションでした。\nSupercharging your transformers with synthetic query generation and lexical search セッションページ： Supercharging your transformers with synthetic query generation and lexical search 動画： Milind Shyani - Supercharging your transformers with synthetic query generation and lexical search - YouTube AWSの人の話でした。こちらもトランスフォーマーが検索に使えると便利だよねという話なのですが。 LLMを使うと高コストでサイズがどんどん大きくなっていて、小さな学習済みのモデルだといまいちな精度でだし、 ファインチューニングしたい場合、ドメインに特化したデータはなかなかないよね。とくにデータ（検索したいもの）はあるけど、クエリがないということがよくあるよね。 そこで、LLMを使って、データからクエリを作って、正解データを作り、それでファインチューニングすればいいのでは？ ということで、やってみました、どうでしたという話でした。\nブログなどもあるので参考にすると面白いかも\nThe Debate Returns (with more vectors) Which Search Engine? セッションページ：The Debate Returns (with more vectors) Which Search Engine? 動画：Charlie Hull - The Debate Returns (with more vectors) Which Search Engine? - YouTube 今年も検索エンジンの人を集めてパネルディスカッションです。今年は次の方たちが参加してディスカッションでした。\n参加者 Jo：Vespaの人。ランキングとかがよくできてるからVespa好き Alessandro：Apache Solrの人。SolrのPMCメンバー。なんでSolr？Pure OSSだし。スケーラブルだ Etienne：Weaviateの人。新しいAI nativeなベクトルデータベース Philipp：Elasticの人。 Kacper：Qdrantの人。 質問は次のようなものでした。\n最初の質問：スケールの話。スケールアウトかな？ 2つ目の質問：どんなアプリケーションが適していないか？ 3つ目の質問：どうやってAIをサポートできるの？ 4つ目の質問：どうやってコミュニティにアプローチしてる？ 5つ目の質問：自分の検索エンジンが使えない時に何を使う？ 6つ目の質問：今後に何が面白そう？ 最後の質問：あなたの検索エンジンが使われてるユースケースで一番好きなものは？ 2つ目や5つ目の質問が面白いですよね。実際の内容はぜひビデオを見ていただくのがいいかと（メモも取ったけど、聞いてもらうほうが面白そうだし）。\nWhat\u0026rsquo;s coming next with Apache Lucene? セッションページ：What\u0026rsquo;s coming next with Apache Lucene? 動画：Uwe Schindler - What\u0026rsquo;s coming next with Apache Lucene? - YouTube 毎年恒例Uweさん。今年Luceneが25周年という話で、これまでの進化の話を駆け足でしてくれました。 あとは、後半は来週9.7が出るよということで、9.7で入ってくるベクトルの距離計算の最適化に関して説明してくれています。 次のバージョンのElasticsearchでもこの最適化が使えるようになるという話もされていましたので、ベクトル検索を使ってる方は、次のバージョンも楽しみですね。\nBuilding MLOps Infrastructure at Japan\u0026rsquo;s Largest C2C E-Commerce Site セッションページ：Building MLOps Infrastructure at Japan\u0026rsquo;s Largest C2C E-Commerce Site 動画：Berlin Buzzwords 2023： Building MLOps Infrastructure at Japan\u0026rsquo;s Largest C2C E-Commerce Site - YouTube メルカリの検索システムに関係しているMLOps周りがどうやって進化してきたのか？という話でした。 英語にいらすとやの絵があるスライドがドイツで使われているのがとても新鮮ですｗ\nHighly Available Search at Shopify セッションページ：Highly Available Search at Shopify 動画：Khosrow Ebrahimpour - Highly Available Search at Shopify - YouTube Shopifyの検索プラットフォームチームの人の、Shopifyの検索プラットフォームがどういったものか？（EsとKafka使ってる）どんな工夫をしているか？という話です。 Kubeconでも他の同僚の方が話をされている見たいで、そちらも参考になるとのことでした（動画）。 スキーマ変更時の話とかもあり、実践的でした。最後に将来的な話でやはりベクトル検索というキーワードが出てきていました。あとは、データ量が大きいのでスケーリングの挑戦もあるとのこと。\nUsing Dense Vector search at the EU Publications Office セッションページ：Using Dense Vector search at the EU Publications Office 動画：Martin Bayton - Using Dense Vector search at the EU Publications Office - YouTube EUのPublication Office（日本だと公文書館とかになるのかなぁ？）の検索サービスで、Googleみたいなこと（検索結果の上にスニペットが出たり、そこにハイライトされたり）をやってみたいよね？という話みたいでした。実際公開してるかはわからないですが、途中からはPureinsightsという会社のプラットフォームで似たようなことをやるデモになってました。\nGoogleでも12%のクエリが、質問の自然文になっているという話で、検索結果にナレッジグラフからの情報（スニペットとか、質問に対する答えとか、地図とか）が出るようになってきていますと。 それをPublication Officeのデータで再現したデモを行った後に、どんな感じのアーキテクチャなのか？という概略を説明されています。国会図書館とかの検索サービスやってる方が興味を持ったりするかもなーと思ったり、思わなかったり？\nLearning to hybrid search セッションページ：Learning to hybrid search 動画：Berlin Buzzwords 2023： Learning to hybrid search - YouTube これまたキーワード検索とセマンティック検索のハイブリッドの話です。 よくハイブリッド検索というのを聞きますが、データだったりベンチマークなどの話があまりないですよね？昨年AmazonがECSIというデータセットを公開したりしています（rejasupotaroさんが年末に書かれた記事にも出てきていました）。 これにLearn to Rankとかもテストできるようなデータ（レビューや評価、カテゴリーとか）を拡張したものを作って、それをもとにいろいろとハイブリッド検索で精度を測ってみたというお話でした。 Metarankというリランキングエンジンの会社の方たちで、Metarankを使ってハイブリッドな検索結果のリランキングで精度がどのように上げられるか？という話です。 今年のTRECのProduct Search Trackの話もされていました。 これが元ネタのブログかな？\nCatch the fraud — with observability and analytics セッションページ：Catch the fraud — with observability and analytics 動画：まだ？ 最後は元同僚のセッションです。こちらは検索ではなく、ちょっと自虐的なネタをもとにしたオブザバビリティおよび分析のお話です。 コミュニティの人たちの貢献（ブログ書いたりプルリク送ったり、どこかで話をしたり）を計測して、年間の貢献者に対してプレゼントを上げるというのをやっているみたいです。 で、昨年の最も貢献した人にMac Bookをプレゼントするというすばらしい（暴挙）話で、チートしようとした人がいてそれを分析した話でしたｗ 締め切り直前に信じられない量の貢献したという登録がブラジルからあり、何かおかしいよね？ということで、Elastic Stackのオブザバビリティの機能などを元に分析してチートした人を除外していったよという話でした。 Kibanaが使いやすくなってるのがわかるセッションで面白かったです。\nまとめ 検索がまたすごく盛り上がってきたなーという時間があるカンファレンスでした。みんな似たような話（ベクトル検索、LLM、AIなど）だったりしますが、 知らないプロダクトで興味が出てくるものもあったし、Amazonのデータセットがあるからいろいろ試してみることもできそうだなぁと。\nすでにビデオが公開されはじめているので、気になったセッションのビデオも見てから後日またブログを書こうとおもいます （たぶん、一覧が作成されるので後日リンクを貼っておきます）。\n来年の予定（6月11日から開催）も公開されていましたし。来年も楽しみですね。 来年はプロダクションでベクトル検索やってみた話とかがさらに出てくるのかなぁ？\n","date":1687278645,"dir":"post/2023/","id":"9335522f4c8dbc7256a42a091e6e00bc","lang":"ja","lastmod":1687278645,"permalink":"https://blog.johtani.info/blog/2023/06/21/attend-berlin-buzzwords-2023/","publishdate":"2023-06-21T01:30:45+09:00","summary":"今年もこの季節がやってきました。 Berlin Buzzwordsにオンラインで出張してました。 今年もハイブリッド開催をしてくれたので、オンラインで参加で","tags":["conference","belin buzzwords"],"title":"今年もオンラインでBerlin Buzzwordsに参加した"},{"contents":"今年もなんとか振り返りブログを書いてます（時間大丈夫かな？w）。紅白をリアタイで見ながら。\n振り返り（2021年に書いた抱負から） まずは振り返りをと。\nフリーランス継続 ありがたいことに個人事業主として今年も１年乗り越えられました。 ZOZOさんには引き続きお世話になっている感じです。 10月からは今月末まで別のお客さんを手伝っていたりという感じでした（アップグレードの手伝いとか）。 相変わらず完全リモートで作業をさせていただいてます。\nただ、来年は今の所、余力がある感じになっているので、新しい仕事を見つけたいところだなあという感じです。 検索で何かお手伝いできることあれば、気軽にお声がけいただければと。\nプログラミング Linderaの大須賀さんのおかげで、レビューは定期的にやらせていただいてますw 業務がっつりというほどではないのですが、検証用のコードを書いたりはしています。\n個人用では、BGM環境のためにシェルを書いたり、文字化けしてるデータを解析したりするのにコードを書いてますが、もうちょっと量を増やしたいところです。 コードがっつり書く仕事をやらせてもらうのとかやらせてもらうのがいいかもなぁ。\n書くよりもどうしても読むほうが多くなってる気がします。\nブッチャー本ちゃんと読む 全部ではないですが、ZOZOさんで輪読をしたりしていました。 が、自分で全部読むといったところまではできてないです。\n読んだ本のブログを書く これはできてないですね。 読むのはちょとちゃってるんですが、ブログを書くところまではできてない。 メモとりながら読みたいですね。\n振り返り(今年あったできごと) ここからは今年の出来事を。 今年もずっと自宅で仕事した。来年は出張とかできるのかなあ？\n自宅環境 今年もDIY 検索ペンギン本が出版された 仕事場を模様替えしました。 今年もずっとWindows環境をメインで仕事をしていました。 年末まではM1 Macを借りて作業するという経験もできたのでよかったです。 今年仕事の環境は少し変わって、AVアンプ（譲り受けたもの）＋Polk Audioのスピーカーで音が良くなりましたw あと、机の天板を大きくして、作業がやりやすくなりました。写真はそのうち。\n仕事場の模様替えにもなるのですが、今年のDIYはラブリコ＋有孔ボードでケーブルやキーボードをすっきり片付けられる環境を作ってみました。 壁を有効活用できるのはよかったです。こちらについては、別途ブログを書こうと思います。\n今年最大のニュースは検索ペンギン本を出版したことです。 声をかけていただいた打田さんには感謝です。著者の皆さん検索システムを色々と手掛けられているので良い本になったと思います。\n『検索システム ― 実務者のための開発改善ガイドブック』 – 技術書出版と販売のラムダノート おー、届いたー pic.twitter.com/RbY5tOe9GB\n\u0026mdash; Jun Ohtani (@johtani) May 17, 2022 いろんなところで輪読も開催されているようで、顔を出してみたいなぁ。 輪読やってます！外部の人を呼んでもOKという方がいたら、参加してみたいのでTwitterでメンションしてもらえると嬉しいです。\n来年の抱負 ということで、来年の抱負です。\nフリーランス継続 プログラミング ベクトル検索まわりをさわる 本を読む 今年もありがたいことに仕事を継続していただけて、乗り越えられました。 来年も価値を提供できるように頑張っていきます。 もっといろんな会社の検索システムを見てみたいですし、検索エンジン入れてみたけどここからどうすればいい？という方も増えて来ているような気がするので、気軽に声をかけていただければと。\nプログラミングは、家の音楽ファイルの文字化けを直すプログラムをもう少しちゃんと書いてからブログを書きたいなと。まぁ、個人的なプログラムなので誰も嬉しくないかもですが（色々検討した結果Javaで書いてる）。 あとは、オライリーさんの初めてのGo言語を買ったのもあるので、前にRustで書いたElasticsearchへのBulk登録のツールをGoで書いてみようかなと考えているところです。みんなはデータ登録するときはどうしてるんだろう？\nNLPでBERTなどによる目まぐるしい進歩の影響もあり、ベクトル検索やセマンティック検索といった検索技術が各社から出て来ています。 ElasticsearchでもGAされたのもあり、今後ますます注目を浴びる技術になるのだろうなと。 ただ、これまでの検索とどう組み合わせるのがいいのか？どう言ったメリットデメリットがあるのか？向き不向きは？といったものもあるので、仕組みを調べながら色々と試行錯誤してみたいと思っています。\nさいごは、毎年書いてる気もしますが、本を読むのもやらんとなぁ。 あたらしいネタを仕入れては実践できる時間もとりつつ、他のことにも目を向けたいと思っています。\n今年は仕事の変化も少し出て来ているので、来年は新しいことをいくつかやってみたいところです。 あとは、外に出る機会が増やせるといいなぁ、少しずつ人から刺激をもらいたいと思っています。\nさて、今年は年内に無事描き終わりました。 来年もよろしくお願いいたします、良い年にしたいなー。\n","date":1672486684,"dir":"post/2022/","id":"df30d810068e4656498e5972c6de7e3d","lang":"ja","lastmod":1672486684,"permalink":"https://blog.johtani.info/blog/2022/12/31/review-2022/","publishdate":"2022-12-31T20:38:04+09:00","summary":"今年もなんとか振り返りブログを書いてます（時間大丈夫かな？w）。紅白をリアタイで見ながら。 振り返り（2021年に書いた抱負から） まずは振り返","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2022）"},{"contents":"PySpaアドベントカレンダーの12/15のエントリーです。昨日はtaichiさんでした。 今年はDIYではなく、PCにまつわる話を。\n仕事中はBGMが基本 フリーランスを始めて（2020年初頭）からすぐに、自宅で仕事をする情勢になりました。 打合せをしていないとき、カンファレンスの発表などの動画を見ていないときは基本的にBGMをかけて作業をしています。 音源としては、CDなどから音楽ファイルにしたり、AmazonやSonyのサイトで購入した音楽ファイルなどがNASにあります。\n今年10月までの環境 2020年の後半に次のような環境を構築して今年の10月まで使っていました。\nLibreELECをラズパイ4に入れて、Kodiのリモコンをスマホに入れたら快適になった\n\u0026mdash; Jun Ohtani (@johtani) October 20, 2020 KODIと呼ばれるマルチメディアセンター？のようなソフトで、それを動かす最小限のOSとして、LibreELECが公開されています。 これをラズパイ4に入れて、NASからファイルをSSDにコピーしてそれをラズパイに接続して音楽を聞いていました。 毎回ラズパイの画面を見に行くのも面倒なので、再生などの操作にはAndroid用のKodiのリモコンアプリを使っていました。\n場所も取らないのでよかったのですが、使っているといくつか問題点が。\n時々調子悪（音が出ない、リモコンからつながらない、無反応など）くなって、ラズパイ再起動 音楽ファイルを購入して増えた時に、外付けSSDを取り外してPCでコピーしたり スマホじゃないと再生できない（PCのクライアントもあったのかもだけど調べてなかった） Ubuntu on Mac mini 10月に模様替えをして、2012年製のMac Miniが宙ぶらりんになりました。 さすがに古いしメインマシンがWindowsになっているのもあり、macOSである必要も特にないので、Ubuntu 22.04を入れて何かに使えるのでは？と。 また、1TBのSSDに内臓ディスクを乗せ換えていたのもあり、音楽再生に使ってみようということに。 なので、Kodiの環境で困っていた点も考慮して、ほしい機能を元にちょっと探してみました。\n音楽再生 on Ubuntu 音楽再生でほしい要件としては次のようなものです。\nUbuntuで音楽再生できるソフト（あたりまえ） PCから操作したい（できればブラウザ） 音楽ファイルの更新（ローカルでもいいけどNASからもってきたり） 日本語の曲情報も表示 対象音楽ファイルが豊富（そんなに制限があるものはないだろうなぁ） 上記の要件をもとに適当にググって見つけてきたのがOwnToneというソフトでした。\nOwnTone OwnToneの説明は公式サイトを見ていただくとして、OwnToneにしてよかったなというのが以下の点です。\nインストールが簡単（apt-getでインストールできる） サポートフォーマットが豊富 Web UIがついてる（ブラウザで見えるし、スマホでもOK。どのブラウザから見ても今の状況も分かる） 簡単だけど検索できる プレイリスト対応（ファイルパスを入れるだけ） サムネイルとかも出てくる（どうやってんだろう？ｗ） AirPlayで再生できる（AVアンプを利用しており、そこにAirPlayで再生できてる） OSS（まだソースは見たことないですがｗ） 再生画面例\nやっぱ検索も気になるよね？\n日本語も検索できるな。 pic.twitter.com/EF6WHkJKli\n\u0026mdash; Jun Ohtani (@johtani) October 19, 2022 とりあえず、インストールして画面もすぐに出て操作も簡単で、便利な世の中になったなーと感動しましたｗ\nただ、音がヘッドフォン端子に刺したアナログ出力先のスピーカーではなく、本体のスピーカーで最初はなってしまいましたｗｗ Linuxの音周りが全然わかってない問題が発覚。\n幸い、先週のPyspa Advent Calendarのエントリーを書いていたaodag先生に助言をいただき、alsamixerで音の設定を見たところ、ヘッドフォン端子がミュートされていたので、ミュートを外して無事再生できました。 インストール当初はYAMAHAのアクティブスピーカーにJust Mixer経由でヘッドフォン端子（アナログ）で出力して音楽再生をしていました。 今は（この記事を書いてる現時点で）、AVアンプのAirPlayにOwnToneから音を流している形で聞いています（便利なんだけど、当初の想定とは異なる、理由は後述）。\nファイルのコピーとか さて、上にも書きましたが、NASにバックアップもかねて音楽ファイルを保存してあります。 新しく買ったファイルもここに置くようになっています。 OwnToneのMac MiniからNASをネットワーク経由で見に行くのもいいのですが、できればローカルにあったほうがネットに影響も出ないなと。\nということで、定期的にNASをウォッチしてMac Miniにファイルをコピーするようなプログラム（Bashスクリプト）を書いてみました。 毎回購入後に手で実行もめんどくさいので毎日夜中にcron実行するような設定になっています。\nスクリプトの中身は次のような感じです。\nfindコマンドで特定の日時（最近コピーしたファイルの日付）以降(-newermtオプション)のファイルのリスト（音楽ファイルの拡張子に限定）を取得 取得したリストをもとに以下の操作 ファイルをコピー コピーしたファイルをコピーした日付のプレイリストを作って入れる（プレイリストはパスだけ書けばOK） mp4形式だと聞けない端末もあるので、soundconverterコマンドでmp3に変換してNASに戻す 最新のファイルの日付を保存（次回のfindコマンド） ファイルがあったら、OwnToneの再読み込みのエンドポイントをcurlでキック NASはSambaでマウントして、見えるようにしてあります。 やっぱり、自動化便利ですねぇ。 気に入った曲を買ってNASに入れとけば聞けるようになるのは本当に便利。\n他にもスマートプレイリストとかもあるので、活用しないとな。\n今後の課題 さて、すごく便利になったのですが、課題も残っています。\n音声出力問題 アナログ出力はaodag先生の助言ですぐに解決したのですが、takabowから譲り受けたAVアンプを導入してから実は音の出力がうまくいっていません。\nHDMI、光端子出力でAVアンプにつなごうとしたのですが、私のUbuntu力（Linux力？）が全然不足しているのでうまくいっていません。ググりつつ、HDMI、光出力でamixerというコマンドで音声ファイルを鳴らすところまでは行ったのですが、OwnToneに設定するとうまくいかない状況です。 結局、解決してないのですが、AVアンプのAirPlayのレシーバー経由で音楽再生ができてしまったので、とりあえずAirPlayで運用することにしました。時間を見つけてaodag先生の記事を読み直して再チャレンジしないとな（けど、鳴ってるしなぁ、音ｗ）。\n文字化け問題 これは、OwnToneというよりはもともとあった問題です。 古い音楽ファイルだったり、Wav形式のファイルなど、様々な形式のファイルを持っています。 音楽サーバーとは別に、音楽ファイルの検索をできるようにしつつ、付加的な情報（Wikimediaなどのデータとか）を付与して、検索できるようにしてみようと思い、音楽ファイルからメタデータを抜き出して、ElasticのApp Searchにいれるデータを作るツールを書いたりしています。 この時にも文字化けに遭遇しました。\n様々な音楽ファイルにはメタデータを付与することができる仕様が決まっています（ID3タグ - Wikipediaなど）。 ただ、文字コードの情報が入っていなかったり、デフォルトとは違う文字コードでデータを付与したファイルがあったり、いろいろな原因で文字化けしているものがあります。 昨年Amazonで購入したmp3の中にも文字化けしているものもあったりします。Wavファイルに付与されたタグなどは、容赦なくShift-JISだったりしますが、読み込むソフトはUTF-8で読もうとしたり。。。\n検索サーバーにデータを抜き出して入れるツールを書いているときは、元のファイルを変更することなく、抜き出す時点でいくつかの文字化けに対応した処理を書いたのですが、今回のOwnToneで曲を流すと結局、元のファイルをきれいにしないとダメだということに気づきました（すぐわかるだろ。。。）\nということで、書いている途中のツールをもとに、根本的な文字化けのファイルのメタデータをきれいにするプログラムを書かないといけないなぁと。\nちなみに、メタデータの抜き出しにはJavaでプログラムを書いており、JAudiotaggerというライブラリを利用しています。 Pythonや他のJavaのライブラリを試そうとしたのですが、文字コードが決め打ちで抜かれているものが多く、ライブラリから読みだした時点ですでにどうしようもない状態のものが多いといった問題からこのライブラリにたどり着きました（まぁ、まだちゃんとしたものができていないんですけどね）。\n検索サーバー OwnToneのUIはブラウザでうごきます。 検索窓もついています。 が、先ほども書いたように、他にもデータを追加して、いろんな検索をしてみたいなぁと（ドラマに使われてたとか、CMにつかわれてたとかとか）。 検索が好きでいろいろとやってるので、その辺も遊んでみたいなぁと思っているところです（実際、ElasticのApp SearchにWikidataから生成した類義語を入れてみたりしている）。\nこうやってブログにしてしまったので、課題をつぶしていなかったら、Twitterなどでつついてくださいｗ\nまとめ 構成図とかは書かなかったですが、OwnToneを使うと簡単にWeb UIが入った音楽サーバーが使えるようになって、仕事がはかどりますよという記事でした。 他にもこれに関するネタを募集してますので、コメントもらえるとうれしいです（Twitterでメンションも大歓迎）。\n","date":1671030358,"dir":"post/2022/","id":"67c2ae6761e89be0fa66db9623b40d30","lang":"ja","lastmod":1671030358,"permalink":"https://blog.johtani.info/blog/2022/12/15/music-server-on-mac-mini/","publishdate":"2022-12-15T00:05:58+09:00","summary":"PySpaアドベントカレンダーの12/15のエントリーです。昨日はtaichiさんでした。 今年はDIYではなく、PCにまつわる話を。 仕事中は","tags":["misc","music"],"title":"仕事中のBGM環境"},{"contents":"本記事は情報検索・検索技術 Advent Calendar 2022の9日目の記事です。\nだいぶ間が空いてしまいましたが、日本語のオートコンプリートに関する記事の続きです。 という感じで、Suggesterのデータ構造とか仕組みを書こうと思っていたのですが、思ったよりも調べないといけないことが多くて挫折しました。。。 （これの続きは年末年始で調べて書くはず？）\nということで、代わりにElasticsearch/OpenSearchのアーキテクチャの変更に関してさらっとまとめてお茶を濁してみようと思います。\n発端はElasticON Tokyo？ 先週の11月30日に、ElasticのオフラインイベントであるElasticON Tokyoが開催され参加しました。 参加しようと思ったのは、10月の頭にElasticのブログで公開された「Stateless — your new state of find with Elasticsearch」というアーキテクチャの変更がきっかけです。\n（図はElasticのブログから引用）\nElasticsearchはLuceneのインデックスを分散したシステムとしてスケールアウトできるようにするという目的でリリースされました。 インデックスをシャードという単位で複数のElasticsearchのノードにデータを保存し、レプリカを作ることで分散する仕組みを実装していました。 Elasticsearchでは、インデックスのレプリカは、作成したインデックスを定期的にコピーするのではなく、登録するデータがElasticsearchのクラスターにやってきた時に、 データ自体をコピー先にも配り、プライマリーやレプリカとなるシャードがあるノード上でそれぞれインデックスに登録する処理を行うという処理の流れです（古いけど、わかりやすい説明はこちら）。 この場合、インデックスにデータを登録する処理（転置インデックスのデータ構造に変換する処理など）は、レプリカの数だけ同じ処理がクラスター上で発生します。\nこの基本的なアーキテクチャをもとに、保持するデータの鮮度（新しいデータのほうが検索頻度が高い、インデックス登録する時はマシンは多く、古くなったデータが入ったインデックスはコストが低いマシンになど）などを元に、クラスター内のノードの特性を異なるものが混在するような複雑な仕組みを作ってきました。 いろいろなデータの持ち方などで多くのデータなどを保持できるようにしてきたのですが、クラスター全体としては、検索の負荷のピークをさばけるような構成を基本的に保持しておくというかんがえです。\nただ、昨今は必要に応じてスケールアウト（リクエストが増えたりデータ量が増えた時）、スケールイン（夜中は利用者が少ないからクラスターを小さくしたい時）できるような仕組みのほうが求められています。 そこで、発表されたのが上記のブログであり、上図の新しいアーキテクチャです。 計算処理（データを登録、検索する処理）とストレージを分離し、さらに登録する処理と検索する処理も分離した構成です。 このようなアーキテクチャにすることで、登録処理の演算コストがレプリカごとに必要ではなくなり、検索の部分だけだったり、登録の部分だけをスケールアウト・インできるような自由度が手に入ります。 また、ストレージ部分でレプリカを担保（S3とかのオブジェクトストレージで冗長性を担保）できれば、レプリカのストレージコストも必要なくなります。\nというブログが発表されたのですが、詳細などはまだよくわからなかったのでElasticON Tokyoに参加して詳しい話が聞けるのかなぁと期待していました。\n参加当日の朝のびっくりするニュース 11月30日の朝に起きて、出かけようかと思っていたところに、AWSのre:Inventで発表されたニュースが舞い込んできました。\nほー（まだタイトルしか読んでない）https://t.co/KK22duaBNH\n\u0026mdash; Jun Ohtani (@johtani) November 29, 2022 Amazon OpenSearchがServerlessオプションを発表というニュースです。 （Amazon OpenSearchとは、AWSがElasticsearchをフォークして始めた検索エンジンで、Amazon OpenSearch Serviceというのは、AWSがそれをSaaSとして提供しているものです）\nまぁ、気になりますよね、「Serverless」ってキーワードに。 ElasticON Tokyoに向かう電車でブログを読んだり、どんな仕組みかを調べたので、それを簡単にまとめておきます。\nプレビュー段階（Tokyoリージョンではもう試せる） これまでのAmazon OpenSearch Serviceとは別（オンザフライで移行はできない？） 「コレクション」という単位でクラスターを管理（スケールインとかアウトとか） コレクションにはタイプがあり、タイムシリーズ（ログとか）か検索のユースケースなのかで使い分ける（公式ドキュメント） インデックス処理と検索処理で計算ユニット（OCU）が別々にスケールできる（下図） 作成されたインデックスはAmazon S3に保存され、そこで冗長性は担保される。（下図） 検索処理のユニットはS3のデータをローカルに持ってきて処理をできる データ登録とかのAPIは基本的にServerlessかどうかで違いはなさそう(これまで通りのクライアントでアクセスとかで競う) 設定した範囲でいいかんじにスケールアウトインしてくれそう（ほんとかな？） もちろん、いくつか制限がある（サポートしてないプラグインとか操作もある） （図はAWSのドキュメントより引用）\n発表時のブログでは詳しくはわからないのですが、公式ドキュメントではさらに詳しく説明がありました。 こちらを読むほうが仕組みがわかると思います。 今後もどんどんドキュメントは充実していくんだろうなと。今ならまだサクッと読める量ですｗ\nただ、「サーバーレス」という定義が私はよくわかりませんでした。 公式ドキュメントを読むとコレクションを作ると少なくとも4つのOCUが起動しているみたいで課金されると記載があります。\nまぁ、Elasticの発表と同様に、これまでは最大負荷の時を元にクラスターを維持せずとも、より柔軟に検索だけ、登録処理だけを一時的にスケールできるとコストを下げられそうですね。 すぐに誰かが使ってみたブログなどを出してくれると思うので、細かな使用感などはそのうちわかってくるかと。\n今後は？ ElasticもAWSも考え方の基本となっているのは、Berlin BuzzwordsでAmazonのMikeさん（Luceneのコミッター）が2019年に発表されたものだと思っています。 アーキテクチャの変更がどんな影響が出るかはわからないですが、少なくとも検索のユースケースでよりスケールアウトしやすくなるだろうなと。 どちらもSaaSとしての仕組みとして提供するので、検索エンジンそのものの機能として公開されるかはわからないです。 ですが、そのほかの検索エンジンも出てきていますし、今後も検索エンジンから目をはなせないです。 今回は残念ながら触っていませんが、時間を見つけて使ってみたいです（Elasticも早く出してくれないかなー）\nということで、当初の予定とは違うブログになってしまいました。。。 技術的な深い話はまたどこかで。。。\n参考文献 Stateless — your new state of find with Elasticsearch | Elastic Blog Preview： Amazon OpenSearch Serverless – Run Search and Analytics Workloads without Managing Clusters | AWS News Blog Berlin Buzzwords 2019： Michael Sokolov \u0026amp; Mike McCandless–E-Commerce search at scale on Apache Lucene - YouTube ","date":1670516125,"dir":"post/2022/","id":"9693a1e77dee5785b1dc61ccffd2e906","lang":"ja","lastmod":1670516125,"permalink":"https://blog.johtani.info/blog/2022/12/09/open-search-serverless/","publishdate":"2022-12-09T01:15:25+09:00","summary":"本記事は情報検索・検索技術 Advent Calendar 2022の9日目の記事です。 だいぶ間が空いてしまいましたが、日本語のオートコンプリートに関する記事の続きです。","tags":["elasticsearch","opensearch"],"title":"ElasticsearchのアーキテクチャとStateless / Serverless"},{"contents":"前回は日本語用オートコンプリートのためのAnalyzerとして、どうやって使うのかを簡単に紹介しました。\n今回はもう少し、いろんなパターンを試してみたいと思います。\nローマ字入力のゆれ 前回のサンプルでも「吾輩\u0026hellip;」のデータをサジェストするためのサンプルとして、「wagah」という「わがはい」をローマ字にしたものを利用しました。\nちなみにローマ字というとどんなものを思い起こしますか？ 普通は学校で習ったヘボン式あたりだと思います。 Kuromojiの読みでローマ字出力するには通常、kuromoji_readingformでuse_romajiをtrueにします。 以下、「吾輩」のサンプルです。\nGET _analyze { \u0026#34;text\u0026#34;: [\u0026#34;吾輩\u0026#34;], \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji_tokenizer\u0026#34;, \u0026#34;filter\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;kuromoji_readingform\u0026#34;, \u0026#34;use_romaji\u0026#34;: true } ] } レスポンス { \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;wagahai\u0026#34;, \u0026#34;start_offset\u0026#34;: 0, \u0026#34;end_offset\u0026#34;: 2, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 0 } ] } 「吾輩」の場合は特に問題ないのですが、ローマ字による日本語入力の場合、次のような単語を入力するときに、ゆれが生じます。\nシャボン＝「shabon」 新橋＝「shimbashi」 括弧内はkuromoji_readingformで出力したもの（＝ヘボン式のローマ字）です。 ですが、ローマ字入力の場合は「syabon」や「shabon」と入力したり、「sinbasi」や「sinnbasi」と入力すると思います。 JapaneseCompletionAnalyzerを利用したCompletion Suggesterの場合、これらのゆれも考慮してサジェストしてくれるようになっています。 前回のサンプルデータを用いると次のような感じです。\nGET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;sha\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } } } GET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;sya\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } } } これらのリクエストは、「しゃ」について2パターンになっていますが、結果はどちらも次のものが返ってきます（このレスはsyaのレスになります）。\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;sya\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 3, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;シャドウ・ワーク\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;000739\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;シャドウ・ワーク\u0026#34;, \u0026#34;朝倉 克彦\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;シャボン玉\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;045054\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;シャボン玉\u0026#34;, \u0026#34;豊島 与志雄\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;上海\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;050899\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;上海\u0026#34;, \u0026#34;横光 利一\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;斜坑\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;002095\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;斜坑\u0026#34;, \u0026#34;夢野 久作\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;社会事情と科学的精神\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;053864\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;社会事情と科学的精神\u0026#34;, \u0026#34;石原 純\u0026#34; ] } } ] } ] } } 「sinnba」や「shinba」も試してみました。\nGET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;sinnba\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } }, \u0026#34;_source\u0026#34;: [\u0026#34;suggest_ja\u0026#34;] } GET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;shinba\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } }, \u0026#34;_source\u0026#34;: [\u0026#34;suggest_ja\u0026#34;] } これらも同じ結果です。\n{ \u0026#34;took\u0026#34;: 0, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;shinba\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 6, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;しんばい\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;044942\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;しんばい\u0026#34;, \u0026#34;村山 籌子\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;新橋\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;002409\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;新橋\u0026#34;, \u0026#34;北原 白秋\u0026#34; ] } } ] } ] } } 入力されるパターンを想定した実装がされているので対応できている形です。 使い方が楽なだけでなく、より使いやすくなってるのは便利ですね。\nうまくいかないパターン 万事OKかというと残念ながらそうでもありません。 うまくいかないパターンもあります（これが本当にうまくいかないかは難しい話な気がしますが）。 「日本」という漢字ですが、「にほん」「にっぽん」どちらとも読めますよね？ これらを試してみると次のようになります（リクエストは省略します）。\nまず「にほん」\n{ \u0026#34;took\u0026#34;: 0, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;にほん\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 3, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;日本橋\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;004565\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本橋\u0026#34;, \u0026#34;泉 鏡花\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本橋\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;045357\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本橋\u0026#34;, \u0026#34;牧野 信一\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本橋あたり\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;047648\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本橋あたり\u0026#34;, \u0026#34;長谷川 時雨\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本橋附近\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;055666\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本橋附近\u0026#34;, \u0026#34;田山 花袋\u0026#34; ] } } ] } ] } } 次に「にっぽん」\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;にっぽん\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 4, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;日本アルプスの五仙境\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;056269\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本アルプスの五仙境\u0026#34;, \u0026#34;木暮 理太郎\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本出版協会論\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;049436\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本出版協会論\u0026#34;, \u0026#34;嶋中 雄作\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化と科学的思想\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;055750\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化と科学的思想\u0026#34;, \u0026#34;石原 純\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化のために\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;003183\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化のために\u0026#34;, \u0026#34;宮本 百合子\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化の特殊性\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;055290\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化の特殊性\u0026#34;, \u0026#34;戸坂 潤\u0026#34; ] } } ] } ] } } 最後に「日本」\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;日本\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 2, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;日本アルプスの五仙境\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;056269\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本アルプスの五仙境\u0026#34;, \u0026#34;木暮 理太郎\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本出版協会論\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;049436\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本出版協会論\u0026#34;, \u0026#34;嶋中 雄作\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化とは何ぞや（其二）\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;002940\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化とは何ぞや（其二）\u0026#34;, \u0026#34;内藤 湖南\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化と科学的思想\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;055750\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化と科学的思想\u0026#34;, \u0026#34;石原 純\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化のために\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;003183\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化のために\u0026#34;, \u0026#34;宮本 百合子\u0026#34; ] } } ] } ] } } 最初の「にほん」は「日本橋」がヒットしているようです。返ってきたoptionsの数は4件しかなく、どうやらこれがすべてのようです（取得件数はデフォルト5件）。 2番目の「にっぽん」は「日本」という単語から始まるものがヒットしていますが、「日本橋」はなさそうでした。 最後に「日本」という漢字を入力にした場合は2つの合計が帰ってきているようです（今回のレスポンス例にはありませんが、サイズを大きくすると「日本橋」が帰ってきていました）。\nどうしてそうなるの？ JapaneseCompletionAnalyzerの基本的な動作としては、\nKuromojiが単語に区切る 区切られた単語ごとに読みを持っている 元の単語と読みをローマ字にしたものが最終的に出てくる というような動きです。 この時、単語には「1つ」の読みが対応しています。 読みから単語を探そうとすると、読みの違い（ゆれ）を吸収することはできないためです。 JapaneseCompletionAanlyzerは3点目のローマ字のゆれに対応していますが、入力となる読みのゆれまでは対応できないです。 対応しているといいかどうかというのも難しい判断になる気もします。。。\nそのほかの例としては次のようなものもあります。 これは、今回のオートコンプリートの話とは少しずれてるかもしれませんが、1番目の処理の結果が変わってくる例です。 「南方熊楠」という名前の間にスペースがあるかないかで、出力される読みが変わってくる例です。\nGET _analyze { \u0026#34;text\u0026#34;: [\u0026#34;南方 熊楠\u0026#34;], \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji_tokenizer\u0026#34;, \u0026#34;filter\u0026#34;: [\u0026#34;kuromoji_readingform\u0026#34;] } GET _analyze { \u0026#34;text\u0026#34;: [\u0026#34;南方熊楠\u0026#34;], \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji_tokenizer\u0026#34;, \u0026#34;filter\u0026#34;: [\u0026#34;kuromoji_readingform\u0026#34;] } # GET _analyze { \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;ナンポウ\u0026#34;, \u0026#34;start_offset\u0026#34;: 0, \u0026#34;end_offset\u0026#34;: 2, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;クマグス\u0026#34;, \u0026#34;start_offset\u0026#34;: 3, \u0026#34;end_offset\u0026#34;: 5, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 1 } ] } # GET _analyze { \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;ミナカタ\u0026#34;, \u0026#34;start_offset\u0026#34;: 0, \u0026#34;end_offset\u0026#34;: 2, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;クマグス\u0026#34;, \u0026#34;start_offset\u0026#34;: 2, \u0026#34;end_offset\u0026#34;: 4, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 1 } ] } 人名や地名は1つの漢字に対して多くの読みが存在しているので大変です。。。 どうしてこれは出てこないんだろう？と不思議に思った場合は、_analyze APIを使ってどういう動きなのかを見てみるのがいいかと。\nまとめ ということで、少しだけですが、こんなことができるよ、できないよというのを書いてみました。 挙動をしっていれば、なんでこうなってるんだっけ？といったことを調べる役に立つかと思います。 入力された文字をもとにどれをサジェストするかなどについてはもう少し違う動きなので、中の仕組みをそろそろ書かないとなぁ。\n参考 同形異音語 - Wikipedia ","date":1660099802,"dir":"post/2022/","id":"73279888a8fe482c836fb19ca23318dc","lang":"ja","lastmod":1660099802,"permalink":"https://blog.johtani.info/blog/2022/08/10/jp-auto-completion-2/","publishdate":"2022-08-10T11:50:02+09:00","summary":"前回は日本語用オートコンプリートのためのAnalyzerとして、どうやって使うのかを簡単に紹介しました。 今回はもう少し、いろんなパターンを試","tags":["elasticsearch","lucene"],"title":"ローマ字入力のゆれと読み（JapaneseCompletionAnalyzerその2）"},{"contents":"風のうわさで、日本語用のオートコンプリートのためのTokenFilterとAnalyzerがLuceneに取り込まれたと聞きました（LUCENE-10102）。 Elasticsearchでも使えるかなぁ？ということで調べたところ（調べた？聞いた？）、どうやら8.1から利用できるようになっている（GitHub Issue #81858）みたいです（まだ、公式ドキュメントには記載がないのですが）。\n8/17追記\n作者の打田さんがブログ書いてたの見落としてた（もしくは見たけど忘れてた）ので貼っておきます。マルチテナンシー下での Query Auto Completion 設計・運用戦略 - LegalForce Engineering Blog\nということで、こんな感じで使えるよというのを試してみました。\nどういうもの？ 日本語入力方法を考慮したオートコンプリート用のトークンを生成してくれるTokenFilterと、 それをLuceneのSuggesterで動くようにしたAnalyzerが用意されています。 Elasticsearchでは、Kuromojiプラグインにそれらを使えるようになっています（バージョン8.1.0以降）。 KuromojiTokenizerと一緒に利用する前提の仕組みとなります。\nオートコンプリートとは？ 検索窓などでキー入力をしていると、入力した文字で始まる単語の一覧が現れることがあると思います。 あの機能がオートコンプリートと呼ばれるものです。search-as-you-typeとも呼ばれることもあります。 （検索ペンギン本にも書いてあるので興味のある方はぜひ！（ステマ）） 入力された文字列を含むパターンもありますが、今回紹介するものは入力された文字で始まる単語を見つけてくる機能になります。\n何がなんで追加されたの？ 日本語の入力方法は、かな入力の人もいればローマ字入力の人もいます。 ですので、オートコンプリートでの入力として、「しゃ」という入力が来る場合もあれば、「sha」というローマ字入力途中のものが来る場合もあります。 これらを考慮したトークンの扱いができるように、 JapaneseCompletionFilterというクラスが追加されています。 内部的にはKuromojiTokenizerでトークンに分割された後に、もともとのトークンと同じポジションで読みをローマ字にしたものを出力します。 JapaneseCompletionAnalyzerは上記Filterをすぐに使えるようにしたAnalyzerです。\n動かし方 百聞は一見に如かずということで、Elasticsearchでの使い方を見たほうが分かりやすいので、簡単に動かしてみることにします。\nインストールとインデックスの用意 Elasticsearch（8.1以上）とKuromojiのプラグインをインストールします（今回試したのは8.3.1）。\nサンプルデータ なにかいいデータはないものか？と思っていたところ夏休みだというのを思い出しました。 夏休みといえば読書感想文だ、ということで、書籍のタイトルがいいかもなと。 青空文庫の著者名と書籍のタイトルの一覧を見つけたのでそちらのデータを使って試してみました。\nCSV to JSON CSVファイルは最後の参考にある青空文庫のページから、「公開中　作家別作品一覧：全て(CSV形式、zip圧縮）」をダウンロードしたものを利用しました。 CSVファイルだったので、jqコマンドで必要な部分だけをNDJSONの形でとりあえずファイルに出力します。\ncat list_person_all_utf8.csv | tr -d \u0026#39;\u0026#34;\u0026#39; | jq -c -R \u0026#39;split(\u0026#34;,\u0026#34;) | {\u0026#34;auth_id\u0026#34;: .[0] | tonumber, \u0026#34;author\u0026#34;: .[1], \u0026#34;id\u0026#34;: .[2] , \u0026#34;title\u0026#34;: .[3], \u0026#34;suggest_ja\u0026#34;: [.[3], .[1]]}\u0026#39; 次のようなJSONが1行ずつ出力されます。\n{\u0026#34;auth_id\u0026#34;:1257,\u0026#34;author\u0026#34;:\u0026#34;アーヴィング ワシントン\u0026#34;,\u0026#34;id\u0026#34;:\u0026#34;056078\u0026#34;,\u0026#34;title\u0026#34;:\u0026#34;駅伝馬車\u0026#34;,\u0026#34;suggest_ja\u0026#34;:[\u0026#34;駅伝馬車\u0026#34;,\u0026#34;アーヴィング ワシントン\u0026#34;]} suggest_jaがオートコンプリートの対象となるデータになります。今回は著作と著者にしてみました。 あとは次に紹介するスキーマでインデックスを作成して、適当なプログラムを使ってBulkでElasticsearchに登録しましょう（私は個人作のツールで入れました）。\nインデックス オートコンプリート用のSuggesterを利用するための特殊なフィールド（completion）を利用したフィールドを用意します。 ちなみに、今回はLUCENE-10102に記載があった設定をそのまま使わせていただきました。 そのほかのフィールドは今回は特に必要はないのでおまけです。\nPUT aozora_index { \u0026#34;mappings\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;completion\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;japanese_completion_index\u0026#34;, \u0026#34;search_analyzer\u0026#34;: \u0026#34;japanese_completion_query\u0026#34;, \u0026#34;preserve_separators\u0026#34;: false, \u0026#34;preserve_position_increments\u0026#34;: true, \u0026#34;max_input_length\u0026#34;: 50 }, \u0026#34;auth_id\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;author\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;text\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;keyword\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;keyword\u0026#34;, \u0026#34;ignore_above\u0026#34;: 256 } }, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34; }, \u0026#34;author_id\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;integer\u0026#34; }, \u0026#34;id\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;integer\u0026#34; }, \u0026#34;title\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;text\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;keyword\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;keyword\u0026#34;, \u0026#34;ignore_above\u0026#34;: 256 } }, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34; } } }, \u0026#34;settings\u0026#34;: { \u0026#34;index\u0026#34;: { \u0026#34;number_of_shards\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;analysis\u0026#34;: { \u0026#34;analyzer\u0026#34;: { \u0026#34;japanese_completion_index\u0026#34;: { \u0026#34;mode\u0026#34;: \u0026#34;index\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;kuromoji_completion\u0026#34; }, \u0026#34;japanese_completion_query\u0026#34;: { \u0026#34;mode\u0026#34;: \u0026#34;query\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;kuromoji_completion\u0026#34; } } } } } } 動作確認 ここまでで、インデックスとデータの用意ができました。 オートコンプリートを実現するためにはElasticsearchのSuggesterという機能の、Completion Suggesterを利用します。検索の仕方が通常のものとは少し異なります。 ちなみに、速度重視のためにインメモリで動いているとの記載がドキュメントにあります。\nCompletion Suggesterのクエリ Suggester用のクエリがあるのでこちらを使います。 例えば、「wagah」という入力がある時に、サジェストする内容を取得するには次のようなリクエストになります。\nGET aozora_index/_search { \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;wagah\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } }, \u0026#34;_source\u0026#34;: [\u0026#34;title\u0026#34;, \u0026#34;author\u0026#34;] } 最初の「suggest」がsuggest用のパラメータを意味しています。 次の「title-suggest」は好きな名前をつけられます。レスポンスにこの名前がついた配列がサジェストの結果になります（同時に3. 複数suggestを呼び出せるので、対応した結果が分かるように名前が付けられます）。 「prefix」に入力の文字列を渡します。 「completion」がsuggesterのタイプの指定です。今回はCompletion Suggesterなので「completion」を指定します。その中に「field」でcompletionに利用するフィールド名を指定します。先ほどのスキーマでcompletionタイプを指定したフィールドです。今回は「suggest_ja」になります。 「_source」は結果を見やすくするために、ヒットしたデータの一部だけ取得するオプションです。 すると、次のような結果が返ってきます。\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;wagah\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 5, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;『吾輩は猫である』中篇自序\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;002671\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;『吾輩は猫である』中篇自序\u0026#34;, \u0026#34;夏目 漱石\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;わが俳諧修業\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;003771\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;わが俳諧修業\u0026#34;, \u0026#34;芥川 竜之介\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;わが母をおもう\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;003997\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;わが母をおもう\u0026#34;, \u0026#34;宮本 百合子\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;わが母を語る\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;049723\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;わが母を語る\u0026#34;, \u0026#34;上村 松園\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;吾輩は猫である\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;000789\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;吾輩は猫である\u0026#34;, \u0026#34;夏目 漱石\u0026#34; ] } } ] } ] } } 「suggest」の「title-suggest」がCompletion Suggesterのレスポンスになります。 最初の「text」は入力の「prefix」の値です。「offset」、「length」もこの文字に関する情報なので特に気にしなくてもいいかと。 「options」がサジェストされた内容になります。それぞれの「text」がサジェストされた文字列になります。「suggest_ja」には著作と著者名を入れましたが、今回は著作が「text」に帰ってきていることがわかります。 次に著者名でもやってみましょう。 「太宰」という入力が来たものとしてリクエストを投げます。\nGET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;太宰\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } } } レスポンスは次のようになります。\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;太宰\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 2, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;000236\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;ア、秋\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;001572\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;I can speak\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;001578\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;愛と美について\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;046597\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;青森\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;004357\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;青森\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } } ] } ] } } 先ほどとは異なり、「options」の中の個々の「text」はすべて「太宰 治」になってしまいました。 登録したデータは著作の一覧ですが、「suggest_ja」には著作と著者名を入れたためです。 これでは、実際に検索窓に実装したときに同じものが並んでしまいます。 こんな時のためのオプション「skip_duplicates」が用意されています。 先ほどのリクエストに「\u0026ldquo;skip_duplicates\u0026rdquo;: true」を追加します。\nGET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;太宰\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34;, \u0026#34;skip_duplicates\u0026#34;: true } } }, \u0026#34;_source\u0026#34;: [\u0026#34;suggest_ja\u0026#34;] } するとレスポンスは次のように変化します。\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;太宰\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 2, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;000236\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;ア、秋\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰治との一日\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;042582\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;太宰治との一日\u0026#34;, \u0026#34;豊島 与志雄\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰治情死考\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;043137\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;太宰治情死考\u0026#34;, \u0026#34;坂口 安吾\u0026#34; ] } } ] } ] } } 「options」は3つに減り、重複していないことがわかります。 「text」が同じ場合は最初に出てきたものを返すようです（注意：結果から観測しているだけで、実装はまだ見ていません）。 （なお、今回は説明を省きますが、入力データでスコアを指定することも可能になっています）。 そのほかにもCompletion Suggesterにはいくつか仕組みが用意されているのですが、それはまた今度にでも。\nまとめ ということで、Luceneコミッターの打田さんに感謝です。 便利な仕組みが簡単に使えるようになるのはとてもありがたいですね。\nまずは簡単にどういうものかとどうやって使うのかを記事にしてみました。 中の動きや、注意点、これまでとの違いなどは次の記事にしようと思います。 そういえば、公式ドキュメントにはまだ出てきてないな、それを書こうと思ってついでに動かしてみたんだけど、追加するのはまた後日かな。。。\n参考資料 青空文庫 - 公開中　作家リスト：全て ［LUCENE-10102］ Add JapaneseCompletionFilter for Input Method-aware auto-completion - ASF JIRA Expose Japanese completion filter to kuromoji analysis plugin by mocobeta · Pull Request #81858 · elastic/elasticsearch Suggesters | Elasticsearch Guide ［8.3］ | Elastic ","date":1660028402,"dir":"post/2022/","id":"6639ec6f88c4976f8ca20fa840f169e3","lang":"ja","lastmod":1660028402,"permalink":"https://blog.johtani.info/blog/2022/08/09/japanese-auto-completion/","publishdate":"2022-08-09T16:00:02+09:00","summary":"風のうわさで、日本語用のオートコンプリートのためのTokenFilterとAnalyzerがLuceneに取り込まれたと聞きました（LUCE","tags":["lucene","elasticsearch"],"title":"日本語用オートコンプリートのためのAnalyzer"},{"contents":"Hugoを0.84から0.92にアップデートをする際に、これまでのブログ記事やレイアウトファイルを修正したので個人的にメモを残しておきます。\nなんでアップデート？ うっかり魔がさして、メインのWSL2のUbuntuを20.04から22.04にアップグレードしました。。。 新規に22.04を落としてきて移行ではなく。 皆さんはまねしないほうがいいですよ！ アップデートした後にGitの環境がおかしくなったりと大変でした。 WSL2のUbuntuではHugoでブログのビルド、いろんな確認のためのElasticsearchの起動、個人的なプログラムとかを書く環境として利用しています。\nで、Ubuntuを上げたところ無事（？）Hugoもアップデートされたわけです。 最初はGitでfetchが出来なくなって修正していましたが、そのほかの動作確認を行なう段階でHugoでブログがビルドできなくなっていることが判明しました。\nバージョンアップに伴う修正 hugoコマンドを実行すると、いくつかのERRORとWARNが出力されました。 次のようなものです。\nhugo v0.92.2+extended linux/amd64 BuildDate=2022-02-23T16:47:50Z VendorInfo=ubuntu:0.92.2-1 ERROR 2022/08/05 13:22:32 Page.URL is deprecated and will be removed in Hugo 0.93.0. Use .Permalink or .RelPermalink. If what you want is the front matter URL value, use .Params.url WARN 2022/08/05 13:22:32 The \u0026#34;tweet\u0026#34; shortcode will soon require two named parameters: user and id. See \u0026#34;/home/johtani/blog_generator/content/post/2020/2020-12-04-build_corne_choc.md:46:1\u0026#34; ... ERROR 2022/08/05 13:22:33 Failed to get JSON resource \u0026#34;https://publish.twitter.com/oembed?dnt=fa... If you feel that this should not be logged as an ERROR, you can ignore it by adding this to your site config: ignoreErrors = [\u0026#34;error-remote-getjson\u0026#34;] ERROR 2022/08/05 18:44:11 Page.UniqueID is deprecated and will be removed in Hugo 0.93.0. Use .File.UniqueID ERROR 2022/08/05 18:44:11 Page.Dir is deprecated and will be removed in Hugo 0.93.0. Use .File.Dir Page.URLなどがdeprecatedに 最初と最後2行のERRORがこちらになります。 どうやら、Pageオブジェクトの変数に変更があったようです（まだdeprecatedであり、存在はしていそう？）。 レイアウト（テンプレート）ファイルで「Previous Post」や「Next Post」といったリンクを作ったり、 Algoliaに登録するためのJSONファイルを生成するところでURL文字列を取得するために参照していました。\nログ出力でどのように変更すればよいのか？という記載があるので便利ですね。 ただ、どのファイルにこの記述があるのかはログに出てなかったので少しだけ苦労しました。\n実際には「UniqueID」という文字列でディレクトリ内を検索してあたりを付けた感じです。 利用させていただいているテーマ（Clean White）がすでにアップデートに対応されていたのでそちらが参考になりました。\nいくつか、テーマをもとに修正したテンプレートがlayoutsディレクトリにあったので、それらを修正した形です（参考のリンクはテーマのファイルになります）。\n.URLを.Permalinkに変更（参考：single.html） .UniqueIDを.File.UniqueIDに変更（参考：list.algolia.json） tweetのshortcodeの引数が増えた これまでは以下のようにIDだけで良かったのですが、userとidという2つの引数が必須になるという変更が入ったようです。\n変更前：\n{{ \u0026lt;tweet 1449214872143609860\u0026gt; }} 変更後：\n{{ \u0026lt;tweet user=\u0026#34;johtani\u0026#34; id=\u0026#34;1449214872143609860\u0026#34;\u0026gt; }} WARNにはファイル名、行番号が出力されていたので、1つずつ修正していきました。 結構な量があったので、地味に大変でした、 公開しているブログを見ながら、該当するツイートを見つけてはuserを指定していく部分が特に。 自分のツイート以外もブログに貼っていたので画一的には対処できなくて。。。\nなにかプログラムで機械的に対応ができたかもなぁ。\n鍵付きツイートによるエラー tweetのshortcode対応を行なった後でもビルドがエラーになっており、次のようなエラーが消えないままでした（エラーの一部は省略しています）。 （幸いにも）1つのツイートだけ、ブログ記事を書いた後で鍵付きになってしまった方のツイートがあったようで、ツイート用のJSONが取得できなくてエラーになっていました。\nERROR 2022/08/05 13:22:33 Failed to get JSON resource \u0026#34;https://publish.twitter.com/oembed?dnt=fa... If you feel that this should not be logged as an ERROR, you can ignore it by adding this to your site config: ignoreErrors = [\u0026#34;error-remote-getjson\u0026#34;] こちらもログに対処方法が出ています。 config.tomlにignoreErrors = [\u0026quot;error-remote-getjson\u0026quot;]を追加すれば、エラーが出力されなくなりビルドも成功するようになります。 ただ、tweet以外でもエラーが出る可能性がありそうで、その場合に、ブログに書いたつもりが一部が出力されないまま公開されそうな気がします。 なので、今回はconfig.tomlに該当の設定を追加するのではなく、ブログ記事から該当のツイートを消す対応をしました。 幸いにも、ツイートを消してもブログ記事自体には影響がありませんでした。\n.hugo_build.lockファイルが生成される これは、エラーではないのですがgit addしようとした際に、ファイルが増えていたのでどういったファイルなのかを調べました。 0.89.0から追加されたロックファイルのようです（参考：0.89.0のリリースノート）。 こちらは特に保管する必要もなさそうなので.gitignoreに追加して対処しました。\nまとめ ということで、気軽にUbuntuをアップグレードしないほうがいいですね。。。 期せずしてHugoのアップグレードができたのは良かったかもなｗ\n参考 【WSL2】Ubuntu 20.04.4 LTS を 22.04 LTS へアップグレードした ","date":1659689954,"dir":"post/2022/","id":"167a7c9d579ce6f2cebf64a6f6329ecb","lang":"ja","lastmod":1659689954,"permalink":"https://blog.johtani.info/blog/2022/08/05/upgrade-hugo-accidentally/","publishdate":"2022-08-05T17:59:14+09:00","summary":"Hugoを0.84から0.92にアップデートをする際に、これまでのブログ記事やレイアウトファイルを修正したので個人的にメモを残しておきます。","tags":["hugo"],"title":"Hugoをアップデートした"},{"contents":"今回はQuerqyのElasticsearchのプラグインがどんなつくりになっているか？をちょっとだけ調べてみました。 SolrでもElasticsearchでも使えるという形なので、どんなつくりになっているのかな？と思ったのが発端です。\nGitHubのリポジトリ GitHubにリポジトリが公開されています。 2つのリポジトリに分かれています。\nEs向けのプラグイン コアのライブラリ どちらもJavaのライブラリで、ビルドシステムとしてはMavenを利用しています。 コアのライブラリのリポジトリにはさらに、以下の2つが存在しています。\nlucene向けライブラリ（Solr向けのモジュールもこちらに含まれる） コアライブラリ pom.xmlを読んだところ、次のような依存関係になっています（それ以外にも使ってるライブラリはあるけど）。\nEsプラグイン -\u0026gt; Lucene向けライブラリ -\u0026gt; コアライブラリ Esプラグイン Es向けのエンドポイントの実装、Esのクエリの組み立てを行なっています。 Rewriterの実装については、Lucene向けライブラリ、コアライブラリを利用する形になります。\nquerqy用のQueryBuilderを実装しており、EsがクエリをパースするタイミングでRewriterなどを呼び出してクエリの書き換えを行う仕組みです。 なお、Es向けのクエリの組み立てと書きましたが、ほとんどLuceneのクエリの組み立てになっています（そりゃそうだ）。 実際にquerqyのクエリ組み立て処理を行っているのは、Lucene向けライブラリのQueryParsingControllerになります。 いくつかのRewriterは、生のEsクエリをルールなどとして登録することができるようになっています。 これらのクエリのパースをEs側にやらせる処理の部分もこちらで定義されている感じです。\nそのほかに、ドキュメントには記載がないエンドポイントが2つ用意されていました。 インデックスに登録してあるRewriterの設定を各ノードでキャッシュする仕組みがあって、そのキャッシュの操作（クリア、リロード）用みたいです。 これらは、Rewriterの追加、削除のアクションの内部で呼び出されているので、ユーザー側で呼び出す必要はなさそうです。\nLucene向けライブラリ Luceneに関連する処理がまとめられています。 Es内部ではLuceneを使って検索処理が行なわれるため、Luceneのクエリを組み立てる必要があります。 querqyとしてLuceneのクエリを組み立てるときに必要なクラスがこのライブラリに含まれています。\nまた、Word Break Rewriterの実装はコアライブラリではなくこちらのライブラリに実装されています。 これは、Luceneのタームディクショナリを活用したRewriterになっているため、Lucene必須となっているからのようです。 （まだちゃんと実装を見ていないので、どんな活用の仕方をしているのかまではわかっていませんが。。。）\nコアライブラリ Rewriterの設定のパース処理、クエリのリライト処理の実装がまとめられています。 querqyのクエリが、Rewriterの処理に基づいて、querqyとして定義されたクエリのモデルに一旦変換される作りになっています。 Lucene向けライブラリやEs向けプラグインはこの内部のクエリモデルになったものをもとに、Lucene向けのクエリに書き換えていくというながれになっています。\nまとめ ざっくりですが、どんな構成なのかを見てみました。 Esのプラグインとなっているのですが、プラグインではなく、外部に出すことってできるのかな？と思いつつ、なんとなくソースを読んでみました。 パターンとしては、Lucene向けのクエリからEs向けのクエリを組み立てるとかの無駄な努力が必要になる気もするけど。。。 Luceneを使っていない検索エンジンに対しては、コアライブラリをもとに、それぞれの検索エンジンむけのクエリを組み立てる仕組みを作る形になると思います。 その際、Rewriterの設定を保持する仕組み、querqyが置き換えたクエリのマッピングができるか？といった点を考える必要がありそうです。 デバッグとかするときに、EsのクエリDSLのJSONとして見れるといいなぁと思ってたけど、そんなことできるかなぁ？\n","date":1658300650,"dir":"post/2022/","id":"3384ea6bb47d70f8ca94b4510813f36a","lang":"ja","lastmod":1658300650,"permalink":"https://blog.johtani.info/blog/2022/07/20/querqy-architecture/","publishdate":"2022-07-20T16:04:10+09:00","summary":"今回はQuerqyのElasticsearchのプラグインがどんなつくりになっているか？をちょっとだけ調べてみました。 SolrでもElast","tags":["elasticsearch"],"title":"Querqyの調査（その2：アーキテクチャ）"},{"contents":"Querqyというクエリのリライト用のプラグインがあるのでどんなものかを調べてみました。とりあえずは概要をドキュメントから追いかけてみた感じです。対応しているのはSolrとElasticsearch（以降、Es）になります。手元にはEsの環境があるのでそちらで試してみました。\nなにもの？ EsやSolrのプラグインで、ルールやパラメータを利用して、クエリの書き換えをEsやSolr側で行えるプラグインです。 なお、本記事ではEsのプラグインを説明します。 今回はドキュメントを読みながらメモを取った感じなので、詳細については公式ドキュメントを見ていただくのが良いかと。 手元では動作させてみましたが、今回の記事ではざっとメモを取っただけになります。\nインストール Esのpluginコマンドでインストール可能ですが、Mavenにアップロードされているバージョンは限定的なので、必要に応じて自分でビルドする必要があります。 対応しているかは、公式ドキュメントのInstallationのプルダウンが参考になります。\nどうやって使うの？ Query DSLにquerqyというクエリが追加されるので、あとはドキュメントをもとにクエリを組み立てるクエリを書いていきます。 すると、プラグインが指定されたルールに従い、EsのQueryに書き換え、実際の検索が実行して結果が返ってきます。 普通にmatchなどの既存のQueryと同レベルのものになるので、既存のEsのクエリと組み合わせた使い方もできるようです。\nサンプルとして紹介されている短めのクエリ（このクエリではルールによるクエリの書き換えはない）。\nGET ecommerce/_search { \u0026#34;query\u0026#34;: { \u0026#34;querqy\u0026#34;: { \u0026#34;matching_query\u0026#34;: { \u0026#34;query\u0026#34;: \u0026#34;notebook\u0026#34; }, \u0026#34;query_fields\u0026#34;: [ \u0026#34;title^3.0\u0026#34;, \u0026#34;brand^2.1\u0026#34;, \u0026#34;short_description\u0026#34;] } } } また、書き換え（Rewriter）の設定をElasticsearchに対して保存できるエンドポイント_querqy/rewriterが用意されています。\nSynonymの書き換えを行なうサンプル（後述するCommon Rules Rewriterの設定）。\nPUT /_querqy/rewriter/common_rules { \u0026#34;class\u0026#34;: \u0026#34;querqy.elasticsearch.rewriter.SimpleCommonRulesRewriterFactory\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;rules\u0026#34; : \u0026#34;notebook =\u0026gt;\\nSYNONYM: laptop\u0026#34; } } どんな書き換えができるの？ 用意されているRewriterは2022年7月時点では次のようなものになります（がんばれば、Javaで実装すれば自作もできそう）。\nCommon Rules Rewriter Replace Rewriter Number Unit Rewriter Word Break Rewriter また、複数のRewriterをチェインして使うこともできる。記述した順番で適用されます。 それぞれのRewriterについて簡単にメモを。\nCommon Rules Rewriter シノニム、結果のブースト、フィルター、結果に対して追加情報を付与したりできます。\nrulesにルールを記載していきます。 以下のようなフォーマットになっています。 クエリが入力に合致したら、ルールが適用される形です。プロパティは後述しますが、ルールの適用する順序などをハンドリングするために使用します。\n入力 =\u0026gt; ルール ルール @プロパティ @プロパティ 入力部分に関する書式 ルールの左辺に該当する部分で、クエリに入力された文字列がマッチするかどうかで、右辺のルールを適用するかがきまります。\n入力の一致の条件は次のような感じです。 完全一致、前方一致、後方一致の使い分けが可能。ダブルクォート\u0026quot;で制御 デフォルトでは、大文字小文字の区別なし（後述するオプションで変更可能） 単語の末尾にワイルドカード*で1文字以上にマッチ。入力の最後にだけ利用可能 書き換えの命令（ルール） 右辺に利用できる命令で、次のようなものがあります。\nSYNONYM 同義語展開するための命令です。Synonym Token Filterとの違いは、複数のルールを同時に適用できます。 フィールドに依存しない設定なのでメンテナンスが楽になるとのこと。 ただし、双方向の設定はないため、例えば\u0026quot;personal computer\u0026quot;と\u0026quot;pc\u0026quot;の場合、2つの設定を個別に定義する必要があります。 また、ステミングなどには未対応なので、\u0026ldquo;personal computers\u0026quot;も対応する場合はこれも追加する必要があります。 類義語ごとに重みを変えることが可能になっています。同列ではなく、同義語のスコアを下げるなどで、リコールを増加させつつ、入力語のスコアを上位にすると行ったことが可能です。\nUP/DOWN 入力文字列がマッチした場合に、追加のクエリを正か負のブーストをしつつ追加できます。 例えば、「iphone」と検索された場合に、「apple」もクエリとして追加しつつスコアをブーストし、「case」のクエリをスコアを下げるように追加できます。 これにより、アクセサリーではなく本体が検索結果の上位に出てくるような仕組みを提供できます。\nFILTER UP/DOWNではクエリとして追加されていたが、こちらはフィルターとして追加されます（＝スコアで調整ではなく、結果から除外される）。\nDELETE クエリからキーワードを削除できます。 単語自体をそのまま削除することも、入力された単語に合わせて他の単語を削除することもできます。\nDECORATE 2022年7月時点でEsでは利用不可で、Solrのみで利用可能です（なので読み飛ばしました）。\nプロパティ 各ルールの設定にタグをつけられるような機能です。 このプロパティを利用して、ルールのソートやフィルタリングなどが可能になります。 複数のルールにクエリがマッチした場合に、優先度が最高のものだけを適用したり、プロパティに特定の値を持っているものだけを採用したりできます。 なお、プロパティは命令のあとに記述する必要があります（パーサーの関係かな？）。\nReplace Rewriter クエリタームの置き換え用のRewriterです。クエリの正規化処理として、他のRewriterの前処理に利用したりできます。 サンプルではタイポの修正などに利用したり、不要な語の除去などがあげてありました。\nWord Break Rewriter クエリトークンを分解・結合します。 たとえばドイツ語は、複合語と呼ばれる個別の意味の単語を結合した1つの単語を持っているため、個別の意味に分解して検索すると便利なことがあります。 そういった単語を辞書を基にして分割できるようにする機能です。 辞書とは実際のインデックスのタームディクショナリのことと思われます（要調査。どのインデックスのフィールドを指し示すのかなど、設定とドキュメントではよくわからない）。 なお、利用可能な形態素解析を基にした実装はドイツ語のみとなっており、また、分解の時には形態素解析を考慮しますが結合時には考慮しません。\nNumber-Unit Rewriter クエリの数値と単位を判別し、対象となるフィールドにマッチさせます。範囲での一致や完全一致やブーストが可能です。 単位をもとにして、特定のフィールドに対する数値のクエリに書き換えることができます。\nShingle Rewriter Solrのみで利用可能なので読み飛ばしました。\nルールはどこに保存されるの？ .querqyというインデックスが内部で作成され、そこに保存されます（公式ドキュメントより）。 （ちなみに、Mappingはこんな感じみたいです）。 現状、プラグインでは設定したRewriterの取得ができないようなので、自分で登録した設定がどんなものかは、このインデックスを検索する必要がありそうです。\n気になった点・改善点？ 気になった点があったので。\nRewriterのエンドポイントは、登録・更新・削除のみ対応しており、登録したものの確認は直接インデックスを見に行くしかなさそうです（Issueは作られてた）。 [要検証]書き換えられたクエリがどんなものか？は残念ながら確認できなそうで、_validate/queryで最終的なLuceneレベルのクエリで確認するしかなさそう？ スキーマ側で定義したものと、Querqyで定義したものの兼ね合いがどういう形になるのか？などを気にする必要があるのが注意点かも。組み合わせたときの副作用などがどんなことになりそうか？が予測がつきにくそう。 Rewriterの定義自体のテストはどうしたものか？ まとめ とりあえず、ざっとドキュメントを見ながらメモを取った感じです。 設定などの記述が独自のものなので、そこに慣れていく必要がありそうです（特にルールの改行の部分とか）。 次は実際にどんな感じで使えそうか、既存の仕組みとの違いは？みたいなところをもう少し見ていきたいとおもいます。\n参考文献 querqy/querqy： Query preprocessor for Java-based search engines (Querqy Core and Solr implementation) Getting started with Querqy — querqy.org documentation ","date":1658285563,"dir":"post/2022/","id":"779e444b4bc720a9eed97f19c41e8773","lang":"ja","lastmod":1658285563,"permalink":"https://blog.johtani.info/blog/2022/07/20/intro-querqy/","publishdate":"2022-07-20T11:52:43+09:00","summary":"Querqyというクエリのリライト用のプラグインがあるのでどんなものかを調べてみました。とりあえずは概要をドキュメントから追いかけてみた感じ","tags":["elasticsearch"],"title":"Querqyの調査（その１）"},{"contents":"今年もBerlin Buzzwordsにオンライン出張してました。 今年はハイブリッドな開催だったようで、現地で再開している人もいるようでした。 ブースもあったみたいです。ちなみに、現地で参加する人はマスク必須のようでした（Health \u0026amp; Safetyというページが用意されていました）。 昨年オンラインだったMICESは現地のみでの開催みたいで見ることはできなかったです（録画公開されないかなぁ）。\nさて、いくつか見たセッションで面白かったものがあったので簡単にメモを。 すでにセッションのビデオがYouTubeで公開されているので、興味のある方は見てみてください。\n面白かったセッション The future of Lucene\u0026rsquo;s MMapDirectory: Why use it and what\u0026rsquo;s coming with Java 19 and later? セッションページ： The future of Lucene\u0026rsquo;s MMapDirectory： Why use it and what\u0026rsquo;s coming with Java 19 and later? ：： Berlin Buzzwords 2022 動画：Uwe Schindler – The future of Lucene\u0026rsquo;s MMapDirectory： Why use it \u0026amp; what\u0026rsquo;s coming with Java19 \u0026amp; later - YouTube 毎年恒例になってる気も？ 前半は昨年も話をした内容で、後半はJava 19がリリースされたら、Previewという形でフラグを立てて使えるようになるようです。 使えるようにするから、テストしてみて！という感じで終わっていますｗ\nScaling an online search engine to thousands of physical stores セッションページ：Scaling an online search engine to thousands of physical stores ：： Berlin Buzzwords 2022 ：： pretalx 動画：Aline Paponaud – Scaling an online search engine to thousands of physical stores - YouTube 数千の実店舗の商品をオンラインで検索できるようにしつつ、オンラインのマーケットプレイスのような検索も一緒にできるようにしたというお話でした。 インデックスの構成をどう工夫したのか？とかどういうクラスター構成にして、どんなことをモニタリングしてるよ？というお話です。 実際の店舗がどんなものかなどは出てこなかったので、少しイメージは沸きにくかったのですが、どんなことを考えながらインデックスの構成とか考慮したよという話はおもしろかったです。 実際に検索したときに、実店舗のデータがどんな感じで結果として表示されたりするのか？といった点はわからなかったので、そのあたりの話をもうちょっと聞いてみたかったなぁ。\nOffline Ranking Validation - Predicting A/B Test Results セッションページ：Offline Ranking Validation - Predicting A/B Test Results ：： Berlin Buzzwords 2022 ：： pretalx 動画：Andrea Schütt \u0026amp; Yunus Lutz – Offline Ranking Validation - Predicting A/B Test Results - YouTube otto.deというECサイトでのランキングをどうやって改善していくか？という話。 現在はマニュアルなチューニングをコンテキストごとにやっているけど、リクエスト量とかデータとかが増えてきてて、このままマニュアルで改善していくのも大変なので、 モデルベースのランキングを開発できないか？というのをはじめていますよと。 そのために、これまでのデータから、A/Bテストの結果を予測できるモデルが作れないか？というのをやっていますという話。 いくつかわからない単語も出てきたので、誰か詳しい人教えて！\nAI-powered Semantic Search; A story of broken promises? セッションページ：AI-powered Semantic Search; A story of broken promises? ：： Berlin Buzzwords 2022 ：： pretalx 動画：Jo Kristian Bergum – AI-powered Semantic Search; A story of broken promises? - YouTube Vespaの開発にかかわってる方の、Semantic Searchに関する話。 Semantic Searchが流行り始めていて、どうやればできるのか？という話が出てきています。 けど、どういうものでどういう点に気を付けたほうがいい？という話でした。 LtRってこんなもの、そのあとに出てきたLLM（Large Language Model）でどうやって検索の改善に使えるの？というのが分かりやすく説明されていました。 それらの説明の後、BEIRという論文を紹介しつつ、LLMを使うときの注意点の話がありました。\nBERTとかをちょっと勉強してたのもあり、なんとなくそうだよなぁと思っていた結論と同じ結論が出てきたので面白いと感じました。 BEIRの論文は時間を見つけて読んでみないとな。\nHybrid search \u0026gt; sum of its parts? セッションページ： Hybrid search \u0026gt; sum of its parts? ：： Berlin Buzzwords 2022 ：： pretalx 動画：Lester Solbakken – Hybrid search： Greater than the sum of its parts? - YouTube こちらもVespaの人の話。 先ほどのSemantic Searchの話では、Semantic Searchがどんなものか？という話でした。 が、それだけで検索ができるわけでもないので、キーワードサーチとSemantic Searchの両方をうまく活用するには？というのがこのセッションでした。 最終的にはVespaを使うとうまくハイブリッドできるよという話ですが、考え方は参考になるかなと。 Vespaも触ってみたいなぁ。\nThe life of a search engine administrator セッションページ：The life of a search engine administrator ：： Berlin Buzzwords 2022 ：： pretalx 動画：Lucian Precup \u0026amp; Vincent Bréhin – The life of a search engine administrator - YouTube 検索システムの管理者ってどんなことやるの？それにはどんなことができるツールがあるといいの？という話です。 まぁ、ツールについてはこの会社の人たちのツールの宣伝なのですが、検索システムを作って育てていくのにどんなことを考えたりするのか？という参考になるかなぁと。\nShould we stop using distance in our location-based data recommendation models? セッションページ：Should we stop using distance in our location-based data recommendation models? ：： Berlin Buzzwords 2022 ：： pretalx 動画：Charlie Davies – Should we stop using distance in our location-based data recommendation models? - YouTube TravelTimeという会社を立ち上げた人の話。 位置に関する情報って重要だし、検索するときに利用しますよね？例えば、ホテル決めたりとか、仕事探したりするときに。 ということで、位置情報を検索エンジンで利用する方法（Bounding Box、ポリゴン、距離）をまず紹介して、どんなユースケースで使えるかという話があります。 また、それとは別に検索速度（いかに検索を速く返すか）も重要だという話があります（ウォルマートはページロード時間を1秒早くしてコンバージョンが2%あがったとか）。 で、実際に検索結果に距離とかでるけど、実際に知りたいのはどのくらいの時間で行けるのか？という話だったりしませんか？と。 公共交通機関を使ったりする場合に、実際に45分で移動できる距離というのは半径5マイルとかできまるものではないのに、単純に位置情報を利用した距離だけでソートしていいの？という問いかけから、 その辺を考慮した検索ができるAPIを開発しているよ、検索速度もはやいよというお話でした。 残念ながら具体的にどうやって作っているのか？というのはなかったですが、観点がおもしろかったです。\nWord2Vec model to generate synonyms on the fly in Apache Lucene セッションページ：Word2Vec model to generate synonyms on the fly in Apache Lucene ：： Berlin Buzzwords 2022 ：： pretalx 動画：Daniele Antuzi \u0026amp; Ilaria Petreti – Word2Vec model to generate synonyms on the fly in Apache Lucene - YouTube Word2Vecのモデルを使った、Apache LuceneのSynonym Filterを開発中だよという話 DeepLearning4Jを使ってみたが、遅くて使えなかったんだけど、最近Luceneに入ったkNNを使うことでそれなりの速度で使えそうなものができるかもよ？って感じでした。 モデル学習用のツールも作ってて、イタリア語のWikipediaで学習したものでちょっと動かしたらそれっぽい感じになってるという話でした。 まだ途中でいくつかやりたいことがあるという話で、実用はまだ先のようでした。例えば、1単語のSynonymにしか対応してないとか、モデルをインメモリでしか動かせないとか。\nQAでも出たのですが、Word2Vecだと対義語も類似していると判定されてしまうと思うので、その辺がどうなっているのかなぁ？という疑問があります。 ルールベースの類義語ではないので、調整するのはどうやるのかなぁ、学習用のコーパスをいい感じにするとかなのかな？とか、気になるところです。\nNrtSearch: Yelp’s fast, scalable, and cost-effective open source search engine セッションページ：NrtSearch： Yelp’s fast, scalable, and cost-effective open source search engine ：： Berlin Buzzwords 2022 ：： pretalx 動画：Umesh Dangat – NrtSearch： Yelp’s fast, scalable, and cost-effective open source search engine - YouTube YelpがLuceneベースで開発をしているNrtSearchというOSSの話です。 Elasticsearchを使っていたんだけど、どういった点が問題点になってどういうモチベーションでNrtSearchを開発したのか？を説明しています。 アーキテクチャがどんなもので、実際に動かしてみてどんな利点があって、どんな点が問題として出てきているか、将来どんなことをやろうとしているかがわかります。 QAでもいろんな質問が出ていて面白いです。\nまとめ ということで、簡単でしたがセッションの感想でした。 Neural/Semantic Searchというのがセッションのタイトルなどに入っているのが多くなってるなぁという感想です（ちょっとやってみたい気はしてるんだよなぁ）。 すでにYouTubeに動画が公開されているので興味があるセッションを見つけてみてください。 Berlin Buzzwordsの次の日に開催されたMICESも観てみたかったですが、オンラインでも参加できる形式で海外のカンファレンスが開催されるのはとても助かりますね（ヨーロッパだと時差もそれほど大変じゃないし）。 けど、落ち着いたらまたオフラインで参加してみたいなぁ。\n","date":1655283615,"dir":"post/2022/","id":"f56c19442484b3e4f47875b58b3f72b2","lang":"ja","lastmod":1655283615,"permalink":"https://blog.johtani.info/blog/2022/06/15/ttend-berlin-buzzwords-online/","publishdate":"2022-06-15T18:00:15+09:00","summary":"今年もBerlin Buzzwordsにオンライン出張してました。 今年はハイブリッドな開催だったようで、現地で再開している人もいるようでした。","tags":["conference","berlin buzzwords"],"title":"今年もオンラインでBerlin Buzzwordsに参加した"},{"contents":"7.16で正式リリースされましたが、Elasticsearchの新しいJavaのクライアントが出ています。 使ってみたので、ちょっとだけ紹介でもしてみようかな。\nこのクライアントが出るまでは、ElasticsearchのJavaクライアント（REST版）はElasticsearch本体の一部として実装・管理されていました（Elasticsearchのリポジトリにあるclientディレクトリ）。\nHTTP経由でElasticsearchにアクセスするクライアントだったのですが、Elasticsearch本体のリポジトリで管理されていることもあり、Elasticsearch本体で利用されているクラスを使用していました。 このため、クライアントライブラリなのですが、Elasticsearch本体のJarが必要になりサイズが大きくなっていました。 また、JavaのObjectへの詰め替えなどの機能も備えておらず、すこし古臭い感じでもあります。 この辺りを刷新する目的もあり新しいクライアントが公開されたようです。 3月くらいに触った時はまだ、ドキュメントが揃ってなかったのですが利用方法などが増えているので移行も楽になってきているようです。 根本的に作り直されたため、これまでのREST Clientとは使い方が違います。ですので、jarだけの差し替えでこれまで動いていたプログラムを移行ができるわけではないので注意が必要です。\nどの辺が便利？ 順次移行が可能 これまでのRESTクライアントとはパッケージ名もjarも別モノになっています。 ですので、少しずつ新しいJava Clientに切り替えていくことが可能になっています。 根本的に使い方が変わっているので、大きなシステムのクライアントを全部切り替えるのは結構大変かと思います。 ですので、Indexをしている部分だけとか、検索部分だけなどといった部分的な置き換えをしつつ新しいクライアントに慣れていくことができます。\nラムダっぽく書ける 検索のクエリのサンプルを見るとわかりますが、こんな感じでクエリが書けます(公式ドキュメントより抜粋)。\nSearchResponse\u0026lt;Product\u0026gt; response = esClient.search(s -\u0026gt; s .index(\u0026#34;products\u0026#34;) .query(q -\u0026gt; q .match(t -\u0026gt; t .field(\u0026#34;name\u0026#34;) .query(searchText) ) ), Product.class ); また、最後で渡しているProduct.classは、検索結果をどのクラスのインスタンスにして返すかの指定です。 Elasticsearchのレスポンス（JSON）から値をコピーして返してくれるようになっています。 ですので、値を入れ替える処理を書く必要がなくなっています。\nJSON文字列をそのまま使える 触り始めてからリリース（7.17.2より後なら使える）された、JSON文字列からリクエストを作る機能もあります。\nこれまでのREST Clientだと、Elasticsearchへのリクエストを必ずJavaのメソッドで構築する必要がありました。 今回のこの機能を利用すると、JSON文字列（やファイル）からリクエストオブジェクトを作るためのメソッド.withJson()が提供されています。 例えば、スキーマや設定変更用のリクエストのJSONなどは、Kibanaやcurlから試験的に投げたリクエスト（JSON）と同じものを使いたいことが多いです。また、ElasticsearchのAPIは数が多く、ドキュメントを見ながら利用方法を調べてJSONでまず試行錯誤することが多いです。 このwithJsonメソッドを利用することで、動作確認などをしたJSONがそのままソースにも利用できるので、リクエスト変更時の確認なども容易になると思います。\n使ってみて困ったのは？ 便利な面も多いのですが、使っていて少し困ったこともあったのでそれもメモを残しておきます。\nどんなリクエストを投げているかが不明 先ほども書きましたが、Elasticsearchのリクエストを試行錯誤するときは公式ドキュメントを見ながら、Kibanaなどを利用して試すことが多いです。 ですので、自分がやりたいことのJSONは手元にあることが多いです。 ただ、プログラムでクエリを組み立てる必要も出てきます。この時、実際にRESTリクエストとしてどんなJSONを投げているのかを知りたいことがあります（実際、検索クエリ作っててメソッドの使い方がうまくいかなくて四苦八苦してました）。 4月時点では簡単にリクエストで投げているJSONを文字列としてログに出すメソッドなどは用意されていないようでした。 デバッグ用に次のようなメソッドを書いてみました。 Elasticsearchへ投げるRequestのクラス（例：CreateTemplateRequestとか）を引数に渡すことで、JSON文字列に変換できるようになっています（StringWriterに書き出されてる）。 ここのLoggerはサンプルです。writer.toString()で取り出せる文字列がJSON文字列になっているので、ログに出してみるなり、ファイルに落とすなりしてデバッグのお供にしてください。\nimport java.io.StringWriter; import co.elastic.clients.elasticsearch._types.RequestBase; import co.elastic.clients.json.SimpleJsonpMapper; import jakarta.json.stream.JsonGenerator; ... private void printRequestBodyJsonForDebug(RequestBase request) { //for debug Logger.log(\u0026#34;** Debug print start **\u0026#34;); StringWriter writer = new StringWriter(); SimpleJsonpMapper mapper = new SimpleJsonpMapper(); JsonGenerator generator = mapper.jsonProvider().createGenerator(writer); mapper.serialize(request, generator); generator.close(); Logger.log(writer.toString()); Logger.log(\u0026#34;** Debug print finish **\u0026#34;); } プラグインなどで提供されるクエリが書けない LtRプラグインなどは、Elasticsearchの検索クエリを拡張しています。 残念ながら、現時点（2022/06/13）ではカスタムクエリを新しいJavaクライアントで利用しようとした場合、エラーが発生してしまいます（知らないJSONだと判断されてしまいます）。\nGitHubのIssueとして「［roadmap］ Add support for plugin-defined custom components · Issue #252 · elastic/elasticsearch-java」があります。 これに対応されたら、拡張されたクエリも利用できるようになるでしょう。 プラグインなどで拡張されているものを使いたい場合は、残念ながら既存のRESTクライアントを当面は使うことになりそうです。\nまとめ 新しいElasticsearchのJavaクライアントを簡単ですが触ってみて、気になった点を記事にしました。 JavaのObjectに詰め替えてくれる機能など便利になっているので使ってみてください。 ドキュメントもちょっとずつ増えているようで、使い方も分かりやすくなっていました（触った時はレスポンスの扱い方などがJavaDocしか用意されてなかったんです）。 説明が欲しいなぁと思うことがあれば、GitHubにIssueを上げてみるといいかもです。\n参考 公式ドキュメント Java Clientチームの人がカンファレンスで利用したスライド ","date":1655119446,"dir":"post/2022/","id":"5eebdf85fd1726db301194bfeeee4377","lang":"ja","lastmod":1655119446,"permalink":"https://blog.johtani.info/blog/2022/06/13/new-elasticsearch-java-client/","publishdate":"2022-06-13T20:24:06+09:00","summary":"7.16で正式リリースされましたが、Elasticsearchの新しいJavaのクライアントが出ています。 使ってみたので、ちょっとだけ紹介で","tags":["elasticsearch","java"],"title":"Elasticsearchの新しいJavaクライアント"},{"contents":"Azure Cognitive Searchで2月に新しい機能が公開されました。 「Index Alias」（インデックスの別名）です。まだ、パブリックプレビューの段階ですが、ドキュメントなどが公開されていたのでどんな機能かを調べてみました。なお、本ブログの内容は2022/05/18時点での内容となります、ご注意ください。\n公式ドキュメント まずは公式ドキュメントです。1つ目の「インデックスの別名を作成する」の冒頭で別名（エイリアス）がどんなものかを説明しています。\nインデックスの別名を作成する - Azure Cognitive Search | Microsoft Docs エイリアスの作成または更新 (2021-04-30-Preview) - Azure Cognitive Search | Microsoft Docs Alias Operations (2021-04-30-Preview) - Azure Cognitive Search | Microsoft Docs REST APIのドキュメント（2022/05/18現在、日本語のページだと左のメニューが壊れているため、どんなAPIがあるかがわかりにくいため、Alias Operationsのページは英語のリンクになっています）\nインデックスエイリアスってどんなもの？ 文字通り、インデックスにエイリアス（別名）をつけることができるようになります。 Azure Cognitive Searchでは残念ながらインデックスを作成するタイミング以外ではインデックスの名前を変更できません。 このため、インデックスのスキーマ（Analyzerの設定変更など）を変更したい場合、新しいインデックスを作成します。 新しいインデックスの名前はこれまでのものとは別の名前になってしまうため、アプリケーションで指定しているインデックス名も書き換える必要が出てきます。 利用しているアプリが複数ある場合は、すべて変更が必要です。\n今回出てきたエイリアスを利用することで、アプリケーションではエイリアスを指定することで、アプリケーション側の変更なくインデックスを入れ替えることができるようになります。\nエイリアスの操作方法 公式ドキュメントにAPIの一覧や利用方法の記載があるので詳細はそちらをご覧ください。 本ブログでは、いくつか利用するときに気になった点を書き残しておきます。\n作成 aliasesというエンドポイントにエイリアスの名前とインデックス名をPOSTすることで作成できます。 以下のサンプルは公式ドキュメントの例です。\nPOST /aliases?api-version=2021-04-30-preview { \u0026#34;name\u0026#34;: \u0026#34;my-alias\u0026#34;, \u0026#34;indexes\u0026#34;: [\u0026#34;hotel-samples-index\u0026#34;] } ちなみに、インデックスの指定がindexesで配列になっていますが、公式ドキュメントに以下の記述があり、複数の指定はできないです（エラーが返ってきます）。\nindexes 配列に指定できるインデックスの名前は 1 つだけです。\nまた、1つのインデックスに対して複数のエイリアスをつけることは問題ありません。\n確認 エイリアスのリストも取得できます。\nGET /aliases?api-version=2021-04-30-preview 現在どんなエイリアスが、どのインデックスに対して付与されているかがリストで取得できます。 きちんと作成されたかどうかなどの確認にも使えるかと思います（もちろんエイリアス名を指定したGETも可能です）\n検索での利用 検索のREST APIでインデックス名を指定していた部分をエイリアス名に置き換えるだけです。\nPOST /indexes/my-alias/docs/search?api-version=2021-04-30-preview { \u0026#34;search\u0026#34;: \u0026#34;pool spa +airport\u0026#34;, \u0026#34;searchMode\u0026#34;: any, \u0026#34;queryType\u0026#34;: \u0026#34;simple\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;HotelId, HotelName, Category, Description\u0026#34;, \u0026#34;count\u0026#34;: true } 更新 エイリアスの更新（インデックスの入れ替え）は作成と同じリクエストです。 更新が成功すれば204のステータスコードが返ってきます（エイリアス初回作成時は201） なお、ドキュメントには以下のような記述があります。入れ替え時の注意点になるかと（入れ替えのタイミングをきちんと制御したい場合は、少しだけアプリケーションを停止するなどが必要かと思います）。\n別名に対する更新がシステムに反映されるまでに最大 10 秒かかります。以前その別名が対応付けられていたインデックスを削除するのは、10 秒以上待ってからにしてください。\n削除 もちろん削除もできます。\nDELETE /aliases/my-alias エイリアスを利用する場合の注意点 便利なエイリアスですが、エイリアスが使用できない場合もあるので注意が必要です。\nデータ登録のAPIと検索のAPIでのみエイリアス名を利用可能 インデックスの設定変更やAnalyze Text APIではこれまで通りインデックス名を指定します。 また、エイリアス名はインデクサー機能でtargetIndexNameにも指定できません。 エイリアス名がついているインデックスは削除不可 エイリアスがついているインデックスを削除しようとした場合はエラーが出るようになっています。 まずはエイリアスを削除してからインデックスを削除するという手順になります。 まとめ 簡単ですが、インデックスのエイリアスに関しての紹介でした。まだパブリックプレビューなので正式リリース時点では利用方法が変わっている可能性もあります。こちらは注意してください。\n正式公開されればですが、今後Azure Cognitive Searchを使ったアプリを開発する場合はインデックスエイリアスを利用することを基本にするのがいいかもなと思います （ちなみに、Elasticsearchにもインデックスエイリアスの機能がありますが、異なる点が多いので同じものとは思わないほうがよさそうです）。\n","date":1652856857,"dir":"post/2022/","id":"7cc21814165879f72529e91682ece5c6","lang":"ja","lastmod":1652856857,"permalink":"https://blog.johtani.info/blog/2022/05/18/index-alias-in-azure-cognitive-search/","publishdate":"2022-05-18T15:54:17+09:00","summary":"Azure Cognitive Searchで2月に新しい機能が公開されました。 「Index Alias」（インデックスの別名）です。まだ、パブリックプレビューの段階です","tags":["azure search"],"title":"インデックスエイリアス - Azure Cognitive Searchの新機能"},{"contents":"年末までに知り合いと次の論文を読んだので軽くまとめておきます。\nExtreme Multi-label Learning for Semantic Matching in Product Search なんで読んだの？ 前回読んだ理由と一緒ですが、Semantic Searchに絡んだ検索の論文であり、Amazonの製品検索での話も関係していたので読みました。\nどんな論文？ Amazonの製品検索でセマンティックマッチングを利用する方法、レイテンシを低くしつつ再現率を改善できるような仕組みを検討して評価した論文です。 実際には商品検索のマッチングを大規模なマルチラベル問題（Extreme Multi-label Classification：以下ではXMC問題とする）として定義して、その問題を効率よく解く方法について検討評価しています。\n検索には大きく2つのフェーズがあります。マッチング（クエリにヒットした文書の集合を求める）とランキング（マッチングのデータを関連性の高い順序で並べる）です。 前回のMSの論文では、マッチング後のランキングのフェーズで言語モデルを利用した並び替えを行う話でした。 今回の論文ではマッチングに関してセマンティックサーチを有効活用できないか？という論文になります。 転置インデックスベースの（語彙による）検索では、スペルミスや類義語などを検索することが難しいです。 語彙以外のデータ（クリックや購入といったユーザーの行動や製品の意味的表現など）を学習できる埋め込みベースのニューラルモデルを活用して、マッチングを補完する方法を検討しています。 下図のようにあくまで転置インデックスベースの検索の補完として利用するみたいです（論文に掲載されていたアーキテクチャ）。\nXMC問題とは？ セマンティックサーチを行なう場合、埋め込みベースのニューラルモデル（例えばBERTとか）を利用することが多いですが、 クエリトークンを埋め込み空間にベクトル化する部分が推論のボトルネック（レイテンシが高くなる）になることが多いです。 これは、ニューラルネットワークの複雑さに依存します。 低レイテンシになるように、複雑ではないエンコーダーを用いることもありますが今度は性能（精度）が良くなくなります。\nそこで、この論文ではセマンティックマッチングをXMC問題として定義し、これを効率よく解くための手法を提案しています。 ここで、XMCの問題とは、入力（今回はクエリ）に対して、最も関連性の高い複数のラベル（今回は製品）を出力することとなります。 Amazonでの製品なのでほんとに大規模（ラベル＝製品＝1億件）です。\n従来のXMC問題を解くための手法として、疎な線形モデルの手法、パーティションベースの手法、グラフベースの手法などが列挙されています。 疎な線形モデルの手法では、ナイーブなOVR(one-versus-rest)だと出力となるラベルの数に対して線形に推論時間も大きくなるため、今回の用途には適しません。 この論文ではパーティションベースの手法として、推論時間を短くできるツリーベースで疎な線形モデルの手法を評価しています。\nどういう仕組み？ ツリーベースのモデルは次のような感じです。 PECOSのXR-Linearモデルを利用しています。 モデルに関する詳細についてはこちらの論文に詳しく載っているようです（まだ読んでいないです、、、）。\n一番上に入力として与えられるxがクエリ（ベクトル）で一番下の四角が製品にあたるラベル（Y={1,...,l,...L}）です。 これらが与えられたときに最も関連性の高い上位k件のラベル（製品）を出力するモデルを生成します。 モデルのパラメータは、学習データとして(x, y)(ここで、y∈{0, 1}^𝐿、すなわちクエリに製品がマッチするかしないかの二値)を使って調整します。\nこれは、ツリーのそれぞれの階層のノードで、その下の層に関連するデータがあるかどうか？という分類を学習すればよいことになります。 学習データとしては、入力と最下層のラベルにマッチするかどうかというデータです。 これをもとに、ツリーの最下層のデータをもとにひとつ上の層の分類器の学習をすればよいことになります。\n推論は出来上がったツリーベースのモデルに対して、ビームサーチで行ないます。 この時、それぞれの層のノードの分類器では推論の効率化のために枝刈りの閾値を設定しています。 本論文で閾値の違いによる精度とレイテンシの比較も行われています。 また、ビームサーチのビームサイズを変化させた場合の性能についても実験しています。\nどうやって検証した？ 次のようなデータを用いてAWS上にモデル構築、推論のシステムを用意し実験しています。\n10億件以上のポジティブなクエリ-商品ペアのデータセット クエリ：2億4千万、商品：1億 ポジティブなペアとは、クリック数や購入数の集計値が閾値以上。ただし、データセットとしては集計値は利用していない。 トレーニングセット：12か月分の検索ログ 評価用テストセット：1か月分の検索ログ（12％の製品はトレーニングセットには出てこない） というデーセットをもとに上記のモデルを学習しています。 特徴量はクエリテキストと製品のタイトルをもとにTF-IDFをいくつかのパターンで導出したものが使われています。 詳しくは論文の結果に関する表などを見ていただくとして。。。\n結果として、1億件の商品カタログで60.9%のRecall@100を1.25ミリ秒/リクエストという低レイテンシで達成したとなっています。\n気になる点は？ 知り合いと3人で読んでいて次のような気になる点が出てきました。\nツリーの構築をするときに、製品のラベルの並び順（製品のクラスタリング？に他製品が似た場所に来る感じ）が推論の効率の良し悪しに影響するんじゃないの？＝Amazonではないところではうまくいかない？ PECOSの論文読まないといけない？ 製品が増えたときにモデルの組み換えとかどうするの？ コールドスタート問題という形で今後の課題として書かれていたので、今後に期待 転置インデックスでのマッチングの補完として利用しているということだったけど、ランキングはどうしてるんだろう？ 別のランキング用の指標があるのかな？上位k件とした場合にどうやって、決めているのか？ モデル更新のタイミングはどのくらいのスパンなんだろう？ まとめ＆感想 セマンティック検索の処理を分類問題に置き換えてその手法を用いて行い、実際のシステムに適用できそうな速度と精度を出しているのが面白かったです。 セマンティック検索にもいろんな手法があるのだなと（そして、いろいろ勉強しないといけないんだなと。。。）。\n気になる点にも書きましたが、ツリーの作り方になにかコツがあるのか？他の検索結果と組み合わせるときに、どのような基準で上位を選択しているのか？など疑問点も残っています。 個人的には特にどのように既存のシステムにくっつけていくのかというところが気になっています。 論文の続編でその辺の話が出てくるのかなぁ？\nツリーの作り方に関するPECOSの論文を誰か解説してくれると嬉しいかもなぁと思いつつ、とりあえずブログに書き残してみました。参考になるかなぁ。。。\n参考文献 Extreme Multi-label Learning for Semantic Matching in Product Search - ACM Extreme multi-label learning for semantic matching in product search - Amazon Science PECOS： Prediction for Enormous and Correlated Output Spaces 数えきれないほどの分類を行うExtreme Classification - Technical Hedgehog ","date":1641980462,"dir":"post/2022/","id":"0645bdb1cdf88ec74288d503eb71839c","lang":"ja","lastmod":1641980462,"permalink":"https://blog.johtani.info/blog/2022/01/12/reading-xmc-for-semantic-search-in-prod/","publishdate":"2022-01-12T18:41:02+09:00","summary":"年末までに知り合いと次の論文を読んだので軽くまとめておきます。 Extreme Multi-label Learning for Semantic Matching in Product Search なんで読んだの？ 前回読んだ理由と一緒ですが、Semantic","tags":["search","paper"],"title":"Extreme Multi-label Learning for Semantic Matching in Product Searchという論文を読んだ"},{"contents":"今年も振り返りブログです。録画した紅白をオッかけ再生して気になるアーティストだけ見ながら書ています。\n振り返り（2020年に書いた抱負から） まずは去年の抱負を元に書きます。今年もコロナウィルスの影響が年末まで続き、ほとんどで書けなかったです。\nフリーランス継続? ありがたいことに個人事業主として無事1年を終えられました。 夏頃は5社ほどお手伝いをさせていただき、年末時点では3社をお手伝いさせていただいています。\n昨年の振り返りで書いた2社はありがたいことに継続していただいています。\n今年も完全リモートで仕事が終わりました。オミクロン株が来ているし、来年春くらいにはミーティングに出かけられるかなぁ。 相変わらず検索のお手伝いをしています。手伝いをしつつ勉強させていただいている感じです。 ありがたし。\nプログラミング ちょっとペースダウンしています。。。\nextract-kana-java 新しく書いたのはこれくらいかな。 SudachiやNeologdのkuromojiでフリガナを出力して違いを見るというコマンドツールです。 ちょっと比較してみたくなったので書いて公開しました。\nあとは、Sudachiをいろいろと触り始めています。 来年はそのへんをもうちょっと何かできるかなぁ。 コーディングしないとよくないなぁと思っているので、強制的になんかやらないとだ。\n検索の勉強 仕事でやってます。ブッチャー本は昨年買って手を付けてませんが。。。 来年は少しずつやる予定です。 あとは、Azure Cognitive SearchのSemantic Searchを触った関係でSemantic Searchに関する論文を探してちょっとずつ読んでいます。 知り合いと読んでいたAmazonの論文をブログにまとめるのは来年早々に。。。\n検索のポッドキャスト? これはできませんでした。重い腰が上がらない。 公開しないまでも雑談したいなぁ。\n振り返り(今年あったできごと) ここからは今年の出来事を。\n自宅環境 キーボード以外もDIY 検索Slack爆誕 車買い替えた WindowsノートPC買った 今年もずっと自宅で仕事でした。 昨年だいぶそろえていたのでそれほど変更はないですが。\n2月バージョン 切り替えてからずっとWindowsです。Macもブラウズ用に使ってはいますが。 ただ、Windowsといっても、プログラムなどに関する環境はほぼWSL2になっています。コマンドプロンプトは触ってないなぁ。 今年最後に更新された自宅環境は椅子になります。 詳しくは昨日のブログをご覧ください。\nキーボードもDIYしましたが、今年はほかにも少しDIYしました。\n今年のDIYキーボードとコントローラーラック このブログにも書きましたが、来年はキーマップやファーム関連を触っていきたいなと。あとロータリーエンコーダー。。。 BLE化は快適で、3台のPCの切り替えがとっても便利です。\ntakuya_aさんの鶴の一声で検索のSlackが爆誕しました。 検索に関連する情報交換ができる場として楽しませてもらってます。 年末には検索100本ノックの話が立ち上がってきています。 来年も面白い話が聞けそうでワクワクしています。\nあとは、車を買い替えました。初のハイブリッドです。 まだまだ慣れないですが、燃費とかがとても楽しみです。\n結局まだ出かけていませんが、出かけられるようにFMV Zeroを購入しました。 このブログもリビングでFMV Zeroで書いています（まだちゃんとセットアップしていないので、実際にはリモートデスクトップでデスクトップにつないでそこのVSCodeで書いちゃってますが。。。）。 ブログ書いたりコード書ける程度の環境は作らないとな。\n来年の抱負 ということで、来年の抱負です。\nフリーランス継続 プログラミング ブッチャー本ちゃんと読む 読んだ本のブログを書く 今年もありがたいことに仕事を継続していただけて、乗り越えられました。 来年も価値を提供できるように頑張っていきます。\nプログラミングは失速気味のでなにかテーマを見つけないとなあ。\nブッチャー本は読み始めます。必ずｗ\nブログのペースが落ちていたり、本を読むペースが落ちているので、 本を読んで自分のためにもブログを書こうと思います。 書いてないって思ったら叱咤してください。。。\n今年も出かけられませんでしたが、仕事も安定してあり、無事乗り切れました。 人と話をする機会は減っているので雑談したいな、オンラインなどで。 相手をしてやってもいいぞという方はぜひ連絡ください。\nさて、来年（もう年あけちゃったけど）は出かけられるかなぁ。 何はともあれ、今年もよろしくお願いします！\n","date":1640957359,"dir":"post/2021/","id":"104b8ee17a8bf1f7043d236659680493","lang":"ja","lastmod":1640957359,"permalink":"https://blog.johtani.info/blog/2021/12/31/looking-back-2021/","publishdate":"2021-12-31T22:29:19+09:00","summary":"今年も振り返りブログです。録画した紅白をオッかけ再生して気になるアーティストだけ見ながら書ています。 振り返り（2020年に書いた抱負から） ま","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2021）"},{"contents":"2021年もあと少しですが、今年買って良かったものをリストアップしておこうかと思います。 今年買ったといいながら、昨年このネタを書くといいつつ書いてないので、昨年の分も入っているかも？ Amazonのアフィリンクを貼っていますが、急いでないものはAliExpressで購入したりもしています。\n象印のポット Amazon | 象印 電気ケトル 1.0L コーヒードリップ用機能付き ホワイト CK-AX10-WA | 象印マホービン(ZOJIRUSHI) いわゆる電気ケトルというやつです。これが来るまでは鍋で湯を沸かしていました。 水を入れてボタンを押し、湯を沸かしている間に他のことができるのはやはり便利です。 また、コーヒーを入れるためのコーヒードリップモードがあるので、ドリップするためにわざわざ湯を他のものに入れたり、 専用のヤカンを使わなくても簡単にドリップができるのがさらに便利で重宝しています。\nウォータードリップコーヒーサーバー Amazon | iwaki(イワキ) コーヒーサーバー SNOWTOP ウォータードリップ ここ数年、冬以外は水出しコーヒーを飲んでいます。 麦茶のポットのような水出しコーヒー用ポットを使っていたのですが、滴下式のほうがえぐみが少ないというのを見かけてウォータードリップのサーバーに変えてみました。 このひとつ前に水のタンクの部分がプラスチックのものを利用していたのですが、ドリップする部分を壊してしまったので、部品を購入することができるこちらに切り替えました。 朝、仕事をする前に豆を挽いて仕込んでおくと、昼にはコーヒーが落ちています。 夏は入れ終わったポットごと冷蔵庫に入れておくと氷を入れなくてもアイスコーヒーが飲めるので気に入っています。\neufyの掃除機 Amazon | Anker Eufy HomeVac H11（ハンディクリーナー） USB充電 仕事に使っている机でプラモデルを作ったり、DIYキーボードの工作をしたりと細かなごみが出る作業を行ないます。 ちょっとごみを吸いたいだけなのに、掃除機を毎回取りに行くのも面倒なので充電式のクリーナーを買ってみました。 仕組みも簡単だし、USBで充電できるのでおすすめです。アタッチメントを利用してキーボードの掃除なんかもしています。\n電動精密ドライバー Amazon | Wowstick 1F\u0026#43; 69in1 電動精密ドライバー ビット56種セット ケース USB充電式 LEDライト付き [並行輸入品] キースイッチを付け替えたり、工作したりでねじの開け閉めを頻繁に行います。 思ったよりも頻度が高くなってきたので、電動の精密ドライバーを試しに使ってみたらすごく楽ができました。 電池の入れ替えなどでもねじの開け閉めは行なうので、すごく役に立っています。 ビットが56種類もついていますが、プラスとマイナス以外はまだ使ってないかも。。。\n磁石のUSBケーブル Amazon | SUNTAIHO マグネット充電ケーブル DIYキーボード、エネループの充電器、上記のドライバーや掃除機など、USBで充電したり、接続するものが結構あります。 毎回ケーブルを差し替えるのも大変なのですが、@ymotongpooに教えてもらった磁石のUSBケーブルがお気に入りです。 先端部分（USB-C、micro）とケーブル部分が別々になっており、また、ケーブルと先端は磁石でくっつく構造なので、充電したい機器に先端部分を刺しておきます。 充電や接続したいときにケーブルを近づけると磁石でくっついてくれるのでケーブルの抜き差しが必要なくなります。 先端部分だけを個別に購入できたので、色々な機器にあらかじめつけてあります。\nMaker hart Just Mixer 5 Amazon | Maker hart Just Mixer 5 ステレオ5入力音声ミキサー/Bluetoothオーディオ入力対応 3台のPC＋音楽サーバーとしてラズパイを主に利用しており、通知音などを1つのスピーカーから聞きたいので、ミキサーを導入しました。 5つの入力個別に音量調節できるので打ち合わせの時だけ他の音源を小さくしたりなど重宝しています。 ただ、入力が増えるとノイズが乗っている気もしますが。。。\nリストレスト（アームレスト） Amazon | エレコム リストレスト アームレスト 肘起き 扇形 左右で使える2個セット ブラック MOH-EL01BK 扇形のものを分割キーボードの手間においてリストレストとして使っています。 使用例の写真を見ると肘を置いていますが、手のひらをおくのにちょうどいいです。 これまでいくつかパームレストを試してみましたが、凹凸もなく適度な硬さで気に入っています。\nコンテッサセコンダ Amazon | オカムラ オフィスチェア コンテッサ セコンダ 10月に注文してクリスマスに届きました。部品が不足しているようで年内に届かないかもといわれていたのですが。 2003年くらいからアーロンチェアを使っていたのですが、さすがに買い替えるかということで奮発しました。 アーロンチェアは座面がメッシュなのですが、ももが疲れるのもあり、クッション座面のものにしてみました。 冬寒くないのがいいですねｗまだ届いたばかりなので調整しないと。\nKindle paperwhite Amazon | Kindle Paperwhite - 大きくなった6.8インチディスプレイ 防水機能搭載 wifi 8GB 電子書籍リーダー 車の点検などでちょっとした待ち時間があるようなときに新書や小説が読めるようにセールで安くなったタイミングで購入しました。 健康診断で読書がはかどりました。もっと本を読まないとなぁ。\nということで、ここ数年で買って便利なものをまとめてみました。 他にもある気がするけど、とりあえずこの辺で。\n","date":1640784504,"dir":"post/2021/","id":"218e2c36d5945ece02fdc55d6cbcbc38","lang":"ja","lastmod":1640784504,"permalink":"https://blog.johtani.info/blog/2021/12/29/best-buy-2021/","publishdate":"2021-12-29T22:28:24+09:00","summary":"2021年もあと少しですが、今年買って良かったものをリストアップしておこうかと思います。 今年買ったといいながら、昨年このネタを書くといいつつ","tags":["misc"],"title":"2021年かって良かったもの"},{"contents":"Azure Cognitive Searchのスキーマの確認をするときに、Azureのポータルでは次のようにフィールドの一覧として見ることができます。\nただ、実際のインデックス定義はJSON形式でやり取りする形になっています（JSONの例：Create Index | Microsoft Docs）。 上記のスクリーンショットのようにフィールド数が少ない場合はそれほど気にならないのですが、フィールド数が大きくなると一覧で見たくなることがあります。 また、ポータルを自分で確認できない場合にJSONファイルを受け取って確認することもあります。 こういう時は、Excel（CSV）って便利ですよね？\nということで、サクッと確認するときには、次のようなjqコマンドをWSL2上で利用して、CSVに変換して確認しています。\necho \u0026#34;Name\u0026#34;, \u0026#34;Type\u0026#34;, \u0026#34;Searchable\u0026#34;, \u0026#34;Facetable\u0026#34;, \u0026#34;Filterable\u0026#34;, \u0026#34;Retrievable\u0026#34;, \u0026#34;Sortable\u0026#34;, \u0026#34;Analyzer\u0026#34;, \u0026#34;IndexAnalyzer\u0026#34;, \u0026#34;SearchAnalyzer\u0026#34; \u0026gt; index_schema.csv cat index_schema.json | jq -r \u0026#39;.fields[]|[.name, .type, .searchable, .facetable, .filterable, .retrievable, .sortable, .analyzer, .indexAnalyzer, .searchAnalyzer]|@csv\u0026#39; \u0026gt;\u0026gt; index_schema.csv 例えばこんな感じになります（上記のポータルのスクショとは別のスキーマですが。。。）。\nどんなフィールドオプションが利用されているか？などをExcelで開いてフィルターなどを活用してチェックするのには便利かなと。 jqコマンドをもっとうまく使うと、ヘッダ行ももっとスマートに出せるかもしれないんですが。。。\nちなみに、上記のコマンドでは残念ながらEdm.ComplexType（参考： 複合データ型をモデル化する方法 - Azure Cognitive Search | Microsoft Docs）には対応していません。 必要になった時に考えるかな。。。\n","date":1640141671,"dir":"post/2021/","id":"f0fdc140e18514362a4e52376a6fecba","lang":"ja","lastmod":1640141671,"permalink":"https://blog.johtani.info/blog/2021/12/22/azure-search-schema-json2csv/","publishdate":"2021-12-22T11:54:31+09:00","summary":"Azure Cognitive Searchのスキーマの確認をするときに、Azureのポータルでは次のようにフィールドの一覧として見ることができます。 ただ、実際のインデ","tags":["azure search","misc"],"title":"Azure Cognitive SearchのIndex Schema JSONをCSVで見たくなる"},{"contents":"今年もアドベントカレンダーの季節になってしまいました。 今年で2回目となる、pyspa Advent Calendar 2021の投稿です。 昨年に引き続きDIYがらみの投稿です。\nコントローラーラック 3つのコントローラーがあるのですが、結構場所を取ります。 また、それぞれ充電しないといけません。\n充電しつつ、邪魔にならない置き方はできないものか？と思っていたところ次のようなコントローラーラックを見つけました。\nAmazon | 山崎実業(Yamazaki) ゲームコントローラー収納ラック これそのものは場所を取るので購入は見送りましたが、エレクターの棚にワイヤーネットをつけると似たようなものができるのでは？ということで、DIYしてみることにしました。\n材料 材料は以下の通りです。 書いていない材料としてあとは、結束バンドがあります。\nワイヤーネット４４×２９．５ｃｍ オフホワイトＢ２８ | 【公式】DAISO（ダイソー）ネットストア スリム型ネットフック５０ｍｍ ２本入り | 【公式】DAISO（ダイソー）ネットストア クロームメッキワイヤーフック（２連、Ｕ字、２個） | 【公式】DAISO（ダイソー）ネットストア Amazon | マグネット 充電ケーブル SUNTAIHO USBケーブル LEDインジケーター付き Amazon | Anker PowerPort Atom III Slim （PD 充電器 65W 4ポート USB-C） 設置 まずは、2連のワイヤーフックでワイヤーネットをエレクターの棚にぶら下げました。\nそのままでは固定されないので、下のエレクターの棚とワイヤーネットを結束バンドで固定。 これで、コントローラーを置いたり取ったりしてもぐらぐらしません。\n固定したワイヤーネットの表（コントローラーを配置する側）に、ネットフック50mmをコントローラーの数だけ配置しました（上の写真でフックとコントローラーの関係がわかります）。\n前から見るとこのような形です。 裏側に、2連フックを使って、Ankerの充電器を固定し、USBのケーブルをコントローラーの上に来るように配置します（写真ではPS4とPS5のコントローラーの上の部分にぶら下がる形です）。\nコントローラーには磁石の端子をコントローラーに差し込んでおきます。\n磁石のUSBケーブルを利用していることで、コントローラーを取り出すときは少し力を入れて引っ張るだけ、収めるときは、ケーブルに近づけて充電できる状態にした後にフックに載せるだけとなりました。 ケーブルの抜き差しをしなくてもよいのでとても便利。 全体像は次の写真のようになっています。一番上のコントローラーはエネループを利用しているのでケーブルは不要になっています。\n磁石のUSBケーブルをpyspaでとんぷーに教えてもらって思いついたアイデアです。 磁石の端子は色々と使い勝手が良いので、DIYキーボードやテンキー、MX Ergo、Kindleなど色々なところに使っています。\n今年のDIYキーボード キーボードを作ったのは2つですが、改造を色々やってました。 ブログに記載したものはリンクだけにしておきます。\nケーブル自作 自作ケーブルキット – 遊舎工房 ケーブルも自作できるみたいなので作ってみました。 現在はテンキーの配置の問題もあって、メインでは利用はしていませんが工作としては面白かったです。 熱収縮チューブを処理するための道具を持っていなかったので、チューブの固定が甘いのが失敗でした。ドライヤーくらいの熱では足りないので作ろうと思っている方は要注意かと。\nCorne Light v2のBLE+LPME-IO対応 詳細はブログ記事を。Corneはこれ以外に、キースイッチの付け替えも行ないました。ルブしたGateronクリアをハンダでつけなおしました。\nCorne Light v2のBLE+LPME-IO対応 #DIYキーボード Sofle keyboard v2のBLE+LPME-IO対応 詳細はブログ記事を。このブログはSofleで書いています。現在メインに利用しているキーボードです。\nSofle v2を組み立てて、BLE+LPME-IO化してみた #DIYキーボード 10月には電池モジュールを次のものに付け替えました。家で主に使用するのもあり、充電池のほうが使い勝手がよさそうだという判断です。スイッチのON/OFFもしやすくなって満足しています。\n単4電池昇圧モジュール - のぎけす屋 - BOOTH Sofleの電池モジュールをボタン電池から単4電池用に差し替えた。 pic.twitter.com/TUizwr2qmw\n\u0026mdash; Jun Ohtani (@johtani) October 16, 2021 Lunakey Miniの組み立てとBLE+LPME-IO対応 詳細はブログ記事を。Sofleと時々入れ替えて使っています。小指のあたりのずれの大きさ、親指のキーの多さが使い勝手のよいキーボードです。コンパクトなのもあり、こちらは持ち運びにも利用できるかなと考えています。\nLunakey Miniを組み立てて、BLE+LPME-IO化してみた #DIYキーボード Soyuzの組み立て（Numpadキット） Soyuz （黒基板） – 遊舎工房 自宅の作業環境(2021/02)の写真にもありますが、分割したキーボードとは別にテンキーを利用しています。 WindowsのログインでPinコードを入力したり、色々な場面で数字の入力をすることがあるためです。 Soyuzを組み立てる前は素 - Shiro – 遊舎工房を利用していたのですが、これでは「⁺」や「Enter」など、電卓のような利用方法の場合にはキーが足りません。 かゆいところに手が届かないので、きちんとしたNumpadをということでSoyuzを組み立てました。\nShiroよりもだいぶ存在感があります。\nGK21S（Numpad） USB Type C充電器付きの滑らかな交換用キーボードキット (Gk21s/k21),スイッチ,デュアルモードPCB|Keyboards| - AliExpress 最後は独身の日のセールで見つけたNumpadキットです。キットといってもこちらは、基盤からケースまで組み立てが終わっているキットで、キースイッチを差し込んで、キーキャップを付けるだけというものになります。 現在はこれをメインに利用しています。通常のNumpadの上に1列キーが多く、Backspaceなどを割り当てられるのが便利です。 ドライバーソフトも用意されており、キーマップのカスタマイズも可能です（まだそこまでやってないけど）。\nお気に入りキースイッチ Kailh Box Silent ピンク軸 5個 | Kochi Keyboard Input Club Hako スイッチ（10個入り） – 遊舎工房 最後はキースイッチの紹介です。 現時点ではこの2種類を組み合わせるのが私の好みに合っているようです（今のところ）。 Box Silentのピンクをアルファベットのキーに、Input Club HakoのVioletをCtrlやShift、Enterなどのキーに割り当てて使っています（下の写真の左側で、キーキャップをつけている部分がHako Violetになっています）。\nまとめ ということで、pyspa Advent Calendar 2021の8日目の記事でした。 それほど作ったりしてないなと思っていたのですが、記事にしてみると今年も色々とDIYしてたみたいです。 キースイッチやキーキャップも自分の好みが固まってきたので、来年はファームウェアやキーマップ周りをいじっていきたいと思っています。\n","date":1638889200,"dir":"post/2021/","id":"26e44dfd16a2963d4c18e99806c26fd7","lang":"ja","lastmod":1638889200,"permalink":"https://blog.johtani.info/blog/2021/12/08/controller-rack/","publishdate":"2021-12-08T00:00:00+09:00","summary":"今年もアドベントカレンダーの季節になってしまいました。 今年で2回目となる、pyspa Advent Calendar 2021の投稿です。 昨年に引き続きDIYがらみの投稿","tags":["DIYキーボード","misc"],"title":"今年のDIYキーボードとコントローラーラック"},{"contents":"Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだので軽くメモを残しておきます。論文自体はリンクから参照してください。\n読んだ理由 Azure Cognitive SearchでSemantic Searchが利用可能になったこともあり、「Semantic Search」に関するMSのリサーチチームが発表している論文をたまたま見つけたためです。 Elasticsearchとニューラルモデルを利用したランカーでのリランクする仕組みがSemantic Searchと似ていたので読んでみました。\nざっくりメモ どんなもの？ クリックログなどで関連度を改善できないような場合に、ドメイン固有の言語モデルを利用して検索結果の改善をする方法が提案されているので、バイオメディカル検索で実際に評価してみたという論文です。 特定分野の大量の文書から検索をするときに、ドメイン固有の事前学習した言語モデルを用意して、さらにファインチューニングする方法を評価しています。 言語モデルの生成に利用されたのはBERTになります。\n技術や手法のキモはどこ？ 医療分野のデータを利用して評価していますが、ほかのドメインにも一般化できる可能性があることや、実際のシステムを提示している部分が肝になりそうです。\n論文から引用した言語モデルを用いてランキングを行う仕組みを構築する部分の構成です。\n左半分が、ドメイン固有の事前学習についてです。Wikipediaなどを利用したBERTのモデルが公開されたりしていますが、大量のドメイン固有データが用意できるのであれば、ドメイン固有のデータで事前学習することが有効であるという主張です（参考文献。これもMS Researchでした。同じチームなのかな？）。 この論文ではBERTの学習データとして、ドメイン固有のテキストを用いています。 実際にはPubMedBERTを利用しています。\n右半分がドメイン固有のデータで生成された言語モデルを利用して、ドメイン固有のニューラルランカー（検索結果のランキングを行なう仕組み）をファインチューニングする処理です。 MS MARCOと呼ばれるMSが公開している機械学習向けのデータセットのうち、ドメイン固有のサブセットを取り出して利用しているようです。\nこの論文では、L1検索（第1段階の検索）にBM25を利用して、L2検索にここで作成したニューラルランカーを利用し、検索結果を返す仕組みとなっています。 これは、Azure Cognitive SearchのSemantic Searchのシステムに似ています。\nこの論文では、BM25で検索した結果の上位60件の結果がL2のランカーの入力となっています。\n以下の2つが主な論文の成果となっています。\nドメイン固有の事前学習を利用することで、高度な学習コンポーネントなどの追加することなく高い精度が出た。 既存のBM25の検索エンジンと組み合わせてニューラルランカーを使うことで、計算コストを下げつつより良い上位の検索結果を返す仕組みを構築した。 どうやって有効だと検証した？ TREC-COVIDデータセットを用いて評価して、TREC-COVIDに参加しているシステムと論文で提案している構成のシステムとの比較をしています。 また、ドメイン固有の事前学習が、一般ドメインなどの事前学習と比較して影響があるかどうかの評価もしています。\n実際にAzure上で構築した仕組みをMicrosoft Biomedical Searchとして公開しているようです。 上記のシステム構成のように、Elasticsearchで検索して、ニューラルランカーはKubernetes上に展開されたGPUで計算をしています。 論文には使用しているマシンの構成や台数なども記載があります。\n実際に構築したシステムをユーザーに利用して体験したもらった結果としては、 複雑な意図を持った長いクエリに対してはPubMedなどの他の検索ツールとしても良い結果が返ってきたことが確認されたとなっています。 ただし、一般的な短いクエリの場合は十分な結果にならない場合があったとのことです。\n議論はある？ 実際にほかのドメイン（金融、法律、小売りなど）で適用してもうまくいくかは今後の研究に期待だと思います。 また、ファインチューニングするときに利用できるデータが今回の論文にあるようにMS MARCOのサブセットとして抽出できればよさそうです。\n他に読むべき論文は？ TREC-COVIDに参加しているほかのシステムがどのような学習や仕組みが必要なのかを見ることで、どのくらいの手間・コストが軽減しているのかがわかるはずです。\n感想 ということで、読んでみました。 細かなほかの手法については調べていませんが、システム構成としてはAzure Cognitive SearchのSemantic Searchの仕組みと同じだと思われます。 違いは、ドメイン固有の事前学習のモデルではないことでしょうか。 ある程度のドメイン固有のモデルを利用できる仕組みができると、さらにSemantic Searchがうまく使えるようになるのかもしれません（前回書いたブログではWikipediaのデータを利用してみましたが、思ったほど良い感じはしなかったです。。。ファインチューニングの仕組みもないしなぁ）。 また、短いクエリでは芳しくない結果もあったというのは、おそらくニューラルランカーで評価するための情報が少なくなってしまうのだと思います。Semantic Searchに向いているクエリの作り方とかが出てくるのかな？\n","date":1636522396,"dir":"post/2021/","id":"35200cbf0b5b45d7f5f0b343cb18868b","lang":"ja","lastmod":1636522396,"permalink":"https://blog.johtani.info/blog/2021/11/10/reading-ms-biomedical-search-paper/","publishdate":"2021-11-10T14:33:16+09:00","summary":"Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだので軽くメモを残しておきます。論文自体はリンクから参照してください。 読んだ理由 Azure Cognitive S","tags":["search","paper"],"title":"Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだ"},{"contents":"今年もMICESにも参加してました。 昨年はBerlin Buzzwordsと共同開催でしたが、今年は別開催（別日程）でした。\nMICESは2017年から始まったe-commerceの検索にフォーカスしたカンファレンスです。 ECに関連する話に特化されていますが、話題は多岐にわたっています。色々やることありますねぇ、ECも。\n参加したセッション 参加したセッションの個人メモを今回も残しておきます。 セッション個別のリンクは用意されていないみたいですが、公式サイトにタイムテーブルがあり、セッションのタイトル、概要に加えて、スライドのPDFもリンクがあります。動画が公開されているものもあります。\nDreaming Search ビデオが公開されています。スライドがざっくりしたものなので最初に聞いた時にはしっくりこなかったので、聞き直してのメモです。 GDPRのような話で、個人の情報を自分たちで管理しようと流れがあります。 それぞれのECサイトなどでのユーザーのイベント（何を検索して、何をクリックした）情報はそれぞれのサイトで閉じた情報になっています。このため、自分の興味のある情報が断片化された情報でそれぞれのサイトで管理されてしまい、パーソナライゼーションされるもの（ランキングだったりレコメンドだったり）がいまいちな場合があります。 この個人の情報（ユーザーのイベント）をユーザー自身がハンドリングして、どの情報までをどこまで公開できるようにするというように管理できる仕組みができないか？という話のようでした。実際にそのための仕組み（もっと大きな話の仕様）を検討しているプロジェクトがあり、それに関連して検索という観点で夢を語っているセッションです。\nざっくり私が理解したのをまとめましたが、empathy.coという会社としてはいくつかPoCなども実施されているようでした。 個人の情報の扱い方に関する話は新鮮で面白かったです。 仕組みが出来上がり、各サイトが対応するとより個人が欲しい情報が集まりやすくなるのかなぁ？\nForget Facets, welcome Refinements (TM) Berlin BuzzwordsでいくつかLTをやられていた方によるファセットとその応用（彼らはRefinementsと名前をつけたみたい）についての話でした（ビデオとスライドが公開済み。）。 検索エンジンとファセットの関係の歴史から始まって、Kibanaでの使い方、モバイルや音声検索・チャットボットでのファセットは難しいよね？という話につながります。 ということで、Refinementsとして、ファセットを提示してユーザーに選んでもらうだけでなく状況に応じて、提案するための情報としてファセットを使うといいのでは？という話でした。例えば、チャットボットや音声検索での結果の場合、検索結果数が多くなるとユーザーが望んだものが返せるとは限らないです。その時に、ファセットの情報をもとに絞り込み条件を聞き返すネタに使うのはどうか？というような話でした。オートサジェスト（検索があいまいな時に、追加のキーワードを提案するもの）のような形でブランド名だったり、カテゴリーなどを表示する仕組みです。 実際の実装の話は、彼らが過去にBerlin Buzzwordsなどで話をしているのでそちらが参考になるとのことでした（参考：berlin buzzwords 2019 / Heystack 2019）\nReinforcement learning in search 検索における強化学習の話みたいです。ビデオとスライドが公開されています。ビジネス的に検索のランキングが重要だが、そのランキングをどうやって良くしていくのか？という話です。 ランキングでデフォルトのBM25から始まり、LtRを導入し、A/Bテストなどをしつつ、モデルの変化がどのようにビジネスに影響するかをはかるのが難しくなります。 LtRに対するオンライン機械学習のアプローチについて実際に直面した課題の話などがされている（はず？）です（どうも、実際にCTRなどを用いたところまでは行ってなさそう）。\n多腕バンディットなどの強化学習の話が続いたあたりでギブアップしてしまいました。。。\nBetter Search through Query Understanding - Panel Query Understandingに関するパネルとして3社の人がそれぞれどういった取り組みをしてるか？という話をしたあと質問などに答えていく形式でした。残念ながらビデオはまだ公開されていませんが、スライドが公開されています。QA部分も結構な時間だったのでビデオの公開がされるといいなぁ。\nUnderstanding queries by analysing user interaction / Andrea Schütt (OTTO) OTTOというECサイトでのQuery Understandingの紹介と、LtR導入にまつわる話。 データサイエンスとして最初はQuery Understandingやってたけど、スケールしないのでLtR導入して色々と試行錯誤しているところのようだった。\nQuery Understanding AI search eBayの方の発表。Query Understanding = ユーザーの興味をクエリから類推するという定義から、クエリを分類する、同定するためにどうしているか？という話でっした。 単語の表面的な文字としての近さだけでは、語順が変わると意味が変わるものや、ステミングのせいで同じになってしまうものといった例を紹介しつつ、クエリをベクトルにして表現（コンバージョン、クリックなどの情報を元にプロダクトのベクトルにしてみたり）し似ているかどうか？を判断している話です。\nCase study : Autocomplete Search Suggestions Digitec Galaxusというサイトでのオートコンプリートをもっと使いやすくするためにどんなデータを集めて、どうやって表示しているか？という話でした。 とりあえず入力されたものにヒットしたものを出すような実装だった場合に、サジェストされる量が多く、ノイズも多いので使いにくかったものをどうやって改善して行ったかという処理の流れなどの説明もありました。\nThe need for an open web search in Europe - The approach of the Open Search Foundation and its implications for E-Commerce-Companies Speaker: Alexander Decker / OPEN SEARCH FOUNDATION\nもっとオープンな検索システムを作っていこうという団体の話でした。 AWSが最近1.0をリリースしたやつとは別物です。 Googleでみんな検索しているけど、ブラックボックスなのでバイアスがかかっている。 もっとバイアスフリーなインデックスを提供できると、使いやすくなるよね？みんなでそういうインデックスを作っていかないか？という話でした。 ECとの直接の関係はセッションからは読み取れませんでした。 どうやって、集めるデータの基準（入れるべき、入れるべきではないなど）を作るんだろう？という疑問が残っています。公共的なものやオープンデータについてはあるとよさそうかもなぁ。\n101 hints to improving the customer satisfaction on search engines in the retail industry Speaker: Marion Hemery (Carrefour France) \u0026amp; Lucian Precup (a// \u0026amp; Adelean)\nカルフールのECサイトでの検索に関する顧客満足度の改善についての話です。 どんなものをどうやって図るのか、フィードバックを取るための仕組みは？ そこからわかったものをどうやってシステムに優先度をつけながら取り込んでいくのか？ というのをどんなものを使っているかという説明を交えながらのセッションです。 スライドが結構細かく書かれているのでスライドを見るだけでもわかりやすいかな。\n“An ounce of prevention is worth a pound of cure”: establishing a gold standard-based evaluation in customer projects Speaker: Bertram Sändig \u0026amp; Cornelia Werk / NEOFONIE\n検索の性能指標（速度ではないほうの性能）をきちんと評価する仕組みが重要だよというセッションです。 検索の仕組みを変更（例ではステミングを導入するはなしをしてました）した場合に、現行システムにどういう影響が出るのか？それをどうやって図るのか、どうやってテストしていくのか？という話です。 ステミングを導入したら、検索にヒットしやすくなったものも出てきたけどその弊害として今までよかった検索の結果にノイズが増え多という話をもとに、検索結果としてこうあってほしいというゴールデンスタンダードをきちんと作って育てていくべきですよという話でした。完ぺきなものなどないので少しずつやっていきましょうと。\nということで、見ていないもの（LTや最後のワークショップ）もありますが、見たものに関してメモを残してみました。\n","date":1626160103,"dir":"post/2021/","id":"10a7f69bd03d2632722300194f01e93d","lang":"ja","lastmod":1626160103,"permalink":"https://blog.johtani.info/blog/2021/07/13/attend-mices-2021/","publishdate":"2021-07-13T16:08:23+09:00","summary":"今年もMICESにも参加してました。 昨年はBerlin Buzzwordsと共同開催でしたが、今年は別開催（別日程）でした。 MICESは201","tags":["conference","berlin buzzwords","MICES"],"title":"今年もMICESにオンライン出張してた"},{"contents":"今年もBerlin Buzzwordsにオンライン出張してました。 今年の開催は6月14日から17日まででした。 どんなカンファレンスなのかは昨年のブログ記事をごらんください。\n今年はHAYSTACKは共同開催で、MICESは別開催でした。 MICESにも参加していたので、また後日にブログ記事を公開する予定です。\n参加したセッション 参加したセッションの個人用のメモを取ってあるので、簡単にまとめておきます。 セッションページに動画やスライドも追加されつつあります。興味のある方はそちらをご覧いただければと。 （今のところYouTubeに上がっているビデオは69本あります。再生リストはこちら） 気になっていたセッションもあるので、ビデオを見てまたメモを公開すると思いますが、まずは第1弾を。 ちなみに、検索をメインに見ています。Berlin Buzzwords自体はオブザバビリティやOSSコミュニティ、データのストリーミングの話などの話題もあるので、この辺りも興味があれば探してみても面白いかもです。\nHow to measure Diversity of Search Results セッションページ： How to measure Diversity of Search Results | Berlin Buzzwords 2021 従来の検索では、クエリに対して精度の高い検索結果を1件または数件返すのはどうするか？というものだったが、最近、あるユースケース（ほかの物の発見を促したいケース）では 検索結果の多様性を高めつつ、精度もある程度確保したいという場合があります。\nざっくりした検索クエリ（例えば自転車）の場合に、自転車だけが1ページ目にある場合よりも自転車とは別に自転車グッズも表示された場合のほうがクリック率やGMV（Gross Merchandice Value?）が上がったという話が紹介されていました。 この時どのくらい混ぜればいいのか？というのを、シャノンのエントロピーを使って、検索結果の多様性を保つための具体的なヒントについて話をされています。 実際にこういう計算をしてやれますねという紹介がされています。\nFrom text search and recommendation to ads and online dating; approximate nearest neighbors in real world applications セッションページ: From text search and recommendation to ads and online dating; approximate nearest neighbors in real world applications | Berlin Buzzwords 2021 Vespa.ai（OSS）の紹介でANNの話でした。通常、ANNを用いた検索の場合に他の検索条件（地理情報、日付など）をANNの結果に対して適用すると、望んでいる数がとれないです。その場合に、Vespaは内部でいい感じの動きをしますよという紹介でした。\n\u0026ldquo;Are You Sure?\u0026quot;： blending product comparisons and recommendations with A.I. セッションページ: \u0026ldquo;Are You Sure?\u0026quot;： blending product comparisons and recommendations with A.I. | Berlin Buzzwords 2021 Amazonの製品ページにある、類似商品との比較一覧のような一覧をどうやって実現するか？という話でした。比較一覧に掲載する商品を選出するパイプラインをこうやれますよね?という話でした。ログ（クリックやカートに入れたかどうかなど）を元にkNNで似ているデータを洗い出し、どの商品、どの項目を比較一覧として選ぶかという流れでした（セッションではもっと詳しい話がされています）。オフライン実験の話までがセッションでされています。\nThe future of Lucene\u0026rsquo;s MMapDirectory： Why use it and what\u0026rsquo;s coming with Java 16 and later? セッションページ: The future of Lucene\u0026rsquo;s MMapDirectory： Why use it and what\u0026rsquo;s coming with Java 16 and later? | Berlin Buzzwords 2021 Apache Lucene PMCのUweさんによるLuceneのMMapDirectoryの話です。 ファイルシステムとJavaに関する歴史と、なぜMMapなのか、現在のMMapの実装の問題点とJDK 16でどうなっているか（どんな感触か）、さらにその先（JDK17）は？という話です。 Luceneでの利用方法からJDKへのフィードバックが行われている話や、そのフィードバックをもとに今後どのようにしていくのか?という話がされています。\nSearch and Sushi; Freshness Counts セッションページ: Search and Sushi; Freshness Counts | Berlin Buzzwords 2021 こちらもVespa.aiの紹介です（今年はスポンサーしてるから多いのかも？）。Yahoo!とVerizon Mediaで利用している話をしたあと、Vespaでのリアルタイムインデキシングに関するアーキテクチャの紹介でした。内部で転置インデックスやそれ以外のデータをどのように保持しているのか？どういったことができるのか？というのをアーキテクチャ、ストレージの観点から紹介しています。\nEncores? - Going beyond matching and ranking of search results セッションページ(動画がまだない): Encores? - Going beyond matching and ranking of search results | Berlin Buzzwords 2021 検索のマッチングやランキング以外のいくつかの機能についての紹介をワークショップ形式で行うセッションです。ファセット、クエリオートコンプリート、スペル訂正、クエリリラクゼーションについて、データとSolrのクエリを基準に説明をしてくれます。\nThe Invasion of Transformers - Boosting Search with Latest NLP セッションページ: The Invasion of Transformers - Boosting Search with Latest NLP | Berlin Buzzwords 2021 deepsetという会社のCTOの方で、自社で作っているOSSのhaystackという製品の紹介です。 最近のGoogleの検索結果にはいろんなもの（問いかけに関する答えそのもの、またそのプレビューやサマリー）が出てきているという話から、Transformersを使って検索ができないかということで自社のOSSの仕組みを紹介しています。\n参考 Google： BERT now used on almost every English query deepset-ai/haystack： End-to-end Python framework for building natural language search interfaces to data. Leverages Transformers and the State-of-the-Art of NLP. Supports DPR, Elasticsearch, Hugging Face’s Hub, and much more! Learning to Judge セッションページ: Learning to Judge | Berlin Buzzwords 2021 otto.deというECサイトでLtRを導入し、そのLtRにどんな特徴を利用しどうやって実験したかというセッションでした。Apache Solrで検索ができていて、これまでは検索の管理を人手で行っていたがスケールしない（扱う商品などは増えているのに）のでLtRを導入し始めたという感じでした。LtRの導入の過程でどういう仮定を置いて、どうモデルを決め、それをどうやってテストしてどう分析したか?という流れでした。\nText categorization with Apache Lucene セッションページ: Text categorization with Apache Lucene | Berlin Buzzwords 2021 LTなので短めです。BBCのデータセットをインデックスに登録し、そのデータをもとにLucene（デモではKibana＋Esを利用していた）でテキスト分類を行なう方法について紹介しています。BBCのデータセットは記事（テキスト）とカテゴリ（タグ）というデータです。 このデータが登録されているインデックスに対して、More Like Thisクエリに分類したい文章を与え、ヒットしたデータをもとにAggregationでカテゴリを取得し、上位のカテゴリが分類された結果になるというデモでした。 テキストフィールドにはEdge N-Gramを利用していること、Aggregationのソートの条件はMore Like Thisクエリでのスコアの平均を利用していることというのがこの方法がうまくいくことのようでした（なるほど！）。ただ、日本語でもこれが使えるかな？というのはやってみないとわからないかなぁと（やってないです）。\nとりあえず、メモしておいたのはこの辺でした。 他にもセッション一覧を眺めながら面白そうな話をピックアップしてメモを取っていこうかなぁ？気になるセッション、メモがおかしいなどあればコメントいただければと。\n","date":1625815493,"dir":"post/2021/","id":"59b7b60e6bbf4858d72643d22ad90451","lang":"ja","lastmod":1625815493,"permalink":"https://blog.johtani.info/blog/2021/07/09/berlin-buzzwords-2021-1/","publishdate":"2021-07-09T16:24:53+09:00","summary":"今年もBerlin Buzzwordsにオンライン出張してました。 今年の開催は6月14日から17日まででした。 どんなカンファレンスなのかは昨年","tags":["conference","berlin buzzwords"],"title":"今年もBerlin Buzzwordsにオンライン出張してた"},{"contents":"Azure Cognitive Searchで新機能「Semantic Search（セマンティック検索）」という機能の日本語対応が発表されました。 実際にはPublic Previewという状態ではありますが、どんな機能か気になったので調べてみました。 なお、本ブログは2021年6月時点での内容となります。\n公式ドキュメント 公式ドキュメントでいろいろと説明されています。まずは公式ドキュメントを見ていただくのが良いかなと。最初のドキュメントには10分ちょっとの紹介ビデオもあります。ピックアップしたのは概要、クエリ、レスポンスの構造、紹介ブログになります。ブログ以外は日本語（たぶん機械翻訳？）になっています(新機能の紹介の日本語ページにはまだ記載がありません)。\nSemantic search - Azure Cognitive Search | Microsoft Docs Create a semantic query - Azure Cognitive Search | Microsoft Docs Structure a semantic response - Azure Cognitive Search | Microsoft Docs The science behind semantic search： How AI from Bing is powering Azure Cognitive Search - Microsoft Research 簡単にですがデータを入れて試してみたので、どんな仕組みなのかどういう挙動なのかを紹介します。\nSemantic Searchとは？ 言語理解、セマンティック関連性などを提供する機能です。BingとMSリサーチにより開発されて、Azure Cognitive Searchに導入されました。 クエリの書き方を少し変更する必要がありますが、再インデックスや設定変更などは必要ないという仕組みになっています。\n検索クエリからコンテキストを読み取って、検索し、リランクするアルゴリズム(Semantic Ranker) 関連する一節を強調表示（Semantic Caption） クエリに対するセマンティック回答(Semantic Answer) スペルチェック機能 言語によって利用できる機能が異なります。\nSemantic Searchの利点は先ほどの紹介にも書きましたが、インデキシング時に特殊処理をする必要がないことかなと。 すでに登録してあるデータ（制限がありますが）でもすぐに試すことができます。\n仕組み https://docs.microsoft.com/ja-jp/azure/search/media/semantic-search-overview/semantic-query-architecture.png\nスペル修正機能 クエリパース スコアリング 上位50件に対してSemantic Rankerにより再評価（検索ヒットが50件以上の場合でも上位50件のみがリランクの対象） 言語表現モデルを利用 結果の要約として最適な部分をキャプションとして抽出。 クエリが質問形式の場合は一番よさそうな場所を回答として選択 1および4番目の処理が今回新しく使えるSemantic Searchの機能になります。スペルチェックは日本語がまだ対象外なので、4番目の機能について紹介します。\n利用できる環境と制限 冒頭でも書きましたが、Public Previewの段階です。実際に利用するにはリクエストページから申し込みが必要になっています。\n利用リクエスト時に利用するAzure Cognitive Searchのサービス名が必要になるので、あらかじめ起動しておかなければいけません。 また、利用できるリージョンが限定されているのでサービス起動時のリージョンには気を付けてください。\n利用できるリージョン 米国中北部、米国西部、米国西部 2、米国東部 2、北ヨーロッパ、西ヨーロッパ 利用できるTier セマンティック検索はStandardレベル スペルチェックはレベル制限なし 価格（セマンティック検索のみ） 7月初旬までは25万クエリで500ドル Analyzerの制限 Azure Cognitive Searchが提供する言語アナライザーが対象（Custom Analyzerでは利用不可） サービス起動後にプレビュープログラムを申請すると、利用できるようになるとメールが届きます。そこから利用ができるようになります。\n今回は日本語のWikipediaのデータをいれてどんな機能なのかを確認してみました。\nWikipediaのデータを入れて試してみた 日本語のWikipedia（あとで英語も入れました）を一部（10万件程度）登録してSemantic Search（主にRanker）の動きを確認してみました。\nデータの登録には自作ツールを利用。\nJSONデータ生成ツール：https://github.com/johtani/wiki-extractor-rs JSONデータ登録ツール：https://github.com/johtani/wiki-json-loader 日本語Wikipediaの2020年6月のデータ、英語Wikipediaの2021年6月のデータを利用。上記ツールで生成したもののうち約10万件をAzure Cognitive Searchに登録して動作確認をしました（英語のデータでJSONデータ生成ツールでバグがあるのですが修正していません。。。）。 また、クエリの実行にはVisual Studio CodeのREST Client拡張(どんなものかは以前のブログをご覧ください)を使いました。簡単にREST APIを呼び出せるのはすばらしい。\n日本語のWikipedia 日本語のWikipediaのデータを「96,344件」登録し実験しました。 スキーマは次のような形です（説明に必要なものだけ抽出してあります）。自然分が入っているtitle、contents、headingsの3つのフィールドを今回はSemantic Searchの対象にしてみるので、AnalyzerをLuceneベースの日本語Analyzerであるja.luceneを設定しました。\nフィールド名 : タイプ / Analyzer id : Edm.String / keyword categories : Collection(Edm.String) / keyword title : Edm.String / ja.lucene contents : Edm.String / ja.lucene headings : Edm.String / ja.lucene Analyzerに言語Analyzerを設定するくらいで、他の設定は特に必要ありません。\nクエリとデータの確認 デモの動画や説明のサンプルを見たところ英語で「Where was Alan Turing born?」や「What\u0026rsquo;s the capital of France?」のような自然文のクエリが出てきたので、次のようなクエリで試してみました。\nフランスの首都はどこですか？ 実際にパリのページがインデックスに存在していることは以下のクエリで確認しました。\nパリ：3047件 POST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;パリ\u0026#34;, \u0026#34;top\u0026#34;: 10, \u0026#34;searchFields\u0026#34;: \u0026#34;title, categories, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id, contents\u0026#34; } ※ここで{{host}}などはREST Client拡張で変数として定義したものです。\nhost : Azure Cognitive Searchのサービス名 index-name : インデックス名 api-key : 接続のためのAPIキー URLパラメータのapi-version=2020-06-30-PreviewがPreview機能を呼び出すための指定になっています。\n3047件の1件目が「パリ」のページで以下のようなWikipediaの文章をセクションごとに文字列としてページ全体を配列に入れてcontentsに登録してあります。\n\u0026#34;パリ（、巴里）は、フランス北部、イル＝ド＝フランス地域圏にある都市。フランスの首都であり、イル＝ド＝フランス地域圏の首府である。\\nフランス最大の都市であり、同国の政治、経済、文化などの中心である。ロンドンと共に欧州を代表する世界都市。行政上では、1コミューン単独で県を構成する特別市であり、ルーヴル美術館を含む1区を中心に、時計回りに20の行政区が並ぶ（エスカルゴと形容される）。\u0026#34;, このインデックスに対して「フランスの首都はどこですか？」というクエリを、セマンティック検索のクエリと通常のクエリの2パターンで検索をしてみました。\nこれまでのクエリ（セマンティックではない検索） まずは通常のクエリです。 searchがクエリ文字列、searchFieldsが検索対象フィールドになります。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;フランスの首都はどこですか？\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34; } クエリを実行するとヒット件数が'13996\u0026rsquo;件で、トップ5件のデータは次のようになりました。\n\u0026#34;@odata.count\u0026#34;: 13996, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 17.059355, \u0026#34;id\u0026#34;: \u0026#34;462\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;首都\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 16.086372, \u0026#34;id\u0026#34;: \u0026#34;21053\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;首都圏\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 15.059893, \u0026#34;id\u0026#34;: \u0026#34;71414\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;どこでもドア\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 14.086605, \u0026#34;id\u0026#34;: \u0026#34;51972\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;首都機能移転\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.996841, \u0026#34;id\u0026#34;: \u0026#34;3877\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;首都の一覧\u0026#34; }, 見るとわかりますが、「首都」「どこ」といった単語を含むデータが上位に入っています。「フランス」を含むデータは8件目と10件目に「フランス植民地帝国」、「ラ・フランス」といったデータが出てきます。\n{ \u0026#34;@search.score\u0026#34;: 12.705561, \u0026#34;id\u0026#34;: \u0026#34;129279\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランス植民地帝国\u0026#34; }, ... { \u0026#34;@search.score\u0026#34;: 12.036648, \u0026#34;id\u0026#34;: \u0026#34;3173\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ラ・フランス\u0026#34; }, 残念ながら望んでいる結果にはほど遠いかと。\nどんな検索になっているのでしょうか？まずは、クエリの解釈から。 デフォルトで、Azure Cognitive Searchはデフォルトでは、入力された文字列をtype=simple、mode=anyで検索します（クエリパラメータ参照）。 対象となるフィールドはsearchFieldsで今回は指定してあるので、これらのフィールドに対して、入力された文字列を渡してAnalyzerで単語分割し（今回はsimpleクエリ用の特殊文字が入っていないため文字列として扱われる）、 出てきた単語で（mode=anyだから）OR検索します。 ja.luceneのAnalyzerが出力する単語列がどんなものかは以下のリクエストを実行するとわかります。\nPOST https://{{host}}/indexes/{{index-name}}/analyze?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;analyzer\u0026#34;:\u0026#34;ja.lucene\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;フランスの首都はどこですか？\u0026#34; } 結果は以下の通りです。\n\u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;フランス\u0026#34;, \u0026#34;startOffset\u0026#34;: 0, \u0026#34;endOffset\u0026#34;: 4, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;首都\u0026#34;, \u0026#34;startOffset\u0026#34;: 5, \u0026#34;endOffset\u0026#34;: 7, \u0026#34;position\u0026#34;: 2 }, { \u0026#34;token\u0026#34;: \u0026#34;どこ\u0026#34;, \u0026#34;startOffset\u0026#34;: 8, \u0026#34;endOffset\u0026#34;: 10, \u0026#34;position\u0026#34;: 4 } ] これで、どのような単語が出てきているかがわかりました。 それぞれのフィールドでどのようなスコアになっているかまではわからないですが、検索結果には上記3つの単語のいずれかがsearchFieldsにヒットすれば出てきます。おそらく、ヒットした単語数が多い、短い文字列のフィールドがより高いスコアになるというような動きになっていると思われます（BM25になってるはず）。\nセマンティック検索 では、セマンティック検索のクエリに変更してみましょう。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;フランスの首都はどこですか？\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34;, \u0026#34;queryType\u0026#34;: \u0026#34;semantic\u0026#34;, \u0026#34;queryLanguage\u0026#34;: \u0026#34;ja-jp\u0026#34; } queryType、queryLanguageがセマンティック検索のクエリを実行するためのパラメータになります（公式ガイド参照）。 今回は日本語のデータであるため、日本語のモデルを利用するようにqueryLanguageを指定します（許可されていない文字列を渡すとエラーになる）。 この2つを追加するだけです。簡単ですね。\n結果は次のようになります（上位5件抜粋）。\n\u0026#34;@odata.count\u0026#34;: 13996, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 12.036648, \u0026#34;@search.rerankerScore\u0026#34;: 2.3456064984202385, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;ラ・フランス\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;ラ・フランス\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;3173\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ラ・フランス\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 11.144733, \u0026#34;@search.rerankerScore\u0026#34;: 2.3173404783010483, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;ラン (フランス)\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;ラン\u0026lt;/em\u0026gt; (\u0026lt;em\u0026gt;フランス)\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;108094\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ラン (フランス)\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 11.144793, \u0026#34;@search.rerankerScore\u0026#34;: 2.1937477812170982, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;ブレスト (フランス)\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;ブレスト\u0026lt;/em\u0026gt; (\u0026lt;em\u0026gt;フランス)\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;116154\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ブレスト (フランス)\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 10.199907, \u0026#34;@search.rerankerScore\u0026#34;: 2.1590753793716431, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;フランス・ハルス\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;フランス・ハルス\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;81566\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランス・ハルス\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 11.273148, \u0026#34;@search.rerankerScore\u0026#34;: 2.1434053033590317, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;バカロレア (フランス)\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;バカロレア\u0026lt;/em\u0026gt; (\u0026lt;em\u0026gt;フランス\u0026lt;/em\u0026gt;)\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;54514\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;バカロレア (フランス)\u0026#34; }, 検索結果数を見ると、通常のクエリと同じ値です。 これは、公式ドキュメントのセマンティック検索に説明があるように、 セマンティック検索が通常のクエリで実行した後の検索結果に対して、上位50件のデータだけに対してsemantic rankerによってスコアを再計算するという仕様のためです（ドキュメントからの推測）。\n実際に検索結果の50件目、51件目は次のようになっていました。50件目までのデータには@search.rerankerScoreというスコア（と@search.captions）が追加されています。 51件目のデータについては、前の通常のクエリの51件目のデータと同じデータでした。\n{ \u0026#34;@search.score\u0026#34;: 10.909212, \u0026#34;@search.rerankerScore\u0026#34;: 0.07321979058906436, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;首都高速埼玉大宮線\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;67667\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;首都高速埼玉大宮線\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 10.049902, \u0026#34;id\u0026#34;: \u0026#34;68569\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;スタッド・ド・フランス\u0026#34; }, 上位5件のデータに戻ります。 これらは、通常のクエリとは異なる結果となりました。 見ると@search.captionsというところにハイライトされた項目が表示されています。 検索クエリをもとにそれっぽい部分がキャプションという形で返ってくる仕組みです。\n結果を見るとわかりますが、残念ながら「パリ」のページは返ってきませんでした。 もともと通常のクエリを実行したときの「326」番目の結果として返ってきているため、セマンティック検索の対象とはならなかったためです。 ただ、「首都」「どこ」といった単語よりも「フランス」に関するドキュメントが通常の検索よりも上位に来ています。 クエリに存在する単語で「フランス」がより重要であると判断されているようです。\nSemantic Rankerに処理させてみる ちなみに、今回登録したデータにはWikipediaのカテゴリも登録してあります。 「ヨーロッパの首都」というカテゴリで絞り込んでから検索してみるとどうなるかもやってみました。 filterのパラメータが絞り込み条件です。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;フランスの首都はどこですか？\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34;, \u0026#34;queryType\u0026#34;: \u0026#34;semantic\u0026#34;, \u0026#34;queryLanguage\u0026#34;: \u0026#34;ja-jp\u0026#34;, \u0026#34;filter\u0026#34;: \u0026#34;search.ismatch(\u0026#39;ヨーロッパの首都\u0026#39;, \u0026#39;categories\u0026#39;)\u0026#34; } 結果は次の通りです。カテゴリで絞り込みをしているので検索結果数は39件となります。このため、すべてのデータがSemantic Rankerの対象です。 ですが、「パリ」のページは11件目に出てきました。\n\u0026#34;@odata.count\u0026#34;: 39, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 3.8405614, \u0026#34;@search.rerankerScore\u0026#34;: 2.0472740978002548, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;ウィーン\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;9465\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ウィーン\u0026#34; }, ... { \u0026#34;@search.score\u0026#34;: 4.8915977, \u0026#34;@search.rerankerScore\u0026#34;: 1.8480307757854462, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;レイキャヴィーク\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;レイキャヴィーク\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;112253\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;レイキャヴィーク\u0026#34; }, ... { \u0026#34;@search.score\u0026#34;: 7.277628, \u0026#34;@search.rerankerScore\u0026#34;: 1.7982495501637459, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;パリ\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;パリ\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;31\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;パリ\u0026#34; }, キャプションは入力された単語だけではなく、クエリが持っている単語をもとにした何かしらの基準（おそらく言語モデルで近い単語？）で選択されていると思われます。首都というカテゴリーで絞り込んでしまったので、ヒットした文章が似たようなものが多くなったせいか、残念ながらそこまでSemantic Rankerが意図を汲み取るところまでは行きませんでした。\nフランスの歴史 視点を変えてみましょう。質問そのものの答えではなく、クエリの意図に近いものが出てくるかを見てみましょう。 ここまでのクエリでフランスに関するクエリを投げていました。今回のインデックスに「フランスの歴史」で検索すると「30820」件のドキュメントがヒットし、上位にはフランスには関係ない「歴史」のページや「フランス」の文学、都市など「フランスの歴史」とは少し離れた意味のものが上位に来ています。\n\u0026#34;@odata.count\u0026#34;: 30820, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 12.888079, \u0026#34;id\u0026#34;: \u0026#34;17875\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;スコットランドの歴史\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.718105, \u0026#34;id\u0026#34;: \u0026#34;10665\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;世界の歴史\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.701981, \u0026#34;id\u0026#34;: \u0026#34;31397\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ベトナムの歴史\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.579847, \u0026#34;id\u0026#34;: \u0026#34;22433\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランス文学\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.524254, \u0026#34;id\u0026#34;: \u0026#34;34667\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランスの国旗\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.52136, \u0026#34;id\u0026#34;: \u0026#34;108094\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ラン (フランス)\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.41088, \u0026#34;id\u0026#34;: \u0026#34;20717\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;歴史小説\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.388911, \u0026#34;id\u0026#34;: \u0026#34;56229\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;演劇の歴史\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.343941, \u0026#34;id\u0026#34;: \u0026#34;39669\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;イギリスの歴史\u0026#34; }, このクエリをセマンティッククエリで検索すると次のようになりました。\n\u0026#34;@odata.count\u0026#34;: 30820, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 12.274498, \u0026#34;@search.rerankerScore\u0026#34;: 1.482184374704957, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;自由フランス\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;自由フランス\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;96475\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;自由フランス\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 11.446766, \u0026#34;@search.rerankerScore\u0026#34;: 1.3535655084997416, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;フランスの地域圏\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;フランスの地域圏\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;51845\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランスの地域圏\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 10.926437, \u0026#34;@search.rerankerScore\u0026#34;: 1.3261859538033605, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;フランス第一帝政\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;フランス第一帝政\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;57573\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランス第一帝政\u0026#34; }, 上位には「フランスの歴史」に関連しそうなタイトルが上がってきています。 また、先ほど「歴史」という単語でヒットして上位に来ていた「スコットランドの歴史」は@search.rerankerScoreの値が低くなっていました（31件目に出現）。\n{ \u0026#34;@search.score\u0026#34;: 12.888079, \u0026#34;@search.rerankerScore\u0026#34;: 0.42768346797674894, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;スコットランドの歴史\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;17875\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;スコットランドの歴史\u0026#34; }, 考察 日本語のWikipediaを約10万件入れたインデックスでセマンティック検索を試してみました。 デモや説明などでクエリが自然文の質問だったこともあり、質問の回答になりそうなページが上に来るかと期待しましたが、期待しすぎました。\nこれは、Azure Cognitive Searchのセマンティック検索の仕組みを考えると納得のいくものです。 説明を読んだ時にも感じたのですが、入力された文字列でまず検索をし、上位50件をセマンティック検索の対象としています。\nですので、そもそもクエリの文章に出てくる単語が含まれたデータだけが対象となります。 このため、クエリに出てこない単語のみで構成されているものは残念ながら対象とできません。 また、上位50件だけがSemantic Rankerの対象となっているため、検索にヒットしたとしても上位に食い込まなければ言語モデルによるランキングの対象にもなりません。 セマンティック検索といっても、残念ながらドキュメントに出てこない単語（似た単語、質問に対するそのものの回答）まで読み取る機能はありません。\nただ、「フランスの歴史」の検索で見たようにそれぞれの単語だけで検索をしていた場合とは異なり、 クエリの意味に沿ったスコアづけにより、通常の検索よりも意図したものに近いデータが出ていることが確認できました。 複数の単語で構成されるクエリの場合に、単語だけでスコアを計算した場合よりもよさそうな結果が上位に出てくることがわかりました。\nただし、重要なのは「上位50件」までしかSemantic Rankerの対象にはならない点です。\n英語のWikipedia セマンティックは英語対応が一番最初にリリースされているので、英語のWikipediaについてもデータを登録してみました。\n英語のWikipediaのデータを「111,649件」登録しました。 スキーマは以下の通り（今回の調査に利用していないものは省略）です。日本語と異なる点はAnalyzerがen.luceneになっていることぐらいです。\nフィールド名 : タイプ / Analyzer id : Edm.String / keyword categories : Collection(Edm.String) / keyword title : Edm.String / en.lucene contents : Edm.String / en.lucene headings : Edm.String / en.lucene クエリとデータの確認 日本語同様に首都に関する質問形式にしてみました。\nWhat\u0026rsquo;s the capital of Italy? 実際にRomeのページがインデックスに存在していることは以下のクエリで確認済みです。\nRome：2302件\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;Rome\u0026#34;, \u0026#34;top\u0026#34;: 10, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id, contents\u0026#34; } 以下のようなWikipediaの文章をセクションごとに文字列としてページ全体を配列に入れてcontentsに登録してあります（これも日本語と同じです）。\n\u0026#34;\u0026#34;\\n\\nRome (Italian and Latin: Roma ) is the capital city and a special comune of Italy (named Comune di Roma Capitale), as well as the capital of the Lazio region. The city has been a major human settlement for almost three millennia. With 2,860,009 residents in , it is also the country\u0026#39;s most populated comune...\u0026#34;, このデータ群に対して「What\u0026rsquo;s the capital of Italy?」というクエリを、Semantic Searchのクエリと通常のクエリの2パターンで検索をしてみる。\nこれまでのクエリ（セマンティックではない検索） まずは、Semantic Searchではないクエリです。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;What\u0026#39;s the capital of Italy?\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34; } ヒット件数は18049件で、トップ5件は次のような形です。\n\u0026#34;@odata.count\u0026#34;: 18049, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 17.870815, \u0026#34;id\u0026#34;: \u0026#34;14532\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Italy\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 16.596167, \u0026#34;id\u0026#34;: \u0026#34;14702\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Economy of Italy\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 16.180624, \u0026#34;id\u0026#34;: \u0026#34;183878\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Louis II of Italy\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 15.917025, \u0026#34;id\u0026#34;: \u0026#34;29665\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;State capitalism\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 15.88901, \u0026#34;id\u0026#34;: \u0026#34;215741\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Capitalization\u0026#34; }, 日本語の場合よりもItalyに関連するものが上位に多く含まれます。 ただ、Rome自体のページは上位50件には出てきていませんでした。 また、capitalとは意味の異なるcapitalizationやcapitalismが上位に来ています。 日本語の場合と同様にクエリがどのように解釈されているのか？も見てみます。\nPOST https://{{host}}/indexes/{{index-name}}/analyze?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;analyzer\u0026#34;:\u0026#34;en.lucene\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;What\u0026#39;s the capital of Italy?\u0026#34; } 結果は以下の通りです。\n\u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;what\u0026#34;, \u0026#34;startOffset\u0026#34;: 0, \u0026#34;endOffset\u0026#34;: 6, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;capit\u0026#34;, \u0026#34;startOffset\u0026#34;: 11, \u0026#34;endOffset\u0026#34;: 18, \u0026#34;position\u0026#34;: 2 }, { \u0026#34;token\u0026#34;: \u0026#34;itali\u0026#34;, \u0026#34;startOffset\u0026#34;: 22, \u0026#34;endOffset\u0026#34;: 27, \u0026#34;position\u0026#34;: 4 } ] 日本語とあまり変わってはいません。ただ、単語が入力されたものとは少し変わっています。 これは、en.luceneの処理で、stemmingが行われているためだと思われます。たとえば、「capital」の場合、Stemmingにより「capital」「capitalize」などの単語が元になりますが、動詞、名詞などの違いなく検索できるようにするためにこのようなStemmingの処理が行われます。 ということで、これらの単語を含むドキュメントがヒットしています。Italyが一番上に来ているのはItalyという単語が多く含まれるからのようです。\nSemantic Searchクエリ では、Semantic Searchのクエリに変更してみましょう。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;What\u0026#39;s the capital of Italy?\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34;, \u0026#34;queryType\u0026#34;: \u0026#34;semantic\u0026#34;, \u0026#34;queryLanguage\u0026#34;: \u0026#34;en_us\u0026#34; } queryType、queryLanguageがsemantic searchのクエリを実行するためのパラメータになります（公式ガイド参照）。 今回は英語のデータであるため、英語のモデルを利用するようにqueryLanguageを指定します（許可されていない文字列を渡すとエラーになる）。\n結果は次のようになります（上位5件抜粋）。\n\u0026#34;@odata.count\u0026#34;: 18049, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 17.870815, \u0026#34;@search.rerankerScore\u0026#34;: 1.9688458815217018, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Italy\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;14532\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Italy\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 14.239678, \u0026#34;@search.rerankerScore\u0026#34;: 1.9419755563139915, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Capital city\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;181337\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Capital city\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 10.181764, \u0026#34;@search.rerankerScore\u0026#34;: 1.8902588561177254, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Lepontii\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;325133\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Lepontii\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 10.865718, \u0026#34;@search.rerankerScore\u0026#34;: 1.875102698802948, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;ItalY\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;14482\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ItalY\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 11.689348, \u0026#34;@search.rerankerScore\u0026#34;: 1.8201303631067276, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Savoy\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;27885\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Savoy\u0026#34; }, 日本語で見てきたように、検索結果数を見ると、通常のクエリと同じ値で、残念ながら50件までにRomeは入っていないため、Semantic Rankerによるブーストもかかりませんでした。 ただし、「Capitalization」や「State capitalism」といった別の意味（地理に関するものではない単語）のものが上位に出てこなくなっています。 これは、capitalという単語が地理に関する意味を持っていると判断された結果のように見えます。 Capitalizationの@search.rerankerScoreは上位のスコアに比べて小さいものとなっています。\n{ \u0026#34;@search.score\u0026#34;: 15.88901, \u0026#34;@search.rerankerScore\u0026#34;: 0.93921028636395931, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Capitalization\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;215741\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Capitalization\u0026#34; }, What\u0026rsquo;s the capital of Finland? 上位50件以内(20件目)に「Helsinki」のページが出てくるクエリでセマンティック検索をしてみました。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;What\u0026#39;s the captial of Finland?\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34;, \u0026#34;queryType\u0026#34;: \u0026#34;semantic\u0026#34;, \u0026#34;queryLanguage\u0026#34;: \u0026#34;en-us\u0026#34; } 結果としては、2件目にHelsinkiが返ってきていたので、Semantic Rankerがによる並び替えがうまくいきました。 （下記の結果は上位3件を抜粋したものです）。\n\u0026#34;@odata.count\u0026#34;: 16673, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 14.026371, \u0026#34;@search.rerankerScore\u0026#34;: 2.42378556355834, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Vanaja (Finland)\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;7132102\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Vanaja (Finland)\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.434971, \u0026#34;@search.rerankerScore\u0026#34;: 2.383675143122673, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Helsinki\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;13696\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Helsinki\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 13.380153, \u0026#34;@search.rerankerScore\u0026#34;: 2.2026549801230431, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Rauma, Finland\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;178635\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Rauma, Finland\u0026#34; }, 考察 今回の英語のクエリではSemantic Rankerがある程度の役割をはたしていそうだということはわかりました。 Capitalがいくつもの意味を持っていることもあり、文章をもとにより意味の近いドキュメントが上位に来たということです。 ただ、英語の場合も基本的には上位50件以内のデータに対して処理が行われるので上位50件以内にデータが入らなければうまくいかないようです。\nまとめ Azure Cognitive Searchの新機能であるセマンティック検索について調べてみました。 まだPublic Previewですが、簡単に使えるような仕組み（データの再登録なし、クエリでパラメータを追加するだけ）が用意されているのは便利でした。 ただ、最初に想像していたもの（私の早とちりもありますが）ほどのセマンティック検索とは行きませんでした。 似たような言葉の意味を持ったものを探してくれたり、答えそのもののページのスコアがすごく高くなるといったものではありませんでした。\n仕組み上、クエリに含まれる単語で検索し、上位50件以内のデータだけが対象になる(残念ながら現時点ではこの件数の変更はできません。)ため、これまでの検索とは劇的に変化するものではないことはわかりました（銀の弾丸はないんですけどね）。\nある程度の挙動をわかっていれば、Wikipediaのようなデータでもそれなりの結果は取得できそうだということはわかりました。\n「言語モデル」でクエリとヒットしたデータをもとにスコア計算をし直しているようですが、この部分がどのようなデータ・クエリだと有効活用できるのか？というのをもう少しいろいろな角度で試してみる必要がある気がします（適材適所が何なのか？）。 あとは、上位50件までが対象なので、それ以上の件数のデータの並びに関してはこれまでと同様の結果となる点は注意しないといけません。 また、今回試していないほかの機能（スペルチェック、Semantic Answerなど）にメリットがあるのかもしれません。\nざっくりですがセマンティック検索について調べてみました。 こんなデータだとどうなの？ここの考え方が間違ってるのでは？などの指摘がありましたら、コメント欄またはTwitter（@johtani）でコメントを頂けたらと。\n","date":1625130583,"dir":"post/2021/","id":"43caef5d41c4e74826e4a8d82088739d","lang":"ja","lastmod":1625130583,"permalink":"https://blog.johtani.info/blog/2021/07/01/semantic-search-in-azure-cognitive-search/","publishdate":"2021-07-01T18:09:43+09:00","summary":"Azure Cognitive Searchで新機能「Semantic Search（セマンティック検索）」という機能の日本語対応が発表されました。 実際にはPublic P","tags":["azure search"],"title":"Azure Cognitive Searchの新機能、Semantic Searchを試してみた"},{"contents":"Sofle v2を長らく使っていましたが、コンパクトなのもやっぱりいいよなぁというときにKochi KeyboardからLunakey Miniが発売していました。 小指のあたりの傾斜が使いやすいかも？ということで、組み立ててみました。\nもちろん購入はKochi Keyboardさんからです（購入はこちらから）。\nLunakey Miniビルドガイド 作者のYoichiroさんが公開しているビルドガイドが詳細まで書かれています。 こちらをまずは参照してください。\nLunakey Mini ビルドガイド (Rev.4以降) ビルドログ（主にツイート） 私の組み立てについては、Twitterでツイートしていたものがありますので、そちらを貼っておきます。 ちなみに、ツイートしていて躓いているときに、作者のYoichiroさんからたびたびコメントをいただきました。 ありがとうございました！！\n間にいくつかコメントを差し込んでいます。\n結局両方のダイオードつけてしまいました。今日はここまで pic.twitter.com/3qLI6EpfXB\n\u0026mdash; Jun Ohtani (@johtani) April 12, 2021 ハンダはつけた pic.twitter.com/ySE9SA3gZn\n\u0026mdash; Jun Ohtani (@johtani) April 13, 2021 コンスルー問題 左手じゃん、T。Tのダイオード浮いてた。右手も一回全部見直すか\n\u0026mdash; Jun Ohtani (@johtani) April 13, 2021 ここで問題が発覚。右手（ツイートではぼけていて、左手と書いています）についてはダイオードが1か所浮いていただけなので、はんだ付けですぐ直りました。 左手側が大問題です。そもそも右手につけたProMicroへの書き込みができませんでした。 キーボードによっては、ダイオードなどを付ける前からまず、リセットボタンを付けて、ProMicroを指して書き込みをする場合もあります。 ただ、その書き込みができない。 （ちなみにこのタイミングでテスターをつけっぱなしにしていたのが発覚し、9V電池切れのため翌日に持ち越した。。。）\nさて、デバッグのお時間です pic.twitter.com/CaEOv4E5Bg\n\u0026mdash; Jun Ohtani (@johtani) April 14, 2021 ただ、ProMicro刺した状態で、リセットボタン、リセットボタンの足をショートさせても書き込みはできず、ProMicroのGndとResetの足のショートでは書き込みができる。\n\u0026mdash; Jun Ohtani (@johtani) April 14, 2021 テスターで調べてみたところ、リセットボタンとProMicroがうまく通電していません。\nだいぶ進んだけど、Eの列がおかしいなぁ。さて、どこの接触だ？ pic.twitter.com/5tci12Vk05\n\u0026mdash; Jun Ohtani (@johtani) April 14, 2021 どうも、左手の基盤のProMicroの足の穴がコンスルーとの接触が悪いみたいでした。 コンスルーの足を無理やりまげて（3個のコンスルーの足を折りました。。。）、通電できるようにして解決（結局あとでいくつかの足についてははんだ付けしました）。\n終わった。LEDの予備はんだまでやってからおしまいにしよ\n\u0026mdash; Jun Ohtani (@johtani) April 16, 2021 LED実装 鬼門の表面実装ですが、LEDを1個破損するだけで乗り切りました。ちょっと色はおかしかったですが、これはおそらくProMicroの足のせい。\n一個逆につけてしまい、お亡くなりになりましたが、まぁ、良いかな。まずは右手 pic.twitter.com/zldu6fRsXR\n\u0026mdash; Jun Ohtani (@johtani) April 18, 2021 ソケットの実装x2 ロープロファイル（Kailh choc v1）のキースイッチも試してみたいので、MXと両方のソケットをはんだ付けしました。 両方利用できるのは便利ですね。はんだ付けも楽しいし。\nソケットを片手だけ(両方のソケットつけるのでまだ、1/4) pic.twitter.com/7XFRDx0D0I\n\u0026mdash; Jun Ohtani (@johtani) April 18, 2021 キースイッチ設置 親指以外にはKailh Box Silentのピンク軸（Kochi Keyboardから）、親指にはKailh Input Club Hako Violet（AliExpressで購入したもの。リンクは遊舎工房のもの）をつけました。 どちらもそれほどぶれもないものです。Silent ピンクはリニアで静かでそれほど力がいらないスイッチになっています。 親指はタクタイルで小気味のいい音が気に入っています。Sofleもこのキースイッチになってます。\n残りのソケットつけて、キースイッチも設置して、動確してボトムプレートも装着。残りはキーキャップ。 pic.twitter.com/hGc1TtI6fu\n\u0026mdash; Jun Ohtani (@johtani) April 25, 2021 キーキャップ＋キーマップ お試しにXDAのキーキャップをはめてみたのですが、キーの境目がわかりにくく、タイプミスが多かったです。 その後のツイートにあるようにOEMに切り替えています。\nキーマップについては、Lunakey Miniの作者のYoichiroさんが作ったRemapというブラウザベースでキーマップの書き換えができるツールで楽々変更ができました。JISキーまで対応しているのでJISベースでキーマップを作成している私にはうってつけでした。 Remapの利用方法についてはサリチル酸さんのブログが詳しく書いてあります（本当に頭が下がります）。\nRemap使ってキーマップいじったら、すごく楽だった。\n\u0026mdash; Jun Ohtani (@johtani) April 26, 2021 BLE + LPME-IO化 ここまでで、USB接続で動作はしていたのですが、Sofle同様に3台をBluetoothで切り替えながら使いたかったので、 Corne Light v2につけていたBLE+LPME-IO(Corneの実装などは前のブログを参照)を抜き取って、Lunakey Miniに移植してみました。\nBLE ProMicro化は作者の方のブログで行われていたので、LPME-IO対応も何とかなるだろうと。\nBLE+LPMEに変えた。後でブログ書こう pic.twitter.com/mGePN52v6k\n\u0026mdash; Jun Ohtani (@johtani) April 29, 2021 LPME-IOへの対応はCorneとSofleの時に行なったこともあり、なんとなくあたりがついていました。 流れとしては、以下の通りです。\nBLE Micro Pro用の設定ファイルを作成 BLE Micro Proのサイトの「キーボードの設定ファイルを編集する」のコマンドでコンフィグファイルを生成 LPME-IOのジャンパをはんだでブリッジ 1.で生成したコンフィグから、Corne Lightと同じ個所のジャンプをすれば良いとわかったので今回はスキップ TRRSのI2C対応 Corne LightのLPME-IO対応の時と同様にSDAとSCLをTRRSの足にショートカット ただ、今回右手側は、下記ツイートのようにOLEDの足からTRRSの足にショートカットしました。Corneの基盤を見ていた時にこれでも行けそうだな？と思っていたので、試してみた次第です。ちなみに、左手はCorneの時と同じPro Microから長い銅線を引っ張っています（電池基盤があったので、外すのがめんどくさかったため）。 BLE Micro Proにファームウェア書き込み BLE Micro Proのサイトの手順に従います。 設定ファイルには1.で出力されているLPME用のファイルを使用。 といった感じです。キーマップが設定されていないので、Remapで設定しなおしました。 Remapは、キーマップをPDFで出力する機能までついていて、すごくいいですね。サイコー\nあと、足。 pic.twitter.com/W0Wpf5k5SE\n\u0026mdash; Jun Ohtani (@johtani) April 29, 2021 傾斜がつくように奥側に高さを出すためのゴム足を貼り付けました。 あとは、3台のPCにBluetoothで接続すれば終了です。 （AD_WO_Lのキーを利用して追加していくのを毎回忘れる。。。）\n疑問点 ちょっとだけ疑問点がありますが、時間があればそのうち調べるかな。\nRemapはクラウドに設定ファイルをセーブできるけど、json形式で手元にダウンロードしたりはできないのかなぁ？ LEDは有線じゃないと点かないみたいだけど、音はどうなんだろう？ 音が出せそうなら、Bluetoothの接続切り替えするときに音の出方を変えるとかをやってみたいなぁ。 まとめ ということで、Lunakey Miniを組み立てて、BLE+LPME-IO対応してみました。 はんだ付けはだいぶ慣れてきましたし、今回もトラブルがあったおかげでテスターを利用して、どのあたりがおかしいかという調査をするのも慣れてきました。 あとは、キーの配置の違いを体感して、どれが自分に合ってるかなぁ？というのを試したり仕様と思います。 ロープロファイルも試してみようかな。\nあ。もちろん、このブログは組み立ててBluetoothで接続したLunakey Mini Rev5、Kailh Box Silentピンク軸＋Input Club Hako Violetで書きました！！久々に数字列がないので記号入力とかがちょっとバタバタしましたｗ\n","date":1619709972,"dir":"post/2021/","id":"f4baa43cc7ca712d83b99a794c4e2dbd","lang":"ja","lastmod":1619709972,"permalink":"https://blog.johtani.info/blog/2021/04/30/build-lunakey-mini-ble/","publishdate":"2021-04-30T00:26:12+09:00","summary":"Sofle v2を長らく使っていましたが、コンパクトなのもやっぱりいいよなぁというときにKochi KeyboardからLunakey Miniが発売して","tags":["DIYキーボード","misc"],"title":"Lunakey Miniを組み立てて、BLE+LPME-IO化してみた #DIYキーボード"},{"contents":"みなさんは、スライドの作成には何を使っていますか？ Keynote？Powerpoint？Google Slides？\n私は、Macでスライドを作るときは前職ではテンプレートもあったのでKeynoteでしたが、ちょっとしたものはMarkdownベースのDecksetを利用していました（買い切りタイプの有料ソフト）。\nフリーランスになってもこちらを利用していたのですが、Windows環境に切り替えたので使えなくなってしまいました。 一度はGoogle Slidesで作ったのですが（第39回Es勉強会スライド）、既存の資産を流用したくなりどうしたものかと悩んでい(ツイートし)たら。\nMacの頃はDecksetってアプリでMarkdownで書いてたんだけど、Winに移動したのでこのタイミングでGoogle Slidesにでもしようかなと考えてるところ。Markdownでスライド作るのほかになんかあるか探すほうがいいかなぁ？\n\u0026mdash; Jun Ohtani (@johtani) March 18, 2021 僕はこれ使ってますhttps://t.co/sFaAmKZY6V\n\u0026mdash; miyake | ZEN (@kazuyukimiyake) March 18, 2021 ということで、利用してみようかなとなりました。\nMarpとは？ Markdownでプレゼンテーションのスライドを作ることができるOSS?になります。\nMarp公式サイト といっても、これ自体を使わなくても、VS Code上でプレビューしたりHTML形式で動作するスライドを吐き出すことが可能です。 なので、VS Code用のプラグインを利用しています。\nサンプル この間利用したスライドはこんな感じのMarkdownになってます。 ---でページを区切りつつ、記述していく形です。\n--- marp: true theme: poster --- \u0026lt;!-- _class: big-center --\u0026gt; # 本当にその検索は\u0026lt;br/\u0026gt;自分が想像している検索に\u0026lt;br/\u0026gt;なってますか？ \u0026lt;br/\u0026gt; \u0026lt;br/\u0026gt; \u0026gt; 2021/03 \u0026gt; Jun Ohtani / @johtani --- ![bg right:40% 40%](johtani_face.jpg) # 自己紹介 - フリーランスエンジニア - 検索技術勉強会主催者 - Apache Solr入門(第2版まで)や データ分析基盤構築入門の著者の一人 --- プレビューで見るとこんな感じです。\nプラグイン Marp for VS Code プラグインをインストールするのも簡単ですよね。 マーケットプレイスからインストールすれば完了です。\n機能については上記のページにあるように、プレビューとスライドの出力です。 プレビューでは、Markdownのプレビューみたいな形で、スライドが表示できます。\n先日この機能を利用して作成して、HTMLで出力して利用しました。 PDFとかPPTX出も出せるようなので、今後試してみようかなと。\nDecksetのスライドとの違い ページの区切りなども同じだったので、大筋ではそれほど違いはありませんでした。 ただ、画像周りとスタイルの設定は細かく修正をしました。\n変更した点としては、以下のようなものがあります。\nヘッダ部分の変更 上のサンプルにありますが、marp: trueを含む部分がMarp独自の記述です。 ページごとのちょっとした変更 ページごとにスタイルの変更ができるみたいで（Decksetではできなかったはず？）、タイトルページのスタイルを変えてあります。 画像の指定 画像の読み込み自体は違いはないのですが、画像の配置についての指定方法は カスタムテーマ用CSSの作成 デフォルトではなく、Decksetで用意されているような感じのスタイルに変更してみてます。 カスタムテーマはCSSで設定できるので、CSSファイルを用意して、VS Codeの拡張機能の設定からファイルパスを指定する形です。\nということで、当面はMarpでスライドを作っていくことになるかと思います。 まぁ、ただ、スライドを作るいこと自体が減ってきてはいるのですが。 ほかの配色を試したり、ヘッダフッタとかも試してみるのもいいかもな。\n気が向いたら、CSSをどこかにアップロードするかもです。\n※今回のブログはGateronサイレントクリア軸をルブしてみた、Corne Light v2で最後の数行を書いてみました。 キースイッチだけだとこすれる音が減った気がしてましたが、キーキャップを付けたら少しこすれる音が気になる感じです。\n","date":1617615911,"dir":"post/2021/","id":"f41d4fde94cbd7bbd28808dc080a2019","lang":"ja","lastmod":1617615911,"permalink":"https://blog.johtani.info/blog/2021/04/05/intro-marp/","publishdate":"2021-04-05T18:45:11+09:00","summary":"みなさんは、スライドの作成には何を使っていますか？ Keynote？Powerpoint？Google Slides？ 私は、Macでスライドを作","tags":["勉強会"],"title":"スライド作成の環境をMarpにしてみた"},{"contents":"新型コロナウィルスの影響もあり、オフラインで集まって勉強会も開催できなくなっています。 検索技術勉強会も、もう1年以上開催できていないです。\nスピーカーの人にオンラインでしゃべってもらうのもありだとは思うのですが、 懇親会とセットでその価値があったかもなぁと思うところもあり、オンラインでの開催に乗り気になれないまま時間がたってしまいました。 (配信周りを調べるのがめんどくさいなぁというのもあったかも（反省）)\nそんな中、takuya-aさんと話をしていて、エンジニア同士のゆるいつながりができる場所が欲しいですねぇということに。\nはー、検索技術勉強会、オフラインでできないまま１年以上たってしまったのか。オンライン勉強会とかはスピーカーの人の負担とかもあるし、Discordみたいなオープンな場だけ用意してみるのありかなぁ？ただ、活発に話がされるのかどうかわからんし、ROMな人ばかりだとアレなんだけどなぁ。\n\u0026mdash; Jun Ohtani (@johtani) March 30, 2021 そこからの、このツイートです。 ちらほらと興味のありそうな人が出てきたねという話をしていたら、Slackのワークスペースが出来上がってましたｗ\n検索技術に関する情報交換を目的とした Slack を立ち上げました！こちらの招待リンクからご参加ください。 https://t.co/Tca70vuMff\n\u0026mdash; takuya-a (@takuya_b) March 31, 2021 ありがとう、takuya-aさん！\nということで、検索周りでわいわいできる場になればいいなぁと。 盛り上がってくれば、オンラインでの勉強会とかもありかもしれないですね！ 興味のある方は、上記ツイート内のリンクからご参加下さい！！\n","date":1617200894,"dir":"post/2021/","id":"ce426b7f3190c8a4a47d45ac799e91a4","lang":"ja","lastmod":1617200894,"permalink":"https://blog.johtani.info/blog/2021/03/31/search-tech-jp-slack/","publishdate":"2021-03-31T23:28:14+09:00","summary":"新型コロナウィルスの影響もあり、オフラインで集まって勉強会も開催できなくなっています。 検索技術勉強会も、もう1年以上開催できていないです。 ス","tags":["勉強会"],"title":"検索技術に関する情報交換を目的としたSlackができました！"},{"contents":"Azure Cognitive SearchにはOData式という書式で条件が書ける仕組みがあります。 ODataは検索条件（$filter）やソート条件（$orderby）、取得する項目名の指定（$select）です。\n私は、Luceneの構文に慣れているので、普通のsearchパラメータを利用しようとします。 が、OData式として特殊な書き方がいくつかあるようなのでこちらの利用方法も調べてみました。 その時、N-Gram（よくやるのはN=2）で陥る問題の話もあるのでこちらについても言及します。\nOData式で検索 次のような3件のドキュメント(フィールド名はbodyとします)をN-Gramで登録していたとします。\nミルクティを飲みたいです。 マティーニはカクテルですが、ミルクセーキは？ 風呂上がりのミルクは最高です。 この時、OData式でミルクティという単語で検索してみましょう。\n検索条件は$filterで指定します。 フルテキスト検索用に関数が用意されており、こちらに単語を指定します。\n$filter=search.ismatchscoring(\u0026#39;ミルクティ\u0026#39;) こんな感じ。フィールドの指定がない場合、対象のフィールドは検索可能なフィールドすべてが検索対象になります（公式ガイドのクエリパラメータのqueryTypeに説明あり）。\nでは、実行してみましょう。で返ってくるのは？1だけかな？と思う人が多いかもしれません。 が、結果は3件とも帰ってきます。\n問題点は？ では問題点はどこでしょう？ ismatchscoringのオプションなどを見る前に、転置インデックスを用いた検索エンジンの挙動をおさらいしましょう。 転置インデックスの仕組みを理解することで、なぜそんな挙動になるのか？というのがわかりやすくなります。 おさらいにはElasticsearchをベースに話をしますが、Azure Cognitive Searchでも同じような挙動になります。\n転置インデックスとトークナイザー（アナライザー）の関係（おさらい） 昨年、オンラインで開催されたOSC広島で発表した資料（録画あり）でもざっくりと説明しています。\nView 本当にその検索は自分が想像している検索になってますか？ on Notist.\nざっくりですが、おさらいです。\n検索エンジンでは、入力された文章を、ある規則（アナライザー）で単語に分割し、その単語ごとにどのドキュメントに出現したのか？というリストが作られます。 このリストが転置インデックスです。書籍の後ろにある索引を想像するとどんなものかがわかりやすいです。 単語に対してその単語が出てくるページ番号がわかるという仕組みです（下図は本の索引の一例）。\n書籍の索引は著者や編集の方により厳選された単語のみが採用されています。 が、検索エンジンでは文章を単語に区切る機能が存在します。 この「ある規則」で単語を区切る仕組みが「アナライザー（トークナイザー）」と呼ばれる機能です。 例えば英語用のアナライザーに英語の文章が入力されたとき、文章はこのように単語に区切られたもの（単語列）を出力します（下図）。\n今回はNGramの話なので、NGramのAnalyzerを利用してみるとこんな感じになります。\n実際に出来上がる転置インデックスは次のような形になります。 検索の仕組み（おさらい） 出来上がっている転置インデックスに対して検索をする場合、入力文字列（検索条件）に対して、転置インデックス作成時と同様にAnalyzerが動作します。 処理としては、\nクエリのパース フィールドのAnalyzerで処理 転置インデックスを検索 という形です。 例えばこんな感じ。\n同じAnalyzerの処理が入ることで、転置インデックスに採用されているのと同じ単語が出てくるため、検索がきちんとできるということになります。\n英語と日本語（NGram）の違い 英語と日本語の違いは、スペースの意味になります。 英語の場合は、スペースが単語の区切りになりますが、日本語の場合スペースでは区切られていません。\nですので、検索窓に入力された文字列は、英語の場合、クエリのパースの時点で単語に区切られます。そのあとにAnalyzerになるので、基本的には単語単位でAnalyzerの処理が動きます。そのあと、転置インデックスへの検索となります。なので、多くの場合はAnalyzerの出力は1単語です（類義語などを利用していたりする場合は異なりますが）。\n日本語の場合、スペースでは区切られていないので、クエリのパースの時点で入力された文字列がそのままAnalyzerにわたります。 今回はAnalyzer（NGram）が単語に分割し、それをもとに検索処理が実行されます。\nismatchscoringの問題点は？（やっと帰ってきました） さて、回り道をし、簡単ですが転置インデックスやAnalyzerについて説明しました。 では本題です。\n$filter=search.ismatchscoring(\u0026#39;ミルクティ\u0026#39;) このismatchscoring関数ですが、そのほかにも引数の指定が可能で、省略した場合にデフォルトで採用される値がいくつかあります。 公式のドキュメントにパラメータの意味が掲載されています。\n今回は、第4引数のsearchModeの値が問題点です。デフォルトでは、anyが指定されます。 この、anyは検索語（今回はミルクティ）の任意の検索語句が一致する必要があることになります。 「検索語句」？なんでしょう？これが、ここまで回り道をして説明してきた、Analyzerの出力した単語になります。 「ミルクティ」はNGram（N=2）のAnalyzerを通すと、\n「ミル」「ルク」「クテ」「ティ」\nという4つの単語が出力されます。 これが、「検索語句」です。「任意の」とあるので、上記4つの2文字のどれか？が出現すれば検索条件にヒットしたこととなります。\nですので、以下のように（一部のみ色を変えてます）3つの文章にはそれぞれの文字が含まれているため、先ほどの条件では3件の結果が返ってくることになります。\nミルクティを飲みたいです。 マティーニはカクテルですが、ミルクセーキは？ 風呂上がりのミルクは最高です。 NGramで一部分の単語だけで一致したものがヒットしてしまうと違和感があるので、allに変更します。\n$filter=search.ismatchscoring(\u0026#39;ミルクティ\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;all\u0026#39;) 今度はどうなるでしょう？\nミルクティを飲みたいです。 マティーニはカクテルですが、ミルクセーキは？ 先ほどよりもマシになりました。 3がヒットしなくなっています。3の文章には「ティ」などが出てこないためです。 ただ、感覚的に2番目がヒットするのは少し違和感がありますよね？ 確かに4つの単語がすべて出てきていますが、「ミルクティ」とは少し遠いです。\nさらに「ミルクティ」にヒットさせるにはフレーズ検索にする必要があります。 Elastic社のブログの日本語の検索に関する記事でも出てきますが、フレーズで検索することで「ミルクティ」だけにヒットさせることができます。\n「フレーズ検索＝語順を保証する検索」となります。 ですので、\n「ミル」「ルク」「クテ」「ティ」\nこの順序で出てきた場合のみ、検索にヒットしたことになります。 OData式でフレーズ検索する場合は、単語をダブルクォート\u0026quot;でくくる必要があります（公式ドキュメントの例に記載あり）。\n$filter=search.ismatchscoring(\u0026#39;\u0026#34;ミルクティ\u0026#34;\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;all\u0026#39;) これで結果は以下の1件だけとなります。\nミルクティを飲みたいです。 これでNGramで部分一致のような挙動で日本語の検索ができるようになりました。\nちなみに、フレーズにした場合は第4引数はanyに変更しても1件だけの検索結果となります。 フレーズ検索には「すべての語が含まれる」、「すべての語が順番に現れる」という2つの条件が含まれるためです。\n$filter=search.ismatchscoring(\u0026#39;\u0026#34;ミルクティ\u0026#34;\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;any\u0026#39;) この例の引数をミルクティを\u0026quot;ミルク\u0026quot; \u0026quot;最高\u0026quot;のような検索条件に変えた場合、「\u0026ldquo;ミルク\u0026rdquo;」「\u0026ldquo;最高\u0026rdquo;」の2つの条件をanyで扱うため、 「\u0026ldquo;ミルク\u0026rdquo;」「\u0026ldquo;最高\u0026rdquo;」のどちらかが出てくれば良い結果となり、3件の結果が返ってきます。 第4引数をallに変更すると、「\u0026ldquo;ミルク\u0026rdquo;」「\u0026ldquo;最高\u0026rdquo;」の両方が出てこなければならないため、3件目のデータのみが返ってきます。\n$filter=search.ismatchscoring(\u0026#39;\u0026#34;ミルクティ\u0026#34; \u0026#34;最高\u0026#34;\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;all\u0026#39;) これは、\n$filter=search.ismatchscoring(\u0026#39;\u0026#34;ミルクティ\u0026#34;\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;any\u0026#39;) and search.ismatchscoring(\u0026#39;\u0026#34;最高\u0026#34;\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;any\u0026#39;) と同じ意味となります。 少し長くはなりますが、後者の書き方をプログラムで書くと思います、私の場合は。 検索窓に入力された単語に必ず\u0026quot;を追加する処理を書くために、画面入力の文字列を一旦パースをすることになるからです。\nまとめ 簡単？にですが、OData式でのフルテキスト検索と、NGramでのフレーズ検索について説明しました。 英語の場合、もともとスペースで区切られているので、フレーズといわれてピンときますが、日本語の場合はAnalyzerの挙動をわかっていないと「？」となるかと思います。 なぜフレーズ検索が必要なのか？というのが少しでもわかっていただければと。 ちなみに、NGramのTokenizerには別の落とし穴もありますが、その話はまた後日にでも。\n参考として日本語関連の検索に関する記事のリンクを残しておきます。\n参考 Elasticsearch日本語でフレーズ検索が必要なわけ NGramも含め、Elasticsearchでの日本語の検索の設定やクエリについては、Elastic社のブログで日本語で書かれた記事が詳しいのでこちらをご覧いただくのがいいです。 ","date":1614756213,"dir":"post/2021/","id":"eced95e5f301a8340e83d81d3c0d5c0d","lang":"ja","lastmod":1614756213,"permalink":"https://blog.johtani.info/blog/2021/03/03/phrase-query-in-japanese/","publishdate":"2021-03-03T16:23:33+09:00","summary":"Azure Cognitive SearchにはOData式という書式で条件が書ける仕組みがあります。 ODataは検索条件（$filter）やソート条件（$orderb","tags":["azure search","elasticsearch"],"title":"OData式と日本語の検索(NGram)とフレーズ検索"},{"contents":"自宅の環境がいろいろと変わったのですが、書いていなかったので更新版です。 前回のブログ(2020/09)、前々回のブログ(2020/03)はそれぞれリンクをたどってください。\n現状のデスクトップはこんな感じ\nPC 別のブログにまとめましたが、Windowsメインに切り替えました。 ハードの話以外に、Windows OSに切り替えたときにいくつか入れたものもあります。 それは、移行のブログに少しだけ書いてあります。\nひさびさにWindowsに戻ってきていますが、だいぶ慣れました。 まぁ、それほど大したことをやってないというのもあるかもですが。。。\nメインPC以外にこれまでのmacをブラウジング用にサブディスプレイにつなぎ、マウスをLogicool Flowで行き来できるようにし、 キーボードはKVMスイッチで切り替えてやりくりしていました（最新環境はキーボードのところを参照してください）。\nAmazon | サンワダイレクト USB切替器 キーボード・マウス用 KVMスイッチ キーボード いくつかDIYしましたが、今はメインでSofle Keyboard v2を利用しています（Kochi Keyboardさんで購入できます）\nSofle keyboard v2を有線で使っていましたが、最近Bluetooth対応して無線化しました（その時のブログはこちら）。 ですので、PCとの接続の切り替えはキーボード上で特定のキーの組み合わせを押すことで、切り替えられるようになっています。 KVMとは異なり、Bluetoothの接続が切り替わるのにタイムラグがある＋どこにつながっているのか？というのがわからないので、想定していないところでキーが入力されていることがあります。 これは、何とかしたいかもなぁと考えてはいるところ。\nマイク＆オーディオインターフェース 基本的に自宅でリモート作業をしています（ありがとうございます）。 なので、ミーティングもオンラインです。 となるとやはり、音がいいほうがお客さんにも喜ばれるかなぁと。 2020年3月時点ではSAMSONのGoMicを利用していました。 これもいい音なのですが、大きいマイクでもいいかなと。 あとは、ほかの使い道もあるかも？ということで、オーディオテクニカのマイク（＋ポップガード）とフォーカスライトのオーディオインターフェースに変えてみました。 自分は実感ないですが、きっと役に立っていると思いますｗ\nAmazon | audio-technica サイドアドレス コンデンサーマイクロホン AT2050 | コンデンサ | 楽器 Amazon | AUDIO-TECHNICA AT-PF2 ポップフィルター | マイクアクセサリ | 楽器 Amazon | Focusrite フォーカスライト オーディオインターフェイス 2イン/2アウト 24bit/192kHz Scarlett Solo (3rd Gen) ステッカー付きセット 【国内正規品】 | 楽器・音響機器 | 楽器 ディスプレイ 以前は、MacBookProの16インチで、メインディスプレイの下に2枚目のディスプレイも兼ねて開いて利用していました（前回のブログ参照）。 自作PCに切り替えたので、ディスプレイがなくなってしまうので、同じような大きさのモバイルモニターを利用しています。 今のところは据え置きになっていますが、持ち運べるので、ほかの部屋や外出時にも使えるんではないかなと。 ディスプレイの足などはないので、邪魔にもならず便利ですね。\nAmazon | モバイルモニター モバイルディスプレイ 4K 15.6インチ cocoparスイッチ用モニター 非光沢IPSパネル 薄い 軽量HDRモード/FreeSync対応/ブルーライト機能 3840x2160 UHD/USB Type-C/標準HDMI/mini DP/カバー付3年保証付 | cocopar | ディスプレイ 通販 音楽再生環境 サブディスプレイにサンダーボルトディスプレイを使用していたので、Mac Miniを接続していましたがサンダーボルトディスプレイには退役してもらいました。 それに伴って、Mac Miniも別の場所に移動しました。音楽再生環境にラズパイ４を復活させました。 以前購入したセットについていたケースではファンの音が気になっていたので、ヒートシンク型に変えました。 結構重いですが、冷えてそうです。\nAmazon | Geekworm Raspberry Pi(ラズベリーパイ) 4 B 用アーマー金属ケース パッシブ冷却/シェル熱放散 ラズベリーパイ4 コンピュ ータモデルB適用 (アーマーケース（ファン無し）) | Geekworm | 冷却パーツ・ファン 通販 Webカメラ カメラ自体に変更はないですが、付属品をいくつか。 Webカメラではないカメラもつけてみたいなと思い、モニターアームにカメラを付けられるものを付けてみました。 ただ、おっさんの顔をきれいに映してもなぁという結論に至ったので、Webカメラが乗っかっています。。。 あとは、デスクトップPCになり、カメラのケーブルだけではPCまで届かなくなってしまったのでUSB Type-Cの延長コードを買ってみました。実はこれ2本目ですが。。。 スタンディングデスクの昇降でケーブルに負荷がかかってしまったことがなんどかあり、1本目の延長コードは接触が悪くなってしまいました。。。時々外したりしていて、ケーブルの配置がおかしいときがあるので、気を付けるようにしています。\nAmazon | 長尾製作所 モニターアーム用 VESA カメラ＆マイクマウント NB-MV001MH | 長尾製作所 | モニタアーム\u0026amp;スタンド 通販 Amazon | iVANKY USB Type C 延長ケーブル USB 3.1 Gen 2(4K@60Hz/1.0m/オス－メス)10Gbps高速データ転送 3A急速充電 usb-c 変換 Huawei MateBook13, iPad Pro11, Nintendo Switch, MacBook等対応 | IVANKY | USBケーブル 通販 照明 裸の蛍光管だったのですが、リモコンで点灯したり、照度を変えられるようにしたかったので、 パナソニックの照明に変えました。\nAmazon | パナソニック LEDシーリングライト 調光・調色タイプ リモコン付 6畳 3, 699lm HH-CD0620AZ 【Amazon.co.jp限定】 | パナソニック(Panasonic) | ホーム＆キッチン 変えたのはよかったのですが、部屋が長細い＋Webカメラの位置（自分から見て左にカメラを置いて、部屋の奥への画角？になっている）のせいで、右半分の顔が暗くなる場合がありました。 幸い、右にはスチールラックが組んであるので、そこにつけられる照明を購入して女優ライトみたいな感じで使っています（頻繁ではないですが）\nAmazon｜ルミナス メタルラック用 LEDライト 磁石で簡単設置 連結可能 幅60cm 昼白色 LED60R-N｜メタルラックパーツ オンライン通販 フットレスト 昨年3月くらいに配置して、座っているときに足を置くのに便利に使っていました。 が、1台だと幅が足りないので最近2つ目を購入して並べて使っています。 片足ずつ載せられるのは便利ですね（基本ガニ股なので。。。）。\nAmazon | サンワダイレクト フットレスト スチール製 角度10° 幅40×奥行30cm 足置き台 100-FR011 | フットレスト | 文房具・オフィス用品 ということで、最近はこんな環境で仕事をしています。 当分これで更新しないんじゃないかなぁ。 （サブディスプレイが左に寄っているので、局面ディスプレイが気になっているところですが。。。）\n","date":1614246182,"dir":"post/2021/","id":"fcb0105fa6b5777a133f247784b9d930","lang":"ja","lastmod":1614246182,"permalink":"https://blog.johtani.info/blog/2021/02/25/update-working-facility/","publishdate":"2021-02-25T18:43:02+09:00","summary":"自宅の環境がいろいろと変わったのですが、書いていなかったので更新版です。 前回のブログ(2020/09)、前々回のブログ(2020/03)はそ","tags":["misc"],"title":"自宅の作業環境(2021/02)"},{"contents":"Azure Cognitive SearchにSuggestやAutocompleteの機能があるのを見つけたので、どんな挙動なのかを調べてログとして残しておきます。\n公式ドキュメント 日本語で公式ドキュメントが公開されています。使い方や流れについてはこちらをまずは見れば使えると思います。\n本ブログでは、ざっくりとした機能の紹介と内部がどんな挙動をしていそうか？、日本語だとどういう感じになるのか？という点を紹介しようと思います。\nどんな機能？ 検索窓でよく、キーワードを入力しているときに検索キーワードの候補が表示されることがあります。 このキーワードの候補を表示するための機能が今回紹介するSuggesterと呼ばれる機能です（日本語の公式ドキュメントでは「先行入力エクスペリエンス」）。 Suggesterには、以下の2つの機能が用意されています。\nAutocomplete：キー入力しているときに、入力されている文字列で始まる単語で、検索できるもの（転置インデックスに登録されている単語）をリストで返す機能 Suggestion：入力した文字列で始まるキーワードを含む、元のデータを返す機能 利用方法 Suggesterの機能を利用するにはインデックスに設定を追加する必要があります（新規、既存どちらでも可）。 ただ、既存のインデックスに設定を追加した場合、内部にすでに存在するドキュメント（データ）については、このSuggesterのデータは作られません。 ですので、既存データを再度登録しなおすといった作業が必要となるので注意が必要です。\n本ブログでは、いくつかAzure Cognitive Searchのサンプルのリクエストが出てきます。Visual Studio CodeのREST Client Extensionの書式となります。拡張機能の簡単な紹介は昨年のブログをご覧ください。\n設定編 Suggesterの設定では、主に以下の2つを設定する必要があります。\nname: suggesterの名称。クエリ時に指定します。 sourceFields: 入力データのもととなるフィールド名。 String型のみ指定可能。また、Azureで用意されたアナライザーだけが利用可能です。自分で用意するカスタムアナライザーは利用できないので注意が必要です（制限についてはこちら）。 今回使用するサンプルのインデックス設定は次の通りです。\nインデックス作成のリクエスト（@host、@api-keyはご自身のものに置き換えてください。）\n## 設定 @host = 名前.search.windows.netと記載 @api-key = APIキーを入力 ### Create index with suggester POST https://{{host}}/indexes/?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;name\u0026#34;:\u0026#34;suggester-test\u0026#34;, \u0026#34;fields\u0026#34;:[ { \u0026#34;name\u0026#34;:\u0026#34;id\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;Edm.String\u0026#34;, \u0026#34;key\u0026#34;:true, \u0026#34;searchable\u0026#34;:false }, { \u0026#34;name\u0026#34;:\u0026#34;name\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;Edm.String\u0026#34;, \u0026#34;searchable\u0026#34;:true, \u0026#34;analyzer\u0026#34;:\u0026#34;ngram_analyzer\u0026#34; }, { \u0026#34;name\u0026#34;:\u0026#34;category\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;Edm.String\u0026#34;, \u0026#34;filterable\u0026#34;:true, \u0026#34;facetable\u0026#34;: true } ], \u0026#34;suggesters\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;name_suggester\u0026#34;, \u0026#34;searchMode\u0026#34;: \u0026#34;analyzingInfixMatching\u0026#34;, \u0026#34;sourceFields\u0026#34;: [ \u0026#34;name\u0026#34; ] } ] } 公式ドキュメントのサンプルでは日本語がないので、日本語のデータも入力しています。\nデータ登録リクエスト\n### Index data POST https://{{host}}/indexes/suggester-test/docs/index?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;value\u0026#34;: [ { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Microsoft Office\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;microsoft\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Microsoft Azure\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;microsoft\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;3\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;GitHub Enterprise\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;github\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;4\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;GitHub dot com\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;github\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;5\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Bluetooth Mic\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;hardware\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;6\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;東京スカイツリー\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;japanese\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;7\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;東京タワー\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;japanese\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;8\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;東京特許許可局\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;japanese\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;9\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;グランメゾン東京\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;japanese\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;10\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;東京都庁\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;japanese\u0026#34; } ] } 以上が事前準備です。データ登録時に内部でSuggester用のデータを内部で生成しているようです（公式ドキュメント）。\nクエリ編 最初に説明しましたが、Suggesterの中ではAutocompleteとSuggestionという2種類の機能が用意されています。それぞれについて例をもとに説明していきます。\nAutocomplete API 検索窓に入力された文字を元に、前方一致でどのような単語で検索できるか？という候補を表示するための機能です（2単語も対応していますが今回は省略。APIの仕様はこちら）。\nたとえば、micという文字が入力されているところでAutocomplete APIを呼び出す時は、次のようなリクエストです。searchというパラメータに入力値を与えます。suggesterNameはインデックス作成時につけた名前になります。\nPOST https://{{host}}/indexes/suggester-test/docs/autocomplete?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;mic\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } レスポンスとして、次のようなJSONが返ってきます。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;microsoft\u0026#34;, \u0026#34;queryPlusText\u0026#34;: \u0026#34;microsoft\u0026#34; }, { \u0026#34;text\u0026#34;: \u0026#34;mic\u0026#34;, \u0026#34;queryPlusText\u0026#34;: \u0026#34;mic\u0026#34; } ] } サンプルデータとして登録したデータにcategoryというフィールドを入れていました。 Autocompleteは条件を絞り込んで結果を返すこともできます。 filterにODataの書式で条件を書けます。 categoryフィールドにmicrosoftが設定されているデータだけを取得するということができます。\n### Autocomplete with filter POST https://{{host}}/indexes/suggester-test/docs/autocomplete?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;mic\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34;, \u0026#34;filter\u0026#34;: \u0026#34;category eq \u0026#39;microsoft\u0026#39;\u0026#34; } レスポンスはこちら。先ほどとは違い、micというデータは返ってきていません。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;microsoft\u0026#34;, \u0026#34;queryPlusText\u0026#34;: \u0026#34;microsoft\u0026#34; } ] } 英語の場合、「単語」の単位は字面の通りです。スペースで単語が区切られているのでわかりやすいです。 日本語の場合は普通の人には少し想像しにくいです。 東京という文字を入力してみます。\n### Autocomplete in Japanese POST https://{{host}}/indexes/suggester-test/docs/autocomplete?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;東京\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } すると返ってくるのは以下の通り「東京」だけになります。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;東京\u0026#34;, \u0026#34;queryPlusText\u0026#34;: \u0026#34;東京\u0026#34; } ] } 入っているデータは「東京スカイツリー」、「東京タワー」などです。 普通に考えると、これらがそのまま返ってくると思うかもしれませんが、違います。\nこれは、Suggesterの元となるフィールドのAnalyzerの挙動によります。 今回のインデックスのnameフィールドのanalyzerにはja.luceneです。これは、日本語用のアナライザー（Kuromoji）になります。いわゆる形態素解析器で日本語の文字列を「単語」に分割します。 英語についてはスペース区切りで分割しますが、日本語についてはKuromojiが内部の辞書とアルゴリズムに基づいて単語に分割してくれます。 Azure Cognitive Searchでは、Analyzerの挙動を確認するためのAPIも用意してあるので実行しみると、\n### Autocomplete in Japanese POST https://{{host}}/indexes/suggester-test/analyze?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;text\u0026#34;: \u0026#34;東京スカイツリー\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;ja.lucene\u0026#34; } このような結果が返ってきます。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;東京\u0026#34;, \u0026#34;startOffset\u0026#34;: 0, \u0026#34;endOffset\u0026#34;: 2, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;スカイ\u0026#34;, \u0026#34;startOffset\u0026#34;: 2, \u0026#34;endOffset\u0026#34;: 5, \u0026#34;position\u0026#34;: 1 }, { \u0026#34;token\u0026#34;: \u0026#34;ツリー\u0026#34;, \u0026#34;startOffset\u0026#34;: 5, \u0026#34;endOffset\u0026#34;: 8, \u0026#34;position\u0026#34;: 2 } ] } ja.luceneのAnalyzerによって、3つの単語に分割されているのがわかります。 Autocomplete APIの実行結果も、このAnalyzerによって分割された単語をもとに、候補となる単語を前方一致で検索して結果を返しているのです。 ですので、「東」と入れても「東京」が返ってくるのがわかります。 一方で、「東京ス」と入力した場合は次のような結果となります。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;スカイ\u0026#34;, \u0026#34;queryPlusText\u0026#34;: \u0026#34;東京スカイ\u0026#34; } ] } これは、autocompleteModeと呼ばれるパラメータの挙動となります。 デフォルトでは、oneTermという設定で、最後の単語（例の「東京ス」の場合は「東京」「ス」と区切られるので「ス」という文字を単語とみなす）にマッチする単語（例では「スカイ」）が返ってきます。 queryPlusTextについては、入力された文字にtextで返ってきた単語をくっつけたものが取得できます。\n英語であれば、スペースで区切られており、単語が切れているのが簡単にイメージできますが、日本語の場合は少し違和感が出るかと。\nこのように、入力された文字が含まれる「単語」を基本的に返す動作をするのがAutocomplete APIです。\nSuggest API では、もうひとつのSuggest APIはどういったものでしょうか？ autocomplete APIに似ていますが、返ってくるデータが登録されたデータそのものになります。\nたとえば、micという文字列を入力とした場合、\nPOST https://{{host}}/indexes/suggester-test/docs/suggest?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;mic\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } 次のような結果が返ってきます。Autocompleteの時は単語でしたが、こちらは入力データがそのまま返ってきています。 入力データの中にmicで始まる単語が含まれたものが候補となっています。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.text\u0026#34;: \u0026#34;Bluetooth Mic\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;5\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;Microsoft Office\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;Microsoft Azure\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;2\u0026#34; } ] } 日本語の場合、Autocompleteとは異なり、その単語を含むものがサジェストされるので、「東京」をsearchに指定すると「東京」を含むデータが出てきます。\n### Suggest in Japanese POST https://{{host}}/indexes/suggester-test/docs/suggest?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;東京\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } レスポンスはこちら。単語を含む元の文字列が返ってきます。ここまでは違和感はありません。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.text\u0026#34;: \u0026#34;東京タワー\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;7\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;グランメゾン東京\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;9\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;東京都庁\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;10\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;東京スカイツリー\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;6\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;東京特許許可局\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;8\u0026#34; } ] } では、「東京」「特許」という2つの単語をスペースで区切ったものが入力されたとするとどうでしょう？\n### Suggest in Japanese POST https://{{host}}/indexes/suggester-test/docs/suggest?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;東京 特許\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } スペースがありますが、内部処理では形態素解析器が分割した後でこの単語の順番で出てくるものを探しているので、出てくることになります。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.text\u0026#34;: \u0026#34;東京特許許可局\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;8\u0026#34; } ] } なお、このSuggestのAPIは、単語の語順を気を付ける必要があります。 「特許」「東京」と順序を入れ替えたスペース区切りの場合は、\n### Suggest in Japanese POST https://{{host}}/indexes/suggester-test/docs/suggest?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;特許 東京\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } 結果は返ってこないです。おそらく内部では、フレーズクエリで、最後の単語だけを前方一致で検索するような仕組みが動いているのだと思われます。 スペースで区切られてはいるが、順序があるので少し違和感を感じるかもしれません。英語だとフレーズの部分のイメージは沸きやすいのですが。\n短い文章のデータ（例：本のタイトルやランドマーク名など）では、このSuggestAPIを利用するとデータそのものが返却されるので、便利かもしれません。\nまとめ ということで、Azure Cognitive SearchのSuggesterの簡単な紹介でした。APIのページにはそのほかのパラメータについても説明があるので、使ってみようと思う方は目を通していただくのがよいかと。\n今回のブログは裏の仕組みがどんな感じなのか？を想像しながらAPIについて調べた形になります。日本語の場合に、少し違和感を覚える人もいそうだろうなということでブログを書いてみました。 今回は書いていませんが日本語でAutocompleteをやりたい場合は、読み仮名でも漢字が表示されるほうがよいという場合もあると思います。 その場合は、用意されている機能では難しいので、独自実装するといった方法になりそうです。 英語や、読みを利用しない場合は、挙動を理解していれば役に立つ場面もありそうです。\n","date":1612515120,"dir":"post/2021/","id":"931b2ebd9bfaeb5dcf1973e724a1f8d0","lang":"ja","lastmod":1612515120,"permalink":"https://blog.johtani.info/blog/2021/02/05/autocomplete-and-suggest-on-azure-search/","publishdate":"2021-02-05T17:52:00+09:00","summary":"Azure Cognitive SearchにSuggestやAutocompleteの機能があるのを見つけたので、どんな挙動なのかを調べてログとして残しておきます。 公","tags":["azure search"],"title":"Azure Cognitive Searchでオートコンプリートやサジェストをしてみる"},{"contents":"オライリー・ジャパンから出ている「コンピュータシステムの理論と実装」を読み始めたのでメモを取ることに。\n原著はオライリーじゃないのかというのが、まず最初の気づきでした。\nNANDからテトリス コンピュータのハードウェアからOS、さらにその上で動くアプリケーションまでを動作させるというのを少しずつやっていくという書籍みたいです。 イントロと1章を読みましたが、1章では論理回路の話でした。\n実際に物理的に作るわけではなく、シミュレーターなどのソフトウェアが用意されており、 そのソフトウェア上で動くものを作っていくことになります。 ソフトウェアのために専用のサイトが用意されて、ダウンロードもできるようになっているので、実際に手を動かしながら理解を進める感じになるのかと。\n目次を見ていただくとわかりますが、すごく幅が広いです。 1年で読み終われるかなぁ？まぁ、のんびりやっていこうかなと。\n用意されているソフトウェアなどで便利だなと思ったのは、どの章からでも興味のある部分から始められるようになっているようです（まだ始めてなくて。。。） 内部ではすべてのパーツがそろえてあるけど、章ごとのプロジェクトでは、個別に自分で実装したものがあればそちらが動くという挙動のようです。\nということで、ちょっとずつやっていこうかなと。 ほんとにテトリス動くのかなぁ？\n","date":1612424444,"dir":"post/2021/","id":"aa61b4543e8a7c67fccabee27a6e99cd","lang":"ja","lastmod":1612424444,"permalink":"https://blog.johtani.info/blog/2021/02/04/reading-elements-of-computing-systems/","publishdate":"2021-02-04T16:40:44+09:00","summary":"オライリー・ジャパンから出ている「コンピュータシステムの理論と実装」を読み始めたのでメモを取ることに。 原著はオライリーじゃないのかというのが","tags":["輪読","Nand2Tetris"],"title":"「コンピュータシステムの理論と実装」を読み始めた #Nand2Tetris"},{"contents":"Corne使ってましたが、数字キーがあるとどうなのかな？というのがやはり気になって。 そこに、Kochi KeyboardさんからSofle Keyboard v2というのが発売されたので組み立ててみました（去年末に）。また、先日Corne Light v2のBLE化に成功したので、Sofle keyboard v2のBLE Pro Micro + LPME-IO化にもチャレンジしてみました。\nSofle keyboard v2 ビルドログ 自分で書くよりもすごくよくできたビルドログがKochi Keyboardさんで公開されているので、そちらを参考にしてください。\nSofle Keyboard v2ビルドガイド すごく詳しく書いてあります。なので、こちらを見ていただければ問題ないかなと。 ただ、自分ではいくつか失敗したので自戒を込めてログを残しておきます。\nOLED用のジャンパをはんだ付けし忘れ 単にビルドログを流し読みしたツケが。。。 Sofleは同じ基盤を左右で利用します。なので、右手と左手で、同じ基盤の表と裏を利用します。 OLED用のジャンパする部分は両面に用意されていますが、はんだでジャンプするのはPro Microが実装される面となります。\n両面にジャンプ用のランドがあるとは気づかないで、左手の裏面をジャンプしてすべて実装し終わってから、OLEDが表示されないことに気づいてしまいました（ビルドログ用にと思って撮った写真に証拠が残ってますねｗ）。。。\nということで、またはんダッシュ太郎くんのお世話になりました（Pro Microを外してジャンプしました）。本当に有能ですよ彼は。。。\nAmazon | サンハヤト はんだシュッ太郎NEO 45Wタイプ HSK-300 | ハンダゴテパーツ ソケットのはんだ付け甘すぎ あとは、慣れてきたなぁと思っていたところに天罰が。 キースイッチのソケットを付けるの慣れてきたなーと思って、サクサクとつけていたのですが、 いざキースイッチをはめるときにボロボロとはがれていきましたｗ 半分くらいは外れたんじゃないかな？ちゃんとはんだ付けした後にピンセットなどで軽くいじってみるべきですね。。。\n滑り止め 利用しているキーキャップがOEMプロファイルということもあり、数字キー側を少し高くしたほうが入力しやすいです。そのために、少し大きめのソフトクッションを購入しました。\nAmazon | WAKI ソフトクッションCN-020 クリアータイプ: 産業・研究開発用品 上の左右の角に貼り付けると、がたつきがあったので少しずらして貼り付けて安定させています。 OLEDのプレートの部分を押すと手前が浮き上がってしまいますが、そこにはキーはないので問題ないかと。\nということで、毎回気づきがあって面白いですね。。。\nSofle keyboardのBLE化 Corne LightのBLE化がうまくいったので、もうひとセットのぎけす屋さんから購入しました。 BLE Micro ProやLPME-IO、電池基盤などについては前回のCorneのBLE化の記事を参照してください。\nハードウェア編 Sofle keyboard v2は残念ながらせきごんさんの公式ページの対応キーボード一覧には掲載されていません。 が、Sofle KeyboardのGitHubのページには次のような記載があります。\nSofle is 6×4+5 keys column-staggered split keyboard with encoder support. Based on Lily58, Corne and Helix keyboards.\n基盤の写真のPro Micro周りもCorneに似ています。 ということで、おそらくBLE + LPME-IO化が行けるのでは？と予測して作業に取り掛かりました。\nPCBの確認 Sofle Keyboardの基盤の設計図はGitHub上に公開されています。 この設計図を見る方法をまずは探しました。\n自作キーボードについて探すにはまずはサリチル酸さんのブログ「自作キーボード温泉街の歩き方」です。 回路図なので、設計ノウハウあたりのカテゴリーにあるだろうと探したところ見つかりました。\n（設計者向け）オートルーターを使って睡眠時間を確保しよう 配線のテクニックというブログですが、回路図を書くためのツールKiCadについて記載があります。 このブログにある以下の記事をもとに、KiCadのインストールや使い方をちょっとだけ勉強しました。\nfoostanさんのMeishi Keyboardの開発者向けガイド(JP) KiCadことはじめ KiCadの中の回路図エディタ「Eeschema」でSofle keyboardのPCBのフォルダを開くと回路図が開きます。 実際の基盤になる前に、Pro Microのどの足と何がつながっているのか？などが見て取れます。 前回のCorneのBLE化でLPME-IO対応したときに、学習しましたが、 TRRSの足とPro MicroのSDAとSCLをつなぐことで、LPME-IOを使うことができるようになるというのがわかっています。 それをもとに回路図を見たところ、以下のような記述がありました。\nどうも、JP9とJP10というはんだでジャンプする場所を用意してくれていそうです。 先を見越した設計本当にありがたいですね。\nJP9とJP10のはんだ付け 今ついているPro Microを外し（またはんダッシュ太郎が活躍）、基板を確認したところ対象の個所がありました。下の写真は左手の裏側です。\nこれらをはんだでジャンプします。\n右手は表側にあるので、Pro Microを外した後にジャンプしました。 左手は裏側です。 Corne Lightでは、Pro Microの足から導線を使ってTRRSの足につなぎましたが、今回はすっきり実装できました。 ジャンプした後はBLE Micro Proをはんだ付けします（はんだ付けせずに動作確認しようとしましたが、うまく通電しなくてちゃんと動かなかったです）。\nLPME-IOのジャンパ LPME-IOのGitHubページにあるように、利用するキーボードによって、いくつかはんだでジャンプする必要があります。 これは、BLE Micro Pro用のConfigファイルを見て、対象を決める必要があります。 が、Sofleは事前に用意されたものがありません。\nConfigファイルの生成 用意されていないConfigファイルが、QMKの設定ファイルから生成することができるようななっています（本当に感謝しかないですね）。 手順はBLE Micro Proのドキュメントにありました。\n新しいキーボード用の設定を作成する - QMK用の設定から変換する この変換スクリプトで３種類のconfig（右手用、左手用、LPME-IO用）が生成されます。 私の場合はLPMEを利用するので、lpmeという名前の入ったconfigを利用します。 中を見るとcol以下の記載が以下の通りだったので、8からDをジャンプします。\n\u0026#34;col_pins\u0026#34;:[18, 17, 16, 15, 14, 13, 18, 17, 16, 15, 14, 13], ここまででハードウェア側が終了です。\nファームウェア・設定編 ハードウェアの実装が終わったので、ファームウェアおよびアプリの設定です。\nファームウェアのセットアップ キーボードをUSBで接続し、BLE Micro Pro Web Configuratorのページにアクセスすると、 セットアップ初期画面が出てきます。\n公式ページの「キーボードを選ぶ」を参考にファームウェア、アプリのアップデートを行います。 「設定ファイルの書き込み」のタイミングでupload your ownを選択すると、ファイル選択画面が出てくるので、変換スクリプトで生成したJSONファイルを選択します。 このとき、Mas Storage Classとしてキーボードが認識されている状態だとうまく書き込めなかったので、キーボードのドライブを「取り出し」してからファイルをアップロードしました。\nキーマップの設定 BLE Micro Proのアプリが設定をきちんと認識すれば、あとはWeb Configuratorでキーマップの設定が可能になります。 これまた、残念なことに、BLE化する前のキーマップをJSONファイルで保存してなかったので（泣きそうｗ）、QMKのkeymap.cのファイルをもとに、ブラウザ上でがんばって設定しましたｗ また、新しい設定ではBLE関連のキーをマッピングとして追加しています。\nBluetooth接続 あとは、接続確認です。 MacとWin２台と接続するのですが、Win→Mac→Winの順番でBluetoothの接続をやっていたら、なぜか３つ目のWindowsで接続候補に出てくるけど、接続しようとするとタイムアウトをするという現象に遭遇しました。 MacのBluetoothの設定を一旦削除してから、Win→Win→Macの順番でペアリングしたところ問題なく接続できました。ただ、これが本当の対処なのかどうかは不明です。３番目だと接続できなかったWindowsマシンは再起動もしてみたのですがダメでした。この辺よくわかってないなぁ。\nまとめ ということで、Corne Lightに引き続き、Sofle Keyboard v2もBLE＋LPME化に成功しました。 導線なども使わずにLPME対応ができたので見た目もすっきりしています。 これで、KVMスイッチだと２台までしか切り替えできなかったのが、３台をひとつのキーボードで操ることができるようになりました。 だいぶ楽になりそうな予感がしています。\nまだ、完ぺきではないので、次のような対応をやっていく予定です。\nロータリーエンコーダー対応：BLE以前はQMKのkeymap.cの中でロータリーエンコーダーの動作を記述していたので、BLE Micro Proでどうやるのかを調べたい。encorder.jsonというファイルがあったのでその辺ではないかな？ OLED対応：Corne Lightの時と同様に、OLEDが点かなくなったのでこの辺りを調べたい。 ということで、とりあえずキー入力するのには困らない程度にはできたので、より便利にする方法を時間を見つけて模索する感じになりそうです。 あと、KiCadも面白そうなのでこっちもちょっと触ってみたくなってきたかも？\n","date":1612106122,"dir":"post/2021/","id":"d95522c691013bfe66dd46ded85a98ed","lang":"ja","lastmod":1612106122,"permalink":"https://blog.johtani.info/blog/2021/02/01/apply-ble-to-sofle/","publishdate":"2021-02-01T00:15:22+09:00","summary":"Corne使ってましたが、数字キーがあるとどうなのかな？というのがやはり気になって。 そこに、Kochi KeyboardさんからSofle Keyboard v","tags":["DIYキーボード","misc"],"title":"Sofle v2を組み立てて、BLE+LPME-IO化してみた #DIYキーボード"},{"contents":"メインマシンとMacは下記のサンワサプライのUSB接続のKVMスイッチを使っていますが、もう一台ノートPCがありここに接続しているCorne（初めてのDIYキーボード）が長いUSBケーブルでつながっています。\nAmazon | サンワダイレクト USB切替器 キーボード・マウス用 KVMスイッチ 時々必要になって、デスクにキーボードだけ引っ張ってきて利用するのですが、ケーブルの取り回しがまぁ邪魔で。。。 BLE対応（BLE Micro Pro）をしてみようかなということに。\nBLE + LPME-IO対応 分割キーボードをBLE対応(それぞれにBLE Micro Proを実装)すると、キーボード間のつながりがいまいちになることもあるというのをちらほら見ていたので、BLE Micro Pro + LPME-IOという構成で、 Corneのキーボード同士はTRRSケーブルで接続し、PCとCorne間をBluetoothで接続する構成にしてみました。\nBLE Micro Proについては、公式ドキュメントにいろいろと記載があります。\n材料 ということで、材料は以下の通り。セット販売は売り切れていたので、個別に購入しました。 コンスルーと電池以外は１つずつです。\nBLE Micro Pro(のぎけす屋) x 1 LPME-IO(のぎけす屋) x 1 BLE Micro Pro用電池基盤(遊舎工房) x 1 コンスルー(Kochi Keyboard) x 4 CR1632ボタン電池（近所のスーパー） x 2 実装 まずは、それぞれ組み立てです。\n電池基盤 以下の記事を参考にはんだ付けしました。\nQiita: 自作キーボードビルドログ：その２「ErgoDash」無線化対応 ハードウェア編 - 電池基盤の組み立て・半田付け yfuku docs - Claw44 / 無線接続について 注意点は以下の通りです。\n基盤が軽いので固定が必要（マスキングテープでマットに貼り付けたらましになった） 電池ホルダーが変形しやすい（設置して、足を折るために上から押さえつけたら、本体が曲がってしまった。。。） 部品が細かいので大変（老眼だから？） BLE Micro Proとの接続は参考にしたyfuku docsにある方法（余っていたピンヘッダを１本ずつ使ってはんだ付け）を採用しました。 （パッと見大丈夫そうだったので電池基盤の裏に絶縁テープは貼ってないです貼ってないです）\nBLE Micro Pro（もげ対策） BLE Micro Pro自体はコンスルーをはんだ付けするだけですが、今回はもげ対策として、ダイソーで買ってきたグルーガンで ちょっとだけ補強してみました。 初グルーガンだったので不細工だけど。これ難しいな。\n効き目あればいいけど？\nLPME-IO対応 いくつかのジャンパをはんだでブリッジ まずは、LPME-IOのREADMEのページの導入手順を読み、いくつかのピンをジャンプしました。 せきごんさんのBLE-Micro-Proのリポジトリに、CorneのLPME用コンフィグファイルを見ると、ジャンプするのは20, 19, 18, 17, 16, 15に対応している、F,E,D,C,B,Aの６つです（写真撮り忘れた。。。）。\nTRRSのI2C対応（って言い方であってるのかなぁ？） ジャンプだけでいけないかなぁ？と思いましたがダメでした（USBでつないでみたけど、左手（BLE-Micro-Proがついている側）だけ入力可能です。\nBLE Micro Proの公式サイトにLPME-IOについても記載があります。 実績のあるキーボード一覧にCorne Lightの記載もあったので、試してみようと思ったのが発端です。\nただ、LPME-IOの欄に注意書きが。\n*LPME-IOを使うには改造が必要\nまた、一覧の最初にも記載があります。\nLPME-IOを使うにはキーボードの左右の有線通信がI2Cである必要があります。とくにOLEDに対応しているキーボード等の場合は、I2C用のピンをTRRSジャックに接続する改造を施すことでI2C化できる場合があります。\nまだ、自作キーボードの仕組みをがっつり理解しているわけではない初心者なので、まぁ、ちょっとわからないかなと。。。 BLE Micro Proのはじめにのページを見ると、 Self Made keyboard in JapanのDiscordに専用チャネルがあるようで、過去ログを検索してみました。 検索したところ、Corneの場合Micro ProのSDA(写真の青い線)とSCL(写真の黄色い線)（参考：Corneの基盤の図）をそれぞれ、TRRSの２つのピンに接続する必要がありそうだというコメントがありました。\nCorne Cherry v2の場合は、接続するためのショートカットが用意されていましたが、Corne Light v2だと見当たりませんでした。 ということで、線を使って物理ショートカットしました。ちなみに、ショートカットは両手ともに必要なようです。\nUSB-Cで接続テスト 上記対応が終わって、基板に設置してUSB-Cケーブルで接続したところ、外部ドライブとして見えるようになりました。\nキーマップの書き換えとか 公式ドキュメントのBLE Micro Pro Web Configuratorを使うの手順通りに書き込みを行っていくと、特に問題なく接続できました。 便利すぎですね。キーマップの変更は、これまでのCorneのキーマップJSONファイルからコピペして書き込んだだけです。 （この後、BLE用のキーマップを書き足すためにもう一度変更しますが）\nLPME-IO対応なので、Micro Proは片側しかないので、書き換えも楽々でした。\nBLEで接続テスト 今回の目的だったWindowsにBluetoothで接続できるようにしてみました。 最初はサリチル酸さんの記事を見ていたのですが、キーコードがちょっと変わっているようでした。\nで、よくよく見ると、BLE Micro Pro Web ConfiguratorにBLE関連のキーも用意されているじゃないですか。。。\nBLE関連のキーを割り当てた後は、USBをオフにして、Bluetoothをオン、BTNEWで新しくペアリングするようにすれば接続完了でした。\n課題 これまでと違い、すんなり実装ができましたがまだいくつか気になる点が。\n複数の機器とペアリングして切り替え Macともペアリングしてみようとしたのですが、切り替えがうまくいかないようで。。。 OLEDつけるにはどうするんだろう？ 左手側は電池が乗っているのですが、右手側はLPME-IOだけなので、上にOLEDを載せる余裕があります。 なので載せてみましたが点かないですね。ファームウェアを何かしないといけないんじゃないかな？調べないとなぁ。 という感じです。 まだちゃんと長時間使っていないので、他の問題点も出てくるかもしれませんが、まぁとりあえず使ってみてからかな。 うまくいくようなら、メインマシンにBluetoothモジュール追加してみるのもありかと考えているところです。\n調べながら、自分なりに対応してみましたが他にもいい方法とかあれば教えてもらえると助かります。\n","date":1610332951,"dir":"post/2021/","id":"4ad8239a37f641bcd17abeb96106314e","lang":"ja","lastmod":1610332951,"permalink":"https://blog.johtani.info/blog/2021/01/11/apply-ble-and-lpme-to-corne/","publishdate":"2021-01-11T11:42:31+09:00","summary":"メインマシンとMacは下記のサンワサプライのUSB接続のKVMスイッチを使っていますが、もう一台ノートPCがありここに接続しているCorne","tags":["DIYキーボード","misc"],"title":"Corne Light v2のBLE+LPME-IO対応 #DIYキーボード"},{"contents":"振り返りブログにも書きましたが、デスクトップPCを自作(DIY)しました。 組み立てたに使ったパーツのアフィリンクを貼っておきます。\n10月くらいにPC組もうと思って、組み上がったのは11月半ばでした。 最初はもうちょっと小さいPCにしようと思ってたのに気づいたらATXになってました。 パーツの選定の基準は以下のツイートです。影響されやすいなぁ。\nタワーってほど大きくなくていいと思いますが、NZXT H510 ぐらいの大きさは欲しいですね。https://t.co/s1c1fOnPyI\n単純に、スペースがないと組みにくいのと冷えにくい、買ってきたものがやっぱりこれだと入らない、というリスクがかなり減るので。\n\u0026mdash; さぼてん（さぼ福）🌵 (@cactusman) October 9, 2020 今年3台作りました。ノートPC使えない体になります。 pic.twitter.com/8zDmeRwNkS\n\u0026mdash; miyake | ZEN (@kazuyukimiyake) October 9, 2020 白いケースいいなぁという感じで、ケースとCPUクーラーが決まったんで、ググってこちらのHAKKAさんのYouTube見ながら妄想してました。 パーツがなかなか揃わなくて。 そして、PCが光るのどうなの?と思ってたのに、気づいたら光ってました(なぜ?)。\nグラボがない状態(CPU内蔵GPU)で12月頭までは動作してました。\n購入自体はTSUKUMO、ビックカメラオンライン、パソコンSHOPアーク、イートレンドオンラインショップでオンラインで購入しました。\nPCケース Amazon | NZXT H510i White CA-H510I-W1 CS7946 | NZXT | PCバッグ・ケース・スリーブ 電源 Amazon | NZXT E850 デジタル電源ユニット 80 Plus Gold 認証 [ 定格 850W 出力 ] NP-1PM-E850A-JP NP-1PM-E850A-JP SP947 | NZXT | パソコン・周辺機器 通販 マザーボード Amazon | ASRock AMD Ryzen 3000シリーズ CPU(Soket AM4)対応 X570チップセット搭載 ATX マザーボード X570 Steel Legend | ASROCK CPU AMD Ryzen 4750G\nCPUクーラー Amazon | NZXT KRAKEN Z63 簡易水冷CPUクーラー 液晶モニタ搭載 RGB対応 280mm RL-KRZ63-01 FN1441 | NZXT | CPUファン 通販 メモリ Amazon | G.SKILL 128GB（4 x 32GB）Trident Z NeoシリーズDDR4 SDRAM 3200MHz PC4-25600デスクトップメモリモデルF4-3200C16Q-128GTZN | G.Skill | メモリ 通販 SSD Amazon | Seagate FireCuda 520 M.2 1TB PCIe Gen4x4 内蔵SSD M.2 2280 3D TLC ZP1000GM3A002 | SEAGATE グラボ Amazon | GIGABYTE NVIDIA GeForce RTX3080搭載 グラフィックボード GDDR6X 10GB ホワイトモデル【国内正規代理店品】GV-N3080VISION OC-10GD | 日本ギガバイト 拡張カード Amazon | ASRock 拡張インターフェースボード Thunderbolt 3 AIC R2.0 | ASROCK | インターフェースカード 通販 拡張カードは実は差し込んだら最初うまく動かなくてサポートに連絡しました。同じ構成の検証機を用意して解決方法を見つけてもらいました。しかも数日で。サイコーのエクスペリエンスでした!\n日本語でサポートしてもらえてしかも数日で解決してもらった。ASRockのサポートすばらしかったです！ https://t.co/8FasCInIqt\n\u0026mdash; Jun Ohtani (@johtani) December 8, 2020 その他 ケースのフロントパネルのUSB-Cポートを使えるようにするために。\nAmazon | Cablecc USB 3.1フロントパネルソケットType-E-マザーボード用USB 3.0 20ピンヘッダーオス拡張アダプター | cablecc | PCアクセサリ・サプライ 通販 最近のPCパーツはUSBでモニタリングできるみたいで、マザボのUSBポートが足りなかったので拡張しました。\nAmazon | マザーボードのUSB 9ピン 増設 内部用4ポートUSB2.0 HUB | ノーブランド品 | USBハブ 通販 白いケースだし、「映え」のために白いケーブルを。\nAmazon | Novonest 電源専用延長スリーブ 補助電源モジュラーケーブル 長さ300mm 6本1セット スリーブガイド24点セット付き 【SC304】 | ｎｏｖｏｎｅｓｔ | 電源ユニット 通販 組み立て中 手元にあったCPUでBiosアップデート(Ryzen 5000シリーズにしたかったから。まだできてないけど)。\n応急処置でBiosアップデートしてる pic.twitter.com/mXf2B5kwqB\n\u0026mdash; Jun Ohtani (@johtani) November 8, 2020 さーて、頑張るぞー pic.twitter.com/HmlGqREjmP\n\u0026mdash; Jun Ohtani (@johtani) November 13, 2020 さて、仮起動実験ですよと pic.twitter.com/5HP3cbs6SH\n\u0026mdash; Jun Ohtani (@johtani) November 13, 2020 きたきたー pic.twitter.com/4sL3ymecEo\n\u0026mdash; Jun Ohtani (@johtani) November 13, 2020 コネクター刺しまくらないと pic.twitter.com/Soye3lS4M9\n\u0026mdash; Jun Ohtani (@johtani) November 13, 2020 完成はこんなかんじ 初期構成\n組み上がったよー pic.twitter.com/sBwpvLsZh3\n\u0026mdash; Jun Ohtani (@johtani) November 14, 2020 グラボデプロイ\n設置完了してこんな感じ。なんかベンチマーク走らせるかなぁ。何がいいだろ pic.twitter.com/aZufAE9fJA\n\u0026mdash; Jun Ohtani (@johtani) December 4, 2020 グラボのおまけも付けてみた。\nまぁ、せっかくついてきたので取り付けてみました（グラボ下の光ってるパネル）。 pic.twitter.com/068IxaV1ps\n\u0026mdash; Jun Ohtani (@johtani) December 4, 2020 とまぁ、こんな感じでした。 メモリは多分使い切れないだろうなぁと思いながら、やってみたかったという感じです。。。\n","date":1609422526,"dir":"post/2020/","id":"64a421c2367372c3199c66a6420faf89","lang":"ja","lastmod":1609422526,"permalink":"https://blog.johtani.info/blog/2020/12/31/diy-pc/","publishdate":"2020-12-31T22:48:46+09:00","summary":"振り返りブログにも書きましたが、デスクトップPCを自作(DIY)しました。 組み立てたに使ったパーツのアフィリンクを貼っておきます。 10月くら","tags":["misc"],"title":"PCもDIYしました"},{"contents":"今年も振り返りブログ書いてます。カタンの航海者版を購入して家族とやってましたが、負けてしまいました。\n振り返り（2019年に書いた抱負から） まずは去年の抱負を元に書きますが、3月以降はコロナウィルスの影響でいろいろと生活が変わってしまいましたね。\n職につく 厳密には達成してないことになるのかな？\n1月末にフリーランスはじめました(仮)という記事を書きましたが、 そのまま、現時点では個人事業主でフリーランスとして4社ほどお手伝いさせていただいています。\nお手伝いしてるお客さんの事例が出てた。直接的に類似画像検索の部分を手伝ってるわけではないんですが、Azure Cognitive Searchの調査とかやってます。 / 「ハッカソン」で社外の知見を積極的に活用! 富士フイルムソフトウエアが実践するサービス開発の理想形 - https://t.co/yDIwYmYDBM\n\u0026mdash; Jun Ohtani (@johtani) June 19, 2020 名前出てた。ZOZOさんの手伝いさせていただいております。 / ZOZOTOWNにおける検索速度改善までの道のり - ZOZO Technologies TECH BLOG - https://t.co/OqaFMYe0TY\n\u0026mdash; Jun Ohtani (@johtani) August 20, 2020 こんな感じです。 コロナウィルスの影響もあり、完全リモートで仕事をさせていただいています。 感謝しかないです。\nブログプラットフォームの移行 昨年の振り返りの時点で目を付けていたHugoへの乗り換えを行いました。 乗り換えについてもまとめてあります。\nOctopressからHugoへ移行中(まだ途中) ブログ移行日記(その1) - Hugoとテーマ ブログ移行日記(その2) - Markdownファイルの変換 ブログ移行日記(その3) - Hugoの設定と微調整(テーマに合わせた) ブログ移行日記(その4) - 検索機能(Algolia)の導入 ブログ移行日記(その5) - Jugemのブログを移行 無事移行できて、特に困ってない感じです。\nプログラミング 昨年よりは書いた気がしています。 まぁ、書きなぐって放置してるのもありますが。。。\n細々としたツールがいくつか。\nfrom-octopress-to-hugo bulk2es-rs azure-search-analyze-client wiki-extractor-rs kuromoji-graphviz-output kuromoji-cli あとは、Linderaという形態素解析も手伝ってみました。 ちょっと後半は忙しくなり、コーディングが減ってるんで、また復活させないと。\nRust再入門 Tantivyは結局触れてないけど、Linderaを手伝えました。あとは、ちょっとしたツール(bulk2es-rs)なども作りました。 知り合いとやっていたRust the bookを読むのも一通り終わりました。 Linderaまわりのリファクタとかを年明けにやろうかな?\n検索の勉強 仕事になりました。というか、しました。 ブッチャー本も買ったんですが、手を付けられてないので、年明けから心機一転、よみ始めようと思います。\n検索技術勉強会の継続 残念ながらだめでした。 年初にスピーカーの方に連絡は入れて履いたのですが、コロナウイルスの影響で 今年はオフラインの勉強会は無理だろうとい事で延期したままです。 オンラインの勉強会もいくつか開催されていましたが、検索技術勉強会は残念ながらモチベーションもわかずのまま今年も終わってしまいました。 単に話を聴くセミナーのようなものよりは、Podcastのような形を取るのがいいのかもなぁとは思っているのですが。。。 だれか、サクッと話したい人いたらやってみませんか?\n振り返り(今年あったできごと) さて、ここからは今年の出来事を。\n自宅環境の改善 Windowsへの移行 キーボードDIY フリーランス ブログ書いたなぁ 3月以降はずーっと自宅で仕事してました。 ということで、自宅の環境がどんどんアップデートされていった1年でした。 最終バージョンは年内に間に合わなくて、年明けに書きますが。。。 途中経過はこんな感じでした。今は更に変わっていますが。\n3月バージョン 9月バージョン 12月バージョンでも書きますが、ずっと自宅で作業だったのもあり、自作PCをやりたくなったので、久々にWindowsに帰ってきました。Ubuntuもチョット検討しましたが、Windowsに今は落ち着いています。自作PCはこんな感じ。 自作PCブログも後で書きますね。\n設置完了してこんな感じ。なんかベンチマーク走らせるかなぁ。何がいいだろ pic.twitter.com/aZufAE9fJA\n\u0026mdash; Jun Ohtani (@johtani) December 4, 2020 Windowsをお試し中 Windowsへの移行（その１） AutoHotKeyで色々と弄っているので、素のWindowsは触れる気がしないけど。。。\n自作つながりで、キーボードもDIYしました。\nDozen0を作成した Corne Light v2を作成した Corne Chocolateを組み立てた Sofle Keyboardも組み立てた(けど、ビルドブログはまだ) 分離キーボードには昨年から興味があったのですが、手を付けていませんでした。 今年は自宅でずっと作業でしたから、これを機会に作ってみました。 既製品(Moonlander)も気になってはいたのですが、DIYキーボードはプラモデル感覚で作れそうだし面白そうだなと。 今年一番ハマったものかもしれないです。 知り合いが始めたKochi Keyboardで最初に発売されたのがCorne Light v2だったので、これが初めての分割キーボードです。 40%キーボードからいきなり入ったので最初はかなり大変でしたが、なれると入力が早くなる気がします。ホームポジションからほぼ動かないのはいいですね。最初は数字列がないのでアホか???と思っていましたが。 今は、Sofle(60%キーボード)がメインになっています。40%から60%に移行すると 数字のキーが遠いなと思ってしまいますねw\nどうなるものかと思いつつ、フリーランスを続けています。 最初に仕事をいただいた富士フイルムソフトウェアさんには非常にお世話になっています(今もお手伝いさせてもらっています、ありがたい)。来年も精進していきます!\n今年はブログを書きました、最後はちょっと息切れしてる感じになってるけど。。。 もっとカジュアルに書くようにしないとなぁ。 年明けにまだ書いてないブログを書いていかないと。「自作PCブログ」「Sofleのビルドブログ」「2020年買ってよかったブログ」とか。\n来年の抱負 ということで、来年の抱負です。\nフリーランス継続? プログラミング 検索の勉強 検索のポッドキャスト? とりあえず今年は乗り切れました。来年も食べていくためにもフリーランスを継続できるように、お手伝いさせて頂いてる各社に 継続してもらえるように精進していきます。色々と勉強させて頂いてるのでほんとうにありがたいです。\nプログラミングは今年の後半はスローダウンしてしまったのでがんばらないと。 検証用のコードやちょっとしたツールを書くほうが多いので、もう少し継続してメンテナンスするようなものも書きたいなぁと。\n検索の勉強はまずはブッチャー本を買ってしまったので、ここからでしょうか。 値段も厚みもすごいので、コツコツ元を取れるようにがんばります。。。\n来年もまだまだ自宅で仕事が続きそうなので、勉強会というよりもポッドキャストみたいなものをやるのがいいのかもなと。 2020年初にやらせていただいた、「検索システム探訪」をポッドキャスト風にやるのもありなのかもなぁ。 興味ある人いたら連絡ください。公開しない雑談とかもありだと思ってるので。\n今年は色々ありましたが、無事に乗り切れました。 気軽にランチなどで遊びに行けない状況ですが、雑談相手になっていいなと思う方、連絡お待ちしています。\nさて、来年はどんなキーボード作るのかなぁ(え?また作るの??)。 今後もよろしくおねがいしまーす!\n","date":1609406004,"dir":"post/2020/","id":"a5b2ee641e10d3e4db8f888217ab9ecc","lang":"ja","lastmod":1609406004,"permalink":"https://blog.johtani.info/blog/2020/12/31/looking-back-2020/","publishdate":"2020-12-31T18:13:24+09:00","summary":"今年も振り返りブログ書いてます。カタンの航海者版を購入して家族とやってましたが、負けてしまいました。 振り返り（2019年に書いた抱負から） ま","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2020）"},{"contents":"Elastic stack (Elasticsearch) Advent Calendar 2020の18日目の記事になります。\n本日の勉強会でLTをしましたが、しゃべり足りなかったんで。 Elasticsearch 7.8でこっそりとリリースされたIndex Template V2について調べたのでどんなものかをまとめてみます。 リリースブログには出てきてない（7.8のEsのページのWhat\u0026rsquo;s newには出てた）ので気づいてない人も多いのではないでしょうか？\nIndex Templateとは？ まずはIndex Templateがどんなものかを説明しましょう。\nIndexの設定やマッピングはデフォルト値以外を設定したい場合に、毎回\u0026quot;mappings\u0026quot;や\u0026quot;settings\u0026quot;の設定を指定してIndexを作成するのは手間がかかります。 そこで便利な機能として提供されているのがIndex Templateです。このIndex TemplateはCluster Stateに保管されます。\nIndex Templateを利用するときの流れは以下の通りです。\nIndex Templateの作成 Indexの作成 例えば、3ノード構成のクラスターでインデックスを作成するときに常に\u0026quot;number_of_shards: 3\u0026quot;を設定したいとします。 Index Templateは次のような感じになります。\nPUT _template/blog_num_shards { \u0026#34;index_patterns\u0026#34;: \u0026#34;blog_*\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;index\u0026#34;: { \u0026#34;number_of_shards\u0026#34;: 3 } } } または日本語のシンプルな形態素解析のアナライザーの設定を\u0026quot;jp_\u0026ldquo;という名前でるようできるようにしたい場合には次のような感じになります。\nPUT _template/jp_simple_kuromoji { \u0026#34;index_patterns\u0026#34;: \u0026#34;jp_\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;index\u0026#34;: { \u0026#34;analysis\u0026#34;: { \u0026#34;simple_jp\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji\u0026#34; } } } } } インデックステンプレートの登録が終われば、インデックスを作成するタイミングでIndex Templateが適用されます。 例えば、blog_2020というインデックスを作成すると、number_of_shards: 3のインデックスが作成されます（デフォルトは1）。 jp_blog_2020というインデックスを作成すると、simple_jpというAnalyzerが設定されています。 このように、インデックス名を意識するだけで設定が適用されていくのが利点です。\nちなみに、Index TemplateはIndex作成時に適用されるだけなので、Index Templateを変更してもこれまでのインデックスへは影響はありません。\nこれまでのIndex Templateの問題点 と、Index Templateが便利なのはわかりましたが、ではなぜ今回V2がリリースされたのでしょうか？ 先ほどの例を見るとわかりますが、これまでのIndex Templateは部品化が難しいのが問題でした。 Index Templateはそれぞれがインデックスの作成時に適用されます。 が、Index TemplateにIndex Templateを組み込むことはできません。 例えば、先ほどサンプルとして作成したjp_simple_kuromojiのIndex Templateはjp_で始まるインデックスにしか適用できません。\nでは、blog_で始まるインデックスにもkuromojiのシンプルなアナライザーを使いたくなった場合はどうなるでしょう？ 残念ながら、jp_simple_kuromojiと同じ設定をblog_num_shardsのテンプレートに追加するか、jp_simple_kuromojiのindex_patternsの部分だけを書き換えた新しいテンプレートを用意するか、jp_simple_kuromojiのindex_patternsにjp_を追加する方法です。 いずれにしてもIndex Templateの継承（複数のテンプレートを1つのインデックスに紐づける）が必要となります。 この時、複数のIndex Templateが適用されるため、適用する順番が出てきます。 この順番をIndex Templateのorderパラメータで指定できます。\nただ、これも問題のもととなっていました。 複数あるIndex Templateのどれがどの順番で適用されるのか？それはインデックスを作成時にようやくわかります。 使いたい側（インデックス）が、使いたいもの（テンプレート）を指定するのではなく、その逆（使いたいものに使いたい側の情報を設定しなくてはならない（index_patternsやorder））になっているのでわかりにくくなっていました。\nということで解決策としてリリースされたのがIndex Template V2です（ちなみに名前にV2とは言ってるわけではなく、現在のIndex Templateの機能がlegacy index templateという名前になり、Deprecatedになっています（まだログには出ない））。\nIndex Template V2 7.8のWhat\u0026rsquo;s newドキュメントではComposable Index Templateと紹介されています。 大きく3つのエンドポイントが提供されます。\nComponent Template 用API テンプレートのコンポーネントという単位で管理するためのAPI。 登録更新、削除、取得が可能 Index Template 用API Index Templateを管理するためのAPI 登録更新、削除、取得が可能 Simulate index template API(Experimental) Index Template Legacy Index Templateとの大きな違いは、\nテンプレートをコンポーネントにできる 1つのインデックスに適用されれるテンプレートは1つだけ という点です。これまでとは挙動が異なるので注意が必要です。\n新しいIndex Templateを利用する際の流れは次のようになります。\nComponent Templateの作成 Index Templateの作成 作成したIndex Templateの挙動を確認 実際にIndex名を指定してIndex Templateの挙動を確認 という形です。では、それぞれの機能を見ていきましょう。\nCoponent Template API テンプレートコンポーネントを管理するためのAPIです。 具体的なAPIごとに説明していきます。\nPUT _component_template コンポーネントを登録、変更するためのAPIです。公式ドキュメントはこちらです。 先ほどのkuromojiのAnalzyerをコンポーネントとして登録してみましょう。\nPUT _component_template/jp_simple_kuromoji { \u0026#34;template\u0026#34;: { \u0026#34;settings\u0026#34;: { \u0026#34;index\u0026#34;: { \u0026#34;analysis\u0026#34;: { \u0026#34;analyzer\u0026#34;: { \u0026#34;simple_jp\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji_tokenizer\u0026#34; } } } } } }, \u0026#34;version\u0026#34;: 1, \u0026#34;_meta\u0026#34;: { \u0026#34;description\u0026#34;: \u0026#34;simpleなKuromoji analyzer\u0026#34; } } 先ほどと特に違いはありません。templateという階層が1段増え、index_patternsがなくなりました。 template部分はIndexに設定するsettings、mappings、aliasesが指定可能です。 ちなみに、\u0026ldquo;template\u0026quot;の中身をそのままIndex作成時に使用した場合にエラーにならない設定である必要があります。 ここは注意が必要です。例えば、component Aでkuromojiのアナライザーの設定をし、component Bでそのアナライザーを使用するフィールドのmappingだけを記述した場合、component Bでエラーが発生します。上記のようなシチュエーションでは、Index Templateで利用するフィールドを定義し、component Aを利用する宣言をすれば問題ありません。\nそのほかに使えるパラメータで便利なものを紹介しておきます。\nクエリパラメータ\ncreate: URLに指定するパラメータ。trueを指定することで、既に存在する場合にエラーを返してくれる。更新も同じAPIなので間違わないようにするために利用すると便利。デフォルトはfalse リクエストボディ\n_meta: テンプレートにメタ情報を付与できる。_metaの中は自由に記述可能。コメントなどを書いておくとあとでわかりやすい GET _component_template コンポーネントを取得するためのAPIです。公式ドキュメントはこちらです。 一覧での取得とリストでの取得が可能です。\n一覧取得サンプル\nGET /_component_template GET /_component_template/* これ以外に、IDを指定して取得することも可能です。\nGET _component_template/jp_simple_kuromoji *を利用して複数取得も可能です。\nGET _component_template/jp* GET _component_template/j*_* DELETE _component_template コンポーネントを削除するためのAPIです。公式ドキュメントはこちらです。 IDを指定してコンポーネントを削除できます。\nDELETE /_component_template/jp_simple_kuromoji ID指定以外に*を利用することも可能ですが気を付けて使用しましょう。\nDELETE /_component_template/jp_* DELETE /_component_template/* ちなみにIndex Templateで利用されているコンポーネントを削除しようとした場合はエラー（ステータスコード400）が返ってきます。 *などを使用して削除しようとした場合は、ひとつでも利用されているものが含まれている場合は削除は実行されずにエラーだけが返ってくるようになっています。\nIndex Template API Index Templateを管理するためのAPIです。 Component Template APIで定義したコンポーネントを利用してテンプレートを作成できます。コンポーネントを利用しないで単体で完結したテンプレートも作成可能です。 具体的なAPIごとに説明していきます。\nPUT _index_template Index Templateを登録・更新するためのAPIです。公式ドキュメントはこちらです。\nこれまでのLegacy Index TemplateのAPIのエンドポイント(_template)ではなく、(_index_template)というエンドポイントになっていることにまず注意してください。 先ほど作成したjp_simple_kuromojiコンポーネントと、追加で作成した3_shardsというコンポーネントを利用して blog_で始まるインデックスに適用できるIndex Templateを作成してみましょう。\nPUT _index_template/blog_template { \u0026#34;index_patterns\u0026#34;: [\u0026#34;blog_*\u0026#34;], \u0026#34;template\u0026#34;: { \u0026#34;mappings\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;hoge\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;text\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;simple_jp\u0026#34; } } } }, \u0026#34;priority\u0026#34;: 100, \u0026#34;composed_of\u0026#34;: [\u0026#34;jp_simple_kuromoji\u0026#34;, \u0026#34;3_shards\u0026#34;] } composed_ofというパラメータに利用したいコンポーネントを配列で記述していきます。 Index Templateが適用される時に、ここに記述されている順番でコンポーネントが適用されていきます。 ですので、最後に書いてあるテンプレートが一番強いことになります。 これは例えば、同じ設定値number_of_shardsを2つのコンポーネントが設定している場合に、最後に設定した値がインデックスに採用されるという意味です (公式ドキュメントにサンプルが掲載されています)。 なお、存在しないコンポーネントをcomposed_ofに指定した場合は400エラーが返ってきます。同じコンポーネントを複数重複して指定した場合は特にエラーにはなりませんでした。 composed_ofを指定しなければ、単体で完結したテンプレートを定義可能です。\n次に重要な設定はpriorityです。これまでのテンプレート機能と異なる点で説明しましたが、\n1つのインデックスに適用されれるテンプレートは1つだけ となっています。 この1つを決めるための値がpriorityになります。 インデックス名によってはindex_patternの定義によって、複数のIndex Templateにマッチします。例えばblog_*と*_2020のIndex Templateがあった場合にblog_2020というインデックスを作った場合です。 この時、Elasticsearchはpriorityの大きい値を持ったIndex Templateだけを適用します。 blog_*のIndex Templateのpropertyが10、*_2020のIndex Templateのpropertyが100だった場合、*_2020のテンプレートが適用されます。Legacy Index Templateではorderという似たパラメータがありましたが、こちらは適用する順序を決定するためのものでした。挙動が違うので注意しましょう。\nちなみに、blog_*と*_2020のpropertyがどちらも10というIndex TemplateをPUTしようとした場合、2番目にIndex TemplateをPUTするタイミングでエラーが返ってきます。\nそのほかに使えるパラメータで便利なものはPUT _component_templateと同様にcreateと_metaです。\nGET _index_template Index Templateを取得するためのAPIです。公式ドキュメントはこちらです。 一覧での取得とリストでの取得が可能です。\n一覧取得サンプル\nGET /_index_template GET /_index_template/* これ以外に、IDを指定して取得することも可能です。\nGET _index_template/blog_template *を利用して複数取得も可能です。\nGET _index_template/blog_* GET _index_template/b*_* DELETE _index_template Index Templateを削除するためのAPIです。公式ドキュメントはこちらです。\nIDを指定してコンポーネントを削除できます。\nDELETE /_component_template/jp_simple_kuromoji ID指定以外に*を利用することも可能ですが気を付けて使用しましょう。\nDELETE /_component_template/jp_* DELETE /_component_template/* 最後のサンプルを実行すると、Elasticのツールなどが登録したIndex Template以外はすべて削除されてしまうので本当に気を付けましょう。\nSimulalte API さて、コンポーネントとテンプレートを作成したので確認をしましょう。 Legacy Index Templateでは確認するためには実際にインデックスを作成するしかありませんでしたが、V2ではSimulate APIが用意されています。 このSimulate APIには2つのAPIがあります。\nPOST /_index_template/_simulate/\u0026lt;テンプレート名\u0026gt; POST /_index_template/_simulate_index/\u0026lt;インデックス名\u0026gt; Index Templateの確認のためのAPIとインデックス名を指定したときに出来上がるIndexの設定を確認するためのAPIです。 Indexを実際に作成しなくても確認できるのは便利ですね。\n例えば先ほど作成したblog_templateを試してみましょう。\n_index_template/_simulate API POST _index_template/_simulate/blog_template レスポンスはこんな感じです。\n{ \u0026#34;template\u0026#34; : { \u0026#34;settings\u0026#34; : { \u0026#34;index\u0026#34; : { \u0026#34;analysis\u0026#34; : { \u0026#34;analyzer\u0026#34; : { \u0026#34;simple_jp\u0026#34; : { \u0026#34;filter\u0026#34; : [ \u0026#34;kuromoji_readingform\u0026#34; ], \u0026#34;type\u0026#34; : \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34; : \u0026#34;kuromoji_tokenizer\u0026#34; } } }, \u0026#34;number_of_shards\u0026#34; : \u0026#34;3\u0026#34; } }, \u0026#34;mappings\u0026#34; : { \u0026#34;properties\u0026#34; : { \u0026#34;hoge\u0026#34; : { \u0026#34;type\u0026#34; : \u0026#34;text\u0026#34;, \u0026#34;analyzer\u0026#34; : \u0026#34;simple_jp\u0026#34; } } }, \u0026#34;aliases\u0026#34; : { } }, \u0026#34;overlapping\u0026#34; : [ { \u0026#34;name\u0026#34; : \u0026#34;blog_template2\u0026#34;, \u0026#34;index_patterns\u0026#34; : [ \u0026#34;blog_*\u0026#34; ] } ] } templateにコンポーネントがマージされた結果が出力されます。 overlappingはindex_patternsがかぶる可能性があるIndex Templateの情報が出力されます。 サンプル用にblog_template2という、同じindex_patternsでpriorityが低いものを登録してあるためです。 index_patternsが完全に同じではなくとも、重複する可能性があるものはここに出力されます。 例えば、index_patternsがb*という別のIndex Templateを作成してからSimulate APIを実行すると、overlappingにそのIndex Templateも出力されます。\nSimulate Index Template APIのもう一つの機能は登録前のIndex Templateの確認です。 リクエストのURLのテンプレート名をなくし、PUT _index_templateと同じJSONをリクエストボディとして送信した場合、コンポーネントをマージしたテンプレートがどんなものかを確認できます。\nPOST _index_template/_simulate { \u0026#34;index_patterns\u0026#34;: [\u0026#34;blog_*\u0026#34;], \u0026#34;template\u0026#34;: { \u0026#34;mappings\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;hoge\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;text\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;simple_jp\u0026#34; } } } }, \u0026#34;priority\u0026#34;: 10, \u0026#34;composed_of\u0026#34;: [\u0026#34;jp_simple_kuromoji\u0026#34;] } このリクエストを送信すると、コンポーネントがマージされた結果が返ってきます。index_patternsがかぶるものがある場合はoverlappingも一緒に返却されます。\n_index_template/_simulate_index API 今度はインデックス名を指定するSimulate APIを試してみましょう。\nPOST _index_template/_simulate_index/blog_2021 これだけです。\n{ \u0026#34;template\u0026#34; : { \u0026#34;settings\u0026#34; : { \u0026#34;index\u0026#34; : { \u0026#34;analysis\u0026#34; : { \u0026#34;analyzer\u0026#34; : { \u0026#34;simple_jp\u0026#34; : { \u0026#34;filter\u0026#34; : [ \u0026#34;kuromoji_readingform\u0026#34; ], \u0026#34;type\u0026#34; : \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34; : \u0026#34;kuromoji_tokenizer\u0026#34; } } }, \u0026#34;number_of_shards\u0026#34; : \u0026#34;3\u0026#34; } }, \u0026#34;mappings\u0026#34; : { \u0026#34;properties\u0026#34; : { \u0026#34;hoge\u0026#34; : { \u0026#34;type\u0026#34; : \u0026#34;text\u0026#34;, \u0026#34;analyzer\u0026#34; : \u0026#34;simple_jp\u0026#34; } } }, \u0026#34;aliases\u0026#34; : { } }, \u0026#34;overlapping\u0026#34; : [ { \u0026#34;name\u0026#34; : \u0026#34;fuga\u0026#34;, \u0026#34;index_patterns\u0026#34; : [ \u0026#34;b*\u0026#34; ] }, { \u0026#34;name\u0026#34; : \u0026#34;2021\u0026#34;, \u0026#34;index_patterns\u0026#34; : [ \u0026#34;*_2021\u0026#34; ] } ] } 例で作成したblog_templateが適用されていますが、それ以外にindex_patternsに合致したがpriorityが低くて適用されなかったものがoverlappingに出力されています。 実際に適用されたテンプレートの名前も別途出力してくれるとわかりやすいかもしれないですね。 (*_2021というインデックスパターンのテンプレートを試しに作ってみたのですが、これはバグがありそうです。2021に合致するインデックス名をSimulateしたらoverlappingに合致しないものがたくさん出てきました。バグ報告しとくか)。\nKibana対応 ここまで、Index Template V2のAPIの説明でしたが、Kibanaでの対応についても調べてみました。\nIndex Management（Stack Management機能。Elasticライセンスが必要だが無償の機能） 7.9からKibanaのIndex管理画面でComposable Templateが利用できるようになっています（GitHub Issue）。 画面のスクショを一通り貼っておきます。残念ながら、それぞれのJSONの編集部分では補完などはサポートされていないようでした。 頑張って自分でsettingsやmappingsのJSONを記述していく感じになります。JSONとして正しいかどうかはチェックしてくれます。 Index Templateのウィザードでは、ボタンでコンポーネントを追加したり削除したり、順序を入れ替えたりといった作業が可能になっています。 また、プレビュー表示が可能なので、composed_ofで選択したものが今どのように適用されているか？といったのも確認できるようになっていました。 結構便利に管理できそうです。ちなみにスクショは7.10の画面になります。\nComponent Template周り 一覧表示とウィザード Index Template周り 一覧表示とウィザード Console(Dev Tools。OSSで利用可能) リクエストを実行は可能ですが、自動補完機能は一部のみ対応しているようです(GitHub Issue)。\n対応済みの機能\nDELETE _component_template (ただし、ここまで。存在するコンポーネント名は補完されない) 上記以外はまだ未対応のようです。 プルリクエストチャンスかも？\n参考 Composable Templates · Issue #53101 · elastic/elasticsearch What’s new in 7.8 | Elasticsearch Reference ［7.8］ | Elastic Index management | Elasticsearch Reference ［7.10］ | Elastic ［Composable template］ Create / Edit wizard by sebelga · Pull Request #70220 · elastic/kibana ［Console］ Support suggesting index templates v2 · Issue #75967 · elastic/kibana まとめ ちょっと長くなってしまいましたが、新しいIndex Templateについての紹介でした。 これまでと違い、複数のテンプレートが適用されない点があるのでそこは注意が必要そうです。 コンポーネントをうまく使えば、管理が簡易化はされそうですね。\n","date":1608216955,"dir":"post/2020/","id":"c6fc88bd57a0e57ddf22e2eb1bef892c","lang":"ja","lastmod":1608216955,"permalink":"https://blog.johtani.info/blog/2020/12/17/index_template_v2/","publishdate":"2020-12-17T23:55:55+09:00","summary":"Elastic stack (Elasticsearch) Advent Calendar 2020の18日目の記事になります。 本日の勉強会でLTをしましたが、しゃべり足りなかったんで。 Elasticsearch 7.8でこっそりとリリースされたI","tags":["elasticsearch"],"title":"Index Template V2"},{"contents":"はじめまして、pyspa。 ということで、pyspa Advent Calendar 2020の4日目(大谷コンビの2号)の投稿になります。 コンビそろってキーボード記事ですね。\n今年はDIYキーボードにはまった（はめられた？）年でした。 もともと分割キーボードには興味があり、自宅で作業するのが基本となったのもあり手を出した次第です。 まだまだ使いこなすところまでは来てないかもしれないですが、組み立てたり、問題点のキリ分けしたり、試行錯誤するのは楽しいなと。\n今回はCorne Chocolateというキーボードを組み立てたのでそちらのビルドログ（かつ今後のための教訓）になります。 LEDを使ったキーボードがどんなものなのか＋薄いキーボードも気になるなということで取り組んでみました。 今回もいくつか失敗をしつつ、リカバリーして動くものができました。\nパーツ（材料） 基本のパーツは今回もKochi Keyboardさんから購入しました。\nキット : Corne Chocolate（ベースキット） キースイッチ : Kailh Choc v1 Blue (25gf リニア) 5個 キーキャップ : Kailhロープロ刻印キーキャップ ケーブル類は家に転がっていたケーブルを利用しました。 キースイッチセットもあるのですが、軽いキータッチが好みなので、一番軽いKailh ChocのBlueを試してみたくキースイッチを個別に選択しました。 キーキャップはShiroを作るときに調達していたものを利用した形です。\n今回も公式のビルドガイドにざっと目を通してから着手しました。\n準備 ビルドログにもあるようにPCBがリバーシルブなので、作業中に迷子にならないようにこんな感じで表にマスキングテープで目印をつけておきました。\n今回から耐熱ワーキングマットで作業をすることにしました。机の天板に傷つくの嫌だし。 気兼ねなくはんだできるのでおすすめです。\nhttps://t.co/0qntPD8qIa\n2ヶ月ぐらいにここで買いました！\n\u0026mdash; 西田和史(k.bigwheel) 開発基盤EM (@k_bigwheel) November 11, 2020 ダイオード、OLEDソケット、コンスルー、TRRSソケット、 こちらは前回のCorneとほぼ同様だったのでビルドガイド通りに進めます（写真撮り損ねました。。。） 前回との違いはダイオードの形です。 表面実装するタイプのダイオードなので向きに気を付けつつ、つけていきます。\nビルドガイドに向きやダイオードのつけ方が紹介されています。 拡大鏡とピンセット必須ですね。 前回同様に、ここまででいったんqmk_toolsでファームウェアをインストールして、ピンセットを使いながらキーの認識とOLEDの動作確認を行いました。 今使っているファームウェアがあるのでそれを入れて問題ないかを確認しました。\nLED実装 今回のメインイベントです（そして苦杯をなめたイベントでもあります）。 ビルドガイドにも記載がありますが、信号が流れる順番があるようなので1番から取り付けていきます。 また、ビルドガイドにLEDに関する注意事項もいくつか掲載されています。必ず読みましょう。\nこの1～6までのLEDがすごく大変でした。。。\n表面実装のLED（Underglow LED）で四苦八苦 いくつかのブログを参考にしながら作業を進めました。\nコルネキーボードを作りました ～LED取り付けに四苦八苦記～ | キオクノロンダリング SK6812miniの仕様などについて書いてあります。デバッグするのにすごく役に立ちました。 Corne Chocolateビルドログ - nokの雑記 手書きでどんな感じでやればいいのかを解説してくれています。最終的にはこの方法が一番だったのかも？ 自作キーボードキット「Corne Cherry」のレビュー - 自作キーボード温泉街の歩き方 あとで出てきますが、リカバリ方法の参考になりました。 皆さん苦労されてますね、そして私も苦労しました。。。\n試してみた方法、考察は次の通りです。\nLEDチェック用のファームウェアをインストールして1つつけては動作確認 HelixのLEDテスト用ファームウェアをインストールしました。 白光 1C型こて先 失敗した後にリカバリするために購入しました。 LEDのランドなどが2Cよりも面積が小さいので、そのサイズに合わせたこて先のほうがよかったようです。 はんだの温度（温調できるはんだごて必須） 最初は250℃でやっていましたが、なかなかはんだが溶けません。そのせいで焦りも出てきます。 最終的には270度で作業しましたが、温度のせいでLEDが壊れたのはなかった気がします。1Cのこて先だったので無事だったのかもしれません。 フラックスなし あると楽だったのかも？残念ながら試してないです。 予備はんだ手法（だめっぽかった） 基盤のランド4か所に予備はんだをし、はんだを温めつつLEDを乗せる方法 LEDの裏にも予備はんだ どちらも試してみましたが、温めている個所以外のはんだと高さの違いが出てしまい、LEDが浮いてしまいます。4か所を同時に温めることはできないので、すこしずつ調整しているうちにLEDを物理的に壊してしまうことがありました。。。 ちょっとコツが分かったかも？ pic.twitter.com/ruwrmEWCAe\n\u0026mdash; Jun Ohtani (@johtani) November 19, 2020 わかった気になっていますが結局失敗しました。。。\n結局最後までこれというコツはわかってない気がします。結局3つか4つのLEDがお亡くなりになりました。 うまくいかなかった原因は、予備はんだで傾きなどができ、それを修正していくうちに基盤やLEDにダメージを与えてしまったのだと思います。\nよく見ると基盤が一部剥がれかけてるのがわかるかなぁと。\nリカバリー 右手側の表面実装の4番と5番が失敗しました。\n4番目（以下のツイート右側画像の上） こちらは、1度付けたLEDをはがすときにはんだを取り除くのが不十分な状態でLEDをはがしたために、基板のランドごとはがれてしまいました。 なのでここはLEDはつかないです。。。 5番目(以下のツイート右側画像の真ん中あたりの黄色い線がつながっているLED) LED自体はつけてありますが、青色しか発光しなくなっています。 4番目が完全に死んでしまったので、無事な3番目のLEDのDINに流れている信号を 5番目のLEDのDINにも流れるようにするために10芯コードでショートカットさせました。 （リカバリ方法は先ほど紹介したブログが非常に参考になりました、先人の知恵ありがたし）。 黒い線も売っていたのですが、自戒も込めて目立つ色にしてみました。\n勉強させていただきました、、、 pic.twitter.com/Zp16fJKziM\n\u0026mdash; Jun Ohtani (@johtani) November 22, 2020 ちなみに、左側のショートカットのコードはつけた後に1か所LEDの向きが違うことに気づき必要なくなっています （上記の基盤が傷ついている画像をよく見ると上下が逆になってるのがわかる人にはわかるかも）。\n片方は導線なくて良くなった。表から見たら向きが違うのに気がついたわ、、、 pic.twitter.com/7TSDMPPxlX\n\u0026mdash; Jun Ohtani (@johtani) November 22, 2020 最終的に2か所おかしいLEDにはなりましたが、幸いにもアンダーグローです。 Kochi Keyboardさんで購入したキットのボトムプレートはFR4なのでほぼ見えません！（負け惜しみ）\nソケット さて、気を取り直してソケットをつけていきます。 Dozen0にて経験済みなのでそれほど手間はかかりませんでした。 LEDの失敗の時に1Cのこて先を購入していたため、ソケットの横の隙間からこて先が差し込めたのが便利でした（LEDでダメージを受けていたのもあり写真撮り忘れ）。\n完成 ということで完成です。デフォルトで赤く光ってます。キーキャップがLEDを透過してくれるタイプだったのがこれまたよかったですね。 作る前は光らなくてもなんて思ってたのに。\nキーマップ(v2) Corne Lightで作業を数週間ほどして、いくつか入力しにくい部分があったのでマッピングを少しだけ変えました。 相変わらず日本語キーボードベースですが、数字のレイヤーにいくつかの記号を使えるように割り当てました。 コーディングをするときに、ライブラリのバージョン（例：7.10.0とか）やIPアドレスを入力していてレイヤー切り替えのためのキーを押したり話したりするのは効率が悪すぎたためです。 数字との組み合わせでよく使いそうな以下のキーを数字のレイヤーに移動しました。\nセミコロン（JP_SCLN） コロン（KC_QUOT） アンダースコア（JP_UNDS） コンマ（KC_COMM） ピリオド（KC_DOT） スラッシュ（KC_SLSH） #include \u0026#34;keymap_jp.h\u0026#34; const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = { [0] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_TAB, KC_Q, KC_W, KC_E, KC_R, KC_T, KC_Y, KC_U, KC_I, KC_O, KC_P, JP_MINS, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, KC_A, KC_S, KC_D, KC_F, KC_G, KC_H, KC_J, KC_K, KC_L, JP_SCLN, KC_QUOT, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, KC_Z, KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_COMM, KC_DOT, KC_SLSH, KC_RSFT, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, MO(1), KC_SPC, KC_ENT, MO(2), KC_RALT //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [1] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_ESC, KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0, KC_BSPC, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, KC_LEFT, KC_DOWN, KC_UP,KC_RIGHT, JP_SCLN, KC_QUOT, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, JP_UNDS, XXXXXXX, KC_COMM, KC_DOT, KC_SLSH, XXXXXXX, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, _______, KC_SPC, KC_ENT, MO(3), KC_RALT\\ //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [2] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_TAB, JP_EXLM, JP_DQUO, JP_HASH, JP_DLR, JP_PERC, JP_AMPR, JP_QUOT, JP_LPRN, JP_RPRN, JP_CIRC, KC_BSPC, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, JP_MINS, JP_EQL, JP_LBRC, JP_RBRC, JP_YEN, JP_AT, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, JP_UNDS, JP_PLUS, JP_LCBR, JP_RCBR, JP_PIPE, JP_TILD, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, MO(3), KC_SPC, KC_ENT, _______, KC_RALT //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [3] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. RESET, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| RGB_TOG, RGB_HUI, RGB_SAI, RGB_VAI, RGB_SPI, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| RGB_MOD, RGB_HUD, RGB_SAD, RGB_VAD, RGB_SPD, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, _______, KC_SPC, KC_ENT, _______, KC_RALT\\ //`--------------------------\u0026#39; `--------------------------\u0026#39; ) }; LEDの色が変えられる！（気づくの遅い） あと、キーマップを変更しているときに4つ目のレイヤーにRGBなどのボタンがあるのに気付いて押してみたら、LEDのパターンや色を変えることができるのに気付きました。 （遅すぎでは。。。）\nキーキャップが白いのもありこんな感じの色にしてみています。\nユニコーンガンダムっぽくなった pic.twitter.com/vHxZkMrYyP\n\u0026mdash; Jun Ohtani (@johtani) November 28, 2020 まとめ ということで、失敗も多々ありましたがキーボードとしてはちゃんと動くできたものができたので安心しました。 今後、状況が落ち着いてきて自宅以外で仕事をするときにはCorne ChocolateをPCと一緒に持ち歩くと思います。 薄くて邪魔にならなくてよさそうです。\n今回もはんだっしゅ太郎大活躍でした。本当に買ってよかった。 LEDがつかないときはちょっと落ち込みましたが、これのおかげで立ち直れたのもありますし。 あとは、試行錯誤しつつLEDとかの理解ができたのも楽しかったです。 キーマップの変更時にLEDの変更などができるのに気づいたのはちょっと遅すぎたので、qmkの仕組みや割り当てられるキーにどんなものがあるのかをもう少し研究したいなと思います。\nさて、次はどんなことを試すかなぁ。\n","date":1607004824,"dir":"post/2020/","id":"a46c601d03a3a26bc418d0096fe83a42","lang":"ja","lastmod":1607004824,"permalink":"https://blog.johtani.info/blog/2020/12/03/build_corne_choc/","publishdate":"2020-12-03T23:13:44+09:00","summary":"はじめまして、pyspa。 ということで、pyspa Advent Calendar 2020の4日目(大谷コンビの2号)の投稿になります。 コンビそろってキーボード記事です","tags":["DIYキーボード","misc"],"title":"Corne Chocolateを組み立てた #DIYキーボード"},{"contents":"前回のブログのまとめに書いたように、セパレートタイプのキーボードであるCorne Light v2を作成したのでそのビルドログです。DIYキーボードとしては2つ目になります。\nまとめで書いていたお店が開店したので、購入してみました。 購入したのはこちらのKOCHI KEYBOARDさんです。 ついこの間オープンしたばっかりのお店です！\nなんで作ったの？ スプリット型（セパレートタイプ？どっちが正しいんだろう？）のキーボードに興味があって、KOCHI KEYBOARDさんで買えたのがこれだったというのが大きな理由です。こういうのってタイミングだと思うので。 あとは、組み立てていくのがプラモデルみたいで面白いというのもあります。 基本的にここのところ自宅で仕事をしているので、ノートPCのキーボードにこだわる必要もないなというのも理由ですね。今後も当面は自宅で仕事になると思いますので。\nCorne Light v2 foostanさんが設計された（って言い方であってるのかな？）、3x6のサイズに親指の3キーが配置された分離型のキーボードの一種です。 シリーズ？の名前としてはCorne Keyboardと呼ばれています。 （そういえば、由来は何だろう？自作キーボードがどうやって設計されていくのかという流れがまとめられた作者の方のブログがおもしろいです。） また、基板の設計などがGitHub上でMITライセンスで公開されています。 オープンソースなハードウェアというのも面白いです。\nビルドログ 作者の方がビルドガイドを公開してくれています。ですので、こちらに沿って作業をしていきます。 ちなみに、私は今回Gateronのクリア軸を選択してみました。さらさらと入力できるのが好きなので。 サイレント軸にも興味はあるのですが、今回は実際にスプリット型のキーボードを早く触ってみたいというのが勝ちました。キーキャップについては後述します。 ツイートに都度、写真をアップしていたので組み立ては画像でお楽しみください（時々取り忘れてるけどｗ）。\nうむ pic.twitter.com/svW9WdzaZv\n\u0026mdash; Jun Ohtani (@johtani) October 21, 2020 刺して曲げる pic.twitter.com/M0jfQJg2k8\n\u0026mdash; Jun Ohtani (@johtani) October 22, 2020 両方できたと。ハンダまでやって今日はおしまいにすっか pic.twitter.com/HgsSrxqpcg\n\u0026mdash; Jun Ohtani (@johtani) October 22, 2020 写真取り忘れたけど、ProMicroつけた pic.twitter.com/RS4z0lqsUZ\n\u0026mdash; Jun Ohtani (@johtani) October 22, 2020 OLEDもついたと。今日はここまで pic.twitter.com/p6Z8MMP0Xz\n\u0026mdash; Jun Ohtani (@johtani) October 22, 2020 ここまでは順調です。\nOLEDがつかない？ ビルドガイドに従って、この後キースイッチをつけちゃうと問題の切り分けが難しくなるということで、 ここまでの段階でQMK Toolboxを使ってProMicroにファームウェアを書き込んで、それぞれのキーのソケットの取り付け部をピンセットでショートさせつつ、キーが入力されるかどうかを見ていきます。 QMK Toolboxについてはサリチル酸さんのブログがわかりやすいので参考にさせていただきました（わかりやすい記事をありがとうございます）。 で、ビルドガイドにあるように動いてるかを確認しようとしたのですが。。。\nさて、ファームウェア書き込んだけど、OLEDがつかないな。どっかつながってないのか？\n\u0026mdash; Jun Ohtani (@johtani) October 24, 2020 ビルドガイドのようにはいかず。。。 USBでPCとつないだ状態で、QMK Configuratorをサイトで開いて、キーボード入力テストを開くと、ショートさせたキーがPC側で認識されているかのテストができます。 これで、一通りキーは認識できていそうだというのはピンセットでショートさせながら確認しました。 ただ、OLEDには何も表示されないんです。。。\n前回Dozen0を組み立てた時に、ソケットのはんだ付けが甘かったというのもあったので、 OLEDやソケットのはんだを温めなおしたりしてみて、何度か確認してみたものの特に進展がなしです。 （ちなみにうまくいかないのもあって、ぼけたツイートしたりもしてます。）\nまぁ、OLEDはビルドガイドを見てもオプション扱いなので、それよりも触ってみたい衝動に駆られて、 キースイッチをはんだ付けしていきます。\nちなみに昨晩、OLEDはとりあえず置いといてって感じでキースイッチつけてた。キーキャップはまだない pic.twitter.com/SzLmzNg60Y\n\u0026mdash; Jun Ohtani (@johtani) October 26, 2020 それも終わって、問題点の切り分けに何かできないかな？と思ってやったのがOLED単体でArduinoと接続してみて動くかどうかです。 Qiitaにちょうどいい感じの記事を見つけたのでこれまた参考にさせていただきました(4本のジャンパー線を一人で持ちながら確認するの大変だったｗ)。\nはんだでの修正にしっぱい で、自分の中での結論として、「OLEDソケットのはんだ付けが怪しい」となりました。 そこで、まずは外してみようかと思ったのが間違いでした。 はんだごてとはんだ吸い取り線で何とか外せるだろうと思っちゃったんですよ。 OLEDピンソケットは足が4本あって、とりあえずとれるところまではんだ吸い取り線で吸い取ってみましたが、 さすがに基盤の穴に流れ込んだはんだまでは吸い取れず、頑張って温めながらソケットを抜こうとがんばって、 ラジオペンチでピンソケットを引っ張りながら引き抜きました。かろうじて引き抜きはできたのですが、ソケットは足が折れてしまいました。\n作者登場（OLED問題の解決） そんなところにCorneの作者の方がツイートを拾ってくれたみたいで以下のような返信を頂きました。\nOLEDが点かないのはファームのせいかもしれません(最近以前のファームで動かない新しいタイプのOLEDモジュールが出回るようになりました)。お手数ですが、https://t.co/vfSBfIeeJX のブランチのものを試して頂けますか？(ただいまPRレビュー中でまだマージされていない状態です)\n\u0026mdash; c7s (@foostan) October 25, 2020 暗闇に光明とはこのことです。 教えていただいたブランチを手元でビルドしてファームウェアを書き込むと、\nすごい、出ました！右側のディスプレイにロゴが。ありがとうございます（左側のOLEDはソケットのはんだ付け直し失敗したのでもうちょっと先になりますが）！\n\u0026mdash; Jun Ohtani (@johtani) October 26, 2020 なんと、ファームウェア書き込んだ瞬間にOLEDが点くじゃないですか。 感謝感激ってやつです。お礼を言うのに便乗してOLEDの問題の切り分けの方法についても聞いてしまいました。\nOLEDリベンジ 片側は無事だったのですが、もう一方は修復が困難になったので救世主を発注します。 自作キーボードの作成に便利なものリストとして、いくつかのブログに上がっていたのですが、必要ないだろうと見送っていたツールです。\nAmazon | サンハヤト はんだシュッ太郎NEO 45Wタイプ HSK-300 | ハンダゴテパーツ 本当にすごく使いやすかったです。 OLEDのピンソケットが修復不可能だったのですが、ProMicro用に付属して余っているピンヘッダがちょうどいい長さでした。 なので、これを4本分切り取り、OLEDモジュールにつけてしまったOLEDヘッダピンを抜き取って、代わりに切り取ったピンヘッダをつかって、OLEDと基盤を直接はんだ付けすれば修復できそうだと判断しました。\nはんだシュッ太郎君を使ってOLEDについてるヘッダピンをまずは除去。 そのあとはこんな感じで繋げました。\n見にくいかもだけど pic.twitter.com/YAHoxjgppN\n\u0026mdash; Jun Ohtani (@johtani) November 5, 2020 取り外しにくくはなったけど、無事両方のOLEDが点くのも確認できました。やったー。\nヤッター、両方のOLEDがついたよー pic.twitter.com/6KLDWvnaEC\n\u0026mdash; Jun Ohtani (@johtani) October 28, 2020 キースイッチがご機嫌斜め キーキャップは別途、AliExpressで発注をかけたのですが、ここまで来たら待ちきれないですよね？ ということで、手元にあった上海問屋のキーボードのキーキャップが同じMXキースイッチ用のものだったので移植しました。キーキャップ付けてみないとわかならいものですね、1つだけキースイッチがうまくはまっておらず、斜めについているのがこの時点で判明しました（ボトムプレート付けた後だったので、プレート外してから、はんだで修正）。\nちなみにキーキャップはめてる途中で、一箇所キースイッチが斜めにはんだ付けされちゃってるのを発見して慌てて直しました。 pic.twitter.com/qofHp3o4Pc\n\u0026mdash; Jun Ohtani (@johtani) October 30, 2020 無事使えるようになりました。\nアンスコが打てない＆Escどこ？ キーキャップ付けたので仮運用ということで、まずはデフォルトのキーマップをもとにどんな感じで入力できるのかを試してみました。 ここにも罠がｗ ブラウザでQMK Configuratorを開いてデフォルトのキーマップを確認しながら試し打ちをしていたのですが、どうも思ったのと違う動きをしているキーが。\nまずBASEレイヤー（レイヤー0）の右側のシフトと、LOWERレイヤーやRAISEレイヤーのEscです。 入力しているとどうも、右のシフトがEscで、レイヤーを切り替えてもTabのままだなと。 しょうがないので、OLEDが出なくてもいいのでQMK Toolboxでダウンロードしてきたものを利用したら想定通りなのにと。 きちんとqmk_firmwareの構成を理解しないままやってたつけでしたね。 結論としては、OLED用に教えてもらったブランチではキーマップが書き換わっていたようでした。 make crkbd:defautでビルドした時に利用されるkeymap.cがキーマップの定義が書いてあるファイルです。 qmk/qmk_firmwareのリポジトリにあるkeymap.cとfoostanさんにもらったブランチでは差分があったみたいでした。\nおかげで、qmk_firmwareのkeymap.cの仕組みがわかったし結果オーライです。 問題があって調べるとどんな作りになってるかとかちゃんと確認できますしね。 手順通りにやってるだけで問題が起きないと、どんな仕組みになってるのかがわからないので人に聞きまくるしかできなくなっちゃいますしね。\nこれでEsc問題は解決したのですが、アンスコがどうしても入力できません。 自作キーボード以外はすべて日本語配列のキーボードを使用しているのもあり、 日本語配列のキーボードだとどうもキーのマッピングが異なるようだと。\nググって参考にしたのはこの辺でした。\n【QMK】JPキーコードでキーマップを定義する - 天高工房 自作キーボードキット「Corne Cherry」のレビュー - 自作キーボード温泉街の歩き方 そのほかにもVIAのファームなども試したのですが、どれもうまくいかず。 色々ググってみて最終的な解決策はkeymap.cでkeymap_jp.hというファイルが読み込まれていないので、日本語用の設定とかを読み込んでみたつもりがうまく反映されていないという感じでした。\nJISにする場合、keymap_jp.hっていうヘッダファイル読み込んだほうがいいです\n\u0026mdash; Yoshi Yamaguchi (@ymotongpoo) November 3, 2020 今の時点ではこんなキーマップにしてあります。 今後も日本語配列のキーボードをベースに考えていくつもりです。\n#include QMK_KEYBOARD_H #include \u0026#34;keymap_jp.h\u0026#34; const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = { [0] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_TAB, KC_Q, KC_W, KC_E, KC_R, KC_T, KC_Y, KC_U, KC_I, KC_O, KC_P, JP_MINS, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, KC_A, KC_S, KC_D, KC_F, KC_G, KC_H, KC_J, KC_K, KC_L, JP_SCLN, KC_QUOT, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, KC_Z, KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_COMM, KC_DOT, KC_SLSH, KC_RSFT, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, MO(1), KC_SPC, KC_ENT, MO(2), KC_RALT //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [1] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_ESC, KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0, KC_BSPC, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, KC_LEFT, KC_DOWN, KC_UP,KC_RIGHT, XXXXXXX, XXXXXXX, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, _______, KC_SPC, KC_ENT, MO(3), KC_RALT\\ //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [2] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_TAB, JP_EXLM, JP_DQUO, JP_HASH, JP_DLR, JP_PERC, JP_AMPR, JP_QUOT, JP_LPRN, JP_RPRN, JP_CIRC, KC_BSPC, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, JP_MINS, JP_EQL, JP_LBRC, JP_RBRC, JP_YEN, JP_AT, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, JP_UNDS, JP_PLUS, JP_LCBR, JP_RCBR, JP_PIPE, JP_TILD, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, MO(3), KC_SPC, KC_ENT, _______, KC_RALT //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [3] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. RESET, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| RGB_TOG, RGB_HUI, RGB_SAI, RGB_VAI, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| RGB_MOD, RGB_HUD, RGB_SAD, RGB_VAD, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, _______, KC_SPC, KC_ENT, _______, KC_RALT\\ //`--------------------------\u0026#39; `--------------------------\u0026#39; ) }; キーキャップが待ちきれなくて この右下のトンガリがちょっと気になる pic.twitter.com/W0A0z67cns\n\u0026mdash; Jun Ohtani (@johtani) October 30, 2020 キーキャップが待ちきれなくて上海問屋のキーキャップを付けてみて、いろいろ試行錯誤してみました。\nあー。上下関係ないのか。だからみんなこんな感じにしてるのか？ pic.twitter.com/KTBlPLespr\n\u0026mdash; Jun Ohtani (@johtani) October 30, 2020 どのくらい離すのが良いか実験中 pic.twitter.com/ozK4WyBXY8\n\u0026mdash; Jun Ohtani (@johtani) November 2, 2020 キーキャップもいろいろあるのね 届いた。 pic.twitter.com/jccNW1ZcEM\n\u0026mdash; Jun Ohtani (@johtani) November 2, 2020 もう一個 pic.twitter.com/9y6qat4JiN\n\u0026mdash; Jun Ohtani (@johtani) November 2, 2020 とりあえずセミコロンの位置につけてみた。 pic.twitter.com/TDk5213IHi\n\u0026mdash; Jun Ohtani (@johtani) November 3, 2020 今はこのDSAプロファイルの青いグラデーションのキーキャップを使っています（Dukeはここにはいないですｗ）。 キーキャップのプロファイルはこれまた、サリチル酸さんのブログがわかりやすく書かれています（ほんとすごいなぁ。）。\n高さ調節 そのまま使っていたのですが、やはりもうちょっと奥側に高さがほしいなと。 ダイソーなどで打っているケーブルクリップがお試しには良さそうだったのでこんな感じで内側がちょっとだけ高くなるような感じにして使っています。\nこうなった。とりあえず仮運用 pic.twitter.com/VkhjawdhLM\n\u0026mdash; Jun Ohtani (@johtani) November 4, 2020 まとめ ということで、駆け足ですがCorne Light v2のビルドログでした。 いきなりフルキーボードから40％キーボードかつ異なる並びにしたので、 混乱しっぱなしですが、いい頭の運動になっているし、なにより作って動かすまでの間に いろいろと調べたり試行錯誤できたのがすごく楽しかったです。\nあとは、スプリット型＋Column Staggeredになったので「c」や「b」を間違えまくっていますが、 いい気付きでした。まだまだ記号とかの入力に慣れていないですが、ちょっとずつ身に着けていけたらなと。\nただ、もう次のキーボードをDIYしたい気持ちも出てきているので困っているところです。\n書ききれてないこともあるかと思うので、ここはどうしてるの？これはどうやったの？などあれば、Tweetなりコメントなりを頂けたらなと思います。いやぁ、DIYキーボード楽しいわ。\n","date":1604503527,"dir":"post/2020/","id":"b16bddd1a6d3e5f4136446bebe7ffbc7","lang":"ja","lastmod":1604503527,"permalink":"https://blog.johtani.info/blog/2020/11/05/build-corne-light-v2/","publishdate":"2020-11-05T00:25:27+09:00","summary":"前回のブログのまとめに書いたように、セパレートタイプのキーボードであるCorne Light v2を作成したのでそのビルドログです。DIYキーボードとし","tags":["DIYキーボード","misc"],"title":"Corne Light v2を作成した #DIYキーボード"},{"contents":"ヒゲが不評だったのでいつも通りの長さに切りました。\n前回「Windowsをお試し中」と書きましたが、いくつかソフトをインストールしたりしたので現状を忘れないようにブログに残しておきます（また同じ作業する予定なので）\nインストールしたものたち 今のところインストールしたのはこの辺。 特にコメントしたいものについてこのあと明記します。\nドライバインストール from CD MX Ergoのソフトインストール。接続はコネクター Windowsアップデート Chrome Visual Studio ビルドツール(Lindera用) JetBrains Toolbox IntelliJ CLion Rider Visual Studio Code Slack Teams Google Drive共有 Gitter Divvy for Windows Zoom DeepL Sophos Twitter for Windows Office 365 AutoHotKey WSL2 - Ubuntu Windows Terminal Rustup Git for Windows wsl-ssh-agent PeaZip Speccy Hugo (WSL2のUbuntuにapt-get install hugoした) PowerToys AutoHotKey 前回のブログに書いたように、カーソル系のEmacsショートカットが体に染みついて離れないのです。 そこで、ググって見つけた記事はこちら。 AutoHotKeyというツールが Windowsに常駐して、特定のキー入力の時に、別の操作を実行してくれるツールです。\n見つけた記事にあった、https://github.com/lintaro-jp/gtk-emacs-theme-like.ahkのキーマップをもとに、いくつか変更したものを使用させていただいています。\n書き換えたのは、以下の通りです。\nCtrl+\\でIMEの切り替え（Wnn風） Ctrl+kをEmacsと同じ挙動に（もとにしたキーマップでは、カーソルから行末までが削除されてしまう） Win+sでもファイル保存（Ctrl+sと同じ挙動に。デフォルトではCortanaが起動して邪魔くさいので） すごく快適です。そのうち、もう少し自分が使いやすいようにキーマップを追加していったりするかもしれません。 特に、Macのショートカットがしみついているものについてなどです（仮想デスクトップ切り替えとか？）\nPowerToys Divvyをインストールしたのですが、グローバルショートカットがうまく動かなくていまいちでした（なんでだろ？） そこでググって見つけたのが@ITのPowerToysの記事でした。 PowerToysはMS製のOSSツールで、GitHub上で公開されています。 中には「ColorPicker」、「FancyZones」、「File Explowrer Add-ons」など、複数のツールが入っています。 「FancyZones」です。\nWindowsでは、デフォルトで、アプリにフォーカスしているときにWin＋カーソルでウィンドウの配置場所をいくつか（左右どちらかに半分、4分の1(右上、左上など)）に配置してくれるAero Snapというものが動いています。が、上半分などデフォルトにない柔軟な配置を設定することができません。 MacではDivvyというツールをいれて、それを実施していたのですが、先ほど書いたようにWindows版はあるものの、なぜかグローバルショートカットが動かず、システムタスクトレイのアイコンをクリックしなければいけませんでした。\nそれを解消してくれるのがFancyZonesです。 FancyZonesの設定項目で、自分で画面上にどのような割り当て領域を作るかを設定できます。さらに、マルチディスプレイ、仮想デスクトップを使っている場合、それぞれのディスプレイかつ仮想デスクトップで個別にレイアウトが設定できるようになります。 レイアウトを設定した後は、Shiftキーを押しながらウィンドウを移動すると、設定した領域が出てきて、あとは、割り当てたい領域にウィンドウを移動するだけでその領域いっぱいにウィンドウをリサイズしてくれます。 また、設定を変えることで、Shiftキーを押さなくてもウィンドウ移動するだけで領域にリサイズすることも可能です。また、Aero Snapの機能をオーバーライドしてWin＋カーソルで動作させることも可能になります。\nWSL2 + Windows Terminal 三宅さんからコメントを頂いたので。\nもう少し幅広い感じですかね。あわせて Windows Terminal 使うとわりと快適です。\n\u0026mdash; miyake | ZEN (@kazuyukimiyake) October 15, 2020 なんとなく噂は聞いていましたがということで、MSのドキュメントを見ながらインストールしました。クイックスタートに則って作業するだけで特に問題なくUbuntuまで無事インストールできました。 Windows Terminalも同様です（クイックスタートで入れることになる）。\nGit for Windows + wsl-ssh-agent 少してこずったのがこちらです。 チュートリアルに記述はあったのですが、どちらで作業するのか？などが少しわかりにくかったので。ググって出てきた記事をもとに作用しました。\nRustのプロジェクトファイルをMacから丸ごとコピーしていたのですが、Git for Windowsを入れるまでは、CLion+Rust pluginの環境では、.gitファイルをきちんと認識してくれませんでした（この時WSL2と少し混同してた）。\n無事環境は用意できました。 作業の手順は以下のような感じです。 Macで使用していた.sshのディレクトリを持ってきて作業しました。\nWindows側での作業 Macから.sshディレクトリをc:\\\\Users\\johta\\にコピー Git for Windowsのインストール OpenSSHクライアントの設定 管理者権限でコマンドプロンプトを起動して sc config ssh-agent start=auto sc start ssh-agent [wsl-ssh-agent(https://github.com/rupor-github/wsl-ssh-agent)のインストール ダウンロードして.7zファイルを展開 wsl-ssh-agent-gui.exeとnpiperelay.exeをc:\\\\Users\\johta\\binに移動 c:\\\\Users\\johta\\bin\\wsl-ssh-agent-gui.exeのショートカットをスタートアップに作成 作成したスタートアップのリンク先に -setenv -envname=WSL_AUTH_SOCKを追加 Git BashでOpenSSHを利用するように設定 setx GIT_SSH C:\\\\Windows\\system32\\OpenSSH\\ssh.exe ssh-addで秘密鍵を登録 ssh-add .ssh/id_rsa WSL2のUbuntuでの作業 Ubuntuはgitがすでに入っていたのでインストールはスキップ git config --global user.name \u0026quot;Jun Ohtani\u0026quot; git config --global user.email \u0026quot;メールアドレス\u0026quot; mkdir .ssh .bashrcの最後行にwsl-ssh-agentのWSL2 compatibilityにあるexportからfiまでをコピー。この時、パスを自分のパスに変更すること(私の場合$HOME/winhome/.wslの部分を/mnt/c/Users/johta/binに書き換えました) これで、WSL2側では.sshのファイルを管理しなくても、Windows側のOpenSSHに接続してssh周りの処理をしてくれるようになりました。\nPeaZip wsl-ssh-agentが.7z形式で圧縮されていたので、ダウンロードしました。 とりあえずこれを入れてみたのですが、ほかにお勧めがあれば教えてほしいです。\nSpeccy CPUの温度やスレッドごとのCPU使用率などを見てみたいので入れてみました。 これもとりあえず入れてみた感じなので、ほかにお勧めのソフトがあれば教えてもらえればと。 リソースマネージャーでもスレッドごとのCPU使用率は見れたのですが、温度が見れなかったので。\nHugo + WSL2にあるUbuntuにsudo apt-get install hugoしてインストールしました。\nそこで、VS Code の Remote Extension です。WSL2 から ‘code’ で起動できます😎\n\u0026mdash; Daiyu Hatakeyama@Microsoft, Hack in ChatGPT (@dahatake) October 17, 2020 あとは、畠山さんに教えてもらったVSCodeのRemote - WSLを入れて、 WLSに接続した状態でVSCodeを起動して記事のMarkdownを書くと、VSCodeのターミナルを開くとWSL2に接続してくれて、hugoコマンドが実行できます。\nまとめ とりあえず、ブログが書ける環境ができました。 Mac上にあった各種プロジェクトのディレクトリをコピーして、Rustの開発もできるようになりました。\n今後も環境構築は続いていきます。Javaとか入ってないし。 SDKMan使ってたけど、切り替えどうしよう？とか。\nそういえばSDKMAN!をJDK切替に使ってたけど、結局windows側のパスは通らんので自力インストールになった。scoopがよさげ\n\u0026mdash; きしだൠ(K1S) (@kis) October 17, 2020 IDE系から呼び出すターミナルはWSL2がいいなぁとか。\nhttps://t.co/X4Jj4tih1I\n\u0026mdash; そーだい@初代ALF (@soudai1025) October 17, 2020 ほかにもおすすめなどがあれば教えてください！\n","date":1603029710,"dir":"post/2020/","id":"188c1ee5132a6752dfce5a0235354070","lang":"ja","lastmod":1603029710,"permalink":"https://blog.johtani.info/blog/2020/10/18/restart-windows-no1/","publishdate":"2020-10-18T23:01:50+09:00","summary":"ヒゲが不評だったのでいつも通りの長さに切りました。 前回「Windowsをお試し中」と書きましたが、いくつかソフトをインストールしたりしたので","tags":["misc","windows"],"title":"Windowsへの移行（その１）"},{"contents":"ヒゲが伸びてきて(試しに伸ばしてる)不評を買っている今日このごろです。\n自宅で作業することが多くなってきたので、自作PCでもと思っていますが、OSをどうしようか悩み中。 とりあえず、試しにWindowsにしてみるかということで、10年ぶりくらいにWindowsに帰ってきました (この文章はMacで入力してますが)。\nむかしむかし もともとはWindowsを使っていたのですが、Win7くらいに32bitと64bit混在の時期に、 Xkeymacsを利用するときに少し手間がかかるなぁと思ったのもあり、Macに移行しました。 Macだと自分がよく使うEmacsっぽいショートカットがデフォルトいろんなアプリで使用できる利点があったからです。\nただ、最近、TL上で光るPCとかを見てしまったのもあり、 自作PC(どちらかというとDIYかな?)熱が復活しました。 まだ、OSをWindows、Ubuntuのどちらをメインにしようかな?と悩んでいるところではありますが、まずはWndowsをちょっと試してみるかなと。\nまずは、やりたいことをちょっとリストアップしておこうかなと思います(きっと、先人の知見が集まってくるはず!)。\nどうしてもほしい機能 大学の頃にSunOSやSolarisを使用し、Emacsでメールを読んだしていたせいで、Emacsのショートカット操作が体から抜けない状態です(抜こうとしてないという話もあるが)。 ですので、社会人になってからWindowsを利用していたときはXkeymacsというソフトのお世話になっていました(神アプリでした。まだあるのかな?)。\nショートカット操作とか カーソル移動(必須) 上下左右：Ctrl+n、p、f、b 行頭、行末：Ctrl+a、e 編集 デリートキー：Ctrl+d Ctrl+hがバックスペースだけど使わないな、そういえば カーソルから行末までをカット：Ctrl+k 必須! カーソル移動がホームポジションから移動しなくてもいいのもあって、多用してしまっています。 これ、WindowsとかUbuntuでいい感じにできるのあるのかな? できれば、IMEやブラウザのURLのサジェストなどもこのカーソル移動で移動できると嬉しいです。 (昔はM-%とかで置換などもやってたけど最近はやらないな。)\nデスクトップ操作系 仮想デスクトップ やることごとにデスクトップを切り替えて使うので ウィンドウのリサイズ? DivvyというアプリをmacOSで利用中 自分で登録したサイズ(例：画面右半分)にウィンドウサイズを変更などがショートカットで可能 仮想デスクトップはあると思うけど、ウィンドウのリサイズの便利なツールあるかなぁ?\n利用するアプリ SNS、オンラインミーティング Twitter macOSではTweetDeckと夜フクロウを使用 Slack ネイティブアプリ Gitter ネイティブアプリ Chatwork ブラウザ Teams ネイティブアプリ Zoom ネイティブアプリ Google Meet ブラウザ Discord ネイティブアプリ(最近使ってないな) 色々使ってますが、最悪ブラウザで使う感じかな?\nオンラインストレージ Google Drive 同期アプリ使ってる Dropbox あんまり使ってない 開発系 JetBrainsのIDE Toolbox App IntelliJ CLion + Rust plugin Rider zsh macOSで標準になったから コマンド系 git SDKman ant gradle JDK Rust Hugo Jasper GitHubのIssueとかを見るネイティブアプリ 自分が関連しているIssueとかが楽に見える(メールだと埋もれてしまう) エディタ Visual Studio Code 開発系では?と思われるかもだけど、Markdownエディタとして使ってる Emacs by Homebrew 最近は起動してない その他 カレンダー macOSのカレンダーで複数のGoogleカレンダーを取り込んでる ScanSnap Ubuntuで使えるやつあるのかな? Mac miniにつないであるので、画面共有とかで入れればそれでOK 画面共有 winやubuntuからMac miniとか見えるかな? キーボード共有 macも使うので、KVMスイッチとかかな? マウス共有 MX ErgoのFlowを使うと行き来が簡単にできたので良さそう。 ただし、Ubuntuだとどうなるのか? システム監視系 CPUの温度とかCPU、メモリの使用率とか まとめ とりあえずこんなところです。カーソル移動系が一番重要なので、そのへんから色々とちょっとずつ試していく予定。 ぜひオススメアプリとかあれば教えていただければと。\n","date":1602727442,"dir":"post/2020/","id":"de37d9fae011687eb1eb5a127fcb89e3","lang":"ja","lastmod":1602727442,"permalink":"https://blog.johtani.info/blog/2020/10/15/restart-windows/","publishdate":"2020-10-15T11:04:02+09:00","summary":"ヒゲが伸びてきて(試しに伸ばしてる)不評を買っている今日このごろです。 自宅で作業することが多くなってきたので、自作PCでもと思っていますが、","tags":["misc","windows"],"title":"Windowsをお試し中"},{"contents":"今年の春くらいから、セパレートタイプのキーボードが気になっています。 また、なんか知らないですが、Twitterのタイムラインが自作キーボード(DIYキーボード)で盛り上がってる気がします。 (たぶん、気になってるから余計目についてる)。 これとか。このスライドから、自分がやってるのは「まだ」DIYキーボードだなということで、タイトルに使ってみました。\n#toruby \u0026quot;DIYキーボードは実質Ruby\u0026quot; 本日のスライドです! とちぎでこの話をできてよかった!!!q: https://t.co/RJot71Ngu9\n\u0026mdash; Kakutani Shintaro (@kakutani) September 12, 2020 セパレートタイプのキーボード 今年の夏まではMac Book Pro 16インチのキーボードを利用していました(参考:自宅の作業環境(2020))。 これまで、自宅で作業することよりも、外で仕事をすることが多く、また、外といっても様々な場所(サムライズムだったり、オフィスだったり、カフェだったり)で作業をすることが多かったので、ノートPCのキーボードにしていました。流石にキーボードを持って歩くほどは気にしていなかったので。\nただ、コロナウイルスの影響もあり、ほぼ自宅で作業することとなりました。 となると、前から気になっていたセパレートタイプのキーボードが俄然気になり始めます。 (といいつつ、寄り道してたりしますが)\n気になっていたのはこのあたりなのですが、\nErgodox EZ Moonlander Mark I 流石にいきなり行くにはちょっと気が引けるなぁと(なかなかいいお値段)。 また、自分が日本語キーボードを利用しているというのもちょっとあります。\nキースイッチの感触を知りたくて ただ、日々、楽しそうな自作キーボードの記事や画像が流れてきます。 で、思い出したのが自分の趣味。プラモデルです。色を塗ったりはしないですが、組み立てるのは楽しいなと。 じゃあ、趣味と実益を兼ねればいいのでは?(ほんとか?)となり、作る気になってきました。\nただ、全く知らない世界だし、どんなものなんだろう?と。 市販のキーボードでも、キーの押し具合が色々合ったり、形もまちまちです。 また、このご時世ですので、自宅からあまり出ていないので遊舎工房さんなどに遊びにも行けず。\nそんなところに流れてきたのがキースイッチのテスターでした(世の中誘惑だらけ)。\nスイッチテスター人気スイッチ詰め合わせ 18個セット 「なるほど、これでどんな感触かわかるじゃないか!」と、気づけばポチッと押していました。。。 届いて、「ふむふむ、これがこういう感触なのか。なるほど」ポチポチ押しながら、さらに自作キーボードについて調べていきます。\nいろんな感触なんだなぁ pic.twitter.com/PaGDMIRJiv\n\u0026mdash; Jun Ohtani (@johtani) September 22, 2020 キースイッチのストロークの深さを知りたくて まぁ、当たり前なのですが、先程のキースイッチテスターどこにもつながっていません。 キーボード触ってるとわかりますが、ストロークが違いがあるんですよ。 ただ、これだとわからない。けど知りたい。\nで、ググっているとArduinoを使ってLチカやってる人とか、キー入力させている人がいるじゃないですか。 これでは?そういえば、Arduinoもどきうちにもあるぞ?と。 で、準備をしていたときに見かけてしまったのがこのツイートでした。。。\nhttps://t.co/ALl7OcRVRa 高機能テスターとしてもおすすめ\n\u0026mdash; Kakutani Shintaro (@kakutani) October 4, 2020 やられてしまいました。。。\ndozen0作りました ということで、前置き長かったですが、Dozen0というキーボード(マクロパッド?)を遊舎工房さんから購入して作ってみました。 手順はビルドガイドという形でまとまっています。\n基本的にはこれに沿って作成しました。\nパーツと手順の確認 さてと。 pic.twitter.com/GTBJ7zDleN\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 まずは入っているパーツがきちんとあるか確認します。 また、ビルドガイドでどんな作業があるのかをざっと眺めておきます。 まぁ、プラモデルといっしょですよね。\nキットにはキースイッチとキーキャップは含まれていません。これはご注意ください。 私は、キースイッチテスターとして入手していたキースイッチとキーキャップがどんな押し具合なのかを確認したかったので特に問題ありません。\nハンダづけ Amazon | 白光 ダイヤル式温度制御はんだこて FX600 | ハンダゴテ Amazon | 白光 こて先 2C型 T18-C2 | ハンダゴテパーツ Amazon | 白光(HAKKO) セラミックヒーターはんだこて専用こて台 クリーニングスポンジ付き FH300-81 | ハンダゴテパーツ Amazon | goot(グット) 高密度集積基板用 鉛入りはんだ Φ0.6mm スズ60%/鉛40% ヤニ入り SD-60 | ハンダゴテ はんだ付け用に揃えた道具です。「自作キーボード ハンダゴテ」とかでググると出てきたものがこれだったので。 デフォルトのコテ先ではなく、2Cのコテ先に付け替えてから作業を開始しました。\n私の持っていたソケットはCherry MX系なのですが、気が向いたらKailh Chocも試したくなるかも?ということで、 すべてはんだ付けしました。本格的にはんだ付けしたのは大学以来だからもう20年近く経ってますね。 ソケットの足をプリント基板にはんだ付けするのですが、2Cのコテ先が大きくなかなか手こずりました(これがこのあと問題を引き起こしました)。\nソケット、リセットスイッチ、ProMicroをはんだ付けすればはんだの作業は終了です。\npic.twitter.com/jjUo162n54\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 pic.twitter.com/p5atvtHfFN\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 スイッチの取付と組みたて 試したいキースイッチを選んでトッププレートにつけていきます。\nキーテスターからスイッチとキーキャップ持ってきて完成。動作確認はまだなのでまた、最初に戻るかもだけど、、、 pic.twitter.com/ZmBd3bgOKI\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 組み立ても終わり次は実際の動作確認です(ツイートしていますが、予想通りの展開でした)。\nファームウェアの書き込み USBで接続して、ファームウェアの書き込みです。 書き込み手順はビルドガイドにありますが、QMK Toolboxの使い方やQMK Configuratorの使い方は以下のサリチル酸さんのブログがわかりやすかったです。\n（初心者編）自作キーボードにファームウェアを書き込む （初心者編）QMK Configuratorを使ってキーマップを書き換えよう 実際に書き込んで動かしてみると。。。。\nうーん、上半分が死んでる気がするなぁ。\nデフォルトキーマップの書き込みはできたけど、カーソルの上とかバックスペースが入らないw\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 とりあえず、もう一回確認してみた。デフォルトのキーマップで、「Cut」「Paste」が強く押さないと入力されない。UpとDeleteは動くようになってた。CopyとBkSpがうんともすんとも言わない。下段のキーは全部動く。https://t.co/zEyINdAK6t\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 といった具合に上半分が動作があやしいです。\n再度、はんだ付け ということで、ネジを外して上の段のソケットをはんだで温めてみると、片側だけ温めるとはずれるじゃないですか。 どうやら、うまくソケットの足が基盤にはんだ付けできていなかったようです。 この時、最初に作業したときに2C型のコテ先が大きくて、ソケットの足に入らなかったのを思い出したので、 最初にはんだごてについていたコテ先に戻してから作業をしました。 これだとソケットの足の隙間に入るんです。ということで、挙動のおかしい上段のソケットをすべてつけ直したところ無事動作しました。\n上の段、全体的にソケットがうまくはんだ付けできてなかったみたいだった。今回はMX系のスイッチしかないので、Kailh Chocのソケットの導通は未確認。ざっとブログにまとめるか。\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 現在のキーマップ これが今のキーマップです。仕事中のBGMをラズパイ4の音楽プレーヤーで流していますが、 部屋から出るときや、打ち合わせがあるときに音楽の停止、開始などを画面共有経由でやっています。 が、わざわざマウス移動するのもめんどくさいなと。これに使えそうだというのもあったので、Dozen0を購入したというのがあります。 残念ながら、Prev Trackとかがうまく動かないので、ショートカットを調べてキーマップ書き換える予定ですが、非常に便利になりました。\nまとめ ということで、Dozen0を作ってみましたが、楽しかったです。すんなりと行かなかったのがまた良かったです。 試行錯誤して動いたときの喜びが何倍もありました。また、キースイッチの感触も知ることができました。 たぶんGateron Silentクリア軸もしくは赤軸くらいが良さそうだなぁと(こうやって沼へ。。。)。 キーマップの仕組みを調べたり、もっと面白い使い方できないかな?と探りつつ、次のステップに進もうかなと。\n次は本格的なセパレートタイプのキーボードを作る予定です。が、お店のオープンを待ってからということになってます。はやくオープンしないかなぁ!!\nがんばって!!\n\u0026mdash; Jun Ohtani (@johtani) September 29, 2020 ","date":1602428006,"dir":"post/2020/","id":"c377351433a941a927aab543931f6026","lang":"ja","lastmod":1602428006,"permalink":"https://blog.johtani.info/blog/2020/10/11/build-dozen0/","publishdate":"2020-10-11T23:53:26+09:00","summary":"今年の春くらいから、セパレートタイプのキーボードが気になっています。 また、なんか知らないですが、Twitterのタイムラインが自作キーボード","tags":["DIYキーボード","misc"],"title":"Dozen0を作成した #DIYキーボード"},{"contents":" 2020/10/06 11:00くらいにマージされました。\n@minoru_osuka さんが開発を引き継いだLinderaというKuromojiのRustクローンがあります(リポジトリ) 。 最近趣味でRustを勉強しているので、こちらを少し手伝っています。\nRustの勉強仲間である@takuya_bさんや@ikawahaさんと話をしているときに、FST部分をDouble Array Trieに置き換えると速度が向上するのでは?という話が出まして、@takuya_bさんがDouble Array Trieを作るらしいという話になったので、下準備などをしつつ、作ってもらったライブラリyadaを組み込んでみたという話です。\nベンチマークの追加 下準備として、今のLindera(FST実装)がどのくらいの性能なのか?というのを計っておく必要があります。 幸いにも、Linderaのオリジナルの開発者の方が、criterion.rsというライブラリを使ったベンチマークプログラムを作成してくれていました。\nただ、1種類だけだと少し心もとないなというのと、長い文章やパターンを増やしたほうが良さそうだなということで、 ベンチマーク自体をいくつか追加しました(追加したときのPR)。\n種類としては、5種類のベンチマークです。\nシステム辞書のみのTokenizerのコンストラクタ呼び出し カスタム辞書ありのTokenizerのコンストラクタ呼び出し システム辞書のみのTokenizerのtokenize処理の呼び出し カスタム辞書ありのTokenizerのtokenize処理の呼び出し 青空文庫の坊っちゃんのテキストをシステム辞書のみのTokenizerでtokenize 1,2はコンストラクタ部分だけの処理をベンチマークテストする目的で作成しました。 LinderaはTokenizerがtokenize処理するのに利用するデータをいくつか内部で保持しています。 これらはファイルにシリアライズされており、Tokenizerのオブジェクト生成時に読み込みやデシリアライズ処理が発生します。 この部分だけも速度を計測したい目的でコンストラクタだけを切り出しました。\n3,4はTokenizerのメインの処理です。コンストラクタはベンチマークの対象外にしました。 純粋にtokenizeの処理だけを切り出して計測するためです。 カスタム辞書がある場合、ない場合は念の為切り出した形になっています。\n5は長い文章(文章が多いのでバリエーションも増える)を扱いたいために別にしました。\nこれで、一応下準備が完了です。 ちなみに、Criterionは賢くて、前のベンチマークの結果と最新の結果を比較してくれる機能があります。 どんな感じで出てくるかはベンチマーク結果をご覧ください。\nyadaの組み込み ベンチマークの準備をしていたところyadaがリリースされたので、Linderaへの組み込みを検討し始めました。\nというわけで、またダブル配列を書いてしまったので crate として公開しました。フィードバックお待ちしております！ https://t.co/As7h0tfmjf\n\u0026mdash; takuya-a (@takuya_b) September 20, 2020 中身の理解 lindera-fstを利用して、prefix searchしている処理があるので、そこで利用しているFSTをyadaに置き換えれば良さそうだと判断して、 処理を読んでいきます。\nTokenizerは、PrefixDictという構造体でlindera-fstを利用している prefixメソッドが入力文字列を元に、FSTを前方一致検索して、ヒットした単語の情報をIteratorとして取り出せる(単語の情報は「入力文字列の先頭からの文字数」と「ヒットした単語のWordEntry構造体」) PrefixDictのfstは辞書(例：ipadic)ごとにlindera-\u0026lt;辞書名\u0026gt;-builderで生成される システム辞書としては、デフォルトではlindera-ipadic-builderでfstを構築している 構築処理はこの辺 という感じです。 また、辞書周りのファイルがそれぞれどんな役割なのか、どんなデータの持ち方をしているのか?といった点を、変更点の調査のついでに書き出してみました。lindera-dictionary/FILES.md。TODOになっている部分も追記が終わっています(PR)\n変更点 実際に変更したプログラムの詳細についてはのPRを見ていただくとして、簡単には以下の点になります。\nRustのバージョンを1.46.0に(おもにREADME.md) yadaが利用している機能に1.46.0で導入された機能があるため lindera-fstをyadaに変更(lindera-core/Cargo.toml, lindera-ipadic-builder/Cargo.toml) 合わせて、dict.fstというファイル名をdict.daに変更 dict.daに関して構築部分と検索部分を変更 FSTではFSTから返ってくる値(入力文字列に出てきた単語に関連する値)はu64だったが、yadaのDoubleArrayがu32しか扱えないため、u32に変更。テストの記述はしていないが、扱うデータ的にu32で問題なさそうだったので。 検索部分：PrefixDict構造体のprefixメソッドでDoubleArrayのprefix_common_searchを使用 DoubleArray自体がprefix_common_searchのメソッドを持っていたので、処理が簡単に置き換え可能だった。FSTはprefixメソッド内で独自で前方一致検索を実装していた。 構築部分：lindera-ipadic-builder/src/lib.rsのbuild_dictとbuild_user_dictのdict.da構築処理 ipadicのCSVファイルを読み込んで、見出し語をキーに、辞書にある単語情報のベクタを値とするBTreeMapを生成し、このBTreeMapに基づいてFSTを構築していた部分をDoubleArray構築処理に置き換えた。 シフト演算などで、実際の値(dict.vals)へのポインタを作っていたのだが、ここの処理を読み解くためにFILES.mdを書き出した。 という感じです。そもそもデータ構造がどうなっているのか?から読み解いて、変更部分を洗い出して変更していった形になります。 取り込み作業中にいくつかyadaに要望(このへん)を上げて、変更を取り込んでもらい、最終的にyadaのバージョン0.3.2で問題なく動きそうだという形になりました。@takuya_bさん、対応ありがとうございました。\nエッジケースバグの発見 作っててよかった、テストケースでした(実際にはベンチマークテストですが)。 取り込み作業中に、Lindera本体のcargo testはすべてOKになるが、ベンチマークを取ろうとしたときに、坊っちゃんの文字列を入力にしたベンチマークが失敗するという事象が発生しました(PRのコメント参照)。 切り分けのために、入力の文章のどこでおかしくなるのか?DoubleArrayのbuildメソッドに渡している値がおかしくないか?などをすこしずつ調べていくと次のバグが判明したという感じです。\n特定のデータ(ipadicの見出し語一覧)をDoubleArrayに入れて、特定の文字列(「は相」)をcommon_prefix_searchにいれたら、 返ってくる情報(0から何バイト目の文字が一覧に存在した)が、不正な値が返ってくるというバグでした。 @takuya_bさんに見てもらいつつ(DoubleArrayの中身わからん。。。)、修正してもらいました。素早い対応ありがとうございます。\nyada 0.3.1 をリリースしています。特定の条件で不正な遷移を許すダブル配列が構築されてしまうバグを修正しています。このエッジケースは @johtani さんが見つけてくださいました。ありがとうございました！ https://t.co/CiftZi5GDn\n\u0026mdash; takuya-a (@takuya_b) September 30, 2020 やはり、いろんな文字列入れてテストしてみるの重要ですね。 ということで、ベンチマークだけでなく、テストケースとしても坊っちゃんのファイルを読み込んでトークナイズするようにPRでテストケースを追加しています。\nベンチマーク結果 yadaを利用した変更が終わったので、再度cargo benchを実行して計測です。 計測としては、masterブランチでまずcargo benchを実行し、yadaの実装をしたブランチに切り替えてからcargo benchを実行します。 すると、Criterion? cargo benchが、最終的な結果に前回との差分でどのくらい性能が改善、改悪したかも合わせて出力してくれます。 実行環境と結果は以下のとおりです。\nMacBook Pro 16インチ CPU：Core i7 6コア 2.6GHz メモリ：32GB コンストラクタのベンチマークについては10%ほど性能が悪くなっています。 これは、FSTよりもDoubleArrayTrieのほうがデータが大きくなってしまうためだと思われます。 実際にファイルのサイズは次のようになりました。yada(DoubleArrayTrie)のほうが2倍以上大きいことがわかります。 また、このファイル以外にもLinderaが利用しているデータはありますが、それらは今回変更の対象にはなっていません。 なので、単純にこのファイルの読み込みの処理に時間がかかっているのだと想像できます。\n2147765 / FST / dict.fst 5425152 / yada / dict.da tokenizeのベンチマークについては、11%〜28%の改善が見られました。 文章から、内部に保持している辞書に存在する単語を見つけ出す処理に利用されるのがFST、DoubleArrayTrieです。 今回の変更では、この処理に利用しているデータ構造だけを変更しました。 実際には\nDoubleArrayTrieを用いた単語の検索処理 見つかった単語の持つ値(data.valsのオフセット情報)を元にシフト演算 といった処理が実行されます。シフト演算はu64だったものがu32に変更されたくらいなので、大した処理量ではないかと。 大部分はDoubleArrayTrieを利用したルックアップ処理が速度向上に寄与していると思います。\nまとめ 最近Linderaに加えた変更、作ったPRについて少しブログにまとめてみました。 ちなみに、まだPRの段階でレビュー\u0026amp;リリース待ちという感じです。\n実際には作ってもらったライブラリを組み込んでみたというだけなのですが、速度が向上した結果が見れたのは面白いです。 また、基本的なデータ構造とかアルゴリズムの勉強にもなりました(2次元配列を1次元配列に押し込むとか)。このへんも今後も勉強していきたいです。\n組み込む際に色々と協力していただいた@takuya_bさん、@ikawahaさん、巻き込んでくれた@minoru_osukaさんに改めて感謝いたします。\nRustや形態素解析のプログラムの勉強を兼ねて、今後もなにか改善できる部分がないかなどを見ていこうと思っています。 Rustで形態素解析をしたいという人がどのくらいいるかはわかりませんが、おかしなところや疑問点などあればコメントください。\n","date":1601865378,"dir":"post/2020/","id":"15932a656f7acfac897d27766eadc9e2","lang":"ja","lastmod":1601865378,"permalink":"https://blog.johtani.info/blog/2020/10/05/switch-fst-2-da/","publishdate":"2020-10-05T11:36:18+09:00","summary":"2020/10/06 11:00くらいにマージされました。 @minoru_osuka さんが開発を引き継いだLinderaというKuromojiのRustクローンがあります(リポジトリ)","tags":["Rust","Lindera"],"title":"LinderaのFSTをDoubleArrayTrieに変更した話"},{"contents":"先日は「検索システムを構成するパーツ」ということで検索システムを構成しているパーツについて書いてみました。\n大体、検索がうまくヒットしないといった場合に、問題になるのがコンテンツ自体のデータもしくは、転置インデックスのキーワードだったりします。 そこで今回は、前回のパーツの「データソース・コンテンツ」周りについて少し書いてみようと思います。言葉の定義、それぞれがどんなことをやるのか、とりあえず導入したあとにコンテンツ周りでどんな改善ができるかなどを書いてみます。\n言葉の定義 コンテンツ 実際に検索させたいデータになります。 コンテンツにはWebページ、データベースのレコード(CMSで登録されたデータなど)、ファイルサーバーにある文書(PDF、Word、Excelなど)などになります。\nデータソース コンテンツのマスタデータが保存されている先です。 よくあるデータソースとしては以下のものが考えられます。\nWebサイト - 自社もしくはインターネットに存在しているWebサイトです。 ファイルサーバー - ローカルネットワーク上のファイルサーバーもありますが、最近ではGoogle DriveやDropboxといった外部のWebサービスもあります。 RDB - CMSや自社システムでのデータの保存先です。 クローラー コンテンツをデータソースから収集してくるプログラムのことです。 Webサイトやファイルサーバーからコンテンツを収集して検索エンジンに登録するところまでを担当します。 RDBにあるデータを検索エンジンに登録する場合はクローラーがデータを登録するというよりは、RDBにデータを登録するシステムが検索エンジンに登録する機能を持っていることが多いです。\nデータの収集と登録 収集 クローラーを使用した収集の場合は、サービスの特性とデータソースによって、どの程度の頻度でクロールするのか、クロール対象はどこまでか?といったものを決める必要が出てきます。 これらが決まれば収集ができるかと(他に権限とかもありますが。)。 収集コンテンツは、そのままでは利用しにくかったり、利用できないことがあるので、次はデータの変換を行います。\nデータ変換 コンテンツはそのままの形では検索エンジンには扱いにくいデータ形式である場合があります。\nWebページの場合 Webページの場合、コンテンツにはHTMLタグが入っていたり、JavaScriptなど検索対象にはしたくないデータなどが入っています。これらを除去して、検索させたいものを取り出す必要があります。 また、Titleタグなど、いくつかメタデータとして扱えるものがHTMLで規定されているので、これらを別の項目として取り出して個別に検索できるようにすると便利です。 HTMLをパースしてデータを抜き出す処理ができるライブラリなどがあるので活用します。\nファイル PDFファイルなど、ファイルの場合もメタデータと呼ばれるファイル自体が持っている情報が存在します。作成者、更新日時、ファイル名、パスなどです。 これらも検索時に有効な情報になります。 また、ファイルから文字列を抜き出す処理も必要になります。 それぞれデータフォーマットが異なりますので、そのフォーマットに合わせて文章データを抜き出す処理が必要です。OSSや製品がありますので、それらを利用して、ファイルから文章を抜き出します。\nRDB RDBのデータの場合、データが正規化されています。 検索エンジンでは、非正規化のデータを登録して検索することが基本となるため、まずは非正規化して取り出す必要が出てきます。\n例えば、ジャンルやカテゴリ、各種IDなどが実際のコンテンツのレコードに入っていると思いますが、これらをユーザーが入力したキーワードで検索したい場合などは、IDではなく表示名を取り出して、検索エンジンに登録する必要が出てきます。\nその他 データごとの変換処理について説明しました。 その他に、データのクリーニング処理などと言ったことも必要になってきます。例えば、HTMLのタイトルに必ずサイト名が入っているが、除去したいといった場合や、検索エンジン固有のデータの前処理などもあります。\n登録 最後は検索エンジンへの登録です。 最近の検索エンジンはJSON形式でデータを受け取る場合が多いので、JSONに変換することが多いです。 基本的には各種プログラミング言語のライブラリが用意されているのでこれらを利用するのが基本となります。\n検索したい項目、検索させたい方法などを洗い出し、必要なデータを作成して検索エンジンに登録します。 登録と書いていますが、更新、削除などもここでの対象となります。\nここまでの流れで、データソースからコンテンツを取得し、変換して、検索エンジンへの登録が終わりました。\n検索の改善 検索のログから分析して改善していくのが良いですが、ユーザーからの質問や意見などからも改善すべき点が見えてくると思います。 検索ログでは、次のようなものを元に、検索がうまく行かないものを見つけ出します。\n0件ヒット 0件クリック ヒットしていない検索ワードがある場合、コンテンツに問題がある場合があります。まずはこのあたりをとってみるのが良いかと。 そもそも、入力されたキーワードにマッチするコンテンツを扱っていないこともわかりますし、入力されたキーワードに似た単語を持ったコンテンツなども存在するはずです。 類義語の辞書を用意して、検索にヒットできるようにするといった分析と改善にも利用できます。\nあとは、検索エンジン側の話ですが、形態素解析器などを利用している場合に、意図した区切りになっていないために、うまくキーワードがヒットしないと言ったこともあります。\nコンテンツの理解 実はこれが一番だったりします。 どんなコンテンツを自分たちが扱っているのか?どんなデータがどういった項目でコンテンツに入っているのか?といったところから、 コンテンツのデータを元に検索にヒットさせる方法が改善できます。\nCMSなど人が入力したデータをコンテンツとして扱う場合、入力画面を改良することで、望んでいるデータを入れてもらえたり、不要なデータが入らなくなる可能性があります。 例えば、ECサイトなどで商品の説明文やタイトルにいろいろなキーワードが入っている場合などがあります。むりやりどんなキーワードでもヒットさせたいという入力者の意図もあるのですが、検索しているユーザーにはノイズになることも多いです。適切にカテゴリやジャンル、属性といった項目に分けることでおかしな入力データを減らすことも可能です。\nWebサイトなどをクローリングしたものの場合は、サイトごとに文章の特徴があったり、重複している部分などが合ったりする場合があります。 これらもコンテンツをよく調べることで、不要な情報を除去したりといったことが可能になります。\nまとめ 簡単ですが、検索のデータソースやコンテンツにまつわる話を紹介しました。 もちろんここでは紹介しきれていない項目がいっぱいあります。 また、具体例ではなく概略をざっくりと書いているのでわかりにくい場合もあるかもしれません。 すこしユースケースを絞り込んで書いたほうがわかりやすくなるのかも?\n次はUIとか書くかも?\n不明点とか疑問点、指摘事項などあればコメントしていただければと。 要望などもお待ちしております。\n","date":1600136614,"dir":"post/2020/","id":"b2c4cf0fb96d02d37f03668caaecbc57","lang":"ja","lastmod":1600136614,"permalink":"https://blog.johtani.info/blog/2020/09/15/improve-search-no3/","publishdate":"2020-09-15T11:23:34+09:00","summary":"先日は「検索システムを構成するパーツ」ということで検索システムを構成しているパーツについて書いてみました。 大体、検索がうまくヒットしないとい","tags":["検索"],"title":"検索対象のデータとデータソース(検索システムに関する妄想その3)"},{"contents":"自宅環境に少しアップデートがあったので更新版です。 お客さんのおかげで相変わらず自宅で作業させてもらってるのもあり、昨今のコロナウイルスの影響で出かけることもないので、自室の作業環境が更新されている感じです。 前回のブログはこちらです。 前回のまとめで触れていた2点について更新されています。\nまずは、現状のデスクの上の写真です。\n基本的には前回紹介したものと大きくは変わっていません(?)。 変わったものについて紹介していきます。\nデスク 先程の写真ではちょっとわかりにくいですが、スタンディングデスクになりました。\nタイマーついてるの便利 pic.twitter.com/E9engTIMnM\n\u0026mdash; Jun Ohtani (@johtani) April 30, 2020 Flexispotの天板と足の組み合わせにしました。 前のElectaの天板が明るめの色だったのもあって、メープルの天板です。 組み立てはちょっと大変でした。 足が重たいのと、天板にはネジ穴がなく電動ドライバーもないので、ネジ締めと机を起こすのがちょっと大変です。子供に手伝ってもらいながら組み立て設置をしました。 オンラインミーティングなどのときには基本、立って作業しています。 あとは、デフォルトのタイマー設定のままですが、45分ごとに立ったり座ったりを数回繰り返す感じです。\nAmazon | FLEXISPOT オフィスデスク用天板 スタンディングデスク120×60cm Amazon | FLEXISPOT スタンディングデスク 電動式 昇降デスク メモリー機能付き ブラック EN1B（天板別売り） スタンディングデスクマット フローリングに45分立ちっぱなしだと結構、足の裏がつかれるんですよ。なので、クッション性が高いフロアマットを立ってるときは利用しています。ちょっとめんどくさいのですが、椅子のときは壁に立て掛けて、立つときにマットを敷くようにして使っています。\nちなみに、ウレタン素材なので開封直後はすごい匂いでした。。。 数日は陰干しみたいなのが必要です、ご注意を。 ただ、これを利用してから膝やかかとが痛いことはなくなっています。\nAmazon | 疲労軽減マット スタンディングデスクマット 滑り止め加工 立ち仕事 耐水 耐油 耐菌 (ブラック, 75cm*50cm*2cm) ケーブルトレー スタンディングデスクだとケーブルをぶら下げた状態だと危なそうだなということで、ケーブルトレーも机の下に追加してあります。電源タップを配置して、ディスプレイなどの電源はこちらから取るようにして、ケーブルトレーからは電源タップとスタンディングデスクの電源コードを垂らすという感じです。実際にはLANケーブルも伸びてたりはしますが。。。 また、後で出てくるラズパイ+SSDも最近こちらに移設しました。 最初にチャコールグレーを発注したのですが、配送日が未定になったので、Lサイズのシルバーを発注するという慌てようでした。 結局、今は両方使っています。テーブルタップにラズパイと、結構乗せるものがあるんですよね。見えない場所だし、色が揃ってないのは気にならないかなと。\nAmazon | プラス Garage ワイヤーケーブルトレー Lサイズ 幅63.7cm シルバー Amazon | プラス Garage 配線ケーブルトレー 幅40cm チャコールグレー キーボード+パームレスト 10数年ぶりに外付けキーボードじゃないかな? 少なくともMacに移行してからは、ずっとMac bookのキーボードを使ってました(極稀にMac mini起動後とかにMagic Keyboard使うくらい)。 外出して仕事をすることが多かったのもあり、体をキーボードに合わせる感じでした。\nが、ずっと在宅で仕事をしていますし、ふるさと納税でRealforce(リンクは楽天)がということで、申し込んでみました。2週間ちょっとで到着。 箱が厳重でびっくりしました。\nAmazon | 東プレ REALFORCE SA for Mac ホワイト R2SA-JP3M-WH | Realforce まだ深いキーに慣れつつあると言った感じです。 付属の2mmのキースペーサーでAPCを2.2mmの設定で使用しています。最初は3mm+APC 1.5mmでやっていたのですが、流石にキーが敏感すぎてちょっとキーボードに手をおいたまま考え事をしているだけで「lllllllllll」のようになってしまったので現在の組み合わせに落ち着いています。\nあと、特殊な設定としてはスペースの横のeng/kanaキーを設定でキーロックして使えなくしました。どうも、ご入力の原因になっているようだったので。 日本語の入力切替は、昨日まではCtrl+Spaceを使用していましたが、このブログを書き始めてからCtrl+\\に変更しています。 むかーし、使っていたIME切り替えのショートカットです(知っている人は知っているやつ)。\nマウスは使用しておらず、キーボードの手前にトラックパッドをおいて使っています。パームレストの部分は、サムライズムさんのトラックパッドがきれいに入るmagicTrayPalmです。 Mac book Proと同じような感じでトラックパッドが使えるのがいいですね。 興味がある方は、侍割のリンクをたどってもらうと、初めてサムライズムさんで買い物をする方に限り割引がつくようになってるみたいです(なんと、私もなんか割引になる!)。\nディスプレイアーム 外付けキーボードになったのですが、Mac Book Proの画面も活用したく、さらに上下での配置がやはり目線の移動距離が少ないので気に入っていました。ただ、前回のブログで紹介したアームでは少し高さが足りず。。。 思案しながらAmazonを回遊していたら、同じ会社の新しいアームがあり、調べると高さが取れそうだということで付け替えました。 アーム2本ありますが、今のところ1本だけを使っています。 2本目のアームにカメラを乗せるのもあり?と思いながらまだ試していませんが。玉突き式に前に使っていたアームがサンダーボルトディスプレイ(縦置き)のアームになっています。前にサンダーボルトにつけていたアームは重量オーバーで悲鳴を上げていたので。。。\nAmazon | HUANUO 2画面 アーム デュアル ガススプリング式 スマホ充電器 寝室で利用していた斜めに立てかけるタイプのワイヤレス充電器を作業デスクに持ってきました。 実は部屋に時計がなく、Pixel 3 XLを使っているので、スマホの画面に常に表示されている時計を置き時計の代わりに使えそうだなと (スマホで写真を撮っているので上の画像ではスマホがありませんが)。 結構便利です。ちょっと時間を確認したいときに、メニューバーの時計では流石に小さすぎるのでw\nAmazon | Anker PowerWave 7.5 Stand, Qi ワイヤレス充電器 ミキサー 音声のミキサーです。Yamahaのスピーカーは入力が2系統あるのですが、入力したい音声は3系統あります(ラズパイ4、Mac mini、メインディスプレイ)。2入力を1系統にまとめるプラグを試しに買ってみて、Mac miniとラズパイをまとめてみたのですが、残念ながら切り替わるときに数分無音状態が続くという問題が発生しました。 USB給電できるタイプを購入しました。スライダーとかいらないなと思っていたのですが、電話やミーティング時にBGMの音を下げたりするのに地味に便利だったりします。 ただ、スライダーを動かそうとすると本体も動いてしまっていたので、本体裏に滑り止めを貼ってあります。\nAmazon | Maker hart Just Mixer ステレオ3入力音声ミキサー/電池とUSB電源可能 Webカメラ おっさんの顔がきれいに写っても仕方ないんですが、下からのアングルよりはいいかなぁということと、今後の勉強会で使えそうかな?ということで、購入してみました。 縦でも横でも使える便利なカメラです。また、あんまりないのですが、部屋の中などを写すときにカメラを持ち回せるの便利ですね。 ディスプレイの上に置いてしまうと高さがありすぎるということで、スピーカーの上に乗っけています。仮置きなのですが、このままになるんじゃないかな? 打ち合わせ中は画面共有してることが多いのでオンライン飲み会などで主に活躍してる気も。。。\nAmazon | ロジクール ウェブカメラ フルHD 1080P 60FPS StreamCam C980OW オフホワイト USB-C接続 Mac miniのSSD化 見えないところですが、Mac miniのHDDをSSDに差し替えました。 性能検証用のマシンとしてMac miniを利用し始めたのですが、 計測するたびに速度の差がありすぎるのでおかしいな?と。 よくよく考えてみると、このMac miniはFusion Driveだったんです。。。 開発などで使う分には大容量だし便利だったのですが、負荷計測に利用する場合は挙動をハンドリングできないので、弊害でしかないです。。。 ということで、頑張って差し替えました。想像以上の大手術でした。 「Mac mini HDD 交換」などでググると換装している方たちがいらっしゃいます。興味ある方はググってみてください。\nさて、復路 pic.twitter.com/SwndXPoKqn\n\u0026mdash; Jun Ohtani (@johtani) July 25, 2020 Amazon | シリコンパワー SSD 1TB SATA3 6Gb/s 2.5インチ ラズパイ4 Mac miniの負荷検証マシン化のため+Linuxを触りたかったというのもあり、ラズパイ4を追加しました。 Mac miniは主な使用用途が音楽再生だったのでラズパイ4で肩代わりできるだろう+その他の検証にもラズパイ4が使えそうだと。 現在はUbuntuをインストールして、画面共有で操作しています。\nAmazon | LABISTS Raspberry Pi 4 4B MicroSDHCカード64G まとめ かなり快適になりました。キーボードもうるさくないですし、熱くもありません。マイクのポップガードは意味がなさそうなので外しました。\nまだいくつか気になってるものもあるので、また更新するかもしれません。\n分離式キーボード - 胸を広げた状態でキーを打ったほうがいいのでは?という気がしています。ただ、最近はずっと日本語キーボードを使っているので選択肢が少ないんですよね。。。\nサンダーボルト?USB-C?ドック - MacBook Proのポートがすべて埋まっているし、もう少しケーブルを減らせると幸せになれそうなきが。。。\nモバイルディスプレイ - MacBook Proのディスプレイを使っているのですが、キーボードの上にかぶってるんですよね、結構。。。クラムシェルにしてiPadもしくはモバイルディスプレイに置き換えたほうがスッキリはしそうかなと。ただ、Touch IDが使えなくなったり、クラムシェル状態でMacBook Proの電源を入れられないというはなしなので、あまり意味がなさそうだなというのもあります。\n","date":1599531445,"dir":"post/2020/","id":"d08a3fdc040bbbdd81c9927ce296318c","lang":"ja","lastmod":1599531445,"permalink":"https://blog.johtani.info/blog/2020/09/08/update-working-facility/","publishdate":"2020-09-08T11:17:25+09:00","summary":"自宅環境に少しアップデートがあったので更新版です。 お客さんのおかげで相変わらず自宅で作業させてもらってるのもあり、昨今のコロナウイルスの影響","tags":["misc"],"title":"自宅の作業環境(2020/09)"},{"contents":"Rustで便利なクレートを見つけたので、紹介がてら、自分のメモのためにブログに残しておきます。\nそもそもの問題 Rustで処理を書いていて、なんかちょっと遅いな?どこの処理で時間がかかってるんだろう? ということがありませんか?ありますよね?\nというのを調べるために、最初に思いつくのは自分で計測する方法です。 流石にそれはなぁ、と思ったのでググって出てきた方法を最初は使っていました。\nRustで実行時間計測 3年前の記事ですが、とりあえず計測する分には問題なかったのでこちらの方が書いていたマクロを拝借していました。 が、ちょっと面倒なのが戻り値がある処理などのときに、このマクロを挟むのが結構めんどくさいなと。 また、処理の時間を測りたいのは基本的にはメソッドや関数単位であることが多いです。\nで、さらにググっていて見つけたのが、meteredでした。\nどんなもの? 計測したい部分に#[metric]のようなアノテーションを追加することで計測対象としてくれます。 あとは、計測したものを保存するレジストリという場所を指定するだけです。 処理が終わったタイミングなどで、そのレジストリの内容を出力することで、次の情報を計測することができます。\nHitCount : 実行された回数 ErrorCount : エラーを返した数(Resultを戻り値にしているメソッドが対象) InFlight : 処理中の回数かな? ResponseTime : レスポンスタイム(処理に何秒かかったか) Throughput : スループット(1秒あたり何回呼ばれたか) とりあえず試してみたのは、ResponseTimeとThroughputです。他のメトリクスはまた後日(機会があれば)。 また、metered::metric::Metricトレイトというものが用意されているようで、これを実装した独自のメトリクスも扱うことができるようです。\n使い方 使い方としては次のようになります。\n計測対象となるメソッドがある構造体に、メトリクスを保持するためのレジストリを用意 計測対象にしたい構造体のメソッドに#[measure]を追加(このとき、計測したいものも指定する。) あとは、実行したあとに構造体をダンプするとメトリクスが出力されます。\nレジストリの用意 #[derive(Default, Debug, Serialize)] pub struct NekoParser { metric_reg: NekoParserMetricRegistry, } NekoParserMetricRegistryという型はこのあとのimplのアノテーションで指定する名前になります。 実際にはこの型の構造体を自分で定義する必要はありません。 構造体のderiveでDefaultを指定します。構造体のインスタンス化のときにdefault()メソッドを呼び出して初期化したいためです(おそらくレジストリの初期化をやってくれるのだと思う(要確認))。 レジストリの用意はこれだけです。\nレジストリの指定と計測対象の指定 計測対象側です。少し長いですが、NekoParserのメソッドすべてを掲載しました。 まずは、1行目でレジストリの名前の指定(registry = NekoParserMetricRegistry)、レジストリのフィールド名(registry_expr = self.metric_reg)、レジストリの可視性(visibility = pub(self))を定義します。 2行目では、implブロック全体で計測したいメトリクスを指定しています。今回は、スループットとレスポンスタイムを計測したかったので #measure([ResponseTime, Throughput])]と2種類を指定しています。 メトリクスが2種類のため配列で指定していますが、1種類だけの場合は[]の記号は必要ありません。\nあとは、計測したい各メソッドに#[measure]をつけるだけです。 なお、メソッドごとに#[measure(ErrorCount)]といったかたちで個別にメトリクスを指定することも可能です。 今回はお試しということもあり、すべて#[measure]だけになっています。 アノテーションを付けただけで、メソッド自体を変更はしていません。\n#[metered(registry = NekoParserMetricRegistry, registry_expr = self.metric_reg, visibility = pub(self))] #[measure([ResponseTime, Throughput])] impl NekoParser { #[measure] pub fn load_and_parse_neko(\u0026amp;self) { let file_path = \u0026#34;./data/chap04/neko.txt\u0026#34;; let file = File::open(file_path).unwrap(); let buf = BufReader::new(file); let mut out = File::create(\u0026#34;./data/chap04/neko.txt.lindera.json\u0026#34;).unwrap(); buf.lines().filter_map(|item| item.ok()).for_each(|line| { let tokens = self.tokenize(line.as_str()); self.output_tokens(\u0026amp;tokens, \u0026amp;mut out); }); } #[measure] pub fn output_tokens(\u0026amp;self, tokens: \u0026amp;Vec\u0026lt;Token\u0026gt;, buf: \u0026amp;mut File) { writeln!(buf, \u0026#34;{}\u0026#34;, serde_json::to_string(tokens).unwrap()) .expect(\u0026#34;Error during output json\u0026#34;); } #[measure] pub fn tokenize(\u0026amp;self, line: \u0026amp;str) -\u0026gt; Vec\u0026lt;Token\u0026gt; { let mut tokenizer = lindera::tokenizer::Tokenizer::new(\u0026#34;normal\u0026#34;, \u0026#34;\u0026#34;); let lindera_tokens = tokenizer.tokenize(line); let tokens = lindera_tokens .iter() .map(|lindera_token| { let surface = lindera_token.text.to_string(); let pos = lindera_token.detail[0].to_string(); let pos1 = if pos != \u0026#34;UNK\u0026#34; { lindera_token.detail[1].to_string() } else { String::new() }; let base = if pos != \u0026#34;UNK\u0026#34; { lindera_token.detail[6].to_string() } else { String::new() }; Token { surface, base, pos, pos1, } }) .collect(); return tokens; } } 計測結果の出力 最後は計測結果の出力です。 今回はテストメソッドで実行して結果を出力する処理を書きました。\nlet parser = NekoParser::default();で構造体をインスタンス化します。 あとは、処理をそのまま実行します。\n最後に出力結果をJSON形式の文字列にしてから出力しました。 let serialized ... println!(\u0026quot;{}\u0026quot;, serialized);という形です。 簡単ですね!\n#[cfg(test)] mod tests { use crate::chapter04::answer::NekoParser; use std::path::Path; #[test] fn success_output_tokenlists() { let parser = NekoParser::default(); parser.load_and_parse_neko(); let serialized = serde_json::to_string(\u0026amp;parser).unwrap(); println!(\u0026#34;{}\u0026#34;, serialized); assert!(Path::new(\u0026#34;./data/chap04/neko.txt.lindera.json\u0026#34;).exists()); } } 出力結果 ここまで紹介したものの実行結果は次のような形でした。 レスポンスタイム、スループットともに、最小、最大、99パーセンタイルなどを出力してくれます。 出力はメソッド名ごとにくくられているのでとても便利です。\n{ \u0026#34;metric_reg\u0026#34;: { \u0026#34;load_and_parse_neko\u0026#34;: { \u0026#34;response_time\u0026#34;: { \u0026#34;samples\u0026#34;: 1, \u0026#34;min\u0026#34;: 176128, \u0026#34;max\u0026#34;: 177151, \u0026#34;mean\u0026#34;: 176640.0, \u0026#34;stdev\u0026#34;: 0.0, \u0026#34;90%ile\u0026#34;: 177151, \u0026#34;95%ile\u0026#34;: 177151, \u0026#34;99%ile\u0026#34;: 177151, \u0026#34;99.9%ile\u0026#34;: 177151, \u0026#34;99.99%ile\u0026#34;: 177151 }, \u0026#34;throughput\u0026#34;: { \u0026#34;samples\u0026#34;: 0, \u0026#34;min\u0026#34;: 0, \u0026#34;max\u0026#34;: 0, \u0026#34;mean\u0026#34;: 0.0, \u0026#34;stdev\u0026#34;: 0.0, \u0026#34;90%ile\u0026#34;: 0, \u0026#34;95%ile\u0026#34;: 0, \u0026#34;99%ile\u0026#34;: 0, \u0026#34;99.9%ile\u0026#34;: 0, \u0026#34;99.99%ile\u0026#34;: 0 } }, \u0026#34;output_tokens\u0026#34;: { \u0026#34;response_time\u0026#34;: { \u0026#34;samples\u0026#34;: 9964, \u0026#34;min\u0026#34;: 0, \u0026#34;max\u0026#34;: 143, \u0026#34;mean\u0026#34;: 0.03592934564431955, \u0026#34;stdev\u0026#34;: 1.5152489085107463, \u0026#34;90%ile\u0026#34;: 0, \u0026#34;95%ile\u0026#34;: 0, \u0026#34;99%ile\u0026#34;: 0, \u0026#34;99.9%ile\u0026#34;: 6, \u0026#34;99.99%ile\u0026#34;: 143 }, \u0026#34;throughput\u0026#34;: { \u0026#34;samples\u0026#34;: 174, \u0026#34;min\u0026#34;: 39, \u0026#34;max\u0026#34;: 71, \u0026#34;mean\u0026#34;: 57.103448275862064, \u0026#34;stdev\u0026#34;: 3.8417981983375835, \u0026#34;90%ile\u0026#34;: 60, \u0026#34;95%ile\u0026#34;: 61, \u0026#34;99%ile\u0026#34;: 64, \u0026#34;99.9%ile\u0026#34;: 71, \u0026#34;99.99%ile\u0026#34;: 71 } }, \u0026#34;tokenize\u0026#34;: { \u0026#34;response_time\u0026#34;: { \u0026#34;samples\u0026#34;: 9964, \u0026#34;min\u0026#34;: 12, \u0026#34;max\u0026#34;: 79, \u0026#34;mean\u0026#34;: 16.897230028101177, \u0026#34;stdev\u0026#34;: 2.331145559054724, \u0026#34;90%ile\u0026#34;: 19, \u0026#34;95%ile\u0026#34;: 20, \u0026#34;99%ile\u0026#34;: 24, \u0026#34;99.9%ile\u0026#34;: 46, \u0026#34;99.99%ile\u0026#34;: 79 }, \u0026#34;throughput\u0026#34;: { \u0026#34;samples\u0026#34;: 174, \u0026#34;min\u0026#34;: 39, \u0026#34;max\u0026#34;: 71, \u0026#34;mean\u0026#34;: 57.103448275862064, \u0026#34;stdev\u0026#34;: 3.819293076427424, \u0026#34;90%ile\u0026#34;: 60, \u0026#34;95%ile\u0026#34;: 61, \u0026#34;99%ile\u0026#34;: 64, \u0026#34;99.9%ile\u0026#34;: 71, \u0026#34;99.99%ile\u0026#34;: 71 } } } } 出力内容で気になったのはoutput_tokensとtokenizeのthroughputが全く同じ結果が出ていることです。 なにかバグを踏んでいる気がします。。。(時間を見つけてソースコード読んでみるか。)\n気をつけること meteredの導入時にわかりにくいコンパイルエラーが出たので備忘録として残しておきます。 (下からコンパイルエラーを読んでしまうくせがあったのが問題なのですが。。。) エラーメッセージは次のとおりです。\nerror[E0412]: cannot find type `ResponseTime` in this scope --\u0026gt; src/chapter04/answer.rs:13:12 | 13 | #[measure([ResponseTime, Throughput])] | ^^^^^^^^^^^^ not found in this scope | help: consider importing one of these items | 1 | use metered::ResponseTime; | 1 | use metered::common::ResponseTime; | error[E0283]: type annotations needed --\u0026gt; src/chapter04/answer.rs:12:1 | 12 | #[metered(registry = NekoParserMetricRegistry, /* default = self.metrics */ registry_expr = self.metric_reg)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type | = note: cannot satisfy `_: std::default::Default` = note: required by `std::default::Default::default` = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info) 最初のメッセージにはわかりやすく出ていますが、ResponseTimeをuseせずに利用しようとした場合に以下のようなエラーが出ていました。 ターミナル画面が狭かったのでE0283のエラーが目に入り、何を言ってるんだろう?という状態になってしまいました。 スクロールアップしたら、答えが載っているのに。。。\nコード全体 元ネタはNLP100本ノックの第4章です。 コードの全体はGitHubのソースをご覧ください。\nまとめ meteredを簡単ですが紹介してみました。 導入自体も簡単で、想像していたような使い方ができたので満足しています。 ほかにもプロファイラなどはあるのかもしれませんが、まずはこれを使っていこうかと思っています。\nバグらしきものがありそうだったりするので、そのへんは今後調査してみようかと。 まだ、ちょっと試してみただけなので、metered自体のオーバーヘッドや、独自のメトリクスの実装方法、メソッドではなく関数に対して利用する場合にはどうするのか?などいくつか疑問点があるので、今後試してみてまたブログに残しておこうと思います。\n","date":1599487900,"dir":"post/2020/","id":"827de2d7a9d231f6bcb44caf35896c1f","lang":"ja","lastmod":1599487900,"permalink":"https://blog.johtani.info/blog/2020/09/07/intro-metered-rs/","publishdate":"2020-09-07T23:11:40+09:00","summary":"Rustで便利なクレートを見つけたので、紹介がてら、自分のメモのためにブログに残しておきます。 そもそもの問題 Rustで処理を書いていて、なん","tags":["Rust"],"title":"meteredクレートの紹介"},{"contents":"Rustで言語処理100本ノックの第4章です。\n前回はこちら。\n今回は早めに続きをやりました。 「形態素解析」ですしね。\n第4章の概要 吾輩は猫であるの文章が用意されていて、MaCabで形態素解析した結果をファイルに保存したところからが開始となります。\nが、せっかくRustでやっているのでKuromojiのRust版であるLinderaを利用して形態素解析した結果を保存する部分から作成しました。 3章に引き続き、大きな流れのところの説明だけにしておきます。\n形態素解析 もとのneko.txtが文章が1行ごとになっているので、そのまま1行ずつ読みならが、形態素解析していきます。読み込みの部分は3章とあまり変わらないので割愛します。 以下は、形態素解析の処理と形態素解析結果用の構造体です。\n#[derive(Clone, Debug, Serialize, Deserialize)] struct Token { surface: String, base: String, pos: String, pos1: String, } まずは構造体です。今回の問題では、必要な情報は4種類だったのでそれを構造体にしました。\n表層形（surface） 基本形（base） 品詞（pos） 品詞細分類1（pos1） deriveでSerialize、Deserializeを付与しているのは、形態素解析の結果をJSON文字列として保存し、あとのそれぞれの課題で読み出すためにserde_jsonを利用するためです。\nfn tokenize(line: \u0026amp;str) -\u0026gt; Vec\u0026lt;Token\u0026gt; { let mut tokenizer = lindera::tokenizer::Tokenizer::new(\u0026#34;normal\u0026#34;, \u0026#34;\u0026#34;); let lindera_tokens = tokenizer.tokenize(line); let tokens = lindera_tokens .iter() .map(|lindera_token| { let surface = lindera_token.text.to_string(); let pos = lindera_token.detail[0].to_string(); let pos1 = if pos != \u0026#34;UNK\u0026#34; { lindera_token.detail[1].to_string() } else { String::new() }; let base = if pos != \u0026#34;UNK\u0026#34; { lindera_token.detail[6].to_string() } else { String::new() }; Token { surface, base, pos, pos1, } }) .collect(); return tokens; } 次が形態素解析の処理です。 入力に1行分の文章を受け取り、出力として、さきほどの構造体をベクタに入れたものVec\u0026lt;Token\u0026gt;を返します。 内部ではLinderaのTokenizerをnormalモードでインスタンス化してそのtokenizer()メソッドを叩いているだけです。 インスタンス化のときの第2引数は辞書のディレクトリですが、今回はデフォルト辞書(IPADIC)を利用しています。 戻り値はLinderaが用意したToken構造体なので、これを今回作成したToken構造体に詰め替えているだけです。\n注意点としてLinderaはMeCabとは異なり、未知語(辞書に出てこない単語)の処理が実装されていないので、品詞が\u0026quot;UNK\u0026quot;の場合にはその他の情報が取得できないので、空文字を構造体に設定するようにしました。\n結果の保存 形態素解析の結果はJSONで保存しました。 もとのファイルが1文が1行になっていたので、 1行を読み込み、形態素解析し、それをVecで取り出して、1行1配列JSONの形で保存するようにしてあります。\nfn output_tokens(tokens: \u0026amp;Vec\u0026lt;Token\u0026gt;, buf: \u0026amp;mut File) { writeln!(buf, \u0026#34;{}\u0026#34;, serde_json::to_string(tokens).unwrap()).expect(\u0026#34;Error during output json\u0026#34;); } serde_json::to_stringにVec\u0026lt;Token\u0026gt;を渡しているだけですが、構造体にderiveをつけているのでよしなにやってくれます(便利ー)。\nJSONの読み込み処理 1行1JSONの読み込み処理です。 今回も3章のように読み込みながら、各文章ごとの形態素解析結果に対して処理を実施するために、処理を実行するためのtraitをCommandとして用意し、それぞれの問題で形態素解析結果に対して処理を書くような実装にしました。また、設問37で「猫」と共起している単語を処理するという課題があるので、文章に「猫」が入っているものだけを処理できるようにするためのFilterも用意し、これをJSONの読み込み処理のイテレータのfilterにわたすようにしています。 特にフィルタリングが必要ない場合ように、NonFilterを予め実装済みです。\ntrait Command { fn execute(\u0026amp;mut self, tokens: \u0026amp;Vec\u0026lt;Token\u0026gt;); } trait Filter { fn is_target(\u0026amp;self, line: \u0026amp;str) -\u0026gt; bool; } struct NonFilter {} impl Filter for NonFilter { fn is_target(\u0026amp;self, line: \u0026amp;str) -\u0026gt; bool { true } } // ch04-30. 形態素解析結果の読み込み fn load_json\u0026lt;T: Command\u0026gt;(cmd: \u0026amp;mut T) { load_json_with_filter(cmd, \u0026amp;NonFilter {}); } fn load_json_with_filter\u0026lt;T: Command, U: Filter\u0026gt;(cmd: \u0026amp;mut T, filter: \u0026amp;U) { let file = File::open(\u0026#34;./data/chap04/neko.txt.lindera.json\u0026#34;).unwrap(); let buf = BufReader::new(file); buf.lines() .filter_map(|item| item.ok()) .filter(|line| filter.is_target(line)) .for_each(|line| { let tokens = parse_line_json(line.as_str()); cmd.execute(\u0026amp;tokens); }); } output_tokensではserde_json::to_stringを呼び出してましたが、読み込みでは、serde_json::from_strを使うと構造体にしてくれます。\nfn parse_line_json(line: \u0026amp;str) -\u0026gt; Vec\u0026lt;Token\u0026gt; { return serde_json::from_str(line).unwrap(); } あとは、設問ごとにCommandトレイトを実装していく形です。 たとえば、32.の動詞の原形を出力する場合は次のようになります。\nstruct ExtractVerbBase { out: File, } impl Command for ExtractVerbBase { fn execute(\u0026amp;mut self, tokens: \u0026amp;Vec\u0026lt;Token\u0026gt;) { tokens .iter() .filter(|token| token.pos == \u0026#34;動詞\u0026#34;) .for_each(|token| { writeln!(self.out, \u0026#34;{}\u0026#34;, token.base).expect(\u0026#34;Error during writeln\u0026#34;); println!(\u0026#34;{}\u0026#34;, token.base); }) } } 標準出力とは別にファイルにも出力できるようにExtractVerbBaseにoutでファイルを保持しています。\n34. 名詞の連接 「名詞の連接（連続して出現する名詞）を最長一致で抽出せよ．」という課題だったのですが、最初は読み間違えて、名詞の連接の最も長いものだけを出力するようにしてました。。。 やっぱり、出力結果とかのサンプルは用意しといてほしいなぁ。。。\nimpl Command for ExtractMaxConjunctionNoun { fn execute(\u0026amp;mut self, tokens: \u0026amp;Vec\u0026lt;Token\u0026gt;) { let mut nouns = vec![]; // TODO 参照保持でどうにかしたいけどなぁ。 tokens.iter().map(|token| token.clone()).for_each(|token| { if token.pos == \u0026#34;名詞\u0026#34; { nouns.push(token); } else { if nouns.len() \u0026gt; 1 { self.buffer.push(nouns.clone()); } nouns = vec![] } }); } } 名詞の場合に、nounsにバッファリングしつつ、違う品詞が来たら出力するという処理になっています。 cloneを呼び出していますが、これを参照を引き回す感じにできるといいのかもなぁ(結構めんどくさい)。\n36. 頻度上位10語 頻度を数えるのにはBTreeMapを利用しています。 数えながら、Top10を保持する方法がいい気がしたのですが、いい入れ物を見つけられなかったので、数え上げたあとにBTreeMapのIteratorを回しながら、キーバリューのVecをまず生成します。 その生成したVecに値でソートし、その後Iteratorから最初の10件を取得して表示する方法にしました。\nソートして取り出すという処理がついでにかかっています。。。 BinaryHeapがなにか使えそうな気もしたのですが、いい方法が思いつきませんでした。\nfn print_top10(\u0026amp;mut self) { let mut key_values: Vec\u0026lt;(\u0026amp;String, \u0026amp;u32)\u0026gt; = self.terms_count.iter().collect::\u0026lt;Vec\u0026lt;(\u0026amp;String, \u0026amp;u32)\u0026gt;\u0026gt;(); key_values.sort_by(|x, y| y.1.cmp(\u0026amp;x.1)); key_values.iter().take(10).for_each(|(key, value)| { writeln!(\u0026amp;self.out, \u0026#34;{}, {}\u0026#34;, key, value).expect(\u0026#34;Error during writeln\u0026#34;); println!(\u0026#34;{}, {}\u0026#34;, key, value); }); } まとめ 形態素解析結果をちゃんと眺めてはいないですが、処理としてはこんなところかなと。 グラフはめんどくさいのでスキップしてしまいました。。。 Kibana/Esに食わせて見てみるのもありかなぁ?\n次は係り受け解析です。Rustで使えるライブラリとかあるかなぁ?\n","date":1599445027,"dir":"post/2020/","id":"3c5d4d351e0fb9e33e0e8b6d1d43c0f2","lang":"ja","lastmod":1599445027,"permalink":"https://blog.johtani.info/blog/2020/09/07/reboot-nlp100-ch04/","publishdate":"2020-09-07T11:17:07+09:00","summary":"Rustで言語処理100本ノックの第4章です。 前回はこちら。 今回は早めに続きをやりました。 「形態素解析」ですしね。 第4章の概要 吾輩は猫である","tags":["Rust","nlp100"],"title":"第4章終了(言語処理100本ノック2020)"},{"contents":"Rustで言語処理100本ノックの第3章です。\n前回はこちら。\n少し間が空きましたが、再開しました。 間が空いた理由は。。。「正規表現」ですかね。。。 苦手なんです、正規表現。 なので、28はちょっとギブアップしてしまいました。\n第3章の概要 個別に説明はせずに大きな流れのところだけ。 それぞれの問題の解についてはリポジトリを御覧ください(興味ある人いるのかなぁ?)\n第3章はNDJSON(new line delimited JSON)という、 1行に1JSONという形式のデータを格納したファイルがgzipで圧縮された状態で提供されます。 まずは、このJSONファイルからJSONを読み込むのが主な処理になります。\n読み込んだデータに「イギリス」のWikipediaの記事が入っているので、そこから正規表現で必要なデータを抽出します。\n最後の問題が少し特殊で、抜き出した情報の「国旗」のファイル名を元に、MediaWikiのREST APIを叩いて、結果を取得し、その一部の情報を抜き出すというものです。\nJSONの読み込み処理 gzipファイルを読み込んでから、1行ずつ抜き出してVecに入れる処理が次のようになります。 今回のgzipファイルは大した量が入っていないので、全部先に抜き出す処理としてまとめました。 もっと巨大なファイルの場合は個別のJSONに対する処理を buf.lines().map()のmapのなかで実行する形にすると思います。 gzipのファイルを開くのにflate2というクレート(ライブラリ)を利用しました。便利なのは、BufReaderにlines()というメソッドがあるところですかね。\n// https://docs.rs/flate2/1.0.14/flate2/read/struct.GzDecoder.html pub fn extract_ndjson_from_gzip(input_file_name: \u0026amp;str) -\u0026gt; Vec\u0026lt;String\u0026gt; { let f = File::open(input_file_name).expect(\u0026#34;file not found?\u0026#34;); let gz = GzDecoder::new(f); let buf = BufReader::new(gz); let lines: Vec\u0026lt;String\u0026gt; = buf.lines().map(|l| l.unwrap()).collect(); return lines; } こちらは、上記のメソッドで抜き出したVecを元に、記事の情報を抜き出す処理をしています。 JSONをパースして構造体Articleにデシリアライズするために、serdeというライブラリを使用しています。 serde自体は様々なデータ形式(JSON、YAMLなど)をパースするためのフレームワークです。今回はJSONなので、serde_jsonの実装を利用しています。 また、JSON文字列から構造体にデシリアライズするのを簡単にできるように構造体に#[derive(Deserialize)]をつけています。 あとは、let article: Article = serde_json::from_str(json.as_str())という処理を実行すればserde_jsonがJSONをパースして構造体に変換してくれます。形式がわかっているJSONの扱いはこれが楽ですね。変数に型を明記してあるので、型の推論もしてくれてるようです。\n#[derive(Deserialize)] pub struct Article { title: String, text: String, } // ch03-20. JSONデータの読み込み // https://serde.rs/ pub fn load_json(input_file_name: \u0026amp;str, target_title: \u0026amp;str) -\u0026gt; Vec\u0026lt;Article\u0026gt; { let mut results = vec![]; let ndjson = extract_ndjson_from_gzip(input_file_name); for json in ndjson { let article: Article = serde_json::from_str(json.as_str()).expect(\u0026#34;json parse error\u0026#34;); if article.title == target_title { results.push(article); } } return results; } 後続の処理ではパースしたArticleから記事情報を取得して色々と処理をしています。\n正規表現 正規表現用のクレートregexがRustに用意されています。Regex::new(正規表現)で、正規表現をコンパイルし、あとは、この構造体のメソッドを利用して文字列を処理していきます。 問題では、マッチするかどうか、マッチした一部の文字列を抜き出す、不要なタグを削除するといった処理を正規表現で行いました(Rust書くよりも正規表現の書き方とかを調べるのに大半の時間をもっていかれてます。。。)。\npub fn extract_category_lines(article: \u0026amp;Article) -\u0026gt; Vec\u0026lt;String\u0026gt; { let re = Regex::new(r\u0026#34;\\[\\[Category:(.*)\\]\\]\u0026#34;).expect(\u0026#34;syntax error in regex\u0026#34;); let mut lines = vec![]; article.lines_from_text().iter().for_each(|line| { if re.is_match(line) { lines.push(line.to_string()); } }); return lines; } MediaWiki APIリクエスト処理 最後の問題で国旗のファイル名を元にMediaWiki APIを叩いて、URLの文字列を取得しましょうという問題がありました。 ファイル名をREST APIの引数に渡してHTTP経由でリクエストを送信し、返ってくるJSONレスポンスからURLを抜き出すという処理です。\nHTTPのリクエストの送受信にreqwestというクレートを利用しました。 ちょっと長いけど、APIコールしている箇所はこんな形です。\nこの関数にはasyncとついています。非同期処理の関数です。内部で2回ほど(リクエスト送信の結果待ちとレスポンスのパース待ち).awaitがあります。\nclientに.get(URL)やquery(\u0026amp;[])といったメソッドが用意されているので、URLやクエリパラメータを用意してsend()でリクエスト送信します。\nasync fn call_api(file_name: \u0026amp;str) -\u0026gt; Result\u0026lt;String, String\u0026gt; { let client = reqwest::Client::new(); let file_name2 = format!(\u0026#34;File:{}\u0026#34;, file_name); //let mut file_name2 = file_name.to_string().replace(\u0026#34; \u0026#34;, \u0026#34;_\u0026#34;); let query = [ (\u0026#34;action\u0026#34;, \u0026#34;query\u0026#34;), (\u0026#34;format\u0026#34;, \u0026#34;json\u0026#34;), (\u0026#34;prop\u0026#34;, \u0026#34;imageinfo\u0026#34;), (\u0026#34;iiprop\u0026#34;, \u0026#34;url\u0026#34;), (\u0026#34;titles\u0026#34;, file_name2.as_str()), ]; let result = client .get(\u0026#34;https://en.wikipedia.org/w/api.php\u0026#34;) .query(\u0026amp;query) .send() .await; match result { Ok(response) =\u0026gt; match response.status() { StatusCode::OK =\u0026gt; { let body = response.json::\u0026lt;MediaWikiResponse\u0026gt;().await; match body { Ok(obj) =\u0026gt; match obj.get_url() { Some(url) =\u0026gt; Ok(url), None =\u0026gt; Err(String::from(\u0026#34;Cannot get url...\u0026#34;)), }, Err(error) =\u0026gt; Err(error.to_string()), } } _ =\u0026gt; Err(String::from(format!( \u0026#34;Status code is {}.\u0026#34;, response.status() ))), }, Err(error) =\u0026gt; { let error_msg = format!(\u0026#34;Error occurred... {:?}\u0026#34;, error); println!(\u0026#34;{}\u0026#34;, error_msg.as_str()); Err(error_msg) } } } あとは、呼び出し元で非同期の処理を実行するために、tokioというクレートを利用しています。 block_on()でcall_api()の実行をして、結果が返ってくるのを待ち受けています。結果が返ってきて、問題なければ、call_apiの戻り値Result\u0026lt;String, String\u0026gt;の左側のStringの値が取り出され、get_image_urlの戻り値となります。\nfn get_image_url(file_name: \u0026amp;str) -\u0026gt; String { let mut _rt = tokio::runtime::Runtime::new().expect(\u0026#34;Fail initializing runtime\u0026#34;); let task = call_api(file_name); _rt.block_on(task).expect(\u0026#34;Something wrong...\u0026#34;) } 一応、非同期に関して説明してみましたが、合っているのかどうか。。。 クレートの関係などはまだちょっと自身がないです。。。 あとは、エラーの処理の仕方とかももうちょっと勉強したいかな。\nまとめ 一応、3章を終わらせました。だいぶ強引かつ1つスキップしましたが。。。 次は第4章の形態素解析です。\n","date":1599230785,"dir":"post/2020/","id":"eb2a5824e03996c1966bee38866ce349","lang":"ja","lastmod":1599230785,"permalink":"https://blog.johtani.info/blog/2020/09/04/reboot-nlp100-ch03/","publishdate":"2020-09-04T23:46:25+09:00","summary":"Rustで言語処理100本ノックの第3章です。 前回はこちら。 少し間が空きましたが、再開しました。 間が空いた理由は。。。「正規表現」ですかね。","tags":["Rust","nlp100"],"title":"第3章終了(言語処理100本ノック2020)"},{"contents":"負荷を計測するために、数回、Azure Cognitive Searchのクラスターを起動したり、停止したりしてました。 これは、Terraformでやると楽できるのでは?と思ったので、やってみました。 1パーティションのクラスターなので、全然大したことはないのですが、メモを残しておくためにブログに書いておきます。\n基本的にはTerraformの公式ドキュメントにあったものを自分用に変数を抽出しただけです。\nファイルたち 単にクラスターを起動するためだけなので、2種類のファイルだけ作成しました(1個でもいいかも)。\nvariables.tf - 変数用のファイル。いくつかの設定を変数として定義しました。 terraform.tf - Terraform本体のファイル。 variables.tf まずはvariables.tfです(ファイル内の並びは異なりますが。。。)。terraform.tfで利用する5つの変数です。\nresource_group - リソースグループ名。既存とは異なるリソースグループ名にしました(変に壊してもいいので)。 machine_type - 価格レベル(SKU)。公式ドキュメントに設定できる値の一覧があります。今回はWikipediaのデータを登録していたのでそれが入るサイズにしています。 region - 場所(リージョン)。リージョンの一覧はどこにあるんだろう?これを参考にしましたが。 partition_size - パーティションのサイズ(=Elasticsearchでのシャードかな?)です。今回は1つでの性能を計測したかったので1にしてあります。 search_cluster_name - Azure Cognitive Searchのサービス名。search.windows.net名前空間で一意である必要があったので、他の人が使わなそうな名前をつけています。 variable \u0026#34;machine_type\u0026#34; { default = \u0026#34;standard\u0026#34; } variable \u0026#34;region\u0026#34; { default = \u0026#34;East Asia\u0026#34; } variable \u0026#34;resource_group\u0026#34; { default = \u0026#34;johtani-wiki-test\u0026#34; } variable \u0026#34;search_cluster_name\u0026#34; { default = \u0026#34;johtani-wikipedia\u0026#34; } variable \u0026#34;partition_size\u0026#34; { default = 1 } terraform.tf terraform.tfは以下の通り。Terraformの公式ドキュメントにある例にproviderを追加しただけのものになります。\nprovider - プロバイダーの設定。Azureを利用するという宣言です。features {}がないとエラーになります。空でも必ず指定が必要です。認証周りについては、azure-cli経由で認証する方式を採用しました。azure-cliはHomebrewでインストールしています。 azurerm_resource_group - リソースグループの設定。variables.tfのresource_groupとregionを利用しています。必須項目はこの2種類だけです。 azurerm_search_service - Azure Cognitive Searchの設定。partition_count以外は必須項目です。variables.tfとazurerm_resource_groupの設定を利用しています。今回は利用していませんが、レプリカ数なども指定できるようになっています。 # Azureのproviderを指定。 provider \u0026#34;azurerm\u0026#34; { features {} } # リソースグループの設定 resource \u0026#34;azurerm_resource_group\u0026#34; \u0026#34;wiki-test\u0026#34; { name = var.resource_group location = var.region } # Azure Cognitive Searchの設定 resource \u0026#34;azurerm_search_service\u0026#34; \u0026#34;search_service\u0026#34; { name = var.search_cluster_name resource_group_name = azurerm_resource_group.wiki-test.name location = azurerm_resource_group.wiki-test.location sku = var.machine_type partition_count = var.partition_size } 以上がファイルです。ほぼ公式ドキュメントのサンプル通りですねw\nデプロイとか ファイルの準備ができたら実際にデプロイします。 Azureの環境への認証にはAzure CLIを利用して、事前にログインした状態にします。 実際にデプロイするまでの手順は次のようになります。\naz login - Azureの認証。ブラウザが起動してログイン画面が表示されます。無事認証がOKなら、azコマンドでAzure Cloudの情報が取得できます。 terraform init - 初回だけです。Terraformのワーキングディレクトリの初期化処理を実行します。 terraform plan - Terraform \u0026lt; 0.12の場合は実行。最新版だともういらないみたいだ。 terraform apply - 実際にAzure上にクラスターを起動します。Terraformが隠蔽してくれているので、実際にどんなことをやっているかはわかってないですが。 以上で、Azure Cognitive Searchのクラスターが起動します。 すごく簡単です。Webコンソールでチェックすれば、起動していることも確認できます。\nこの状態では、クラスターが起動しただけなので、あとは必要に応じてデータをロードしたり、アプリから検索したりと行ったことが可能になります。 そのへんの話はまた機会があれば。\nDestroy 今回は負荷テスト用にクラスターを起動していましたので、必要なくなれば、クラスターを削除します。Terraformを導入したもう一つの理由がこの簡略化です。 terraform destroyを実行するだけで、Azure Cognitive Searchのクラスターおよび、リソースグループが削除されます。\nまとめ ということで、ほぼ公式ドキュメントのままですが、TerraformでAzure Cognitive Searchのクラスターを起動する方法の紹介でした。 ブログを書いていて、1点気になったのは、ロケーション(リージョン)の一覧はどこにあるんだろう?という点です。azコマンドとかで出てくるのかなぁ?\n","date":1597742807,"dir":"post/2020/","id":"f5effd616a3f8db6193b482caec37912","lang":"ja","lastmod":1597742807,"permalink":"https://blog.johtani.info/blog/2020/08/18/azure-search-with-terraform/","publishdate":"2020-08-18T18:26:47+09:00","summary":"負荷を計測するために、数回、Azure Cognitive Searchのクラスターを起動したり、停止したりしてました。 これは、Terraformでやると楽でき","tags":["azure search"],"title":"TerraformでAzure Cognitive Searchのクラスターを起動"},{"contents":"先日は「システムの特徴と検索機能について」という感じでふんわり書きました。 まぁ、頭の中でぼんやり考えてることを文章にしてみた感じです。 他にもぼんやりしてるものはいくつかあるので今日も書いてみることに。 検索システム?みたいなツイートも見かけたので、検索システムってこんなイメージですというブログを書いてみました。\n検索システム(機能)を構成するパーツ 今回はシステムに組み込まれる検索機能を構成するパーツについて書き出してみようかなと思います。 パーツといってもユーザー、UI、コンテンツなども入れています。\nユーザー 検索UI 検索窓 オートコンプリート 検索結果画面 ファセット ソート ハイライト 詳細画面 レコメンド 検索エンジン コンテンツ 検索ログ クリックログとかも サービス提供者 ざっくり書くとこんな感じです。 システム構成だったり、機能だったり、アクターだったりといろいろなものが混ざってしまっていますが、登場するものはこんなものです。\nざっくりした繋がりの図はこんな感じです。\nそれぞれの役割について見ていきましょう。\nユーザー サイト、システムのユーザーです。 検索UIを経由して望んだコンテンツを探します。 探す目的は、サイトによって異なります。 「何かを購入(ECサイトやオークション)する」だったり、「情報(レシピや社内文書)を見つける」だったりします。 図では「キーワード」と記載しましたが、最近では自然文(文章)を受け付ける検索もあります。\n検索UI サイト、システムが提供するUIです。ユーザーはこのUIにキーワード(質問)を入力し、検索結果を取得します。 UIにはいくつものパーツがさらに存在します。簡単に例を上げると以下のようなものです。\n検索窓 - キーワードを入れるための入力ボックスです。 オートコンプリート(自動補完) - サイトによっては、検索窓に何かを入力すると、キーワードを保管したりサジェストしたりしてくれます。 検索結果画面 - 質問にマッチしたコンテンツの一覧を表示する画面です。一覧以外にもいくつか情報が表示されます。 検索結果一覧 - コンテンツの一覧です。何かしらの基準(日付順や人気順など)によってソートされたものが表示されます。 ファセット - 検索結果が持っている属性(価格帯、カテゴリ、メーカー名など)の一覧で、絞り込み検索のヒントです。 ハイライト - 入力したキーワードがどこにマッチしたかがわかるように、強調表示されたスニペット(情報の一部)が出ます。 検索APIとUIに分かれている場合が多いでしょうか? 処理の流れとしては、検索窓に入力されたキーワードを検索エンジンに問い合わせができるクエリに書き換えてからリクエストを投げます。 あとは、検索エンジンからのレスポンスにある検索結果を表示できる形に変換して表示するのが役割です。 また、検索ログの出力もこの部分で担当することが多いです(もしくは、検索エンジン自体がログ出力の機能を持っている場合もあります)。\n検索エンジン 検索に特化したデータ構造を内部に持っているサーバーもしくはサービスです。 ElasticsearchやApache Solr、Azure Cognitive Searchなどは転置インデックスと呼ばれるデータ構造になっています。 検索エンジンの検索処理に対しての主な役割は次の2つです。\nクエリにマッチするコンテンツの集合を決定する マッチしたコンテンツを特定の条件で並び替える(ランキング) クエリを受け取り、検索結果のリストを返すのが処理の大きな流れです。 その他に、ファセット、ハイライトといった付加的な処理を実行することがあります。\nまた、データ登録(インデキシング/インデクシング)の処理もあります。\n登録するコンテンツを検索に特化したデータ構造にして格納する 転置インデックスの場合は、入力されたデータ(文章)から単語列を作り出して、単語からコンテンツのIDが判別できる形にする処理になります。\nAlgoliaやElastic App SearchのようなSaaSであったり、RDBの機能を利用するといった選択肢もあります。\nデータソース・コンテンツ 実際に提供したいコンテンツになります。 コンテンツが保存されている場所は、サイトによって異なります。\nWebの検索サイト - インターネット上のホームページ ECサイト - データベースに格納されているアイテムのデータ 社内文書検索 - ファイルサーバーやWikiなどのファイル、文書 といった感じです。 実際には、データソースからコンテンツを検索エンジンに登録する場合は、いくつかの処理(いわゆる前処理)が必要になります。 社内文書検索やWebの検索サイトの場合は、データを収集するためのクローラーが必要ですし、 収集したデータから、検索エンジンに登録するデータを加工したり(HTMLタグを除去したり、メタデータ(URL、収集日、タイトル)を付与したり)もします(ETL処理とか言われる)。\n検索ログ 検索を提供するだけであれば、必要ありません。 が、実際に検索がどのような使われ方をしているか?を知るために必要な機能になります。 この検索ログがユーザーのニーズを読み解くための情報になります。 検索ログには次のような情報が入ります。\n検索窓に入力された文字列 入力された文字列でヒットした件数 検索結果を出したタイミングでのログです。他にも実際にヒットしたコンテンツのIDなどをログに残したり、他のユーザーと区別をつけるために、ユーザーのセッションごとにIDを発行してログに残したりもします。\nまた、検索に満足してもらえているかを見るために、実際に検索結果のどのコンテンツに興味をもったのか?という情報も検索ログとして残すことがあります。クリックログなどとも呼ばれます。検索結果のどのドキュメントが実際にクリックされたか(詳細画面に遷移したか)という情報です。1回の検索結果に対してクリックされるごとにログが残ります。 もちろん、結果に満足しない場合は、クリックされずに、キーワードを変えたり、絞り込み条件がクリックされたりします。\nECサイトなどの場合は更に、実際に購入されたかどうかといった情報もユーザーのニーズを読み解くための情報となります。 詳細画面へのクリックログや購入ログについては、検索以外からの流れ(広告やDMだったり、レコメンドだったり)なども考えられます。 これらのログを元に、検索を改善していくことになります。\nサービス提供者 サイト・システムの提供者です。 コンテンツの準備、検索UIにはどんな物が必要なのか、サイト・システムにとって良い検索とはなにか?、検索ログからユーザーのニーズを分析して何を改善していくのか?といったことを考えます。 例としては次のようなことです。\n検索結果に表示するコンテンツとはなにか? コンテンツの持っている項目・属性の何を検索対象とするか? 検索結果の並び順(ランキング)がどんなものがよいのか? 検索UIにはどんなものを表示するのか? 検索機能を作るときの流れ 検索機能を構成するパーツにどんなものがあるかを紹介しました。 実際にシステムに検索機能を追加する場合は、最低限、次のものが必要になります。\n検索UI 検索エンジン(RDB?SaaS?ミドルウェア?) データソース・コンテンツ とりあえずこれらがあれば、検索機能を作ることはできるかと。 ただ、作っただけでは、いいか悪いかの判断がつかないので、どういった使われ方をしているかを知るために検索ログをとったりして、 改善をしていく必要が出てきます。\nまとめ わかってるよそんなことはと言われそうな感じになったかもしれないですが、 検索の機能を構成するパーツについて紹介してみました。 細かなはなしは色々とありますが、大まかにはこのような役割のパーツがあります。\n実際にはこれらのパーツを用意すればよいわけではなく、それぞれで検索を良くしていくためにどんなことを考えていくのか?などが出てきます。そのあたりの話はまた、別のブログで書いていく感じでしょうか。こんな感じで書いてくと、終わらない気がしてきたけど。。。 次はどんなはなしを書くかなぁ。\n","date":1595907282,"dir":"post/2020/","id":"11a61827e80739a6065960eb188d5758","lang":"ja","lastmod":1595907282,"permalink":"https://blog.johtani.info/blog/2020/07/28/improve-search-no2/","publishdate":"2020-07-28T12:34:42+09:00","summary":"先日は「システムの特徴と検索機能について」という感じでふんわり書きました。 まぁ、頭の中でぼんやり考えてることを文章にしてみた感じです。 他にも","tags":["検索"],"title":"検索システムを構成するパーツ(検索システムに関する妄想その2)"},{"contents":"今年の頭からシステムの検索周りを手伝う仕事をフリーランスとしてやっています。 検索の仕組みを知れば知るほど面白くなってきたからという理由になるのかな? LuceneやSolr、Elasticsearchなどを長く触っているというのもあるかと思います。\nということで、検索についていつも考えています。 頭の中でまとまっていない状況ですが、システムにおける検索機能についていくつか頭の中にあることを書き出して、 いろんな方にダメ出しやコメントをもらいたいなと思ったので、色々と書いてみようかと。 思いつきのままに書いているので、はなしがあちこち飛ぶ可能性もありますが、あしからず。\n検索って難しい 「「検索」とは、データの集合から目的のデータを探し出すこと」By Wikipedia\n一言で「検索」といっても、使う人、ユースケースによっていろいろな「検索」があります。 例えば、新しいスマホを買ったときに、スクリーンロックの時間を設定する機能を「検索」したりします。 また、PCで仕事をしているときに、ファイルの中身をある文字列で「検索」したりもします。 TSUTAYAに行って、欲しかった本がおいてあるかどうか店内の端末で「検索」もします。 Rustを書いていて、こんなことをやるライブラリありそうだよな?と思ってGoogleでウェブの検索をしたりもします。\n私が特にそうだと思いますが、なにかあったらまず検索をするという生活をしています。 ただ、このとき、「検索」といっても望んでいる挙動が違ったりするものです。 以下は自分が「検索」しているときに想定していることになります。\nファイル内の検索をしているときはgrep的な検索を想定していることが多い。 書籍の検索をしているときは、特定の項目(著者など)に対してgrep的な検索を想定しているが、名前の読みなどでも検索されることを想定している(漢字覚えてなかったりする。。。)。 Rustを書いているときに機能をGoogleで検索するときは、いい感じに検索してくれることを望んでいる(入力するキーワードが曖昧なことが多々ある。例えば、そのものズバリの名前をしらないときとか) あくまでも私が想像している挙動です。他の人とは違う可能性もあります。 なので、「検索」といってもさまざまな要素があるし、想定しているシーンも異なるので「難しい」なと思っています。 また、そんな「検索」ですが、世の中的にはあって当たり前だと思われていたり、お金や時間がかかるものと思われてなかったりもします。ま、けどそういったことも含めてやればやるほど面白いなと感じている今日このごろです。\n前置きはこのくらいにして、今回はシステムの特徴と検索機能について感じていることを書いてみようと思います。\nシステムの特徴と検索機能 先ほども書きましたが、検索は今やシステムに欠かせない機能となっています。 が、あればいいというものでもないのではないかなと。とりあえず検索できるべきだということで 検索機能を追加しても使いにくいものや、想定している動きをしない場合は使われないものになってしまいます。\nシステムでの検索機能は特に、「情報検索」(Wikipediaはこちら)と呼ばれたりもします。Wikipediaによるとこんな説明です。\n情報検索（じょうほうけんさく）とは、コンピュータを用いて大量のデータ群から目的に合致したものを取り出すこと。検索の対象となるデータには文書や画像、音声、映像、その他さまざまなメディアやその組み合わせとして記録されたデータなどが含まれる。\n「目的」と呼ばれるものは「ユーザーのニーズ」と呼ばれたりもします。 「合致したもの」というのがシステムが返す「検索結果」になります。検索結果は大体の場合、何かしらの順序でソートされていることが多いです。 ざっくり話をすると、「ユーザーのニーズ」を元に「(何かしらの順序でソートされている)検索結果」を返すという処理です。\nただ、この「ユーザーのニーズ」や「何かしらの順序でソートされている検索結果」はシステムの特性、特徴によってぜんぜん違うものになります。検索エンジンを入れただけで解決するものではありません。\nまた、システムは提供する側のニーズもあります。 ECサイトであればより多くのユーザーに購買してもらったり、 コミュニティサイトの場合は利用ユーザーを増やしてコンテンツや広告の収入を増やしたりといったニーズがあります。\nこれらの両方のニーズが検索機能に影響を与えたりもします。\nいくつか例を上げてみましょう。\n書籍の検索の場合 ユーザーのニーズは、「ある本を探す」ことです。そのためにユーザーがクエリを入力します。 クエリは、例にも出しましたがタイトルや著者名の読みだったりします。 検索窓が1つしかないというよりは、著者やタイトル、出版社などそれぞれの項目ごとに検索できるほうが便利だったりしますよね。 検索結果については、完全一致したものが一番最初に出てきてほしいこともあれば、出版年月日の降順で並べたいことなど、 その時々でやりたいことが変わったりもします。\n場合によっては、説明文などでも検索できると嬉しいこともあります。また、システムからは離れますが、図書館や書店で時々、「〇〇について書かれている本ありますか?」といった聞き方をしたりもします。\nまた、書店としては、探している本を見つけてもらうために検索端末などを用意しますが、そ れ以外の本も買ってもらえるといいですよね。 オンラインの書店などでは、検索結果や書籍詳細の画面に関連書籍が出ていることもあります。\n検索とは少し異なり、探索(なにか面白い本とかないかな?というようなニーズ)をしに、書店に行くこともあります。 書店で平積みされた本やポップなどを見て新しい本に興味を持つこともあります。\nオークションサイトやECサイトでの検索の場合 ユーザーのニーズは、「欲しい物を探す」ことです。 ユーザーが入力するクエリは、幅広いものになると思います。製品の型番を入力する人もいれば、 メーカー名や製品名だったり、ジャンルで絞り込んで検索することもあります。\n探されるもの(コンテンツ、アイテム)も多数に渡ります。 検索窓は1つかもしれませんが、検索結果には、絞り込み条件(ファセット)がいくつか並んで、絞り込んでいける仕組みが用意されていることが多いです。\n検索結果のソートは、価格順だったり人気順だったりします。 ただ、オークションサイトの場合は新しいもの順や、終了日時の早い物順だったりします。\nサイト提供者のニーズとしては、より多くのアイテムを購入してもらうこと(売上)です。 また、オークションサイトの場合は、アイテムを提供している人のニーズも影響してくるでしょう。 売りたい人はより多くの人の目に止まってほしいと思うはずなので、 様々な情報を付与していかに目にとまるか?といったことを考えてくると思います。\nまた、様々な商品を扱うECサイトの場合は、さらに色々と大変になってきます。たとえば、「iPhone」で検索されたときに、 iPhoneそのものが上位に来るべきなのか、ケースなどの周辺商品なのかだったりといった問題が出てきます。 商品の提供者が多数に渡る場合は、同一商品でもさまざまなお店から提供されてしまうために、検索結果一覧に多数同じ商品が並んだりもしますよね。\nレシピサイトでの検索の場合 ユーザーのニーズは「レシピを探す」です。が、探し方はユーザーによって様々です。 冷蔵庫にある材料を入力して検索することもあれば、食べたいものが決まっていてそのレシピを検索することもあります。 このとき、重要なのは類義語だったりするでしょう。食材やレシピは同じものでも様々な名前(例:パクチー、コリアンダー、シャンツァイ(香菜)など)を持っていたりします。また、部位や形によっても名前が変わったりもします。\n検索結果は人気順で並ぶことが多いでしょうか? ただ、レシピの提供がユーザーによるものなのか、サイト運営者が提供しているものかによっても変わってくるでしょう。\nサイト提供者のニーズとしては、レシピコミュニティサイトの場合は、ユーザー数の増加や広告の売上などがあるでしょう。 調味料などのメーカーがレシピサイトをやっている場合は、調味料の売上だったりします。この場合は、検索がどの程度売上に寄与しているのか?などを測ることが難しかったりしそうです。\n社内文書検索の場合 ユーザーのニーズは「文書を探す」です。探し方はファイル名であったり、ファイルのなかに出てくる単語だったりします。 社内用語・略語のような特殊な単語で検索されることもあるでしょう。ユーザーによっては、ぼんやりとした「こんな資料を探している」といったふんわりとした検索をしたくなることもあります。\n検索結果の表示順は「それっぽいもの」が上位に出てくることが望まれそうです。 ただ、古い文書が出てきても役に立たないこともあります。新しい文書のほうが役に立つことが多いので、最近作られたものというのも重要な情報になります。ただし、権限によっては見ることができなかったり、そもそも探すこともNGだったりもします。\n社内文書検索の提供者は、素早く検索できるものを提供することで仕事の効率を上げてもらったり、無駄を省くことができることを期待しているでしょう。\n昔からですが、社内の文書は様々な場所に散らばっていることが多いです。顧客管理システム、ファイルサーバー、Wiki、ウェブサイトなどこれらをまとめて検索できるシステムなどが望まれていることも多いです(使われるかはまた別ですが。。。)。\nスマートスピーカーの場合 ちょっと特殊な面白い例かなと思ってます。 音声で検索(というかお願い?)します。 システムとしては、ユーザーのニーズを理解するのに2段階あるのかなと。\n音声認識 認識した文章・キーワードで検索(場合によってはコマンド発行) これだけでも難易度が増します。\nさらに、画面のないスピーカーの場合は、結果は1件だけになります。これって結構難しいことだと思うんです。 画面があれば、検索結果を上位10件などのリストで表示して、あとはユーザーに選んでもらうことができますが、 音声の場合は1件だけしか返せません。 また、レスポンスタイムもシビアなものだと想定されます。ずっとスピーカーに黙っていられると困りますよね? きっと大変なんだろうなぁ(妄想)。\nこのように、検索と言っても、システムごとに要求・想定されるものは変わってきます。\nまとめ 例をいくつか上げましたが、ざっくりしすぎて発散してますかね。。。 想像している部分もあるので、この通りではないと思います。 ただ、システムによって、「検索」といってもシステムの特性上、 さまざまな物事、思惑が絡んでくるというのは想像してもらえたと思います?(思いたい)。\nシステムに検索機能を追加すると言っても、探したいものが何なのか?、探してもらうものはどういったものなのか?、 検索機能を追加することで何を達成したいのか?など考えることは色々あります。 どうやって、検索機能を実装するのか、その検索機能を実装するためにはどんな情報が必要なのか?などの検索機能のコアな部分を考えるだけでなく、提供しているシステム、コンテンツがどんなものかなど、システム全体を考えながら検索機能を考えていく事が検索をより良いものとして行くことだと思います。\nまた、検索されるものも検索する人もシステムが成長するのに合わせて変化していきいます。システム同様、一度作ればおしまいというものではないので、やることはいっぱいあるのかなと。\n次は、検索のパーツについてなにか書こうかなぁ。\nボヤキ もう少しまとめてから書いたほうがいいのかもなぁ。 もしくは、出てくる要素を整理するとか。 ユーザー、コンテンツ、コンテンツ提供者とかで。 ふんわりとしたブログになってしまった。 個別のシステムごとにもっと書けることもありそう。\n","date":1595842134,"dir":"post/2020/","id":"9da845cd31310b8952efd1be1881e651","lang":"ja","lastmod":1595842134,"permalink":"https://blog.johtani.info/blog/2020/07/27/improve-search-no1/","publishdate":"2020-07-27T18:28:54+09:00","summary":"今年の頭からシステムの検索周りを手伝う仕事をフリーランスとしてやっています。 検索の仕組みを知れば知るほど面白くなってきたからという理由になる","tags":["検索"],"title":"システムの特徴と検索機能について(検索システムに関する妄想その1)"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章 Rust the book - 第9章 Rust the book - 第10章 Rust the book - 第13章 14章は飛ばして、15章です(Cargoはまた別途調べればいいかな?と思って)。\n第15章 スマートポインタ たぶん、これを理解すれば、参照とベクタや構造体とかの組み合わせがもう少し効率よく使えるようになるのかなぁ?\nポインタの強い版? 参照カウント方式のスマートポインタ型 - Luceneとかで実装されてた気がするなぁ 複数の所有者!? DerefとDropトレイトを実装している構造体 ヒープのデータを指すBoxを使用する これはコンパイルエラー。let yのタイミングで借用してるので、書き換えでエラーになる。\nfn main() { let mut x = 5; let y = \u0026amp;x; assert_eq!(5, x); assert_eq!(5, *y); x = 6; assert_eq!(6, x); assert_eq!(6, *y); } こっちはOK。\nfn main() { let mut x = 5; // in stack let y = Box::new(x); // in heap assert_eq!(5, x); assert_eq!(5, *y); x = 6; assert_eq!(6, x); assert_eq!(6, *y); } 余談:コンパイラが変なワーニングを出してくれた。\nuse std::ops::Deref; impl\u0026lt;T, Z\u0026gt; Deref for MyBox\u0026lt;T, Z\u0026gt; { type Target = T; fn deref(\u0026amp;self) -\u0026gt; \u0026amp;T { \u0026amp;self.0 } } struct MyBox\u0026lt;T, Z\u0026gt;(T, Z); impl\u0026lt;T, Z\u0026gt; MyBox\u0026lt;T, Z\u0026gt; { fn new(x: T, y: Z) -\u0026gt; MyBox\u0026lt;T, Z\u0026gt; { MyBox(x, y) } } fn main() { let x = 5; let z = \u0026#34;10\u0026#34;; let y = MyBox::new(x, z); assert_eq!(5, x); assert_eq!(5, *y); } Derefトレイトでスマートポインタを普通の参照のように扱う 参照外し型強制 : 日本語ムズカシイネ Derefを自分で実装しないといけない場面がちょっと想像できてない。たぶん、Boxとかの説明に必要なので出てきたって感じなんだろうけど。 Dropトレイトで片付け時にコードを走らせる こっちは、リソース開放とかでいい感じにできそうだってのはわかった。 Dropはどんなときに実装するんだろう?Tantivyだとオブジェクトプールとかで使ってた。 Rcは、参照カウント方式のスマートポインタ これ、ここで作ったConsのリストを追っかけるためのサンプルも書いてほしい。 #[derive(Debug)] enum List { Cons(i32, Rc\u0026lt;List\u0026gt;), Nil, } fn print_typename\u0026lt;T\u0026gt;(_: T) { println!(\u0026#34;{}\u0026#34;, std::any::type_name::\u0026lt;T\u0026gt;()); } use List::{Cons, Nil}; use std::rc::Rc; use std::borrow::Borrow; fn main() { let z = Cons(5, Rc::new(Cons(10, Rc::new(Nil)))); let a = Rc::new(z); let _b = Cons(3, Rc::clone(\u0026amp;a)); let _c = Cons(4, Rc::clone(\u0026amp;a)); match \u0026amp;(*a) { Cons(v1, v2) =\u0026gt; { print_typename(v2); println!(\u0026#34;{}, {:?}\u0026#34;, v1, v2); }, Nil =\u0026gt; println!(\u0026#34;Nil!!\u0026#34;) }; } RefCellと内部可変性パターン 循環参照は、メモリをリークすることもある ","date":1594288778,"dir":"post/2020/","id":"208a8c072ea521c813b86ca7730eb880","lang":"ja","lastmod":1594288778,"permalink":"https://blog.johtani.info/blog/2020/07/09/hap15-rust-the-book/","publishdate":"2020-07-09T18:59:38+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第15章"},{"contents":"6月7日の週に開催されたBerlin Buzzwordsにオンライン出張してました。\nBerlin Buzzwordsとは? ベルリンで開催されている、Big Data、Scarability、Storage and Searchabilityに関するカンファレンスです。 今年はコロナウイルスの影響で、オンラインで開催されました。 また、同時期に検索に関する他のカンファレンス(以下の2つ)もベルリンで毎年開催されているのですが、今年はこれら3つのカンファレンスが1つのチケットで参加できる形で開催されました。\nMICES - MIX-CAMP E-COMMERCE SEARCH HAYSTACK - The Search Relevance Conference! sponsored by OpenSource Connections MICES、HAYSTACKは初参加ですが、検索に関するいくつかのトピックが聞けたので楽しかったです。\n6/7から6/12まで(がんばって)参加したので、その感想などをブログにとどめておきます。\nオンラインってどんな感じで開催されてた? まずは、オンライン開催がどのような感じだったのかをメモしておきます。\n有料のオンラインカンファレンス(事前にチケット購入が必要) 参加者用Slack カンファレンス数日前まではここで連絡とか質問が可能だった(もちろん、メールも来ましたけど)。 基本的なプラットフォームはBrellaのバーチャルイベントプラットフォーム 参加者同士のSNS機能 - 参加者同士の興味によって参加登録時に似たような人ですよとマッチングしたり。ビデオチャット機能もあり。 カンファレンスのスケジュール確認 - セッションのスケジュールの他に、参加者同士でのチャットのスケジュールも可能。一番便利だったのは自分のタイムゾーンも表示してくれること。 ストリームチャネル - セッションが行われている場所への誘導 スピーカー・スポンサーのリスト - スピーカーやスポンサーを探せる機能。スポンサー企業からは参加者も見ることができる セッションはYouTubeライブ ストリーム中だったらちょっと戻ったり、ポーズもできるので、便利だった セッション後の質疑応答にはJitsiというオープンソース!?のビデオカンファレンスの部屋が用意されてた(GitHubで公開されてるのか。https://github.com/jitsi)。 2日目、3日目はLTとかが終わったあとに、オンライン飲み会やってたっぽい(不参加) 主催者側も初めてだとは思うのですが、目立ったトラブルはなかったです。 ちょっとだけ遅れたりしてましたが、それほど影響はなかったです。 オンラインでの開催の一番のネックは、日本だと時差が辛いということです。 ベルリンが開催地なのですが、スピーカーや参加者はアメリカからの方が結構います。 そのため、開始時間が日本の23時といった具合になりました。\n面白かった\u0026amp;気になったセッション いくつか面白かった\u0026amp;もう一度見ないとなと思ったセッションと感想を。\nNatural Language queries at Salesforce scale セッションのページはこちら(2020年7月現在) Salesforceでどのような自然言語のようなクエリに対して書き換え、サジェストのようなことをやっているか?という話です。 Salesforceはテナント(企業)ごとに、データ構造などがカスタマイズ可能なため、 それぞれ個別に入力クエリ(例: new leads in sf)に対して、どういったパーツ(時間?場所?状態?)なのか?、どのフィールドへの条件なのか?といったものをNERのディープラーニングモデルとして捉えて解析しているという話でした。 企業毎にパーソナライズもされていると。実際にはパイプラインの一部でこの処理をやっており、それ以外にも処理はされているという話もありました。評価の話もされています。\nAMA - AI-Powered Search セッションのページはこちら(2020年7月現在) ManningでMEAP(絶賛書いているところ)のAI-Powered Searchの著者2名がAMA形式でいろんな質問に答えていく感じのやつです。 最初は近況報告(Treyさんがカンファレンス直前に転職してた)と、書籍がどんなものかを簡単に紹介したあと、質問に答えていく形式で2時間あります。ディープラーニングのモデルに関する話なども出てきています。 もう一度見たいと思ってたやつなので見ないとな。。。 (パネルっぽいセッションは、ヒントがなにもないので結構辛い)\nAsk Me Anything: Lucene 9 セッションのページはこちら(2020年7月現在) LuceneのPMCメンバーのUweさんが今後のLucene/Solrのいくつかの質問に答える感じのAMAです。 出てきた話(質問の前の)としては、Lucene 8の現状(Bloc-Max WANDとか)や、Java 11対応になるよとかです。 QAでは、SIMDの話、Approximate Nearest Neighborがどんな感じか?などの話でした。\nFrom commercial search to owned search セッションのページはこちら(2020年7月現在) カルフールスペインがECの検索をどのように導入したかという概要レベルの話でした。 モノリシックなものをマイクロサービスでk8s上に載せ替えたという大きなアーキテクチャ以降の話です。 Empathy.coが提供しているものを最終的には使用したみたいだけど、 どんな検索がされているのかといったニーズの調査ができるようになり、検索に絡んだKPIが改善した話でした。 COVID-19に絡んだクエリの変化についてもちょっと話が出てました。\nNeural Search in Practice セッションのページはこちら(2020年7月現在) Zalandoの検索の一部でNIR(Neural IRモデル)を利用してクエリの改善をやって、それをどうやってトレーニングして、テストしたかなどの話。 NIRを利用することで、複数の言語に対して改善が見られたという話だった。 今までは、クエリをいくつかの処理を元に翻訳して、入力された単語がカテゴリーに対するものなのか、スタイルに関するものなのか?などを判別して、クエリの補強?を行っている手法だった。 これに対して、ディープラーニングでクエリに対するクリックデータを元にトレーニングして、どういうクエリに対してどんなアイテムを出すのか?というモデルで検索を改善していた。 ヒット件数が0件だったり少ないものを対象にして上記の処理を入れているらしい。 (ということで、ディープラーニングをしっかり勉強しないといけないみたいなので、どうにかしたい。。。)\nTop 10 Lessons learned in search projects the past 10 years セッションのページはこちら(2020年7月現在) 10年検索プロジェクトをやってきた10個の気づきという感じのセッション。 ごく当たり前のことなんだけど、検索の導入・改善に関して、こういう事あって、何も考えないとこうなっちゃうよね。 だから、こんなことをやるべきだよね?という話です。 たとえば、検索窓はあるけど分析すらしていない状況(レッスン1)だとまずはこういうのやらないとね。とか、 検索クエリの分析・改善ばかりして、コンテンツの分析・改善を怠っていないか?という当たり前の話です。 当たり前なんだけどまとめてくれてるのは、やはりいいなぁと。\nClick logs and insights: Putting the search experts in your audience to work セッションのページはこちら(2020年7月現在) 検索ログとクリックログがあったときに、どういったことに使えるのかを料理のレシピに見立ててデモをするセッションで説明が面白かったです。 「こんなログがあったときに、ログのこの項目とこの項目を材料にすると、こんなのができますね」というのを、Elasticsearchにログを取り込んで、JupyterNotebookでデモをしていました。やはり動くものがあるとわかりやすいですねぇ。\nMixing and Matching: Diversifying Search Results セッションのページはこちら(2020年7月現在) これまたパネルセッションです。 検索結果の多様性に関するディスカッションでした。 これは、ECだからこその課題でもあるのかなと。検索自体は「何かを見つける」ための手段です。 普通に考えた場合は、ピンポイントで探していたものが見つかるのが嬉しいです。 が、例えば、ユーザーが検索した単語そのものが入っているだけのものが見つかるよりも、似たような商品も一緒に出てきてほしいことありますよね?また、ECサイトだと、回遊してほしいというのもあります。ということで、それぞれの方がどんな観点で多様性を考えているのかという話をするディスカッションになっていました。\nThought Vectors, Knowledge Graphs, and Curious Death(?) of Keyword Search セッションのページはこちら(2020年7月現在) AI-Powered Searchの著者の一人、Treyさんのセッション。ベクトルを検索にどうやって使うのか、 ベクトルで表現できるものはどんなものがあるのか?どんな検索エンジンで使えるのか?という話でした。 歴史的な話も交えつつ、検索だとこのへんで使えるんじゃないか?というような話でした。\n録画は? 気になったセッションをいくつか書き出してみました。 ちなみに、全セッションのビデオが公開されています。興味がある方は、ご覧いただければと。\nThe recordings from this year\u0026#39;s Berlin Buzzwords / MICES / Haystack joint event are now online. You can watch them all on our YouTube channel. Thank you once again to all of our wonderful speakers. https://t.co/hTRDmKNdpd\n\u0026mdash; @berlinbuzzwords@floss.social (@berlinbuzzwords) July 6, 2020 感想そして来年は? 楽しかったです。検索に関する話が色々聞けるのはやっぱ楽しいですね。サイトの特性(ECなのか、Wikipediaなのかなど)によっても「良い検索」の定義も変わるので、サービスなどがどんなものか、そしてそれを良くするためには検索はどんなことができるのか?といった話や、技術的な濃い話までいろいろな話を聞けました。 ただ、パネルは英語の聞き取りが辛いですね。。。あと、時差が。日本にいながらにして時差ボケは辛い。。。 オンライン飲み会には流石に参加できませんでした(4時とか5時から始まるし)。\n来年もオンラインで開催されたら間違いなく参加します。 オフラインのみだった場合はどうなるかなぁ。。。\n","date":1594005164,"dir":"post/2020/","id":"e5cb2e5d501d3db2db5d8f14984a66d4","lang":"ja","lastmod":1594005164,"permalink":"https://blog.johtani.info/blog/2020/07/06/attend-berlin-buzzwords/","publishdate":"2020-07-06T12:12:44+09:00","summary":"6月7日の週に開催されたBerlin Buzzwordsにオンライン出張してました。 Berlin Buzzwordsとは? ベルリンで開催されている、Big","tags":["conference","berlin buzzwords"],"title":"Berlin Buzzwordsにオンライン出張してた"},{"contents":"luceneutil - マニアックなツールのセットアップの続きです。 今回も誰得?なブログなので興味ない場合は飛ばしましょう。\n一応、luceneutilのREADMEにあるlocalrun.pyを動かせるところまでいったんですが、そこで一旦本題を思い返してみました。\nKuromojiの性能が落ちてるらしいし、Analyzer系のベンチマーク測ってるグラフに載せたほうがいいよね。\nこれが、そもそも動かしてみようと思った本題です。 READMEに書いてある手順で動いたんですが、よくよく調べてみると、Analyzer系の性能テストをやってるのは、別物っぽいぞと。 なんとなく、「ソフトウェア考古学」っぽくなってきましたね。\nAnalyzerの性能テストやってるのは? Analyzerのパフォーマンステストのグラフに出てきたTokenizerの名前を元にluceneutilのリポジトリを検索してみました。 EgdeNGrams当たりで検索するとヒットしたのが以下のファイルです。\nsrc/main/perf/TestAnalyzerPerf.java src/main/perf/TestAnalyzerPerf4x.java src/python/sumAnalyzerPerf.py 本命はsrc/main/perf/TestAnalyzerPerf.javaっぽいですね。 これを動かしている人はどれかな?ということで、今度はこのファイル名で検索します。\nsrc/python/runAnalyzerPerf.py どうやら、このPythonのファイルが先程のJavaファイルを実行して、性能を計測しているみたいです。 最初に出てきた、sumAnalyzerPerf.pyはrunAnalyzerPerf.pyの実行結果をAnalyzerの計測結果のグラフに追加する処理をしているようだということまでがわかりました。\nKuromojiをTestAnalyzerPerfに追加してみる 動かす対象がわかったので、あとは、やることを追加しましょうと。\nKuromojiの実行をTestAnalyzerPerfに追加 引数を追加して日本語版のWikipediaのファイルも読み込むようにする runAnalyzerPerf.pyに引数の追加とクラスパスの追加 JapaneseAnalyzerはlucene/analysis/kuromojiにビルドされるのでクラスパスを追加 引数に日本語版のWikipediaのファイルを追加 日本語版のWikipediaのデータの用意 こんなものかな?と。\n1と2はそれほど大変ではないので、3をまずはというところから始めてみました。\nWikipediaのXMLから1行1データのTSVファイルに まずは、どんなファイルを想定して動いているのかな?ということで、英語版のファイルがどんなものかを探してみることに。\nTestAnalyzerPerf.javaでは入力ファイルから1行ずつ文字列を読み込んでAnalyzerに処理させているだけというのがわかっています。なので、とりあえず、1行ずつ読めるような形式だと。 次に、runAnalyzerPerf.pyの55行目でenwiki-20130102-lines.txtというものを読み込んでいます。 が、これがよくわからないw\n前回とりあえず動いたときに、src/python/constants.pyにいろんなファイルへのパスとかが記載されていたのを覚えていたので、その当たりから調べてみます。 52行目に約665万件のドキュメントだというような記載があります。 前回のlocalrun.pyのファイルと似たような構造(1行に1記事が埋め込まれたTSVファイル)だろうと判断して、それを作りそうなプログラムを探してみました。 Wikiとかで検索して見つけたのがこのソースたちでした。\nsrc/python/wikiXMLToText.py - それっぽい名前ですよね? 中身を見ると、第1引数のファイル(XML)からpageタグごとにデータを抜き出し、処理をしてからタブ区切りで第2引数のファイルに書き出してます。 src/python/WikipediaExtractor.py - これもそれっぽいですね。 WikipediaExtractory.pyは界隈では有名なhttps://github.com/attardi/wikiextractorみたいです。こっちはなんとなく使い方はわかっています。 src/python/combineWikiFiles.py - これまたそれっぽい。 中身を見ると、1番目のコードで出力したデータに、2番めのコードで出力されたデータを元になにかしら処理をして、引数で与えられたファイルに出力する感じになってます。 ということで、完全に憶測ですが、日本語のWikipediaのXMLファイルを元に次のような流れでファイル作ってみればいいのかな?と。\njawiki-20200620-pages-articles.xml.bz2をwikimediaからダウンロードして、unbzip2で展開 python src/python/wikiXMLToText.py jawiki-20200620-pages-articles.xml jawiki-lines.txtで、1行ごとのデータを作る ちなみに、このプログラムは2箇所ほど修正しました。usernameタグが存在しないpageが出力されなさそうなので、デフォルトでusername: \u0026quot;\u0026quot;みたいなデータをattrってディクショナリに設定しました。 cat jawiki-20200620-pages-articles.xml | python -u src/python/WikipediaExtractor.py -b102400m -o extractedで別途XMLからデータを抽出 python src/python/combineWikiFiles.py jawiki-lines.txt extracted/AA/wiki_00 jawiki-20200620-lines.txtで2と3の出力をかけ合わせる で、まぁ、一応ファイルはできたんですが。。。 前回のブログ記事でセットアップしたときにダウンロードされたファイルはtitle、日付、本文の3つのカラムしかないんですが、上記の手順で作り出したファイルにはいろんなカラムが存在するんですよね(2が出力する項目が結構ある)。。。\n性能テスト用プログラムの書き換え 入力ファイルは出来上がったので、あとは、性能テストを走らせる部分の修正です。 修正部分はプルリク見たほうが明確なので省略で。\n実行してみた で、実行してみました。 せっかくなので、ブランチをbranch_8_5とmasterを対象にしてやってみました。 実際にはsrc/python/runAnalyzerPerf.pyにディレクトリ名やブランチ名が直書きされてたので書き換えつつ実施した結果はこちら。\n他の英語系のAnalyzerと同じグラフに載せてみたのですが、遅いので、下の方に表示されてます。 で、下に凹んだ部分(23 Juneのところ)がbranch_8_5で実行したときの性能値でした。 実際に遅くなってますね。ただ、他のAnalyzerの振れ幅も大きいので、別のグラフにしたほうがわかりやすくなるのかもなぁと思った次第です。\nということで、一応動いたんでプルリク出してみました。 採用されるかなぁ?\n一応誰得ブログはこれでおしまい。 Noriとかもこの感じで対応できるんじゃないかな?\n","date":1593050518,"dir":"post/2020/","id":"bbd2824ff0d5b801bb6f5da3a2a1a888","lang":"ja","lastmod":1593050518,"permalink":"https://blog.johtani.info/blog/2020/06/25/analyzer-perf-test-with-luceneutil/","publishdate":"2020-06-25T11:01:58+09:00","summary":"luceneutil - マニアックなツールのセットアップの続きです。 今回も誰得?なブログなので興味ない場合は飛ばしましょう。 一応、luceneutilのREAD","tags":["lucene"],"title":"luceneutil - Analyzer性能テストへのkuromojiの追加"},{"contents":"LuceneのFSTの修正に関連して、Kuromojiのパフォーマンス問題が出ているようです。 この問題自体はLucene 8.6.0以降で直る予定のようなのです(Elasticsearchへの影響範囲についてはこれが参考になるかな?)。 で、これに関連して、ベンチマーク計らないとねという話が出ていて、 昔から、LuceneのMikeさんがやっているベンチマークのグラフに載せるのがいいよねという話になっていました。 どうも、これについては、Luceneの中にあるbenchmarkというプロジェクトではなく、MikeさんのGitHubリポジトリにあるプログラムで計測しているようです。\nじゃあ、手元でこれどうやって動かすんだろう?ということでやってみたブログになります。 おそらく、99.99%の人は興味ないと思うのでスルーしていただくのがいいと思います。備忘録のために書いてます。\nとりあえずgit clone 公開されているリポジトリはこちらです。\n手順通りに? とりあえず、READMEにセットアップなどのやり方があったんで追っていくことに。 とりあえず動くまでの手順は以下のとおりです。\nディレクトリを決める $LUCENE_BENCH_HOMEが起点になります。名前は何でもいいみたいです。 cd $LUCENE_BENCH_HOME リポジトリをクローン - git clone https://github.com/mikemccand/luceneutil.git utilです。 コレ自体は問題なし。 cd util セットアップスクリプトを実行 - python src/python/setup.py -download ここがすごく時間かかります。6GBのファイルをゆっくりダウンロードしてきますので、一晩置いておきましょう(起きたら終わってた) $LUCENE_BENCH_HOME/dataにenwiki-20120502-lines-1k.txt.lzmaとwikimedium500.tasksいうファイルがダウンロードされている。 ダウンロードした圧縮ファイルを展開 - unlzma enwiki-20120502-lines-1k.txt.lzma macOSにlzmaのコマンド入ってるんですね。知らなかった。 終わったらcd ../で$LUCENE_BENCH_HOMEに戻っておく ベンチマーク対象となるLuceneを用意 - git clone https://github.com/apache/lucene-solr.git READMEにはlucene_candidateとlucene_baselineって名前でって書いてあったのですが、これだと、この後の実行フェーズでエラーになりました。 trunkとpatchというディレクトリにそれぞれ変更しました。localrun.pyを実行したらこのディレクトリ名だったので(相変わらず、自分、行きあたりばったりな対応してるなぁ。。。) とりあえず動くかどうかを確認したかったので、trunkとpatchはどちらもリポジトリをcloneしたものになってます。動いたのを確認したら、タグを指定して比較したいブランチをチェックアウトする予定。 trunkとpatchをビルド - ant jar * localrun.pyを実行 - cd utilそして。。。 5.で記述したディレクトリ以外に1箇所Pythonのコードを書き換えた。 src/python/benchUtil.py内部にhppc-0.8.1.jarのファイルの存在チェックをしているのだが、2020/06/23時点でのLuceneのリポジトリの依存関係だとhppc-0.8.2.jarになっており、ファイルが見つからないエラーが出たため、0.8.2に書き換えた。970行目付近。 改めて実行したら成功した。 まだ途中 とりあえず、実行するところまではできましたが、結果の見方とかちゃんと調べないとなぁ。 いくつかローカルで対応したものについてはあとでGitHubにIssue立てとくべきだな。\nと、動くのを確認したので、日本語周りの準備をしてみてるところです。\n終わったこと\n日本語のWikipediaのデータjawiki-20200620-pages-articles.xml.bz2をダウンロードして展開 試している途中\nWikipediaExtractorでXMLからデータを抽出 - cat ~/tmp/wiki/jawiki-20200620-pages-articles.xml | python -u src/python/WikipediaExtractor.py -b102400m -o extracted これは手順が違うかも???? python src/python/wikiXMLToText.py ~/tmp/wiki/20200620-pages-articles.xml ./hoge.txt これで、title、日付、本文が抜き出せそう? この後にcombineWikiFiles.pyの実行かな? って感じです。 誰得だろうこれ???\n","date":1592917109,"dir":"post/2020/","id":"8a1ea5d5cf843bc5955a94cfcc321e92","lang":"ja","lastmod":1592917109,"permalink":"https://blog.johtani.info/blog/2020/06/23/how-to-use-luceneutil/","publishdate":"2020-06-23T21:58:29+09:00","summary":"LuceneのFSTの修正に関連して、Kuromojiのパフォーマンス問題が出ているようです。 この問題自体はLucene 8.6.0以降で直る","tags":["lucene"],"title":"luceneutil - マニアックなツールのセットアップ"},{"contents":"Azure Cognitive Searchで日本語を扱うときに、形態素解析器を使いたい場合、2種類のAnalyzerが用意されています。今回はこれらの違いがどんなものかを見ていくことにします。\nAnalyzerとは? まずは、その前にAnalyzerとは何者か?というのを少しだけ。 Azure Cognitive Searchは転置インデックスを内部で作成して、検索を行っています。 この、転置インデックスは、「単語」がどのドキュメントに入っているか?を素早く見つけることができるデータ構造となっています。\nAzure Cognitive Searchは、この「単語」を入力された文章から生成するときに、Analyzerというものを利用します。 Analyzerは入力された文章をある規則に則って単語に分割する機能です。 この「ある規則」が、各種言語や用途によって様々に用意されています。 今回はこの中のja.luceneとja.microsoftという2種類のAnalyzerについて違いを見ていきます。\n2種類のAnalyzerの違いはどんなもの? このAnalyzerの挙動を見るためのエンドポイントとしてanalyzeというAPIがあります(詳細は昔のブログを参照)。\nこのAPIを利用して、Wikipediaのいくつかの文章を単語に区切って見て、 ja.microsoftがどんな動きをしているのか想像してみます(残念ながらja.microsoftの仕様?や挙動についてはページが見つからないため)。\nもとの文章と解析結果(一部抜粋) 文章は、手元のElasticsearchに登録したjawikiのデータからランダムに抽出しています。また、自前のツールで生成したWikipediaのデータなので、まだ一部、見苦しい文字列になっています(そっちもなおさないと)。\n1. 砂川（熊本県） thumb|250px|right|上砂川橋より上流方砂川（すながわ）は、熊本県宇城市・八代郡氷川町を流れる二級河川。\nこの文字列から抽出された単語で特徴的なものを一部抜粋しました。\nja.microsoft ja.lucene 250px 250 px 上砂 上, 上砂川 川橋 砂川 橋 宇城 宇 市 城市 二級 二 ^ 級 まず、最初の250pxですが、ja.microsoftでは、pxが単位であると判定しているのか、数値と合わせた単語として抽出されています。この場合、250で検索しても、この文字列はヒットしない形になるので、ノイズが減ることが考えられるかと。\n上砂川橋という文字は、分割の仕方が別れました。 ja.luceneでは、上砂川という単語が地名として辞書に存在するために、このような分割になっています。ja.microsoftのデータは品詞の情報が取れないのですが、上砂、川橋ともに、名詞として辞書に存在しているのではないかなと。ja.luceneには川橋という単語は存在していないようでした。\n宇城市(うきし)については、2005年に合併でできた市のようで、ja.luceneが利用している辞書には存在しない可能性があり、宇城という文字が抽出できてないと思われます。\n最後は二級です。ja.luceneでは、数字と助数詞として分割されています。こちらも何かしらのロジックにより、二級という1単語でヒットできるように数字と単位?が合わせた単語で出てくる仕組みがja.microsoftなのかなと。\n2. UEFA U-18女子選手権2000 UEFA U-18女子選手権2000は第3回目のUEFA U-18女子選手権である。決勝トーナメントは2000年7月27日から8月4日までフランスで行われ、ドイツが初優勝を果たした。\nこの文字列から抽出された単語で特徴的なものを一部抜粋しました。\nja.microsoft ja.lucene u-18, u u 18, nn18 18 第3回目 第 3 回 目 トーナメント, トナメント トーナメント 2000年 2000 年 7月 7 月 27日 27 日 数字を含む単語第3回目や2000年、7月などは、ja.microsoftは先程と同様、数字と単位の組み合わせを1単語として出力しています。\nまた、トーナメントという単語をトナメントという形で、長音を除去した形で出力しています。 今回の文字列ではないですが、この他に、センターをセンターとセンタの2パターンの単語で出力するといったことを行っています。 ja.luceneの場合、単語の最後に長音がある場合だけセンタとして、長音を除去した単語が出力されます。 これは、長音の表記ゆれに対応するためではないかなと。たとえば、インターフェースとインタフェース、インターフェイスのように、人や文章によって、間にでてくる長音を使ったり使わなかったりという表記ゆれに対応するためだと思われます。 その他にも、イプロゥヴェトをイプロゥベトに、ネクストをネキストに、バラエティをバラエチにも変換するなどといった処理をしてくれるようです。カタカナの表記ゆれには強そうですね(これどうやってるんだろう?)。\nja.microsoftでは、nn18というちょっと変わった単語も出てきていました。純粋な数字の場合はnnと入力してくれるようで、数字だけで検索したい場合に利用できるのかな?これはドキュメントに書いておいてほしいかも?\n共通点 ja.lucene、ja.microsoftともに、共通している動作として、「てにをは」といった単語は除去されていました。違いがあるものとしては、「より」(助詞-格助詞-一般)、「されている」(動詞-自立、動詞-接尾、助詞-接続助詞、動詞-非自立)、「ある」(助動詞)といったものはja.microsoftでは除去されずに出てきていました。 ストップワード的に「てにをは」あたりを除去をしている感じでしょうか?\nアルファベットで構成されている単語についても、基本はそのまま出力される挙動のようでした。\nじゃあどっちがいいの? 残念ながらどちらがいいかは、一長一短かなぁと。 ja.luceneに関しては、Luceneの仕組みを利用しているので、Elasticsearchなどを使えば、個別の単語についてより詳細の情報を取得することが可能です(品詞、読みなど)。ja.microsoftについては、残念ながら手の入れようがないので、そういう動きのものだという割り切った使い方になるでしょうか? ただ、長音の除去による表記ゆれなどについては、便利な機能なので、そのあたりの問題に対応したい場合は、ja.microsoftを活用するのも良いかと思います。\n個人的には、より細かい単語としてインデックスに登録できるもののほうが、柔軟な検索には対応できるのではないかなぁと考えています(Kuromojiの辞書をUniDicにするとか?も考えますが、これはAzure Searchではできないですが)。\nまとめ Wikipediaのデータをいくつか使って、ja.microsoftとja.luceneの違いについて、考察してみました。何かの役に立てばと。 他に、これはどんな感じになるの?などありましたら、コメントいただければと。\n","date":1591692240,"dir":"post/2020/","id":"82a115ab8d617e4e96813587fe3a6049","lang":"ja","lastmod":1591692240,"permalink":"https://blog.johtani.info/blog/2020/06/09/difference-analyzers-in-azure-search/","publishdate":"2020-06-09T17:44:00+09:00","summary":"Azure Cognitive Searchで日本語を扱うときに、形態素解析器を使いたい場合、2種類のAnalyzerが用意されています。今回はこれらの違いがどんなもの","tags":["azure search","kuromoji"],"title":"Azure Cognitive Searchでの日本語向けAnalyzerの違い"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章 Rust the book - 第9章 Rust the book - 第10章 11章、12章はちょっと飛ばして、13章です。\n第13章 イテレータ、クロージャです。 12章の話もちょっと出てくるのか。\nクロージャ 基本的に、「変数には値が束縛されている」という固定観念がずっと頭にこびりついたままなので、クロージャに慣れないんだろうなぁ。そろそろこの固定概念をどうにかしないと。\n匿名関数で、変数に保存したり引数に渡せる ちょっと面白い話(ワークアウト)で実際に考えられる手法の説明がいくつか行われる 関数でリファクタリング これが自分がよくやるパターンかなぁ。クロージャになれてないので。。。 クロージャーを変数に束縛 呼び出しは関数みたいな感じ(ここで少し混乱) これだと、結局呼び出されたタイミングが複数回あるよね? -\u0026gt; あはりそうだった ここで、閑話休題で、クロージャの型推論とか注釈の話。 クロージャは狭い文脈だし、外に公開しているものでもないので、戻り値なども定義してなくてもいいよねとのこと。書くことも可能?なので、書いてわかりやすくするのもありなんだろうな。\n推論についてはこれまで通りで、2回異なる型の変数で呼び出すと、2回目で怒られていた。\n遅延評価(クロージャを保持する構造体!?) Fnトレイト トレイトとMatchの組み合わせだからこのへんで説明する形になるのか。 これを真似すれば、いくつか処理を簡素化できるかもしれないなぁ、たしかに。 なければ実行するみたいな処理を書きたいことがよくあるし。Javaだとnullで定義しといて、nullだったらみたいなのがあるから。 Cacherはサンプルだからこの名前でいいけど、自分だと、どんな名前にするかなぁ?\n振る舞いは難しくなるのか。Cacher実装の限界を読むと。\n関数にするとスコープが変わるのでアクセスできなくなると。。。コンパイラが教えてくれるのは便利だな。\n環境から値をキャプチャする3つの方法\n多分この話が一番クロージャに意味がある話なんだと思う。 イテレータ 回しましょう。\n便利。ただ、こういう書き方に自分が慣れてないので、そっちを補正しないとなぁ。 どれがイテレータ?っていうのを判別するのがちょっとむずかしい(慣れの問題かなぁ) イテレータアダプタ便利。どんなのがあるのか?とかがやっとわかってきた。 パフォーマンスに関しては、うーん、どうなんだろう?という感想だった。 ","date":1591259849,"dir":"post/2020/","id":"e74d071363645a588f858b35231128c4","lang":"ja","lastmod":1591259849,"permalink":"https://blog.johtani.info/blog/2020/06/04/chap13-rust-the-book/","publishdate":"2020-06-04T17:37:29+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第13章"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章 Rust the book - 第9章 第10章 ジェネリック、トレイト、ライフタイムです。 手強そう。\nいきなり関数の切り出し方みたいな話が始まって面食らいました。\nジェネリックなデータ型 ジェネリックはJavaにもあるので、それほど理解に苦しむことはなかったです。 また、OptionやResultですでに経験済みでしたし。\nただ、impl\u0026lt;T\u0026gt; Point\u0026lt;T\u0026gt;{、このメソッド定義は少し最初は戸惑いました。 言われてみれば、なるほどなんですけど。\nコンパイル時にコンパイラが単相化を行うことにより、必要最低限なコードを生成してくるというのは理にかなっているなぁと。\nトレイト: 共通の振る舞いを定義する 出だしにもありますが、「インターフェイス」という機能に類似していると考えると割とすんなりと理解が進みました。 ただ、Javaだと、インターフェースはクラスとセットなため、トレイとの実装に関する記述方法は少し戸惑いが。\nデフォルト実装との組み合わせはAbstractに似た処理になるなと考えながら読みすすめました。\n「トレイト境界」という日本語には少し違和感を覚えましたが、線引をして、制限をかけるという理解でいいのかな?\n実際には#[derive()]などで、トレイトを自分で実装する必要がないなどの、便利機能も用意されており、このあたりのコードの追い方がまだ少し慣れていないかもなぁと。便利なんですけど。。。\n少しだけ気になったので、動作確認したのは次の実装です。\nトレイトで宣言されている関数と構造体が独自に実装する関数の名前がかぶるとどうなるのかという実験です。 構造体独自のメソッドが優先される感じになりそう。\npub struct Tweet { pub username: String, pub content: String, pub reply: bool, pub retweet: bool, } pub trait Summary { fn summarize_author(\u0026amp;self) -\u0026gt; String; fn summarize(\u0026amp;self) -\u0026gt; String { // {}さんからもっと読む format!(\u0026#34;(Read more from {}...)\u0026#34;, self.summarize_author()) } } impl Tweet { fn summarize_author(\u0026amp;self) -\u0026gt; String { format!(\u0026#34;hoge {}\u0026#34;, self.username) } fn to_string(\u0026amp;self) -\u0026gt; String { format!(\u0026#34;fuga\u0026#34;) } } impl Summary for Tweet { fn summarize_author(\u0026amp;self) -\u0026gt; String { format!(\u0026#34;@{}\u0026#34;, self.username) } } pub fn summary\u0026lt;T: Summary\u0026gt;(hoge: \u0026amp;T) { println!(\u0026#34;{}\u0026#34;, hoge.summarize_author()); } pub fn main() { let tweet = Tweet { username: String::from(\u0026#34;horse_ebooks\u0026#34;), content: String::from(\u0026#34;of course, as you probably already know, people\u0026#34;), reply: false, retweet: false, }; println!(\u0026#34;{}\u0026#34;, tweet.summarize_author()); summary(\u0026amp;tweet); println!(\u0026#34;{}\u0026#34;, Summary::summarize_author(\u0026amp;tweet)); } ライフタイムで参照を有効化する 言われてみればそうですが、プログラマが色々考えないとまぁ、行けないんですねという感想。\nただ、借用チェッカーが賢くやってくれるおかげで、全てにライフタイム注釈をつけなくて良くなっているというのがわかりました。 逆に言うと、なんとなくRustを書き始めてしまったので、それを知らずに書いたせいで、コンパイラに怒られてても「?」となっていたのかと。。。\n疑問点がいくつかあって、\n通常はどんなライフタイム注釈をみんな書いてるんだろう?'aとかざっくりしすぎてる? 1つのメソッド、関数にライフタイム注釈が大量に出てくるような書き方をした場合は設計がおかしいのでは?って考えたほうがいいのかも? ジェネリックな型とライフタイム引数の順序を入れ替えてみても動くだろ?とおもって入れ替えてみたら怒られた。 あとは、構造体+ジェネリックが絡んできたら少しこんがらがってきそうっという感じです。 まぁ、これから先は実際に書いてみないことにはわからないんだろうなと。\nまとめ 読みました。 実際にはプログラムを書きながら慣れていく感じだろうなぁと。 まだまだ、あれ?ジェネリックってどう書くんだっけ?とか、ライフタイム注釈どうやって付けて、使うときはどうすんだ?みたいになりながら、 出てくるサンプルを少し変えてみてはどうやって動くんだろうこの場合?みたいなことをやってました。 次は、11章、12章を少しだけ自習しつつ、13章に入る予定です(知り合いと一緒に読みすすめてる)。\n","date":1590656815,"dir":"post/2020/","id":"163beeae9620c1a6a46a38aa7ebd9663","lang":"ja","lastmod":1590656815,"permalink":"https://blog.johtani.info/blog/2020/05/28/chap10-rust-the-book/","publishdate":"2020-05-28T18:06:55+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第10章"},{"contents":"今回はAzure Cognitive SearchのSDKを利用したアプリケーションが、実際にAzure Cognitive Searchに対して送信しているリクエストのパラメータとボディをログに保存する方法について紹介します。\n動機 アプリケーションでリクエストを組み立てて、SDK経由で送信していると、最終的にAzure Cognitive Searchに対して送信されているリクエストのパラメータや検索条件などをひと目で見たいことがあります。 アプリケーションでは、ソート条件や、クエリ文字列の組み立てなどの処理は異なる場所で行われたりしますので。\nまた、公式リファレンスでは、機能の説明はRest APIの使い方と組み合わせで説明されることが多いです。\nということで、SDKを利用しているアプリからAzure Searchへ送信されているリクエストをログに保存する方法を調べてみました。\n方法 調べてみるといくつかの手段を取ることができそうだとわかりました。実際に調べて実装する方法を4種類ほど試してみたのでブログに残しておきます。なお、2020年4月時点でのSDKとAzureの仕組みに基づいたブログになります。最新版ではお手軽な方法があるかもしれません。\nDelegatingHandlerを利用する ServiceClientTracingの機能を利用する Azure Application Insightsを活用する Azure Cognitive Searchのコンソールにある診断情報の機能を利用する 1、2はAzure Cognitive SearchのSDKのリファレンスから当たりを付けて見つけた方法です。 3はApplication Insights、4はAzure Cognitive Searchの機能になります。 これらの方法について個別に説明していきます。\n1. DelegatingHandleを利用する まずは、SDKでロギングの機能がないかを調べて見つけた機能がこちらです。 SDKのSearchServiceClientのコンストラクタの引数にDelegatingHandlerというものが渡せることを発見しました。\nこれは、.NET FrameworkのHttpのAPIに存在するクラスで、HTTPのクライアントがHTTPの送受信時に、処理を挟むことができる機能です。フレームワーク側で、LoggingHttpMessaggeHandlerというクラスを用意してくれていましたが、残念ながらこちらは、リクエストとレスポンスのヘッダのみをロギングするクラスでした。 ということで、リクエストボディをログに出力したい場合は独自に拡張してやる必要があります。なお、ロギングにはMicrosoft.Extensions.LoggingのILoggerを使用します。\nまた、Azure Cognitive SearchのSDK側に違う問題点もありました。チュートリアルにあるように、検索するときには、SDKは次のような使い方を想定しています。\n// Create a service and index client. _serviceClient = new SearchServiceClient(searchServiceName, new SearchCredentials(queryApiKey)); _indexClient = _serviceClient.Indexes.GetClient(\u0026#34;hotels\u0026#34;); インデックス用のクライアントを取得するために、GetClient(インデックス名)というメソッドを使用します。このGetClientメソッドのバリエーションとして、DelegatingHandlerを受け取るメソッドがないのです。。。\nということで、DelegationHandlerを活用する方法としては、以下の2つを実装する必要があります。\nCustomなLoggingHttpMessageHandlerクラスを実装 GetClientと同等の処理をDelegatingHandlerを引数にしたものを実装する 以上の2つを実装し、アプリケーション側から2で作成したGetClientを呼び出すことで、リクエストをボディも含めてログ出力することが可能になります。以下は実装例です。\nCustomHttpMessageHandlerクラス。\nusing System; using System.Collections.Generic; using System.Diagnostics; using System.Net.Http; using System.Net.Http.Headers; using System.Text; using System.Threading; using System.Threading.Tasks; using Microsoft.Extensions.Logging; namespace AzureSearchSample { public class CustomLoggingHttpMessageHandler : DelegatingHandler { private readonly ILogger _logger; private readonly bool _logContent = false; public CustomLoggingHttpMessageHandler(ILogger logger, bool logContent) { if (logger == null) { throw new ArgumentNullException(nameof(logger)); } this._logger = logger; this._logContent = logContent; } protected override async Task\u0026lt;HttpResponseMessage\u0026gt; SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) { if (request == null) { throw new ArgumentNullException(nameof(request)); } await Log.RequestStart(this._logger, request, this._logContent); var stopwatch = new Stopwatch(); HttpResponseMessage response = await base.SendAsync(request, cancellationToken).ConfigureAwait(false); stopwatch.Stop(); await Log.RequestEnd(this._logger, response, stopwatch.Elapsed); return response; } private static class Log { private static class EventIds { public static readonly EventId RequestStart = new EventId(100, \u0026#34;RequestStart\u0026#34;); public static readonly EventId RequestEnd = new EventId(101, \u0026#34;RequestEnd\u0026#34;); } public static async Task RequestStart(ILogger logger, HttpRequestMessage request, bool logContent) { StringBuilder message = new StringBuilder(); message.AppendLine($\u0026#34;Sending HTTP request {request.Method} {request.RequestUri}\u0026#34;); if (logger.IsEnabled(LogLevel.Trace)) { LogHttpHeaders(message, request.Headers); await LogHttpContent(message, request.Content, logContent); logger.Log( LogLevel.Trace, EventIds.RequestStart, message, null, (state, ex) =\u0026gt; state.ToString()); } } public static async Task RequestEnd(ILogger logger, HttpResponseMessage response, TimeSpan duration) { StringBuilder message = new StringBuilder(); message.AppendLine( $\u0026#34;Recieving HTTP response after {duration.TotalMilliseconds}ms - {response.StatusCode}\u0026#34;); if (logger.IsEnabled(LogLevel.Trace)) { LogHttpHeaders(message, response.Headers); await LogHttpContent(message, response.Content, false); logger.Log( LogLevel.Trace, EventIds.RequestEnd, message, null, (state, ex) =\u0026gt; state.ToString() ); } } private static void LogHttpHeaders(StringBuilder message, HttpHeaders headers) { if (headers == null) throw new ArgumentNullException(nameof(headers)); foreach (KeyValuePair\u0026lt;string, IEnumerable\u0026lt;string\u0026gt;\u0026gt; header in headers) { foreach (string value in header.Value) { message.AppendLine($\u0026#34;{header.Key}: {value}\u0026#34;); } } } private static async Task LogHttpContent(StringBuilder message, HttpContent content, bool logContent) { if (content != null) { foreach (KeyValuePair\u0026lt;string,IEnumerable\u0026lt;string\u0026gt;\u0026gt; header in content.Headers) { foreach (string value in header.Value) { message.AppendLine($\u0026#34;{header.Key}: {value}\u0026#34;); } } if (logContent) { string contentBody = await content.ReadAsStringAsync(); message.AppendLine(contentBody); } } } } } } GetClientの実装\nprivate ISearchIndexClient GetClient(string indexName, params DelegatingHandler[] handlers) { var rootHandler = _searchServiceClient.HttpMessageHandlers.OfType\u0026lt;HttpClientHandler\u0026gt;().SingleOrDefault(); var indexClient = new SearchIndexClient(_searchServiceClient.SearchServiceName, indexName, _searchServiceClient.SearchCredentials, rootHandler, handlers) { SearchDnsSuffix = _searchServiceClient.SearchDnsSuffix }; indexClient.HttpClient.Timeout = _searchServiceClient.HttpClient.Timeout; return indexClient; } 出力されるログ例\n2020/04/14 19:17:53.591|TRACE|Sending HTTP request POST https://サービス名.search.windows.net/indexes(\u0026#39;インデックス名\u0026#39;)/docs/search.post.search?api-version=2019-05-06 client-request-id: be02140f-3a07-48cc-b018-d8aa5e819bc3 Accept-Language: en-US Accept: application/json; odata.metadata=none api-key: APIキー User-Agent: FxVersion/4.700.20.11803 User-Agent: OSName/MacOs User-Agent: OSVersion/Darwin.19.4.0.Darwin.Kernel.Version.19.4.0.Wed.Mar.4.22.28.40.PST.2020.root.xnu.6153.101.6.15RELEASE.X86.64 User-Agent: Microsoft.Azure.Search.SearchIndexClient/10.100.19.52907 Content-Type: application/json; charset=utf-8 { \u0026#34;count\u0026#34;: false, \u0026#34;facets\u0026#34;: [], \u0026#34;queryType\u0026#34;: \u0026#34;simple\u0026#34;, \u0026#34;scoringParameters\u0026#34;: [], \u0026#34;search\u0026#34;: \u0026#34;azure\u0026#34;, \u0026#34;searchMode\u0026#34;: \u0026#34;any\u0026#34; } |AzureSearchSample.SearchService|EventId_Id=100, EventId_Name=RequestStart, EventId=RequestStart メリット、デメリット Azure Cognitive Searchの検索の処理だけを対象にリクエストのログを出力することが可能です。また、影響範囲はアプリケーションだけに閉じていますので、デバッグ目的などでログ出力したい場合に、自分だけの手元でログの確認が可能になります。\nデメリットとしては、独自に実装しなければいけない範囲が広いことです。\n2. ServiceClientTracingの機能を利用する Microsoft.Rest.ClientRuntimeというライブラリをAzure Cognitive Searchは利用しています。 このライブラリにServiceClientTracingというクラスが存在します。 なにやら、クライアントの処理のトレースができそうです。\nAzure Cognitive SearchのSDKの実装がGitHubに公開されており、検索リクエストの処理を投げる直前に、このトレースの仕組がONになっていると、ServiceClientTracing.SendRequestメソッドを呼び出していました。\n実際にSendRequestメソッドに送られたものに対して何かしらの処理を行うのは、IServiceClientTracingIntercepterインターフェースを実装したクラスになります。 このインターフェースの実装がLog4Netに存在します。Log4Netを利用している場合は、これを活用すれば楽ができます。\n実際にServiceClientTracingを有効にするには、以下の2行を呼び出すだけです。\nServiceClientTracing.IsEnabled = true; ServiceClientTracing.AddTracingInterceptor(new Log4NetTracingInterceptor()); あとは、Rest.ClientRuntimeがよしなにやってくれます。 1とは異なり、トレースログなので、リクエストのボディについても出力してくれます。\n2020-05-26 19:09:04,058 [1] DEBUG Microsoft.Rest.Tracing.Log4Net.Log4NetTracingInterceptor [(null)] - invocationId: 1 instance: Microsoft.Azure.Search.DocumentsProxyOperations method: SearchPost parameters: {searchRequest=Microsoft.Azure.Search.Models.SearchRequest,clientRequestId=,cancellationToken=System.Threading.CancellationToken} 2020-05-26 19:09:04,164 [1] DEBUG Microsoft.Rest.Tracing.Log4Net.Log4NetTracingInterceptor [(null)] - invocationId: 1 request: Method: POST, RequestUri: \u0026#39;https://サービス名.search.windows.net/indexes(\u0026#39;インデックス名\u0026#39;)/docs/search.post.search?api-version=2019-05-06\u0026#39;, Version: 2.0, Content: System.Net.Http.StringContent, Headers: { client-request-id: 591cb14f-e5c2-4a85-977d-01d1f6431ddc Accept-Language: en-US Accept: application/json; odata.metadata=none api-key: APIキー Content-Type: application/json; charset=utf-8 } Body: { { \u0026#34;count\u0026#34;: false, \u0026#34;facets\u0026#34;: [], \u0026#34;queryType\u0026#34;: \u0026#34;simple\u0026#34;, \u0026#34;scoringParameters\u0026#34;: [], \u0026#34;search\u0026#34;: \u0026#34;azure\u0026#34;, \u0026#34;searchMode\u0026#34;: \u0026#34;any\u0026#34; } } 2020-05-26 19:09:04,459 [Thread Pool Worker] DEBUG Microsoft.Rest.Tracing.Log4Net.Log4NetTracingInterceptor [(null)] - invocationId: 1 response: StatusCode: 200, ReasonPhrase: \u0026#39;OK\u0026#39;, Version: 1.1, Content: System.Net.Http.StreamContent, Headers: { Cache-Control: no-cache Pragma: no-cache request-id: 591cb14f-e5c2-4a85-977d-01d1f6431ddc elapsed-time: 72 OData-Version: 4.0 Preference-Applied: odata.include-annotations=\u0026#34;*\u0026#34; Strict-Transport-Security: max-age=15724800; includeSubDomains Date: Tue, 26 May 2020 10:09:04 GMT Content-Type: application/json; odata.metadata=none Expires: -1 Content-Length: 376 } メリット、デメリット Log4Netを利用しているアプリの場合、2行だけを追加することで実装が完了するのがお手軽な点です。\n難点としては、Rest Client全てにたいしてトレース処理が入ってしまうので、Azure Cognitive Search以外にもRestクライアントを利用しているものが存在した場合、ログの量が増えてしまいます。また、検索以外の処理でもトレースされてしまうのもデメリットになります。\nLog4Net以外のログ機構を使用している場合は、自分でIServiceClientTracingInterceptorを実装する必要も出てきます(参考:StackOverflow)。\n3. Azure Application Insightsを活用する ここから紹介する3と4については、ログの出力先がAzure上になります。\nAzureのApplication Insightsを利用する方法です。 Azure?.NET?のアプリケーションパフォーマンスモニタリングのサービスです。\nApplication Insightsを自分のアプリケーションに設定することで、アプリケーションのパフォーマンス監視に関する情報がAzure上のApplication Insightsリソースに送信されるようになります。\nただ、Application Insightsのデフォルトの機能では、URL程度の情報だけが送信されます(参考:しばやんさんのブログ)\nこちらも拡張機能が用意されており、ITelemetryInitializerのインターフェースを実装したクラスを用意することで、独自の情報をApplication Insightsに出力することが可能となります。詳細についてはしばやんさんのブログを参考にしてもらうのが良いかと。\nHttpリクエストを出力する実装例は次のとおりです。ただ、ちょっとうまく行かないパターンがあったので、コメントアウトとして残してあったりします(なんでだろう?)\nusing System.Collections.Generic; using System.Net.Http; using System.Net.Http.Headers; using Microsoft.ApplicationInsights.Channel; using Microsoft.ApplicationInsights.DataContracts; using Microsoft.ApplicationInsights.Extensibility; namespace AzureSearchWebSample.ApplicationInsights { public class HttpRequestInitializer : ITelemetryInitializer { public void Initialize(ITelemetry telemetry) { if (!(telemetry is DependencyTelemetry dependency)) { return; } HttpRequestMessage requestMessage = null; HttpRequestHeaders requestHeaders; if (dependency.TryGetOperationDetail(\u0026#34;HttpRequest\u0026#34;, out var details) \u0026amp;\u0026amp; details is HttpRequestMessage request) { requestMessage = request; requestHeaders = request.Headers; if (requestMessage.Method == HttpMethod.Post) { string contentBody = requestMessage.Content.ReadAsStringAsync().GetAwaiter().GetResult(); dependency.Properties.Add(\u0026#34;RequestBody\u0026#34;,contentBody); } } else if (dependency.TryGetOperationDetail(\u0026#34;HttpRequestHeaders\u0026#34;, out details) \u0026amp;\u0026amp; details is HttpRequestHeaders headers) { requestHeaders = headers; } else { return; } foreach (KeyValuePair\u0026lt;string,IEnumerable\u0026lt;string\u0026gt;\u0026gt; header in requestHeaders) { foreach (string value in header.Value) { dependency.Properties.Add(header.Key, value); } } //この実装の場合は出力されなかった。なぜ? // if (requestMessage != null \u0026amp;\u0026amp; requestMessage.Method == HttpMethod.Post) // { // string contentBody = requestMessage.Content.ReadAsStringAsync().GetAwaiter().GetResult(); // dependency.Properties.Add(\u0026#34;RequestBody\u0026#34;,contentBody); // } } } } メリット、デメリット すでにApplication Insightsを利用している場合はついでに情報が出力されるので便利です。かつ、常にリクエストログを見れるようにしておく場合はとても便利だと思います。\nApplication Insightsを利用していない場合は、そこから導入しなければならなくなるので、手間が増えるかもしれないです。\n4. Azure Cognitive Searchのコンソールにある診断情報の機能を利用する。 最後はAzure Cognitive Searchの診断ログを有効にする方法です。 ここまで説明してきた方法の中で、一番お手軽な方法です。。。\nこれまでは、リクエストボディを出力する方法を考えていましたが、Azure Cognitive Search側の診断ログを有効にすると、リクエストボディで送信したものが、Azure Cognitive Search側で、クエリパラーメータとして、診断ログに出力されます(診断ログのQuery_s)。\nあとは、Azureのコンソールで当該時間のログを見ればよいだけです。以下は出力されたログの一部です。Description_sにはURLのパスが記載されています。\n診断ログ例(一部)\nDescription_s POST /indexes(\u0026#39;multi-field-test\u0026#39;)/docs/search.post.search Query_s ?api-version=2019-05-06\u0026amp;searchMode=Any\u0026amp;search=azure\u0026amp;queryType=Simple\u0026amp;$count=false メリット、デメリット アプリケーション側に手を入れる必要がなのでお手軽です。 一度設定しておけばコンソール側でログをいつでも見れるので便利です。\nリクエスト量が多くなってしまうと、ログの量も多くなり、費用がかさむ恐れがあります。また、複数の人が触る環境の場合は自分で送信したリクエストがどれだったのか?といった状況に陥る可能性はあります。\nその他は? Azureに対してではないですが、昔似たようなことをやるときにやっていた方法として、ローカルにプロキシサーバーを起動し、そのプロキシサーバー経由でアプリケーションから、Azureに接続することで、リクエストを保存する方法もあります。 ざんねんながら、未調査ですがアプリなどにはそれほど手を入れる必要はないかと思います。\nまとめ ちょっと送信リクエストの内容が見てみたいという話でしたが、いろいろな手段が存在しました。 自分の状況、環境に合わせて手段を選択肢てみるのがいいかと思います。 まずは、簡単な診断ログあたりからでしょうか?\n","date":1590481367,"dir":"post/2020/","id":"36dd94159e3e60076c0c6098086e255f","lang":"ja","lastmod":1590481367,"permalink":"https://blog.johtani.info/blog/2020/05/26/logging-azure-search-request/","publishdate":"2020-05-26T17:22:47+09:00","summary":"今回はAzure Cognitive SearchのSDKを利用したアプリケーションが、実際にAzure Cognitive Searchに対して送信しているリクエストのパラメータ","tags":["azure search",".net"],"title":"Azure Cognitive Searchのリクエストのロギング"},{"contents":"Mircosoft Buildというイベントが今週ありました(MSの方やお客さんに教えてもらった)。\nそこで、Azure Cognitive Searchのセッション(MyBuild - Cognitive Search： The pocket-knife for knowledge mining)があったので、見てみました。 内容がどんなものかをメモっておきます。 最初はCognitive Searchがどんなものよという説明でした。\nビルトインスキルの拡充の話 データソースからデータを取り出し、エンリッチし、検索エンジンに保存するという、パイプラインが組めるようになっています。\nこのパイプラインで利用できる処理のことがスキルと呼ばれています。ここで利用できるビルトインスキルが拡充されますよという話でした。ちょっとだけ抜き出すと以下のとおりです。\nAzure Machine Learning Text translation Brand detection Object detection スキルのリファレンスには載ってるものと載ってないものがあるので、今後追加されてくのかな? Brand detectionがどんなものなんだろう?ってのがちょっと気になりました。どっかにデモとかあるかなぁ?\nスキルセットのための新機能 : Debug Sessionのデモ 上記のスキルを組み合わせてパイプラインを組んで、データソースから取り出したデータをエンリッチしてから、検索エンジンに入れる処理をかけるのですが、その処理のデバッグ用に新しいGUIの機能が追加されてますよという紹介とデモでした。\nTutorial： Use Debug sessions to diagnose, fix, and commit changes to your skillset - Azure Cognitive Search | Microsoft Docs Manage Identityの話 Azure Cognitive Searchにデータを登録するパイプランの最初の段階で、各種データソースにアクセスが必要です。 このアクセス時にコネクションの設定にアカウントキーなども含めてましたが、これをコネクション設定ではなく、専用の管理機能が用意されましたよという話でした。\nSet up a connection to a data source using a managed identity (preview) - Azure Cognitive Search | Microsoft Docs QA Similarityとかの話 BM25になってるよとか SDKの話とか ほかにRelevancyの話 Analyzerをデフォルトのままじゃなくてちゃんと考えて使いましょう(例:各言語用のAnalyzerがいっぱいあるよとか) こんな感じでした。\n","date":1590117041,"dir":"post/2020/","id":"21982f43bc435f22efef22b309a48c66","lang":"ja","lastmod":1590117041,"permalink":"https://blog.johtani.info/blog/2020/05/22/watching-azure-cognirive-search-session-at-ms-build/","publishdate":"2020-05-22T12:10:41+09:00","summary":"Mircosoft Buildというイベントが今週ありました(MSの方やお客さんに教えてもらった)。 そこで、Azure Cognitive Searchのセッション(MyBuil","tags":["azure search"],"title":"Microsoft Build(2020)のAzure Cognirive Searchのセッションを見たのでメモ"},{"contents":"ElasticのWorkplace Searchを触ってみています(その1、その2)が、Elastic Stackの7.7.0がリリースされてしまいました。\n簡単ですが、リリースブログを見ながら気になった点をメモしとこうかと。\n本家のリリースブログ いっぱいあるんですよ、これが。まぁ、内容かぶってるのもあるんですが。\nElastic Stack Elastic Stack 7.7.0をリリース Elasticsearch 7.7.0 released Kibana 7.7.0 released Logstash 7.7.0 released Enterprise Search系 Elastic Enterprise Search 7.7 released, featuring Workplace Search GA | Elastic Blog Elastic App Search updates： Scale your way with new configuration options | Elastic Blog Elastic Workplace Search： 新しい、統合された働き方へ Observability系 Elastic Observability 7.7 released | Elastic Blog\nElastic APM 7.7.0 released with service maps, async profiler, and more | Elastic Blog\nElastic Logs 7.7.0 released with PCF support, MQTT support, and more | Elastic Blog\nElastic Metrics 7.7.0 released with enhanced Prometheus integration and PCF support, | Elastic Blog\nElastic Uptime Monitoring 7.7.0 released with alerting, anomaly detection and more | Elastic Blog\nNew alerting framework released for Observability, Security and the Elastic Stack | Elastic Blog\nIntroducing Elastic Security 7.7.0 | Elastic Blog\n個人的に気になったもの で、全部読んだわけではないのですが、個人的に気になった機能についてメモを残しておきます。 多分に検索によっている可能性がありますが、お気になさらず。 また、ブログとドキュメントを元に気になるところをピックアップしてます。 実際の実装とか動作に関してはまだ未調査の段階です。\nAsync Search - Elasticsearch ElasticsearchのAPIとして非同期に検索できるAPIが実装されました (公式リファレンス)。 大量データを検索が終了してから検索結果を返すのではなく、クエリは実行しつつわかったところまでは都度取得したいという要望だったり、Coldインデックスのように遅いストレージ上にあるデータへの検索でも少しずつ取得できるようにという具合だと思います。ログとか大量に扱う場合にまぁ、ほしいですよね。今回はEsのリリースがメインで、今後はKibanaなどとの連携だったり色々改善していくよという話みたいです(Kibanaの一部の機能は利用しているみたい)。\nライセンスとサブスクリプションのレベル Elastic License Basic 気になるところ(と、予想とか) 仕組みがどうなっているか? Search APIと同等のリクエストパラメータが使える。が、いくつか制約はありそう おそらくTask Manageerで検索してる処理が管理され、レスポンスにはIDが発行されて、そのIDで処理の進み具合を取得する感じ。 Shard単位?Segment単位? 内部的にはShard単位で検索処理を扱ってるので、Shard単位がとりあえず楽そう? Aggsとかも? 対象の模様 Sortは? 有効。ソートのフィールドがインデックス対象だった場合は、そのデータの統計値を使ってShardをソートするっぽい(公式リファレンスのNOTE参照) 関連しそうなGitHubのIssuesとか まだ読んでない\nAsync search · Issue #49091 · elastic/elasticsearch Add a listener to track the progress of a search request locally by jimczi · Pull Request #49471 · elastic/elasticsearch Pre-sort shards based on the max/min value of the primary sort field by jimczi · Pull Request #49092 · elastic/elasticsearch Async search： store intermediate results · Issue #55464 · elastic/elasticsearch Reduced consumption of heap - Elasticsearch ヒープの使用量が7.7で減ってるよというブログも別途ありました。\n元になっているLuceneの実装に関するIssueが「［LUCENE-8635］ Lazy loading Lucene FST offheap using mmap - ASF JIRA」です。ヒープ上に展開していたデータをmmapで扱えるようにすることで、ヒープのメモリを削減してる。\nで関連して、これがLuceneで操作できるようになって(「Use reader attributes to control term dict memory useage by s1monw · Pull Request #42838 · elastic/elasticsearch」)、そこからEsに取り込まれたと。\n_idをoff-heapにする話は[ここ](Move the terms index of _id off-heap. by jpountz · Pull Request #52405 · elastic/elasticsearch)にあった。\nこれに関連して、ヒープサイズの推奨について再考が必要かも?というIssue(Reconsider our recommendations for heap size? · Issue #52561 · elastic/elasticsearch)も上がってる。\nPainless Lab - Kibana ほんとにPainless?と言う話はさておき、_script APIでexecuteはできていましたが、やはりもう少し楽に実行したいですよね?ということで画面ができたみたいです。\nシンタックスハイライトとかもできるので、より簡単に使えるようになってますね。 まだ、ベータなので足りないContextとかもあるっぽいけど。\nライセンスとサブスクリプションのレベル Elastic License Basic? まだベータだからか、サブスクリプションのページにはなかった。 公式ドキュメントとGitHubのリポジトリから、Elastic Licenseであることは判明。\n気になるところ(と、予想とか?) 制限事項がどんなものか? 使えるContextがまだ少ない?まだGAではない サジェストがどのくらい効くのか? シンタックスハイライトはあるけど。まだかなぁ? その他Elasticsearch関連 7.7リリースのハイライトが別途用意されています。\n7.7.0 release highlights | Elasticsearch Reference ［7.7］ | Elastic こっちで気になるのは、ClassificationとかTransformsあたりかなぁ。ML関連の機能で。\nWorkplace Search GA これは別のブログに書くかな。\n気になるところ Betaと何が変わったのか? APIとかどういう形で提供されるのか?そもそも提供されるのか? どんな機能?みたいなのも書く予定です。\nData VisualizerでFilebeatのConfigをサジェスト - Kibana and Filebeat Kibanaの画面からデータをちょっと?(100MB)だけアップロードして、Elasticsearchにサクッとデータ登録できる機能が実はあります。この機能の拡張として、Filebeatの設定だとこんな感じに作れるよ?というのを提示してくれるようになったみたいです。 手元にあるファイルを定期的に読み込むときに、設定を書く下地ができるのは便利じゃないかな?\nライセンスとサブスクリプションのレベル Elastic License Basic Data Visualizerってどんなもの?というのはここにブログがあります。残念ながらKibanaとかの公式リファレンスには使い方のページがないんだよなぁ。\nAPMのサービスマップ - APM and Kibana アプリケーションアーキテクチャのどこでAPMが動作しているか、どこと通信しているかという、APMのエージェントが入っているアプリ間のつながりをKibana上で可視化できる機能っぽいです。まだ、ベータみたいですが、面白そう。Azure Application Insightのアプリケーションマップに似てる気がします。\nライセンスとサブスクリプションのレベル Elastic License Platinum 気になるところ どうやって作ってる(つながりをどうやて判断してる)のか? 分散トレーシングのデータを元に誰がどこと通信してるってのは取れるんじゃなかろうか? Log categorization and contextual examples - Kibana and Elasticsearch 7.6から入ってたっぽいですが、ログの分類をMLの機能を使ってできるものが、LogsのUIとかでさらに使いやすくなった模様。\nライセンスとサブスクリプションのレベル Elastic License Platinum 気になるところ 7.6の機能から追いかけないとなぁ。。。 似たようなログをカテゴリーごとに分析できるようになるので、プラスMLの仕組みでこれまでとは異なる種類のログが出始めたみたいなことが分析できそう。 まとめ 眺めるだけで時間かかりましたが、まぁ、相変わらずいっぱいありますね。 興味のあるところの濃淡が出た感じになりましたが、気になる点をピックアップしてみました。 おかしなところとか、ここはどういう意味?などあればツッコミお願いします。\n","date":1589509037,"dir":"post/2020/","id":"306cecb32320ead508346ad8fed3394d","lang":"ja","lastmod":1589509037,"permalink":"https://blog.johtani.info/blog/2020/05/15/elastic-stack-7_7/","publishdate":"2020-05-15T11:17:17+09:00","summary":"ElasticのWorkplace Searchを触ってみています(その1、その2)が、Elastic Stackの7.7.0がリリースされてし","tags":["elastic stack"],"title":"Elastic Stack 7.7がリリースされた"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章 第9章 エラー処理です。 NLP100とか、いくつかのプログラムを書いていて、なんとなくは扱っていますが、きちんと勉強しないと。\nとりあえず、「Rustには例外は存在しません。」が一番知っておくことかな。\npanic!で回復不能なエラー panic!マクロでスタックを巻き戻して掃除をして終了。 異常終了(panic = 'abort')にもできる。 「RUST_BACKTRACEを0以外の変数にセットして実行」 * Resultで回復可能なエラー expect()は気持ち悪い名前じゃないかなぁ? ここでio::Errorではないものもエラーが発生する場合には panic!すべきかするまいか まとめ 「Rustには例外は存在しない」ので、回復不能か可能かを考えつつ処理を書こうと。\n","date":1589449406,"dir":"post/2020/","id":"1e220a934e16fd941bd804ca03865b60","lang":"ja","lastmod":1589449406,"permalink":"https://blog.johtani.info/blog/2020/05/14/chap9-rust-the-book/","publishdate":"2020-05-14T18:43:26+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第9章"},{"contents":"Rustで言語処理100本ノックの第2章の残りです。\n前回はこちら。\nちなみに、標準入力から受け取る処理は書いてないです。 出力に関してはファイル分割、保存と支持があるもの以外は文字列として取り出すところで終わっています。\n12. 1列目をcol1.txtに，2列目をcol2.txtに保存 pub fn extract_column(input_file_name: \u0026amp;str, num: usize, output_file_name: \u0026amp;str) { let input_f = File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;); let read_buf = BufReader::new(input_f); let mut output_f = OpenOptions::new() .write(true) .create(true) .open(output_file_name) .expect(format!(\u0026#34;can\u0026#39;t open file[{}] with write option\u0026#34;, output_file_name).as_str()); read_buf.lines().for_each(|line| match line { Ok(line) =\u0026gt; { let columns: Vec\u0026lt;_\u0026gt; = line.split(\u0026#39;\\t\u0026#39;).collect(); writeln!(output_f, \u0026#34;{}\u0026#34;, columns[num]); output_f.flush().expect(\u0026#34;Error during flush\u0026#34;); } Err(_) =\u0026gt; panic!(\u0026#34;parse error \u0026#34;), }); } 13で出力結果を利用するので入力として出力ファイル名も受け取るようにしました。 問題としては、1列目と2列目を別々に出力すればいいので、1回の処理で書いても良かったのですが、1回1ファイルの出力という形で実装しました(効率は悪い)。\n改行コードあたりを考えるのがめんどくさかったのでwriteln!マクロでファイルに書き出しています。が、普通にwriteメソッドで改行コードを追加しても良かったのかなと。\nあとは、出力先ファイルが存在しない場合だけopenするようにOpenOptionsを利用してみています。\nflushを呼び出すべきなのかどうか?を調べないとな。。。\n13. col1.txtとcol2.txtをマージ pub fn merge_files(col1_file: \u0026amp;str, col2_file: \u0026amp;str, output_file_name: \u0026amp;str) { let col1_buf = BufReader::new(File::open(col1_file).expect(\u0026#34;file not found\u0026#34;)); let col2_buf = BufReader::new(File::open(col2_file).expect(\u0026#34;file not found\u0026#34;)); let mut output_f = OpenOptions::new() .write(true) .create(true) .open(output_file_name) .expect(format!(\u0026#34;can\u0026#39;t open file[{}] with write option\u0026#34;, output_file_name).as_str()); col1_buf .lines() .zip(col2_buf.lines()) .for_each(|(col1, col2)| { let col1 = col1.expect(\u0026#34;parse error col1\u0026#34;); let col2 = col2.expect(\u0026#34;parse error col2\u0026#34;); writeln!(output_f, \u0026#34;{}\\t{}\u0026#34;, col1, col2); output_f.flush().expect(\u0026#34;Error during flush\u0026#34;); }); } 2つのファイル名を入力として受け取り、タブでくっつけて出力します。 zipを利用することで、2つのイテレーターを同時に回しています。\n14. 先頭からN行を出力 pub fn head(input_file_name: \u0026amp;str, lines: usize) -\u0026gt; String { let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); let mut head = String::new(); buf.lines().take(lines).for_each(|line| { head.push_str(format!(\u0026#34;{}\\n\u0026#34;, line.expect(\u0026#34;parse error\u0026#34;)).as_str()); }); return head; } イテレーターのメソッドにtakeがあります。 これを利用することで、引数に指定した数のエレメントが取得できるので、これでheadが実現できます。\n15. 末尾のN行を出力 pub fn tail(input_file_name: \u0026amp;str, lines: usize) -\u0026gt; String { let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); let mut tail = String::new(); let line_count = word_count(input_file_name); buf.lines().skip(line_count - lines).for_each(|line| { tail.push_str(format!(\u0026#34;{}\\n\u0026#34;, line.expect(\u0026#34;parse error\u0026#34;)).as_str()); }); return tail; } tailの場合は少し複雑で、11で作成した行数をカウントするメソッドで総行数を取り出し、そこから引数で指定された行数を引き算した数(=出力しない行数)を、イテレーターのskipメソッドの引数に渡しています。これにより、指定された数のエレメントをスキップしたあとの処理がかけます。\n16. ファイルをN分割する pub fn split_files( input_file_name: \u0026amp;str, num: usize, output_file_prefix: \u0026amp;str, output_file_suffix: \u0026amp;str, ) { let total = word_count(input_file_name) as f64; let lines_in_file = total / num as f64; let lines_in_file = lines_in_file.ceil() as usize; // let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); let output_files: Vec\u0026lt;File\u0026gt; = create_file_vec(output_file_prefix, num, output_file_suffix); println!(\u0026#34;split file each {} lines.\u0026#34;, lines_in_file); let mut lines = buf.lines(); for mut output_f in output_files { let mut current = 1; while current \u0026lt; lines_in_file + 1 { let line = lines.next(); if let Some(line_rs) = line { if let Ok(line_str) = line_rs { writeln!(output_f, \u0026#34;{}\u0026#34;, line_str); } } current = current + 1; } output_f.flush().expect(\u0026#34;error during flush\u0026#34;); } } fn create_file_vec(output_file_prefix: \u0026amp;str, num: usize, output_file_suffix: \u0026amp;str) -\u0026gt; Vec\u0026lt;File\u0026gt; { let mut files = Vec::with_capacity(num); for i in 0..num { let output_file_name = format!(\u0026#34;{}{}{}\u0026#34;, output_file_prefix, i + 1, output_file_suffix); let output_f = OpenOptions::new() .write(true) .create(true) .open(output_file_name.as_str()) .expect(format!(\u0026#34;can\u0026#39;t open file[{}] with write option\u0026#34;, output_file_name).as_str()); files.push(output_f); } return files; } ちょっと長いですね。\n入力としては、分割するファイル数Nが指定されます。まずは、総行数/Nで各ファイルに保存されるべき行数を計算します。 次に、2つ目の関数をつかって、必要な数のファイルオブジェクトをベクトルとして生成します。\nファイルオブジェクトのベクトルの要素を元にしたfor文を回しつつ、それぞれのファイルに必要な行数を出力している処理になっています。\n総行数がNで割り切れない場合にceilで切り上げした行数にするというちょっとした処理を入れてあります。\n17. １列目の文字列の異なり pub fn count_uniq_words(input_file_name: \u0026amp;str, col: usize) -\u0026gt; usize { let mut words = HashSet::new(); let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); buf.lines().for_each(|line| match line { Ok(line_str) =\u0026gt; { let columns: Vec\u0026lt;_\u0026gt; = line_str.split(\u0026#39;\\t\u0026#39;).collect(); words.insert(columns[col].to_string()); } Err(_) =\u0026gt; panic!(\u0026#34;parse error \u0026#34;), }); return words.len(); } HashSetを利用することでユニーク性を担保して、最後はHashSetの数を数え上げれば終了です。\n18. 各行を3コラム目の数値の降順にソート pub fn sort_on_col3(input_file_name: \u0026amp;str) -\u0026gt; String { let mut lines: BTreeSet\u0026lt;Line\u0026gt; = BTreeSet::new(); let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); buf.lines().for_each(|line| match line { Ok(line_str) =\u0026gt; { let columns: Vec\u0026lt;_\u0026gt; = line_str.split(\u0026#39;\\t\u0026#39;).collect(); let num: u32 = columns[2].parse().expect(\u0026#34;parse error\u0026#34;); let line = Line { line: line_str, num, }; lines.insert(line); } Err(_) =\u0026gt; panic!(\u0026#34;parse error\u0026#34;), }); let mut sorted = String::new(); lines.iter().for_each(|line| { sorted.push_str(format!(\u0026#34;{}\\n\u0026#34;, line.line).as_str()); }); return sorted; } #[derive(Eq)] struct Line { line: String, num: u32, } impl Ord for Line { fn cmp(\u0026amp;self, other: \u0026amp;Self) -\u0026gt; Ordering { let ord = other.num.cmp(\u0026amp;self.num); if let Ordering::Equal = ord { other.line.cmp(\u0026amp;self.line) } else { ord } } } impl PartialOrd for Line { fn partial_cmp(\u0026amp;self, other: \u0026amp;Self) -\u0026gt; Option\u0026lt;Ordering\u0026gt; { Some(self.cmp(other)) } } impl PartialEq for Line { fn eq(\u0026amp;self, other: \u0026amp;Self) -\u0026gt; bool { self.eq(other) } } Lineという、行の文章と第3カラム目の値をもった構造体を作成しました。そこにEq、Ord、PartialOrd、PartialEqを実装し、3カラム目での大小比較できるようにしました。 この構造体をBTeeSetに格納していき、イテレーターで回すことで、ソートされた状態にしてあります。 同一数値の場合は行の降順でソートできるようにOrdを実装してあります。\n19. 各行の1コラム目の文字列の出現頻度を求め，出現頻度の高い順に並べる pub fn sort_on_frequency(input_file_name: \u0026amp;str) -\u0026gt; String { let mut names: HashMap\u0026lt;String, u32\u0026gt; = HashMap::new(); let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); buf.lines().for_each(|line| match line { Ok(line_str) =\u0026gt; { let columns: Vec\u0026lt;_\u0026gt; = line_str.split(\u0026#39;\\t\u0026#39;).collect(); let name_str = columns[0].to_string(); let count = names.entry(name_str).or_insert(0); *count += 1; } Err(_) =\u0026gt; panic!(\u0026#34;parse error\u0026#34;), }); let mut sorted = String::new(); let mut sorted_names: Vec\u0026lt;(\u0026amp;String, \u0026amp;u32)\u0026gt; = names.iter().collect(); sorted_names.sort_by(|(aname, acount), (bname, bcount)| { let ord = bcount.cmp(acount); if let Ordering::Equal = ord { bname.cmp(aname) } else { ord } }); sorted_names.iter().for_each(|(name, count)| { sorted.push_str(format!(\u0026#34;{} {}\\n\u0026#34;, count, name).as_str()); }); return sorted; } もうすこしうまくできる気がしますが、いったんこれで。 数え上げのためにまずはHashMapに第1カラムの文字列, 個数という組み合わせでデータを入れていきます。 出来上がったHashMapをタプルのベクターに変換し、変換したベクターのsort_byメソッドに比較用の関数を渡すことで個数の降順に並べています。同一個数の場合は文字列の降順になっています。 で、最後に並びかわったベクターのイテレーターを使って出力しておしまいです。 内部的には最悪3回回る感じでしょうか? 最初からベクトルに入れつつソートできる仕組みにするようなのがいいのかなぁ?\nまとめ Unixコマンドの勉強になりましたw あとは、HashMapなどの勉強にもなりました。 最後の方は効率がいまいち良くない気もしてはいますが、とりあえず第3章に進もうかと思います。\n","date":1589253809,"dir":"post/2020/","id":"09155bf417a93847b538ad607f78cca2","lang":"ja","lastmod":1589253809,"permalink":"https://blog.johtani.info/blog/2020/05/12/reboot-nlp100-ch02-12to19/","publishdate":"2020-05-12T12:23:29+09:00","summary":"Rustで言語処理100本ノックの第2章の残りです。 前回はこちら。 ちなみに、標準入力から受け取る処理は書いてないです。 出力に関してはファイル","tags":["Rust","nlp100"],"title":"第2章の12から19まで(言語処理100本ノック2020)"},{"contents":"気づいたら1ヶ月サボってました、ごめんなさい。。。\nRustで言語処理100本ノックの第2章をはじめました。\n前回はこちら。\n確認用のUnixコマンド 確認用のファイルを先に生成して置きました。 これで、Rustでコードを書いて、作成済みの確認ファイルを元にassert_eq!でチェックするという方式を取ろうかと。\nで、コマンド群はこちらです。\nUnix/Linuxコマンド、昔から使っています。が、なにかちょっとした文字列処理やファイル処理をやるときは、Javaのプログラム(最近だとPython)を書くというのが基本になってるので、結構、使ったことの無いコマンドが今回ありました。使ったことがなかったのはこちらです。\nsed tr expand paste cut split sedとかは普通さわってるだろ?って思われそうですね。。。\nで、コマンドをmanで調べつつやりました、macOS上で。 これがまたいくつか罠があったので書き残しておきます(自分が知らないだけかもしれないので、おかしいところがあったらツッコミお願いします。)。\nsedコマンドでのタブの扱い ## sed command for macOS. If using Linux, use \u0026#34;\\t\u0026#34; for tab character cat $INPUT_FILE_NAME | sed -e \u0026#39;s/\t/ /g\u0026#39; \u0026gt; $OUTPUT_DIR/11_sed.txt \\tで行けると思ったのですが、うまく動きませんでした。\u0026lt;tab\u0026gt;みたいな書き方もあると思うのですが、これも駄目で、結局タブ文字をそのまま打ち込みました。。。 これ、めんどくさくないですか??? ちなみに、ターミナルで動作確認して、GitHubにあげてあるシェルファイルにコピペしてたのですが、CLionに貼り付けたらタブ文字がスペースに変換されてしまってて20分くらい悩みました。。。\nsplitコマンドに-nオプションがない LINES=`cat $OUTPUT_DIR/10.txt` SPLIT_LINES=`echo $LINES/$N | bc` split -a 1 -l $SPLIT_LINES $INPUT_FILE_NAME $OUTPUT_DIR/16_ splitコマンドについてググると、-nで指定した数のファイルに分割できるという記事がいくつも出てくるのですが、man splitをターミナル上でやるとそんなオプションがないと。。。 macOSがBSD系だからっぽいです。 ということで、行数を元に、指定した数(N)で行数を割ってから、指定行数ごとにファイルを分割する方式にしました。\nこれらのコマンドの違いはHomebrewとかでインストールするとなくなるのかなぁ?(めんどくさいので確認してないですが。。。)\nってことで、2章のそれぞれの課題の正解ファイルの生成はこれでできたはずです。\n10. 行数のカウント wc -lですね。\n// ch02-10 行数のカウント pub fn word_count(file_name: \u0026amp;str) -\u0026gt; usize { let f = File::open(file_name).expect(\u0026#34;file not found\u0026#34;); let buf = BufReader::new(f); return buf.lines().count(); } ファイルを読み込んで行数を数えます。 文字列として読み込んで改行コードの数を数えるというのもありかな?と思いましたが、RustのBufReaderにlines()という行のイテレータ?が取れることがわかったので、それでカウントを取りました。\n11. タブをスペースに置換 // ch02-11 タブをスペースに置換 pub fn tab_2_space(file_name: \u0026amp;str) -\u0026gt; String { let mut f = File::open(file_name).expect(\u0026#34;file not found\u0026#34;); let mut contents= String::new(); f.read_to_string(\u0026amp;mut contents).expect(\u0026#34;read error\u0026#34;); return contents.replace(\u0026#34;\\t\u0026#34;, \u0026#34; \u0026#34;); } こっちはファイル全体を文字列に読み込んでしまってから、文字列のreplaceで置換するという方式です。 ファイルが大きい場合にこれでいいのか?という問題がある気がしますが、まずはこの実装にしました。 やるとしたら、readメソッドとbufferを用意して、少しずつ読みながら、置換して吐き出す感じでしょうか? ちゃんとした文字コードの区切りで取れるかどうかを気にしないと行けないと思うので、思ったよりはめんどくさくなりそう。\nBufReaderをつかってread_lineのほうがましかも?\nまとめ ということで、サボっていたのを再開しました。 Rustのコードを書く前に、Unixコマンドの処理に結構悩みましたw\nRustのコードとしてはファイル処理なので、今後も役立つ気がしてます。 ということで、頑張っていくぞと。\n","date":1588948640,"dir":"post/2020/","id":"c098c6f0901979bd914ed7a345200f90","lang":"ja","lastmod":1588948640,"permalink":"https://blog.johtani.info/blog/2020/05/08/rebootnlp100-ch02-10to11/","publishdate":"2020-05-08T23:37:20+09:00","summary":"気づいたら1ヶ月サボってました、ごめんなさい。。。 Rustで言語処理100本ノックの第2章をはじめました。 前回はこちら。 確認用のUnixコマ","tags":["Rust","nlp100"],"title":"第2章の10から11まで(言語処理100本ノック2020)"},{"contents":"Rustで言語処理100本ノックのリファクタリングの続き。\n前回はこちら。\nとっくに終わってたのに、ブログ書いてなかった。。。\n08. 暗号文 pub fn cipher(text: \u0026amp;str) -\u0026gt; String { return String::from_iter(text.chars().map(|x| { if x.is_ascii_alphanumeric() \u0026amp;\u0026amp; x.is_lowercase() { let mut b = [0; 4]; x.encode_utf8(\u0026amp;mut b); b[0] = 219 - b[0]; char::from(b[0]) } else { x } })); } Rustの文字列はUTF-8でエンコードされたテキストを保持しているので、文字コード自体は意識していないです。 chars()でUnicodeスカラー値のイテレータが返ってくるので、1文字ずつ扱えるようになります。\nただ、1文字をバイトとして扱うのに手こずりました。 encode_utf8というメソッドを利用して1バイトだけ取り出して、計算するというのをやっています。 文字種の判別のメソッドが用意されているのは便利ですね。\nなんかもうちょっとスマートにできないのかな?と思いつつ動いたのでこれになってます。\n09. Typoglycemia pub fn typoglycemia(text: \u0026amp;str) -\u0026gt; String { return text .split_whitespace() .map(|word| { if word.len() \u0026lt;= 4 { word.to_string() } else { let original = word.chars().collect::\u0026lt;Vec\u0026lt;char\u0026gt;\u0026gt;(); let first = original.get(0).unwrap(); let last = original.last().unwrap(); let mut typo = original[1..original.len() - 1] .iter() .map(|x| x.clone()) .collect::\u0026lt;Vec\u0026lt;char\u0026gt;\u0026gt;(); let mut rng = thread_rng(); typo.shuffle(\u0026amp;mut rng); let mut typo = String::from_iter(typo.iter()); typo.insert(0, first.clone()); typo.push(last.clone()); typo } }) .collect::\u0026lt;Vec\u0026lt;String\u0026gt;\u0026gt;() .join(\u0026#34; \u0026#34;); } 一応、1行で記述できたかな? まずは、スペースで単語ごとに区切った後に、word(単語)の長さによって、処理を分岐し、単語が5文字以上の場合にランダムに並び替えを行うというのをやっています。 文字単位で処理を行うために、chars()で1文字ずつ取り出しています。 最初と最後の文字だけはそのままに、間の文字をランダムにシャッフルするというのをやるのに、もとのwordのスライスからコピーした文字列を作り出してから組み立て直すということをやっています。\nコピーしないでゴニョゴニョする方法ってあるのかなぁ? 思いつかなかったので、結構泥臭い感じの実装になってしまいました。\nまとめ めんどくさいので、コードをGitHubのソースコードからではなく、ブログにコードスニペットとしてコピペしました。Hugoでいい感じにGitHubのコードスニペット表示するのないかなぁ?\nということで、2年越しで1章が終了しました。 2章もやらないとなぁ。\n","date":1588923657,"dir":"post/2020/","id":"2c3270f8797ace2fb37402ea6a09d126","lang":"ja","lastmod":1588923657,"permalink":"https://blog.johtani.info/blog/2020/05/08/reboot-nlp100-finish-ch01/","publishdate":"2020-05-08T16:40:57+09:00","summary":"Rustで言語処理100本ノックのリファクタリングの続き。 前回はこちら。 とっくに終わってたのに、ブログ書いてなかった。。。 08. 暗号文 pub fn cipher(text: \u0026amp;str) -\u0026gt;","tags":["Rust","nlp100"],"title":"第1章の08から09まで(言語処理100本ノック2020)"},{"contents":"前回はWorkplace Searchの概要について書きましたが、今回はインストールと構成要素について説明します。なお、2020/5/7時点での情報を元に本記事は書いていますのでご注意ください。基本的にはインストールと起動方法についての手順を元に書いています。所々に考察を挟んだ形の記事になっていますので、気になるところだけ呼んでいただければと。\n記事一覧 ElasticのWorkplace Searchを触ってみる - その1 インストール インストール方法は公式リファレンスもしくはダウンロードページに記載があります。 現時点ではMacもしくはLinuxが対象でWindowsはまだサポート対象外となっています。\n必要なもの インストールに必要なものは以下になります。\nElasticsearch 7.6.x + Platinum license Elastic CloudのElasticsearch Service もしくは ダウンロードしてローカルで起動 enterprise-search-7.6.0.tar.gz ダウンロードページはこちら Java 8もしくは11 Long Term Supportの対象であるJavaです。2020/5/7時点では8か11 今回はローカルにElasticsearchの7.6.2をインストールしてから試してみます。30日間のトライアルライセンスが有効になっているので、Platinumの機能を試すことができます。\nJavaの8か11が必要になります。Elasticsearchには7.xからJDKが同梱されるようになりましたが、Workplace SearchがJettyを元に動作しているからです(enterprise-search-7.6.0.tar.gzにjettyというフォルダあり)。\nインストール手順 大まかには以下の3つです。\nJava 8もしくは11のインストール 14でも大丈夫でした(ローカルにはSDKMANでインストールした14.0.1が利用された)。 Elasticsearchのインストール(Elastic Cloudの場合はクラスタの起動) 今回はローカルにインストール Workplace Searchのインストール Javaはもともとインストールされていたので、今回は2と3をインストールしました。どちらもローカルで起動するので、2つをダウンロードしてtar.gzファイルを展開するだけになります。\n起動方法と設定 起動方法に起動前の設定の手順も記載があります。 設定しながら起動していきます。\nElasticsearchの起動 既存のElasticsearchのクラスターがあり、Platinumのライセンスが有効になっている場合はこの手順は必要ありません。\nElasticsearchの設定ファイルでSecurity機能をオンに 7.1から基本的なセキュリティ機能はベーシックの機能に含まれています。 Elasticsearchを起動 まずは起動(パスワードなどを設定するために必要) Elasticsearchのパスワードの設定 Elasticsearchでデフォルトで用意されているユーザーのパスワードを設定してします。手順では自動で生成させる方法ですが、独自に設定することも可能です。 Workplace Searchの起動 Elasticsearchが起動したらWorkplace Searchの設定をして起動します。\nEsへの接続設定をconfig/enterprise-search.ymlに指定 Esのパスワード設定時に生成されたelasticというユーザーのパスワードをここで指定。 yamlファイルに記載があるが、${ELASTICSEARCH_PASSWORD:changeme}という記述をした場合に環境変数を読み込める allow_es_settings_modification: trueをconfig/enterprise-search.yml ここに記載があるような変更をWorkplace SearchがEsのクラスターに対して実行する模様。Workplace Search以外でも使用しているElasticsearchクラスターの場合はallow_es_settings_modificationを有効にする代わりに、リンク先にあるような設定を自分で追加する。 secret_management.encryption_keysを複数設定 Encryption Keysのガイドに少し詳しい説明がある。 opensslコマンドとかで作ればいいかな?? 1.と同じような設定をしようとしたがうまくいかなかったので、ファイルにキーを設定する方式にしました(バグ?) 起動するときにデフォルトユーザーパスワードを指定 指定しなければ勝手に生成してコンソールに出力してくれるので、そちらの方がいいかと。 今回は手順通りに指定した。 起動確認のためhttp://localhost:3002にアクセス 起動するとログが流れ、問題がなければ次のようにデフォルトユーザーの情報が出力されます。\n######################################################### *** Default user credentials have been setup. These are only printed once, so please ensure they are recorded. *** username: enterprise_search password: pas...ple ######################################################### そして無事起動に成功したことも出力されます。\n######################################################### Success! Elastic Workplace Search is starting successfully. In a few moments, you\u0026#39;ll be able to login at the following address: * URL: http://localhost:3002 * If this is your first time starting Workplace Search, check the console output above for your user authentication credentials. * Visit the documentation: https://swiftype.com/documentation/enterprise-search Secret session key has been generated. Set the key in your config file to persist user sessions through process restarts: secret_session_key: c23...3 ######################################################### ブラウザで画面にアクセスすると、次のような画面が表示されました。\n起動時のエラー いくつかのパターンも試してどんなエラーが出るのかを見てみました。 おまけですね。\nElasticsearchが見つからないエラー Esを起動しないでWorkplace Searchを起動してみました。\n200秒間アクセスしようと試みて駄目だったらエラーで終了みたいです。\n[2020-05-07T03:48:33.645+00:00][13709][2002][app-server][INFO]: Failed to connect to Elasticsearch backend. Make sure it is running. ... [2020-05-07T03:51:54.038+00:00][13709][2002][app-server][INFO]: Could not connect to Elasticsearch backend after 200s. Terminating... [2020-05-07T03:51:54.039+00:00][13709][2002][app-server][ERROR]: -------------------------------------------------------------------------------- Error: Workplace Search is unable to connect to Elasticsearch. Ensure a healthy Elasticsearch cluster is running at http://127.0.0.1:9200 for user elastic. -------------------------------------------------------------------------------- ElasticsearchのSecurityがオフのときのエラー ちなみにSecurityをオフにしたままWorkplace Searchを起動した場合は以下のようなエラーが出ました。\n[2020-05-07T03:46:53.474+00:00][13567][2002][app-server][ERROR]: -------------------------------------------------------------------------------- Elastic Workplace Search requires Elasticsearch security features to be enabled. Please enable Elasticsearch security features as outlined here: https://www.elastic.co/guide/en/workplace-search/current/workplace-search-install.html -------------------------------------------------------------------------------- 構成要素 ここまでインストールして起動してきました。 では、Workplace Searchがどういったコンポーネントから構成されているかを予測してみましょう(あくまで外から見た予想となります。そのうちElastic社のウェビナーとかイベントで内部の発表とかあるかも?)。\nインストールページの記載から インストールページに最小ハードウェアという記載があり、そこで何が動く可能性があるかというのがわかります。\n起動するものはこんな感じみたいです。\nElasticsearch - 外部でもOK App Server - Workplace SearchのWeb機能 Worker - クローラーとかかな? Filebeat - Workplace Searchのログ収集用 その他プロセス - なんだろ? という具合です。\n設定などからの予想 次は設定項目や起動時のログなどからの予想です。\nWorklpace Search配下のセキュアなデータストア - アクセストークンなどの管理のため JRubyアプリケーション - App ServerはJRuby上で動いているRailsアプリ Filebeatも起動している - Workplace Searchのログ収集のため? Filebeatの接続設定はWorkplace Searchの設定値を利用 では構成要素は? ということで、現時点でわかった構成要素は以下のとおりです。\nElasticsearch Workplace Search App Server - Railsアプリ on JRuby Webアプリとは別に(内部?で)、いくつかのワーカーが存在する 管理画面と検索画面の2種類が存在 Filebeat - ログ収集 といった感じです。 まだ起動したばかりなのでこのくらいでしょうか。ログを見るともう少しわかりそうな気がします。\n基本的には、EsをバックエンドにしたRailsのミドルウェアになります。コネクターや検索画面はすべてWorkplace Searchのミドルウェア経由でアクセスする形になりますので、普通に検索で利用するユーザーにはElasticsearchの存在は見えない作りになっています。\n次は? Getting Startedを元に、どんなアクターがいて、どんな機能が提供されているのか、どんな利用方法なのか?というのを見ていこうと思います。\n","date":1588818770,"dir":"post/2020/","id":"44db1f1fefc97cd28d55d443f2bd2b63","lang":"ja","lastmod":1588818770,"permalink":"https://blog.johtani.info/blog/2020/05/07/install-workplace-search/","publishdate":"2020-05-07T11:32:50+09:00","summary":"前回はWorkplace Searchの概要について書きましたが、今回はインストールと構成要素について説明します。なお、2020/5/7時点で","tags":["elasticsearch","workplace search"],"title":"ElasticのWorkplace Searchを触ってみる - その2 - インストールと起動"},{"contents":"2月のElastic社のブログですが、Enterprise Searchとこれまで呼んでいた製品をWorkplace Searchという製品名に変更し、App Searchなどを含む製品群をEnterprise Searchという名前に変更しました(ちょっとややこしい)。 Workplace Search自体はまだβ版という位置づけですが、ダウンロードして試すことが可能です。\nきちんと触ったことがないので、ちょっと触って見ようかなと思い、何回かに分けてブログを書いてみます。まずは概要とかから。\nWorkplace Searchとは? Elasticsearchをバックエンドに利用するElastic社が提供するアプリケーション(ミドルウェア?)の1つです。\nもともとはSwiftypeという会社が作っていた、Site Search、App Searchと同じような系列で開発されている統合検索の検索エンジンミドルウェアという感じです。 製品ページを見るとわかりますが、様々なデータソースから、データをクロールしてElasticsearchに保存することで、統合された検索を提供することができるようになる製品です。 最近は会社のドキュメントがさまざまな場所(Google Drive、Saleseforce、GitHub、Dropboxなど)に保存されています。 それぞれで検索窓などはありますが、1箇所で検索することで横断的に検索でき、仕事の効率があがりますよね?ということで作られている製品です。\n提供(利用)方法は? 今後の提供方法としては、Elastic Cloudで利用できるSaaS形式のものと、独自に(クラウドのコンピューティングエンジンやオンプレのサーバーなどで)Workplace Searchのアプリを起動する方法(オンプレ版)があります。後者の場合は、Elasticsearchのクラスターを用意する必要があります。なお、後者の場合、Elasticsearchのサブスクリプションのプラチナライセンスが必要になるようです(ダウンロードページに記載あり)\nまだ、β版という位置づけなので、今後どのように変更されるかはわかりませんが、今回は2020年5月1日時点でのベータ版(7.6.0)を元にどんなものかを紹介します。現時点で利用できるのはβ版のオンプレ版で、MacやLinuxで利用可能です。\nダウンロードとインストール ダウンロードページにインストール方法などの記載があります。\nインストールして触って見るところはまた後日。\nライセンス、価格は? まだ不明です。SaaS版の提供はまだです。 オンプレ版については少なくとも、Elasticのサブスクリプションのプラチナが必要になります。こちらは、価格は公開されていません。Elastich社もしくはパートナー企業での問い合わせが必要になります。 (たぶん、ドキュメントレベルのセキュリティとかSSOとかの仕組みがプラチナで提供されているのでそのあたりを使っているのでは?と想像してます。)\n想定できそうな用途は? 社内の文書検索でしょうか。ただ、いわゆる昔ながらのエンタープライズサーチと呼ばれている、社内のファイルサーバーなどの文書検索ではなく、クラウドサービスを複数利用している会社が利用する想定になっています。\n例えば、開発者は社内Wiki(Confluence)で社内文書を書き、Issue管理にはJIRAやGitHubを活用しており、ただ、社内での説明にはGoogle Driveを利用しているといった場合です。こういう場合、あの機能についての説明や資料ってどこだっけ?というので、あちこち探し回ったりしないといけないです。また、営業部門やサポート、マーケティングなどが絡んでくると更に、SalesforceやZendeskといったデータソースも出てきます。 情報が散らばっていて、それらを探し出したりまとめるだけで時間を取られている場合などに便利かもしれません。\n次は? 実際にインストールしてから起動して、どんな感じで使えるのかといったところを見て、どんな機能が提供されているのかを見ていこうと思います。\n","date":1588318144,"dir":"post/2020/","id":"4d71d2a23c85fb7af20e8d1e8b3e0de8","lang":"ja","lastmod":1588318144,"permalink":"https://blog.johtani.info/blog/2020/05/01/intro-workplace-search/","publishdate":"2020-05-01T16:29:04+09:00","summary":"2月のElastic社のブログですが、Enterprise Searchとこれまで呼んでいた製品をWorkplace Searchという製品名に","tags":["elasticsearch","workplace search"],"title":"ElasticのWorkplace Searchを触ってみる - その1"},{"contents":"先日、Elasticsearchでのカスタム辞書の利用方法についてブログを書きました。\n辞書の設定方法について記載しましたが、今回は辞書の更新について書いていなかったので、書いてみようと思います。 ここで「辞書」としているのは、Kuromojiのユーザー辞書、Synonym Graph Token FilterのSynonym辞書(いわゆる類義語辞書)のことになります。サードパーティのAnalyzer等に関する話ではありません。\n辞書更新に関する制限事項 辞書の更新について、大原則と制限事項が存在します。\n大原則(辞書の更新=データも更新) ElasticsearchはAnalyzerが切り出した単語を元に転置インデックスを作成して、検索を行っています(この仕組みに関するスライドはこちらを参照のこと)。 Analyzerが辞書を持っている場合、その辞書を元に単語を切り出して転置インデックスに利用します。 また、検索クエリの単語に対してもこのAnalyzerの辞書が利用されます。\n辞書に新しい単語を追加するということは、その単語に関連するドキュメントも更新しないと行けないということになります。\n例えば、Kuromojiを利用していて、「グランベリーパーク」という単語「グランベリー」「パーク」という単語に分割できるような新しい単語として辞書に追加する場合を考えてみましょう。ユーザーが「グランベリー」で検索しても検索結果として出てきてほしいという場合です。\n辞書に「グランベリーパーク」を登録していない頃に登録されたドキュメントは「グランベリーパーク」という1単語として転置インデックスの見出し語を切り出します(Kuromojiはカタカナの連続している文字列については未知語として1単語にし、「名詞-一般」の品詞を付与)。\n更新前でのドキュメントのAnalyze結果\n「グランベリーパーク」「で」「ショッピング」 もし、辞書に「グランベリーパーク」を「グランベリー」「パーク」から構成される新規の単語として登録しそれを使用した場合、辞書を更新したあとから、「グランベリーパーク」という単語がAnalyzerからは出てこなくなります。\n更新後でのドキュメントのAnalyze結果\n「グランベリー」「パーク」「で」「ショッピング」 ということは、辞書更新以前のドキュメントは「グランベリーパーク」という見出し語に対して登録されているので、辞書更新以前に登録されているドキュメントは検索にヒットしなくなります。\nこのように転置インデックスを利用している検索エンジンでは、単語の区切りが変更されるような辞書の更新があった場合、最低でも影響があるドキュメントについては再登録が必要となるわけです。\nこれが大原則(辞書更新=データも更新)となります。 基本的には辞書の更新を行った場合は、ドキュメントの再インデックス(再登録)が必要となります。\nElasticsearchでの制限事項 Elasticsearchでは、辞書の更新に関して実装上の制限事項が存在しています。 内部的な実装として、ElasticsearchではAnalyzerのインスタンス(正確にはAnalyzerのFactoryのインスタンス)の生成がインデックスに関する内部のインスタンスが生成されたタイミングの1回のみとなっています。\nこのインスタンスの生成時に設定ファイル(辞書を含む)を読み込んでいます。\n言い換えると、辞書(ファイル、インデックス設定に関わらず)の読み込みは、インデックスが作られたタイミングのみということになります。 なおここで言う「インデックスが作られたタイミング」というのは、以下の2パターンです。\nインデックス新規作成時 インデックスオープン時 では、ここから辞書を更新してそれを既存のインデックスに適用する方法について説明しましょう。\n辞書の更新方法(ファイル編) 前回のブログで説明しましたが、Elasticsearch 7.4よりも古いバージョンでは、ファイルでKuromojiのユーザー辞書を設定していました。まずはこちらの方法について説明します。前提として、すでにユーザー辞書を設定したKuromoji Tokenizerがインデックスに設定されているものとします(ユーザー辞書の設定方法については公式リファレンスを御覧ください)。\n辞書ファイルに新規にエントリーを追加しただけでは、設定は読み込まれていません。新規辞書を反映させるためには以下の手順が必要となります。\n更新した辞書ファイルの配布 複数ノードでElasticsearchのクラスターを構成している場合はすべてのノードに更新した辞書ファイルを配布する必要があります。 インデックスのクローズ(公式リファレンス) 設定ファイルを再読込させるために一度インデックスをクローズします。 クローズするので、書き込み、検索などの処理を停止する必要があります。もし停止していない場合はクライアント側ではインデックスがクローズされているという旨のエラーを受け取ります(400で、index_closed_exception)。 インデックスのオープン(公式リファレンス) 設定ファイルを読み込みます。これで、新規追加された単語が読み込まれます。 再インデックス _update_by_queryを利用することで、対象のインデックスのデータを再インデックスすることができます。条件無しでAPIを呼び出すとすべてのデータが再度登録されます。 _sourceがfalseの場合は_update_by_queryは利用できません。元データをもう一度外部からElasticsearchに対して登録する必要があります。 Kibanaでの手順をGistにしてあります。手順はこちらをご覧ください。\n辞書の更新方法(インデックス設定編) ファイルの場合とは少し手順が異なります。 インデックスの設定としてユーザー辞書を登録しているため、ファイルをElasticsearchのクラスターにあるノードに配布する必要がありません。 また、辞書の設定はインデックスの設定に指定してありますが、こちらは動的に設定変更できる項目ではないため、インデックスを先にクローズする必要があります。\nインデックスのクローズ(公式リファレンス) 辞書の設定を更新するにはインデックスをクローズする必要があります。辞書の設定は動的に更新できる項目にはなっていないためです。 オープンしているインデックスで更新しようとした場合はillegal_argument_exceptionでCan't update non dynamic settings...というメッセージが返ってきます。 辞書の更新(公式リファレンス:インデックス設定の更新) user_dictionary_rulesに単語と追加します。 インデックスのオープン(公式リファレンス) 設定ファイルを読み込みます。これで、新規追加された単語が読み込まれます。 再インデックス _update_by_queryを利用することで、対象のインデックスのデータを再インデックスすることができます。条件無しでAPIを呼び出すとすべてのデータが再度登録されます。 _sourceがfalseの場合は_update_by_queryは利用できません。元データをもう一度外部からElasticsearchに対して登録する必要があります。 Kibanaでの手順をGistにしてあります。手順はこちらをご覧ください。\n第3の方法(新規インデックス作成) ここまで、インデックスのクローズ、オープンで既存のインデックスに対して辞書を更新する方法について説明しました。 ただ、残念なことにAmazon Elasticsearch ServiceではElasticsearchが提供しているすべてのAPIが利用できるわけではありません(Amazon ESの利用可能なAPIの一覧はこちら)。 (_closeは駄目だけど_openは呼べるのかな???)\nということで、新規にインデックスを作成して、新しい辞書の設定を反映したインデックスを用意し、そこにデータをコピーもしくは登録するという方法になります(Amazon ESのカスタム辞書のドキュメントに手順がありますね)。\n手順としては以下のとおりです。\n辞書の更新(用意) 新しい単語などを登録した辞書を用意します。 ファイル、インデックス設定どちらでもOKです。 ファイルの場合は、既存のファイル名とは異なるファイル名にしたほうが混乱がなくなります。 新規インデックス作成 1.で作成した辞書を元に新規インデックスを作成します。 新規インデックスにデータコピー _reindex APIを利用するとデータコピーが簡単です。sourceとdestを指定するだけです。 _sourceがfalseの場合は_update_by_queryは利用できません。元データをもう一度外部からElasticsearchに対して登録する必要があります。 アプリケーション側で新規インデックスを利用するように変更 _aliasを使用しておくと切り替えが簡単です(公式リファレンスはこのあたり)。 考慮すべき点としては、サービスを提供しながら行う場合は、3.の_reindexを実行し始めたタイミング以降の登録・更新データの扱いについてでしょうか。\nまとめ 辞書の更新に関する大原則、制限事項、手順などについて説明しました。 辞書の変更は検索に大きく影響がでます。そのあたりをきちんと考慮しながら更新しましょう。 ユーザー辞書、カスタム辞書を扱う際の参考にしていただければと。 他にもユーザー辞書で気をつけないといけないこともありますが、今日はこのあたりで。\n","date":1587951855,"dir":"post/2020/","id":"be2c49ea5816e7daa6d3b3ff45353291","lang":"ja","lastmod":1587951855,"permalink":"https://blog.johtani.info/blog/2020/04/27/note-updating-dictionary/","publishdate":"2020-04-27T10:44:15+09:00","summary":"先日、Elasticsearchでのカスタム辞書の利用方法についてブログを書きました。 辞書の設定方法について記載しましたが、今回は辞書の更新","tags":["elasticsearch"],"title":"辞書の更新についての注意点"},{"contents":"Elasticsearchで日本語を扱うときに、カスタム辞書を使いたいという要望がよくあります。 AWSのElasticsearch Serviceでカスタム辞書ファイルを読み込める機能が発表されたようです。\n実は、Elasticsearchの7.4からファイルを使用しなくても日本語のTokenizerでカスタム辞書を利用することができるようになっています。\nカスタム辞書をインデックスの設定で指定 やり方はドキュメントに記載があります。\nトークナイザーの設定をインデックスの設定に記述しますが、このときに user_dictionary_rulesという設定を利用することでカスタム辞書を指定できます。\nPUT custom_dic_sample { \u0026#34;settings\u0026#34;: { \u0026#34;index\u0026#34;: { \u0026#34;analysis\u0026#34;: { \u0026#34;tokenizer\u0026#34;: { \u0026#34;kuromoji_user_dict\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;kuromoji_tokenizer\u0026#34;, \u0026#34;mode\u0026#34;: \u0026#34;extended\u0026#34;, \u0026#34;user_dictionary_rules\u0026#34;: [ \u0026#34;グランベリーパーク,グランベリー パーク,グランベリー パーク,カスタム名詞\u0026#34;, \u0026#34;高輪ゲートウェイ,高輪 ゲートウェイ,タカナワ ゲートウェイ,カスタム名詞\u0026#34;] } }, \u0026#34;analyzer\u0026#34;: { \u0026#34;my_analyzer\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji_user_dict\u0026#34; } } } } } } 辞書の内部は\u0026quot;単語,出てきてほしい単語列(スペース区切り),読みの単語列(スペース区切り),品詞名\u0026quot;になります。配列で設定可能で、複数の単語を登録したい場合は、カンマ区切りで登録していきます(上記例では2つの単語を登録しています)。\n_analyzeを利用して設定の確認 実際に上記の設定がうまく動作するかは_analyzeのエンドポイントを利用します。\nGET custom_dic_sample/_analyze { \u0026#34;text\u0026#34;: \u0026#34;グランベリーパークがオープンしました。\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;my_analyzer\u0026#34; } 出力は以下のようになります。\n{ \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;グランベリー\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 6, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 0 }, { \u0026#34;token\u0026#34; : \u0026#34;パーク\u0026#34;, \u0026#34;start_offset\u0026#34; : 6, \u0026#34;end_offset\u0026#34; : 9, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 1 }, { \u0026#34;token\u0026#34; : \u0026#34;が\u0026#34;, \u0026#34;start_offset\u0026#34; : 9, \u0026#34;end_offset\u0026#34; : 10, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 2 }, { \u0026#34;token\u0026#34; : \u0026#34;オープン\u0026#34;, \u0026#34;start_offset\u0026#34; : 10, \u0026#34;end_offset\u0026#34; : 14, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 3 }, ...(省略) ] } ちなみに、デフォルトのkuromojiを利用した場合は、グランベリーパークが1単語として出力されます。\nGET _analyze { \u0026#34;text\u0026#34;: \u0026#34;グランベリーパークがオープンしました。\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34; } ## レスポンス { \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;グランベリーパーク\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 9, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 0 }, { \u0026#34;token\u0026#34; : \u0026#34;オープン\u0026#34;, \u0026#34;start_offset\u0026#34; : 10, \u0026#34;end_offset\u0026#34; : 14, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 2 } ] } これで、カスタム辞書を使用することでグランベリーで検索された場合に、グランベリーパークもヒットするという仕組みです。\n_analyzeはexplainというパラメータも持っており、こちらを利用することで、単語の品詞情報なども取得できます。これを使うことで、実際に設定がきちんと動作しているかの確認に利用できます。\nGET custom_dic_sample/_analyze { \u0026#34;text\u0026#34;: \u0026#34;グランベリーパークがオープンしました。\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;my_analyzer\u0026#34;, \u0026#34;explain\u0026#34;: true } ## レスポンス(一部のみ) { \u0026#34;detail\u0026#34; : { \u0026#34;custom_analyzer\u0026#34; : true, \u0026#34;charfilters\u0026#34; : [ ], \u0026#34;tokenizer\u0026#34; : { \u0026#34;name\u0026#34; : \u0026#34;kuromoji_user_dict\u0026#34;, \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;グランベリー\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 6, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 0, \u0026#34;baseForm\u0026#34; : null, \u0026#34;bytes\u0026#34; : \u0026#34;[e3 82 b0 e3 83 a9 e3 83 b3 e3 83 99 e3 83 aa e3 83 bc]\u0026#34;, \u0026#34;inflectionForm\u0026#34; : null, \u0026#34;inflectionForm (en)\u0026#34; : null, \u0026#34;inflectionType\u0026#34; : null, \u0026#34;inflectionType (en)\u0026#34; : null, \u0026#34;partOfSpeech\u0026#34; : \u0026#34;カスタム名詞\u0026#34;, \u0026#34;partOfSpeech (en)\u0026#34; : null, \u0026#34;positionLength\u0026#34; : 1, \u0026#34;pronunciation\u0026#34; : null, \u0026#34;pronunciation (en)\u0026#34; : null, \u0026#34;reading\u0026#34; : \u0026#34;グランベリー\u0026#34;, \u0026#34;reading (en)\u0026#34; : \u0026#34;guramberi\u0026#34;, \u0026#34;termFrequency\u0026#34; : 1 }, { partOfSpeechにカスタム辞書で設定したカスタム名詞が出力されていますね。 _analyzeのAPIはこのように、アナライザーの挙動の確認に非常に便利なので是非活用してみてください。\nKibanaでこのAPIを使うためのプラグインも開発していますので、こちらも合わせて利用してみてください。\n注意点 ちなみに、user_dictionaryとuser_dictionary_rulesを両方指定した場合はエラーとなります。 ファイルをベースにしつつ、追加の設定をするという使い方はできないので、注意しましょう。\nインデックスの設定で書くことにより、バックアップ・リストアは楽になるかな。ただ、クラスターステートに取り込まれるから、あまりにも巨大なカスタム辞書だと心配かなぁ。ファイルの場合はクラスターステートには取り込まれないので、そこは圧迫しない。\n\u0026mdash; Jun Ohtani (@johtani) April 22, 2020 それ以外の注意点については、別途ブログを書きました。 「辞書の更新についての注意点」、こちらも合わせてご覧ください。\nまとめ カスタム辞書をファイルではなくインデックスの設定値として設定する方法を紹介しました。こちらは、Elasticsearch 7.4で導入された機能になります。7.4以降を利用している場合はこちらを利用することも検討してはいかがでしょうか? また、_analyze APIも便利なので合わせて活用してみてください。\n","date":1587519056,"dir":"post/2020/","id":"15357b6978e83daa2d97692c861dc177","lang":"ja","lastmod":1587519056,"permalink":"https://blog.johtani.info/blog/2020/04/22/custom-dictionary-after-7-4/","publishdate":"2020-04-22T10:30:56+09:00","summary":"Elasticsearchで日本語を扱うときに、カスタム辞書を使いたいという要望がよくあります。 AWSのElasticsearch Servi","tags":["elasticsearch"],"title":"Kuromojiのカスタム辞書をインデックスの設定で指定"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 第8章 7章はパッケージなので後回しにして、8章に入ります。 8章はコレクションです。\nベクタ型 ベクタは同じ型の値だけ保持可能。 ジェネリクスで型を指定可能 - Vec\u0026lt;i32\u0026gt;とか。 vec!マクロで初期値とか設定すると便利。 ベクタに値を追加するのはpush。もちろん値が変わるので元のベクタにはmutが必要 ベクタのスコープ(ライフサイクル)は要素に対する参照があるのとないので話が変わってくる メモリの確保などの影響で、ベクタ全体に対して借用の規則が矯正されると。 ベクタの値を読むのはいくつか方法あり getメソッドはOptionを返す \u0026amp;v[2]の添字記法の場合はパニックの可能性あり 走査(唐突に参照外しが出てきた) 単純に値を取り出す場合はfor - in \u0026amp;v Enumをベクタにいれることで、異なる型も保持可能(まぁ、Enumの型では固定されるけど)。 これだけのためにEnumを使うことってあるのかな? トレイとオブジェクトに関する文章はちょっとわかりにくい。。。 説明以外のメソッドなどについてはAPIドキュメント見ましょうと(リンクも張ってくれてると嬉しいなぁと思ったり。まぁ、バージョンとかの絡みがあるから難しいか)。\n文字列型 文字列はUTF-8でエンコードされた文字を扱うための型。\nstrは文字列データへの参照。\nString型は言語のコアではなく、標準ライブラリに入っている文字列型。\n他にもあるのか。。。OsStringとか。。。 文字リテラルはDisplayトレイトを実装していると。\n.to_string() = String::from\nStringはコレクションだから追加とかが可能なのか、なるほど。\npush_strとpush\n+演算子での参照。\n\u0026amp;Stringは\u0026amp;strに型強制(キャスト?)してくれる。してくれる場合としてくれない場合もあるのかな?s2の所有権は奪わない形で扱うのでs2はこのあとも使えていると。 ここでは、s1を変更したあとに所有権がs3に持っていかれてる? format!を使うとどの所有権も奪わないので、これを使うほうが考え方は簡単そう。ただし、効率がいいかはわからん。 添字記法でのアクセスをStringは許容していない\n文字の境界が必ずしも1バイトとは限らないから。 スライスも同様。 基本的には.chars()で文字としてアクセスするのが良い。\n逆にバイト表現を得る方法はどうするんだろう?\nNLP100本ノックではencode_utf8メソッド使ったけど。 ハッシュマップ いろんな呼び方あるよね。Rustではハッシュマップだよ。 ハッシュマップはuseしないと使えない キーは1つの型、値も1つの型 タプルのベクタからcollectで生成。なるほど。 タプルのベクタだと、タプルの中身は同じものであることが言える? -\u0026gt; 言える。エレメント数が異なるとコンパイルエラーになった 所有権周りの話。 これ、ベクタのときに話してほしい感じがした。 値を渡すか参照を渡すかによって話が変わってくる。詳しくは10章 このあたりが自分が混乱していた元だ。 entryとinsertの違い entryの戻り値はEntryというenumでor_insertというメソッドがありそれを使うと存在しない場合だけinsertが呼ばれる。 これ便利だ。毎回existあたりで存在チェックしてた気がする。 or_insertは可変参照\u0026amp;mut Vを返す。 これをlet countで束縛するときに、中身が可変かどうかをcountには指定しないのか。。。 まとめ 一応、大学などで習ってた(はず)ですが、 スタックとヒープを意識して考えないといけないなぁというのを何度か意識させられた感じです。\nあと、これはRustに限らずですが、それぞれがどんな関数を持っているか、どんなメソッドを持っているか、どんなマクロが存在するかなどを探すときにみんなどうしてるんだろう? 人に教えてもらっているのか、APIリファレンスを探すのか、そういったところをみんながどういう感じにプログラミング言語を勉強しているか、業務で書いているのかと言うのが気になりました。\n","date":1587028650,"dir":"post/2020/","id":"f488aa62d39194824861a134567cadb8","lang":"ja","lastmod":1587028650,"permalink":"https://blog.johtani.info/blog/2020/04/16/chap8-rust-the-book/","publishdate":"2020-04-16T18:17:30+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 第8章 7章はパ","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第8章"},{"contents":"Rustで言語処理100本ノックのリファクタリングの続き。\n前回はこちら。\nコードも載せたほうが見やすいかなぁ?\n03. 円周率 2年前はこちら。 どちらかというとJavaっぽい書き方かな? 入れ物を用意して、入力を整形して、それからループを回す感じで書いてました。\n今回は1行で収めてみました。 Rustっぽく、returnを省略してみました。 あとは、Iteratorを組み合わせる感じでやってます。 アルファベットの文字数ということで、is_alphabetic()メソッドでfilterしてます。\n04. 元素記号 2年前はこちら。 エラー処理が多いのと、文字の扱いがちょっと\nここまで同様に極力イテレータを利用するという方針でリファクタリングしました。 あとは、エラー処理を除去してます。 正常系だけのテストなのでスッキリさせました。\nこういった、ストリーム系?の書き方の場合にエラー処理をどう入れるかってところはちょっと悩みどころになるんじゃないかなぁ?と思いつつ、イレギュラーなものは後回しで(あとにやるのかなぁ?)\n05. n-gram 2年前はこちら。 これまでと同じく、入れ物を作ってから処理をしてます。\n同じく、極力イテレータを利用する形で実装しました。 いくつか型の変換が必要なので、.map()を呼び出して詰め替えたりしています。\n06. 集合 2年前はこちら。 独自に実装しています。\nせっかく05で文字n-gramの配列を返す処理を実装しているので、 そちらを呼び出して、Setに入れるという処理に書き換えました。 その後の集合に対する処理については特にリファクタリングしてないです。\nまとめ 2年前にやってたところまでは追いつきました。 07は特にリファクタリングする必要がないので、次は08からの予定です。\nリファクタリングしているときになるのは、速度とかでしょうか。 実装の違いでなにか差が出るのかどうかはちょっと気になるところですが、 今回の目的ではないので、目をつぶって進める予定です。\n","date":1586423695,"dir":"post/2020/","id":"9a687babb0f44db51dc389b75bdaa19d","lang":"ja","lastmod":1586423695,"permalink":"https://blog.johtani.info/blog/2020/04/09/reboot-nlp100-ch01-03to05/","publishdate":"2020-04-09T18:14:55+09:00","summary":"Rustで言語処理100本ノックのリファクタリングの続き。 前回はこちら。 コードも載せたほうが見やすいかなぁ? 03. 円周率 2年前はこちら。 どちらか","tags":["Rust","nlp100"],"title":"第1章の03から06まで(言語処理100本ノック2020)"},{"contents":"今回もツイートから。\n言語処理100本ノックの2020年版を公開しました。最近の自然言語処理の研究動向を反映し、深層ニューラルネットワークに関する問題を追加しました。留学生も一緒に取り組めるように多言語化を進め、その第１弾として英訳を部分公開しています（40番以降は順次公開予定）。 https://t.co/52h362PIQQ\n\u0026mdash; Naoaki Okazaki (@chokkanorg) April 6, 2020 言語処理100本ノックが2020年版になったそうです。 そうです、2年前に初めて、準備運動で止まっていたんです!(衝撃的な続かなさ。。。)\nということで、Rust the bookも読んでいることだし、過去のプログラムをチェックしつつ再開しようかなと。 ということで、いくつかリファクタリングしてみました。\nソースはリポジトリを御覧ください。\n00. 文字列の逆順 2年前の実装では、chars()メソッドで取り出したあとに、collect()でVecにしていたのですが、RustのIteratorトレイトにrev()という便利なメソッドが存在していました。\nということで、これを取り出すと、最初の文字列の逆順で文字を取り出すIteratorが取得できます。 あとは、Stringが実装してくれているfrom_iterに渡せば文字列が出来上がります。\n01. 「パタトクカシーー」 ストリーム処理っぽい書き方に変更しました。 2年前はIteratorを取り出して、詰替していましたが、 enumerate()で添字と文字のタプルのイテレータに変換し、 filterで添字が偶数のときだけフィルタリングして、 mapで対象の文字をまとめたイテレータにします。 で、最後はそれを元に文字列を生成することにしました。 iterを使わないでそのままString::from_iterの引数に渡すことも可能ですね。\n02. 「パトカー」＋「タクシー」＝「パタトクカシーー」 2年前は2つのIteratorをloopで回して頑張って結合してました。 ではなく、zip()を使って、2つのイテレータを組み合わせる方法に替えてみました。 このとき、2つの文字列が違う文字数の場合の処理として、長い方から取り出した文字をあとに結合する処理を追加で記述しました。 ちょっとスマートな感じになりましたかね?\nzipしたあとに出てきたタプルの文字列を結合するのにformat!マクロを使いましたが、他にいい方法有るかなぁ?\nまとめ とりあえず最初の3つをリファクタリングしてみました。 残りもやりつつ、準備運動以降もがんばるぞと。\n","date":1586338425,"dir":"post/2020/","id":"dc9580308938069159c5afc55b2f3b96","lang":"ja","lastmod":1586338425,"permalink":"https://blog.johtani.info/blog/2020/04/08/reboot-nlp10-with-rust/","publishdate":"2020-04-08T18:33:45+09:00","summary":"今回もツイートから。 言語処理100本ノックの2020年版を公開しました。最近の自然言語処理の研究動向を反映し、深層ニューラルネットワークに関","tags":["Rust","nlp100"],"title":"言語処理100本ノック、再び"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 第6章 Enumです。match式に大活躍\nEnumを定義する 列挙型は取りうる値をすべて列挙できる。これが名前の由来 列挙型と列挙子 2連コロン(::)で列挙子を指定可能 列挙子にデータ(構造体も)が格納可能。 標準ライブラリに実装例あり。 疑問:Write(String)とかはタプルの表現になるのかな? と思ったが、タプルでは1つだけの変数を持つものは定義(正確には定義できるが、内部で普通の変数にもどされてるっぽい)できなかった。 メソッド定義も可能 関連関数もできる? -\u0026gt; できる Optionの紹介 Rustにnullはない。代わりにOptionがある Noneを指定する場合に型が必要。Someの場合はすでに値が入るから推測可能なため。 match制御フロー演算子 アーム -\u0026gt; matchしたときの処理のこと 短い場合は波括弧は不要 returnなしでmatchが書いてあるだけだと、慣れない場合に値を返していることに気づかないかも(実際気づけてないかも) Enumが値を持っているときに、値の束縛がmatch式で可能 すべての列挙子を網羅していないことをコンパイラが検知してくれるのはすごく助かる。 ただし、_を利用していなければだけど if letで簡潔な制御フロー enumで1つのパターンのときに処理をしたい場合に使えるmatchの糖衣構文 elseもかけるよ。 まとめ enumに慣れていないので、値や構造体を持つenumを利用するという想像ができないことがありそうだなぁと読みながら思いました。 それになれると、色々とプログラムがシンプルに書ける部分が多くなりそうかな。\n","date":1586255231,"dir":"post/2020/","id":"4fbdc9c57a37781dc5dd86f470c61d04","lang":"ja","lastmod":1586255231,"permalink":"https://blog.johtani.info/blog/2020/04/07/chap6-rust-the-book/","publishdate":"2020-04-07T19:27:11+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 第6章 Enumです。matc","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第6章"},{"contents":"Kuromoji-CLIの使い方などについては過去のブログを御覧ください。\nKuromojiのCLIコマンドとpicocliとGraalVM GitHubリポジトリ Issueだけ上げていたJSON出力対応をしました。 また、ラティス(後述)の出力対応もしました。\nJSON出力 LinderaがJSON出力に対応してるのでそれを真似しました。 -o jsonで指定していただくと、次のようなJSONが出力されます。\n% echo \u0026#34;春眠暁を覚えず\u0026#34; | build/graal/kuromoji -o json [ { \u0026#34;text\u0026#34;: \u0026#34;春眠\u0026#34;, \u0026#34;detail\u0026#34;: [ \u0026#34;名詞\u0026#34;, \u0026#34;一般\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;春眠\u0026#34;, \u0026#34;シュンミン\u0026#34;, \u0026#34;シュンミン\u0026#34; ] }, { \u0026#34;text\u0026#34;: \u0026#34;暁\u0026#34;, \u0026#34;detail\u0026#34;: [ \u0026#34;名詞\u0026#34;, \u0026#34;一般\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;暁\u0026#34;, \u0026#34;アカツキ\u0026#34;, \u0026#34;アカツキ\u0026#34; ] }, { \u0026#34;text\u0026#34;: \u0026#34;を\u0026#34;, \u0026#34;detail\u0026#34;: [ \u0026#34;助詞\u0026#34;, \u0026#34;格助詞\u0026#34;, \u0026#34;一般\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;を\u0026#34;, \u0026#34;ヲ\u0026#34;, \u0026#34;ヲ\u0026#34; ] }, { \u0026#34;text\u0026#34;: \u0026#34;覚え\u0026#34;, \u0026#34;detail\u0026#34;: [ \u0026#34;動詞\u0026#34;, \u0026#34;自立\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;一段\u0026#34;, \u0026#34;未然形\u0026#34;, \u0026#34;覚える\u0026#34;, \u0026#34;オボエ\u0026#34;, \u0026#34;オボエ\u0026#34; ] }, { \u0026#34;text\u0026#34;: \u0026#34;ず\u0026#34;, \u0026#34;detail\u0026#34;: [ \u0026#34;助動詞\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;特殊・ヌ\u0026#34;, \u0026#34;連用ニ接続\u0026#34;, \u0026#34;ぬ\u0026#34;, \u0026#34;ズ\u0026#34;, \u0026#34;ズ\u0026#34; ] } ] Viterbiラティス出力 Kuromojiが内部でトークンをどのように切り出すかを計算するためのViterbiのラティスです。これをGraphvizというツールのDOTフォーマットのファイルとして出力できるメソッドがデバッグ用ですが、Kuromojiに用意されています。 こちらを呼び出して出力するオプション-v(もしくは--viterbi)を追加しました。 注意点として、このオプションを指定すると、DOTファイルが標準出力に出力され、トークンの結果は標準エラーに出力されます。\necho \u0026#34;春眠暁を覚えず\u0026#34; | build/graal/kuromoji -v \u0026gt; viterbi.dot .dotファイル自体は画像ではないので、Graphvizのdotコマンドにて画像ファイルに変換する必要があります。\ndot -Tpng viterbi.dot -oviterbi.png これで、PNGファイルが出来上がります。出来上がったファイルはこんな感じです。\n画像を見ていただくと、緑色のパスがあるのがわかります。 こちらが、Kuromojiが実際に採用した形態素のリストです。それ以外のパスは不採用だったパスとなります。\nちなみに、macOSで1行で画像表示まで行うにはこんな感じで実行します。 openコマンドでpreviewアプリを指定することで画像が表示できます。 Windowsは。。。わかりません、すみません。\n% echo \u0026#34;春眠暁を覚えず\u0026#34; | build/graal/kuromoji -v -o json | dot -Tpng | open -f -a preview.app まとめ これ以前に複数辞書対応などもしていました。 今回は2つの出力形式を追加してみました。 特にViterbiラティス出力については、内部的にどのようなコスト計算で最終的な結果が出てきているかという理解に役立ちます。想定していない切れ方の場合は、そもそも想定している形態素になっていないか、コスト計算で不採用だったかなどを確認できますので、使ってみると面白いかもです。\n","date":1586143600,"dir":"post/2020/","id":"6fbf7c3d0f4f89e415e89cec28811a94","lang":"ja","lastmod":1586143600,"permalink":"https://blog.johtani.info/blog/2020/04/06/update-kuromoji-cli/","publishdate":"2020-04-06T12:26:40+09:00","summary":"Kuromoji-CLIの使い方などについては過去のブログを御覧ください。 KuromojiのCLIコマンドとpicocliとGraalVM G","tags":["misc"],"title":"KuromojiのCLIコマンドにJSON出力とラティス出力を追加"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 第5章 構造体です。勝手知ったるなんとやら?オブジェクト指向的な部分は問題ないかなぁと。\n定義とインスタンス化 structで定義 インスタンスの生成は引数は順不同でOK 構造体のインスタンスを可変にするとフィールドの値も変更可能 特定のフィールドのみ可変にすることは不可能 インスタンス化する関数の最後でreturnなしでインスタンスの返却を暗黙にできる(return書いてほしいな。。。) インスタンス化時にフィールド初期化省略記法が可能(これはちょっと便利?) 構造体更新記法..user1のように、明示的に設定されていない他のフィールドをコピーしてくれる機能あり タプル構造体 タプル構造体!? struct Color(i32, i32, i32); いつ使うんだろう? ユニット様構造体 ユニット様構造体 = フィールドのない構造体。トレイトを実装したいけどインスタンスで持つ値はない場合に利用 ライフタイム 構造体が参照を持つときにライフタイムという話が出てくる。なるほど。 ライフタイム指定子が必要になる -\u0026gt; 10章での話 プログラム例 タプルを引数かぁ。タプルは慣れないので構造体作りそう Debugトレイトと{:?}という書き方 derive(Debug)でデバッグ用のトレイトを自動で実装=継承してくれる {:#?}だとpretty printになる(改行とか入る) この辺の便利なトレイとは付録Cにあるらしい。この辺はやりながら覚えるしかないか。\nメソッド記法 最初の引数は必ずself implは構造体とは別の場所に書く = Javaのクラスとは違う struct Rectangle { width: u32, height: u32, } impl Rectangle { fn area(\u0026amp;self) -\u0026gt; u32 { self.width * self.height } } 参照じゃないselfも使えるらしい。どういうときに使うんだろう? 関連関数 selfなしの関数をimplにかける。Javaのスタティックメソッドみたいな感じ その他 implブロックがあちこちにかける。これはつらいな。。。 2つにわかれたimplブロックに同じメソッドを書いてみたら、CLionのプラグインではエラーを検知してもらえなかった。 cargo buildではきちんとエラーが表示された。 複数のimplブロックが有用になるケースは第10章で見ますが、そこではジェネリック型と、トレイトについて議論します。\n人の構造体に自分のトレイトを適用したりもできる。 実験 スコープとかどうなりそう?って実験もしてみた。\nfn main() { trait Hoge { fn trim(\u0026amp;self); } impl Hoge for String { fn trim(\u0026amp;self) { println!(\u0026#34;hogehoge {}\u0026#34;, \u0026amp;self); } } let c = String::from(\u0026#34;hoge\u0026#34;); c.trim(); println!(\u0026#34;{}\u0026#34;, fuga(\u0026amp;c)); } fn fuga(d: \u0026amp;String) -\u0026gt; \u0026amp;str { d.trim() } 出力はこんな感じ\nhogehoge hoge hoge まとめ 気になったのは以下の点。そのうち分かるようになってくるのかな。\n構造体更新記法はどういったときに使うのを想定して作ったんだろう?とか 可変長引数はマクロじゃないとだめ ","date":1585807758,"dir":"post/2020/","id":"8d9c3760395e8e0eb40e335b22750b68","lang":"ja","lastmod":1585807758,"permalink":"https://blog.johtani.info/blog/2020/04/02/chap5-rust-the-book/","publishdate":"2020-04-02T15:09:18+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 第5章 構造体です。勝手知ったるなんとやら?","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第5章"},{"contents":"すもけさんが在宅勤務環境をブログに書いてておもしろそうだな(あと、アフィリンク貼れるな)と思ったので自分の環境も書いてみようかなと。\n私自身は昨今の新型コロナウイルスの影響というのではなく、もう10年以上自宅でも作業ができる環境を整えています。 前前職の頃から家でも仕事をすることがよくあったので。今は、お客さんに恵まれていてリモートができる形で働かせていただいてます。\n机周りはこんな感じです。机はこれも15年以上前から使用しているエレクターの机です。椅子も15年以上前から使っているアーロンチェア(購入時は高いと思ったけど、これだけ使えているので大満足)です。\nメインのPCはMac Book Pro16インチを使っています。それとは別にMac miniがMac bookの後ろに隠れています。こっちはブラウジングや音楽を聞いたりするために使っています。\nまずはディスプレイ周りから。\nディスプレイ周り ディスプレイ Acerの31インチディスプレイです。昨年の夏に購入しました。28インチの4Kディスプレイを探していたのですが、セールか何かで2-3000円の違いでこのサイズが買えたので、このサイズになっちゃいました。Mac Book ProはDisplay port-USB-Cケーブルで接続し、PS4をHDMIで接続しています。 【Amazon.co.jp 限定】Acer モニター ディスプレイ ET322QKwmiipx 31.5インチ マイクの左側に写っているのはAppleのサンダーボルトディスプレイです。縦にしてブラウザやミュージックプレイヤーなどで音楽かけながら仕事をしています。 サブディスプレイって感じです。 Mac Book ProとMac miniの両方を操作するのですが、できれば同じキーボード+トラックパッドがいいなということで、Synergyというソフトを使って、Mac Book Proのキーボードとマウスでネットワーク越しにMac miniを操作しています。ただ、マシンの再起動後などにこのソフトが起動していない場合もあるので、Mac Book Proの右側にMac miniのためのトラックパッドがおいてあります。\nディスプレイアーム ディスプレイはそれぞれディスプレイアームを使っています。写真のようにMac Book Proを下に、外部ディスプレイを上にという上下で作業をしています。 16インチの画面だと普通のディスプレイの足だとメインディスプレイにかぶってしまうので、アームに切り替えました。 最初はグリーンハウスの激安を使っていたのですが、31インチのディスプレイだとアームの高さが足りなかったので、2つ目のガススプリング式のアームを追加で購入しました。ガススプリング式なのに5千円しないので、かなりお得感があります。ただ、ディスプレイは基本的に動かさないので、どちらかというとディスプレイの足の部分を効率良く使うことが目的です。\nAmazon | グリーンハウス 液晶ディスプレイアーム 4軸 クランプ式 Amazon | HUANUO PC モニター アーム 液晶ディスプレイ アーム ガススプリング式 サウンド関連 スピーカー 基本、音楽を聞きながら作業をするので、小型だけどしっかりと音がでるスピーカーを買いました。スタイルもいいし気に入ってます。 入力が2系統あるので、31インチディスプレイのヘッドフォン出力とMac miniのからの出力の2つをつないでいます。 仕事中はMac miniで音楽流しつつ、テレカンやゲームのときはメインディスプレイからの音が出る形です。 Amazon | ヤマハ パワードスピーカー NX-50 マイク 前職がDeveloper Advocateということで、インタビューなどに行くこともあるかも?ということで小さめのも運びができるコンデンサマイクを購入してました。結局それほど持ち運びはしてないのですが、値段の割には音がいいんじゃないかな?一応、無指向と単一指向の2種類を切り替えることが可能です。\nAmazon | SAMSON マイク ポータブル USB コンデンサ Go Mic | コンデンサ | 楽器 マイクスタンド マイクはあったのですが、クリップ式でした。PCのディスプレイにクリップしていると、打鍵音を拾ってしまうので、マイクスタンドを最近導入しました。やすかったです。 前まではヘッドフォンのケーブルに付いているマイクで喋っていたのですが、服によってはマイクに擦れてしまい、ノイズが載っていました。 マイクスタンド+スピーカーでもスピーカーの音をマイクが拾わないので、最近はヘッドフォンを使用しないで気楽に話ができるようになっています。 Amazon | Luling Arts マイクスタンド アーム その他 モニタスタンド Mac Book Proの後ろで見えにくいですが、Mac miniが下に入っていて、上にMac mini用のキーボード、スピーカー、Qiの充電パッドが載せてあります。 Mac miniのキーボードをじゃまにならないように置きたいという目的で購入しました。3次元で空間が利用できるので結構重宝してます。 Amazon | サンワサプライ 机上液晶モニタスタンド(D200・黒) MR-LC303BK 充電関連 スマホ充電用にスピーカーの横においてあります。ただ、スイートスポットを探すのがちょっと大変で、時々充電できてないことがあったりします。。。 Amazon | DesertWest Qi 急速充電ワイヤレス充電器 【Qi認証済み/PSEマーク付き】15W USBでの様々な充電用にはMercariさんのカンファレンスでいただいたAnkerの充電器をおいてあります。Mi Band 4、キーボードなどの充電向けです。 Amazon | Anker PowerPort 6(60W 6ポート USB急速充電器) まとめ 簡単ですが作業環境でした。だいたい満足しています。もうちょっと改善したいなと思っているのは次の点です。\nUSB-Cドック?ハブ?みたいなものがほしい 充電ケーブル、マイク、ディスプレイケーブル、有線LANの4つのケーブルがMac Book Proに刺さっており、ポートが全滅です。出先から帰ったときにつなぐのも少し面倒なので、1つか2つのポートでまとめられるといいなぁと思っています。が、ドック系はいい値段するのでまだ置き換わっていない感じです。 スタンディングデスクが気になる 自宅でずっと座っているのはやはり気になるもので。スタンディングデスクにして時々たって作業したいなぁと思うことがあります。ただ、使ったことがないので、どれがいいのかわからず手を出せない状況です。 ウェブカメラいる? Mac Book Proのカメラでオンラインミーティングなどしています。気にするほどのことではないとは思いますが、メインディスプレイを見ながらしゃべると下からカメラで撮影されている形になります。。。 今のところはこんな形です。なにかの参考になればと。 あと、なにかおすすめのもの(特にスタンディングデスク)があれば教えて下さい!\n","date":1585217511,"dir":"post/2020/","id":"3f431bf71ee866f626daf42bc915fa3f","lang":"ja","lastmod":1585217511,"permalink":"https://blog.johtani.info/blog/2020/03/26/working-facility/","publishdate":"2020-03-26T19:11:51+09:00","summary":"すもけさんが在宅勤務環境をブログに書いてておもしろそうだな(あと、アフィリンク貼れるな)と思ったので自分の環境も書いてみようかなと。 私自身は","tags":["misc"],"title":"自宅の作業環境(2020)"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた 第4章 第4章です。たぶん、これがいちばん大事な概念だと思います、Rustの。 そして、つまみ食いしながらRust書いてましたが、ここがきちんと理解できないまま書いてたってのもあります。。。\n所有権とは? drop関数ってのがあって、明示的に呼ぶことも可能。次のような感じで。2つ目のprintln!はエラーになる。sがもう無いのに借用しようとしてるから。 fn main() { let mut s = String::from(\u0026#34;hello\u0026#34;); s.push_str(\u0026#34;, world!\u0026#34;); println!(\u0026#34;{}\u0026#34;, s); drop(s); println!(\u0026#34;{}\u0026#34;, s); } ムーブ - shallow copyではない。以下の2行目がムーブ。 let s1 = String::from(\u0026#34;hello\u0026#34;); let s2 = s1; println!(\u0026#34;{}, world!\u0026#34;, s1); スタックとヒープの話が絡んでくる。あんまり意識すること無いよなぁ。 スタック = 固定長のデータを入れる場所。ポインタ、数値など ヒープ = 可変長のデータが入る場所。可変の文字列とか。\nクローン - ヒープのデータをコピーすること。 コピー - スタックに収まるデータの場合はクローンが必要なくコピーで事足りる。 CopyトレイととDropトレイとは同居できない。 タプルのコピーはややこしそう 所有権と関数でまた、スタックに入れられるような変数と可変のオブジェクトの違いが出てくる。 takes_ownership(s: String)が参照を受け取れば問題なく、このあとも使える。 戻り値でもムーブが発生 参照と借用 借用 - 関数の引数に参照を取ること 可変な参照\u0026amp;mutは1つ(不変な参照も含めて1つ)しか許さない データの競合を防ぐため。 不変な参照を複数用いるのはOK 実際に変更が実行されるタイミングでエラーと判定される場合もある。 let mut s = String::from(\u0026#34;hello\u0026#34;); { let r1 = \u0026amp;mut s; } // r1はここでスコープを抜けるので、問題なく新しい参照を作ることができる let r2 = \u0026amp;mut s; ダングリング参照はテスト書くときとかにやってるかも。。。 fn dangle() -\u0026gt; \u0026amp;String { // dangleはStringへの参照を返す let s = String::from(\u0026#34;hello\u0026#34;); // sは新しいString \u0026amp;s // String sへの参照を返す } // ここで、sはスコープを抜け、ドロップされる。そのメモリは消される。 // 危険だ スライス型 部分的な参照。開始位置+長さで構成されているっぽい \u0026amp;strの説明がよくわからなかった。 引数としての文字列スライスのテクニックは色々と使いまわせそう。\nまとめ 所有権、これまで特に難しいと思ってたのは、固定長の変数と、可変長の変数の違いを意識してなかったのが原因っぽい。 まぁ、Vecとかがどうなるのかとか、他にもいくつか気になるところはあるので、もうちょっとやらないといけないなと思いました。\n","date":1585210331,"dir":"post/2020/","id":"7fded0345c258eea966c0b5ee1b7c7aa","lang":"ja","lastmod":1585210331,"permalink":"https://blog.johtani.info/blog/2020/03/26/chap4-rust-the-book/","publishdate":"2020-03-26T17:12:11+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた 第4章 第4章です。たぶん、これがいちばん大事な概念だと思","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第4章"},{"contents":"先日、Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)というブログを書きました。 このプラグインを作ってたタイミングで、Elasticの河村さん経由で、Microsoft Open Tech Night #9 w/ ElasticでなにかLTしませんか?という打診がありました。\n仕組み的には似たようなものだし、Elasticsearch用の拡張機能も作れるし、発表のネタにもなるし一石二鳥では?ということで、LTを快諾し、昨日発表してきました。\n資料とか 発表資料やGitHubのリポジトリなどは、以下のとおりです。\n発表資料 : Analyze APIのVS Codeプラグインを作ってみた GitHub Repository : https://github.com/johtani/vs-code-es-analyze-client Visual Studio Code Marketplaceページ 機能 まだ、必要最低限の機能を実装した感じです。\nAnalyze APIのパラメータ入力用のエディタ起動(Elasticsearch Analyze Client: Create Elasticsearch Analyze Request) Esにリクエストを送信して結果の表示 インストールからリクエスト送信して結果が出てくるまでのデモです。\n1点LTのデモのときに話すのを忘れていましたが、.esanalyzeという拡張子のファイルであれば、このプラグインが入力値を見つけ出して、「Analyze text with analyzers」というコマンド送信用のリンクをエディタ画面に表示する機能があります。 ですので、パラメータ入力用のエディタを起動し、値を設定したあとにファイルをhoge.esanalyzeというような名前で保存してもらえれば、後日そのファイルを開くことでリクエストが再送できます。\nAzure Search版との機能の違い 先日のAzure Search向けのクライアントとの違いがいくつかあります。 ElasticsearchのAnalyze APIの方が多機能であるため、プラグインとしても違いがあったほうがいいかなと。\n入力がJSON形式 結果画面に詳細表示切り替えボタンを追加 現時点では対応していませんが、Analyze APIはカスタムのtokenizer、filter、char_filterの設定を入力として受け付けることが可能です。そのときに指定するのはJSON形式でtokenizerなどの設定を記述します。 今後、これらの対応をすることを考えると、入力全体をJSON形式で読み込めるほうがわかりやすいかなということで、入力はJSON形式で入力してもらうことを想定しました。\n結果画面に詳細表示切り替えボタンを追加したのは、2つの理由があります。1つはAzure SearchのAnalyze APIよりもTokenの情報としていくつか他の情報も存在するためです。複数のAnalyzerとの比較をする場合は、単語列だけを比較したいですが、Analyzer個別の詳細情報を見たい場合もあるので、切り替えができたほうがよいかなと。 2つ目の理由はまだ実装していませんが、explainパラメータの出力への対応のためです。 explainパラメータを指定すると、カスタムAnalyzerの場合に、Analyzerの設定にあるchar_filter、tokenizer、token_filterのそれぞれのステップでの単語列の出力が結果として返ってきます。この結果には標準の出力よりもさらに多くのtokenの情報(例えば、kuromojiだと品詞情報、読み、原型など)が追加されてきます。これらの表示を切り替えることができたほうがよいかと。\nこれらは、実はKibanaのプラグインとしてすでに実装済みになっています。 同等の機能は実装できるかなという目論見もあり、そちらに合わせた感じにしてあります。\n今後の対応 現時点では、Analyzer名の指定のみが可能となっています。Kibanaのプラグインと同程度の機能はGitHubのIssueとして登録してみました。\nexplainパラメータ対応 fieldパラメータ対応 custom analyzer対応 その他に、インデックス名やアナライザ名の自動補完みたいな機能があると便利かも?と妄想していたりします(実装が大変かもですが。。。)。Kibanaのプラグインの場合は、Mappingやインデックス名を調べるときに、KibanaのConsoleからチェックすればよかったのですが、このプラグイン単体だとそのあたりの情報の取得に他のツール(Kibanaだったり、REST API Clientだったり)を使わないといけないという問題点はあるかなぁと。\nあとは、結果画面がこのままで本当に見やすいかどうか?なども気になってはいます。\nまとめ まだまだ、作ってみたというレベルのプラグインです。 どのくらいの人に使ってもらえるかもわかりませんが、こんな機能あるといい?など要望があればリクエストいただければと。 Twitterで聞いていただいてもいいですし、GitHubのIssueとして登録していただいても構いません。 そもそもいらないなぁなんて意見でももちろん大歓迎です。フィードバックお待ちしてます!\n","date":1585102205,"dir":"post/2020/","id":"a7f0e85fcad4f5bc5ae5c18c10de4f9e","lang":"ja","lastmod":1585102205,"permalink":"https://blog.johtani.info/blog/2020/03/25/vsc-es-analzye-plugin/","publishdate":"2020-03-25T11:10:05+09:00","summary":"先日、Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)というブログを書きました。 このプラグインを作ってたタイミン","tags":["elasticsearch","visual studio code"],"title":"ElasticsearchのAnalyze APIのVisual Studio Codeのクライアントプラグイン"},{"contents":"自転車本を読み始めましたが、その前にRust the bookを読んだほうが良いかも?と知り合いと話をしていてなったので、先にRust the bookを読み始めてます。 コツコツ読むってのが苦手なので、知り合いと小規模オンライン読書会しながら読むことになりました(基本的になにか書きながら、使い方を調べるので、存在そのものを知らない記述や使用法などがあったりする)。\n日本語版Rust the book Rust the book 基本は日本語版を読んでいます。まずは1章から3章あたり。\n気になった点などを。自分用のメモなので、読みやすさとかは考えてないです(あとで自分が死ぬパターン?)。\n1章 rustfmt便利。\nCLionのRustプラグインでは、保存時にrustfmtするというオプションがある。デフォルトはオフ。\u0026ldquo;Run rustfmt on Save\u0026rdquo; cargoの--binオプション。意識してつけたことなかった=デフォルトだった。\nライブラリにするときは--lib 2章 「変数を値に束縛」という言い回しにまだ慣れない。 「代入」という言い方に慣れているから? ただ、エラーにはassignってあるな。\u0026ldquo;error[E0384]: cannot assign twice to immutable variable x\u0026rdquo; preludeというのがデフォルトで読み込まれる型が存在する場所。 .expect()により、Resultが評価済みになる マクロがまだ慣れない extern crate rand;が最新版だと要らなくなっている。 rand::Rngはgen_rangeのためにuseしている。CLionだとかってにuseを推測して追加してくれた。 matchはswitch文みたいな感じ。けど、defaultが必ず実行されるって感じではないな。 ただし、全て網羅しないと怒られるのが便利。 アームという呼び方が新鮮 単一の式のときは{}が省略できる ブロック{}のときは、終わりにカンマを入力するとrustfmtが除去する(最後の条件かどうかは関係ない)。 シャドーイングは面白い。 よく、hoge_strやhoge_intのような変数を書くので、ありがたい。 ただし、コードを読むときに少し混乱しそう? let ... matchで変数への束縛でmatchが使えるのは便利(これまで知らなかったので、変数宣言して条件つけて束縛する処理書いてた)。 シャドーイング? fn main() { let x = 5; let x = x + 1; let x = x * 2; println!(\u0026#34;The value of x is: {}\u0026#34;, x); } とか\nlet spaces = \u0026#34; \u0026#34;; let spaces = spaces.len(); みたいに、同一変数名を使い回せること。再代入ではない\n3章 constは型注釈が必須 100_000のような記述が便利(Javaもできるって言われてびっくりしたw) タプルの中身を一部だけ書き換え可能。(mutを指定すれば) tup.0 = 20;のような感じで。 配列は固定長でかつ、同一の型のものだけが入る 文末にセミコロンがない場合に四季になるというのはちょっと射にくいので辛いのでは。。。 自分は明示的にreturnを書きたくなる。が、returnだと動かない場合もある。。。 let ... ifのような記述もできる。 (1..4)はRange型 おまけ フィボナッチ数列計算してみろというのがまとめにあったので。こんな感じでいいのかな?\nfn calc_fibonacci(n: usize) -\u0026gt; usize { if n == 0 { return 0; } else if n==1 { return 1; } else { return calc_fibonacci(n-1) + calc_fibonacci(n-2); } } その他 知り合いと読みすすめると、人が不思議に思ったところが、自分が理解が曖昧だったことなどに気づけて便利です。\n","date":1584928642,"dir":"post/2020/","id":"48b5ab9805919736382ffea5a9554c02","lang":"ja","lastmod":1584928642,"permalink":"https://blog.johtani.info/blog/2020/03/23/start-reading-rust-the-book/","publishdate":"2020-03-23T10:57:22+09:00","summary":"自転車本を読み始めましたが、その前にRust the bookを読んだほうが良いかも?と知り合いと話をしていてなったので、先にRust the bookを読","tags":["rust","読書","rust-the-book"],"title":"Rust the Bookを読み始めた"},{"contents":"動機 Azure Cognitive Searchを検索エンジンに使っているお客さんを手伝っています。 そこで、検索の基本的な話をさせていただきました(もともとJJUGナイトセミナーでしゃべる予定だったスライドがベース)。\nで、Elasticsearchなどの転置インデックスを利用している検索エンジンで検索の基本的な動作がどうなっているかを理解するのに、 個人的には一番重要だと思っているのがAnalysis(Analyze)の機能です。 転置インデックスの単語の切り出し方がどうなっているかによって、望んだ単語でうまく検索できているかいないかなどがわかります。\nAzure Cognitive SearchもAnalyze TextというAPIを提供してくれています(内部的にはElasticsearchだし)。 APIはあるのですが、返ってくる結果はJSONです。また、他のAnalyzerの設定との違いなどをみたくなったりもします。 やはり、普段使っているツールなどで簡単にどういう単語が出てくるかがわかるとうれしんじゃないかなぁ?と。\nということで、最初はPythonでちょっとAPI呼び出して、カンマ区切りで出力するものを作ってみたのですが、GUIとかあると便利かなぁという話になりました。 最近、ブログ書いたりするのにVisual Studio Codeを使い始めているので、これなら使いやすいかなと。 ということで、Visual Studio Codeの拡張機能(プラグイン?)としてインストールできるツールを作ってみました。 Azure Cognitive Searchを使っている人向けなので、ニッチなツールですが。。。\n余談 Elastic Stack(Elasticsearch)向けにはKibanaのプラグインでAnalyze APIを可視化するツールを作ってます。 analyze-api-ui-pluginです。Elastic Stack、特にKibanaを必ず利用する方はこちらを使うと便利かもです。\n概要と機能 GitHub リポジトリ Visual Studio Marketplaceのページ Marketplaceに公開しているので、johtaniやAzure Search Analyze Clientなどで検索してもらえれば出てきてインストールができます。\n機能としては、以下の2つです。\nテンプレートから入力値設定用のドキュメントを作成(Untitled-1というドキュメントをエディタに新しく開く) Azure Cognitive SearchのAnalyze Text APIを呼び出して、結果をHTMLのテーブル形式で表示 入力値設定用のドキュメント作成 APIの呼び出しに必要な情報を記入してもらうのに、いくつか案を考えました。\nプラグインの設定に記入してもらう 環境変数とかを読み出す テキストとして保存したファイルを使う 設定や環境変数だと、異なる環境に接続したりするときに、わざわざ設定し直すのがめんどくさいかもと。 で、愛用していたREST API Clientを真似するのが良いかもという結論になり、.analyzeという拡張子のファイルから必要な項目を読み出して、APIを呼び出す形にしてあります。\nCommand Palette(左下の歯車マークもしくは、メニューのViewから開ける)からAzure Search Analyze Client: Create Azure Search Analyze Requestというコマンドを選びます。\nすると、以下のようなファイルがエディタに開きます。\nこれらの項目をまずは埋めていきます。 それぞれの値がどういったものかはGitHubのREADMEを御覧ください。\n入力値エラー(存在チェックしかしていない)がある場合は、ダイアログが表示されます。\n結果表示 値を入力したら、設定値と###の間に表示されているAnalyze text with analyzersというグレーの文字をクリックします。すると、APIにリクエストを送信し、結果が返ってきて、別のパネルとして表示されます。\n複数のAnalyzerを入力値に設定すると、それぞれがどのような区切り方をするかがわかります。 文字の下にある[0:2]は、その単語がもとの文章の何文字目から何文字目までに出現しているかというオフセットの表示になります。\nもし、Analyzer名の設定ミスなどで指定されたAnalyzerがない場合は、結果画面にエラーが表示されるようにしています。\n以上が簡単な機能の説明です。 簡単なと言いつつ、これだけしか機能がありませんが。\nVisual Studio Codeのプラグインの作り方 プラグイン自体の作り方に関してはVisual Studio CodeのGetting Startedがわかりやすかったです。 APIや機能が豊富なので、最初はちょっと戸惑いましたが、サンプルもGitHubで多数公開されています。\nあとは、REST API Clientを参考にさせていただきました。\nGetting Startedを一通り読むことで、なんとなくプラグインの作成からMarketplaceへのリリースまでが完了できました。 (TypeScriptに慣れていないのがあるので、プログラミング自体は手間取りましたが。。。)\n今後の対応? いまのところ、こんなところを考えていますが、こんな機能がほしい、バグが有るなどあれば、GitHubにIssueを上げていただければと(使う人すくないだろうけど)。\nいろいろなエラーに関する対応 Readmeに画像をアップ アイコン作成? 自動補完機能? まとめ Visual Studio Codeの拡張機能を作ってみました。 Yeomanによるプロジェクトテンプレートが用意されているので、とりあえず、Hello worldを作るのは簡単でした。 試行錯誤しつつTypeScriptを書いたので、TypeScriptっぽくないところなどもあるかもですが、誰かの役に立つツールになってくれれば良いなぁと。\n","date":1584582615,"dir":"post/2020/","id":"c9d257aba54475c20b3737ce7c779e55","lang":"ja","lastmod":1584582615,"permalink":"https://blog.johtani.info/blog/2020/03/19/azure-search-analyze-plugin/","publishdate":"2020-03-19T10:50:15+09:00","summary":"動機 Azure Cognitive Searchを検索エンジンに使っているお客さんを手伝っています。 そこで、検索の基本的な話をさせていただきました(もともとJJUGナイ","tags":["azure search","visual studio code"],"title":"Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)"},{"contents":"これまで\n実践Rust入門はじめました 実践Rust入門の3章を読んでるところ 3章終了 3章の終わりまで読み終えた。\nいきなり実践的なプログラムで少し面食らっていたが、ステップを追って所有権周りの話まで来たので、 なんとなくRustのいいところが理解できたような気がする。\nただ、最後のsplit_at_mutが実際には内部でどういう形に変換することによって、コンパイルエラーにならずに、 借用がうまく行っているのかあたりは、まだきちんと理解できていない。\nこれは、どの言語にも言えるんだけど、リファレンスをうまく読み解きながら、 自分がやりたい処理ができるかどうかを考えるのって結構むずかしいなぁと思う。\nbenchmark.rsはコピペして実行しただけなので、またあとで読み返してみるかな。\nということで、ここから先は、基本を勉強する感じで4章から読みつつ、なんかプログラムをまた書いてみるか。\n","date":1583140813,"dir":"post/2020/","id":"6f47cb314fd780c122adb8cc1f44f785","lang":"ja","lastmod":1583140813,"permalink":"https://blog.johtani.info/blog/2020/03/02/finish-bicycle-book-chap3/","publishdate":"2020-03-02T18:20:13+09:00","summary":"これまで 実践Rust入門はじめました 実践Rust入門の3章を読んでるところ 3章終了 3章の終わりまで読み終えた。 いきなり実践的なプログラムで少","tags":["rust","読書"],"title":"実践Rust入門の3章を読み終わった"},{"contents":"Kuromoji-CLI Rust初心者がRust製の日本語形態素解析器の開発を引き継いでみたという記事にありますが、LinderaというRust製の日本語形態素解析が出てきました。KuromojiのRustクローンみたいなものです。 で、作者の人とのチャットの中で、「MeCabみたいなKuromojiのCLIないですかね？誰か知りませんか？」という話になりました。\n自分は普段はKuromojiの確認をするのは、Elasticsearch関連もしくは、Azure Searchなどだったりするので、 当たり前のようにKibanaを立ち上げたり、REST APIを叩いてましたが、たしかにコマンドラインインタフェースあると便利かも? と思い、作ってみるかということに。\npicocli いま、JavaでかんたんなCLI作るとなったら何がおすすめ？\n\u0026mdash; Jun Ohtani (@johtani) February 26, 2020 で、いつものツイートです。で、picocliという返信がありました。 JavaでCLIのプログラムを書くのが簡単になりそうだと。 ドキュメントもしっかりしてます。サンプルも載ってるし。\nAnnotationで、コマンドの説明などパラメータ、オプションなどが記述でき、必須チェックなども可能です。\nまた、オプションの説明文に関しては、テンプレートを用いることで、取りうる値をEnumの値で出力してくれたりといった便利機能まで備わっていました。\nGraalVM また、GRAALVMとPICOCLIでJAVAのネイティブコマンドラインアプリを作ろうというスライドも教えてもらい、ネイティブコマンドまで作れるらしいと。 なんて便利なんでしょう!ってことで、こちらもチャレンジしてみました。 GraalVMがどんなものかはなんとなくは知ってたのですが、何者だろう?とツイートしたところ、これまた返信が。\nっ 資料はかなり古いので現行版と乖離はあるけど概念は変わってないので..https://t.co/KRQjhNdD9f\n\u0026mdash; たむたむ🏫 (@tamtam180) February 26, 2020 本当に、Twitter便利ですね。\nGraalVMがどんなものかもいただいた資料でサクッと理解できました。 ただ、picocliが実はものすごく良くできており、自分でインストールする必要も実はありませんでした。\ngradle-graalというGradleのプラグインと、 Picocli Code Generationを利用することで、 以下のコマンドを実行することで、ネイティブコマンドアプリが作成できました。\ngradle nativeImage build.gradleファイルに記述したのは、以下のような項目です。\npluginの利用 picocli-codegenをannotationProcessorとして呼び出し jarに関する記述(メインクラスと依存するJarを含める設定) ネイティブコマンドの名前とか(gradle-graalの設定) 辞書が読み込めなかった で、native imageを作って実行しましたが、Kuromojiが内包している辞書ファイルが読み込めませんでした。 どうやら、picocli-codegenの自動生成では対応できない、リソース関連設定が必要らしいと。\npicocli-godegenの設定を見ていて見つけたのが、other.resource.patternsというオプションでした。\nkuromoji-cliのbuild.gradleに、その設定を加えたら辞書が読み込めるようになりました。\nこの設定をどうやって書くのか?というのを探すのにちょっと時間がかかりました。Picocli作者のRemko Popmaさんのサンプルリポジトリに設定を利用したbuild.gradleがありました。サンプル本当にありがたいですね。\n完成 出来上がったのは、kuromoji-cliというリポジトリになります。 内部で利用しているのはAtilikaのKuromojiです。LuceneのKuromojiではないのでご注意を(LuceneのKuromojiで最初やってみたのですが、リフレクションなどが多用されてて、Single Imageにするのが手間がかかりそうだった)。 コマンドのポータビリティはそれほど無いと理解してる(あってる?)ので、利用してみたい方は、リポジトリをクローンしてからビルドしてみてください。\n参考資料 kuromoji Picocliドキュメント Getting Started GraalVM / GraalVM超入門 一体何モノなの? GraalVM入門編 / GraalVM for beginners まだ途中? ほかにもあると便利かも?という機能があればIssueやPRを上げてください。 とりあえず、頭にあるのは以下のとおりです。\nJSONの出力はまだ未対応 いろんな辞書をAtilikaのKuromojiはサポートしてるのでそのへんも対応してみる? ","date":1582858179,"dir":"post/2020/","id":"d710a073be2da219a388a150eb7b6b6a","lang":"ja","lastmod":1582858179,"permalink":"https://blog.johtani.info/blog/2020/02/28/kuromoji-cli/","publishdate":"2020-02-28T11:49:39+09:00","summary":"Kuromoji-CLI Rust初心者がRust製の日本語形態素解析器の開発を引き継いでみたという記事にありますが、LinderaというRust製の日本語形態素解","tags":["misc"],"title":"KuromojiのCLIコマンドとpicocliとGraalVM"},{"contents":"これまでのはこちら。読書メモなので、本と合わせて読んでいただくのが良いです。\n実践Rust入門はじめました 3章のクイックツアーを読んでます。 バイトニックソート自体の理解はちょっとおいておいて、読み進めています。 いくつか疑問に思ったことがあったので、またメモを。 まだ、3.5.7の手前ですが。\n疑問点 3.4.1のジェネリクス対応のテストケースの部分で、既存のu32用のテストケースの入力のデータ列にVec\u0026lt;u32\u0026gt;という型注釈をつけるのですが、 追加した文字列の入力データには注釈をここではつけないのはなんでなんだろう?ちなみに、なくても動いた。バージョンの違いとかあるのかしら?\n3.4.6のmatch文\nmatch文の引数?が*orderになっていたが、orderでも実行できた。引数にくるのが参照だから*が付いてるんだとも運だが、なくても動くのはコンパイラがよしなに解釈してくれてるからかな? 便利なツール Rust標準のツールの説明がいくつか3章で紹介されてて便利だったのでメモ。\nrustfmt フォーマッター。デフォルトでフォーマット機能が付いてるの便利ですね。言語として決まってると、プロジェクトごとに悩まなくていいってのがありますし。\nrustfmt ファイル名 という形で使えるみたい。 プロジェクトごとだとcargo fmtのほうが楽そうかな。\n標準ライブラリAPIドキュメントをブラウザで閲覧 rustup doc --std これでデフォルトブラウザでRustの公式ドキュメントが開きます。 しかもローカルファイルだからサクサク。検索バーもついてて便利です。\nエラーのドキュメントを閲覧 rustc --explain 308 コンパイル時にエラーが出たときに、error[E0308]のようにコンソールに出てきます。 ヒントも出てくるのですが、詳細が上記のコマンドで読めるみたいです。\n","date":1582443437,"dir":"post/2020/","id":"71cf83ae0f45e9ede3a3f979b9c74933","lang":"ja","lastmod":1582443437,"permalink":"https://blog.johtani.info/blog/2020/02/23/bicycle-book-chap3/","publishdate":"2020-02-23T16:37:17+09:00","summary":"これまでのはこちら。読書メモなので、本と合わせて読んでいただくのが良いです。 実践Rust入門はじめました 3章のクイックツアーを読んでます。 バ","tags":["rust","読書"],"title":"実践Rust入門の3章を読んでるところ"},{"contents":"もう2020年2月になってしまってますが、2019年に買って便利だったもの良かったものをいくつか記録に残しとこうかなと。\nBRAVIA KJ-55X9500G Amazon | ソニー SONY 49V型 液晶 テレビ ブラビア 4Kチューナー内蔵 テレビをやっと買い替えました。 前に使っていたのはプラズマディスプレイで、10年以上たったもので、パネルの一部が赤い残像が残ってたりしました。 もう流石にいいでしょうということで、買い替えたのがSonyのテレビです。 4Kのチューナーもついているし、アップコンバーターもついているので普通の地上波でもきれいです。 まぁ、10年前のテレビに比べればたくさんいいことがありますよねw\n新しいTV買って一番活躍してるのはYouTubeボタンだったりします。 最近はミュージックビデオがYouTubeにたくさんあるので、King Gnuなどの音楽流したりするのに便利です(テレビなのに)。 今は、プライムビデオボタンがより活用される感じになってきてます(テレビなのにw)。\nSodastream Amazon｜スピリット ワンタッチ ホワイト スターターキット ここ数年、炭酸を普段飲んでます。甘いもの飲まないようにって意味でも。。。 で、これを買うまでは、サントリーの天然水スパークリングレモンとかを、箱買いしてました。 が、まぁ、ペットボトルのゴミが半端ないんですよ。場所も取るし。\nソーダストリームのことは知ってたのですが、自分で炭酸の量を考えながら、入れないといけないので避けていました。\nが、今回購入したものは、水の入ったボトルを指して、ボタン一つで3段階の炭酸を入れることができるんです!買って本当に重宝してます。うちでは1Lのボトルを1本追加して、2本で運用してます。 家族はなっちゃんのオレンジとかを炭酸割りしたり、カルピスソーダ作ったりして楽しんでます。 ワンタッチということで、簡単に入れられるので家族も重宝してます。\nNature Remo + Chromecast Amazon | Nature スマートリモコン Nature Remo mini Remo-2W1 Google Home miniがキャンペーンで手に入ったので、ベッドルームの照明やクーラーの操作もできそうなのでNature Remoを導入しました。 Chromecastは余っている液晶モニターにつないで、スマホからキャストできるようにしたり、音楽聞けるようにしてあります。\nNature Remoは温度計などもついているので、部屋の温度に合わせてエアコンのオンオフなども可能で、 暑い夏にとても便利でした。寝る時間にはクーラーが入っているのですんなり寝れたりと。 スマホから電源オンオフできるのも便利ですね。 Chromecastはモニターにつなぎましたが、今は、Google Music Playのプレーヤーになってます。 (最近、家にあるCDを読み込んでGoogle Play Musicにアップしてる)。\nただ、それ以上のことには使えてないので、もうちょっと面白いことしてみないとなぁ。\nモニターアーム Amazon | HUANUO PC モニター アーム 液晶ディスプレイ アーム ガススプリング式 Amazon | グリーンハウス 液晶ディスプレイアーム 4軸 クランプ式 ディスプレイがふるくなってたので、4Kディスプレイに買い替えた(27インチで4万切るとかで安い。。。)んですが、Mac Book Pro 15インチ(今は16インチ)を使っていて、Macの画面がディスプレイにかぶるので モニターアームを買いました。 1つ目がガススプリング式のアームです。なのに、5000円を切ってるんですよ。おそるべし。 2つ目はクランプ式です。アームにしたものの特に動かすことはなく、高さを出したいだけってことがあるので、クランプ式のも使ってます(家ではディスプレイ2枚使ってる)。 コスパ最高です。\nAnker PowerCore 10000 PD Amazon | Anker PowerCore 10000 PD（10000mAh PD対応最小最軽量 大容量 モバイルバッテリー） Pixel 3にしてから、電池の持ちはよくはなってるんですが、もしもの時のためにモバイルバッテリーは話せないですよね。 PD対応なので、Pixel 3に急速充電ができるし、サイズもそれほどじゃまにならないサイズなので便利です。USB-Aもついているので、このあと紹介するイヤホンの充電ケーブルなんかも差し込めて大活躍です。\nサウンドピーツのイヤホン Amazon | SOUNDPEATS(サウンドピーツ) Q35HD ワイヤレス イヤホン 高音質・低遅延 IPX8防水 私が持ってるのはこの前のバージョンで、micro-USBで充電充電するタイプですが、こちらもコスパ最高です。 冬は防寒も兼ねてヘッドフォンをしているのですが、春から秋にかけてはこれまで、優先のイヤホンを使ってました。もしくは、Bluetoothのレシーバーに優先のイヤホンつけてました。電池切れたら、イヤホンさして使う感じで。 が、Pixel 3はイヤホンジャックがありません。ということで、ワイヤレスイヤホンに移行するかということで選んだのがこちらです。 世の中的には、完全ワイヤレスイヤホンが流行っていますが、片方無くなってしまうイメージしかわかなくて。。。 これが壊れても、完全ワイヤレスではなくつながったワイヤレスイヤホンを使うと思います。\nヘッドルーペ Amazon | Tumao ヘッドルーペ ルーペ メガネ LED付拡大鏡 眼鏡の上装着 メガネゴムバンド両用 5レンズ交換調節 プラモデルをちょいちょい作るんですが、もう年ですね。。。細かいところが見にくくて。 ガンダムのRG系のプラモデルだと、1/144なんですよ。小さいんですよ。見えないんですよ。。。\n完成しましたー！ pic.twitter.com/S9QTS4kJDI\n\u0026mdash; Jun Ohtani (@johtani) February 16, 2020 ということで、ヘッドルーペ導入してみました。 最初は、卓上に置けるルーペにしてみたんですが、自分がルーペがあるところに動かないといけないの結構つらくて。 これのおかげで、プラモデル作成に問題はなくなりました。老眼とは関係なく、ちょっと猫背になっちゃうのが今は悩みの種ですが。。。こたつで作ってるからなぁ。\nまとめ ということで、いくつかよかったものを紹介してみました。 今年はちゃんと年末に書こう。。。\n","date":1582272302,"dir":"post/2020/","id":"daa3fe935b0be9f31b6b362ad9e0d2d6","lang":"ja","lastmod":1582272302,"permalink":"https://blog.johtani.info/blog/2020/02/21/best-buy-2019/","publishdate":"2020-02-21T17:05:02+09:00","summary":"もう2020年2月になってしまってますが、2019年に買って便利だったもの良かったものをいくつか記録に残しとこうかなと。 BRAVIA KJ-55X9500G Amazon | ソニー SONY 49","tags":["買い物"],"title":"2019年に買ってよかったもの"},{"contents":"ブログ移行日記(その5)です。前回まではこちら\nブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4) 今回はこれまでとは異なる特殊な話です。\n最初にブログを書き始めたときに利用していたのがJugemのブログでした。 その後、Octopressに移行して、今年、Hugoに移行したという流れです。\nで、よくよく考えると、Jugemのブログも移行できるんじゃないか?となりました。 じゃあ、やってみるかと。なので、今回のブログは自分の備忘録です(興味のない人が大多数じゃないかな)。 一応、Pythonで書いたプログラムはGitHubに上がっています。文字列置換と正規表現のオンパレードです。\nJugemからExport まずは、移行元のデータが取り出せるかどうかを調べたところ、text形式もしくはXML形式でエクスポートが可能でした。\n変換処理が必要なはずなので、XMLでダウンロードします。 独自のXMLですが、記事ごとにXMLのタグ(\u0026lt;entry\u0026gt;)でまとめられているので、処理が楽です。\nXMLをMarkdownに \u0026lt;entry\u0026gt;タグの下に次のような項目が入っているので、抜き出します。\nヘッダ部 title - 記事タイトル author - 著者 category - タグ date - 投稿日付 description : 本文(先頭部分) sequel : 本文(つづき) titleからdateまでをHugoのMarkdownのヘッダ部分として出力します。 日付は形式が違うので合わせるように変換し、 titleは(Jugemより移植)という文字列を追加しました。\nまた、Hugoの個別のコンテンツにするためにそれぞれをMarkdownのファイルに変換しています。 ファイル名は変換後のdateの先頭10文字(yyyy-MM-dd)に-を付け加えて、 タイトルを追加しました。ホントは英語のファイル名にしたかったんですが、ちょっと手抜き。ファイル名に使用できないような文字は-に置換しています。\n本文 本文部分はもう少し複雑です。 まずは、descriptionとsequelから抜き出した文字列を結合します。\nで、内部の文字列に次のようなものがあるので、それぞれMarkdownに変換したりという処理を書いてます。\nHTMLのheadingタグをMarkdown形式に br、hr、del、strongなどのタグもMarkdown形式に aタグの処理 Amazonのアフィリエイトタグの処理 ul、olタグの処理 などです。 アフィリエイトタグは、数行に渡るの複数のHTMLタグで記述されているので、 ASINと商品タイトルだけを抜き出しています。 Hugoでアフィリエイトのリンクを作るために、hugo-amazon-jpという公開されているshortcodeを元に、カスタマイズしたものを使っています。 これ用に、必要なASINとタイトルを別ファイルに出力したりしています。\nまた、いくつか画像を使っている記事があったのですが、これが曲者でした。 XMLに入っているimgタグに画像へのURLがあるのですが、アクセスしても存在しないURL担っています。。。 ブログで公開している画像のファイル名に似たものがXMLに入っていたので、URLを組み直して、ダウンロードするという処理も書いています。\nあとは、昔ちょっと凝った書き方(spanタグで章みたいなことやってた)をしていた部分の処理を加えて完成です。\nまとめ 元のXMLを見たり、抜き出したファイルを見ながら、トライアンドエラーでプログラムを書きました。 なんとなく変換できたなかっていうところで、取り込んで公開しました。 まだ、全部の記事をチェックしてないですが、なんとなく移植できたので一旦これでいいかなと。 昔の記事を見たときにおかしい場所があったら手で治すつもりでいます。\nなんか、もうちょっとうまくプログラムかけた気もしますが、書き捨てのプログラムだと思うのでこんなもんかな。\n1点気になっているところは、コメントの部分です。 ブログにコメントをいただいていたのですが、その部分は移植できてないです。\nOctopresに移植していこうは、Disqusのサービスでコメント部分を提供しています。ここに移植するのも変な話だなぁと思っているので、本文にコメントを取り込む感じかなぁ？\nもともとのJugemのサイトもそのまままだ残してあるので、そのうち気が向いたらで。\n","date":1582254240,"dir":"post/2020/","id":"ef8a399c9679ce4e9710c7c6ecf8bcc7","lang":"ja","lastmod":1582254240,"permalink":"https://blog.johtani.info/blog/2020/02/21/import-jugem-posts/","publishdate":"2020-02-21T12:04:00+09:00","summary":"ブログ移行日記(その5)です。前回まではこちら ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4","tags":["hugo","ブログ"],"title":"ブログ移行日記(その5) - Jugemのブログを移行"},{"contents":"お手伝いしているお客さんがAzure Cognitive Searchを利用してます。 検索周り=Azure Cognitive Searchに関する手伝いをする形で入っており、 いくつか触った感触をブログにまとめてみようかと(お客さんからはOKいただいてます)。\nAzure Cognitive Searchとは？ 公式サイト 「AIを活用した」クラウド検索サービスと紹介されています。\n昔はAzure Searchと呼ばれていましたが、ここ最近はAzure Cognitive Searchと呼ばれているみたいです(Microsoft Igniteで発表された話がまとまっているページもあります)。 もともと、検索エンジンのSaaSサービス(キーワード検索、あいまい検索、オートサジェスト、スコアリングなどの機能)として作られていた部分に、データの登録パイプラインにCognitive Serviceの便利な機能を簡単に使えるようにしたものというイメージでしょうか。\nバックエンドはElasticsearchのはずです。変わってなければ。 昔、Elastic社主催のユーザーカンファレンスでMSの方が公演された資料が公開されていたりします。 ちなみに質問が多いのでしょうか、Azure Cognitive SearchとElasticsearchの違いはなんですか?というページがよくある質問のページに用意されていました。参考までに。\n今回はちょっとしたインデックスをつくって検索する部分を紹介してみようかと思います (Cognitiveなところは機会があればまた)。\n普通の使い方については、Azureのドキュメントなどを読んで頂く形にします。 ポータルと呼ばれるブラウザ上でAzureのサービスを触ることができる画面が用意されています。 ここで、簡単な操作(インデックス作成、フィールドの追加)\nAPIを使ってインデックス(特にAnalyzer)の設定をしたり、データをいれて、クエリしてみるというところをサクッと紹介しようと思います。\nインデックスの作り方 インデックス作成に関するドキュメントも用意されています。最初はポータル(GUI)でインデックスを作成する方法が紹介されています。 ですが、今回はn-gram(n=2)のAnalyzerを利用したかったので、GUIではなくAPIでインデックスを作成しました。 カスタムアナライザーを利用する場合、REST APIを利用しなければ行けないということになっています。 n-gramのAnalyzerを含むインデックス生成のREST APIは以下のとおりです。こちらを実行することで、インデックスが作成されます(JSONの記述ミスなどがある場合はエラーが返ってきます)。\n@host = \u0026lt;サーチのサービス名\u0026gt;.search.windows.net @api-key = \u0026lt;APIキー\u0026gt; ### POST https://{{host}}/indexes/?api-version=2019-05-06 Content-Type: application/json api-key: {{api-key}} { \u0026#34;name\u0026#34;:\u0026#34;ngram-test\u0026#34;, \u0026#34;fields\u0026#34;:[ { \u0026#34;name\u0026#34;:\u0026#34;id\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;Edm.String\u0026#34;, \u0026#34;key\u0026#34;:true, \u0026#34;searchable\u0026#34;:false }, { \u0026#34;name\u0026#34;:\u0026#34;ngram\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;Edm.String\u0026#34;, \u0026#34;searchable\u0026#34;:true, \u0026#34;analyzer\u0026#34;:\u0026#34;bi_gram_analyzer\u0026#34; } ], \u0026#34;analyzers\u0026#34;:[ { \u0026#34;name\u0026#34;:\u0026#34;bi_gram_analyzer\u0026#34;, \u0026#34;@odata.type\u0026#34;:\u0026#34;#Microsoft.Azure.Search.CustomAnalyzer\u0026#34;, \u0026#34;tokenizer\u0026#34;:\u0026#34;bi_gram_tokenizer\u0026#34;, \u0026#34;tokenFilters\u0026#34;:[ \u0026#34;lowercase\u0026#34; ] } ], \u0026#34;tokenizers\u0026#34;:[ { \u0026#34;name\u0026#34;:\u0026#34;bi_gram_tokenizer\u0026#34;, \u0026#34;@odata.type\u0026#34;:\u0026#34;#Microsoft.Azure.Search.NGramTokenizer\u0026#34;, \u0026#34;minGram\u0026#34;:2, \u0026#34;maxGram\u0026#34;:2 } ] } なんだかどこかで見たことのある記述のようなそうでないような。。。 Analyzerは、charFilters(0以上複数可)、tokenizer(1つ必須)、tokenFilters(0以上複数可)から構成されます。 フィールドで指定するのはAnalyzerなので、まずanalyzersにCustomAnalyzerの設定を行います。 名前はbi_gram_analyzerにしました(好きに付けてください)。 tokenizerにはこのあと設定するtokenizerの名前を設定します。ここでは、bi_gram_tokenizerという名前にしています。 また、大文字小文字を気にせずに検索したいため、tokenFiltersにlowercaseを指定しています。こちらはすでに定義済みのため、定義済みの名前で呼び出すだけで使用できます。\n次が、bi_gram_tokenizerの設定です。 n=2としたいので、tokenizers配下にTokenizerの設定をします。 @odata.type\u0026quot;:\u0026quot;#Microsoft.Azure.Search.NGramTokenizerがTokenizerの名前です(ちょっと独特な名前ですね)。 Tokenizerごとにオプションがあり、NGramTokenizerの場合は、minGram、maxGramがオプションに相当します。 今回は2文字ごとにトークンを出力したいので、minとmaxをそれぞれ2としています。\nこれで、あとは、フィールドでanalyzerという設定にbi_gram_analyzerを指定すればそのフィールドはbi_gram_analyzerを使用してアナライズされるようになります(このへんはElasticsearchといっしょですね)。 フィールドは文字列を扱うので、Edm.Stringというタイプにしてあります。データ型については、フィールドコレクションとフィールド属性というドキュメントを参考に設定しましょう。\n閑話休題 - REST Client Exstension for Visual Studio Code なお、今回のサンプルはREST Clinet Extention for Visual Studio Codeを利用する想定の記述になっています。\nVisual Studio Codeで.restもしくは.httpというファイルに以下のAPIを記述すると、Send RequestというリンクがURLの上部に出てくるような拡張機能です。REST APIにリクエストするときに便利なツールになっています。 変数も使えるので、APIのキーやURLの一部をこのように共通化して、他の環境でも使いやすくできるのは素晴らしいなと。\nアナライザーの挙動の確認 設定したAnalyzerがきちんと機能しているかというのを確認する必要があります。 入力した文字列がきちんと想定している単語として切り出されて、転置インデックスの見出し語に使われるかというのが重要になるからです。\nAzure Cognitive Searchでもアナライザーのテスト用APIが用意されています。 使い方はこちら。 APIの仕様のページもありました。 「アナライザーの挙動はどんな感じ？」という文字列が、作成したインデックスの定義したアナライザーbi_gram_analyzerにより、 どのように分割されるかを確認するAPIの呼び出しは以下のとおりです。\n### POST https://{{host}}/indexes/ngram-test/analyze?api-version=2019-05-06 Content-Type: application/json api-key: {{api-key}} { \u0026#34;analyzer\u0026#34;:\u0026#34;bi_gram_analyzer\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;アナライザーの挙動はどんな感じ？\u0026#34; } レスポンスはこんな形です。ヘッダ部分は省略してあります。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;https://{{host}}.search.windows.net/$metadata#Microsoft.Azure.Search.V2019_05_06.AnalyzeResult\u0026#34;, \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;アナ\u0026#34;, \u0026#34;startOffset\u0026#34;: 0, \u0026#34;endOffset\u0026#34;: 2, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;ナラ\u0026#34;, \u0026#34;startOffset\u0026#34;: 1, \u0026#34;endOffset\u0026#34;: 3, \u0026#34;position\u0026#34;: 1 }, { \u0026#34;token\u0026#34;: \u0026#34;ライ\u0026#34;, \u0026#34;startOffset\u0026#34;: 2, \u0026#34;endOffset\u0026#34;: 4, \u0026#34;position\u0026#34;: 2 }, { \u0026#34;token\u0026#34;: \u0026#34;イザ\u0026#34;, \u0026#34;startOffset\u0026#34;: 3, \u0026#34;endOffset\u0026#34;: 5, \u0026#34;position\u0026#34;: 3 }, { \u0026#34;token\u0026#34;: \u0026#34;ザー\u0026#34;, \u0026#34;startOffset\u0026#34;: 4, \u0026#34;endOffset\u0026#34;: 6, \u0026#34;position\u0026#34;: 4 }, { \u0026#34;token\u0026#34;: \u0026#34;ーの\u0026#34;, \u0026#34;startOffset\u0026#34;: 5, \u0026#34;endOffset\u0026#34;: 7, \u0026#34;position\u0026#34;: 5 }, { \u0026#34;token\u0026#34;: \u0026#34;の挙\u0026#34;, \u0026#34;startOffset\u0026#34;: 6, \u0026#34;endOffset\u0026#34;: 8, \u0026#34;position\u0026#34;: 6 }, { \u0026#34;token\u0026#34;: \u0026#34;挙動\u0026#34;, \u0026#34;startOffset\u0026#34;: 7, \u0026#34;endOffset\u0026#34;: 9, \u0026#34;position\u0026#34;: 7 }, { \u0026#34;token\u0026#34;: \u0026#34;動は\u0026#34;, \u0026#34;startOffset\u0026#34;: 8, \u0026#34;endOffset\u0026#34;: 10, \u0026#34;position\u0026#34;: 8 }, { \u0026#34;token\u0026#34;: \u0026#34;はど\u0026#34;, \u0026#34;startOffset\u0026#34;: 9, \u0026#34;endOffset\u0026#34;: 11, \u0026#34;position\u0026#34;: 9 }, { \u0026#34;token\u0026#34;: \u0026#34;どん\u0026#34;, \u0026#34;startOffset\u0026#34;: 10, \u0026#34;endOffset\u0026#34;: 12, \u0026#34;position\u0026#34;: 10 }, { \u0026#34;token\u0026#34;: \u0026#34;んな\u0026#34;, \u0026#34;startOffset\u0026#34;: 11, \u0026#34;endOffset\u0026#34;: 13, \u0026#34;position\u0026#34;: 11 }, { \u0026#34;token\u0026#34;: \u0026#34;な感\u0026#34;, \u0026#34;startOffset\u0026#34;: 12, \u0026#34;endOffset\u0026#34;: 14, \u0026#34;position\u0026#34;: 12 }, { \u0026#34;token\u0026#34;: \u0026#34;感じ\u0026#34;, \u0026#34;startOffset\u0026#34;: 13, \u0026#34;endOffset\u0026#34;: 15, \u0026#34;position\u0026#34;: 13 }, { \u0026#34;token\u0026#34;: \u0026#34;じ？\u0026#34;, \u0026#34;startOffset\u0026#34;: 14, \u0026#34;endOffset\u0026#34;: 16, \u0026#34;position\u0026#34;: 14 } ] } このAzure SearchのAnalyze API、使用できるオプションはすくないですが、ElasticsearchのAnalyze APIと似ています。\nデータの登録の仕方 データ登録もAPIからできます(あたりまえですね)。 APIは1件ずつではなく、バルクで登録できる形で提供されています。\nサンプルとしては、以下のような形です。 @search.actionの部分(searchがあるとわかりにくい気がするけど。。。)が、ドキュメントの登録、更新、削除の命令を書き込むところになります。 今回は単純に登録するだけなので、uploadを指定しました。 ほかにもいくつかアクションが用意されています。用途に合わせて指定する感じになります。 id、ngramはそれぞれフィールド名です。ドキュメントに登録したい値を記述します。\nPOST https://{{host}}/indexes/ngram-test/docs/index?api-version=2019-05-06 Content-Type: application/json api-key: {{api-key}} { \u0026#34;value\u0026#34;: [ { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;ngram\u0026#34;: \u0026#34;新しいAzure Searchの使い方\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;ngram\u0026#34;: \u0026#34;Elasticsearchの紹介\u0026#34; } ] } 検索クエリ 最後は検索クエリです。 検索クエリはいくつかのオプションがあります。 ざっくりだと、queryTypeがsimpleとfullという2種類が用意されており、ちょっとした検索を作る場合はsimpleで事足りそうという感じです。 入力された単語(スペース区切りで複数扱い)をフィールド(複数可)に対していずれかの単語を含むもしくは、すべての単語を含むという検索に行くというパターンですね。 このときの、「いずれか」か「すべて」の設定がsearchModeというパラメータになります。 anyの場合、Googleの検索と同様に、どれかの単語が入っているドキュメントが対象に、allの場合すべての単語が含まれるドキュメントだけがたいしょうになるといった形です。\nqueryType=fullの場合はLuceneの構文でクエリがかけます。ElasticsearchのQuery String Queryみたいな形です。\n簡単なサンプルは次のような感じです。このサンプル\nPOST https://{{host}}/indexes/multi-field-test/docs/search?api-version=2019-05-06 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#39;ngram:\u0026#34;使い方\u0026#34; ngram:\u0026#34;紹介\u0026#34;\u0026#39;, \u0026#34;queryType\u0026#34;: \u0026#34;full\u0026#34;, \u0026#34;searchMode\u0026#34;: \u0026#34;any\u0026#34; } すこしだけクエリの補足を。 searchに入力された単語をダブルクォートで囲んでいます。これは、「使い方」という文字がbi_gram_analyzerにより「使い」「い方」に 分割されるのですが、必ずこの順序で出現したものだけを検索対象にしたい(フレーズ検索)という意味になります(*bi_*gramなので、「紹介」に関してはダブルクォートは厳密には必要ないです)。\nあと、レスポンスは今回記載していませんが、@search.scoreという項目で、スコアが返ってきます。 デフォルトのスコア計算には何を使ってるんだろう?ドキュメントにはTF-IDFとの記述があるのですが。。。カスタマイズもできそうです。\n少しオモシロイと思ったのは、スキーマ(インデックスの設定)に定義されているが、ドキュメントとしては登録していない項目についても、 Azure Cognitive Searchはドキュメントのフィールドがnullという形で返ってくるようでした。 そもそもフィールドが存在しないドキュメントとフィールドの値がnullのものの違いは無いようです。\n簡単ですが、インデックスの設定、ドキュメントの登録、検索の方法の紹介でした。\nちょっと触った感想 一番売りである、Cognitiveの部分はまだ触っていないです、すみません(こっちが売りな気もするんですが)。 検索エンジンの部分としては、Elasticsearchを知っていると、「あー、そんな感じね」という気持ちになれるサービスです。 個々のAPIやデータの形式は異なるので、きちんとAPIのリファレンスなどを確認しつつという形になりますが、なんとなくこういうAPIなどがありそうだな?と予測しつつ使えるかなと。 内部的にはElasticsearchだと思いますが、独自のAPIでラップされているおかげで、バージョンの違いなどを意識せずに使えるのではないかと思います。\nまた、今回は紹介していませんが、マイクロソフト独自の各言語のアナライザー(日本語も含む)があります。 Luceneのアナライザーとマイクロソフトのアナライザーのどちらも利用できますので、ここの違いを見てみるのも面白そうだなと思いました。 緯度経度を利用した検索、フィルター検索(スコア計算対象にならない)、ファセット、スコア調整の機能なども備えているようです。\nなんにせよ、利用する場合やドキュメントを読む場合に、全文検索の仕組みをなんとなく知っておいたほうが読みやすいんじゃないかなというのが感想です。\nここ数年はElasticsearchがメインでほかはほぼ触っていない状況だったので新しい製品に触れるのは面白いですね。 時間があったら、アナライザーの違いなども調べてみたいなと思います。\n","date":1582080481,"dir":"post/2020/","id":"c3053579ae25e2fb9b967076a06373af","lang":"ja","lastmod":1582080481,"permalink":"https://blog.johtani.info/blog/2020/02/19/research-azure-cognitive-search/","publishdate":"2020-02-19T11:48:01+09:00","summary":"お手伝いしているお客さんがAzure Cognitive Searchを利用してます。 検索周り=Azure Cognitive Searchに関する手伝いをする形で入っており、 いく","tags":["azure search"],"title":"Azure Cognitive Searchでインデックスを作って検索"},{"contents":"また、ツイートから始まるお話です。 まだまだ、検索システムってどんなものかを勉強したいしということで、こんなのをツイートしてました。\n「検索システム探訪」みたいな名前がいいかな? https://t.co/sG7BDdGI9h\n\u0026mdash; Jun Ohtani (@johtani) February 6, 2020 検索について知り合いとお茶をしながら話をしていて、こういう話を聞くの面白いなぁと思ったので。 どんなことを個人的には聞きたいかな?というのをまとめといたほうがいいかと思いブログを書いています。 こんなことも面白そうだよね?\nどんなこと聞きたいかな? いまのところ思いついた内容はこんな感じかな? こんなのも聞くと面白そうだよね?などありましたら、コメント欄に書いてもらえればと。\n利用しているシステム・サービスは? 構成やどこのサービスなのか？ 検索ユーザーはどんな人？ ユーザーの種類 ユーザーの検索ニーズ 検索対象データはどんなもの？ データ件数はどのくらい？ 属性、項目がどのくらいあるか？ 検索結果として出したいものは？ ソートはどんなものがあるの？ ランキングで重要なものは？ UI/UXはどんな感じ? ハイライト、ソート、ファセット(Aggs) キーワードサジェスト、オートコンプリート 検索システムの監視(オブザバビリティ??) ビジネス的な指標 クエリログ、クリック(ユーザーに関する情報) システムメトリクス 困っていることは？ ランキング クエリ 検索システム分析 第1回やりました。 ちなみに、最初のツイートに対して、すぐに返事をくれた方がいました。\nうちでよければご説明します！\n\u0026mdash; Kizashi （令和もRailsエンジニア募集中） (@kizashi1122) February 6, 2020 Twitter本当にありがとうございますという感じです。\nで、早速話を聞かせていただきました。大阪の方だったので、テレカンでやらせていただきました。 移動時間とか気にせずにできるので、テレカン形式いいですよね。\n内容は、非常に面白かったです。 使ってるシステムについて、どんなところで、どのようなように検索エンジンをつかっているのか、 どんなことで困っているのかなどをお聞きすることができました。\n2020/02/13 追記 対応していただいたIngageの永田さんから、内容を公開しても良いという承諾をいただいたので、メモを公開します。\nサービス : Re:lation 問い合わせメールなどのチームで対応する対応 利用している検索エンジン Elasticsearch (AWS Es) ノード数 8 - 3 master + 5 data データ データ数 : 約1億5千万 親子関係 : チケット - メール(=1ドキュメント) - コメント 画面としてはチケットの一覧=aggsでチケットIDの一覧を生成してリスト表示 インデックス数 : 5 = テナントごとに振り分けしてる。 8シャード - スケールアウトした場合も対応できるので。 PostgreSQLにマスターは保存 データの単位はメール。コメントはtextの配列でメールに保存されている。 EsはIDの一覧を返す。ただし、チケットのIDの一覧 機能 ハイライト Esではなく独自実装。 クエリ n-gramでやってる = kuromoji使ってない min=1, max=2 悩み事 EBS上だったものをローカルにしたので速くなった。 期間が長いと、検索結果一覧の表示が遅い aggsが遅いのかな? 検索結果一覧はチケットが持っているメールの日付の降順。結果一覧はチケットの一覧。 詳細検索はDB、左のステータスもファセットも現在はDBから生成 Es使ったほうが早いかも? マルチテナントのつらさ 検索ログ 独自ログはとっていない = アプリのログから判別 今後 アドレス帳検索 お誘いお待ちしております! 今後もこれやっていきたいなぁ。話してもいいよ!という方がいらっしゃいましたら、@johtaniまでDMもしくはメンションをください。お待ちしております!\n","date":1581344427,"dir":"post/2020/","id":"7b080dc43fce482af14de61c6ab819a5","lang":"ja","lastmod":1581344427,"permalink":"https://blog.johtani.info/blog/2020/02/10/explore-search-system/","publishdate":"2020-02-10T23:20:27+09:00","summary":"また、ツイートから始まるお話です。 まだまだ、検索システムってどんなものかを勉強したいしということで、こんなのをツイートしてました。 「検索シス","tags":["検索システム探訪"],"title":"「検索システム探訪」したいな=\u003eやりました"},{"contents":"年末、何種類かのボードゲームを家族で楽しみました。 家族の感想を交えて簡単に紹介しようかと思います。 家族や知人でボードゲームを購入するときの参考に参考にしてもらえたらと。 それぞれのゲームの詳細については、それぞれWikipediaなどのリンクを張っておくので、参考にしていただけたらと。 結構有名なボードゲームが多いのかな?\nカタン Amazon | カタン スタンダード版 | ボードゲーム | おもちゃ 簡単な紹介 プレーヤー数 : 3-4名 (拡張版を追加すると5-6名でもプレイできるみたい) 対象年齢 : 10歳以上 種類 : 対戦型 紹介 : 大航海時代に発見された無人島を複数の入植者たちが開拓していき、もっとも繁栄したプレイヤーが勝利するという内容のボードゲーム(Wikipediaより)。 特徴 : 5種類の資源を元に、道を作ったり、開拓地や都市を作ったり、サイコロを使った運も必要ですが、プレーヤー同士で手持ちの資源を交渉することも可能なゲームです。 感想 最初の配置が重要な気がします。資源の組み合わせによってできることが変わってくるので、何をやりたいかというのを元に考えて配置するのが重要そうです(私はまだうまくできてませんがw)。 プレーヤー同士の交渉も1つの手段なので、会話しながら、自然と交渉術も身についてきそうです。 戦略だけじゃなくサイコロを使った運もあるので、子供と大人が混ざっていても偏った結果にはならないです。 自分の道や町が発展していくのも楽しみの1つです。 お化け屋敷の宝石ハンター Amazon | お化け屋敷の宝石ハンター FBH20 | おもちゃ | おもちゃ 簡単な紹介 プレーヤー数 : 2-4名 対象年齢 : 8歳以上 種類 : 協力型 紹介 : お化け屋敷がおばけでいっぱいになる前に、みんなで協力して８つの宝石をみつけて、屋敷から脱出しよう！(メーカーホームページより)。 特徴 : 対戦ではなくプレーヤーみんなで協力してやるボードゲーム。おばけのフィギュアも可愛いです。サイコロを利用した運もありますが、みんなでどういった戦略で宝石を取り出すかなど会話も進むゲームです。上級編という難しめのルールも用意されているので、ハラハラ・ドキドキしながらプレイできます。 感想 負けて悔しくなったり機嫌が悪くなることがないのがいいですね。 普通のルールだと少し物足りない感じですが、上級編のルールはより、みんなで協力する必要が出てきます。 また、上級編のルールは絶妙な難易度で、もう一度やりたいと思わせるのが良い仕組みです。 ラビリンス Amazon | ラビリンス (Labyrinth) ボードゲーム | ボードゲーム | おもちゃ 簡単な紹介 プレーヤー数 : 1-4名 対象年齢 : 8歳以上 種類 : 対戦型 紹介 : 動く迷路で宝探し！通路が動く不思議な迷路の中に、「宝物」や「奇妙な生き物」が隠されています。プレイヤーはこれらを集めてこなければなりませんが、そのためには、巧みに迷路を動かさなければなりません。(メーカーホームページより)。 特徴 : サイコロがないボードゲームです。先を予測しながら人のじゃまをしつつ、自分に有利に進めていくゲームです。プレーヤー個別に難易度を変えられる仕組みがあります(子供だけに有利なルール設定が可能)。 感想 子供ルールがあるので、1度のゲームで別々の難易度が設定できるのがいいです。左右盲の人には子供ルールとかもありです。 ラビリンスが得意な人は地図を読むのが得意な人だと思います。 頭も使うけど、自分が望んだ道ができた時の快感があります。 モノポリー Amazon | ハズブロ ボードゲーム モノポリー クラシック C1009 正規品 | ボードゲーム | おもちゃ 簡単な紹介 プレーヤー数 : 2-6名 対象年齢 : 8歳以上 種類 : 対戦型 紹介 : プレイヤーは双六の要領で盤上を周回しながら他プレイヤーと盤上の不動産を取引することにより同一グループを揃え、家やホテルを建設することで他のプレイヤーから高額なレンタル料を徴収して自らの資産を増やし、最終的に他のプレイヤーを全て破産させることを目的とする。モノポリーとは英語で「独占」を意味する。(Wikipediaより)。 特徴 : 資本主義とは?みたいなのを体験できるゲーム。すごろく型ですが、ゴールがあるわけではなく、決着がつくまでぐるぐる回る感じです。 感想 資本主義を象徴しているゲーム展開。真剣勝負間違いなしです。 負けると途中退場ってのがちょっとつらいです。。。 カタンとは違った感じの交渉術になります。 コマが色んな種類があってかわいいです。 パンデミック Amazon | パンデミック:新たなる試練 (Pandemic) 日本語版 ボードゲーム | ボードゲーム | おもちゃ 簡単な紹介 プレーヤー数 : 2-4名 対象年齢 : 8歳以上 種類 : 協力型 紹介 : 『パンデミック』（Pandemic）は、プレイヤーが新型ウイルス対策チームの一員となり、協力しあい感染症の世界的流行（パンデミック）に立ち向かうというボードゲームである。(Wikipediaより)。 特徴 : プレーヤーが個別のロール(役割)を持っており、よりみんなで協力をしないとウイルスに打ち勝てない感じです。 感想 ルールが結構複雑で、理解しながらだと少し時間かかりました。 8歳以上になっていますが、少しむずかしい印象でした。 戦略、戦術が問われる形のゲームなのでしっかり理解すると楽しそう。 世界地図上で、ウイルスと戦っていく感じは臨場感があって面白いです。 ナインタイル Amazon | ナインタイル | カードゲーム・トランプ | おもちゃ 簡単な紹介 プレーヤー数 : 2-4名 対象年齢 : 6歳以上 種類 : スピード対戦型 紹介 : 「ナインタイル」の基本ルールは、それぞれの手元にある、９枚のタイルを自由に動かしたりひっくり返したりして、誰よりも早くお題どおりに並べるだけ。(公式サイトより)。 特徴 : ボードゲームというか、カードゲーム。ルールは簡単ですが、記憶力と素早さが重要です。 感想 脳トレに良さそう(子供に勝てませんでした。。。)。 瞬発力+記憶力が重要。 デザインがきれい じゃあ、家族の人気は? ラビリンス、カタン、モノポリーあたりが人気です。 ゲーム性もありますが、デザインとしてもきれいなものが多かったです。\nテレビゲームも面白いですが、ワイワイ喋りながらボードゲームをやるのも楽しかったです。 今回紹介したボードゲームはどれもある程度ルールを理解するところから始めないといけないですが、理解力や説明力なども必要になってくるので色んな楽しみがあるかなと思います。\n","date":1580558694,"dir":"post/2020/","id":"90f9355781403b92e844de8568863ae8","lang":"ja","lastmod":1580558694,"permalink":"https://blog.johtani.info/blog/2020/02/01/intro-board-game/","publishdate":"2020-02-01T21:04:54+09:00","summary":"年末、何種類かのボードゲームを家族で楽しみました。 家族の感想を交えて簡単に紹介しようかと思います。 家族や知人でボードゲームを購入するときの参","tags":["ゲーム"],"title":"ボードゲーム紹介"},{"contents":"実践Rust入門という本を買っていた(去年の7月だ。。。)のですが、積んであったので、時間を作って読み始めようかと。\n実践Rust入門[言語仕様から開発手法まで] | κeen, 河野 達也, 小松 礼人 |本 | 通販 | Amazon 経緯 もともとは、言語処理100本ノックはじめました(Rust)という感じで、触っていたのですが、場当たり的にやってても時間を持っていかれるだけだなということに気づいたのが最初です。\n今年の目標は、覚えられなので、ちょっとずつでもアウトプットしていこうってのもあり、 読書記録をつけつつ、読んでいこうかなぁと。\nどこまで読んだ? 2章の2-2-5までです。 前回、Rustの環境はセットアップしていたのですが、新PCに切り替わったので、rustupからはじめました。\nrustup rustupではデフォルト設定のままではなく、PATH変数の書き換えだけはしない形でインストールを行いました。\nPATH変数は.zshrcファイルで変更したかったためです(rustupコマンドに変更して貰う場合は.profileなどのファイルが変更されそうだったため)。\nインストールが終わったあとに.zshrcに以下の行を追加しました。\n### For Rust env source $HOME/.cargo/env 疑問点 ここまで読んだ疑問点です。\ncargo new helloしたあとにmain.rsに以下のmain()関数が出来上がっている!? fn main() { println!(\u0026#34;Hello, world!\u0026#34;); } 驚きましたが、cargo new hogeってやっても、おなじmain.rsができてました。デフォルトで出来上がるんですね。どんな超能力!?と思ってしまいましたw\ncargo new helloして出来上がったCargo.tomlに著者名が入力されていた。 authors = [\u0026#34;Jun Ohtani \u0026lt;メアド\u0026gt;\u0026#34;] なんで?と思いました。まだ解明してないです。 本を読んでいけばわかるかな?\n予想:gitの設定(~/.gitconfig)に氏名とメアドが設定されているので、これを利用しているのかな? ","date":1580475492,"dir":"post/2020/","id":"7fcfaa8dd34dbd508f19e8ca0fcfda0f","lang":"ja","lastmod":1580475492,"permalink":"https://blog.johtani.info/blog/2020/01/31/start-reading-bicycle-book/","publishdate":"2020-01-31T21:58:12+09:00","summary":"実践Rust入門という本を買っていた(去年の7月だ。。。)のですが、積んであったので、時間を作って読み始めようかと。 実践Rust入門[言語仕","tags":["rust","読書"],"title":"実践Rust入門はじめました"},{"contents":"12月に退職しますブログを書きましたが、その後どうなったのか?という話をしてないなと思ったので、一応現在の状況を書き留めておこううかと。\n結論 実際にはフリーランスとして働き始めてます。検索周りをお手伝いするお仕事を。読解いとこあれば所属するつもりでもいるし。\n\u0026mdash; Jun Ohtani (@johtani) January 27, 2020 フリーランスとして最初の仕事はElasticsearchではなく、Azure Cognitive Searchの支援だったりします。Esで困ってる方の手伝いもしますので、興味ある方はDMください。\n\u0026mdash; Jun Ohtani (@johtani) January 31, 2020 2020年1月24日が、正式なElasticの退職日でした(有給休暇消化してた)。 で、現在のステータスはこのツイートです。\n現在の心境 どこかに就職してガッツリ検索もやりたいし、いろんな会社の検索やElastic Stackに関するお手伝いをするのにも興味があるし、どちらにも興味がある状況です。まぁ、検索に興味が尽きないというのだけは決まってますかね。\n悩んでいるところに、幸いにもAzure Search周りで手伝ってほしいという話が舞い込んできたので、フリーランスとしてお手伝いをさせていただいてます(現時点で、半稼働で、が3月末まで)。\nElastic Stackなどの知見もあるのでのお手伝いをするというのもありかなぁと。お仕事発注してもいいな?という方があれば、TwitterのDMなど、連絡をいただければと。\n現在の状況でした。\n副業ができる会社に就職するのがどっちもできていいのかも?\n","date":1580470659,"dir":"post/2020/","id":"c61a5bda3f1667498626ae52ad0362e0","lang":"ja","lastmod":1580470659,"permalink":"https://blog.johtani.info/blog/2020/01/31/start-freelance/","publishdate":"2020-01-31T20:37:39+09:00","summary":"12月に退職しますブログを書きましたが、その後どうなったのか?という話をしてないなと思ったので、一応現在の状況を書き留めておこううかと。 結論","tags":["転職"],"title":"フリーランスはじめました(仮)"},{"contents":"ブログ移行日記(その4)です。その他の記事はこちら。\nブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その5) 前回までで、なんとなく移行は終わってます。 今回はテーマで使えるようになっているブログの検索機能の導入の話です。\n検索サービスはAlgoliaを利用します。 OctopressのころはElastic社のサービスであるElastic Site Searchの機能を利用して、クローリングしてから検索できるようにしていましたが、Hugoで導入できるモジュール?があったので、今回からこちらに移行しました。\n参考記事 Clean White ThemeのREADME(Algoliaの設定方法) 参考ブログ:hugoで作ったblogにalgoliaで全文検索機能を追加する Algoliaとは? 検索のas-a-serviceをやっている会社です。Wikipediaによると本社はサンフランシスコにあるみたいですね(フランスの会社のイメージでした。起業された方がフランス出身だからかなぁ?)。 クラウドで検索インデックスを保持でき、API経由で検索したり登録したりできる感じのサービスです。内部で使われているのはOSSではない独自の検索エンジンです。\nクラウドで提供されているサービスなのでサクッと検索を使い始めることができるのがいい点ですね。 また、小さな非商用のプロジェクトにフリーで利用できるプランも提供されているようです(2020年1月現在)。\nAlgoliaのサービス登録からインデックス作成 私が利用しているテーマで設定する方法の記載があったので手順の通りにやってみました。 大きく2つの作業(Algolia側とHugo側)が必要です。まずは、Algoliaで必要な作業から。作業の流れだけ記載しておきます。詳細は「Static site search with Hugo + Algolia」の3)を確認してください。\nAlgoliaのサインアップ(すでにアカウントがあれば不要) New Applicationの作成(名前とプランの指定) リージョンの指定 インデックス名の指定 APIキーを確認 です。これで、Algolia側の準備は完了です。\n今回は関係ないですが、Algoliaの管理画面で、利用状況(データ登録などの操作回数、クエリの回数、インデックスに保存されているレコード数)の確認が可能です。 ほかにも有料プランを利用するとAnalyticsなどもできるようです。\nHugo側で必要な設定 今度はHugo側です。Hugoのサイトのディレクトリに移動してからの作業です。\n仕組みとしては、\nHugoのoutput機能でAlgolia向けのJSONファイルを生成する Node.jsのライブラリを使用してAlgoliaに1.で生成したJSONを登録、更新する 検索画面の作成 という流れになります。 ですので、作業としては以下のとおりです。\nOutput出力の設定(すでにテーマ側で設定されているので、特に作業は必要なし) npm環境の構築(Hugoのconfig.tomlと同じディレクトリ階層) Node.jsのインストール(必要であれば) npm環境の初期化 npmでatomic-algoliaのインストール atomic-algolia向けの設定(登録のためのAPI関連の設定) Algolia向けJSONの出力設定 検索関連の設定 content/search/placeholder.mdの作成 検索用のAPIキーなどを設定 npm関連の作業 以下、npm関連の作業です。\nNode.jsのインストール(必要であれば) 割愛します。環境に合わせてインストールしてください。私はnvm経由でインストールしています。 npm環境の初期化 Hugoのディレクトリでnvm initを実行 npmでatomic-algoliaのインストール Hugoのディレクトリでnpm install atomic-algolia --save atomic-algolia向けの設定(登録のためのAPI関連の設定) Hugoのディレクトリに.envファイルを作成し、以下を設定します。 Algolia向けJSONの出力設定 特に変更なし(config.tomlに少し設定があります)。 ALGOLIA_APP_ID=AlgoliaのApplication ID ALGOLIA_ADMIN_KEY=AlgoliaのAdmin API Key ALGOLIA_INDEX_NAME=先程作ったインデックス名 ALGOLIA_INDEX_FILE=public/algolia.json 最後のALGOLIA_INDEX_FILEは固定文字列でいいと思います。 hugoコマンドを実行するとpublicディレクトリ配下にalgolia.jsonというファイルが生成され、Algolia登録用のJSONが出力されています。\n余談 : algolia.jsonの出力の設定は、config.tomlに記載があります。また、JSONファイルのテンプレート自体はthemes/hugo-theme-cleanwhite/layouts/_default/list.algolia.jsonにあります。Algoliaに登録するデータの構造など変更をする場合はこのテンプレートをカスタマイズすれば良さそうです。\n検索関連の設定 実際に検索の画面を表示するために、検索用の画面と、検索用のAPIの設定が必要です。\ncontent/search/placeholder.mdの作成 /search/が検索用のページになります。空のファイルです。実際にはJavaScriptが検索用の窓を表示したりしてくれます(これが必要な理由がまだ不明だなぁ)。 検索用のAPIキーなどを設定 検索のためのAPIキーなどの設定が必要となります。テーマ作者の方のサンプルのconfig.tomlにパラメータは用意されています。 以下の値を設定します。\nalgolia_search = true algolia_appId = \u0026#34;AlgoliaのApplication ID\u0026#34; algolia_indexName = \u0026#34;作成したインデックス名\u0026#34; algolia_apiKey = \u0026#34;AlgoliaのSearch-Only API Key\u0026#34; 以上でAlgolia関連の設定などの作業が終了です。\nAlgoliaへのデータ登録方法 最後に、実際にデータを登録する必要があります。 手順は、以下のとおりです。\nhugoコマンドの実行(htmlと一緒に登録データのalgolia.jsonを生成) npm run algoliaコマンドの実行(atomic-algoliaを利用してAlgoliaにデータを登録) 設定などが問題なければ、Algoliaの管理画面で登録ができているはずです。 実際にブログのデプロイにはdeploy.shというファイルをこちらを元に作成して使っています。このなかで、hugoコマンド実行後にnpm run algoliaを実行するようにしいます。\n今後の課題 Hugoで生成された記事はそれぞれのブログポスト以外に、タグごとのページも生成されています。 こちらも実はAlgoliaのインデックスに登録されていて、タグを入力すると、タグ名のリンクが出てきます。\nこちらはelasticsearchで検索したときの検索結果です。1件目はタグページです。\nこれらのページはAlgoliaに登録しないようにするのが良さそうかな?と考えているところです(考えてるだけ)。\n2020/01/29更新\nlist.algolia.jsonを編集して、記事だけをインデックスするように修正しました。 テーマに存在するlayouts/_default/list.algolia.jsonを、自分のところにコピーし、次のように変更しました。if文を1行追加して、postという種類のものだけを出力するようにしました。\n{{/* Generates a valid Algolia search index */}} {{- $.Scratch.Add \u0026#34;index\u0026#34; slice -}} {{- $section := $.Site.GetPage \u0026#34;section\u0026#34; .Section }} {{- range .Site.AllPages -}} {{- if or (and (.IsDescendant $section) (and (not .Draft) (not .Params.private))) $section.IsHome -}} {{- if (and (eq .Section \u0026#34;post\u0026#34;) (ne .URL \u0026#34;/post/\u0026#34;)) -}} {{- $.Scratch.Add \u0026#34;index\u0026#34; (dict \u0026#34;objectID\u0026#34; .UniqueID \u0026#34;date\u0026#34; .Date.UTC.Unix \u0026#34;description\u0026#34; .Description \u0026#34;dir\u0026#34; .Dir \u0026#34;expirydate\u0026#34; .ExpiryDate.UTC.Unix \u0026#34;fuzzywordcount\u0026#34; .FuzzyWordCount \u0026#34;keywords\u0026#34; .Keywords \u0026#34;kind\u0026#34; .Kind \u0026#34;lang\u0026#34; .Lang \u0026#34;lastmod\u0026#34; .Lastmod.UTC.Unix \u0026#34;permalink\u0026#34; .Permalink \u0026#34;publishdate\u0026#34; .PublishDate \u0026#34;readingtime\u0026#34; .ReadingTime \u0026#34;relpermalink\u0026#34; .RelPermalink \u0026#34;html\u0026#34; .Params.Description \u0026#34;title\u0026#34; .Title \u0026#34;type\u0026#34; .Type \u0026#34;url\u0026#34; .URL \u0026#34;weight\u0026#34; .Weight \u0026#34;wordcount\u0026#34; .WordCount \u0026#34;section\u0026#34; .Section \u0026#34;tags\u0026#34; .Params.Tags \u0026#34;categories\u0026#34; .Params.Categories \u0026#34;author\u0026#34; .Params.authors \u0026#34;content\u0026#34; .Params.Description \u0026#34;excerpt_html\u0026#34; .Params.Description \u0026#34;excerpt_text\u0026#34; .Params.Description \u0026#34;summary\u0026#34; .Summary)}} {{- end -}} {{- end -}} {{- end -}} {{- $.Scratch.Get \u0026#34;index\u0026#34; | jsonify -}} まとめ これで、ブログ内記事検索ができるようになります。 Algoliaは個人の非商用利用の場合、フリープランが用意されているのがありがたいですね。 まだ、Hugoと連携しただけで、Algolia自体でどんな機能があって、どんなことができそうかといったところは調べていませんが、簡単に利用できるのはとても助かります。\nまぁ、個人ブログの検索機能ってそんなに使う人はいないんですが、自分としては便利かなぁと。\n","date":1580186404,"dir":"post/2020/","id":"d9018f459d3c94a91e92b459e152f7e7","lang":"ja","lastmod":1580283604,"permalink":"https://blog.johtani.info/blog/2020/01/28/introduce-algolia/","publishdate":"2020-01-28T13:40:04+09:00","summary":"ブログ移行日記(その4)です。その他の記事はこちら。 ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(","tags":["ブログ"],"title":"ブログ移行日記(その4) - 検索機能(Algolia)の導入"},{"contents":"ブログ移行日記(その3)です。その他の記事はこちら。\nブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その4) ブログ移行日記(その5) 今回は、Hugoの設定とテーマの一部変更した点について記載します。\n設定ファイル(config.toml) Hugoの設定ファイルはconfig.tomlになります。hogo new siteコマンドで生成したディレクトリの中にデフォルトで含まれていますが、こちらではなく、テーマの作者が用意してくれたconfig.tomlを元に変更を加えました。\nちなみにテーマの作者の方が設定とコンテンツを含めたサンプルも公開してくれています。設定やディレクトリの構成はこちらを参考にしました。\n設定ファイルで変更した項目は以下のとおりです。\nサイトのタイトルや説明など 特記することはありません。好きなように変えました。\nbaseurl title SEOTitle description keyword slogan sidebar_about_descrption 画像関連(ヘッダーや著者近影) 画像の置き場はstatic/images/ディレクトリですが、設定ファイルには images/から設定します。\nheader_image : ブログのヘッダー背景 sidebar_avatar : 著者近影 言語周り(特に多言語対応する予定は無いのですが) languageCode = \u0026ldquo;ja\u0026rdquo; defaultContentLanguage = \u0026ldquo;ja\u0026rdquo; オフにした機能、削除した項目 freands = false bookmarks = false 上記の設定変更以外に、[[params.bookmark_link]]や[[params.friend_link]]も削除。\n中国のサービスや、特化した設定など。\nBaidu Analytics関連 Disqus proxy関連 Reward(wechat pay \u0026amp; alipay関連) params.social関連 rss = true twitter linkedin github ほかはすべてコメントアウト。\n外部サービス関連 disqusShortname : Disqusのショートネーム googleAnalytics : Gooogle AnalyticsのトラッキングID algolia関連 : 別のブログ記事として、設定方法などを書きます。 追加した設定(昨日のブログで説明済み) Octopressと同じ形のパーマリンク [permalinks] post = \u0026#34;/blog/:year/:month/:day/:slug\u0026#34; Markdownファイル中のHTMLタグ表示 [markup.goldmark.renderer] unsafe = true 以上が設定ファイル関連です。\nテーマの変更点 テーマそのままでは問題があったり、独自に変更したいという点があったので、いくつか変更をしています。\nフォントの変更 そのままテーマを適用するだけでうまく行けばよかったのですが、フォントの問題が発生しました。テーマの作者の方が中国の方だから?かどうかはわかりませんが、デフォルトのままだと中華フォントになってしまいました。\nあー、中華フォントだな。 pic.twitter.com/OvHpY4LSp1\n\u0026mdash; Jun Ohtani (@johtani) January 16, 2020 config.tomlにcustom_cssという設定があり、こちらで指定したCSSのファイルがテーマのlayouts/partials/head.htmlから読み込まれる仕組みがあるようなので、フォントに関するCSSをこの機能を使用して指定するようにしました。\nconfig.tomlの設定は次のとおりです(リスト)になっているので、複数のファイルに分割して、読み込ませることも可能なのかな?。\ncustom_css = [\u0026#34;css/custom-font.css\u0026#34;] cssファイルについては、static/css/custom-font.cssというファイルを作成し、次のような記載になっています。 フォントの指定と右側サイドバーの自己紹介の部分の文字色を変更するためのものです。\nbody, h1, h2, h3, h4, h5, h6, .navbar-custom { font-family: Helvetica,\u0026#34;Sawarabi Gothic\u0026#34;,Meiryo,\u0026#34;メイリオ\u0026#34;,\u0026#34;Hiragino Kaku Gothic ProN\u0026#34;, \u0026#34;ヒラギノ角ゴ ProN\u0026#34;,YuGothic,\u0026#34;游ゴシック\u0026#34;,Arial,sans-serif; } .sidebar-container { color: #404040; font-size: 14px; } faviconの変更 テーマにfavicon.icoが含まれていたのですが、せっかくなので独自のものに変えてみようかと。 ただ、残念ながら、こちらはパスおよびファイル名がlayouts/partials/head.htmlに直書きされていました。\n画像はimages配下にと思っていたのですが、このパスだけを変更するためにhead.htmlを自分の配下にコピーしてカスタマイズするのもどうかと思った(テーマに変更やバグ修正が入るたびに手動でコピーするのはなぁと思った)ので、static/img/favicon.icoファイルを作成しました。\nテーマよりもHugoのプロジェクトにあるファイルを優先するようなので、ファイルだけをプロジェクトに作成しました。\n記事一覧のテンプレート 記事の一覧で表示される、作成者と作成日時が英語表記でかつ、冗長な感じがしたので、スッキリさせるために、layouts/partials/post_list.htmlをテーマからコピーして、次のように変更しました。\n元の形式は : Posted by author Monday, January 2, 2006 現在の形式 : 2006-01-02 by author 記事のテンプレート 今回採用したテーマでは、記事の先頭に記事のセクションを元に目次を生成してくれるものでした。\n目次をコンテンツから自動で作ってくれるの便利だな。 pic.twitter.com/9bU3sLnUrm\n\u0026mdash; Jun Ohtani (@johtani) January 16, 2020 とても便利です。ただ、表示が「TOC」なんです。 英語でしかも「ToC」という表記ならまだ気にならなかったかもですが、大文字だと流石に気になったので、プロジェクトのlayouts/_default/single.htmlにコピーして「目次」という日本語に書き換えました。 このHTMLにテーマで修正が入った場合はどうしようかなぁ。。。というのが目下の悩みです。。。\nArchetypeテンプレートの追加 最後は新規記事を書くときに生成されるMarkdownのメタデータの追加です。 HugoにはArchetypesというのが存在します。\nHugoではhugo new 記事としたときに、記事の種類(content/ディレクトリ名=記事のタイプ)によって、作成するmarkdownファイルをテンプレートから生成する機能があります。この生成時に使われるのがarchetypesというディレクトリにあるファイルです。\n私のブログサイトでは、今のところcontent/postというブログの記事だけを書く予定ですので、archetypes/post.mdというファイルを作って以下のようなメタデータをhugo newしたときに自動で生成するようにしました(テーマにあったpost.mdファイルの代わり)。\n--- layout: post title: \u0026#34;{{ replace .Name \u0026#34;-\u0026#34; \u0026#34; \u0026#34; | title }}\u0026#34; slug: \u0026#34;{{ substr .Name 11 }}\u0026#34; author: johtani date: {{ .Date }} comments: true tags: [] draft: true --- タイトルはファイル名のハイフンを空白に変換したもの(実際にはファイル名は英語にしているので、使いませんが。。。) slugはファイル名の先頭からYYYY-MM-DD-という11文字を除いたもの。これは、OctopressのURLに合わせるために使用するURLの一部の文字列です。 author: johtani : 著者は私だけだから固定文字列 comments: true : ブログ記事にはDisqusのコメント機能を利用 tags: [] : 各内容によってタグを付けるが、生成時には空 draft: true : 明示的にこの行を消すまではドラフト記事としたいため という感じです。ほかにどのよなメタデータがあるのかまではまだ調べていないので、今後また適宜変更していくと思います。\nまとめ Hugoの設定や、テーマそのままではなく独自の変更を加えた部分を思い出して書き出してみました。\nこれで、Algoliaに関する部分以外はだいたい思い出して書いたと思います。 次は、Algoliaの使い方と設定について書き残す予定です。\n","date":1579853081,"dir":"post/2020/","id":"99c9c80a6532e4ea3b535c5a92d07a25","lang":"ja","lastmod":1579853081,"permalink":"https://blog.johtani.info/blog/2020/01/24/setting-hugo/","publishdate":"2020-01-24T17:04:41+09:00","summary":"ブログ移行日記(その3)です。その他の記事はこちら。 ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その4) ブログ移行日記(","tags":["ブログ"],"title":"ブログ移行日記(その3) - Hugoの設定と微調整(テーマに合わせた)"},{"contents":"その他の記事はこちら\nブログ移行日記(その1) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) ブログ移行日記(その2)です。前回はHugoとは?というのと、自分が選んだテーマについて記載しました。 本家の手順などを参考にすると、Hugoにテーマを適用し、でHTMLを生成して、表示するところまでできるはずです。\n今回は、OctopressのmarkdownファイルをHugo用に変換する方法について紹介します。お手製ですが、Pythonスクリプトを作ったので、そちらも合わせて簡単に紹介する予定です。\n参考ブログ 「Octopress Hugo 移行」でググるといくつか出てきます。先人の知恵ありがたいですね。 ということで、私はこちらの2つのブログを参考にさせていただきました。ありがとうございます。\nOctopress から Hugo へ移行した - iriya-ufo\u0026rsquo;s blog OctopressからHugoへ移行する方法 | gam0022.net 画像のコピー 画像はそのまま上記参考ブログを元にsource/imagesからstatic/imagesにコピーしました。特にディレクトリ構造の変更とかもしませんでした。\nコンテンツのコピー こちらは、コピーのタイミングでいくつか変換などの処理を行いました。 ファイルの変換にはPythonのスクリプトを書きました。 自分向けの移行ツールなんで、ディレクトリ名とか引数にすらしてないです。。。\n参考ブログと同様の変換\nメタデータの日付変換 categoriesをtagsに変換 画像タグの変換 タイトル、画像のサイズなどに合わせていくつか分岐があります。 参考ブログとは異なる変換、変更\nコードブロックは無変換 0.60.0からCode Fencesに対応したみたいなので不要でした。 ディレクトリ構造の変更 ファイルを年ごとのディレクトリに格納(これまでは、全てのファイルが同一ディレクトリにあった) 拡張子の変更 (.markdown -\u0026gt; .md) メタデータにauthorの追加(自分しか書かないんですけどね) URLをOctopressに合わせる Google検索からの流入もあり、これまでのURLに変更はかけたくないなと。 こちらも参考ブログに記載があるので、そのまま参考にさせていただきました。\nslugについては、移行ツールでファイル名を元に追加する処理を書きました。\nHTMLを含んだMarkdownの対応 TweetやAmazonのアフィリエイトのリンクがHTMLタグでいくつかの記事に含まれており、デフォルトの設定だと表示されません。 config.tomlファイルに以下の設定を追記することで、出力されるようになりました。\n[markup.goldmark.renderer] unsafe = true 名前がunsafeなので、ちょっと気になりますが。。。 すべての記事を表示してチェックしてみたわけではないので、おかしな記事を見つけた方は連絡をいただけると助かります。\nまとめ OctopressのファイルをHugo用にコピーや変換した方法を思い出しながら書いてみました。基本的には参考ブログに上げた2つのブログを真似したものになります。\n次は、利用したテーマのサンプル設定を元に、自分用に変更した点などについて書き残しておこうかな?\n","date":1579775514,"dir":"post/2020/","id":"018b365b00dd3a6ad17c813d21590549","lang":"ja","lastmod":1579775514,"permalink":"https://blog.johtani.info/blog/2020/01/23/convert-md-from-octopress-to-hugo/","publishdate":"2020-01-23T19:31:54+09:00","summary":"その他の記事はこちら ブログ移行日記(その1) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) ブログ移行日記(その2)","tags":["ブログ"],"title":"ブログ移行日記(その2) - Markdownファイルの変換"},{"contents":"その他の記事はこちら\nブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) 起因 いつものツイートから始まる私の行動です。\n(もしかしたら前に一度おすすめしたかもですが) Goのtemplate構文に拒絶反応がなければHugo割と良いですよ〜。\n\u0026mdash; Nobuyuki Kubota (@nobu_k) October 10, 2019 ってことで、Hugo勧められたし、テーマが豊富だしということで、乗り換えた次第です。\n(元)同僚に教えてもらった記事を見てる。Gatsbyも気になるんだけど、デザインセンスないし、テーマが豊富なのがいいなぁ。/ Comparison of Gatsby vs Jekyll vs Hugo | GatsbyJS - https://t.co/yUbKiBmtMS\n\u0026mdash; Jun Ohtani (@johtani) January 9, 2020 一応Gatsbyのサイトにあった比較も見たのですが、テーマの豊富さが勝ちました。デザインを自分でやれるほどではないので。\n理由 乗り換えるに至ったのは主に2つの理由です。\nOctopressが更新されていない ページが増えてきてサイトの生成に時間がかかる 前に使っていたOctopressもJekyllというものがベースになっていました。 Jekyllは今でも更新があるのですが、Octopressが更新されなくなってしまったのと、Rubyがベースになっているため?なのかはわかりませんが、 ブログのページ数が増えてきて、サイトのビルドに時間がかかってくるようになりました。\n結果 まだ、改良点があるかもですが、とりあえず公開できる感じになったと思ったんで切り替えました。\n前のブログはこんな感じで、\n移行後はこんな感じです。\nHugoとは? 公式サイト こちらにあるように、Go言語で実装されているウェブサイト構築フレームワークです。 Go言語で実装されているのもあり、インストールが簡単でした。 Macを使っていますが、Homebrewでインストールができてしまいます。 他の方法もあるようでしたが、Emacsをインストールするのにbrewを入れているので、brewでインストールしました。\n使い方は色んな人が書いてるし、公式ドキュメントを見ていただけばいいかな。\nテーマとは? Hugoのサイトにテーマの一覧があります。 一応、個人のブログなので、それなりにデザインを入れつつ、他の人と違う感じにしたいなと。 テーマ一覧をざっと眺めて良さそうなのをピックアップしたら、最終的にこちらのテーマになりました。\nClean White それなりに更新されてますし、DisqusとSearch(Algolia)が使えるのでこのテーマに決めました。 テーマのインストール方法などはGitHubのREADMEの「Quick Start」に記載があります。\n私は、Hugo自体の設定などをGitHubで管理したかったので、git submoduleを利用して、次のような構成になりました。\nhugo - main repository ├── archetypes ├── content ├── data ├── layouts ├── public - github.com/johtani/johtani.github.io ├── resources ├── static └── themes └── hugo-theme-cleanwhite - github.com/zhaohuabing/hugo-theme-cleanwhite.git hugo : hugo new siteコマンドで作成されたディレクトリです。このディレクトリでまずgit initしました(このリポジトリはプライベートで管理してます)。 themes/hugo-theme-cleanwhite : テーマのQuick Startにあるgit submodule addコマンドでサブモジュールとしてテーマをインストールしました。 public : hugoが生成するHTMLのトップのディレクトリがこちらです。私はGitHub pagesを利用してブログを公開しているので、git submodule addでjohtani.github.ioをサブモジュールにしました。 Hugoで生成したHTMLなどをGitHub pagesで公開するときの手順などはHugoのドキュメントに記載がありました。\nまとめ Hugoに移行した理由や、Hugoとテーマの簡単な紹介でした。 テーマが豊富なのはデザイン力(りょく)がない身としてはありがたいですよね。 次はOctopressのmarkdownファイルをHugo用に変換したり、それに関する設定周りの話を書く予定です。\n","date":1579659814,"dir":"post/2020/","id":"a65bd31d4c3dab0a41712823a5d6002b","lang":"ja","lastmod":1579659814,"permalink":"https://blog.johtani.info/blog/2020/01/22/intro-hugo-and-theme/","publishdate":"2020-01-22T11:23:34+09:00","summary":"その他の記事はこちら ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) 起因 いつものツイートから","tags":["ブログ"],"title":"ブログ移行日記(その1) - Hugoとテーマ"},{"contents":"5年くらい、Octopressを使用していましたが、更新されなくなっているのと、コンテンツの生成に時間がかかることもあり、 ほかのプラットフォームを使用するように変更しました。\nとりあえず、今回の移行で参考にした記事とかURLをリストアップしてみました。 詳細についてはまた明日以降で。\n参考記事 移行関連 : https://iriya-ufo.net/blog/2018/12/27/octopress-to-hugo/#github-pages- 移行関連 : https://gam0022.net/blog/2016/09/25/migrated-from-octopress-to-hugo/ Hugo自体の日本語紹介記事 : https://knowledge.sakura.ad.jp/22908/ Hugo概要 https://gohugo.io/ テーマ 一覧 : https://themes.gohugo.io/ 利用したテーマ : https://github.com/zhaohuabing/hugo-theme-cleanwhite データ移行 作ったスクリプト : https://github.com/johtani/from-octopress-to-hugo favicon 作ったサイト : http://emblemmatic.org/markmaker/#/ Algoliaセッティング 参考 : https://blog.uni-3.app/2019/01/02/hugo-algolia-search/ GitHub Pagesでの運用 https://gohugo.io/hosting-and-deployment/hosting-on-github/#types-of-github-pages 残タスク Amazonのアフィリンクをきれいに表示するlayoutか何かを用意する?　","date":1579166617,"dir":"post/2020/","id":"3c299a4d77be8b4f886ce9fcd23a2561","lang":"ja","lastmod":1579166617,"permalink":"https://blog.johtani.info/blog/2020/01/16/moving-to-hugo/","publishdate":"2020-01-16T18:23:37+09:00","summary":"5年くらい、Octopressを使用していましたが、更新されなくなっているのと、コンテンツの生成に時間がかかることもあり、 ほかのプラットフォ","tags":["hugo","ブログ","octopress"],"title":"OctopressからHugoへ移行中(まだ途中)"},{"contents":"今年も振り返りブログ書いてます。Sasukeがついてる。\n振り返り（2018年に書いた抱負から） まずは去年の抱負を元に。\nTOEIC 受けました。\nお。TOEICの点上がってた（まだまだだけど。。。）\n\u0026mdash; Jun Ohtani (@johtani) October 21, 2019 無事、上がってました。テストの点数を上げるのが目的ではなく、今の実力が どんな感じかというのを確認するために受けました。 前回までが低かったのもあるんですが。 また、数年後に受けてみるのかな?\nCfP見つけて応募 \u0026amp; いろんな場所に顔を出す 色んな所には顔を出しました。 CfPはそれほど出せていなく、とちぎRubyとDevRelJPで喋った程度かと。 12月に最終出社日を迎えたので、今後は顔を出したりCfP見つけて応募も、 一旦休憩に入る予定です。\nもっとブログ！ 12月に入ってから、一気に増えてますねw Elasticでは結局それほどかけなかったなぁ。\nRustの継続 こっちは、書籍も買ったのに手がついてないです。 来年に書籍を読みながら再入門する予定です。\n開発の継続 一応ほそぼそと続けてますが、メンテナンスですね。 Analyzer向けのKibanaのプラグインのバージョンアップにだけ対応していたり。 年初にReact化には着手しました。 あとは、Luceneにちょっとしたパッチ(Lukeの画面とKuromojiのUniDic対応)を送った感じかな。もっとLucene周りやりたいかな。\n日本でエンジニア獲得! トレーナーやエンジニアが入社してくれました! が、私が退職してしまいますが。。。 私自体が次のステップに移らないとなぁと。 Elasticに興味がある人いたら、中の人を紹介できるので声をかけてください!\n振り返り(今年あったできごと) さて、ここからは今年の出来事を。\n検索技術勉強会発足 勉強会運営座談会 初フロリダ 初カナダ\u0026amp;初ナイアガラの滝 退職(予定) 検索技術勉強会ってのをはじめました(はじめましたブログはこちら)。 やっぱり検索の話を聞いたり考えたりするのが好きなので、もっといろんな話を聞く機会がほしいなぁと。ツイートすると何人かの知り合いが手を上げてくれたので、初めて見たのが2月でした。 所属会社もあったので、自分が全面に出ない形で運営に協力するという形式でやっています。なんだかんだでもう4回も開催できています。スピーカーへの声掛けなど、複数人で運営するとそのあたりが多様性が出るし、楽になるのですごくいいなぁと。 来年も2月か3月にやりたいねと話をしているところです。興味のある方は、ぜひスピーカーを!\nで、その流れで、他の勉強会の運営ってみんなどうしてるんだろう? という疑問も出てきたので、勉強会運営座談会なるものもやってみました。少人数で集まって、勉強会の運営ってどんなやり方してます?どんなことに困ってます?みたいなのを共有してみました。 自分自身がそれほど、ほかの勉強会の運営に顔を出してたわけでもなく、やり方をみんなはどうやって共有してるのかなぁ?というのが気になったので。 思った以上に属人化してるのかもなぁというのが感想でした。 ドタバタしてたので、あれからやってませんが、共有する勉強会みたいなのも面白いのかも?\n今年も2回ほどElasticの社内イベントで海外に行かせてもらいました。 5月にフロリダと11月にトロントでした。 フロリダでは、NASAにも行けたし、トロントでは足を伸ばしてナイアガラの滝を見に行くなどもしてみました。こういう機会が定期的にあるのは、いいですよねぇ。\n最後は、退職イベントですね。5年5ヶ月勤めたElasticでの仕事が、12/6で最終出社日でした。実際の退職日は1/24となっています(現在有給休暇消化中)。長かったような、短かったような。日本で1人目で入社してさまざまなことをやらせてもらい、本当に色んな経験ができました。英語も上達したし。 ただ、外にいることでできることがありそうだなと感じたこともあってのこの決断でした。\n最終出社日以降、色んな人とランチさせてもらったりしています。 次に何をやろうかな?ってのんびり考えながら休んでいるところなので。 やっぱり、検索周りのことをやりたいなぁというのが念頭にあるので、そのあたりで模索中という感じです。 が、せっかくの機会なので、少しのんびりしようかなとも思ってます。 なので、プラモデルの作成や配達業(デス・ストランディング)をやってみたり、16インチMacbookのセットアップしながらブログ書いたりしています。 年明けに入ったら、プログラミングもちょっとやりたいな。\nあとこの場を借りて、ブログの欲しい物リストのものを送っていただいた皆様に感謝を述べさせていただきます。本当にありがとうございました!この感謝はまた何かの機会にでも!\n来年の抱負 ということで、来年の抱負です。\n職につく ブログプラットフォームの移行 プログラミング Rust再入門 検索の勉強 検索技術勉強会の継続 まぁ、まずは職につかないとですね。どこかに在籍しつつ、副業で検索周りのこととかやるのもありかもなぁと考えたりしています(プラモデルつくりながらw)。\nブログのプラットフォームをOctopressからHugoあたりに移行しようかなと思ってます。Octopress自体がもう開発がされてないようですし。Hugoだとテンプレート?テーマ?がそれなりにありそうなので良さそうかなぁと。移行プログラムも書かないとかな。新しいものを調べるのって楽しいですよね。\nプログラミングも復活させたいなと。どうしてもこれまでは、しゃべるのをメインにしていたので、後回しにしてしまっていたのもあります。まぁ、向いてないのかもと思ったりもしますが、下手の横好きなりに少しずつでも何かを改善したり作ったりしたいなと。 勉強会の運営周りですこし楽をするためのプログラム書いたりもしているので、この辺もブログに書こうかな?\nRustはTantivyというプロダクトも出てきているし、勉強しようと思って、自転車本を買いつつ、Kindleの肥やしにしているので、手を動かそうとおもいます。 ブログ書いてサボった場合の可視化しないとなw\n検索の勉強もやりたいなと。これまではElasticsearchに注力していましたが、ほかのプロダクトやサービスも調べてみたいなと。教えを請いに皆さんのところにお邪魔するかもしれないので、そのときは優しくしてください。\n今年始めた検索技術勉強会を今後も継続できるようにしたいなと。 で、運営周りを楽にできるような仕組みをもう少し導入できればなぁと考えていきたいなと思います。\nさて、嵐の曲も始まったし終わりです。\n今年も様々な方々に助けていただきました。また、最終出社日以降にランチを一緒にさせていただいたり、遊びに行かせていただいたりとありがとうございました。年明けもひましてるので、ぜひランチしましょうw\n来年はなにやってるんだろうなぁ? 今後も皆さんよろしくおねがいします!!\n","date":1577764743,"dir":"post/2019/","id":"35aa9e09db936aee7ec407c431816573","lang":"ja","lastmod":1577764743,"permalink":"https://blog.johtani.info/blog/2019/12/31/looking-back-2019/","publishdate":"2019-12-31T12:59:03+09:00","summary":"今年も振り返りブログ書いてます。Sasukeがついてる。 振り返り（2018年に書いた抱負から） まずは去年の抱負を元に。 TOEIC 受けました。 お。TO","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2019）"},{"contents":"このブログ書こうと思って、これまでMacのセットアップしてたんだった。。。\n普段、macOSの標準ターミナルを使ってます。 で、ターミナルを使うシーンは次のような感じです。\nブログのデプロイ（参考：Octopress環境のDockerイメージ化） ElasticsearchとKibanaの動作確認 Elasticsearchの起動用ターミナル Kibanaの起動用ターミナル プラグインの開発(elasticsearch-ingest-csv と analyze_api_ui) elasticsearchのリポジトリ kibanaのリポジトリ ingest-csvのリポジトリ analyze_api_uiのリポジトリ 上記のように1.以外については複数のターミナルをそれぞれのディレクトリで起動して使っています。 これらの3つのパターンのときに、毎回ターミナル(シーンによっては複数のウィンドウ)を開いて、ディレクトリに移動って大変だなと。\nウィンドウグループって？ そこで、ターミナルに便利な機能がないのかな?と思い、メニューを見ていたところ「ウィンドウグループ」というのがあったので調べて、現在の使い方に至っています。\nウィンドウグループの使い方の説明はこちらです。\n使い方にあるようにウィンドウの場所、設定、タブなどを保存できます。 そして、「ウィンドウグループを開く」というメニューから保存しておいたグループを開くと、簡単に作業環境が再現可能になります。\n開くときのメニューはこんな感じです。\n作り方 ウィンドウグループの使い方に載ってます。 まずは、保存したいターミナルを開いて、開いたときに移動していたいディレクトリに移動します。 複数のタブやウィンドウを開いた状態にしたい場合は、複数ターミナルを起動して、それぞれ移動したいディレクトリに移動しておきます。\nグループとしてまとめたいウィンドウが起動できたら、あとは、「ウィンドウ」メニューの「ウィンドウをグループとして保存」を選択します。\nこれだけです。あとは、使いたくなったときに開くだけです。 簡単ですよね?\n作るときの注意点としては、複数のウィンドウグループを作りたいときは、 それぞれグループごとに作成しては、個別にやる必要があります。 現在開いているターミナルのうち、あれとこれをウィンドウにしたいというやり方はできないので、そこだけ注意点です。 環境ごとにプロファイル(バックグラウンドの色やテーマ)を覚えさせることができるので、1.のシーンだとIceberg、2.のシーンではBasic、3.のシーンではHomevrewで設定していたりします。 (ただ、Preztoのテーマをagnosterにしてしまったので、Basicだとプロンプトが見にくくてしょうがないのですが。。。)\n設定はどんな感じ？？ ウィンドウグループの管理については、ターミナルの「環境設定」に管理用の画面があります。\nこの画面でいらないグループを削除したり、設定のエクスポート/インポートも可能です。\n私の使い方 3つの利用シーンは説明しました。 すべてのウィンドウグループを変更するたびにインポート/エクスポートしてます。 上記1.と3.のユースケースはほぼ変更がないので、エクスポートしたものを移植用に管理していますが、2.のユースケースについては、頻繁に更新しています(ElasticsearchとKibanaのバージョンをアップしないといけないので)。\nこのとき、MacのGUIで毎回設定をしているわけではありません。 エクスポートしたファイルは、.terminalという名のXMLファイルになっています。\nその中に、次のようなパスが記述されています。このバージョン番号の部分をアップデートのたびにemacsなどで変更し、ターミナルの管理画面で、削除してからインポートし直すだけで、バージョンアップに対応している感じです。\n\u0026lt;key\u0026gt;Tab Working Directory URL\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;file://johtani-mac-15.local/Users/johtani/tmp/elastic_stack/v7.5/elasticsearch-7.5.1/\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Tab Working Directory URL String\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;file://johtani-mac-15.local/Users/johtani/tmp/elastic_stack/v7.5/elasticsearch-7.5.1\u0026lt;/string\u0026gt; まとめ ということで、標準ターミナルのウィンドウグループを使うと、よく開くディレクトリやウィンドウ、タブを覚えて置かせることができるので、それぞれの環境向けのターミナルを、好きなときに開くことができるようになります。 私は、ウィンドウは1つで複数のタブをウィンドウグループという形で覚えさせておくことで、各シーンの切り替え、もしくは併用を閉じたり開いたりを簡単にできるようにしています。\n他のターミナルソフトを使うと似たようなことが簡単にできたりするのかな? みなさんがどうやってこのような作業やってるのかな?ってのはちょっと気になるところです。\n余談（いつものようにツイートとその反応） ちなみに、みんなどんなターミナル環境なんだろう？と思いツイートしてみた結果はこちらです。 (コメントRTってうまいことひろえないのかなぁ？)\nMac標準のターミナル使ってる人ってどのくらいいるんだろ？iTermとか入れてるのかな？tmuxとか？\n\u0026mdash; Jun Ohtani (@johtani) December 11, 2019 Iterm2使ってtmux使って今はIterm2だなー\ncommand2回押すだけでターミナル出すくせが抜けん https://t.co/P8o4M1HSoj\n\u0026mdash; GO☆ | TAFDATA (@_gogoponz) December 11, 2019 Alacritty + tmux やなー。標準はもう使ってない。 https://t.co/HI7hPCg3uo\n\u0026mdash; Ryo HIGASHIGAWA (@biwakonbu) December 11, 2019 標準です https://t.co/W27e2pcq3j\n\u0026mdash; shin higuchi @Acroquest (@shin0higuchi) December 11, 2019 Macを買って以来、ずっと結局標準ターミナル以外使っていない感じ。珍しかったのか。。 https://t.co/Zjz32SgjC6\n\u0026mdash; Kazuhiro Hara™ (@kara_d) December 11, 2019 ","date":1577063679,"dir":"post/2019/","id":"1a1a8cc0040b356d06eacd22e0526476","lang":"ja","lastmod":1577063679,"permalink":"https://blog.johtani.info/blog/2019/12/23/whats-window-group-of-terminal/","publishdate":"2019-12-23T10:14:39+09:00","summary":"このブログ書こうと思って、これまでMacのセットアップしてたんだった。。。 普段、macOSの標準ターミナルを使ってます。 で、ターミナルを使う","tags":["misc"],"title":"macOS標準のターミナルのウィンドウグループが便利"},{"contents":"ドットファイル系（.emacsとか）をこれまでは、PCを引っ越すたびにコピーしてたんですが、いいかげん、GitHubとかで管理したいなと。\nで、ツイートしたところ（こればっかりだなｗ）、homeshick(homesick)が便利だよとの情報を得たので使ってみました。\nhomesick、正確にいうとhomeshickを使ってます。悪くないです\n\u0026mdash; 🤓k.bigwheel🤓 (@k_bigwheel) December 10, 2019 使い方とか 実物はGitHubで公開されていました。\nhttps://github.com/andsens/homeshick\n何者かというと、ホームディレクトリにあるドットファイル(.zshrcなど)をgitコマンドで管理するのを楽にしてくれるシェルの関数群みたいです。 インストールは至ってかんたんで、git cloneで持ってくるだけです。homeshickのリポジトリのREADMEに記載があります。\n使い方はTutorialsにあります。\nhomeshick generate ほげほげで管理する単位（castle）を作ります。ほげほげが名称です。今回私はdotfilesにしました。 homeshick track ほげほげ .zshrcで管理したいファイルを指定します。すると、homeshickが対象のファイル（ここでは.zshrc）をcastleの保存先ディレクトリにコピーしてから、シンボリックリンクをホームディレクトリ上に作ってくれます。 homeshick cd ほげほげで、castleの実際のディレクトリに移動します。実態は.homeshick/repos/ほげほげです。 git remoteコマンドでcastleとGitHubの関連をつけて、あとは、普通にgitコマンドでコミットしたりすればOKです。 すごく簡単に導入できました。あとは、実際にtrackしたいファイルを追加していく感じです。 現状は、.zshrc、.gitconfigあたりを管理しています。 ついでに、homebrewでインストールしたものもbrew bundle dumpで出力して、homeshickで管理することで、brewでインストールしたものの管理もできそう（参考）。\nってことで、至極かんたんでした。すばらしい。\n参考 homeshick Tutorials Qiita : homeshickを使ったdotfilesの管理 ","date":1576624266,"dir":"post/2019/","id":"80c8fca02ebfecc7a931dad1ec38466e","lang":"ja","lastmod":1576624266,"permalink":"https://blog.johtani.info/blog/2019/12/18/introduce-homeshick/","publishdate":"2019-12-18T08:11:06+09:00","summary":"ドットファイル系（.emacsとか）をこれまでは、PCを引っ越すたびにコピーしてたんですが、いいかげん、GitHubとかで管理したいなと。 で","tags":["misc"],"title":"homeshick導入"},{"contents":"Macbook Proが新しくなり、OSがCatalinaになっちゃいました。 これまで使ってた、.bash_profileをコピーしてターミナルを立ち上げたところ、 なんか色々と設定が動いてないな？と思ったら、zshがデフォルトに切り替わってました。\nということで、デフォルト変わったし、時間あるしzshってどんな感じなのか調べてみようと。\n準備前（ツイート） で、ツイートをしたところ、海外の方？より返信が来ました。\nI have a series of posts explaining the transition: https://t.co/dz8QNjxxGf\n\u0026mdash; Scripting OS X (@scriptingosx) December 10, 2019 おもしろそうなので、ざっくりと読んでみました。zshを利用されているTwitterの知り合いの何人かからはzsh + oh-my-zshがいいよとコメント頂いてたんですが、\nMoving to zsh Catalinaからzshがデフォルトになるからと、手元の環境を変更するための話をブログにまとめてくれてます。\nMoving to zsh\nサラッと読んだので、いくつか抜粋すると\nbashでいくつか今設定しているものがあるのでその説明 alias - ファイルをそれぞれの拡張子ごとにアプリを切り替えてる（openコマンドの利用例があって参考になりました）。 functions - manコマンドのときに新しいWindowひらいたりとか shell settings - 大文字小文字関係なくファイル名をTabで候補を表示したり、historyをターミナル個別ではなく共有できるような設定にしたり prompt - 現在のディレクトリがどこかとか表示したり zshの設定ファイル群の説明 shellオプションの抜粋 といった感じでした（途中で読むのやめましたが。。。）\n面白かったのは、Suffix Aliasesです。 ファイル名だけをターミナルで指定すると、拡張子に応じて起動するコマンドを切り替えたりできると（結局まだ採用はしてないですがｗ）\n結局？ 結局、上記ブログを読んでいろんなオプションあるんだなぁ。と思ったのですが、手っ取り早く試すためにPreztoをインストールしました。 以下のような構成になってます。\nなるほど、これがzsh + prezto + powerline fontか。前までgit-promptを拾ってきてbashに組み込んでたけど、ブランチ表示されるし便利だな。 pic.twitter.com/Z2ArBgRZey\n\u0026mdash; Jun Ohtani (@johtani) December 12, 2019 Mac標準ターミナル Iceberg プロファイル Powerline font Prezto agnoster theme - prompt agnoster or ~/.zpreztorc の変更 .zshrcにいくつかaliasなどを追加。参考:gist Preztoのデフォルトでlessなどからエディタを立ち上げるとnanoが起動したので、vimに変更 Preztoが作る設定と自分の設定を混ぜたくなかったので、.zshrcでinit.zshを呼び出し になりました。フォントサイズだけはちょっと大きくしました（老眼ェ。。。） ターミナルの参考にさせていただいたブログは「preztoでzsh構築した時のメモ 」です。\nターミナルソフト(余談？) terminalも人によっては、色んなものを使ってたなと思いツイートしました。 結構みなさん標準のterminalを使ってるみたいでした。ただ、私が聞いたこともないターミナルソフトもちらほらあったので、色々あるんだなぁと。\nMac標準のターミナル使ってる人ってどのくらいいるんだろ？iTermとか入れてるのかな？tmuxとか？\n\u0026mdash; Jun Ohtani (@johtani) December 11, 2019 ","date":1576542903,"dir":"post/2019/","id":"f3ef819656f68b87a91c53afbd441fec","lang":"ja","lastmod":1576542903,"permalink":"https://blog.johtani.info/blog/2019/12/17/move-to-zsh/","publishdate":"2019-12-17T09:35:03+09:00","summary":"Macbook Proが新しくなり、OSがCatalinaになっちゃいました。 これまで使ってた、.bash_profileをコピーしてターミナルを立ち上げ","tags":["misc"],"title":"zshへの移行"},{"contents":"最近使っていたPCが手元からなくなったので、16インチ Macbook Proをセットアップしているところです。 で、時間もあるのでこれまでほったらかしてきた、このブログの環境をちょっと変更しようかなと。\nまずは、変更するにしても、Octopressのブログの環境自体は必要です。 実際に、移行する前のこの記事自体も書いているわけですし。\nただ、今後なくなる環境をローカル環境にセットアップするのもどうかと思い、Docker環境にしてみました。\n参考 \u0026ldquo;Octopress Docker image\u0026quot;でググって出てきたサイトを参考にしました。\n参考ブログ：Octopress in a Docker Container\nセットアップからDockerイメージのビルドまで Docker for Mac自体もインストールしていなかったので、インストールしておきます。 参考ブログの方がGitHubのリポジトリにDockerfileをアップしてくれているので、手順に従い、cloneします。 cloneしたDockerfileの3行目にENV LC_ALL C.UTF-8を追加します（UTF-8でブログを書いており、previewした場合にエラーが出たため） 参考ブログにある「Build the docker image」の手順に従い、Gemfile、.gitconfigをコピーしてイメージをビルドします。 参考ブログの「Rakefile」にあるように、自分のoctopress/RakefileのProcess.spawn(...)にアドレスを追加します（Dockerコンテナの外からアクセスできるように） 自分のoctopressにあるGemfile.lockを削除しました（ビルドしたイメージにはいるGemと一部バージョンが異なる記載のものがあったため） ここまでで、\nDocker run 実際にコンテナを実行するためのスクリプトを書きました（書いたと言っても参考ブログにある起動コマンドを叩いてるだけですが。。。）\nlaunch-octopress-docker.shというファイル名で以下のコマンドを実行してるだけです。\n!/bin/sh docker run -p 4000:4000 --rm --volume /Users/johtani/projects/blog/octopress:/octopress --volume /Users/johtani/.ssh:/home/blogger/.ssh -ti blog/octopress /bin/bash このシェルを起動すると、Dockerコンテナにbashで接続し、/octopressディレクトリにログインしています。 あとは、いつものようにrake new_post[\u0026quot;....\u0026quot;]で新規記事のテンプレートを作成したりすればOKです。\nrake generate; rake previewと実行してからローカルのブラウザでhttp://localhost:4000に接続すればプレビューも可能。\nということで、このDockerファイルとかを持っておけば、他の環境でもかんたんにOctopressの環境が再現できそうです。 先人の知恵有り難し。 これで、クリーンなまま他のブログ環境に移行できそう。\n追記(2019/12/17) Docker環境でいくつか問題があったので、追記しておきます。\nDocker for Macが再起動しない Docker for MacがCatalina環境だと問題があるみたいでした。 CPUの数やメモリの数を変更してDockerを再起動したところ、ずっとStartingのまま。\n解決方法としては、launchctlの設定に$PATHを追加するみたい。これで、問題なく起動するようになった気がする\nsshの設定ファイルの問題 .ssh/configにMacのKeyChainを利用する設定を記載してるんですが、Ubuntu上だとこの設定のせいで、エラーが出てしまいます。 IgnoreUnknownという設定で、知らないオプションがあったら無視するという設定になる模様。ということで、Dockerコンテナ上でrake deployのときにエラーが出てたのが解消できました。\n","date":1576458061,"dir":"post/2019/","id":"1abc586d67f0b6c05fd5e60f25492340","lang":"ja","lastmod":1576458061,"permalink":"https://blog.johtani.info/blog/2019/12/16/dockernize-octopress/","publishdate":"2019-12-16T10:01:01+09:00","summary":"最近使っていたPCが手元からなくなったので、16インチ Macbook Proをセットアップしているところです。 で、時間もあるのでこれまでほったらかしてきた","tags":["octopress"],"title":"Octopress環境のDockerイメージ化"},{"contents":"本日、Elasticでの最終出社日でした。実際の退職日はまだ先ですが、有休消化という感じです。\n思い返せばもう5年と5ヶ月も前ですが、Elastic（当時はElasticsearchって社名だった）に参加しました。\n社名も変わりましたし、プロダクトの数も増えたし、IPOもしました。 初の外資＋スタートアップということもあり、ものすごくエキサイティングな5年半でした。 Elasticを離れはしますが、検索自体にはまだまだ興味があるので、LuceneやElasticsearchになにかしら関わる感じのことをする予定です。 検索技術勉強会も今後もやっていきますし。\nただ、激動の5年半だったので、退職日までちょっとゆっくりしようと思っています。 次にどんなことをするのかはまた、別の機会にでも。\nおまけ ということで、まぁお約束です。\nほしい物リストはこちら\n","date":1575615090,"dir":"post/2019/","id":"1bbf2ef67f096960e13d8578fa544536","lang":"ja","lastmod":1575615090,"permalink":"https://blog.johtani.info/blog/2019/12/06/leaving-elastic/","publishdate":"2019-12-06T15:51:30+09:00","summary":"本日、Elasticでの最終出社日でした。実際の退職日はまだ先ですが、有休消化という感じです。 思い返せばもう5年と5ヶ月も前ですが、Elas","tags":["転職"],"title":"退職します"},{"contents":"これは、情報検索・検索エンジン Advent Calendar 2019 の 4 日目の記事です。\n1日目から、質の高いエントリーが続いていましたが、一旦休憩して頂く感じの記事になってます。気軽に読んでくださいw。Advent Calendarつくらないの？と煽ったのもあり、穴を埋めようかなと。　発端 ちょっと先ですがこういうのやります。実装寄りの話やOSS開発に興味がある方，きてください～ / Lucene 版 #Kuromoji のコードを読む会（辞書ビルダー編） https://t.co/NgEmUohoPo #kuromoji\n\u0026mdash; Tomoko Uchida (@moco_beta) September 6, 2019 「Lucene 版 #Kuromoji のコードを読む会（辞書ビルダー編）」という勉強会があり、参加したところ、UniDicの辞書のビルドがコケるという話を聞いたんで、ちょっとやってみるかと。\nちなみに、Kuromojiとは、Apache Luceneに入っている、日本語向けの形態素解析ライブラリです。IPAdicの辞書を内包しており、SolrやElasticsearchといった、Apache Luceneを利用している検索エンジンで手軽に使える形態素解析ライブラリになっています。が、対応している辞書がデフォルトだとIPAdicなのです。\n問題点 LUCENE-4056というIssueが上がっています。\nbuild.xmlには記載はないけど、辞書のビルダーは対応していそうな雰囲気を醸し出しているので、試してみたというのが発端？かと。で、実際に動かしてみると動かない点がありましたと。\nまた、Issueの会話で出ていたUniDicの辞書のライセンスの話もありました。 ただ、UniDicがライセンスを変更したので、このあたりはクリアできそうかなと。\nパッチ ということで、動かしてみていくつか修正してパッチを作りました。\nhttps://github.com/apache/lucene-solr/pull/935\n最近のLuceneはGitHubでプルリク遅れるのが便利ですね。 そんなに大したことはやってないです。以下の点が問題だったので直しています。\nIPAdicとUniDicで語彙定義ファイルのCSVの形式（カラムの数）が異なる unk.defのカラム数も異なる あとは、辞書のダウンロードの部分やbuild.xmlでの処理を追加した形です。 このプルリクを適用したlucene-solrのソースディレクトリを持ってきて、手元でjarをビルドすれば普通はIPAdicの辞書を内包したkuromojiのjarファイルが出来上がります。\nlucene/analysis/kuromoji/build.xmlファイルを、このGistにあるように変更して、ant build-dictとやれば辞書のビルドが可能です。 また、cd lucene/;ant jarとすれば、UniDicの辞書を内包したjarファイルもビルドできます(lucene/build/analysis/kuromojiの下にjarファイルができあがります)。\n確認？ 一応、パッチは動くのですが、パッチ自体はUniDicの辞書をビルドする仕組みはオフのままです。なので、テストをどうやろう？というところでやなんで止まっています。。。\nただ、実際に作ったパッチできちんとIPAdicとUniDicがそれぞれビルドできているかの確認はしないとなと。\nということで、2つのjarファイルを読み込んで、それぞれトークナイズして、その出力を表示するツールを作ってみました。\n上記パッチを適用したlucene-solrのソースを持ってきて、IPAdicの辞書を内包したkuromojiのjarファイルと、UniDicの辞書を内包したjarファイルを用意し、ツールの支持に従って、ファイルをディレクトリに配置して、実行すれば以下のような出力がされるようになっています（とりあえず作ったものなので、Javaファイルにトークナイズしたいテキストを書かないといけないのですが）。\nたとえば、「自転車と自動車の違いはなんでしょう？」という文字列を入力すると、以下のような出力になりました。\n+++ ipadic ++++++++++++++ token[0] is [自転車] token[1] is [と] token[2] is [自動車] token[3] is [の] token[4] is [違い] token[5] is [は] token[6] is [なん] token[7] is [でしょ] token[8] is [う] +++ unidic ++++++++++++++ token[0] is [自転] token[1] is [車] token[2] is [と] token[3] is [自動] token[4] is [車] token[5] is [の] token[6] is [違い] token[7] is [は] token[8] is [なん] token[9] is [でしょう] UniDicは[短単位]で語彙が扱われるため、「自転車」や「自動車」がそれぞれ「自転」「車」、「自動」「車」という形でトークナイズされていることがわかります。\nどちらがより便利なのか？というのは用途によっても変わってくるかと思いますが、検索の転置インデックスとしては、より短い単語で区切られている方が、より多くの文書にヒットする可能性が高くなるので、便利な可能性が高いです。\nまとめ ということで、パッチを作ってみたものの、まだ取り込まれていない状況です。 着地点をどうするかって話かなと思っています。興味があれば遊んでみていただければと。\n将来的には、辞書をjarから切り離して別のディレクトリやjarとして使えるようにしようというIssueも作られています。こちらがすすめば、UniDicだけでなく、その他の辞書を切り替えながら使えるようになる日が来るのではないでしょうか？\n","date":1575385200,"dir":"post/2019/","id":"c2d39f2f7fe6cb69fc8efb6c5495c932","lang":"ja","lastmod":1575385200,"permalink":"https://blog.johtani.info/blog/2019/12/04/about-lucene-4056/","publishdate":"2019-12-04T00:00:00+09:00","summary":"これは、情報検索・検索エンジン Advent Calendar 2019 の 4 日目の記事です。 1日目から、質の高いエントリーが続いていましたが、一旦休憩して頂く感じの記事になって","tags":["Lucene"],"title":"Apache LuceneのKuromojiのUniDicビルド対応パッチについて"},{"contents":"Elastic stack (Elasticsearch) Advent Calendar 2019の1日目の記事になります。\nまだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみようと思います。毎年恒例ですね、ここ数年。\nElastic Stack 6.6.0リリース(1月) リリース記事はこちら\nElastic APMが6.6のリリースと同時にElastic CloudでAPM Serverが無料で利用できるようになったのが地味に便利でした。APMのデモをやるために、それまでは手元にAPM Serverの起動が必要だったので。。。\nユーザーの方たちにはIndex Lifecycle Management（インデックスライフサイクル管理：ILM）がリリースされたのが便利だったと思います。 まだ、ベータでしたが、インデックスの世代管理を格段に便利にしてくれるツールになり、現在では必須アイテムとなっています。 もう一つ、地味に便利なのは、KibanaからElasticsearchへの接続を複数指定できるようになった点かと思います。\nElatic Common Schemaのベータリリース(2月) リリース記事はこちら\nElastic Stackではメトリック、APM、ログなど、様々なデータを一元的に可視化することができるという利点があります。ただ、一元的にデータを可視化、検索するためには異なるデータセットに統一されたフィールド名が欠かせません。そのための手段としてElasticが公開したのがElastic Common Schemaです。 各種データの項目名、型などを共通化する仕様をGitHub上で公開しています。最近のBeatsのモジュールはこのElastic Common Schemaに則ってデータが定義されるようになってきています。これにより、ログからメトリックへ、APMからログデータへというシームレスな移動ができるようになっています。\nElastic Stack 6.7.0リリース(3月) リリース記事はこちら\nElastic MapsやUptimeといった、これまでの可視化とは異なる便利なアプリが増え始めました。Mapsでは地図の表現が格段にアップしたので、コレまで以上に地理情報と合わせた可視化が楽しくなりました。\nもちろん、基本的に必要な技術が着実にGAされていくのもElastic Stackの素晴らしい点です。\nIndex Lifecycle Management(ILM)がGA Cross Cluster Replication(CCR)がGA CanvasがGA Logs \u0026amp; Infra UIがGA Elastic Stack 7.0.0リリース(4月) リリース記事はこちら\nメジャーバージョンのリリースです。 KibanaのUIが刷新されたり、Elasticsearchのクラスター管理の機能が新規に構築されたり、様々な改善がこのリリースでも入っています。また、メジャーバージョンのリリースのタイミングが、さまざまな大きな仕様の変更や改善が入るタイミングでもあります。これまで以上にパフォーマンスが改善（Top-Nクエリ高速化など）されたり、新しい機能の追加（ナノ秒のサポート）されたりしました。\nElasticsearchのセキュリティの主要な機能が無料に(5月) リリース記事はこちら\n6.8.0および7.1.0のリリースはこの機能の無償提供となりました。 結構衝撃的な話だったのではないかなぁと。これ以前は有償の機能だったセキュリティの以下の機能をElastic License配下で無料で提供する形に変わりました。まだ、ご存知でない方は、データの安全のためにもセキュリティ機能を利用することをおすすめします。\nTLSによる通信暗号化 ユーザー作成と管理にファイルおよびネイティブのレルム認証を使用可能 クラスターAPIとインデックスに対するユーザーアクセスの管理にロールベースのアクセス制御を使用可能、またSpaces機能でKibanaのマルチテナンシーの安全性を向上 Elastic{ON}19開催(5月) 今年も東京で開催しました。ビデオなどはこちらで公開されています。 https://www.elastic.co/elasticon/tour/2019/tokyo\n今回も偉そうにElatic Stackの新しくなった点を紹介するなどしてました。。。\nElastic Stack 7.2.0リリース(6月) リリース記事はこちら\nElastic SIEMがベータリリースされたのがこのタイミングです。 2月の発表したElastic Common Schemaをフルに活用していると言ってもいいのがこの機能になります。まだ今後もどんどん改善が入るであろうきのうになります。\nまた、Elasticsearchをバックエンドにした検索ミドルウェアとして利用いただけるElastic App Searchのセルフマネージド版もこのタイミングでリリースされています。\nさらに、このリリースの直前にはElastic Cloud on Kuberunetes(ECK)というものベータリリースされました。少しわかりにくいかもですが、ElasticsearchやKibanaをKubernetesのOperatorとして利用できるようになっています。こちらもElastic Licenseでリリースされているのでk8s上でKibanaやEsを管理しようとしている方は触ってみると面白いかもです。\nElastic Cloud Elasticsearch ServiceがGCP日本で利用可能に(7月) リリース記事はこちら\nElastic Cloudもプラットフォームが拡大した年でした。 Google Cloud Platformの東京リージョンを選択できるようになりました。さらなる統合（支払いをGCP経由にまとめたり、GCPのコンソールから利用できたりなど）も進んでいます。\nElastic Stack 7.3.0リリース(8月) リリース記事はこちら\nデータフレームと呼ばれるデータ取り込み時のピボット機能が導入されました。また、MapsのGAリリース、Elastic APMの.NETエージェント正式リリースなど、細かいですが様々なものがリリースされています。\nElastic Cloud Elasticsearch ServiceがAzureで利用可能に(9月) リリース記事はこちら\nMicrosoft Azureへのデプロイも可能になりました。残念ながらまだ日本リージョンには来ていないですが、今後出てくるはずです！さまざまなクラウドベンダーのサポートにより、より多くの人に使っていただけるようになるのかと。\nElastic Stack 7.4.0リリース(10月) リリース記事はこちら\nもう7.4.2まで出ていますが、いい感じの間隔で7.0、7.2、7.3と来ていますね。 7.4では、スナップショットリストアがKibanaから簡単に行えるようになりました。これまではKibanaのConsoleでJSONを見ながら管理されていたかもですが、GUIにより今どんなスナップショットがあるのか、どれをリストアするのかといった操作が簡単にできるようになっています。\nKibanaについてはPKI認証のサポートなども始まり、様々な認証方式でより便利にKibanaが使えるようになっています。\n12月？ 12月ですし、Elasticsearch勉強会では「LT＆忘年会」ということで、懇親会がメインの勉強会として12/6に開催します。悪路クエストの緑川さん、吉岡さんに主体となっていただき、マイクロソフトさんを会場に借りて開催予定です。興味のある方はぜひご参加ください。 LTもおまちしています！\nまとめ 駆け足でしたが今年を振り返ってみました。 今年も色々ありました。残すところあと1ヶ月です！\nさて、Elastic Stack Advent Calendar 2019は今日から25日まで続きます。今年はその2もできています！こらからの記事を楽しみにしています！ 本日はその2で[kaibadash@github]さんが「5分でできるElastic stack環境構築」というのを書いてくれてるはずです！\nということで、次はKunihikoKidoさんの「 Elastic Cloud を使うようになって設計方針やら変わったことについて書きます。」になります。お楽しみに！\n","date":1575126000,"dir":"post/2019/","id":"78da47d61c91c82809a3c97a791d26d2","lang":"ja","lastmod":1575126000,"permalink":"https://blog.johtani.info/blog/2019/12/01/whats-happen-at-elastic-in-2019/","publishdate":"2019-12-01T00:00:00+09:00","summary":"Elastic stack (Elasticsearch) Advent Calendar 2019の1日目の記事になります。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみようと思います。毎年恒例ですね、","tags":["elasticsearch"],"title":"2019年のElastic StackとElastic"},{"contents":"Bonfire Data \u0026amp; Science #1にブログ枠で参加してきました。 ということで、メモです。\n日時 : 2019/10/25 19:00 - 21:30 場所 : Yahoo! Japan サイト : https://yj-meetup.connpass.com/event/148121/ ハッシュタグ: #yjbonfire 概要 Data \u0026amp; Scienceとは？ データとサイエンスに関わる人達の情報共有のための勉強会/交流会\nサイトから引用です。\n第1回のテーマは「画像検索」です！ 最近EC系のサイトで類似画像検索が出来るようになったけどどうやってるの？ 画像検索のモデルってどうしてるの？ 画像検索のインフラはどうしてるの？ 私たちの会社でも画像検索を用いたサービスを構築できるだろうか？ こういった疑問に答えたり、いま抱えている悩みを解決するヒントを得る場になればと思っています。 今回は、画像検索を行なっているヤフー, メルカリ, ZOZOテクノロジーズの3社に事例と基盤技術について登壇いただきます。 QAはこちら。https://app.sli.do/event/w3wayjmv/live/questions\nMercari画像検索について(仮) 発表者：荒瀬晃介(株式会社メルカリ / AIエンジニアリングチーム)\nAIエンジニアチーム\n写真検索プロジェクトのTech Lead\niOSのみで提供の写真検索\nシステムオーバービュー\nMobileNet v2で特徴抽出 ANNのインデックスを使ってDBに入れる 論文も発表済み（3本）\n今日の発表はこの内の2本を元に話をします。 C2Cでの問題点 商品は床やテーブル上で撮影 クエリは着用（着ている）画像が使われやすい。 人が写ってる写真が結果に多いと業者が出展しているように見えてしまう。 提案手法 人が写ってるものから人の代表ベクトルを抜き取る (クエリ時にのみ処理を実施しているので変更が容易) 特徴変換ベクトル トップスなど、分類ごとに学習させてからベクトルを構成 なんでMobileNet v2? エッジデバイスでの処理を見据えて選択 インフラ Docker + k8s\nCRDを使ってる？\ntraining\nコンテナベースパイプライン いくつかのバッチ処理を工程ごとにパイプライン化 バッチ実行情報をカスタムリソースとしている＝再実行が簡単（復旧作業が容易） 画像を扱う＝ダウンロードが時間がかかる -\u0026gt; 復旧しやすいようにPVにある程度キャッシュさせている Serving\u0026hellip;\nGCP側 なぜ2つに別れてるんだろう？実際のサービスも2つに分かれてたりするんだろうか？\n将来の展望 Realtime Image Search カメラでものを写している状態でそれが何かを検索できる。 物体検出＋特徴抽出をエッジで行うためできる エッジの性能により違いが出てきたりするっぽい QA Q: 業者が想定されると、購入意欲を下げるというのは実験した結果？それとも想像？ A: 実験はしていないが、e-commerceにおいての研究がある Q: どういう理由でマルチクラウドにしたんでしょう? A: 画像のマスターがAWS。メルカリのマイクロサービスはGKEなので、サービング環境がGCP Q: 画像の内、服のエリアが大部分で体の面積が少ない場合と、メガネや帽子のように、アイテムの方の面積が少ない場合で、トレーニングに必要なデータ数は変わりましたか？ A: カテゴリによる性質の違うはある。ので、改善は必要。 ZOZO画像検索について(仮) 発表者：平田拓也(株式会社ZOZO / AIエンジニアリングチーム)\n(聞き逃した。。。)\nWEAR\nマルチサイズ\nチーム構成 研究所＋ML Opsチーム 使用しているアルゴリズム 物体検出アルゴリズム 特徴量抽出アルゴリズム 近似最近傍探索（approximate nearest neighbor, ANN） インフラ GCPを採用。 BigQuery上にデータ基盤がある Managed GPUが必要 なんでk8s? コンテナ Cloud Runがなかった アーキテクチャ マイクロサービス化されている Google Cloud Next 2019 Tokyoでsonotsさんの発表があるよ 監視項目 CPUなどは見ていない レスポンスタイムとステータス監視 リクエスト数 APM 使ってるものStackdriver + Datadog + Sentry Warningが30分で続けたら通知などができるのがStackdriver 画像検索の改善のためにやっていること 課題 レイテンシーが大きい 推論が大変？ 急激なトラフィックの増加に対応できない GPUのスケールアウトが問題 -\u0026gt; 先行投資が必要 流れ キャッシュありなし 物体検出 (GPU) 特徴量抽出 (GPU) 近似最近傍探索 DBから取得 2と3が問題\n2と3を特徴量DBという形でデータが登録された時点で特徴量などを計算してしまうことでGPUへの依存をなくした。 Apache AirFlowが便利？ Cloud ComposerとApache AirFlow Cloud Composerに関するいくつかのTipsがありました。\nQA Q: 推論をCPUでやったらどれぐらい遅いんだろう A: GPUインスタンス代金 \u0026lt; それと同等の速度を出すためのCPUインスタンス代金 Q: k8sスケールアウト時のリソース割当を最適化する為、resource limit / request標準化 or 時系列分析などから自動調整するなどはされていますか？ A: \u0026hellip;聞き逃した Q: (TCOを考慮したクラスタ構成) Cloud Composerの値段が高いようなパプリッククラウド利用の課題対策としてプライベートクラウドとのハイブリッド構成にされているのでしょうか？もしハイブリッド構成でしたら、パブリック or クラウドを切り分ける基準はございますか。 A: GKEオンリー Q: cloud composerでairflowを使う辛い点は？ A: 不安定さ。。。 Yahoo!ショッピングにおける画像検索(仮) 発表者：佐藤 純一(ヤフー株式会社) 商品検索APIの開発とか検索エンジンの保守とか 類似画像検索システムの開発が直近の仕事 類似画像検索 ヤフーショッピング 3億の商品 ファッション系はビジュアルが重要＝言語による表現が難しい iOSとAndroid Androidだとカメラで撮影してから検索みたいなことも可能 システム概要 物体検出 ノイズ除去 特徴抽出 インデックス(NGT) -\u0026gt; https://github.com/yahoojapan/NGT 1000万件を超える 検索 アプリの画像をAPIに投げてベクトルから、近いものn件を取得 ベクトル化/インデックス更新 GPUマシン Kafka使ってる クラウドストレージに日次？バックアップみたいに保存 差分更新の仕組みがある メンズとレディースは分けている 絞り込み検索のために分離（インデックスのメタデータとしてタグがある） システム構成 Python Kafka TensolflowServing 可視化？監視？はGrafana＋Prometheus 開発を通しての学び 自動デプロイとかテスト 検索精度の確認ツールを作る コレ重要だよね。何が変更してるかとか、何が正しいかってのが必要だし。。。 復旧可能、早期復旧の仕組みを容易 今後の方針 対象商品の拡大 物体検出特徴抽出モデルの性能改善 NGTの検索システムをValdに移行 Vald k8s上で動作、分散検索、分散インデキシングなどの機能を提供予定 QA Q: iOS(既存の画像)とAndroid(カメラで撮る)で画像検索の方式が違うのはなぜ？ A: アプリの違い Q: 1枚の写真に沢山写っている中で、対象の商品をどう識別しているんでしょう。靴もトップスもボトムスも写っていたら、かなり難しそう A: Yahooブラウザの場合は1番大きな領域のものを選択。Yahoo shoppingだと選択可能 NGTについて(仮) 発表者：岩崎 雅二郎(ヤフー株式会社) 類似画像検索を20年くらいやってる 近傍検索ライブラリ https://github.com/yahoojapan/NGT\n高次元ベクトルの近傍検索 ツリーとグラフによるインデックス 近傍検索とは?\n距離空間上でのクエリの近傍のオブジェクトを取得 k最近傍検索（通常はこっち） 範囲検索（あんまり使われない） NGTの特徴\n世界トップレベルの高速高精度な近似近傍検索 OSS 追加削除が可能（削除がとくに難しいらしい） 多様な利用形態（Python、C++、C、Go、コマンドライン） サーバ版NGT（ngtd、vald）を提供 共有メモリ版でメモリサイズ以上のデータ登録可能 量子化版NGT（NGTQ）により。。。 ANNベンチマークによりテスト\n実行環境が決められているらしい。誰が実行しても比較可能 グラフベースの検索の仕組みのほうが性能がいいというのがベンチマーク結果からわかる なんではやいの？ インデックス生成 ツリー（グラフの探索起点の取得に利用する。DVP-tree） グラフ（ANNG） ノードを逐次追加しつつ、近傍ノードを検索してから接続するというのを繰り返している 検索 ツリーから絞り込みつつ、グラフを検索する ANNGに課題があるのでONNG（Optimized Nearest Neighbors Graph）に ノード単位の次数（入出）を最適化 データセットによって有効な次数が違う。。。 NGTを利用した深層学習で。。。 Yahoo!ラボ FavNavi 特徴量の構成（低次特徴量（300次元）、カテゴリ特徴量（128次元）、領域アスペクト比（1次元）） 個別の特徴量だけだとイマイチな結果になるが、組み合わせるといい感じになる モデル性西洋学習データ スライドがあればいいなぁ（表書くの大変だし。。。）\nQA Q: 実際のお客さまの利用を考えると、近似近隣の密度が異なるので、近いものばかりの検索結果や遠いものも含んでしまった検索結果が出ると思うのですが、遠いものが含まれてしまうと、閾値でフィルタしたりするのでしょうか? A: NGTは近いものしかないので、外れ値ってなんでしょう。。。 検索のフィルタリングをある程度している（カテゴリとか）。 まとめ 慣れない分野の話を聞きながらざっとメモを取ったものなので役に立つかはわかりませんが。。。\nアルゴリズムとかまでは得意ではないんですが、画像「検索」ということで参加してみました。 実際に画像検索の仕組みがどんな感じでできているのか、どんな技術がつかわれているのか？ってのがわかったのは 面白かったです。確かに検索のためのキーワードって出てこないことあるしなぁと。 あー、こんなかばんほしいとか、これなんだろ？みたいなのあるからなぁ。\n","date":1572000002,"dir":"post/2019/","id":"11b3a28b536f34d3606427f835bd3ddf","lang":"ja","lastmod":1572000002,"permalink":"https://blog.johtani.info/blog/2019/10/25/bonefire-01/","publishdate":"2019-10-25T19:40:02+09:00","summary":"Bonfire Data \u0026amp; Science #1にブログ枠で参加してきました。 ということで、メモです。 日時 : 2019/10/25 19:00 - 21:30 場所 : Yahoo! Japan サイト : https://yj-meetup.connpass.com/event/148121/ ハッシュタグ: #yjbonfire 概要 Data \u0026amp; Scienceと","tags":["勉強会"],"title":"Bonfire Data \u0026 Science #1に参加しました"},{"contents":"この間のElasticsearch勉強会でAcroquest Technologyの人たちが技術書展7で販売されていた書籍を頂いてしまいました。なので、軽く読んでの感想と宣伝です（これ、電子版とかで買えないのかな？）。\nElasticのパートナーとしても活躍していただいてますが、こういう感じでさまざまなところでElastic Stackを広めていただいていて感謝しかありません。\n章立てとしては以下の通りです。\nElasticsearchでエンタープライズサーチを実現する 同僚が作成、メンテナンスしているFSCrawlerを使った例も書かれています。ローカルのファイル（PDFやJSONとか）をサクッとElasticsearchにインストールしたりするのには便利です。 Kibana Canvasによる柔軟な可視化 Canvasについてどんなものなのか？というのとelasticcofeeというサンプルを元に、その変更の仕方などが説明されています。 Elastic APMによるアプリケーションパフォーマンス監視 Go AgentとAPM自体の使い方の説明です。最近強化されている他の機能との連携（AlertingやMachine Learning）についても触れてくれています。 Kubernetesクラスタのメトリクス・ログ・性能情報の可視化 Azure上でAzure Kubernetes Serviceの上で動いているアプリなどをBeats、APMでデータを取りつつ、他のAzure上にAzure Marketplaceのテンプレートを用いて起動したElasticsearchとKibanaの環境を用いて可視化する方法が説明されています。 ということで、薄い本ですが、手順をおって説明されていたり、7.3と新しいバージョンで書かれているのですばらしいなぁと。 前作の「Elasticsearch NEXT STEP」に引き続きインプレスさんから出たりするのかなぁ？\nちなみに、Elastic APMのRubyに関して興味がある方は、私が前に発表したときの資料がありますので、こちらを参考にしてみてください。\n","date":1570690589,"dir":"post/2019/","id":"d8041ae308961666b15aa1e57b0f9f35","lang":"ja","lastmod":1570690589,"permalink":"https://blog.johtani.info/blog/2019/10/10/review-es-next-step-2/","publishdate":"2019-10-10T15:56:29+09:00","summary":"この間のElasticsearch勉強会でAcroquest Technologyの人たちが技術書展7で販売されていた書籍を頂いてしまいました","tags":["書籍"],"title":"Elasticsearch NEXT STEP 2を頂きました"},{"contents":"Twitterで「Meetup.comに切り替えたらー」みたいな話があったので、 受付用アプリとかなくてという話になったので、普段Elasticsearch勉強会で使用している QRコード生成の仕組みを紹介してみようかと。\nHTMLだけで済むようにQRコードを生成するjquery.qrcode.min.jsってのを使用してます。\nHTMLコードはこちら。\n仕組み 1枚だけのHTMLを生成 MeetupのOAuth2の仕組みを利用(consumer keyを発行する必要あり。) Meetup APIを利用してユーザー情報取得 取得したユーザー情報をGoogle Formに埋め込んだ形で表示するURLを組み立てる 組み立てたURLをQRコードにしてHTMLに表示 受付で、QRコードリーダーを使って、QRコードを読み込むとGoogle Formが開くので、「送信」ボタンを押す 1. HTMLの作成 QRコードを表示するためのHTMLを作成します。Gistに貼り付けてあるので、参考にしてもらえれば。 いくつか埋め込まないといけないものがあるので、個別にそれは説明します。\n2. Google Formの準備 Elasticsearch勉強会では、出席者の情報として、IDと氏名をリストとして保存しています。 目的としては、何人実際に参加したかを計測するのが目的です。 ですので、参加者リストのGoogle Formを作成します。 で、作成した後に、プレビューを表示する。こんな感じ。\nこの時のプレビューのURLをQRコードのURLとして使いたいので、このURLをQRコード表示のHTMLに埋め込みます。\nfunction createGoogleFormURL(data) { var obj = { \u0026#34;entry.1744035444\u0026#34; : data.id, \u0026#34;entry.2031666715\u0026#34; : data.name }; return \u0026#34;https://docs.google.com/forms/d/e/\u0026lt;GOOGLE_FORM_ID\u0026gt;/viewform?\u0026#34; + $.param(obj); } ここら辺です。 returnに書いてあるhttpsで始まる文字列をまず、先ほどのURLで置き換えます。 次に、プレビューのHTMLの中から\u0026lt;input\u0026gt;タグを探して、nameの値を抜き出します。 それをobjのキーに利用します。entry.で始まる文字列が該当します。\nこれで、このURLをQRコードにすれば、値（ここだとIDと氏名）が埋め込まれた形のGoogle Formがスマホのブラウザで起動します。\n3. Meetup APIの準備 MeetupのAPIを利用できるようにします。Meetup.comにログインするとみれるAPIのページがあります。 https://secure.meetup.com/meetup_api\nまず、OAuthを利用するためのConsumer Keyを発行します。\nメニューのOAuth Consumersをクリックして、\n\u0026ldquo;Create New Consumer\u0026quot;をクリックします。 すると、次のような画面が開きます。\nConsumer nameとRedirect URIが重要です。\nConsumer nameはユーザーがMeetup経由で認証するときに、その認証画面で表示される名前になります。 わかりやすい名前を表示してあげると良いかと。\nRedirect URIが一番重要です。実際にOAuthで認証が通った後に表示するHTMLを提供しているURLを指定します。 Elasticsearch勉強会の場合は、私のドメインにwwwをつけた\u0026quot;https://www.johtani.info\u0026quot;を指定しています。 実際にQRコード表示用のHTMLを配置するHTTPサーバーのトップのURLを指定します。 （ちなみに、私のウェブサーバーはS3で運用してます。ですので、HTMLをS3のバケットにアップロードしてあるだけです）\n必須項目を入力したあと、最下部にあるRegister Consumerボタンを押せばキーが生成されます。 生成されたキーがOAuth2のURLのパラメータに必要になります。\nこれで、リダイレクトの準備が整いました。\nOAuth2のURLには、Implicit Flowを利用します。 これで、リダイレクト先のHTMLにトークンがわたるので、Meetup APIにこのトークンが使えるようになります。\n認証用のURLはこちらです。このURLを参加者宛のメールに入れて毎回送信しています。\nhttps://secure.meetup.com/ja-JP/oauth2/authorize?response_type=token\u0026amp;redirect_uri=\u0026lt;QRコード表示HTMLのURL\u0026gt;\u0026amp;client_id=\u0026lt;コンシューマーキー\u0026gt; 参加者はこのリンクをクリックすることで、次のような画面が出てきます。 ログインしていない場合はLog in画面が表示され、まずはログインを促されます。\nで、Allowをクリックすれば、redirect_uriに指定されているページが表示されるわけです。\nQRコード表示用のHTMLでは、次のAPIを使用して、ログインしているユーザーの情報を取得してきています。\nfunction getMemberId() { $.getJSON(\u0026#39;https://api.meetup.com/2/member/self/?only=id,name\u0026amp;access_token=\u0026#39;+ getToken(), displayQRCode); } ここで取れた値が、先ほどの「2. Google Formの準備」で説明したコードのdataの部分に渡ってくるわけです。\nfunction createGoogleFormURL(data) { var obj = { \u0026#34;entry.1744035444\u0026#34; : data.id, \u0026#34;entry.2031666715\u0026#34; : data.name }; return \u0026#34;https://docs.google.com/forms/d/e/\u0026lt;GOOGLE_FORM_ID\u0026gt;/viewform?\u0026#34; + $.param(obj); } 4. QRコードの表示 あとは、jquery.qrcode.min.jsを使用してURLを表示するだけです。\nfunction displayQRCode(data) { $(\u0026#39;#qrcode\u0026#39;).qrcode({width: 128,height: 128, text:createGoogleFormURL(data)}); } サイズとURLを指定するだけですね。\nまとめ あとは、受付で、参加者の方が表示してくれたQRコードをスマホのQRコードリーダーやカメラで読み込めばGoogle Formが開いて必要な情報は入っているので、「送信ボタン」を押せば参加者リストが出来上がっていくという形になります。\n毎回勉強会の前日に、前回のGoogle Formを「コピー」してから、各回の勉強会の登録者フォームを作成しています。 コピーすることにより、Google Formの\u0026lt;input\u0026gt;タグに使用されるnameもそのままコピーされるので、 QRコード生成用のHTMLを書き換える部分の手間が減る形になっています（気づくまで数回かかったw）。\nですので、QRコードのHTMLの中身としては、「勉強会のページへのリンク」、「Google Formへのリンク」の2つを書き換えてから毎回アップロードしているだけとなっています。\nこのやり方が、スマートかどうかはわからないですが、受付アプリがない中、Meetup.comから取得した参加者リストのExcelやプリントアウトしたリストを元に参加者をチェックするよりは、手間が省けてるんじゃないかなぁと。\n残念ながら、QRコードの存在を知らないでそのまま勉強会にくる人がいるので、受付で最低一人はMeetup.comの参加者リストから、 名前を検索してチェックするという作業もやってもらってます。 QRコードを持ってきた方がすんなり受付を通過できるようになってますので、ぜひQRコードを持って勉強会にきてもらえればと。\n","date":1560939044,"dir":"post/2019/","id":"d96f80f23543850a2ee9fff8cd2cc53f","lang":"ja","lastmod":1560939044,"permalink":"https://blog.johtani.info/blog/2019/06/19/qr-code-with-meetup-dot-com/","publishdate":"2019-06-19T19:10:44+09:00","summary":"Twitterで「Meetup.comに切り替えたらー」みたいな話があったので、 受付用アプリとかなくてという話になったので、普段Elasti","tags":["勉強会"],"title":"勉強会の受付自作？アプリ？HTMLについて"},{"contents":"Elasticsearch勉強会や検索技術勉強会やってるんだけど、独学で勉強会やってるなーと思い、みんなはどうやってるんだろうとツイートしてみたところ。\nあー、勉強会運営座談会したい。\n\u0026mdash; Jun Ohtani (@johtani) 2019年4月2日 面白そう\n\u0026mdash; 機械の体を手に入れるのよ鉄郎 (@tetsuroito) 2019年4月2日 やってみるか。\n\u0026mdash; Jun Ohtani (@johtani) 2019年4月2日 やりましょう\n\u0026mdash; 機械の体を手に入れるのよ鉄郎 (@tetsuroito) 2019年4月2日 ってことで、何人か釣れたので、勉強会運営座談会をやってみました。 会場提供していただいた、Classiさんありがとうございました！\n参加してくれた人たちはまぁ、勉強会のサイトを見ていただければなんとなくわかるかなと。 自己紹介とどんな勉強会、読書会運営してますってとこから始めて、次のようなトピックについてピザ食いながら3時間くらい話しました。\nスピーカーの募集方法 運営側から声かけてる？それとも公募してる？ 登壇時間とかどうしてる？ スピーカーになってもらうためになんかやってる？ スケジュール管理 会場探し、スピーカー探し、イベントページ作るタイミングは？ 複数拠点開催したことある？ ハンズオンとかはどうしてる？ 土日開催？平日開催？ アンケートとってますか？ 使用してるイベントサイトは？ ドタキャン対応どうしてる？出欠とったりしてる？懇親会の規模とかどうやって見積もってる？ 運営費用関連はどうしてる？ グッズとか、ツールとか、スピーカーへの謝礼とか 運営って複数でやってる？ その時のツールは？ 運営メンバーにはどうやってなってもらう？ 録画配信とかまで手が回る？ 会場探すの大変じゃない？ 会場の部屋の使い方はどうしてる？ 行動規範とかどうしてる？ 読書会の場合に人が減ってったりしない？ まぁ、こんな感じです。色々話してメモしてたんですが、まぁトピックくらいで。\nそもそもは、勉強会の運営って本業ではない（はずな）ので、いかに楽をしつつうまく運営できるかってのを知りたいのと、 他の人どうやってるかってのからアイデアもらえるといいなーと思ったんでやってみました。 他のツールがどんなものかとか知れたし、あー、そういうやり方すればいいのねーみたいなのも知れたので、次回以降の勉強会に活かせればなーと。 自分がやってるやり方とかもブログ書くといいのかなぁ？\n残念です！次回もやるかもしれないので、 @johtani さんに期待してください！\n\u0026mdash; 機械の体を手に入れるのよ鉄郎 (@tetsuroito) 2019年4月25日 次回やるのかなぁ？興味ある人いるのかなぁ？\n","date":1556204526,"dir":"post/2019/","id":"538e38fbc3f78cd61e1841d8141ddcc1","lang":"ja","lastmod":1556204526,"permalink":"https://blog.johtani.info/blog/2019/04/26/meetup-organizer-drinkup/","publishdate":"2019-04-26T00:02:06+09:00","summary":"Elasticsearch勉強会や検索技術勉強会やってるんだけど、独学で勉強会やってるなーと思い、みんなはどうやってるんだろうとツイートして","tags":["勉強会"],"title":"勉強会運営座談会ってのをやってみた"},{"contents":"どーも、johtaniです。\nSearch Engineering Tech Talkという勉強会に運営として参加して、第1回の勉強会を開始しました。 本日（2/26）は第1回目だったので、ブログを残しておこうかと。\n勉強会自体の資料については第1回の勉強会のページにあるし、勉強会の感想とかブログはツイートやみんながブログを書いてくれると思うので、勉強会開催の経緯などについてブログを残しておこうかと。\nなんで始めたの？ 私自身が古くはFAST Searchに始まり、何か縁があって、 検索のシステムに長く携わってきたこと（Apache Solrの本書いたり、Elasticsearch勉強会始めたり）もあり、 検索が面白いなと日々思ってます（思ってるだけかもしれないが）。\nで、これまでElasticsearch勉強会をやっているのですが、検索エンジン固有の話ではない、 いわゆる検索の共通の課題というのがあるなぁと。 そういう課題やノウハウって、製品に限らず共有できれば面白いことがもっとできるんじゃないだろうか？ と感じることが多々ありまして。 オープンソースのコミュニティをソースコードをベースではなく、共通の課題・話題を中心としたコミュニティが あってもいいんじゃないかなぁと。\nまぁ、要は、私がみんなの検索で困ってることとか、どうやって検索システム考えてるのかが聞きたかったわけですよ。\nということで、一人でやっても面白くないので、興味ありそうな人を募ってやってみようということを始めたのが2018年12月くらいです。\n運営とかどうしてるの？ まずは、共同主催者（コアメンバー）を募集してみようということで、Googleフォーム作って、 興味ありそうな人がいる場所に投稿してみました。（TwitterとかFBとか） で集まったのが今回紹介したメンバー（スライド参照）です。 ユーザー企業の人もいれば、私みたいな検索エンジンの人もいるので面白い感じにできたかなぁと。 で、スピーカーを運営や知り合いに声をかけて第1回をやってみたという感じです。\n今後どうするの？ 残念ながら次回はまだ未定です。 2ヶ月に1回くらいのペースで開催できればなーと思ってますが、スピーカーが集まるかなどによるかなぁと。 ということで、勉強会のグループのページにスピーカー応募フォームのリンクがありますので、スピーカーに興味がある方は入力していただければと。\nもちろん第2回はやりたいので、勉強会のページからの連絡をお待ちください！！\n","date":1551191880,"dir":"post/2019/","id":"b27bdabd8e1a6b7dc06886867331ceb3","lang":"ja","lastmod":1551191880,"permalink":"https://blog.johtani.info/blog/2019/02/26/start-search-engineering-tech-talk/","publishdate":"2019-02-26T23:38:00+09:00","summary":"どーも、johtaniです。 Search Engineering Tech Talkという勉強会に運営として参加して、第1回の勉強会を開始しました。 本日（2/26）は第1回目だったの","tags":["勉強会","検索"],"title":"Search Engineering Tech Talk(検索技術勉強会)の運営として参加して始めてみました。"},{"contents":"今年も振り返りブログをかけてます。よかったw\n振り返り（2017年に書いた抱負から） まずは去年の抱負を元に。\nもっと英語の継続＆TOEIC まぁ、継続してます。英会話も続けてますし、海外TVドラマや映画見てます。 ただ、昨年書いたTOEICはイベントが被りまくってて受けれてないです。。。 来年は受けれればいいが。 ちなみに見たドラマはこの辺。あんまり見てないなぁ。 「はじまりのうた」は飛行機の中で見たんですが、よかったです。 最近は音楽系の映画が好きなのかなぁ。グレーテストマンショー（ミュージカル風）とかもハマったし。\nGame of Thrones はじまりのうた BEGIN AGAIN (映画) 24 シーズン4まで 今は、ボキャブラリのなさに苦しんでる感じです。キクタンとかするべきなのかもなぁ。 基本勉強が下手だからなー。\n継続的にイベントに登壇 ＆ CfPもっと出すぞ！ OSCには出てました。あとは、いくつかに呼ばれて出たりでしょうか。 CfPはJJUGしか出せてない気がするんで、もっと出さないとですね。。。 春のJJUGでは20分で短すぎた「オープンソースとビジネスモデル」の話（同僚のネタ）が 今年面白かった内容かなぁと。 もっと話を作るのをうまくしないとだろうなぁ。 ユースケースが増えてるんで、もっといろんなところに出ていかないとなぁと。 ブースの出し方とかもちょっと考えないといけないかもなーと思ってたり。 マンネリになってきてる気がするんで、なんか取り入れないとなぁ。\nもっとブログ！ 出だしはよかったんですが、途中でRustネタのブログも止まってしまいましたね。。。 業務が忙しくなったのを言い訳にして時間が取れなくなってるんで、 もっと習慣つけないとなぁ。\n雑誌やWeb系雑誌で記事を。 できてないです。。。どうすっかなぁ。 重い腰上げないのが問題なんですけどね。。。 自社のウェビナーとかはそこそこやってましたが。\nコミュニティを別の方法で盛り上げ フォーラムは皆さんのおかげで盛り上がってきてる気がしてます。 別の方法ではなく、勉強会を9月から毎月開催にして、ユースケースごとに切り替えてみました。 あとは、スピーカー登録用のフォームの用意とかして、継続的に楽にスピーカーの人たちが見つけられるようにと。 私は「全然」関わってないんですが、技術書典でいろんな方に書籍を書いていただきました。 また、Elasticloverという毎週いろんな記事をまとめていただけ助かりました。 少しでも感謝をということで、コミュニティランチというイベントで、フォーラムで回答していただいてる方や、書籍を出していただいた方を招いてCEOのShayとランチするというイベントもやってみました。 少しは盛り上げられたかなぁ。 次は、ハッカソンみたいなのとかやってみるのもありなのかなぁ？（サポートしきれない気がするんだよなぁ）\nElasticsearchなど検索系の開発にも参加 開発。。。 Analyzer向けのKibanaのプラグインの開発は継続してますが、あんまり開発してないですねぇ（GitHubの草をみながら)。 ちょっとしたPRはやったりしてますが、もっとやりたい。。。 とりあえず、来年しょっぱなは、検索系じゃないですが、KibanaのプラグインのReact化をやらないとなぁと。\n振り返り(今年あったできごと) さて、反省が多かったですが、ここからは今年の出来事を。\n初スノーシュー in US オフィス引越し パリで料理w K8sとde:code QNAPとか IPO! 初のオンライン登壇 初アイルランド! Pixel3 XL 今年も初モノがちらほら。\nアメリカでスノーシューやりました。昨年は釣りでしたが、今年はスノーシューでした。 スノーシューはすごくよかったんですが、サンフランシスコから社内ミーティングのある場所までの 移動に10時間バスに缶詰という変な初モノもありました。。。 スノーリゾートのある山の上にバスで移動だったんですが、前日までの天候の生でチェーン規制が出てしまい、登りかけた山を降りて、違う経路で登り直すという長旅でした。。。 途中からずっとゲームオブスローンズみてました。。。\nオフィスが引っ越しました。人数が増えてきたのもあり、銀座のWeWorkに引っ越しました（私はあんまり行かなかったりしますがw）。 ただ、すでに手狭になってきて、来年はまた引っ越してるかもなぁ。 今年の終わりで日本のメンバーが22名に増えました！すごい！4年半前の22倍！\nパリで料理もしましたwセールスのキックオフミーティングがパリで開催され、なぜか参加してきました。 そこで、DevRelチームのミーティング＆ディナーがあったんですが、ディナーがアクティビティ付きで、チームのみんなとパリで料理やカクテル作ってきました。 まさか、パリで手巻き寿司作るとは思わなかった（怖くて食べてないですw）\n今年はイベントが連続することが多かったです。パリから帰ってすぐにde:codeでMSの川崎さんと登壇したりしました。Kubernetesを触る機会ができたんでよかったですが、時差ボケは辛かったw今年は他にもカンファレンス直後にトレーニングだったりと、夏に喉やられちゃいました。喉に負担をかけない話し方の練習すべきなんだろうなぁ。\n自宅の環境もちょっと整えました。10年前から使ってた、TeraStationをQNAPに刷新。快適に検索できるわ、クラウドにバックアップとれるわで、すごく快適です。 あとは、自室のディスプレイをディスプレイアームにつけたり、壊れたモニタースピーカーをYamahaのパワードスピーカーに買い替えたりと。 ちょこちょこ自宅で作業したりするんで、快適です。\n今年はめでたいことに会社がIPOしました。ニューヨーク証券取引所で株式公開しました。 転職して4年、初体験なんで何がどうってのはいまいち実感わかないんですが、順調にきてるのは嬉しい限りです。今後も頑張りますよ！\n自社のウェビナーでは、オンライン登壇してたんですが、インフラ勉強会でオンライン登壇させていただきました。 Elastic Stackの入門的な話をさせていただいたので、興味があればみていただければと。 こういうのにはマイクが非常に重要だなというのが結論です。ウェビナーで使ってるShureのマイクで話したので聞き取りやすかったです。 来年はもっと手軽にちょっとしたウェビナーとかポッドキャストやろうかな、ということで、持ち運び用にSAM SONGo Micを購入してみたのでどっかで試してみたいなー。\nアイルランド（ダブリン）にも行きました。これまた、社内のミーティングなんですけどね。半年に1度エンジニアが集まる社内イベントがあるので、いろんなところに旅をさせてもらっていて、すごく楽しいです。 みんなにも会えるし。ただ、アイルランドの英語はきつかった。。。\n最後はPixel3です。SonyのXperiaをここ数年は使ってたんですが、電池の持ちなどが悪くなったんで、気になってたPixel3に変えました。すごくいい。いらないものが入ってないのもいい。あとカメラがすごくいい。他の機能をまだちゃんと調べてないんで、誰か便利機能知ってたら教えてくださいw\nとまぁ、こんな感じでした。\n来年の抱負 最後は来年の抱負を。\nTOEIC CfP見つけて応募 \u0026amp; いろんな場所に顔を出す もっとブログ！ Rustの継続 開発の継続 日本でエンジニア獲得! まぁ、英語ですね。これは地道にやるしかないんだろうなと思いつつ、コツコツが苦手でw とりあえず、今年はどこかでTOEIC受けないとな。\nいつも行かないけど、弊社プロダクトに関係のあるカンファレンスのCfPを見つけ出して、 応募しまくって、少しでもしゃべらないとなぁ。喋れなくても、Elasticsearchがらみで登壇していただいてる方がいるカンファレンスには顔を出していきたいなぁと。 登壇される方いたら、ぜひ連絡ください！あとは、CfPのサイトを探す仕組みを作らないとなぁ。 検索サイト作るかなぁ。 あとは、カンファレンスではなく、いろんな会社に遊びにいきたいと思ってます。 入門的な話をしてほしいような方、こんな使い方してますっていう話をしていただける方、大募集です。 これもGoogle Formでも作ってみるか。\nブログなぁ。小さな習慣を読んだのに、習慣化できてないので、なんとかしないとという意味で。。。が、頑張ります。。。\nRustの継続＆開発の継続もですね。Java歴が長いので、他の言語を勉強しようと思ってRustやってますがなかなか身についてないというか、時間を取れてない。これもコツコツやらないとなー 検索関連の開発もちょっとずつやりたいなと思ってるんで、LukeへContributeしようかな。\n切実なんですが、日本に弊社のエンジニアを増やしたいなと。特に人前で喋ってもらえる人が増えると助かるんです。弊社最近、ユースケースが増えてきてて、追いつかなくてwダレカタスケテーw\nさーて、そろそろ紅白のサザンが始まるんで終わりです。\n今年も様々な方々に様々な面で助けていただきました。本当にお世話になりました。 この場を借りてお礼申し上げます。\n来年ももちろん、助けてもらうんで、よろしくお願いいたします！ あと、話聞きたい方、声かけてくださーい。\n","date":1546240485,"dir":"post/2018/","id":"6c226ee1519fbf910197cc1d5c5a5756","lang":"ja","lastmod":1546240485,"permalink":"https://blog.johtani.info/blog/2018/12/31/looking-back-2018/","publishdate":"2018-12-31T16:14:45+09:00","summary":"今年も振り返りブログをかけてます。よかったw 振り返り（2017年に書いた抱負から） まずは去年の抱負を元に。 もっと英語の継続＆TOEIC まぁ、","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2018）"},{"contents":"Elastic stack (Elasticsearch) Advent Calendar 2018の25日目の記事になります。 今年最後のAdvent Calendarです！来年も忘れてなければやるはず！\n今日は、すでにalpha2までリリースされた7系でどんな変更が入るのかをちょっとだけ紹介します。 ほんとにちょっとだけですよ。\nKibanaのk7 design (kibana) Kibanaの新デザインです。K7って呼ぶのかな？\nまだ、メニューと一部が実装されているだけですが、7.0.0でガラッと変わりそうです。 そのほかの画面のIssueはこちらです。 \u0026ldquo;k7\u0026quot;で検索しただけですが。メタIssueが見つからなかったんで。例えば、こんな感じでアプリとかのスイッチとかがこんな感じになるよというデザイン案が観れたりします。\nZen2 (elasticsearch) Elasticsearchの新しいクラスター管理機構アルゴリズムになります。 Zenと呼ばれる独自実装のものを6系までは使っていましたが、7系向けに変更がかかりました。 実際には、Nodeを探す仕組み、Masterの選出アルゴリズム、クラスター状態の管理などを行います。 上記のリンクにあるようにドキュメントも詳しくなりました。 信頼性をさらに向上し、設定ミスを起こしにくくして、より使いやすくという目的で様々な変更が加えられています。 これが、メタIssueかな？ アルゴリズムの変更や、クラスターの状態の管理の方法などの変更に関するIssueやPRにリンクが貼ってあります。\n新しいデータタイプ (elasticsearch) Feature/Feature vector datatype ドキュメントはこちらとこちら\nfeature queryと合わせて使用するためのフィールドで、しかもクエリのスコア計算「のみ」に使用するフィールドになります。 検索条件やソート、Aggregationの対象ではなく、クエリのスコアに影響させたい値を入れておくためのフィールドです。 6から追加された機能の「track_total_hits」をfalseにした時と合わせると、function_scoreなどで計算をしていた場合よりも、検索性能が上がるという利点まであります。 ちなみに、「track_total_hits」は検索ヒット数を計算しないで、上位のデータを取得する時にクエリを早くするといったことができる機能になります。 Index Sortingと組み合わせることで威力が発揮できる仕組みになるはずです。\nFilebeat supports NetFlow (beats) NetFlowが入力として追加されます。 Filebeatと言いつつ、File以外の入力が徐々に増えてきてますね（UDPやTCPにも対応しましたし）。 ネットワーク機器などの監視を行う方などにはさらに便利になってくるのではないでしょうか？ （私はこの辺りは不得手なので、誰か使ってみてもらえればと！）\nまとめ まだ、序の口って感じですが、今年はこの辺で。7系ではここであげた以外にも様々な機能が追加されています（もしくは予定です）。 Elasticのドキュメントの良いところは、masterブランチのドキュメントも公開されていることです。 ドキュメントのバージョンを7.0.0-alpha2にすれば、masterブランチで追加されたページが見れるので、 興味のある方は眺めてみていただければと。物によって、リリースノートが書かれていなかったりするので注意は必要ですが。\n今年もあと数日になりましたが、Advent Calendarへの参加ありがとうございました！ 来年ももちろんやりますので、年始からネタを考えてくださいね。\n来年一発目は、第28回Elasticsearch勉強会 - 6.5機能紹介 -になります。ウェビナーでも紹介しましたが、6.5で入った様々な新機能をデモありで紹介する予定です。 興味のある方はぜひご参加ください。\nでは、来年もよろしくお願いいたします。\n","date":1545663601,"dir":"post/2018/","id":"ee62cb0b9a97f990df1ed0266a7027e2","lang":"ja","lastmod":1545663601,"permalink":"https://blog.johtani.info/blog/2018/12/25/whats-new-in-elastic-stack-7/","publishdate":"2018-12-25T00:00:01+09:00","summary":"Elastic stack (Elasticsearch) Advent Calendar 2018の25日目の記事になります。 今年最後のAdvent Calendarです！来年も忘れてなければやるはず！ 今日は、すでにalp","tags":["elasticsearch"],"title":"Elastic Stack 7.0で入ってくる新機能をちょっと紹介"},{"contents":"Elastic stack (Elasticsearch) Advent Calendar 2018の1日目の記事になります。\nちょっと遅れちゃいました。。。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみようと思います。毎年恒例ですね、ここ数年。\nElastic Stack 6.2.0リリース(2月) リリース記事はこちら\nAPMがGAリリースされ、Beats monitoring UIも追加されました。Stackとしての統一度がちょっとずつ上がってきた感じですね。 Kibanaのホーム画面（左メニューのKibanaアイコンをクリックした時）にデータ登録のチュートリアル的な画面が追加されています。 特にBeatsを利用する時の流れが簡単にわかるのがいい感じです。Metricsなどはローカルでちょっと試すのにも簡単な流れですので、ぜひ一度やってみてもらいたいなと。 個人的にはtermsを使ったパイチャートで、その他の数値がどのくらいあるかといった表示ができるようになって、やっと帰ってきた！（Kibana 3の頃にはあった機能）という印象でした。\nElastic{ON}18開催(2月) 第4回目のユーザーカンファレンスがSFで開催されました。 今年のキーノートが今年最大のニュースですね。 X-Packのコードの公開が発表されたのがこの時でした。 個人的に今後もオープンソースに携わっていきたいと思いながら日々働いていますが、 Elasticのオープンソースへのこだわりと、シンプルな考え方を再確認して素晴らしい会社で働けてるなーと。 商用のソースコードを公開してユーザーや顧客の皆さんとより良いものを作っていきたいという形ですので、今後もよろしくお願いします！ キーノートの動画はこちらからご覧いただけます。\nそのほかにも次のような発表が行われました。\nSQL for elasticsearch Canvas Elastic App Search(旧Swiftype) Elastic Stack 6.3.0リリース(6月) リリース記事はこちら\n2月末のElastic{ON}で発表されたX-Packのコードの公開にはやはり時間がかかりました。 有償コードのリポジトリとの統合やライセンスの変更、テスト環境などなど、色々大変だったみたいです。 ようやく公開され、ベーシックのライセンスの扱いなども変わり、より使いやすくなったのがこのタイミングです。\nX-Packをプラグインとしてのインストールが不要に ベーシックライセンスがデフォルトでONに。6.3から登録などが不要に。 Apache 2.0ライセンスの部分のみのディストリビューションも別途ダウンロードできるようになどなど 日本でもリリースウェビナーをやりました。ご覧いただけましたかね？\nElastic Cloud Elasticsearch Serviceがより使いやすく(8月) リリース記事はこちら\nこれまでは、メモリとストレージの比率だけしか指定できなかったのですが、 このリリースで様々なユースケースに応じた組み合わせが可能になりました。 CPUやメモリリソースよりもストレージを大きくしたりなどです。 専用マスターノードを追加できたり、待望の機械学習（Machine Learning）が提供されたりと色々と変更があり使いやすくなったかと。 昔からよく聞かれる、Kuromojiなどのカスタム辞書を登録する機能もあるので、Elastic Cloud便利です。 ご存知ない方は、14日間のトライアルもありますので試していただければと！\nElastic Stack 6.4.0リリース(8月) リリース記事はこちら\nフィールドエイリアスや韓国語のアナライザーがElasticsearchに追加されました。 Kibanaはデザインがここからさらに少しずつ変更が入ってたりします。 Elastic UIフレームワークと呼ばれるデザイン用のライブラリが、ElasticのプロダクトのUIに取り込まれていってる感じです。統一感が取れてきてますよね。私が開発しているAnalyze UIのプラグインにも取り込みました。 あとは、マイクロソフトのde:codeで話をさせていただいた、Logstash向けのAzure Moduleがリリースされたのもこのバージョンでした。AzureのEvent Hubからデータを取り込んで、SQLデータベースのモニタリングや、ユーザーの認証などをとってKibanaで可視化するものです。\nもっとも気に入っているのはサンプルデータの登録が簡単になったことです。これまでは、KibanaとElasticsearchを用意した後に、データを入れるためにFilebeatなどを使ってから、ようやくKibanaで遊べるという形でした。 6.4からは、ElasticsearchとKibanaを立ち上げて、Kibanaのホーム画面の「Sample Data」のリンクを押した後に、「Sample flght data」の「Add」ボタンを押せばKibanaからデータが登録されます（サンプルデータについてはこちら）。とりあえず触ってみたいという方への敷居がさらに下がったのではないかなぁと。\nElastic認定エンジニア第1号(8月) ブログ記事はこちら\n認定制度も始まりました。Elasticsearchの知識、経験を問われるテストを受けていただき、合格すると認定されるというやつです。 なんと、社外で世界初の認定エンジニアがアクロクエストの吉岡さんでした（上記ブログ参照）。 私もトレーナーやってるのもあり、慌てて認定をとったりしましたw。 認定テストは筆記ではなく、実際に作業をするテストなので実践的です。 トレーニングの受講が必須ではないのも面白いなぁと思いました。 トレーニングや認定エンジニアに興味がある方は、Elasticのトレーニングのサイトをご覧ください。 1月末にはまた、日本語でElasticsearchのトレーニングも開催されます！\nElastic Cloud Enterprise 2.0リリース(9月) リリース記事はこちら\nElastic Cloud Enterpriseをご存知ない方もいらっしゃるかもしれません。 Elastic Cloudの裏側で利用しているクラスターの起動などの仕組みを製品として提供しているのがこちらになります。 Elastic Cloudで機械学習や様々な構成ができるようになったものがリリースされたのがこの2.0です。 複数のElasticsearchクラスターを管理したい場合には、こちらが便利なツールになってるんじゃないかなぁと。 部署ごとにクラスターを提供するといったことが可能になるので、乱立する前に利用するのも便利かなーと。\nニューヨーク証券取引所で株式を公開(10月) ブログ記事\n日本語でブログ(10月) Elasticsearchの運用に関する典型的な4つの誤解というブログを書きました。4年も働いてるのに、会社のブログに翻訳以外で書いたことなかったので。。。 Twitterや勉強会、ブログ記事などで見かけるよくある誤解に関する記事を書いてみました。 Elasticは英語のブログも活発に書かれているのですが、今後もこのような形で日本語でのブログも頑張りますので、 読んでみたいものなどあればコメントいただければと。\nまぁ、弊社の大輪は色々書いてるんで、私がもっと頑張れって話ですかね。。。\nElastic Stack 6.5.0リリース(11月) リリース記事はこちら\n昨日（11/30）のウェビナーでも話をさせていただきましたが、Elastic Stack 6.5は「本当にマイナーリリース？？？」と思うほど盛りだくさんの機能がリリースされました。\nインフラUI、ログUI Elastic APMの分散トレーシング対応 Java \u0026amp; Go APM Agent GAリリース Cross Cluster Replication ODBCドライバー Kibana Canvas Kibana Spaces Data Visualizer for files Functionbeat LogstashのApp Search output リストアップしただけでもこれです。45分のウェビナーでは伝えきれてないなぁとも思ってますので、何か検討しようと思います！\nElasticsearch勉強会(3月から12月) Elasticsearch勉強会ページ\n今年は、6回の勉強会を開催（1つは12月19日開催）しました。 9月からは、ユースケースなど、もっと参加者の皆さんの興味があることにフォーカスしながら開催をしてみ始めました。 参加しやすくなってればいいのですが。。。 そろそろまたアンケートをとったりして、参加しやすいか、どんな改善がしてほしいかなどを聞きたいなと思っています。\n12月はもっと皆さんと喋りたいなということで、スピーカーなしの「LT\u0026amp;忘年会」にしてみました。 私やElasticのものも参加するので、ぜひ色々聞いたり、他のコミュニティの方達の使い方を聞き出して、 新しい発見をしていただければなーと思います。LTでスピーカーの練習をするってものありですよ！（まだ誰も応募してくれてない。。。） 発表することで、フィードバックがもらえて、自分の使い方に自信が持てたり、その他の視点を得ることができると思いますので、 ぜひ発表してみていただければと。\n12月のjohtani出没イベント 12月は以下のイベントにブースを出してます。イベントに参加される方ははぜひブースにお立ち寄りください！！\n12/4-5 : Japan Container Days - 東京 12/8 : OSC福岡 - 福岡 12/15 : JJUG CCC 2018 Fall - 東京 12/19 : 第27回Elasticsearch勉強会 - 東京 なんか、忙しそうだな。。。\nまとめ 駆け足でしたが今年を振り返ってみました。 今年も色々ありましたが、今後もよろしくお願いいたします。\nさて、Elastic Stack Advent Calendar 2018は今日から25日まで続きます。こらからの記事を楽しみにしています！\nということで、次はkaibadash@githubさんの「ぼくの考えた最強のElasticsearch index設定を最強にわかりやすく書くぞ！！！」になります。お楽しみに！\n","date":1543628918,"dir":"post/2018/","id":"ba45ddd3042dad59a12e5937644f7246","lang":"ja","lastmod":1543628918,"permalink":"https://blog.johtani.info/blog/2018/12/01/whats-happen-at-elastic-in-2018/","publishdate":"2018-12-01T10:48:38+09:00","summary":"Elastic stack (Elasticsearch) Advent Calendar 2018の1日目の記事になります。 ちょっと遅れちゃいました。。。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみよ","tags":["elasticsearch"],"title":"2018年のElastic StackとElastic"},{"contents":"（転職する少し前までパスポートすら持ってなかったのに）今の会社に転職してから、半年に1度の割合で海外への出張が発生する生活を送っています。 4年目になりますが、今回いくつか新しいガジェット？アイテム？を出張用に導入したので感想を書いておこうかなと。\nとりあえず、以下の4つです。\nFelimoa ネック ピロー これまでは、無印で購入した「フィットするネックピロー」を使ってました。 特に使ってる間は問題ないのですが、どうしてもかさばります。。。 そんな時、FBで見かけたのがこちら。\n厚みがないので、持ち運びが便利でした（商品紹介の中にありますが、リュックにつけると邪魔にならない）。 飛行機の中で使うので、それほど暑くない場所なので、ムレる感じでもなく。 ただ、ヘッドフォン＋真横にフレームがくる形になるとヘッドフォンに干渉するので、 私はフレームを顎の下の方に寄せた形で使ってました。 軽さと場所を取らないのがよかったです。\nノイズキャンセリングヘッドフォン これまでは、SONYのNW-A847という ノイズキャンセリング機能付きのウォークマン＋アクセサリーで外部入力を取り込む形で、飛行機で映画を見ていました。 これ自体が8年前の製品ですね。。。 これとは別に、冬の寒い時期は防寒も兼ねてヘッドフォンを使用しています。 MDR-10Rを使ってたんですが、昨年こんな感じになりまして。。。\n応急処置 pic.twitter.com/uDErZWpPVC\n\u0026mdash; Jun Ohtani (@johtani) 2017年11月10日 で、ヘッドフォンの買い替えを検討してたんです。 そこへ飛び込んできたのがSonyの新しいノイズキャンセリングヘッドフォンでしたと。\nせっかく買い換えるし、今度はいいものを長くということでフライト前日に購入してしまいました。 結論としては高いけど買ってよかったと。よかった点はこんな感じです。\n軽い イヤーパッドが耳を抑えることがないので長時間でも気にならない 人の声だけノイズキャンセリングをオフにする（騒音などはキャンセルしてくれる） バッテリーが長時間 ヘッドフォンを外さないでも案内を聞くことができる「クイックアテンションモード」 などなど。行きのフライトで5時間も遅れが出ましたが、空港、飛行機内で非常に快適に過ごせました。 大事に使おう。。。\ncw-x 知り合いがFBにアップしてて、立ちっぱなしの仕事だったり、長時間のフライトでも足が疲れないという噂を聞いて購入しました。\n長時間のフライトの後に、ホテルで1泊しても足の疲れって結構残ってるんです。 今回、12時間のフライトでズボンの下に履いて行きましたが、足の疲れがほぼありませんでした。 デブになりつつあり、足太くなって来てるので、履くのはちょっと苦労しますが。。。もともときつめに作ってるんじゃないかなぁ（希望的観測）。 帰りも使用しましたが、帰りはフライト前に1万歩ほどダブリンの街中を歩き回ってたので、流石に疲れが出てます。。。 今度は、カンファレンスのブースなどで立つことが多いシーンでも使ってみて、疲れがどうなるかを試してみようと思います。\n携帯ウォシュレット 初めて購入しました。海外のホテルで1週間とか連泊するんですが、トイレットペーパーがやはり硬めなのが気になって。。。\n世界に誇る日本の技術の一つだと確信してますw ドイツに長期出張してた友人が便利だよと言ってたので、思い切って購入して持って行きました。 硬めのトイレットペーパーも気にならなくなるのでとても幸せな気分ですw\nまとめ とりあえず、今回はこんな感じです。 総じて導入してよかったなという感じでした。 他にもおすすめ出張グッズとかあればコメントいただけると嬉しいです。\n普段使ってるものとか、どういうものを持っていってるとか興味ある人いるかなぁ？ ではでは。\n","date":1539794095,"dir":"post/2018/","id":"3fd9052870778e14ab4a5acbc8c24af4","lang":"ja","lastmod":1539794095,"permalink":"https://blog.johtani.info/blog/2018/10/18/items-for-long-businesstrip/","publishdate":"2018-10-18T01:34:55+09:00","summary":"（転職する少し前までパスポートすら持ってなかったのに）今の会社に転職してから、半年に1度の割合で海外への出張が発生する生活を送っています。 4","tags":["misc"],"title":"新規導入した長期出張用のアイテムをいくつか紹介"},{"contents":"毎月開催の2回目になります。 今回は日経さんの会場をお借りしての開催となりました。\n前回から、スピーカーの募集をhttp://bit.ly/SpeakerElasticTokyoMeetup で行なっております。 ぜひ皆さんのノウハウを共有していただけると助かります。 また、次回もすでにスケジュール済みです。次回は「ログ/メトリック分析」回になります。\n以下は、個人的なメモになります。\nメディアコンテンツ向け記事検索DBとして使うElasticsearch / Future Architect 株式会社 村田 靖拓さん (twitter: @famipapamart) メディア記事コンテンツ検索 全ての情報が1indexに入っているようにすること。 typeは少し悩んだ。 範囲検索にはならない場合がある。（文字列で登録してWildcard検索できるようにした） kuromojiで基本対応 異体字についてはchar filterでマッピング 細かな設定とかもスライドにて公開予定。 基本的なプラグインだけで対応した Dynamic Field mappingを有効にしたまま対応 パフォーマンス検証 初回のインデックスのロードはこの辺かなぁ？。 自力でQueryのoffset-limitを構築するのかぁ。 ソート条件が固定らしいのでできる方法 minne での検索運用(仮) / @_shiro16 さん ハンドメイドなものをマーケットプレイスがminne SolrからElasticsearchに切り替えた話 2016/02以降はEs 昔は、DBからSolrへ同期 Es版ではDBからの同期ではなく、Workerに対してリクエストを入れる 現状は独自にEC2で運用中 ユーザーが求めているものがきちんとでているかを計測している 行動ログはどんな感じ？ TDにログを入れて、CTRとかを計算してre:dashで可視化 A/Bテストも実施 指標はキャンペーンなどが実施されている場合にブレる場合もある トレンドをログから知ることができる Function Scoreでスコアを変更してる 季節的な単語でスコアを変更したりする ドリンクの対応などをして聴けてないところが。。。 query_stringのはなし / 加藤遼さん　(日本経済新聞社) 電池が切れそう＋ピザとかの手配をしていたらメモが取れず。\n苦労が滲み出る感じのセッションでした。 query_string queryが実際にどんなクエリになっているかの説明を交えて説明してもらえたのはすごくよかったんじゃないかと。 まとめ 検索は話してくれる人が多いし話題に事欠かないなぁという印象でした。 今回も、スピーカーの皆さん、会場提供をしていただいた日経さんありがとうございました。\n他のユースケースのスピーカーも募集してます。ぜひMeetup.comの概要に記載してあるリンクからスピーカーの応募をお願いします！\n","date":1539765230,"dir":"post/2018/","id":"d3fa23c9066f943f10e8883de9340dea","lang":"ja","lastmod":1539765230,"permalink":"https://blog.johtani.info/blog/2018/10/17/26th-elasticsearch-tokyo-meetup/","publishdate":"2018-10-17T17:33:50+09:00","summary":"毎月開催の2回目になります。 今回は日経さんの会場をお借りしての開催となりました。 前回から、スピーカーの募集をhttp://bit.ly/Sp","tags":["elasticsearch","勉強会"],"title":"第25回Elasticsearch勉強会を開催しました。"},{"contents":"7/25にJJUGナイトセミナーでElastic Stackの紹介とAPMのJava Agentの紹介をしたので、補足のブログです。 （久々に書くな。。。）\nスライドとサンプルアプリのリポジトリはこちら。\nスライド：https://speakerdeck.com/johtani/intro-elastic-stack-and-elastic-apm-java リポジトリ：https://github.com/johtani/apm-beats-kubernetes-demo/tree/master サンプルアプリ 勉強会の頭でサンプルアプリへのアクセス用QRコードを用意して質問してもらう感じにしました。\nアプリ自体が質問の受付と、そこにある質問に対して聞きたいかどうかのVoteができる仕組みになっています。 セッション最後にこの画面をみながら答えました。 手を挙げていただくよりも、匿名（名前入れるようになってますが、実名である必要はない）で登録できるし、 みんなが聞きたいかどうかもわかるので便利だなぁと。\n元は、Elastic{ON} 2018であった「Docker \u0026amp; Kubernetes Log Collection and Monitoring with Beats and Elasticsearch」のサンプルアプリです。 これをSpring Bootに移植して、ちょっとだけサンプルコードを追加したものになります。\n構成とかの補足 スライド、GitHubのリポジトリのREADMEにある図は、k8s上のサンプルアプリケーションの構成だけでした。 ElasticsearchとKibanaを含めた図はこんな感じです。\nk8s上の各種Beats、APM Serverは一旦Elastic CLoud Elasticsearch Service（AWS Tokyoリージョンにデプロイ）に対してデータを投げます。 で、KibanaはGKE(k8s on GCP)で動かして、実際に勉強会ではkubectl proxyで接続してから表示していました。 この構成にしている理由は次の理由です。\nElastic CloudのElasticsearchクラスターにデータを投げている理由 クラスターの起動が簡単。 データを永続化したい。k8sのアプリは必要がなくなったらデータを削除したいから。 k8sのdeploymentを書く手間を省く 普段使ってるので。。。 KibanaをGKEで動かした理由 Elastic Cloudでは*「現時点(7/29現在)」*で、KibanaでAPM専用のUIを起動できない ローカルである必要はない といったところです。 Elastic Cloudのインスタンスを起動したままにしておけば、デモをしなくても、このタイミングのログ、メトリクスを 再利用して話をすることも可能です。\nまとめ ということで、簡単ですが、構成の補足でした。 勉強会では告知したのですが、今後の勉強会はトピックスごとでやりたいなと。ということで、どんなトピックスに興味があるのか、スピーカーの応募にはどんなツールが話しやすいかなどといったことのアンケートを集めております。ぜひご協力ください！ また、アンケート、このブログに関する質問がある場合は、@johtani、もしくはブログへのコメントでお願い致します。\n今後の勉強会のやり方などについてアンケートを実施中です。https://t.co/XU15CHro0n 皆さん是非ご協力ください。ここにない項目については返信をお願いします。 #elasticsearchjp\n\u0026mdash; Jun Ohtani (@johtani) 2018年7月23日 ","date":1532843130,"dir":"post/2018/","id":"10ae016e19fff6ae9cfaeb8534fa47f9","lang":"ja","lastmod":1532843130,"permalink":"https://blog.johtani.info/blog/2018/07/29/apm-java-at-jjug/","publishdate":"2018-07-29T14:45:30+09:00","summary":"7/25にJJUGナイトセミナーでElastic Stackの紹介とAPMのJava Agentの紹介をしたので、補足のブログです。 （久々に書く","tags":["勉強会"],"title":"JJUGナイトセミナーで話しました"},{"contents":"第2回から少し間が空いてしまいましたが、templateで作成したプラグインのディレクトリ構成とどういう流れでデータがやり取りされるかについてみていきます。 （2018/02月時点で作成したディレクトリ構成にしたがって説明します） ちなみに、JavaScriptの優れた開発者ではないので、誤解している点や、効率の悪い書き方などがあるかもしれません。見つけた場合は、連絡をいただければと思います。\nでは、まずは作成したディレクトリ構成についてみていきましょう。\nディレクトリ構成 simple-sample-kibana-pluginがプラグインのプロジェクトのトップディレクトリになります。このディレクトリに次のような構成でサブディレクトリが存在します(なお、画像はIntelliJに取り込んだ後のディレクトリになっているので、.imlなど、不要なファイル/ディレクトリが存在しています)。\n主要なディレクトリ、ファイルについて簡単に一覧で説明します(順不同)。\nファイル/ディレクトリ名 説明 index.js プラグインの本体。Kibanaはこのファイルのオブジェクトを読み込みプラグインを起動。設定などの読み込みもこちら。 package.json npm/yarnのパッケージに関する情報を定義するファイル README.md README。プラグインの説明などを記載する。インストール方法なども記載すると便利 public ブラウザ側に配布されるプログラムや画像一式 public/less/main.less LESS用のファイル。アプリ固有のスタイルなどを記載 public/app.js ブラウザ側で読み込まれるプラグインのモジュールなど。 public/template/index.html HTMLのテンプレート。ブラウザ上での描画に利用 server/routes Kibanaサーバー側で動作するプラグイン。hapi.jsを利用してREST APIを実装する 重要なファイルについて少しだけ説明します。\npackage.json npmやyarnでビルドなどをするときに使用するパッケージ情報を記載するためのファイルです。 プラグインの名前、バージョン、説明などを記載します。 Kibanaのバージョンについてもこちらで管理します。この情報を また、ライブラリなどの依存関係についてもこちらで記載しています。 以下、抜粋。\n{ \u0026#34;name\u0026#34;: \u0026#34;simple-sample-kibana-plugin\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;0.0.0\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;Sample plugin for explaining how to make kibana app\u0026#34;, \u0026#34;main\u0026#34;: \u0026#34;index.js\u0026#34;, \u0026#34;kibana\u0026#34;: { \u0026#34;version\u0026#34;: \u0026#34;6.2.1\u0026#34;, \u0026#34;templateVersion\u0026#34;: \u0026#34;7.2.4\u0026#34; }, \u0026#34;scripts\u0026#34;: { \u0026#34;lint\u0026#34;: \u0026#34;eslint **/*.js\u0026#34;, ... }, \u0026#34;devDependencies\u0026#34;: { \u0026#34;@elastic/eslint-config-kibana\u0026#34;: \u0026#34;^0.14.0\u0026#34;, \u0026#34;@elastic/eslint-import-resolver-kibana\u0026#34;: \u0026#34;^0.9.0\u0026#34;, \u0026#34;@elastic/plugin-helpers\u0026#34;: \u0026#34;^7.1.3\u0026#34;, ... \u0026#34;expect.js\u0026#34;: \u0026#34;^0.3.1\u0026#34; } } ちなみに私は、versionなどをリリースするたびに変更しています。\nindex.js 最初にKibanaに読み込まれるオブジェクトになります。 Kibanaのアプリの名前や、必要なモジュールなどを記載します。\nまた、kibana.ymlから設定など読み込む処理なども書くことができます。\n2行目のexampleRouteはサーバー側のAPIとして利用するhapi.js用のファイルのパスになります。\nuiExportsはこのアプリの画面に関する設定などの記載になります。 appの部分が実際にアプリの情報で、 mainがあとで説明するこのプラグインのUIのためのJavaScriptファイル(public/app.js)になります。mainですので、最初に読み込まれる処理が記載されているものを指定します。app.jsというファイル名を変更する場合は、こちらのappの部分を変更したファイルに合わせましょう。\nconfig(Joi)の関数が設定ファイルの読み込みなどの処理を記載する場所です。\ninit(server, options)の関数が初期化処理を記載する場所になります。 このサンプルアプリでは、2行目のimportで読み込んだhapi.js用のファイルの関数を呼び出しています。引数で渡しているserverがhapi.jsのserverオブジェクトになります。 routeメソッドを使用して作成しているプラグイン用のREST APIを追加しています。\nimport { resolve } from \u0026#39;path\u0026#39;; import exampleRoute from \u0026#39;./server/routes/example\u0026#39;; export default function (kibana) { return new kibana.Plugin({ require: [\u0026#39;elasticsearch\u0026#39;], name: \u0026#39;simple-sample-kibana-plugin\u0026#39;, uiExports: { app: { title: \u0026#39;Simple Sample Kibana Plugin\u0026#39;, description: \u0026#39;Sample plugin for explaining how to make kibana app\u0026#39;, main: \u0026#39;plugins/simple-sample-kibana-plugin/app\u0026#39; }, ... }, config(Joi) { return Joi.object({ enabled: Joi.boolean().default(true), }).default(); }, init(server, options) { // Add server routes and initialize the plugin here exampleRoute(server); } }); }; public/app.js 画面用のモジュールです。 uiRoutesという機能を使用して、アプリの呼び出しURLを定義します。テンプレートで作成したばかりの場合は、/というURLが追加されるのみです。\n実際に画面を表示する際に動くコントローラーの部分はその下の uiModules.controllerに指定してあるfunctionが画面描画の 処理を書く部分になります。 templateで作成したプラグインでは、\u0026ldquo;title\u0026quot;など表示に必要なデータを$scopeというオブジェクトに詰め込んでいます。 これはAngularJS(1系)でのモデルオブジェクトになります。\nimport moment from \u0026#39;moment\u0026#39;; import { uiModules } from \u0026#39;ui/modules\u0026#39;; import uiRoutes from \u0026#39;ui/routes\u0026#39;; import \u0026#39;ui/autoload/styles\u0026#39;; import \u0026#39;./less/main.less\u0026#39;; import template from \u0026#39;./templates/index.html\u0026#39;; uiRoutes.enable(); uiRoutes .when(\u0026#39;/\u0026#39;, { template, resolve: { ... } }); uiModules .get(\u0026#39;app/simple-sample-kibana-plugin\u0026#39;, []) .controller(\u0026#39;simpleSampleKibanaPluginHelloWorld\u0026#39;, function ($scope, $route, $interval) { $scope.title = \u0026#39;Simple Sample Kibana Plugin\u0026#39;; $scope.description = \u0026#39;Sample plugin for explaining how to make kibana app\u0026#39;; ... $scope.$watch(\u0026#39;$destroy\u0026#39;, unsubscribe); }); server/routes/example.js hapi.jsというNode.jsのためのサーバーフレームワークです。 このフレームワークをKibanaは使っており、Kibanaのサーバーとブラウザとのやり取りに使用するREST APIを記述するために使用しています。 例えば、Elasticsearchとのやり取りを実際に行うAPIなどをこのREST API内部で記述します。\nexport default function (server) { server.route({ path: \u0026#39;/api/simple-sample-kibana-plugin/example\u0026#39;, method: \u0026#39;GET\u0026#39;, handler(req, reply) { reply({ time: (new Date()).toISOString() }); } }); } pathの部分がブラウザ側からアクセスするURLになります。 実際にElasticsearchとやり取りする処理の書き方については、次回の記事で説明します。\nアーキテクチャ（簡易版） ざっくりですが、ファイルやディレクトリについて説明しました。 簡単なデータのやり取りについての流れを説明します。\nKibana自体はNode.jsで実装されサーバーとして動作していますが、ブラウザでアクセスすることで画面を描画しています。 簡単なコンポーネントを並べるとデータのやり取りはこのような形です。\nすごく簡易で大雑把な絵ですが。。。\n実際のプラグインとしては大きく、2つの処理があります。\nブラウザ上の処理 クリックなどのイベント処理 HTMLなどのレンダリング処理 Kibanaサーバー上の処理(Elasticsearchなどとの通信が必要な場合) 外部との通信処理 ブラウザ上では重い処理 絵に記載しましたが、ブラウザ上の処理についてはAngularJSが主なフレームワークで、サーバー上の処理についてはhapi.jsがフレームワークとなっています。\nまとめ ということで、今回はディレクトリ構造とファイルの説明、どういったフレームワークが使われ、データのやり取りがどのように行われているか説明しました。\n次回からは、実際に私が作成したAnalyze UIを元にElasticsearchとのデータのやり取りなどについて紹介していきます。\n","date":1524205801,"dir":"post/2018/","id":"04d818cbaac08b2915db15e0bffdcb5b","lang":"ja","lastmod":1524205801,"permalink":"https://blog.johtani.info/blog/2018/04/20/directory-layout-and-architecture/","publishdate":"2018-04-20T15:30:01+09:00","summary":"第2回から少し間が空いてしまいましたが、templateで作成したプラグインのディレクトリ構成とどういう流れでデータがやり取りされるかについ","tags":["Kibana","plugin"],"title":"Analyze UIとKibanaのプラグインの作成方法（第3回）"},{"contents":"#MANABIYA のブースでセッション時間の合間はお客さん少ないので、ブログを書いてみたり。 ここ数年、スポンサーとして色々なカンファレンスに参加してるんですが、それについてちょっと気なることがあったので。\nスポンサー情報ってどうやって探してます？ 職業柄、カンファレンスにCfP出してセッションしてみたり（落ちること多いけど）、スポンサーとしてブースを出したりしています。\nで、疑問があるんですが、みなさんどうやってカンファレンスの情報をゲットしてます？\n数年やって来て、検索したりして見つけてスポンサーした結果、 これまでスポンサーしていたので、情報が流れてくるという感じになりました。 それ以外だと、@yusuke さんに教えてもらったりと言うのがあったんですが。。。\n自分が知らない、自分のTwitterで流れてこないという情報をどうやったら集められるかな？と言うのが今の課題になってます。 と言うことで、ブログを書いてみました。\nカンファレンスを検索できるサイトとか便利？ で、私の会社は検索エンジンの会社なんで、検索できると便利では？と考えるんです。\nCfPの応募期間で絞り込みできたり、場所で検索できたり、スポンサー情報を取得する方法が載ってたりすると便利なのではないかなと。 便利に思うのが自分だけでは？と言うのがあるんですが。。。\nあると嬉しい人、データを掲載したいなと言う人いますでしょうか？ Google Formなどで入力してもらえるようにして何か作るのもありかなぁと考えているところです。 それとも、スポンサーを募っているカンファレンスのスタッフや企業の人は、こういう情報は特定の人にだけ知ってもらったりしたいでしょうか？\n自分だけではわからないことが多いので、懸念事項や、それダメでしょ？ あると便利！などのフィードバックをいただけると助かります。\nそれ以外に、カンファレンス自体の場所、開催日程、サイトへのURLなどが検索できると便利だったりするかも？というのもあります。\nとりあえず、自分が知ってるものだけ、個人的に検索できるようにしたりするのがいいかなぁ。。。 コメントお待ちしてます！\n","date":1521867012,"dir":"post/2018/","id":"8cc6b19cd410e638f4beaf1642f4f52a","lang":"ja","lastmod":1521867012,"permalink":"https://blog.johtani.info/blog/2018/03/24/how-to-find-conferences/","publishdate":"2018-03-24T13:50:12+09:00","summary":"#MANABIYA のブースでセッション時間の合間はお客さん少ないので、ブログを書いてみたり。 ここ数年、スポンサーとして色々なカンファレンスに参加してるんです","tags":["カンファレンス","スポンサー"],"title":"カンファレンス情報の探し方（CfP、スポンサー応募、開催期間など）？"},{"contents":"Rustで言語処理100本ノックの続きで、05と06です。\n05. n-gram 問題はこちら。\nみんな大好きn-gramです。単語と文字があるので、それぞれ別関数として実装しました。問題はbi-gramとn=2だったのですが、一応、nを引数に取る形にして実装しました。\nまずは、単語です。\n前に実装した時は、自分で頑張って、先頭から数えたりしてたんですが、Rustにはwindows(n)という便利なメソッドがsliceにあり、これを利用したらこんな簡単になりました。 sliceは特定のシーケンス（配列）に対してある特定のサイズのViewを作ってくれます（説明あってる？）。 ということで、文字列から、単語の配列（スペース区切りで単語にしている）を作り出して、windows(n)メソッドを通すと、 nで指定した数字の個数だけの単語の配列を先頭から、1単語ずつずらして作ってくれます。まさに、n-gram! 戻り値は配列の配列です。 1点だけ疑問点があるのは、「空白で区切ったものが単語」という考え方で良いかどうか？という点です。特に問題文にはそれが明示されていなかったので、このような前提を置いてあります。\ninvalid_n(text, n)はnの値や入力された文字列をチェックする関数です。入力チェックですね。nが1よりも小さい場合、入力文字列が空文字の場合は、warningでメッセージを出して、空の配列を返す仕組みになっています。\n次は、文字です。\n単語とほぼ一緒ですが、入力文字列を、1文字ずつの配列にしているところが異なります。 また、windowsメソッドで取り出された、1文字ずつのn個の配列を文字列に修正してから、結果の配列に入れています。 ここでも疑問は空白をどう扱うか？になります。 現時点では、空白も1文字とカウントして扱うことにしてあります。 どっちがいいのかなぁ？\n06. 集合 問題はこちら。\nまずは、文字n-gramで出てきた文字列をSetに入れる関数から。\nn-gramの問題で実装した文字n-gramの関数の戻り値を配列ではなく、BTreeSetに変えたものになります。比較などがしやすいように？と思い、BTreeSetを利用していますが、実装としてはHashSetでも問題ないかと。 この関数の集合（Set）を元に、和集合、積集合、差集合を求める関数を実装しました。\nSetのメソッドとして、それぞれ、union＝和集合、intersection＝積集合、difference＝差集合のメソッドが用意されているので、特に困ることはなかったです。 差集合については、1-2と2-1で結果が異なるはずなので、それぞれをテストケース、main.rsで出力するようにしてあります。\n所感 今回は、Rustがすでに実装してくれているメソッドがあったので楽ができました。 やりたいことに相当するメソッドがあるかどうかを調べるためにリファレンスを探さないといけないのがちょっと苦労しましたが。。。 ということで、今日はこの辺りまで。\n","date":1521549285,"dir":"post/2018/","id":"d791eaca9375ca1b36a987af22ee71dd","lang":"ja","lastmod":1521549285,"permalink":"https://blog.johtani.info/blog/2018/03/20/nlp100-ch01-05to06/","publishdate":"2018-03-20T21:34:45+09:00","summary":"Rustで言語処理100本ノックの続きで、05と06です。 05. n-gram 問題はこちら。 みんな大好きn-gramです。単語と文字があるので、それぞれ別関","tags":["Rust","nlp100"],"title":"第1章の05から06までやってみた（言語処理100本ノック）"},{"contents":"Rustで言語処理100本ノックの続きで、03と04です。\n03. 円周率 問題はこちら。\n入力文字列を.split_whitespace()で分割しておいて、単語ごとのベクタを作り出し、そこに対して文字を数えました。「アルファベットの」という注意書きがあるので\u0026quot;,\u0026ldquo;や\u0026rdquo;.\u0026ldquo;は含めずに数えるのかなということで、 charの.is_alphabetic()でA-zまでの判定をしつつ、文字のベクタを作ってから、そのベクタの長さを詰め込むという感じでやりました。\nこれ、ひょっとして、collectでベクタにしなくても、i32とかの変数でカウントするとベクタ作らなくてもいいなじゃにか？というのに書きながら気づいた。。。 必要じゃないオブジェクトを作ってるよなぁ。\n.filter().mapとかかな？この辺りの操作がイマイチ苦手。Javaでもまだ馴染めてないところなんだよなぁ。頭固すぎ。\n04. 元素記号 問題はこちら。\n大作ですね。何だろう、大作。。。 最終的に連想配列（辞書型もしくはマップ型）」ということだったので、BTreeMapに詰め込んでます。 HashMapでもいいんですが、文字列で出力した時にキーが並んで見やすいからという理由で、BTreeMap使いました。それ以上の理由はないです。普通にやるなら、HashMapかな？\n入力として、1文字だけの出力をする場所（インデックス番号）の配列を受け取ってます。1点だけ、チェックしていない、けど入力値の想定をしていて、idx_one_symbolsがソートされていて、小さいものから順番に出てくるものとしてます。関数作って、チェックすべきかな？\nで、指定された場所の最後のものが入力文字列よりも大きいかどうかというチェックもしています。（あー、テストケース書いてないな）この辺りのせいでちょっと長めになってます。\n単語の配列を作るのは03の時と同じやり方です。 回しかたがちょっと違って、.iter().enumerate()で回して、添字と値をタプル？でとりだしてます。添字を見ながら1文字取り出すのか、2文字取り出すのかの判断が必要だからです。あとは一緒ですね。1文字取り出すときは、.first()を使って見ました。 実は、2文字取り出す時と、1文字の時と同じロジック使った方が共通化できて、短くなった？？？\nということで、こんな感じでした。いつものようにツッコミお待ちしてます。\n所感 問題それぞれについてではなく、 やってて思ったのですが、問題に対して想定される結果が記載されていると嬉しいなと思いました。 ロジックについては、各自実装者に寄ったり、言語によって違いが出たりするし、議論するベースになっていいかなと思うんですが、 問題で想定されている結果（出力）があると、自分の実装にケアが足りないところがないのか？とか、ケアしなくていい点とかがわかるのかもなぁと。 ユニットテスト相当のものがあると楽かなぁと。\nこのケースどうするんだろ？みたいなのが、ところどころコメントに残ったりしてます。 出題の意図としては、その部分も議論の対象ということなのかな？\n","date":1519032848,"dir":"post/2018/","id":"e6684944c37dbdd4c08d978af9e47bed","lang":"ja","lastmod":1519032848,"permalink":"https://blog.johtani.info/blog/2018/02/19/nlp100-ch01-03to04/","publishdate":"2018-02-19T18:34:08+09:00","summary":"Rustで言語処理100本ノックの続きで、03と04です。 03. 円周率 問題はこちら。 入力文字列を.split_whitespace()で分割して","tags":["Rust","nlp100"],"title":"第1章の03から04までやってみた（言語処理100本ノック）"},{"contents":"「鉄は熱いうちに打て」ということで、言語処理100本ノックの第1章の00から02を実装してみました。\nさて、これが効率がいいのかどうかはさておき。\n00. 文字列の逆順 問題はこちら。\n最初、Vecのreverse()で逆順にして0からlen()まで回してたんですが、pop()がいい感じに後ろから取れることがわかったんで、切り替えました。 シンプルかな？\n01. 「パタトクカシーー」 問題はこちら。\n1文字ずつ取り出して、インデックスの番号が2で割ってあまりが0なら文字列に追加していくってのでやってみました。 （ブログ書いてるところで、i in 0..char_array.len()じゃなくて、(i, x) in char_array.iter().enumerate()に切り替えました。） matchとか使って綺麗に書けたりするのかなぁ？\n02. 「パトカー」＋「タクシー」＝「パタトクカシーー」 問題はこちら。\nだいぶ思考錯誤してる感じがソースに現れてます。 とりあえず、両方の文字列をcharsの配列にして個々のイテレータを回しながら、next()の戻り値があれば追加していく感じにして、 終了条件が両方Noneを通ったらにしてるけど、、、 なんか、もっと綺麗にできないのかなぁ。。。 next()のタプル返す関数作って、とかでなんかできたりするかなぁ？\ngist-it 関係ないですが、GitHubのコードを貼り付けるのに便利なサービスがあるみたいです。\nhttp://gist-it.appspot.com\nこれほんと便利だな。行数指定もできるし。 説明するのが簡単だ。\nとりあえず、今日はこの辺まで。なんか、いい知恵あれば教えてください！\n","date":1518699541,"dir":"post/2018/","id":"bbe1deec11d459bdb348051b970abdaf","lang":"ja","lastmod":1518699541,"permalink":"https://blog.johtani.info/blog/2018/02/15/nlp100-ch01-00to02/","publishdate":"2018-02-15T21:59:01+09:00","summary":"「鉄は熱いうちに打て」ということで、言語処理100本ノックの第1章の00から02を実装してみました。 さて、これが効率がいいのかどうかはさてお","tags":["Rust","nlp100"],"title":"第1章の00から02までやってみた（言語処理100本ノック）"},{"contents":"ども。新しいもの始めないと頭が退化する。。。ということで、こちら（ happy new year and new language - katsyoshiのめもみたいなもの）のブログに触発されて、言語処理100本ノックをはじめてみました。\n言語処理100本ノックとは、自然言語処理になるのかな、東北大学の研究室の先生が公開している言語処理に関する実践的な課題をベースにプログラミングなどのスキルを学んでいくための問題集です。 元々はPythonを対象とされているようですが、Rustでやってみようかと。 まぁ、先ほどあげたブログの二番煎じです。。。 ちなみに、インスパイアされた元のブログの方はRust book 2nd editionを読み終えたらしいですが、私はかじった程度です（ダメかも？）。\nNLPもRustもかじった程度なので、苦戦しそうですが、ちょっとずつやっていこうかなと。 ということで、準備運動の第1章から始めようかと。 GitHubにちょっとずつあげていく予定です。 https://github.com/johtani/nlp100-rust\nまぁ、まずは宣言のブログを書いてみただけです。 続いてなかったら、叱咤激励してください。叱咤だけかも？\n","date":1518605551,"dir":"post/2018/","id":"a673b3829e62477e01abc75465416b86","lang":"ja","lastmod":1518605551,"permalink":"https://blog.johtani.info/blog/2018/02/14/start-nlp100-with-rust/","publishdate":"2018-02-14T19:52:31+09:00","summary":"ども。新しいもの始めないと頭が退化する。。。ということで、こちら（ happy new year and new language - katsyoshiのめもみたいなもの）のブログに触発されて、","tags":["Rust","nlp100"],"title":"言語処理100本ノックはじめました(Rust)"},{"contents":"第1回では、Analyze UIというプラグインの紹介をしました、ごく簡単にですが。\n第2回では、Kibanaのプラグインの作成方法を順を追って見ていこうと思います。今回は、プラグインのプロジェクトの作り方を説明します。 どんなファイルがあるのかなどについては第3回で説明します（2018/02月現在の方法になります。残念ながら、Kibanaのプラグイン作成自体はまだExperimentalな話になっていますので、変更がある可能性があります）。\n実はそれほど難しいというわけではありません。Kibanaのプラグインを作成するためのテンプレートが用意されています。template-kiban-pluginです。 テンプレートのリポジトリのREADMEに作業手順の記載があります。\nKibanaのリポジトリをClone、Checkout Node.jsの環境を用意する Kibanaを起動できるようにする SAOのインストール テンプレートによるプロジェクトファイルの生成 順を追って説明します。 PLUGIN_DEV_DIRというディレクトリ配下で作業をしている想定になります。\n1. KibanaのリポジトリをClone、Checkout 開発環境として、Kibanaが必要です。Kibanaのプラグインを作るので。 手順などはKibanaのCONTRIBUTING.mdに記載があります。 ということで、まずはKibanaのリポジトリをCloneします。\ncd PLUGIN_DEV_DIR git clone git@github.com:elastic/kibana.git このままだと、masterブランチなので、開発したい対象のKibanaのバージョンのブランチもしくはタグをcloneします。今回は6.2.1向けということで、次のようになります。\ngit checkout v6.2.1 これで、ソースが6.2.1向けになりました。\n2. Node.jsの環境を用意する Node.jsをインストールします。 Kibanaのリポジトリに.node-versionというファイルがあります。 こちらにNode.jsのバージョンが記載されています。 Kibanaが使用しているNode.jsを利用できるようにします。ローカルではnvm利用してインストールしました。後から、切り替えが可能だからです。 nvm自体のインストールについてはnvmのサイトをご覧ください。 nvmがインストールできたら、次のコマンドで、Kibanaが使用しているバージョンをインストールします。\ncd kibana nvm install \u0026#34;$(cat .node-version)\u0026#34; すでにnvmを利用している場合などは、Kibana起動時にKibanaのバージョンに合わせたNode.jsに切り替えるようにしてください。\n3. Kibanaを起動できるようにする Kibanaではyarnというjavascript向けのパッケージマネージャーを利用して起動やビルドなどを行います。まずはyarnをインストールします。最近npmからyarnに切り替えたようです。 私はMacだったので、brewでインストールしました。 インストールできたら、次のコマンドを実行します。\nyarn これにより、package.jsonから必要なライブラリなどをダウンロードして来てくれます。 問題なければ「✨ Done in 439.30s.」というような表示がされます（結構時間かかりますね）。 では、Kibanaを起動できるか確認してみましょう。 さらに、Elasticsearchも起動してみます。 Kibanaのpackage.jsonの中にはElasticsearchを起動するためのスクリプトも用意されています。実際にはgruntを利用してタスクを実行しているようです。Elasticsearchの起動にはJavaが必要になります。 今回は6.2.1なので、JDK 8以降がインストールされている必要があります。 こちらはインストールされているものとします。\nyarn elasticsearch で起動できます。\n\u0026gt;\u0026gt; Started 1 Elasticsearch nodes. という表示が出てればOKです。 次にKibanaです。別のTerminalを起動して、以下のコマンドで起動できます。\nyarn start これだけです。\nserver log [06:58:56.930] [info][listening] Server running at http://localhost:5603 この辺りが出てればKibanaのServerは起動済みです。また、Elasticsearchに接続できていれば、次のログが出ているはずです。\nserver log [07:02:18.010] [info][status][plugin:elasticsearch@6.2.1] Status changed from red to green - Ready Elasticsearch接続用のKibanaのプラグインの状態になります。 これで、Kibanaの環境が整ったことが確認できました。 もちろん、Elasticsearchに関しては、yarnで起動せずに、tar.gzなどでダウンロードして来たElasticsearchを起動しておき、アクセスするといったことも可能です。プラグインなどをElasticsearchにもいれてテストしたい場合などはそちらの方が便利かもしれません。\n4. SAOのインストール では、一度、ElasticsearchとKibanaを停止しましょう。フォワグラウンドで起動しているので、それぞれのTerminalでCtrl+Cで停止できます。 Kibanaのプラグイン作成むけに、テンプレートが作られています。sao.jsというGitHubのリポジトリやnpmのパッケージをテンプレートとして使うことができるツールを利用してプラグインのプロジェクト（リポジトリ）を作成します。 実際にテンプレートとなるリポジトリはtemplate-kibana-pluginになります。 まずはSaoのインストールです。\nnpm install -g sao プラグインのテンプレートのページには上記のようにnpmを利用したインストール方法になっていますが、次のようにyarnでも可能です。\nyarn global add sao これで、saoがインストールできました。\n5. テンプレートによるプロジェクトファイルの生成 あとは、テンプレートを元にプロジェクトを作成します。 PLUGIN_DEV_DIRディレクトリ配下に、kibanaと同じ階層で作成するプラグイン用のディレクトリを作成します。\nmkdir simple-sample-kibana-plugin 以下のような構成になります。\nkibana simple-sample-kibana-plugin 次にテンプレートを適用していきます。\ncd simple-sample-kibana-plugin sao kibana-plugin@7.2.4 2行目がsaoを利用してプロジェクトを作成しているコマンドになります。 すると、次のような質問が出て来ます。 これらに答えるとプロジェクトに必要なファイル（package.jsonやREADME.mdなど）に入力した情報を適用したものを作ってくれます。\n? Name of your plugin? ? Provide a short description ? What Kibana version are you targeting? ? Should an app component be generated? ? Should translation files be generated? ? Should an hack component be generated? ? Should a server API be generated? 実際に答えた内容はこちら。\n? Name of your plugin? simple-sample-kibana-plugin ? Provide a short description Sample plugin for explaining how to make kibana app ? What Kibana version are you targeting? 6.2.1 ? Should an app component be generated? Yes ? Should translation files be generated? Yes ? Should an hack component be generated? Yes ? Should a server API be generated? Yes プラグインの名前などは、ディレクトリ名と同じものを入力補完してくれているので、そのままEnterでもOKです。 Descriptionについてはわかりやすいものを入力しましょう。 バージョンは、先ほどのKibanaのリポジトリに合わせて、6.2.1にしてあります。 あとは、作るプラグインの種類に応じて、必要なコンポーネントを作るかどうかの質問にYes/Noで答えます。 今回はサンプルの説明ということもあるので、全てYesで答えました。 ちなみに、私が実際に作成したanalyze-api-ui-pluginでは、appとtranslationとserverの3つを作成しました。 ただし、translationについては現在はテンプレートで作成したままのファイルが入っており、実際には利用してないです。\n完了したら、プラグインのサンプル入りのプロジェクトが完成です。 もう一度、Elasticsearchを立ち上げて、プラグインのプロジェクトからKibanaを起動してアクセスしてみます。まずは、PLUGIN_DEV_DIR/kibanaディレクトリの下で、Elasticsearchを起動します。\nyarn elasticsearch 次に、PLUGIN_DEV_DIR/simple-sample-kibana-pluginディレクトリの下で、以下のコマンドを実行し、プラグインが入った状態のKibanaを起動します。\nyarn start 問題なく起動すれば、ブラウザでアクセスすると次のような画面が表示されるはずです。\n左側にメニューが1つ増えています。 クリックすると、上記画像のような画面が表示されるはずです。\nこれで、カスタムプラグインの開発ができる環境ができました！ 次回は、プロジェクトのディレクトリ構成や、どんなツールが内部で使用されてデータのやり取りが行われているかについて説明します。お楽しみに。\n","date":1518167857,"dir":"post/2018/","id":"7b6cb59a177abe9767fd22da5a03b1e6","lang":"ja","lastmod":1518167857,"permalink":"https://blog.johtani.info/blog/2018/02/09/getting-started-template-kibana-plugin/","publishdate":"2018-02-09T18:17:37+09:00","summary":"第1回では、Analyze UIというプラグインの紹介をしました、ごく簡単にですが。 第2回では、Kibanaのプラグインの作成方法を順を追って","tags":["Kibana","plugin"],"title":"Analyze UIとKibanaのプラグインの作成方法（第2回）"},{"contents":"あけましておめでとうございます。今年はサボりがちだったブログをちょっとずつ復活させようかと。 ということで、第1弾として、昨年少し作っていたKibanaのプラグインを何度かに分けて紹介したいと思います。\n今回はAnalyze UIというプラグインの紹介です。\n今回はインストール方法と簡単な機能紹介です。 細かな紹介は個別にやりたいと思います。\nAnalyze UI pluginとは？ Elasticsearchの_analyzeというAPI\u0002(個人的に好きなAPIです)をご存知でしょうか？\nElasticsearchは全文検索エンジンで、データの検索には転置インデックスというものを使用します。 Elasticsearchにデータを登録する際に、text型のデータの場合、この転置インデックスのキーとなる単語を決める処理のことをAnalysisと呼びます（Analysisの詳細については割愛します。後日説明するかも？）。 このAnalysisの処理が、入力されたデータの文字列に対してどのように行われて、結果としてどんな単語がキーとして用いられているかを確認できる機能が_analyze APIです。検索で単語がうまくヒットしないな？とか、なんで、こんなので検索結果に出てくるんだ？といった場合、このAPIを利用すると、どのような単語で転置インデックスが作られているかがわかるので、検索にヒットしない/する理由を見つけることができます。\nElasticsearchの便利な点はRESTfulなAPI＋JSONでやりとりができる点なのですが、_analyze APIの結果をJSONで受け取っても、見るのにちょっと苦労します。。。こんな感じ。\nリクエスト：\nPOST _analyze { \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;今年はブログをいっぱい書きますよ！\u0026#34; } レスポンス：\n{ \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;今年\u0026#34;, \u0026#34;start_offset\u0026#34;: 0, \u0026#34;end_offset\u0026#34;: 2, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;ブログ\u0026#34;, \u0026#34;start_offset\u0026#34;: 3, \u0026#34;end_offset\u0026#34;: 6, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 2 }, { \u0026#34;token\u0026#34;: \u0026#34;いっぱい\u0026#34;, \u0026#34;start_offset\u0026#34;: 7, \u0026#34;end_offset\u0026#34;: 11, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 4 }, { \u0026#34;token\u0026#34;: \u0026#34;書く\u0026#34;, \u0026#34;start_offset\u0026#34;: 11, \u0026#34;end_offset\u0026#34;: 13, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 5 } ] } このくらいの量であればまだなんとかなりますが、文章が長くなると辛いですよね。\nということで、GUIがあると便利だろうなぁと。で、作ってみましたというのが今日紹介するKibana用のAnalyze UIプラグインです。 こんな感じで、Kibanaのアプリの一部として動作しブラウザ上で、入力テキストの文字列がどのようにanalyzeされて、単語になるかがわかります。\n（先ほどのAPIのサンプルと同じものを画面で入力した結果になります）。\nインストール方法 現時点の最新版Kibana（6.1.2）に対応しています。 Kibanaのディレクトリでkibana-pluginコマンドを利用してインストールします。\n./bin/kibana-plugin install https://github.com/johtani/analyze-api-ui-plugin/releases/download/6.1.2/analyze-api-ui-plugin-6.1.2.zip これだけです。 で、Kibanaを起動していただくと、左のメニューに「Analyze UI」という項目が増えています。\nクリックすると、Analyze UIが表示されます。\n初期画面は入力された文字を特定のAnalyzerで処理した場合の結果を見るための画面です。綱目の説明は画像をご覧ください。\n先ほどのJSONよりは見やすくなったかと思います。 そのほかにもいくつか画面や機能があるのですが、今日はこの辺りで。 「_analyze API便利なんだけど、JSONは。。。」とか「検索うまくできないなぁなんでだろう？」と思っている方は、ぜひ試して見ていただければと。 問題点などありましたら、GitHubのIssueを登録してください。\n","date":1516343806,"dir":"post/2018/","id":"4afcb20d4d95bcd1bde3aa6b7f552660","lang":"ja","lastmod":1516343806,"permalink":"https://blog.johtani.info/blog/2018/01/19/how-to-make-kibana-plugin-example-analysis-ui/","publishdate":"2018-01-19T15:36:46+09:00","summary":"あけましておめでとうございます。今年はサボりがちだったブログをちょっとずつ復活させようかと。 ということで、第1弾として、昨年少し作っていたK","tags":["Kibana","plugin"],"title":"Analyze UIとKibanaのプラグインの作成方法（第1回）"},{"contents":"今年は紅白を見ながら書いてます。 今年はいろんなところに出張に行ったなぁ。\n振り返り（2016年に書いた抱負から） まずは去年の抱負を元に。\nもちろん英語の継続 もちろん継続してます。英会話しながら海外TVドラマや映画を見てます。 ちょっとずつ英語字幕でも見ようとしてますが、まだまだだなぁ。 あと、TOEICを受けてないんで、それは受けないと。 見たドラマはこの辺です。\nER ウォーキング・デッド Agent of Shield SUITS Mr.Robot(いまいち話の展開についていけなかった) 継続的にイベントに登壇 OSCに今年もブース出してセッション持ってました。 勉強会ももちろんやりました。 あと、外部のカンファレンス（FOSS4G、BigData Analytics、db tech showcaseなど）や 勉強会(monitoring勉強会やCA.ioなど)にも登壇させていただきました。 もっと外部から読んでいただいたり、CfPに応募して通過できるようにしないとなぁ。\nもっと開発＆ブログ ブログはすみません。。。来年頑張ります。。。 ブログの代わりに書籍を出せました。データ分析基盤系の書籍になるので、興味のある方はのぞいて見ていただければ。\n開発はちょっとやってます。今年後半はKibanaのプラグインとかをちょっと書いてました。 Ingest-CSVもちょこちょこバージョンアップに追従してたりします。\nサポートエンジニア獲得！ 獲得しました！（自分の成果かどうかはわかりませんが。。。） 今は3名体制でサポートしてもらってます。おかげさまでだいぶサポートする機会が減ってきました。 開発は世界各地どこでも募集中だったりしますので、ぜひ連絡いただければと。\n個人的な検索勉強会の再開 再開しました。検索エンジン自作入門を知人と隔週くらいで読んでます。読んでるだけではあれなんで、実装もしてたり。全然違う言語でトライして見ようと思ったのでRustで書き始めてます。まずは、単純なところからと思ったんですが、 Rustの書き方の違いにだいぶ戸惑ってます。。。\n振り返り(今年あったできごと) ここからは今年の出来事を。\n初アメリカで釣り Nintendo Switch! 初Japanチームオフサイト チーム変更 初Berlin Buzzword! 母校（大学）訪問 Kibanaプラグイン開発 今年も初モノがちらほらとありますね。 今年もカレンダー振り返ってたら「え？これ今年だったの？」ってのがちらほらありました。。。\nアメリカで釣りやりました。自社のカンファレンスElastic{ON}のあとに、エンジニアが集まるミーティングがあるんですが、そこで1日Fun Dayがあって、そこで釣りをやりました。 魚群探知機とかで魚探すんですね、最近のは。2、3匹釣ったので非常に楽しかったです。 来年はスノーシューにチャレンジする予定。\nNintendo Switch買って、ゼルダやりました。今はイカやってます。 イカ欲はちょっと減ってるかもなぁ、1に比べると。 あとは、子供に買ったマリオやったりしてるかな。\nここ10年くらい行きたいと思っていたカンファレンス、Berlin Buzzwordに行ってきました！ これが今年一番嬉しかった出来事です。Luceneコミッターの方々にも会えたし。特にPoliceman JenkinsのUweさんに会えたのが本当に感激でした。。。 来年も行けるといいなぁ。。。\n今年も出張が多めだったのであちこち飛び回ってたなぁ。 そんな飛び回っている中で、故郷である広島（出身地？）に出張で行ったので、母校に顔を出してきました。 変わってなかった。。。自分が一期生なので、自分が入学した時はまだクレーンとか立ってるような新校舎だったんだけど、それが20年くらい経て、だいぶ古くなってました。。。 広島市内は港近くに高速道路とか出ててだいぶ様変わりしてました。 ただ、小学校も高校も変わってなかったなぁ。久々に高校の同級生にも会えたし。 また、機会があればぜひ行きたいなと。帰省する場所ではなくなったので、行く機会がないんですよね。。。\n開発もちょっとやってます。Kibanaのプラグインに挑戦して見てます。 いまだにJavaScriptは苦手なんですが。。。 ちょっとずつ改良して、ひょっとすると本体とかに取り込めるかな？ あとは、今年始めたRustをちょっとずつ継続して行きたいなと。\n来年の抱負 最後は来年の抱負を。\nもっと英語の継続＆TOEIC 継続的にイベントに登壇 CfPもっと出すぞ！ もっとブログ！ 雑誌やWeb系雑誌で記事を。 コミュニティを別の方法で盛り上げ Elasticsearchなど検索系の開発にも参加 英語はもちろんですね。今年は12月の自社イベントに合わせて多くのAPJチームの人が来て、 チームで会話できたし、もっと英語やらないとなぁと。前よりもちょっとは喋れるようになった気がしてます（気がしてるだけで、喋れてるかどうかは不明）。あとは、TOEIC受けて、実力チェックしてみないとなぁ。\nイベント登壇はまぁ、DevRelですから、一応。 来年もとりあえず、3月までは毎月どこかでブース出してます。 Ask Me Anything的なブースの出し方を今年はしてみようかなと思ってるので、 ちょっと使い始めたけど、この辺よくわからないと思ってる方、ぜひ質問しに来てください。 ブース出すだけじゃなくて、スピーカーとしていろんな場所で喋れるようにしないとなぁと。 もっと幅広く知ってもらえるように雑誌とかで連載できるようにしたいなぁと思ってます。 また、日本語の入り口の情報を増やすためにブログも書かないとなぁ。\n勉強会も継続しますが、別の方法でも盛り上げて行きたいなぁと。 勉強会はどうしても聞く人が多くて、ユーザーの間での交流や情報交換とまでは行ってない気がするし、discuss.elastic.coというフォーラムで質問は増えて来てるけど、もう少し交流しやすい場があると使ってもらえるかなぁ？と思っていたり。 何かおすすめとかあれば、連絡ください。 meetup.comの勉強会のページにも掲示板はついてるんだけど交流しにくそうだし。\n来年は自分が最も興味のある検索系の開発にも参加したいなぁと。 Elasticsearchをちょっとずつ時間見つけてやってたりはしますが、もう少し首を突っ込んで行きたいなぁと。Swiftypeもジョインしたし。もっと検索やって行きたい気持ちが強いので。\nさて、ということで、今年もあと1時間なくなりました。 今年も様々な面で色々な方々に助けていただけました。本当にお世話になりました。 この場を借りてお礼申し上げます。\n来年ももちろん、色々な方に助けてもらうと思いますが、よろしくお願いいたします！\n","date":1514723443,"dir":"post/2017/","id":"7c21b70f9e9c782c1f5153268e0cc1c1","lang":"ja","lastmod":1514723443,"permalink":"https://blog.johtani.info/blog/2017/12/31/looking-back-2017/","publishdate":"2017-12-31T21:30:43+09:00","summary":"今年は紅白を見ながら書いてます。 今年はいろんなところに出張に行ったなぁ。 振り返り（2016年に書いた抱負から） まずは去年の抱負を元に。 もちろ","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2017）"},{"contents":"Merry Christmas! Elastic Stack Advent Calendar 2017の24日目の記事になります。\nちょっとですが、2018年のElasticについて書いてみようかと思います。\nイベント いくつか出展が決まっているイベントがあるのでまずは宣伝を。\nOSC Osaka 2018 まずは、1月25日、26日にOSC Osaka 2018に出展し、話をします。参加者がいそうであれば、25日や26日の夜に勉強会もありかなぁと思っています。 セッションでは入門的な話をする予定です。ブースにいますので、色々質問がある関西の方はぜひご参加ください。\nDeveloper Summit 2018 2月15日、16日はDeveloper Summit 2018に出展します。 こちらでもブースにいますので、AMA（Ask Me Anything）的に使っていただくのもいいかなと。 デブサミに参加される方はぜひお立ち寄りください。\nManabiya 3月23日、24日はManabiyaに出展します。 こちらでもAMAのつもりでブースを出す予定です。質問がある方はぜひお立ち寄りください。 こちらのイベントは初めての開催になるようなので、どんなイベントになるか楽しみにしています。\nイベント回りはこの辺りで。 また、1月末に勉強会を予定しています。決まり次第またMeetup.comの方々にメールを出す予定です。\nElastic Stackの2018年は？ Canvas! 昨年のElastic{ON}でみなさんをCanvasがリリースされるかなぁと。 現在、みなさんにテストしてもらえるようにcanvas.elastic.coというサイトを公開中で、実際にインストールして試すことができるようになっています。 ぜひ、触って、全く新しいUIを体験して見てください。\nSQL? こちらも昨年のElastic{ON}でみなさんから反響があったものです。 もう直ぐでてくるのではないかなぁと。\nその他は？ いくつか面白そうで、取り込み済みのものをピックアップしておきます。\nAdd ranking evaluation API 検索クエリなどに対して検索結果のランクのクオリティを評価するためのAPIの追加（7.0予定） JDK9サポート？ 6.2でサポートされそうです。が、LTSのJDK8が推奨のままの予定です。 High-level REST ClientでいくつかAPIが追加 https://github.com/elastic/elasticsearch/pull/27574、https://github.com/elastic/elasticsearch/pull/27351 APM正式リリース？ ベータ版がリリースされているので、秒読み段階？ ということで より詳しく知りたい方は、サンフランシスコで開催されるElastic{ON} 2018に参加するのが一番です！（ステマ） 私も参加予定ですので、ぜひ、現地でお会いし、色々な情報をゲットしましょう。\n明日で、今年のAdvent Calendarも最後です。micci184さんの記事を楽しみにしましょう！\n","date":1514124616,"dir":"post/2017/","id":"f3a9b931b7f552a4f9dfa61ce4f39f0e","lang":"ja","lastmod":1514124616,"permalink":"https://blog.johtani.info/blog/2017/12/24/elastic-2018/","publishdate":"2017-12-24T23:10:16+09:00","summary":"Merry Christmas! Elastic Stack Advent Calendar 2017の24日目の記事になります。 ちょっとですが、2018年のElasticについて書いてみようかと思います。 イベント いくつか","tags":["elasticsearch"],"title":"2018年のElasticは？"},{"contents":"Elastic stack (Elasticsearch) Advent Calendar 2017の1日目の記事になります。\nまだ、1ヶ月を残していますが、簡単に今年起こったことを振り返ってみようかと思います。思った以上に色々ありましたね。。。\nElastic Stack 5.2.0リリース (1月) リリース記事はこちら\nHeatmapがKibanaで追加されたり、Heartbeatがベータですが追加されました。 個人的には、Terms aggregationのFiltering Valuesによるパーティションが便利になったと思います。Terms Aggsでページングに似たことができるようになりました。\nElastic{ON}17開催 (3月) 第3回目のユーザカンファレンスが開催されました。 バレーダンサーの踊りから始まったキーノート、様々なユーザ企業によるユースケース発表などいろいろありました。 セッションはこちらのサイトからから録画を見ることができます。 SQL for ElasticsearchやAwardが目を引いたと思います。SQL対応まだ出てきていないですが、もうすぐじゃないかと！\nElastic Stack 5.3.0リリース (3月) リリース記事はこちら\nFilebeat moduleが導入され、ログファイルを取り込んでKibanaで可視化するまでの手順がより簡単になりました。Elasticの目指しているものの一つに、シンプルな使い方、簡単にはじめられることといったものがあります。KibanaのTimepickerもより便利になったのも、このバージョンからです。\nShayがCEOに (5月) 2月にすでに発表されていましたが、Elasticsearchの生みの親のShay BanonがCEOに正式に就任しました。CEOになってさらに、精力的に様々なことをやっていて、本当にすごいなと思います。\nElastic Stack 5.4.0、6.0.0-alpha1リリース (5月) 5.4.0リリース記事はこちら、6.0.0-alpha1リリース記事はこちら\n5.4.0は節目になるリリースでした。Machine Learningがベータリリースとして、X-Packに追加されましたし、ElasticsearchではCross Cluster Searchの改善が進みました。LogstashではPersistent QueueがGAになりましたし、KibanaにはTime Series Visual BuilderやEvent Contextなどが追加されますます使いやすくなりました。\nまた、6.0.0のalpha版も同時にリリースされ、様々な方からのフィードバックが集まり始めました。\nElastic Cloud Enterprise GAリリース (5月) Elastic Cloudのバックエンドの技術を製品に採用したものになります。 多くのElasticsearchクラスタを管理しないといけない方には朗報でした。\nOpbeatがJoin (6月) Opbeatチームがジョインしたのが6月です。Elastic StackがAPM\u0002(Application Performance Monitoring)でも活躍することになりそうです。APMの仕組みとしては、APM Agentをアプリ側に配置し、APM Serverへデータを送信し、Elasticsearchに保存、Kibanaで可視化するという流れになります。\nElastic Stack 5.5.0リリース (7月) リリース記事はこちら\nMachime LearningがGAリリースになったのが5.5.0です。色々な方から質問を受けました。それ以外にも、ElasticsearchのWindows MSI InstallerやKibanaのFilter editorなどが追加されました。Filter editorはこれまで検索条件を記述するのが難しいと感じていたKibanaユーザにとても喜んでもらえたものじゃないかなと。 GrokDebuggerが導入されたのもこのタイミングです。\nElastic Stack 5.6.0リリース (9月) リリース記事はこちら\n5系最後のマイナーリリースであり、6へのアップグレードが楽になる様々な仕組みが用意されたのがこのバージョンです。ElasticsearchのJava High level REST clientが導入されたのもこのバージョンです。本当に様々な機能が次のメジャーバージョンとの互換性のために組み込まれています。。。\nElastic Cloud on GCP (9月) リリース記事はこちら\nこれまで、AWS上のみで展開していたElastic CloudがGCP上でも展開されることになりました。残念ながら、日本リージョンはまだありませんが、問い合わせなどが増えれば今後サポートされる可能性が高くなると思います！\nElastic APM alpha (9月) リリース記事はこちら\nOpbeatチームによりElastic StackのAPMがAlphaですがリリースされました。APMがOpen Sourceで利用できるんです！Agentがもっと増えてくると色々なことに使えるようになると思います。ぜひAgentを作成してみてください！\nElastic Stack 6.0.0リリース (11月) リリース記事はこちら\n待ちに待った6.0.0のリリースです。新機能については本日(12/1)の昼に行われるウェビナーをご覧ください！\nSwiftypeがJoin (11月) ニュースリリースはこちら\nSwiftypeと呼ばれる検索のSaaSを提供している会社がジョインしました。 個人的には今年一番嬉しいニュースです。やはり、検索が好きなので。 簡単にSite Searchを構築できる仕組みは非常に面白いものです。 興味のある方は、ぜひ触ってみてください。日本語固有の機能などはまだないので、今後関わっていければなーと。\nElastic{ON} Tour Tokyo開催 (12月) まだ開催前ですが、今年も東京で1dayイベントを開催します。 残念ながら、もうSold outなので、キャンセル待ちになってしまっているみたいですが。私もスピーカーとして喋りますし、AMAブースにも立っています。 参加される方はぜひ声をかけていただければと思います。\nOSC 2017.Enterprise (12月) オープンソースカンファレンスで今年も様々な都市に出張しました。 今年の締めくくりということで、12/8に渋谷で開催されるカンファレンスに出展します。時間のある方は、ぜひブースに遊びに来てください。入門者向けのセッションもあるので、こちらもお待ちしております。\nまとめ 超駆け足ですが、今年を振り返ってみました。 今年もいろんなことがありました。書くのが大変だったw。 OSCなどイベントで声をかけていただいた皆様、ありがとうございました。\nさて、Elastic Stack Advent Calendar 2017は始まったばかりです。これからの記事を楽しみにしています！\nということで、 次はaeroastroさんの「Elasticsearchのインデックスを本当の意味で無停止再構築する方法」（Advent Calendarのページはこちら）になります、お楽しみに！\n","date":1512054000,"dir":"post/2017/","id":"fa0486610d8a02cea245c13c85b6de27","lang":"ja","lastmod":1512054000,"permalink":"https://blog.johtani.info/blog/2017/12/01/whats-happen-at-elastic-in-2017/","publishdate":"2017-12-01T00:00:00+09:00","summary":"Elastic stack (Elasticsearch) Advent Calendar 2017の1日目の記事になります。 まだ、1ヶ月を残していますが、簡単に今年起こったことを振り返ってみようかと思います。思った以上に","tags":["elasticsearch"],"title":"2017年のElastic StackとElastic"},{"contents":"Swiftypeでサイト内検索？ プレスリリース：Elasticがサイト内検索サービス最大手のSwiftypeを買収が出ましたが、SwiftypeチームがElasticにジョインしました！\n自分のブログ検索に導入してみる？ SwiftypeはSite Searchをサービスとして提供しています。 実際に指定したサイトのデータをクロールして、インデキシングし、検索できるようになります。 ものは試しということで、自分のブログを登録してみました。検索窓はつけてないですが。 14日間のFree trialがあるのでそちらで試してみましょう。 検索窓はデモとか作れたらかな。\nということで、Free trialへ まずはユーザ登録です。Googleのアカウントと連携するか、Swiftypeにメルアドを登録するかが選択できます。 登録できたら、次にどちらのプロダクトを使うかという選択画面が出てきます。 今回はサイト検索して見たいので、「Site Search」の「START FREE TRIAL」をクリックします。\nEngineの指定 Web Crawlerを利用するか、独自にSwiftypeのAPIを利用してデータを登録するかを選択します。\n今回は、お手軽な方のCrawlerを選択します。 すると次に、クロールしたいURLの指定画面が出てきます。\n今回は自分のブログなので、\u0026lsquo;http://blog.johtani.info\u0026rsquo;を指定します。\nで少し待つと、URLのチェック（存在チェックとか、接続チェックとか）が終わり、今回作成するEngineに名前をつける画面が出てきます。 「My Blog search」という名前にしてみました。\nsitemapがあるかどうかをCrawlerがチェックしています。 私のBlogはOctopressでできていて、sitemap.xmlも作ってくれているので、これを元にCrawlerはクロールをしてくれます。そのほかにもRSSやAtomサポートもあるみたいですね。 「COMPLETE SETUP」を押すと、Engineの管理画面が出てきます。\n「CRAWLING」という表示が出ています。クロールしている最中です。これが終われば、「PREVIEW」に代わり、検索できる準備ができたことになります。 実際にPREVIEWして見ると、次のような検索ができるようになります。\nそのほかにはWeightの調整画面などもありますね。フィールド毎に重み付けを変えて見たりもできます。\n日本語独自のAnalyzerなどはまだないので、そのあたりができてくるともっと便利になりそうです。 とりあえず、気になる方は触って見てはいかがでしょうか？ 個人的は検索に関するサービスが出てきたのですごく楽しみにしています！\n","date":1510280089,"dir":"post/2017/","id":"c20d71627e66a044b21780f56f2f9504","lang":"ja","lastmod":1510280089,"permalink":"https://blog.johtani.info/blog/2017/11/10/welcome-swiftype/","publishdate":"2017-11-10T11:14:49+09:00","summary":"Swiftypeでサイト内検索？ プレスリリース：Elasticがサイト内検索サービス最大手のSwiftypeを買収が出ましたが、Swifty","tags":null,"title":"Swiftypeがジョインしたので触ってみました"},{"contents":"久々に執筆しました。といっても、以前の書籍の更新版です。 まぁ、更新版といっても、私以外の方々は結構な量を書き直しor新規書き起こしされてますが。。。\nということで、みなさん「買って」から感想をいただけるとうれしいです！\u0002（以下の画像でAmazonにジャンプできます！Kindle版も発売中です。）\n今回もElasticsearchの章を担当しました。 5.4ベースで書きましたが、ちょっとずつ6でどう変わるかなども記載してあります。 また、付録ではLogstashやBeatsにもちょっと触れています。 また、自分が一番好きなKibanaの機能であるDev ToolsのConsoleについても記載してあります。こちらも合わせて目を通していただければと。\nみなさんのフィードバック（ツイート、ブログ、Amazonのコメントなどなど）をお待ちしております！\n","date":1505955750,"dir":"post/2017/","id":"4f88f3eebe44285ded812939553ef94c","lang":"ja","lastmod":1505955750,"permalink":"https://blog.johtani.info/blog/2017/09/21/release-intro-logging-analysis-system/","publishdate":"2017-09-21T10:02:30+09:00","summary":"久々に執筆しました。といっても、以前の書籍の更新版です。 まぁ、更新版といっても、私以外の方々は結構な量を書き直しor新規書き起こしされてます","tags":["elasticsearch","kibana","本"],"title":"データ分析基盤構築入門 を一部執筆しました。"},{"contents":"久々のブログ。 Elasticsearch勉強会を主催してますが、 プロダクトを超えて、検索で共通してある課題とか、悩みとか、あるかなぁと。 その辺りを話す場所を考えてみるのいいかもと思い、検索座談会ってのを5人でやってみた。\nとりあえず、初めてなので、5名ほどで。プロダクトはかぶってない感じでした。\n話した議題はこの辺り。 形態素解析の辞書は何を使ってる？有償のもの？ そもそも形態素解析？ 辞書の更新とかは？ シノニムってどうしてる？ サジェストとかのデータはどう作ってる？どうしてる？ 検索ログとかから作ってる？ 検索結果のランキングって検索結果だけで決めるの？ 検索漏れとかキーワードのミスマッチとかどうしてる？ 今後話したい内容はこの辺かな？ 緯度経度系の検索 画像検索、音声検索 検索のキーワードの調査とかしてる人とかいるかな？ どんな機能が欲しい？ 前処理としてはどんなことをしてる？ このあとどうしていくかはまだ考え中。知り合いを捕まえて、どんなことしてるかを聞きにいくのもいいし、議題みたいなことを決めて、それを話してくれそうな人にコンタクトして議論するのもありかなぁ。 普通の勉強会みたいなのにするかもしれないし。 とりあえず、どのくらい興味を持ってる人がいるのかがわからないので。。。\nもちろん、Elasticsearch勉強会は別でやっていきますよ。\n","date":1495639453,"dir":"post/2017/","id":"29b4c2b5adcd80ced1612128b3ca95a9","lang":"ja","lastmod":1495639453,"permalink":"https://blog.johtani.info/blog/2017/05/25/search-meetup/","publishdate":"2017-05-25T00:24:13+09:00","summary":"久々のブログ。 Elasticsearch勉強会を主催してますが、 プロダクトを超えて、検索で共通してある課題とか、悩みとか、あるかなぁと。 その","tags":["勉強会"],"title":"検索座談会ってのをやってみた"},{"contents":"今年はRioのプレイバック\u000e見ながら書いてます。 今年はなんか長い一年だった気が。\n振り返り（2015年に書いた抱負から） まずは去年の抱負を元に。\n英語の継続 継続してます。まぁ当たり前ですが。もう少し話す機会増やさないとだなぁと思いつつ。英会話しながら、海外TVドラマ見ながら。 見たドラマはこの辺かな？\nER SUITS メンタリスト Numb3rs エレメンタリー Agent of Shield あと、映画も見てます。とりあえず、耳を慣らすために字幕ありで見てるので、 英語だけでとは行きませんが。。。 そろそろ同じ映画を英語字幕で見るとかしたほうがいいのかもなぁ。\nもっとElasticsearchの開発に参加 一応参加してます。ちょっとずつですが。 イベントが重なるとできなくなるので、小さなPRとかを細々とって感じですが。。。\n人員の倍増？ 倍増したかな？現時点で日本は8名になりました。そのうち1人は完全リモートです。 来年も倍増とは行かないだろうなぁ。取り急ぎ、サポートエンジニアが足りてないのでそこを埋めないと。。。\n日本語情報発信 これはちょっと足踏みしてるかも。ブログの翻訳とかはやってるんですが、もう少しなんとかしないとなぁ。ブログも書かないと。。。\nSplatoon S+? なりました！とりあえずS+とSを行ったり来たりしてる感じです。 メインはノヴァネオですが、Sに落ちたら違う武器でS+に上がるまでチャレンジするってのをやってます。わかば、バケスロソーダ、プライム、ワサビくらいはやったかな？ そろそろまた違う武器かなぁ。S+99は無理そうなんで。。。\n振り返り(今年あったできごと) その他の今年の出来事。\n初香港 初プラハ OSCなど、東京以外でのカンファレンス参加 厄年 東京オフィス！ BBLとかトレーニング lucene-gosenをちょっとメンテ Podcastデビュー？ 初モノ今年も多いかな。 今年は、昨年よりは長く感じた一年でした。 月1くらいで出張してたのもあるのかなぁ？ 香港、プラハはもちろん会社のイベントです。 香港はジャッキーチェンの映画を彷彿とさせるところがちょくちょくあって面白かったです。 ビルとかの補修の足場が竹竿とか。 プラハも面白かったです。やっぱりヨーロッパの古い町は歴史のある建物が多くて楽しいです。\nOSCなどのイベントも色々行きました。福岡、名古屋、大阪、京都、札幌と回りました。 それとは別に大阪、福岡も行ったかな。 来年は沖縄と広島に行きたいなぁ。。。 出張のついで？じゃないですが、御朱印集めし始めました。神社仏閣もいいですよねぇ。\n厄年はきつかった。。。たまたまだとは思うけど、お祓いに行ったのが効いたのかなぁ。後半は特に問題なかったかな。腕時計無くしたと思ったら見つかったりしたし。\n弊社東京オフィスができました。（あんまり行ってないけど） ときどきアクロクエストさんがセミナーを開いたりしてます。 昨年のTour Tokyo後のMeetupでもイベントスペースを使って、Drinkup（勉強会の懇親会だけバージョン）もやりました。 今後もちょこちょことイベントをやってみようかな？\nBBLも始めました。あまりきちんと宣伝してないからそれほど依頼は来てないですが。 あとは、今年も2回日本語でトレーニングしました。 前回はほぼ満席にまでなりました。 来年も頑張りたいかな。ショートカットするためにもいいと思うんで、トレーニングを受けて欲しいんです。。。\nlucene-gosenのメンテもしました。 といってもプログラムではなく、ビルドシステムをAntからGradleに変更したんですが。 来年もちょっとずつ触りたいな。機能面で拡充するかはわからないですが。。。\nPodcastにもデビューさせていただきました。 wyukawaさんのPodcastです。「johtaniさんとElasticsearchについて話しました」楽しかったです。 また出たいなぁというか、喋るの面白かった！\n来年の抱負 もちろん英語の継続 継続的にイベントに登壇 もっと開発＆ブログ サポートエンジニア獲得！ 個人的な検索勉強会の再開 英語はまぁ、当たり前ですね。会社の人つかまえてもっと喋る時間増やさないとだな。\n来年もいろんなカンファレンスなどに出てブース出したり、セッション持ったりして もっともっと広めていかないとなぁ。 あとは、勉強会とMeetupもやっていかないと。入門編と上級編みたいに分けてみるのもありかなぁと考えて見たり。 スピーカー、ご意見募集しております。\n開発に時間をさくための時間の活用をしていかないとなぁと。 どうも時間の使い方がまだ上手くないので。ブログも一緒ですね。。。 月1くらいのペースではかきたいな。。。 ブログもそうだけど書籍もかな？？？？ あと、外資系の他の会社の人ともまた飲みたいなー。\n開発の時間を確保という面ではサポートエンジニアも募集中です。 最近、クライアントが増えて来てチケットが増えて来てるんで、サポートしたりもしてるんです。。。 自分の時間を増やすためにもサポートエンジニアを確保しないと。誰かいい人いないかなぁ。\n個人的にやってた勉強会を忙しいって言って中断してるので、再開しないと。。。\nということで、今年もあと數十分になってしまいました。 今年も色々な方に助けていただけました。お世話になりました。 この場を借りてお礼申し上げます。\n来年もいろんな方々に助けてもらうと思いますが、よろしくお願いいたします。\n","date":1483190534,"dir":"post/2016/","id":"16f1046144ad9ee7bb96214ba7ae7516","lang":"ja","lastmod":1483190534,"permalink":"https://blog.johtani.info/blog/2016/12/31/looking-back-2016/","publishdate":"2016-12-31T22:22:14+09:00","summary":"今年はRioのプレイバック\u000e見ながら書いてます。 今年はなんか長い一年だった気が。 振り返り（2015年に書いた抱負から） まずは去年の抱負を元に","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2016）"},{"contents":"Merry Christmas! Elastic stack Advent Calendar 2016 最終日の記事になります。\n簡単に今年の変遷を振り返ってみます。\nElasticsearch 2.2 (2月) Elasticsearch 2.2.0、2.1.2、1.7.5リリース クエリプロファイラやGeo系の性能改善などが取り込まれました。 また、同時期にリリースされたKibana 4.4ではColor pickerやShare用のURLの短縮化機能なども追加されました。\n第2回目のユーザカンファレンス、Elastic{ON}開催（2月） サンフランシスコで、弊社第2回目のカンファレンスが開催されました。 2015年の会場よりも大きくなり、多数の方に参加いただきました。 ここで、以下の発表がありました。\nElastic StackとX-Packの紹介 これまで、ELK stackと呼ばれて意味明日が、Beatsチームの参加により、ELKだけではなくなったこともあり、Elastic Stackと呼び名を変える事になりました。 また、Marvel、Shield、Watcherなどの商用の拡張機能についても、 単体の名称ではなく、X（Extension）-Packと1つの名前になる事に。 詳細については公式のブログをご覧ください。\nElastic CloudとElastic Cloud Enterpriseの発表 2015年にElasticにジョインし、 これまでFound.no（Found）と呼ばれていた弊社のElasticsearch as a ServiceがElastic Cloudと名称変更しました。 また、Elastic Cloudで培っているノウハウを詰め込んだElastic Cloud Enterpriseも発表しました。実際に利用可能になるまでには まだもう少しかかってしまいますが、アルファ版が公開されていますので、興味のある方は触ってみてください。\nElastic{ON}2016で撮影された、「Elasticsearchがないあなたの人生はどうなりますか？」 といった面白い動画も公開されています。\nElasticsearch 2.3リリース（3月） Elasticsearch 2.3.0および2.2.2をリリース Reindex APIが登場し、Mappingの変更やShard数の変更など、色々とデータの更新などがやりやすくなりました。 また、Task Managementの機能も追加され、長時間かかる処理を間違った場合などの対処が楽になりました。 個人的には、Deprecation Loggingの機能が導入されたことが嬉しいこととなります。次期メジャーバージョンで廃止される機能についてログに出力されるようになりました。 実際に運用されているアプリで利用している機能が今後なくなるかどうかをログを見るとわかるという仕組みです。\nRally登場（4月） Rally登場：Elasticsearchのベンチマークツール Elasticsearchのベンチマークツールがリリースされました。 定期的にElasticsearchの性能を計測することは問題点を見つける事に役に立ちます。そういった手助けをしてくれるツールが公開されることは非常に便利なことかと。\nElastic Stack 5 alpha1 リリース（4月） Elastic Stack 5.0.0 alpha 1 リリース Ingest NodeやLucene 6、新しいKibanaのUIなど多くのものが詰まっていました。ここから多くのユーザにテストしてもらい、5.0の正式リリースを迎えることができました。\nElasticsearch 2.4.0リリース（8月） 2.xの最後のマイナーバージョンリリースです。 Reportingなどの追加とドットつきフィールド名の復活がありました。\nElastic Stack 5.0.0 beta1 リリース（9月） Elastic Stack Release - 5.0.0-beta1 ついにベータです。Painlessがスクリプトのデフォルトになったり、TimelionがKibanaに取り込まれるなど、正式リリースまであと少し！\nPrelertチームジョイン（9月） Welcome Prelert to the Elastic Team Machine Learningエンジンを開発し、Elasticsearch,Kibanaとの組み合わせの製品をリリースしていたPrelertという会社がジョインしました。 Elasticsearchに保存された多くのデータをより活用していただくことができるかと思います。 Elastic{ON} Tour 2016 Tokyoで弊社SAの大輪の発表も人気があるものでした。まだベータ段階ですが、利用して見ることも可能です。 ビデオなどが公開されたらまたツイートしようと思います。\nElastic{ON} Tour Tokyo 2016開催（12月） 今年で2回目のTokyoローカルの1日イベントでした。 ブログは「まだ」書いてませんが、、、今回も盛りだくさんのイベントになりました。 早朝のトレーニング（ハンズオンではない）にも80名近くの方に参加していただけましたし、私はKibanaのキーノート＋デモという大役をもらいましたし、ちょっと大変でした。 今年もAMA（Ask Me Anything）ブースが大盛況でした。 色々な方から、弊社のサポート、開発者が色々な質問を受け、それに答えるという形です。楽しんでいただけたかと思います。 来年もぜひ開催したいなと思っています。\nまた、Elastic{ON}17のセッションもいくつか発表されています。 ぜひ、サンフランシスコで行われる本場のカンファレンスにもご参加ください！\n来年は？ 1月後半か2月にElasticsearch勉強会を検討しようと思っています。スピーカーに興味のある方は連絡いただければと。\n会社としては、Elastic{ON}2017が3月にまた開催されます。これで3回目となります。もちろん私も参加予定なので、参加される方は、現地で会いましょう！\nそのほかにもBIG DATA ANALYTICS TOKYOやオープンソースカンファレンス（大阪）、デブサミといったカンファレンスに参加（登壇・ブースなど）予定です。 参加される方は、ぜひブースまでお越しください。\nでは、また来年のAdvent Calendarでお会いしましょう！\n","date":1482591830,"dir":"post/2016/","id":"002d980d74d19b43ff4e2446665e2fe5","lang":"ja","lastmod":1482591830,"permalink":"https://blog.johtani.info/blog/2016/12/25/elasticsearch-6-features/","publishdate":"2016-12-25T00:03:50+09:00","summary":"Merry Christmas! Elastic stack Advent Calendar 2016 最終日の記事になります。 簡単に今年の変遷を振り返ってみます。 Elasticsearch 2.2 (2月) Elasticsearch 2.2.0、2.1.2、1.7.5リリース クエリプロ","tags":["elasticsearch"],"title":"2016年のElastic Stack"},{"contents":"Elastic stack Advent Calendar 1日目の記事になります。\nElasticsearch 5.0が10月末にリリースされました。 リリースのブログでいくつか紹介されているのですが、そこでは紹介されていない機能について2、3紹介しようと思います。\nその前に、5.0、あれ？その前は2.xじゃなかったっけ？？と困惑されている方もいるかと思うので、簡単に5となった経緯の紹介をしようかと。\nバージョン番号 なぜ2から5に飛んだのかという話ですが、このスライドがその紹介になっています。\nhttps://speakerdeck.com/johtani/elastic-stack-5-dot-0-alpha1-alpha5?slide=5\nElastic{ON} 2016のキーノートでも紹介がありましたが、KibanaやLogstashとElasticsearchを組み合わせて使うときにバージョンのミスマッチで動かないというユーザの声が上がっていました。 2.xのリリースから、同じ日にKibana、Logstash、Beatsもリリースするようになったのですが、 やはり、バージョン番号が異なるため、ミスマッチで動かないというユーザが時々いました。\nElastic Stackという名称にもなったため、バージョン番号をそろえようという事になり、 Elasticsearch、Kibana、Logstash、Beats全てが5.0.0としてリリースされ、 今後は同じバージョン番号になります。\nちなみに、「5」になった理由はKibanaのメジャーバージョンが「4」だったためです。\nさて、では、いくつか機能の紹介を。\nReindex from remote cluster Reindexが2.3から導入されました。データの再登録ができるようになり、マッピングの変更や Shardの数の変更などが柔軟に行えるようになりました。 便利でしたが、あくまでも同一のクラスタでデータを登録し直す形でした。\n5.0からはこの機能に加えて、異なるクラスタからデータを取得してReindexを行うことができるようになりました。 こんな形になります。\nPOST _reindex { \u0026#34;source\u0026#34;: { \u0026#34;remote\u0026#34;: { \u0026#34;host\u0026#34;: \u0026#34;http://otherhost:9200\u0026#34;, \u0026#34;username\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;password\u0026#34;: \u0026#34;pass\u0026#34; }, \u0026#34;index\u0026#34;: \u0026#34;source\u0026#34;, \u0026#34;query\u0026#34;: { \u0026#34;match\u0026#34;: { \u0026#34;test\u0026#34;: \u0026#34;data\u0026#34; } } }, \u0026#34;dest\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;dest\u0026#34; } } usernameとpasswordはリモートのクラスタに認証の気候が存在する場合に利用できるオプションです。 また、ReindexのAPIはクエリを使用して、必要なデータだけを取得することが可能です。 この機能により、1.xや2.xのクラスタからデータを移行することが可能になります。\nCustom analyzer test using Analyze API もう一つ、ちょっとだけ便利な機能を紹介します。 独自にAnalyzerを定義（TokenizerとToken Filterなどを個別に設定）して、その挙動を確認するとき、2.xまでは、インデックスを作成してそのインデックスに対して_analyze APIを呼び出す必要がありました。\n5.xからは_analyze APIの読み出しのパラメータで指定できるようになりました。 こんな感じです。ここでは、lowercaseフィルタのあとに、{...}でstopフィルタを パラメータの中で、指定しています。\ncurl -XGET \u0026#39;localhost:9200/_analyze\u0026#39; -d \u0026#39; { \u0026#34;tokenizer\u0026#34; : \u0026#34;whitespace\u0026#34;, \u0026#34;filter\u0026#34; : [\u0026#34;lowercase\u0026#34;, {\u0026#34;type\u0026#34;: \u0026#34;stop\u0026#34;, \u0026#34;stopwords\u0026#34;: [\u0026#34;a\u0026#34;, \u0026#34;is\u0026#34;, \u0026#34;this\u0026#34;]}], \u0026#34;text\u0026#34; : \u0026#34;this is a test\u0026#34; }\u0026#39; ちょっとだけですが、Analyzerなどを試すのが楽になるのではないでしょうか？\nということで、以上が1日目の記事でした。 Logstashなど、他の5.0.0に関する記事もAdvent Calendarに空きがあるようなので、個別にかこうかなと思います。お楽しみに！\n","date":1480581270,"dir":"post/2016/","id":"550becdd08d00fb1e7fd00c2adc3d3d6","lang":"ja","lastmod":1480581270,"permalink":"https://blog.johtani.info/blog/2016/12/01/elasticsearch-5-dot-0-highlight/","publishdate":"2016-12-01T17:34:30+09:00","summary":"Elastic stack Advent Calendar 1日目の記事になります。 Elasticsearch 5.0が10月末にリリースされました。 リリースのブログでいくつか紹介されているのですが、そこでは紹介されて","tags":["elasticsearch"],"title":"Elasticsearch 5.0の便利機能紹介？"},{"contents":"久しぶりに、技術的なブログ書いてます。\nIngest Processorのプラグインを作ってみたくなったので、書いてみました。 ただ書いてみるんじゃ3番煎じになりそうなので、cookiecutterを使ってみました。\nと言っても、同僚のAlexがcookiecutter-elasticsearch-ingest-processorと言うテンプレートを作ってくれているのを使っただけですが。（https://discuss.elastic.co に投稿された記事で、使い方がアニメgifで説明されててわかりやすいです）\ncookiecutterとは、コマンドラインで質問に答えると、テンプレートからプロジェクトが生成できるツールです。 Elasticでは、カスタムBeatを作る時に利用する例がいつかの日本語ブログや発表資料で話題になっていました。 これのIngest Processorのプラグインバージョンです。\n今回は、NEologdも使ってみたかったので、Lucene Kuromoji for NEologdを利用して 指定した品詞の単語だけを抽出するProcessorを作ってみました。\nGitHubのプロジェクト：https://github.com/johtani/elasticsearch-ingest-kuromoji-pos-extract\nCookiecutterの使い方 Cookiecutterのインストールはサイトをご覧ください。\ncookiecutter gh:spinscale/cookiecutter-elasticsearch-ingest-processor あとは、出てくる以下の項目を指定するだけです。\nprocessor_type : Ingest Processorのタイプ名です。kuromoji_part_of_speech_extractとしました。（Alexのだと_を使うとちょっと問題があるので後述） description : readme.mdに利用されます。 developer_name : 名前を記載。Javaのファイルのヘッダに利用 elasticsearch_version : デフォルトで5.0.0-alpha4が指定されているので、特に指定せず 以上の質問に答えたら、プロジェクトのディレクトリ構造が出来上がってます。 プロジェクトのビルドなどにはGradleを利用します。\nプロジェクトのIntelliJ IDEA用のファイルを生成 build.gradleファイルでGradleのideaプラグインがapplyされているので、以下のコマンドを叩けばIntelliJ IDEAのプロジェクトファイル（？）が生成され、IntelliJで開けばすぐに開発ができる状態にできます。\ngradle idea コーディング あとは、必要処理をコーディングします。 実際にコーディングするクラスはorg.elasticsearch.plugin.ingest.kuromoji_part_of_speech_extractのパッケージにある以下の2つです。（パッケージ名にはprocessor_typeの名前が指定されている）\nIngestKuromojiPartOfSpeechExtractPlugin KuromojiPartOfSpeechExtractProcessor IngestKuromojiPartOfSpeechExtractPlugin Pluginというクラスは、プラグインをNodeのModuleとして登録する処理を書くクラスとなります。 生成してすぐは、次のような形になっています。（※importやクラス定義の部分は省略しています。）\n... public static final Setting\u0026lt;String\u0026gt; YOUR_SETTING = new Setting\u0026lt;\u0026gt;(\u0026#34;ingest.kuromoji_part_of_speech_extract.setting\u0026#34;, \u0026#34;foo\u0026#34;, (value) -\u0026gt; value, Setting.Property.NodeScope); @Override public List\u0026lt;Setting\u0026lt;?\u0026gt;\u0026gt; getSettings() { return Arrays.asList(YOUR_SETTING); } public void onModule(NodeModule nodeModule) throws IOException { nodeModule.registerProcessor(KuromojiPartOfSpeechExtractProcessor.TYPE, (registry) -\u0026gt; new KuromojiPartOfSpeechExtractProcessor.Factory()); } ... YOUR_SETTINGプロパティとgetSettings()メソッドはelasticsearch.ymlで指定したい設定を記述する場合の例になります。今回は特に必要ないので両方削除しました。 最終系はGitHubのコードをご覧ください。\nKuromojiPartOfSpeechExtractProcessor Processorは実際にIngest Nodeで行う処理を書くところです。\npublic static final String TYPE = \u0026#34;kuromoji_part_of_speech_extract\u0026#34;; private final String field; private final String targetField; public KuromojiPartOfSpeechExtractProcessor(String tag, String field, String targetField) throws IOException { super(tag); this.field = field; this.targetField = targetField; } @Override public void execute(IngestDocument ingestDocument) throws Exception { String content = ingestDocument.getFieldValue(field, String.class); // TODO implement me! ingestDocument.setFieldValue(targetField, content); } @Override public String getType() { return TYPE; } public static final class Factory extends AbstractProcessorFactory\u0026lt;KuromojiPartOfSpeechExtractProcessor\u0026gt; { @Override public KuromojiPartOfSpeechExtractProcessor doCreate(String processorTag, Map\u0026lt;String, Object\u0026gt; config) throws Exception { String field = readStringProperty(TYPE, processorTag, config, \u0026#34;field\u0026#34;); String targetField = readStringProperty(TYPE, processorTag, config, \u0026#34;target_field\u0026#34;, \u0026#34;default_field_name\u0026#34;); return new KuromojiPartOfSpeechExtractProcessor(processorTag, field, targetField); } } TYPEがIngest APIのPipelineでProcessorを指定するときに使う名前になります。ここは、cookiecutterの時にprocessor_typeに入力した文字列になっています。 kuromoji_part_of_speech_extractだと長いので、kuromoji_pos_extractに変えました。\nexecute()メソッドに// TODO implement me!とあります。 この部分に実際の処理を記述していきます。\nあとは、FactoryクラスでIngest APIで指定された設定項目を読み込みます。 今回作成したelasticsearch-ingest-kuromoji-pos-extractでは品詞を指定する必要があるので、pos_tagsを指定できるように処理を追加しました。\n私が実装したものの説明をするとちょっと長くなりそうなので、GitHubのコードをご覧ください。\nテストのコーディング テストのクラスもテンプレートで生成されています。\nKuromojiPartOfSpeechExtractProcessorTests KuromojiPartOfSpeechExtractRestIT KuromojiPartOfSpeechExtractProcessorTests Processorクラスのテストになります。生成直後は次のような感じです。\npublic void testThatProcessorWorks() throws Exception { Map\u0026lt;String, Object\u0026gt; document = new HashMap\u0026lt;\u0026gt;(); document.put(\u0026#34;source_field\u0026#34;, \u0026#34;fancy source field content\u0026#34;); IngestDocument ingestDocument = RandomDocumentPicks.randomIngestDocument(random(), document); KuromojiPartOfSpeechExtractProcessor processor = new KuromojiPartOfSpeechExtractProcessor(randomAsciiOfLength(10), \u0026#34;source_field\u0026#34;, \u0026#34;target_field\u0026#34;); processor.execute(ingestDocument); Map\u0026lt;String, Object\u0026gt; data = ingestDocument.getSourceAndMetadata(); assertThat(data, hasKey(\u0026#34;target_field\u0026#34;)); assertThat(data.get(\u0026#34;target_field\u0026#34;), is(\u0026#34;fancy source field content\u0026#34;)); // TODO add fancy assertions here } テストメソッドも実装されていますが、パラメータの追加の設定処理やアサーションが書かれてません。 実装に合わせて、アサーションや設定処理を追加しましょう。\nKuromojiPartOfSpeechExtractRestIT こちらはIntegration Testになります。 実際にElasticsearchに対して外部からAPIを叩くような感じです。 APIを叩くときに利用するJSONの設定やアサーションはsrc/test/resourcesにyamlファイルがあります。\n10_basic.yaml 20_kuromoji_part_of_speech_extract_processor.yaml 10_basic.yamlはプラグインがインストールされているかの確認のテストです。特に変更する必要はないです。\n20_kuromoji_part_of_speech_extract_processor.yamlは実際にコーディングしたProcessorが動くかどうかのテストです。\nテストの内容については、GitHubのコードをご覧ください。\nテストの実行とZipの生成 テストの実行とZipの生成は次のコマンドを実行すればOKです。\ngradle check テストに問題があった場合は、コケますし、問題なければSUCCESSと表示が出ます。 成功した場合はbuild/distributions/というディレクトリにzipファイルができています。 これをElasticsearchのpluginコマンドでインストールすれば動きます。\nbin/plugin install file:///path/to/elasticsearch-ingest-kuromoji-pos-extract/build/distribution/ingest-kuromoji_part_of_speech_extract-0.0.1-SNAPSHOT.zip kuromoji_pos_extractの利用方法 Ingest APIには便利なSimulate Pipeline APIがあります。\nということで、mecab-ipadic-NEologdにあったサンプルの文章を使って、使い方の説明です。\nPOST _ingest/pipeline/_simulate { \u0026#34;pipeline\u0026#34; : { \u0026#34;description\u0026#34; : \u0026#34;kuromoji neologd extract test\u0026#34;, \u0026#34;processors\u0026#34; : [ { \u0026#34;kuromoji_pos_extract\u0026#34; : { \u0026#34;field\u0026#34; : \u0026#34;body\u0026#34;, \u0026#34;target_field\u0026#34; : \u0026#34;noun_field\u0026#34;, \u0026#34;pos_tags\u0026#34; : [ \u0026#34;名詞-固有名詞-組織\u0026#34;, \u0026#34;名詞-固有名詞-一般\u0026#34;, \u0026#34;名詞-固有名詞-人名-一般\u0026#34;, \u0026#34;名詞-固有名詞-地域-一般\u0026#34;, \u0026#34;名詞-固有名詞-地域-国\u0026#34; ] } } ] }, \u0026#34;docs\u0026#34; : [ { \u0026#34;_index\u0026#34;: \u0026#34;index\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;type\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;id\u0026#34;, \u0026#34;_source\u0026#34;: { \u0026#34;body\u0026#34; : \u0026#34;10日放送の「中居正広のミになる図書館」（テレビ朝日系）で、SMAPの中居正広が、篠原信一の過去の勘違いを明かす一幕があった。\u0026#34; } } ] } 結果はこちら。\n{ \u0026#34;docs\u0026#34;: [ { \u0026#34;doc\u0026#34;: { \u0026#34;_index\u0026#34;: \u0026#34;index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;id\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;type\u0026#34;, \u0026#34;_source\u0026#34;: { \u0026#34;noun_field\u0026#34;: [ \u0026#34;10日\u0026#34;, \u0026#34;中居正広のミになる図書館\u0026#34;, \u0026#34;テレビ朝日\u0026#34;, \u0026#34;SMAP\u0026#34;, \u0026#34;中居正広\u0026#34;, \u0026#34;篠原信一\u0026#34; ], \u0026#34;body\u0026#34;: \u0026#34;10日放送の「中居正広のミになる図書館」（テレビ朝日系）で、SMAPの中居正広が、篠原信一の過去の勘違いを明かす一幕があった。\u0026#34; }, \u0026#34;_ingest\u0026#34;: { \u0026#34;timestamp\u0026#34;: \u0026#34;2016-07-22T06:18:49.007+0000\u0026#34; } } } ] } noun_fieldに固有名詞の単語が抜き出せているのがわかるかと思います。\nAlexのテンプレートで困った点 テンプレートは便利だったのですが、processor_typeに_を使用したタイプ名を指定すると次のような問題（？）が発生しました。\nクラス名がKuromoji_part_of_speech_extractProcessorとなってしまう 深刻な問題ではないのですが、JavaだとCamel Caseが普通なのでちょっと気になって。 ということで、プルリク作って出してみました。まだ取り込まれてないかな。\n取り込み前に使いたい方は以下のコマンドを実行してください。 processor_class_nameという項目が増えています。 デフォルトだとprocessor_typeの_の部分を取り除きつつCamel Caseにしたものが入ります。\ncookiecutter gh:johtani/cookiecutter-elasticsearch-ingest-processor まとめ ということで、とりあえず作ってみましたというものになります。 特徴的な単語（固有名詞だけ）を抜き出して、別のフィールドにできるので、タグみたいなものをこれを使って前処理で作れるようになるかなぁと。\n参考ブログ（元ネタ？） インスパイア元となったブログです。\nUser Agentを解析するIngest Pluginを書いてみた Elasticsearch 5.0.0のIngest Node用プラグインを書いた話 ","date":1469161616,"dir":"post/2016/","id":"a62186ea292d6db03a087bd5dfcc3f1e","lang":"ja","lastmod":1469161616,"permalink":"https://blog.johtani.info/blog/2016/07/22/making-ingest-processor-plugin-with-cookiecutter/","publishdate":"2016-07-22T13:26:56+09:00","summary":"久しぶりに、技術的なブログ書いてます。 Ingest Processorのプラグインを作ってみたくなったので、書いてみました。 ただ書いてみるんじゃ3番煎じ","tags":["elasticsearch","plugin"],"title":"Lucene Kuromoji for NEologdで指定した品詞の単語を抜き出すIngest Pluginを書いてみた #elasticsearchjp"},{"contents":"なんか、今年はよく物が壊れる、厄年だからかなぁ？\nということで、記念に何が壊れたかをブログに残しておこうかと。\n腕時計（壊れてないかな） 電波腕時計を使ってたんだけど、電池がへたってたのでオーバーホールしてもらった。 Moto 360（壊れたというか。。。） 何度かバージョンアップしてるんだけど、数ヶ月前から、ちょっと触っただけで電源が落ちる現象が。ファームウェアのせいかAndroid Wearのバージョンアップのせいかわからないけど。。。挙げ句の果てに、電源を入れるために充電器にセットしないといけないと言う酷い仕様。。。 自転車前輪 自転車で車道を横切る側溝の蓋の間に前輪がはまってすっ転んでしまい、タイヤのスポークがちょっと曲がってしまう ジーンズその1 自転車で転んだ時に、膝とかこすって破れる ジーンズその2 福岡出張中に雨で滑って派手に転んで、膝に大きな穴が。。。 リュック あー、怪しいなと思ってたんだけど、やっぱりこわれた、、、 pic.twitter.com/CD2Y7t6AOD\n\u0026mdash; Jun Ohtani (@johtani) 2016年6月16日 怪しいとは思ってたんだけど。。。 ということで、リュックを新調しつつ修理に出してるところ。 5. Xperia Z3 * 先週金曜日にカメラのレンズが結露してるなぁと思ったら、電源が入らなくなった。補償サービスに入ってたんで、新しいZ3を次の日に送付してもらい復旧。いろいろなアプリがログインしないといけないのでかなり大変だった。。。\nまだ、半年残ってるので他にも壊れるのかなぁ。。。 お祓いしてもらったので、何もなければいいんだけど。\nということで、なんとなく欲しいものリストを貼っておきますね。\n","date":1467251858,"dir":"post/2016/","id":"167e2a6833d49ce198cb3b88f521991e","lang":"ja","lastmod":1467251858,"permalink":"https://blog.johtani.info/blog/2016/06/30/broken-something-in-this-year/","publishdate":"2016-06-30T10:57:38+09:00","summary":"なんか、今年はよく物が壊れる、厄年だからかなぁ？ ということで、記念に何が壊れたかをブログに残しておこうかと。 腕時計（壊れてないかな） 電波腕時","tags":["misc"],"title":"よく物が壊れる年"},{"contents":"第16回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 今回は、司会だけに注力してみました（）。\nチェックイン数など チェックインした人：141名 キャンセルしなかった人：67名 でした。\n今回は、参加希望者が多くて、当日にも100名近いキャンセル待ちの方がいたので、 240名まで、参加者枠を増枠（会場キャパ190名程度）して対応しました。 まぁ、読み通り、1/3の方はキャンセルしない形でした。 天気も良く電車の遅延などもなさそうだったので、ちょっとドキドキしてたのですが。\n以下は簡単なメモです。\n「LogstashとElasticsearchで作るEnterprise Search Platform」/ Elastic Kosho Owa スライド：https://speakerdeck.com/kosho/enabling-enterprise-search-platform-with-elastic-stack\n使ってるLogstashの設定ファイルを elastic-japan at elastic dot co に送るとTシャツがもらえるらしい。 Logstashのfilter-rubyはここで、evalしてcallしてるから、特にforkとかしてないかと。 「企業・業界情報プラットフォームSPEEDAにおけるElasticsearchの活用」 / 株式会社ユーザベース 北内 啓さん スライド：http://www.slideshare.net/tau3000/speedaelasticsearch-63510388\nアルゴリズム関連の開発担当 企業データをいろんな軸で検索したい データ数が約70億レコードになりそう（通貨 x MySQL） 300万企業データ＋Nestedとかで持ってる。 11万フィールド？？？ 10台の物理サーバに24仮想マシン 企業名の検索 recall重視 NewsPicksの検索機能 「日本 化粧品 売上高」業界のデータとかも観れるのかな？有料会員向け機能 登録済みキーワードかどうかをRDB＋Esに検索して、ID化するっぽい ID（Analyze必要ない）検索だから、termクエリだった、サンプルが。 ノードの役割分担 更新はMasterNode経由でDataNodeへ。 検索はClientNode経由でDataNodeへ。 1.xかぁ。。。 「Elasticsearchベースの全文検索システムFess」 / 株式会社エヌツーエスエム 菅谷信介さん スライド：http://www.slideshare.net/shinsuke/elasticsearchfess\n10.xからSolrをやめてElasticsearchへ。 日本語検索 bigram＋形態素（1文字検索とかに対応するため） NeologDに対応したkuromojiを利用 DBFluteをESFluteとしてEs対応 KOPFを組み込んで使ってる configをREST API経由で更新できるプラグインあり LT 「ElasticsearchとGCPのネットワークでハマった話」 株式会社サイバーエージェント 平田大地 さん @daichild スライド：https://speakerdeck.com/daic_h/gcpfalsenetutowakudehamatutahua\nhhkb2 2刀流！ networkのKeep-alive周りで困ったよというお話。 後で聞いたけど、GCE Cloud Pluginは使ってるそうです。 06/28 17:00追記\nPingを定期的に実行させることで回避も出来るようです。 transport.ping_scheduleに時間を指定します。通常のNode（Transport以外）は\u0026rsquo;-1\u0026rsquo;が指定してあり、動作してません。 「スクリプトフィールドで作るランキングみたいな何か」iwag さん スライド：https://speakerdeck.com/iwag/elasticsearch-dezuo-rurankingu\n1.xかぁ。。。 あとは、function_scoreとかも面白いですよ！ その他、感想などのブログ 第16回elasticsearch勉強会に参加してきた 第16回Elasticsearch勉強会に参加してきた まとめ＋宣伝？ 1.xがまだまだいますねぇ、早く2.xにアップしましょう！（5.0ももう直ぐだし）。懇親会でも色々と話しましたが、https://discuss.elastic.co というフォーラムあるので、ぜひ活用してください。\n次回は8月末か9月頭かでしょうか。 7月末にOSC京都に出没するので、京都で勉強会やりたいと思ってます！ 会場とかスピーカーとか興味ある人連絡ください。\n東京の勉強会のスピーカーも随時募集中ですので、連絡ください。\n","date":1467089755,"dir":"post/2016/","id":"993e58f132740b464ecf06ee289dc7b2","lang":"ja","lastmod":1467089755,"permalink":"https://blog.johtani.info/blog/2016/06/28/16th-elasticsearch-meetup/","publishdate":"2016-06-28T13:55:55+09:00","summary":"第16回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第16回Elasticsearch勉強会を開催しました。 #elasticsearchjp"},{"contents":"第15回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 今回は、Elastic{on} 2016開催直後ということで、大半はElastic{on}に関する話でした。\nチェックイン数など チェックインした人：114名 キャンセルしなかった人：62名 でした。 今回は、少しおそめで1時間前にキャンセル待ちがいない状態にしました。 まぁ、いつもの感じでしょうか。数値も安定してきた感じですかね。\n\u0026ldquo;Elasticsearchと機械学習を実際に連携させる\u0026rdquo; / Preferred Networks America, Inc. CTO 久保田展行(Kubota Nobuyuki) さん スライド：Elasticsearchと機械学習を実際に連携させる\n前回の続きの話で、今回が本題でした。\n勉強会直前に発表されたSensorBeeをElasticsearchと一緒に使うとどんなことができるかというお話です。 まぁ、前処理重要ですよねというのが、いつものことですが、印象的でした。 いつものようにわかりやすい説明だったので、使ってブログを書いて欲しいなと。\n発表の中で、説明に出てきたデモとか。\nCES2016でロボットカーのデモを展示してきました \u0026ldquo;Elastic{ON} 2016レポート\u0026rdquo; / Elastic Jun Ohtani スライド：elastic{on} 2016 レポート\n写真多めで、キーノートをメインに話をしました。\n簡単なまとめとしては\nプロダクトロゴができました。ロゴ画像などはこちら 次のメインバージョンは全て5.0。（5.0に関する通知が欲しい人はこちらで登録できます） elastic{on} 2016のビデオなどはこちら BBL始めます。連絡ください \u0026ldquo;Elastic{ON}の過ごし方\u0026rdquo; / クラスメソッド株式会社 藤本 真司 さん スライド：Elastic{ON}の過ごし方\n印象に残ったのは\n「自他共に認めるブログの会社」 4/12にSAPさんに会場を借りてElastic＆クラスメソッドでイベントやります。 やっぱりご飯が美味しいんですねぇ。 早速ブログが書かれてました。\n\u0026ldquo;Elastic{ON} 2016 見るべきセッション資料 7選\u0026rdquo; / Acroquest Technology株式会社 谷本 心 さん スライド：Elastic{ON} 2016 見るべきセッション資料 7選 #elasticsearchjp\n印象に残ったのは\n東京でハンズオンやる会場提供者募集中！ Ingest Node（参考：Ingest Nodeのドキュメントは公開中。） Reindex API（参考：Backport reindex to 2.x ） その他、感想などのブログ 第15回elasticsearch勉強会にLTで登壇しました #elasticsearch #elasticsearchjp 第15回elasticsearch勉強会に参加してきました #elasticsearch #elasticsearchjp まとめ＋宣伝 来年のElastic{ON}に参加したいと思っていただけたらよかったなと。\n4/12にクラスメソッドさんとイベントを行います。また、ツイートすると思います。\n次回はいつも通りだと5月中旬になるかと思います（大丈夫かな？OSC 2016 Nagoyaでしゃべったり、ブース出したりとかするけど）。 5末に名古屋に出没します。名古屋で勉強会できればやりたいと思ってます。会場とかスピーカーとか興味がある方は連絡ください。\n","date":1458186180,"dir":"post/2016/","id":"c56a76ef8f604a8d87be2a32b1f81fac","lang":"ja","lastmod":1458186180,"permalink":"https://blog.johtani.info/blog/2016/03/17/15th-elasticsearch-jp/","publishdate":"2016-03-17T12:43:00+09:00","summary":"第15回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第15回Elasticsearch勉強会を開催しました。 #elasticsearchjp"},{"contents":"久々のポスト。。。\n久々に、技術書読んでます。「自然言語処理の基本と技術」という本です。\n監修の方のツイートを見て気になったので、買ってみました。 書籍のサイトの説明はこんな感じでした。\n本書は、この未来に不可欠となるに違いない自然言語処理の、技術的、ビジネス的基礎知識をくまなくコンパクトに図解した一冊です。 著者陣もそれぞれの分野の第一線で活躍するエキスパート揃い！\n確かに著者陣がすごいです。\nまだ、「はじめに」と自分に関係のある「情報検索」の章を流し読みしただけなんですが、次のような特徴がある本です。\n平易な単語で説明してある（難しい専門用語が少ない） 数式が出てこない（多分。少なくとも読んだ部分では見てない） 説明には例と図解がある 情報検索の章で言うと、全文検索でよく使われる転置インデックス（索引という単語が使われてる）がなぜ必要なのか、どういう感じで作られるのか、 転置インデックスに利用する索引の単語をどうやって作るのか（文字N-Gramや形態素解析）、単語の正規化（ステミングやストップワード）などの説明が 本当にわかりやすく書かれています。 スコアリングについても触れられています。\nElasticsearchも転置インデックスを用いた検索を行っており、 MappingでAnalyzerの指定をしている理由などの理解に役に立つと思います。\n全文検索システムがどのように検索を処理しているかをざっくり理解するのにはもってこいじゃないかと。 1点残念だなと思ったのは、書籍に「索引」がありませんでした（本の索引を思い浮かべてくださいっていう説明あったんだけど）。。。 Kindle版を購入すれば「検索」できるのかな？\nということで、まだ、流し読みしただけなんですが、「すごく」オススメです。 購入はこちらから！\n","date":1457962452,"dir":"post/2016/","id":"3fc7462a83fa55885067fee629287e8a","lang":"ja","lastmod":1457962452,"permalink":"https://blog.johtani.info/blog/2016/03/14/review-basics-and-tech-of-nlp/","publishdate":"2016-03-14T22:34:12+09:00","summary":"久々のポスト。。。 久々に、技術書読んでます。「自然言語処理の基本と技術」という本です。 監修の方のツイートを見て気になったので、買ってみました","tags":["本"],"title":"「自然言語処理の基本と技術」を読んでる"},{"contents":"あけましておめでとうございます、johtaniです。\n第14回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 今年もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\nチェックイン数など チェックインした人：122名 キャンセルしなかった人：58名 でした。 今回も当日の昼の時点でキャンセル待ちがない状態にしていました。 いくつか電車が止まっていたという話を聞いていたので、開始を5分遅らせ、 受付は45分くらいまで開けておくという対応をしてもらいました。\n\u0026ldquo;ココが辛いよelasticsearch\u0026rdquo; / 株式会社リクルートテクノロジー @tatakaba さん スライド：ココが辛いよelasticsearch\n実際にいくつかのサービスで運用されている内容とどういった機能を利用しているか、 どういったものを独自に作っているかという話をしていただきました。\n独自PluginでA/Bテストしてる Snapshotの活用 Index作成は環境に合わせて行っている。 バージョンは混在 PusnaRSのバージョンアップの話。 2つのバージョンのクラスタを用意してリアルタイムに切り替え。 Elasticsearchの活用 QueryのRewrite： SolrのリクエストをEsで受け付けたり。 辛い話。 バージョンアップが辛い Riverなくなるのつらい データずれるのつらい 補足：\nバージョンアップについて 1.x系から2.x系にアップされるのであれば、こちらを必ず試してください。\nhttps://github.com/elastic/elasticsearch-migration\n「.」が使えなくなるという話は、Solrとの大きな違いになるのかもなぁと。 ネスト構造のデータの表記を「.」で行うというのを厳密に行えるように、 「.」を使えなくしたというのがあるかと。\nRiverについて Riverがなくなった理由については、https://www.elastic.co/blog/deprecating-rivers で記載があります。 便利なのですが、負荷が偏ったり、スケールしないとかいう問題点があるかなと。\n良いサンプルとしては、JDBC Riverなどは、Javaのプログラムとして起動できるように変更されていたりします。\nhttps://github.com/jprante/elasticsearch-jdbc/wiki/jdbc-plugin-feeder-mode-as-an-alternative-to-the-deprecated-elasticsearch-river-api\n（個人的 には、SolrのDIHもRiverもあんまり好きではなかったです。データの変換処理と、ロード処理は別々にしたい人だったので。）\nデータのズレなど 耐障害性とか信頼性に関しては、どういった問題点があるのか、どういった対応をしているのかというのがまとめられたページが用意されています。\nhttps://www.elastic.co/guide/en/elasticsearch/resiliency/current/index.html\n「機械学習を利用したちょっとリッチな検索」 / Preferred Networks America, Inc. CTO 久保田展行(Kubota Nobuyuki) さん スライド：機械学習を利用したちょっとリッチな検索\n来日していただき、機械学習と検索の話をしてもらいました。 本編は次回の発表かもw\n機械学習を元に、検索対象の情報を元の情報から増やしてあげる。 増えた情報を検索できるようにする 今日のゴール： 機械学習とはどういうものか？ データの集め方とか、アノテーションとか 学習の方法（ツールやライブラリに依存） Esでの活用方法 オフラインで学習させて、情報を付与した後に、Elasticsearchに入れる Jubatus＋fluentdで ChainerサポートのOSSのツールを公開予定 「ここからが本当の地獄だ。。。」ってのが聴きたいw\n「Lucene Query 再考 - Domain Specific Query 実装 -」 / Supership株式会社 インフラ事業開発本部検索グループ 大川真吾 さん スライド：Lucene Query 再考 - Domain Specific Query 実装 -\nLuceneのクエリに関する話と、クエリパーサーに関する話でした。 こういった濃い話も勉強会でしてもらえると、色々な参加者に楽しんでいただけるかなぁと。 次回も続きを話してもらう予定です。\n補足：\n参考までにですが、Elasticsearchに入門したての人向けに、 Analyzerとか転置インデックスとかの話をした時のスライドになります。 https://speakerdeck.com/johtani/lucenetori-ben-yu-falsejian-suo\nLT: Fluentd meets Beats / @repeatedly さん スライド：http://www.slideshare.net/repeatedly/fluentpluginbeats-at-elasticsearch-meetup-14\n参考Qiita：http://qiita.com/repeatedly/items/77af41788f0b3ccdefd2\nBeatsの説明をTDの人からしてもらうなどw FluentdにBeatsからのデータを流し込めるようにしたプラグインが出たという話でした。\nfilebeatの性能の件は社内で聞いてみようかと。\nElasticsearchインデクシングのパフォーマンスを測ってみた / 日本IBM　黒澤亮二さん スライド：Elasticsearchインデクシングのパフォーマンスを測ってみた\n参考Qiita：http://qiita.com/rjkuro/items/e79eec7ffb0511b7c678\n細かな性能測定の結果を駆け足で話してもらいました。 皆さんもこの指標をもとに、手元の環境を計測してみたりしてみてもらえればと。\nあとは、2.x系になってるので、同じ方法で計測してもらってまた 発表してもらえると嬉しいなー（棒）\nその他、感想などのブログ Elasticsearch勉強会　第14回フィードバック まとめ＋宣伝 久々に（初めてかな？）、ゲストがいないのに自分が喋りませんでした。 次回は3月中旬を予定してます。 次回は、Elastic{ON}16の報告をする予定です。いろいろと発表あるだろうし。\nあと、今月末の1/29にオープンソースカンファレンス 2016.enterprise@Osakaにブース出展します。 セミナー枠でも弊社OSSプロダクトの概要を話しする予定です。 関西の方は、ぜひ参加していただければと。ブースでお待ちしております。\nまた、スピーカーや場所が用意できたら、出張勉強会もまたやりたいなと思っています。 興味ある方は、連絡ください！\n","date":1452220496,"dir":"post/2016/","id":"4b0a768585da8f9f8f8db1ca409e7ebd","lang":"ja","lastmod":1452220496,"permalink":"https://blog.johtani.info/blog/2016/01/08/14th-elasticcsearch-jp/","publishdate":"2016-01-08T11:34:56+09:00","summary":"あけましておめでとうございます、johtaniです。 第14回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆","tags":["elasticsearch","勉強会"],"title":"第14回Elasticsearch勉強会を開催しました。 #elasticsearchjp"},{"contents":"今年は紅白見ながら書いてます。 早い一年だったなぁ。\n振り返り(2014年に書いた抱負から) まずは去年の抱負を元に振り返りをば。\n英語の継続 海外のイベントへの参加 多岐にわたるイベントでのスピーカー 日本の人員の倍増！？ Elasticsearchに関する日本語の情報発信 Elasticsearch座談会みたいなものの開催 英語はまぁ、継続してます。亀の歩みですが。。。\n海外のイベントへの参加は、自社のイベントだけでした。来年のElastic{ON}ももちろん参加です。来年こそBerlin Buzzwords行きたいな。。。\n多岐にわたるイベントとまではいってないですかね。。。来年はOSC(大阪や東京)に出没予定です。参加される方は、声をかけていただければと。\n人員は倍増しました！営業の方が参画されたのがかなり助かってます。 今現在で4名です！来年も倍増できるかなぁ？\n日本語の情報発信はリリースブログの翻訳が多めでした。来年は独自コンテンツも増やさないとなぁ。 あとやっぱ書籍かなぁ。。。座談会は来年の課題に。。。\n振り返り(今年あったできごと) その他の今年の出来事。\n初渡米 初バルセロナ 東京以外で勉強会 初自社イベント（日本で） 初トレーナー 不惑 今年も初モノ多いですね。今年も楽しい一年でした。 自社イベントでアメリカやバルセロナなどに行きました。40年近く、海外に行ったことないせいか、海外に行って経験することが面白いです。\n東京以外での勉強会もやりました。名古屋、大阪、京都、北海道と。 来年もOSCで訪れた場所で勉強会を開催したいなぁと。\n自社のイベント（Elastic{ON} Tour Tokyo）も東京でやりました。 どうなることかと思っていましたが、朝から大勢の方に来ていただけてホッとしました。 自分のトークがどうだったのかという反応も気になりますが。。。 せっかくShayたちが来ていたので、もっとブースに話しに来てもらえるともっと嬉しかったかもなぁと。\nTour Tokyoを挟んで自社の公式トレーニングのトレーナーもやりました。 日本で3回目にして、初の日本語でのトレーニングでした。前の2回は逐次通訳だったんですが。 トレーニングって大変だなぁと思ったのと、やはり日本語でトレーニングを受けられるとだいぶ違うだろうなという実感がありました。 来年もできればいいなと。トレーニング自体があったことを知らない人もいたのかなぁ？\n来年の抱負 英語の継続 もっとElasticsearchの開発に参加 人員の倍増？ 日本語情報発信 Splatoon S+? 英語あいかわらず出来てないので、頑張らないと。 もっと喋ったりしないとなんだろうなぁ。\n来年は開発をもっとやりたいなと。 来年1月にはセールスのエンジニアが加入するので、開発にもっと時間を割きたいなと。\n人員は倍増できるように頑張りたいです。少なくとも、2人が1月に入ることは決まってるんで、後二人！\nブログももっと書かないとですね。新機能とかこんな使い方できるよとか。 どんな記事が欲しいかとかコメントもらえると楽なので、突っ込みくださいw\n最後は、完全に私用ですね。Splatoonにはまってますw SとA+を行ったり来たりで。。。\nということで、今年はあと、数時間ですが、色々とお世話になりました。 この場を借りてお礼申し上げます。\n来年も、いろんな方に絡んでいくとは思いますが、よろしくお願いいたします。\n","date":1451565182,"dir":"post/2015/","id":"c54909ecf4fb3e9afeea36200fe95dce","lang":"ja","lastmod":1451565182,"permalink":"https://blog.johtani.info/blog/2015/12/31/looking-back-2015/","publishdate":"2015-12-31T21:33:02+09:00","summary":"今年は紅白見ながら書いてます。 早い一年だったなぁ。 振り返り(2014年に書いた抱負から) まずは去年の抱負を元に振り返りをば。 英語の継続 海外の","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2015）"},{"contents":"今年最後のAdvent Calendarとなります。\nこの記事はElasticsearch Advent Calendar 2015の最終日のエントリです。\n簡単に今年の変遷を、Elasticsearchをベースに振り返ってみようかと思います。\nKibana 4リリース（2月） Kibana 4（日本語訳） いきなり、Elasticsearchではない話題ですが。 AggregationベースのKibanaがリリースされました。 画面が黒くないというので、話題になりましたw 12月末時点では、4.3.1になっています。 Sub Aggregationによる強力なグラフ表示や異なるインデックスに対するグラフを 一つのダッシュボードに表示できるといったことができるようになりました。\nセキュリティ向けプラグインShieldのリリース（2月） セキュリティ向けプラグインShieldのリリース（日本語訳） 商用向けのプラグインの第2弾です。 セキュリティ強化のためのプラグインで、いろいろなところで引き合いがあったりします。\n初のユーザカンファレンス、Elastic{ON}開催（3月） #elasticon に参加中 サンフランシスコで、弊社初のカンファレンスが開催されました。（来年（2016年）もサンフランシスコで開催されます。） また、ここで、以下の2点の発表がありました。\nロゴ及びドメイン名などの変更 Foundのジョイン 約1300名が参加する大イベントでした。 初の渡米で楽しんできましたが、ドメインの切り替えなどは大変でした。。。 まだ、ロゴを変えて1年経ってないということが実感できてないです。\nFoundのジョインはまだまだ、日本で知名度が出てないかもなぁと。 もっと広めないと。 利点としては以下の通りです。\n新バージョンがすぐに利用可能に。また、バージョンアップも画面で指定可能 公式プラグイン＋その他いくつかのプラグインが利用可能 Elasticsearch 1.5 リリース（4月） Elasticsearch 1.5.0リリース（日本語訳） 主に、resiliencyに関する改良になります。 毎リリースで信頼性向上につながる改良が含まれる形になっています。 このリリースの近くで初の東京の外での勉強会を名古屋で開催したりもしました。\ndiscuss.elastic.coをオープン（5月） https://discuss.elastic.co これまでは、Google Groupsを使っていましたが、Elasticが提供しているプロダクトが 別々のグループであったために、プロダクトにまたがった質問がやりにくかったり、検索がしにくかったりという問題点がありました。 今では、過去のGoogle Groupsのデータも移行されているので、是非参加して、質問・回答してみてください。 日本語でやりとりできるカテゴリもあるので、どんどん、やりとりしていただければ。\nElasticsearch 1.6 リリース（6月） Elasticsearch 1.6.0リリース（日本語訳） 2.0に向けたUpgrade APIが含まれるなど、次期リリースに向けた準備が整いつつあるリリースでした。 他にもsynced flushの取り込みやレスポンスのJSONのフィルタリングなど細かな改善も取り込まれています。\nFound PremiumとStandardリリース（7月） さらに進化したFound（日本語訳） Foundに弊社のサポートチームがサポートできるプレミアムが追加されました。 これにより、商用プラグインとして提供しているShieldが（現在はWatcherも）利用できるなど、 より便利になりました。また、Kibana 4も無料で提供されていたりします。\n小さなサイズのものですと、無料で試していただけるものもあるので、試してみてもらえればと。\nElasticsearch 1.7 リリース（7月） Elasticsearch 1.7.0 および 1.6.1リリース（日本語訳） 1.x系、最後のリリースでした。 小さい改善ですが、セキュリティフィックス、クラスタの安定化に寄与する機能改善が含まれています。\nこのリリース直前に大阪、京都で勉強会も開催してみました。\nElasticsearch 2.0.0-beta1 リリース（8月） Elasticsearch 2.0.0-beta1リリース（日本語訳） 待ちに待った、Lucene 5ベースのElasticsearchの登場でした。 doc_valuesがデフォルトになったり、エラーが構造化されて見やすくなったり、 Pipeline Aggregationが導入されたりしています。 また、問題点の洗い出しも兼ねて、ベータリリースとして、本リリースまでに多くのIssueをあげていただきました。\nElasticsearch 2.0.0 リリース（10月） 2.0の本リリースです。リリースまでに、beta1、2及び、rc1がリリースされました。\n追加された機能や目玉の改善については「Elasticsearch 2.0の紹介」のスライドを参考にしていただければと。\nまた、Elasticsearch 2.0のリリースに合わせて、商用プラグインやLogstash、Kibanaの新しいバージョンがリリースされました。 Kibanaなどは、プラットフォームとしての機能を備え、SenseやTimelionと言ったプラグインアプリもリリースされています。\nLogstash 2.0.0リリース（日本語訳） Kibana 4.2.0リリース（日本語訳） Senseの歴史 - Sense 2.0.0-beta1の紹介(日本語訳) Shield、Watcher、Marvel 2.0.0 GAリリース（日本語訳） Elasticsearch 2.1.0 リリース（11月） Elasticsearch 2.1.0 and 2.0.1 released Beats 1.0.0のリリース（11月） The Beats 1.0.0 Go言語で書かれた軽量データシッパーになります。 パケットをキャプチャしてElasticsearchに送るPacketbeat、 topコマンドで取れるデータなどをTopbeat、 ログファイルなどを取り込み配送するFilebeatがリリースされました。\nlibbeatと呼ばれる、 ベースとなるライブラリを元にしたプロダクトで、Logstashのエージェントのような使い方もできるようになっています。\nGo言語に興味のある方などは、調べてみてはいかがでしょう？\n来年は？ 日本では、1/7に第14回Elasticsearch勉強会を開催します。 すでに、38名のキャンセル待ちとなっていますが、おそらく、年明けにキャンセルがそこそこ出ると思うので、まだ間に合うんじゃないかなぁと。\n会社としては、Elastic{ON}16が控えています。参加される方は、ぜひ現地で声をかけてください！！\nその他にもイベント、オープンソースカンファレンス（まずは、大阪、東京）などに出没する予定ですので、こちらも参加していただければと。\nでは、また来年のAdvent Calendarでお会いしましょう！\n","date":1451017794,"dir":"post/2015/","id":"d819cea5197e9b8673d6c0b16659a5ea","lang":"ja","lastmod":1451017794,"permalink":"https://blog.johtani.info/blog/2015/12/25/about-elasticsearch-in-2015/","publishdate":"2015-12-25T13:29:54+09:00","summary":"今年最後のAdvent Calendarとなります。 この記事はElasticsearch Advent Calendar 2015の最終日のエントリです。 簡単に今年の変遷を","tags":["elasticsearch"],"title":"2015年のElasticsearch"},{"contents":"こんにちは、@johtaniです。\n早いもので、師走です。今年もあと少しとなりました（今月が一番忙しかったりしますが。。。）。 ということで、Advent Calendarの季節が始まりました。\nこの記事はElasticsearch Advent Calendar 2015の1日目のエントリです。\n今日は、最近公開されたTimelionの紹介をしたいと思います。\nTimelion? 11/12に公開されたばかりのアプリになります。（公式のブログはこちら。ブログでは動画による説明もあり）\nKibanaにプラグインとしてインストールすることで使用することができるようになるアプリです。 Timelionと書いて「Timeline」と読むようです。 Kibanaとは異なるグラフ描画のプラグインになっています。\nKibana 4.2からプラットフォーム化 Kibana 4.2から、Kibanaにプラグイン機構が導入されました。 Kibanaとしての機能以外にも、プラグインとして、アプリを追加できるようになっています。 Timelionもその一つです。\nインストール Timelionを試してみるには、ElasticsearchとKibanaが必要になります。（こちらは、すでにインストールされているとして。。。）\nKibanaのコマンドを利用して、プラグインをインストールします。\nbin/kibana plugin -i kibana/timelion インストールしたら、Kibanaにアクセスして、Timelionを呼び出します。\nTimelionへアクセス ブラウザでlocalhost:5601にアクセスすると、Kibanaが出てきます。 Kibanaのプラグイン選択のアイコンをクリックし、Timelionのアイコンをクリックします。\nすると、初期画面はこんな感じです。 直近15分のElasticsearchに入っているデータがが全部出てきます。 チュートリアルも出てきてます（初回起動時に出たはず）\nKibanaでの検索窓の部分に関数を指定していくことで、グラフが描画できるツールになっています。\nサンプル：気温データを可視化 百聞は一見に如かずということで、 気象庁のデータを使って、 ちょっとしたグラフを書いてみました。 1年間の気温の推移と日照時間になります。\n上のグラフが那覇、下グラフが札幌の気温のグラフになります。\n赤いライン：最高気温 青いライン：最低気温 黄色い棒グラフ：日照時間 最低気温と日照時間はグラフは次のような式で描画しています。\n青いラインの最低気温 気温のグラフになります。\n.es(index=\u0026#39;tenki2\u0026#39;, q=\u0026#39;city:naha\u0026#39;, metric=\u0026#39;avg:temperature_min\u0026#39;).label(\u0026#39;min\u0026#39;), .es()がelasticsearchに対するデータ取得の関数です。 引数は次のような意味になります。\nindex：対象とするインデックス名 q：検索クエリ。ここでは、cityというフィールドにnahaで検索。 metric：描画対象となっているデータの入ったフィールド。temperature_minというフィールドの1日毎の平均値を取得 最低気温と最高気温は別々のフィールドに格納してあります。最高気温の場合は（temperature_max）を指定します。\n.label(min)で、グラフの凡例の指定です。 残念ながら、日本語の指定は現時点（2015年12月01日時点）ではうまくいかなかったです。（https://github.com/elastic/timelion/issues/17）\nデフォルトでは、線グラフが選択されているので、グラフの種類は特に指定はしていません。 明確に指定する場合はlines()を指定します。\n黄色い棒グラフの日照時間 .es(index=\u0026#39;tenki2\u0026#39;, q=\u0026#39;city:naha\u0026#39;, metric=\u0026#39;avg:sunlight\u0026#39;).label(sunlight).bars() .es()に関しては最低気温のグラフとほぼ一緒です。異なるのは、metricの取得対象のフィールド名です。\n.label()で凡例を指定しています。先程と同様です。\n最後に、棒グラフにしたいため、.bars()を指定しています。\nその他に用意されている関数について知りたい場合は、Timelionのヘルプを表示すると説明が出てきます。 cusum()のような値を累積して表示するような関数も用意されています。\nまとめ Kibanaとは少し違うアプローチで時系列データを描画するためのツールとなっています。 線グラフと棒グラフを一つのグラフに描画したりもできますし、 累積のグラフなんかも描画できるようになっています。\n実験的なプロジェクトである、Timelionの紹介でした。 ここでのノウハウがkibanaにフィードバックされると色々と面白いことになるんじゃないかなと。\nということで、 明日は、zoetroさんの「Kibanaのプラグインの話」になります。 お楽しみに！\n","date":1448936891,"dir":"post/2015/","id":"1b56132638912a1ca54fcf7cd38b8e23","lang":"ja","lastmod":1448936891,"permalink":"https://blog.johtani.info/blog/2015/12/01/introduction-timelion/","publishdate":"2015-12-01T11:28:11+09:00","summary":"こんにちは、@johtaniです。 早いもので、師走です。今年もあと少しとなりました（今月が一番忙しかったりしますが。。。）。 ということで、A","tags":["kibana","timelion"],"title":"Timelionの紹介 - Elasticsearch Advent Calendar 2015 1日目"},{"contents":"第13回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 来年もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n7月同様、サムライズムの@yusukeさんに テキスト翻訳していただき、大変助かりました。\nチェックイン数など チェックインした人：100名 キャンセルしなかった人：36名 でした。 今回は当日の時点でキャンセル待ちがない状態にしていました。 雨もあって、これなかった人もいるのでしょうか。\n\u0026ldquo;Beyond the basics with Elasticsearch\u0026rdquo; / Honza Král / Elastic スライド：https://speakerdeck.com/elasticsearch/beyond-the-basics-with-elasticsearch\n参考ビデオ（別のカンファレンスで話した時のビデオ）：https://www.youtube.com/watch?v=yIixWzjTNog\nPycon HKでアジアに来ていたHonzaに、ついでに日本で話をしてもらうという企画で、 前回から1カ月足らずでの開催となりました。 Elasticsearchの基本的な検索機能とは別の機能に関して少し話をしてもらった感じです。 PercolatorとAggregationの話でした。\n詳しくはビデオやスライドを見てもらうのがいいかなと。\n\u0026ldquo;How did we use Found.no for our services?\u0026rdquo; / 株式会社アイリッジ　Takuya Noguchi さん @tn961ir スライド：未定\nFoundユーザー。1.7までの話。 社内で独自にクラスタを構築していたが、managed serviceを利用したいと思っていた。 Found用のACLがShieldに マルチバイトのインデックス名とかも使いたいが、Nginxとの連携でちょっと。。。 セキュリティ関連の話も。Securityに関する報告はこういうものも用意されてるので、こちらに相談してもらうのがいいかも。https://www.elastic.co/community/security 要望がいくつか。 \u0026ldquo;ログ収集の仕組みを再考しよう！　あとマウンテンビューに行ってきました。\u0026rdquo; / Acroquest Technology株式会社 谷本 心さん @cero_t スライド：http://www.slideshare.net/shintanimoto/lets-reconsider-about-collecting-logs-plus-visiting-elasticmoutain-view\nログの小話から始まり、ログに関する考え方とかを披露してもらいました。 さらに踏み込んだログの活用の方法の話になるかと思いきや、 思いっきり話が飛んで、マウンテンビューのElasticオフィスに遊びに行った写真が出てきましたw\n写真の後は、弊社のTanya（来月のElastic{ON} Tour Tokyoで来日予定）から 聞いた弊社製品に関する話をしていただきました。 きっと、Beatsに関して次は話してくれるんだろうなぁ（棒）。 流れ的には、来年の2月にサンフランシスコで開催されるElastic{ON}16につながりそうだったので、ここで宣伝しときますね。 今年3月に開催されたイベントには残念ながら日本の方はいなかったので、次回は日本の方がいると嬉しいなぁと。\nLT \u0026ldquo;「Elasticsearch を使った単語共起頻度の計算」\u0026rdquo; / 株式会社はてな　id:takuya-a さん スライド：未定\n一風変わったElasticsearchの使い方的な話でした。 検索用にデータを登録してあるElasticsearchから単語の頻度情報を抜き出して、 別のインデックスに登録するという感じでしょうか。 こういうのが、実は、Elasticsearchに機能としてあると便利だったりするのかもなぁと思ってみたり。\nLTよりはちょっと長かったですかねw\nその他、感想などのブログ elasticsearch勉強会 まとめ＋宣伝 今回も@yusukeさんのテキスト翻訳に助けていただきました。ほんとありがとうございます。 今年の勉強会はこれがラストになります。 来月は、トレーニングとElastic{ON} Tour Tokyoがあるので忙しくなりそうですが、 参加予定の方は楽しみにしていてください！\nOperations : http://training.elastic.co/class/Operations/Japan/Dec Developer : http://training.elastic.co/class/Developer/Japan/Dec ","date":1447143778,"dir":"post/2015/","id":"2ea86ae5093670df1d4502ea82efa1ac","lang":"ja","lastmod":1447143778,"permalink":"https://blog.johtani.info/blog/2015/11/10/13th-elasticsearch-jp/","publishdate":"2015-11-10T17:22:58+09:00","summary":"第13回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第13回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：The Story of Sense - Announcing Sense 2.0.0-beta1\n誕生 よくある良いプロジェクト同様、Senseもビールを飲みながら考えつきました。 Amstelでの手漕ぎボートのセッションの後で。 友人のJasperと私はJasperの会社で毎年行われる ハッカソンについて話をしていました。 このハッカソンはどのようなアイデアでどんなチームで行うかを聞き取りされる、厳密なハッカソンです。 その時、私とJasperはChromeブラウザに別のヒストリーを表示するという作業をやるとAnne Velingに話をしていました。\nJasperと私はElasticsearchのユーザでしたが、リッチなREST APIにリクエストを送信するための 便利なツールがないと知っていました。 恥ずべきことに、cURLコマンドを利用するターミナルがその時の一番良いツールでした。 皆さん、ターミナルでボディつきのリクエストをサブミットするのがどのくらい不便かというのをわかるために、 5秒ほどターミナルで実行してみてください。 タイプミスのような単純なことでさえ、すべてのコマンドを再タイプしなければならなかったり、 複数行サポートのターミナルと戦ったりです。 ウェブベースのJSONエディタを見つけ出して、それをベースにすることが必要でした。\n終わりなきウィークエンド リサーチをして、Anneに電話しました。 私は彼に、History Pageのプロジェクトにもコミットするが、 Elasticsearchユーザなので、便利なコンソールを開発する時間も欲しいという話をしました。 私たちは、Aceオンラインエディタを利用して、 自動でAPIを認識するナレッジベースを構築し、 コンテキストに沿ったサジェストを大なうようにしました。 Anneはすぐに、それが素晴らしいと同意してくれました。 しかし、彼は、ハッカソンの基本的なルール（週末にそれが終わる必要がある）に違反しているので、 そのアイデアを却下するしかありませんでした。 確かに、私たちが提案していたものは行えませんでした。 最後に、私たちは、ChromeのHistory Pageの素晴らしい置き換えについて実装しました。\nそれでも、私はチャレンジし、それが終わるであろうことを終わるであろうことを証明しなければなりませんでした。 次の週末（といくつかの終業後 :)）に、私はそれを作りました。 Senseの誕生です。 それは、まだバグだらけでしたが、動きました。 これを見せるとみんな興奮しました。\n初期 Knowledge Baseの拡張とバグのフィックスで数日を過ごしました。 Senseは広まり始め、ずっと古いバグのあるバージョンを利用しないといけないのかと私は恐れました。 SenseをChromeのExtentionとしてリリースすることを決め、リリースすると自動的に更新されるようにしました。 History Panelのような機能を一つづつ追加するようにしました。\nElasticにジョインしてから、会社の人たちがSenseを使用しているということを聞き、とても幸せでした。 特に、Clintと話をしたときのことを覚えています。 彼は、\u0026ldquo;You know what Sense should do? It should use this format and allow you to have multiple requests in the editor\u0026rdquo; 「Senseになにをすべきかわかる？フォーマットを使うべきだし、エディタで複数のリクエストを持つようにするべきだ」 と言いました。 もちろん、その他のチャレンジも行いました。これは、簡単なものではなく、Aceの詳細を知る必要がありました。 それは新しいAceモード（Aceによって利用されているハイライティングロジック）です。 これは、Senseのサジェストエンジンに密に統合されました。\n次のものが古いSenseのスクリーンショットです。\n画像あり。Figure 1. Sense 0.7 ※画像に関しては原文をご覧ください。\nAPIのURLを入力すると、JSONのボディが入力されます。 うまく切り離すことができ、AceのスタンダードJSONモードを使っていました。 しかし、ここで、次のようなフォーマットをどうやってサポートするか考える必要がありました。\nGET _cluster/health POST index/_settings { \u0026#34;index\u0026#34;: { \u0026#34;number_of_replicas\u0026#34;: 3 } } これは、Aceが3つの異なるものをどうやってパースするかを知る必要があるということです。 HTTPメソッドとURLとJSONボディです。 また、困ったことに、前に説明した前に説明した通り、明らかに別々にはならないものでした。 JSONボディが完全であることを知る唯一の方法はかっこを数えることです。 それは、いくつかの作業とAceのカスタマイズが必要でしたが、それらを切り離すことができました。 そして、Senseのシンタックスが生まれたのです（Thanks Clint!）\nMarvel時代 就業時間中、私の優先すべき仕事はMarvelの開発になりました。 これは、Elasticsearchのための管理と監視のためのソリューションです。 （side note: Marvelは生まれ変わっています。（\u0026quot;Shield, Watcher, and Marvel 2.0.0 GA Released\u0026quot;）） Marvelは開発環境ではフリーなので、MarvelにSenseを組み込むことにしました。 これにより、Senseの開発が日中も行えるようになり、多くのユーザに利用され始めました。 また、Senseは実際に真のJavaScript開発者によって開発されました。 彼は、コードをクリーンにし、ブラウザにおける最新の技術を私に教えてくれました。\nこの期間のSenseは数回書き換えられています。 最も顕著なものは、個別のURLとJSONのサジェストエンジンを書き換えて、 1つのサジェストエンジンにしこれらのコンテキストで動作するようにし、さらに3つ目のコンテキスト（URLパラメータ）を追加したことです。\n新しいエンジンはまた、複数のサジェストコンテキストをメンテナンスするのが簡単になりました。 例えば、_search APIのソートパラメータを考えます。\nGET _search { \u0026#34;sort\u0026#34;: [ \u0026#34;timestamp\u0026#34;: \u0026#34;desc\u0026#34;, \u0026#34;price\u0026#34;: { \u0026#34;order\u0026#34;: \u0026#34;desc\u0026#34;. \u0026#34;missing\u0026#34;: \u0026#34;last\u0026#34; }, \u0026#34;nested_filter\u0026#34;: { \u0026#34;term\u0026#34;: { ... }}, \u0026#34;_score\u0026#34; ] } ユーザがどこにいるかによって、Senseは単純な値（_scoreのような）か、 複雑な構造（orderとmissingのような）やフィルタ（nested_filterのような）も サジェストする必要があります。 これらのサジェストのパスが一度に処理され、無関係なものは除外されます。\nSense 2.0の紹介！ Marvel 1.xはKibana 3.0をベースにしていました。 これは、データの探索やダッシュボードツールとして素晴らしいものでした。 しかし、Kibanaチームはさらに素晴らしいものを出しました。 Kibana 4.xはElasticsearchをバックエンドとするUIアプリを簡単に構築することができる プラットフォームとして設計されています。 実際に、Marvel 2.0はKibanaの プラットフォームで利用できる最初のアプリです。\nSenseの話に戻します。 ElasticsearchのAPIとやりとりする一般的なコンソールです。 これをKibanaのアプリぴったりだと気付きました。 ということで、Sense 2.0をKibanaアプリとしてオープンソースで公開しました。 開発及び本番環境で利用してください。\nFigure 2. Screenshot Sense 2.0 ※画像に関しては原文をご覧ください。\nリリースのハイライト Sense 2.0の新しい機能をここで簡単に紹介します。 （すべての変更点についてはこちらをご覧ください。）\nElasticsearch 2.0 SenseのナレッジベースをElasticsearch 2.0サポートに更新しました。 新しいPipeline aggregationにも対応しています。\n複数リクエストの実行 テストやいくつかの一連のコマンドを繰り返し実行したい時があるでしょう。 その時に、それら全てをSenseに記述し、 実行したいリクエストを選択状態にしてElasticsearchにリクエストできます。\nFigure 3. Submit multiple requests ※画像に関しては原文をご覧ください。\nSenseは、Elasticsearchにリクエストを一つずつ送信し、それぞれの出力結果を右のパネルに表示します。 これは、問題のデバッグや複数のシナリオでのクエリの組み合わせの実行に非常に便利です。\n複数リクエストのコピーペースト 複数リクストを選択し、フォーマットしたり、cURLのコマンドとしてコピーすることも可能です。\nFigure 4. Copy multiple requests as cURL ※画像に関しては原文をご覧ください。\n# Delete all data in the `website` index curl -XDELETE \u0026#34;http://localhost:9200/website\u0026#34; # Create a document with ID 123 curl -XPUT \u0026#34;http://localhost:9200/website/blog/123\u0026#34; -d\u0026#39; { \u0026#34;title\u0026#34;: \u0026#34;My first blog entry\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;Just trying this out...\u0026#34;, \u0026#34;date\u0026#34;: \u0026#34;2014/01/01\u0026#34; }\u0026#39; もちろん、複数のcURLコマンドをコピーしてSenseにペースとすると、Senseはそれらをパースしてくれます。\nまとめ Sense 2.0.0のベータリリースです。 実際に多くの作業が終わった認識です。すぐにGAが出るでしょう。\nSense 2.0を知り、試していただくために、新しいドキュメントを参考にしてください。 バグやリクエストがある場合は、フォーラムやGitHubのIssueに登録をお願いします。\n","date":1446195306,"dir":"post/2015/","id":"5912529cfd6ce14c5ede5c6c83dae7e8","lang":"ja","lastmod":1446195306,"permalink":"https://blog.johtani.info/blog/2015/10/30/sense-2-0-0-beta1-ja/","publishdate":"2015-10-30T17:55:06+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：The Story of Sense - Announcing Sense 2.0.0-beta1 誕生 よくある良いプロジェクト同様、Senseもビールを飲みながら考","tags":["elasticsearch","sense"],"title":"Senseの歴史 - Sense 2.0.0-beta1の紹介(日本語訳)"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Shield, Watcher, and Marvel 2.0.0 GA Released\n本日（10/28）Shield、WatcherおよびMarvel 2.0をリリースしました。 これが、Elasticsearch 2.0に対応したこれらのプラグインの最初のリリースです。\nElasticsearch 2.0対応のほかに、ShieldとWatcher 2.0は、 セキュリティとアラートを拡張するいくつかの新しい素敵な機能も備えています。\nShield 拡張可能なレルム - Sheild 1.xはユーザ認証のコア的なものを定義するのにフォーカスし 3つの認証メカニズム（esusers、LDAP/AD、PKI）を提供しました。 これらを提供することで、多くのユーザおよびユースケースをカバー出来ましたが、 追加の認証メカニズムを統合する必要があることもわかっていました。 ということで、Shieldのレルムベースの認証システムをユーザが利用、拡張できるようにオープンにし、 ユーザ認証を扱うためのレルム実装をプラグインとして拡張できるようにしました。 特定もしくはプロプライエタリな認証メカニズムが必要なユーザもShieldの強力な セキュリティ機能（ロールベースの認証、セキュアな通信など）をフルに活用できるようになりました。 カスタムレルムの詳細については、こちらをご覧ください。\nフィールドとドキュメントのACL - Shield 2.0はフィールドとドキュメントレベルのアクセス制御機能を提供します。 これは、ロールごとにアクセス可能なフィールドやドキュメントを定義できます。 この新しい機能は、設定の変更するよりも便利です。 このアクセス制御はElasticsearchのLuceneインデックスという最も低レベルで実装されています。 その結果として、このメンテナンスがより簡単であるだけでなく、より良くなっています。 詳細についてはこちらをご覧ください。\nユーザなりすまし - Shield 2.0で、ユーザなりすましの機能が実装されました。 これは、ユーザ（適切なパーミッションを持った）が、他のユーザになることができ、 それらのユーザのためにリクエストを実行できます。 これは、Elasticsearch上に構築されたアプリケーションがすでにユーザ認証を行いますが、 認可はElasticsearchサイドで行う必要があるような場合に有用です。 このシナリオで、アプリケーションの\u0026quot;main\u0026quot;ユーザを設定でき、正しくなりすましを割り当て、 ElasticsearchにアプリケーションユーザとしてリクエストをElasticsearchに実行させることができます。 詳細については、こちらをご覧ください。\nWatcher SlackとHipChatインテグレーション - SlackとHipChatはチーム/グループコラボレーションツールです。 これらは、急速に主流になり、組織の主な内部コミュニケーションハブとなっています。 Watcher 2.0はチャンネル/ルームやユーザにこれらのコミュニケーションチャネル経由で、Watchの通知を行うことができるアクションを 実装しました。 slackやhipchatアクションについてはドキュメントをご覧ください。\nArray Compare Condition - 新しいconditionはタイムシリーズのデータのスパイクを検知するのを簡単にします。 compare conditionは1.xで導入されましたが、このコンディションはElasticsearchのダイナミックスクリプト機能を有効にする必要がアンク使えます。 詳細についてはarray_compare conditionをご覧ください。\nWatchの有効・無効化 - ユーザからの多かったリクエストとして、Watchの無効化がありました。 1.xには、登録済みのWatchを無効にする機能がありませんでした。 これは、Watchを消すか、Watchのトリガーを変更することで回避していました。 これは、全体としてはWatchを管理するのを難しくする回避方法でしかありません。 2.0では、APIを呼び出すだけで、Watchの変更をすることなく、簡単にWatchの有効化・無効化が可能になりました。 これは1.0からあるべき基本的な機能でしたが、ついにこの問題を解決しました。 詳細はこちらをご覧ください。\nMarvel Marvel 2.0を紹介するのに興奮しています。 Kibana 4をベースとした、再設計されたUIを持っています。 Marvel 1.xで学んだ多くのことを導入し、より使いやすく監視しやすいUIになっています。 ShieldとWatcherと同様に、最初のMarvelのリリースは将来的な成長の基盤となり Elasticsearch2.0を効率的に管理するための主要なメトリックにフォーカスしています。\n画像あり。 ※画像に関しては原文をご覧ください。\n再設計により、インタフェースを6ページに減らしています。\nCluster list 画像あり。 ※画像に関しては原文をご覧ください。\nユーザやカスタマーの多くは複数のクラスタを利用しています。 新しいMarvelはそれらを集中的にモニタリングする一つのクラスタからそれらを簡単に監視できます。 各クラスタのデータ送信先をこのモニタリングクラスタにするだけです。\nCluster Overview 画像あり。 ※画像に関しては原文をご覧ください。\nクラスタオーバービューはある一つのクラスタの主要な性能メトリックを見ることができ、 素早くスパイクを発見できます。 このページはまた、アクティブなシャードのリカバリやリロケーションも見ることができます。\nIndices List 画像あり。 ※画像に関しては原文をご覧ください。\nインデックスのリストにはクラスタにあるすべてのインデックスとその属性が表示されます。 テーブルはライブでアップデートされ、フィルタリングやソートも可能です。 一番大きなインデックスは？といったことも調べられます。\nIndex Detail 画像あり。 ※画像に関しては原文をご覧ください。\nインデックス詳細ページはインデックスの主な性能メトリックを見ることができ、シャードの配置についても表示します。\nNodes List 画像あり。 ※画像に関しては原文をご覧ください。\nノードリストはクラスタにあるノードとその主な性能メトリックを見ることができます。 テーブルはライブでアップデートされ、フィルタリングも可能です。 高いCPU利用率やディスクの残り容量なども簡単にわかるようになっています。\nNode Detail 画像あり。 ※画像に関しては原文をご覧ください。\nノード詳細ページは個別のノードに関する主な性能メトリックを見ることができ、ノードにあるシャードのリストも見ることができます。\n新しいMarvelはKibana 4の上に構築されたので、管理方法が変わっています。 Marvelのインストールは2つのステップがあります。 marvel-agentとmarvel user interfaceです。\nMarvel Agent marvel-agentはElasticsearchクラスタにプラグインとしてインストールします。 主なパフォーマンス情報を取得し、ローカルもしくは分離されたモニタリングクラスタにデータを保存・送信します。\nMarvel User Interface Marvel UIはKibanaのプラグインとしてインストールします。 これは、Kibana 4.2の新しいプラグインインフラを利用し、 Marvel Appとして、Kibanaのインタフェースとは個別に提供されます。 Kibanaのアプリの切り替えは次の画像の通りです。\n画像あり。 ※画像に関しては原文をご覧ください。\n2.0リリースは私たちのプロダクトの大きな一歩です。またユーザの意見を常にお待ちしています。 ぜひ、Webフォーラム（https://discuss.elastic.co）やメール（info@elastic.co）でご意見を。\n","date":1446189691,"dir":"post/2015/","id":"15700442e957951307bbcec5fff8643d","lang":"ja","lastmod":1446189691,"permalink":"https://blog.johtani.info/blog/2015/10/30/shield-watcher-and-marvel-2-0-ga-released-ja/","publishdate":"2015-10-30T16:21:31+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Shield, Watcher, and Marvel 2.0.0 GA Released 本日（10/28）Shield、WatcherおよびMarv","tags":["elasticsearch","shield","watcher","marvel"],"title":"Shield、Watcher、Marvel 2.0.0 GAリリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 2.0.0 GA released\nElasticsearch 1.0.0のリリース以降、 477のコミッター2,799のpull requestがあった、 **Elasticsearch 2.0.0 GA（Lucene 5.2.1ベース）**をリリースしました。\nそれだけでなく、Shield（セキュリティプラグイン）とWatcher（アラーティングプラグイン）、 新しくなったMarvel（モニタリングプラグイン）（プロダクション環境でフリー！）、 また、新しくオープンソースとなったSense editorの2.0.0もリリースしました。\nElasticsearch 2.0.0のダウンロードはこちらから。 また、2.0.0での重要な変更点についてはこちらをご覧ください。 全ての変更点については、次をご覧ください。\nChanges list for Elasticsearch 2.0.0 Changes list for Elasticsearch 2.0.0-rc1 Changes list for Elasticsearch 2.0.0-beta2 Changes list for Elasticsearch 2.0.0-beta1 商用プラグインについてはこちらです。\nShield 2.0.0 change logs Watcher 2.0.0 change logs Elasticsearchの新機能 Elasticsearch 2.0.0には素晴らしい新機能があります。\nPipeline Aggregations Aggregationsで導関数や移動平均のような他のAggregationの結果に対する計算が可能となります。 この機能はクライアントサイドで実装しなければなりませんでしたが、 Elasticsearchに計算させることで、より強力な解析のクエリを簡単に組み立て、クライアントのコードを簡略化できます。 これは、予測解析や予測解析や例外検知といった可能性をもたらします。 Pipeline Aggregationについては次をご覧ください。\nOut of this world aggregations. Staying in Control with Moving Averages - Part 1. Staying in Control with Moving Averages - Part 2. Query/Filter merging フィルタはもうありません。 全てのフィルタ条件はクエリとなりました。 クエリコンテキストで使用した場合、関連度のスコアに影響し、フィルタコンテキストで使用した場合、 これまでのフィルタのように、ヒットしなかったドキュメントを除外するだけとなります。 この変更はクエリの実行時に自動的に最も効率的な順序で実行するように最適化されることを意味します。 例えば、遅いクエリ（フレーズやgeo）の最初の実行は速い近似フェーズで実行され、 それから、遅い正確なフェーズで結果を修正します。 フィルタコンテキストでは、直近でよく使われた条件が自動的にキャッシュされます。 詳細については、\u0026quot;Better query execution coming to Elasticsearch 2.0\u0026ldquo;をご覧ください。\n設定可能な圧縮率 _sourceのようなStored fieldsは高速なLZ4（デフォルト）で圧縮するか、インデックスサイズを小さくできるDEFLATE で圧縮できます。 これは、特にロギングのケースで便利です。 古いインデックスをオプティマイズする前にbest_compressionに変更することができます。 詳細については\u0026rdquo;Store compression in Lucene and Elasticsearch\u0026ldquo;をご覧ください。\n堅牢に 新しいElasticsearchはJava Security Managerの元で実行されます。 これは、セキュリティの観点で大きな前進です。 Seciruty ManagerはElastcsearchにより制限をかけ、ハッカーによりシステムに対して何でもできるようなものを制限します。 Elasticsearchはまた、インデキシングの観点でも堅牢になっています。\nドキュメントはインデキシングリクエストに答える前に、耐久性のためにディスクにfsyncされます。 すべてのファイルはチェックサムにより、早期に障害を検知します。 すべてのファイルはどんなファイルへの書き込みもアトミックです 最後に、システム管理者から要請の多かった変更として、 設定されて居ないノードがパブリックなネットワークから参加しないようになりました。 Elasticsearchはデフォルトではローカルホストのみにバインドします。マルチキャストは無くなりました。（プラグインとして残っています。）\nパフォーマンスと信頼性 上記以外にも細かな修正がElasticsearchとLuceneにはあります。 より安定し、信頼性をあげ、簡単に設定できるようにするものです。例えば、次のようなものです。\nヒープの使用率の低減（doc valuesがデフォルト、マージ時のメモリ使用率の削減、 roaring bitsetsによるフィルタキャッシュ） 構造化され読みやすくなった例外 設定の代わりに、フィードバックループを使用した自動調整 安全で明確で信頼性のあるタイプマッピングの大きな修正 クラスタ状態の差分変更による伝搬の高速化および、大きなクラスタでのより安定的に normsの圧縮の改善。これまではヒープスペースを大きく利用していた。 マージの自動的な調整（不可解な設定の微調整が必要ない） より詳細なLuceneのメモリリポート 最適化されたクエリ実行を活用するためにParent/childを書き換え コアプラグイン 公式にサポートされたコアプラグインはElasticsearchと同じバージョン番号で同じタイミングでリリースされます。 インストールするプラグインとElasticsearchの複雑なバージョンの対応表に悩まされる必要はもうありません。 コアプラグインのインストールは次のように簡略化されています。\nbin/plugin install analysis-icu ShieldとWatcherの新機能 商用プラグインも新しい機能をリリースしました。\nShield フィールドおよびドキュメントレベルのアクセス制御 ユーザのなりすまし カスタム拡張可能な認証レルム Watcher 個別のWatchを有効/無効に SlackやHipChatへの通知 これらの詳細については“Shield, Watcher, and Marvel 2.0.0 GA Released”をご覧ください。\nコアプラグイン同様、商用プラグインもElasticsearchのバージョンと同じものが同時にリリースされます。 インストールは次の通りです。\nbin/plugin install license bin/plugin install shield bin/plugin install watcher Marvel 2.0.0はプロダクションでの利用もフリーに Marvelモニタリングプラグインはカスタマに非常に価値のあるもので、 ユーザの発展とともに問題を診断したり見つけたりするのに役に立ってきました。 私たちは、何を改善でき、Mαrvelを一から書き直すことで、いろいろとわかったことがあります。\nMarvel UIを新しいKibanaプラットフォーム上に構築 ダッシュボードにはより簡単に問題を発見するために、最も重要なメトリックを可視化 1つのインストールで、複数のクラスタのモニタリングをサポート（商用サポート対象） 一番良い点はMarvelがすべてのElasticsearchユーザに対してプロダクション環境でフリーになったことです！ ライセンスが必要ですが、課金の必要はありません。 もし、マルチクラスタモニタリングサポートが必要な場合、それは商用サポート対象となります。\n詳細に関しては“Shield, Watcher, and Marvel 2.0.0 GA Released”をご覧ください。\nSense editorがオープンソースに Sense（ブラウザベースのElasticsearchリクエストとDSL向けのエディタ）を Kibanaプラットフォームのアプリとして、オープンソースにしました。 また、このリリースで新しい機能が追加されています。\n複数のcURLリクエストをペースとすると、Sense表記に変更 複数のSenseリクエストをcURL表記にしてコピー 複数のリクエストを一度に実行可能 Elasticsearch 2.0サポートとなった自動補完機能 SenseはKibanaのアプリとして次のようにインストールします。\n./bin/kibana plugin --install elastic/sense Senseの詳細については、\u0026quot;The Story of Sense - Announcing Sense 2.0.0-beta1\u0026ldquo;をご覧ください。\nElasticsearch Migration Plugin Elasticsearch Migration PluginはElasticsearch 1.xから2.0にアップグレードする時の良い出発点となります。 1.xのElasticsearchクラスタにサイトプラグインとしてインストールすると、 アップグレードする前に解決すべき問題があるかどうかを検知してくれます。 （例えば、Lucene 3のような古いインデックスや、2.0.0にした場合に動作しない問題のある マッピング（The Great Mapping Refactoring）のような問題）\nプラグインに関してElasticsearch Migration repositoryをご覧ください。\nまとめ ぜひ、Elasticsearch 2.0.0をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)やWebフォーラムなどで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1446103243,"dir":"post/2015/","id":"018e32a8010960eb17e368a6fdd5a51b","lang":"ja","lastmod":1446103243,"permalink":"https://blog.johtani.info/blog/2015/10/29/elasticsearch-2-0-0-released-ja/","publishdate":"2015-10-29T16:20:43+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0 GA released Elasticsearch 1.0.0のリリース以降、 477のコミッター2,79","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0リリース(日本語訳)"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Kibana 4.2.0 released\nElasticsearch 2.0 + Kibana 4.2 = 💚 Elasticsearch 2.0サポートのKibanaの最初のリリースです。 これが何を意味するでしょう？ 速さ、安定さ、新しい機能。 試してみたい方は、いますぐダウンロードしてください。 そうでない方は、Kibana 4.2の楽しい機能について読んでみてください。\n暗黒面は怖い？ そんなことありません。 私たちは常にチャートチャートとダッシュボードを組み立てている組み立てている間は明るいバックグラウンドを使うことを推奨してきましたが、 時々、巨大なスクリーンで暗い部屋で誰も明るい画面から目を背けないようにしたいでしょう。 その影響を小さくするためにダークモードを導入しました。 あなたは、NOCや天文台、その他の暗い場所でKibanaのダッシュボードを楽しむことができます。\n画像あり。 ※画像に関しては原文をご覧ください。\n地図のカスタマイズ Kibanaの地図は素晴らしいですが、もっと多くのオプションが望まれていると聞きました。 もし地図に関して知識があるなら、Kibana 4.2のWMSバックグラウンド地図サポートを試してみてください。 WMSは非常に強力で、US Geological Surveyを含む多くの無料サービスがあります。 http://viewer.nationalmap.gov/example/services/serviceList.html\n画像あり。 ※画像に関しては原文をご覧ください。\nシナリオは？ 何かおかしい時、何が起こっているかを正しく知ってもらいたいので、Kibanaがそのタイミングで注目したいコンポーネントがあるなら、 どのように動いているかという概要を知るためのサーバステータスページを作りました。 もちろん、全てがOKであるというのを知りたいだけの場合でも、settingメニューのStatusタブからいつでも呼び出せます。\n画像あり。 ※画像に関しては原文をご覧ください。\n全てにおいて速く ブラウザリフレッシュはKibana 4.2の新しいコードビルディングシステムのおかげで、さらに早くなりました。 また、メモリを覚えてます？Pepperidge FarmKibanaが覚えています。 Kibana 4.2は小さな小さな小さなメモリフットプリントを管理している間、長い長い長い時間実行されているダッシュボードを見ることができるような 大きなメモリのクリーンアップも含んでいます。\nもっとありますが。。。 小さな微調整がいくつもあります。また、今後紹介する本当に刺激的なものの基礎を気づき上げてきました。 これからもElasticのブログ、Twitter、KibanaのGitHubリポジトリに注目し、モンスタートラックアナリティクスの瞬間に立ち会ってください。\n","date":1446103219,"dir":"post/2015/","id":"e159a35d1b9a46e03072a3d54780edcb","lang":"ja","lastmod":1446103219,"permalink":"https://blog.johtani.info/blog/2015/10/29/kibana-4-2-0-ja/","publishdate":"2015-10-29T16:20:19+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Kibana 4.2.0 released Elasticsearch 2.0 + Kibana 4.2 = 💚 Elasticsearch 2.0サポートのKibanaの最初のリリースです。 これ","tags":["elastic","kibana"],"title":"Kibana 4.2.0リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Logstash 2.0.0 released\nLogstash 2.0.0が本日（10/28）リリースされました。 このリリースは いくつかの設定に関する重要な変更があります。 詳細については、changelogまたは、新しいbreaking changesドキュメントをご覧下さい。\nこれまでの2.0.0直前のリリースに関する変更点はこちらをご覧ください。\nbeta1 beta2 beta3 RC ここでは、2.0の主な変更点の概要を説明します。\nElasticsearch 2.0との互換性 多くの機能および改善を含んだElasticsearch 2.0がリリースされました。 Logstash 2.0はこのリリースに対応しています。 Logstashのこれまでのリリースでは、デフォルトで、Javaの node clientをElasticsearchとの通信として 使用してきました。 2.0では、HTTPクライアントがデフォルトになります。 これにより、シームレスにユーザのデータを取り込み、付加価値をつけ、Elasticsearchに保存して解析することができます。\nHTTPは他のプロトコル（nodeやtransport）同等の機能を持っていますが、 単一のクライアントに接続する時に、少しだけ遅いですが、管理や動作がより簡単です。 HTTPプロトコルを使うことで、Elasticsearchのバージョンのアップグレードが、Logstashのアップグレードすることなく 行うことができます。 デフォルトをHTTPに変更したさらに詳しい情報についてはbeta1のブログをご覧ください。\n他のプロトコル（nodeとtransport）もサポートしますが、これらを利用する場合には、 プラグインを別途インストールする必要があります。\nbin/plugin install --version 2.0.0 logstash-output-elasticsearch_java 互換性のマトリックス LogstashとElasticsearchのバージョンの互換性は次のようになります。\n画像あり。 ※画像に関しては原文をご覧ください。 #Image https://www.elastic.co/assets/bltde5b69e2164aa82f%2Fcompat_matrix.png\nShield 2.0との互換性 このリリースはShield 2.0リリースにも対応しています。 HTTPプロトコルで、追加のプラグインは必要ありません。 こちらのドキュメントをご覧ください。 transportプロトコルでは、Shield 2.0対応のプラグインを個別にインストールする必要があります。\nbin/plugin install --version 2.0.0 logstash-output-elasticsearch_java_shield パフォーマンスの改善 このリリースはまた、多くの部分のパフォーマンスの改善を含んでおり、Logstashを利用してデータをより早く処理することができます。 いくつかをここで説明します。\nUserAgentとGeoIPフィルタ：これらのフィルタで、LRUキャッシュを追加して改善しています。 これにより、IPとユーザエージェントがまとまって現れるというWebリクエストの特性を用いています。 ユーザエージェントフィルタのケースでは、サンプルデータセットにおいて3.7倍ほど早くなりました。 GeoIPでは、1.69倍早くなっています。\nJSONプロセシング：LogstashでJSONのsiriaraizu/でシリアライズに利用しているJrJacksonを新しいバージョンにしました。 これにより、JSONの処理が改善されています。\nフィルタワーカーのより良い値をデフォルトに：以前のリリースでは、filter_workersの設定は1がデフォルトでした。 これは、フィルタの処理を行うワーカーが1つであるという意味です。 filter_workersの設定のデフォルト値はCPUコア数の半分の値を設定します。フィルタ実行の並列性が上がります。 ですので、複雑なgrokパターンやuseragentフィルタの処理がにとっては重要です。\nFilebeat Support Filebeatのベータバージョンを先日リリースしました。 これは、Logstash Forwarderの次期バージョンです。 Filebeatはファイルベースのログをさらに処理するためにLogstashに送るためのエージェントです。 2.0.0はlogstash-input-beatsプラグインを使えばFilebeat 1.0.0-beta4とすぐに動作します。\nシャットダウン操作 これまでのLogstashでは、シャットダウンが開始した時に、例外の機構でシャットダウンが開始したことを プラグインに通知していました。 この処理はサードパーティのコードを使ったプラグインで問題を起こしていました。 Logstashはどの例外を処理するか知らないため、予期しない動作をしていました。 これを修正するためにAPI呼び出し（例えばstop）を各プラグインにシャットダウンのイベントを通知し、 プラグイン自身がきちんと停止するようにしました。 これは、200以上のプラグインに新しいAPIを利用するように修正しないといけないことを意味しました。 しかし、Logstashの停止についてはまだ完全にはフィックスしていません。 とちゅうでおわっているoutputがシャットダウンを遅らせる可能性があるからです。 2.0でAPIの破壊的な変更は適切なリリースでの変更を繰り返すことができる出発点です。\nプラグインの開発者へ：もし、Logstash　1.5のプラグインを開発しているなら、 シャットダウンに関する新しいAPIのリストに関するbreaking changesのドキュメントに助言をください。 また、example inputリポジトリにて、新しいシャットダウンメカニズムの使い方のサンプルコードを提供しています。\nドキュメント 2.0に更新されたドキュメントはこちらです。設定の変更についてもこちらをご覧ください。\n2.0へのアップデート 2.0へアップデートする前に、アップデートガイドもご覧ください。\nフィードバック 2.0のリリースできたことに、多くのコントリビューター、ユーザに感謝しています。 このリリースに含まれている多くのパッチと全てのプレリリースのテストにも感謝しています。 将来の修正やリリースなどについてはロードマップをご覧ください。 2.0は今日リリースされました。 ご意見ご感想はWebフォーラムで！\n","date":1446103197,"dir":"post/2015/","id":"cc64c2fcdecdb505b3797e1aaaa59adc","lang":"ja","lastmod":1446103197,"permalink":"https://blog.johtani.info/blog/2015/10/29/logstash-2-0-0-released-ja/","publishdate":"2015-10-29T16:19:57+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Logstash 2.0.0 released Logstash 2.0.0が本日（10/28）リリースされました。 このリリースは","tags":["elastic","logstash"],"title":"Logstash 2.0.0リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Relase, we have ※画像に関しては原文をご覧ください。\nElasticにとって大きな1日（社内では「release bonanza」と呼んでいる）です。 多くの主要なプロダクトを新たにリリースしました。 そして、本日、それらを一緒に利用する時にそれらを一緒に利用する時にユーザの体験についてまとめてみました。\n次の通りです。\nElasticsearch 2.0リリース。 大きなマイルストーン、チームによる改善、そして、コミュニティからの素晴らしい貢献。 Pipeline Aggsと呼ばれる新しいタイプのaggregations、 クエリとフィルタのコンセプトを統合することにより簡素化されたクエリDSL、 better compressionオプション、 JavaのSecurity Managerを有効にすることによる強化されたセキュリティ、 FSの挙動に関する強化（fsync、checksum、atmicなリネーム）、 パフォーマンス、マッピングの挙動の一貫性などなどです。 また、我々のチームによる改善も含まれているLucene 5ベースにアップグレードしています。\nKibana 4.2リリース。 Elasticsearch 2.0対応、ダークテーマ、カスタマイズ可能な地図、多くの改善。 Kibana 4.2の多くに作業については外部プラグインサポートといった、内蔵に関するものでした。 この後の説明に続きます。\nMarvel 2.0リリース。 Elasticsearch 2.0対応、合理化されたメトリックス、簡素化されたUI、 多くはKibanaプラグイン（Kibanaプラットフォーム上に構築）としての書き換えです。 このKibana拡張の最初の努力は、Kibanaのプラグインをどうやって書くか、 Kibanaユーザに公式に何をする必要があるかといったものを特定するのに役立ちました。 おっと、忘れるところでした、Marvelを全てのユーザにフリーで使えるようにしました。 マルチクラスタサポートについては有償となります。\nSense 2.0リリース。 2つ目のKibanaプラグインがこれです。 SenseをKibanaプラグインとして書き換えました。 Elasticsearch 2.0サポート、複数リクエストの実行、 curlへのコピーなどです。 おっと、忘れるところでした。オープンソースとすることにしました！\nShield + Watcher 2.0リリース。ElasticsearchのためのセキュリティプラグインであるShieldと、アラート管理のためのプラグインであるWatcherにも 多くの結果が入っています。 最も要求のあった機能である、フィールドお呼びドキュメントレベルでのセキュリティについて、Luceneに落とし込んで実装しました。 また、セキュリティの操作についてプラガブルに実装できるように変更しました。 Watcherは監視の無効化、SlackやHipChatへの通知（bot ops向け）が可能です。\nLogstash 2.0リリース。 Elasticsearch 2.0のサポート、クリーンな停止、全面的なパフォーマンス改善、Beatsサポート。\nご覧の通り、すべてのプロダクトに関する大きな結果です。 チーム間およびFoundの開発者との間での密な連携に感謝します。 これらが私たちが公式にElasticsearch / KibanaをホストしているFoundで 利用可能です。\nひゅう、息切れしました。 チームがしてきたことは、感動的で、謙虚で、刺激的です！ Elasticが会社として、全てのユーザ、コントリビュータがどのように私たちの大きなミッションに対する結果をもたらしたかという素晴らしい良い例です。 ユーザに愛され、楽しまれ、成功に導き、革新させる製品を是非ご利用ください。ありがとうございます。\n\u0026ldquo;A Lion, in Africa?\u0026rdquo; - まだまだ終わりではありません。この文言で終わりにしますが、すぐに（本当にすぐに）戻ってきます。;)\n","date":1446095939,"dir":"post/2015/","id":"4cc08ca51ecf0f963035f039de6194c5","lang":"ja","lastmod":1446095939,"permalink":"https://blog.johtani.info/blog/2015/10/29/release-we-have-ja/","publishdate":"2015-10-29T14:18:59+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Relase, we have ※画像に関しては原文をご覧ください。 Elasticにとって大きな1日","tags":["elasticsearch","kibana","logstash"],"title":"Release, we have（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 2.0.0-beta2 released\n本日（9/17）、Lucene 5.2.1ベースのElasticsearch 2.0.0-beta2をリリースしました。 本リリースが2.0.0のRCの前の最後のベータリリースになります。\n注意事項 本リリースはベータリリースであり、テストを目的としたものとなります。 Elasticsearch 2.0.0-beta2はElasticsearch 2.0.0-beta1と互換がありません。 また、Elasticsearch 2.0.0 GAと互換性があるかどうかの保証はありません。\n本番環境には利用しないでください。\nElasticsearch 2.0.0-beta2のダウンロードおよび、すべての変更についてはリンクをごらんください。\n2.0.0-beta1をテストし、問題点を報告していただいた皆様、ありがとうございます。 2.0.0-beta1のあとのElasticsearchのコアの部分の修正のほとんどはバグフィックスになりますが、 geo_shapeフィールドのpoints_only最適化のようなちょっとした改善も含んでいます。\nまた、本リリースでは、商用プラグインの重要な新機能もあります。 こちらについてはShield and Watcher 2.0.0-beta2 releasedをごらんください。 簡単な紹介は次の通りです。\nShieldの新機能 ドキュメントおよびフィールドレベルのセキュリティ Shieldは、クエリを利用したインデックスにあるドキュメントへのアクセスを制御するためのロールを定義できるようになりました。 また、ドキュメントにある特定のフィールドに関するアクセス制限も可能です。 フィルタされたエイリアスのような形ではなく、ドキュメントを検索したり、IDで取得したりする場合にこれらの制限が利用できます。 詳細はField- and Document-level Securityをごらんください\nユーザなりすまし 特定のユーザーに他のユーザーに扮して、彼らのためにリクエストを実行する能力を与えることが、現在できます。 これは、認証がアプリケーションによって実行される場合に便利です。 そして、それは、ユーザの許可レベルを考慮するようにElasticsearchにリクエストします。 詳細はSubmitting Requests for Other Usersをごらんください。\nプラガブルな認証レルム このリリースで、サードパーティの拡張のための認証レルムのインフラを公開しました。 もし、特定の認証要求があり、Shieldがサポートしていない（が、内部の認証管理システムを使いたいような）場合、 これらの要求に見合う新しい認証レルムを利用するプラグインを作成可能です。 詳細はCustom Realmsをごらんください。\nWatcherの新機能 監視の一時 新しく、active / inactive の状態がwatchに追加されました。 これらは、Watchを中断したり、要求に応じて再開させたりできます。 詳しくは、Active Stateをごらんください。\nチャットのための新しいアクション slackとhipchatアクションが追加されました。 これは、Watcherが通知を、SlackやHipchatのユーザに直接送ったり、 チームのチャットルームに送ったりすることが出来るようにします。 詳細については、Slack actionおよび、Hipchat actionをごらんください。\n2.0に関するこれまでのブログ記事 これまでのリリースについての情報はこれらのブログ記事をごらんください。\n\u0008* Elasticsearch 2.0.0.beta1 released\nElasticsearch 2.0.0.beta1 coming soon! The Great Mapping Refactoring Store compression in Lucene and Elasticsearch Better query execution coming to Elasticsearch 2.0 Out of this world aggregations Staying in Control with Moving Averages - Part 1 Staying in Control with Moving Averages - Part 2 The Delete by Query API Is now a plugin Elasticsearch unplugged - Networking changes in 2.0 また、Elasticsearch 2.0.0-beta2のドキュメントや2.0のbreaking changesのリストもごらんください。\nElsticsearch Migration Plugin Elasticsearch Migration Pluginは、既存のインデックスをアップグレードする 必要があるか、他に必要な行動がないかについて、Elasticsearch 2.0.0-beta2を試す前に確認する助けとなります。 Lucene 3のような古いインデックスや、2.0.0にした場合に動作しない問題のある マッピングのような問題を発見できます。\nプラグインの動作に関しては[Elasticsearch Migration repository](Elasticsearch Migration repository)をごらんください。\nテストしましょう！ Elasticsearch 2.0.0 GAをすぐにリリースできるようにより多くのベータテスターをお待ちしています。\nぜひ、Elasticsearch 2.0.0-beta2をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)やWebフォーラムなどで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1442565101,"dir":"post/2015/","id":"4b227d61f33182579cd3edd0ac6c7c44","lang":"ja","lastmod":1442565101,"permalink":"https://blog.johtani.info/blog/2015/09/18/elasticsearch-2-0-0-beta2-released-ja/","publishdate":"2015-09-18T17:31:41+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0-beta2 released 本日（9/17）、Lucene 5.2.1ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0-beta2リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch unplugged - Networking changes in 2.0\nElasticsearchをローカルのマシンで起動します。 そして、昨日試したデータを削除するためにDELETE *を実行します。 すると、悲しそうな叫びを同僚が発していることに気づき、なぜそんなことになっているのか不思議に思うでしょう。。。\nElasticsearchはいつも、親しみやすいものでした。 複数ノードのクラスタがどのように機能するのかをテストするには、 ローカルのマシンでいくつかのElasticsearchのインスタンスを起動するだけでした。 起動したインスタンスはマルチキャストを利用して自動的にお互いを見つけて、1つのクラスタになり、負荷を共有し始めます。 しかし、これは親しみやすすぎました。 カンファレンスなどで、ローカルのマシンでElasticsearchを起動してみてください。 すると100ノードのクラスタに参加しているのがすぐにわかるでしょう。\nもうすぐリリースされる、2.0.0-beta1では、Elasticsearchが通信先を選択するネットワークの機能に関する変更があります。 ただし、これまで通り、簡単に開発者が経験できる機能も残っています。\nlocalhostへのバインド 以前、Elasticsearchはデフォルトで、利用可能なネットワークインタフェース全てにバインドしていました。 そこから、一番適したインタフェースをpublish_hostとして選択しようとします。 このアドレスはElasticsearchがクラスタの他のノードとやりとりするためのアドレスです。\nElasticsearch 2.0では、デフォルトでは、localhostにのみバインドします。 127.0.0.1（IPv4）と[::1]（IPv6）の両方にバインドしようとします。 また、どちらかのみの環境でも動作します。 この変更は、特に指定がない限り、Elasticsearchがネットワーク上の他のノードと接続しません。 本番環境に移行する場合は、network.hostパラメータを使って設定しましょう。 設定は、elasticsearch.ymlに記述するか、コマンドラインで指定します。\nbin/elasticsearch --network.host 192.168.1.5 bin/elasticsearch --network.host _non_loopback_ network.hostの全てのオプションについては、network settingsのドキュメントをごらんください。\nマルチキャストは廃止 Elasticsearch 1.xはネットワークの他のノードに接続・探索するためにマルチキャストを使用しました。 マルチキャストは魔法のような挙動です。。。 残念ながら、マルチキャストのサポートは良くも悪くもあります。 Linuxはローカルホストでマルチキャストの待ち受けをしていません。 OS/Xは構成されたアドレスの全てのインタフェースにマルチキャストで配信できます。 また、ネットワークによってはマルチキャストはデフォルトでは使用できなくなっています。\nElasticsearch 2.0は異なるアプローチを採用しました。 マルチキャストを廃止します（ただし、新たにプラグインとして提供します）。 代わりに、ローカルホストでは、Elasticsearchはtransport.tcp.portで指定されている範囲（デフォルトは9300-9400）の最初の5ポートに対してユニキャストを使用できるようにします。\nこれは、開発者のための、設定することなく自動的にクラスタを組むという機能を残しています。 しかし、本番に移行するときは、unicast hostsで次のようにリストを指定する必要があります。\ndiscovery.zen.ping.unicast.hosts: [ 192.168.1.2, 192.168.1.3 ] unicast hostsとしてクラスタにあるノードの全てのリストを指定する必要はありません。 少なくとも、マスタノードとして選出されるべきものを指定します。 巨大なクラスタでは、3つの専用のマスタノードを持っており、この3つをunicast hostsとして設定することを推奨しています。\nこれにより、開発の知識・経験が、私たちの推奨する本番でのネットワーク設定に、より近いものとなります。\nノード情報の変更 最後に、inet[/127.0.0.1:9200]といったシンタックスを廃止します。 これは、Elasticsearchがnodes-info APIなどで、使用していたIPアドレスのためのシンタックスです。 今は、RFCに準拠した形で表示します。 127.0.0.1:9200（IPv4）や[::1]:9200（IPv6）のようにです。\n質問がある場合は、ElasticsearchのWebフォーラムで質問してください。ベータはもうすぐです！（翻訳した時点で、すでにベータリリースされています。）\n","date":1440730890,"dir":"post/2015/","id":"0de0edbf2a506143c1739b12e94c0ef9","lang":"ja","lastmod":1440730890,"permalink":"https://blog.johtani.info/blog/2015/08/28/elasticsearch-unplugged-ja/","publishdate":"2015-08-28T12:01:30+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch unplugged - Networking changes in 2.0 Elasticsearchをローカルのマシンで起","tags":["elasticsearch"],"title":"Elasticsearch unplugged - 2.0におけるネットワークの変更(日本語訳)"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 2.0.0-beta1 released\n本日（8/26）、Lucene 5.2.1ベースのElasticsearch 2.0.0-beta1をリリースしました。 本リリースは469名のコミッターからの2,500以上ものpull requestを含んでいます。 pull requestのうち、約850が2.0のための新規のものとなります。\n注意事項 本リリースはベータリリースであり、テストを目的としたものとなります。 Elasticsearch 2.0.0-beta1は Elasticsearch 2.0.0 GAと互換性があるかどうかの保証はありません。\n本番環境には利用しないでください。\nElasticsearch 2.0.0-beta1のダウンロードおよび、すべての変更についてはリンクをごらんください。\nElasticsearch 2.0.0-beta1には次の新しい変更が含まれています。\nPipeline Aggregations：これは、他のaggregationsの結果に対するAggregationを実行できます（導関数、移動平均、Holt Winter予測アルゴリズムなども含む） ディスクやファイルシステムキャッシュにより適したより良いデータの圧縮 doc-valuesがデフォルトになったこと、マージ実行時のメモリ使用量の低減、フィルターキャッシュのためのroaring bitsetsなどにより、ヒープの使用率がより効率的に。 構造化された例外 最適化されたクエリ実行順序、フィルタの自動キャッシュ、より高速なクエリに書き換えられたparent-child 設定の代わりに、フィードバックループを使用した自動調整 トランザクションログへの書き込みがデフォルトで、アトミックでかつ冗長に 安全で明確で信頼性のあるタイプマッピング デフォルトでローカルホストでのみクラスタを構成 クラスタ状態の差分によりより高速に変更を伝搬 上記の変更以外にも、多くのElasticsearchおよびLuceneに対する継続的な変更が含まれています。 これらは、Elasticsearch 2.0をより安全に、より簡単に、より良いものにしています。 本リリースに関するより詳しい情報が次のブログにあるので、参考にしてください。\nElasticsearch 2.0.0.beta1 coming soon! The Great Mapping Refactoring Store compression in Lucene and Elasticsearch Better query execution coming to Elasticsearch 2.0 Out of this world aggregations Staying in Control with Moving Averages - Part 1 Staying in Control with Moving Averages - Part 2 The Delete by Query API Is now a plugin Elasticsearch unplugged - Networking changes in 2.0 また、Elasticsearch 2.0.0-beta1のドキュメントも参考になります。 特に、2.0での重大な変更点については必ずごらんください。\nCore plugins コアプラグインの開発の方法を変更しました。 公式にサポートしているプラグインは、現在elasticsearchのリポジトリに含まれています。 これにより、コアと一緒にテストされ、Elasticsearchと同じタイミングでリリースされます。 コアプラグインはElasticsearchと同じバージョン番号隣ます。 インストールは次のようになります。\nsudo bin/plugin install analysis-icu プラグインの新しいドキュメントは私たちのWebサイトのGuideにあります。\nCommercial plugins 私たちの商用プラグインもElasticsearchと同じバージョン番号となり、Elasticsearchと一緒にリリースされます。 ShieldやWatcherはすでに2.0.0-beta1が利用可能です。 インストールのコマンドはは次のようになります。\nsudo bin/plugin install license sudo bin/plugin install shield sudo bin/plugin install watcher MarvelおよびSenseに関する新しい情報もありますが、もう少しお待ちください。\n2.0.0-beta1の商用プラグインに関するドキュメントは次のリンクからごらんください。\nShield 2.0.0-beta1 Watcher 2.0.0-beta1 Elasticsearch Migration plugin Elasticsearch 2.0.0-beta1を試す前に、 既存のインデックスのアップグレードするためになにか行う必要があるかどうかを確認するためのElasticsearch Migration Pluginもリリースしました。 2.0.0では機能しない、問題のあるマッピングなどを見つけるために便利なプラグインです。\nこのプラグインの利用方法についてはElasticsearch Migration repositoryをごらんください。\n既知の問題 同じインデックスの異なるタイプに、同じ名前のipタイプのフィールドを追加した時に、問題があることがわかっています。 この問題は次のリリースでフィックスされます。詳細は#13112をごらんください。\nテストしましょう！ Elasticsearch 2.0.0 GAをすぐにリリースできるようにより多くのベータテスターをお待ちしています。\nぜひ、Elasticsearch 2.0.0-beta1をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)やWebフォーラムなどで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1440638952,"dir":"post/2015/","id":"744554499cb7880086fbd9b1f080e7e1","lang":"ja","lastmod":1440638952,"permalink":"https://blog.johtani.info/blog/2015/08/27/elasticsearch-2-0-0-beta1-released-ja/","publishdate":"2015-08-27T10:29:12+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0-beta1 released 本日（8/26）、Lucene 5.2.1ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0-beta1リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：The Delete by Query API Is now a plugin\nElasticsearchの2.0.0-beta1では、これまであった Delete by Query APIが削除され、 新しく Delete by Query pluginに置き換えられています。\nもし、Delete by Query を利用する場合、2.0にアップグレードしたあとは、プラグインをインストールし、ドキュメントに従ってください。\nbin/plugin install delete-by-query なぜプラグインに？ ElasticsearchのコアなAPIの品質を保つためであり、以前のDelete by Queryの実装は簡単にはフィックスできない大きな問題がありました。\n各リクエストのあとに、refreshを実行します。これは、削除されたデータが想定外に検索に出てこないようにするためです。\nまた、セグメントが大量にでき、マージが大量に発生し、ヒープが大量に消費されてインデキシングが劇的にスローダウンし、クラスタの複数のノードがクラッシュしてしまう状況も引き起こしました。 このクエリは、プライマリ、レプリカの両方で実行されるため、ことなるドキュメントを削除し、矛盾したレプリカ（データの破損）を引き起こしました。 アップグレードが不安定になります。これは、Delete by Queryリクエストがトランザクションログの中にクエリとして残るためです。そのため、アップグレードのあとに正確にパースされなかったり正確に実行されないかもしれません。例えば、インデックスエイリアスに対するリクエストで、それが削除された後の場合にこのようなバグが発生します。 対照的に、新しいプラグインは、安全な実装です。 scanとscrollリクエストでクエリにマッチしたIDを見つけ、そのIDを使って、bulk indexing APIで削除します。\nこの実装は、遅い必要があります。特に、クエリが多くのドキュメントを削除する場合です。 もし、多くのドキュメントをこのAPIを利用して削除する場合、アプリケーションをテストしてください。 そして、代わりにインデックス全体を消すようなアプローチに切り替えることができないか検討してください。\nDelete by Query pluginのドキュメントに、新しい実装についての違いなどのより詳しい説明があります。\nElasticsearch coreを最小限に プラグインに切り替えることは、簡単な決断ではありませんでした。 多くのユーザは問題なく、Delete by Queryを利用していました。 しかし、危険が常にそこにあり、些細とは言い切れない数のユーザが上記のような深刻な問題に遭遇していました。\nさらに、Elsticsearchのコアは信頼できるものでなければなりません。 他のコアAPIを利用して実装できる機能は、コアに含みません。特に、それがバグを含んでいる場合。 コアのすべての機能は強固であるべきで、Delete by Queryは人気があり、高性能ですが、そうではありませんでした。\n必要に応じて、このような難しいトレードオフの末、信頼性と品質を選びます。\nマッピングの削除の廃止 タイプのマッピングを削除する機能も2.0で廃止されます。 これは、同じフィールド名を、異なるフィールドのタイプで再利用した場合に、インデックスの破損を引き起こす可能性があるためです。\nしかし、Match All Queryで、Delete by Queryプラグインに対してタイプを指定することで、タイプのすべてのドキュメントを削除することはできます。 または、1つのインデックスに異なるタイプを複数含める代わりに、個別のインデックスに分割するようなアプローチに変更することを検討してください。\n","date":1440044644,"dir":"post/2015/","id":"5a9e950f4ac186925e5de978c5f72062","lang":"ja","lastmod":1440044644,"permalink":"https://blog.johtani.info/blog/2015/08/20/core-delete-by-query-is-a-plugin-ja/","publishdate":"2015-08-20T13:24:04+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：The Delete by Query API Is now a plugin Elasticsearchの2.0.0-beta1では、これまで","tags":["elasticsearch"],"title":"Delete by Query APIはプラグインへ（日本語訳）"},{"contents":"第11回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズさん、そして、Shayありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n今回は、CTOのShayが来日していたので、英語でいろいろと喋ってもらいました。 4月同様、サムライズムの@yusukeさんに テキスト翻訳していただき、大変助かりました。 今回はQAベースのトークだったのでちょっときつかったですね、申し訳ない。。。\nチェックイン数など チェックインした人：141名 キャンセルしなかった人：51名 でした。 今回はあらかじめ220名（全員が来たらキャパオーバー）としていたので、キャンセル待ちの人は 当日の午後にはいなくなっていた状態です。まぁ、こんなもんかな。結構入りましたね。ありがたいです。\nLT 今回は、少し趣向を変えて、4社の方達にLTをしていただきました。 Shayが来日しているのもあり、事前に英語でスライドを作っていただけると助かりますとお願いさせていただきました。 英語でスライドを作っていただいていたので、伝わりやすくて助かりました、スピーカーの方々ありがとうございました！\n（海外のユーザにもリンクを紹介しやすいので、英語でスライド作ってもらえるといろいろと知ってもらえるのかも。）\nElasticsearch and Recruit Technologies Co., Ltd. / 株式会社リクルートテクノロジーズ　守谷 純之介さん スライド：未定\nN-Gramと形態素のハイブリッドの話などをしていただきました。 @ITで連載もされてますね。ありがとうございます。\nリクルート全社検索基盤のアーキテクチャ、採用技術、開発体制はどうなっているのか (1/2) ElasticsearchとKuromojiを使った形態素解析とN-Gramによる検索の適合率と再現率の向上 (1/3) Shayからは、elasticsearch-hadoopがあるから検討してねと質問（お願い？）がありましたw。\nElasticsearch as a DMP / 株式会社インティメート・マージャー　松田和樹さん　@mats116 スライド：Elasticsearch as a DMP\nいくつかのデータソースからAEROSPIKE経由でelasticsearchにデータを登録しているようです。 Data Management Platformのエンジンの一部として、elasticsearchを利用しているようです。\nShayからの質問：「どの機能を使って関心のある単語を抽出していますか？」\n回答：「Significant Term Aggregation」です。\nShay：「おぉ、チェックしてみますw」。\nReal-time social big data analytics using elasticsearch / 株式会社ホットリンク宮田洋毅さん　@kakka_jp スライド：未定\nソーシャルメディアのデータを解析するのにelasticsearchにデータを入れて解析。 時間軸での解析やテキストマイニングなんかをしているみたいでした。 いろいろと独自のプラグインを作ってるようです。（興味あるなぁ）\nShayからの質問：「ノード数は？」「30ノードで30シャード」\nElasticsearch in Hatena Bookmark / 株式会社はてな　id:skozawa スライド：Elasticsearch in Hatena Bookmark\nはてなブックマークの検索の歴史（MySQL -\u0026gt; Sedue -\u0026gt; Solr -\u0026gt; Elasticsearch） はてなブックマークの検索（ユーザが利用）と社内利用と、ログ解析で利用してる Shayからの質問：「昨年会いましたよね？今はクラスタのサイズはどのくらいのサイズですか？」「メインクラスタは9データノード」\nOpen QA with Shay 思い出せるものだけ。。。（あとで追記します）\nElasticsearch 2.0の話 Pipeline Aggregationとか。 Spark Streaming対応してる？ まだ検討中 elasticsearch-hadoopってどんなもの？HDFSにインデックス作ったりするの？ いえ、Hadoopの入出力先としてelasticsearchが使える感じ 個人的にAWSのCloudSearchとAWSでElasticsearchはどっちがいい？ 時系列データはCloudSearchだと難しいだろうし、AWS上ならfound.noがあるよ！ PostgreSQLみたいに信頼性の高いデータストアを目指してる（まだ、プライマリデータストアには使わないで） その他、感想などのブログ Elasticsearch勉強会でLTしてきました | Intimate Merger Engineer Blog 『第11回elasticsearch勉強会』のまとめ #elasticsearchjp \u0008* [Elasticsearch] 第11回 Elasticsearch 勉強会へ参加してきた - 雑文発散(2015-07-28) 第11回 Elasticsearch 勉強会に参加したら英語力に危機感を覚えて最高だった まとめ 今回はShayが来日したので特別バージョンでした。 もっと英語を翻訳するサポートしないとですね、反省してます。。。ぜんぜん流暢じゃないしw\n次回は9月に開催予定ですが、12月にまたShayが再度来日する予定です。 丸1日のイベントを検討中で、Shay以外にも開発者が来日すると思います。 どんな話が聞きたい、どんな人と話をしたいなどあれば、コメントいただければ（対応できるかは。。。）\n勉強会のスピーカーは随時募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1438321313,"dir":"post/2015/","id":"73b8194ad8fce0cabb01cd21d5e18500","lang":"ja","lastmod":1438321313,"permalink":"https://blog.johtani.info/blog/2015/07/31/11th-elasticsearch-jp/","publishdate":"2015-07-31T14:41:53+09:00","summary":"第11回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第11回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.7.1 and 1.6.2 released\n本日（7/29）、Lucene 4.10.4ベースのElasticsearch 1.7.1およびElasticsearch 1.6.2 のバグフィックス版をリリースしました。 これらのリリースは稀ですが、データの欠損が発生する重要なバグのフィックスを含んでいます。 すべてのユーザにアップグレードを推奨します。\nダウンロードおよびすべての変更については次のリンクをごらんください。\n最新安定版：Elasticsearch 1.7.1 1.6系バグフィックス：Elasticsearch 1.6.2 問題のバグ(#12487)は、 同時に複数のノードが故障またはリスタートをした場合の非常にまれな状況で、 シャードのすべてのコピーがクラスタから削除されてしまう状況を発生させます。 このバグは1.5.0から含まれています。\nこのリリースはまた、IPv4アドレスのCIDRマスクのバグのフィックス、 Shieldユーザがmore-like-this APIを利用できないバグのフィックスなど、 いくつかの変更も含んでいます（詳細は更新リストをごらんください）。\nぜひ、Elasticsearch 1.7.1をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1438173353,"dir":"post/2015/","id":"100c0a69bea7f02a0f4540ecaa37d0e3","lang":"ja","lastmod":1438173353,"permalink":"https://blog.johtani.info/blog/2015/07/29/elasticsearch-1-7-1-and-1-6-2-released-ja/","publishdate":"2015-07-29T21:35:53+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.1 and 1.6.2 released 本日（7/29）、Lucene 4.10.4ベースのE","tags":["elasticsearch"],"title":"Elasticsearch 1.7.1 および 1.6.2リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.7.0 and 1.6.1 released\n本日（7/16）、Lucene 4.10.4ベースのElasticsearch 1.7.0およびElasticsearch 1.6.1 のバグフィックス版をリリースしました。 これらのリリースはセキュリティフィックスを含んでおり、すべてのユーザにアップグレードを推奨します。\nダウンロードおよびすべての変更については次のリンクをごらんください。\n最新安定版：Elasticsearch 1.7.0 1.6系バグフィックス：Elasticsearch 1.6.1 1.7.0が1.x系の最後のリリースとなります。 今後の新機能については、Elasticsearch 2.0以降で取り込まれる予定です。\nElasticsearch 1.7.0は小さなリリースですが、2つの重要なセキュリティフィックスと クラスタの安定化とリカバリに関する2つの重要な機能を含んでいます。\nセキュリティフィックス シャードアロケーションを遅らせる インデックスリカバリの優先度 セキュリティフィックス Elasticsearch 1.6.1 と 1.7.0 は次の2つのセキュリティフィックスを含んでいます。\nリモートコード実行の脆弱性 Elasticsearch 1.6.1より前のバージョンには、transport protocol（ノードとJavaクライアント間での通信に利用）により、 リモートでコードが実行される脆弱性があります。 これは、CVE-2015-3253でのGroovyに関係しています。\nGroovyのダイナミックスクリプティングがオフでも脆弱性があります。 アップグレードをしないユーザは、transport protocol のポート（デフォルトで9300）信頼したエージェントからのみの アクセスに限定することで、脆弱性から保護できます。\nこの問題をCVE-2015-5377としました。\nディレクトリ探索の脆弱性 Elasticsearch 1.0.0から1.6.0までのバージョンで、ElasticsearchのJVMプロセスによって読み込みが可能なファイルを 取得することができるディレクトリ探索攻撃の脆弱性があります。 アップグレードをしないユーザは、信頼できない場所からのSnapshot-Restore APIの呼び出しを防ぐためにファイアウォール、リバースプロキシやShieldを使用することができます。\nこの問題をCVE-2015-5531としました。\nシャードアロケーションを遅らせる Elasticsearch 1.6.0でSynced Flushingが導入されました。 これは、ノードのリスタート時に、更新が止まっているシャードのリカバリを劇的にスピードアップします。 しかし、この変更は、シャードの配置を無効にしている環境でのみうまく実行されます。 ノードが一時的にクラスタから外れている場合や予期せぬリブートの場合には役に立ちません。\nこのシナリオとは次のようなものです。\nノードの想定外のシャットダウン マスタがたのノードにシャードを再配置 各シャードが新しい場所にネットワーク越しにコピー その間に、外れていたノードが再度クラスタにジョイン マスタは新しいノードにシャードを再配置。新しいノードに存在する既存のシャードが全く再利用されない可能性がある ノードレベルとクラスタレベルの両方の並列的なリカバリを抑制しても、 この\u0026quot;シャードシャッフル\u0026quot;がクラスタに対して負荷をかける可能性があります。 これは、外れたノードが再度ジョインするのを単に待つことにより防げるかもしれません。\n待ちましょう！ Elasticsearch 1.7.0はindex.unassigned.node_left.delayed_timeout設定を追加しました。デフォルトでは1分です。 これは、ノードがクラスタから外れたとき、ほかのノードにこれらのノードを再配置するまでマスタが1分待つということです。 ノードがこの1分の間に復帰した場合、マスタはローカルにあるシャードを再度配置します。\nなぜ1分？ ノードがシャットダウンし、リスタートし、復帰するために十分な時間が1分だからです。 しかし、ノードが復帰しない場合にはまだ再配置が発生することを意味します。 デフォルト値を決定するのは難しいです。 この設定をどのくらいに減らすか、増やすかを決める必要があるかもしれません。\nこのデフォルト値は、config/elasticsearch.ymlファイルに設定できますが、インデックス設定の更新APIを使って設定することも可能です。\nこのデフォルトに関する知見をぜひフィードバックしてください。\nインデックスリカバリの優先度 1.7.0の2つ目の重要な機構はフルクラスタリスタートのような後に、 どの順番でインデックスをリカバリするかという優先度をつけることができるという機能です。\n電源故障による、ロギング用のクラスタのダウンを想像してください。 クラスタが普及した場合、500個のインデックスをリカバリするような場合、499個のインデックスのデータは古く、 500番目のインデックスが重要です。 もっとも最近作成されたインデックスがリカバリされるまで、インデキシングを待つというようなことはできません。\nこれまでは、インデックスはランダムな順序でリカバリされ、重要なインデックスがリカバリされるまで待つしかありませんでした。 1.7.0では、インデックスは優先度の順番でリカバリされます。 この優先度は次のプロパティで指定できます。\nindex.priority設定（大きな値が優先度が高い） インデックス作成日（新しいものが優先度が高い） インデックス名 既存のクラスタについて特に変更せずとも、最も最近作成されたインデックスが古いものよりも復旧されます。 古いインデックスの優先度を上げるためには、index.priority設定に0よりも大きな値を設定します。\nPUT important_index/_settings { \u0026#34;index.priority\u0026#34;: 5 } この設定は、存在するインデックスに対して更新できます。リカバリ中にもです。\nまとめ ぜひ、Elasticsearch 1.7.0をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1437546817,"dir":"post/2015/","id":"809925e891b0456231c374b09cbe4a90","lang":"ja","lastmod":1437546817,"permalink":"https://blog.johtani.info/blog/2015/07/22/elasticsearch-1-7-0-and-1-6-1-released-ja/","publishdate":"2015-07-22T15:33:37+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.0 and 1.6.1 released 本日（7/16）、Lucene 4.10.4ベースのE","tags":["elasticsearch"],"title":"Elasticsearch 1.7.0 および 1.6.1リリース（日本語訳）"},{"contents":"東京以外での勉強会の第2弾として、関西で勉強会を開催してきました。\nElasticsearch勉強会 in 大阪 Elasticsearch勉強会 in 京都 会場提供をしていただいた、Yahoo!大阪、はてなのみなさん、ご協力ありがとうございました！\nここからはいつものメモです。 ちなみに、大阪の勉強会に、@takuya_aさんと@5kozawaさんの両名にお越しいただき話をしていただきました。 なので、勉強会の内容はほぼ同一になります。\nIntroduction Elastic @johtani スライド：Introduction Elasticsearch\n初めての関西での勉強会ということで、ElasticsearchのOSSおよび商用プラグインの紹介をしてきました。 もちろん、Kibanaのデモもちょっとだけ。スプラトゥーンに関するデータをKibanaでちょっとだけ。 突貫でデータをかき集めたのでもう少し改良しないとですが。\nElasticsearch での類似文書検索と More Like This API 詳解 / 株式会社はてな　id:takuya-a スライド：Elasticsearch での類似文書検索と More Like This Query API 詳解\nElasticsearchのMore Like Thisのソースコードリーディングみたいな感じで、 内部でどうやって処理されているかの説明を詳しくしてもらいました。\n前のはてなエンジニアセミナーで話をされていた検索精度の件に絡んだ内容になっているかと。 （大阪で発表してもらった時より京都での発表が分かりやすくなってました。1日で改善されたのすごい！） MoreLikeThisだとチューニングつらいので、自分で作るためにTermVectorAPIでやってみたという流れかと。\n以下は発表後に出てきた質問のいくつかです。\nQ:MoreLikeThisに対してTermVectorで柔軟にできる？ A:TermVectorのAPIで統計情報が取れるので、それを使うことでさらなるデータの更新ができる。\nQ:TFとかの統計情報が必要なら、すべてインデックスをしたあとじゃないとちゃんとした値はとれないのでは？ A:TermVectorで取得したものをどうやって使うか\nQ:TermVectorAPi\u0026hellip;聞こえなかった A:。。。\nElasticsearchを用いたはてなブックマークのトピック生成 / 株式会社はてな　id:skozawa スライド：Elasticsearchを用いたはてなブックマークのトピック生成\nSignificant Terms Aggregationを活用してる話。 トピックページの生成のために、Significant Terms Aggregationをどうやって利用しているかなどのお話でした。\nトピックの集合の重複だったり、精度の判定方法とかいろいろ詳しく説明していただきました。\nQ:2011年と12年で11年の方が多いのは？ A:ブックマークの件数に比例\nQ:Significant terms aggsのsizeはいくつをつかってますか？ A:20を指定してます。\nQ:Yahooとかニュースをストップワードとしてますが、Yahoo自体のニュースに関してはどーしてるんですか？ A:本文とタイトルから別々に作っていて、タイトルからは弾かれますが、本文から作った時に出てきます。\nはてなブックマークにおける Elasticsearch の運用まわりの話 / 株式会社はてな　id:hagihala スライド：未定（おそらく公開される）\n体調が回復しきっていない中の発表ありがとうございました。 大幅に修正された資料が出てくるかなと。（ツイートできない数値がちらほらあったので）\nElasticsearchのクラスタの構成、どういった点で困ってたのでどういう調べ方をしたのか、どういった対処をしたのか。 どのあたりが次の課題かなどの話もありました。\n感想・反省点など 大阪、京都ともに30名弱の方の参加をしていただきました。ありがとうございました。 反省点としては、ハッシュタグを告知し忘れてました。。。\n勉強会はやはり、東京が異常に活発で、大阪や京都はまだそれほどでもないのかなぁとも。 大阪はエンジニアの人や会社も多い気がするんですが。私の告知の仕方もあるかもなぁと。 次回があれば、大阪での事例も聞きたいので、スピーカーをもっと探さないとなと。\n関連ブログなど 見つけたら、リンク追加していきます。\nElasticsearch勉強会 in 大阪/京都で発表しました \u0008* 「Elasticsearch での類似文書検索と More Like This Query API 詳解」というタイトルで発表しました その他（余談） 大阪のYahoo!さんは立地条件（梅田のすぐそば）がよく、\n夜景も綺麗でした。大阪城とかも見えてました。（夜景じゃないけど。。。）\n京都は祇園祭の真っ最中。\n水曜日はお休みをいただいて、観光してました。ちょっと日焼けが。。。 おかげで、リフレッシュできました。三十三間堂とか良かった:)\nあまり、関西に縁がない（大阪15年ぶり、京都10年ぶり）ので、 もっとユーザが増えて勉強会の機運が高まると嬉しいなと。:)\n","date":1437010857,"dir":"post/2015/","id":"dd6c32a722dc815273cd9ed8cd6c671b","lang":"ja","lastmod":1437010857,"permalink":"https://blog.johtani.info/blog/2015/07/16/kansai-1st-elasticsearch-jp/","publishdate":"2015-07-16T10:40:57+09:00","summary":"東京以外での勉強会の第2弾として、関西で勉強会を開催してきました。 Elasticsearch勉強会 in 大阪 Elasticsearch勉強会 in 京","tags":["勉強会","elasticsearch"],"title":"大阪と京都でElasticsearch勉強会を開催しました。 #elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：The Great Mapping Refactoring\nElasticsearchのユーザの悩みの最も大きなものの一つは、 タイプとフィールドのマッピングに関する多義性です。 この多義性は、インデックス時の例外やクエリ時の例外、 正しくない結果、リクエストからリクエストへ変化する結果、 また、インデックスの故障やデータのロスを結果として引き起こします。\nElasticsearchをより強固で予測可能な振る舞いをするようにする作業において、 フィールドやタイプのマッピングをより厳格でより信頼性を高くするかといったことに 多くの変更を費やしました。 多くのケースで、Elasticsearch v2.0で新しいインデックスを作るときにのみ、 新しいルールを強制し、これまでのインデックスに関しては後方互換性を保つようにします。\nしかし、幾つかのケースでは、先ほど説明したようなフィールドマッピングの コンフリクトなどが存在するため、それらを利用できないです。\nコンフリクトしたフィールドのマッピングをもつインデックスはElasticsearch v2.0にはアップグレードできません。\nもし、これらのインデックスのデータが必要ない場合は、インデックスを消せばいいです。 そうでない場合はマッピングを正しくして再度インデックスする必要があるでしょう。\nマッピングを正しく変更することは、私たちが簡単に決めることではありません。 ここからは、現在ある問題点と、私たちがどのように実装して解決したかについて説明します。\nフィールドマッピングのコンフリクト あいまいなフィールドのルックアップ タイプのメタフィールド アナライザ設定 index_nameとpath 同期的なマッピングの更新 マッピングの削除 2.0のための準備 フィールドマッピングのコンフリクト これまで、わたしたちはドキュメントのタイプは「データベースのテーブルのようなもの」と説明していました。 タイプの目的を説明する簡単な方法だったからです。 しかし、残念なことにこれは、真実ではありません。 「同じ」インデックスの「異なるタイプ」にある同じ名前のフィールドは、 内部的に、Luceneのフィールド名が同じものになります。\nもしerrorフィールドとして、ドキュメントタイプがapacheのものには数値（integer）を、 ドキュメントタイプがnginxのものには文字列（string）を割り当てた場合、 Elasticsearchは同じLuceneのフィールドに数値と文字列のデータをもつことになります。 このフィールドに対して、検索やaggregationを行う場合、おかしな結果を受け取るか、例外が帰ってくるか、 インデックスが破損することになります。\nこの問題を解決するために、まず、ドキュメントタイプの名前をフィールドの名前の前に追加することを考えました。 各フィールドは完全に別のものとなります。 このアプローチの利点はドキュメントタイプが実際のテーブルのようになることです。\nしかし、この方法には多くの欠点があります。\nフィールドは常に、他のタイプとは異なるものであると区別するためもしくは、複数のタイプに同じフィールドのクエリのためにワイルドカードをつけた場合、 ドキュメントタイプを前につける必要があります。 複数のドキュメントタイプに対して同じフィールド名で検索する場合、クエリを個別に発行しなければならなく遅くなります。 多くの検索で、既存の多くのクエリを壊してしまうために、単純なmatchやtermクエリの代わりに、multi-fieldクエリを使う必要があります。 圧縮の効率の悪さから、ヒープ利用量、ディスク使用量、I/Oなどが、増加します。 複数のドキュメントタイプに対するaggregationは、global ordinalの利点を利用できなくなるために、遅くなり、メモリの使用量も増えます。 解決方法 最終的に、同じインデックスの同じ名前を持つ全てのフィールドは、同じマッピングを持つ必要があるというルールを採用することに決めました。 ただ、copy_toやenabledのようなパラメータはタイプごとに指定することができるようになっています。 これにより、データの破損、クエリ時の例外そして、おかしな結果が発生する問題を防ぎます。 クエリとaggregationは現在でも高速なままで、圧縮率を最大化し、ヒープ使用量やディスク使用率の低減させます。\nこの解決方法の欠点は、個別のテーブルとしてタイプを扱いたいユーザが彼らの考え方を変える必要があるということです。 これは、思ったよりも問題ではありません。 実際には、多くのフィールド名はデータの明確なタイプを表現しています。 created_dateは常に、日付ですし、number_of_hitsフィールドはいつも数値です。 フィールドマッピングがコンフリクトしているユーザはデータを失ったり、おかしなデータを受け取ったり、データを欠損させています。 ベストプラクティスにユーザが従っているかどうかによらず、インデックス時に正しい振る舞いを強制することが現在の違いです。\nユーザの多くがコンフリクトしていないフィールドマッピングをもっていれば、 コンフリクトが起きた場合、技術がこれらのシチュエーションを扱うことが可能になると思いませんか？ そこにはいくつかの解決方法があります。\nタイプの代わりにインデックスを別々に 最も簡単な解決方法です。インデックスを別々のインデックスとし、実際のデータベーステーブルのようにします。 インデックスをまたいだ検索はタイプをまたいだ検索のように動作しますし、 ソートやaggregationも同じデータタイプへのクエリのように動作します。これまでと同じ制限です。\nコンフリクトしたフィールドの名前の変更 コンフリクトがごくわずかな場合、（Logstashやアプリケーションで使っているものも一緒に）よりわかりやすいフィールド名に変更することで解決できます。 例えば、2つのerrorフィールドがあった場合に、error_codeとerror_messageに変更します。\ncopy_toもしくはmulti-fieldsを利用 異なるドキュメントタイプのフィールドは別々のcopy_toを設定できます。 元のerrorフィールドはindexの設定にnoが設定してあり、全てのドキュメントタイプで無効化されていますが、 特定のタイプだけ、errorフィールドの値を数値のerror_codeフィールドにコピーすることができます。\nPUT my_index/_mapping/mapping_one { \u0026#34;properties\u0026#34;: { \u0026#34;error\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;no\u0026#34;, \u0026#34;copy_to\u0026#34;: \u0026#34;error_code\u0026#34; }, \u0026#34;error_code\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;integer\u0026#34; } } } 他のタイプでは文字列のerror_messageにコピーします。\nPUT my_index/_mapping/mapping_two { \u0026#34;properties\u0026#34;: { \u0026#34;error\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;no\u0026#34;, \u0026#34;copy_to\u0026#34;: \u0026#34;error_message\u0026#34; }, \u0026#34;error_message\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } 同様の解決方法としてmulti-fieldも使えます。\n各データタイプに対してネストしたフィールドに ときどき、Elasticsearchに送ったドキュメントやドキュメントがもっているフィールドを制御できない場合があります。 部分的なコンフリクトに加え、闇雲に、ユーザが送ってきたフィールドを受け入れると、マッピングが肥大化します。 タイムスタンプやIPアドレスをフィールド名に使うようなドキュメントがあると考えてください。\nnested フィールドにすることで、str_val、int_val、date_valというような各データタイプを利用できます。\nこのアプローチによって、次のドキュメントは\n{ \u0026#34;message\u0026#34;: \u0026#34;some string\u0026#34;, \u0026#34;count\u0026#34;: 1, \u0026#34;date\u0026#34;: \u0026#34;2015-06-01\u0026#34; } アプリケーションによって、次のようにフォーマットしなおす必要があります。\n{ \u0026#34;data\u0026#34;: [ {\u0026#34;key\u0026#34;: \u0026#34;message\u0026#34;, \u0026#34;str_val\u0026#34;: \u0026#34;some_string\u0026#34; }, {\u0026#34;key\u0026#34;: \u0026#34;count\u0026#34;, \u0026#34;int_val\u0026#34;: 1 }, {\u0026#34;key\u0026#34;: \u0026#34;date\u0026#34;, \u0026#34;date_val\u0026#34;: \u0026#34;2015-06-01\u0026#34; } ] } この解決方法は、アプリケーションサイドでより多くの作業が必要ですが、コンフリクトの問題とマッピングの肥大化の問題を同時に解決します。\nあいまいなフィールドのルックアップ 現在、フィールドの指定には\u0026quot;short name\u0026quot;、フルパス、ドキュメントタイプを前につけたフルパスが利用できます。 これらのオプションがあいまいさをもたらしています。 サンプルとして次のマッピングをご覧ください。\n{ \u0026#34;mappings\u0026#34;: { \u0026#34;user\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;title\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;blog\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;title\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;user\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;object\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;title\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } } } } } titleはuser.title、blog.title、blog.user.titleのどれでしょう？ user.titleはuser.titleまたはblog.user.titleのどちらでしょう？ 答えは「場合によります。」です。Elasticsearchが最初に見つけたものになります。 フィールドはリクエストごとに変わるため、各ノードでマッピングがどのようにシリアライズされたかに依存します。\n2.0では、フィールドを指定する時に、ドキュメントタイプを除いたフルパス名を使用するべきでしょう。\nuser.titleは、blogタイプのuser.titleを意味します。 titleは、userとblogタイプのtitleフィールドを意味します。 *titleはuser.titleとtitleフィールドの両方にマッチします。 userタイプのtitleフィールドとblogタイプのtitleの違いはどのように指定するのでしょう？\n指定できません。フィールドマッピングのコンフリクトで説明した変更により、 titleフィールドは両方のタイプで同じフィールドになります。 本質的にtitleと呼ばれる1つのフィールドになります。\nuser.やblog.のようなタイプのプレフィックスはタイプを指定することによるフィルタリングで効果があります。 クエリのblog.titleフィールドはblogタイプのドキュメントだけを検索し、userタイプのドキュメントを検索しません。 このシンタックスは誤解を招きやすいです。なぜなら、いつでも動作するわけではないからです。 aggregationやsuggestionはすべてのタイプに関する結果を含みます。 この利用のため、上記の例のあいまいさがあるので、タイプのプレフィックスはサポートしません。\n重要 short nameやタイププレフィックスを利用したpercolatorは更新する必要があります。\nタイプのメタフィールド すべてのタイプはメタフィールドを持っています。_id、_index、_routing、_parent、_timestampなどです。 これらのほとんどはindex、store、pathのような幾つかの設定をサポートしています。 これらの設定について次のようにシンプルにしました。\n_idと_typeは変更不可 _indexは、ドキュメントのもつインデックスを保存するためにenabled _routingはrequiredのみを指定 _sizeはenabledのみ _timestampはデフォルトで保存される _boostと_analyzerは廃止。古いインデックスのものは無視される ドキュメントのフィールドから_idと_routingと_timestampの値を抽出することができました。 この機能は廃止されます。これは、ドキュメントのパースとコンフリクトを起こすためです。 代わりに、これらの値はURLもしくはquery stringで指定可能です。\n_boostと_analyzerフィールドは例外で、すでにあるメタフィールドの設定は古いインデックスのものが採用されます。\nアナライザ設定 これまで、indexとsearchのアナライザがインデックス、タイプ、フィールド、ドキュメント（_analyzerフィールドで）の それぞれのレベルで指定可能でした。 同じフィールドに対して異なるanalysis chainの組み合わせができることにより、おかしな関連度を引き起こしていました。 フィールドマッピングのコンフリクトを解消することに加え、アナライザの設定も簡略化します。\nAnalyzedな文字列フィールドは、analyzer設定とsearch_analyzer設定（analyzer設定の値をデフォルトとする）を指定できます。index_analyzer設定はanalyzerとなります。 複数のタイプで同じ名前のフィールドがある場合、フィールドはすべて、同じアナライザの設定を持たなければなりません。 タイプレベルのデフォルト設定のanalyzer、index_analyzer、search_analyzer設定は廃止されます。 デフォルトアナライザはインデックスごとにインデックスのanalysis設定で設定します。これらはdefaultもしくはdefault_searchという名前で設定します。 ドキュメントごとの_analyzerフィールドはサポートしません。既存のインデックスのものは無視されます。 index_nameとpath index_nameとpath設定は（Elasticsearch v1.0.0から利用できる）copy_toによって置き換わりました。 既存のインデックスについてはこれらは機能しますが、新しいインデックスでは指定できません。\n同期的なマッピングの更新 現在、これまで存在していないフィールドを含むドキュメントをインデキシングするとき、 フィールドはローカルのマッピングに追加され、それから、マスターに変更（新しいマッピングをすべてのシャードに適用する更新）が送信されていました。 同時に2つのシャードに同じフィールドを追加することができます。 また、そのとき、異なる2つのマッピングがある可能性があります。 1つはdoubleでもう1つはlongだったり、stringとdateだったりと。\nこのような場合、マスターに最初に届いたマッピングが採用されます。 しかし、「負けた」マッピングをもつシャードでは、すでに異なるデータのタイプを利用しているため、 これを利用し続けます。 そのご、ノードをリスタートしたときに、シャードが別のノードに移動し、マスターにあるマッピングを適用します。 このとき、インデックスが破損したりデータを失ったりします。\nこれを防ぐために、シャードはインデキシングを続ける前に、新しいマッピングがマスターによって採用されるかどうかを待つようになりました。 これはすべてのマッピングが安全に更新されます。 新しいフィールドをもっているドキュメントをインデキシングすると、前よりも処理が遅くなるでしょう。 受け入れられることを待つ必要があるためです。 しかし、クラスタの状態の更新処理のスピードが次の2つの新しい機能によって大きく改善されています。\nクラスタ状態の差分：可能であれば、クラスタの状態の変更はクラスタ状態全体の変更ではなく、部分的なものとする。 シャードへのリクエストの非同期化：シャードアロケーション処理中に、マスタノードは、 割り当てられていないシャードのコピーの日付が最新のものを持っているかを見つけるために、リクエストをデータノードに対して送信します。 ここで、クラスタ状態を変更する呼び出しがブロッキングで行われていました。v1.6.0から、このリクエストはバックグラウンドで非同期で実行されます。 これにより、マッピング更新のようなペンディングタスクをより早く処理できるようになります。 マッピングの削除 （そのタイプのドキュメントがある場合）タイプマッピングを削除できないようにします。 マッピングを削除した後に、削除されたフィールドの情報は、Luceneレベルでは存在し続け、 もし、後から同じ名前のフィールドが追加されたときにインデックスの破損を引き起こします。 そのようなマッピングは残しておくか、新しいインデックスに再インデックスすることができます。\n2.0のための準備 マッピングがコンフリクトしているかどうかを決めることは、手動で行うには慎重に行う必要があります。 私たちは、Elasticsearch Migration Pluginを提供します。 これは、2.0で非推奨になったり廃止された機能を利用しているかどうかを見つけるために役に立つでしょう。\nもし、コンフリクトしたマッピングを持っている場合、 正しいマッピングを持つ新しいインデックスにデータを再インデックスするか、 必要ないなら削除します。 これらのコンフリクトを解決しない限り2.0にはアップグレードできないでしょう。\n","date":1436346691,"dir":"post/2015/","id":"ee4ff9e4e8a1948795e26af2f3f8a30f","lang":"ja","lastmod":1436346691,"permalink":"https://blog.johtani.info/blog/2015/07/08/great-mapping-refactoring-ja/","publishdate":"2015-07-08T18:11:31+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：The Great Mapping Refactoring Elasticsearchのユーザの悩みの最も大きなものの一つは、 タイプと","tags":["elasticsearch"],"title":"Mappingのすばらしいリファクタリング（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 2.0.0.beta1 coming soon!\nElasticsearch 2.0.0.beta1のリリースの準備をしています。 これは、Lucene 5.2.1に含まれる多くの改善が利用できるようになります。 このリリースに関するいくつかの機能は次のようなものです。\nPipeline Aggregations 差分や移動平均、他のAggregationsの結果に対する series arithmeticのようなaggregationが利用可能になります。 この機能は、これまでは、クライアントサイドで実行する必要がありました。 しかし、この計算をより強力な解析クエリを構築してElasticsearchで 実行することができるようになります。 クライアントのコードをより簡潔にすることができます。 これにより、予測解析や異常検知のようなことができるようになります。\nQuery/Filter merging Filterはなくなります。全てのフィルタは、クエリになります。 クエリコンテキストで利用されると、効率的に関連度スコアを計算し、 フィルタコンテキストで利用されると、単に、 マッチしていないドキュメントを除外する（今のフィルタのようなもの）だけです この変更は、クエリ実行が自動的に、より効率的な順番で実行されるように 最適化されることを意味します。 例えば、フレーズやgeoクエリのような遅いクエリは まず、近似フェーズを実行し、それから、より遅い実際のフェーズが 結果に対して行われます。 フィルタコンテキストにおいて、頻繁に利用される条件は自動的にキャッシュされます。\nConfigurable store compression index.codec設定により、高速化のためのLZ4圧縮（default）か インデックスサイズを小さくするためのDEFLATE（best_compression）を 選択できます。これは、ロギングでとくに役に立ちます。 これにより、古いインデックスオプティマイズする前にbest_compressionに 変更できます。\nこれらに関するブログ記事がすぐに公開されるでしょう。\nPerformance and resilience 以降では、新しいメジャーリリースに関して簡単に紹介します。 2.0の変更の多くは内部の機能に関するものであり、 直接ユーザに関連するわけではないからです。\n新しいメジャーバージョンのテーマは、パフォーマンス、安定性、 堅牢性、予測可能性、そして使い勝手の良さです。\n物事が予測した通りに動作する 何か問題があった場合に、Elasticsearchから役立つフィードバックがある ローレベルの設定を扱う必要はなく、Elasticsearchが良い設定を決定する これらに加え、データがより安全に これらの目標は完全ではありません。 まだ、多くの改善があります。しかし、2.xブランチで、 すでに500コミットを超える大きな改善が実施されています。\non-diskの doc valuesをデフォルトで利用（これまではfielddata）。 ヒープ使用量を減らして、スケーラビリティを向上 セグメントマージ処理中のメモリ使用量の削減 normsの圧縮率の改善。ヒープスペースを利用している大きな処理のひとつだったため。 全てのリクエストの後に、transaction logをfsyncすることで、デフォルトで耐久性を向上 全てのファイル変更をアトミックに（部分的なファイルの書き出しはなし） マージを自動で制限 フレーズクエリやスパンクエリを高速化 フィルタキャッシュをより効率化するための圧縮されたビットセット クラスタ状態の差分更新 構造化されたJSON形式の例外 よりきめ細かいLuceneのメモリレポート デフォルトではlocalhostにのみバインド。開発のノードが他のクラスタにジョインするのを防ぐ parent/childのクエリ実行最適化のためにリライト Java Security Managerで必要最小限なパーミッションで実行 全てのコアなプラグインをelasticsearchリポジトリに移行し、Elasticsearchのバージョンに同期してリリースされる予定 アップグレード前に メジャーバージョンのアップグレードは問題のあるものを一掃する機会を与えてくれます。 できる限り、これらの変更をアップグレードするために、簡単な方法を提供しようとしています。 しかし、Elasticsearch 2.0にアップグレードする前に、必要な処理が2つあります。\n1つ目は、フィールドとタイプマッピングに関することです。 mapping APIは、現在、それほど厳密ではありません。 内蔵された保護機構を提供する代わりに、ユーザがベストプラクティスを知っていると信頼していました。 2.0では、mappingはより厳密で安全ですが、いくつかの変更では、後方互換性を保っていません。 詳細についてはThe Great Mapping Recatoringをごらんください。\n2つ目はElasticsearch 0.20以前のユーザに関する変更です。 これは、Lucene 3.xを使っています。 Elasticsearch 2.xはLucene 5をベースにしています。 Lucene 5はLucene 4.xによって作成されたインデックスの読み込みはサポートしていますが、 Lucene 3.xに関してはサポートしていません。\nElasticsearch 0.20以前のバージョンによって生成されたインデックスを持っている場合、 Elasticsearch 2.xのクラスタをスタートすることはできません。 これらの古いインデックスを削除するか、Elaticsearch 1.6.0以上に含まれている upgrade APIを使用してアップグレードする必要があります。\nupgrade APIの実行は2つのジョブを実行します。\n古いLuceneフォーマットのセグメントを最新のフォーマットで書き換えます Elasticsearch 2.xによって読み込めるようという印をインデックスに追加します 全てのセグメントを最新バージョンにアップグレードするのも良い案ですが、 アップグレード前に必要な処理を最小限に抑えることも可能です。 （Lucene 3.xのセグメントだけをアップグレード） その場合は、only_ancient_segmentsパラメータを指定します。\nElasticsearch Migration Plugin Elasticsearch 2.0 に移行する前に、インデックスがアップグレードが必要なのか、 ほかになにかするべきことがあるのかをチェックする助けになる Elasticsearch Migration Pluginをリリースしました。\nまず、プラグインをインストールします\n./bin/plugin -i elastic/elasticsearch-migration プラグインのインストール後はノードのリスタートは必要ありません。\n以下のリンクをブラウザで開きます。\nhttp://localhost:9200/_plugin/migration\n（localhost:9200はインストールしたホスト名に変更してください。）\nMigration pluginに関してバグやご意見がある場合は、GitHubのIssueにお願いします。\n","date":1436250300,"dir":"post/2015/","id":"f887e1aabf801e351bfb39698f208af1","lang":"ja","lastmod":1436250300,"permalink":"https://blog.johtani.info/blog/2015/07/07/elasticsearch-2-dot-0-0-dot-beta1-coming-soon-ja/","publishdate":"2015-07-07T15:25:00+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0.beta1 coming soon! Elasticsearch 2.0.0.beta1のリリースの準備をしています。","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0.beta1リリース間近（日本語訳）"},{"contents":"4ヶ月前に、Found joined our team at Elasticをアナウンスしました。 Foundの素晴らしいチームと一緒に仕事をしていますが、彼らによって、より素晴らしい hosted Elasticsearchを提供することになりました。\n私たちがともに密接に働くことにより、本日（2015/7/1）、 新しい2つのFoundを提供することになりました。 Found StandardはこれまでのFoundの機能に加え、さらに低価格を提供します。 Found Premiumは、SLAサポートと、ShieldやWatcherを将来Found上で提供します。\nFound Standard Foundは素晴らしいです。専用のElasticsearchクラスタ、簡単なスケール、 ビルトインのセキュリティそして、時間単位での課金などを持っています。 私たちは、hosted Elasticsearchを探している方に、 Foundが適したソリューションであると思っていますし、 すべての方に利用できて手頃な価格であるということを確信したいと思っています。\n本日（2015/07/01）からFoundの価格をかなり低価格にし、 月額50ドル以下でhosted Elasticsearchを簡単に試してもらえるようにしました。\n価格を下げることは正しい重要なステップですが、 Foundを利用している全ての人に、より良い経験を持っていただきたいと考えています。 低価格化と一緒に、free backupsとbuilt in SSDもFoundで提供を始めることになります。\nFoundの重要な特徴の一つが、高可用性のために、クラスタをいくつのデータセンターに持つかを 選択できることです。 データは重要です。これが正しい選択でユーザの助けになると考えています。 これにより、私たちの価格は、複数のデータセンターにより安価に配置することができます。\nまた、KibanaもElasticsearchのデータを可視化する素晴らしい方法だと考えています。 Kibana 4が最新バージョンですが、 これは、サーバサイドコンポーネントを持っています。 これは、サービスとしてこれを提供するために、追加の料金がかかることを意味します。 Foundチームが築いた素晴らしい基盤とKibanaチームの努力により、 hosted Elasticsearchクラスタで無料のKibana 4を7月15日より提供することになりました。\nFound Premium また、私たちは、オープンソースプロダクトに関してサブスクリプションを提供していますが、 Found Standardに対しても提供することになりました。 これが、Found Premiumです。\nフォーラムベースのサポートよりもSLAベースのサポートを望んでいる場合、 プロダクトを開発しているチームからのサポートを受けることができるオプションを 提供し始めました。 クリティカルなイベントを持っていたり、私たちのプロダクトに関する 問題を予測するためのベストなヘルプやガイダンス、アドバイスを探しているような場合にサポートします。\nさらに近い将来、サブスクリプションの一部として、Shield（Elasticasearchのセキュリティプラグイン）やWatcher（アラーティングプラグイン）が利用できるようになります。\n私たちのチームがともに働き、多くのことを可能にし、すばらしい仕事をユーザに提供したかを 将来も楽しみです。 私は非常に誇りに思っていますし、気に入っていただけたらと思っています。 ぜひ、7/15のWebnarに参加してくわしい話を聞いていただき、疑問を解消してください。\n","date":1436250000,"dir":"post/2015/","id":"9cc2a0b6c8be1405cddcdeb4487c59fe","lang":"ja","lastmod":1436250000,"permalink":"https://blog.johtani.info/blog/2015/07/07/we-just-made-found-more-awesome-ja/","publishdate":"2015-07-07T15:20:00+09:00","summary":"4ヶ月前に、Found joined our team at Elasticをアナウンスしました。 Foundの素晴らしいチームと一緒に仕事をしていますが、彼らによって、より","tags":["elasticsearch","found.no"],"title":"さらに進化したFound（日本語訳）"},{"contents":"JustTechTalk#02 形態素解析のあれやこれや@ジャストシステム\nに参加してきました。 ジャストシステムさんの形態素解析器JMATの話とKagome、Janome、Kuromoji.js、ssslaの開発者の パネルディスカッションでした。\nということで、いつものメモです。\nジャストシステムの形態素解析その２（機械学習編） JMATの話\n前回は辞書の話 今回は学習の話 教師あり/教師なし\nJMATは教師あり 教師なしは研究段階 ラティス構造を辞書ベースで構築して、コストの総和が最小の経路を求める\n連接、単語生成とか。 学習は3フェーズ\nベース、能動、部分アノテーション ベース 300万文のコーパスから1万文のみを利用（なぜ？今から説明） 64GBマシン買ってみたけど、複数実験するには追いつかない オンライン学習がメジャーでない時代に作り始めたので、つかってない CRF学習器を改善 結果として50万文くらいで精度が良くなる 辞書チームからNGがでて、方向転換 方向転換した結果が3つのフェーズらしい ピタジョブに採用？ 疑問 \u0008* JMATって、Webの検索の前処理とか分類とかに主に利用するのかな？\nATOKでもこのノウハウって利用してるんかな？ 辞書もあるらしいけど、辞書更新されると学習器のデータとかどーなるんだろ？ 形態素解析器の実装言語Talkについて kuromoji.jsの@takuya_aさん\nTyped Arrayサポートが高速にできてる理由でもあるらしい Kagomeの@ikawahaさん\nGoはいろいろないらしい Janomeの@moco_betaさん\nsssla（茶筌のRuby clone）\nなんで作ったの？\n形態素解析のライブラリ「解析部分」はNLPのHelloWorldだから なんで、その言語？\nPython 3系は文字列とバイト配列の扱いがすごく楽！ その言語で困った点は？\nGoだと、辞書を内包するのが大変 JSは苦労したところしかない（1hくらいしゃべれるぞ！）。基本的なデータ構造とかもない Pythonはパフォーマンスを考えないと Ruby（1.6だったので）もパフォーマンスが その言語を開発するときに必須のものは？\nGoはとくにない。エディタはどれでもOK browserifyが便利 \u0008* ほかの人たちの言語をdisってください * JSは論外。Pythonのコードフォーマッターが揺れるのが。。。Rubyはバージョンが。。。 * Goはブラウザで動かない。Pythonもブラウザで動かない。Rubyも(ry * ほかのは触ったことないので。。。 * Pythonは2.xか3.xか決めてくれ！\nなんで、Kuromojiベースなの？ Java読みやすいから。 MeCabとKuromojiの違いは？ 未知語の処理が結構違う 感想 きれいなロビーで良かったのですが、マイクがあると嬉しかったかもしれません。 前回の辞書の話も聞いてみたかったかも。\n","date":1436147341,"dir":"post/2015/","id":"18b7998a871950ebc36c415a53630477","lang":"ja","lastmod":1436147341,"permalink":"https://blog.johtani.info/blog/2015/07/06/attend-justsystem-techtalk-no2/","publishdate":"2015-07-06T10:49:01+09:00","summary":"JustTechTalk#02 形態素解析のあれやこれや@ジャストシステム に参加してきました。 ジャストシステムさんの形態素解析器JMATの話とKagome、Janome、","tags":["勉強会"],"title":"JustTechTalk#02 形態素解析のあれやこれや@ジャストシステムに参加しました。"},{"contents":"ひさびさに、勉強会メモ。 Hatena Engineer Seminar #5 @ Tokyoに当選したので行ってきました。\nいつもは近寄らないオシャレな街をドキドキしながら行ってきました。\nということで、簡単なメモです。\nはてなブックマーク全文検索の精度改善 id:takuya-a 問題：検索精度がよくない 京都で検索 →　「ポーランドの京都」「京都大学のまるまる教授」のようなもんがヒット 京都っぽいエントリが出て欲しい。 京都っぽい？？？ 問題点をブレイクダウン 課題 クエリ考えるの大変だよね 順序が新着順なのが辛い 適合率と再現率の両立 そして（ドラムロール）、できました！（さすが）\nアイデア：はてブのタグを利用する。 関連キーワードを抽出して、クエリ拡張する。\n関連キーワードとは？ タグ検索する 検索にヒットしたTerm Vectorsを取得 特徴語をTop25件取得 もっともスコアが高いタームを特徴語とする 英語のストップワードとかが問題点となってたり。 →Dynamic stop word listというのを利用して排除（IDF、RIDF、Gain） 今後の課題 再現率の向上 解析用のフィールド・辞書を追加（精度向上や解析ミスなど） トークに出てきた機能など トークに出てきたElasticsearchの機能については、こんなツイートをしてたので、参考にしてもらえれば。\nこれのkuromoji_stemmerを使ってるっぽい？ #hatenatech / elastic/elasticsearch-analysis-kuromoji - https://t.co/3F2sBYXLPH\n\u0026mdash; Jun Ohtani (@johtani) 2015, 6月 16 #hatenatech Term Vectors APIのドキュメントはこちら - https://t.co/HhBmTDr46i\n\u0026mdash; Jun Ohtani (@johtani) 2015, 6月 16 #hatenatech min_score - https://t.co/Sc0exzJRC1\n\u0026mdash; Jun Ohtani (@johtani) 2015, 6月 16 個人的な疑問 Q：クエリにヒットするタグがそもそもなかったら？\nはてなブックマークに基づく関連記事レコメンドエンジンの開発 id:skozawa 課題：一部のエントリに対して関連記事が出ない タグがない記事について関連エントリが出ない＝既存はタグを利用している 例：レシピで考える\n現行システム ユーザがつけたタグ情報を利用してMoreLikeThisで計算 新規システム 類似記事検索 特徴語の抽出 特徴語を分類 関連記事検索 関連記事をスコアリング 個人的な疑問 Q：毎回計算してるのかな？記事登録とかされたタイミングでやってるのかな？ Q：Termの精度などどうなんだろ？\n『BrandSafe はてな』のアドベリフィケーションのしくみ id:tarao BrandSafeはてな：とか。 広告の配信先をフィルタリング\n複数の素朴なフィルタの組み合わせ→AdaBoost\n個人的な疑問 Q：海外とかもいけるのかな？\nまとめと感想 ということで、簡単なメモでした。ピザごちそうさまでした！ 聞いてて少し思ったのは、データ量があるサイトだからうまくいく手法だというのもあるんだろうなというところでした。 あとは、クエリを暗に改善するのとは別に、サジェスト的に表示するのにも使えたりするかも？と思ってみたり。 できるかどうかはわからないですが。。。\nElasticsearchをいろいろと活用してもらってるのがわかって、楽しい勉強会でした。 もっともっといろんなところで宣伝してくださいw\n今日の勉強会を聞いて、俄然、京都・大阪でElasticsearch勉強会を開催したい気になってきました。 特に大阪に知り合いがいないので、だれか紹介してもらえると嬉しいです。 お待ちしてます。\n","date":1434468093,"dir":"post/2015/","id":"ddab6357ff522c0c956ebd7669e83454","lang":"ja","lastmod":1434468093,"permalink":"https://blog.johtani.info/blog/2015/06/17/attend-hatena-engineer-seminar-5/","publishdate":"2015-06-17T00:21:33+09:00","summary":"ひさびさに、勉強会メモ。 Hatena Engineer Seminar #5 @ Tokyoに当選したので行ってきました。 いつもは近寄らないオシャレな街をドキドキしながら行ってきました。 と","tags":["勉強会"],"title":"Hatena Engineer Seminar #5 @ Tokyoに参加しました。 #hatenatech"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.6.0 released\n本日（6/9）、Lucene 4.10.4ベースのElasticsearch 1.6.0をリリースしました。 このリリースはElasticsearchの最新の安定バージョンとなります。 また、素晴らしい新機能がいくつか追加されています。\nsynced flushによるリスタートの高速化 \u0008* シャード配置は保留中のタスクをブロックしない レスポンスボディのJSONのフィルタリング 共有ファイルシステムリポジトリに対するセキュリティフィックス 古いインデックスのためのUpgrade API Kibanaユーザのためのハイライトの強化 Windowsユーザのためのmlockall より詳細なスクリプト設定 すべての変更リストとダウンロードはこちらをごらんください。\nsynced flushによるリスタートの高速化 1.6.0より前のバージョンでは、メンテナンスやローリングアップグレード時の ノードの再起動で、必要であるかどうかに関わらず、多くの場合、 ノードのすべてのシャードのすべてのデータを再度コピーする必要がありました。 この新しいsynced flush機能により、 sync-flushされたインデックスに対して、既存のデータを再利用し、 より早くクラスタを正常な状態にすることができるようにします。\nここで、この変更以前にどのように動いていたかを説明します。 すでにあるレプリカシャードは、ノードがリスタートした後に、 プライマリから復元するときに、 最初のステップはプライマリにあるセグメントとレプリカにあるセグメントを 比較することです。そして、セグメントに違いがあった場合にコピーされます。 問題は、セグメントプライマリのセグメントのマージと レプリカのセグメントのマージが別々に起こっており、 各シャードのセグメントが完全に異なるが、 それらが同じデータを持っているという点です。\n新しいsynced-flush機能では、sync_idがプライマリと レプリカシャードに、シャードのコンテンツが同一であるという判別するために、 書き込まれます。これは、リカバリがセグメントの比較のステップを スキップできることを意味します。 リカバリのスピードを高速にします。\nsynced flushはアイドル状態のインデックスで自動的に実行されます。 直前の5分間でデータが登録、更新削除されていないインデックスに対してです。 これは、ロギングのユースケースで特に役に立ちます。 機能のインデックスはインデキシングがストップしたあとの5分で自動的に syncされるでしょう。\nノードのリスタートやクラスタのリスタートが必要で、 自動的に発生するsyncを待てない場合は次のようなことが可能です。\nインデキシングを停止（実行中のリクエストが停止するのも待つ） シャードのアロケーションを停止 synced-flushリクエストの発行 ノードのリスタート シャードのアロケーションの再開 クラスタの状態がグリーンになるまで待つ インデキシングの再開 NOTE: \u0026ldquo;シャードのアロケーションを停止\u0026quot;のステップが必要です。 これがない場合、Elasticsearchはノードの再起動が始まると、 異なるノードにシャードの再配置を始めます。 これは、新しいノードにシャードデータの全てをコピーする必要があります。\nドキュメントのインデキシング、更新、削除のあとに最初のフラッシュが 発生したときに、 シャードのsync_idが自動的に無効化されます。 詳細については#11336と#11179をごらんください。\nシャード配置は保留中のタスクをブロックしない 多数のノードやインデックスを持っているユーザは クラスタ全体のリスタートのあとのシャードのリカバリで、 長い間、リカバリが止まって見えることに気づいたかもしれません。 これらのリカバリが止まって見える間は、クラスタ設定の更新のような軽微なアクションでさえ、 例外が発生したり、その設定が反映されるまでに長時間かかるといったことが起きていました。 この問題の兆候は保留中のタスクのキューが大きくなることです。\nこれらの遅延の原因はシャードの配置のプロセスにあります。 配置されるべきシャードのコピーを 持っているのがどのノードかを全てのデータノードに聞きます。 多くのシャードや遅いディスクを持ったデータノードは 反応するのに時間がかかります。 特に、シャードのリカバリがすでにI/Oを利用しているような時です。 このバージョン以前のものは、シャード情報のためのリクエストを 同期的に処理していました。 クラスタ状態の更新はアロケーションプロセスを続けるために 必要な情報を待っている間、ブロックされます。\n#11262での変更は この情報のためのリクエストを非同期にします。 クラスタ状態の更新はこのタスクによってブロックされません。 これは、保留中のタスクがより早く処理でき、 クラスタが変更に対してより早く反応できます。 処理中のshard infoリクエストの数は number_of_in_flight_fetchキーとしてcluster-health APIで取得できます。\nさらに、シャードがある理由で復旧に失敗すると、 クラスタは、シャードのリカバリが成功するまで、同じノードに対して シャードをアロケーションしないようにします。\nレスポンスボディのJSONのフィルタリング Elasticsearchは全ての情報を返します。 例えば、検索リクエストは_index、_type、_id、 _score、_sourceを返します。 しかし、全ての情報が必要でない場合があります。 また、これらのデータを遅いネットワークで転送することは 遅延の原因となります。\nユーザはこの検索メタデータを無効にするための特殊な設定を 行ったり、他のAPIのレスポンスのフォーマットを コントロールするための設定があります。 #10980の変更で、任意のレスポンスボディのJSONに対して、 必要な要素だけを取得する機能が追加されました。 filter_pathパラメータを使用します。\n例えば、検索リクエストからはtotal数と、各要素のhitsの配列を欲しい場合、 次のように指定します。\nGET _search?filter_path=hits.total,hits.hits nodes-info APIから各ノードのhttp_addressだけを取得したい場合は、 ノード名の部分にワイルドカード(*)を使用します。\nGET _nodes?filter_path=nodes.*.http_address 単一の*がJSON階層の1つの階層に対しての ワイルドカードとして機能します。 2つの**は複数階層に対してとなります。 複数のフィルタはカンマ区切りで指定可能です。 詳細についてResponse filteringをごらんください。\n共有ファイルシステムリポジトリに対するセキュリティフィックス 本リリースはsnapshot-restoreで使われる 共有ファイルシステムリポジトリに関するセキュリティ強化の変更が含まれます。 現在、Elasticsearchのユーザは、Elasticsearchプロセスによって書き込み可能 任意のディレクトリに.snapshotファイルを書き込むことができます。 #11284の変更で、リポジトリのために使用できるディレクトリを 強制的に指定できるようになりました。 適切なディレクトリがconfig/elasticsearch.yml設定ファイルの path.repoに指定される必要があります。\n次のように設定されたElasticsearchインスタンスはこのセキュリティ問題に対して影響を受けにくいです。\nrootではなくelasticsearchユーザとしてElasticsearchを実行 elasticsearchユーザがdataディレクトリに対してのみ 書き込み権限を持っていて、共有ファイルシステムリポジトリに対しても利用できる ファイアウォールやプロキシ、Shieldを使って、snapshot APIの実行を任意のユーザから実行されるのを防いでいる この問題をCVE-2015-4165としています。\n古いインデックスのためのUpgrade API Elasticsearch 2.0以降では、 Lucene 5ベースとなり、Lucene 3 （Elasticsearchのバージョンでは0.90以前） によって書き出されたセグメントを含んだインデックスを読み込むことが できなくなります。 これらの「古いインデックス」はLucene 4にアップグレードする必要があり、 2.0-compatibleとして印をつける必要があります。 そうしなければ、Elasticsearch 2.0に以降できないでしょう。\nupgrade APIは 、最新のLuceneフォーマットにインデックスにある全てのセグメントを アップグレードするためにすでに利用できます。 また、最新のフォーマットは性能向上やバグフィックスといった利点もあります。 さらに、2.0-compatibleとして古いインデックスをマークする設定も 書き込むことができます。 さらに、upgrade_only_ancient_segmentsオプションが Lucene 3のセグメントだけをアップグレードするために利用でき、 移行前の必要な処理を減らすことができます。\nKibanaユーザのためのハイライトの強化 KibanaユーザはElasticsearchのハイライトについて2つの点で問題を見つけていました。\nワイルドカードでフィールド名を指定した場合に、ハイライトに適さないフィールドも帰ってくる（日付や数値のフィールドなど） 古いインデックスが非常に大きなターム（\u0026gt; 32kB）を含んでいて、ハイライトが失敗する。 最近のバージョンでは、これらの大きなタームはインデックス時に除去される #11364の変更で これらの問題が修正されました。 ワイルドカードを利用したフィールド名では、stringフィールドのみを返し、非常に長いタームによる例外は無視するようになります。\nWindowsユーザのためのmlockall 速いGCはノードの安定性と性能について重要です。 小さなバイトのヒープでさえ、ディスクにスワップすることを許可してしまうと、GCに対して大きな影響が出てしまいます。 ですので、これらのコストは排除されるべきです。\nLinuxユーザはbootstrap.mloclall設定による恩恵を受けています。 これは、RAMにJVMのヒープを起動時にロックします。 #10887では、同様の機能をWindowsユーザにも提供します。\nより詳細なスクリプト設定 Scriptsはリクエストにインラインで指定できます。 .scriptsインデックスにインデックスもでき、config/ディレクトリ配下にファイルとして保存もできます。 これまでは、インラインかインデックスされたスクリプトの両方を同時に有効無効にすることが選択できましたが、 .scriptsインデックスをプロキシやShieldで保護することもできました。\n#10116で追加されたより詳細なスクリプトの設定で、インラインか、インデックスされたものか、ファイル化を個別に言語ごとに設定できるようになりました。 また、例えば、search APIではスクリプトを許可するが、update APIでは許可しないといったような設定も可能です。\n最後に ぜひ、Elasticsearch 1.6.0を試してみてください。 そして、感想をTwitter(@elastic)やWebフォーラムなどで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1433910662,"dir":"post/2015/","id":"55188a318c5998989255253e15ccc1f6","lang":"ja","lastmod":1433910662,"permalink":"https://blog.johtani.info/blog/2015/06/10/elasticsearch-1-6-0-released-ja/","publishdate":"2015-06-10T13:31:02+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.6.0 released 本日（6/9）、Lucene 4.10.4ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 1.6.0リリース（日本語訳）"},{"contents":"第10回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n今回も新規の方が結構いたような気がしました。 最終的に、124人がアプリでチェックインした形になりました。 直前にキャンセル待ちから繰り上がると来れない人がいますよねぇ。 多少キャパシティオーバーするくらいの人数で募集するのがいいのでしょうか。 あと、カードが2枚不明で。。。心あたりある人いないでしょうか？\nさて、いつもの通り簡単なメモです。\nElastic{ON}報告＋有償プラグインの紹介　Elastic Jun Ohtani @johtani スライド：elastic{ON}報告と商用プラグインの紹介\n少し時間が経ってしまいましたが、弊社初のカンファレンスelastic{ON}の紹介をしました。 約1300名の方に参加していただいたカンファレンスで、非常に盛り上がりました。 Microsoft、GitHubなど、いろいろな会社の方が話をしたり、弊社のエンジニアが濃い話をしたりと。 今回は、日本の方はいなかったですが、次回は日本からも参加してもらえると嬉しいです！\nあとは、5月に弊社にも日本の営業の人が入社したので、有償プラグインについて簡単ですが説明をしました。 プラグインなどに興味があるかたがいらっしゃいましたら、Twitterなどで連絡いただければと。 もちろん、弊社サイトからの問い合わせでも大丈夫です。\nカンファレンスの資料やビデオが弊社サイトで公開されています。 ぜひ一度見ていただければと。\nAWSで実現するelasticsearchの大規模運用 株式会社インティメート・マージャー　松田和樹さん　@mats116 スライド：第10回elasticsearch勉強会 公開用資料\nパブリックDMPのサービスの裏側でElasticsearchを利用しているというお話でした。 AWS Auto Scalingに詳しくないので、勉強しないといけないんですが、 リバランスがどのくらいの頻度で発生するのかはちょっと気になります。\nSSDを利用したり、doc valuesを利用したりと、性能を気にしながら利用されている点、負荷試験を行って検証されていたりと、 参考になる話でした。 今回はインフラ側の話に寄っていたので、今度はアプリ側でどんな使い方をしているかといった話を聞いてみたいですね！\nSpark in small or middle scale data processing with Elasticsearch　株式会社ビズリーチ 島本　多可子さん @chibochibo03 スライド：Spark in small or middle scale data processing with Elasticsearch\nScalaとSparkとElasticsearchで検索サービスを作っている話でした。 サービスのアーキテクチャの選別についての説明を順を追って説明していただきました。 失敗と言われていたアーキテクチャを見た時に、「あー、それは。。。」と思っていたら、 思った通りの改善案のアーキテクチャが出てきたので少しホッとしましたw\nJSONのクエリが辛いという話がありましたが、validate APIなどを利用してもらって、事前にチェックをしてもらうと 少しは改善できるかもなぁと。\nSparkをぼんやりとしかわかってないので、もう一度話を聴きたいなぁと思ったので、 押しかけて話を聴きたいと思います。\n話の中で出てきた自作のScalaのElasticsearchクライアントがHTTPのクライアントになった理由が知りたかったです。\nLT Elasticsearchのサジェスト機能を使った話　株式会社アイスタイル　渡邊 紘太朗さん @ktaro_w スライド：Elasticsearchのサジェスト機能を使った話\nぴったり5分でしたwまだ2年目なのにこんなにうまく話をしていただけるとは。。。\nGatling便利そうですね。サーバが1台しかないので、単一インデックスの方が性能が出るだろうなと。 Elasticsearchは1インデックスに対してデフォルトだと5シャードで、シャード単位でLuceneのインデックスが作成されます。 この話で行くと、18インデックスを作ると、かなりの数のファイルI/Oが発生するので、いろいろなインデックスに検索をすると キツいだろうなと。\nサジェストについての日本語の資料が少ないという事だったので、ブログを書いてもらえると嬉しいですw\nElasticsearchで作る形態素解析サーバ　株式会社エヌツーエスエム　菅谷信介さん スライド：Elasticsearchで作る形態素解析サーバ\nいつも発表ありがとうございます。私以外の最多発表者じゃないかという話でした。 今回はElasticsearchを形態素解析サーバにしてしまおうという話で、ちょっと面白い話でした。 Elasticsearch以外の場所で形態素解析したい場合には手軽に使えるかもしれないですし、Elasticsearchと同じ解析結果を別の場所で欲しい場合にも便利かも。\nextended analyze APIの紹介までしていただいて。。。\nちなみに、今は、extended analyze プラグインも指定したAttributeの情報だけ返せるようになってたり、 マルチバリューへの対応もしていたりします。 そのうち本家のanalyze APIに機能を取り込む予定です。（早くしないと）\n開発効率UP! Elasticsearch Client Tool 作ってみた　ナレッジワークス株式会社　木戸国彦さん @9215 スライド：開発効率アップ!Elasticsearch Client Tool 作ってみた\nHello Elasticsearch!にはお世話になっている人が多いんじゃないかなと。 今回はSublime Textのプラグインのお話でした。（すみません、Sublime Text使ってなくて。。。） AtomとかIntellijのプラグインもあるとうれしいなー\n変わり種プラグインの作り方　日本IBM　黒澤亮二さん スライド：変わり種プラグインの作り方\nElasticsearchの拡張ポイントの話と、簡単なプラグインの作り方と少しElasticsearch内部の話をしていただきました。 Foundの資料が上がってました。さすが。あそこのブログは面白い話が多いんですよね。 社内で実際に使われてる話とかも聞いてみたい！\nその他、感想などのブログ 第10回 Elasticsearch 勉強会へ参加してきた昨日の話 第10回elasticsearch勉強会 #elasticsearch #elasticsearchjp 第10回elasticsearch勉強会に行ってきました elasticsearch勉強会に登壇してきました まとめ 懇親会で24Fに移動していただくということで、少し手間をかけてしまいました、すみませんでした。 今回も初参加の方がそこそこいたんじゃないかなと。 あとは、AWSサミットがあるために上京してて参加しましたという方もいらっしゃいました。 大きなカンファレンスの期間の前後に行うとこんなメリットもあるんですね、今後の参考にしたいと思います。 次回は7/27を予定しています。CTOのShayが来日予定です！\nあと、東京以外の勉強会も検討しつつあります。興味のある方はコメントやTwitterで反応をいただけると嬉しいです。\nスピーカーは随時募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1433225196,"dir":"post/2015/","id":"75d9268739fe7787ac02d389ac605feb","lang":"ja","lastmod":1433225196,"permalink":"https://blog.johtani.info/blog/2015/06/02/10th-elasticsearch-jp/","publishdate":"2015-06-02T15:06:36+09:00","summary":"第10回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさ","tags":["elasticsearch","勉強会"],"title":"第10回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Reindex Elasticsearch With Logstash\nThanks David!\nマッピングを変更したり、インデックスの設定を変更したり、あるサーバから他のサーバや、 あるクラスタから他のクラスタ（例えば複数のデータセンターのような場合）にデータを再インデックスしたくなることがあるでしょう。\n後者のような場合はSnapshotやRestoreの機能を利用することもできますが、インデックスの設定を変更をしたい場合は その他の方法が必要になります。\nLogstash 1.5.0で、 elasticsearch inputとelasticsearch outputを使うことで、とても簡単に再インデックスができます。\nではやってみましょう。\n古いクラスタ elasticsearch 1.5.2 はすでにダウンロード済みとして、localhost:9200でoldという名前のクラスタを起動します。\nbin/elasticsearch --cluster.name=old クラスタにpersonという名前のインデックスが存在します。 これは、5シャードで、100万件のドキュメントを持っています。\n新しいクラスタ 次に新しいクラスタを起動します。 localhost:9201でnewという名前のクラスタを起動します。\nbin/elasticsearch --cluster.name=new こちらは、空です。\ncurl -XGET \u0026#34;http://localhost:9201/person\u0026#34; { \u0026#34;error\u0026#34;: \u0026#34;IndexMissingException[[person] missing]\u0026#34;, \u0026#34;status\u0026#34;: 404 } Logstashのインストール 次に、Logstash 1.5.0をダウンロードして、インストールします。\nwget http://download.elastic.co/logstash/logstash/logstash-1.5.0.tar.gz tar xzf logstash-1.5.0.tar.gz cd logstash-1.5.0 logstashの設定ファイルlogstash.confを次のように設定します。\ninput { # We read from the \u0026#34;old\u0026#34; cluster elasticsearch { hosts =\u0026gt; [ \u0026#34;localhost\u0026#34; ] port =\u0026gt; \u0026#34;9200\u0026#34; index =\u0026gt; \u0026#34;person\u0026#34; size =\u0026gt; 500 scroll =\u0026gt; \u0026#34;5m\u0026#34; docinfo =\u0026gt; true } } output { # We write to the \u0026#34;new\u0026#34; cluster elasticsearch { host =\u0026gt; \u0026#34;localhost\u0026#34; port =\u0026gt; \u0026#34;9201\u0026#34; protocol =\u0026gt; \u0026#34;http\u0026#34; index =\u0026gt; \u0026#34;%{[@metadata][_index]}\u0026#34; index_type =\u0026gt; \u0026#34;%{[@metadata][_type]}\u0026#34; document_id =\u0026gt; \u0026#34;%{[@metadata][_id]}\u0026#34; } # We print dots to see it in action stdout { codec =\u0026gt; \u0026#34;dots\u0026#34; } } 実行と修正 実行します。\nbin/logstash -f logstash.conf ドキュメントのチェックと修正 何が起きたでしょう？\ncurl -XGET \u0026#34;http://localhost:9200/person/person/AU1wqyQWZJKU8OibfxgH\u0026#34; { \u0026#34;_index\u0026#34;: \u0026#34;person\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;person\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;AU1wqyQWZJKU8OibfxgH\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;Tali Elyne\u0026#34;, \u0026#34;dateOfBirth\u0026#34;: \u0026#34;1955-05-03\u0026#34;, \u0026#34;gender\u0026#34;: \u0026#34;female\u0026#34;, \u0026#34;children\u0026#34;: 2, \u0026#34;marketing\u0026#34;: { \u0026#34;cars\u0026#34;: null, \u0026#34;shoes\u0026#34;: null, \u0026#34;toys\u0026#34;: null, \u0026#34;fashion\u0026#34;: null, \u0026#34;music\u0026#34;: null, \u0026#34;garden\u0026#34;: null, \u0026#34;electronic\u0026#34;: null, \u0026#34;hifi\u0026#34;: null, \u0026#34;food\u0026#34;: 846 }, \u0026#34;address\u0026#34;: { \u0026#34;country\u0026#34;: \u0026#34;Germany\u0026#34;, \u0026#34;zipcode\u0026#34;: \u0026#34;0099\u0026#34;, \u0026#34;city\u0026#34;: \u0026#34;Bonn\u0026#34;, \u0026#34;countrycode\u0026#34;: \u0026#34;DE\u0026#34;, \u0026#34;location\u0026#34;: [ 7.075943707068682, 50.72883500730124 ] } } } もう一方のクラスタと比較してみましょう。\ncurl -XGET \u0026#34;http://localhost:9201/person/person/AU1wqyQWZJKU8OibfxgH\u0026#34; { \u0026#34;_index\u0026#34;: \u0026#34;person\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;person\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;AU1wqyQWZJKU8OibfxgH\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;Tali Elyne\u0026#34;, \u0026#34;dateOfBirth\u0026#34;: \u0026#34;1955-05-03\u0026#34;, \u0026#34;gender\u0026#34;: \u0026#34;female\u0026#34;, \u0026#34;children\u0026#34;: 2, \u0026#34;marketing\u0026#34;: { \u0026#34;cars\u0026#34;: null, \u0026#34;shoes\u0026#34;: null, \u0026#34;toys\u0026#34;: null, \u0026#34;fashion\u0026#34;: null, \u0026#34;music\u0026#34;: null, \u0026#34;garden\u0026#34;: null, \u0026#34;electronic\u0026#34;: null, \u0026#34;hifi\u0026#34;: null, \u0026#34;food\u0026#34;: 846 }, \u0026#34;address\u0026#34;: { \u0026#34;country\u0026#34;: \u0026#34;Germany\u0026#34;, \u0026#34;zipcode\u0026#34;: \u0026#34;0099\u0026#34;, \u0026#34;city\u0026#34;: \u0026#34;Bonn\u0026#34;, \u0026#34;countrycode\u0026#34;: \u0026#34;DE\u0026#34;, \u0026#34;location\u0026#34;: [ 7.075943707068682, 50.72883500730124 ] }, \u0026#34;@version\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;@timestamp\u0026#34;: \u0026#34;2015-05-20T09:53:44.089Z\u0026#34; } } Logstashは@versionと@timestampフィールドを追加してしました。 これらを除去したいので、Mutate filter pluginのremove_fieldを使います。\nfilter { mutate { remove_field =\u0026gt; [ \u0026#34;@timestamp\u0026#34;, \u0026#34;@version\u0026#34; ] } } マッピングのチェックと修正 実際に、logstashは_sourceフィールドを既存のドキュメントから読み込み、 それらを新しいクラスタに直接投入しています。 しかし、logstashはマッピングについてはケアしていません。\n古いマッピングと新しいマッピングを比較するために、マッピングを取得してみましょう。\ncurl -XGET \u0026#34;http://localhost:9200/person/person/_mapping\u0026#34; { \u0026#34;person\u0026#34;: { \u0026#34;mappings\u0026#34;: { \u0026#34;person\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;address\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;city\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;country\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;countrycode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;location\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;geo_point\u0026#34; }, \u0026#34;zipcode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;children\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;dateOfBirth\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;date\u0026#34;, \u0026#34;format\u0026#34;: \u0026#34;dateOptionalTime\u0026#34; }, \u0026#34;gender\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;marketing\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;cars\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;electronic\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;fashion\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;food\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;garden\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;hifi\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;music\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;shoes\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;toys\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; } } }, \u0026#34;name\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } } } } curl -XGET \u0026#34;http://localhost:9201/person/person/_mapping\u0026#34; { \u0026#34;person\u0026#34;: { \u0026#34;mappings\u0026#34;: { \u0026#34;person\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;address\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;city\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;country\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;countrycode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;location\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;double\u0026#34; }, \u0026#34;zipcode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;children\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;dateOfBirth\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;date\u0026#34;, \u0026#34;format\u0026#34;: \u0026#34;dateOptionalTime\u0026#34; }, \u0026#34;gender\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;marketing\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;cars\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;electronic\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;fashion\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;food\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;garden\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;hifi\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;music\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;shoes\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;toys\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; } } }, \u0026#34;name\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } } } } これにより、いくつかの相違を発見できます。\n\u0026#34;location\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;geo_point\u0026#34; } \u0026#34;location\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;double\u0026#34; } データをインデックスする「前」に、実際に利用したいマッピングでインデックスを作成しておくことで、 この問題に対処できます。 この時点で、オリジナルのマッピングを望んだ形に変更することができます。例えば、アナライザを変更したりです。 また、インデックスの設定を新しく定義することもできます。 デフォルトでは、Elasticsearchは5つのシャードと各シャードに対して1つのレプリカを作成します。 しかし、この時点でもう一度変更することが可能です。\ncurl -XDELETE \u0026#34;http://localhost:9201/person\u0026#34; curl -XPUT \u0026#34;http://localhost:9201/person\u0026#34; -d\u0026#39; { \u0026#34;settings\u0026#34;: { \u0026#34;number_of_shards\u0026#34;: 1, \u0026#34;number_of_replicas\u0026#34;: 0 } }\u0026#39; curl -XPUT \u0026#34;http://localhost:9201/person/person/_mapping\u0026#34; -d\u0026#39; { \u0026#34;person\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;address\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;city\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;country\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;countrycode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;location\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;geo_point\u0026#34; }, \u0026#34;zipcode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;children\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;dateOfBirth\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;date\u0026#34;, \u0026#34;format\u0026#34;: \u0026#34;dateOptionalTime\u0026#34; }, \u0026#34;gender\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;marketing\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;cars\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;electronic\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;fashion\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;food\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;garden\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;hifi\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;music\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;shoes\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;toys\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; } } }, \u0026#34;name\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } }\u0026#39; さて、もう一度再インデックスしましょう！\nbin/logstash -f logstash.conf インデックスやタイプ名の変更 もちろん、インデックス名やタイプ名、IDを変更したい場合も変更が可能です！:)\nelasticsearch { host =\u0026gt; \u0026#34;localhost\u0026#34; port =\u0026gt; \u0026#34;9201\u0026#34; protocol =\u0026gt; \u0026#34;http\u0026#34; index =\u0026gt; \u0026#34;europe_people\u0026#34; index_type =\u0026gt; \u0026#34;someone\u0026#34; document_id =\u0026gt; \u0026#34;%{[@metadata][_id]}\u0026#34; } ","date":1432624090,"dir":"post/2015/","id":"23a22d1411afb787810d68210e6fad4f","lang":"ja","lastmod":1432624090,"permalink":"https://blog.johtani.info/blog/2015/05/26/reindex-elasticsearch-with-logstash-ja/","publishdate":"2015-05-26T16:08:10+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Reindex Elasticsearch With Logstash Thanks David! マッピングを変更したり、インデックスの設定を変更したり、あるサ","tags":["logstash","elasticsearch"],"title":"Logstashを使ったElasticsearchの再インデックス（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Join the Conversation: Discuss.Elastic.Co\n3つのOSSプロジェクトの開発をスケールアップし始め、 コミュニティサポートのために必要なやりとりに対してメーリングリストでは難しいということがわかってきました。 私たちは複数のメーリングリストを持っています。Elasticsearch、Logstash、そして英語以外の様々な言語のメーリングリストです。 このような状況では、あたらしい人たちはどこで質問をするのが良いのか混乱します。\nまた、メーリングリストの流量が増え、「参考になる話題」を見つけるのが難しくなってきました。 様々なユーザに採用してもらい、様々なユースケースが出てくることで、様々な質問が出てきています。 汎用的なメーリングリストではノイズの中から望んだ情報を見つけるのは難しいです。 また、ユーザ全てがメーリングリスト満足しているわけではありません。\nElasticは、ユーザの問題を解くことが大好きです。 コミュニティのメンバー皆さんに気に入っていただけるであろうソリューションを見つけ、フォーラムを https://discuss.elastic.co に移すことにしました。 ぜひ参加して、この新しいツールについてのご意見を聞かせてください。\nメーリングリストは好きだけど、ウェブフォーラムは苦手？問題ありません。 フォーラムにユーザプロファイル（GitHub、Facebook、Twitter、Google Appsのアカウントと連携するか、emailアドレスを利用すれば簡単に作れます）を作り、 email通知の設定をすればOKです。 これで、emailでのやりとりができるようになります。\n利用して、議論を楽しんでください。 もちろん、改善案などにかんするご意見もお待ちしています！\n","date":1432197903,"dir":"post/2015/","id":"615db1a24f36d19a8eaf18d4dceed6b2","lang":"ja","lastmod":1432197903,"permalink":"https://blog.johtani.info/blog/2015/05/21/join-the-conversation-ja/","publishdate":"2015-05-21T17:45:03+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Join the Conversation: Discuss.Elastic.Co 3つのOSSプロジェクトの開発をスケールアップし始め、 コミュニティサポー","tags":null,"title":"discuss.elastic.co にぜひ参加を"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.5.2 Released\n本日（4/27）、Lucene 4.10.4ベースのElasticsearch 1.5.1およびElasticsearch 1.4.5 をセキュリティバグフィックス版をリリースしました。 ダウンロードおよびすべての変更については次のリンクをごらんください。\n最新安定版：Elasticsearch 1.5.2 1.4系バグフィックス：Elasticsearch 1.4.5 本リリースはディレクトリトラバーサルの脆弱性のフィックスです。すべてのユーザにアップグレードを勧めます。\n過去のリリースに関するブログは以下のリンクを参照してください。\n1.5:1.4.1, 1.5.0 1.4:1.4.4,1.4.3, 1.4.2,1.4.1, 1.4.0, 1.4.0.Beta1 すべての1.5.2および1.4.5の変更についてはリンクをごらんください。以下では、セキュリティの問題について紹介します。\nディレクトリトラバーサル脆弱性の発見 1.5.2および1.4.5以前の全バージョンのElasticsearchで、ディレクトリトラバーサル攻撃に対する脆弱性がみつかりました。 攻撃者はElasticsearchを実行しているサーバからファイルを取得することができます。 この脆弱性はインストールしたばかりのElasticsearchには存在しません。 この脆弱性は\u0026quot;site plugin\u0026quot;がインストールされると露呈します。 ElasticのMarvelプラグインおよびコミュニティサポートの多くのプラグイン（例：Kopf、BigDesk、Head）がsite pluginです。 Elastic Shield、Licensing、Cloud-AWS、Cloud-GCE、Cloud-Azure、analysis pluginおよびriverプラグインはsite pluginではありません。\nこの問題をCVE-2015-3337としました。\nバージョン1.5.2と1.4.5はこの脆弱性に対して対策済みで、私たちはすべてのユーザにアップグレードを勧めています。\nアップグレードを望まないユーザはいくつかの方法でこの脆弱性に対して対応可能ですが、これらの方法はsite pluginを動作させなくします。\nsite pluginをインストールしているノードのelasticsearch.ymlのhttp.disable_sitesをtrueに設定し、Elasticsearchのノードを再起動 ファイアウォールもしくはプロキシを利用して、/_pluginへのHTTPリクエストをブロック すべてのsite pluginをすべてのElasticsearchノードからアンインストール この問題を報告していただいた、DocuSignのJohn Heasmanに感謝いたします。\n他の変更について インデックスされたスクリプトおよびテンプレートを上書きもしくは削除時に、キャッシュからも完全に削除する。 geo-shapeの多数のフィックス（distance_error_pctを利用した場合の、重要なprecisionに関するフィックスを含む） インデックステンプレートのデフォルトマッピングがバルクインデキシング中にも考慮するように修正 Shadowレプリカがファイルシステムの遅延に対する対障害性を向上し、プライマリシャードのよりスムーズなリロケーションをサポート geo-contextsをcompletion suggesterで使用した場合のマッピングのリフレッシュループを改善 いくつかの重要な変更がv1.4.5にバックポートされています。\n大きなシャードのリカバリを早くするためのシャードリカバリ中のマージを可能に \u0008* truncated translogsの操作をグレースフルに マージが遅くなる場合に、delete-by-queryを減速 ぜひ、Elasticsearch 1.5.2をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1430201648,"dir":"post/2015/","id":"8d7caf84b3a51cca27291c1f7cfc2d40","lang":"ja","lastmod":1430201648,"permalink":"https://blog.johtani.info/blog/2015/04/28/elasticsearch-1-5-2-and-1-4-5-released-ja/","publishdate":"2015-04-28T15:14:08+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.2 Released 本日（4/27）、Lucene 4.10.4ベースのEla","tags":["elasticsearch"],"title":"Elasticsearch 1.5.2 および 1.4.5リリース（日本語訳）"},{"contents":"第9回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n今回はトレーニングで来日していたIgorとNathanによる特別公演でした。 昨年同様、サムライズムの@yusukeさんに テキスト翻訳していただき、大変助かりました。ほんとうにすごかった。。。\nチェックイン数など 今回はチェックインした人：119名 キャンセルしなかった人：45名 でした。今回はキャンセル待ちのまま当日を迎えた人もいなかったので良かったかなと。 今回から懇親会ページを別にしてみました。本編の勉強会に参加登録していた方には何度かメールを出していたので、 見つけていなかった人は以内とは思うのですが、勉強会のページと間違える人がいたらしいという話を聞きました。 Doorkeeperで1イベントで複数のチケットにそれぞれの参加者数を設定できるようになると嬉しいかもなぁ。\nさて、いつもの通り簡単なメモです。 本当に簡単にですが。\nResiliency in Elasticsearch and Lucene / Igor Motov スライド：https://speakerdeck.com/elastic/resiliency-in-elasticsearch-and-lucene\n※上記スライドは少し古いバージョンです。公開されたら差し替える予定です。\nサンフランシスコで行われたElastic{ON}（弊社初のカンファレンス）で行われたセッションの 改良版といったところでしょうか。 話の中で登場した機能などのリンクをざっとアップしておきます。\nFielddata Doc Values Resiliency Status Kibana4: What\u0026rsquo;s New ? / Nathan Zamecnik スライド：未定\nKibana4の紹介をデモを交えてという感じでした。 こちらは、スライドよりもデモを見てもらうのが一番いいのですが。。。\nいくつかQAがあったので補足を。ちなみに、Issueのラベルに実装される予定のバージョンが付与されてたりします。\nQ：グラフをPDFでエクスポートとかできますか？ A：4.3.0で実装される予定です。関連Issueはこちら。https://github.com/elastic/kibana/issues/509 Q：巨大な数値の場合にKB、MBなどといった表示は可能ですか？ A：4.1.0で実装される予定です。関連Issueはこちら。https://github.com/elastic/kibana/issues/1543 Q：地図のズームを固定することはできますか？ A：4.1.0で実装される予定です。関連Issueはこちら。https://github.com/elastic/kibana/issues/1442 その他、感想などのブログ [Elasticsearch] 第9回 Elasticsearch 勉強会へ参加してきた まとめ 今回は特別バージョンでした。かなり詳しい話だったので面白かったと思います。 Kibanaはデモを見ていただけましたし。また、海外から人を呼べるといいなぁ。\n次回は6月ごろをめどに計画しようかと。 スピーカーは随時募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1429249314,"dir":"post/2015/","id":"7249710187cc2d983709e044dbc78d9d","lang":"ja","lastmod":1429249314,"permalink":"https://blog.johtani.info/blog/2015/04/17/9th-elasticsearch-jp/","publishdate":"2015-04-17T14:41:54+09:00","summary":"第9回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第9回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.5.1 Released\n本日（4/9）、Lucene 4.10.4ベースのElasticsearch 1.5.1 をリリースしました。 このリリースはElasticsearchの最新の安定バージョンとなります。\nすべての変更についてはdownload Elasticsearch 1.5.1 hereをごらんください。\n本リリースはシャードを新しいノードに配置するスピードを改善するためのバグフィックスを含んでいます。 シャードのリカバリーの最初のフェーズで、コピー元のノードからコピー先のノードへすべてのセグメントをコピーします。 このフェーズ中には登録、更新削除のリクエストはトランザクションログに記録され、リカバリが終了したあとに コピー先のノードでトランザクションログが再生されます。 シャードが大きい場合、トランザクションログに多数のイベントがたまってしまいます。\n以前では、新しいセグメントのマージはリカバリ中のコピー先のノードでは、実行できませんでした。 大きなトランザクションログは結果として、小さな新しいセグメントを多く生成し、リカバリのスピードに非常に影響を与えます。 Issue #10463は リカバリ中のコピー先のシャードのマージを可能にする変更です。\nその他の注目すべきバグフィックスは次のものになります。\n多くの削除によりバージョンマップがいっぱいになった場合にrefreshを実行するように変更(#10312) 多数のスナップショットを含んだリポジトリの管理の改善(#10366) 実験的な機能であるinner hitsのバグフィックス(#10388, #10353, #10309, #10235) 最後に、Riverが非推奨となりました、まだ見ていない場合は記事をご覧ください。\nぜひ、Elasticsearch 1.5.1をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1428892471,"dir":"post/2015/","id":"563864a949924c505985a168191dcb84","lang":"ja","lastmod":1428892471,"permalink":"https://blog.johtani.info/blog/2015/04/13/elasticsearch-1-5-1-released-ja/","publishdate":"2015-04-13T11:34:31+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.1 Released 本日（4/9）、Lucene 4.10.4ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 1.5.1リリース（日本語訳）"},{"contents":"Elasticsearch勉強会 in 名古屋を開催しました。 初の東京以外での勉強会です。 企画、セッションなどお手伝いいただいた@smogamiさん、@mzpさんありがとうございました！\nElasticsearch/ELK stack紹介 @johtani スライド：Introduction Elasticsearch\n初回（次回があるかはわかりませんが。。。）ということもあり、Elasticsearchの説明を行いました。 あと、LogstashとKibanaも。 Kibanaについては、手元の環境でいつものアクセスログのデモやなどを行いました。 また、LTの後に時間があったので、前回の勉強会で利用したチェックリストの説明なども。\nスタンドファームにおけるElasticsearch導入事例 @mzp さん スライド：後日アップ？\n\u0008* 使ってるのはKibana3\nアクセスログが保存されてたけど、活用できてなかった。 Fluentd、Elasticsearch、Kibanaをいれて、可視化してみた。 普通にログ検索が簡単にできて嬉しい システムのレスポンスの性能値などを可視化できるようにして性能改善中 Kibanaでログ分析を1年続けてみたら業務システムの保守と運用が捗った(仮) @smogami さん スライド：「Kibanaでログ分析を1年続けてみたら業務システムの保守と運用が捗った」\n名古屋でJavaの勉強会を主催してみたり（最近できてないけど） 導入するのになかなか大変だった（ファイアウォールだったりが）。。。 Kibanaを使ってどんなことをしてるのか？\n既存システムなどの機能の実行回数やレスポンス時間の推移 曜日ごとにもチェック どの機能がよく使われるのか？ 対象となっているシステムはJavaのシステム。 QA\nQ：ログの出力は新規に追加したのか？ A : ログの出力自体はLog4Jの設定を変更しただけ。もともと、各メソッドの開始と終了にそれぞれ時間が出力される仕組みがある。\nログの読み込み自体は自作ツールを利用。 飛び込みLT @dabits さん スライド：未定\nKibanaの使い道\nKPIツール エゴサーチツール - Twitterや2chなどのデータを解析ソーシャル分析みたいな感じ？ \u0008* ダッシュボードを用意してあげる場合もあるが、触っていろんな機能を試す人も。 感想・反省点など 30名弱の方に参加していただきました。ありがとうございました。 東京の勉強会でもそうですが、半分くらいが検索、半分くらいがログ解析関連に興味がある感じでした。 飛び込みLTもしていただけましたし。会場内限定の話もいくつか。\n場所 場所が少しわかりにくかったかなと。。。建物の入り口に看板がないので、1名に看板役として立っていただきました。 ただ、設備は充実していましたし、室内も綺麗でよかったです。\n懇親会 11名（+私）でした。美味しい手羽先などをいただきながら、Elasticsearch以外のことでも盛り上がりましたw。 また、名古屋の観光名所なども教えてもらったりと有意義な時間でしたw。\nということで、少しでもElasticsearch、Kibana、Logstashなどのユーザが増えてくれればうれしいかなと。 私抜きでも勉強会はできると思うので、今後も開いてもらえるとうれしいかぎりです。 初めての東京以外での勉強会でどんな感じの方が利用しているのか、興味があるのかといったことも知ることができました。\n関連ブログなど Kibana4活用事例を話しました その他（余談） コンパルという喫茶店のアイスコーヒー。ちょっと新鮮な体験でした。 あとは、日曜日に観光場所として教えてもらった、トヨタ産業技術記念館にも行ってみました。 一人だったけど、非常に楽しめました。実演とかあって、わかりやすいし。 トヨタが自動織機の会社が始まりだってのは知らなかった。\n","date":1428108439,"dir":"post/2015/","id":"24357fe145c869ec82fdfc8134a1a6d1","lang":"ja","lastmod":1428108439,"permalink":"https://blog.johtani.info/blog/2015/04/04/elasticsearch-study-session-at-nagoya/","publishdate":"2015-04-04T09:47:19+09:00","summary":"Elasticsearch勉強会 in 名古屋を開催しました。 初の東京以外での勉強会です。 企画、セッションなどお手伝いいただいた@smogamiさ","tags":["elasticsearch","勉強会"],"title":"Elasticsearch勉強会 in 名古屋を開催しました。#elasticsearch #elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.5.0 Released\n本日（3/23）、Lucene 4.10.4ベースのElasticsearch 1.5.0 をリリースしました。 このリリースはElasticsearchの最新の安定バージョンとなります。 多くのresiliency(復元性、弾力性) enhancementとバグフィックスを含んでおり、 すべてのユーザにアップグレードを推奨しています。\nすべての変更についてはdownload Elasticsearch 1.5.0 hereをごらんください。\n460PRという大量の変更を含む本リリースは、Elasticsearchをよりresilient(弾力のあるもの)にするために 費やされています。\nInner hits 本リリースで追加された、Elasticsearchに最もリクエストされたものの一つがinner hitsです。 これは、has_childもしくはnestedクエリにマッチした子のドキュメントを、各親ドキュメントと一緒に返すことができます。\n例えば、blogという親ドキュメントとcommentという子ドキュメントを持っているとします。 この時、\u0026ldquo;full text search\u0026quot;というコメントを持ったブログ記事を検索したいとします。\nGET /my_index/blog/_search { \u0026#34;query\u0026#34;: { \u0026#34;has_child\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;comment\u0026#34;, \u0026#34;score_mode\u0026#34;: \u0026#34;sum\u0026#34;, \u0026#34;query\u0026#34;: { \u0026#34;match\u0026#34;: { \u0026#34;body\u0026#34;: \u0026#34;full text search\u0026#34; } } } } } 上記のリクエストは、親のblogドキュメントを返します。 しかし、どのコメントが関係しているのかはわかりません。 関連しているコメントを検索して親ごとにグルーピングするために、 少し手間のかかる2回目のクエリを実行する必要があります。\nInner hitsがこれを変えてくれます。 inner_hitsパラメータを次のように、上記のクエリに追加するだけです！\nGET /my_index/blog/_search { \u0026#34;query\u0026#34;: { \u0026#34;has_child\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;comment\u0026#34;, \u0026#34;score_mode\u0026#34;: \u0026#34;sum\u0026#34;, \u0026#34;query\u0026#34;: { \u0026#34;match\u0026#34;: { \u0026#34;body\u0026#34;: \u0026#34;full text search\u0026#34; } }, \u0026#34;inner_hits\u0026#34;: {} } } } 検索結果の各blog記事に、inner_hitsという項目があり、そこに検索にヒットしたコメントの 上位3件（デフォルト値）が返ってきます。\n... \u0026#34;hits\u0026#34;: [ { \u0026#34;_index\u0026#34;: \u0026#34;my_index\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;blog\u0026#34;, \u0026#34;_id\u0026#34;: 1, \u0026#34;_score\u0026#34;: 3.68, \u0026#34;_source\u0026#34;: { ... }, \u0026#34;inner_hits\u0026#34;: { \u0026#34;comment\u0026#34;: { \u0026#34;total\u0026#34;: 16, \u0026#34;hits\u0026#34;: [ { \u0026#34;_type\u0026#34;: \u0026#34;comment\u0026#34;, \u0026#34;_id\u0026#34;: 5, \u0026#34;_score\u0026#34;: 2.79, \u0026#34;_source\u0026#34;: { \u0026#34;body\u0026#34;: \u0026#34;Full text search is the bomb\u0026#34; } }, { ... }, { ... } ] } } } ] ... inner_hits部分は、第2の検索リクエストに似ています。 sizeやfromパラメータを含めるくことで、挙動をカスタマイズできます。 また、検索から想像するであろう、ページネーション、ソート、ハイライト、_sourceフィルタリングなどといった機能もサポートします。\nInner hitsはparent-childおよび、nestedドキュメントをサポートします。 この機能は、現時点ではexperimentalラベルが付与されています。 このラベルは、この機能が将来変更されたり、削除されたりする可能性があるかもしれないことを意味します。 詳細については、Inner Hits documentationをごらんください。\nShadow replicas Elasticsearchはそれ自身の冗長性に常に気をつけています。 それは、レプリカシャード（各プライマリシャードの冗長なコピー）を持っています。 これは、プライマリシャードを失った時に、データをロスしないようにするためのものです。 レプリカシャードはまた、検索のスループットをスケールアウトするためにも利用できます。 多くのレプリカ（ノードを伴うことで。）はスループットを増加させます。\nしかし、ユーザによってはElsticsearchを分散ファイルシステム上でホスティングしており、すでに、 ファイルシステムがレプリケーションと冗長性を担当しています。 ファイルシステムが同じことしているので、各シャードのコピーを複数持つことはあまり意味がありません。\nShadowレプリカはノードを追加することによる検索スループットをスケールアウトすることが、 余分なストレージやインデキシングのコストを払うことなく、可能になります。 代わりに、各シャドーレプリカはプライマリシャードを持っている共有ファイルシステムにread-onlyでアクセスします。 Shadowレプリカは定期的にファイルシステムのビューをリフレッシュし、プライマリシャードのどんな変更も検知するでしょう。\nプライマリシャードが失敗したら、Shadowレプリカがプライマリに昇格し、 失敗したプライマリによって書き込まれたトランザクションログを読み込みリプレイできます。\nこの機能はexperimentalマークが付いています。詳細についてはShadow Replicas documentationをごらんください。\nResiliency improvements Elasticsearch 1.1 から 1.3では、インデックスのすべてのファイルのチェックサムを追加し、 それらのファイルが壊れているかどうかをチェックするために利用することにフォーカスしました。 1.4では、Zen discoveryと分散モデルについて大きな改良を加えました。\nこれらの変更にともなう、より詳細な統計情報やより詳細なロギングがElasticsearchやLuceneの以前のバージョンに存在した 未知の問題を明るみに出しました。 Elasticsearch 1.5.0では、これらの問題の多くに対処しています。\nElasticsearchとLuceneの以前のバージョンにあるバグがインデックスの故障を引き起こしていました。\nチェックサムコードのおかげで、これらを発見できました。現在は、Elasticsearchの起動時に自動的にLucene3.x\n(Elasticsearch 0.20.x以前)が作成したセグメントを検知して、シャードをオープンする前に、新しいフォーマットを使って、 新しいコミットポイントを書き出します。(#9899)\n1.3.xもしくは以前のバージョンからローリングアップグレードは、ローカルのシャードデータを再利用しようとせずに、\nシャード全体をコピーしようとします。1.3.2と以前のバージョンが実行されているノードからローリングアップグレードすることは 圧縮をオフにしない限りできなくなりました。(#9925)\n1.3.xやそれ以前のバージョンからアップグレードする場合、ローリングアップデートする代わりにクラスタの再起動を考えたほうがいいかもしれません。\n非同期環境は予測することが難しいです。時に、最も予測していないことが起きるからです。\nシャード配置、リカバリ、削除のコードの多くが単純化され、状態変更をよりアトミックで決定的にするための変更によりリファクタリングされました。\n(#8720, #9799, #9784, #9801, #9083, #8579, #8436, #8092, #9902, #6644, #8350, #9770, #9616, #9439, #8350, #8494)\n同様に、変更はクラスタ状態の更新が常に前進するということを確実にしました。更新の受け取り順序が順不同であったり、\nマスターだったノードからの更新を受け取った場合に混乱させていました。 (#9632, #9541, #9503)\nチェックサムとチェックサムのバリデーションの強化(#8723,\n#8599, #8587, #8407, #8010, #8018)\ndisk threshold allocation deciderを速く(#8803)、賢く(#7785)、自動化(#8270)\nauto-generated IDの利用時のインデキシングのスピードアップのためのに追加された最適化を除去。\nたまにドキュメントを重複して登録するため(#7729)\nDownload now ぜひ、Elasticsearch 1.5.0をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1427859496,"dir":"post/2015/","id":"19ecbaa5e12f7a9ebcff703c79534a52","lang":"ja","lastmod":1427859496,"permalink":"https://blog.johtani.info/blog/2015/04/01/elasticsearch-1-5-0-released-ja/","publishdate":"2015-04-01T12:38:16+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.0 Released 本日（3/23）、Lucene 4.10.4ベースのEla","tags":["elasticsearch"],"title":"Elasticsearch 1.5.0リリース（日本語訳）"},{"contents":"サンフランシスコからこんにちは。\n今、私は、弊社初のユーザカンファレンスelastic{ON}に 参加するために、初のアメリカ出張中です。 初のユーザカンファレンスですが、世界各国から約1300人！の登録がありました。\n本日が初日（Welcome Receptionが昨晩開催されましたが）です。 初日のキーノートで重要な発表が2つありました。\nブランド名の変更（Elastic: For - You Know, More Than Search） Found.noの加入（Welcome Found） です。\n昨日までは、elasticsearchでした。 本日からは、elasticになります。 ブランド名の変更と同時にサイト、ロゴなども変更されました。\nもう一つのビッグニュースがFoundの加入です。 found.noはElasticsearchをクラウドサービスとして提供している会社です。 彼らがジョインすることで、elasticsearchをより気軽に利用できるような環境ができてきます。\nKeynoteでの驚きのニュースこれらでした。 もちろん、このカンファレンスはそれだけには止まりません。\nNetflixやGitHub、Verison Mobile、WikimediaといったElasticsearch,ELKスタックのユーザの話や、 弊社の人たちによる今後のロードマップや私たちの考え方など多岐にわたる話を聞くことができます。\nこのような機会を今後も提供できるような会社になれるよう、頑張っていきたいなと思っています。\nちなみに、弊社のカンファレンスは私がこれまで経験したことのないカンファレンスになっています。 DJや各種ゲーム（ビリヤードとかパックマンとか）が楽しめるようなパーティが 懇親会として開催されたり、スポンサーブースでウェルカムレセプションが行われたりと、 面白い取り組みにあふれています。 次回開催されることがあれば、ぜひ日本の方達にも参加してもらえたらうれしいなと。\n","date":1426059991,"dir":"post/2015/","id":"ced9df0d8c8ed14de91c509b31b4c4ae","lang":"ja","lastmod":1426059991,"permalink":"https://blog.johtani.info/blog/2015/03/11/attend-elasticon/","publishdate":"2015-03-11T16:46:31+09:00","summary":"サンフランシスコからこんにちは。 今、私は、弊社初のユーザカンファレンスelastic{ON}に 参加するために、初のアメリカ出張中です。 初のユ","tags":["elastic","elasticon"],"title":"#elasticon に参加中"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：you know, for security: shield goes ga\n1/27にShield 1.0 をリリースしました。 Elasticsearch向けの私たちのセキュリティプラグインの最初のリリースです。 11月にShieldについてアナウンスしてから、Elsaticsearchのためのセキュリティの機能は、 一般的に望まれているものから始まり、具体的な考えと実行できる計画へと変遷し、それが、いま現実となりました。\n十分にセキュアな環境に、Elasticsearchクラスタをセキュアな状態でデプロイできるようにするため、 私たちは継続的にカスタマーやユーザーからのリクエストを受け取り、統合されたソリューションになるようにしてきました。\n私たちは、そのようなプロダクトがどうあるべきか調査することから始め、 カスタマーとユーザが必要とするセキュリティとはどんなものかを理解するために多くの時間を費やしました。 その結果がShieldです。 Shieldは、ElasticsearchクラスタをセキュアにするElasticsearchの有償プラグインです。 私たちは、ShieldをDev、Gold、Platinumサブスクリプションの一部として、追加料金なしで提供します。\n最初のリリースでは、基本的な機能と基盤にフォーカスしています。 Elasticsearch自身に対しても、セキュリティに対して準備してきました。 拡張性の側面だけでなく、Elasticsearchにあるデータフローについても再考してきました。 Elasticsearchクラスタをセキュアにする場合に、具体的な価値を即座に届けるだけでなく、素早く拡張できるようにも開発しました。\n機能 Shield 1.0は次の5つにフォーカスしています。\n認証(Authentication) 認可(Authorization) 暗号化通信とノードの認可(Encrypted Communication \u0026amp; Node Authentication) IPフィルタリング 監査証跡(Audit Trail) 認証(Authentication) セキュリティの大部分はアイデンティティについてです（例えば、だれがこのAPIを呼び出したのか？システムに何のサービスが接続するか？など） サービスのライフタイムのある時点で、サブジェクト（例えばユーザー）を現在実行中のサブプロセスなどに結びつけることです。 この関係性を持つためには、サブプロセスを実行する前にユーザの身元を確認するように命じます。 ユーザの身元の確認のプロセスをAuthenticationと呼び、ElasticsearchのすべてのAPIコールでそれが実行されます。\n認証の手法は多くの異なるものがあります。 それぞれの手法は、ユーザが認証されたという資格（Authentication Token）を、それぞれのタイプで提供するようにユーザに要求します。 Shield 1.0ではシンプルに、必要なauthentication tokenをユーザ/パスワードペアとしています。 （これは、Shieldの認証基盤が簡単に拡張でき、将来は異なるauthentication tokenもサポートできることを意味します。）\nユーザの資格を受け取ることだけでは不十分で、次に、それらをチェックする必要があります。 Shieldでは、これはレルムの責務です。 レルムは認証プロバイダ/サービスとしてみることができます。 妥当なユーザであると判断/解決されたか、 authentication tokenが適切な資格を持っていない/単に知らないユーザであるということで、拒否されたかです。 Shieldの認証メカニズムでは、複数のレルムを設定でき、さらに、あるレルムの戻り値を扱う他のレルム、というようなchainとすることもできます。 Shield 1.0は3つのレルムをサポートします。\nesusers - Elasticsearchによって管理されるファイルベースのレルムです。 これは、ファイルにユーザを定義することができます。（Apacheサーバのhtpasswdファイルのようなもの） このレルムは外部への依存はなく、Shieldをインストールすれば、デフォルトで使用できます。 このレルムは配置が簡単で、マルチテナントなElasticsearchクラスタに対して使用できます。 マルチテナントなElasticsearchクラスタとは、クラスタを複数のアプリでシェアすることをテナントと言います。 また、すべてのユーザがパスワードを忘れてしまうような\u0026quot;emergency\u0026quot;な代替レルムも対応可能です。 (誰もシステムに入れないような状況のことです) LDAP - 外部のLDAPサーバでユーザを認証するレルムです。 このレルムは組織のLDAPサーバで管理/保存されているユーザをすでに持っている組織を対象としています。 Active Directory - LDAPのタイプの1つで、Active Directoryに対する設定になります。 レルムはelasticsearch.yml設定ファイルで、次のように設定可能です。\nshield.authc realms:\nesuser: type: esusers order: 0 ldap: type: ldap order: 1 url: ldaps://url/to/ldap1/server ldap_fallback: type: ldap order: 2 url: ldaps://url/to/ldap2/server 上記のようにrealmsが一つのチェインとして参照されます。 レルムごとに、設定された順序で、それらは参照されます。\nNOTE : Shieldには、esusersファイルに保存されたユーザを管理するためのコマンドラインツールもあります。\n認可(authorization) 認可(Authorization)は保護されたリソースにアクセスするユーザを許可するか拒否するかということです。 モダンなシステムは、ユーザのパーミッションのために、ロールベースのアクセスコントロール（RBAC）モデルを利用します。 このモデルでは、各ユーザはロールの集合に関連していて、それぞれのロールには、パーミッションの集合が定義されています。 これは、洗練された設定で、パーミッションを機能的なグループで共有させることができます。 例えば、次のようなロールを定義したとします。\nemployee - すべての従業員は部門をまたいだ会社のデータへアクセスできます（例えば、コンタクトやディレクトリ情報など） sales - すべての営業職は営業データにアクセスできる（例えば、流通ルート、ルート、顧客） finace - すべての財務の従業員は財務データにアクセスできる（例えば、予算、経費、伝票） 財務部門のAnnは従業員と財務のロールを持っており、会社のディレクトリと財務データにアクセスでできます。\n認可プロセスはユーザがリクエストに関連したユーザが必要で、このプロセスのために、認証フェーズの後に直接実行されます。\nShieldは2つのタイプのリソースを定義します。クラスタとインデックスです。 これらは、すべてのAPIコールで保護されます。 さらに、それらに関連したパーミッションとロールも定義できます。 一度定義をすると、ロールはユーザもしくはLDAP/ADのグループに関係します。 ロールはroles.yml設定ファイルで定義されます。 設定のサンプルは次のようになります。\nadmin: cluster: all indices: \u0026#39;*\u0026#39; : all monitor: cluster: monitor indices: \u0026#39;*\u0026#39;: monitor employee: indices: \u0026#39;company_directory\u0026#39; : read sales: indices: \u0026#39;opportunities\u0026#39; : read, write \u0026#39;accounts\u0026#39; : read, write finance: indices: \u0026#39;expenses\u0026#39; : read, write \u0026#39;purchases\u0026#39; : read, write 上記のサンプルで、次の5つのロールを定義しています。\nadmin - 管理者のロールで、すべてのクラスターレベルの操作とすべてのインデックスに対してすべてのインデックスレベルの操作を実行可能です。 (¥*インデックスはすべてのインデックスにマッチするワイルドカード) monitor - システム/クラスタのモニタリングのためのロール。このロールのユーザはすべてのクラスタとインデックスレベルの情報の読み取りの APIにアクセス可能だが、インデックスのデータへの読み書きや設定の更新は不能 employee - compnay_directoryにあるすべてのデータへの読み取りアクセスを与えられたロール。このロールはクラスタレベルへのアクセスやデータの書き込みアクセスは持っていない (特にcompany。洗濯されたグループの人々はcompanyディレクトリの更新は可能だが、employeeは読み取りのみが可能) sales - opportunitiesとaccountsインデックスの読み書きができるロール finance - expensesとpurchasesの両方に読み書きができるロール 上記のサンプルで定義されているallとreadとwriteとして名前がつけられた権限です。 これらは、予約語で、Elasticsearchのローレベルのアクションを複数含んだ権限です。 （writeはindex, delete, delete_by_query, bulk, updateの操作を含んでいます。） 多くのケースで、これらのハイレベルの名前が付けられた権限で十分ですが、特定のロールに特定のアクションを明示的に指定することもできます。 次のようになります。\nhr: indices: \u0026#39;company_directory\u0026#39; : indices:data/write/index, indices:data/write/update ここまで説明した認可のレルムは、各ユーザに関連するロールを識別するためのものです。 内部のesuserレルムでは、提供されるesuserコマンドラインツールを使ってロールはユーザに割り当てたり変更したりもできます。 LDAPやActive Directoryでは、LDAP/ADグループにShieldのロールを割り当てることができます。\n認証と認可の両方を用いることで、ユーザリクエストに対して、ユーザごとに許可/不許可をすることができます。\n暗号化通信 認可はElasticsearchのデータを機能的な観点（許可されたユーザだけが操作を可能にする）で保護しますが、 クライアントからElasticsearchクラスタへ、もしくはクラスタのノード間では暗号化されていないデータを送るためまだ危険があります。 第三者が登頂したり、オンザフライでデータを書き換えたりといった可能性やクラスタを壊すことができます。\nShield 1.0はElasticsearchのすべての通信チャネルをセキュアにすることができます。 クラスタ内のノード間のチャネルやクライアントに公開されているチャネルです。 これは、SSL/TLS通信を導入して実現します。\nShieldで使えるSSLはElasticsearchのtransportサービスをSSL/TLSで通信できるものに置き換えます。 これは、ノード間通信チャネルと、HTTP transport（REST APIを提供するもの）のそれぞれに設定可能です。\nShieldのSSL/TLSは、スタンダードなJavaのものとkeystoreとtruststoreを基本にしたものが利用可能です。 SSL/TLSを設定すると、各ノードのキーストアに証明書をインポートする必要があります。 CAがサインした証明書を使うことも、CAが信頼したものとして許可許諾されたものを使うことが可能です。 これは、信頼されたすべてのCAとして知られているtrust storeが必要です。 新しいノードをクラスタに追加するときに、すべての必要な少なくとも一つの信頼されたCAから発行されてサインされたものが必要になります。 クラスタで個別のノードがすべてのkeystore/truststoreを更新する必要性なしに。？？\n通信チャネルを安全にする方法やSSL/TLS設定をどのように行うかはShieldのドキュメントをご覧ください。\nノード間認証 強く推奨しますが、許可されたノードだけがクラスタに接続できるようにするために、ノードの認証をSSL transportに設定することができます。 これは、shield.transport.client.authにtrueを設定することで可能です。 設定した場合、ノード間でSSLハンドシェイクが行われ、接続されたノードが接続に来たノードのクライアント認証を要求しチェックします。 もし、チェックに失敗した場合は、SSLシェイクハンドが失敗し接続が拒否されます。\nSSLクライアント認証 transportレベルでノード認証が必要なようなら、次のような疑問がわくでしょう。 Elasticsearchはクラスタに接続するTransportクライアントを使うときはどのように振る舞うのか？ Transportクライアントはクラスタの他のノードと同じチャネルを使うため、コネクションを確立するときに、ノードが他のノードと異なるかどうかを見極めることはできません。\nこの時、もっとも単純な解決は、Transportクライアントも同様に許可を与えることです。 それは、認証を解決するときに、他の問題（潜在的な悪意）を引き起こします。 Transportクライアントが他のクラスタのノードを偽装しようとすることです。これは望んでいません。\n幸いなことに、良い解決方法があります。 トランスポートプロファイルです。 Elasticsearch 1.4で導入されたトランスポートプロファイルは、トランスポートレイヤー（異なるホスト/ポートにバインドされる）のために複数のネットワークチャネルを設定することができます。 Shieldはこのサポートを、プロファイルごとに異なるSSL設定をできるように拡張します。 また、ノードのタイプとクライアントプロファイルタイプの間に明確な違いを設定することも可能です。 これを用いると、2つのプロファイルを設定できるようになります。 ひとつは、クライアントのためのもので、もうひとつはクラスタのノードのためのものです。 これにより、クライアントのための認証の問題が必要なくなり、Shieldはクライアントプロファイルをもった限定されたクライアントからのリクエストを保証します。\nIPフィルタリング これは、厳密には、認証カテゴリではありませんが関係しています。 Shieldはそれ自身がIPフィルタリングのメカニズムを持っています。 これは、許可/不許可のIPのリストを設定することができます。 これらのフィルタリングのルールは複数のレベルで設定可能です。 transportチャネル、transportプロファイルレベル、そして、HTTPチャネルです。 次の設定は、それらの設定のサンプルです。（設定ファイルはelasticsearch.ymlになります）\nshield: transport.filter: allow: - \u0026#39;127.0.0.1\u0026#39; - \u0026#39;2001:0db8:1234:0000:0000:8a2e:0370:73 deny: - \u0026#39;10.0.0.0/8\u0026#39; - \u0026#39;2001:0db8:1234::/48\u0026#39; - \u0026#39;*.google.com\u0026#39; http.filter: allow: [ \u0026#39;10.0.0.0/8\u0026#39; ] deny: [ \u0026#39;127.0.0.1\u0026#39; ] transport.profiles: client: shield.filter.deny: [ \u0026#39;_all\u0026#39; ] このように、IPv4とIPv6、CIDR、ホスト名、ワイルドカードが利用できます。 また、この機能はホストOSのIPテーブルに設定することで追加できるが、Shieldにそれを保持し、それらの設定を単純化し、 デプロイの全体から除去できることにも注意してください（詳細はドキュメントのIPフィルタリングをご覧ください）。\n監査証跡（Audit Trail） セキュアなシステムの必須機能の一つで、監査硝石により、Elasticsearchに発生した重要なイベントをトラッキングすることが可能です。 これらのイベントを保存することは、Elasticsearchクラスタの重要なアクティビティの証拠を提供でき、 不審な/悪意のある可能性のあるイベントを追跡するときの診断ツールにもなります。\nShield 1.0.0で、監査証跡は監査/アクセスlogを一般的なElasticsearchのログとは個別に保存します。 それらは、構造化されているため、読んだりパースするのが容易で、イベントのタイプも分類されています。 また、情報のレベルを設定することができ、各イベントをlogレベルの設定で書き出すことができます。 以下が、イベントのリストです。\nanonymous_access_denied - 認証トークンがないユーザからのリクエストがあった時のログ authentication_failed - リクエストされたユーザの認証に失敗した時のログ access_denied - 認証されたユーザが許可されていない操作を実行した時のログ access_granted - 認証されたユーザが許可された操作を実行した時のログ tampered_request - 不正に書き換えられたリクエストが到着したのを検知した時のログ connection_granted - ノードもしくはtransportクライアントがIPフィルタのルールにパスした時のログ connection_denied - ノードもしくはtransportクライアントがIPフィルタリングルールの制限により却下された時のログ Shieldの監査証跡についてより詳しく知りたい方は、ドキュメントをごらんください。\n次のバージョンでは？ ここまで紹介したように、これはまだ始まりにすぎません。 Shieldに追加される多くの機能があり、しっかりとした基盤を構築したところです。 Shieldの次のバージョンでは、以下の機能の追加にフォーカスするでしょう。（これらだけに限ったわけではありません。）\nAPIによる設定、管理 より拡張され、柔軟なLDAP/Active Directoryサポート レルムタイプの追加（kerberos、anonymous、certificatesなどなど） セッションベースの認証 ShieldはElasticsearch社の2番目の（Marvelに続く）商用プロダクトです。 ダウンロードして開発環境で評価してください。 インストールは他のプラグインと同様の方法です（インストール方法についての詳細はこちら）。 一度インストールすると、30日の試用ライセンスが始まります。 もし、さらに時間が必要な場合は、sales@elasticsearch.comまで連絡してください。\n私たちのすべてのプロダクトについてフィードバックをお待ちしています。 Shieldの商用利用、機能、ロードマップ、その他のセキュリティに関するトピックなど、質問がありましたら、 サイトからご連絡ください。\n","date":1425030596,"dir":"post/2015/","id":"cb13b64d0127c13bb466c4d4677a7b8a","lang":"ja","lastmod":1425030596,"permalink":"https://blog.johtani.info/blog/2015/02/27/you-know-for-security-shield-goes-ga-ja/","publishdate":"2015-02-27T18:49:56+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：you know, for security: shield goes ga 1/27にShield 1.0 をリリースしました。 Elasticsearc","tags":["elasticsearch","shield"],"title":"セキュリティ向けプラグインShieldのリリース（日本語訳）"},{"contents":"4月13日から3日間、ElasticsearchのCoreトレーニングが東京で開催されます。 Early Birdということで、3/14までに申し込みすると割引があります。 興味のある方は、見ていただければと。\nまた、4/15にElasticsearch勉強会を開催します。 トレーニングに弊社のエンジニアが来日しますので、なにか話をしてもらう予定です。\n募集は後日、Elasticsearch勉強会のDoorkeeperで行います。 興味のある方は、登録しておいていただければと。\nトレーニングや勉強会でお待ちしております。\n","date":1425024629,"dir":"post/2015/","id":"f2cbe07bf2ff16d5a5860b4d6edbc5e8","lang":"ja","lastmod":1425024629,"permalink":"https://blog.johtani.info/blog/2015/02/27/2nd-tokyo-training/","publishdate":"2015-02-27T17:10:29+09:00","summary":"4月13日から3日間、ElasticsearchのCoreトレーニングが東京で開催されます。 Early Birdということで、3/14までに申し込みす","tags":["elasticsearch"],"title":"Elasticsearch Coreトレーニング開催"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：kibana 4. literally.\nKibana 4は現在、文字通り、抽象的に、概念的に、精神的に、そしてとても楽しく、プロダクションレディになりました。 1週間前に準備はできていましたが、満足できるものであるという確信を得たいと思っていました。 そして、Kibana 4.0.0 GAをリリースしました。 次のものはサンプルのスクリーンショットと前日譚です。 これらに興奮してしまった方のために、2ステップのプランを用意しました。\nダウンロードする：Kibana 4 downloadsページからダウンロードします。 理解する：Kibana 4 docsページを読んで理解します。 Tip : もし、まだ、あなたのクラスタがElasticsearch 1.4.4でない場合は、アップグレードする必要があります。\nTip2 : Kibana 4 RC1からアップグレードする場合は、configを移行する必要があります。こちらのgistを参照\n前日譚 - the back story Kibanaはすでに問題解決のためのツールになっています。 なぜ、毎晩2時に呼び出されるんでしょう？ そのコードがプロダクションに入ったのはいつですか？ その結果、何を壊しました？ 私たちはそれらを解決しました。 世界的に、長い間、だれも夜中の2時に呼び出されませんでした。知ってます？。\n*しかし、ここには落とし穴があります。*答えが簡単になれば、問題が難しくなります。 楽な勝利は簡単でした。では、難しい問題（深さが3層の問題）を解きましょう。 複数の要素、複数のフィールドそして、複数のデータソースを分析する必要がある問題を解きましょう。 Kibana 4は少ない時間と労力で最も難しい問題を解決してくれます。\nKibana 3で学んだことをKibana 4に取り込みました。 なぜ10億のデータを持っているのに、地図には1000個しかプロットできないのでしょう？ 1つのチャートに1つのフィールドなんでしょう？ なぜ、1つのパネルに1つのチャートなんでしょう？ なぜ、1つのダッシュボードに1つのインデックスなんでしょう？ 5つのシナリオを用意し、2つのフィールドにまたがったデータを比較し、 1つのダッシュボードに3つのインデックスのデータを表示してみましょう。 さぁ、やりましょう。終わったらアイスクリーム（トッピング付きの）を取りに行きましょう。\nthe plot アイスクリームのように、問題には多くの種類があります。 そのために、Kibanaをナポリ風アイスクリーム（3色アイス）のように分割しました。 嫌いな種類は除いて。 もし、あなたがKibanaのユーザ歴が長い場合、最初のタブのDiscoverがホームであることが正しく感じるでしょう。 これにより、短時間で、検索し、レコードを見つけ、簡単な問題を解決できます。 簡単な問題とは、すべてを物語る1行のデータを見つけることによって解決する問題です。\n物事が簡単な検索で説明できるものよりも複雑になった時、チャートとグラフで魔法を作る時間です。 Visualizeタブを開き、Elasticsearchのaggregationの力を利用してデータを解析しましょう。 Visualizeは複数の次元の性質のデータを見せ、今まで尋ねたことがないような質問に対して素早く回答するチャートやテーブル、 地図を作成できます。 あなたが最初に尋ねる質問は「先週サイトが遅かったのはなぜ？」でした。 しかし、データによって明らかにされた質問は「なぜ、クリスマスに東京からの平均ファイルサイズリクエストがスパイクしたのか？」です。\n最後に、Dashboardでこれらを1つにします。\n大きなスクリーンに配置して、こう言います。 「あなたの答えはこのリンクにあります。また、Wikiに埋め込んで、データをCSVにエクスポートしてメールしました。 アイスクリームを食べた後に、自叙伝の第1章を書きました。もっとアイスを持ってきてください。かき混ぜますから。」\nそれぞれのタブで見てきた詳細については、Kibana 4 Beta 1 : Releasedをごらんください。\nto be continued\u0026hellip; 居眠りをする時間はあります？いいえ、Kibana 4.1についてすでに作業中で、将来の大きなプランを持っています。 多くの労力はKibana 4の土台の安定と実用性を構築することに使われました。 また、Elasticsearchアプリケーションの将来を構築するプラットフォームを作りました。 すべてのものは拡張できるように設計されています。 例えば、可視化はより良くなるように構築されています。 オープンソースは私たちのGitHubアカウント以上のものです。 それは、新しく素晴らしいものを誰もが作ることができる構造を作ることが私たちの約束です。\nKibanaでグラフなどを構築したり、Elasticsearchを利用したアプリケーションを作成するために、 私たち開発者のブログを参考にしてください。 ちょっと見てみたいですか？ Elastic{ON}15のSpencer Algerのトークをチェックしてください。\nあなた方なしでは、私たちはここにはいないですし、あなた方の助けがなければ何もできません。 ぜひ、GitHubでのissueや提案、貢献をお待ちしています。 もしくは、IRCでFreenodeの#kibanaに参加してください。\nextra credit Kibana 4のすべての話に興味がありますか？私たちのKibana 4ベータに関する過去のブログをチェックしてください。\nKibana 4 Beta 1: Released Kibana 4 Beta 2: Get it now Kibana 4 Beta 3: Now more filtery Kibana 4 RC1: Freshly baked 最後に、Kibanaの利用に関する話をお持ちなら、ぜひ聞かせてください。 stories at elasticsearch dot comもしくは@elasticsearchに連絡をください。 あなたの話を世界にどのようにシェアしているかごらんください。\n","date":1424408752,"dir":"post/2015/","id":"eee039f49a5b570599cf459c55c649f3","lang":"ja","lastmod":1424408752,"permalink":"https://blog.johtani.info/blog/2015/02/20/kibana-4-literally-ja/","publishdate":"2015-02-20T14:05:52+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：kibana 4. literally. Kibana 4は現在、文字通り、抽象的に、概念的に、精神的に、そしてとても楽しく","tags":["elasticsearch","kibana4"],"title":"Kibana 4（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch 1.4.4 and 1.3.9 released\n本日（2/20）、Elasticsearch 1.4.4とElasticsearch 1.3.9をリリースしました。 これはバグフィックスリリースとなります。 主に、Lucene expression scriptsを使う場合のRPMとDEBパッケージの パッケージング問題のフィックスをしたものです。 1.4.4のダウンロードこちらのリンクからアクセスできます。\nfixes 1.4.3のRPMおよびDEBパッケージにはAntlrとASMの依存関係の不足がありました。 この依存はElasticsearchでLucene expression scriptsを利用する場合に必要になります。 Groovyに関する1.4.3の変更により、多くのユーザがLucene explression scriptsを利用することが予想されるため、すぐに、1.4.4をリリースしました。\nまた、このリリースには、クラスタの保留タスクに関するいくつかのバグフィックスも含まれています。 さらに、date histogramで負のインターバルの場合にOutOfMemoryErrorを引き起こすバグも 修正されています。\nすべての変更については1.4.4のリリースノートおよび1.3.9のリリースノートをごらんください。\nフィードバック 私たちはフィードバックをお待ちしています。 Twitter(@elasticsearch)もしくはGitHub issues pageで教えてください。\n","date":1424408734,"dir":"post/2015/","id":"ddd3e6f6e298d3884abc4d888a043664","lang":"ja","lastmod":1424408734,"permalink":"https://blog.johtani.info/blog/2015/02/20/elasticsearch-1-4-4-and-1-3-9-released-ja/","publishdate":"2015-02-20T14:05:34+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.4 and 1.3.9 released 本日（2/20）、Elasticsearch 1.4.","tags":["elasticsearch"],"title":"Elasticsearch 1.4.4および1.3.9リリース（日本語訳）"},{"contents":"来る、4月4日の土曜日の午後に名古屋でElasticsearch勉強会を開催予定です。 「初」の東京以外の勉強会です。\nTwitterでこのようなツイートを見かけまして。\n名古屋でElasticsearchの勉強会やりたい機運（今のところ2人）。\n\u0026mdash; mogami (@smogami) 2015, 2月 4 これは！ということで、名古屋で勉強会をやろうかと思います。30名程度の場所を借りて実施予定です。 募集はいつもの、elasticsearch勉強会のDoorkeeperで行う予定です。 ページの準備まで少々待ちください。（おそらく、3月中旬くらい） 私自身はElasticsearchやELKについて話をしようと思っています。そのほかに、2,3名のスピーカーの方を予定しています。 LTなど興味がある人がいたら、連絡ください。\nこれを機に（？）他の場所でも勉強会を開催したいと考えています。 ニーズがどのくらいありそうなのかが、まだよくわかっていませんが、関西などでニーズがあるんじゃないかと期待していたり。\n興味のある方は、コメント欄、Twitterなどでコンタクトしてもらえればと。 （連絡来るとうれしいなぁ。）\n","date":1424240573,"dir":"post/2015/","id":"5b97ead91c0dd0bad57b4f43a89149a2","lang":"ja","lastmod":1424240573,"permalink":"https://blog.johtani.info/blog/2015/02/18/preparing-elasticsearch-meetup-in-nagoya/","publishdate":"2015-02-18T15:22:53+09:00","summary":"来る、4月4日の土曜日の午後に名古屋でElasticsearch勉強会を開催予定です。 「初」の東京以外の勉強会です。 Twitterでこのよう","tags":["elasticsearch","勉強会"],"title":"名古屋でElasticsearch勉強会を開催します"},{"contents":"第8回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n今回は出足が好調で、早々に180人の枠を超えるという嬉しい事態でしたが、 キャンセル待ちが残っているにもかからわらず、来られていない方が67名もいるということで、キャンセル待ちの方には申し訳なかったです。 もうすこし、キャンセルをしてもらえると嬉しいんですが。。。 今回はメールを当日に1度しか打ってないからかなぁ。\nさて、いつもの通り簡単なメモです。 本当に簡単にですが。\n「Elasticsearch導入チェックリスト？」 Elasticsearch株式会社 Jun Ohtani @johtani スライド：Elasticsearch導入チェックリスト？\nElasticsearchを開発環境や本番に導入する前に気にかけて欲しいことについて発表しました。 元ネタはelasticsearch pre-flight checklistです。 少々古いのですが、私が今回話した内容以外にもモニタリングなどについての話も盛り込まれています。 時間がある方は、見ていただければと。\n「Elasticsearch クエリとスキーマ定義のすごい細かい話」株式会社ドワンゴ 藤堂淳也 さん スライド：Elasticsearch クエリとスキーマ定義のすごい細かい話\nフィールドのチェックを別途インデキシングするアプリで行っている。利用できるものだけElasticsearchに投げる 実際に本番環境で利用しているマッピングに対してフィールドを追加する手順について 「これもドキュメントに書いてあるんですが」という感じでドキュメントに色々書いてあるので読みましょうというありがたい発表でした。 実際に試行錯誤したり検証するときに行ったことを喋ってもらえたので、どういった点を気にしながら運用、設計するかというのがわかりやすかったです。\n「ElasticsearchとKibanaで実現する、30億req/dayのリアルタイム分析」株式会社サイバーエージェント　山田直行さん　@satully スライド：ElasticsearchとKibanaで実現する、30億req/dayのリアルタイム分析\n会場が21時までしか抑えられていないという失態で、ドタバタしてて前半は聞けてないです。。。\n前回の発表では30日分Elasticsearchに入れていたが、今は3日分のみ保存 レポートなどにはRedshift＋Tableauを利用 Kibana3をメインに使っているが、Kibana4も検討予定？ QA\nQ：なぜ、ELBを挟んでいるのか？ A：特に考えておいているわけではない。 Q：インデックスの構成は？ A：1日に2つのインデックス。Bitされたもの、入札されないもの Q：searchのnodeをやめたのは？ A：前回発表した勉強会での懇親会で話を聞いたり、他の方と話を聞いて、不要と判断したため 「はてなのメディア面を支えるElasticsearch」株式会社はてな　山家雄介さん　@yanbe スライド：未定。おそらく、開発者ブログに公開されるかと。\n\u0008* アドテク系にもやってるらしい。BrandSafeはてな\nはてなブックマークのデータを魅せ方を変える機能などで大活躍。B!KUMAとか その日の話題の見出し自動生成機能。Significant Terms Aggregationsを利用。 こちらの「自然言語処理技術を用いたはてなブックマークの新機能「トピック」をベータリリースしました」エントリに関係あるのかな？ 記事の魅せ方を検索できる管理画面ではElasticsearchのクエリDSLを活用されているとのことでした。 検索専門の人でなくても検索式を簡単にくみたてられる画面を用意して、ElasticsearchのクエリDSLに変換するようにしていると。 確かに、クエリをそのまま組み立ててもらうよりも利用しやすい画面がある方がいいですよね。バックエンドはJSとPerlのライブラリとのことでした。\nその他、感想などのブログ 2015-02-13 第8回 elasticsearch 勉強会 @ 丸の内 リクルート 41Fアカデミーホール [Elasticsearch] 第8回 elasticsearch 勉強会へ参加してきた 第8回elasticsearch勉強会 #elasticsearch #elasticsearchjp 第8回 Elasticsearch 勉強会に行ってきた #elasticsearch #elasticsearchjp 勉強会メモ - 第8回elasticsearch勉強会 まとめ 今回も検索からログまでいろんな話になったので、面白かったかと。 参加された方は新しい方が多かったんじゃないかなぁと。（集計結果で見れないのかな、Doorkeeper）。\n今回は、みなさんに21時に41Fから33Fへ移動していただくという大失態があったので、大変申し訳なかったです。 次回（4月中旬）は、このようなことがないように気をつけますので、今後もよろしくお願いいたします。\nあと、東京以外の勉強会も検討しつつあります。興味のある方はコメントやTwitterで反応をいただけると嬉しいです。\nスピーカーは随時募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1424066543,"dir":"post/2015/","id":"997acc135d01b54f7de77a432fb9133f","lang":"ja","lastmod":1424066543,"permalink":"https://blog.johtani.info/blog/2015/02/16/8th-elasticsearch-jp/","publishdate":"2015-02-16T15:02:23+09:00","summary":"第8回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第8回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：running groovy scripts without dynamic scripting\nElasticsearch1.3.8と1.4.3のリリースにより、デフォルトで、リクエストに含まれるGroovyスクリプトや インデックスに保存されたスクリプトを動的に実行する機能をオフにしました。 しかし、Groovyはまだデフォルトのスクリプト言語です。 本ブログ記事では、少しだけダイナミックだが、サンドボックスではない言語のためのスクリプトを どのように使い続けるかを説明します。\n本ブログ記事は、それが何を意味し、さらに重要なのは、安全に重要なタスクを実行させるためにスクリプトを どのように使用し続けるかを理解する助けとなるはずです。\nダイナミックスクリプトとは？ Elasticsearchに詳しくない方のために、Elasticsearchでは、 さまざまなリクエストの一部としてスクリプトを送信することができます。 search、aggregation、update、upsert、delete by queryなどです。 あなたのユースケースのために、通常の動作よりも拡張した動作をさせるためにスクリプトを追加できます。\n例えば、以下のリクエストは、ダイナミックスクリプトを含んでいます。 field1とfield2 + shiftが同じ値を持っている時だけドキュメントを返します。\nGET /_search { \u0026#34;query\u0026#34;:{ \u0026#34;filtered\u0026#34;:{ \u0026#34;filter\u0026#34;:{ \u0026#34;script\u0026#34;:{ \u0026#34;script\u0026#34;:\u0026#34;doc[\u0026#39;field1\u0026#39;].value == (doc[\u0026#39;field2\u0026#39;].value + shift)\u0026#34;, \u0026#34;lang\u0026#34;:\u0026#34;groovy\u0026#34;, \u0026#34;params\u0026#34;:{ \u0026#34;shift\u0026#34;:3 } } } } } } 言語を変えることもできます。 それは、当然、シンタックスが変わったり、制限が追加（例えば、Groovyスクリプトの代わりにLucene　Expressionsに変更）されることもあります。 langパラメータによって言語を指定できます。\nなぜそれはダイナミック？ 上記の例はダイナミックスクリプトです。 それは、実際のスクリプトの部分はサーバサイドで動的に解釈されコンパイルされる必要があるからです。 ダイナミックスクリプトはElasticsearchのAPIによってデータノードに送信されます。 これは、インデックスされたスクリプト(indexed script)も含みます。\n言い換えると、もし、スクリプトがデータノード全てに保存されていなければ、 それは、ダイナミックスクリプトとして扱われます。\ndynamic scriptingをオフにするとどうなるか？ 最新のリリースでの変更により、Groovyのdynaic scriptingはデフォルトでオフになりました。 先ほどのスクリプトについても同様で、もし、先ほどのリクエストを実行すると、次のようなエラーが発生します。 (一部省略してあります。)\n{ \u0026#34;error\u0026#34;:\u0026#34;SearchPhaseExecutionException[Failed to execute phase [query], all shards failed; shardFailures {[8FJ02MofSnqVvOQ10BXxhQ][test][0]: SearchParseException[[test][0]: from[-1],size[-1]: Parse Failure [Failed to parse source [{...}]]]; nested: ScriptException[dynamic scripting for [groovy] disabled]...\u0026#34;, \u0026#34;status\u0026#34;:400 } エラーメッセージの重要な箇所は「ScriptException[dynamic scripting for [groovy] disabled]」です。\nスクリプティングを使い続けるには？ Elasticsearchでスクリプトを実行するには3つの方法があります。 2つのダイナミックな方法は、リクエストごとのスクリプト（上述）かインデックスされた スクリプト(indexed script)を使う方法です。 インデックスされたスクリプトを使うことは、Elasticsearch自身にGroovyスクリプトを保管することで 利用で、それらを要求に応じて利用することです。 （これは、実際には十分機能しますが、これではまだ、信頼できないユーザに対して彼らのスクリプトを実行できます） RDBのように保存されたプロシージャとして同じ方法で実行させるものと同様です。 前もって、スクリプトを記述しておき、リクエストの一部として後から、名前で呼び出して実行可能です。\nGET /_search { \u0026#34;query\u0026#34;:{ \u0026#34;filtered\u0026#34;:{ \u0026#34;filter\u0026#34;:{ \u0026#34;script\u0026#34;:{ \u0026#34;script_id\u0026#34;:\u0026#34;your_custom_script\u0026#34;, \u0026#34;lang\u0026#34;:\u0026#34;groovy\u0026#34;, \u0026#34;params\u0026#34;:{ \u0026#34;shift\u0026#34;:3 } } } } } } あまり変わっていないことに気づくでしょう。 scriptの部分が、前もって記述されたスクリプトの名前script_idに変更されただけです。\nElasticsearchにスクリプトを提供するダイナミックではない方法はインデックスに保存する代わりに、 ディスクにファイルとしてスクリプトを保存することです。 そうすることで、各スクリプトを設定として保存します。 これは、どのようなスクリプト言語に対してもダイナミックスクリプティングをオフにしたまま、 サンドボックス化されないスクリプトを使い続けることができる方法です。\n最初のサンプルで、Groovyスクリプトはdoc['field1'].value == doc['field2'].value + shiftでした。 これを、.groovy拡張子を持ったファイルとして書き出すことができます。\ndoc[\u0026#39;field1\u0026#39;].value == (doc[\u0026#39;field2\u0026#39;].value + shift) もし、このファイルにyour_custom_script.groovyちう名前をつけて、 Elasticsearchのすべてのデータノードのconfig/scriptsディレクトリに保存すると、 Elasticsearchは60秒（elasticsearch.ymlのwatcher.intervalで変更可能）でこのスクリプトを認識し、今後のリクエストに利用できるようにプリコンパイルするでしょう。 そのファイルはElasticsearch実行ユーザによって読み込みができる必要があります。 これをディスクに書き込んだ後、あなたの設定ディレクトリは次のようになっています。\nconfig/ elasticsearch.yml logging.yml scripts/ your_custom_script.groovy これは、各リクエストやインデックスされたスクリプトをスクリプトとして動的に送信しませんが、 信頼された環境にスクリプトを追加することでダイナミックスクリプトとなることを許します。\nディスクに書かれたスクリプトを使用する スクリプトは、ロードされたスクリプトになるまでは、利用できません。 ログファイルに次のようなログが表示されるまではです。\n[2015-02-11 11:14:47,066][INFO ][script ] [Sergei Kravinoff] compiling script file [/path/to/elasticsearch-1.4.3/config/scripts/your_custom_script.groovy] すべてのElasticsearchのデータノードでスクリプトが読み込まれたら、 それを利用することができます。 利用するために、file（script_idではありません！）としてスクリプト名を指定します。\nGET /_search { \u0026#34;query\u0026#34;:{ \u0026#34;filtered\u0026#34;:{ \u0026#34;filter\u0026#34;:{ \u0026#34;script\u0026#34;:{ \u0026#34;file\u0026#34;:\u0026#34;your_custom_script\u0026#34;, \u0026#34;lang\u0026#34;:\u0026#34;groovy\u0026#34;, \u0026#34;params\u0026#34;:{ \u0026#34;shift\u0026#34;:3 } } } } } } Note:langは必須ではありません。Groovyがデフォルトの言語のためです。 もし、違うスクリプト言語を使いたい、もしくは、デフォルトの言語を（例えば、Lucene Expressionsへ） 変更したい場合、言語が正しいスクリプトを見つけるために提供されている必要があります。 一番良い方法は、アプリケーションがlangパラメータを含んでいることを勧めます。 これは、将来、デフォルトのスクリプト言語が変更されても、問題ないからです。\n質問？ もし、質問があれば、遠慮なくTwitter(@elasticsearch)で教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1423721589,"dir":"post/2015/","id":"1fed22e99b0e11a50eb7b92cb1644e8a","lang":"ja","lastmod":1423721589,"permalink":"https://blog.johtani.info/blog/2015/02/12/running-groovy-scripts-without-dynamic-scripting-ja/","publishdate":"2015-02-12T15:13:09+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：running groovy scripts without dynamic scripting Elasticsearch1.3.8と1.4.3のリリースによ","tags":["elasticsearch"],"title":"Groovyスクリプトをダイナミックスクリプトなしで実行(日本語訳)"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch 1.4.3 and 1.3.8 released\n本日、Lucene 4.10.3をベースにしたElasticsearch 1.4.3と、セキュリティとバグフィックスリリースである、Elasticsearch 1.3.8をリリースしました。 ダウンロードおよび変更リストはそれぞれ次のリンクからアクセスできます。\n最新ステーブルリリース：Elasticsearch 1.4.3 1.3.x系バグフィックス：Elasticsearch 1.3.8 過去のリリースに関するブログ（公式）はこちら。\n1.4:1.4.2, 1.4.1, 1.4.0, 1.4.0.Beta1 1.3:1.3.7, 1.3.6, 1.3.5, 1.3.4, 1.3.3, 1.3.2, 1.3.1, 1.3.0. すべての変更については1.4.3のリリースノートおよび1.3.8のリリースノートをごらんください。 以下では、セキュリティの問題について紹介します。\ngroovy scripting の脆弱性 Elasticsearchのバージョン1.3.0から1.3.7および1.4.0から1.4.2で、Groovyスクリプトエンジンに脆弱性が発見されました。 脆弱性は、攻撃者がGroovyスクリプトをサンドボックスを避けて構築でき、 ElasticsearchのJava VMを実行しているユーザとしてシェルコマンドを実行できます。\nこの問題をCVE-2015-1427として報告済みです。\nバージョン1.3.8と1.4.3では、デフォルトで、Groovyに対してのサンドボックスをオフにしました。 結果として、ダイナミックスクリプトの実行はGroovyに対してもオフとなります。\nもし、脆弱性のあるバージョンで実行している場合、v1.3.8かv1.4.3にアップグレードするか、ダイナミックなGroovyスクリプトをクラスタの すべてのノードに対して次の設定を追加することで、オフにします。\nscript.groovy.sandbox.enabled: false これは、Groovyのサンドボックスをオフにし、リクエストの一部としてインラインで受け付けるダイナミックなGroovyスクリプトや 特殊な.scriptsインデックスに保存されているスクリプトを実行しません。\nそれまでは、各データノードのconfig/scriptsディレクトリにファイルとして保存されたGroovyスクリプトは まだ、利用可能です。詳細の情報についてはRunning scripts without dynamic scriptingをごらんください。\nfuture scripting plans 安全なダイナミックスクリプティング言語としてGroovyを失うことは、Elasticsearchにとって痛手です。 update APIやsearch APIやaggregationsフレームワークの一部としてScriptを使います。 それらは、静的なAPIでは簡単に表現できない、カスタムなトリックをユーザに実行できるようにします。\n残念ながら、Groovyチームとこの問題を議論した後、Groovy言語もサンドボックスによってきちんと保護されている というにはあまりにもダイナミックであるという結論に達しました。 Groovyは、デフォルトでは利用できなくなります。 利用可能なダイナミックスクリプト言語としてはLucene Expressions言語のみとなります。 Expressionsははやいですが、それらは非常に限定されています。数値のフィールドでのみ実行可能で、ループをサポートしていません。\nより強力で（しかし安全な）ミニ言語になるようにExpressionsを拡張することを調査しています。 これは、Scriptユーザが現在持っている最も一般的なユースケースを少なくとも助けるでしょう。 この拡張は長期間のプロジェクトであり、進化には時間がかかるでしょう。\nぜひ、Elasticsearch 1.4.3をダウンロードして、試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1423712393,"dir":"post/2015/","id":"5badf61ecb9cfadd7d6af58712fa5f6f","lang":"ja","lastmod":1423712393,"permalink":"https://blog.johtani.info/blog/2015/02/12/elasticsearch-1-4-3-and-1-3-8-released-ja/","publishdate":"2015-02-12T12:39:53+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElas","tags":["elasticsearch"],"title":"Elasticsearch　1.4.3および1.3.8リリース（日本語訳）"},{"contents":"今年もCROSS参加しました。そして、話もしてきました。 今年は横浜の大さん橋でした。横浜はあんまりこないので、乗り換えでおたおたしてしまいましたが。。。\nなかなかいい景色でした。（寒いけど） 「おおさんばし」って読むんですね。「だいさんばし」だと思ってた。。。\n以下はいつもの、自分用メモです。\n俺はどうしてそのデータストアを選択したのか 〜銀河と小宇宙を語る会〜 http://2015.cross-party.com/program/c1\n遅れて入ったので、ちゃんと聴けてないです。\n最近注目しているデータストアは？ Postgresql。JSON型が気になってる。 AiroSpike。データ型のあるデータストアが気になってる。 MongoDB。JSON使いたいなら、これじゃないの？ AWSのAurora。インスタンスタイプを選ばなくていい（選ばないといけないらしい）とか、勝手にスケールしてくれるし、MySQL互換。 今こそ語るエンジニアの幸せな未来 http://2015.cross-party.com/program/x3\n「無職初日です。」 Web系の人？とか質問されて、自分が何系かいつもわからなくなるなぁ。 「働きがいは会社が提供するのか、個人が見つけるのか？」 個人かなぁ。会社がなにをやってるかにもよる気がするかなぁ。 「辞めると伝えると、やりたいようにやれって言われるw」 リモートできるかできないか。 「働きがい」というキーワードが出てると普通は怪しい会社w 今は、働きやすさを高くしないと人が雇えなくなってきている。 欧米のミドルウェアだと、35歳定年説はない。→日本でもそうじゃないですか？ 漫然と進んでるとダメ。→そりゃそうだ。 全文検索エンジン群雄割拠〜あなたが使うべきはどれだ！〜 http://2015.cross-party.com/program/c4\nスライド：https://speakerdeck.com/johtani/elasticsearchfalseshao-jie-tote-zheng-cross-2015\n楽しんでいただけましたでしょうか？ ちょっと話が長くなってしまい、あとの方の時間が少なかった気がしますが。。。\nKibanaのバックエンドとして認識されている人もいたので、検索エンジンですよというのをアピールするいい機会になったので良かったです。 もちろん、Kibanaとの組み合わせも面白いので、少しでも興味をもっていただき、触っていただけたらなぁと。\n話をする機会を用意していただいた、やまかつさん、その他のスピーカーのみなさん、ありがとうございました！。\nElasticsearchに関して何か興味質問などありましたら、気軽にコンタクトしてください。Twitterとかブログコメントなどで。\nプレモルタイム以降 プレモルの写真撮るの忘れてました。。。重要なのに。。。\n美味しくプレモルをいただきながら、何人かの方に声をかけていただき、話をすることができました。 こういう時間がとってあるのがいいですよね。 色々なところでElasticsearchを使っていただいているようで、うれしい限りです。 DMMの方とも話ができたし。\nまとめ 今年はプレモルを飲みに行くだけかなぁと思っていたのですが、話をする人になってました。（おかしいなぁ） 来年もあれば、きっと参加するかなぁと。ではまた来年！\n夜景きれいですね。（端っこに写ってる船は飛鳥IIでした。）\n","date":1422500368,"dir":"post/2015/","id":"fe6ba10cc6c9509b4b22e9d59e029775","lang":"ja","lastmod":1422500368,"permalink":"https://blog.johtani.info/blog/2015/01/29/talk-at-cross2015/","publishdate":"2015-01-29T11:59:28+09:00","summary":"今年もCROSS参加しました。そして、話もしてきました。 今年は横浜の大さん橋でした。横浜はあんまりこないので、乗り換えでおたおたしてしまいま","tags":["勉強会","elasticsearch"],"title":"CROSS 2015で話をしてきました #cross2015"},{"contents":"今年は大晦日になってしまいました。しかも、ちょっと飲んでたり。。。 第9流しながら書いてます。\n振り返り(2013年に書いた抱負から) まずは昨年書いた抱負からの振り返りです。\nElasticsearch勉強会の継続、Solr勉強会の継続＋ミックスした検索勉強会の開催 IDEAのさらなる活用 もっと開発(プラグインとか) AWSをもう少し活用 海外のイベントに行ってみたい 読書と英語を継続 AWS活用できてないです、、、 ミックスした勉強会は、ドタバタしててできませんでした。\nIDEAはさらなる活用までいってるかは不明ですが、最近は隣にとても詳しい人が座っているので色々と教えてもらってます。 開発については、ちょっとずつですが、PR書いたりしてます。\n振り返り(今年あったできごと) 初海外（ベルリンとアムステルダム） Elasticsearchに転職 初献本? Elasticsearch勉強会の定期開催 ElasticSearch Serverの翻訳 サーバ/インフラエンジニア養成読本の執筆 勉強会以外でもスピーカー 英語の継続（切実） 初ものが多かったです。 初の海外の会社、初の海外旅行（仕事）、初の献本（著者の人から、多分、初）、初の翻訳本、初のムック本執筆などなど。\n初の海外でした。なのに、夏には海外の会社に転職してみてるとか、ちょっと自分でも信じられません。 ベルリンでは、海外の勉強会にも参加できて非常に有意義でした。 ヨーロッパの街並みは、日本では経験できない雰囲気で、向こうの方には普通の街並みも自分にはとても新鮮でした。\n転職自体は2回目ですが、海外の会社というのは初めてです。日々、英語\u0008の勉強になりますし、いろんな刺激を受けています。 英語の勉強自体も継続中です。英語力が不足しているのは自覚してるので、少しでも英語に触れるようにDLifeで海外ドラマを録画して、通勤時間帯にみるなどを試みてます。\n書籍には、昨年につづき関わることができました。来年も何かしらの書籍に関われることができればなと。 （\u0008気になる人は以下のリンクから。。。）\n分かりきったことですが、Elasticsearchな1年でした。 転職してあっという間の半年です。まだまだやりたいことがいっぱいあるので、来年もバランスよく頑張らないと。\n来年の抱負 英語の継続 海外のイベントへの参加 多岐にわたるイベントでのスピーカー 日本の人員の倍増！？ Elasticsearchに関する日本語の情報発信 Elasticsearch座談会みたいなものの開催 英語の継続については書くまでもないですね。 海外のイベントへの参加もかなぁ。3月にサンフランシスコに行くとは思います。 そのほかには、今度こそBerlin Buzzwordsに行きたいです。\nElasticsearch勉強会以外のイベントでもElasticsearchを広めるべく色々なところでスピーカーをしたいなと思っています。 検索、ログ解析で少しは知名度が上がってきていますが、別の言語のコミュニティやイベントでは、まだまだ、elasticsearch自体を知らない人もいると思います。まずは知ってもらうところからかなと。\n日本の人員の倍増については、今年も達成してます（一人が二人になりましたw）。 来年も倍増できればうれしいなと。同じ母国語の同僚がいるのはやっぱりうれしいし、心強いですから。\n来年は（も）、日本語での情報をどんどん発信していきます。サイトやガイドなども 日本語にしたいなと。 あとは、これまで、勉強会でスピーカーをしていただいた人だけを集めた座談会のようなものも開催したいなと考えています。 私自身も色々と聞きたいことがありますし。 そのほかにも色々と要望をお待ちしています。Twitterやブログのコメント欄などで気軽にコンタクトしていただければと。\n最後は、いつものようにですが、来年も勉強会やいろんなイベントに参加する予定です。 ブログも週1程度で書く努力しないとなぁ。 こんな話を書いてくださいとかのリクエストもお待ちしています。\n今年はあと、数時間ですが、色々とお世話になりました。 この場を借りてお礼申し上げます。\n来年も、いろんな方に絡んでいくとは思いますが、よろしくお願いいたします。\n","date":1420026086,"dir":"post/2014/","id":"b36abffbe5d6a0de73a9968604a1a3f9","lang":"ja","lastmod":1420026086,"permalink":"https://blog.johtani.info/blog/2014/12/31/looking-back-2014/","publishdate":"2014-12-31T20:41:26+09:00","summary":"今年は大晦日になってしまいました。しかも、ちょっと飲んでたり。。。 第9流しながら書いてます。 振り返り(2013年に書いた抱負から) まずは昨年","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2014）"},{"contents":"この記事はElasticsearch Advent Calndar 2014の25日目のエントリです。\nあっという間に最終日です。来年につなげるという意味で、Elasticsearchの2系のIssueをいくつかピックアップして紹介してみます。\n現在、ElasticsearchのGitHubリポジトリは、大きく3つのブランチで作業しています。 master、1.x、1.4です。masterと1.xの大きな違いとしては、masterはLuceneの5.x系を採用している点です。\nなお、これから紹介するIssueは現在、確定していない項目も含んでいます。実際に2.0がリリースされるタイミングでは 採用されない場合もあります。\nUpgrade master to lucene 5.0 snapshot #8347 (closed) https://github.com/elasticsearch/elasticsearch/pull/8347\n先ほど書きましたが、Luceneの5に対応するためのPRです。 Lucene 5に関してはLuceneのコミッターのMikeさんのブログ記事も参考になります。\nLucene 5に変更することで、BitSetに関する改善が多く含まれることになります。 メモリの利用量、圧縮などの改善が多く含まれています。 もう1点大事な点としては、Lucene 5系ではLucene 3系のインデックスを読み込むことができなくなる点です。 Luceneの下位互換の範囲は1つ前のメジャーバージョン（5.x系の場合は4.xまでが対象）となっています。\nFilter cache: add a _cache: auto option and make it the default.（closed） https://github.com/elasticsearch/elasticsearch/pull/8573\nFilter cacheは、trueもしくはfalseの設定が利用できますが、filterの種類にも依存します。 その辺りの条件を加味しつつ、よしなにCacheをコントロールしてくれます。\nRemove and/or/not in favour of bool filter #8960（open / discuss） https://github.com/elasticsearch/elasticsearch/issues/8960\n似ているが少し異なるand、or、notフィルタとboolフィルタが存在しています。 これらをわかりやすくするために、boolフィルタに統一しましょうという話し合いをしています。\nInput validation #9059（open / discuss） https://github.com/elasticsearch/elasticsearch/issues/9059\n色々な入力に関するチェックを追加しようというIssueです。 たとえば、ディレクトリ名やファイル名、URLのパスやクエリストリング、フィールドのパスやスクリプトなどです。 Validationがあると、変な設定をして頭をかかえることもなくなるかなぁと。\nRefactor analysis framework #8961（open） https://github.com/elasticsearch/elasticsearch/issues/8961\n新しくAnalyzerを作った場合に、色々な場所に登録必要があったりします。インデックスレベルとノードレベルです。（Kuromojiプラグインなどが参考になります。） また、インデックスごとにカスタムのAnalyzerを設定するので、1つのノードに同じAnalyzerを何度も設定しないといけません。 よりシンプルにするために、Analyzerをノード単位で設定しようという提案です。\nRemove possibility for conflicting field definitions and ambiguous field resolution #8870（open） https://github.com/elasticsearch/elasticsearch/issues/8870\n同じインデックスに、異なるtypeで、同じフィールド名があった場合、いろいろと良くないことがあったりします。 たとえば、フィールドのタイプがintegerとstringと異なる場合に、インデックスレベルで検索を行うとうまく検索できなかったりと。 この問題を解消するために、より明確にしようというIssueです。 たとえば、フィールド名を指定するためには、フルパスで記述をするだとか、フィールドマッピングに関してはインデックスレベルで内部で保持をするなど。\nValidation of mappings request to reject unsupported fields #7205（closed） https://github.com/elasticsearch/elasticsearch/issues/7205\n1.xでも取り込まれますが、嬉しい機能なので紹介します。 これまでは、mappingsでスペルミスをした場合（たとえば、field設定で\u0026quot;indexx\u0026quot;といったミス）には、その項目は単に無視されるだけでした。 これが、v1.xでは、エラーに\nまとめ ということで、簡単ですが、v2.0.0に向けたIssueをピックアップして紹介してみました。 上記以外にも多くの改善、提案が2.0に向けて行われています。 興味のある方は、v2.0.0ラベルでIssueを検索してみてはいかがでしょうか？\n今年もあとわずかとなりました。 今年の2月にElasticsearchの1.0がリリースされ、あっという間に1.4なりました。まだまだ改善しています。\n来年もElasticsearchに興味をもっていただければ嬉しいです。 Elasticsearch初のユーザカンファレンスのサイトもオープンしました。 Elasticsearchに関するいろいろな話が聞ける機会だと思います。登録をお待ちしています。\n","date":1419490380,"dir":"post/2014/","id":"cb9649eca3dfbd356527ffc88f1dcb94","lang":"ja","lastmod":1419490380,"permalink":"https://blog.johtani.info/blog/2014/12/25/pickup-elasticsearch-2-0-0-labels/","publishdate":"2014-12-25T15:53:00+09:00","summary":"この記事はElasticsearch Advent Calndar 2014の25日目のエントリです。 あっという間に最終日です。来年につなげるという意味で、Elasti","tags":["elasticsearch"],"title":"Elasticsearch 2.0系のIssueの紹介"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：marvel 1.3.0 released\n12/17に、Elasticsearch Marvel 1.3.0をリリースしました。 Marvelの以前のリリースから、Elasticsearchでは様々なことがありました（Elasticsearch 1.4のリリースなど）。 このバージョンでは、モニタリングにクエリキャッシュや新しいcircuit breakerなどのような機能を追加してあります。 Senseのナレッジベースは最新のAPIを含むものに拡張されています。 また、Shieldのリリースに向けた準備として、HTTPsのサポートも追加しました。\nアップグレードのために、Elasticsearchの全てのノードに最新版のMarvelプラグインをインストールする必要があります。 また、他のJavaプラグインと同様に、Marvelの新バージョンを有効にするために、各ノードを（1台ずつ）リスタートする必要があるでしょう。 アップグレードプロセスについての詳細は、Marvelドキュメントをごらんください。\nまとめとして、ここに本リリースに関する改善点をいかにリストアップしておきます。\nagent 追加： httpsのサポート デフォルトのMarvelの設定（以前は常に9200）ではなく、ローカルノードのポートを自動的に検出 改善： marvelインデックステンプレートに関するエラーチェックと耐障害性(それに対するチェックと追加時のチェック) エラーログに関するくり返しの抑制 URLパラメータによるインデックス名を指定する_bulk exportコマンド。これは、rest.action.multi.allow_explicit_indexがfalseに設定されているときに有用 修正： ES 1.4.0のtribe nodeがMarvelのインストール時に初期化されない問題 削除： UIで表示されないoptional shard level statsを除去 monitoring ui 追加： ES 1.4.0で導入された新しいcircuit breakerを追加 circuit breakerのlimitをグラフにプロット QueryCacheのグラフを追加 index throttlingのグラフの追加 Index writerとバージョンのmapのメモリ使用量のグラフの追加 修正： Network Transport Bytes Receivedグラフに実際の送信量を表示 Node Statsダッシュボードでいくつかのスレッドプールの不足 sense 追加：\nmappingsをインデックスでオートコンプリートするしないの設定を可能に Cluster Reroute API Search APIのQuery Cacheパラメータ Analyze API Validate Query API Put Percolator API cluster.routing.allocation.*設定 Function Scoreクエリのweightパラメータ Flush API Terms Aggregationのshow_term_doc_count_errorパラメータ Update API _geo_distanceソートオプション Significant Terms aggregationを1.4.0にアップデート Mapping APIにメタデータフィールドを追加 Get Index API Scripted Metric Aggregation simple_query_stringクエリ More Like Thisクエリを1.4.0にアップデート has_childクエリ/フィルタのmin_childrenとmax_childrenオプション terms aggs/significant terms aggsのヒントオプション Mappings APIのtransform インデックスされたscriptとtemplate \u0008* Geo Bounds aggregation Top Hits aggregation Terms aggregationのcollect_modeオプション Percentiles Rank aggregation Disk Threshold Allocator設定 修正：\nURLオートコンプリートの挙動（プロトコルとホストのような組み合わせ） nested typeマッピングのinclude_in_parentとinclude_in_rootの不足 Rangeフィルタでのgt、gte、lt、lte Existsフィルタのオートコンプリート Snapshot、Restore APIのリポジトリ設定の時オートコンプリートの失敗 いつものように、Elasticsearch Marvelを改善するために、フィードバックをお待ちしています。 ElasticsearchユーザMLやTwitterに質問や意見お送りください。\n","date":1418890008,"dir":"post/2014/","id":"7dea465ad52758b10cbceb08c81d1760","lang":"ja","lastmod":1418890008,"permalink":"https://blog.johtani.info/blog/2014/12/18/marvel-1-3-0-released-ja/","publishdate":"2014-12-18T17:06:48+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：marvel 1.3.0 released 12/17に、Elasticsearch Marvel 1.3.0をリリースしました","tags":["elasticsearch","marvel"],"title":"Marvel 1.3.0リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch 1.4.3 and 1.3.8 released\n本日、Lucene 4.10.3をベースにしたElasticsearch 1.4.3と、セキュリティフィックスとバグフィックスリリースである、Elasticsearch 1.3.8をリリースしました。 ダウンロードおよび変更リストはそれぞれ次のリンクからアクセスできます。\n最新ステーブルリリース：Elasticsearch 1.4.3 1.3.x系バグフィックス：Elasticsearch 1.3.8 過去のリリースに関するブログ（公式）はこちら。\n1.4:1.4.1, 1.4.0, 1.4.0.Beta1 1.3:1.3.6, 1.3.5, 1.3.4, 1.3.3, 1.3.2, 1.3.1, 1.3.0. すべての変更については1.4.2のリリースノートおよび1.3.7のリリースノートをごらんください。 以下では、重要な変更について紹介します。\nbug fixes Elasticsearchに対して広範囲にわたってランダムなテストを行っています。以下の問題を見つけ、修正するのに役立っています。\nプライマリシャードを持つnodeがレプリカシャードをプライマリから復旧している間に、リスタートした場合に、プライマリ上のトランザクションログが削除されデータをロスする(#8917) scriptインデックスが普及した場合に、ScriptService全体がデッドロック(#8901) Index Writerのロックを強制的に解放することによるシャードの破損(#8892) パフォーマンス改善 複雑な設定をもつ大きめのクラスタをもつユーザは、小さなスケールではわからない性能ボトルネックに直面します。 彼らの報告が次の改善をもたらす助けとなりました。\n使用可能なディスク空間に基づいてシャードの配置を決定する、disk allocation deciderの速度改善とクラスタリスタート後のリカバリ速度の改善(#8803) 以前よりも高速な共有ファイルシステムでのSnapshot生成(#8749) 不要なクラスタ状態変更の削減とそれによるネットワークトラフィックの削減およびリカバリの速度向上(#8933, #8413) index stats APIはシャードリカバリによるブロックしない(#8910) 試してみてください。 ぜひ、Elasticsearch 1.4.2をダウンロードして、試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1418880374,"dir":"post/2014/","id":"bce2fa6458f39a75e2713f3d687271a1","lang":"ja","lastmod":1418880374,"permalink":"https://blog.johtani.info/blog/2014/12/18/elasticsearch-1-4-2-released-ja/","publishdate":"2014-12-18T14:26:14+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElas","tags":["elasticsearch"],"title":"Elasticsearch 1.4.2および1.3.7リリース（日本語訳）"},{"contents":"「【東京】JJUG ナイト・セミナー「機械学習・自然言語処理特集！」12/17（水）開催」でLuceneの話をしてきました。 本当にごく簡単な入門です。 Luceneをさわるきっかけにしてもらえたら嬉しいです。\nそのほかにも面白い話が聞けましたので、簡単ですがメモを。\nJJUGの2014年振り返り だいたい、毎月ナイトセミナーかCCCを開催 イベント系に、のべ3100名が参加 Java でカジュアルにはじめる機械学習 小宮 篤史さん(スマートニュース株式会社) スライド：#JJUG - Java でカジュアルにはじめる機械学習\nブログ：#JJUG ナイトセミナー「機械学習・自然言語処理特集！」で Java でカジュアルに機械学習する話をしてきました\nガチの人は寝ててください。 機械学習でできること 分類・識別 予測・回帰 パターンマイニング・アソシエーションルール クラスタリング 上2つは教師あり学習/下2つは教師なし学習 データとしては、日構造では扱えないので、「特徴量」を抽出して「特徴ベクトル」を作って、処理をするのが機械学習 得られた結果の正しさの測定などなど\n機械学習の実装は辛いので、車輪の再発明をやめましょう！ \u0008Javaで使える機械学習\nWeka：とりあえず使ってみるならこれ？ MLlib：Sparkで使われてる Mahout：オワコン？ SAMOA：Stormの上で利用できる Jubatus：Javaクライアントあり。 h2o：Deep learningをJavaでやるなら、これ。 ほかにもあったけど、スライド見ていただければ。 機械学習をはじめるのに使えるデータセット\nUCI Machine learning repository\nIris（アヤメデータ）は機械学習界のHello world Wekaを使ったサンプルコード\nSpark/MLlibではじめるスケーラブルな機械学習 猿田 浩輔さん(株式会社エヌ・ティ・ティ・データ) スライド：（後日、リンクがあれば更新予定）\n\u0008* Spark+MLlibを語る上で外せない話題\nHadoopとの違い？\nまずはHadoopの話\nHadoopによるK-meansのデモ\nHadoopの問題点に対するSparkの解決策\nSpark 1.0系からJava8で書ける\nQA：\nQ： データをキャッシュできるという話でしたが、キャッシュするということは、ジョブが途中で失敗した場合は最初からやり直しになるのでしょうか？ A： キャッシュしたデータが残っている場合は、途中から再開出来ます。キャッシュしたデータを持ったマシンがこけたら、最初からやり直しです。\nLuceneと日本語の検索 自分 スライド：Luceneと日本語の検索 サンプルのリポジトリ：jjug-example\n自然言語処理にからめて何か話をしてくださいと話を受けていたのですが、自然言語処理については「形態素解析」くらいしか出てこなかったですけど。。。 Luceneがどんなものかを超概要で話をしてみました。少しでもLuceneがどんなものかをわかってもらえたら嬉しいです。\nもっと詳しく知りたい方は、スライドにある参考資料などを見ていただければと。\nJavaで書くのもいいんですが、もっと簡単に検索したい場合はElasticsearchを使うのが便利ですよ！で締めくくりたかったのですが、発表では失敗してしまいました。。。 Elasticsearchの起動からデータ登録、検索まではこちらのスライドを見ていただければ簡単さがわかると思います。\nまた、Kuromojiを利用した時に、Tokenizerなどが出力するTokenの品詞情報を見たい場合に便利なElasticsearch用プラグインも作っています。 こちらも、Elasticsearchと一緒に使ってみてください。\nまとめ 機械学習に関していろんなツールがあるのだなぁと。 懇親会でもちょっと話しましたが、アルゴリズムの選定とか、アルゴリズムに適したデータの作成など、前処理のノウハウとかが大変そうだなぁといつも思います。 機械学習はいつもぼやーっとしか理解してないので。。。\nJJUGさんはYouTubeの動画もあるようなので、過去の面白そうなセミナーも合わせてみてみると面白いと思います。\n毎度のことですが、なんでも良いので、発表した後のフィードバックをいただけるとうれしいです。 今後の励みや改善につながるので。\n","date":1418809314,"dir":"post/2014/","id":"e5390751969ab21df280b7591854b89f","lang":"ja","lastmod":1418809314,"permalink":"https://blog.johtani.info/blog/2014/12/17/jjug-night-seminar-dec-2014/","publishdate":"2014-12-17T18:41:54+09:00","summary":"「【東京】JJUG ナイト・セミナー「機械学習・自然言語処理特集！」12/17（水）開催」でLuceneの話をしてきました。 本当にごく簡単な入","tags":["elasticsearch","jjug"],"title":"JJUG ナイトセミナーでLuceneの簡単な紹介をしてきました。#JJUG"},{"contents":"たまには、他愛のないブログを。\n仕事しながら、コーヒーを飲んでます。\n最近は、サムライズムさんのオフィスに入り浸って仕事してます。 オフィスには、コーヒーミル付きのコーヒーメーカーがあるんです。\n↓こんな感じ（現物は違うけど）\nで、近所のコーヒー問屋で豆を買ってきてます。 そこのマスターに、いつもサジェストされるんです。\n「この豆は、日が経つにつれて、細かく挽いて飲んでください。」\n「この豆は、細かめに挽いて飲むのがオススメです。」\nなどなど。 オススメされるんですが、全自動のコーヒーメーカーは残念ながらここまでやってくれません。\nということで、手動のミルを買ってみました。家でも使えるし。\nちょっと考え事しながらとか、頭の切り替えに、ミルを回すのもいいかなと。 気持ち、美味しいコーヒーな気がします（気のせいかも）\n","date":1418698892,"dir":"post/2014/","id":"05330c3703d0e2c96cfe657ab33f130c","lang":"ja","lastmod":1418698892,"permalink":"https://blog.johtani.info/blog/2014/12/16/a-coffee-break/","publishdate":"2014-12-16T12:01:32+09:00","summary":"たまには、他愛のないブログを。 仕事しながら、コーヒーを飲んでます。 最近は、サムライズムさんのオフィスに入り浸って仕事してます。 オフィスには、","tags":["misc","coffee"],"title":"コーヒーブレイク"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：exciting logstash plugin ecosystem changes\nLogstash 1.5.0 Beta 1(お試しはこちら)のリリースで、 プラグインのインストール、管理、公開の方法を変更しています。 ユーザやコミュニティからフィードバックをもらいました。 その目的は、プラグインの利用や開発をより簡単にすることです。 このプロジェクトは始まったばかりです。プラグインのコミュニティを探し、 共有するためのワンストップソリューションを提供するこのアイデアを改善していく予定です。 このブログで、この決定を行った理由を説明し、新しいワークフローをと今後のロードマップを説明します。\nプラグインがあります！ Logstashは、プラグイン（input、filter、output、codec）が豊富にあります。 これらは、Elasticsearchにより開発されたものと、コミュニティからコントリビュートされたものです。 Logstashの主な特長の1つは、これらのプラグインの有効性と動作を拡張するプラグインを追加するのが簡単なことです。 現在、165以上のプラグインがエコシステムにあり、これらは、2つのプロジェクトに分かれています。\nlogstash-coreは最もよく使われるプラグインで、Logstashにデフォルトで含まれます logstash-contribはコミュニティにより開発されたプラグインを含み、別途ダウンロードできます 新プラグインエコシステムの変更 1.5.0では、全てのプラグインは、Logstashコアから分離され、rubygemsを使って個別にパッケージングされます。 rubygemsを選択したのは、依存関係のあるライブラリの配布とパッケージングがパワフルで一般的なものだからです。 さらに、rubygems.orgプラットフォームは配布や探索に影響があります。 また、Logstashにプラグインをインストール、アップデート、削除するのが簡単な基盤も追加しました。 contribプロジェクトは徐々に終了します。全てのプラグインは個別のプロジェクトになります。\nプラグインエコシステム変更の理由 多数のプラグインをもっていると、配布と公開に関して難題が出てきます。 私たちが変更するに至った理由は次のようなものです。\n現在は、プラグインの更新に伴い、Logstashの新バージョンのリリースが必要 開発者は、Logstashのリリース間隔とは別に、新バージョンをリリースをしたい プラグイン開発者は、外部依存を記述できるようにしたい Logstashコアの配布パッケージのダウンロードサイズを小さくし、ユーザは必要なプラグインのみインストール logstash-contribを1つのリポジトリとして管理するのは難しい 詳細： ソースコードの場所 Logstashのソースコードは、今後も現在のGitHubのリポジトリのままです。 しかし、プラグインに関するコードやテストコードは含まなくなります。 この分離により、個別のプラグインの改善と同様にコアの改善に集中できます。 これにより、Logstashプロジェクトの全体の品質も向上します。\n全プラグインのソースコードは、新しいGitHub organization、logstash-pluginsにて管理します。 各プラグインは個別のリポジトリとして、ここに配置されます。 一見すると、これはメンテナンスが難しくなるように思えます。しかし、テスト、Issue、依存関係を明確にすることができます。 私たちの目的は、テスト、ドキュメント、gemの公開の自動化であり、これを簡単にするためのツールを追加します。\nしかし、プラグインの開発者はプラグインのソースコードソースコードをlogstash-pluginsに置く必要はありません。 ー コミュニティで利用可能にするために、rubygems.orgでそれを公開するだけで良いです。\nワークフロー ここで、新プラグインエコシステムのやりとり/ワークフローについて、いくつかの観点から説明します。\nlogstashユーザ: ユーザは、これまでのリリース同様にLogstashのバイナリをダウンロードします。 Logstash 1.5.0は、1.4.2でパッケージされていたプラグインと同等のものが含まれています。 新しいシステムに簡単に移行できるようにです。 そして、ユーザは、最初のデプロイの後に、Logstashプラグインのをインストール、アップグレードできるようになります。\n$LS_HOME/bin/pluginスクリプトがプラグイン操作に関連するコマンドになります。\nプラグインのインストール プラグインのほとんどはgemとしてrubygems.orgにアップロードされます。 例えば、もしユーザがApache Kafka outputプラグインをインストールする場合、次のコマンドを実行します。\nbin/plugin install logstash-output-kafka または、ファイルをダウンロード済みの場合は次のコマンドとなります。\nbin/plugin install /path/to/logstash-output-kafka-1.0.0.gem プラグインの削除 bin/plugin uninstall logstash-output-kafka 1つまた全プラグインのアップデート bin/plugin update bin/plugin update logstash-output-kafka プラグインのリストアップ bin/plugin list bin/plugin list elasticsearch ( List all plugins containing a name ) bin/plugin list --group output ( list all outputs ) ドキュメント プラグインが個別に管理されても、全プラグインのドキュメントは1カ所です。\nlogstash plugin開発者: プラグイン開発者と作者は、Logstashエコシステムのためにプラグインを公開することができます。 プラグインは、gemやJavaライブラリの依存関係を宣言できます。 より重要なのは、Logstashのリリース間隔に関係なく、プラグインの改善版をリリースできます。\nRubygemsテクノロジはパッケージングシステム、依存関係管理、ホスティングのために選択されてきました。 Rubyのgemを公開することに慣れている開発者は、Logstashプラグインを簡単に公開することができます。 Elasticsearchはこれらの機能に関して開発者を支援するために、ツールを提供、メンテナンスします。\n開発およびローカルでのテスト JRuby 1.7.16がプラグインを開発するための唯一の前提条件です。 プラグインにパッチを提供するのは以前と同様です。 例えば、logstash-output-kafkaにパッチを送るのは次のようになります。\ngit clone https://github.com/logstash-plugins/logstash-output-kafka.git 変更 プラグインをローカルでテスト bundle install bundle exec rspec Logstashの他のバージョンもしくはローカルでテストする場合、Gemfileを編集し、 次のように別のロケーションを加えます。gem \u0026quot;logstash\u0026quot;, :github =\u0026gt; \u0026quot;elasticsearch/logstash\u0026quot;, :ref =\u0026gt; \u0026quot;master\u0026quot; 新しいPull Requestをlogstash-output-kafkaに対して作成 コミュニティでコードレビューを受け、Elasticsearchがパッチを受け入れ バージョン バージョン情報は、それぞれのプラグインの.gemspecで管理します。 例えば、Apache Kafka outputのgemspecはこちらです。 バージョニングはsemantic versioningのルールに従い、 Logstashのバージョニングとは別に、プラグインの開発者によって管理されます。 Logstash 1.5.0がリリースされると、マイルストーン1のプラグインはバージョン1.0.0となり、マイルストーン2のプラグインはバージョン2.0.0となるでしょう。\n公開 開発者が変更を加えプラグインを公開したいと思った時、.gemspecのバージョン番号を変更します。 全テストが成功した時、Elasticsearchはrubygems.orgにプラグインを手動で公開します。 もし、テストが失敗した場合、プラグインは公開されません。 長期的には、プラグインの公開の自動化を行いたいと思っています。 この変更は新しいため、公開の自動化を提供する前に、自動化についてより理解し、プラグインのテスト基盤を改良したいと思っています。\nIssue Issueは、各プラグインのGitHubリポジトリに対してオープンなければなりません。 Logstashコアのリポジトリは、コアのパイプラインや共通的な機能に関連するIssueについて扱います。\nドキュメント プラグインのドキュメントはソースコード自体から生成されます。 それぞれのプラグインのドキュメントは、そのプラグインのリポジトリに含まれます。 Elasticsearchは elasticsearch.org/guideに全てのプラグインのドキュメントを集め生成できる基盤を提供します。\n移行 全ての新しいpull requestとissueはlogstash-plugin organisation配下にある各プラグインのリポジトリに対してオープンする必要があります。\nすでにあるPRはどうすれば良いですか？ 気にしないでください。すでにあるpull requestは開発者によって移行する必要はありません。 LogstashチームがLogstashコアリポジトリに対してのPRを、個別の関連するプラグインのリポジトリに対してマージします。\ngit clone … # clone the specific plugin repo # now apply the patch curl -s https://github.com/elasticsearch/logstash/pull/XXXX | git am --3way git push Note:このプロセスはすでにあるPRに対してgit historyを管理します\nGitHub Issue 現在、LogstashリポジトリにオープンされているIssueは、それぞれのプラグインのリポジトリに移行します。 Logstashチームがgithub.com APIを利用してこの処理を自動的に行います。 安心してください。私たちが個別のプラグインに対する既存のIssueを移行します。\n今後のロードマップ これは、最初のステップであり、これらの変更は、ユーザや開発者に対してエコシステムをよりよくするために、 しっかりとした基盤を提供します。\n短期的には、開発者のためにpull requestのフィードバックでテスト自動化を提供する基盤を追加していきます。 プラグインリポジトリのブートストラップや管理のためのツールも提供していきます。\n長期的には、すべてのLogstashプラグインを探し、公開するためのコミュニティポータルを提供したいと思っています。 このアイデアは、Puppet ForgeやAWS marketplaceのようなものです。\nLogstash 1.5.0 Beta 1をリリースし、これは新しいエコシステムを提供します。 ぜひ、試していただき、これらの変更に関して感じたことを教えてください。 あなたのフィードバック(TwitterもしくはGitHub)はとても貴重です！\n","date":1418486440,"dir":"post/2014/","id":"4a3c42c9c5ac29db268010bbebf4f579","lang":"ja","lastmod":1418486440,"permalink":"https://blog.johtani.info/blog/2014/12/14/plugin-ecosystem-changes/","publishdate":"2014-12-14T01:00:40+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：exciting logstash plugin ecosystem changes Logstash 1.5.0 Beta 1(お試しはこちら)のリリースで、 プラグインのインストー","tags":["logstash"],"title":"Logstashプラグインのエコシステムの変更（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：logstash 1.5.0.beta1 released\nLogstash 1.5.0 Beta1をリリースしました。こちらのページからダウンロードできます。\nNote: ベータリリースです。本番環境では使用しないでください。\n1.5.0の主な変更点は？ 1.5.0の主なテーマはプラグイン管理、パフォーマンス改善、Apache Kafkaインテグレーションです。Logstashの主な特徴の1つは プラグインを利用できることであり、パイプラインの動作を拡張するためにプラグインを追加するのが簡単なことです。 このリリースで、プラグインの開発、管理、公開がより簡単になります。 また、Logstashの速度をより良くしたため、より多くのデータを短時間に処理することができます。 興味ありませんか？では、詳細を見ていきましょう。\nplugin ecosystemの変更 Logstashは165ものプラグイン(inputs、filters、outputs、codecs)を持っており、 これらはElasticsearchとコミュニティからのコントリビュートで開発されています。 多くのプラグインを管理することは、使いやすさと素早さの間のトレードオフがあります。 Logstashの全てのプラグインをまとめることは使いやすさがある一方、プラグインの更新を取り込むために Logstashの新しいリリースを待ってもらうことになります。 Logstashからプラグインを分離して個別に配布する場合、更新は簡単になりますが、使いやすさ（特に新しいユーザに）に影響が出ます。\n私たちは、プロジェクトを前進させるために、これらのバランスをとることを考えました。 これまで、全ての利用可能なプラグインは’core’と\u0026rsquo;contrib\u0026rsquo;の2つに分割していました。 \u0026lsquo;core\u0026rsquo;にあるよく使われるプラグインは、Logstashに含めていました。 コミュニティによりコントリビュートされたプラグインは\u0026rsquo;contrib\u0026rsquo;パッケージとして分離して配布していました。 1.5.0のリリースで、ユーザに対してより良いプラグイン管理をできるように変更しました。 全てのプラグインは、それ自身によるパッケージに移行しました。 パッケージングフレームワークとしてrubygemsを使い、rubygem.org経由でこれらのプラグインを配布、公開します。 また、Logstashにプラグインのインストール、更新、削除を簡単にするための構造も追加しました。\n例えば、S3 output pluginをインストールするには、以下のコマンドを実行します。\n$LS_HOME/bin/plugin install logstash-output-s3 それだけです！Logstashがgemと依存するgemをrubygems.orgからダウンロードし、インストールします。 あなたは、S3にデータを送ることができるようになります。\nダウンロード可能なLogstashリリースはプラグインをまだ多く含んでいますが、 いつでも、個別にプラグインをアップグレードし、インストールすることができます。 プラグインエコシステムの変更に関する詳細のブログ記事をお待ち下さい。\nパフォーマンス改善 Logstash 1.5.0はより高速になっています。パフォーマンスが改善された2カ所について説明します。\ngrok filter Grok filterはLogstashで、構造化データを抽出するためにパターンを記述するのに使われます。 本リリースで、人気のある幾つかのパターンのgrok filterのスループットを100%に改善しました。 言い換えると、grok filterを使うときに、Logstashを通してより多くのデータを処理することができます。\n私たちのベンチマークテストで、1.5.0と1.4.2のスループットの比較をしました。 利用したデータは690万件のApache Webアクセスlogで、COMBINEDAPACHELOGのgrok patternです。 1.5.0で、スループットは34,000 event per sec(eps)から50,000 epsに増加しました。 両方のテストを8コアのマシンでLogstashで8つのワーカーを実行しました。 これらのテストで、一つのgrok filterを実行し、 stdinとstdoutを使ったパイプラインでイベントのスループットを計測しました。 全体的なパフォーマンスは、様々なハードウェアやLogstashのコンフィグによって変化することに注意してください。\njson serialization / deserialization JSONのシリアライズ/でシリアライズをJrJacksonライブラリを利用して実装しました。 これにより、100%以上のスループットの改善がありました。 先ほど説明したパフォーマンステストにおいて、1.3KBのサイズの500,00 JSONイベントを送信し、 16,000 epsから30,000 epsにスループットが改善しました。 45,000サイズのイベントで、850 epsから3500 epsにスループットが増加しました。 すばらしいです。\napache kafka integration いまでは、Apache Kafkaが大規模スケールデータ処理システムでよく利用されます。 Logstashの配備のスケーリングにおいて、Kafkaもまた、shippingインスタンスとindexingインスタンス間の データを保存するための中間メッセージバッファとして使うことができます。\n1.5.0で、Logstash Kafkaのinputとoutputのプラグインのビルトインサポートを追加しました。 これは、Joseph Lawsonによって最初に開発されました。 私たちは、これらのプラグインにインテグレーションテストとドキュメントを追加することにより改良し、 新しいKafkaの機能を開発し続けます。 また、Apache Avro codecを追加することで、Kafkaに保存されたイベントを 簡単に取得でき、ELKスタックを使ってそれらを解析できるようにしました。\nKafka inputを追加するのは次のコマンドです。\n$LS_HOME/bin/plugin install logstash-input-kafka Kafka outputは次のコマンドです。\n$LS_HOME/bin/plugin install logstash-output-kafka セキュリティに関する改善 認証と経路暗号化のサポートを追加し、Elasticsearchのoutput、input、filterのセキュリティを改良しました。 例えば、HTTPプロトコルでSSL/TLSにより暗号化を有効にでき、 HTTPベーシック認証をユーザ名とパスワードをリクエストに与えることで設定できます。 これらの機能は、時期にリリースされるElasticsearch ShieldセキュリティプロダクトとLogstashを統合できます。\nドキュメント これまで、Logstashのドキュメントは[logstash.net])(http://logstash.net/)に置いてあり、 他のELKスタックと一緒に動かす時に、情報を探すのが厄介でした。 1.5.0および、今後のバージョンのドキュメントはelasticsearch.orgのLogstash Guideに移行します。 この移行でelasticsearch.org/guideにELKスタックを利用、 学習するためにドキュメントが1つになりました。 このベータリリースのイテレーションで、私たちはプレゼンテーションとドキュメントの品質を改善することに活発に取り組んでいきます。 (過去のLogstashのドキュメントの全てはいままでのlogstash.netで引き続き公開していく予定です。)\nバグフィックスと改善 ここまでの新しい機能に加えて、Logstash 1.5.0では、多くのバグフィックスと多くの機能改善があります。 ここで、これらのいくつかを紹介します。\n出力しない\u0026rsquo;metadata\u0026rsquo;をイベントに格納可能に。これは、例えば、date filterに使う中間フィールドのために必要。(#1834, #LOGSTASH-1798) HTTPを利用しているときのファイルデスクリプタリークの修正。Logstashがストールするのを防ぎ、OOMエラーからクラッシュするケースも防ぎます。(#1604) Twitter input:full_tweetオプションの追加、Twitter rate limitingエラーのハンドリング(#1471) イベントを生成するfilter(multiline、clone、split、metrics)により、 後続の条件文にこれらのイベントを正しく伝搬(#1431) Elasticsearch output:Logstashはデフォルトでmessage.rawフィールドを作成しない。messageフィールドはElasticsearch によりnot_analyzedでマルチフィールドとして追加される。マルチフィールドはディスクスペースが2倍必要だが、利点がない。 bin/logstashの複数のサブコマンドを除去(#1797) これらの機能、改善、バグフィックスについては、Logstash 1.5.0.Beta1 のchangelogをごらんください。\n試してみてください！ ぜひ、Logstash 1.5.0 Beta 1をダウンロードして試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1418372246,"dir":"post/2014/","id":"1bc36080b2493aab78c26e4f2152542c","lang":"ja","lastmod":1418372246,"permalink":"https://blog.johtani.info/blog/2014/12/12/logstash-1-5-0-beta1-released-ja/","publishdate":"2014-12-12T17:17:26+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：logstash 1.5.0.beta1 released Logstash 1.5.0 Beta1をリリースしました。こちらのページからダウンロードで","tags":["logstash"],"title":"Logstash 1.5.0 Beta1リリース(日本語訳)"},{"contents":"早いもので、師走です。今年もあと少しとなりました。ということで、Advent Calendarの季節が始まりました。\nこの記事はElasticsearch Advent Calndar 2014の1日目のエントリです。\n1日目ということで、簡単に今年の変遷を振り返りつつ、今年導入された新機能についてピックアップしてみようかと思います。\n1.0リリース(Lucene 4.6.0) 今年一番の目玉と思いますが、1月にRCが公開されて、1.0.0が2月にリリースされました。 （ElasticSearch Serverの翻訳が昨年末に終わってレビューをしていた段階での発表だったので個人的にはきついタイミングでした） 1.0の主な変更点はこちら。\nElasticsearch（Sが小文字に） 1.0からSが小文字になりました。(#4634) 0.90以前のバージョンについては、Sが大文字になっています。 ややこしいですが、今年の3月に出版された黒いElasticSearch Server日本語版は原著が0.20で日本語版にするタイミングで0.90に対応しました。 このため、こちらの書籍のタイトルはSが大文字となっています。 （なお、原著の2nd Editionは小文字になっています）\nSnapshot/Restoreの導入とGatewayの廃止 0.90以前のバージョンでは、gatewayというモジュールで、S3などにインデックスのメタデータなどを保存する機能がありました。 この機能は、0.20からlocal以外はdeprecatedとなりました。\nインデックスのバックアップ、リストアのために、1.0で実装されたのがSnapshot/Restoreです。 Snapshot/Restoreでは、インデックスごと、もしくはクラスタ全体をリモートにあるリポジトリにスナップショットを取ることが可能となりました。 初期リリースの段階では、共有ファイルシステムのみでしたが、現在は、S3やHDFSなどに保存が可能となっています。\nAggregation Facetをより強力にしたものです。Facetでは、指定したフィールドの集計のみでした。 データの解析などを行うには、独自で集計する必要がありました。 この機能をより柔軟に行えるように実装したのがAggregationです。\nたとえば、アクセスログを日毎に集計し、さらに日毎の集計に対して国別の集計やユーザエージェントごとの集計をさらに行うといった感じです。 Facetの場合は、日毎の検索結果に対して個別に集計するのみでしたが、Aggregationを使うことで、1週間の検索結果に対して、 日毎に国別の集計を行うといったことが可能になっっています。\ncat API \u0026ldquo;=^.^=\u0026ldquo;猫が出てくるAPIです。(違う)\nElasticsearchでは、クラスタの状態などが全てREST APIで取得でき、JSONで結果が帰ってきていました。 JSONはプログラムなどで処理を行う場合は便利ですが、コンソールで確認したり、管理系のツールでメールで通知する場合などは見にくいことがあります。 これを解消したのが_cat APIです。（公式の紹介ブログはこちら）\nCircuit Breaker OOMが発生しそうなfielddataの読み込みを検知して、事前に防ぐ機構になります。 初期段階ではFielddataに対してのものから実装されました。\n1.1リリース(Lucene 4.6.1) 3月にリリースされました。Elasticsearchはまだまだ発展しているため、リリースのサイクルが短いのが特徴です。\n1.x系では、Rolling Upgradeが導入されました。このため、クラスタ全体を停止することなく、クラスタのアップグレードが可能になりました。\nsearch templates 検索クエリをテンプレートとして登録することができるsearch templatesです。 JSONでクエリを記述できるのは便利ですが、毎回組み立てるのは大変かもしれません。 特に、固定のクエリをプログラムから利用するような場合などです。 テンプレートとして登録しておくことで、検索時に値を埋め込むだけで検索ができるようになりました。\nAggregationの強化 Aggregationの種類が増えました。\ncardinality：ユニークユーザ数の集計などが行えるaggregationです。HyperLogLog++アルゴリズムを利用した実装になっています。 significant_terms：単語の数による集計ではなく、コレクション全体に対する単語の頻度と、検索結果に対する単語の頻度を計算することで、重要度を計ることができます。 percentiles：パーセンタイル値を計算できます。 1.2リリース(Lucene 4.8系) Java 7必須 利用しているLuceneがJava 7必須となったためです。また、Java 6のEOLも切れてますし。\ndynamic scriptingがデフォルトオフ 採用していたMVELがサンドボックス化に対応していないため、危険を回避するためにオフとなりました。\nインデキシングとマージング インデキシングとマージ処理に関するさまざまな改善。\nflushのthreasholdを操作回数ではなく、サイズや時間によるものに変更 デフォルトをConcurrentMergeSchedulerに変更 1.3リリース(Lucene 4.9.0系) セキュリティ関連 JSONPのデフォルトオフ MVELの非推奨化（1.4で削除）＋script.disable_dynamicのデフォルト値がsandbox aggregationの強化 top hits：Field Collapsing/combiningと呼ばれる機能です。たとえば、いくつかのサイトのHTMLを収集して検索機能を提供する場合に、ドメインごとに1件ずつ検索結果に出したい場合などに利用できる機能です。 その他にも以下のaggregationが追加されています。\npercentile ranks geo bounds mappingのtransform Mappingにtransform機能が追加されました。 mappingにドキュメントの値を元に、インデキシング時に変換処理を記述できます。 たとえば、特定のフィールドにある値がある場合にだけ、あるフィールドに値を入れるなどといったことが可能になります。\nディスク関連 disk based shard allocation deciderが導入されました。ノードのディスクの使用率を元に、シャードを配置しても良いかといった決定を行う機構です。 チェックサムによるファイルのチェック（Lucene4.9で導入されたコードへの切り替え） 1.4リリース(Lucene 4.10系) ベータ版が出されるほど、多くの改善が入っています。\nresiliency メモリ使用量の低下によるノードの安定性向上 DocValues、リクエストごとのcircuit breakerなど discoveryアルゴリズムの改善によるクラスタの安定性向上 チェックサムの導入による破損したデータの検知 セキュリティ関連 CORSをデフォルト無効 Groovyがデフォルトのスクリプト言語に。 Aggregationの強化 以下のaggregationが追加されています。\nfilter、children、scripted_metric Upgrade API インデックスを最新のバージョンのものにアップグレードするためのAPIです。 Luceneは下位互換を保ってくれているため、古いバージョンのインデックスも読み込むことが可能です。 ただ、最新バージョンで使える機能が制限されていたりということもあります。 クラスタにあるインデックスをアップグレードするのにかかる時間や必要かどうかといったことを取得できる仕組みも提供します。\nまた、Lucene自体は、1つ前のメジャーバージョン（4.x系だと3.x系まで）までの互換性は提供していますが、 2つ前のメジャーバージョンの互換性がなくなります。 Luceneも5.x系のブランチが作成されており、5系のリリースにより、3系との互換性がなくなります。 5系のリリースに対応する場合にも、こちらのAPIが助けになるかと。\n1.4.1 11\u0008/27に1.4.1がリリースされました。 シャードの配置やparent/child、nestedドキュメントの改善などが行われています。\nまとめ ということで、駆け足で、1月から11月までのElasticsearchの流れを追ってみました。 1.0で大きな機能追加、改善が行われ、その後も活発に開発が行われています。 要望などがあれば、MLで聞いてみたりやGitHubに登録するなどを行っていただければと。\nあと、今年から来年にかけての大きなイベントとして、 Elasticsearch初のユーザカンファレンスのサイトがオープンしました。 Elasticsearchに関するいろいろな話が聞ける機会だと思うので、興味のある方は見ていただければと。\nでは、また次のAdvent Calendarで！（最終日の予定ですが、空きがあるのでなにか書くかも）\n","date":1417424748,"dir":"post/2014/","id":"2de582c67fca31500621ecd6d3917a07","lang":"ja","lastmod":1417424748,"permalink":"https://blog.johtani.info/blog/2014/12/01/about-elasticsearch-in-2014/","publishdate":"2014-12-01T18:05:48+09:00","summary":"早いもので、師走です。今年もあと少しとなりました。ということで、Advent Calendarの季節が始まりました。 この記事はElastics","tags":["elasticsearch"],"title":"2014年のElasticsearch"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch 1.4.1 and 1.3.6 released\n本日、Lucene 4.10.2をベースにしたElasticsearch 1.4.1と、バグフィックスリリースである、Elasticsearch 1.3.6をリリースしました。 ダウンロードおよび変更リストはそれぞれ次のリンクからアクセスできます。\n最新ステーブルリリース：Elasticsearch 1.4.1 1.3.x系バグフィックス：Elasticsearch 1.3.6 過去のリリースに関するブログ（公式）はこちら。\n1.4:1.4.0, 1.4.0.Beta1 1.3:1.3.5, 1.3.4, 1.3.3, 1.3.2, 1.3.1, 1.3.0. すべての変更については1.4.1のリリースノートおよび1.3.6のリリースノートをごらんください。 以下では、重要な変更について紹介します。\nshard allocation Elasticsearch 1.3.0で、disk based shard allocationが デフォルトで有効になっています。 もし、ノードのディスクの使用量がlawで指定された値（85%）を超えた場合、ノードにはシャードが配置されません。 また、highで指定された値（90%）を超えた場合、シャードを他のノードへ移動します。\nElasticsearch 1.4.1では、disk based shard allocationに3つの改良が追加されました。\nディスク使用量のチェックはシャードがクラスタに配置されるタイミングでのみ実施していた。現在は60秒ごとに使用量をチェック。(#8270) ディスクフルメッセージはDEBUGレベルでログに出力されていました。なぜ、新しいシャードが配置されないのかを説明するのが困難でした。現在はWARNレベルで30秒ごとにログに出力されます。(#8382) 以前は、シャードをもう一つのノードへ動かすべきかどうか決めるとき、allocation deciderはノードにあるシャードのサイズを考慮するだけでした。現在は、動かされるシャードのサイズも考慮します。これにより、必要最小限のシャードの移動量となります。(#8569) parent/child and nested documents Elasticsearch 1.4.0で、parent/childとnestedドキュメントに対して（新しいセグメントを開くときに）固定長ビットセットフィルタを構築しキャッシュしました。クエリ、フィルタおよびAggregationを常に速くするためにです。 多くのnestedフィールドを持つユーザにとっては、以前のバージョンよりもヒープの使用量が大きくなってしまいました。\nnested aggregationによって処理されるドキュメントの順序を変更すること(#8454)によって、固定長ビットセットフィルタが子のドキュメントに対して必要でなくなりました。 現在は、親のドキュメント（つまり、nestedではないドキュメント）を表すフィルタのみをキャッシュしています。これにより必要なキャッシュ空間のサイズを減少しました。(#8414、#8440)\ndate ranges 2つの日付範囲に関する問題がこのリリースで修正されました。 1つ目は、日付を丸めるかというものです。例えば、timestampフィールドに1秒の解像度の値があるとします。 {\u0026quot;lt\u0026quot;: \u0026quot;2014/11/26||/d\u0026quot;}というrangeフィルタは2014/11/26 00:00:00未満のタイムスタンプのデータを結果として返しました。 しかし、ltをlteに変更した場合、2014/11/27 00:00:00以外の値も含めたいです。\n以前は、lteは2014/11/27 00:00:00のタイムスタンプも含めてしまっていました。現在は、想定通りの動作をします。(#8556)\n2つ目のバグは日付の範囲条件にnow()を利用したaliasとpercolatorフィルタです。 now()の値を、フィルタが作成したタイミングで決定していました。フィルタが実行されるたびに更新せずにです。 #8534で、now()はaliasとpercolatorで想定通りの動作をします。\n試してみてください。 ぜひ、Elasticsearch 1.4.1をダウンロードして、試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1417056212,"dir":"post/2014/","id":"0a8183ced0e9e3e895b41286e54e8e4d","lang":"ja","lastmod":1417056212,"permalink":"https://blog.johtani.info/blog/2014/11/27/elasticsearch-1-4-1-released-ja/","publishdate":"2014-11-27T11:43:32+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.1 and 1.3.6 released 本日、Lucene 4.10.2をベースにしたElas","tags":["elasticsearch"],"title":"Elasticsearch 1.4.1および1.3.6リリース（日本語訳）"},{"contents":"前回の「Logstashを利用したApacheアクセスログのインポート」の続きです。 前回の記事では、Logstashの設定ファイルについて説明しました。 今回は「Elasticsearchに設定するインデックステンプレート」について説明します。\nテンプレートの設定 Elasticsearchでは、登録するデータの特性に合わせてMappingを定義する方がデータを効率良く扱うことができる場合があります。 この場合、通常ですと、インデックス作成時にMappingを指定します。\nただ、今回は、インデックス名に「年」を含める形で指定してあります。 「年」はLogstashで処理したデータによって決まります。このため、あらかじめMappingを指定してインデックスを作成するのは難しいです。\nこのような場合に便利な機能として、「インデックステンプレート」があります。\nインデックステンプレートとは 実際のテンプレートの説明に入る前に、少しだけ説明を。 インデックステンプレートとは、インデックスが作成されるタイミングで自動的に適用される設定をテンプレートとして登録できる機能のことです。 実際にテンプレートが適用されるかどうかは、インデックス名で判断されます。\n例えば、大して重要でもなく、データ量も少ないインデックス用のテンプレートとして、シャード数が1、レプリカ数が0、\u0026quot;_source\u0026quot;を保存しない設定のテンプレートを登録する場合、 次のようになります。\ncurl -XPUT localhost:9200/_template/template_1 -d \u0026#39; { \u0026#34;template\u0026#34; : \u0026#34;te*\u0026#34;, \u0026#34;settings\u0026#34; : { \u0026#34;number_of_shards\u0026#34; : 1, \u0026#34;number_of_replicas\u0026#34; : 0 }, \u0026#34;mappings\u0026#34; : { \u0026#34;type1\u0026#34; : { \u0026#34;_source\u0026#34; : { \u0026#34;enabled\u0026#34; : false } } } } \u0026#39; _templateがインデックステンプレートを登録するためのエンドポイントです。 template_1がこのテンプレートのIDです。削除などについては、このIDを利用します。\nそして、重要なのは、\u0026quot;template\u0026ldquo;の設定です。 \u0026ldquo;template\u0026ldquo;には、このテンプレートが適用されるべきインデックス名を記載します。 上記サンプルではte*となっているため、teで始まる名前のインデックスを作成した場合にテンプレートにある設定が適用されます。\n今回利用するテンプレート 私がJJUG CCCや第7回Elasticsearch勉強会のKibana4のデモで利用したインデックスのテンプレートは次のものになります。 \u0026ldquo;template\u0026ldquo;には、前回の記事で紹介したoutput/elasticsearchの設定 に合致するnew_demo_access_log-*を指定しています。\ncurl -XPUT localhost:9200/_template/new_access_log_for_demo -d \u0026#39; { \u0026#34;template\u0026#34;: \u0026#34;new_demo_access_log-*\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;number_of_shards\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;number_of_replicas\u0026#34;: \u0026#34;0\u0026#34; }, \u0026#34;mappings\u0026#34;: { \u0026#34;_default_\u0026#34;: { \u0026#34;dynamic_templates\u0026#34;: [ { \u0026#34;string_template\u0026#34;: { \u0026#34;mapping\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;match_mapping_type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;match\u0026#34;: \u0026#34;*\u0026#34; } } ], \u0026#34;properties\u0026#34;: { \u0026#34;path\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;multi_field\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;no_analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;referer\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;multi_field\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;no_analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;agent\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;multi_field\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;no_analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;geoip\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;object\u0026#34;, \u0026#34;properties\u0026#34;: { \u0026#34;location\u0026#34;: { \u0026#34;geohash\u0026#34;: true, \u0026#34;geohash_precision\u0026#34;: 10, \u0026#34;type\u0026#34;: \u0026#34;geo_point\u0026#34;, \u0026#34;lat_lon\u0026#34;: true, \u0026#34;geohash_prefix\u0026#34;: true } } }, \u0026#34;response\u0026#34;: { \u0026#34;copy_to\u0026#34;: \u0026#34;response_int\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;bytes\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;response_int\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;integer\u0026#34; } } } } } \u0026#39; settings設定 デモ用であり、手元で2台のノードを起動するということもあり、number_of_shardsに2を、number_of_replicasに0を指定してあります。\nmappings設定 インデックスのタイプ Mappingsの指定は通常、特定のタイプを指定します。 今回のデモでは、1種類しかないのですが、タイプ名を特に意識しないために、_default_を使用しました。 この場合、任意のタイプに適用されることとなります。 タイプを指定してMappingの設定を行う場合は_default_の部分に特定のタイプ名を記入します。\n\u0026#34;mappings\u0026#34;: { \u0026#34;_default_\u0026#34;: { ... ダイナミックテンプレート 次はダイナミックテンプレートです。 インデックステンプレートはインデックスの設定をテンプレート化しました。ダイナミックテンプレートはフィールドに対してテンプレートを設定できます。\n以下のダイナミックテンプレートでは、stringタイプのフィールドのデフォルト設定を変更しています。 通常、stringタイプのフィールドはanalyzedとなりますが、not_analyzedに変更してあります。 詳しく検索したいフィールドの方が少ないためです。\n... \u0026#34;dynamic_templates\u0026#34;: [ { \u0026#34;string_template\u0026#34;: { \u0026#34;mapping\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;match_mapping_type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;match\u0026#34;: \u0026#34;*\u0026#34; } } ], ... multi_field指定 検索もしたいし、Terms Aggregationでも利用したいフィールドについては、multi_fieldを利用して、 analyzedとnot_analyzedの2種類のフィールドを用意しています。 multi_field設定を用いることで、1つのJSONのデータから、異なる形のフィールドを用意することが可能です。\n今回のテンプレートでは、path、referer、agentにmulti_fieldを指定しました。\n... \u0026#34;path\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;multi_field\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;no_analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, ... 例えば、上記の設定の場合、入力のJSONはpathというデータのみですが、インデックス上にはpath.no_analyzedと path.analyzedというフィールドができあがります。 実際に検索する場合は、path.analyzed:検索したい文字列という形で検索をすることで、いわゆる部分一致のような検索が可能です。 また、完全一致をしたい場合はpath.no_analyzed:検索したい文字列という指定になります。 用途を考えると、requestも指定したほうが良いかもしれません。\ngeoip Logstashでgeoipデータを付与していました。 このgeoipのデータをKibana4で利用するために、geoデータとして登録する必要があります。\n\u0026#34;geoip\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;object\u0026#34;, \u0026#34;properties\u0026#34;: { \u0026#34;location\u0026#34;: { \u0026#34;geohash\u0026#34;: true, \u0026#34;geohash_precision\u0026#34;: 10, \u0026#34;type\u0026#34;: \u0026#34;geo_point\u0026#34;, \u0026#34;lat_lon\u0026#34;: true, \u0026#34;geohash_prefix\u0026#34;: true } } }, 上記の設定がgeoデータの指定です。 typeにobjectが指定してありますが、これは、geoipのデータがネストしているためです。 geoipオブジェクトのうち、緯度経度のデータはlocationに入っているため、こちらに緯度経度関係の設定を指定します。\n\u0026quot;type\u0026quot;: \u0026quot;geo_point\u0026quot;：geo_pointタイプであることを指定 \u0026quot;geohash\u0026quot;: true：緯度経度のデータをもとに、geohashの値もインデックス \u0026quot;geohash_precision\u0026quot;: 10：geohashの精度の指定 \u0026quot;lat_lon\u0026quot;: true：緯度経度を個別の.lat、.lonというフィールドにもインデックス \u0026quot;geohash_prefix\u0026quot;: true：該当するgeohashのみでなく、その親にあたるgeohashについてもインデックスする response、response_int、bytes 最後は、response、response_int、bytesです。\nresponseには、HTTPステータスコードが入ります。 文字列としても扱いたいですが、integerとして、Renge Aggregationなどを行いたいので、 response_intというフィールドにも値を入れています。 multi_fieldでも可能ですが、ここでは、copy_toを利用しました。 copy_toを用いることで、異なるフィールドに値をコピーすることができます。\nbytesについては、longで扱いたいとういう理由だけです。\n\u0026#34;response\u0026#34;: { \u0026#34;copy_to\u0026#34;: \u0026#34;response_int\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;bytes\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;response_int\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;integer\u0026#34; } まとめ 今回はデモに利用したインデックスてプレートについて説明しました。 前回の、Logstashの設定とこのインデックステンプレートを用いることで、Kibanaで解析するデータの準備ができます。 実際の操作などについては、また次回の記事で説明しようかと思います。\n不明な点、誤植などありましたら、コメント欄へお願いします。\n","date":1416900346,"dir":"post/2014/","id":"4d8f5e581eee602c7fd21da8eb68df9a","lang":"ja","lastmod":1416900346,"permalink":"https://blog.johtani.info/blog/2014/11/25/import-apache-accesslog-using-logstash-2/","publishdate":"2014-11-25T16:25:46+09:00","summary":"前回の「Logstashを利用したApacheアクセスログのインポート」の続きです。 前回の記事では、Logstashの設定ファイルについて説","tags":["logstash","kibana","elasticsearch"],"title":"インデックステンプレートとLogstash"},{"contents":"JJUG CCCや第7回Elasticsearch勉強会のKibana4のデモにアクセスログを利用しました。\nただ、セッションでは、どうやってElasticsearchに投入したのかという詳しい話をしていませんでした。 本記事では、データ取り込み時に利用したLogstashの設定ファイルについて説明します。\nLogstashの設定の説明に入る前に、全体の流れを。 「ApacheアクセスログをKibana4により可視化」です。\n材料の準備 「ApacheアクセスログをKibana4により可視化」に必要な材料は次の通りです。 （今回は起動するところまでいかないので、実際に必要なのは次回以降になります。）\nJava 7（u55以上を1つ） Logstash 1.4.2（1つ） Elasticsearch 1.4.0（1つ） Kibana4 Beta2（1つ） Apacheのアクセスログ（適量） Apacheのアクセスログ以外は、公式サイトからダウンロードできます。 それぞれをダウンロードして、起動できるようにしておきましょう。\n※1台のマシン上で行う場合は、アクセスログの量を少なめにするなどの対策をとりましょう。 ※今回は、1台のマシン（Mac）上で、VMなどを利用せず、それぞれ直接起動するものとします。\n可視化の手順と流れ 可視化の流れとしては、\nLogstashでファイルを読み込み、各種処理（パースしたり、情報を追加したり、切り出したり） Elasticsearchに保存 Kibanaでグラフを作ったり、検索してみたり です。\n今回は、1のLogstashでファイルを読み込んだりする設定ファイルの説明です。\nLogstashの設定 Logstashの基本 まずは、Logstashの設定ですが、簡単にLogstashの説明を。 Logstashは大きく3つのパーツに分かれています。\ninput：データの入力処理 filter：inputで読み込んだデータに対する操作など output：データの出力処理 inputでデータを読み込み（複数可）、filterでデータに対して各種処理を行い、outputでデータを指定されたところに出力（複数可）します。\nアクセスログの読み込み設定 アクセスログの読み込み処理は大まかに次のようなものとなります。\nアクセスログを読み込む（input/file） 読み取ったアクセスログを各フィールド（IPアドレス、ユーザエージェントなど）に分割（filter/grok） 日付のパース（filter/date） クライアントIPアドレスにgeoipの情報を付加（filter/geoip） リクエストのパスの第1階層の抽出（filter/grok） ユーザエージェントのパース（filter/useragent） Elasticsearchへの出力（output/elasticsearch） 設定ファイルは次のようなものになります。\ninput { file { path =\u0026gt; \u0026#34;/Users/johtani/demo_access_log/*/*.log\u0026#34; start_position =\u0026gt; \u0026#34;beginning\u0026#34; } } filter { grok { match =\u0026gt; { \u0026#34;message\u0026#34; =\u0026gt; \u0026#34;%{COMBINEDAPACHELOG}\u0026#34; } break_on_match =\u0026gt; false tag_on_failure =\u0026gt; [\u0026#34;_message_parse_failure\u0026#34;] } date { match =\u0026gt; [\u0026#34;timestamp\u0026#34;, \u0026#34;dd/MMM/YYYY:HH:mm:ss Z\u0026#34;] locale =\u0026gt; en } geoip { source =\u0026gt; [\u0026#34;clientip\u0026#34;] } grok { match =\u0026gt; { \u0026#34;request\u0026#34; =\u0026gt; \u0026#34;^/%{WORD:first_path}/%{GREEDYDATA}$\u0026#34; } tag_on_failure =\u0026gt; [\u0026#34;_request_parse_failure\u0026#34;] } useragent { source =\u0026gt; \u0026#34;agent\u0026#34; target =\u0026gt; \u0026#34;useragent\u0026#34; } } output { elasticsearch { host =\u0026gt; \u0026#34;localhost\u0026#34; index =\u0026gt; \u0026#34;new_demo_access_log-%{year}\u0026#34; cluster =\u0026gt; \u0026#34;demo_cluster\u0026#34; protocol =\u0026gt; \u0026#34;http\u0026#34; } } 1. アクセスログを読み込む（input/file） inputのfileモジュール(a)を使用してアクセスログのファイルを読み込みます。 pathでアクセスログのファイルのパスを指定します。 今回利用したアクセスログはdemo_access_log/2010/access20100201.logといった日毎のファイルに分割されていたため、 *を利用してファイルのパスを指定しました。 また、今回は既存のファイルの読み込みだけのため、start_positionにbeginningを指定してあります。 デフォルトではendが指定されるため、Logstashを起動後に追記されたログから対象になってしまうためです。 その他の設定については、公式ガイドをご覧ください。\ninput { file { # a path =\u0026gt; \u0026#34;/Users/johtani/demo_access_log/*/*.log\u0026#34; # b start_position =\u0026gt; \u0026#34;beginning\u0026#34; # c } } Logstashでは、ファイルをどこまで読み込んだかという情報を保持するために、sincedbを利用しています。 設定変更後に同じファイルを最初から読み込みたい場合などは、こちらのファイルを一旦削除するなどの対応が必要です。\nちなみに、読み込んだデータは次のようなJSONになっています。\n{ \u0026#34;message\u0026#34;: \u0026#34;読み込んだアクセスログ\u0026#34;, \u0026#34;@version\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;@timestamp\u0026#34;:\u0026#34;2014-11-21T06:16:21.644Z\u0026#34;, \u0026#34;host\u0026#34;:\u0026#34;jupiter.local\u0026#34;, \u0026#34;path\u0026#34;:\u0026#34;/Users/johtani/demo_access_log/2010/access20100201.log\u0026#34;} } 特に指定がない場合は、messageに読み込んだデータが入ってきます。 @timestampがLogstashが読み込んだ時刻、hostはLogstashが動作しているホスト名です。 pathはfileモジュールが読み込んだファイルのパスを設定しています。 この後の処理で、どこの項目に対して処理を行うかといったことが重要になるので、\n2. 読み取ったアクセスログを各フィールド（IPアドレス、ユーザエージェントなど）に分割（filter/grok） 2.〜6.の処理は、inputで読み込んだ1アクセスログに対する処理となります。\nここでは、grokフィルタを使用して Apacheのアクセスログを各フィールドに分割します。 Logastashでは、簡単に使えるようにいくつかのパターンが用意されています。 Apacheのログのために、COMBINEDAPACHELOGというのが用意されています。 今回はこちらを使用しています。その他にも日付などパターンが用意されているので、試してみてください。\nmessageにアクセスログが入っているので、こちらの項目に対してCOMBINEDAPACHELOGのパターンを matchで適用してフィールドに抜き出します。 tag_on_failureは、matchでパースに失敗した場合に、tagというフィールドに指定した文字列を出力する機能になります。 デフォルトだと_grokparsefailureが付与されますが、ここでは、どの処理で失敗したがを判別するために文字列を変更しています。\nfilter { grok { match =\u0026gt; { \u0026#34;message\u0026#34; =\u0026gt; \u0026#34;%{COMBINEDAPACHELOG}\u0026#34; } break_on_match =\u0026gt; false tag_on_failure =\u0026gt; [\u0026#34;_message_parse_failure\u0026#34;] } ... clientip、ident、auth、timestamp、verb、request、httpversion、response、bytes、referrer、agentがgrokフィルタにより抜き出された項目です。\n{ \u0026#34;message\u0026#34;:\u0026#34;アクセスログ\u0026#34;, \u0026#34;@version\u0026#34;:\u0026#34;1\u0026#34;, \u0026#34;@timestamp\u0026#34;:\u0026#34;2014-11-21T07:20:54.387Z\u0026#34;, \u0026#34;host\u0026#34;:\u0026#34;jupiter.local\u0026#34;, \u0026#34;path\u0026#34;:\u0026#34;/Users/johtani/demo_access_log/2010/access20100201.log\u0026#34;, \u0026#34;clientip\u0026#34;:\u0026#34;クライアントのIPアドレス\u0026#34;, \u0026#34;ident\u0026#34;:\u0026#34;-\u0026#34;, \u0026#34;auth\u0026#34;:\u0026#34;-\u0026#34;, \u0026#34;timestamp\u0026#34;:\u0026#34;01/Feb/2010:00:00:26 +0900\u0026#34;, \u0026#34;verb\u0026#34;:\u0026#34;GET\u0026#34;, \u0026#34;request\u0026#34;:\u0026#34;/images/favicon.ico\u0026#34;, \u0026#34;httpversion\u0026#34;:\u0026#34;1.1\u0026#34;, \u0026#34;response\u0026#34;:\u0026#34;200\u0026#34;, \u0026#34;bytes\u0026#34;:\u0026#34;318\u0026#34;, \u0026#34;referrer\u0026#34;:\u0026#34;\\\u0026#34;-\\\u0026#34;\u0026#34;, \u0026#34;agent\u0026#34;:\u0026#34;\\\u0026#34;Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)\\\u0026#34;\u0026#34; } 3. 日付のパース（filter/date） Logstashは特に指定がない場合、inputでデータを取り出した日付が@timestampとなります。 そして、このフィールドが特に指定がない場合は、Elasticsearchのデータの日付となり、Kibanaで利用する日付となります。\nリアルタイムにアクセスログを読み込む場合は、読み込んだ日時でもほぼ問題はありませんが、過去データの場合はそうもいきません。 そこで、dateフィルタを使用して、@timestampの値を書き換えます。\ndate { match =\u0026gt; [\u0026#34;timestamp\u0026#34;, \u0026#34;dd/MMM/YYYY:HH:mm:ss Z\u0026#34;] locale =\u0026gt; en } 上記では、timestampという項目に対してdd/MMM/YYYY:HH:mm:ss Zという日付パターンの場合に値を書き換える設定となります。 なお、日付の月の部分がFebとなっているため、localeにenを指定しています。Logstashが動作するマシンのlocaleがjaなどの場合にパースに失敗するためです。\n4. クライアントIPアドレスにgeoipの情報を付加（filter/geoip） どの国からのアクセスかなどを判別したいので、IPアドレスを元にgeoipを利用してより詳細な情報を付与します。 Logstashでもこの機能が用意されており、簡単に利用ができます。\ngeoip { source =\u0026gt; [\u0026#34;clientip\u0026#34;] } これだけです。対象とするIPアドレスのフィールドを指定しているだけです。 geoipというフィールドが追加され、次のような情報が付与されます。 国名、緯度経度、タイムゾーンなどです。\n{ ... \u0026#34;geoip\u0026#34;: { \u0026#34;ip\u0026#34;: \u0026#34;IPアドレス\u0026#34;, \u0026#34;country_code2\u0026#34;: \u0026#34;JP\u0026#34;, \u0026#34;country_code3\u0026#34;: \u0026#34;JPN\u0026#34;, \u0026#34;country_name\u0026#34;: \u0026#34;Japan\u0026#34;, \u0026#34;continent_code\u0026#34;: \u0026#34;AS\u0026#34;, \u0026#34;latitude\u0026#34;: 36, \u0026#34;longitude\u0026#34;: 138, \u0026#34;timezone\u0026#34;: \u0026#34;Asia/Tokyo\u0026#34;, \u0026#34;location\u0026#34;: [ 138, 36 ] } ... } 5. リクエストのパスの第1階層の抽出（filter/grok） リクエストされたURLはrequestフィールドにありますが、個別のURLだと、大まかな集計が大変です。 もちろん、クエリで処理することもできますが、Logstashで処理するついでに、第1階層のディレクトリ名を抽出しておくことで、 検索や集計を行いやすくしておきます。\ngrok { match =\u0026gt; { \u0026#34;request\u0026#34; =\u0026gt; \u0026#34;^/%{WORD:first_path}/%{GREEDYDATA}$\u0026#34; } tag_on_failure =\u0026gt; [\u0026#34;_request_parse_failure\u0026#34;] } また、grokフィルタの登場です。 今回は、WORD:first_pathという記述方法で、WORDパターンにマッチした文字列をfirst_pathというフィールドに展開する指定をしています。\n例えば、サイトのスクリプトなどがscriptsというディレクトリにある場合は、first_pathの値を利用して、 後続のフィルタでログデータを出力しないといった処理にも使えます。\n6. ユーザエージェントのパース（filter/useragent） Logstashではユーザエージェントの文字列から、いくつかの情報を付与するフィルタも用意されています。 useragentフィルタです。\nuseragent { source =\u0026gt; \u0026#34;agent\u0026#34; target =\u0026gt; \u0026#34;useragent\u0026#34; } agentというフィールドにユーザエージェントの文字列があるので、このフィールドに対してフィルタを適用します。 元の文字列も取っておきたいので、useragentという別のフィールドに出力するように指定してあります。\n\u0026#34;useragent\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;Firefox\u0026#34;, \u0026#34;os\u0026#34;: \u0026#34;Windows XP\u0026#34;, \u0026#34;os_name\u0026#34;: \u0026#34;Windows XP\u0026#34;, \u0026#34;device\u0026#34;: \u0026#34;Other\u0026#34;, \u0026#34;major\u0026#34;: \u0026#34;17\u0026#34;, \u0026#34;minor\u0026#34;: \u0026#34;0\u0026#34; }, このように、OS名やバージョン名などが抽出できます。\n7. Elasticsearchへの出力（output/elasticsearch） 最後は、Elasticsearchへのデータの出力設定です。\nindexにて、出力するindex名を指定してあります。 また、年毎のインデックス名にするために%{year}を利用しています。 sprintf formatです。\nelasticsearch { host =\u0026gt; \u0026#34;localhost\u0026#34; index =\u0026gt; \u0026#34;new_demo_access_log-%{year}\u0026#34; cluster =\u0026gt; \u0026#34;demo_cluster\u0026#34; protocol =\u0026gt; \u0026#34;http\u0026#34; } まとめ ということで、今回はアクセスログをLogstashにて読み込む時の設定について説明してきました。 次回は、実際にLogstashを起動してElasticsearchにデータを登録するところまでを説明します。\nJJUG CCCや勉強会のデモに用いたデータは、 Elasticsearchにデータを登録する前にテンプレートも設定してありました。こちらについても、次回説明しようと思います。\n不明な点、誤植などありましたら、コメント欄へお願いします。\n","date":1416558639,"dir":"post/2014/","id":"937a597a8b399fd32caba88a3c1c7bc4","lang":"ja","lastmod":1416558639,"permalink":"https://blog.johtani.info/blog/2014/11/21/import-apache-accesslog-using-logstash/","publishdate":"2014-11-21T17:30:39+09:00","summary":"JJUG CCCや第7回Elasticsearch勉強会のKibana4のデモにアクセスログを利用しました。 ただ、セッションでは、どうやってElas","tags":["logstash","kibana","elasticsearch"],"title":"Logstashを利用したApacheアクセスログのインポート"},{"contents":"第7回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n昨日も紹介しましたが、Elasticsearch Advent Calendar 2014を用意してみました。まだ、空きがありますので、登録お待ちしております！\n今回は出足が好調で、早々に180人の枠を超えるという嬉しい事態でした。 最終的な参加人数は130名程度で、懇親会参加者が50名弱といったところです。\n「Kibana4」 Elasticsearch Inc. Jun Ohtani @johtani スライド：Kibana4\nということで、Kibana4の紹介と、Kibana4のBeta2を利用したデモを行いました。 デモの開始のところで少し環境がうまく動いてなくて手間取ってしまいましたが。。。\n発表で1点だけ修正があります。JRubyを選択しているのがElasticsearchのライブラリを使用するためという説明をしましたが、 こちらは、Logstashに関する話でした。Kibana4は現時点では、ElasticsearchへのProxyとしての動作が主なものとなります。Rubyでも動作可能です。 bin/kibanaについてはJavaを使った起動になります。 参考：https://github.com/elasticsearch/kibana/tree/master/src/server\n発表でも主張しましたが、ダウンロードして、Elasticsearchを用意すれば簡単に動作させることが可能です。 ぜひ、ローカルで試して見てもらえればと思います。 今回のデモのデータを入れるのに利用したLogstashの設定などについては、ブログで記事を書こうと思います。\nniconicoの検索を支えるElasticsearch 株式会社ドワンゴ 伊藤 祥 さん スライド：niconicoの検索を支えるElasticsearch\nリアルタイム検索の実現、新しい検索への対応 検索のアーキテクチャとか。 Capistranoでデプロイとかを管理 1.4.1が出たら、クラスタを更新予定 ということで、実際に導入した話から、現在の運用の仕方、クラスタのアップグレードなど多岐にわたる内容でおもしろかったです。 遭遇した問題点とかもあったので。 Marvel便利なのでぜひ導入を検討してもらえればw\nElasticsearch at CrowdWorks\u2028株式会社クラウドワークス 九岡 佑介 さん @mumoshu スライド：Elasticsearch at CrowdWorks\n会社の紹介 仕事が検索対象 検索時間が1桁減少！ Graceful Degradationで失敗したら、InnoDB FTSで代替：Gracefully found.noのサービスを利用 elasticsearch-modelの拡張を作成してOSSとして公開：elasticsearch-model-extensions Gracefullyで切り替えとかは面白いなと思いました。 検索での利用の話でしたが、他のシーンでも使えそうですよね。 日本にFoundユーザがいるのも初めて知りました。 彼らの開発者ブログも質の良い情報が載っているので、参考になりますよね。\n次は、どんなMappingで運用しているのかとか、どういった工夫をしているかといった点を詳しく聞きたいなと思いました。 またお待ちしております。\n1分で作るElasticsearchプラグイン 株式会社エヌツーエスエム 菅谷 信介 さん スライド：Elasticsearchプラグインの作り方\n\u0008\u0008* プラグインの作り方とか。\n十数個のプラグインの紹介。プラグインはこちらで公開中。https://github.com/codelibs/ 実際に、業務で必要なものから作成 まだまだ作りたいものがある コミュニティ還元できるものはPR送ってもらえるとうれしいです。 前よりは体制も増えてるので、PRも目にとまるようになってるはずです。\nあとは、使ってみたいと思う方も多数いると思うので、ぜひ、OSSなので、貢献しましょう！ フィードバックがあるだけで、OSS活動やってるものにとってはやる気につながると思いますし。\nLT：GISとして活用するElasticsearch\u2028船戸 隆さん スライド：GISとして活用するElasticsearch\u2028java-jaからIngressの青（Registance）の勧誘に来られた方w APIをハックして、情報を取得し、Kibanaで可視化 残念ながら、APIが変更されて見れなくなったらしい。 Ingress実際にやったことはないのですが、おもしろそうでした。 発表される方の会社の採用紹介ではなく、Ingressの勧誘をされるとは想定外でしたw\n興味のあるデータをKibanaで可視化するのも面白い例だと思うので、活用してもらえればと思います。\nその他、感想などのブログ 適当に見つけたブログを列挙してあります。これもあるよ！などあれば、教えてください。\n勉強会メモ - 第7回elasticsearch勉強会 第7回elasticsearch勉強会 #elasticsearch #elasticsearchjp まとめ JJUGの時とは違い、Elasticsearch勉強会ではさすがに、企業としてのElasticsearchの知名度が高かったのはありがたいことでした。 自分の発表のために始めた勉強会でもありますが、まだまだ、発表するときは緊張しますし、分かりにくいんじゃないかなぁと思うことも多々あります。 この辺がわかりにくかった、この辺をもっと知りたいなど、フィードバックをお待ちしております。\n冒頭にも書きましたが、Elasticsearch Advent Calendar 2014の登録をお待ちしております。どんなことでも歓迎なので、Elasticsearch、Kibana、Logstashなどについて書いてもらえるとうれしいです。\n次回ももちろん2ヶ月後くらいに行います。 スピーカー募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1416363547,"dir":"post/2014/","id":"2a8412aa50d07330f1298f0243fa79d3","lang":"ja","lastmod":1416363547,"permalink":"https://blog.johtani.info/blog/2014/11/19/hold-on-7th-elasticsearch-jp/","publishdate":"2014-11-19T11:19:07+09:00","summary":"第7回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第7回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch-1.4.0 and 1.3.5 released\n本日、Lucene 4.10.2をベースにしたElasticsearch 1.4.0と、バグフィックスリリースである、Elasticsearch 1.3.5をリリースしました。 ダウンロードおよび変更リストはそれぞれ次のリンクからアクセスできます。\n最新ステーブルリリース：Elasticsearch 1.4.0 1.3.x系バグフィックス：Elasticsearch 1.3.5 1.3ブランチに関する過去のリリースについてのブログは次のとおりです：1.3.4, 1.3.3, 1.3.2, 1.3.1, 1.3.0.\nBeta1リリースでも言及しましたが、1.4.0の主なテーマは*resiliency(復元性、弾力性)*です。 Elasticsearchをより安定し信頼性のあるものにし、メモリ管理を改善し、ディスカバリアルゴリズムを改善し、破損したデータの検知を改善しました。 Beta1リリースからのハイライトも含んでいます。\nDoc values (インデックス時にディスクに保存されるfielddata)がヒープ利用率を激減 Request circuit breaker: メモリを消費しすぎる検索リクエストの中断 Bloom filterのデフォルト無効、高速なインデキシングのためにもはや必要とされないため。 ノードディスカバリ、シャードリカバリの数多くのバグフィックス及び改善 データ破損の早期検知のためのチェックサムのさらなる利用 GroovyをMVELの代わりにデフォルトスクリプト言語に CORSをデフォルト無効に。XSS攻撃防止の為。 クエリキャッシュ、変更されていないシャードからすぐにaggregation結果を返す 新しいAggregation：filter(ドキュメント)、children(ドキュメント)、scripted_metric(ドキュメント) 新しいGET /indexAPI。インデックスのsettings、mappings、warmers、aliasesを1回のリクエストで返却(ドキュメント) 自動付与ドキュメントIDのためのFlake ID。プライマリキーの探索パフォーマンスの改善。 ドキュメントに変更のない更新によるドキュメントの再インデックスの防止 function_scoreクエリの関数でweightパラメータによる個別の改善を可能に。(ドキュメント) 詳細については1.4.0.Beta1のブログ(英語)(日本語訳)をご覧ください。\nBeta1以降の1.4.0の変更の全てについては、1.4.0 release notesでご覧いただけます。 以下では、2つの主な変更について紹介します。\nHTTP Pipelining HTTP pipeliningは複数のリクエストを1回のコネクションで、関連するレスポンスを待つことなく送信することができます。 そして、レスポンスは、受け取ったリクエストと同じ順序で返却されます。 HTTP/1.1の仕様で、pipeliningのサポートが必要です。ElasticsearchはHTTP/1.1であるとしてきましたが、pipeliningはサポートしていませんでした。この問題は.NETユーザで問題を引き起こしました。\n現在、HTTP pipeliningは公式にサポート済みで、デフォルトで利用できます。#8299をご覧ください。\nUpgrade API Luceneのすべてのリリースではバグフィックスや最適化が提供されます。しかし、多くのユーザは古いバージョンのLuceneで作成されたインデックスを持っており、より最新の改善による利点を利用できないことがあります。 新しいupgradeAPIは、あなたのインデックスすべてもしくは一部を最新のLuceneフォーマットに透過的にアップグレードできます。\nGET _upgradeリクエストは、インデックスのアップグレードが必要かどうかを提示し、アップグレードに必要なセグメントのサイズをリポートすることによって、どのくらいの時間が必要かの目安を提供します。 POST _upgradeコマンドはバックグラウンドでインデックスを最新のLuceneフォーマットに書き換えます。\nより詳しい情報はupgradeAPIドキュメントをご覧ください。\n試してみてください。 Beta1リリースを利用し、経験・体験を報告していただいたベータテスターの方々に感謝します。 1.4.0がこれまでの最高のリリースになると確信しています。 ぜひ、Elasticsearch 1.4.0をダウンロードして、試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1415205033,"dir":"post/2014/","id":"d266a2023c67b7a20c3bd01055b223bc","lang":"ja","lastmod":1415205033,"permalink":"https://blog.johtani.info/blog/2014/11/06/elasticsearch-1-4-0-ja/","publishdate":"2014-11-06T01:30:33+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch-1.4.0 and 1.3.5 released 本日、Lucene 4.10.2をベースにし","tags":["elasticsearch"],"title":"Elasticsearch 1.4.0および1.3.5リリース（日本語訳）"},{"contents":"久しぶりに翻訳ではないブログを。書こうと思いながらかけてなかったので。。。\n今回はvalidate APIの紹介です。\n背景 ElasticsearchのクエリはQuery DSLというJSONで クエリを定義できるものを提供しています。 これは、様々なクエリ、フィルタを定義するために必要です。\n自分の望んでいる条件を記述するために、JSONのネストと格闘することも必要となります。。。 また、クエリ、フィルタには様々なパラメータが用意されています。 これらのパラメータをすべて覚えるのは無理でしょうし、タイプミスなどもありますよね。 タイプミスやカッコのミスマッチなどで格闘して1時間が経過してしまったなどもあると思います。\nそんな時に便利なAPIとして用意されているのがvalidate APIです。\n利用方法 APIが用意されています。\nhttp://ホスト名:ポート番号/インデックス名/タイプ名/_validate/query インデックス名やタイプ名は省略可能ですが、マッピングが異なると思うので、タイプ名まで指定するほうが良いと思います。 上記のAPIに対してクエリを送信するだけです。\nクエリの確認 たとえば、こちらのGistにあるようなマッピングのインデックスに対して 検索クエリを組み立てていて、エラーが出るとします。 ※このクエリはmatch_allのところをmatch_alと、lが1文字足りないクエリになっています。\n検索クエリのリクエスト（エラーあり）\nGET pref_aggs/_search { \u0026#34;query\u0026#34;: { \u0026#34;match_al\u0026#34;: {} } } 実行結果のレスポンス\n{ \u0026#34;error\u0026#34;: \u0026#34;SearchPhaseExecutionException[Failed to execute phase [query], all shards failed; shardFailures {[rwkb01chTZq2V7FD0Tlwrw][pref_aggs][0]: SearchParseException[[pref_aggs][0]: from[-1],size[-1]: Parse Failure [Failed to parse source [{\\n \\\u0026#34;query\\\u0026#34;: {\\n \\\u0026#34;match_al\\\u0026#34;: { }\\n }\\n}\\n]]]; nested: QueryParsingException[[pref_aggs] No query registered for [match_al]]; }{[rwkb01chTZq2V7FD0Tlwrw][pref_aggs][1]: SearchParseException[[pref_aggs][1]: from[-1],size[-1]: Parse Failure [Failed to parse source [{\\n \\\u0026#34;query\\\u0026#34;: {\\n \\\u0026#34;match_al\\\u0026#34;: { }\\n }\\n}\\n]]]; nested: QueryParsingException[[pref_aggs] No query registered for [match_al]]; }]\u0026#34;, \u0026#34;status\u0026#34;: 400 } とこんなかんじで、エラーが帰っては来るのですが、非常に読みづらいです。\nそこで、validate APIを利用します。 リクエスト先を/_searchから/_validate/queryに変更します。\nvalidate API\nGET pref_aggs/_validate/query { \u0026#34;query\u0026#34;: { \u0026#34;match_al\u0026#34;: {} } } validate APIのレスポンス\n{ \u0026#34;valid\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 } } すると、非常にシンプルな結果が返ってきます。 \u0026quot;valid\u0026quot;: falseとなっているため、クエリに問題があることがわかります。\nエラーの詳細 問題がある事自体はわかりましたが、エラーの内容も知りたいですよね？ その場合は、explainというパラメータを追加します。 （正しくはexplain=trueを追加しますが、=trueを省略可能です。）\nvalidate API(explainあり、クエリ自体は省略)\nGET pref_aggs/_validate/query?explain {...} validate APIのレスポンス\n{ \u0026#34;valid\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;explanations\u0026#34;: [ { \u0026#34;index\u0026#34;: \u0026#34;pref_aggs\u0026#34;, \u0026#34;valid\u0026#34;: false, \u0026#34;error\u0026#34;: \u0026#34;org.elasticsearch.index.query.QueryParsingException: [pref_aggs] No query registered for [match_al]\u0026#34; } ] } explanationsという項目が追加されました。 ここにerrorという項目として、エラーの詳細が返ってきます。_searchの時よりも見やすいですね。 今回のエラーは、match_allが正しいクエリですの、match_alというクエリは登録されていないというエラーでした。 では、クエリを修正して実行しましょう。\nvalidate API(エラー無し)\nGET pref_aggs/_validate/query?explain { \u0026#34;query\u0026#34;: { \u0026#34;match_all\u0026#34;: {} } } validate APIのレスポンス\n{ \u0026#34;valid\u0026#34;: true, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;explanations\u0026#34;: [ { \u0026#34;index\u0026#34;: \u0026#34;pref_aggs\u0026#34;, \u0026#34;valid\u0026#34;: true, \u0026#34;explanation\u0026#34;: \u0026#34;ConstantScore(*:*)\u0026#34; } ] } 今度はクエリに問題はありません。\u0026quot;valid\u0026quot;: trueです。 そして、explanationsの項目には、errorの代わりにexplanationという項目が返ってきました。 これが、実際にElasticsearch内部で実行されるクエリになります。\n実際のクエリに利用される単語の確認 この機能はこの他に、クエリの解析にも利用できます。 思ったとおりに検索にヒットしない場合があって、困ったことはないですか？ フィールドに指定されたアナライザによっては、単語を変形したりするものが存在します。\nサンプルマッピング\nPUT /validate_sample { \u0026#34;mappings\u0026#34;: { \u0026#34;several_analyzer\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;title\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;}, \u0026#34;body_ja\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34;}, \u0026#34;body_en\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;english\u0026#34;} } } } } 例えば、このようにkuromoji、english、デフォルト(standard)アナライザを利用したマッピングがあるとします。 このフィールドに対してpowerfulという単語で検索したとします。\nvalidate API\nGET /validate_sample/_validate/query?explain { \u0026#34;query\u0026#34;: { \u0026#34;multi_match\u0026#34;: { \u0026#34;fields\u0026#34;: [\u0026#34;body_en\u0026#34;,\u0026#34;body_ja\u0026#34;,\u0026#34;title\u0026#34;], \u0026#34;query\u0026#34;: \u0026#34;powerful\u0026#34; } } } この場合、レスポンスは次のとおりです。\nvalidate APIのレスポンス\n{ \u0026#34;valid\u0026#34;: true, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;explanations\u0026#34;: [ { \u0026#34;index\u0026#34;: \u0026#34;validate_sample\u0026#34;, \u0026#34;valid\u0026#34;: true, \u0026#34;explanation\u0026#34;: \u0026#34;(title:powerful | body_en:power | body_ja:powerful)\u0026#34; } ] } title、body_jaについては入力された単語がそのままクエリとして利用されています。 body_enについては、powerという単語に変換されて実行されています。 これは、englishアナライザがステミングを行った結果がクエリとして利用されるという意味です。 また、powerfulを秋葉原といった日本語に変更して実行すると次のようになります。 日本語はstandardアナライザなどでは、1文字ずつ区切られてしまうことがわかります。\nvalidate APIのレスポンス\n{ \u0026#34;valid\u0026#34;: true, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;explanations\u0026#34;: [ { \u0026#34;index\u0026#34;: \u0026#34;validate_sample\u0026#34;, \u0026#34;valid\u0026#34;: true, \u0026#34;explanation\u0026#34;: \u0026#34;((title:秋 title:葉 title:原) | (body_en:秋 body_en:葉 body_en:原) | ((body_ja:秋葉 body_ja:秋葉原) body_ja:原))\u0026#34; } ] } このように、クエリの単語がどのような単語に変換されてクエリに利用されているかなども知ることが可能です。\nまた、クエリを組み立てて、ヒットするはずが、0件となってしまうという場合にも、どのようなクエリが組み立てられているかを確認するという点で、 validate APIが役立ちます。 検索がヒットするが、望んだクエリになっていないのでは？という場合は_search APIのexplainパラメータを 利用すれば、クエリの構成がわかるのですが、検索結果が0件の場合はクエリの構成は表示されません。\n解決できない問題は？ 便利なvalidate APIですが、以下の問題に対しては残念ながら確認できません。\nquery以外の項目のvalidate不可 たとえば、_search APIのsizeなどの項目についてはチェックできないです。 存在しないフィールドの指定 上記validate_sampleのマッピングの例でクエリにbody_engという存在しないフィールドを指定してもエラーとはなりません。 まとめ 書いたクエリがうまく動かない、JSONのタグがおかしいといった場合は、 まずはこのvalidate APIで確認してみるのがオススメです。\n","date":1414402951,"dir":"post/2014/","id":"bc2709406a9bb19e8d83a78f81e36244","lang":"ja","lastmod":1414402951,"permalink":"https://blog.johtani.info/blog/2014/10/27/how-to-use-validate-api/","publishdate":"2014-10-27T18:42:31+09:00","summary":"久しぶりに翻訳ではないブログを。書こうと思いながらかけてなかったので。。。 今回はvalidate APIの紹介です。 背景 Elasticsear","tags":["elasticsearch"],"title":"validate APIの利用"},{"contents":"Elasticsearch 1.4.0.Beta1がリリースされました。\n個人でelasticsearch-extended-analyzeというプラグインを開発してます。 こちらも1.4.0.Beta1に対応するべく作業をしてて、少し戸惑ったことがあったので、メモをば。\nここ最近はプラグインのバージョン番号をElasticsearchのバージョン番号と同じものを利用していました。 （プラグインの機能追加をサボってる？？） その時に、1.4.0.Beta1という番号を指定したのですが、意味不明なエラーに悩まされてしまいまして。\nプラグインのリリースでは、以下のコマンドを実行します。\n$ mvn release:prepare $ mvn release:perform 最初のコマンド（prepare）で、パッケージングを実施し、Githubにリリースタグを打ったバージョンがpushされます。 次のコマンド（perform）で、パッケージングされたzipファイルがsonatypeのサイトに公開するためにアップロードされます。\n1.4.0.Beta1というバージョン文字列を利用した場合、prepareは問題なく実行できたのですが、 performで以下の様なエラーが返ってきました。\nReturn code is: 401, ReasonPhrase: Unauthorized. バージョン番号が1.3.0では特に問題はなかったのですが、、、 結局、バージョン番号を1.4.0-beta1に変更すると問題なくリリースが完了しました。\nmike_neckさんと話をしていて、Semantic Versioningに関係しているのかなぁという話にはなったのですが、 詳しく調べていません。。。\nそのうち調べようかなぁ。。。。\n","date":1413354368,"dir":"post/2014/","id":"998eda745d07fd8608f251138384a0b9","lang":"ja","lastmod":1413354368,"permalink":"https://blog.johtani.info/blog/2014/10/15/versioning-of-sonatype/","publishdate":"2014-10-15T15:26:08+09:00","summary":"Elasticsearch 1.4.0.Beta1がリリースされました。 個人でelasticsearch-extended-analyzeというプラグインを開発してま","tags":["Elasticsearch","plugin","sonatype"],"title":"Sonatypeのバージョン番号で困ったので"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch 1.4.0.beta1 released\n本日、Lucene 4.10.1をベースにした、Elasticsearch 1.4.0.Beta1をリリースしました。 Elasticsearch 1.4.0.Beta1からダウンロードできます。 また、すべての変更点に関してもこちらをご覧ください。\n1.4.0のテーマは*resiliency(復元性、弾力性)*です。 resiliencyとはElasticsearchをより安定し信頼性のあるものにすることを意味します。 すべての機能が正常に機能している場合は信頼することは簡単です。 予想外のことが発生した時に難しくなります：ノードでout of memoryの発生、スローGCや重いI/O、ネットワーク障害、不安定なデータの送信によるノードのパフォーマンス低下など。\n本ベータリリースは、resiliencyの主な3つの改善を含んでいます。\nメモリ使用量の低下によるノードの安定性向上 discoveryアルゴリズムの改善によるクラスタの安定性向上 チェックサムの導入による破損したデータの検知 分散システムは複雑です。 決して想像できないような状況をシミュレーションするために、ランダムなシナリオを作成する広範囲なテストスイートを持っています。 しかし、無数のエッジケース(特殊なケース)があることも認識しています。 1.4.0.Beta1はこれまで私たちが行ってきた改善のすべてを含んでいます。 これらの変更を実際にテストしていただき、何か問題があった場合は私たちに教えてください。\nメモリ管理 ヒープ空間は限られたリソースです。 上限を32GBとし、利用可能なRAMの50%をヒープの上限にすることを推奨します。 この上限を超えた場合、JVMは圧縮したポインタを使用することができず、GCが非常に遅くなります。 ノードの不安定性の主な原因は遅いGCです。それは、次のようなことから発生します。\nメモリプレッシャー スワップ(参照：memory settings) 非常に大きなヒープ 本リリースは、メモリ管理の改善し、（結果として）ノードの安定性を改善するいくつかの変更を含んでいます。\ndoc values メモリの利用の最も大きなものの1つはfielddataです aggregation、ソート、スクリプトがフィールドの値に素早くアクセスするために、フィールドの値をメモリにロードして保持します。 ヒープは貴重なため、1ビットも無駄にしないためにメモリ内のデータは高度な圧縮と最適化を行っています。 これは、ヒープスペース以上のデータをもつまでは、非常によく動作します。 これは、多くのノードを追加することによって常に解決できる問題です。 しかし、CPUやI/Oが限界に達してしまうずっと前に、ヒープ空間の容量に到達します。\n最近のリリースは、doc valuesによるサポートがあります。 基本的に、doc valuesはin-memory fielddataと同じ機能を提供します。 doc valuesの提供する利点は、それらが、非常に少量のヒープ空間しか使用しない点です。 doc valuesはメモリからではなく、ディスクから読み込まれます。 ディスクアクセスは遅いですが、doc valuesはカーネルのファイルシステムキャッシュの利点を得られます。 ファイルシステムキャッシュはJVMヒープとはことなり、32GBの制限による束縛がありません。 ヒープからファイルシステムキャッシュにfielddataを移行することによって、より小さなヒープを使うことができます。これは、GCがより早くなり、ノードが更に安定することを意味します。\n本リリースより前は、doc valuesはin-memory fielddataよりもかなり遅かったです。 本リリースに含まれる変更は、パフォーマンスをかなり向上させ、in-memory fielddataとほぼ同じくらいの速度になっています。\nin-memory fielddataの代わりにdoc valuesを利用するために必要なことは、次のように新しいフィールドをマッピングすることです。\nPUT /my_index { \u0026#34;mappings\u0026#34;: { \u0026#34;my_type\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;timestamp\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;date\u0026#34;, \u0026#34;doc_values\u0026#34;: true } } } } } このマッピングで、このフィールドに対するfielddataの利用は、メモリにフィールドをロードする代わりに、自動的にディスクからdoc valuesを利用します。 *注意：*現時点で、doc valuesはanalyzedなstringフィールドはサポートしていません。\nrequest circuit breaker fielddata circuit breakerはfielddataによって利用されるメモリの上限を制限するために追加され、OOMEの最も大きな原因の1つを防ぎました。 そして、リクエストレベルのcircuit-breakerを提供するために、コンセプトを拡張しました。 これは、単一のリクエストによって使用されるメモリの上限を制限します。\nbloom filters Bloom filters はインデキシング(前のバージョンのドキュメントが存在するかどうかのチェックのため)や、 IDによるドキュメントの検索(ドキュメントを含むセグメントがどれかを決定するため)に関する重要な性能最適化を提供しました。 しかし、もちろんそれらはコスト（メモリ）を必要とします。 現在の改善は、bloom filterの必要性を取り除きました。 現在では、Elasticsearchはまだ、インデックス時にそれらを構築します(実世界の経験がテストシナリオにそぐわない場合に備えて)。 しかし、デフォルトではメモリにはロードされません。 すべてが予定通りに運べば、将来のバージョンで完全にこれらは除去します。\nクラスタの安定性 クラスタの安定性向上のために私たちができる最も大きなことは、ノードの安定性の向上です。 もし、ノードが安定しておりタイミングよく反応すれば、クラスタが不安定になる可能性が大いに減少します。 私たちは不完全な世界に住んでいます。- 物事は予想外にうまく行きません。クラスタはデータを失うことなくこのような状況から回復できる必要があります。\n私たちは、improve_zenブランチ上で、Elasticsearchの障害からの復旧するための能力の向上に数ヶ月費やしてきました。 まず、複雑なネットワークレベルの障害を繰り返すためのテストを追加しました。 次に、各テストのための修正を追加しました。 そこには、より多くの行うことが存在します。しかし、私たちは、issue #2488(\u0026ldquo;分割が交差している場合、minimum_master_nodesはsplit-brainを防げない\u0026rdquo;)に含まれる、ユーザが経験してきた大部分の問題を私たちは解決しました。\n私たちはクラスタのresiliencyを非常に真剣に取り組んでいます。 私たちは、Elasticsearchが何ができるか、その上で何が弱点であるかを理解してほしいと思っています。 これを考慮して、私たちはResiliency Status Documentを作成しました。 このドキュメントは、私たち(または私たちユーザ)が遭遇したresiliencyの問題の、何が修正済みで、何が修正されないまま残っているかを記録します。 このドキュメントを慎重に読み、あなたのデータを保護するために適切な方法を選択してください。\nデータ破損の検知 ネットワークをまたいだシャードリカバリのチェックサムは、圧縮ライブラリのバグを発見する助けとなりました。 それは、バージョン1.3.2で修正済みです。 それ以来、私たちはElasticsearchのいたるところにチェックサムとチェックサムの確認を追加しました。\nマージ中に、あるセグメント内すべてのチェックサムの確認(#7360) インデックス再オープン時に、あるセグメント内の最も小さなファイルの完全な確認と、より大きなファイルの軽量な打ち切りチェック(LUCENE-5842) トランザクションログからイベントを再生するとき、各イベントはチェックサムを確認される(#6554) シャードのリカバリ中もしくは、スナップショットからのリストア中にElasticsearchはローカルファイルとリモートのコピーが同一であるか確認する必要がある。ファイルの長さとチェックサムのみを使うのは不十分であることが確認された。このため、現在はセグメントのすべてのファイルの同一性を確認(#7159) その他のハイライト Elasticsearch 1.4.0.Beta1のchangelogに本リリースの多くの機能、改善、バグフィックスについて読むことができます。 ここでは、特筆すべきいくつかの変更について述べます。\ngroovyによるmvelの置き換え Groovyは現在、デフォルトのscripting languageです。 以前のデフォルトはMVELで、古くなってきており、サンドボックス内で実行できないという事実は、セキュリティ問題でした。 Groovyはサンドボックスであり(それは、ボックスの外へは許可が必要)、メンテナンスされており、速いです！ 詳しくはscriptingについてのブログ記事をご覧ください。\nデフォルトでcorsはオフ Elasticsearchのデフォルト設定はクロスサイトスクリプティングに対して脆弱でした。 私たちはデフォルトでCORSをオフにすることで修正しました。 Elasticsearchにインストールされたサイトプラグインはこれまで同様に機能します。 しかし、CORSを再度オンにすることがない限り、外部のウェブサイトがリモートのクラスタにアクセスすることはできません。 ウェブサイトがあなたのクラスタにアクセス可能に制御できるように、さらにCORS settingsを追加しました。 詳しくはsecurity pageをご覧ください。\nクエリキャッシュ 新しい試験的なshardレベルのクエリキャッシュは、静的なインデックスのアグリゲーションをほとんど即座に反応できます。 ウエブサイトのアクセスの日毎のページビュー数を見るダッシュボードを持っていると想像してみてください。 これらの数値は古いインデックスでは変更がありません。しかし、アグリゲーションはダッシュボードのリフレッシュのたびに再計算されます。 新しいクエリキャッシュを利用すると、シャードのデータが変更されない限り、アグリゲーションの結果はキャッシュから直接返却されます。 キャッシュから古い結果を決して取得することはありません。それは、常に、キャッシュされていないリクエストと同じ結果を返します。\n新しいaggregations 3つの新しいaggregationsがあります。\nfilters\nこれはfilter aggregationの拡張です。複数のバケットを定義し、バケット毎に異なるフィルタを利用できます。 children\nnestedアグリゲーションの親子版。children aggは親のドキュメントに属する子のドキュメントを集計できる scripted_metric\nこのaggregationは、データによって計算されたメトリックを完全にコントロールできます。これは、初期化フェーズ、ドキュメント収集フェーズ、shardレベル結合フェーズ、global reduceフェーズを提供します。 get /index api 以前、ある1つのインデックスのaliases、mappings、settings、warmersを取得出来ました。しかし、それらを個別にです。 get-index API はこれらのすべてもしくは一部を、複数もしくはひとつのインデックスに対して一緒に取得できます。 これは、既存のインデックスと同一もしくはほぼ同一であるインデックスを作成したいときに非常に役に立ちます。\n登録と更新 ドキュメントの登録と更新にいくつかの改善があります。\n現在、ドキュメントIDの自動生成のためにFlake IDを使用しています。これは、プライマリキー探索時に素晴らしい性能向上を提供します。 detect_noopにtrueを設定すると、ドキュメントに変更を与えない更新が軽量になります。この設定を有効にすると、_sourceフィールドのコンテンツを変更する更新リクエストだけ、ドキュメントの新しいバージョンを書き込みます。 更新はスクリプトから完全に操作できます。以前は、スクリプトはドキュメントがすでに存在しているときだけ実行可能で、それ以外は、upsertドキュメントで登録しました。script_upsertパラメータでスクリプトから直接ドキュメントの作成が操作できます。 function score すでに非常に便利なfunction_scoreクエリが、新しくweightパラメータをサポートします。 これは、それぞれの指定された関数の影響をチューニングするのに使われます。 これは、人気度よりも更新日時により重みをかけたり、地理情報よりも価格により重みをかけるといったことを可能にします。 また、random_score機能はセグメントマージによる影響を受けません。これにより、より一貫した順序が提供されます。\n試してみてください。 ぜひ、Elasticsearch 1.4.0.Beta1をダウンロードして、試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1412244840,"dir":"post/2014/","id":"853cac0f2d1f90b7c986e7d1dcdbbfde","lang":"ja","lastmod":1412244840,"permalink":"https://blog.johtani.info/blog/2014/10/02/elasticsearch-1-4-0-beta-released-ja/","publishdate":"2014-10-02T19:14:00+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.0.beta1 released 本日、Lucene 4.10.1をベースにした、Elast","tags":["Elasticsearch"],"title":"elasticsearch 1.4.0.Beta1のリリース"},{"contents":"第6回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。 今回は、スタッフが私を含めて3，4名ということで、ドタバタしてしまってスミマセンでした。\n今回はキャンセルが多く、最終的には90人弱の参加となりましたが、今回も多数の方にお集まりいただきありがとうございました。 同じ日に他の勉強会もあった影響でしょうか？\n「Aggregationあれこれ」Elasticsearch Inc. Jun Ohtani @johtani スライド：Aggregationあれこれ\nちょっと長かったですかね。。。 Aggregationの概要、内部動作、種類などを簡単に紹介してみました。 個々のAggregationもいろいろなオプションなどがあるので、色々と試してみていただければと思います。 アニメーション入りのスライドになってましたが、UpしてあるスライドはPDF版になります。 「秒間3万の広告配信ログをElasticSearchでリアルタイム集計してきた戦いの記録」 株式会社サイバーエージェント　山田直行さん　@satully スライド：秒間3万の広告配信ログをElasticSearchでリアルタイム集計してきた戦いの記録\nディスプレイ広告配信DSPの話 システム: Fluentd、S3、Elasticsearch、Redis、MySQL 7月に秒間3万〜4万のリクエストをさばいている。 なぜElasticsearchを選んだのか、今の構成など 実際に苦労された点なども交えて話していただき面白かったです。 7月時点のお話ということで、現時点ではまた違う構成っぽかったので、また話を聞きたいなぁ。 「Elasticsearch 日本語スキーマレス環境構築と、ついでに多言語対応」ナレッジワークス株式会社　木戸国彦さん @9215 スライド：Elasticsearch 日本語スキーマレス環境構築と、ついでに多言語対応\nDynamic TemplateやIndex Templateの説明 日本語や多言語化するときのMappingのサンプルになりそうなものがゴロゴロ紹介されてました。 いくつかの例があって、後で見直したいなと。 途中で出てきた、fielddata（インデックスに入っている単語区切りのデータ）を見るのに使ってたクエリはfield data fieldsだったかな。 「elasticsearchソースコードを読みはじめてみた」@furandon_pig さん スライド：elasticsearchソースコードを読みはじめてみた\nリクエストを受けて検索してる部分から読むといいって言われたらしいが、起動スクリプトから読み始めてみた。 時間かかりそうｗ ただ、人がどんな感じでソースを読んだり理解してるかがわかりやすかったので面白かったです。 定期的に続きを聞いてみたいです。 LT 「reroute APIを使用してシャード配置を制御する」 株式会社富士通ソフトウェアテクノロジーズ 滝田聖己さん @pisatoshi スライド：reroute APIを使用してシャード配置を制御する\nシャードの再配置が自動で行われるので、それをオフにしないと、せっかく移動しても無駄になることがというあるあるネタ Bonsaiロゴを作成するLT 実際にいくら掛かったのかが知りたかった。 「検索のダウンタイム0でバックアップからIndexをリストアする方法」株式会社ドワンゴモバイル 西田和史さん スライド：検索のダウンタイム0でバックアップからIndexをリストアする方法\n擬似無停止のやりかた。 aliasを活用して、かつ、Restoreで再構築するという方法。 aliasまで一緒にリストアされるので注意が必要っていうのは、実際にやってみたからわかることという感じですね。 その他、感想などのブログ 適当に見つけたブログを列挙してあります。これもあるよ！などあれば、教えてください。\n第6回elasticsearch勉強会に行ってきましたのでそのメモ elasticsearch 勉強会 第6回 まとめ 今回も、ためになる話がいっぱい聞けたかなと。 個人的な印象としては、いつものメンバーよりも新しい方が多かった印象です。 また、ほとんどの方が、Elasticsearchをご存知でした。 そこそこ知名度は上がってきているようで嬉しい限りです。（東京以外での知名度なども知りたいかなと。）\nあと、懇親会の部屋の案内が遅くなってしまってスミマセンでした。 さすがにスタッフ3名はきつかったです。。。\n19時半開始にしてみましたが、懇親会の時間がやはり短めになってしまうなぁという印象でした。\n次回ももちろん2ヶ月後くらいに行います。 スピーカー募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1410927720,"dir":"post/2014/","id":"4616fbea6a6dbc1074bc3f1016bbc73b","lang":"ja","lastmod":1410927720,"permalink":"https://blog.johtani.info/blog/2014/09/17/hold-on-6th-elasticsearch-jp/","publishdate":"2014-09-17T13:22:00+09:00","summary":"第6回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第6回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"先日2014年9月9日(火)に『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』　出版記念！執筆者が語る大講演会！で、 「elasticsearch.もうちょっと入門」というタイトルで発表してきました。 会場のGMOのみなさま、Treasure Data、技術評論社のみなさま、どうもありがとうございました。\n書籍に興味のある方は、右のリンクから購入してもらえるとうれしいです。Kindle版も用意されています。\n提供のTDの方に目をつぶってもらいながらLogstashについての発表となってしまいましたが、楽しんでいただけたかなぁと。 書籍では主にKibana3をメインにしたElasticsearchの使い方だったので、それ以外の機能ということで、Aggregationについて説明してみました。\nそのあとは、おそらく初めてですが、パネルディスカッションにも参加しました。 @naoya_itoさんをモデレーターに、rebuild.fm風に進めていただき、話しやすかったかなと。 （少なくとも私は楽しめました！） ただ、私だけバックグラウンドが少し異なることもあり、話をうまく繋げられなかったかもと気にしていたりもしますが。。。\nパネルディスカッションでもありましたが、エンジニアが「趣味」で入れて試してみるのにはもってこいのツール群だと思います。 ちょっと入れてみて、可視化をしてみるといろいろと発見があると思います。 何かを発見するためにもまず試してみるのが何事も重要かなと最近思ってるのもあるので、気軽に試してみてもらえればと。\n不明点などあれば、著者陣に気軽に聞いていただけると良いかと思います（いいですよね、みなさんｗ）。 Fluentd（もちろん、Logstashも）、Elasticsearch、Kibanaを利用して、データについて試行錯誤してもらって、 システムやビジネスに必要なものを探索して見てください。\n参考 他の方々のブログをメモとして。\nサービス改善とログデータ解析について発表してきました Kibanaではじめるダッシュボードについて発表してきました #gihyo_efk Fluentdのお勧めシステム構成パターンについて発表しました ","date":1410841260,"dir":"post/2014/","id":"f15702ae9e55bad42182cf18724d1863","lang":"ja","lastmod":1410841260,"permalink":"https://blog.johtani.info/blog/2014/09/16/book-publication-event/","publishdate":"2014-09-16T13:21:00+09:00","summary":"先日2014年9月9日(火)に『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』 出版記念！執筆者が語る大講演会！で、 「elastics","tags":["勉強会","本"],"title":"elasticsearch.もうちょっと入門という話をしてきました #gihyo_efk"},{"contents":"Elasticsearchのインデキシングに関するパフォーマンス検討\n原文：performance considerations for elasticsearch indexing\nElasticsearchユーザは様々な楽しいユースケースを持っています。小さなログを追加することから、Webスケールの大きなドキュメントの集合をインデキシングするようなことまでです。また、インデキシングのスループットを最大化することが重要で一般的な目標となります。 「典型的な」アプリケーションに対して良いデフォルト値を設定するようにしていますが、次のちょっとした簡単なベストプラクティスによってインデキシングのパフォーマンスをすぐに改善することができます。それらについて記述します。\n第一に、制御できないならば、巨大なJavaヒープを使用しない：必要なサイズ（マシンの持つRAMの半分以下）のheapだけを設定しましょう。Elasticsearchの利用方法のために必要な全体量を設定します。これは、OSにIOキャッシュを制御するためのRAMを残すことを意味します。OSがjavaプロセスをスワップアウトしていないことも確認しましょう。\n最新バージョン（現時点では1.3.2）のElasticsearchにアップグレードしましょう：多数のインデキシングに関連する問題点が最新リリースで修正されています。\n詳細に入る前に警告：ここで述べるすべての情報は現時点での最新（1.3.2）の情報です。しかし、Elasticsearchの更新は日々行われています。この情報をあなたが見た時点では最新ではなく、正確ではなくなっているかもしれません。自信がない場合はユーザメーリングリストで質問してください。\nクラスタのインデキシングスループットをチューニングする場合、Marvelは非常に有用なツールです：ここで述べている各設定を継続的に試し、変更の影響がクラスタの挙動をどのように変更されたかを簡単に可視化することが可能です。\nクライアントサイド bulk APIを常に使いましょう。1リクエストで複数のドキュメントをインデキシングでき、各バルクリクエストで送るのに良いドキュメント数を試しましょう。最適なサイズは多くの要因に依存しますが、最適サイズからずれるならば多すぎるよりも少なすぎる方が良いでしょう。クライアントサイドのスレッドで並列にbulkリクエストを使うか、個別の非同期リクエストを使ってください。\nインデキシングが遅いと結論付ける前に、クラスタのハードウェアの性能を引き出せているかを確認して下さい：すべてのノードでCPUやIOが溢れていないかを確認するためにiostatやtop、psといったツールを使いましょう。もし、溢れていなければ、より多くの並列なリクエストが必要です。しかし、javaクライアントからのEsRejectedExecutionExceptionや、RESTリクエストのHTTPレスポンスとしてTOO_MANY_REQUESTS (429)が返ってきた場合は並列リクエストを多く送りすぎています。もしMarvelを利用しているなら、Node Statistics DashboardのTHREAD POOLS - BULKにリジェクトされた数が表示されます。bulkスレッドプールサイズ（デフォルト値はコア数）を増やすのは得策ではありません。インデキシングスループットを減少させるでしょう。クライアントサイドの並列度を下げるか、ノードを増やすのが良い選択です。\nここでは、1シャードに対してインデキシングスループットを最大化する設定に注目します。1つのLuceneインデックスのドキュメントの容量を測定するために、単一ノード（単一シャード、レプリカなし）で最初にテストをして最適化し、クラスタ全体にスケールする前にチューニングを繰り返します。これはまた、インデキシングスループットの要件を見つけるために、クラスタ全体にどのくらいのノードが必要かをラフに見積もるためのベースラインを与えてくれます。\n単一シャードが十分機能したら、Elasticsearchのスケーラビリティの最大の利点や、クラスタでの複数ノードによるレプリカ数やシャード数の増加の利点が得られます。\n結論を導き出す前に、ある程度の時間（60分）くらいクラスタ全体の性能を計測しましょう。このテストは、巨大なマージ、GCサイクル、シャードの移動、OSのIOキャッシュ、予期しないスワップの可能性などのイベントのライフサイクルをカバーできます。\nストレージデバイス 当然ながらインデックスを保存するストレージデバイスはインデキシングの性能に多大な影響を及ぼします：\nSSDを利用する：これらは最も速いHDDよりも速いです。ランダムアクセスのための消費電力が低いだけでなく、シーケンシャルIOアクセスも高いです。また、同時に発生するインデキシング、マージや検索のための並列的なIOも高速です。 インデックスをリモートマウントされたファイルシステム（例：NFSやSMB/CIFS）上に配置しない：代わりにローカルストレージを使う 仮想化されたストレージ（AmazonのElastic Block Storageなど）に注意：仮想化されたストレージはElasticsearchで十分に動作します。また、十分早く簡単に用意できることから魅力的です。しかし、残念なことに、ローカルストレージと比較すると本質的に遅いです。最近の非公式なテストでは、最高の性能を持つプロビジョニングされたIOPSのSSDオプションのEBSでさえ、ローカルインスタンスにあるSSDよりも遅いです。ローカルインスタンスにあるSSDは物理マシン上のすべての仮想マシンから共有されてアクセスされます。もし他の仮想マシンが急にIOが集中した場合に不可解なスローダウンとなることがあることを覚えておいてください。 複数のSSDを複数のpath.dataディレクトリにインデックスをストライピング（RAID0のように）：2つは同様で、ファイルブロックレベルでストライピングする代わりに、個別にインデックスファイルレベルでElasticsearchの\u0026quot;stripes\u0026quot;となります。これらのアプローチは、いづれかのSSDの故障によりインデックスが壊れるという、1シャードが故障する(IO性能を高速化することとトレードオフ)というリスクを増加させることに注意してください。これは、一般的に行うのに良いトレードオフです：単一シャードで最大のパフォーマンスを最適化し、異なるノード間でレプリカを追加すると、ノードの故障への冗長化ができます。また、snapshotやrestoreを使って保険のためにインデックスのバックアップを取ることもできます。 セグメントとマージ 新しくインデキシングされたドキュメントは最初にLuceneのIndexWriterによってRAMに保存されます。RAMバッファがいっぱいになった時もしくは、Elasticsearchがflushもしくはrefreshを実行した時など定期的にこれらのドキュメントはディスクに新しいセグメントとして書き込まれます。最後に、セグメントが多くなった時に、Merge PolicyとSuchedulerによってそれらがマージされます。このプロセスは連続的に生じます：マージされたセグメントはより大きなセグメントとなり、小さなマージが幾つか実行され、また、大きなセグメントにマージされます。これらがどのように動作するかをわかりやすく可視化したブログはこちらです。\nマージ、特に大きなマージは非常に時間がかかります。これは、通常は問題ありません。そのようなマージはレアで全体のインデックスのコストと比べればささいなものです。しかし、マージすることがインデキシングについていけない場合、インデックスに非常に多くのセグメントがあるような深刻な問題を防ぐために、Elasticsearchはやってくるインデキシングリクエストを単一スレッド(1.2以降)に制限します。\nもし、INFOレベルのログメッセージにnow throttling indexingと表示されていたり、Marvelでのセグメント数が増加しているを見た場合、マージが遅れているとわかります。MarvelはIndex Statistics dashboardのMANAGEMENT EXTENDEDの部分にセグメント数をプロットしており、それは、非常にゆっくりと指数対数的に増加しており、大きなマージが終了したところがのこぎりの歯のような形で見て取れます。\nセグメント数 なぜマージが遅れるのでしょう？デフォルトでElasticsearchはすべてのマージの書き込みのバイト数をわずか20MB/secに制限しています。スピニングディスク（HDD）に対して、これはマージによって典型的なドライブのIOキャパシティを飽和させず、並列に検索を十分に実行させることを保証します。しかし、もし、インデキシング中に検索をしない場合や、検索性能がインデキシングのスループットよりも重要でない場合、インデックスの保存にSSDを使用している場合などは、index.store.throttle.typeにnoneを設定して、マージの速度制限を無効化するべきです（詳細はこちらをご覧ください）。なおバージョン1.2以前には期待以上のマージIO制限の発生といったバグが存在します。アップグレードを！\nもし、不幸にもスピニングディスク（それはSSDと同等の並列なIOを扱えません）をまだ使っている場合、index.merge.scheduler.max_thread_countに1を設定しなければなりません。そうでない場合は、（SSDを支持する）デフォルト値が多くのマージを同時に実行させるでしょう。\n活発に更新が行われているインデックスでoptimizeを実行しないでください。それは、非常にコストの高い操作(すべてのセグメントをマージ)です。しかし、もし、インデックスにドキュメントを追加が終わった直後はオプティマイズのタイミングとしては良いタイミングです。それは、検索時のリソースを減らすからです。例えば、時間ベースのインデックスを持っており、新しいインデックスに日々のログを追加している場合、過去の日付のインデックスをオプティマイズするのは良い考えです。特に、ノードが多くの日付のインデックスを持っている場合です。\n更にチューニングするための設定：\n実際に必要のないフィールドをオフにする。例えば_allフィールドをオフ。また、保持したいフィールドでは、indexedかstoredかを検討する。 もし、_sourceフィールドをオフにしたくなるかもしれないが、インデキシングコストは小さい(保存するだけで、インデキシングしない)、また、それは、将来の更新や、前のインデックスを再インデキシングするために非常に価値があり、それはディスク使用率の懸念事項がない限り、オフにする価値はあまりない。それは、ディスクが比較的安価であるので価値がない。 もし、インデックスされたドキュメントの検索までの遅延を許容できるなら、index.refresh_intervalを30sに増やすか、-1を設定して、オフにする。これは、巨大なセグメントをフラッシュし、マージのプレッシャーを減らすことができる。 Elasticsearch 1.3.2(稀に、フラッシュ時に過度のRAMを使用するという問題を修正した)にアップグレードすることで、index.translog.flush_threshold_sizeをデフォルト(200mb)から1gbに増加し、インデックスファイルのfsyncの頻度を減らす。 MarvelにIndex Statistics dashboardのMANAGEMENTにフラッシュの頻度がプロットされている。 インデックスバッファサイズ 巨大なインデックスを構築中はレプリカ数を0にし、あとから、レプリカを有効にする。レプリカが0ということは、データを失った(ステータスがred)時に冗長性がないので、ノードの故障に注意すること。もし、optimize(ドキュメントの追加をすることがないので)を計画するなら、インデキシングが終わったあとで、レプリカを作成する前に実行するのが良いでしょう。レプリカはオプティマイズされたセグメントをコピーするだけになります。詳細はインデックス設定更新を参照。\nもし、ノードがヘビーなインデキシングを行っているだけなら、アクティブなシャードのインデキシングバッファに多くてい512MBをindices.memory.index_buffer_sizeに与えてください。(超えてもインデキシングのパフォーマンスは一般的には改善されません。)Elasticsearchはその設定(Javaヒープのパーセンテージもしくはバイト数)を受けて、min_index_buffer_sizeとmax_index_buffer_sizeの値を前提にノードのアクティブシャードに均等に割り当てます；大きな値はLuceneが最初のセグメントをより大きくし、将来的なマージのプレッシャーを減らすことを意味します。\nデフォルトは10%で、それで十分です；例えば、もし、5つのアクティブなシャードがノードにあり、ヒープが25GBの場合、各シャードは25GBの10%の1/5=512MB（すでに最大値）を持っています。ヘビーなインデキシングのあと、この設定をデフォルトに下げましょう。検索時のデータ構造のために十分なRAMを確保するために。この設定はまだ動的な設定変更はできません。Issueがここにあります。\nインデックスバッファによって現在利用されているバイト数は1.3.0のindices stats APIに追加されています。indices.segments.index_writer_memoryの値を見ることができます。これはMarvelではまだプロットされていませんが、将来のバージョンで追加される予定です。しかし、自分でグラフに追加することもできます。(Marvelはデータは収集しています)\n1.4.0では、indices.segments.index_writer_max_memoryとして、indices stats APIにアクティブシャードにどのくらいのRAMバッファが割り当てられているかも表示されます。これらの値はインデックスのシャード事の値として見ることができ、http://host:9200/\u0026lt;indexName\u0026gt;/_stats?level=shardsを使ってみることができます；これは、全シャードに対する合計と、各シャードごとのstatsを返すでしょう。\nオートIDの利用もしくは良いIDの利用 もし、ドキュメントのIDがなんでも良い場合、Elasticsearchで採番することができます：これは、(1.2以降)ドキュメントIDをバージョンを探さずに保存できるように最適化され、Elasticsearchの日毎のベンチマークで異なるパフォーマンスを見ることができます。(FastとFastUpdateのグラフを比較)\nもし、IDを自身が持っていて、自分の支配下でLuceneに対して素早く選ぼうとしているなら、1.3.2にアップグレードしましょう、IDのルックアップがさらにオプティマイズされています。JavaのUUID.randomUUID()はやめましょう。それは、セグメントに対してどのようにIDを割り当てるかという予測やパターン性がないため、最悪のケースでセグメントごとのシークが発生します。\nFlake IDsを利用した時のMarvelによるインデックス性能の違い：\nflakeIDsPerf ランダムUUIDを利用した場合：\nuuidsPerf 次の1.4.0では、ElasticsearchのID自動採番をUUIDからFlake IDに変更します。\nもし、Luceneのローレベル操作がインデックスに対してなにをやっているかについて興味があるなら、lucene.iwをTRACEログレベルで出力できるようにしてみましょう(1.2から利用可能)。これは、多くの出力がありますが、LuceneのIndexWriterレベルで何が起きているかを理解するのに非常に役に立ちます。出力は非常にローレベルです：Marvelがインデックスに何が起きているかをよりリアルタイムにグラフを描画してくれます。\nスケールアウト 我々は、単一シャード(Luceneインデックス)性能のチューニングに注目してきました。しかし、一旦それに満足できたならば、Elasticsearchはクラスタ全体にわたってインデキシングや検索を簡単にスケールアウトすることに長けています。シャード数(デフォルトでは5)を増やすのは可能です。それは、マシン全体に対して並列度、巨大なインデックスのサイズ、検索時のレイテンシの低下など得ることができます。また、レプリカを1位上にすることは、ハードウェア故障に対する冗長性を持つことを意味します。\n最後に、このドキュメントを見ても問題解決しない場合はコミュニティに参加しましょう。例えば、ElasticsearchのユーザMLに投稿するなど。おそらく、修正すべきエキサイティングなバグがあるでしょう。(パッチも常に歓迎です！)\n","date":1410250260,"dir":"post/2014/","id":"77d965afaebd7193badc746d52b4173f","lang":"ja","lastmod":1410250260,"permalink":"https://blog.johtani.info/blog/2014/09/09/performance-considerations-for-elasticsearch-indexing/","publishdate":"2014-09-09T17:11:00+09:00","summary":"Elasticsearchのインデキシングに関するパフォーマンス検討 原文：performance considerations for elasticsearch indexing Elasticsearchユーザは様","tags":["Elasticsearch"],"title":"Elasticsearchのインデキシングに関するパフォーマンス検討"},{"contents":"懲りずにまた、執筆してみました。みなさん「買って」から感想をいただけるとうれしいです！\n本書について 共著者の方々のブログが詳しいので、そちらを読んでもらいつつ。 実際にログを収集して解析されている方々と一緒に書かせていただくことで色々と勉強させていただいています。\n共著者の方々のブログ @suzu_vさん：サーバ/インフラエンジニア養成読本 ログ収集~可視化編 を書きました @yoshi_kenさん：ログ収集や可視化で話題のFluentd、Elasticsearch、Kibanaを徹底解説したムック本が発売となります @harukasanさん：書きました: サーバ/インフラエンジニア養成読本 ログ収集~可視化編 どの辺を書いたの？ 「特集３：Elasticsearch入門」（なんか、入門ばっかりだなぁ）を書かせていただきました。 データストア入門ということで、ほんとうに簡単な他のデータストアを説明し、Elasticsearchってどんなものかを単語の説明をしつつ紹介してみました。\nElasticsearch自体は多くの機能を持っており、それ単体で分厚い書籍がかけるので、ログ検索に関係ありそうな部分をピックアップしてみました。 あとは、運用時に気をつける点や便利なツール（Curatorなど）の紹介をしています。\nまた、Hadoopと合わせて利用してみたい、すでにHadoopにあるデータも活用してみたいという話もありそうだということで、elasticsearch-hadoopについても簡単ですが紹介してあります。\nその他感想 個人的に、忙しい時期（参考記事）だったので、あんまり力になれてないので大変申し訳なく思っています。。。 ただ、素晴らしい出来（カラーでKibanaの解説が日本語で読めたり、Fluentdの逆引きのリストがあったり、ログを貯めて可視化する意義を説明してあったり）です。\nぜひ、読んだ感想をいただければと！\n","date":1407156840,"dir":"post/2014/","id":"bdea71d64cdfcc405e65e750fe8d9b86","lang":"ja","lastmod":1407156840,"permalink":"https://blog.johtani.info/blog/2014/08/04/release-magazine-book-of-log-aggs-and-viz/","publishdate":"2014-08-04T21:54:00+09:00","summary":"懲りずにまた、執筆してみました。みなさん「買って」から感想をいただけるとうれしいです！ 本書について 共著者の方々のブログが詳しいので、そちらを","tags":["elasticsearch","kibana","本"],"title":"サーバ/インフラエンジニア養成読本 ログ収集~可視化編 を手伝いました"},{"contents":"Proxy環境で働いている方も結構いると思います。 Twitter上で、Elasticsearchのpluginコマンドでプラグインがインストールできなくて困っている方がいたので、 調べてみたのでメモしておきます。\nプラグインコマンド Elasticsearchでは、プラグインという形でいくつかの便利な機能が公開されています。 形態素解析ライブラリのKuromojiを使うためのプラグインや、クラスタの管理がGUIで可能なkopfプラグインなどがあります。 公式、サードパーティいろいろです。\nこれらのプラグインをElasticsearchにインストールする場合、以下のコマンドを実行すれば 自動的にダウンロードしてpluginsディレクトリにインストールしてくれます。\n./bin/plugin -i elasticsearch/elasticsearch-analysis-kuromoji/2.3.0 ここで、elasticsearch/elasticsearch-analysis-kuromoji/2.3.0がプラグインのパスになります（例では、提供元/プラグイン名/プラグインバージョンとなっています。）。\nこのpluginコマンドがダウンロード元にアクセスに行くのですが、プロキシ環境だとプロキシの設定が必要になります。\nプロキシの指定（Mac/LinuxとWindowsでの違い） Mac/Linux(shコマンド) 以前の記事でプロキシのポート番号などの指定方法を 以下のように説明していました。 （※昔の記事のため、kuromojiプラグインのバージョンが古いです）\nElasticsearchのpluginコマンドはJavaで実装されています。（org.elasticsearch.common.http.client.HttpDownloadHelper） プラグインのダウンロードには、java.net.URL.openConnection()から取得URLConnectionを使用しています。\nですので、pluginのインストールを行う際に、Proxy環境にある場合は以下のようにコマンドを実行します。\n./bin/plugin -DproxyPort=ポート番号 -DproxyHost=ホスト名 -i elasticsearch/elasticsearch-analysis-kuromoji/1.5.0 LinuxやMacの環境であれば、こちらのコマンドでプロキシの指定が可能です。 ただし、Windows環境ではうまくいきません。\nElasticsearchは、環境の違いにより、ダウンロードするファイルが異なります。 Windows環境の方は、zipファイルをダウンロードしてもらうようになっています。 elasticsearchコマンドおよびpluginコマンドがbat形式で提供されているのがzipファイルとなるからです。\nWindows(batコマンド) Windows環境では次のように指定します。\nset JAVA_OPTS=\u0026#34;-DproxyHost=ホスト名 -DproxyPort=ポート番号\u0026#34; bin\\plugin -i elasticsearch/elasticsearch-analysis-kuromoji/2.3.0 コマンドの実装方法が少し異なるために、このようになっています。\nまとめ プロキシ環境で利用される場合は、プラグインコマンドは上記のように実行していただければと。\n公式ガイドには、これらの情報を追記するPRを送る予定です。 また、WindowsのコマンドでもMac/Linuxと同様にできたほうがいい気がするので、Issueをあげようと思います。\n不明点などあれば、コメントいただければと。\n","date":1406874240,"dir":"post/2014/","id":"7cc605e721fdd1d2ccc16f5b6490e830","lang":"ja","lastmod":1406874240,"permalink":"https://blog.johtani.info/blog/2014/08/01/plugin-using-under-proxy-env/","publishdate":"2014-08-01T15:24:00+09:00","summary":"Proxy環境で働いている方も結構いると思います。 Twitter上で、Elasticsearchのpluginコマンドでプラグインがインスト","tags":["elasticsearch","plugin"],"title":"プロキシ環境でのpluginコマンドの実行"},{"contents":"原文：Elasticsearch 1.3.1 Releasedを日本語に翻訳したものです。\nバグフィックス版のElasticsearch 1.3.1をリリースしました。 ダウンロードおよび変更履歴はElasticsearch 1.3.1からお願いいたします。\nこのリリースはインデックスリカバリ時の後方互換性バグ（#7055）への対応です。 このバグはデータの欠損は起こりません。 Elasticsearch 1.3.1へアップグレードすることで問題を回避できます。 このバグは、以下のElasticsearchのバージョンで作成されたセグメントを含むインデックスを1.3.0へアップグレードしようとすると発生します。\nElasticsearch 0.90.7 Elasticsearch 0.90.2 Elasticsearch 0.90.0以前のバージョン このバグは、これらの古いインデックスをレプリカからリカバリできなくします。 これらのバージョンのセグメントを持つインデックスが、レプリカは可能ですが、 ステータスがYellowのままGreenに決してなりません。 ログには次のようなExceptionが発生します。\nIllegalArgumentException[No enum constant org.apache.lucene.util.Version.x.x.x]\nLuceneの特定のバージョンではLuceneのマイナーバージョンを含んでおらず、誤ったバージョン番号がセグメントに記録されました。 LUCENE-5850のチケットがこの問題に対処するためにオープンされています。 この問題は我々の後方互換テストで見つかるべき問題ですが、Luceneで不足しているため発見されませんでした。 テストスイートは今後の可能性のために改良されます。\nこのリリースはその他に、Aggregationのマイナーバグフィックスも含まれています。 詳細はリリースノートをご覧ください\nElasticsearch 1.3.1をダウンロードし、試してください。 もし問題を見つけた場合はGitHubのIssuesへご報告をお願いいたします。\n","date":1406604120,"dir":"post/2014/","id":"fb1da4a6ed74705ad98bb60ad4badaf2","lang":"ja","lastmod":1406604120,"permalink":"https://blog.johtani.info/blog/2014/07/29/elasticsearch-1-3-1-release/","publishdate":"2014-07-29T12:22:00+09:00","summary":"原文：Elasticsearch 1.3.1 Releasedを日本語に翻訳したものです。 バグフィックス版のElasticsearch 1.3.1をリリー","tags":["elasticsearch","release"],"title":"Elasticsearch 1.3.1 リリース（日本語訳）"},{"contents":"Curatorの1.2.0がリリースされました。\n前回のCuratorの記事が古くなってしまった（1.1.0からコマンドのI/Fが変更された）ので 1.1.0および1.2.0に関する記事を翻訳しておきます。\nちなみに、Curatorとは、Elasticsearchに時系列のインデックス（例：LogstashやFluentdでログを保存）を保存している場合にそれらのインデックスを管理（削除したり、クローズしたり）するための便利なツールです。 Curatorの概要については、GitHubリポジトリか前回の記事をご覧ください。\nCurator 1.1.0リリース (2014/06/13公開) 元記事：elasticsearch curator - version 1.1.0 released\nElasticsearch 1.0.0がリリースされ、新しい機能、Snapshot \u0026amp; Restoreが利用できるようになりました。 Snapshotはある時点でのインデックスの写真を撮るように、バックアップを作成することができます。 1.0.0が発表されてすぐに、この機能に関するリクエストが寄せられるようになりました。 「Curatorにスナップショットを追加して！」もしくは「いつCuratorでスナップショットが使えるようになる？」といった感じです。 これがあなたの要望なら、それはついに叶えられました。しかも他の追加機能も一緒にです。\n新機能 Curatorの新機能は以下のとおりです。\n新CLI構造 スナップショット(Snapshot) エイリアス(Aliases) パターンによる除外インデックス指定 配置ルーティング(Allocation Routing) インデックスとスナップショットの表示 リポジトリ管理(個別のスクリプトによる) ドキュメントWiki 新コマンドライン構造 注意：コマンドライン構造の変更とは、Curator 1.1.0以前のcron記述が動作しないことを意味します。Curator 1.1.0にアップグレードする場合はコマンドも修正が必要となるので注意してください。\nシンプルにするために、commandsという概念を追加しました。 また、ヘルプの出力もわかりやすくなっています。 前のバージョンと同じタスクをCuratorは実行できますが、異なるフォーマットを用いるようになりました。\n旧コマンド：\ncurator -d 30 新コマンド：\ncurator delete --older-than 30 コマンドは、フラグとは異なりハイフンを前に付けないことに注意してください。 また、似たような名前のフラグがあることに気をつけてください。 例えば、--older-thanフラグは多くのコマンドに利用できます。 指定される値は各ケースにおいて同一です。「指定された数よりも古いインデックス」となります。\n新しいコマンドのリストは次のとおりです。\nalias allocation bloom close delete optimize show snapshot コマンドのヘルプは次のコマンドで表示されます。\ncurator [COMMAND] --help コマンドに関係あるフラグがすべて表示されます。\nスナップショット(snapshots) snapshotコマンドで、存在しているリポジトリにインデックスのスナップショットを保存することができます。\nCuratorはインデックス毎に1つのスナップショットを作成し、インデックスから名前をつけます。 例えば、インデックスの名前がlogstash-2014.06.10の場合、スナップショットの名前はlogstash-2014.06.10となります。 指定した条件を元に、シーケンシャルに、1つずつインデックスのスナップショットを作成していきます。\ncurator snapshot --older-than 20 --repository REPOSITORY_NAME このコマンドは、20日以上古いインデックスすべてのスナップショットを作成し、REPOSITORY_NAMEで指定されたリポジトリに保存します。\nes_repo_mgrと呼ばれるリポジトリ作成を支援するスクリプトがCuratorには含まれています。 ファイルシステムおよびS3タイプのリポジトリ両方の作成を支援します。\nさらに、古いインデックスのスナップショットを取ることができることに加えて、Curatorは最新のインデックスをアップロードする方法も提供します。 これは、Elasticsearch Marvelのインデックスをアップロードするときに便利です。 トラブルシューティングを目的として、パフォーマンスデータを他の人に見せる場合などです。\ncurator snapshot --most-recent 3 --prefix .marvel- --repository REPOSITORY_NAME このコマンドでは、最新の3つのMarvelインデックスのスナップショットを指定されたリポジトリに保存できます。\nエイリアス(aliases) Curatorはすでに存在するエイリアスにインデックスを追加することも、削除することもできるようになりました。 ただし、エイリアスがすでに存在している必要があります。エイリアスの作成はできません。\nlast_weekという前の一週間のインデックスのエイリアスを保持していること想像してください。 この場合、次の2つのコマンドを利用することで、エイリアスを管理できます。\ncurator alias --alias-older-than 7 --alias last_week curator alias --unalias-older-than 14 --alias last_week 新しく作られたインデックスがインデックステンプレートによって 自動的にエイリアスの一部となるようにElasticsearchに設定しておくと、さらに便利です。 この場合、新しいインデックスが自動的にthis_weekというエイリアスの一部になるようにしてあれば、以下のコマンドのみとなります。\ncurator alias --unalias-older-than 7 --alias this_week this_weekとlast_weekのエイリアスのアップデートを保持できます。\nパターンによる除外(exclude pattern) 時には、指定したインデックスを操作から除外したくなる場合もあるでしょう。 ここまでは、プレフィックスや日付によって選択されたインデックスのみを対象にしてきました。 そこで、--exclude-patternオプションです。これは、指定したインデックスを除いて処理を行うことができます。\nlogstash-2014.06.11というインデックスを決して削除したくないとします。 この場合、次のコマンドのようになります。\ncurator delete --older-than 15 --exclude-pattern 2014.06.11 Curatorはデフォルトでlogstash-というプレフィックスにマッチしますが、2014.06.11というインデックスは対象外となります。\n配置ルーティング(allocation routing) Elasticsearchはノードにタグを付けることができます。 これらのタグはインデックスやシャードをクラスタのどこに配置するかをコントロールするために役立ちます。 一般的なユースケースだと、高性能なSSDドライブを持ったノードをインデキシングのために、ハードディスクを持った性能の低いマシンは検索頻度が低い古いインデックスを配置するといった場合です。 この場合、HDDノードには、elasticsearch.ymlにnode.tag: hdd、SSDノードにはnode.tag: ssdと設定されているべきです。 Curatorはこの時、インデックスをタグに基づいてオフピークの時間帯に再配置させることができます。\nコマンド：\ncurator allocation --older-than 2 --rule tag=hdd index.routing.allocation.require.tag=hddという設定が２日よりも古いインデックスに適用されます。 これは、インデックスのシャードがnode.tag: hddというノードに再配置される必要があると、Elasticsearchに伝えます。\nインデックスとスナップショットの表示(show indices and snapshots) これは、単にあなたの持っているインデックスやスナップショットがどんなものかを表示します。\ncurator show --show-indices これは、デフォルトプレフィックスのlogstash-にマッチするすべてのインデックスを表示します。\ncurator show --show-snapshots --repository REPOSITORY_NAME これは、指定されたリポジトリにある、デフォルトプレフィックスのlogstash-にマッチするすべてのスナップショットを表示します。\nリポジトリ管理(repository management) 前に説明したとおり、es_repo_mgrと呼ばれるヘルパースクリプトをCuratorは含んでいます。 現時点では、fsとs3タイプをサポートしています。 リポジトリを作る前に利用したいタイプのドキュメントを読むようにしてください。 例えば、fsタイプのリポジトリを各ノードで使う場合は、同じ共有ファイルシステムに、同じパスでアクセスできなければなりません。 パスの指定は--locationです。\nfsタイプリポジトリの作成\nes_repo_mgr create_fs --location \u0026#39;/tmp/REPOSITORY_LOCATION\u0026#39; --repository REPOSITORY_NAME 削除\nes_repo_mgr delete --repository REPOSITORY_NAME ドキュメントWiki Curatorのドキュメントが更新され、オンラインにWiki形式でだれでも更新できるようになっています。 コマンドやフラグのより詳細の情報はこちらで見つけることができます。また、もし、興味があれば、ドキュメントを追加することもできます。\nインストールと更新 Curator 1.1.0はPyPiリポジトリにあります。 インストールは以下のとおりです。\npip install elasticsearch-curator バージョン1.0.0からアップグレードする場合は以下のとおりです。\npip uninstall elasticsearch-curator pip install elasticsearch-curator バージョン1.0.0よりも古いバージョンからのアップグレードは以下のとおりです。\npip uninstall elasticsearch-curator pip uninstall elasticsearch pip install elasticsearch-curator pip uninstall elasticsearchで、古いパイションモジュールをを削除します。 適切なバージョンが依存関係により再インストールされます。\nまとめ Curatorの新機能は素晴らしいです！このリリースは大きな改善です。 もし、トラブルや足りないものを見つけた場合はGitHub Issueに報告してください。 また、Curatorが便利だと思ったら、私たちに伝えてください。#elasticsearchタグを付けてツイートしてください！\nCuratorはまだ、始まったばかりです。Curator 2.0のロードマップを作業中です。ここまで読んでいただきありがとうございます。 Happy Curating!\nCurator 1.2.0リリース(2014/07/24) 元記事：curator 1.2.0 released\nCurator v1.1.0のリリースから、数週間が経ちました。 私たちは、Curator 1.2.0をリリースしました。\n新機能(new features) ユーザ指定の日付パターン：長い間リクエストされていた機能 ウィークリーインデックスのサポート：これも長い間リクエストされていた機能 複数のログフォーマットオプション：Logstashフォーマットが利用可能 これらの変更はCuratorドキュメントにも記載されています。\n更新(updates) ログ出力の整理：デフォルトのログ出力を整理しました。デバッグログはすべて表示されます。 ドライランのログ出力の詳細化：テスト実行時に何が起きたかをわかりやすくしました。 日付パターンと--timestring(date patterns and \u0026ndash;timestring) 前のリリースで、セパレータ文字を利用して、インデックス名のエレメントを分離することで、日付を計算しました。 この設計の決定は、プログラムが管理するために設計されたLogstashのインデックスを使うのには簡単でした。 しかし、Curatorは時系列インデックス管理に成長しています。これは、異なる命名規則のインデックスを意味しています。\nまた、インターバルによって、日付の計算が必要になる場合もあります。 --time-unitオプションが残っており、weeksという単位を指定することもできます。 デフォルトの--timestringオプションは、以前のコマンドと同様の動作をしなければなりません。次のようになります。\nTime Unit Timestring days %Y.%m.%d hours %Y.%m.%d.%H weeks %Y.%W これが意味するものは、もし、単位にhoursをした場合、--timestringを指定しなかった場合は%Y.%m.%d.%Hとなります。 これは、Pythonのstrftimeフォーマットで\u0026quot;年.月.日.時\u0026quot;を意味します。 同様に、weeksを単位に指定した場合、Curatorはデフォルトの--timestringは%Y.%Wとなります。\nこの機能は、日付の間にセパレーター文字のないインデックスでも機能します。 例えば、production-20140724のような日時インデックスがある場合、2日よりも古いインデックスに対するブルームフィルタっキャッシュのオフのコマンドは次のようになります。\ncurator bloom --prefix production- --older-than 2 --timestring %Y%m%d この例で、デフォルトの単位はdaysであることに注意してください。hourly-2014072414のような時間インデックスの場合は次のようになります。\ncurator bloom --prefix hourly- --older-than 2 --time-unit hours --timestring %Y%m%d%H --separatorの置き換え もし、Curatorの前のバージョンでカスタムセパレータ文字を利用していた場合、次のように変更すべきです。 前のコマンドでcerberus-2014-07-24のようなインデックスがある場合、コマンドを--separator -の用に置き換える必要があります。 新しいコマンドは次のとおりです。\ncurator delete --prefix cerberus- --older-than 30 --timestring %Y-%m-%d 年(％Y)と月(%m)と日(\u0026rsquo;%d\u0026rsquo;)の間にセパレータ文字を置くだけです。\nこれは、また、Curatorで以前は不可能であったことをできるようにもします。 異なるセパレータ文字の混在です。 logs-2014.07.24-14というようなインデックスを処理するときに--timestringは%Y.%m.%d-%Hのようになります.\n--timestringの詳細はCuratorのドキュメントをご覧ください。\nフィードバック これらの新しい機能はユーザのコメントやリクエストから来ています。もし、機能のリクエストやバグを発見したら、こちらまで連絡してください。\nまた、Twitterでもお待ちしています。私たちのTwitter IDは@elasticsearchです。\nHappy Curating!\n","date":1406524740,"dir":"post/2014/","id":"0c1821d1069578551d0e3c7d9275f16b","lang":"ja","lastmod":1406524740,"permalink":"https://blog.johtani.info/blog/2014/07/28/curator-2-0-and-1-1/","publishdate":"2014-07-28T14:19:00+09:00","summary":"Curatorの1.2.0がリリースされました。 前回のCuratorの記事が古くなってしまった（1.1.0からコマンドのI/Fが変更された）","tags":["elasticsearch","curator"],"title":"Curator 1.2および1.1について"},{"contents":"第5回Elasticsearch勉強会を開催しました。 遅くなってしまいましたが、まとめてみました。\n今回は、Elasticsearchに入って初の勉強会でした。タイミングが良いことに、Honza、Igor、Shayの3名がトレーニングのために 来日していたため、特別回ということにして、話をしてもらいました。\nそして、サムライズムの@yusukeさんにテキスト翻訳してもらいました。 早くて正確なタイピング＋翻訳、本当にありがとうございました。\n開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！ 参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\namazing turnout to the elasticsearch at Tokyo #elasticsearchjp pic.twitter.com/Aa88eVf5dF\n\u0026mdash; Shay Banon (@kimchy) 2014, 7月 14 動画があとで、アップされる予定です。お楽しみに。\nHonza\u0026rsquo;s talk djangoの開発者！であり、ElasticsearchのPythonクライアント、Curatorの開発者 Python Clientを利用しながら、ライブコーディングのような形で説明する方法が新鮮 Aggregationの便利さについての説明 Python Clientがクエリを組み立てるのにすごく便利そうだった Pythonユーザが結構いたので助かりましたｗ Igor\u0026rsquo;s talk スライド：elasticsearch data/\nSnapshot/Restoreの開発などを行っている開発者 Elasticsearchのデータ、ディレクトリ構造に関するお話 シャードの話から、ディレクトリ構造、メタデータに関する説明 transaction logの挙動の説明 検索のフェーズの説明 Igorは、実は私がElasticsearch社の人とコンタクトがとれた最初の人だと思います。 第1回Elasticsearch勉強会が開催する当日に帰国されるという不運だったのですが、1年越しでトークしてもらえました！\n@johtani I am so bummed! I am leaving Tokyo Thursday morning.\n\u0026mdash; Igor Motov (@imotov) 2013, 8月 27 QA ShayをメインにいくつかのQAをしてもらいました。 NetflixなどのMeetupの動画で見てたのですが、こんな形で日本でも実現できるとは。\nQ: なんで、ファイルデスクリプタの設定を大きくするの？ A: Luceneのインデックスは複数のセグメントから構成されている。メモリに作られたあと、ファイルにfsyncされる。 Q: KibanaでAggregation使いたいんだけど？ A: Kibana 4で対応するよ！異なるフィールドの値を1つのグラフにすることも出来るよ！ Q: なんでElasticsearch作ったの？ A: 暇だったからｗ奥さんのレシピ検索を作ってみようと思って作り始めて、Luceneを触って感動して。。。検索すげー、Compassってのを触ってこれもすごいと思いつつ、もっとLucene活用できるんじゃないかということでElasticsearch作ったんだ。奥さんのレシピ検索？まだ完成してないよｗ Q: 2000くらいスナップショット撮ったらパフォーマンスが悪くなっててなんで？ A: 差分でスナップショットを作るんだけど、差分の計算に昔のスナップショットを見るので、定期的に新しくしたほうがいい。もし、気になることがあったらIssue上げたりMLに投げてくれるとうれしい。\n（あとでちょっと聞いたけど、古いスナップショットを消すのも有効っぽい。差分でスナップショットを作るけど、昔のを消した場合は、新しいスナップショットが利用しているファイルは残る仕組みになっているから。） Q: Relevancyのチューニングってどうすればいい？ドキュメントが少なくない？ A: ドキュメンテーションは頑張ってるので、応援してねｗあとは、definitive guideも参考になるよ。スコアはfunction_scoreクエリがすごいのでいろいろ使ってね。MVELをGroovyに帰る予定。性能もだけど、サンドボックス的な意味もあります。 Q: 次のVisionは？現時点は検索だけど。（最後の質問がとてもナイスで、助かりましたｗ私がしたほうがいい気がするｗｗ） A: 今後はアナリティクスのプラットフォームに向かってる。Aggregationとかね。メモリ効率よくしたりしてるよ。あとは、Field-collapsionも実装中だよ。あと、マシンラーニングとかもね。データを探索するための機能を色々作ってくよ。障害性にも。チェックサム機能をLuceneに入れて、ESにも入れていく予定。Zenの機能も改善している。 まとめ 今週は、トレーニングがあったり、いろいろな打ち合わせがあったりと、テンパってたので至らない点が多かったかもしれないですが。。。 楽しんでいただけと思います。 数日、Shay、Honza、Igorと行動を共にして、本当に情熱のあるチームでユーザのことを気にかけているなと感じることができました。 少しでもその片鱗を勉強会で感じてもらえたんじゃないかと。特に、QAでのShayによる情熱が伝わったんじゃないかと。\n懇親会でも数人の方から、日本語のサポートを望んでいるという声も頂きました。 興味のある方は私までコンタクトいただければと。\nあと、@yusukeさんのテキスト翻訳が素晴らしくて、参加してもらった方たちも絶賛してました。 次回も英語スピーカーの場合に助けてもらえると嬉しいです（私もそこまで出来るように頑張ります）\nその他のブログ ブログ記事ありがとうございます！\n第5回elasticsearch勉強会にいってきました - はやさがたりない。 感想戦：aggrigation から見える検索エンジンの次 - 第5回 Elasticsearch勉強会 - よしだのブログ 「第5回elasticsearch勉強会 #elasticsearch #elasticsearchjp」（2014年07月14日）の参加メモ - uchimanajet7のメモ ","date":1405774320,"dir":"post/2014/","id":"e3e146469ed4318eaa2ffbca3510c054","lang":"ja","lastmod":1405774320,"permalink":"https://blog.johtani.info/blog/2014/07/19/hold-on-5th-elasticsearch-jp/","publishdate":"2014-07-19T21:52:00+09:00","summary":"第5回Elasticsearch勉強会を開催しました。 遅くなってしまいましたが、まとめてみました。 今回は、Elasticsearchに入って","tags":["elasticsearch","勉強会"],"title":"第5回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"ということで、転職しました。 どーしてもやりたいことが出てきたので、無理を言って転職することにしてみました。\nサムライズムではなく、Elasticsearchにジョインします。（というか、しました。）\n初出社 #サムライズム\n\u0026mdash; Jun Ohtani (@johtani) 2014, 7月 1 冗談でツイートしたのですが、その前に英語アカウントのツイートがRTされてしまっていまいちでした。。。\nスキポール空港 先週、アムステルダムに行っていたのも退職前に休みをいただき、Elasticsearchの全社会議に参加していたためです。 とてもエキサイティングな経験（英語漬けとか）ができ、もっと精進しないとなという気持ちにもなり、ますます頑張らないとなと。\nということで、今後は日本中にElasticsearchやLogstash、Kibanaを広めるべく、いろいろな場所で話をしたいと思います。 興味のある方は、声をかけていただければと。\nあと、東京でElasticsearchのCoreトレーニングが行われます。 通常は2日間ですが、通訳の方が付く関係で3日間の開催となっています。 開発者2名がトレーナーとして来日します。開発者に質問をできる良い機会ですので、興味のある方は参加してみてはいかがでしょうか。 また、CTOのShay Banonも来日する予定です。\nトレーナー2名とShayは7/14の勉強会でも話をしてくれます。 こちらも興味のある方は参加してみてください。（参加登録はこの後、すぐに開始します。）\nまだまだ、勉強しなければいけないことだらけですが、ElasticsearchのいろいろなプロダクトやOSSについて広めていきたいと思いますので、よろしくお願いいたします。\nおまけ ということで、一度やってみたかったのでリンクを貼ってみます。\nほしい物リストはこちら\n","date":1404181800,"dir":"post/2014/","id":"21a8e6324e9330d4f8ebade604c62b6e","lang":"ja","lastmod":1404181800,"permalink":"https://blog.johtani.info/blog/2014/07/01/join-elasticsearch/","publishdate":"2014-07-01T11:30:00+09:00","summary":"ということで、転職しました。 どーしてもやりたいことが出てきたので、無理を言って転職することにしてみました。 サムライズムではなく、Elasti","tags":["転職"],"title":"転職しました"},{"contents":"退職しました。\n色々と書きたいんですが、時差ボケで頭痛いので、このくらいです。 余裕出たら書くかも。\nほしい物リストはこちら\n新天地についてはまた明日。\n","date":1404137940,"dir":"post/2014/","id":"40abea0a87a64bd832a1fad69458b293","lang":"ja","lastmod":1404137940,"permalink":"https://blog.johtani.info/blog/2014/06/30/resignation/","publishdate":"2014-06-30T23:19:00+09:00","summary":"退職しました。 色々と書きたいんですが、時差ボケで頭痛いので、このくらいです。 余裕出たら書くかも。 ほしい物リストはこちら 新天地についてはまた明","tags":["転職"],"title":"退職しました"},{"contents":"Elasticsearch server 2nd editionが発売されています。\n私が翻訳したのは前のバージョンですが。。。 まずは、目次を元にどのくらい変わってるかを見てみました。 （全部まだ読んでなくて。。。）\n1章 Getting Started with the Elasticsearch Cluster 冒頭に、全文検索とは、転置インデックスとはどんなものか、 Luceneの簡単なアーキテクチャの仕組みについて説明が追加されています。 検索の仕組みを知らない人が読んでもわかりやすくなっています。\nインストール方法なども少し追記されています。 バージョニングと簡単なデータ登録と検索方法についてもここで触れられています。 検索結果の構造の説明もちょっとあります。 まず簡単に触ってみるというところまでが1章でまとめられた感じです。\n2章 Indexing Your Data 新しく、切りだされた形です。 前のバージョンでは1章で説明されていた、Mapping周りが切りだされています。 シャードやレプリカの説明もこちらです。\nIPアドレスタイプ（IPv4のみ）とtoken_countタイプの説明も追加されてます。 similarityやpostingsフォーマットなどは新しく追記されています。 また、メタフィールドと呼ばれる_typeなどはこちらに移動しているようです。 マージ処理などの説明も追記されています。このあたりは、Mastering ElasticSearchに 記載されているものが移植された感じでしょうか。\n3章 Searching Your Data 前のバージョンでは2章だった章です。 クエリについては1.0で追加されたsimple_query_stringなどが追記されています。 constant_scoreやdismaxなどもです。\nまた、前のバージョンの3章で説明されていたハイライトや8章で触れられていたvalidate APIについても 移動しています。\n4章 Extending Your Index Structure 前のバージョンの3章で触れられていた、データの構造に関する部分がこの章になります。 親子や配列、ネスト等のデータのインデックスや検索の方法です。\n5章 Make Your Search Better スクリプティングや言語判定などの仕組みが記載されています。 また、ブーストについても同様です。Synonymについてもここです。 スパンクエリについては省略されたのかな？\n6章 Beyond Full-text Searching 1.0の目玉機能の一つであるAggregationの説明から始まります。 その後、ファセットやPercolatorについてです。メモリに関する注意点もありそうです。 また、Geoについての説明がこちらに移動されていました。 scroll APIについてもこちらで説明されています。\n7章 Elasticsearch Cluster in Detail 前の7章で記載されていたElasticsearchの分散の仕組み（Node Discovery）についての記載があります。 また、1.0で追加されたcircuit breakerやスレッドプール、インデックスのリフレッシュレートなど、Mastering ElasticSearchの 内容も追記されている気がします。\nインデックスやマッピングのテンプレート機能についてもここで説明があるみたいです。\n8章 Administrating Your Cluster 1.0で追加されたsnapshot/restoreの説明から始まります。 あとは、前のバージョンの7章で説明されていたクラスタ管理用のAPIについての説明です。 いくつか（例えばcat API）、1.0で追加されています。\nまた、シャードのリバランスの話も追加されているようです。 エイリアスやプラグインの話はこちらに移動してるみたいです。\n感想 ということで、とりあえず、駆け足で目次ベースで違いを見てみました。 Mastering ElasticSearchでの 知見がフィードバックされ、しかも1.0（すでに1.3が出そうな勢いですが。。。）にバージョンアップされた内容になっています。 冒頭がわかりやすくなっているので、検索をやったことのない方にもおすすめな書籍になった気がします。 英語が苦にならなければ、おすすめの一冊だと思います。\n来月から読み進めるつもりなので、また、面白い内容があったら感想を書いていこうと思います。 （また翻訳できるといいかもなー）\n","date":1402908420,"dir":"post/2014/","id":"916bda59bc7621d5c1790c040572a3c0","lang":"ja","lastmod":1402908420,"permalink":"https://blog.johtani.info/blog/2014/06/16/first-impression-elasticsearch-server-2nd-edition/","publishdate":"2014-06-16T17:47:00+09:00","summary":"Elasticsearch server 2nd editionが発売されています。 私が翻訳したのは前のバージョンですが。。。 まずは、目次を元にどのくらい変わってるかを見てみました。 （","tags":["elasticsearch","本"],"title":"Elasticsearch server 2nd editionのファーストインプレッション"},{"contents":"可視化ツール現状確認会に参加して、カジュアルウォーターじゃなくて可視化ツールの現状を確認してきました。\nということで、いつものメモです。\nMackerel と Graphite について （y_uuk1さん） Graphite 時系列 工夫すればスケーラブル SensuやCollectdと組み合わせたり GrafanaとGrapheneでGUI Mackerel素敵だよと。 架空のわかりやすいグラフが見れた Kibana \u0026amp; Grafana \u0026amp; Influga （hakoberaさん） Kibana\nかっこいい。 JVM大変。 Grafana\nGraphiteがカッコ悪いのでKibanaをフォーク なぜか、ESが必要。 InfluxDBに浮気しそう Influga\n@haoberaさん作 InfluxDB Queryサポート 迷ったら、Kibana入れとけ。\nDistinctがKibana出できないけど、それ以外はある程度行けるらしい。\naggregationがサポートされたら、できると思う。 Kibana以外は、バックエンドがタイムシリーズなので、縛りがある\n可視化ツール紹介（仮） （showyouさん） 誰がチャートを作るの？ 誰が見るの？ 一覧化されてて、あとで眺めたい IPython Notebookのデモ R shiny Serverのデモ Pentaho CE+Saikuのデモはネットワークがダメだったので割愛 分析側の視点を見せたかったので。 可視化とは何だったのか （harukasanさん） インフラ モニタリング、アナライズ、可視化どれ？ 可視化は目的ではないよねと。 熱く、ユーザとサービスプロバイダ間の距離のお話。 ログ 生ファイルで残すのが重要 トータルで必要とか考えないといけないことがわかって面白かったｗ\nあなたの知らないrrdtool （shoichimasuharaさん） すげー！ いろいろできるらしい（ノートPCの前にいなかったｗ） D3.jsとジオマッピング （Takaki_さん） 時空間推進課！すげー！ ジオデータのおはなし。 TopoJSONとかGeoJSONとか Zipkinについて （synkさん） ものすごい数のJVMがThriftで殴りあってるらしい。 ZipkinはTwitterが作ったもの Brave、HTraceというのが、PureJava用のZipkinトレーシングプラグイン 見積もりする必要がないくらいでかいHBaseがあるので、そこにためてる。 まとめ LINEはエンジニアを大募集中 Graphiteについて (mickey19821 さん) ドリコムさんのGraphiteのおはなし Metricsの収集はCollectd Graphite-webがスケールできなくて困ってるらしい。 Graphiteで可視化ツラいｗ まとめ RRDTool最高\nあと、クックパッドの技術力がすごいという発表なんかもありました。\n","date":1401884100,"dir":"post/2014/","id":"5bb6f8322cdbda7a21e4aecbe04462b7","lang":"ja","lastmod":1401884100,"permalink":"https://blog.johtani.info/blog/2014/06/04/attending-visualize-study/","publishdate":"2014-06-04T21:15:00+09:00","summary":"可視化ツール現状確認会に参加して、カジュアルウォーターじゃなくて可視化ツールの現状を確認してきました。 ということで、いつものメモです。 Mackerel と Graphite","tags":["勉強会"],"title":"可視化ツール現状確認会に参加してきました。#可視化"},{"contents":"今月2回目の目黒で、初のドリコムさんです。 「最新インフラエンジニア技術勉強～Fluentd, Elasticsearch,Chefの実践実例～」に参加してきました。 もちろん、Elasticsearchってキーワードがあったからです。\nざっくりメモです。\nドリコムのInfrastructure as Code/ひらしーさん CM：jojoss、トレクル、など サーバ300台、クラウド○○台。月30〜50台の割合で増加中。 少人数でいかに回すか。 Chef Rubyが書ける人が多いから。 serverspec テストだよと。 すみません、色々と聞き逃しました。。。\nWinning the metrics battle/mickeyさん Graphiteとかを触っている。 1300台超えたら、色々大変だった。 失敗談 Cactiを利用して、色々と運用が大変だった。DCが別なのでProxyとか。 成功例？現行システム？ 最大値、平均値、最小値などをプロット collectdを収集、送信に採用して、独自で開発？ 受信して保存するのに、Graphite（carbon-relay、carbon-cache、DRBD、graphite-web）ってなってる。 1300台程度のサーバから、5分間隔で、問題ない。 Graphite良いツールだよ。 Q：過去データはどのくらい？ A：5分間隔で1年分。\nQ：移動平均とかを使ったグラフとか時間かかりませんか？100台だと A：100台でもほとんど時間はかからない。\nFluentd プラグイン開発講座/外山 寛さん Fluentdプラグインを作ることができると威力倍増 Elasticsearchの勉強会の話までしてくれました！ 勉強会スペース貸出しています。 未公開だけど、sedueのプラグインもあるらしい。 CHUNKとBUFFERとか覚えときましょう プラグインの作り方的なのがなかった気がしたので、今回の発表です。 gem作らなくてもディレクトリにおけば使えるよと。 td-agent使ってる人が大多数だよね。（fluentdを素で使ってる人は会場にはいなかった） エンジニア募集中 Q：エラー処理どうしてますか？ A：今は、スルーしています\nQ：単体テストの書き方は？ A：人によってバラバラみたいですね。\nMySQLと組み合わせて始める全文検索エンジン「elasticsearch」/yoshi_ken スライド：http://www.slideshare.net/y-ken/introduce-elasticsearch-mysql-importer\nElasticsearch歴は1年位です。\nMySQLを使っていて、モダンな検索がほしいですよね？ね？\nサジェスト、ファセット、位置情報、ネスト検索などなど。\nGoogleトレンドだとSolrに迫る勢いと。\n実データを用いて、手軽にElasticsearchと連携。\nBinaryLogではなく、SQLの結果を同意する方式。yamabiko\n今日は、新しいものを公開します。\nbulk import file generator as well as nested document from MySQL for elasticsearch bulk api 東京トレーニング\nElasticsearch本については、右にあるリンクをクリックしてくれるとうれしいなぁ。\n","date":1400840280,"dir":"post/2014/","id":"a578acf825a595ce95fe8f804b7208f0","lang":"ja","lastmod":1400840280,"permalink":"https://blog.johtani.info/blog/2014/05/23/attending-drecom-infra-study/","publishdate":"2014-05-23T19:18:00+09:00","summary":"今月2回目の目黒で、初のドリコムさんです。 「最新インフラエンジニア技術勉強～Fluentd, Elasticsearch,Chefの実践実例～","tags":["勉強会","elasticsearch"],"title":"最新インフラエンジニア技術勉強に参加しました。"},{"contents":"どうやら、中身がSolrベース？Luceneベース？になったらしいということで、 今日は「AWSプロダクトシリーズ｜よくわかるAmazon CloudSearch」に行ってきました。\n※ElasticSearchではありません！\nということで、いつものメモ。\nCloudSearch Overview Amazon Web Services, Inc. Pravin Muthukumar(Product Manager) / Vivek Sriram (Business Development) Introduction to Search 検索の紹介。アイアンマンのDVD？のページにいろんな項目（フィールド）があるよねと。（もちろん、Amazonのページ） ファセット、Geo、テキスト処理（Analysis処理）、Postings listとか。とかとか ランキングも Amazon CloudSearch 独自実装orRDB拡張もある。 OSSもあるよね。 Legacy Enterprise SearchとしてFASTとかもある。 Building with CloudSearch 他のサービス同様、コンソールとかあるし、色々できるし、すぐ起動できるよと。 自動で、データが増えたら、パーティションが増えると。\n日本語の形態素解析があるらしい。何を使ってるのかな？ ICUのノーマライズとかもやってくれるらしい。これかな？http://lucene.apache.org/core/4_8_0/analyzers-icu/index.html ユーザが辞書を指定できるのかな？ 備えてる機能の説明\nファセット SimpleQuery Autocomplete Highlight などなど\nMulti-AZにも対応 QA Q：NGramありますか？ A：今はないです。 Q：ユーザ辞書対応してますか？ A：今はないです。 Q：lang-detectあるか？ A：今はないので、自分で判定して、適切なフィールドに入れてね。 Expectation for CloudSearch Apache Solr contributor　大須賀　稔氏 Solr本の宣伝ありがとうございます！（右のアイコンから買ってもらえると更に嬉しいですｗ） Kinesisとかとの組み合わせとか、自然言語処理とか、いろいろとあるAWSのコンポーネントと組み合わせる例が欲しいと。 すばらしい、最後はManifoldCFがらみに持っていくとは。ACLがらみのクローリングとかあるといいじゃないでしょうかと。 Impression of using CloudSearch 吉田　匠氏　(@yoshi0309　http://blog.yoslab.com/) スライド：https://speakerdeck.com/yoshi0309/impression-of-using-cloudsearch\nお見かけしたことある気がするなぁ。 全部置き換えできる！わけではなさそう。。。 いいところ。 UIがいいし、セットアップが簡単 auto scaleがうれしい マルチドメイン、マルチスキーマがいい Luceneのdismaxサポートがいい。（edismaxじゃないのかな？） dismaxって書いてあるな。\nhttp://docs.aws.amazon.com/cloudsearch/latest/developerguide/search-api.html\nフィードの仕方に気をつけて！\nバッチサイズで課金されるので、1件ずつじゃなくて、複数件送ったほうがいい。 いきなりスケールアウトできるわけじゃない？\nウォームアップ機能がない。インスタンス上限がデフォルト50件\nVPC対応してほしい。\nインターネット経由になってしまう フィードのスピードが セキュリティグループ機能が使えない CloudSearch UseCase - SnapDish Vuzz Inc.　清田　史和氏 独自辞書をもって、Tokenizeは独自でやって、空白区切りでデータ登録している。 インデックス更新はSQSを使ってる。 古いAPIを使ってるらしい。 移行が結構大変らしい。 感想 使ったことないんですが、きめ細かい検索したい場合はちょっとテクニックが要るかもと思いました。 AWS初心者なんで、なんとも言えないんですが。。。\nといあえず、テキスト処理（アナライズ処理）で、単語がどうやって区切られるのかってのがわからないのはキツイんじゃなかろうかと。 ただ、簡単に起動できて、オートスケールできるのは素晴らしいと思います。\n","date":1400143800,"dir":"post/2014/","id":"706c033b4483b6d062b66d6e4ea0236a","lang":"ja","lastmod":1400143800,"permalink":"https://blog.johtani.info/blog/2014/05/15/amazon-cloud-seaarch-study-session/","publishdate":"2014-05-15T17:50:00+09:00","summary":"どうやら、中身がSolrベース？Luceneベース？になったらしいということで、 今日は「AWSプロダクトシリーズ｜よくわかるAmazon Cl","tags":["勉強会","CloudSearch","AWS"],"title":"「よくわかるAmazon #CloudSearch 」に行ってきました！"},{"contents":"酔っ払ってなんとなく書きたくなったスピリチュアルなブログなので、流していただければと。\n最近、勉強会やTwitterで知り合いになって話をする人が増えたりで、 その方たちに色々と教えてもらうことが多いなぁと感じてます。 また、知り合いに恵まれてきたなぁとも。\nそもそも私が勉強会に参加し始めたきっかけはSolr勉強会（第1回から参加してて、気づいたら主催者になってた）で、 そのころは、Solr初心者で色々とやってる人、知ってる人がいて無料で話が聞けるのすごいと興奮したのを覚えてます。 （もちろん、ぼっちでしたが）\nSolr勉強会が定期的に開かれて、それに参加しているうちに少しずつ知り合いもできて、 面白そうな勉強会（Hadoopとか）が他にもあるんだ、参加してみようかって思うようになってと。\nそこにプラスで、関口さんと知りあえてSolr本を書く話が出てきて、本を書いてみたら、 今度は勉強会で話してみませんかとなって。\nスピーカーやると、顔を覚えてもらえるようで、また知り合いが増えてと。\n人のつながりって大事だし、自分が発信することで教えてもらえることもあるしと。 前にも書いた気がするけど、Solr勉強会（当時の主催の方）や関口さんやElasticsearch勉強会のスタッフの方や スピーカーやってくれた方、会場提供を心よくしてくれてるVOYAGE GROUP、リクルートテクノロジーズさん、という具合にどんどん頭が上がらなくなってきてるなぁと。\nということで、外の世界を知ると色々とつながりが出来て面白いですよという、個人的な感想でした。 ま、自分が思ってるだけで、違う意見もいっぱいあると思うけど。\nあー、なんか、酔って勢いで書いてしまった。。。 脈略のない文章なきがするけど、エイヤで公開しちゃおう。\n","date":1399999440,"dir":"post/2014/","id":"72df0bf7853e05560d94208817b83468","lang":"ja","lastmod":1399999440,"permalink":"https://blog.johtani.info/blog/2014/05/14/spiritual-entry1/","publishdate":"2014-05-14T01:44:00+09:00","summary":"酔っ払ってなんとなく書きたくなったスピリチュアルなブログなので、流していただければと。 最近、勉強会やTwitterで知り合いになって話をする","tags":["スピリチュアル"],"title":"外の世界を知るということ"},{"contents":"「アジャイルデータサイエンス」の見本をいただいてしまいました。\nなので、感想文でも書いてみようかと。\nどんな本？ 想像以上に薄かったです、物理的に。 なのに、とても幅広い範囲をカバーしています。\nデータの分析にどんな人が関わっているのか、アジャイルにデータを分析する目的から始まり、 データから何かを見つけるための手順、考え方などをさらっとですが、 システムに取り込む流れから取り込んだあとに改良するという流れまで紹介してくれます。 流れはこんな感じ。\nイベント：ログとかのイベントの発生 コレクタ：イベントの収集 バルクストレージ：イベントの一時保存 バッチ処理：ストレージにあるデータに対して処理 分散ストア：処理結果をWebアプリなどで表示するために保存 Webアプリ：処理結果をユーザに提供 Webアプリでデータを見えるようにして、そこから更にフィードバックを受けることで、データの分析などを進めていくという流れです。\n私はデータサイエンス系の人ではないのでこの流れで作業をされているかはわからないのですが、 検索のシステムについてもこの流れに似ているなと感じました。\n検索システムでも、検索したいデータを収集して、加工（検索したい項目の洗い出しやファセットにする項目の選定とか）して、 インデックスを生成するといった処理が必要になるからです。\nこの本では、Python、Hadoop（Pig）、MongoDB、ElasticSearch（バージョンが0.90だから）、d3.jsなどが出てきます。 また、日本語版の付録では、Fluentd、Kibana+Elasticsearchといった組み合わせの紹介もあります。\nコードも書かれていますが、すみません、そこまでちゃんと読んでません。。。\n後半では、データを活用して行くためには順序があるという話が書かれています。\nレコード：レコード1件のアトミックな処理と表示 グラフ：レコードを元に集計したりグラフ作ったり レポート：関係性やトレンドを抽出し、インタラクティブに探求 予測：構造を利用して、推論やレコメンドとか 行動：上記の結果を元にユーザに行動を促す 前のステップがおろそかだと次のステップがうまくいかないという話です。 後半はこの流れに沿って、先ほどのシステムの流れを変更していく方法が展開されます。\n注意点 ちょっとだけ気になる点があったので。\nElasticsearch周りについては少し注意が必要かと。（Pigとかは詳しくないので不明です。） 紹介されているElasticsearchのバージョンが0.90と少し古いのと、 Hadoopとの統合（Pigで処理したデータをElasticsearchに出力）に利用されているWondordogというツールも最近更新がされていないみたいです。 おそらく、1.0系では動かないのではないかと。\n1.0系の場合は、Elasticsearchが提供しているelasticsearch-hadoopを利用するのが良いと思います。\n付録については1.0系で記載されているので問題ないかと。ただし、Elasticsearchは更新が早いので、公式サイトで最新情報を入手するのが良いと思います。\n感想 データを解析するシステムってどんなことやってるの？という全体像を 俯瞰するのに良い本なのではないかと思います。 また、データの解析を活かすために、必要な順序と疎かにできない点もあって面白かったです。\n紹介されているツール類については、OSSのトレンドや開発速度が早いので、参考程度にとどめておいて、 自分たちで使いやすいものを探してきて検討するのがいいと思います。\n付録がとても豪華です。FluentdやKibanaがわかりやすく解説されてます。\nあと、薄いのでさらっと読めます。ｗ\n","date":1399563900,"dir":"post/2014/","id":"91fe03f994e8e85cede4e3bd62f4d6b7","lang":"ja","lastmod":1399563900,"permalink":"https://blog.johtani.info/blog/2014/05/09/reading-agile-data-science/","publishdate":"2014-05-09T00:45:00+09:00","summary":"「アジャイルデータサイエンス」の見本をいただいてしまいました。 なので、感想文でも書いてみようかと。 どんな本？ 想像以上に薄かったです、物理的に","tags":["感想文","オライリー"],"title":"アジャイルデータサイエンスが届きました"},{"contents":"こんなツイートを見つけたので、Aggregationのサンプルでも書こうかなと。（前から書こうと思ってたんですが。。。）\n@elasticsearch Hi, Would you please tell me the way to do \u0026quot;Pivot Faceting\u0026quot; like Solr-4.0 in elasticsearch-1.1.1 or prior version? Thank you.\n\u0026mdash; Y.Kentaro (@yoshi_ken) 2014, 5月 2 ちなみに、Aggregationは1.0.0から導入された機能なので、ElasticSearch Server日本語版には掲載されていない機能になります。（ごめんなさい）\n公式ガイドのAggregationsのページはこちらになりますが、実例があったほうがいいかなと。\n@yoshi_ken さんから実例のサンプルの指定もいただいたので、ブログを書くのが非常に楽です。ありがとうございます。\n問題 元ネタ（gist）\n次のような不動産系のデータがあるとします。\nid 物件名 都道府県（東京、神奈川、\u0026hellip;..） 物件種別（賃貸、売買、\u0026hellip;..） この時、都道府県別に、物件種別ごとの件数を取得したいという趣旨です。\n東京 賃貸: xxx件 売買: yyy件 神奈川 賃貸: xxx件 売買: yyy件 \u0026hellip; これを、Elasticsearchでどうやって取得するかという問題です。\nインデックスとデータの登録 まずは、インデックスを作ります。 あくまでもサンプルなので、全部not_analyzedにしてますが、そのへんは適宜変更してください。\n# create index PUT /pref_aggs { \u0026#34;settings\u0026#34;: { \u0026#34;number_of_shards\u0026#34;: 2 }, \u0026#34;mappings\u0026#34;: { \u0026#34;japan\u0026#34; : { \u0026#34;_id\u0026#34; : { \u0026#34;path\u0026#34; : \u0026#34;id\u0026#34; }, \u0026#34;properties\u0026#34;: { \u0026#34;id\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;}, \u0026#34;name\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;}, \u0026#34;pref\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;}, \u0026#34;type\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;} } } } } _idを使用して、データ登録時にidフィールドにある文字列をそのままIDとして登録できるように指定してあります。\n登録するデータは次のようなものを適当に100件程度作ってりました。\n{\u0026#34;id\u0026#34;: \u0026#34;id0\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name0\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;01_北海道\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;売買\u0026#34;} {\u0026#34;id\u0026#34;: \u0026#34;id1\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name1\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;09_栃木県\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;売買\u0026#34;} {\u0026#34;id\u0026#34;: \u0026#34;id2\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name2\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;38_愛媛県\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;賃貸\u0026#34;} {\u0026#34;id\u0026#34;: \u0026#34;id3\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name3\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;40_福岡県\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;賃貸\u0026#34;} {\u0026#34;id\u0026#34;: \u0026#34;id4\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name4\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;35_山口県\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;売買\u0026#34;} {\u0026#34;id\u0026#34;: \u0026#34;id5\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name5\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;12_千葉県\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;賃貸\u0026#34;} ... データの登録には、前に紹介した方法「stream2esと複数データの登録」を用いました。\nファセット このようなデータがある場合に、まず思いつくのはファセットによる取得です。 いささか強引ですが。。。\nGET /pref_aggs/japan/_search { \u0026#34;size\u0026#34;: 0, \u0026#34;query\u0026#34;: { \u0026#34;match_all\u0026#34;: {} }, \u0026#34;facets\u0026#34;: { \u0026#34;type_賃貸\u0026#34;: { \u0026#34;terms\u0026#34;: { \u0026#34;order\u0026#34;: \u0026#34;term\u0026#34;, \u0026#34;field\u0026#34;: \u0026#34;pref\u0026#34;, \u0026#34;size\u0026#34;: 50 }, \u0026#34;facet_filter\u0026#34;: {\u0026#34;term\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;賃貸\u0026#34; }} }, \u0026#34;type_売買\u0026#34;: { \u0026#34;terms\u0026#34;: { \u0026#34;order\u0026#34;: \u0026#34;term\u0026#34;, \u0026#34;field\u0026#34;: \u0026#34;pref\u0026#34;, \u0026#34;size\u0026#34;: 50 }, \u0026#34;facet_filter\u0026#34;: {\u0026#34;term\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;売買\u0026#34; }} } } } facet_filterを使用して、typeフィールドによる個別の絞込を行っています。 あとは、prefフィールドのファセットを取得すれば、出力は次のようになります。\n{ \u0026#34;took\u0026#34;: 6, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 2, \u0026#34;successful\u0026#34;: 2, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 100, \u0026#34;max_score\u0026#34;: 0, \u0026#34;hits\u0026#34;: [] }, \u0026#34;facets\u0026#34;: { \u0026#34;type_賃貸\u0026#34;: { \u0026#34;_type\u0026#34;: \u0026#34;terms\u0026#34;, \u0026#34;missing\u0026#34;: 0, \u0026#34;total\u0026#34;: 52, \u0026#34;other\u0026#34;: 0, \u0026#34;terms\u0026#34;: [ { \u0026#34;term\u0026#34;: \u0026#34;00_北海道\u0026#34;, \u0026#34;count\u0026#34;: 1 }, { \u0026#34;term\u0026#34;: \u0026#34;01_青森県\u0026#34;, \u0026#34;count\u0026#34;: 2 }, { \u0026#34;term\u0026#34;: \u0026#34;03_宮城県\u0026#34;, \u0026#34;count\u0026#34;: 3 }, ... }, \u0026#34;type_売買\u0026#34;: { \u0026#34;_type\u0026#34;: \u0026#34;terms\u0026#34;, \u0026#34;missing\u0026#34;: 0, \u0026#34;total\u0026#34;: 48, \u0026#34;other\u0026#34;: 0, \u0026#34;terms\u0026#34;: [ { \u0026#34;term\u0026#34;: \u0026#34;00_北海道\u0026#34;, \u0026#34;count\u0026#34;: 2 }, { \u0026#34;term\u0026#34;: \u0026#34;02_岩手県\u0026#34;, \u0026#34;count\u0026#34;: 1 }, { \u0026#34;term\u0026#34;: \u0026#34;04_秋田県\u0026#34;, \u0026#34;count\u0026#34;: 1 }, ... } 望んでいた形式とは少し異なりますが、facet_filterする回数を少なくするため、 ファセットは都道府県のフィールドを指定したためです。 アプリで頑張って入れ替えてください。。。\nこの場合、\u0026rsquo;type\u0026rsquo;の個数がわかっているので、頑張ってこのような記述ができました。 ただ、typeが増えた時にアプリの修正とかが必要になりますよね。\nAggregations ということで、Aggregationsの出番です。 ファセットよりも柔軟に、検索結果に対していろいろな集計が行える機能になります。 一見に如かずということで、クエリを紹介します。\nGET /pref_aggs/japan/_search { \u0026#34;size\u0026#34;: 0, \u0026#34;query\u0026#34;: { \u0026#34;match_all\u0026#34;: {} }, \u0026#34;aggs\u0026#34;: { \u0026#34;pref\u0026#34;: { \u0026#34;terms\u0026#34;: { \u0026#34;order\u0026#34;: { \u0026#34;_term\u0026#34;: \u0026#34;asc\u0026#34; }, \u0026#34;field\u0026#34;: \u0026#34;pref\u0026#34;, \u0026#34;size\u0026#34;: 50 }, \u0026#34;aggs\u0026#34;: { \u0026#34;type\u0026#34;: { \u0026#34;terms\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;type\u0026#34;, \u0026#34;size\u0026#34;: 10 } } } } } } ファセットよりもシンプルですし、賃貸といったような値を指定していません。 aggsというのがaggregations機能を指定している部分になります。 検索結果は次のように出力されます。\n{ \u0026#34;took\u0026#34;: 4, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 2, \u0026#34;successful\u0026#34;: 2, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 100, \u0026#34;max_score\u0026#34;: 0, \u0026#34;hits\u0026#34;: [] }, \u0026#34;aggregations\u0026#34;: { \u0026#34;pref\u0026#34;: { \u0026#34;buckets\u0026#34;: [ { \u0026#34;key\u0026#34;: \u0026#34;00_北海道\u0026#34;, \u0026#34;doc_count\u0026#34;: 3, \u0026#34;type\u0026#34;: { \u0026#34;buckets\u0026#34;: [ { \u0026#34;key\u0026#34;: \u0026#34;売買\u0026#34;, \u0026#34;doc_count\u0026#34;: 2 }, { \u0026#34;key\u0026#34;: \u0026#34;賃貸\u0026#34;, \u0026#34;doc_count\u0026#34;: 1 } ] } }, { \u0026#34;key\u0026#34;: \u0026#34;01_青森県\u0026#34;, \u0026#34;doc_count\u0026#34;: 2, \u0026#34;type\u0026#34;: { \u0026#34;buckets\u0026#34;: [ { \u0026#34;key\u0026#34;: \u0026#34;賃貸\u0026#34;, \u0026#34;doc_count\u0026#34;: 2 } ] } }, ... Aggregationsの結果は、望んでいた通りの出力になっています。\nクエリの構成を見てみましょう。\n\u0026#34;aggs\u0026#34;: { \u0026#34;pref\u0026#34;: { #1 \u0026#34;terms\u0026#34;: { \u0026#34;order\u0026#34;: { \u0026#34;_term\u0026#34;: \u0026#34;asc\u0026#34; }, \u0026#34;field\u0026#34;: \u0026#34;pref\u0026#34;, \u0026#34;size\u0026#34;: 50 }, \u0026#34;aggs\u0026#34;: { #2 \u0026#34;type\u0026#34;: { \u0026#34;terms\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;type\u0026#34;, \u0026#34;size\u0026#34;: 10 } } } } } 最初の#1のprefは出力を扱いやすくするためにつけているラベルになります。好きな名前をつけることが可能です。 次のtermsがAggregationのタイプ（どのような集計をして欲しいか）になります。 今回は、prefフィールドにある単語(term)毎に、集計をしたいので、termsを指定します。 その他にどんなタイプがあるかは、公式ガイドをご覧ください。\n次に、さらにtypeフィールドで集計したいので、#2の部分で後続のAggregationを指定しています。 都道府県同様、typeフィールドにある単語毎に集計するために、termsを指定します。\nこれで、先ほどのような結果が出力できます。 ちなみに、さらにtypeの中に他の種別で集計したいという場合は、さらにaggsを追加していけばOKです。\nAggregationは非常に柔軟な集計を可能にする機能です。ただし、検索結果に対して集計処理を行っているため、 メモリやCPUなどのリソースを消費するので注意が必要です。\nAggregationの説明については、こちらのFound.noのブログ（英語）がわかりやすかったので参考にしてみてください。\nまとめ 非常に簡単ですが、Aggregationsについて紹介しました。 その他にもAggregationsでできることがあるので、後日別のサンプルを用意して説明しようかと思います。\n100件のデータやここまでの操作については、gistにあるので、興味がある方はご覧いただければと。 stream2esの操作以外は、Marvelに付属のsenseを利用しています。\n","date":1399456620,"dir":"post/2014/","id":"ed4f5a398056eef1cf6caa90786b340a","lang":"ja","lastmod":1399456620,"permalink":"https://blog.johtani.info/blog/2014/05/07/aggregation-example/","publishdate":"2014-05-07T18:57:00+09:00","summary":"こんなツイートを見つけたので、Aggregationのサンプルでも書こうかなと。（前から書こうと思ってたんですが。。。） @elasticsearch Hi, Would you please tell me the way to","tags":["elasticsearch"],"title":"Aggregations - ファセットよりも柔軟な集計"},{"contents":"今日はelasticsearch-kopfのAnalysis画面の紹介です。\n（簡単なところから。。。その３）\nちょっとあいだが開いてしまいましたが、再開です。 メニューのaliasesを選択すると、次のような画面が表示されます。\nAliases画面 Elasticsearchのaliasを画面で確認できます。\nエイリアスは、インデックスに別名をつけることができるElasticsearchの機能です。 １エイリアス＝１インデックスでも良いですが、１エイリアスに対して複数のエイリアスを付与することもできます。 この機能を利用することで、次のようなことが可能となります。\nインデックスの切り替えをアプリ側に意識させずに実施（アプリはエイリアス名に対して検索すればOKなので） 直近１週間のログを検索するためのエイリアスの作成（複数のインデックスを１つのエイリアスに割り当て可能） 特定のルーティングによる検索（特定のデータに対する検索だけに絞るためにfilterを指定する） エイリアスについて詳しく知りたい方は公式ガイドをご覧いただくのが良いかと。\n画面は非常にわかりやすい作りになっているので、特に説明必要ないんですよね。。。\n","date":1399132860,"dir":"post/2014/","id":"2824bef72110575c78aeb979170212b8","lang":"ja","lastmod":1399132860,"permalink":"https://blog.johtani.info/blog/2014/05/04/intro-elasticsearch-kopf-alias-percolator/","publishdate":"2014-05-04T01:01:00+09:00","summary":"今日はelasticsearch-kopfのAnalysis画面の紹介です。 （簡単なところから。。。その３） ちょっとあいだが開いてしまいまし","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（aliases画面）"},{"contents":"kopfの記事の続きも書く必要があるんだけど、こんなツイートを見つけてしまったので。。。\nElasticsearchのBulk APIの仕様、JSONファイルをいい感じに加工して置かなければならないしハマりどころ多い。 http://t.co/hmfycqZlqk\n\u0026mdash; Kenta Suzuki (@suzu_v) 2014, 4月 24 前に思いついたけど、放ったらかしにしてた疑問が再浮上してきたので、せっかくだから調べてみようかなと。\n複数JSONデータがある場合にもっと楽にデータを入れる方法ないかなぁと思って、これかな？というのがあったのですが、 そのまま手を動かさずに放置してたので、一念発起してブログ書いてます。\nBulk APIって？ ElasticsearchはURLにアクセスしてデータを登録できます。 基本的には次のように1件毎の登録になります。\n$ curl -XPUT http://localhost:9200/bookshop/books/1 -d \u0026#39; { \u0026#34;book_id\u0026#34; : 1, \u0026#34;title\u0026#34; : \u0026#34;ElasticSearch Server Japanese Edition\u0026#34;, \u0026#34;price\u0026#34; : 3024, \u0026#34;publisher\u0026#34; : \u0026#34;KADOKAWA\u0026#34; }\u0026#39; これでもいいのですが、大量のデータを登録するときは、Elasticsearch側での効率が悪いです。 そこで、Elasticsearchは大量データを登録するためにBulk APIというものを用意しています。\nこれは、次のような形式のJSONを作ってデータを登録します。\n{ \u0026#34;index\u0026#34; : { \u0026#34;_index\u0026#34; : \u0026#34;bookshop\u0026#34;, \u0026#34;_type\u0026#34; : \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34; : \u0026#34;1\u0026#34; } } { \u0026#34;book_id\u0026#34; : 1, \u0026#34;title\u0026#34; : \u0026#34;ElasticSearch Server Japanese Edition\u0026#34;, \u0026#34;price\u0026#34; : 3024, \u0026#34;publisher\u0026#34; : \u0026#34;KADOKAWA\u0026#34;} { \u0026#34;index\u0026#34; : { \u0026#34;_index\u0026#34; : \u0026#34;bookshop\u0026#34;, \u0026#34;_type\u0026#34; : \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34; : \u0026#34;2\u0026#34; } } { \u0026#34;book_id\u0026#34; : 2, \u0026#34;title\u0026#34; : \u0026#34;Introduction of Apache Solr\u0026#34;, \u0026#34;price\u0026#34; : 3888, \u0026#34;publisher\u0026#34; : \u0026#34;gihyo\u0026#34;} これは、次のような構成になっています。\nコマンド データ コマンド データ ... これで効率よくデータが登録できるのですが、このようなJSONデータを別途作って上げる必要が出てきます。 結局、複数のJSONがあるのに、特殊なJSONを生成しないといけないということでプログラム書いて実行することになります。 これだと、Elasticsearchへのアクセスをプログラムで書くのとあまり大差がないかもしれません。\nstream2es もっとお手軽に複数のJSONを登録できないかな？と目をつけていたのが、stream2esです。\nどんなもの？ Clojureで作られた、Elasticsearchにデータを流し込むためのツールです。 Java 7がインストールされていれば、ダウンロードしてくれば動作せることができます。\nインストール 公式ページに載っている方法そのままです。\n$ curl -O download.elasticsearch.org/stream2es/stream2es; chmod +x stream2es 実行したディレクトリにコマンドがコピーされます。 あとは、コマンドを実行すればOKです。\n実行 データは次のような形式でsample.jsonに保存してあるとします。\n{ \u0026#34;book_id\u0026#34; : 1, \u0026#34;title\u0026#34; : \u0026#34;ElasticSearch Server Japanese Edition\u0026#34;, \u0026#34;price\u0026#34; : 3024, \u0026#34;publisher\u0026#34; : \u0026#34;KADOKAWA\u0026#34;} { \u0026#34;book_id\u0026#34; : 2, \u0026#34;title\u0026#34; : \u0026#34;Introduction of Apache Solr\u0026#34;, \u0026#34;price\u0026#34; : 3888, \u0026#34;publisher\u0026#34; : \u0026#34;gihyo\u0026#34;} 先ほどのBulk APIで利用したJSONよりも、スッキリしていますね。 1行1ドキュメント1JSONです。\nあとは、次のコマンドを実行するだけです。\n$ ./stream2es stdin --target http://localhost:9200/bookshop/books \u0026lt; sample.json ファイルをstream2esに流し込んで、stream2esが1行ずつパースして、Elasticsearchに投げ込んでくれます。\n登録されたデータは次のようになります。 IDは自動で付与されています。\n{ \u0026#34;_index\u0026#34;: \u0026#34;bookstore\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;0Hvy4IJCRkKrvGb4Dgam_w\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;book_id\u0026#34;: 1, \u0026#34;title\u0026#34;: \u0026#34;ElasticSearch Server Japanese Edition\u0026#34;, \u0026#34;price\u0026#34;: 3024, \u0026#34;publisher\u0026#34;: \u0026#34;KADOKAWA\u0026#34; } }, { \u0026#34;_index\u0026#34;: \u0026#34;bookstore\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;b9M6TooFQzGYyJeix_t_WA\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;book_id\u0026#34;: 2, \u0026#34;title\u0026#34;: \u0026#34;Introduction of Apache Solr\u0026#34;, \u0026#34;price\u0026#34;: 3888, \u0026#34;publisher\u0026#34;: \u0026#34;gihyo\u0026#34; } } せっかく、book_idがあるんだし、_idをインデックスの設定に指定します。\n$ curl -XDELETE http://localhost:9200/bookshop $ curl -XPUT http://localhost:9200/bookshop -d \u0026#39; { \u0026#34;mappings\u0026#34;: { \u0026#34;books\u0026#34; : { \u0026#34;_id\u0026#34; : { \u0026#34;path\u0026#34;: \u0026#34;book_id\u0026#34; } } } }\u0026#39; あとは、登録すればbook_idが_idに採用されます。\n{ \u0026#34;_index\u0026#34;: \u0026#34;bookshop\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;book_id\u0026#34;: 1, \u0026#34;title\u0026#34;: \u0026#34;ElasticSearch Server Japanese Edition\u0026#34;, \u0026#34;price\u0026#34;: 3024, \u0026#34;publisher\u0026#34;: \u0026#34;KADOKAWA\u0026#34; } }, { \u0026#34;_index\u0026#34;: \u0026#34;bookshop\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;book_id\u0026#34;: 2, \u0026#34;title\u0026#34;: \u0026#34;Introduction of Apache Solr\u0026#34;, \u0026#34;price\u0026#34;: 3888, \u0026#34;publisher\u0026#34;: \u0026#34;gihyo\u0026#34; } } 複数ファイル ディレクトリに複数のJSONファイルが有った場合は、次のようなコマンドでOK\n$ cat sample_data/*.json |./stream2es stdin --target http://localhost:9200/bookshop/books まぁ、catして流してるだけですが。。。\nダメだったケース JSONが複数行になっているようなデータだとエラーが出てしまいました。\n（jqコマンドで1行に整形したりできるかなぁ？）\nまた、1行に2つのJSONが書いてある場合は、1つ目のJSONをパースしたら、そこでおしまいみたいで、その後に記述されたデータは登録されませんでした。\nインデックスがない場合 stream2esで登録するインデックスがElasticsearchに存在しない場合、stream2esがインデックスを作成してくれるのですが、 この時、シャード数などはstream2es内部に記述があるので注意が必要です。 以下がその設定です。\nindex.number_of_shards : 2 index.number_of_replicas : 0 index.refresh_interval : 5s 課題？ 内部的にはおそらく、Bulkでデータを登録していると思うのですが、まだよくわかっていません。 Clojureが読めないので、せっかくだから、Clojureの勉強も兼ねてちょっとソースを読んでみようかなと思います。 それほど量があるわけでもないので。\nあとは、その他にWikipediaのデータやTwitterのデータ登録、 ElasticsearchからデータをScrollで読み出しつつ、別のElasticsearchに流しこむといったこともできそうなので、そちらも試してみようかと。 他にもオプションがいくつかありそうです。\n今回は2件ほどでしたが、大量データを流し込んだ時にどうなるか（stream2esが悲鳴を上げるのか、Elasticsearchで詰まることがあったらどうなるか）なども 気になるので、なんか適当なデータで試してみるのもいいかなぁと。 （ということで、だれか、いろいろ試してみてもらえると楽できるなぁ。）\n","date":1398341460,"dir":"post/2014/","id":"e396cbf9274b590a1d94ee43d823a0bd","lang":"ja","lastmod":1398341460,"permalink":"https://blog.johtani.info/blog/2014/04/24/usage-stream2es/","publishdate":"2014-04-24T21:11:00+09:00","summary":"kopfの記事の続きも書く必要があるんだけど、こんなツイートを見つけてしまったので。。。 ElasticsearchのBulk APIの仕様、J","tags":["elasticsearch","stream2es"],"title":"stream2esと複数データの登録"},{"contents":"第4回Elsticsearch勉強会を開催しました。 今回から、遅刻厳禁にしてみました。 それほど困った人もいないと思うので、次回からも遅刻厳禁で。\nということで、今回も多数の方にお集まりいただきありがとうございました。\nスタッフの皆さん、スピーカーの皆さん、プレゼント用に書籍を用意してくれたKADOKAWAさん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！ 参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\nさて、ブログですが司会業とかやってたので、あんまり書けてないけど。。。\n134番までチケットがはけていたので＋スタッフで140〜150名くらいの参加者だったのではないかと思います。 懇親会まで残っていただいた方々も片付けなどありがとうございました。\nさて、感想とか補足です。\n「アナライズ処理の仕組みとクエリDSL」株式会社シーマーク　大谷　純　@johtani スライド：アナライズ処理の仕組みとクエリDSL※スライドはPDFです。\nプラグイン：elasticsearch-extended-analyze\nプラグインの紹介記事：http://blog.johtani.info/blog/2013/10/25/developing-es-extended-analyze-plugin/\nMarvel：http://www.elasticsearch.com/marvel/\n日本語版メーリングリスト：https://groups.google.com/forum/#!forum/elasticsearch-jp\nなんか、宣伝（本＋プラグイン）ばっかりですみません。 「プラグインの紹介記事」に簡単な使い方が書いてあります。が、情報が古いので、Elasticsearchのバージョンに合わせたバージョンを使ってください。\nまだまだ発表に慣れてないので、頑張ろ。\nアンケート取ってみましたが、ログ検索と全文検索と半々くらいで興味がある人がいるみたいでした。 あと、有料トレーニングは人気ないっすね。。。\n「elasticsearch-hadoopを使ってごにょごにょしてみる」 株式会社マーズフラッグ R\u0026amp;D部　やまかつ さん　@yamakatu スライド：elasticsearch-hadoopを使ってごにょごにょしてみる\nelasticsearch-hadoop：https://github.com/elasticsearch/elasticsearch-hadoop\nQAとして、Elasticsearchにプライマリデータを保存するのは的な話が出てました。 ESにのみデータを入れるのは個人的には考えたことないかなぁ。 どうしても、ElasticsearchのWriteが遅いんじゃないかという懸念事項を持ってる人がいるなぁと。（実際ツラいという話もちらほら）\nお腹痛い中の発表ありがとうございました。。。 次回はMapRの方に紹介してもらえそう（交渉中）なので楽しみです。やまかつさんの続きも聞きたいなぁ。\n「CouchbaseとElasticsearchが手を結んだら」株式会社アットウェア 佐竹雅央さん @madgaoh 河村康爾さん @ijokarumawak スライド：CouchbaseとElasticsearchが手を結んだら\nCouchbaseのElasticsearchに関するページ：http://docs.couchbase.com/couchbase-elastic-search/\nCouchbaseに入れたら、自動的にElasticsearchにもデータを入れてくれる。 デモがあるの、いいっすね。\n最新版はmasterを落としてきてビルドしないとダメらしい。確かに、上のページには0.90.5って書かれてる。 ここでも、やはり、Elasticsearchが詰まった時にどうするの？みたいな話が出てました。 CouchbaseのXDCRだと、後ろが詰まってる時によしなに？データを流すのを制御してくれるってのがあるみたいですが、 Elasticsearchだと悲鳴を上げているのがわかりにくいと。\nあと、Elasticsearchがインデキシングでキューを取りこぼしているのがログからわかりにくいってのも出てました。 （なにか、分かる方法があるかとかも調べてみようかなぁ。）\n自分の宿題：Transportプラグインって何かについて調べてブログに書くこと。\n「Elasticsearch at Wantedly」（タイトルあってるか不安）　Wantedly, Inc 内田誠悟さん @spesnova スライド：Elasticsearch at Wantedly\n参考文献：Elasticsearchチュートリアル\n参考文献：Elasticsearch Workshop\n参考文献：elasticsearch-rails\nWantedlyでどうやって使ってるのか。 あと、オートコンプリートでも使ってます。（この話は次回聞けるといいなぁｗ）\nデータ数は少ないので、参考にまだならないかも。\n公式のサイト見難いですよねと。 ペンギン先生のブログが素晴らしかった！ マッピングすごいｗ\n最後は、苦労して作ってもらったautocompleteの資料は放ったらかしにして、質疑応答してもらいました。 辞書とか、検索漏れとかの話は今後の課題っぽかったですね。\n「Elasticsearchのみに決めてました！」ってセリフがカッコ良かったｗ\nアクセスコントロール周りのノウハウもブログで共有してくれそうなので楽しみにしています！\nあと、「tireがretire」の話が出てましたが（この発表だっけ？）参考文献にあげてある、elasticsearch-railsが今は本流なんじゃないかなぁ？\nLT ###「ElasticsearchのScripting」株式会社富士通ソフトウェアテクノロジーズ 滝田聖己さん @pisatoshi\nスライド：ElasticsearchのScripting\n参考文献：elasticsearch-native-script-example\n色々とScriptがあるという話を説明してもらい感謝です。 もちろん、ElasticSearchServerにも書いてあるので、そちらも参考にしてください！\n「Elasticsearch 向け多言語解析プラグイン」ベイシス・テクノロジー株式会社 江口天さん スライド：Elasticsearch 向け多言語解析プラグイン\n参考文献：Elasticsearchで使えるRosette基本言語解析モジュール\n参考文献：Elasticsearch-inquisitorプラグインの紹介\nベイシステクノロジさんが提供しているRosetteをElasticsearchで活用できるモジュールみたいです。 いまなら、無料で体験できるみたいなので、どんなものか触ってみると面白いかもしれません。\nあと、デモで使用されていたプラグインについて、私が昔に書いた記事があるので、興味のある方は参考にしていただければと。 このプラグインはクエリがどのように内部でLuceneのクエリになっているか、どのフィールドでどうトークンが生成されるか？ といったものが見ることができるプラグインになっています。\n関連ブログ 適当に見つけたブログを列挙してあります。これもあるよ！などあれば、教えてください。\n勉強会メモ - 第4回elasticsearch勉強会 2014/04/21\ntogetter 第4回elasticsearch勉強会 #elasticsearchjp\n参加レポート:第4回elasticsearch勉強会 #elasticsearchjp\n第4回elasticsearch勉強会に参加しました\nまとめ しつこいくらい宣伝してしまいましたが、「ElasticSearch Server日本語版」よろしくお願いします！\n今回も楽しい話が聞けました。メモがちょっと少ないんですが。。。\n次回は6末を目処に、MapRの方などと調整して開催しようと思います。 聞きたい話とか、発表したい方とかあれば、連絡くださいー！\n","date":1398077040,"dir":"post/2014/","id":"50562b09417cd8c4a2348a0a5aabe754","lang":"ja","lastmod":1398077040,"permalink":"https://blog.johtani.info/blog/2014/04/21/hold-on-4th-elasticsearch-jp/","publishdate":"2014-04-21T19:44:00+09:00","summary":"第4回Elsticsearch勉強会を開催しました。 今回から、遅刻厳禁にしてみました。 それほど困った人もいないと思うので、次回からも遅刻厳禁","tags":["elasticsearch","勉強会"],"title":"第4回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"今日はelasticsearch-kopfのAnalysis画面の紹介です。\n（簡単なところから。。。その２）\nメニューのanalysisを選択すると、次のような画面が表示されます。\nAnalysis画面 Elasticsearchの_analyze APIを画面で確認できます。 画面で動作の確認ができるのは嬉しいですよね。\n入力文字列：入力となるドキュメントに含まれる文字列や検索キーワードを入力 フィールドの指定：対象とするインデックス名、タイプ名、フィールド名を選択 analyze：ボタンを押す トークナイズされた結果：入力文字列がどのようなトークンに分割されるか start、end：入力文字列中の文字列の位置 pos：トークンの位置 という形でElasticsearchが指定されたフィールドで入力文字をどのようにトークナイズしたかを確認することができます。\nElasticsearchは内部でこのトークナイズされた単語を元に転置インデックスを作成し、検索に利用します。 ですので、特定のデータが検索に上手くヒットしないときに、この画面でデータの文字列をトークナイズしてみるといった用途に使えます。\nフィールドの設定がどのようにして入力文字列をトークンにしているかといった点については、今度のElasticsearch勉強会で話す予定です。\nフィールドの設定を利用する以外に、アナライザを指定してどのようにトークナイズされるかを見ることもできます。 「ANALYZE BYANALYZER」をクリックすると利用できます。\nANALYZE BY ANALYZER トークナイズしたい文字列を入力し、インデックス名と、インデックスに設定されているアナライザ名を選択してanalyzeボタンを押すと 結果が表示されます。 （例では、kuromojiアナライザを利用して出力になっています。また、出力結果のposの表示位置がFIELD TYPEの時と違うのが少し気になりました。）\nただ、残念ながら、インデックスのマッピングで指定したアナライザしか利用できないみたいなので、 どのアナライザがどんな挙動かを調べたい場合は、以前紹介したelasticsearch-inquisitorを 利用したほうが良さそうです。\nということで、今日はanalysis画面の説明でした。\n","date":1397011260,"dir":"post/2014/","id":"76a1fb7f21fda9eddb95426b65124517","lang":"ja","lastmod":1397011260,"permalink":"https://blog.johtani.info/blog/2014/04/09/intro-elasticsearch-kopf-analysis/","publishdate":"2014-04-09T11:41:00+09:00","summary":"今日はelasticsearch-kopfのAnalysis画面の紹介です。 （簡単なところから。。。その２） メニューのanalysisを選択","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（analysis画面）"},{"contents":"JVM Operation Casual Talksに参加しました。 あんまり、運用とかやってないので、ついていけるか不安ですが、楽しそうだったので。 懇親会は予定されてないらしい。\n@stanaka\t15分でわかるJVMのメモリ管理 スライド：https://speakerdeck.com/stanaka/understanding-memory-management-of-javavm-in-15-minutes\nJVMの基礎知識\n某研究所で。。。\nElasticsearch、Solrの名前が！\nJVM困りどころ。ネットの情報が古いのが多いとか。\n使いこなすにはきちんと知識が必要。\nMemory Model 困ったらJava8に。。。\nHeapのチューニングが重要\nHeapの構成やGC処理の説明\nCMSでもすべて並列ではない\nOlgGenがフラグメントして確保が遅くなっていく G1GCの概念図。YoungやOld、Survivorの区別がない？\nリージョン？ リファレンスリストすばらしい。\n@oranie\tCassandra運用で実施しているJVM監視について スライド：http://www.slideshare.net/oranie/jvm-operation-casual-talks-33218856\nCassandra(1.1)で運用中。 35TBとか エンジニアブログ読め。 Cassandraの監視って何すればいいの？ GC頻度とかグラフで見れる VisualVM便利って教えてもらった。 VisualVMでどんな値があるか見ながら調べて、取りたい値を考える。 SNMPで頑張るの辛い＝JMXかな？＝Javaで叩くの？＝Jolokia どんなことやってる？ Nagios+Jenkins＋。。。あとでスライド yohoushi+GrowthForecastも便利。 @waysaku\tSpray(Akka)運用でJVMをCPUスケールさせるために行った事 スライド：http://www.slideshare.net/waysaku/jvm-operation-casual-talks\nSpray Akkaアプリケーションの運用を任されちゃった人 カットオーバー直前の負荷試験でびっくりするくらいスループットでない。。。 いろんなActorが特定のActorに処理を投げた状態で待ってるという状況。。。 スレッドダンプ追っかけてる様子を追体験してる。 ログ出力がBLOCKしてた I/Oを伴う処理は非常にセンシティブ 以下、LT @oinume\t運用に効く！JVMオプション三選 スライド：http://www.slideshare.net/oinume/jvm-operationcasualtalks20140407\nサーバに入らなくても見れるのは VisualVM 最終形Java Mission Control Flight Recorder（商用だと有償） @y_uuki1\tなにもわからないところから始めるJVMモニタリング スライド：https://speakerdeck.com/yuukit/nanimowakaranaitokorokarashi-merujvmmonitaringu\nブログ：http://yuuki.hatenablog.com/entry/2014/04/08/074507\nなんでここにいるかわかりませんが。 色んな所記事とかのリンクがある。 Graphiteに放り込んでるらしい。 @tagomoris\tNorikraのJVMチューンで苦労している話 スライド：http://www.slideshare.net/tagomoris/norikrajvm\nNorikraで困ったので開催したらみんなしゃべりに来てくれてありがたい世の中ですね。 デフォルト設定で運用。mx4096mで4ヶ月は元気に動いてた 年末に崩壊 -\u0026gt; harukaさんのQiita見ながら設定してほったからした。 3月にまた崩壊OOM SoftRefが悪さしてるのか？ nekopさんのブログにヒントが。 @shot6\tJVM的なナニカを話す、GC戦略をそえて スライド：http://www.slideshare.net/shot6/jvm-33248312\n某A社からきました。 CMSを中心が良い CPUコア少ないとCMS Incremental G1GCは6GB以上とかもっと大きい場合のほうが良さそう（雑感） 基本的に、ドキュメントに書いてあるけど、つらいので、まとめてみました。 後で見たいな、このスライドも。 @kazeburo\tWebアプリケーションとメモリ スライド：http://www.slideshare.net/kazeburo/jvm-casual\nJavaは1行も書いたことありません。 Java運用したけど、まぁ、ひどい目にあってます。 ということで、PerlとApacheの話？ bumpyなんとかってのは頭良くプロセスの処理回数とかをなんとかしてくれる JVMとかどうなの？ ということで、CA社の人が釣れたので良かったですね。 TBD\tJVMの運用について話す会(パネル) なんでJVM？\n全文検索だとJVMだなぁ。SolrとかElasticsearchとか 入社したらあった。 JVMこまったところは？\n突然Dioが出てくる JVMいいところは？\nうーん、あえて言うと。。。スレッド処理 型がある言語を調べるとJVM。というよりScala。 飛び入り参加。落ちないところ。人殺しは良くないｗ 簡単には殺せないところに使えるのは良いのでは。 チューンはどこまでやる？\n7,8割でやめたほうが良い？ そんなに突き詰めなくてもいいのかな。 Cassandraだと、FullGCが走ってる時点で再起動しかない場合が多いです。 言語のランタイムについてチューンすることってJVMの他ある？\nRubyくらい？ 自分たちで何とかできないものを相手にしている人たちは苦労してるんじゃないか\nCaなんとかさんとかHBなんとかさんは困ってる人が多い 最後に一言\nモニタリングツール参考にしたい 最後に 「やりたくなったら誰かやってください。」ということみたいです。\n基礎から監視まで結構幅広くキーワードが出てきたので楽しかったです。\nその他に話に出てきてた方のブログもリンクしとこうかな。\nnekopの日記\n","date":1396866240,"dir":"post/2014/","id":"299abcee56b05b312ed5700f686f79b8","lang":"ja","lastmod":1396866240,"permalink":"https://blog.johtani.info/blog/2014/04/07/attend-jvm-casual-1/","publishdate":"2014-04-07T19:24:00+09:00","summary":"JVM Operation Casual Talksに参加しました。 あんまり、運用とかやってないので、ついていけるか不安ですが、楽しそうだったので。 懇親会は予定されてないらしい","tags":["JVM","Java","勉強会"],"title":"JVM Operation Casual Talksに参加しました #jvmcasual"},{"contents":"今日はelasticsearch-kopfのREST画面の紹介です。\n（簡単なところから。。。）\nメニューのrestを選択すると、次のような画面が表示されます。\nElasticsearch自体が、さまざまな操作をRESTでできる仕組みになっています。 検索にも利用しますが、それ以外の設定などにつてもリクエストを送ればOKです。\nですので、リクエストや設定を自分で組み立てて送ることができる画面が用意されているととても便利です。 （もちろん、curlコマンドでもいいのですが、画面があると便利ですよね）\nREST画面 History 履歴表示画面です。 これまで、kopfのrest画面を利用して送信したリクエストが一覧で表示されます。\nHistoryという文字をクリックすることで、表示/非表示の切り替えが可能です。（最初は非表示） マウスオーバーすると、リクエストボディがポップアップで表示されます。\nHistory 履歴にあるURLはクリック可能で、クリックすると実行されます。 履歴はlocalStorageに保存されるみたいです。（ブラウザの仕様？あんまり詳しくないので。。。） たぶん、30件が上限かと（ソースで確認しただけ）\nURL rest画面でリクエストを送信する先のURLを指定します。 メソッドは右側のSELECTで選択可能です。\nリクエストパラメータも指定が可能です。\nリクエストボディ 検索や設定のJSONを記述するところです。 一応、JSON的にエラーがある場合は行数の左側にバツ印が出てきておかしなところもわかるようになっています。\nインデントなどは行ってくれますが、senseみたいな補完などはないので、少し辛いところです。\nレスポンス 送信したリクエストに対するレスポンスが返ってきます。 インデントされた状態で表示されるので読みやすいかと。 また、入れ子になっているJSONについては、閉じたり開いたりすることも可能です。 （開始のカッコの右側に-が表示されていて、クリックすると閉じることができます。閉じると+に変わります）\n簡単ですが、rest画面の説明でした。 KOPFを使っていて、ちょっとしたクエリを送ったりするのには便利だと思います。\n複雑な検索クエリなどについては、やはりsenseを使うのが良いかと思いますが。。。\n","date":1396837440,"dir":"post/2014/","id":"670744b945088de05866864f7d57bee7","lang":"ja","lastmod":1396837440,"permalink":"https://blog.johtani.info/blog/2014/04/07/intro-elasticsearch-kopf-rest/","publishdate":"2014-04-07T11:24:00+09:00","summary":"今日はelasticsearch-kopfのREST画面の紹介です。 （簡単なところから。。。） メニューのrestを選択すると、次のような画面","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（rest画面）"},{"contents":"なんだか、ドタバタしてて久しぶりの更新です。 ベルリンの旅行記みたいなのも書きたいのですが、まずはこちらかと。\nelasticsearch-kopfプラグインの紹介です。\n今回は概要の説明だけになります。機能が結構多いので。\nelasticsearch-kopfとは？ _siteプラグインの一つで、クラスタ管理用のプラグインになります。 headプラグインやHQプラグインと同様です。\nプラグインの画面 このようにシンプルな画面で、スッキリとしています。 緑を基調にした画面構成はElasticsearchの緑色を意識してるんでしょうか？\n上記の画像に簡単なコメントを入れてあります。\nメニュー KOPF：KOPF自体の設定（接続先とリフレッシュインターバルの変更） cluster：クラスタ管理、情報（デフォルト表示画面） rest：RESTリクエスト送信、結果表示画面 aliases：エイリアス管理 analysis：analysis API percolator：パーコレータ管理 warmup：ウォームアップクエリ管理 上記のようなメニューです。各メニューについては、今後のブログで少しずつ紹介しようかと。 このメニューの色が、クラスタの状態も表しています。ステータスがYELLOWなら黄色、REDなら赤色に変わります。\nインデックス インデックスは列として表示されます。先ほどの画像では、2つのインデックスが表示されている状態です。 インデックス毎に、シャードも表示されます。これは、各ノードがどのシャードを保持しているかという情報です。 色の濃いシャードがプライマリでしょう。 インデックス名やシャードの箱はクリックできるようになっていて、それぞれの情報がJSONで表示されます。 その他にもドキュメント数、サイズなども表示されます。 インデックスの各種操作（closeやdeleteなど）もここからメニューが表示されます。（これも次回詳しく）\nノード ノードの情報が行として表示されます。ノードが増えると下に追加されていきます。 node1というのが、ノード名です。（ヒーローの名前とかが出てくるやつです。）\nその他に、IPアドレス、ポート番号、負荷、ヒープサイズなども表示されています。 電源ボタンはノードのシャットダウンを行うためのボタンです。（確認用のダイアログが表示される）\nその他 その他に、クラスタの概要として、ノード数、インデックス数、シャード数、ドキュメント数なども表示されます。 インデックスの作成などは、アイコンから操作が可能です。 大規模なクラスタを管理している場合、検索ボックスを利用することで、インデックス名やノード名による絞込もできるようになっています。\n感想 シンプルな構成の画面で、個人的にはheadよりも好きな画面です。 HQよりもシャードの分散具合がわかりやすいので、今後はこのプラグインを利用していこうと考えています。\nまずは、簡単な紹介です。今後、各画面についてもう少し説明をブログに書いていこうかと考えています。 待てない方は、触ってみてもらうのが良いかと。 もちろん、続きを書いてもらってもいいですよ！！\n","date":1396707480,"dir":"post/2014/","id":"c1241374502f200cf9fc49c8d6fb5822","lang":"ja","lastmod":1396707480,"permalink":"https://blog.johtani.info/blog/2014/04/05/intro-elasticsearch-kopf-1/","publishdate":"2014-04-05T23:18:00+09:00","summary":"なんだか、ドタバタしてて久しぶりの更新です。 ベルリンの旅行記みたいなのも書きたいのですが、まずはこちらかと。 elasticsearch-ko","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（概要）"},{"contents":"先日、「ElasticSearch Serverを翻訳しました」という記事を書きました。\nこの中で電子版も出ますよと書いていましたが、電子版も発売されたので、再告知も兼ねてブログを書いています。\nなお、最近よく「ElasticsearchのSは小文字」とツイートしていますが、本書は原著のタイトルが「ElasticSearch Server」となっているため、Sは大文字になっています。原著が出版された時期にはまだSが小文字に統一されていなかったためです。\n紙の書籍はすでに書店に並んでいたり、Amazonでも発送されているようです。\n私自身が電子書籍が場所を取らなくて好きというのもあり、電子版も出版していただけるようにお願いしていました。\n電子版についてはAmazonでKindle版、達人出版会からEPUBとPDFが購入可能です。\n達人出版会のElasitcSearch Serverのページ AmazonのKindle版ページ こちらのリンク（Amazonはアフィリンク）を参考にしていただければと。\n書籍の写真入りツイートしたら、原著者の方からレスを頂きました。\n@johtani Thanks for the great work out there :)\n\u0026mdash; Rafał Kuć (@kucrafal) 2014, 3月 23 また、原著者のサイトでも紹介してもらいました（結構うれしい）。 私が窓口をやっていた関係で、私の名前しか入っていませんが。。。 編集者と翻訳者の方々のお陰で良い本が出版できたと思っています。\nThanks for sharing! / ElasticSearch Server book in Japanese | ElasticSearch Server Book Blog http://t.co/fhCP1vVBd3\n\u0026mdash; Jun Ohtani (@johtani) 2014, 3月 24 ということで、Elasticsearchの導入の手助けになればと。 感想（賛否問わず）など、あればコメント、ツイート、ブログなど書いていただければうれしいです。 （その際に、連絡してもらえるとさらにうれしいです）\n","date":1395722580,"dir":"post/2014/","id":"d51032bef3e7117a94336fea18a3fad7","lang":"ja","lastmod":1395722580,"permalink":"https://blog.johtani.info/blog/2014/03/25/release-elasticsearch-server-ja-ebook/","publishdate":"2014-03-25T13:43:00+09:00","summary":"先日、「ElasticSearch Serverを翻訳しました」という記事を書きました。 この中で電子版も出ますよと書いていましたが、電子版も発","tags":["elasticsearch"],"title":"ElasticSearch Server日本語版（電子版も）が発売されました"},{"contents":"GOTO Night elasticsearchに参加しました。 初の海外の勉強会です（海外自体が初だし）。\nベルリンにあるWoogaという会社で開催された勉強会です。\nFull house at the #gotonight about @elasticsearch in the auditorium of @wooga pic.twitter.com/r2Vx2aMcEn\n\u0026mdash; GOTO Berlin (@GOTOber) 2014, 3月 18 会場はこんな感じで、とってもおしゃれです。（なんか、写ってますね、最前列にｗ） ベルリンの古い建物をリノベーションしたオフィスみたいで、そこにこういったひな壇を用意して発表するスペースにしているみたいです。\n内容としては、Elasticsearch1.0の新機能の話として、snapshot/restore、cat、aggregationなどの話題でした。簡単にどういったものかの説明です。\n一人目の発表が終わったら、ブレイクタイムとして上のフロアに用意されている軽食＋ドリンクで軽く交流の時間が用意されていました。 ベーグルなどのサンドイッチとハイネケンやクラブマテ？と呼ばれるチープなレッドブルとかが飲めました。\nちょっと食べて談笑したあとに、次はLogstashとKibanaのお話でした。Logstashってどんなもの？という話がメインで、Kibanaは簡単な紹介という感じでしょうか。最後に、ライブデモがありました。 Kibanaを使ったライブデモはインパクトがあるなというのが感想です。 フィールド名の補完をしてくれたりと便利な機能が操作をしているところでわかるので。\nYoutubeなどでも見てても思っていた感想ですが、こちらの勉強会は質問が結構出てきます。 今日参加した勉強会も質疑応答が結構されてました。\nelasticsearchの方たちと少しだけ話しをできたので、かなり興奮気味でブログを書いています（ミーハー）。\nただ、やっぱり英語のヒアリングがまだまだだなぁとも実感出来ました。 場数踏むしかないと思うので少しずつ耳にしてなれるしかないかなぁと。 はぁ、ちゃんと高校とか大学の頃に単語を覚えとくんだったと軽く後悔。\nこんなツイートもしてもらって、興奮気味です。明日早起きしないといけないので寝ないといけないのにｗ\nMeeting @johtani finally in #berlin watching @spinscale talking about #elasticsearch\n\u0026mdash; Simon Willnauer (@s1m0nw) 2014, 3月 18 ","date":1395151860,"dir":"post/2014/","id":"65453a1ae403679bd2e47398a04205ca","lang":"ja","lastmod":1395151860,"permalink":"https://blog.johtani.info/blog/2014/03/18/attend-goto-night-elasticsearch/","publishdate":"2014-03-18T23:11:00+09:00","summary":"GOTO Night elasticsearchに参加しました。 初の海外の勉強会です（海外自体が初だし）。 ベルリンにあるWoogaという会社で開催された勉強会","tags":["elasticsearch","勉強会"],"title":"GOTO Night elasticsearchに参加しました"},{"contents":"Berlinからおはようございます。\nということで、人生で初めての海外に来ています。\n人生初の海外なのに、一人で乗り換えがあるようなBerlinに来ています。 今年はチャレンジの年になりそう。初めてづくしですが、楽しみたいなと。 会社に感謝です。ESのトレーニングを受けに来たのがメインなのです。 ついでに、Berlinでの勉強会にも参加してみようかなと。\n幸いにも時差ボケはなさそうなので、色々と見て回ろうと思います。 ただ、日曜日はお店が軒並みしまってそう。。。\n","date":1394916660,"dir":"post/2014/","id":"abc5ca9856a61831fd4ed06b402875d2","lang":"ja","lastmod":1394916660,"permalink":"https://blog.johtani.info/blog/2014/03/16/post-from-berlin/","publishdate":"2014-03-16T05:51:00+09:00","summary":"Berlinからおはようございます。 ということで、人生で初めての海外に来ています。 人生初の海外なのに、一人で乗り換えがあるようなBerlin","tags":["misc","travel"],"title":"Berlinからおはようございます"},{"contents":"elasticsearchに、このへん入れるときっと幸せになれるはず・たぶん。\u0026#10;elasticsearch/elasticsearch-analysis-kuromoji/1.6.0\u0026#10;oyrusso/elasticsearch-HQ\u0026#10;mobz/elasticsearch-head\n\u0026mdash; toshi_miura (@toshi_miura) 2014, 3月 5 こんなツイートを見かけたので、普段入れてるプラグインを簡単に紹介してみようかと。\nローカルの環境に普段入れているプラグインの紹介です。 ちゃんとクラスタを管理しているというよりは、最新版の動作などを確認するための環境になります。なので、ちょっと視点が異なるかもしれませんが参考になればと。\nelasticsearch-analysis-kuromoji URL : elasticsearch-analysis-kuromoji\nKuromojiという日本語形態素解析のTokenizerなどを使えるようにするためのプラグインです。 今度、発売される「ElasticSearch Server」日本語版には付録として、利用方法を執筆しました。参考にしていただければと。 READMEにもサンプルは掲載されてるので、こちらを参考にするのもありですが。\nelasticsearch-extended-analyze URL : elasticsearch-extended-analyze\n私が開発しているプラグインです。 ElasticsearchにはanalyzeというAPIが用意されています。 文章を渡すと指定したanalyzerなどでどのような単語に区切られるかがわかるAPIです。\nただ、analyzerの内部ではchar filter、tokenizer、token filterという個別のパーツがそれぞれ入力された文字列に対して処理を実施します。 この過程がanalyze APIではわかりません。 それをわかるようにしてみたのがelasticsearch-extended-analyzeプラグインになります。\n詳細については過去の記事を見ていただければと。 画面があると便利だよなぁと思いつつ、作ってない。。。\npolyfractal/elasticsearch-inquisitor URL : elasticsearch-inquisitor\nクエリのデバッグとかに便利なプラグイン。\nこちらも詳細は過去の記事を見ていただければと。\nmobz/elasticsearch-head URL : elasticsearch-head\nクラスタ管理に便利なプラグインです。クラスタに存在するノードに対してインデックスのデータ（シャード）がどこに配置されているかなどが一目瞭然になる便利なプラグインです。 プライマリシャードやレプリカなどもわかります。 インデックスの削除もできるし、クエリを投げることもできるし、全部入りな感じのプラグインです。\n私個人は、シャードの配置を見るのに主に利用しています。クエリを投げたりインデックスを消したりするのには殆ど使っていません。\nroyrusso/elasticsearch-HQ URL : elasticsearch-HQ\nこれも管理系のプラグインです。こっちのほうが個人的にスッキリしていて好きなプラグインです。 インデックスの管理やノードの停止などはこちらを主に使用しています。 あくまでもローカルの簡易クラスタを管理する目的というのもあります。\npolyfractal/elasticsearch-segmentspy URL : elasticsearch-segmentspy\nこちらはモニタリングでしょうか。 ElasticSearch Serverで紹介されていたのが主な理由で、入れてますがあんまり見てないかも。 インデックスのSegment単位の情報が見ることが可能です。 あと、ちょっと更新されてない感じがしますね。\nelasticsearch/marvel Elasticsearch社から提供されている、モニタリングなどに使えるプラグインです。 開発環境では無償提供という感じです。 渡しの場合、モニタリング目的ではなく、senseと呼ばれるクエリの補完をしてくれるツールの目的のために使用しています。 モニタリング部分を停止する方法とかないかなぁ。\n詳細については過去の記事を参考にしていただければと。\nまとめ？ ということで、簡単にローカルに入っているプラグインの紹介でした。 他にもいっぱいあるので、おすすめがあれば、教えてもらえると助かります。\n","date":1394515380,"dir":"post/2014/","id":"386dc9d1b647a9f3965f1fbe29c7dfb9","lang":"ja","lastmod":1394515380,"permalink":"https://blog.johtani.info/blog/2014/03/11/es-plugin-installed-to-my-env/","publishdate":"2014-03-11T14:23:00+09:00","summary":"elasticsearchに、このへん入れるときっと幸せになれるはず・たぶん。\u0026#10;elasticsearch/elasticsearc","tags":["elasticsearch","plugin"],"title":"いつも入れているElasticsearchのプラグイン"},{"contents":"第3回Elasticsearch勉強会で、軽く触れていましたが、ElasticSearch Server日本語版が発売されます。 ツイートなどもちらほらとして頂いているみたいで嬉しい限りです。\n本書は、私自身、初の翻訳本となります。\nなお、ElasticSearchはAWSのサービスではなく、全文検索・解析サーバのOSSです\n内容、概要 PacktPublishingから発売されているElasticSearch Serverの日本語版となります。 以下の点が、原著とは異なる点になっています。\n0.90.xに対応（原著は0.20） Kibana、Kuromojiに関して追記 もちろん日本語 残念ながら、つい最近、Elasticsearchについては1.0がリリースされました。 1.0で追加された機能（SnapshotやRestore、Aggregatorなど）については触れていませんが、Elasticsearchの機能を網羅的にカバーした良書となっています。 どんな機能があるのか、どんなプラグインがあるのか、どういったことに使えるのかなど、幅広くまとめられた本になっていますので、 Elasticsearchに興味がある方はぜひ読んでいただければと思います。\nまた、現段階では予定ですが電子版の出版も予定されています。電子版が気になる方は、少しお待ちいただければと。\nElasticSearch？Elasticsearch？ 1.0.0がリリースされた現在は、Elasticsearch（SearchのSは小文字）が正式な名称となっています。 ただ、原著が発売された当初（2013年2月時点）では、まだSは小文字と大文字が混在した状況でした（コミットログなどを見るとわかります。） このため、日本語版でもElasticSearchという表記に統一してあります。\n翻訳に関して 初の翻訳書ということもあり、大変でした。英語に精通しているわけではないので（むしろ苦手）。。。 他の翻訳者の方々には大変助けていただきましたし、勉強になりました。 また、監修社であるリクルートテクノロジーズにも色々とサポートしていただき、感謝の限りです。 （Elasticsearch勉強会の開場提供にも協力して頂いています。）\nわかりにくい日本語となっている部分などありましたら、ご指摘いただければ今後の参考にさせていただきます。 英語やElasticsearchについて、学ぶという目的もあって、本書の翻訳を買って出たのが本音です。\n翻訳作業について Githubのリポジトリを編集の方に用意してもらい、翻訳原稿を管理、校正していきました。 Github自体をあまり触っていなかったので、作業をしながらGithubも覚えられ一石二鳥でした。 Issueやプルリクエストによる校正、チェックも便利ですね。 他の原稿を書くようなことがあれば、またこの経験を活かしていきたいなと。 （翻訳の進め方や原稿のチェックなどについてはまた後日何か書こうかと。）\n原著について 原著のサイトが用意されています。 http://elasticsearchserverbook.com/elasticsearch-server-errata/\n原著を翻訳するにあたって見つけた、誤植などを報告し、掲載して頂いています。 原著をお持ちの場合はこちらも参考にしていただければと思います。\nご購入はこちらから ということで、簡単ですが書籍の紹介（というより宣伝！？）でした。 Elasticsearchに関する何かしらの助けになる書籍であれば嬉しい限りです。\n「ElasticSearch Server日本語版」をよろしくお願いします。 （もちろん、購入は下のリンクからですよね！）\n","date":1393836900,"dir":"post/2014/","id":"9ad72c2a5157f21741bd4581a562dfc7","lang":"ja","lastmod":1393836900,"permalink":"https://blog.johtani.info/blog/2014/03/03/release-elasticsearch-server-japanese-edition/","publishdate":"2014-03-03T17:55:00+09:00","summary":"第3回Elasticsearch勉強会で、軽く触れていましたが、ElasticSearch Server日本語版が発売されます。 ツイートなども","tags":["elasticsearch"],"title":"ElasticSearch Serverを翻訳しました"},{"contents":"今年初の「突撃！隣のElasticsearch」ということで、Wantedlyさんにおじゃましました。\n※写真を自分でも撮ったのですが、画像が壊れてたので、一緒に行ったペンギン先生の写真を拝借しました。\n第3回のElasticsearch勉強会を開催中にES使ってるってツイートを見つけたので、アタックかけて遊びに行きました。 交渉に快諾いただきありがとうございました！\nWantedlyさんがどのようにElasticsearchを使用されているかはきっと、ブログを書いてくれると思うので期待しておくとして、書いてくれました！！ 「実践！Elasticsearch」 そこで、nestedでハイライトがなんかうまくいかないって話があったので、ちょっと調べてみました。 （※まだ、調査中です）\n前提条件 再現する手順はgistにあります。（Senseに貼り付ければ動作します。ただし、elasticsearch-analysis-kuromojiが必要です。）https://gist.github.com/johtani/9184287\nなお、このマッピングやデータはWantedlyさんとは全く関係ありません。\nnestedフィールド内部のデータに対して、検索しハイライトしようとするとうまく動作しないという状況です。 マッピングは以下のとおり。\n\u0026#34;books\u0026#34; : { \u0026#34;properties\u0026#34;: { \u0026#34;book\u0026#34; : { \u0026#34;type\u0026#34;: \u0026#34;nested\u0026#34;, \u0026#34;properties\u0026#34;: { \u0026#34;title\u0026#34; : { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34;, \u0026#34;store\u0026#34;: \u0026#34;no\u0026#34;}, \u0026#34;contents\u0026#34; : {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34;, \u0026#34;store\u0026#34;: \u0026#34;yes\u0026#34;} } } } } } このマッピングの特徴は以下のとおり。\n_sourceは保存される（デフォルト値） bookがnestedなオブジェクト titleはstore : no contentsはstore : yes 動作の挙動をわかりやすくするため、titleとcontentsのstore属性に違いを持たせてあります。\n問題点 nestedクエリを使って、検索した時にハイライトが返ってきません。 次のクエリを実行するとわかります。\nGET /bookstore/books/_search { \u0026#34;_source\u0026#34; : [\u0026#34;book.title\u0026#34;,\u0026#34;book.contents\u0026#34;], \u0026#34;fields\u0026#34;: [ \u0026#34;book.title\u0026#34;, \u0026#34;book.contents\u0026#34; ], \u0026#34;query\u0026#34;: { \u0026#34;nested\u0026#34;: { \u0026#34;path\u0026#34;: \u0026#34;book\u0026#34;, \u0026#34;query\u0026#34;: { \u0026#34;query_string\u0026#34; : { \u0026#34;query\u0026#34; : \u0026#34;Solr\u0026#34;, \u0026#34;fields\u0026#34; : [\u0026#34;book.title\u0026#34;, \u0026#34;book.contents\u0026#34;] } } } }, \u0026#34;highlight\u0026#34;: { \u0026#34;pre_tags\u0026#34;: [\u0026#34;\u0026lt;b\u0026gt;\u0026#34;], \u0026#34;post_tags\u0026#34;: [\u0026#34;\u0026lt;/b\u0026gt;\u0026#34;], \u0026#34;fields\u0026#34;: { \u0026#34;*\u0026#34;: {} } } } 結果はこちら。 ハイライトがありません。\n{ \u0026#34;took\u0026#34;: 3, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 5, \u0026#34;successful\u0026#34;: 5, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;max_score\u0026#34;: 0.5, \u0026#34;hits\u0026#34;: [ { \u0026#34;_index\u0026#34;: \u0026#34;bookstore\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;_score\u0026#34;: 0.5, \u0026#34;_source\u0026#34;: { \u0026#34;book\u0026#34;: { \u0026#34;title\u0026#34;: \u0026#34;Apache Solr入門\u0026#34;, \u0026#34;contents\u0026#34;: \u0026#34;Apache Solrについて日本語で書かれた唯一の書籍です。SolrはLuceneをコアにした検索サーバです。\u0026#34; } } } ] } } 次に、ハイライトが帰ってくるパターン。 nestedクエリではなく、_allを対象としたクエリを投げます。\n{ \u0026#34;_source\u0026#34; : [\u0026#34;book.title\u0026#34;,\u0026#34;book.contents\u0026#34;], \u0026#34;fields\u0026#34;: [ \u0026#34;book.title\u0026#34;, \u0026#34;book.contents\u0026#34; ], \u0026#34;query\u0026#34;: { \u0026#34;query_string\u0026#34; : { \u0026#34;query\u0026#34; : \u0026#34;Solr\u0026#34;, \u0026#34;fields\u0026#34;: [ \u0026#34;_all\u0026#34; ] } }, \u0026#34;highlight\u0026#34;: { \u0026#34;pre_tags\u0026#34;: [\u0026#34;\u0026lt;b\u0026gt;\u0026#34;], \u0026#34;post_tags\u0026#34;: [\u0026#34;\u0026lt;/b\u0026gt;\u0026#34;], \u0026#34;fields\u0026#34;: { \u0026#34;book.title\u0026#34; : {}, \u0026#34;book.contents\u0026#34;: {} } } } この場合の結果は次の通り。\n{ \u0026#34;took\u0026#34;: 2, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 5, \u0026#34;successful\u0026#34;: 5, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;max_score\u0026#34;: 0.27063292, \u0026#34;hits\u0026#34;: [ { \u0026#34;_index\u0026#34;: \u0026#34;bookstore\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;_score\u0026#34;: 0.27063292, \u0026#34;_source\u0026#34;: { \u0026#34;book\u0026#34;: { \u0026#34;title\u0026#34;: \u0026#34;Apache Solr入門\u0026#34;, \u0026#34;contents\u0026#34;: \u0026#34;Apache Solrについて日本語で書かれた唯一の書籍です。SolrはLuceneをコアにした検索サーバです。\u0026#34; } }, \u0026#34;highlight\u0026#34;: { \u0026#34;book.title\u0026#34;: [ \u0026#34;Apache \u0026lt;b\u0026gt;Solr\u0026lt;/b\u0026gt;入門\u0026#34; ] } } ] } } ハイライトが返ってきています。\n考察（原因は未特定） 残念ながら、まだ調査してません。 まずは、現象が理解できたというだけです。 問題点が実は２つありそうです。\n問題点１：nestedクエリの場合に、ハイライトされない。 nestedクエリではハイライトが動作していないようです。 想像ですが、検索に利用されたクエリで指定されているフィールドをハイライタ（ハイライトを実行するモジュール）が認識できてないのではないかと。 なぜ認識できていないのかという点を調査する必要がありそうです。\n考察（試してみたパターン） nestedではないクエリで、ハイライトが動作しているのですが、 \u0026quot;book.title\u0026quot; : {\u0026quot;require_field_match\u0026quot; : true},にした場合は、ハイライトが返ってこないです。 このオプションは、検索対象のフィールドでマッチした文字列だけがハイライトされるオプションになります。 したがって、book.titleフィールドに対する検索でSolrという文字を検索していないことになります。 _allに対するクエリであるためです。 このため、例えば、titleだけを検索対象にしたのに、contentsにSolrという文字が入っていてもハイライトされてしまうという状況が発生します。\n問題点２ store : yesのデータがハイライトできない。 GithubにIssueをあげました。https://github.com/elasticsearch/elasticsearch/issues/5245 （2014/02/25追記）\nnestedオブジェクトにあるデータのうち、store : noのものだけがハイライト結果として返ってきました。\n考察 なぜ、store : yesのデータがハイライトされないかを調べるために、fieldsパラメータをリクエストに追加してみました。\n{ \u0026#34;_source\u0026#34; : [\u0026#34;book.title\u0026#34;,\u0026#34;book.contents\u0026#34;], \u0026#34;fields\u0026#34;: [ \u0026#34;book.title\u0026#34;, \u0026#34;book.contents\u0026#34; ], ... } すると、fieldsの戻り値は次のとおりです。\n... \u0026#34;fields\u0026#34;: { \u0026#34;book.title\u0026#34;: [ \u0026#34;Apache Solr入門\u0026#34; ] }, ... このことから、store : noのデータの場合、_sourceから値を取得して返却しているというのがわかります。 ハイライトがされない原因も、fieldsで値が取れていないのも同じ原因であると思われます。 なぜなら、ハイライトは、保存された文字列を内部で取り出し利用して、ハイライトタグを埋め込むという動作をするためです。\n参考？ これらの問題点についてですが、次のIssueが関係あるかもしれません。\nReturn matching nested inner objects per hit #3022\n今後？ 残念ながら、現時点では、問題点がどんなものかというのを理解しただけとなります。 デバッグしたりソースを追っかけたりして何が問題なのかを調べて行ってみようかなぁと。\nなにか、気づいたことなどあればコメントしてもらえると助かります。\n","date":1393231920,"dir":"post/2014/","id":"f55d33371dcff207fd7d201128df2ea3","lang":"ja","lastmod":1393231920,"permalink":"https://blog.johtani.info/blog/2014/02/24/strange-behavior-of-field-in-nested-obj/","publishdate":"2014-02-24T17:52:00+09:00","summary":"今年初の「突撃！隣のElasticsearch」ということで、Wantedlyさんにおじゃましました。 ※写真を自分でも撮ったのですが、画像が","tags":["elasticsearch"],"title":"Nested Objectのフィールドの奇妙な動作"},{"contents":"今回はたまたま日本にいたElasticsearchの人をスペシャルゲストに呼べたので、大満足ですｗ 英語の通訳とかちゃんと勉強しないとなぁ。。。\nとりあえず、てきとーなメモですが、残しておきます。 参加者数は130人＋スタッフ＋リクルートテクノロジーズ社内の人。という感じでした。アンケート集計はもう少々おまちを。\nスライドがそろったら、また、更新すると思いますが、第一報という感じで公開しておきます。 懇親会にも50名も参加していただけて、非常に楽しかったです。 話ができてない方が多数いるかもしれませんが、次回以降、声をかけていただければと。 （物覚え悪いんで、あれですが。。。） 盛り上がってきてて楽しいなぁ。 スタッフの人達の練度も上がってきてるので、すごく楽ができてます。\n至らない点とかあれば、こちらにコメントしてもらったりしていただければと。\nGeohashing with Elasticsearch Florian Schilling, Elasticsearch Inc, スライド：https://speakerdeck.com/chilling/tokyo-es-study-session-iii-geohashes\n自己紹介 Geoのスタッフ Elsticsearchの概要 転置イデックスやREST APIなどの説明 マイクの調子が良くなくて申し訳なかったっす。。。 平賀さん、通訳ありがとう！ Solr本もよろしくお願いします！！\nAWSで構築するsharding 株式会社イプロス　外山　寛さん　@toyama0919 スライド：http://toyama0919.bitbucket.org/elasticsearch.html\nAWS対応の話 ルーティングが重要だよ。（宣伝ありがとうございますｗ） type指定しないとルーティングできない。（内部でtypeも使ってハッシュ値取ってたかなぁ？） 苦労話とかいくつか。 tireはre-tire\u0026hellip; 実サービスでのElasticsearch設定・使用例（仮） 株式会社じげん　多田 雅斗さん　@tady_jp スライド：https://speakerdeck.com/tadyjp/tesutoqu-dong-jian-suo-falsesusume-at-tady-jp\n検索とは的な話がわかりやすい。 全文検索のお話。ログ検索じゃないよと。 書籍ないですよねー（ふふふ） specで検索条件記述しといて、ってのいいですよね。絶対必要だと思う Mapping変更した時にテストやり直す方法とかどうしてますか？ 特にフレームワークは使ってないです。\nMySQLユーザ視点での、小さく始めるElasticsearch 株式会社リブセンス 吉田 健太郎さん @yoshi_ken スライド：http://www.slideshare.net/y-ken/introducing-elasticsearch-for-mysql-users\nやっぱりkuromoji便利だよね MySQLとかと連携したい。 river-pluginもいまいち安定しない なので、Yamabiko作ってみました。 Geo検索とKuromojiの話をしてくれました。（作者とか開発者がいるってのを狙ってたのかすごいなぁ。） Mappingとかはちゃんと指定したほうがいろいろいいですよ。 nodeJS+DynamoDB＋Elasticsearchで全社基盤を作った話 株式会社リクルートテクノロジーズ 相野谷 直樹さん @naokiainoya スライド：http://www.slideshare.net/recruitcojp/elasticsearchnodejsdynamodb-7\nちょっと変わった使い方のElasticsearchで面白いです。 Scroll/Scanについては、Solrでもない機能なので、そういう意味でもElasticsearchなのかもしれないですね。 参加していただいた方々のブログ 第3回elasticsearch勉強会 [2014/02/07(Fri.)]に参加してきました - ほわいとぼーど\nhttp://a3no.hatenablog.com/entry/2014/02/09/022405\n第 3 回 elasticsearch 勉強会に行ってきた - ようへいの日々精進\nhttp://inokara.hateblo.jp/entry/2014/02/07/233057\nhttp://www.smokeymonkey.net/2014/02/3elasticsearch.html\n第3回elasticsearch勉強会でトークしました #elasticsearchjp\nhttp://y-ken.hatenablog.com/entry/elasticsearch-meetup-vol3\n第3回elasticsearch勉強会にいってきました #elasticsearchjp\nhttp://blog.livedoor.jp/ashibuya0128/archives/52058766.html\n","date":1391787720,"dir":"post/2014/","id":"229b7fc784707b1d2c702fbeba080e86","lang":"ja","lastmod":1391787720,"permalink":"https://blog.johtani.info/blog/2014/02/08/hold-3rd-elasticsaerch-meetup-in-tokyo/","publishdate":"2014-02-08T00:42:00+09:00","summary":"今回はたまたま日本にいたElasticsearchの人をスペシャルゲストに呼べたので、大満足ですｗ 英語の通訳とかちゃんと勉強しないとなぁ。。","tags":["elasticsearch","勉強会"],"title":"第3回elasticsearch勉強会を開催しました！ #elasticsearchjp"},{"contents":"すずけんさんがVagrant+puppet使って、VM起動してElasticsearchのクラスタを組んでる記事を書いているのを見て、試してみたくなりました。 ということで、VagrantとかPuppetなに？くらいの私ですが、クラスタを起動するところまで行ったので、その時のメモを残しておきます。\n元記事とか参考 Vagrant環境にpuppet moduleを利用してさくっとelasticsearchをインストールする Vagrant環境にpuppetを利用してさくっとelasticsearchのclusterを作成する puppet-elasticsearch なんとなくの理解 VagrantやPuppetについては、何度か勉強会で話を聞いてはいたのですが、 想像していたレベルだったので良い機会でした。 今のところの認識はこんな感じです。\nVagrant VMを起動したり、VM周りの設定をあれこれできるツール。 VMのネットワーク設定や、インスタンス名？などを指定できる。\nPuppet 起動後のVM（VMとは限らないか。）のゲストOS側の設定周りやアプリのインストールなどを 実行できるツール。\n詰まった箇所 すずけんさんのブログを元に作業をしましたが、自分がVagrantやPuppetに疎いため、以下の部分で躓いたので、備忘録のために残しておきました。\nその１：Puppetのファイルの場所 search01.vm.localのVMを設定（というか、elasticsearchのインストール？）するときに、manifests/search.appとroles/search/manifests/init.ppファイルが必要で作成します。\nこのファイルの配置場所は/vagrant配下に作成する必要がありました。 ssh search01.vm.localでVMにログインした場合は/home/vagrantにログインしており、この場所でファイルを作ってもPuppetがエラーを吐いたためです。\nと思ったのですが、あれ？これひょっとしてVagrantfileがあるところにディレクトリとファイル作ると勝手にVMにコピーしてくれるんですか？destroyして、upしたら、ファイルが勝手にコピーされてる。ひょっとして、/vagrantってディレクトリはVagrantfileがあるディレクトリを共有してたりするのかな？そのうち、Vagrantについても調べてみようかな。\nその２：ネットワーク周り curl http://192.168.10.114:9200/ をホストOSから実行してみましたがうまく行きませんでした。。。 ネットワーク周りの設定だと思うんですが。 少なくとも「sshによるログイン」「ping」コマンドの応答は返ってきてます。\nまた、VM内でcurlコマンドを実行したらレスポンスが返ってきました。\nなんで？ってツイートしたら各所から「iptables」という単語が飛んできて、 service止めたら大正解でした。まぁ、そうですよね。基本ですよね。。。\nということで、Puppetがよくわかっていませんが、ググって変更してみました。\nmanifests/search.appに以下を追加\ninclude iptables roles/iptables/manifests/init.pp\nclass iptables { service { \u0026#39;iptables\u0026#39;: enable =\u0026gt; false, ensure =\u0026gt; stopped, } } iptablesを停止するmanifests？です（良くないことなんですが、よくわかってない）。\nということで、ローカルで1個のVM起動して、elasticsearchにアクセスできることは確認できました。\nと、書いてるそばから、元記事が修正されてしまいましたｗ\nクラスタ編（変更点） クラスタを組むときに、追加でプラグインを入れたのでroles/search/manifests/init.ppは次のようにしました。\nclass search { class { \u0026#39;elasticsearch\u0026#39;: package_url =\u0026gt; \u0026#39;https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-1.0.0.RC2.noarch.rpm\u0026#39;, java_install =\u0026gt; true, config =\u0026gt; { \u0026#39;cluster\u0026#39; =\u0026gt; { \u0026#39;name\u0026#39; =\u0026gt; \u0026#39;test-es-cluster\u0026#39; }, \u0026#39;network.host\u0026#39; =\u0026gt; \u0026#39;_eth1:ipv4_\u0026#39;,, \u0026#39;marvel.agent.exporter.es.hosts\u0026#39; =\u0026gt; [\u0026#39;192.168.10.114:9200\u0026#39;,\u0026#39;192.168.10.115:9200\u0026#39;] } } elasticsearch::plugin{\u0026#39;elasticsearch/marvel/latest\u0026#39;: module_dir =\u0026gt; \u0026#39;marvel\u0026#39; } elasticsearch::plugin{\u0026#39;mobz/elasticsearch-head\u0026#39;: module_dir =\u0026gt; \u0026#39;head\u0026#39; } elasticsearch::plugin{\u0026#39;royrusso/elasticsearch-HQ\u0026#39;: module_dir =\u0026gt; \u0026#39;HQ\u0026#39; } elasticsearch::plugin{\u0026#39;elasticsearch/elasticsearch-analysis-kuromoji/2.0.0.RC1\u0026#39;: module_dir =\u0026gt; \u0026#39;analysis-kuromoji\u0026#39; } elasticsearch::plugin{\u0026#39;info.johtani/elasticsearch-extended-analyze/1.0.0.RC1\u0026#39;: module_dir =\u0026gt; \u0026#39;extended-analyze\u0026#39; } elasticsearch::plugin{\u0026#39;polyfractal/elasticsearch-inquisitor\u0026#39;: module_dir =\u0026gt; \u0026#39;inquisitor\u0026#39; } } とりあえず、今日はクラスタ組んでMarvelやプラグインの動作確認でおしまいです。\n疑問点 いくつか疑問点が。試してみてもないんでなんとも言えませんが。気が向いたら、調べて追記するかも。\n:private_networkはVirtualBox内で完結する（Macから外には影響しない）ネットワークが構築される？たぶん、VagrantというよりはVM、仮想化周りの知識なんだろうけど どこから再開可能？elasticsearch.ymlの設定を書き換えた場合に、最後のコマンドだけ実行するとちゃんとやりなしてくれたりするのかな？ VMのディスク増やすのもVagrantでできるんかな？まぁ、できると思うけど。 :forwarded_portのauto_correctとかわかってない。 JVMをSunのJVMでかつ、7u25に変更したいのだがどうしたものか？(現時点での推奨バージョン) 感想 Vagrantって便利ですね。あれ？って思ったら、destroyして、やり直すのがすごく簡単です。 元記事があるので、なんとなくですが、構成とかどうすればいいかがわかるのは本当に助かりました。 これで、あれこれと検証する環境が簡単に構築できることがわかったので、色々と楽できるかも。ありがとうございます、すずけんさん！\n","date":1391695740,"dir":"post/2014/","id":"c98cbc333fb7d95c6c9fc4924b0526e1","lang":"ja","lastmod":1391695740,"permalink":"https://blog.johtani.info/blog/2014/02/06/es-cluster-start-using-vagrant-and-puppet/","publishdate":"2014-02-06T23:09:00+09:00","summary":"すずけんさんがVagrant+puppet使って、VM起動してElasticsearchのクラスタを組んでる記事を書いているのを見て、試して","tags":["elasticsearch","vagrant","puppet","marvel"],"title":"すずけんさんのメモを元にVagrantでElasticsearchクラスタを起動してみた"},{"contents":"改訂新版Solr入門出版記念ということで、第13回Solr勉強会 #SolrJP 新Solr本出版記念を開催しました。\n出版記念なので、技術評論社様より、プレゼント用にSolr本を用意していただきました！ありがとうございます！！ 書籍をゲット出来た方は、ツイートしたりブログ書いたり書評書いたりして、宣伝してください！！！\n今回は、私は手を抜いて他の人に喋ってもらいました！\n今回は、著者陣（関口さんは特別ゲスト）でスピーカーを固めてみました。 以下は、いつもの簡単なメモです。 スライドが集まったらまた更新していきます。\n1. 「はじめての検索エンジン＆Solr」 株式会社NTTデータCCS　鈴木 教嗣さん スライド：はじめての検索エンジン＆Solr 第13回Solr勉強会\n鈴木さんの発表初めて聞きましたｗ。 趣味が多いなぁ。 ちょこちょこと、宣伝を入れてるのが流石ですｗ\n入門らしい概要 クエリの概要とかも。 スコア計算とか 導入するとうれしいところとか Solr盛り上げましょう！ 2. 「Solr SearchComponent 再訪」 株式会社ロンウイット　関口 宏司さん スライド：公開待ち\nベン図で検索の評価指標の説明 理論的なお話 Solrのサーチコンポーネントを使って何ができるか。ベン図で。 サーチコンポーネント以外にも NGramTokenizerも SynonymFilterも パーソナライズ検索 いきなり話をふられたのでちょっとびっくりしましたｗ\n3. 「自動補完(Autocomplete)ともしかして？(Did You Mean?)」 株式会社 ロンウイット　大須賀 稔さん スライド：Solr AutoComplete and Did You Mean?\nデモ：https://github.com/mosuka/solr-suggester-demo-ui\n職歴が相変わらずおもしろい 編集距離のお話 素晴らしいCM！ 候補のランキングを変更できる？ SpellcheckComponentのパラメータで指定できるものなら楽ですが。。。\n4. 「Lucene Revolution 2013 Dublin振り返り」 楽天株式会社　平賀 一昭さん スライド：公開待ち\nダブリンどこ？（間違ってベルリンって言っちゃいましたｗ） スタジアムで開催。グランドにも入れるのかなぁ？ まずはTwitter Luceneの改良版 ちょっと特殊。１４０文字とか 青いRさんのライバル。Careerbuilder 元FASTユーザ 企業向けに検索キーワードとかの解析画面を用意 検索精度の改良の話とか 転職で引っ越す意思があるかとか。 最後はLinkedIn Luceneのユーザ まとめ ということで、スピーカーの方々のスライドにもありましたが、 改訂新版Apache Solr入門は良い本なので、購入していただけると嬉しいです。\n感想、コメントなど、いつでもお待ちしています！\n","date":1390988760,"dir":"post/2014/","id":"c6107ff57e96a1373c019d252c00ad84","lang":"ja","lastmod":1390988760,"permalink":"https://blog.johtani.info/blog/2014/01/29/hold-to-japan-solr-meetup/","publishdate":"2014-01-29T18:46:00+09:00","summary":"改訂新版Solr入門出版記念ということで、第13回Solr勉強会 #SolrJP 新Solr本出版記念を開催しました。 出版記念なので、技術評論社様より、プレ","tags":["Solr","勉強会"],"title":"第13回Solr勉強会を開催しました"},{"contents":"昨晩、Elasticsearchから初のプロダクトとなるMarvelがリリースされました。ということで、さっそく触ってみて、簡単な紹介と感想を書いてみました。\nMarvelって？ Elasticsearch社が初のプロダクトとしてリリースした、Elasticsearchクラスタモニタリングツールです。 次のような特徴があります。\nplugin形式で提供 GUIがKibana メトリックスはElasticsearchに保存 SenseがChrome以外でも使える プロダクション環境で利用する場合は有料ですが、開発用途では無料で利用できます。 現時点(2014/01/29)では、0.90.9以上のバージョン(1.0.0.RC1含む)で利用が可能です。\nなにができるの？ Elasticsearchクラスタに関するメトリックスを保存、可視化できるプロダクトです。 ドキュメント数やJVMの状況、クラスタの状態など、いろいろなメトリックスが保存されます。\n保存先は、別のElasticsearchクラスタにすることも可能です。 お試しでインストールして見る場合は、同一クラスタにサービスに利用するインデックスとMarvel用のメトリックス保存先インデックスを入れても良いです。\nただ、プロダクション環境では、Marvel用インデックスはあくまでもモニタリングに使用するため、サービスのクラスタへの影響を最小にしたくなります。\nこのような場合、Marvelのプラグインの設定を変更することで、メトリックス送信用のエージェントとして動作させることができます。\n詳しくは、Marvelのドキュメントにあるinstalling a secondary monitoring clusterを御覧ください。\n1/29 16時時点で、上記ドキュメントのエージェントの送信先の設定に関する部分に誤記がありました。 おそらく、configuration optionsの記述が正だと思います。 もう、なおってました。(1/30朝時点)\nキャプチャいろいろ 日本語WikipediaのデータをRiverで登録しながら各画面の動作などを見てみました。\nMarvel Overview 日本語WikipediaをRiverで登録してる途中。Loadが高くなってることなどがわかります。\nOverview (クラスタの状態が変化) クラスタの状態が変化したところに、タグが付くみたいです。 ここでは、ノードの一つを停止、起動しました。\nインデックス終了後に、クラスタを再起動してしまい、クラスタ内のシャードの再配置が実行されてしまったため、クラスタの状態がYellowになってしまうとこんな感じ。ちょっとわかりにくいです。\nSense Chromeプラグインとしてリリースされていたクエリ実行コンソールがMarvelのサイトプラグインとして提供されています。これがあるだけで、Elasticsearchへのクエリの実行が格段に効率良くなります。\nIndex Statistics インデックスに関する情報のグラフが見れるページです。ドキュメント数の他に、容量やリクエスト数なども見れます。\nインデックス終了後のグラフはこんな感じ。\nインデックス終了後のOverviewはこんなかんじです。\nCluster Pulse クラスタで発生したイベントとイベントの詳細を見ることができるページです。各種インデックスがYELLOWからGREENに変わっていっているのがmessageで分かります。\nすべて再配置が終わったらGREENになりました。\nNode Statistics 各ノードに関する情報を見ることができる画面です。 ノードごとにグラフの色を分けることもできます。\nその他 Marvelプラグインにブラウザから接続できなくなるとこんなメッセージが出ました。\n参考までに、elasticsearch-headの画面も。こちらのほうが、シャードの再配置中であるのがひと目で分かります。\n感想 綺麗です。まぁ、Kibanaが綺麗ですから。 クラスタ内で発生したイベントが時系列で保存されるため、あとからどんなことが発生したのかといった原因の追求などには非常に役に立ちそうです。\nただ、インデックスの状態や状況（クラスタ再起動やノード追加時にshard再配置などが実行されている状況とか）はelasticsearch-headのほうがわかりやすかったです。 インデックス単位でのStatusがMarvelの画面ではわからないため、shard再配置が完了したかどうかなどのタイミングがわかりにくかったです。\nある程度、多くのノードを利用したクラスタを利用する場合に、モニタリングツールとして利用するのは便利なのではないでしょうか？ 時系列でログやイベントが保存されるので、ノードが追加されたり外れたりといった状況があとからでも追跡可能なのが便利です。\n疑問点 インデックスの情報などは、5s毎にMarvelのインデックスに保存されているようです。ただ、GUI上では5分毎のデータしか表示されません。 どうやって変更するんだろう？\nまた、Marvelのクラスタへの接続が切れた時のデータはどうなるのか？という部分も気になります。Marvelのクラスタを更新している時や、ネットワークが遮断されてしまった場合のデータがどうなるのかという点です。\n疑問点への回答(2014/01/30追記) 疑問点に対して中の人から回答を頂いたので、追記です。\nQ：GUI上で5分毎のデータしか表示されないんですが？ A：ブラウザの負荷を高くしないようにするために、1つのグラフに20のプロットしてるだけです。ズームしたりすると、もっと細かなデータが見れますよ。 Q：Marvelのクラスタへの接続が切れた時のデータはどうなるんだろう？ A：接続が切れた場合は、ローカルに保存されるけどデータは無視されます。接続が戻ると、戻った後のデータは記録されていきます。将来的には改善するかも。 ちなみに、昨日試してた環境が、足元Linux環境（監視対象のクラスタ）＋手元Mac環境（Marvelモニタリングデータ格納クラスタ）という環境でした。 確かに、出社してから、手元Mac環境を起動すると、データが流れてくるようになりました。 ただ、監視対象のクラスタでは、socket timeoutのログがずっと出てましたが。\n参考文献 リリースブログ プロダクトページ ドキュメント ","date":1390983240,"dir":"post/2014/","id":"f6debed350f20a2b3aa4d970e3227411","lang":"ja","lastmod":1390983240,"permalink":"https://blog.johtani.info/blog/2014/01/29/simple-introduction-and-first-impression-es-marvel/","publishdate":"2014-01-29T17:14:00+09:00","summary":"昨晩、Elasticsearchから初のプロダクトとなるMarvelがリリースされました。ということで、さっそく触ってみて、簡単な紹介と感想","tags":["elasticsearch","marvel"],"title":"Elasticsearch Marvelの紹介と第一印象"},{"contents":"Lucene/Solr 4.6.1がリリースされそう(バイナリ配布待ち)lucene-gosenの4.6.1対応版をリリースしました。\nライブラリのインタフェースなどは特に変更はないのですが、ライブラリのダウンロード先が変更になっているため、注意喚起です。\nGoogle Project Hostingの仕様変更により、Downloadsに新規ファイルがアップロードできなくなっています。（2014年から）\nこのため、プロジェクトの選択肢としては以下の3点となっています。\nGoogle Driveにファイルをアップロードしてダウンロードしてもらう 他のソースコード管理サイトなどを利用する。 他のダウンロードサイトを利用する 1.と3.は場所が違うだけで、方法は一緒です。 今回は、暫定的に1.を利用してダウンロードするように対応しました。\nダウンロード先はプロジェクトのページにリンクが有りますが、わかりにくいのでキャプチャを撮ってみました。\nダウンロード先 これまでのFeatured - Downloadsとは異なり、Links - External linksの下に Downloads lucene-gosen 4.6.1というリンクを用意してあります。\nフォルダとなっており、各種jarファイルがリストされていますので、こちらからダウンロードをお願いします。 今後は、この下にダウンロードリンクを追加していく予定です。\nただし、2.で述べたように「別のソースコード管理サイト」も検討中です。\n","date":1390880040,"dir":"post/2014/","id":"c4e7199a586a308352b7a881add7e356","lang":"ja","lastmod":1390880040,"permalink":"https://blog.johtani.info/blog/2014/01/28/release-lucene-gosen-4-dot-6-1/","publishdate":"2014-01-28T12:34:00+09:00","summary":"Lucene/Solr 4.6.1がリリースされそう(バイナリ配布待ち)lucene-gosenの4.6.1対応版をリリースしました。 ライブラリのインタフェースな","tags":["Solr","Lucene","lucene-gosen"],"title":"lucene-gosen 4.6.1のリリースに関する注意点"},{"contents":"Elasticsearchのcuratorのブログ記事を読んで、日本語でツイートしたところ、Aaron Mildensteinさんから日本語（ローマ字）で返信を頂きました。 せっかくなので、ブログ記事を翻訳してもいいかを尋ねたところ、快くOKを頂いたので、翻訳してみました。参考になればと。（誤訳など見つけたらコメントください。）\n@johtani Kore no hou ga ii. Nihongo de no Curator RT, arigatou gozaimasu! #elasticsearch #curator #logstash\n\u0026mdash; Aaron Mildenstein (@theuntergeek) 2014, 1月 22 curator: 時系列インデックスの管理 原文：curator: tending your time-series indices\n背景 数年前、Elasticsearch、Logstash、Kibana(ELK)を管理し、ここ30日よりも古いインデックスを自動的に削除する方法を必要としていました。 APIドキュメントを読み、#logstashや#elasticsearchのIRCチャネルのコミュニティの助けを借りて、簡単なスクリプトとcronを用意するのが簡単であることを知りました。\ncurl -XDELETE \u0026#39;localhost:9200/logstash-2014.01.01?pretty\u0026#39; もちろん、これも動作しますが、日付を生成するのがめんどくさいのでもっとエレガントな方法が欲しかったです。\n最初に pythonでスクリプトを書き始めました。特定の日数のインデックスを管理するだけのコマンドラインクリーナーを書いてコミュニティにシェアしました。他の人が、新しい機能を追加してくれました。私は、古いインデックスをoptimizeすることができる他のスクリプトも書きました。これは、シャードごとにnセグメント以上存在しないように各シャードのセグメントをマージすることです。これらのスクリプトで1つになるようにマージしたりエンハンスし、古いインデックスを管理する助けになるツールです。\ncuratorの紹介 Curatorで可能なインデックスオペレーション\n削除（日付もしくは、トータル容量による制限） インデックスのクローズ(Close) bloom filter cacheの無効化 Optimize(LuceneのforceMerge) curatorのインストール この記事を書いている時点で、Curator は0.5.1がリリースされ、0.90.10に対応しています。Curatorはまた、Elasticsearchの1.0(現在はRC1)へも対応しています。各リリースへの互換性の保証のためのテストも行っています。\n現時点では、gitリポジトリで配布しています。近い将来、pipによるインストール可能なパッケージにする予定です。利用することを恐れないでください。もし、pythonとpipがあなたのマシンにインストールされていれば、次のようにインストールは簡単です。\ngit clone https://github.com/elasticsearch/curator.git pip install -r requirements.txt インストール後の確認は次のコマンドです。\n$ ./curator.py -v curator.py 0.5.1 利用方法とサンプル サンプルを示す前に、オプションを見ておくとよいでしょう。このリストは長いですが（この記事の最後に含まれています）、どのようなことがコントロールできるかを説明しています。デフォルトがどうなっているかに注意してください。もし、デフォルト値で良い場合は、フラグを指定する必要はありません。\nでは、簡単なサンプルを見ながら、CuratorがELKスタックをどうやって管理するかを見て行きましょう。\n削除(delete) 90日以上のインデックスを保存したくないとしましょう。コマンドは次のようになります。\n$ curator.py --host my-elasticsearch -d 90 -dで日数を指定しているだけです。簡単でしょ？\n容量による削除(delete by space) これは、指定したギガバイト数を超えたインデックスを場合に(最も古いものから)削除を行う特殊なケースです。\n$ curator.py --host my-elasticsearch -C space -g 10024 -Cでspaceによるcurationであること、-gでギガバイト数(10024、10TB)であることを指定しているのがわかります。-gは1.5や0.5という数値を指定できます。\nその他のCuratorオプションはspaceによる削除と組み合わせて使用できないことに注意してください。\nクローズ(close) Open/Close Index APIにより、インデックスをクローズすることができます。\nopen/close index APIを利用すると、インデックスをクローズしたり、あとでオープンしたりすることができます。クローズされたインデックスはクラスタのオーバヘッドにほとんどならず(メタデータの管理を除く)、読み書き操作の妨げにもなりません。クローズされたインデックスは、リカバリプロセス時に、オープンされます。\nインデックスをクローズすることは、存在はするが検索できないという意味です。何が便利なのでしょう？\n90日のインデックスを保存する義務があるが、検索は過去30日のインデックスを対象にする以外は稀であるような場合を想像してください。このような状況で、価値のあるリソース(ヒープスペースなど)を節約するためにインデックスをクローズすることができます。これは、クラスタに検索やインデキシングのためのメモリを与えることができることを意味します。そして、もし、クローズしたインデックスのデータが必要になったら、APIを呼び出してインデックスをオープンすれば検索できます。\nこのような場合、今オープンしているインデックスが再び、クローズされないように、一時的にCuratorのスケジュール実行をオフにしておくのが懸命です。\n$ curator.py --host my-elasticsearch -c 30 -d 90 先ほど説明した例の実行方法です。これは、30日よりも古いインデックスはクローズし、90日より古いインデックスを削除します。本当に簡単でしょ？\nbloom filterの無効化 これは、0.90.9以降のバージョンで利用可能な機能です。(リンク先はIssue #4525)\n心配しないでください。このスクリプトは操作を行う前に、elasticsearchが利用可能なバージョンであるかをチェックします。\nbloom filterとは何でしょう？なぜ、無効化したくなるのでしょう？\nbloom filterはインデキシング操作を高速化するためにリソースを割り当てられます。時系列データで、インデキシングしている間もこれは有用です。インデックスは2日後には、日付が変わると新しいデータはおそらくインデックスされません。そのインデックスにはもはや必要のないリソースをbloom filterはまだ持っています。Curatorはこれらのリソースを開放することができます！\n$ curator.py --host my-elasticsearch -b 2 -c 30 -d 90 これで、bloom filterのリソースは少なくとも2日(1にもできます)よりも古いインデックスについては利用せず、30日より古いインデックスはクローズし、90より古いインデックスは削除します。\noptimizeというよりもforcemerge コマンドの説明をする前に、Elasticsearch APIのoptimizeを見ることは、生きているインデックスや\u0026quot;cold\u0026quot;インデックス(インデキシングがアクティブではないという意味)に実行する必要があるということを理解するために重要です。実際、optimizeはLuceneではforceMergeと名前が変えられ、インデックスを改善するためにoptimizeを呼び出す必要はなくなりました。Elasticsearchのセグメントをマージすることは利点がありますが、coldインデックス全てに対してoptimizeを開始する前に、コストを理解する必要があります。\nforceMerge操作はインデックスにある各シャードのセグメントの数を少なくします。各セグメントはオーバヘッドがあるため、セグメントが多いということは、より多くのリソースを使うという意味です。良さそうですね？リソースが少ない？\nそれは、可能ですが、merge操作を実行するには多くのディスクやネットワークI/Oが必要で、ディスクやクラスタの通常の書き込み操作に悪影響を及ぼします。もし、これが必要なら私のアドバイスを良く考えてください。(数％ほど)検索を速くし、リソースの使用量も減らすことができます。また、管理しているセグメント数が小さくなるということは、クラスタのリカバリを速くすることにもなります。1つのインデックスをoptimizeするためにはおそらく1時間以上の時間がかかります。「使用する前に目立たない場所で試してください」というクリーニングボトル(訳注：洗剤とか漂白剤かな？)の注意書きと同様に、ディスクI/Oが低い時にテストし、もし操作とリソースがあなたのクラスタのユースケースにあっているかを見てください。デフォルトでは、シャードごとに2つのセグメントにマージしますが、--max_num_segmentsフラグで変更可能です。\nここまでのサンプルは次のようなコマンドになります。\n$ curator.py --host my-elasticsearch -b 2 -o 2 -c 30 -d 90 これで、bloom filterは2日より古いインデックスでは向こうにし、2日より古いインデックスは\u0026quot;optimize\u0026quot;し、30日より古いインデックスはクローズし、90日より古いインデックスは削除されます。\n操作の順序 スクリプトは操作が衝突するのを防ぐために次の順序で実行されます。なぜ、クローズされたインデックスはoptimizeしないのでしょう？なぜ、削除予定のインデックスはクローズされないのでしょう？\nDelete (by space or time) Close Disable bloom filters Optimize 使用の検討 最後の例で、3つの操作を1つのコマンドで実行していますが、それらが連続ですべて実行されるのを望んでいないかもしれません。\n$ curator.py --host my-elasticsearch -b 2 -o 2 -c 30 -d 90 これは、次の操作と同様です。\n$ curator.py --host my-elasticsearch -d 90 $ curator.py --host my-elasticsearch -c 30 $ curator.py --host my-elasticsearch -b 2 $ curator.py --host my-elasticsearch -o 2 これらのコマンドを異なる時間に実行したり、異なるその他のオプション(特に、optimize実行で--timeout 3600を追加したり)を指定して実行するのは簡単です。\nまた、デフォルトのlogstash-とは異なるプレフィックスのインデックスを持っているかもしれません。\n$ curator.py --host my-elasticsearch --prefix logstash- -d 30 $ curator.py --host my-elasticsearch --prefix othername- -d 30 最後に Curatorは時系列インデックスの保存ポリシーを管理するのに役立ちます。豊富な設定オプションがインデックスを管理することを簡単にします。クラスタに存在するノードの数に関係なく。https://github.com/elasticsearch/curatorへのフィードバックやコントリビューションをお待ちしています！\n参考(全引数とオプション) $ curator.py -h usage: curator.py [-h] [-v] [--host HOST] [--port PORT] [-t TIMEOUT] [-p PREFIX] [-s SEPARATOR] [-C CURATION_STYLE] [-T TIME_UNIT] [-d DELETE_OLDER] [-c CLOSE_OLDER] [-b BLOOM_OLDER] [-g DISK_SPACE] [--max_num_segments MAX_NUM_SEGMENTS] [-o OPTIMIZE] [-n] [-D] [-l LOG_FILE] Curator for Elasticsearch indices. Can delete (by space or time), close, disable bloom filters and optimize (forceMerge) your indices. optional arguments: -h, --help show this help message and exit -v, --version show program version number and exit --host HOST Elasticsearch host. Default: localhost --port PORT Elasticsearch port. Default: 9200 -t TIMEOUT, --timeout TIMEOUT Elasticsearch timeout. Default: 30 -p PREFIX, --prefix PREFIX Prefix for the indices. Indices that do not have this prefix are skipped. Default: logstash- -s SEPARATOR, --separator SEPARATOR Time unit separator. Default: . -C CURATION_STYLE, --curation-style CURATION_STYLE Curate indices by [time, space] Default: time -T TIME_UNIT, --time-unit TIME_UNIT Unit of time to reckon by: [days, hours] Default: days -d DELETE_OLDER, --delete DELETE_OLDER Delete indices older than n TIME_UNITs. -c CLOSE_OLDER, --close CLOSE_OLDER Close indices older than n TIME_UNITs. -b BLOOM_OLDER, --bloom BLOOM_OLDER Disable bloom filter for indices older than n TIME_UNITs. -g DISK_SPACE, --disk-space DISK_SPACE Delete indices beyond n GIGABYTES. --max_num_segments MAX_NUM_SEGMENTS Maximum number of segments, post-optimize. Default: 2 -o OPTIMIZE, --optimize OPTIMIZE Optimize (Lucene forceMerge) indices older than n TIME_UNITs. Must increase timeout to stay connected throughout optimize operation, recommend no less than 3600. -n, --dry-run If true, does not perform any changes to the Elasticsearch indices. -D, --debug Debug mode -l LOG_FILE, --logfile LOG_FILE log file ","date":1390542480,"dir":"post/2014/","id":"15f501351d482ffd73985a50f5c89d1f","lang":"ja","lastmod":1390542480,"permalink":"https://blog.johtani.info/blog/2014/01/24/curator-tending-your-time-series-indices-in-japanese/","publishdate":"2014-01-24T14:48:00+09:00","summary":"Elasticsearchのcuratorのブログ記事を読んで、日本語でツイートしたところ、Aaron Mildensteinさんから日本語（","tags":["elasticsearch","curator"],"title":"Curator: 時系列インデックスの管理(日本語訳)"},{"contents":"あけましておめでとうございます。今年もSolrやElasticsearchについて色々と頑張っていく所存です。 とまぁ、お決まりの挨拶はおいておいてと。(もう、新年も22日ですが。。。)\nElasticsearchの1.0.0RC1がリリースされました。 ということで、私が作っているExtended-Analyzeプラグインも1.0.0RC1向けに修正してリリースしました。\n1.0.0RC1向けに修正したこと コミットログを見てもらえば、いいのですが、ロジック自体は変更しなくても良かったです。\nただ、正式に、Elasticsearchのつづりが決定したようで、クラス名が「ElasticSearchほげほげ」から、「Elasticsearchほげほげ」と、SearchのSが小文字になりっています。 この影響で、例外クラスなどの名称を幾つか変更しました。 また、バージョン番号を1.0.0RC1とし、0.x系をElasticsearchの0.90系向けのバージョンにしていく予定です。\n今後は、UIを追加したいと思っているので、Elasticsearchのバージョン番号とはずれてくるとは思いますが。。。\nElasticsearch 1.0.0RC1を利用してみて 1点だけですが。 これまでは、-fオプションを指定すると、デーモンではない動作で起動できていました。（デフォルトがデーモン起動）\nこれが、1.0.0から（0.90の最新もかな？詳しく見ていない）デフォルトの挙動が変更され、デーモン起動ではなくなりました。 代わりに、-dオプションを指定することで、デーモン起動ができるようになりました。\nこれで、手元でうっかりデーモン起動することがなくなって、ひと安心です。（他の人は困るかもしれないけど）\nということで 1.0.0RC1が出たので、少しずつ1.0系で追加されたAPIや機能について、ブログで紹介していけたらと思います。\nこんなこと調べてよ？、これわかんないんだけど？などありましたら、コメントいただければと。 気が向いたら記事を書くので。\nあと、Extended-Analyzeプラグインの感想などもお待ちしています！\n今年もよろしくお願いします！\n","date":1390317360,"dir":"post/2014/","id":"6425af51edead39c0e439073986043fb","lang":"ja","lastmod":1390317360,"permalink":"https://blog.johtani.info/blog/2014/01/22/release-extended-plugin-for-1-0-0rc1/","publishdate":"2014-01-22T00:16:00+09:00","summary":"あけましておめでとうございます。今年もSolrやElasticsearchについて色々と頑張っていく所存です。 とまぁ、お決まりの挨拶はおいて","tags":["elasticsearch"],"title":"Extended-Analyze 1.0.0RC1をリリースしました"},{"contents":"昨年は、大晦日に書いてました。 ちょっと進歩したかも。\n振り返り(2012年に書いた抱負から) ということで、まずは昨年書いた抱負からの振り返りです。\nIntelliJ IDEAをメインに使う JIRAを継続して活用 ブログの継続 elasticsearch Luceneのソースコードリーディング 何かOSSのソースを読む Macでもっと開発 読書と英語を継続 お。思ったよりもできてるかも。 IntelliJ IDEAについては、メインになりました。Eclipseを開くことはまずないです。 Macがメインの開発マシンにもなってきてるので。(開発してないんじゃないかという話も。。。)\nJIRAは一応、継続しているという感じです。\n唯一Luceneのソースコードリーディングができてないですね。。。 言い訳をすると、明示的にソースコードリーディングをしているわけではないですが、Luceneのソース自体は時々見ています。 SolrやElasticsearchを調べるとそのままLuceneにたどり着くことがあるので。\nポモドーロのタスク管理用に使っていますが、時々忘れていたり。あと、振り返りがまだちゃんとできてないので、そこをやらないとかなぁと。 読書と英語は今後も継続です。もっと習慣づけないと。\n振り返り(今年あった出来事など) CROSSでモデレータやりました Xperia Zに機種変 メニエール病 リクルートテクノロジーズさんのお手伝い Lucene In Action輪読やってる MIR輪読も継続 Solr勉強会を不定期開催 Elasticsearch勉強会を始めた Solr本の改訂版を執筆 AWSちょっと触った Elasticsearchプラグイン作ってみた Githubの活用 Octopressでブログ こんなかんじです。\nCROSSでは、モデレータをやらせていただきました。すこしは検索を面白いと思ってもらえたかなと思います。 来年のCROSS 2014ではスタッフとして盛り上げていく予定ですので、スタッフに興味ある方は声をかけてください！ 面白い話がいっぱい聞けますし、おいしい物も飲み食いできるかも！？\nXperia Zは良い買い物でした。ただ、すでに2回電源部分が故障してますが。。。 それ以外は非常に快適です。\n2月末から3月は少し休んでました。難聴→めまい→メニエール病という流れで、ちょっとしんどかったです。 ほぼ回復しましたが、原因は不明みたいなので、長く付き合ってくのかなぁと。\n4月からリクルートテクノロジーズさんの仕事を手伝っています(Solr本の著者紹介にも書いてます)。 色々と面白いことをしているATLという部署で面白い人達と仕事させて頂いてます。 来年もよろしくお願いします！(もっと価値を出さないとなぁ。。。)\nその一環で、Lucene In Actionの輪読を社内でやっていたりも。バージョンが3.x系で書かれているので、 ちょっと大変ですが、4だとどう違うかなどの話を交えつつ少しずつ読んでいます。\n輪読会といえば、MIR(Modern Information Retirieval)の輪読も続いています。 私は深いところまでわからないのですが、色々と詳しい方たちとボチボチ読んでます。教えてもらってばかりですが、来年も頑張りますよと。\nSolr勉強会も、引き継いでぼちぼちやっています。来年は1/29に開催します。Solrの入門的な話をしてもらうので、 ぜひ、触ったことがない方や興味がある人に参加していただきたいと。\nElasticsearch勉強会も主催し始めました。興味ある人がいるだろうとは思ったのですが、想像以上でびっくりしてます。 自分が理解を深め、発表するためにも、2ヶ月程度のスパンで来年も開催する予定です。 スピーカーに興味のある方は、elasticsearch-jpのMLや私にコンタクトしてください。\nSolr入門のSolr4対応版も執筆しました。今回は全体のコーディネートもやらせていただきました。 Solr活用のお役に立てていただければと。まだ購入してない方はぜひ、以下のリンクから！(PDF版もあります。) 質問などあれば、ブログにコメントをいただくか、ツイートしていただくか、技術評論社のサポートページに問い合わせていただければと思います。\nAWSをちょっとだけ触りました。 S3にバックアップ取ってるだけですが。。。来年はもう少し。。。 JIRA（さくらVPSに立ててる）のバックアップなどをやってます。\nあとは、Elasticsearchの勉強会も始めたこともあり、Elasticsearchを色々と触っています。 elasticsearch-analysis-kuromojiプラグインのREADMEを記述してコントリビュートしてみたり、 elasticsearch-extended-analysisプラグインを作ってみたり。\n勉強会のスピーカー探しも兼ねて、いろんなところに、「突撃!隣のElasticsearch」と称してElasticsearchの話を聞きに行きたいと思っていますので、使ってるよ！とか使いたいんだけど、どうすればいい？みたいな話があれば、声をかけてください。Twitterでツイート見たら勝手に、アタックすることもあるかもですが、その時はよろしくお願いします。\n来年はSolrやElaticsearchにもっと貢献できればと。\nGithub(git)もようやくまともに触り始めました。 某データの管理やプラグインの開発などでやっと触り始めました。 まだ、チーム開発ってほどではないので、チームで開発するときのやり方なども少しずつ勉強していこうかと。 プルリクとかも少しずつやってみたりしてます。\nあとは、Octopressでブログ始めました。その前はjugemだったのですが、なんとなく。 Markdownに慣れるためというのもありOctopressにしてみました。 (Solr本の原稿もMarkdownで書いてました) 昔のブログもこっちにコピーするプログラムも書いてみようかな。\n来年の抱負 Elasticsearch勉強会、Solr勉強会の継続＋ミックスした検索勉強会の開催 IDEAのさらなる活用 もっと開発(プラグインとか) AWSをもう少し活用 海外のイベントに行ってみたい 読書と英語を継続 勉強会の開催は今後も継続していく予定です。会場を毎回提供して頂いているVOYAGE GROUPさん、リクルートテクノロジーズさんには、 今後もお手数をお掛けしますが、よろしくお願い致します。勉強会の開催を通じて、色々な人のノウハウがうまく共有できて、 もっと本質的な作業（サービスの改善とか）に注力できる環境ができると面白いなぁと思ってるので。\nあと、Elasticsearch、Solrと別々の勉強会になっていますが、検索エンジン勉強会という形でそれぞれのメリット・デメリットを 共有できる勉強会も面白いかもと思っているので、春とかに開催したいなぁと考えてもいます。（まだ考えているだけで何もネタがないですが）\nIDEAは、年貢(13のサブスクリプション)を収めたので、もっと活用しないとという意味で。プラグインの開発、gitやsvnのクライアントとしては 活躍していますが、もっと開発に活用していかないとなぁと。まだ、10%くらいしか活用できてない気がするので。\nもっと開発しないとなと。毎年言ってますが。今年は書籍に注力したのもあり、ソースを読んだり英語を読んだりが多くなってました。 偉そうにしてるためか、開発する機会が減ってきているので、細かなことでもいいので、すこしずつコードを書いていこうかと。 （もっと自分で問題点を見出してそれを補完するようなコードなりプラグインなり書けばいいんだろうな。）\n開発と合わせて、AWSをもう少し触りたいなと。これも数年言っていますができてないです。。。 ネタ探すのが下手なのかなぁ。\n海外イベントにも行ってみたいです。まだ、海外行ったことないんですが。。。 Lucene Revolutionとか。その訓練も兼ねて英語でメール書いたり、プラグインのREADME書いたりしてみてます。\n最後は、毎年恒例ですが、読書と英語です。 Packtのキャンペーンで買ってしまった英語の本とか貯まっているので、読まないと。 nasneが便利で通勤時間にドラマ見てるからなぁ。ま、必要なときにボチボチと読んでいく予定です。\n最後は、いつものようにですが、来年も勉強会やいろんなイベントに参加する予定です。 ブログも週1程度で書く努力しないとなぁ。 こんな話を書いてくださいとかのリクエストもお待ちしています。\n今年もまだ、大晦日が残っていますが、色々とお世話になりました。 この場を借りてお礼申し上げます。\n来年も、いろんな方に絡んでいくとは思いますが、よろしくお願いいたします。\n","date":1388406000,"dir":"post/2013/","id":"10c715f70de25ccb493bbbb532b78ced","lang":"ja","lastmod":1388406000,"permalink":"https://blog.johtani.info/blog/2013/12/30/looking-back-2013/","publishdate":"2013-12-30T21:20:00+09:00","summary":"昨年は、大晦日に書いてました。 ちょっと進歩したかも。 振り返り(2012年に書いた抱負から) ということで、まずは昨年書いた抱負からの振り返りで","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2013）"},{"contents":"昨夜、Elasticsearchの0.90.8がリリースされました。\nリリースされた内容などについては、本家のブログ「0.90.8 released」をご覧いただくこととして。 1点注意したほうが良い点があります。\nelasticsearch-analysis-kuromojiを利用している場合は、0.90.8に対応したバージョンがリリースされるのを待つ必要があります。\nelasticsearch 0.90.8はLuceneのバージョンが4.6.0に変更されています。 Lucene 4.6.0では、TokenStreamというTokenizerのI/Fに変更があり、Tokenizerの実装を変更する必要があります。\n現時点（2013年12月19日現在）のelasticsearch-analysis-kuromojiの1.6.0にはlucene-analyzers-kuromoji-4.5.1.jarが含まれており、この部分でI/Fが異なるためエラーが発生してしまいます。 プラグインをインストールする時点ではエラーは発生せず、実際にKuromojiのTokenizerやAnalyzerを利用するタイミングでエラーが出ます。 以下、0.90.8にanalysis-kuromojiの1.6.0をインストールした状態で_analyzeを実行した時のエラー。\ncurl -XPOST \u0026#39;localhost:9200/_analyze?tokenizer=kuromoji_tokenizer\u0026amp;filters=kuromoji_baseform\u0026amp;pretty\u0026#39; -d \u0026#39;寿司が美味しかった\u0026#39; { \u0026#34;error\u0026#34; : \u0026#34;IllegalStateException[TokenStream contract violation: reset()/close() call missing, reset() called multiple times, or subclass does not call super.reset(). Please see Javadocs of TokenStream class for more information about the correct consuming workflow.]\u0026#34;, \u0026#34;status\u0026#34; : 500 } ということで、1.7.0がリリースされるのを待つか、自分でmvn packageしてビルドする必要があります。 他にも独自でTokenizerなどを造られている方は注意が必要かと。\nたぶん、すぐにリリースされるんじゃないかなぁと。\n2013/12/20追記\nとりあえず、masterブランチが0.90.8に変更されたみたいです。(と書いてるそばから、1.7.0がリリースされました) ということで、0.90.8では1.7.0を使うとエラーが出ないです。 （あと、踊り字対応のcharfilterも追加されたみたいです）\n","date":1387524240,"dir":"post/2013/","id":"c18b12fff24dc87e7f1039bd17c0c6aa","lang":"ja","lastmod":1387524240,"permalink":"https://blog.johtani.info/blog/2013/12/20/release-elasticsearch-0-90-8/","publishdate":"2013-12-20T16:24:00+09:00","summary":"昨夜、Elasticsearchの0.90.8がリリースされました。 リリースされた内容などについては、本家のブログ「0.90.8 releas","tags":["elasticsearch","kuromoji"],"title":"Elasticsearch 0.90.8がリリースされました＆注意点（2013/12/20追記）"},{"contents":"Solr本が出てから、質問を受けてブログ書くと言いながら書いてなかったことを思い出しました。。。\nプラグインの配置方法についてこんな質問を受けてたので、それっぽいエントリを書いておきます。（想像と違ってたらツッコミ入れてください）\n@johtani 追加でプラグインの配置方法とかあると便利かなと思いました\n\u0026mdash; Tsubosaka (@tsubosaka) 2013, 12月 2 改定前のSolr本では、日本語の形態素解析器をjarファイルとして追加する方法が書かれていました。 ただ、改定後のSolr本では、KuromojiがLuceneで実装されているためサンプルとしてjarファイルを追加するような方法の記載が明確にはありません。\n19ページのcollection1の説明ですこしだけ、libディレクトリについて触れています。\n独自のTokenizer（lucene-gosenなど）はjar形式でSolrに追加し、schema.xmlなどに利用するFactoryを指定してから利用します。\nこのとき、追加のjarファイルを配置する先がlibディレクトリです。\nlibディレクトリは2つの種類のスコープのディレクトリが存在します。\nSolr全体で利用可能なlibディレクトリ コア単位で利用可能なlibディレクトリ Solr全体で利用するlibディレクトリ これは、起動しているSolrにある全てのコアで利用するようなjarファイルを配置するディレクトリになります。 場所は$SOLR_HOME/libです。ここにjarファイルを配置することで、この$SOLR_HOMEを利用するすべてのコアで同じjarファイルを利用することができるようになります。\nですので、例えば、lucene-gosenはすべてのコアで利用するという場合にはここに配置すれば、1つのjarファイルを配置するだけで済むことになります。\nコア単位で利用するlibディレクトリ これは、コアごとにlibディレクトリを用意する場合です。 19ページにも記載されていますが、$SOLR_HOME/コアディレクトリ名/libとなります。\n特定のコアのみで利用するライブラリについてはこちらに配置する形になります。 他のコアで利用してほしくないjarファイルなどを配置するのに利用すればよいかと。\n簡単ですが、補足記事でした。 UIMAやlangidの利用方法などもあるとうれしですかね？ そのうち気が向けば書くかもしれません。（他の人に書いてもらうのもありかも。）\n","date":1387447740,"dir":"post/2013/","id":"cb5b6f7ab4d36e90d2619cb907ebb956","lang":"ja","lastmod":1387447740,"permalink":"https://blog.johtani.info/blog/2013/12/19/add-jar-file-to-solr/","publishdate":"2013-12-19T19:09:00+09:00","summary":"Solr本が出てから、質問を受けてブログ書くと言いながら書いてなかったことを思い出しました。。。 プラグインの配置方法についてこんな質問を受け","tags":["Solr"],"title":"Solrへのプラグインの配置方法について"},{"contents":"ども。 プラグインのインストールに長いURL入れるの辛いですよね？ね？\nということで、MavenでリリースしてMaven Repositoryからダウンロードできるようにしてみました。\n流れとしては\nSonatypeにリリースできるように申請する Sonatypeにリリースする SonatypeからMavenにSyncしてもらう という流れです。\nSonatypeにリリースするための方法はイケメンの人(@yusuke)がブログに簡単ですが残してくれてました。 あと、こちらの@vvakameさんのブログも参考にしながら作業しました。\n【最新版】Maven Central Repository へのライブラリ登録方法 #maven JsonPullParser が Maven Central Repository に入るようです pom.xmlについては、プラグインのpom.xmlを参考にしてもらえればと。 1.の作業が終わったら、リリースを実行します。\nこの時、\u0026lt;scm\u0026gt;タグにgithubの情報が記載されているため（？）、githubにタグを打つ作業もmavenコマンドがやってくれるみたいです。\nmvn release:prepare を実行すると、リリースするバージョンやタグ名などを聞いてくれます。 それらに答えると、pom.xmlにバージョンを指定してcommit\u0026amp;pushしてくれ、タグも打ってくれます。（なんて便利）\nその後、release:performにてSonatypeへのリリースが完了します。 あとは、Sonatypeの画面で作業したら、Mavenのリポジトリにそのうち同期してくれます。\nということで、次のコマンドを実行すればプラグインがインストールできるようになりました。0.6.0と0.7.0の違いは実装には差異はありません。リリース方法が変更されただけということになります。\nbin/plugin -i info.johtani/elasticsearch-extended-analyze/0.7.0 これで少しは活用してもらえるようになるかなぁ？ （どのくらいの人が使ってくれてるのかは不明。。。）\n","date":1387249860,"dir":"post/2013/","id":"a0a00c23556fcc5dbfb7b7f43fbbb61d","lang":"ja","lastmod":1387249860,"permalink":"https://blog.johtani.info/blog/2013/12/17/release-es-extended-analyze-plugin-to-maven-and-sonatype/","publishdate":"2013-12-17T12:11:00+09:00","summary":"ども。 プラグインのインストールに長いURL入れるの辛いですよね？ね？ ということで、MavenでリリースしてMaven Repositoryから","tags":["elasticsearch"],"title":"elasticsearch-extended-analyzeプラグインをMavenとSonatypeにリリース"},{"contents":"少し遅くなってしまいましたが、12/05に電子書籍も発売されました。\n技術評論社の電子書籍サイトから購入可能です。\n書籍のページへのリンク PDF版となっております。 購入の際は、技術評論社の電子書籍サイトに会員登録後購入可能となります。\n個人的には電子書籍が便利なので、こちらを普段活用しようと思っています。\nもちろん、紙の書籍も発売中です！購入の際は右の書影をクリックしていただければと！\n","date":1386554880,"dir":"post/2013/","id":"d9560caeb797b302191f667b4264da40","lang":"ja","lastmod":1386554880,"permalink":"https://blog.johtani.info/blog/2013/12/09/release-introduction-solr-ebook/","publishdate":"2013-12-09T11:08:00+09:00","summary":"少し遅くなってしまいましたが、12/05に電子書籍も発売されました。 技術評論社の電子書籍サイトから購入可能です。 書籍のページへのリンク PDF","tags":["Solr"],"title":"改訂版Solr入門のPDF版も発売"},{"contents":"勉強会で宣伝もしましたが、改めて。\nSolr入門の改訂版を執筆しました。 考えてみれば、もう3年も前なんですね、Solr入門は。 Solr勉強会などでも何度も新しいのは出ないのですか？と聞かれていましたが、やっと出ました。（お待たせしました。）\n時が立つのは早いものです。前回のSolr入門はバージョン1.4にて執筆していましたが、今回は4.4をベースにし、4.5.1への対応を行っています。\n月曜日には手元に見本が届き、今週金曜日に発売予定です！\nSolrCloud、SoftCommit、Spatial、Joinなど、多彩な機能についても記載してあります。 また、ManifoldCFというSolrにデータを登録するのに 利用できるコネクタフレームワークについても書いてあります。\nより多彩になったSolrの機能を活用するための一助となれればと思います。 （電子版も出る予定です。詳細についてはもう少々お待ちください）\nまた、出版を記念して少し時期が先になりますが、Solr勉強会を開催しようと思います。\n日時：2014年01月29日 第13回Solr勉強会 #SolrJP 新Solr本出版記念 今回はせっかくのSolr入門の書籍の出版記念ということで入門的な話をしてもらう予定です。 Solr初心者の方、Solrに興味のある方などに来ていただきたいと思っています。 （プレゼントも用意できるかも！？）\nということで、「改訂版Apache Solr入門」をよろしくお願いします。 （もちろん、購入は下のリンクからですよね！）\n","date":1385436420,"dir":"post/2013/","id":"a2012a3c9cdb1d6fd69afdbadc1e76b6","lang":"ja","lastmod":1385436420,"permalink":"https://blog.johtani.info/blog/2013/11/26/introduction-to-solr-new-edition/","publishdate":"2013-11-26T12:27:00+09:00","summary":"勉強会で宣伝もしましたが、改めて。 Solr入門の改訂版を執筆しました。 考えてみれば、もう3年も前なんですね、Solr入門は。 Solr勉強会な","tags":["Solr"],"title":"改訂版Solr入門を執筆しました"},{"contents":"どーも。以前の記事で開発中としていたプラグインですが、とりあえず、pluginコマンドでインストール出来る形にしてみました。\nインストールなどについては、READMEに記載したのでそちらを参照してもらうことにして、試行錯誤した話をメモとして残しておきます。\nプラグインの開発はしいてたのですが、やっぱりpluginコマンドでインストール出来ないと使ってもらえないよなということで、勉強会も終わったのでちょっと調べてました。\nプラグインコマンド コマンドが用意されてますが、実態はJavaで実装されてて、通常はこんなかんじでプラグインをインストールします。\n./bin/plugin -i elasticsearch/elasticsearch-analysis-kuromoji/1.6.0 この「elasticsearch/elasticsearch-analysis-kuromoji/1.6.0」という文字列ですが、「ユーザ名/リポジトリ名/バージョン」という意味になります。\nで、ダウンロードするURLは以下のものの中から選ばれます。\nelasticsearch.orgのダウンロード用サイト search.maven.org oss.sonatype.org Githubのarchive これらのサイトに先ほどのユーザ名、リポジトリ名、バージョンを利用したURLを組み立てて、ダウンロードしてくれるという仕組みになっています。\nelasticsearch.orgについては、本家の人しかアップロードできないと思うので、なし。\nmaven、sonatypeについては、Mavenのリポジトリにリリースする必要があるんじゃないかなと。 で、昔調べてググって途中で挫折したんですが、挫折してます。手順が結構手間で。。。 （参考記事：【最新版】Maven Central Repository へのライブラリ登録方法 #maven）\nということで、Githubにアップしたらなんとかなるんじゃん？ということで色々と調査して試してみました。（結果はイマイチなんですが。。。）\nその１：mvn release:prepare せっかくGithubだし、せっかくMavenなんだしなんか、pom.xmlに便利な設定したらコマンド一発でリリースできるんじゃない？という甘い気持ちで調査したググったらそれっぽい記事が見つかりました。 「MavenとGitHubの連携」って記事です。\nで、pom.xmlの設定にも他のプラグインを真似してコピペしたものに\u0026lt;scm\u0026gt;ってタグがあったなぁと。このコマンドでついでにGithubにアップロードできるんじゃないの？ということで、試してみました。\nmvn release:prepare このコマンドを叩くと、記事にあるとおりにいくつか質問をされます。 タグについては、プロジェクト名-バージョン番号という文字列がデフォルトだと指定されているので、v0.5と変更して実施してみると、Githubのreleaseにv0.5ってのができてるじゃないですか。\n※pluginコマンドはGithubを見に行く時に次のファイルをダウンロードしに行きます。\nhttps://github.com/ユーザ名/リポジトリ名/archive/vバージョン名.zip やった！と思い、早速pluginコマンドを実行してみましたが、エラーが出ました。。。\nTrying https://github.com/johtani/elasticsearch-extended-analyze/archive/v0.5.zip... Downloading ...DONE Installed johtani/elasticsearch-extended-analyze/0.5 into /Users/johtani/projects/tmp/ess_env/second_node/elasticsearch-0.90.7/plugins/extended-analyze Usage: -u, --url [plugin location] : Set exact URL to download the plugin from ...省略... Message: Error while installing plugin, reason: IllegalArgumentException: Plugin installation assumed to be site plugin, but contains source code, aborting installation. あらら、なんで？と。\nで、実際にgithubにアップされてたzipファイルをダウンロードしてみたら、githubのリポジトリにあるディレクトリ構成がそのまま入ってるじゃないですか。。。 そうですか、そうですよね。prepareだし、タグ打ってzipにかためてくれるだけなんですねと。。。\nおそらく、siteプラグインだけの場合はこの方法でpluginコマンド叩けばOKなんでしょうが、私がダウンロードしてもらいたいのは.jarファイルが入ったzipファイルなんです。\nということで、断念しました。（タグ消したりをgitコマンドで叩いて綺麗にし直すとか虚しい作業をしてました）\nその２：github.comのWebでリリース おとなしく、Sonatypeのサイトにアップロードする方向でがんばればいいんですが、とりあえず使えるようにするのが先だと思い、 github.comのページでアップロードしてしまおうと。\n「release」というタブをクリックすると、画面からアップロードできるようになります。\nzipファイルを作ってアップロードしました。（zipファイル自体はmvn packageコマンドを実行したらtarget/releaseというディレクトリに作成されてる）\nこれで行けるだろということで、またpluginコマンドを実行すると\nTrying https://github.com/johtani/elasticsearch-extended-analyze/archive/v0.5.zip... Downloading ...DONE Installed johtani/elasticsearch-extended-analyze/0.5 into /Users/johtani/projects/tmp/ess_env/second_node/elasticsearch-0.90.7/plugins/extended-analyze Usage: -u, --url [plugin location] : Set exact URL to download the plugin from ...省略... Message: Error while installing plugin, reason: IllegalArgumentException: Plugin installation assumed to be site plugin, but contains source code, aborting installation. あれ？同じエラー？なんで？jar入りのzipファイルアップロードしたのに？？？\nと。で、https://github.com/johtani/elasticsearch-extended-analyze/releasesにreleaseのページができてたので見てみると、あら。 アップロードしたファイルについては次のようなURLになってるじゃないですか。\nhttps://github.com/johtani/elasticsearch-extended-analyze/releases/download/v0.5/v0.5.zip で、よく見ると「Source code(zip)」というボタンもあるぞ？このリンクは？\nhttps://github.com/johtani/elasticsearch-extended-analyze/archive/v0.5.zip 。。。あぁ。そうですか。そういうことですか。理解してない私が悪いんですねと。\n結論？ ということで、とりあえず、releaseにjar入りファイルはアップロードできた（手動で）ので -uオプションで直接URL指定すればインストールできるだろ！と諦めました。 いい勉強になりました。。。\nREADME見ていただくとインストール方法が分かりますが、長いです。。。\n時間をとって本腰入れてSonatypeにMavenコマンドでアップロードできるようにしようかな。。。\n","date":1384419300,"dir":"post/2013/","id":"13684d16fdd07d5f0584e29265a270e7","lang":"ja","lastmod":1384419300,"permalink":"https://blog.johtani.info/blog/2013/11/14/release-elasticsearch-extended-analyze-0-dot-5/","publishdate":"2013-11-14T17:55:00+09:00","summary":"どーも。以前の記事で開発中としていたプラグインですが、とりあえず、pluginコマンドでインストール出来る形にしてみました。 インストールなど","tags":["elasticsearch","plugin"],"title":"elasticsearch-extended-analyzeを公開？"},{"contents":"第2回を開催しました！ すごい、140人くらいくらいの参加登録者（参加者は１００人ちょっと！）がいて、びっくりです。 ステキな会場を提供していただいた、リクルートテクノロジーズさん、運営していただいた方々、スピーカーの皆さん、参加者の皆さん本当にありがとうございました。 今回も素敵な看板ありがとうございます。\n今回もしっかり楽しめたので、次回も頑張ります！\n今回は、elasticsearch-jpMLの紹介とかをできたのでよかったかなぁと。 ぜひ、活用してください！どんな質問でもいいので。\nあと、スライドに入ってた例の本もよろしくです。\nということで、懇親会も盛り上がったし楽しかったです。 今後も場の提供＋自分の勉強のトリガーとして、開催していくので、ご協力お願いします！ 聞きたい話など、MLや@ツイートしていただければと。\nelasticsearchのRouting機能：株式会社シーマーク　大谷　純　（@johtani） スライド：Routing機能※スライドはPDFです。\nド緊張で、大した発表ではなかったですが。。。 どちらかと言うとSolr本の紹介だったかもなぁ。スミマセン。\n※スライドが一部文字が消えてるので、作りなおすかも。\nElasticSearchを使ったBaaS基盤の開発(仮)：株式会社富士通ソフトウェアテクノロジーズ 滝田聖己さん（@pisatoshi） スライド：https://speakerdeck.com/pisatoshi/elasticsearch-trial-and-error\n本日はお越しいただきありがとうございました！しかも静岡から！今後もよろしくお願い致します。\nEnchantMoonでシステム構成ｗ\n0.17.0から利用されていると。（スゴイ）\nプライマリのデータストア！ただし、登録元データはMySQLにもある。\n階層も深く、大きめのドキュメント。\nレプリカ１、インデックスのバックアップも取ってないと。。。\nルーティングの機能\nDynamicMappingの問題点\nマッピング定義が肥大、型がコンフリクト。。。苦労しっぱなし\nデータ登録は１台にして、１台で一気に登録してから再配置\n実際に運用とかされてるので、いろんなノウハウがまだまだありそう！\nKibana入門：水戸祐介さん（@y_310） スライド：https://speakerdeck.com/y310/kibanaru-men\n（やっぱりru-menになってるｗ）\n実は、押しかけて話してもらうように説得したのでした。今後もよろしくです。\nCOOKPADの方によるKibanaのお話。 Kibanaの利点とかなんで？とか。 画面構成の説明から ダッシュボードは必ず保存して！リロードしたら悲しい思いをしてしまうので。 sparkline便利そうだなぁ。ほんとに、データサイエンティスト系のツールを目指してるのかな 一通り、ダッシュボードに配置できるパネルの説明してもらえたのですごく参考になりました！ Tips周りが役に立ちそう。not_analyzedは重要ですよね。 LT 「データ集計用ダッシュボードブラウザとしても使えるElasticSearch＋Kibana v3を利用する際の運用ノウハウ紹介」：株式会社リブセンス Y.Kentaro さん (@yoshi_ken) さん スライド：http://www.slideshare.net/y-ken/elasticsearch-kibnana-fluentd-management-tips\nKibanaの紹介とかFluentdの紹介。 Tips満載すばらしい。 JDBC riverは0.90.6ではうまく動かないので、気をつけてと。 「Fluentd as a Kibana」：@repeatedly さん スライド(gist)？：https://gist.github.com/repeatedly/7427856\nKibanaがfluentdの中で動くと！？\n「Authプラグインでアクセスコントロール」：株式会社エヌツーエスエム 菅谷信介さん (@shinsuke_sugaya) スライド：http://www.slideshare.net/shinsuke/es-auth-plugin\nAPI毎？インデックスごと？にアクセス制御ができるプラグイン\n","date":1384247760,"dir":"post/2013/","id":"66f43ab4b823d67f52735bbbe6ba65b0","lang":"ja","lastmod":1384247760,"permalink":"https://blog.johtani.info/blog/2013/11/12/elasticsearch-japan-user-meetup-no2/","publishdate":"2013-11-12T18:16:00+09:00","summary":"第2回を開催しました！ すごい、140人くらいくらいの参加登録者（参加者は１００人ちょっと！）がいて、びっくりです。 ステキな会場を提供していた","tags":["elasticsearch","kibana","fluentd","勉強会"],"title":"第2回elasticsearch勉強会を開催しました！ #elasticsearchjp"},{"contents":"Cloudera World Tokyo 2013に参加してきました。\n午前中はあいにくの雨でしたが、それでも結構な人数が最初の基調講演から参加されてました。 私が参加したセッションは大盛況な感じでした。\nおみやげとしてカステラも頂いちゃいました！\nまた、色々なセッションに現れたこんなメッセージ画像も見つけました！\n昨日の写真データの整理をしていたら、こんなものが・・・ @shiumachi さんよ・・・ #cwt2013 pic.twitter.com/S0JsxSYXIx\n\u0026mdash; Kenichiro HAMANO (@hamaken) November 8, 2013 やっぱり、スーツの人が多いなという印象。\n名刺を毎回回収されるのはちょっとつらかったです。なにか、いい方法ないですかねぇ。\n以下はいつもの個人メモです。\n「ビッグデータプラットフォームとして進化するHadoop」 Cloudera株式会社　代表取締役　ジュセッペ小林氏 Costcoなどの写真を元にビッグデータを可視化 BigDataとHadoopの関係 検索、SQL、機会学習、数理処理、データ管理などにもHadoopの活用されつつある。 セキュリティ、データ管理、クラスタ上でのツールの実行なども増えてきてる。\n「今日ビッグデータは明日のスモールデータ」\nアーキテクチャとしてのビッグデータ 多種多様なデータを一箇所に集約し、生データを直接活用できる。 OSSとしての責任も。\nデータサイエンス Opsだけでないデータ解析にも活用\n「Clouderaのビッグデータプラットフォーム戦略」（仮） 講師：Cloudera, Inc. CTO Dr.Amr Awadallah レガシーな情報アーキテクチャ→スケールできない、可視化の限界、硬直したスキーマなどなど。\nエンタープライズデータハブとしてのHadoopとか。\nビッグデータの歴史と将来展望 講師：国立情報学研究所　アーキテクチャ科学研究系　教授　佐藤一郎氏 ビッグデータの歴史的経緯とか 最初の事例はアメリカの1880年国勢調査。\n「ビッグデータがコンピュータを生み出した」。コンピュータがビッグデータを生み出したんじゃない。\n少量データにもHadoopを\nバッチ処理のリアルタイム化とか（一晩から10分へ） 原点は検索データのインデクシング\nHadoopを使うのが目的じゃないんだから、構築には手を掛けないのがいいよね。\nプラットフォームと発展している\n分散システム研究者から見たHadoop 分散ししテムの難しさを、処理範囲を限定することで巧みに回避 データの近くで処理 研究レベルではリアルタイム化や逐次処理化が活発 全工程で逐次・リアルタイムが必要とは限らない 聞いてばかりじゃなくて、動かしてみましょう。 データサイエンス：超並列分散処理を活用した新たなビジネス価値の創出 講師：アクセンチュア株式会社　工藤卓哉氏 「日経BPのビッグデータ総覧2013」に記事書いてる。 多様化するデータ（社外のデータも）をどうやってうまく活用していくか。 データが教えてくれたこと→まず、データありき、まずデータためましょう。それから解析とかすればいいのでは？というはなし？ 競合他社さんはNGだけど、ブースでデモ？実機？が見れますと。 Hadoopデータプラットフォーム Cloudera株式会社　嶋内　翔氏 まずは宣伝 Cloudera Implaraのフリーブックの日本語版 Hadoop Operationの書籍でるよ プラットフォームを構成するもの Flume Sqoop HBase Hive Impala データ登録してBIアナリストのお仕事にどうやって役立てる？ 外部テーブル：Hiveからはテーブルのように見える仕組み。元ファイルは消えない SerDe（さーでぃー）：データをHiveレコードに変換する仕組み 生データを少し加工しましょう 圧縮したりファイル結合したりはしときましょう。 Hadoop活用のポイント 富豪的プログラミング。リソースケチるな。 ローカルでできることはローカル。むりにHadoopでやんなくてもいいですよねと。バランス重要 スケジューリング実行などはOozie使うと便利。（日次集計とか） Cloudera Searchで元データにインデックス貼れるぞと。検索しながら分析ができる クラスタ管理とか Cloudera manager便利ですよ ストレージリソースの管理。 声掛け、管理者が容量チェック、Cloudera Managerのレポート 少数精鋭でHadoop使おう＝手が回らなくなる。 みんなで使おう＝Kerberos認証とか管理をちゃんと考えないと。けど、文化が根付けば強力。Sentry、Cloudera Navigatorとか。 Hadoopシステムの全体構成図。データの流れと各製品のつながり。 We are hiring!ということで、興味のある方は@shiumachiさんにコンタクトをとりましょうとのこと。 SQLで実現するバッチ処理とストリーム処理 LINE株式会社　田籠 聡氏 資料：Batch and Stream processing with SQL\nLINEのキャラがちらほら出てきた。\nSQL好きですか？\nログの量とか。2.1TB/Day\nバッチ処理とストリーム\n速い集計のためにHadoopが重要 エラー系のログとかはストリームで処理したい\nアーキテクチャ説明\nデータ解析する人って色々。\n管理者 プログラマ サービスディレクタ 経営陣 みんなが集計用処理を理解、編集ができるほうがいい。\n顔あげたらHiveアイコンだらけだったｗ\nShibとか。\nなんでHiveに限るの？\nHiveに着目したバージョンアップだけを考えれば良くなる。 スケジュールクエリが増えてきて、つらい。\nTimeWindowを固定して集計処理をすることで、回避できる。 Norikra!! スキーマレス\nOSS。Esperベース。\nインストールが楽\nクエリの動作のお話。\nhttp://norikra.github.io\nWe Are Hiring!\nHadoop コミュニティと YARN の現状 日本電信電話株式会社　小沢 健史氏 なんでHadoop？ PostgreSQLでやってたけど、大きなデータにはHadoopを使おうという感じになってきた。 なんで使い分けるの？ スキーマ後付け NTTDocomoのモバイル位置情報の統計処理とか？ 技術的な話をするので、HiveTに着替えます！ｗ YARNのなにが嬉しいの？ ImpalaとMapReduceが同時に動くような環境の時に、リソースをうまく管理できないのがV1 そこでYARN Apache Mesosとだいたい一緒。 Apache MesosとYARNの比較 ","date":1383786660,"dir":"post/2013/","id":"a106d7c1b1b277538367f9c8140e3a75","lang":"ja","lastmod":1383786660,"permalink":"https://blog.johtani.info/blog/2013/11/07/cloudera-world-tokyo-2013/","publishdate":"2013-11-07T10:11:00+09:00","summary":"Cloudera World Tokyo 2013に参加してきました。 午前中はあいにくの雨でしたが、それでも結構な人数が最初の基調講演から参加されてました。 私が参加したセッショ","tags":["Cloudera","Hadoop","Norikra"],"title":"Cloudera World Tokyo 2013に参加しました！ #cwt2013 "},{"contents":"またまた、Riak Meetup Tokyo #3に参加してきました。Riak2.0のYokozunaの話があると聞いたので。\nということで、いつものように個人メモです。\n今日は自重して、懇親会はアルコールなしにしました。思いがけずfluentd＋elasticsearch+kibanaという組み合わせの話も聞けて大満足です。 Yokozunaのデモが見れなかったのがちょっと残念だったかなぁ。\n少しだけSolr本の宣伝もしてきちゃいました。\n古城さん@Mixi 「RiakCSとmixi プライベートクラウド環境」 プライベートクラウドとは？ 計算リソースが安い（ストレージは微妙） 開発者が好きに使える環境＋運用側のチケットに追われる毎日からの開放 Riak CSの概要 S3互換の分散ファイルストレージ 検証とか 検証時はRiak CS 1.3\n5ノードで2Mファイルを40万個\n削除は遅延で削除される\nPUT性能とか。\nRiak CSの死活監視にはRiakのstatsとか\n障害対応とか\nクラスタ クラスタは3つ。ログ、サービス（画像） 、バックアップ保存用 ログの収集にfluentd、解析にelasticsearchやkibanaを使っているらしい。 篠原＠Basho 「Riak 2.0: 分散データ型、セキュリティ、そしてより容易な運用へ」 riak 2.0 pre5をリリース アプリ向け機能強化、運用の容易性 設計ポリシーとか、1.xとか 運用、高可用性、水平拡張性 Capabilityネゴシエーションとか 2.0の機能強化 バケットタイプ キーの名前空間としてバケットがあったけど、同種のバケットをまとめて管理とかしたくなった。 データ型の導入（CRDT） Setデータ型 セキュリティとか 強い整合性\u0026hellip; 鈴木@Basho 「Yokozuna: Riak 2.0の新しい全文検索機能」 YokozunaやSolrの概要 1ノードにRiakとSolrが1プロセスずつ SolrプロセスはRiakが管理してくれる SolrCloudは使ってません。 Riakのノードに届いたデータをSolrに裏で書き込んでくれる。 検索時にはRiakのノードが分散検索をしてくれる X-Riak-Metaもインデクシングしてくれる。jsonやxmlの各要素をSolrのフィールドとして認識してくれる。 Extractor Solrは4.4で、JVMは1.7をユーザが入れるらしい。\n","date":1383746460,"dir":"post/2013/","id":"9dca844d353efed03fbaddfc0fab7c76","lang":"ja","lastmod":1383746460,"permalink":"https://blog.johtani.info/blog/2013/11/06/riak-meetup-tokyo-no3/","publishdate":"2013-11-06T23:01:00+09:00","summary":"またまた、Riak Meetup Tokyo #3に参加してきました。Riak2.0のYokozunaの話があると聞いたので。 ということで、いつものように個人メモで","tags":["Riak","Yokozuna"],"title":"Riak Meetup #3 #riakjp に参加しました。"},{"contents":"開発中ですと書きました、elasticsearch-extended-analyzeですが、改良しました。\n改良と変更は以下のとおりです。\nソースのパッケージをorg.elasticsearchからinfo.johtaniに。MLで気になったので質問したら、変えたほうがいいよとのこと。ダウンロード化については、もう少々お待ちを。 出力形式を変更。可能な限りCharFilter、Tokenizer、TokenFilterそれぞれが出力する内容を返すようにしました。 ただし、既存のAnalyzer（JapaneseAnalyzerクラスとか）に関しては、現時点では出力しません。CharFilterなどを取得するI/Fが見えないためです。（改良できるかの調査は未着手） 現時点でできてないのは以下の項目\npluginコマンドでインストール 出力したいAttributeの指定 TokenizeChainで変更されたTokenの追跡（現状はどのTokenがStopFilterで消されたかなどが不明） 画面の用意（簡単に確認できる画面） ということで、README.mdに出力サンプルは貼り付けてるので、興味のある方は試してみてください。 不明点などあれば、コメントかIssueかツイートでも。\n","date":1383570720,"dir":"post/2013/","id":"b5c628b0c1dbf857a475c4be5de4690d","lang":"ja","lastmod":1383570720,"permalink":"https://blog.johtani.info/blog/2013/11/04/improve-output-extended-analyze/","publishdate":"2013-11-04T22:12:00+09:00","summary":"開発中ですと書きました、elasticsearch-extended-analyzeですが、改良しました。 改良と変更は以下のとおりです。 ソー","tags":["elasticsearch","plugin"],"title":"elasticsearch-extended-analyzeの改良"},{"contents":"お久しぶりです。 気づいたらまた、結構ブログを書いてなかったです。。。\n今回は、今開発しているElasticsearchのプラグインに関するお話です。\nいやぁ、名前決めるの難しいですね。これで英語的に合ってるか不安ですが、elasticsearch-extended-analyzeというプラグインを作っています。\nどんなもの？ Solrの管理画面のanalysisに相当する機能が欲しくて作り始めました。\nElasticsearchにはanalyze APIというAPI（名前あってるのかなぁ?）が存在します。\nこれは、文字列を投げると、指定したアナライザやトークナイザでどのようなトークンに分割されるかを調べることができるAPIです。\n例えば、elasticsearch-analysis-kuromojiをインストールしたElasticsearchに対して、以下のcurlコマンドを実行します。\ncurl -XPOST \u0026#39;localhost:9200/_analyze?tokenizer=kuromoji_tokenizer\u0026amp;filters=kuromoji_baseform\u0026amp;pretty\u0026#39; -d \u0026#39;寿司が美味しい\u0026#39; すると、トークナイズされた結果が次のようなJSONで返ってきます。\n{ \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;寿司\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 2, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 1 }, { \u0026#34;token\u0026#34; : \u0026#34;が\u0026#34;, \u0026#34;start_offset\u0026#34; : 2, \u0026#34;end_offset\u0026#34; : 3, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 2 }, { \u0026#34;token\u0026#34; : \u0026#34;美味しい\u0026#34;, \u0026#34;start_offset\u0026#34; : 3, \u0026#34;end_offset\u0026#34; : 7, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 3 } ] } トークナイズの結果がわかるのは嬉しいのですが、どんな品詞なのかといったKuromoji固有のTokenの属性情報がなくなってしまいます。\nSolrでは、こんな画面が用意されていて、品詞情報とかが出力されます。あとは、各TokenFilterでどのトークンがなくなっているかなどもわかるようになっています。\nこれって結構役立つと思うんですよ。 ということで、Pluginも作ってみたかったので、いい機会だから作ってみようかと。\n出力サンプル まずは、その他のAttribute（品詞とか）を表示するところを実装してみました。\ncurl -XPOST \u0026#39;localhost:9200/_extended_analyze?tokenizer=kuromoji_tokenizer\u0026amp;filters=kuromoji_baseform\u0026amp;pretty\u0026#39; -d \u0026#39;寿司が美味しい\u0026#39; 先ほどとほぼ一緒のcurlコマンドを実行します。違う点は**「_analyze」が「_extended_analyze」**となっている点です。\nで、実行結果はこんな感じです。（長いですがそのまま載せてます。続きの文章がしたにあります。）\n{ \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;寿司\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 2, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 1, \u0026#34;extended_attributes\u0026#34; : [ { \u0026#34;org.apache.lucene.analysis.tokenattributes.TermToBytesRefAttribute#bytes\u0026#34; : \u0026#34;[e5 af bf e5 8f b8]\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.PositionLengthAttribute#positionLength\u0026#34; : 1 }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.BaseFormAttribute#baseForm\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech\u0026#34; : \u0026#34;名詞-一般\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech (en)\u0026#34; : \u0026#34;noun-common\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading\u0026#34; : \u0026#34;スシ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading (en)\u0026#34; : \u0026#34;sushi\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation\u0026#34; : \u0026#34;スシ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation (en)\u0026#34; : \u0026#34;sushi\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType (en)\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm (en)\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.KeywordAttribute#keyword\u0026#34; : false } ] }, { \u0026#34;token\u0026#34; : \u0026#34;が\u0026#34;, \u0026#34;start_offset\u0026#34; : 2, \u0026#34;end_offset\u0026#34; : 3, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 2, \u0026#34;extended_attributes\u0026#34; : [ { \u0026#34;org.apache.lucene.analysis.tokenattributes.TermToBytesRefAttribute#bytes\u0026#34; : \u0026#34;[e3 81 8c]\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.PositionLengthAttribute#positionLength\u0026#34; : 1 }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.BaseFormAttribute#baseForm\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech\u0026#34; : \u0026#34;助詞-格助詞-一般\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech (en)\u0026#34; : \u0026#34;particle-case-misc\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading\u0026#34; : \u0026#34;ガ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading (en)\u0026#34; : \u0026#34;ga\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation\u0026#34; : \u0026#34;ガ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation (en)\u0026#34; : \u0026#34;ga\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType (en)\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm (en)\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.KeywordAttribute#keyword\u0026#34; : false } ] }, { \u0026#34;token\u0026#34; : \u0026#34;美味しい\u0026#34;, \u0026#34;start_offset\u0026#34; : 3, \u0026#34;end_offset\u0026#34; : 7, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 3, \u0026#34;extended_attributes\u0026#34; : [ { \u0026#34;org.apache.lucene.analysis.tokenattributes.TermToBytesRefAttribute#bytes\u0026#34; : \u0026#34;[e7 be 8e e5 91 b3 e3 81 97 e3 81 84]\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.PositionLengthAttribute#positionLength\u0026#34; : 1 }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.BaseFormAttribute#baseForm\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech\u0026#34; : \u0026#34;形容詞-自立\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech (en)\u0026#34; : \u0026#34;adjective-main\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading\u0026#34; : \u0026#34;オイシイ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading (en)\u0026#34; : \u0026#34;oishii\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation\u0026#34; : \u0026#34;オイシイ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation (en)\u0026#34; : \u0026#34;oishii\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType\u0026#34; : \u0026#34;形容詞・イ段\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType (en)\u0026#34; : \u0026#34;adj-group-i\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm\u0026#34; : \u0026#34;基本形\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm (en)\u0026#34; : \u0026#34;base\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.KeywordAttribute#keyword\u0026#34; : false } ] } ] } 先ほどの結果に**「extended_attributes」**という配列のオブジェクトが追加された形になっています。 ちょっと長くなってしまいましたが。。。\nSolrの処理を真似して作ったので大したことはやってないんですが、少しは便利になるかもなぁと。\n現時点では、最終的な結果しか取得できないですが、今後は次のような機能を作っていこうかと思っています。 できるかどうかは、やってみてって感じですが。\npluginコマンドでインストール pom.xmlはありますが、まだMavenとかに登録はされていません。ですので、mvn packageしてからjarファイルをpluginsフォルダに配置しないといけません。pluginコマンドでインストールできるともっと使ってもらえるはず？ 出力したいAttributeの指定 リクエストパラメータで、出力したいAttribute名を指定するとか。 出力形式の変更 今は、Solrの真似をしていますが、せっかくJSONだったりするので、もう少し検討しようかと（同じAttributeの異なる値も1オブジェクトとして出力されてる） TokenizeChainの出力 Solr同様、CharFilter、Tokenizer、TokenFilterが動作して、最終的なTokenがインデックスに登録されます。ですので、各処理の直後のTokenがどうなっているかもわかったほうが嬉しいと思うので、それらも取得できるようにしたいなぁと 画面の用意 せっかくプラグインなんだし、画面で見れると嬉しいかなと。これは当分先になっちゃうと思いますが、Webページで確認できるような画面を作ると確認しやすくなるかなぁと。上記対応が終わってから取替かかると思いますが。 とりあえず、思いつくのはこんなかんじです。\nElasticsearchの_analyze APIを真似しただけのコードだし、テストも実装もまだまだですが、とりあえず公開してみました。\n要望などあれば、コメント、Issue、ツイート（もちろん、テストコードなども！）なんでも受け付けてますので、お気軽に。\n","date":1382695560,"dir":"post/2013/","id":"0302e8a57a5e8604342a925b2dc60737","lang":"ja","lastmod":1382695560,"permalink":"https://blog.johtani.info/blog/2013/10/25/developing-es-extended-analyze-plugin/","publishdate":"2013-10-25T19:06:00+09:00","summary":"お久しぶりです。 気づいたらまた、結構ブログを書いてなかったです。。。 今回は、今開発しているElasticsearchのプラグインに関するお話","tags":["elasticsearch","plugin"],"title":"elasticsearch-extended-analyzeプラグインを開発中"},{"contents":"不定期開催ですが第12回Solr勉強会を主催しました。\n今回は、前回ほどの過熱ぶりでは無かったですが、70人ほどの参加者の方がいらっしゃったかと。 ありがとうございます！\n今回は聞きたかったYokozunaの話をしてもらいました。あと、リベンジManifoldCF。 一部、追記しました。Bashoさんからツッコミがあったので。あと、4.5.1の話とか。\nManifoldCFのとSolrの組み合わせ（仮）株式会社 ロンウイット　大須賀　稔さん 前回お休みだったのでリベンジですw。\n英語だ。。。やっぱ英語がいいですか、スライド。。。\nManifoldCFの概要から。 最新版は1.3です。色々サポートしてるなぁ。\nデモもありました。（やっぱりちゃんと動かないので、鬼門みたいですが）\nデモ ManifoldCFのGUIで操作しながら。 いまいちちゃんと動かなかった。。。\nQA Q:Zipはうまく動かなかった A:Solr側で処理してくれてる。 Q:Notes対応するの？ A:いまのところない。 Q:ExcelとかPDFはTika？ A:Tika次第です。 Q:認証周りどこから取ってくるの？ A:クローラ側にはなくて、SharePointとかの権限をみてる。 Q:Web系の認証は？ A:まだないのでは。。。（調査します） あー、デモの続き忘れてましたね。。。\nSolrを組み込んだRiak 2.0の全文検索機能 -Yokozuna- Bashoジャパン株式会社　鈴木　一弘さん Riak色々使われてるよ！アングリーバードとか、Y!とか。 Riakで提供されている1機能としてのYokozuna。単独製品ではないですよと。\nRiakの説明。スケールするよ、いつでもRead/Writeできるよ、運用にフォーカスしてるよと。 マスターレスですよ。 Riak2.0のリリースは2013年末。Yokozunaもかな？\nダイナミックフィールド使ってるので、Yokozunaをonにするだけで簡単に使えるよ。\nRiakがSolrのプロセスを管理。\nインデックスの不整合の検知とかってどうやってるのかなぁ？ インデックス比較用のハッシュツリーをノード間でコピーしつつ検査してる。（Active Anti-Entropy）\n(デモには魔物がいるようだ。。。)\nQA Q:JSONの属性を元にしてフィールドにインデックス可能か？ A:可能です。IIJさんの発表で話が出ます。 Q:ProtocolBufferでSolrにアクセス可能？ A:そのうちできそうです。リリース時にはできるようになっています。 Q:コアのスワップは？スキーマの変更は？ A:事前に設定するのは可能。 Q:RiakのデータとSolrでデータがずれるってのはあるの？ A:可能性はありますが、極力ずれAAEで修復。 Q:復旧中のインデックスにアクセスが行かないようにする仕組みなどはある？ A:今はないです。 Yokozuna ベンチマークしました　株式会社インターネットイニシアティブ　曽我部　崇さん、田中 義久さん いいとこ取りで楽だなぁと。いうことで、試してみてます。 デモが動いてる。\nextractorでXMLやJSONをパースできる。 ベンチマーク結果。\nRiak Meetup Tokyo #2の時のQAも入ってるので助かります。素晴らしい。\nQA Q:スナップショットは両方取れるの？ A:Riakは取れますが、インデックスは今は無理です。 フォロー:0.8はYokozunaにボトルネックがあったので、0.9以降だともっと性能が出るはずですとのこと。また次回とかに発表してもらうのもありですかねぇ。 Solr 4.5の新機能など @johtani 発表資料のPDFです。\nツイート見てて誤解を招いたなと思ったのですが、7u40は4.5限定ではなく、すべてのバージョンと考えてください。 チケットを見ると分かりますが、影響バージョンの記載はありません。\n※あ、4.5のChangesを紹介しましたが、4.5.1が出るかも。このへんが困ってるらしいです。\nSOLR-5306: can not create collection when have over one config SOLR-5317: CoreAdmin API is not persisting data properly LUCENE-5263: Deletes may be silently lost if an IOException is hit and later not hit (e.g., disk fills up and then frees up) LT @haruyama さん 資料：http://haruyama.github.io/solr_20131009/#(1)\n記号が捨てられるTokenizer困るので、捨てないのを作ってみました。\nKuromojiの困ったこと。全角数字を分解しちゃう。→MappingCharFilterFactoryで全角から半角にしましょう。 lucene-gosenデフォで半角記号が未知語になってしまい、半角カナと混ざるので、記号を全角にしましょう。\n","date":1381372500,"dir":"post/2013/","id":"76e127a44931bfefab991be3dd7a08b7","lang":"ja","lastmod":1381372500,"permalink":"https://blog.johtani.info/blog/2013/10/10/solr-meetup-memo/","publishdate":"2013-10-10T11:35:00+09:00","summary":"不定期開催ですが第12回Solr勉強会を主催しました。 今回は、前回ほどの過熱ぶりでは無かったですが、70人ほどの参加者の方がいらっしゃったか","tags":["Solr","Riak","Yokozuna","ManifoldCF"],"title":"第12回Solr勉強会を主催しました。#SolrJP"},{"contents":"今日は、ElasticSearchのMLで見つけたelasticsearch-inquisitorプラグインの紹介です。\nElasticSearchはREST API形式で簡単にコマンドラインからいろいろな処理を実行できて便利ですが、 GUIがあったほうが楽なこともまた事実です。 今回紹介する、inquisitorプラグインもSiteプラグイン（Webブラウザでアクセスできるプラグイン）の1つです。 （ただし、ローカルにインストールしてローカルのElasticSearchにしか接続できませんが。。。）\nインストール プラグインですので、以下のコマンドでインストールが出来ます。インストール後はElasticSearchの再起動が必要です。\nbin/plugin -install polyfractal/elasticsearch-inquisitor ElasticSearch再起動後に、以下のURLにアクセスすればOKです。 ※ローカルでのみ動作可能なプラグインです。（内部で呼び出しているJSにlocalhostと記載があるため）\nhttp://localhost:9200/_plugin/inquisitor/#/ 何ができるの？ 自分の書いたQueryが正しく動作するかや、Analyzerによって文章がどのように、Term（Token）に分割されるかといった挙動をWebブラウザ上で確認することができます。用意されている画面は「Queries」「Analyzers」「Tokenizers」の3種類です。\nQueries クエリの確認、実行が可能な画面です。\n「Index」「Type」はプルダウンになっており、現在ElasticSearchに存在しているものが選択可能です。 その下のテキストエリアがクエリを入力する画面です。\nクエリを入力していると、入力しているクエリがValidかどうかをクエリのコンソール部分（右側上部）に表示してくれます。\n少し残念なことに、Tabを押すと、フォームのフォーカスが切り替わってしまうので、クエリを入力するのがちょっと面倒です。。。（私は通常の検索には、ChromeプラグインのSenseというものを利用してます。）\nクエリに問題がない場合は、「Query」ボタンを押すことで実際の検索が実行されます。 この時、画面真ん中のブルーのテーブル（内部で実行されるクエリ）の部分に、QueryがElasticSearch内部で解釈されたあとの、Luceneで実行されるレベルのクエリに変換されたクエリが表示されます。\nこれが便利です。JSONで記述したり、色々なタイプのクエリがElasticSearchでは実行できますが、望んだ形に単語が区切られているかなどを確認することができるため、非常に便利です。\nElasticSearchのQuery DSLではexplainをtrueにすることで、ヒットしたドキュメントのスコア計算に用いられた単語などがわかるのですが、そもそもヒットしないクエリの場合は、explainでは単語の区切られ方などがわかりません。\nその場合に、このプラグインで確認すると、想定と違う単語の区切られ方やクエリの造られ方がわかるかと思います。\nAnalyzers Analyzerによる文章のアナライズ結果の確認が出来る画面です。 ElasticSearchやSolrにあまり詳しくない場合、どんなAnalyzerが文章をどのように単語に区切って、転置インデックスのキーワードとして利用しているかがわからないと思います。\nこのAnalyzerが文章をどのように単語に区切っているかを確認することができるのがAnalyzers画面です。 こんなかんじの画面になります。\n一番上のテキストエリアが文章を入力する場所です。 文章を入力していくと、その下のテーブルの「Analyzed Text」の部分が変化していくのが分かります。 このグレーの単語が転置インデックスのキーワードとなります。\n予め用意されているAnalyzer以外に、用意されているTokenzier＋Filterの組み合わせも簡単ですが確認可能です。（Tokenizer、Filtersとあるテーブル） ただし、ここまでのどちらも細かな設定は画面上ではできません（Filterの細かな引数の指定など）\n一番下の部分が、ElasticSearchに存在しているインデックスごとに定義されたAnalyzerやフィールドを元にした解析結果を表示することができる領域です。\n自分でマッピングを記述してフィールド定義したものの動作確認や、インデックスを適当に作ったけど、うまくヒットしない場合など、ここで、単語の区切れ方を確認することで、検索になぜヒットしないのかといった問題のヒントを得ることができると思います。\nAnalyzerによっては、インデックス対象の文字として扱わない文字があったりしますので。 先ほどのQueries画面のLuceneに投げられる直前のクエリと、Analyzersでの単語の区切られ方を確認することで、検索がうまくヒットしていないことが判明すると思います。\nTokenizers 最後はTokenizers画面です。Analyzersとほぼ同様ですが、ちがいは、デフォルトで用意されているTokenizerの挙動の確認ができるというだけになります。\n簡単な確認ならここで可能かと。\n注意点は？ まだ開発途中のようで、つぎの部分が課題かと。\nローカルでのみ実行可能 Queries画面の結果の「Explain Result」リンクが未実装 Queries画面のクエリ入力が使いにくい（タブが打てないので） カスタム登録のAnalyzersはインデックスを用意しないと確認できない。（Kuromojiのプラグインを登録しただけでは確認できなかった） 細かな設定のフィールドも用意しないと、Analyzers画面では利用できない まとめ ということで、Inquisitor（読みがわからない）プラグインの簡単な説明でした。 検索にうまくヒットしないという理由は大体の場合、 クエリに入力した文字列が単語に区切られたものと、登録したデータが単語に区切られたものが異なるために検索にヒットしないというものです。\nそのクエリ、データの単語の区切られ方を確認するのに役に立つプラグインじゃないでしょうか。\nちなみに、このプラグイン自体はHTML＋JSで作成されており、実際にはElasticSearchが持っているREST APIをキックしているだけになります。 ですので、Web画面なんか要らないという方は、このプラグインが実際に送信しているリクエストを参考にするとcurlコマンドでどういったリクエストを投げればいいかというのがわかると思います。\n私は軟弱者なので画面があったほうがいいですが。\n","date":1379906820,"dir":"post/2013/","id":"e1870dde155be1a375f155dd1f7ead13","lang":"ja","lastmod":1379906820,"permalink":"https://blog.johtani.info/blog/2013/09/23/intro-elasticsearch-inquisitor/","publishdate":"2013-09-23T12:27:00+09:00","summary":"今日は、ElasticSearchのMLで見つけたelasticsearch-inquisitorプラグインの紹介です。 ElasticSea","tags":["elasticsearch","plugin"],"title":"elasticsearch-inquisitorプラグインの紹介"},{"contents":"river-wikipediaの前々回の記事で書きましたが、bulk_sizeに関連して登録件数がやけにきりが良いのが気になると書いていました。\nで、Riverの仕組みを勉强がてら、elasticsearch-river-wikipediaのソース（1.2.0）を読んでみました。\nRiverの作り Riverはorg.elasticsearch.river.Riverというinterfaceを実装することで作らています。 ただ、Riverがinterfaceとなっていますが、o.e.river.AbstractRiverComponentというクラスを継承して作られています。\nAbstractRiverComponentにはRiverの名前や設定などが用意されています。 ま、ここはそれほど重要じゃないので、軽く流してと。\nRiverの設定関連は実装したRiverクラス（ここでは、WikipediaRiverクラス）のコンストラクタで、設定値の読み取りなどの記述を記載します。 このコンストラクタが、_river/hogehoge/_metaをPUTした時のJSONを元にElasticSearchから呼ばれて、Riverのインスタンスが作成されます。（たぶん、このへんがその処理だと思う。。。このあたりはまた今度）\n実際のRiverの処理はWikipediaRiverクラスのstart()メソッド内部に記述されています。\n@Override public void start() { logger.info(\u0026#34;starting wikipedia stream\u0026#34;); try { ① client.admin().indices().prepareCreate(indexName).execute().actionGet(); } catch (Exception e) { if (ExceptionsHelper.unwrapCause(e) instanceof IndexAlreadyExistsException) { // that\u0026#39;s fine } else if (ExceptionsHelper.unwrapCause(e) instanceof ClusterBlockException) { // ok, not recovered yet..., lets start indexing and hope we recover by the first bulk // TODO: a smarter logic can be to register for cluster event listener here, and only start sampling when the block is removed... } else { logger.warn(\u0026#34;failed to create index [{}], disabling river...\u0026#34;, e, indexName); return; } } ② currentRequest = client.prepareBulk(); ③ WikiXMLParser parser = WikiXMLParserFactory.getSAXParser(url); try { ④ parser.setPageCallback(new PageCallback()); } catch (Exception e) { logger.error(\u0026#34;failed to create parser\u0026#34;, e); return; } ⑤ thread = EsExecutors.daemonThreadFactory(settings.globalSettings(), \u0026#34;wikipedia_slurper\u0026#34;).newThread(new Parser(parser)); thread.start(); } 内部では\nインデックスの作成 バルクアップデート用クライアントの設定 WikiXMLのパーサの初期化 ページごとにキックされるコールバック処理の登録 デーモンスレッドの起動と起動 といった処理の流れになっています。\nで、このスレッドの起動後は、4.で用意したparser.parse()処理がグルグル回ります。\n1ページがパースされるたびに、WikipediaRiver.PageCallbackクラスのproess()メソッドが呼ばれます。 このメソッドの最後で、processBulkIfNeeded()メソッドが呼ばれています。ここで、実際にパースしたページをインデックスに登録する処理が実行されます。\nこのメソッドの1行目が鍵でした。 bulkSize以上の件数がバルクのリクエストに貯まった時だけ、実際にインデックスに登録する処理が実行されます。 このため、スレッドが回っている間は、bulkSize以上のデータが貯まらないと、インデックスへの登録は行われないわけです。\n次に、このスレッドを止めるには、前々回書いたように、_riverにPUTした、Riverの設定をDELETEするしかありません。（あとは、ElasticSearchを停止するとかでしょうか。）\nで、DELETEが実行される呼ばれるのが、WikipediaRiverクラスのclose()メソッドです。\n@Override public void close() { logger.info(\u0026#34;closing wikipedia river\u0026#34;); closed = true; if (thread != null) { thread.interrupt(); } } 見ていただくと分かりますが、スレッド止めて終了です。\n問題点は？ ということで、\nWikipediaのXMLを読み込んでもRiverは停止しない Riverの停止を行ってもスレッドが止められるだけ。 bulkSize以下の件数がcurrentRequestに残っているけど、破棄される とまぁ、こんな流れになっているので、最後の端数のドキュメントがインデックスに登録されないようです。 （まだ、ちゃんと確認してないんですが、備忘録のため先に書いちゃいました。。。）\nじゃあ、全部うまく登録するにはどうしたもんかなぁと。 いまのところ思いついたのはこんな感じです。 他にいい案があったら教えて下さい。\n案１：close()処理の中で、スレッド停止後に、currentRequestに貯まっているデータをインデックスに登録しちゃう 案２：bulkSize以外に、定期的（指定された時間）で登録処理を実行してしまう。 簡単なのでとりあえず、案１を実装してみるかなぁと。 （さっさとコード書けよって話ですね。。。スミマセン） その前にMLで質問ですかねぇ、英語で。\nWikipediaのRiverをざっと眺めてみた感じですが、わかりやすい作りだなぁと。 他のRiverがどうなってるかをちゃんと見てませんが、他にもbulkSize指定をするRiverの場合は、このように件数がbulkSizeに満たない状態ではデータが登録されないといったことがあるかもしれません。\nElasticSearchのソースを読み始める取っ掛かりとしては面白いかと思いますので、興味ある方は読んで作ってみるといいかもしれません。（私は読んだだけですがｗ）\n追記（2013/09/13 21:00） MLで質問してみました。とりあえず、案1を。\nriver-wikipedia does not index all pages\n他のRiverでは対応してるしバグだね、Issue上げてとのことで、あげときました。 ついでにプルリクも出せばいいんでしょうが、プルリクまだやったことないヘタレです。。。\nあと、案2についても同じトピックで質問してます。 どうやら、BulkProcessorにその機能があるよと。 flushintervalというプロパティがありそうです。どうやって設定して、どうやって動くのかとか見てないので、 調査してブログorLTかな。\nbulk udpにはその値を設定できそうなのがあるんだよなぁ。\n追記その２（2013/09/16 23:50） さっそく修正版がコミット(コミットログ)されてました。 結構変わってます。BulkProcessorにflush_intervalの設定をすれば、よしなにやってくれる仕組みがすでに実装されているようです。 bulkSizeについても同様に、BulkProcessorに設定すれば良いようです。 Riverの仕組みが結構スッキリしています。 もともと実装されていた、bulkSizeごとの処理も消されています。 確かに、BulkProcessorの仕組みとして実装されている方がしっくりきますね。\nということで、考える暇もなくコミットされてしまいました。 こうやって質問しつつ、少しずつソースを読んでいこうかなと思ってるとこです。\n","date":1378921080,"dir":"post/2013/","id":"d2e805472f79f0b558f75b90b5e7b4ee","lang":"ja","lastmod":1378921080,"permalink":"https://blog.johtani.info/blog/2013/09/12/question-river-wikipedia/","publishdate":"2013-09-12T02:38:00+09:00","summary":"river-wikipediaの前々回の記事で書きましたが、bulk_sizeに関連して登録件数がやけにきりが良いのが気になると書いていまし","tags":["elasticsearch","wikipedia"],"title":"elasticsearch-river-wikipediaの疑問点"},{"contents":"前々回紹介した、日本語Wikipediaのデータをインデックス登録する記事の続きです。\n今回は、Kuromojiのアナライザを利用してインデックス登録してみます。\n余談（Proxy環境でのプラグインインストール） ElasticSearchのpluginコマンドはJavaで実装されています。（org.elasticsearch.plugins.PluginManager） プラグインのダウンロードには、java.net.URL.openConnection()から取得URLConnectionを使用しています。\nですので、pluginのインストールを行う際に、Proxy環境にある場合は以下のようにコマンドを実行します。\n./bin/plugin -DproxyPort=ポート番号 -DproxyHost=ホスト名 -i elasticsearch/elasticsearch-analysis-kuromoji/1.5.0 elasticsearch-analysis-kuromojiのインストール WikipediaのデータをKuromojiを使って、形態素解析ベースの転置インデックスを作成していきます。 まずは、Kuromojiを利用するために、Analysisプラグインのインストールです。 ElasticSearchのバージョンに対応したプラグインのバージョンがあります。（プラグインのページに対応したバージョンの記載あり） 今回はElasticSearchの0.90.3を利用しているため、1.5.0をインストールします。\n./bin/plugin -i elasticsearch/elasticsearch-analysis-kuromoji/1.5.0 インストール後は再起動しておきます。 なお、Kuromojiを利用して、Wikipediaのデータを登録するばあい、デフォルトの設定では、ヒープが足りなくなるおそれがあります。 ElasticSearchの起動時に以下のオプションを指定して、最大ヒープサイズを2Gとしておきます。\nexport ES_HEAP_SIZE=2g;./bin/elasticsearch Indexの作成（デフォルトでKuromojiのAnalyzerを利用する） Wikipediaのデータを登録する際に、Kuromojiのアナライザを利用したいのが今回の趣旨でした。 一番ラクな方法として、Wikipediaデータのインデックスの設定として、デフォルトのアナライザをKuromojiにしてしまいます。 （きちんと設計する場合は、必要に応じてフィールドごとに指定しましょう）\ncurl -XPUT \u0026#39;localhost:9200/ja-wikipedia-kuromoji\u0026#39; -d \u0026#39;{ \u0026#34;settings\u0026#34;: { \u0026#34;analysis\u0026#34;: { \u0026#34;analyzer\u0026#34;: { \u0026#34;default\u0026#34; : { \u0026#34;type\u0026#34; : \u0026#34;kuromoji\u0026#34; } } } } }\u0026#39; これでkuromojiのアナライザがデフォルトで利用される形となります。 あとは、Riverを起動して登録するだけです。\nRiverの実行 前回と一緒です。 インデックス名（_river/\u0026lt;インデックス名\u0026gt;/_meta）だけは、先ほど作成した「ja-wikipedia-kuromoji」に変更してください。\ncurl -XPUT localhost:9200/_river/ja-wikipedia-kuromoji/_meta -d \u0026#39; { \u0026#34;type\u0026#34; : \u0026#34;wikipedia\u0026#34;, \u0026#34;wikipedia\u0026#34; : { \u0026#34;url\u0026#34; : \u0026#34;file:/home/johtani/src/jawiki-latest-pages-articles.xml\u0026#34; }, \u0026#34;index\u0026#34; : { \u0026#34;bulk_size\u0026#34; : 10000 } }\u0026#39; あとは、インデックスされるのを待つだけです。\nデータ量とか 5.8gbになりました。Kuromojiを利用したため、形態素解析により単語にきちんとトークないずされた結果でしょう。 Uni-gramだと、転置インデックスのボキャブラリも単語に対してヒットするドキュメント数も大きくなるため、 インデックスサイズも大きくなっているのかと。\n検索クエリのサンプルなどはまた後日。（夜遅いので。。。）\n","date":1378138500,"dir":"post/2013/","id":"79e647a3f8b36a1221897f5837c84aff","lang":"ja","lastmod":1378138500,"permalink":"https://blog.johtani.info/blog/2013/09/03/ja-wikipedia-with-kuromoji/","publishdate":"2013-09-03T01:15:00+09:00","summary":"前々回紹介した、日本語Wikipediaのデータをインデックス登録する記事の続きです。 今回は、Kuromojiのアナライザを利用してインデッ","tags":["elasticsearch","kuromoji","wikipedia"],"title":"日本語Wikipediaをインデクシング（Kuromojiバージョン）"},{"contents":"ElasticSearch勉強会 第1回を主催しました。 昨年のpyfesでなんちゃって資料で喋って、1年たちました。\nElasticSearchの書籍（英語）も出てきて、今年はElasticSearchが面白くなりそうだし、使ってる人たちから話も聞きたいなぁということで、主催しました。\n思った以上に興味のある方がいらっしゃったようで、100人応募のところ、チケットがすぐ完売してしまうほど。。。 しかも、当日もほぼ満員ということで、大変な盛況ぶりでした。\nスピーカーの皆様、参加された皆様、会場を提供していただいたリクルートテクノロジーズさん、ありがとうございました！（たぶん、90人くらいいらっしゃってたかと。）\nこんなステキな案内板も用意してもらいました。スタッフのみなさんありがとうございます！ トゥギャっても頂きました。まとめていただいてありがとうございます！\n自分の発表や個々の発表に関する感想は以下のメモに。\nElasticSearch入門 @johtani スライド：ElasticSearch入門※スライドはPDFです。\n緊張しまくりでわかりにくかったですかね。。。 とりあえず、AWSのサービスじゃないってのだけでも覚えて帰っていただければ満足です。 途中で見せたChromeプラグインのSense わからなかった点や質問、ご意見などは、当ブログのコメント、私宛の＠ツイート、なんでもいいので、反応ください。なんでもいいので反応があると、今後の励みになりますので！ ということで、発表でも言いましたが、わからないことがアレば、@johtaniまで投げてもらえれば、「知らない」「ブログのネタにします」「ソレはこんなかんじですかねぇ？（テキトー）」みたいに答えると思います。 Elasticsearch in Actionは帰宅中に、4章追加されたよというメールが届きました。 宿題 クラスタへのノードの追加の処理方法とか、シャーディングの実装とか。 elasticsearchプラグイン入門 ～ mocksolrpluginでSolrと入れ替えてみよう 菅谷さん スライド：elasticsearchプラグイン入門　slideshare\nプラグイン構成とか（公式でまとまってるの見つけられないので助かります。） 作る上でのポイントうれしいです。 パッケージ名変えられるとか、つらい。。。 Solr APIプラグインについて（Solrの振りしてくれる便利なヤツ） 感想 まだ、プラグインを書いたことがないのですが、ちゃんとプラグインはどういう構成で書くんですよというまとまった資料って本家のサイトにもない気がしています。 なので、スライドが公開されたらすごく役に立つかと。 そのまえに、何かプラグイン書いてみます。。。\nDebugging and testing ES systems Chris Birchallさん スライド：Debugging and testing ES systems　slideshare\nテストの方法とか便利なお話（最後のほうしか聞いてなかったですが。。。。） クエリのデバッグは色々とやらないと、なんでヒットしないのってよくあるので。とくに形態素解析を利用した検索の場合、短い文章（クエリ）と長い文章（ドキュメント）で切れ目が変わってうまくヒットしないとかありますよね。 最後に少しだけ話しましたが、n-gramとKuromojiを組み合わせてOR検索とかすると良い場合があります。 インデックスが大きくなったり、OR検索なので遅くなったりというデメリットもありますが。 感想 実際に使われているノウハウを元に話をしていただいたので助かりました。 最初に席を外してたのですが、戻ってきて日本語で普通に発表されててほんとにびっくりしましたｗ テスト用プラグインがあるのとかは知らなかったです。 あと、使われてたIDEがIntelliJ IDEAでしたね！私も使ってます！\nニコニコ動画データセット 25億件を検索可能にしてみよう @PENGUINANA_ スライド：ニコニコ動画を検索可能にしてみよう　slideshare\nkibana@cookpadのお話 どういう挙動するかをやってみればいいじゃんってことで、やってみるのカッコイイ！ http://goo.gl/FYtO5T bigdeskとか。プラグインいろいろ。 感想 さすがです、ペンギン先生。大きなデータセットつかって、構築した環境に関する数値も書かれてる資料ができて素晴らしすぎです。 思った以上にサクサク動いてて、4hでインデクシングできるのもすごいなぁと。 私も見習ってこのくらいがサクッとできるようになりたい。。。 あと、発表後にムチャぶりしましたが、次回はぜひ検索側の性能とかも話してもらえたらと。\n反省点 イベントアテンドだと、キャンセル待ちができない＋どのくらいの方が興味をもっているのかわからない。 イベントページの主催者は複数指定できる方がいい。（土壇場の登録の人が管理できない。私が司会やってたから） マイクが聞こえにくかった（音量調節とかちゃんと調べないと） 懇親会は立食のほうがやはり動きやすい。 懇親会が1時間ちょっとしかできなかった 雑感 ということで、ES勉強会、主催の私が一番楽しめました。ありがとうございます。 （あと、気前よく調べて答えますと言ってしまいました。。。まぁ、いいトリガーになるので、ウェルカムですが）\nやっぱりKibanaについて興味を持ってる人も多いのかなぁという感触がしたので、次回はぜひKibana3の話をしてもらえるように頑張ります。 あと、elasticsearch-headを使われてるんだなぁと。私はelasticsearch-HQを入れて使ってみてます。大きなクラスタ管理まではまだやってないので。\nあとは、やはりいろんな人に助けられてるなぁと実感しつつ、今後も開催するので助けてください！ということで。 （もちろん、Solr勉強会もがんばりますよー）\n関連ブログ ElasticSearch勉強会 第1回 - Go ahead! タムタムの日記 - ElasticSearch勉強会 の参加メモ #elasticsearchjp 第1回ElasticSearch勉強会に行ってきた！ #elasticsearchjp - #侍ズム 第1回 ElasticSearch 勉強会に参加 #elasticsearchjp - seratch 他にもブログを書かれた方がいらっしゃいましたたら、リンクしたいので連絡いただければ。\n","date":1377798120,"dir":"post/2013/","id":"5931f8e3acdac724742c4ee0960d8d40","lang":"ja","lastmod":1377798120,"permalink":"https://blog.johtani.info/blog/2013/08/30/hold-first-elasticsearch-meetup-in-japan/","publishdate":"2013-08-30T02:42:00+09:00","summary":"ElasticSearch勉強会 第1回を主催しました。 昨年のpyfesでなんちゃって資料で喋って、1年たちました。 ElasticSearch","tags":["elasticsearch","勉強会"],"title":"第1回ElasticSearch勉強会を開催しました！ #elasticsearchjp"},{"contents":"久々のブログはElasticSearchネタです。勉強会開催する予定だったりすので、もう少し触っておきたいなと。 お手軽に検索するデータとして、よくWikipediaのデータを使っています。 ElasticSearchにはelasticsearch-river-wikipediaという便利なプラグインがあり、Wikipediaのデータを簡単に検索可能な状態にできます。このRiverを利用して日本語のWikipediaのデータを入れたので、メモを取っておきます。 まずは、river-wikipediaで日本語のデータをインデクシングしてみるまでの説明です。 日本語特有の設定（Kuromojiを利用したインデクシング）などはまた後日。\nプラグインのインストール 対象とするElasticSearchは現時点で最新版の0.90.3とします。 最新版でRiver動かないなぁとつぶやいた影響かどうかはわかりませんが、2013/08/19に最新版のElasticSearchで動作するプラグインが公開されました。\nまずはインストールです。 HPにも書いてありますが、以下のコマンドを実行すればインストールされます。\n$ ./bin/plugin -install elasticsearch/elasticsearch-river-wikipedia/1.2.0 -\u0026gt; Installing elasticsearch/elasticsearch-river-wikipedia/1.2.0... Trying http://download.elasticsearch.org/elasticsearch/elasticsearch-river-wikipedia/elasticsearch-river-wikipedia-1.2.0.zip... Downloading ..........DONE Installed river-wikipedia into /opt/elasticsearch/plugins/river-wikipedia ElasticSearchが起動している場合はプラグインをインストール後、認識させるためにElasticSearchを再起動します。\n日本語Wikipediaのインデクシング 通常は英語のWikipediaがインデクシングされますが、対象となるファイルを変更することで日本語のWikipediaもインデクシング可能です。 手元に日本語Wikipediaのダンプファイルがあるものとします。（ダウンロードはWikipediaデータベースダウンロードのページにあるpages-articles.xml.bz2のファイルです）\nファイルを指定してインデクシングするには、つぎのcurlコマンドを実行します。 コマンドを実行するとすぐにインデクシングが始まりますので注意が必要です。\ncurl -XPUT localhost:9200/_river/ja-wikipedia/_meta -d \u0026#39; { \u0026#34;type\u0026#34; : \u0026#34;wikipedia\u0026#34;, \u0026#34;wikipedia\u0026#34; : { \u0026#34;url\u0026#34; : \u0026#34;file:/home/johtani/src/jawiki-latest-pages-articles.xml\u0026#34; }, \u0026#34;index\u0026#34; : { \u0026#34;bulk_size\u0026#34; : 1000 } }\u0026#39; ここでURLに含まれる「ja-wikipedia」がインデックス名になります。 また、JSONの\u0026quot;url\u0026quot;にはファイルの場所を指定するため、file:で開始するパスを指定します。 例では、bz2を解凍したファイルを指定していますが、bz2のままのファイルでもOKです。\n上記コマンドを実行すると、_riverというインデックスにつぎのようなエントリが増えています。 (curl -XGET 'localhost:9200/_river/ja-wikipedia/_search?pretty)\n{ \u0026#34;took\u0026#34;: 5, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 2, \u0026#34;max_score\u0026#34;: 1, \u0026#34;hits\u0026#34;: [ { \u0026#34;_index\u0026#34;: \u0026#34;_river\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;ja-wikipedia\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;_status\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;ok\u0026#34;: true, \u0026#34;node\u0026#34;: { \u0026#34;id\u0026#34;: \u0026#34;gdyvwpiAR52lqUCcRhVwsg\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Blitzschlag, Baron Von\u0026#34;, \u0026#34;transport_address\u0026#34;: \u0026#34;inet[/192.168.100.7:9300]\u0026#34; } } }, { \u0026#34;_index\u0026#34;: \u0026#34;_river\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;ja-wikipedia\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;_meta\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;wikipedia\u0026#34;, \u0026#34;wikipedia\u0026#34;: { \u0026#34;url\u0026#34;: \u0026#34;file:/home/johtani/src/jawiki-latest-pages-articles.xml\u0026#34; }, \u0026#34;index\u0026#34;: { \u0026#34;bulk_size\u0026#34;: 100 } } } ] } } \u0026quot;_id\u0026quot;: \u0026quot;_meta\u0026quot;というエントリがさきほど登録したWikipediaのRiverに関する設定です。 \u0026quot;_id\u0026quot;: \u0026quot;_status\u0026quot;というエントリが起動したRiverの状態になります。\nRiverの停止 日本語Wikipediaは結構サイズが大きく、手元のAirでインデクシングするのに30分程度かかりました。（bz2圧縮されていないファイルで、何もしていない状態）\n途中でRiverを停止したくなった場合は、以下のcurlコマンドを実行します。\n$ curl -XDELETE \u0026#39;localhost:9200/_river/ja-wikipedia\u0026#39; 先ほど設定した_river/ja-wikipediaの情報を削除すると、エントリが削除されたのを検知してRiverが停止します。ログにはつぎのようなメッセージが表示されます。\n[2013-08-26 18:26:50,130][INFO ][cluster.metadata ] [Blitzschlag, Baron Von] [[_river]] remove_mapping [ja-wikipedia] [2013-08-26 18:26:50,130][INFO ][river.wikipedia ] [Blitzschlag, Baron Von] [wikipedia][ja-wikipedia] closing wikipedia river Riverを停止してもそれまでインデクシングされたデータは検索できます。 データはちょっとだけで良いという場合は、先ほどの_riverのデータを削除してください。 （◯件だけ登録したいとかできるかは調べてないです。）\nサイズとかマッピングとか サイズ インデックス前のXMLのサイズが5.7Gのとき、ElasticSearchのインデックスサイズ（Optimize後）は7.2Gとなりました。すこし古いファイルを利用しているため、最新版とはサイズが異なるかもしれません。\nあと、データ数が、1540000件とやけにきりがいいのがちょっと気になっています。。。 bulkのサイズを10000で指定してインデックスしたので、切れてるのかなぁと。\nということは、データが欠落しているような気がするのでRiverの作りの問題なのか、ElasticSearchの問題なのかはちょっと調べてみないとわからないなと。\nマッピング 出来上がったインデックスのマッピング（Solrでいうスキーマみたいなもの）は次のようになっています。\n{ \u0026#34;ja-wikipedia\u0026#34;: { \u0026#34;page\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;category\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;disambiguation\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;boolean\u0026#34; }, \u0026#34;link\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;redirect\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;boolean\u0026#34; }, \u0026#34;special\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;boolean\u0026#34; }, \u0026#34;stub\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;boolean\u0026#34; }, \u0026#34;text\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;title\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } } } Wikipediaの各種データが上記のフィールドに入っています。 また、マッピングタイプはデフォルトで「page」というタイプになっています。\n検索 先ほどのマッピングを元に検索すればOKです。例えばつぎのような感じです。\ncurl -XPOST \u0026#39;localhost:9200/ja-wikipedia/_search?pretty\u0026#39; -d \u0026#39; { \u0026#34;size\u0026#34; : 3, \u0026#34;script_fields\u0026#34;: { \u0026#34;title_only\u0026#34;: { \u0026#34;script\u0026#34;: \u0026#34;_source.title\u0026#34; } }, \u0026#34;query\u0026#34; : { \u0026#34;query_string\u0026#34;: { \u0026#34;default_field\u0026#34;: \u0026#34;title\u0026#34;, \u0026#34;query\u0026#34; : \u0026#34;千葉\u0026#34; } } }\u0026#39; 結果はこんな感じ。\n{ \u0026#34;took\u0026#34;: 51, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 5, \u0026#34;successful\u0026#34;: 5, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 8616, \u0026#34;max_score\u0026#34;: 5.8075247, \u0026#34;hits\u0026#34;: [ { \u0026#34;_index\u0026#34;: \u0026#34;ja-wikipedia\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;page\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;3582\u0026#34;, \u0026#34;_score\u0026#34;: 5.8075247, \u0026#34;fields\u0026#34;: { \u0026#34;title_only\u0026#34;: \u0026#34;千葉\u0026#34; } }, { \u0026#34;_index\u0026#34;: \u0026#34;ja-wikipedia\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;page\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;2352241\u0026#34;, \u0026#34;_score\u0026#34;: 4.94406, \u0026#34;fields\u0026#34;: { \u0026#34;title_only\u0026#34;: \u0026#34;千葉千枝子\u0026#34; } }, { \u0026#34;_index\u0026#34;: \u0026#34;ja-wikipedia\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;page\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;14020\u0026#34;, \u0026#34;_score\u0026#34;: 4.8754807, \u0026#34;fields\u0026#34;: { \u0026#34;title_only\u0026#34;: \u0026#34;千葉千恵巳\u0026#34; } } ] } } 結果を見やすくするため、タイトルだけを「title_only」という表示にしています。 ただ、この検索だと、一見「千葉」できちんとヒットしているように見えますが、ElasticSearchのフィールドの定義はstring型になっています。なので、実は「千」や「葉」だけのデータもヒットしています。 マルチバイト文字は1文字ずつインデックスされてしまい、query_stringというクエリでは、フレーズ検索などができていないためです。\nまとめ プラグインいれて、XMLファイルがあれば、検索できるデータが出来上がるので、 暇があったら、お試しで触ってみるデータを簡単に入れてみてはどうでしょうか。\nただ、いくつか気になる点も。\n日本語が検索しにくい（string型のフィールドなのでuni-gramっぽくなっている） bulk_sizeの影響で端数が登録できてない（バグ？どうなの？） ということで、ちょっと使いにくいかもなぁということで、つぎはKuromojiを利用してインデックスしてみてみようかなと。次回のエントリで書く予定です。\n","date":1377226920,"dir":"post/2013/","id":"3931327ed463d1568868c5ab8e839148","lang":"ja","lastmod":1377226920,"permalink":"https://blog.johtani.info/blog/2013/08/23/index-wikipedia-ja-to-elasticsearch/","publishdate":"2013-08-23T12:02:00+09:00","summary":"久々のブログはElasticSearchネタです。勉強会開催する予定だったりすので、もう少し触っておきたいなと。 お手軽に検索するデータとして","tags":["elasticsearch","wikipedia"],"title":"ElasticSearchにプラグインで日本語Wikipediaデータを入れてみました"},{"contents":"宿題その2？かな。Solr勉強会でCloudera Searchのスキーマ周りってどうなってるの？という質問が出てて、 なんか調べることになってたので、関係しそうなMorphlinesのLoadSolrコマンドを調べてみました。 こいつが、Solrへの書き込みを実行するコマンドみたいだったので。\n（※Cloudera Searchのスキーマの設定方法とかは調べてないです。）\n（※めんどくさかったので、パッケージ名すっ飛ばしてクラス名書いてます。githubへのリンクを代わりに貼ってます。）\nRecord＝Solrのドキュメント convert()メソッドにて、MorphlinesのRecord（コマンドの処理するデータの１単位）に格納されているKey-ValueデータをSolrInputDocumentクラスのフィールドとして格納しています。 Recordにもフィールドという概念があり、Recordのフィールド＝Solrのフィールドという事みたいです。\nということで、Solrのフィールドは事前に定義しておき、Morphlinesの処理内部でSolrのフィールド名に値を詰めていく感じでしょうか。 別途、sanitizeUnknownSolrFildsというコマンドが用意されていて、Solrのスキーマにないものはこのコマンドを使って、無視するフィールド名に変えたり、雑多なデータを入れるためのフィールド名にするといった処理ができるようです。このコマンド内部で、Solrのスキーマ設定を元に、Solrのフィールドに合致する物があるかをチェックして処理しています。\nSolrへの登録処理は？ Solrへの登録処理自体はLoadSolrクラス内部でDocumentLoaderというクラスのload()メソッドを呼び出しているだけでした。ということで、DocumentBuilderクラスを少し調査。\nDocumentLoader IFでした。。。実クラスは次の条件\nSolrMorphlineContextにDocumentLoaderがあればそちらを採用（他の種類はなにがあるんだろ？） なければ、SolrServerDocumentLoaderをnewしたものを利用 2.の場合がおそらくMapReduceではないパターンのloadSolrだと思われます。SolrServerDocumentBuilderはSolrJのAPIを利用して、Solrへデータ登録していく普通のアプリです。（対象とするSolrは外部に起動しているもののはず＝FlumeのSolrSinkではこちらを採用かな？）\nSolrへの接続情報とか設定ファイルとかSolrCloud用のZooKeeperとかはSolrLocatorクラスに設定される内容が利用されます。\n1.のパターンは、どうやら、Cloudera SearchのMapReduceIndexerToolのクラスにあるMyDocumentLoaderかなぁと。 こちらは、MapReduceを利用する場合に、利用されてるっぽいです（ちゃんと見てないけど） 内部処理は、HadoopのContext.writeメソッドにでSolrInputDocument（＝MorphlinesのRecord）を書きだして、ReducerでSolrOutputFormatでインデックス作成の流れかなと。たぶん、MorphlineMapRunnerあたりを読みこめば解読できるかと。 ちなみに、こちらは、2.とは異なり、SolrLocatorの設定は無視されそう。\n感想＋妄想？ ということで、Morphlinesのデータ流れを考える上で、現時点ではSolrのスキーマを頭の片隅に置きつつ、 Recordの中にあるデータをゴニョゴニョしてデータを形成していくって感じになりそうです。 うまく処理できなかったものとかのカウントとかもとれたりするのかなぁ？とか、また色々と気になるところが出てきますが、一旦ここまでで。。。（だれか、続きを調べて書いてみてくれてもいいんですよ！コマンドもいっぱいあるし！）\nとまぁ、こんなかんじでMorphlinesをちょっとだけ読みました。 よくよく考えたら、こんなの作ったことあるなぁと（こんなに汎用的じゃないけど）。 みんな同じ事考えるんですねぇ。 コマンドパターン？みたいな感じで、I/F決めてSolrとか別のシステムとかにデータ入れる処理を順番に記述できる的なバッチ処理良くかいてます（書いてましたのほうが正解かなぁ）。\n","date":1375434120,"dir":"post/2013/","id":"33e01e2271be22b5ed330045fe6aff50","lang":"ja","lastmod":1375434120,"permalink":"https://blog.johtani.info/blog/2013/08/02/morphlines-loadsolr/","publishdate":"2013-08-02T18:02:00+09:00","summary":"宿題その2？かな。Solr勉強会でCloudera Searchのスキーマ周りってどうなってるの？という質問が出てて、 なんか調べることになって","tags":["Cloudera Search","Morphlines","Solr"],"title":"MorphlinesのloadSolrをちょっとだけ調べてみた"},{"contents":"今朝起きたら、Xperia Zが故障してしまいました。 電源ボタンを押してもスリープにならないんです。しかも、スリープからの復帰もできない。。。\nということで、ドコモショップに行って来ました。対応も良かったです。 やっぱり、ボタンがおかしく再起動してもNGでした。 ということで、トントン拍子で交換品に変更してもらえました。\n2、3回繰り返し言われましたが、データなくなりますよ＆交換品なので、復旧はご自分でとのこと。 ドコモショップ行く前に「Sony Bridge for Mac」というSony製のアプリでバックアップ取ってたし問題ないですと回答して、交換してもらいました。 最後に使ってないオプションとか要らないのでやめたほうが安くなりますよなどの提案もいただき満足でした。 さらに、前の機種に貼ってたフィルムもきちんと張り替えてもらえたし。時間はちょっとかかったけど。\nで、先ほど帰宅して、朝とっておいたバックアップから復旧しようとしたら。\n**「そんなバックアップありません」**みたいなメッセージが表示されて復旧出来ません。。。\nえ？なにそれ？と思い、とりあえず現時点のデータをバックアップ取ってみるかと。 バックアップ取ったあとに、再度復旧しようとしたらちゃんとリストがでてくるじゃないですか。\nなんだこれ？ということで、ファイル探しです。。。\n「Sony Bridge for Mac」バックアップファイルは次の場所に保存されるみたいです。\n/Users/ユーザ名/Library/Application Support/Sony Ericsson Bridge for Mac/Backups/製品番号みたいな文字列/日付 この最後のディレクトリが製品番号？ごとのディレクトリっぽく、２つありました。 どうせ初期化された状態だしということで、古い日付フォルダを新しい製品番号のフォルダにコピーしたら復元は可能でした。 壁紙の設定は再起動したら復活しましたが、復活してないものも。。。 復活してないのは以下のものです。\nインストールしてたアプリ ホーム画面の配置 アカウント色々（Google Playとか） ということで、スマホでインストールするのもだるくなってきたので、PCで黙々とGoogle Playのサイトからインストールしてますが、これもだるいですね。。。\n必要なアプリインストールし直したら、またSonyのアプリで復旧してみて、設定が復活するのを祈って。。。\n続き インストールしなおして、ホーム画面での配置をがんばりました。 Google Playのサイトから既存アプリをインストールするときに、ブラウザバックで戻ってたのですが、 一覧から別タブにインストールしたいアプリのページを開きまくってから、インストールボタン押すのが楽でした（半分くらい終わった所で気づいた。。。）\n一通りインストールしたあとに、ホーム画面の配置をやり直して、「Sony Bridge for Mac」もう一回復元。 twiccaやブクログなど、個別にアカウントとか設定を管理しているアプリについては復活しました。\nけど、Androidがアカウントを管理するもの（例：Facebookなど）については、残念ながら、一部のものはアカウントを再登録しないといけませんでした。\n写真や音楽についてはもともとSDカードに入れていたのもあったので、まぁ、被害は少なかったかなぁと。\nただ、iPadやiPhoneの用に簡単にバックアップ（アプリの情報、配置まで）ができて復元できると助かるなぁと思いました。（今度はホーム画面のキャプチャ撮ってから修理に出すかなぁ。。。）\n","date":1375364280,"dir":"post/2013/","id":"cd9ba1f582642d9cbe500f018afab341","lang":"ja","lastmod":1375364280,"permalink":"https://blog.johtani.info/blog/2013/08/01/replace-xperia-z/","publishdate":"2013-08-01T22:38:00+09:00","summary":"今朝起きたら、Xperia Zが故障してしまいました。 電源ボタンを押してもスリープにならないんです。しかも、スリープからの復帰もできない。。。","tags":["Xperia Z"],"title":"Xperia Zが故障したので交換したのでメモ"},{"contents":"Morphlinesについてちょっとだけ、さらに調べました。\n誤解 Solr勉強会でなんとなく私の認識を話しましたが、ちょっと誤解してたみたいです。スミマセン。\n誤解：Morphlineというプラットフォーム/ミドルウェアがありそうなイメージ まぁ、書いてあるのでちゃんと読めって話ですが、Morphlineはあくまでライブラリだということでした。 私はなんとなくManifoldCFのようなミドルウェアorプラットフォームが存在して、 そこにFlumeのSinkとかMapReduceによるIndexerが動作するのかと思ってました。\nまぁ、これが間違いでした。正解のイメージはこっちですね。\n各プラットフォーム（FlumeとかHadoopとか）に組み込んむライブラリで、 それぞれ組み込んだ先でMorphlineの設定を記述することで、パイプライン処理ができるっぽいです。\nFlumeについては、MorphlineSolrSinkというクラスでMorphlineの設定ファイルを読み込み、いろいろ処理出来ます。\nMap/ReduceだとCloudera Searchに含まれてるMapReduceIndexerToolがMorphlineの設定を読み込んでコマンド実行してくれるみたいです。 MapReduceIndexerToolはまだちゃんと読んでないのですが、MapperとしてMorphlineのコマンドが実行されるのかなぁ？という感じです。 （結構入り組んでるので、ちゃんと読まないとわからない。。。）\nということで、Morphlineというプラットフォームがあって、一元的にFlumeやMap/Reduceに対するコマンドをパイプライン化するという話でありませんでした。\n※ちなみに、上の画像ですが、愛用しているNUBoardを使って書いてます。 考えをまとめるのにすごく役立つ一品です。持ち運び可能なノート型ホワイトボードです。\n疑問点 ただ、読んでてまだ不明な点があります。まぁ、ぼちぼち調べるかなぁと。。。\nSolrのschemaはどーなってんの？ MorphlineにSolrへロードするコマンド（loadSolr）があるけど、FlumeのMorphlineSolrSinkってのもSolrに書き込みそうだけど？ Map/ReduceでSolrに書き込むもMorphlineのコマンドとの違いは？（前にソースを見たときはSOLR-1301がベースになっていて、SolrOutputFormatってクラスがEmbeddedSolrServer起動してインデクシングしてた） GoLiveってなんだろ？（MapReduceIndexerToolに入ってて、M/Rでインデックス作ったあとにSolrのクラスタに配布＋マージするやつっぽい） どんなコマンドがあるの？（Cloudera Morphlines Ref Guide） 以下は、参考資料と参考資料にあるSlideshareの資料を一部訳したものになります。\n参考資料 Using Morphlines for On-the-Fly ETL(slideshare) cloudera/cdk/cdk-morphlines(github) メモ 現在のコマンドライブラリ（スライド 18-19ページ） Solrへのインテグレートとロード フレキシブルなログファイル解析 1行、複数行、CSVファイル 正規表現ベースのパターンマッチと展開 Avro、JSON、XML、HTMLのインテグレーション Hadoop シーケンスファイルのインテグレーション SolrCellとApache Tikaパーサすべてのインテグレーション Tikaを利用したバイナリデータからMIMEタイプの自動判別 動的Javaコードのスクリプティングサポート フィールドの割り当て処理、比較処理 リストやセット書式のフィールド処理 if-then-else条件分岐 簡易ルールエンジン（tryRules） 文字列とタイムスタンプの変換 slf4jロギング Yammerメトリックとカウンター ネストされたファイルフォーマットコンテナの解凍 などなど プラグインコマンド（スライド　20ページ） 簡単に新しいI/Oや変換コマンドが追加可能 サードパーティや既存機能のインテグレード CommandインタフェースかAbstractCommandのサブクラスを実装 Javaクラスパスに新規作成したものを追加 登録処理などは必要ない 新しいプラグインコマンドとして考えられるもの（22ページ） RDBやKVSやローカルファイルなどの外部データソースをレコードにjoin DNS名前解決とか短縮URLの展開とか ソーシャル・ネットワークからリンクされたメタデータのフェッチ（？？） レコードの感情分析とアノテーション？ 31ページの図がわかりやすいかも\n以上。\n","date":1375265520,"dir":"post/2013/","id":"b875f24d3d444fdda82b6bbfb75a4c92","lang":"ja","lastmod":1375265520,"permalink":"https://blog.johtani.info/blog/2013/07/31/introduction-morphlines/","publishdate":"2013-07-31T19:12:00+09:00","summary":"Morphlinesについてちょっとだけ、さらに調べました。 誤解 Solr勉強会でなんとなく私の認識を話しましたが、ちょっと誤解してたみたいで","tags":["Cloudera Search","Morphlines","Solr"],"title":"Morphlines入門？"},{"contents":"不定期開催ですが第11回Solr勉強会を主催しました。\n今回も大入り90人くらい？の参加者の皆さんがいらっしゃいました。ありがたいことです！（20時時点で最終的に補欠17人でした。）\nとりあえず、第一報です。このあと懇親会なので。\nということで、帰りの電車でいくつか感想を（忘れちゃうから）。\n小林さんの苦労話は細かいですが、結構はまりがちな点を共有していただいたので良かったかなぁと。 Solrのexampleの設定とか、ManifoldCFとかちょっとずつ罠があったりするので、あるあるネタはありがたいと思いますｗ\nCloudera Searchについては、安定の嶋内さんの喋りに圧巻でした。検索だけの視点とは異なる観点についての 話は私には足りないしてんだったりするので参考になります。 なんか、気づいたらMorphlineやスキーマ周りを調べてブログ書くことになっちゃったけど。。。 一つ質問しそこねたのがあって、Cloudera社は基本的に公開したOSSについてのトレーニングも立ち上げているイメージです。Cloudera Searchについてもトレーニングが立ち上がるのかなぁと密かに期待をしてみたり（予算の関係上参加できるかは不明ですが。。。）\n牧野さんの話は画像系について、私は詳しくないので、また関口さんのalikeと比較とかしてもらえると面白いかなぁと。とりあえず、青いロボットがちゃんと検索できるようになるといいですねｗｗ\n秀野さんの空間検索は緯度経度以外のPOLYGONなどを利用した検索で、実は私も知らない機能でしたｗ\nなとなくは知ってたんですが、そこまでちゃんと検索できるとは！地図以外にも活用できるような気がします（想像つかないんだけど。。。）\n最後は私の発表で、簡単な資料ですみませんでした。しかも発表よりも宣伝が。。。（ブログの宣伝だったりとか。。。） 最後に宣伝した「「ビッグデータ活用を支えるOSS」特集への論文投稿のご案内」もご検討ください！\n懇親会も楽しかったです。また思いついたら開催しますー\n最後に、今回の発表者の皆様、会場提供していただいたVOYAGE GROUPの皆様ありがとうございました！\n以下はいつものメモです。\nManifoldCFのとSolrの組み合わせ（仮）株式会社 ロンウイット　大須賀さん 残念ながら、発熱のため発表は次回に持ち越しに。\n##社内ファイル及びWEBコンテンツの検索システム構築時に苦労したこと ソフトバンクBB㈱　小林さん\nManifoldCF＋Solrを使って社内ファイルの検索システム構築 約1000万ドキュメント さまざまなDCにドキュメントがある クロールジョブのハング。。。 ログをDEBUGにしたら。。。ログファイル150GB。。。 一定時間ごとにAgentをリスタートするバッチを。。。（力技） MCFエラーによるジョブの停止 CONNECTORS-590 エラーが発生して止まったジョブを起動するバッチをcronで。。。 自作リアルタイムインデクシングの問題 MCF使わないでSlaveにインデックス openSearcher=falseだとautoCommitが実行されてもSearcherを再起動しないので検索にでてこない リプリケーションのNW負荷 別DCからのレプリケーションが複数が一度に実施される→ネットワーク負荷が。。。 cronで別々にレプリすることでNW負荷を分散できてるかな。。。 Cloudera Search 入門(仮) Cloudera 株式会社　嶋内さん マサカリ画像がｗ SolrのコミッターMark Millerさんもジョインしてる ClouderaとHadoop入門とか。 いろいろあるよ、エコシステム 4つの分類。 データの取り込み データの保存 データの活用 Search 検索エンジンなら数十億人が使い方を知ってる（Clouderaのチャールズ・ゼドルースキ） Cloudera Search Hadoopのためのインタラクティブな検索\nCDHとSolrの統合\nOSS！\n利点とか。\nデータ解析にも使えるよね、検索 非構造化データの検索にもいいよね 単一プラットフォームによるコスパ Cloudera Searchの事例 バイオテクノロジー企業で画像検索とか 医療系企業でいろんなログイベントの管理とか Cloudera Searchのアーキテクチャ Flumeでストリーミングで登録 HBaseデータの登録 M/Rでバッチ登録 HueのWebインタフェース Morphlines、HBaseはLinyプロジェクトのもの\nSolr使うならCDH！！\nQA Q：デモで使われたTwitterの検索のデータ料とかは？\nA：デモ環境ですので小さい。\nQ：スキーマってどうするの？\nA：スキーマは。。。私が書こうかなぁ、ブログ。。。\nコンピュータビジョン　株式会社 Curious Vehicle　牧野さん 色々やってます コンピュータビジョンの説明（某ネコ型ロボットのいろんな画像がｗ） 画像検索の流れ 特徴情報の抽出 特徴情報のクラスタリングによるword化 Solrによる画像情報の検索 1. 特徴情報の抽出 SIFT特徴点解析 グレースケールしてからSIFT 注意！SIFTは商用ライセンスが必要です 2. 特徴情報のクラスタリングによるword化 K-meansでクラスタリング クラスタ情報をヒストグラム化してSolrへ 3. Solrによる画像情報の検索 物体認識ベンチマークセット（ケンタッキー大）を使って。 やっぱり良し悪しある。データセットに特化したチューニングしてます。 つぎのステップ 文字認識とか顔認識 つぎはドラえもんじゃねぇ、検索とかも。。。 ガウシアンによる画像ぼかしの例 QA マイク回しててメモ取れず。。。\n国土交通省のデータをSolrで検索　株式会社ネクスト　秀野さん スライドはこちら\n評価の関係で。。。 Spatial検索の話 デモの想定機能 地図上の小学校を起点に物件検索 地図上をクリックしたところを中心に検索 デモ環境 Solr4.3.0、PostGIS 2.0.3、東京都のデータ 事前知識 ジオメトリーデータ（点、線、面がある） WKB/WKT、Intersects（しらなかった。こんなのもあるのか） 環境 EC2上にPostGIS＋Solrで構築 WKT形式でDIHでインポートできるらしい。 Solr＋S3をJSでGoogleMapへ Solr 4.4新機能をちょっと紹介　@johtani 紹介というよりも宣伝。。。\n","date":1375107300,"dir":"post/2013/","id":"59d1b7206e7664e76672d3de4dc9a8ed","lang":"ja","lastmod":1375107300,"permalink":"https://blog.johtani.info/blog/2013/07/29/study-of-solr/","publishdate":"2013-07-29T23:15:00+09:00","summary":"不定期開催ですが第11回Solr勉強会を主催しました。 今回も大入り90人くらい？の参加者の皆さんがいらっしゃいました。ありがたいことです！（","tags":["Solr","Cloudera Search","ManifoldCF"],"title":"第11回Solr勉強会を主催しました。#SolrJP"},{"contents":"Hadoopとか離れちゃってるし、Hive触ったこと無いにもかかわらず参加しました！\n（たまたま近くにいるからって理由なのは内緒で）\n玉川さんの四方山話を聞くのが主目的で参加しました。（ちょっと翻訳が気になってるので）\nイベントページはこちら\n刊行記念イベントにも関わらず、想像以上の人の入りでびっくりしました。Hadoop、Hive界隈はまだまだ人気なんだなぁと。\nプレゼントじゃんけん大会もあったのですが、そうそうに負けてしまったのが悔やまれます。。。\nTeam Geek欲しかったなぁ。もちろん、懇親会まで参加しました。\n以下、いつものメモです。\nHiveの正しい使い方（Cloudera 嶋内さん） 残念ながら、マサカリは持ってなかったです。\nスライドの各所に本の章番号が書いてあるのがうれしい。 Hiveロゴが回ってたのでスライドの時に集中できなかったｗ Impalaの話も出てきた。 速いけど、色々足りない。Hiveの置き換えじゃないよと。 HiveとImpalaのおいしいとこ取り（セラン　須田さん） スライド：http://www.slideshare.net/sudabon/20130724-oreilly-org\nオンプレだとCDH便利だよと教えてもらう いくつかSlideshareにImpalaの性能評価の資料を上げてある（必要になったら検索で。。。） リリースされたその日に性能評価やってレポート書くとかすごすぎ！ 翻訳の四方山話（玉川さん） 翻訳＝写経です 締め切り駆動勉強法ｗ 4page/day 自分から電突してオライリーさんに翻訳させてくださいと。 他の方の本が読めない（チェックしちゃうのでｗ） 動機があるから読めるってのはあるだろうなぁ。 選び方：わくわくするもの、仕事に活きるもの 今年もあと2冊やる予定（Hadoop Operations、Vagrantを翻訳中） 来年の候補（Chefとか） 高可用性HDFSのご紹介（Cloudera 小林さん） スライドにどの版で書いてあったかがわかりやすく書いてある。 3段階の開発フェーズを経てる QJMのお話 Cloudera UniversityとHadoop認定試験（Cloudera 川崎さん） Clouderaデータアナリスト向けトレーニング（3日間、10月日本語で開催予定） Hive、Pig、Impalaなど Data Science入門コースも準備中 出版記念！ 8月管理者向け先着20 or 30名にHadoop第3版贈呈予定 先着20名にプログラミングHive贈呈予定 ","date":1374685860,"dir":"post/2013/","id":"1b9c5ae60ec46be64a1877f0c6920edc","lang":"ja","lastmod":1374685860,"permalink":"https://blog.johtani.info/blog/2013/07/25/hadoop-hive-publication-party/","publishdate":"2013-07-25T02:11:00+09:00","summary":"Hadoopとか離れちゃってるし、Hive触ったこと無いにもかかわらず参加しました！ （たまたま近くにいるからって理由なのは内緒で） 玉川さんの","tags":["Hadoop","Hive","Cloudera","オライリー"],"title":"『プログラミング Hive』 『Hadoop 第3版』刊行記念セミナーに参加しました！ #oreilly0724"},{"contents":"Yokozunaの気になる点というか、自分だったらこのへん調べるだろうなって観点を上げてみます。 別に調べるわけじゃないので、完全に自己満足なメモですけど。\nちなみに、分散システムとかRiakの仕組みは詳しくないので、ズレてる点がいっぱいあるかも。\nというか、分散システムでテストというか、検討する点とかってまとまってる資料とかあるのかなぁ？\nスキーマ変更時の挙動 フィールド型変更とか、フィールド追加とか 既存RiakクラスタにYokozunaの機能を追加する方法と制限 タイムラグとかも Riak＋Yokozunaクラスタに対してノード追加時に発生するオーバーヘッド（ネットワークとかディスクIOとか） 性能検証のためのシナリオ（どっちが先に悲鳴をあげるかとか） Riakメインで、Yokozunaはおまけ程度に検索するというシナリオ Yokozunaメインで使うシナリオ 更新が多い場合のシナリオ Riakのみ、Riak＋Yokozunaの各種統計情報（CPU、メモリ、ディスクサイズ、ネットワークIO） 運用系（監視とか）の手法とか機能？とか バージョンアップなどの対応方法 Solrがコケた時とかの対処 とりあえず、こんな感じかなぁ。\n","date":1373474580,"dir":"post/2013/","id":"50557b455cba1a3ce9b4555fc3fd5433","lang":"ja","lastmod":1373474580,"permalink":"https://blog.johtani.info/blog/2013/07/11/yokozuna-check-point/","publishdate":"2013-07-11T01:43:00+09:00","summary":"Yokozunaの気になる点というか、自分だったらこのへん調べるだろうなって観点を上げてみます。 別に調べるわけじゃないので、完全に自己満足な","tags":["Riak","Solr","Yokozuna"],"title":"Yokozunaの気になる点というかなんというか"},{"contents":"先日、Bashoさんにおじゃましたのもあり、Riak Meetup Tokyo #2に参加しました。\nYokozunaの話も聞けるということで。 懇親会も参加しました。Vさん＆リピさんと話し込んじゃってあんまり他の人と話せなかったけど。。。\n以下はいつものメモです。\nFreakOut 久森さん 「Riak環境をプロダクションで構築＆運用してみた（仮）」 FreakOutとRTB ディスプレイ広告の新しい配信の枠の話 この人には何出すの？いくらで？みたいな感じ 純広告：表示保証、期間保証など RTB：1回の広告表示ごとに買い付け DSP（デマンド・サイト・プラットフォーム） 広告表示は大体0.1秒で表示しないといけない。この間に色々やってる。 50ms or die.で戦ってます。 RTBはCPUバウンド 多コアを安く並べたい Tokyoなんとかとか使ってた。 スケーラビリティがキツイ（クライアント側でアルゴリズム分散してる） データ解析もしたいけど、検索ができない RTBに適したRiakがうまくハマるのではと。 構成とかとか アプリはPerlなので、PerlでRiakクライアントが必要。Memcached互換とかあると嬉しい。 ProtobufサポートもPurePerlしかなかった。 ないなら、作ろうと。githubに上がってます。このへんかな？ 監視はcloudforecastとかでやってる。 課題 Redirectがつらい（haproxy？がつらい？） Setが詰まるとつらい（ケースがまだわからない） 対策１ memcached＋Riak 対応２（案） hashからpartitionに直接取りに行くとか まとめ 素のままRiakはちょっとつらい QA 聞き取れたやつだけ\nQ：1台いくら位ですか？ A：10万から11万くらい Q：どのくらいの性能ですか？ A：同時1000くらいをさばいてる？ Q：50ms以下を出すのに、ネットワーク周りで近さとかを考えることありますか？ A：国内だと10msあればなんとかなる。それよりもアプリ側のチューニングのほうがまだ重要 Q：Cassandraとか候補に挙がらなかったんですか？ A：苦しんでる人が知人にいるので。。。あと、用途的に違うので。 Q：バックエンドとしてはなにを？ A：bitcaskにしてる Q：サーバ構成、ネットワーク構成がどうなってる？ A：。。。 Q：Redirectとは？RiakがやってるRedirect？ A：はい。 Q：他に候補にあがったのは？ A：商用のaerospike（これかな？）がスケールできそうだったけど、クライアントがいまいち。。。 感想 広告業界のことをよくわかってないので、微妙にピンときてなかったりもするのですが、以下に素早く返すかって観点でどこに注力して、問題点を潰していくのかってのは面白そうだなぁと。 リクエスト処理の性能がクリアできたらつぎはスケールの観点（ノード追加時の挙動とか）で検証していくんだろうなと。次回の話も聞いてみたい感じです。\nIIJ 曽我部さん、田中さん 「Yokozuna 日本語検索性能を評価しました」 Yokozunaって？ Riak＋Solrでいいとこ取り データの登録とかはRiakのAPIで。 SolrのAPIが使える。 YokozunaがSolrの分散検索の部分を隠してくれる。 Yokozunaのインストールとか。 SolrのAPIっぽい形で検索できるし、戻りもSolrのXMLっぽいのが出てくるよ。 Wikipediaデータってstoreの性能とか。 Riakのノード32台。（Xeon、メモリ24GB、HDD。。。） yz_extractor：Riakのコンテンツタイプを見てSolrにデータを入れる処理が書いてある。 自分でschema.xmlを書いてYokozunaに指定することもできる。 スキーマの変更とか登録とか。 すでに指定済みスキーマを変更した場合の挙動ってどうなるの？ デモではSolrからid取って、Riakからその他のデータを取り出していた。 Rubyでの性能評価 ベンチマークプログラム側の問題が先に影響が出てしまった。 QA Q：Riak単体とYokozunaつかった時でディスク容量がどのくらい増えた？ A：ちゃんと調べてないが、10%くらい増えた気がする。 Q：Solr側の設定でstored=trueだけど、falseにしてもいいんじゃないの？ A：デモはfalseにしてます。 Q：スキーマってあとから変更できるんですかね？ A：まだ良くわかってないです。 Q：ノードの追加、削除時の挙動とかも気になります。 感想 今回はStore性能に関してでしたが、今後は検索性能やシナリオによる性能（KVSの処理メインで、時々全文検索とか、全文検索の処理も結構あるパターンとか）の測定とか、耐障害性とかの観点で調査を進めてもらってSolr勉強会で話をしてもらえると面白そうだなぁと勝手に思ってみたり。 Solr勉強会へのコンタクトお待ちしてます！ｗ\n","date":1373450220,"dir":"post/2013/","id":"146e8ca40c0d37f36eecea822028dd9e","lang":"ja","lastmod":1373450220,"permalink":"https://blog.johtani.info/blog/2013/07/10/riak-meetup-tokyo-no2/","publishdate":"2013-07-10T18:57:00+09:00","summary":"先日、Bashoさんにおじゃましたのもあり、Riak Meetup Tokyo #2に参加しました。 Yokozunaの話も聞けるということで。 懇親会も参加しました。","tags":["Riak","Yokozuna","Solr"],"title":"Riak Meetup Tokyo #2に参加しました。#riakjp"},{"contents":"Solr 4.4に取り込まれる予定のチケットで、気になるものを見つけたのでいつものごとく調べてみました。\n元となるチケットはこちら。SOLR-4897。\nスキーマレス？ Solrはschema.xmlにデータの定義（フィールドタイプやフィールドなど）を記述して、データを登録する全文検索システムです。 これまでのSolrではこの設定ファイルを元にデータを登録するフィールド名を決定しており、 変更を行う場合はSolrのコアを再起動するなどの手順が必要でした。（※ダイナミックフィールドはすこし特殊）\nそれだと、Solrを管理するのがめんどくさいですね？という感じで現れたのがSchemaREST APIです。（たぶん。）\nSchema REST API Solr 4.2から導入されたSolrのスキーマに関する情報を提供するためのREST APIです。 4.2で導入されたのはあくまでもschema.xmlの情報を取得するためのAPIでした。 たとえば、Fieldの一覧を取得するとか。\n4.4から、フィールドの追加（変更、削除はできない）ができるようになりました。あくまでも、フィールドの追加で、フィールドタイプなどの追加はまだできません。（できるようになるのかもわからないですが。） フィールドの追加方法などはWikiに記載がありました。\nということで、簡単に試してみることに。\n起動方法 exampleディレクトリの下にexample-schemalessというディレクトリが新設されています。 ここに、スキーマレスモード用の設定がされているファイルが入っているので、こちらを利用します。\ncd $SOLR/example java -Dsolr.solr.home=example-schemaless/solr -jar start.jar ログにいくつかWARNが出ますが、影響の内パス設定ミスなので無視してOKです。\n最初に定義されているフィールドは「id」と「_version_」のみになります。（Schema Browserなどで確認できます。あ、REST APIでもいいですね。http://localhost:8983/solr/schema/fields）\nスキーマの更新 さて、フィールドを追加してみます。 PUTを利用すると1フィールドの追加が可能です。 「fugatext」というフィールド名でフィールドを追加しています。今のところJSONのみ対応みたいです。\n$ curl -X PUT http://localhost:8983/solr/schema/fields/fugatext -H \u0026#39;Content-Type: application/json\u0026#39; -d \u0026#39;{\u0026#34;type\u0026#34;:\u0026#34;text_ja\u0026#34;,\u0026#34;stored\u0026#34;:false,\u0026#34;multiValued\u0026#34;:true}\u0026#39; { \u0026#34;responseHeader\u0026#34;:{ \u0026#34;status\u0026#34;:0, \u0026#34;QTime\u0026#34;:18}} 追加できたかどうかもREST APIで取得してみます。\n$ curl http://localhost:8983/solr/schema/fields { \u0026#34;responseHeader\u0026#34;:{ \u0026#34;status\u0026#34;:0, \u0026#34;QTime\u0026#34;:0}, \u0026#34;fields\u0026#34;:[{ \u0026#34;name\u0026#34;:\u0026#34;_version_\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;long\u0026#34;, \u0026#34;indexed\u0026#34;:true, \u0026#34;stored\u0026#34;:true}, { \u0026#34;name\u0026#34;:\u0026#34;fugatext\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;text_ja\u0026#34;, \u0026#34;multiValued\u0026#34;:true, \u0026#34;stored\u0026#34;:false}, { \u0026#34;name\u0026#34;:\u0026#34;id\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;string\u0026#34;, \u0026#34;multiValued\u0026#34;:false, \u0026#34;indexed\u0026#34;:true, \u0026#34;required\u0026#34;:true, \u0026#34;stored\u0026#34;:true, \u0026#34;uniqueKey\u0026#34;:true}]} 追加できました。 ちなみに、同じフィールド名を追加しようとするとエラーが帰ってきます。\n$ curl -X PUT http://localhost:8983/solr/schema/fields/fugatext -H \u0026#39;Content-Type: application/json\u0026#39; -d \u0026#39;{\u0026#34;type\u0026#34;:\u0026#34;text_ja\u0026#34;,\u0026#34;stored\u0026#34;:false,\u0026#34;multiValued\u0026#34;:true}\u0026#39; { \u0026#34;responseHeader\u0026#34;:{ \u0026#34;status\u0026#34;:400, \u0026#34;QTime\u0026#34;:1}, \u0026#34;error\u0026#34;:{ \u0026#34;msg\u0026#34;:\u0026#34;Field \u0026#39;fugatext\u0026#39; already exists.\u0026#34;, \u0026#34;code\u0026#34;:400}} 設定の違い example-schemalessのsolrconfig.xmlは以下の設定が通常のexampleとは異なるようです。\nschemaFactoryの設定 schemaをAPIから変更可能にする設定です。これまでの変更しない設定の場合はClassicIndexSchemaFactoryを指定します。\n... \u0026lt;schemaFactory class=\u0026#34;ManagedIndexSchemaFactory\u0026#34;\u0026gt; \u0026lt;bool name=\u0026#34;mutable\u0026#34;\u0026gt;true\u0026lt;/bool\u0026gt; \u0026lt;str name=\u0026#34;managedSchemaResourceName\u0026#34;\u0026gt;managed-schema\u0026lt;/str\u0026gt; \u0026lt;/schemaFactory\u0026gt; ... update.chainの設定 更新処理（update関連のリクエストハンドラ「/update」とか）には次のような設定が追加されていました。（1006行目あたり）\n\u0026lt;requestHandler name=\u0026#34;/update\u0026#34; class=\u0026#34;solr.UpdateRequestHandler\u0026#34;\u0026gt; \u0026lt;!-- See below for information on defining updateRequestProcessorChains that can be used by name on each Update Request --\u0026gt; \u0026lt;lst name=\u0026#34;defaults\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;update.chain\u0026#34;\u0026gt;add-unknown-fields-to-the-schema\u0026lt;/str\u0026gt; \u0026lt;/lst\u0026gt; \u0026lt;/requestHandler\u0026gt; 「add-unknown-fields-to-the-schema」というupdate.chainが指定されています。このchainの定義自体は1669行目くらいに存在します。 （長い。。。）\n\u0026lt;!-- Add unknown fields to the schema An example field type guessing update processor that will attempt to parse string-typed field values as Booleans, Longs, Doubles, or Dates, and then add schema fields with the guessed field types. This requires that the schema is both managed and mutable, by declaring schemaFactory as ManagedIndexSchemaFactory, with mutable specified as true. See http://wiki.apache.org/solr/GuessingFieldTypes --\u0026gt; \u0026lt;updateRequestProcessorChain name=\u0026#34;add-unknown-fields-to-the-schema\u0026#34;\u0026gt; \u0026lt;processor class=\u0026#34;solr.RemoveBlankFieldUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;processor class=\u0026#34;solr.ParseBooleanFieldUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;processor class=\u0026#34;solr.ParseLongFieldUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;processor class=\u0026#34;solr.ParseDoubleFieldUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;processor class=\u0026#34;solr.ParseDateFieldUpdateProcessorFactory\u0026#34;\u0026gt; \u0026lt;arr name=\u0026#34;format\u0026#34;\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ss.SSSZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ss,SSSZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ss.SSS\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ss,SSS\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ssZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ss\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mmZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ss.SSSZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ss,SSSZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ss.SSS\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ss,SSS\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ssZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ss\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mmZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026lt;/str\u0026gt; \u0026lt;/arr\u0026gt; \u0026lt;/processor\u0026gt; \u0026lt;processor class=\u0026#34;solr.AddSchemaFieldsUpdateProcessorFactory\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;defaultFieldType\u0026#34;\u0026gt;text_general\u0026lt;/str\u0026gt; \u0026lt;lst name=\u0026#34;typeMapping\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;valueClass\u0026#34;\u0026gt;java.lang.Boolean\u0026lt;/str\u0026gt; \u0026lt;str name=\u0026#34;fieldType\u0026#34;\u0026gt;booleans\u0026lt;/str\u0026gt; \u0026lt;/lst\u0026gt; \u0026lt;lst name=\u0026#34;typeMapping\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;valueClass\u0026#34;\u0026gt;java.util.Date\u0026lt;/str\u0026gt; \u0026lt;str name=\u0026#34;fieldType\u0026#34;\u0026gt;tdates\u0026lt;/str\u0026gt; \u0026lt;/lst\u0026gt; \u0026lt;lst name=\u0026#34;typeMapping\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;valueClass\u0026#34;\u0026gt;java.lang.Long\u0026lt;/str\u0026gt; \u0026lt;str name=\u0026#34;valueClass\u0026#34;\u0026gt;java.lang.Integer\u0026lt;/str\u0026gt; \u0026lt;str name=\u0026#34;fieldType\u0026#34;\u0026gt;tlongs\u0026lt;/str\u0026gt; \u0026lt;/lst\u0026gt; \u0026lt;lst name=\u0026#34;typeMapping\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;valueClass\u0026#34;\u0026gt;java.lang.Number\u0026lt;/str\u0026gt; \u0026lt;str name=\u0026#34;fieldType\u0026#34;\u0026gt;tdoubles\u0026lt;/str\u0026gt; \u0026lt;/lst\u0026gt; \u0026lt;/processor\u0026gt; \u0026lt;processor class=\u0026#34;solr.LogUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;processor class=\u0026#34;solr.RunUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;/updateRequestProcessorChain\u0026gt; 使ってるUpdateProcessorはこんな感じみたいです。最後の2つはこれ用じゃないので省略。\nプロセッサ名説明 RemoveBlankFieldUpdateProcessorFactory値がないフィールドは除去 ParseBooleanFieldUpdateProcessorFactoryスキーマに定義されていないフィールドで、値がBooleanとしてパースできたら、Boolean型とする。 ParseLongFieldUpdateProcessorFactoryスキーマに定義されていないフィールドで、値がLongとしてパースできたら、Long型とする。 ParseDoubleFieldUpdateProcessorFactoryスキーマに定義されていないフィールドで、値がDoubleとしてパースできたら、Double型とする。 ParseDateFieldUpdateProcessorFactoryスキーマに定義されていないフィールドで、値がDateとしてパースできたら、Date型とする。（パースの形式がformatで列挙されてる） AddSchemaFieldsUpdateProcessorFactory入力されたドキュメントの中でスキーマに定義されていないフィールド（静的、動的両方）を見つけた時に、フィールドの値の型を元にフィールド型をマッピングする。 とここまで見てきたところで、スキーマレスという名前の意図がちょっとわかったかも。\n定義されてないフィールドを持ったデータを登録 起動時には定義されてないフィールドをもったデータを登録してみます。 boolean型で試してみることに。以下のデータを管理画面のデータ登録画面から登録します。（http://localhost:8983/solr/#/collection1/documents） （タイトルでbooleanってわかりにくいですが）\n{\u0026#34;id\u0026#34;:\u0026#34;change.me\u0026#34;,\u0026#34;title\u0026#34;:true, \u0026#34;price\u0026#34;:1.25, \u0026#34;fuga\u0026#34;:\u0026#34;100,200\u0026#34;} エラーは出ません。で、またフィールド一覧を取得すると。\n$ curl http://localhost:8983/solr/schema/fields { \u0026#34;responseHeader\u0026#34;:{ \u0026#34;status\u0026#34;:0, \u0026#34;QTime\u0026#34;:1}, \u0026#34;fields\u0026#34;:[{ \u0026#34;name\u0026#34;:\u0026#34;_version_\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;long\u0026#34;, \u0026#34;indexed\u0026#34;:true, \u0026#34;stored\u0026#34;:true}, { \u0026#34;name\u0026#34;:\u0026#34;fuga\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;tlongs\u0026#34;}, { \u0026#34;name\u0026#34;:\u0026#34;fugatext\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;text_ja\u0026#34;, \u0026#34;multiValued\u0026#34;:true, \u0026#34;stored\u0026#34;:false}, { \u0026#34;name\u0026#34;:\u0026#34;id\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;string\u0026#34;, \u0026#34;multiValued\u0026#34;:false, \u0026#34;indexed\u0026#34;:true, \u0026#34;required\u0026#34;:true, \u0026#34;stored\u0026#34;:true, \u0026#34;uniqueKey\u0026#34;:true}, { \u0026#34;name\u0026#34;:\u0026#34;price\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;tdoubles\u0026#34;}, { \u0026#34;name\u0026#34;:\u0026#34;title\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;booleans\u0026#34;}]} おー、最後にtitleが追加されてます。他にもfugaやpriceも。（日付は手を抜きました。。。）\n感想 詳細までは追いかけてないですが、こんなかんじです。 フィールド追加が可能になるのはいいんじゃないでしょうか。SolrCloudの機能との関連もあるのかもしれません。ZooKeeperへの出力も実装されてそうなので。\nただ、機械的に出力されたschema.xml（exampleだとmanaged-schemaというファイル）には_「DO NOT EDIT」_との記述があるので、修正するとなにかおきてしまうかもしれないですねぇ。 現時点では、フィールドタイプの変更やフィールドの更新、削除に関してはSolrCoreの再起動などの手順が必要です。 あと、変なデータ（タイプミスとか）が登録されたりしないかってのは気になりますね。\n※ちなみに、別の人が気づいたんですが、ちょっとバグが有ったみたいで、代わりにチケットつくったらキリ番（SOLR-5000） ゲットしましたｗ\n","date":1372867920,"dir":"post/2013/","id":"a98d42be181c01b8077e060b1b5080ec","lang":"ja","lastmod":1372867920,"permalink":"https://blog.johtani.info/blog/2013/07/04/schemaless-example/","publishdate":"2013-07-04T01:12:00+09:00","summary":"Solr 4.4に取り込まれる予定のチケットで、気になるものを見つけたのでいつものごとく調べてみました。 元となるチケットはこちら。SOLR-4897","tags":["Solr"],"title":"スキーマレスモード？（SOLR-4897）を調べて見ました。"},{"contents":"SolrのチケットをML経由で眺めてるんですが、便利そうなチケットが流れてきたのでブログを書いてみみようかと。 元になってるチケットはこちらです。昨日だか、今朝にtrunkとbranch_4xにコミットされたみたいです。試してみたい方は、branch_4xかtrunkをチェックアウトすると触ることができます。\nデータ登録用の画面（JSON） branch_4xをチェックアウトしてexampleを起動し、Solrにアクセスします。\n管理画面に「Dcuments」という項目が追加されてます。開くとこんなかんじです。\nなんと、デフォルトはJSONになってます。これも時代の流れでしょうかｗ\nSolrでは、これまで設定ファイルやデータ登録もXMLがメインになっていました。（Apache Solr入門もXMLを基本に書いてます。このころはまだデフォルトでは対応してなかったので）\n登録するデータをテキストエリアに記述して、「Submit Document」をクリックすればデータは登録されます。基本的には単件登録の画面でしょうか。 （登録されたデータを確認するには「Query」画面を利用すればいいです。） また、JSONのデータ形式はSolrのWikiを参照してください。\nCSVやXMLも この管理画面ではJSON以外の形式でもデータの登録が可能です。 「Document Type」の項目をクリックすると以下のように選択肢があられます。\nCSV、XMLについては、先ほどのJSONの画面の用に、テキストエリアが表示されます。 テキストエリアにCSV（データの形式はこちら）やXML（データの形式はこちら）を入力してボタンを押せば登録できます。\nSolr Command形式も（JOSNかXML） Solr Command というのはXMLやJSONで登録、コミット、削除などを実行するための画面になります。 JSONのコマンドはこちら、XMLのコマンドはこちらをご覧ください。\nあと、便利なのがファイルアップロードです。 こんなかんじで、ファイルを選んでSubmitすればデータが登録出来ます。\nファイルのサイズが大きいとちょっと時間がかかりますが、コマンドを打つより簡単かもしれません。 post.jarツールと違って、デフォルトでコミットをしてくれるわけではないので、「Extracting Req. Handler Params」に「commit=true」をつけないと、データが登録されてない？と思ってしまうかもしれませんが。\n組立もできるみたい（Document Builder） 最後に紹介するのが「Document Builder」というタイプです。\nもっと簡易にデータを記述できるようにということで用意されているようです。 フィールドの情報はSolrに接続して利用できるフィールド？（ダイナミックはないのかな？）が表示されます。\n追記していくとこんなかんじになります。\n日本語のデータもちゃんと登録できました。 ただ、まだ、開発中なんでしょうがないかもしれませんが、以下の様な制約があるようです。\nmultiValuedなフィールドに値を追加できない（上書きされる） 改行が入ったデータをテキストエリアにいれると「Add Field」を押しても反応しない ダイナミックフィールドは自分で書きましょう ただ、これまでXMLでファイルを作ってコマンドで登録したり、curlコマンドでJSON書いたりして登録していたよりはお手軽にさわれるようになるかと思います。つぎの4x系のバージョンが出たときはこちらからデータを登録してみてください。\n","date":1372318080,"dir":"post/2013/","id":"ecf3ac80454654d990d9c07d33d35d1c","lang":"ja","lastmod":1372318080,"permalink":"https://blog.johtani.info/blog/2013/06/27/upload-docs-solr-admin/","publishdate":"2013-06-27T16:28:00+09:00","summary":"SolrのチケットをML経由で眺めてるんですが、便利そうなチケットが流れてきたのでブログを書いてみみようかと。 元になってるチケットはこちらで","tags":["Solr"],"title":"Solrの管理画面でデータ登録"},{"contents":"前回は3番煎じぐらいでしたが、今回は初記事かな？（だといいな）\nKibanaには、前回の記事で書いたものとは別に開発中のKibana3というのが存在します。\nKibana3って？ Kibana2はRubyで書かれていましたが、Kibana3はHTML＋JavaScriptで構成されています。 ですので、ApacheなどのWebサーバに配置することで、利用が可能となります。 ただ、HTML＋JavaScriptのため、ブラウザ上で動作するためブラウザが動作するマシンからElasticSearch（通常だとhttp://マシン名orIPアドレス:9200/とか）にアクセスできなければいけないという制限があります。\nこの条件さえクリア出来れば、Kibana3ではKibana2よりも様々なパネルが用意されていて、色々できそうなのでお勧めです。\nインストール ElasticSearchやログについては、前回の記事の環境を利用しました。 ですので、Kibana3のインストールのみです。（ApacheもCentOSのサーバに入っていたので。）\nダウンロードして、Apacheの公開ディレクトリに置いただけです。（お試し環境のため、権限とかは大目に見てください。\n$ git clone https://github.com/elasticsearch/kibana.git kibana-javascript $ cp -R kibana-javascript /var/www/html 今回はApacheとElasticSearchが同一マシン（＝同一IPアドレスでアクセス可能）で動作している＋ElasticSearchへのアクセスのポートがデフォルト（9200）のため特に設定が必要ありませんでした。\nElasticSeachサーバとKibana3のApacheのサーバが別のサーバの場合やElasticSearchサーバのポートが異なる場合はkibana-javascript/config.jsファイルの編集が必要になります。 cloneしてすぐのconfig.jsは、以下のとおりです。\n/* elasticsearch: URL to your elasticsearch server. You almost certainly don\u0026#39;t want \u0026#39;http://localhost:9200\u0026#39; here. Even if Kibana and ES are on the same host kibana_index: The default ES index to use for storing Kibana specific object such as stored dashboards modules: Panel modules to load. In the future these will be inferred from your initial dashboard, though if you share dashboards you will probably need to list them all here If you need to configure the default dashboard, please see dashboards/default */ var config = new Settings( { // By default this will attempt to reach ES at the same host you have // elasticsearch installed on. You probably want to set it to the FQDN of your // elasticsearch host elasticsearch: \u0026#34;http://\u0026#34;+window.location.hostname+\u0026#34;:9200\u0026#34;, // elasticsearch: \u0026#39;http://localhost:9200\u0026#39;, kibana_index: \u0026#34;kibana-int\u0026#34;, modules: [\u0026#39;histogram\u0026#39;,\u0026#39;map\u0026#39;,\u0026#39;pie\u0026#39;,\u0026#39;table\u0026#39;,\u0026#39;stringquery\u0026#39;,\u0026#39;sort\u0026#39;, \u0026#39;timepicker\u0026#39;,\u0026#39;text\u0026#39;,\u0026#39;fields\u0026#39;,\u0026#39;hits\u0026#39;,\u0026#39;dashcontrol\u0026#39;, \u0026#39;column\u0026#39;,\u0026#39;derivequeries\u0026#39;,\u0026#39;trends\u0026#39;,\u0026#39;bettermap\u0026#39;], } ); ポート番号が異なる場合は、1つ目の「elasticsearch:」で指定されている「9200」を環境に合わせて編集するだけになります。 Kibana3とElasticSearchのホストが異なる場合は、1つ目の「elasticsearch:」の行をコメントアウトし、2つ目を有効にしてから環境に合わせたURLに修正して保存すればOKです。\n以上で、インストールは完了します。あとは、以下のURLにアクセスするだけです。\nhttp://hogehoge/kibana-javascript/ 画面構成 アクセスすると次のような画面が表示されます。\n初期画面 左上に赤い帯で、「 Oops! Could not match index pattern to any ElasticSearch indices」とエラーが表示されました。\nKibanaはElasticSearchに「logstatsh-年.月.日」という日付ごとのインデックスが存在することが前提となっています。 Kibanaに初めてアクセスした場合、「logstash-当日日付」で始まるインデックスを描画しようとします。 これは、私が前回利用したElasticSearchの環境に古いデータ（試したのが19日、データは10日のみ）しか入っていないために出たエラーです。\n日付は「Options」というエラーが出ている付近の「Absolute」というリンクをクリックすると、特定の日付をカレンダーで指定することができるようになります。データは6/10にしか入っていないので、6/10（12時くらいから20時くらいまで）のを指定します。\n日付指定 選択すると無事データが見えるようになりました。\nデータ描画 ダッシュボードの構成（初期） Kibana3では、この画面をダッシュボードというようです。 このダッシュボードは初期状態では、以下のパーツが表示されています。（子要素があとで説明するパネル名です）\nOptions：描画対象の日付の指定やダッシュボードの保存などを行うRow timepickerパネル：日付の指定 dashcontrolパネル：ダッシュボードの制御（保存とか） Query：ログ検索式を入れるところ stringqueryパネル Graph：ヒストグラムの描画（X軸：時間、Y軸：ログ件数） histogramパネル Events：検索にヒットしたログデータの描画領域 fieldsパネル：表示するフィールドの選択（左側。チェックを入れると右側のログ表示領域のカラムが増える） tableパネル：ログデータ（右側。左側でチェックが入ったカラムだけが表示される。） あくまで初期表示です。各パーツの設定アイコン（歯車のマーク）をクリックすると色々と設定が可能です。 また、「Events」など名称はクリック可能となっていて、クリックすると、そのパーツが折りたたまれた状態にすることも可能です。\n折りたたんだ状態 ダッシュボードの設定 ダッシュボードには独自のパネルを簡単に追加することができます。 ダッシュボードの構成はページの一番上にある「Logstash Search」の設定アイコンをクリックすると設定画面が開きます。\nダッシュボード設定 「New row」にタイトル名を適当にいれて「Create Row」するとあたらしくパネルを追加することができるRowが追加されます。「Rows」の「Move」にある矢印でRow自体の表示場所を上下に移動することも可能です。\nRowの設定 追加した「Hoge」にパネルを追加する場合はHogeの上にある設定アイコンをクリックすると設定画面が開きます。\nRowの設定 ここでKibana3で用意されているパネルの追加ができます。\nPanel追加ボタン パネルを選んでボタンを押せばすぐに表示されます。\nパネルの羅列 こんな感じです。とりあえず、ポコポコと追加してみました。\n利用できるパネルの種類は以下の様なパターンです。 適当ですが、表にしてみました。\nパネル名概要 columnRowの中にパネルを配置するコンテナを用意するためのパネル dashcontrolダッシュボードの保存、保存したダッシュボードの表示などの操作ボタン textmarkdown形式などで記述が可能な文章を表示できるパネル stringquery検索クエリ入力用パネル derivequeriesフィールドと検索式がわかれた形式の検索入力用パネル timepickerログ表示の期間を指定するパネル histogramログの件数のヒストグラム表示用パネル hitsヒット件数表示用パネル pieパイチャート表示用パネル trends指定された時間でデータの増減を%表示するパネル sortソート条件指定用のプルダウン表示用パネル（変更したらtableの内容がソートされる） tableログデータ表示用パネル fieldstableパネルに表示するフィールドを選択するための補助パネル bettermapなんか地図が出てきたパネルGeoJSONデータをゴニョゴニョ（表示かな？）できるみたい mapなんか世界地図が出てきたパネル２文字の国コード（jaとかか？）かU.S.の州コードのデータを元に地図に色をつけるのかな？ これらのパネルは個々に色々と設定が可能です。他にもdebug、map2など有りそうでしたがまだ使えないみたいです。\n適当に触ってて気づいた注意点です。\ntableは１ダッシュボードで１つだけが良さそう。 ２つあると、どちらかにしか描画されない。columnに入れるとグルーピングできたりするのかなぁ？ stringquery、timepickerも１ダッシュボードで１つが良さそう。 これもtableと似たような理由です。 ダッシュボード保存し忘れて泣きそうになる JSで実装されてて、自分で色々とカスタマイズできるのですが、保存するのを忘れて泣きそうになりましたｗ カスタマイズしたダッシュボードについては、ローカルに保存する以外にElasticSearchにも保存ができるみたいです。チームで共有することもできそうです。 derivequeriesを表示するとグラフがカラフルに derivequeriesを追加したらグラフが急にカラフルになりました。 どうもderivequeriesのFieldの部分を変更すると、そのフィールドの値を元にグラフを細分化してくれるようです。色の数の上限はderivequeriesのLength属性の数値で制御出来ます。（5だと5個まで色が出る） histogramのパネルで自分でクエリを記載することも可能です。ただ、derivequeriesのフィールド変更すると書き換わっちゃいます。。。 derivequeriesを追加したらカラフルに ヒストグラムは色々なパターンのグラフを描画できました。ラインによる描画（histo1）、総数を100%としたパーセンテージでの表示（histo2）、ライン＋点による描画（histo3）などです。\nヒストグラムのいくつかのパターン 感想 ということで、適当にですが触ってみました。 Kibana2はApacheのアクセスログとかの表示しかできない感じがしましたが、Kibana3だといろいろなデータを描画できそうだなと。 logstash形式のインデックスを用意するのが前提になってるので、時系列データをグラフ描画するのに向いてるんでしょうか。 お手軽にグラフ化できるし、自分でダッシュボードをカスタマイズできるのは素敵です。 ただ、クエリとグラフの関係などはちょっと癖があるかもしれないので、色々と試してみないといけないかもしれないです。 （たとえば、特定のフィールドの値について「A、B、その他」みたいなグラフの描画とかをどうするかとか）\n地図の描画は試してみたいかなぁ。\n","date":1371652980,"dir":"post/2013/","id":"26c47355cbe966a94826cbe2fbf2b355","lang":"ja","lastmod":1371652980,"permalink":"https://blog.johtani.info/blog/2013/06/19/introduction-kibana3/","publishdate":"2013-06-19T23:43:00+09:00","summary":"前回は3番煎じぐらいでしたが、今回は初記事かな？（だといいな） Kibanaには、前回の記事で書いたものとは別に開発中のKibana3というの","tags":["elasticsearch","kibana"],"title":"Kibana3というのもありまして"},{"contents":"ちょくちょく書こうと言いながら、前の記事が1週間以上前になってる。。。\n昨日は、Basho Japanに遊びに行って来ました。 （Riak触ったことないのに。。。Erlangも。。。ゴメンナサイ）\nRiakにSolrを組み合わせたYokozunaというものの名前を最近耳にしていたので、どんなものなのかなぁと興味がありまして。Solrがどんな使い方をされているのかってのが気になったので、 情報交換したいなぁと思っていたところ、Vの人が調整してくれたので色々と有意義な話ができたかなぁと。 （Yokozunaについての最新のスライドはBerlin Buzzword 2013のものがここに） Twitter上で見かけたことのある方々と話ができたり面白かったです。（やっぱ英語で会話できたりスラスラと読めるの必要だよなぁと痛感したりもしました。。。）\nということで、遊びに行ったのに美味しいピザやこんなおみやげまでもらってしまいました。 （ピザの写真撮るの忘れてたw）\nRiak＆Bashoグッズ ちなみに、Yokozunaですが、Riakに登録したデータを裏で起動しているSolにデータを流しこんでくれるものになります。 Solrの機能としては分散検索（Distributed Search）と呼ばれる仕組みを利用しているようです。 YokozunaのI/Fとしては、Solrのインデックスの分散構成は隠してくれていて、かつ、Solr（っぽい？）リクエストを投げれば裏の分散構成に問い合わせた結果をSolrのレスポンスの形で返してくれます。 KVSに全文検索の機能がついてくるお得感が満載な気がしますw。\nRiak自身のデータの取り扱いがどんなものかをまだちゃんと理解していないので（ゴメンナサイ。Little Riak Bookは開いてるんですが読んでなくて。。。）またおじゃましてもう少し情報交換したいかなぁとｗ。\nCloudera Searchといい、Yokozunaといい、Solrを利用したものが少しずつ増えてきて嬉しい限りです。 Solrの作りがしっかりしている？活発？、だから取り込む形が多いんですかねぇ。 Solr本を書いてから数年たちますが、やっと検索のニーズが出てきたのかもしれないなぁと思ってみたり。 （流れのつながりはあまりないですが）ElasticSearchも少しずつ人気が出てきてるし、日本語の本とかのニーズあったりするかなぁ？\n","date":1371603780,"dir":"post/2013/","id":"33919e866426ce8e7b2ce06f19bbf889","lang":"ja","lastmod":1371603780,"permalink":"https://blog.johtani.info/blog/2013/06/19/visited-basho/","publishdate":"2013-06-19T10:03:00+09:00","summary":"ちょくちょく書こうと言いながら、前の記事が1週間以上前になってる。。。 昨日は、Basho Japanに遊びに行って来ました。 （Riak触ったこ","tags":["Riak","Basho","Yokozuna","Solr"],"title":"Basho Japanに遊びに行きました"},{"contents":"Lucene/Solr 4.3.1のRCのVoteが始まっていますが、そのMLできになったコトがあり、ちょっと調べたので メモを残しておきます。\nマルチコアの設定ファイルであるsolr.xmlの記述方法と、コアの探索ロジックが4.4（実装的には4.3から入っている）から変更されるようです。4.x系の最新版である、branch_4xのexampleディレクトリにあるsolr.xmlも新しい記述に変更されていました。\n参考URL 新しいCore探索（4.4以降） 新しいsolr.xml（4.4以降） 4.3までのsolr.xml ちなみに、最後のold styleと呼ばれる4.3までの記述方法はつぎの5.0ではDeprecatedになるようです。（5.0がいつ出るのかはわからないですが。）\nCore探索ロジック 4.4から、$SOLR_HOMEディレクトリ以下の探索ロジックは次のようになるようです。 以下では、「新スタイル」（4.4以降の書式）、「旧スタイル」（4.3以下の書式）として記述します。\nsolr.xmlファイルの存在チェック solr.xmlが存在しない場合→旧スタイルとして処理→3へ（旧スタイル） solr.xmlが存在し\u0026lt;cores\u0026gt;タグが存在しない場合→2へ（新スタイル） solr.xmlが存在し\u0026lt;cores\u0026gt;タグが存在する場合→3へ（旧スタイル） 新スタイルのロジック SOLR_HOMEディレクトリに存在するディレクトリについて以下の処理を繰り返す SOLR_HOME/ディレクトリ/core.propertiesファイルが存在する→後続処理へ。存在しなければ終了 SOLR_HOME/ディレクトリ/conf/solrconfig.xmlを読み込み、コアを起動 旧スタイルのロジック これまで同様、solr.xmlの\u0026lt;core\u0026gt;タグの記載内容を元にコアを起動（instanceDir以下のconf/solrconfig.xmlを使って） solr.xmlが存在しない場合はSOLR_HOME/collection1/conf/solrconfig.xmlが存在するものとしてコアを起動 このようなロジックになります。\nちなみに、以下の場合はエラーとなりSolrは起動しますがログや管理画面にエラーである表示がされます。\n2.3でsolrconfig.xmlが見つけられなかった場合 3.1で\u0026lt;core\u0026gt;タグが存在しなかった場合（この場合、ログにはエラーが出ません） propertiesに記述できる内容やsolr.xmlの記述内容については、Wikiを見てもらうということで。。。 CoreAdminHandlerでコアを生成したりした場合に、新スタイルの設定がどのように出力されるのかといった点が気になりますが、また今度にでも。\n","date":1370945460,"dir":"post/2013/","id":"78292d953eafbdf9e57cc4bbbe6e8964","lang":"ja","lastmod":1370945460,"permalink":"https://blog.johtani.info/blog/2013/06/11/new-solr-xml/","publishdate":"2013-06-11T19:11:00+09:00","summary":"Lucene/Solr 4.3.1のRCのVoteが始まっていますが、そのMLできになったコトがあり、ちょっと調べたので メモを残しておきます。 マルチコアの設定ファ","tags":["Solr"],"title":"新しいsolr.xmlとCore探索ロジック"},{"contents":"もう何番煎じだ？ってくらい書かれてますが、コリもせず書いてみました。 Elasticsearch＋Kibanaの環境を作って、タムタムさんのログ生成ツールからApacheのダミーログを流しこんで入れてみました。\n参考URL memorycraftさんのブログ Kibana Elasticsearch fluentd apache-loggen インストールと起動 今回はCentOSへのインストールです。 基本的にはmemorycraftさんのブログの流れのままです。\nelasticserchのインストールと起動 ダウンロードして、起動するだけ。 お試しということで、-fオプションにてコンソールにログ出力。\ncurl -OL https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-0.90.1.tar.gz tar zxvf elasticsearch-0.90.1.tar.gz cd elasticsearch-0.90.1 ./bin/elasticsearch -f Kibanaのインストールと起動 git cloneしてbundleインストール\ngit clone --branch=kibana-ruby https://github.com/rashidkpc/Kibana.git cd Kibana bundle install ruby kibana.rb これで、Kibana＋ESのインストール＋起動が完了。 下地が完了。\ntd-agentのインストールと起動 ログの流し込みはlogstashなのですが、fluentdのelasticsearchプラグインにて流しこむこともできます。 td.repoとしてtd-agentのリポジトリを登録してから以下を実行します。\nyum install td-agent -y /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-elasticsearch vim　/etc/td-agent/td-agent.conf /etc/init.d/td-agent start これで、td-agentがインストール出来ました。 次は設定です。\n\u0026lt;source\u0026gt; type tail format apache path /var/log/httpd/dummy_access_log tag dummy.apache.access \u0026lt;/source\u0026gt; \u0026lt;match *.apache.*\u0026gt; index_name adminpack type_name apache type elasticsearch include_tag_key true tag_key @log_name host localhost port 9200 logstash_format true flush_interval 10s \u0026lt;/match\u0026gt; 以上が設定です。td-agentはtd-agentというユーザで起動されるので、/var/log/httpdディレクトリにアクセスできるかだけ確認が必要です。\nいくつかの設定値について気になったので調べました。\nindex_name：adminpackとなってるが、elasticsearchではlogstash-xxxとなってる。 これは、logstash_formatがtrueの場合は、利用されないので、指定しなくてもいい。 type_name：Elasticsearchのタイプ名 *　これはlogstash_formatを指定しても有効。ただし、Kibana側で画面からのtype指定は不可能。KibanaConfig.rbにて指定することは可能。 logstash_format：Kibana用にlogstashフォーマットで出力するオプション この指定があるときは、index名が「logstash-YYYY.mm.dd」となる record（ログ）に@timestampとして時刻が追加される。 tag_key：include_tag_keyがtrueと指定されているため、record（ログ）にtag_keyで指定した文字列をキー、値としてtagの値（上記例だとdummy.apache.access）が付与されて登録される。 apache-loggenのインストールと起動 タムタムさんが作成されたApacheのログのダミーを生成するツールです。\ngem化されてるので、インストールは非常に簡単です。\ngem install apache-loggen で、ログを出力します。出力先は先程設定したdummy_access_logです。\napache-loggen --rate=10 --progress /var/log/httpd/dummy_access_log 秒間10アクセスログを出力してくれます。 これで、Kibanaでログが見れるようになりました。 なんて簡単なんでしょう。。。 簡単なログの検索ができてしまいました。 他の形式のログがどうなるのかとかは、また時間があれば。。。\n感想とか 非常に簡単でした。素敵です。いくつかこうなるのかな？というのを試してみたのでメモを。\nいくつか疑問点です。\n溜まったログの削除は手動？ おそらく。日付ごとにindexが出来上がっているので、削除は楽そう。「logstash-年月日」なので。 認証とかかけれるの？ ログ検索は内部でするだろうから、まぁ、なくていいのかな。ログインすらないし。 複数行のログとかってどーすんだろう？（JavaのExceptionとかが混ざるやつ） 本格的に触るようになれば調べるかなぁ。。。\nあと、ログが増えてきた時にどういった分割構成ができるだろう？って思って考えてみたのが以下になります。\n構成パターン ログを複数扱う場合は次のようなパターンがありそうかと。\nタグ（fluentdのタグ）で識別 「@log_name」という名前＝fluentdのタグにてログを識別することで、異なるログを検索することができそうです。 タグであれば、プラグインによってはログ出力時に制御も可能だと思うので、td-agentの設定を変更したりすることもなく対応が可能かと。 ただ、ログの種別ごとにKibanaのプロセスを別にして起動したいといった用途には向いてなさそうです。\ntype_nameによる識別 ElasticSearchの機能であるtypeを利用したログの識別パターンです。\nfluent-plugin-elasticsearchの設定でtype_nameを指定しました。 ここを別の名前にすることで、識別することも可能です。\nただし、この場合はKibanaの画面から指定して検索することができません。 →コメント頂きました。検索条件に「_type:タイプ名」と検索することでtypeを利用した検索が可能です。\nタグ（@log_name）でも識別できるようにするなどの工夫が必要です。 その代わり、タグ識別ではできなかったKibanaのプロセスを別にして起動することは可能になります。\nKibanaConfig.rbのTypeに値を設定することで、起動したKibanaが対象とするログを絞り込むことが可能です。 こうすることで例えば、apache用のKibanaとtomcat用のKibanaは別プロセスにして、ElasticSearchのクラスタは1つという構成も可能になります。\nElasticSearchサーバを別立て ElasticSearchサーバをそもそも別のプロセスor別のサーバで起動し、Kibanaも別々にすればログの識別も可能です。 可能ですが、色々と管理するものが増えてめんどくさそうですね。。。\nインデックス名変更 最後は、fluent-plugin-elasticsearchの設定で「logstash_format」をfalseにすれば、好きなindex_nameを付与できるので、 ログ種別ごとに名前を変更することで識別できます。\nただ、logstash形式でないインデックス名の場合、日付ローテーションができなかったり、Kibana内部で検索時に日付で検索対象を絞り込んで検索することで高速化するといった処理など、使えない機能が多々出てきてしまうのであまりおすすめじゃないかと。。。\nということで、流行りものは触っておこうということで、さわってブログ書いてみました。\n開発中に立てておいて、各サーバのログを流しこんでおくなどにも利用できるかもしれないです。 アラート通知などの機能が出てくるともっと便利かもしれないです。\n","date":1370874840,"dir":"post/2013/","id":"c4d3a917f623f58646ce93015d79e8e0","lang":"ja","lastmod":1370874840,"permalink":"https://blog.johtani.info/blog/2013/06/10/fluent-es-kibana/","publishdate":"2013-06-10T23:34:00+09:00","summary":"もう何番煎じだ？ってくらい書かれてますが、コリもせず書いてみました。 Elasticsearch＋Kibanaの環境を作って、タムタムさんのロ","tags":["kibana","elasticsearch","fluentd"],"title":"apache-loggen + fluentd + elasticsearch + kibana = ログ検索デモ"},{"contents":"昨日に引き続き、AWS Summit Tokyo 2013に行ってきました。\n@ryu_kobayashiさんからパシリを仰せつかるなどあり、忙しかったのですが楽しかったです。\n今日もすごい人出で、昼時の展示ブースは人だかりで、TDの方たち忙しそうでした。 後半はちょっとつかれたなぁ。 1日目よりも空調の温度が上がってたので快適でした。 飲物忘れたので、ちょっと喉がやられ気味でしたが。\nAWSはやっぱり勢いがあるんだなぁってのを実感しました。JAWS-UGまで残った感想です。 あとは、セルフハンズオンに参加するんだったかなぁというのもちょっとあります。あんまり触ったことないんで。\n以下はいつものメモです。\nAmazon Redshiftが切り開くクラウド・データウェアハウス 自己紹介と流れとニュース 6/5からTokyoリージョンでも利用可能に！ Redshiftどんなもの？ Redshift＝クラウド型データウェアハウス オンプレの課題 初期投資、運用管理、費用対効果 EMRと同じで、分析処理向けのサービス 簡単な利用例 各種データストア→S3→Redshift 各種データストア→EMR→Redshift Data Pipelineでデータの流れの処理がかける。 データロードはパラレルに実行可能 バックアップは管理コンソールからボタンででも可能。 クラスタのリサイズも管理コンソールからできるよ。 NRIでの評価 2012年末の限定公開してすぐに先行評価に参加\nRedshiftの性能は？\n500億件からの検索処理（1週間分のデータを抜き出して処理するSQL） 8XLノード2ノードで43秒、4ノードで27.8秒、8ノードで19秒 データロドも線形に性能が上がる 1.2億件の検索処理は4ノードより8ノードのほうが性能劣化 EMRとRedshiftの比較。1.5TB、500億件でのJOIN＋集計処理でRedshiftのほうが早かった。 Redshiftのチューニングポイント\nインデックスが存在得ず、Distribution Keyでノードに分散 Sort Keyも重要。データロード時間はSort Keyをつけると遅くなる ニガテなデータ形式もあるよ。EMRとかの組み合わせにすると安く済むこともあるよ\n簡単につくれるので、気をつけましょう。セキュリティとか。統制されないものが乱立してくるんで。\nそこでNRIですよ！（宣伝） 出てきた性能に関するものだけど、「ケース１」「ケース２」とかってなってるので、その部分の詳細が書かれたレポートが公開されないとどんなのがニガテなのかとかわからなかった。\n事例紹介とか オンプレのデータをどうやってRedshiftに持ってくの？ インフォテリアのASTERIA WARP GUIツールでデータの変換とかして、S3に持って行って、Redshiftと連携できるよと。 無料セミナーの紹介 6/21、8/2にRedshiftの無料セミナーやりますよ。 インターネット上のユーザーの行動の可視化を実現したAWSによるビックデータ解析基盤 C-Finderのサービス紹介 元オプトの方。C-Finderの紹介。 10万ユーザの行動履歴の可視化。\nサイトに来たけど、行動せずに他サイトに移動したとか、サイトに来る前の状態ってのがわからない。これをC-Finderで可視化。\n例１：自動車業界 ライバル企業の動向を自社と比較したい。 Audi、BMW、ベンツで可視化。 例２：化粧品業界 Web上での化粧品のトレンドが見たい。 @cosmeサイトのPVとかから。 ユーザって会員登録とかしてる人を追っかけてるってことなのかなぁ？ よくわかってない。。。\nレポーティングサービスしてたけど、納品まで１ヶ月かかってた。 リアルタイムにみたいという要望が多かったのでASPをTISと開発 ASPサービスの開発したよ AWSで。 可視化というタイトルだったんだけど、期待してた可視化の話ではなかった。。。\nネット選挙クラウド　～オバマ大統領選挙の事例：データ解析からネット募金まで～ ボランティアで構成ってすごいな。 本番まで１年 みんな髭の人だｗ GoogleとかFacebookとかの人がボランティアで開発に参加。 予算は抑えながら、スケールアップダウンがすぐ出来てとか。 秒間10万回のI/OのDB SQSとEC2のSoftware queueの比較。Softwareキュー選ぶと、さらにドレがいいのかってのを選ばないとい。 AWSにあるサービスなら、造らなくてもいいのではとか。 CloudSearchはつかわなかったのかなぁ？ tsunami S3に静的ページをおいて、最後のとりでにしたり。 コードとか、ノウハウってどこまで公開されてるんだろ？ 同時通訳もあったんですが、英語を聞いてみようと聞いてましたが、まだまだダメですねぇ。\nパネルディスカッション「ウェブテクノロジーをエンタープライズで活かすには？」 趣旨 B2B、B2C間でのトレンドのやり取りが加速されてるよねと。 ICTはもはやコモディティ？ TD太田さん Consumerization Of IT 色々なものがSaaSになってきてる TD：Consumerization of Data Infrastructure オンプレ＜AWS＜TD 三井物産黒田さん 三井クラウド（プライベート＆パブリック） ユビキタス これまで使ってきたものがクラウドで動くのかとかが観点 電通平川さん マーケティングダッシュボードはsalesforceでは厳しかった？ ビジネスに注力したいので、柔軟で、質実剛健なICT基盤がほしい。 ディスカッション 新しい技術に対するスタンスは？\nいかにダメな部分を潰していくか（太田さん） R\u0026amp;Dを予算化して評価して取り組んでいく。評価でダメならつぎ。（黒田さん） 消費者の方たちがネットですごい勢いで活動してる。その人達へのアプローチが重要。（平川さん） コンシューマ系技術の懸念事項は？\nセキュリティ面。レベルがある。自分の所だけじゃなく、クラウドベンダーと二人三脚が必要。丸投げはNG（黒田さん） セキュリティ面の攻撃を受けたつぎの手をどう打つかが重要。堅牢性上げると、ユーザビリティが下がる。（平川さん） 法規制的に出せないとかもある。持ちきれないデータもあるよね。（太田さん） 何を見分けてどうやって取り組むか？\nとりあえず、やってみる。そこで見える課題に対応していく。見極めるのは難しい（平川さん） ということは、すぐに出来る環境ってのは当たり前になってますよね。\n尖った技術＝セキュリティ面が弱い？みたいな印象があるのかなぁ？\nJAWS-UG AWSアップデート AmazonのCTO登場 Game Day Game Day。土曜日にやるよ。 障害を発生させて、それを復旧させる。 最もひどい壊し方をしたらかちｗ 最後はかるくボッチでした。。。 AWSあんまり使ってないからなぁ。。。\n","date":1370527200,"dir":"post/2013/","id":"d12c1c2a68be4c7fda5a7737d5493b4d","lang":"ja","lastmod":1370527200,"permalink":"https://blog.johtani.info/blog/2013/06/06/aws-summit-tokyo-day2/","publishdate":"2013-06-06T23:00:00+09:00","summary":"昨日に引き続き、AWS Summit Tokyo 2013に行ってきました。 @ryu_kobayashiさんからパシリを仰せつかるなどあり、忙しかったのですが楽しか","tags":["AWS","勉強会"],"title":"AWS Summit Tokyo 2013に行って来ました。(Day2) #awssummit"},{"contents":"ざっとインストールガイドとかCloudera Searchのソース眺めて、テキトーにメモを書いてみました。 （ユーザガイドはまだ読んでないです。）\nざっくりメモ ストリーム処理でインデックス作るときはFlume経由でSolrに SinkとEventの両方が用意されてる？（Flumeを良く知らないので、違いがわからない） FluemeからはリモートのSolrに対してインデックス登録するクラスがある。SolrServerDocumentLoaderがソレだと思う。 バッチ処理でインデックス作るときはMapReduceIndexerToolsってのを使ってSolrに SOLR-1301がベースになっている。色々と改良されてるようだけど、コアとなってる処理はSOLR-1301。 GoLiveってクラスの処理の中で、現在動作してるSolrに配布したバッチで作成されたIndexをマージする処理が書いてある。 HDFSへ出力されたインデックスはリモートのSolrからアクセスするとオーバヘッドとかどーなるのかなぁ？ 検索処理自体はHueでもできるけど、基本的にSolrCloud任せ インデキシングの処理のフローについてはCloudera Mrophlinesで定義 ということで、 2つの流れがありそう。\nHDFS→Flume→Solr HDFS→MapReduce→Solr で、まだ、わかってないですが、構成要素として\nHadoop（HDFS）：データソース Hadoop（MapReduce）：データ変換処理、バッチインデキシング Zookeeper：SolrCloudのクラスタ管理 Solr：インデキシング、検索エンジン Flume：データをストリーミングでSolrへ Coudera Morphlines：HDFSからSolrまでのETLデータ処理を定義実行する環境 って感じでしょうか。 SolrCloudのクラスタとHadoopのクラスタが同一マシン上なのか、別なのかとか。組み合わせがどんなものができるのかがまだわかってないです。 ユーザガイド読んでみたらなにか出てくるかなぁ。\nちなみに、Cloudera SearchのgithubリポジトリにあるソースはCloudera Morphlinesのコードがメインで、SolrのHDFS対応版のソースがあるわけでは無かったです。\nSolrのHdfsDirectoryってのがClouderaのリポジトリにあるSolrには追加されていて、これが、HDFSのインデックスを読み込んだりする処理が出来る仕組みっぽい。 一応、SolrCloud以外（分散検索）も考慮された形になってるっぽい。 ってとこでしょうか。\n感想 読んでて思ったんですが、Cloudera Searchの肝はじつは、検索じゃなくて、Morphlinesにあるんじゃないかなぁと。今はSolrが出力先ですが、 その他のデータ変換処理とかが増えてくると、処理の流れがMorphlinesで定義できてデータ変換処理が簡便になりそうな気が。\nその他に気になる観点 CDH経由でSolrCloudのクラスタの管理するのかな？ SolrCloud用のクラスタとCDHのクラスタって同一マシンに載るの？別マシンにもできるの？ 併存したらIOがキツそうだけど Hueで検索アプリとか組めるの？（そもそもHueがわかってないんだけど。。。） ま、とりあえず、こんなとこで。 つぎは余力があれば、ユーザガイドかなぁ。 英語力。。。\n","date":1370489160,"dir":"post/2013/","id":"f45069216cd934b80ce882c9a2f2a08a","lang":"ja","lastmod":1370489160,"permalink":"https://blog.johtani.info/blog/2013/06/06/cloudera-search-memo2/","publishdate":"2013-06-06T12:26:00+09:00","summary":"ざっとインストールガイドとかCloudera Searchのソース眺めて、テキトーにメモを書いてみました。 （ユーザガイドはまだ読んでないです。","tags":["Cloudera Search","Hadoop","Solr"],"title":"Cloudera Searchメモ（妄想版）"},{"contents":"AWS Summit Tokyo 2013に行って来ました。\n@cocoatomoさんに行き掛けに出会ったので、アンデルセンの講演を一緒に聞いてました。 TDブースの@ryu_kobayashiさんに挨拶に伺ったりも。\nすごい人で、セッション間の入れ替え時には会場前のスペースが大変なことになってました。もう少し余裕のある建物のほうが良かったのかもしれないですねぇ。\nいつものように以下はメモです。\nRoad to AWS アンデルセンサービス とてもおいしいランチボックスでした。\n広島（ここ重要！）に本社のあるパン屋さん。\n2003年に汎用機からOpenシステムに 内製ではなく外注に。複数のSIerにお願いしてるとデータセンタに マスタ管理と生産管理はオンプレ 2004年に稼動時のネットワーク整備。店舗はISDNで、設定ミスとかを防ぐためにIIJのSMFサービスに PCはレンタル契約にしたので入れ替えを強制できる→レガシーシステムの対応が必要なくなる ネットワーク広帯域化→基本システムにデータセンターに。 2009年にリース満了などで、OSの変更とかミドルの変更という移行SI費用だけで結構な値段が。ものによっては会社もない。 データセンターの月額手数料にして、機器変更などの費用を平準化。仮想化など。 けど、サイジングにどうしても安全係数をかけてしまうことに。結構値段がかかる そこで、今後の方向性 SIerどっぷりのOLTP受発注基幹システムはSIerのホスティングで それ以外のシステムは外に出したい バッチの計算を早くすることができるとノーチラスさんから提案された バッチを外部化するか、性能あげるか。IOネックなどもありスペック上げるとコストになるから、外部化したい Hadoopを組むけど、オンプレじゃなくてAWSにした。ノウハウがないので、ノーチラスさんにお任せした。 AWSのEMRを利用。4時間かかっていたものが40分で。 EDIのサーバを6ヶ月でAWSに移行 S3絡みで2度の問題が。性能劣化があった。 パッケージ開発環境がAWSにあるなら、AWSでも動くでしょ？（NTTイントラマートとか） SIerどっぷりの部分もAWSに持っていく？ アンデルセンサービスの部長さんからのAWSへの要望 メールサーバなどの基本サビスとか、コントロールパネルを充実して欲しい。 クラウド技術を活用したリアルタイム広告\u0026quot;Logicad\u0026quot;の入札・配信・ログ解析 Web広告の歴史 最初は広告主がWebサイト単位で契約 アドネットワークによる仲介 聞きそびれた。。。DSP？ アドネッエクスチェンジ SSP(Supply Side Platform) リアルタイムビッティング（RTB） RTPの仕組みを説明。 AWSとオンプレでシステムを構築してる。\nSSP事業者との取引はオンプレ 配信はAWS オンプレとAWSはAWS Direct Conectで接続 S3とHadoopの接続が安くなったり速くなったりするらしい。 オンプレミス側 Bidリクエスト：秒間数万件。。。 KVSのユーザ数は３億件。。。 AEROSPIKEというSSD向けのKVSを利用してる AWS側 ログはS3に。溜まったデータは定期的にEMRで解析。DynamoDBに入れてレポート作成 RabbitMQを使ってる。 ELBで外部からのリクエストはバランシング データセンタ間通信 遅延を複数コネクションを貼る方法で回避？ 非同期で、複数のMsgとAckをやり取りする。RabbitMQがこれに相当する機能を持ってる QueueとConsumerで多重送信が可能。 配信結果をオンプレ側に送るのにRabbitMQを使ってるのかな？ ハイブリッド構成を支えるAWSテクノロジー 聞くつもりだったんだけど、すごい人だったので、諦めて充電してた。\nAWSクラウドで構築する、ワールドクラスの分散クラウドアーキテクチャ エマージングソリューション部の部長のshot6さん。\nマルチAZ（アベイラビリティゾーン）モデル AWS固有のコンセプト。 ELBやDynamoDBやRDS、S3とか。\nマルチリージョンとは違うよと。マルチリージョンは結構難しいので。 マルチリージョンがどんなに大変かをこれから説明。\nマルチリージョンアーキテクチャ（これは別物） 複数のリージョンを利用して作る。 AWSのビルディングブロックではカバーしない範囲をカバーしないとダメとか。 リージョン間の通信は基本的に非同期 ディザスタリカバリ コストバランス見てから決めるよね。 CAP定理とかもいろいろと出てくるよね。 合意プロトコル。正確性、生存性（時間が制限されても大丈夫）、理論的にパフォーマンス出る？ 非同期レプリケーションになる（1トランザクション当たりのオーバヘッドが大きいから）けど、復旧の難しさがある。 GlusterFSとかでやってるとこもある。 NetflixはCassandraをクオラム＋Geo-Replicationでマルチリージョンを構成してる。 マルチリージョンでのデータ一貫性は維持がむずい 注意点 必要になるまで分散させない。 まずは、マルチAZを考えましょう 物理制限を考慮する 同期型だとタイムラグあるし。 複合障害の伝搬をどう抑えるか。 NetflixはHYSTRIXというのがいて遮断できるようにしている 自動化が重要。ロールバックとかロールアウトとか。 テストをどーするの？ 本番環境でアクティブ/アクティブ構成でのテスト。 ちゃんとフェイルオーバするかなどを実環境でやってる。DB落としたり。。。 障害は避けられないので、受け入れて日常に取り込むべきだよねと。\nAmazon.comではGameDay NetflixはChaos Monkey（OSS） Obama for America リカバリーオリエンテッドコンピューティングパターン\nボーアバグ：再現可能なソフトウェバグ ハイゼンバグ：通常ではありえないパターンで発生するバグで、調査が大変 ということで、マルチAZがいいよ 同期式レプリケーションを前提にできる。 アプリ開発者がアプリにフォーカスできる。分散系の難しいところはAWSが隠蔽してくれるから。 ","date":1370424600,"dir":"post/2013/","id":"1fe14e2e02b6e65e6e6e2ae3d8ddcc9f","lang":"ja","lastmod":1370424600,"permalink":"https://blog.johtani.info/blog/2013/06/05/aws-summit-tokyo-day1/","publishdate":"2013-06-05T18:30:00+09:00","summary":"AWS Summit Tokyo 2013に行って来ました。 @cocoatomoさんに行き掛けに出会ったので、アンデルセンの講演を一緒に聞いてました。 TDブースの@ry","tags":["勉強会","AWS"],"title":"AWS Summit Tokyo 2013に行って来ました。(Day1) #awssummit"},{"contents":"Cloudera Searchは次のようなモジュールから構成されています。 これはCloudera Searchのモジュールで、さらにこれらがSolrとかを使ってるみたいですね。pom.xmlを見たら何を使ってるかがわかるかな。\ncdk-morphlines search-contrib search-core search-flume search-mr search-solrcell てきとーに、README.mdみながらメモを残してみました。ソースとかはまだ読んでないです。 ざっと眺めたけど、インデキシング処理の話がメインで、検索側がどうやって動くかってのがわからなかったなぁ。 ユーザガイド（注：PDF）ってのがあるから、これを読んでみるか。。。\n各モジュールについては、以下。\ncdk-morphlines（Cloudera Morphlines） Cloudera Morphlinesという名前みたい。 検インデキシングアプリの構築、変更をラクにするためのフレームワーク。 ETLの処理チェインを簡単にCloudera Searchにデータを入れる設定（Extract/Transform/Load処理）がかけると。 バッチ処理、Near Real Timeのために使えるみたい。検索結果をさらに入れるとかもできるんかなぁ。？\nUnixパイプラインのの進化版みたいなもので、一般的なレコードに対するStream処理から、Flueme、MapReduce、Pig、Hie、SqoopのようなHadoopコンポーネントも使えるみたい。\nHadoop ETLアプリケーションのプロトタイピングにも使えて、リアルタイムで複雑なStreamやイベント処理やログファイル解析とかに使えるの？\n設定ファイルのフォーマットはHOCONフォーマット。AkkaやPlayで使われてる。\ncdk-morphlines-core Cloudera Morphlinesのコンパイラ、実行環境、コマンドのライブラリを含んでる。 ログファイル解析やsingle-lineレコード、multi-lineレコード、CSVファイル、正規表現パターンマッチ、フィールドごとの比較とか条件分岐とか、文字列変換とか色々なコマンドを含んでる。\ncdk-morphlines-avro Avroファイルやオブジェクトの抽出、変換、読み込み処理コマンド\ncdk-morphlines-tika バイナリデータからMIMEタイプを検出して、解凍するコマンド。Tikaに依存\n雑感 Cloudera Searchへのデータの流し込みを設定ファイルに記述して実行するとデータの変換処理とかが記述できるって感じかな？ Morphlinesのコマンドとして独自処理や使えそうな処理を作ることで、いろんな処理ができるって感じかなぁ。\nsearch-core Solrに対するMorphlineコマンドの上位モジュール\nsearch-solrcell Tikaパーサを使ったSolrCellを使うためのMorphlineコマンド。 HTML、XML、PDF、Wordなど、Tikaがサポートしてるものがサポート対象。\nsearch-flume Flueme Morphline Solr Sink。 Apache Flumeのイベントから検索ドキュメントを抽出、変換し、SolrにNearRealTimeで読み込むためのコマンド\nsearch-mr HDFSに保存されたファイルに含まれる大量データをMapReduceで処理してHDFS上の検索インデックスに焼きこむモジュール。\nMapReduceIndexerToolは入力ファイルの集合からSolrのインデックスシャードの集合を作るためのmorphlineのタスクで、MapReduceのバッチジョブドライバー。 HDFSにインデックスを書き込む。 動作してるSolrサーバに対して出力されたデータをマージするのもサポートしてる。\nとりあえず、Near Real Time検索するにはFlueme使って、バッチ処理でインデックス焼くのはMapReduceIndexerToolみたいだなぁ。\n","date":1370412720,"dir":"post/2013/","id":"e30258aeb8475d4c27f7935945671856","lang":"ja","lastmod":1370412720,"permalink":"https://blog.johtani.info/blog/2013/06/05/cloudera-search-modules/","publishdate":"2013-06-05T15:12:00+09:00","summary":"Cloudera Searchは次のようなモジュールから構成されています。 これはCloudera Searchのモジュールで、さらにこれらがSolrとかを使っ","tags":["Cloudera","Hadoop","Solr","Cloudera Search"],"title":"Cloudera Searchのモジュールたち"},{"contents":"AWS Summitに来ていたのですが、TLでは、Cloudera Searchが賑わってました。 ということで、軽くどんなものか読んだり調べたりしたメモを残しとこうかと。 英語力はあやしいので、おかしいとこがあったらツッコミを。\nCloudera Searchとは？ CDH4.3に対応したCDHユーザ向けの検索システム（beta版）なのかな？ CDHに統合された検索フレームワークなのかな？\n基本はLucene/Solr 4.3でHadoopのペタバイトデータを検索することができるようになるみたいです。\nどんな仕組み？ 次のものを利用しているようです。（GithubのREADMEから。）\n使ってるもの Apache Solr(4.3.0＋α？) Apache Lucene（Solrつかってるからね） Apache SolrCloud（うーん、Solrに含まれるのに別に出してるのなんで？） Apache Flume Apache Hadoop MapReduce \u0026amp; HDFS Apache Tika SolrCellとしてSolrにも組み込まれてる、いろんな文書（WordとかHTMLなどなど）からメタデータと本文データとかを取り出せるライブラリラッパー。実際にはさらにpdfboxとかを使って各文書からのデータを取り出してる。 何ができるの？ HBaseやHDFSの用にZookeeperを使ってインデックスのシャーディングや高可用性ができる。（SolrCloudがZookeeperを使ってるからね。） MapReduceのジョブの出力から自動的にSolrのインデックスにデータをマージできるらしい。 Cloudera Managerを使って、デプロイ、設定モニタリングなどが可能。\nFlumeのフィードをつかって、ストリーミングしてインデックスを作れる。FluemeがデータをSolrに流しこむのかな？ 将来的にはHiveやHBaseのテーブルをインデックスすることも可能になるらしい。Impalaクエリの結果もフィードできるのか？\nApache Blurってキーワードも出てきた。HDFSのデータからLuceneのインデックス作るのかな？ NGDataのチームがSolr/HBaseの統合とかしてるみたい。\n参考URL Cloudera社のブログ Cloudera SearchのFAQ（注：PDF） Githubのリポジトリ ","date":1370412300,"dir":"post/2013/","id":"cd90bce912f5743226af94c1efaaa4a7","lang":"ja","lastmod":1370412300,"permalink":"https://blog.johtani.info/blog/2013/06/05/what-is-cloudera-search/","publishdate":"2013-06-05T15:05:00+09:00","summary":"AWS Summitに来ていたのですが、TLでは、Cloudera Searchが賑わってました。 ということで、軽くどんなものか読んだり調べたりした","tags":["Cloudera","Hadoop","Solr","Cloudera Search"],"title":"Cloudera Searchってのが出たらしい（とりあえず、雑感？）"},{"contents":"憧れ？のfluentを使ってみました。 こちらの記事で紹介したZoomdataを最近触っているのですが、お試しにfluentdでデータ流し込むプラグインを作ってみようかなぁと。（今は、Javaでの接続も書いていて、主にそっちを使っています。） ということで、作ってみました。fluent-plugin-zoomdata。\n基本的にはtagomoris先生のfluent-plugin-growthforecastを参考（パクリ？）にさせてもらいました。 作っている最中もここわからんってツイートに反応していただき、大変助かりました。 私はベースがJavaの人間なので、手探り状態でRubyを書いています。そこおかしいんじゃないの？とかあればコメントもらえると嬉しいです。\nZoomdataのAPI ZoomdataのAPIはこんなかんじで、JSONをHTTPSでPOSTするものになります。\n指定する必要があるものは、以下の項目です。\nsource：Zoomdataのデータ保存先（Zoomdataでのデータを保存する単位。） user：Zoomdataのユーザ名 password：Zoomdataのユーザのパスワード JSONデータ：Zoomdataでグラフ化するデータ sourceはデータ保存先の名称で、この単位でZoomdataはデータを保存、描画します。fluentdのタグをこれにするとわかりやすいかなぁ？と考えていったん、実装してみています。\nで、作成したプログラムを使いつつ、Zoomdataの検証をしたかったので、つぎのような簡単なプログラムを作って動かしてみました。\nサンプルプログラムの構成 基本的にJavaの人なので、クライアントはJavaで書いてます。 CLIプログラムで適当なJSONを作って、fluent-loggerを使って、fluentdに投げ込みます。\nfluentdにfluent-plugin-zoomdataを設定して、localのZoomdataサーバに対してHTTPSでJSONをPostする仕組みです。(初keynote)\n利用しているライブラリなどのバージョンは次の通り\ntd-agent.x86_64：1.1.12-0 fluent-logger：0.2.8 Zoomdata：1.0.3 バグ？ で、Zoomdataにいろんなデータを流し込んでみたのですが、つぎのようなエラーが出て、エラーが出力されたあとはZoomdataにデータが流れ込まなくなってしまいました。\n2013-06-03 14:42:33 +0900 [warn]: emit transaction failed error=\u0026#34;SSL_connect returned=1 errno=0 state=SSLv3 read finished A: sslv3 alert handshake failure\u0026#34; 2013-06-03 14:42:33 +0900 [warn]: /usr/lib64/fluent/ruby/lib/ruby/1.9.1/net/http.rb:799:in `connect\u0026#39; 2013-06-03 14:42:33 +0900 [warn]: /usr/lib64/fluent/ruby/lib/ruby/1.9.1/net/http.rb:799:in `block in connect\u0026#39; 2013-06-03 14:42:33 +0900 [warn]: /usr/lib64/fluent/ruby/lib/ruby/1.9.1/timeout.rb:54:in `timeout\u0026#39; 全ログはこちら。\nまだきちんと問題を調査しないでブログを書いています、すみません。\n現象 ログが発生した時の症状です。\nクライアントプログラムは送信が続いており、エラーは出ない td-agent.logに先ほどのエラーが出力 別途type fileにて出力しているログも停止 想像 とりあえず、ログを見た想像、所感です。\n問題の箇所はfluent-plugin-zoomdataからZoomdataサーバへのデータ送信部分 emit処理内部で、HTTPSでデータをPOSTする処理でエラーが起きて リトライ処理とか書いてないので、emitがコケて、その後データが送信されなくなる emitで例外をつかみそこねてるのがあるから止まってる？ とまぁ、ちゃんと仕組みを理解しないでRubyとか書くからこうなるんですねぇ。 あとでちゃんと調べて考えて、改良してブログ書きます。\n悩んでいる点、今後手を入れたい点 上記バグとは別に作りの点でいくつか悩んでる点も書いてみます。\nBufferedOutputにしてみたい fluentdのバッファリングを使って、Zoomdataが落ちていても使えるようにしたいと思っているのでBufferedOutputで書くのがいいのかなぁとか。 ちょうどいいスライドがあったので、読みながらまずは中身を理解してみよう。\nZoomdataのsource、userなどの扱い 基本的には設定ファイルで切り替えるのが妥当かなぁと思っています。\nただ、Zoomdataのsourceやuserが増えるたびにfluentdの設定を書き換えて再起動するのかなぁと。userはしょうが無いにしても、sourceは設定じゃない所で切り替えたいなぁと。\nで、切り替えるのにつぎの案があるかなぁと。\nタグで指定（今実装してるもの） メッセージにメタ情報とボディ構造を設ける 設定をどんどん増やす（やりたくない） 1と3はまぁ、いいかと。2.のパターンはどうなのかなぁと。 毎回のメッセージでヘッダ部分が送信されるのはなんだか無駄だなぁというのが否めないので悩ましいところです。1、2の両方対応できるように作るのもありか。\n{ \u0026#34;header\u0026#34;: { \u0026#34;source\u0026#34;: \u0026#34;source_name\u0026#34;, \u0026#34;user\u0026#34;: \u0026#34;userid\u0026#34;, \u0026#34;password\u0026#34;: \u0026#34;userid\u0026#34;, }, \u0026#34;body\u0026#34;: { \u0026#34;label\u0026#34;: \u0026#34;label1\u0026#34;, \u0026#34;count\u0026#34;: 1 } } ということで、fluent触って遊ぶの楽しいですね。Rubyの勉強にもなりそうだし。 ちょっとずつ頑張ってみようかなぁと。 まぁ、まだ私以外にニーズは無さそうなプラグインですが。\n","date":1370234580,"dir":"post/2013/","id":"494557db52824555864d1106278cd1f0","lang":"ja","lastmod":1370234580,"permalink":"https://blog.johtani.info/blog/2013/06/03/fluent-plugin-zoomdata-0-0-1/","publishdate":"2013-06-03T13:43:00+09:00","summary":"憧れ？のfluentを使ってみました。 こちらの記事で紹介したZoomdataを最近触っているのですが、お試しにfluentdでデータ流し込む","tags":["Zoomdata","fluentd"],"title":"fluent-plugin-zoomdata作りました＋悩み事とか"},{"contents":"最近、Markdownで文章を書くのに慣れてきました。 ということで、ブログをMarkdownで書けないかなぁと思い、TLの人たちのブログを見たりしていると 「Octopress」というキーワードがあるじゃないですか。 ということで、Github Pages作って、Octopressを使ってブログを書いてみました。 こちらです。\n独自ドメインは昨年から使っているものがあったので、ついでに独自ドメインの設定もしてみました。 ケチなので、.comなどではなく、.infoですが。。。\nということで、徐々にOctopressに移行していこうと考えているところです。 こちらのブログも当面は残しておく予定です。（有料会員は解約して、広告が出る形になると思いますが。。。）\nOctopressでこんなの便利だよとかアレば教えてもらえると助かります。\n","date":1370228038,"dir":"post/2013/","id":"16f10764f0ccce42d5be8cfeac36b446","lang":"ja","lastmod":1370228038,"permalink":"https://blog.johtani.info/blog/2013/06/03/octopress%E3%82%92%E8%A9%A6%E3%81%97%E4%B8%AD/","publishdate":"2013-06-03T11:53:58+09:00","summary":"最近、Markdownで文章を書くのに慣れてきました。 ということで、ブログをMarkdownで書けないかなぁと思い、TLの人たちのブログを見","tags":["misc"],"title":"Octopressを試し中(Jugemより移植)"},{"contents":"昨年から、ブログをどうしようかって話をしていて、そのままになっていたのですが、Octopress＋Github Pagesというのがあるらしいと聞きつけて（Twitterで見かけたのかなぁ？）ちょっとやってみました。\n最近は、ドキュメントをMarkdownで記述しようとして癖をつけているのもあり、 ちょうどいい練習になるかなぁと。\nということで、まずは手始めのエントリーでした。 いくつか書きたいこともあるので、調べながら書いていこうかと。 まだ、イメージできてないこと\n画像をどうやって貼るの？ About meみたいなのも貼り付けたい bitbucketやTwitterのリンクとかも アフィリエイトも貼る（とりあえずSolr本を） 検索とかは？ デザインは？ などなど。ちょっとずつ調べていこうかなぁと。 あ、調べたことも書いてくのもありか。\n","date":1370098620,"dir":"post/2013/","id":"dbcc4002c15afefef853a08a0804ba3a","lang":"ja","lastmod":1370098620,"permalink":"https://blog.johtani.info/blog/2013/06/01/first-octopress/","publishdate":"2013-06-01T23:57:00+09:00","summary":"昨年から、ブログをどうしようかって話をしていて、そのままになっていたのですが、Octopress＋Github Pagesというのがあるらしい","tags":["octopress","misc"],"title":"Octopress始めました"},{"contents":"Lucene/Solr 4.3.0がリリースされた（LuceneのChanges、SolrのChanges）ので、lucene-gosen 4.3.0をリリースしました。（ダウンロードはこちら） なお、lucene-gosen 4.3.0ですが、Lucene/Solr 4.2.1以下のバージョンのLucene/Solrでは利用できません。 注意してください。 また、lucene-gosen 4.2.1もLucene/Solr 4.3.0では動作しませんので注意が必要です。\n現時点（2013/05/06）では、lucene-gosen 4.3.0はLucene/Solr 4.3.0でのみ利用できます。 これは、先日のエントリにも書きましたが、LuceneにてAPIの変更が行われたためとなります。 いくつかのクラスおよびメソッドが廃止されたため、下位互換が保てない変更が入っているためです。\n独自のTokenizerやTokenizerFactory、TokenFilterFactory、CharFilterFactoryを作成されている方は、Lucene/Solrのバージョンアップを行う際は注意が必要です。\n","date":1367850324,"dir":"post/2013/","id":"11d4726484be418849e1f4200ade9535","lang":"ja","lastmod":1367850324,"permalink":"https://blog.johtani.info/blog/2013/05/06/lucene-gosen4-3-0%E3%82%92%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Flucene-solr4-3-0%E4%BB%A5%E4%B8%8A%E3%81%A7%E3%81%AE%E5%88%A9%E7%94%A8%E3%81%8C%E5%8F%AF%E8%83%BD%E3%81%A7%E3%81%99/","publishdate":"2013-05-06T23:25:24+09:00","summary":"Lucene/Solr 4.3.0がリリースされた（LuceneのChanges、SolrのChanges）ので、lucene-gosen 4.3.0をリリースしま","tags":["lucene-gosen"],"title":"lucene-gosen4.3.0をリリースしました。（Lucene/Solr4.3.0以上での利用が可能です）(Jugemより移植)"},{"contents":" アジャイルな時間管理術 ポモドーロテクニック入門 ポモドーロテクニック入門という本を読みました。 きっかけは、Twitter上で何度か「ポモドーロ」という単語を何度か見ていたためです。 最初は、なんだろう？というのが発端です。 「ポモドーロ＝トマト」なのですが、実際にはトマト型のキッチンタイマーが元になっているらしいです。 このタイマーを使った時間（タスク）管理術がポモドーロ・テクニックです。\n私は、ここ数年、複数の仕事がパラで走ることが時々ありました。 このような場合に、日によって異なる複数のタスクが存在します。 このとき、異なるタスクにスイッチするのに結構な時間を取られます。。。 また、急な割り込みが入った時も同様に、以前のタスクに戻るのになにしてたっけ？となることが多々あります。 普通に自己管理ができている方なら問題ないのでしょうが、私は結構ニガテでした。 そのようなときに、Twitter上で「ポモドーロ」という単語を見かけて、軽くググってみたところ、 タスク管理、時間管理によさそうな本だったので、その点を矯正するのも兼ねて、読んだ次第です。 また、タスクに集中できるという利点もあるそうです。\n本については、少し読みにくいところがありました。 ポモドーロテクニックとはどんなものかという全体像や単語に関する説明がないままに、話が進んでいくので。。。 1度読み終わったあとに実践しながらパラパラめくっているような状況です。 実際には、個々人のやり方などを考慮しながら、改善していくべきなのもあり、型を説明してないのかもしれないですが、もうすこし概観がわかる感じのほうが良かったです。\nで、4月初旬くらいから実践してみています。 効果が実際にあるかというと、まだわからないです。\n私がポモドーロテクニックに利用しているのはキッチンタイマーではなく、pomodairoというAdobeAIR上で動くアプリになります。 ほかにもPomodoroAppというのもあるのですが、Free版だと登録できるタスクの上限があったので、pomodairoを選びました。（今見たら、3.0にバージョンが上がって、Limitがなくなってるかも） AIRだと、WinでもMacでも動作するのというも決定した要因です。\nまだ、1ヶ月経ってませんが、私が実践してきて良かった点、できてない点、うまくいってない点はつぎのような感じです。\n良かった点 目の前のタスクに集中できる。（25分スパンなので、Twitterを意識的に見なくできる。。。） 適度な休憩が挟める。25分に5分の休憩が入るので、適度な没頭になる（没頭し過ぎない） 自宅で作業するときにかなり有効。（5分の休憩時にTwitterやFB以外に漫画をパラパラ読んだりもできるので） ということで、自宅で作業するときには結構いいです。 自宅ですと、pomodairoを使っていてタイマーの音を気兼ねなく出せるので、きちんとポモドーロが回せます。\nできてない点 アクティビティ在庫管理。個人的にJIRAを使っていて、そこで管理しようと思っているのですが、うまくできてないです。pomodairoのアプリにもタスクを登録しているのもあり2重登録などを手間に思ってしまって。。。 レコーディングと今日のTodo作成。 インタラプトの記録 アクティビティ在庫管理ができてないのは、レコーディングがきちんと出来てないためでしょう。。。 二重管理になっている＋pomodairoで統計情報が出るが、当日分の統計情報がレコーディングできてないというのが痛いです。 また、このレコーディングが出来てないので、効果が出ているかがわからないという問題かと。。。 きりが悪かったりして、どうしても、仕事時間ギリギリまでタスクをこなしてしまい、レコーディング＋アクティビティ在庫の管理の時間が取れていません。 ここは意識してちゃんとやらないと意味がないよなぁと。今後の大きな課題です。\nうまくいってない点 できてない（やろうとしてできてない）点とは別に、どうもしっくり来ていないのがつぎのような点です。\nプログラミングしていると、25分のタイマーで区切りがすごく悪い時がおおい 自宅以外でのタイマー音が出せない 自宅以外での休憩の取り方 プログラミングをやっていて、乗ってきたタイミングでタイマーが鳴ってしまったり、 ちょっと頭のなかで整理していたあとの今まさに、頭のなかにある処理の流れをコードに落としている途中でタイマーがなってしまったり。 このような状況だと、休憩に入れなくて、ずるずるとコーディングを続けてしまうということが多々あります。 メモ（ソース上のコメントや手元）を残して休憩すればいいのでしょうが、どうしても今までの癖もありズルズルとやってしまい、すごく時間が経ってることが何度もあります。 ポモドーロテクニック的にはやはりNGなんでしょうが、なかなか治らない＋治したくない気もしています。 また、自宅以外の場合、基本的には自社ではなく客先に出ていることが多いのでどうしても音を出すことができません。 これもまた、切り替えができない要因になっています。 タイマーだけ携帯のアプリを使用しするという手もあるのでしょうが、この場合さらにレコーディングが出来ない状況に陥りそうで。。。 また、スマホだと電池が持たないのも問題点です。（Twitterを見るのに利用してるから電池が持たないという話もあるのですが。。。） レコーディングに関しては、手描きのメモを使うのがいいのかなぁと。本では＋や◎などの印を付けるだけにしておけば良いとありますが、アプリのタイマーだと自動でそれができるので、悩みどころです。 最後の休憩の取り方も、ネットやTwitterを見るのもありなのですが、画面から離れる休憩を取りたいなぁと思うところもあり。。。 職場だと技術書やWEB+DBのような雑誌はあるのですが、休憩にはあまり向いていないなぁと。\nつらつらと書いて来ましたが、本を読んで、1ヶ月実践してきた（できてないとこも多いが）現状をメモしておきます。 こうやってるよ、こうしたら良かったよ、こうしてみれば？などありましたら、コメントいただけると助かります。\n来週以降はとりあえず、JIRAできちんとアクティビティ在庫管理をしながら、1日の結果をレコーディングしていくのを意識していこうと思います。\n","date":1367592139,"dir":"post/2013/","id":"db97311c24809f103575d8a7fee19680","lang":"ja","lastmod":1367592139,"permalink":"https://blog.johtani.info/blog/2013/05/03/%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E5%9B%9E%E3%81%97%E3%81%A6%E3%81%BE%E3%81%99%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF%E5%85%A5%E9%96%80%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2013-05-03T23:42:19+09:00","summary":"アジャイルな時間管理術 ポモドーロテクニック入門 ポモドーロテクニック入門という本を読みました。 きっかけは、Twitter上で何度か「ポモドーロ","tags":["読書"],"title":"ポモドーロ回してます。（ポモドーロテクニック入門読みました）(Jugemより移植)"},{"contents":"まだ、Vote公開されていない、Solr 4.3（2013/04/25 11:00現在）ですが、 ひさびさに訳してみた。詳細まで追っていないので、誤訳があるかもしれないですが。 おかしいとこあったらツッコミを。\n○Solr 4.3.0のChanges ・Upgrading from Solr 4.2.0 1.schema REST APIのcopyFields、dynamicFieldsの出力パスをCamelCaseに。他も同様。（SOLR-4623） 2.Slf4j/logging jarをSolrのwarに含めないことに。すべてのlogging jarはexample/lib/extに。（SOLR-3706、SOLR-4651） 3.SolrCloudでハードコードされてたhostContextとhostPortをdeprecatedに。Solr5.0で削除する。（SOLR-4622）\n・New Features 1.SOLR-4648　PreAnalyzedUpdateProcessorFactoryでPreAnalyzedFieldの機能をほかのフィールドタイプでも使えるようにした。詳しくはJavadocとexampleを見て。 2.SOLR-4623　REST APIで現在のschemaのエレメントをすべて読めるように。REST APIの返却の形式として、XMLとJSONとschema.xmlの形式を追加REST APIのパッケージを変更。 クラス名も変更しschemaにフォーカスした機能も除去。今後のschema以外のREST APIのために。 copyFieldsとdynamicFieldsの出力パスをすべてlowercaseのものからCamelCaseに変更。他のREST APIも同様。 3.SOLR-4658　REST APIリクエストでschemaを変更できるようにするために、「managed schema」を導入。solrconfig.xmlに「\u0026lt;schemaFactory class=\u0026ldquo;ManagedSchemaFactory\u0026rdquo; mutable=\u0026ldquo;true\u0026rdquo;/\u0026gt;」を追加。REST APIリクエストでスキーマ変更が可能にするために。 4.SOLR-4656　2つのハイライトパラメータ（hl.maxMultiValuedToMatch、hl.maxMultiValuedToExamine）を追加。 hl.maxMultiValuedToMatchは指定された数のsnippetが見つかったらそれ以降の探索を停止する設定。multiValuedフィールドがどんなに離れてても探索する。 hl.maxMultiValuedToExamineは指定された数のmultiValuedのエントリ数を調査したら探索を停止する設定。 両方を指定した場合、最初のlimitに達したら停止する。ドキュメント全体をハイライトするためにコピーされるのを削減する。これらの最適化はmultiValuedフィールドに大量のエントリが存在する時に効く。。。 5.SOLR-4675　PostingsSolrHighlighterでper-field/クエリ次のパラメータ指定のサポート 6.SOLR-3755　既存のshardを動的にsplitしてshardを追加するための新コレクションAPI（shard splitting） 7.SOLR-4530　DIH：TikaのIdentityHtmlMapperを使う設定の提供 8.SOLR-4662　solr.xmlにあるSolrCoreの定義よりもディレクトリ構造で見つける。また、solr.xmlのフォーマットを変えて、solrconfig.xmlに近くする。Solrのこのバージョンは旧スタイルの例で提供するが、新しいスタイルも試すことができる。Solr 4.4では、新しいスタイルで提供し、Solr 5.0では旧スタイルは廃止する予定。 SOLR-4347　Adminハンドラで新しく生成されたコアがsolr.xmlに永続化される SOLR-1905　Adminリクエストハンドラで生成されたコアもsolr.xmlに永続化される。また、solr.solr.datadirのようなプロパティの用にsolr.xmlに永続化される問題のfix。 9.SOLR-4717/SOLR-1351　SimpleFacetで同じフィールドに異なるファセットを適用出来るlocalParamsを追加 10.SOLR-4671　CSVResponseWriterのpseudoフィールドのサポート 11.SOLR-4358　HttpSolrServerでuseMultiPartPostでstream名を送信できる ・Bug Fixes 1.SOLR-4543：solr.xml/solr.propertiesでshardHandlerFactoryの設定が動作しない 2.SOLR-4634：Java 8\u0026quot;Nashorn\u0026quot;JavaScript実装の動作に関するscripting engineのテストのfix 3.SOLR-4636：SolrIndexSearcherをオープンする時に何かの理由でreaderがオープンできない時に、ディレクトリがリリースされない 4.SOLR-4405：Admin UIのadmin-extraファイルでcore-menuが表示されない 5.SOLR-3956：group.facet=trueでfacet.limitがマイナスの時の動作 6.SOLR-4650：copyFieldでダイナミックフィールドや暗黙的なフィールドがsourceでマッチしない。4.2で入ったバグ 7.SOLR-4641：Schemaで、illegalなフィールドパラメータで例外が発生するようにする。 8.SOLR-3758：SpellCheckComponentが分散groupingで動作しない。 9.SOLR-4652：solr.xmlプラグインのresource loaderで共有ライブラリの挙動がおかしい 10.SOLR-4664：ZkStateReaderがaliasを更新しても見えない 11.SOLR-4682：CoreAdminRequest.mergeIndexが複数コアやindexDirが複数の場合にマージできない 12.SOLR-4581：Solr4.2で数値フィールドのファセットでマイナスの値があるとソートがおかしい 13.SOLR-4699：Admin Handlerでデータディレクトリの場所がファイルシステムだと思い込んでる。（RAMの場合もある） 14.SOLR-4695：non-cloudセットアップでもコア管理のSPLITが使えるように 15.SOLR-4680：exampleのspellcheck設定のqueryAnalyzerFieldTypeの修正 16.SOLR-4702：exampleの/browseの「Did you mean?」のサジェストをFix 17.SOLR-4710：Zookeeperから全ノードをアップせずにコレクションを削除できないのを修正 18.SOLR-4487：HttpSolrServerからのSolrExceptionがリモートのサーバから戻るHTTPステータスコードを含んでない 19.SOLR-4661：Admin UIのレプリケーションで現在のレプリカ可能なマスタのバージョンを正確に表示 20.SOLR-4716,SOLR-4584：SolrCloudリクエストプロキシがTomcatなどJetty出ないコンテナで動作していない 21.SOLR-4746：Distributed groupingのトップレベルグループコマンドでSimpleOrderedMapの代わりにNamedListを使う。non-distributed groupingと出力形式が異なるため。 ","date":1366856040,"dir":"post/2013/","id":"286a9a4ee373398d7d2c93862c5f6661","lang":"ja","lastmod":1366856040,"permalink":"https://blog.johtani.info/blog/2013/04/25/solr4-3-0%E3%81%AEchanges%E3%82%92%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/","publishdate":"2013-04-25T11:14:00+09:00","summary":"まだ、Vote公開されていない、Solr 4.3（2013/04/25 11:00現在）ですが、 ひさびさに訳してみた。詳細まで追っていないので、","tags":["solr"],"title":"Solr4.3.0のChangesを訳してみた。(Jugemより移植)"},{"contents":"現在、RC3のVoteをやっている最中（2013/04/24　16:00時点）で、まだリリースされていない、4.3.0についてです。 開発者MLでChangesの書き方を考えないとね、みたいなエントリーが流れてて気になっていたので、訳してみた。 lucene-gosenの実装を変更しないといけないっぽいなぁ。Lucene/Solr 4.2.1以前と4.3.0でI/Fとかが変わることになりそうです。（3.とか8.とか） （ここで力尽きて、それより下はまだ読んでないです。。。）\n○Changes in backwards compatibility policy 1.LUCENE-4810：EdgeNGramTokenFilterが同じ入力tokenから複数のngramを生成した時にpositionを増加させていないのを修正 2.LUCENE-4822：KeywordMarkerFilterがabstractクラスで、サブクラスがisKeyword()メソッドを実装する必要がある。新しく、SetKeywordTokenFilterというクラスにすでにある機能を分解した。 3.LUCENE-4642：TokenizerとサブクラスのAttributeSourceのコンストラクタを削除。代わりにAttributeFactoryをもつコンストラクタを追加。 4.LUCENE-4833：IndexWriterConfigがsetMergePolicy(null)の時にLogByteSizeMergePolicyを使っているのをデフォルトmerge policyをTieredMergePolicyに。また、nullが引数に渡されたらExceptionを返す。 5.LUCENE-4849：ParallelTaxonomyArraysをDirectoryTaxonomyWriter/Readerのためのabstractとして作成。あと、o.a.l.facet.taxonomyに移動。 6.LUCENE-4876：IndexDeletionPolicyをInterfaceではなく、abstractクラスに。IndexDeletionPolicy、MergeScheduler、InfoStreamでCloneableをimplement。 7.LUCENE-4874：FilterAtomicReaderと関連するクラス（FilterTerms、FilterDocsEnumなど）でフィルタされたインスタンスをforwardしないように。メソッドが他のabstractメソッドを実装している場合に。（？） 8.LUCENE-4642, LUCENE-4877：TokenizerFactory、TokenFilterFactory、CharFilterFactoryの実装者は、少なくともMap\u0026lt;String,String\u0026gt;（SPIフレームワーク（Solrとか）によってロードされる）を引数にするコンストラクタを提供する必要がある。さらに、TokenizerFactoryはcreate(AttributeFactory,Reader)メソッドを実装する必要もある。\n","date":1366786800,"dir":"post/2013/","id":"99f5219da22485d0872a2529599c8440","lang":"ja","lastmod":1366786800,"permalink":"https://blog.johtani.info/blog/2013/04/24/lucene-4-3-0%E3%81%AEchanges%E3%81%AB%E3%81%82%E3%82%8Bchanges-in-backwards-compatibility-policy%E3%81%8C%E6%B0%97%E3%81%AB%E3%81%AA%E3%81%A3%E3%81%9F%E3%81%AE%E3%81%A7%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/","publishdate":"2013-04-24T16:00:00+09:00","summary":"現在、RC3のVoteをやっている最中（2013/04/24 16:00時点）で、まだリリースされていない、4.3.0についてです。 開発者ML","tags":["solr"],"title":"Lucene 4.3.0のChangesにあるChanges in backwards compatibility policyが気になったので訳してみた。(Jugemより移植)"},{"contents":"第2回目も参加しました。 とりあえずメモ。 自分には欠けてる視点の話しなので面白かった。 ちょっと寒かったなぁ。\nエンジニアのためのスキルアップ勉強会『Tech Compass』 #tecomp ― Vol.2 「人気Webサービスの作り方教えます！」 ― 日時：2013/04/23 19:00 場所：パレスサイドビル9F マイナビルーム ◎自己紹介 ●株式会社Zaim／閑歳孝子 小学校3年からFMVで草の根チャットとかにつないでた。（すげー） これがいい記事ですよ。http://www.1101.com/umeda_iwata/ テレビとかで紹介されてるZaimやってます。 3つの基準　・日常的に使うもの ・普通の人が使うもの ・少なくとも自分は使うもの サービスの良さの基準 縦軸：影響の深さ 横軸：影響する人数 この面積が大きいのがいいんでは。 ●株式会社ワディット／和田裕介 いろいろ作ってます「カウントダウンチューブ」とか「君のラジオ」とか30～40くらい作ってます。 ・「ボケて」ってのやってます。 600万ボケ。アプリ120万DL　僕らがつくるための５Wについて ・なぜ？ ・サービスの根本となる「哲学」をみんなで共有できるかが重要 ・内向けのビジョンも大事 ・何を？ ・ユースケースで整理する ・いつ？ ・つくろう！すぐ作れるようにしようねって感じ ・誰と？ ・最強のチーム。意思決定がはやい。 自分主体でサービス設計して、作りなおすのをためらわない ◎ディスカッション Q：どうしてサービス作ったの？ A：エンジニアへのあこがれから、サービスを作った（閑歳さん） ものづくりという意味では、Webサービス以外もあるけど？（馬場さん） 学内のSNSのようなものを作ってて、アクセスが伸びるのが面白かった。（閑歳さん） 大学でlastfmみたいなものを研究してて。。。（和田さん） 社会に出てサービスを作るまでの話は？作って稼ごうって思ったのは？（馬場さん） あんまりなかった。（閑歳さん） すでに起業してた。サービス作ると実績として認められて仕事が入ってきてた。（和田さん） 直接あった時に反応がもらえるのが楽しい。（和田さん） Q：どうやって、チームを組み立てたりして開発とかしてきたのか？（馬場さん） A：「ボケて」まとめサイトでブレイクしたけど、アクセス数が落ちてない。 同年代の知人で色々とチームが組めてて楽しい（和田さん） はじめは一人でやってて、しかも構想とか。あとロゴだけ最初に作ってた。 ノマド的に作業してました。（閑歳さん） Q：チームがバラバラですが、困らないですか？ A：今のところ困ってないです。もっと人が増えると困るかもしれないですけど。（閑歳さん） それぞれが他に職を持ってるので特に困ってないです（和田さん） 向き不向きはあるんじゃないかなぁ。10人とかになるとどうなるか不明（閑歳さん） GoogleのMLでレスが早ければ問題ないかな。（和田さん） あとは、チームが大きくならないように上手く分割してる（？）（ふたりとも） Q：ユーザの声の吸い上げ方、サービス改善の判断材料は？ A：ユーザの声は聞くけど、全部取り込むものではない。 細かな点はユーザの声を取り込むけど、軸はブレないようにしてる（閑歳さん） 古参ユーザよりも新しいユーザを取り込むのが大事。（和田さん） nanapiのけんすうさん Q：品質はどうしてる？ A：セキュリティは絶対。（閑歳さん） 品質を気にするってのは難しい。品質を担保できる仕組みを作るとこまでいけるようにしたい。 投稿される画像はチェックしている。（和田さん） ","date":1366717542,"dir":"post/2013/","id":"36ff37ced0d3211db95a5ac0daac0c35","lang":"ja","lastmod":1366717542,"permalink":"https://blog.johtani.info/blog/2013/04/23/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass--tecomp--vol-2-%E4%BA%BA%E6%B0%97web%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9%E6%95%99%E3%81%88%E3%81%BE%E3%81%99%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2013-04-23T20:45:42+09:00","summary":"第2回目も参加しました。 とりあえずメモ。 自分には欠けてる視点の話しなので面白かった。 ちょっと寒かったなぁ。 エンジニアのためのスキルアップ勉強","tags":["勉強会"],"title":"エンジニアのためのスキルアップ勉強会『Tech Compass』 #tecomp ― Vol.2 「人気Webサービスの作り方教えます！」に参加しました。(Jugemより移植)"},{"contents":"だいぶ、ブログを書くペースが落ちてきてて、危機感を感じている今日このごろです。。。 今回は、個人的に利用しているJIRAのバックアップについて、ブログに残しておこうかと。\nさくらVPSのサーバを借りてJIRAを運用しています。 運用といっても、自分の備忘録のためというのが大半の理由です。 タスクを忘れないように管理するのと合わせて、その作業を行ったときのメモも残したいなと。\nバックアップといっても、同じサーバ内に保存しても意味がない＋AWSを触ると言いつつ1年以上経ってしまったので、 このへんで本腰を入れるという意味も込めてAWSのS3（ゆくゆくはGlacier）にバックアップを取る仕組みを作りました。 「作りました」というと凄そうですが、Cronとシェルだけで終わりました、なんて便利な世の中。 ということで、以下は作業の備忘録です。\n1.AWSのアカウント作成 アカウントを作ってください。ここは特に説明しなくてもいいかと。。。クレジットカードの登録が必要なのが注意点でしょうか。 アカウント作成後の1年間は無料枠と呼ばれる仕組みが用意されており、いろんなことが無料で行えます。 （まだ、S3しか使ってないので、他にももっと使わないと。。。）\n2.S3のバケット作成 AWSのアカウントが作成できたら、Amazon S3（Simple Storage Service）のバケットと呼ばれる、データの保存先を作成します。 作成手順はこちらの公式入門ドキュメント（英語）をそのまま行いました。 簡単な手順はこちら\nAWS Management Consoleと呼ばれるところから、S3のコンソールにアクセス 「Create Bucket」ボタンをクリック 「Bucket Name」を入力し、リージョンを選択したら「Create」ボタンをクリック 以上でバケットが作成されました。これだけです。WebのConsoleからファイルをアップロードすることも可能です。 ただ、今回はさくらVPSから定期的にバックアップしたいのでシェルでアクセスできるようにします。\n3.AWSのアクセスキーとシークレットアクセスキーの取得 次に紹介するs3cmdというツールを利用するのに、AWSのアクセスキーとシークレットキーが必要になります。 取得方法はこちらを参考にしましたが、今は日本語のページが用意されています。 セキュリティ証明書（Security Credentials）のページで、「アクセス証明書」というタブで、「新しいアクセスキーを作成する」リンクをクリックしてください。 アクセスキーIDが新しく表示されます。このアクセスキーIDとシークレットアクセスキー（表示リンククリック後に表示される）をメモしておきます。\n4.s3cmdのインストール 世の中には便利なものを作ってくれる方がいるもので。 s3cmdと呼ばれるS3へアクセスできるコマンドラインツールが存在します。 ということで、こちらをインストール。これまた、便利なものでインストール手順を書いてくれれてるブログもありました。（あれ、なんか、見たことある名前がURLにはいってるなぁ） インストールはこちら。\n# yum -y --enablerepo epel install s3cmd インストール後に、先ほど取得したアクセスキーIDを設定します。\n$ s3cmd --configure Access Key: xxxx Secret Key: xxxx 以上で、s3cmdが使えるようになりました。\n5.バックアップスクリプトの作成 つぎは、本題のJIRAのバックアップです。 バックアップ方法はこちらを参考にしました。ちょっと古いみたいですが。 おもなデータは「JIRAのXMLバックアップユーティリティ」にてバックアップするか、「データベースのバックアップツール」を利用する方法があります。 推奨は「データベースのバックアップツール」のようなので、私の場合は「pg_dump」にてJIRAのデータベースをまるごとバックアップすることにしています。 また、データベースには添付ファイルが保存されていないようなので、別途「/var/atlassian/application-data/jira/data」というディレクトリをtarコマンドで圧縮して保存すようにしました。 あとは、pg_dumpの結果と添付ファイルの保存先の圧縮したデータをまとめてディレクトリに保存して圧縮します。 さいごは、S3にアップロードすればおしまいです。 一応、ファイルが連綿と残り続けるのは嫌だなぁということで、ファイル数で世代管理することにもしました。 これまた、ググって見つけてきたサイトを参考にしただけですが。。。 ということで、こんなかんじのスクリプトを日時でcronに設定して動かしてます。\n#!/bin/sh TODAY=`date +%Y%m%d` BACKUP_HOME=\u0026#34;/var/atlassian/backups\u0026#34; S3SYNC_DIR=\u0026#34;/var/atlassian/backups/s3sync\u0026#34; AGE=7 mkdir -p ${BACKUP_HOME}/${TODAY}/ /usr/bin/pg_dump -U postgres -Fc jiradb \u0026gt; ${BACKUP_HOME}/${TODAY}/jiradb_backup.dump tar zcvf ${BACKUP_HOME}/${TODAY}/attachment.tgz /var/atlassian/application-data/jira/data tar zcvf ${S3SYNC_DIR}/jira_backup_${TODAY}.tgz ${BACKUP_HOME}/${TODAY} rm -rf ${BACKUP_HOME}/${TODAY} NUM=`ls ${S3SYNC_DIR} | wc -l` while [ ${NUM} -ge ${AGE} ] do DEL_FILE=`ls -lt ${S3SYNC_DIR} | tail -1 | awk \u0026#39;{print $9}\u0026#39;` rm -r ${S3SYNC_DIR}/${DEL_FILE} NUM=`ls ${S3SYNC_DIR} | wc -l` done s3cmd sync --delete-removed ${S3SYNC_DIR}/* s3://my_jira_backup/s3sync/ そこへんだよとかあれば、ツッコミを。 今のところ、S3へのsyncだけなので、このあとは、月1くらいでGlacierに落とすとかの仕組みも考えるかなぁ。これまた何かあるんだろうけど。 あとは、この応用で家のNASに溜まっている写真をS3経由もしくは直接Glacierにバックアップする仕組みを考える予定です。\n","date":1366639648,"dir":"post/2013/","id":"1ca04e5339ed1826c12fe61fd984e949","lang":"ja","lastmod":1366639648,"permalink":"https://blog.johtani.info/blog/2013/04/22/jira%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E3%82%92s3%E3%81%B8%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97/","publishdate":"2013-04-22T23:07:28+09:00","summary":"だいぶ、ブログを書くペースが落ちてきてて、危機感を感じている今日このごろです。。。 今回は、個人的に利用しているJIRAのバックアップについて","tags":["備忘録"],"title":"JIRAのデータをS3へバックアップ(Jugemより移植)"},{"contents":" HerokuではじめるRailsプログラミング入門 heroku気になってるのに使ってなくて、TDのアカウント作ってデータアップしてない軟弱者ですが、参加して来ました。。。 とりあえず、大事なことです。まずは、上記の書籍を買ってください（って中の人が言ってました。） イベントページはこちら。\n総じて、herokuの中のエンジニアの方たちがすごく情熱があって、ユーザと会話をしたがっているという感想だったようで、まだまだ、よくなりそうだなぁと。 私は、ベースがJavaなので、JavaやScala、Playで使ってる方の感想とか聞きたいかなぁ。 あと、herokuとS3の組み合わせだと思うんですが、料金とかはAmazonとheroku両方に別々に払うのかな？とかはちょっと気になりました。 AWSのアカウントも作ってS3にバックアップあげるの作ろうと思って手をつけてない軟弱者ですが。。。 今月は余裕がありそうなので、TDとか触ってみようと思います。。。\n懇親会ではTDのmuga-sanとお話できて、いくつか気になってた話ができたのでスッキリしました。 あと、株式会社サムライズムの名刺頂きました。写真載せろって言われたけど、また今度ｗ\n最後に、大事なことです。まずは、上記の書籍を買ってください（って中の人が言ってました。）\n以下は、いつものようなメモです。最後の方はちょっとくたばってたのでメモがおざなりになってます、すみません。\n日時：2013年04月04日(木) 18時30分 - 21時00分 場所：日本創生ビレッジ 事業開発支援オフィス 東京21cクラブ コラボレーションスペース ◯Ayumu Aizawa（Heroku, Inc.） ・■ PostgreSQLが9.2になりました。 ・◆ メモリが2倍。βテスタ向けにスケールアップ。 JavaとかJavaとかJavaとかデプロイしてもいいよね。 けど、メモリ2xは価格も2x！ ・● Heroku OAuthを提供。Experimentalだけど。 heroku-bouncer使うとOAuthが楽になる。 ◯Treasure Data and heroku Masahiro Nakagawa（TreasureData） ・会社紹介 ・フロントエンド部分の担当（fluentd） ・1500億レコード！？ ・投資家の中にHerokuの方がいる。 ・ターゲットは？ Cloud + Big Dataが対象 Hadoopは立ち上げるのはいいんだけどメンテナンスコストが。 Hadoopの処理基板を提供 ・Hadoop生ではなく、Plazmaを使っていたりする。 ・Viki herokuにtd-agent入れて、TDにデータ送って、Postgresに書き出して使ってる。 ・TDはどうやってheroku使ってるの？ Webコンソール。 http://console.treasure-data.com Webサイトは大体heroku fluentdとかも ・herokuのaddonとしてtd-agentを提供してる。 ・STDOUTからTDにデータ送るのもできるよと。 ◯Waza Report ◯吉田雄哉さん（co-meeting） ・まずは、co-meetingの紹介。 1文字ずつ送信してるよと ・Chief Talk Officerらしいｗ ・MongoDB使ってるって言ったら、herokuのPostgreSQLの人と話して、鼻で笑われたｗ ・すごく熱意のある人達がエンジニアとして働いてる ・ユーザの声をきちんと聞いてくれる体制ができてるミーティングだった。 ・「クラウド」って単語を聞いてない。勉強会のレベルもすごい。 ◯山本裕介さん（株式会社サムライズム） ・ニッチなブログ書いてます。 ・Java屋が見るWaza Tシャツプレゼント！ ・OSS好きが多い。 Java/Scala系の話が少なかった。Scala界隈では人気みたい ◯岡村純一さん（株式会社シャノン） ・スライド1枚も作らずに喋る人とかいました。 （すごい。。。） ・Django Playに似てて面白いかもと ・Ruby2.0 Matzが喋ってたとか ・クロージングはビールが出てきてた。 交流パーティみたいになってた。CROSSがそれに似てますね。日本でやってるイベント ◯小西俊司さん（株式会社フレクト） ・バックエンドの性能とかを収集して見ることができるツールがあるらしい。 ・クエリを登録しておくと監視ができるツールとか。（TDとかぶってる？） ・やっぱり、情熱的だし、OSS好きでオープンな感じのエンジニアが多い。 ◯Heroku LT 無慈悲なLTです。3分たったらケーブル引っこ抜きます。 （最後はくたばっててあまり聞けてない。。。） ◯山本 裕介（株式会社サムライズム） ・herokuでJava7！ Java6終わってますからherokuも移行してね！ ◯竹野 淳（Grow!） ・BoxTo？ ・コラボレーター募集！ ◯小西 俊司（株式会社フレクト） ・ExcelのテンプレートをアップロードしてGETでパラメータわたせばいいよみたいなの作ってる。 ◯大久保英樹（Job-Hub） ・CarrierWaveとかの注意点 ","date":1365128443,"dir":"post/2013/","id":"73d2fce4efa52675b35a11ee97bc2db0","lang":"ja","lastmod":1365128443,"permalink":"https://blog.johtani.info/blog/2013/04/05/heroku-meetup--8-treasuredata--waza-report-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/","publishdate":"2013-04-05T11:20:43+09:00","summary":"HerokuではじめるRailsプログラミング入門 heroku気になってるのに使ってなくて、TDのアカウント作ってデータアップしてない軟弱者","tags":["勉強会"],"title":"Heroku Meetup #8 TreasureData + Waza Report!! に参加しました。#herokujp(Jugemより移植)"},{"contents":"記念すべき！？第10回のSolr勉強会です。\n発表者が無事あつまり（本当にありがとうございました！）、今回も盛況な感じでほぼ満員でした。 ツイートのおかげか、キャンセル処理もちゃんと行なってもらえて助かりました。 開場直後にドタバタしてしまい、すみませんでした。。。\nとりあえず、第一報の記事をアップしておきます。 懇親会での話とか感想はまたあとで。\n関口さんの資料は実は、前もって見たことがある資料でした。 最初の発表にしては、少しむずかしいと思った方もいるかなぁと。 ただ、類義語の辞書は結構作るのが大変だし、探しても出てこないものなので、面白い話だったんではないかなぁと。 「ミスチル」はできないけど、「マツケン」ができるのは読みがあるからとかなんですかねぇ？って質問するの忘れてた。\n尾形さんの話は結構、みんな通ってきた道かもなぁと思いました。他の方も同じ経験してるんじゃないかなぁと。 ただ、一人でやるのはすごいですよね。検索って結構人数が割かれてない場合が多いのかなぁ。 あんまり使われていないというのが少し悲しい話でしたが。。。 サーバを要求すれば結構なスペックが用意してもらえるのはうらやましい限りですねぇ。 スキーマ変更については、レプリケーション機能を使うと追加などならうまくいくんじゃないでしょうか。（そんなツイートもありましたよ。togetter読み返すと出てきます。） フィールド名を変更しないで型を変更するなどしたらおかしくなると思いますが。\n野口さんの話はなかなかチャレンジングでいいなぁと思いました。よく挫けずに頑張られているなぁとｗ 試行錯誤した仮定も発表してもらえると同じ轍を踏んだ人が助かると思います。 大きな企業で本格的に横断的な社内検索が出来る仕組みが出来上がっているって話はなかなかきかないかなと。 どうしても、社内検索とかお金が出なくて手を付けられないといいう悲しい話が多いので、こういう話は共有したい情シスの方がいっぱいいるんじゃないかなぁと。 ManifoldCFが結構地雷を多く含んでいるのは大変そうですね。。。 SolrにもTikaが入っていたりしますが、個人的にはTikaがやるべき処理は前処理と思っているので、Solrとは別の場所でやりたいとか考えていたりします。 ManifoldCFがその辺りまでやってくれるかまではちゃんと調べてないんですが。 Solrは検索だけに注力させることで、役割を分割できるので、性能の対処とかを行うのが楽になるんじゃないかなぁとか。 ManifoldCFで困ってる人は他にもいるようなので、ジャンジャン使って、どんどんチケット上げて貢献してもらうといいかと。 また、定期的に発表してもらうと面白そうだなぁと。\n弘瀬さんの話は結構興味ある方がいたんじゃないかなと。 SolrCloudは壮大だなぁと思いつつ、手を出しづらいと思ってる方が多いと思います。 実際のサービスに投入して試行錯誤された話を細かな数値も上げて発表してもらえるのは検証をやる方の助けになります。 残念ながら、私もSolrCloudは興味有りつつちゃんと追っかけてないので、途中でnodeとshardとcoreの関係がわからなくなってしまいましたので。。。 もう一度勉強して、スライドを見たいと思います。。。 分散検索（1つのインデックスが複数のcoreやshardに分割された状態）が絡んでくると、複数台の検索の性能のうち、一番遅い性能が最終的な検索性能に響いてくるので、検索リクエストの偏りとかも影響が出たりするかもしれないなぁと。 そういった意味でも試行回数を3以上で計測した結果で再度発表してもらうと面白そう！（なんか、下心見え見えですがｗ）\n前回、今回も感じたのですが、もう少し質問をしてもらえると発表された方も励みになるかなぁと思いました。 質問しにくい雰囲気になってるのでしょうか？参加者が結構いるから質問しにくく感じたりするのでしょうか？ そのあたりをもう少しうまくやれるようになにかコメントもらえると嬉しいかなぁと。 運営で気になった点などもコメントやツイートをいただけると今後の改善にも役立てますので気兼ねなく連絡いただけると助かります。 開場がドタバタしすぎとか、ハッシュタグがわからなかったとか。\n今回は思ったよりも懇親会に残る方が少なめでした。 コミッターの方（LuceneやManifoldCFとかlucene-gosenとか）が複数いたり、Solrを結構触ってる方がいたりと面白い話が聞けそうだったのですが。。。 Kuromojiのユーザ辞書の改良点をチケットにあげるって約束したのでやらないとなぁ。 早く帰るつもりだったのに気づいたら23時でしたwやっぱり色々と話ができるのが楽しくて。。。 駅前の機動隊とかびっくりしながら帰りました。 今回、お話ができなかった方もいらっしゃるかと思いますが、気兼ねなく、ツイートしてもらったり、声をかけていただければと。\nあと、常に発表していただける方は歓迎しておりますので、連絡いただけると非常に助かります！ こんな話が聞きたいなどでもいいかと思いますので、連絡いただければと。\n#SolrJPもtogetterにまとめてもらいました。ありがとうございます。 以下は、いつものメモになります。\n日時：2013/03/26 19:00 to 21:00 場所：VOYAGE GROUP 会議室 1. 株式会社 ロンウイット　関口　宏司さん タイトル：Wikipediaからの類義語知識の自動獲得について 発表資料はこちら\n・「辞書型コーパス」という単語は造語かもしれません。 ・なんでこんなことを？ →類義語辞書を自動生成したいから。 ・自賠責保険、自動車賠償責任保険を例にSynonymFilterの説明。 ・Wikipediaを入力として、類義語辞書を作成するときにLuceneのインデックスを活用してる。 ・類義語候補の見つけ方 いくつかヒューリスティクスな処理とかも入れてます。 日本語Wikipedia固有なもの。 ・実際に導出された単語も載ってる。 FTPなども導出で来てる。 丸ビルとかも。 ・導出できなかったものもあります。 「十六進法」が「十進法」になってる 「ミスチル」も無理。 ・ミスもあるけど、類義語が存在しない場合になんとなく、使う辞書としては採用できるのでは？ 類義語検索対象のブーストを小さくするなどをすれば役に立つ Q：類似度にしきい値を用意したりしてますか？ A：min.scoreという値を用意し、足切りをしている。 Q：ベクトルを作るという話があったが、品詞でフィルタリングとかしてる？ A：名詞に限って処理してます。名詞に限らなくてもいいかも。。。（若干聴き逃しました） 重みの高いn件をベクトルの対象にしてます。 2. グリー株式会社　尾形　暢俊さん タイトル：GREEにおける全文検索の歴史 発表資料はこちら\n・GREEさん、検索はないがしろにされてる。。。 一人でつくって、一人でメンテナンスしてる。 ・GREEの検索は右上の検索ボックスが ・2007年はSennaつかってました。 Tritonnに移行。2009年くらいまで。 やっぱり安定しない＋MySQLのバージョンアップしたいけど、追従できない ・2012年初頭までLuceneでやってた。（結構古い） フラグメントが発生してOptimizeすると、検索サーバが使えなくなる。。。 検索しにくるサーバが1000台いるので、Optimizeかけるときに、1000台のサーバの設定を書き換えるとかしてた。。。 ・現在まではSolrをつかってる。 Luceneのバージョンも古かったので100倍くらい速くなった。 ・Solr本が必須ですよ！！！ ・Lucene+Tomcatから移行。 移行に気をつける点として、I/FをそのままSolrに置き換えると。 Solr返却のXMLをカスタマイズしたり、クエリをSolr向けに書き換えたり。 あと、メンテナンスが楽になるように。 40数台のインデックスサーバがあると。 一人でメンテナンスしてるから、楽になる方法が重要 ・レプリケーションで、Optimizeの影響が出ないように。 キューをつかって、マスタに登録して、スレーブにレプリカを配布 ・スキーマが7つ あんまり使われてなくてかなしい。。。 ・負荷のグラフもありました。 ・RangeQueryを結構使う。 ・作りこんだ部分 インデックスのMasterへ分散させる処理とか クエリの変換とか人力監視処理とかNGワードとか サーバ監視のための仕組み ・今でも大変なこと スキーマ変更が大変 スレーブをマスタに昇格とかが手動 ・今後改善したいこと 精度を上げたい 辞書を使ってみたいけど、各国語対応 あと、自動化とか 3. ソフトバンクBB株式会社　野口　勝義さん タイトル：企業内の大規模ファイルサーバ検索事例 ・情シスの企画版？という立場のかた。 ・売上に貢献したいのでクラウドサービスとして検索をオプションとして立ち上げてみた！ ・Solr＋ManifoldCFで作ってみたよと ・なんでSolr？ OSSだし、機能が充実 ・なんでManifoldCF？ Active Directory連携が使いたかったと。 社内検索ってやっぱりアクセス権がうるさいので。 ・ManifoldCFの説明はロンウイットさんの画像を使わせてもらいましたｗ ・ファイルサーバが、70TB。。。 ・困ったこと。 ・その１ ・クローラージョブの構成の最適化どうする？ ・マルチコアで、クローラーとファイルサーバを1対1の構成にしてみた。 ・その２ ・ファイル数が増えるとまた問題が。。。 ・ファイルサイズが大きい→Heapが足りないエラーとか、MCFのタイムアウトとか。。。 ファイルサイズのリミットを設けてみた。 mp4とかでエラーがでるとか。既知のエラーでしたとか。 ulimitがたりないとか。 MCFの稀に出るバグとか。。。 ファイルサーバの不良ブロックとか。。。 ・その３ ・クロールに時間がかかる ・MySQLでスロークエリとか MySQLよく知らないとか言われながらコミッターに対応してもらうなど。 SSDつかうとか考え中 ・フルクロールで1週間 差分でも1日強かかる。 ManifoldCFだけで対応できないから、ファイルの特徴を元に →ManifoldCFを経由しないリアルタイムインデックス更新のAPIを経由してMasterじゃなくて、更新かけると。（特定のクライアントからの方法） ・その４ ・本文データをstored=falseに けど、ハイライトできないから、どうにかしたい ・ユーザの要望 ・もしかして検索 類義語？じゃないよねぇ。テザリング、tezaringuとか フロント側で頑張った。（Solr諦めました） ・検索スコアも弄りたいとか 外部データでブーストとかもしたい。External Fieldとか使うといいのでは？とか。 4. 株式会社サイバーエージェント　弘瀬　健さん タイトル：SolrCloudの導入事例 発表資料はこちら\n・Webエンジニアだったのに、検索エンジニアに！ ・SolrCloudもサービスインしてると。 ・SolrCloud概要 4.0以降の機能とか。 ・SolrCloudの構成要素 概念的なもの。Collection、Shard 物理的なもの。Node、Core ・ Simplogってサービスに導入済み。 ZooKeeperが3台、6Shard、3nodeという形式 ・性能 平均レスポンスタイム50msec 思ったより出てないので、調べてみた。node数とかshard数を変えてみて調べてみた（まだ、模索中。） ・色々テストケース試したけど、試行回数が1回だけです。 詳細なデータが出てるのありがたい（全部はまだ理解できてないですｗ） ・検証まとめ ノード当たりのcore数が少ないほうが検索、更新性能がいい 1コレクション当たりのshard数が少ないほうが検索性能がいい ・まとめ ・SolrCloudの利点 クライアントが色々意識しなくていいのがうれしい。 ・SolrCloudの注意点 shardの分割機能がまだないので、大変。 コレクション情報が壊れると検索更新できないとか。4.0だとバグが有った ・性能的には素のSolrのほうがいいよと。 ","date":1364300160,"dir":"post/2013/","id":"26d0c0d8c465087cf160a3bdc479f2b4","lang":"ja","lastmod":1364300160,"permalink":"https://blog.johtani.info/blog/2013/03/26/%E7%AC%AC10%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/","publishdate":"2013-03-26T21:16:00+09:00","summary":"記念すべき！？第10回のSolr勉強会です。 発表者が無事あつまり（本当にありがとうございました！）、今回も盛況な感じでほぼ満員でした。 ツイー","tags":["勉強会"],"title":"第10回Solr勉強会を主催しました。#SolrJP(Jugemより移植)"},{"contents":"なんか、とても久しぶりにイベント参加メモ以外の投稿です。 elastic searchのMLを見てたら、KuromojiのAnalyzerを使うときにユーザ辞書使うのどうするの？という投稿を見かけました。\nKuromojiのユーザ辞書にもちょうど興味があったり、elasticsearchもちょっとずつ触りたかったのでちょっと試してみました。（返信もしてみましたが、テキトーな英語です。。。）\nelasticsearch-kuromoji-pluginのインストールなどはElasticSearch で kuromoji を使う (ES 0.90.Beta1 + kuromoji 1.2.0篇)を参考にしてください。 私もこちらに記述のある組み合わせ（elasticsearch-0.90.0Beta1 + elasticsearch-analysis-kuromoji/1.2.0）を利用しました。 KuromojiのAnalyzerはデフォルトで「kuromoji」として登録済みですが、こちらはユーザ辞書の指定がありません。 ということで、「kuromoji_user_dict」というユーザ辞書指定をしたtokenizerと、それと使う「my_analyzer」というanalyzerを登録したIndexを作成します。 定義する前に、「userdict_ja.txt」を用意して、elasticsearch-0.90.0Beta1/config/ディレクトリに配置しておきます。 （以下のサンプルでは、SOLE_HOME/example/solr/collection1/conf/lang/userdict_ja.txtをコピーして使いました）\n$ curl -XPUT \u0026#39;http://localhost:9200/kuromoji_sample/\u0026#39; -d\u0026#39; { \u0026#34;index\u0026#34;:{ \u0026#34;analysis\u0026#34;:{ \u0026#34;tokenizer\u0026#34; : { \u0026#34;kuromoji_user_dict\u0026#34; : { \u0026#34;type\u0026#34;:\u0026#34;kuromoji_tokenizer\u0026#34;, \u0026#34;user_dictionary\u0026#34;:\u0026#34;userdict_ja.txt\u0026#34; } }, \u0026#34;analyzer\u0026#34; : { \u0026#34;my_analyzer\u0026#34; : { \u0026#34;type\u0026#34; : \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34; : \u0026#34;kuromoji_user_dict\u0026#34; } } } } } \u0026#39; 「user_dictionary」というのがユーザ辞書の定義ファイルになります。 注意点としては、6行目で指定した名前「kuromoji_user_dict」を14行目の「tokenizer」に指定しないとちゃんと動かないという点でしょうか。\n上記で指定したAnalyzerを利用して「朝青龍」という単語をを解析してみます。\n$ curl -XGET \u0026#39;http://localhost:9200/kuromoji_sample/_analyze?analyzer=my_analyzer\u0026amp;pretty\u0026#39; -d \u0026#39;朝青龍\u0026#39; { \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;朝青龍\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 3, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 1 } ] 「朝青龍」という単語がユーザ辞書に登録されているので、1単語として出力されます。 ちなみに、デフォルトの「kuromoji」のanalyzerを指定すると以下の様な出力です。\n$ curl -XGET \u0026#39;http://localhost:9200/kuromoji_sample/_analyze?analyzer=kuromoji\u0026amp;pretty\u0026#39; -d \u0026#39;朝青龍\u0026#39; { \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;朝\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 1, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 1 }, { \u0026#34;token\u0026#34; : \u0026#34;青龍\u0026#34;, \u0026#34;start_offset\u0026#34; : 1, \u0026#34;end_offset\u0026#34; : 3, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 2 } ] とまぁ、こんなかんじです。 ユーザ辞書を書き換えたあとは「close/open」しないと読み込めないのかなぁ？そのへんはまたあとで調べようかな。\nちなみ、以下のページを参考にさせてもらいました。 elasticsearch kuromoji plugin - natural days ElasticSearch で kuromoji を使う (ES 0.90.Beta1 + kuromoji 1.2.0篇)\n","date":1363765380,"dir":"post/2013/","id":"f5f28f42ad234b4389af4cbea54ff60d","lang":"ja","lastmod":1363765380,"permalink":"https://blog.johtani.info/blog/2013/03/20/elasticsearch-analysis-kuromoji%E3%81%A7%E3%83%A6%E3%83%BC%E3%82%B6%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%88%A9%E7%94%A8%E6%96%B9%E6%B3%95/","publishdate":"2013-03-20T16:43:00+09:00","summary":"なんか、とても久しぶりにイベント参加メモ以外の投稿です。 elastic searchのMLを見てたら、KuromojiのAnalyzerを使うときにユーザ","tags":["elasticsearch"],"title":"elasticsearch-analysis-kuromojiでユーザ辞書の利用方法(Jugemより移植)"},{"contents":"久々にブログ＋イベント参加です。 知り合いが開催＋出演したので参加してみました。 「スマホ」ってキーワードはあまりなかったけど、面白かったです。\nとりあえず、メモ。 余力があれば感想追加します。\n日時：2013/03/19 19:00 場所：パレスサイドビル9F マイナビルーム （東京都千代田区一ツ橋1-1-1） URL：http://atnd.org/events/36966 登壇者：@naoya_ito @yusuke ◯@naoya_itoさんの発表 最近、感心してること。 ・RubyMotionやってます。 今年5月に ・AWSもやってるよ。 ・「継続的デリバリー」の話 GREEでは毎日デリバリーしてるよと。 ・Chefの話 DevOpsとか。 ・Obama for Americaの話 GitHubとか使ってた。 身に付けるべきものは？ 「変化に適応する力」が必要だよね。 最近は Ruby、クラウド、AWS、iOS開発とかやってる、どうしてこうなったｗ 先は予測してないけど、変化に適応するには5分でいいからやり続けること。 ◯@yusukeさんの発表 自己紹介が難しい ・今やってること ブログ執筆 刺さるツイート研究 ソフトウェア販売代理店 思わぬ収穫。InDesign/Illustratorのスキル、ビジネスの仕方ｗ 会社設立中。 Webサイト構築・運用 ・ハッタリが大事 ・プログラム好き プログラミング以外を仕事にしてる。 ・人と違うことがしたい。市場がない場所での差別化はしない＝トレンドに逆行し過ぎない。バランス。 ・今は種まき中。 ◯ディスカッション ・2,3年後とか何やってると思いますか？ @naoya_itoさん ドラクエやってると思ってるかもしれませんが、サービス作るコード書いてます。 将来的な見通しでやってるのか？って言われるとそうでもない。 ツールとかよりは、コミュニティとかのサービスを作るほうが好き。 @yusuke 一定の収入がありつつ、プログラミングしてたい。あわよくばサービス作ったのが当たるといいなぁ ・そもそもフリーランスをどう捉えているか？ @naoya_ito いいところ。自由に自分の時間をコントロールできる。 悪いところ。自分でコントロールしないといけない。 自分をコントロールしないと厳しい。 フリーになってわかったのは、会社は人間を働かせるための仕組みをよく考えて出来てる。 フリーでいいのは、選択した結果に自分が責任を持つというのがいい。 @yusuke セフルマネージメントできたほうがいい。 しがらみを捨てるためにフリーになるのはおすすめしない。 ・情報発信を継続してるけど、必要なことか？ @naoya_ito 必要とは思わないけど、みんな書いたらいいと思う。 検索すれば自分が助かるからｗ セルフブランディングのために重要？かなぁ。あまりそれが唯一の方法ではないと思う。 @yusuke 発信することで、何に興味を持ってるかをわかってもらえるから、便利かな。 ブログに残したほうがググって引っかかるよと。 ・技術の方向性？見つけ方？は？ @naoya_ito 直近は、クラウド流行るしiOSはまだ伸びてるしと。 そっから先はどうするの？ わからないよね。じゃあ、どうするの？って変化に対応してボトムアップで見つけてくのがいいんじゃないかなぁ。 人がやってないところを先にやらないと武器にならないけど、どうやって見つけるのか？ プログラミングやってる時に、その先に必要なこととか、気付きがあるので、手を動かさないとだめだよねと。 @yusuke トレンドを追いかけつつ、知ったかぶりするのは重要 ある程度ハッタリ＋手を動かす ","date":1363692480,"dir":"post/2013/","id":"5412fb82160d0f6093e4b6670f505c13","lang":"ja","lastmod":1363692480,"permalink":"https://blog.johtani.info/blog/2013/03/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass%E7%AB%B9%E6%A9%8B--vol1-%E3%82%B9%E3%83%9E%E3%83%9B%E6%99%82%E4%BB%A3%E5%88%B0%E6%9D%A5%E3%81%93%E3%81%AE%E5%85%88%E7%94%9F%E3%81%8D%E3%81%AE%E3%81%93%E3%82%8B%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%A8%E3%81%AF%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-tecomp/","publishdate":"2013-03-19T20:28:00+09:00","summary":"久々にブログ＋イベント参加です。 知り合いが開催＋出演したので参加してみました。 「スマホ」ってキーワードはあまりなかったけど、面白かったです。","tags":["勉強会"],"title":"エンジニアのためのスキルアップ勉強会『Tech Compass』＠竹橋 ― Vol1 「スマホ時代到来、この先生きのこるエンジニアとは！？」に参加しました。#tecomp(Jugemより移植)"},{"contents":"技術ブログから離れていってますが。。。 Xperia Zを購入しました。\n前に使っていたのはXperia arcになります。 もうすぐ２年だったのですが、容量不足に悩まされていたため＋芸の肥やし（仕事の足し）という名目で Xperia Zの購入に踏み切りました。 予約しての購入です。\nいくつか戸惑いなどを感じているので備忘録としてブログに残しておきます。 サイズが大きい___ まぁ、わかっていたことですが、5インチと大きいです。 ステータスバーを表示するのがちょっときついくらいです。 私は手が大きい方なのですがそれでもキツイので、普通の人は両手じゃないと厳しいんじゃないかと。。。 一応、ステータスバーを表示するためのアプリなんかもあるようなので、その辺を検討するのもいいかなぁと（まだインストールもしてませんが。） また、Angry Birdを演ってびっくりしたのですが、解像度が大きいため、startボタンなどが小さくて押しづらいですｗ\n移行がめんどくさい___ iPadも持っていて、ソレと比較するとひどくめんどくさかったです。 実は方法を知らないだけかもしれないんですが。。。 iPadだと、初期化したりしてもiTunesにインストールしたアプリなども覚えていてくれます。 ですので、すぐに同じ環境が出来上がります。 Xperiaに関しては、arcでインストールしてたアプリをインストール履歴を元に一つずつインストールして、 それぞれのアプリやアカウントを設定して行きました。 これが結構面倒で、まだ完全にはアプリがインストールできてないかも（他にも新しいものを入れたいなぁと思いつつ、探す手間を惜しんでます。。。おすすめアプリお待ちしてます。）\nZite、Angry Bird star warsがインストールできない___ Ziteは英語の勉強も兼ねて入れていたのですが、対応していないバージョンですと言われます。 AngryBirdもいっしょですね。 starwarsじゃない奴はインストールできたのですが、肝心のやってみたいstar warsがインストールできなくて。。。\nドコモアプリがいっぱい___ ドコモのアプリやプリインストールアプリがいっぱいあったので、どうしようか悩んでいます。 いくつかはアンインストールしました。HotpepperBeautyとか間違いなく使わないし SFA-QRというよくわからないアプリも入っていたのでこれまたアンインストールしました。\n通知に出さないアプリとか選択できない？___ 容量不足だったのも有り、TwitterクライアントにはTwiccaのみをインストールしていたのですが、今回はTwitter純正のクライアントもインストールしました。 お気に入り登録されたりといった状況も見れるので重宝するのですが、基本的にはtwiccaを使うつもりです。 ですが、通知バー（ステータスバー）に@ツイートが届いたなどといった通知は見なくてもいいと思っているんですが、なにか方法あるんでしょうか。\ndビデオが危険___ いわゆる携帯ショップで機種変更したため、いくつかのサービスに登録しないといけませんでした。 で、dビデオ（月額525円で映画とか見放題）に登録したので、せっかくだからと映画をダウンロードしてみたのですが、危険です。。。 ただでさえ、本読むのが遅かったり、コーディングしてないのにビデオ見ると更に時間ががが。。。 けど、面白くて。。。危険です。（スターシップ・トゥルーパーズ見ちゃいました。。）\nクレードルがもう一つほしい___ 防水なので、あまりキャップを開けたくないんです。 そして、dビデオとか見てるとやっぱり電池の減りがはやいんです。（ディスプレイが大きいのもあるのかなぁ。要らないサービス切るとかしないと） 結局、出先でも充電をしないといけなくて。 ただ、純正のクレードルが2100円と結構な値段でして。。。 あと、イヤホンを指すところもキャップがあるので、Bluetoothレシーバーも気になってたりします。 こちらも結構な値段でして。。。\nとまぁ、新しいものを手に入れて、色々悩んでますが、楽しいですね。購入したての色々と悩む時間がｗ おすすめアプリとかあったらコメントください\n","date":1360687980,"dir":"post/2013/","id":"b051fd352847c06e748b345e8ed0738b","lang":"ja","lastmod":1360687980,"permalink":"https://blog.johtani.info/blog/2013/02/13/xperia-z%E8%B2%B7%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2013-02-13T01:53:00+09:00","summary":"技術ブログから離れていってますが。。。 Xperia Zを購入しました。 前に使っていたのはXperia arcになります。 もうすぐ２年だったのですが、容量不","tags":["備忘録"],"title":"Xperia Z買いました(Jugemより移植)"},{"contents":"金曜日に引き続き、イベントに参加して来ました。（仕事。。。これも仕事だよ。）\n「Hadoop Conference Japan 2013 Winter」です。 普段、Hadoopを触るのも少ないのですが情報を仕入れときたいなぁということで。 今年はビッグサイトですよ。そろそろ無料のカンファレンスもキツイのではないでしょうか。。。 こちらの写真はセッション会場。今回もすごいです。。。 簡単ですが、聞いていた感想です。 全体的に、Hadoop本体の話ではなく、エコシステムと呼ばれる周辺のプロダクトの話や実際に運用している実例が増えていました。 だいぶ普及期に来たのかなぁと。そして、自分の不勉強を実感できたなぁと。 （あと、TreasureDataに絡む話が多いなぁと言うのも印象です。そういうセッションを選んで出ていたのかもしれませんが） 懇親会まで残っていたのですが、結構、すごい方たちの顔ぶれだなぁというのを今更ながらに実感するとか。 （ハチ象Tシャツを着ているすごい集団でもありましたが。。。）\n以下はいつものメモになります。だいぶ金曜日のイベント後で腑抜けてるのでメモが雑ですが。\n◯ご挨拶 Doug Cuttingさんのビデオ（あんまり聞けてない）　さすがのhamakenさんのトークの安定感。 後援はリクルートテクノロジーズさんが大半。 リクルートテクノロジーズの米谷さんが軽く発表 ◯LINEのHBaseを利用した大規模なメッセージストレージ：NHN Japan 中村 俊介 まずは、LINEの紹介が続く。 New Yearのメッセージは3倍位だったけど、何とかなっったよと。 データロスがない。 サーバ故障からのデータリカバリも自動でやってくれる 書き込み1ms、読み出し1-10msでできてる ・IDC onine migration クライアントベースで2つに書き込み Incremental replication（新データ）、BulkMigration（旧データ） 元のHBaseのレプリケータは利用してない（pushだったから。スループットコントロールしたかったから） ・NN failover 2012.10にNameNode障害発生 HA構成にしてたから問題が発生。 VIPはHDFSにつかうとリスキー 現在： 少ないダウンタイムを許容する ・Stabilizing LINE message cluster ※あとでHBase触るときに資料見直すくらいで。。。 Case1：Too many HLogs Case2：Hotspot問題 まぁ、けど1億ユーザのインフラとして使えるってすごいよな。。。　◯Hadoop meets Cloud with Multi-tenancy： Treasure Data 太田 一樹 TDもFluentdも有名だなぁ Hadoopのメンテナンスとか、つらいよねというのを見てきたのでTD作った ・なぜ、BigData+Cloud？ Hadoopだけみてもバージョンが混在してる＋ディストリビューターも多くなってる 十徳ナイフみたいになってきてるけど、必要なのはナタだよね。というのを提示するためにTD立ち上げた。 ・なぜCloud？ ・IaaSベンダーの対象としてるのはSCM。 オンプレだとHWが陳腐化してくよね→HWはクラウドが主流に ・PaaS、SaaSの対象は時は金なり バージョンアップとか大変だよねと ・TDのご紹介 唯一の解析用DBを目指して ・哲学とアーキテクチャ 解析とか運用をいかに楽にしていくかというのを主体においたサービスを提供したい？ いかに速くレポーティングシステムを簡単に構築していくかとかの話 簡単なインタフェースと目的に集中することで、価値を提供 ・AWSとの違いは？ ・アーキテクチャとか技術的な話 データを集める処理がデータ解析に実際には重要なフェーズ ・カラム指向でデータ保存 実装がどーなってるのかとか、TD内部のHadoopクラスタの運用、バージョンアップとかがどうなってるのかもきになる。（企業秘密だろうけど） ◯Amazon Elasti MapReduceとHadoopコミュニティの関わり：Amazon Web Services Peter Sirota ・３つのV Volume、Velocity、Variety ・yelpのAuto-suggestの例 カスタマーのレコメンデーションにElasticMapReduce使ってるよと。 ・razorfishの広告インプレッションの解析に使ってる ・Amazon.comでの話 AWS Public Datasetsの話 http://aws.amazon.com/jp/publicdatasets/ IonFluxのDNA解析の話 ・いろんな分野でのBig Data 事例がちらほら ※わかりやすい英語なんだけど寝不足が。。。 ◯ランチ！ サンドイッチと豚汁とあとなんとかライス。 TDブースにて、fluentdのTシャツもらったよ！ ◯Hadoop\u0026#39;s Power to Transform Business：MapR　Ted Dunning ・Mahaut＋Solrの単語が。8時間のレコメンデーションデータの作成が3分に？？ ・Stormにてリアルタイム処理と連携。バッチ処理はMRで。 ・バッチ処理とリアルタイム処理の間としてのDrill ・Drillの概観とできるところの話。 （あとでスライドで）データ解析のために機会学習の処理とかも投げられそう。 Q：ImplaraとDrillの違いは？ コミュニティベースかなどが違うよね（あまり聞き取れず） Q：Drillの開発はどのくらいすすんでるの？ A：。。。 Q.クエリ言語としてSQLがいいの？ A.No。というのも、単独の言語ですべてにベストというのはないから。SQLはわかりやすくて良いが、実行が非効率な場面も。 ◯Introduction to Impala～Hadoop用のSQLエンジン～：Cloudera　川崎 達夫 ・Impalaとは 分析に特化した低レイテンシクエリ実行基盤 Apacheライセンス バッチ処理要ではなく、データサイエンティストが試行錯誤するときに利用するのを想定 パフォーマンスが良い 実行エンジンはC＋＋とかで実装されてる MapReduceに依存してない ・MapReduceの問題点 MR直接は難しい→Hiveとか、M/Rの実装を隠して使いやすくするものが増えてきた Hiveを例に説明。MRがベースなので高レイテンシ ・Impalaのアーキテクチャ 機能制限やGA版について言及されてる資料なのが良い ・GA以降の話もあり ピンチヒッターなのに落ち着いて発表とか凄すぎです。 jdbcサポートも入ると。 プランナーはjava実装 Hiveとの互換性は？→完全互換を目指す。 開発のプロセスが見えにくいのでは？開発主体がcloudera ◯Flumeを活用したAmebaにおける大規模ログ収集システム：CyberAgent　飯島 賢志 立ち見。 Flumeのコミッターの人がCAにいたんだ。 ◯Log analysis system with Hadoop in livedoor 2013 Winter：NHN Japan　田籠さん@tagomorisさん ・NHNJapanのお話 ・Webサービスのログ解析について話していく 400+Webサービス ・2011年8月にLTしました。 ・1.5TB/day。。。 ・batchとstream Batch集計も重要だし、Stream処理も重要なので、ハイブリッドシステム ・システムーバービュー FluentdClusterを中心にして各種ツール、保存先に転送してる。 これが結構重要。だけど、今日はFluentdの話ではない ・Fluentd周りを一人でやってるのか。。。 ・処理の流れ ・ログの収集と、生ログ保存 ・パース（主にHive用に）、変換、フラグ追加（分類しておくとあとで集計したいとか、保存すべきかを処理可能に） ・Hiveにロード ・第1世代のはなし すべてbatch処理、Scribe 遅延が1時間ちょっとあるため、Hiveクエリで結果が見れないとか。 ・第2世代の話 Fluentdのstream処理にHadoop Streamingを呼び出せるようなプラグインを書いた Fluentd＋HoopServerの構成 ・第3世代 HoopをWebHDFS Fluentdでのオンライン集計 GrowthForcast、HRForcast ・第4世代（ここ1週間でやったこと） CDH4でQJMベースのNameNode（Failoverは手動） Hiveのスキーマを変更（これはブログに今度書くよ） とりあえず、現時点で改善点が思いつかない ・総括 HTTPベースでRPCベースにしたのでコンポーネント切り替えが結構楽 OSSで公開されてるからいいよね 公開することにより色々とドライブするよ！ ◯いかにしてHadoopにデータを集めるか：Treasure Data　古橋 貞之 ・自己紹介 ・ビッグデータ収集の問題点 ・壊れたデータが入ってる ・読み書きの時間がかかる ログはサブケースである。メインはサービスとかだから。 ・トライ＆エラー処理が時間かかる ・データを分割するのが基本的なアイデア 失敗した時のリトライが楽になる。さらに、それをStream処理すれば良いよねと。 ・flumeのお話 ・fluentdのお話 バッファリングは性能アップも兼ねてる 設定のクラスタへの伝搬とかインストールはpuppetとか使おうねと。 プラグインのインストールが楽 ・いくつかのプラグインの紹介 ・TDへのデータ投入のお話 ・最後にmuddydixonさんのプラグインの宣伝がw ◯Hadoopの次に考える分散システム技術：Microsoft　萩原 正義 ・CAP定理の克服をどうしていくか ・CAPのおさらい ・Lease クライアント主導、サーバ手動とか （理論重視の話で最後のセッションには辛かった。。。頭が疲れててついていけませんでした） おまけ 今回頂いたノベルティなどを写真に撮ってみました。（ランチはお腹すいてて写真取らずに食べちゃいました。。。） Hiveロゴへの愛を語ってHive Tシャツをゲット。 FluentdのTシャツももらいました！ Hiveステッカーなどもゲット あと、メッセージボードなるものがあったので書いてみました。一応、Hadoopに絡んだことですよね！？\n","date":1358783400,"dir":"post/2013/","id":"bf4f86812812dab8d39db9aaefe94a78","lang":"ja","lastmod":1358783400,"permalink":"https://blog.johtani.info/blog/2013/01/22/hadoop-conference-japan-2013-winter%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hcj13w/","publishdate":"2013-01-22T00:50:00+09:00","summary":"金曜日に引き続き、イベントに参加して来ました。（仕事。。。これも仕事だよ。） 「Hadoop Conference Japan 2013 Winter」です。 普段、Hadoopを触る","tags":["勉強会"],"title":"Hadoop Conference Japan 2013 Winterに参加しました。#hcj13w(Jugemより移植)"},{"contents":"1/18（金）に開催された、エンジニアサポートCROSS 2013で「検索CROSS」セッションのセッションオーナー（モデレータ）をやって来ました。\n@muddydixonさんに昨年の夏くらいに声をかけていただいたのがきっかけです。 こういったイベントの運営のお手伝い（ほとんど何もしてない）も初めてでしたし、セッションオーナー（モデレータ）も初めての経験で色々といい勉強をさせて頂きました（自分の足りない所とか、考慮すべき点がどういったところにあるとか）。本当にありがとうございます。\nスピーカーとして登壇していただいた久保田さん、佐藤さん、安田さんほんとうにありがとうございました。 頼りないオーナーで、モヤッとした内容を提示したにもかかわらず、意図を汲み取って話の内容をふくらませていただいてすごく助かりました。 また、会場にお越しいただいたみなさん、ありがとうございました。すこしでも検索に興味をもっていただければ、セッションは成功だったと思っています。 朝一だったのと、私の認知度の低さもあったのとで残念ながら満席とはいきませんでしたが。。。\n後日、録画されたセッションの内容を見て色々と反省しようかなぁと。。。 緊張していたので、うまくモデレートできてたのか、話ができていたのか不安ですが。 忌憚ない感想をお待ちしています。\nということで、反省終わり！ここからは、イベントの感想と聞いたセッションに関する感想です。\n###聞いたセッション\n####企業CROSS DeNA x グリー x Aiming： 大企業・ベンチャーが語る「スクラム」開発 (仮)\nGoogleの及川さん見たさで参加しました。 スクラム自体は名前くらいは聞いたことある程度だったのですが、その程度の私でもわかりやすいディスカッションで楽しかったです。 聞いていて感じたのは、次のようなこと。\n「スクラム」という開発手法の話しなんだけど目的はそこじゃなくて、どうやってうまくプロジェクトを回して（ドライブして）、目的（サービスを作るとか顧客の要望を叶えるとか）を達成するかというのが重要だなぁと。 「スクラムマスター」の仕事は子育てに似てる 「スクラムマスター」になりたい人はなかなかいないらしい 「スクラムマスター」の人は、俯瞰してプロジェクト全体を見渡して落穂拾いをしていく人なのかもなぁと 個人的には「スクラムマスター」の仕事がちょっとおもしろそうと思いました。（いつもいろんなことを面白そうと思う自分なのでなんともいえないですが。。。）\n####データ理解を助けるビジュアライゼーション\n昨年からビジュアライゼーションには興味だけ（実践とかできてない）は持っていたので、参加しました。 スピーカーの方々の対立軸がはっきりしていたのが面白かったかと。 聞いていて感じたのは、次のようなこと\nビジネスの視点からのビジュアライゼーションはコスパがどうなのかというのがまだ不明 可視化できたらおしまいじゃなくて、お金につながる可視化に心がけるのが重要そう 可視化して楽しむのも有りだとは思うけど、それは趣味だったり芸術の話かもなぁ 異なるコンテキストの人にでも誤解を与えない可視化というのが重要 何をどう可視化するかというのが実は統計学知ってると必要ないこともある 基本的にはCAの方の内容が一番しっくり来ました。やっぱりビジネス的な視点と学術的な視点は違うのかもなぁと。\n####継続的システム運用のゲンバのハナシ\n面白かったです。のっけから燃料がテーブルにならんでるしｗ 運用とかインフラはそこまで詳しくないのですが、少しは作業したりするので気になってましたが、ぶっ飛んだ話が聞けて楽しめました。 聞いていて感じたのは、次のようなこと\nサービス内容によっては夜中にアクセス数が低いものもある（cookpadは夜中はアクセス数が低い） アプリを修正することでインフラを楽にするという考えもある インフラエンジニアは実はリア充 cookpad面白い人多いw このあとは、おまちかねのプレモルタイムだったので、プレモル片手（失礼だろｗ）にTech10の池本さんに挨拶してきました。（Solr本のときはお世話になりました！） あとは、RedBull片手に知り合いの方々（Twitter上のみやいつもお世話になってる人）に挨拶をして回ってました。（プレモルも美味しかったのですが、プレモルおつまみも美味しかったです！） また、ちょっとつかれて座るために入った「体系的に学ぶ安全な利用規約の作り方」でも、面白い話を聞けました。 （利用規約をきちんと考えて変更している企業のほうが炎上をしてしまうとか無駄だしおかしいよねとか）\nイベント終了まで、会場にいて（いただけで大した手伝いしてないです、すみません。）その後打ち上げに向かって楽しみました。\n####さいごは、イベント通じて感じたことと気になったこと。（若干、意図的なものが入り込んでますが。。。）\n題材にもなってる「CROSS」ですが、ここ数年特に、エンジニアとして複数の技術や考えなどを身につけないといけないなぁと 有名人に会える！（ミーハーです。。。） プレモル美味しい！（いつも飲んでるビールが「え？」って思った） ケンタッキー美味しい！ RedBull美味しい！ いろんな技術分野に触れられる機会ができそう Wi-fiは用意してもらえると助かる。（参加者の方々が一斉にLTEとかでつなごうとするのでみんなが繋がらなくなってツイートされないとかちょっとつらいかも） 各会場が覗けるようになってたのは良かった（ただ、会場の後ろの人はざわつきを感じるためスピーカーの声が聴こえないことも） スクリーンはもう少し高い位置にあると良かった（後ろに座ると下のほうが見えないことも） 飲食の配布は会場内でできたほうが良かったのかも（NGなのかな？）。プレモルやRedBullは配ってくれたので良かったのだが、食べ物を取りに行くために入口付近が混雑してた気がした。 （これで、メッキ剥がれたかなぁ） 会場入り口の写真とか撮ってくるんだった。。。 ということで、総じて楽しかったので来年もあるならまた、手伝いたいです！\nおまけ\nプレモル！ Amebaウォーター プレモル＋プレモルおつまみ＋RedBull いただいたスタッフTシャツとプレモル！\n","date":1358600940,"dir":"post/2013/","id":"322264a17ef7182eb1475bd2eaebc2eb","lang":"ja","lastmod":1358600940,"permalink":"https://blog.johtani.info/blog/2013/01/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88cross-2013%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%8A%E6%89%8B%E4%BC%9D%E3%81%84%E3%83%A2%E3%83%87%E3%83%AC%E3%83%BC%E3%82%BF%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--cross2013/","publishdate":"2013-01-19T22:09:00+09:00","summary":"1/18（金）に開催された、エンジニアサポートCROSS 2013で「検索CROSS」セッションのセッションオーナー（モデレータ）をやって来ま","tags":["勉強会"],"title":"エンジニアサポートCROSS 2013に参加（＋お手伝い＋モデレータ）しました #cross2013(Jugemより移植)"},{"contents":"いまさら感満載ですが、今週の金曜日(1/18)に開催されるCROSS 2013というイベントで「検索CROSS」のセッションを担当することになってます。\nここ数年、検索に携わっていますが、検索は色々な技術の組み合わせ（検索用インデックス、自然言語処理、機械学習などなど）でなりったていて奥が深いなぁと感じる毎日です。 そこで、実際のサービスで検索をやられている方、検索プラットフォーム製品を開発している方、自然言語処理や検索に長けた方を招いてつぎのような話をしてもらおうかと。\n・現在の事例（検索とその周辺技術） ・今後の検索にクロスすると面白い技術\nがっつり検索をやられている方々に登壇していただきますので、検索に興味のある方はぜひ、ご参加を！ 登壇者の方々についてはこちらを御覧ください。\n検索CROSS以外にも楽しみなセッションが多数ありますので、参加をご検討いただければと。 あと、実はこっちがメインなのですが、夕方からのプレモルタイムも期待できるのでこちらへの参加だけでもぜひ！！\n","date":1358267340,"dir":"post/2013/","id":"20110c8f8da8304b6d9d3c2845a38128","lang":"ja","lastmod":1358267340,"permalink":"https://blog.johtani.info/blog/2013/01/16/%E3%81%84%E3%81%BE%E3%81%95%E3%82%89%E3%81%A7%E3%81%99%E3%81%8Ccross-2013%E3%81%A7%E6%A4%9C%E7%B4%A2cross%E3%81%A8%E3%81%84%E3%81%86%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E6%8B%85%E5%BD%93%E3%81%97%E3%81%BE%E3%81%99/","publishdate":"2013-01-16T01:29:00+09:00","summary":"いまさら感満載ですが、今週の金曜日(1/18)に開催されるCROSS 2013というイベントで「検索CROSS」のセッションを担当することにな","tags":["勉強会"],"title":"いまさらですが、CROSS 2013で検索CROSSというセッションを担当します(Jugemより移植)"},{"contents":"年末から年始にかけて、「コード・シンプリシティ」を読みました。\n先日の記事にも書きましたが、Kindle paperwhiteを思いかけず入手できたので、eBookを読みたいなぁと思いまして。 Kindleのお試しも兼ねて読んでみました。\nまずは、本の感想。 短めの書籍＋読み物なので、サクっと読めました。 題名に「コード」と書かれていますが、コードの実例が出てくる書籍ではありません。 「ソフトウェア」を以下にシンプルに保って、管理しやすくするか、機能追加、テストをやりやすくするかといった指針について書かれています。 機能追加に関して検討しないといけないバランス（先読みしすぎずと実装しすぎないとか）の話や定期的なデザインの見直しなどについても書かれています。 ソフトウェアに関しては動くこともだが、デザインが重要であること。（確かに。） すでにあるソフトウェアについて、どのように簡潔にしていくかという話もありました。 ただ、読んでいて一番重要だと思ったのは、「悪いプログラマーと良いプログラマーの違いは理解力だ」という一文です。 何をしているかを「理解」していないと、根本的な問題点の解決もできないですし、どうすればコードが簡潔になるかといったこともわからないです。 また、やっている作業がどんなもので、何のためにやっているのか、それを行うことで今後にどのような影響があるのかといったことも理解しておく必要があるかと。 ま、ある程度考えながら作業とかしましょうってことですかね。（強引なまとめかも。。。）\nで本題です。 Kindle paperwhiteとiPadの使い分けを検討するのも兼ねて本を読んでました。 iPadを持っているのもあり、Kindleはそもそも眼中になかったのですが、めっけ物でした。 やはり実際に使ってみないとわからないことありますねぇと。 paperwihteはつぎのような利点があるかと。\n読書に没頭できる。→本を読むというシンプルな目的を達成するものだけが実装されている 目が疲れない→Twitterでも話に上がったのですが、液晶とは異なり字が読みやすいです 軽いし小さい→電車で立っていても楽に持てるし、カバンからの出し入れも楽です（iPadに比べて） 複数の端末のKindleアプリで同期できる。→あまり異なる端末では読まないですが、paperwhiteで読んだところが、iPadでも同期されるのですんなり続きが読めます 電池長持ち ということで、本を読むのに没頭できるし目が疲れないと。 ただ、つぎの点では不満もあります。\nPDFは読みにくい。→画面のサイズが小さいので大きめの書籍のPDF版は読みにくいです。 PDFは読みにくい。→文字のサイズを変更できないのもキツイです。Kindle専用のmobi形式の書籍が読みやすいです ページめくりに一定時間がかかる→紙の書籍やiPadで書籍を読むのとは異なり、ページをめくるのに時間がかかります。e-inkの再描画の問題かと。パラパラと書籍を読みたい場合は厳しいです 白黒。カラーの電子書籍は読めないですねぇ ソースコードなどもキツイ→長めのコードが書いてある本だとコードが頭に入ってこないです。。。 という感想でした。 今後は基本Kindle paperwhiteを持ち歩きmobi形式の本を読むようにすると思います。 iPadは自炊本やカラーの本を読むとき、映像、ネットを見るような場合に持ち歩くことになりそうです。 私は基本的にMBAを持ち歩いているというのもあるので、paperwhiteのほうが主流になりそうです。 ネットを見るときなどは最悪、MBAを開くでしょうし。 小説とかをメインに読むのであれば断然、paperwhiteだと思います（最近読んでないなぁ）\n","date":1357658880,"dir":"post/2013/","id":"992a00c30242b6217243f3c387ea18b7","lang":"ja","lastmod":1357658880,"permalink":"https://blog.johtani.info/blog/2013/01/09/%E3%82%B3%E3%83%BC%E3%83%89%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AA%E3%82%B7%E3%83%86%E3%82%A3%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9Fkindle-paperwhite%E3%81%AE%E4%BD%BF%E3%81%84%E5%8B%9D%E6%89%8B%E3%81%AE%E7%A2%BA%E8%AA%8D%E3%82%82%E5%85%BC%E3%81%AD%E3%81%A6/","publishdate":"2013-01-09T00:28:00+09:00","summary":"年末から年始にかけて、「コード・シンプリシティ」を読みました。 先日の記事にも書きましたが、Kindle paperwhiteを思いかけず入手で","tags":["読書"],"title":"「コード・シンプリシティ」を読みました。（Kindle paperwhiteの使い勝手の確認も兼ねて）(Jugemより移植)"},{"contents":"書こうと思いながら、気づいたら大晦日。 よくないですね、思いついた時に書かないと。\n昨年も書いたので、昨年書いた抱負から振り返りをと。\nMongoDB触ってみる Scala触ってみる なんかWebサービス作ってみる（Amazonとかで） elasticsearch、IndexTankを調べてみる NewSolrCloudDesignを読み込んで自分なりにまとめる Junsaiに参加する 「7つの言語7つの世界」の続き えーと。。。できてないことばかりですねｗ MongoDBはインストールすらしてないですし、Webサービスも作ってないです。（さくらVPSは借りたんですが） Junsaiは参加したけど何もできてないし。7つの言語もそのままですね。。。 SolrCloudDesignはまとめられてないですしね。 Scalaは少しだけ触りました。結局Javaみたいな記述をしてしまうという良くないくせが出てしまうので、 見送ってしまいましたが。。。 elasticsearchは少しだけやりました。#pyfesで話をさせて貰える機会があったので。\n興味がコロコロ変わってしまうのが問題点かもしれないです。少しは地に足をつけてなんかやったほうがいいのになぁ\n###今年の振り返り 今年はこんなかんじでしょうか。\nいろんな勉強会に出没 #pyfesでelasticsearchのさわりを紹介 個人的にJIRA導入 MIR輪読会開始 Solr勉強会の主催を引き継ぐ Kindle paperwhite当たった 相変わらずいろんな勉強会に出てました。最近は勉強しに行くのもありますが、人に会いに行ってるような気がします。 勉強会から帰ってきて復習したりしないとすぐ忘れちゃうんですよね。。。\n#pyfesではelasticsearchの入門中という話をしてきました。 人の多さに緊張しまくりでよくわかりにくい発表になってしまったのが反省点かと。。。 もっと話をする機会を増やすとなれるのでしょうか。\nJIRAの導入はパラで仕事をしているとタスク管理がおろそかになってくるので導入しました。 フリーのredmineを考えていたのですが、インストールが簡単なJIRAを導入しました。 有料ですが、1-10人までなら、ダウンロード版が$10ですし。いろんな時間を買ったと考えると安いかと\n検索に関してもまだまだ初心者に近いということでModern Information Retrievalという英語の本の輪読を主催しました。 Twitterでの呼びかけに答えてくれた方々に感謝です。 まだ、半分も行ってないですが、何周かしたいと思っています。\nSolr勉強会の主催者も引き継ぎました。Atnd立てるの手伝おうか？って言ったら主催者になってましたｗ 来年も開催するので、喋りたい方、こんな話を聞きたいなどTwitterやブログでコンタクトいただければと。\nあと、会社の忘年会で思いがけずKindle paperwhiteが当たりました！（やったー！） iPadを持っていることもあり、完全に購入する気も無かったのですが。。。 使ってみると結構いいです。画面のギラツキがないのと、他のソフトがないのがいいです。 読書に没頭できます。通常はKindleを持ち歩くことになるかと。（没頭できるけど、読むスピードが遅い＋すぐ忘れるのが難点。。。）\n###来年の抱負 来年の抱負も書いておきます。 昨年の前科があるのでどこまでできるかわかりませんが。 すぐに興味が変わってしまうのもありますし\nIntelliJ IDEAをメインに使う JIRAを継続して活用 ブログの継続 elasticsearch Luceneのソースコードリーディング 何かOSSのソースを読む Macでもっと開発 読書と英語を継続 IDEA（アイデア）は11をインストールしてたのですが、使えていませんでした。 イメケンが主催したJetBrainsユーザー会で洗脳されて＋タイミング良い75%オフセールにやられて購入しました。 普段はEclipseを使っているのですが、これを機にチャレンジしようかと。 少し変化をしてかないとすぐ取り残されちゃうので。。。\nJIRAはまだタスクを登録してクローズするという初歩段階の使い方しかできてないので、少しずつ研究してフィールド追加したり、ワークフローを変更してみたりと研究したいです。\nブログは、今年後半が勉強会参加ブログしかないのを反省して来年は、もう少しSolrやLucene、lucene-gosenについて書いて行きたいです。 （すくなくとも、4.0で動かす話を書かないと。。。）\nelasticsearchはまぁ触れる環境を維持しようという話です。 どこかで導入できればいいんでしょうが、なかなか。 （勉強会開いてみるのも面白いかな？）\nLuceneソースコードリーディングは誘われてるのに、ちゃんと返事をしていなかったので。 来年2月のどこかの土日を候補日にする予定です。\n何かOSSのソースも読もうと思ってます。 「何か」はまだ決めてないですが、人のソースを実はあまり読んでないなぁと。 Vさんと話をした時に人のソースを読むのがいいですよという話になったので。 真似をするためにもなんか読みたいなぁと。Javaになるのかなぁ。\nとある事情で週4はWindowsで開発してます。 Macはちょっとしか触ってないのでMacの環境が成長していないのが難点です。 できれば、Macで開発を継続できる環境を作りたいなぁと。Kobitoとか入れてるけど触ってないし。。。 IntelliJも入れたのでMacで開発したいものです。\n最後は毎年のことですが、本を読むスピードが買うスピードに追いついてないと。。。 英語の本もかってるんですが、これまた読むスピードが。。。 ということで、ざっくり目を通す読書をもっとやりたいなぁと。 買うのはいいのですが、必要にならないと呼んだ内容を忘れてしまうので、読んだあとに実践する機会も設けたいと思ってます（思ってるだけかもしれないですが）\nあと、来年もいろんな人に会うためにいろんな勉強会に出没すると思いますので、声をかけていただければと また、不抜けているのを見かけたらカツを入れてください。（技術内容のブログ書けとか、本読んだ感想をブログにかけとか） 来年もTwitterなどで絡みまくると思いますが、よろしくです。\n","date":1356908460,"dir":"post/2012/","id":"4c08b67e0c1fdeef50b1fdcc32cdcee2","lang":"ja","lastmod":1356908460,"permalink":"https://blog.johtani.info/blog/2012/12/31/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A02012/","publishdate":"2012-12-31T08:01:00+09:00","summary":"書こうと思いながら、気づいたら大晦日。 よくないですね、思いついた時に書かないと。 昨年も書いたので、昨年書いた抱負から振り返りをと。 Mongo","tags":["備忘録"],"title":"今年の振り返りと来年の抱負（2012）(Jugemより移植)"},{"contents":"Atlassian Advent Calendar 2012の20日目。（急遽参戦） （某イケメンにMT（改変リツイート）されたので書いてみました） 久々に、勉強会以外のエントリです。（Solrとかlucene-gosenじゃないんだが。。。）\n私は、最近忘れっぽくなってきてしまったので、さくらVPSを借りてJIRAを立てて、タスク管理とかに使い始めました。 有料ツールなので、まずは、評価版から入れましたと。 評価版をインストールするときに、楽なのでHSQLDBを選択していました。が、 インストール時に「HSQLDBは評価版だけで使用してください。正式版ではサポートしてないです」みたいなことを言われていたので、PostgreSQLに切り替えようかと。 ちなみに、MySQLも選択肢としてはあったのですが、PostgreSQLのほうが触ってるし（つかいこなせてるわけではない）、補完機能になれてるというのもありPostgreSQLを選んでみました。\n作業のログとして、ブログ書いとこうと思いたったのでメモ的に残しておきます。\n作業の流れはこんなかんじでした。 （基本的にはサポートサイトのここに載ってます。サポートいいね。） この手順通りでいいみたい。\n###1. JIRAのデータのバックアップ（JIRAの管理画面からバックアップ）\nまずは管理画面へ。ページ右上に管理へのリンクがあるのでクリック。 開いた管理画面の右下あたりにエクスポート（バックアップ）へのリンクがあります。 クリックしたあとに、エクスポートのファイル指定画面が現れるので、ファイル名を指定してバックアップボタンを押します。 バックアップが完了するとバックアップファイルの場所が表示されます。 ###2. JIRAの停止\nバックアップが終わったのでJIRAを停止します。\n###3. PostgreSQLのインストール（yum） PostgreSQLが入ってないので、yum installします。（軟弱者なので）\nyum install postgresql-server ####initdbで四苦八苦 PostgreSQLはインストールしただけでは起動できません。なので、初期化をします。 yumでインストールしたPostgreSQLだとつぎのコマンドでinitdbできるようです。（これが罠でした）\nservice postgresql initdb このコマンドでinitdbすると、encodingが指定できませんでした。（私がしらないだけという話も。。。） encodingを指定できていないと、このあと4.を実行するときにエラーが出ました。（これも回避方法あるのかも。） ということで、結局、昔とった杵柄なやり方でinitdbコマンドで\u0026ndash;encoding=UTF8 \u0026ndash;no-localeを指定しました。\ninitdb --encoding=UTF8 --no-locale -D/var/lib/pgsql/data service postgresql start これで初期化が完了するので、PostgreSQLを起動します。\n###4. JIRA用DBとユーザの作成\nまずは、ユーザの作成。そして、DB作成\ncreateuser jirauser createdb -E UNICODE jiradb テーブルなど作成しません。あとの処理がやってくれます。\n###5. JIRAにJDBCドライバを入れる（必要なかった。）\nwarじゃないJIRAをインストールした場合はすでに入ってるみたいです。 ここを見るとわかります。JIRA Installation Directoryの下のlibですかね。\n/opt/atlassian/jira/lib ###6. マニュアルでPostgreSQLの接続設定（あれ、これいらないのか。）\n~~　コンソールオンリーなので、JIRAが提供してくれているツールが使えないため、手で設定。 /var/atlassian/application-data/jira にあるdbconfig.xmlを修正~~ ちゃんと英語読めってことですね。。。必要なかったです。。。\n###7. JIRAのdbconfig.xmlを削除\nDB接続の設定を初期セットアップウィザードで再設定するため、dbconfig.xmlを消します。 （一応、インストールディレクトリとホームディレクトリとかバックアップしたほうがいいみたい） 場所はここ。 中身はdbcpとかのデータソースの設定に似てました。 今は、HSQLDBのJDBCドライバが記載されてました。\nrm /var/atlassian/application-data/jira/dbconfig.xml ###8. JIRAの起動\n7.のファイルを消したあとにJIRAを起動します。\nservice jira start ###9. JIRAにアクセスとDB接続設定\nアクセスすると、インストールした時と同じDB接続の指定を行うセットアップウィザードの画面が現れます。 今回はJIRAサーバの外にあるPostgreSQLなので、「外部」を選んで四角で囲んだ部分を入力します。 入力したら、「接続テスト」を押して接続できることを確認したら「次へ」を押します。 マシンのスペックにもよると思いますが、ここでJIRAサーバがDBに接続してテーブルのCREATEなどDBのセットアップを実行してるのでちょっと時間がかかります。\n###10. バックアップしたデータのインポート\nDBのセットアップが終わったら、アプリケーションのセットアップ画面が出てきます。 新規インストールではないので、「ここ」にある「既存のデータをインポート」リンクをクリックします。 すると、インポートファイルの指定画面が現れるので、1.でバックアップしたファイル名を指定してインポートします。 すると、インポート中画面が出てきます。 で、インポートが完了すると無事JIRAにログインできますと。\nとこんなかんじです。 私の場合は、まだJIRAをインストールしてから間もないため、チケットの数が少なかったり、添付ファイルが無かったりなので、すぐにインポートが完了しました。 添付ファイルがある場合は、別途添付ファイルが保存されているディレクトリのバックアップと復旧などもあるみたいです。 最初にも書きましたが、ドキュメントのサイトに「Switching Databases」という項目があり、そのページの手順で問題なく切り替えできました。 次は、定期的にデータをバックアップするのを考えないとですかね。\nいやぁブログ書くのが、思いの外、手こずりました。 手こずった原因はスクリーンショットだったんですけどね。。。 safariでページ全体のスクリーンショットがとれなかったので、結局ChromeでAwesome Screenshotプラグイン使いました。 safariの拡張もあるんですが、ページ全体のスクリーンショットがうまく動かないみたいです。。。 ということで、備忘録でした。（次はちゃんとSolrとかの記事書かないとなー。その前に忘年ブログかな）\n","date":1356002280,"dir":"post/2012/","id":"4a30eeb083acec8460150068ba0c6743","lang":"ja","lastmod":1356002280,"permalink":"https://blog.johtani.info/blog/2012/12/20/jira%E3%81%AEdb%E7%A7%BB%E8%A1%8Chsqldb%E3%81%8B%E3%82%89postgresql%E3%81%B8-augj/","publishdate":"2012-12-20T20:18:00+09:00","summary":"Atlassian Advent Calendar 2012の20日目。（急遽参戦） （某イケメンにMT（改変リツイート）されたので書いてみました） 久々に、勉強会以外のエントリです。（So","tags":["JIRA"],"title":"JIRAのDB移行（HSQLDBからPostgreSQLへ）#augj(Jugemより移植)"},{"contents":"イケメンが主催した「第一回 JetBrainsユーザーグループ #jbugj」に参加してきました。\nいろんな製品があるんだなぁと。入り口には良いイベントだったと思います。 個人的に、WebStorm、IntelliJが気になっていたので、参加しました。（あとは、イケメンがやってるイベントだからというのもあるかも） ちなみに、MBAにしてからインストールはしていたのですが、ほぼ触っていなかったのでこれを機会にちょっと触ってみようかなぁと。\n発表は、全般的な製品紹介、ライセンスの紹介から、ライブコーディングあり、ここがいいよ！という話ありという感じでした。\nMTLさんのおしゃれな空間で発表を聞いたので、いつもとは少し違った感じでしたでしょうか。\n私自身は、発表を聞きつつ、IDEAのCEで色々やってました。 一応、Lucene/SolrのSVNからチェックアウトしたり、lucene-gosenのtrunkをチェックアウトしたり、個人のbitbucketからlucene-gosen-wikiparseとかcloneしてました。 Eclipseで作ったプロジェクトなので、cloneとかチェックアウトしたあとに、Eclipseと並行開発するとどうなるのかなぁ？というのがちょっと気になります。（普通は移行しておしまいなんだろうけど。。。） ちなみに、lucene-gosenのプロジェクトもSVNからチェックアウトしたらすんなり使えそうでした。 こんな感じ。（lucene-gosenのプロジェクト） とりあえず、見た目がカッコイイｗ\nいくつか触ったり、聞いていて気になったのはつぎのような点です。ちょっとずつ触る機会を作った時に調べてみようかなぁと\nEclipseのワーキングセット相当の機能はどうするのか？→モジュールとかでやればいいらしい。 プラグインってどんなものがあるの？探す方法とインストールの仕方 JDKの複数の切り替え方とか Eclipseでやってる人とIntelliJでやってる人の混在チームでの開発とか で、いつものごとく、懇親会に参加しました。 @mike_neckさんや@sue445さんとお話できたのですが、VCSにEclipseの設定ファイルとか挙げないほうがいいですよねとか、テストが無いプロジェクトってないわーなどの話を聞いて、やっぱり自分はまだまだなんだなぁと認識できるとか面白かったです。 lucene-gosenのSVNにはEclipseの設定ファイルとかアップされてるからなぁ。ホントはAntとかMavenのターゲットでこれらの設定ファイルができるようにしとくのがいいんでしょうねぇ。 まだまだ勉強することだらけですが、コツコツ教えてもらいます\nちなみに、イベント参加者にはショートカットキーが印字されたキートップシールや2ヶ月有効な評価ライセンスがあとからもらえるなどの特典もありました。 普段はEclipseなのですが、運良くライセンスが当たったら本気で乗り換えようかなぁｗ\nちなみに、Eclipseでもそうですが、私自身はショートカットキーをほとんど覚えてない軟弱者ですので、メニューの場所などを覚えれば乗り換え自体はこんなんじゃないかと。 Mac自体にKeyRemap４MacBookを入れていて、Emacsっぽいショートカットを使うので、覚えられないというのもありますが。 ライセンス当たらないかなぁー\n以下はいつもの通り、聴きながら自分用にメモしたものになります。\n日時：2012/12/11（火）19:00-21:00 場所：メディアテクノロジーラボ イベントサイト：http://www.zusaar.com/event/450003\n◎JetBrains製品群、ライセンス形態などの紹介 - @yusuke ・日本でヤル気あるの！？→あるある！→じゃあ、ユーザグループ立ち上げるぜー ・あくまで情報交換の場を設けるだけ。 ・アンケート結果 IntelliJが1番人気 WebStromが2番 ・ステッカー（ちょっとかっこ悪いかも。。。） ・2名限定でIDEAのライセンスプレゼント！ ブログ書いて、応募用フォームに登録してランダム抽選 ◎IntelliJの基本(インストール～プロジェクト作成、テスト、実行までのウォークスルー) @yusuke ・JetBRAINSはチェコの会社 ・IntelliJはなんでもできる（AppCodeは違うけど） ・.Net系もある（書きそびれた） ・YouTrack：課題追跡 ・TeamCity：継続インテグレーション ・読み方は「イデア」じゃなくて「アイデア」だよ！ ・Community Editionはあんまり機能がない。 OSSライセンスだと、Ultimateの機能が使えるよと。 ・仙台の人が一人アドベント・カレンダーやってます。 http://d.hatena.ne.jp/masanobuimai/20121201\n・ライブデモ 黒いインタフェースにするのどーすんだろう？ →Preferences→AppearancesでThemeで「Darcula」を選択すると黒くなる。 ・やべ、時間過ぎてたｗ終わり！ ◎IntelliJのここが気持ちいい！→普通IntelliJでしょ？ @mike_neck ・DQXやってます。 ・僕とeclipse ・新規クラス作成：3ステップかかる ・補完の素早さ： ・SprintFramework：Ultimateなら対応してるよ。 関係ないけど、TLで質問したので。 Eclipseのワーキング・セットに相当するもの。 http://d.hatena.ne.jp/masanobuimai/touch/20121024\n◎LT ◯WebStormとRubyMineについて @sue445 ・JavaScriptのIDEとして最強 jsの補完が素晴らしい。（外部のJSはプロジェクトに入れないと難しい。） jsTestDriver pluginがデフォルトで入ってる！ ・RubyMine RubyのIDE ソースを追うのが楽。 erbのインポートしたものも追っかけられるの便利。 viewからhelperクラスにも飛べる。 QA UMLとか出せるの？→出せるよ。 DBクライアントもあるよ。 ◎JetBrains発のJVM言語Kotlinの紹介 - @ngsw_taro アドベントカレンダー（一人）http://atnd.org/events/34627\n・社畜してます ・Androidアプリとか作ってる。 ・Kotlinな活動 Pull Requestしてる ・マイルストーンなど。 M4が3時間前に出た！ ・どんな言語？ 静的型付け、オブジェクト指向、関数型プログラミング的、JSへコンパイル可 産業利用目的（初めて聞いたかも、この言葉ｗ） ・Java大変だよね。 互換性問題とか ・ライブコーディング 大変そうだｗKUnitってのもあるらしい。 （ゴメンナサイ、IDEA触ってて、流してました。。。Eclipseで作ってたプロジェクトをBitbucketから落としてきて四苦八苦してた） （参考にしたサイト（ググった）：http://d.hatena.ne.jp/waman/20100506/1273166533）\n◎AppCodeについて ・IDEAには含まれないので、別途ラインセンス購入が必要。 ・XcodeとAppCodeの違いをライブコーディングで説明。 ・XCodeよりも補完が良くできてるっぽい。 GUIはXCodeで作って、コーディングはAppCodeでやるってのがいいですよ。 ※私が、iOS系のアプリの開発ってやったこと無いからよくわかってないです。。。 XCodeはコードフォーマットがないのが辛い by @yusuke ","date":1355228520,"dir":"post/2012/","id":"898d25a2ab9c0ba1fa9bad462405e475","lang":"ja","lastmod":1355228520,"permalink":"https://blog.johtani.info/blog/2012/12/11/%E7%AC%AC%E4%B8%80%E5%9B%9E-jetbrains%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97--jbugj-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-12-11T21:22:00+09:00","summary":"イケメンが主催した「第一回 JetBrainsユーザーグループ #jbugj」に参加してきました。 いろんな製品があるんだなぁと。入り口には良いイ","tags":["勉強会"],"title":"第一回 JetBrainsユーザーグループ #jbugj に参加してきました(Jugemより移植)"},{"contents":"ヒカリエに行ってみたいという不純な理由で参加してきました。 新しいということもあり、おしゃれで綺麗なカフェでした。 入り口にはおっきな人形も立ってたし。 渋谷の夜景も見下ろせて素敵な場所でした。\nで、内容です。残念ながら、本編の3回めには参加していなかったのですが、 今回も濃い話が聞けたので楽しかったです。 論文読まなかったり、基礎を勉強したのに忘れてたりと抜けてる部分が多いので、 こういう機会が与えてもらえるというだけで目からうろこです。\n@kumagiさんの「あなたの知らないハッシュテーブルの世界」はハッシュテーブルの基本的な話から、最近の論文で発表されてる内容までをカバーする幅広いお話で面白かったです。 （大学でやってると思うんだけどすっかり抜けてる自分がなんとも。。。） こういうコアな中身も知ってると、色々とプログラム書いたりするときの見方や考え方も変わってきますよね。 （そんなプログラム書いてないけど。。。） で、随分おとなしい内容だなぁ？と思いきや、途中からちゃんとLock-Freeの話も出てきてさすがと感心させられましたｗ 最後はJubatusの宣伝まで入ってたし。（某氏のすごい写真入りで。。。）\n@hitoshi_niさんの文書要約の話は、NLPに興味があるので、楽しみにしていた内容でした。 今回もなめらかによどみなく喋られる発表にただただ感心させられるばかりでした。 内容は中級編ということで、文書要約のキモになる処理の文章の短縮の話です。 係り受け木を元にする手法をわかりやすく説明されて、もうなんか、すぐに実装できちゃうんじゃないかと錯覚してしまう始末でした。 係り受け解析というと、CaboChaを思い浮かべてしまうんですが、きっと違う実装なんだろうなぁ。 入門編と次回の重要文抽出の話も聞きたいなぁと。\n最後に、技術評論社さんから「Emacs実践入門」など3冊の書籍のプレゼントまでありました。 その他の2冊は購入済みだったのですが、Emacs本は購入したいリストに入れたままでした。 ということで、欲しいですというアピールをしてゲットしてきました！ Emacsはなんだかんだで、もう10年以上使っていますが、そこまで深入りしないような使い方をしていました。 これを機に、再入門してもっと使いこなせるようになろうかと。 また、読了したタイミングでブログに感想かきます。\nということで、以下はいつもの自分用のメモになります。おかしいところ、それ書いちゃダメでしょ的なところのツッコミをいただければ。\n日時：2012年11月28日(水) 19:00 場所：渋谷ヒカリエ27F NHN Japan カフェ ◎開会、諸注意など　@overlast 人材募集、会場説明など。 前回、本をもらった人はブログ書いてね。オライリー様より 今回も本のプレゼントあり。技術評論社様より ◎あなたの知らないハッシュテーブルの世界(30分 + 質疑応答10分)　@kumagi さん ・まずは前提。 データの集合を扱いたいよね 配列でもできるね。けど、データ増えるとキツイね。 ・ハッシュ関数の話から。 リハッシュとかの話 ・ClosedAddressingとOpenAddressingの話 ・ClosedAddressingの場合、ポインタ使ってるからキャッシュミスあり。 メモリとかの話 ・OpenAddressingメモリに乗るのでキャッシュミスは少ないけど、削除データの扱いがちょっと大変 →削除がいっぱい有ると処理が面倒 ・RubyはClosedAddressing、PythonはOpenAddressing memcachedはClosedAddressing ・Cuckoo Hashing（2001） 密度50%以上になると急にコストが高くなる。 挿入がすごく遅くなる。追い出し操作が増えるから？ ・そこで、Hopscotch ググった参考ページ：http://shnya.jp/blog/?p=639 http://en.wikipedia.org/wiki/Hopscotch_hashing 密度が上がっても性能劣化がない。 ・C++でHashtableが欲しくなったら、google_sparse_hashとdense使うよと。 ・ConcurrentHashmapのお話 テーブル部分がvolatile、Chain部分はfinal insertはChainの先頭に。 削除は遅い。ReadCopyUpdate。 空でも1.7M（K？）持ってく ・ここからはLock-free系 ・Lock-Free Hash Table http://www.azulsystems.com/events/javaone_2007/2007_LockFreeHash.pdf HotSpot VMの人のもの？こんなのやってる。http://www.0xdata.com/faq.html ・（聞きそびれた） ・日立謹製Lock-free hashtable 日立のDBで使ってる部品？ ベンチマークが胡散臭い ・最後はJubatusのCM ◎文書要約入門 中級編(40分 + 質疑応答10分)　@hitoshi_ni ・画数が少ないです。 ・ヒカリエ綺麗ですね。 ・文書要約とは？ 「機械に」要約させる。 ・なんで要約？ 長い文章読みたくない。人件費の削減 ・どうやって要約？ 1.文分割：文書を文に分割 2.文短縮：就職説を削除するなどして、原文より短い文の亜種を出す。 3.重要文抽出：要約にふさわしい文を選び出す。 ・今回は文短縮について ・動機 長い文は文抽出で扱いにくい 文の中にも重要なところとそうでないとこがある ・係り受け木の剪定すると短くできると。 剪定のルール 中間ノードは落としちゃダメ 除去の時に考えること 重要度 言語 ・重要度？ 文節に点数を付ける 文書集合中の出現頻度とかを採用。訓練データからでもいいよ（ロジスティック回帰とか）。 ・言語尤度 言語としての尤もらしさ 典型的にn-gram言語モデルを使う ・そして探索 基本的には2値ラベリング ビタビアルゴリズムではだめ。係り受け制約が考慮できない ナイーブいはビームサーチをする。 ・文短縮の評価 ・人間が書いた短縮文と比較 ・ROUGE-Lという尺度などで評価（これしらないなぁ。） ・幾つかの論点 係り受け解析しない 文節じゃなくて、単語単位でもいいよねとか。 Q：硬い文章以外の要約ってやってるの？ A：あります。 技術的な話だと、係り受け解析がうまく出来ればできる。 係り受け解析がうまくいけば、そこまで大変じゃない。 Q：短さが短くなるほど難易度があがるけどどこまでやってます？ A：短くすればするほど難しい。これは情報の欠落が激しくなるから。 文法性を担保するのも難しい。 10文字くらいならできそう。 Q：実例としてどのくらいの長さをどのくらい短くしてる？ A：ある程度の長さを20文字にしてくれとか。Twitterに入るくらいにしてくれとか。 頂いちゃいました！ Emacs実践入門　～思考を直感的にコード化し、開発を加速する (WEB\u0026#43;DB PRESS plus) ","date":1354122000,"dir":"post/2012/","id":"e01e01d18582c7f69e1b0db7e1b111a0","lang":"ja","lastmod":1354122000,"permalink":"https://blog.johtani.info/blog/2012/11/29/dsirnlp-3-5%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Femacs%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80%E3%82%92%E9%A0%82%E3%81%84%E3%81%A1%E3%82%83%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-11-29T02:00:00+09:00","summary":"ヒカリエに行ってみたいという不純な理由で参加してきました。 新しいということもあり、おしゃれで綺麗なカフェでした。 入り口にはおっきな人形も立っ","tags":["勉強会"],"title":"#DSIRNLP 3.5に参加しました。＆「Emacs実践入門」を頂いちゃいました！(Jugemより移植)"},{"contents":"第9回Solr勉強会に参加しました。 皆勤賞です！というか、主催者になってしまいました。 まだ不定期の開催になると思いますが、話をされたい方などいらっしゃいましたら連絡いただければ助かります。\n今回も面白い話が聞けました。\n最初はKuromojiの開発者でSolrのコミッターでもあるChristianの発表です。 Solr勉強会では初の英語の発表だったんじゃないでしょうか。 Atilikaでやってることの紹介から、Kuromojiの紹介、今後の改良に関する話とひと通り話してもらいました。 途中でKuromoji使ってる人？などの質問があったのですが、残念ながら反応が薄かったです。 漢数字をアラビア数字でも検索できるようにするチケットなど、今後のKuromojiの発展も楽しみです。 （コメントとかパッチを送れというプレッシャーもあったので、パッチ頑張って書きます。。。）\nつぎはニコ生でのSolrのお話。結構、赤裸々（前任者がいない状態で引き取ったとか）に語っていただき、ハラハラしながら聞いてました。 やはり、新語や略語で苦労されてるんだなぁと。 複数のサービスや開発者に対してSolrの環境を提供するという話はなかなか興味深かったです。 いろんな人がSolrを触るような状況になってきてるんだなぁと。 基盤となるラッパーのようなフレームワークとかも作ってるのかなぁ？ 今後は台湾語や英語への展開も考えられているようなので、Language Detectionなどを利用してみた感想とその内容を今度発表してもらいたいですねｗ\nつぎはFacetPivotの話です。 昔から要望が出ていたのですが、4.0系でやっと使えるようになりました。 ファセットはSolrの売りの一つだと思います。 最初はこの考え方がしっくりこない人もいるかもなぁと。特にデータをどのように作れば、いいのかって悩むこともあります。 その悩んだ内容について発表してもらいました。 実際にどうやって使うかを悩んだ内容を発表してもらうのもいいなと思いました。\n最後はSolr勉強会なのに、elasticsearchの洗脳会になってましたｗ elasticsearchはSolrと同じ、Luceneをコアに採用した検索エンジンサーバーになります。 Solrとは別のアプローチでLuceneをラップし、REST APIでアクセスしやすくしたプロダクトです。 Luceneのコミッターの方もelasticsearchの開発に参加しています。 分散インデックスを念頭においた設計や、インストールが簡単なプラグイン構造といったSolrとは違ったアプローチがなされており、面白いものになっています。 残念ながら日本で利用されているという話はまだ聞いた事ないですが、だからこそ、触ってみて事例を紹介してみるのも面白いのではないでしょうか。 今回紹介したKuromojiも使えるようになっていたりしますので、日本語でもある程度使えると思います。\n以上が簡単ですが感想です。主催者だったのに、@hirotakasterさんや@ajiyoshiさんに受付などをやっていただいたので、いつもの様にしっかり話を聞いてしまいました。 発表者の方、会場提供いただいたVOYAGE GROUP、お手伝いいただいた皆さんに感謝です！\n今回初の主催でしたが、本当に助かりました。たどたどしい説明や紹介など至らない点も多々有ったかと思いますが、今後もよろしくお願いいたします。\n主催者的な立場として感じたことも書いておこうかと。 無料の勉強会で、ATNDという参加しやすい環境というのもあるかもしれないのですが、キャンセルをきちんとしていただくほうがいいなと思っています。 幸いにもSolr勉強会はここ数回は盛況で、キャンセル待ちの方が結構いらっしゃいます。 ギリギリまで業務との兼ね合いを見つつ、参加しようと思っていらっしゃる方もいると思うのですが、キャンセル待ちで行けるかな？どうかな？と思っている方もいらっしゃいます。 ドタキャンは問題ないのですが、キャンセルせずに欠席は出来れば避けていただけると助かるなぁと。 （残念ながら、きちんと集計をとれなかったので、次回からは集計取ってみようかなぁと）\n次回の開催は今のところ未定です。発表してみたい方、こんな話を聞いてみたいなど、気兼ねなく連絡いただければと思います。 このブログにコメントを頂いてもいいですし、ツイートしていただいてもいいので、反応をいただけると嬉しいです。 また、今回至らない点があったなどのツッコミ、批判も気兼ねなく言っていただければと思います。 今後の反省点にもしたいので、ぜひ反応をいただければと！\n懇親会でも色々な方とお話できました。（もう少し、Christianと英語で話す努力とかしないとなぁ。。。）\nとりあえず、メモをアップしときます。 リンクとか感想とかはまた（飲んだ）後で。。。\ntogetterでまとめてももらったみたいです。ありがたいです。\n第9回Solr勉強会 場所：VOYAGE GROUP 会議室 日時：11/26(月) 19:00～21:00 1. Atilika Inc.　Christian Moenさん タイトル：Who we are, what we do, and a little bit about Kuromoji ◎Atilikaの紹介。 会社の目指すもの ・BigData、検索、NLP ◎プロダクト Kuromoji：形態素解析エンジン Akahai：日本語クエリサジェストエンジン Keywords：日本語キーフレーズ抽出 ◎Kuromojiの紹介 3.6からデフォルトで使える。 ◎将来の改良の話。 ・踊り字対応（コミット済み） ・漢数字に関するチケット＆パッチのお話。 ・ユーザ辞書の重複エントリ改良とか（すみません、パッチ書きます。。。） 2. 株式会社ドワンゴ　吉村総一郎さん(@sifue) タイトル：Solr@ニコニコ生放送 ◎ニコニコ生放送の紹介 ・1日に10万番組。。。 ・10/17にバージョンQをリリースしたら、トップはひどい叩かれようでした。。。 ◎これまで。 Jackrabbit→Lucene→Solr→ニコ生のSolr ◎退職者と入れ替わりでSolr担当。。。 今回は資料と環境を調べて発掘した機能のお話。。。 ◎機能 キーワード検索。論理クエリ、などなど。 ◎利用してる環境 3.4ベース＋Jetty マスタスレーブ構成（スレーブ2台） 途中は分散インデックスを自分で実装？ ボトルネック自体がDBからのデータ収集だった ◎インデックス対象 ・見れるのは過去1週間と過去の公式番組すべて。 この部分だけ検索可能。 ・更新頻度の高い情報に「来場者数」「コメント数」 ◎インデックス作成 ・バッチにて更新 ◎アナライザ CJKTokenizerFactoryを利用 HTMLStripCharFilterFactory Bi-gramなので、「FF」とか「DQ」に弱い（FF1でFF13とかヒットしちゃう） 検索精度は悪いと言われてるみたい。 ◎1日のリクエスト ピーク時40QPS程度 5分おきにスパイクがある。（ユーザが作ったツールによる検索とか。。。） ◎UPDATEリクエスト ピーク時は80QPS ◎開発用のJettyのマルチテナント機能を利用したSolr環境の提供 ◎台湾語とか英語もやりたいなぁ。　3. 株式会社マーズフラッグ　柳吾朗さん(@hitode7456) タイトル：ドリルダウン色々 ◎Facetの紹介から ◎楽天でのドリルダウン例（これはFacetの紹介での例であり、実際にSolrが利用されているかはわからないです。） ◎多段ドリルダウン（ファセット）のお話。 アプリを実装するときの考え方とか。 ◎実直形、工夫形、PivotFacet Q\u0026amp;A Q：3つの性能系のコストは？ A：まだ調べてないです。残り2つは工夫形がいいですよ。と 次回、調べた結果の発表もやってほしいなぁ。 4. 兼山元太さん (@penguinana_) https://speakerdeck.com/penguinco/solrtoelasticsearchfalsebi-jiao タイトル：SolrとElasticsearchの比較 ◎クックパッド！ ◎elasticsearchの紹介 ◎比較サイトもあるよ！ http://solr-vs-elasticsearch.com ◎サンプルデータ・セット（ライブドアグルメ）でサンプル実装。 https://github.com/penguinco/ld_gourmet_search ◎APIの紹介 REST APIがちゃんと造られてますよと。 設計時点でコレクションなどがURLに含まれてるのがいいよねと。 ◎_analyzeによりアナライザーもAPIとして公開されてるよと。 ◎Kuromojiも対応してるよ！ ◎DynamicFieldよりも便利だよ。 ◎クエリのDSLが違うのでちょっとアレ。 ◎スコアリングも色々できるよ。 ◎感想 ・機能面の不足なし ・APIがいい コア追加とか、curlだけでできるのがいい。 ・習得が容易（Solrやってると機能とか似てる） ・大規模じゃなくても使えそう ◎分散検索がデザイン時に組み込まれてるのがいいよね。 write consistencyなどがインデックスごと（コレクションごと？）に設定可能なので便利。 ◎multi-tenant open/closeなどができる（時系列データとか） shard allocationなどの細かな制御も可能ですよと。 ◎plugin 色々プラグインがあるよ。管理画面もプラグインであります。 プラグインもコマンド一発で追加可能。 ◎クエリキャッシュがないので、自前でnginx、varnishなどでキャッシュが必要。 ","date":1353923040,"dir":"post/2012/","id":"7e23419e4fc69b5b533815681c9bb1a9","lang":"ja","lastmod":1353923040,"permalink":"https://blog.johtani.info/blog/2012/11/26/%E7%AC%AC9%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/","publishdate":"2012-11-26T18:44:00+09:00","summary":"第9回Solr勉強会に参加しました。 皆勤賞です！というか、主催者になってしまいました。 まだ不定期の開催になると思いますが、話をされたい方など","tags":["勉強会"],"title":"第9回Solr勉強会を主催しました。#SolrJP(Jugemより移植)"},{"contents":"初目黒（たぶん）で、初Amazonな感じで、流行りの「ビッグデータ」のセミナーに参加してきました。\nとりあえず、いつもの自分用のメモを残しておきます。 感想はまた後日。。。（たぶん、頑張れ私。。。）\nAWS ビッグデータ活用事例セミナー 日時：2012/11/09 [ 金 ] 9:30 - 12:00 場所：アマゾンデータサービスジャパン目黒オフィス ★AWSビッグデータ概要 @understeer　○Amazonの紹介 ○Amazon Web Serviceの紹介 ・オンプレミスと比べ、初期費投資が不要 ・コストダウンを促進 過去6年で21回の値下げを実施 ・IaaSだけじゃなく、PaaSもやってますよ。 ・OSより上の層は好きに選べるよ。 ○AWSのサービスだけで20ある。 ○3つのV Volume　2012年で1.2ZB。95%が非構造データ。今後も非構造データが増加 Velocity　デバイスの増加、パーソナライゼーション系の増加 Variaty 素粒子のデータの解析とか、地質学、気象予報とかいろいろやってるみたい。 ○BIG DATAの4つのプロセス。 収集、保存、分析、共有を繰り返しやりましょう。 そこで！AWS使いましょう。 ○収集 AWSへのデータアップロード オンプレにあるデータをAWS（S3）にアップロード ・インターネット経由 ・専用線サービス（AWS Direct Connect、1/10Gbps）も可能 ・AWS Import/Export（HDDを送りつけてS3にアップロードしてくれる。Tokyoリージョンにはだない） ・インターネットVPN経由も可能 ・EC2上のデータももちろんできる。 ※WAN高速化ソリューションも利用可能。 ○保存 ・AmazonS3 99.999999999%の耐久性。 同一リージョン内の3箇所以上のDCに自動複製 容量無制限で低コスト（1G 約10円/月） ・Amazon Glacier データの利用準備に3.5～4.5時間かかる。 S3の約1/10という低コスト ○分析　オンプレミスだと運用が大変。 ・Amazon EC2 スケールアップ/ダウン、アウト/インが即座に可能。ライセンス持ち込みや従量課金に対応 スペックの種類が豊富（SSDとかもあるよと） ・Elastic MapReduce Hadoopをサポートしたの仮想サーバが簡単に用意可能。 S3、Dynamoとの連携も可能 ディストリビューションも選択可能（Apache、MapR） 追加のアプリ（Hive、Pig、HBase）なども利用可能。 ジョブの大きさに合わせてクラスタサイズを適切にすることでコスパがよくなる。 →HadoopのMRのデータのローカリティとかはどうなってるんだろう？ ○共有 ・AWS RDS MySQL、Oracle、SQLServerをサポート（PostgreSQLはないのかな？） 自動バックアップ、フェイルオーバー、パッチ適用機能があるよ ・Amazon DynamoDB AmazonオリジナルなNoSQLデータベース。論文有るよ。 運用管理は気にしなくていい。 性能については客指定の性能が出せるようになる。しかも変えられるよと。 ※データサイズに応じて以下を選択しましょう RDS、HBase on EMR、DynamoDB、S3 他にもEC2上で、CassandraやmongoDB、GlusterFSを使ってる事例もありますよ。 ○以上を繰り返すのが意味があります。そこで！ ・Simple Queue Service マネージド分散キューサービス 最低1度のメッセージ到達の保証。複数DC間で複製保存 ・Simple Workflow Service 進捗などの管理も可能 NASAのCURIOSITYの制御に利用？10m前進するのに10時間のバッチ処理がある。。。 データがなくて試せない！そんなあなたに！ ○AWS Public Data Sets すぐ使えるPublic Dataが用意されてるよ。 http://aws.amazon.com/jp/publicdatasets/ ★AWSのビッグデータ事例紹介　@shot6 ○NETFLIX ・どんな会社？ 2500万人以上のストリーミング会員 500億以上のイベント ・AWSの利用は？（保存） 8TB/日のイベントデータを収集しS3に。 Cassandra上の顧客データもS3に。 1PB以上のデータがS3に保存。 ・AWSの利用は？（解析） EMRでレコメンデーション、アドホック分析、パーソナライゼーションなど。 本番クラスタ（ずっと動かしている） アドホック分析用クラスタ（必要に応じて構築） 解析用のアルゴリズムをAPIで叩けて、ジョブとして定義されてるらしい ・Cassandraを使ってるよ。 Cassandraのクラスタをマルチリージョンで対応したりもしてる。 CassandraのBackupもやってる。OSSで公開されてる？ ※HBaseのものもあるよ。 ※AWS上のCassandra事例もいくつか広告系で出てるみたい。 ・High I/O Instances for EC2（SSDのインスタンスまだ東京に無いらしい。） ・AWSスケールアウトだけでなく、スケールアップも徐々に増えています。 ○yelp ・どんな会社？ 口コミサイト。 スペルミスの自動修正、検索ワード自動補完、 ・AWSの利用は？ WebサイトのログをS3に保存。 EMRを利用してHadoopClusterで解析してS3に保存している。 EMRは処理終了後にシャットダウンしてる。 ・データ解析が日常になった ○SHAZAM ・どんな会社？ 広告配信、モバイル系の配信をやってる会社。 Super Bowlの広告配信でAWS、DynamoDBを利用。 ※マイネット・ジャパンでもDynamoDBを利用している ○CLIMATE Corporation ・どんな会社？ 天候保険の会社 ・AWSの利用は？ 200TBの地質、天候データを解析して ○THOMSON REUTERS ・どんな会社？ 情報提供の会社。データの提供が元だけど、解析した結果の情報も提供してるみたい。 ・AWSの利用は？ MarketScanという18年分の個人の医療データ（個人情報自体はないみたい）を販売する、販促ールとして利用。 1500万人分の患者データを提供。 マーケットの分析に使えるデータの提供。 KARMASPHEREとEMRの組み合わせで、ソリューションを提供していますよと。 ・事例 1.MarketScanをS3にアップロード。 2.分析官が、KARMASPHERE経由でEMRにアクセス。 3.EMRにS3からデータロードされ、結果がRDS（Oracle）に保存 4.RDSに他の人達もアクセスして使ってるよと。 ○RANGESPAN ・どんな会社？ ECサイト向けのPaaSサービスを提供してるロンドンの会社。 ・AWSの利用は？ NLP、機械学習にEMRを利用？ mongoDBのクラスタを構築してる。 ※mongoDBの日本の事例としてCAがあるらしい。 ★Huahin Framework活用事例 on AWS @ryu_kobayashi ○Cassandra本とかもやられてるみたい。 ○EMRとは PaaSなんだけど、中身を自分でいじれるらしい。 Management Consoleでは3つのバージョンが使えるが、コマンドラインからだと他にも使えるみい。 ・HBaseはAmazonのDistributionのものだけ。 ・EMRのメリットは？ インフラの面倒を見なくていい。 クラスタの立ち上げも複数あげられるので簡単。本番実行と同じ環境 ・EMRのデメリット オンプレミスにすでにデータがあるとアップロードが大変。実際に物理HDDを送ったこともある（2,3日でAWS上にアップロードされた） 外に出せないデータがあると。。。 ○EMRのTips（EMRの連載に載ってますよ！http://gihyo.jp/dev/serial/01/emr） ・Bootstrapを設定 EMRのクラスタの起動前にメモリ設定とかHadoopの設定が可能にできる。 ・ファイルサイズを適切に Map数=splitを決めるコード を指定することで、処理が早くできるのかな？ ○EMRの起動には いろいろあるけど、HuahinEManagerを使うと使いやすいよ？ ○Huahin Frameworkの構成 ・Huahinの名前の由来は？ 社内のコードはワインの産地にするという決まり。 タイの観光地Hua Hinがワインの産地。 ・他のHadoop関連のマスコットより可愛いでしょ！？ ・Huahin Core MRのプログラムを簡易化 WritableとかSecondary Sortとか書かなくていい 考え方がSQL寄り 素のMRも書ける。Pig、Hiveだとパフォーマンスが難しい Huahin UnitというMRUnitをラップしたものもある ・Huahin Tools 汎用的な処理を集めたツール群だけど、Apache Logの成形のみ。 オンプレミスHadoop、スタンドアロン環境でも動かせるようになってる。 ・Huahin Manager Jobを管理するマネージャ Jobの実行 キューを持ってるので、複数の実行が可能だよ。 EMR対応してる。bootstrapに設定するとできるらしい。 ・Huahin EManager EMRのいろいろが管理できるみたい。 初期設定20までしかインスタンスが挙げられない上限があるらしいので気をつけましょうと。 キュー登録のPOST機能は便利そうだ。（EMR触る機会まだまだないけど。。。） EMRにはJobのkillがない→Job FlowをターミネートすればOK→実際にはEMRのマスタノードにSSHすればできるよ。→めんどくさいよね。。。 EManagerなら可能ですよと。これは必須だよなぁ。 ","date":1352477220,"dir":"post/2012/","id":"98c640616f997a323af625e34ba34850","lang":"ja","lastmod":1352477220,"permalink":"https://blog.johtani.info/blog/2012/11/10/aws-%E3%83%93%E3%83%83%E3%82%B0%E3%83%87%E3%83%BC%E3%82%BF%E6%B4%BB%E7%94%A8%E4%BA%8B%E4%BE%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-jawsug/","publishdate":"2012-11-10T01:07:00+09:00","summary":"初目黒（たぶん）で、初Amazonな感じで、流行りの「ビッグデータ」のセミナーに参加してきました。 とりあえず、いつもの自分用のメモを残してお","tags":["勉強会"],"title":"AWS ビッグデータ活用事例セミナーに参加しました。#jawsug(Jugemより移植)"},{"contents":"##Lucene/Solr 4.0.0リリース ついに、Lucene/Solr4.0.0がリリースされました。 MLで流れていましたが、3年越しのリリースだったようです。 コミッターの方々、JIRAにバグ報告をした方々、お疲れ様でした。\nということで、ちょっと忙しくなりそうです。。。 4.0の機能を調べたりもしたいですし、すこしずつ紹介もしたいです。\n本家サイトのニュースはこちら\n##lucene-gosenの4.0対応版について lucene-gosenも4.0正式版のjarを利用したバージョンを公開する予定です。 branches/4xでは、すでに作業を行なっており、jarファイルの差し替えは終了しています。 お急ぎの方は、branches/4xをエクスポートして、ビルドしていただくと利用可能となっています。 なお、Lucene/Solrのバージョンが上がっているため、lucene-gosenのメジャーバージョンも変更し、lucene-gosen-4.0.0としてリリースする予定ですしました。。（順当に行けば、3.0.0ですが、Luceneのメジャーバージョンに合わせたほうがわかりやすいかと思いまして。） また、現在、trunkが3.6.x対応のソースになっていますが、このあと、現在のbranches/4xのソースをtrunkにする予定です。 3.6.x対応のlucene-gosenについては、branches/lucene-gosen-rel2.0にて作業を行うこととなります。 今後は注意してチェックアウトするようにお願いいたします。\nということで、ダウンロードできるようにしました。 lcuene-gosen-4.0.0*.jarとついているものがLucene/Solr 4.0.0に対応したライブラリになります。\n","date":1350031500,"dir":"post/2012/","id":"922cc71fd28b1dac8f407f1d517f5595","lang":"ja","lastmod":1350031500,"permalink":"https://blog.johtani.info/blog/2012/10/12/lucene-solr-4-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9lucene-gosen%E3%81%AE4-0%E5%AF%BE%E5%BF%9C/","publishdate":"2012-10-12T17:45:00+09:00","summary":"##Lucene/Solr 4.0.0リリース ついに、Lucene/Solr4.0.0がリリースされました。 MLで流れていましたが、3年越しのリリースだったようです。","tags":["lucene-gosen"],"title":"Lucene/Solr 4.0.0リリース＆lucene-gosenの4.0対応(Jugemより移植)"},{"contents":"このイベントにウチダスペクトラムの枠でMahoutのコミッターである、Grant Ingersollさんが講演されるということで、興味があったので聞いて来ました。 （この枠だけ）\nLucidWorks社が現在展開している、LucidWorks BigDataの概要とコンセプトといった話の内容でしょうか。 LucidWorks社（元Lucid Imagination）はLucene/Solrのコミッターの方々が多く在籍している会社です。 検索システムに関するノウハウを元に、発見や解析といった部分にニーズが広がってきているという話の ざっくりした概要のはなしでした。 検索システムを中核にして、ログや検索で提供しているデータの解析などの重要そうなポイントが散りばめられて いるお話でした。\nもっと詳しい話を聞きたいなぁ。\n講演では日本語の資料でしたが、サイトに英語の資料がアップされているとのことでした。 原文が読めるのは非常に助かります。他のイベントなどでもこのように英語の資料も見れるようになると嬉しいです。\n以下は、いつものメモになります。\n場所：富士ソフト　アキバプラザ5Fホール 日時：16:10- ◯サーチ技術による情報の可視化 通常、検索と言うとWebサーチだけど、ウチダスペクトラムのやっている部分はエンタープライズ向け ナイスガイ＝Grant S. Ingersollという紹介 ◯サーチからSDAへ LuceneやSolrのお陰で、検索自体は簡単になってきている。 ◯サーチの進化 ユーザとデータを結びつける意味での検索の進化が必要 ユーザインタラクションや、アクセスの方法とか ◯SDA Search, Discovery and Analytics ・ユーザからのニーズ 検索、優先順序付け、新たな気づき、フィードバックによる学習 ・ビジネスからのニーズ ナレッジの有効活用 ◯ユーザ事例 保険会社での請求に関する不正利用分析を含んだクレーム処理と分析 ◯事例：個人に最適化された医薬品 DNAをベースに検索やファセットで医薬品を検索したり。 ◯事例：通信会社における通話記録処理 ログを元に検索して、不正通話などを解析 ◯SDA基盤に必要な要素 高速で拡張性のある、検索 大規模でのコスト効率が高いストレージと処理 NLPとMLにより解析などが向上 ◯SDAのアーキテクチャ 基盤 LucidWorks Search、Hadoop、HBase、ApachePig、Mahout、 NLP、 管理 Zookeeper インフラ ZABBIX、AWS、Chef データの流し込み Twitterからのデータとか ◯検索部分にフォーカス ・LucidWorks Search SolrCloudによる簡単なshard処理 ・Hadoop ログ、生データ、中間ファイルの保存 WebHDFS 小さなファイルには向いていない ・HBase メトリック、ユーザ履歴などのストレージ 課題 どこに正式に保存する？ リアルタイム処理 vs バッチ処理 分析はどこで行われるべきか？ ◯検索の実装に関連すること 3つのポイント 性能と拡張性 関連性 オペレーション（モニタリング、フェイルオーバーなど） ビジネス側では検索結果の適合性を重要視する 開発側は性能を重視する傾向がある。 ◯適合性に関して テストが重要。 クエリ、クリック、表示したドキュメントなど、すべて保存すべき！ ◯Discoveryにフォーカス ◯MahoutによるDiscovery 3つのC ・協調フィルタリング ・クラシフィケーション ・クラスタリング 追加事項 課題 収束を伴う計算コストの高い機械学習アルゴリズム Mahout ◯余談：Experiment Management ◯Analyticsにフォーカス Rとか、うまく活用 検索エンジン自体でもできることがある。ファセット、TF、DF/IDF SearchとDiscoveryの定量化 ログ、ナビゲーション分析 ","date":1348650492,"dir":"post/2012/","id":"43501cdf0de25278a208cbb9aad80012","lang":"ja","lastmod":1348650492,"permalink":"https://blog.johtani.info/blog/2012/09/26/lucid%E3%81%AEgrant-ingersoll%E3%81%95%E3%82%93%E3%81%AE%E8%AC%9B%E6%BC%94%E3%82%92%E8%81%9E%E3%81%84%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-09-26T18:08:12+09:00","summary":"このイベントにウチダスペクトラムの枠でMahoutのコミッターである、Grant Ingersollさんが講演されるということで、興味があった","tags":["勉強会"],"title":"LucidのGrant Ingersollさんの講演を聞いてきました(Jugemより移植)"},{"contents":"PFIオープンセミナー2012に参加してきました。 対象から微妙に外れてたり、話の内容についていけるか自信がありませんでしたが、参加してきました。 PFIさんは前から面白そうなことやってる会社だなぁと思っていたので。\n面白い話がいっぱい聞けました。 電池が切れそうなので、とりあえず、まずはメモをアップしときます。 かろうじてついていけたという感じですが。 丸山先生の話はアーキテクチャの話に入る前のビッグデータの光と影の話がよかったです。 ビッグデータと言っても、まずは、サンプリングなどで小さなデータで処理できるかもしれないと考えるのも必要なのでは？という話や、相関があるからといって、因果が有るわけではないとか、おそらく、統計やってる人や、数学やってる人にしてみれば、当たり前の事なんでしょうが、その部分に警鐘を鳴らす話が聞けたのは良かったです。 もちろん、ビッグデータでなければ意味が無い解析などもありますという話もきちんと出ていました。\n伊藤さんの話は、Screwと呼ばれる、多言語解析基盤のお話です。その前にSedueの紹介で、SolrとSedueの比較の話も出ていました。（若干、強引な感じもしましたが。。。） 多言語解析基盤は、Solrでも少し入ってきています。ただ、それよりも汎用的な作りになるようなので、今後Solrと組み合わせて使うといったことも可能になるかもしれません。 まだ、対応言語などが少ないので今後に期待という感じでしょうか。 複数の言語が混ざった時の挙動がどうなるのかや、身近な文章での言語判定の正確さは少し気になります。\nサイバーセキュリティの話も面白かったのですが、話が多岐にわたるのと、スライドの情報量の多さに少しついていけませんでした。 資料が公開されたら、もう一度見直したいかなぁと。\n比戸さんの話は、Jubatusと関連のある話でした。機械学習の実際の利用の話が特に興味深かったです。 最近になって、ようやく、実際のデータを利用した話が出てきているみたいで、もっと事例が出てくると機械学習も身近になりそうだなぁと。\n最後は、日経BPの中田さんの話でした。これが、一番想像していたものと内容が違って、驚きつつ、楽しめた話でした。 ビッグデータというバズワードがいかにして生まれたのかがよく分かりました。 私は、バズワードだなぁと思う程度だったのですが、出てきた背景にある程度意味があるという考察に感心して聞き入ってしまいました。\nということで、思っていたよりも話の内容についていけたので、講演された方々の話しのされ方が良かっただと思います。\n少し無理をして参加してよかったと。\n残念だったのは、会場が地下だったため、携帯が入らなかったことでしょうか。 私はe-mobileで接続していたので大丈夫でしたが、docomoの携帯は圏外でした。 ツイートがもう少し盛り上がれば、もっと質問も出たのかもしれないです。\nhttp://preferred.jp/news/seminar/\n資料が公開されたので、リンクを貼っておきます。 PFIの方たちの資料へのリンク： http://preferred.jp/news/?id=1139\nゲスト講師の資料へのリンク： http://preferred.jp/news/?id=1159\n◯「多様化する情報を支える技術」　講師：西川徹（株式会社プリファードインフラストラクチャー　代表取締役） ・PFIの説明 VCに頼らない。製品につながるビジネスにこだわる（受託開発しない）、技術の多様性を重視 ・PFIの技術領域、ビジネス 製品開発（Sedue/Bazil/Jubatus）、自然言語処理、機械学習、分散システムなど ・”人”が生み出すデータと\u0026#34;機械\u0026#34;が生み出すデータ ビッグデータの発端はGoogleが元じゃないか？→最後の公演で解説があるよ 人：質が高いけど、量が少ない 機械：質は低いけど、量が多い ・検索システムについてのお話 社内の資料とか情報が、人によって、まちまちなデータの保存（形式、場所など）が実施されてしまう。 情報検索技術と大規模データ ・人のデータへ必要なアプローチ より検索システムを活用してもらうために、楽に整理できる仕組みなどをどう提供するか 質の高いデータなのに、形式的な共有しかできていないのはもったいない ・機械のデータへ必要なアプローチ 大量データと高度な解析が重要（CEPとか） デバイスが性能向上→流れてくるデータが大量に→蓄積するだけでも問題になってくる →蓄積したデータを扱うだけでも処理コストが高くなる 分析をオンライン化、ストリーム化すること→Jubatusで貯めずに高度な解析をしましょう。 Edge-Heavyになりつつある。　◯「ITアーキテクチャはどこへ向かうのか」 講師：丸山宏氏（統計数理研究所　副所長　モデリング研究系教授　工学博士） ・ビッグデータの光と影 「その数学が戦略を決める」という本がオススメ ・大量データでも、ランダムサンプリングでとければ、ビッグデータじゃなくてもいいよね。 もちろん、ランダムサンプリングだけじゃダメな場合もある。 ・Hadoopが解ける問題領域って少ないのでは。 ・TVを見る時間が長い人ほど、方言の使用率が高い 因果関係と相関関係の違いをきちんと理解しましょう。 ・データをきちんと理解して意思決定などをしたほうがいいよと。 ・つぎのアーキテクチャは何か？ ・コンピュータ・アーキテクチャの歴史 ConnetionMachine CM-1（1985） SPARC Transputer（CSPによる並列性、Occam） SymbolicsLispMachine Intelアーキテクチャの台頭により、アーキテクチャの研究が廃れてくる ・クラサバ、スマホ・クラウドなどのアーキテクチャの話 ・じゃあつぎは？ Edge-Heay Data＝スマホなどデータが保存される場所がEdgeになりつつある ビッグデータのほとんどが廃棄されるデータ ・Edge-Heavy Dataに特化したアーキテクチャとは？ 分散マッチング・プロトコル→サマリ情報を交換することで、絞り込みが可能 X=3とした場合、センサーとかなら、ピンポイントな値ではなく、範囲では。 分布表現を1stクラスオブジェクトとするプログラミング言語が必要では？ ・アーキテクチャの変節点を見極めよう QA： Q：スパースネス問題がランダムサンプリングやフィルタリングじゃ解けないんでは？ A：はい。ただ、その前にやることがあるはずですよねという注意喚起の意味での発表です。 価値に応じて、EdgeにあるデータをCenterに持ってくるという考え方が必要。 今は価値が見いだせないのなら、Centerにまで持ってこなくてもいいのでは。 ◯「グローバル化する情報処理」 講師：伊藤敬彦（株式会社プリファードインフラストラクチャー 研究開発部門　リサーチャー） ・Sedueの説明 NHKニュースなどで ・提供する機能 ・検索補助 レコメンド、サジェストなど ・レコメンド機能の紹介 ・Sedue/Solrの比較 サポート体制：開発チームがサポートしてくれる 安定性：GCがないのがいい 付加機能： 検索の完全性：接尾辞配列による検索 ・多言語処理の話 ・翻訳ではなく、任意の自然言語言語で動作・精度を向上させる処理の話。 ・背景 サービスのグローバル化、会社組織のグローバル化 ・複数言語を扱う場合の難しさ 多言語解析基盤Screwの開発。 1.必要な処理を順番に適用する 処理の順序は設定で。出力はJSONで。 例：言語同定、単語分割、単語正規化 →言語同定処理で 2.言語ごとに必要な処理を適用 ・疑問 ScrewはSolrとの組み合わせもできる？ 複数言語が混ざった文章の場合にどういう形で動作する？ 言語判定は独自実装？ ◯「BigData処理技術とサイバーセキュリティ」→題名変更されてた 講師：桑名栄二氏（NTTセキュアプラットフォーム研究所　所長） ・経歴 Jubatusプロジェクト立ち上げに参画 ・攻撃に関する話 原因のわかっていないケースが多い。 ・端末の初期設定のパスワードとかが狙われるケースも多い ・変化する攻撃、変化するシステム・サービス、変化するデータ ・マルウェアの分類にJubatus ・不正IPアドレスを機械学習して ・ABC 「あたりまえ」のことを「ばかみたいに」「ちゃんとやる」 ◯「先進ビッグデータ応用を支える機械学習に求められる新技術」 講師：比戸将平（株式会社プリファードインフラストラクチャー　研究開発部門　リサーチャー） ・ビッグデータ分析はより深い地検を得られるビッグデータ「解析」へ ・ビッグデータ分析プロセス Volume、Variety、Velocity 蓄積（NoSQL系）、分析（CEP）、両方やるのがHadoop ・分析から深い解析へ 予測、カテゴリ分類、レコメンド、異常検知　これを機械学習で解決する方向で ・機械学習を応用している例 クレジットカードの不正利用検知：FICO ネットワーク攻撃/侵入検出 Jeopardy!でクイズ王に勝利 医療診断支援 ・データ解析技術への過度な期待と現実とのギャップ いろいろできるみたいだけど、何が必要？ ・ビッグデータ処理系を使える人 ・データサイエンティスト ・機械学習ツール ・ビッグデータ処理系での機械学習への対応状況 Hadoop本体（YARN） MapReduce系（Mahout、AllReduce or Vowpal Wabbit、SystemML） 非MapReduce系（Spark） ・機械学習からビッグデータへの歩み寄り ベンチマーク性能への固執とか、応用との乖離を批判する論文もあるらしい。 ・機械学習の応用例 Machine Lerning for the New York City Power Grid[Rudin et al., TPAMI, 2012] 電力配電設備の障害予測・検知 実データを用いた例が今後増えていくのでは。 ・今後重要になる技術とPFIの取り組み ・データ解析の敷居を下げるためのトレーサビリティ 機械学習向けスクリプト言語は敷居が高い WekaやSPSSのようなアイコンベースのデータ処理プロセスの記述は前処理には強力だけど、機械学習とは相性が良くない 結果が見える化部分との統合が不十分。 ・Bazil Farm学習結果分析例 Tweet年齢推定、Tweet性別推定 ◯「“ビッグデータ”が話題になった理由」 講師：中田敦氏（株式会社日経BP社　記者） ・自己紹介 ・バズワードができるまで まずは、「クラウド」のバズワードの歴史 「バズワードはIT企業やThe Economist誌の煽りでなく一般企業の経営陣が納得すると生まれる」 ・なぜ経営者がビッグデータに興味を？ 「ザ・クオンツ」という書籍に金融業界のルールの変化が書かれてる。面白いよ。 Google/Amazonに対する警戒心から。 破壊的な新規産業者へ対抗して行かないといけない思うところからビッグデータが流行ってるのでは。 「買ってきたIT」は差別化要因にならないのでは？→自分で作ったITなら差別化できる。 ・競争力は自分で作るしか無い 日本のとある特殊事情 ITエンジニアの所属先が日米で割合がぜんぜん違う。米国はユーザ企業が75%、日本は25%くらい ・ビッグデータの次はなに？ 3次元プリンタがあれば、好きなモノが作れちゃう。＝消費地の近くで作成しちゃえば良くなるのでは。 ","date":1348214700,"dir":"post/2012/","id":"89abaa7f21cf788ce4744e3e61173291","lang":"ja","lastmod":1348214700,"permalink":"https://blog.johtani.info/blog/2012/09/21/pfi%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC2012%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pfiopen2012/","publishdate":"2012-09-21T17:05:00+09:00","summary":"PFIオープンセミナー2012に参加してきました。 対象から微妙に外れてたり、話の内容についていけるか自信がありませんでしたが、参加してきまし","tags":["勉強会"],"title":"PFIオープンセミナー2012に参加してきました。 #pfiopen2012(Jugemより移植)"},{"contents":"友人にお値打価格で購入したMac miniはMountain Lionにアップデートしてたのですが、手元のAirはまだアップデートしていませんでした。\n夏休み中にバックアップ＋アップデートをしてしまおうと思いMountain Lionにアップデートはしていたのですが、 本格的に触り始めると色々と動かないものがあったので、備忘録としてブログを書いておきます。 （まだ途中ですが。）\n###1.Eclipseが起動しない Java6が未インストール状態になったみたいで、Eclipseを起動すると、Java6をインストールしなさいと言われました。 で、私の記憶が確かなら、前はJavaコマンドを実行するとインストールされたんですが、ターミナルでjavaコマンドを実行するとjavaはすでにインストールされてる模様。。。 あれ？と思い、-versionを実行すると、JDK7u4と出るじゃないですか。 どうやら、Java7u4は別途入れてたものが残ってる模様。 さて、どーする？ということで、ツイートしたりぐぐってみて、「Java Preferences」なる設定用のアプリ？が有ることに気づき、とりあえず開いてみたらJava6ないからインストールしたら？と言われました。 結果オーライということで、インストール開始。 無事、インストールも終了。Eclipseも起動しました。（ただし、今度はMercurialのプラグインがPythonのライブラリが無いとエラーを出すことに） ###2.Xcodeが起動しない。 使ってはいないんですが、Javaの件を調べるのに、起動したらLionじゃないと駄目だよと。 ということで、Xcodeもインストールしなおし。 ###3. homebrewが動かない 1.で書いた方法で、Eclipse自体は起動したんですが、Mercurialのプラグインがエラーを吐き始めました。 で、見てみると、hgコマンドを実行しようとしてなんか、壊れていると。 で、hgコマンドってどうやってインストールしたか思い出さないまま、とりあえず、homebrewだっけ？と勘違いしたまま、「brew update」を実行したらエラーがでて、「brew install git」でしょ？って言われてしまいました。 コメントにもいただいていたように、Xcodeをインストールしたのだが、コマンドラインツールが入ってないというのが影響しているみたいです。。。 で、ググってみると、こんな情報が。[http://labs.torques.jp/2012/07/04/2830/](http://labs.torques.jp/2012/07/04/2830/) ただ、そこに有るようにPreferenceのダウンロードを開いてもなーんにも表示されません。 で、更にググってこちらの情報に。[http://qiita.com/items/9dd797f42e7bea674705](http://qiita.com/items/9dd797f42e7bea674705)（なんだか、TLで見かける人のお名前が！） AppleのDeveloperサイトからダウンロードかぁと思いつつダウンロード用のリンクを踏んだら、アカウント登録しろとのページが。。。 なかなか遠い道のりですね。。。 Appleのアカウント自体は持ってるので、Developerへの追加登録なんですが、日本語が文字化けしまくりの確認ページが出る始末。 もう、めんどくさいので、そのまま登録しちゃいました。 で、ダウンロードする前にもう一回XcodeのPreference見てみたらなんか、ダウンロードする候補が出てきてるじゃないですか！ 結局、XcodeのPereference画面からダウンロードすることにしました。 AppleのDeveloperに登録したからなのか、Xcodeのプロジェクトを作ろうとしてXcodeをきちんと起動したからなのかは結局わかっていません。。。 良くないよなぁ。（ご存知の方いたらコメントもらえると嬉しいです。） で、やっと「homebrew」を入れようかなぁと。 一応その前に「sudo brew update」ってやってみたらどうなる？と挑戦したら今度は動きました。 homebrewが何を判断してinstallでしょ？って言ってたのかもわかっていませんが、updateで良かったみたいです。 ついでに、upgradeもしときました。（こっちは後からインストールしたもののバージョンが上がってるものがあったら更新してくれるコマンドかなぁ？）\n###4. pipの更新 ただ、brewをupdateしても相変わらず、EclipseのMercurialのPluginはエラーを出してました。 で、ターミナルからhgコマンドを実行してみたら同じエラーが。まぁ、そうですよね。 エラーメッセージを頼りにこれまたググってみたら、同じ状況のひとがいました。[https://groups.google.com/forum/#!msg/mercurial-ja/MxY6lejLXxo/OgJA_knXV6cJ](https://groups.google.com/forum/#!msg/mercurial-ja/MxY6lejLXxo/OgJA_knXV6cJ)（ここにもTLでお世話になってる方のお名前が！！） で、書いてあるように「とりあえず pip install mercurial で解決しました. 」ということで、コマンドを実行して見ることに。 これが、また失敗します。。。（日頃の行いが悪い？？てか、日頃MBAをメンテできてないのが悪いのか。。。） そういえば、過去のMBAセットアップのメモを残してたなぁと思い出して「johtani mercurial」でググってみるとちゃんと[書いてある](http://johtani.jugem.jp/?eid=34)じゃないですかー（偉いぞ、自分） ということで、「sudo easy_install pip」でpipを更新してから「sudo pip install Mercurial」で無事、hgコマンドもインストールし直せました。 Eclipseを起動してもエラーが出ない。（まだbitbucketに接続確認まではできてないですが。。。眠さに勝てず寝てしまいました。） ","date":1346650440,"dir":"post/2012/","id":"7604edf307a5e96120606c8dda06458f","lang":"ja","lastmod":1346650440,"permalink":"https://blog.johtani.info/blog/2012/09/03/%E3%83%A1%E3%82%A4%E3%83%B3mba%E3%82%92mountain-lion%E3%81%AB%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88%E3%81%84%E3%82%8D%E3%81%84%E3%82%8D%E7%A2%BA%E8%AA%8D%E4%B8%AD/","publishdate":"2012-09-03T14:34:00+09:00","summary":"友人にお値打価格で購入したMac miniはMountain Lionにアップデートしてたのですが、手元のAirはまだアップデートしていませんで","tags":["備忘録"],"title":"メインMBAをMountain Lionにアップデート（いろいろ確認中）(Jugemより移植)"},{"contents":"興味をもちつつ、触っていない軟弱者ですが、興味があるので今回も話を聞きに行って来ました。\nまずは、作者古橋さんによるFluentdの魅力や次期バージョンのお話。 あいかわらずわかりやすいスライドで話もわかりやすくてよかったです。 どうしても実績という点を懸念事項として上げる人が多いというアンケートを元に、各社が使ってるし導入もしやすいですというお話。 ここまでしてもらってるのに触ってないなんてほんと申し訳ないです。。。\n次は楽天の方によるCloud Foundryのログの問題点解消のためのFluentd導入のお話。 EC2でもそうですが、ファイルが永続化されない？のでログが消えてしまうという問題があるので、 集約しましょうと。 いままでとは少し違う問題点からの話でした。\n次はドリコムの方（浴衣？甚平？でかっこ良く発表）のIDCをまたいだFluentdの活用と、Fluentd自体の監視などについてのお話。 実際にログが増殖して苦労された点を解決するために考えられた監視項目など、あとで見返したくなる資料でした。 実際に試行錯誤されたあとの話はやはりありがたいです。 あと、お子さんが可愛かったｗ\nつぎのCROOZの方のPCがWindowsだったため（？）プロジェクターに繋がらず、急遽QAタイム。 このあたりの@doryokujinの話のつなぎの旨さとかほんとすごいなぁと感心します。\nで、Macに乗り換えてCROOZの方の発表。 Fluentd＋TreasureDataのお話。少人数（というか一人？）でも簡単にログ収集の仕組みが作れて、しかも保存先のサーバを用意せずに簡単な解析もできるというお話。 これは、ちょっとやってみようと思う人（少なくとも、私はやろうと思った）が増えたんじゃないかなぁという発表でした。 スライドがなぜか最後のほうが見えなくなってしまったので、第３回でも発表されるということになってましたｗ 最後は新大阪から文字通り駆けつけた玉川さんのHBase本＋そのた今後の翻訳本の紹介。 つぎはHiveの本も出てくるみたいでした。 日本語の資料ってホント助かります。購入しないと翻訳本が出る機会もないみたいなので皆さん買ってくださいとのこと。 HBaseはまだ触りそうにないから９月に出るAWSの本でも買おうかなぁ。 あ、日本語で解説してあるSolrの本もあるので是非買ってください！\nその後は懇親会でした。今回もTL上でズケズケと私が勝手に絡んでいる方たちにリアルにお会いできたので楽しかったです。\n自分もフロントよりも、バックエンドに興味があるし、実際に運用されてる人の話が多く聞けるので次回も参加したいです。 それまでにどこかで触るかplugin作るかしないとなぁ。\nということで、以下はいつもの適当メモです。\n開催日時：2012/08/22 18:00 ～ 22:00 場所：グリー株式会社 14F セミナールームYosemite ◎「Fluentdの現在と未来」　Treasure Data, Inc.　古橋　貞之 (@frsyuki) ◯アンケートの内訳 ◯ドキュメント欲しい？ ※思ったより日本語のドキュメントじゃなくてもよさそうだった。 ◯loggingってなんでいるの？ いろいろな解析ってあるよね。 ◯ログの集約、保存、などの問題点について フォーマットが混在 集約するのもいろんなスクリプトが混在 ◯メリット ・プラグインアーキテクチャ in/outに合わせてプラグインが用意/開発可能 ・フォーマットがJSON アプリでの解析が楽 ・HA構成が可能 ◯実績がない？→ 誰が使ってる？ COOKPADとか、NHNとか ◯次期バージョンの構想 ・設定ファイルで色々とらくできるよ。 ・MessagePackのv5に対応 ・td-agent-lite などなど ◯QA Q：時刻にミリ秒を持つことは可能？ A：互換性も気になりますが、検討します。 Q：JSONで構造化が売りだが、Flumeとかはテキストだけど、テキスト A：ログのパース時にやるというスタンス。 Q：日本語ドキュメントがやっぱり欲しい。手伝います！ A：別ブランチで翻訳しながら公開して欲しいし、バラバラにやるよりいいので。 Q：Windowsでも動かしたいけど、cool.ioの移植とか考えてないですか。 A：次期で、fluentdのコアからはcool.ioを外す予定です。 ◎「Logging Infrastructure in PaaS by Fluentd」　Rakuten, Inc.　Yohei Sasaki (@yssk22), Waldemar Quevedo (@wallyqs) ◯Cloud Foundryの説明 ◯Cloud Foundryの問題点 解析しようにもログが消えてしまう。。。 なので、Fluentdでログを集める仕組みを作ったよと。 これかな？ https://github.com/rakutentech/dea/ ◎「Fluentdを優しく見守る監視事例」　株式会社ドリコム　外道父 ( @GedowFather ) ◯概要： Fluentdをより穏やかに安定稼働させるための監視項目と自動処理について。また，その実運用における障害例なども紹介したいと思います。 ◯目次 ◯動作環境 ・IDCもバラバラな環境のログを一箇所に集約。 グローバルなネットで、圧縮、暗号化し、VPN使ってない ・tailのプラグインを改良して利用 copy、flow counterを利用 forwardも改良 Flume OGとは比較にならないし、FlumeNGはOGと全然違うから論外だった。 ◯ローカル監視 ・monit使って監視してる。 ログを記録してるか、内容が正しいか td-agentが正しく起動してるか、Collectorに送っているか 重複起動してないかとか、起動してるかとか。 ※重複起動でログが増えてた（@mazgi濡れ衣事件） HDFSに送ってるか、保存されてるか ◯リモート監視 アラート/グラフ作成の集約 状態の可視化 Collectorのキャパシティ管理 Agentにキャパシティの心配はほぼないが、Collectorは足りなくなる可能性がある。 ◯野望 CollectorでAgentを把握したい ◯QA Q：圧縮はどうやって？ A：forwardを改造してやっている。 ◎QAタイム Q：秒間どのくらい出るの？ A；秒間8000メッセージくらいらしい。 Q：ハートビートの取りこぼしは？ A：案1：UDPじゃなくて、TCPにする。案２：TCP接続してたらハートビートのカウントとしてしまう。 Q：CollectorのCPUに影響があるのってなに？ A：ロックがCPUを食う＝ロックが影響→リクエスト量を減らす Q：Windows対応はいつ？（発生源がWindows） A：td-agent-liteをWindows対応にしたいと思ってる。 Q：F#の実装とかテストは？ A：性能値の測定までは行ってない。メッセージが送れたなぁくらい。 Q：設定のDSL化はv11ではなくなったの？ A：ホスト名は入れたい。設定はやっぱり設定だけにしたい（プログラムは入れたくない） プラグイン側がDSL対応してればDSLできるようなものは入れようかと思ってるが、 DSLは延期したい。 A（tagomoris）：DSL化したいパターンが幾つかに絞れるなぁと思ってて、それに合わせたプラグインをいくつか作ってるよー。 ◎「Fluentd \u0026amp; Treasure Data でこっそり始めるログ集計」　CROOZ 株式会社　池田 朋大（ @mikeda ） ◯概要： FluentdとTreasureDataプラットフォームを使って、1インフラエンジニアが勢いでログ集計システムを作ってみたお話です ◯アクセスログ、エラーログ、メールログ（試験中）を集めてる。 ◯TreasureData 500Gまで無料なのかー。 ◯ダマで入れてもばれないぞ！ ◯最後は心の目で見えるスライドでした。 ◎祝・O\u0026#39;Reilly HBase 訳本発売。訳者本人によるPR。　Sky株式会社 玉川 竜司　※ O\u0026#39;Reillyの新刊「HBase 」　http://www.oreilly.co.jp/books/9784873115665/ ◎懇親会 そうそう、ステッカーもらったのでアンケート書きましたｗ ","date":1345657200,"dir":"post/2012/","id":"775894425f5a7436f56fc5a3b4a2cfaa","lang":"ja","lastmod":1345657200,"permalink":"https://blog.johtani.info/blog/2012/08/23/fluentd-meetup-in-japan--2--fluentd-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-08-23T02:40:00+09:00","summary":"興味をもちつつ、触っていない軟弱者ですが、興味があるので今回も話を聞きに行って来ました。 まずは、作者古橋さんによるFluentdの魅力や次期","tags":["勉強会"],"title":"Fluentd meetup in Japan #2 #fluentd に参加しました。(Jugemより移植)"},{"contents":"またまた飲みに行って参加してきました。 今回は、Rails、iOSでのTwitter連携の話から、ツイート分析、クライアントアプリの開発の苦労？楽しい話と、 幅広い話題でこれまた面白かったです。\nRailsはあとで、もう一回資料＋ビデオがみたいかも。あと、発表者の方が言ってたけど他の言語の似たようなサンプルがあると面白いかも。（Solr入門みたいに同じ題材で違う言語のサンプルとか）\nツイート分析は、私の使い方とは異なる分析結果がちょっと意外でした。土日はあんまりツイートしないからなぁ。 利用時間帯とかは、他のSNS（Facebookとかmixiとか）の分析と比較してみると面白いのかも。 まぁ、深夜帯はそれほど利用は無いだろうけど。\nAttaccaは自社や自宅でコーディングするときに利用させてもらってます。 どうしても自分のお気に入りのリストを作ってそれを聞くので満足しちゃうんで、 他の人のお気に入りも一緒にシャッフルして再生とかできると面白いかもなぁ。 もう少し、他にも曲を発見したいんだけど、その導線がもう少しうまく行くと嬉しいかも。\nチャーハン諸島の話は開発者の原点みたいな話で面白かった。やっぱり、自分で作るの大事だよなぁと。 作りたいと思うものがあるのはいいことだし、実際作ってみないとわからないこともいっぱいありますよねぇ。 ただ、何か作ろうかなぁと思うものがあるのはちょっとうらやましいとも思いました。 なかなかサービスとか、ほしいものを作ろうと思うところまで行かないからなぁ。年取ったのかなぁ。\n懇親会では、いつものように@twtrfkさんと喋って、あと Lytroを触らせてもらいました！ 思ったよりも大きいのが第一印象。 ぱっと見で、何の変哲もないところがズームするところだったりと、インタフェースがちょっとおもしろかったです。 ピントが後から合わせられるということで、どうしても同じ構図になっちゃうのがなぁという話も聞けましたｗ けど、ちょっと欲しいかもなぁ。動くものを撮るとどんな感じなのかも聞くんだった。\n次回は9月中旬！らしいので、余力がありそうだったらまた遊びに行きます。\n日時：2012/08/01 19:00 ～ 21:00 場所：デジタルハリウッド東京本校 1Fセミナールーム\nいつもの自己紹介タイム\n@i7a16k(@_gifteeの中の人)　スライドはこちら\n「RailsでTwitter連携アプリをサクっと作る」 ・まずは、Railsの紹介 MVC+routes.rbの紹介 ・Dev Twitterの登録する必要なとことか。 ・Railsのインストールから起動まで。 ・実際にログイン画面を作成するまでの紹介 コーディングするコマンドの紹介。動画付き omniauth_twitter ってのを使うみたい。 ・サインイン、サインアウトまで。 ツイートは次回！ 録画がよくできてて、それに合わせてしゃべるのもうまいなぁ。 @teapipin(ツイッター分析シリーズ の方)　スライドはこちら\n「約173万ツイートを調査して分かったTwitterの利用動向」 ・ハンドル名は午後の紅茶からきてる？＋ピピン＠ ・ブログで色々公開してます。 ・サービス作るのに、下調べをしてみましたというお話 情報が無かったから、自分で調べてみたよと。（すばらしい） ・Streaming APIで取得 タイムゾーンとか言語設定の取得でもうまく取れない。。。 ということで、UnicodeBlockで判定してみたけど、、、 最後は手作業で不要データを除去（すごい！） ・4日間で172万ツイート （金環日食とかスカイツリーのイベントがあったので、4日間で我慢） ・上位5個で50%を占めるクライアントみたい ・日曜日が多いらしい ・携帯が60%くらい ・位置情報（Geoタグつき） 日本が多い。4sqが40%占めてる。 店舗情報や天気情報などもあるらしい。 人口と関係した相関が散布図でわかった。 そこで、ツイート内容との関係を分析 あとで資料みたいなー @i2key(#attacca の関係者)　スライドはこちら\n「iOSのTwitterFrameworkを使ってみたら・・・・」 ・Twitter4Jのほうが楽だったよー デモがいいね！ ・アーキテクチャ play!をバックエンド。Amazonとか。 iOS Twitter framework ・Reverse Authの使い方とか。 申請してから、20日間かかった。 @Mocel(チャーハン諸島 開発者)　スライドはこちら\n「(仮)Twitter クライアントの開発とかについて」 ・趣味プログラマー ・「ラーメン大陸」のクローン：「チャーハン諸島」を開発 Excel溶けこむGUI Javaで実装 コマンドライン風のTL画面もある（自分では使ってないけど） 「電力会社の電力使用量モニター」もクライアント初搭載！ ラーメン大陸のバージョンチェックも可能ｗ ・開発したことで 自分のニーズにジャストフィット 優しい気持ちになれる（苦労がわかる） Twitter APIのテストとかもすぐ試せる ・GUIアプリ開発のノウハウも手に入るからオススメ ・API利用規約は読んどこうね ・自動アップデート機能がいるよ。→バージョンごとのサポートがなくなるよ。 ・通信エラー前提で作りましょう ・鍵付きの非公式RTはやめなさい。 ・Twitterクライアントの作成はおもしろいよ！ 反応がプレッシャーになることもあるけど。 おもしろ機能をつけるのがいいよーと 話が上手で聞きやすかった。 ","date":1343875800,"dir":"post/2012/","id":"8a29f62d1bebfe7b8008d7f264b56b4e","lang":"ja","lastmod":1343875800,"permalink":"https://blog.johtani.info/blog/2012/08/02/twitter-%E5%8B%89%E5%BC%B7%E4%BC%9A--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-08-02T11:50:00+09:00","summary":"またまた飲みに行って参加してきました。 今回は、Rails、iOSでのTwitter連携の話から、ツイート分析、クライアントアプリの開発の苦労","tags":["勉強会"],"title":"Twitter 勉強会 #twtr_hack に参加しました。(Jugemより移植)"},{"contents":"ということで、ステッカー欲しさ？に勉強中の話を恥ずかしげもなく偉そうにしゃべってきました。 #pyfesは以前から、気になっていたんですが、タイミングがあわず初の参加になりました。 TwitterのプロフィールにSenseiDBに興味あると書いていたら、@voluntusさんに声をかけていただけて、 さらになぜかelasticsearchの話をすることにして話をしてきました。 まだまだ、いろんな意味（プレゼン的にも内容的にも）で至らない所だらけだったので反省しまくりですが、 これでまた経験値が稼げたかなと。次回に活かしたいと思いますです。 やっぱり、しっかり勉強して、シナリオを練ってから発表しないとダメですね。。。\n発表のスライドは一番最後にリンクを用意しておきましたので、興味があれば見てもらえればと思います。\nということで、いつものメモを残しておきます。\n日時：日本オラクル青山センター 場所：2012/07/28 10:00 - 20:00 概要：こちらにページあり\n前半（10時から15時）はハンズオンなどをやられてました。参加せずにスライドを微調整して、他の勉強会のスライドをいじったりしてました。 以下は、15時から行われたスライドのメモになります。\n◯PyConJP の宣伝　@shomah4a（LT） 9/15-17 PythonカンファレンスJapan App Engine、Django、Sphinxなどのカンファレンスも併設 遠方参加者支援制度があるらしい。 ◯elasticsearch 入門　@johtani わかりにくい話でしたかねぇ。。。 ◯たのしいうぇっぶくろーら　@tokoroten（LT） index.htmlをクロールしまくってる社畜2.0の人らしい。 ◯Sphinxを使って翻訳してたら本が出てた話　@ymotongpoo（LT） OSSでもドキュメント翻訳でお手伝いできるよ。 そしたら、いつのまにか書籍も出せたよ。 スライド\n◯iOS関連のお話　@Seasons バイナリ解析をしてゴニョゴニョする話。 解析するのに何を使ったとか思考の遷移を説明してくれるのでわかりやすい。 スライドが大きなマインドマップを切り出した形。 ◯HBaseのお話　@shiumachi HBase 分散DB 列ファミリ思考 HBaseなんで？ RDB→シャーディング→だるい。。。 シャーディング→スケールできねー nandeHBase？ 書き込みスケールできるよ。 KVS HBaseのデータ構造 キーがいろいろな情報を含んでる キーがソートされてる HBaseのテーブル構造 リージョンがシャーディングの情報もと？ リージョン見つけなど スライド\n◯PythonではじめるGit　@mkouhei GitPython LXCホスト？ GitもPythonも初心者だわー ◯勉強会を成長させる参加者になろう　@sawonya イラストレーター（スタートアップRubyのイラスト書いた人。サインもらいましたｗ）。 参加者が増えるとなにがいいの？など。 勉強会参加に向けた勉強会の講師とかやられてるらしい。 スライド\n◯IT 系勉強会ネタ(仮)　@tmmkr アジャイルサムライを読んだ情報を共有したくなって読書会を開催してみた！ ビアバッシュのケータリングとかは楽天デリバリーとか、カクヤスがいいよ。 かなり、いいスライドなので、あとで見返す。 今、読書会やったりしてるし、Solr勉強会の役にも立てそうだし。 スライド\n◯Do not invent your RNG...　@kenji_rikitake Androidの乱数のコードがすごいらしい（ひどい） Pythonの乱数ではos.urandomを使うのが安全です。 オレオレ乱数は作っちゃ駄目！ ◯分散ファイルシステム（LeoFS）　@yosukehara LeoFSの開発者の方。 Erlangで98%書いてある。 Masterノードは存在しない。SPOFになるから。 分散システムとして元にした概念とか論文ってあるんだろうか？ ◯継続的デリバリー　@troter CIとデリバリーの話。 いいこと書いてあるんだけど、実際のツールの話しがないのが辛いこともある ということで、Python周りのツールをこうして見たよというお話。 Rubyの方がものがいろいろ揃ってるらしい ◯クライアントサイドのみで作ったダッシュボード　@takufukushima RESTアクセス用のUIのフロントエンドの話？ JSのお話の？node.jsとかの話。 MVCにしたり、CSSフレームワーク使ったり。 backbone.jsつかってるらしい。 実際の画面がみたいなぁ。 現状の話なので、 ◯Meinheld　@mopemope Python3対応とかLoggerとかやってから秋くらいに出るみたい。 このあたりは未知の領域です。。。 ◯3分間で開発環境構築 @tk0miya Vagrant＋Chefみたい。 VeeWeeってのでIOSイメージからVMイメージを作ってくれる。 （githubから持ってこないといろいろ古いらしい） これ、重要だと思う。 実践するようにしよう。 手順書がわりにChefのレシピを書こうよと。 環境マニア募集中！ 継続的デリバリー座談会やってます ◯筋トレ講座　@hiroki_niinuma ジムに通い続けるのはキツイ。 成功率5% 以下の条件に ・10時間以下の仕事時間 ・ジムが近い ・ジムという環境が好き ベンチマークｗ先入観を捨てましょうとｗ ジムで筋トレとかよりも歩くのが全然いいよと。 togetterがあったのでリンク。 http://togetter.com/li/346242 http://togetter.com/li/346270\nスライドはこちら。\n** [Elasticsearch入門 pyfes 201207](http://www.slideshare.net/JunOhtani/elasticsearch-pyfes-201207) ** from **[Jun Ohtani](http://www.slideshare.net/JunOhtani)** それにしても発表するといういい機会を与えてもらえて良かったです！。 継続的にelasticsearchも調べていきたいので、興味ある人は声をかけてくださいー\n","date":1343466900,"dir":"post/2012/","id":"7fa2f0877831b4c924438396760f1841","lang":"ja","lastmod":1343466900,"permalink":"https://blog.johtani.info/blog/2012/07/28/python-developers-festa-2012-07%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%97%E3%82%83%E3%81%B9%E3%81%A3%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pyfes/","publishdate":"2012-07-28T18:15:00+09:00","summary":"ということで、ステッカー欲しさ？に勉強中の話を恥ずかしげもなく偉そうにしゃべってきました。 #pyfesは以前から、気になっていたんですが、タ","tags":["勉強会"],"title":"Python Developers Festa 2012.07に参加してしゃべってきました #pyfes(Jugemより移植)"},{"contents":"今日はSolr 4.0 ALPHAの興味深い機能があったので紹介です。 数日前に「Solr 4.0: Partial documents update」という記事を見つけました。\nSolrには、ドキュメント（RDBで言うレコード）のデータを更新したい場合には、特定のフィールドだけを更新するという機能がありませんでした。 ですので、特定の項目（例えば、priceなど）を更新したい場合、ドキュメントの全データをSolrに再度上書き登録するという処理をしなければなりませんでした。 RDBを触っていた方が、Solrを始めた場合に必ず使いづらいと思われる点だと思います。\nで、4.0でその機能がありますという、「Solr 4.0: Partial documents update」の記事を見つけました。 ただ、SolrのWikiや4.0 ALPHAの紹介のページには「partial update」という記述が見当たりません。 （あれ、これかな？Update semantics） あと、まだ完成していないので、載っていないのかもしれないです。（このチケットSOLR-139が部分更新に関するもののはず。チケット番号をみても古くから望まれている機能だということがわかります。）\nということで、調べてみました。\n###機能概要\nSolrの機能として、特定のフィールドのみを更新するという機能です。 あくまでも、Solrレベルでの機能となり、Luceneの機能を利用したものではありません。 つぎのような流れになっています。\nSolrに対して特定フィールドを更新したいという形のドキュメントを投げる Solrはドキュメントを受け取ると、内部のインデックスに保存してあるデータを取り出す 取り出したドキュメントオブジェクトに対して、更新対象フィールドの値だけデータを更新する ドキュメントオブジェクトをインデックスに保存する このような流れです。 まぁ、言われてみれば当たり前な処理です。 ただし、この機能を使う場合はいくつかの前提条件があります。\n###前提条件\n前提条件はつぎのとおりです。\nすべてのフィールドをstored=\u0026ldquo;true\u0026quot;にする 「version」という特殊なフィールドを用意する 1点目は、データの保存方法についてです。 先ほど流れに書きましたが、Solrが内部に保存してあるデータを取り出して、更新対象以外のデータを保存しなおしてくれます。 このため、stored=\u0026ldquo;true\u0026quot;にしておかないと、元のデータがSolr内部で取得できません。\n2点目の「version」というフィールドは4.0から導入されたフィールドです。 SolrCloudに必要な機能としてドキュメントのバージョン管理を行うために導入されたフィールドだと思います。（あまり詳しく調べていない。。。） SolrCloud内でレプリカの更新などに使ってるのかなぁと（そのうち調べます。） 以上の2点が前提条件です。すべてのデータをstored=\u0026ldquo;true\u0026quot;としなければならない点は、インデックスのサイズや性能に関わってくるので考えて利用するほうがいいかと思います。\n###利用方法\nSolrのサンプルデータ（exampledocs/mem.xml）を例として利用します。 部分更新を行うにはつぎのような形のデータを投げると部分更新が可能です。 （JSONでの更新のサンプルについては、こちらの記事を参考にしてください。） ####XMLのサンプル（partial_update.xmlというファイルで保存する）\n\u0026lt;add\u0026amp;gt; \u0026lt;doc\u0026amp;gt; \u0026lt;field name=\u0026#34;id\u0026#34;\u0026amp;gt;VS1GB400C3\u0026lt;/field\u0026amp;gt; \u0026lt;field name=\u0026#34;_version_\u0026#34;\u0026amp;gt;バージョン番号\u0026lt;/field\u0026amp;gt; \u0026lt;field name=\u0026#34;cat\u0026#34; update=\u0026#34;add\u0026#34;\u0026amp;gt;cats_and_dogs\u0026lt;/field\u0026amp;gt; \u0026lt;field name=\u0026#34;popularity\u0026#34; update=\u0026#34;inc\u0026#34;\u0026amp;gt;10\u0026lt;/field\u0026amp;gt; \u0026lt;!-- set empty for SOLR-3502 bug --\u0026amp;gt; \u0026lt;field name=\u0026#34;price_c\u0026#34; update=\u0026#34;set\u0026#34;\u0026amp;gt;0.0,USD\u0026lt;/field\u0026amp;gt; \u0026lt;/doc\u0026amp;gt; \u0026lt;/add\u0026amp;gt; 上記サンプルのうち、バージョン番号の部分は、現在Solrに登録してある値を指定します。（Solrの管理画面で検索すれば表示されます。） 上記ファイルを「SOLR_HOME/example/exampledocs」に保存し、同フォルダにてつぎのコマンドを実行すると、部分更新されるのがわかります。 Solrに更新であるというフィールドがわかるように、fieldタグにupdateという属性を指定してあります。\njava -Durl=http://localhost:8983/solr/update?versions=on -Dout=yes -jar post.jar partial_update.xml ちなみに、上記post.jarのオプションで、「-Durl」「-Dout」を追加してあります。 「-Durl」はverions=onというパラメータを追加したいためです。 「-Dout」はPOSTした結果をターミナルに表示するために追加しています。 これらのオプションを指定すると、データ更新後のバージョンが取得できるようになります。\n####更新に利用できるコマンド？ 部分更新にはつぎの3つのコマンド？（正式名は不明）が用意されています。fieldタグのupdate属性に指定します。\nコマンド？ 説明 add 値を追加します。multiValuedのフィールドでない場合はエラーが出ます。 set 値を新規に登録しなおします。現在入っているデータは無くなります inc 指定された数値を加算（数値形式のみ） 以上が、部分更新の機能になります。 ちなみに、登録されているバージョンと更新データに入っているバージョンが異なる場合はエラーが発生する仕組みになっているようです。 それとは別に、この機能を調べていて、copyFieldのバグにぶつかってしまいました。。。 multiValuedでない、copyFieldを利用しているしている場合には注意が必要です。\n###copyFieldのバグ（SOLR-3502）\n4.0-ALPHA（3.6.0でも再現しました。）のexampleのデータで部分更新の機能を確認できると言いました。 ただし、「price_c」というフィールドのせいで、2回部分更新を行うと2回目にエラーが発生します。 根本的な問題は、部分更新ではなくcopyFieldのバグのようです。（部分更新の処理にも問題は有るような気がしますが。。。）\nバグの内容はつぎのとおりです。\nmultiValued=\u0026ldquo;false\u0026quot;のフィールドをdestに指定 srcに指定されたフィールドに値を設定（exampleのpriceフィールドに「1」を指定） destに指定されたフィールドに値を設定（exampleのprice_cフィールドに「2,USD」を指定） 上記のように設定した場合、「price_c」フィールドに、指定された値＋「price」の値がcopyにより追加されます。 通常は「price_c」フィールドはmultiValued=\u0026ldquo;false\u0026quot;なのでエラーが出るはずなのですが、エラーが発生せず2つの値が登録されてしまいます。\nこのバグのため、exampleのデータを利用して部分更新を行うとつぎのような状態が発生します。 更新を行う対象のデータはprice、price_cフィールド以外のフィールドとします。\n1回目の登録後：priceフィールド「\u0026ldquo;185.0\u0026rdquo;」、price_cフィールド「\u0026ldquo;185.0,USD\u0026rdquo;」 2回目の登録後：priceフィールド「\u0026ldquo;185.0\u0026rdquo;」、price_cフィールド「[\u0026ldquo;185.0,USD\u0026rdquo;,\u0026ldquo;185.0,USD\u0026rdquo;]」 3回目の登録：エラーが発生 部分更新の処理で、すでに登録済みのデータをSolrが自動で取り出すため、2回目の登録処理にて「price_c」の登録済みの値がSolrから取り出され、さらにcopyField設定により、「price」の値が追加されます。 本当は2回目の登録でエラーが発生すべきなのですが、バグのためエラーが発生せずに登録できてしまいます。 部分更新の処理としては、copyフィールドのdestに指定されているフィールドの値を取り出さないほうがいいような気もしますが、きちんと考えてないのでなんとも言えないです。（制約事項とする形のほうがいいかもしれません）\n","date":1342177320,"dir":"post/2012/","id":"68a8f34c240a42ab521d2f885f7aa33c","lang":"ja","lastmod":1342177320,"permalink":"https://blog.johtani.info/blog/2012/07/13/partial-update%E3%81%A8copyfield%E3%81%AE%E3%83%90%E3%82%B0solr-4-0-alpha/","publishdate":"2012-07-13T20:02:00+09:00","summary":"今日はSolr 4.0 ALPHAの興味深い機能があったので紹介です。 数日前に「Solr 4.0: Partial documents update」という記事を見つけました。 Solrには、","tags":["solr"],"title":"Partial UpdateとcopyFieldのバグ【Solr 4.0 ALPHA】(Jugemより移植)"},{"contents":" Modern Information Retrieval: The Concepts and Technology behind Search (2nd Edition) (ACM Press Books) いやぁ、蒸し暑くてなかなか寝れない日がはじまりましたね。（あんまり関係ないですね。。。）\nModern Information Retrieval 2nd Editionを輪読会という形で読み始めました。 Solrに関わって数年ですが、昔から検索をやっていたわけではありません。 なので、そろそろ基礎的、理論的なところも勉強して行かないとなと思い、この本を買いました。 ただ、約1000ページある英語の本でして。。。 一人で読むと間違いなく挫折するし、理解不能になりそうだなと。。。\nということで、Twitterで呟いたら賛同してくれる方が現れ、輪読会を開催することにしました。 イベントの開催とか初めてなので、手さぐりしながらです。（それにしても、ほんと、Twitterは素晴らしい。賛同してもらえる人が見つかったのもTwitterのおかげだし。）\nさすがに細かく読んでいくと終わらなそうなので、１周目（できれば、２周目もやりたいなぁと思ってる。１週目が１年でも終わりそうにない感じだけど）は公開されているスライドを元に進めようと思ってます。 それにしても検索周りはいろんな技術が必要なのだなぁと分厚い書籍を見て、途方に暮れつつ、楽しみでもあるなと思いながら、輪読会後の飲みを楽しんでましたｗ\nということで、各分野の専門家もいそうなので、特別ゲストとして読んできて話に混ざってもらうのも面白いかもと夢想しつつブログを書いています。 だれかいないかなーｗ\n参考URL： 書籍のHPで公開されているスライドのページです。 http://grupoweb.upf.es/WRG/mir2ed/contents.php\n","date":1342111298,"dir":"post/2012/","id":"9ac7bb94e60dc30a023ce433de027364","lang":"ja","lastmod":1342111298,"permalink":"https://blog.johtani.info/blog/2012/07/13/mir%E8%BC%AA%E8%AA%AD%E4%BC%9A%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-07-13T01:41:38+09:00","summary":"Modern Information Retrieval: The Concepts and Technology behind Search (2nd Edition) (ACM Press Books) いやぁ、蒸し暑くてなかなか寝れない日がはじまりましたね。（あんまり関係ないですね。。。） Modern Information Retrieval 2nd Editionを","tags":["勉強会"],"title":"MIR輪読会始めました(Jugemより移植)"},{"contents":"Lucene/Solrの4.0.0-ALPHAが7/3にリリースされました。\nこれに伴い、lucene-goenの4xブランチのjarファイルも4.0-ALPHAのものに置き換え、現在のtrunkの修正もマージしました。 こちらにあります。チェックアウトしてビルドしてから利用してください。\n※さすがに、jarをダウンロードできるようにすべきかもなぁ。 あと、Maven登録も。。。\n","date":1341457909,"dir":"post/2012/","id":"dcc2e24df32287e89ee3b0f64d617f57","lang":"ja","lastmod":1341457909,"permalink":"https://blog.johtani.info/blog/2012/07/05/lucene-gosen%E3%81%AElucene-solr4-0-alpha%E5%AF%BE%E5%BF%9C/","publishdate":"2012-07-05T12:11:49+09:00","summary":"Lucene/Solrの4.0.0-ALPHAが7/3にリリースされました。 これに伴い、lucene-goenの4xブランチのjarファイル","tags":["lucene-gosen"],"title":"lucene-gosenのLucene/Solr4.0-ALPHA対応(Jugemより移植)"},{"contents":"またまた参加しました。いまだ皆勤賞です。 感想などはあとで。とりあえず、メモとったので第一弾です。\nということで、感想です。 まずは、参加人数。 今回は今までで一番、ATND登録した人が多かったんじゃないかなぁと。 埋まるのも早かったですし。やっとSolrというキーワードが多くの方に触れられるようになってきたんですかねぇ。\nmixiの事例はやはり、SSDを使った11億文書のインデックスが圧巻です。 実際にマイニングに利用していて、ネガポジ分析なども行われているようで楽しそう。 TLにもありましたが、「ヤバイ」はネガ？ポジ？など、そのへんの分析方法をもう少し詳しく聞いてみたい感じもしました。 あとは、Luceneソースコードリーディングの開催が楽しみです！（候補日知らせないと。。。）\nLucene Revolution 2012の参加レポートは、自己紹介がおもしろかったですｗ ずっと検索をやらてているのもあり、色々と理論ではなく、実践的なノウハウを持っていそうで、つぎはそのあたりの話を聞いてみるのも面白そうです（発表してくれないかなーｗ） 残念ながら、私はまだスライドを見ていないので、事例を中心にピックアップして見てみようかなぁと（時間がトレない。。。）\n最後は阿部さんの4.0の紹介です。タイムリーに、前日に4.0-ALPHAがリリースされたので、 資料がすごく参考になりそうです。 SolrCloudについても詳しく書かれてたし。（ちゃんと動くのかなぁ？）\n最後は懇親会です。最近知り合った方から、発表者、昔からの勉強会の参加者といろいろな方と今回も話ができて楽しかったです。 TL上で知り合った方にもお会いできたし。 次回もしゃべってもらえそうな人を捕まえつつあるので、また企画してもらうようにつついてみようかな。\n※そういえば、毎度のことながら4.0ベースで、書籍は出さないのかって言われましたｗ\n※ちなみに、4.0-ALPHAが出たので、lucene-gosenも4xブランチの更新作業をしています。 終わったらまたブログに書くと思います。\n第8回Solr勉強会 場所：VOYAGE GROUP 会議室 日時：7/4(水)　19:00 ～ 1. ＠haruyamaさん mixi での Solr の利用 ・mixiの全文検索 2011年以前：Hyper Etraier、Tokyo Dystopia、Senna 2011年以降：Solrを利用して新規案件の検索システムの構築、入れ替えを行なっている。 ・Anuenueの論理構成など。 ・物理構成 1マスター、2スレーブ インデックスが小さい、QPSが100以下 インデックスサイズが大きいものは今後構築予定 ・今後やりたいこと ・ログ分析 ・パーソナライズ ・外部ストレージ参照のカスタム関数 ・外部ストレージをファンクションカスタム関数クエリ FunctionQueryを活用したい。 ・上記のデモ（検討中のもの？） 現在はjar内部のファイルを読んでるよと。 速度的な面がどうなるかがきになるところ。 ・テキストマイニング mixiボイス haruyamaさん入社前：ダンプして解析してた haruyamaさん入社後：Solrに載せちゃえば 600GのSSD　約11億文書 約450GB 利用してるもの：Solr 4.0（2012/01） lucene-gosen 1.2.1 自作フィルタ haruyama/solr-filter - GitHub ・利用統計の説明。 女性が多い。 「AKB」だと20代前半が多い。男性はおっさんも頑張ってる。 ・mergeindex機能を利用して、過去データとマージしてる。 1日分だけ集計したいこともあるかもしれないから。 updateじゃなくて、mergeindexなのは、ソッチのほうが早かったから。 ・拡張してる分析 ・ポジネガ分析 形容詞＞絵文字＞顔文字でスコアが効く 機械学習して辞書を調整してる ・Luceneソースコードリーディングまたやりますよ！ 2. 楽天株式会社 大須賀 稔さん Lucene Revolution 2012 in Boston参加レポート(仮) ・まずは自己紹介。 infoseekに転職→楽天→Ask.com→楽天（そして英語） ・Lucene Revolutionってなに？ ・トレーニング Scaling Search with Big Data \u0026amp; Solr Hadoopの紹介 SolrとHadoopのMapReduceを利用したインデキシングのハンズオン Solrのスケーリング（Sharding、Replication）、マルチテナント ※http://www.lucidimagination.com/services/training/big-data-training-scaling-solr 日本ではやってない、残念。 ・カンファレンス スライドとかはlucidimaginationのサイトで見れるよと。 http://www.lucidimagination.com/devzone/events/conferences/lucene-revolution-2012 ・Lucidworks Big Dataの紹介 Hadoopとかいろいろ組み合わせて使えるよと ・Microsoftの人がAzureでSolrの紹介 IEとかWindows8の話ばっかり。 ・Kuromojiの紹介 やはり、マイノリティ。 内容は日本語勉強会ｗ 中国語とかは対応するの？日本語しか知らないです。。。 ・ErickさんのSolrCloudの話 4.0は2012年にリリースする予定 スコアリングをプラガブルに。 管理系画面がリッチだよと。 ・一番重要だなぁと思ったのは。。。 「英語」！（会社的な感想ではありません。。。） Q：これはみとけ的なスライドは？ A：Hadoop上でインデキシングして、ビットトレントとかで連携してるという例が面白かった。 Q：FASTとかと比べてSolrってどーなの？ A：ESPは洗練されてる。クローラーとか、ベイシスのトークナイザーを内包してるとか。 Solrは言語処理系が弱かったとかあるけど、そろってきてるのでは。 4.0は互角になるんじゃないかなぁ。 ESPがWindowsオンリーになるので、LinuxユーザがSolrに行きつつある。 3. 株式会社 ロンウイット　阿部さん Solr 4.0の紹介 ・Solr 4.0の主な機能の紹介 3.xは3.6が最後4.0-ALPHAが7/3に出た ・プラガブルなスコアリング BM25、Language Models、Divergence from Randomness、Information-based Models 関口さんがスライド作ってる ・FST対応 Finite State Automata/Transducer オートマトン理論を活用したもの。 TokenStreamはFSAで実装 SynonymFilterがFSTになると、オフセットが変わってくるらしいと。 ・Codecプラグイン Luceneレベルのお話。 ドキュメントをファイルに保存するときの形式をプラガブルに変更可能。 SimpleTextなどもあるらしい。テストに利用できそう。 APIレベルで、マイグレーションの必要があるかも。 ・NRT Near Real Time Search softCommitのお話 Realtime-get：IDを入れたらGETできるよと。 KVSとしても活用できるぞ～と。 ・PivotFacet Facetが階層的（？）な感じで取れる ・JOIN、pseudo-join ローカルパラメータでできるよーと。 ・SolrCloud インデックスの分散配置をやってくれる（3.6まではやってくれない） shardがダウンしたらフェイルオーバーしてくれそう Master/Slave環境 リアルタイムインデクシングとリアルタイム検索とか ・ZooKeeperIntegration実装 リーダー選出、コンフィグの管理などなど ・ManifoldCFの近況 5月にトップレベルに昇格！ http://manifoldcf.apache.org/ja_JP/index.html 0.6は7月に出そう。日本語にもなってる。すげー Alfresco Connector、ElasticSearch Connectorなども Solr Plugin for Enterprise Searchとか ","date":1341402000,"dir":"post/2012/","id":"8acc78be63e27e938ee53ec2c0b90c61","lang":"ja","lastmod":1341402000,"permalink":"https://blog.johtani.info/blog/2012/07/04/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--solrjp/","publishdate":"2012-07-04T20:40:00+09:00","summary":"またまた参加しました。いまだ皆勤賞です。 感想などはあとで。とりあえず、メモとったので第一弾です。 ということで、感想です。 まずは、参加人数。 今","tags":["勉強会"],"title":"Solr勉強会第8回に参加しました。 #SolrJP(Jugemより移植)"},{"contents":"Hadoopからはちょっと離れているのに、面白そうなネタなので参加しました。 Data Science Summit、HBaseCon、Hadoop Summitのイベント参加レポートです。\n最初の草薙さんの発表が実は一番興味を惹かれていたので、参加しました。 データの解析に関するサミットというのはなかなか聞いたことが無いのでどんな内容なのかなぁと。 ちょうどVisualizeなどに興味を持っていたり、データ解析、今後重要ですよねという話が出ていたりしていたので。 実際にデータ解析が今後重要で、どんなことに使えるのかなど、製品に偏らない内容のようで色々とためになりました。 この内容をずっと聞くのは私には無理ですw英語も数学もイマイチなので、ついていけない自信がありますｗ。 「データ分析の結果をビジネスに結び付けられる人とかが今後重要になります」という話が一番気になったキーワードでした。\nHBaseConもかなり濃い内容だったようです。 私は残念ながら、HBaseの概要の概要くらいしか知らないので、内容にはついていけてないですが。。。 Facebookがかなり活用しているようですが、残念ながらスライドが上がっていないようです。 Solrに関連する話もあったようです。HBaseとSolrを組み合わせたLilyプロジェクトに関連する話のようでした。 スライドは登録しないと見れないみたいです。\n最後はHadoop Summitの参加レポートです。 まずは、ユーザ寄りの内容を@muddydixonさんから。個人的に、Twitterの話が多いのかなぁと。 ここでも、Visualizeの話が出ていたとか。 Lucidの話もあったようです。LucidWorks BigDataの話かな？\n最後は@shiumachiさんのHadoopのプロダクト寄りのお話。 YARN（Map/Reduce2.0？）やHBaseの今後の展望など。YARNはキーワードだけ知っていたので、わかりやすい解説で、やっと理解できました。 全体を通して、HBaseが今後もっといろんな局面で使われそうだなぁと。日本語の本も7/24に出るし。（まだページが無いみたいなので、英語のほうを。）\nいつものごとく、途中でビールが入ったので後半はメモが適当ですが、楽しかったです。皆さんお疲れ様でした。\n帰り着いたら、さっそくスライドが上がってました。すごい！ スライドはこちら（2012/06/26 0時現在）\nData Science Summit / EMC Worldレポート HBaseCon 2012 参加レポート』の発表スライドをアップしました。（NTTデータ 猿田 @raspberry1123 ／岩崎） @muddydixonさんのHadoopSummit2012参加レポート @shiumachiさんのHadoopSummit2012参加レポート @muddydixonさんのブログ いろんなキーワード、特に、データサイエンス寄りの話が面白かったです。 次回はJenkins関連のようで、7/30開催みたいです。\n以下はいつものメモです。\n日　時： 2012年6月25日（月） 19:00～21:00 （受付開始 18:40） 場　所： 豊洲センタービルアネックス（NTTデータ、豊洲駅直通） ◯ Data Science Summit / EMC World レポート （EMC Japan 草薙） ・Data Science Summitのレポート 揃ってるようで揃ってないスロットの写真ｗ EMC World2012と併設 今回2回目。 ・OpeningKeynote: What We Can Predict About Prediction by Nate Silver 研究者は不確実性やリスクを包含した、現実的な予測モデルを開発すべき いろいろ ・Roundtable: Economic, Political, \u0026amp; Societal Roles of Social Data ユーザの「query-like intent」を自然言語解析と機械学習で捉える 属性だけじゃなく、活動を コンテンツからコンテキストへ、コンバージョンからカンバセーション ・Big Data Transformation - HealthMap ウィルスのアウトブレイクの検知（160日→20日）に。 ウィルス＝コンピュータじゃない方 ・Big Data Transformation - Intuit int.com？ データがあるから、こういうことが知りたいなどの新しいプロセスが 「https://www.mint.com/」 ・Big Data Transformation - InfoMotion Sports Technologies バスケのボールにセンサーつけて、試合や選手の解析に利用して、 チームが強くなったりしてるらしい。 ・Big Data Transformation - Decide.com アメリカ？の価格比較サイト ソーシャルデータを元に、買い時、売り時を予測して教えてくれる。 もうすぐ新しいモデル出るかもよ？などの噂を利用してる。 ・Analytics Maturity: Master or Novice? 2010年のアメリカの教育事情のレポート データサイエンス系の統計とかがもっと必要なんじゃないか。 ・Keynote: Navigating the Road from Business Intelligence to Data science Piyanka Jain BIの限界とか、データサイエンスの恩恵を受け入れるのに必要なもの？など システムじゃなくて、人やスキルに投資しましょう。 データ分析の結果をビジネスに結び付けられる人とか。 Panel: From Raw Data とValue Data プライバシー問題 データ品質の問題 異常値を除外するなと。最も興味深いデータになることもある。 \u0026#34;Data exhaust\u0026#34;の問題 個人が日々インターネット上で行う様々なインタラクションに関するデータの集合 相関と因果関係の区別が大変難しい。 Panel: Tapping Into the Pulse of the Data Science movement ストーリを持ってデータを語れるのが重要。 Keynote: Data Visualizeation at the Point of Influence by Adam Bly Closing Keynote: The Promise and Peril in the Human / Technology Relationship by Jonathan Harris TEDで有名な人 まとめ アメリカはこの分野での投資は回り始めている. http://www.greenplum.com/datasciencesummit/ ◯ HBaseCon レポート （NTTデータ 猿田／岩崎） ・GeneralSession HBaseの開発に参加してね。 ・レプリケーション、セキュリティ、セカンダリインデックス、スナップショット、バックアップなど特に貢献して欲しいと。 ・HBaseによりカバーできるアプリケーション領域 メッセージング、位置ベースアプリケーション、リアルタイムレコメンデーション、広告最適化 ・開発者への要望 メッセージをちゃんとして 解析用メトリクス 管理ツール ・M/Rジョブとの連携の改善 ・自動チューニングなど ・Applications ・GAPの事例 色々試してHBaseにした。 クラスタ構成、16Slave、3Master、NN Failover via NFS ※ZKはスレーブに置くと、アウト。 ・Tumblr 最初は失敗した。 OpenTSDBを経験して、Motherboy V1に。 テストフェーズまでが目的 →幾つかの知見が得られたよーと。 Motherboy V2を構築中。 ・Facebook ひと月250TBペースで増加中。。。 なんで、HBaseにしたの？ 低レイテンシ、水平スケール、一貫性重視の設計、M/Rとの親和性とか Schema V1＝Snapshot Schema Schema V2＝Split Snapshot Schema Schema V3＝Hybrid Schema HBaseのデータにさらにインデックス作ったりとか。 Schema Vertion Current＝Finer grained schema and Indexer 読み書きの単位を分析して、スキーマを分割して細かくして行っていた。 ・Operations ・HBaseで困ったよ at Facebook ・リージョンサーバに特定データ入れると連鎖的に死亡 ・サーバが死に切らないとか。 ・HBaseは落ちるときは落ちるので、しぶとく生き残れるアプリを作ってねと。 ※Facebook関連のスライドなどがあがってませんと。 ・HBaseバックアップについて Clouderaの人とFacebookの人 ・選択肢 DistCP /hbaseディレクトリまるごとコピー。一貫性が保証されない exportツール MRジョブ。1度に1つのテーブルのみ copytableツール データを別クラスタに保存 exportツールに似てる。 レプリケーション 。。。 アプリケーションから複数クラスタへの書き込み 。。。 ・ユースケース ・HBASE-5509を利用したバックアップ ・開発中バックアップ HBASE-6055スナップショット、HBASE-4618など ・Development ・HBase Schema Design　Salesforce.comの人 非正規化でやりなさいと。Joinはおすすめしないと 最後にデザインパターンが載ってると。 0.行キーの設計がすべて 1.Design for the questions, not the answers. 2.データサイズは2種類しかない。大きすぎるか、そうじゃないか。 3.コンパクトに詰め込め 4.行単位の原子性を活用する。 5.属性は行キー内に移動することができる。（Lars Georgeがfoldingと読んでいる手法） 6.エンティティをネストさせると、データを事前に集計できる。 ・HBase Performance Tuning And Organizations　Facebookの中の人 テーブルの事前スプリット オフピーク時間を設定する。（0.94で入った） コンパクション設定が効いてくるよ ・SolrのバックエンドにHBase？？？ ◯ Hadoop Summit レポート (@muddydixonさん) ・オープニングビデオは必見 ・ショーケース ・Datameerを注目した。Visualizationの専任チームがいる。 UIじゃなくて、解析部隊だけで60名 お値打価格。$2900/年 ・Azure Big Data JavaScriptで ・ショーケースLucid Solr、HBaseとかいろいろ組み合わせて。 ・Session Hadoop... 2015までにApache Hadoopに世界のデータの半分が乗るらしいと。 ・Session Realtime analytics with Storm and Hadoop フォロワのフォロワをunique処理したり。 ・Session Scalding Twitter\u0026#39;s new DSL for Hadoop ※Zipkinにも出てきたな、名前。 ・Hadoop Plugin for MongoDB ・Hadoop and Vertica The Data Analytics Platform at Twitter Twitter社でのHadoop周りのデータフローとか。 Verticaは速度がいるものの処理に利用 80-100TB/dayとか。。。 ・Keynotes ・Big data analyzing system is censor of company. ・It is difficult in blind and deaf. ・Session Large Scale Search, Discovery and Analytics with Hadoop, Mahout and Solr ※@muddydixonさんのブログにセッションに対応するスライドのリンクを公開中。http://d.hatena.ne.jp/muddydixon/20120617/1339919125 ◯Hadoop Summit レポート (@shiumachiさん) ・Hadoop1.x MapReduce 非常に安定 ・課題。。。 ・YARN（Yet Another Resource Negociator） ターゲット：6000～10000ノード 100,000以上のタスクの同時実行 10,000ジョブの同時実行 性能は倍以上 Q：これは同じプログラムを動かして？ A：。。。倍以上です！（わかんないっす。） 今後の予定 幾つかのJIRAの紹介 MAPREDUCE-4327とかHBASE-4329とか まとめ YARNは「汎用」分散処理基盤に向けて一歩踏み出したもの！ 更なる進化に注目と ・HBaseの可用性とリペア ダウンタイムを短くしよう。 障害停止7割くらい。 設定ミスが44% 不安定な機能は使うな、推奨構成を推奨！ HBase 0.92＋Hadoop 2.0 HDFS HAによる高可用性とか 将来：HBase 0.96＋Hadoop 2.x 計画停止時間削減：オンラインスキーマ変更（HBASE-1730） ローリングアップデート：バージョン間互換性が必須 HBase本読みなさい。 金があれば、サポート買ってください。 日本語HBaseトレーニング開催予定（来月） ・HBase NameNode HighAvailability ```　","date":1340642460,"dir":"post/2012/","id":"9f29c6d9719fc6bc09a2981057642b69","lang":"ja","lastmod":1340642460,"permalink":"https://blog.johtani.info/blog/2012/06/26/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC10%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/","publishdate":"2012-06-26T01:41:00+09:00","summary":"Hadoopからはちょっと離れているのに、面白そうなネタなので参加しました。 Data Science Summit、HBaseCon、Hadoop Summitのイ","tags":[],"title":"Hadoopソースコードリーディング第10回に参加しました。#hadoopreading(Jugemより移植)"},{"contents":"Issue 32で上がってきたlucee-gosenのUniDic対応の最初のパッチを書いたので、ブログに残しておきます。\n###UniDicとは___ UniDicとは、日本語テキストを単語に分割し，形態論情報を付与するための電子化辞書です。 UniDicの詳細や特長についてはHPを御覧ください。\n残念ながら、UniDicは利用者登録をして、利用規約に従うと利用が可能となります。 ですので、lucene-gosenでは、Ipadicやnaist-chasenの辞書とは異なり自動で辞書をダウンロードする機能はありません。\n###利用手順___ 以下が、Unidicの辞書を利用したjarファイルの作成方法となります。\n1. lucene-gosenをダウンロードし、パッチを当てる lucene-gosenのリポジトリからソースをエクスポートし、パッチをダウンロードし、パッチを適用します。 コマンドは以下のとおりです。\nsvn co . lucene-gosen-trunk-readonly cd lucene-gosen-trunk-readonly patch -p0 \u0026amp;gt; ...patch （パッチに関しては今後正式版をリリースされたら手順からは必要なくなります。）\n2. Unidic辞書生成のためのディレクトリを作成「$GOSEN_HOME/dictionary/unidic」\nmkdir dictionary/unidic 3. 対象となるUnidicの辞書のソースファイルをダウンロード 利用者登録をし、利用規約に同意の上、以下のファイルをダウンロードします。 「/」に添ってダウンロードページから遷移してダウンロードしてください。\n1.3.12個別ファイル/unidic-chasen/unidic-chasen1312src.tar.gz 4. ダウンロードしたtar.gzファイルを「dictionary/unidic/」にコピー\ncp .. lucene-gosen-trunk-readonly/dictionary/unidic/ 5. Antを実行してjarファイルの作成\nant -Ddictype=unidic 成功すれば、lucene-gosen-trunk-readonly/dist/lucene-gosen-2.1-dev-unidic.jarファイルが生成されます。 あとは、通常通り、SolrやLuceneで利用することが可能です。\n以上がjarファイルの作成手順となります。\n###制約事項（2012/06/18現在）___ 現在（2012/06/18）時点で公開しているパッチは、以下の制約が存在します。\nCOMPOUNDエントリー未対応 品詞情報（発音）の内容の制限 COMPOUNDエントリー未対応 Unidicの辞書のエントリーの中に1件だけ、COMPOUNDと呼ばれるエントリーが1件だけ存在します。 別々の単語を組み合わせて1単語として扱うことができるようになっているようです。 lucene-gosenでは、残念ながら、このような辞書の形式には対応していません。 1件しか存在しないデータでもあることを鑑みて、今回の辞書構築処理では、スキップするようにしました。\n品詞情報（発音）の内容の制限 lucene-gosenの実装上、単語の読みのバリエーション数と発音のバリエーション数には以下の制限が存在します。\n「読み」バリエーション数 ＜ 「発音」バリエーション数 「読み」に対応する形で、「発音」がlucene-gosenでは品詞情報としてデータ登録されています。 UniDicのデータには上記制約を満たさないデータが5件ほど存在します。 現在、これら5件のデータについて、「読み」に対応した「発音」データには空文字が表示されるようになっています。\nまだ、簡単に動作確認をしただけです。UniDicを利用していて問題など有りましたら連絡、Issueへのアップをしていただけると助かります。\n","date":1340028180,"dir":"post/2012/","id":"d13aa56e27fe71ef40ff153c093ecdf8","lang":"ja","lastmod":1340028180,"permalink":"https://blog.johtani.info/blog/2012/06/18/lucene-gosen%E3%81%AEunidic%E5%AF%BE%E5%BF%9C/","publishdate":"2012-06-18T23:03:00+09:00","summary":"Issue 32で上がってきたlucee-gosenのUniDic対応の最初のパッチを書いたので、ブログに残しておきます。 ###UniDicとは___","tags":["lucene-gosen"],"title":"lucene-gosenのUniDic対応(Jugemより移植)"},{"contents":"「鉄は熱いうちに打て」ということで、残りも勢いでメモ。 まだ、見直しとかしてない状態なのでおかしいところとかありますが。。。 図とか入れるのはまた今度。\nTransport（転送）\nZipkinとHadoopに異なるサービスからのトレースを送信するのにScribeを利用します。 ScribeはFacebookにより開発されました。 システムの各サーバで実行できるデーモンとして作成されています。 ログメッセージをListenし、カテゴリごとのcorrectレシーバーに配送します。 Zipkin collector daemon\nトレースデータがZipkinコレクターデーモンに配送されたらvalidかどうかをチェックしてから保管し、インデックスを作成します。 Storage\nストレージにはCassandraを選びました。 スケーラブルで、柔軟なスキーマをもっており、Twitter内部で大変使われています。 このコンポーネントをプラガブルにしようと試みましたが、困難なため、ここでは公開しません。 Zipkin query daemon\n保存、インデックスされたデータを探す方法が必要です。 クエリーデーモンはユーザに対して簡単なThriftAPIを公開しており、トレースを探すことが可能です。Thrift fileを見て下さい。\nUI\n多くのユーザはUI経由でデータにアクセスします。 VisualizeにD3を利用したRailsアプリケーションです。 UIの認証は実装していないことに注意してください。\nモジュール Zipkin内部のモジュール関連図\n##インストール___ Cassandra\nZipkinはCassandraをストレージにしています。Cassandraクラスタが必要になります。 1. Cassandraサイトを参考にしてクラスタを構築してください。 2. Zipkin Cassandraスキーマを利用します。つぎのコマンドでスキーマが作成できます。 bin/cassandra-cli -host localhost -port 9160 -f zipkin-server/src/schema/cassandra-schema.txt Zookeeper\nZipkinは協調のためにZooKeeperを利用します。 これは、保存すべきサーバをサンプルレートで決定し、サーバを登録します。？ 1. ZooKeeperのサイトを参考にインストールしてください。 Scribe\nScribeはトレースデータを配送するのに利用するロギングフレームワークです。 ネットワーク保存先としてZipkinコレクターデーモンを指定する必要があります。 Scribeの設定は次のようにします。 \u0026lt;store\u0026amp;gt; category=zipkin type=network remote_host=zk://zookeeper-hostname:2181/scribe/zipkin remote_port=9410 use_conn_pool=yes default_max_msg_before_reconnect=50000 allowable_delta_before_reconnect=12500 must_succeed=no \u0026lt;/store\u0026amp;gt; 注意：上記設定は、カテゴリーにより送信ホストを見つけるためにZooKeeperを利用するサポートのScribeのTwitterバージョンを使用する方法です。 コレクターのためのDNSエントリーを利用したりもできます。 Zipkinサーバ ZipkinサーバはScala 2.9.1、SBT 0.11.2そしてJDK6で開発しました。\n1. git clone https://github.com/twitter/zipkin.git 2. cd zipkin 3. cp zipkin-scribe/config/collector-dev.scala zipkin-scribe/config/collector-prod.scala 4. cp zipkin-server/config/query-dev.scala zipkin-server/config/query-prod.scala 5. Modify the configs above as needed. Pay particular attention to ZooKeeper and Cassandra server entries. 6. bin/sbt update package-dist (This downloads SBT 0.11.2 if it doesn\u0026#39;t already exist) 7. scp dist/zipkin*.zip [server] 8. ssh [server] 9. unzip zipkin*.zip 10. mkdir -p /var/log/zipkin 11. zipkin-scribe/scripts/collector.sh -f zipkin-scribe/config/collector-prod.scala 12. zipkin-server/scripts/query.sh -f zipkin-server/config/query-prod.scala SBTでコレクターとクエリサービスを起動します。 Scribeコレクターサービスの起動方法は次の通り。 bin/sbt \u0026#39;project zipkin-scribe\u0026#39; \u0026#39;run -f zipkin-scribe/config/collector-dev.scala\u0026#39; クエリサービスは次の通り bin/sbt \u0026#39;project zipkin-server\u0026#39; \u0026#39;run -f zipkin-server/config/query-dev.scala\u0026#39; Zipkin UI\nUIはRails3アプリです。 1. 設定をZooKeeperサーバでアップデートします。これはクエリデーモンを見つけるのに利用します。 2. Rails3アプリケーションサーバにデプロイします。テストの場合は次のようにすることもできます。 bundle install \u0026amp;amp;\u0026amp;amp; bundle exec rails server. zipkin-tracer gem\nzipkin-tracer gemをトレースしたいRailsアプリケーションにRack Handlerで追加します。 config.ruにつぎの記載をします。 use ZipkinTracer::RackHandler run \u0026lt;YOUR_APPLICATION\u0026gt; もし、アプリケーションのstatic assetsがRailsで提供されれば、リクエストがトレースされます。 ##　Running a Hadoop job\nScribeからHadoopにログを保存する設定をすることも可能です。 これをすると、Zipkin自身でオンザフライで簡単に作れないデータから様々なレポートが作成可能です。 ScalaでHadoopのジョブをかけるScaldingというライブラリを利用します。\n``` 1. Hadoopジョブを実行するためのfatなjarを作成します。 2. scald.rbをjarをコピーしたいホスト名とjobを実行するホスト名に書き換えます。 3. 必要なら、scald.rbのjarファイルのバージョンを更新します。 4. scald.rbスクリプトを利用してジョブを実行できます。\n./scald.rb \u0026ndash;hdfs com.twitter.zipkin.hadoop.[classname] \u0026ndash;date yyyy-mm-ddThh:mm yyyy-mm-ddThh:mm \u0026ndash;output [dir]\n##計測ライブラリの利用方法\u0026lt;hr\u0026gt; 計測のためのライブラリとプロトコルがちょっとだけあります。 しかし、もっと計測するための役に立つものを望んでいます。 開始する前にトレースデータがどんな構造なのかを知る必要があります。\n・Annotation - 値、タイムスタンプ、ホストを含みます。 ・Span - 特定のRPCに相当するAnnotationの集合 ・Trace - あるルートSpanにぶら下がるSpanの集合\nZipkinに送信するトレースデータです。\nこれらの詳細な記述は[こちら](https://github.com/twitter/zipkin/blob/master/zipkin-thrift/src/main/thrift/zipkinCore.thrift)を見て下さい。 その他にトレースデータの重要なものは、トレースされたサービス間でやり取りされる情報である、軽量なヘッダーです。 トレースヘッダは次のものから構成されます。\n・Trace Id - トレース全体のID ・Span Id - 個々のリクエストのID ・Optional Parent Span Id - このリクエストが他のリクエストの一部として生成されたら付与される ・Sampled boolean - トレースすべきかどうかを表すフラグ\nデータタイプについて、理解したので、どのように計測が行われるかを順をおってみてみましょう 例はFinagleのHTTPがどのようにトレースされるかを示しています。 他のライブラリやプロトコルはもちろん、異なりますが、基本的な部分は一緒です。\n\u0026lt;b\u0026gt;　サーバサイド\u0026lt;/b\u0026gt; 1. 到達したリクエストのトレースヘッダー存在するかどうかを調べます。存在すれば、なら、このリクエストに対して関連するIDとします。トレースヘッダーがなければ、サンプリング対象かどうかを決めて、新しいTrace Id、Span Idを生成します。参考には[HttpSererTracingFilter](https://github.com/twitter/finagle/blob/master/finagle-http/src/main/scala/com/twitter/finagle/http/Codec.scala)を見て下さい。 2. もし、現在のリクエストがサンプリングされる場合、サービス名、ホスト名、スパン名（例えば、http get/put）、その他のAnnotationのような情報を集めます。 リクエスト受信時には「server received」というAnnotationを生成し、処理が終了して結果を返すときに「server send」というAnnotationを生成します。 参考には[HttpServerTracingFilter](https://github.com/twitter/finagle/blob/master/finagle-http/src/main/scala/com/twitter/finagle/http/Codec.scala)を見てください。 3. 生成されたトレースデータはServerBuilderにより設定されたトレーサーに渡されます。 デバッグのためのConsoleTracerが例としてありますが、ZipkinTracerになります。 トレースデータを[ZipkinTracer](https://github.com/twitter/finagle/tree/master/finagle-zipkin)が受け取った時、Span Idにより集約されます。 4. ZipkinTracerが\u0026#34;end of span\u0026#34;イベント（\u0026#34;server received\u0026#34;アノテーションやタイムアウトのような）を受け取ると、Thrift構造としてデータを集約してScribeに送ります。もし、そのようなイベントが発生しない場合、ZipkinTracerはいつかそのデータを送信します？？？おかしい？。データ送信のための他の方法も追加します。 ThriftやScribeのようなものですが、JSONやHttpかもしれません？ \u0026lt;b\u0026gt;　クライアントサイド\u0026lt;/b\u0026gt; 1. リクエストを送る前にそれがトレースの一部かどうかをチェックします。 サーバで利用されているとします。　サーバは、リクエストを処理してすでに付与されているトレースIDを割り当てます。 トレースIDを再利用しますが、この新しいリクエストには新しいスパンIDを生成します。 また、親のスパンIDが存在すれば、前のスパンIDに設定します。 [ここ(TracingFilter)](https://github.com/twitter/finagle/blob/master/finagle-core/src/main/scala/com/twitter/finagle/tracing/TracingFilter.scala)や[ここ(Trace)](https://github.com/twitter/finagle/blob/master/finagle-core/src/main/scala/com/twitter/finagle/tracing/Trace.scala)が参考になります。 2. サーバサイドと同様に、送信されるHttpリクエストにトレースヘッダーを追加するための[HttpClientTracingFilter](https://github.com/twitter/finagle/blob/master/finagle-http/src/main/scala/com/twitter/finagle/http/Codec.scala)があります。 3. リクエスト送信前の「client send」やサーバからの返信を受信した「client receive」のようなアノテーションを生成します。 4. サーバサイドと同様に、データがZipkinにデータを送るZipkinTracerに到達します。 ","date":1339772520,"dir":"post/2012/","id":"9ccda414c322ebcdf875eacbba2e4b7e","lang":"ja","lastmod":1339772520,"permalink":"https://blog.johtani.info/blog/2012/06/16/zipkin%E3%81%AEreadme%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%81%9D%E3%81%AE%EF%BC%92%E6%AE%8B%E3%82%8A/","publishdate":"2012-06-16T00:02:00+09:00","summary":"「鉄は熱いうちに打て」ということで、残りも勢いでメモ。 まだ、見直しとかしてない状態なのでおかしいところとかありますが。。。 図とか入れるのはま","tags":["Zipkin"],"title":"ZipkinのReadme読んでる（その２、残り）(Jugemより移植)"},{"contents":"ZipkinのGithubにあるReadmeを読んでます。 せっかくというか、頭が悪いので読みながら内容をメモ。 まずは、アーキテクチャとトレースデータ送信のためのクライアント側あたりです。 （誤訳とかおかしいだろというツッコミ大歓迎です。） あとで、リンク貼ったり絵を入れたりするかもしれませんが、とりあえず。\n◯アーキテクチャ（図はこちら）\n・対象とするサービスからScribeでデータを収集し、ZipkinのCollectorに投げる ・CollectorはCassandraにデータを格納 ・WebUIからはQueryでCassandraに問い合わせを行なってデータ取得 ・Scripe、CollectorはZookeeperと連携している（妄想） ◯計測用ライブラリ（図はこちら。図のSと書かれた青い箱）\n・各ホストの計測用ライブラリがトレースデータを集めてZipkinに送信する。 ・ホストは他のサービスへリクエストを飛ばすときに、リクエストにトレース用のIDを付与してます こうすることで、データをあとで、束ねることが可能となります。 ◯計測ライブラリの利用方法 ・Finagle\nJVMのための非同期ネットワークスタックである。 それは、JVMベース言語（JavaやScalaなど）で非同期RPCのクライアント・サーバを構築するのに利用できる。 FinagleはTwitterの内部ですごく利用されていて、トレースサポートを実現するのに当然のポイントです。 現時点で（Finagleは）ThriftやHTTP、Memcache、Redisのクライアント・サーバサポートも持っています。 ScalaでFinagleサーバをセットアップするのはつぎのようなコードになります。 トレースを追加するには、finagle-zipkinを追加して、ServerBuilderのtraceFactory関数を呼ぶだけです。\nServerBuilder() .codec(ThriftServerFramedCodec()) .bindTo(serverAddr) .name(\u0026#34;servicename\u0026#34;) .tracerFactory(ZipkinTracer()) .build(new SomeService.FinagledService(queryService, new TBinaryProtocol.Factory())) クライアント側も同様です。 上記のようにサンプリングしたリクエストにZipkinトレーサーを指定することで 自動的にトレースできるようになります。 サービスやホストでのリクエストの開始と終了を記録できます。 さらに付加的な情報を記録したい場合は、つぎのようなコードを追加します。 Trace.record(\u0026#34;starting that extremely expensive computation\u0026#34;) 上記コードは、上記コードが実行された時間に文字列を付加できます。 キーバリュー情報を付加したい場合は次のようになります。 Trace.recordBinary(\u0026#34;http.response.code\u0026#34;, \u0026#34;500\u0026#34;) Ruby Thrift\nリクエストのトレースに利用できるgemもあります。 リクエストに対してトレースIDを生成し、リクエストに付与し、トレーサーにプッシュするのにRackHandlerのgemを利用できます。 トレーサをトレースするサンプルはzipkin-webを参照。\nRubyからトレースクライアントをコールするのに、Twitter Ruby Thrift clientを使います。 つぎのようなコードを書きます。\nclient = ThriftClient.new(SomeService::Client, \u0026#39;127.0.0.1:1234\u0026#39;) client_id = FinagleThrift::ClientId.new(:name =\u0026gt; \u0026#34;service_example.sample_environment\u0026#34;) FinagleThrift.enable_tracing!(client, client_id), \u0026#34;service_name\u0026#34;) Querulous\nQuerulousはScala用のSQLデータベースのインタフェースライブラリです。 SQLクエリの実行のタイミング情報をトレースに追加できます。 Cassie\nCassieはFinagleベースのCassandraクライアントライブラリです。 CassieのトレーサーはFinagleの例とほぼ一緒ですが、 CassieではKeyspaceBuilderに設定します。 cluster.keyspace(keyspace).tracerFactory(ZipkinTracer()) とりあえず、ここまで。___ 2012/06/22 リンクを貼って体裁を修正\n","date":1339721820,"dir":"post/2012/","id":"69f755dd5b9e90a99c3086543790541c","lang":"ja","lastmod":1339721820,"permalink":"https://blog.johtani.info/blog/2012/06/15/zipkin%E3%81%AEreadme%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E5%91%A8%E3%82%8A%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-06-15T09:57:00+09:00","summary":"ZipkinのGithubにあるReadmeを読んでます。 せっかくというか、頭が悪いので読みながら内容をメモ。 まずは、アーキテクチャとトレー","tags":["Zipkin"],"title":"ZipkinのReadmeを読んでる（クライアント周りについて）(Jugemより移植)"},{"contents":"久々にSolrの話です。 といっても、結構前からの話でして。。。\nschema.xmlのfieldTypeの設定に「autoGeneratePhraseQueries」という属性があります。 Solr3.1で導入されました。動作に関しては関口さんのブログで説明されています。 Solr 1.4までは、Analyzerがトークンを複数返してくる場合（例：lucene-gosenで「Solr入門」という文字列を入れた場合など）にフレーズクエリとして処理していました。 Lucene 3.1.0から、この処理がデフォルトfalse（つまり、フレーズクエリにならない）という挙動になりました。（詳しくは関口さんのブログで。） ただ、Solr 3.1.0では、下位互換性を考慮して、autoGeneratePhraseQueriesの設定値はデフォルトが「true」でした。\nこのデフォルト値がSolr 3.3以降で提供されているschemaのバージョン（1.4以上）からデフォルト値が「false」に変更されています。 schemaのバージョンを1.3以前のものから1.4以上に移行する場合は注意が必要です。\nとまぁ、偉そうに書きましたが、私もちゃんと追えてませんでした。 Solr勉強会第６回で、関口さんの発表できちんと説明されていて、参加してたのに聞けてなかったですし。（メモ取ってるのに、書いてない。）\nということで、Solr入門のサンプルschemaも少し修正しました。 こちらとこちらの記事に追記してありますので、参考にしてください。\n","date":1339603740,"dir":"post/2012/","id":"277f7f2177e2a265a62680ea0158f9b9","lang":"ja","lastmod":1339603740,"permalink":"https://blog.johtani.info/blog/2012/06/14/autogeneratephrasequeries%E3%81%AE%E3%83%87%E3%83%95%E3%82%A9%E3%83%AB%E3%83%88%E5%80%A4%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-06-14T01:09:00+09:00","summary":"久々にSolrの話です。 といっても、結構前からの話でして。。。 schema.xmlのfieldTypeの設定に「autoGeneratePh","tags":["solr"],"title":"autoGeneratePhraseQueriesのデフォルト値について(Jugemより移植)"},{"contents":"すでに読まれた方もいるかも知れませんが、気になったのでメモを書いてみようかと。\n先週の木曜日にTwitterのエンジニアブログでZipkinというOSSを公開したという記事がでました。 非常に興味深いシステムだったので、ちょっとずつ読み解いていきたいなという宣言（というか、ハッパをかけてもらうため）も兼ねて、まずはブログの内容をメモ程度に残しておきます。\nZipkinは分散トレースシステム（distributed tracing system）です。Twitter APIの１リクエストを構成する様々なサービスのタイミングデータ（計時データ）を集めるために作りました。 Firebugのような性能プロファイラのよなもので、しかもバックエンドのサービスもプロファイル可能です。 ZipkinはAPLv2ライセンスでOSSとしてGithubで公開しています。\nZipkinはWebのユーザインタフェースを持っています。（元記事参照） 各サービス（縦軸）でどのくらい時間がかかっているか（横軸）がわかり、クリックすることでより詳細な情報が得られます。 Zipkinはパフォーマンス改善の余地のある部分（遅いMySQLのSELECTなど）を見つけるのに役立ちます。\nZipkinはどのように動くの？ Twitterに届いたリクエストからサンプリングしたリクエストに対してトレース可能なIDを付与して、すべてのサービスに渡していきます。 全リクエストの一部をサンプリングすることで、トレースのオーバヘッドを減らし、常に本番環境で利用できるようにしています。 Zipkinコレクタ（collector）が、Scribe経由でタイミングデータを受け取り、Cassandraに保存してインデックスを作成します。 Zipkinクエリデーモンがインデックスを利用して、WebUIにトレースデータを見つけます。\nZipkinはHack Weekで開始されました。 最初はThriftに対するGoogle Dapperの論文の基本的な部分の実装から始まり、現在ではHttp、Thrift、Memcache、SQL、Redisリクエストをサポートしています。 これらはFinagleライブラリで経由で動作します。Rubyのgemも用意してあります。\nということで、ほぼ直訳ですが、何かの役に立てればと。 ちょっとずつですが、Githubのページやソースを読みながら記事を書いていこうと思っています。\n","date":1339515600,"dir":"post/2012/","id":"ee48516e57684c5a4c22adccac34be92","lang":"ja","lastmod":1339515600,"permalink":"https://blog.johtani.info/blog/2012/06/13/twitter%E3%81%8C%E5%85%AC%E9%96%8B%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%B3%E3%82%B0%E8%BF%BD%E8%B7%A1%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0zipkin/","publishdate":"2012-06-13T00:40:00+09:00","summary":"すでに読まれた方もいるかも知れませんが、気になったのでメモを書いてみようかと。 先週の木曜日にTwitterのエンジニアブログでZipkinと","tags":["OSS"],"title":"Twitterが公開した分散トレーシング（追跡？）システム、Zipkin(Jugemより移植)"},{"contents":"lucene-gosenの最新版（2.0.1）をリリースしました。\nプロジェクトページよりダウンロードが可能です。\n今回の修正では、@haruyama さんからいただいていたパッチの取り込み（リソース周りの改善など）が主な対応となっています。 また、コンパイルに利用するjarファイルがLucene/Solr3.6.0に変更になっています。（Issueはこちら） 3.6.0から追加されたテストケースにて、発生する問題への対処も施したものとなっています。\n","date":1339059234,"dir":"post/2012/","id":"216db319052b5742fc68862cb2f39905","lang":"ja","lastmod":1339059234,"permalink":"https://blog.johtani.info/blog/2012/06/07/lucene-gosen-2-0-2%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E5%91%A8%E3%82%8A%E3%81%AE%E6%94%B9%E5%96%84%E3%81%AA%E3%81%A9/","publishdate":"2012-06-07T17:53:54+09:00","summary":"lucene-gosenの最新版（2.0.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、@haruy","tags":["lucene-gosen"],"title":"lucene-gosen 2.0.2リリース（リソース周りの改善など）(Jugemより移植)"},{"contents":"昨晩に引き続き、情けない内容のブログになってしまいますが。。。\n昨晩、書いた記事の調査をしていた時に気づいた、問題になるケースがあったので調査をしていました。 Issue32に登録した内容になります。 拙い英語を振り絞って書いた英語なので、伝わらないかもしれないのでブログに残しておきます。 昨晩の問題点となったクラス（StreamTagger2.java）の内部処理についてです。 lucene-gosenのLucene向けのTokenizerの内部処理では入力文字列の処理を行うのに、「char buffer[]」を用いて 入力文字列をReaderから読み込むときにバッファリングしています。 このバッファリングにて、特定のケースにて、想定していない場所を単語の切れ目と認識してしまう問題が実装上存在しました。 Issue32に記載した内容は次のようになります。\n上記バッファは4096文字というサイズで固定になっています。 StreamTagger2クラスでは、この4096文字をオーバーするような文字列の場合に、つぎの処理により、4096文字以下の場所に文章の区切りを探そうとします。\n4096文字以上の文字列が入力される バッファに入れられるだけの文字（4096文字）をバッファにコピーする。 バッファの後ろから、つぎの5種類の文字を探索し、見つかった場合（場所をkとし、ｋ＞０の場合）は、その場所を文章の切れ目と判定して、0からk+1文字目までの文字をStringTaggerを利用して形態素解析する。 あとは、繰り返し 上記条件に合致しない場合は、4096文字を文章とみなして形態素解析を行います。 ここで、5種類の文字は以下のとおり。\n0x000D:CARRIAGE RETURN(CR) 0x000A:LINE FEED(LF) 0x0085:NEXT LINE (NEL) 0x2028:LINE SEPARATOR 0x2029:PARAGRAPH SEPARATOR 見ての通り、制御文字ばかりです。 この5文字以外は切れ目と判断してくれません。 ということで、4097文字の文字列が存在し、上記5種類の文字が一度も出てこない場合、バッファのサイズで文字列が途切れてしまい、想定しない区切り位置で区切られた文章に対して形態素解析が実行されてしまいます. HTMLから文字列を抜き出して解析したり、長い文書を解析する場合に、改行文字を削除して処理するといったことも考えられます。 上記5種類の文字列のみで文章の区切り位置を判断してしまうのは問題ではないかと。 まずは、4096文字内に「。」句点が存在した場合に、その部分を区切り位置として認識するようなパッチを記載して、Issue32に添付しました。\n「。」句点を採用した理由はつぎのとおりです。 StreamTagger2では、上記バッファリングした文字列を更に、BreakIterator.getSentenceIterator(Locale.JAPANESE)にて取得したBreakIteratorにて文節単位に区切ってから、各文節ごとに形態素解析を実施しています。 ということは、BraekIteratorにて分節の区切りとして判断される文字については、上記の文字種に追加しても問題無いという判断からです。 ただし、この修正でも、純粋に4096文字以上、句点が出てこない場合には区切り位置がおかしなことになってしまいますが。。。 もう少し、BreakIteratorの挙動を調べて、他にも利用可能な区切り文字が存在しないかを調査していく予定です。。。\n1年以上コミッターをやっているのに、こんなことも理解していないのかよいうツッコミを受けてしまいそうでなんとも情けない話です。。。 まずは、現状報告でした。\n","date":1338913260,"dir":"post/2012/","id":"cbf9587a8187985725963b8bfc67004d","lang":"ja","lastmod":1338913260,"permalink":"https://blog.johtani.info/blog/2012/06/06/issue32%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A64096%E3%81%AE%E5%A3%81/","publishdate":"2012-06-06T01:21:00+09:00","summary":"昨晩に引き続き、情けない内容のブログになってしまいますが。。。 昨晩、書いた記事の調査をしていた時に気づいた、問題になるケースがあったので調査","tags":["lucene-gosen"],"title":"Issue32について（4096の壁）(Jugemより移植)"},{"contents":"久々にlucene-gosenを触っています。 trunkのlibにある、jarファイルが3.5ベースだったので、3.6ベースにしてテストをしたところ、 いくつかある、ランダムテストで結果の不整合が検出されたので、調査していました。 先程、trunkに対応版をコミットしました。もう少しテストケースを追加してからリリースします。 おそらく、通常の使い方では問題無いと思います。\nLuceneでは、ランダムな文字列を利用したテストが実装されています。 lucene-gosenでもこのテストを利用してランダムなテストをしています。 実際にはtest/以下のorg.apache.luceneパッケージにテストケースがあります。 今回、jarファイルを差し替えた時に、このランダムなテスト実施にて、assertが失敗するケースが発生しました。\n原因究明までに、いくつかフェーズがあったので、忘れないように書いておきます。\n1.ランダムテストのテストケースにてエラーがassertが失敗するケースが発生 ※ただし、成功する場合もあり。 2.該当のテストを再現しつつデバッグ＋該当のテストがどんなものかを解読（勉強不足。。。） ※テストは、失敗した場合につぎのようなメッセージが表示され、同じテストが再現可能です。 以下、エラーの出力例。「NOTE: reproduce with: 」のあとにあるantコマンドを実行すれば、同じテストが再現可能です。\n[junit] ------------- Standard Error ----------------- [junit] TEST FAIL: useCharFilter=false text=\u0026#39;wgxznwk\u0026#39; [junit] [junit] ===\u0026gt; [junit] Uncaught exception by thread: Thread[Thread-3,5,main] [junit] org.junit.ComparisonFailure: term 0 expected:\u0026lt;w[gxznwk]\u0026gt; but was:\u0026lt;w[]\u0026gt; [junit] at org.junit.Assert.assertEquals(Assert.java:125) [junit] at org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:146) [junit] at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:565) [junit] at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:396) [junit] at org.apache.lucene.analysis.BaseTokenStreamTestCase.access$000(BaseTokenStreamTestCase.java:51) [junit] at org.apache.lucene.analysis.BaseTokenStreamTestCase$AnalysisThread.run(BaseTokenStreamTestCase.java:337) [junit] \u0026lt;=== [junit] [junit] NOTE: reproduce with: ant test -Dtestcase=TestGosenAnalyzer -Dtestmethod=testReliability -Dtests.seed=4ad9618caecb9fb2:d5476c03b8172df:-9c569f70013ffbb -Dargs=\u0026#34;-Dfile.encoding=SJIS\u0026#34; [junit] ------------- ---------------- --------------- [junit] Testcase: testReliability(org.apache.lucene.analysis.gosen.TestGosenAnalyzer):\tCaused an ERROR 3.デバッグの結果、Luceneのtest-frameworkにある「MockReaderWrapper」というクラスの影響を確認 LuceneのJIRAのLUCENE-3894にて追加されたクラスであるとわかる。 このクラス、Readerのreadメソッド内部で、ランダムな値を元に長さを途中で返すという実装のReaderになっている。 （全部で18文字の文字列なのだが、ランダムな値を元に、12文字として結果を一旦返すという仕組みが実装されている） 4.lucene-gosenの問題箇所を特定。 Readerが途切れた部分を分節として扱ってしまう実装になっていた。 該当の部分に修正をいれてコミット。 という具合です。 一応、テストを数回走らせてランダムテストが問題なく終了するのを確認はしてあります。 今回の問題に対する、個別のテストケースを追加してから近日中リリースする予定です。 対応が遅くなって申し訳ないです。。。\n","date":1338827340,"dir":"post/2012/","id":"0dcb6d0f17794bbca56b6cdb9e20b932","lang":"ja","lastmod":1338827340,"permalink":"https://blog.johtani.info/blog/2012/06/05/trunk%E3%81%AE%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E5%B7%AE%E3%81%97%E6%9B%BF%E3%81%88lucene-solr3-6-0%E3%81%A8%E3%83%A9%E3%83%B3%E3%83%80%E3%83%A0%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E5%A4%B1%E6%95%97%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-06-05T01:29:00+09:00","summary":"久々にlucene-gosenを触っています。 trunkのlibにある、jarファイルが3.5ベースだったので、3.6ベースにしてテストをし","tags":["lucene-gosen"],"title":"trunkのライブラリ差し替え（Lucene/Solr3.6.0）とランダムテストの失敗について(Jugemより移植)"},{"contents":"録画してたEテレのスーパープレゼンテーションを見ててふと書きたくなったので、書いてます。 あとから読んだら恥ずかしくなりそうだけど。。。 「\u0026ldquo;知力の余剰\u0026quot;が世界を変える」というClay Shirkyさんの話を見て思ったことです。 社会的に貢献できる仕組みが最近増えているという話の内容でした。そこで、OSSについても同じことが言えるよなぁと思った次第でして。\n昔からいろんなかたが言ってると思うし、今さら何をとおもわれるかもしれないですが、なんとなく書きたくなってしまったので。\n私はシステム開発を生業にしています。特にOSSにはお世話になっています。 実際に、OSSを利用している方はかなりいると思います。 幸いにも、私はOSSのコミッターもやっています。 OSSに色々と関わってきて常々思っていることがありまして。\nOSSは基本は有志の方々が開発やメンテナンスを行なっています。（最近では会社で行なっているところもありますが。） そんなOSSに貢献する方法はいくつかあるのかなぁと。\nバグを発見したら報告したり、こんな機能を作ってみたけどどうですか？とパッチを送ってみたりするのは素晴らしい貢献だと思います。 ただ、なかなかアクションを起こすのって勇気がいるかなぁと。 実際、私もパッチ書いたりバグ報告するのは気後れすることがありしました。 ただ、貢献する方法ってこれだけじゃないよなぁと、コミッターをやり始めて思いました。\nもちろん、バグ報告してもらえるともっとありがたいですし、新機能とかリクエストを送ってもらえるともっと嬉しいです。 MLに質問するのもありです。ただ、ちょっとハードルが高いと思うこともあります。\nそんな時は、ただ使っているよと、ツイートしたりブログを書いてくれるだけでもありがたいし、ヤル気が出るものです。 使い勝手が悪いなぁというツイートでも、なんでこんなに使いにくいんだというブログでもいいんです。 気になるなぁという形でもいいと思っています。 githubでフォローするだけでもいいかと。 反応があれば、使ったり触ってもらえていることがわかります。 なので、使っているよとかアピールしてもらえると嬉しいよなぁと。\nなんか、締りのない感じになっちゃいましたが、反応があるとうれしいので、お気楽に反応しましょうよというお話です。\n","date":1338394320,"dir":"post/2012/","id":"ffdbd6a7d28c9a63976e9eec38cab0f5","lang":"ja","lastmod":1338394320,"permalink":"https://blog.johtani.info/blog/2012/05/31/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%B8%E3%81%AE%E8%B2%A2%E7%8C%AE%E3%81%AE%E3%82%B9%E3%82%B9%E3%83%A1/","publishdate":"2012-05-31T01:12:00+09:00","summary":"録画してたEテレのスーパープレゼンテーションを見ててふと書きたくなったので、書いてます。 あとから読んだら恥ずかしくなりそうだけど。。。 「\u0026l","tags":["misc"],"title":"オープンソースへの貢献のススメ(Jugemより移植)"},{"contents":"JJUG CCC 2012 Springに参加してきました。 昨年のFallに続き、2回目です。 概要や、タイムテーブルはこちらを御覧ください。 今回は、午後一から参加しました。 色々と迷いましたが、つぎのを聞いて来ました。\nHotSpot vs JRockit ～ HotRockit到来の前に予習しよう！ Play! Framework - モダンで高速なWeb開発 Grails/Groovyの開発活用術 Scala 最新状況報告 From Swing to JavaFX SwingからJavaFXへのマイグレーションガイド JRockitは使ったことがなく（たぶん）、新鮮でした。いろいろなコマンドが用意されているなぁと。 あと、jvisualvmの使い方も知らないこともあったのでいい話が聞けました。 プレゼンに慣れているようで、プレゼン中に、コマンドラインの拡大＋コマンドのオプションに赤い下線を入れるなど、どうやってやっているのか、プレゼンの内容よりも気になってしまったのが本音です\nPlayは今回の目玉の一つでした。まだ、手元でPlayを触り始めたばかりだったので、概観がつかめたのが良かったです。 あとでスライドを見なおさないと。 頭がどうしてもServlet、JSPのため、未だにPlayに切り替えができてないので、もっと触ってみないとなぁと。 ちなみに、紆余曲折してまして、Play 1.2.4→Play 2.0（Javaアプリ）→Play 2.0（Scalaアプリ）と心変わりしまくりで、まだ完全に作ってないのに、ふらふらしてます。。。\nGrailsはGrailsを現場にどのように投入していくのがいいかという、技術よりは、政治的な話でしたが面白かったです。 実際に、あまり有名でないプロダクトを現場に導入するのに、Javaだからと無理やり説得してみたりｗ、開発コストがこれくらい下がりますという話をしてみたりと、いろいろやられているようでした。 あと、PlayのあとにGrailsということもあり、すこしPlayを意識した話もされていました。\nScalaはScalaDaysの話＋Scalaの最近の動向ということで、ある程度Scalaを知っている人がターゲットのようでした。 少し触っただけなので、何となく分かる部分もありましたが、最後の方はついていけてないです、すみません。。。 一番感じたのは、発表者の水島さんのScalaに対する愛情でしょうか。\n最後は桜庭さんのJavaFXのお話です。 一応、昔、JFreeChart＋Swingでちょっとしたものを作ったことがあるので面白かったです。 プレゼン自体もJavaFXで作成されていたり、オープニングがStarWars風だったりと凝ったプレゼンでした。 JavaFXとしては、JavaOneでも聞いたのですが、グラフやHTMLがリッチに書けるようになったことがびっくりです。\n実際のSwingアプリからJavaFXへの移行に関して、注意する点などがわかりやすく聞けました。 FXMLは確かに便利ですよねぇ。レイアウトをJavaで組むのがすごくめんどくさかったもんなぁ。\nさて、簡単ですが、感想でした。 今回一番残念だったのは、長丁場の割に電源の確保が難しかったことでしょうか。 ツイートしたり、メモ取ったりしたかったのですが、電源が乏しいので、Wi-fiオフにしてメモ取るのが限度でした。。。\n場所：オリンピック記念青少年総合センター 日時：2012/05/28 10:00 - 19:00 ◎13:10 - 14:00 C-1 HotSpot vs JRockit ～ HotRockit到来の前に予習しよう！ 谷本 心 @cero_t ◯HotSpot from Sun ◯JRockit from BEA 今は、どちらもOracle ◯違いは？ 1.歴史 2.プラットフォーム JRockitはMacではNG。Solarisは一部。 2.1Oracleさん曰く Solaris/Mac → HotSpot Windows/Linuxのサーバ → JRockit Windows/Linuxのクライアント → HotSpot 2.2谷本さんは？ WebLogic → JRockit 1.4、5の時の開発環境はJRockit 当時はJRockitの解析ツールがカッコ良かった 3.解析ツール 3.1コマンドラインツール プロセス HotSpot ： jps JRockit ： jrcmd スレッドダンプ HotSpot ：jstack JRockit ： jjrcmd \u0026lt;pid\u0026gt; print_threads ヒープ解析 HotSpot：jmap -histo \u0026lt;pid\u0026gt; JRocket：jrcmd \u0026lt;pid\u0026gt; heap_diagnostics HotSpot： JRockit：jrcmd \u0026lt;pid\u0026gt; 他にもJRockitは色いろある。 print_utf8poolとか（内部の文字列が出てくる） 3.2GUIツール HotSpot：jvisualvm　NetBeansベース JRockit：Mission Control　Eclipseベース メモリリークの解消をツールを使ってみてみましょうデモ。 ・hprofファイルを吐き出して、jvisualvmで読みこむのが楽な方法 ・jrmcはヒープダンプファイルを読み込む機能がない。 memleakというツールがある。アプリを起動してから、プロセスを右クリックして選択可能。 タイプグラフや割当てトレースみたいなものが使えるよ。 フライトレコーダーというのもあるよ。 4.HotRockitの紹介 まだいつ出るのかなぁという状態だけど、HotSpotにJRockitのツールも使えるようになるVMが出る模様。（2013？） ※デモ中に画面拡大した時に、赤線でラインを引いているのがすごく気になった。（便利なツールなのかな？そこだけ？） ◎14:15 - 15:05 C-2 Play! Framework - モダンで高速なWeb開発 池田尚史 @ikeike443 ◯自己紹介 Play!Frameworkコミッター 日本Playframeworkユーザ会 ◯アンケート メイン言語は？Java多数 触ったことある？半分くらい？ Play1？Play2？半々くらい プロダクションで使ってる人？3人 ◯Playframeworkって？ JEEではないよ。 Webだよ。 ServletとかXML使ってないよ。 ◯JEEは難しいよね。RailsとかDjangoから流れてくると。 ◯Webフレームワーク なので、Webアプリが作れればいいよね。 開発すべきものに注力して、抽象化とかを頑張らないようにと。 ◯ライブコーディング！ Play2.0のScalaアプリみたい。 プロジェクト作成～編集して起動まで。 エラーを起こして、エラーがどのように表示されるか。 エラーのリンクをクリックして、エディタを起動するということも可能みたい。 TODOとかで、まだ終わってないのも記述可能。 パラメータとControllerの関数の引数が勝手にひもづけられますよと。 ◯歴史 Servletとかもあった。 1.2からNetty、Websocket、Scalaサポート 2.0.1：Scalaで書き直し。Netty+Akkaで非同期 ◯１と２のちがいは？ ・Play1 Javaで書かれたJavaのフレームワーク。Scalaはプラグインサポート ・Play2 Scalaで書かれたScala/Javaのフレームワーク ◯Playの特徴 ステートレスとかノンブロッキングとかリアクティブとか ・高生産性 XMLがないし、unzipするとすぐ使えるよ。 ホットスワップできるよ。 CoffeeScript、LESSサポートも。assetsに入れとくとコンパイルしてくれて静的コンテンツにしてくれる。（Railsにも似たようなのあったっけか？） ・ステートレス HttpSessionがない→必要ならMemcachedとかで管理してね。 「デプロイ→ニーズ・状況に応じて即時スケールアウトという時代じゃないか？」という主張 Playはステートレス養成ギブスであり、時代の要請にマッチ ・広範囲な型安全 コンパイルしてエラー検知 ・ノンブロッキングI/O 非同期処理が手軽に書けるように考えられている。 →リアルタイムWebの時代 NettyやAkkaにより実現されてるのがいい Akkaを使ったアプリを書くと、長い処理のActorを別サーバにするなども設定で変更が可能。 ◯テスタビリティ BDDフレームワーク（Specs2？） Viewもテストできるぞと。 ◯事例 Klout：ソーシャルスコアリング イギリスのガーディアン：コンテンツAPIの実装がPlay2 MinecraftのWebサイト ◎15:20 - 16:10 C-3 Grails/Groovyの開発活用術 ～Java EE資産を活かして開発を加速する～(仮) 上原潤二 山本剛 ◯充電中のためお休み ◎16:25 - 17:15 C-4 Scala 最新状況報告 ～或いはScala Days 2012リポート～ 水島宏太 ◯自己紹介 言語を作るのが夢みたい。 ◯Scala最新状況報告 ScalaDaysの雰囲気を伝えるよと。（どっちかというと、旅行記かも） ◯Scala？ ・オブジェクト指向関数型言語 ハイブリッドじゃなくて、統合したもの ・強力な静的型付け NullPointerExceptionなども起きにくい ・超強力なコレクションフレームワーク ・Javaと同等の実行速度 ・コードが簡潔（1/4くらい） ◯Scala採用企業 Twitter、Amazon.com（どこに使ってるかは不明）、Foursquare、LinkedIn、VMWare、Klout、Tumblrなど ◯Scalaのバージョンは？ 2.10が開発版。2.9.2がステーブル版。 ◯開発体制 Typesafe＋世界のContributor Typesafeメンバの議決でいろいろ決定 githubでオープンに開発 ◯ScalaDays2012の目玉 豪華ゲスト（私は、わからなかった） Scala2.10の新機能紹介 今後のScala、多数の応用例 ◯ScalaDays2012を見ての方向性 ・All-in-oneパッケージの提供 Typesafe Stackの提供 重要なツール sbt（Simple Build Tool） gitter8（プロジェクトテンプレート生成ツール。githubを元に色々取ってくる？） Akka Play 2.0 Framework ・学習コストの削減 言語機能のモジュール化 高度な開発者が使う昨日はデフォルトOff ・バイナリ互換性問題への対処 ・Minor Release間での互換性を維持 MIMAでジドウテキに非互換性を検出 ・Major Release間では互換性は保証しない。 No more java.util.Date ソース互換性は「概ね」保証される deprecatedは次期メジャーバージョン時に削除される。 ・Scala IDEへの注力 インクリメンタルにコンパイルしてくれるから、遅いのも気にならなくなるかも。 デバッガとか、できるよと。 ・さらなるパフォーマンス改善 Value classes AnyValを継承したクラスが作成可能 該クラスのオブジェクトがインライン化 Pimp my libraryによるヒープ使用料が0に！ ◯2.10最新機能紹介 \u0026#34;1+2=#{1+2}\u0026#34;ができない s\u0026#34;1+2=${1+2}\u0026#34;ができるように String = 1 + 2 = 3 f\u0026#34;1=${1}%03d\u0026#34;もできるようにSring = 1 = 001 自分でStringコンテキストにメソッド追加できるらしい（聞き取った日本語が合ってるか？） とか。（かなり不安。。。まだまだわかってない。。。） ◎17:30 - 18:30 BOF-B-1 From Swing to JavaFX SwingからJavaFXへのマイグレーションガイド 櫻庭 祐一 ◯JavaFX 次世代のJava GUI Library Swing+Java2D+α JavaSE8から標準（JavaFX3.0） ◯サンプル クラス名がいろいろ変わってる。 ◯はまりそうなところ コンテナへの追加がちょっと違う イベントリスナは1種類のみになった。（Genericsを使うようになったよと。） ◯Bind 値が変わるとModelが勝手に検知して変わるみたい。 双方向もあり。これだとEventを書かなくても良くなりつつ有るよと。 ◯シナリオベースでマイグレーション考えましょう 1.JavaFX in Swing JavaFXにSwingを埋め込むことはできないぞと。 SwingでできないことをJavaFXでやりますよと。 おー、グラフが動く。JavaDocのHTMLも綺麗に出てる。 使い方：JFXPanelを使う シーングラフを記述可能 データのやり取りが大変。Threadが違うから。 パフォーマンスが落ちます。Java2Dで画像を書くので遅いですよと。 新規のものはJavaFXで書きましょうと。 2.Swing to JavaFX w/o FXML SwingをJavaFXに置き換える。 使い方が違うものはTableViewなど、◯Viewとついてるもの。 ちょっと考えるのはLayout Swing：コンテナ＋レイアウトマネージャー JavaFX：コンテナがレイアウトを含む BorderPaneクラスとか。 問題はTableとか Swing：TableModel JavaFX：BeanをColumnにバインド 3.Swing to JavaFX w/ FXML ・FXML GUIの構造をXMLで表す。 シーングラフを表現。 スキーマレス クラス：要素 プロパティ：属性 or 要素 アノテーションバリバリです。これで、FXMLとJavaのバインディングができるよと。 ツール Java ：NetBeans e(fx)clipseってのがあるかも。 FXML：Scene Builder ","date":1338259500,"dir":"post/2012/","id":"de734259dfb9addebe2b226d96b4f744","lang":"ja","lastmod":1338259500,"permalink":"https://blog.johtani.info/blog/2012/05/29/jjug-ccc-2012-spring%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-05-29T11:45:00+09:00","summary":"JJUG CCC 2012 Springに参加してきました。 昨年のFallに続き、2回目です。 概要や、タイムテーブルはこちらを御覧ください。 今回は、午後一から参加","tags":["勉強会"],"title":"JJUG CCC 2012 Springに参加してきました。(Jugemより移植)"},{"contents":"PlayFramework2.0を触ってみてます。 ちょっとコーディングしたくなったのと、最近のアプリの作成の調査も兼ねて。 まぁ、せっかくなので、Solr検索のアプリでも作ってみようかと言うことで触ってます。 ただ、Solr検索アプリでしかなく、今のところDBを使わないので、実はPlay Frameworkじゃなくてもいいのではないかという疑問も。。。\nまだ、触り始めたばかりなので、なんともですが。感想を。 たぶん、Ruby on Railsに似ているのかなと。 RoRは仕事で少し関わったので、なんとなく知っていますが、アプリの作成手順や、ディレクトリ構成などが似ている気がします。\nコントローラーの生成のタイミングとか、内部でオブジェクトをSingletonで保持する方法とかのイメージがまだ良くつかめていない状態で、まずは、Solr検索部分（Palyにあんまり関係ないところ）を実装しているところです。\n現状で一番の疑問点は、Eclipseプロジェクト化した時の参照ライブラリのパスに関するところでしょうか。 Play Frameworkは「play new ほげほげ」コマンドを実行するとアプリのディレクトリ構成が作成されます。 このあとに、eclipsfyというplayのコマンドを実行すると、Ecilpseのプロジェクトファイルが作成されます。 この時、PlayFrameworkが利用するjarファイルたちが参照ライブラリとしてクラスパスに設定されます。\nこのパスには、PlayFrameworkのインストールディレクトリが含まれた絶対パスが記述されるのですが、 複数人で開発するときにはどうしているのかなぁと。 あと、BitbucketやGitHubにアップするときもどうするのかなぁと。 以前、この疑問ツイートして、頂いた回答としては、環境変数として定義して、各自で設定してもらうというものでした。 私も同じ事を考えていたので、腑に落ちたのですが、他にもっといい方法があったりするんでしょうか？ クラスパスやEclipseプロジェクトのファイルをアップしないというのもあると思いますが、それもちょっとなぁと。 なにか、オススメとかあれば、教えていただけると嬉しいです。\n最近、ブログ更新してなかったのもあったので、まずは、導入編でした。\n","date":1337151314,"dir":"post/2012/","id":"78f002cc3d512ea302c900d1da4dfeec","lang":"ja","lastmod":1337151314,"permalink":"https://blog.johtani.info/blog/2012/05/16/playframework-2-0-java%E3%81%AE%E6%96%B9-%E3%82%92%E8%A7%A6%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%A6%E3%82%8B/","publishdate":"2012-05-16T15:55:14+09:00","summary":"PlayFramework2.0を触ってみてます。 ちょっとコーディングしたくなったのと、最近のアプリの作成の調査も兼ねて。 まぁ、せっかくなの","tags":["備忘録"],"title":"PlayFramework 2.0(Javaの方)を触ってみてる(Jugemより移植)"},{"contents":"lucene-gosenの最新版（2.0.1）をリリースしました。\nプロジェクトページよりダウンロードが可能です。\n今回の修正では、Java7でUnicodeのバージョン変更に伴う対応（詳細はこちらを参照）を行なっています。\nリソース周りの対応はまた後日。。。すみません。2012/05/16 遅くなりましたが、昨晩、JavaDocをアップしました。\n","date":1336494900,"dir":"post/2012/","id":"c4b418764dca70aebfc965899a3fa7e5","lang":"ja","lastmod":1336494900,"permalink":"https://blog.johtani.info/blog/2012/05/09/lucene-gosen-2-0-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9java7%E5%AF%BE%E5%BF%9C/","publishdate":"2012-05-09T01:35:00+09:00","summary":"lucene-gosenの最新版（2.0.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、Java7で","tags":["lucene-gosen"],"title":"lucene-gosen 2.0.1リリース（Java7対応）(Jugemより移植)"},{"contents":" IDの秘密 (丸善ライブラリー―情報研シリーズ) 非常に面白く読めました。 バーコードの話に始まり、最後はシステムで付与するIDに関する考慮点まで幅広くIDについて語られています。\n適度に配置されたコラムがまた面白く、ここまで書いてもいいのかな？と思いながらも楽しく読ませて頂きました。 2次元バーコードが汚れに強いのも知らなかったし、チロルチョコの話は知らなかったし、指コレクションとか面白すぎです。 また、JRのSuicaの導入に7年もかけている点などは、やはりすごい技術なのだなぁというため息混じりの感想です。 それほど長い期間のテストや設計は想像がつかないです。\n最後の2章（７，８章）については、エンジニアの以外のシステムに関わる方やエンジニアになられたばかりの方たちにぜひ読んで欲しいと思いました。 もちろん、エンジニアの方にも読んでほしい内容です。\nいくつか疑問点や気になる点もあったので。\n「静脈や指紋が人によって異なるって確率はどうやって決めたんだろう？」 Twitterの説明文のあとにFBの画面の図番号が書いてある。 日本語がデコードされたけど、QRコードの文字コードって、この中に含まれてるのかな？それとも規格で決まってるのかな？ 最後に、書影がNIIに合ったので撮影しました。写真へのリンクです。\n","date":1335794635,"dir":"post/2012/","id":"95c0a5b8a66950b5f22dd82a8dfe0ce5","lang":"ja","lastmod":1335794635,"permalink":"https://blog.johtani.info/blog/2012/04/30/id%E3%81%AE%E7%A7%98%E5%AF%86%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-04-30T23:03:55+09:00","summary":"IDの秘密 (丸善ライブラリー―情報研シリーズ) 非常に面白く読めました。 バーコードの話に始まり、最後はシステムで付与するIDに関する考慮点まで","tags":["読書"],"title":"「IDの秘密」を読みました。(Jugemより移植)"},{"contents":"WebSolrの話があるらしいというのを嗅ぎつけて、初めてHeroku JP Meetupに参加しました。 herokuもWebSolrも知りつつ、手を出していなかったので、いい機会でした。 （SignUpだけ、勉強会直前に済ませましたｗ）\nHerokuはAWS上に構築されたアプリケーションプラットフォームで、簡単にアプリをデプロイして動作させることができるようです。 Ruby on Railsを使うのが多いみたいですが、他の言語も利用できると。 で、herokuの面白いところは、アドオンとして、開発が簡単にできるようなしくみが用意されていることみたいです。 今回発表のあった、IronMQ、WebSolr、PaperTrailもアドオンとして用意されており、簡単に利用することが可能です。 IronMQはメッセージキューとして利用できます。\nWebsolrはSolrを簡単に利用できる形で提供しているものになります。 今、利用できるのは3.5.0のようで、最新版（3.6.0）になるのはまだ未定のようです。 今回の発表はWebSolrの話しもありましたが、基本は全文検索の仕組みとKuromojiの説明でした。 ただ、残念ながら、Kuromojiは3.6.0からの提供となるので、現時点では利用できないようです。 あとで、聞いた話だと、schema.xmlを自分で変更できるようです。 ただ、jarファイルを置いたりはできないようなので、lucene-gosenを利用するとかはできないみたいですが。。。 ほかにも、bonsai.ioとして、ElasticSearchの提供も行うようです。 まだ、利用はできないようですが。\n最後がPapertrailです。 こちらは、ログを保存して、検索、グラフ化（視覚化）してくれるアドオンです。 まだ、ベータのようですが、ログを保存してくれるようです。無料版もあるようです。 アドオンとしての機能もそうですが、利用しているグラフ化のツールなど、面白そうなものが利用されていました。\nLTはRuby使いの方が多かったです。\nRuby使いではないのですが、いろいろなアドオンが用意されており、サービスを簡単に提供することができそうだという印象をうけ、ちょっと使ってみたいなぁと思いました。 普段参加していない勉強会だったので、普段では知りえない興味ある話が聞けて面白かったです。\n余談ですがPapertrailの人が利用していた、slideshareのようなサービスのSpeaker Deckもよさそうなので登録してみました。 次に何か発表があった時には資料はこっちにアップしてみようかなぁと\n以下は、いつものように自分用のメモです。\n日時2012/04/20 19:00 to 21:00 会場：パソナグループ本部　呉服橋 ◎オープニング – Ayumu AIZAWA (Heroku Evangelist） ◎新入社員からの挨拶 – Koichi SASADA (Ruby Developer） 前職：大学教員 仕事：CRuby開発 Heroku使った事無いですｗRailsもよく知らないですｗ RUby2.0のリリースがゴール。2013/Feb 性能アップのことやってます。 ◎IronMQ – Chad Arimura (Iron.IO)\n「メッセージキューは涼しいです。」 （Google翻訳による日本語訳付きのスライド） Aggregation、Distribution。。。 IronMQ Elastic、RESTful heroku addon ironmq:rust 簡単にheroku上にキューが用意できるアドオンです。 Q：メッセージがキューに到達したのを確認する方法か？ A：ステータスコードが帰ってくる。 Q：データのサイズのリミットは？ A：postのリミットはある。S3とかに巨大データをおいて、ポインタを渡すとかしてほしい。 Q：キューへの到達の成功の保証は？ A：アプリケーション側で判断してください？ ◎Search \u0026amp; Indexing on Heroku – Nick Zadrozny (Websolr) スライドはこちら。\n※ツイートしてて、メモとってなかったので、ツイートをコピペ。 次はWebsolrのお話 Bonsai.io？ Bonsai by onemorecloud - http://bit.ly/JjCuaE SQLのLIKE検索はO(n)でおそいねぇと。 クエリのパースについての話。 今度は転置インデックスのお話。 Termへの分割ってどーすんの？というお話。Tokenizeのお話。 その１：N-GramというTokenizeの方法。N文字ずつ先頭からTermを切り出す。開始位置は1文字ずつずらしていくと。 N-Gramはノイズがのるし、多くのTermがでてきちゃうよと。 その２：そこで、次は形態素解析ですね。 先週、Lucene/Solr 3.6.0がリリースされて、Kuromojiという日本語向けの形態素解析器がでましたよ。 Kuromojiはこちら。（Lucene版とは少し違うけど。）http://atilika.org/ Kuromojiのサーチモードのお話。 通常は、「関西国際空港」という単語になってしまうのを、Kuromojiでは「関西」「国際」　「空港」という切り方の単語も出してくれると。 ちなみに、lucene-gosenでは、サーチモードはないんですねぇ。。。 「の」はどこに消えたんだ？？そこの説明は？ ElasticSearchやSolrのコアの部分でLuceneを使ってるよ。 ElasticSearch　http://bit.ly/qjjvWp Kuromojiはユーザ辞書をサポートしてるよ。 Q：まだ、3.5.0では？ A：もうすぐやります ◎log analysis for your Heroku app – Eric Lindvall (Papertrail)\nheroku上にログを貯めて、検索したりグラフ化したりできるようになりそうなもの。 [スライドはこちら](http://speakerdeck.com/u/lindvall/p/log-analysis-for-your-heroku-app) ログを貯めて、検索や可視化できるようにするサービスみたいです。 まだ、アイデアレベルのものも発表資料には含まれていました。 内部で利用しているツールなど、資料の最後に出てきますが、色々と面白そうなものがありました。 ◎Lightning Talks ◯Receibo ( @shu_0115 ) デザイナーｘエンジニアハッカソンでの成果らしい。 Webベースの家計簿アプリ。 買ったものの名称と料金を入れるだけ。 ◯Heroku + Pusherで作る！リアルタイムアプリケーション ( @satococoa ) WebSocketみたいなことが、Pusherでできるらしい。 http://www.slideshare.net/satococoa/heroku-pusher　◯Herokuアドオンを作ってみてわかったこと ( @takkam ) ◯heroku client のちょっと進んだ使い方 ( @hsbt ) ◯love heroku? – we love herokuのご紹介 ( @ppworks ） ","date":1334935380,"dir":"post/2012/","id":"c92c12a28fa219ad1aab60865046ff05","lang":"ja","lastmod":1334935380,"permalink":"https://blog.johtani.info/blog/2012/04/21/heroku-jp-meetup-4%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/","publishdate":"2012-04-21T00:23:00+09:00","summary":"WebSolrの話があるらしいというのを嗅ぎつけて、初めてHeroku JP Meetupに参加しました。 herokuもWebSolrも知りつつ、","tags":["勉強会"],"title":"Heroku JP Meetup ＃4に参加しました。#herokujp(Jugemより移植)"},{"contents":"先日、Solr入門のサンプルschema.xmlの3.6.0対応版の作成をしていて、気になったことがあったので、 メモとして残しておきます。\nSynonymFilterFactoryの属性「tokenizerFactory」に関連する話です。 （「Apache Solr入門」の36-37ページに記載があります。）\nSynonymFilterFactoryでは、類義語設定ファイルを読み込む際に利用するTokenizerFactoryを「tokenizerFactory」という属性で指定できます。（以下は書籍の記述を抜粋）\n\u0026lt;filter class=\u0026#34;sold.SynonymFilterFactory\u0026#34; synonyms=\u0026#34;synonyms.txt\u0026#34; ... tokenizerFactory=\u0026#34;solrbook.analysis.SenTokenizerFactory\u0026#34;/\u0026gt; このように、TokenizerFactoryが指定できます。\nただ、こちらの記事で書いたように、 Solr 3.6.0のexampleのschema.xmlではCJKのフィールドは次のように設定されています。\n\u0026lt;!-- CJK bigram (see text_ja for a Japanese configuration using morphological analysis) --\u0026gt; \u0026lt;fieldType name=\u0026#34;text_cjk\u0026#34; class=\u0026#34;solr.TextField\u0026#34; positionIncrementGap=\u0026#34;100\u0026#34;\u0026gt; \u0026lt;analyzer\u0026gt; \u0026lt;tokenizer class=\u0026#34;solr.StandardTokenizerFactory\u0026#34;/\u0026gt; \u0026lt;!-- normalize width before bigram, as e.g. half-width dakuten combine --\u0026gt; \u0026lt;filter class=\u0026#34;solr.CJKWidthFilterFactory\u0026#34;/\u0026gt; \u0026lt;!-- for any non-CJK --\u0026gt; \u0026lt;filter class=\u0026#34;solr.LowerCaseFilterFactory\u0026#34;/\u0026gt; \u0026lt;filter class=\u0026#34;solr.CJKBigramFilterFactory\u0026#34;/\u0026gt; \u0026lt;/analyzer\u0026gt; \u0026lt;/fieldType\u0026gt; 3.6.0以前は、solr.CJKTokenizerFactoryを利用していましたが、3.6.0からはCJKTokenizerFactoryがdeprecatedになってしまい、代わりにStandardTokenizerFactory＋CJKBigramFilterFactoryの組み合わせになっています。 exampleのCJKのフィールドタイプ設定を利用して、かつ、そのフィールドにSynonymFilterを利用する場合に、 StandardTokenizerFactoryを指定してしまうと、類義語が展開できなくなってしまうので注意が必要です。\nCJKのフィールドでSynonymFilterを利用する場合は、類義語の設定ファイル内の記述を自力でCJKTokenizerが分割する形で記述する（まぁ、やらないでしょうが）か、deprecatedですが、CJKTokenizerFactoryを利用するのが現時点での対応でしょうか。\nなお、これに絡んで、このようなチケットもできています。\nSyntaxHighlighterを導入してみました。 ちょっとはみやすくなってますかね？ まだ、SyntaxHighlighterの設定を調べながら使っているので、コロコロ変わるかもしれないですが、気にしないでください。 ","date":1334592971,"dir":"post/2012/","id":"12d1e0cf7396dd33a9bbbca8da4cbc68","lang":"ja","lastmod":1334592971,"permalink":"https://blog.johtani.info/blog/2012/04/17/solr-3-6-0%E3%81%AEcjk%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%81%A8synonymfilterfactory%E3%81%AE%E6%B0%97%E3%81%AB%E3%81%AA%E3%82%8B%E7%82%B9/","publishdate":"2012-04-17T01:16:11+09:00","summary":"先日、Solr入門のサンプルschema.xmlの3.6.0対応版の作成をしていて、気になったことがあったので、 メモとして残しておきます。 S","tags":["solr"],"title":"Solr 3.6.0のCJKの設定とSynonymFilterFactoryの気になる点(Jugemより移植)"},{"contents":"先日の続きです。「Apache Solr入門」の2章から4章の説明について、Solr3.6.0で動作させる時の変更点を以下に書いていきます。 なお、前回も説明しましたが、3.6.0からKuromojiという形態素解析器がSolrに同梱されるようになりました。 これから説明する2章の変更点の手順ですが、Kuromojiとlucene-gosenそれぞれの利用方法について説明します。 添付のschema.xmlについては、基本的にKuromojiを利用する形に変更してあります。 それに加えて、lucene-gosen用のフィールドを別途追加で定義しました。 これらのフィールド名については、次の表の用になります。 適宜、書籍のフィールド名と置き換えながら読み進めたり、試したりしてください。\nKuromojiフィールド lucene-gosenフィールド title title_gosen author auther_gosen summary summary_gosen intended_reader intended_reader_gosen from_author from_author_gosen toc toc_gosen 2章 2.1.3 schema.xmlのバージョン（27ページ） Solr3.xではschema.xmlのファイルの最新バージョンは**1.5**になっています。\n2.2.3 代表的なトークナイザ（35ページ） solrbook.analysis.SenTokenizerFactoryは必要ありません。 Solr 3.6.0からはKuromojiと呼ばれる形態素解析器が用意されています。 solr.JapaneseTokenizerFactoryがそれに該当します。 これとは別に、lucene-gosenを利用する場合、Solr向けのトークナイザが用意されています。 solr.GosenTokenizerFactoryがそれに該当します。\n2.2.4 代表的なトークンフィルタ（37ページ） 以下の2つについてはKuromojiが同等のトークンフィルタを提供しています。 また、lucene-gosenを利用する場合は、lucene-gosenに同等のトークンフィルタが存在します。\nsolrbook.analysis.KatakanaStemFilterFactory solrbook.analysis.POSFilterFactory 次のものがSolr 3.6.0に用意されているので、こちらを利用します。\nsolr.JapaneseKatakanaStemFilterFactory solr.JapanesePartOfSpeechStopFilterFactory それぞれ、次のものがlucene-gosenにあるので、こちらを利用します。\nsolr.GosenKatakanaStemFilterFactory solr.GosenPartOfSpeechStopFilterFactory 2章向けのschema.xmlはこちらです。その他のtxtファイルについては、特に変更はありません。\n3,4章は特に変更はありません。Solrの起動の仕方にだけ注意してください。（-Dsen.homeは必要ありません）\n以上が4章までの修正点になります。\n昨日に引き続き、眠い目をこすりながら修正したので、おかしいかも。 動かない、意味がわからないなどあれば、コメントorツイートいただければと思います。\n2012/06/14提供しているschema.xmlに関して修正を加えました。こちらの記事で説明しているautoGeneratePhraseQueriesの値をtext_gosen、text_cjkのフィールドに対してtrueを設定する記述を追記しました。\n","date":1334339880,"dir":"post/2012/","id":"d77cdb466c5063b99c5aea58e6da4d32","lang":"ja","lastmod":1334339880,"permalink":"https://blog.johtani.info/blog/2012/04/14/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C2%E7%AB%A04%E7%AB%A0/","publishdate":"2012-04-14T02:58:00+09:00","summary":"先日の続きです。「Apache Solr入門」の2章から4章の説明について、Solr3.6.0で動作させる時の変更点を以下に書いていきます。 な","tags":["solr"],"title":"「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（2章～4章）(Jugemより移植)"},{"contents":"以前より、アナウンスしていた、Kuromojiという日本語形態素解析が含まれるLucene/Solr 3.6.0がリリースされました。\n以下、各リリース内容について簡単に説明されているページへのリンクです。\nSolrリリースのお知らせ\nLuceneリリースのお知らせ\nSolr 3.6.0の変更の目玉は各言語のAnalyzer/Tokenizerの設定がexampleのschema.xmlに含まれるようになったことです。 Kuromojiという日本語用の形態素解析器もexampleを起動すればすぐに利用できる形になっています。 Kuromojiを利用する場合は、exampleのschema.xmlが参考になるでしょう。\nあと、大きな変更は、Ivyに対応した点です。ソースをダウンロードするとわかりますが、依存するjarファイルが含まれない形に変更されています。 SVNからチェックアウトした場合も同様です。ビルドにはネットワークに接続している環境が必要になりました。\nまた、このリリースに合わせて、以前書いた「Apache Solr入門」のサンプルについての記事も変更が必要かと思い、 前回の記事をベースに以下に変更した記事を書いたので、参考にしてください。 今回は、Kuromojiという日本語形態素解析がデフォルトで含まれるようになったので、 Kuromojiの利用方法とあわせて、lucene-gosenの利用方法も記載します。 サンプルのschema.xmlについては、Kuromoji、lucene-gosenが同時に利用できる形のものを用意しました。\nサンプルのschema.xmlを最新版（Solr 3.6 + lucene-gosen-2.0.0-ipadic）のものを用意しました。 なお、あくまでも、3.xでlucene-gosenを利用する場合の「Apache Solr入門」のサンプルプログラムの変更点（とりあえず、4章まで）の違いについて記述します。 申し訳ございませんが、1.4と3.xの違いについての説明はここでは行いません。\n以下では、各章でschema.xmlに関連する記載のある部分を抜粋して、変更点と変更したschema.xmlのリンクを用意しました。参考にしてもらえればと思います。\n1章 1.6.1 N-gram（17ページ） 1.6.1の手順に変更はありません。 サンプルプログラムが入っているZip「solrbook.zip」のintroduction/ngram/schema.xmlファイルの代わりに こちらのschema.xmlを利用してください。 ※なお、Solr 3.6.0から、SOLR_HOME/example/solr/conf/schema.xmlにデフォルトでN-gramで利用しているCJKTokenizerの設定が入るようになっています。 （実際にはCJKTokenizerではなく、CJKBigramFilterとCJKWidthFilterに変更されています。）\n1.6.2 形態素解析（18ページ～20ページ中盤まで） CJKと同様、exampleにKuromojiを利用した設定がすでに記述されています。text_jaというフィールドタイプになります。書籍の21ページ1行目に記載のある、 「Field」のテキストボックスに入力する文字列を「text_ja」とすると、Kuromojiを利用した形態素解析結果が表示されます。exampleですでに幾つかのフィルタも設定されているため、書籍の出力結果とは異なる表示となるはずです。\nlucene-gosenを利用する場合は手順が大きく変わります。 Senを利用する場合、Senの辞書のビルド、Senのjarファイルの配置、Senを利用するためのTokenizerクラスを含んだサンプルjarの配置という作業があります。 lucene-gosenではコンパイル済みの辞書がjarファイルに含まれています。 また、Solr向けのTokenizerもlucene-gosenのjarファイルに含まれています。 lucene-gosenを利用して形態素解析を体験するための手順は次の流れになります。 なお、schema.xmlについては上記N-gramでダウンロードしたschema.xmlに形態素解析の設定もあわせて記載してあります。\njarファイル（lucene-gosen-2.0.0-ipadic.jar）をダウンロードして、$SOLR/example/solr/lib（libディレクトリがない場合は作成）にコピーします。 コピーが終わりましたら、次のように$SOLR/exampleディレクトリでSolrを起動します。 （-Dsen.homeは必要なし）\n$ java -jar start.jar あとは、書籍の記述にしたがって管理画面のAnalysis画面で動作を確認します。 ほぼ、図1-6と同じ結果になっていると思います。 （lucene-gosenで出力される情報には本書のサンプルよりも多くの情報が含まれています。また、サンプルでは、形態素解析の後の単語に基本形を採用しているため、「な」が「だ」として出力されています。基本形を出力する場合は後述するこちらで紹介したTokenFilterを利用すれば可能です。）\n2章については後日説明することにします（眠くなってきた。。。）\n動作しないなどあれば、コメントください。\n2012/06/14追記提供しているschema.xmlに関して修正を加えました。こちらの記事で説明しているautoGeneratePhraseQueriesの値をtext_gosen、text_cjkのフィールドに対してtrueを設定する記述を追記しました。\n","date":1334339100,"dir":"post/2012/","id":"904b07170a0ce481b7491e7fecce4f79","lang":"ja","lastmod":1334339100,"permalink":"https://blog.johtani.info/blog/2012/04/14/lucene-solr-3-6-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9---apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0/","publishdate":"2012-04-14T02:45:00+09:00","summary":"以前より、アナウンスしていた、Kuromojiという日本語形態素解析が含まれるLucene/Solr 3.6.0がリリースされました。 以下、各","tags":["solr"],"title":"Lucene/Solr 3.6.0リリース / 「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（1章）(Jugemより移植)"},{"contents":"Twitterでこのブログ流れてきて、気になったので、流し読みして簡単にメモ。 Amazonのサービスでスケールする検索サービスみたい。\n主に、機能面です。価格とかはみてないです。\nデータと検索トラフィックに対して自動でスケール（※automaticってのがどういう感じかは調べてないです） CloudSearch APIsでアクセス可能。AWS管理コンソールからオペレーションできる。コマンドツールもある データ登録にHTTPSも使えますよ。データ形式はJSON、XML、SDF（Search Document Format）と呼ばれるものに準拠したもの near real-timeで検索可能になる。RAMにインデックスを保持して更新処理が早くなる（Lucene/Solrと一緒か？） ステミングとかストップワードの設定変えたらre-index ファセット、フィールド指定検索が可能。（ファセットはファセットクエリみたいなのもできるのかな？） データ量が増えたら、サーチインスタンスを追加するか、インスタンスタイプを大きくしてスケールする？ トラフィックが増えたら新しいインスタンスにデータをレプリケートしてインスタンスを追加する 簡単に実現できるよ。ファセット検索、全文検索、And/OR検索式、ランキングのカスタマイズ、フィールド指定ソート、フィールド指定検索、テキスト処理オプション（ストップワード、類義語、ステミングのような） ここから詳細のドキュメントが見れるみたいなので、また、見てみます。\nあと、WikipediaをCloudSearchで動かしてるデモとそれに関する記事もあるみたいです。これも暇を見つけて眺めてみます。\n","date":1334241069,"dir":"post/2012/","id":"bed3b7fcc1294e23639057435ac8756a","lang":"ja","lastmod":1334241069,"permalink":"https://blog.johtani.info/blog/2012/04/12/%E3%83%A1%E3%83%A2amazon-cloudsearch%E3%81%8C%E5%87%BA%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F%E3%82%88/","publishdate":"2012-04-12T23:31:09+09:00","summary":"Twitterでこのブログ流れてきて、気になったので、流し読みして簡単にメモ。 Amazonのサービスでスケールする検索サービスみたい。 主に、","tags":["備忘録"],"title":"【メモ】Amazon CloudSearchが出てきましたよ(Jugemより移植)"},{"contents":"JavaOne Tokyo 2012に参加してきました。 4/4-4/5の2日間開催されていたのですが、子供が体調を崩してしまい、4/5のみの参加となりました。 4/4はTwitterのTLを眺めて、羨ましがってました。\n7年ぶりに日本で開催されたJavaOneみたいです。 そういえば、7年前くらいに参加した記憶があるなぁと。\n会場入りして最初の感想は年齢層が高いなぁと。 最近、勉強会によく顔を出すようになったのですが、勉強会とは年齢層が少し異なりました。 まぁ、私も年齢層を上げている一人ではあるのですが。。。 Javaも熟成してきてるなぁというのが最初の感想でした。 あと、思ったよりもスーツ率は低かったと思いました。（5割はいましたが） 一番違和感を感じたのは、会場の所々の色が「赤い」ことです。。。\n以下は私が参加したセッションのカンタンな感想です。\nJava EE6 Modeling　JS2-01　#jt12_s201\nJavaEEから離れてはや数年。私が関わっていた頃はEJB2.0が出たくらいのタイミングだったので、 色々と変わってきているなぁというのが第一印象です。 CDI、Singleton EJBなど、知らない単語もちらほらと。 earではなく、warファイル1つで済む、jQueryをリソースjarとしてパッケージングしてwarファイルに入れられるなどは簡易になっていいなぁと。 web.xmlがアノテーションで記述できて要らなくなるという話は一長一短だと思いました。 一覧性があるからいいと思うこともあるので。 中国の方？の英語だったので少し特徴的でした。すこしは頑張ってみたものの、やはり同時通訳を聞いてしまって反省しています。。。\nマルチコアCPU時代のJavaプログラミング　JS2-14　#jt12_s214\nF社の方が実際に経験されてきた性能関連のプログラミングについての話でした。 現時点のJavaでマルチコアCPUで気をつけるべきプログラミングの観点をわかりやすく説明されたいいセッションでした。 詳細は下のメモを見ていただけるといいですが、色々とプログラミングで気をつけるべき点を説明されていました。 いいおさらいになりましたし、忘れていることや知らないこともあって勉強になりました。 TLでも見かけましたが、モダンJavaプログラミングみたいな、今のJavaでのプログラミングの気をつけるべき点を書いた書籍があるといいかもなぁと思いました。 あと、もうひとつ私が好印象だと思ったのは、F社の製品の紹介などがなかったからかもしれませんｗ\nサービス維持・発展を踏まえた楽天オークションのJava EEによる開発と運用　JS2-23　#jt12_s223\n楽天オークションの開発をサれている方の立ち上げから現在に至るまでの開発メンバーの管理の仕方や 実際に利用している開発手法、気をつけている点のお話です。 スライドに書いてあること以外のことを発表者の方が話をされており、もう少し、喋る内容に関連した図などを入れてもらえるとわかりやすかったかもしれません。 あとは、WebLogicの管理画面が使いやすくていいという話のあとに、GlassFishに移行していますという話があったりと、少し「？」が浮かぶ部分がありました。。。\nJSR 353: Java API for JSON Processing　JS2-33　#jt12_s233\n最近、Twitterで遊んでもらっている（勝手に絡んでいるだけという話も。。。）@yusukeyさんの発表です。 結構な数の立ち見が出るほどの盛況ぶりで、発表者の@yusukeyさんもびっくりしていました。 JSRがどういった形で実際の仕様として公開されていくのかという話がわかりやすく紹介されていて勉強になりました。 所々で笑いが入るなど、さすがの安定感でした。立ち見が出るはずです。 ようやく、JavaもJSONに関する処理を仕様として取り入れようとしているのはいい傾向かと。 ※残念ながら資料は公開されないようです。\nUI Controls and Charts: Drag-and-Drop, Filtering, Sorting, Table Hookup with Charts　JS2-42　#jt12_s242\n最近、Chartに興味を持っていたので、登録したセッションです。 内容としてはJavaFXのコンポーネントをリストアップして紹介していくというお話でした。 グラフ（Chart）周りも数種類が用意されるようです。 JavaFXをあまり知らないのですが、Swingをすこしやっていたのでなんとかついていくことが出来ました。 発表者の方が、実際にJavaFX内部の実装を行われている方だったようで、QAでいくつかこんなコンポーネントはないのか？という質問に、「私のPCでは動いているのですが、ドキュメントなどの整備が追いついていないので公開できていないです」という回答が出て、なかなか大変なのだなぁとｗ Chartに関しては、グラフの重ね合わせなどがまだできないということで、JFreeChartを触ったことがある身としてはすこし物足りなさそうだなぁというのが印象です。\nLearn how the JVM is fundamental to our architecture.　BoF2-03 #jt12_b203\n今回JavaOneに参加した一番の理由がこのセッションです。 Twitterのアーキテクチャに関するセッションでした。 思った以上に濃い内容で、ツイートしたデータがどんな流れで登録されるのか、登録されたデータを各ユーザのTimelineにどのようにアクセスして表示しているのかが説明されました。 今回は主にFinagleについての話でしたが、非同期処理をどのように活用しているかというお話でした。 負荷分散を行なっているポイントやキャッシュについての考え方などです。 メモを取るのに夢中になってしまい、英語をヒアリングするという目的を見失ってしまいましたが。。。 期待以上の話が聞けて満足しています。\nパネルディスカッション\n最後はJavaに関連するコミュニティを運営されている方々のコミュニティ運営に関するディスカッションです。 コミュニティの運営の苦労している点や、心がけている点など、運営も大変そうだなぁと。 どうしても長くやっているとメンバーが固定化してしまうという話なども出ていました。 これは難しいですよね。会社も同じことが言えますし。 一番印象に残ったのは桜庭さんの「動くものが作れるのが楽しい」という一言でした。 エンジニアをやってるのは確かにそこが面白いからだなぁと。最近忘れかけているので、もっと色々と作っていきたいですね。\n以上がカンタンな感想です。 少し残念なのですが、事前に参加登録していたセッションについては、マイページと呼ばれるところから資料がダウンロードできるものもあるみたいですが、参加登録してないものについてはダウンロードが出来ない様でした。（4/6現在） 参加できなかったセッションの資料こそ見たいと思うのが普通だと思うのですが、どうでしょう？そのうちどこかに公開されるのかなぁ。\n以下は、いつもの通り個人のメモです。\n場所：六本木ヒルズ　アカデミーヒルズ49F 日時：2012/04/05 ○Java EE6 Modeling　JS2-01　#jt12_s201 スーツ禁止。Eva好き？ ・特徴 Web Profile Pruing POJO、Annotation、Less XML Java EE6の半分のAPIは変更なし。新規が11% ・JavaEE6 Web Profile CDI、Interceptors、JSR 250 Singleton EJB JPAはEntityBeanの代わりかな？ ・パッケージングがearではなく、war一つで済むように。 war（ウォーファイル） web.xmlはアノテーションで行えるようになり、要らなくなる。 ◯マルチコアCPU時代のJavaプログラミング　JS2-14　#jt12_s214 HotSpotVM依存のお話ですよ。 ・GCとか ・java.util.concurrent.ForkJoinPool デフォルト並列数は論理CPU数 ・メモリアロケーション TLABが非効率に。先にある程度大きめにスレッドに割り当てを行うため、 スレッド数が上がるとTLABが非効率になる-\u0026gt;Eden全体では未使用領域があるんだけどGC発生とか ・JNIでの問題 GetStringCriticalとReleaseStringCritical間はGCが抑止されるため。 ・無意識のロック HashTableやStringBufferなど。 String#getBytes()も。 InetAddress#getAllByName()が内部でキャッシュを持ってる＝ロック File#renameTo()も内部でキャッシュ（ExpiringCache）持ってる。 Javaでは時間がかかる処理にはキャッシュを利用するという仕組みなので。スレッド数を増加させる場合は注意が必要 ・フェアネスロック lock = new Object(); for (int i=0;i\u0026lt;100;i++0{ synchronized(lock){ System.out.println(\u0026#34;i=\u0026#34;+i+\u0026#34;tid=\u0026#34;+Thread.currentThread().getId()); } } 上記を実行してもかたよることがあるよ。＝フェアじゃない モニターによるスレッド割り当ての説明。 RentrantLockでフェアネスになるよ。 ・性能分析 println()で区間分析。複数スレッドで実行したら実行時間にずれが。 println内部でもsynchronizedを利用している。＝ロックのせいで処理時間が遅くなるスレッドが出てきたりする。 JVMTIで性能分析する場合RawMonitorEnter,RawMonitorExitでロックとりあいなるのでもマルチスレッッドだと正しい値がでない。GetThreadLocalStrage使え。 ・まとめ： ハードウェア更改時にプログラムの変更が必要になることもあるよ。 わずかのロックが命取りに（ロックをあんまり使わない、無意識なロックを見極めなさい） ロックポリシーの選択（レスポンス重視なのか、スループット重視なのか） QA Q：事例が合ったという話でしたが、コードの修正しかないんですか？ A：はい。やっぱり治すのがいいです。あとは、チューニングですが。。。 Q：ReentrantLockが昔はスレッドダンプにでなかったのですが、今は？ A：今は出ます。 Q：各世代とJavaのバージョンのマッピングは？ A：第3世代が1.5くらいから。第2世代が1.3とか1.4？ ◯サービス維持・発展を踏まえた楽天オークションのJava EEによる開発と運用　JS2-23　#jt12_s223 ・短期で人材が参加できるようにしているというお話 ・楽天オークションの成り立ち（郵政とdocomoと楽天） ・商品、コミュニティ系（出品とか検索とか）と流通系（入出金、配送など）の2軸 ・メンバー30人くらい ミドルエンジニア エンジニア プロデューサー ・楽天市場をベースとして機能追加 ・巨大でリリースが大変に。 ・この5年で機能分解して機能ごとのリリースをめざして改善している ・JavaEEを使う理由 WebLogic上にバッチが動いているなどの仕組みをしている？ 管理機能が充実している（WebLogic） ・GlassFishへ移行中 あれ？Weblogicの管理機能がいいんじゃなかったっけ？ EJB実装はWebLogicに依存してるのでWebLogicもバージョンアップしてる。 ※メモはここまで。電池の持ちを気にして ◯ JSR 353: Java API for JSON Processing　JS2-33　#jt12_s233 ・JSONとは JavaScript Object Notation 「軽量な」データ交換フォーマット ・JSON仕様のグラフ ・XMLもあるのになんで？ シンプルで可読性が高い 属性がなく、複雑なスキーマ仕様がない。 ・コンパクト ・Twitter、GoogleMaps、YahooWebServicesなど ・JCP、JSRのお話 JSRの役割とか。 リファレンス実装の話。 ・JSR-353 http://jcp.org/en/jsr/detail?id=353 StAXやDOMに対応するよ。 ・ゴールではないもの JSONをJavaのドメインオブジェクトにバインドするとかもどすとか。 ・メンバー @yusukeyも一人 ・参加になったきっかけ 2011/10にTwitterがJCPに参加 2012/12/6にJSON JSR提出 年越しに採択 @yusukey「これTwitterで重要じゃない？」 @cra　「やりましょう」 ・JSRのコミュニケーション 世界各地の人なので、基本メールベース（今は自己紹介したくらい。。） ・既存のJSONライブラリ json.org、jackson、google-gson ・なんで、いろいろあるのにJSR？ 標準化、クラスパスにデフォ、シンプル、ライセンスで悩まないとか。 ・ロードマップ エキスパートグループ作成→アーリードラフト→パブリックレビュー→ファイナルリリース いま、アーリードラフト ・最新仕様 javax.json.* javax.json.spi.* javax.json.stream.* javax.json.tree.* メソッドチェインできるみたい。 JsonObject.create(reader);みたい JsonObject obj = …; JsonWriter writer = obj.accept(writer.) ・改善案 JSON***にしたいな。 spiはらないんじゃないかな？（いま、一個しか無い） treeもいらないんじゃないかな？（そんなに増えないし） parseじゃないかな？ メソッド追加（asStringで文字列化とか、create(String)とか） QA Q：JSONのスキーマ決めないの？バリデータとか A：JSONスキーマはあんまりもてはやされてない。一応あるのはある。 さすがの安定感。適宜笑いが入ってて楽しかったです。 ◯UI Controls and Charts: Drag-and-Drop, Filtering, Sorting, Table Hookup with Charts　JS2-42　#jt12_s242 ◯JavaFX 2.0のControls ◯Label、Button、ToggleButton、RadioButton、Hyperlink、CheckBox ◯Slider、ScrollBar、ScrollPane、ProgressIndicator、ProgressBar ◯TextField、PasswordField、TextArea ◯新しい機能 TitledPaneとAccordion TabPaneとSplitPane ◯Charts XYChartとPieChart XYChartにはLineChart、AreaChart、BarChart、ScatterChart、BubbleChartがある。 ◯Menu MenuItemの下に色々ある。 CheckMenuItem、RadioMenuItem、CustomMenuItem（SeparatorMenuItemとか) ◯ChoiceBox、ContextMenu、ToolTip ◯ListView ◯2.1の新機能 ComboBox、http://fxexperience.com/2012/03/new-in-javafx-2-1-combobox/ StackedBarChart、 StackedAreaChart MenuBarのMac OSへの対応（窓の中じゃなく、画面上部にちゃんと出る。） LCD Text QA： Q：テキストエリアの日本語入力とかは？ A：JavaFX3.0で対応 Q：FXML（Scene Builder）を使ってコードが生成されるのか？ A：ドラッグ・アンド・ドロップでやる場合はScene Builderでもできるでしょう。私はNetBeansとかでやりますけどね。 Q：Dialogはいつ対応されるんでしょうか？ A：私は使ってるんですけど、JavaFXに入れてもらえませんｗコードは出来てますｗ Q：Chartがありますが、pngやsvgでの出力は可能？ A：できません。そのうちできるかも。 Q：Chartの結合はできる？Axisの時間を便利に使うツールはありますか？ A：できないです。ありません。 Q：FX2.0でカスタムコントロール作るの大変？ A：私のマシンでは動いてるんですがｗ Q：ChartにCSSを適用することは可能？ A：可能です。データはJavaから出力されたものだけですけどね。 Q：JavaFX2.0の起動速度が上がったけど、どういう仕組？ A：私は上の方のエンジニアなのでよくわからないですが、GPUをうまく使ってるみたいです。 ◯Learn how the JVM is fundamental to our architecture.　BoF2-03 #jt12_b203 Java、Scala、Linuxのカーネルまで担当してます。 ・Twitterのアーキテクチャ ・スパイクが急にあがる場合にも対応できるスケールの話。 なでしこ、#バルス、大震災など ・Twitterはプラットフォーム ・最上位層：HTTP Proxy（Routing） ・中層：Twitter App（Models/Biz Objects、Composition） UserService、TweetService、TimelineServiceに分解（Models/Biz Objects） API（Composition） ・最下層：TimelineStorage、TweetStorage、SocialGraph、UserStorage（Storage/Retrieval） ・NEEDS サーバ負荷をハンドルできる必要がある。 言語のフレキシビリティ（JavaとかScalaとか） 成熟したコンカレンシーモデル ・Java が提供してるもの 開発者のエコシステムが素晴らしい。例：Nettyを使っている。Non-blocking I/O world class JITとコンカレンシーモデル メモリ管理 利点：メモリ管理を意識しなくていい 課題：GC。OpenJDKのコミュニティで参加してる。 複数の言語が実行可能な環境 ・OpenJDKについて ・Finagleのお話。 Netty上に作られた非同期なRPCサーバクライアントのライブラリ http://twitter.gthub.com/finagle/ ・TimelineServiceのお話 340M/day 10K/sec（イベント時） ・ツイートが入ってくる仕組み HTTP Proxy → tweet API → queue → tweet daemon → fanout （social graph）→ delivery → timeline cache → redis ・fanout 4000フォロワーごとにdeliveryにツイートが渡される。 ・Timelineを見る仕組み HTTP Proxy → timeline API（user service、） →timeline service →timeline cache ・timeline、tweets、users ・timeline serviceとtimeline cacheの関係 Finagleで負荷分散している ・timeline serviceからtimeline cacheへのリクエストを監視して、 高頻度のリクエストについては、timeline serviceのin-process cacheに入れる仕組み ・Service[Request, Response] Scalaの記述 service(request).onSuccess {response =\u0026gt; println(\u0026#34;got response! \u0026#34; + response) } ・Finagleのコンポーネント コネクション管理 プロトコルデコード　ThriftでService以降がつながってる。 分散トレース　オーバーヘッドを抑えて全体を監視（RPCトレース（呼び出しと処理時間のタイムラインチャート）） サービスディスカバリ　observability ◯パネルディスカッション ・JGGUG、JRuby、Scala、Groovyのコミュニティ運営に関係している方々によるディスカッション。 ","date":1333698660,"dir":"post/2012/","id":"56d5711303378bd333ddb611a53ece94","lang":"ja","lastmod":1333698660,"permalink":"https://blog.johtani.info/blog/2012/04/06/java-one-tokyo-2012-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-javaonejp/","publishdate":"2012-04-06T16:51:00+09:00","summary":"JavaOne Tokyo 2012に参加してきました。 4/4-4/5の2日間開催されていたのですが、子供が体調を崩してしまい、4/5のみの参加となりました。 4/4","tags":["勉強会"],"title":"Java One Tokyo 2012 に参加しました。#JavaOneJp(Jugemより移植)"},{"contents":"先日、2.0.0リリースの記事にも記載しましたが、Java7でテストケースが失敗する問題がありました。\n@haruyamaさんと@hideaki_tさんの協力により問題を解消し、trunkと4xブランチにコミットしました。\nissueにも記載しましたが、Java6からJava7にバージョンアップするタイミングで変更されたUnicodeのバージョンが原因でした。 Java6ではUnicodeのバージョンが4.0です。Java7ではUnicodeのバージョンが6.0に変更されています。 今回の問題は「・」（0x30FB）の文字列のCharacter.getType()がCONNECTOR_PUNCTUATIONからOTHER_PUNCTUATIONに変更されたのが原因です。（この変更自体はUnicode 4.1で変更されたみたい） カタカナ文字種の判別をlucene-gosenのnet.java.sen.tokenizers.ja.JapaneseTokenizerのgetCharClass(char c)メソッドで行なっています。 修正前は、ここで、charの範囲が0x30A0～0x30FFにある文字でかつ、Character.getType()がCONNECTOR_PUNCTUATIONでないものがカタカナとして判別されていました。 issueの添付ファイルにJava6とJava7で上記範囲の文字のCharacter.getType()のリストを生成して、該当する文字を探した所、「・」（0x30FB）のみであることがわかりました。 ということで、このコードの意図としては、「・」はカタカナではないと判別したかったのだと。 上記の確認を行えたので、ソースコードを修正してコミットしました。 2.0.1としてリリースするかは、Issue29のボリュームを見て考えますので、もう少しお待ちください。\n参考にしたサイト： JavaSE 7でメソッド名に使えなくなった文字 UNICODE CHARACTER DATABASEのHistory\n","date":1333552800,"dir":"post/2012/","id":"c7937b6b4bde2a96191dc31db913e1ab","lang":"ja","lastmod":1333552800,"permalink":"https://blog.johtani.info/blog/2012/04/05/lucene-gosen%E3%81%AEjava7%E3%81%A7%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E5%A4%B1%E6%95%97%E5%95%8F%E9%A1%8C%E3%81%AE%E5%AF%BE%E5%BF%9C/","publishdate":"2012-04-05T00:20:00+09:00","summary":"先日、2.0.0リリースの記事にも記載しましたが、Java7でテストケースが失敗する問題がありました。 @haruyamaさんと@hideak","tags":["lucene-gosen"],"title":"lucene-gosenのJava7でのテスト失敗問題の対応(Jugemより移植)"},{"contents":"先日、宣言したとおり、lucene-gosenのパッケージ名＋クラス名の変更を行ったlucene-gosen 2.0.0をリリースしました。 Lucene/Solr 3.6.0のリリースを待つつもりだったのですが、なかなか出ないので先にリリースを行いました。 現時点では、branches/4xについては、パッケージ名、クラス名の修正が追いついていません。 明日までに4xブランチについても修正を反映する予定です。\n参考までに、1.2.1から2.0.0への変更点について以下にまとめました。 また、変更に伴い、Solrのschema.xmlに記述するクラス名も変更になります。 schema.xmlのサンプルについてはこちらをご覧下さい。\n変更点 まずは、パッケージ名の変更点です。 左が旧パッケージ名、右が新パッケージ名となります。\n旧パッケージ名 新パッケージ名 org.apache.lucene.analysis.ja org.apache.lucene.analysis.gosen org.apache.lucene.analysis.ja.tokenAttributes org.apache.lucene.analysis.gosen.tokenAttributes また、パッケージ名とは別に、以下のクラス名も変更になっています。 まずは、org.apache.lucene.analysis.gosenのクラス名の変更点です。\n旧クラス名 新クラス名 JapaneseAnalyzer.java GosenAnalyzer.java JapaneseBasicFormFilter.java GosenBasicFormFilter.java JapaneseKatakanaStemFilter.java GosenKatakanaStemFilter.java JapanesePartOfSpeechKeepFilter.java GosenPartOfSpeechKeepFilter.java JapanesePartOfSpeechStopFilter.java GosenPartOfSpeechStopFilter.java JapanesePunctuationFilter.java GosenPunctuationFilter.java なし GosenReadingsFormFilter.java JapaneseTokenizer.java GosenTokenizer.java JapaneseWidthFilter.java GosenWidthFilter.java 次は**org.apache.solr.analysis**です。 旧クラス名 新クラス名 JapaneseBasicFormFilterFactory.java GosenBasicFormFilterFactory.java JapaneseKatakanaStemFilterFactory.java GosenKatakanaStemFilterFactory.java JapanesePartOfSpeechKeepFilterFactory.java GosenPartOfSpeechKeepFilterFactory.java JapanesePartOfSpeechStopFilterFactory.java GosenPartOfSpeechStopFilterFactory.java JapanesePunctuationFilterFactory.java GosenPunctuationFilterFactory.java なし GosenReadingsFormFilterFactory.java JapaneseTokenizerFactory.java GosenTokenizerFactory.java JapaneseWidthFilterFactory.java GosenWidthFilterFactory.java また、上記クラスに関連するテストクラスの名前も変更になっています。\n以上がクラス名、パッケージ名の対応に関する修正ついてでした。\nまた、現在、Java7にてテストケースが失敗する問題が見つかっています。 こちらの問題の対応版についても近日中にリリースを行う予定です。\n問題点、質問などありましたら、コメントしていただくと回答いたします。\n2012-04-03追記 忘れてました、すみません。今回のリリースで、以下の機能が追加されています。\nAntのパラメータにproxy.user、proxy.passwordの追加 GosenReadingsFormFilterの追加 TokenAttributeの修正（PronunciationsAttributeImpl、ReadingsAttributeImpl） Antは認証が必要なプロキシ環境で辞書のビルドを実施するときにユーザ名、パスワードを指定できるようにしました。\nGosenReadingsFormFilterは単語を読みに変換するTokenFilterになります。 よみは、辞書に登録してある読みになります。オプションとして、romanizedが指定可能です。指定をすると、よみをローマ字に変換します。\nTokenAttributeの修正は、バグフィックスになります。Issueはこちらです。\n","date":1333362120,"dir":"post/2012/","id":"06731164684f90f33ce4017eca9d8ec1","lang":"ja","lastmod":1333362120,"permalink":"https://blog.johtani.info/blog/2012/04/02/%E9%87%8D%E8%A6%81lucene-gosen-2-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2012-04-02T19:22:00+09:00","summary":"先日、宣言したとおり、lucene-gosenのパッケージ名＋クラス名の変更を行ったlucene-gosen 2.0.0をリリースしました。 Lucene/Solr","tags":["lucene-gosen"],"title":"【重要】lucene-gosen 2.0.0リリース(Jugemより移植)"},{"contents":"lucene-gosenを利用して頂いてる皆様に連絡があります。\n連絡事項 次期lucene-gosenのリリース（2.0を予定）にて、org.apache系のパッケージ名および、クラス名の変更を行います。 Lucene/Solrの次期リリース版である3.6.0以降では、lucene-gosen 2.0（予定）を利用するようにしてください。\n経緯 Twitterでは少しずつツイートしていますが、Lucene/Solr 3.6から日本語の形態素解析器がLucene/Solrにて用意されることになりました。 ベースとなっているのは、Atilika社が開発したKuromojiという形態素解析器です。 Lucene/SolrにコントリビュートされたタイミングではKuromojiAnalyzerなど、Kuromojiという名称が残った形で取り込みが行われました。 その後、LUCENE-3909にて、Kuromojiではなく、一般的な名称（Japanese*）に変更する提案が行われました。 この提案で、luene-gosenが利用しているクラス名、パッケージ名と大半のクラスが衝突してしまうこととなりましす。 今後も、lucene-gosenを利用していただけるように、lucene-gosenのIssueを発行し、 現在、lucene-gosenのtrunkにてパッケージ名の変更及びクラス名の変更作業を行なっています。 正式にリリースするタイミングになりましたら、再度連絡いたします。\nブランチなどについて 現時点ではパッケージ名、クラス名の変更はリポジトリの以下のものについてのみ作業を行う予定です。\ntrunk branches/4x 現時点でのリリース版（1.2系）のソースについてはbranches/rel-1.2にて、これまで同様のクラス名、パッケージ名のまま変更を行いません。 1.2系についてはこちらをご覧下さい。\nまた、当ブログにて、提供しているSolr入門のサンプルに利用可能なschema.xmlなどの記事についてもLucene/Solr3.6がリリースされた際には再度修正して掲載いたします。 Kuromojiの利用方法もあわせて記載したいです。\n参考： lucene-gosenとKuromojiの機能などの比較についてはこちらを参考にしてください。\n","date":1332783540,"dir":"post/2012/","id":"f8327953a0f0b80011b939111807999a","lang":"ja","lastmod":1332783540,"permalink":"https://blog.johtani.info/blog/2012/03/27/%E9%87%8D%E8%A6%81lucene-gosen%E3%81%AE%E6%AC%A1%E6%9C%9F%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-03-27T02:39:00+09:00","summary":"lucene-gosenを利用して頂いてる皆様に連絡があります。 連絡事項 次期lucene-gosenのリリース（2.0を予定）にて、org.","tags":["lucene-gosen"],"title":"【重要】lucene-gosenの次期リリースについて(Jugemより移植)"},{"contents":"子供の寝かしつけしてたら、寝かしつけされてしまって、２時に目が覚めてしまいました。 TSUTAYAでCD借りてきてウォークマンに入れようと思っていたのに。。。 ということで、今作業してます。\nMBAを買う前から使っている、もう９年目のWindows自作デスクトップで基本的にはCDの取り込みをしています。 ファイルサーバ（BuffaloのTeraStation）がLionから接続できないというのと、 X-アプリで曲管理していたのでという理由です。 あと、ウォークマンなのでMac用のソフトがなかったりというのも理由です。\nで、眠い目をこすりながらWindowsマシンを起動すると、ネットワークにつながらないじゃないですか。。。 再起動してもダメでした。\nとなってしまったので、せっかく、譲ってもらったMac miniも活用しないといけないなと思い、iTunesでアルバムを取り込んでみています。 ここ数年はWAV形式でデータを取り込んでいたので、WAVでの取り込みを設定して、iTunesで取り込みました。\nとまぁ、ここまでやってから、件のWindows機を再度、再起動したらネットワークに繋がってしまいました。。。 なので、残りのCDはWindows機で取り込みしてます。 けど、そろそろこのPCも危なそうなので、データをサルベージして、Mac miniで作業できるようにしないとなぁ。 Macでウォークマンを運用している人はどうやってるんだろう？ ちなみに私が利用しているウォークマンはNW-A847です。 エンコードはWAV形式で取り込んで、X-アプリでウォークマンに入れています。 iTunes使ってる人は、アップルのロスレスエンコードをつかってるのかなぁ？ ということで、調査・検討したい項目はこんなところですか。\n調査：TeraStationにMacからつなぐ方法（Lionで利用できそうなソフトなにかないかな？） 調査：iTunesでウォークマンに曲転送（やってみればすぐわかるだろう。。。） 調査：iTunesの曲をCDに焼く方法（車で曲聞くのにCDだから） 検討：ファイルサーバのリプレース対象となる機種（ファイルサーバは導入してまだ５年だから余裕がないと買い換えない） 検討：iPodに鞍替え（Sony好きだし、ウォークマン好きだし、買ったばっかりだからまず無い選択肢） 検討：Mac miniにVirtualBox入れて、WindowsからX-アプリ使うとか。（ファイルサーバが見えるようになるかな？） 検討：Mac miniをWindowsとして運用（もったいなさすぎる気がする） とまぁ、まだ悩んでるだけで、取り留めもない事を書いて、しかも結論が出ないままですが、ご容赦ください。 ご意見、提案を大募集してます！！\n","date":1332618420,"dir":"post/2012/","id":"8b76101d185700a8efed148d8722d926","lang":"ja","lastmod":1332618420,"permalink":"https://blog.johtani.info/blog/2012/03/25/%E4%B9%85%E3%80%85%E3%81%ABmac-mini%E3%81%AE%E3%81%93%E3%81%A8%E3%81%A7%E3%82%82/","publishdate":"2012-03-25T04:47:00+09:00","summary":"子供の寝かしつけしてたら、寝かしつけされてしまって、２時に目が覚めてしまいました。 TSUTAYAでCD借りてきてウォークマンに入れようと思っ","tags":["備忘録"],"title":"久々にMac Miniのことでも(Jugemより移植)"},{"contents":"はい。またまた、Twitter API勉強会に参加してきました。（今回から開催回数の記載がなくなった？） 今回は直前でタイムテーブルが変わってしまう波乱がありましたが、個人的には楽しめる内容でした。 Twitterの国際化や形態素解析などの話が聞けたのがすごく面白かったです。 アーキテクチャや利用されている形態素解析器の話など、また、現状の問題点なども話が聞けました。 日々、進化しているんだなぁと。 残念ながら、発表者の方が懇親会にいらっしゃらなかったので、詳しく聞けませんでしたが、挨拶だけは出来ました。 実際のテスト環境や導入方法、A/Bテストとかやってるのかなど、ブログをかきながら色々と気になることが出てきてしまいますｗ 頭の回転がよくないので、話を聞いてる間は質問があんまり思い浮かばなかったなぁ。。。\nその他にも（使ったことなくてすみません。。。）「昼会」のサービスの話、他の言語でのTwitterの活用の話も聞けました。\n途中で帰ってしまいましたが、懇親会でも数人の方とお話できて、楽しかったです。 （今回の懇親会会場はちょっと人数の割に手狭だったかもなぁ）\n次回は4月末を予定しているようでした。今度こそ、利用規約の話になるんですかね？ 忙しさを見つつ、また参加しようかと思います。\nということで、いつものメモです。\n開催日時：2012/03/21 19:00 ～ 21:00場所：ハロー会議室shibuya Zusaarのページ\n◎Twitterの日本語検索、ハッシュタグについて　@keita_f\n◯アーキテクチャ ・Twitterバックエンドの国際化 Before 各言語ごとに独自実装。 After 共通テキスト処理ライブラリ：Penguin ・アーキテクチャ：検索 Firehose → ingester → Earlybird ⇔ Blender ← ユーザの検索 Firehose：ツイートの受信 ingester：ツイート解析 Earlybird：Luceneベースのインデクサ Blender： ・アーキテクチャ：トレンド TrendsはGeo（ユーザ位置情報）を利用してるっぽい。 Term Statisticsは過去ツイートからHadoopで頻出フレーズを解析する。 今頻出しているフレーズ＋過去頻出しているフレーズ ◯日本語関連 ・ツイートの言語判定 言語判定にはIndigenous Tweets（Kevin Scannell）をベースに実装。 ５０言語サポート、Javaで実装 ・文字種チェック ・エンコーディングチェック ・Ngram（the→英語、das→ドイツ語） 問題点： ２つ以上の言語が混じってる場合 絵文字が入ってる場合 Unicodeアルファベット ・形態素解析 日本語：Gomoku 中国語：LuceneのSmartCN その他：N-Gram 問題点： 形態素が小さすぎる →そのままだと細かすぎるので品詞情報を元に大きめに区切るようにしている iPhone4Sなどが数字で区切られる →ASCIIの数字とアルファベットは連結しなおす ・フレーズ抽出 他の言語もあったけど、キー入力間に合わず 日本語の場合： トークンに分割 トークンでNgramを生成 品詞情報を使ってフィルター 最初、最後が助詞はNG、接頭詞で終わるのはNG ・やりたい事はまだまだたくさん ・形態素解析の品質向上 辞書への単語追加 韓国語、タイ語のトークなイザー ・同義語、類義語、翻訳、音訳、略語などのサポート ・フレーズ・トピックのクラスタリング ・Sentiment Analysis ・日本語のできるエンジニア募集中ｗ QA Q：顔文字を手動で抜き出すと言われたんですが、どのくらいあるんでしょうか？　A：正規表現なので、なんとも言えませんが、パターンを Q：Gomokuの選択の理由は？ A：Javaだから。jarに辞書が入るから。スピードが出るから。 ◎ランチタイム共有サービス「昼会(http://www.hirukai.jp/)」のご紹介　@setomits\n◯前提 ・ネットワーキングは重要 ・出会いも重要 ・飲み会だとコスパが悪い ◯ランチだと ・金額が限られる ・必ず食べる ということで、昼会だ！ ◯画面でサービスの説明 パブリックな昼会、プライベートな昼会がある。 ◯なんでTwitter？ LinkedInのOAuthを使ったログイン検討してた。 ビジネス目的＋ 敷居が高いのでTwitterに変更 ◯Twitterのapiで利用しているものなど ◯ユーザの声 ・DMを使ってる＝自分からのDMが気持ち悪い APIの使用制限やフォローしてもらう必要があるのが辛い。 - スパムかと思った - 乗っ取られたかと思った。 - エンジニアからは、「まぁ、こうするよね」 ・OAuthについて - ユーザ登録しなくていいのは嬉しい - イベント参加のためにOAuthでの書き込み権限まで与えたくない ◯８ヶ月経って ・新しい出会いがあった ・昼会を開催する敷居が高い ＝なかなか使ってもらえない ◯今後の計画 募集中！ QA Q：AppEngineで月額どのくらい？ A：料金改定前：数千円/１ヶ月、料金改定後：２万円くらい/１ヶ月 処理数を減らして、現時点では数千円/１ヶ月に最適化した Q：夜会はないんですか？ A：設計していたら、出会い系サイト？になりそうなので、昼にした。 ドメイン的になぁ。まだ悩み中 Q：GAE特化したもの？AWSに移行できる作り？ A：できない作りです。（pythonで書いてます。） GAEが楽なので、移行可能な作りにするのがつらい。 ◎LT ◯Twitter 4 contact　@inda_re ・広告！アジャイルサムライの道場\n・問い合わせフォームをTwitterにしちゃう 今あるHTMLにフォームを入れる方法（MySQLとPHP） githubにサンプルあるよ。 ◯PerlのTwitterモジュールについて　@xtetsuji\n・前回出席したら、ムチャぶりが！ ・いまどきのPerl 進化してるよ、古い情報が検索で出てきてしまうのがネック ・perlbrewってのがある http://perlbrew.pl/ ・AnyEvent::Twitter::Streamをよく使ってます。 ・gistにサンプルあげてあるよ！ ◯KotlinでもTwitter4J　@ngsw_taro ・Kotlinの説明 ・以下のサイトでインストールしなくても動かせるよ！ http://kotlin-demo.jetbrains.com/ ・NULL安全 Nullを許容する型、許容しない型がある。 ・一応、Twitter4Jのサンプルも作ったけど、ブログ見てね http://d.hatena.ne.jp/ngsw_taro/\n◯締め Twitter API勉強会ではスピーカーを常に募集中です。登録はこちら！\n","date":1332343680,"dir":"post/2012/","id":"16b3c9445539e9274282a612dea354c2","lang":"ja","lastmod":1332343680,"permalink":"https://blog.johtani.info/blog/2012/03/22/%E7%AC%AC5%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%B8%8B%E8%B0%B7--twtr_hack/","publishdate":"2012-03-22T00:28:00+09:00","summary":"はい。またまた、Twitter API勉強会に参加してきました。（今回から開催回数の記載がなくなった？） 今回は直前でタイムテーブルが変わってし","tags":["勉強会"],"title":"第5回 Twitter API勉強会 @渋谷 #twtr_hack(Jugemより移植)"},{"contents":"TLで面白いと見かけて、Amazonで買ってしまいました。 SEやってるのに、つい最近Amazonを使い始めた軟弱者です。 それにしてもAmazon危険です。スマートフォンにAmazonの Androidアプリを入れたのですが、これがまた、レコメンドに面白そうな本が出てきて危険です。\n話がそれてしまいましたが、面白い本でした。 久々に、小説でも技術書でもない本を短期間で読みました。 「箱」と呼ばれる概念の中と外について、とある会社に転職した管理職の人が学んでいくという物語風の作りです。 いくつか、自分の経験にカブるシーンがあったので、サクサク読めました。 今までの自分になかった考えである「箱」という視点が得られたのがよかったです。\nただ、いくつか気になる点もあるので、また少し時間を開けてからサラっと流し読みしたいと思います。\nあと、すこしだけ、キリスト教チックな考え方でもあるかなぁと思う部分もありました。（キリスト教をちゃんと勉強してるわけではないので認識が間違ってるかもしれないです）\n人によっては共感出来なかったり、読みにくかったりすると思いますが、私は面白いと思った本でした。 なんとなく、人間関係に違和感を感じていることがある場合は目を通してみるといいかもしれません。\nTwitterで読み終えたというツイートをしたら、「自分を変える気づきの瞑想法」を読むとまた面白いですという＠ツイート（これがmentionの日本語の正式名称らしい？）を@ledsunいただきました。 箱に入る原理が別の視点で書かれているようです。 読んでみたいです。（本会過ぎてる気がするので、図書館で探そうかなぁ。。。）\n自分を変える気づきの瞑想法【増補改訂版】 自分を変える気づきの瞑想法【増補改訂版】 ","date":1332253920,"dir":"post/2012/","id":"ee623aaa99b429863f89da313fffed97","lang":"ja","lastmod":1332253920,"permalink":"https://blog.johtani.info/blog/2012/03/20/%E8%87%AA%E5%88%86%E3%81%AE%E5%B0%8F%E3%81%95%E3%81%AA%E7%AE%B1%E3%81%8B%E3%82%89%E8%84%B1%E5%87%BA%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-03-20T23:32:00+09:00","summary":"TLで面白いと見かけて、Amazonで買ってしまいました。 SEやってるのに、つい最近Amazonを使い始めた軟弱者です。 それにしてもAmaz","tags":["読書"],"title":"「自分の小さな「箱」から脱出する方法」を読みました。(Jugemより移植)"},{"contents":"えーと、ブログ更新してないなぁとふと思ったので。 １年前くらいからずーっと、つぶやいてましたが、やっとScalaを始めました。 長かった。。。 とある、サンプルデータを作成するので、ついでにScalaを勉強してしまえという感じで始めました。\nScalaで学ぶ関数脳入門を買ってもう１年以上経ってました。。。 とりあえず、CSVデータからInsert文を作ってます。 書籍を見ながら、四苦八苦してるところです。 今日は、csvファイルを読み込んで適当に出力した所で終了でした。 現状を忘れないようにというのと、いくつか気になった点があったので、備忘録のため上げておきます。\nscala IDE for Eclipseを利用（もっさりしてる） classとは別にobjectというものがある点に慣れない セミコロンいらないのに、ついつい打ってしまう usingを利用しようとしたが、Eclipseに怒られた（なんで？） メソッドの戻り値を省略出来る場合とできない場合がよくわかってない Javaが混ざる（ファイル出力にBufferedWriterを使う）のがまた戸惑う ということで、四苦八苦してますｗ ７つの言語、７つの世界も参考にしつつ、コップ本をパラパラしながら、ググって書くといった感じです。 Javaだととっくにできていると思うのですが、まだ、読み込んで出力できただけです。\n新しいものに触れるのは頭を使って面白いのですが、思い通りに行かず（とくにIDEがもっさりしてたり、上手く使えなかったり）イライラもしていますｗ まぁ、ちょっとずつ勉強していきます。\n（ほかにもいろいろやらないとなぁ。。。）\nScalaスケーラブルプログラミング第2版 Scalaスケーラブルプログラミング第2版 ","date":1331652421,"dir":"post/2012/","id":"116c9be6d760b4befa6d51ce9e96604c","lang":"ja","lastmod":1331652421,"permalink":"https://blog.johtani.info/blog/2012/03/14/scala%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-03-14T00:27:01+09:00","summary":"えーと、ブログ更新してないなぁとふと思ったので。 １年前くらいからずーっと、つぶやいてましたが、やっとScalaを始めました。 長かった。。。 と","tags":["Scala"],"title":"Scala始めました(Jugemより移植)"},{"contents":"森ビルに行ったことなかったので、参加してみました。 あと、最近まともにコーディングしてないので、そのへんを矯正するためにもと思って。 （まぁ、遊びに行きたかっただけなんですけどね）\nすこし遅刻して参加です。 会場は、Twitter Japanさんの@yakitoriでした。ここだけ、撮影可でした。 で、肝心のハッカソンの中身です（ハッカソン自体、初参加！）。 Twitter APIもTwitter4Jも触ったことがありません。 なので、ソファーに座ってMac Book AirでTwitter4Jのサンプルを眺めながら、とりあえず、Solrに流しこむってのを作ってみました。 今回、Solrに用意したのはlucene-gosenによる形態素解析を行うフィールドとあとは、Solrのexampleについてるダイナミックフィールドたちです。 Twitter4Jからどんなデータが取れるかわからないので、ダイナミックフィールドで型だけ指定してSolrを起動しておきます。 次に、Twitter4Jにあるsample()にてパブリックなツイートの1%を取得（適当なのがこれくらいしか思い浮かばなかったから）。 あとは、SolrJのStreamingUpdateSolrServerを利用して、流し込みです。 あんまり時間がなかった（準備とかウォーミングアップで時間かかった）ので、結局、Screan名とツイート本文を SolrInputDocumentに無理やり詰め込んで登録しただけでした。 ほかにも色々と情報が取れるはずなので、そのへんも格納してファセットとかで遊びたかったなぁ。 とまぁ、こんな感じでタイムアップです。（コードは大したことないので文章だけでｗ） 画面も用意出来なかったので、発表はSolrのダサい管理画面で検索でした。 次回は、もう少し中身を勉強して画面もbootstrapで作ってとかやってみたいですね。 あと、自己紹介スライドに書きましたが、Scalaから使ってみるのもやってみたいです。（その前に、Scalaに入門しないといけないんですけど。。。）\nということで、個人的にいろいろと反省点があるハッカソンでした。 反省点：\n立ち上がりに時間がかかった（普段からコーディングしてないから） Twitter4Jについて事前に勉強してない（ごめんなさい） 環境面が整備しきれてない Twitter API ポケットリファレンス（右の本）を忘れた。。。 スターウォーズのピザの箱の写真取り忘れた＞＜ 普段、コーディングをしていない仇が出てしまいました。 もっと、すぐにコーディングをできる環境、体質を日頃から鍛えておかないといけないなぁと。 （SolrやTwitter4JのJavaDocをオロオロしながら探すとか情けないです。。。）\n場所や雰囲気は全然問題ありませんでした。 ピザを@yusukeyさんからごちそうになったり、飲み物、お菓子が用意されていたりと至れり尽くせりでした。 iPadで音楽も流してくれてたし。 他のハッカソンに参加したことないので比較はできないですが、集中できてよかったです。 あと、ソファーでコーディングもなかなかいいなぁと実感出来ました。（初めて！） 人数的にもこのくらいのほうが話がしやすくていいかなぁと。発表も時間かからないですし。 ただ、帰り道に誰かが言っていましたが、「マラソンというよりは短距離走だったね」というのは否めないかなぁと。 時間は限られちゃうので、準備をしっかりしないとなぁと。 私としては、土日のハッカソンだと参加しづらいので、平日開催がうれしいのですが。 いやぁ、楽しかったです。みなさんの面白いネタも見れたし。（自分のやったのは普通すぎて少し恥ずかしかったです。。。） あと、GoogleDocsの使い方（自己紹介スライドとかアンケートの集計とか）も学べたのが収穫でした。 @yusukeyありがとうございます！ 次回もありそうなので、懲りずに参加しようかな。\nさて、他の方たちのブログやtogetterは@yusukeyさんのページからたどってくださいｗ。 第0回Twitterハッカソンを開催しました #twtr_hack\n今日購入したCD聴きながらブログ書いてます。 タワレコで視聴して購入したCDです。 なかなか大人な雰囲気でオススメです。 Heaven ","date":1331230200,"dir":"post/2012/","id":"4d6c95b0b3ea2ddb30fdd3edf3b82391","lang":"ja","lastmod":1331230200,"permalink":"https://blog.johtani.info/blog/2012/03/09/%E7%AC%AC0%E5%9B%9E-twitter-hack--twtr_hack-%E3%81%AB%E9%81%8A%E3%81%B3%E3%81%AB%E8%A1%8C%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-03-09T03:10:00+09:00","summary":"森ビルに行ったことなかったので、参加してみました。 あと、最近まともにコーディングしてないので、そのへんを矯正するためにもと思って。 （まぁ、遊","tags":["勉強会"],"title":"第0回 Twitter Hack #twtr_hack に遊びに行きました。(Jugemより移植)"},{"contents":" Clean Coder プロフェッショナルプログラマへの道 Clean Coderを読みました。 理由はTwitterで「Clean Code」がいい本だと流れてきたためです。 「Clean Code」はまだ読んでいないのですが、クリーンなコード（メンテナンスしやすく、修正などもやりやすいコード？）を書くために必要な話が書いてあるのだと思います。（まだ妄想）\nそして、何も考えずに、「Clean Code”r”」という本が新しく出ていたので、新しい方に手を出しました。 まぁ、軽い勘違いですｗ（コードの構造の話などは出てこなかったです。） それほど分厚くなく、軽く読めそうだということで読み進めると軽い衝撃を受けました。 Clean Coderはプロのプログラマとして、どのような意識を持つべきか、立ち居振る舞いをするべきかなどが書かれています。 「～したい」はまず守らない約束だという話、ユニットテストを書くことはプロとして当たり前の行為だ、目的意識を明確に持つことなどなど、耳の痛いことが色々と書かれています。 これは、著者の方（パンチカードのころからコーディングをされている！）の実体験を元に、失敗した経験から導きだされているようです。 ところどころ、古くてよくわからない話やちょっとだけしっくりこない表現（ビジネス、QAといった単語）もありましたが、概ねわかりやすい話でした。\n基本的にはアジャイルなスタイルの開発を行うプログラマ（設計書に基づいてコーディングするだけの人ではない）について書かれています。 この本を読んでいて、昨年、仕事をご一緒させていただいたRubyistの方たちの開発スタイルを思い出しました。 私よりもこの本に書かれているプロに近いなぁと。 ペアプロやったり、実装方法について相談していたりと。\n勘違いでしたが、良い本に出会えて本当によかったです。 私もこの本に書かれているようなチームでのプログラミングをやりたい、またなにかコーディングをしたいという気にさせてくれました。（「～したい」じゃダメって書いてあったのに。。。） 自分を戒めるためにも、定期的に読み返したい本です。 プログラマでいたい方、ある程度プログラミングができるようになってきた方にはぜひ読んでいただきたい本です。 （この流れで、アジャイルサムライやClean Codeを読んだら理解が深まりそうだなぁ）\n参考URL： 35歳定年説をブチ破れ！「Clean Coder プロフェッショナルプログラマへの道 Robert C. Martin」 - ledsunの日記 ","date":1330704840,"dir":"post/2012/","id":"10eb415a232ad4be7d05c57eb850036c","lang":"ja","lastmod":1330704840,"permalink":"https://blog.johtani.info/blog/2012/03/03/clean-coder%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A0/","publishdate":"2012-03-03T01:14:00+09:00","summary":"Clean Coder プロフェッショナルプログラマへの道 Clean Coderを読みました。 理由はTwitterで「Clean Code」がいい本だと流れてきたためです。","tags":["読書"],"title":"Clean Coderを読んだ(Jugemより移植)"},{"contents":" 親子で楽しめる 絵本で英語をはじめる本 Twitterでこの本について書かれたブログ記事が流れてきて、購入しました。\n最近、英語を身につけておいたほうがいいなと思うことが多々あり、子供にも英語を勉強してもらいたいなと思っていたところでした。 あとは、私自身が英語が苦手というのもあり、子供をダシにして勉強したいというのもありまして。。。 サラっと読んでみましたが、参考になりました。 特に「多読」というキーワードが面白かったです。こちらが元のようですが。 多読とは、文章を分析しないで大意を把握する読書法だそうです。\n辞書を引かずに楽しめるものを読む わかるところをつなげて読む 自分が面白いと思う本を選んで読む という原則があるようで、確かにいいなと思いました。 絵本だと絵が書かれているので、辞書を引かなくても想像できそうですし、楽しめそうだなぁと。 また、多読は先日読んだ、速読の本に書かれていた本の読み方にも通じるものがあるなと。（まだ、実践できてないんですけどね）\nどうしても英語を勉強させたい！、勉強しないと！と思ってしまいがちですが、この本にも書いてあるように楽に楽しんでやったほうがやっぱいいなぁと。 楽しくないと続かないですからねぇ（実際、何度も挫折してるし、押し付けられるとヤル気がなくなるので。。。）\nということで、実践してみようと思います。（平日は子供が寝てしまってから帰宅なので、まずは土日から）子供のためというよりは、自分の英語の勉強のために。 まずは、簡単な絵本を購入して。 この本の後半半分は、著者の方の感想や説明がついた、オススメの絵本50冊が書かれています。 英語の絵本を入手するのは、結構大変（実際に売ってる店もなかなかないし、手にとって見る機会も少ない）だと思うのですごく参考になりそうです。 いくつかピックアップして、あわよくば本屋で手にとってみようかと。なければ、Amazonで購入しようかなぁと思ってる所です。\n","date":1330186800,"dir":"post/2012/","id":"627a0c45dd07150343c81d856855590e","lang":"ja","lastmod":1330186800,"permalink":"https://blog.johtani.info/blog/2012/02/26/%E8%A6%AA%E5%AD%90%E3%81%A7%E6%A5%BD%E3%81%97%E3%82%81%E3%82%8B-%E7%B5%B5%E6%9C%AC%E3%81%A7%E8%8B%B1%E8%AA%9E%E3%82%92%E3%81%AF%E3%81%98%E3%82%81%E3%82%8B%E6%9C%AC/","publishdate":"2012-02-26T01:20:00+09:00","summary":"親子で楽しめる 絵本で英語をはじめる本 Twitterでこの本について書かれたブログ記事が流れてきて、購入しました。 最近、英語を身につけておいた","tags":["読書"],"title":"親子で楽しめる 絵本で英語をはじめる本(Jugemより移植)"},{"contents":"今週も勉強会に参加しました。 @yusukey さんが開催してるTwitter API勉強会です。 前回とは会場が異なりましたが、広くて大画面で良い会場でした。駅も近いし。（デジタルハリウッドさいこー！） 今回はLT枠のbootstrapの話が聞きたくて参加しました。（ムチャぶり駆動勉強会の現場をTLで目撃してたのでｗ） あと、バーチャファイター（昔、VF目当てでセガサターンを買ったなぁ、懐かしい）の話も聞きたかったので。 （ごめんなさい、Twitter APIはまだ触る機会がなさそうです。。。） 今回も途中で参加者同士を数グループ（座席が近い人）に分けて自己紹介タイムがあり素敵でした。 ちょっと残念だったのはネームプレートが今回はなかったことでしょうか。 自己紹介でツイッターID教える＋聞くのがちょっと辛かったです。（やっぱり個人名刺作ったほうがいいかなぁ） 私はPCを開いていたのでTwitterのページを見せることで対応出来ましたが。 （次やるときはお手伝いするのでこえかけてください。）\n内容はメモをとってあり、下に書いてますので見ていただければ。\nTwitter APIの説明はいろいろ新鮮でした。今回はWebページに貼るリンクやボタンの話でした。 カスタマイズも出来るようになってるってのは知りませんでした。Webサイトやってる人は簡単にカスタマイズできるのは便利ですよね。\nバーチャファイターのTwitter連携の話は結構詳細な話が出てきてびっくりでした。（テーブル名とかまで出てきましたｗ） ゲーム筐体の前のユーザの動きまで考えてシステム作るとかすごいなぁとか。違う業界の話って面白いです。\nBootstrap入門はbootstrapの紹介だけじゃなく、Tips（bootstrap弊害とかw）やその他の便利なサイトの紹介までありました。 スライドもあとから読んでもわかるのがすごく嬉しいです。時間を見て試してみます。 TwitterSphereは懇親会でもデモが見れました。Groovyは名前を知ってるだけだったのですが、Swingとかまで動くんですね。（JVMだから当たり前なんだけどなんか新鮮。） 最後はAndroidのAPI Demoのお話。こちらも普段Android携帯使ってるのに知らないことが多くて。。。 Macでもデモが動くんですね。やっぱり動くものを作ってLTするのって素晴らしいですねぇ（なんか作るかー）\nとまぁ、最近はキーワードだけ知ってて、いろいろ触れてもいないものが多いなぁと思ってたところに、 今日の勉強会で色々見れて面白かったです。 Twitterがいろんな人に興味を持たれているのがわかります。 （けど、Twitterってどうやって儲かってるんだろう？？？） 懇親会は、入り口からは想像できない貸パーティースペースで素敵でした。 開始の乾杯の音頭を取ることもできましたし（もちろん、ムチャぶり）。 学生が多かったのですが、声をかける暇なく懇親会が終わってしまったのが少し心残りですかねぇ。 毛色が違うメンバーが居て面白いので、次回も空きがあれば参加しようと思います。 スタッフとかお手伝いもしますので。\nということで、いつものメモです。\n開催日時：2012/02/23 19:00 ～ 21:00 場所：デジタルハリウッド東京本校 1Fセミナールーム Zusaarのページはこちら。他にも学生枠とかありました。\n◯ Webサイト向けAPI @yusukey\n・Webサイト向けAPI フォローボタン、ツイートボタン、Web Intents、@Anywhere サーバサイドの実装扶養、htmlのみで構成可能 ・Twitterボタン Twitterのサイトで色々カスタマイズ可能なボタンが作れます。 ツイートのカウント表示とか。 ・Web Intents @ツイート、リツイート、お気に入りが簡単にできるものが作成可能。 ツイートの埋め込み用リンクがTwitterのWeb版のツイート詳細から生成可能。 「このツイートをサイトに埋め込む」リンクをクリックするとダイアログが出てきます。 ・@Anywhere あんまりフォローされてないけど、JavaScriptでサーバサイドなしにTwitterと連携可能。 ユーザIDを辞書的に検知してTwitterの情報をホバーで出してくれる。 ・ウィジェット（検索、プロフィール、お気に入り、リストなど） これもTwitterサイトでカスタマイズ可能。 ・ツイートボタンには公式ロゴを利用しましょう ・注意点 charsetを必ず指定しましょう。 IE/Firefoxで問題が発生します。 ◯ グルーブに分かれて簡単に自己紹介\n◯ デジタルハリウッドよりご挨拶\n◯ 「Virtua Fighter5 Final ShowdownのTwitter連動機能について」@twtrfk\n部内にAmitterというSNSを構築して自由に使ってもらって、Twitterを疑似体験してもらった。 VF5FSでの開発中はTwitter4JにAmitterのラッパーを追加してテストしてたらしい。（おもしろいなー） 当時は、筐体にツイート機能を入れることも考えていたらしい。 ツイート自体はバッチで処理してます。 ゲーム筐体にお客さんが座ってる時間もシステムの性能として考慮しないといけない。 苦労した点： テストアカウントを100個地道に作成（連番、内容がバレるアカウント名はNGだから） Twitter4Jがうまく動かなかった。。。 今後の展開： まだ未定 QA Q：FB連携とかは？ A：今は考えてないです。 ◯ LT ・ @making「Twitter Bootstrap入門」 スライドはこちら\n・Bootstrapとは？ Twtter者が提供するWebアプリケーションのフロントエンド 一般的にCSSフレームワークと呼ばれるもの 簡単にかっこいいデザインにするための枠組み ダウンロードしてきてHTMLで読み込むだけ。 ・Bootstrapのコンポーネント紹介 いろいろおしゃれなコンポーネントあるよ。（スライド見ましょう） ・Tips examplesがあるので、それをベースに作るのが簡単です！ Initializrも対応してて、こっちで作るのもいいよ！ bootstrap簡単すぎて、みんな同じデザインのサイトに（弊害） 差別化のサービスが出てきてます。 ・ @kimukou_26 「TwitterSphere of Twitter4J」\nGriffon？ codehausで作られてるGroovy製のMVCイメージのGUIフレームワーク codehausはJetty作ってるとこですね 地球儀にツイートを乗っけることができるアプリ。 Groovyの記述がちょっと新鮮。 ・ @bina1204 「ApiDemos of Twitter4J for Android」\nAPI DemosというAndroidのデモがあり、ここにTwitter4Jを仕込んでみた？ Android系は持ってるのに知らない。。。 ","date":1330015800,"dir":"post/2012/","id":"966fe8d32b86121f8a465a21b95f7e5c","lang":"ja","lastmod":1330015800,"permalink":"https://blog.johtani.info/blog/2012/02/24/%E7%AC%AC4%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E3%83%8F%E3%83%AA%E3%82%A6%E3%83%83%E3%83%89--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-02-24T01:50:00+09:00","summary":"今週も勉強会に参加しました。 @yusukey さんが開催してるTwitter API勉強会です。 前回とは会場が異なりましたが、広くて大画面で良い会場でした。駅","tags":["勉強会"],"title":"第4回 Twitter API勉強会 @デジタルハリウッド #twtr_hack に参加しました。(Jugemより移植)"},{"contents":"久々にlucene-gosenの話です。 しかも、あんまり嬉しくない話しです。\nすでにissueをアップしていますが、lucene-gosenとSynonymFilterを併用する場合に、特定の条件下でNullPointerExceptionが発生してしまいます。\n条件は以下の組み合わせになります。\nSolr 3.5.0以前 lucene-gosen1.2.0 - 1.2.1の辞書なしjar SynonymFilterFactoryにてtokenizerFactoryを指定 根本的にはSolr側の問題のようです。SOLR-2909としてissueが上がっています。\nSynonymFilterFactoryでは、類義語の設定ファイルの単語を読み込むときにtokenizerFactoryを指定できます。 このとき、SynonymFilterFactory内部でtokenizerFactoryに指定されたFactoryのクラスが読み込まれ、 インスタンス化されて、Tokenizerが作成されます。 この、Tokenizerのインスタンス化の処理シーケンスに問題があります。 schema.xmlの\u0026lt;tokenizer\u0026gt;タグで指定されたTokenizerFactoryでは、ResourceLoaderAwareインタフェースのinform(ResourceLoader loader)メソッドが実行されます。 このinform()メソッドがSynonymFilterFactoryのToeknizerのインスタンス化の場合に実行されません。 lucene-gosenのJapaneseTokenizerFactoryではこのinform()メソッドでdictionaryDirのパスの読み込みを行なっています。（このへん）\n上記の条件では、NullPointerExceptionが発生すると書きました。 辞書を内包したjarファイルを利用している場合、NullPointerExceptionが発生しなくても次のような問題点があります。こちらの問題は見た目は動いているように見えてしまうので注意が必要です。 すべて、SynonymFilterを利用する時点でも問題点になります。\ncompositePOS設定が類義語辞書読み込み時に無効 dictionaryDir設定が類義語辞書読み込み時に無効（＝jarに内包されている辞書で動作する） 一見動いているように見えるかもしれませんが、望んでいてる動作になっていない可能性があるので注意が必要です。\n解決策（まだ途中） 先程書きましたが、基本的にはSolr側の修正をするのが妥当です。 SolrのJIRAにパッチもアップされました。 こちらのパッチをSolrに適用し、SynonymFilterFactoryを次のように指定することで問題を回避することが可能になります。\n\u0026lt;tokenizer class=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; compositePOS=\u0026#34;compositePOS.txt\u0026#34; dictionaryDir=\u0026#34;dictionary/naist-chasen\u0026#34;/\u0026amp;gt; ... \u0026lt;filter class=\u0026#34;solr.SynonymFilterFactory\u0026#34; synonyms=\u0026#34;synonyms.txt\u0026#34; ignoreCase=\u0026#34;true\u0026#34; expand=\u0026#34;true\u0026#34; tokenizerFactory=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; **compositePOS=\u0026#34;compositePOS.txt\u0026#34; dictionaryDir=\u0026#34;dictionary/naist-chasen\u0026#34;**/\u0026amp;gt; ... SynonymFilterFactoryの設定にcompositePOS、dictionaryDirを追加します。 ここの設定は\u0026lt;tokenizer\u0026gt;タグで指定された設定と同じ物を指定します。以上で問題なく動作することになります。\nただし、この方法はSolrにパッチを当てなければいけません。 Solrにパッチを当てるのもなかなかな作業だと思います。 ということで、どうにかlucene-gosen側だけでも対応出来る形にしたいなぁと考えているところです。 残念ながら、まだ考えているだけですので、もう少し提供できるのは先になってしまいますが。。。 現時点では、次の方法を考え中です。\ninformメソッドを呼ぶフラグを追加して、どうにかしてinformメソッドを呼び出す SynonymFilterの修正版をlucene-gosenに内包して提供する できれば、a.にて対応できればと思っています。 最悪、b.の方法かと。 悩んでいる間にSolrの次のバージョンが出てしまわないように出来るだけ早く対応しようと思っています。 他にも問題点や気になる点があれば、日本語、英語を問わないので、気兼ねなくissueに上げてもらうか、Twitterで私宛にメンションしてもらえればと。 （あ、issue23へのパッチでもいいですよ！）\n追記： まだ、SOLR-2909のパッチを適用してからの確認はできていません。（ソース見て大丈夫だと思ってるレベル） あと、現時点での対応方法としては、「lucene-gosenとは別のjarにSynonymFilterFactoryなどを入れて提供」が妥当かなぁと考えているところです。（無理やりinformメソッド呼び出すのは骨が折れそう＋パッチが思いの外早く出て、導入されたのでlucene-gosen本体に特殊処理を入れるのはあまりメリットを感じない。）\n","date":1329756060,"dir":"post/2012/","id":"4e7b945feca199bd486653fea1d0e39c","lang":"ja","lastmod":1329756060,"permalink":"https://blog.johtani.info/blog/2012/02/21/lucene-gosen%E3%81%A8synonymfilter%E3%82%92%E5%88%A9%E7%94%A8%E3%81%99%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AE%E6%B3%A8%E6%84%8F%E7%82%B9%E5%95%8F%E9%A1%8C%E7%82%B9%E7%B7%A8/","publishdate":"2012-02-21T01:41:00+09:00","summary":"久々にlucene-gosenの話です。 しかも、あんまり嬉しくない話しです。 すでにissueをアップしていますが、lucene-gosenと","tags":["lucene-gosen"],"title":"lucene-gosenとSynonymFilterを利用するときの注意点（問題点編）(Jugemより移植)"},{"contents":"また、勉強会ログです、すみません。。。 直接業務とは関係ないのですが、今回はリクルートの中野さんが話しをされるというので顔を出してきました。 もちろん、内容も気になりましたというのもありますが。 実際には中野さんは2分くらいしか喋らなかったんですけどね。。。\n今回は、最初のセッションはちゃんとしたソースコードリーディングでした。 Hadoopの入力としてデータをHDFSじゃなくて、MongoDBから取得するときに利用するMultipleInputの実装をしてみたというお話でした。 MongoDBやHadoopを知らないと（私はあんまり知らない。。。）少しきつかったかもしれないです。 幸い、HadoopのMultipleInputについては以前、すこしだけ見たことがあったので、かろうじてついていけました。 最初の部分を聞きのがしてしまったので合っているか自信がないのですが、10genから出ているmongo-hadoopの使い勝手、効率の悪そうなところに手を入れた話しがベースになっているんでしょうか？（ツッコミあるとうれしいです） 気になったのは、MongoDBのデータをHadoopから直接取りに行くというユースケースがどういう場合に出てくるのかという点です。 ネットワークやMongoDBの負荷がHadoop処理へのボトルネックになるんじゃないかしらという懸念がありそうだなと。 発表を聞いていて感じたのは、やっぱりソース書いて動かさないとダメだよねぇ、自分も手を動かそうというところです。 リクルートさんの発表は波乱万丈（？）でした。 最後まで話しを聴いたあとに思った感想は「こんなに話して大丈夫なのかな？」「いろんな人を敵に回してない？」というものです。 実際に昨年の夏くらいからEMCの草薙さんも検証メンバーに入って、リクルート社内での活用シーンをベースにMapRの検証をいろんな項目でやられたようです。（ある程度の詳細は以下のメモ参照） で、最終的な結論はまだ出ていないのですが、最後に出てきた検討中の比較対象が某C社のCDH。 どちらかというとCDHの方に傾いてる感じに取れる終わり方で心配になりました。。。 会場が会場だからというのもあったのかなぁ？ mesosというキーワードが出てきたのが気になりました。単語だけは以前Twitterで流れてきたのを目にしてたのですが、どんなものかという概要がわかったのは収穫でした。 リクルートさんの資料はどこまで公開されるかわからないですが、もう一度見たい気がします。（mesosの部分だけでも公開して欲しい）\nということで、以下はいつもの自分用メモです。\n日時： 2012年2月8日（水） 19:00～21:30 （受付開始 18:40） 場所： 豊洲センタービルアネックス（NTTデータ、豊洲駅直通）\n◎日本OSS貢献者賞・奨励賞のご案内　@hamaken 日本OSS貢献者賞・奨励賞\n◎『オレオレMultipleInputを作る方法（仮）』@muddydixon さん http://www.slideshare.net/muddydixon/multipleinput\nhadoopからMongoDBを利用する方法を紹介 CDH3u2かu3で試しました。 10genからも出てるけど使いにくい？から作った？ MongoMultipleInputs.addInputPath で色々簡単に使えるようにしたかった。 絞り込みしてデータをMapperにとり込みたかったため。 ＝絞り込みできないと必要なデータ以外も取得できてしまいJSONのパース処理がオーバヘッドになるから。 com.mongodb.hadoop.input.DelegatingInputFormat mongodbの環境にあわせて多くのsplitを生成する。 mongosへのアクセスはメタ情報の取り出しだけ。 あとは、個々のサーバにアクセスしてるのでデータ取り出しが高速？ ◎『MapRってどうよ？ - 実際に使ってみた感触を紹介します』 - リクルート 中野さん、高林さん、大坪さん\nMapRの説明資料がなかったので、EMCの草薙さんが出てきて説明を開始。 Greenplum MRはMapRテクノロジが開発した実装のOEM版。 EMCは特に手を加えず。 ※MapRについては前回のMapR勉強会の記事を御覧くださいな。 Q：JavaのAPI互換と言われている部分はHadoopのどのバージョン？ A：CDH3u2に近いパッチが当たってるらしい。 Q：DFSIO性能の比較対象のHadoopはどのバージョン？ A：手元に資料は残念ながらないです。 ここからリクルートさん。 検証内容：性能検証 中古車サイトで利用されている3つのHiveに置き換えてみた。 結果（パーティション圧縮） MapRのほうが約1.3倍高速に（そこまで速くならなかった？） 結果（非パーティション圧縮） MapRのほうが約1.7倍高速に（そこまで速くならなかった？） ビルドイン圧縮はGzip圧縮と比較して高速 ※チューニング次第では結果変わるかもね。 機能検証：マルチテナント検証 目的： 複数ユーザに対して1つのクラスタを提供する セキュリティの担保（） 余剰リソースの有効活用 複数ユーザのJobの並列実行？ 結果１（ユーザ権限まわり） MapRのユーザはLinuxユーザに準拠。 同じmaprユーザでもUIDがずれてるとエラーが起きる。 MapR内のPermissionは内部のクラスタ、ボリュームの権限定義が可能 ※Volumeは管理者に付加的な情報を与えるような存在 Job実行はHadoopと一緒のアクセス権。 結果２（FairScheduler） MapRではデフォルトとなっている。 複数テナントからの同時ジョブ実行の動作を確認。 poolをベースにタスクを割り当ててく。 min/max値にあわせてslotが利用される模様 結果３（Load処理（Hive）、Job実行（HiveのSelect）） じゃらんPVデータ１ヶ月分をロード。 NFS→MFS 結果４（フェイルオーバー） HA機能 ノード切り替え時間、タスクの復旧までの時間とか。 結果５（DirectNFSでの転送） NFSGatewayをクライアント側にした場合との違いなど。 クライアント側に載せた場合、通信量が減るから速度が出てる。 Mesos概要 Apache IncubatorのOSS。C++により実装 効率的なリソース分離、リソース共有機能を提供するクラスタマネージャ。 Mesosでの検証 マルチテナント（ユーザ権限）硬い。 リソース制限ができない。などなど。 MapRとMesosの比較 資料期待！ リクルートとしてのMapRの評価 保守/サポート/教育が充実してるのが重要。速度だけじゃない。 けど、まだ検討中です。 Q：クラスタに対するパーミッションの権限情報はどこで管理されてるの？ どこが落ちたときにそのパーミッションの情報がとれなくなる？ A：CLDBで管理されてます。 Q：CLDB内部でのデータはバイナリ？DBを別途持ってる？ A：HDFS上にボリュームが作られてそこに吐き出されてる。 Q：Jobのスケジュールの情報とかはどこに？ A：Job管理データはJobTracker用のボリュームに保存されてる。 それを別の人が引き継ぐ。 Q：ボリュームが壊れたら？ A：さすがに壊れたら引き継げない。 けど、壊れにくくしてあるのが売り？ Q：MapRのチューニングのポイントはどんなものがあるの？ A：チューニングに関しては256Mのchunkサイズを64Mに減らした場合の化粧しかしてない。Apache Hadoopの方は若干チューニングした。 Q：DFSのシリアライズは？ボンディングとかでもできるんじゃないの？ A：そこはやってないのでやってみます。 Q：MapRでの8台構成で全部のせてみた場合、CLDBのリソースはどのくらいもっていってるの？ A：結構使ってる。CLDBを3台以上にしたらサポート対象外。 Q：CLDBを3台に制限してる理由は？ A：わからない。 Q：本番MapR、検証CDHというのはあり？ A：M3を開発環境で利用して欲しいですね。（ステマ？）開発目的だとM5を無償提供してほしいなー（EMCへのお願い？） Q：Pigの検証は？ A：リクルートではHiveを利用してたので検証してない。 次回は3月ころかなぁ？だそうです。 ","date":1328716980,"dir":"post/2012/","id":"fa16213d24273d386d22332cd01ce774","lang":"ja","lastmod":1328716980,"permalink":"https://blog.johtani.info/blog/2012/02/09/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/","publishdate":"2012-02-09T01:03:00+09:00","summary":"また、勉強会ログです、すみません。。。 直接業務とは関係ないのですが、今回はリクルートの中野さんが話しをされるというので顔を出してきました。 も","tags":["勉強会"],"title":"Hadoopソースコードリーディング第8回に参加しました。#hadoopreading(Jugemより移植)"},{"contents":"Fluentd meetup in Japanに参加しました。いつも面白そうな話を聞いてばっかりなので、役に立つためにスタッフとしても参加してみました。 まずは、会場が綺麗でびっくりしました。しかも電源タップまで用意されていてかなり充実してました。Ustはまだ見ていないのですが、Ustも録画までされていて素晴らしい運営メンバーでした。\n開発者の古橋さんほか、Treasure Data Inc.の方たち（太田さんはいなかった）が集まり、 Fluentdの仕組みから、プラグイン開発の方法、実際にプラグイン開発してしかも本番で利用してる実例まで 「パーフェクトFluentd」という本ががそのまま書けてしまうのではというくらい密度の濃い話が聞けました。 私個人は、いつものごとく興味を持ってるんだけど、仕事、私用では触っていないという腰抜けなので話についていくのが大変でしたが。。。 各セッションごとに、しっかりとしたQA時間が取られていて、質問者も質が高く、中の人や発表者の方も誠実に回答されている感じがすごく良かったです。 （残念ながらLTの時は懇親会の準備を手伝っていたので聞けてないです） 基本はログの中継サーバとして利用するという話でした。 個人的には性能系のデータやログ（遅いクエリのログに関するプラグインの話などもあった）をストレージに保存して、時間を軸にログとグラフを表示するとかいう仕組みに使うと面白いかもなぁと感じました。 今回はFluentdがメインなので、ログを集める部分の話が主だったところでしたが、懇親会直前の@doryokujinさんのスライドでも上がっていた集計後のビジュアライゼーションに関する部分のはなしも聞いてみたいなぁと思ってるところです。\nあとは、いくつか知りたかったことが。 Treasure Data Serviceというサービスをやってるみたいで、SQLライクな問い合わせやビジュアライゼーションされた画面があるみたいな話があがっていたんですが、画面が見てみたかったです。 また、@just_do_neetさんの構想図のその後を聞いてみたいですねぇ。\nそれにしても実例も構成から性能値まで上がっていたので、実際に利用する場合に参考になる資料だらけで普及にはずみがつきそうです。 Ust録画が上がっているようなので復習したいと思います。 （あ、内容とは関係ないけど、Ust録画にハッシュタグつきのツイートを時間軸で重ねて表示するサービスとか機能ってないのかな？）\nということで、以下はいつものメモ書きです。\n2012/02/04 12:30 ～ 19:00\nフューチャーアーキテクト セミナールーム\n参考URL：http://fluentd.org\n◎13:00～14:00 「What\u0026rsquo;s Fluentd? - The missing log collector」 http://www.slideshare.net/treasure-data/fluentd-meetup-in-japan-11410514 Treasure Data, Inc.　古橋 貞之 (@frsyuki)\nまずは、Fluentdの概要。syslogdみたいなもの Fileのtailで流すことが基本。 Clientライブラリから流すことも可能。 他との比較 ScribeとFluentd 構造化されたデータを扱う gemとかapt-get，yumでインストールあg可能 Rubyで書かれてるからカスタマイズもプラグインの追加も簡単。 FluentdとFlume FlumeはZKやマスタノードが必要＝セットアップが面倒 JVMだから面倒、設定も簡単。 Fluentdのアーキテクチャ Bufferプラグイン：スレッドセーフ、バッファ処理など Outputプラグイン：出力だけ out_forwardプラグイン：Cassandraと同じアルゴリズムでHeartBeatしてる out_copyプラグイン：同じ出力を別の出力先にコピー bof_fileプラグイン：バッファ先をファイルにする。Fluentdがこけても大丈夫 out_exec_filterプラグイン：外部プログラムからの入出力を使える in_tailプラグイン：ログのパーサーが内蔵されてるみたい。 開発者用API Unitテストフレームワーク（MRUnitに似てる） TailInput（パーサカスタマイズも簡単） ドキュメントとか http://fluentd.org にあります。 会社紹介！ Treasure Data Service Fluentdでは出力先がいろいろできるけど、自分で解析しないといけない ！ここで、Treasure Data Service（クラウド）に保存すると。。。 データのVisualizationとかがリアルタイムで出来る。 QA： Q：ログ転送にUDP使ってますか？ A：TCPです。UDPはハートビートに利用してます。 Q：文字コードはどういう扱い？ A：バイナリ形式であつかってます。 文字列で扱う場合はプラグインで対応しましょう。 Q：性能大丈夫？ A：Twitterで議論があがって、いろいろ対応しました。 Q：TreasureDataServiceはクラウド対応だけなの？ A：データはクラウド上で管理してるので上げても大丈夫なものだけが現在は対応。暗号化などは行なっている。 Q：TreasureDataServiceはどこで動いてる？ A：AWS上（S3にデータ保存） Q：解析プラットフォームを提供している？SQLだけ？ A：HiveのSQLで解析可能。Visualizationのツールもある。 Q：コンサルタントもあるの？ログ出力系とか。 A：あとから解析できるように。 Q：in_tailでログローテート（iノードが変わって）も大丈夫？　A：大丈夫。動かなかったら連絡ください。 Q：ファイルバッファリングされるデータの順序は保証される？ A：キュー形式なので、保証される。けど、S3とかだと出力先が遅いので、 パラレルモードで対応が可能。だけど、パラレルだと順序は保証されない。 Q：実際のシステムが投げるときにFluentd側で認証とかできる？ A：認証はないです。推奨は同一アプリサーバでFluentdを起動。 Q：Fluentd間のデータ通信のセキュリティ対応は？ A：今はない。プラグインとか作ればOK。 Q：中間層のFluentdを置くのは推奨？なしで直接ストレージ保存も可能？ A：柔軟な対応（送信先、バッファリングとか）が可能にできるように中間層を置くほうがいい。直接出すことも可能。 Q：TDAgentでのセットアップが推奨？gemは？ A：gemはOSS版でtrunkに近い。TDAgentはテストとかしっかりやってる。 バージョンの対応表はリリースノート見ないとわからない。 Q：Flumeのほうが優れているのは？ A：設定ファイルが一元管理ができる。大規模はFlumeのほうがいいかも ただし、includeでHTTPサーバ経由で設定ファイルを取得可能な機能あり。 Q：バッファサイズは指定可能？ A：可能。 Q：ストレージがずっと停止している場合にログがあふれるのを防ぎたい場合の対処法は？ A：セカンダリという機能がある。（ただし、対応できてないプラグインもある） Q：フェイルオーバーでローカルファイル出力とかはできる？ A：out_forwardは対応してる？ Q：Fluentdからのbuf_fileに出力してる部分で遅延、書き込み不可が発生したら？ A：入力と出力がスレッドで分かれてる。 入力スレッドでのエラーはinput_plugin側にException上がる ◎14:15～15:00 「Dive into Fluent Plugin」 http://www.slideshare.net/repeatedly/fluentd-meetup-dive-into-fluent-plugin Preferred Infrastructure, Inc.　Masahiro Nakagawa (@repeatedly)\n好きなプラグインとか言いましょう（発表者さん） MongoDBのプラグインをベースにプラグイン開発の説明 http://bit.ly/fluentd-with-mongo プラグイン名はfluent-plugin-xxxで統一されてます。 fluent-plugin-mongoがダウンロード数が1位に！ （scribeのプラグインがデイリーでテストが走ってダウンロード数が増えるという卑怯なカウント稼ぎしてたらしいｗ） fluentd.confの説明 fluentdの起動は以下のとおり。開発中は-vつけるといいよ fluentd -c fluentd.conf プラグインをどう作る？ Fluentdの構成図による説明 Cool.io、MessagePack、Rubyなど。 それぞれの説明を簡単に。 Cool.ioがファイル監視とかをやってくれるみたい。 プラグイン開発に関する詳細な説明 テスト、gem構成などを書いてくれてる。 QA： Q：複数行のログを扱うのはどこを作ればいい？tailプラグインの正規表現だとうまく行かなかった。 A：tailをoverrideしてparserLineを実装する。複数行のparserは難しいけどね Q：ログのアグリゲーションをやってみたいのだが、どう？CPU利用率とかを1分間バッファしてからアグリゲーションして平均出すとか。 A；fluent-plugin-aggregateってのがあって、forward-pluginを書き換えて作ってる。 TimeSlicedOutputでやると時間の期間指定とかが可能。 管理画面つくろうと思ってるので手伝ってください！@repeatedly Q：fluentd自体が処理した統計データの出力とかある？ A：古橋さんが頑張ります！協力して！=\u0026gt;@tagomoris先生が書いてる！ ◎15:15～16:00 「fluent を使った大規模ウェブサービスのロギング」 http://www.slideshare.net/hotchpotch/20120204fluent-logging COOKPAD, Inc.　舘野 祐一 (id:secondlife, @hotchpotch)\nCOOKPADでの基盤全般を見てる部署の人　PVログ＋MySQL 1日分はオンメモリにのるから高速。けど、1週間前とかになると遅くなる blackholeエンジン（MySQLの一部？）だと速い（ときどきおそくなる） データ保存でも問題 直近データしか保存できない。大きすぎて。 今後スケールしないときつくなる（1日分もメモリに載らなくなる可能性も出てくる） 他のログはMySQLへJSONでシリアライズして出力とかもしてた。 アプリでDBにログ出力はinsertのコストが厳しい。PVとかなら、1リクエスト＝1insertだけど、1リクエストで多数ログ出力とかが厳しい。 そこにFluentd登場！！！ 出力先が色々使える。（MySQL以外もOK） パフォーマンス バッファリング＋転送をやってくれるし、非同期で処理可能なのでレスポンスタイムへの影響が最小限にできてる。 安定性 プラグインはちょっと注意が必要。 バッファリングしてくれてるので、一時的に停止もできるのがうれしい。 6時間止めてもOKだったよ（テヘッｗ） 今後 PV系のログをMySQLから移行検討中 具体例！！ td-agentをrpmで入れてるし、Rubyまで入ってくれる。 構成管理はpuppetを利用してる。 td-agentの設定の注意点 「retry_limit 9」に変更してる。標準だと17なんだけど、2の16乗＝大体1日かかる。9だと大体10分くらい 中央転送用サーバ gitで設定ファイル管理してる。 よく変更するため。　gemfileで各種fluentd/pluginを利用してる。 自分たちで手を入れたソースを利用できるようにもしたいため。 テスト時にテストが書けるのが嬉しい（Rubyで出来てるアプリからもいじりやすいし、アプリのテストでも簡単に使える） ロガーへの実装追加もできる。 Tips バッファからすぐ処理させたい場合とかの説明 こんなのあったら嬉しいな。 設定ファイルの柔軟な設定記述方式 DSLにならないかなぁ（けど、やり過ぎも厳しいし。。。） ログの重要性 統計を考えられるエンジニアが重要。 どのデータにどんな価値があってそれを仕事（お金）に結び付けられるか？ QA： Q：障害対応のノウハウとか？ A：nagios、muninでサーバとか監視してる。 アラートチェックもしてる。 Fluentdの安定性は2ヶ月実際に導入してみて特に問題は出てない。 Q：MongoDBの構成は？ A：master/slave構成。PVログはS3に保存してEMRで処理。 Q：パフォーマンスの測定は？ A：40Mbit/sが処理できてたのは見てる。あとは、後ろの発表ですごいのがある！ Q：設定ミスの防止とかをどうやった？ A：今回はpuppetの設定後のリロードをチェックするような仕組みを入れた。 本来なら、データが流れてるかどうかのチェックを入れるプラグインを書いて欲しいｗ Q：データマイニングエンジニアの定義は？ A：データの価値を見いだせるエンジニア。あとは、きちんと統計学を学んできてるエンジニア。両方募集中！！ Q：DynamoDBは検討は？ A：西海岸でしか動かないのでデータ転送の時間がかかってしまった＋RESTで１件ずつ登録なので今回は見送った。スキーマレスなのでうまく使えそう。 A２（古橋さん）：バルクインポートがないので使いにくい。 Q：ログ出力の形式をFluentdにあわせて変更したとかありますか？ A：もともとアプリで出力してたから特に変更なかった。 ◎16:15～17:00　「fluentをサービスで使ってみた」 http://www.slideshare.net/naverjapan/20120204fluent-public NHN Japan株式会社　Tetsuya Ohira (@just_do_neet)\n自己紹介が面白かったｗ 実例の話。 事例１： 社内向けのログ解析に利用　Fluentd＋Hadoop データノードにFluentdで出力して、データノードからHDFSに書き込んでる。 事例２： NAVERまとめのまとめ作成者へのデータ解析 Fluentd＋Hadopo＋Azkaban Azkaban（個人的にはオススメできないｗ） flutendの負荷は全然上がってない。 監視 tcp portの監視 転送されたデータサイズのチェック。HDFS側のデータ量でチェックしてる。 なぜか半死半生の状態になった（よくわからない。） プラグインを自分で直せるので対応が楽。（Ruby力は必要だけど。） demo 準リアルタイム解析基盤の構成案（おもろそう） fluentd、MongoDB、Hadoop、Jubatus、node.js 地図にアクセス解析結果をのっけて見せる。（maptail.js？） 提案or相談： 動的に設定ファイルの内容を変更できるようにしたい log rotateのタイミングでshell実行でfluentd再起動 必要な情報だけrelayしたい フィルタープラグインみたいなものが書きたい。 fluentd自体のメトリクスを出して欲しい jubatusプラグインはー？ QA：　Q：log rotateへの対応はどーしてる？ A：今はログローテートのタイミングでfluentd再起動してる Q：Apps側のFluentdがコケたときにaccess_logをcopyしてるらしいけど、重複しないの？ A：失敗した対象のログをストレージから一旦廃棄して、再送してる。 Q：Rubyがそこまで得意じゃないのにFluentdを選んだ理由は？ A：他のモノが使いにくかった＋既存システムに手を入れなくて済む＋タイムリーだったという理由。 Q：構成案のデータの流れは？ A：MongoDB、Hadoopへは同一ログを流して、リアルタイムが重要な場合はMongoDB、大量データ回すのはHadoop？ ◎17:15～18:00 「Distributed message stream processing on fluentd」 http://www.slideshare.net/tagomoris/distributed-stream-processing-on-fluentd-fluentd NHN Japan株式会社 ウェブサービス本部　Tagomori Satoshi (@tagomoris)\nsed | grep | wc がメイン。 Hiveで集計してます。 なんでFluentd？（not Storm、Kafka or Flume?） Rubyが好き（ライブドアはJavaが入ってない環境もあるし） プラグインやTimeSlicedOutputがあるのも採用理由 ログ収集の構成図 ブログに別の勉強会の資料があるので見てください。 まだ１０日間しか動いてないので実績は少ない？ 127サーバからのログを流してる。 7万行/sec、ピーク120Mbpsが流れてる。 89 fluentd インスタンスが12ノード（4コアHT）で動いてる。 1行のログを1行のタブ区切りで出力する（Hiveでインポートしやすいから） Apacheのログに幾つか追加したデータなどが出力されてて、それをタブ区切りにするため設定一発では変換できない。 TimeSlicedOutputが重要 時刻単位でログ出力できないとキツイ（ログの流量が半端ないから） ログローテートでは時刻単位できちんと出力されてない。 ログから解析までの流れ図 以前は生ログをHadoopに書き出してたので25分くらいのタイムラグが出てしまっていた。（ノード数が少ないという理由もあるけど、お金的に増やしたくない）＋Hadoopで他のジョブが実行されてるとさらに遅くなる。。。 fluentd でログを流しながらコンバートもかけられ、Hadoopでのデータコンバートの処理遅延が少なくなってハッピーに！ ストリーミング処理の重要な点 バッチでもストリーミング処理でも同じことが可能。（out_exec_filterとHadoop Streaming） SPOFがないこと トポロジ、Fluentdの構成　ログエージェント（scribeline：お手製） pythonで書かれたscribelineというものを利用してる。 フェイルオーバーの処理（primary、secondary構成）が可能 fluentdは入れてない。（ログを拾い上げて流すだけには重い） workerノード serializerノードが必要なのは出力先の競合を減らす必要があるため。 出力先が大量のアクセスに向いてない場合があるから。 あと、ログの流れを元に監視したい項目にもここで対応可能。 watcherノード deliver、serializerからのデータを見ながら監視、統計処理を行える。 設定は自動生成してる。800行くらいになっちゃうから。 workerへの分散具合をよしなにしたいから。 remove_prefix 、add_prefixでデータの流れ先の交通整理してるのか。 GrowthForecastでグラフを出力してる。 https://github.com/kazeburo/GrowthForecast QA Q：大規模環境での移行はどうやったの？ A：もともと流すような仕組みはあって、流し先を変えたので それほど大変ではなかった。ただ、アプリ側で動いてた部分に手を入れたときは配備が大変だった。 Q：workerが1サーバ8の理由は？ A：4コアHT＝8というので8としている。 Q：deliverのカーネルパラメータをいじってたりしない？ A：ライブドア標準の設定がされてる。CentOSのデフォルトでもそれほどきびしくないかな？ Q：deliverノードでラウンドロビン＋out_forwardになってる理由は？out_forwardだけじゃだめ？ A：バッファのタイミングでの切り替えだと溢れてしまうので、最大でも1秒でラウンドロビンしてworkerを切り替える必要がある。 ※懇親会設営の手伝いのためあんまり聞けず。 ◎18:15～19:00(Plugin紹介LT)(各10分)　@shun0102: 「fluent-plugin-dstatを使ったリアルタイムクラスタモニタリング」 http://www.slideshare.net/shun0102/fluent-plugindstat\n@ixixi: 「fluent-plugin-couch」 http://www.slideshare.net/ixixi/fluent-plugins-for-couchdbamazon-sqssns\n@chobi_e: 「Fluentd \u0026amp; PHP」 http://www.slideshare.net/shuheitanuma/fluentd-and-php\n@railute:「Fluent Output Plugin for Cassandra」 https://skydrive.live.com/view.aspx?cid=D105615A0F594518\u0026amp;resid=D105615A0F594518%21333\n","date":1328367780,"dir":"post/2012/","id":"a2679a7d860a0bfb2645809ed92ce138","lang":"ja","lastmod":1328367780,"permalink":"https://blog.johtani.info/blog/2012/02/05/fluentd-meetup-japan%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-02-05T00:03:00+09:00","summary":"Fluentd meetup in Japanに参加しました。いつも面白そうな話を聞いてばっかりなので、役に立つためにスタッフとしても参加してみました。 まずは、会場が綺麗","tags":["勉強会"],"title":"Fluentd Meetup Japanに参加しました。(Jugemより移植)"},{"contents":"昨年末に今年の抱負について書いたのですが、 他にも興味あるものが増えたので備忘録＆公約？を兼ねてブログに書いておきます。 （興味あるものがあれば、シェアしたりできると楽しいので、ツイート、コメント待ってます。）\nZooKeeper SolrCloud SenseiDB Lucene 検索システムのアジャイル開発？ まずは、ZooKeeper。このなんとも言えないアイコンでお馴染みのヤツです。 こんな顔してますが（顔関係ない。。。）、いろんな所に出没します。 Katta、Lilly、SolrCloudにも出てくるんです。SenseiDBにも出てくるんです。分散処理にことごとく絡んできます。 で、これは、知っとかないとまずそうだと。\nSolrCloud。まぁ、妥当です。一応、Solrな人なんで。 昨年、NewSolrDesignを訳してみてもいます。訳しただけでほったらかし。。。 elasticsearchとかSenseiDBとかSolrに似たLuceneを利用している検索サーバがチラホラ話題になってます。 できれば、このあたりの分散の仕組みを比較しながら調べたいなと思ってみたり。 すべてをカバーするのはキツイので、SolrCloudかSenseiDBあたりを調べていきたいなぁと。\nで、SenseiDBです。先日、Publickeyで記事が出て飛びつきました。 Zookeeper使ってるし、分散だし、全文インデックスにLucene使ってるし。 なんだか興味あること、全部入りな感じです。\nLuceneも興味津津です。 Solrがコアとして使ってますし、昨年、Solrと同時にリリースされるようになりました。 Luceneも奥が深く、時々、Solr調べててLuceneのソースも見るのですが、本格的に全体像を把握したりは残念ながらできていません。 そのくせ、Zookeeper同様、いろんな所に出没するんです、これが。 ということで、足元を固めるためにもLuceneに入門しないとなぁと。\nで、最後に検索システムのアジャイル開発です。 lucene-gosenのコミッターをやらせてもらってたり、Solrに絡んだ仕事もしてますが、長期にわたってフィードバックをもらいながら検索システムを育てていくというのが最近興味が出てきてることです。 検索システムは作ったらおしまいとは行かないのが厄介なところです。 データは増加しますし、検索されるキーワードも変わってきます。 また、検索される方法も変わってきたりもします。 ユーザが検索したいものも変化があります。 思ったように検索にヒットしない場合とユーザが離れて行ってしまいますし、検索しにくい場合も同様です。 今日、クックパッドの方の話しを聞いて思い出した次第です。（前に、Solr勉強会でも同じ話しをされて、同じ思いに至ったのですが、いかんせん忘れやすくてｗ） また、ログ解析の話などをTwitterで見てることもあり、検索という側面でのログ解析ってのも重要だよなぁと。 いくつか思いつくこともあるのですが、実践出来る場も限られてます。 色々と話しをする場を設けるのも面白いかもなぁと妄想してる次第です。\n取り留めもなく、現時点で気になってることを書きだして見ました。 また、数ヶ月したら気が変わってるかもしれないですが、とりあえず書き残してみます。 興味がある方がいらっしゃったら声をかけてもらえるとうれしいですね。\n","date":1327596641,"dir":"post/2012/","id":"58e83fb33c120db338132d23b9112805","lang":"ja","lastmod":1327596641,"permalink":"https://blog.johtani.info/blog/2012/01/27/%E4%BB%8A%E8%88%88%E5%91%B3%E3%81%8C%E3%81%82%E3%82%8B%E3%81%93%E3%81%A8/","publishdate":"2012-01-27T01:50:41+09:00","summary":"昨年末に今年の抱負について書いたのですが、 他にも興味あるものが増えたので備忘録＆公約？を兼ねてブログに書いておきます。 （興味あるものがあれば","tags":["備忘録"],"title":"今興味があること(Jugemより移植)"},{"contents":"ということで、いつものように勉強会に参加したメモです。\nhttp://atnd.org/events/23608 日時 :2012/01/26 19:00 to 22:00 会場 :アカデミーヒルズ(六本木ヒルズ内) 49階（タワーホールA） （港区六本木6-10-1） ハッシュタグ :#mnlgy\n■タイムテーブル 司会：CROOZLabs株式会社 研究所 所長 代表取締役社長　小俣 泰明 モーションノロジーの説明があったけど、他のことしてました。すんません。 1. 発表者: 有限会社未来検索ブラジル　森 大二郎 概要：groongaの索引構築の実装 全文検索とは。歴史から 1971：full-text。。。というキーワードが。 現代の全文検索の課題はあんまり変わってない 全文検索の手法 いくつかあるけど、転置索引の説明だけ。groongaも転置索引 groongaはインデックスの動的構築が得意 静的構築も考慮してます。 2. 発表者：CROOZ株式会社　長谷川 博紀 概要：MeCabからの脱出？(仮 CROOZ MALLの解説 MySQLとMeCabでやってます。 Tritonnつかってるのか？ groongaとの性能比較検証やってみました。 MeCabが問題じゃなくて、辞書ありの形態素解析が問題。 辞書にない単語もうまく検索したい 辞書に単語登録したら形態素やり直し ソート用のデータが。。。（ここはわからなかった） QA Q：MeCabの代わりとなっているものは？ A：MeCabを改善してみる？ 3. 発表者 : グリー株式会社　一井 崇 概要：全文検索のちょっとちがった使い方（仮） グリーでの数値指標管理 事前集計してKVSに登録してみてみる 1億パターンのキーが存在する。。。 キーがわからなくなる問題とか事前集計できてる？とか迷子になる。 キーも全文検索に入れてみては？ 「富士山の標高は何メートル？」とかでデータが取れる。 構造化されたキーをkey stringとして全文検索する。 構造化Keyに対応したKVSがあればいいんだけど。 データストアとしての全文検索もいいのでは。 4. 発表者：株式会社クリアコード　須藤 功平 概要：rroongaによる検索サービスの実装 groongaとRubyの組み合わせでrroonga。Rubyによるインタフェース？ groongaとのつながり部分をRubyで書いたライブラリ 多段ドリルダウン機能 絞り込みによる検索結果の比較とかに利用可能 メタデータ抽出にドリルダウンが便利 例：番組説明から出演者を抽出 サジェスト機能もある コンテンツベース すぐできる。候補の精度がいい 統計情報ベース 元データがある程度必要 候補が増えるけど、精度の問題あり 5. 発表者: 株式会社ぐるなび　塩畑 公一 概要: groongaの位置情報検索関連について。 2010年4月からgroongaを利用し始めた レストラン検索、地図検索など 円形、矩形の緯度経度検索が可能。 距離算出もやってる。ソートとか用かな。 球面近似もやってる。 geoの検索速度についてパフォーマンステストしました。 Q：近似手法をいくつもサポートされてるけど必要？ A：距離計算を正確にしないと不利になるお店が出てきちゃうから 6. 発表者: クックパッド株式会社 兼山 元太 概要: Solrを使ったレシピ検索のプロトタイピング クックパッドとは？ 女性多いよ AWS上でRubyで組んであるよ プロトタイピングって？ ユーザの問題を発見してから、プロトタイピング 本番デプロイ（一部ユーザに公開） 問題を抱えているユーザーに向けてそれぞれ数十のバージョンが動いている インタビューとかしてフィードバック受ける。 本番の検索エンジンのフィールドをいっぱい追加 Solrの紹介（MySQL（Tritonn）から移植しました） ダイナミックフィールドやレプリケーションの話。 JSON型でHTTP経由で検索できるのが便利。 Solr本の紹介して頂きました！あざっす！ 気になってるSolrの新機能 not to cache SurroundQuery BloomFilter Q：全部AWS？ A：全部AWSに移行しました。 とまぁ、参加してきました。 初六本木ヒルズで、おしゃれな場所、雰囲気にやられてしまって、あんまりちゃんと聞けてないところがありますが。。。 メモを取りましたので。参考までに。 groongaについては勉強不足のため、いまいちついていけませんでした。 ちょっと英語の記事を読んでいたのもありまして。（内職良くない。。。） MeCabに関する発表に興味があり、勝手にMeCabの代わりorMeCabよりいいものを使ってます！みたいな発表かと想像していました。（ちょっと違ったみたい、妄想は良くないですね。。。）\nグリーの方の発表は興味深かったです。ログ解析とかにも確かに全文検索の技術使えるし。 検討が進んだ次の話も聞いてみたいです groongaの位置情報の話やrroongaでのgroongaの色々な機能のはなしも出てきてgroongaの理解もちょっと進んだのはありがたかったです。\n最後のクックパッドさんの話は、今回もわかりやすくて面白かったです。 検索を成長させていくという姿勢と、実際にどんな形でそれを実施されているかが楽しそうに話されててとても羨ましかったです。 次はSolrで困ってる点とか、検索のログとか利用され方をどのように解析してるのかといった話も聞きたいですね。\nどうしてもSolrに思い入れがあるので、感想が偏ってるかもしれません、すみません。 気になる点やいや、こうなんだよ！ってツッコミがあれば、ぜひコメントやTweetしてもらえるとありがたいです。\n","date":1327593155,"dir":"post/2012/","id":"c6dc6e6567d673436ac41ebc8e79a9ec","lang":"ja","lastmod":1327593155,"permalink":"https://blog.johtani.info/blog/2012/01/27/%E3%83%A2%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%8E%E3%83%AD%E3%82%B8%E3%83%BC2012-1%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-01-27T00:52:35+09:00","summary":"ということで、いつものように勉強会に参加したメモです。 http://atnd.org/events/23608 日時 :2012/01/26 19:00 to 22:00 会場 :アカデミーヒルズ(六本木ヒルズ内) 49階（タワーホールA） （港区六","tags":["勉強会"],"title":"モーショノロジー2012#1に参加しました。(Jugemより移植)"},{"contents":"日時：2012/01/19 18:30-20:30 場所：ベルサール三田Room2シアター\nInside MapR デモ＋内部のお話。 ・自己紹介 Susheel Kaushik 元YahooのHadoop系の人。製品担当責任者。 草薙さん 3台のベアボーンでMapRが動いてるデモが開始。 クラスタ管理画面の説明。 なぜか、NFSのサービスが1台落ちてますがｗ MapReduceなんかの実行結果なども出てくるのか。 ボリューム管理も画面から操作 レプリケーション、スナップショットも管理画面で操作、動作確認できますよ。 ミラー先はリードオンリーでボリュームの同期が可能。 スナップショットによりMapRのクラスタ内部にバックアップが保持可能。 NFSのHA構成可能。VIPの機能などもあるよ。 事前定義された各種Alertの発行も可能。 JobTrackerもMapRで拡張された表示がある。 例：MapTaskPrefetchCapacity：次のジョブのMapperを起動する準備可能な仕組み MapR内で独自に出力してる測定値をGangliaで見ることができるよ。 MapRはHadoopの置き換えとなる製品。 HDFS部分を重点的に性能アップさせるために主に置き換えた製品。 MapReduce部分にも手を入れてる。例：Direct Shuffle（HTTPじゃなくて、RPCでShuffleの通信を行ってるとか）ボリューム活用してるらしい。 分散NameNode、JavaGCの影響の排除、ビルトイン圧縮によるI/O削減など。 Mapperの出力をHDFSに置くと、メタデータ更新が多くなり、NameNodeがパンクする。（Apache Hadoop） Q：中間データもレプリケーションすると性能劣化しないんですか？ A：中間データボリュームは特定ノードしか保持されない（＝レプリカ数は１） ストレージプール（SP） ソフトウェアでストライピング。RAIDしなくてよい。 コンテナ（データ、ネームがある。） データブロックをグループ化したもの ※ストレージプールの数と同数のボリュームを作成すべき。 CLDBがコンテナを管理してる。 Q：トランザクション失敗するのは？ A：どこかにかければトランザクションは成功。 コンテナが復旧してきたら、データがコピーされる。復旧されない場合は別途コンテナを割り当てることもある？ Q：ノードが追加される場合の挙動は？ A：。。。聞き逃した。 トポロジ ノードを階層的にグループ化してデータ配置をコントロール。 Q：トポロジ設定などの権限設定は？ A：Permission画面があるよ。 Q：ボリューム単位のファイルシステムアクセスに関する設定は？ A：？？？聞き逃した？ ボリューム いろいろな設定が可能。 スナップショット Copy-on-Write方式による差分格納 ミラー ソースからミラーにコピー。手動orスケジュールによる起動が必要。 ミラー側はRead-only ※誤解を招きやすいので注意 読み出しが多い場合にミラーを利用することで対応が可能。 ビルトイン圧縮 LZZFの一種を高速化してる ネットワークIOにも効いてくる JobTracker HA 最大３ノードで構成可能。アクティブスタンバイ NFS HA すべてのノードで稼働可能。 NFS機能 NFSv3相当 クライアント側にNFSサービスをインストールするという構成も可能に。 Q：NFSマウントして作成したファイルもブロックサイズ分のファイルサイズになるの？ A：8Kバイト単位で内部的にはファイルを作成してる。8KB単位で圧縮して管理してるので、小さいサイズでもいい。（アロケーションサイズが8KB） Q：8KBにしてしまったために大きなブロックサイズの利点がなくなるのでは？ A：オーバーヘッド内容な構成になってる。シーケンシャルに8KBに並んでるから？ Q：NFSによるとMapReduceによるアクセスの排他制御とかは？ A：独自で頑張らないといけない。Job起動時に効果的にスナップショット取ったりはしてない。 リバランスもバックグラウンドで実行可能 Apache Hadoopが備えるJava APIは100%語幹 Q：なんで、HDFSをがりっと書き換えたの？ A：運用性も、ノード管理も。。。全部です。 なくなっても良いデータなら、別にHadoopでもいいですよね。 けど、基幹システムとかだと、信頼性が必要だし、運用の効率も必要だしいろいろ必要。 Q：実績が必要なんですが、どのような試験を行われているのかという情報が公開される？EMCでやられてるテストのプロセスを適用しているなどの裏付けは公開されないの？ A：内部で6ヶ月利用してデータロスはない。 品質については強化していく。 Q：MapRとしてHadoopコミュニティへの還元していく内容ってどんなもの？ A：Apacheコミュニティに対して1000台のクラスタを提供してスケーラビリティテストとかやってくださいとしている。 Q：このクラスタを実際にはどう使ってもらうの？ A：品質アップするためにテスト環境として使ってもらう？ Q：ApacheのAPIの互換性を死守するのが必ずしもいいとは思えない場合にどうするの？MapR独自APIとかは出さないの？ A：ApacheのAPIに準拠するのは非常に重要。他のHadoop上のアプリが動作しなくなるから。 Q：MapRを容量の大きなファイルシステムとしてだけ利用するなんて想定はありますか？MapReduceを利用しないパターンです。 A：いや、それはｗ Q：MapRはエンタープライズがターゲットだけど、Amazonはパブリッククラウドが対象。マルチテナントなパブリックサービスでMapRを利用するとかは？ A：。。。 Q：ジョブ管理にも手を入れてるの？ A：あんまり手を入れてません。 Q：EMCのストレージ製品でMapRのMapReduceない版みたいの出てない？ A：中身はMapRじゃないですよ。 想定とは異なり、日本の草薙さんが主に説明されたのですごくわかりやすかったです。 しかもかなり内部まで理解されている方だったので突っ込んだ質問にもきちんと回答されてるので更に理解が進みました。 今回利用された資料は現時点では公開の予定はないという話でした。 ただ、かなりまとまってる資料なので、後悔して欲しいものです。 普通にviとかしてるだけなのに、すごいと思うデモってなんか新鮮でした。 MapR自体を触る機会はまだまだないと思うのですが、MapRとしてHadoopに対する思想が垣間見えたのが面白かったです。 すごいメンツが質問を投げまくるのでいろいろな側面で話が聞けました。 ただ、やっぱり英語のヒアリングがダメダメだというのが露呈しました。。。今年は少し頑張らないと、先が思いやられますね。。。 あと、疑問と言うか、感想ですが、MapR自体が結構多機能で、その機能をどう扱うか、どのようなノード構成やボリューム構成を取るかといった設計が結構大事でしかも大変なんじゃないかなぁという印象を受けました。 特にマルチテナントで利用する場合などは、想定されないミラーの利用などでデータ容量が足りなくなったりといった側面も出てくるのかなぁと。\n説明会のあと、Hadoopにあんまり絡んでないのに図々しくも飲み会にまで参加してきました。 これまた濃いメンバーだったので話についていくのも大変でしたが、面白い話が聞けました。やっぱり懇親会重要ですよねぇ。\n事前にこのブログを読んでいたので話しを聞くのが楽でした。 MapR勉強するために必須のページです。（どうやら今日説明した人がかいてるきがしますが。。。）\n追記： トゥギャってくれた人に感謝。 ","date":1326988680,"dir":"post/2012/","id":"7198e10ebcf1bb88dc479b5c5b9f2c15","lang":"ja","lastmod":1326988680,"permalink":"https://blog.johtani.info/blog/2012/01/20/mapr%E4%B8%AD%E8%BA%AB%E8%AA%AC%E6%98%8E%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-01-20T00:58:00+09:00","summary":"日時：2012/01/19 18:30-20:30 場所：ベルサール三田Room2シアター Inside MapR デモ＋内部のお話。 ・自己紹介 Susheel Kaushik 元YahooのHadoop系の人。製品","tags":["勉強会"],"title":"MapR中身説明会に参加しました。(Jugemより移植)"},{"contents":"お久しぶりです。インフルエンザで一家全滅という最悪の状況に陥っていた我が家でした。 流行してるみたいなのでみなさんも気をつけてください。\nさて、そんな中、OSSAJのミニセミナーでSolrについて簡単に話しをしてきました。 人生初Ustだったのですが、ぶっ倒れている中作成した資料だったためなんとも情けない発表だった気がします。（言い訳カッコ悪いですね。。。） 関係者の皆様、申し訳ございませんでした。\n内容としては、Solrの機能を簡単に紹介する程度の資料となっています。デモなどもないのでスライドだけ見てもなんだこれという感じかもしれませんが。\nということで、恥ずかしながら、録画もされているようなので、後で見て反省しようと思います。。。\n[オープンソースソフトウェア検索サーバ Solr入門](http://www.slideshare.net/JunOhtani/solr-11146713)** View more [presentations](http://www.slideshare.net/) from [Jun Ohtani](http://www.slideshare.net/JunOhtani) ","date":1326941184,"dir":"post/2012/","id":"a4462529ab493676987d946019a14945","lang":"ja","lastmod":1326941184,"permalink":"https://blog.johtani.info/blog/2012/01/19/ossaj%E3%81%AE%E3%83%9F%E3%83%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%A7%E8%A9%B1%E3%81%97%E3%82%92%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-01-19T11:46:24+09:00","summary":"お久しぶりです。インフルエンザで一家全滅という最悪の状況に陥っていた我が家でした。 流行してるみたいなのでみなさんも気をつけてください。 さて、","tags":["勉強会"],"title":"OSSAJのミニセミナーで話しをしてきました(Jugemより移植)"},{"contents":"先日のSolr勉強会でLucene/Solr4.x系のlucene-gosenについて質問を受けていたのを忘れないように（年越しちゃいました、すみません。）先週金曜日（1/6）にissueに登録しました。 まずは忘れないようにと思って、登録だけして3連休に突入したのですが、Robertさんが1/7に対応してくれました。 Lucene/Solr 4.x系では3.x系とはパッケージやメソッドが変更されるなど少し異なる部分があります。 lucene-gosenでは、プロジェクトのページにもあるとおり、4.x系にも対応しています。 ただ、この4x系に対応したブランチが、2011年5月から放置されていました。\nということで、Lucene/Solr 4.0系でlucene-gosenを利用されている方、これから利用される方は、この4x系に対応したブランチを利用してください。 なお、このブランチにはLucene/Solrのtrunk (r1228509)のSNAPSHOT版のjarファイルが利用されています。\n今後はlucene-gosen側でバグ修正や機能追加を行った場合にも4xブランチを更新していく予定です。 ※ただし、Lucene/Solr 4.0が正式リリースされていないため、頻繁にSNAPSHOTのjarファイルを入れ替えることはこなわないと思います。\n","date":1326033660,"dir":"post/2012/","id":"f7df7b85af230b2623d3a827b0cbddd2","lang":"ja","lastmod":1326033660,"permalink":"https://blog.johtani.info/blog/2012/01/08/lucene-gosen%E3%81%AElucene-solr4-0%E5%AF%BE%E5%BF%9C%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%9B%B4%E6%96%B0/","publishdate":"2012-01-08T23:41:00+09:00","summary":"先日のSolr勉強会でLucene/Solr4.x系のlucene-gosenについて質問を受けていたのを忘れないように（年越しちゃいました","tags":["lucene-gosen"],"title":"lucene-gosenのLucene/Solr4.0対応ブランチ更新(Jugemより移植)"},{"contents":"あけましておめでとうございます。（もう5日ですが。。。） 今年もlucene-gosenを中心に色々と記事を書いていきますので、ツッコミ、コメント待ってます。\nたまには会社のブログを書かないとイカンということで、会社のブログにNearRealTime検索についての記事をアップしました。 読んでやってください。\nということで、今年もいろんな勉強会に出没しますので、よろしくお願い致します。\n","date":1325735817,"dir":"post/2012/","id":"cc573488dec311655890a205aad4fb65","lang":"ja","lastmod":1325735817,"permalink":"https://blog.johtani.info/blog/2012/01/05/%E3%81%82%E3%81%91%E3%81%BE%E3%81%97%E3%81%A6%E3%81%8A%E3%82%81%E3%81%A7%E3%81%A8%E3%81%86%E3%81%94%E3%81%96%E3%81%84%E3%81%BE%E3%81%99%E4%BC%9A%E7%A4%BE%E3%81%AE%E3%83%96%E3%83%AD%E3%82%B0%E6%9B%B4%E6%96%B0/","publishdate":"2012-01-05T12:56:57+09:00","summary":"あけましておめでとうございます。（もう5日ですが。。。） 今年もlucene-gosenを中心に色々と記事を書いていきますので、ツッコミ、コメ","tags":["misc"],"title":"あけましておめでとうございます＋会社のブログ更新(Jugemより移植)"},{"contents":"他の方たちよりひと足はやいですが、今年の仕事が終わりました。 せっかくブログを始めたので、振り返りと来年の抱負など書いてみようかなと。\n今年の振り返り まずは、今年1年を振り返ってみます。 今年の出来事はこんな感じでした。\n3月に仕事が一区切り lucene-gosenに参加 ブログを始める 色々な勉強会に参加 Twitterでつぶやきまくり Mac Book Airの購入 PSVita買いました 3月に一昨年から参加していた仕事が一区切りつきました。 もう少し色々とやり残した感がある中で区切りがついたのが少し心残りでした。 あと、3月は震災もあり、色々と大変でした。ただ、自分の中では震災の記憶が少し薄れつつあるのが気がかりです。 良くも悪くも忘れて行ってしまうのだなと。今でも頑張っている方々もいるので、少しでも心に留めておきたいものです。\n個人的に一番大きな今年の変化は「lucene-gosenへの参加」です。 関口さんとここ数年ずっと仕事をご一緒させていただいていることもあり、コミッターとして参加させてもらうことが出来ました。 英語が苦手な中、Robertさんへ自己紹介のメールを書いたり、Issueを英語で書いたりと苦労もしていますが、OSSに参加できることがとても楽しいです。 また、使っていただいている方たちからのフィードバックもいただけているのがすごく励みになります。 やはり、OSSは使ってもらってさらに良いものになっていくのかなぁという感想です。 ただ、自分の腰が重いため、なかなか対応が遅かったりといったところもあるなと反省するところも。\n勉強会にも色々と参加しました。Solr勉強会を始めとして、かねてより興味があるHadoopのカンファレンスやソースコードリーディング。MongoDBの勉強会やDSIRNLPといった少し研究よりの勉強会にも参加しました。 Solr勉強会に参加してきた経験もあり、他の勉強会にも気負わずに参加できたので本当にSolr勉強会には感謝しています。 おかげで、社外のいろいろな方と話ができ、様々な刺激をうけることが出来ました。\n勉強会以外にもTwitterで色々な方に絡みまくったのもまた社外の方とのつながりが出来るいい機会でした。 Twitter依存症じゃないかというくらい、つぶやいたり、人に絡んだりしてます。。。（迷惑だったら言ってください。） お陰で@doryokujinさんや@wyukawaさんが主催してくれたログ解析の飲み会に誘ってもらえたり、@nobu_kさんや@ IjokarumawakさんにSolr勉強会で講演してもらえたりしました。 あと、Twitterを通じて勉強会やHadoop関連の情報、lucene-gosenへのフィードバックなどももらえていてかなり助かってます。 @yusukeyさんや@repeatedlyさんに遊んでもらってるのも楽しいですｗ\n最後の大きな変化はApple製品の購入でした。 これまでもブログで書いてきましたが、私は今年の中頃までアンチApple派でした。 それがここ半年足らずでAir、Mini、iPadと3つのApple製品に囲まれています。 Emacsのショートカットが使えるのが最大の要因ですが、何ごとも毛嫌いせずためしてみるのがいいなと思いましたね。 今では、Windowsで開発したくないくらいになってきています。\n2012年の抱負 さて、来年の抱負です。 今年いくつかチャレンジしようとして挫折してるものがあります。\nMongoDB触ってみる Scala触ってみる なんかWebサービス作ってみる（Amazonとかで） elasticsearch、IndexTankを調べてみる NewSolrCloudDesignを読み込んで自分なりにまとめる Junsaiに参加する 「7つの言語7つの世界」の続き 最初の3つはセットですかね。コップ本買ったり、NoSQLの本を買ったりしてるのですが、手付かずです。。。 電子書籍の検索サービスでもつくってみようと思いつつ、腰が重い状態です。 来年は余裕を見ながらちょっとずつやりたいですね。\nelasticsearchやIndexTankは仕事がらみです。 Solr入門を書いたこともあり、検索関連には興味があります。Solrだけでも2ヶ月おきに新バージョンがリリースされたり、4.0系でいろんな機能が実装されているのですが、それ以外にもOSSの検索サーバがいくつかあります。 気になってはいるものの英語が障壁でなかなか手を出して来ませんでした。 来年はSolr以外についてももう少し知識をつけていきたいです。 個人的ですが、分散処理にも少々興味を持っています。 慣れ親しんでいるSolrでもSolrCloudという壮大な計画が上がっていて、少しずつ実装もされています。 ブログでWikiページを翻訳してもみたのですが、翻訳に注力しすぎて理解ができていないです。 このあたりをもう少し理解しつつどのような実装がされているかも調べたいところです。\nJunsaiはSolr入門の著者である武田さんが最新のMeCab（今はMeCabが新しくなってしまったので、少し前のMeCabになってしまいました）をJavaに移植したプロジェクトです。 今年頭のSolr勉強会でお披露目があり、私も一応参画しているのですが、手が出せていない状態です。 lucene-gosenで少しは経験を積んできたので、その部分を生かしつつ、こちらももっと活性化させたいところです。 最後は夏ごろにやっていた「7つの言語7つの世界」の再開です。序盤で止まってしまっています。。。 新しい技術に触れる題材としてちょうどよいので、余裕をつくって続きを再開します。 なんか、抱負と言うよりも積み残しですね。。。 他にもTwitterで情報を仕入れるとやりたいことも変わってくるかもしれませんが、それも含めてブログに少しずつでも書きためていこうと思います。\n先ほども書きましたが、今年はTwitterを通じて色々な方たちと知り合いになれた一年でした。 ここには書ききれていませんが、フォローしてもらっている方々や勝手に絡んでも相手をしてくれている方々に感謝しています。 今後も絡みますのでよろしくお願いしますｗ あと、様々な勉強会に今後も顔を出していくので、かまってやってください。 いやぁ、色々書いたけど恥ずかしいですね。。。 まぁ、何事も経験なので、恥ずかしいと思いつつ今後も色々書いていきます。\n","date":1325006100,"dir":"post/2011/","id":"7164823f504286e3a762ee612ff0a988","lang":"ja","lastmod":1325006100,"permalink":"https://blog.johtani.info/blog/2011/12/28/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A0/","publishdate":"2011-12-28T02:15:00+09:00","summary":"他の方たちよりひと足はやいですが、今年の仕事が終わりました。 せっかくブログを始めたので、振り返りと来年の抱負など書いてみようかなと。 今年の振","tags":["misc"],"title":"今年の振り返りと来年の抱負？(Jugemより移植)"},{"contents":"@yusukeyさんにサインをもらう目的で勉強会に参加してきました。前回もらいそびれたのでｗ 残念ながら、まだTwitter APIを触ってないし、利用したサービスも思いついてないんですが。。。 けど、勉強になりました。 といことで、いつものごとく、自分メモです。\n◎APIの基本と最新動向について @yusukey 資料：http://www.slideshare.net/yusukey/21twitter-api-api\n・検索APIについて http://search.twitter.com/search.json?q=*** %3Aは「:」 詳しくはリファレンスを買ってね。 ・ページ処理のベストプラクティス Pageじゃなくて、MaxIdを利用して取得すると１５００件以上のデータも取れるよ。 ・最近のTwitterAPIアップデートについて - ポケリファでの変更点 ストリーミングのエンドポイントがSSLのみに。（twitter4jは2.2.5以上） - ユーザ名が検索APIのスキーマに追加（１２月以降） - in_reply_toの追加（１２月以降） =\u0026gt;検索結果から会話を追える。 ・include_entitiesが追加 t.coの展開したリンクも取得可能。 けど、t.coリンクの飛び先はt.coリンクにしてね。パトロールとかしてるから。 ・本当にあった怖いt.co - URLのつもりじゃないのにリンクになる。 →仕様です - 日本語を含むURLがおかしくなる。 →少しずつ治ってきてる。 - リンク先のURLがわからない（クライアント依存） そのたいろいろ？ ◎Zusaarについて何か @knj77 資料：\n・特徴 - SNSアカウントでログイン トラブル抑制など - 事前決済可能。最小催行人数が決められて、払い戻しも可能。 ・利用例 旅行とか合宿に使う例がないんだけど、できるんじゃないかな？ ・イベントを依頼する機能 欲しいイベントを提案可能 http://www.zusaar.com/idea/ ・アーキテクチャ GAE/Java、Twitter4j、Yahoo APIのテキスト解析 ・SNS連携 TwitterのDMが送れない。他のSNSのアカウントが主催者とか。 なので、自分からDMが届く。 ・PayPal連携 小さいアプリほど相性がいい 固定費ゼロ、マイクロペイメント（１００円とか可能） 銀行口座の登録不要、返金可能。部分返金も可能。 ・トラブル - SNS側のエラーが適当 ステータスコードは信用できないｗ - PayPalの実装を３回変更 - GAE料金体系の変更 9$/month。追加料金はほとんど使ってない。Googleのアナウンスが下手。 - ブルーオーシャンのはずが... Q：Zusaarで返金できるポイントは？ A：主催者が主導（手動？）で返金可能。 Q：無料イベントで約束手形的に課金するのはできる？ A：やろうと思えば出来ます。ただ、システム的には１００円は手数料としてもらっている。 Q：新しいATNDに対抗意識はありますか？ A：ZusaarはCtoCをターゲットにしてる。ATNDはBtoCなので、補完できる関係だと思ってる。 Q：APIでTwitterIDとかで検索したいんですが。 A：対応予定あります。 Q：できればATNDのAPIと共通化してほしい。 A：追加してるだけのつもりです。 ◎グループに分かれて自己紹介 6人中、懇親会参加者が5人もいたｗ\n◎LT - OAuth Echoについて@tkawa 資料：http://www.slideshare.net/tkawa1/oauth-echo-20111221-10657954\ntwitpicで使ってる。 認証をServiceProviderに委譲する仕組み。 クライアントがOAuth登録してあれば、。。。 ・問題点 非公式仕様 OAuth1.0に基づいてて2.0では変わってそう。 ・Railsで実装してみたよ。 - GroovyとQuartzとTwitter4Jの甘い生活G @mike_neck 資料：\nベトナムから緊急来日らしい。 しかもむちゃぶりされたらしい。 - 認証なしで使えるAPIまとめ？@ts_3156 えごったーの作者で学生！\n- TDD (Twitter4J Driven Development) @sue445 資料：\nAZusaarの作者！ テストドリブンなはなし。 Twitter4Jを利用するときのTDDの簡単に実装できる仕組みの話。 ここにソースがあるのかな？ http:/github.com/sue445/twtrhack/ - 放射線を自動計測してTwitterにつぶやくimaocandeの紹介 @imaoca 松山の方。 とまぁ、APIの話だけでなく、実際にAPIを利用している方のサービスの話など色々と面白い話が聞けました。 厚かましくも懇親会にも参加して、そこでも今までのイベントとは違うクラスタの方たちの話が聞けたのが楽しかったです。 やはり、APIを利用して色々とやってみようと思っている方が多かったのでいつもと違う話が聞けたんですかね。 私自身はサービスを思いついたりしないタイプなので、いい刺激になりました。（まだ、特になにか作る気にはなってないですがｗ） ということで、次回も余力があれば参加したいなー。 ","date":1324485660,"dir":"post/2011/","id":"da67e2f049b5b6babcf7906b85653399","lang":"ja","lastmod":1324485660,"permalink":"https://blog.johtani.info/blog/2011/12/22/%E7%AC%AC2-1%E5%9B%9E-twitter-api-%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%9D%B1%E4%BA%AC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-22T01:41:00+09:00","summary":"@yusukeyさんにサインをもらう目的で勉強会に参加してきました。前回もらいそびれたのでｗ 残念ながら、まだTwitter APIを触ってない","tags":["勉強会"],"title":"第2.1回 Twitter API 勉強会 @東京に参加しました。(Jugemより移植)"},{"contents":"lucene-gosenの最新版（1.2.1）をリリースしました。\nプロジェクトページよりダウンロードが可能です。\n今回の修正では、特定文字列でメモリの使用量が爆発してしまうバグへの対処となっています。 1.2.1以前のバージョンを利用している場合は最新版を利用するようにしてください。\n","date":1324437339,"dir":"post/2011/","id":"584b2b145f362098fc5fc1e634d57de5","lang":"ja","lastmod":1324437339,"permalink":"https://blog.johtani.info/blog/2011/12/21/1-2-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-21T12:15:39+09:00","summary":"lucene-gosenの最新版（1.2.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、特定文字列で","tags":["lucene-gosen"],"title":"1.2.1リリースしました(Jugemより移植)"},{"contents":"いつものようにSolr勉強会に参加してきました。 皆勤賞を継続中です。（暇人というはなしも。。。） 今回は話しを聞きたいですねぇといったら、いやいや、話もしてくださいと言われてしまったので、 発表もしてきました。 発表資料はブログの最後に掲載してあります。\n日時：2011/12/19(月) 19:00～21:00 場所：Voyage Group 8階\n1.Fessについて N2SM菅谷さん 資料：http://www.slideshare.net/shinsuke/solr-fess\nマルチコアで構成されてる。 S2Robotでクロールしてますよ。 ※ごめんなさい、あまり聞けなかった。。。あとで資料を読んで質問します！ 2.lucene-gosenについて @johtani 発表しました。 3.ApacheConに参加しました @Ijokarumawak 資料：http://www.slideshare.net/KojiKawamura/apache-con-2011report\n日本-\u0026gt;カナダ-\u0026gt;ベルリン-\u0026gt;カナダ-\u0026gt;日本 50万円。。。 キーノート１： セキュアな開発について。 キーノート２： Hortonworksのコミュニティ運営大変だよねぇ、頑張るよという話。 キーノート３： 本題：Lucene 4.0の話：Simonさん ヨーロッパの方？ PostingsFormatの話。 Document内部の情報を使うためにどうする？ StoredField：あんまり効率よくないね。 FieldCache（on RAM）：インデックス作る動作の逆を行う。これも効率よくないね。 IndexDocValue：インデックス作成時に作られるので読み込み性能が１００倍！（DocValue） Document Writer Per Thread！ Automaton Query あいまい検索の処理に利用。 Solr Flair Solr同梱 Prism LucidImaginationが出してるJRubyのラッパー GitHubで公開されてるらしい。 Blacklight RoR 図書館むけのパッケージじゃなかったっけ？ VUFind PHP これも図書館向け？ TwigKit JSPのタグリブ おぉ。これ直接読んでるのかな？ Ajax Solr Ajax用 QA Q：TwigKit、Ajax Solrは直接Solrを呼んでるんですかね？ A：たぶん、そうですね。JSPのはSolrJかもしれないですが。 4.サフィックスアレイの話 @nobu_k 資料：http://www.slideshare.net/nobu_k/suffix-arraysolr\nSuffix Arrayの話 全文検索インデックスの話。 Suffix Array＝検索漏れがない。 Suffix＝接尾辞 RedBullがどの文書に入っているか！ SuffixArrayのメリット 検索漏れがない＝n-gramと同様 仕組み上n-gramよりも早くなるケースが多い。 長いクエリに対して速い THIS IS IT：全部ストップワード SuffixArrayのデメリット インデックス構築系 アルゴリズムが難しい。 メモリ上での構築はちょっとだけ楽（けど、簡単ではない） SAISなど。けど、これだとメモリがいっぱいないとキツイ HDDでの構築 ランダムアクセスを排除したアルゴリズムが必要（dc3,dc7） インデックス更新、差分更新できない。 頑張って１台100GB/day Sedueでは？ SA＆インメモリn-gramのハイブリッド 更新分はn-gramに 検索時にはn-gram＋SAの内容をマージして出力 検索 二分探索はHDDとは相性が悪い。 メモリ上で検索できればOKだけど、サイズが大きいからきびしい。 圧縮接尾辞配列なら可能だけど、低速。。。 SSDだとはやいよ！ SSD対応のクラウドはまだないけど。。。 Sedueでは最初の２０段でキャッシュしてる。 VSストップワード ストップワード込でインデックス作るみたい。 1.SAを二分探索 2.該当区間から出現位置をロード 3.出現位置をソート O(n)だけど、CPUのキャッシュミスが激しく影響 4.ソートした出現位置からヒット文書を求める。 同じくキャッシュミスがやばい ・実際にはmallocした領域のページフォルトが一番やばい SAが超活躍する場面 遺伝子の検索 n-gramとか死ぬ。形態素解析も無理。区切りがわからんｗ 5.P2P検索 ORBIS @ceeflyer 資料：http://www.slideshare.net/ceeflyer/p2p-search-engine-orbis\nORBISとは？ラテン語で「目」 ORBISとは？ リアルタイム検索エンジン 自律分散検索エンジン もともとはAmebaなうの検索のため ノード構成 比較的小規模（～１０００台）\u0026lt;=しょ、小規模ですか。すごいな。 Master-Slaveの差がなし MessagePack利用 フルメッシュネットワークを構築 インデックス フィールド： Content（形態素解析対象） Appendix（形態素解析しない） Flag（属性） ハッシュレプリケーションで登録。近いハッシュ値に登録（レプリカ数を指定できるのかな？） 単語に対して転置インデックスを一定数で固定 投稿日時が新しいものだけ検索するため。 検索： マージして結果を返す。 壊れてたら取れたものだけ返す。 QA： Q：ハッシュ値が大きくて１台しか選ばれないとかあるのでは？ A：ハッシュ値は循環しているという形で３台とか選ぶ。 Q：最大何台で稼働させてる？ A：現在はまだ５台程度 Q：障害時にレプリケーションの維持はするのか？ A：現時点はしてない。 Q；Cassandra、Lucendraとかあるけど、それをしなかった理由は？ A：単純にConfigurationができるから、１から作った。 今回はSolr以外の話も聞けたのがとても面白かったです。 やはり、Solr以外の検索エンジンについても知見があると、色々と比較の話しとかしやすいので。 それにしても、一からP2Pの検索エンジンを作っているのにはびっくりしました。 他にもSuffixArray（Sedue）の話も気になっていたのが少し氷解したし、海外旅行のノウハウがApacheConの話で聞けたしｗ やはり、発表をすると話しをしてもらえるのもあって、いい機会だなと再認識しました。 今回も紹介ネタだったので、ちゃんと事例とか測定したものも発表できるようにならねばと。。。\nということで、私の発表資料はこちらになります。疑問点とか質問事項とか、指摘事項など、コメントorTwitterで連絡いただけるとすごく嬉しいです。\n[Lucene gosenの紹介 solr勉強会第7回](http://www.slideshare.net/JunOhtani/lucene-gosen-solr7)** View more [presentations](http://www.slideshare.net/) from [Jun Ohtani](http://www.slideshare.net/JunOhtani) ","date":1324311660,"dir":"post/2011/","id":"c6696a730f7498efb66f5ba3a8b35d08","lang":"ja","lastmod":1324311660,"permalink":"https://blog.johtani.info/blog/2011/12/20/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC%EF%BC%97%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F%E7%99%BA%E8%A1%A8%E3%82%82%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-20T01:21:00+09:00","summary":"いつものようにSolr勉強会に参加してきました。 皆勤賞を継続中です。（暇人というはなしも。。。） 今回は話しを聞きたいですねぇといったら、いや","tags":["勉強会"],"title":"Solr勉強会第７回に参加しました。（発表もしました）(Jugemより移植)"},{"contents":"ということで、懲りずに#DSIRNLPに参加してきました。 基礎的な部分をおろそかにしたくないけど、TokyoNLPとかWebMiningではついていけないので。。。 今回もしがみつくのが精一杯かもしれないと思いつつ、聞いて来ました。\n0. DSIRNLPについて　@overlast 講演者が可能なら実装に関して言及する。 「こうやって作って結果を出す」系の発表をしましょう。 開催に際して協力してくださったみなさんへの感謝の辞。 1.自然言語処理はじめました　@phyllo 資料：http://www.slideshare.net/phyllo/ngram-10539181 ブログ：http://d.hatena.ne.jp/jetbead/20111210/1323499634 某Web企業の新入社員！（すごい） で、入って自然言語処理をはじめたらしい。 N-Gramの説明 Perl？ 1.ナイーブな方法 Perlでハッシュ使って数えてみたよ。これでOK？ いやいや、Nが大きくなったりデータが大きくなるとキツイでしょ 2.SuffixArrayを使う ということで、Suffix Arrayを使ってみた。 SuffixArrayのデータを作ってから、上からN文字数えれば数えられる！ （数式出てきたけど目も取れなかったｗ） これでいいじゃん？いやいや、更に大規模だとどーすんの。1TBのメモリ 3.近似カウント法 いくつかある中からLossy Countingを説明します。 ストリームデータから数えてみよう。 C++の実装？ 4.分散処理を使う方法 近似じゃダメ！正確な頻度が欲しい！ ＝＞Hadoopつかえ！ 色々やってみた感想が良かった。 SuffixArrayのメモリ使用量という話がありましたが、ディスクを使う方法もあります。 by ? 新人から自然言語やり始めたというが、自分が新人の頃にはこんなに出来なかった気がするなぁ。 発表とかもってのほかだったし。 2.AI で AI 創ってみた（LT）　@uchumik 資料： Luaプログラミングが出てきたので、 多クラスロジスティック回帰とListNetを書いて見ました。（ただし、本は読んでないよ。） 学習器のお話。 ラグナロクオンラインのAIがLuaでかけることを思い出した。 動画の途中で終了ｗ GitHubにあげなさい。ブログ書きなさい。動画もあげなさい。 by @overlast 資料の割に時間がｗ　2.5.CMコーナー 技評の方からWEB+DBのCM！（ただし、商品なし） 読者層の95%が男性ｗ 総集編買ってね！WEB+DB plusシリーズも買ってね！ 書いてor買ってね。 技評さんつぎはオライリーさんに負けないように賞品持ってきてねｗ 3.Mahout にパッチを送ってみた　@issay 資料：http://www.slideshare.net/issaymk2/mahout-10539755 人がやめていく会社で検索やHadoopやってます。 ※今日は皆既月食です。 機械学習関連 SGDはMapReduceでの分散に対応していないので、パッチを送ってみた。 MapReduce、Shuffleなどの説明 これをベースにナイーブベイズの説明をあわせて実装を見てみる。 ・単語ｗのカテゴリｃにおける確率 ・文書ｄのカテゴリｃにおける確率 -文書ｄに出てくる単語ｗの確率の積と定義 単語の相関を見ない。 ゼロ頻度問題の解説 文書頻度の逆数（IDF） カテゴリ毎の文書数のばらつきに対応するために、Complement Naive Bayes BayesFeatureDriver 次はランダムフォレスト 決定木とは？ ランダムフォレストとは？ ここでは素性。 Mahoutでの実装は？ 決定木の数だけ処理分散が可能。 Reducerは使ってない。＝Mapperで計算が終わっちゃうから？ 次はロジスティクス回帰 尤度関数、損失関数、確率的勾配降下法（SGD） 先程まではオンライン。バッチ学習もある。 Mahoutでの実装はオンラインで、MapReduceに向いてない！ Adaptive Logistic Regrettion（アダプティブロジスティクス回帰）というのも実装されてる。 送ったパッチの概要 Iterative Parameter Mixisngというのがあるので、それをSGDに適用するパッチ 今後 MapReduce以外も増えるかも。 Q:パッチがはいったバージョンはいつでる？A:3日前に送ったのでまだです Q:ナイーブベイズのMapReduceが一段ムダでは？（文書数のカウントは同時に出来るよね）A:そうですね、ぜひパッチを送ってみてください。 Q:Mahout、Hadoopの未来は明るいんでしょうか？A:HDFSのデータをMapReduce以外のフレームワークで使えるといい。 Q:Hadoopのパッチ送るの大変ですか？どのくらいかかりました？A:4,5ヶ月かかりました。 すみません、途中から頭がパンクしてしまいました。。。 ただ、MahoutがHadoopに乗っかってるからといって、MapReduce活用できてるわけじゃないという話がわかりました。 4.GraphDBのデータ構造　@kimuras 資料：http://www.slideshare.net/skimura/graphdatabase-data-structure LTみたいな資料にになっちゃいました。すみません。 mixiではMySQLだけど、いろんなDB触ってます。 なので、GraphDBに興味持ちました。 Luceneを教科書的に読んでます。 Neo4jモダンな作りでよかった。　http://www.slideshare.net/skimura/ss-8787632 ノードデータの構造 NodeManagerというのがいて、Cache系を管理してる。 プロパティのインデックス、トランザクションManagerもいて、PersistenceManager ここからNodeにアクセス（探索、）。 キャッシュとかいいね。 Soft LRU Cacheってのもあるよ。 その他色々ｗ Q:トランザクション周りでLRUのキャッシュはどうなるんでしょうか@kumagi A:きちんとロックしてました。 Q:分散はネットワーク、HDDどちらがキツイ？A:HDDがかなりきつい Q:プロパティもキャッシュに乗ってたほうがいい？A:プロパティも必要なら載せたほうがいい。メモリのしてはできたはず。 Luceneがほめられてました。Neo４Jの 5.冬のLock-free祭り　@kumagi 資料：https://docs.google.com/viewer?a=v\u0026amp;pid=explorer\u0026amp;chrome=true\u0026amp;srcid=0B72X9w6tG5q0NzMyODgwNDYtNjY4Yy00ZDgwLTliZDMtMjQwYmViMWE5NGU5\u0026amp;hl=en_US ※資料がうまく見れないのは、アニメーションガチガチって話だからかな？ http://twitter.com/#!/kumagi/status/145363169718697984 辻Lock-free活動してます。 Lock-freeとツイートすると補足されるらしい。 CPUの系譜のおさらい ポラックの系譜 最新のIntelManyCoreとか東大とかに配られてるらしい。 なんで、マルチコアのCPUがTSUKUMOとかで売ってないの？ 僕らが使いこなせてないから。＝マルチスレッドの対応がうまくできてないから。 CAS＝Compare And Swap まずは、Lock-free stack ABA問題？ Lock-free Queue QueueのEnqueueの場合は2回のCASが必要になる。 不変条件を守る。ロックだと守りやすい。 2回のCAS処理の間が危険領域 Lock-free List 色々なロックの説明。 Lock-free hash map これも気が狂ってるアルゴリズム？ ConcurrentHashMapなども話が出てきたが、説明しない＝Lock-freeじゃないからｗ Lock-free SkipList SkipList： 順序関係のあるデータをO(log n)で検索・挿入・削除ができるデータ構造（2分木ともろかぶり） DougLea先生がjava.util.concurrentに入っています。 Lock-free Btree 論文ないんですよ。簡単すぎて。 SoftwareTransactionalMemory The Art of Multiprocessor Programmingを読みましょう！ 論文のお話。 http://labs.gree.jp/Top/OpenSource/Flare.html を利用しているらしい。 The Art of Multiprocessor Programming関連サイト http://www.cs.brown.edu/courses/cs176/lectures.shtml すごくわかりやすかった。資料をもっと見たいなぁ。 Q:STMはメモリ使用量が2倍になる？A: Q:STM（Clojure）使ってみたけど残念な性能しか出なかったけど、なんで？A:Clojureのものはロックベース。でうーむ。。。 6.機械学習と最適化の基礎（仮）　@tkng PFIの徳永さん 日本語入力を支える技術（技評）2012年2月発売予定 最適化の話、機械学習の話、学習率の話。 大域的最適、局所的最適の説明。（言いにくそう、大域的最適ｗ） 凸最適化問題＝最適解が1つしかない？ 大域的最適解＝局所的最適解 機械学習なはなし。 スパムメールの例で説明 淡々と語られてましたが、わかりやすい説明でした。もっと昔にこんな形で数学の説明聞きたかった。。。 7.機械学習・言語処理技術を用いた誤り検出・訂正（LT）　@mamoruk 資料： スペル誤り訂正とかに機械学習とか使われてます。 8.神の言語による自然言語処理（LT）　@AntiBayes 資料：http://www.slideshare.net/AntiBayesian/ss-10539347# Lispさいこー Clojureさいこー lucene-gosenもいいよーｗ 9.言語判定へのいざない（LT）　@shuyo 資料： Solrで採用されたlanguage-detection libraryの紹介。 アゼルバイジャン語とか大変みたい。 12.作ろう！簡潔ビットベクトル　@echizen_tm 資料：http://www.scribd.com/doc/73565169/Lets-Impl-Sbv 入門編： 簡潔データ構造 データサイズをほぼ情報量的下限にまで小さくしたデータ構造 データは小さいし、速度速いというのがこれ。 実用化されてる。 mozc（LOUDSが使われてます） Sedue（圧縮接尾辞配列（デフォルトではなくなった by @tkng）） 種類： ビット列：ここの説明がこのあと 木構造：トライ木をLOUDSが結構で実装するケースが多い。データサイズが小さくなる 文字列：ウェーブレット木が有名。全文検索、転置インデックスにウェーブレット木を使う研究が多い。 中級編 簡潔ビットベクトル： rank(i)関数：i番目より前の立っているビットの数。 疎なデータ列の効率的な実装に使える。検索結果が少ない場合のFacetとかに使える？ select(i)関数：？ 可変長データ列の効率的な実装 上級編 ダメでした。。。ごめんなさい。。。 体力的に厳しかったです。。。けど面白いし、わかりやすい。どういった所でこれらを使うべきかを取捨選択するのがすこし難しそうです。Luceneとかの内部ソース見ると実はこのあたりで実装されてる部分があったりするのかも。 11.類似文字列検索の仕組み　@overlast 資料： 使い所のはなし 例：辞書メンテナンスコストを軽減したい 架空の事例から類似検索を適用できるというストーリー 既存データが活用されるうれしさの例？ Apporoのデータ構造とかの話かな？ 11.5.審査委員長から賞品持って帰る人の発表 @kumagi @tkng @echizen_tm の方たちでしたー 12.懇親会 いやぁ、前回も感じましたが、基礎ができてないなぁと実感できた勉強会です。 そして幅も広い。やはり、数学的な要素が時々出てくるのでその部分をもっと身につけないといけないなぁと。。。 ついていけなかったところも多々ありましたが、頭の中にキーワードが入ってればなんとかなるかなぁと。 Neo4jやLuceneのソースコードリーディングをやるのが仕事に役立ちそうなので、少しずつでもやろう。 これから懇親会なので、とりあえず、このへんで。 あとで、見返しながら、リンク貼り直したりすると思います。\n","date":1323529475,"dir":"post/2011/","id":"16fa0e4aefe18e1446bf6baefd3ba400","lang":"ja","lastmod":1323529475,"permalink":"https://blog.johtani.info/blog/2011/12/11/%E7%AC%AC2%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-11T00:04:35+09:00","summary":"ということで、懲りずに#DSIRNLPに参加してきました。 基礎的な部分をおろそかにしたくないけど、TokyoNLPとかWebMiningでは","tags":[],"title":"第2回 データ構造と情報検索と言語処理勉強会に参加しました(Jugemより移植)"},{"contents":"ひさびさに、MBAのお話です。 セットアップといっても、物理的な方ですね。 以前、ケース（カバー）について記載しました。 この記事にも書いてあったのですが、付属の滑り止めが簡易なシールで、カバンの中から出し入れすると剥がれるは、作業をしてるとずれるわで、悩んでいました。 今日、たまたま、東急ハンズに行くことがあったので、店員さんに相談してすべり止め対策のグッズを購入しました。 相談した所、カバーは傷がつきにくくなるような素材ですから、シールもつきにくいとのこと。（言われてみればそりゃそうか。） 対策としては紙ヤスリで傷つけたところに薄手のシールゴムをつければはがれにくくなりますよとのこと。 ということで、やってみました。まぁ、ゴムにホコリはつくかもしれませんが、今のところ滑らず快適！ いやぁ、ハンズの店員さんすごいですわ。 MBAについてはこんなとこです。最近また、出先に行っていてMBA使えないので、ブログを書くかメールにしか使ってないです。。。\nで、もう一つはMac Mini（2009 late：Core2Duo 2.26GHz、メモリ4G、HDD250G）です。 前職の同期から安く譲ってもらいました。音声が出力されないという問題点があるとFacebookでつぶやいているのをみて、興味を持ったらゲット出来ましたｗ で、セットアップをしたのです。 大変でした。まずつまずいたのが、キーボードとマウスでした。 これまで使っていたデスクトップのキーボードがあるのですが、これがPS/2ということで使えません。（軽いジャブ） MBAのキー配列にも慣れてきていたので、ビックカメラで悩みながらもApple純正のワイヤレスキーボードとまじっくトラックパッドを購入。 で、まずは、付属のLeopardで初期化。 このときは、ワイヤレスキーボードは認識したのですが、マジックトラックパッドはこの時代に無かったらしく、反応せず（さらに軽いジャブ） さすがに前のPCのマウスはUSBだったので、これを利用してセットアップ再開 次にSnow Leopard（これもつけてくれた）にアップグレードして最後にLionです。 Snow Leopardでソフトウェアアップデートしたところでようやくトラックパッドが認識できたと。 で、やっと使い始めたのですが、MBA（2011）に慣れていたので、思いの外もっさりした動きをしているMacMiniに 戸惑ってます。（トドメのストレート。現在ここ） ということで、どうやれば快適に使えるかアイデア募集中です。 とりあえず、Lionの設定のウィンドウ復元機能やアニメーションをオフにするなど対策してます。 HDDのSSD化とかメモリ増設とか考えないとダメかなぁ。 あと、ついでにBootcampも興味があるので、せっかくだから実験する予定です。 Windowsが前のデスクトップより快適に使えるようになるなら、Windowsマシンとするのもありかなぁと。。。\nセットアップ系はこのへんで。 あとは、最近興味が有ること2点です。（技術系ではありません） 1つ目は最近発売されたゼルダ。夜な夜なやってます。 もともとゲーム好きでゼルダも欠かさずやってきてますが、ゼルダらしさを残しつつ新しい要素やアクションも取り入れとなかなか楽しいです。 ただ、Wii全般に言えることですが難しい！まぁ、楽しんでますけどね 2つ目は前からつぶやいてるのですが、電子書籍を読むためのタブレットがすごく気になってます。 最初は財布に優しく、MBAを普段持ち歩いてるのもあるから、LenovoのA1（7インチ）で決まりだと思っていたのですが、技術書を読むのは少しキツイかもという印象。 どうしてもオライリー本などの大きめのサイズになるため、7インチの画面でPDFを表示したところ、字が小さくなってしまい拡大しないと見づらいのです。 ただ、拡大してしまうと今度はパッと見るという一覧性が下がってしまいます。。。 少々重くなってもいいので10インチにしたほうがいいのかな、けど、電車で立って読むの辛いかもなどなど考えているところで最終的な決断ができない次第です。。。 最初は毛嫌いしていたiPad2もいいかもと思う始末で困ってるとこです。 安い中華パッド（2万ちょっと）に手を出すか、7インチで我慢するか、Galaxy Tab 10.1のWifi版を輸入業者から購入するかと悩んでるところ。 ただ、長く使うのを考えると、OSのバージョンアップなどを保証してくれるiPad2が実はいいじゃないかなぁなど。 皆さんからしてみればくだらないなぁと思われるかもしれないけどずーっと悩んでつぶやいたりしております。 はぁ、こまった。（そもそもそんなにスペックいらないんじゃないかというのもあるからなぁ。メインはPDF読むことだから。） ゼルダの伝説 スカイウォードソード (期間限定生産 スペシャルCD同梱) ","date":1322668828,"dir":"post/2011/","id":"6e970d0818d58ff2d50c5bf037b1a565","lang":"ja","lastmod":1322668828,"permalink":"https://blog.johtani.info/blog/2011/12/01/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%95%E3%81%A8mac-mini2009late%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E3%81%A8%E3%81%9D%E3%81%AE%E4%BB%96%E3%81%8F%E3%81%A0%E3%82%89%E3%81%AA%E3%81%84%E8%A9%B1/","publishdate":"2011-12-01T01:00:28+09:00","summary":"ひさびさに、MBAのお話です。 セットアップといっても、物理的な方ですね。 以前、ケース（カバー）について記載しました。 この記事にも書いてあった","tags":["備忘録"],"title":"MBAセットアップ備忘録その５とMac Mini（2009late）セットアップとその他くだらない話(Jugemより移植)"},{"contents":" どんな本でも大量に読める「速読」の本 Twitterで知り合った方がこの本について書かれていたブログ記事を読んで興味を持ち、読みました。 書籍（特に技術書）が山になっていたこともあり、速読に興味を持っていたところちょうど記事を目にしたのは きっと何かのタイミングなんだろうなと。\n悪い癖で、電車で読もうと本を常に持ち歩くのですが、ついついスマートフォンやゲームで遊んでしまい、今回も読むのに時間がかかってしまいました。 ３章の途中までを今月頭に読んでいたのですが、そこから少しほったらかしで、読み終わったのが昨日でした。\n本の内容ですが、先ほどのブログにも書かれていますが、速読は技術ではない。 ### 速読　＝　速読技術　X　ストック（知識、経験、情報） であると。あとは、わからなくてもいいから、ざっと目を通す感じで繰り返し読みなさいと。 さらに、１回でわからんくてもいいから、とにかく繰り返し読むことが重要だということでした。\n確かに「速読＝１回で速く読む」、「読書＝１回で理解する」という意識がどこかにあったなぁと気付かされました。 プログラム組んだり、あることを覚えるときは繰り返しを意識してたのに、読書は１回読んで「はい、おしまい。」という気になってました。（マンガは繰り返し読むんですけどねぇ）\n他の速読の本は胡散臭いし、絶対無理だよなぁと思ってたのですが、この本に書かれている話は筋が通っているように感じました。 ただ、考えずにサラサラ読みなさいという部分の実践はなかなか難しいかな。どうしても頭の中で音読してしまうので。 私は間を開けてしまったせいで、時間がかかってしまいましたが普通なら１日あれば読める内容なので速読に関してちょっとと思ってる方は読んでみると面白いかと思います。\nちょっとだけショックだったのは、この本の論理だと電子書籍は速読に向いていないというところです。 せっかく溜まった書籍をPDF化して、タブレット購入して（まだ買ってない。。。）読もうと思っていたところなのに。。。\n","date":1322542620,"dir":"post/2011/","id":"0ebe78077c8b48410cf52a0bccdff866","lang":"ja","lastmod":1322542620,"permalink":"https://blog.johtani.info/blog/2011/11/29/%E3%81%A9%E3%82%93%E3%81%AA%E6%9C%AC%E3%81%A7%E3%82%82%E5%A4%A7%E9%87%8F%E3%81%AB%E8%AA%AD%E3%82%81%E3%82%8B%E9%80%9F%E8%AA%AD%E3%81%AE%E6%9C%AC%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-29T13:57:00+09:00","summary":"どんな本でも大量に読める「速読」の本 Twitterで知り合った方がこの本について書かれていたブログ記事を読んで興味を持ち、読みました。 書籍（","tags":["読書"],"title":"「どんな本でも大量に読める「速読」の本」を読みました(Jugemより移植)"},{"contents":"Hadoopソースコードリーディング第7回に参加しました。 いつものごとく、自分用のメモをとっていたので。 第6回（2010/12）には参加してたのですが、あれからそういえば、話が無いなぁと思っていたところに 再開するという話がTwitterに流れてきたので、即申し込みしました。 思い返せば、Hadoopに興味をもって少し触っているところで参加したのだったなぁと感慨深い思いを思い出しました。\n今回は場所を変えて豊洲のNTTデータさんで開催されました。\n日時：2011/11/28（月）19:00～22:00 場所：豊洲センタービルアネックス NTTデータ\n◎アジェンダ＋導入（NTTデータ 濱野さん） ちょっと間が空きましたが隔月で行う予定。 2012/01/12くらいに次回を予定。ネタ募集中。 ◎Hadoop World NYC 2011 参加レポート - NTTデータ 下垣 徹さん （Hadoop徹底入門著者の一人です！） ・イベント概要：2011/11/08～09にNYで開催 スポンサー企業の数がどんどん大きくなってる。 ・会場の様子 最初のキーノートは立ち見が出るほど。 個別に5並列でセッションが開催されてましたと。 ・キーノート紹介 1.Hadoop World（Michael Olson） アンケートからの概観 HadoopはNext Generation DataCenterだそうで。 2.JP Morgan（Larry Feinsmith） コスト削減＋収入増加のためにHadoopつかうぞと。 BigData分析の戦略 ユースケース１：ETL（Extract/Transfer/Load）ツールとして ユースケース２：共通データ基盤 検索頻度が低いデータの低コストストレージなどなど。 ユースケース３：データマイニング 異常値検出とか。 3.eBay（E. Williams） Cassini：オークション情報の検索エンジン 柔軟な検索＋協力なランキング機能 Hadoopで転置インデックス作成＝Luceneは使ってるってことかな？ HBaseも利用。データはHBaseに登録してる。 4.Informatica（James Markarian） データとプロセス Hadoopが賑わうからRDBMSも活気づく Hadoopはプラットフォームになるよと 5.Cloudera（Doug Cutting） Hadoopの背景と今後について BigDataを分散処理するためのカーネルになりつつあるよと。 Apacheプロジェクトの良さ 類似するプロジェクトも共存させてるよと。 Hadoopの今とこれから（0.20（今）、0.23（将来）） 0.23はHDFSの性能面改善、スケーラビリティの強化、HA MapReduce2.0 CDH4のはなし。 Hadoopコミュニティはまだまだ若い ・HadoopWorldの傾向 HBaseの利用増加 利用理由？ 小さいレコードにも強い。 ランダムアクセス 大手ベンダ参加 Oracleすげー。Hadoopの周りを固めていくぞと。 Hadoopの周りを各社がどう固めていくかというはなし。 事例が多い WibiData：HBaseの利用事例。Fonedoctor Walt Disney：Big Dataに対する機会損失があるから、導入するよと。 テーマパークの交通流解析にも使うぞ！ イケメンによる来年（2012年）のHadoop Worldの動向！？ 参加者3000人！ ラスベガスで開催？ スポンサー拡大で食事が美味しく！？ 全方位戦略vs.特化型 BIツールベンダの巻き込み 利用事例のアピール合戦 HBaseの利用事例が続々！（Salesforce.comあたりがセッション持つんじゃね？） Hadoop対抗アプリケーション、業界特化型キラーアプリケーションがますます増える？ Mahout事例の増加 データマイニング＋Web勉強会 - NTTデータ 政谷さんのHadoopNYでの発表のダイジェスト まずは印象。深く使っている人は去年より減っている。バズワードになってるからかな？ 今後もHadoopコミュニティは健全なコミュニティになりそう。（いろんな所が出てきたけど、大丈夫そうだなぁ） ・発表スライドのダイジェスト版 日本でのHadoopの盛り上がりの話。 Hadoopと他との住み分けの話。 Sqoopのお話。PostgreSQLに向けたインテグレーションの話。これはPostしてコミット待ち。 Low-Latency Serving Systemへの受け渡し（前処理はHadoopでGPGPU使ってデータをクラスタリングして処理速度をあげる） FujitsuのETERNUSにHDFS APIが用意されたという話。 MapRの話に似ているよと。小さめのクラスタの場合に有効？セッションの後に少し話題になった。 扇子を配りましたよと。 ※ビールが配られ始めた！（ビールじゃないという声もチラホラｗ） ◎『Hadoop Troubleshooting 101』 セッションレポート - Cloudera 嶋内さん （@shiumachi） Hadoopを壊す7つの方法 Hadoop設定したりしたことある人？＝結構いた。さすがソースコードリーディング Clouderaでは木曜日に重要なミーティング（ボードゲームするかFPSするか）というのがあるらしい。 チケット分析 設定ミス？ HadoopやOSの設定ファイルの変更を必要とするあらゆるチケットの事 35%が該当 問題の原因別のグラフ 1番は設定ミス 2番はバグ（これはベータ版リリースからチケット管理してるから） メモリの管理ミス Task Out Of Memory Error io.sort.mb \u0026lt; mapred.child.java.optsとなるように設定すること io.sort.mb = mapバッファのサイズ mapperとreducerを減らす。 mapper＝ノード上のコア数 これは机にはっとけ！ Total RAM = (Mappers + Reducers) * Child Task Heap + DN heap + 3GB + RS heap + ？ JobTracker Out Of Memory Error JTのメモリ使用量の合計　＞　割り当てRAM 原因は？ タスクが小さすぎ jobヒストリが多すぎ 解決は？ maximumを減らしなさい？ Unable to Create New Native Thread どういう意味？ プロセスが起動中にもかかわらずDNが障害ノードとして表示されている。 原因は？ nprocのデフォルト値が低すぎる 対応は？ /etc/seurity/limits.confの値を考えろ Too Many Fetch-Failures 元スライドの発表者はこれが大好きらしい どういう意味？ Reducerのfetch操作がmapperの出力の取得に失敗 ブラックリスト入りのTTで発生するらしい 原因は？ DNSの問題 対応は？ mapred.reduce.slowstart.completed.maps = 0.80 reducerの開始を遅らせることで対応 tasktracker.http.threads = 80 Jetty 6.1.26は使うな！CDH3u2に上げましょう。 Not Able to Place Enough Replicas 。。。きっとどっかにスライドあるからメモはこのへんでいいか。。。 ◎Hadoop World NYC 2011 参加レポート - Acroquest Technology 阪本 雄一郎さん （@frutescens） 落合 雄介さん （@taro_x） ・RとHadoopの融合（Revolution AnalyticsのDavid Champagneさん） R言語の紹介 Rとの接続点（rmr、rhdfs、？） R言語の利点がHadoopで使えるから、記述が少なくて済むよと。 統計処理がわからなくてもRが使えると分析ができるよ。（そう言われても、その分析で正しいのかとかは結局統計とかをある程度理解してないと厳しいんじゃないか？） ・Hadoopを使った衛星画像解析 スケールとかしたいからHadoopにしたけど、ジョブ起動遅いし、科学計算ライブラリが不十分 ・Hadoopをクラウド上に展開（vmware） Hadoopだけじゃなく、NoSQLとかもスケールしてから使いたいよねぇ。 ということで、vmwareの色々なものを使ってHadoopと他をうまく構築しますよ事例紹介。 マルチテナントのHadoopの話とかもありますよねと。 ◎最後はHadoopには関係ないのが多かったけどおみやげ争奪戦。 なぜか、MongoDBのシールをもらいました。 ということで、HadoopWorld2011の総括＋各スライドの紹介でした。 これまでのHadoopWorldの傾向などから、参加者などのトレンドがどうなっているかなどの話が聞けたのが面白かったです。 ClouderaのスライドはHadoopのトラブルシューティングとして必見になりそうな感じでした。 内容が濃くて、それほど触っていない私にはわからないところもチラホラ。（日本語資料の公開されるかなぁ？） 案の定、ビール（発泡酒）を飲んだので、途中から一部が飲み会状態になってたし、ピザ食べてたので、私のメモも途中から適当になってしまいました。 あとは、とある件についていろんなかたからの知見を入手できたのが良かったですね。 他にもLilyプロジェクト（Solrが利用されているOSSの話）の話もあったようなのですが（HPの方が教えてくれました）、今回の参加レポートでは含まれてなかったです。（話聞きたかったなぁ。余力があれば、スライド読むかなぁ。誰か発表してくれないかなぁ） 今日もまた、Twitterで絡んでいた方たち数人と面識が得られました。 今後は定期開催の流れになるようなので、これからもHadoopにしがみついていくためにも参加するようにがんばりますよと。\n会場提供のNTTデータのみなさん、発表者の皆さんお疲れ様でした。次回も期待してます！！\n2011/12/01追記 Togetterのまとめ\n","date":1322499060,"dir":"post/2011/","id":"924727b6f380cf3cdfe5650163e92054","lang":"ja","lastmod":1322499060,"permalink":"https://blog.johtani.info/blog/2011/11/29/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC7%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-29T01:51:00+09:00","summary":"Hadoopソースコードリーディング第7回に参加しました。 いつものごとく、自分用のメモをとっていたので。 第6回（2010/12）には参加して","tags":["勉強会"],"title":"Hadoopソースコードリーディング第7回に参加しました。(Jugemより移植)"},{"contents":"先週末から勤労感謝の日まで風邪で寝こんでました。。。 みなさん、朝晩、冷え込みが激しいので風邪には気をつけてください。\n季節の言葉も入れたので本題です。 つい最近、「Apache Solr入門」のサンプルをlucene-gosenでどうやって動かすんですかー？という質問を受けました。 確かに、「Apache Solr入門」を書いたのはSolrのバージョンが1.4が出る直前でしたし、lucene-gosenは存在せず、 当時はSenを元にした日本語の形態素解析のサンプルとなっていました。 そのSenも入手しづらくなってきており、私もlucene-gosenのプロジェクトに携わるようになってきてある程度時間が 経ちました。 せっかくなので、サンプルのschema.xmlだけでも最新版（Solr 3.4 + lucene-gosen-1.2.0-ipadic）のものを用意しました。 なお、あくまでも、3.xでlucene-gosenを利用する場合の「Apache Solr入門」のサンプルプログラムの変更点（とりあえず、4章まで）の違いについて記述します。 申し訳ございませんが、1.4と3.xの違いについての説明はここでは行いません。\n以下では、各章でschema.xmlに関連する記載のある部分を抜粋して、変更点と変更したschema.xmlのリンクを用意しました。参考にしてもらえればと思います。\n1章 1.6.1 N-gram（17ページ） 1.6.1の手順に変更はありません。 サンプルプログラムが入っているZip「solrbook.zip」のintroduction/ngram/schema.xmlファイルの代わりに こちらのschema.xmlを利用してください。\n1.6.2 形態素解析（18ページ～20ページ中盤まで） 手順が大きく変わります。 Senを利用する場合、Senの辞書のビルド、Senのjarファイルの配置、Senを利用するためのTokenizerクラスを含んだサンプルjarの配置という作業があります。 lucene-gosenではコンパイル済みの辞書がjarファイルに含まれています。 また、Solr向けのTokenizerもlucene-gosenのjarファイルに含まれています。 lucene-gosenを利用して形態素解析を体験するための手順は次の流れになります。 なお、schema.xmlについては上記N-gramでダウンロードしたschema.xmlに形態素解析の設定もあわせて記載してあります。\njarファイル（lucene-gosen-1.2.0-ipadic.jar）をダウンロードして、$SOLR/example/solr/lib（libディレクトリがない場合は作成）にコピーします。 コピーが終わりましたら、次のように$SOLR/exampleディレクトリでSolrを起動します。 （-Dsen.homeは必要なし）\n$ java -jar start.jar あとは、書籍の記述にしたがって管理画面のAnalysis画面で動作を確認します。 ほぼ、図1-6と同じ結果になっていると思います。 （lucene-gosenで出力される情報には本書のサンプルよりも多くの情報が含まれています。また、サンプルでは、形態素解析の後の単語に基本形を採用しているため、「な」が「だ」として出力されています。基本形を出力する場合は後述するこちらで紹介したTokenFilterを利用すれば可能です。）\n2章 2.1.3 schema.xmlのバージョン（27ページ） Solr3.xではschema.xmlのファイルの最新バージョンは1.4になっています。\n2.2.3 代表的なトークナイザ（35ページ） solrbook.analysis.SenTokenizerFactoryは必要ありません。 先ほども説明しましたが、lucene-gosenにはSolr向けのトークナイザが用意されています。 solr.JapaneseTokenizerFactoryがそれに該当します。\n2.2.4 代表的なトークンフィルタ（37ページ） 以下の2つについてはlucene-gosenに同等のトークンフィルタが存在します。\nsolrbook.analysis.KatakanaStemFilterFactory solrbook.analysis.POSFilterFactory それぞれ、次のものがlucene-gosenにあるので、こちらを利用します。\nsolr.JapaneseKatakanaStemFilterFactory solr.JapanesePartOfSpeechStopFilterFactory 2章向けのschema.xmlはこちらです。その他のtxtファイルについては、特に変更はありません。\n3,4章は特に変更はありません。Solrの起動の仕方にだけ注意してください。（-Dsen.homeは必要ありません）\n以上が4章までの修正点になります。 動作しないなどあれば、コメントください。 サンプルアプリについてはまた後日余裕があれば。。。\n","date":1322244000,"dir":"post/2011/","id":"26d48d68b28f927bfebad454658f9425","lang":"ja","lastmod":1322244000,"permalink":"https://blog.johtani.info/blog/2011/11/26/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AElucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0%E3%81%8B%E3%82%894%E7%AB%A0/","publishdate":"2011-11-26T03:00:00+09:00","summary":"先週末から勤労感謝の日まで風邪で寝こんでました。。。 みなさん、朝晩、冷え込みが激しいので風邪には気をつけてください。 季節の言葉も入れたので本","tags":["lucene-gosen"],"title":"「Apache Solr入門」のサンプルのlucene-gosen対応（1章から4章）(Jugemより移植)"},{"contents":"今回は、触ろうと思って触れていないMongoDBの勉強会に行って来ました。 2週連続の渋谷で、さすがに今回は出口をすんなりでれました。 今回は初のGMOさんのビルへの潜入です。 ということで、いつものごとく自分のメモを残しておきます。\n日時 :2011/11/15 14:30 to 20:00 定員 :140 人 会場 :GMO Yours （セルリアンタワー（11階）） ハッシュタグ :#mongotokyo\n1.fluentd plugins for MongoDB @doryokujin スライドはこちら。\nFluentとMongoDBのコラボレーション ・Fluentとは？ 解析対象のログについて。データ量が膨大 これまでのログの扱い方。日次でS3に送信して、ログ解析サーバにて前日分を解析する。 これではリアルタイム性がないのが問題！しかも1日分なので、データ量が半端ない。 そこでFluentにてストリーミングアプローチ。 リレーサーバ（Fluentd）にログを流すと、適宜、解析サーバに流れていく仕組みが可能。 これにより、ネットワークに負荷をあまりかけずにログを定期的（時次とか）で流せる。 ※splunkに近い考えかな。 ここで、Fluentのスライドで説明が入りました。http://www.scribd.com/doc/70897187/Fluent-event-collector-update ・Out Mongo For Local Back-Up MongoDBへの出力。 信頼性をあげるためにローカルにmongoDBを置いておき、スプールしておく。 リレーサーバにも配置してみるという仕組み。 バッファリングにMongoDBを使うので Aggregation Mongoってのを作ったらしい。そのせいで、スライドの作成が遅れたらしいw ・Aggregation Mongo Map/Reduceの集約のようなプラグイン。 fluentdのアプリを通して、特定のキーをベースに集計してから、outputする仕組み。 更に、キーに対してshufleが行われて、次のfluentdにデータが集まる。　fluentdを使ってM/Rっぽいことが可能なのかな。 QA 最終的な流れ込み先のMongoDBはCappedCollectionじゃなくしたほうがいい。検索とかしたくなるから。 2.about Server Density and MongoDB @davidmytton スライドはこちら\nQueuingシステムで利用。 MongoDBとRabbitMQとの比較？ MongoDB関連のノウハウかな。 データ量に関する話。メモリに載せたほうがいいのかとか、ログ出力の設定とか、ジャーナルとか。 HDDの見積もりに関連しそう。 健康状態の監視方法。 コネクションプールの話とか。 rs＝ReplicaSet？ mongostatってコマンドがあるのか。 ServerDensityのツールとダッシュボードなどについて。 ※英語のスライド見ながら話聞くとメモがとれない。　まとめ： Keep it in Ram インデックスはメモリに載せましょう。 Watch your Strage ストレージのサイズは監視しましょう。（ログ、データ、ジャーナルなどなど） db.serverStatus()　コマンドあるよ。これで見れるデータが重要なのかな？ rs.stats()　コマンドあるよ。これで見れるデータが重要なのかな？ QA：残念ながら聞き取れなかったっすｗ Q：MongoDBのクエリログの統計の質問。DBごと？＝コレクションごと？のクエリ統計のとり方は？ A：MongoDBにはないので、ログレベルを下げて統計取ったりする方法しかないかなぁ。 3.MongoDB: Case Study for AMN @koyhoge スライドはこちら\nサービス（アジャイルメディア・ネットワーク）で利用している実例について 広告配信に関連して利用してる。 最初にPostgreSQLにて実装。5分おきにCronで再起動するはめに。。。 PostgreSQLの次にSimpleDBへ（インサートが遅い。分散インサート） SimpleDB＋SQSに変更。1日130$で断念。 SaaSなKVSはやめてMongoDBに移行してみる。 負荷も軽いし、インサートも速い！ EC2でMongoDB。しかもレプリカを東京A、B、シンガポールAにしてみよう。 shardingは残念ながらうまく行かず。 ストレージはEBSの1TB 4.「MongoDBとHadoopの蜜月関係」 @muddydixon スライドはこちら\nお父さんエンジニアなので、土曜日の勉強会は無理です！＝同じく辛いです！ HadoopとMongoDBのつなぎについて。 MongoDBからデータを読み込んで、Hadoopで計算してMongoDBに戻すものがmongo-hadoop データロストがニュースになってて心配してる。データロストはめったにない（by @doryokujin） Hadoopを計算だけに利用できるのでクラスタが落ちても気にせず立ち上げができそう。 MongoDBからデータを取得する時点でフィルタリングが可能なので、Hadoopでの演算が楽。 AdHocなクエリをMongoDBに投げれるのがうれしいのかな？ HBaseとかHiveに入れてやったりはダメなんかな？ QA Q：なんで、みんなMongoDBにログ入れるの？@kzk_mover A：様々な形式を入れやすいから。 Q：捨てるのどーするの？ A：コンパクションが大変（ただし、2.0以降は良くなる予定） Q：MongoDBのMap/Reduceは？ A：時間がかかった上に死ぬというひどい目にあったので。。。 5.Fusion-io @hasegaw\n340の仮想マシンが4台で動きます！ すごそう。。。一回は触ってみたいかも。 Fusion-ioすげーーーって感じ。（Ustストップ） 6.MongoDB on Cloud Foundry @yssk22\nVMWare社のPaaSオファリングの名称 感想など： mongoDBに興味はあるのに、腰が引けてるおじさんになって結局触らずに会場入りしてしまいました。 会場に入っていきなり、Treasure Dataの太田さんがマグカップを売っているという場面に遭遇するというインパクトがあるスタート。（思わず1個購入） 最初はMongoDB JPの主催者でもある@doryokujinさんの話から。今熱いfluentdとmongoDBの組み合わせに関する話で、面白かったです。 途中でfluentdを作っている古橋さんのスライドを用いてfluentdの解説まで入りました。 TL上では、その古橋さんが時々フォローを入れているという贅沢な流れ。 なんとなく仕組みはスライドなどを見ていたのですが、更に理解が深まりました。 次が、イギリスから来日されていた@davidmyttonさん（なんと24歳という若さ！）のお話。 残念ながら英語のヒアリングは微妙な私なので、あまり理解できなかったのですが、どうやら、MongoDBの運用でのTipsのお話だったようです。スライドを後で見なおしたほうがいいかな。 次は、実際のMongoDBを利用した事例の紹介。PostgreSQLから試行錯誤してMongoDB＋AWSの組み合わせのお話。 やはり実例があると面白いですね。試行錯誤された部分があるので、非常にわかりやすかったです。 次が、HadoopとMongoDBの組み合わせのお話。HadoopのMap/Reduceの部分だけを利用して、データ保存先はMongoDBにしましょうという割りきった話でした。 いくつか疑問点がメモにもありますが、残念ながら質問する勇気なしという腰抜けっぷり（もうちょっと積極的にならないと。。。） で、このあとFusion-ioとCloud Foundryの話になるのですが、体力切れ＋lucene-gosenのjavadocが古いことに気づいてしまい、作業をしながら聞いていたのであまり頭に残っていません。（ほんとに申し訳ない。。。） とまぁ、最近、Twitter上でいろんな人に絡みまくってまして、@doryokujinにも絡みまくってたというのもあり、今回参加することにしたという次第でした。 懇親会にも多くの人が残っており、良いコミュニティができてるなぁというのが正直な感想です。 各セッションでも@doryokujinさんが適宜QAなどのフォローをされていて感心しっぱなしでした。 あとは、Twitter上で会話をしていた方たちとも顔合わせができたので、大収穫でした。\n次は、少しでもいいので、触ってから参加することにしようかと思います。 来年1月にはMongo Tokyo 2012というイベントも開かれるようで、ますます注目を浴びていきそうですね。主催者もミドルウェアもｗ\nあ、そうそう、そんなMongoDBの勉強会でしたが、CouchDBの話もちらほら出てまして、CouchConf TOKYOというチラシも@Ijokarumawakさんから頂きました。こちらも1月開催のようです。\n追記： 戦利品の画像です。マグカップ（500円）以外は貰い物です。 なんと、このUSBにはMongoDBのコマンドやクエリのチートシート（PDF）が入ってました。びっくり！\n","date":1321376880,"dir":"post/2011/","id":"bda9a5da86ec9790262e14f953bbadcb","lang":"ja","lastmod":1321376880,"permalink":"https://blog.johtani.info/blog/2011/11/16/mongodb%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC7%E5%9B%9E%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-16T02:08:00+09:00","summary":"今回は、触ろうと思って触れていないMongoDBの勉強会に行って来ました。 2週連続の渋谷で、さすがに今回は出口をすんなりでれました。 今回は初","tags":["勉強会"],"title":"MongoDB勉強会（第7回）に行って来ました。(Jugemより移植)"},{"contents":"Solr本の武田さんから教えていただいたSplunkの イベントに行って来ました。 Splunkとは様々な機器のログなどを一箇所に集めてリアルタイムに検索、分析できるようにするための製品です。（ざっくりした説明ですが。。。） ちなみに、データ量が小さければフリー版も用意されています。 以前、話しを聞いていて気になっていた所イベントが開催されるということだったので参加してきました。 以下に、その時取ったメモを記載しておきます。いつものごとく、自分用のメモなので、役に立つかはわかりませんが。\nSplunk Live! in toyosu\n日時：2011/11/02　10:00-12:00 場所：豊洲\n1.挨拶＋アジェンダ紹介 2.ビッグデータ取り込み、ロードマップ（Splunk Inc.）CEO Godfrey Sullivan 英語でした。。。 データの種類と量が大きくなってきてるのに、ツールが追いつかないし、回答するのもはやくしろと言われる。 非構造化データの例としてApacheのログが出ていた。 TimeSeriesのフラットファイルがsplunkのデータのインデックス。（No RDB＝スキーマいらないよと。）　※ここが重要な点かもしれない。 リアルタイムに解析できるのが売り。Jubatusとの違いとか聞くと面白いかも。 Machine Data Engine＝Splunk データの関連付けの方法がどんなものか？ 事前のスキーマが不要＝流しこむ前には定義が必要？だよね？ ？No need to filter/forward？？ デベロッパーフレームワークってなんだ？？ Splunkbaseと呼ばれる場所にSplunk Appsと呼ばれるアプリケーションがある。色々な場所、OS、アプリで利用できるものらしい。 ？自動監視も学習する仕組みがある？？ それとも定義するのか？ あくまでもMachine Dataと言っている。これは、ユーザのリレーションの解析などはないということか？ Leading Social Gaming Company＝Zynga Introscopeのログバージョンに似てるかもなぁ。 Cloudベースのアプリの解析にも利用（saleforce） 色々な利用シーンのお話。 3.適用事例（独立行政法人理化学研究所） 和光と神戸で利用。10G程度のデータを扱ってる？ ログから情報基盤を監視するのに利用している。 syslogベースでsplunkにログを送信している。 事例１：VPNに接続できない（接続数上限がある？） CISCOのログから解析 どの研究室で発生しているかも検索。 事例２：DHCPの接続ミス？（IPアドレスロスト） ここまでは問題が発生してからログを漁るという使い方。 事例３：LINK FLAPのアラート 短時間にUPDOWNを繰り返す場合にスイッチがおかしくなってるんでは？ 事例４：メール大量送信（ウィルス感染） 不特定多数のサーバに短時間でメールを配信している ※使い方としては情報基盤環境すべて（ネットワークとかサーバなど）のログを集めておいて監視＋解析に利用して障害対応などに利用している？データセンターとかに入れるのか？ あくまでも、ログを保存して、検索できる仕組みが１箇所にまとめられているという感じ。 そのログの解析について（どういった問題に対して、どういったクエリを投げるか？どういったトラップを仕込むか？）は利用する側の腕にかかっている印象。 ※実際に触ってみたいなぁ。500M/dayか。ご近所に入れてみるか？syslogで転送設定＋入れるサーバが必要。 4.最新アプリなどの紹介（Splunk Inc.） GUIがきれいだなー（最近のgoogleっぽいが。。。） リアルタイムにデータが入っているのが見えるのか。おもろいな。 どこのフィールドにヒットしたかがファセットで表示できるらしい。おもろい。 flashでできたビューがすごくおもろかったぞ。（ドキュメントどこだ？） 5.最新の取り組み（NTTデータ先端） やっぱり武田さんだった。 複数の監視システムのメッセージを統合して検索、アラートを出せるようにする。 消費電力を算出するためにログを集めて集計する。 6.QA ロードマップ ・２年以内にビジネスサイドでの利用に向けての動きを見せていく予定。 ・アプリケーションフレームワークにして、他のパートナーのアプリを載せていきたい。 ということで、感想ですが、事例紹介などを聴いた感じだと今のところはインフラ系のログを一元化して検索、監視、アラートをあげるということに活用するためのツールの用に感じました。 当初の使い方がそういったところにあるためだとは思いますが。 開発者としての視点で話しを聞いていて、活用できそうだというのは次のシーンでしょうか。\n開発時の開発環境のログ集約 性能試験などでのログ、性能データ集約 開発時点もしくは性能試験時ですが、色々なサーバ（DBやアプリサーバ）の時間を横串にして表示検索などができると思うので、問題があった時の各種サーバの状態を一元的に見れるため、どのサーバにどういった負荷がかかっていたか、 どこに問題があったかなどをグラフ化して見ることが簡単にできるのではないかなぁという感想です。 あとは、ログが一元化されているので、問題があったときにまずログを検索すればいいのが楽ですかね。\n基本的にはログが集まってるからあとは、どう使うかはご自由にという印象でした。 どのようなログを集めておき、どういったトラップでアラートさせるか、どのような検索をすれば望んでいるログが出てくるか、どのような集計をしたいかなどについては、やはり導入してからノウハウを貯めていくか、導入時にコンサルしてもらうなどが必要かと。 また、このツールを入れることでどのようなフィードバックをどのように活用できるかをイメージしていなければ、 宝の持ち腐れになりそうです。 あとは、使い方次第ですが、サーバログ以外にアプリログ（ユーザの行動履歴とか）などを入れることで、インフラ以外での使い道もありそうです。 とりあえず、保存しておいて、あとから特定の傾向を見出すのに検索できるのはちょっと面白いかも。\nあ、そうそう、ストラップとUSBメモリ（4G）のノベルティをお土産にもらいました。無料セミナーなのに。\n","date":1320822000,"dir":"post/2011/","id":"cc1a3b2f107510ac664e491d5f2412aa","lang":"ja","lastmod":1320822000,"permalink":"https://blog.johtani.info/blog/2011/11/09/splunk-live%E3%81%AE%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-09T16:00:00+09:00","summary":"Solr本の武田さんから教えていただいたSplunkの イベントに行って来ました。 Splunkとは様々な機器のログなどを一箇所に集めてリアルタ","tags":["misc"],"title":"Splunk Live!のイベントに行って来ました。(Jugemより移植)"},{"contents":"最近忘れやすいので、記録しておこうかと。 読んだスライドの簡単な内容と感想です。 ちなみに、スライドの一覧はこちらです。 ※スライドへのリンクはすべてPDFへのリンクになっていますので、注意が必要です。\nSolr 4 Highlights（PDF）\nSolrの次期バージョン4.0で採用される機能の紹介でした。 紹介されているのは次の機能。各機能について、JIRAの番号も記載があるので便利ですね。\nDirectSolrSpellChecker NRT (Near RealTime search) Realtime Get SolrCloud - search side SolrCloud - indexing side (WIP) これまでと異なるSpellChecker、Commit前のデータが検索できるNRT（なんでNRSじゃないんだろう？）、Commit前の登録済みデータを取得することが出来るRealtime Getなどの簡単な紹介です。 あと、個人的に興味のあるSolrCloud周りが絵付きで紹介されてます。ZooKeeperもちょっと出てきます。 まだ、ちゃんとまとめてないですが、NewSolrCloudDesignの翻訳したものも参考までに。（その１、その２）\nArchive-It: Scaling Beyond a Billion Archival Web-pages\nInternetArchiveの事例紹介。1996年からWebページのアーカイブを行なっているサイトですね。 その一部でSolrが利用されています。 「1,375,473,187 unique documents」との記述もあり、データ量が巨大です。 データ量が多いのに、ここでFieldCollapsing/Groupingも利用しているようで、インデックス作成、検索両方に対してカスタマイズしたものをgithubで公開している模様です。\n[**Scaling search at Trovit with Solr and Hadoop**](http://www.lucidimagination.com/sites/default/files/file/Eurocon2011/MarcSturlese_scalingsearchTrovit_eurocon2011.pdf) 次は、Trovitという会社のSolr＋Hadoopの事例紹介です。 最初はLuceneをベースに検索サーバ作ってたけど、Solrが出てきたので、Solrを使うようになったようで。 データ保存先として最初はMySQLを利用してDataImportHandlerでSolrにデータ登録してたけど、 データ量が増加するが、MySQLのShardingが面倒なので、Hadoop（Hive）でデータをパイプライン処理してSolrのインデックスを作成しましょうという流れになったようです。 私が以前、Solr勉強会で紹介したSOLR-1301のパッチをベースにMap/Reduceの処理を2段階にして性能をアップさせたという話が記載されてました。 ただ、これで早くなるのかはよくわからないんですが。。。 一応、資料では、いきなり大きなSolrのインデックスを作らずに、最初のM/Rで小さなインデックスを作成し（TaskTrackerの数＞＞Solrのshardサーバ数だから小さくしたほうが速い？）、 2段目のM/Rでインデックスをマージしてshardサーバ数のインデックスに集約する？という形みたいです。 （英語力のなさが。。。） あとは、テキスト処理を幾つかHadoopでやってますよという紹介でした。 SOLR-1301の利用者が他にもいて、違うアプローチをとっていたのが印象的。 毎回全データインデックス生成するときは、SOLR-1301を利用してshard数が増えてもすぐに対応が可能になるので、 かなり便利ですよ。\nSolr @ Etsy\nEtsyは個人の作家（編み物とかシールとか）の方が出店するためのショッピングモールのようなサイトです。 実は、最近、MacBookAirのステッカーを購入したのがここでした。 で、検索にSolrを使っています。 面白いのが、検索サーバとWebアプリ（PHPで書かれている）の間のデータのやり取りにThriftを利用していること。 Solrの前にThriftを話すサーバを別途用意しているようです。ネットワークのデータ量を減らすことが目的らしいです。 そのあとは、少しThriftのサーバでのLoadBalancingの話が続きます。 次にレプリケーションの性能問題のはなし。定期的にレプリケーションに異様に時間がかかるのが問題になったようで、 Multicast-Rsyncを試してみたけどダメでしたというはなし。 Bit Torrent + Solrという組み合わせで回避したらしいのですが、いまいち仕組みがわからなかったです。。。 こちらもgithubに公開されている模様。 あとは、QParser、Stemmerをカスタマイズしたものの話です。\nArchitecting the Future of Big Data and Search\nLuceneのカンファレンスにHortonworksが出てきてびっくりしました。 まぁ、Luceneの生みの親＝Hadoopの生みの親ですから、問題ないのかもしれないですが。 大半が予想通り、Hadoopに関する話でした。 知らないApacheのプロジェクト「Ambari」というのが出てきました。これは、HadoopConferenceJapan2011 Fallでの発表にもチラッと出てきたようです。 「Ambari is a monitoring, administration and lifecycle management project for Apache Hadoop clusters.」ということで、Hadoopクラスタの統合管理のツールになるんでしょうか？ 最後の2枚くらいにLuceneが出てきます。絡めてみたって感じですかね。\nConfiguring mahout Clustering Jobs\n今度はMahoutが出てきました。はやりのものが満載です。 まぁ、MahoutもLuceneのインデックスを利用するという話もありますので。 スライドはクラスタリングとはどういうものか、Mahoutの説明とテキストクラスタリング処理のお話、最後はstuckoverflowでのMahoutとSolrの活用の仕方について。\nということで、英語力がない中、かなり流し読みな感じですが、あとで思い出すために書きだして見ました。 何かの役に立てれば幸いです。\n他に、こんなスライドが面白かったとか、このスライドについても書いてほしいなどあれば、コメントください。\n","date":1320724920,"dir":"post/2011/","id":"d9c6ab5c6630a4a84e242c5765103d2d","lang":"ja","lastmod":1320724920,"permalink":"https://blog.johtani.info/blog/2011/11/08/lucene-eurocon-2011-barcelona-%E3%81%AE%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%89%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-08T13:02:00+09:00","summary":"最近忘れやすいので、記録しておこうかと。 読んだスライドの簡単な内容と感想です。 ちなみに、スライドの一覧はこちらです。 ※スライドへのリンクはす","tags":["solr"],"title":"Lucene Eurocon 2011 Barcelona のスライド読みました(Jugemより移植)"},{"contents":"Bookscanというサービスがあります。 書籍を電子化（PDF）して原本を破棄してくれるサービスです。\n電子書籍にはずっと興味を持っていました。 技術書を購入するのですが、技術書は３００ページ超の大きな書籍が大半です。 また、日本語の技術書については、なかなか電子書籍が見つからないもしくは、電子化されるのが遅いとうのが現状です。 海外では、Manningなど、電子書籍も同時に発売（もしくは、製本前から電子書籍が売られている）サイトがありますが、やはり英語の書籍はハードルが高いなぁと。\nそんな中、Bookscanの噂を耳にしました。 ということで、どんどん、積ん読になっていく技術書だったので、思い切って、電子化してみることにしました。 ※残念ながらまだタブレット（電子書籍端末）は持っていないのですが。。。もうすぐ発売されるlenovoの7inchタブレットを待ちかねているところです。\nBookscanでは、１冊１００円で書籍をPDFにしてくれます。（ページ数により変わってくる） この場合、あくまでも書籍をスキャンするだけで、検索などはできません。 OCR処理については別途１冊１００円（これもページ数による）のオプションが必要になります。 詳しいサービス内容はこちらを御覧ください。 基本的には書籍をBookscanに発送してから約３ヶ月ほど電子化するのに時間がかかります。 これでは、すぐに見たい場合に手元にないという状態になってしまいます。 この電子化までの時間を短くできる、「プレミアム会員」というオプションが存在します。 月額固定の費用（９９８０円）を支払うことで、５０冊（※ページ数により１冊の単位が異なります）まで無料で、「スキャン＋OCR＋書籍名をファイル名」のPDFファイルを書籍到着後１週間以内で作成してもらうことができます。 また、プレミアム会員は月単位での契約が可能なようで、１ヶ月（＝５０冊）だけ早く電子化してもらうといった利用方法もできるようです。\nで、実際にプレミアム会員となって４９冊の書籍を送付して電子化してもらいました。 先週金曜日に発送、Bookscanに書籍が到着したのが翌土曜日、電子化が完了したのが火曜日の夜という感じでした。 すごくはやい！かなり感動してます。自炊自体をしたことがないので、出来上がりが自炊と比べてという比較はできないのですが、ざっと見ている感じでは全然問題なく読めそうです。\nただ、１冊の２ページだけ、ページの端が文章の途中で切れているPDFがありました。 この書籍に関しては、サポートサービスにお願いして、再スキャンをしてもらいました。 昨日夜に頼んで今日の午後には問題なく電子化されているというサービスの質でとても満足しています。 なお、原本の破棄が電子化後から１０日後に行われるため、問題ないかの確認はそれまでに行う必要があるようです。 大量の本を送る場合は小分けに送ったほうが確認するのが楽になると思います。（送料は小分けにした分、かかってしまいますが。）\n書籍の山になっていた机がすっきりして、とても満足しています。 せっかく電子化したので、早くタブレットが欲しいなと思う今日この頃。。。 基本的には今後は電子書籍を購入するようにしていく予定なので、プレミアム会員を継続することはないと思いますが、 家に溜まっている漫画を電子化するのもありかなぁと思っているところです 漫画の場合はOCRに掛ける必要もないですし。\n個人的にはBookscanさんには悪いのですが、もっと電子書籍が増えると助かります。 技術書はページ数が多く、重たいうえ、実際に利用するときは検索したくなることが多々ありますので。 あとは、電子書籍を検索できるサイトがあるといいなと思ってもいるところです。 現在は、各出版社が個別に電子書籍のHPを持っている状況で、会社によっては検索すらできないです。 電子書籍があるかないかだけでも簡単に検索できると、いいなと思っています。（小説などはまた別なのかもしれないですが。） みんなはどう思ってるんですかねぇ？検索したくないですか？\n","date":1320225060,"dir":"post/2011/","id":"7a9609a971a8f31685e88da563eea5ce","lang":"ja","lastmod":1320225060,"permalink":"https://blog.johtani.info/blog/2011/11/02/bookscan%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-02T18:11:00+09:00","summary":"Bookscanというサービスがあります。 書籍を電子化（PDF）して原本を破棄してくれるサービスです。 電子書籍にはずっと興味を持っていました","tags":["misc"],"title":"Bookscanを使ってみました(Jugemより移植)"},{"contents":"lucene-gosenの最新版（1.2.0）をリリースしました。\nプロジェクトページよりダウンロードが可能です。\n新規追加機能についてはこちらのエントリを御覧ください。\nバグなどありましたら、容赦なく報告をいただけると助かります。\n","date":1320043560,"dir":"post/2011/","id":"14cf6e75aec1ead888e7101d3d94d28a","lang":"ja","lastmod":1320043560,"permalink":"https://blog.johtani.info/blog/2011/10/31/1-2-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2011-10-31T15:46:00+09:00","summary":"lucene-gosenの最新版（1.2.0）をリリースしました。 プロジェクトページよりダウンロードが可能です。 新規追加機能についてはこちら","tags":["lucene-gosen"],"title":"1.2.0リリース(Jugemより移植)"},{"contents":"すぐやりますと言いつつ、はや1ヶ月。。。 腰が重い、ダメエンジニアですね。。。\nすみませんでした。。。 ようやくtrunkにコミットしました。 すぐにリリース版を用意すると思います。\n1ヶ月もあいてしまったので、追加した機能に関するまとめと、 用途別の利用方法を記載しておきます。 （lucene-gosenのWikiにもそろそろ書かないとなぁ。日本語でもいいから。）\n追加した機能\nこれまでのlucene-gosenはjarに辞書を含む形でライブラリを提供していました。 ただ、この場合、カスタム辞書を利用している環境ではカスタム辞書を修正し、ビルドしなおすたびに、 jarファイルを作成しなければなりません。 また、jarファイルをSolrなどに配布する必要も出てきます。 この手間を考慮して、辞書を外部ディレクトリで指定することができるようにしたものが 今回の修正になります。 また、修正の過程で同一VM内で異なる辞書を使えるようにする機能も副産物として生まれました。 今回追加した機能は次のようなものになります。 辞書を含まないjarのビルドおよび提供 ディレクトリ指定による辞書の指定 同一VM内での複数辞書の利用 辞書リビルド用のAntターゲットの追加 Lucene/Solr jarファイルの最新化（3.4.0対応） ディレクトリ指定による辞書の指定ですが、以下のような形になります。 まずは、LuceneのTokenizerでの指定方法です。 「辞書のディレクトリ」という引数が追加になっています。 ここに、辞書ディレクトリ（*.senファイルが存在するディレクトリ）を相対/絶対パスで指定します。\n... Tokenizer tokenizer = new JapaneseTokenizer(reader, null, \u0026#34;辞書のディレクトリ\u0026#34;); ... つぎは、Solrでの設定の方法です。 schema.xmlにて次のような設定を行います。\n... \u0026lt;fieldType name=\u0026#34;text_ja\u0026#34; ...\u0026gt; \u0026lt;analyzer\u0026gt; ... \u0026lt;tokenizer class=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; compositePOS=\u0026#34;compositePOS.txt\u0026#34; dictionaryDir=\u0026#34;辞書のディレクトリ\u0026#34;/\u0026amp;gt; ... \u0026lt;/analyzer\u0026gt; \u0026lt;/fieldType\u0026gt; ... schema.xmlの設定については、example/schema.xml.snippetにも説明がありますので、こちらもあわせて参考に。 なお、Solrの設定については、先ほどのLuceneでの辞書のディレクトリの指定方法（絶対/相対パス）に加えて、 $SOLR_HOME/conf からの相対パスでの指定も可能になっています。\nAntのターゲットについて\n辞書なしjarファイルを作成するターゲットなどを追加しています。 実際に追加したターゲットは以下のとおりです。 ターゲット名 説明 nodic-jar 辞書なしのjarファイルを生成するためのターゲット。辞書のダウンロード、コンパイルは行いません。 rebuild-dic lucene-gosenのビルド済み辞書（.senファイル）を削除してから辞書のコンパイル（ビルド）を行います。-Ddictypeにより辞書のタイプ（ipadic|naist-chasen）の指定が必要です。また、-Dcustom.dicsによりカスタム辞書の指定もあわせて可能です。 build-dic-ipadic テスト用に追加。-Ddictype=ipadicを指定してbuild-dicを実行。 build-dic-naist-chasen ついでに追加。-Ddictype=naist-chasenを指定してbuild-dicを実行。 最後の２つはあまり関係ありません。内部的に有ると便利だったため、作りました。 重要なのは最初の２つです。 ひとつめの「nodic-jar」は辞書を含まないjarファイルをビルドします。 このjarファイル＋辞書の入ったディレクトリを利用することで、辞書の外部化が可能となります。\nそして、「rebuild-dic」です。こちらは、以前記事に書きましたが、カスタム辞書のコンパイルが思いの外面倒だったので、ターゲットを追加しました。 次のように指定することで、辞書のリビルドが可能です。\n$ ant -Ddictype=naist-chasen -Dcustom.dcs=\u0026#34;custom1.csv custom2.csv\u0026#34; rebuild-dic 提供されるjarファイルについて\n提供されるjarファイルは次のようになる予定です。 1番目のjarファイルが今回追加になる、辞書なしのjarファイルになります。\nlucene-gosen-1.x.x.jar lucene-gosen-1.x.x-ipadic.jar lucene-gosen-1.x.x-naist-chasen.jar 用途別の利用方法 利用用途別に利用するjarファイルやantのターゲットを利用シーンを交えて想定を書いてみます。 Solrでの利用シーンを想定します。\nお手軽に使う。辞書ありjarファイルで一発インストール。 これまでどおりの使い方になります。 辞書込みのjarファイルを利用すれば、すぐに利用可能になります。\nカスタム辞書を使い倒す。定期的に辞書をメンテナンス。 定期的にシステム固有の単語が増える（例：製品名、新語など）場合です。\n利用するjar：lucene-gosen-1.x.x.jar 辞書のコンパイル＋配置：ant -Ddictype=naist-chasen -Dcustom.dics=\u0026ldquo;custom1.csv\u0026rdquo; rebuild-dir Solrの該当コアのRELOAD Solrのマルチコア環境を利用します。なお、sharedLib設定にlucene-gosen-1.x.x.jarを配置すると、辞書の再読み込みができないので注意してください。 設定は、上記のようにTokenizerFactoryの設定でdictionaryDirにて辞書のディレクトリを設定しておきます。 カスタム辞書に単語を追加後、antにて、辞書のリビルドを行います。 リビルドした辞書ファイルを必要に応じて対象の辞書ディレクトリにコピーします。（ビルド後のディレクトリをそのまま利用している場合はコピーの必要はないです。） 最後に、Solrの該当コアのリロードを行います。（リロードの仕方はこちらを参考に。） コアのリロードにより、辞書の再読み込みが行われるので、リロード後から新しい辞書が適用されます。\n異なる辞書を使い倒す。TokenizerごとにdictionaryDir設定するぞ 1つのSolrで異なる辞書を使ったフィールドを使いたい場合です。 ipadicとnaist-chasenといった異なる場合はあまり想定できないですが、カスタム辞書の部分が異なるという形が想定できるでしょうか。（例：製品名のフィールド、企業名のフィールド。。。など）\n利用するjar：lucene-gosen-1.x.x.jar 設定：schema.xmlに異なるdictionaryDirを設定したTokenizerFactoryを設定 上記、カスタム辞書の定期更新も一緒に行うことも可能です。コアをリロードすれば、リロードしたコアで利用している 辞書がすべてリロードされます。\n最後に 遅くなってしまいましたが、ようやく、trunkにコミットしました。 できるだけ速く、リリースしますので、もう少々お待ちを。\nSolrのconfディレクトリからの指定については、＠shinobu_aokiさんにパッチを提供してもらいました。 また、trunkにコミットしていないパッチを適用して記事を書いてくれた方もいらっしゃいました。こちらもあわせて参考に。私より説明が上手です。 Java製形態素解析ライブラリ「lucene-gosen」を試してみる\n","date":1319559120,"dir":"post/2011/","id":"14a6d294550c9760aec57ba29682a750","lang":"ja","lastmod":1319559120,"permalink":"https://blog.johtani.info/blog/2011/10/26/%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%A4%96%E9%83%A8%E5%8C%96%E3%81%A8lucene-solr3-4%E5%AF%BE%E5%BF%9C/","publishdate":"2011-10-26T01:12:00+09:00","summary":"すぐやりますと言いつつ、はや1ヶ月。。。 腰が重い、ダメエンジニアですね。。。 すみませんでした。。。 ようやくtrunkにコミットしました。 すぐ","tags":["lucene-gosen"],"title":"辞書の外部化とLucene/Solr3.4対応(Jugemより移植)"},{"contents":"JJUG CCC 2011 Fallに参加してきました。 個人的にはかなり久々のJavaのカンファレンスです。（※あくまで「Javaの」という話で。SolrやHadoopとは別という意味です。）\n概要やタイムテーブルはこちら。 予定があったので、残念ながら最後の２つのセッション（Scala、Twitter）しか参加できませんでした。 Hadoopの話も聞きたかったのですが、しょうがないかと。 いつものごとく、メモを個人的に取ったので。\n★楽々Scalaプログラミング 浅海 ◎OOPからOFPへの道しるべ ・関数型の使い所、プログラミングのコツ ・つながりの部分 ◎最近の活動 モデリングからモデル駆動によるソース生成などに利用。 Scala、2008年から使い始めている ◎Scalaと他の機能との比較図 ◎Scalaの用途 ・高い生産性 体感で3倍。コード量が少なくなる。 IDEのサポートを考えるとまだ、Java+Eclipseのほうが高い！ ・DSL ドメインモデルの記述 フレームワークAPI ・並行プログラミング Many Core 消費電力的に複数のコアで動かす＝関数型のほうが並行性が上がる（スレッドさわるJavaだけだときつい） Parallel Everything Object指向＋関数型が扱いやすい。 ◎関数型言語とは ・公開関数をあつかえる 関数を値として扱える、引数と返却地に関数を渡せる。（やさしめ） ＜＝＞ 数学（ラムダ計算、圏論など）的にプログラムを記述できる（きびしめ） ある程度使えるはず。厳しめの部分も ◎関数型言語の長所と短所 長所 ・高階関数を使った技が使える List（？？？） 短所 ・メモリ、関数実行オーバーヘッド、スタックの大きさが読めない（再帰的） ◎関数型言語の系譜 純粋関数型言語 pure Lisp 伝統的関数型言語 OCaml 新世代関数型言語 Haskell Scala 型クラス 代数データ型、モナド Parametric polymorphism ◎関数型でしたいこと DSL（Domain Specific Lanuguage） 昨年の資料を参考に！ ◎準備 scalaの文法 ◎並列コレクション スレッドを利用しないで並列に動作実行させるか？ ※List().par.map(sitelen).sum これで並行実行させられる。 ◎Future （これってJavaでもあるよね？＝あるよ） 処理を非同期で先行実行し、あとから結果を取得可能 Scalaではアクターライブラリでサポート（cala.actors） 関数合成するとFutureの実行結果を取り出す所でブロックされる！！ ◎Promise Futureより強力 関数合成すると、合成関数全体が非同期実行される！ scalazを利用してた ◎5つのコツ コツ１：　y=f(x) 引数がひとつの関数が基本 関数合成のビルディングブロックになるよ 引数が複数ある関数は他の関数（map関数とか）で合成しにくい 対処方法：カリー化（関数の戻りを関数とする） addc(a: Int)(b: Int) : Int = a + b とすることで、 コツ２：分割統治 コツ３：演算は転換 flatMapとかfoldLeftとか ※永続データ構造 前に作ったデータ コツ４：オブジェクトの世界と関数の世界を分ける 更新指示書の形でObjectに渡す？ 関数型データ構造 コツ５：新しいデザインパターン 関数型プログラミングの用語 ・Functor（関手） ・Subgroup（半群） ・Monoid（モノイド） ・Monad（モナド） OOPのデザインパターン的に考えれば、数学的なところまで理解しなくてもよさそう？ ★Twitterとオープンソース　@yusukey http://dev.twitter.com http://bit.ly/tdt-ja id：twj_dev ◎OSSとの関わり 支援してます。 Apache、Eclipse、Open Invention、JCP、OpenJDK パフォーマンス系のためにもOpenJDKに参画してる ◎Twitter API オープンなAPIで無償提供 １３言語でAPIライブラリがあるよ ◎Twitter4Jのこれまで ほぼ全てをカバー APIはだいぶ落ち着いてきていて、追加変更は少なくなってる。 ◎立ち位置 Twitterはコミュニティを活発にするためにもライブラリを出さないらしい。 ◎Twitter4Jのこれから キャッシング ストリーミングAPI利用を簡単に モックテスト レートリミットの影響を受けると辛いから。。。 ツイート/ユーザの永続化機能 jClouds対応？ ライブラリからフレームワークへ 半公式ライブラリへ github/twitter/twitter4jへ JSR Social API Twitter4Jが参照実装に？？？ スケーラビリティの話。 Hadoopはユーザのデータ解析とかに使ってる。 メッセージはキューイングしている。デモ。 memcachedプロトコルなんだけど、値を取ると値が消えるよ。（memcachedとは動きが違うよねー。プロトコル的にはクライアントがいっぱいあっていいよねー） RubyのGCがきつかったのでJavaベースに変更 Kestrel（Scalaで記述。） Kestrelのフォーカス外 メッセージの順序保証（してないよ） トランザクション memcachedプロトコルの拡張１ ブロックフェッチ コンシューマから取りに行くというのが特徴 memcachedプロトコルの拡張２ リライアブルフェッチ ということで感想。\nScalaは前から気になっていて、本までかってるのになかなか手を付けられていない始末でした。 そんな時にこのJJUGの話があったので、ちょうどいいと聞きに。 関数型やScalaのぼんやりしたイメージのみを持って聴いていたのですが、思った以上にキーワードが多くてついていくのがやっとというイメージ。 で、いつものごとく、Twitterでつぶやいていた所、色々な反応が。（わからずにつぶやいたのもあり、波紋を呼んだ模様） お陰で、Scala関連の方たちをフォローできたので結果オーライでした。 話の内容自体はサラっとながす感じだったので、再度資料を見る＋Scalaをもっと勉強しないと理解出来ないなぁという印象でした。 ちなみに、資料はこちら。\n次は、最近Twitterの中の人になった山本さん（@yusukey）の話しを聞きました。 Twitter4Jの話と、TwitterのOSSへの関わりの話。あとは、実際にTwitterが作成しているOSSのひとつKestrelについて。 TwitterはRubyベースで色々と作ってきていたのだが、Java（JVM上で動く言語（Scalaなど））に徐々にシフトしているというのが一番の印象です。あとは、Lucene、Hadoopなど私の興味のあるOSSも利用しているなど。 Kestrelについてはデモを交えながら、実際の動きを説明されていたのでとてもわかり易かったです。 プレゼン中もTweetを表示しながらという、さすがTwitterの中の人という印象でした。 Twitterでは少し前から知り合いだったのですが、実際にお会いできた（イケメンでしたよ！）のも収穫でした。 次はStormの話も聞きたいかなぁ\nで、２セッション（山本さんの話のあとにLT大会にも参加）だけですが、全体の感想を。 「クロスコミュニティカンファレンス」というだけあり、Java以外の話題（CouchDBとか名前がありました）もちらほらあったようです。 ただ、最近の他の勉強会やカンファレンスに比べると人が少ない印象でした。 私が参加したセッションは比較的大きな部屋だったせいもあり、40～50人くらい入っていたと思うのですが、ガラガラな印象でした。良い意味で、Javaも安定してきているため、参加者が少なかったのかなぁと あとは、年齢層がHadoopなどに比べると高めかなぁという印象（かく言う私も年齢層を上げている一人ですが。。。）。Javaも長いですからねぇ。 午前中から参加していると違った印象だったかもしれないですが。。。 あと、初めて行った会場で、しかも大きめの施設でした。午後の途中から行ったせいもあるかもしれないですが、 案内が出ていなくて若干迷子に。。。 ただ、セッションの部屋自体は各席に机があり、電源も比較的多めにあったので、PC持ち込みでメモを取るには最適でした。\n","date":1318922443,"dir":"post/2011/","id":"5d827a1e8ea70edb11d946b54f076cae","lang":"ja","lastmod":1318922443,"permalink":"https://blog.johtani.info/blog/2011/10/18/jjug-ccc-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-10-18T16:20:43+09:00","summary":"JJUG CCC 2011 Fallに参加してきました。 個人的にはかなり久々のJavaのカンファレンスです。（※あくまで「Javaの」という話で。SolrやHad","tags":["備忘録"],"title":"JJUG CCC 2011 Fallに参加してきました。(Jugemより移植)"},{"contents":"昨日、文章から特定の単語（リストあり）を探したいという話を聞き、lucene-gosenでもできるねぇという話になりました。 まぁ、考えてみればごくごく当たり前なのですが。。。（その筋の方たちにしてみれば常識なのかもしれないですが。。。） 一応やってみたので、こんなこともできるなという一例ですということで、記録を残しておきます。\n今回の例文として野田首相の所信表明演説の一部を活用させてもらいます。 単語のリストは次のようにします。\n内閣総理大臣 正心誠意 東日本 日本 今回も結果をわかりやすくするためにSolrのanalysis画面を利用します。 作業手順は以下のとおり。\ndictionary.csvの編集 辞書のコンパイル fieldTypeの定義（Solrのschema.xmlの設定） 文章からキーワード抽出（Solrのanalysis画面） ### **1.dictionary.csvの編集** 今回はnaist-chasenディレクトリで作業します。 なお、今回利用するlucene-gosenは[ここ](http://johtani.jugem.jp/?eid=21)で紹介した辞書分離バージョンです。（はやくtrunkにコミットせねば。。。） dictionary.csvを先ほど上げた単語だけのエントリに変更します。 キーワードだけを抽出したいので、他の単語は必要ないからです。 ``` \u0026ldquo;内閣総理大臣\u0026rdquo;,1,名詞,一般,,,,,\u0026ldquo;内閣総理大臣\u0026rdquo;,\u0026ldquo;ナイカクソウリダイジン\u0026rdquo;,\u0026ldquo;ナイカクソウリダイジン\u0026rdquo; \u0026ldquo;正心誠意\u0026rdquo;,1,名詞,一般,,,,,\u0026ldquo;正心誠意\u0026rdquo;,\u0026ldquo;セイシンセイイ\u0026rdquo;,\u0026ldquo;セイシンセイイ\u0026rdquo; \u0026ldquo;東日本\u0026rdquo;,1,名詞,一般,,,,,\u0026ldquo;東日本\u0026rdquo;,\u0026ldquo;ヒガシニホン\u0026rdquo;,\u0026ldquo;ヒガシニホン\u0026rdquo; \u0026ldquo;日本\u0026rdquo;,1,名詞,一般,,,,,\u0026ldquo;日本\u0026rdquo;,\u0026ldquo;ニホン\u0026rdquo;,\u0026ldquo;ニホン\u0026rdquo;\n\u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; ### **2.辞書のコンパイル** 先ほど作成した辞書をコンパイルし、lucene-gosen用バイナリ辞書を作成します。 $ cd $LUCENE_GOSEN_HOME¥dictionary $ ant -Ddictype=naist-chasen clean-sen compile\n\u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; ### **3.fieldTypeの定義（Solrのschema.xmlの設定）** Solrのschema.xmlにlucene-gosenを利用するフィールドタイプを定義します。 追加するのは次の通り \u0026lt;fieldType name=\u0026quot;text_ja\u0026quot; class=\u0026quot;solr.TextField\u0026quot; positionIncrementGap=\u0026quot;100\u0026quot; autoGeneratePhraseQueries=\u0026quot;false\u0026quot;\u0026amp;gt; \u0026lt;analyzer\u0026amp;gt; \u0026lt;tokenizer class=\u0026quot;solr.JapaneseTokenizerFactory\u0026quot; compositePOS=\u0026quot;compositePOS.txt\u0026quot; dictionaryDir=\u0026quot;keyword-dic\u0026quot;/\u0026amp;gt; \u0026lt;filter class=\u0026quot;solr.JapanesePartOfSpeechKeepFilterFactory\u0026quot; tags=\u0026quot;keeptags_ja.txt\u0026quot; enablePositionIncrements=\u0026quot;true\u0026quot;/\u0026amp;gt; \u0026lt;/analyzer\u0026amp;gt; \u0026lt;/fieldType\u0026amp;gt; また、ここで定義しているcompositePOS.txt、keeptags_ja.txtは次のようになります。 compositePOS.txt 未知語\nkeeptags_ja.txt 名詞-一般\n未知語がバラバラに出現しないようにして見やすくするためと、必要な単語（今回は「名詞-一般」しか利用しないため。）だけを抽出したいための設定です。 \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; **### 4.文章からキーワード抽出（Solrのanalysis画面）** あとは、analysis画面で解析して見るだけになります。 ということで、辞書に登録された単語だけが抽出されてますね。 この例ではインデックスに登録となりますが。 ただし、「東日本」「日本」のような一部を含む単語の場合、「東日本」が見つかった場合は「日本」は抽出されません。 あくまでも、ベストな解が見つかるのみという形です。 すべての単語を出したい場合はもう少しやり方を考えたほうがいいかもしれません。 （まぁ、このやり方でキーワードを抽出するかも考えたほうがいいかもしれませんが。。。） \u0026lt;/div\u0026gt; 最近、頭が硬くなってきてるなぁと実感してしまいました。まぁ、こんな使い方もあるかなぁと。 もっと頭を柔らかくして問題を解けるけるようになりたいなぁと。 ","date":1318389420,"dir":"post/2011/","id":"b9d4f73fa7ca8ef66891554b66b2cded","lang":"ja","lastmod":1318389420,"permalink":"https://blog.johtani.info/blog/2011/10/12/lucene-gosen%E3%81%A7%E6%96%87%E7%AB%A0%E3%81%8B%E3%82%89%E3%82%AD%E3%83%BC%E3%83%AF%E3%83%BC%E3%83%89%E6%8A%BD%E5%87%BA%E3%82%A4%E3%83%AC%E3%82%AE%E3%83%A5%E3%83%A9%E3%83%BC/","publishdate":"2011-10-12T12:17:00+09:00","summary":"昨日、文章から特定の単語（リストあり）を探したいという話を聞き、lucene-gosenでもできるねぇという話になりました。 まぁ、考えてみれ","tags":["lucene-gosen"],"title":"lucene-gosenで文章からキーワード抽出（イレギュラー？）(Jugemより移植)"},{"contents":"ちょっと間があいてしまったが、ようやくIoの1日目を終了。 なれない感じの言語なので苦労しました。 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大募集です。コメント欄にどしどしコメントください。そこは違うだろ？こっちのほうがいいのでは？という感じで。\n感想： プロトタイプ言語であり、すべての言語はクローンだそうです。\n○手始めに スロット、オブジェクトのクローンについて。 メッセージとその送信について。 あくまでもオブジェクトだけの世界。クローンであり、クラスのインスタンスではない。（まだつかめない。。。） ### ○オブジェクト、プロトタイプ、継承 slotNamesで取れないけど、継承してる。クローンで元をコピーしてるだけか？ 頭文字が大文字かどうかがtypeかどうかの違い。大文字＝type（クラスもどき＝） オブジェクト＝スロットの入れ物 オブジェクトのクローン＝オブジェクトのチェーン？（Object ＝＞ Vehicle ＝＞ Car ＝＞ ferrari） 疑問点： 存在しないスロット名をgetSlot()で呼び出したら？＝＞nilが返る 存在しないスロットをメッセージとして送信したら？＝＞Exceptionが出る ○メソッド method()で定義 メソッドもオブジェクト＝スロットに入れることができる（まだつかめない。。。） メソッドをスロットから呼び出すと実行される。 ○リストとマップ リスト、マップは簡単。幾つか（スタックやキュー）のメソッドも用意されてる。 ○true、false、nil、singleton cloneメソッドを最定義することでsingletonの動作にする。（言われてみれば当たり前か） Object cloneをオーバーライドすることもできるが、プロセス停止などしないとダメ。（恐るべし。。。） ○インタビュー SIMD（Single Instruction Multiple Data）http://ja.wikipedia.org/wiki/SIMD やりながら感想： シンタックスが全然違うのでかなり戸惑い。 ただ、考え方はシンプル。slotとか。 まだ、予約語がわかってない（cloneとかprintとかslotNamesとか）ので。 ★セルフスタディ （探してみよう） ○Ioのいくつかの問題点の例 見つけられず。。。英語がダメダメ。。。　○質問に答えてくれるIoコミュニティ\nML：http://tech.groups.yahoo.com/group/iolanguage/ twitter：http://twitter.com/#!/iolanguage **○Ioのイディオムに関するスタイルガイド** Io Note（英語） [http://iota.flowsnake.org/](http://iota.flowsnake.org/) Ioプログラミングガイド [http://iolanguage.com/scm/io/docs/IoGuide.html](http://iolanguage.com/scm/io/docs/IoGuide.html) [http://xole.net/docs/IoGuide_ja.html](http://xole.net/docs/IoGuide_ja.html)（日本語） Ioスタイルガイド [http://en.wikibooks.org/wiki/Io_Programming/Io_Style_Guide](http://en.wikibooks.org/wiki/Io_Programming/Io_Style_Guide) [http://d.hatena.ne.jp/katzchang/20080819/p1](http://d.hatena.ne.jp/katzchang/20080819/p1)（日本語訳してくれてるブログ） （確認してみよう） ○1 + 1を評価してから、1 + \u0026ldquo;one\u0026quot;を評価する。Ioは強く型付けされた言語か？\n``` Io\u0026gt; 1 + 1 ==\u0026gt; 2 Io\u0026gt; 1 + \u0026ldquo;one\u0026rdquo;\nException: argument 0 to method \u0026lsquo;+\u0026rsquo; must be a Number, not a \u0026lsquo;Sequence\u0026rsquo; message \u0026lsquo;+\u0026rsquo; in \u0026lsquo;Command Line\u0026rsquo; on line 1\nということで、型付けは強いです。 \u0026lt;/div\u0026gt; **○0は真か偽か？空文字列はどうか？nilは真か偽か？** \u0026lt;div\u0026gt; Io\u0026gt; 0 ==\u0026gt; 0 Io\u0026gt; true and 0 ==\u0026gt; true Io\u0026gt; true and \u0026quot;\u0026rdquo; ==\u0026gt; true Io\u0026gt; \u0026quot;\u0026quot; ==\u0026gt; Io\u0026gt; true and nil ==\u0026gt; false Io\u0026gt;\n0、空文字列はtrue、nilはfalseでした。 \u0026lt;/div\u0026gt; **○プロトタイプに存在するスロットを確認するにはどうすればよいか？** \u0026lt;div\u0026gt; Io\u0026gt; Highlander := Object clone ==\u0026gt; Highlander_0x1a233a0: type = \u0026ldquo;Highlander\u0026rdquo;\nIo\u0026gt; hoge := Highlander clone ==\u0026gt; Highlander_0x1a83630:\nIo\u0026gt; hoge proto slotNames ==\u0026gt; list(type) Io\u0026gt; Highlander name := \u0026ldquo;arnold\u0026rdquo; ==\u0026gt; arnold Io\u0026gt; hoge slotNames ==\u0026gt; list() Io\u0026gt; hoge proto slotNames ==\u0026gt; list(type, name) Io\u0026gt; Highlander slotNames ==\u0026gt; list(type, name) Io\u0026gt; hoge name ==\u0026gt; arnold Io\u0026gt; hoge getSlot(\u0026ldquo;name\u0026rdquo;) ==\u0026gt; arnold\nこんな感じ。slotNamesでスロット名を確認し、スロット内部についてはgetSlotで確認できます。 \u0026lt;/div\u0026gt; **○等号（=）、コロン等号（:=）および、コロンコロン等号（::=）の違いはなにか？どのようなときに使うか？** \u0026lt;div\u0026gt; \u0026lt;table class=\u0026#34;list_view\u0026#34;\u0026gt; \u0026lt;thead\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;th\u0026gt;演算子\u0026lt;/th\u0026gt; \u0026lt;th\u0026gt;説明\u0026lt;/th\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;/thead\u0026gt; \u0026lt;tbody\u0026gt; \u0026lt;tr class=\u0026#34;spec\u0026#34;\u0026gt; \u0026lt;td\u0026gt;:::=\u0026lt;/td\u0026gt; \u0026lt;td\u0026gt;スロットへの代入＋setterの追加\u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr class=\u0026#34;specalt\u0026#34;\u0026gt; \u0026lt;td class=\u0026#34;alt\u0026#34;\u0026gt;:=\u0026lt;/td\u0026gt; \u0026lt;td class=\u0026#34;alt\u0026#34;\u0026gt;スロットへの代入\u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr class=\u0026#34;spec\u0026#34;\u0026gt; \u0026lt;td\u0026gt;=\u0026lt;/td\u0026gt; \u0026lt;td\u0026gt;スロットへの代入（ただし、スロットが存在しない場合は例外が発生）\u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;/tbody\u0026gt; \u0026lt;/table\u0026gt; とまぁ、記載したが、実際に動かして確認しました。 Io\u0026gt; Highlander := Object clone ==\u0026gt; Highlander_0x223b800: type = \u0026ldquo;Highlander\u0026rdquo;\nIo\u0026gt; hoge := Highlander clone ==\u0026gt; Highlander_0x21acd60:\nIo\u0026gt; hoge slotNames ==\u0026gt; list() Io\u0026gt; hoge name ::= \u0026ldquo;arnold\u0026rdquo; ==\u0026gt; arnold Io\u0026gt; hoge slotNames ==\u0026gt; list(setName, name) Io\u0026gt; hoge sword := \u0026ldquo;long sword\u0026rdquo; ==\u0026gt; long sword Io\u0026gt; hoge slotNames ==\u0026gt; list(setName, name, sword) Io\u0026gt; hoge clothes = \u0026ldquo;armor\u0026rdquo;\nException: Slot clothes not found. Must define slot using := operator before updating. message \u0026lsquo;updateSlot\u0026rsquo; in \u0026lsquo;Command Line\u0026rsquo; on line 1\n\u0026lt;/div\u0026gt; ### （試してみよう） **○ファイルからIoプログラムを実行せよ** \u0026lt;div\u0026gt; ファイル「great.io」を作成し、以下を入力。 Highlander := Object clone Highlander giveWarCry := \u0026ldquo;Woooooooo!!\u0026rdquo; println Highlander giveWarCry()\nで、以下のコマンドを実行する。 $ io great.io Woooooooo!!\n\u0026lt;/div\u0026gt; **○スロットの名前を指定して格納されているコードを実行せよ** \u0026lt;div\u0026gt; Io\u0026gt; Masason := Object clone ==\u0026gt; Masason_0x20ae7d0: type = \u0026ldquo;Masason\u0026rdquo;\nIo\u0026gt; Masason recieveNiceTweet := method(\u0026ldquo;やりましょう\u0026rdquo; println) ==\u0026gt; method( \u0026ldquo;やりましょう\u0026rdquo; println ) Io\u0026gt; Masason getSlot(\u0026ldquo;recieveNiceTweet\u0026rdquo;) ==\u0026gt; method( \u0026ldquo;やりましょう\u0026rdquo; println ) Io\u0026gt; Masason getSlot(\u0026ldquo;recieveNiceTweet\u0026rdquo;) call やりましょう ==\u0026gt; やりましょう\ncallとgetSlotが鍵ですね。 \u0026lt;/div\u0026gt; 1日目の途中で間があいてしまったのでシンタックスを忘れてしまう始末。。。 ただ、そんなに込み入った記述もないので、最初に勉強することは少ないかもしれないです。 まだメソッドをあとから追加とか、cloneしたあとにまたプロトタイプを変更して反映可能など、考え方になれないもところがありますが、良い頭の体操になってます。 間を置かずに3日目まで行かないと！！ ","date":1317990120,"dir":"post/2011/","id":"dc962e34780f0374b7eb3d583f6d7eb6","lang":"ja","lastmod":1317990120,"permalink":"https://blog.johtani.info/blog/2011/10/07/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-1%E6%97%A5%E7%9B%AE/","publishdate":"2011-10-07T21:22:00+09:00","summary":"ちょっと間があいてしまったが、ようやくIoの1日目を終了。 なれない感じの言語なので苦労しました。 今回もセルフスタディの私の回答が最後の方に記","tags":[],"title":"「7つの言語　7つの世界」 Io 1日目(Jugemより移植)"},{"contents":"久々に、MBAの備忘録です。 あれから色々入れました。 なので、入れたソフトの一覧を追加。\nAIR：TweetDeckをインストールするのに必要だったため TweetDeck（AIR版）：TwitterとFacebookを同じ画面で見ることができるため。 TextWrangler：テキストエディタ（まだあんまり使ってない） Skitch：Evernoteに買収されて無料に。先日のSolr管理画面の説明書きにもちょっと使用 ClamXav：フリーのセキュリティソフト。 SourceTree：Twitterで知ったMac用のgit、mercurialのクライアントソフト。AtlassianがSourceTreeを買収したのを機に一時的に無料公開されていたので。 Firefox：基本はSafariを使ってます。WindowsではChromeを使ってます。ただ、Webページを表示されていない部分もまるごとキャプチャするのにChromeのプラグインだとダメだったので入れました。今のところキャプチャ用のブラウザです。 Full Screen enable for Eclipse on Lion：Eclipseをフルスクリーン対応するためのプラグイン MercurialEclipse：bitbucketにアカウントをもっているので。 mercurial：pipを使ってインストール。MercurialEclipseでコマンドが必要だから。「sudo pip install Mercurial」 pip：mercurialをインストールするためにインストール。「sudo easy_install pip」でインストール iStat pro（ウィジェット）：CPUなどの情報を表示するウィジェット。ウィジェットがアップルのサイト（AppStoreではない）から検索できるというのを人から聞いた。ウィジェットってあんまり使われないのか？ Mac Blu-ray Player：現時点で有料ソフトはこれだけ。こちら。もともとNASのデータのバックアップ用にBlu-rayのドライブ買ったんですが、せっかくだからMacにも使ってみようと思い、MacでBlu-rayを見るために購入しました。所用で長距離移動もあったので、新幹線で映画見てました。 このくらいです。 ほんとはリンクを貼ればいいのですが、そこまでの元気がないので、ご勘弁を。\nSkitchがおすすめです。簡単に画像編集＋説明書きが入れられて、矢印などがよくある画像編集の野暮ったさがないので、画面キャプチャに説明書くのに今後活躍する予定です。\nあと、ソフトではなく、サービスなのですが、Cacooというサービスが便利です。 ここ最近、ちょっとした作図にはこのサービスを使うようにしています。オンラインで利用できるので、いろんな場所で編集できます。 また、図の作成もさることながら、図を共有することが可能です。 先日は、lucene-gosenが思ったように動かないという相談を受けて、このCacooでanalysis画面や設定をを貼ってもらったりしながら使いました。結構便利ですね。 ただ、付属のチャットを使ったのですが、このチャットの内容がテキスト形式でコピー出来なかったのが残念でした。今後の改修に期待ということで。\nあと、セットアップとは少し違いますが、ジャケット買ってつけました。 ステッカーを直接貼るのがちょっと気になったので、ジャケットつけてステッカーを貼ってます。 ただ、ステッカーは思ったよりチープな感じが。。。ジャケットの中に貼らないとダメだったかも。まぁ、それが嫌でジャケット買ったんですが。。。 エアージャケットセット for Macbook Air 13inch(クリア)PMC-81 ","date":1317968700,"dir":"post/2011/","id":"de1ab82817c0fb24e591b9a89a82f736","lang":"ja","lastmod":1317968700,"permalink":"https://blog.johtani.info/blog/2011/10/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%94/","publishdate":"2011-10-07T15:25:00+09:00","summary":"久々に、MBAの備忘録です。 あれから色々入れました。 なので、入れたソフトの一覧を追加。 AIR：TweetDeckをインストールするのに必要だ","tags":["備忘録"],"title":"MBAセットアップ備忘録その４(Jugemより移植)"},{"contents":"Lucene/SolrのMLでSolrの管理画面を新しくするというチケットが流れていたのでちょっと触って見ました。 ほんとにちょっと触っただけですが、いくつかキャプチャ撮ってみたので、アップしときます。 ※以下ではサムネイル画像に元画像（100Kくらいの画像）へのリンクが設定されています。携帯などでは見づらいかもしれませんが、ご容赦を。\nURLは旧管理画面とことなり、http://localhost:8983/solr/になります。\nまずはトップ画面 ダッシュボードと呼ばれるトップ画面。メモリの利用率や起動してからの時間、Luceneなどのバージョンが表示されます。 次は検索画面すっきりしてます。facetが指定できるようになったのは大きいかな。ただし、facet.fieldを複数指定などができないが。結果についてはとくに指定がなければXMLで帰ってきます。ただ、パラメータの追加ができなくなってる気がするなぁ ちなみに、Solrを止めて検索したらこんな感じの画面になりました。クエリの実行ならこのようにエラーがわかったのですが、停止後に左のメニューにあるSchemaなどをクリックしても白い画面が出るだけで、エラーかどうかがわかりにくいです。 Analysis画面。入力画面がシンプルになりました。フィールド名はリストで表示されるので選択するだけです。あとは、これまでどおり。サンプルはlucene-gosenの解析結果です。ハイライトもきちんと表示されます。ただし、長い文章の場合は結果部分だけがスクロールできる形になり、ちょっとわかりにくかったです。 Analysisの入力画面を表示したあとにSolrを停止して解析してみたらこんなエラー画面が出ました。ちなみに、その後、画面を切り替えずにSolrを起動して解析したら、赤い帯のエラーは出たままでした。一度別画面にすれば、元に戻りますが。 Pluginsの画面（旧管理画面のstatisticsに相当）。 キャッシュの状態が確認できます。今まであった画面と情報的には一緒かと。一段カテゴリ（CACHEとかCOREとか）の選択ができるようになり、見やすくなりました。 同じくPluginsの画面。 こちらはupdateHandlerについての情報です。commit数やoptimizeの回数、updateして、commitする前の状態のドキュメント数などが表示されます。前より表示される項目が多くなってるかな？ 最後はスキーマブラウザこの画面が一番良くなっています。旧管理画面では、フィールド名がすべて大文字で表示され、しかもソートがされていない状態だったため、ダイナミックフィールドを利用しているとフィールドを探すのが一苦労でした。 今回は、プルダウンでフィールドやフィールドタイプのリストが表示され、辞書順で並んでいます。Filterなどもわかりやすい表示になっているかと。 おまけ Solritasと呼ばれるVelocityを使った、3.x系で入ってきた新しいサンプル画面です。URLはhttp://localhost:8983/solr/browseです。ファセットなどを使った簡単なサンプル画面なので、検索結果画面でこんなことができるというデモにも使えるかと。ただ、これも旧管理画面よりはましですが、デザインが。。。 とまぁ、簡単ですが、4.x系の管理画面をいくつか触ってみて、キャプチャをとって見ました。 デザインは前よりもすっきりしています。ただ、クエリについてはパラメータの追加ができなくなっているので、もう少し改良されるといいかなぁ（自分でやれよと言われそうですが。。。）\n","date":1317811380,"dir":"post/2011/","id":"09677934e13a5d728f00c6ed7c8870a9","lang":"ja","lastmod":1317811380,"permalink":"https://blog.johtani.info/blog/2011/10/05/solr%E3%81%AE%E6%96%B0%E3%81%97%E3%81%84%E7%AE%A1%E7%90%86%E7%94%BB%E9%9D%A2solr4-x-trunk%E7%B3%BB/","publishdate":"2011-10-05T19:43:00+09:00","summary":"Lucene/SolrのMLでSolrの管理画面を新しくするというチケットが流れていたのでちょっと触って見ました。 ほんとにちょっと触っただけ","tags":["solr"],"title":"Solrの新しい管理画面（Solr4.x trunk系）(Jugemより移植)"},{"contents":"遅くなりましたが、続きです。 さらに英語力のなさを痛感して凹んでいるところですが、何かの役に立てばと恥を晒すところです。。。\n一応、訳してみたのですが、訳すのに必死になってしまい、つながりがわかっていない点もちらほら。 このあと一旦見直しつつ、再度理解する「理解編」をアップしようかと思います。 できれば、シーケンス図とかも交えつつ。（そうしないと理解ができない可能性が。。。） 前回同様、原文は最後に付加しておきます。\nBoot Strapping Cluster Startup（クラスタの起動） ノードはZookeeperのホストとポートを指定することから始めます。 クラスタの最初のノードはクラスタのschema/configとクラスタの設定を指定するとこから開始します。 最初のノードはZookeeperに設定をアップロードしてクラスタをブートします。 クラスタは「ブートストラップ」状態です。 この状態ではノード-\u0026gt;パーティションマッピングは計算されず、クラスタはクラスタ管理コマンド以外のどんなread/writeリクエストも受け付けません。\nクラスタの最初のノード集合が起動した後、クラスタ管理コマンド（TBD記述？？？）が管理者によって発行されます。このコマンドは整数「partitions」パラメータを受け取り、次のステップを実行します。\nCluster Lockを取得 「partitions」をパーティション数として割り当て 各パーティションのためのノードを取得 ZooKeeperのノード-\u0026gt;パーティションマッピングを更新 Cluster Lockをリリース 全ノードに対して最新版のノード-\u0026gt;パーティションマッピングをZooKeeper経由で更新させる Node Startup ノードが起動すると、自分がすでに存在するシャードの一部かどうかZooKeeperでチェックします。 もし、ZooKeeperがノードのレコードを持っていない、またはどのシャードの一部でもないと判断したら、 ノードは後述の「New Node」のステップを実行します。すでに存在するノードの場合は後述の「Node Restart」のステップを実行します。\nNew Node\n新しいノードはクラスタの一部ではなく、クラスタのキャパシティを増強するためのものです。\n「auto_add_new_nodes」クラスタプロパティが「false」の場合、新しいノードはZooKeeperに「idle」として登録され、他のノードが参加してくれと言うまで待機します。 そうでない場合（auto_add_new_nods=true）は次のステップを実行します。\nCluster Lockを取得します。 適切なnode-\u0026gt;partitionエントリを選び出します。 利用可能なパーティションのリストをスキャンして「replication_factor」のノード数以下のパーティションのエントリを探します。複数ある場合はノード数が最小のエントリを選びます。それも一緒ならランダムに選びます。 全パーティションが「replication_factor」以上のノードを持っている場合、ノードはパーティションが最も多いものをスキャンします。複数ある場合はパーティション内のドキュメント数が最大のエントリを選びます。ドキュメント数が同一なら任意のエントリを選びます。 もし、選んだノード-\u0026gt;パーティションエントリを現在のノードに移動させることでがクラスタのパーティション：ノード比率の最大値を小さくするなら、現在のエントリを返します。。それ以外の場合選ばれたエントリがないので、アルゴリズムは終了です。。 ZooKeeper内のノード-\u0026gt;パーティションマッピングを更新します ZooKeeper内のノードステータスを「リカバリ」状態にします Cluster Lockをリリースします 「リカバリ」はパーティションのリーダーから開始します。 リカバリが終了したら、再度、Cluster Lockを取得します。 元のエントリはZooKeeperのノード-\u0026gt;パーティションマッピングから削除されます。 Cluster Lockをリリースします 元のノードはZooKeeperからノード-\u0026gt;パーティションマッピングを更新させられます ステップ1に戻ります。 Node Restart ノードの再起動とは次のいずれかを意味しています。\nJVMがクラッシュし、手動または自動でのリスタート ノードが一時的にネットワークから切り離された。もしくは、ZooKeeperに接続できなかった（死んでいると思われた）。または、ある一定期間、リーダーからの更新を受信できなかった。 このシナリオが表す書き込み処理のライフサイクルの間にネットワークから分断された ハード故障もしくはメンテナンスウインドウによりクラスタからノードが分断され、ノードをクラスタにrejoinさせるために起動した。 ノードが各パーティションに対してメンバーであるパーティションのリストを読み、パーティションのリーダーがリカバリプロセスを実行する。その時、ノードは「auto_add_new_nods」プロパティをチェックして、「New Node」処理のステップを実行する。 これはクラスタが。。。（元の文章が切れてて意味が不明）\nクライアントは標準的なSolrの更新形式を利用して書き込みできます。 書き込み処理はクラスタの任意のノードに送信されます。 ノードはハッシュ関数を利用して、どのパーティションに所属するか決めるためにrange-パーティションマッピングを使います。 ZooKeeperはシャードのリーダーを識別して、書き込み処理をそこに送ります。 SolrJはリーダーに対して書き込みを直接送信するための拡張がされています。\nリーダーはPartitionバージョンの操作を割り当て、そのトランザクションログの操作を書き込み、シャードに属する他のノードにドキュメントバージョンハッシュを転送します。 ノードはインデックスにドキュメントハッシュを書き込み、トランザクションログに操作を記録します。 リーダーは、min_writesの最小数のノード以上のノードが「OK」とレスポンスを返したら「OK」とレスポンスを返します。 クラスタプロパティのmin_writesは書き込みリクエスト時に指定することで、異なる値を指定できます。\nクラウドモードはコミット/ロールバック操作を明示的には行いません。 コミットは特定の間隔で（commit_within）リーダーによりオートコミットにより管理されます。 また、シャードの全メンバーのコミットはトリガーにより管理されます。 ノードが利用可能な最新バージョンはコミットの時点で記録されます。\nTransaction Log トランザクションログは2つのコミットの間にインデックスに対して実行された操作全てを記録したもの コミットはそれ以前に実行された操作の耐久性を保証するために、新しいトランザクションログを開始します。 同期は調整が可能です。例えば、flush vs fsynです。fsyncがデフォルトで、JVMクラッシュに対して保証できるが、電源異常の場合には保証できないが、速度的には早いです。 Recovery 次のトリガーにより復旧が可能です。\nBootstrap パーティション分割 クラスタの再構築 ノードは自身に「recovering」というステータスを設定して復旧を開始します。 このフェーズの間、ノードは読み込みリクエストを受けることができませんが、トランザくkションログに書きこまれるすべての新しい書き込みリクエストを受け取ります。 ノードは自身が持つインデックスのバージョンを調べて、パーティションの最新バージョンのリーダーに問い合わせます。 リーダーはシャード内の残りのノードと同期する前に実行されるべき操作の集合を返します（？？？）。\n最初にインデックスをコピーし、最新のノードにあるトランザクションログをリプレイします。 もし、インデックスのコピーが必要ならば、インデックスファイルをローカルにまずコピーし、その後トランザクションログをリプレイします。 トランザクションログのリプレイは通常の書き込みリクエストの流れと同じです。 この時、ノードは新しい書き込みを受け付けるかもしれません。その書き込みはインデックスに再生されるべきです。 ある時点でノードは最新のコミットポイントに追いつき、自身のステータスを「ready」にします。 この時点で、このノードは読み込みリクエストを処理できます。\nHandling Node Failures 一時的にネットワークが分断され、幾つかのノードとZooKeeperの間の通信が遮断されるかもしれません。 クラスタはデータの再構築（リバランシング）の前にしばらく待ちが発生します。\nLeader failure\nノードが故障し、もしそれがシャードのリーダだった場合、他のメンバーがリーダー選出のプロセスを開始します。 新しいリーダーが選出されるまで、このパーティションへの書き込みは受け付けられません。 この時、これはリーダー以外の故障ステップを処理します。（？？？）\nLeader failure\nシャードの一部に新しいノードが割り当てられる前にリーダーはmin_reaction_timeの間待ちます。 リーダーはCluster Lockを取得し、シャードの新規メンバーとしてノードを割り当てるためのノード-シャード割り当てアルゴリズムを使用します。 ZooKeeperのノード-\u0026gt;パーティションマッピングが更新され、Cluster Lockがリリースされます。 新しいノードはZooKeeperからノード-\u0026gt;パーティションマッピングを強制的にリロードされます。\nSplitting partitions 明示的なクラスタ管理コマンドもしくはSolrによる自動的な分割戦略（ストラテジ）はパーティションを分割することができます。 明示的な分割コマンド（split command）は対象となるパーティションを分割するために実行されます。\nパーティションXが100から199のハッシュの範囲を持つものとし、X（100から149）、Y（150～199）に分割するとします。 Xのリーダーは、XとYの新しい値の範囲をZooKeeperに分割アクションを記録します。 ノードはこの分割アクションもしくは新しいパーティションの存在については通知を受けません。（？？？）\nXのリーダはCluster Lockを取得し、パーティションY（アルゴリズムはto be determined）を割り当てるノードを決定し、新しいパーティションを知らせ、パーティション-\u0026gt;ノードマッピングを更新します。Xのリーダはノードのレスポンスを街、新しいパーティションがコマンドを受付可能な状態になったら次の処理を実行します。 Xのリーダーは分割が完了するまですべてのコミットを停止します。 Xのリーダーは最新のコミットポイント（バージョンVとする）のIndexReaderをオープンし、同じバージョンのIndexReaderもオープンするように命じます XのリーダーはYのリーダーに対してバージョンV以降のトランザクションログのうちハッシュ値の範囲が150から199のものを流します。 Yのリーダーはトランザクションログの#2（#3の間違い？）で送られたリクエストだけを記録します？？？ Xのリーダーはステップ#2で開いたIndexReaderに対してインデックスの分割を開始します。 #5で作成されたインデックスはYのリーダーに送られ、登録されます。 Yのリーダーは「recovery」プロセスを開始するように（シャードの）他のノード命令し、インデックスのトランザクションログを再生し始めます。 パーティションYのすべてのノードがバージョンVに到達したならば YのリーダーはXのリーダーに#2で作成されたReaderの上に、ハッシュの範囲が100から149だけに属しているドキュメントを抽出するようにするFilteredIndexReaderを準備するように頼みます。 Xのリーダーは#8aのリクエストが完了したのを検知したら、YのリーダーがCluster Lockを取得し、クラスタ全体の検索/登録リクエストの受信を開始するためにレンジ-\u0026gt;パーティションマッピングを変更します。 YのリーダーはXのリーダーに検索リクエストのために#8aで作成されたFilteredIndexReaderの利用開始を頼みます YのリーダーはXのリーダーに、ZooKeeperからレンジ-\u0026gt;パーティションマッピングを矯正リフレッシュするように頼みます。この時点で#3で開始されたトランザクションログの流しこみが停止されるのが保証されます。 Xのリーダーは自身のパーティションに存在するべきでないハッシュ値をもつドキュメントを削除し、最新のコミットポイントのsearcherを再度開きます。 この時点で分割は完全に終了し、Xのリーダーはcommit_withinパラメータによるコミットをレジュームします（？？？） Notes:\n分割操作が完了するまで、commit_withinパラメータによるパーティションの分割は実行されない #8b開始から#8c終了までの間の分散検索は一貫しない検索結果を帰す場合がある（例えば：検索結果が異なる） Cluster Re-balancing クラスタは明示的なクラスタ管理コマンドにより再構築（リバランシング）できる。\nTBD （to be determined）\nCluster Re-balancing TBD （to be determined）\nConfiguration solr_cluster.properties これはクラスタ内の全ノードにわたって適用される一般的なSolr設定ファイルとは別のプロパティファイルの集合である。\nreplication_factor：クラスタによって管理されるドキュメントのレプリカの数 min_writes：書き込み操作が成功になる前の最小の書き込み？？？？。これは書き込みごとに上書き設定可能 commit_within：検索に現れるまでの書き込み操作の最大回数 hash_function：ドキュメントのハッシュ値を計算するための関数の実装 max_hash_value：ハッシュ関数が出力することができる最大値。理論的には、この値はクラスタが保持できるパーティションの最大数でもある min_reaction_time：起動、停止の後に再配分/分割にかかる時間（？？） min_replica_for_reaction：レプリカノード数がこの値以下になったら、min_reaction_timeにならなくても分割が実行される。 auto_add_new_nodes：booleanフラグ。もしtrueなら新しいノードは自動的にパーティションからレプリカを読み込む。そうでない場合は新しいノードはクラスタに「idle」状態で登録される Cluster Admin Commands すべてのクラスタ管理コマンドはすべてのノードでパス（/cluster_admin）を与えることで実行できます。 全ノードは同じコマンドを受け付けることができ、振る舞いも同じものになるでしょう。 以下のコマンドはユーザが利用できるパブリックなコマンドです。\ninit_cluster：（パラメータ：パーティション）このコマンドはノードの集合の初期化後に実施されます。このコマンドが実行されるまで、クラスタは読み込み/書き込みコマンドを受け付けません。 split_partition：（パラメータ：パーティション（任意））パーティションを2つに分割します。もしパーティションパラメータが指定されない場合は、ドキュメント数が最大の add_idle_nodes：このコマンドはauto_add_new_nodes=falseの場合に利用できます。このコマンドはクラスタに対して「idle」状態のすべてのノードを追加するトリガーとなります。 move_partition：（パラメータ：パーティション、from、to）fromのノードからtoの別のノードに引数で指定されたパーティションを移動します。 command_status：（パラメータ：completion_id（任意））上記コマンドはすべて非同期で実行され、completion_idを返します。このコマンドは特定の実行中のコマンドもしくは全ての実行中のコマンドの状態を表示するために利用できます。 status：（パラメータ：パーティション（任意））パーティションのリストを表示し各パーティションの次の情報を表示します。 リーダーノード ノードのリスト ドキュメント数 平均読み込み回数（reads/sec） 平均書き込み回数（writes/sec） 平均読み込み時間（time/read） 平均書き込み時間（time/write） Migrating from Solr to SolrCloud クラウドに移行するときに幾つかの特徴は不要かもしれないし、サポートされないかもしれません。 既存の（クラウドでない）バージョンでのすべての特徴をSolrCloudでサポートし続けなければなりません。\nレプリケーション：これは必要ありません。 CoreAdminコマンド：明示的なコアの操作は許可されません。内部にコアがあるかもしれないが、暗黙的に管理されるでしょう 複数スキーマのサポート？：単純化のため、ver1.0ではサポートしないかもしれない solr.xml：SolrCloudでほんとに必要？ Alternative to a Cluster Lock リーダーを選出する常設の調停ノード（masterはインデックスレプリケーションで利用している用語なので、「調停」とする）を持つほうが単純かもしれません。 「truth」状態をZookeeperの状態としてみなすような次のパターンでは、将来の柔軟性（クラスタを制御するためのZookeeperの状態を直接変更するような外部管理ツールのような）を考慮に入れることができます。 （毎回ロックを取得するよりも）調停ノードを持つことにより、よりスケーラブルになるかもしれません。 特定条件下でのみCluster Lockを利用するハイブリッドも意味があるでしょう。\nSingle Node Simplest Use Case 単一ノードでスタートして、ドキュメントをインデックス登録できないといけません。 また、あとで、クラスタに2番目のノードを追加できないと行けません。\n1つのノードから開始し、最初にZookeeperに設定ファイルをアップロードし、shard1にノードを作成＋登録します。 他の情報がない状態で設定が作成され、1つのシャードのシステムとなります。 いくつかのドキュメントをインデックスします 他のノードが起動し、「まだ割り当てられていない場合、レプリカの最小の数をもつshardに割り当てられ、「recovery」プロセスを開始します」というパラメータを受け取ります。 * 出来れば、同一ホスト上に同じシャードはコピーしない * この時点の後で、ノードが停止したら、再起動し、同じ役割が再開されるべきです。（Zookeeperでそれ自身であると判別されれば） 原文はこちらからです。\nBoot Strapping Cluster Startup A node is started pointing to a Zookeeper host and port. The first node in the cluster may be started with cluster configuration properties and the schema/config files for the cluster. The first node would upload the configuration into zookeeper and bootstrap the cluster. The cluster is deemed to be in the “bootstrap” state. In this state, the node -\u0026gt; partition mapping is not computed and the cluster does not accept any read/write requests except for clusteradmin commands.\nAfter the initial set of nodes in the cluster have started up, a clusteradmin command (TBD description) is issued by the administrator. This command accepts an integer “partitions” parameter and it performs the following steps:\nAcquire the Cluster Lock Allocate the “partitions” number of partitions Acquires nodes for each partition Updates the node -\u0026gt; partition mapping in ZooKeeper Release the Cluster Lock Informs all nodes to force update their own node -\u0026gt; partition mapping from ZooKeeper The Cluster Lock is acquired A suitable source (node, partition) tuple is chosen: The list of available partitions are scanned to find partitions which has less then “replication_factor” number of nodes. In case of tie, the partition with the least number of nodes is selected. In case of another tie, a random partition is chosen. If all partitions have enough replicas, the nodes are scanned to find one which has most number of partitions. In case of tie, of all the partitions in such nodes, the one which has the most number of documents is chosen. In case of tie, a random partition on a random node is chosen. If moving the chosen (node, partition) tuple to the current node will decrease the maximum number of partition:node ratio of the cluster, the chosen tuple is returned.Otherwise, no (node, partition) is chosen and the algorithm terminates The node -\u0026gt; partition mapping is updated in ZooKeeper The node status in ZooKeeper is updated to “recovery” state The Cluster Lock is released A “recovery” is initiated against the leader of the chosen partition After the recovery is complete, the Cluster Lock is acquired again The source (node, partition) is removed from the node -\u0026gt; partition map in ZooKeeper The Cluster Lock is released The source node is instructed to force refresh the node -\u0026gt; partition map from ZooKeeper Goto step #1 Node Restart A node restart can mean one of the following things:\nThe JVM crashed and was manually or automatically restarted The node was in a temporary network partition and either could not reach ZooKeeper (and was supposed to be dead) or could not receive updates from the leader for a period of time. A node restart ine node failure. Lifecycle of a Write Operation this scenario signifies the removal of the network partition. A hardware failure or maintenance window caused the removal of the node from the cluster and the node has been started again to rejoin the cluster. The node reads the list of partitions for which it is a member and for each partition, starts a recovery process from each partition’s leader respectively. Then, the node follows the steps in the New Node section without checking for the auto_add_new_nodes property. This ensures that the cluster recovers from the imbalance created by th\nWrites are performed by clients using the standard Solr update formats. A write operation can be sent to any node in the cluster. The node uses the hash_function , and the Range-Partition mapping to identify the partition where the doc belongs to. A zookeeper lookup is performed to identify the leader of the shard and the operation is forwarded there. A SolrJ enhancement may enable it to send the write directly to the leader\nThe leader assigns the operation a Partition Version and writes the operation to its transaction log and forwards the document + version + hash to other nodes belonging to the shard. The nodes write the document + hash to the index and record the operation in the transaction log. The leader responds with an ‘OK’ if at least min_writes number of nodes respond with ‘OK’. The min_writes in the cluster properties can be overridden by specifying it in the write request.\nThe cloud mode would not offer any explicit commit/rollback operations. The commits are managed by auto-commits at intervals (commit_within) by the leader and triggers a commit on all members on the shard. The latest version available to a node is recorded with the commit point.\nTransaction Log A transaction log records all operations performed on an Index between two commits Each commit starts a new transaction log because a commit guarantees durability of operations performed before it The sync can be tunable e.g. flush vs fsync by default can protect against JVM crashes but not against power failure and can be much faster Recovery A recovery can be triggered during:\nBootstrap Partition splits Cluster re-balancing The node starts by setting its status as ‘recovering’. During this phase, the node will not receive any read requests but it will receive all new write requests which shall be written to a separate transaction log. The node looks up the version of index it has and queries the ‘leader’ for the latest version of the partition. The leader responds with the set of operations to be performed before the node can be in sync with the rest of the nodes in the shard.\nThis may involve copying the index first and replaying the transaction log depending on where the node is w.r.t the state of the art. If an index copy is required, the index files are replicated first to the local index and then the transaction logs are replayed. The replay of transaction log is nothing but a stream of regular write requests. During this time, the node may have accumulated new writes, which should then be played back on the index. The moment the node catches up with the latest commit point, it marks itself as “ready”. At this point, read requests can be handled by the node.\nHandling Node Failures There may be temporary network partitions between some nodes or between a node and ZooKeeper. The cluster should wait for some time before re-balancing data.\nLeader failure\nIf node fails and if it is a leader of any of the shards, the other members will initiate a leader election process. Writes to this partition are not accepted until the new leader is elected. Then it follows the steps in non-leader failure\nNon-Leader failure\nThe leader would wait for the min_reaction_time before identifying a new node to be a part of the shard. The leader acquires the Cluster Lock and uses the node-shard assignment algorithm to identify a node as the new member of the shard. The node -\u0026gt; partition mapping is updated in ZooKeeper and the cluster lock is released. The new node is then instructed to force reload the node -\u0026gt; partition mapping from ZooKeeper.\nSplitting partitions A partition can be split either by an explicit cluster admin command or automatically by splitting strategies provided by Solr. An explicit split command may give specify target partition(s) for split.\nAssume the partition ‘X’ with hash range 100 - 199 is identified to be split into X (100 - 149) and a new partition Y (150 - 199). The leader of X records the split action in ZooKeeper with the new desired range values of X as well as Y. No nodes are notified of this split action or the existence of the new partition.\nThe leader of X, acquires the Cluster Lock and identifies nodes which can be assigned to partition Y (algorithm TBD) and informs them of the new partition and updates the partition -\u0026gt; node mapping. The leader of X waits for the nodes to respond and once it determines that the new partition is ready to accept commands, it proceeds as follows: The leader of X suspends all commits until the split is complete. The leader of X opens an IndexReader on the latest commit point (say version V) and instructs its peers to do the same. The leader of X starts streaming the transaction log after version V for the hash range 150 - 199 to the leader of Y. The leader of Y records the requests sent in #2 in its transaction log only i.e. it is not played on the index. The leader of X initiates an index split on the IndexReader opened in step #2. The index created in #5 is sent to the leader of Y and is installed. The leader of Y instructs its peers to start recovery process. At the same time, it starts playing its transaction log on the index. Once all peers of partition Y have reached at least version V: The leader of Y asks the leader of X to prepare a FilteredIndexReader on top of the reader created in step #2 which will have documents belonging to hash range 100 - 149 only. Once the leader of X acknowledges the completion of request in #8a, the leader of Y acquires the Cluster Lock and modifies the range -\u0026gt; partition mapping to start receiving regular search/write requests from the whole cluster. The leader of Y asks leader of X to start using the FilteredIndexReader created in #8a for search requests. The leader of Y asks leader of X to force refresh the range -\u0026gt; partition mapping from ZooKeeper. At this point, it is guaranteed that the transaction log streaming which started in #3 will be stopped. The leader of X will delete all documents with hash values not belonging to its partitions, commits and re-opens the searcher on the latest commit point. At this point, the split is considered complete and leader of X resumes commits according to the commit_within parameters. Notes:\nThe partition being split does not honor commit_within parameter until the split operation completes Any distributed search operation performed starting at the time of #8b and till the end of #8c can return inconsistent results i.e. the number of search results may be wrong. Cluster Re-balancing The cluster can be rebalanced by an explicit cluster admin command.\nTBD\nMonitoring TBD\nConfiguration solr_cluster.properties This are the set of properties which are outside of the regular Solr configuration and is applicable across all nodes in the cluster:\nreplication_factor : The number of replicas of a doc maintained by the cluster min_writes : Minimum no:of successful writes before the write operation is signaled as successful . This may me overridden on a per write basis commit_within : This is the max time within which write operation is visible in a search hash_function : The implementation which computes the hash of a given doc max_hash_value : The maximum value that a hash_function can output. Theoretically, this is also the maximum number of partitions the cluster can ever have min_reaction_time : The time before any reallocation/splitting is done after a node comes up or goes down (in secs) min_replica_for_reaction : If the number of replica nodes go below this threshold the splitting is triggered even if the min_reaction_time is not met auto_add_new_nodes : A Boolean flag. If true, new nodes are automatically used as read replicas to existing partitions, otherwise, new nodes sit idle until the cluster needs them. Cluster Admin Commands All cluster admin commands run on all nodes at a given path (say /cluster_admin). All nodes are capable of accepting the same commands and the behavior would be same. These are the public commands which a user can use to manage a cluster:\ninit_cluster : (params : partition) This command is issued after the initial set of nodes are started. Till this command is issued, the cluster would not accept any read/write commands split_partition : (params : partitionoptional). The partition is split into two halves. If the partition parameter is not supplied, the partition with the largest number of documents is identified as the candidate. add_idle_nodes : This can be used if auto_add_new_nodes=false. This command triggers the addition of all ‘idle’ nodes to the cluster. move_partition : (params : partition, from, to). Move the given partition from a given node from to another node command_status :(params : completion_idoptional) . All the above commands are asynchronous and returns with a completion_id . This command can be used to know the status of a particular running command or all the current running commands status : (params : partitionoptional) Shows the list of partitions and for each partition, the following info is provided leader node nodes list doc count average reads/sec average writes/sec average time/read average time/write Migrating from Solr to SolrCloud A few features may be redundant or not supported when we move to cloud such as. We should continue to support the non cloud version which supports all the existing features\nReplication. This feature is not required anymore CoreAdmin commands. Explicit manipulation of cores will not be allowed. Though cores may exist internally and they meay be managed implicitly Multiple schema support ? Should we just remove it from ver 1.0 for simplicity? solr.xml . Is there a need at all for this in the cloud mode? Alternative to a Cluster Lock It may be simpler to have a coordinator node (we avoid the term master since that is associated with traditional index replication) that is established via leader election. Following a pattern of treating the zookeeper state as the \u0026ldquo;truth\u0026rdquo; and having nodes react to changes in that state allow for more future flexibility (such as allowing an external management tool directly change the zookeeper state to control the cluster). Having a coordinator (as opposed to grabbing a lock every time) can be more scalable too. A hybrid model where a cluster lock is used only in certain circumstances can also make sense.\nSingle Node Simplest Use Case We should be able to easily start up a single node and start indexing documents. At a later point in time, we should be able to start up a second node and have it join the cluster.\nstart up a single node, upload it\u0026rsquo;s configuration (the first time) to zookeeper, and create+assign the node to shard1. in the absence of other information when the config is created, a single shard system is assumed index some documents start up another node and pass it a parameter that says \u0026ldquo;if you are not already assigned, assign yourself to any shard that has the lowest number of replicas and start recovery process\u0026rdquo; avoid replicating a shard on the same host if possible after this point, one should be able to kill the node and start it up again and have it resume the same role (since it should see itself in zookeeper)\n","date":1317720720,"dir":"post/2011/","id":"7052598d2355984237d126afea2f6e88","lang":"ja","lastmod":1317720720,"permalink":"https://blog.johtani.info/blog/2011/10/04/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE2/","publishdate":"2011-10-04T18:32:00+09:00","summary":"遅くなりましたが、続きです。 さらに英語力のなさを痛感して凹んでいるところですが、何かの役に立てばと恥を晒すところです。。。 一応、訳してみたの","tags":["solr"],"title":"New SolrCloud Designの翻訳（その2）(Jugemより移植)"},{"contents":"ちょっと興味があるので、訳してみました。（Wikiのページはこちら） 更新されているようなので、もとの文章も残しておきます。（ページ下部の続きはこちら部分以降） 全部訳そうと思ったのですが、終わらなかったので、まずは前半部分です。まだ、訳しただけで理解できてない。。。 （英語力のなさをさらけ出してしまうのですが、これも修行です。。。おかしいところはツッコミを。）\nWhat is SolrCloud? Solrクラウドはクラウドでの検索サービスとしてのSolrを管理、運用するための既存のSolrを拡張するものです。\n用語集 Cluster：クラスタは1単位として管理されるSolrノードの集合です。クラスタ全体で単一のschema、solrconfigをもたないといけません。 Node：ひとつのJVMインスタンスで起動しているSolrのこと Partition：パーティションはドキュメント集合全体のサブセット（部分集合）のことです。パーティションは部分集合のドキュメントが単一のインデックスに含まれるような形で作られます。 Shard：パーティションはn（＝replication factor）個のノードに保存される必要があります。このn個のノードすべてでひとつのshardです。1つのノードはいくつかのshardの一部にで有る場合があります。 Leader：各Shardは1つのリーダとなるノードを持っています。パーティションに登録されたドキュメントリーダーからコピーされます Replication Factor：クラスタによって保持されるレプリカの最小限の数 Transaction Log：各ノードによって保持される書き込み処理の追記ログ Partition version：これは各shardのリーダーが持っているカウンターで、書き込み処理ごとに増加し、レプリカに送られます。 Cluster Lock：これはrange（※後述されているハッシュ値の範囲のことか？）-\u0026gt;パーティションもしくはパーティション-\u0026gt;ノードのマッピングを変更するために取得しなければいけないグローバルなロックのことです。 ※用語だけだと関係がわかりづらかったので、図を書いてみました。\nドキュメントの集合とパーティションについての考え方\nクラスタ、ノード、シャードの考え方。\n処理原則 任意の処理はクラスタにある任意のノードに実行可能です。 リカバリできないSPOFはありません。 クラスタは伸縮自在（elastic）でなければならない 書き込みが失われないこと（耐久性）を保証する 書き込み順序が保証されなければならない 2つのクライアントが2つの「A」というドキュメントを同時に送信してきた場合、すべてのレプリカで一貫してどちらか一方が保存されなければならない。 クラスタの設定は中央管理されなければならない。また、クラスタのどのノードからもクラスタ設定が更新できます。 読み込み（検索）の自動的なフェイルオーバー 書き込み（インデクシング）の自動的なフェイルオーバー ノードの故障が発生しても自動的にrepcation factorの数は守られます。（故障したら動的にレプリカを再配置？） Zookeeper ZooKeeperクラスタは次のために使用されます。\nクラスタ設定の集中管理 分散同期に必要な操作のコーディネータ クラスタ構成を保存するためのシステム Partitioning クラスタは固定されたmax_hash_value＝「N」が設定されます。 max_hash_valueは1000のような大きな値が設定されます。\nhash = hash_function(doc.getKey()) % N ハッシュ値の範囲がパーティションに割り当てられ、ZooKeeperに保存されます。 次の例のような形で、パーティションに対して範囲が設定されます。\nrange : partition ------ ---------- 0 - 99 : 1 100-199: 2 200-299: 3 ハッシュはドキュメントにインデックスフィールドとして追加され、変更されない値です。 これは、インデックスを分割するときにも利用します。\nハッシュ関数はプラガブルです。これはドキュメントを受け取り、一貫した正整数ハッシュ値を返します。デフォルトのハッシュ関数として、必須でかつ変更されないフィールド（デフォルトはユニークキーフィールド）からハッシュ値を計算する関数が提供されます。\nUsing full hash range max_hash_valueは必ずしも必要ではありません。各shardはいずれにしろハッシュ値の範囲持っているので、完全な32 bitsハッシュを使うこともできます。 設定可能なmax_hash_valueを利用しないで、クライアントからの値をもとにハッシュ値を作ることができます。 例えば、電子メールの検索アプリでは次のようにハッシュ関数を作ることができます。\n(hash(user_id)\u0026lt;\u0026lt;24) | (hash(message_id)\u0026gt;\u0026gt;\u0026gt;8) ユーザIDから8bitのハッシュコードの先頭8ビットを利用することで、任意のユーザのメールがクラスタの同じ256番目（のノード？）にあるのを保証します。検索時はこの情報をもとにクラスタのその部分への問い合わせだけで情報が得られます。\nおそらく、私たちは最大値から最小値をカバーする範囲を表現するのにハッシュ空間を輪（固定のハッシュではなく）とみなしたいです。（？？？円状のハッシュ空間とすることで、クラスタ内のノード数の増減に耐えられるようにするよということかな？）\nshard naming シャードからハッシュ値の範囲へのマッピングを別々に管理するよりも、ハッシュコードによりパーティションを構成するときに実際にはハッシュの範囲をシャード名にします。 （シャード「1-1000」は1から1000の間のハッシュコードを持つドキュメントが含まれるという形）\n現時点では（コレクション1つに対してシングルコアの1Solrサーバと仮定して）solrコア名はコレクション名をつけるようになっています。 同一コレクションのためのマルチコアに対してのいい命名規則をつけるという課題が残っています。 （※コレクションに対する説明がここまでないかな？）\nShard Assignment ノード-\u0026gt;パーティションのマッピングはZooKeeperにあるCluster Lockを取得したノードによってのみ変更が可能です。 ノードの追加時に、まず、Cluster Lockを取得し、次にそれがどのパーティションを取得できるかを識別します。\nNode to a shard assignment 新しいノードを探しているノードはまずCluster Lockを取得しないといけません。 第一に、リーダーはシャードを決めます。 シャードが持つ、すべての利用可能なノード数で最小の値を持つノードが選び出されます。 もし、同値ならランダムにノードを選びます。\n原文はこちらからです。\nNew SolrCloud Design (Work in progress)\nWhat is SolrCloud? SolrCloud is an enhancement to the existing Solr to manage and operate Solr as a search service in a cloud.\nGlossary Cluster : Cluster is a set of Solr nodes managed as a single unit. The entire cluster must have a single schema and solrconfig Node : A JVM instance running Solr Partition : A partition is a subset of the entire document collection. A partition is created in such a way that all its documents can be contained in a single index. Shard : A Partition needs to be stored in multiple nodes as specified by the replication factor. All these nodes collectively form a shard. A node may be a part of multiple shards Leader : Each Shard has one node identified as its leader. All the writes for documents belonging to a partition should be routed through the leader. Replication Factor : Minimum number of copies of a document maintained by the cluster Transaction Log : An append-only log of write operations maintained by each node Partition version : This is a counter maintained with the leader of each shard and incremented on each write operation and sent to the peers Cluster Lock : This is a global lock which must be acquired in order to change the range -\u0026gt; partition or the partition -\u0026gt; node mappings. Guiding Principles Any operation can be invoked on any node in the cluster. No non-recoverable single point of failures Cluster should be elastic Writes must never be lost i.e. durability is guaranteed Order of writes should be preserved If two clients send document \u0026ldquo;A\u0026rdquo; to two different replicas at the same time, one should consistently \u0026ldquo;win\u0026rdquo; on all replicas. Cluster configuration should be managed centrally and can be updated through any node in the cluster. No per node configuration other than local values such as the port, index/logs storage locations should be required Automatic failover of reads Automatic failover of writes Automatically honour the replication factor in the event of a node failure Zookeeper A ZooKeeper cluster is used as:\nThe central configuration store for the cluster A co-ordinator for operations requiring distributed synchronization The system-of-record for cluster topology Partitioning The cluster is configured with a fixed max_hash_value (which is set to a fairly large value, say 1000) ‘N’. Each document’s hash is calculated as:\nhash = hash_function(doc.getKey()) % N Ranges of hash values are assigned to partitions and stored in Zookeeper. For example we may have a range to partition mapping as follows\nrange : partition ------ ---------- 0 - 99 : 1 100-199: 2 200-299: 3 The hash is added as an indexed field in the doc and it is immutable. This may also be used during an index split\nThe hash function is pluggable. It can accept a document and return a consistent \u0026amp; positive integer hash value. The system provides a default hash function which uses the content of a configured, required \u0026amp; immutable field (default is unique_key field) to calculate hash values.\nUsing full hash range Alternatively, there need not be any max_hash_value - the full 32 bits of the hash can be used since each shard will have a range of hash values anyway. Avoiding a configurable max_hash_value makes things easier on clients wanting related hash values next to each other. For example, in an email search application, one could construct a hashcode as follows:\n(hash(user_id)\u0026lt;\u0026lt;24) | (hash(message_id)\u0026gt;\u0026gt;\u0026gt;8) By deriving the top 8 bits of the hashcode from the user_id, it guarantees that any users emails are in the same 256th portion of the cluster. At search time, this information can be used to only query that portion of the cluster.\nWe probably also want to view the hash space as a ring (as is done with consistent hashing) in order to express ranges that wrap (cross from the maximum value to the minimum value).\nshard naming When partitioning is by hash code, rather than maintaining a separate mapping from shard to hash range, the shard name could actually be the hash range (i.e. shard \u0026ldquo;1-1000\u0026rdquo; would contain docs with a hashcode between 1 and 1000).\nThe current convention for solr-core naming is that it match the collection name (assuming a single core in a solr server for the collection). We still need a good naming scheme for when there are multiple cores for the same collection.\nShard Assignment The node -\u0026gt; partition mapping can only be changed by a node which has acquired the Cluster Lock in ZooKeeper. So when a node comes up, it first attempts to acquire the cluster lock, waits for it to be acquired and then identifies the partition to which it can subscribe to.\nNode to a shard assignment The node which is trying to find a new node should acquire the cluster lock first. First of all the leader is identified for the shard. Out of the all the available nodes, the node with the least number of shards is selected. If there is a tie, the node which is a leader to the least number of shard is chosen. If there is a tie, a random node is chosen.\n","date":1317210300,"dir":"post/2011/","id":"927612b57ba01ca878b2d7edce52a563","lang":"ja","lastmod":1317210300,"permalink":"https://blog.johtani.info/blog/2011/09/28/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE%EF%BC%91/","publishdate":"2011-09-28T20:45:00+09:00","summary":"ちょっと興味があるので、訳してみました。（Wikiのページはこちら） 更新されているようなので、もとの文章も残しておきます。（ページ下部の続き","tags":["solr"],"title":"New SolrCloud Designの翻訳（その１）(Jugemより移植)"},{"contents":"Hadoop Conference Japan 2011 Fallに行ってきました。 まずは、ユーザ会の方々、運営の方々、発表された方々お疲れ様でした。こんな機会を用意していただき、ありがとうございます。 Hadoopは昨年触っていたのですが、最近は縁がなくなってしまいました。 ただ、触っていたときに面白かったので参加してきました。 ということで、今回も自分用にメモを取ったので。（今回は英語のヒアリングがあって、メモがひどい事になってます。。。） いつものことながら、おかしいところとかあれば、ツッコミなどフィードバックをもらえると嬉しいです。\n場所：ベルサール汐留 日時：2011/09/26 10:00～18:00＋懇親会：18:30～21:00\nオープニングトーク：濱野、太田 参加者：1100名超！（実際は800名弱？） Hadoopの経験：利用経験なしな方が580名 カンファレンスの認知：Twitterよりも知人、その他が多かった。 会場提供：リクルート様 リクルート米谷様より一言。 Question VOTE！！サイトを用意。 http://mit.recruit.co.jpにて情報提供。 ※残念ながら地下だったため、E-mobileにつながらず、あと、電源確保が難しかったのでMBAをスタンドアロンにしてメモをとっていたので、 QAサイトにはアクセスしませんでした。もう少し活用したかったんですが、携帯でTwitterを追っかけるので精一杯。。。\n◎The role of the Distribution in the Apache Hadoop Ecosystem：Todd Lipcon（Cloudera）\n1.Introduction Todd Lipcon：Clouderaエンジニア Hadoop とHBaseのコミッター 2. Hadoop Overview HDFS＋MapReduceの説明 Hadoopの生まれてきた経緯　様々な形式のデータが大量に存在し、データのハンドリングが難しくなってきたため。 Flexible, Scalable Solutionが必要に。 Hadoop の2つのユースケース 1.Advanced Analytics SNS（Web）、Content Optimization（Media）、Network Analytics（Telco）、 2.Data Processing Clickstream SessionizationEngagement 3.Cloudera Overview ClouderaCustomers ・Large National Bank ・Web-Based Media click-through dataや広告のログ ・Wireless Telecom 大量のデータ 目標：大量データからビジネスを引き出すこと。 Cloudera Japan：トレーニング。NTTDと協業して開発支援も 4.CDH Overview 100% pure Apache Hadoop SCM Epress(Service \u0026amp;amp; Configuration Manager) Free なぜ、CDHを利用するの？ Linuxを利用する場合にLinux.orgからはダウンロードしないように、Hadoopも同じように提供したい。 RedHat系を目指しているみたい。 様々なパッケージの依存関係が混乱を招く。 CDHならテストが終わってるものが提供されてる。 ※SolrはLWEがLucidWorksEnterpriseがこれを目指してるのか。 5.Cloudera Enterprise Activity Monitor：Jobのパフォーマンスをリアルタイムに監視 SCM：設定のvalidateや管理。 Resource Manager：。。。 6.まとめ CDH：簡単にHadopが使えるよ。 SCM Express：簡単にHadoopの設定ができてフリーだよ Cloudera：Hadoopに関していろいろサポートしているよ。（Enterprise用ソフトやトレーニングなど） ◎About Hortonworks：Owen O\u0026rsquo;Malley（Hortonworks）\n1.About Hortonworks 2011/2月に設立 22人のYahooからのアーキテクトとコミッタにより設立 2.Credentials Yahooのクラスタの経験者がいますよ。 OSSに長けた人達によるチームです。 3.What is Apache Hadoop Hadoopの説明（別の側面が幾つかあり。） Commodity Hardwareで動く 簡単にプログラムできる 典型的なアプリケーションのタグクラウド（あとでちゃんと見る） HadoopのほとんどのソースコードはYahooで作られてるよ。 Clouderaとか目じゃないよ 4.Hadoop @ Yahoo! 各種サーバや規模など Science Hadoop Cluster \u0026lt;-\u0026amp;gt; Production Hadoop Cluster \u0026lt;-\u0026amp;gt; Serving Systems という構成で、いろいろやってます。 5.Hadoop Market ビジネス：ビッグデータを扱って色々やろうね 金融系：IT系のコストをOSSとHadoopで削減 技術系： 6.Hortonworks Strategy Hadoopを利用、管理しやすくするためのいろんなことをコミュニティに還元しますよ。 性能などについても同様。 トレーニングやテクニカルサポートやりますよ。 QA： Q：42Kのノードの管理ツールはなに？ A：手で管理してます。 Q：社名の由来は？ A：童話でHortonという名前の象の話がある。 Q：CDHはおすすめ？それともほかのものがいい？ A：※聞き取れず。。。 Q：500万Query/月はアドホックQueryもあるの？ A：幾つかのクラスタに分けて使ってる。アドホックは不明 ◎How Hadoop needs to evolve and integrate into the enterprise：Ted Dunning（MapR）\n・Quick History ・英語わからない身には辛い。。。 Zookeeperの人らしい。 Narrow Foundations HDFSとNASの間には大きな壁があり、大きなデータを移動するのはコストが掛かる。 Broad Foundation HDFSの代わりにNAS、RDBMSの下に位置するMapRを用意 ど、どんな仕組み？-\u0026amp;gt;テクニカルセッションで。 QA： Q：MapRはOSSにしないのか？ A：MapRで開発したものはApacheに還元はしますが、OSSにはしないよ。フリー版は提供するかも ここで昼食。午前中からいた人にはランチボックスが提供されました。 午後からはコミュニティトラックとテクニカルトラックの2トラックがありましたが、LTが聞きたかった（それよりも英語が辛かった？）のでコミュニティトラックのど真ん中、最前列に入り浸りました。 ★コミュニティトラック ◎Elastic MapReduce Amazonが提供するHadoop：大谷晋平（Amazon）\n・Amazonとは Eコマース 流通 AWS の3つのサービス ・AWS Low-level、High-level、Cross Service、Tools to access services、アプリケーション 色々あるなー ・Bigデータが大変な理由 ケタ違いのデータ量、異なる形式データ、即時性 現状システムはスケールしない ビジネスとして成立する？ 成立するならすぐスケールだめならすぐ縮小 ・Hadoopとは？ これまでのお話。 スケーラブル、低価格なハード 誰でも入手可能で、実績多数。 ・Amazon EMR AWS上でスケーラブルなインフラ上に構築が可能 オンプレミスからMapReduceアプリを移行可能なため、分析、解析に集中可能 S3からデータIN/OUTするので、データ欠損がない。 Hadoopそのままではチューニングやクラスタサイズ見積もりも難しい ＝＞クラスタサイズを動的に拡張伸縮可能。パフォーマンス最適化もできるよ。 0.18、0.20が利用可能。 EMRはHDFSとジョブ（タスク）トラッカーを別構成にしている。 EC2上にMaster、Core、タスクノードを展開 S3にデータを格納 SimpleDB（KVS）を利用 ・EMR注目機能 ジョブフローの高速化 ジョブの再起動無しにコスト/パフォーマンス比を変更可能。 タスクノードを動的に増やせる 柔軟なデータウェアハウスクラスタ タスクノードをバッチ実行時にのみ増やせる。 ※増減できるのはタスクノード Coreノードは増加のみ EMR＋Spotインスタンスの活用 コスト削減効果が非常に高い AWSの余剰リソースをリーズナブルに提供（Amazon的にもウハハだ） ・その他の機能 東海岸だけだけど、スパコンレベルのインスタンスも利用可能 AWS上での最適化設計など ※ちょっと時間足りなくなってきたｗ ・EMRの事例 1.Razorfish ROAS（広告費用対効果）を500%改善（すげー） 2.So-net ・EMR都市伝説 物理vs仮想 そりゃ、物理が速いよ EMRの柔軟性・拡張性がセールスポイント ビッグデータは成功/失敗が読めないのもあるので、 インフラに投資する部分を少なくできるよ。 オンプレミスが安い？ いやいや、HWの購入から設定など時間かかる。 ・Beyond Hadoop HadoopのIn/Out含めてスケーラブル、フレキシビリティが重要 運用管理の仕組みも重要 まだまだやってくよ。 QA Q：EMRは複数サービスから構築してるけど、一部がダウンするとどーなる？（例：SimpleDBが落ちてるとか） A：ジョブはReRunしてもらうか、SimpleDBの状態をみてリカバリをしてもらう。 Q：上記にともない、SLAの計算は？ A：SLAはEMRについては定義できてない。S3などはリージョン跨いで Q：S3のセキュリティが心配だが、どう考えてるか？ A：いままで脆弱性を晒してデータをロストしてない。 ユーザコントロールなどもできる。基本的には問題ない Q：EMRでS3を使う＝Hadoopのローカリティの利点が失われるのでは？ A：オーバヘッドはあるが、実際のデータはS3で守られているので、HDFSが飛んでも大丈夫。 Q：S3からのコピーオーバヘッドはどーなるか？ A：Single5で少しずつor分割して全部送るも可能 Q：EMRはマルチテナントだけど他のユーザのネットワークの影響を受けないの？ A：マルチテナントだと起こる可能性がある。 M1（？）だと内部ネットワークは専有可能らしい。 ◎LT\n・Hadoop and Subsystems in livedoor @tagomoris ピーク時に15Gbps。 10ノード（36コア） CDH3b2を利用 データマイニングではなく、ログからレポーティングをするのに利用している。 hadoop streaming + Hiveで実施 580G/dayが96サーバから来る ScribeにてHadoop Streaming（Perl）でper hourでHiveにload scribelineをWebサーバに入れててログ配送してくれる。 **　・Lightweight　@stanaka（はてなCTO：田中慎司さん）**\nEMR以前 自前20台クラスタ ジョブがあふれてきた ナマMapReduceを利用 PerlでMapper/Reducerを記述（Hadoop Streaming） EMR導入 リソース増やせて便利！ 必要な台数に伸縮可能 問題点： S3にアップしないとダメ ＝＞ログデータをS3に展開するlog2s3.plを作成。毎時実行。 起動、ジョブキック、結果改修どーする？ ＝＞Net::Amazon::EMR::Wrapperを作成した。 クラスタ起動、ジョブキック、クラスタ停止などできる 作ってみて思ったこと よかったところ： Perlでかける。Cronで実行可能。HiveQL便利。 悪かったところ。 途中で失敗してクラスタ起動しっぱなしとかがある。S3にデータを展開が大変。複雑な計算がきつい。 慣れてないエンジニアにも触れるようにしたい ＝＞Perlで書けるようにした？。 **　・HBaseでグラフ構造を扱う（開発中）：アメーバ鈴木**\n自己紹介@brfrnl69 アメーバのソーシャルグラフ 基本はMySQL マスタ分散が難しい、シャーディング管理が面倒 ＝＞HBaseでやってみるか。 目的　グラフデータに対して高速に更新追加したい。 隣接ノードが取れればいい（これを高速化したい） オンライン処理したい 運用コストの削減したい。 Not目的 マルチホップはどうでもいい。 アーキテクチャ JavaでGatewayつくってみる。 ・Large-Scale Graph Processing：井上さん（@doryokujin）さん Map/Reduceではグラフ計算だめ？ Vertex基本だとShuffleに問題ががが。 BSPの紹介 Bulk Synchronous Processing Google Pregel SSSP：MapReduce Model すごい計算時間が掛かりそう。MRの組み合わせが何回回ることやら。 枝が少ないとこっちのほうがいいのか？ SSSP：PregelModel シンプルなアルゴリズム Pregel使えるのあるの？ Hama GoldenOrb Giraph YERN？YARN？ ◎リクルート式Hadoopの使い方：石川（リクルート）\n@ground_beetle ・導入の課題点 バッチ処理時間対策のため。 ＝＞実は入れたかっただけｗ ・導入の障壁 現行システムへの影響＋開発工数 ＝＞これへの対処がこのあとの話 ・課題の克服と活用シーン Azkaban知らなかった。ジョブスケジューリングツール Hadoop単体ではなく、エコシステム（関連ツール）が魅力 ・活用シーン：Hive SQLゆーがざ多く、HiveQLがSQLライクのため導入が簡単に！ 既存機能のリプレイス系案件に活躍（低工数＋簡単に高速化） とりあえず、Hive実装 ＝＞性能アップのためにMapReduceで書きなおし Hotpepperなどのアトリビューション分析に利用 ・活用シーン：Sqoop＋Hive RDBとHadoop連携のツール：Sqoop 現行システムの横にHadoopを配置でき、RDBMSの利点も利用しつつHiveも利用できるようになる。 （※気を付けないといけないけどねぇ。） ゼクシィで活用しようとしてるところ。 ・活用シーン：Mahout マイニング用ツール カーセンサーのレコメンド（同時に閲覧される車種） アソシエーション分析＋クラスタリング ・活用シーン：BIツールの導入 何度か導入しようとして失敗してます。。。 BIツールの前処理（クレンジングなど）にHadoopを活用 ・インフラリソースは？ 全部で118台。 最小のクラスタ構成はサーバ6台で構成してる ・Hadoopで複数処理を回す方法 ここまで紹介したものを入れてますよ。Hive、Sqoop、Solr。。。 ・Azkaban TomcatにWar配置で利用可能。 LinedInのチームにより作成 ※若干マシントラブルで中断 ・今後のHadoop導入 ログ基盤 分析エンジン・レコメンドエンジンとして バッチ処理短縮＝トライアンドエラーが簡単にできるようになる。＝色々な気づきが出てくる。 アジャイル的な解析が可能に。 ・開発サイクルの短縮ができるエコシステムでビジネスが回りだす。 ・今後の展開 MapRが気になってる。 マルチテナント対応ができてうはうはできそう。 EMCと共同して検証中 QA： Q：性能監視ツールの選別の理由は？ A：Zabbix、Cactiです。今から利用しようと思っている段階。 Q：CDH、GreenPlum、Apacheをそれぞれ利用してるけど、使い分けのシーンは？比較は？ A：CDH3u0です。GreenPlumは使ってないです。理由は言うとクビが飛ぶ可能性ががが。 Q：高度なデータ分析ができる技術者はどこからヘッドハントしてるの？ A：MITに別途分析チームが存在し、高度な分析をしてくれる。 Q：NameNodeの冗長化はどーやってんの？ A：象本と一緒DRBD＋HeartBeat Q：EMRの導入を検討してる？ A：今後、サーバ数が多くなると導入の検討をしていくと思う。 現時点は、運用ノウハウも入手するために社内で使ってる。 EMRになるかRCloud（リクルート社内クラウド）になるかは不明。 Q：HBaseを利用してる？ A：してないです。スペック的にサーバが買ってもらえないと厳しいです。 ◎The history and the future of Hadoop use case at Rakuten：Tarje Marthinussen（楽天）\n・Introduction（self、rakuten） NextGeneration Search Group Norwayから来ましたよ。 ・RakutenのBigDataとは ・Hadoop at rakuten　Recommendation（2009） ProductRanking、GenreRanking、Log解析、（2010） Enhance Search。。。（2011） ・PigやHiveのようなものが簡単に利用できるようになってきた ・新しい検索プラットフォームを構築中 index 10k docs/sec search 400qps ・What\u0026#39;s Next Generation Search 20%はインデックスとQuery評価の 50%がデータの前処理（データとQuery） 30%がアナライズ ・Collecting Data？ ログの取得はバッチ処理だった。これをStreamingに（Flume） ・Flume Zookeeperを利用してFlumeを管理してる？？？ ・気になる部分があったので、改善のコーディングしてるよ。 ・セキュリティ マスタで管理できるように ・Pools Agentが送信先がコケてると他のPoolにスイッチ可能に。 ・MasterlessACKs QA Q：パッチ作成は何人でやってるの？ A：50人が働いていてOSSコミッターが何人いるかはわからんです。 Q：ログはテキストだけど、パース処理はどこで？（古橋さん） A：Flumeは各ノードでうまい構成になっていて Decorator 性能問題は？ HiveはJSONデータをうまく活用できてるよ。 Q：Masterlessとそうじゃないバージョンの性能比は？ A：ノード数が増えると Q：HBaseじゃなくてCassandraなの？ A：（※英語きつい。。。聞き取れず） ◎マーケティング向け大規模ログ解析事例紹介：原謙治（NTTコミュニケーション）\n・自己紹介 ・BizCITYというクラウドサービスを展開中 まずは、宣伝。 Bizストレージ、Bizマーケティングとして大規模データ、分散処理を実施してる。 ・Hadoop in Bizマーケティング CGMデータを解析して口コミ情報抽出 アクセスログから行動情報抽出 ・Hadoop in BuzzFinder CGM DBからHDFSにインポートして解析開始。DBはPostgreSQL 処理フローは資料参照。 リッチインデクシング技術（NTT研究所が開発した日本語解析技術） ※検索インデックスってどんなものなんだろう？ ポジネガ分析気になる。 ・Fast Map-Reduce for PaaS Services アクセス解析やマーケティング解析を行う上でShuffleコストが大きくなるため大量マシンが必要 ＝＞マシン数を減らすことが目的？ Map Multi-Reduce、PJoinはNTT研究所が開発した技術！？（子象本にないっけ？？） ＝＞Multi-Reduce。同一ノード上のMap出力をReduceすることで、shuffleフェーズに渡るデータを削減している。 ＝＞PJoin　QA Q：Map multi-reduce、PJoinはどう実現してるのか？公開するのか？ A：Hadoopの0.19に改造をしてる。 公開できるかどうかはわかりません。NTT研究所が研究しているものを試しに実装してみてるから。 なのでパッチにはなりませんかね（研究所に聞いてみないとわからないっす） Q：性能が向上したパターンはあったが、悪化する場合などはあるのか？ A：不明 Q：Map-side Joinとの違いは？ A：。。。 ※この辺で少し集中力が途切れてしまいました、すみません。（次に集中したかったので。。。） ◎ミクシィにおけるHadoopの利用：伊藤敬彦（mixi）\nLSH-Based Recommendation engine powered by hadoop ・実はmixiの話はすくないよ。 ・利用している環境。5or6台/クラスタ ・Hadoopの活用 ログデータをHDFSに保存 DBコンテンツをHDFSに入れることで、DBに負荷をかけずに解析する。 ・マイニングも検証中 検索クエリログをベースにデータマイニング では、本題。 ・LSHを利用した推薦 ・推薦とは？ mixiにはいろいろ推薦（レコメンド）を付加できるサービスがある。 ・推薦するには？ 類似インスタンス集合を抽出する。 インスタンスは文書だったりユーザだったり ・類似インスタンスとは？ 同じ特徴を持つ集合 例：同一商品購入したユーザとか同一単語を持つ文書とか ・抽出するには？ 全ユーザごとに全ユーザとの類似性をチェックすると時間がかかりすぎる！ ＝＞LSHを利用しよう！ ・LSHについて 特徴： ・速い！ ・精度はそれほどではない 事例： ・Google Newsのレコメンド（USロケール） ・LSHの処理ステップ 2つだけ。 1.インスタンスベクトルを計算（似ているデータは同じ値が返りやすい関数） 2.同一値が帰ってきたデータが類似インスタンス ・インスタンスベクトル例（あとでスライド見ようね） ・Likelikeがいち実装。Hadoopでうごくよ ・実験について トップページに表示されていない記事を知ってもらうために推薦してみるぞ！ ・実験１ 性能を測ってみた ・実験２ 精度を調べてみた。 精度はほんとにひどいな。。。 ＝＞同一カテゴリの遷移を元に計算したらそれなりになってきた。 ・今後 データソースを増やしたい。 他のアルゴリズムも実装したい ・CM 以下も作ってますよ。 Oluolu Anuenue QA Q：Mahoutは使わないんですか？ A：Likelikeを作った頃にMahoutになかったので作った。 性能比較したいと思ってる。 Q：ログサーバのデータ転送はどーやってる？ A：伊藤さんのところにはどういう仕組みかは上がって来てない。 Q：ベクトルの次元数はどのくらいまで耐えられる？ A：高次元のデータに対して耐えられるように作られてる。 次元数が低くて良い制度が欲しければ他のアルゴリズムがいいかも。 Q：ユーザのベクトルを作るテクニックは？ A：画像などであれば大変だけど、ユーザであれば、単語とかキーワードとかで Q：ニュース以外のデータは？ A：まだまだ実験中。まだやってない。 Q：推薦される記事数のばらつきはどういった理由が考えられる？ A：後ほど考察してQAサイトに入れます。 Q：LSHをMapReduceに載せたということだけど、関数の計算をさせてる？ A：Iterationはしてない。 Map側でLSH関数計算してる。Reduceにて類似インスタンスを導出してる。 Q：今後の予定の空間木とは？R-Treeだと高次元できついのでは？ A：低次元にて利用できるように用意したい。 Q：HamaとかGiraphで高速化させてみるのはどう？ A：イテレーションがいらないからあまり利用用途がないかなぁ。 ◎懇親会\nAWSを採用しない企業がいくつかあったのでそのあたりを質問してみた。 AWSは通常運用に利用すると結構なコストがかかる場合があるので、ノウハウがある企業や データ量が多い場合は、オンプレミスの場合を選択しているらしい。 やはりスポットで利用する方がお得感があるみたいだった。 Twitter上だけの知り合いだった方々と面識が持てたのが一番の収穫でした。 感想＋調べること\n感想\n会場規模とかQAサイトとかオープニングムービーとかすごかったです。しかも無料。さすがリクルートさん。 ランチボックスとか出てきたし。装飾もとても無料のカンファレンスと思えない出来でした。 午前中はHadoopをもとにした各社の戦略とCMという感じが色濃かったです。少しずつ各社の立ち位置が違いそれはそれで面白かったです。 AWSの説明を聞いてやはりAWSを扱える技術は必要だと再認識。 お金かけないで触ってみれるレベルでまずは触ってみるかなぁ。 洗脳されてるのかもしれないけど、自社or自前でHadoop運用するのは厳しそうです。（懇親会ですこし認識が変わった） カフェコーナーでは、リクルートのMITの冊子が配られていたり、映像や案内に使われていたHadoopマスコットのシールが配られていたりと小技も聞いてました。 あと、オライリーの販売コーナーも用意されていて、思わず子象本を買ってしまう罠にはまったりもしましたが。。。 mixiの伊藤さんの話は最後で疲れていたのですが、ストーリーが上手くできていて、実験や事例もあったのでわかりやすかったです。 Hadoopはエコシステムと呼ばれるHadoopを活用するツール群（Hiveの話が多かった？）、Hadoopの今後、Hadoopを活用したログ解析の話など、 話題が豊富でそれぞれの話が面白くて困ってしいまうくらいです。 いくつかのセッションで出てきたのですが、アクセスログなどをHDFS上に集めるための仕組みがまだ乱立（定番がまだない）している感じを受けました。 Flume、Scribe、MapR。。。などなど あとは、テクニカルセッションのビデオがアップされたらまた目を通さないと。。。 残念ながらHadoopから少し縁遠くなっていますが、これからもネタや参考になりそうな話には事欠かなそうなのでかじりついていこうと思います。 ※一番やらないといけないのは英語の勉強かもしれないです。。。 調べること 一応Solrの人なので、Solrに関連しそうな話に興味がいってしまいます。\nNTT研究所のリッチインデクシング技術 やっぱりAWS触ってみる。EMRまでとは言わないが。（herokuもちょっと興味あるが。） Mesos、GreenPlum、Scribe、Storm、Flume、Giraphこれらの概要 関連サイト 公式QAサイト。後日録画していたセッションがアップされるそうです Hadoop Conferene Japan Fall 2011 - 急がば回れ、選ぶなら近道 Hadoopカンファレンスが開催、本格普及を見据えた支援サービスや先進事例が充実 - ニュース：ITpro Hadoop Conference Japan 2011 fallで使用された資料 #hcj11f | インフラエンジニアのつぶやき（スライドをまとめてくれてます。）\n","date":1317113460,"dir":"post/2011/","id":"97402287d8c6c03f0b63848e17e9d944","lang":"ja","lastmod":1317113460,"permalink":"https://blog.johtani.info/blog/2011/09/27/hadoop-conference-japan-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-09-27T17:51:00+09:00","summary":"Hadoop Conference Japan 2011 Fallに行ってきました。 まずは、ユーザ会の方々、運営の方々、発表された方々お疲れ様でした。こんな機会を用意していただき、ありがとう","tags":["hadoop"],"title":"Hadoop Conference Japan 2011 Fallに参加してきました。(Jugemより移植)"},{"contents":"台風15号すごかったですね。幸いにも（？）夏休みだったので、通勤などでひどい目に合わずにすみました。 風雨はすごくてちょっと怖かったですが。。。\nさて、夏休みに進める予定が、子供の寝かしつけで一緒に寝てしまう日が続いてしまい、 間が開いてしまいました。\n0日目というタイトルになっているのは、まだ、1日目に入ってないからです。。。 Ioという未知の言語をMBAにそのままインストールするのも抵抗があり、VirtualBox上にLinuxをインストールしてから 進めようとして思いの外手こずってしまったためです。 ということで、0日目として、VirtualBox上にScientific Linux 6.1をインストールしてIoのインストールまでではまった箇所を記録として残しておきます。\n罠その１ 罠と言うよりは、私の無知に関する部類なのですが。。。 Scientific Linux 6.1のインストールは特に手こずることなくインストールでき、 起動も出来ました。 次にscpコマンドでダウンロードしてきたIoのソースをLinuxに渡そうとしてはまりました。 問題となったのはネットワーク接続が「NAT」のみだったため。 NATのため、Linux（ゲストOS）から外部への接続は可能だったのですが、Mac（ホストOS）からLinux（ゲストOS）への接続ができませんでした。 で、変更したのは以下の2点。\nVirtualBoxの環境設定-\u0026gt;ネットワーク-\u0026gt;ホストオンリーネットワークの追加 仮想マシン（Linux）の設定-\u0026gt;ネットワーク-\u0026gt;アダプタ2を有効にしてホストオンリーアダプタを割り当て 1番目のホストオンリーネットワークの追加をしておかないと、2番目のアダプタ2でホストオンリーアダプタを選択したときにエラーが出て、設定ができませんでした。割り当てるべきアダプタを先に用意しとかないとダメですよね、そりゃあ。\n罠その２ これも罠というほどではないのですが。。。 Ioのビルドにはcmakeが必要なのですが、Scientific Linux 6.1に入っているcmakeはバージョンが古い（2.6.4）ため、必要なバージョン（2.8以上）をインストールしないとダメでした。 インストール自体はcmakeのサイトにある手順通りのため割愛します。\n罠その３ これもちゃんとドキュメント読めよというレベルですが。。。 Ioのインストールは以下のコマンドを実行するという話です。 私がcmakeについて知らなかったと言われればそれまで。。。\n$ cd io $ mkdir build \u0026amp;amp;\u0026amp;amp; cd build $ ccmake .. $ make $ sudo make install 3つ目の「ccmake」の部分がIoのGetting Startedの下の方にありました。上の方に記載がある「cmake」ではエラーがでてうまく行かなかったので。 IoのGetting Startedにもありますが、ccmakeの場合はCUI上にGUIのようなものが起動するので、「c」（configure）と実行後、「g」（generate）を実行して最後に「e」（exit）でccmakeを離れます。 するとmakeが実行できるようになりました。\nあとは、/etc/ld.so.conf.d/io.confファイルを作成し、「/usr/local/lib」と記述。ldconfigを実行することで、Ioが実行可能になります。 ということで、1日目に入れず終了。。。\n明日は出来るかなぁ。\n","date":1316716440,"dir":"post/2011/","id":"62f31128a21b0e240bdb7b3d5b121c04","lang":"ja","lastmod":1316716440,"permalink":"https://blog.johtani.info/blog/2011/09/23/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-0%E6%97%A5%E7%9B%AE/","publishdate":"2011-09-23T03:34:00+09:00","summary":"台風15号すごかったですね。幸いにも（？）夏休みだったので、通勤などでひどい目に合わずにすみました。 風雨はすごくてちょっと怖かったですが。。","tags":["読書"],"title":"「7つの言語　7つの世界」 Io 0日目(Jugemより移植)"},{"contents":"Solr/Lucene 3.4がリリースされました。（速報）\n以下、各サイトへのリンクです。\nSolrリリースのお知らせ\nLuceneリリースのお知らせ\nちなみに、先日のSolr勉強会で関口さんが話されていたインデックスが壊れるバグですが、 先日のアメリカのハリケーン（Irene）で実際に電源が落ちて見つかったみたいです。\nということで、3.4がリリースされたので、3.1~3.3は利用しないほうがいいようです。\n追記： lucidimagination.jpのサイトに日本語のリリースノートが公開されていたので、リンクを記載しておきます。\n","date":1316046660,"dir":"post/2011/","id":"54da1b916f49ef40c822fab61d37cf66","lang":"ja","lastmod":1316046660,"permalink":"https://blog.johtani.info/blog/2011/09/15/lucene-solr-3-4%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/","publishdate":"2011-09-15T09:31:00+09:00","summary":"Solr/Lucene 3.4がリリースされました。（速報） 以下、各サイトへのリンクです。 Solrリリースのお知らせ Luceneリリースのお知らせ ちなみに、先日の","tags":["solr"],"title":"Lucene/Solr 3.4リリース（速報）(Jugemより移植)"},{"contents":"ということで、Rubyの最終日の感想。 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大募集です。コメント欄にどしどしコメントください。そこは違うだろ？こっちのほうがいいのでは？という感じで。\n感想： ◎メタプログラミングが特徴 例：ActiveRecordのhas_many、has_oneがいい例\n◎オープンクラス クラス定義をいつでも変更可能。 あらゆるクラスやオブジェクトをいつでも再定義できる 書きやすいコードのために再定義が可能＝何でもできるが気を付ける必要あり。 DSLの定義に便利。 確かに便利。ただ、範囲を限定しないと予期せぬ場所で問題が発生しそう。 ※解析するための手段はいいのがあるのかな？=\u0026gt;method_missingみたい\n◎method_missing 対象メソッドが見つからない場合に最後に実行されるメソッド 通常はNoMethodErrorが発行される。\n◎モジュールによるメタプログラミング defやattr_accessorなどその一例。 DSLではモジュール内にメソッドを定義してメソッド＋定数を利用 ActsAs\u0026hellip;ってそういう意味合いだったのか。 親クラスバージョン、親クラス＋マクロ、モジュールそれぞれの実装の仕方の紹介。 ※マクロもinclude同様、実行順で、メソッドの上書きが発生するのか？ ActiveRecordではメタプログラミングを利用してDBのカラム名からアクセサを追加。 シンタックスの美しさ＝読みやすさ\n感想＆疑問点： メタプログラミングはフレームワークを作成するのが便利そう。 ただし、エラーや問題が起きた時の対処をきちんと準備しておかないとひどい目に合いそう。 クラスやモジュールはわかりやすい単位で1ファイルにまとめるもの？ ファイル名の規則とかあったりする？ ディレクトリ構成でパッケージ構成が可能？ 複数のモジュール（gemとか）を組み合わせて使っている場合にincludeの順序がどのようになるかが気になる。 予期せぬ順序でincludeされて利用しようと思ったメソッドがオーバーライドされてるとかありそう。 追っかけるのがまた大変そうだ。 異なるパフォーマンス（開発者の開発速度）の観点が一番おもしろかった。ただ、なれるまでは大変そう。すんなりinjectとかコードブロックをうまく利用するイメージがわかない。 まぁ、思考については反復練習かな。これは他の言語でも一緒かな\nようやく、Rubyの世界が終わりました。楽しかった。次は未知の言語である「Io」です。\n（試してみよう：） ○eachメソッドがCsvRowオブジェクトを返すようにCSVアプリケーションを変更せよ。そのCsvRowのmethod_mmissingを使って、与えられた見出しの列の値を返すようにせよ。 モジュールにて実装してみた。 ``` module ActsAsCsv\ndef self.included(base) base.extend ClassMethods end module ClassMethods def acts_as_csv include InstanceMethods end end\nmodule InstanceMethods\ndef read @csv_rows = [] file = File.new(self.class.to_s.downcase + '.txt') headers = file.gets.chomp.split(', ') file.each do |row| @csv_rows \u0026lt;\u0026lt; CsvRow.new(headers,row.chomp.split(', ')) end end def each(\u0026amp;block) csv_rows.each(\u0026amp;block) end attr_accessor :csv_rows def initialize read end end\nclass CsvRow def initialize(headers, csv_contents) @headers = headers @csv_contents = csv_contents end\nattr_accessor :headers, :csv_contents def method_missing name, *args csv_contents.fetch(headers.find_index(name.to_s)) end end end\nここまでが実装したモジュール＋クラス。 以下は実行例。id,name,sizeというheaderをもつCSVを使ってみた。 require \u0026lsquo;acts_as_csv_module_mod.rb\u0026rsquo; =\u0026gt; true class RubyCsv include ActsAsCsv acts_as_csv end =\u0026gt; RubyCsv csv = RubyCsv.new =\u0026gt; #\u0026lt;RubyCsv:0x103c4c530 @csv_rows=[#\u0026lt;ActsAsCsv::CsvRow:0x103c4c030 @csv_contents=[\u0026ldquo;1\u0026rdquo;, \u0026ldquo;RubyCsv.class\u0026rdquo;, \u0026ldquo;20\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;, #\u0026lt;ActsAsCsv::CsvRow:0x103c4be78 @csv_contents=[\u0026ldquo;2\u0026rdquo;, \u0026ldquo;JRubyCsv.class\u0026rdquo;, \u0026ldquo;50\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;]\u0026gt; csv.each {|row| puts row.name} RubyCsv.class JRubyCsv.class =\u0026gt; [#\u0026lt;ActsAsCsv::CsvRow:0x103c4c030 @csv_contents=[\u0026ldquo;1\u0026rdquo;, \u0026ldquo;RubyCsv.class\u0026rdquo;, \u0026ldquo;20\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;, #\u0026lt;ActsAsCsv::CsvRow:0x103c4be78 @csv_contents=[\u0026ldquo;2\u0026rdquo;, \u0026ldquo;JRubyCsv.class\u0026rdquo;, \u0026ldquo;50\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;] csv.each {|row| puts row.id} (irb):8: warning: Object#id will be deprecated; use Object#object_id 2179096600 (irb):8: warning: Object#id will be deprecated; use Object#object_id 2179096380 =\u0026gt; [#\u0026lt;ActsAsCsv::CsvRow:0x103c4c030 @csv_contents=[\u0026ldquo;1\u0026rdquo;, \u0026ldquo;RubyCsv.class\u0026rdquo;, \u0026ldquo;20\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;, #\u0026lt;ActsAsCsv::CsvRow:0x103c4be78 @csv_contents=[\u0026ldquo;2\u0026rdquo;, \u0026ldquo;JRubyCsv.class\u0026rdquo;, \u0026ldquo;50\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;]\n\u0026lt;span style=\u0026#34;color:#FF0000\u0026#34;\u0026gt;※idというcsvフィールド名にしたら、object_idとかぶっているようでwarningが出てしまった。\u0026lt;/span\u0026gt; CsvRowクラスの定義がモジュールの中に入っているが、この実装でも動くみたい。ただ、パッケージみたいな感じ7日までは調査してない。。。 ","date":1315992060,"dir":"post/2011/","id":"41b811063b9425de1934e77d89118022","lang":"ja","lastmod":1315992060,"permalink":"https://blog.johtani.info/blog/2011/09/14/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-3%E6%97%A5%E7%9B%AE%E6%9C%80%E7%B5%82%E6%97%A5/","publishdate":"2011-09-14T18:21:00+09:00","summary":"ということで、Rubyの最終日の感想。 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大","tags":["読書"],"title":"「7つの言語　7つの世界」 Ruby 3日目（最終日）(Jugemより移植)"},{"contents":"「第6回Solr勉強会」に参加しました。 なんだかんだと第6回で、今のところ皆勤賞です。\nということで、主に自分用ですが、メモなどとったので。\n概要\n日時 :2011/09/12 19:00 to 21:00 定員 :110 人 会場 :株式会社 ECナビ 1.「Lucene/Solr 3.2-3.4」 by ロンウイット 関口 宏司さん ※Solr2.9.4、3.1でデグレードし、Solr3.4で修正されたバグがあります。 インデックス中にPCがシャットダウンされた場合にインデックスが壊れてしまうものあり。 Solr3.1-3.3は使用しないようにとのこと。 ○index ・IndexWriter.addDocuments(docs) 複数ドキュメントの更新が可能になった。 ※検索で話をする親子関係のNestedQuery向けの登録にも利用する。 この登録では途中でフラッシュされないため、セグメントが分割されない特徴あり。 複数だけでなく、 ・TieredMergePolicy ※Lucene3.2/Solr3.3からデフォルトになった。 新しいインデックスのマージポリシー。（amebaの開発者ブログに説明があった。） インデックスの登録順が守られていたが、このマージ処理では保証がされなくなったので注意が必要。 ・update.chain update.processorがdeprecatedに。 update.chainというパラメータに変更 ○index(cont\u0026#39;d) ・TwoPhaseCommit ・UniqFieldsUpdateProcessor 重複した値を削除するための機能。 UIMAでの提案から取り込まれた ○search ・group=on 検索グルーピング機能を使えるパラメータ ・{!term} クエリパーサを通さないでTermQueryをかける機能。 ・structured explanation debug=onの算出根拠を XMLタグで構造化されたExplanationが取得可能に ・ReloadCacheRequestHandler 関口さん担当。ExternalFileField インデックス外（外部ファイル）を元にFunctionQueryの情報を利用可能にできるのだが、 このファイルのリロードが可能になる。 ・Carrot2　3.5.0 アップグレード。 デモあり。Carrot2のworkbenchとか　○search(cont\u0026#39;d) ・hl.phraseLimit parameter FastVectorHighlighterの高速化用パラメータ。 ・{!cache=false} キャッシュを利用しないためのローカルパラメータ。fqのローカルパラメータに利用可能。 検索セッション内でキャッシュへの処理（参照・登録）をしなくなる ・BlockJoinQuery NestedDocumentQueryの名前が変更された。 （Luceneで登録されたところまで。） ○schema ・KStemFilter PoterStemmerとは別のstemmer ・ReversePathHierarchyTokenizer パスの構造化インデックスの逆バージョン ・ommitPositions=\u0026#34;true\u0026#34; 指定が可能になった。 ・version 1.4 スキーマのバージョンが新しくなった。 ○admin/tools ・action=MERGEINDEXES\u0026amp;srcCore=coreName コア名指定可能。 ・action=UNLOAD\u0026amp;deleteIndex=true UNLOAD時にインデックス削除 ・action=CREATE\u0026amp;property.name ※ぎゃーーー。打ち込み失敗。 ○ぎゃーーーー失敗。 ○技術者大募集中！！ Q\u0026amp;A Q：クラスタリングの日本語は大丈夫？入門には制限があると記載があったが。 A：analyzerが記載が簡単になってるかは不明 前処理をして別フィールドにメタデータ的にある程度単語で区切ったようなものを作成したほうがいい。 Q：グルーピングで、グルーピング後のファセット件数が取得可能か？ A：3.4ではグループ数で表示可能。 パラメータ指定で可能。 2.「Solr＠cookpad」 by ＠PENGUINANA_ さん ○COOKPADとは？ ・レシピ投稿サイト ・105万のユーザのレシピ ・30代女性の1/2が利用 ○レシピ検索 ・PC：1307万UU、1億回強/月 ・モバイルで利用が多く、スーパの店頭などで利用？ ・Androidもあるよ。 ○人気順検索（Solrですよ） ○自己紹介 ・＠PNGUINANA_ ・情報可視化＋検索が好き！！ yats、など ○Solrはどのように利用 ・レシピ検索 ・もしかして ○Tritonnから移行 同じ検索結果になるようにして徐々に移行 ○なぜ？ パフォーマンスが良い。 フィールド追加が簡単 レプリケーション-\u0026gt;ファイルベース プロトタイピングが楽 ○Solr4 nightly（on Oracle JVM） ・マルチコア利用 ・Ruby on Railsから ○簡単な構成＋説明 ・バッチからSolrへの更新をしている。 ※Analyzerを利用せず、バッチ側で分かち書き、正規化、同義語展開を行っている。 Rubyで全部かけるほうが社内に展開しやすい。 ・バッチ終了後、可能ならoptimize ※検索速度がmax20%高速になる。 ・マスタ-\u0026gt;スレーブレプリケーションはschema.xmlもレプリケート 新規フィールド追加などはレプリケーションだけで実行できて楽。 ・アプリはMySQLとSolrのSlaveにアクセス。 Solrにはidのみ。本文はMySQLから取得 インデックスサイズを小さくできる＝レプリケーション時間が短くなる オンメモリにできるため検索速度も向上 ○監視（munin） ・監視項目（コア別）： クエリ：QTime/QPS キャッシュ：hit/eviction キャッシュから漏れている数をみてキャッシュサイズを定期的に変更して無駄をなくす インデックス：サイズ/docの数 運用してから重要。開始当初は気にしてるが、そのうち気にならなくなるため。 レプリケーション：所要時間 スレーブ間でのズレを検知するため。 ※コアごとに監視することで、問題点を把握しやすくしている。 ○監視（nagios） ・監視項目（コア別）： サーバの基本的なヘルスチェック Solrが動いてるサーバのはなし。 レプリ：インデックスバージョンのチェック ズレが長いとメールが飛ぶ ○便利だった機能 ・DynamicField フィールドをあとから簡単に追加可能。 例：人気順のアルゴリズムの違うフィールド。検索用フィールド ・FacetQuery 絞り込み検索をクエリで記載可能。 現時点では社内向け検索機能で利用。 ※ファセットで簡単な解析もやってる。 例：鍋の季節ごとの登録件数。 ・HTTP経由で色々可能 検索の並列化 通常検索画面：3クエリを同時実行 あるプロトタイプ画面だと8クエリで実行したりしてる。 ・分散検索（Distributed Search） 簡単にsharding可能 思いクエリは４shardで投げる オーバヘッドが大きいので思いクエリにだけ利用しているらしい。 ○開発の流れ ・まずはステージングを更新 ・問題なければマスターも更新 例外： フィールド追加するだけだったら直接マスタへ 例：ファセット追加など。 ○パフォーマンスとか大丈夫？ 本番で複数のバージョンを持っており、 バグっていても自動フォールバックするらしい。 価値があったらパフォーマンス向上＋テスト追加 例：スニペット変更 ○気になっている機能 ・not to cache(SOLR-2429) ・SurroundQuery(Solr-2703) ・JOIN(SOLR-2272) SQLのJOINなイメージ ・BloomFilter(SOLR-1375) 単語が存在するかどうかのチェック ○Solr入門おすすめ ○おすすめ ・http://blog.sematext.com 月一で新機能が出てくる ・SolrのJIRA ・@otisg ○今後やりたいこと ・わかち書きの精度向上 ・検索セッションの分析 nDCG、クエリ分類、検索意図 ・デバイス対応 ・パーソナライズ Q\u0026amp;A Q：同義語は誰が集めている？ A：外部辞書を利用。０件キーワードから解析して取得 単語登録も一緒。 Q：プチトマトとトマトの違いはどうやってる？ A：上位、下位の概念で同義語を利用している。 本にあるよ。 Q：もしかしてはSolrの機能？ A：Solrではない。訂正候補の単語をSolrに検索してからチェックして表示する。 Q：人気順はどういった計算をしてるんですか？計算してから登録？By 大谷 A：１フィールドに外から入れている。 Q：RubyからSolrの利用方法は？独自？ライブラリ？By 大谷 A：Rsolrを利用しており、コネクション管理にだけ利用している。 あとは、ラッパーを独自で作成。 Q：4.0を利用している理由は？なかなかチャレンジャー。By関口 A：グループクエリを利用したかったため。 実際には重くて使えていない。 今は必要ないかもと思っている。年始のバージョンを利用。いつでも入れ替え可能。 マスタスレーブ構成のsolrのバージョンアップはサービスアウトしてから入れ替える。 3. 「Solrを用いた検索システムの構築」　by データセクション株式会社 高井さん いろいろな試行錯誤について ○データセクションについて 言語処理を元にデータの解析（Twitterとかブログとか）している会社。 ・昔は自社で検索サーバを構築していた ・Luceneを利用して検索サーバを構築するように変更。 ○構成（過去？） ・Lucene＋RMI 3.0から縮小で、4.0で廃止に ○SolrにするかLuceneにするか？ ・いろいろ機能があるからSolr使ってみるかｗ ○Solr導入は1.4.1から スペック マスタ： メモリ：16G Disk：2Tｘ12 スレーブ： 256GのSSDを利用 JavaVMが32bit ○ひと月分を1shardにして登録 ○検証＋手探り？ メモリが足りない。 Solrのキャッシュを全Offに。 BOBO SolrPluginってのを利用 compressオプションも利用。 各スレーブにキューを用意して1つだけしか処理しない。（なんでだ？？） ○結果 キャッシュはフィルタキャッシュのみ利用 ユーザが同じクエリを投げるのはほぼないので。 フィルタキャッシュのエントリのメモリ量の計算式（あとで資料が出てくるかなぁ。） ○問題点 ・レプリケーションでインデックスサイズの2倍の容量が必要になる。 ・レプリケーションの日時フォーマットのバグ（SOLR-1995）を踏んでしまった。 ・レプリケーション後にインデックスが消えない場合がある ○検討（1.4.1-\u0026gt;3.2） うれしい要素 レプリケーションバグがfix 省メモリや範囲検索の高速化など　かなしい要素 compressが使えなく（しかも回答してからriindexしてくれる） ○検討 余計なインデックス消す nearinfinityが出しているlucene-compressionを利用 https://github.com/nearinfinity/lucene-compression ○残った問題 facet.rangeが使えないなど。 ○じゃあ集約サーバつくっちゃえ（すごいな。） facet書き換えコンポーネントなど。 ○シャードのインデックスサイズが下がった 130GiB-\u0026gt;90GiB これはlucene-compressionの効果 ○ここまでの変更はプラグインにて対応（この一覧いいかも） ○感想 コンポーネント化されてて、簡単に追加機能が実装可能 用途次第であまりスペック高くなくても使える。 Q\u0026amp;A Q：Twitterのデータのクロール方法は？ A：HTMLをスクレイピングしている。publicなTLのみ。 Q：いきなりSolrに入れる？Solrの前処理は？ A：SolrJを利用して前処理済みのデータを登録している。 4. 「Anuenueの紹介と最近の進捗」 by @takahi_i さん（mixi） ○自己紹介 ・NAIST出身 ・ファストサーチ ・今はmixi ○mixiとは？ ○社内の緊急タスク ・内製検索エンジンをメンテナンスしやすいOSSにしたい！ -\u0026gt;Solrを選択 Anuenueも実装 ○Anuenueの作成理由は？ インデックス運用が面倒（検索（distributed search）はあるがインデックスは自前） クラスタ用のコマンドが提供されていない。 ○Anuenueが提供する機能 ・検索クラスタの簡単設定 ・クラスタ用コマンド ・もしかして機能 ○機能：Anuenueのクラスタ設定 Merger：クライアントからのクエリをMasterに分散 Master：インデックス作成側 Slave：検索用スレーブ。マスタからコピー ○クラスタの管理コマンド クラスタのコマンドを用意。 起動、コミット、登録など ○SolrCloud向けのAnuenueを検討中 branch-cloudにあります。 今後の予定 インスタンス追加削除を動的に実行できるようにしたい ○Hadoop Conferenceの宣伝ｗ Oluolu：Hadoop上で動くクエリログマイニングツール Likelike：LSHをHadoopで実装（Hadoop Conference 2011 Fallで発表） 5. LT 5.1　「solrとRの連携について」　by @yutakashino さん（BakFoo） Python本、Zope本を書いてます。 ○NHKの実証実験で利用？ ○TwitterストリームをSolrにストア facet.date ○Rでキーワード頻度グラフ Node.js、Redis、R、Solrを使ってる。しかもPython ○デモ キーワード＋日付でグラフが出てくる。 Rでプロット。 GoogleのチャートAPIを利用すると面白いことができる。 5.2　「 Apache ManifoldCF」　by 阿部さん(ロンウィット) ○Apache Incubator ○Manifold Connector Framework Solr ＜－ MCF ＜－ web＋non-web repositories すぐに利用可能。 ○概要 出力はSolr。 接続先はWeb、DB、CMS、などなどいろいろRepositoryConnectorというのがあります。 ○Crawler Agent クロールに関するJobの管理 接続先、スケジュールなど ○Windowsサーバのクロールもできる 社内のナレッジ共有などに使える。権限周りも簡単に対応可能。 JCIFS.jarによりWindowsの権限情報を取得 ○クロール設定画面もある デモ ○導入が簡単なのがおすすめ。 ○ManifoldCFの資料関連 http://www.manning.com/wright 懇親会についてはあとで記載します！！ ということで追記です。 懇親会でも色々と面白い話を聞けました。 @PENGUINANA_さんにはCOOKPADのCI関連の話を聞けました。 1日に数度リリースするという話もあるようでした。\nあとは、Rについても@yutakashinoさんから概要が聞けたのが良かったです。\nちょっとだけ追記。まだ成形する予定ですが、とりあえず。\n追記：スライドが公開され始めたので。\n関口さんのスライドはこちら 阿部さんのスライドはこちら ＠PENGUINANA_さんのスライドはこちら。 @takahi_iさんのスライドはこちらからPDFダウンロード可能。\nその他に関連するブログも見つけましたので。 「Solr@Cookpad」- Solr勉強会で発表してきました Ars longa, vita brevis: 第６回 Solr 勉強会に行ってきた\n勉強会で出てきた各製品などのリンク： 色々とURLが出てきていたので、リンクをまとめておきます。\nlucene-compression Anuenue Apache Solr のラッパー Likelike LSH (Localtiy Sensitive Hashing)の実装 OluOlu 検索ログマイニングツール @takahi_iさんのLuceneRevolution2011のスライド Kuromoji 形態素解析器 lucene-gosen 形態素解析器（Senの後継） Apache ManifoldCF ","date":1315810980,"dir":"post/2011/","id":"37b622eaad1f79e759a722aacebf48ec","lang":"ja","lastmod":1315810980,"permalink":"https://blog.johtani.info/blog/2011/09/12/%E7%AC%AC6%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-09-12T16:03:00+09:00","summary":"「第6回Solr勉強会」に参加しました。 なんだかんだと第6回で、今のところ皆勤賞です。 ということで、主に自分用ですが、メモなどとったので。 概","tags":["勉強会"],"title":"第6回Solr勉強会に参加しました。(Jugemより移植)"},{"contents":"ということで、Ruby2日目の感想（2日目だけで2日間かかったのは内緒。。。） 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大募集です。コメント欄にどしどしコメントください。そこは違うだろ？こっちのほうがいいのでは？という感じで。\n感想： ◎関数の定義：ありゃ、利用するのはダメなんだ、これじゃ。\u0026ndash;\u0026gt;単なるタイプミスでした。お恥ずかしい。。。 \u0026gt;\u0026gt; def tell_the_truth \u0026gt;\u0026gt; true \u0026gt;\u0026gt; end =\u0026gt; nil \u0026gt;\u0026gt; tell_the_trueth() NoMethodError: undefined method `tell_the_trueth\u0026#39; for main:Object from (irb):4 ◎配列：そしてシンタックスシュガー puts animalsで内容が出力されるのはうれしい。JavaだとHashCodeが出てくるから。出力メソッド書かないといけなくなる。 animals[-1]で最後の要素とかかなり便利。 animals[0..1]はRangeクラスを利用する形。Rangeはやはり便利。substringなどもできそう。 カラ配列の定義は必要。a = [] 1.9と1.8でinclude?の書き方が異なるので注意！ 配列（Array）クラスは中はObjectが入る。 多次元配列もOK。popやpushでキューとしても利用可能。\n◎ハッシュ： Mapのようなもの。任意のキーが利用可能。:付きの文字列はシンボルと呼ばれる定数値を簡単に定義する方法。 object_idという属性？関数によりObjectのハッシュコードが取れるらしい。 ブレース＝「{}」のカッコのこと。do～endでも代用可能\n◎コードブロックとyeild コードブロック＝名前なし関数。習慣では複数行の場合、do/endで、１行は{}みたい。Javaと混同しそう。 コードブロックは引数も指定可能。 「yield」予約語？を利用してコードブロック自体をメソッド内部などで呼び出し可能。 ということで、コードブロックは引数にも指定できると。コードブロック＝関数もObjectとして扱われてる感じか？ 実行遅延、分岐、共通関数とか？Javaだとabstractメソッドを利用して処理するようなイメージか？ちょっと違うなぁ。 なれると、yieldはコードを読みやすくできそう。また、シンタックスハイライトしてくれるツールがあれば、更に便利。\n◎ファイルの実行 ruby ファイル名 vi、Emacs、TextMateなどがあるよ。\n◎クラスの定義 ※数字で始まる変数は利用できない！Javaと一緒 Tree.rbとログを参考にすること。 \u0026amp;使うとブロックに名前が付けられる。yieldじゃなくてもいい？ クラス名はキャメルケース。 変数とメソッド名は「_」アンダーバーつなぎ インスタンス変数の頭は@ クラス変数は@@ 定数は大文字 ※メソッド名、変数名には違和感が。なんでこんな規則？？ 判定用関数とメソッドには「?」（if test?）をつける！！Javaでいう「is」か。\n◎Mixin（多重継承？モジュールと呼ばれるものを利用） 多重継承のような類似の振る舞いを伝搬する仕組み。 Javaではインタフェースでやること。 Rubyではモジュールといい、関数と定数の集まり。 クラスに機能を盛り込む場合はincludeする ※複数includeして、includeしたものの中に同じメソッドとかあったらどーなる？ \u0026ndash;\u0026gt;Overrideされた＝includeがあとにあるもので上書きされる Abstractにできないものをモジュール化できるの楽。 javaだとstaticメソッドだらけのUtilクラスを別途起こすイメージだけど、内部で呼ばれるメソッド（コードブロック）が同じインタフェースじゃないと行けないから、インタフェースの記述もしないと行けない。 ただし、同一名のメソッドを持ってるとややこしそう。 ※モジュールからモジュールは呼べる？\n◎モジュール、Enumerable、セット EnumerableとComparable（JavaのCollectionまわりかな。） 宇宙船演算子（\u0026lt;=\u0026gt;）Javaのequalsに似てる any?とかCollectionUtils？？に似たのあったな。 ※今利用しているクラスが何をincludeしてるかってのは分かる仕組みあるのかな？ ※そういえば、メソッドごとに戻り値があるが、全部newされてインスタンス化されてGCの対象になってるのか？irbだけ？ injectはすんなり使うイメージが出にくそう。また、ソースをぱっと見て理解出来ない。なれだろうけど。 ※injectしながらinjectとかあるんだろうな。\n（探してみよう：） ○コードブロックを使った場合と使わない場合の両方について、ファイルにアクセスするコードを書く。コードブロックの利点は？ ※コードブロックあり。 ``` File.open(\u0026ldquo;tree.rb\u0026rdquo;, \u0026lsquo;r\u0026rsquo;) {|f| f.each {|line| puts \u0026ldquo;#{f.lineno} : #{line}\u0026rdquo;}}\n※コードブロックなし f = File.open(\u0026ldquo;tree.rb\u0026rdquo;, \u0026lsquo;r\u0026rsquo;) while line = f.gets puts \u0026ldquo;#{f.lineno} : #{line}\u0026rdquo; end\nコードブロックの利点： 見通しの良さ。行数が少なくてすむ。繰り返し処理が簡単に記述できる。 ※うーん、まだきちんと理解できてないか？ \u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○ハッシュを配列に変換するにはどうすればよいか？また、逆に配列をハッシュに変換する方法は？\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt; ※間違えた。。。 h = [:key1 =\u0026gt; \u0026ldquo;hoge\u0026rdquo;, :key2 =\u0026gt; \u0026ldquo;boke\u0026rdquo;, :key3 =\u0026gt; \u0026ldquo;fuga\u0026rdquo;] h.each {|key, value| puts \u0026ldquo;#{key} is #{value}\u0026rdquo;} =\u0026gt;key1hogekey2bokekey3fuga is\nハッシュ-\u0026amp;gt;配列変換 h.to_a\n配列-\u0026amp;gt;ハッシュ変換 a = [\u0026ldquo;value1\u0026rdquo;, \u0026ldquo;valu2\u0026rdquo;, \u0026ldquo;value3\u0026rdquo;] h = {} a.each {|i| h.store(a.index(i),i) }\n※また間違い？なんでそうなる？ a.inject(h2) {|hoge, i| hoge[a.index(i).to_s] = i}\nこっちならいいみたい。まだinjectがわかってない。 a.inject(h2) {|hoge, i| hoge[a.index(i).to_s] = i;puts \u0026ldquo;#{i}\u0026rdquo;; hoge}\n\u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○ハッシュの各要素について繰り返すにはどうすればよいか？\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt; h.each {|key, value| puts \u0026ldquo;#{key} is #{value}\u0026rdquo;}\n\u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○Rubyの配列はスタックとしても使える。スタック以外に配列で実現可能なよくあるデータ構造体を挙げよ。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;キュー。 他にある？Treeとか？Treeはハッシュじゃないか？Set？順番が関係ないけど。\u0026lt;/dd\u0026gt; \u0026lt;/dl\u0026gt; ### **（試してみよう：）** \u0026lt;dl\u0026gt; \u0026lt;dt\u0026gt;○最初に、eachだけを用いて、１６個の数値と４個の数値の配列の中身を同時に出力せよ。次に、同じ事をEnumerableのeach_sliceを用いて実行せよ。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt; \u0026lt;span style=\u0026#34;color:#FF0000\u0026#34;\u0026gt;\u0026lt;em\u0026gt;※これ日本語がわからないんだが、4個ずつ出せってことか？？\u0026lt;/em\u0026gt;\u0026lt;/span\u0026gt;ということで、「16個の数字の配列の中身を4個ずつ同時に出力せよ。」と解釈して実装してみた ※each利用版 a = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16] s = [] a.each do |b| unless s.length \u0026lt; 4 puts s.inspect s.clear end s \u0026laquo; b end\n※each_slice a = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16] a.each_slice(4) {|b| puts b.inspect}\nまた、えらい違いだな。 \u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○Treeクラスは面白いクラスだったが、きれいなインタフェースを用いて新しいツリーを指定することは出来なかった。そこで、initializerにハッシュと配列が入れ子になった構造体を指定できるようにせよ。具体的には、次のようなツリーを指定できるようにしたい。{\u0026#39;grandpa\u0026#39; =\u0026amp;gt; { \u0026#39;dad\u0026#39; =\u0026amp;gt; {\u0026#39;child 1\u0026#39; =\u0026amp;gt; [], \u0026#39;child 2\u0026#39; =\u0026amp;gt; [] }, \u0026#39;uncle\u0026#39; =\u0026amp;gt; {\u0026#39;child 3\u0026#39; =\u0026amp;gt; [], \u0026#39;child 4\u0026#39; =\u0026lt; [] } } }\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;\u0026lt;span style=\u0026#34;color:#FF0000\u0026#34;\u0026gt;※root（ここではgrandpaレベル）が複数あると破綻しないのか？\u0026lt;/span\u0026gt; class Tree attr_accessor :children, :node_name\ndef initialize(name, children=[]) @children = children @node_name = name end\ndef initialize(hash) hash.each do |key, value| @node_name = key @children = value.inject([]) do |array, (child_key, child_val)| puts \u0026ldquo;inject! #{key}\u0026rdquo; [Tree.new({child_key =\u0026gt; child_val})] + array end end end\ndef visit_all(\u0026amp;block) visit \u0026amp;block children.each {|c| c.visit_all \u0026amp;block} end\ndef visit(\u0026amp;block) block.call self end end\n残念ながらちょっとカンニングしてしまいました。。。 \u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt; ○ファイル内で、あるフレーズを含む全ての行を出力する簡単なgrepをかけ。簡単な正規表現でマッチングを行い、ファイルから行を読み出す必要がある（この処理はRubyでは驚くほど簡単にかける）。必要なら行番号も出力してみると良い。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;※メソッドだけでいいな。\u0026lt;span style=\u0026#34;color:#0000FF\u0026#34;\u0026gt;ファイルクローズはこの記述の場合はコーディングブロックのendのタイミングでクローズされるのか？\u0026lt;/span\u0026gt; class RegGrep def grep(filename, regexp) File.open(filename, \u0026lsquo;r\u0026rsquo;) do |f| f.each do |line| puts \u0026ldquo;#{f.lineno} : #{line}\u0026rdquo; if line.match(regexp) end end end end\n\u0026lt;/dd\u0026gt; \u0026lt;/dl\u0026gt; ということで、2日目終了。 恥ずかしいコードだらけだけど、ぜひツッコミ入れてもらえると助かります。 数年前までは、恥ずかしいからとか見せられるレベルじゃないからと、ほとんどアウトプットしなかったのですが、 最近はそれではものすごく損をしていると思っています。 ホントは発表するとか議論するとかする場もあればいいのですが。 アウトプットすることで、フィードバックが貰えて、いろんなかたの考えが参考になり、糧となり成長していけるのかと。 （これじゃ成長できないレベルだよという話でなければいいのだが。。。） 一度、Rubyのプロフェッショナル各位に見てもらいたいなぁｗ ","date":1315588260,"dir":"post/2011/","id":"73262345214f9b7794f2cc4a612b15e8","lang":"ja","lastmod":1315588260,"permalink":"https://blog.johtani.info/blog/2011/09/10/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-2%E6%97%A5%E7%9B%AE/","publishdate":"2011-09-10T02:11:00+09:00","summary":"ということで、Ruby2日目の感想（2日目だけで2日間かかったのは内緒。。。） 今回もセルフスタディの私の回答が最後の方に記載されてます。見た","tags":["読書"],"title":"「7つの言語　7つの世界」 Ruby 2日目(Jugemより移植)"},{"contents":"実に3年ぶりくらいにゆっくりできる日々が訪れたので、積読状態の本を消化しようと「7つの言語　7つの世界」を読み始めました。\nせっかくブログも始めたので、備忘録も兼ねて感想などを書いていこうかと。\nこの本ですが、以下の7つの言語についてエッセンスがまとめられています。\nRuby Io Prolog Scala Erlang Clojure Haskell まずはRubyからです。 ここ2年ほどRuby（Rails）に関連する仕事をしていたのですが、Ruby周りはプロフェッショナルな方たちがいたので、きちんと勉強していないことがこの本を読み始めてわかりました。\nということで、前置きはそれなりな記述ですが、感想は適当になりますので、あしからず。\n感想： irbが便利。簡単に動作確認ができるのが便利。Javaだとコンパイルが必要。 変数を定義する必要がない気軽さはある。 必ず戻り値が帰ってくる「puts \u0026lsquo;hello, world\u0026rsquo;」でも。=\u0026gt;nil putsは楽かな。まぁ、Eclipse使ってると一緒か。 「4」もオブジェクトとなっている。ここもJavaと異なる。 (x \u0026lt;= 4).classという記述でTrueClassというクラスだとわかる。 unlessが結構便利。ただし、記述方法が多数あるので、可読性は落ちる？場合によってはわかりやすいか？ あと、括弧()がないのも慣れない。（まぁ、これは慣れの問題。ただし、カッコありでもOK） {}のかわりがif～endなのはわかりやすいかも。 if not はわかりやすくていい。!はだいたい間違えるから。。。 whileも１行形式で書けるのか。「x = x + 1 while x \u0026lt; 10」慣れないと厳しい。個人的には混在すると読めないなぁ。 nilとfalse以外がすべてtrueに評価されるのは厳しいのでは？型のチェックがないので、booleanが入ってると想定してない場合に挙動を読めないかも。実行時に動作が変だなーと思うことが出てきそう。 and、orの記述が使えるのは読みやすい。ただし、混在するとやっかい。 判定結果が明らかになった時点で実行が中止されるのは普通。\u0026amp;、|の挙動はJava同様。\nやりながら疑問点：\nNetBeansとかIDEでフォーマッタやcheckstyleみたいなのはあるのか？ コーディング規約はあるのか？（2日目に「習慣」があるらしいとの記載があった。） 必ず戻り値が戻ってくるのは、必ずGC対象になりうるオブジェクトが生成されるってことか？ ここまでが感想と疑問点。で、この本の面白いところは最後に調査、コーディングを行う練習問題的なものがある部分です。 一応、私なりの答えを書いておこうかと。（一覧などで見えないようにはしますが、ネタバレがあるので注意してください。）\nということで、セルフスタディの回答。\n（探してみよう） ○Ruby API http://ruby-doc.org/core/ ○Programming Ruby: The Pragmatic Programmer's Guideのオンライン版 http://www.ruby-doc.org/docs/ProgrammingRuby/参考資料：http://www.swlab.it.okayama-u.ac.jp/man/ruby/uguide/uguide00.html ○文字列の一部を置換するメソッド \"hello\".gsub(/[aeiou]/, '*') ○Rubyの正規表現に関する情報 日本語：http://www.namaraii.com/rubytips/?%A5%D1%A5%BF%A1%BC%A5%F3%A5%DE%A5%C3%A5%C1 英語の試せるサイト（irbが動けば必要ないかもね）：http://rubular.com/ ○Rubyの範囲に関する情報 日本語：http://doc.okkez.net/static/192/class/Range.html 英語：RDocのRangeクラスに相当するのかな。 （試してみよう） ○文字列\"Hello, world\"を出力する。 ``` ○文字列\"Hello, Ruby\"の中の\"Ruby\"という単語のインデックスを検索する。 ``` s = \u0026lsquo;Hello, Ruby\u0026rsquo; s.index(\u0026lsquo;Ruby\u0026rsquo;) //indexofで間違えた\n\u0026lt;dt\u0026gt;○自分の名前を10回出力する。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;``` ※まずは、正統派。 i = 0 while i \u0026lt; 10 puts \u0026#34;johtani\u0026#34; i = i + 1 end ※Rangeを利用 (1..10).each {|n| puts \u0026#34;johtani #{n}\u0026#34;} ※forもあるよね for i in 1..10 puts \u0026#34;johtani\u0026#34; end ※timesってのもある。（0始まり） 10.times {|n| puts \u0026#34;johtani #{n}\u0026#34;} ※uptoなんてのもあるのか。 1.upto(10) {|n| puts \u0026#34;johtani #{n}\u0026#34;} ※downtoも 10.downto(1) {puts \u0026#34;johtani\u0026#34;} ※stepもある。 10.step(1, -1) {puts \u0026#34;johtani\u0026#34;}//step(上限,ステップ) ```\u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○文字列\u0026#34;This is sentence number 1\u0026#34;の1を10までカウントアップしながら10回出力する。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;``` 1.upto(10) {|n| puts \u0026#34;This is sentence number #{n}\u0026#34;} ※あとは上記と一緒 ```\u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○ファイルに格納されているRubyプログラムを実行する。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;``` vi hoge.rb ※#上記処理をどれか記述 $ ruby hoge.rb ○ボーナス問題：少し物足りない人は、乱数を選択するプログラムを書いてみてほしい。プレーヤーに数字を選択してもらい、その数字が生成された乱数よりも大きいか小さいかを返す。 ``` -- coding: utf-8 -- range = (1..100) while true puts \u0026ldquo;#{range.min}から#{range.max}の数字を入力してください\u0026rdquo; n = gets n = n.to_i if range.include?(n) break; else puts \u0026ldquo;範囲外の入力値です。もう一度入力してください\u0026rdquo; end end i = rand(range.max) if i \u0026lt; n puts \u0026ldquo;入力「#{n}」は乱数「#{i}」より大きいです\u0026rdquo; elsif i == n puts \u0026ldquo;入力「#{n}」は乱数「#{i}」と等しいです\u0026rdquo; else puts \u0026ldquo;入力「#{n}」は乱数「#{i}」より小さいです\u0026rdquo; end\n\u0026lt;/dl\u0026gt; とまぁ、こんな感じ。こんな方法もあるよ、ここおかしくない？などあれば、コメント欄まで。 リアクション大募集です。 はやく、シンタックスライター導入せねば。 ","date":1315545120,"dir":"post/2011/","id":"9baedcd033169611a42c3cfd58b3ae03","lang":"ja","lastmod":1315545120,"permalink":"https://blog.johtani.info/blog/2011/09/09/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-1%E6%97%A5%E7%9B%AE/","publishdate":"2011-09-09T14:12:00+09:00","summary":"実に3年ぶりくらいにゆっくりできる日々が訪れたので、積読状態の本を消化しようと「7つの言語 7つの世界」を読み始めました。 せっかくブログも始め","tags":["読書"],"title":"「7つの言語　7つの世界」 Ruby 1日目(Jugemより移植)"},{"contents":"現在の出先でMBAを使えないので、なかなか進んでいないMBAのセットアップです。。。\nとりあえず、Eclipse、homebrewをインストールしたので、lucene-gosenの開発やビルドには支障がない程度になってきました。（肝心のSolrがまだ動く状況になかった。。。）\nあとは、Windowsで使用頻度の高いソフトを列挙して、対応するMacのアプリを探そうかと。 まずは、Windowsでよく利用するソフトのリストアップ\nEclipse Cygwin TeraTerm WinSCP meadow サクラエディタ WinMerge PDF-XChange Viewer Evernote FreeMind VMWare こんなところかな。 a.～e.についてはMacOS特に問題なし。Eclipseは入れたし、その他は標準で入ってるものでまかなえると。 f.についてもEmacsで当面対応する予定。ただ、OmmWriter やCotEditorがおすすめらしいと聞いてます。 g.についてはFileMergeなるものがあるらしいので、試してみようかと。 h.は現状Adobe Readerです。ほかにいいのあるのかしら。PDF-XChange Viewerはちなみに、Solr入門を書くときに編集の方から教えてもらったPDFのビューワです。コメントとかハイライトできるのが便利でした。 i.はMacOS版をインストールして、すでに活用中。 j.については一時期活用していたのですが、最近利用していないです。なので、保留 k.についてはVirtualBoxをインストールしてみました。フリーだったので。WindowsではVMWareだったのですが。。。\nほんとにこれくらいで大丈夫かどうかはもう少し使ってみてからかなぁと。 その他におすすめ、これがあるとかなり便利などあれば、教えてもらえると助かります。 まだ、MacOSに触り始めたところなので、細かな部分のカスタマイズなどができていないので、その辺りもオイオイ考えていこうかと。\n※余談ですが、現在「７つの言語　７つの世界」を読み始めました。いろいろな言語の特徴について学べる本のようでかなり楽しく感じています。どうしてもJavaで仕事優先だとコーディングする速度優先でJavaばかり使ってしまうので。 いい頭の体操にもなりそうなのでオススメです。（といってもまだ、最初の言語Rubyなのですが。。。）\n","date":1315329480,"dir":"post/2011/","id":"f23ca2aa066b1ee0fa4df1f2f865be4c","lang":"ja","lastmod":1315329480,"permalink":"https://blog.johtani.info/blog/2011/09/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%93/","publishdate":"2011-09-07T02:18:00+09:00","summary":"現在の出先でMBAを使えないので、なかなか進んでいないMBAのセットアップです。。。 とりあえず、Eclipse、homebrewをインストー","tags":["備忘録"],"title":"MBAセットアップ備忘録その３(Jugemより移植)"},{"contents":"すぐにテストケース追加しますといいつつ、はや一週間。\nようやく仕事が落ち着いたので、テストケースを追記しました。まだパッチの段階です。 一応、異なる辞書の読み込みのテストケースなどを追加し、テストケース追加時点で いくつか気になったところもあったので、ついでに修正を加えました。 一応、辞書の分離＋複数辞書対応については現時点ではこんなところかと。\nあと、もう１項目対応してからtrunkに取り込む予定です。 対応する項目とは以下の項目です。\nカスタム辞書ビルドの簡易化 以前の記事にも書いていますが、カスタム辞書のビルドが思いのほか手間がかかります。 辞書の外部化は対応したのですが、せっかく辞書が外部化できたのですから、コマンド（ant？）で一発で カスタム辞書を含んだビルドをしたくなるのが人情です。 辞書なしのjarファイルもあることなので、すぐに対応可能かと。 ということで、今週中には対応する予定です（宣言しないとまた先延ばしになりそう）\n忘れてそうだったらTwitterやコメントでツッコミを入れてもらえると助かります。\n","date":1315328188,"dir":"post/2011/","id":"3c2523e65ff953fd73579aaaf5d7ce36","lang":"ja","lastmod":1315328188,"permalink":"https://blog.johtani.info/blog/2011/09/07/%E8%BE%9E%E6%9B%B8%E5%88%86%E9%9B%A2%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E3%82%B1%E3%83%BC%E3%82%B9%E8%BF%BD%E5%8A%A0%E3%81%A8%E6%AE%8B%E3%82%BF%E3%82%B9%E3%82%AF/","publishdate":"2011-09-07T01:56:28+09:00","summary":"すぐにテストケース追加しますといいつつ、はや一週間。 ようやく仕事が落ち着いたので、テストケースを追記しました。まだパッチの段階です。 一応、異","tags":["lucene-gosen"],"title":"辞書分離のテストケース追加と残タスク(Jugemより移植)"},{"contents":"先日、辞書のjarファイルからの分離についてパッチと記事を書きました。\nIssueにあげていたパッチをRobertさんが見ていたらしく、次のようなコメントをもらいました。\nMaybe if we change SenFactory.getInstance to use a ConcurrentHashMap then you can easily use multiple dictionaries at the same time? 「SenFactory.getInstanceメソッドでConcurrentHashMap使ったら複数辞書対応できるんじゃない？」（訳） たしかに。。。なんで思いつかなかったのだろう。。。\nということで、実装してみました。 パッチはこちら。\n使い方ですが、先日の記事と代わりはありません。 ただし、あった制限事項が次のようになります。\nマルチコアの設定でsharedLibにlucene-gosenのjarを含まない 同一コア内で異なるdictinaryDirの指定はできない ソースの変更点ですが、ものすごく単純です。 dictionaryDirに指定された文字列をキー、その辞書ディレクトリを利用したSenFactoryのインスタンスを値に持つmapをSenFactory内に保持します。あとは、SenFactoryのgetInstance(String dictionaryDir)メソッドで取得する際にmapに対応するインスタンスがあれば、そのインスタンスをなければ、dictionaryDirから辞書を読み込んでインスタンス生成してmapにキャッシュしつつ返すという実装に変えただけです。 ということで、次のようなIPADICとNAIST-JDIC for ChaSenを同時に使う設定も可能となります。\n\u0026lt;fieldType name=\u0026#34;text_ja_ipadic\u0026#34; class=\u0026#34;solr.TextField\u0026#34; positionIncrementGap=\u0026#34;100\u0026#34;\u0026amp;gt; \u0026lt;analyzer\u0026amp;gt; \u0026lt;tokenizer class=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; dictionaryDir=\u0026#34;/tmp/lucene-gosen/dictionary/ipadic\u0026#34;/\u0026amp;gt; \u0026lt;/analyzer\u0026amp;gt; \u0026lt;/fieldType\u0026amp;gt; \u0026lt;fieldType name=\u0026#34;text_ja_naist_chasen\u0026#34; class=\u0026#34;solr.TextField\u0026#34; positionIncrementGap=\u0026#34;100\u0026#34;\u0026amp;gt; \u0026lt;analyzer\u0026amp;gt; \u0026lt;tokenizer class=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; dictionaryDir=\u0026#34;/tmp/lucene-gosen/dictionary/naist-chasen\u0026#34;/\u0026amp;gt; \u0026lt;/analyzer\u0026amp;gt; \u0026lt;/fieldType\u0026amp;gt; あと、注意事項です。 普通に考えるとわかることですが、辞書を複数読み込めるようになったことで、読み込んだ複数の辞書をメモリに保持することになります。ですので、今までよりも多くのメモリを利用するので、Heapのサイズには注意が必要です。 例のごとく（ほんとよくない。。。）テストコードを書いていない状態のパッチをまずはアップしました。 テスト書かないと。。。次回はテストコードかきましたと言う報告をしたいな\nあと、Robertさんのコメントの前に@shinobu_aokiさんからJapaneseTokenizerFactoryの設定では辞書のディレクトリを$SOLR_HOME/confからの相対パスで記述できるというパッチもいただいています。 この部分については先日と使い方が異なります。 （すみません、まだきちんとソースを見れてないです。。。）\n","date":1314668040,"dir":"post/2011/","id":"88a8e608108be939da9aab5a9a8af7d1","lang":"ja","lastmod":1314668040,"permalink":"https://blog.johtani.info/blog/2011/08/30/%E8%A4%87%E6%95%B0%E8%BE%9E%E6%9B%B8%E3%81%AE%E8%AA%AD%E3%81%BF%E8%BE%BC%E3%81%BF%E6%A9%9F%E8%83%BD%E8%BF%BD%E5%8A%A0%E4%BB%AE/","publishdate":"2011-08-30T10:34:00+09:00","summary":"先日、辞書のjarファイルからの分離についてパッチと記事を書きました。 IssueにあげていたパッチをRobertさんが見ていたらしく、次のよ","tags":["lucene-gosen"],"title":"複数辞書の読み込み機能追加（仮）(Jugemより移植)"},{"contents":"ひさびさに、lucene-gosenの話題です。\nlucene-gosenはjarファイルに辞書も同梱されており、jarファイルをクラスパスに取り込むだけで、 簡単に形態素解析器が利用できるといお手軽さがあり、便利です。\nですが、以前カスタム辞書の登録について記事を書いたように、カスタム辞書の登録は思いのほか手間がかかります。 lucene-gosenのソースをダウンロードし、lucene-gosenを一度コンパイルし、カスタム辞書のcsvファイルを作成し、カスタム辞書を取り込んだ辞書のバイナリを生成し、最後にjarファイルにするという作業です。（書くだけでいやになってきました。。。）さらに作成したjarファイルをSolrや各プログラムに再度配布するという具合です。\nそこで、辞書ファイルの外部化ができないかという話があがっていました。 すこし時間ができたので、山積みになっているissueを横目に軽く実装をしてpatchをissueにアップしました。\n機能としてはごく簡単で、JapaneseTokenizerのコンストラクタに辞書のディレクトリ（*.senファイルのあるディレクトリ）を指定可能にしただけです。 また、JapaneseTokenizerFactoryでもdictionaryDir属性で指定可能になっています。 まずは、コンパイルの方法から。 trunkをSVNでcheckoutし、issueにあるpatchをダウンロードして適用します。（svnのチェックアウトについてはこちらを参考にしてください。）\n$ cd lucene-gosen-trunk $ patch -p0 --dry-run \u0026lt; lucene-gosen-separate-dictionary.patch $ patch -p0 \u0026lt; lucene-gosen-separate-dictionary.patch 次に、antを実行し辞書なし版のjarファイルをビルドします。\n$ ant nodic-jar これで、dictディレクトリに「lucene-gosen-1.2-dev.jar」というjarファイルが出来上がります。 （※ただし、これだけでは動作しないので、別途辞書のコンパイルは必要です。）\n次に、指定の仕方です。JapaneseTokenizerのコンストラクタは第3引数に辞書のディレクトリ（フルパスor実行ディレクトリからの相対パス）を渡すだけです。\nTokenizer tokenizer = new JapaneseTokenizer(reader, compositeTokenFilter, dictionaryDir); 最後に、Solrのtokenizerタグでの指定方法です。\n\u0026lt;fieldType name=\u0026#34;text_ja\u0026#34; class=\u0026#34;solr.TextField\u0026#34; positionIncrementGap=\u0026#34;100\u0026#34;\u0026amp;gt; \u0026lt;analyzer\u0026amp;gt; \u0026lt;tokenizer class=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; dictionaryDir=\u0026#34;/hoge/dictionarydir\u0026#34;/\u0026amp;gt; \u0026lt;/analyzer\u0026amp;gt; \u0026lt;/fieldType\u0026amp;gt; 以上が、簡単な設定の仕方です。なお、辞書を内包したjarファイルでもdictionaryDirは利用可能です。優先度としては、dictionaryDirが指定されている場合はdictionaryDirを探索しファイルがなければRuntimeExceptionです。指定がnullもしくは空文字の場合はjarファイルの辞書の読み込みを行います。\n次に利用シーン、制限事項についてです。 利用シーンとしてはカスタム辞書を定期的にメンテナンス（追加更新）しながらSolrを運用するというのが想定されます。定期的に辞書の再読み込みをしたい場合です。 利用方法は次のようになります。\nSolrのマルチコア構成を利用する 各コアごとにlib/lucene-gosen-1.2-dev.jarを用意 辞書の更新が終わったらコアのRELOADを実施 コアをリロードすることで、lucene-gosenが辞書を再読み込みようになります。（現状でも再読み込みするが、jarファイルを再配置しないといけない。）あとは、定期的に辞書ファイルを更新、再構築しコアをリロードすれば、 リロード後に新しい辞書が利用できるという具合です。 （もちろん、辞書更新後に入った単語は辞書更新以前に作成したインデックスにはでてこないですが。。。） また、コアごとにdictinaryDirを別々に指定することも可能です。\n制限事項は次のようになります。\nマルチコアの設定でsharedLibにlucene-gosenのjarを含まない 同一コア内で異なるdictinaryDirの指定はできない 以上が、辞書の外部ファイル化のパッチについてでした。 少しテストケースを追加したら、trunkにコミットする予定です。興味があれば、パッチを利用してみてください。\nSyntaxHighlighterの導入をしないとソースコードが見にくいですね。。。導入を検討しないと。。。どこかにWebサーバ用意しないとダメかも\n","date":1314062760,"dir":"post/2011/","id":"2f1ec795216d5bafa33a810af3421942","lang":"ja","lastmod":1314062760,"permalink":"https://blog.johtani.info/blog/2011/08/23/%E8%BE%9E%E6%9B%B8%E3%81%AEjar%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%8B%E3%82%89%E3%81%AE%E5%88%86%E9%9B%A2/","publishdate":"2011-08-23T10:26:00+09:00","summary":"ひさびさに、lucene-gosenの話題です。 lucene-gosenはjarファイルに辞書も同梱されており、jarファイルをクラスパスに","tags":["lucene-gosen"],"title":"辞書のjarファイルからの分離(Jugemより移植)"},{"contents":"すみません、また、MBA関連の記事になってしまいました。 ということで、備忘録その２です。\n前回からいくつかインストールや環境の設定をしたので、リストアップ。\nVirtualBoxとWindowsのインストール homebrewのインストール KeyRemap4MacBookのインストール Growlのインストール Time Machine用HDDの購入と設定 VirtualBoxのインストールとWindowsXPのセットアップ。会社関連でどうしてもWindowsが必要なので、 とりあえず、VirtualBoxとWIndowsを入れました。これまでのWindows環境ではVMWareを利用してたのですが、 Macだと有償ということで、無償版が存在するVirtualBoxを選択。 MBAにはDVDのドライブがなく、また、ケチって購入しなかったので、ちょっと手間取りました。 自宅のデスクトップでXPのイメージをisoにして、MBAにコピーしてからインストールと。。。 ただ、MBAのSSDの効果なのか、XPの起動がすごく速くてびっくりです。\nhomebrewのインストールは、まだインストールしただけの状態。。。 MacPortsってのがあるというのは知っていたのですが、最近はこちらがいいとのこと。 ちなみに、MacPortsにはSolrがあるらしいです。デフォルトのため、lucene-gosenとか入れる必要がありますが。\nKeyRemap4MacBookのインストール。入れた方がいいですよと言われてたのだが、きちんと調査してなく、 キーの入れ替えができる程度だと思ってました。昨日、EmacsModeなるものが存在するというのをKeyRemap4MacBookのドキュメントを読んでいて発見し即インストール。 とりあえず、Ctrl-x,Ctrl-cでEvernoteが終了できて喜んでるところです。\nGrowlのインストール。KeyRemap4MacBookのCtrl-xを通知してくれます。ほかにも使い方があるかは調査が必要。\nあとは、昨日、ビックカメラでWDの2TBのHDDを購入してTimeMachineの設定をしてバックアップをとりました。 まだバックアップをとっただけで、差分を見たりはしていないです。帰ってからやってみようかと。\n最後に、ケースを買いました。封筒とかいろいろ考えたのですが、やはり機能重視ということで、以下のケースです。 できれば、ファスナーが２つついていて、両方からあけられるとよかったのですが。リュックとショルダーバッグを使い分けるので、横でも縦でも取り出しが楽なものがよかったので、このケースを買いました。 一応、がんばれば縦でも出せるので。あとは、PCだけもって移動することもあるため、取っ手があるのが便利かと。\nとまぁ、お盆なので、このエントリーで許してください。次回は技術的なことを書きますので。。。 CaseLogic 機能的なモバイルコンピュータケース(13~14.1インチPC対応)、MacBookやMacBook Proにも対応 ダークグレー UNS-114J-DG ","date":1313369460,"dir":"post/2011/","id":"ce0aea06d44878b4a373efe090a66a62","lang":"ja","lastmod":1313369460,"permalink":"https://blog.johtani.info/blog/2011/08/15/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%92/","publishdate":"2011-08-15T09:51:00+09:00","summary":"すみません、また、MBA関連の記事になってしまいました。 ということで、備忘録その２です。 前回からいくつかインストールや環境の設定をしたので、","tags":["備忘録"],"title":"MBAセットアップ備忘録その２(Jugemより移植)"},{"contents":"Mac Book Airのセットアップ関連の備忘録\n（今回は備忘録なので、文体も変かも）\nインストールしたもの（順不同）だいたい、このサイトを参考にした。\nEvernote Dropbox XCode Twitter YoruFukurou GNU Emacs For Mac OS X Java Office for mac 現状はこんなところ。\nまだ、キーボードの配列とショートカット、ウィンドウの切り替えなどがすぐにできないので、かなりおぼつかない状態。\nCtrl+aなどの操作は快適なのだが、ウインドウを閉じたりする場合のcommandキーの扱いがまだなれない。キー配置を切り替えたりした方がいいのか悩み中。 Windowsでは長年XKeymacsを使ってきたため、通常のOfficeなどもCtrl+x　Ctrl+sなどで閉じていたので、command＋qなどがすんなり出てこない。。。\nあとは、VirtualBoxにWindowsを入れて、Eclipseを入れればなんとか、WindowsPCからMBAへの切り替えができそう。\n残っている課題は以下の通り。\nTime Machine環境の整備USB接続のHDDの導入（ミラーリング対応にするか悩み中）※ちなみにうちで使ってるNASは古い＋NFSマウントできない機種だった。。。　対応可能だったらScientific Linux＋Netatalk環境などを用意するのも考えたんだが。 homebrewのインストール 日本語入力（GoogleIME？SKK？） ウォークマン、Xperia arcの運用方法まぁ、今まで使ってたPCで対応かな キーの配置Emacsのショートカットに変更できたりするか調査したい データの移行Windowsに入ってるデータのうち移行するものしないものの選別Macでは利用できないデータやファイルもあると思う。 解凍ツールの選別？いるのかな？ ブラウザのインストールchrome、Firefoxはいれるかな。 メーラーのインストールWindwosではBecky!を使ってたのだが、どうするか。デフォルトメーラで様子見？ ウイルス対策ソフトの導入Macってどんなソフトがあるかがわからない。。。 あと、１週間触っての感想\nまずは、良かった点。\nいろんなUIがよくできてるセットアップなどきれいな画面で説明が進むのが新鮮だった。あと、フォントのきれいさも新鮮。これは、今までのPCが古いからかもしれないが。 トラックパッドがいいまだなれてないけど、スイスイ動くのでストレスなく作業できる。スワイプとかも画面の移動が楽でいい。 静かで速いSSDのため、静かだし起動がすごく速い。会社で支給されてるPCもSSD（３年くらい前のもの）だけど、こんなに起動などがはやくない。 あとは、気になった点。\nAppStoreでページ間のスワイプができない。かなり使いづらい。Safariと同じイメージでいるので。 手首がいたい手前のエッジ部分が手首に当たってちょっといたい。 アプリインストール時にファンがうるさい動画などはまだ見てないが、Office、XCodeのインストール時にファンの排気音がうるさくなり、結構な熱を発していた ファーストインプレッションはこんな感じ。\nただ、前回も書いたようにうらやましかったのもあり、かなり満足している。 もっと触る時間が欲しいのだが、なかなかとれないのが歯がゆい。。。\n持ち歩くようになったらとりあえず、「７つの言語　７つの世界」を読み進め＋写経をやる予定。\n","date":1312904760,"dir":"post/2011/","id":"c0e423f9ac41cc5b265c95a3e97e3fcb","lang":"ja","lastmod":1312904760,"permalink":"https://blog.johtani.info/blog/2011/08/10/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2/","publishdate":"2011-08-10T00:46:00+09:00","summary":"Mac Book Airのセットアップ関連の備忘録 （今回は備忘録なので、文体も変かも） インストールしたもの（順不同）だいたい、このサイトを参考にした。 Evernote Dropbox","tags":["備忘録"],"title":"MBAセットアップ備忘録(Jugemより移植)"},{"contents":"個人用のPCを８年ぶりに新調しました。\n前回購入した家のデスクトップPCがもう８年ものになりつつあるということで、\nさすがに今年はPCを買おうと思い、年初からいろいろと調べていました。\n当初は次もデスクトップPCを購入する予定でした。ただ、次のような状況ということもあり\nデスクトップは見送ることにし、代わりにノートPCにすることに。\n通勤時間が１時間を超えること\n基本、客先に出向いての仕事\n家でPCに触る時間が少ない（家族サービスのため。）\nで、ここ数週間悩んでいたのですが、Mac Book Air 13インチを購入しました。（そのMBAから初投稿です。）\n実は、Apple製品はこれが初の購入となります。\n対抗馬としてあがっていたのはSonyのVAIO Type Zでした。\n元々ソニスト（ソニー大好き）であり、携帯（Xperia arc）、ウォークマン（Sony）、PSP go、ハンディカムなど、\nソニー製品に囲まれており、デザインもType Zのほうが好みなのですが、MBAを購入しました。\nこの理由なのですが、私が大学時代にさかのぼります。\n情報系の大学の出身で、はじめてきちんと触ったマシンがSunOS4.1（最後の数年はSolaris2.6）でした。\nその後、大学６年間は基本的にEmacsでメールをみて、Emacsで文章を書いていました。\nそのため、社会人になってからもEmacsのキーバインドから抜け出せない日々を送っていました。\n社会人ではやはりWindowsでしたが、XKeymacsというフリーソフトのおかげ（せい？）でEmacsの\nショートカットからは抜け出せないまま。（家のPCはXPで、XKeymacsがインストールされてます。）\n今までの流れだと、何も考えずにWindows7+XKeymacsの流れだったのですが。。。\n職場でWindows7のPCを使う機会があり、XKeymacsを入れてみたのですが、これまでとことなり、\nうまく機能しないことこの上なし（例：chromeのアドレスバーでCtrl+Kとかできないなど）。\nさらに、64bit版の場合、XKeymacsを32bit、64bitの２つインストールしないといけないことに。（32bit用アプリのために32bitを入れないといけない）\nで、数ヶ月使っているのですが、ちょっとずつストレスがたまっている始末。。。\n今までは、「Mac？今更恥ずかしくてかえない」「Mac？おしゃれすぎて無理」「Apple？MSにかわって独占してるの気に食わん」と公言していたのですが。。。\nやはりUnixベースであり、Ctrl+aやCtrl+kが意識せずに利用できるということでコーディングなどを行う場合のストレスよりも保守的な思考を変える方が今後のためにも良さそうだということで、心機一転MBAを購入しました。\nということで、ついにApple教へ入信です。\nまだ、１時間も触ってないですが、すでに洗脳されつつあります。。。\n新しいものに触れるのって楽しいですよね。当分は何をインストールするかなど楽しい悩みでいっぱいになれそうです。（次回はちゃんとした技術的な記事書きたいと、書けるかな、書くぞ、たぶん。。。）\nとまぁ、いろいろと理由を書いてみましたが、要は（オシャレさに）憧れてて、あまのじゃくになって思ってもないこと言ってたんです！\n理由が欲しかったんです！！\nMacかっこえーわーw\nMac miniとかiMacとかもほしーわー\n","date":1312389240,"dir":"post/2011/","id":"7ed1d2efa3e0f0ed6b77eb4eff3d86b3","lang":"ja","lastmod":1312389240,"permalink":"https://blog.johtani.info/blog/2011/08/04/apple%E6%95%99%E3%81%AB%E5%85%A5%E4%BF%A1%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-08-04T01:34:00+09:00","summary":"個人用のPCを８年ぶりに新調しました。 前回購入した家のデスクトップPCがもう８年ものになりつつあるということで、 さすがに今年はPCを買おうと","tags":["備忘録"],"title":"Apple教に入信しました(Jugemより移植)"},{"contents":"かなり遅くなりましたが、第1回 データ構造と情報検索と言語処理勉強会 #DSIRNLPに参加しました。\n帰ってから２日半ほど寝込んでしまい、更新が遅れました。。。\n初の土曜日開催の勉強会でしたが、家族を説得してなんとか参加しました。\nおかげで色々と面白そうなキーワードが拾えてよかったです。（拾っただけで理解するのはかなり時間がかかりそうですが。。。）\nということで、前回同様、個人的にメモを取ったので。誤記などあるかもしれませんが、その時はコメントいただければと。\n0.DSIRNLPについて\n※ボランティアで受付してたので聞けず。\n1.TRIEにトライ！～今日からはじめるTRIE入門～\n@echizen_tm さん\n資料：http://www.scribd.com/doc/58688141/Try-for-Trie\n1.TRIEの説明\n実装についてはあとでスライドをみればいいか。（※ボランティアで受付してたので前半聞けず）\n・パトリシア木\n・Double Array\n・LOUDS\n・XBW\n2.作ってみた\nその1　ベーシック\nQ.ノードのラベルどーする？\n・固定長（ラベル＝1文字）\n定数時間でアクセス可能\n・可変長（ラベル＝任意文字列）\nPatricia木に拡張可能\nA.拡張性を考えて可変長に！\n3.LOUDSとは？\n概要\nJacobsonが提案　Level-Order Unary Degree Sequenceの略（いつからLOUDSになったのか不明）\n構築済みTRIEからLOUDSを構築\n作業領域がO(NlogN)からO(N)に\n・ノードに幅優先で順番（Level-Order）をつける\n・子ノードの数を付ける。Unary符号で実装\n作ってみた\n・UnaryよりVerticalCodeのほうがよさそう\nhttp://d.hatena.ne.jp/echizen_tm/20100531/1275323074\n・dag_vectorを使ってもいいかもよ？\n4.QA\nQ.可変長を配列にすればいいんじゃね？\nA.単純にやると効率悪そう？\n※LOUDSをlucene-gosenに適用するとなんか嬉しいことあるかな？\n現状はDouble-Arrayだけど。\n2. ランキング学習ことはじめ（Solr系に利用できそうな予感。。。ごごご。。。むずかしい。。。）\n@sleepy_yoshi さん NTTのSuharaさん「話がうまい」\n数原　良彦\n自己紹介\n情報検索、ランキング学習をやってる。\n三浦半島在住\nねらい\nランキング学習の認知度を高める、ざっくり伝える。　ごめんなさい　「実装」についてをわすれてた。\n・ランキング学習とは？\nLearning to rank\npreference learningとは違う\n教師あり機械学習で検索ランキングに適用\n・歴史\n従来は単一ランキング\nクエリ・文書関連度（TF-IDF、BM25）\n文書の重要度（PageRank、HITS、SALSAなど）\n近代的なランキングの実装方法\n上記データを利用して関数を適用する。\n・何を正解とするのか？\n適合性評価の作成方法\n評価点数を多段階で点数化\nランキング評価方法\nランキングを正解データと比較\nNDCG（Normalized Discounted Cumulative Gain）　※分類問題におけるモデルの生成\nTraining Data＋学習アルゴリズム＝＞モデル\nランキング学習の訓練データ\n素性や評価はクエリごとに変わってくるTraining data（ここが違う）\nここまでのまとめ\n正解データは適合度至上主義！\nランキング学習手法\n３つのアプローチ\n教師あり機械学習（識別学習）≒\nどのような目的関数/損失関数を\nどのように最適化するのか\nアプローチ\n1.Pointwise手法\n単一のデータに対して損失関数を設定\n2.Pairwise手法\n同一クエリのペアに対して損失関数を設定\n3.Listwise手法\n同一クエリのリストに対して損失関数を設定\nPointwise：あまりつかえない。\n例：二値分類（適合＋１不適合－１）で学習\n補足：Perceptron\n例：PRank\nしきい値と重み両方修正する。\nPairwise：Pointwiseよりいいらしい\n文書ペアで損失を設定\nMQ2007、MQ2008データセットの結果\nPairwise手法とListwise手法を比較しても\nそんなに悪くないらしい\nIR-SVMってので偏りなどを排除できて、精度向上になるよ\nNLP2011でPARankっての発表したよ（手前味噌）\nQA\nQ.じゃんけんみたいに循環しない？（nokuno）\nA.半順序のデータだと起きるが、検索の場合は全順序なので大丈夫だよ\nListwise：Pairwiseよりいいらしい\nListNetってのあり。\nAdaRank\n検索評価指標を直接最適化するブースティング手法\n性能はいまいち？実装は簡単\nその他の話題\nClick-through logs\nQuery-dependent ranking\nFeature selection\nTransfer learning/Domain adaptation\nDiversity/Novelty\n公開Dataset\nLETOR3.0/4.0 Dataset\nMSLR-WEB Datasetなど\n実装\nRankingSVM\nStoch\u0026hellip;.\nLearning to Rank教科書\n英語の資料が今年複数出たみたい\nまとめ\n近代的な検索エンジンは多数のランキング素性を利用\n評価データを用いてランキング素性の最適な重み付けを求める方法\n。。。\n機械学習手法は論文≒実装\nなので、ソースコード見るほうが重要（論文にないノウハウがあるよ）\n3.snappy調べてみた\n@machy　町永圭吾（赤いポータルサイト）\nTopCoderなどで活躍中？\n・snappyは圧縮/伸張ライブラリ\nzlibよりサイズが大きいけど一桁はやいですぞ。\n・インストールなど\ngoogle－gflagsってのがないと動作しないよ。\n・比較してみた（zlib）\n一桁は言い過ぎだけど、はやかった。\n・比較してみた（lzo）\nHadoopで利用されているlzo\nはやかった。\n・仕組みは？\nzlib　辞書式符号化＋ハフマン符号化＝出力\nsnappy　辞書式符号化＋リテラル＝出力\n・辞書式符号化は？\n前に出てきたデータで同じ文字列の部分について端折る\n・ハフマン符号化\nよく出てくる記号を短い符号で置き換えることで圧縮する。\n・snappyの符号化\n基本バイト単位での処理にすることで、高速化してるみたい。\n・snappyの辞書参照元の探し方\nハッシュテーブル利用してマッチする位置を検索\n4byte窓でハッシュ値を計算してハッシュテーブルを更新\n・圧縮しにくいデータ（同じ単語が出てこないパターン）について\n圧縮をあきらめ始める（32回同じのが見つからないと窓の移動幅が1つずつ大きくなる）\n16KB（フラグメント内）での比較回数が1008回に抑えられる。\n・特徴\nハッシュがしょうと移したらあるはずのマッチが見つからないこともある。\nメモリ消費量を抑えるためのハッシュのサイズ？\n最悪ケースのサイズを予め確保してから処理するため、メモリの再確保が起きないのではやいぞ。\n4.類似文字列検索してますか？\n@overlast さん　Yな会社\n1.曖昧な情報を処理する能力\n曖昧な情報を解決しようとする能力が高い。\n例：お笑い芸人の芸がサンプルｗ\n画像検索は曖昧クエリに答える例。。。\nスターバックス、スタバ、SUTABA\nスータバでも画像が出てきた。-\u0026gt;女子高生とかが「スータバ」で画像をアップしてたりするから。\n文字列を使った検索は現代のインフラになってるよね。\n例：iタウンページ\nタイトルとかに「スターバックスコーヒー」って書いてないとだめ。？\n「スタバ」800件くらい　-\u0026gt;　正規化で「ー」消してるんじゃないの？\n「スータバックスコーヒー」0件　ちがうな。シノニム辞書登録してるな。\n曖昧なクエリ（キーワード）から検索できないかなぁ？\n曖昧情報の処理は文字列処理にこそ必要\nなんでヒットしたかがわかるのが正解　なんでヒットしたかわからないけど、ちゃんと出てきたから正解！\n2.ゼロ件ヒット問題（ゼロマッチ）\nピクシブ百科事典\n「ピングドラム」だと17件\n「ピンクドラム」だと0件　しかも真っ白！！\n使いにくいよね。けど、一般的な検索システムの問題だよね。\nGoogleだと出てくる「ピンクドラム」の結果の最初にはピングドラムが出てくる。\n-\u0026gt;リンクがはられているから出てきた？みんなの間違いで助けられてる\n食べログ\n「俺のハンバーグ」\n「俺はハンバーグ」で検索したら。。。「俺はハンバーグで連れは。。。」がヒット-\u0026gt;しらねーよｗ\nまとめ\nゼロ件ヒットは機会損失！！\n3.曖昧な文字列で正しい文字列を探す方法\n正しい文字列って？\n1.表記誤りがない\n2.心の底で求めている\n※異表記同義、同表記異義、異言語表記（日本語の情報を英語で検索）などもある\n正しさはユーザによって変わる。\n正しい文字列をさがす手法\nクエリ表記の正誤という軸\n誤の場合表記をヒントに似た文字列を検索してみる。\n探したい対象が正確か曖昧か\n表記意外がヒントで同じ対象に到達できる？\nどんな情報を手がかりにする？\n編集距離（レーベンシュタイン）\n検索ログ\n4.Apporoの紹介\nチョコ？いや、ロケット？いや、Approximate \u0026hellip;\nhttp://code.google.com/p/apporo/\n中小規模だと使えそう\nSimString\n今後\nよみかな、ローマ字表記に基づく類似文字列検索＋高速化の予定\n技術概要\nSuffix Array\nN-gram Searchベースの近似文字列照合\nBit Parallel Matchingによる編集距離計算\n5.検索と言語と文化（仮）\n@mizuno_takaaki さん\n放送禁止のためメモなし。\n7.自然言語処理におけるargmax操作\n@hitoshi_ni さん\n※順番変更\n・近似解法\nその１　全探索\nいや、無理でしょ、計算が。\nその２　貪欲法\n最適解が出るかは不明。\nその３　ビームサーチ\n上位kこの仮説を保持しながら幅優先探索\n・動的計画法\nすでに最大値がわかっていて、ゴールから眺めてみる。\n逆からたどるとルートがわかるんじゃないか。\nマルコフ性につけ込むことで、わかるんじゃないか。\n計算量：品詞数の2乗\n（品詞数の2乗）＊形態素数\nDPの実装\nViterbiかなぁ？\n・整数計画法（線形-\u0026gt;整数）\n自然言語処理としては整数計画法でだいたいOK。\nアルゴリズム\n・手元の解空間中から許容解を得る\n・分枝してそこから最大値を求める\n最大値＞許容解ならそちらを探索。\nプログラム実装する？\nすごく大変じゃないけど簡単でもないね。\n問題の弱点がわかってるなら実装してもいいよね。\n整数計画法の場合lp_solveなどのフリーのソフトで解くのがいいよ。エクセルでも解けるよ\nILP（整数計画法？）\n問題の切り分けに使える。\nまとめ\nILPで解けたら、いろいろ自分で考えると面白いよ。\nその他のバズワード\n参考資料\n組み合わせ最適化＝1万円超\nアリ本\n6.ソーシャルグラフ分析(導入編)\n@kimuras さん　mixiの木村さん\n・グラフ探索部分はまた今度。\n・テキストマイニングや検索エンジンまわりやってる。\n・ノードが数1千万、エッジが数億のオーダー\n・分散技術の発展によるアルゴリズムの多様化\nこれまで\nRDBからDumpしたデータをKVSに入れて頑張ってた。\nDump部分でデータ構造を毎回構築\n問題点\n変更による再実装、メンテナンスコスト、\nこれから\ngraphDBに取組中。マイニングに最適な感じ\ngraphDBの実装\nOrientDB、Neo4jとか\nNeo4jって\nACIDトランザクション可能\nEmbeddedGraphDatabaseだとAGPLｖ３だから気をつけてね。\nluceneで全文検索インデックスつくってるみたい。\nGremlinってのがquery言語を汎化してるらし。\nとあるSNSのデータを使ってみたよ。\nメモリ64G、CPUは1コアしか使えなかったよ。\nノード：15million、枝：600million\nまとめ\nということで、色々と面白い話が聞けました。特にTRIEの話はかなり興味を持ちました。\n検索周りで嫌というほど出てくるので。まだまだきちんと理解できてないので復習しないと。。。\nlucene-gosenにも関係あるので、しっかり資料をみて復習する予定です。\n基本的に検索系の話に関連があることが多くて面白く聞くことができました。\n「類似文字列検索してますか？」や「ランキング学習ことはじめ」などは身近な話（だけど、なかなかきちんと学習できてない話）でした。\nまた、「自然言語処理におけるargmax操作」では大学でやっていた線形計画法などのわかりやすい説明で10年経ってようやく理解ができた次第です。。。（もっとちゃんと勉強しとけば。。。）\n懇親会にも参加し、研究に近い分野の方が多い中でいろいろな話が聞けたのはよかったと思います。\n次回もいろいろなキーワードを拾いたいのでぜひ参加したいです。\n","date":1311737580,"dir":"post/2011/","id":"3811b40721f7ca651887aac4eb17f9f0","lang":"ja","lastmod":1311737580,"permalink":"https://blog.johtani.info/blog/2011/07/27/%E7%AC%AC1%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-07-27T12:33:00+09:00","summary":"かなり遅くなりましたが、第1回 データ構造と情報検索と言語処理勉強会 #DSIRNLPに参加しました。 帰ってから２日半ほど寝込んでしまい、更新が","tags":["勉強会"],"title":"第1回 データ構造と情報検索と言語処理勉強会に参加しました。(Jugemより移植)"},{"contents":"以前から春山さんのブログ（リンク）や勉強会で耳にはしていたのですがソースは読んでいませんでした。 先日、Luceneにcontributeされた（リンク）ので軽くソースを読んでみました。\n公式サイトはこちら\nまずはMeCabのページにある比較表（リンク）を基準に特徴を調べてみました。せっかくなので、lucene-gosenも隣に。\n\u0026nbsp; Kuromoji lucene-gosen 解析モデル なし（学習機能なし） なし（学習機能なし） コスト推定 なし（学習機能なし） なし（学習機能なし） 学習モデル なし（学習機能なし） なし（学習機能なし） 辞書引きアルゴリズム Double Array Trie Double Array Trie 解探索アルゴリズム Viterbi Viterbi 連接表の実装 2次元 Table 3次元 Table 品詞の階層 無制限多階層品詞？ipadic、unidic形式に対応 無制限多階層品詞 未知語処理 字種 (動作定義を変更可能)（おそらく。） 字種（変更不可能） 制約つき解析 たぶん、不可？ たぶん、不可？ N-best解 不可能 不可能 こうやって比較してみるとlucene-gosen（Sen）とあまりかわりはありませんが、lucene-gosenが少し古いのがわかりますね。。。\nKuromojiで利用出来る辞書は現時点ではMeCab IPADIC、UNIDICの2種類のようです。\nソースを読んでの感想ですが、やはりMeCabが偉大だということがよくわかりました。 Senよりも新しいMeCabの処理に似ている点が多いです。解探索アルゴリズムや連接コスト表が特に。 MeCab向けの辞書を利用しているためというのもあるかと思います。\nKuromojiが特徴的なのは「searchモード」と呼ばれるモードが用意されていることです。 公式サイトにある例ですと、「関西国際空港」が「関西」「国際」「空港」というTokenで出力されます。 ソースを見たところViterbiアルゴリズムで辞書を探索しているときに特定の条件でコストをカサ増しすることで、結果を変えるという処理を行っているようです。\n全て漢字の単語：3文字以上の場合に「(単語の長さ-3)*10000」をコストに加算 その他の単語：7文字以上の場合に「(単語の長さ-7)*10000」をコストに加算 このようにコストを変化させることで「空港」でも「関西国際空港」という文字を含む文章が検索できる仕組みになっています。 また、「拡張searchモード」と呼ばれるモードも存在し、こちらは、未知語をuni-gramで区切って出力を行うようです。\nソース上で確認しただけで、未確認ですが、GraphvizFormatterというクラスがあるので、Graphvizで読み込める形式で形態素解析の結果が出力されるかもしれません。（すみません、確認してなくて。）\n未知語の処理やsearchモードなど面白い機能があるので、試してみるのもいいかもしれません。lucene-gosenを考えていく上でも参考になりそうです。\n最後に余談ですが、FAQのページ（リンク）が面白いです。。。\n","date":1311132540,"dir":"post/2011/","id":"5a765f9668608a39333fa90cf462657e","lang":"ja","lastmod":1311132540,"permalink":"https://blog.johtani.info/blog/2011/07/20/kuromoji%E3%82%92%E8%AA%BF%E3%81%B9%E3%81%A6%E3%81%BF%E3%81%9F/","publishdate":"2011-07-20T12:29:00+09:00","summary":"以前から春山さんのブログ（リンク）や勉強会で耳にはしていたのですがソースは読んでいませんでした。 先日、Luceneにcontributeされ","tags":["形態素解析"],"title":"Kuromojiを調べてみた(Jugemより移植)"},{"contents":"忘れてしまうので、備忘録を残しておきます。 一応、ソースには少しずつコメントをいれてはいるのですが。 私は残念ながら、自然言語処理は初心者に毛が生えた程度（現在、鋭意勉強中）で、対応方法に問題があるかもしれません。気づいた方はコメントをいただけると助かります。\n辞書ファイルについて NAIST-JDic for MeCabの辞書ファイルは以下の構成になっています。\nファイル名 メモ char.def 文字種の設定 feature.def 辞書学習用の設定？ left-id.def左文脈IDのマスタ（左文脈ID、品詞情報） matrix.def 連接コスト表（前件文脈ID,後件文脈ID,連接コスト） pos-id.def 品詞IDのマスタ（品詞情報、ID） rewrite.def rewrite情報（左右文脈に出現した場合のそれぞれの品詞情報のrewriteルール。辞書学習で主に利用） right-id.def 右文脈IDのマスタ（右文脈ID、品詞情報） unk.def 未知語の品詞情報（文字種ごとに未知語のコスト、左右文脈ID、品詞情報が記載されている） naist-jdic.csv 単語辞書（単語、左右文脈ID、単語コスト、品詞情報、読みなど記載） 現時点では、MeCabDicPreprocessorでは以下のファイルを利用しています。\nleft-id.def matrix.def right-id.def naist-jdic.csv 上記以外のファイルは現時点では利用しない実装になっています。 ただし、rewrite.def、unk.def、char.defについては利用したほうがよりMeCabに近い結果が得られるような気がしています。（特に文字種ごとのコストを利用することは有効と思われます。）\nPreprocessorでの処理について lucene-gosenはSenの後継であり、MeCabの昔のバージョンを移植したものがベースとなっています。 lucene-gosenとMeCabの現時点での実装の大きな違いとして、連接コスト表の違いがあります。 ここからは憶測になってしまいますので、注意してください。（論文を探せばどこかにこの実装の変化の過程が記載してあるかもしれないですが、まだ探していません、すみません。） 過去のMeCabではChaSen向けの辞書を利用していました。 ChaSenでは連接コスト表が3つの項（前の前、前、後）から構成されていました。（n項まで定義可能らしい） ですので、lucene-gosenのViterbiアルゴリズムの引数も3つのノードが引数となっています。 lucene-gosen向けの連接コスト辞書も同様の作りになっています。 一方、現在のMeCabは先ほど書いたとおり、matrix.defでは2項の連接コスト表（前、後）となっています。この違いを保管するために、Preprocessorでは、matrix.defを3項にするために一番左（前の前）については任意の品詞を採用できるように「,,,,,,*」のみを設定しています。\n現時点では、Preprocessorの出力である中間ファイルを共通の形式に出力することで、DictinaryBuilder以降の処理に変更を加えることなくNAIST-JDic for MeCabへの対応を行う形を取りました。まずは使えるようにするのが先かと思いまして。 ただ、MeCabの辞書の構成から考えると中間ファイルに落とし込む処理に無駄があると感じています。 matrix.defでせっかく、IDによる連接コスト表を構成しているのに、IDを品詞情報の文字列に戻したconnection.csvを生成していますので。\nということで、備忘録でした。 あとは、テストをどうするか（正解をどう考えるか）なども考える必要があります。現時点での悩みの種です。。。アイデア募集中です。\n","date":1310432760,"dir":"post/2011/","id":"c70b78fd0b5dffcd38322355e9c2471e","lang":"ja","lastmod":1310432760,"permalink":"https://blog.johtani.info/blog/2011/07/12/naist-jdic-for-mecab%E3%81%AEpreprocessor%E3%81%AE%E5%AE%9F%E8%A3%85%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E5%82%99%E5%BF%98%E9%8C%B2/","publishdate":"2011-07-12T10:06:00+09:00","summary":"忘れてしまうので、備忘録を残しておきます。 一応、ソースには少しずつコメントをいれてはいるのですが。 私は残念ながら、自然言語処理は初心者に毛が","tags":["lucene-gosen"],"title":"NAIST-JDic for MeCabのPreprocessorの実装に関する備忘録(Jugemより移植)"},{"contents":"lucene-gosen 1.1.1をリリースしました。\n先日お知らせしたバグ修正を取り込んだjarを用意いしました。\nダウンロードはこちらから\n","date":1309777240,"dir":"post/2011/","id":"229975f1e84b5088e819cd5f2dc43080","lang":"ja","lastmod":1309777240,"permalink":"https://blog.johtani.info/blog/2011/07/04/lucene-gosen-1-1-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2011-07-04T20:00:40+09:00","summary":"lucene-gosen 1.1.1をリリースしました。 先日お知らせしたバグ修正を取り込んだjarを用意いしました。 ダウンロードはこちらから","tags":["lucene-gosen"],"title":"lucene-gosen 1.1.1リリース(Jugemより移植)"},{"contents":"Solr/Lucene 3.3がリリースされました。（速報）\n以下、各サイトへのリンクです。\nSolrリリースのお知らせ\nLuceneリリースのお知らせ\nリリースのタイミングがどんどん早くなってる。。。\n","date":1309501779,"dir":"post/2011/","id":"10eb1e7dc64d8ca3dad92641dadb5de7","lang":"ja","lastmod":1309501779,"permalink":"https://blog.johtani.info/blog/2011/07/01/lucene-solr-3-3%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/","publishdate":"2011-07-01T15:29:39+09:00","summary":"Solr/Lucene 3.3がリリースされました。（速報） 以下、各サイトへのリンクです。 Solrリリースのお知らせ Luceneリリースのお知らせ リリースのタイミ","tags":["solr"],"title":"Lucene/Solr 3.3リリース（速報）(Jugemより移植)"},{"contents":"「Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）」に参加しました。300名入るイベントルームでしたが、後ろの方まで人が埋まっていました。\nということで、主に自分用ですが、メモを取ったので。\n※二次会行きたかった。。。\n1.「鉄道システムへの誘い」\n@ayasehiro（本名無理w）\nHadoopの話はありません。\n○鉄道系基幹システムの開発\n実態：\n耐用年数：１０年以上\n開発期間：数年～５年程度\n開発規模：～10Mステップ、10k人月～\nほとんどテスト、しかも異常系が主体。\n夜間に実際に鉄道を走らせて試験したり。\n開発サイクルが長い\n人材育成が難しい、ノウハウがたまらない。\n開発自体はほとんど時間がなく、設計・製造・試験など新規技術の採用が難しい。\n開発４年前の調査・検証自体が２年程度。\nHadoopも調査中。\n○鉄道システム３大システム\nマルス（予約オンラインシステム）（1960～）\nコムトラック（運行管理システム）（1972～）\nヤックス（ヤード自動化システム）（1968～1984）\n○鉄道輸送システムとは\n用語：\n運行を計画する=\u0026gt;輸送計画\n列車を運行する=\u0026gt;運行管理\n需要想定＋営業施策＋その他（お召し列車など）＝列車ダイヤ作成\n基本計画（長期）＋短期計画（数日～四半期程度）＝列車ダイヤ（重ねあわせてできあがり）\nダイヤの計画（発車時刻など）と車両運用（車両自体の走る組み合わせ（仮の車両））の作成\n＋乗務員運用（乗務員の運用計画）\n運行管理：\nなにも起きなければすることなし。（車両故障、天候、人身事故などによる整合性を取る作業）\n＝事前に計画した輸送計画をすべて見直し\n遅延の検知は？\n昔：人による伝令\n今：システムによる検知（レールに電流流して検知）\n運転整理（実際に遅れた）：\n部分運休、折り返し駅の変更などにより対応\n元の計画になるべく近づく形で修正していく。\n新幹線、山手線、京浜東北線などは速度信号という信号が表示される。\n線路上に信号はないらしい。\n○鉄道システムを取り巻く情勢\n少子高齢化・人口減少のため凋落産業となっている。\n社会インフラの責務＝動くのが当たり前\n2007年問題（ベテランの引退）＝スジ屋さんは最近いないらしい。\n高度な判断支援をするシステムが必要\n連続稼動＝分散技術を適用できない？\n関係各所との情報共有\n計画立案のための情報支援＝最適化技術を適用できない？\n○分散処理技術の適用\n個人的な感想\n可用性（連続稼動）のための仕組み\nバッチ処理\n○分散技術の適用\n・連続稼動\nactive-active構成がメイン\n主系の出力だけを行う。問題が出れば副系の出力。\n3系統の出力を比較器にて出力もある\nmagiシステム\n問題点：\nハードが高い（H社）\nソフトウェアの作り込みが複雑＝テストが前パターンできない\n解決案：\n汎用的なハードが使いたい。\n作り込みも減らしたい\n・バッチ処理：\nAsakusa使えないかなーw\n○最適化技術の採用\nコンピュータ技術の発展\n2007年問題\n職人に言わせれば最適化はいらない、俺の言うことを聞けｗ\n・車両運用のモデリング\n車両数大=\u0026gt;組み合わせ大\n制約条件が多い\n車両運用の場合、走行累積キロの条件もある\n-\u0026gt;有向グラフにモデル化される。（ただし、グラフ化するまでが大変）\n・乗務員運用のモデリング\n車両と違い、乗務員は1回で2人とか運べる（運転士＋移動する人とか）\n・車両割当のモデリング\nやはり、グラフ化が可能\n・乗務員交番のモデリング。。。など\n結構一般的なモデルに落とし込める。ただし、落し込みが大変。\n机上研究だったものが、コンピュータの発展により実証研究になりつつある。\n○まとめ\n鉄道システムはまだまだ未到の領域が残っている。\n開発サイクルが長いため、保守的な開発になる（35年前の設計思想からあまり変わってなかったりする）\nしかし業務要件やシステム利用者の意識は変化している\n興味を持たれた方は、ぜひ、我社に！（社名は2次会でｗ）\n○Q\u0026amp;A\nQ：鉄道システムのカルチャーってイケイケ？保守的？（@okachimachiorgさん）\nA：最新技術も知らないとだめじゃないかという人が出てきている。\nコア部分（安全第一なところ）＋周辺領域（ある程度融通が効きそうな部分）と考えることができるんじゃないかって人も出てきている。\nJR九○＝先進的\nJR四○、北○道＝お金ない\nJR○海＝超保守（企業的に超保守）\nJR東、西＝うーむ？\n東京メト○（運行計画）、阪○＝先進的\n京○急行＝基本人間で進路制御w\n基本的には新しいものには興味をもつ人たちでは。\nQ：Su○caとかで分散処理は利用出来るんでは？\nA：匿名なので外側から見ていると分散処理はいろいろ使えるんでは？\nログデータからいろいろできるんじゃないの？活かすべきでないの？\n使いどころはいっぱいある。\nQ：鉄道システムでどうしようもなくなったことはあるか？\nA：保守体制が一番気になる。\nOSSとかならまだ調べられる。ミドルウェアなどの保守契約が必要。\n保守体制が確立されてればある程度の保守費用は飲み込む。\nどうしようもないことはないが、今すごく困ってることは\nExcelで帳票を出したいとかいわれること。（ちょっと前に作ったシステムでExcel2003。バージョンあげると速度が遅くなったりするｗ）\nilog社のものを使ってたが、IBMに買収されて保守費用があがってこまってるｗ\n保守が10年と長いため、サポートなどの折衝が必要。\nQ：最適化の適用範囲は？\nA：走行順序（どこで追い抜くか）の算出に活用。ほぼ完成でユーザ教育中。\n1列車の波及がかなり影響が出る。ダイヤだけ見ると列車だけだが、乗務員も関係しており、大変。\nある時点から終電までを最適化の対象としたりして割り切っている。\nまた、不足分について算出が出来れば、そこで打ち切ったりもする。\n2.「九州電力におけるHadoopの取り組みについて」\n株式会社キューデンインフォコム e－ビジネス部　@hisashi_yano\n概要：2年間関係したOSSをメインにしたシステムの話。\n○九州電力の概要\n現在風当たりが強い業界。\n東電の1/10くらい\n部門ごとに大手ベンダーが関わってる。\n○Hadoop採用の経緯\n部門ごとに個別最適なシステムを導入していてベンダーロックインされてる。\n・ホストのリプレース\n・両現用センター構成への対応\n・スマートグリッドへの対応\n問題点\n・コスト削減\n・技術革新への中の人の対応（内部でも問題を理解できるように）\n・商用パッケージのカスタマイズの限界\n・脱ベンダーロックイン（実は楽なんだけど。。。）\n○過去2年間の研究内容\n・H21年度の結果\nテーマ：クラウドの要素技術の研究\nKVM、Eucalyptus、wakame、hadoop　性能比較：VMWareとKVM-\u0026gt;ベンチマーク比較\n結論：性能的にあまり問題なし。\nMapReduceの耐障害性など\nダミーデータにより台数増加による影響を検証\n結論：台数大-\u0026gt;性能向上\nストリーミングは性能劣化する\nスループットはリニアに向上\n信頼性は？\n実行中にノードを抜いたりして検証。\n結論：問題なし。\nクラウド環境におけるシステム管理手法\n複数ハードで1アプリという構成になる。\n監視対象が膨大になる。\n障害発生時の切り離しや監視対象も膨大。\nデータセンター自体を監視する仕組みが必要では？というところで終了。\n・H22年度の結果\n分散に特化した研究\n前年度の課題\nサーバの仮想化・管理に関する課題\n分散処理に関する課題\n分散処理環境の運用監視に関する課題\n目的：\nHadoopを本番への適用（実際にはダミーデータ＋本番の仕組み）\n柔軟なサーバ統合基盤（サーバを起動-\u0026gt;バッチを起動-\u0026gt;回す仕組み）＝MonkeyMagic\nlibvirtを使ってる\n50台の仮想サーバの起動が10数分で完了。\n運用監視基盤（monkey magic）\n仮想、実サーバ混在の監視\n監視状況（サーバの状況）から判断して制御する仕組みを構築\nDSLにてルール（判断＋制御）を指定\n・ジョブの監視\n・ジョブの実行管理\n・構成管理の省力化\nvolanteと連携が可能＝AmazonWebServiceとも連携可能\n・サーバリソース＋アプリケーションの一括監視が可能\n分散バッチ処理の概要\nRDBからKV形式にして抽出し、MRで回してRDBに戻すという研究\n対象：\n配電部門（電柱の設備情報の目視検査）のデータの月間バッチ処理\n現状：\n19時間程度かかってる。\nテスト環境：\n実サーバ2台（仮想10台）\nMySQL、Javaで実装\n処理内容\n電柱104万本\n巨大バッチを分割して実装\n結果\nMySQL1台では15日以上かかる処理（現行システムで19時間）\n処理が32分で終了！他でも効果でるよね。\nバッチ短縮の理由は？\n1.データアクセスが分散された\n2.処理の並列化（多重化出来る部分がうまくできた）\n分散処理を書くのに2名死亡。。。\n適用基準の策定、開発ガイドライン、フレームワーク整備などが必要。\n・H23年度は？\nAsakusaの適用など。\n・さらに今後は？\nスマートグリッドへの適用\n-\u0026gt;メーターの交換が必要だが、10年くらいかかる\n-\u0026gt;スパンが長い（10年）ので商用製品だときつい？\nデータ量も半端ない。\nテネシー州とClouderaでOpenPDCってのやってるらしい。\n電力と気温の関係は密接な関係あり。\nエアコンが割合を占めてるから。\n過去実績と予想気温データから分析するのにHadoop使える！\n・2年間やってきて思うこと\n将来目指すべき理想像を掲げるのが重要\n新技術導入は段階を踏むことが必要\nコミュニケーション大切！\n○Q\u0026amp;A\nQ：仮想化環境のオーバヘッドは？（I/O）\nA：台数を増やしたときにどうなるか？というのを検証したかった。\nアプリ配布も考えていたので、物理サーバに縛られたくなかった。\nQ：仮想化に関して気をつけたM/RのPGで気をつけたことありますか？\nA：まったくないです。\nQ：日本でスマートグリッドははやるの？\nA：電力会社的にはやりたくない。費用対効果があまりない。\nQ：今後のスケジュールは？\nA：文書管理システムの組織名変更などの処理時間が540時間とかでてくるらしい。\nこれをHadoopで対応してみようかと思ってる。\nQ：Asakusaをどう評価していくのか？\nA：開発効率性があがるか？は検証する予定。1/3くらい楽になるんじゃないかなぁ？byのぐちさん\nバッチの種類などにもよると思うが、標準化も指標にする予定。\n結果はまたこの場で報告する予定。\nQ：Asakusa＋MonkeyMagicの連携はどんなこと考えてる？\nA：MonkeyMagicを運用基盤として行く予定。合意が取れればだけど。\n※MonkeyMagicもOSSにするよー\nまとめ\nHadoopから少しずつ離れつつありますが、やはり興味があるので、非常に楽しく話を聞けました。\nまた、今回はインフラ分野のシステムということで、システムに要求されるレベルや\n運用周りにも気を配っている話が聞けたのが収穫でした。保守期間が長いため、テストが長い＝\n運用もしっかりと考慮を入れた設計、実装が必要になるというのは最もだと思います。\nただ、少しずつ修正が入るアジャイルなども同様かと。\nMonkeyMagicが出来上がってきた背景の話を聞いて、さらに興味が湧いてきたところです。\n今後もかかわりが少ないかもしれないですが、ウォッチしていきたいと思いました。\nただ、興味あるモノが多すぎるので、優先度をつけつつこなして行かないと。。。\n少しずつでも身につけていきたいと思う今日このごろです。\n※追記：Twitterでコメントを頂いたので、忘れないように追記。\nコメントを貰えるだけでもうれしい。やはり、アウトプットしたらフィードバック貰いたいし。\nありがとうございます！\nTwitter / @cocoatomo: あの質問をまとめるとこうなるのかぁ…… 最適化そのも \u0026hellip;\nTwitter / @cocoatomo: @johtani すみません, コメントはコメント欄 \u0026hellip;\nTwitter / @cocoatomo: @johtani そこらへんの理論って最後には計算量 \u0026hellip;\nTwitter / @cocoatomo: @johtani あの話し振りだとどうもまだ本格的に \u0026hellip;\nあと、まとめも出来ていたので、ついでに。\nTogetter - 「2011/06/29_Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回） #hadoopmodeling」\n関連するブログも見つけたので。\n第5回Hadoop座談会の感想 - ひしだまの変更履歴\nHadoopモデリング座談会（第5回）へ行ってきました - 虎塚\n","date":1309356600,"dir":"post/2011/","id":"49ba23148db9effdc3979aa0fe5876ea","lang":"ja","lastmod":1309356600,"permalink":"https://blog.johtani.info/blog/2011/06/29/hadoop%E3%82%92%E4%B8%AD%E5%BF%83%E3%81%A8%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E7%92%B0%E5%A2%83%E3%81%A7%E3%81%AE%E9%96%8B%E7%99%BA%E6%96%B9%E6%B3%95%E8%AB%96%E3%83%A2%E3%83%87%E3%83%AA%E3%83%B3%E3%82%B0%E8%A8%AD%E8%A8%88%E6%89%8B%E6%B3%95%E7%AD%89%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E5%BA%A7%E8%AB%87%E4%BC%9A-%E7%AC%AC5%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-06-29T23:10:00+09:00","summary":"「Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）」に参加しました。300名入るイベントルー","tags":["hadoop"],"title":"Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）に参加しました。(Jugemより移植)"},{"contents":"以前、こちらで話題に上がっていた「未知語」に関するcompositePOSのエラーの件を調査しました。（Twitterでも流れてました。） 次のような条件の場合にエラーが発生するようです。\ncompositePOSの設定に構成品詞として「未知語」が指定されたエントリが存在する。 未知語が連続して出現する文字列をanalyzeする。（例：ニンテンドーDSi） ということで、trunkに修正版をコミットしました。 Issueはこちら。\n※お茶をにごす感じの日記になってしまいました。次回はマシな記事を書く予定です。。。\n6/29追記：恥ずかしいバグをいれこんでしましました。。。 ということで、trunkに再度修正版をコミットしました。\n","date":1309232160,"dir":"post/2011/","id":"f6dff70097776e24c2a7c9c0f2514f79","lang":"ja","lastmod":1309232160,"permalink":"https://blog.johtani.info/blog/2011/06/28/compositeposcompositetokenfilter%E3%81%AE%E3%83%90%E3%82%B0%E4%BF%AE%E6%AD%A3/","publishdate":"2011-06-28T12:36:00+09:00","summary":"以前、こちらで話題に上がっていた「未知語」に関するcompositePOSのエラーの件を調査しました。（Twitterでも流れてました。） 次","tags":["lucene-gosen"],"title":"compositePOS（CompositeTokenFilter）のバグ修正(Jugemより移植)"},{"contents":"lucene-gosenのtrunkbranches/impl-mecab-dicにNAIST-JDic for MeCabの辞書を利用出来るPreprocessorをコミットしました。\nビルド方法は次のとおりです。\n$ cd lucene-gosen-trunk $ ant -Ddictype=naist-mecab 現在のstable版で利用できる辞書は「ipadic」「naist-chasen」の2種類でした。\n[以前の記事](http://johtani.jugem.jp/?eid=4)に書きましたが、naist-chasenの辞書でも2008年の更新となっています。\n今回コミットしたPreprocessorでは[NAIST-JDicのサイト](http://sourceforge.jp/projects/naist-jdic/)で公開されているMeCab向けの辞書である「mecab-naist-jdic-0.6.3-20100801」を利用出来るようになります。\nただし、lucene-gosenは昔のMeCabから派生したSenをもとにしていますので、最新のMeCabが持っている機能は\n利用できません。\nMeCab向けの辞書のうち一部のもの（matrix.def、naist-jdic.csvなど）を利用してlucene-gosen向けの辞書の中間ファイルを生成する仕組みになっています。\nまだ、仮実装版ということで、とりあえず動作するバージョンとなっています。\nまだテストが不十分ですが。。。\n利用してみて問題などあれば、lucene-gosenの[issue](http://code.google.com/p/lucene-gosen/issues/list)に登録していただくか、コメントを頂ければと思います。\n※更新が週1回に落ちてきてるので、もう少し頑張らねば。\n※2011/07/04追記 trunkにコミットしていましたが、branchに一旦移動しました。 仮実装として一旦コミットしたので、trunkとは別でテストする必要があるかと思った次第です。 ということで、試してみたい方は、[branches/impl-mecab-dic](http://code.google.com/p/lucene-gosen/source/browse/#svn%2Fbranches%2Fimpl-mecab-dic)にありますので、触ってみてください。 ","date":1308609480,"dir":"post/2011/","id":"991285e3967c3295b4ff2dcd835f7c61","lang":"ja","lastmod":1308609480,"permalink":"https://blog.johtani.info/blog/2011/06/21/naist-jdic-for-mecab%E5%AF%BE%E5%BF%9C%E7%89%88%E4%BB%AE%E5%AE%9F%E8%A3%85/","publishdate":"2011-06-21T07:38:00+09:00","summary":"lucene-gosenのtrunkbranches/impl-mecab-dicにNAIST-JDic for MeCabの辞書を利用出来るPre","tags":["lucene-gosen"],"title":"NAIST-JDic for MeCab対応版（仮実装）(Jugemより移植)"},{"contents":"前回、naist-chasenではアルファベットが別々の単語としてanalyzeされてしまうという話をしました。\nただ、これだと、英単語が含まれた文章を形態素解析すると、英単語がアルファベット単位に区切られてしまい、 単語の意味をなさなくなってしまいます。\nlucene-gosenでは、この問題に対応するための方法が提供されています。 CompositeTokenFilter（compositePOS）という機能です。\n文字通り「トークン」を「合成」するための機能になります。\n利用するためには以下の作業が必要です。（※Solrでのの利用方法を説明します。）\ncompositePOS設定ファイル（composite_pos_ja_naist-chasen.txt）の用意 schema.xmlのtokenizerにcompositePOS設定を追加 まずは、compositePOS設定ファイルの記述方法について説明します。 compositePOS設定ファイルには１行につき１つのcompositeの設定を記述していきます。 記述方法は次のようになります。品詞名を半角スペース区切りで記述します。\n連結品詞名 構成品詞名1 構成品詞名2 ... 構成品詞名n それぞれは次のような意味を持ちます。\n連結品詞名：合成したあとのトークンの品詞として出力する品詞名 構成品詞名：合成したい品詞名（スペース区切りで複数指定可能） TokenizerのcompositePOS機能は、構成品詞に定義されたトークンが連続して出力された場合に、 結合（合成）して１つのトークン（連結品詞名）として出力します。 また、以下のように構成品詞名が１種類で連続品詞名としても利用する場合は次のように省略した記述も可能です。\n以下にcompositePOSファイルの設定例を上げます。 ※なお、現時点では#によるコメント機能はありません。ので、記述した内容がそのまま利用されます。\n名詞-数 未知語 記号-アルファベット １行目は連続した数字を1つのトークン（名詞-数）として出力する設定です。（連続品詞名＝構成品詞名として省略して記述した例になります。） 2行目は連続したアルファベットを１つのトークン（未知語）として出力する設定です。\n次にSolrのschema.xmlにlucene-gosenのtokenizerを利用するフィールドタイプの設定を記述します。 $SOLR_HOME/conf/schema.xmlに以下を追加します。\u0026lt;types\u0026gt;～\u0026lt;/types\u0026gt;タグの間に記載します。\n... \u0026lt;types\u0026amp;gt; ... \u0026lt;fieldType name=\u0026amp;quot;text_ja\u0026amp;quot; class=\u0026amp;quot;solr.TextField\u0026amp;quot; positionIncrementGap=\u0026amp;quot;100\u0026amp;quot;\u0026amp;gt; \u0026lt;analyzer\u0026amp;gt; \u0026lt;tokenizer class=\u0026amp;quot;solr.JapaneseTokenizerFactory\u0026amp;quot; compositePOS=\u0026amp;quot;composite_pos_ja_naist-chasen.txt\u0026amp;quot;/\u0026amp;gt; \u0026lt;/analyzer\u0026amp;gt; \u0026lt;/fieldType\u0026amp;gt; \u0026lt;/types\u0026amp;gt; ... 重要なのはtokenizerタグのcompositePOS属性になります。ここに1.で記載したファイルを指定します。指定したファイルはschema.xmlと同じディレクトリに配置します。 以上が利用するための設定です。\n前回同様、「このComputerは、10回に1回の割合で起動中に青い画面が表示されます。」という文章をanalyze画面で解析した結果を示します。\nとまぁ、記事を書きましたが、すでにこちらで出ている話ですね。。。\nみなさん手が早くて困ってますｗ\nちなみに、上記の設定の場合、「100,000」や「3.14」といった文字列は「100」「,」「000」という形で出力されてしまいます。これらも数字とみなしたい場合は「名詞-数 名詞-数 記号-句点 記号-読点」という設定で１つのトークンとして出力されます。ただし、「。」も「記号-句点」なので注意が必要です。\n※なお、今回はlucene-gosen-1.1.0、Solr3.2を利用した例になっています。 ","date":1307977200,"dir":"post/2011/","id":"50f43b1726cf61066ef8656477b226be","lang":"ja","lastmod":1307977200,"permalink":"https://blog.johtani.info/blog/2011/06/14/compositepos%E3%81%AE%E5%88%A9%E7%94%A8%E4%BE%8Bnaist-chasen%E3%81%A7%E3%81%AE%E8%8B%B1%E5%8D%98%E8%AA%9E%E3%81%AE%E5%87%BA%E5%8A%9B%E6%96%B9%E6%B3%95%E4%BE%8B/","publishdate":"2011-06-14T00:00:00+09:00","summary":"前回、naist-chasenではアルファベットが別々の単語としてanalyzeされてしまうという話をしました。 ただ、これだと、英単語が含ま","tags":["lucene-gosen"],"title":"compositePOSの利用例（naist-chasenでの英単語の出力方法例）(Jugemより移植)"},{"contents":"lucene-gosenの1.1.0がリリースされました。\n大きな目玉はJapaneseTokenizerが出力する形態素に関するデータを遅延ロードすることで、パフォーマンスの改善を行ったことです。\n詳しくは関口さんのブログで実測されてます。さすが、早い。。。 あと、先日リリースされたLucene/Solr 3.2への対応も行われています。\nlucene-gosen-1.1.0のダウンロードはこちらから。\nうーん、中身がない記事だ。。。\n","date":1307934480,"dir":"post/2011/","id":"eeef60efe889349870426d10edc694be","lang":"ja","lastmod":1307934480,"permalink":"https://blog.johtani.info/blog/2011/06/13/lucene-gosen-1-1-0-%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2011-06-13T12:08:00+09:00","summary":"lucene-gosenの1.1.0がリリースされました。 大きな目玉はJapaneseTokenizerが出力する形態素に関するデータを遅延","tags":["lucene-gosen"],"title":"lucene-gosen 1.1.0 リリース(Jugemより移植)"},{"contents":"lucene-gosenをSolr/Luceneで利用する場合、TokenFilterを利用してTokenizerが出力したToken対してさまざまな処理（Tokenに対する正規化や展開など）を追加することが可能です。\n今回は現在（ver. 1.0.1）用意されているTokenFilterについて説明します。 以下はTokenFilterの一覧です。 「フィルタ名」にはSolrのschema.xmlで記述するクラス名を書いてあります。\nフィルタ名(Factory名) 概要 solr.JapaneseWidthFilterFactory 全角のASCII文字を半角に、半角カタカナを全角にするフィルタ。例：「Ｃｏｍｐｕｔｅｒ」-\u0026gt;「Computer」 solr.JapanesePunctuationFilterFactory 区切り文字、記号などを除外するフィルタ。[※1](#token_filter_kome_1) solr.JapanesePartOfSpeechStopFilterFactory 設定ファイルに記載した品詞に該当するTokenを除外するフィルタ。ファイルは「tags=\"ファイル名\"」とfilterに記載。なお、ここで記述する品詞とはanalysis画面に表示される「partOfSpeech」の完全一致となります。 solr.JapanesePartOfSpeechKeepFilterFactory 設定ファイルに記載した品詞に該当するToken\"以外\"を除去フィルタ。ファイルは「tags=\"ファイル名\"」とfilterに記載。なお、ここで記述する品詞とはanalysis画面に表示される「partOfSpeech」の完全一致となります。 solr.JapaneseBasicFormFilterFactory Tokenを基本形に変換するフィルタ。例：「悲しき」-\u0026gt;「悲しい」 solr.JapaneseKatakanaStemFilterFactory カタカナの長音（ー）の正規化フィルタ。4文字以上のカタカナのみの文字列の最後の長音（ー）を除去した文字列に変換します。例：「コンピューター」-\u0026gt;「コンピュータ」、「コピー」-\u0026gt;「コピー」 上記のTokenFilterをJapanizeTokenizerを利用するフィールドタイプに設定することで 各フィルタによる機能が有効になります。 schema.xmlの記載に関する詳細についてはこちらを参考にしてください。\n※1　Characterクラスの以下の定数に相当する文字が。SPACE_SEPARATOR、LINE_SEPARATOR、PARAGRAPH_SEPARATOR、CONTROL、FORMAT、DASH_PUNCTUATION、START_PUNCTUATION、END_PUNCTUATION、CONNECTOR_PUNCTUATION、OTHER_PUNCTUATION、MATH_SYMBOL、CURRENCY_SYMBOL、MODIFIER_SYMBOL、OTHER_SYMBOL、INITIAL_QUOTE_PUNCTUATION、FINAL_QUOTE_PUNCTUATION\n","date":1307344980,"dir":"post/2011/","id":"4b046ac6a4796fb1338f0481dbd4003d","lang":"ja","lastmod":1307344980,"permalink":"https://blog.johtani.info/blog/2011/06/06/lucene-gosen%E3%81%AEtokenfilter%E3%81%9F%E3%81%A1/","publishdate":"2011-06-06T16:23:00+09:00","summary":"lucene-gosenをSolr/Luceneで利用する場合、TokenFilterを利用してTokenizerが出力したToken対して","tags":["lucene-gosen"],"title":"lucene-gosenのTokenFilterたち(Jugemより移植)"},{"contents":"辞書の特性について 現在lucene-gosenでは以下の2つの辞書が利用可能です。 簡単に違いについて説明します。\nIPAdicの辞書について\nバージョン：2.6.0（※IPAdicとして公開されている最新は2.7.0） 最終更新日：2003/06/19 登録単語数：約24万語 NAIST-Jdicができたためか、更新されていない NAIST-Jdic-for-ChaSenの辞書について\nバージョン：0.4.3（※NAISTとして公開されている最新はMeCab用の辞書0.6.3） 最終更新日：2008/07/07 登録単語数：約28万語 IPAdicの後継として整備。品詞の定義など大まかな仕様は共通。 IPAdicと異なり、アルファベットや数字が1文字ずつ単語として登録されている。 IPAdicとNAIST-Jdicで大きな違いはアルファベットと数字の扱いについてです。 次のような文章をそれぞれの辞書で解析した結果は次のようになります。(SolrのField Analysisの画面です。思いの外大きいのでサムネイルのみですが。) 「このComputerは、10回に1回の割合で起動中に青い画面が表示されます。」 ○IPAdicの場合 ○NAIST-Jdicの場合 「Computer」と「10」という単語の区切り方が異なることがわかります。 この違いは、辞書のエントリが異なるために発生します。 NAIST-Jdicでは、数字（例：「1」）やアルファベット（例：「a」）が個々のエントリで登録されているため、分割された単語として認識されます。\n※この問題への対応方法はまた後日。\nカスタム辞書について 実際のデータを形態素解析したい場合、辞書に存在しない単語を登録して、1単語として認識させたい場合があります。（固有名詞など） このような場合にカスタム辞書を利用することで、新しい単語を辞書に登録することが可能になります。 カスタム辞書を利用する手順としては次のようになります。\nカスタム辞書ファイルの作成 作成した辞書ファイルを利用したjarファイルの生成 まずは辞書ファイルの作成についてです。 以下では、naist-chasen(NAIST-Jdic)の辞書を例として説明します。（ディレクトリの違いだけで、IPAdicでも同じ方法でOKです。）\nlucene-gosenでは辞書のコンパイルに2つのフェーズが存在します。\ngosen用辞書を生成する前処理（中間csvファイルの生成） gosen用バイナリ辞書の生成 カスタム辞書は1の出力の形式(=中間csvファイル=dictionary.csv)にあわせたCSVファイルとして作成します。 CSVの各カラムは次のような意味を持っています。\n単語 単語の生起コスト 品詞 品詞細分類1 品詞細分類2 品詞細分類3 活用型 活用形 基本形 読み 発音 3カラム目以降は「素性（そせい？）」と呼ばれる項目です。ipadic、naist-jdicでは「品詞」「品詞細分類1」「品詞細分類2」「品詞細分類3」「活用型」「活用形」「基本形」「読み」「発音」となります。 ※「見出し語」「形態素生起コスト」「素性」と呼ばれる項目を表形式にする。 厳密な品詞の体系に関してはIPAdicやNAIST-Jdicのサイトをご覧ください（説明できるレベルにはまだまだなっていないので。。。） 今回は、固有名詞（人名、地名など）を追加するという例でカスタム辞書について説明します。 固有名詞として「達川」という人名を追加してみましょう。 まずは、次のようなエントリをもつ「custom-dic.csv」ファイルを作成します。ファイルはUTF-8で保存してください。 コストはすでにあるエントリで似たようなエントリのコストを真似します。（今回は固有名詞,人名で似ているものを採用）。ちなみに、コストは小さいほど単語として出てきやすくなります。 ※カスタム辞書にはSenで利用していたものが利用できます。 **\"達川\",2245,名詞,固有名詞,人名,名,*,*,\"達川\",\"タツカワ\",\"タツカワ\"** 上記ファイルを、先日紹介した$LUCENE-GOSEN/dictionary/ディレクトリにコピーします。 では、カスタム辞書を含んだlucene-gosenのjarを作成しましょう。 カスタム辞書のビルドは$LUCENE-GOSEN/dictionary/で行います。 また、カスタム辞書の指定はCSVファイル名をantの引数で指定します。次がコマンドの例になります。\n$ cd lucene-gosen-trunk $ cd dictionary $ ant -Ddictype=naist-chasen clean-sen $ ant -Ddictype=naist-chasen -Dcustom.dics=\u0026#34;../custom-dic.csv\u0026#34; compile $ cd .. $ ant -Ddictype=naist-chasen 上記コマンドの例で\u0026quot;clean-sen\u0026quot;というタスクを実行しています。これは、すでに出来上がっているgosen用のバイナリ辞書を削除するタスクになります。すでにgosen用の辞書が作成されている場合には辞書の再生成が行われないためです。 また、複数のファイルを利用したい場合は-Dcustom.dics=\u0026ldquo;custom-dic.csv custom-dic2.csv\u0026quot;という形でスペース区切りでファイル名を記述すればOKです。\nカスタム辞書を適用する前と適用後の違いは次のとおりです。 適用前 適用後 簡単ですが、以上がカスタマイズ辞書を利用する方法でした。 ちなみに、この記事を書く前にすでにカスタム辞書の件を書いているブログがありました。。。こちらも参考にしてください。 今回の例でいくつかSolrのanalysis画面を利用して説明してきました。Solrでのlucene-gosenの利用方法についてはまた後日記載したいと思います。 ※参考までに。Solrでの利用方法はこちらにも記載してあります。\nまた、IPAdicなどの辞書について記載のある書籍を見つけましたので、参考になれば。\nアプリケーションソフトの基礎 (講座ITと日本語研究) ","date":1307002560,"dir":"post/2011/","id":"b2621497b3313c97855ed951f0d9b291","lang":"ja","lastmod":1307002560,"permalink":"https://blog.johtani.info/blog/2011/06/02/%E8%BE%9E%E6%9B%B8%E3%81%A8%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E8%BE%9E%E6%9B%B8%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2011-06-02T17:16:00+09:00","summary":"辞書の特性について 現在lucene-gosenでは以下の2つの辞書が利用可能です。 簡単に違いについて説明します。 IPAdicの辞書について バ","tags":["lucene-gosen"],"title":"辞書とカスタム辞書について(Jugemより移植)"},{"contents":"今回はソースのダウンロードとビルドについてです。\n最新版のソースを利用したり、JavaDocを見たい場合はソースをダウンロードしてからビルドすることになります。 ソースのダウンロードからビルドまでの手順について説明します。\nまずはソースのダウンロードです。\n$ mkdir ~/work $ cd work $ svn co http://lucene-gosen.googlecode.com/svn/trunk/ lucene-gosen-trunk $ cd lucene-gosen-trunk ダウンロードしたソースは次のようなディレクトリ構成です。\n.classpathEclipse用ファイル .projectEclipse用ファイル .settingsEclipse用ファイル AUTHORS作者のリスト（Sen、GoSen） CHANGES.txtlucene-gosenにおける更新履歴 COPYING.LGPLライセンス README.txtReadme build.xmlAntのビルドファイル dictionary辞書コンパイル用ディレクトリ docsAPIドキュメント用ディレクトリ libライブラリ prettifyGoogle Code Prettify用ディレクトリ（APIドキュメントでの色づけ用） srcソースコード また、辞書やソースのコンパイルにはAntを利用します。 通常利用するAntのタスクには次のようなものがあります。\ncleanプロジェクトのクリーンアップ build-dic辞書のコンパイル（辞書のダウンロードも行う） jarjarファイル生成 dist配布パッケージの生成（2つのjarファイル生成） javadocJavaDocの生成 jarファイルの生成までの大まかな流れは「javaソースのコンパイル」～「辞書のダウンロード」～「辞書のプレコンパイル」～「辞書のコンパイル」～「jarファイルの生成」となります。 Antのタスク以外にjarファイルを生成する場合に利用するオプションは以下の通りです。\n-Dproxy.hostプロキシのホスト -Dproxy.portプロキシのポート -Ddictype辞書の指定（指定可能なものは次の通り。naist-chasen、ipadic） 以下はNaist-Jdicのjarファイルを生成するコマンドの実行例になります。プロキシサーバを利用する環境の場合は-Dproxy.hostと-Dproxy.portも指定してください。（※認証が必要なプロキシの場合はAntのビルドファイルを修正する必要が出てきます。）\n$ ant -Ddictype=naist-chasen jarファイルはdistディレクトリに生成されます。 これで、jarファイルが利用できるようになります。\n次回は、ipadicとNaist-chasenの辞書の違いとカスタム辞書を利用する方法について書こうと思います。\n","date":1306398840,"dir":"post/2011/","id":"ff1441a42144a7de9a3eaf9f5e7cfea9","lang":"ja","lastmod":1306398840,"permalink":"https://blog.johtani.info/blog/2011/05/26/%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%8B%E3%82%89%E3%81%AE%E3%83%93%E3%83%AB%E3%83%89%E3%81%A8%E6%A7%8B%E6%88%90/","publishdate":"2011-05-26T17:34:00+09:00","summary":"今回はソースのダウンロードとビルドについてです。 最新版のソースを利用したり、JavaDocを見たい場合はソースをダウンロードしてからビルドす","tags":["lucene-gosen"],"title":"ソースからのビルドと構成(Jugemより移植)"},{"contents":"概要： Lucene/SolrのコミッターであるRobert Muirさんが始めたプロジェクト 歴史： MeCabのJava移植版としてスタートしたSenがベースになります。 その後、辞書の構築部分をPerlからJavaに置き換えたGoSenが登場しました。 が、どちらもメンテナンスされなくなってきたので、Robertさんが引き継いでメンテナンスとLucene/Solr対応をはじめました。そして、現在にいたります。 ライセンス： LGPLライセンス（ベースになったMeCabのライセンスにならって） 特徴： 以下のような特徴があります。 ・Lucene/Solrですぐに利用可能（3.1、4.0に対応済み） ・jarファイル1つで利用可能（辞書をjarファイルに内包） ・LuceneのAttributeをベースにしたTokenの解析 ・その他（パフォーマンス改善、テスト改善など） プロジェクトのサイト： http://code.google.com/p/lucene-gosen/ ダウンロード： http://code.google.com/p/lucene-gosen/downloads/list 現時点では2つの辞書を内包したjarファイルが用意されています。 Naist-jdic 0.4.3（for ChaSen） 参考サイト：http://sourceforge.jp/projects/naist-jdic/ IpaDic 2.6.0　参考サイト：http://sourceforge.jp/projects/ipadic/ ","date":1306130400,"dir":"post/2011/","id":"5988b62a0c0785a303b77c74608e8b55","lang":"ja","lastmod":1306130400,"permalink":"https://blog.johtani.info/blog/2011/05/23/lucene-gosen%E3%81%A8%E3%81%AF/","publishdate":"2011-05-23T15:00:00+09:00","summary":"概要： Lucene/SolrのコミッターであるRobert Muirさんが始めたプロジェクト 歴史： MeCabのJava移植版としてスタートした","tags":["lucene-gosen"],"title":"lucene-gosenとは(Jugemより移植)"},{"contents":"今さらですが、ブログをはじめてみようかと。今さらですが…\nはじめてみようと思った一番の理由は、自分で調べたことをメモがわりに残すためです。 あとは、自分を追い込むためもありますが。(こっちが一番の理由かも)最近勉強してないなぁと感じているので。 ということで、まずは、lucene-gosenやsolrについて書いていく予定です。\n","date":1305859440,"dir":"post/2011/","id":"94b85ba716dbb7c20b230e69248b8208","lang":"ja","lastmod":1305859440,"permalink":"https://blog.johtani.info/blog/2011/05/20/%E3%83%96%E3%83%AD%E3%82%B0%E3%81%AF%E3%81%98%E3%82%81%E3%81%BE%E3%81%99/","publishdate":"2011-05-20T11:44:00+09:00","summary":"今さらですが、ブログをはじめてみようかと。今さらですが… はじめてみようと思った一番の理由は、自分で調べたことをメモがわりに残すためです。 あと","tags":["misc"],"title":"ブログはじめます(Jugemより移植)"}]
\ No newline at end of file
diff --git a/index.html b/index.html
index ddd704db8c..7e3335e949 100644
--- a/index.html
+++ b/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2024/01/25/kagome-bot-as-a-user-service/">
+        <h2 class="post-title">
+            kagome-botのユーザーサービス化
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            日常でよく、形態素解析したくなることがありますよね？ そして、Slackも日常的に立ち上がってますよね？ ということは、Slackのボットとして
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2024-01-25  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2023/12/31/review-2023/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2023/07/13/introduce-vs-code-and-dev-container/">
-        <h2 class="post-title">
-            VS CodeとDev Containerの導入（まだ途中）
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            前回の記事で、pre-commitとPyCharmとWindowsの組み合わせで困っていることを書きました。 これについて、知り合いとチャット
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2023-07-13  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -592,6 +592,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -983,7 +985,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/index.xml b/index.xml
index 1ca337447f..507d2caba1 100644
--- a/index.xml
+++ b/index.xml
@@ -7,7 +7,61 @@
     <description>Recent content on @johtaniの日記 3rd</description>
     <generator>Hugo -- gohugo.io</generator>
     <language>ja</language>
-    <lastBuildDate>Sun, 31 Dec 2023 07:49:21 +0000</lastBuildDate><atom:link href="https://blog.johtani.info/index.xml" rel="self" type="application/rss+xml" />
+    <lastBuildDate>Thu, 25 Jan 2024 09:30:53 +0000</lastBuildDate><atom:link href="https://blog.johtani.info/index.xml" rel="self" type="application/rss+xml" />
+    <item>
+      <title>kagome-botのユーザーサービス化</title>
+      <link>https://blog.johtani.info/blog/2024/01/25/kagome-bot-as-a-user-service/</link>
+      <pubDate>Thu, 25 Jan 2024 09:30:53 +0000</pubDate>
+      
+      <guid>https://blog.johtani.info/blog/2024/01/25/kagome-bot-as-a-user-service/</guid>
+      <description>日常でよく、形態素解析したくなることがありますよね？ そして、Slackも日常的に立ち上がってますよね？ ということは、Slackのボットとして</description>
+      <content:encoded>&lt;p&gt;日常でよく、形態素解析したくなることがありますよね？
+そして、Slackも日常的に立ち上がってますよね？
+ということは、Slackのボットとして常駐してもらえばできるのでは？&lt;/p&gt;
+&lt;h2 id=&#34;kagome-bot&#34;&gt;kagome-bot&lt;/h2&gt;
+&lt;p&gt;知り合いが&lt;a href=&#34;https://github.com/ikawaha/kagome&#34;&gt;kagome&lt;/a&gt;という形態素解析ライブラリを開発しています。
+その知り合いが、ボットにもしてくれています（複数辞書対応してみたかったので、PR作って取り込んでもらいました）。&lt;/p&gt;
+&lt;ul&gt;
+&lt;li&gt;&lt;a href=&#34;https://github.com/ikawaha/kagome-bot&#34;&gt;https://github.com/ikawaha/kagome-bot&lt;/a&gt;&lt;/li&gt;
+&lt;/ul&gt;
+&lt;p&gt;ただ、デプロイはしてなかったので、我が家にあるUbuntuのサーバーにデプロイして動かすことにしました。
+ボットについては、上記のリポジトリを見てもらえればいいかなと。&lt;/p&gt;
+&lt;p&gt;とりあえず動けばいいや、ということで、適当なshell scriptに&lt;code&gt;nohup&lt;/code&gt;で起動していたのですが、Ubuntuの更新後の再起動で毎回ログインしてスクリプトの実行はめんどくさいな？ということでググって調べてみました。&lt;/p&gt;
+&lt;h2 id=&#34;systemdでユーザーのサービスとして登録&#34;&gt;systemdでユーザーのサービスとして登録&lt;/h2&gt;
+&lt;p&gt;参考ブログにある手順ほぼそのままでした。知見ありがたいです。&lt;/p&gt;
+&lt;p&gt;サービスの登録自体は、指定のディレクトリにファイルを作るのではなく、systemdコマンドをしようしました。&lt;/p&gt;
+&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;$ systemctl --user --force --full edit kagome
+&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;これで、参考ブログにあるように&lt;code&gt;kagome.service&lt;/code&gt;というファイルが&lt;code&gt;~/.config/systemd/user/&lt;/code&gt;ディレクトリに作られます。
+ファイルの内容などはほぼ参考ブログにある通りです。こんなかんじ。&lt;/p&gt;
+&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;[Unit]
+Description=kagome bot
+
+[Service]
+ExecStart=/home/johtani/kagome-bot/start_kagomebot_service.sh
+ExecStop=/bin/kill ${MAINPID}
+Restart=always
+
+[Install]
+WantedBy=default.target
+&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;&lt;code&gt;start_kagomebot_service.sh&lt;/code&gt;の中で、kagome-botコマンドを実行しますが、こちらは絶対パスで記述しておきました。
+サービス起動時のパスは&lt;code&gt;~/&lt;/code&gt;のようなのですが、念のために。&lt;/p&gt;
+&lt;p&gt;あとは、次の手順でサービスを登録して開始します。&lt;/p&gt;
+&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;$ systemctl --user enable kagome
+$ systemctl --user start kagome
+&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;ログを見るのは&lt;code&gt;journalctl&lt;/code&gt;コマンドです。&lt;/p&gt;
+&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;$ journalctl --user -u kagome
+&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;あとは、以下のコマンドを実行しないと、マシン再起動後にログインするまでサービスが起動しないので忘れないようにしましょう。
+（忘れてログインしてみて起動してるじゃん？というコントみたいなことをしてしまいました）。&lt;/p&gt;
+&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;$ sudo loginctl enable-linger username
+&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;参考ブログ本当にありがたいですね。
+備忘録のついでにブログにしておきます。&lt;/p&gt;
+&lt;h2 id=&#34;参考ブログ&#34;&gt;参考ブログ&lt;/h2&gt;
+&lt;ul&gt;
+&lt;li&gt;&lt;a href=&#34;https://pyopyopyo.hatenablog.com/entry/2021/04/30/233755&#34;&gt;ユーザー権限で systemd のサービスを稼働させる方法 - pyopyopyo - Linuxとかプログラミングの覚え書き -&lt;/a&gt;&lt;/li&gt;
+&lt;/ul&gt;
+</content:encoded>
+    </item>
+    
     <item>
       <title>今年の振り返りと来年の抱負（2023）</title>
       <link>https://blog.johtani.info/blog/2023/12/31/review-2023/</link>
diff --git a/orama.json b/orama.json
index e78792d1a1..f8edd60b5e 100644
--- a/orama.json
+++ b/orama.json
@@ -1 +1 @@
-[{"contents":"今年も振り返りブログをリビングで書いています（ドミノ倒しすごいな）。 FMVのキーボードで書いているのでタイポがつらい。。。\n振り返り（2022年に書いた抱負から） まずは振り返りをと。\nフリーランス継続 今年も個人事業主として乗り越えられました。 ZOZOさんには今年も引き続きお世話になっている感じです。 そのほかにベクトル検索のお手伝いをしたり、OpenSearchを調べたりといった仕事を手伝っています。 今年も完全にリモートで作業していましたが、イベントに出かけたりできました。 来年はもう少し出かける感じになるかな？ 今年はすこしのんびり仕事をしていたので、来年はもう少し仕事探さないとかな（営業しないとなあ）\nプログラミング 今年はプログラムを書いたほうかなと。 Goで個人用ですが、Slackのボットを書いてみたり（GoでSlackのボットを作った話 | @johtaniの日記 3rd | @johtani\u0026rsquo;s blog 3rd edition）、公開されているAmazonのプロダクトデータを使って検索アプリを書いてみたり。 プロダクト用のアプリを書いているわけではないですが、ちょっとずつコードを読んだり書いたりしています。\nベクトル検索まわりをさわる がっつりとまではいかないですが、Elasticsearchのベクトル検索の調査をやったりしました。 Amazonのプロダクトデータを使ってもうちょっとやろうと思いつつ、そこまでは手が回せてない感じですが。 速度という面でどうやって折り合いをつけつつ導入するのか？ どういうシーンでつかうのがいいのか？ どのモデル選ぶのか？とか気になることだらけ。 なんか、みなさんがどうしてるのか気になってしょうがないので、話をしてもいいよという方は連絡をもらえるとうれしいかもなぁ。 ベクトル検索とかLLMの周りの動きがはやすぎてついていけてるのかどうか。。。\n本を読む 今年は比較的読んだかも？\n単体テストの考え方/使い方 ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティング ザ・ダークパターン ユーザーの心や行動をあざむくデザイン これまでの仕事 これからの仕事 機械学習による検索ランキング改善ガイド ソフトウェア設計のトレードオフと誤り 初めてのGo言語 買って読んでない本ももっとあるんですが。。。\n振り返り(今年あったできごと) ここからは今年の出来事を。 今年もずっと自宅でしごとしてました。 あとは少し仕事が少なめだったのでゲームが多くなってしまったかも？（本読めばいいのに。。。）\nゲーム（ONI、ゼルダ、FactorioのSpace Exploration） Dev container導入 検索技術勉強会の再開 ゼルダの新作面白かったですね。年初はOxigen Not Includedをやっていたのに、ゼルダが出てからはご無沙汰中です。ゼルダが終わった後は、ゼルダロスになってPythonを書いたりしていたのですが、うっかりFactorioのSpace Explorationを始めてしまい大変なことに。。。 全然終わる気配がないｗ\nローカルでの開発環境などをDev containerにちょっとずつしています。 Slackのボット、検索の遊び場、このブログ環境など。Dockerが必要にはなりますが、VSCodeとDev containerで環境を隔離できるし、VSCodeの拡張もコンテナごとに入れるのもできたりと便利です。\n最後は、検索技術勉強会を再開したことです。再始動という感じで4年ぶり？に再開しました（12月に開催した時のページ）。残念ながら私は裏方をしてただけで、当日は参加できてないのですが、次回（たぶん4月くらい）は参加するつもりです。再開の声を上げてくれた@takuya_aさんありがとう。絶賛スピーカーを募集中です。\n来年の抱負 さて、来年の抱負です。\nフリーランス継続 プログラミング継続 ベクトル検索の使い方をいろいろ試す 本を読んだブログを書く 今年もなんとかフリーランスを継続できましたが、そろそろ営業をしないといけないのかも？ ということで、外でしゃべったりもしていかないとなぁと。 あとは、検索ってどうやって導入すればいいのか？検索どうすれば改善できる？みたいなところのお手伝いをもっとしたいと思っています。 昨年出したこの本もあるので（『検索システム ― 実務者のための開発改善ガイドブック』 – 技術書出版と販売のラムダノート）、勉強会をやろうとしているところに顔を出したりしたいなあ。 外部の人を呼んで社内勉強会とかをできるというところがあれば参加したいので、声をかけてもらえればと。\nプログラミングはGo言語を触ったし、今年後半には検索の画面回りのプロダクトを触ってTypeScriptを勉強していこうかなという気になっています（なっているだけかもしれない？）。\nベクトル検索の使い方は、LLMだったりRAGだったりが世の中を席巻しているのもあり、いろんな記事が出てきて全然追いつけていません。だれか、少人数で勉強会とかやると興味ある人とかいるかなぁ？ こんなブログ見つけたよ、こんな論文があったよ、こんな使い方したらよかったよとかの共有をやるとみんな楽になったりしないかなぁ？\n今年は時々出かけて移動するタイミングで書籍を読んでいました。 読んだだけになってるのもあるので、少しでもいいからブログか何かに残しとかないとな。\nさて、今年は少しゆっくりできたので、来年はもうちょっといろんなところに顔を出しつつ、新しい仕事もできるといいなぁ。 勉強会もスピーカー集めをがんばるぞと。\nということで、今年もあと少しというところで無事書き終わりました。 来年もよろしくお願いいたします。よいお年をー\n","date":1704008961,"dir":"post/2023/","id":"d869fb48cb9acba03dc639481524ee80","lang":"ja","lastmod":1704008961,"permalink":"https://blog.johtani.info/blog/2023/12/31/review-2023/","publishdate":"2023-12-31T07:49:21Z","summary":"今年も振り返りブログをリビングで書いています（ドミノ倒しすごいな）。 FMVのキーボードで書いているのでタイポがつらい。。。 振り返り（2022","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2023）"},{"contents":"この記事は、情報検索・検索技術 Advent Calendar 2023の15日目の記事です。\n昨年に続き2回目の情報検索のAdvent Calendar参戦です。\n今年は、夏にオンライン参加したBerlin Buzzwordsの「The Debate Returns (with more vectors) Which Search Engine?」というセッションでPhilippさんが話題に出したOrama searchという検索エンジンを紹介してみようと思います（Oramaが正式名称なのかな？）。\nOramaという検索エンジン 公式サイトのトップにも記載がありますが、エッジで動作する全文検索＆ベクトル検索エンジンというもののようです。 なにそれ？という感じがしますが、オープンソース版のドキュメントを見るともう少しわかりやすい説明になっています。\nOrama is a fast, batteries-included, full-text and vector search engine entirely written in TypeScript, with zero dependencies.\nOramaはTypeScriptで書かれた、依存なしで利用できる検索エンジンということです（batteries-includedって初めて見たかも。「必要なものがそろってる」とかいう意味みたい（参考：英語のWikipedia））。\n以下は公式サイトにあるサンプルです。\ncreateでスキーマの定義をした検索エンジンのインスタンスを生成します。 insertで先ほど生成した検索エンジンにデータをインデックスします（後で紹介しますが、一括でインデックスするメソッドも用意されています）。 searchで検索し、検索した結果が返ってきます。 以上です。あとは、必要に応じてGUIを用意するだけです。\nimport { create, insert, search } from \u0026#39;@orama/orama\u0026#39; const db = await create({ schema: { title: \u0026#39;string\u0026#39;, director: \u0026#39;string\u0026#39;, isFavorite: \u0026#39;boolean\u0026#39;, year: \u0026#39;number\u0026#39; } }) await insert(db, { title: \u0026#39;The Prestige\u0026#39;, director: \u0026#39;Christopher Nolan\u0026#39;, isFavorite: true, year: 2006 }) const searchResults = await search(db, { term: \u0026#39;prestige\u0026#39;, where: { isFavorite: true, year: { between: [2000, 2008] } } }) サクッと動きそうですよね？依存関係がなくTypeScriptで書かれているということは静的なサイトなどでコンテンツを検索するのに使えるのでは？\nということで、自分のブログに組み込んでみました。 今回は組み込んだ時の流れと気になった点などを紹介します。 Hugoに組み込む際になるべく簡単にしたかったので、unpkg.comで公開されているJavaScriptだけを利用する形で検索ページを作ってみました。 JavaScriptやTypeScriptは不慣れなので効率がよくなかったり、間違っている点があればコメントなどをいただけると嬉しいです。\n構成 私のブログサイトはHugoで生成（参考：Hugo導入時の記事）して、GitHub Pagesとして公開しています。 現在のブログ検索にはAlgoliaを利用しているのですが、テスト目的としてOramaも使えるようにしてみました（右上のメニューでOramaをクリックすると以下で説明するOramaによる検索を試すことができます。\n今回実装してみたのは次のような流れです（日本語検索対応については後で説明します）。\nHugoでJSONのリストを生成（これまでと一緒） 1.で生成したリストをもとにNodeのスクリプトでOramaのインデックスファイルを作成 2.で作成したファイルを公開 画面で3.のファイルをダウンロードして検索 1. HugoでJSONのリストを生成（これまでと一緒） HugoでJSONのリストを生成します。Algoliaに記事を登録するのにも利用している仕組みです。 検索に利用する記事の情報を1記事を1つのオブジェクトとして出力します。1つの配列に記事ごとのオブジェクトが入っているJSONファイルになります。\n少しだけ特殊なことをしています。 ブログ記事にTagsというフィールドのありなしで処理を分岐しています。 Oramaが配列にNullを受け取った場合にうまく動かなかったので出力するJSON側で調整しています（あとで再確認してIssueあげておかないと）\n2. 1.で生成したリストをもとにNodeのスクリプトでOramaのインデックスファイルを作成 最初に紹介した公式のサンプルの場合、毎回Oramaのインスタンスを生成した後にインデックス登録の処理を行わなければいけません。 ただ、Hugoで生成したコンテンツは特に動的に更新があるわけでもないので、検索画面を表示するたびにインデックス登録するのも無駄が多い気がします。 Orama単体で最初に実装した時には、1.で作成した記事一覧のJSONをOramaで実装した検索ページのスクリプトが呼ばれたタイミングでフェッチし、insertMultiple（複数登録用のメソッド）を呼び出す実装にしていました。\nOramaでは、あらかじめ作成したOramaのデータベースを永続化・リストアするためのData Persistenceプラグインが提供されています。 インデックスに登録する処理コストはHugoでコンテンツを生成した直後に行い、検索画面では作成済みのインデックスファイルをフェッチしてリストアする形にすることにしました。インデックスと記事のJSONデータを含んだファイルになるので、元の記事一覧のJSONよりはファイルサイズが大きくなってしまいますが、処理時間も含めて考えると許容できるサイズではないかなと。\n次のスクリプトは1.で生成したJSONファイルを読み込んで、Oramaでインデックスした後にdpackというバイナリ形式でファイルに保存しています。 こののプラグインで選択できる形式は現時点ではjson、binary（デフォルト＝msgpack）、dpackの3種類になります。 残念ながら今回試したところ、binaryではエラーが発生したので、dpackを使用しました。\n3. 2.で作成したファイルを公開 単にGitHub Pagesに公開しているだけです。 ブラウザが2.で作成したインデックスファイルをフェッチしてから利用するためです。\n4. 画面で3.のファイルをダウンロードして検索 あとは検索画面です（長すぎるので、styleの部分は省略しています）。\nまず、必要なライブラリなどを読み込みます（下のソースコードの1行目から14行目）。\nOramaだけであれば問題ないのですが、OramaのプラグインがOramaをモジュールとして参照しているため、importmapとして定義しています。 Oramaのプラグインがいくつか利用しているものがあったので、まとめてimportmapに定義してあります。\n次に、検索窓（search-searchbar）や検索結果（search-hits）などのHTMLタグを用意します。 ヒット件数と検索にかかった時間も取れるので、表示する場所としてstatsも用意してあります。\n22行目からが実際の処理になります。\n28行目で、手順2.で作成したインデックスのファイルをフェッチします。 32行目でフェッチしたファイルから取り出した文字列をリストアして、Oramaのインスタンスを生成します。 34行目のtokenizerに関しては日本語対応で説明します。\n48行目のquery関数がクエリの組み立て＋検索の処理です。search-inputで入力されたテキストをtermとして渡して検索をしています（56行目）。 検索した結果のリストをもとに検索結果のHTMLタグを組み上げていきます。 検索結果には後述する@orama/highlightのモジュールを利用してスニペットを追加しています。\n日本語対応 残念ながらOramaは公式には日本語をサポートしていません（サポートしているスキーマに設定できるlanguageの一覧（＝STEMMERSにあるものだけ指定可能）。一覧と実装分けたほうがいい気がするけど？）。 ただ、tokenize関数を変更できるようにしてくれています。これを利用して、少しトリッキーな形で日本語対応しました。\n先ほどの手順2.でOramaのcreate関数として、componentsに次のtokenizerを渡します。\nlanguageはenglishですが、日本語をtokenizeする処理に次のように書き換えました。 stemmingは今回は行わない（＝用意されているstemmerを使えない）のでfalse、normalizationCacheは空のMapを用意しておかないとエラーが出るので、new Map()しています。 この設定を使ってcreateすることで、\ncomponents: { tokenizer: { language: \u0026#34;english\u0026#34;, stemming: false, normalizationCache: new Map(), tokenize: (raw) =\u0026gt; { return tokenize(raw) }, }, }, 少しわかりにくいですが、tokenizerのtokenize関数の中で呼び出しているreturn tokenize(raw)の部分はwakachigakiというライブラリのtokenize関数となっています。\nwakachigakiというライブラリ Elasticsearchなどのサーバー上で動作させる検索エンジンではkuromojiなどの辞書を内包した形態素解析器を利用するのが通常です。 ただ、今回はブラウザだけで完結した簡単な検索を行う仕組みをOramaを使って提供しようと考えました（kuromoji.jsというのもありますが、辞書のサイズがそこそこのサイズです）。 ですので、辞書ファイルのない軽量の形態素解析ライブラリとして、wakachigakiというライブラリ（＝6.2Kbの軽量日本語分かち書きライブラリ）を利用してみました。\n最初はTinySegmenterの利用をしていたのですが、wakachigakiのサイトにもあるように、TypeScriptやES Moduleでも利用できる形式となっていたのでこちらに切り替えました。\n辞書もっていないため、品詞でのフィルタリングや読みを利用した処理はできませんが、日本語の文章を分かち書きしてくれます。\ntokenize関数の設定 OramaのTokenizerインタフェースのtokenizeは入力の文字列をstring[]として返すことを期待しています。 wakachigakiのtokenizeも文字列を引数にとり、string[]を返すので、そのまま呼び出すだけにしてあります。\nただ、今回のブログ検索の実装では、検索窓に入力された文字列も特に何も処理せずにtokenizeに渡す形にしています。 クエリパーサーなどを考える場合は、検索窓に入力された文字列を前処理したりする必要がありますが今回はいったんこれで。。。\ndata-persistenceはcomponentsはpersistしない 手順2.で導入した、data-persistenceプラグインですが、現在の実装ではOramaが生成したデータベース（転置インデックス）だけを永続化しています。 独自に設定したtokenizerは残念ながら含まれていませんでした。 手順4.の検索画面のコードの34行目の部分（下記）で、フェッチしたインデックスデータからrestoreした後のOramaのインスタンスのtokenizerに手順2.と同じ設定のtokenizerを設定することで検索時にも同じトークナイズがされるようになります（今の仕組みだと修正した場合には、両方のソースコードを修正しないといけないのがちょっと面倒かも？）。\ndb.tokenizer = { language: \u0026#34;english\u0026#34;, stemming: false, normalizationCache: new Map(), tokenize: (raw) =\u0026gt; { return tokenize(raw) }, } tokenizerはOramaの検索エンジンのインスタンスに紐づく設定となっているので、フィールドごとに切り替えるといったことも現在では想定されていない気がします。\nハイライト ハイライトのために、インデックスデータに単語のポジションを保存するためのプラグインも提供されています。 このポジションは検索の単語がヒットしドキュメントのどの位置に出てくるのか？をあらかじめデータとして保存しておくことで、ハイライトのたびに単語の位置を毎回計算しなくてもよくするためのものと思われます。\nこれを利用してもよかったのですが、今回は@orama/highlightというモジュールを利用することにしました。 検索にヒットしたドキュメントの元の文章と検索のキーワードを入力すると検索キーワードの周りにハイライトのHTMLタグを埋め込んでくれるライブラリを利用しました。これは普通に他でも便利かも？\n余力があればプラグインを利用した時のインデックスのサイズの違いや検索時の速度の違いを調べてみるのもいいかもしれないです。\nそのほかの機能 今回は利用していませんが、Oramaにはそのほかの機能も用意されています（公式ドキュメントの検索の紹介のページ）。詳細は公式ドキュメントをご覧ください。\nTypo tolerance Facet/Filter Vector Search Geo Search Grouping Threshold Preflight Oramaで（まだ？）できないこと 今回触ってみて、現在のOramaの実装ではできなそうなことがいくつかあったので書き出しておきます。 あくまでも現時点のことです。今後実装される可能性もあります。\nデフォルトでは、searchのtermに渡した文字列をtokenizeし、出力されたトークン列（単語の配列）のそれぞれのトークン（単語）にヒットしたドキュメントが全て検索結果に含まれます。 検索結果のドキュメントはBM25でスコアリングされるので、多くのトークンが含まれるものが上位に来る可能性が高いです。\nただ、特定の単語を含まない検索、ANDやOR検索など凝ったクエリは現在は書けないようです（Issueがある）。\nfilterは別途用意されているので、例えばファセットで表示したカテゴリで絞り込んだ状態にするといったことはできそうです。\n残課題 とりあえず日本語をなんとなく検索できるようにすることはできました。 が、気になることもいっぱいありました。 時間を見つけてTypeScriptなどを勉強しながら探っていく感じでしょうか。\nインデックスを小さくする方法 今回はブログ記事のサマリー（Hugoで生成されるSummary）でインデックスを作ったので、インデックスのサイズはまだ小さくなっています（といっても1MB超えてるけど）。ブログ記事全体を検索できるようにする場合は、インデックスファイルが大きくなります。\nこれは、OramaがデフォルトではインデックスしたJSON自体もインデックス（ドキュメントストア）に保存しているためです。 ですので、Oramaに登録したJSONデータ＋検索用のインデックスがインデックスファイルとなります。 ただ、検索だけができればよい場合は、出来上がったインデックスがあればドキュメントのIDは取得できます。\n公式ドキュメントでもそのことに触れているページがあります（参考：Remote document storing）。\nまだちゃんと実装を見ていませんが、ブログ記事本体の文字列はドキュメントストアに保存しないようにすれば検索はできるが、容量が大きくならないといった工夫ができそうです。\nただ、検索結果にハイライトを含んだスニペットを表示したい場合は、コンテンツ文字列が必要になってくるので、代わりに何かしらの仕組みを考える必要が出てきます（例えばサマリー部分の文字列だけ保存しておいて、ハイライトはそこだけを対象とするなど）。\nそのほか そのほかに思いつくのはこの辺でしょうか？\nオートコンプリート：Oramaというよりも、JavaScriptやTypeScriptでうまく実装できるのか？という話のような気がしますが。。。 ファセット対応：機能としては存在していますが、今回は実装が間に合いませんでした。 Vector Search：検索キーワードのベクトルをどうやって作るのか？という問題が残りそう。コンテンツのベクトルだけで関連ページの表示みたいなことはできるかも？（動的にやる必要がないので、事前計算して各ページに埋め込むほうがよさそうだけど） Geo Search：緯度経度があるデータを探し出してこないと？ relevanceの処理の変更：BM25以外に切り替えることができるかどうか（Oramaのソースとにらめっこしないといけなそう） tokenizeの改良：辞書を利用する形態素解析ライブラリやAPIを利用してみたり、「てにをは」といった1文字のひらがなを削ることで、無駄な検索ヒットを減らしてみたり。大文字小文字の正規化も必要。 検索ログの解析：検索ログを保存する仕組みなどはないので、Google AnalyticsやほかのAPIなどを用意する？ まとめ ということで、Oramaという検索エンジン？ライブラリ？を利用して日本語のブログ検索を実装してみました。 まだ、機能が少ない部分もありますが、少数のデータをブラウザだけで簡単に検索できる仕組みをGitHub Pagesだけで提供することができそうです。 今回は静的なファイルだけで完結する形にしましたが、TypeScriptで利用できる簡単な検索エンジンライブラリとして使ってみるとまた別の面白さもあるかもしれないです。 まだ触っていない機能は思いついたこと（＝残課題に書いたこと）もあるので、ちょっと試行錯誤してみようかなぁ。\n","date":1702566000,"dir":"post/2023/","id":"476e17b6f854414033d5cec1470774ee","lang":"ja","lastmod":1702566000,"permalink":"https://blog.johtani.info/blog/2023/12/15/introduce-orama-to-blog/","publishdate":"2023-12-15T00:00:00+09:00","summary":"この記事は、情報検索・検索技術 Advent Calendar 2023の15日目の記事です。 昨年に続き2回目の情報検索のAdvent Calendar参戦です。 今年は、夏","tags":["orama","search"],"title":"Oramaという検索エンジンでブログ検索を作ってみた"},{"contents":"PySpaアドベントカレンダーの12/08のエントリーです。昨日は渋川さんのアンラーニングで失敗した話でした。\n私は、今年は昨年の続きっぽい話を。\n音楽の再生とか停止とか 今年もリモートで仕事を継続しています。 昨年、OwnToneという音楽サーバーを導入しましたが、ミーティング開始時や終了後に音楽の停止や再生をするのに、ブラウザで操作するのはちょっと面倒です。 加えて、ミーティングする際には実際には\n音楽を止める 電気をつける といったことをっやります。 音楽再生についても\n音楽を再生する アンプの音は音楽再生用の音量にする といった複数のことを行います。\n基本的にPCの前にいるし、Slackを常に開いているからSlackのBotを作ると便利になるのでは？ ということで、自分専用のSlack Botを作ってみました。\nGitHubリポジトリ 全く誰の役にも立たないけど、公開しています。\nhttps://github.com/johtani/smarthome Goで実装 知り合いに勧められたということもあり、Goをあまり触ったことがなかったので、Goでやってみました。時々新しい言語を触ってみたくなるので。。。\nコマンドパターンのような作りで、コマンド（操作）を増やしていく感じで実装してはみたのですが、この書き方がいいのかはまだよくわかっていないです。\nActionという単体の操作(例：OwnToneの一時停止)を、操作したい機器の操作ごとに作成しています。 インターフェースとしてはRunだけを定義しています。\ntype Action interface { Run() (string, error) } それらの操作（Action）をひとまとめにしたものをSubcommandという形で定義して、SlackのBotにはSubcommandの名前を送って処理を実行する形にしています。\ntype Subcommand struct { Definition actions []action.Action ignoreError bool } やりたいことを追加するタイミングで時々リファクタしたりもしていますが、基本はこんな感じです。 細かな実装はさておき、今回ボットを作るときの観点をいくつか。\n宅内ネットワーク 音楽サーバーのOwnToneもですが、YAMAHAのアンプのAPIも見つけたのでこれらの操作をボットから行っています。どちらも自宅のネットワークにあるので、今回作成したボットも同じネットワークで動作します。\n外部に公開されたHTTPのエンドポイントがあればよいのですが、今回は用意していません。 SlackのAPIではこれに対応したアプリを作るときのためにSocket Modeを用意してくれています。\nドキュメントがしっかりしているのもあり、チュートリアルなどを見つつ特に迷うことなく構築できました。\n基本的には「特定のチャンネルでボットがメンションされたら動作する」という挙動だけしか実装していないので、特に今回はこれで困ることもありませんでした（世の中の人たちはもっとすごいSlackの使い方をしていそうだけど。。。）。\n対象となるものたち ボットから操作しているのは今のところ3種類です。\nSwitchBot OwnTone YAMAHAのアンプ SwitchBot SwitchBotについては、go-siwtchbotを利用しています。 電気、エアコン、空気清浄機、サーキュレーターのオンオフをSwitchBot経由でやっています。\n室内灯の明るさのために、SwitchBot側でシーンを設定している（一番暗い明るさで電気をつける）ので、そこが少しと特殊でしょうか？\nあとは、SwitchBotの温湿度計を3つ（室内2つ、室外1つ）おいてあるので、これらの温度を表示するコマンドも用意しました。\nそれぞれの機器の電池残量（電池の絵文字の右側）を表示してます（書斎が2つあるように見えますが、温湿度計の名前なので、同じ部屋においてあります。。。温度が高いほうがデスクトップPCの近くにある）。 防水の温湿度計があるので、外の気温もわかるのは便利です。\nOwnTone JSONのAPIが用意されていますが、特にクライアントライブラリなどは用意されていません。 今回は、用意されているAPIのごく一部だけを利用するので、net/httpのClientでJSONを投げています。 必要になったらowntone/clientにメソッドを追加していく感じです。\nhttps://github.com/johtani/smarthome/blob/master/subcommand/action/owntone/client.go#L45 再生、一時停止、プレイリストの取得、音量指定あたりを実装しています。 音の出力先はAirPlay（次に出てくるYamahaのアンプ）になっています。\nあと、JSON APIのサンプルをChatGPTに渡して、「このJSONをレスポンスに受け取る処理をGoで書いてください」と聞いて処理を書いたりしました（細かいのはどう聞いたか覚えてないけど）。\nYAMAHAのアンプ ググって探してきましたが、利用しているYAMAHAのアンプにYXC（Yamaha Extented Control）と呼ばれるAPIが用意されていました。 PDFでAPIの仕様が公開されていたので、この資料とにらめっこしながら、必要そうなAPIを実行するクライアントを実装しました。 こちらは、OwnToneのAPIの処理をすでに書いた後だったので、それをもとに必要な実装を追加しただけです。\nちなみに、アンプの電源をONにするAPIは実装していません。\nOwnToneで音楽を再生する(AirPlayで信号が送られるみたい) シーン選択（Nintendo SwitchやPS5のシーンを用意している）のAPIを呼び出す という処理をすると自動で電源がONになりました。スタンバイしている状態でもAPIはリクエストを受け付ける状態になっているようです。 また、PS5のシーンを呼び出したら、PS5自体も起動するのが便利だったりします。HDMI経由で信号が飛んでるのかな？ 「ミーティング開始」や「音楽停止」コマンドではアンプの電源をオフするAPIを呼び出すようにしています。\nタイポ対応 「入力間違いしちゃうんです、人間だもの。。。」\nということで、10月にタイポ対応の処理を入れてみました。 タイポ対応前の実装では、入力された文字列がコマンドの文字列と完全一致した場合にだけ、コマンドが実行される形になっていました。 結構タイポしちゃうので、完全一致で見つからない場合の処理として、入力された文字列とコマンド名のレーベンシュタイン距離が2以下のものを探し、その中で距離が一番小さな値のコマンドを実行する形にしてみました。 コマンド数はたかが知れているのでコマンドのリストを全部チェックする形にしています。 タイポするとこんな感じ。\nレーベンシュタイン距離の計算にはGo-edlibを利用しています。OSS便利ですね。\nやってよかったこと ミーティング開始時などのいくつかの手順が簡素化できたので満足しています。 SwitchBotの操作もスマホをわざわざ操作しなくてもいいですし（仕事してるとキーボードとSlackは常に使ってるし）。 また、副次的な効果として、部屋の外から電源を切り忘れていたり、エアコンの切り忘れなどの場合に、スマホから遠隔でまとめた処理ができるのが便利です。\n今後やってみたいこと こういうのがあるともうちょっと便利かもなぁ？というのもあるので今後も気が向いたらコマンドなどを追加していく予定です。 今のところこんなことやりたいなというのがいくつかあります。\nキーワードに関連する曲の再生 OwnTone自体に検索の仕組みがついているので、キーワードを受け付けてそれに関する曲を流す Flexispotの操作 ミーティングの時は立ち上がっているので、机をスタンディングの状態にしたい 電子工作しないとだめかも？ Webカメラ用ライトの点灯 ミーティング時に明かりが必要なのですが、物理スイッチのOn/Off これも電子工作かな？ 定期的に温度をBotに表示させるとと面白いかも？ まとめ ということで、新しいプログラミング言語にも触れたし、作業環境も便利になって一石二鳥でした。 新しいプログラミング言語触るのはやっぱたのしいですね。\n","date":1701961200,"dir":"post/2023/","id":"516a7aa07f8faa6b7aa38beb5010cf8c","lang":"ja","lastmod":1701961200,"permalink":"https://blog.johtani.info/blog/2023/12/08/smarthome-bot/","publishdate":"2023-12-08T00:00:00+09:00","summary":"PySpaアドベントカレンダーの12/08のエントリーです。昨日は渋川さんのアンラーニングで失敗した話でした。 私は、今年は昨年の続きっぽい話","tags":["misc","music","bot"],"title":"GoでSlackのボットを作った話"},{"contents":"「機械学習による検索ランキング改善ガイド」を読みました。\n著者の鈴木さんより献本いただいたのを読み終わったのでレビューと、あとおまけです。\n紹介とレビュー どんな本なのか？は打田さんが書かれたブログ、「ブックレビュー：『機械学習による検索ランキング改善ガイド』 - Tomoko Uchida - Medium」に詳しく書かれているので、そちらも参考にしてもらうほうがわかりやすいと思います（丸投げ）。\n読みながらいくつかツイートしていたので、そちらも参考のために貼っておきいます。\nオライリーの検索ランキング本、負荷テストのことも書いてある、すごいhttps://t.co/YPnB6kxFY2\n\u0026mdash; Jun Ohtani (@johtani) August 28, 2023 私のレビュー わかりやすく検索の基本を紹介しつつ、本書のメインであるランキング改善について全体の流れが書かれています。 ランキング改善のやり方といっても、手法の話だけではなく、プロジェクトとしてどの様に進めていくべきなのか？また、関係するものはどんなものがあり（システムだけではなくチームについても書かれていたり）、どういう判断をもちながら運用していくのか？、負荷テストにまで言及されています。\n読んでいて特に私が気に入ったのは以下のような話でした\nランキング改善を進める前にきちんと解ける問題なのか？それ以前にやることはないのかを考えましょう マッチング改善についても少しだけ触れられているが、メインはランキングについてだと明記されている 実際に体験されたのであろう落とし穴の話 負荷テストについて1章設けてある！ ハンズオンのパートでもレイテンシの話がされている 付録としてベクトル検索についても触れてある 日本語でまとまって読める本があるのは本当に幸せですよね。\nおまけ 書籍ではハンズオンで、Elasticsearchとランキング学習のプラグインであるelasticsearch-learning-to-rankを利用しています（GitHubにサンプルが公開されています）。 書籍ではElasticsearchが7.13.4、プラグインが1.5.7-es7.13.4というバージョンになっていました。\nブログを書いている時点でのElasticsearchは8.x系になっています。せっかくなので、書籍を読みながら現時点で最新のものに置き換えてみるというのをやってみました。\nElasticsearchは8.10.2が最新なのですが、ランキング学習のプラグインはサードパティ製で、1.5.8-es8.8.2が最新版となっています。 ハンズオンのサンプルコードをフォークして、以下の構成にして動くようにしてみました。\nElasticsearch : 8.8.2 learning-to-rankプラグイン : 1.5.8-es8.8.2 Kibana : 8.8.2 Python : 3.10 Elasticsearch、プラグイン、Kibanaのアップグレード Elastic社が提供しているDockerイメージが利用されているので、バージョン番号を書き換えました。 あとは、learning-to-rankプラグインのバージョンを書き換えるついでに、elasticsearch-pluginコマンドで直接ダウンロードさせる形に書き換えました。\nhttps://github.com/johtani/building-search-app-w-ml/blob/es8/part2/app/search-engine/Dockerfile\nPython3.10にアップグレード 本当は必要なかったのですが、Pythonのイメージもついでに3.10にしました。 ただ、このおかげでインストールされるXGBoostのバージョンも1系から2系に上がってしまい、XGBoostを利用してモデル生成をする処理でエラーが出るようになってしまいました。。。\n2系へのアップグレードは手間がかかりそうだということで、pipコマンドでのインストールでのバージョンを\u0026lt;2として、1系をインストールすることで回避しました。\nhttps://github.com/johtani/building-search-app-w-ml/blob/es8/part2/app/workspace/Dockerfile\nelasticsearch-pyのアップグレード Elasticsearchを8系にしたので、クライアントライブラリ側も8系に書き換えました（元は7.17以下に固定されていた）。 pipで7系に固定されていたものを外して最新のもの（8系）をインストールするようにしました。 これだけでも特に問題なく動いたのですが、「DeprecationWarning」が出ている部分が1か所だけあります（サンプルではDeprecationWarningが出力されない形になっていましたが、出力するように変更しました）。\nElastic公式のドキュメントにMigrate to 8.0というページが公開されています。Pythonクライアントのアップグレードを行う際はこちらを参考にすると指針が記載されています。\n今回のサンプルコードではsearchの時の引数としてbodyを渡していたのですが、8系のクライアントライブラリからこちらが廃止になり、queryやrescoreなど個別の引数を渡す形に変更されています（search APIのリファレンス）。 ですので、bodyを**bodyでアンパックして渡すようにしただけです。サンプルコードがわかりやすく書かれているので変更も少しで済みました。\nhttps://github.com/johtani/building-search-app-w-ml/blob/es8/part2/app/workspace/collect_responses.py#L59\n一応、これでエラーが出ないで動きました。 すべて適用した、フォークして修正したブランチはhttps://github.com/johtani/building-search-app-w-ml/tree/es8で公開しています。\nまとめ すごくわかりやすいうえに、手を動かしながらどんなデータを使ってどんなことをやるのかが体験できる良い本でした。 理論的な話だけでなく、システムとしてどういうものが必要で、どういうことをやらないといけないのか？というのがわかるのがイメージできるのは重要だと思います。\n最後は広告ですが、ランキング改善以外の検索システムについて学べる本を検索システム ― 実務者のための開発改善ガイドブック – 技術書出版と販売のラムダノート出していますので、こちらも参考書として読んでいただけるとうれしいです。\n","date":1695612744,"dir":"post/2023/","id":"7f78b02c531f09602ba4e140132d26a2","lang":"ja","lastmod":1695612744,"permalink":"https://blog.johtani.info/blog/2023/09/25/read-search-raking-guide/","publishdate":"2023-09-25T03:32:24Z","summary":"「機械学習による検索ランキング改善ガイド」を読みました。 著者の鈴木さんより献本いただいたのを読み終わったのでレビューと、あとおまけです。 紹介","tags":["読書","elasticsearch"],"title":"機械学習による検索ランキング改善ガイドを読みました"},{"contents":"趣味？（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書いています。 ベクトル検索などの確認なども含めて、Jupyter Notebookで簡単なAPIの呼び出しを書いていましたが、検索はやはり画面があるほうがにぎやかでいいですよね。 ということで、画面周りで調べものをしていた時のことを後日の自分のためのメモとして残しておきます。\nSearch UIとSearchkit ということで、それほど手がかからないで検索の画面をサクッと作る方法がないか？ということでちょっとだけ探してみました。 最初にElasticsearchを利用していることもあり、すぐに検索の画面を作れるライブラリ・フレームワーク・コンポーネントがないかな？ということで思いついたのが次の2つでした。\nElastic Search UI Searchkit どちらも直接Elasticsearchに接続して検索をすることができるコンポーネントです。 Elasticsearchだけで完結していればそれでおしまいだったのですが、今回はバックエンド経由でElasticsearchに検索を書ける必要があります（ベクトル検索の仕組みもデモをしたいため、クエリの文字列をLLMなどでベクトルにしてからknn検索をすることになります）。\nSearch UIの構成 もともとSearch UIはElasticのApp SearchのGUI構築向けのコンポーネントとして作られました。 最近になって、直接Elasticsearchに接続できるコネクターを提供しています（ベータだけど）。 このコネクターを利用した場合は、ざっくりですが、このような流れになります。\nまた、Search UIはCustom Connectorの仕組みも用意しており（ConnectorのAPIが宣言されているのでそのAPIで独自実装が可能）、これを利用することで、ブラウザではなくバックエンド（Node）でElasticsearch Connectorを利用するような構成も取れるようになっています。\n改めて要件をまとめると ということで、やりたいことは\n簡単にUIが作れる バックエンドはPythonを経由して検索したい となります。 Searchkitも調べようかと思いましたが、いったんはSearch UIのCustom ConnectorでPythonでFastAPIでバックエンドのAPIを実装して、Search UIの想定しているリクエスト・レスポンスに変換すればいいかな？ということにしました。\nとりあえずSearch UI＋Custom Connectorからのリクエスト・レスポンス（フロントからバックエンドへの出入りの部分）を記録し、 Search UI＋Elasticsearch Connectorのときのリクエスト・レスポンス（バックエンドからEsへのの出入りの部分）も記録して、 参考にしながらバックエンドを実装しようと試みました。 Search UIのCustom Connectorのサンプルとなっていた、Node上でElasticsearch Connectorを動かしている部分をPythonで簡単に再実装しようという試みです（まったく同じ実装にする必要はなく、必要最低限の機能（検索窓、ファセット、ページング）が動作するところを目指します）。\nElasticsearch API connectorの調査 方針が決まったので、Search UIがElasticsearch API Connectorに渡しているリクエストをブラウザのデバッグ機能を使って追いかけてみると。。。 内部でSearchkitを読んでいる？？ことがわかりました。\nElasticsearch API Connectorがリクエストを変換しているのかと思っていたのですが、実は内部にもう一段変換が行われていました。\n方針を決めたつもりが、Searchkitが出てきてしまったので、Searchkitも調べてみることに。。。 なお、Search UIにElasticsearch API Connectorを導入したのがどうやら、Searchkitの作者で、現在はElasticのエンジニアになられているようです。\nSearchkitとは？ Search UIが利用しているSearchkitは、3.0ですが、Searchkit本家のリポジトリを見ると4.x.0となっています。\nどうして新しいものをSearch UIで使っていないのかな？と思いつつ調べてみたところ、Searchkit V4のブログを発見しました。\nSearchkit V4 integrates with Algolia’s Instantsearch library, which is a Search UI library built by Algolia. Instantsearch is an amazing library, and it’s been used by many companies and supports many frameworks like React, Vue and Angular. ブログより引用\nどうやら、V4ではコンセプトをガラッと変更されたようで、Algoliaがオープンソースとして開発しているInstantSearchのコネクター（アダプター）としてSearchkit V4を開発しているようです。 これは最近出てきている検索エンジンのTypesenseやMeilisearchの戦略にもなっています。\nなお、SearchkitのGitHubリポジトリやSearch UIのリポジトリを見ていると、Search UIの開発（およびSearchkitの3系）は現在は活発に行われていないように見えました。 Searchkit V4はちょっとずつ開発が進んでいるようです。\nまとめ？ 一応Searchkit V4の現状やInstantSearchもすこしだけ見てみたのですが、今回の私のプロジェクトでは検索画面はまだそこまで重要度は高くないので、いったん調べていたSearch UI＋Pythonのバックエンドの構成で動作する最小限を実装したところで終わりにしました。 なので、Searchkit V4＋InstantSearchの構成はまた今度という感じです。\nなお、Search UIの方は5月からコミットがされていないようです。どうも開発しているチームが別件で忙しそうだなというのを感じました。\n","date":1692768764,"dir":"post/2023/","id":"8f58cbe5f2ce85c22569af765de3f8d3","lang":"ja","lastmod":1692768764,"permalink":"https://blog.johtani.info/blog/2023/08/23/search-ui-and-searchkit/","publishdate":"2023-08-23T05:32:44Z","summary":"趣味？（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書いています。 ベクトル検索などの確認なども含めて、Jupyter N","tags":["searchkit","search-ui","画面"],"title":"search-UIとSearchkitと検索画面"},{"contents":"いくつかある環境をDev Containerで動くように変えていますが、最初に導入した時に疑問点だった「コンテナ名」について解消したのでメモを残しておきます。\nコンテナ名の指定 最初のDev Container導入の記事で、起動したコンテナの名前が自動で付与されて、ランダムに変わるという疑問点を書いていました。\ndocker-compose.yml対応の記事ではdocker-compose.ymlを利用すると、コンテナ名はファイル内で定義されたサービス名で起動されて見やすくなると気づきました。\nやはり、Dev Containerでイメージを指定している場合もわかりやすいコンテナ名がいいなと思ったところで、「runArgs」を思い出しました。 Dev Containerからコンテナを起動するときに渡す引数が書けるじゃないですか。そういえば、むかしdockerコマンドを使う時に名前を指定した記憶があったなと。ということで、Google検索です。「docker command args container name」で検索しましたｗ\n--nameというオプションで起動時のコンテナの名前の指定ができます。ということで、このブログを生成するためのdevcontainer.jsonに\u0026quot;runArgs\u0026quot;でコンテナ名を指定してコンテナ起動ができるようになりました（「ブログ記述環境としてのDev Container」という記事のdevcontainer.jsonにrunArgsの行を追加しただけ）。\n{ \u0026#34;name\u0026#34;: \u0026#34;Hugo - blog generator\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;mcr.microsoft.com/devcontainers/javascript-node:16\u0026#34;, \u0026#34;runArgs\u0026#34;: [\u0026#34;--name\u0026#34;, \u0026#34;blog_generator\u0026#34;], \u0026#34;postCreateCommand\u0026#34;: \u0026#34;/bin/sh ./.devcontainer/postCreateCommand.sh\u0026#34;, ... ","date":1690420969,"dir":"post/2023/","id":"f9e847ee886bdb9ab5583eeb6eabbd51","lang":"ja","lastmod":1690420969,"permalink":"https://blog.johtani.info/blog/2023/07/27/container-name-in-devcontainer/","publishdate":"2023-07-27T01:22:49Z","summary":"いくつかある環境をDev Containerで動くように変えていますが、最初に導入した時に疑問点だった「コンテナ名」について解消したのでメモを","tags":["dev container"],"title":"VS CodeとDev Container(コンテナ名の指定)"},{"contents":"このブログの生成には、Hugoを利用しています。 ブログ移行日記（その1）に書いてありますが、当時はbrewでインストールしていました。 また、Windowsに移行したタイミングで、WSL2のUbuntuにaptでhugoをインストールして利用していました。 WSL2の環境が壊れなければこのままでもいいのですが、最近Dev Containerを触っていたので、このブログを書く環境（おもにHugo）もDev Containerにできるのでは？と気づきました。\nということで、Hugo＋αの環境をDev Container化したので、そのメモです。\n必要なもの ブログを書いて、記事を構築して、公開するところまでに利用するのは次のようなものです。\ngit Hugo node atomic-algolia GitHubのプライベートリポジトリでHugoのプロジェクトを管理しています。 また、GitHub Pagesで公開しており、生成したHTMLもgitコマンドを利用してGitHubにpushしています。 このため、gitコマンドが必要です。\nコンテンツの生成はHugoコマンドを利用します（テーマの適用とかいろいろ）。\nあと、Algoliaでブログを検索できるようにしており（ブログ移行日記（その4）参照）、Algoliaへドキュメントのデータをアップロードするために、atomic-algoliaを利用しています。こちらは、nodeのモジュールであるので、nodeの環境も必要です。\nベースにするイメージ Dev Container Templatesというリポジトリが公開されています。 こちらを探すと、元となるdevcontainer.jsonが見つかることがあります。 Hugoのものがあるか探してみましたが、残念ながら見つかったのはJekyllのテンプレートでした。 今回は、nodeの環境が必要なのでjavascript-nodeを元に編集していきます。\n手元のUbuntuのnodeのバージョンが16だったので、バージョン16のイメージを指定します(devcontainer.jsonは後述)。\nHugoの追加 Hugoのテンプレートはなかったのですが、Dev Container FeaturesにHugoのfeatureが用意されていました。 featuresに1行追加するだけでコンテナにHugoをインストールしてくれる便利ものです。\nMarkdownの環境 Dev Container Templatesを探索していて見つけたMarkdownのテンプレートも参考にしてみました。 VS CodeのMarkdown向けの拡張機能がいくつかリストアップされていたので、ついでに追加です。 markdown-all-in-oneやmarkdownlintはこれまでも利用していたので、他のものも便利だろうということで。 他の物はどんなものかを後で調べてみる予定です。\n作った.devcontainerの設定はこちら ということで、出来上がった設定は以下の通りです。\ndevcontainer.json { \u0026#34;name\u0026#34;: \u0026#34;Hugo - blog generator\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;mcr.microsoft.com/devcontainers/javascript-node:16\u0026#34;, \u0026#34;postCreateCommand\u0026#34;: \u0026#34;/bin/sh ./.devcontainer/postCreateCommand.sh\u0026#34;, \u0026#34;features\u0026#34;: { \u0026#34;ghcr.io/devcontainers/features/hugo:1\u0026#34;: {} }, \u0026#34;customizations\u0026#34;: { \u0026#34;vscode\u0026#34;: { \u0026#34;extensions\u0026#34;: [ \u0026#34;yzhang.markdown-all-in-one\u0026#34;, \u0026#34;streetsidesoftware.code-spell-checker\u0026#34;, \u0026#34;DavidAnson.vscode-markdownlint\u0026#34;, \u0026#34;shd101wyy.markdown-preview-enhanced\u0026#34;, \u0026#34;bierner.github-markdown-preview\u0026#34; ] } } } postCreateCommand.shでは、npm installで、必要なモジュールのインストールをコンテナビルド後に実行できるようにしました。 （apt updateはなくてもいいな）\npostCreateCommand.sh #!/bin/sh # postCreateCommand.sh echo \u0026#34;START Install\u0026#34; sudo apt update sudo chown -R vscode:vscode . npm install echo \u0026#34;FINISH Install\u0026#34; まとめ ということで、ここ最近Dev Containerについて色々調べていたのでサクッとDev Container化ができました。 まぁ、HugoのFeatureが用意されていて、他に大したことをやっていないというのが大きいのですが。 このブログは今回構築したDev Containerで生成して公開した記事になります。\n","date":1690189832,"dir":"post/2023/","id":"7884b62c561b999b9358d52779a18218","lang":"ja","lastmod":1690189832,"permalink":"https://blog.johtani.info/blog/2023/07/24/introduce-dev-container-to-hugo-env/","publishdate":"2023-07-24T09:10:32Z","summary":"このブログの生成には、Hugoを利用しています。 ブログ移行日記（その1）に書いてありますが、当時はbrewでインストールしていました。 また、","tags":["hugo","dev container"],"title":"ブログ記述環境としてのDev Container"},{"contents":"WSL2にUbuntuを入れて、開発とかはこちらを利用しています。 また、Docker DesktopもWSL2のバックエンドエンジンを利用しています。\n知り合いとの話で、Ubuntuの外付けのSSDをマウントしたという話が出てきて、それだと遅くない？Ubuntu自体を移動できるんじゃないかな？という 流れになりました。 知り合いは、特に移動とかは考えてなかったのですが、自分のディスクの容量が今どのくらい使われているのかが気になり、調べてみると、 Cドライブの使用率が90%を超えてるじゃないですか。\nWizTreeというソフトを前回入れていたのを思い出して、再度調べてみたところUbuntuらしきvhdxファイルのサイズが171GB、Docker Desktopのデータ領域のvhdxファイルのサイズが81GBと、結構な割合です。\n前回は、Hyper-V管理ツールで仮想ディスクの圧縮処理を行ったのですが、Dドライブに移行したほうが安心できそうな気がしたので、移動の方法を調べました。\nWSLコマンドのドキュメントが公式で公開されています。こちらのコマンドを元に作業をしました。 また、ググって出てきた記事も参考にさせていただきました。ありがとうございます。\nwsl をDドライブに入れ直してディスク拡張する | blog.ojisan.io WSL2環境をコピー（複製）する方法 - Qiita まずは確認と停止 WSL2で使っているディストリビューションを確認します。コマンドは以下の通り。 実行した結果も含まれています。コマンドの実行にはコマンドプロンプトを使用しました。公式ドキュメントのドキュメントではスニペットはPower Shellと書かれてますが、コマンドプロンプトでも大丈夫そうでした。\nD:\\\u0026gt;wsl -l -v NAME STATE VERSION * Ubuntu Running 2 docker-desktop Running 2 docker-desktop-data Running 2 残念ながら、wslのコマンドでは実体がどこにあるのかを調べることができなかったですが、WizTreeでディレクトリ名などを見ていたのでなんとなう予測ができました。 （これ、他に知る方法あるのかなぁ？）\nディストリビューションの移動は次のような手順になります。\nwslのshutdown エクスポート（ディストリビューションのコピー） 今あるディストリビューションを削除 インポート（今ある名前で2.のファイルをインポート） まずは停止です。これをやらないとエクスポートができないので。\nD:\\\u0026gt;wsl --shutdown エクスポート 次にエクスポートです。 今回は以下の2種類の仮想環境をエクスポートします。\nUbuntu docker-desktop-data エクスポートでは、元のディストリビューションのファイル（Cドライブにあるファイル）が消えることはありません。 また、エクスポートの形式として、tarとvhdxの2種類が指定できます。 エクスポートのコマンドのデフォルトはtar形式ですが、エクスポート元のファイルがvhdxなので、vhdxでエクスポートしたほうがCPUにやさしかったです。 ちなみに、docker-desktop-dataはtar形式でエクスポートしてインポートしました。tar形式の場合は、ディスクのサイズが小さくなる可能性があるみたいです（不要なデータがvhdxの中に残っていたりする影響かと）。\nコマンドは以下の通りです（詳細は公式ドキュメントを参照してください）。出力ディレクトリはあらかじめ作っておきました（作ってない場合の挙動は未確認です。）\nD:\\\u0026gt;wsl --export Ubuntu .\\wsl\\Ubuntu\\ext4.vhdx --vhd docker-desktop-dataはtar形式です。\nD:\\\u0026gt;wsl --export docker-desktop-data .\\Docker\\ docker-desktop-data.tar ディストリビューションの削除（こわい？） 今ついているディストリビューション名を利用したいので、いったん、Cドライブ上にあるディストリビューションを削除する必要があります。 コマンドは公式ドキュメントにある--unregisterオプションを利用します。 以下のコマンドはUbuntuですが、docker-desktop-dataもやりました。\nD:\\\u0026gt;wsl --unregister Ubuntu ちなみに、このコマンドを実行すると、Cドライブの容量がいきなり空きました。 コマンドいっぱつでなくなりました。きちんとエクスポートしてから実行しましょう。 （なんなら、一度、別名でインポートして動作確認するのもいいかもしれないです。私はしましたｗ）\nインポート インポートするオプションも2種類あります。vhdxファイルの場合は、インプレースでのインポート（vhdxファイルをそのまま利用する形式）が可能です。 Ubuntuについてはこちらを利用しました。この場合、vhdxファイルがそのまま利用されるため、バックアップとしては利用できなくなります。今回は170GBもあるので、これでいいかと。\nD:\\\u0026gt;wsl --import-in-place Ubuntu .\\wsl\\Ubuntu\\ext4.vhdx tarファイル（docker-desktop-data）の場合は、通常のインポートを行いました。\nwsl --import docker-desktop-data D:\\Docker\\docker-desktop-data\\ D:\\Docker\\docker-desktop-data.tar この場合、tarファイルは残ったままで、新たにD:\\Docker\\docker-desktop-data\\ディレクトリにext4.vhdxファイルが作られました。 バックアップも取りつつ移行したい場合は--importがいいかもしれません。 また、WSLはバージョン1とバージョン2があり、インポートの際にこの部分も気にする必要があるようです。 今回はすべてバージョン2で、かつ、wslのデフォルトのバージョンを2にしてあったので特に意識していません。\nUbuntu起動ユーザーの指定と注意点 公式ドキュメントに、既存のユーザーを変更するコマンドの記載があります。 インポートしたディストリビューションは、デフォルトユーザーがrootになっていることがあるようなので、Ubuntuのユーザーを次のようなコマンドで変更しました。\nubuntu config --default-user johtani 公式ドキュメントの警告にもありますが、実行可能ランチャーがない場合があります。 今回のubuntuは、WSL2でUbuntuをインストールした時に作成されたコマンドで、unregisterした後にimportしてもきちんと動いたので問題にはなりませんでした。これは、インポートするときに、既存のディストリビューション名を利用したためと思われます。\nエクスポートやインポートの検証するために、NewUbuntuという名前で別途インポートした時には、NewUbuntuという実行可能ランチャーは作成されず、上記のデフォルトユーザーの設定は別の方法が必要になります（罠だ）\ndocker-desktop-dataのほうは、特に変更してないけど動いてそうだからいいのかな？ 前の設定の確認とかやっておくのがいいんだろうな、本当は。。。\nまとめ ということで、Cドライブに300GB近い空きができて、心の余裕もできました。 今回は、同じPC内で別のドライブへの移動でしたが、他のPCにもこれで移行ができそうですね。 たまにはバックアップをとっておくのもいいのかも？と思いました（やるかどうかはまた別の話）\n","date":1690180128,"dir":"post/2023/","id":"ed431877ce11fe403fee77f7d26ce637","lang":"ja","lastmod":1690180128,"permalink":"https://blog.johtani.info/blog/2023/07/24/move-distribution-to-another-disk/","publishdate":"2023-07-24T06:28:48Z","summary":"WSL2にUbuntuを入れて、開発とかはこちらを利用しています。 また、Docker DesktopもWSL2のバックエンドエンジンを利用して","tags":["wsl","windows"],"title":"WSL2のディストリビューションの環境移行"},{"contents":"前回の記事で、VS Code＋Dev Containerを導入しました。 残課題として「マルチコンテナ化」があるという話もしました。今回はDev Containerのdocker-compose.yml対応をした話をメモとして残しておきます。 実際、VS Code + Dev Containerに移行した後に、Esを起動してアプリからつなげるというのがうまくいかないというのがあったので対応がんばりました。。。\nDev Containerのdocker compose設定 この記事ではすでにdocker-compose.ymlが存在している状態の話をします。 変更する前は、devcontainer.jsonでベースのコンテナイメージの指定、マウントの設定などを行っていましたが、docker-compose.ymlにいくつかを移動しないといけません。 対応した時の作業の流れは以下のような感じです。\nワークスペース用のDockerfileの作成 docker-compose.ymlにワークスペース用のサービスを追加 devcontainer.jsonをdokcer-compose.ymlを利用する形に書き換え アプリでの接続文字列をlocalhostからdocker-compose.ymlのサービス名に変更 参考：対応した時のコミットです。差分などはこちらをごらんください。\ndevcontainerのリポジトリにPython+PostgreSQLのサンプルが公開されており、こちらを参考にしながら作業をしました。\n1. Dockerfileの作成 docker-compose.ymlだけでも完結するのかもしれないですが、いろいろやりたいことも出てくるかもしれないので別のファイルに切り出しました。 といっても、コンテナのイメージはdevcontainer.jsonに記述していたものを使っています。\nARG VARIANT=3.11-bookworm FROM mcr.microsoft.com/devcontainers/python:${VARIANT} ENV PYTHONUNBUFFERED 1 ENV TZ Asia/Tokyo TZはdevcontainer.jsonで指定していたものを、こちらに移行した形になります。 PYTHONUNBUFFEREDは参考にしたDockerfileの記載です。標準出力・エラーをバッファリングしない指定になっています。\n2. dokcer-compose.ymlにサービス追加 backendという名前のサービスをdevcontainer（VS Code）から接続するコンテナのサービス名にしています。\nservices: backend: build: context: . dockerfile: .devcontainer/Dockerfile init: true environment: - TZ=Asia/Tokyo command: sleep infinity volumes: - .:/workspace/search-research:cached - venv-search-research-backend:/workspace/search-research/.venv ... volumes: venv-search-research-backend: 1.で作成したDockerfileを利用します。docker-compose.ymlファイル自体は、プロジェクトのルートディレクトリに配置していますが、Dockerfileは.devcontainerディレクトリに入れたため、contextとdockerfileはこのような指定になっています。\ninitは、devcontainer.jsonで指定していた\u0026quot;runArgs\u0026quot;: [\u0026quot;--init\u0026quot;],の設定になります。\ncommandの部分は、コンテナが起動したままにしておくための設定です。\nvolumesでは2つのボリュームに関しての指定があります。 1つ目の/workspace...は、VS Codeがコンテナにプロジェクトをマウントする場所の指定です。 devcontainer.jsonだけを利用していた場合は意識していませんでしたが、/workspace/プロジェクト名というディレクトリにプロジェクトがマウントされていました。 docker-compose.ymlを利用する場合は、明示的に指定が必要です。 2つ目のvenv-...は.venvのディレクトリをコンテナの中だけのものにする設定を移植したものになります。 前回の記事ではコンテナIDをボリューム名に含めていましたが、こちらのほうがわかりやすいかと思い、プロジェクトの名前とサービス名をつけるようにしてみました。 Dev Containerで起動した場合はsearch-research_venv-search-research-backendという名前がついています（最初の部分はDev Containerがつけてるのかな？）\n3. dovcontainer.jsonの変更 devcountainer.jsonから呼び出すものの準備ができたので、devcontainer.jsonを書き換えます。 公式のドキュメントとしてDocker Compose向けのプロパティが紹介されています。 変更したものは次のような形です。\n{ \u0026#34;name\u0026#34;: \u0026#34;search-research\u0026#34;, \u0026#34;dockerComposeFile\u0026#34;: \u0026#34;../docker-compose.yml\u0026#34;, \u0026#34;service\u0026#34;: \u0026#34;backend\u0026#34;, \u0026#34;workspaceFolder\u0026#34;: \u0026#34;/workspace/search-research\u0026#34;, \u0026#34;postCreateCommand\u0026#34;: \u0026#34;/bin/sh ./.devcontainer/postCreateCommand.sh\u0026#34;, \u0026#34;customizations\u0026#34;: { ... dockerComposeFile : 利用するdocker-compose.ymlのファイルパス service：VS Codeが利用するワークスペース用のサービス名 workspaceFoldeer：VS Codeがコンテナに接続したときに開くフォルダのパス を指定します。これで、VS Codeでこのプロジェクトを開いた時に、Dev Containerがdocker-compose.ymlを使ってコンテナの起動（ビルドとか）を行ってくれます。\n4. アプリの接続文字列の書き換え こちらはおまけです。 PythonのアプリからElasticsearchに接続するときの文字列として、Dev Container化の前は、http://localhost:9200と指定をしていました。 Elasticsearch用のサービス（es）で、ポートフォワードをしていたためです。\nアプリ側もコンテナ化したので、Docker Composeが名前の解決をしてくれるので、http://es:9200という接続文字列で接続ができるようになりました。\nということで、ここまでで、VS Codeでプロジェクトを開くと、2つのコンテナ（backendとes）が起動してVS Code上でPythonアプリからEsへの接続ができるようになりました。\n追加の変更 参考のプルリクでは、上記まででしたがさらにいくつかの変更をそのあとやっています。\n起動するサービスの指定(開発だけするときはEsを起動したくない) devcontainer.jsonでrunServicesを使って指定できます（公式ドキュメント） GPUをコンテナから利用できるように devcontainer.jsonでfeaturesのnvidia-cudaを指定し、docker-compose.ymlでnvidiaのドライバーなどを設定することで対応しました。 nvidiaが公開しているcuda対応のコンテナイメージでもよかったのですが、こちらのほうが楽そうだったという理由です。featuresとコンテナのビルド、postCreateCommandの順序などはもうちょっと勉強しないといけない気がしています。 これらの対応はこちらのコミットで対応しています。\nGPUの対応は、私個人の環境はこれでいいのですが、複数の人がこのリポジトリを使う場合はどうやって切り替えたりするんだろう？という疑問が残っています。。。 今回はrinna/japanese-clipのモデルを使って、テキストからベクトルを生成する部分の処理のためにGPUを使いたいというモチベーションがあり、コンテナでもGPUを使えるようにしています（CPUだと時間がすごくかかる。。。）。\nサービス起動の新たな問題点 runServicesで起動するサービス名を指定したのはよかったのですが、Elasticsearchのサービスを起動して、データ登録や検索の確認を行おうと思った時に、EsのコンテナをVS Codeだけで起動する方法がまだわかっていません。。。 一度コンテナをビルドした後なら、「Remote Explorer」でOther Containerというくくりで表示され、右クリックで起動や停止ができそうなのだけど、新規サービスをdocker-compose.ymlに追加した場合は、自分でターミナルなどでコンテナのビルドをしないといけないかもしれないです。もうちょっと調べてみないとなぁ。\n副次的な効果 Docker Compose対応をしたことで、前回の記事での疑問点のうち、「コンテナ名」「VolumeのID」については懸念点がなくなりました。\n「コンテナ名」は、docker-compose.ymlのサービス名がコンテナ起動時に名前として利用されるため、Docker Desktopで見た時などの探しにくさはなくなりました。 ただ、「イメージ名」については、いまだに2つできています。「-uid」がつかないものの代わりに、search-research-backendというイメージが作られています。 ただし、実際に利用されるのは前回の記事に書いたようなvsc-search-research-bf04371c017c8d2f1dd5ad2529841b02e9ea1d1aaa4354c19edf53cef3f0c13b-uidという名前のイメージです。\n「VolumeのID」については、docker-compose.ymlのファイルで自分で名前をつけるようにしたので、コンテナのIDが利用されなくなったという次第です。 代わりに、プロジェクト名である「search-research」という名前を直接記述しているので、変数などで置き換えたほうがいいのかも？という気がしています。\nまとめ ということで、複数のコンテナを利用するプロジェクトでVS Code+Dev Container対応ができそうだということがわかりました。 ついでに、GPU対応もできたのでこれで、やっと他の検索エンジン対応などができる気がしています。 （その前にpre-commitを保存時にチェックする形に変更かなぁ） やりたいことからちょっとずつ外れている気もするけれど、新しいことを調べるのは楽しいですね。\n","date":1689902010,"dir":"post/2023/","id":"086b4fd5f77021a0a2aa6b0e90061486","lang":"ja","lastmod":1689902010,"permalink":"https://blog.johtani.info/blog/2023/07/21/multi-containers-with-dev-container/","publishdate":"2023-07-21T10:13:30+09:00","summary":"前回の記事で、VS Code＋Dev Containerを導入しました。 残課題として「マルチコンテナ化」があるという話もしました。今回はDev C","tags":["python","dev container"],"title":"VS CodeとDev Container（docker-compose.yml対応）"},{"contents":"前回の記事で、pre-commitとPyCharmとWindowsの組み合わせで困っていることを書きました。 これについて、知り合いとチャットで話をしていて、それほどPyCharmにこだわりもないよなぁということになり、 であれば、ISIDのブログ（Dev Containerを使ってステップバイステップで作るPythonアプリケーション開発環境 - ISID テックブログ）を試してみるとすっきりするかもしれないとなり、Dev Container対応をブログを参考に行ってみました。\n順を追ってブログで説明されているので、どういう仕組みなのか、どの設定が何を意味しているのか？がとてもよくわかりやすくすんなり対応することができました。\nブログの手順をなぞっているところでいくつか固有の手順や疑問点が出てきたのでブログに書き記しておきます。 結果は、コミットしてあるものを見てください。\nブログとは違う手順 まずはISIDのブログとは違う点をいくつか。\n.venvはいったん削除 ブログでは新規のプロジェクトを作成していく過程で、コンテナ化した環境を作った後に.venvをDockerコンテナのボリュームにして、最後に仮想環境のPythonを生成していました。 私の場合は、すでにホストOS（実際にはWSL2のUbuntuだけど）で.venvのディレクトリを作成してある状態だったので、いったん削除する必要がありました。 すでに存在する.venvがbindマウントされてしまっている状態になるため、Dockerのボリュームとの整合性が取れなくなるようです。\nこの作業を行う前か、途中でDev Containerを停止した状態で、.venvを削除することで問題なくDockerのボリュームに仮想環境のPythonが登録されるようになります。\npostCreateCommand.shの呼び出し方 ファイルに実行権限がないと、実行権限エラーが出ました。 実行権限を与えるか、次のような記述で動くようになりました。 今は、ファイルに実行権限をつけるのではなく、次のような記述にしていますが、何か問題あるかな？\n\u0026#34;postCreateCommand\u0026#34;: \u0026#34;/bin/sh ./.devcontainer/postCreateCommand.sh\u0026#34;, 実際に動作しているログを見ると\n/bin/sh -c /bin/sh ./.devcontainer/postCreateCommand.sh\nとなっているので、少し気持ち悪いのだけれども。。。\npostCreateCommand.shの追加処理 今回Dev Containerを適用したプロジェクトでは、sentencepieceを利用します。 この、sentencepieceをpoetryがインストールするタイミングで、cmakeを要求してきました。 今回利用しているDocker Imageにはcmakeは含まれていないため、以下の処理を追加しています。\nsudo apt update sudo apt-get install cmake -y また、rinna/japanese-clipも利用しているのですが、こちらは、poetryで追加してインストールでは依存するパッケージがインストールされないため、pipコマンドを利用するようにしています。\npip install git+https://github.com/rinnakk/japanese-clip.git コンテナイメージを作った後にやりたいことを、自由にスクリプトで書けるのは便利ですね。\npre-commitのスクリプトの再生成 こちらも、既存の環境が残っているとPythonへのパスの違いの問題が出たので、作り直しました。 .git/hooks/pre-commitのファイルを削除し、pre-commit installをやったものをリポジトリにコミットしてあります。\n疑問点 作業をしていて疑問点もいくつか出てきたのでメモを残しておきます。ちなみに、これらの疑問について実際に調べるまでには至っていません。 時間を見て解決できればなぁと（できるのか？）。\nImageが2つ Dev Containerの設定を書いた後に、コンテナをビルドすると、Docker DesktopのImagesにイメージが出来上がります。 この時、イメージが2つできあがっています（なぜ？）。\nREPOSITORY TAG IMAGE ID CREATED SIZE vsc-search-research-bf04371c017c8d2f1dd5ad2529841b02e9ea1d1aaa4354c19edf53cef3f0c13b-features-uid latest 25c7e23416ec 3 days ago 1.69GB vsc-search-research-bf04371c017c8d2f1dd5ad2529841b02e9ea1d1aaa4354c19edf53cef3f0c13b-features latest fcf9eaeb2187 3 days ago 1.69GB こんな感じで、最後に-uidがついているかいないかの違いです。 実際にコンテナ起動時に利用されるのは-uidがついているものになります。 なぜ2つになっているのか、1つにする設定などがあるのか？といったところが気になるところです。\nContainerの名前 devcontainer.jsonの設定を書き換えて、コンテナをリビルドすると起動したコンテナの名前が自動で割り振られているようです。 今は、fervent_hopperとなっています。ランダムにつけられているようなのですが、名前を付ける方法はないのかなぁ？と。\ndevcontainer.jsonにはnameというプロパティもあるのですが、この値がどこで使われているのかはよくわかっていません。 Remote Explorerでコンテナの一覧が見えますが、ここでは、リポジトリ名が利用されているようです。\nVolumeのIDはどこから？ devcontainer.jsonで次のような記述で、.venvのディレクトリようにDockerにボリュームを作っています。\n\u0026#34;mounts\u0026#34;: [ \u0026#34;source=venv-${devcontainerId},target=${containerWorkspaceFolder}/.venv,type=volume\u0026#34; ], 実際にコンテナでマウントされている情報を見ると\n/workspaces/search-research/.venv /var/lib/docker/volumes/venv-04emir9hi2caivtjunfe3l17452hkbb3hdut1qflbrn8n924ho5c/_data となっています。 04emir9hi2caivtjunfe3l17452hkbb3hdut1qflbrn8n924ho5cがdevcontainerIdに相当するのだとは思うのですが、誰がつけたものかなどがまだよくわかっていません。 もうちょっとわかりやすいものが使えるほうが嬉しいかも？と思っていたりします。 （複数Dev Containerを使い始めると、Docker Desktopで見ると、どのボリュームがどのDev Containerに紐づいているかがぱっと見ではわからない）\n.vscodeディレクトリどうしよう？ たぶん、VS Codeを触っている過程で、何かの設定をしてしまったのだとは思うのですが、 .vscode/settings.jsonというファイルができており、次のような内容になっています。\n{ \u0026#34;git.ignoreLimitWarning\u0026#34;: true } 何か意味があるかも？ということで、コミットしてリポジトリに入れたのですが、いらないのかもしれないなぁと。\n残作業 とりあえず、VS CodeでPython環境ができて、VS CodeのTerminalでPythonのプログラムが実行できるのはわかった段階です。 いくつか、今後調べながらやる必要があるものが残っているのでメモとして残しておきます。\nマルチコンテナ化 今回Dev Containerに対応したプロジェクトでは、検索エンジンもDockerのコンテナとして起動して、Pythonのプログラムから接続したいと思っています。 となると、docker composeでいろいろと起動するほうがネットワークなどの設定も楽になるのでは？と思っているところです。 Dev Containerのテンプレートがいくつか用意されており、その中に「Python 3 \u0026amp; PostgreSQL (postgres)」というのを見つけたので、このあたりが参考になるのでは？と考えているところです。\npre-commitではなく、保存時にフォーマット pre-commit＋localのコマンドも動くようにはなったのですが、保存時にフォーマットなどをかける設定もISIDのブログで記載がありました。 コミットしようとして、怒られるよりも、保存時に怒られたりするほうがいいかも？という気分になってきています。 どこまでが切り替え可能なのか？なども見ながら対応してみようかなと。\nもう少し開発してみて改善点を探っていく とりあえず動いたという段階です。 PyCharmとの違いがあるはずで（たとえば、git周りのGUIの違いとか）、そのあたりでどんな違いがあり、どんなものがあると嬉しいのか？といったものを調べる必要もあるかなと考えています。 TerminalでCtrl+rがうまく使えなかったり(Auto Hot Keyで検索のショートカットに割り当ててしまっているから。。。)などもあるので、この辺も調べていきたいなと。 Windows Terminalを使えたりするのかなぁ？\nまとめ さて、とりあえず、VS CodeでPythonのDev Container環境を作って動くところまでは来ました。 PyCharmを使いこなしていなかったのもあり、それほど違和感なく移行できるような気がしています。 調べることはまだまだあるし、プログラム書くつもりが、環境を整える方向に話がずれている気もしますが、まぁ面白いのでよしとするかなぁ。 いろいろまだまだ知らないことだらけです。。。\n","date":1689254123,"dir":"post/2023/","id":"a12474027c91fad5a861aa9919817d72","lang":"ja","lastmod":1689254123,"permalink":"https://blog.johtani.info/blog/2023/07/13/introduce-vs-code-and-dev-container/","publishdate":"2023-07-13T22:15:23+09:00","summary":"前回の記事で、pre-commitとPyCharmとWindowsの組み合わせで困っていることを書きました。 これについて、知り合いとチャット","tags":["python","dev container"],"title":"VS CodeとDev Containerの導入（まだ途中）"},{"contents":"最近、趣味（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書き始めました。\nきちんとPythonのプログラムをプロジェクトとして書いたことがないので、 Pythonのプロジェクトのディレクトリ構成などを手探りで進めているところです。 コードのフォーマットとかもやらないとなぁ？と知り合いのいるSlackでつぶやいたところ、gitのpre-commitフェーズでblackなどのフォーマットやスタイルを修正してくれるツールを実行する方法を教えてもらいました（PRまで送ってもらえたのでありがたい）。\nで、pre-commit周りの設定などを変えている段階で遭遇した問題点についてログを残しておこうと重いブログを書いています。 残念ながら現時点では解決してないんですけどね。。。\n手元の環境 簡単に環境を書いておくとこんな感じです。\nWindows上のPyCharmを開発で使用 プロジェクトのディレクトリはWSL2のUbuntu上 Python、gitはUbuntuのものを利用 プロジェクトのルートディレクトリにある.venvにvenvでPythonの仮想環境を作成してある 問題点 遭遇したpre-commitの問題点は次の通りです。\npre-commitの設定でrepo:localでローカルのプロジェクトにインストールしたコマンドを利用するように変更 すると、PyCharmでコミットすると、blackなどのコマンドが見つからない ターミナルでコミットするときはきちんと動作する 色々調べて試行錯誤した結果、現在はrepo:localでのローカルコマンドを使用する方法はあきらめました。 移行は、作業記録みたいなものです。どういう流れでpre-commitを取り込み、ローカルに切り替え、切り戻したかという話です。\npre-commitとpre-commit 最初に少し戸惑ったのは、pre-commitというツールとgitのpre-commitフックです。 gitのpre-commitのフックのために作られたPython製のpre-commitというツールがあります。\nこのPython製のツールを利用することで、プロジェクトに.pre-commit-config.yamlという設定ファイルを置けば設定に記述されたツールをgit commitのタイミングで実行してくれます。 実際には、pre-commitというツールの初期設定のタイミングでpre-commit installというコマンドを実行して .git/hooks/pre-commitというスクリプトが生成されます。 gitコマンドはcommitされた時に（commit前のフェーズ）でこのスクリプトを実行し、そこで.pre-commit-config.yamlが参照されています。\n.pre-commit-config.yamlの記述は次のようなものになります（最初にもらったPRより）。\nrepos: - repo: https://github.com/psf/black rev: 23.3.0 hooks: - id: black args: [\u0026#34;--line-length\u0026#34;, \u0026#34;120\u0026#34;, \u0026#34;.\u0026#34;] - repo: https://github.com/pycqa/flake8 rev: 6.0.0 hooks: - id: flake8 - repo: https://github.com/pycqa/isort rev: 5.12.0 hooks: - id: isort args: [\u0026#34;--profile\u0026#34;, \u0026#34;black\u0026#34;, \u0026#34;--filter-files\u0026#34;, \u0026#34;--multi-line\u0026#34;, \u0026#34;3\u0026#34;] - repo: https://github.com/pre-commit/mirrors-mypy rev: v1.4.1 hooks: - id: mypy 実際に、PRを取り込んで動かしてみたところ、blackなどが動いて行末のスーペースの除去や未使用のimportについて指摘をしてくれました。 便利だなと思ったのですが、ここで疑問が。\n今回は対象とするプロジェクトはpoetryで依存パッケージの管理を行っています。 今回、上記を動かすためにpoetryに追加されたものはpre-commitだけでした。 「あれ？blackとかはどこにあって、どうやって動いてるんだ？」という疑問が出てきます。 コンフィグファイルにはパスなどの記載をせず、それぞれのgithubリポジトリの記載とバージョンがあるからです。\npre-commitが使用するツールのインストール先 調べてみたところ、どうやらホームディレクトリにある.cache/pre-commitにblackなどのコマンドが見つかりました。 pre-commitツールが設定ファイルを基に、必要なコマンドをgithubからダウンロードしてきて実行時に利用しているようです。 pre-commitは便利なのだけど、せっかくPythonのプロジェクトだしそれぞれのツールはpoetryでpyproject.tomlでバージョンや設定を管理したほうがすっきりするのではないか？ということで、少し調べてみました。\n同じようなことを考えている方がブログを残していてくれました（Pythonレポジトリ用のpre-commit環境を整える）。 設定をpyproject.tomlに移行し、そのあと、ローカルのpetryでblackなどのコマンド類をインストールして利用する設定に書き換えています。 先人の肩に乗っかって、手元で同じようにpre-commitの設定ファイルのrepoをlocalに書き換えていき（その時のコミット）、ターミナルでpoetry run pre-commit run -aで動作確認できました。\nPyCharmでコミットしたらエラー ですが、実際に変更した状態でPyCharmからコミットしたら、コマンドが見つかりませんというエラーが出ます。。。 WSL2のターミナルでgit commitした場合は問題ありません。 どうして？となりますよね。。。。\n.git/hooks/pre-commitはPyCharm、ターミナルのどちらからも実行されています。 ですが、PyCharmではblackなどが見つからないというエラーが出ました。\n.git/hooks/pre-commitを見てみると、python実行するためのpythonのパスはプロジェクトにある.venv/bin/pythonを指定しています。 デバッグのために、このスクリプトにecho $PATHを差し込んで、git commitをPyCharmとターミナルからそれぞれ実行してみたところ、大きな違いがあります。\nターミナルで実行した場合は、\u0026lt;プロジェクトのディレクトリ\u0026gt;/.venv/binもPATH環境変数に存在していました。このため、.venv/binにあるblackなどを実行できています。\nPyCharmはWindowsから起動しています。プロジェクトのインタプリタとしては、WSL2のUbuntuにある.venv/bin/pythonを指定しているためもあり（？）、出力されたパスは/mnt/c/などのWindowsのパスなども入っていたりしますが、\u0026lt;プロジェクトのディレクトリ\u0026gt;/.venv/binは見つかりません。\nここからはソースコードは読んでいないので憶測ですが、.git/hooks/pre-commitで呼び出されているpre-commitツール（Python製）は、設定ファイルで指定されたコマンド（blackなど）を、コマンドとして今の呼び出されたコンテキストで実行しているのではないかということです。 実際、ターミナル上でもsource .venv/bin/activateを実行していない状態だとコマンドが見つからないというエラーが出ました。\n対処方法は？ ということで、今考えられる対処方法としては次の通りです。\n.git/hooks/pre-commitのスクリプトを修正して、\u0026lt;プロジェクトのディレクトリ\u0026gt;/.venv/binのパスを見えるようにする PyCharmで何かしらの設定を探す PyCharmではgit操作しない repo:localはあきらめて、.pre-commit-config.yamlでblackなどは管理して、pyproject.tomlからは除外する 1.ですが、.git/hooks/pre-commitはprecommit intallを実行すると自動で生成されるスクリプトです。自分の環境で書き換えたとしても他の人が同じ環境を作るときにパッチを当てるなどをしないといけなくなります。\n2.はそれらしい設定を見つけることができませんでした。\n3.はめんどくさいですよね。。。ターミナルでgitのコメントを日本語で書くためにいくつか他の設定を考えないといけないです。。。\nということで、今回は4.の対処をとりました。やりたいことは、ツールや環境をそろえるのではなく、プロジェクトでやりたいことをやることなので。。。\nまとめ 最終的には元に戻ってしまいました（pyproject.tomlに設定周りは移動した）。 Windows環境がちょっとややこしくしてるかもな？というのと、個人のプロジェクトなのでそこまで気にしなくてもいいのでは？というのもありそうです。 それにしても、世の中の皆さんはフォーマッターとかどのタイミングで動かしてるんだろう？とかどういう環境構築してるんだろう？とか気になってます。 最近だとこういうディレクトリ構造にする、こういうツールを使うと便利などあれば、コメントいただけると嬉しいです。\n教えてもらったISIDのブログ（Dev Containerを使ってステップバイステップで作るPythonアプリケーション開発環境 - ISID テックブログ）も参考にさせてもらおうと思ってるところです。Pythonの環境をコンテナに移動したいなぁというのもあるので。ただ、PyCharmだからこのブログの通りには行かないけど（VS Codeに移るのも検討したほうがいいのかなぁ）。\n参考サイト Git - Git フック pre-commit Pythonレポジトリ用のpre-commit環境を整える Dev Containerを使ってステップバイステップで作るPythonアプリケーション開発環境 - ISID テックブログ ","date":1688954148,"dir":"post/2023/","id":"698cf3cbd796161d82c9ac438ebab5d2","lang":"ja","lastmod":1688954148,"permalink":"https://blog.johtani.info/blog/2023/07/10/pre-commit-and-python/","publishdate":"2023-07-10T10:55:48+09:00","summary":"最近、趣味（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書き始めました。 きちんとPythonのプログラムをプロジェクト","tags":["python"],"title":"pre-commitとvenvとPyCharm（困ったな？）"},{"contents":"今年もこの季節がやってきました。 Berlin Buzzwordsにオンラインで出張してました。 今年もハイブリッド開催をしてくれたので、オンラインで参加できました。 現地ではブースが出たり、朝食なども用意されているようでした。今年は昨年と違いマスク必須でもなくなったようです。 MICESも去年同様、現地開催のみのようです（今見たら、昨年のビデオとスライドが公開されてるので、時間見つけてみてみよう）。\n今年はうれしいことに検索に絡むセッションが大多数でした。世の中的にChatGPTの盛り上がりやベクトル検索がいろんな検索エンジンで使えるようになってきたこともあり、 大規模言語モデルと検索エンジン、ベクトルデータベースに関する話がたくさんありました（昨年まではKafkaやストリーム処理の話も多かったんですが）。\nということで、今年もセッションを見ながら残したメモを公開しておきます。\n簡単にメモ What defines the “open” in “open AI”? セッションページ：What defines the “open” in “open AI”? 動画： Jennifer Ding - What defines the \u0026ldquo;open\u0026rdquo; in \u0026ldquo;open AI\u0026rdquo;? - YouTube \u0026ldquo;OpenAI\u0026quot;の話ではなく、オープンなAIとは？という話で、ライセンスの話であったり、コミュニティ（データセットの公開とかベンチマークの共有とか）に関する話であったり。 後半は気を抜いてしまって話をうまく聞き取れてないので、興味がある方はビデオで。。。\nVectorize Your Open Source Search Engine セッションページ：Vectorize Your Open Source Search Engine 動画： Atita Arora - Vectorize Your Open Source Search Engine - YouTube ベクトル検索が流行ってきてるけど、これまでの検索（エンジン）に対して、どうやってベクトル検索を取り入れる？という話です。 ベクトル検索ってどんなもので、どういうことの助けになりそうか？じゃあ、どうやって、これまでの検索が改善したかを見ていくのか？ という、これからベクトル検索を取り入れようとしている時にどのようなアーキテクチャにして、 どのような考慮するポイント（モデルの選択とかスケーラビリティとか）にどんなものがあるのか？といった紹介でした。 ざっくりですが、ベクトル検索やるのにどんなことをやっていけばよいのか？という地図になるようなセッションでした。\nSupercharging your transformers with synthetic query generation and lexical search セッションページ： Supercharging your transformers with synthetic query generation and lexical search 動画： Milind Shyani - Supercharging your transformers with synthetic query generation and lexical search - YouTube AWSの人の話でした。こちらもトランスフォーマーが検索に使えると便利だよねという話なのですが。 LLMを使うと高コストでサイズがどんどん大きくなっていて、小さな学習済みのモデルだといまいちな精度でだし、 ファインチューニングしたい場合、ドメインに特化したデータはなかなかないよね。とくにデータ（検索したいもの）はあるけど、クエリがないということがよくあるよね。 そこで、LLMを使って、データからクエリを作って、正解データを作り、それでファインチューニングすればいいのでは？ ということで、やってみました、どうでしたという話でした。\nブログなどもあるので参考にすると面白いかも\nThe Debate Returns (with more vectors) Which Search Engine? セッションページ：The Debate Returns (with more vectors) Which Search Engine? 動画：Charlie Hull - The Debate Returns (with more vectors) Which Search Engine? - YouTube 今年も検索エンジンの人を集めてパネルディスカッションです。今年は次の方たちが参加してディスカッションでした。\n参加者 Jo：Vespaの人。ランキングとかがよくできてるからVespa好き Alessandro：Apache Solrの人。SolrのPMCメンバー。なんでSolr？Pure OSSだし。スケーラブルだ Etienne：Weaviateの人。新しいAI nativeなベクトルデータベース Philipp：Elasticの人。 Kacper：Qdrantの人。 質問は次のようなものでした。\n最初の質問：スケールの話。スケールアウトかな？ 2つ目の質問：どんなアプリケーションが適していないか？ 3つ目の質問：どうやってAIをサポートできるの？ 4つ目の質問：どうやってコミュニティにアプローチしてる？ 5つ目の質問：自分の検索エンジンが使えない時に何を使う？ 6つ目の質問：今後に何が面白そう？ 最後の質問：あなたの検索エンジンが使われてるユースケースで一番好きなものは？ 2つ目や5つ目の質問が面白いですよね。実際の内容はぜひビデオを見ていただくのがいいかと（メモも取ったけど、聞いてもらうほうが面白そうだし）。\nWhat\u0026rsquo;s coming next with Apache Lucene? セッションページ：What\u0026rsquo;s coming next with Apache Lucene? 動画：Uwe Schindler - What\u0026rsquo;s coming next with Apache Lucene? - YouTube 毎年恒例Uweさん。今年Luceneが25周年という話で、これまでの進化の話を駆け足でしてくれました。 あとは、後半は来週9.7が出るよということで、9.7で入ってくるベクトルの距離計算の最適化に関して説明してくれています。 次のバージョンのElasticsearchでもこの最適化が使えるようになるという話もされていましたので、ベクトル検索を使ってる方は、次のバージョンも楽しみですね。\nBuilding MLOps Infrastructure at Japan\u0026rsquo;s Largest C2C E-Commerce Site セッションページ：Building MLOps Infrastructure at Japan\u0026rsquo;s Largest C2C E-Commerce Site 動画：Berlin Buzzwords 2023： Building MLOps Infrastructure at Japan\u0026rsquo;s Largest C2C E-Commerce Site - YouTube メルカリの検索システムに関係しているMLOps周りがどうやって進化してきたのか？という話でした。 英語にいらすとやの絵があるスライドがドイツで使われているのがとても新鮮ですｗ\nHighly Available Search at Shopify セッションページ：Highly Available Search at Shopify 動画：Khosrow Ebrahimpour - Highly Available Search at Shopify - YouTube Shopifyの検索プラットフォームチームの人の、Shopifyの検索プラットフォームがどういったものか？（EsとKafka使ってる）どんな工夫をしているか？という話です。 Kubeconでも他の同僚の方が話をされている見たいで、そちらも参考になるとのことでした（動画）。 スキーマ変更時の話とかもあり、実践的でした。最後に将来的な話でやはりベクトル検索というキーワードが出てきていました。あとは、データ量が大きいのでスケーリングの挑戦もあるとのこと。\nUsing Dense Vector search at the EU Publications Office セッションページ：Using Dense Vector search at the EU Publications Office 動画：Martin Bayton - Using Dense Vector search at the EU Publications Office - YouTube EUのPublication Office（日本だと公文書館とかになるのかなぁ？）の検索サービスで、Googleみたいなこと（検索結果の上にスニペットが出たり、そこにハイライトされたり）をやってみたいよね？という話みたいでした。実際公開してるかはわからないですが、途中からはPureinsightsという会社のプラットフォームで似たようなことをやるデモになってました。\nGoogleでも12%のクエリが、質問の自然文になっているという話で、検索結果にナレッジグラフからの情報（スニペットとか、質問に対する答えとか、地図とか）が出るようになってきていますと。 それをPublication Officeのデータで再現したデモを行った後に、どんな感じのアーキテクチャなのか？という概略を説明されています。国会図書館とかの検索サービスやってる方が興味を持ったりするかもなーと思ったり、思わなかったり？\nLearning to hybrid search セッションページ：Learning to hybrid search 動画：Berlin Buzzwords 2023： Learning to hybrid search - YouTube これまたキーワード検索とセマンティック検索のハイブリッドの話です。 よくハイブリッド検索というのを聞きますが、データだったりベンチマークなどの話があまりないですよね？昨年AmazonがECSIというデータセットを公開したりしています（rejasupotaroさんが年末に書かれた記事にも出てきていました）。 これにLearn to Rankとかもテストできるようなデータ（レビューや評価、カテゴリーとか）を拡張したものを作って、それをもとにいろいろとハイブリッド検索で精度を測ってみたというお話でした。 Metarankというリランキングエンジンの会社の方たちで、Metarankを使ってハイブリッドな検索結果のリランキングで精度がどのように上げられるか？という話です。 今年のTRECのProduct Search Trackの話もされていました。 これが元ネタのブログかな？\nCatch the fraud — with observability and analytics セッションページ：Catch the fraud — with observability and analytics 動画：まだ？ 最後は元同僚のセッションです。こちらは検索ではなく、ちょっと自虐的なネタをもとにしたオブザバビリティおよび分析のお話です。 コミュニティの人たちの貢献（ブログ書いたりプルリク送ったり、どこかで話をしたり）を計測して、年間の貢献者に対してプレゼントを上げるというのをやっているみたいです。 で、昨年の最も貢献した人にMac Bookをプレゼントするというすばらしい（暴挙）話で、チートしようとした人がいてそれを分析した話でしたｗ 締め切り直前に信じられない量の貢献したという登録がブラジルからあり、何かおかしいよね？ということで、Elastic Stackのオブザバビリティの機能などを元に分析してチートした人を除外していったよという話でした。 Kibanaが使いやすくなってるのがわかるセッションで面白かったです。\nまとめ 検索がまたすごく盛り上がってきたなーという時間があるカンファレンスでした。みんな似たような話（ベクトル検索、LLM、AIなど）だったりしますが、 知らないプロダクトで興味が出てくるものもあったし、Amazonのデータセットがあるからいろいろ試してみることもできそうだなぁと。\nすでにビデオが公開されはじめているので、気になったセッションのビデオも見てから後日またブログを書こうとおもいます （たぶん、一覧が作成されるので後日リンクを貼っておきます）。\n来年の予定（6月11日から開催）も公開されていましたし。来年も楽しみですね。 来年はプロダクションでベクトル検索やってみた話とかがさらに出てくるのかなぁ？\n","date":1687278645,"dir":"post/2023/","id":"9335522f4c8dbc7256a42a091e6e00bc","lang":"ja","lastmod":1687278645,"permalink":"https://blog.johtani.info/blog/2023/06/21/attend-berlin-buzzwords-2023/","publishdate":"2023-06-21T01:30:45+09:00","summary":"今年もこの季節がやってきました。 Berlin Buzzwordsにオンラインで出張してました。 今年もハイブリッド開催をしてくれたので、オンラインで参加で","tags":["conference","belin buzzwords"],"title":"今年もオンラインでBerlin Buzzwordsに参加した"},{"contents":"今年もなんとか振り返りブログを書いてます（時間大丈夫かな？w）。紅白をリアタイで見ながら。\n振り返り（2021年に書いた抱負から） まずは振り返りをと。\nフリーランス継続 ありがたいことに個人事業主として今年も１年乗り越えられました。 ZOZOさんには引き続きお世話になっている感じです。 10月からは今月末まで別のお客さんを手伝っていたりという感じでした（アップグレードの手伝いとか）。 相変わらず完全リモートで作業をさせていただいてます。\nただ、来年は今の所、余力がある感じになっているので、新しい仕事を見つけたいところだなあという感じです。 検索で何かお手伝いできることあれば、気軽にお声がけいただければと。\nプログラミング Linderaの大須賀さんのおかげで、レビューは定期的にやらせていただいてますw 業務がっつりというほどではないのですが、検証用のコードを書いたりはしています。\n個人用では、BGM環境のためにシェルを書いたり、文字化けしてるデータを解析したりするのにコードを書いてますが、もうちょっと量を増やしたいところです。 コードがっつり書く仕事をやらせてもらうのとかやらせてもらうのがいいかもなぁ。\n書くよりもどうしても読むほうが多くなってる気がします。\nブッチャー本ちゃんと読む 全部ではないですが、ZOZOさんで輪読をしたりしていました。 が、自分で全部読むといったところまではできてないです。\n読んだ本のブログを書く これはできてないですね。 読むのはちょとちゃってるんですが、ブログを書くところまではできてない。 メモとりながら読みたいですね。\n振り返り(今年あったできごと) ここからは今年の出来事を。 今年もずっと自宅で仕事した。来年は出張とかできるのかなあ？\n自宅環境 今年もDIY 検索ペンギン本が出版された 仕事場を模様替えしました。 今年もずっとWindows環境をメインで仕事をしていました。 年末まではM1 Macを借りて作業するという経験もできたのでよかったです。 今年仕事の環境は少し変わって、AVアンプ（譲り受けたもの）＋Polk Audioのスピーカーで音が良くなりましたw あと、机の天板を大きくして、作業がやりやすくなりました。写真はそのうち。\n仕事場の模様替えにもなるのですが、今年のDIYはラブリコ＋有孔ボードでケーブルやキーボードをすっきり片付けられる環境を作ってみました。 壁を有効活用できるのはよかったです。こちらについては、別途ブログを書こうと思います。\n今年最大のニュースは検索ペンギン本を出版したことです。 声をかけていただいた打田さんには感謝です。著者の皆さん検索システムを色々と手掛けられているので良い本になったと思います。\n『検索システム ― 実務者のための開発改善ガイドブック』 – 技術書出版と販売のラムダノート おー、届いたー pic.twitter.com/RbY5tOe9GB\n\u0026mdash; Jun Ohtani (@johtani) May 17, 2022 いろんなところで輪読も開催されているようで、顔を出してみたいなぁ。 輪読やってます！外部の人を呼んでもOKという方がいたら、参加してみたいのでTwitterでメンションしてもらえると嬉しいです。\n来年の抱負 ということで、来年の抱負です。\nフリーランス継続 プログラミング ベクトル検索まわりをさわる 本を読む 今年もありがたいことに仕事を継続していただけて、乗り越えられました。 来年も価値を提供できるように頑張っていきます。 もっといろんな会社の検索システムを見てみたいですし、検索エンジン入れてみたけどここからどうすればいい？という方も増えて来ているような気がするので、気軽に声をかけていただければと。\nプログラミングは、家の音楽ファイルの文字化けを直すプログラムをもう少しちゃんと書いてからブログを書きたいなと。まぁ、個人的なプログラムなので誰も嬉しくないかもですが（色々検討した結果Javaで書いてる）。 あとは、オライリーさんの初めてのGo言語を買ったのもあるので、前にRustで書いたElasticsearchへのBulk登録のツールをGoで書いてみようかなと考えているところです。みんなはデータ登録するときはどうしてるんだろう？\nNLPでBERTなどによる目まぐるしい進歩の影響もあり、ベクトル検索やセマンティック検索といった検索技術が各社から出て来ています。 ElasticsearchでもGAされたのもあり、今後ますます注目を浴びる技術になるのだろうなと。 ただ、これまでの検索とどう組み合わせるのがいいのか？どう言ったメリットデメリットがあるのか？向き不向きは？といったものもあるので、仕組みを調べながら色々と試行錯誤してみたいと思っています。\nさいごは、毎年書いてる気もしますが、本を読むのもやらんとなぁ。 あたらしいネタを仕入れては実践できる時間もとりつつ、他のことにも目を向けたいと思っています。\n今年は仕事の変化も少し出て来ているので、来年は新しいことをいくつかやってみたいところです。 あとは、外に出る機会が増やせるといいなぁ、少しずつ人から刺激をもらいたいと思っています。\nさて、今年は年内に無事描き終わりました。 来年もよろしくお願いいたします、良い年にしたいなー。\n","date":1672486684,"dir":"post/2022/","id":"df30d810068e4656498e5972c6de7e3d","lang":"ja","lastmod":1672486684,"permalink":"https://blog.johtani.info/blog/2022/12/31/review-2022/","publishdate":"2022-12-31T20:38:04+09:00","summary":"今年もなんとか振り返りブログを書いてます（時間大丈夫かな？w）。紅白をリアタイで見ながら。 振り返り（2021年に書いた抱負から） まずは振り返","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2022）"},{"contents":"PySpaアドベントカレンダーの12/15のエントリーです。昨日はtaichiさんでした。 今年はDIYではなく、PCにまつわる話を。\n仕事中はBGMが基本 フリーランスを始めて（2020年初頭）からすぐに、自宅で仕事をする情勢になりました。 打合せをしていないとき、カンファレンスの発表などの動画を見ていないときは基本的にBGMをかけて作業をしています。 音源としては、CDなどから音楽ファイルにしたり、AmazonやSonyのサイトで購入した音楽ファイルなどがNASにあります。\n今年10月までの環境 2020年の後半に次のような環境を構築して今年の10月まで使っていました。\nLibreELECをラズパイ4に入れて、Kodiのリモコンをスマホに入れたら快適になった\n\u0026mdash; Jun Ohtani (@johtani) October 20, 2020 KODIと呼ばれるマルチメディアセンター？のようなソフトで、それを動かす最小限のOSとして、LibreELECが公開されています。 これをラズパイ4に入れて、NASからファイルをSSDにコピーしてそれをラズパイに接続して音楽を聞いていました。 毎回ラズパイの画面を見に行くのも面倒なので、再生などの操作にはAndroid用のKodiのリモコンアプリを使っていました。\n場所も取らないのでよかったのですが、使っているといくつか問題点が。\n時々調子悪（音が出ない、リモコンからつながらない、無反応など）くなって、ラズパイ再起動 音楽ファイルを購入して増えた時に、外付けSSDを取り外してPCでコピーしたり スマホじゃないと再生できない（PCのクライアントもあったのかもだけど調べてなかった） Ubuntu on Mac mini 10月に模様替えをして、2012年製のMac Miniが宙ぶらりんになりました。 さすがに古いしメインマシンがWindowsになっているのもあり、macOSである必要も特にないので、Ubuntu 22.04を入れて何かに使えるのでは？と。 また、1TBのSSDに内臓ディスクを乗せ換えていたのもあり、音楽再生に使ってみようということに。 なので、Kodiの環境で困っていた点も考慮して、ほしい機能を元にちょっと探してみました。\n音楽再生 on Ubuntu 音楽再生でほしい要件としては次のようなものです。\nUbuntuで音楽再生できるソフト（あたりまえ） PCから操作したい（できればブラウザ） 音楽ファイルの更新（ローカルでもいいけどNASからもってきたり） 日本語の曲情報も表示 対象音楽ファイルが豊富（そんなに制限があるものはないだろうなぁ） 上記の要件をもとに適当にググって見つけてきたのがOwnToneというソフトでした。\nOwnTone OwnToneの説明は公式サイトを見ていただくとして、OwnToneにしてよかったなというのが以下の点です。\nインストールが簡単（apt-getでインストールできる） サポートフォーマットが豊富 Web UIがついてる（ブラウザで見えるし、スマホでもOK。どのブラウザから見ても今の状況も分かる） 簡単だけど検索できる プレイリスト対応（ファイルパスを入れるだけ） サムネイルとかも出てくる（どうやってんだろう？ｗ） AirPlayで再生できる（AVアンプを利用しており、そこにAirPlayで再生できてる） OSS（まだソースは見たことないですがｗ） 再生画面例\nやっぱ検索も気になるよね？\n日本語も検索できるな。 pic.twitter.com/EF6WHkJKli\n\u0026mdash; Jun Ohtani (@johtani) October 19, 2022 とりあえず、インストールして画面もすぐに出て操作も簡単で、便利な世の中になったなーと感動しましたｗ\nただ、音がヘッドフォン端子に刺したアナログ出力先のスピーカーではなく、本体のスピーカーで最初はなってしまいましたｗｗ Linuxの音周りが全然わかってない問題が発覚。\n幸い、先週のPyspa Advent Calendarのエントリーを書いていたaodag先生に助言をいただき、alsamixerで音の設定を見たところ、ヘッドフォン端子がミュートされていたので、ミュートを外して無事再生できました。 インストール当初はYAMAHAのアクティブスピーカーにJust Mixer経由でヘッドフォン端子（アナログ）で出力して音楽再生をしていました。 今は（この記事を書いてる現時点で）、AVアンプのAirPlayにOwnToneから音を流している形で聞いています（便利なんだけど、当初の想定とは異なる、理由は後述）。\nファイルのコピーとか さて、上にも書きましたが、NASにバックアップもかねて音楽ファイルを保存してあります。 新しく買ったファイルもここに置くようになっています。 OwnToneのMac MiniからNASをネットワーク経由で見に行くのもいいのですが、できればローカルにあったほうがネットに影響も出ないなと。\nということで、定期的にNASをウォッチしてMac Miniにファイルをコピーするようなプログラム（Bashスクリプト）を書いてみました。 毎回購入後に手で実行もめんどくさいので毎日夜中にcron実行するような設定になっています。\nスクリプトの中身は次のような感じです。\nfindコマンドで特定の日時（最近コピーしたファイルの日付）以降(-newermtオプション)のファイルのリスト（音楽ファイルの拡張子に限定）を取得 取得したリストをもとに以下の操作 ファイルをコピー コピーしたファイルをコピーした日付のプレイリストを作って入れる（プレイリストはパスだけ書けばOK） mp4形式だと聞けない端末もあるので、soundconverterコマンドでmp3に変換してNASに戻す 最新のファイルの日付を保存（次回のfindコマンド） ファイルがあったら、OwnToneの再読み込みのエンドポイントをcurlでキック NASはSambaでマウントして、見えるようにしてあります。 やっぱり、自動化便利ですねぇ。 気に入った曲を買ってNASに入れとけば聞けるようになるのは本当に便利。\n他にもスマートプレイリストとかもあるので、活用しないとな。\n今後の課題 さて、すごく便利になったのですが、課題も残っています。\n音声出力問題 アナログ出力はaodag先生の助言ですぐに解決したのですが、takabowから譲り受けたAVアンプを導入してから実は音の出力がうまくいっていません。\nHDMI、光端子出力でAVアンプにつなごうとしたのですが、私のUbuntu力（Linux力？）が全然不足しているのでうまくいっていません。ググりつつ、HDMI、光出力でamixerというコマンドで音声ファイルを鳴らすところまでは行ったのですが、OwnToneに設定するとうまくいかない状況です。 結局、解決してないのですが、AVアンプのAirPlayのレシーバー経由で音楽再生ができてしまったので、とりあえずAirPlayで運用することにしました。時間を見つけてaodag先生の記事を読み直して再チャレンジしないとな（けど、鳴ってるしなぁ、音ｗ）。\n文字化け問題 これは、OwnToneというよりはもともとあった問題です。 古い音楽ファイルだったり、Wav形式のファイルなど、様々な形式のファイルを持っています。 音楽サーバーとは別に、音楽ファイルの検索をできるようにしつつ、付加的な情報（Wikimediaなどのデータとか）を付与して、検索できるようにしてみようと思い、音楽ファイルからメタデータを抜き出して、ElasticのApp Searchにいれるデータを作るツールを書いたりしています。 この時にも文字化けに遭遇しました。\n様々な音楽ファイルにはメタデータを付与することができる仕様が決まっています（ID3タグ - Wikipediaなど）。 ただ、文字コードの情報が入っていなかったり、デフォルトとは違う文字コードでデータを付与したファイルがあったり、いろいろな原因で文字化けしているものがあります。 昨年Amazonで購入したmp3の中にも文字化けしているものもあったりします。Wavファイルに付与されたタグなどは、容赦なくShift-JISだったりしますが、読み込むソフトはUTF-8で読もうとしたり。。。\n検索サーバーにデータを抜き出して入れるツールを書いているときは、元のファイルを変更することなく、抜き出す時点でいくつかの文字化けに対応した処理を書いたのですが、今回のOwnToneで曲を流すと結局、元のファイルをきれいにしないとダメだということに気づきました（すぐわかるだろ。。。）\nということで、書いている途中のツールをもとに、根本的な文字化けのファイルのメタデータをきれいにするプログラムを書かないといけないなぁと。\nちなみに、メタデータの抜き出しにはJavaでプログラムを書いており、JAudiotaggerというライブラリを利用しています。 Pythonや他のJavaのライブラリを試そうとしたのですが、文字コードが決め打ちで抜かれているものが多く、ライブラリから読みだした時点ですでにどうしようもない状態のものが多いといった問題からこのライブラリにたどり着きました（まぁ、まだちゃんとしたものができていないんですけどね）。\n検索サーバー OwnToneのUIはブラウザでうごきます。 検索窓もついています。 が、先ほども書いたように、他にもデータを追加して、いろんな検索をしてみたいなぁと（ドラマに使われてたとか、CMにつかわれてたとかとか）。 検索が好きでいろいろとやってるので、その辺も遊んでみたいなぁと思っているところです（実際、ElasticのApp SearchにWikidataから生成した類義語を入れてみたりしている）。\nこうやってブログにしてしまったので、課題をつぶしていなかったら、Twitterなどでつついてくださいｗ\nまとめ 構成図とかは書かなかったですが、OwnToneを使うと簡単にWeb UIが入った音楽サーバーが使えるようになって、仕事がはかどりますよという記事でした。 他にもこれに関するネタを募集してますので、コメントもらえるとうれしいです（Twitterでメンションも大歓迎）。\n","date":1671030358,"dir":"post/2022/","id":"67c2ae6761e89be0fa66db9623b40d30","lang":"ja","lastmod":1671030358,"permalink":"https://blog.johtani.info/blog/2022/12/15/music-server-on-mac-mini/","publishdate":"2022-12-15T00:05:58+09:00","summary":"PySpaアドベントカレンダーの12/15のエントリーです。昨日はtaichiさんでした。 今年はDIYではなく、PCにまつわる話を。 仕事中は","tags":["misc","music"],"title":"仕事中のBGM環境"},{"contents":"本記事は情報検索・検索技術 Advent Calendar 2022の9日目の記事です。\nだいぶ間が空いてしまいましたが、日本語のオートコンプリートに関する記事の続きです。 という感じで、Suggesterのデータ構造とか仕組みを書こうと思っていたのですが、思ったよりも調べないといけないことが多くて挫折しました。。。 （これの続きは年末年始で調べて書くはず？）\nということで、代わりにElasticsearch/OpenSearchのアーキテクチャの変更に関してさらっとまとめてお茶を濁してみようと思います。\n発端はElasticON Tokyo？ 先週の11月30日に、ElasticのオフラインイベントであるElasticON Tokyoが開催され参加しました。 参加しようと思ったのは、10月の頭にElasticのブログで公開された「Stateless — your new state of find with Elasticsearch」というアーキテクチャの変更がきっかけです。\n（図はElasticのブログから引用）\nElasticsearchはLuceneのインデックスを分散したシステムとしてスケールアウトできるようにするという目的でリリースされました。 インデックスをシャードという単位で複数のElasticsearchのノードにデータを保存し、レプリカを作ることで分散する仕組みを実装していました。 Elasticsearchでは、インデックスのレプリカは、作成したインデックスを定期的にコピーするのではなく、登録するデータがElasticsearchのクラスターにやってきた時に、 データ自体をコピー先にも配り、プライマリーやレプリカとなるシャードがあるノード上でそれぞれインデックスに登録する処理を行うという処理の流れです（古いけど、わかりやすい説明はこちら）。 この場合、インデックスにデータを登録する処理（転置インデックスのデータ構造に変換する処理など）は、レプリカの数だけ同じ処理がクラスター上で発生します。\nこの基本的なアーキテクチャをもとに、保持するデータの鮮度（新しいデータのほうが検索頻度が高い、インデックス登録する時はマシンは多く、古くなったデータが入ったインデックスはコストが低いマシンになど）などを元に、クラスター内のノードの特性を異なるものが混在するような複雑な仕組みを作ってきました。 いろいろなデータの持ち方などで多くのデータなどを保持できるようにしてきたのですが、クラスター全体としては、検索の負荷のピークをさばけるような構成を基本的に保持しておくというかんがえです。\nただ、昨今は必要に応じてスケールアウト（リクエストが増えたりデータ量が増えた時）、スケールイン（夜中は利用者が少ないからクラスターを小さくしたい時）できるような仕組みのほうが求められています。 そこで、発表されたのが上記のブログであり、上図の新しいアーキテクチャです。 計算処理（データを登録、検索する処理）とストレージを分離し、さらに登録する処理と検索する処理も分離した構成です。 このようなアーキテクチャにすることで、登録処理の演算コストがレプリカごとに必要ではなくなり、検索の部分だけだったり、登録の部分だけをスケールアウト・インできるような自由度が手に入ります。 また、ストレージ部分でレプリカを担保（S3とかのオブジェクトストレージで冗長性を担保）できれば、レプリカのストレージコストも必要なくなります。\nというブログが発表されたのですが、詳細などはまだよくわからなかったのでElasticON Tokyoに参加して詳しい話が聞けるのかなぁと期待していました。\n参加当日の朝のびっくりするニュース 11月30日の朝に起きて、出かけようかと思っていたところに、AWSのre:Inventで発表されたニュースが舞い込んできました。\nほー（まだタイトルしか読んでない）https://t.co/KK22duaBNH\n\u0026mdash; Jun Ohtani (@johtani) November 29, 2022 Amazon OpenSearchがServerlessオプションを発表というニュースです。 （Amazon OpenSearchとは、AWSがElasticsearchをフォークして始めた検索エンジンで、Amazon OpenSearch Serviceというのは、AWSがそれをSaaSとして提供しているものです）\nまぁ、気になりますよね、「Serverless」ってキーワードに。 ElasticON Tokyoに向かう電車でブログを読んだり、どんな仕組みかを調べたので、それを簡単にまとめておきます。\nプレビュー段階（Tokyoリージョンではもう試せる） これまでのAmazon OpenSearch Serviceとは別（オンザフライで移行はできない？） 「コレクション」という単位でクラスターを管理（スケールインとかアウトとか） コレクションにはタイプがあり、タイムシリーズ（ログとか）か検索のユースケースなのかで使い分ける（公式ドキュメント） インデックス処理と検索処理で計算ユニット（OCU）が別々にスケールできる（下図） 作成されたインデックスはAmazon S3に保存され、そこで冗長性は担保される。（下図） 検索処理のユニットはS3のデータをローカルに持ってきて処理をできる データ登録とかのAPIは基本的にServerlessかどうかで違いはなさそう(これまで通りのクライアントでアクセスとかで競う) 設定した範囲でいいかんじにスケールアウトインしてくれそう（ほんとかな？） もちろん、いくつか制限がある（サポートしてないプラグインとか操作もある） （図はAWSのドキュメントより引用）\n発表時のブログでは詳しくはわからないのですが、公式ドキュメントではさらに詳しく説明がありました。 こちらを読むほうが仕組みがわかると思います。 今後もどんどんドキュメントは充実していくんだろうなと。今ならまだサクッと読める量ですｗ\nただ、「サーバーレス」という定義が私はよくわかりませんでした。 公式ドキュメントを読むとコレクションを作ると少なくとも4つのOCUが起動しているみたいで課金されると記載があります。\nまぁ、Elasticの発表と同様に、これまでは最大負荷の時を元にクラスターを維持せずとも、より柔軟に検索だけ、登録処理だけを一時的にスケールできるとコストを下げられそうですね。 すぐに誰かが使ってみたブログなどを出してくれると思うので、細かな使用感などはそのうちわかってくるかと。\n今後は？ ElasticもAWSも考え方の基本となっているのは、Berlin BuzzwordsでAmazonのMikeさん（Luceneのコミッター）が2019年に発表されたものだと思っています。 アーキテクチャの変更がどんな影響が出るかはわからないですが、少なくとも検索のユースケースでよりスケールアウトしやすくなるだろうなと。 どちらもSaaSとしての仕組みとして提供するので、検索エンジンそのものの機能として公開されるかはわからないです。 ですが、そのほかの検索エンジンも出てきていますし、今後も検索エンジンから目をはなせないです。 今回は残念ながら触っていませんが、時間を見つけて使ってみたいです（Elasticも早く出してくれないかなー）\nということで、当初の予定とは違うブログになってしまいました。。。 技術的な深い話はまたどこかで。。。\n参考文献 Stateless — your new state of find with Elasticsearch | Elastic Blog Preview： Amazon OpenSearch Serverless – Run Search and Analytics Workloads without Managing Clusters | AWS News Blog Berlin Buzzwords 2019： Michael Sokolov \u0026amp; Mike McCandless–E-Commerce search at scale on Apache Lucene - YouTube ","date":1670516125,"dir":"post/2022/","id":"9693a1e77dee5785b1dc61ccffd2e906","lang":"ja","lastmod":1670516125,"permalink":"https://blog.johtani.info/blog/2022/12/09/open-search-serverless/","publishdate":"2022-12-09T01:15:25+09:00","summary":"本記事は情報検索・検索技術 Advent Calendar 2022の9日目の記事です。 だいぶ間が空いてしまいましたが、日本語のオートコンプリートに関する記事の続きです。","tags":["elasticsearch","opensearch"],"title":"ElasticsearchのアーキテクチャとStateless / Serverless"},{"contents":"前回は日本語用オートコンプリートのためのAnalyzerとして、どうやって使うのかを簡単に紹介しました。\n今回はもう少し、いろんなパターンを試してみたいと思います。\nローマ字入力のゆれ 前回のサンプルでも「吾輩\u0026hellip;」のデータをサジェストするためのサンプルとして、「wagah」という「わがはい」をローマ字にしたものを利用しました。\nちなみにローマ字というとどんなものを思い起こしますか？ 普通は学校で習ったヘボン式あたりだと思います。 Kuromojiの読みでローマ字出力するには通常、kuromoji_readingformでuse_romajiをtrueにします。 以下、「吾輩」のサンプルです。\nGET _analyze { \u0026#34;text\u0026#34;: [\u0026#34;吾輩\u0026#34;], \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji_tokenizer\u0026#34;, \u0026#34;filter\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;kuromoji_readingform\u0026#34;, \u0026#34;use_romaji\u0026#34;: true } ] } レスポンス { \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;wagahai\u0026#34;, \u0026#34;start_offset\u0026#34;: 0, \u0026#34;end_offset\u0026#34;: 2, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 0 } ] } 「吾輩」の場合は特に問題ないのですが、ローマ字による日本語入力の場合、次のような単語を入力するときに、ゆれが生じます。\nシャボン＝「shabon」 新橋＝「shimbashi」 括弧内はkuromoji_readingformで出力したもの（＝ヘボン式のローマ字）です。 ですが、ローマ字入力の場合は「syabon」や「shabon」と入力したり、「sinbasi」や「sinnbasi」と入力すると思います。 JapaneseCompletionAnalyzerを利用したCompletion Suggesterの場合、これらのゆれも考慮してサジェストしてくれるようになっています。 前回のサンプルデータを用いると次のような感じです。\nGET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;sha\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } } } GET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;sya\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } } } これらのリクエストは、「しゃ」について2パターンになっていますが、結果はどちらも次のものが返ってきます（このレスはsyaのレスになります）。\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;sya\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 3, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;シャドウ・ワーク\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;000739\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;シャドウ・ワーク\u0026#34;, \u0026#34;朝倉 克彦\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;シャボン玉\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;045054\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;シャボン玉\u0026#34;, \u0026#34;豊島 与志雄\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;上海\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;050899\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;上海\u0026#34;, \u0026#34;横光 利一\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;斜坑\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;002095\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;斜坑\u0026#34;, \u0026#34;夢野 久作\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;社会事情と科学的精神\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;053864\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;社会事情と科学的精神\u0026#34;, \u0026#34;石原 純\u0026#34; ] } } ] } ] } } 「sinnba」や「shinba」も試してみました。\nGET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;sinnba\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } }, \u0026#34;_source\u0026#34;: [\u0026#34;suggest_ja\u0026#34;] } GET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;shinba\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } }, \u0026#34;_source\u0026#34;: [\u0026#34;suggest_ja\u0026#34;] } これらも同じ結果です。\n{ \u0026#34;took\u0026#34;: 0, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;shinba\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 6, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;しんばい\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;044942\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;しんばい\u0026#34;, \u0026#34;村山 籌子\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;新橋\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;002409\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;新橋\u0026#34;, \u0026#34;北原 白秋\u0026#34; ] } } ] } ] } } 入力されるパターンを想定した実装がされているので対応できている形です。 使い方が楽なだけでなく、より使いやすくなってるのは便利ですね。\nうまくいかないパターン 万事OKかというと残念ながらそうでもありません。 うまくいかないパターンもあります（これが本当にうまくいかないかは難しい話な気がしますが）。 「日本」という漢字ですが、「にほん」「にっぽん」どちらとも読めますよね？ これらを試してみると次のようになります（リクエストは省略します）。\nまず「にほん」\n{ \u0026#34;took\u0026#34;: 0, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;にほん\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 3, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;日本橋\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;004565\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本橋\u0026#34;, \u0026#34;泉 鏡花\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本橋\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;045357\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本橋\u0026#34;, \u0026#34;牧野 信一\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本橋あたり\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;047648\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本橋あたり\u0026#34;, \u0026#34;長谷川 時雨\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本橋附近\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;055666\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本橋附近\u0026#34;, \u0026#34;田山 花袋\u0026#34; ] } } ] } ] } } 次に「にっぽん」\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;にっぽん\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 4, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;日本アルプスの五仙境\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;056269\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本アルプスの五仙境\u0026#34;, \u0026#34;木暮 理太郎\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本出版協会論\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;049436\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本出版協会論\u0026#34;, \u0026#34;嶋中 雄作\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化と科学的思想\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;055750\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化と科学的思想\u0026#34;, \u0026#34;石原 純\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化のために\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;003183\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化のために\u0026#34;, \u0026#34;宮本 百合子\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化の特殊性\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;055290\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化の特殊性\u0026#34;, \u0026#34;戸坂 潤\u0026#34; ] } } ] } ] } } 最後に「日本」\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;日本\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 2, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;日本アルプスの五仙境\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;056269\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本アルプスの五仙境\u0026#34;, \u0026#34;木暮 理太郎\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本出版協会論\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;049436\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本出版協会論\u0026#34;, \u0026#34;嶋中 雄作\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化とは何ぞや（其二）\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;002940\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化とは何ぞや（其二）\u0026#34;, \u0026#34;内藤 湖南\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化と科学的思想\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;055750\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化と科学的思想\u0026#34;, \u0026#34;石原 純\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化のために\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;003183\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化のために\u0026#34;, \u0026#34;宮本 百合子\u0026#34; ] } } ] } ] } } 最初の「にほん」は「日本橋」がヒットしているようです。返ってきたoptionsの数は4件しかなく、どうやらこれがすべてのようです（取得件数はデフォルト5件）。 2番目の「にっぽん」は「日本」という単語から始まるものがヒットしていますが、「日本橋」はなさそうでした。 最後に「日本」という漢字を入力にした場合は2つの合計が帰ってきているようです（今回のレスポンス例にはありませんが、サイズを大きくすると「日本橋」が帰ってきていました）。\nどうしてそうなるの？ JapaneseCompletionAnalyzerの基本的な動作としては、\nKuromojiが単語に区切る 区切られた単語ごとに読みを持っている 元の単語と読みをローマ字にしたものが最終的に出てくる というような動きです。 この時、単語には「1つ」の読みが対応しています。 読みから単語を探そうとすると、読みの違い（ゆれ）を吸収することはできないためです。 JapaneseCompletionAanlyzerは3点目のローマ字のゆれに対応していますが、入力となる読みのゆれまでは対応できないです。 対応しているといいかどうかというのも難しい判断になる気もします。。。\nそのほかの例としては次のようなものもあります。 これは、今回のオートコンプリートの話とは少しずれてるかもしれませんが、1番目の処理の結果が変わってくる例です。 「南方熊楠」という名前の間にスペースがあるかないかで、出力される読みが変わってくる例です。\nGET _analyze { \u0026#34;text\u0026#34;: [\u0026#34;南方 熊楠\u0026#34;], \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji_tokenizer\u0026#34;, \u0026#34;filter\u0026#34;: [\u0026#34;kuromoji_readingform\u0026#34;] } GET _analyze { \u0026#34;text\u0026#34;: [\u0026#34;南方熊楠\u0026#34;], \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji_tokenizer\u0026#34;, \u0026#34;filter\u0026#34;: [\u0026#34;kuromoji_readingform\u0026#34;] } # GET _analyze { \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;ナンポウ\u0026#34;, \u0026#34;start_offset\u0026#34;: 0, \u0026#34;end_offset\u0026#34;: 2, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;クマグス\u0026#34;, \u0026#34;start_offset\u0026#34;: 3, \u0026#34;end_offset\u0026#34;: 5, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 1 } ] } # GET _analyze { \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;ミナカタ\u0026#34;, \u0026#34;start_offset\u0026#34;: 0, \u0026#34;end_offset\u0026#34;: 2, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;クマグス\u0026#34;, \u0026#34;start_offset\u0026#34;: 2, \u0026#34;end_offset\u0026#34;: 4, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 1 } ] } 人名や地名は1つの漢字に対して多くの読みが存在しているので大変です。。。 どうしてこれは出てこないんだろう？と不思議に思った場合は、_analyze APIを使ってどういう動きなのかを見てみるのがいいかと。\nまとめ ということで、少しだけですが、こんなことができるよ、できないよというのを書いてみました。 挙動をしっていれば、なんでこうなってるんだっけ？といったことを調べる役に立つかと思います。 入力された文字をもとにどれをサジェストするかなどについてはもう少し違う動きなので、中の仕組みをそろそろ書かないとなぁ。\n参考 同形異音語 - Wikipedia ","date":1660099802,"dir":"post/2022/","id":"73279888a8fe482c836fb19ca23318dc","lang":"ja","lastmod":1660099802,"permalink":"https://blog.johtani.info/blog/2022/08/10/jp-auto-completion-2/","publishdate":"2022-08-10T11:50:02+09:00","summary":"前回は日本語用オートコンプリートのためのAnalyzerとして、どうやって使うのかを簡単に紹介しました。 今回はもう少し、いろんなパターンを試","tags":["elasticsearch","lucene"],"title":"ローマ字入力のゆれと読み（JapaneseCompletionAnalyzerその2）"},{"contents":"風のうわさで、日本語用のオートコンプリートのためのTokenFilterとAnalyzerがLuceneに取り込まれたと聞きました（LUCENE-10102）。 Elasticsearchでも使えるかなぁ？ということで調べたところ（調べた？聞いた？）、どうやら8.1から利用できるようになっている（GitHub Issue #81858）みたいです（まだ、公式ドキュメントには記載がないのですが）。\n8/17追記\n作者の打田さんがブログ書いてたの見落としてた（もしくは見たけど忘れてた）ので貼っておきます。マルチテナンシー下での Query Auto Completion 設計・運用戦略 - LegalForce Engineering Blog\nということで、こんな感じで使えるよというのを試してみました。\nどういうもの？ 日本語入力方法を考慮したオートコンプリート用のトークンを生成してくれるTokenFilterと、 それをLuceneのSuggesterで動くようにしたAnalyzerが用意されています。 Elasticsearchでは、Kuromojiプラグインにそれらを使えるようになっています（バージョン8.1.0以降）。 KuromojiTokenizerと一緒に利用する前提の仕組みとなります。\nオートコンプリートとは？ 検索窓などでキー入力をしていると、入力した文字で始まる単語の一覧が現れることがあると思います。 あの機能がオートコンプリートと呼ばれるものです。search-as-you-typeとも呼ばれることもあります。 （検索ペンギン本にも書いてあるので興味のある方はぜひ！（ステマ）） 入力された文字列を含むパターンもありますが、今回紹介するものは入力された文字で始まる単語を見つけてくる機能になります。\n何がなんで追加されたの？ 日本語の入力方法は、かな入力の人もいればローマ字入力の人もいます。 ですので、オートコンプリートでの入力として、「しゃ」という入力が来る場合もあれば、「sha」というローマ字入力途中のものが来る場合もあります。 これらを考慮したトークンの扱いができるように、 JapaneseCompletionFilterというクラスが追加されています。 内部的にはKuromojiTokenizerでトークンに分割された後に、もともとのトークンと同じポジションで読みをローマ字にしたものを出力します。 JapaneseCompletionAnalyzerは上記Filterをすぐに使えるようにしたAnalyzerです。\n動かし方 百聞は一見に如かずということで、Elasticsearchでの使い方を見たほうが分かりやすいので、簡単に動かしてみることにします。\nインストールとインデックスの用意 Elasticsearch（8.1以上）とKuromojiのプラグインをインストールします（今回試したのは8.3.1）。\nサンプルデータ なにかいいデータはないものか？と思っていたところ夏休みだというのを思い出しました。 夏休みといえば読書感想文だ、ということで、書籍のタイトルがいいかもなと。 青空文庫の著者名と書籍のタイトルの一覧を見つけたのでそちらのデータを使って試してみました。\nCSV to JSON CSVファイルは最後の参考にある青空文庫のページから、「公開中　作家別作品一覧：全て(CSV形式、zip圧縮）」をダウンロードしたものを利用しました。 CSVファイルだったので、jqコマンドで必要な部分だけをNDJSONの形でとりあえずファイルに出力します。\ncat list_person_all_utf8.csv | tr -d \u0026#39;\u0026#34;\u0026#39; | jq -c -R \u0026#39;split(\u0026#34;,\u0026#34;) | {\u0026#34;auth_id\u0026#34;: .[0] | tonumber, \u0026#34;author\u0026#34;: .[1], \u0026#34;id\u0026#34;: .[2] , \u0026#34;title\u0026#34;: .[3], \u0026#34;suggest_ja\u0026#34;: [.[3], .[1]]}\u0026#39; 次のようなJSONが1行ずつ出力されます。\n{\u0026#34;auth_id\u0026#34;:1257,\u0026#34;author\u0026#34;:\u0026#34;アーヴィング ワシントン\u0026#34;,\u0026#34;id\u0026#34;:\u0026#34;056078\u0026#34;,\u0026#34;title\u0026#34;:\u0026#34;駅伝馬車\u0026#34;,\u0026#34;suggest_ja\u0026#34;:[\u0026#34;駅伝馬車\u0026#34;,\u0026#34;アーヴィング ワシントン\u0026#34;]} suggest_jaがオートコンプリートの対象となるデータになります。今回は著作と著者にしてみました。 あとは次に紹介するスキーマでインデックスを作成して、適当なプログラムを使ってBulkでElasticsearchに登録しましょう（私は個人作のツールで入れました）。\nインデックス オートコンプリート用のSuggesterを利用するための特殊なフィールド（completion）を利用したフィールドを用意します。 ちなみに、今回はLUCENE-10102に記載があった設定をそのまま使わせていただきました。 そのほかのフィールドは今回は特に必要はないのでおまけです。\nPUT aozora_index { \u0026#34;mappings\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;completion\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;japanese_completion_index\u0026#34;, \u0026#34;search_analyzer\u0026#34;: \u0026#34;japanese_completion_query\u0026#34;, \u0026#34;preserve_separators\u0026#34;: false, \u0026#34;preserve_position_increments\u0026#34;: true, \u0026#34;max_input_length\u0026#34;: 50 }, \u0026#34;auth_id\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;author\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;text\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;keyword\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;keyword\u0026#34;, \u0026#34;ignore_above\u0026#34;: 256 } }, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34; }, \u0026#34;author_id\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;integer\u0026#34; }, \u0026#34;id\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;integer\u0026#34; }, \u0026#34;title\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;text\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;keyword\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;keyword\u0026#34;, \u0026#34;ignore_above\u0026#34;: 256 } }, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34; } } }, \u0026#34;settings\u0026#34;: { \u0026#34;index\u0026#34;: { \u0026#34;number_of_shards\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;analysis\u0026#34;: { \u0026#34;analyzer\u0026#34;: { \u0026#34;japanese_completion_index\u0026#34;: { \u0026#34;mode\u0026#34;: \u0026#34;index\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;kuromoji_completion\u0026#34; }, \u0026#34;japanese_completion_query\u0026#34;: { \u0026#34;mode\u0026#34;: \u0026#34;query\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;kuromoji_completion\u0026#34; } } } } } } 動作確認 ここまでで、インデックスとデータの用意ができました。 オートコンプリートを実現するためにはElasticsearchのSuggesterという機能の、Completion Suggesterを利用します。検索の仕方が通常のものとは少し異なります。 ちなみに、速度重視のためにインメモリで動いているとの記載がドキュメントにあります。\nCompletion Suggesterのクエリ Suggester用のクエリがあるのでこちらを使います。 例えば、「wagah」という入力がある時に、サジェストする内容を取得するには次のようなリクエストになります。\nGET aozora_index/_search { \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;wagah\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } }, \u0026#34;_source\u0026#34;: [\u0026#34;title\u0026#34;, \u0026#34;author\u0026#34;] } 最初の「suggest」がsuggest用のパラメータを意味しています。 次の「title-suggest」は好きな名前をつけられます。レスポンスにこの名前がついた配列がサジェストの結果になります（同時に3. 複数suggestを呼び出せるので、対応した結果が分かるように名前が付けられます）。 「prefix」に入力の文字列を渡します。 「completion」がsuggesterのタイプの指定です。今回はCompletion Suggesterなので「completion」を指定します。その中に「field」でcompletionに利用するフィールド名を指定します。先ほどのスキーマでcompletionタイプを指定したフィールドです。今回は「suggest_ja」になります。 「_source」は結果を見やすくするために、ヒットしたデータの一部だけ取得するオプションです。 すると、次のような結果が返ってきます。\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;wagah\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 5, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;『吾輩は猫である』中篇自序\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;002671\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;『吾輩は猫である』中篇自序\u0026#34;, \u0026#34;夏目 漱石\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;わが俳諧修業\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;003771\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;わが俳諧修業\u0026#34;, \u0026#34;芥川 竜之介\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;わが母をおもう\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;003997\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;わが母をおもう\u0026#34;, \u0026#34;宮本 百合子\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;わが母を語る\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;049723\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;わが母を語る\u0026#34;, \u0026#34;上村 松園\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;吾輩は猫である\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;000789\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;吾輩は猫である\u0026#34;, \u0026#34;夏目 漱石\u0026#34; ] } } ] } ] } } 「suggest」の「title-suggest」がCompletion Suggesterのレスポンスになります。 最初の「text」は入力の「prefix」の値です。「offset」、「length」もこの文字に関する情報なので特に気にしなくてもいいかと。 「options」がサジェストされた内容になります。それぞれの「text」がサジェストされた文字列になります。「suggest_ja」には著作と著者名を入れましたが、今回は著作が「text」に帰ってきていることがわかります。 次に著者名でもやってみましょう。 「太宰」という入力が来たものとしてリクエストを投げます。\nGET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;太宰\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } } } レスポンスは次のようになります。\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;太宰\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 2, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;000236\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;ア、秋\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;001572\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;I can speak\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;001578\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;愛と美について\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;046597\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;青森\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;004357\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;青森\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } } ] } ] } } 先ほどとは異なり、「options」の中の個々の「text」はすべて「太宰 治」になってしまいました。 登録したデータは著作の一覧ですが、「suggest_ja」には著作と著者名を入れたためです。 これでは、実際に検索窓に実装したときに同じものが並んでしまいます。 こんな時のためのオプション「skip_duplicates」が用意されています。 先ほどのリクエストに「\u0026ldquo;skip_duplicates\u0026rdquo;: true」を追加します。\nGET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;太宰\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34;, \u0026#34;skip_duplicates\u0026#34;: true } } }, \u0026#34;_source\u0026#34;: [\u0026#34;suggest_ja\u0026#34;] } するとレスポンスは次のように変化します。\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;太宰\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 2, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;000236\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;ア、秋\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰治との一日\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;042582\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;太宰治との一日\u0026#34;, \u0026#34;豊島 与志雄\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰治情死考\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;043137\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;太宰治情死考\u0026#34;, \u0026#34;坂口 安吾\u0026#34; ] } } ] } ] } } 「options」は3つに減り、重複していないことがわかります。 「text」が同じ場合は最初に出てきたものを返すようです（注意：結果から観測しているだけで、実装はまだ見ていません）。 （なお、今回は説明を省きますが、入力データでスコアを指定することも可能になっています）。 そのほかにもCompletion Suggesterにはいくつか仕組みが用意されているのですが、それはまた今度にでも。\nまとめ ということで、Luceneコミッターの打田さんに感謝です。 便利な仕組みが簡単に使えるようになるのはとてもありがたいですね。\nまずは簡単にどういうものかとどうやって使うのかを記事にしてみました。 中の動きや、注意点、これまでとの違いなどは次の記事にしようと思います。 そういえば、公式ドキュメントにはまだ出てきてないな、それを書こうと思ってついでに動かしてみたんだけど、追加するのはまた後日かな。。。\n参考資料 青空文庫 - 公開中　作家リスト：全て ［LUCENE-10102］ Add JapaneseCompletionFilter for Input Method-aware auto-completion - ASF JIRA Expose Japanese completion filter to kuromoji analysis plugin by mocobeta · Pull Request #81858 · elastic/elasticsearch Suggesters | Elasticsearch Guide ［8.3］ | Elastic ","date":1660028402,"dir":"post/2022/","id":"6639ec6f88c4976f8ca20fa840f169e3","lang":"ja","lastmod":1660028402,"permalink":"https://blog.johtani.info/blog/2022/08/09/japanese-auto-completion/","publishdate":"2022-08-09T16:00:02+09:00","summary":"風のうわさで、日本語用のオートコンプリートのためのTokenFilterとAnalyzerがLuceneに取り込まれたと聞きました（LUCE","tags":["lucene","elasticsearch"],"title":"日本語用オートコンプリートのためのAnalyzer"},{"contents":"Hugoを0.84から0.92にアップデートをする際に、これまでのブログ記事やレイアウトファイルを修正したので個人的にメモを残しておきます。\nなんでアップデート？ うっかり魔がさして、メインのWSL2のUbuntuを20.04から22.04にアップグレードしました。。。 新規に22.04を落としてきて移行ではなく。 皆さんはまねしないほうがいいですよ！ アップデートした後にGitの環境がおかしくなったりと大変でした。 WSL2のUbuntuではHugoでブログのビルド、いろんな確認のためのElasticsearchの起動、個人的なプログラムとかを書く環境として利用しています。\nで、Ubuntuを上げたところ無事（？）Hugoもアップデートされたわけです。 最初はGitでfetchが出来なくなって修正していましたが、そのほかの動作確認を行なう段階でHugoでブログがビルドできなくなっていることが判明しました。\nバージョンアップに伴う修正 hugoコマンドを実行すると、いくつかのERRORとWARNが出力されました。 次のようなものです。\nhugo v0.92.2+extended linux/amd64 BuildDate=2022-02-23T16:47:50Z VendorInfo=ubuntu:0.92.2-1 ERROR 2022/08/05 13:22:32 Page.URL is deprecated and will be removed in Hugo 0.93.0. Use .Permalink or .RelPermalink. If what you want is the front matter URL value, use .Params.url WARN 2022/08/05 13:22:32 The \u0026#34;tweet\u0026#34; shortcode will soon require two named parameters: user and id. See \u0026#34;/home/johtani/blog_generator/content/post/2020/2020-12-04-build_corne_choc.md:46:1\u0026#34; ... ERROR 2022/08/05 13:22:33 Failed to get JSON resource \u0026#34;https://publish.twitter.com/oembed?dnt=fa... If you feel that this should not be logged as an ERROR, you can ignore it by adding this to your site config: ignoreErrors = [\u0026#34;error-remote-getjson\u0026#34;] ERROR 2022/08/05 18:44:11 Page.UniqueID is deprecated and will be removed in Hugo 0.93.0. Use .File.UniqueID ERROR 2022/08/05 18:44:11 Page.Dir is deprecated and will be removed in Hugo 0.93.0. Use .File.Dir Page.URLなどがdeprecatedに 最初と最後2行のERRORがこちらになります。 どうやら、Pageオブジェクトの変数に変更があったようです（まだdeprecatedであり、存在はしていそう？）。 レイアウト（テンプレート）ファイルで「Previous Post」や「Next Post」といったリンクを作ったり、 Algoliaに登録するためのJSONファイルを生成するところでURL文字列を取得するために参照していました。\nログ出力でどのように変更すればよいのか？という記載があるので便利ですね。 ただ、どのファイルにこの記述があるのかはログに出てなかったので少しだけ苦労しました。\n実際には「UniqueID」という文字列でディレクトリ内を検索してあたりを付けた感じです。 利用させていただいているテーマ（Clean White）がすでにアップデートに対応されていたのでそちらが参考になりました。\nいくつか、テーマをもとに修正したテンプレートがlayoutsディレクトリにあったので、それらを修正した形です（参考のリンクはテーマのファイルになります）。\n.URLを.Permalinkに変更（参考：single.html） .UniqueIDを.File.UniqueIDに変更（参考：list.algolia.json） tweetのshortcodeの引数が増えた これまでは以下のようにIDだけで良かったのですが、userとidという2つの引数が必須になるという変更が入ったようです。\n変更前：\n{{ \u0026lt;tweet 1449214872143609860\u0026gt; }} 変更後：\n{{ \u0026lt;tweet user=\u0026#34;johtani\u0026#34; id=\u0026#34;1449214872143609860\u0026#34;\u0026gt; }} WARNにはファイル名、行番号が出力されていたので、1つずつ修正していきました。 結構な量があったので、地味に大変でした、 公開しているブログを見ながら、該当するツイートを見つけてはuserを指定していく部分が特に。 自分のツイート以外もブログに貼っていたので画一的には対処できなくて。。。\nなにかプログラムで機械的に対応ができたかもなぁ。\n鍵付きツイートによるエラー tweetのshortcode対応を行なった後でもビルドがエラーになっており、次のようなエラーが消えないままでした（エラーの一部は省略しています）。 （幸いにも）1つのツイートだけ、ブログ記事を書いた後で鍵付きになってしまった方のツイートがあったようで、ツイート用のJSONが取得できなくてエラーになっていました。\nERROR 2022/08/05 13:22:33 Failed to get JSON resource \u0026#34;https://publish.twitter.com/oembed?dnt=fa... If you feel that this should not be logged as an ERROR, you can ignore it by adding this to your site config: ignoreErrors = [\u0026#34;error-remote-getjson\u0026#34;] こちらもログに対処方法が出ています。 config.tomlにignoreErrors = [\u0026quot;error-remote-getjson\u0026quot;]を追加すれば、エラーが出力されなくなりビルドも成功するようになります。 ただ、tweet以外でもエラーが出る可能性がありそうで、その場合に、ブログに書いたつもりが一部が出力されないまま公開されそうな気がします。 なので、今回はconfig.tomlに該当の設定を追加するのではなく、ブログ記事から該当のツイートを消す対応をしました。 幸いにも、ツイートを消してもブログ記事自体には影響がありませんでした。\n.hugo_build.lockファイルが生成される これは、エラーではないのですがgit addしようとした際に、ファイルが増えていたのでどういったファイルなのかを調べました。 0.89.0から追加されたロックファイルのようです（参考：0.89.0のリリースノート）。 こちらは特に保管する必要もなさそうなので.gitignoreに追加して対処しました。\nまとめ ということで、気軽にUbuntuをアップグレードしないほうがいいですね。。。 期せずしてHugoのアップグレードができたのは良かったかもなｗ\n参考 【WSL2】Ubuntu 20.04.4 LTS を 22.04 LTS へアップグレードした ","date":1659689954,"dir":"post/2022/","id":"167a7c9d579ce6f2cebf64a6f6329ecb","lang":"ja","lastmod":1659689954,"permalink":"https://blog.johtani.info/blog/2022/08/05/upgrade-hugo-accidentally/","publishdate":"2022-08-05T17:59:14+09:00","summary":"Hugoを0.84から0.92にアップデートをする際に、これまでのブログ記事やレイアウトファイルを修正したので個人的にメモを残しておきます。","tags":["hugo"],"title":"Hugoをアップデートした"},{"contents":"今回はQuerqyのElasticsearchのプラグインがどんなつくりになっているか？をちょっとだけ調べてみました。 SolrでもElasticsearchでも使えるという形なので、どんなつくりになっているのかな？と思ったのが発端です。\nGitHubのリポジトリ GitHubにリポジトリが公開されています。 2つのリポジトリに分かれています。\nEs向けのプラグイン コアのライブラリ どちらもJavaのライブラリで、ビルドシステムとしてはMavenを利用しています。 コアのライブラリのリポジトリにはさらに、以下の2つが存在しています。\nlucene向けライブラリ（Solr向けのモジュールもこちらに含まれる） コアライブラリ pom.xmlを読んだところ、次のような依存関係になっています（それ以外にも使ってるライブラリはあるけど）。\nEsプラグイン -\u0026gt; Lucene向けライブラリ -\u0026gt; コアライブラリ Esプラグイン Es向けのエンドポイントの実装、Esのクエリの組み立てを行なっています。 Rewriterの実装については、Lucene向けライブラリ、コアライブラリを利用する形になります。\nquerqy用のQueryBuilderを実装しており、EsがクエリをパースするタイミングでRewriterなどを呼び出してクエリの書き換えを行う仕組みです。 なお、Es向けのクエリの組み立てと書きましたが、ほとんどLuceneのクエリの組み立てになっています（そりゃそうだ）。 実際にquerqyのクエリ組み立て処理を行っているのは、Lucene向けライブラリのQueryParsingControllerになります。 いくつかのRewriterは、生のEsクエリをルールなどとして登録することができるようになっています。 これらのクエリのパースをEs側にやらせる処理の部分もこちらで定義されている感じです。\nそのほかに、ドキュメントには記載がないエンドポイントが2つ用意されていました。 インデックスに登録してあるRewriterの設定を各ノードでキャッシュする仕組みがあって、そのキャッシュの操作（クリア、リロード）用みたいです。 これらは、Rewriterの追加、削除のアクションの内部で呼び出されているので、ユーザー側で呼び出す必要はなさそうです。\nLucene向けライブラリ Luceneに関連する処理がまとめられています。 Es内部ではLuceneを使って検索処理が行なわれるため、Luceneのクエリを組み立てる必要があります。 querqyとしてLuceneのクエリを組み立てるときに必要なクラスがこのライブラリに含まれています。\nまた、Word Break Rewriterの実装はコアライブラリではなくこちらのライブラリに実装されています。 これは、Luceneのタームディクショナリを活用したRewriterになっているため、Lucene必須となっているからのようです。 （まだちゃんと実装を見ていないので、どんな活用の仕方をしているのかまではわかっていませんが。。。）\nコアライブラリ Rewriterの設定のパース処理、クエリのリライト処理の実装がまとめられています。 querqyのクエリが、Rewriterの処理に基づいて、querqyとして定義されたクエリのモデルに一旦変換される作りになっています。 Lucene向けライブラリやEs向けプラグインはこの内部のクエリモデルになったものをもとに、Lucene向けのクエリに書き換えていくというながれになっています。\nまとめ ざっくりですが、どんな構成なのかを見てみました。 Esのプラグインとなっているのですが、プラグインではなく、外部に出すことってできるのかな？と思いつつ、なんとなくソースを読んでみました。 パターンとしては、Lucene向けのクエリからEs向けのクエリを組み立てるとかの無駄な努力が必要になる気もするけど。。。 Luceneを使っていない検索エンジンに対しては、コアライブラリをもとに、それぞれの検索エンジンむけのクエリを組み立てる仕組みを作る形になると思います。 その際、Rewriterの設定を保持する仕組み、querqyが置き換えたクエリのマッピングができるか？といった点を考える必要がありそうです。 デバッグとかするときに、EsのクエリDSLのJSONとして見れるといいなぁと思ってたけど、そんなことできるかなぁ？\n","date":1658300650,"dir":"post/2022/","id":"3384ea6bb47d70f8ca94b4510813f36a","lang":"ja","lastmod":1658300650,"permalink":"https://blog.johtani.info/blog/2022/07/20/querqy-architecture/","publishdate":"2022-07-20T16:04:10+09:00","summary":"今回はQuerqyのElasticsearchのプラグインがどんなつくりになっているか？をちょっとだけ調べてみました。 SolrでもElast","tags":["elasticsearch"],"title":"Querqyの調査（その2：アーキテクチャ）"},{"contents":"Querqyというクエリのリライト用のプラグインがあるのでどんなものかを調べてみました。とりあえずは概要をドキュメントから追いかけてみた感じです。対応しているのはSolrとElasticsearch（以降、Es）になります。手元にはEsの環境があるのでそちらで試してみました。\nなにもの？ EsやSolrのプラグインで、ルールやパラメータを利用して、クエリの書き換えをEsやSolr側で行えるプラグインです。 なお、本記事ではEsのプラグインを説明します。 今回はドキュメントを読みながらメモを取った感じなので、詳細については公式ドキュメントを見ていただくのが良いかと。 手元では動作させてみましたが、今回の記事ではざっとメモを取っただけになります。\nインストール Esのpluginコマンドでインストール可能ですが、Mavenにアップロードされているバージョンは限定的なので、必要に応じて自分でビルドする必要があります。 対応しているかは、公式ドキュメントのInstallationのプルダウンが参考になります。\nどうやって使うの？ Query DSLにquerqyというクエリが追加されるので、あとはドキュメントをもとにクエリを組み立てるクエリを書いていきます。 すると、プラグインが指定されたルールに従い、EsのQueryに書き換え、実際の検索が実行して結果が返ってきます。 普通にmatchなどの既存のQueryと同レベルのものになるので、既存のEsのクエリと組み合わせた使い方もできるようです。\nサンプルとして紹介されている短めのクエリ（このクエリではルールによるクエリの書き換えはない）。\nGET ecommerce/_search { \u0026#34;query\u0026#34;: { \u0026#34;querqy\u0026#34;: { \u0026#34;matching_query\u0026#34;: { \u0026#34;query\u0026#34;: \u0026#34;notebook\u0026#34; }, \u0026#34;query_fields\u0026#34;: [ \u0026#34;title^3.0\u0026#34;, \u0026#34;brand^2.1\u0026#34;, \u0026#34;short_description\u0026#34;] } } } また、書き換え（Rewriter）の設定をElasticsearchに対して保存できるエンドポイント_querqy/rewriterが用意されています。\nSynonymの書き換えを行なうサンプル（後述するCommon Rules Rewriterの設定）。\nPUT /_querqy/rewriter/common_rules { \u0026#34;class\u0026#34;: \u0026#34;querqy.elasticsearch.rewriter.SimpleCommonRulesRewriterFactory\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;rules\u0026#34; : \u0026#34;notebook =\u0026gt;\\nSYNONYM: laptop\u0026#34; } } どんな書き換えができるの？ 用意されているRewriterは2022年7月時点では次のようなものになります（がんばれば、Javaで実装すれば自作もできそう）。\nCommon Rules Rewriter Replace Rewriter Number Unit Rewriter Word Break Rewriter また、複数のRewriterをチェインして使うこともできる。記述した順番で適用されます。 それぞれのRewriterについて簡単にメモを。\nCommon Rules Rewriter シノニム、結果のブースト、フィルター、結果に対して追加情報を付与したりできます。\nrulesにルールを記載していきます。 以下のようなフォーマットになっています。 クエリが入力に合致したら、ルールが適用される形です。プロパティは後述しますが、ルールの適用する順序などをハンドリングするために使用します。\n入力 =\u0026gt; ルール ルール @プロパティ @プロパティ 入力部分に関する書式 ルールの左辺に該当する部分で、クエリに入力された文字列がマッチするかどうかで、右辺のルールを適用するかがきまります。\n入力の一致の条件は次のような感じです。 完全一致、前方一致、後方一致の使い分けが可能。ダブルクォート\u0026quot;で制御 デフォルトでは、大文字小文字の区別なし（後述するオプションで変更可能） 単語の末尾にワイルドカード*で1文字以上にマッチ。入力の最後にだけ利用可能 書き換えの命令（ルール） 右辺に利用できる命令で、次のようなものがあります。\nSYNONYM 同義語展開するための命令です。Synonym Token Filterとの違いは、複数のルールを同時に適用できます。 フィールドに依存しない設定なのでメンテナンスが楽になるとのこと。 ただし、双方向の設定はないため、例えば\u0026quot;personal computer\u0026quot;と\u0026quot;pc\u0026quot;の場合、2つの設定を個別に定義する必要があります。 また、ステミングなどには未対応なので、\u0026ldquo;personal computers\u0026quot;も対応する場合はこれも追加する必要があります。 類義語ごとに重みを変えることが可能になっています。同列ではなく、同義語のスコアを下げるなどで、リコールを増加させつつ、入力語のスコアを上位にすると行ったことが可能です。\nUP/DOWN 入力文字列がマッチした場合に、追加のクエリを正か負のブーストをしつつ追加できます。 例えば、「iphone」と検索された場合に、「apple」もクエリとして追加しつつスコアをブーストし、「case」のクエリをスコアを下げるように追加できます。 これにより、アクセサリーではなく本体が検索結果の上位に出てくるような仕組みを提供できます。\nFILTER UP/DOWNではクエリとして追加されていたが、こちらはフィルターとして追加されます（＝スコアで調整ではなく、結果から除外される）。\nDELETE クエリからキーワードを削除できます。 単語自体をそのまま削除することも、入力された単語に合わせて他の単語を削除することもできます。\nDECORATE 2022年7月時点でEsでは利用不可で、Solrのみで利用可能です（なので読み飛ばしました）。\nプロパティ 各ルールの設定にタグをつけられるような機能です。 このプロパティを利用して、ルールのソートやフィルタリングなどが可能になります。 複数のルールにクエリがマッチした場合に、優先度が最高のものだけを適用したり、プロパティに特定の値を持っているものだけを採用したりできます。 なお、プロパティは命令のあとに記述する必要があります（パーサーの関係かな？）。\nReplace Rewriter クエリタームの置き換え用のRewriterです。クエリの正規化処理として、他のRewriterの前処理に利用したりできます。 サンプルではタイポの修正などに利用したり、不要な語の除去などがあげてありました。\nWord Break Rewriter クエリトークンを分解・結合します。 たとえばドイツ語は、複合語と呼ばれる個別の意味の単語を結合した1つの単語を持っているため、個別の意味に分解して検索すると便利なことがあります。 そういった単語を辞書を基にして分割できるようにする機能です。 辞書とは実際のインデックスのタームディクショナリのことと思われます（要調査。どのインデックスのフィールドを指し示すのかなど、設定とドキュメントではよくわからない）。 なお、利用可能な形態素解析を基にした実装はドイツ語のみとなっており、また、分解の時には形態素解析を考慮しますが結合時には考慮しません。\nNumber-Unit Rewriter クエリの数値と単位を判別し、対象となるフィールドにマッチさせます。範囲での一致や完全一致やブーストが可能です。 単位をもとにして、特定のフィールドに対する数値のクエリに書き換えることができます。\nShingle Rewriter Solrのみで利用可能なので読み飛ばしました。\nルールはどこに保存されるの？ .querqyというインデックスが内部で作成され、そこに保存されます（公式ドキュメントより）。 （ちなみに、Mappingはこんな感じみたいです）。 現状、プラグインでは設定したRewriterの取得ができないようなので、自分で登録した設定がどんなものかは、このインデックスを検索する必要がありそうです。\n気になった点・改善点？ 気になった点があったので。\nRewriterのエンドポイントは、登録・更新・削除のみ対応しており、登録したものの確認は直接インデックスを見に行くしかなさそうです（Issueは作られてた）。 [要検証]書き換えられたクエリがどんなものか？は残念ながら確認できなそうで、_validate/queryで最終的なLuceneレベルのクエリで確認するしかなさそう？ スキーマ側で定義したものと、Querqyで定義したものの兼ね合いがどういう形になるのか？などを気にする必要があるのが注意点かも。組み合わせたときの副作用などがどんなことになりそうか？が予測がつきにくそう。 Rewriterの定義自体のテストはどうしたものか？ まとめ とりあえず、ざっとドキュメントを見ながらメモを取った感じです。 設定などの記述が独自のものなので、そこに慣れていく必要がありそうです（特にルールの改行の部分とか）。 次は実際にどんな感じで使えそうか、既存の仕組みとの違いは？みたいなところをもう少し見ていきたいとおもいます。\n参考文献 querqy/querqy： Query preprocessor for Java-based search engines (Querqy Core and Solr implementation) Getting started with Querqy — querqy.org documentation ","date":1658285563,"dir":"post/2022/","id":"779e444b4bc720a9eed97f19c41e8773","lang":"ja","lastmod":1658285563,"permalink":"https://blog.johtani.info/blog/2022/07/20/intro-querqy/","publishdate":"2022-07-20T11:52:43+09:00","summary":"Querqyというクエリのリライト用のプラグインがあるのでどんなものかを調べてみました。とりあえずは概要をドキュメントから追いかけてみた感じ","tags":["elasticsearch"],"title":"Querqyの調査（その１）"},{"contents":"今年もBerlin Buzzwordsにオンライン出張してました。 今年はハイブリッドな開催だったようで、現地で再開している人もいるようでした。 ブースもあったみたいです。ちなみに、現地で参加する人はマスク必須のようでした（Health \u0026amp; Safetyというページが用意されていました）。 昨年オンラインだったMICESは現地のみでの開催みたいで見ることはできなかったです（録画公開されないかなぁ）。\nさて、いくつか見たセッションで面白かったものがあったので簡単にメモを。 すでにセッションのビデオがYouTubeで公開されているので、興味のある方は見てみてください。\n面白かったセッション The future of Lucene\u0026rsquo;s MMapDirectory: Why use it and what\u0026rsquo;s coming with Java 19 and later? セッションページ： The future of Lucene\u0026rsquo;s MMapDirectory： Why use it and what\u0026rsquo;s coming with Java 19 and later? ：： Berlin Buzzwords 2022 動画：Uwe Schindler – The future of Lucene\u0026rsquo;s MMapDirectory： Why use it \u0026amp; what\u0026rsquo;s coming with Java19 \u0026amp; later - YouTube 毎年恒例になってる気も？ 前半は昨年も話をした内容で、後半はJava 19がリリースされたら、Previewという形でフラグを立てて使えるようになるようです。 使えるようにするから、テストしてみて！という感じで終わっていますｗ\nScaling an online search engine to thousands of physical stores セッションページ：Scaling an online search engine to thousands of physical stores ：： Berlin Buzzwords 2022 ：： pretalx 動画：Aline Paponaud – Scaling an online search engine to thousands of physical stores - YouTube 数千の実店舗の商品をオンラインで検索できるようにしつつ、オンラインのマーケットプレイスのような検索も一緒にできるようにしたというお話でした。 インデックスの構成をどう工夫したのか？とかどういうクラスター構成にして、どんなことをモニタリングしてるよ？というお話です。 実際の店舗がどんなものかなどは出てこなかったので、少しイメージは沸きにくかったのですが、どんなことを考えながらインデックスの構成とか考慮したよという話はおもしろかったです。 実際に検索したときに、実店舗のデータがどんな感じで結果として表示されたりするのか？といった点はわからなかったので、そのあたりの話をもうちょっと聞いてみたかったなぁ。\nOffline Ranking Validation - Predicting A/B Test Results セッションページ：Offline Ranking Validation - Predicting A/B Test Results ：： Berlin Buzzwords 2022 ：： pretalx 動画：Andrea Schütt \u0026amp; Yunus Lutz – Offline Ranking Validation - Predicting A/B Test Results - YouTube otto.deというECサイトでのランキングをどうやって改善していくか？という話。 現在はマニュアルなチューニングをコンテキストごとにやっているけど、リクエスト量とかデータとかが増えてきてて、このままマニュアルで改善していくのも大変なので、 モデルベースのランキングを開発できないか？というのをはじめていますよと。 そのために、これまでのデータから、A/Bテストの結果を予測できるモデルが作れないか？というのをやっていますという話。 いくつかわからない単語も出てきたので、誰か詳しい人教えて！\nAI-powered Semantic Search; A story of broken promises? セッションページ：AI-powered Semantic Search; A story of broken promises? ：： Berlin Buzzwords 2022 ：： pretalx 動画：Jo Kristian Bergum – AI-powered Semantic Search; A story of broken promises? - YouTube Vespaの開発にかかわってる方の、Semantic Searchに関する話。 Semantic Searchが流行り始めていて、どうやればできるのか？という話が出てきています。 けど、どういうものでどういう点に気を付けたほうがいい？という話でした。 LtRってこんなもの、そのあとに出てきたLLM（Large Language Model）でどうやって検索の改善に使えるの？というのが分かりやすく説明されていました。 それらの説明の後、BEIRという論文を紹介しつつ、LLMを使うときの注意点の話がありました。\nBERTとかをちょっと勉強してたのもあり、なんとなくそうだよなぁと思っていた結論と同じ結論が出てきたので面白いと感じました。 BEIRの論文は時間を見つけて読んでみないとな。\nHybrid search \u0026gt; sum of its parts? セッションページ： Hybrid search \u0026gt; sum of its parts? ：： Berlin Buzzwords 2022 ：： pretalx 動画：Lester Solbakken – Hybrid search： Greater than the sum of its parts? - YouTube こちらもVespaの人の話。 先ほどのSemantic Searchの話では、Semantic Searchがどんなものか？という話でした。 が、それだけで検索ができるわけでもないので、キーワードサーチとSemantic Searchの両方をうまく活用するには？というのがこのセッションでした。 最終的にはVespaを使うとうまくハイブリッドできるよという話ですが、考え方は参考になるかなと。 Vespaも触ってみたいなぁ。\nThe life of a search engine administrator セッションページ：The life of a search engine administrator ：： Berlin Buzzwords 2022 ：： pretalx 動画：Lucian Precup \u0026amp; Vincent Bréhin – The life of a search engine administrator - YouTube 検索システムの管理者ってどんなことやるの？それにはどんなことができるツールがあるといいの？という話です。 まぁ、ツールについてはこの会社の人たちのツールの宣伝なのですが、検索システムを作って育てていくのにどんなことを考えたりするのか？という参考になるかなぁと。\nShould we stop using distance in our location-based data recommendation models? セッションページ：Should we stop using distance in our location-based data recommendation models? ：： Berlin Buzzwords 2022 ：： pretalx 動画：Charlie Davies – Should we stop using distance in our location-based data recommendation models? - YouTube TravelTimeという会社を立ち上げた人の話。 位置に関する情報って重要だし、検索するときに利用しますよね？例えば、ホテル決めたりとか、仕事探したりするときに。 ということで、位置情報を検索エンジンで利用する方法（Bounding Box、ポリゴン、距離）をまず紹介して、どんなユースケースで使えるかという話があります。 また、それとは別に検索速度（いかに検索を速く返すか）も重要だという話があります（ウォルマートはページロード時間を1秒早くしてコンバージョンが2%あがったとか）。 で、実際に検索結果に距離とかでるけど、実際に知りたいのはどのくらいの時間で行けるのか？という話だったりしませんか？と。 公共交通機関を使ったりする場合に、実際に45分で移動できる距離というのは半径5マイルとかできまるものではないのに、単純に位置情報を利用した距離だけでソートしていいの？という問いかけから、 その辺を考慮した検索ができるAPIを開発しているよ、検索速度もはやいよというお話でした。 残念ながら具体的にどうやって作っているのか？というのはなかったですが、観点がおもしろかったです。\nWord2Vec model to generate synonyms on the fly in Apache Lucene セッションページ：Word2Vec model to generate synonyms on the fly in Apache Lucene ：： Berlin Buzzwords 2022 ：： pretalx 動画：Daniele Antuzi \u0026amp; Ilaria Petreti – Word2Vec model to generate synonyms on the fly in Apache Lucene - YouTube Word2Vecのモデルを使った、Apache LuceneのSynonym Filterを開発中だよという話 DeepLearning4Jを使ってみたが、遅くて使えなかったんだけど、最近Luceneに入ったkNNを使うことでそれなりの速度で使えそうなものができるかもよ？って感じでした。 モデル学習用のツールも作ってて、イタリア語のWikipediaで学習したものでちょっと動かしたらそれっぽい感じになってるという話でした。 まだ途中でいくつかやりたいことがあるという話で、実用はまだ先のようでした。例えば、1単語のSynonymにしか対応してないとか、モデルをインメモリでしか動かせないとか。\nQAでも出たのですが、Word2Vecだと対義語も類似していると判定されてしまうと思うので、その辺がどうなっているのかなぁ？という疑問があります。 ルールベースの類義語ではないので、調整するのはどうやるのかなぁ、学習用のコーパスをいい感じにするとかなのかな？とか、気になるところです。\nNrtSearch: Yelp’s fast, scalable, and cost-effective open source search engine セッションページ：NrtSearch： Yelp’s fast, scalable, and cost-effective open source search engine ：： Berlin Buzzwords 2022 ：： pretalx 動画：Umesh Dangat – NrtSearch： Yelp’s fast, scalable, and cost-effective open source search engine - YouTube YelpがLuceneベースで開発をしているNrtSearchというOSSの話です。 Elasticsearchを使っていたんだけど、どういった点が問題点になってどういうモチベーションでNrtSearchを開発したのか？を説明しています。 アーキテクチャがどんなもので、実際に動かしてみてどんな利点があって、どんな点が問題として出てきているか、将来どんなことをやろうとしているかがわかります。 QAでもいろんな質問が出ていて面白いです。\nまとめ ということで、簡単でしたがセッションの感想でした。 Neural/Semantic Searchというのがセッションのタイトルなどに入っているのが多くなってるなぁという感想です（ちょっとやってみたい気はしてるんだよなぁ）。 すでにYouTubeに動画が公開されているので興味があるセッションを見つけてみてください。 Berlin Buzzwordsの次の日に開催されたMICESも観てみたかったですが、オンラインでも参加できる形式で海外のカンファレンスが開催されるのはとても助かりますね（ヨーロッパだと時差もそれほど大変じゃないし）。 けど、落ち着いたらまたオフラインで参加してみたいなぁ。\n","date":1655283615,"dir":"post/2022/","id":"f56c19442484b3e4f47875b58b3f72b2","lang":"ja","lastmod":1655283615,"permalink":"https://blog.johtani.info/blog/2022/06/15/ttend-berlin-buzzwords-online/","publishdate":"2022-06-15T18:00:15+09:00","summary":"今年もBerlin Buzzwordsにオンライン出張してました。 今年はハイブリッドな開催だったようで、現地で再開している人もいるようでした。","tags":["conference","berlin buzzwords"],"title":"今年もオンラインでBerlin Buzzwordsに参加した"},{"contents":"7.16で正式リリースされましたが、Elasticsearchの新しいJavaのクライアントが出ています。 使ってみたので、ちょっとだけ紹介でもしてみようかな。\nこのクライアントが出るまでは、ElasticsearchのJavaクライアント（REST版）はElasticsearch本体の一部として実装・管理されていました（Elasticsearchのリポジトリにあるclientディレクトリ）。\nHTTP経由でElasticsearchにアクセスするクライアントだったのですが、Elasticsearch本体のリポジトリで管理されていることもあり、Elasticsearch本体で利用されているクラスを使用していました。 このため、クライアントライブラリなのですが、Elasticsearch本体のJarが必要になりサイズが大きくなっていました。 また、JavaのObjectへの詰め替えなどの機能も備えておらず、すこし古臭い感じでもあります。 この辺りを刷新する目的もあり新しいクライアントが公開されたようです。 3月くらいに触った時はまだ、ドキュメントが揃ってなかったのですが利用方法などが増えているので移行も楽になってきているようです。 根本的に作り直されたため、これまでのREST Clientとは使い方が違います。ですので、jarだけの差し替えでこれまで動いていたプログラムを移行ができるわけではないので注意が必要です。\nどの辺が便利？ 順次移行が可能 これまでのRESTクライアントとはパッケージ名もjarも別モノになっています。 ですので、少しずつ新しいJava Clientに切り替えていくことが可能になっています。 根本的に使い方が変わっているので、大きなシステムのクライアントを全部切り替えるのは結構大変かと思います。 ですので、Indexをしている部分だけとか、検索部分だけなどといった部分的な置き換えをしつつ新しいクライアントに慣れていくことができます。\nラムダっぽく書ける 検索のクエリのサンプルを見るとわかりますが、こんな感じでクエリが書けます(公式ドキュメントより抜粋)。\nSearchResponse\u0026lt;Product\u0026gt; response = esClient.search(s -\u0026gt; s .index(\u0026#34;products\u0026#34;) .query(q -\u0026gt; q .match(t -\u0026gt; t .field(\u0026#34;name\u0026#34;) .query(searchText) ) ), Product.class ); また、最後で渡しているProduct.classは、検索結果をどのクラスのインスタンスにして返すかの指定です。 Elasticsearchのレスポンス（JSON）から値をコピーして返してくれるようになっています。 ですので、値を入れ替える処理を書く必要がなくなっています。\nJSON文字列をそのまま使える 触り始めてからリリース（7.17.2より後なら使える）された、JSON文字列からリクエストを作る機能もあります。\nこれまでのREST Clientだと、Elasticsearchへのリクエストを必ずJavaのメソッドで構築する必要がありました。 今回のこの機能を利用すると、JSON文字列（やファイル）からリクエストオブジェクトを作るためのメソッド.withJson()が提供されています。 例えば、スキーマや設定変更用のリクエストのJSONなどは、Kibanaやcurlから試験的に投げたリクエスト（JSON）と同じものを使いたいことが多いです。また、ElasticsearchのAPIは数が多く、ドキュメントを見ながら利用方法を調べてJSONでまず試行錯誤することが多いです。 このwithJsonメソッドを利用することで、動作確認などをしたJSONがそのままソースにも利用できるので、リクエスト変更時の確認なども容易になると思います。\n使ってみて困ったのは？ 便利な面も多いのですが、使っていて少し困ったこともあったのでそれもメモを残しておきます。\nどんなリクエストを投げているかが不明 先ほども書きましたが、Elasticsearchのリクエストを試行錯誤するときは公式ドキュメントを見ながら、Kibanaなどを利用して試すことが多いです。 ですので、自分がやりたいことのJSONは手元にあることが多いです。 ただ、プログラムでクエリを組み立てる必要も出てきます。この時、実際にRESTリクエストとしてどんなJSONを投げているのかを知りたいことがあります（実際、検索クエリ作っててメソッドの使い方がうまくいかなくて四苦八苦してました）。 4月時点では簡単にリクエストで投げているJSONを文字列としてログに出すメソッドなどは用意されていないようでした。 デバッグ用に次のようなメソッドを書いてみました。 Elasticsearchへ投げるRequestのクラス（例：CreateTemplateRequestとか）を引数に渡すことで、JSON文字列に変換できるようになっています（StringWriterに書き出されてる）。 ここのLoggerはサンプルです。writer.toString()で取り出せる文字列がJSON文字列になっているので、ログに出してみるなり、ファイルに落とすなりしてデバッグのお供にしてください。\nimport java.io.StringWriter; import co.elastic.clients.elasticsearch._types.RequestBase; import co.elastic.clients.json.SimpleJsonpMapper; import jakarta.json.stream.JsonGenerator; ... private void printRequestBodyJsonForDebug(RequestBase request) { //for debug Logger.log(\u0026#34;** Debug print start **\u0026#34;); StringWriter writer = new StringWriter(); SimpleJsonpMapper mapper = new SimpleJsonpMapper(); JsonGenerator generator = mapper.jsonProvider().createGenerator(writer); mapper.serialize(request, generator); generator.close(); Logger.log(writer.toString()); Logger.log(\u0026#34;** Debug print finish **\u0026#34;); } プラグインなどで提供されるクエリが書けない LtRプラグインなどは、Elasticsearchの検索クエリを拡張しています。 残念ながら、現時点（2022/06/13）ではカスタムクエリを新しいJavaクライアントで利用しようとした場合、エラーが発生してしまいます（知らないJSONだと判断されてしまいます）。\nGitHubのIssueとして「［roadmap］ Add support for plugin-defined custom components · Issue #252 · elastic/elasticsearch-java」があります。 これに対応されたら、拡張されたクエリも利用できるようになるでしょう。 プラグインなどで拡張されているものを使いたい場合は、残念ながら既存のRESTクライアントを当面は使うことになりそうです。\nまとめ 新しいElasticsearchのJavaクライアントを簡単ですが触ってみて、気になった点を記事にしました。 JavaのObjectに詰め替えてくれる機能など便利になっているので使ってみてください。 ドキュメントもちょっとずつ増えているようで、使い方も分かりやすくなっていました（触った時はレスポンスの扱い方などがJavaDocしか用意されてなかったんです）。 説明が欲しいなぁと思うことがあれば、GitHubにIssueを上げてみるといいかもです。\n参考 公式ドキュメント Java Clientチームの人がカンファレンスで利用したスライド ","date":1655119446,"dir":"post/2022/","id":"5eebdf85fd1726db301194bfeeee4377","lang":"ja","lastmod":1655119446,"permalink":"https://blog.johtani.info/blog/2022/06/13/new-elasticsearch-java-client/","publishdate":"2022-06-13T20:24:06+09:00","summary":"7.16で正式リリースされましたが、Elasticsearchの新しいJavaのクライアントが出ています。 使ってみたので、ちょっとだけ紹介で","tags":["elasticsearch","java"],"title":"Elasticsearchの新しいJavaクライアント"},{"contents":"Azure Cognitive Searchで2月に新しい機能が公開されました。 「Index Alias」（インデックスの別名）です。まだ、パブリックプレビューの段階ですが、ドキュメントなどが公開されていたのでどんな機能かを調べてみました。なお、本ブログの内容は2022/05/18時点での内容となります、ご注意ください。\n公式ドキュメント まずは公式ドキュメントです。1つ目の「インデックスの別名を作成する」の冒頭で別名（エイリアス）がどんなものかを説明しています。\nインデックスの別名を作成する - Azure Cognitive Search | Microsoft Docs エイリアスの作成または更新 (2021-04-30-Preview) - Azure Cognitive Search | Microsoft Docs Alias Operations (2021-04-30-Preview) - Azure Cognitive Search | Microsoft Docs REST APIのドキュメント（2022/05/18現在、日本語のページだと左のメニューが壊れているため、どんなAPIがあるかがわかりにくいため、Alias Operationsのページは英語のリンクになっています）\nインデックスエイリアスってどんなもの？ 文字通り、インデックスにエイリアス（別名）をつけることができるようになります。 Azure Cognitive Searchでは残念ながらインデックスを作成するタイミング以外ではインデックスの名前を変更できません。 このため、インデックスのスキーマ（Analyzerの設定変更など）を変更したい場合、新しいインデックスを作成します。 新しいインデックスの名前はこれまでのものとは別の名前になってしまうため、アプリケーションで指定しているインデックス名も書き換える必要が出てきます。 利用しているアプリが複数ある場合は、すべて変更が必要です。\n今回出てきたエイリアスを利用することで、アプリケーションではエイリアスを指定することで、アプリケーション側の変更なくインデックスを入れ替えることができるようになります。\nエイリアスの操作方法 公式ドキュメントにAPIの一覧や利用方法の記載があるので詳細はそちらをご覧ください。 本ブログでは、いくつか利用するときに気になった点を書き残しておきます。\n作成 aliasesというエンドポイントにエイリアスの名前とインデックス名をPOSTすることで作成できます。 以下のサンプルは公式ドキュメントの例です。\nPOST /aliases?api-version=2021-04-30-preview { \u0026#34;name\u0026#34;: \u0026#34;my-alias\u0026#34;, \u0026#34;indexes\u0026#34;: [\u0026#34;hotel-samples-index\u0026#34;] } ちなみに、インデックスの指定がindexesで配列になっていますが、公式ドキュメントに以下の記述があり、複数の指定はできないです（エラーが返ってきます）。\nindexes 配列に指定できるインデックスの名前は 1 つだけです。\nまた、1つのインデックスに対して複数のエイリアスをつけることは問題ありません。\n確認 エイリアスのリストも取得できます。\nGET /aliases?api-version=2021-04-30-preview 現在どんなエイリアスが、どのインデックスに対して付与されているかがリストで取得できます。 きちんと作成されたかどうかなどの確認にも使えるかと思います（もちろんエイリアス名を指定したGETも可能です）\n検索での利用 検索のREST APIでインデックス名を指定していた部分をエイリアス名に置き換えるだけです。\nPOST /indexes/my-alias/docs/search?api-version=2021-04-30-preview { \u0026#34;search\u0026#34;: \u0026#34;pool spa +airport\u0026#34;, \u0026#34;searchMode\u0026#34;: any, \u0026#34;queryType\u0026#34;: \u0026#34;simple\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;HotelId, HotelName, Category, Description\u0026#34;, \u0026#34;count\u0026#34;: true } 更新 エイリアスの更新（インデックスの入れ替え）は作成と同じリクエストです。 更新が成功すれば204のステータスコードが返ってきます（エイリアス初回作成時は201） なお、ドキュメントには以下のような記述があります。入れ替え時の注意点になるかと（入れ替えのタイミングをきちんと制御したい場合は、少しだけアプリケーションを停止するなどが必要かと思います）。\n別名に対する更新がシステムに反映されるまでに最大 10 秒かかります。以前その別名が対応付けられていたインデックスを削除するのは、10 秒以上待ってからにしてください。\n削除 もちろん削除もできます。\nDELETE /aliases/my-alias エイリアスを利用する場合の注意点 便利なエイリアスですが、エイリアスが使用できない場合もあるので注意が必要です。\nデータ登録のAPIと検索のAPIでのみエイリアス名を利用可能 インデックスの設定変更やAnalyze Text APIではこれまで通りインデックス名を指定します。 また、エイリアス名はインデクサー機能でtargetIndexNameにも指定できません。 エイリアス名がついているインデックスは削除不可 エイリアスがついているインデックスを削除しようとした場合はエラーが出るようになっています。 まずはエイリアスを削除してからインデックスを削除するという手順になります。 まとめ 簡単ですが、インデックスのエイリアスに関しての紹介でした。まだパブリックプレビューなので正式リリース時点では利用方法が変わっている可能性もあります。こちらは注意してください。\n正式公開されればですが、今後Azure Cognitive Searchを使ったアプリを開発する場合はインデックスエイリアスを利用することを基本にするのがいいかもなと思います （ちなみに、Elasticsearchにもインデックスエイリアスの機能がありますが、異なる点が多いので同じものとは思わないほうがよさそうです）。\n","date":1652856857,"dir":"post/2022/","id":"7cc21814165879f72529e91682ece5c6","lang":"ja","lastmod":1652856857,"permalink":"https://blog.johtani.info/blog/2022/05/18/index-alias-in-azure-cognitive-search/","publishdate":"2022-05-18T15:54:17+09:00","summary":"Azure Cognitive Searchで2月に新しい機能が公開されました。 「Index Alias」（インデックスの別名）です。まだ、パブリックプレビューの段階です","tags":["azure search"],"title":"インデックスエイリアス - Azure Cognitive Searchの新機能"},{"contents":"年末までに知り合いと次の論文を読んだので軽くまとめておきます。\nExtreme Multi-label Learning for Semantic Matching in Product Search なんで読んだの？ 前回読んだ理由と一緒ですが、Semantic Searchに絡んだ検索の論文であり、Amazonの製品検索での話も関係していたので読みました。\nどんな論文？ Amazonの製品検索でセマンティックマッチングを利用する方法、レイテンシを低くしつつ再現率を改善できるような仕組みを検討して評価した論文です。 実際には商品検索のマッチングを大規模なマルチラベル問題（Extreme Multi-label Classification：以下ではXMC問題とする）として定義して、その問題を効率よく解く方法について検討評価しています。\n検索には大きく2つのフェーズがあります。マッチング（クエリにヒットした文書の集合を求める）とランキング（マッチングのデータを関連性の高い順序で並べる）です。 前回のMSの論文では、マッチング後のランキングのフェーズで言語モデルを利用した並び替えを行う話でした。 今回の論文ではマッチングに関してセマンティックサーチを有効活用できないか？という論文になります。 転置インデックスベースの（語彙による）検索では、スペルミスや類義語などを検索することが難しいです。 語彙以外のデータ（クリックや購入といったユーザーの行動や製品の意味的表現など）を学習できる埋め込みベースのニューラルモデルを活用して、マッチングを補完する方法を検討しています。 下図のようにあくまで転置インデックスベースの検索の補完として利用するみたいです（論文に掲載されていたアーキテクチャ）。\nXMC問題とは？ セマンティックサーチを行なう場合、埋め込みベースのニューラルモデル（例えばBERTとか）を利用することが多いですが、 クエリトークンを埋め込み空間にベクトル化する部分が推論のボトルネック（レイテンシが高くなる）になることが多いです。 これは、ニューラルネットワークの複雑さに依存します。 低レイテンシになるように、複雑ではないエンコーダーを用いることもありますが今度は性能（精度）が良くなくなります。\nそこで、この論文ではセマンティックマッチングをXMC問題として定義し、これを効率よく解くための手法を提案しています。 ここで、XMCの問題とは、入力（今回はクエリ）に対して、最も関連性の高い複数のラベル（今回は製品）を出力することとなります。 Amazonでの製品なのでほんとに大規模（ラベル＝製品＝1億件）です。\n従来のXMC問題を解くための手法として、疎な線形モデルの手法、パーティションベースの手法、グラフベースの手法などが列挙されています。 疎な線形モデルの手法では、ナイーブなOVR(one-versus-rest)だと出力となるラベルの数に対して線形に推論時間も大きくなるため、今回の用途には適しません。 この論文ではパーティションベースの手法として、推論時間を短くできるツリーベースで疎な線形モデルの手法を評価しています。\nどういう仕組み？ ツリーベースのモデルは次のような感じです。 PECOSのXR-Linearモデルを利用しています。 モデルに関する詳細についてはこちらの論文に詳しく載っているようです（まだ読んでいないです、、、）。\n一番上に入力として与えられるxがクエリ（ベクトル）で一番下の四角が製品にあたるラベル（Y={1,...,l,...L}）です。 これらが与えられたときに最も関連性の高い上位k件のラベル（製品）を出力するモデルを生成します。 モデルのパラメータは、学習データとして(x, y)(ここで、y∈{0, 1}^𝐿、すなわちクエリに製品がマッチするかしないかの二値)を使って調整します。\nこれは、ツリーのそれぞれの階層のノードで、その下の層に関連するデータがあるかどうか？という分類を学習すればよいことになります。 学習データとしては、入力と最下層のラベルにマッチするかどうかというデータです。 これをもとに、ツリーの最下層のデータをもとにひとつ上の層の分類器の学習をすればよいことになります。\n推論は出来上がったツリーベースのモデルに対して、ビームサーチで行ないます。 この時、それぞれの層のノードの分類器では推論の効率化のために枝刈りの閾値を設定しています。 本論文で閾値の違いによる精度とレイテンシの比較も行われています。 また、ビームサーチのビームサイズを変化させた場合の性能についても実験しています。\nどうやって検証した？ 次のようなデータを用いてAWS上にモデル構築、推論のシステムを用意し実験しています。\n10億件以上のポジティブなクエリ-商品ペアのデータセット クエリ：2億4千万、商品：1億 ポジティブなペアとは、クリック数や購入数の集計値が閾値以上。ただし、データセットとしては集計値は利用していない。 トレーニングセット：12か月分の検索ログ 評価用テストセット：1か月分の検索ログ（12％の製品はトレーニングセットには出てこない） というデーセットをもとに上記のモデルを学習しています。 特徴量はクエリテキストと製品のタイトルをもとにTF-IDFをいくつかのパターンで導出したものが使われています。 詳しくは論文の結果に関する表などを見ていただくとして。。。\n結果として、1億件の商品カタログで60.9%のRecall@100を1.25ミリ秒/リクエストという低レイテンシで達成したとなっています。\n気になる点は？ 知り合いと3人で読んでいて次のような気になる点が出てきました。\nツリーの構築をするときに、製品のラベルの並び順（製品のクラスタリング？に他製品が似た場所に来る感じ）が推論の効率の良し悪しに影響するんじゃないの？＝Amazonではないところではうまくいかない？ PECOSの論文読まないといけない？ 製品が増えたときにモデルの組み換えとかどうするの？ コールドスタート問題という形で今後の課題として書かれていたので、今後に期待 転置インデックスでのマッチングの補完として利用しているということだったけど、ランキングはどうしてるんだろう？ 別のランキング用の指標があるのかな？上位k件とした場合にどうやって、決めているのか？ モデル更新のタイミングはどのくらいのスパンなんだろう？ まとめ＆感想 セマンティック検索の処理を分類問題に置き換えてその手法を用いて行い、実際のシステムに適用できそうな速度と精度を出しているのが面白かったです。 セマンティック検索にもいろんな手法があるのだなと（そして、いろいろ勉強しないといけないんだなと。。。）。\n気になる点にも書きましたが、ツリーの作り方になにかコツがあるのか？他の検索結果と組み合わせるときに、どのような基準で上位を選択しているのか？など疑問点も残っています。 個人的には特にどのように既存のシステムにくっつけていくのかというところが気になっています。 論文の続編でその辺の話が出てくるのかなぁ？\nツリーの作り方に関するPECOSの論文を誰か解説してくれると嬉しいかもなぁと思いつつ、とりあえずブログに書き残してみました。参考になるかなぁ。。。\n参考文献 Extreme Multi-label Learning for Semantic Matching in Product Search - ACM Extreme multi-label learning for semantic matching in product search - Amazon Science PECOS： Prediction for Enormous and Correlated Output Spaces 数えきれないほどの分類を行うExtreme Classification - Technical Hedgehog ","date":1641980462,"dir":"post/2022/","id":"0645bdb1cdf88ec74288d503eb71839c","lang":"ja","lastmod":1641980462,"permalink":"https://blog.johtani.info/blog/2022/01/12/reading-xmc-for-semantic-search-in-prod/","publishdate":"2022-01-12T18:41:02+09:00","summary":"年末までに知り合いと次の論文を読んだので軽くまとめておきます。 Extreme Multi-label Learning for Semantic Matching in Product Search なんで読んだの？ 前回読んだ理由と一緒ですが、Semantic","tags":["search","paper"],"title":"Extreme Multi-label Learning for Semantic Matching in Product Searchという論文を読んだ"},{"contents":"今年も振り返りブログです。録画した紅白をオッかけ再生して気になるアーティストだけ見ながら書ています。\n振り返り（2020年に書いた抱負から） まずは去年の抱負を元に書きます。今年もコロナウィルスの影響が年末まで続き、ほとんどで書けなかったです。\nフリーランス継続? ありがたいことに個人事業主として無事1年を終えられました。 夏頃は5社ほどお手伝いをさせていただき、年末時点では3社をお手伝いさせていただいています。\n昨年の振り返りで書いた2社はありがたいことに継続していただいています。\n今年も完全リモートで仕事が終わりました。オミクロン株が来ているし、来年春くらいにはミーティングに出かけられるかなぁ。 相変わらず検索のお手伝いをしています。手伝いをしつつ勉強させていただいている感じです。 ありがたし。\nプログラミング ちょっとペースダウンしています。。。\nextract-kana-java 新しく書いたのはこれくらいかな。 SudachiやNeologdのkuromojiでフリガナを出力して違いを見るというコマンドツールです。 ちょっと比較してみたくなったので書いて公開しました。\nあとは、Sudachiをいろいろと触り始めています。 来年はそのへんをもうちょっと何かできるかなぁ。 コーディングしないとよくないなぁと思っているので、強制的になんかやらないとだ。\n検索の勉強 仕事でやってます。ブッチャー本は昨年買って手を付けてませんが。。。 来年は少しずつやる予定です。 あとは、Azure Cognitive SearchのSemantic Searchを触った関係でSemantic Searchに関する論文を探してちょっとずつ読んでいます。 知り合いと読んでいたAmazonの論文をブログにまとめるのは来年早々に。。。\n検索のポッドキャスト? これはできませんでした。重い腰が上がらない。 公開しないまでも雑談したいなぁ。\n振り返り(今年あったできごと) ここからは今年の出来事を。\n自宅環境 キーボード以外もDIY 検索Slack爆誕 車買い替えた WindowsノートPC買った 今年もずっと自宅で仕事でした。 昨年だいぶそろえていたのでそれほど変更はないですが。\n2月バージョン 切り替えてからずっとWindowsです。Macもブラウズ用に使ってはいますが。 ただ、Windowsといっても、プログラムなどに関する環境はほぼWSL2になっています。コマンドプロンプトは触ってないなぁ。 今年最後に更新された自宅環境は椅子になります。 詳しくは昨日のブログをご覧ください。\nキーボードもDIYしましたが、今年はほかにも少しDIYしました。\n今年のDIYキーボードとコントローラーラック このブログにも書きましたが、来年はキーマップやファーム関連を触っていきたいなと。あとロータリーエンコーダー。。。 BLE化は快適で、3台のPCの切り替えがとっても便利です。\ntakuya_aさんの鶴の一声で検索のSlackが爆誕しました。 検索に関連する情報交換ができる場として楽しませてもらってます。 年末には検索100本ノックの話が立ち上がってきています。 来年も面白い話が聞けそうでワクワクしています。\nあとは、車を買い替えました。初のハイブリッドです。 まだまだ慣れないですが、燃費とかがとても楽しみです。\n結局まだ出かけていませんが、出かけられるようにFMV Zeroを購入しました。 このブログもリビングでFMV Zeroで書いています（まだちゃんとセットアップしていないので、実際にはリモートデスクトップでデスクトップにつないでそこのVSCodeで書いちゃってますが。。。）。 ブログ書いたりコード書ける程度の環境は作らないとな。\n来年の抱負 ということで、来年の抱負です。\nフリーランス継続 プログラミング ブッチャー本ちゃんと読む 読んだ本のブログを書く 今年もありがたいことに仕事を継続していただけて、乗り越えられました。 来年も価値を提供できるように頑張っていきます。\nプログラミングは失速気味のでなにかテーマを見つけないとなあ。\nブッチャー本は読み始めます。必ずｗ\nブログのペースが落ちていたり、本を読むペースが落ちているので、 本を読んで自分のためにもブログを書こうと思います。 書いてないって思ったら叱咤してください。。。\n今年も出かけられませんでしたが、仕事も安定してあり、無事乗り切れました。 人と話をする機会は減っているので雑談したいな、オンラインなどで。 相手をしてやってもいいぞという方はぜひ連絡ください。\nさて、来年（もう年あけちゃったけど）は出かけられるかなぁ。 何はともあれ、今年もよろしくお願いします！\n","date":1640957359,"dir":"post/2021/","id":"104b8ee17a8bf1f7043d236659680493","lang":"ja","lastmod":1640957359,"permalink":"https://blog.johtani.info/blog/2021/12/31/looking-back-2021/","publishdate":"2021-12-31T22:29:19+09:00","summary":"今年も振り返りブログです。録画した紅白をオッかけ再生して気になるアーティストだけ見ながら書ています。 振り返り（2020年に書いた抱負から） ま","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2021）"},{"contents":"2021年もあと少しですが、今年買って良かったものをリストアップしておこうかと思います。 今年買ったといいながら、昨年このネタを書くといいつつ書いてないので、昨年の分も入っているかも？ Amazonのアフィリンクを貼っていますが、急いでないものはAliExpressで購入したりもしています。\n象印のポット Amazon | 象印 電気ケトル 1.0L コーヒードリップ用機能付き ホワイト CK-AX10-WA | 象印マホービン(ZOJIRUSHI) いわゆる電気ケトルというやつです。これが来るまでは鍋で湯を沸かしていました。 水を入れてボタンを押し、湯を沸かしている間に他のことができるのはやはり便利です。 また、コーヒーを入れるためのコーヒードリップモードがあるので、ドリップするためにわざわざ湯を他のものに入れたり、 専用のヤカンを使わなくても簡単にドリップができるのがさらに便利で重宝しています。\nウォータードリップコーヒーサーバー Amazon | iwaki(イワキ) コーヒーサーバー SNOWTOP ウォータードリップ ここ数年、冬以外は水出しコーヒーを飲んでいます。 麦茶のポットのような水出しコーヒー用ポットを使っていたのですが、滴下式のほうがえぐみが少ないというのを見かけてウォータードリップのサーバーに変えてみました。 このひとつ前に水のタンクの部分がプラスチックのものを利用していたのですが、ドリップする部分を壊してしまったので、部品を購入することができるこちらに切り替えました。 朝、仕事をする前に豆を挽いて仕込んでおくと、昼にはコーヒーが落ちています。 夏は入れ終わったポットごと冷蔵庫に入れておくと氷を入れなくてもアイスコーヒーが飲めるので気に入っています。\neufyの掃除機 Amazon | Anker Eufy HomeVac H11（ハンディクリーナー） USB充電 仕事に使っている机でプラモデルを作ったり、DIYキーボードの工作をしたりと細かなごみが出る作業を行ないます。 ちょっとごみを吸いたいだけなのに、掃除機を毎回取りに行くのも面倒なので充電式のクリーナーを買ってみました。 仕組みも簡単だし、USBで充電できるのでおすすめです。アタッチメントを利用してキーボードの掃除なんかもしています。\n電動精密ドライバー Amazon | Wowstick 1F\u0026#43; 69in1 電動精密ドライバー ビット56種セット ケース USB充電式 LEDライト付き [並行輸入品] キースイッチを付け替えたり、工作したりでねじの開け閉めを頻繁に行います。 思ったよりも頻度が高くなってきたので、電動の精密ドライバーを試しに使ってみたらすごく楽ができました。 電池の入れ替えなどでもねじの開け閉めは行なうので、すごく役に立っています。 ビットが56種類もついていますが、プラスとマイナス以外はまだ使ってないかも。。。\n磁石のUSBケーブル Amazon | SUNTAIHO マグネット充電ケーブル DIYキーボード、エネループの充電器、上記のドライバーや掃除機など、USBで充電したり、接続するものが結構あります。 毎回ケーブルを差し替えるのも大変なのですが、@ymotongpooに教えてもらった磁石のUSBケーブルがお気に入りです。 先端部分（USB-C、micro）とケーブル部分が別々になっており、また、ケーブルと先端は磁石でくっつく構造なので、充電したい機器に先端部分を刺しておきます。 充電や接続したいときにケーブルを近づけると磁石でくっついてくれるのでケーブルの抜き差しが必要なくなります。 先端部分だけを個別に購入できたので、色々な機器にあらかじめつけてあります。\nMaker hart Just Mixer 5 Amazon | Maker hart Just Mixer 5 ステレオ5入力音声ミキサー/Bluetoothオーディオ入力対応 3台のPC＋音楽サーバーとしてラズパイを主に利用しており、通知音などを1つのスピーカーから聞きたいので、ミキサーを導入しました。 5つの入力個別に音量調節できるので打ち合わせの時だけ他の音源を小さくしたりなど重宝しています。 ただ、入力が増えるとノイズが乗っている気もしますが。。。\nリストレスト（アームレスト） Amazon | エレコム リストレスト アームレスト 肘起き 扇形 左右で使える2個セット ブラック MOH-EL01BK 扇形のものを分割キーボードの手間においてリストレストとして使っています。 使用例の写真を見ると肘を置いていますが、手のひらをおくのにちょうどいいです。 これまでいくつかパームレストを試してみましたが、凹凸もなく適度な硬さで気に入っています。\nコンテッサセコンダ Amazon | オカムラ オフィスチェア コンテッサ セコンダ 10月に注文してクリスマスに届きました。部品が不足しているようで年内に届かないかもといわれていたのですが。 2003年くらいからアーロンチェアを使っていたのですが、さすがに買い替えるかということで奮発しました。 アーロンチェアは座面がメッシュなのですが、ももが疲れるのもあり、クッション座面のものにしてみました。 冬寒くないのがいいですねｗまだ届いたばかりなので調整しないと。\nKindle paperwhite Amazon | Kindle Paperwhite - 大きくなった6.8インチディスプレイ 防水機能搭載 wifi 8GB 電子書籍リーダー 車の点検などでちょっとした待ち時間があるようなときに新書や小説が読めるようにセールで安くなったタイミングで購入しました。 健康診断で読書がはかどりました。もっと本を読まないとなぁ。\nということで、ここ数年で買って便利なものをまとめてみました。 他にもある気がするけど、とりあえずこの辺で。\n","date":1640784504,"dir":"post/2021/","id":"218e2c36d5945ece02fdc55d6cbcbc38","lang":"ja","lastmod":1640784504,"permalink":"https://blog.johtani.info/blog/2021/12/29/best-buy-2021/","publishdate":"2021-12-29T22:28:24+09:00","summary":"2021年もあと少しですが、今年買って良かったものをリストアップしておこうかと思います。 今年買ったといいながら、昨年このネタを書くといいつつ","tags":["misc"],"title":"2021年かって良かったもの"},{"contents":"Azure Cognitive Searchのスキーマの確認をするときに、Azureのポータルでは次のようにフィールドの一覧として見ることができます。\nただ、実際のインデックス定義はJSON形式でやり取りする形になっています（JSONの例：Create Index | Microsoft Docs）。 上記のスクリーンショットのようにフィールド数が少ない場合はそれほど気にならないのですが、フィールド数が大きくなると一覧で見たくなることがあります。 また、ポータルを自分で確認できない場合にJSONファイルを受け取って確認することもあります。 こういう時は、Excel（CSV）って便利ですよね？\nということで、サクッと確認するときには、次のようなjqコマンドをWSL2上で利用して、CSVに変換して確認しています。\necho \u0026#34;Name\u0026#34;, \u0026#34;Type\u0026#34;, \u0026#34;Searchable\u0026#34;, \u0026#34;Facetable\u0026#34;, \u0026#34;Filterable\u0026#34;, \u0026#34;Retrievable\u0026#34;, \u0026#34;Sortable\u0026#34;, \u0026#34;Analyzer\u0026#34;, \u0026#34;IndexAnalyzer\u0026#34;, \u0026#34;SearchAnalyzer\u0026#34; \u0026gt; index_schema.csv cat index_schema.json | jq -r \u0026#39;.fields[]|[.name, .type, .searchable, .facetable, .filterable, .retrievable, .sortable, .analyzer, .indexAnalyzer, .searchAnalyzer]|@csv\u0026#39; \u0026gt;\u0026gt; index_schema.csv 例えばこんな感じになります（上記のポータルのスクショとは別のスキーマですが。。。）。\nどんなフィールドオプションが利用されているか？などをExcelで開いてフィルターなどを活用してチェックするのには便利かなと。 jqコマンドをもっとうまく使うと、ヘッダ行ももっとスマートに出せるかもしれないんですが。。。\nちなみに、上記のコマンドでは残念ながらEdm.ComplexType（参考： 複合データ型をモデル化する方法 - Azure Cognitive Search | Microsoft Docs）には対応していません。 必要になった時に考えるかな。。。\n","date":1640141671,"dir":"post/2021/","id":"f0fdc140e18514362a4e52376a6fecba","lang":"ja","lastmod":1640141671,"permalink":"https://blog.johtani.info/blog/2021/12/22/azure-search-schema-json2csv/","publishdate":"2021-12-22T11:54:31+09:00","summary":"Azure Cognitive Searchのスキーマの確認をするときに、Azureのポータルでは次のようにフィールドの一覧として見ることができます。 ただ、実際のインデ","tags":["azure search","misc"],"title":"Azure Cognitive SearchのIndex Schema JSONをCSVで見たくなる"},{"contents":"今年もアドベントカレンダーの季節になってしまいました。 今年で2回目となる、pyspa Advent Calendar 2021の投稿です。 昨年に引き続きDIYがらみの投稿です。\nコントローラーラック 3つのコントローラーがあるのですが、結構場所を取ります。 また、それぞれ充電しないといけません。\n充電しつつ、邪魔にならない置き方はできないものか？と思っていたところ次のようなコントローラーラックを見つけました。\nAmazon | 山崎実業(Yamazaki) ゲームコントローラー収納ラック これそのものは場所を取るので購入は見送りましたが、エレクターの棚にワイヤーネットをつけると似たようなものができるのでは？ということで、DIYしてみることにしました。\n材料 材料は以下の通りです。 書いていない材料としてあとは、結束バンドがあります。\nワイヤーネット４４×２９．５ｃｍ オフホワイトＢ２８ | 【公式】DAISO（ダイソー）ネットストア スリム型ネットフック５０ｍｍ ２本入り | 【公式】DAISO（ダイソー）ネットストア クロームメッキワイヤーフック（２連、Ｕ字、２個） | 【公式】DAISO（ダイソー）ネットストア Amazon | マグネット 充電ケーブル SUNTAIHO USBケーブル LEDインジケーター付き Amazon | Anker PowerPort Atom III Slim （PD 充電器 65W 4ポート USB-C） 設置 まずは、2連のワイヤーフックでワイヤーネットをエレクターの棚にぶら下げました。\nそのままでは固定されないので、下のエレクターの棚とワイヤーネットを結束バンドで固定。 これで、コントローラーを置いたり取ったりしてもぐらぐらしません。\n固定したワイヤーネットの表（コントローラーを配置する側）に、ネットフック50mmをコントローラーの数だけ配置しました（上の写真でフックとコントローラーの関係がわかります）。\n前から見るとこのような形です。 裏側に、2連フックを使って、Ankerの充電器を固定し、USBのケーブルをコントローラーの上に来るように配置します（写真ではPS4とPS5のコントローラーの上の部分にぶら下がる形です）。\nコントローラーには磁石の端子をコントローラーに差し込んでおきます。\n磁石のUSBケーブルを利用していることで、コントローラーを取り出すときは少し力を入れて引っ張るだけ、収めるときは、ケーブルに近づけて充電できる状態にした後にフックに載せるだけとなりました。 ケーブルの抜き差しをしなくてもよいのでとても便利。 全体像は次の写真のようになっています。一番上のコントローラーはエネループを利用しているのでケーブルは不要になっています。\n磁石のUSBケーブルをpyspaでとんぷーに教えてもらって思いついたアイデアです。 磁石の端子は色々と使い勝手が良いので、DIYキーボードやテンキー、MX Ergo、Kindleなど色々なところに使っています。\n今年のDIYキーボード キーボードを作ったのは2つですが、改造を色々やってました。 ブログに記載したものはリンクだけにしておきます。\nケーブル自作 自作ケーブルキット – 遊舎工房 ケーブルも自作できるみたいなので作ってみました。 現在はテンキーの配置の問題もあって、メインでは利用はしていませんが工作としては面白かったです。 熱収縮チューブを処理するための道具を持っていなかったので、チューブの固定が甘いのが失敗でした。ドライヤーくらいの熱では足りないので作ろうと思っている方は要注意かと。\nCorne Light v2のBLE+LPME-IO対応 詳細はブログ記事を。Corneはこれ以外に、キースイッチの付け替えも行ないました。ルブしたGateronクリアをハンダでつけなおしました。\nCorne Light v2のBLE+LPME-IO対応 #DIYキーボード Sofle keyboard v2のBLE+LPME-IO対応 詳細はブログ記事を。このブログはSofleで書いています。現在メインに利用しているキーボードです。\nSofle v2を組み立てて、BLE+LPME-IO化してみた #DIYキーボード 10月には電池モジュールを次のものに付け替えました。家で主に使用するのもあり、充電池のほうが使い勝手がよさそうだという判断です。スイッチのON/OFFもしやすくなって満足しています。\n単4電池昇圧モジュール - のぎけす屋 - BOOTH Sofleの電池モジュールをボタン電池から単4電池用に差し替えた。 pic.twitter.com/TUizwr2qmw\n\u0026mdash; Jun Ohtani (@johtani) October 16, 2021 Lunakey Miniの組み立てとBLE+LPME-IO対応 詳細はブログ記事を。Sofleと時々入れ替えて使っています。小指のあたりのずれの大きさ、親指のキーの多さが使い勝手のよいキーボードです。コンパクトなのもあり、こちらは持ち運びにも利用できるかなと考えています。\nLunakey Miniを組み立てて、BLE+LPME-IO化してみた #DIYキーボード Soyuzの組み立て（Numpadキット） Soyuz （黒基板） – 遊舎工房 自宅の作業環境(2021/02)の写真にもありますが、分割したキーボードとは別にテンキーを利用しています。 WindowsのログインでPinコードを入力したり、色々な場面で数字の入力をすることがあるためです。 Soyuzを組み立てる前は素 - Shiro – 遊舎工房を利用していたのですが、これでは「⁺」や「Enter」など、電卓のような利用方法の場合にはキーが足りません。 かゆいところに手が届かないので、きちんとしたNumpadをということでSoyuzを組み立てました。\nShiroよりもだいぶ存在感があります。\nGK21S（Numpad） USB Type C充電器付きの滑らかな交換用キーボードキット (Gk21s/k21),スイッチ,デュアルモードPCB|Keyboards| - AliExpress 最後は独身の日のセールで見つけたNumpadキットです。キットといってもこちらは、基盤からケースまで組み立てが終わっているキットで、キースイッチを差し込んで、キーキャップを付けるだけというものになります。 現在はこれをメインに利用しています。通常のNumpadの上に1列キーが多く、Backspaceなどを割り当てられるのが便利です。 ドライバーソフトも用意されており、キーマップのカスタマイズも可能です（まだそこまでやってないけど）。\nお気に入りキースイッチ Kailh Box Silent ピンク軸 5個 | Kochi Keyboard Input Club Hako スイッチ（10個入り） – 遊舎工房 最後はキースイッチの紹介です。 現時点ではこの2種類を組み合わせるのが私の好みに合っているようです（今のところ）。 Box Silentのピンクをアルファベットのキーに、Input Club HakoのVioletをCtrlやShift、Enterなどのキーに割り当てて使っています（下の写真の左側で、キーキャップをつけている部分がHako Violetになっています）。\nまとめ ということで、pyspa Advent Calendar 2021の8日目の記事でした。 それほど作ったりしてないなと思っていたのですが、記事にしてみると今年も色々とDIYしてたみたいです。 キースイッチやキーキャップも自分の好みが固まってきたので、来年はファームウェアやキーマップ周りをいじっていきたいと思っています。\n","date":1638889200,"dir":"post/2021/","id":"26e44dfd16a2963d4c18e99806c26fd7","lang":"ja","lastmod":1638889200,"permalink":"https://blog.johtani.info/blog/2021/12/08/controller-rack/","publishdate":"2021-12-08T00:00:00+09:00","summary":"今年もアドベントカレンダーの季節になってしまいました。 今年で2回目となる、pyspa Advent Calendar 2021の投稿です。 昨年に引き続きDIYがらみの投稿","tags":["DIYキーボード","misc"],"title":"今年のDIYキーボードとコントローラーラック"},{"contents":"Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだので軽くメモを残しておきます。論文自体はリンクから参照してください。\n読んだ理由 Azure Cognitive SearchでSemantic Searchが利用可能になったこともあり、「Semantic Search」に関するMSのリサーチチームが発表している論文をたまたま見つけたためです。 Elasticsearchとニューラルモデルを利用したランカーでのリランクする仕組みがSemantic Searchと似ていたので読んでみました。\nざっくりメモ どんなもの？ クリックログなどで関連度を改善できないような場合に、ドメイン固有の言語モデルを利用して検索結果の改善をする方法が提案されているので、バイオメディカル検索で実際に評価してみたという論文です。 特定分野の大量の文書から検索をするときに、ドメイン固有の事前学習した言語モデルを用意して、さらにファインチューニングする方法を評価しています。 言語モデルの生成に利用されたのはBERTになります。\n技術や手法のキモはどこ？ 医療分野のデータを利用して評価していますが、ほかのドメインにも一般化できる可能性があることや、実際のシステムを提示している部分が肝になりそうです。\n論文から引用した言語モデルを用いてランキングを行う仕組みを構築する部分の構成です。\n左半分が、ドメイン固有の事前学習についてです。Wikipediaなどを利用したBERTのモデルが公開されたりしていますが、大量のドメイン固有データが用意できるのであれば、ドメイン固有のデータで事前学習することが有効であるという主張です（参考文献。これもMS Researchでした。同じチームなのかな？）。 この論文ではBERTの学習データとして、ドメイン固有のテキストを用いています。 実際にはPubMedBERTを利用しています。\n右半分がドメイン固有のデータで生成された言語モデルを利用して、ドメイン固有のニューラルランカー（検索結果のランキングを行なう仕組み）をファインチューニングする処理です。 MS MARCOと呼ばれるMSが公開している機械学習向けのデータセットのうち、ドメイン固有のサブセットを取り出して利用しているようです。\nこの論文では、L1検索（第1段階の検索）にBM25を利用して、L2検索にここで作成したニューラルランカーを利用し、検索結果を返す仕組みとなっています。 これは、Azure Cognitive SearchのSemantic Searchのシステムに似ています。\nこの論文では、BM25で検索した結果の上位60件の結果がL2のランカーの入力となっています。\n以下の2つが主な論文の成果となっています。\nドメイン固有の事前学習を利用することで、高度な学習コンポーネントなどの追加することなく高い精度が出た。 既存のBM25の検索エンジンと組み合わせてニューラルランカーを使うことで、計算コストを下げつつより良い上位の検索結果を返す仕組みを構築した。 どうやって有効だと検証した？ TREC-COVIDデータセットを用いて評価して、TREC-COVIDに参加しているシステムと論文で提案している構成のシステムとの比較をしています。 また、ドメイン固有の事前学習が、一般ドメインなどの事前学習と比較して影響があるかどうかの評価もしています。\n実際にAzure上で構築した仕組みをMicrosoft Biomedical Searchとして公開しているようです。 上記のシステム構成のように、Elasticsearchで検索して、ニューラルランカーはKubernetes上に展開されたGPUで計算をしています。 論文には使用しているマシンの構成や台数なども記載があります。\n実際に構築したシステムをユーザーに利用して体験したもらった結果としては、 複雑な意図を持った長いクエリに対してはPubMedなどの他の検索ツールとしても良い結果が返ってきたことが確認されたとなっています。 ただし、一般的な短いクエリの場合は十分な結果にならない場合があったとのことです。\n議論はある？ 実際にほかのドメイン（金融、法律、小売りなど）で適用してもうまくいくかは今後の研究に期待だと思います。 また、ファインチューニングするときに利用できるデータが今回の論文にあるようにMS MARCOのサブセットとして抽出できればよさそうです。\n他に読むべき論文は？ TREC-COVIDに参加しているほかのシステムがどのような学習や仕組みが必要なのかを見ることで、どのくらいの手間・コストが軽減しているのかがわかるはずです。\n感想 ということで、読んでみました。 細かなほかの手法については調べていませんが、システム構成としてはAzure Cognitive SearchのSemantic Searchの仕組みと同じだと思われます。 違いは、ドメイン固有の事前学習のモデルではないことでしょうか。 ある程度のドメイン固有のモデルを利用できる仕組みができると、さらにSemantic Searchがうまく使えるようになるのかもしれません（前回書いたブログではWikipediaのデータを利用してみましたが、思ったほど良い感じはしなかったです。。。ファインチューニングの仕組みもないしなぁ）。 また、短いクエリでは芳しくない結果もあったというのは、おそらくニューラルランカーで評価するための情報が少なくなってしまうのだと思います。Semantic Searchに向いているクエリの作り方とかが出てくるのかな？\n","date":1636522396,"dir":"post/2021/","id":"35200cbf0b5b45d7f5f0b343cb18868b","lang":"ja","lastmod":1636522396,"permalink":"https://blog.johtani.info/blog/2021/11/10/reading-ms-biomedical-search-paper/","publishdate":"2021-11-10T14:33:16+09:00","summary":"Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだので軽くメモを残しておきます。論文自体はリンクから参照してください。 読んだ理由 Azure Cognitive S","tags":["search","paper"],"title":"Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだ"},{"contents":"今年もMICESにも参加してました。 昨年はBerlin Buzzwordsと共同開催でしたが、今年は別開催（別日程）でした。\nMICESは2017年から始まったe-commerceの検索にフォーカスしたカンファレンスです。 ECに関連する話に特化されていますが、話題は多岐にわたっています。色々やることありますねぇ、ECも。\n参加したセッション 参加したセッションの個人メモを今回も残しておきます。 セッション個別のリンクは用意されていないみたいですが、公式サイトにタイムテーブルがあり、セッションのタイトル、概要に加えて、スライドのPDFもリンクがあります。動画が公開されているものもあります。\nDreaming Search ビデオが公開されています。スライドがざっくりしたものなので最初に聞いた時にはしっくりこなかったので、聞き直してのメモです。 GDPRのような話で、個人の情報を自分たちで管理しようと流れがあります。 それぞれのECサイトなどでのユーザーのイベント（何を検索して、何をクリックした）情報はそれぞれのサイトで閉じた情報になっています。このため、自分の興味のある情報が断片化された情報でそれぞれのサイトで管理されてしまい、パーソナライゼーションされるもの（ランキングだったりレコメンドだったり）がいまいちな場合があります。 この個人の情報（ユーザーのイベント）をユーザー自身がハンドリングして、どの情報までをどこまで公開できるようにするというように管理できる仕組みができないか？という話のようでした。実際にそのための仕組み（もっと大きな話の仕様）を検討しているプロジェクトがあり、それに関連して検索という観点で夢を語っているセッションです。\nざっくり私が理解したのをまとめましたが、empathy.coという会社としてはいくつかPoCなども実施されているようでした。 個人の情報の扱い方に関する話は新鮮で面白かったです。 仕組みが出来上がり、各サイトが対応するとより個人が欲しい情報が集まりやすくなるのかなぁ？\nForget Facets, welcome Refinements (TM) Berlin BuzzwordsでいくつかLTをやられていた方によるファセットとその応用（彼らはRefinementsと名前をつけたみたい）についての話でした（ビデオとスライドが公開済み。）。 検索エンジンとファセットの関係の歴史から始まって、Kibanaでの使い方、モバイルや音声検索・チャットボットでのファセットは難しいよね？という話につながります。 ということで、Refinementsとして、ファセットを提示してユーザーに選んでもらうだけでなく状況に応じて、提案するための情報としてファセットを使うといいのでは？という話でした。例えば、チャットボットや音声検索での結果の場合、検索結果数が多くなるとユーザーが望んだものが返せるとは限らないです。その時に、ファセットの情報をもとに絞り込み条件を聞き返すネタに使うのはどうか？というような話でした。オートサジェスト（検索があいまいな時に、追加のキーワードを提案するもの）のような形でブランド名だったり、カテゴリーなどを表示する仕組みです。 実際の実装の話は、彼らが過去にBerlin Buzzwordsなどで話をしているのでそちらが参考になるとのことでした（参考：berlin buzzwords 2019 / Heystack 2019）\nReinforcement learning in search 検索における強化学習の話みたいです。ビデオとスライドが公開されています。ビジネス的に検索のランキングが重要だが、そのランキングをどうやって良くしていくのか？という話です。 ランキングでデフォルトのBM25から始まり、LtRを導入し、A/Bテストなどをしつつ、モデルの変化がどのようにビジネスに影響するかをはかるのが難しくなります。 LtRに対するオンライン機械学習のアプローチについて実際に直面した課題の話などがされている（はず？）です（どうも、実際にCTRなどを用いたところまでは行ってなさそう）。\n多腕バンディットなどの強化学習の話が続いたあたりでギブアップしてしまいました。。。\nBetter Search through Query Understanding - Panel Query Understandingに関するパネルとして3社の人がそれぞれどういった取り組みをしてるか？という話をしたあと質問などに答えていく形式でした。残念ながらビデオはまだ公開されていませんが、スライドが公開されています。QA部分も結構な時間だったのでビデオの公開がされるといいなぁ。\nUnderstanding queries by analysing user interaction / Andrea Schütt (OTTO) OTTOというECサイトでのQuery Understandingの紹介と、LtR導入にまつわる話。 データサイエンスとして最初はQuery Understandingやってたけど、スケールしないのでLtR導入して色々と試行錯誤しているところのようだった。\nQuery Understanding AI search eBayの方の発表。Query Understanding = ユーザーの興味をクエリから類推するという定義から、クエリを分類する、同定するためにどうしているか？という話でっした。 単語の表面的な文字としての近さだけでは、語順が変わると意味が変わるものや、ステミングのせいで同じになってしまうものといった例を紹介しつつ、クエリをベクトルにして表現（コンバージョン、クリックなどの情報を元にプロダクトのベクトルにしてみたり）し似ているかどうか？を判断している話です。\nCase study : Autocomplete Search Suggestions Digitec Galaxusというサイトでのオートコンプリートをもっと使いやすくするためにどんなデータを集めて、どうやって表示しているか？という話でした。 とりあえず入力されたものにヒットしたものを出すような実装だった場合に、サジェストされる量が多く、ノイズも多いので使いにくかったものをどうやって改善して行ったかという処理の流れなどの説明もありました。\nThe need for an open web search in Europe - The approach of the Open Search Foundation and its implications for E-Commerce-Companies Speaker: Alexander Decker / OPEN SEARCH FOUNDATION\nもっとオープンな検索システムを作っていこうという団体の話でした。 AWSが最近1.0をリリースしたやつとは別物です。 Googleでみんな検索しているけど、ブラックボックスなのでバイアスがかかっている。 もっとバイアスフリーなインデックスを提供できると、使いやすくなるよね？みんなでそういうインデックスを作っていかないか？という話でした。 ECとの直接の関係はセッションからは読み取れませんでした。 どうやって、集めるデータの基準（入れるべき、入れるべきではないなど）を作るんだろう？という疑問が残っています。公共的なものやオープンデータについてはあるとよさそうかもなぁ。\n101 hints to improving the customer satisfaction on search engines in the retail industry Speaker: Marion Hemery (Carrefour France) \u0026amp; Lucian Precup (a// \u0026amp; Adelean)\nカルフールのECサイトでの検索に関する顧客満足度の改善についての話です。 どんなものをどうやって図るのか、フィードバックを取るための仕組みは？ そこからわかったものをどうやってシステムに優先度をつけながら取り込んでいくのか？ というのをどんなものを使っているかという説明を交えながらのセッションです。 スライドが結構細かく書かれているのでスライドを見るだけでもわかりやすいかな。\n“An ounce of prevention is worth a pound of cure”: establishing a gold standard-based evaluation in customer projects Speaker: Bertram Sändig \u0026amp; Cornelia Werk / NEOFONIE\n検索の性能指標（速度ではないほうの性能）をきちんと評価する仕組みが重要だよというセッションです。 検索の仕組みを変更（例ではステミングを導入するはなしをしてました）した場合に、現行システムにどういう影響が出るのか？それをどうやって図るのか、どうやってテストしていくのか？という話です。 ステミングを導入したら、検索にヒットしやすくなったものも出てきたけどその弊害として今までよかった検索の結果にノイズが増え多という話をもとに、検索結果としてこうあってほしいというゴールデンスタンダードをきちんと作って育てていくべきですよという話でした。完ぺきなものなどないので少しずつやっていきましょうと。\nということで、見ていないもの（LTや最後のワークショップ）もありますが、見たものに関してメモを残してみました。\n","date":1626160103,"dir":"post/2021/","id":"10a7f69bd03d2632722300194f01e93d","lang":"ja","lastmod":1626160103,"permalink":"https://blog.johtani.info/blog/2021/07/13/attend-mices-2021/","publishdate":"2021-07-13T16:08:23+09:00","summary":"今年もMICESにも参加してました。 昨年はBerlin Buzzwordsと共同開催でしたが、今年は別開催（別日程）でした。 MICESは201","tags":["conference","berlin buzzwords","MICES"],"title":"今年もMICESにオンライン出張してた"},{"contents":"今年もBerlin Buzzwordsにオンライン出張してました。 今年の開催は6月14日から17日まででした。 どんなカンファレンスなのかは昨年のブログ記事をごらんください。\n今年はHAYSTACKは共同開催で、MICESは別開催でした。 MICESにも参加していたので、また後日にブログ記事を公開する予定です。\n参加したセッション 参加したセッションの個人用のメモを取ってあるので、簡単にまとめておきます。 セッションページに動画やスライドも追加されつつあります。興味のある方はそちらをご覧いただければと。 （今のところYouTubeに上がっているビデオは69本あります。再生リストはこちら） 気になっていたセッションもあるので、ビデオを見てまたメモを公開すると思いますが、まずは第1弾を。 ちなみに、検索をメインに見ています。Berlin Buzzwords自体はオブザバビリティやOSSコミュニティ、データのストリーミングの話などの話題もあるので、この辺りも興味があれば探してみても面白いかもです。\nHow to measure Diversity of Search Results セッションページ： How to measure Diversity of Search Results | Berlin Buzzwords 2021 従来の検索では、クエリに対して精度の高い検索結果を1件または数件返すのはどうするか？というものだったが、最近、あるユースケース（ほかの物の発見を促したいケース）では 検索結果の多様性を高めつつ、精度もある程度確保したいという場合があります。\nざっくりした検索クエリ（例えば自転車）の場合に、自転車だけが1ページ目にある場合よりも自転車とは別に自転車グッズも表示された場合のほうがクリック率やGMV（Gross Merchandice Value?）が上がったという話が紹介されていました。 この時どのくらい混ぜればいいのか？というのを、シャノンのエントロピーを使って、検索結果の多様性を保つための具体的なヒントについて話をされています。 実際にこういう計算をしてやれますねという紹介がされています。\nFrom text search and recommendation to ads and online dating; approximate nearest neighbors in real world applications セッションページ: From text search and recommendation to ads and online dating; approximate nearest neighbors in real world applications | Berlin Buzzwords 2021 Vespa.ai（OSS）の紹介でANNの話でした。通常、ANNを用いた検索の場合に他の検索条件（地理情報、日付など）をANNの結果に対して適用すると、望んでいる数がとれないです。その場合に、Vespaは内部でいい感じの動きをしますよという紹介でした。\n\u0026ldquo;Are You Sure?\u0026quot;： blending product comparisons and recommendations with A.I. セッションページ: \u0026ldquo;Are You Sure?\u0026quot;： blending product comparisons and recommendations with A.I. | Berlin Buzzwords 2021 Amazonの製品ページにある、類似商品との比較一覧のような一覧をどうやって実現するか？という話でした。比較一覧に掲載する商品を選出するパイプラインをこうやれますよね?という話でした。ログ（クリックやカートに入れたかどうかなど）を元にkNNで似ているデータを洗い出し、どの商品、どの項目を比較一覧として選ぶかという流れでした（セッションではもっと詳しい話がされています）。オフライン実験の話までがセッションでされています。\nThe future of Lucene\u0026rsquo;s MMapDirectory： Why use it and what\u0026rsquo;s coming with Java 16 and later? セッションページ: The future of Lucene\u0026rsquo;s MMapDirectory： Why use it and what\u0026rsquo;s coming with Java 16 and later? | Berlin Buzzwords 2021 Apache Lucene PMCのUweさんによるLuceneのMMapDirectoryの話です。 ファイルシステムとJavaに関する歴史と、なぜMMapなのか、現在のMMapの実装の問題点とJDK 16でどうなっているか（どんな感触か）、さらにその先（JDK17）は？という話です。 Luceneでの利用方法からJDKへのフィードバックが行われている話や、そのフィードバックをもとに今後どのようにしていくのか?という話がされています。\nSearch and Sushi; Freshness Counts セッションページ: Search and Sushi; Freshness Counts | Berlin Buzzwords 2021 こちらもVespa.aiの紹介です（今年はスポンサーしてるから多いのかも？）。Yahoo!とVerizon Mediaで利用している話をしたあと、Vespaでのリアルタイムインデキシングに関するアーキテクチャの紹介でした。内部で転置インデックスやそれ以外のデータをどのように保持しているのか？どういったことができるのか？というのをアーキテクチャ、ストレージの観点から紹介しています。\nEncores? - Going beyond matching and ranking of search results セッションページ(動画がまだない): Encores? - Going beyond matching and ranking of search results | Berlin Buzzwords 2021 検索のマッチングやランキング以外のいくつかの機能についての紹介をワークショップ形式で行うセッションです。ファセット、クエリオートコンプリート、スペル訂正、クエリリラクゼーションについて、データとSolrのクエリを基準に説明をしてくれます。\nThe Invasion of Transformers - Boosting Search with Latest NLP セッションページ: The Invasion of Transformers - Boosting Search with Latest NLP | Berlin Buzzwords 2021 deepsetという会社のCTOの方で、自社で作っているOSSのhaystackという製品の紹介です。 最近のGoogleの検索結果にはいろんなもの（問いかけに関する答えそのもの、またそのプレビューやサマリー）が出てきているという話から、Transformersを使って検索ができないかということで自社のOSSの仕組みを紹介しています。\n参考 Google： BERT now used on almost every English query deepset-ai/haystack： End-to-end Python framework for building natural language search interfaces to data. Leverages Transformers and the State-of-the-Art of NLP. Supports DPR, Elasticsearch, Hugging Face’s Hub, and much more! Learning to Judge セッションページ: Learning to Judge | Berlin Buzzwords 2021 otto.deというECサイトでLtRを導入し、そのLtRにどんな特徴を利用しどうやって実験したかというセッションでした。Apache Solrで検索ができていて、これまでは検索の管理を人手で行っていたがスケールしない（扱う商品などは増えているのに）のでLtRを導入し始めたという感じでした。LtRの導入の過程でどういう仮定を置いて、どうモデルを決め、それをどうやってテストしてどう分析したか?という流れでした。\nText categorization with Apache Lucene セッションページ: Text categorization with Apache Lucene | Berlin Buzzwords 2021 LTなので短めです。BBCのデータセットをインデックスに登録し、そのデータをもとにLucene（デモではKibana＋Esを利用していた）でテキスト分類を行なう方法について紹介しています。BBCのデータセットは記事（テキスト）とカテゴリ（タグ）というデータです。 このデータが登録されているインデックスに対して、More Like Thisクエリに分類したい文章を与え、ヒットしたデータをもとにAggregationでカテゴリを取得し、上位のカテゴリが分類された結果になるというデモでした。 テキストフィールドにはEdge N-Gramを利用していること、Aggregationのソートの条件はMore Like Thisクエリでのスコアの平均を利用していることというのがこの方法がうまくいくことのようでした（なるほど！）。ただ、日本語でもこれが使えるかな？というのはやってみないとわからないかなぁと（やってないです）。\nとりあえず、メモしておいたのはこの辺でした。 他にもセッション一覧を眺めながら面白そうな話をピックアップしてメモを取っていこうかなぁ？気になるセッション、メモがおかしいなどあればコメントいただければと。\n","date":1625815493,"dir":"post/2021/","id":"59b7b60e6bbf4858d72643d22ad90451","lang":"ja","lastmod":1625815493,"permalink":"https://blog.johtani.info/blog/2021/07/09/berlin-buzzwords-2021-1/","publishdate":"2021-07-09T16:24:53+09:00","summary":"今年もBerlin Buzzwordsにオンライン出張してました。 今年の開催は6月14日から17日まででした。 どんなカンファレンスなのかは昨年","tags":["conference","berlin buzzwords"],"title":"今年もBerlin Buzzwordsにオンライン出張してた"},{"contents":"Azure Cognitive Searchで新機能「Semantic Search（セマンティック検索）」という機能の日本語対応が発表されました。 実際にはPublic Previewという状態ではありますが、どんな機能か気になったので調べてみました。 なお、本ブログは2021年6月時点での内容となります。\n公式ドキュメント 公式ドキュメントでいろいろと説明されています。まずは公式ドキュメントを見ていただくのが良いかなと。最初のドキュメントには10分ちょっとの紹介ビデオもあります。ピックアップしたのは概要、クエリ、レスポンスの構造、紹介ブログになります。ブログ以外は日本語（たぶん機械翻訳？）になっています(新機能の紹介の日本語ページにはまだ記載がありません)。\nSemantic search - Azure Cognitive Search | Microsoft Docs Create a semantic query - Azure Cognitive Search | Microsoft Docs Structure a semantic response - Azure Cognitive Search | Microsoft Docs The science behind semantic search： How AI from Bing is powering Azure Cognitive Search - Microsoft Research 簡単にですがデータを入れて試してみたので、どんな仕組みなのかどういう挙動なのかを紹介します。\nSemantic Searchとは？ 言語理解、セマンティック関連性などを提供する機能です。BingとMSリサーチにより開発されて、Azure Cognitive Searchに導入されました。 クエリの書き方を少し変更する必要がありますが、再インデックスや設定変更などは必要ないという仕組みになっています。\n検索クエリからコンテキストを読み取って、検索し、リランクするアルゴリズム(Semantic Ranker) 関連する一節を強調表示（Semantic Caption） クエリに対するセマンティック回答(Semantic Answer) スペルチェック機能 言語によって利用できる機能が異なります。\nSemantic Searchの利点は先ほどの紹介にも書きましたが、インデキシング時に特殊処理をする必要がないことかなと。 すでに登録してあるデータ（制限がありますが）でもすぐに試すことができます。\n仕組み https://docs.microsoft.com/ja-jp/azure/search/media/semantic-search-overview/semantic-query-architecture.png\nスペル修正機能 クエリパース スコアリング 上位50件に対してSemantic Rankerにより再評価（検索ヒットが50件以上の場合でも上位50件のみがリランクの対象） 言語表現モデルを利用 結果の要約として最適な部分をキャプションとして抽出。 クエリが質問形式の場合は一番よさそうな場所を回答として選択 1および4番目の処理が今回新しく使えるSemantic Searchの機能になります。スペルチェックは日本語がまだ対象外なので、4番目の機能について紹介します。\n利用できる環境と制限 冒頭でも書きましたが、Public Previewの段階です。実際に利用するにはリクエストページから申し込みが必要になっています。\n利用リクエスト時に利用するAzure Cognitive Searchのサービス名が必要になるので、あらかじめ起動しておかなければいけません。 また、利用できるリージョンが限定されているのでサービス起動時のリージョンには気を付けてください。\n利用できるリージョン 米国中北部、米国西部、米国西部 2、米国東部 2、北ヨーロッパ、西ヨーロッパ 利用できるTier セマンティック検索はStandardレベル スペルチェックはレベル制限なし 価格（セマンティック検索のみ） 7月初旬までは25万クエリで500ドル Analyzerの制限 Azure Cognitive Searchが提供する言語アナライザーが対象（Custom Analyzerでは利用不可） サービス起動後にプレビュープログラムを申請すると、利用できるようになるとメールが届きます。そこから利用ができるようになります。\n今回は日本語のWikipediaのデータをいれてどんな機能なのかを確認してみました。\nWikipediaのデータを入れて試してみた 日本語のWikipedia（あとで英語も入れました）を一部（10万件程度）登録してSemantic Search（主にRanker）の動きを確認してみました。\nデータの登録には自作ツールを利用。\nJSONデータ生成ツール：https://github.com/johtani/wiki-extractor-rs JSONデータ登録ツール：https://github.com/johtani/wiki-json-loader 日本語Wikipediaの2020年6月のデータ、英語Wikipediaの2021年6月のデータを利用。上記ツールで生成したもののうち約10万件をAzure Cognitive Searchに登録して動作確認をしました（英語のデータでJSONデータ生成ツールでバグがあるのですが修正していません。。。）。 また、クエリの実行にはVisual Studio CodeのREST Client拡張(どんなものかは以前のブログをご覧ください)を使いました。簡単にREST APIを呼び出せるのはすばらしい。\n日本語のWikipedia 日本語のWikipediaのデータを「96,344件」登録し実験しました。 スキーマは次のような形です（説明に必要なものだけ抽出してあります）。自然分が入っているtitle、contents、headingsの3つのフィールドを今回はSemantic Searchの対象にしてみるので、AnalyzerをLuceneベースの日本語Analyzerであるja.luceneを設定しました。\nフィールド名 : タイプ / Analyzer id : Edm.String / keyword categories : Collection(Edm.String) / keyword title : Edm.String / ja.lucene contents : Edm.String / ja.lucene headings : Edm.String / ja.lucene Analyzerに言語Analyzerを設定するくらいで、他の設定は特に必要ありません。\nクエリとデータの確認 デモの動画や説明のサンプルを見たところ英語で「Where was Alan Turing born?」や「What\u0026rsquo;s the capital of France?」のような自然文のクエリが出てきたので、次のようなクエリで試してみました。\nフランスの首都はどこですか？ 実際にパリのページがインデックスに存在していることは以下のクエリで確認しました。\nパリ：3047件 POST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;パリ\u0026#34;, \u0026#34;top\u0026#34;: 10, \u0026#34;searchFields\u0026#34;: \u0026#34;title, categories, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id, contents\u0026#34; } ※ここで{{host}}などはREST Client拡張で変数として定義したものです。\nhost : Azure Cognitive Searchのサービス名 index-name : インデックス名 api-key : 接続のためのAPIキー URLパラメータのapi-version=2020-06-30-PreviewがPreview機能を呼び出すための指定になっています。\n3047件の1件目が「パリ」のページで以下のようなWikipediaの文章をセクションごとに文字列としてページ全体を配列に入れてcontentsに登録してあります。\n\u0026#34;パリ（、巴里）は、フランス北部、イル＝ド＝フランス地域圏にある都市。フランスの首都であり、イル＝ド＝フランス地域圏の首府である。\\nフランス最大の都市であり、同国の政治、経済、文化などの中心である。ロンドンと共に欧州を代表する世界都市。行政上では、1コミューン単独で県を構成する特別市であり、ルーヴル美術館を含む1区を中心に、時計回りに20の行政区が並ぶ（エスカルゴと形容される）。\u0026#34;, このインデックスに対して「フランスの首都はどこですか？」というクエリを、セマンティック検索のクエリと通常のクエリの2パターンで検索をしてみました。\nこれまでのクエリ（セマンティックではない検索） まずは通常のクエリです。 searchがクエリ文字列、searchFieldsが検索対象フィールドになります。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;フランスの首都はどこですか？\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34; } クエリを実行するとヒット件数が'13996\u0026rsquo;件で、トップ5件のデータは次のようになりました。\n\u0026#34;@odata.count\u0026#34;: 13996, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 17.059355, \u0026#34;id\u0026#34;: \u0026#34;462\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;首都\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 16.086372, \u0026#34;id\u0026#34;: \u0026#34;21053\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;首都圏\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 15.059893, \u0026#34;id\u0026#34;: \u0026#34;71414\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;どこでもドア\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 14.086605, \u0026#34;id\u0026#34;: \u0026#34;51972\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;首都機能移転\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.996841, \u0026#34;id\u0026#34;: \u0026#34;3877\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;首都の一覧\u0026#34; }, 見るとわかりますが、「首都」「どこ」といった単語を含むデータが上位に入っています。「フランス」を含むデータは8件目と10件目に「フランス植民地帝国」、「ラ・フランス」といったデータが出てきます。\n{ \u0026#34;@search.score\u0026#34;: 12.705561, \u0026#34;id\u0026#34;: \u0026#34;129279\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランス植民地帝国\u0026#34; }, ... { \u0026#34;@search.score\u0026#34;: 12.036648, \u0026#34;id\u0026#34;: \u0026#34;3173\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ラ・フランス\u0026#34; }, 残念ながら望んでいる結果にはほど遠いかと。\nどんな検索になっているのでしょうか？まずは、クエリの解釈から。 デフォルトで、Azure Cognitive Searchはデフォルトでは、入力された文字列をtype=simple、mode=anyで検索します（クエリパラメータ参照）。 対象となるフィールドはsearchFieldsで今回は指定してあるので、これらのフィールドに対して、入力された文字列を渡してAnalyzerで単語分割し（今回はsimpleクエリ用の特殊文字が入っていないため文字列として扱われる）、 出てきた単語で（mode=anyだから）OR検索します。 ja.luceneのAnalyzerが出力する単語列がどんなものかは以下のリクエストを実行するとわかります。\nPOST https://{{host}}/indexes/{{index-name}}/analyze?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;analyzer\u0026#34;:\u0026#34;ja.lucene\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;フランスの首都はどこですか？\u0026#34; } 結果は以下の通りです。\n\u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;フランス\u0026#34;, \u0026#34;startOffset\u0026#34;: 0, \u0026#34;endOffset\u0026#34;: 4, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;首都\u0026#34;, \u0026#34;startOffset\u0026#34;: 5, \u0026#34;endOffset\u0026#34;: 7, \u0026#34;position\u0026#34;: 2 }, { \u0026#34;token\u0026#34;: \u0026#34;どこ\u0026#34;, \u0026#34;startOffset\u0026#34;: 8, \u0026#34;endOffset\u0026#34;: 10, \u0026#34;position\u0026#34;: 4 } ] これで、どのような単語が出てきているかがわかりました。 それぞれのフィールドでどのようなスコアになっているかまではわからないですが、検索結果には上記3つの単語のいずれかがsearchFieldsにヒットすれば出てきます。おそらく、ヒットした単語数が多い、短い文字列のフィールドがより高いスコアになるというような動きになっていると思われます（BM25になってるはず）。\nセマンティック検索 では、セマンティック検索のクエリに変更してみましょう。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;フランスの首都はどこですか？\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34;, \u0026#34;queryType\u0026#34;: \u0026#34;semantic\u0026#34;, \u0026#34;queryLanguage\u0026#34;: \u0026#34;ja-jp\u0026#34; } queryType、queryLanguageがセマンティック検索のクエリを実行するためのパラメータになります（公式ガイド参照）。 今回は日本語のデータであるため、日本語のモデルを利用するようにqueryLanguageを指定します（許可されていない文字列を渡すとエラーになる）。 この2つを追加するだけです。簡単ですね。\n結果は次のようになります（上位5件抜粋）。\n\u0026#34;@odata.count\u0026#34;: 13996, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 12.036648, \u0026#34;@search.rerankerScore\u0026#34;: 2.3456064984202385, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;ラ・フランス\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;ラ・フランス\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;3173\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ラ・フランス\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 11.144733, \u0026#34;@search.rerankerScore\u0026#34;: 2.3173404783010483, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;ラン (フランス)\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;ラン\u0026lt;/em\u0026gt; (\u0026lt;em\u0026gt;フランス)\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;108094\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ラン (フランス)\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 11.144793, \u0026#34;@search.rerankerScore\u0026#34;: 2.1937477812170982, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;ブレスト (フランス)\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;ブレスト\u0026lt;/em\u0026gt; (\u0026lt;em\u0026gt;フランス)\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;116154\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ブレスト (フランス)\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 10.199907, \u0026#34;@search.rerankerScore\u0026#34;: 2.1590753793716431, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;フランス・ハルス\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;フランス・ハルス\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;81566\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランス・ハルス\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 11.273148, \u0026#34;@search.rerankerScore\u0026#34;: 2.1434053033590317, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;バカロレア (フランス)\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;バカロレア\u0026lt;/em\u0026gt; (\u0026lt;em\u0026gt;フランス\u0026lt;/em\u0026gt;)\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;54514\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;バカロレア (フランス)\u0026#34; }, 検索結果数を見ると、通常のクエリと同じ値です。 これは、公式ドキュメントのセマンティック検索に説明があるように、 セマンティック検索が通常のクエリで実行した後の検索結果に対して、上位50件のデータだけに対してsemantic rankerによってスコアを再計算するという仕様のためです（ドキュメントからの推測）。\n実際に検索結果の50件目、51件目は次のようになっていました。50件目までのデータには@search.rerankerScoreというスコア（と@search.captions）が追加されています。 51件目のデータについては、前の通常のクエリの51件目のデータと同じデータでした。\n{ \u0026#34;@search.score\u0026#34;: 10.909212, \u0026#34;@search.rerankerScore\u0026#34;: 0.07321979058906436, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;首都高速埼玉大宮線\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;67667\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;首都高速埼玉大宮線\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 10.049902, \u0026#34;id\u0026#34;: \u0026#34;68569\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;スタッド・ド・フランス\u0026#34; }, 上位5件のデータに戻ります。 これらは、通常のクエリとは異なる結果となりました。 見ると@search.captionsというところにハイライトされた項目が表示されています。 検索クエリをもとにそれっぽい部分がキャプションという形で返ってくる仕組みです。\n結果を見るとわかりますが、残念ながら「パリ」のページは返ってきませんでした。 もともと通常のクエリを実行したときの「326」番目の結果として返ってきているため、セマンティック検索の対象とはならなかったためです。 ただ、「首都」「どこ」といった単語よりも「フランス」に関するドキュメントが通常の検索よりも上位に来ています。 クエリに存在する単語で「フランス」がより重要であると判断されているようです。\nSemantic Rankerに処理させてみる ちなみに、今回登録したデータにはWikipediaのカテゴリも登録してあります。 「ヨーロッパの首都」というカテゴリで絞り込んでから検索してみるとどうなるかもやってみました。 filterのパラメータが絞り込み条件です。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;フランスの首都はどこですか？\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34;, \u0026#34;queryType\u0026#34;: \u0026#34;semantic\u0026#34;, \u0026#34;queryLanguage\u0026#34;: \u0026#34;ja-jp\u0026#34;, \u0026#34;filter\u0026#34;: \u0026#34;search.ismatch(\u0026#39;ヨーロッパの首都\u0026#39;, \u0026#39;categories\u0026#39;)\u0026#34; } 結果は次の通りです。カテゴリで絞り込みをしているので検索結果数は39件となります。このため、すべてのデータがSemantic Rankerの対象です。 ですが、「パリ」のページは11件目に出てきました。\n\u0026#34;@odata.count\u0026#34;: 39, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 3.8405614, \u0026#34;@search.rerankerScore\u0026#34;: 2.0472740978002548, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;ウィーン\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;9465\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ウィーン\u0026#34; }, ... { \u0026#34;@search.score\u0026#34;: 4.8915977, \u0026#34;@search.rerankerScore\u0026#34;: 1.8480307757854462, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;レイキャヴィーク\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;レイキャヴィーク\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;112253\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;レイキャヴィーク\u0026#34; }, ... { \u0026#34;@search.score\u0026#34;: 7.277628, \u0026#34;@search.rerankerScore\u0026#34;: 1.7982495501637459, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;パリ\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;パリ\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;31\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;パリ\u0026#34; }, キャプションは入力された単語だけではなく、クエリが持っている単語をもとにした何かしらの基準（おそらく言語モデルで近い単語？）で選択されていると思われます。首都というカテゴリーで絞り込んでしまったので、ヒットした文章が似たようなものが多くなったせいか、残念ながらそこまでSemantic Rankerが意図を汲み取るところまでは行きませんでした。\nフランスの歴史 視点を変えてみましょう。質問そのものの答えではなく、クエリの意図に近いものが出てくるかを見てみましょう。 ここまでのクエリでフランスに関するクエリを投げていました。今回のインデックスに「フランスの歴史」で検索すると「30820」件のドキュメントがヒットし、上位にはフランスには関係ない「歴史」のページや「フランス」の文学、都市など「フランスの歴史」とは少し離れた意味のものが上位に来ています。\n\u0026#34;@odata.count\u0026#34;: 30820, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 12.888079, \u0026#34;id\u0026#34;: \u0026#34;17875\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;スコットランドの歴史\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.718105, \u0026#34;id\u0026#34;: \u0026#34;10665\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;世界の歴史\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.701981, \u0026#34;id\u0026#34;: \u0026#34;31397\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ベトナムの歴史\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.579847, \u0026#34;id\u0026#34;: \u0026#34;22433\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランス文学\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.524254, \u0026#34;id\u0026#34;: \u0026#34;34667\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランスの国旗\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.52136, \u0026#34;id\u0026#34;: \u0026#34;108094\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ラン (フランス)\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.41088, \u0026#34;id\u0026#34;: \u0026#34;20717\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;歴史小説\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.388911, \u0026#34;id\u0026#34;: \u0026#34;56229\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;演劇の歴史\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.343941, \u0026#34;id\u0026#34;: \u0026#34;39669\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;イギリスの歴史\u0026#34; }, このクエリをセマンティッククエリで検索すると次のようになりました。\n\u0026#34;@odata.count\u0026#34;: 30820, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 12.274498, \u0026#34;@search.rerankerScore\u0026#34;: 1.482184374704957, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;自由フランス\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;自由フランス\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;96475\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;自由フランス\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 11.446766, \u0026#34;@search.rerankerScore\u0026#34;: 1.3535655084997416, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;フランスの地域圏\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;フランスの地域圏\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;51845\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランスの地域圏\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 10.926437, \u0026#34;@search.rerankerScore\u0026#34;: 1.3261859538033605, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;フランス第一帝政\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;フランス第一帝政\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;57573\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランス第一帝政\u0026#34; }, 上位には「フランスの歴史」に関連しそうなタイトルが上がってきています。 また、先ほど「歴史」という単語でヒットして上位に来ていた「スコットランドの歴史」は@search.rerankerScoreの値が低くなっていました（31件目に出現）。\n{ \u0026#34;@search.score\u0026#34;: 12.888079, \u0026#34;@search.rerankerScore\u0026#34;: 0.42768346797674894, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;スコットランドの歴史\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;17875\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;スコットランドの歴史\u0026#34; }, 考察 日本語のWikipediaを約10万件入れたインデックスでセマンティック検索を試してみました。 デモや説明などでクエリが自然文の質問だったこともあり、質問の回答になりそうなページが上に来るかと期待しましたが、期待しすぎました。\nこれは、Azure Cognitive Searchのセマンティック検索の仕組みを考えると納得のいくものです。 説明を読んだ時にも感じたのですが、入力された文字列でまず検索をし、上位50件をセマンティック検索の対象としています。\nですので、そもそもクエリの文章に出てくる単語が含まれたデータだけが対象となります。 このため、クエリに出てこない単語のみで構成されているものは残念ながら対象とできません。 また、上位50件だけがSemantic Rankerの対象となっているため、検索にヒットしたとしても上位に食い込まなければ言語モデルによるランキングの対象にもなりません。 セマンティック検索といっても、残念ながらドキュメントに出てこない単語（似た単語、質問に対するそのものの回答）まで読み取る機能はありません。\nただ、「フランスの歴史」の検索で見たようにそれぞれの単語だけで検索をしていた場合とは異なり、 クエリの意味に沿ったスコアづけにより、通常の検索よりも意図したものに近いデータが出ていることが確認できました。 複数の単語で構成されるクエリの場合に、単語だけでスコアを計算した場合よりもよさそうな結果が上位に出てくることがわかりました。\nただし、重要なのは「上位50件」までしかSemantic Rankerの対象にはならない点です。\n英語のWikipedia セマンティックは英語対応が一番最初にリリースされているので、英語のWikipediaについてもデータを登録してみました。\n英語のWikipediaのデータを「111,649件」登録しました。 スキーマは以下の通り（今回の調査に利用していないものは省略）です。日本語と異なる点はAnalyzerがen.luceneになっていることぐらいです。\nフィールド名 : タイプ / Analyzer id : Edm.String / keyword categories : Collection(Edm.String) / keyword title : Edm.String / en.lucene contents : Edm.String / en.lucene headings : Edm.String / en.lucene クエリとデータの確認 日本語同様に首都に関する質問形式にしてみました。\nWhat\u0026rsquo;s the capital of Italy? 実際にRomeのページがインデックスに存在していることは以下のクエリで確認済みです。\nRome：2302件\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;Rome\u0026#34;, \u0026#34;top\u0026#34;: 10, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id, contents\u0026#34; } 以下のようなWikipediaの文章をセクションごとに文字列としてページ全体を配列に入れてcontentsに登録してあります（これも日本語と同じです）。\n\u0026#34;\u0026#34;\\n\\nRome (Italian and Latin: Roma ) is the capital city and a special comune of Italy (named Comune di Roma Capitale), as well as the capital of the Lazio region. The city has been a major human settlement for almost three millennia. With 2,860,009 residents in , it is also the country\u0026#39;s most populated comune...\u0026#34;, このデータ群に対して「What\u0026rsquo;s the capital of Italy?」というクエリを、Semantic Searchのクエリと通常のクエリの2パターンで検索をしてみる。\nこれまでのクエリ（セマンティックではない検索） まずは、Semantic Searchではないクエリです。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;What\u0026#39;s the capital of Italy?\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34; } ヒット件数は18049件で、トップ5件は次のような形です。\n\u0026#34;@odata.count\u0026#34;: 18049, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 17.870815, \u0026#34;id\u0026#34;: \u0026#34;14532\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Italy\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 16.596167, \u0026#34;id\u0026#34;: \u0026#34;14702\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Economy of Italy\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 16.180624, \u0026#34;id\u0026#34;: \u0026#34;183878\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Louis II of Italy\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 15.917025, \u0026#34;id\u0026#34;: \u0026#34;29665\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;State capitalism\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 15.88901, \u0026#34;id\u0026#34;: \u0026#34;215741\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Capitalization\u0026#34; }, 日本語の場合よりもItalyに関連するものが上位に多く含まれます。 ただ、Rome自体のページは上位50件には出てきていませんでした。 また、capitalとは意味の異なるcapitalizationやcapitalismが上位に来ています。 日本語の場合と同様にクエリがどのように解釈されているのか？も見てみます。\nPOST https://{{host}}/indexes/{{index-name}}/analyze?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;analyzer\u0026#34;:\u0026#34;en.lucene\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;What\u0026#39;s the capital of Italy?\u0026#34; } 結果は以下の通りです。\n\u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;what\u0026#34;, \u0026#34;startOffset\u0026#34;: 0, \u0026#34;endOffset\u0026#34;: 6, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;capit\u0026#34;, \u0026#34;startOffset\u0026#34;: 11, \u0026#34;endOffset\u0026#34;: 18, \u0026#34;position\u0026#34;: 2 }, { \u0026#34;token\u0026#34;: \u0026#34;itali\u0026#34;, \u0026#34;startOffset\u0026#34;: 22, \u0026#34;endOffset\u0026#34;: 27, \u0026#34;position\u0026#34;: 4 } ] 日本語とあまり変わってはいません。ただ、単語が入力されたものとは少し変わっています。 これは、en.luceneの処理で、stemmingが行われているためだと思われます。たとえば、「capital」の場合、Stemmingにより「capital」「capitalize」などの単語が元になりますが、動詞、名詞などの違いなく検索できるようにするためにこのようなStemmingの処理が行われます。 ということで、これらの単語を含むドキュメントがヒットしています。Italyが一番上に来ているのはItalyという単語が多く含まれるからのようです。\nSemantic Searchクエリ では、Semantic Searchのクエリに変更してみましょう。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;What\u0026#39;s the capital of Italy?\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34;, \u0026#34;queryType\u0026#34;: \u0026#34;semantic\u0026#34;, \u0026#34;queryLanguage\u0026#34;: \u0026#34;en_us\u0026#34; } queryType、queryLanguageがsemantic searchのクエリを実行するためのパラメータになります（公式ガイド参照）。 今回は英語のデータであるため、英語のモデルを利用するようにqueryLanguageを指定します（許可されていない文字列を渡すとエラーになる）。\n結果は次のようになります（上位5件抜粋）。\n\u0026#34;@odata.count\u0026#34;: 18049, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 17.870815, \u0026#34;@search.rerankerScore\u0026#34;: 1.9688458815217018, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Italy\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;14532\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Italy\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 14.239678, \u0026#34;@search.rerankerScore\u0026#34;: 1.9419755563139915, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Capital city\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;181337\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Capital city\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 10.181764, \u0026#34;@search.rerankerScore\u0026#34;: 1.8902588561177254, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Lepontii\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;325133\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Lepontii\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 10.865718, \u0026#34;@search.rerankerScore\u0026#34;: 1.875102698802948, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;ItalY\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;14482\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ItalY\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 11.689348, \u0026#34;@search.rerankerScore\u0026#34;: 1.8201303631067276, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Savoy\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;27885\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Savoy\u0026#34; }, 日本語で見てきたように、検索結果数を見ると、通常のクエリと同じ値で、残念ながら50件までにRomeは入っていないため、Semantic Rankerによるブーストもかかりませんでした。 ただし、「Capitalization」や「State capitalism」といった別の意味（地理に関するものではない単語）のものが上位に出てこなくなっています。 これは、capitalという単語が地理に関する意味を持っていると判断された結果のように見えます。 Capitalizationの@search.rerankerScoreは上位のスコアに比べて小さいものとなっています。\n{ \u0026#34;@search.score\u0026#34;: 15.88901, \u0026#34;@search.rerankerScore\u0026#34;: 0.93921028636395931, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Capitalization\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;215741\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Capitalization\u0026#34; }, What\u0026rsquo;s the capital of Finland? 上位50件以内(20件目)に「Helsinki」のページが出てくるクエリでセマンティック検索をしてみました。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;What\u0026#39;s the captial of Finland?\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34;, \u0026#34;queryType\u0026#34;: \u0026#34;semantic\u0026#34;, \u0026#34;queryLanguage\u0026#34;: \u0026#34;en-us\u0026#34; } 結果としては、2件目にHelsinkiが返ってきていたので、Semantic Rankerがによる並び替えがうまくいきました。 （下記の結果は上位3件を抜粋したものです）。\n\u0026#34;@odata.count\u0026#34;: 16673, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 14.026371, \u0026#34;@search.rerankerScore\u0026#34;: 2.42378556355834, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Vanaja (Finland)\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;7132102\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Vanaja (Finland)\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.434971, \u0026#34;@search.rerankerScore\u0026#34;: 2.383675143122673, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Helsinki\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;13696\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Helsinki\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 13.380153, \u0026#34;@search.rerankerScore\u0026#34;: 2.2026549801230431, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Rauma, Finland\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;178635\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Rauma, Finland\u0026#34; }, 考察 今回の英語のクエリではSemantic Rankerがある程度の役割をはたしていそうだということはわかりました。 Capitalがいくつもの意味を持っていることもあり、文章をもとにより意味の近いドキュメントが上位に来たということです。 ただ、英語の場合も基本的には上位50件以内のデータに対して処理が行われるので上位50件以内にデータが入らなければうまくいかないようです。\nまとめ Azure Cognitive Searchの新機能であるセマンティック検索について調べてみました。 まだPublic Previewですが、簡単に使えるような仕組み（データの再登録なし、クエリでパラメータを追加するだけ）が用意されているのは便利でした。 ただ、最初に想像していたもの（私の早とちりもありますが）ほどのセマンティック検索とは行きませんでした。 似たような言葉の意味を持ったものを探してくれたり、答えそのもののページのスコアがすごく高くなるといったものではありませんでした。\n仕組み上、クエリに含まれる単語で検索し、上位50件以内のデータだけが対象になる(残念ながら現時点ではこの件数の変更はできません。)ため、これまでの検索とは劇的に変化するものではないことはわかりました（銀の弾丸はないんですけどね）。\nある程度の挙動をわかっていれば、Wikipediaのようなデータでもそれなりの結果は取得できそうだということはわかりました。\n「言語モデル」でクエリとヒットしたデータをもとにスコア計算をし直しているようですが、この部分がどのようなデータ・クエリだと有効活用できるのか？というのをもう少しいろいろな角度で試してみる必要がある気がします（適材適所が何なのか？）。 あとは、上位50件までが対象なので、それ以上の件数のデータの並びに関してはこれまでと同様の結果となる点は注意しないといけません。 また、今回試していないほかの機能（スペルチェック、Semantic Answerなど）にメリットがあるのかもしれません。\nざっくりですがセマンティック検索について調べてみました。 こんなデータだとどうなの？ここの考え方が間違ってるのでは？などの指摘がありましたら、コメント欄またはTwitter（@johtani）でコメントを頂けたらと。\n","date":1625130583,"dir":"post/2021/","id":"43caef5d41c4e74826e4a8d82088739d","lang":"ja","lastmod":1625130583,"permalink":"https://blog.johtani.info/blog/2021/07/01/semantic-search-in-azure-cognitive-search/","publishdate":"2021-07-01T18:09:43+09:00","summary":"Azure Cognitive Searchで新機能「Semantic Search（セマンティック検索）」という機能の日本語対応が発表されました。 実際にはPublic P","tags":["azure search"],"title":"Azure Cognitive Searchの新機能、Semantic Searchを試してみた"},{"contents":"Sofle v2を長らく使っていましたが、コンパクトなのもやっぱりいいよなぁというときにKochi KeyboardからLunakey Miniが発売していました。 小指のあたりの傾斜が使いやすいかも？ということで、組み立ててみました。\nもちろん購入はKochi Keyboardさんからです（購入はこちらから）。\nLunakey Miniビルドガイド 作者のYoichiroさんが公開しているビルドガイドが詳細まで書かれています。 こちらをまずは参照してください。\nLunakey Mini ビルドガイド (Rev.4以降) ビルドログ（主にツイート） 私の組み立てについては、Twitterでツイートしていたものがありますので、そちらを貼っておきます。 ちなみに、ツイートしていて躓いているときに、作者のYoichiroさんからたびたびコメントをいただきました。 ありがとうございました！！\n間にいくつかコメントを差し込んでいます。\n結局両方のダイオードつけてしまいました。今日はここまで pic.twitter.com/3qLI6EpfXB\n\u0026mdash; Jun Ohtani (@johtani) April 12, 2021 ハンダはつけた pic.twitter.com/ySE9SA3gZn\n\u0026mdash; Jun Ohtani (@johtani) April 13, 2021 コンスルー問題 左手じゃん、T。Tのダイオード浮いてた。右手も一回全部見直すか\n\u0026mdash; Jun Ohtani (@johtani) April 13, 2021 ここで問題が発覚。右手（ツイートではぼけていて、左手と書いています）についてはダイオードが1か所浮いていただけなので、はんだ付けですぐ直りました。 左手側が大問題です。そもそも右手につけたProMicroへの書き込みができませんでした。 キーボードによっては、ダイオードなどを付ける前からまず、リセットボタンを付けて、ProMicroを指して書き込みをする場合もあります。 ただ、その書き込みができない。 （ちなみにこのタイミングでテスターをつけっぱなしにしていたのが発覚し、9V電池切れのため翌日に持ち越した。。。）\nさて、デバッグのお時間です pic.twitter.com/CaEOv4E5Bg\n\u0026mdash; Jun Ohtani (@johtani) April 14, 2021 ただ、ProMicro刺した状態で、リセットボタン、リセットボタンの足をショートさせても書き込みはできず、ProMicroのGndとResetの足のショートでは書き込みができる。\n\u0026mdash; Jun Ohtani (@johtani) April 14, 2021 テスターで調べてみたところ、リセットボタンとProMicroがうまく通電していません。\nだいぶ進んだけど、Eの列がおかしいなぁ。さて、どこの接触だ？ pic.twitter.com/5tci12Vk05\n\u0026mdash; Jun Ohtani (@johtani) April 14, 2021 どうも、左手の基盤のProMicroの足の穴がコンスルーとの接触が悪いみたいでした。 コンスルーの足を無理やりまげて（3個のコンスルーの足を折りました。。。）、通電できるようにして解決（結局あとでいくつかの足についてははんだ付けしました）。\n終わった。LEDの予備はんだまでやってからおしまいにしよ\n\u0026mdash; Jun Ohtani (@johtani) April 16, 2021 LED実装 鬼門の表面実装ですが、LEDを1個破損するだけで乗り切りました。ちょっと色はおかしかったですが、これはおそらくProMicroの足のせい。\n一個逆につけてしまい、お亡くなりになりましたが、まぁ、良いかな。まずは右手 pic.twitter.com/zldu6fRsXR\n\u0026mdash; Jun Ohtani (@johtani) April 18, 2021 ソケットの実装x2 ロープロファイル（Kailh choc v1）のキースイッチも試してみたいので、MXと両方のソケットをはんだ付けしました。 両方利用できるのは便利ですね。はんだ付けも楽しいし。\nソケットを片手だけ(両方のソケットつけるのでまだ、1/4) pic.twitter.com/7XFRDx0D0I\n\u0026mdash; Jun Ohtani (@johtani) April 18, 2021 キースイッチ設置 親指以外にはKailh Box Silentのピンク軸（Kochi Keyboardから）、親指にはKailh Input Club Hako Violet（AliExpressで購入したもの。リンクは遊舎工房のもの）をつけました。 どちらもそれほどぶれもないものです。Silent ピンクはリニアで静かでそれほど力がいらないスイッチになっています。 親指はタクタイルで小気味のいい音が気に入っています。Sofleもこのキースイッチになってます。\n残りのソケットつけて、キースイッチも設置して、動確してボトムプレートも装着。残りはキーキャップ。 pic.twitter.com/hGc1TtI6fu\n\u0026mdash; Jun Ohtani (@johtani) April 25, 2021 キーキャップ＋キーマップ お試しにXDAのキーキャップをはめてみたのですが、キーの境目がわかりにくく、タイプミスが多かったです。 その後のツイートにあるようにOEMに切り替えています。\nキーマップについては、Lunakey Miniの作者のYoichiroさんが作ったRemapというブラウザベースでキーマップの書き換えができるツールで楽々変更ができました。JISキーまで対応しているのでJISベースでキーマップを作成している私にはうってつけでした。 Remapの利用方法についてはサリチル酸さんのブログが詳しく書いてあります（本当に頭が下がります）。\nRemap使ってキーマップいじったら、すごく楽だった。\n\u0026mdash; Jun Ohtani (@johtani) April 26, 2021 BLE + LPME-IO化 ここまでで、USB接続で動作はしていたのですが、Sofle同様に3台をBluetoothで切り替えながら使いたかったので、 Corne Light v2につけていたBLE+LPME-IO(Corneの実装などは前のブログを参照)を抜き取って、Lunakey Miniに移植してみました。\nBLE ProMicro化は作者の方のブログで行われていたので、LPME-IO対応も何とかなるだろうと。\nBLE+LPMEに変えた。後でブログ書こう pic.twitter.com/mGePN52v6k\n\u0026mdash; Jun Ohtani (@johtani) April 29, 2021 LPME-IOへの対応はCorneとSofleの時に行なったこともあり、なんとなくあたりがついていました。 流れとしては、以下の通りです。\nBLE Micro Pro用の設定ファイルを作成 BLE Micro Proのサイトの「キーボードの設定ファイルを編集する」のコマンドでコンフィグファイルを生成 LPME-IOのジャンパをはんだでブリッジ 1.で生成したコンフィグから、Corne Lightと同じ個所のジャンプをすれば良いとわかったので今回はスキップ TRRSのI2C対応 Corne LightのLPME-IO対応の時と同様にSDAとSCLをTRRSの足にショートカット ただ、今回右手側は、下記ツイートのようにOLEDの足からTRRSの足にショートカットしました。Corneの基盤を見ていた時にこれでも行けそうだな？と思っていたので、試してみた次第です。ちなみに、左手はCorneの時と同じPro Microから長い銅線を引っ張っています（電池基盤があったので、外すのがめんどくさかったため）。 BLE Micro Proにファームウェア書き込み BLE Micro Proのサイトの手順に従います。 設定ファイルには1.で出力されているLPME用のファイルを使用。 といった感じです。キーマップが設定されていないので、Remapで設定しなおしました。 Remapは、キーマップをPDFで出力する機能までついていて、すごくいいですね。サイコー\nあと、足。 pic.twitter.com/W0Wpf5k5SE\n\u0026mdash; Jun Ohtani (@johtani) April 29, 2021 傾斜がつくように奥側に高さを出すためのゴム足を貼り付けました。 あとは、3台のPCにBluetoothで接続すれば終了です。 （AD_WO_Lのキーを利用して追加していくのを毎回忘れる。。。）\n疑問点 ちょっとだけ疑問点がありますが、時間があればそのうち調べるかな。\nRemapはクラウドに設定ファイルをセーブできるけど、json形式で手元にダウンロードしたりはできないのかなぁ？ LEDは有線じゃないと点かないみたいだけど、音はどうなんだろう？ 音が出せそうなら、Bluetoothの接続切り替えするときに音の出方を変えるとかをやってみたいなぁ。 まとめ ということで、Lunakey Miniを組み立てて、BLE+LPME-IO対応してみました。 はんだ付けはだいぶ慣れてきましたし、今回もトラブルがあったおかげでテスターを利用して、どのあたりがおかしいかという調査をするのも慣れてきました。 あとは、キーの配置の違いを体感して、どれが自分に合ってるかなぁ？というのを試したり仕様と思います。 ロープロファイルも試してみようかな。\nあ。もちろん、このブログは組み立ててBluetoothで接続したLunakey Mini Rev5、Kailh Box Silentピンク軸＋Input Club Hako Violetで書きました！！久々に数字列がないので記号入力とかがちょっとバタバタしましたｗ\n","date":1619709972,"dir":"post/2021/","id":"f4baa43cc7ca712d83b99a794c4e2dbd","lang":"ja","lastmod":1619709972,"permalink":"https://blog.johtani.info/blog/2021/04/30/build-lunakey-mini-ble/","publishdate":"2021-04-30T00:26:12+09:00","summary":"Sofle v2を長らく使っていましたが、コンパクトなのもやっぱりいいよなぁというときにKochi KeyboardからLunakey Miniが発売して","tags":["DIYキーボード","misc"],"title":"Lunakey Miniを組み立てて、BLE+LPME-IO化してみた #DIYキーボード"},{"contents":"みなさんは、スライドの作成には何を使っていますか？ Keynote？Powerpoint？Google Slides？\n私は、Macでスライドを作るときは前職ではテンプレートもあったのでKeynoteでしたが、ちょっとしたものはMarkdownベースのDecksetを利用していました（買い切りタイプの有料ソフト）。\nフリーランスになってもこちらを利用していたのですが、Windows環境に切り替えたので使えなくなってしまいました。 一度はGoogle Slidesで作ったのですが（第39回Es勉強会スライド）、既存の資産を流用したくなりどうしたものかと悩んでい(ツイートし)たら。\nMacの頃はDecksetってアプリでMarkdownで書いてたんだけど、Winに移動したのでこのタイミングでGoogle Slidesにでもしようかなと考えてるところ。Markdownでスライド作るのほかになんかあるか探すほうがいいかなぁ？\n\u0026mdash; Jun Ohtani (@johtani) March 18, 2021 僕はこれ使ってますhttps://t.co/sFaAmKZY6V\n\u0026mdash; miyake | ZEN (@kazuyukimiyake) March 18, 2021 ということで、利用してみようかなとなりました。\nMarpとは？ Markdownでプレゼンテーションのスライドを作ることができるOSS?になります。\nMarp公式サイト といっても、これ自体を使わなくても、VS Code上でプレビューしたりHTML形式で動作するスライドを吐き出すことが可能です。 なので、VS Code用のプラグインを利用しています。\nサンプル この間利用したスライドはこんな感じのMarkdownになってます。 ---でページを区切りつつ、記述していく形です。\n--- marp: true theme: poster --- \u0026lt;!-- _class: big-center --\u0026gt; # 本当にその検索は\u0026lt;br/\u0026gt;自分が想像している検索に\u0026lt;br/\u0026gt;なってますか？ \u0026lt;br/\u0026gt; \u0026lt;br/\u0026gt; \u0026gt; 2021/03 \u0026gt; Jun Ohtani / @johtani --- ![bg right:40% 40%](johtani_face.jpg) # 自己紹介 - フリーランスエンジニア - 検索技術勉強会主催者 - Apache Solr入門(第2版まで)や データ分析基盤構築入門の著者の一人 --- プレビューで見るとこんな感じです。\nプラグイン Marp for VS Code プラグインをインストールするのも簡単ですよね。 マーケットプレイスからインストールすれば完了です。\n機能については上記のページにあるように、プレビューとスライドの出力です。 プレビューでは、Markdownのプレビューみたいな形で、スライドが表示できます。\n先日この機能を利用して作成して、HTMLで出力して利用しました。 PDFとかPPTX出も出せるようなので、今後試してみようかなと。\nDecksetのスライドとの違い ページの区切りなども同じだったので、大筋ではそれほど違いはありませんでした。 ただ、画像周りとスタイルの設定は細かく修正をしました。\n変更した点としては、以下のようなものがあります。\nヘッダ部分の変更 上のサンプルにありますが、marp: trueを含む部分がMarp独自の記述です。 ページごとのちょっとした変更 ページごとにスタイルの変更ができるみたいで（Decksetではできなかったはず？）、タイトルページのスタイルを変えてあります。 画像の指定 画像の読み込み自体は違いはないのですが、画像の配置についての指定方法は カスタムテーマ用CSSの作成 デフォルトではなく、Decksetで用意されているような感じのスタイルに変更してみてます。 カスタムテーマはCSSで設定できるので、CSSファイルを用意して、VS Codeの拡張機能の設定からファイルパスを指定する形です。\nということで、当面はMarpでスライドを作っていくことになるかと思います。 まぁ、ただ、スライドを作るいこと自体が減ってきてはいるのですが。 ほかの配色を試したり、ヘッダフッタとかも試してみるのもいいかもな。\n気が向いたら、CSSをどこかにアップロードするかもです。\n※今回のブログはGateronサイレントクリア軸をルブしてみた、Corne Light v2で最後の数行を書いてみました。 キースイッチだけだとこすれる音が減った気がしてましたが、キーキャップを付けたら少しこすれる音が気になる感じです。\n","date":1617615911,"dir":"post/2021/","id":"f41d4fde94cbd7bbd28808dc080a2019","lang":"ja","lastmod":1617615911,"permalink":"https://blog.johtani.info/blog/2021/04/05/intro-marp/","publishdate":"2021-04-05T18:45:11+09:00","summary":"みなさんは、スライドの作成には何を使っていますか？ Keynote？Powerpoint？Google Slides？ 私は、Macでスライドを作","tags":["勉強会"],"title":"スライド作成の環境をMarpにしてみた"},{"contents":"新型コロナウィルスの影響もあり、オフラインで集まって勉強会も開催できなくなっています。 検索技術勉強会も、もう1年以上開催できていないです。\nスピーカーの人にオンラインでしゃべってもらうのもありだとは思うのですが、 懇親会とセットでその価値があったかもなぁと思うところもあり、オンラインでの開催に乗り気になれないまま時間がたってしまいました。 (配信周りを調べるのがめんどくさいなぁというのもあったかも（反省）)\nそんな中、takuya-aさんと話をしていて、エンジニア同士のゆるいつながりができる場所が欲しいですねぇということに。\nはー、検索技術勉強会、オフラインでできないまま１年以上たってしまったのか。オンライン勉強会とかはスピーカーの人の負担とかもあるし、Discordみたいなオープンな場だけ用意してみるのありかなぁ？ただ、活発に話がされるのかどうかわからんし、ROMな人ばかりだとアレなんだけどなぁ。\n\u0026mdash; Jun Ohtani (@johtani) March 30, 2021 そこからの、このツイートです。 ちらほらと興味のありそうな人が出てきたねという話をしていたら、Slackのワークスペースが出来上がってましたｗ\n検索技術に関する情報交換を目的とした Slack を立ち上げました！こちらの招待リンクからご参加ください。 https://t.co/Tca70vuMff\n\u0026mdash; takuya-a (@takuya_b) March 31, 2021 ありがとう、takuya-aさん！\nということで、検索周りでわいわいできる場になればいいなぁと。 盛り上がってくれば、オンラインでの勉強会とかもありかもしれないですね！ 興味のある方は、上記ツイート内のリンクからご参加下さい！！\n","date":1617200894,"dir":"post/2021/","id":"ce426b7f3190c8a4a47d45ac799e91a4","lang":"ja","lastmod":1617200894,"permalink":"https://blog.johtani.info/blog/2021/03/31/search-tech-jp-slack/","publishdate":"2021-03-31T23:28:14+09:00","summary":"新型コロナウィルスの影響もあり、オフラインで集まって勉強会も開催できなくなっています。 検索技術勉強会も、もう1年以上開催できていないです。 ス","tags":["勉強会"],"title":"検索技術に関する情報交換を目的としたSlackができました！"},{"contents":"Azure Cognitive SearchにはOData式という書式で条件が書ける仕組みがあります。 ODataは検索条件（$filter）やソート条件（$orderby）、取得する項目名の指定（$select）です。\n私は、Luceneの構文に慣れているので、普通のsearchパラメータを利用しようとします。 が、OData式として特殊な書き方がいくつかあるようなのでこちらの利用方法も調べてみました。 その時、N-Gram（よくやるのはN=2）で陥る問題の話もあるのでこちらについても言及します。\nOData式で検索 次のような3件のドキュメント(フィールド名はbodyとします)をN-Gramで登録していたとします。\nミルクティを飲みたいです。 マティーニはカクテルですが、ミルクセーキは？ 風呂上がりのミルクは最高です。 この時、OData式でミルクティという単語で検索してみましょう。\n検索条件は$filterで指定します。 フルテキスト検索用に関数が用意されており、こちらに単語を指定します。\n$filter=search.ismatchscoring(\u0026#39;ミルクティ\u0026#39;) こんな感じ。フィールドの指定がない場合、対象のフィールドは検索可能なフィールドすべてが検索対象になります（公式ガイドのクエリパラメータのqueryTypeに説明あり）。\nでは、実行してみましょう。で返ってくるのは？1だけかな？と思う人が多いかもしれません。 が、結果は3件とも帰ってきます。\n問題点は？ では問題点はどこでしょう？ ismatchscoringのオプションなどを見る前に、転置インデックスを用いた検索エンジンの挙動をおさらいしましょう。 転置インデックスの仕組みを理解することで、なぜそんな挙動になるのか？というのがわかりやすくなります。 おさらいにはElasticsearchをベースに話をしますが、Azure Cognitive Searchでも同じような挙動になります。\n転置インデックスとトークナイザー（アナライザー）の関係（おさらい） 昨年、オンラインで開催されたOSC広島で発表した資料（録画あり）でもざっくりと説明しています。\nView 本当にその検索は自分が想像している検索になってますか？ on Notist.\nざっくりですが、おさらいです。\n検索エンジンでは、入力された文章を、ある規則（アナライザー）で単語に分割し、その単語ごとにどのドキュメントに出現したのか？というリストが作られます。 このリストが転置インデックスです。書籍の後ろにある索引を想像するとどんなものかがわかりやすいです。 単語に対してその単語が出てくるページ番号がわかるという仕組みです（下図は本の索引の一例）。\n書籍の索引は著者や編集の方により厳選された単語のみが採用されています。 が、検索エンジンでは文章を単語に区切る機能が存在します。 この「ある規則」で単語を区切る仕組みが「アナライザー（トークナイザー）」と呼ばれる機能です。 例えば英語用のアナライザーに英語の文章が入力されたとき、文章はこのように単語に区切られたもの（単語列）を出力します（下図）。\n今回はNGramの話なので、NGramのAnalyzerを利用してみるとこんな感じになります。\n実際に出来上がる転置インデックスは次のような形になります。 検索の仕組み（おさらい） 出来上がっている転置インデックスに対して検索をする場合、入力文字列（検索条件）に対して、転置インデックス作成時と同様にAnalyzerが動作します。 処理としては、\nクエリのパース フィールドのAnalyzerで処理 転置インデックスを検索 という形です。 例えばこんな感じ。\n同じAnalyzerの処理が入ることで、転置インデックスに採用されているのと同じ単語が出てくるため、検索がきちんとできるということになります。\n英語と日本語（NGram）の違い 英語と日本語の違いは、スペースの意味になります。 英語の場合は、スペースが単語の区切りになりますが、日本語の場合スペースでは区切られていません。\nですので、検索窓に入力された文字列は、英語の場合、クエリのパースの時点で単語に区切られます。そのあとにAnalyzerになるので、基本的には単語単位でAnalyzerの処理が動きます。そのあと、転置インデックスへの検索となります。なので、多くの場合はAnalyzerの出力は1単語です（類義語などを利用していたりする場合は異なりますが）。\n日本語の場合、スペースでは区切られていないので、クエリのパースの時点で入力された文字列がそのままAnalyzerにわたります。 今回はAnalyzer（NGram）が単語に分割し、それをもとに検索処理が実行されます。\nismatchscoringの問題点は？（やっと帰ってきました） さて、回り道をし、簡単ですが転置インデックスやAnalyzerについて説明しました。 では本題です。\n$filter=search.ismatchscoring(\u0026#39;ミルクティ\u0026#39;) このismatchscoring関数ですが、そのほかにも引数の指定が可能で、省略した場合にデフォルトで採用される値がいくつかあります。 公式のドキュメントにパラメータの意味が掲載されています。\n今回は、第4引数のsearchModeの値が問題点です。デフォルトでは、anyが指定されます。 この、anyは検索語（今回はミルクティ）の任意の検索語句が一致する必要があることになります。 「検索語句」？なんでしょう？これが、ここまで回り道をして説明してきた、Analyzerの出力した単語になります。 「ミルクティ」はNGram（N=2）のAnalyzerを通すと、\n「ミル」「ルク」「クテ」「ティ」\nという4つの単語が出力されます。 これが、「検索語句」です。「任意の」とあるので、上記4つの2文字のどれか？が出現すれば検索条件にヒットしたこととなります。\nですので、以下のように（一部のみ色を変えてます）3つの文章にはそれぞれの文字が含まれているため、先ほどの条件では3件の結果が返ってくることになります。\nミルクティを飲みたいです。 マティーニはカクテルですが、ミルクセーキは？ 風呂上がりのミルクは最高です。 NGramで一部分の単語だけで一致したものがヒットしてしまうと違和感があるので、allに変更します。\n$filter=search.ismatchscoring(\u0026#39;ミルクティ\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;all\u0026#39;) 今度はどうなるでしょう？\nミルクティを飲みたいです。 マティーニはカクテルですが、ミルクセーキは？ 先ほどよりもマシになりました。 3がヒットしなくなっています。3の文章には「ティ」などが出てこないためです。 ただ、感覚的に2番目がヒットするのは少し違和感がありますよね？ 確かに4つの単語がすべて出てきていますが、「ミルクティ」とは少し遠いです。\nさらに「ミルクティ」にヒットさせるにはフレーズ検索にする必要があります。 Elastic社のブログの日本語の検索に関する記事でも出てきますが、フレーズで検索することで「ミルクティ」だけにヒットさせることができます。\n「フレーズ検索＝語順を保証する検索」となります。 ですので、\n「ミル」「ルク」「クテ」「ティ」\nこの順序で出てきた場合のみ、検索にヒットしたことになります。 OData式でフレーズ検索する場合は、単語をダブルクォート\u0026quot;でくくる必要があります（公式ドキュメントの例に記載あり）。\n$filter=search.ismatchscoring(\u0026#39;\u0026#34;ミルクティ\u0026#34;\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;all\u0026#39;) これで結果は以下の1件だけとなります。\nミルクティを飲みたいです。 これでNGramで部分一致のような挙動で日本語の検索ができるようになりました。\nちなみに、フレーズにした場合は第4引数はanyに変更しても1件だけの検索結果となります。 フレーズ検索には「すべての語が含まれる」、「すべての語が順番に現れる」という2つの条件が含まれるためです。\n$filter=search.ismatchscoring(\u0026#39;\u0026#34;ミルクティ\u0026#34;\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;any\u0026#39;) この例の引数をミルクティを\u0026quot;ミルク\u0026quot; \u0026quot;最高\u0026quot;のような検索条件に変えた場合、「\u0026ldquo;ミルク\u0026rdquo;」「\u0026ldquo;最高\u0026rdquo;」の2つの条件をanyで扱うため、 「\u0026ldquo;ミルク\u0026rdquo;」「\u0026ldquo;最高\u0026rdquo;」のどちらかが出てくれば良い結果となり、3件の結果が返ってきます。 第4引数をallに変更すると、「\u0026ldquo;ミルク\u0026rdquo;」「\u0026ldquo;最高\u0026rdquo;」の両方が出てこなければならないため、3件目のデータのみが返ってきます。\n$filter=search.ismatchscoring(\u0026#39;\u0026#34;ミルクティ\u0026#34; \u0026#34;最高\u0026#34;\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;all\u0026#39;) これは、\n$filter=search.ismatchscoring(\u0026#39;\u0026#34;ミルクティ\u0026#34;\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;any\u0026#39;) and search.ismatchscoring(\u0026#39;\u0026#34;最高\u0026#34;\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;any\u0026#39;) と同じ意味となります。 少し長くはなりますが、後者の書き方をプログラムで書くと思います、私の場合は。 検索窓に入力された単語に必ず\u0026quot;を追加する処理を書くために、画面入力の文字列を一旦パースをすることになるからです。\nまとめ 簡単？にですが、OData式でのフルテキスト検索と、NGramでのフレーズ検索について説明しました。 英語の場合、もともとスペースで区切られているので、フレーズといわれてピンときますが、日本語の場合はAnalyzerの挙動をわかっていないと「？」となるかと思います。 なぜフレーズ検索が必要なのか？というのが少しでもわかっていただければと。 ちなみに、NGramのTokenizerには別の落とし穴もありますが、その話はまた後日にでも。\n参考として日本語関連の検索に関する記事のリンクを残しておきます。\n参考 Elasticsearch日本語でフレーズ検索が必要なわけ NGramも含め、Elasticsearchでの日本語の検索の設定やクエリについては、Elastic社のブログで日本語で書かれた記事が詳しいのでこちらをご覧いただくのがいいです。 ","date":1614756213,"dir":"post/2021/","id":"eced95e5f301a8340e83d81d3c0d5c0d","lang":"ja","lastmod":1614756213,"permalink":"https://blog.johtani.info/blog/2021/03/03/phrase-query-in-japanese/","publishdate":"2021-03-03T16:23:33+09:00","summary":"Azure Cognitive SearchにはOData式という書式で条件が書ける仕組みがあります。 ODataは検索条件（$filter）やソート条件（$orderb","tags":["azure search","elasticsearch"],"title":"OData式と日本語の検索(NGram)とフレーズ検索"},{"contents":"自宅の環境がいろいろと変わったのですが、書いていなかったので更新版です。 前回のブログ(2020/09)、前々回のブログ(2020/03)はそれぞれリンクをたどってください。\n現状のデスクトップはこんな感じ\nPC 別のブログにまとめましたが、Windowsメインに切り替えました。 ハードの話以外に、Windows OSに切り替えたときにいくつか入れたものもあります。 それは、移行のブログに少しだけ書いてあります。\nひさびさにWindowsに戻ってきていますが、だいぶ慣れました。 まぁ、それほど大したことをやってないというのもあるかもですが。。。\nメインPC以外にこれまでのmacをブラウジング用にサブディスプレイにつなぎ、マウスをLogicool Flowで行き来できるようにし、 キーボードはKVMスイッチで切り替えてやりくりしていました（最新環境はキーボードのところを参照してください）。\nAmazon | サンワダイレクト USB切替器 キーボード・マウス用 KVMスイッチ キーボード いくつかDIYしましたが、今はメインでSofle Keyboard v2を利用しています（Kochi Keyboardさんで購入できます）\nSofle keyboard v2を有線で使っていましたが、最近Bluetooth対応して無線化しました（その時のブログはこちら）。 ですので、PCとの接続の切り替えはキーボード上で特定のキーの組み合わせを押すことで、切り替えられるようになっています。 KVMとは異なり、Bluetoothの接続が切り替わるのにタイムラグがある＋どこにつながっているのか？というのがわからないので、想定していないところでキーが入力されていることがあります。 これは、何とかしたいかもなぁと考えてはいるところ。\nマイク＆オーディオインターフェース 基本的に自宅でリモート作業をしています（ありがとうございます）。 なので、ミーティングもオンラインです。 となるとやはり、音がいいほうがお客さんにも喜ばれるかなぁと。 2020年3月時点ではSAMSONのGoMicを利用していました。 これもいい音なのですが、大きいマイクでもいいかなと。 あとは、ほかの使い道もあるかも？ということで、オーディオテクニカのマイク（＋ポップガード）とフォーカスライトのオーディオインターフェースに変えてみました。 自分は実感ないですが、きっと役に立っていると思いますｗ\nAmazon | audio-technica サイドアドレス コンデンサーマイクロホン AT2050 | コンデンサ | 楽器 Amazon | AUDIO-TECHNICA AT-PF2 ポップフィルター | マイクアクセサリ | 楽器 Amazon | Focusrite フォーカスライト オーディオインターフェイス 2イン/2アウト 24bit/192kHz Scarlett Solo (3rd Gen) ステッカー付きセット 【国内正規品】 | 楽器・音響機器 | 楽器 ディスプレイ 以前は、MacBookProの16インチで、メインディスプレイの下に2枚目のディスプレイも兼ねて開いて利用していました（前回のブログ参照）。 自作PCに切り替えたので、ディスプレイがなくなってしまうので、同じような大きさのモバイルモニターを利用しています。 今のところは据え置きになっていますが、持ち運べるので、ほかの部屋や外出時にも使えるんではないかなと。 ディスプレイの足などはないので、邪魔にもならず便利ですね。\nAmazon | モバイルモニター モバイルディスプレイ 4K 15.6インチ cocoparスイッチ用モニター 非光沢IPSパネル 薄い 軽量HDRモード/FreeSync対応/ブルーライト機能 3840x2160 UHD/USB Type-C/標準HDMI/mini DP/カバー付3年保証付 | cocopar | ディスプレイ 通販 音楽再生環境 サブディスプレイにサンダーボルトディスプレイを使用していたので、Mac Miniを接続していましたがサンダーボルトディスプレイには退役してもらいました。 それに伴って、Mac Miniも別の場所に移動しました。音楽再生環境にラズパイ４を復活させました。 以前購入したセットについていたケースではファンの音が気になっていたので、ヒートシンク型に変えました。 結構重いですが、冷えてそうです。\nAmazon | Geekworm Raspberry Pi(ラズベリーパイ) 4 B 用アーマー金属ケース パッシブ冷却/シェル熱放散 ラズベリーパイ4 コンピュ ータモデルB適用 (アーマーケース（ファン無し）) | Geekworm | 冷却パーツ・ファン 通販 Webカメラ カメラ自体に変更はないですが、付属品をいくつか。 Webカメラではないカメラもつけてみたいなと思い、モニターアームにカメラを付けられるものを付けてみました。 ただ、おっさんの顔をきれいに映してもなぁという結論に至ったので、Webカメラが乗っかっています。。。 あとは、デスクトップPCになり、カメラのケーブルだけではPCまで届かなくなってしまったのでUSB Type-Cの延長コードを買ってみました。実はこれ2本目ですが。。。 スタンディングデスクの昇降でケーブルに負荷がかかってしまったことがなんどかあり、1本目の延長コードは接触が悪くなってしまいました。。。時々外したりしていて、ケーブルの配置がおかしいときがあるので、気を付けるようにしています。\nAmazon | 長尾製作所 モニターアーム用 VESA カメラ＆マイクマウント NB-MV001MH | 長尾製作所 | モニタアーム\u0026amp;スタンド 通販 Amazon | iVANKY USB Type C 延長ケーブル USB 3.1 Gen 2(4K@60Hz/1.0m/オス－メス)10Gbps高速データ転送 3A急速充電 usb-c 変換 Huawei MateBook13, iPad Pro11, Nintendo Switch, MacBook等対応 | IVANKY | USBケーブル 通販 照明 裸の蛍光管だったのですが、リモコンで点灯したり、照度を変えられるようにしたかったので、 パナソニックの照明に変えました。\nAmazon | パナソニック LEDシーリングライト 調光・調色タイプ リモコン付 6畳 3, 699lm HH-CD0620AZ 【Amazon.co.jp限定】 | パナソニック(Panasonic) | ホーム＆キッチン 変えたのはよかったのですが、部屋が長細い＋Webカメラの位置（自分から見て左にカメラを置いて、部屋の奥への画角？になっている）のせいで、右半分の顔が暗くなる場合がありました。 幸い、右にはスチールラックが組んであるので、そこにつけられる照明を購入して女優ライトみたいな感じで使っています（頻繁ではないですが）\nAmazon｜ルミナス メタルラック用 LEDライト 磁石で簡単設置 連結可能 幅60cm 昼白色 LED60R-N｜メタルラックパーツ オンライン通販 フットレスト 昨年3月くらいに配置して、座っているときに足を置くのに便利に使っていました。 が、1台だと幅が足りないので最近2つ目を購入して並べて使っています。 片足ずつ載せられるのは便利ですね（基本ガニ股なので。。。）。\nAmazon | サンワダイレクト フットレスト スチール製 角度10° 幅40×奥行30cm 足置き台 100-FR011 | フットレスト | 文房具・オフィス用品 ということで、最近はこんな環境で仕事をしています。 当分これで更新しないんじゃないかなぁ。 （サブディスプレイが左に寄っているので、局面ディスプレイが気になっているところですが。。。）\n","date":1614246182,"dir":"post/2021/","id":"fcb0105fa6b5777a133f247784b9d930","lang":"ja","lastmod":1614246182,"permalink":"https://blog.johtani.info/blog/2021/02/25/update-working-facility/","publishdate":"2021-02-25T18:43:02+09:00","summary":"自宅の環境がいろいろと変わったのですが、書いていなかったので更新版です。 前回のブログ(2020/09)、前々回のブログ(2020/03)はそ","tags":["misc"],"title":"自宅の作業環境(2021/02)"},{"contents":"Azure Cognitive SearchにSuggestやAutocompleteの機能があるのを見つけたので、どんな挙動なのかを調べてログとして残しておきます。\n公式ドキュメント 日本語で公式ドキュメントが公開されています。使い方や流れについてはこちらをまずは見れば使えると思います。\n本ブログでは、ざっくりとした機能の紹介と内部がどんな挙動をしていそうか？、日本語だとどういう感じになるのか？という点を紹介しようと思います。\nどんな機能？ 検索窓でよく、キーワードを入力しているときに検索キーワードの候補が表示されることがあります。 このキーワードの候補を表示するための機能が今回紹介するSuggesterと呼ばれる機能です（日本語の公式ドキュメントでは「先行入力エクスペリエンス」）。 Suggesterには、以下の2つの機能が用意されています。\nAutocomplete：キー入力しているときに、入力されている文字列で始まる単語で、検索できるもの（転置インデックスに登録されている単語）をリストで返す機能 Suggestion：入力した文字列で始まるキーワードを含む、元のデータを返す機能 利用方法 Suggesterの機能を利用するにはインデックスに設定を追加する必要があります（新規、既存どちらでも可）。 ただ、既存のインデックスに設定を追加した場合、内部にすでに存在するドキュメント（データ）については、このSuggesterのデータは作られません。 ですので、既存データを再度登録しなおすといった作業が必要となるので注意が必要です。\n本ブログでは、いくつかAzure Cognitive Searchのサンプルのリクエストが出てきます。Visual Studio CodeのREST Client Extensionの書式となります。拡張機能の簡単な紹介は昨年のブログをご覧ください。\n設定編 Suggesterの設定では、主に以下の2つを設定する必要があります。\nname: suggesterの名称。クエリ時に指定します。 sourceFields: 入力データのもととなるフィールド名。 String型のみ指定可能。また、Azureで用意されたアナライザーだけが利用可能です。自分で用意するカスタムアナライザーは利用できないので注意が必要です（制限についてはこちら）。 今回使用するサンプルのインデックス設定は次の通りです。\nインデックス作成のリクエスト（@host、@api-keyはご自身のものに置き換えてください。）\n## 設定 @host = 名前.search.windows.netと記載 @api-key = APIキーを入力 ### Create index with suggester POST https://{{host}}/indexes/?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;name\u0026#34;:\u0026#34;suggester-test\u0026#34;, \u0026#34;fields\u0026#34;:[ { \u0026#34;name\u0026#34;:\u0026#34;id\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;Edm.String\u0026#34;, \u0026#34;key\u0026#34;:true, \u0026#34;searchable\u0026#34;:false }, { \u0026#34;name\u0026#34;:\u0026#34;name\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;Edm.String\u0026#34;, \u0026#34;searchable\u0026#34;:true, \u0026#34;analyzer\u0026#34;:\u0026#34;ngram_analyzer\u0026#34; }, { \u0026#34;name\u0026#34;:\u0026#34;category\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;Edm.String\u0026#34;, \u0026#34;filterable\u0026#34;:true, \u0026#34;facetable\u0026#34;: true } ], \u0026#34;suggesters\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;name_suggester\u0026#34;, \u0026#34;searchMode\u0026#34;: \u0026#34;analyzingInfixMatching\u0026#34;, \u0026#34;sourceFields\u0026#34;: [ \u0026#34;name\u0026#34; ] } ] } 公式ドキュメントのサンプルでは日本語がないので、日本語のデータも入力しています。\nデータ登録リクエスト\n### Index data POST https://{{host}}/indexes/suggester-test/docs/index?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;value\u0026#34;: [ { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Microsoft Office\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;microsoft\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Microsoft Azure\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;microsoft\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;3\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;GitHub Enterprise\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;github\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;4\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;GitHub dot com\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;github\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;5\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Bluetooth Mic\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;hardware\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;6\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;東京スカイツリー\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;japanese\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;7\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;東京タワー\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;japanese\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;8\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;東京特許許可局\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;japanese\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;9\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;グランメゾン東京\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;japanese\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;10\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;東京都庁\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;japanese\u0026#34; } ] } 以上が事前準備です。データ登録時に内部でSuggester用のデータを内部で生成しているようです（公式ドキュメント）。\nクエリ編 最初に説明しましたが、Suggesterの中ではAutocompleteとSuggestionという2種類の機能が用意されています。それぞれについて例をもとに説明していきます。\nAutocomplete API 検索窓に入力された文字を元に、前方一致でどのような単語で検索できるか？という候補を表示するための機能です（2単語も対応していますが今回は省略。APIの仕様はこちら）。\nたとえば、micという文字が入力されているところでAutocomplete APIを呼び出す時は、次のようなリクエストです。searchというパラメータに入力値を与えます。suggesterNameはインデックス作成時につけた名前になります。\nPOST https://{{host}}/indexes/suggester-test/docs/autocomplete?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;mic\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } レスポンスとして、次のようなJSONが返ってきます。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;microsoft\u0026#34;, \u0026#34;queryPlusText\u0026#34;: \u0026#34;microsoft\u0026#34; }, { \u0026#34;text\u0026#34;: \u0026#34;mic\u0026#34;, \u0026#34;queryPlusText\u0026#34;: \u0026#34;mic\u0026#34; } ] } サンプルデータとして登録したデータにcategoryというフィールドを入れていました。 Autocompleteは条件を絞り込んで結果を返すこともできます。 filterにODataの書式で条件を書けます。 categoryフィールドにmicrosoftが設定されているデータだけを取得するということができます。\n### Autocomplete with filter POST https://{{host}}/indexes/suggester-test/docs/autocomplete?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;mic\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34;, \u0026#34;filter\u0026#34;: \u0026#34;category eq \u0026#39;microsoft\u0026#39;\u0026#34; } レスポンスはこちら。先ほどとは違い、micというデータは返ってきていません。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;microsoft\u0026#34;, \u0026#34;queryPlusText\u0026#34;: \u0026#34;microsoft\u0026#34; } ] } 英語の場合、「単語」の単位は字面の通りです。スペースで単語が区切られているのでわかりやすいです。 日本語の場合は普通の人には少し想像しにくいです。 東京という文字を入力してみます。\n### Autocomplete in Japanese POST https://{{host}}/indexes/suggester-test/docs/autocomplete?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;東京\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } すると返ってくるのは以下の通り「東京」だけになります。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;東京\u0026#34;, \u0026#34;queryPlusText\u0026#34;: \u0026#34;東京\u0026#34; } ] } 入っているデータは「東京スカイツリー」、「東京タワー」などです。 普通に考えると、これらがそのまま返ってくると思うかもしれませんが、違います。\nこれは、Suggesterの元となるフィールドのAnalyzerの挙動によります。 今回のインデックスのnameフィールドのanalyzerにはja.luceneです。これは、日本語用のアナライザー（Kuromoji）になります。いわゆる形態素解析器で日本語の文字列を「単語」に分割します。 英語についてはスペース区切りで分割しますが、日本語についてはKuromojiが内部の辞書とアルゴリズムに基づいて単語に分割してくれます。 Azure Cognitive Searchでは、Analyzerの挙動を確認するためのAPIも用意してあるので実行しみると、\n### Autocomplete in Japanese POST https://{{host}}/indexes/suggester-test/analyze?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;text\u0026#34;: \u0026#34;東京スカイツリー\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;ja.lucene\u0026#34; } このような結果が返ってきます。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;東京\u0026#34;, \u0026#34;startOffset\u0026#34;: 0, \u0026#34;endOffset\u0026#34;: 2, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;スカイ\u0026#34;, \u0026#34;startOffset\u0026#34;: 2, \u0026#34;endOffset\u0026#34;: 5, \u0026#34;position\u0026#34;: 1 }, { \u0026#34;token\u0026#34;: \u0026#34;ツリー\u0026#34;, \u0026#34;startOffset\u0026#34;: 5, \u0026#34;endOffset\u0026#34;: 8, \u0026#34;position\u0026#34;: 2 } ] } ja.luceneのAnalyzerによって、3つの単語に分割されているのがわかります。 Autocomplete APIの実行結果も、このAnalyzerによって分割された単語をもとに、候補となる単語を前方一致で検索して結果を返しているのです。 ですので、「東」と入れても「東京」が返ってくるのがわかります。 一方で、「東京ス」と入力した場合は次のような結果となります。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;スカイ\u0026#34;, \u0026#34;queryPlusText\u0026#34;: \u0026#34;東京スカイ\u0026#34; } ] } これは、autocompleteModeと呼ばれるパラメータの挙動となります。 デフォルトでは、oneTermという設定で、最後の単語（例の「東京ス」の場合は「東京」「ス」と区切られるので「ス」という文字を単語とみなす）にマッチする単語（例では「スカイ」）が返ってきます。 queryPlusTextについては、入力された文字にtextで返ってきた単語をくっつけたものが取得できます。\n英語であれば、スペースで区切られており、単語が切れているのが簡単にイメージできますが、日本語の場合は少し違和感が出るかと。\nこのように、入力された文字が含まれる「単語」を基本的に返す動作をするのがAutocomplete APIです。\nSuggest API では、もうひとつのSuggest APIはどういったものでしょうか？ autocomplete APIに似ていますが、返ってくるデータが登録されたデータそのものになります。\nたとえば、micという文字列を入力とした場合、\nPOST https://{{host}}/indexes/suggester-test/docs/suggest?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;mic\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } 次のような結果が返ってきます。Autocompleteの時は単語でしたが、こちらは入力データがそのまま返ってきています。 入力データの中にmicで始まる単語が含まれたものが候補となっています。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.text\u0026#34;: \u0026#34;Bluetooth Mic\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;5\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;Microsoft Office\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;Microsoft Azure\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;2\u0026#34; } ] } 日本語の場合、Autocompleteとは異なり、その単語を含むものがサジェストされるので、「東京」をsearchに指定すると「東京」を含むデータが出てきます。\n### Suggest in Japanese POST https://{{host}}/indexes/suggester-test/docs/suggest?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;東京\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } レスポンスはこちら。単語を含む元の文字列が返ってきます。ここまでは違和感はありません。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.text\u0026#34;: \u0026#34;東京タワー\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;7\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;グランメゾン東京\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;9\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;東京都庁\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;10\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;東京スカイツリー\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;6\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;東京特許許可局\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;8\u0026#34; } ] } では、「東京」「特許」という2つの単語をスペースで区切ったものが入力されたとするとどうでしょう？\n### Suggest in Japanese POST https://{{host}}/indexes/suggester-test/docs/suggest?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;東京 特許\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } スペースがありますが、内部処理では形態素解析器が分割した後でこの単語の順番で出てくるものを探しているので、出てくることになります。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.text\u0026#34;: \u0026#34;東京特許許可局\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;8\u0026#34; } ] } なお、このSuggestのAPIは、単語の語順を気を付ける必要があります。 「特許」「東京」と順序を入れ替えたスペース区切りの場合は、\n### Suggest in Japanese POST https://{{host}}/indexes/suggester-test/docs/suggest?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;特許 東京\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } 結果は返ってこないです。おそらく内部では、フレーズクエリで、最後の単語だけを前方一致で検索するような仕組みが動いているのだと思われます。 スペースで区切られてはいるが、順序があるので少し違和感を感じるかもしれません。英語だとフレーズの部分のイメージは沸きやすいのですが。\n短い文章のデータ（例：本のタイトルやランドマーク名など）では、このSuggestAPIを利用するとデータそのものが返却されるので、便利かもしれません。\nまとめ ということで、Azure Cognitive SearchのSuggesterの簡単な紹介でした。APIのページにはそのほかのパラメータについても説明があるので、使ってみようと思う方は目を通していただくのがよいかと。\n今回のブログは裏の仕組みがどんな感じなのか？を想像しながらAPIについて調べた形になります。日本語の場合に、少し違和感を覚える人もいそうだろうなということでブログを書いてみました。 今回は書いていませんが日本語でAutocompleteをやりたい場合は、読み仮名でも漢字が表示されるほうがよいという場合もあると思います。 その場合は、用意されている機能では難しいので、独自実装するといった方法になりそうです。 英語や、読みを利用しない場合は、挙動を理解していれば役に立つ場面もありそうです。\n","date":1612515120,"dir":"post/2021/","id":"931b2ebd9bfaeb5dcf1973e724a1f8d0","lang":"ja","lastmod":1612515120,"permalink":"https://blog.johtani.info/blog/2021/02/05/autocomplete-and-suggest-on-azure-search/","publishdate":"2021-02-05T17:52:00+09:00","summary":"Azure Cognitive SearchにSuggestやAutocompleteの機能があるのを見つけたので、どんな挙動なのかを調べてログとして残しておきます。 公","tags":["azure search"],"title":"Azure Cognitive Searchでオートコンプリートやサジェストをしてみる"},{"contents":"オライリー・ジャパンから出ている「コンピュータシステムの理論と実装」を読み始めたのでメモを取ることに。\n原著はオライリーじゃないのかというのが、まず最初の気づきでした。\nNANDからテトリス コンピュータのハードウェアからOS、さらにその上で動くアプリケーションまでを動作させるというのを少しずつやっていくという書籍みたいです。 イントロと1章を読みましたが、1章では論理回路の話でした。\n実際に物理的に作るわけではなく、シミュレーターなどのソフトウェアが用意されており、 そのソフトウェア上で動くものを作っていくことになります。 ソフトウェアのために専用のサイトが用意されて、ダウンロードもできるようになっているので、実際に手を動かしながら理解を進める感じになるのかと。\n目次を見ていただくとわかりますが、すごく幅が広いです。 1年で読み終われるかなぁ？まぁ、のんびりやっていこうかなと。\n用意されているソフトウェアなどで便利だなと思ったのは、どの章からでも興味のある部分から始められるようになっているようです（まだ始めてなくて。。。） 内部ではすべてのパーツがそろえてあるけど、章ごとのプロジェクトでは、個別に自分で実装したものがあればそちらが動くという挙動のようです。\nということで、ちょっとずつやっていこうかなと。 ほんとにテトリス動くのかなぁ？\n","date":1612424444,"dir":"post/2021/","id":"aa61b4543e8a7c67fccabee27a6e99cd","lang":"ja","lastmod":1612424444,"permalink":"https://blog.johtani.info/blog/2021/02/04/reading-elements-of-computing-systems/","publishdate":"2021-02-04T16:40:44+09:00","summary":"オライリー・ジャパンから出ている「コンピュータシステムの理論と実装」を読み始めたのでメモを取ることに。 原著はオライリーじゃないのかというのが","tags":["輪読","Nand2Tetris"],"title":"「コンピュータシステムの理論と実装」を読み始めた #Nand2Tetris"},{"contents":"Corne使ってましたが、数字キーがあるとどうなのかな？というのがやはり気になって。 そこに、Kochi KeyboardさんからSofle Keyboard v2というのが発売されたので組み立ててみました（去年末に）。また、先日Corne Light v2のBLE化に成功したので、Sofle keyboard v2のBLE Pro Micro + LPME-IO化にもチャレンジしてみました。\nSofle keyboard v2 ビルドログ 自分で書くよりもすごくよくできたビルドログがKochi Keyboardさんで公開されているので、そちらを参考にしてください。\nSofle Keyboard v2ビルドガイド すごく詳しく書いてあります。なので、こちらを見ていただければ問題ないかなと。 ただ、自分ではいくつか失敗したので自戒を込めてログを残しておきます。\nOLED用のジャンパをはんだ付けし忘れ 単にビルドログを流し読みしたツケが。。。 Sofleは同じ基盤を左右で利用します。なので、右手と左手で、同じ基盤の表と裏を利用します。 OLED用のジャンパする部分は両面に用意されていますが、はんだでジャンプするのはPro Microが実装される面となります。\n両面にジャンプ用のランドがあるとは気づかないで、左手の裏面をジャンプしてすべて実装し終わってから、OLEDが表示されないことに気づいてしまいました（ビルドログ用にと思って撮った写真に証拠が残ってますねｗ）。。。\nということで、またはんダッシュ太郎くんのお世話になりました（Pro Microを外してジャンプしました）。本当に有能ですよ彼は。。。\nAmazon | サンハヤト はんだシュッ太郎NEO 45Wタイプ HSK-300 | ハンダゴテパーツ ソケットのはんだ付け甘すぎ あとは、慣れてきたなぁと思っていたところに天罰が。 キースイッチのソケットを付けるの慣れてきたなーと思って、サクサクとつけていたのですが、 いざキースイッチをはめるときにボロボロとはがれていきましたｗ 半分くらいは外れたんじゃないかな？ちゃんとはんだ付けした後にピンセットなどで軽くいじってみるべきですね。。。\n滑り止め 利用しているキーキャップがOEMプロファイルということもあり、数字キー側を少し高くしたほうが入力しやすいです。そのために、少し大きめのソフトクッションを購入しました。\nAmazon | WAKI ソフトクッションCN-020 クリアータイプ: 産業・研究開発用品 上の左右の角に貼り付けると、がたつきがあったので少しずらして貼り付けて安定させています。 OLEDのプレートの部分を押すと手前が浮き上がってしまいますが、そこにはキーはないので問題ないかと。\nということで、毎回気づきがあって面白いですね。。。\nSofle keyboardのBLE化 Corne LightのBLE化がうまくいったので、もうひとセットのぎけす屋さんから購入しました。 BLE Micro ProやLPME-IO、電池基盤などについては前回のCorneのBLE化の記事を参照してください。\nハードウェア編 Sofle keyboard v2は残念ながらせきごんさんの公式ページの対応キーボード一覧には掲載されていません。 が、Sofle KeyboardのGitHubのページには次のような記載があります。\nSofle is 6×4+5 keys column-staggered split keyboard with encoder support. Based on Lily58, Corne and Helix keyboards.\n基盤の写真のPro Micro周りもCorneに似ています。 ということで、おそらくBLE + LPME-IO化が行けるのでは？と予測して作業に取り掛かりました。\nPCBの確認 Sofle Keyboardの基盤の設計図はGitHub上に公開されています。 この設計図を見る方法をまずは探しました。\n自作キーボードについて探すにはまずはサリチル酸さんのブログ「自作キーボード温泉街の歩き方」です。 回路図なので、設計ノウハウあたりのカテゴリーにあるだろうと探したところ見つかりました。\n（設計者向け）オートルーターを使って睡眠時間を確保しよう 配線のテクニックというブログですが、回路図を書くためのツールKiCadについて記載があります。 このブログにある以下の記事をもとに、KiCadのインストールや使い方をちょっとだけ勉強しました。\nfoostanさんのMeishi Keyboardの開発者向けガイド(JP) KiCadことはじめ KiCadの中の回路図エディタ「Eeschema」でSofle keyboardのPCBのフォルダを開くと回路図が開きます。 実際の基盤になる前に、Pro Microのどの足と何がつながっているのか？などが見て取れます。 前回のCorneのBLE化でLPME-IO対応したときに、学習しましたが、 TRRSの足とPro MicroのSDAとSCLをつなぐことで、LPME-IOを使うことができるようになるというのがわかっています。 それをもとに回路図を見たところ、以下のような記述がありました。\nどうも、JP9とJP10というはんだでジャンプする場所を用意してくれていそうです。 先を見越した設計本当にありがたいですね。\nJP9とJP10のはんだ付け 今ついているPro Microを外し（またはんダッシュ太郎が活躍）、基板を確認したところ対象の個所がありました。下の写真は左手の裏側です。\nこれらをはんだでジャンプします。\n右手は表側にあるので、Pro Microを外した後にジャンプしました。 左手は裏側です。 Corne Lightでは、Pro Microの足から導線を使ってTRRSの足につなぎましたが、今回はすっきり実装できました。 ジャンプした後はBLE Micro Proをはんだ付けします（はんだ付けせずに動作確認しようとしましたが、うまく通電しなくてちゃんと動かなかったです）。\nLPME-IOのジャンパ LPME-IOのGitHubページにあるように、利用するキーボードによって、いくつかはんだでジャンプする必要があります。 これは、BLE Micro Pro用のConfigファイルを見て、対象を決める必要があります。 が、Sofleは事前に用意されたものがありません。\nConfigファイルの生成 用意されていないConfigファイルが、QMKの設定ファイルから生成することができるようななっています（本当に感謝しかないですね）。 手順はBLE Micro Proのドキュメントにありました。\n新しいキーボード用の設定を作成する - QMK用の設定から変換する この変換スクリプトで３種類のconfig（右手用、左手用、LPME-IO用）が生成されます。 私の場合はLPMEを利用するので、lpmeという名前の入ったconfigを利用します。 中を見るとcol以下の記載が以下の通りだったので、8からDをジャンプします。\n\u0026#34;col_pins\u0026#34;:[18, 17, 16, 15, 14, 13, 18, 17, 16, 15, 14, 13], ここまででハードウェア側が終了です。\nファームウェア・設定編 ハードウェアの実装が終わったので、ファームウェアおよびアプリの設定です。\nファームウェアのセットアップ キーボードをUSBで接続し、BLE Micro Pro Web Configuratorのページにアクセスすると、 セットアップ初期画面が出てきます。\n公式ページの「キーボードを選ぶ」を参考にファームウェア、アプリのアップデートを行います。 「設定ファイルの書き込み」のタイミングでupload your ownを選択すると、ファイル選択画面が出てくるので、変換スクリプトで生成したJSONファイルを選択します。 このとき、Mas Storage Classとしてキーボードが認識されている状態だとうまく書き込めなかったので、キーボードのドライブを「取り出し」してからファイルをアップロードしました。\nキーマップの設定 BLE Micro Proのアプリが設定をきちんと認識すれば、あとはWeb Configuratorでキーマップの設定が可能になります。 これまた、残念なことに、BLE化する前のキーマップをJSONファイルで保存してなかったので（泣きそうｗ）、QMKのkeymap.cのファイルをもとに、ブラウザ上でがんばって設定しましたｗ また、新しい設定ではBLE関連のキーをマッピングとして追加しています。\nBluetooth接続 あとは、接続確認です。 MacとWin２台と接続するのですが、Win→Mac→Winの順番でBluetoothの接続をやっていたら、なぜか３つ目のWindowsで接続候補に出てくるけど、接続しようとするとタイムアウトをするという現象に遭遇しました。 MacのBluetoothの設定を一旦削除してから、Win→Win→Macの順番でペアリングしたところ問題なく接続できました。ただ、これが本当の対処なのかどうかは不明です。３番目だと接続できなかったWindowsマシンは再起動もしてみたのですがダメでした。この辺よくわかってないなぁ。\nまとめ ということで、Corne Lightに引き続き、Sofle Keyboard v2もBLE＋LPME化に成功しました。 導線なども使わずにLPME対応ができたので見た目もすっきりしています。 これで、KVMスイッチだと２台までしか切り替えできなかったのが、３台をひとつのキーボードで操ることができるようになりました。 だいぶ楽になりそうな予感がしています。\nまだ、完ぺきではないので、次のような対応をやっていく予定です。\nロータリーエンコーダー対応：BLE以前はQMKのkeymap.cの中でロータリーエンコーダーの動作を記述していたので、BLE Micro Proでどうやるのかを調べたい。encorder.jsonというファイルがあったのでその辺ではないかな？ OLED対応：Corne Lightの時と同様に、OLEDが点かなくなったのでこの辺りを調べたい。 ということで、とりあえずキー入力するのには困らない程度にはできたので、より便利にする方法を時間を見つけて模索する感じになりそうです。 あと、KiCadも面白そうなのでこっちもちょっと触ってみたくなってきたかも？\n","date":1612106122,"dir":"post/2021/","id":"d95522c691013bfe66dd46ded85a98ed","lang":"ja","lastmod":1612106122,"permalink":"https://blog.johtani.info/blog/2021/02/01/apply-ble-to-sofle/","publishdate":"2021-02-01T00:15:22+09:00","summary":"Corne使ってましたが、数字キーがあるとどうなのかな？というのがやはり気になって。 そこに、Kochi KeyboardさんからSofle Keyboard v","tags":["DIYキーボード","misc"],"title":"Sofle v2を組み立てて、BLE+LPME-IO化してみた #DIYキーボード"},{"contents":"メインマシンとMacは下記のサンワサプライのUSB接続のKVMスイッチを使っていますが、もう一台ノートPCがありここに接続しているCorne（初めてのDIYキーボード）が長いUSBケーブルでつながっています。\nAmazon | サンワダイレクト USB切替器 キーボード・マウス用 KVMスイッチ 時々必要になって、デスクにキーボードだけ引っ張ってきて利用するのですが、ケーブルの取り回しがまぁ邪魔で。。。 BLE対応（BLE Micro Pro）をしてみようかなということに。\nBLE + LPME-IO対応 分割キーボードをBLE対応(それぞれにBLE Micro Proを実装)すると、キーボード間のつながりがいまいちになることもあるというのをちらほら見ていたので、BLE Micro Pro + LPME-IOという構成で、 Corneのキーボード同士はTRRSケーブルで接続し、PCとCorne間をBluetoothで接続する構成にしてみました。\nBLE Micro Proについては、公式ドキュメントにいろいろと記載があります。\n材料 ということで、材料は以下の通り。セット販売は売り切れていたので、個別に購入しました。 コンスルーと電池以外は１つずつです。\nBLE Micro Pro(のぎけす屋) x 1 LPME-IO(のぎけす屋) x 1 BLE Micro Pro用電池基盤(遊舎工房) x 1 コンスルー(Kochi Keyboard) x 4 CR1632ボタン電池（近所のスーパー） x 2 実装 まずは、それぞれ組み立てです。\n電池基盤 以下の記事を参考にはんだ付けしました。\nQiita: 自作キーボードビルドログ：その２「ErgoDash」無線化対応 ハードウェア編 - 電池基盤の組み立て・半田付け yfuku docs - Claw44 / 無線接続について 注意点は以下の通りです。\n基盤が軽いので固定が必要（マスキングテープでマットに貼り付けたらましになった） 電池ホルダーが変形しやすい（設置して、足を折るために上から押さえつけたら、本体が曲がってしまった。。。） 部品が細かいので大変（老眼だから？） BLE Micro Proとの接続は参考にしたyfuku docsにある方法（余っていたピンヘッダを１本ずつ使ってはんだ付け）を採用しました。 （パッと見大丈夫そうだったので電池基盤の裏に絶縁テープは貼ってないです貼ってないです）\nBLE Micro Pro（もげ対策） BLE Micro Pro自体はコンスルーをはんだ付けするだけですが、今回はもげ対策として、ダイソーで買ってきたグルーガンで ちょっとだけ補強してみました。 初グルーガンだったので不細工だけど。これ難しいな。\n効き目あればいいけど？\nLPME-IO対応 いくつかのジャンパをはんだでブリッジ まずは、LPME-IOのREADMEのページの導入手順を読み、いくつかのピンをジャンプしました。 せきごんさんのBLE-Micro-Proのリポジトリに、CorneのLPME用コンフィグファイルを見ると、ジャンプするのは20, 19, 18, 17, 16, 15に対応している、F,E,D,C,B,Aの６つです（写真撮り忘れた。。。）。\nTRRSのI2C対応（って言い方であってるのかなぁ？） ジャンプだけでいけないかなぁ？と思いましたがダメでした（USBでつないでみたけど、左手（BLE-Micro-Proがついている側）だけ入力可能です。\nBLE Micro Proの公式サイトにLPME-IOについても記載があります。 実績のあるキーボード一覧にCorne Lightの記載もあったので、試してみようと思ったのが発端です。\nただ、LPME-IOの欄に注意書きが。\n*LPME-IOを使うには改造が必要\nまた、一覧の最初にも記載があります。\nLPME-IOを使うにはキーボードの左右の有線通信がI2Cである必要があります。とくにOLEDに対応しているキーボード等の場合は、I2C用のピンをTRRSジャックに接続する改造を施すことでI2C化できる場合があります。\nまだ、自作キーボードの仕組みをがっつり理解しているわけではない初心者なので、まぁ、ちょっとわからないかなと。。。 BLE Micro Proのはじめにのページを見ると、 Self Made keyboard in JapanのDiscordに専用チャネルがあるようで、過去ログを検索してみました。 検索したところ、Corneの場合Micro ProのSDA(写真の青い線)とSCL(写真の黄色い線)（参考：Corneの基盤の図）をそれぞれ、TRRSの２つのピンに接続する必要がありそうだというコメントがありました。\nCorne Cherry v2の場合は、接続するためのショートカットが用意されていましたが、Corne Light v2だと見当たりませんでした。 ということで、線を使って物理ショートカットしました。ちなみに、ショートカットは両手ともに必要なようです。\nUSB-Cで接続テスト 上記対応が終わって、基板に設置してUSB-Cケーブルで接続したところ、外部ドライブとして見えるようになりました。\nキーマップの書き換えとか 公式ドキュメントのBLE Micro Pro Web Configuratorを使うの手順通りに書き込みを行っていくと、特に問題なく接続できました。 便利すぎですね。キーマップの変更は、これまでのCorneのキーマップJSONファイルからコピペして書き込んだだけです。 （この後、BLE用のキーマップを書き足すためにもう一度変更しますが）\nLPME-IO対応なので、Micro Proは片側しかないので、書き換えも楽々でした。\nBLEで接続テスト 今回の目的だったWindowsにBluetoothで接続できるようにしてみました。 最初はサリチル酸さんの記事を見ていたのですが、キーコードがちょっと変わっているようでした。\nで、よくよく見ると、BLE Micro Pro Web ConfiguratorにBLE関連のキーも用意されているじゃないですか。。。\nBLE関連のキーを割り当てた後は、USBをオフにして、Bluetoothをオン、BTNEWで新しくペアリングするようにすれば接続完了でした。\n課題 これまでと違い、すんなり実装ができましたがまだいくつか気になる点が。\n複数の機器とペアリングして切り替え Macともペアリングしてみようとしたのですが、切り替えがうまくいかないようで。。。 OLEDつけるにはどうするんだろう？ 左手側は電池が乗っているのですが、右手側はLPME-IOだけなので、上にOLEDを載せる余裕があります。 なので載せてみましたが点かないですね。ファームウェアを何かしないといけないんじゃないかな？調べないとなぁ。 という感じです。 まだちゃんと長時間使っていないので、他の問題点も出てくるかもしれませんが、まぁとりあえず使ってみてからかな。 うまくいくようなら、メインマシンにBluetoothモジュール追加してみるのもありかと考えているところです。\n調べながら、自分なりに対応してみましたが他にもいい方法とかあれば教えてもらえると助かります。\n","date":1610332951,"dir":"post/2021/","id":"4ad8239a37f641bcd17abeb96106314e","lang":"ja","lastmod":1610332951,"permalink":"https://blog.johtani.info/blog/2021/01/11/apply-ble-and-lpme-to-corne/","publishdate":"2021-01-11T11:42:31+09:00","summary":"メインマシンとMacは下記のサンワサプライのUSB接続のKVMスイッチを使っていますが、もう一台ノートPCがありここに接続しているCorne","tags":["DIYキーボード","misc"],"title":"Corne Light v2のBLE+LPME-IO対応 #DIYキーボード"},{"contents":"振り返りブログにも書きましたが、デスクトップPCを自作(DIY)しました。 組み立てたに使ったパーツのアフィリンクを貼っておきます。\n10月くらいにPC組もうと思って、組み上がったのは11月半ばでした。 最初はもうちょっと小さいPCにしようと思ってたのに気づいたらATXになってました。 パーツの選定の基準は以下のツイートです。影響されやすいなぁ。\nタワーってほど大きくなくていいと思いますが、NZXT H510 ぐらいの大きさは欲しいですね。https://t.co/s1c1fOnPyI\n単純に、スペースがないと組みにくいのと冷えにくい、買ってきたものがやっぱりこれだと入らない、というリスクがかなり減るので。\n\u0026mdash; さぼてん（さぼ福）🌵 (@cactusman) October 9, 2020 今年3台作りました。ノートPC使えない体になります。 pic.twitter.com/8zDmeRwNkS\n\u0026mdash; miyake | ZEN (@kazuyukimiyake) October 9, 2020 白いケースいいなぁという感じで、ケースとCPUクーラーが決まったんで、ググってこちらのHAKKAさんのYouTube見ながら妄想してました。 パーツがなかなか揃わなくて。 そして、PCが光るのどうなの?と思ってたのに、気づいたら光ってました(なぜ?)。\nグラボがない状態(CPU内蔵GPU)で12月頭までは動作してました。\n購入自体はTSUKUMO、ビックカメラオンライン、パソコンSHOPアーク、イートレンドオンラインショップでオンラインで購入しました。\nPCケース Amazon | NZXT H510i White CA-H510I-W1 CS7946 | NZXT | PCバッグ・ケース・スリーブ 電源 Amazon | NZXT E850 デジタル電源ユニット 80 Plus Gold 認証 [ 定格 850W 出力 ] NP-1PM-E850A-JP NP-1PM-E850A-JP SP947 | NZXT | パソコン・周辺機器 通販 マザーボード Amazon | ASRock AMD Ryzen 3000シリーズ CPU(Soket AM4)対応 X570チップセット搭載 ATX マザーボード X570 Steel Legend | ASROCK CPU AMD Ryzen 4750G\nCPUクーラー Amazon | NZXT KRAKEN Z63 簡易水冷CPUクーラー 液晶モニタ搭載 RGB対応 280mm RL-KRZ63-01 FN1441 | NZXT | CPUファン 通販 メモリ Amazon | G.SKILL 128GB（4 x 32GB）Trident Z NeoシリーズDDR4 SDRAM 3200MHz PC4-25600デスクトップメモリモデルF4-3200C16Q-128GTZN | G.Skill | メモリ 通販 SSD Amazon | Seagate FireCuda 520 M.2 1TB PCIe Gen4x4 内蔵SSD M.2 2280 3D TLC ZP1000GM3A002 | SEAGATE グラボ Amazon | GIGABYTE NVIDIA GeForce RTX3080搭載 グラフィックボード GDDR6X 10GB ホワイトモデル【国内正規代理店品】GV-N3080VISION OC-10GD | 日本ギガバイト 拡張カード Amazon | ASRock 拡張インターフェースボード Thunderbolt 3 AIC R2.0 | ASROCK | インターフェースカード 通販 拡張カードは実は差し込んだら最初うまく動かなくてサポートに連絡しました。同じ構成の検証機を用意して解決方法を見つけてもらいました。しかも数日で。サイコーのエクスペリエンスでした!\n日本語でサポートしてもらえてしかも数日で解決してもらった。ASRockのサポートすばらしかったです！ https://t.co/8FasCInIqt\n\u0026mdash; Jun Ohtani (@johtani) December 8, 2020 その他 ケースのフロントパネルのUSB-Cポートを使えるようにするために。\nAmazon | Cablecc USB 3.1フロントパネルソケットType-E-マザーボード用USB 3.0 20ピンヘッダーオス拡張アダプター | cablecc | PCアクセサリ・サプライ 通販 最近のPCパーツはUSBでモニタリングできるみたいで、マザボのUSBポートが足りなかったので拡張しました。\nAmazon | マザーボードのUSB 9ピン 増設 内部用4ポートUSB2.0 HUB | ノーブランド品 | USBハブ 通販 白いケースだし、「映え」のために白いケーブルを。\nAmazon | Novonest 電源専用延長スリーブ 補助電源モジュラーケーブル 長さ300mm 6本1セット スリーブガイド24点セット付き 【SC304】 | ｎｏｖｏｎｅｓｔ | 電源ユニット 通販 組み立て中 手元にあったCPUでBiosアップデート(Ryzen 5000シリーズにしたかったから。まだできてないけど)。\n応急処置でBiosアップデートしてる pic.twitter.com/mXf2B5kwqB\n\u0026mdash; Jun Ohtani (@johtani) November 8, 2020 さーて、頑張るぞー pic.twitter.com/HmlGqREjmP\n\u0026mdash; Jun Ohtani (@johtani) November 13, 2020 さて、仮起動実験ですよと pic.twitter.com/5HP3cbs6SH\n\u0026mdash; Jun Ohtani (@johtani) November 13, 2020 きたきたー pic.twitter.com/4sL3ymecEo\n\u0026mdash; Jun Ohtani (@johtani) November 13, 2020 コネクター刺しまくらないと pic.twitter.com/Soye3lS4M9\n\u0026mdash; Jun Ohtani (@johtani) November 13, 2020 完成はこんなかんじ 初期構成\n組み上がったよー pic.twitter.com/sBwpvLsZh3\n\u0026mdash; Jun Ohtani (@johtani) November 14, 2020 グラボデプロイ\n設置完了してこんな感じ。なんかベンチマーク走らせるかなぁ。何がいいだろ pic.twitter.com/aZufAE9fJA\n\u0026mdash; Jun Ohtani (@johtani) December 4, 2020 グラボのおまけも付けてみた。\nまぁ、せっかくついてきたので取り付けてみました（グラボ下の光ってるパネル）。 pic.twitter.com/068IxaV1ps\n\u0026mdash; Jun Ohtani (@johtani) December 4, 2020 とまぁ、こんな感じでした。 メモリは多分使い切れないだろうなぁと思いながら、やってみたかったという感じです。。。\n","date":1609422526,"dir":"post/2020/","id":"64a421c2367372c3199c66a6420faf89","lang":"ja","lastmod":1609422526,"permalink":"https://blog.johtani.info/blog/2020/12/31/diy-pc/","publishdate":"2020-12-31T22:48:46+09:00","summary":"振り返りブログにも書きましたが、デスクトップPCを自作(DIY)しました。 組み立てたに使ったパーツのアフィリンクを貼っておきます。 10月くら","tags":["misc"],"title":"PCもDIYしました"},{"contents":"今年も振り返りブログ書いてます。カタンの航海者版を購入して家族とやってましたが、負けてしまいました。\n振り返り（2019年に書いた抱負から） まずは去年の抱負を元に書きますが、3月以降はコロナウィルスの影響でいろいろと生活が変わってしまいましたね。\n職につく 厳密には達成してないことになるのかな？\n1月末にフリーランスはじめました(仮)という記事を書きましたが、 そのまま、現時点では個人事業主でフリーランスとして4社ほどお手伝いさせていただいています。\nお手伝いしてるお客さんの事例が出てた。直接的に類似画像検索の部分を手伝ってるわけではないんですが、Azure Cognitive Searchの調査とかやってます。 / 「ハッカソン」で社外の知見を積極的に活用! 富士フイルムソフトウエアが実践するサービス開発の理想形 - https://t.co/yDIwYmYDBM\n\u0026mdash; Jun Ohtani (@johtani) June 19, 2020 名前出てた。ZOZOさんの手伝いさせていただいております。 / ZOZOTOWNにおける検索速度改善までの道のり - ZOZO Technologies TECH BLOG - https://t.co/OqaFMYe0TY\n\u0026mdash; Jun Ohtani (@johtani) August 20, 2020 こんな感じです。 コロナウィルスの影響もあり、完全リモートで仕事をさせていただいています。 感謝しかないです。\nブログプラットフォームの移行 昨年の振り返りの時点で目を付けていたHugoへの乗り換えを行いました。 乗り換えについてもまとめてあります。\nOctopressからHugoへ移行中(まだ途中) ブログ移行日記(その1) - Hugoとテーマ ブログ移行日記(その2) - Markdownファイルの変換 ブログ移行日記(その3) - Hugoの設定と微調整(テーマに合わせた) ブログ移行日記(その4) - 検索機能(Algolia)の導入 ブログ移行日記(その5) - Jugemのブログを移行 無事移行できて、特に困ってない感じです。\nプログラミング 昨年よりは書いた気がしています。 まぁ、書きなぐって放置してるのもありますが。。。\n細々としたツールがいくつか。\nfrom-octopress-to-hugo bulk2es-rs azure-search-analyze-client wiki-extractor-rs kuromoji-graphviz-output kuromoji-cli あとは、Linderaという形態素解析も手伝ってみました。 ちょっと後半は忙しくなり、コーディングが減ってるんで、また復活させないと。\nRust再入門 Tantivyは結局触れてないけど、Linderaを手伝えました。あとは、ちょっとしたツール(bulk2es-rs)なども作りました。 知り合いとやっていたRust the bookを読むのも一通り終わりました。 Linderaまわりのリファクタとかを年明けにやろうかな?\n検索の勉強 仕事になりました。というか、しました。 ブッチャー本も買ったんですが、手を付けられてないので、年明けから心機一転、よみ始めようと思います。\n検索技術勉強会の継続 残念ながらだめでした。 年初にスピーカーの方に連絡は入れて履いたのですが、コロナウイルスの影響で 今年はオフラインの勉強会は無理だろうとい事で延期したままです。 オンラインの勉強会もいくつか開催されていましたが、検索技術勉強会は残念ながらモチベーションもわかずのまま今年も終わってしまいました。 単に話を聴くセミナーのようなものよりは、Podcastのような形を取るのがいいのかもなぁとは思っているのですが。。。 だれか、サクッと話したい人いたらやってみませんか?\n振り返り(今年あったできごと) さて、ここからは今年の出来事を。\n自宅環境の改善 Windowsへの移行 キーボードDIY フリーランス ブログ書いたなぁ 3月以降はずーっと自宅で仕事してました。 ということで、自宅の環境がどんどんアップデートされていった1年でした。 最終バージョンは年内に間に合わなくて、年明けに書きますが。。。 途中経過はこんな感じでした。今は更に変わっていますが。\n3月バージョン 9月バージョン 12月バージョンでも書きますが、ずっと自宅で作業だったのもあり、自作PCをやりたくなったので、久々にWindowsに帰ってきました。Ubuntuもチョット検討しましたが、Windowsに今は落ち着いています。自作PCはこんな感じ。 自作PCブログも後で書きますね。\n設置完了してこんな感じ。なんかベンチマーク走らせるかなぁ。何がいいだろ pic.twitter.com/aZufAE9fJA\n\u0026mdash; Jun Ohtani (@johtani) December 4, 2020 Windowsをお試し中 Windowsへの移行（その１） AutoHotKeyで色々と弄っているので、素のWindowsは触れる気がしないけど。。。\n自作つながりで、キーボードもDIYしました。\nDozen0を作成した Corne Light v2を作成した Corne Chocolateを組み立てた Sofle Keyboardも組み立てた(けど、ビルドブログはまだ) 分離キーボードには昨年から興味があったのですが、手を付けていませんでした。 今年は自宅でずっと作業でしたから、これを機会に作ってみました。 既製品(Moonlander)も気になってはいたのですが、DIYキーボードはプラモデル感覚で作れそうだし面白そうだなと。 今年一番ハマったものかもしれないです。 知り合いが始めたKochi Keyboardで最初に発売されたのがCorne Light v2だったので、これが初めての分割キーボードです。 40%キーボードからいきなり入ったので最初はかなり大変でしたが、なれると入力が早くなる気がします。ホームポジションからほぼ動かないのはいいですね。最初は数字列がないのでアホか???と思っていましたが。 今は、Sofle(60%キーボード)がメインになっています。40%から60%に移行すると 数字のキーが遠いなと思ってしまいますねw\nどうなるものかと思いつつ、フリーランスを続けています。 最初に仕事をいただいた富士フイルムソフトウェアさんには非常にお世話になっています(今もお手伝いさせてもらっています、ありがたい)。来年も精進していきます!\n今年はブログを書きました、最後はちょっと息切れしてる感じになってるけど。。。 もっとカジュアルに書くようにしないとなぁ。 年明けにまだ書いてないブログを書いていかないと。「自作PCブログ」「Sofleのビルドブログ」「2020年買ってよかったブログ」とか。\n来年の抱負 ということで、来年の抱負です。\nフリーランス継続? プログラミング 検索の勉強 検索のポッドキャスト? とりあえず今年は乗り切れました。来年も食べていくためにもフリーランスを継続できるように、お手伝いさせて頂いてる各社に 継続してもらえるように精進していきます。色々と勉強させて頂いてるのでほんとうにありがたいです。\nプログラミングは今年の後半はスローダウンしてしまったのでがんばらないと。 検証用のコードやちょっとしたツールを書くほうが多いので、もう少し継続してメンテナンスするようなものも書きたいなぁと。\n検索の勉強はまずはブッチャー本を買ってしまったので、ここからでしょうか。 値段も厚みもすごいので、コツコツ元を取れるようにがんばります。。。\n来年もまだまだ自宅で仕事が続きそうなので、勉強会というよりもポッドキャストみたいなものをやるのがいいのかもなと。 2020年初にやらせていただいた、「検索システム探訪」をポッドキャスト風にやるのもありなのかもなぁ。 興味ある人いたら連絡ください。公開しない雑談とかもありだと思ってるので。\n今年は色々ありましたが、無事に乗り切れました。 気軽にランチなどで遊びに行けない状況ですが、雑談相手になっていいなと思う方、連絡お待ちしています。\nさて、来年はどんなキーボード作るのかなぁ(え?また作るの??)。 今後もよろしくおねがいしまーす!\n","date":1609406004,"dir":"post/2020/","id":"a5b2ee641e10d3e4db8f888217ab9ecc","lang":"ja","lastmod":1609406004,"permalink":"https://blog.johtani.info/blog/2020/12/31/looking-back-2020/","publishdate":"2020-12-31T18:13:24+09:00","summary":"今年も振り返りブログ書いてます。カタンの航海者版を購入して家族とやってましたが、負けてしまいました。 振り返り（2019年に書いた抱負から） ま","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2020）"},{"contents":"Elastic stack (Elasticsearch) Advent Calendar 2020の18日目の記事になります。\n本日の勉強会でLTをしましたが、しゃべり足りなかったんで。 Elasticsearch 7.8でこっそりとリリースされたIndex Template V2について調べたのでどんなものかをまとめてみます。 リリースブログには出てきてない（7.8のEsのページのWhat\u0026rsquo;s newには出てた）ので気づいてない人も多いのではないでしょうか？\nIndex Templateとは？ まずはIndex Templateがどんなものかを説明しましょう。\nIndexの設定やマッピングはデフォルト値以外を設定したい場合に、毎回\u0026quot;mappings\u0026quot;や\u0026quot;settings\u0026quot;の設定を指定してIndexを作成するのは手間がかかります。 そこで便利な機能として提供されているのがIndex Templateです。このIndex TemplateはCluster Stateに保管されます。\nIndex Templateを利用するときの流れは以下の通りです。\nIndex Templateの作成 Indexの作成 例えば、3ノード構成のクラスターでインデックスを作成するときに常に\u0026quot;number_of_shards: 3\u0026quot;を設定したいとします。 Index Templateは次のような感じになります。\nPUT _template/blog_num_shards { \u0026#34;index_patterns\u0026#34;: \u0026#34;blog_*\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;index\u0026#34;: { \u0026#34;number_of_shards\u0026#34;: 3 } } } または日本語のシンプルな形態素解析のアナライザーの設定を\u0026quot;jp_\u0026ldquo;という名前でるようできるようにしたい場合には次のような感じになります。\nPUT _template/jp_simple_kuromoji { \u0026#34;index_patterns\u0026#34;: \u0026#34;jp_\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;index\u0026#34;: { \u0026#34;analysis\u0026#34;: { \u0026#34;simple_jp\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji\u0026#34; } } } } } インデックステンプレートの登録が終われば、インデックスを作成するタイミングでIndex Templateが適用されます。 例えば、blog_2020というインデックスを作成すると、number_of_shards: 3のインデックスが作成されます（デフォルトは1）。 jp_blog_2020というインデックスを作成すると、simple_jpというAnalyzerが設定されています。 このように、インデックス名を意識するだけで設定が適用されていくのが利点です。\nちなみに、Index TemplateはIndex作成時に適用されるだけなので、Index Templateを変更してもこれまでのインデックスへは影響はありません。\nこれまでのIndex Templateの問題点 と、Index Templateが便利なのはわかりましたが、ではなぜ今回V2がリリースされたのでしょうか？ 先ほどの例を見るとわかりますが、これまでのIndex Templateは部品化が難しいのが問題でした。 Index Templateはそれぞれがインデックスの作成時に適用されます。 が、Index TemplateにIndex Templateを組み込むことはできません。 例えば、先ほどサンプルとして作成したjp_simple_kuromojiのIndex Templateはjp_で始まるインデックスにしか適用できません。\nでは、blog_で始まるインデックスにもkuromojiのシンプルなアナライザーを使いたくなった場合はどうなるでしょう？ 残念ながら、jp_simple_kuromojiと同じ設定をblog_num_shardsのテンプレートに追加するか、jp_simple_kuromojiのindex_patternsの部分だけを書き換えた新しいテンプレートを用意するか、jp_simple_kuromojiのindex_patternsにjp_を追加する方法です。 いずれにしてもIndex Templateの継承（複数のテンプレートを1つのインデックスに紐づける）が必要となります。 この時、複数のIndex Templateが適用されるため、適用する順番が出てきます。 この順番をIndex Templateのorderパラメータで指定できます。\nただ、これも問題のもととなっていました。 複数あるIndex Templateのどれがどの順番で適用されるのか？それはインデックスを作成時にようやくわかります。 使いたい側（インデックス）が、使いたいもの（テンプレート）を指定するのではなく、その逆（使いたいものに使いたい側の情報を設定しなくてはならない（index_patternsやorder））になっているのでわかりにくくなっていました。\nということで解決策としてリリースされたのがIndex Template V2です（ちなみに名前にV2とは言ってるわけではなく、現在のIndex Templateの機能がlegacy index templateという名前になり、Deprecatedになっています（まだログには出ない））。\nIndex Template V2 7.8のWhat\u0026rsquo;s newドキュメントではComposable Index Templateと紹介されています。 大きく3つのエンドポイントが提供されます。\nComponent Template 用API テンプレートのコンポーネントという単位で管理するためのAPI。 登録更新、削除、取得が可能 Index Template 用API Index Templateを管理するためのAPI 登録更新、削除、取得が可能 Simulate index template API(Experimental) Index Template Legacy Index Templateとの大きな違いは、\nテンプレートをコンポーネントにできる 1つのインデックスに適用されれるテンプレートは1つだけ という点です。これまでとは挙動が異なるので注意が必要です。\n新しいIndex Templateを利用する際の流れは次のようになります。\nComponent Templateの作成 Index Templateの作成 作成したIndex Templateの挙動を確認 実際にIndex名を指定してIndex Templateの挙動を確認 という形です。では、それぞれの機能を見ていきましょう。\nCoponent Template API テンプレートコンポーネントを管理するためのAPIです。 具体的なAPIごとに説明していきます。\nPUT _component_template コンポーネントを登録、変更するためのAPIです。公式ドキュメントはこちらです。 先ほどのkuromojiのAnalzyerをコンポーネントとして登録してみましょう。\nPUT _component_template/jp_simple_kuromoji { \u0026#34;template\u0026#34;: { \u0026#34;settings\u0026#34;: { \u0026#34;index\u0026#34;: { \u0026#34;analysis\u0026#34;: { \u0026#34;analyzer\u0026#34;: { \u0026#34;simple_jp\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji_tokenizer\u0026#34; } } } } } }, \u0026#34;version\u0026#34;: 1, \u0026#34;_meta\u0026#34;: { \u0026#34;description\u0026#34;: \u0026#34;simpleなKuromoji analyzer\u0026#34; } } 先ほどと特に違いはありません。templateという階層が1段増え、index_patternsがなくなりました。 template部分はIndexに設定するsettings、mappings、aliasesが指定可能です。 ちなみに、\u0026ldquo;template\u0026quot;の中身をそのままIndex作成時に使用した場合にエラーにならない設定である必要があります。 ここは注意が必要です。例えば、component Aでkuromojiのアナライザーの設定をし、component Bでそのアナライザーを使用するフィールドのmappingだけを記述した場合、component Bでエラーが発生します。上記のようなシチュエーションでは、Index Templateで利用するフィールドを定義し、component Aを利用する宣言をすれば問題ありません。\nそのほかに使えるパラメータで便利なものを紹介しておきます。\nクエリパラメータ\ncreate: URLに指定するパラメータ。trueを指定することで、既に存在する場合にエラーを返してくれる。更新も同じAPIなので間違わないようにするために利用すると便利。デフォルトはfalse リクエストボディ\n_meta: テンプレートにメタ情報を付与できる。_metaの中は自由に記述可能。コメントなどを書いておくとあとでわかりやすい GET _component_template コンポーネントを取得するためのAPIです。公式ドキュメントはこちらです。 一覧での取得とリストでの取得が可能です。\n一覧取得サンプル\nGET /_component_template GET /_component_template/* これ以外に、IDを指定して取得することも可能です。\nGET _component_template/jp_simple_kuromoji *を利用して複数取得も可能です。\nGET _component_template/jp* GET _component_template/j*_* DELETE _component_template コンポーネントを削除するためのAPIです。公式ドキュメントはこちらです。 IDを指定してコンポーネントを削除できます。\nDELETE /_component_template/jp_simple_kuromoji ID指定以外に*を利用することも可能ですが気を付けて使用しましょう。\nDELETE /_component_template/jp_* DELETE /_component_template/* ちなみにIndex Templateで利用されているコンポーネントを削除しようとした場合はエラー（ステータスコード400）が返ってきます。 *などを使用して削除しようとした場合は、ひとつでも利用されているものが含まれている場合は削除は実行されずにエラーだけが返ってくるようになっています。\nIndex Template API Index Templateを管理するためのAPIです。 Component Template APIで定義したコンポーネントを利用してテンプレートを作成できます。コンポーネントを利用しないで単体で完結したテンプレートも作成可能です。 具体的なAPIごとに説明していきます。\nPUT _index_template Index Templateを登録・更新するためのAPIです。公式ドキュメントはこちらです。\nこれまでのLegacy Index TemplateのAPIのエンドポイント(_template)ではなく、(_index_template)というエンドポイントになっていることにまず注意してください。 先ほど作成したjp_simple_kuromojiコンポーネントと、追加で作成した3_shardsというコンポーネントを利用して blog_で始まるインデックスに適用できるIndex Templateを作成してみましょう。\nPUT _index_template/blog_template { \u0026#34;index_patterns\u0026#34;: [\u0026#34;blog_*\u0026#34;], \u0026#34;template\u0026#34;: { \u0026#34;mappings\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;hoge\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;text\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;simple_jp\u0026#34; } } } }, \u0026#34;priority\u0026#34;: 100, \u0026#34;composed_of\u0026#34;: [\u0026#34;jp_simple_kuromoji\u0026#34;, \u0026#34;3_shards\u0026#34;] } composed_ofというパラメータに利用したいコンポーネントを配列で記述していきます。 Index Templateが適用される時に、ここに記述されている順番でコンポーネントが適用されていきます。 ですので、最後に書いてあるテンプレートが一番強いことになります。 これは例えば、同じ設定値number_of_shardsを2つのコンポーネントが設定している場合に、最後に設定した値がインデックスに採用されるという意味です (公式ドキュメントにサンプルが掲載されています)。 なお、存在しないコンポーネントをcomposed_ofに指定した場合は400エラーが返ってきます。同じコンポーネントを複数重複して指定した場合は特にエラーにはなりませんでした。 composed_ofを指定しなければ、単体で完結したテンプレートを定義可能です。\n次に重要な設定はpriorityです。これまでのテンプレート機能と異なる点で説明しましたが、\n1つのインデックスに適用されれるテンプレートは1つだけ となっています。 この1つを決めるための値がpriorityになります。 インデックス名によってはindex_patternの定義によって、複数のIndex Templateにマッチします。例えばblog_*と*_2020のIndex Templateがあった場合にblog_2020というインデックスを作った場合です。 この時、Elasticsearchはpriorityの大きい値を持ったIndex Templateだけを適用します。 blog_*のIndex Templateのpropertyが10、*_2020のIndex Templateのpropertyが100だった場合、*_2020のテンプレートが適用されます。Legacy Index Templateではorderという似たパラメータがありましたが、こちらは適用する順序を決定するためのものでした。挙動が違うので注意しましょう。\nちなみに、blog_*と*_2020のpropertyがどちらも10というIndex TemplateをPUTしようとした場合、2番目にIndex TemplateをPUTするタイミングでエラーが返ってきます。\nそのほかに使えるパラメータで便利なものはPUT _component_templateと同様にcreateと_metaです。\nGET _index_template Index Templateを取得するためのAPIです。公式ドキュメントはこちらです。 一覧での取得とリストでの取得が可能です。\n一覧取得サンプル\nGET /_index_template GET /_index_template/* これ以外に、IDを指定して取得することも可能です。\nGET _index_template/blog_template *を利用して複数取得も可能です。\nGET _index_template/blog_* GET _index_template/b*_* DELETE _index_template Index Templateを削除するためのAPIです。公式ドキュメントはこちらです。\nIDを指定してコンポーネントを削除できます。\nDELETE /_component_template/jp_simple_kuromoji ID指定以外に*を利用することも可能ですが気を付けて使用しましょう。\nDELETE /_component_template/jp_* DELETE /_component_template/* 最後のサンプルを実行すると、Elasticのツールなどが登録したIndex Template以外はすべて削除されてしまうので本当に気を付けましょう。\nSimulalte API さて、コンポーネントとテンプレートを作成したので確認をしましょう。 Legacy Index Templateでは確認するためには実際にインデックスを作成するしかありませんでしたが、V2ではSimulate APIが用意されています。 このSimulate APIには2つのAPIがあります。\nPOST /_index_template/_simulate/\u0026lt;テンプレート名\u0026gt; POST /_index_template/_simulate_index/\u0026lt;インデックス名\u0026gt; Index Templateの確認のためのAPIとインデックス名を指定したときに出来上がるIndexの設定を確認するためのAPIです。 Indexを実際に作成しなくても確認できるのは便利ですね。\n例えば先ほど作成したblog_templateを試してみましょう。\n_index_template/_simulate API POST _index_template/_simulate/blog_template レスポンスはこんな感じです。\n{ \u0026#34;template\u0026#34; : { \u0026#34;settings\u0026#34; : { \u0026#34;index\u0026#34; : { \u0026#34;analysis\u0026#34; : { \u0026#34;analyzer\u0026#34; : { \u0026#34;simple_jp\u0026#34; : { \u0026#34;filter\u0026#34; : [ \u0026#34;kuromoji_readingform\u0026#34; ], \u0026#34;type\u0026#34; : \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34; : \u0026#34;kuromoji_tokenizer\u0026#34; } } }, \u0026#34;number_of_shards\u0026#34; : \u0026#34;3\u0026#34; } }, \u0026#34;mappings\u0026#34; : { \u0026#34;properties\u0026#34; : { \u0026#34;hoge\u0026#34; : { \u0026#34;type\u0026#34; : \u0026#34;text\u0026#34;, \u0026#34;analyzer\u0026#34; : \u0026#34;simple_jp\u0026#34; } } }, \u0026#34;aliases\u0026#34; : { } }, \u0026#34;overlapping\u0026#34; : [ { \u0026#34;name\u0026#34; : \u0026#34;blog_template2\u0026#34;, \u0026#34;index_patterns\u0026#34; : [ \u0026#34;blog_*\u0026#34; ] } ] } templateにコンポーネントがマージされた結果が出力されます。 overlappingはindex_patternsがかぶる可能性があるIndex Templateの情報が出力されます。 サンプル用にblog_template2という、同じindex_patternsでpriorityが低いものを登録してあるためです。 index_patternsが完全に同じではなくとも、重複する可能性があるものはここに出力されます。 例えば、index_patternsがb*という別のIndex Templateを作成してからSimulate APIを実行すると、overlappingにそのIndex Templateも出力されます。\nSimulate Index Template APIのもう一つの機能は登録前のIndex Templateの確認です。 リクエストのURLのテンプレート名をなくし、PUT _index_templateと同じJSONをリクエストボディとして送信した場合、コンポーネントをマージしたテンプレートがどんなものかを確認できます。\nPOST _index_template/_simulate { \u0026#34;index_patterns\u0026#34;: [\u0026#34;blog_*\u0026#34;], \u0026#34;template\u0026#34;: { \u0026#34;mappings\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;hoge\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;text\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;simple_jp\u0026#34; } } } }, \u0026#34;priority\u0026#34;: 10, \u0026#34;composed_of\u0026#34;: [\u0026#34;jp_simple_kuromoji\u0026#34;] } このリクエストを送信すると、コンポーネントがマージされた結果が返ってきます。index_patternsがかぶるものがある場合はoverlappingも一緒に返却されます。\n_index_template/_simulate_index API 今度はインデックス名を指定するSimulate APIを試してみましょう。\nPOST _index_template/_simulate_index/blog_2021 これだけです。\n{ \u0026#34;template\u0026#34; : { \u0026#34;settings\u0026#34; : { \u0026#34;index\u0026#34; : { \u0026#34;analysis\u0026#34; : { \u0026#34;analyzer\u0026#34; : { \u0026#34;simple_jp\u0026#34; : { \u0026#34;filter\u0026#34; : [ \u0026#34;kuromoji_readingform\u0026#34; ], \u0026#34;type\u0026#34; : \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34; : \u0026#34;kuromoji_tokenizer\u0026#34; } } }, \u0026#34;number_of_shards\u0026#34; : \u0026#34;3\u0026#34; } }, \u0026#34;mappings\u0026#34; : { \u0026#34;properties\u0026#34; : { \u0026#34;hoge\u0026#34; : { \u0026#34;type\u0026#34; : \u0026#34;text\u0026#34;, \u0026#34;analyzer\u0026#34; : \u0026#34;simple_jp\u0026#34; } } }, \u0026#34;aliases\u0026#34; : { } }, \u0026#34;overlapping\u0026#34; : [ { \u0026#34;name\u0026#34; : \u0026#34;fuga\u0026#34;, \u0026#34;index_patterns\u0026#34; : [ \u0026#34;b*\u0026#34; ] }, { \u0026#34;name\u0026#34; : \u0026#34;2021\u0026#34;, \u0026#34;index_patterns\u0026#34; : [ \u0026#34;*_2021\u0026#34; ] } ] } 例で作成したblog_templateが適用されていますが、それ以外にindex_patternsに合致したがpriorityが低くて適用されなかったものがoverlappingに出力されています。 実際に適用されたテンプレートの名前も別途出力してくれるとわかりやすいかもしれないですね。 (*_2021というインデックスパターンのテンプレートを試しに作ってみたのですが、これはバグがありそうです。2021に合致するインデックス名をSimulateしたらoverlappingに合致しないものがたくさん出てきました。バグ報告しとくか)。\nKibana対応 ここまで、Index Template V2のAPIの説明でしたが、Kibanaでの対応についても調べてみました。\nIndex Management（Stack Management機能。Elasticライセンスが必要だが無償の機能） 7.9からKibanaのIndex管理画面でComposable Templateが利用できるようになっています（GitHub Issue）。 画面のスクショを一通り貼っておきます。残念ながら、それぞれのJSONの編集部分では補完などはサポートされていないようでした。 頑張って自分でsettingsやmappingsのJSONを記述していく感じになります。JSONとして正しいかどうかはチェックしてくれます。 Index Templateのウィザードでは、ボタンでコンポーネントを追加したり削除したり、順序を入れ替えたりといった作業が可能になっています。 また、プレビュー表示が可能なので、composed_ofで選択したものが今どのように適用されているか？といったのも確認できるようになっていました。 結構便利に管理できそうです。ちなみにスクショは7.10の画面になります。\nComponent Template周り 一覧表示とウィザード Index Template周り 一覧表示とウィザード Console(Dev Tools。OSSで利用可能) リクエストを実行は可能ですが、自動補完機能は一部のみ対応しているようです(GitHub Issue)。\n対応済みの機能\nDELETE _component_template (ただし、ここまで。存在するコンポーネント名は補完されない) 上記以外はまだ未対応のようです。 プルリクエストチャンスかも？\n参考 Composable Templates · Issue #53101 · elastic/elasticsearch What’s new in 7.8 | Elasticsearch Reference ［7.8］ | Elastic Index management | Elasticsearch Reference ［7.10］ | Elastic ［Composable template］ Create / Edit wizard by sebelga · Pull Request #70220 · elastic/kibana ［Console］ Support suggesting index templates v2 · Issue #75967 · elastic/kibana まとめ ちょっと長くなってしまいましたが、新しいIndex Templateについての紹介でした。 これまでと違い、複数のテンプレートが適用されない点があるのでそこは注意が必要そうです。 コンポーネントをうまく使えば、管理が簡易化はされそうですね。\n","date":1608216955,"dir":"post/2020/","id":"c6fc88bd57a0e57ddf22e2eb1bef892c","lang":"ja","lastmod":1608216955,"permalink":"https://blog.johtani.info/blog/2020/12/17/index_template_v2/","publishdate":"2020-12-17T23:55:55+09:00","summary":"Elastic stack (Elasticsearch) Advent Calendar 2020の18日目の記事になります。 本日の勉強会でLTをしましたが、しゃべり足りなかったんで。 Elasticsearch 7.8でこっそりとリリースされたI","tags":["elasticsearch"],"title":"Index Template V2"},{"contents":"はじめまして、pyspa。 ということで、pyspa Advent Calendar 2020の4日目(大谷コンビの2号)の投稿になります。 コンビそろってキーボード記事ですね。\n今年はDIYキーボードにはまった（はめられた？）年でした。 もともと分割キーボードには興味があり、自宅で作業するのが基本となったのもあり手を出した次第です。 まだまだ使いこなすところまでは来てないかもしれないですが、組み立てたり、問題点のキリ分けしたり、試行錯誤するのは楽しいなと。\n今回はCorne Chocolateというキーボードを組み立てたのでそちらのビルドログ（かつ今後のための教訓）になります。 LEDを使ったキーボードがどんなものなのか＋薄いキーボードも気になるなということで取り組んでみました。 今回もいくつか失敗をしつつ、リカバリーして動くものができました。\nパーツ（材料） 基本のパーツは今回もKochi Keyboardさんから購入しました。\nキット : Corne Chocolate（ベースキット） キースイッチ : Kailh Choc v1 Blue (25gf リニア) 5個 キーキャップ : Kailhロープロ刻印キーキャップ ケーブル類は家に転がっていたケーブルを利用しました。 キースイッチセットもあるのですが、軽いキータッチが好みなので、一番軽いKailh ChocのBlueを試してみたくキースイッチを個別に選択しました。 キーキャップはShiroを作るときに調達していたものを利用した形です。\n今回も公式のビルドガイドにざっと目を通してから着手しました。\n準備 ビルドログにもあるようにPCBがリバーシルブなので、作業中に迷子にならないようにこんな感じで表にマスキングテープで目印をつけておきました。\n今回から耐熱ワーキングマットで作業をすることにしました。机の天板に傷つくの嫌だし。 気兼ねなくはんだできるのでおすすめです。\nhttps://t.co/0qntPD8qIa\n2ヶ月ぐらいにここで買いました！\n\u0026mdash; 西田和史(k.bigwheel) 開発基盤EM (@k_bigwheel) November 11, 2020 ダイオード、OLEDソケット、コンスルー、TRRSソケット、 こちらは前回のCorneとほぼ同様だったのでビルドガイド通りに進めます（写真撮り損ねました。。。） 前回との違いはダイオードの形です。 表面実装するタイプのダイオードなので向きに気を付けつつ、つけていきます。\nビルドガイドに向きやダイオードのつけ方が紹介されています。 拡大鏡とピンセット必須ですね。 前回同様に、ここまででいったんqmk_toolsでファームウェアをインストールして、ピンセットを使いながらキーの認識とOLEDの動作確認を行いました。 今使っているファームウェアがあるのでそれを入れて問題ないかを確認しました。\nLED実装 今回のメインイベントです（そして苦杯をなめたイベントでもあります）。 ビルドガイドにも記載がありますが、信号が流れる順番があるようなので1番から取り付けていきます。 また、ビルドガイドにLEDに関する注意事項もいくつか掲載されています。必ず読みましょう。\nこの1～6までのLEDがすごく大変でした。。。\n表面実装のLED（Underglow LED）で四苦八苦 いくつかのブログを参考にしながら作業を進めました。\nコルネキーボードを作りました ～LED取り付けに四苦八苦記～ | キオクノロンダリング SK6812miniの仕様などについて書いてあります。デバッグするのにすごく役に立ちました。 Corne Chocolateビルドログ - nokの雑記 手書きでどんな感じでやればいいのかを解説してくれています。最終的にはこの方法が一番だったのかも？ 自作キーボードキット「Corne Cherry」のレビュー - 自作キーボード温泉街の歩き方 あとで出てきますが、リカバリ方法の参考になりました。 皆さん苦労されてますね、そして私も苦労しました。。。\n試してみた方法、考察は次の通りです。\nLEDチェック用のファームウェアをインストールして1つつけては動作確認 HelixのLEDテスト用ファームウェアをインストールしました。 白光 1C型こて先 失敗した後にリカバリするために購入しました。 LEDのランドなどが2Cよりも面積が小さいので、そのサイズに合わせたこて先のほうがよかったようです。 はんだの温度（温調できるはんだごて必須） 最初は250℃でやっていましたが、なかなかはんだが溶けません。そのせいで焦りも出てきます。 最終的には270度で作業しましたが、温度のせいでLEDが壊れたのはなかった気がします。1Cのこて先だったので無事だったのかもしれません。 フラックスなし あると楽だったのかも？残念ながら試してないです。 予備はんだ手法（だめっぽかった） 基盤のランド4か所に予備はんだをし、はんだを温めつつLEDを乗せる方法 LEDの裏にも予備はんだ どちらも試してみましたが、温めている個所以外のはんだと高さの違いが出てしまい、LEDが浮いてしまいます。4か所を同時に温めることはできないので、すこしずつ調整しているうちにLEDを物理的に壊してしまうことがありました。。。 ちょっとコツが分かったかも？ pic.twitter.com/ruwrmEWCAe\n\u0026mdash; Jun Ohtani (@johtani) November 19, 2020 わかった気になっていますが結局失敗しました。。。\n結局最後までこれというコツはわかってない気がします。結局3つか4つのLEDがお亡くなりになりました。 うまくいかなかった原因は、予備はんだで傾きなどができ、それを修正していくうちに基盤やLEDにダメージを与えてしまったのだと思います。\nよく見ると基盤が一部剥がれかけてるのがわかるかなぁと。\nリカバリー 右手側の表面実装の4番と5番が失敗しました。\n4番目（以下のツイート右側画像の上） こちらは、1度付けたLEDをはがすときにはんだを取り除くのが不十分な状態でLEDをはがしたために、基板のランドごとはがれてしまいました。 なのでここはLEDはつかないです。。。 5番目(以下のツイート右側画像の真ん中あたりの黄色い線がつながっているLED) LED自体はつけてありますが、青色しか発光しなくなっています。 4番目が完全に死んでしまったので、無事な3番目のLEDのDINに流れている信号を 5番目のLEDのDINにも流れるようにするために10芯コードでショートカットさせました。 （リカバリ方法は先ほど紹介したブログが非常に参考になりました、先人の知恵ありがたし）。 黒い線も売っていたのですが、自戒も込めて目立つ色にしてみました。\n勉強させていただきました、、、 pic.twitter.com/Zp16fJKziM\n\u0026mdash; Jun Ohtani (@johtani) November 22, 2020 ちなみに、左側のショートカットのコードはつけた後に1か所LEDの向きが違うことに気づき必要なくなっています （上記の基盤が傷ついている画像をよく見ると上下が逆になってるのがわかる人にはわかるかも）。\n片方は導線なくて良くなった。表から見たら向きが違うのに気がついたわ、、、 pic.twitter.com/7TSDMPPxlX\n\u0026mdash; Jun Ohtani (@johtani) November 22, 2020 最終的に2か所おかしいLEDにはなりましたが、幸いにもアンダーグローです。 Kochi Keyboardさんで購入したキットのボトムプレートはFR4なのでほぼ見えません！（負け惜しみ）\nソケット さて、気を取り直してソケットをつけていきます。 Dozen0にて経験済みなのでそれほど手間はかかりませんでした。 LEDの失敗の時に1Cのこて先を購入していたため、ソケットの横の隙間からこて先が差し込めたのが便利でした（LEDでダメージを受けていたのもあり写真撮り忘れ）。\n完成 ということで完成です。デフォルトで赤く光ってます。キーキャップがLEDを透過してくれるタイプだったのがこれまたよかったですね。 作る前は光らなくてもなんて思ってたのに。\nキーマップ(v2) Corne Lightで作業を数週間ほどして、いくつか入力しにくい部分があったのでマッピングを少しだけ変えました。 相変わらず日本語キーボードベースですが、数字のレイヤーにいくつかの記号を使えるように割り当てました。 コーディングをするときに、ライブラリのバージョン（例：7.10.0とか）やIPアドレスを入力していてレイヤー切り替えのためのキーを押したり話したりするのは効率が悪すぎたためです。 数字との組み合わせでよく使いそうな以下のキーを数字のレイヤーに移動しました。\nセミコロン（JP_SCLN） コロン（KC_QUOT） アンダースコア（JP_UNDS） コンマ（KC_COMM） ピリオド（KC_DOT） スラッシュ（KC_SLSH） #include \u0026#34;keymap_jp.h\u0026#34; const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = { [0] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_TAB, KC_Q, KC_W, KC_E, KC_R, KC_T, KC_Y, KC_U, KC_I, KC_O, KC_P, JP_MINS, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, KC_A, KC_S, KC_D, KC_F, KC_G, KC_H, KC_J, KC_K, KC_L, JP_SCLN, KC_QUOT, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, KC_Z, KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_COMM, KC_DOT, KC_SLSH, KC_RSFT, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, MO(1), KC_SPC, KC_ENT, MO(2), KC_RALT //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [1] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_ESC, KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0, KC_BSPC, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, KC_LEFT, KC_DOWN, KC_UP,KC_RIGHT, JP_SCLN, KC_QUOT, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, JP_UNDS, XXXXXXX, KC_COMM, KC_DOT, KC_SLSH, XXXXXXX, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, _______, KC_SPC, KC_ENT, MO(3), KC_RALT\\ //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [2] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_TAB, JP_EXLM, JP_DQUO, JP_HASH, JP_DLR, JP_PERC, JP_AMPR, JP_QUOT, JP_LPRN, JP_RPRN, JP_CIRC, KC_BSPC, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, JP_MINS, JP_EQL, JP_LBRC, JP_RBRC, JP_YEN, JP_AT, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, JP_UNDS, JP_PLUS, JP_LCBR, JP_RCBR, JP_PIPE, JP_TILD, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, MO(3), KC_SPC, KC_ENT, _______, KC_RALT //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [3] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. RESET, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| RGB_TOG, RGB_HUI, RGB_SAI, RGB_VAI, RGB_SPI, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| RGB_MOD, RGB_HUD, RGB_SAD, RGB_VAD, RGB_SPD, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, _______, KC_SPC, KC_ENT, _______, KC_RALT\\ //`--------------------------\u0026#39; `--------------------------\u0026#39; ) }; LEDの色が変えられる！（気づくの遅い） あと、キーマップを変更しているときに4つ目のレイヤーにRGBなどのボタンがあるのに気付いて押してみたら、LEDのパターンや色を変えることができるのに気付きました。 （遅すぎでは。。。）\nキーキャップが白いのもありこんな感じの色にしてみています。\nユニコーンガンダムっぽくなった pic.twitter.com/vHxZkMrYyP\n\u0026mdash; Jun Ohtani (@johtani) November 28, 2020 まとめ ということで、失敗も多々ありましたがキーボードとしてはちゃんと動くできたものができたので安心しました。 今後、状況が落ち着いてきて自宅以外で仕事をするときにはCorne ChocolateをPCと一緒に持ち歩くと思います。 薄くて邪魔にならなくてよさそうです。\n今回もはんだっしゅ太郎大活躍でした。本当に買ってよかった。 LEDがつかないときはちょっと落ち込みましたが、これのおかげで立ち直れたのもありますし。 あとは、試行錯誤しつつLEDとかの理解ができたのも楽しかったです。 キーマップの変更時にLEDの変更などができるのに気づいたのはちょっと遅すぎたので、qmkの仕組みや割り当てられるキーにどんなものがあるのかをもう少し研究したいなと思います。\nさて、次はどんなことを試すかなぁ。\n","date":1607004824,"dir":"post/2020/","id":"a46c601d03a3a26bc418d0096fe83a42","lang":"ja","lastmod":1607004824,"permalink":"https://blog.johtani.info/blog/2020/12/03/build_corne_choc/","publishdate":"2020-12-03T23:13:44+09:00","summary":"はじめまして、pyspa。 ということで、pyspa Advent Calendar 2020の4日目(大谷コンビの2号)の投稿になります。 コンビそろってキーボード記事です","tags":["DIYキーボード","misc"],"title":"Corne Chocolateを組み立てた #DIYキーボード"},{"contents":"前回のブログのまとめに書いたように、セパレートタイプのキーボードであるCorne Light v2を作成したのでそのビルドログです。DIYキーボードとしては2つ目になります。\nまとめで書いていたお店が開店したので、購入してみました。 購入したのはこちらのKOCHI KEYBOARDさんです。 ついこの間オープンしたばっかりのお店です！\nなんで作ったの？ スプリット型（セパレートタイプ？どっちが正しいんだろう？）のキーボードに興味があって、KOCHI KEYBOARDさんで買えたのがこれだったというのが大きな理由です。こういうのってタイミングだと思うので。 あとは、組み立てていくのがプラモデルみたいで面白いというのもあります。 基本的にここのところ自宅で仕事をしているので、ノートPCのキーボードにこだわる必要もないなというのも理由ですね。今後も当面は自宅で仕事になると思いますので。\nCorne Light v2 foostanさんが設計された（って言い方であってるのかな？）、3x6のサイズに親指の3キーが配置された分離型のキーボードの一種です。 シリーズ？の名前としてはCorne Keyboardと呼ばれています。 （そういえば、由来は何だろう？自作キーボードがどうやって設計されていくのかという流れがまとめられた作者の方のブログがおもしろいです。） また、基板の設計などがGitHub上でMITライセンスで公開されています。 オープンソースなハードウェアというのも面白いです。\nビルドログ 作者の方がビルドガイドを公開してくれています。ですので、こちらに沿って作業をしていきます。 ちなみに、私は今回Gateronのクリア軸を選択してみました。さらさらと入力できるのが好きなので。 サイレント軸にも興味はあるのですが、今回は実際にスプリット型のキーボードを早く触ってみたいというのが勝ちました。キーキャップについては後述します。 ツイートに都度、写真をアップしていたので組み立ては画像でお楽しみください（時々取り忘れてるけどｗ）。\nうむ pic.twitter.com/svW9WdzaZv\n\u0026mdash; Jun Ohtani (@johtani) October 21, 2020 刺して曲げる pic.twitter.com/M0jfQJg2k8\n\u0026mdash; Jun Ohtani (@johtani) October 22, 2020 両方できたと。ハンダまでやって今日はおしまいにすっか pic.twitter.com/HgsSrxqpcg\n\u0026mdash; Jun Ohtani (@johtani) October 22, 2020 写真取り忘れたけど、ProMicroつけた pic.twitter.com/RS4z0lqsUZ\n\u0026mdash; Jun Ohtani (@johtani) October 22, 2020 OLEDもついたと。今日はここまで pic.twitter.com/p6Z8MMP0Xz\n\u0026mdash; Jun Ohtani (@johtani) October 22, 2020 ここまでは順調です。\nOLEDがつかない？ ビルドガイドに従って、この後キースイッチをつけちゃうと問題の切り分けが難しくなるということで、 ここまでの段階でQMK Toolboxを使ってProMicroにファームウェアを書き込んで、それぞれのキーのソケットの取り付け部をピンセットでショートさせつつ、キーが入力されるかどうかを見ていきます。 QMK Toolboxについてはサリチル酸さんのブログがわかりやすいので参考にさせていただきました（わかりやすい記事をありがとうございます）。 で、ビルドガイドにあるように動いてるかを確認しようとしたのですが。。。\nさて、ファームウェア書き込んだけど、OLEDがつかないな。どっかつながってないのか？\n\u0026mdash; Jun Ohtani (@johtani) October 24, 2020 ビルドガイドのようにはいかず。。。 USBでPCとつないだ状態で、QMK Configuratorをサイトで開いて、キーボード入力テストを開くと、ショートさせたキーがPC側で認識されているかのテストができます。 これで、一通りキーは認識できていそうだというのはピンセットでショートさせながら確認しました。 ただ、OLEDには何も表示されないんです。。。\n前回Dozen0を組み立てた時に、ソケットのはんだ付けが甘かったというのもあったので、 OLEDやソケットのはんだを温めなおしたりしてみて、何度か確認してみたものの特に進展がなしです。 （ちなみにうまくいかないのもあって、ぼけたツイートしたりもしてます。）\nまぁ、OLEDはビルドガイドを見てもオプション扱いなので、それよりも触ってみたい衝動に駆られて、 キースイッチをはんだ付けしていきます。\nちなみに昨晩、OLEDはとりあえず置いといてって感じでキースイッチつけてた。キーキャップはまだない pic.twitter.com/SzLmzNg60Y\n\u0026mdash; Jun Ohtani (@johtani) October 26, 2020 それも終わって、問題点の切り分けに何かできないかな？と思ってやったのがOLED単体でArduinoと接続してみて動くかどうかです。 Qiitaにちょうどいい感じの記事を見つけたのでこれまた参考にさせていただきました(4本のジャンパー線を一人で持ちながら確認するの大変だったｗ)。\nはんだでの修正にしっぱい で、自分の中での結論として、「OLEDソケットのはんだ付けが怪しい」となりました。 そこで、まずは外してみようかと思ったのが間違いでした。 はんだごてとはんだ吸い取り線で何とか外せるだろうと思っちゃったんですよ。 OLEDピンソケットは足が4本あって、とりあえずとれるところまではんだ吸い取り線で吸い取ってみましたが、 さすがに基盤の穴に流れ込んだはんだまでは吸い取れず、頑張って温めながらソケットを抜こうとがんばって、 ラジオペンチでピンソケットを引っ張りながら引き抜きました。かろうじて引き抜きはできたのですが、ソケットは足が折れてしまいました。\n作者登場（OLED問題の解決） そんなところにCorneの作者の方がツイートを拾ってくれたみたいで以下のような返信を頂きました。\nOLEDが点かないのはファームのせいかもしれません(最近以前のファームで動かない新しいタイプのOLEDモジュールが出回るようになりました)。お手数ですが、https://t.co/vfSBfIeeJX のブランチのものを試して頂けますか？(ただいまPRレビュー中でまだマージされていない状態です)\n\u0026mdash; c7s (@foostan) October 25, 2020 暗闇に光明とはこのことです。 教えていただいたブランチを手元でビルドしてファームウェアを書き込むと、\nすごい、出ました！右側のディスプレイにロゴが。ありがとうございます（左側のOLEDはソケットのはんだ付け直し失敗したのでもうちょっと先になりますが）！\n\u0026mdash; Jun Ohtani (@johtani) October 26, 2020 なんと、ファームウェア書き込んだ瞬間にOLEDが点くじゃないですか。 感謝感激ってやつです。お礼を言うのに便乗してOLEDの問題の切り分けの方法についても聞いてしまいました。\nOLEDリベンジ 片側は無事だったのですが、もう一方は修復が困難になったので救世主を発注します。 自作キーボードの作成に便利なものリストとして、いくつかのブログに上がっていたのですが、必要ないだろうと見送っていたツールです。\nAmazon | サンハヤト はんだシュッ太郎NEO 45Wタイプ HSK-300 | ハンダゴテパーツ 本当にすごく使いやすかったです。 OLEDのピンソケットが修復不可能だったのですが、ProMicro用に付属して余っているピンヘッダがちょうどいい長さでした。 なので、これを4本分切り取り、OLEDモジュールにつけてしまったOLEDヘッダピンを抜き取って、代わりに切り取ったピンヘッダをつかって、OLEDと基盤を直接はんだ付けすれば修復できそうだと判断しました。\nはんだシュッ太郎君を使ってOLEDについてるヘッダピンをまずは除去。 そのあとはこんな感じで繋げました。\n見にくいかもだけど pic.twitter.com/YAHoxjgppN\n\u0026mdash; Jun Ohtani (@johtani) November 5, 2020 取り外しにくくはなったけど、無事両方のOLEDが点くのも確認できました。やったー。\nヤッター、両方のOLEDがついたよー pic.twitter.com/6KLDWvnaEC\n\u0026mdash; Jun Ohtani (@johtani) October 28, 2020 キースイッチがご機嫌斜め キーキャップは別途、AliExpressで発注をかけたのですが、ここまで来たら待ちきれないですよね？ ということで、手元にあった上海問屋のキーボードのキーキャップが同じMXキースイッチ用のものだったので移植しました。キーキャップ付けてみないとわかならいものですね、1つだけキースイッチがうまくはまっておらず、斜めについているのがこの時点で判明しました（ボトムプレート付けた後だったので、プレート外してから、はんだで修正）。\nちなみにキーキャップはめてる途中で、一箇所キースイッチが斜めにはんだ付けされちゃってるのを発見して慌てて直しました。 pic.twitter.com/qofHp3o4Pc\n\u0026mdash; Jun Ohtani (@johtani) October 30, 2020 無事使えるようになりました。\nアンスコが打てない＆Escどこ？ キーキャップ付けたので仮運用ということで、まずはデフォルトのキーマップをもとにどんな感じで入力できるのかを試してみました。 ここにも罠がｗ ブラウザでQMK Configuratorを開いてデフォルトのキーマップを確認しながら試し打ちをしていたのですが、どうも思ったのと違う動きをしているキーが。\nまずBASEレイヤー（レイヤー0）の右側のシフトと、LOWERレイヤーやRAISEレイヤーのEscです。 入力しているとどうも、右のシフトがEscで、レイヤーを切り替えてもTabのままだなと。 しょうがないので、OLEDが出なくてもいいのでQMK Toolboxでダウンロードしてきたものを利用したら想定通りなのにと。 きちんとqmk_firmwareの構成を理解しないままやってたつけでしたね。 結論としては、OLED用に教えてもらったブランチではキーマップが書き換わっていたようでした。 make crkbd:defautでビルドした時に利用されるkeymap.cがキーマップの定義が書いてあるファイルです。 qmk/qmk_firmwareのリポジトリにあるkeymap.cとfoostanさんにもらったブランチでは差分があったみたいでした。\nおかげで、qmk_firmwareのkeymap.cの仕組みがわかったし結果オーライです。 問題があって調べるとどんな作りになってるかとかちゃんと確認できますしね。 手順通りにやってるだけで問題が起きないと、どんな仕組みになってるのかがわからないので人に聞きまくるしかできなくなっちゃいますしね。\nこれでEsc問題は解決したのですが、アンスコがどうしても入力できません。 自作キーボード以外はすべて日本語配列のキーボードを使用しているのもあり、 日本語配列のキーボードだとどうもキーのマッピングが異なるようだと。\nググって参考にしたのはこの辺でした。\n【QMK】JPキーコードでキーマップを定義する - 天高工房 自作キーボードキット「Corne Cherry」のレビュー - 自作キーボード温泉街の歩き方 そのほかにもVIAのファームなども試したのですが、どれもうまくいかず。 色々ググってみて最終的な解決策はkeymap.cでkeymap_jp.hというファイルが読み込まれていないので、日本語用の設定とかを読み込んでみたつもりがうまく反映されていないという感じでした。\nJISにする場合、keymap_jp.hっていうヘッダファイル読み込んだほうがいいです\n\u0026mdash; Yoshi Yamaguchi (@ymotongpoo) November 3, 2020 今の時点ではこんなキーマップにしてあります。 今後も日本語配列のキーボードをベースに考えていくつもりです。\n#include QMK_KEYBOARD_H #include \u0026#34;keymap_jp.h\u0026#34; const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = { [0] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_TAB, KC_Q, KC_W, KC_E, KC_R, KC_T, KC_Y, KC_U, KC_I, KC_O, KC_P, JP_MINS, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, KC_A, KC_S, KC_D, KC_F, KC_G, KC_H, KC_J, KC_K, KC_L, JP_SCLN, KC_QUOT, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, KC_Z, KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_COMM, KC_DOT, KC_SLSH, KC_RSFT, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, MO(1), KC_SPC, KC_ENT, MO(2), KC_RALT //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [1] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_ESC, KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0, KC_BSPC, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, KC_LEFT, KC_DOWN, KC_UP,KC_RIGHT, XXXXXXX, XXXXXXX, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, _______, KC_SPC, KC_ENT, MO(3), KC_RALT\\ //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [2] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_TAB, JP_EXLM, JP_DQUO, JP_HASH, JP_DLR, JP_PERC, JP_AMPR, JP_QUOT, JP_LPRN, JP_RPRN, JP_CIRC, KC_BSPC, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, JP_MINS, JP_EQL, JP_LBRC, JP_RBRC, JP_YEN, JP_AT, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, JP_UNDS, JP_PLUS, JP_LCBR, JP_RCBR, JP_PIPE, JP_TILD, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, MO(3), KC_SPC, KC_ENT, _______, KC_RALT //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [3] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. RESET, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| RGB_TOG, RGB_HUI, RGB_SAI, RGB_VAI, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| RGB_MOD, RGB_HUD, RGB_SAD, RGB_VAD, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, _______, KC_SPC, KC_ENT, _______, KC_RALT\\ //`--------------------------\u0026#39; `--------------------------\u0026#39; ) }; キーキャップが待ちきれなくて この右下のトンガリがちょっと気になる pic.twitter.com/W0A0z67cns\n\u0026mdash; Jun Ohtani (@johtani) October 30, 2020 キーキャップが待ちきれなくて上海問屋のキーキャップを付けてみて、いろいろ試行錯誤してみました。\nあー。上下関係ないのか。だからみんなこんな感じにしてるのか？ pic.twitter.com/KTBlPLespr\n\u0026mdash; Jun Ohtani (@johtani) October 30, 2020 どのくらい離すのが良いか実験中 pic.twitter.com/ozK4WyBXY8\n\u0026mdash; Jun Ohtani (@johtani) November 2, 2020 キーキャップもいろいろあるのね 届いた。 pic.twitter.com/jccNW1ZcEM\n\u0026mdash; Jun Ohtani (@johtani) November 2, 2020 もう一個 pic.twitter.com/9y6qat4JiN\n\u0026mdash; Jun Ohtani (@johtani) November 2, 2020 とりあえずセミコロンの位置につけてみた。 pic.twitter.com/TDk5213IHi\n\u0026mdash; Jun Ohtani (@johtani) November 3, 2020 今はこのDSAプロファイルの青いグラデーションのキーキャップを使っています（Dukeはここにはいないですｗ）。 キーキャップのプロファイルはこれまた、サリチル酸さんのブログがわかりやすく書かれています（ほんとすごいなぁ。）。\n高さ調節 そのまま使っていたのですが、やはりもうちょっと奥側に高さがほしいなと。 ダイソーなどで打っているケーブルクリップがお試しには良さそうだったのでこんな感じで内側がちょっとだけ高くなるような感じにして使っています。\nこうなった。とりあえず仮運用 pic.twitter.com/VkhjawdhLM\n\u0026mdash; Jun Ohtani (@johtani) November 4, 2020 まとめ ということで、駆け足ですがCorne Light v2のビルドログでした。 いきなりフルキーボードから40％キーボードかつ異なる並びにしたので、 混乱しっぱなしですが、いい頭の運動になっているし、なにより作って動かすまでの間に いろいろと調べたり試行錯誤できたのがすごく楽しかったです。\nあとは、スプリット型＋Column Staggeredになったので「c」や「b」を間違えまくっていますが、 いい気付きでした。まだまだ記号とかの入力に慣れていないですが、ちょっとずつ身に着けていけたらなと。\nただ、もう次のキーボードをDIYしたい気持ちも出てきているので困っているところです。\n書ききれてないこともあるかと思うので、ここはどうしてるの？これはどうやったの？などあれば、Tweetなりコメントなりを頂けたらなと思います。いやぁ、DIYキーボード楽しいわ。\n","date":1604503527,"dir":"post/2020/","id":"b16bddd1a6d3e5f4136446bebe7ffbc7","lang":"ja","lastmod":1604503527,"permalink":"https://blog.johtani.info/blog/2020/11/05/build-corne-light-v2/","publishdate":"2020-11-05T00:25:27+09:00","summary":"前回のブログのまとめに書いたように、セパレートタイプのキーボードであるCorne Light v2を作成したのでそのビルドログです。DIYキーボードとし","tags":["DIYキーボード","misc"],"title":"Corne Light v2を作成した #DIYキーボード"},{"contents":"ヒゲが不評だったのでいつも通りの長さに切りました。\n前回「Windowsをお試し中」と書きましたが、いくつかソフトをインストールしたりしたので現状を忘れないようにブログに残しておきます（また同じ作業する予定なので）\nインストールしたものたち 今のところインストールしたのはこの辺。 特にコメントしたいものについてこのあと明記します。\nドライバインストール from CD MX Ergoのソフトインストール。接続はコネクター Windowsアップデート Chrome Visual Studio ビルドツール(Lindera用) JetBrains Toolbox IntelliJ CLion Rider Visual Studio Code Slack Teams Google Drive共有 Gitter Divvy for Windows Zoom DeepL Sophos Twitter for Windows Office 365 AutoHotKey WSL2 - Ubuntu Windows Terminal Rustup Git for Windows wsl-ssh-agent PeaZip Speccy Hugo (WSL2のUbuntuにapt-get install hugoした) PowerToys AutoHotKey 前回のブログに書いたように、カーソル系のEmacsショートカットが体に染みついて離れないのです。 そこで、ググって見つけた記事はこちら。 AutoHotKeyというツールが Windowsに常駐して、特定のキー入力の時に、別の操作を実行してくれるツールです。\n見つけた記事にあった、https://github.com/lintaro-jp/gtk-emacs-theme-like.ahkのキーマップをもとに、いくつか変更したものを使用させていただいています。\n書き換えたのは、以下の通りです。\nCtrl+\\でIMEの切り替え（Wnn風） Ctrl+kをEmacsと同じ挙動に（もとにしたキーマップでは、カーソルから行末までが削除されてしまう） Win+sでもファイル保存（Ctrl+sと同じ挙動に。デフォルトではCortanaが起動して邪魔くさいので） すごく快適です。そのうち、もう少し自分が使いやすいようにキーマップを追加していったりするかもしれません。 特に、Macのショートカットがしみついているものについてなどです（仮想デスクトップ切り替えとか？）\nPowerToys Divvyをインストールしたのですが、グローバルショートカットがうまく動かなくていまいちでした（なんでだろ？） そこでググって見つけたのが@ITのPowerToysの記事でした。 PowerToysはMS製のOSSツールで、GitHub上で公開されています。 中には「ColorPicker」、「FancyZones」、「File Explowrer Add-ons」など、複数のツールが入っています。 「FancyZones」です。\nWindowsでは、デフォルトで、アプリにフォーカスしているときにWin＋カーソルでウィンドウの配置場所をいくつか（左右どちらかに半分、4分の1(右上、左上など)）に配置してくれるAero Snapというものが動いています。が、上半分などデフォルトにない柔軟な配置を設定することができません。 MacではDivvyというツールをいれて、それを実施していたのですが、先ほど書いたようにWindows版はあるものの、なぜかグローバルショートカットが動かず、システムタスクトレイのアイコンをクリックしなければいけませんでした。\nそれを解消してくれるのがFancyZonesです。 FancyZonesの設定項目で、自分で画面上にどのような割り当て領域を作るかを設定できます。さらに、マルチディスプレイ、仮想デスクトップを使っている場合、それぞれのディスプレイかつ仮想デスクトップで個別にレイアウトが設定できるようになります。 レイアウトを設定した後は、Shiftキーを押しながらウィンドウを移動すると、設定した領域が出てきて、あとは、割り当てたい領域にウィンドウを移動するだけでその領域いっぱいにウィンドウをリサイズしてくれます。 また、設定を変えることで、Shiftキーを押さなくてもウィンドウ移動するだけで領域にリサイズすることも可能です。また、Aero Snapの機能をオーバーライドしてWin＋カーソルで動作させることも可能になります。\nWSL2 + Windows Terminal 三宅さんからコメントを頂いたので。\nもう少し幅広い感じですかね。あわせて Windows Terminal 使うとわりと快適です。\n\u0026mdash; miyake | ZEN (@kazuyukimiyake) October 15, 2020 なんとなく噂は聞いていましたがということで、MSのドキュメントを見ながらインストールしました。クイックスタートに則って作業するだけで特に問題なくUbuntuまで無事インストールできました。 Windows Terminalも同様です（クイックスタートで入れることになる）。\nGit for Windows + wsl-ssh-agent 少してこずったのがこちらです。 チュートリアルに記述はあったのですが、どちらで作業するのか？などが少しわかりにくかったので。ググって出てきた記事をもとに作用しました。\nRustのプロジェクトファイルをMacから丸ごとコピーしていたのですが、Git for Windowsを入れるまでは、CLion+Rust pluginの環境では、.gitファイルをきちんと認識してくれませんでした（この時WSL2と少し混同してた）。\n無事環境は用意できました。 作業の手順は以下のような感じです。 Macで使用していた.sshのディレクトリを持ってきて作業しました。\nWindows側での作業 Macから.sshディレクトリをc:\\\\Users\\johta\\にコピー Git for Windowsのインストール OpenSSHクライアントの設定 管理者権限でコマンドプロンプトを起動して sc config ssh-agent start=auto sc start ssh-agent [wsl-ssh-agent(https://github.com/rupor-github/wsl-ssh-agent)のインストール ダウンロードして.7zファイルを展開 wsl-ssh-agent-gui.exeとnpiperelay.exeをc:\\\\Users\\johta\\binに移動 c:\\\\Users\\johta\\bin\\wsl-ssh-agent-gui.exeのショートカットをスタートアップに作成 作成したスタートアップのリンク先に -setenv -envname=WSL_AUTH_SOCKを追加 Git BashでOpenSSHを利用するように設定 setx GIT_SSH C:\\\\Windows\\system32\\OpenSSH\\ssh.exe ssh-addで秘密鍵を登録 ssh-add .ssh/id_rsa WSL2のUbuntuでの作業 Ubuntuはgitがすでに入っていたのでインストールはスキップ git config --global user.name \u0026quot;Jun Ohtani\u0026quot; git config --global user.email \u0026quot;メールアドレス\u0026quot; mkdir .ssh .bashrcの最後行にwsl-ssh-agentのWSL2 compatibilityにあるexportからfiまでをコピー。この時、パスを自分のパスに変更すること(私の場合$HOME/winhome/.wslの部分を/mnt/c/Users/johta/binに書き換えました) これで、WSL2側では.sshのファイルを管理しなくても、Windows側のOpenSSHに接続してssh周りの処理をしてくれるようになりました。\nPeaZip wsl-ssh-agentが.7z形式で圧縮されていたので、ダウンロードしました。 とりあえずこれを入れてみたのですが、ほかにお勧めがあれば教えてほしいです。\nSpeccy CPUの温度やスレッドごとのCPU使用率などを見てみたいので入れてみました。 これもとりあえず入れてみた感じなので、ほかにお勧めのソフトがあれば教えてもらえればと。 リソースマネージャーでもスレッドごとのCPU使用率は見れたのですが、温度が見れなかったので。\nHugo + WSL2にあるUbuntuにsudo apt-get install hugoしてインストールしました。\nそこで、VS Code の Remote Extension です。WSL2 から ‘code’ で起動できます😎\n\u0026mdash; Daiyu Hatakeyama@Microsoft, Hack in ChatGPT (@dahatake) October 17, 2020 あとは、畠山さんに教えてもらったVSCodeのRemote - WSLを入れて、 WLSに接続した状態でVSCodeを起動して記事のMarkdownを書くと、VSCodeのターミナルを開くとWSL2に接続してくれて、hugoコマンドが実行できます。\nまとめ とりあえず、ブログが書ける環境ができました。 Mac上にあった各種プロジェクトのディレクトリをコピーして、Rustの開発もできるようになりました。\n今後も環境構築は続いていきます。Javaとか入ってないし。 SDKMan使ってたけど、切り替えどうしよう？とか。\nそういえばSDKMAN!をJDK切替に使ってたけど、結局windows側のパスは通らんので自力インストールになった。scoopがよさげ\n\u0026mdash; きしだൠ(K1S) (@kis) October 17, 2020 IDE系から呼び出すターミナルはWSL2がいいなぁとか。\nhttps://t.co/X4Jj4tih1I\n\u0026mdash; そーだい@初代ALF (@soudai1025) October 17, 2020 ほかにもおすすめなどがあれば教えてください！\n","date":1603029710,"dir":"post/2020/","id":"188c1ee5132a6752dfce5a0235354070","lang":"ja","lastmod":1603029710,"permalink":"https://blog.johtani.info/blog/2020/10/18/restart-windows-no1/","publishdate":"2020-10-18T23:01:50+09:00","summary":"ヒゲが不評だったのでいつも通りの長さに切りました。 前回「Windowsをお試し中」と書きましたが、いくつかソフトをインストールしたりしたので","tags":["misc","windows"],"title":"Windowsへの移行（その１）"},{"contents":"ヒゲが伸びてきて(試しに伸ばしてる)不評を買っている今日このごろです。\n自宅で作業することが多くなってきたので、自作PCでもと思っていますが、OSをどうしようか悩み中。 とりあえず、試しにWindowsにしてみるかということで、10年ぶりくらいにWindowsに帰ってきました (この文章はMacで入力してますが)。\nむかしむかし もともとはWindowsを使っていたのですが、Win7くらいに32bitと64bit混在の時期に、 Xkeymacsを利用するときに少し手間がかかるなぁと思ったのもあり、Macに移行しました。 Macだと自分がよく使うEmacsっぽいショートカットがデフォルトいろんなアプリで使用できる利点があったからです。\nただ、最近、TL上で光るPCとかを見てしまったのもあり、 自作PC(どちらかというとDIYかな?)熱が復活しました。 まだ、OSをWindows、Ubuntuのどちらをメインにしようかな?と悩んでいるところではありますが、まずはWndowsをちょっと試してみるかなと。\nまずは、やりたいことをちょっとリストアップしておこうかなと思います(きっと、先人の知見が集まってくるはず!)。\nどうしてもほしい機能 大学の頃にSunOSやSolarisを使用し、Emacsでメールを読んだしていたせいで、Emacsのショートカット操作が体から抜けない状態です(抜こうとしてないという話もあるが)。 ですので、社会人になってからWindowsを利用していたときはXkeymacsというソフトのお世話になっていました(神アプリでした。まだあるのかな?)。\nショートカット操作とか カーソル移動(必須) 上下左右：Ctrl+n、p、f、b 行頭、行末：Ctrl+a、e 編集 デリートキー：Ctrl+d Ctrl+hがバックスペースだけど使わないな、そういえば カーソルから行末までをカット：Ctrl+k 必須! カーソル移動がホームポジションから移動しなくてもいいのもあって、多用してしまっています。 これ、WindowsとかUbuntuでいい感じにできるのあるのかな? できれば、IMEやブラウザのURLのサジェストなどもこのカーソル移動で移動できると嬉しいです。 (昔はM-%とかで置換などもやってたけど最近はやらないな。)\nデスクトップ操作系 仮想デスクトップ やることごとにデスクトップを切り替えて使うので ウィンドウのリサイズ? DivvyというアプリをmacOSで利用中 自分で登録したサイズ(例：画面右半分)にウィンドウサイズを変更などがショートカットで可能 仮想デスクトップはあると思うけど、ウィンドウのリサイズの便利なツールあるかなぁ?\n利用するアプリ SNS、オンラインミーティング Twitter macOSではTweetDeckと夜フクロウを使用 Slack ネイティブアプリ Gitter ネイティブアプリ Chatwork ブラウザ Teams ネイティブアプリ Zoom ネイティブアプリ Google Meet ブラウザ Discord ネイティブアプリ(最近使ってないな) 色々使ってますが、最悪ブラウザで使う感じかな?\nオンラインストレージ Google Drive 同期アプリ使ってる Dropbox あんまり使ってない 開発系 JetBrainsのIDE Toolbox App IntelliJ CLion + Rust plugin Rider zsh macOSで標準になったから コマンド系 git SDKman ant gradle JDK Rust Hugo Jasper GitHubのIssueとかを見るネイティブアプリ 自分が関連しているIssueとかが楽に見える(メールだと埋もれてしまう) エディタ Visual Studio Code 開発系では?と思われるかもだけど、Markdownエディタとして使ってる Emacs by Homebrew 最近は起動してない その他 カレンダー macOSのカレンダーで複数のGoogleカレンダーを取り込んでる ScanSnap Ubuntuで使えるやつあるのかな? Mac miniにつないであるので、画面共有とかで入れればそれでOK 画面共有 winやubuntuからMac miniとか見えるかな? キーボード共有 macも使うので、KVMスイッチとかかな? マウス共有 MX ErgoのFlowを使うと行き来が簡単にできたので良さそう。 ただし、Ubuntuだとどうなるのか? システム監視系 CPUの温度とかCPU、メモリの使用率とか まとめ とりあえずこんなところです。カーソル移動系が一番重要なので、そのへんから色々とちょっとずつ試していく予定。 ぜひオススメアプリとかあれば教えていただければと。\n","date":1602727442,"dir":"post/2020/","id":"de37d9fae011687eb1eb5a127fcb89e3","lang":"ja","lastmod":1602727442,"permalink":"https://blog.johtani.info/blog/2020/10/15/restart-windows/","publishdate":"2020-10-15T11:04:02+09:00","summary":"ヒゲが伸びてきて(試しに伸ばしてる)不評を買っている今日このごろです。 自宅で作業することが多くなってきたので、自作PCでもと思っていますが、","tags":["misc","windows"],"title":"Windowsをお試し中"},{"contents":"今年の春くらいから、セパレートタイプのキーボードが気になっています。 また、なんか知らないですが、Twitterのタイムラインが自作キーボード(DIYキーボード)で盛り上がってる気がします。 (たぶん、気になってるから余計目についてる)。 これとか。このスライドから、自分がやってるのは「まだ」DIYキーボードだなということで、タイトルに使ってみました。\n#toruby \u0026quot;DIYキーボードは実質Ruby\u0026quot; 本日のスライドです! とちぎでこの話をできてよかった!!!q: https://t.co/RJot71Ngu9\n\u0026mdash; Kakutani Shintaro (@kakutani) September 12, 2020 セパレートタイプのキーボード 今年の夏まではMac Book Pro 16インチのキーボードを利用していました(参考:自宅の作業環境(2020))。 これまで、自宅で作業することよりも、外で仕事をすることが多く、また、外といっても様々な場所(サムライズムだったり、オフィスだったり、カフェだったり)で作業をすることが多かったので、ノートPCのキーボードにしていました。流石にキーボードを持って歩くほどは気にしていなかったので。\nただ、コロナウイルスの影響もあり、ほぼ自宅で作業することとなりました。 となると、前から気になっていたセパレートタイプのキーボードが俄然気になり始めます。 (といいつつ、寄り道してたりしますが)\n気になっていたのはこのあたりなのですが、\nErgodox EZ Moonlander Mark I 流石にいきなり行くにはちょっと気が引けるなぁと(なかなかいいお値段)。 また、自分が日本語キーボードを利用しているというのもちょっとあります。\nキースイッチの感触を知りたくて ただ、日々、楽しそうな自作キーボードの記事や画像が流れてきます。 で、思い出したのが自分の趣味。プラモデルです。色を塗ったりはしないですが、組み立てるのは楽しいなと。 じゃあ、趣味と実益を兼ねればいいのでは?(ほんとか?)となり、作る気になってきました。\nただ、全く知らない世界だし、どんなものなんだろう?と。 市販のキーボードでも、キーの押し具合が色々合ったり、形もまちまちです。 また、このご時世ですので、自宅からあまり出ていないので遊舎工房さんなどに遊びにも行けず。\nそんなところに流れてきたのがキースイッチのテスターでした(世の中誘惑だらけ)。\nスイッチテスター人気スイッチ詰め合わせ 18個セット 「なるほど、これでどんな感触かわかるじゃないか!」と、気づけばポチッと押していました。。。 届いて、「ふむふむ、これがこういう感触なのか。なるほど」ポチポチ押しながら、さらに自作キーボードについて調べていきます。\nいろんな感触なんだなぁ pic.twitter.com/PaGDMIRJiv\n\u0026mdash; Jun Ohtani (@johtani) September 22, 2020 キースイッチのストロークの深さを知りたくて まぁ、当たり前なのですが、先程のキースイッチテスターどこにもつながっていません。 キーボード触ってるとわかりますが、ストロークが違いがあるんですよ。 ただ、これだとわからない。けど知りたい。\nで、ググっているとArduinoを使ってLチカやってる人とか、キー入力させている人がいるじゃないですか。 これでは?そういえば、Arduinoもどきうちにもあるぞ?と。 で、準備をしていたときに見かけてしまったのがこのツイートでした。。。\nhttps://t.co/ALl7OcRVRa 高機能テスターとしてもおすすめ\n\u0026mdash; Kakutani Shintaro (@kakutani) October 4, 2020 やられてしまいました。。。\ndozen0作りました ということで、前置き長かったですが、Dozen0というキーボード(マクロパッド?)を遊舎工房さんから購入して作ってみました。 手順はビルドガイドという形でまとまっています。\n基本的にはこれに沿って作成しました。\nパーツと手順の確認 さてと。 pic.twitter.com/GTBJ7zDleN\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 まずは入っているパーツがきちんとあるか確認します。 また、ビルドガイドでどんな作業があるのかをざっと眺めておきます。 まぁ、プラモデルといっしょですよね。\nキットにはキースイッチとキーキャップは含まれていません。これはご注意ください。 私は、キースイッチテスターとして入手していたキースイッチとキーキャップがどんな押し具合なのかを確認したかったので特に問題ありません。\nハンダづけ Amazon | 白光 ダイヤル式温度制御はんだこて FX600 | ハンダゴテ Amazon | 白光 こて先 2C型 T18-C2 | ハンダゴテパーツ Amazon | 白光(HAKKO) セラミックヒーターはんだこて専用こて台 クリーニングスポンジ付き FH300-81 | ハンダゴテパーツ Amazon | goot(グット) 高密度集積基板用 鉛入りはんだ Φ0.6mm スズ60%/鉛40% ヤニ入り SD-60 | ハンダゴテ はんだ付け用に揃えた道具です。「自作キーボード ハンダゴテ」とかでググると出てきたものがこれだったので。 デフォルトのコテ先ではなく、2Cのコテ先に付け替えてから作業を開始しました。\n私の持っていたソケットはCherry MX系なのですが、気が向いたらKailh Chocも試したくなるかも?ということで、 すべてはんだ付けしました。本格的にはんだ付けしたのは大学以来だからもう20年近く経ってますね。 ソケットの足をプリント基板にはんだ付けするのですが、2Cのコテ先が大きくなかなか手こずりました(これがこのあと問題を引き起こしました)。\nソケット、リセットスイッチ、ProMicroをはんだ付けすればはんだの作業は終了です。\npic.twitter.com/jjUo162n54\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 pic.twitter.com/p5atvtHfFN\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 スイッチの取付と組みたて 試したいキースイッチを選んでトッププレートにつけていきます。\nキーテスターからスイッチとキーキャップ持ってきて完成。動作確認はまだなのでまた、最初に戻るかもだけど、、、 pic.twitter.com/ZmBd3bgOKI\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 組み立ても終わり次は実際の動作確認です(ツイートしていますが、予想通りの展開でした)。\nファームウェアの書き込み USBで接続して、ファームウェアの書き込みです。 書き込み手順はビルドガイドにありますが、QMK Toolboxの使い方やQMK Configuratorの使い方は以下のサリチル酸さんのブログがわかりやすかったです。\n（初心者編）自作キーボードにファームウェアを書き込む （初心者編）QMK Configuratorを使ってキーマップを書き換えよう 実際に書き込んで動かしてみると。。。。\nうーん、上半分が死んでる気がするなぁ。\nデフォルトキーマップの書き込みはできたけど、カーソルの上とかバックスペースが入らないw\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 とりあえず、もう一回確認してみた。デフォルトのキーマップで、「Cut」「Paste」が強く押さないと入力されない。UpとDeleteは動くようになってた。CopyとBkSpがうんともすんとも言わない。下段のキーは全部動く。https://t.co/zEyINdAK6t\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 といった具合に上半分が動作があやしいです。\n再度、はんだ付け ということで、ネジを外して上の段のソケットをはんだで温めてみると、片側だけ温めるとはずれるじゃないですか。 どうやら、うまくソケットの足が基盤にはんだ付けできていなかったようです。 この時、最初に作業したときに2C型のコテ先が大きくて、ソケットの足に入らなかったのを思い出したので、 最初にはんだごてについていたコテ先に戻してから作業をしました。 これだとソケットの足の隙間に入るんです。ということで、挙動のおかしい上段のソケットをすべてつけ直したところ無事動作しました。\n上の段、全体的にソケットがうまくはんだ付けできてなかったみたいだった。今回はMX系のスイッチしかないので、Kailh Chocのソケットの導通は未確認。ざっとブログにまとめるか。\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 現在のキーマップ これが今のキーマップです。仕事中のBGMをラズパイ4の音楽プレーヤーで流していますが、 部屋から出るときや、打ち合わせがあるときに音楽の停止、開始などを画面共有経由でやっています。 が、わざわざマウス移動するのもめんどくさいなと。これに使えそうだというのもあったので、Dozen0を購入したというのがあります。 残念ながら、Prev Trackとかがうまく動かないので、ショートカットを調べてキーマップ書き換える予定ですが、非常に便利になりました。\nまとめ ということで、Dozen0を作ってみましたが、楽しかったです。すんなりと行かなかったのがまた良かったです。 試行錯誤して動いたときの喜びが何倍もありました。また、キースイッチの感触も知ることができました。 たぶんGateron Silentクリア軸もしくは赤軸くらいが良さそうだなぁと(こうやって沼へ。。。)。 キーマップの仕組みを調べたり、もっと面白い使い方できないかな?と探りつつ、次のステップに進もうかなと。\n次は本格的なセパレートタイプのキーボードを作る予定です。が、お店のオープンを待ってからということになってます。はやくオープンしないかなぁ!!\nがんばって!!\n\u0026mdash; Jun Ohtani (@johtani) September 29, 2020 ","date":1602428006,"dir":"post/2020/","id":"c377351433a941a927aab543931f6026","lang":"ja","lastmod":1602428006,"permalink":"https://blog.johtani.info/blog/2020/10/11/build-dozen0/","publishdate":"2020-10-11T23:53:26+09:00","summary":"今年の春くらいから、セパレートタイプのキーボードが気になっています。 また、なんか知らないですが、Twitterのタイムラインが自作キーボード","tags":["DIYキーボード","misc"],"title":"Dozen0を作成した #DIYキーボード"},{"contents":" 2020/10/06 11:00くらいにマージされました。\n@minoru_osuka さんが開発を引き継いだLinderaというKuromojiのRustクローンがあります(リポジトリ) 。 最近趣味でRustを勉強しているので、こちらを少し手伝っています。\nRustの勉強仲間である@takuya_bさんや@ikawahaさんと話をしているときに、FST部分をDouble Array Trieに置き換えると速度が向上するのでは?という話が出まして、@takuya_bさんがDouble Array Trieを作るらしいという話になったので、下準備などをしつつ、作ってもらったライブラリyadaを組み込んでみたという話です。\nベンチマークの追加 下準備として、今のLindera(FST実装)がどのくらいの性能なのか?というのを計っておく必要があります。 幸いにも、Linderaのオリジナルの開発者の方が、criterion.rsというライブラリを使ったベンチマークプログラムを作成してくれていました。\nただ、1種類だけだと少し心もとないなというのと、長い文章やパターンを増やしたほうが良さそうだなということで、 ベンチマーク自体をいくつか追加しました(追加したときのPR)。\n種類としては、5種類のベンチマークです。\nシステム辞書のみのTokenizerのコンストラクタ呼び出し カスタム辞書ありのTokenizerのコンストラクタ呼び出し システム辞書のみのTokenizerのtokenize処理の呼び出し カスタム辞書ありのTokenizerのtokenize処理の呼び出し 青空文庫の坊っちゃんのテキストをシステム辞書のみのTokenizerでtokenize 1,2はコンストラクタ部分だけの処理をベンチマークテストする目的で作成しました。 LinderaはTokenizerがtokenize処理するのに利用するデータをいくつか内部で保持しています。 これらはファイルにシリアライズされており、Tokenizerのオブジェクト生成時に読み込みやデシリアライズ処理が発生します。 この部分だけも速度を計測したい目的でコンストラクタだけを切り出しました。\n3,4はTokenizerのメインの処理です。コンストラクタはベンチマークの対象外にしました。 純粋にtokenizeの処理だけを切り出して計測するためです。 カスタム辞書がある場合、ない場合は念の為切り出した形になっています。\n5は長い文章(文章が多いのでバリエーションも増える)を扱いたいために別にしました。\nこれで、一応下準備が完了です。 ちなみに、Criterionは賢くて、前のベンチマークの結果と最新の結果を比較してくれる機能があります。 どんな感じで出てくるかはベンチマーク結果をご覧ください。\nyadaの組み込み ベンチマークの準備をしていたところyadaがリリースされたので、Linderaへの組み込みを検討し始めました。\nというわけで、またダブル配列を書いてしまったので crate として公開しました。フィードバックお待ちしております！ https://t.co/As7h0tfmjf\n\u0026mdash; takuya-a (@takuya_b) September 20, 2020 中身の理解 lindera-fstを利用して、prefix searchしている処理があるので、そこで利用しているFSTをyadaに置き換えれば良さそうだと判断して、 処理を読んでいきます。\nTokenizerは、PrefixDictという構造体でlindera-fstを利用している prefixメソッドが入力文字列を元に、FSTを前方一致検索して、ヒットした単語の情報をIteratorとして取り出せる(単語の情報は「入力文字列の先頭からの文字数」と「ヒットした単語のWordEntry構造体」) PrefixDictのfstは辞書(例：ipadic)ごとにlindera-\u0026lt;辞書名\u0026gt;-builderで生成される システム辞書としては、デフォルトではlindera-ipadic-builderでfstを構築している 構築処理はこの辺 という感じです。 また、辞書周りのファイルがそれぞれどんな役割なのか、どんなデータの持ち方をしているのか?といった点を、変更点の調査のついでに書き出してみました。lindera-dictionary/FILES.md。TODOになっている部分も追記が終わっています(PR)\n変更点 実際に変更したプログラムの詳細についてはのPRを見ていただくとして、簡単には以下の点になります。\nRustのバージョンを1.46.0に(おもにREADME.md) yadaが利用している機能に1.46.0で導入された機能があるため lindera-fstをyadaに変更(lindera-core/Cargo.toml, lindera-ipadic-builder/Cargo.toml) 合わせて、dict.fstというファイル名をdict.daに変更 dict.daに関して構築部分と検索部分を変更 FSTではFSTから返ってくる値(入力文字列に出てきた単語に関連する値)はu64だったが、yadaのDoubleArrayがu32しか扱えないため、u32に変更。テストの記述はしていないが、扱うデータ的にu32で問題なさそうだったので。 検索部分：PrefixDict構造体のprefixメソッドでDoubleArrayのprefix_common_searchを使用 DoubleArray自体がprefix_common_searchのメソッドを持っていたので、処理が簡単に置き換え可能だった。FSTはprefixメソッド内で独自で前方一致検索を実装していた。 構築部分：lindera-ipadic-builder/src/lib.rsのbuild_dictとbuild_user_dictのdict.da構築処理 ipadicのCSVファイルを読み込んで、見出し語をキーに、辞書にある単語情報のベクタを値とするBTreeMapを生成し、このBTreeMapに基づいてFSTを構築していた部分をDoubleArray構築処理に置き換えた。 シフト演算などで、実際の値(dict.vals)へのポインタを作っていたのだが、ここの処理を読み解くためにFILES.mdを書き出した。 という感じです。そもそもデータ構造がどうなっているのか?から読み解いて、変更部分を洗い出して変更していった形になります。 取り込み作業中にいくつかyadaに要望(このへん)を上げて、変更を取り込んでもらい、最終的にyadaのバージョン0.3.2で問題なく動きそうだという形になりました。@takuya_bさん、対応ありがとうございました。\nエッジケースバグの発見 作っててよかった、テストケースでした(実際にはベンチマークテストですが)。 取り込み作業中に、Lindera本体のcargo testはすべてOKになるが、ベンチマークを取ろうとしたときに、坊っちゃんの文字列を入力にしたベンチマークが失敗するという事象が発生しました(PRのコメント参照)。 切り分けのために、入力の文章のどこでおかしくなるのか?DoubleArrayのbuildメソッドに渡している値がおかしくないか?などをすこしずつ調べていくと次のバグが判明したという感じです。\n特定のデータ(ipadicの見出し語一覧)をDoubleArrayに入れて、特定の文字列(「は相」)をcommon_prefix_searchにいれたら、 返ってくる情報(0から何バイト目の文字が一覧に存在した)が、不正な値が返ってくるというバグでした。 @takuya_bさんに見てもらいつつ(DoubleArrayの中身わからん。。。)、修正してもらいました。素早い対応ありがとうございます。\nyada 0.3.1 をリリースしています。特定の条件で不正な遷移を許すダブル配列が構築されてしまうバグを修正しています。このエッジケースは @johtani さんが見つけてくださいました。ありがとうございました！ https://t.co/CiftZi5GDn\n\u0026mdash; takuya-a (@takuya_b) September 30, 2020 やはり、いろんな文字列入れてテストしてみるの重要ですね。 ということで、ベンチマークだけでなく、テストケースとしても坊っちゃんのファイルを読み込んでトークナイズするようにPRでテストケースを追加しています。\nベンチマーク結果 yadaを利用した変更が終わったので、再度cargo benchを実行して計測です。 計測としては、masterブランチでまずcargo benchを実行し、yadaの実装をしたブランチに切り替えてからcargo benchを実行します。 すると、Criterion? cargo benchが、最終的な結果に前回との差分でどのくらい性能が改善、改悪したかも合わせて出力してくれます。 実行環境と結果は以下のとおりです。\nMacBook Pro 16インチ CPU：Core i7 6コア 2.6GHz メモリ：32GB コンストラクタのベンチマークについては10%ほど性能が悪くなっています。 これは、FSTよりもDoubleArrayTrieのほうがデータが大きくなってしまうためだと思われます。 実際にファイルのサイズは次のようになりました。yada(DoubleArrayTrie)のほうが2倍以上大きいことがわかります。 また、このファイル以外にもLinderaが利用しているデータはありますが、それらは今回変更の対象にはなっていません。 なので、単純にこのファイルの読み込みの処理に時間がかかっているのだと想像できます。\n2147765 / FST / dict.fst 5425152 / yada / dict.da tokenizeのベンチマークについては、11%〜28%の改善が見られました。 文章から、内部に保持している辞書に存在する単語を見つけ出す処理に利用されるのがFST、DoubleArrayTrieです。 今回の変更では、この処理に利用しているデータ構造だけを変更しました。 実際には\nDoubleArrayTrieを用いた単語の検索処理 見つかった単語の持つ値(data.valsのオフセット情報)を元にシフト演算 といった処理が実行されます。シフト演算はu64だったものがu32に変更されたくらいなので、大した処理量ではないかと。 大部分はDoubleArrayTrieを利用したルックアップ処理が速度向上に寄与していると思います。\nまとめ 最近Linderaに加えた変更、作ったPRについて少しブログにまとめてみました。 ちなみに、まだPRの段階でレビュー\u0026amp;リリース待ちという感じです。\n実際には作ってもらったライブラリを組み込んでみたというだけなのですが、速度が向上した結果が見れたのは面白いです。 また、基本的なデータ構造とかアルゴリズムの勉強にもなりました(2次元配列を1次元配列に押し込むとか)。このへんも今後も勉強していきたいです。\n組み込む際に色々と協力していただいた@takuya_bさん、@ikawahaさん、巻き込んでくれた@minoru_osukaさんに改めて感謝いたします。\nRustや形態素解析のプログラムの勉強を兼ねて、今後もなにか改善できる部分がないかなどを見ていこうと思っています。 Rustで形態素解析をしたいという人がどのくらいいるかはわかりませんが、おかしなところや疑問点などあればコメントください。\n","date":1601865378,"dir":"post/2020/","id":"15932a656f7acfac897d27766eadc9e2","lang":"ja","lastmod":1601865378,"permalink":"https://blog.johtani.info/blog/2020/10/05/switch-fst-2-da/","publishdate":"2020-10-05T11:36:18+09:00","summary":"2020/10/06 11:00くらいにマージされました。 @minoru_osuka さんが開発を引き継いだLinderaというKuromojiのRustクローンがあります(リポジトリ)","tags":["Rust","Lindera"],"title":"LinderaのFSTをDoubleArrayTrieに変更した話"},{"contents":"先日は「検索システムを構成するパーツ」ということで検索システムを構成しているパーツについて書いてみました。\n大体、検索がうまくヒットしないといった場合に、問題になるのがコンテンツ自体のデータもしくは、転置インデックスのキーワードだったりします。 そこで今回は、前回のパーツの「データソース・コンテンツ」周りについて少し書いてみようと思います。言葉の定義、それぞれがどんなことをやるのか、とりあえず導入したあとにコンテンツ周りでどんな改善ができるかなどを書いてみます。\n言葉の定義 コンテンツ 実際に検索させたいデータになります。 コンテンツにはWebページ、データベースのレコード(CMSで登録されたデータなど)、ファイルサーバーにある文書(PDF、Word、Excelなど)などになります。\nデータソース コンテンツのマスタデータが保存されている先です。 よくあるデータソースとしては以下のものが考えられます。\nWebサイト - 自社もしくはインターネットに存在しているWebサイトです。 ファイルサーバー - ローカルネットワーク上のファイルサーバーもありますが、最近ではGoogle DriveやDropboxといった外部のWebサービスもあります。 RDB - CMSや自社システムでのデータの保存先です。 クローラー コンテンツをデータソースから収集してくるプログラムのことです。 Webサイトやファイルサーバーからコンテンツを収集して検索エンジンに登録するところまでを担当します。 RDBにあるデータを検索エンジンに登録する場合はクローラーがデータを登録するというよりは、RDBにデータを登録するシステムが検索エンジンに登録する機能を持っていることが多いです。\nデータの収集と登録 収集 クローラーを使用した収集の場合は、サービスの特性とデータソースによって、どの程度の頻度でクロールするのか、クロール対象はどこまでか?といったものを決める必要が出てきます。 これらが決まれば収集ができるかと(他に権限とかもありますが。)。 収集コンテンツは、そのままでは利用しにくかったり、利用できないことがあるので、次はデータの変換を行います。\nデータ変換 コンテンツはそのままの形では検索エンジンには扱いにくいデータ形式である場合があります。\nWebページの場合 Webページの場合、コンテンツにはHTMLタグが入っていたり、JavaScriptなど検索対象にはしたくないデータなどが入っています。これらを除去して、検索させたいものを取り出す必要があります。 また、Titleタグなど、いくつかメタデータとして扱えるものがHTMLで規定されているので、これらを別の項目として取り出して個別に検索できるようにすると便利です。 HTMLをパースしてデータを抜き出す処理ができるライブラリなどがあるので活用します。\nファイル PDFファイルなど、ファイルの場合もメタデータと呼ばれるファイル自体が持っている情報が存在します。作成者、更新日時、ファイル名、パスなどです。 これらも検索時に有効な情報になります。 また、ファイルから文字列を抜き出す処理も必要になります。 それぞれデータフォーマットが異なりますので、そのフォーマットに合わせて文章データを抜き出す処理が必要です。OSSや製品がありますので、それらを利用して、ファイルから文章を抜き出します。\nRDB RDBのデータの場合、データが正規化されています。 検索エンジンでは、非正規化のデータを登録して検索することが基本となるため、まずは非正規化して取り出す必要が出てきます。\n例えば、ジャンルやカテゴリ、各種IDなどが実際のコンテンツのレコードに入っていると思いますが、これらをユーザーが入力したキーワードで検索したい場合などは、IDではなく表示名を取り出して、検索エンジンに登録する必要が出てきます。\nその他 データごとの変換処理について説明しました。 その他に、データのクリーニング処理などと言ったことも必要になってきます。例えば、HTMLのタイトルに必ずサイト名が入っているが、除去したいといった場合や、検索エンジン固有のデータの前処理などもあります。\n登録 最後は検索エンジンへの登録です。 最近の検索エンジンはJSON形式でデータを受け取る場合が多いので、JSONに変換することが多いです。 基本的には各種プログラミング言語のライブラリが用意されているのでこれらを利用するのが基本となります。\n検索したい項目、検索させたい方法などを洗い出し、必要なデータを作成して検索エンジンに登録します。 登録と書いていますが、更新、削除などもここでの対象となります。\nここまでの流れで、データソースからコンテンツを取得し、変換して、検索エンジンへの登録が終わりました。\n検索の改善 検索のログから分析して改善していくのが良いですが、ユーザーからの質問や意見などからも改善すべき点が見えてくると思います。 検索ログでは、次のようなものを元に、検索がうまく行かないものを見つけ出します。\n0件ヒット 0件クリック ヒットしていない検索ワードがある場合、コンテンツに問題がある場合があります。まずはこのあたりをとってみるのが良いかと。 そもそも、入力されたキーワードにマッチするコンテンツを扱っていないこともわかりますし、入力されたキーワードに似た単語を持ったコンテンツなども存在するはずです。 類義語の辞書を用意して、検索にヒットできるようにするといった分析と改善にも利用できます。\nあとは、検索エンジン側の話ですが、形態素解析器などを利用している場合に、意図した区切りになっていないために、うまくキーワードがヒットしないと言ったこともあります。\nコンテンツの理解 実はこれが一番だったりします。 どんなコンテンツを自分たちが扱っているのか?どんなデータがどういった項目でコンテンツに入っているのか?といったところから、 コンテンツのデータを元に検索にヒットさせる方法が改善できます。\nCMSなど人が入力したデータをコンテンツとして扱う場合、入力画面を改良することで、望んでいるデータを入れてもらえたり、不要なデータが入らなくなる可能性があります。 例えば、ECサイトなどで商品の説明文やタイトルにいろいろなキーワードが入っている場合などがあります。むりやりどんなキーワードでもヒットさせたいという入力者の意図もあるのですが、検索しているユーザーにはノイズになることも多いです。適切にカテゴリやジャンル、属性といった項目に分けることでおかしな入力データを減らすことも可能です。\nWebサイトなどをクローリングしたものの場合は、サイトごとに文章の特徴があったり、重複している部分などが合ったりする場合があります。 これらもコンテンツをよく調べることで、不要な情報を除去したりといったことが可能になります。\nまとめ 簡単ですが、検索のデータソースやコンテンツにまつわる話を紹介しました。 もちろんここでは紹介しきれていない項目がいっぱいあります。 また、具体例ではなく概略をざっくりと書いているのでわかりにくい場合もあるかもしれません。 すこしユースケースを絞り込んで書いたほうがわかりやすくなるのかも?\n次はUIとか書くかも?\n不明点とか疑問点、指摘事項などあればコメントしていただければと。 要望などもお待ちしております。\n","date":1600136614,"dir":"post/2020/","id":"b2c4cf0fb96d02d37f03668caaecbc57","lang":"ja","lastmod":1600136614,"permalink":"https://blog.johtani.info/blog/2020/09/15/improve-search-no3/","publishdate":"2020-09-15T11:23:34+09:00","summary":"先日は「検索システムを構成するパーツ」ということで検索システムを構成しているパーツについて書いてみました。 大体、検索がうまくヒットしないとい","tags":["検索"],"title":"検索対象のデータとデータソース(検索システムに関する妄想その3)"},{"contents":"自宅環境に少しアップデートがあったので更新版です。 お客さんのおかげで相変わらず自宅で作業させてもらってるのもあり、昨今のコロナウイルスの影響で出かけることもないので、自室の作業環境が更新されている感じです。 前回のブログはこちらです。 前回のまとめで触れていた2点について更新されています。\nまずは、現状のデスクの上の写真です。\n基本的には前回紹介したものと大きくは変わっていません(?)。 変わったものについて紹介していきます。\nデスク 先程の写真ではちょっとわかりにくいですが、スタンディングデスクになりました。\nタイマーついてるの便利 pic.twitter.com/E9engTIMnM\n\u0026mdash; Jun Ohtani (@johtani) April 30, 2020 Flexispotの天板と足の組み合わせにしました。 前のElectaの天板が明るめの色だったのもあって、メープルの天板です。 組み立てはちょっと大変でした。 足が重たいのと、天板にはネジ穴がなく電動ドライバーもないので、ネジ締めと机を起こすのがちょっと大変です。子供に手伝ってもらいながら組み立て設置をしました。 オンラインミーティングなどのときには基本、立って作業しています。 あとは、デフォルトのタイマー設定のままですが、45分ごとに立ったり座ったりを数回繰り返す感じです。\nAmazon | FLEXISPOT オフィスデスク用天板 スタンディングデスク120×60cm Amazon | FLEXISPOT スタンディングデスク 電動式 昇降デスク メモリー機能付き ブラック EN1B（天板別売り） スタンディングデスクマット フローリングに45分立ちっぱなしだと結構、足の裏がつかれるんですよ。なので、クッション性が高いフロアマットを立ってるときは利用しています。ちょっとめんどくさいのですが、椅子のときは壁に立て掛けて、立つときにマットを敷くようにして使っています。\nちなみに、ウレタン素材なので開封直後はすごい匂いでした。。。 数日は陰干しみたいなのが必要です、ご注意を。 ただ、これを利用してから膝やかかとが痛いことはなくなっています。\nAmazon | 疲労軽減マット スタンディングデスクマット 滑り止め加工 立ち仕事 耐水 耐油 耐菌 (ブラック, 75cm*50cm*2cm) ケーブルトレー スタンディングデスクだとケーブルをぶら下げた状態だと危なそうだなということで、ケーブルトレーも机の下に追加してあります。電源タップを配置して、ディスプレイなどの電源はこちらから取るようにして、ケーブルトレーからは電源タップとスタンディングデスクの電源コードを垂らすという感じです。実際にはLANケーブルも伸びてたりはしますが。。。 また、後で出てくるラズパイ+SSDも最近こちらに移設しました。 最初にチャコールグレーを発注したのですが、配送日が未定になったので、Lサイズのシルバーを発注するという慌てようでした。 結局、今は両方使っています。テーブルタップにラズパイと、結構乗せるものがあるんですよね。見えない場所だし、色が揃ってないのは気にならないかなと。\nAmazon | プラス Garage ワイヤーケーブルトレー Lサイズ 幅63.7cm シルバー Amazon | プラス Garage 配線ケーブルトレー 幅40cm チャコールグレー キーボード+パームレスト 10数年ぶりに外付けキーボードじゃないかな? 少なくともMacに移行してからは、ずっとMac bookのキーボードを使ってました(極稀にMac mini起動後とかにMagic Keyboard使うくらい)。 外出して仕事をすることが多かったのもあり、体をキーボードに合わせる感じでした。\nが、ずっと在宅で仕事をしていますし、ふるさと納税でRealforce(リンクは楽天)がということで、申し込んでみました。2週間ちょっとで到着。 箱が厳重でびっくりしました。\nAmazon | 東プレ REALFORCE SA for Mac ホワイト R2SA-JP3M-WH | Realforce まだ深いキーに慣れつつあると言った感じです。 付属の2mmのキースペーサーでAPCを2.2mmの設定で使用しています。最初は3mm+APC 1.5mmでやっていたのですが、流石にキーが敏感すぎてちょっとキーボードに手をおいたまま考え事をしているだけで「lllllllllll」のようになってしまったので現在の組み合わせに落ち着いています。\nあと、特殊な設定としてはスペースの横のeng/kanaキーを設定でキーロックして使えなくしました。どうも、ご入力の原因になっているようだったので。 日本語の入力切替は、昨日まではCtrl+Spaceを使用していましたが、このブログを書き始めてからCtrl+\\に変更しています。 むかーし、使っていたIME切り替えのショートカットです(知っている人は知っているやつ)。\nマウスは使用しておらず、キーボードの手前にトラックパッドをおいて使っています。パームレストの部分は、サムライズムさんのトラックパッドがきれいに入るmagicTrayPalmです。 Mac book Proと同じような感じでトラックパッドが使えるのがいいですね。 興味がある方は、侍割のリンクをたどってもらうと、初めてサムライズムさんで買い物をする方に限り割引がつくようになってるみたいです(なんと、私もなんか割引になる!)。\nディスプレイアーム 外付けキーボードになったのですが、Mac Book Proの画面も活用したく、さらに上下での配置がやはり目線の移動距離が少ないので気に入っていました。ただ、前回のブログで紹介したアームでは少し高さが足りず。。。 思案しながらAmazonを回遊していたら、同じ会社の新しいアームがあり、調べると高さが取れそうだということで付け替えました。 アーム2本ありますが、今のところ1本だけを使っています。 2本目のアームにカメラを乗せるのもあり?と思いながらまだ試していませんが。玉突き式に前に使っていたアームがサンダーボルトディスプレイ(縦置き)のアームになっています。前にサンダーボルトにつけていたアームは重量オーバーで悲鳴を上げていたので。。。\nAmazon | HUANUO 2画面 アーム デュアル ガススプリング式 スマホ充電器 寝室で利用していた斜めに立てかけるタイプのワイヤレス充電器を作業デスクに持ってきました。 実は部屋に時計がなく、Pixel 3 XLを使っているので、スマホの画面に常に表示されている時計を置き時計の代わりに使えそうだなと (スマホで写真を撮っているので上の画像ではスマホがありませんが)。 結構便利です。ちょっと時間を確認したいときに、メニューバーの時計では流石に小さすぎるのでw\nAmazon | Anker PowerWave 7.5 Stand, Qi ワイヤレス充電器 ミキサー 音声のミキサーです。Yamahaのスピーカーは入力が2系統あるのですが、入力したい音声は3系統あります(ラズパイ4、Mac mini、メインディスプレイ)。2入力を1系統にまとめるプラグを試しに買ってみて、Mac miniとラズパイをまとめてみたのですが、残念ながら切り替わるときに数分無音状態が続くという問題が発生しました。 USB給電できるタイプを購入しました。スライダーとかいらないなと思っていたのですが、電話やミーティング時にBGMの音を下げたりするのに地味に便利だったりします。 ただ、スライダーを動かそうとすると本体も動いてしまっていたので、本体裏に滑り止めを貼ってあります。\nAmazon | Maker hart Just Mixer ステレオ3入力音声ミキサー/電池とUSB電源可能 Webカメラ おっさんの顔がきれいに写っても仕方ないんですが、下からのアングルよりはいいかなぁということと、今後の勉強会で使えそうかな?ということで、購入してみました。 縦でも横でも使える便利なカメラです。また、あんまりないのですが、部屋の中などを写すときにカメラを持ち回せるの便利ですね。 ディスプレイの上に置いてしまうと高さがありすぎるということで、スピーカーの上に乗っけています。仮置きなのですが、このままになるんじゃないかな? 打ち合わせ中は画面共有してることが多いのでオンライン飲み会などで主に活躍してる気も。。。\nAmazon | ロジクール ウェブカメラ フルHD 1080P 60FPS StreamCam C980OW オフホワイト USB-C接続 Mac miniのSSD化 見えないところですが、Mac miniのHDDをSSDに差し替えました。 性能検証用のマシンとしてMac miniを利用し始めたのですが、 計測するたびに速度の差がありすぎるのでおかしいな?と。 よくよく考えてみると、このMac miniはFusion Driveだったんです。。。 開発などで使う分には大容量だし便利だったのですが、負荷計測に利用する場合は挙動をハンドリングできないので、弊害でしかないです。。。 ということで、頑張って差し替えました。想像以上の大手術でした。 「Mac mini HDD 交換」などでググると換装している方たちがいらっしゃいます。興味ある方はググってみてください。\nさて、復路 pic.twitter.com/SwndXPoKqn\n\u0026mdash; Jun Ohtani (@johtani) July 25, 2020 Amazon | シリコンパワー SSD 1TB SATA3 6Gb/s 2.5インチ ラズパイ4 Mac miniの負荷検証マシン化のため+Linuxを触りたかったというのもあり、ラズパイ4を追加しました。 Mac miniは主な使用用途が音楽再生だったのでラズパイ4で肩代わりできるだろう+その他の検証にもラズパイ4が使えそうだと。 現在はUbuntuをインストールして、画面共有で操作しています。\nAmazon | LABISTS Raspberry Pi 4 4B MicroSDHCカード64G まとめ かなり快適になりました。キーボードもうるさくないですし、熱くもありません。マイクのポップガードは意味がなさそうなので外しました。\nまだいくつか気になってるものもあるので、また更新するかもしれません。\n分離式キーボード - 胸を広げた状態でキーを打ったほうがいいのでは?という気がしています。ただ、最近はずっと日本語キーボードを使っているので選択肢が少ないんですよね。。。\nサンダーボルト?USB-C?ドック - MacBook Proのポートがすべて埋まっているし、もう少しケーブルを減らせると幸せになれそうなきが。。。\nモバイルディスプレイ - MacBook Proのディスプレイを使っているのですが、キーボードの上にかぶってるんですよね、結構。。。クラムシェルにしてiPadもしくはモバイルディスプレイに置き換えたほうがスッキリはしそうかなと。ただ、Touch IDが使えなくなったり、クラムシェル状態でMacBook Proの電源を入れられないというはなしなので、あまり意味がなさそうだなというのもあります。\n","date":1599531445,"dir":"post/2020/","id":"d08a3fdc040bbbdd81c9927ce296318c","lang":"ja","lastmod":1599531445,"permalink":"https://blog.johtani.info/blog/2020/09/08/update-working-facility/","publishdate":"2020-09-08T11:17:25+09:00","summary":"自宅環境に少しアップデートがあったので更新版です。 お客さんのおかげで相変わらず自宅で作業させてもらってるのもあり、昨今のコロナウイルスの影響","tags":["misc"],"title":"自宅の作業環境(2020/09)"},{"contents":"Rustで便利なクレートを見つけたので、紹介がてら、自分のメモのためにブログに残しておきます。\nそもそもの問題 Rustで処理を書いていて、なんかちょっと遅いな?どこの処理で時間がかかってるんだろう? ということがありませんか?ありますよね?\nというのを調べるために、最初に思いつくのは自分で計測する方法です。 流石にそれはなぁ、と思ったのでググって出てきた方法を最初は使っていました。\nRustで実行時間計測 3年前の記事ですが、とりあえず計測する分には問題なかったのでこちらの方が書いていたマクロを拝借していました。 が、ちょっと面倒なのが戻り値がある処理などのときに、このマクロを挟むのが結構めんどくさいなと。 また、処理の時間を測りたいのは基本的にはメソッドや関数単位であることが多いです。\nで、さらにググっていて見つけたのが、meteredでした。\nどんなもの? 計測したい部分に#[metric]のようなアノテーションを追加することで計測対象としてくれます。 あとは、計測したものを保存するレジストリという場所を指定するだけです。 処理が終わったタイミングなどで、そのレジストリの内容を出力することで、次の情報を計測することができます。\nHitCount : 実行された回数 ErrorCount : エラーを返した数(Resultを戻り値にしているメソッドが対象) InFlight : 処理中の回数かな? ResponseTime : レスポンスタイム(処理に何秒かかったか) Throughput : スループット(1秒あたり何回呼ばれたか) とりあえず試してみたのは、ResponseTimeとThroughputです。他のメトリクスはまた後日(機会があれば)。 また、metered::metric::Metricトレイトというものが用意されているようで、これを実装した独自のメトリクスも扱うことができるようです。\n使い方 使い方としては次のようになります。\n計測対象となるメソッドがある構造体に、メトリクスを保持するためのレジストリを用意 計測対象にしたい構造体のメソッドに#[measure]を追加(このとき、計測したいものも指定する。) あとは、実行したあとに構造体をダンプするとメトリクスが出力されます。\nレジストリの用意 #[derive(Default, Debug, Serialize)] pub struct NekoParser { metric_reg: NekoParserMetricRegistry, } NekoParserMetricRegistryという型はこのあとのimplのアノテーションで指定する名前になります。 実際にはこの型の構造体を自分で定義する必要はありません。 構造体のderiveでDefaultを指定します。構造体のインスタンス化のときにdefault()メソッドを呼び出して初期化したいためです(おそらくレジストリの初期化をやってくれるのだと思う(要確認))。 レジストリの用意はこれだけです。\nレジストリの指定と計測対象の指定 計測対象側です。少し長いですが、NekoParserのメソッドすべてを掲載しました。 まずは、1行目でレジストリの名前の指定(registry = NekoParserMetricRegistry)、レジストリのフィールド名(registry_expr = self.metric_reg)、レジストリの可視性(visibility = pub(self))を定義します。 2行目では、implブロック全体で計測したいメトリクスを指定しています。今回は、スループットとレスポンスタイムを計測したかったので #measure([ResponseTime, Throughput])]と2種類を指定しています。 メトリクスが2種類のため配列で指定していますが、1種類だけの場合は[]の記号は必要ありません。\nあとは、計測したい各メソッドに#[measure]をつけるだけです。 なお、メソッドごとに#[measure(ErrorCount)]といったかたちで個別にメトリクスを指定することも可能です。 今回はお試しということもあり、すべて#[measure]だけになっています。 アノテーションを付けただけで、メソッド自体を変更はしていません。\n#[metered(registry = NekoParserMetricRegistry, registry_expr = self.metric_reg, visibility = pub(self))] #[measure([ResponseTime, Throughput])] impl NekoParser { #[measure] pub fn load_and_parse_neko(\u0026amp;self) { let file_path = \u0026#34;./data/chap04/neko.txt\u0026#34;; let file = File::open(file_path).unwrap(); let buf = BufReader::new(file); let mut out = File::create(\u0026#34;./data/chap04/neko.txt.lindera.json\u0026#34;).unwrap(); buf.lines().filter_map(|item| item.ok()).for_each(|line| { let tokens = self.tokenize(line.as_str()); self.output_tokens(\u0026amp;tokens, \u0026amp;mut out); }); } #[measure] pub fn output_tokens(\u0026amp;self, tokens: \u0026amp;Vec\u0026lt;Token\u0026gt;, buf: \u0026amp;mut File) { writeln!(buf, \u0026#34;{}\u0026#34;, serde_json::to_string(tokens).unwrap()) .expect(\u0026#34;Error during output json\u0026#34;); } #[measure] pub fn tokenize(\u0026amp;self, line: \u0026amp;str) -\u0026gt; Vec\u0026lt;Token\u0026gt; { let mut tokenizer = lindera::tokenizer::Tokenizer::new(\u0026#34;normal\u0026#34;, \u0026#34;\u0026#34;); let lindera_tokens = tokenizer.tokenize(line); let tokens = lindera_tokens .iter() .map(|lindera_token| { let surface = lindera_token.text.to_string(); let pos = lindera_token.detail[0].to_string(); let pos1 = if pos != \u0026#34;UNK\u0026#34; { lindera_token.detail[1].to_string() } else { String::new() }; let base = if pos != \u0026#34;UNK\u0026#34; { lindera_token.detail[6].to_string() } else { String::new() }; Token { surface, base, pos, pos1, } }) .collect(); return tokens; } } 計測結果の出力 最後は計測結果の出力です。 今回はテストメソッドで実行して結果を出力する処理を書きました。\nlet parser = NekoParser::default();で構造体をインスタンス化します。 あとは、処理をそのまま実行します。\n最後に出力結果をJSON形式の文字列にしてから出力しました。 let serialized ... println!(\u0026quot;{}\u0026quot;, serialized);という形です。 簡単ですね!\n#[cfg(test)] mod tests { use crate::chapter04::answer::NekoParser; use std::path::Path; #[test] fn success_output_tokenlists() { let parser = NekoParser::default(); parser.load_and_parse_neko(); let serialized = serde_json::to_string(\u0026amp;parser).unwrap(); println!(\u0026#34;{}\u0026#34;, serialized); assert!(Path::new(\u0026#34;./data/chap04/neko.txt.lindera.json\u0026#34;).exists()); } } 出力結果 ここまで紹介したものの実行結果は次のような形でした。 レスポンスタイム、スループットともに、最小、最大、99パーセンタイルなどを出力してくれます。 出力はメソッド名ごとにくくられているのでとても便利です。\n{ \u0026#34;metric_reg\u0026#34;: { \u0026#34;load_and_parse_neko\u0026#34;: { \u0026#34;response_time\u0026#34;: { \u0026#34;samples\u0026#34;: 1, \u0026#34;min\u0026#34;: 176128, \u0026#34;max\u0026#34;: 177151, \u0026#34;mean\u0026#34;: 176640.0, \u0026#34;stdev\u0026#34;: 0.0, \u0026#34;90%ile\u0026#34;: 177151, \u0026#34;95%ile\u0026#34;: 177151, \u0026#34;99%ile\u0026#34;: 177151, \u0026#34;99.9%ile\u0026#34;: 177151, \u0026#34;99.99%ile\u0026#34;: 177151 }, \u0026#34;throughput\u0026#34;: { \u0026#34;samples\u0026#34;: 0, \u0026#34;min\u0026#34;: 0, \u0026#34;max\u0026#34;: 0, \u0026#34;mean\u0026#34;: 0.0, \u0026#34;stdev\u0026#34;: 0.0, \u0026#34;90%ile\u0026#34;: 0, \u0026#34;95%ile\u0026#34;: 0, \u0026#34;99%ile\u0026#34;: 0, \u0026#34;99.9%ile\u0026#34;: 0, \u0026#34;99.99%ile\u0026#34;: 0 } }, \u0026#34;output_tokens\u0026#34;: { \u0026#34;response_time\u0026#34;: { \u0026#34;samples\u0026#34;: 9964, \u0026#34;min\u0026#34;: 0, \u0026#34;max\u0026#34;: 143, \u0026#34;mean\u0026#34;: 0.03592934564431955, \u0026#34;stdev\u0026#34;: 1.5152489085107463, \u0026#34;90%ile\u0026#34;: 0, \u0026#34;95%ile\u0026#34;: 0, \u0026#34;99%ile\u0026#34;: 0, \u0026#34;99.9%ile\u0026#34;: 6, \u0026#34;99.99%ile\u0026#34;: 143 }, \u0026#34;throughput\u0026#34;: { \u0026#34;samples\u0026#34;: 174, \u0026#34;min\u0026#34;: 39, \u0026#34;max\u0026#34;: 71, \u0026#34;mean\u0026#34;: 57.103448275862064, \u0026#34;stdev\u0026#34;: 3.8417981983375835, \u0026#34;90%ile\u0026#34;: 60, \u0026#34;95%ile\u0026#34;: 61, \u0026#34;99%ile\u0026#34;: 64, \u0026#34;99.9%ile\u0026#34;: 71, \u0026#34;99.99%ile\u0026#34;: 71 } }, \u0026#34;tokenize\u0026#34;: { \u0026#34;response_time\u0026#34;: { \u0026#34;samples\u0026#34;: 9964, \u0026#34;min\u0026#34;: 12, \u0026#34;max\u0026#34;: 79, \u0026#34;mean\u0026#34;: 16.897230028101177, \u0026#34;stdev\u0026#34;: 2.331145559054724, \u0026#34;90%ile\u0026#34;: 19, \u0026#34;95%ile\u0026#34;: 20, \u0026#34;99%ile\u0026#34;: 24, \u0026#34;99.9%ile\u0026#34;: 46, \u0026#34;99.99%ile\u0026#34;: 79 }, \u0026#34;throughput\u0026#34;: { \u0026#34;samples\u0026#34;: 174, \u0026#34;min\u0026#34;: 39, \u0026#34;max\u0026#34;: 71, \u0026#34;mean\u0026#34;: 57.103448275862064, \u0026#34;stdev\u0026#34;: 3.819293076427424, \u0026#34;90%ile\u0026#34;: 60, \u0026#34;95%ile\u0026#34;: 61, \u0026#34;99%ile\u0026#34;: 64, \u0026#34;99.9%ile\u0026#34;: 71, \u0026#34;99.99%ile\u0026#34;: 71 } } } } 出力内容で気になったのはoutput_tokensとtokenizeのthroughputが全く同じ結果が出ていることです。 なにかバグを踏んでいる気がします。。。(時間を見つけてソースコード読んでみるか。)\n気をつけること meteredの導入時にわかりにくいコンパイルエラーが出たので備忘録として残しておきます。 (下からコンパイルエラーを読んでしまうくせがあったのが問題なのですが。。。) エラーメッセージは次のとおりです。\nerror[E0412]: cannot find type `ResponseTime` in this scope --\u0026gt; src/chapter04/answer.rs:13:12 | 13 | #[measure([ResponseTime, Throughput])] | ^^^^^^^^^^^^ not found in this scope | help: consider importing one of these items | 1 | use metered::ResponseTime; | 1 | use metered::common::ResponseTime; | error[E0283]: type annotations needed --\u0026gt; src/chapter04/answer.rs:12:1 | 12 | #[metered(registry = NekoParserMetricRegistry, /* default = self.metrics */ registry_expr = self.metric_reg)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type | = note: cannot satisfy `_: std::default::Default` = note: required by `std::default::Default::default` = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info) 最初のメッセージにはわかりやすく出ていますが、ResponseTimeをuseせずに利用しようとした場合に以下のようなエラーが出ていました。 ターミナル画面が狭かったのでE0283のエラーが目に入り、何を言ってるんだろう?という状態になってしまいました。 スクロールアップしたら、答えが載っているのに。。。\nコード全体 元ネタはNLP100本ノックの第4章です。 コードの全体はGitHubのソースをご覧ください。\nまとめ meteredを簡単ですが紹介してみました。 導入自体も簡単で、想像していたような使い方ができたので満足しています。 ほかにもプロファイラなどはあるのかもしれませんが、まずはこれを使っていこうかと思っています。\nバグらしきものがありそうだったりするので、そのへんは今後調査してみようかと。 まだ、ちょっと試してみただけなので、metered自体のオーバーヘッドや、独自のメトリクスの実装方法、メソッドではなく関数に対して利用する場合にはどうするのか?などいくつか疑問点があるので、今後試してみてまたブログに残しておこうと思います。\n","date":1599487900,"dir":"post/2020/","id":"827de2d7a9d231f6bcb44caf35896c1f","lang":"ja","lastmod":1599487900,"permalink":"https://blog.johtani.info/blog/2020/09/07/intro-metered-rs/","publishdate":"2020-09-07T23:11:40+09:00","summary":"Rustで便利なクレートを見つけたので、紹介がてら、自分のメモのためにブログに残しておきます。 そもそもの問題 Rustで処理を書いていて、なん","tags":["Rust"],"title":"meteredクレートの紹介"},{"contents":"Rustで言語処理100本ノックの第4章です。\n前回はこちら。\n今回は早めに続きをやりました。 「形態素解析」ですしね。\n第4章の概要 吾輩は猫であるの文章が用意されていて、MaCabで形態素解析した結果をファイルに保存したところからが開始となります。\nが、せっかくRustでやっているのでKuromojiのRust版であるLinderaを利用して形態素解析した結果を保存する部分から作成しました。 3章に引き続き、大きな流れのところの説明だけにしておきます。\n形態素解析 もとのneko.txtが文章が1行ごとになっているので、そのまま1行ずつ読みならが、形態素解析していきます。読み込みの部分は3章とあまり変わらないので割愛します。 以下は、形態素解析の処理と形態素解析結果用の構造体です。\n#[derive(Clone, Debug, Serialize, Deserialize)] struct Token { surface: String, base: String, pos: String, pos1: String, } まずは構造体です。今回の問題では、必要な情報は4種類だったのでそれを構造体にしました。\n表層形（surface） 基本形（base） 品詞（pos） 品詞細分類1（pos1） deriveでSerialize、Deserializeを付与しているのは、形態素解析の結果をJSON文字列として保存し、あとのそれぞれの課題で読み出すためにserde_jsonを利用するためです。\nfn tokenize(line: \u0026amp;str) -\u0026gt; Vec\u0026lt;Token\u0026gt; { let mut tokenizer = lindera::tokenizer::Tokenizer::new(\u0026#34;normal\u0026#34;, \u0026#34;\u0026#34;); let lindera_tokens = tokenizer.tokenize(line); let tokens = lindera_tokens .iter() .map(|lindera_token| { let surface = lindera_token.text.to_string(); let pos = lindera_token.detail[0].to_string(); let pos1 = if pos != \u0026#34;UNK\u0026#34; { lindera_token.detail[1].to_string() } else { String::new() }; let base = if pos != \u0026#34;UNK\u0026#34; { lindera_token.detail[6].to_string() } else { String::new() }; Token { surface, base, pos, pos1, } }) .collect(); return tokens; } 次が形態素解析の処理です。 入力に1行分の文章を受け取り、出力として、さきほどの構造体をベクタに入れたものVec\u0026lt;Token\u0026gt;を返します。 内部ではLinderaのTokenizerをnormalモードでインスタンス化してそのtokenizer()メソッドを叩いているだけです。 インスタンス化のときの第2引数は辞書のディレクトリですが、今回はデフォルト辞書(IPADIC)を利用しています。 戻り値はLinderaが用意したToken構造体なので、これを今回作成したToken構造体に詰め替えているだけです。\n注意点としてLinderaはMeCabとは異なり、未知語(辞書に出てこない単語)の処理が実装されていないので、品詞が\u0026quot;UNK\u0026quot;の場合にはその他の情報が取得できないので、空文字を構造体に設定するようにしました。\n結果の保存 形態素解析の結果はJSONで保存しました。 もとのファイルが1文が1行になっていたので、 1行を読み込み、形態素解析し、それをVecで取り出して、1行1配列JSONの形で保存するようにしてあります。\nfn output_tokens(tokens: \u0026amp;Vec\u0026lt;Token\u0026gt;, buf: \u0026amp;mut File) { writeln!(buf, \u0026#34;{}\u0026#34;, serde_json::to_string(tokens).unwrap()).expect(\u0026#34;Error during output json\u0026#34;); } serde_json::to_stringにVec\u0026lt;Token\u0026gt;を渡しているだけですが、構造体にderiveをつけているのでよしなにやってくれます(便利ー)。\nJSONの読み込み処理 1行1JSONの読み込み処理です。 今回も3章のように読み込みながら、各文章ごとの形態素解析結果に対して処理を実施するために、処理を実行するためのtraitをCommandとして用意し、それぞれの問題で形態素解析結果に対して処理を書くような実装にしました。また、設問37で「猫」と共起している単語を処理するという課題があるので、文章に「猫」が入っているものだけを処理できるようにするためのFilterも用意し、これをJSONの読み込み処理のイテレータのfilterにわたすようにしています。 特にフィルタリングが必要ない場合ように、NonFilterを予め実装済みです。\ntrait Command { fn execute(\u0026amp;mut self, tokens: \u0026amp;Vec\u0026lt;Token\u0026gt;); } trait Filter { fn is_target(\u0026amp;self, line: \u0026amp;str) -\u0026gt; bool; } struct NonFilter {} impl Filter for NonFilter { fn is_target(\u0026amp;self, line: \u0026amp;str) -\u0026gt; bool { true } } // ch04-30. 形態素解析結果の読み込み fn load_json\u0026lt;T: Command\u0026gt;(cmd: \u0026amp;mut T) { load_json_with_filter(cmd, \u0026amp;NonFilter {}); } fn load_json_with_filter\u0026lt;T: Command, U: Filter\u0026gt;(cmd: \u0026amp;mut T, filter: \u0026amp;U) { let file = File::open(\u0026#34;./data/chap04/neko.txt.lindera.json\u0026#34;).unwrap(); let buf = BufReader::new(file); buf.lines() .filter_map(|item| item.ok()) .filter(|line| filter.is_target(line)) .for_each(|line| { let tokens = parse_line_json(line.as_str()); cmd.execute(\u0026amp;tokens); }); } output_tokensではserde_json::to_stringを呼び出してましたが、読み込みでは、serde_json::from_strを使うと構造体にしてくれます。\nfn parse_line_json(line: \u0026amp;str) -\u0026gt; Vec\u0026lt;Token\u0026gt; { return serde_json::from_str(line).unwrap(); } あとは、設問ごとにCommandトレイトを実装していく形です。 たとえば、32.の動詞の原形を出力する場合は次のようになります。\nstruct ExtractVerbBase { out: File, } impl Command for ExtractVerbBase { fn execute(\u0026amp;mut self, tokens: \u0026amp;Vec\u0026lt;Token\u0026gt;) { tokens .iter() .filter(|token| token.pos == \u0026#34;動詞\u0026#34;) .for_each(|token| { writeln!(self.out, \u0026#34;{}\u0026#34;, token.base).expect(\u0026#34;Error during writeln\u0026#34;); println!(\u0026#34;{}\u0026#34;, token.base); }) } } 標準出力とは別にファイルにも出力できるようにExtractVerbBaseにoutでファイルを保持しています。\n34. 名詞の連接 「名詞の連接（連続して出現する名詞）を最長一致で抽出せよ．」という課題だったのですが、最初は読み間違えて、名詞の連接の最も長いものだけを出力するようにしてました。。。 やっぱり、出力結果とかのサンプルは用意しといてほしいなぁ。。。\nimpl Command for ExtractMaxConjunctionNoun { fn execute(\u0026amp;mut self, tokens: \u0026amp;Vec\u0026lt;Token\u0026gt;) { let mut nouns = vec![]; // TODO 参照保持でどうにかしたいけどなぁ。 tokens.iter().map(|token| token.clone()).for_each(|token| { if token.pos == \u0026#34;名詞\u0026#34; { nouns.push(token); } else { if nouns.len() \u0026gt; 1 { self.buffer.push(nouns.clone()); } nouns = vec![] } }); } } 名詞の場合に、nounsにバッファリングしつつ、違う品詞が来たら出力するという処理になっています。 cloneを呼び出していますが、これを参照を引き回す感じにできるといいのかもなぁ(結構めんどくさい)。\n36. 頻度上位10語 頻度を数えるのにはBTreeMapを利用しています。 数えながら、Top10を保持する方法がいい気がしたのですが、いい入れ物を見つけられなかったので、数え上げたあとにBTreeMapのIteratorを回しながら、キーバリューのVecをまず生成します。 その生成したVecに値でソートし、その後Iteratorから最初の10件を取得して表示する方法にしました。\nソートして取り出すという処理がついでにかかっています。。。 BinaryHeapがなにか使えそうな気もしたのですが、いい方法が思いつきませんでした。\nfn print_top10(\u0026amp;mut self) { let mut key_values: Vec\u0026lt;(\u0026amp;String, \u0026amp;u32)\u0026gt; = self.terms_count.iter().collect::\u0026lt;Vec\u0026lt;(\u0026amp;String, \u0026amp;u32)\u0026gt;\u0026gt;(); key_values.sort_by(|x, y| y.1.cmp(\u0026amp;x.1)); key_values.iter().take(10).for_each(|(key, value)| { writeln!(\u0026amp;self.out, \u0026#34;{}, {}\u0026#34;, key, value).expect(\u0026#34;Error during writeln\u0026#34;); println!(\u0026#34;{}, {}\u0026#34;, key, value); }); } まとめ 形態素解析結果をちゃんと眺めてはいないですが、処理としてはこんなところかなと。 グラフはめんどくさいのでスキップしてしまいました。。。 Kibana/Esに食わせて見てみるのもありかなぁ?\n次は係り受け解析です。Rustで使えるライブラリとかあるかなぁ?\n","date":1599445027,"dir":"post/2020/","id":"3c5d4d351e0fb9e33e0e8b6d1d43c0f2","lang":"ja","lastmod":1599445027,"permalink":"https://blog.johtani.info/blog/2020/09/07/reboot-nlp100-ch04/","publishdate":"2020-09-07T11:17:07+09:00","summary":"Rustで言語処理100本ノックの第4章です。 前回はこちら。 今回は早めに続きをやりました。 「形態素解析」ですしね。 第4章の概要 吾輩は猫である","tags":["Rust","nlp100"],"title":"第4章終了(言語処理100本ノック2020)"},{"contents":"Rustで言語処理100本ノックの第3章です。\n前回はこちら。\n少し間が空きましたが、再開しました。 間が空いた理由は。。。「正規表現」ですかね。。。 苦手なんです、正規表現。 なので、28はちょっとギブアップしてしまいました。\n第3章の概要 個別に説明はせずに大きな流れのところだけ。 それぞれの問題の解についてはリポジトリを御覧ください(興味ある人いるのかなぁ?)\n第3章はNDJSON(new line delimited JSON)という、 1行に1JSONという形式のデータを格納したファイルがgzipで圧縮された状態で提供されます。 まずは、このJSONファイルからJSONを読み込むのが主な処理になります。\n読み込んだデータに「イギリス」のWikipediaの記事が入っているので、そこから正規表現で必要なデータを抽出します。\n最後の問題が少し特殊で、抜き出した情報の「国旗」のファイル名を元に、MediaWikiのREST APIを叩いて、結果を取得し、その一部の情報を抜き出すというものです。\nJSONの読み込み処理 gzipファイルを読み込んでから、1行ずつ抜き出してVecに入れる処理が次のようになります。 今回のgzipファイルは大した量が入っていないので、全部先に抜き出す処理としてまとめました。 もっと巨大なファイルの場合は個別のJSONに対する処理を buf.lines().map()のmapのなかで実行する形にすると思います。 gzipのファイルを開くのにflate2というクレート(ライブラリ)を利用しました。便利なのは、BufReaderにlines()というメソッドがあるところですかね。\n// https://docs.rs/flate2/1.0.14/flate2/read/struct.GzDecoder.html pub fn extract_ndjson_from_gzip(input_file_name: \u0026amp;str) -\u0026gt; Vec\u0026lt;String\u0026gt; { let f = File::open(input_file_name).expect(\u0026#34;file not found?\u0026#34;); let gz = GzDecoder::new(f); let buf = BufReader::new(gz); let lines: Vec\u0026lt;String\u0026gt; = buf.lines().map(|l| l.unwrap()).collect(); return lines; } こちらは、上記のメソッドで抜き出したVecを元に、記事の情報を抜き出す処理をしています。 JSONをパースして構造体Articleにデシリアライズするために、serdeというライブラリを使用しています。 serde自体は様々なデータ形式(JSON、YAMLなど)をパースするためのフレームワークです。今回はJSONなので、serde_jsonの実装を利用しています。 また、JSON文字列から構造体にデシリアライズするのを簡単にできるように構造体に#[derive(Deserialize)]をつけています。 あとは、let article: Article = serde_json::from_str(json.as_str())という処理を実行すればserde_jsonがJSONをパースして構造体に変換してくれます。形式がわかっているJSONの扱いはこれが楽ですね。変数に型を明記してあるので、型の推論もしてくれてるようです。\n#[derive(Deserialize)] pub struct Article { title: String, text: String, } // ch03-20. JSONデータの読み込み // https://serde.rs/ pub fn load_json(input_file_name: \u0026amp;str, target_title: \u0026amp;str) -\u0026gt; Vec\u0026lt;Article\u0026gt; { let mut results = vec![]; let ndjson = extract_ndjson_from_gzip(input_file_name); for json in ndjson { let article: Article = serde_json::from_str(json.as_str()).expect(\u0026#34;json parse error\u0026#34;); if article.title == target_title { results.push(article); } } return results; } 後続の処理ではパースしたArticleから記事情報を取得して色々と処理をしています。\n正規表現 正規表現用のクレートregexがRustに用意されています。Regex::new(正規表現)で、正規表現をコンパイルし、あとは、この構造体のメソッドを利用して文字列を処理していきます。 問題では、マッチするかどうか、マッチした一部の文字列を抜き出す、不要なタグを削除するといった処理を正規表現で行いました(Rust書くよりも正規表現の書き方とかを調べるのに大半の時間をもっていかれてます。。。)。\npub fn extract_category_lines(article: \u0026amp;Article) -\u0026gt; Vec\u0026lt;String\u0026gt; { let re = Regex::new(r\u0026#34;\\[\\[Category:(.*)\\]\\]\u0026#34;).expect(\u0026#34;syntax error in regex\u0026#34;); let mut lines = vec![]; article.lines_from_text().iter().for_each(|line| { if re.is_match(line) { lines.push(line.to_string()); } }); return lines; } MediaWiki APIリクエスト処理 最後の問題で国旗のファイル名を元にMediaWiki APIを叩いて、URLの文字列を取得しましょうという問題がありました。 ファイル名をREST APIの引数に渡してHTTP経由でリクエストを送信し、返ってくるJSONレスポンスからURLを抜き出すという処理です。\nHTTPのリクエストの送受信にreqwestというクレートを利用しました。 ちょっと長いけど、APIコールしている箇所はこんな形です。\nこの関数にはasyncとついています。非同期処理の関数です。内部で2回ほど(リクエスト送信の結果待ちとレスポンスのパース待ち).awaitがあります。\nclientに.get(URL)やquery(\u0026amp;[])といったメソッドが用意されているので、URLやクエリパラメータを用意してsend()でリクエスト送信します。\nasync fn call_api(file_name: \u0026amp;str) -\u0026gt; Result\u0026lt;String, String\u0026gt; { let client = reqwest::Client::new(); let file_name2 = format!(\u0026#34;File:{}\u0026#34;, file_name); //let mut file_name2 = file_name.to_string().replace(\u0026#34; \u0026#34;, \u0026#34;_\u0026#34;); let query = [ (\u0026#34;action\u0026#34;, \u0026#34;query\u0026#34;), (\u0026#34;format\u0026#34;, \u0026#34;json\u0026#34;), (\u0026#34;prop\u0026#34;, \u0026#34;imageinfo\u0026#34;), (\u0026#34;iiprop\u0026#34;, \u0026#34;url\u0026#34;), (\u0026#34;titles\u0026#34;, file_name2.as_str()), ]; let result = client .get(\u0026#34;https://en.wikipedia.org/w/api.php\u0026#34;) .query(\u0026amp;query) .send() .await; match result { Ok(response) =\u0026gt; match response.status() { StatusCode::OK =\u0026gt; { let body = response.json::\u0026lt;MediaWikiResponse\u0026gt;().await; match body { Ok(obj) =\u0026gt; match obj.get_url() { Some(url) =\u0026gt; Ok(url), None =\u0026gt; Err(String::from(\u0026#34;Cannot get url...\u0026#34;)), }, Err(error) =\u0026gt; Err(error.to_string()), } } _ =\u0026gt; Err(String::from(format!( \u0026#34;Status code is {}.\u0026#34;, response.status() ))), }, Err(error) =\u0026gt; { let error_msg = format!(\u0026#34;Error occurred... {:?}\u0026#34;, error); println!(\u0026#34;{}\u0026#34;, error_msg.as_str()); Err(error_msg) } } } あとは、呼び出し元で非同期の処理を実行するために、tokioというクレートを利用しています。 block_on()でcall_api()の実行をして、結果が返ってくるのを待ち受けています。結果が返ってきて、問題なければ、call_apiの戻り値Result\u0026lt;String, String\u0026gt;の左側のStringの値が取り出され、get_image_urlの戻り値となります。\nfn get_image_url(file_name: \u0026amp;str) -\u0026gt; String { let mut _rt = tokio::runtime::Runtime::new().expect(\u0026#34;Fail initializing runtime\u0026#34;); let task = call_api(file_name); _rt.block_on(task).expect(\u0026#34;Something wrong...\u0026#34;) } 一応、非同期に関して説明してみましたが、合っているのかどうか。。。 クレートの関係などはまだちょっと自身がないです。。。 あとは、エラーの処理の仕方とかももうちょっと勉強したいかな。\nまとめ 一応、3章を終わらせました。だいぶ強引かつ1つスキップしましたが。。。 次は第4章の形態素解析です。\n","date":1599230785,"dir":"post/2020/","id":"eb2a5824e03996c1966bee38866ce349","lang":"ja","lastmod":1599230785,"permalink":"https://blog.johtani.info/blog/2020/09/04/reboot-nlp100-ch03/","publishdate":"2020-09-04T23:46:25+09:00","summary":"Rustで言語処理100本ノックの第3章です。 前回はこちら。 少し間が空きましたが、再開しました。 間が空いた理由は。。。「正規表現」ですかね。","tags":["Rust","nlp100"],"title":"第3章終了(言語処理100本ノック2020)"},{"contents":"負荷を計測するために、数回、Azure Cognitive Searchのクラスターを起動したり、停止したりしてました。 これは、Terraformでやると楽できるのでは?と思ったので、やってみました。 1パーティションのクラスターなので、全然大したことはないのですが、メモを残しておくためにブログに書いておきます。\n基本的にはTerraformの公式ドキュメントにあったものを自分用に変数を抽出しただけです。\nファイルたち 単にクラスターを起動するためだけなので、2種類のファイルだけ作成しました(1個でもいいかも)。\nvariables.tf - 変数用のファイル。いくつかの設定を変数として定義しました。 terraform.tf - Terraform本体のファイル。 variables.tf まずはvariables.tfです(ファイル内の並びは異なりますが。。。)。terraform.tfで利用する5つの変数です。\nresource_group - リソースグループ名。既存とは異なるリソースグループ名にしました(変に壊してもいいので)。 machine_type - 価格レベル(SKU)。公式ドキュメントに設定できる値の一覧があります。今回はWikipediaのデータを登録していたのでそれが入るサイズにしています。 region - 場所(リージョン)。リージョンの一覧はどこにあるんだろう?これを参考にしましたが。 partition_size - パーティションのサイズ(=Elasticsearchでのシャードかな?)です。今回は1つでの性能を計測したかったので1にしてあります。 search_cluster_name - Azure Cognitive Searchのサービス名。search.windows.net名前空間で一意である必要があったので、他の人が使わなそうな名前をつけています。 variable \u0026#34;machine_type\u0026#34; { default = \u0026#34;standard\u0026#34; } variable \u0026#34;region\u0026#34; { default = \u0026#34;East Asia\u0026#34; } variable \u0026#34;resource_group\u0026#34; { default = \u0026#34;johtani-wiki-test\u0026#34; } variable \u0026#34;search_cluster_name\u0026#34; { default = \u0026#34;johtani-wikipedia\u0026#34; } variable \u0026#34;partition_size\u0026#34; { default = 1 } terraform.tf terraform.tfは以下の通り。Terraformの公式ドキュメントにある例にproviderを追加しただけのものになります。\nprovider - プロバイダーの設定。Azureを利用するという宣言です。features {}がないとエラーになります。空でも必ず指定が必要です。認証周りについては、azure-cli経由で認証する方式を採用しました。azure-cliはHomebrewでインストールしています。 azurerm_resource_group - リソースグループの設定。variables.tfのresource_groupとregionを利用しています。必須項目はこの2種類だけです。 azurerm_search_service - Azure Cognitive Searchの設定。partition_count以外は必須項目です。variables.tfとazurerm_resource_groupの設定を利用しています。今回は利用していませんが、レプリカ数なども指定できるようになっています。 # Azureのproviderを指定。 provider \u0026#34;azurerm\u0026#34; { features {} } # リソースグループの設定 resource \u0026#34;azurerm_resource_group\u0026#34; \u0026#34;wiki-test\u0026#34; { name = var.resource_group location = var.region } # Azure Cognitive Searchの設定 resource \u0026#34;azurerm_search_service\u0026#34; \u0026#34;search_service\u0026#34; { name = var.search_cluster_name resource_group_name = azurerm_resource_group.wiki-test.name location = azurerm_resource_group.wiki-test.location sku = var.machine_type partition_count = var.partition_size } 以上がファイルです。ほぼ公式ドキュメントのサンプル通りですねw\nデプロイとか ファイルの準備ができたら実際にデプロイします。 Azureの環境への認証にはAzure CLIを利用して、事前にログインした状態にします。 実際にデプロイするまでの手順は次のようになります。\naz login - Azureの認証。ブラウザが起動してログイン画面が表示されます。無事認証がOKなら、azコマンドでAzure Cloudの情報が取得できます。 terraform init - 初回だけです。Terraformのワーキングディレクトリの初期化処理を実行します。 terraform plan - Terraform \u0026lt; 0.12の場合は実行。最新版だともういらないみたいだ。 terraform apply - 実際にAzure上にクラスターを起動します。Terraformが隠蔽してくれているので、実際にどんなことをやっているかはわかってないですが。 以上で、Azure Cognitive Searchのクラスターが起動します。 すごく簡単です。Webコンソールでチェックすれば、起動していることも確認できます。\nこの状態では、クラスターが起動しただけなので、あとは必要に応じてデータをロードしたり、アプリから検索したりと行ったことが可能になります。 そのへんの話はまた機会があれば。\nDestroy 今回は負荷テスト用にクラスターを起動していましたので、必要なくなれば、クラスターを削除します。Terraformを導入したもう一つの理由がこの簡略化です。 terraform destroyを実行するだけで、Azure Cognitive Searchのクラスターおよび、リソースグループが削除されます。\nまとめ ということで、ほぼ公式ドキュメントのままですが、TerraformでAzure Cognitive Searchのクラスターを起動する方法の紹介でした。 ブログを書いていて、1点気になったのは、ロケーション(リージョン)の一覧はどこにあるんだろう?という点です。azコマンドとかで出てくるのかなぁ?\n","date":1597742807,"dir":"post/2020/","id":"f5effd616a3f8db6193b482caec37912","lang":"ja","lastmod":1597742807,"permalink":"https://blog.johtani.info/blog/2020/08/18/azure-search-with-terraform/","publishdate":"2020-08-18T18:26:47+09:00","summary":"負荷を計測するために、数回、Azure Cognitive Searchのクラスターを起動したり、停止したりしてました。 これは、Terraformでやると楽でき","tags":["azure search"],"title":"TerraformでAzure Cognitive Searchのクラスターを起動"},{"contents":"先日は「システムの特徴と検索機能について」という感じでふんわり書きました。 まぁ、頭の中でぼんやり考えてることを文章にしてみた感じです。 他にもぼんやりしてるものはいくつかあるので今日も書いてみることに。 検索システム?みたいなツイートも見かけたので、検索システムってこんなイメージですというブログを書いてみました。\n検索システム(機能)を構成するパーツ 今回はシステムに組み込まれる検索機能を構成するパーツについて書き出してみようかなと思います。 パーツといってもユーザー、UI、コンテンツなども入れています。\nユーザー 検索UI 検索窓 オートコンプリート 検索結果画面 ファセット ソート ハイライト 詳細画面 レコメンド 検索エンジン コンテンツ 検索ログ クリックログとかも サービス提供者 ざっくり書くとこんな感じです。 システム構成だったり、機能だったり、アクターだったりといろいろなものが混ざってしまっていますが、登場するものはこんなものです。\nざっくりした繋がりの図はこんな感じです。\nそれぞれの役割について見ていきましょう。\nユーザー サイト、システムのユーザーです。 検索UIを経由して望んだコンテンツを探します。 探す目的は、サイトによって異なります。 「何かを購入(ECサイトやオークション)する」だったり、「情報(レシピや社内文書)を見つける」だったりします。 図では「キーワード」と記載しましたが、最近では自然文(文章)を受け付ける検索もあります。\n検索UI サイト、システムが提供するUIです。ユーザーはこのUIにキーワード(質問)を入力し、検索結果を取得します。 UIにはいくつものパーツがさらに存在します。簡単に例を上げると以下のようなものです。\n検索窓 - キーワードを入れるための入力ボックスです。 オートコンプリート(自動補完) - サイトによっては、検索窓に何かを入力すると、キーワードを保管したりサジェストしたりしてくれます。 検索結果画面 - 質問にマッチしたコンテンツの一覧を表示する画面です。一覧以外にもいくつか情報が表示されます。 検索結果一覧 - コンテンツの一覧です。何かしらの基準(日付順や人気順など)によってソートされたものが表示されます。 ファセット - 検索結果が持っている属性(価格帯、カテゴリ、メーカー名など)の一覧で、絞り込み検索のヒントです。 ハイライト - 入力したキーワードがどこにマッチしたかがわかるように、強調表示されたスニペット(情報の一部)が出ます。 検索APIとUIに分かれている場合が多いでしょうか? 処理の流れとしては、検索窓に入力されたキーワードを検索エンジンに問い合わせができるクエリに書き換えてからリクエストを投げます。 あとは、検索エンジンからのレスポンスにある検索結果を表示できる形に変換して表示するのが役割です。 また、検索ログの出力もこの部分で担当することが多いです(もしくは、検索エンジン自体がログ出力の機能を持っている場合もあります)。\n検索エンジン 検索に特化したデータ構造を内部に持っているサーバーもしくはサービスです。 ElasticsearchやApache Solr、Azure Cognitive Searchなどは転置インデックスと呼ばれるデータ構造になっています。 検索エンジンの検索処理に対しての主な役割は次の2つです。\nクエリにマッチするコンテンツの集合を決定する マッチしたコンテンツを特定の条件で並び替える(ランキング) クエリを受け取り、検索結果のリストを返すのが処理の大きな流れです。 その他に、ファセット、ハイライトといった付加的な処理を実行することがあります。\nまた、データ登録(インデキシング/インデクシング)の処理もあります。\n登録するコンテンツを検索に特化したデータ構造にして格納する 転置インデックスの場合は、入力されたデータ(文章)から単語列を作り出して、単語からコンテンツのIDが判別できる形にする処理になります。\nAlgoliaやElastic App SearchのようなSaaSであったり、RDBの機能を利用するといった選択肢もあります。\nデータソース・コンテンツ 実際に提供したいコンテンツになります。 コンテンツが保存されている場所は、サイトによって異なります。\nWebの検索サイト - インターネット上のホームページ ECサイト - データベースに格納されているアイテムのデータ 社内文書検索 - ファイルサーバーやWikiなどのファイル、文書 といった感じです。 実際には、データソースからコンテンツを検索エンジンに登録する場合は、いくつかの処理(いわゆる前処理)が必要になります。 社内文書検索やWebの検索サイトの場合は、データを収集するためのクローラーが必要ですし、 収集したデータから、検索エンジンに登録するデータを加工したり(HTMLタグを除去したり、メタデータ(URL、収集日、タイトル)を付与したり)もします(ETL処理とか言われる)。\n検索ログ 検索を提供するだけであれば、必要ありません。 が、実際に検索がどのような使われ方をしているか?を知るために必要な機能になります。 この検索ログがユーザーのニーズを読み解くための情報になります。 検索ログには次のような情報が入ります。\n検索窓に入力された文字列 入力された文字列でヒットした件数 検索結果を出したタイミングでのログです。他にも実際にヒットしたコンテンツのIDなどをログに残したり、他のユーザーと区別をつけるために、ユーザーのセッションごとにIDを発行してログに残したりもします。\nまた、検索に満足してもらえているかを見るために、実際に検索結果のどのコンテンツに興味をもったのか?という情報も検索ログとして残すことがあります。クリックログなどとも呼ばれます。検索結果のどのドキュメントが実際にクリックされたか(詳細画面に遷移したか)という情報です。1回の検索結果に対してクリックされるごとにログが残ります。 もちろん、結果に満足しない場合は、クリックされずに、キーワードを変えたり、絞り込み条件がクリックされたりします。\nECサイトなどの場合は更に、実際に購入されたかどうかといった情報もユーザーのニーズを読み解くための情報となります。 詳細画面へのクリックログや購入ログについては、検索以外からの流れ(広告やDMだったり、レコメンドだったり)なども考えられます。 これらのログを元に、検索を改善していくことになります。\nサービス提供者 サイト・システムの提供者です。 コンテンツの準備、検索UIにはどんな物が必要なのか、サイト・システムにとって良い検索とはなにか?、検索ログからユーザーのニーズを分析して何を改善していくのか?といったことを考えます。 例としては次のようなことです。\n検索結果に表示するコンテンツとはなにか? コンテンツの持っている項目・属性の何を検索対象とするか? 検索結果の並び順(ランキング)がどんなものがよいのか? 検索UIにはどんなものを表示するのか? 検索機能を作るときの流れ 検索機能を構成するパーツにどんなものがあるかを紹介しました。 実際にシステムに検索機能を追加する場合は、最低限、次のものが必要になります。\n検索UI 検索エンジン(RDB?SaaS?ミドルウェア?) データソース・コンテンツ とりあえずこれらがあれば、検索機能を作ることはできるかと。 ただ、作っただけでは、いいか悪いかの判断がつかないので、どういった使われ方をしているかを知るために検索ログをとったりして、 改善をしていく必要が出てきます。\nまとめ わかってるよそんなことはと言われそうな感じになったかもしれないですが、 検索の機能を構成するパーツについて紹介してみました。 細かなはなしは色々とありますが、大まかにはこのような役割のパーツがあります。\n実際にはこれらのパーツを用意すればよいわけではなく、それぞれで検索を良くしていくためにどんなことを考えていくのか?などが出てきます。そのあたりの話はまた、別のブログで書いていく感じでしょうか。こんな感じで書いてくと、終わらない気がしてきたけど。。。 次はどんなはなしを書くかなぁ。\n","date":1595907282,"dir":"post/2020/","id":"11a61827e80739a6065960eb188d5758","lang":"ja","lastmod":1595907282,"permalink":"https://blog.johtani.info/blog/2020/07/28/improve-search-no2/","publishdate":"2020-07-28T12:34:42+09:00","summary":"先日は「システムの特徴と検索機能について」という感じでふんわり書きました。 まぁ、頭の中でぼんやり考えてることを文章にしてみた感じです。 他にも","tags":["検索"],"title":"検索システムを構成するパーツ(検索システムに関する妄想その2)"},{"contents":"今年の頭からシステムの検索周りを手伝う仕事をフリーランスとしてやっています。 検索の仕組みを知れば知るほど面白くなってきたからという理由になるのかな? LuceneやSolr、Elasticsearchなどを長く触っているというのもあるかと思います。\nということで、検索についていつも考えています。 頭の中でまとまっていない状況ですが、システムにおける検索機能についていくつか頭の中にあることを書き出して、 いろんな方にダメ出しやコメントをもらいたいなと思ったので、色々と書いてみようかと。 思いつきのままに書いているので、はなしがあちこち飛ぶ可能性もありますが、あしからず。\n検索って難しい 「「検索」とは、データの集合から目的のデータを探し出すこと」By Wikipedia\n一言で「検索」といっても、使う人、ユースケースによっていろいろな「検索」があります。 例えば、新しいスマホを買ったときに、スクリーンロックの時間を設定する機能を「検索」したりします。 また、PCで仕事をしているときに、ファイルの中身をある文字列で「検索」したりもします。 TSUTAYAに行って、欲しかった本がおいてあるかどうか店内の端末で「検索」もします。 Rustを書いていて、こんなことをやるライブラリありそうだよな?と思ってGoogleでウェブの検索をしたりもします。\n私が特にそうだと思いますが、なにかあったらまず検索をするという生活をしています。 ただ、このとき、「検索」といっても望んでいる挙動が違ったりするものです。 以下は自分が「検索」しているときに想定していることになります。\nファイル内の検索をしているときはgrep的な検索を想定していることが多い。 書籍の検索をしているときは、特定の項目(著者など)に対してgrep的な検索を想定しているが、名前の読みなどでも検索されることを想定している(漢字覚えてなかったりする。。。)。 Rustを書いているときに機能をGoogleで検索するときは、いい感じに検索してくれることを望んでいる(入力するキーワードが曖昧なことが多々ある。例えば、そのものズバリの名前をしらないときとか) あくまでも私が想像している挙動です。他の人とは違う可能性もあります。 なので、「検索」といってもさまざまな要素があるし、想定しているシーンも異なるので「難しい」なと思っています。 また、そんな「検索」ですが、世の中的にはあって当たり前だと思われていたり、お金や時間がかかるものと思われてなかったりもします。ま、けどそういったことも含めてやればやるほど面白いなと感じている今日このごろです。\n前置きはこのくらいにして、今回はシステムの特徴と検索機能について感じていることを書いてみようと思います。\nシステムの特徴と検索機能 先ほども書きましたが、検索は今やシステムに欠かせない機能となっています。 が、あればいいというものでもないのではないかなと。とりあえず検索できるべきだということで 検索機能を追加しても使いにくいものや、想定している動きをしない場合は使われないものになってしまいます。\nシステムでの検索機能は特に、「情報検索」(Wikipediaはこちら)と呼ばれたりもします。Wikipediaによるとこんな説明です。\n情報検索（じょうほうけんさく）とは、コンピュータを用いて大量のデータ群から目的に合致したものを取り出すこと。検索の対象となるデータには文書や画像、音声、映像、その他さまざまなメディアやその組み合わせとして記録されたデータなどが含まれる。\n「目的」と呼ばれるものは「ユーザーのニーズ」と呼ばれたりもします。 「合致したもの」というのがシステムが返す「検索結果」になります。検索結果は大体の場合、何かしらの順序でソートされていることが多いです。 ざっくり話をすると、「ユーザーのニーズ」を元に「(何かしらの順序でソートされている)検索結果」を返すという処理です。\nただ、この「ユーザーのニーズ」や「何かしらの順序でソートされている検索結果」はシステムの特性、特徴によってぜんぜん違うものになります。検索エンジンを入れただけで解決するものではありません。\nまた、システムは提供する側のニーズもあります。 ECサイトであればより多くのユーザーに購買してもらったり、 コミュニティサイトの場合は利用ユーザーを増やしてコンテンツや広告の収入を増やしたりといったニーズがあります。\nこれらの両方のニーズが検索機能に影響を与えたりもします。\nいくつか例を上げてみましょう。\n書籍の検索の場合 ユーザーのニーズは、「ある本を探す」ことです。そのためにユーザーがクエリを入力します。 クエリは、例にも出しましたがタイトルや著者名の読みだったりします。 検索窓が1つしかないというよりは、著者やタイトル、出版社などそれぞれの項目ごとに検索できるほうが便利だったりしますよね。 検索結果については、完全一致したものが一番最初に出てきてほしいこともあれば、出版年月日の降順で並べたいことなど、 その時々でやりたいことが変わったりもします。\n場合によっては、説明文などでも検索できると嬉しいこともあります。また、システムからは離れますが、図書館や書店で時々、「〇〇について書かれている本ありますか?」といった聞き方をしたりもします。\nまた、書店としては、探している本を見つけてもらうために検索端末などを用意しますが、そ れ以外の本も買ってもらえるといいですよね。 オンラインの書店などでは、検索結果や書籍詳細の画面に関連書籍が出ていることもあります。\n検索とは少し異なり、探索(なにか面白い本とかないかな?というようなニーズ)をしに、書店に行くこともあります。 書店で平積みされた本やポップなどを見て新しい本に興味を持つこともあります。\nオークションサイトやECサイトでの検索の場合 ユーザーのニーズは、「欲しい物を探す」ことです。 ユーザーが入力するクエリは、幅広いものになると思います。製品の型番を入力する人もいれば、 メーカー名や製品名だったり、ジャンルで絞り込んで検索することもあります。\n探されるもの(コンテンツ、アイテム)も多数に渡ります。 検索窓は1つかもしれませんが、検索結果には、絞り込み条件(ファセット)がいくつか並んで、絞り込んでいける仕組みが用意されていることが多いです。\n検索結果のソートは、価格順だったり人気順だったりします。 ただ、オークションサイトの場合は新しいもの順や、終了日時の早い物順だったりします。\nサイト提供者のニーズとしては、より多くのアイテムを購入してもらうこと(売上)です。 また、オークションサイトの場合は、アイテムを提供している人のニーズも影響してくるでしょう。 売りたい人はより多くの人の目に止まってほしいと思うはずなので、 様々な情報を付与していかに目にとまるか?といったことを考えてくると思います。\nまた、様々な商品を扱うECサイトの場合は、さらに色々と大変になってきます。たとえば、「iPhone」で検索されたときに、 iPhoneそのものが上位に来るべきなのか、ケースなどの周辺商品なのかだったりといった問題が出てきます。 商品の提供者が多数に渡る場合は、同一商品でもさまざまなお店から提供されてしまうために、検索結果一覧に多数同じ商品が並んだりもしますよね。\nレシピサイトでの検索の場合 ユーザーのニーズは「レシピを探す」です。が、探し方はユーザーによって様々です。 冷蔵庫にある材料を入力して検索することもあれば、食べたいものが決まっていてそのレシピを検索することもあります。 このとき、重要なのは類義語だったりするでしょう。食材やレシピは同じものでも様々な名前(例:パクチー、コリアンダー、シャンツァイ(香菜)など)を持っていたりします。また、部位や形によっても名前が変わったりもします。\n検索結果は人気順で並ぶことが多いでしょうか? ただ、レシピの提供がユーザーによるものなのか、サイト運営者が提供しているものかによっても変わってくるでしょう。\nサイト提供者のニーズとしては、レシピコミュニティサイトの場合は、ユーザー数の増加や広告の売上などがあるでしょう。 調味料などのメーカーがレシピサイトをやっている場合は、調味料の売上だったりします。この場合は、検索がどの程度売上に寄与しているのか?などを測ることが難しかったりしそうです。\n社内文書検索の場合 ユーザーのニーズは「文書を探す」です。探し方はファイル名であったり、ファイルのなかに出てくる単語だったりします。 社内用語・略語のような特殊な単語で検索されることもあるでしょう。ユーザーによっては、ぼんやりとした「こんな資料を探している」といったふんわりとした検索をしたくなることもあります。\n検索結果の表示順は「それっぽいもの」が上位に出てくることが望まれそうです。 ただ、古い文書が出てきても役に立たないこともあります。新しい文書のほうが役に立つことが多いので、最近作られたものというのも重要な情報になります。ただし、権限によっては見ることができなかったり、そもそも探すこともNGだったりもします。\n社内文書検索の提供者は、素早く検索できるものを提供することで仕事の効率を上げてもらったり、無駄を省くことができることを期待しているでしょう。\n昔からですが、社内の文書は様々な場所に散らばっていることが多いです。顧客管理システム、ファイルサーバー、Wiki、ウェブサイトなどこれらをまとめて検索できるシステムなどが望まれていることも多いです(使われるかはまた別ですが。。。)。\nスマートスピーカーの場合 ちょっと特殊な面白い例かなと思ってます。 音声で検索(というかお願い?)します。 システムとしては、ユーザーのニーズを理解するのに2段階あるのかなと。\n音声認識 認識した文章・キーワードで検索(場合によってはコマンド発行) これだけでも難易度が増します。\nさらに、画面のないスピーカーの場合は、結果は1件だけになります。これって結構難しいことだと思うんです。 画面があれば、検索結果を上位10件などのリストで表示して、あとはユーザーに選んでもらうことができますが、 音声の場合は1件だけしか返せません。 また、レスポンスタイムもシビアなものだと想定されます。ずっとスピーカーに黙っていられると困りますよね? きっと大変なんだろうなぁ(妄想)。\nこのように、検索と言っても、システムごとに要求・想定されるものは変わってきます。\nまとめ 例をいくつか上げましたが、ざっくりしすぎて発散してますかね。。。 想像している部分もあるので、この通りではないと思います。 ただ、システムによって、「検索」といってもシステムの特性上、 さまざまな物事、思惑が絡んでくるというのは想像してもらえたと思います?(思いたい)。\nシステムに検索機能を追加すると言っても、探したいものが何なのか?、探してもらうものはどういったものなのか?、 検索機能を追加することで何を達成したいのか?など考えることは色々あります。 どうやって、検索機能を実装するのか、その検索機能を実装するためにはどんな情報が必要なのか?などの検索機能のコアな部分を考えるだけでなく、提供しているシステム、コンテンツがどんなものかなど、システム全体を考えながら検索機能を考えていく事が検索をより良いものとして行くことだと思います。\nまた、検索されるものも検索する人もシステムが成長するのに合わせて変化していきいます。システム同様、一度作ればおしまいというものではないので、やることはいっぱいあるのかなと。\n次は、検索のパーツについてなにか書こうかなぁ。\nボヤキ もう少しまとめてから書いたほうがいいのかもなぁ。 もしくは、出てくる要素を整理するとか。 ユーザー、コンテンツ、コンテンツ提供者とかで。 ふんわりとしたブログになってしまった。 個別のシステムごとにもっと書けることもありそう。\n","date":1595842134,"dir":"post/2020/","id":"9da845cd31310b8952efd1be1881e651","lang":"ja","lastmod":1595842134,"permalink":"https://blog.johtani.info/blog/2020/07/27/improve-search-no1/","publishdate":"2020-07-27T18:28:54+09:00","summary":"今年の頭からシステムの検索周りを手伝う仕事をフリーランスとしてやっています。 検索の仕組みを知れば知るほど面白くなってきたからという理由になる","tags":["検索"],"title":"システムの特徴と検索機能について(検索システムに関する妄想その1)"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章 Rust the book - 第9章 Rust the book - 第10章 Rust the book - 第13章 14章は飛ばして、15章です(Cargoはまた別途調べればいいかな?と思って)。\n第15章 スマートポインタ たぶん、これを理解すれば、参照とベクタや構造体とかの組み合わせがもう少し効率よく使えるようになるのかなぁ?\nポインタの強い版? 参照カウント方式のスマートポインタ型 - Luceneとかで実装されてた気がするなぁ 複数の所有者!? DerefとDropトレイトを実装している構造体 ヒープのデータを指すBoxを使用する これはコンパイルエラー。let yのタイミングで借用してるので、書き換えでエラーになる。\nfn main() { let mut x = 5; let y = \u0026amp;x; assert_eq!(5, x); assert_eq!(5, *y); x = 6; assert_eq!(6, x); assert_eq!(6, *y); } こっちはOK。\nfn main() { let mut x = 5; // in stack let y = Box::new(x); // in heap assert_eq!(5, x); assert_eq!(5, *y); x = 6; assert_eq!(6, x); assert_eq!(6, *y); } 余談:コンパイラが変なワーニングを出してくれた。\nuse std::ops::Deref; impl\u0026lt;T, Z\u0026gt; Deref for MyBox\u0026lt;T, Z\u0026gt; { type Target = T; fn deref(\u0026amp;self) -\u0026gt; \u0026amp;T { \u0026amp;self.0 } } struct MyBox\u0026lt;T, Z\u0026gt;(T, Z); impl\u0026lt;T, Z\u0026gt; MyBox\u0026lt;T, Z\u0026gt; { fn new(x: T, y: Z) -\u0026gt; MyBox\u0026lt;T, Z\u0026gt; { MyBox(x, y) } } fn main() { let x = 5; let z = \u0026#34;10\u0026#34;; let y = MyBox::new(x, z); assert_eq!(5, x); assert_eq!(5, *y); } Derefトレイトでスマートポインタを普通の参照のように扱う 参照外し型強制 : 日本語ムズカシイネ Derefを自分で実装しないといけない場面がちょっと想像できてない。たぶん、Boxとかの説明に必要なので出てきたって感じなんだろうけど。 Dropトレイトで片付け時にコードを走らせる こっちは、リソース開放とかでいい感じにできそうだってのはわかった。 Dropはどんなときに実装するんだろう?Tantivyだとオブジェクトプールとかで使ってた。 Rcは、参照カウント方式のスマートポインタ これ、ここで作ったConsのリストを追っかけるためのサンプルも書いてほしい。 #[derive(Debug)] enum List { Cons(i32, Rc\u0026lt;List\u0026gt;), Nil, } fn print_typename\u0026lt;T\u0026gt;(_: T) { println!(\u0026#34;{}\u0026#34;, std::any::type_name::\u0026lt;T\u0026gt;()); } use List::{Cons, Nil}; use std::rc::Rc; use std::borrow::Borrow; fn main() { let z = Cons(5, Rc::new(Cons(10, Rc::new(Nil)))); let a = Rc::new(z); let _b = Cons(3, Rc::clone(\u0026amp;a)); let _c = Cons(4, Rc::clone(\u0026amp;a)); match \u0026amp;(*a) { Cons(v1, v2) =\u0026gt; { print_typename(v2); println!(\u0026#34;{}, {:?}\u0026#34;, v1, v2); }, Nil =\u0026gt; println!(\u0026#34;Nil!!\u0026#34;) }; } RefCellと内部可変性パターン 循環参照は、メモリをリークすることもある ","date":1594288778,"dir":"post/2020/","id":"208a8c072ea521c813b86ca7730eb880","lang":"ja","lastmod":1594288778,"permalink":"https://blog.johtani.info/blog/2020/07/09/hap15-rust-the-book/","publishdate":"2020-07-09T18:59:38+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第15章"},{"contents":"6月7日の週に開催されたBerlin Buzzwordsにオンライン出張してました。\nBerlin Buzzwordsとは? ベルリンで開催されている、Big Data、Scarability、Storage and Searchabilityに関するカンファレンスです。 今年はコロナウイルスの影響で、オンラインで開催されました。 また、同時期に検索に関する他のカンファレンス(以下の2つ)もベルリンで毎年開催されているのですが、今年はこれら3つのカンファレンスが1つのチケットで参加できる形で開催されました。\nMICES - MIX-CAMP E-COMMERCE SEARCH HAYSTACK - The Search Relevance Conference! sponsored by OpenSource Connections MICES、HAYSTACKは初参加ですが、検索に関するいくつかのトピックが聞けたので楽しかったです。\n6/7から6/12まで(がんばって)参加したので、その感想などをブログにとどめておきます。\nオンラインってどんな感じで開催されてた? まずは、オンライン開催がどのような感じだったのかをメモしておきます。\n有料のオンラインカンファレンス(事前にチケット購入が必要) 参加者用Slack カンファレンス数日前まではここで連絡とか質問が可能だった(もちろん、メールも来ましたけど)。 基本的なプラットフォームはBrellaのバーチャルイベントプラットフォーム 参加者同士のSNS機能 - 参加者同士の興味によって参加登録時に似たような人ですよとマッチングしたり。ビデオチャット機能もあり。 カンファレンスのスケジュール確認 - セッションのスケジュールの他に、参加者同士でのチャットのスケジュールも可能。一番便利だったのは自分のタイムゾーンも表示してくれること。 ストリームチャネル - セッションが行われている場所への誘導 スピーカー・スポンサーのリスト - スピーカーやスポンサーを探せる機能。スポンサー企業からは参加者も見ることができる セッションはYouTubeライブ ストリーム中だったらちょっと戻ったり、ポーズもできるので、便利だった セッション後の質疑応答にはJitsiというオープンソース!?のビデオカンファレンスの部屋が用意されてた(GitHubで公開されてるのか。https://github.com/jitsi)。 2日目、3日目はLTとかが終わったあとに、オンライン飲み会やってたっぽい(不参加) 主催者側も初めてだとは思うのですが、目立ったトラブルはなかったです。 ちょっとだけ遅れたりしてましたが、それほど影響はなかったです。 オンラインでの開催の一番のネックは、日本だと時差が辛いということです。 ベルリンが開催地なのですが、スピーカーや参加者はアメリカからの方が結構います。 そのため、開始時間が日本の23時といった具合になりました。\n面白かった\u0026amp;気になったセッション いくつか面白かった\u0026amp;もう一度見ないとなと思ったセッションと感想を。\nNatural Language queries at Salesforce scale セッションのページはこちら(2020年7月現在) Salesforceでどのような自然言語のようなクエリに対して書き換え、サジェストのようなことをやっているか?という話です。 Salesforceはテナント(企業)ごとに、データ構造などがカスタマイズ可能なため、 それぞれ個別に入力クエリ(例: new leads in sf)に対して、どういったパーツ(時間?場所?状態?)なのか?、どのフィールドへの条件なのか?といったものをNERのディープラーニングモデルとして捉えて解析しているという話でした。 企業毎にパーソナライズもされていると。実際にはパイプラインの一部でこの処理をやっており、それ以外にも処理はされているという話もありました。評価の話もされています。\nAMA - AI-Powered Search セッションのページはこちら(2020年7月現在) ManningでMEAP(絶賛書いているところ)のAI-Powered Searchの著者2名がAMA形式でいろんな質問に答えていく感じのやつです。 最初は近況報告(Treyさんがカンファレンス直前に転職してた)と、書籍がどんなものかを簡単に紹介したあと、質問に答えていく形式で2時間あります。ディープラーニングのモデルに関する話なども出てきています。 もう一度見たいと思ってたやつなので見ないとな。。。 (パネルっぽいセッションは、ヒントがなにもないので結構辛い)\nAsk Me Anything: Lucene 9 セッションのページはこちら(2020年7月現在) LuceneのPMCメンバーのUweさんが今後のLucene/Solrのいくつかの質問に答える感じのAMAです。 出てきた話(質問の前の)としては、Lucene 8の現状(Bloc-Max WANDとか)や、Java 11対応になるよとかです。 QAでは、SIMDの話、Approximate Nearest Neighborがどんな感じか?などの話でした。\nFrom commercial search to owned search セッションのページはこちら(2020年7月現在) カルフールスペインがECの検索をどのように導入したかという概要レベルの話でした。 モノリシックなものをマイクロサービスでk8s上に載せ替えたという大きなアーキテクチャ以降の話です。 Empathy.coが提供しているものを最終的には使用したみたいだけど、 どんな検索がされているのかといったニーズの調査ができるようになり、検索に絡んだKPIが改善した話でした。 COVID-19に絡んだクエリの変化についてもちょっと話が出てました。\nNeural Search in Practice セッションのページはこちら(2020年7月現在) Zalandoの検索の一部でNIR(Neural IRモデル)を利用してクエリの改善をやって、それをどうやってトレーニングして、テストしたかなどの話。 NIRを利用することで、複数の言語に対して改善が見られたという話だった。 今までは、クエリをいくつかの処理を元に翻訳して、入力された単語がカテゴリーに対するものなのか、スタイルに関するものなのか?などを判別して、クエリの補強?を行っている手法だった。 これに対して、ディープラーニングでクエリに対するクリックデータを元にトレーニングして、どういうクエリに対してどんなアイテムを出すのか?というモデルで検索を改善していた。 ヒット件数が0件だったり少ないものを対象にして上記の処理を入れているらしい。 (ということで、ディープラーニングをしっかり勉強しないといけないみたいなので、どうにかしたい。。。)\nTop 10 Lessons learned in search projects the past 10 years セッションのページはこちら(2020年7月現在) 10年検索プロジェクトをやってきた10個の気づきという感じのセッション。 ごく当たり前のことなんだけど、検索の導入・改善に関して、こういう事あって、何も考えないとこうなっちゃうよね。 だから、こんなことをやるべきだよね?という話です。 たとえば、検索窓はあるけど分析すらしていない状況(レッスン1)だとまずはこういうのやらないとね。とか、 検索クエリの分析・改善ばかりして、コンテンツの分析・改善を怠っていないか?という当たり前の話です。 当たり前なんだけどまとめてくれてるのは、やはりいいなぁと。\nClick logs and insights: Putting the search experts in your audience to work セッションのページはこちら(2020年7月現在) 検索ログとクリックログがあったときに、どういったことに使えるのかを料理のレシピに見立ててデモをするセッションで説明が面白かったです。 「こんなログがあったときに、ログのこの項目とこの項目を材料にすると、こんなのができますね」というのを、Elasticsearchにログを取り込んで、JupyterNotebookでデモをしていました。やはり動くものがあるとわかりやすいですねぇ。\nMixing and Matching: Diversifying Search Results セッションのページはこちら(2020年7月現在) これまたパネルセッションです。 検索結果の多様性に関するディスカッションでした。 これは、ECだからこその課題でもあるのかなと。検索自体は「何かを見つける」ための手段です。 普通に考えた場合は、ピンポイントで探していたものが見つかるのが嬉しいです。 が、例えば、ユーザーが検索した単語そのものが入っているだけのものが見つかるよりも、似たような商品も一緒に出てきてほしいことありますよね?また、ECサイトだと、回遊してほしいというのもあります。ということで、それぞれの方がどんな観点で多様性を考えているのかという話をするディスカッションになっていました。\nThought Vectors, Knowledge Graphs, and Curious Death(?) of Keyword Search セッションのページはこちら(2020年7月現在) AI-Powered Searchの著者の一人、Treyさんのセッション。ベクトルを検索にどうやって使うのか、 ベクトルで表現できるものはどんなものがあるのか?どんな検索エンジンで使えるのか?という話でした。 歴史的な話も交えつつ、検索だとこのへんで使えるんじゃないか?というような話でした。\n録画は? 気になったセッションをいくつか書き出してみました。 ちなみに、全セッションのビデオが公開されています。興味がある方は、ご覧いただければと。\nThe recordings from this year\u0026#39;s Berlin Buzzwords / MICES / Haystack joint event are now online. You can watch them all on our YouTube channel. Thank you once again to all of our wonderful speakers. https://t.co/hTRDmKNdpd\n\u0026mdash; @berlinbuzzwords@floss.social (@berlinbuzzwords) July 6, 2020 感想そして来年は? 楽しかったです。検索に関する話が色々聞けるのはやっぱ楽しいですね。サイトの特性(ECなのか、Wikipediaなのかなど)によっても「良い検索」の定義も変わるので、サービスなどがどんなものか、そしてそれを良くするためには検索はどんなことができるのか?といった話や、技術的な濃い話までいろいろな話を聞けました。 ただ、パネルは英語の聞き取りが辛いですね。。。あと、時差が。日本にいながらにして時差ボケは辛い。。。 オンライン飲み会には流石に参加できませんでした(4時とか5時から始まるし)。\n来年もオンラインで開催されたら間違いなく参加します。 オフラインのみだった場合はどうなるかなぁ。。。\n","date":1594005164,"dir":"post/2020/","id":"e5cb2e5d501d3db2db5d8f14984a66d4","lang":"ja","lastmod":1594005164,"permalink":"https://blog.johtani.info/blog/2020/07/06/attend-berlin-buzzwords/","publishdate":"2020-07-06T12:12:44+09:00","summary":"6月7日の週に開催されたBerlin Buzzwordsにオンライン出張してました。 Berlin Buzzwordsとは? ベルリンで開催されている、Big","tags":["conference","berlin buzzwords"],"title":"Berlin Buzzwordsにオンライン出張してた"},{"contents":"luceneutil - マニアックなツールのセットアップの続きです。 今回も誰得?なブログなので興味ない場合は飛ばしましょう。\n一応、luceneutilのREADMEにあるlocalrun.pyを動かせるところまでいったんですが、そこで一旦本題を思い返してみました。\nKuromojiの性能が落ちてるらしいし、Analyzer系のベンチマーク測ってるグラフに載せたほうがいいよね。\nこれが、そもそも動かしてみようと思った本題です。 READMEに書いてある手順で動いたんですが、よくよく調べてみると、Analyzer系の性能テストをやってるのは、別物っぽいぞと。 なんとなく、「ソフトウェア考古学」っぽくなってきましたね。\nAnalyzerの性能テストやってるのは? Analyzerのパフォーマンステストのグラフに出てきたTokenizerの名前を元にluceneutilのリポジトリを検索してみました。 EgdeNGrams当たりで検索するとヒットしたのが以下のファイルです。\nsrc/main/perf/TestAnalyzerPerf.java src/main/perf/TestAnalyzerPerf4x.java src/python/sumAnalyzerPerf.py 本命はsrc/main/perf/TestAnalyzerPerf.javaっぽいですね。 これを動かしている人はどれかな?ということで、今度はこのファイル名で検索します。\nsrc/python/runAnalyzerPerf.py どうやら、このPythonのファイルが先程のJavaファイルを実行して、性能を計測しているみたいです。 最初に出てきた、sumAnalyzerPerf.pyはrunAnalyzerPerf.pyの実行結果をAnalyzerの計測結果のグラフに追加する処理をしているようだということまでがわかりました。\nKuromojiをTestAnalyzerPerfに追加してみる 動かす対象がわかったので、あとは、やることを追加しましょうと。\nKuromojiの実行をTestAnalyzerPerfに追加 引数を追加して日本語版のWikipediaのファイルも読み込むようにする runAnalyzerPerf.pyに引数の追加とクラスパスの追加 JapaneseAnalyzerはlucene/analysis/kuromojiにビルドされるのでクラスパスを追加 引数に日本語版のWikipediaのファイルを追加 日本語版のWikipediaのデータの用意 こんなものかな?と。\n1と2はそれほど大変ではないので、3をまずはというところから始めてみました。\nWikipediaのXMLから1行1データのTSVファイルに まずは、どんなファイルを想定して動いているのかな?ということで、英語版のファイルがどんなものかを探してみることに。\nTestAnalyzerPerf.javaでは入力ファイルから1行ずつ文字列を読み込んでAnalyzerに処理させているだけというのがわかっています。なので、とりあえず、1行ずつ読めるような形式だと。 次に、runAnalyzerPerf.pyの55行目でenwiki-20130102-lines.txtというものを読み込んでいます。 が、これがよくわからないw\n前回とりあえず動いたときに、src/python/constants.pyにいろんなファイルへのパスとかが記載されていたのを覚えていたので、その当たりから調べてみます。 52行目に約665万件のドキュメントだというような記載があります。 前回のlocalrun.pyのファイルと似たような構造(1行に1記事が埋め込まれたTSVファイル)だろうと判断して、それを作りそうなプログラムを探してみました。 Wikiとかで検索して見つけたのがこのソースたちでした。\nsrc/python/wikiXMLToText.py - それっぽい名前ですよね? 中身を見ると、第1引数のファイル(XML)からpageタグごとにデータを抜き出し、処理をしてからタブ区切りで第2引数のファイルに書き出してます。 src/python/WikipediaExtractor.py - これもそれっぽいですね。 WikipediaExtractory.pyは界隈では有名なhttps://github.com/attardi/wikiextractorみたいです。こっちはなんとなく使い方はわかっています。 src/python/combineWikiFiles.py - これまたそれっぽい。 中身を見ると、1番目のコードで出力したデータに、2番めのコードで出力されたデータを元になにかしら処理をして、引数で与えられたファイルに出力する感じになってます。 ということで、完全に憶測ですが、日本語のWikipediaのXMLファイルを元に次のような流れでファイル作ってみればいいのかな?と。\njawiki-20200620-pages-articles.xml.bz2をwikimediaからダウンロードして、unbzip2で展開 python src/python/wikiXMLToText.py jawiki-20200620-pages-articles.xml jawiki-lines.txtで、1行ごとのデータを作る ちなみに、このプログラムは2箇所ほど修正しました。usernameタグが存在しないpageが出力されなさそうなので、デフォルトでusername: \u0026quot;\u0026quot;みたいなデータをattrってディクショナリに設定しました。 cat jawiki-20200620-pages-articles.xml | python -u src/python/WikipediaExtractor.py -b102400m -o extractedで別途XMLからデータを抽出 python src/python/combineWikiFiles.py jawiki-lines.txt extracted/AA/wiki_00 jawiki-20200620-lines.txtで2と3の出力をかけ合わせる で、まぁ、一応ファイルはできたんですが。。。 前回のブログ記事でセットアップしたときにダウンロードされたファイルはtitle、日付、本文の3つのカラムしかないんですが、上記の手順で作り出したファイルにはいろんなカラムが存在するんですよね(2が出力する項目が結構ある)。。。\n性能テスト用プログラムの書き換え 入力ファイルは出来上がったので、あとは、性能テストを走らせる部分の修正です。 修正部分はプルリク見たほうが明確なので省略で。\n実行してみた で、実行してみました。 せっかくなので、ブランチをbranch_8_5とmasterを対象にしてやってみました。 実際にはsrc/python/runAnalyzerPerf.pyにディレクトリ名やブランチ名が直書きされてたので書き換えつつ実施した結果はこちら。\n他の英語系のAnalyzerと同じグラフに載せてみたのですが、遅いので、下の方に表示されてます。 で、下に凹んだ部分(23 Juneのところ)がbranch_8_5で実行したときの性能値でした。 実際に遅くなってますね。ただ、他のAnalyzerの振れ幅も大きいので、別のグラフにしたほうがわかりやすくなるのかもなぁと思った次第です。\nということで、一応動いたんでプルリク出してみました。 採用されるかなぁ?\n一応誰得ブログはこれでおしまい。 Noriとかもこの感じで対応できるんじゃないかな?\n","date":1593050518,"dir":"post/2020/","id":"bbd2824ff0d5b801bb6f5da3a2a1a888","lang":"ja","lastmod":1593050518,"permalink":"https://blog.johtani.info/blog/2020/06/25/analyzer-perf-test-with-luceneutil/","publishdate":"2020-06-25T11:01:58+09:00","summary":"luceneutil - マニアックなツールのセットアップの続きです。 今回も誰得?なブログなので興味ない場合は飛ばしましょう。 一応、luceneutilのREAD","tags":["lucene"],"title":"luceneutil - Analyzer性能テストへのkuromojiの追加"},{"contents":"LuceneのFSTの修正に関連して、Kuromojiのパフォーマンス問題が出ているようです。 この問題自体はLucene 8.6.0以降で直る予定のようなのです(Elasticsearchへの影響範囲についてはこれが参考になるかな?)。 で、これに関連して、ベンチマーク計らないとねという話が出ていて、 昔から、LuceneのMikeさんがやっているベンチマークのグラフに載せるのがいいよねという話になっていました。 どうも、これについては、Luceneの中にあるbenchmarkというプロジェクトではなく、MikeさんのGitHubリポジトリにあるプログラムで計測しているようです。\nじゃあ、手元でこれどうやって動かすんだろう?ということでやってみたブログになります。 おそらく、99.99%の人は興味ないと思うのでスルーしていただくのがいいと思います。備忘録のために書いてます。\nとりあえずgit clone 公開されているリポジトリはこちらです。\n手順通りに? とりあえず、READMEにセットアップなどのやり方があったんで追っていくことに。 とりあえず動くまでの手順は以下のとおりです。\nディレクトリを決める $LUCENE_BENCH_HOMEが起点になります。名前は何でもいいみたいです。 cd $LUCENE_BENCH_HOME リポジトリをクローン - git clone https://github.com/mikemccand/luceneutil.git utilです。 コレ自体は問題なし。 cd util セットアップスクリプトを実行 - python src/python/setup.py -download ここがすごく時間かかります。6GBのファイルをゆっくりダウンロードしてきますので、一晩置いておきましょう(起きたら終わってた) $LUCENE_BENCH_HOME/dataにenwiki-20120502-lines-1k.txt.lzmaとwikimedium500.tasksいうファイルがダウンロードされている。 ダウンロードした圧縮ファイルを展開 - unlzma enwiki-20120502-lines-1k.txt.lzma macOSにlzmaのコマンド入ってるんですね。知らなかった。 終わったらcd ../で$LUCENE_BENCH_HOMEに戻っておく ベンチマーク対象となるLuceneを用意 - git clone https://github.com/apache/lucene-solr.git READMEにはlucene_candidateとlucene_baselineって名前でって書いてあったのですが、これだと、この後の実行フェーズでエラーになりました。 trunkとpatchというディレクトリにそれぞれ変更しました。localrun.pyを実行したらこのディレクトリ名だったので(相変わらず、自分、行きあたりばったりな対応してるなぁ。。。) とりあえず動くかどうかを確認したかったので、trunkとpatchはどちらもリポジトリをcloneしたものになってます。動いたのを確認したら、タグを指定して比較したいブランチをチェックアウトする予定。 trunkとpatchをビルド - ant jar * localrun.pyを実行 - cd utilそして。。。 5.で記述したディレクトリ以外に1箇所Pythonのコードを書き換えた。 src/python/benchUtil.py内部にhppc-0.8.1.jarのファイルの存在チェックをしているのだが、2020/06/23時点でのLuceneのリポジトリの依存関係だとhppc-0.8.2.jarになっており、ファイルが見つからないエラーが出たため、0.8.2に書き換えた。970行目付近。 改めて実行したら成功した。 まだ途中 とりあえず、実行するところまではできましたが、結果の見方とかちゃんと調べないとなぁ。 いくつかローカルで対応したものについてはあとでGitHubにIssue立てとくべきだな。\nと、動くのを確認したので、日本語周りの準備をしてみてるところです。\n終わったこと\n日本語のWikipediaのデータjawiki-20200620-pages-articles.xml.bz2をダウンロードして展開 試している途中\nWikipediaExtractorでXMLからデータを抽出 - cat ~/tmp/wiki/jawiki-20200620-pages-articles.xml | python -u src/python/WikipediaExtractor.py -b102400m -o extracted これは手順が違うかも???? python src/python/wikiXMLToText.py ~/tmp/wiki/20200620-pages-articles.xml ./hoge.txt これで、title、日付、本文が抜き出せそう? この後にcombineWikiFiles.pyの実行かな? って感じです。 誰得だろうこれ???\n","date":1592917109,"dir":"post/2020/","id":"8a1ea5d5cf843bc5955a94cfcc321e92","lang":"ja","lastmod":1592917109,"permalink":"https://blog.johtani.info/blog/2020/06/23/how-to-use-luceneutil/","publishdate":"2020-06-23T21:58:29+09:00","summary":"LuceneのFSTの修正に関連して、Kuromojiのパフォーマンス問題が出ているようです。 この問題自体はLucene 8.6.0以降で直る","tags":["lucene"],"title":"luceneutil - マニアックなツールのセットアップ"},{"contents":"Azure Cognitive Searchで日本語を扱うときに、形態素解析器を使いたい場合、2種類のAnalyzerが用意されています。今回はこれらの違いがどんなものかを見ていくことにします。\nAnalyzerとは? まずは、その前にAnalyzerとは何者か?というのを少しだけ。 Azure Cognitive Searchは転置インデックスを内部で作成して、検索を行っています。 この、転置インデックスは、「単語」がどのドキュメントに入っているか?を素早く見つけることができるデータ構造となっています。\nAzure Cognitive Searchは、この「単語」を入力された文章から生成するときに、Analyzerというものを利用します。 Analyzerは入力された文章をある規則に則って単語に分割する機能です。 この「ある規則」が、各種言語や用途によって様々に用意されています。 今回はこの中のja.luceneとja.microsoftという2種類のAnalyzerについて違いを見ていきます。\n2種類のAnalyzerの違いはどんなもの? このAnalyzerの挙動を見るためのエンドポイントとしてanalyzeというAPIがあります(詳細は昔のブログを参照)。\nこのAPIを利用して、Wikipediaのいくつかの文章を単語に区切って見て、 ja.microsoftがどんな動きをしているのか想像してみます(残念ながらja.microsoftの仕様?や挙動についてはページが見つからないため)。\nもとの文章と解析結果(一部抜粋) 文章は、手元のElasticsearchに登録したjawikiのデータからランダムに抽出しています。また、自前のツールで生成したWikipediaのデータなので、まだ一部、見苦しい文字列になっています(そっちもなおさないと)。\n1. 砂川（熊本県） thumb|250px|right|上砂川橋より上流方砂川（すながわ）は、熊本県宇城市・八代郡氷川町を流れる二級河川。\nこの文字列から抽出された単語で特徴的なものを一部抜粋しました。\nja.microsoft ja.lucene 250px 250 px 上砂 上, 上砂川 川橋 砂川 橋 宇城 宇 市 城市 二級 二 ^ 級 まず、最初の250pxですが、ja.microsoftでは、pxが単位であると判定しているのか、数値と合わせた単語として抽出されています。この場合、250で検索しても、この文字列はヒットしない形になるので、ノイズが減ることが考えられるかと。\n上砂川橋という文字は、分割の仕方が別れました。 ja.luceneでは、上砂川という単語が地名として辞書に存在するために、このような分割になっています。ja.microsoftのデータは品詞の情報が取れないのですが、上砂、川橋ともに、名詞として辞書に存在しているのではないかなと。ja.luceneには川橋という単語は存在していないようでした。\n宇城市(うきし)については、2005年に合併でできた市のようで、ja.luceneが利用している辞書には存在しない可能性があり、宇城という文字が抽出できてないと思われます。\n最後は二級です。ja.luceneでは、数字と助数詞として分割されています。こちらも何かしらのロジックにより、二級という1単語でヒットできるように数字と単位?が合わせた単語で出てくる仕組みがja.microsoftなのかなと。\n2. UEFA U-18女子選手権2000 UEFA U-18女子選手権2000は第3回目のUEFA U-18女子選手権である。決勝トーナメントは2000年7月27日から8月4日までフランスで行われ、ドイツが初優勝を果たした。\nこの文字列から抽出された単語で特徴的なものを一部抜粋しました。\nja.microsoft ja.lucene u-18, u u 18, nn18 18 第3回目 第 3 回 目 トーナメント, トナメント トーナメント 2000年 2000 年 7月 7 月 27日 27 日 数字を含む単語第3回目や2000年、7月などは、ja.microsoftは先程と同様、数字と単位の組み合わせを1単語として出力しています。\nまた、トーナメントという単語をトナメントという形で、長音を除去した形で出力しています。 今回の文字列ではないですが、この他に、センターをセンターとセンタの2パターンの単語で出力するといったことを行っています。 ja.luceneの場合、単語の最後に長音がある場合だけセンタとして、長音を除去した単語が出力されます。 これは、長音の表記ゆれに対応するためではないかなと。たとえば、インターフェースとインタフェース、インターフェイスのように、人や文章によって、間にでてくる長音を使ったり使わなかったりという表記ゆれに対応するためだと思われます。 その他にも、イプロゥヴェトをイプロゥベトに、ネクストをネキストに、バラエティをバラエチにも変換するなどといった処理をしてくれるようです。カタカナの表記ゆれには強そうですね(これどうやってるんだろう?)。\nja.microsoftでは、nn18というちょっと変わった単語も出てきていました。純粋な数字の場合はnnと入力してくれるようで、数字だけで検索したい場合に利用できるのかな?これはドキュメントに書いておいてほしいかも?\n共通点 ja.lucene、ja.microsoftともに、共通している動作として、「てにをは」といった単語は除去されていました。違いがあるものとしては、「より」(助詞-格助詞-一般)、「されている」(動詞-自立、動詞-接尾、助詞-接続助詞、動詞-非自立)、「ある」(助動詞)といったものはja.microsoftでは除去されずに出てきていました。 ストップワード的に「てにをは」あたりを除去をしている感じでしょうか?\nアルファベットで構成されている単語についても、基本はそのまま出力される挙動のようでした。\nじゃあどっちがいいの? 残念ながらどちらがいいかは、一長一短かなぁと。 ja.luceneに関しては、Luceneの仕組みを利用しているので、Elasticsearchなどを使えば、個別の単語についてより詳細の情報を取得することが可能です(品詞、読みなど)。ja.microsoftについては、残念ながら手の入れようがないので、そういう動きのものだという割り切った使い方になるでしょうか? ただ、長音の除去による表記ゆれなどについては、便利な機能なので、そのあたりの問題に対応したい場合は、ja.microsoftを活用するのも良いかと思います。\n個人的には、より細かい単語としてインデックスに登録できるもののほうが、柔軟な検索には対応できるのではないかなぁと考えています(Kuromojiの辞書をUniDicにするとか?も考えますが、これはAzure Searchではできないですが)。\nまとめ Wikipediaのデータをいくつか使って、ja.microsoftとja.luceneの違いについて、考察してみました。何かの役に立てばと。 他に、これはどんな感じになるの?などありましたら、コメントいただければと。\n","date":1591692240,"dir":"post/2020/","id":"82a115ab8d617e4e96813587fe3a6049","lang":"ja","lastmod":1591692240,"permalink":"https://blog.johtani.info/blog/2020/06/09/difference-analyzers-in-azure-search/","publishdate":"2020-06-09T17:44:00+09:00","summary":"Azure Cognitive Searchで日本語を扱うときに、形態素解析器を使いたい場合、2種類のAnalyzerが用意されています。今回はこれらの違いがどんなもの","tags":["azure search","kuromoji"],"title":"Azure Cognitive Searchでの日本語向けAnalyzerの違い"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章 Rust the book - 第9章 Rust the book - 第10章 11章、12章はちょっと飛ばして、13章です。\n第13章 イテレータ、クロージャです。 12章の話もちょっと出てくるのか。\nクロージャ 基本的に、「変数には値が束縛されている」という固定観念がずっと頭にこびりついたままなので、クロージャに慣れないんだろうなぁ。そろそろこの固定概念をどうにかしないと。\n匿名関数で、変数に保存したり引数に渡せる ちょっと面白い話(ワークアウト)で実際に考えられる手法の説明がいくつか行われる 関数でリファクタリング これが自分がよくやるパターンかなぁ。クロージャになれてないので。。。 クロージャーを変数に束縛 呼び出しは関数みたいな感じ(ここで少し混乱) これだと、結局呼び出されたタイミングが複数回あるよね? -\u0026gt; あはりそうだった ここで、閑話休題で、クロージャの型推論とか注釈の話。 クロージャは狭い文脈だし、外に公開しているものでもないので、戻り値なども定義してなくてもいいよねとのこと。書くことも可能?なので、書いてわかりやすくするのもありなんだろうな。\n推論についてはこれまで通りで、2回異なる型の変数で呼び出すと、2回目で怒られていた。\n遅延評価(クロージャを保持する構造体!?) Fnトレイト トレイトとMatchの組み合わせだからこのへんで説明する形になるのか。 これを真似すれば、いくつか処理を簡素化できるかもしれないなぁ、たしかに。 なければ実行するみたいな処理を書きたいことがよくあるし。Javaだとnullで定義しといて、nullだったらみたいなのがあるから。 Cacherはサンプルだからこの名前でいいけど、自分だと、どんな名前にするかなぁ?\n振る舞いは難しくなるのか。Cacher実装の限界を読むと。\n関数にするとスコープが変わるのでアクセスできなくなると。。。コンパイラが教えてくれるのは便利だな。\n環境から値をキャプチャする3つの方法\n多分この話が一番クロージャに意味がある話なんだと思う。 イテレータ 回しましょう。\n便利。ただ、こういう書き方に自分が慣れてないので、そっちを補正しないとなぁ。 どれがイテレータ?っていうのを判別するのがちょっとむずかしい(慣れの問題かなぁ) イテレータアダプタ便利。どんなのがあるのか?とかがやっとわかってきた。 パフォーマンスに関しては、うーん、どうなんだろう?という感想だった。 ","date":1591259849,"dir":"post/2020/","id":"e74d071363645a588f858b35231128c4","lang":"ja","lastmod":1591259849,"permalink":"https://blog.johtani.info/blog/2020/06/04/chap13-rust-the-book/","publishdate":"2020-06-04T17:37:29+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第13章"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章 Rust the book - 第9章 第10章 ジェネリック、トレイト、ライフタイムです。 手強そう。\nいきなり関数の切り出し方みたいな話が始まって面食らいました。\nジェネリックなデータ型 ジェネリックはJavaにもあるので、それほど理解に苦しむことはなかったです。 また、OptionやResultですでに経験済みでしたし。\nただ、impl\u0026lt;T\u0026gt; Point\u0026lt;T\u0026gt;{、このメソッド定義は少し最初は戸惑いました。 言われてみれば、なるほどなんですけど。\nコンパイル時にコンパイラが単相化を行うことにより、必要最低限なコードを生成してくるというのは理にかなっているなぁと。\nトレイト: 共通の振る舞いを定義する 出だしにもありますが、「インターフェイス」という機能に類似していると考えると割とすんなりと理解が進みました。 ただ、Javaだと、インターフェースはクラスとセットなため、トレイとの実装に関する記述方法は少し戸惑いが。\nデフォルト実装との組み合わせはAbstractに似た処理になるなと考えながら読みすすめました。\n「トレイト境界」という日本語には少し違和感を覚えましたが、線引をして、制限をかけるという理解でいいのかな?\n実際には#[derive()]などで、トレイトを自分で実装する必要がないなどの、便利機能も用意されており、このあたりのコードの追い方がまだ少し慣れていないかもなぁと。便利なんですけど。。。\n少しだけ気になったので、動作確認したのは次の実装です。\nトレイトで宣言されている関数と構造体が独自に実装する関数の名前がかぶるとどうなるのかという実験です。 構造体独自のメソッドが優先される感じになりそう。\npub struct Tweet { pub username: String, pub content: String, pub reply: bool, pub retweet: bool, } pub trait Summary { fn summarize_author(\u0026amp;self) -\u0026gt; String; fn summarize(\u0026amp;self) -\u0026gt; String { // {}さんからもっと読む format!(\u0026#34;(Read more from {}...)\u0026#34;, self.summarize_author()) } } impl Tweet { fn summarize_author(\u0026amp;self) -\u0026gt; String { format!(\u0026#34;hoge {}\u0026#34;, self.username) } fn to_string(\u0026amp;self) -\u0026gt; String { format!(\u0026#34;fuga\u0026#34;) } } impl Summary for Tweet { fn summarize_author(\u0026amp;self) -\u0026gt; String { format!(\u0026#34;@{}\u0026#34;, self.username) } } pub fn summary\u0026lt;T: Summary\u0026gt;(hoge: \u0026amp;T) { println!(\u0026#34;{}\u0026#34;, hoge.summarize_author()); } pub fn main() { let tweet = Tweet { username: String::from(\u0026#34;horse_ebooks\u0026#34;), content: String::from(\u0026#34;of course, as you probably already know, people\u0026#34;), reply: false, retweet: false, }; println!(\u0026#34;{}\u0026#34;, tweet.summarize_author()); summary(\u0026amp;tweet); println!(\u0026#34;{}\u0026#34;, Summary::summarize_author(\u0026amp;tweet)); } ライフタイムで参照を有効化する 言われてみればそうですが、プログラマが色々考えないとまぁ、行けないんですねという感想。\nただ、借用チェッカーが賢くやってくれるおかげで、全てにライフタイム注釈をつけなくて良くなっているというのがわかりました。 逆に言うと、なんとなくRustを書き始めてしまったので、それを知らずに書いたせいで、コンパイラに怒られてても「?」となっていたのかと。。。\n疑問点がいくつかあって、\n通常はどんなライフタイム注釈をみんな書いてるんだろう?'aとかざっくりしすぎてる? 1つのメソッド、関数にライフタイム注釈が大量に出てくるような書き方をした場合は設計がおかしいのでは?って考えたほうがいいのかも? ジェネリックな型とライフタイム引数の順序を入れ替えてみても動くだろ?とおもって入れ替えてみたら怒られた。 あとは、構造体+ジェネリックが絡んできたら少しこんがらがってきそうっという感じです。 まぁ、これから先は実際に書いてみないことにはわからないんだろうなと。\nまとめ 読みました。 実際にはプログラムを書きながら慣れていく感じだろうなぁと。 まだまだ、あれ?ジェネリックってどう書くんだっけ?とか、ライフタイム注釈どうやって付けて、使うときはどうすんだ?みたいになりながら、 出てくるサンプルを少し変えてみてはどうやって動くんだろうこの場合?みたいなことをやってました。 次は、11章、12章を少しだけ自習しつつ、13章に入る予定です(知り合いと一緒に読みすすめてる)。\n","date":1590656815,"dir":"post/2020/","id":"163beeae9620c1a6a46a38aa7ebd9663","lang":"ja","lastmod":1590656815,"permalink":"https://blog.johtani.info/blog/2020/05/28/chap10-rust-the-book/","publishdate":"2020-05-28T18:06:55+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第10章"},{"contents":"今回はAzure Cognitive SearchのSDKを利用したアプリケーションが、実際にAzure Cognitive Searchに対して送信しているリクエストのパラメータとボディをログに保存する方法について紹介します。\n動機 アプリケーションでリクエストを組み立てて、SDK経由で送信していると、最終的にAzure Cognitive Searchに対して送信されているリクエストのパラメータや検索条件などをひと目で見たいことがあります。 アプリケーションでは、ソート条件や、クエリ文字列の組み立てなどの処理は異なる場所で行われたりしますので。\nまた、公式リファレンスでは、機能の説明はRest APIの使い方と組み合わせで説明されることが多いです。\nということで、SDKを利用しているアプリからAzure Searchへ送信されているリクエストをログに保存する方法を調べてみました。\n方法 調べてみるといくつかの手段を取ることができそうだとわかりました。実際に調べて実装する方法を4種類ほど試してみたのでブログに残しておきます。なお、2020年4月時点でのSDKとAzureの仕組みに基づいたブログになります。最新版ではお手軽な方法があるかもしれません。\nDelegatingHandlerを利用する ServiceClientTracingの機能を利用する Azure Application Insightsを活用する Azure Cognitive Searchのコンソールにある診断情報の機能を利用する 1、2はAzure Cognitive SearchのSDKのリファレンスから当たりを付けて見つけた方法です。 3はApplication Insights、4はAzure Cognitive Searchの機能になります。 これらの方法について個別に説明していきます。\n1. DelegatingHandleを利用する まずは、SDKでロギングの機能がないかを調べて見つけた機能がこちらです。 SDKのSearchServiceClientのコンストラクタの引数にDelegatingHandlerというものが渡せることを発見しました。\nこれは、.NET FrameworkのHttpのAPIに存在するクラスで、HTTPのクライアントがHTTPの送受信時に、処理を挟むことができる機能です。フレームワーク側で、LoggingHttpMessaggeHandlerというクラスを用意してくれていましたが、残念ながらこちらは、リクエストとレスポンスのヘッダのみをロギングするクラスでした。 ということで、リクエストボディをログに出力したい場合は独自に拡張してやる必要があります。なお、ロギングにはMicrosoft.Extensions.LoggingのILoggerを使用します。\nまた、Azure Cognitive SearchのSDK側に違う問題点もありました。チュートリアルにあるように、検索するときには、SDKは次のような使い方を想定しています。\n// Create a service and index client. _serviceClient = new SearchServiceClient(searchServiceName, new SearchCredentials(queryApiKey)); _indexClient = _serviceClient.Indexes.GetClient(\u0026#34;hotels\u0026#34;); インデックス用のクライアントを取得するために、GetClient(インデックス名)というメソッドを使用します。このGetClientメソッドのバリエーションとして、DelegatingHandlerを受け取るメソッドがないのです。。。\nということで、DelegationHandlerを活用する方法としては、以下の2つを実装する必要があります。\nCustomなLoggingHttpMessageHandlerクラスを実装 GetClientと同等の処理をDelegatingHandlerを引数にしたものを実装する 以上の2つを実装し、アプリケーション側から2で作成したGetClientを呼び出すことで、リクエストをボディも含めてログ出力することが可能になります。以下は実装例です。\nCustomHttpMessageHandlerクラス。\nusing System; using System.Collections.Generic; using System.Diagnostics; using System.Net.Http; using System.Net.Http.Headers; using System.Text; using System.Threading; using System.Threading.Tasks; using Microsoft.Extensions.Logging; namespace AzureSearchSample { public class CustomLoggingHttpMessageHandler : DelegatingHandler { private readonly ILogger _logger; private readonly bool _logContent = false; public CustomLoggingHttpMessageHandler(ILogger logger, bool logContent) { if (logger == null) { throw new ArgumentNullException(nameof(logger)); } this._logger = logger; this._logContent = logContent; } protected override async Task\u0026lt;HttpResponseMessage\u0026gt; SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) { if (request == null) { throw new ArgumentNullException(nameof(request)); } await Log.RequestStart(this._logger, request, this._logContent); var stopwatch = new Stopwatch(); HttpResponseMessage response = await base.SendAsync(request, cancellationToken).ConfigureAwait(false); stopwatch.Stop(); await Log.RequestEnd(this._logger, response, stopwatch.Elapsed); return response; } private static class Log { private static class EventIds { public static readonly EventId RequestStart = new EventId(100, \u0026#34;RequestStart\u0026#34;); public static readonly EventId RequestEnd = new EventId(101, \u0026#34;RequestEnd\u0026#34;); } public static async Task RequestStart(ILogger logger, HttpRequestMessage request, bool logContent) { StringBuilder message = new StringBuilder(); message.AppendLine($\u0026#34;Sending HTTP request {request.Method} {request.RequestUri}\u0026#34;); if (logger.IsEnabled(LogLevel.Trace)) { LogHttpHeaders(message, request.Headers); await LogHttpContent(message, request.Content, logContent); logger.Log( LogLevel.Trace, EventIds.RequestStart, message, null, (state, ex) =\u0026gt; state.ToString()); } } public static async Task RequestEnd(ILogger logger, HttpResponseMessage response, TimeSpan duration) { StringBuilder message = new StringBuilder(); message.AppendLine( $\u0026#34;Recieving HTTP response after {duration.TotalMilliseconds}ms - {response.StatusCode}\u0026#34;); if (logger.IsEnabled(LogLevel.Trace)) { LogHttpHeaders(message, response.Headers); await LogHttpContent(message, response.Content, false); logger.Log( LogLevel.Trace, EventIds.RequestEnd, message, null, (state, ex) =\u0026gt; state.ToString() ); } } private static void LogHttpHeaders(StringBuilder message, HttpHeaders headers) { if (headers == null) throw new ArgumentNullException(nameof(headers)); foreach (KeyValuePair\u0026lt;string, IEnumerable\u0026lt;string\u0026gt;\u0026gt; header in headers) { foreach (string value in header.Value) { message.AppendLine($\u0026#34;{header.Key}: {value}\u0026#34;); } } } private static async Task LogHttpContent(StringBuilder message, HttpContent content, bool logContent) { if (content != null) { foreach (KeyValuePair\u0026lt;string,IEnumerable\u0026lt;string\u0026gt;\u0026gt; header in content.Headers) { foreach (string value in header.Value) { message.AppendLine($\u0026#34;{header.Key}: {value}\u0026#34;); } } if (logContent) { string contentBody = await content.ReadAsStringAsync(); message.AppendLine(contentBody); } } } } } } GetClientの実装\nprivate ISearchIndexClient GetClient(string indexName, params DelegatingHandler[] handlers) { var rootHandler = _searchServiceClient.HttpMessageHandlers.OfType\u0026lt;HttpClientHandler\u0026gt;().SingleOrDefault(); var indexClient = new SearchIndexClient(_searchServiceClient.SearchServiceName, indexName, _searchServiceClient.SearchCredentials, rootHandler, handlers) { SearchDnsSuffix = _searchServiceClient.SearchDnsSuffix }; indexClient.HttpClient.Timeout = _searchServiceClient.HttpClient.Timeout; return indexClient; } 出力されるログ例\n2020/04/14 19:17:53.591|TRACE|Sending HTTP request POST https://サービス名.search.windows.net/indexes(\u0026#39;インデックス名\u0026#39;)/docs/search.post.search?api-version=2019-05-06 client-request-id: be02140f-3a07-48cc-b018-d8aa5e819bc3 Accept-Language: en-US Accept: application/json; odata.metadata=none api-key: APIキー User-Agent: FxVersion/4.700.20.11803 User-Agent: OSName/MacOs User-Agent: OSVersion/Darwin.19.4.0.Darwin.Kernel.Version.19.4.0.Wed.Mar.4.22.28.40.PST.2020.root.xnu.6153.101.6.15RELEASE.X86.64 User-Agent: Microsoft.Azure.Search.SearchIndexClient/10.100.19.52907 Content-Type: application/json; charset=utf-8 { \u0026#34;count\u0026#34;: false, \u0026#34;facets\u0026#34;: [], \u0026#34;queryType\u0026#34;: \u0026#34;simple\u0026#34;, \u0026#34;scoringParameters\u0026#34;: [], \u0026#34;search\u0026#34;: \u0026#34;azure\u0026#34;, \u0026#34;searchMode\u0026#34;: \u0026#34;any\u0026#34; } |AzureSearchSample.SearchService|EventId_Id=100, EventId_Name=RequestStart, EventId=RequestStart メリット、デメリット Azure Cognitive Searchの検索の処理だけを対象にリクエストのログを出力することが可能です。また、影響範囲はアプリケーションだけに閉じていますので、デバッグ目的などでログ出力したい場合に、自分だけの手元でログの確認が可能になります。\nデメリットとしては、独自に実装しなければいけない範囲が広いことです。\n2. ServiceClientTracingの機能を利用する Microsoft.Rest.ClientRuntimeというライブラリをAzure Cognitive Searchは利用しています。 このライブラリにServiceClientTracingというクラスが存在します。 なにやら、クライアントの処理のトレースができそうです。\nAzure Cognitive SearchのSDKの実装がGitHubに公開されており、検索リクエストの処理を投げる直前に、このトレースの仕組がONになっていると、ServiceClientTracing.SendRequestメソッドを呼び出していました。\n実際にSendRequestメソッドに送られたものに対して何かしらの処理を行うのは、IServiceClientTracingIntercepterインターフェースを実装したクラスになります。 このインターフェースの実装がLog4Netに存在します。Log4Netを利用している場合は、これを活用すれば楽ができます。\n実際にServiceClientTracingを有効にするには、以下の2行を呼び出すだけです。\nServiceClientTracing.IsEnabled = true; ServiceClientTracing.AddTracingInterceptor(new Log4NetTracingInterceptor()); あとは、Rest.ClientRuntimeがよしなにやってくれます。 1とは異なり、トレースログなので、リクエストのボディについても出力してくれます。\n2020-05-26 19:09:04,058 [1] DEBUG Microsoft.Rest.Tracing.Log4Net.Log4NetTracingInterceptor [(null)] - invocationId: 1 instance: Microsoft.Azure.Search.DocumentsProxyOperations method: SearchPost parameters: {searchRequest=Microsoft.Azure.Search.Models.SearchRequest,clientRequestId=,cancellationToken=System.Threading.CancellationToken} 2020-05-26 19:09:04,164 [1] DEBUG Microsoft.Rest.Tracing.Log4Net.Log4NetTracingInterceptor [(null)] - invocationId: 1 request: Method: POST, RequestUri: \u0026#39;https://サービス名.search.windows.net/indexes(\u0026#39;インデックス名\u0026#39;)/docs/search.post.search?api-version=2019-05-06\u0026#39;, Version: 2.0, Content: System.Net.Http.StringContent, Headers: { client-request-id: 591cb14f-e5c2-4a85-977d-01d1f6431ddc Accept-Language: en-US Accept: application/json; odata.metadata=none api-key: APIキー Content-Type: application/json; charset=utf-8 } Body: { { \u0026#34;count\u0026#34;: false, \u0026#34;facets\u0026#34;: [], \u0026#34;queryType\u0026#34;: \u0026#34;simple\u0026#34;, \u0026#34;scoringParameters\u0026#34;: [], \u0026#34;search\u0026#34;: \u0026#34;azure\u0026#34;, \u0026#34;searchMode\u0026#34;: \u0026#34;any\u0026#34; } } 2020-05-26 19:09:04,459 [Thread Pool Worker] DEBUG Microsoft.Rest.Tracing.Log4Net.Log4NetTracingInterceptor [(null)] - invocationId: 1 response: StatusCode: 200, ReasonPhrase: \u0026#39;OK\u0026#39;, Version: 1.1, Content: System.Net.Http.StreamContent, Headers: { Cache-Control: no-cache Pragma: no-cache request-id: 591cb14f-e5c2-4a85-977d-01d1f6431ddc elapsed-time: 72 OData-Version: 4.0 Preference-Applied: odata.include-annotations=\u0026#34;*\u0026#34; Strict-Transport-Security: max-age=15724800; includeSubDomains Date: Tue, 26 May 2020 10:09:04 GMT Content-Type: application/json; odata.metadata=none Expires: -1 Content-Length: 376 } メリット、デメリット Log4Netを利用しているアプリの場合、2行だけを追加することで実装が完了するのがお手軽な点です。\n難点としては、Rest Client全てにたいしてトレース処理が入ってしまうので、Azure Cognitive Search以外にもRestクライアントを利用しているものが存在した場合、ログの量が増えてしまいます。また、検索以外の処理でもトレースされてしまうのもデメリットになります。\nLog4Net以外のログ機構を使用している場合は、自分でIServiceClientTracingInterceptorを実装する必要も出てきます(参考:StackOverflow)。\n3. Azure Application Insightsを活用する ここから紹介する3と4については、ログの出力先がAzure上になります。\nAzureのApplication Insightsを利用する方法です。 Azure?.NET?のアプリケーションパフォーマンスモニタリングのサービスです。\nApplication Insightsを自分のアプリケーションに設定することで、アプリケーションのパフォーマンス監視に関する情報がAzure上のApplication Insightsリソースに送信されるようになります。\nただ、Application Insightsのデフォルトの機能では、URL程度の情報だけが送信されます(参考:しばやんさんのブログ)\nこちらも拡張機能が用意されており、ITelemetryInitializerのインターフェースを実装したクラスを用意することで、独自の情報をApplication Insightsに出力することが可能となります。詳細についてはしばやんさんのブログを参考にしてもらうのが良いかと。\nHttpリクエストを出力する実装例は次のとおりです。ただ、ちょっとうまく行かないパターンがあったので、コメントアウトとして残してあったりします(なんでだろう?)\nusing System.Collections.Generic; using System.Net.Http; using System.Net.Http.Headers; using Microsoft.ApplicationInsights.Channel; using Microsoft.ApplicationInsights.DataContracts; using Microsoft.ApplicationInsights.Extensibility; namespace AzureSearchWebSample.ApplicationInsights { public class HttpRequestInitializer : ITelemetryInitializer { public void Initialize(ITelemetry telemetry) { if (!(telemetry is DependencyTelemetry dependency)) { return; } HttpRequestMessage requestMessage = null; HttpRequestHeaders requestHeaders; if (dependency.TryGetOperationDetail(\u0026#34;HttpRequest\u0026#34;, out var details) \u0026amp;\u0026amp; details is HttpRequestMessage request) { requestMessage = request; requestHeaders = request.Headers; if (requestMessage.Method == HttpMethod.Post) { string contentBody = requestMessage.Content.ReadAsStringAsync().GetAwaiter().GetResult(); dependency.Properties.Add(\u0026#34;RequestBody\u0026#34;,contentBody); } } else if (dependency.TryGetOperationDetail(\u0026#34;HttpRequestHeaders\u0026#34;, out details) \u0026amp;\u0026amp; details is HttpRequestHeaders headers) { requestHeaders = headers; } else { return; } foreach (KeyValuePair\u0026lt;string,IEnumerable\u0026lt;string\u0026gt;\u0026gt; header in requestHeaders) { foreach (string value in header.Value) { dependency.Properties.Add(header.Key, value); } } //この実装の場合は出力されなかった。なぜ? // if (requestMessage != null \u0026amp;\u0026amp; requestMessage.Method == HttpMethod.Post) // { // string contentBody = requestMessage.Content.ReadAsStringAsync().GetAwaiter().GetResult(); // dependency.Properties.Add(\u0026#34;RequestBody\u0026#34;,contentBody); // } } } } メリット、デメリット すでにApplication Insightsを利用している場合はついでに情報が出力されるので便利です。かつ、常にリクエストログを見れるようにしておく場合はとても便利だと思います。\nApplication Insightsを利用していない場合は、そこから導入しなければならなくなるので、手間が増えるかもしれないです。\n4. Azure Cognitive Searchのコンソールにある診断情報の機能を利用する。 最後はAzure Cognitive Searchの診断ログを有効にする方法です。 ここまで説明してきた方法の中で、一番お手軽な方法です。。。\nこれまでは、リクエストボディを出力する方法を考えていましたが、Azure Cognitive Search側の診断ログを有効にすると、リクエストボディで送信したものが、Azure Cognitive Search側で、クエリパラーメータとして、診断ログに出力されます(診断ログのQuery_s)。\nあとは、Azureのコンソールで当該時間のログを見ればよいだけです。以下は出力されたログの一部です。Description_sにはURLのパスが記載されています。\n診断ログ例(一部)\nDescription_s POST /indexes(\u0026#39;multi-field-test\u0026#39;)/docs/search.post.search Query_s ?api-version=2019-05-06\u0026amp;searchMode=Any\u0026amp;search=azure\u0026amp;queryType=Simple\u0026amp;$count=false メリット、デメリット アプリケーション側に手を入れる必要がなのでお手軽です。 一度設定しておけばコンソール側でログをいつでも見れるので便利です。\nリクエスト量が多くなってしまうと、ログの量も多くなり、費用がかさむ恐れがあります。また、複数の人が触る環境の場合は自分で送信したリクエストがどれだったのか?といった状況に陥る可能性はあります。\nその他は? Azureに対してではないですが、昔似たようなことをやるときにやっていた方法として、ローカルにプロキシサーバーを起動し、そのプロキシサーバー経由でアプリケーションから、Azureに接続することで、リクエストを保存する方法もあります。 ざんねんながら、未調査ですがアプリなどにはそれほど手を入れる必要はないかと思います。\nまとめ ちょっと送信リクエストの内容が見てみたいという話でしたが、いろいろな手段が存在しました。 自分の状況、環境に合わせて手段を選択肢てみるのがいいかと思います。 まずは、簡単な診断ログあたりからでしょうか?\n","date":1590481367,"dir":"post/2020/","id":"36dd94159e3e60076c0c6098086e255f","lang":"ja","lastmod":1590481367,"permalink":"https://blog.johtani.info/blog/2020/05/26/logging-azure-search-request/","publishdate":"2020-05-26T17:22:47+09:00","summary":"今回はAzure Cognitive SearchのSDKを利用したアプリケーションが、実際にAzure Cognitive Searchに対して送信しているリクエストのパラメータ","tags":["azure search",".net"],"title":"Azure Cognitive Searchのリクエストのロギング"},{"contents":"Mircosoft Buildというイベントが今週ありました(MSの方やお客さんに教えてもらった)。\nそこで、Azure Cognitive Searchのセッション(MyBuild - Cognitive Search： The pocket-knife for knowledge mining)があったので、見てみました。 内容がどんなものかをメモっておきます。 最初はCognitive Searchがどんなものよという説明でした。\nビルトインスキルの拡充の話 データソースからデータを取り出し、エンリッチし、検索エンジンに保存するという、パイプラインが組めるようになっています。\nこのパイプラインで利用できる処理のことがスキルと呼ばれています。ここで利用できるビルトインスキルが拡充されますよという話でした。ちょっとだけ抜き出すと以下のとおりです。\nAzure Machine Learning Text translation Brand detection Object detection スキルのリファレンスには載ってるものと載ってないものがあるので、今後追加されてくのかな? Brand detectionがどんなものなんだろう?ってのがちょっと気になりました。どっかにデモとかあるかなぁ?\nスキルセットのための新機能 : Debug Sessionのデモ 上記のスキルを組み合わせてパイプラインを組んで、データソースから取り出したデータをエンリッチしてから、検索エンジンに入れる処理をかけるのですが、その処理のデバッグ用に新しいGUIの機能が追加されてますよという紹介とデモでした。\nTutorial： Use Debug sessions to diagnose, fix, and commit changes to your skillset - Azure Cognitive Search | Microsoft Docs Manage Identityの話 Azure Cognitive Searchにデータを登録するパイプランの最初の段階で、各種データソースにアクセスが必要です。 このアクセス時にコネクションの設定にアカウントキーなども含めてましたが、これをコネクション設定ではなく、専用の管理機能が用意されましたよという話でした。\nSet up a connection to a data source using a managed identity (preview) - Azure Cognitive Search | Microsoft Docs QA Similarityとかの話 BM25になってるよとか SDKの話とか ほかにRelevancyの話 Analyzerをデフォルトのままじゃなくてちゃんと考えて使いましょう(例:各言語用のAnalyzerがいっぱいあるよとか) こんな感じでした。\n","date":1590117041,"dir":"post/2020/","id":"21982f43bc435f22efef22b309a48c66","lang":"ja","lastmod":1590117041,"permalink":"https://blog.johtani.info/blog/2020/05/22/watching-azure-cognirive-search-session-at-ms-build/","publishdate":"2020-05-22T12:10:41+09:00","summary":"Mircosoft Buildというイベントが今週ありました(MSの方やお客さんに教えてもらった)。 そこで、Azure Cognitive Searchのセッション(MyBuil","tags":["azure search"],"title":"Microsoft Build(2020)のAzure Cognirive Searchのセッションを見たのでメモ"},{"contents":"ElasticのWorkplace Searchを触ってみています(その1、その2)が、Elastic Stackの7.7.0がリリースされてしまいました。\n簡単ですが、リリースブログを見ながら気になった点をメモしとこうかと。\n本家のリリースブログ いっぱいあるんですよ、これが。まぁ、内容かぶってるのもあるんですが。\nElastic Stack Elastic Stack 7.7.0をリリース Elasticsearch 7.7.0 released Kibana 7.7.0 released Logstash 7.7.0 released Enterprise Search系 Elastic Enterprise Search 7.7 released, featuring Workplace Search GA | Elastic Blog Elastic App Search updates： Scale your way with new configuration options | Elastic Blog Elastic Workplace Search： 新しい、統合された働き方へ Observability系 Elastic Observability 7.7 released | Elastic Blog\nElastic APM 7.7.0 released with service maps, async profiler, and more | Elastic Blog\nElastic Logs 7.7.0 released with PCF support, MQTT support, and more | Elastic Blog\nElastic Metrics 7.7.0 released with enhanced Prometheus integration and PCF support, | Elastic Blog\nElastic Uptime Monitoring 7.7.0 released with alerting, anomaly detection and more | Elastic Blog\nNew alerting framework released for Observability, Security and the Elastic Stack | Elastic Blog\nIntroducing Elastic Security 7.7.0 | Elastic Blog\n個人的に気になったもの で、全部読んだわけではないのですが、個人的に気になった機能についてメモを残しておきます。 多分に検索によっている可能性がありますが、お気になさらず。 また、ブログとドキュメントを元に気になるところをピックアップしてます。 実際の実装とか動作に関してはまだ未調査の段階です。\nAsync Search - Elasticsearch ElasticsearchのAPIとして非同期に検索できるAPIが実装されました (公式リファレンス)。 大量データを検索が終了してから検索結果を返すのではなく、クエリは実行しつつわかったところまでは都度取得したいという要望だったり、Coldインデックスのように遅いストレージ上にあるデータへの検索でも少しずつ取得できるようにという具合だと思います。ログとか大量に扱う場合にまぁ、ほしいですよね。今回はEsのリリースがメインで、今後はKibanaなどとの連携だったり色々改善していくよという話みたいです(Kibanaの一部の機能は利用しているみたい)。\nライセンスとサブスクリプションのレベル Elastic License Basic 気になるところ(と、予想とか) 仕組みがどうなっているか? Search APIと同等のリクエストパラメータが使える。が、いくつか制約はありそう おそらくTask Manageerで検索してる処理が管理され、レスポンスにはIDが発行されて、そのIDで処理の進み具合を取得する感じ。 Shard単位?Segment単位? 内部的にはShard単位で検索処理を扱ってるので、Shard単位がとりあえず楽そう? Aggsとかも? 対象の模様 Sortは? 有効。ソートのフィールドがインデックス対象だった場合は、そのデータの統計値を使ってShardをソートするっぽい(公式リファレンスのNOTE参照) 関連しそうなGitHubのIssuesとか まだ読んでない\nAsync search · Issue #49091 · elastic/elasticsearch Add a listener to track the progress of a search request locally by jimczi · Pull Request #49471 · elastic/elasticsearch Pre-sort shards based on the max/min value of the primary sort field by jimczi · Pull Request #49092 · elastic/elasticsearch Async search： store intermediate results · Issue #55464 · elastic/elasticsearch Reduced consumption of heap - Elasticsearch ヒープの使用量が7.7で減ってるよというブログも別途ありました。\n元になっているLuceneの実装に関するIssueが「［LUCENE-8635］ Lazy loading Lucene FST offheap using mmap - ASF JIRA」です。ヒープ上に展開していたデータをmmapで扱えるようにすることで、ヒープのメモリを削減してる。\nで関連して、これがLuceneで操作できるようになって(「Use reader attributes to control term dict memory useage by s1monw · Pull Request #42838 · elastic/elasticsearch」)、そこからEsに取り込まれたと。\n_idをoff-heapにする話は[ここ](Move the terms index of _id off-heap. by jpountz · Pull Request #52405 · elastic/elasticsearch)にあった。\nこれに関連して、ヒープサイズの推奨について再考が必要かも?というIssue(Reconsider our recommendations for heap size? · Issue #52561 · elastic/elasticsearch)も上がってる。\nPainless Lab - Kibana ほんとにPainless?と言う話はさておき、_script APIでexecuteはできていましたが、やはりもう少し楽に実行したいですよね?ということで画面ができたみたいです。\nシンタックスハイライトとかもできるので、より簡単に使えるようになってますね。 まだ、ベータなので足りないContextとかもあるっぽいけど。\nライセンスとサブスクリプションのレベル Elastic License Basic? まだベータだからか、サブスクリプションのページにはなかった。 公式ドキュメントとGitHubのリポジトリから、Elastic Licenseであることは判明。\n気になるところ(と、予想とか?) 制限事項がどんなものか? 使えるContextがまだ少ない?まだGAではない サジェストがどのくらい効くのか? シンタックスハイライトはあるけど。まだかなぁ? その他Elasticsearch関連 7.7リリースのハイライトが別途用意されています。\n7.7.0 release highlights | Elasticsearch Reference ［7.7］ | Elastic こっちで気になるのは、ClassificationとかTransformsあたりかなぁ。ML関連の機能で。\nWorkplace Search GA これは別のブログに書くかな。\n気になるところ Betaと何が変わったのか? APIとかどういう形で提供されるのか?そもそも提供されるのか? どんな機能?みたいなのも書く予定です。\nData VisualizerでFilebeatのConfigをサジェスト - Kibana and Filebeat Kibanaの画面からデータをちょっと?(100MB)だけアップロードして、Elasticsearchにサクッとデータ登録できる機能が実はあります。この機能の拡張として、Filebeatの設定だとこんな感じに作れるよ?というのを提示してくれるようになったみたいです。 手元にあるファイルを定期的に読み込むときに、設定を書く下地ができるのは便利じゃないかな?\nライセンスとサブスクリプションのレベル Elastic License Basic Data Visualizerってどんなもの?というのはここにブログがあります。残念ながらKibanaとかの公式リファレンスには使い方のページがないんだよなぁ。\nAPMのサービスマップ - APM and Kibana アプリケーションアーキテクチャのどこでAPMが動作しているか、どこと通信しているかという、APMのエージェントが入っているアプリ間のつながりをKibana上で可視化できる機能っぽいです。まだ、ベータみたいですが、面白そう。Azure Application Insightのアプリケーションマップに似てる気がします。\nライセンスとサブスクリプションのレベル Elastic License Platinum 気になるところ どうやって作ってる(つながりをどうやて判断してる)のか? 分散トレーシングのデータを元に誰がどこと通信してるってのは取れるんじゃなかろうか? Log categorization and contextual examples - Kibana and Elasticsearch 7.6から入ってたっぽいですが、ログの分類をMLの機能を使ってできるものが、LogsのUIとかでさらに使いやすくなった模様。\nライセンスとサブスクリプションのレベル Elastic License Platinum 気になるところ 7.6の機能から追いかけないとなぁ。。。 似たようなログをカテゴリーごとに分析できるようになるので、プラスMLの仕組みでこれまでとは異なる種類のログが出始めたみたいなことが分析できそう。 まとめ 眺めるだけで時間かかりましたが、まぁ、相変わらずいっぱいありますね。 興味のあるところの濃淡が出た感じになりましたが、気になる点をピックアップしてみました。 おかしなところとか、ここはどういう意味?などあればツッコミお願いします。\n","date":1589509037,"dir":"post/2020/","id":"306cecb32320ead508346ad8fed3394d","lang":"ja","lastmod":1589509037,"permalink":"https://blog.johtani.info/blog/2020/05/15/elastic-stack-7_7/","publishdate":"2020-05-15T11:17:17+09:00","summary":"ElasticのWorkplace Searchを触ってみています(その1、その2)が、Elastic Stackの7.7.0がリリースされてし","tags":["elastic stack"],"title":"Elastic Stack 7.7がリリースされた"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章 第9章 エラー処理です。 NLP100とか、いくつかのプログラムを書いていて、なんとなくは扱っていますが、きちんと勉強しないと。\nとりあえず、「Rustには例外は存在しません。」が一番知っておくことかな。\npanic!で回復不能なエラー panic!マクロでスタックを巻き戻して掃除をして終了。 異常終了(panic = 'abort')にもできる。 「RUST_BACKTRACEを0以外の変数にセットして実行」 * Resultで回復可能なエラー expect()は気持ち悪い名前じゃないかなぁ? ここでio::Errorではないものもエラーが発生する場合には panic!すべきかするまいか まとめ 「Rustには例外は存在しない」ので、回復不能か可能かを考えつつ処理を書こうと。\n","date":1589449406,"dir":"post/2020/","id":"1e220a934e16fd941bd804ca03865b60","lang":"ja","lastmod":1589449406,"permalink":"https://blog.johtani.info/blog/2020/05/14/chap9-rust-the-book/","publishdate":"2020-05-14T18:43:26+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第9章"},{"contents":"Rustで言語処理100本ノックの第2章の残りです。\n前回はこちら。\nちなみに、標準入力から受け取る処理は書いてないです。 出力に関してはファイル分割、保存と支持があるもの以外は文字列として取り出すところで終わっています。\n12. 1列目をcol1.txtに，2列目をcol2.txtに保存 pub fn extract_column(input_file_name: \u0026amp;str, num: usize, output_file_name: \u0026amp;str) { let input_f = File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;); let read_buf = BufReader::new(input_f); let mut output_f = OpenOptions::new() .write(true) .create(true) .open(output_file_name) .expect(format!(\u0026#34;can\u0026#39;t open file[{}] with write option\u0026#34;, output_file_name).as_str()); read_buf.lines().for_each(|line| match line { Ok(line) =\u0026gt; { let columns: Vec\u0026lt;_\u0026gt; = line.split(\u0026#39;\\t\u0026#39;).collect(); writeln!(output_f, \u0026#34;{}\u0026#34;, columns[num]); output_f.flush().expect(\u0026#34;Error during flush\u0026#34;); } Err(_) =\u0026gt; panic!(\u0026#34;parse error \u0026#34;), }); } 13で出力結果を利用するので入力として出力ファイル名も受け取るようにしました。 問題としては、1列目と2列目を別々に出力すればいいので、1回の処理で書いても良かったのですが、1回1ファイルの出力という形で実装しました(効率は悪い)。\n改行コードあたりを考えるのがめんどくさかったのでwriteln!マクロでファイルに書き出しています。が、普通にwriteメソッドで改行コードを追加しても良かったのかなと。\nあとは、出力先ファイルが存在しない場合だけopenするようにOpenOptionsを利用してみています。\nflushを呼び出すべきなのかどうか?を調べないとな。。。\n13. col1.txtとcol2.txtをマージ pub fn merge_files(col1_file: \u0026amp;str, col2_file: \u0026amp;str, output_file_name: \u0026amp;str) { let col1_buf = BufReader::new(File::open(col1_file).expect(\u0026#34;file not found\u0026#34;)); let col2_buf = BufReader::new(File::open(col2_file).expect(\u0026#34;file not found\u0026#34;)); let mut output_f = OpenOptions::new() .write(true) .create(true) .open(output_file_name) .expect(format!(\u0026#34;can\u0026#39;t open file[{}] with write option\u0026#34;, output_file_name).as_str()); col1_buf .lines() .zip(col2_buf.lines()) .for_each(|(col1, col2)| { let col1 = col1.expect(\u0026#34;parse error col1\u0026#34;); let col2 = col2.expect(\u0026#34;parse error col2\u0026#34;); writeln!(output_f, \u0026#34;{}\\t{}\u0026#34;, col1, col2); output_f.flush().expect(\u0026#34;Error during flush\u0026#34;); }); } 2つのファイル名を入力として受け取り、タブでくっつけて出力します。 zipを利用することで、2つのイテレーターを同時に回しています。\n14. 先頭からN行を出力 pub fn head(input_file_name: \u0026amp;str, lines: usize) -\u0026gt; String { let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); let mut head = String::new(); buf.lines().take(lines).for_each(|line| { head.push_str(format!(\u0026#34;{}\\n\u0026#34;, line.expect(\u0026#34;parse error\u0026#34;)).as_str()); }); return head; } イテレーターのメソッドにtakeがあります。 これを利用することで、引数に指定した数のエレメントが取得できるので、これでheadが実現できます。\n15. 末尾のN行を出力 pub fn tail(input_file_name: \u0026amp;str, lines: usize) -\u0026gt; String { let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); let mut tail = String::new(); let line_count = word_count(input_file_name); buf.lines().skip(line_count - lines).for_each(|line| { tail.push_str(format!(\u0026#34;{}\\n\u0026#34;, line.expect(\u0026#34;parse error\u0026#34;)).as_str()); }); return tail; } tailの場合は少し複雑で、11で作成した行数をカウントするメソッドで総行数を取り出し、そこから引数で指定された行数を引き算した数(=出力しない行数)を、イテレーターのskipメソッドの引数に渡しています。これにより、指定された数のエレメントをスキップしたあとの処理がかけます。\n16. ファイルをN分割する pub fn split_files( input_file_name: \u0026amp;str, num: usize, output_file_prefix: \u0026amp;str, output_file_suffix: \u0026amp;str, ) { let total = word_count(input_file_name) as f64; let lines_in_file = total / num as f64; let lines_in_file = lines_in_file.ceil() as usize; // let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); let output_files: Vec\u0026lt;File\u0026gt; = create_file_vec(output_file_prefix, num, output_file_suffix); println!(\u0026#34;split file each {} lines.\u0026#34;, lines_in_file); let mut lines = buf.lines(); for mut output_f in output_files { let mut current = 1; while current \u0026lt; lines_in_file + 1 { let line = lines.next(); if let Some(line_rs) = line { if let Ok(line_str) = line_rs { writeln!(output_f, \u0026#34;{}\u0026#34;, line_str); } } current = current + 1; } output_f.flush().expect(\u0026#34;error during flush\u0026#34;); } } fn create_file_vec(output_file_prefix: \u0026amp;str, num: usize, output_file_suffix: \u0026amp;str) -\u0026gt; Vec\u0026lt;File\u0026gt; { let mut files = Vec::with_capacity(num); for i in 0..num { let output_file_name = format!(\u0026#34;{}{}{}\u0026#34;, output_file_prefix, i + 1, output_file_suffix); let output_f = OpenOptions::new() .write(true) .create(true) .open(output_file_name.as_str()) .expect(format!(\u0026#34;can\u0026#39;t open file[{}] with write option\u0026#34;, output_file_name).as_str()); files.push(output_f); } return files; } ちょっと長いですね。\n入力としては、分割するファイル数Nが指定されます。まずは、総行数/Nで各ファイルに保存されるべき行数を計算します。 次に、2つ目の関数をつかって、必要な数のファイルオブジェクトをベクトルとして生成します。\nファイルオブジェクトのベクトルの要素を元にしたfor文を回しつつ、それぞれのファイルに必要な行数を出力している処理になっています。\n総行数がNで割り切れない場合にceilで切り上げした行数にするというちょっとした処理を入れてあります。\n17. １列目の文字列の異なり pub fn count_uniq_words(input_file_name: \u0026amp;str, col: usize) -\u0026gt; usize { let mut words = HashSet::new(); let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); buf.lines().for_each(|line| match line { Ok(line_str) =\u0026gt; { let columns: Vec\u0026lt;_\u0026gt; = line_str.split(\u0026#39;\\t\u0026#39;).collect(); words.insert(columns[col].to_string()); } Err(_) =\u0026gt; panic!(\u0026#34;parse error \u0026#34;), }); return words.len(); } HashSetを利用することでユニーク性を担保して、最後はHashSetの数を数え上げれば終了です。\n18. 各行を3コラム目の数値の降順にソート pub fn sort_on_col3(input_file_name: \u0026amp;str) -\u0026gt; String { let mut lines: BTreeSet\u0026lt;Line\u0026gt; = BTreeSet::new(); let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); buf.lines().for_each(|line| match line { Ok(line_str) =\u0026gt; { let columns: Vec\u0026lt;_\u0026gt; = line_str.split(\u0026#39;\\t\u0026#39;).collect(); let num: u32 = columns[2].parse().expect(\u0026#34;parse error\u0026#34;); let line = Line { line: line_str, num, }; lines.insert(line); } Err(_) =\u0026gt; panic!(\u0026#34;parse error\u0026#34;), }); let mut sorted = String::new(); lines.iter().for_each(|line| { sorted.push_str(format!(\u0026#34;{}\\n\u0026#34;, line.line).as_str()); }); return sorted; } #[derive(Eq)] struct Line { line: String, num: u32, } impl Ord for Line { fn cmp(\u0026amp;self, other: \u0026amp;Self) -\u0026gt; Ordering { let ord = other.num.cmp(\u0026amp;self.num); if let Ordering::Equal = ord { other.line.cmp(\u0026amp;self.line) } else { ord } } } impl PartialOrd for Line { fn partial_cmp(\u0026amp;self, other: \u0026amp;Self) -\u0026gt; Option\u0026lt;Ordering\u0026gt; { Some(self.cmp(other)) } } impl PartialEq for Line { fn eq(\u0026amp;self, other: \u0026amp;Self) -\u0026gt; bool { self.eq(other) } } Lineという、行の文章と第3カラム目の値をもった構造体を作成しました。そこにEq、Ord、PartialOrd、PartialEqを実装し、3カラム目での大小比較できるようにしました。 この構造体をBTeeSetに格納していき、イテレーターで回すことで、ソートされた状態にしてあります。 同一数値の場合は行の降順でソートできるようにOrdを実装してあります。\n19. 各行の1コラム目の文字列の出現頻度を求め，出現頻度の高い順に並べる pub fn sort_on_frequency(input_file_name: \u0026amp;str) -\u0026gt; String { let mut names: HashMap\u0026lt;String, u32\u0026gt; = HashMap::new(); let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); buf.lines().for_each(|line| match line { Ok(line_str) =\u0026gt; { let columns: Vec\u0026lt;_\u0026gt; = line_str.split(\u0026#39;\\t\u0026#39;).collect(); let name_str = columns[0].to_string(); let count = names.entry(name_str).or_insert(0); *count += 1; } Err(_) =\u0026gt; panic!(\u0026#34;parse error\u0026#34;), }); let mut sorted = String::new(); let mut sorted_names: Vec\u0026lt;(\u0026amp;String, \u0026amp;u32)\u0026gt; = names.iter().collect(); sorted_names.sort_by(|(aname, acount), (bname, bcount)| { let ord = bcount.cmp(acount); if let Ordering::Equal = ord { bname.cmp(aname) } else { ord } }); sorted_names.iter().for_each(|(name, count)| { sorted.push_str(format!(\u0026#34;{} {}\\n\u0026#34;, count, name).as_str()); }); return sorted; } もうすこしうまくできる気がしますが、いったんこれで。 数え上げのためにまずはHashMapに第1カラムの文字列, 個数という組み合わせでデータを入れていきます。 出来上がったHashMapをタプルのベクターに変換し、変換したベクターのsort_byメソッドに比較用の関数を渡すことで個数の降順に並べています。同一個数の場合は文字列の降順になっています。 で、最後に並びかわったベクターのイテレーターを使って出力しておしまいです。 内部的には最悪3回回る感じでしょうか? 最初からベクトルに入れつつソートできる仕組みにするようなのがいいのかなぁ?\nまとめ Unixコマンドの勉強になりましたw あとは、HashMapなどの勉強にもなりました。 最後の方は効率がいまいち良くない気もしてはいますが、とりあえず第3章に進もうかと思います。\n","date":1589253809,"dir":"post/2020/","id":"09155bf417a93847b538ad607f78cca2","lang":"ja","lastmod":1589253809,"permalink":"https://blog.johtani.info/blog/2020/05/12/reboot-nlp100-ch02-12to19/","publishdate":"2020-05-12T12:23:29+09:00","summary":"Rustで言語処理100本ノックの第2章の残りです。 前回はこちら。 ちなみに、標準入力から受け取る処理は書いてないです。 出力に関してはファイル","tags":["Rust","nlp100"],"title":"第2章の12から19まで(言語処理100本ノック2020)"},{"contents":"気づいたら1ヶ月サボってました、ごめんなさい。。。\nRustで言語処理100本ノックの第2章をはじめました。\n前回はこちら。\n確認用のUnixコマンド 確認用のファイルを先に生成して置きました。 これで、Rustでコードを書いて、作成済みの確認ファイルを元にassert_eq!でチェックするという方式を取ろうかと。\nで、コマンド群はこちらです。\nUnix/Linuxコマンド、昔から使っています。が、なにかちょっとした文字列処理やファイル処理をやるときは、Javaのプログラム(最近だとPython)を書くというのが基本になってるので、結構、使ったことの無いコマンドが今回ありました。使ったことがなかったのはこちらです。\nsed tr expand paste cut split sedとかは普通さわってるだろ?って思われそうですね。。。\nで、コマンドをmanで調べつつやりました、macOS上で。 これがまたいくつか罠があったので書き残しておきます(自分が知らないだけかもしれないので、おかしいところがあったらツッコミお願いします。)。\nsedコマンドでのタブの扱い ## sed command for macOS. If using Linux, use \u0026#34;\\t\u0026#34; for tab character cat $INPUT_FILE_NAME | sed -e \u0026#39;s/\t/ /g\u0026#39; \u0026gt; $OUTPUT_DIR/11_sed.txt \\tで行けると思ったのですが、うまく動きませんでした。\u0026lt;tab\u0026gt;みたいな書き方もあると思うのですが、これも駄目で、結局タブ文字をそのまま打ち込みました。。。 これ、めんどくさくないですか??? ちなみに、ターミナルで動作確認して、GitHubにあげてあるシェルファイルにコピペしてたのですが、CLionに貼り付けたらタブ文字がスペースに変換されてしまってて20分くらい悩みました。。。\nsplitコマンドに-nオプションがない LINES=`cat $OUTPUT_DIR/10.txt` SPLIT_LINES=`echo $LINES/$N | bc` split -a 1 -l $SPLIT_LINES $INPUT_FILE_NAME $OUTPUT_DIR/16_ splitコマンドについてググると、-nで指定した数のファイルに分割できるという記事がいくつも出てくるのですが、man splitをターミナル上でやるとそんなオプションがないと。。。 macOSがBSD系だからっぽいです。 ということで、行数を元に、指定した数(N)で行数を割ってから、指定行数ごとにファイルを分割する方式にしました。\nこれらのコマンドの違いはHomebrewとかでインストールするとなくなるのかなぁ?(めんどくさいので確認してないですが。。。)\nってことで、2章のそれぞれの課題の正解ファイルの生成はこれでできたはずです。\n10. 行数のカウント wc -lですね。\n// ch02-10 行数のカウント pub fn word_count(file_name: \u0026amp;str) -\u0026gt; usize { let f = File::open(file_name).expect(\u0026#34;file not found\u0026#34;); let buf = BufReader::new(f); return buf.lines().count(); } ファイルを読み込んで行数を数えます。 文字列として読み込んで改行コードの数を数えるというのもありかな?と思いましたが、RustのBufReaderにlines()という行のイテレータ?が取れることがわかったので、それでカウントを取りました。\n11. タブをスペースに置換 // ch02-11 タブをスペースに置換 pub fn tab_2_space(file_name: \u0026amp;str) -\u0026gt; String { let mut f = File::open(file_name).expect(\u0026#34;file not found\u0026#34;); let mut contents= String::new(); f.read_to_string(\u0026amp;mut contents).expect(\u0026#34;read error\u0026#34;); return contents.replace(\u0026#34;\\t\u0026#34;, \u0026#34; \u0026#34;); } こっちはファイル全体を文字列に読み込んでしまってから、文字列のreplaceで置換するという方式です。 ファイルが大きい場合にこれでいいのか?という問題がある気がしますが、まずはこの実装にしました。 やるとしたら、readメソッドとbufferを用意して、少しずつ読みながら、置換して吐き出す感じでしょうか? ちゃんとした文字コードの区切りで取れるかどうかを気にしないと行けないと思うので、思ったよりはめんどくさくなりそう。\nBufReaderをつかってread_lineのほうがましかも?\nまとめ ということで、サボっていたのを再開しました。 Rustのコードを書く前に、Unixコマンドの処理に結構悩みましたw\nRustのコードとしてはファイル処理なので、今後も役立つ気がしてます。 ということで、頑張っていくぞと。\n","date":1588948640,"dir":"post/2020/","id":"c098c6f0901979bd914ed7a345200f90","lang":"ja","lastmod":1588948640,"permalink":"https://blog.johtani.info/blog/2020/05/08/rebootnlp100-ch02-10to11/","publishdate":"2020-05-08T23:37:20+09:00","summary":"気づいたら1ヶ月サボってました、ごめんなさい。。。 Rustで言語処理100本ノックの第2章をはじめました。 前回はこちら。 確認用のUnixコマ","tags":["Rust","nlp100"],"title":"第2章の10から11まで(言語処理100本ノック2020)"},{"contents":"Rustで言語処理100本ノックのリファクタリングの続き。\n前回はこちら。\nとっくに終わってたのに、ブログ書いてなかった。。。\n08. 暗号文 pub fn cipher(text: \u0026amp;str) -\u0026gt; String { return String::from_iter(text.chars().map(|x| { if x.is_ascii_alphanumeric() \u0026amp;\u0026amp; x.is_lowercase() { let mut b = [0; 4]; x.encode_utf8(\u0026amp;mut b); b[0] = 219 - b[0]; char::from(b[0]) } else { x } })); } Rustの文字列はUTF-8でエンコードされたテキストを保持しているので、文字コード自体は意識していないです。 chars()でUnicodeスカラー値のイテレータが返ってくるので、1文字ずつ扱えるようになります。\nただ、1文字をバイトとして扱うのに手こずりました。 encode_utf8というメソッドを利用して1バイトだけ取り出して、計算するというのをやっています。 文字種の判別のメソッドが用意されているのは便利ですね。\nなんかもうちょっとスマートにできないのかな?と思いつつ動いたのでこれになってます。\n09. Typoglycemia pub fn typoglycemia(text: \u0026amp;str) -\u0026gt; String { return text .split_whitespace() .map(|word| { if word.len() \u0026lt;= 4 { word.to_string() } else { let original = word.chars().collect::\u0026lt;Vec\u0026lt;char\u0026gt;\u0026gt;(); let first = original.get(0).unwrap(); let last = original.last().unwrap(); let mut typo = original[1..original.len() - 1] .iter() .map(|x| x.clone()) .collect::\u0026lt;Vec\u0026lt;char\u0026gt;\u0026gt;(); let mut rng = thread_rng(); typo.shuffle(\u0026amp;mut rng); let mut typo = String::from_iter(typo.iter()); typo.insert(0, first.clone()); typo.push(last.clone()); typo } }) .collect::\u0026lt;Vec\u0026lt;String\u0026gt;\u0026gt;() .join(\u0026#34; \u0026#34;); } 一応、1行で記述できたかな? まずは、スペースで単語ごとに区切った後に、word(単語)の長さによって、処理を分岐し、単語が5文字以上の場合にランダムに並び替えを行うというのをやっています。 文字単位で処理を行うために、chars()で1文字ずつ取り出しています。 最初と最後の文字だけはそのままに、間の文字をランダムにシャッフルするというのをやるのに、もとのwordのスライスからコピーした文字列を作り出してから組み立て直すということをやっています。\nコピーしないでゴニョゴニョする方法ってあるのかなぁ? 思いつかなかったので、結構泥臭い感じの実装になってしまいました。\nまとめ めんどくさいので、コードをGitHubのソースコードからではなく、ブログにコードスニペットとしてコピペしました。Hugoでいい感じにGitHubのコードスニペット表示するのないかなぁ?\nということで、2年越しで1章が終了しました。 2章もやらないとなぁ。\n","date":1588923657,"dir":"post/2020/","id":"2c3270f8797ace2fb37402ea6a09d126","lang":"ja","lastmod":1588923657,"permalink":"https://blog.johtani.info/blog/2020/05/08/reboot-nlp100-finish-ch01/","publishdate":"2020-05-08T16:40:57+09:00","summary":"Rustで言語処理100本ノックのリファクタリングの続き。 前回はこちら。 とっくに終わってたのに、ブログ書いてなかった。。。 08. 暗号文 pub fn cipher(text: \u0026amp;str) -\u0026gt;","tags":["Rust","nlp100"],"title":"第1章の08から09まで(言語処理100本ノック2020)"},{"contents":"前回はWorkplace Searchの概要について書きましたが、今回はインストールと構成要素について説明します。なお、2020/5/7時点での情報を元に本記事は書いていますのでご注意ください。基本的にはインストールと起動方法についての手順を元に書いています。所々に考察を挟んだ形の記事になっていますので、気になるところだけ呼んでいただければと。\n記事一覧 ElasticのWorkplace Searchを触ってみる - その1 インストール インストール方法は公式リファレンスもしくはダウンロードページに記載があります。 現時点ではMacもしくはLinuxが対象でWindowsはまだサポート対象外となっています。\n必要なもの インストールに必要なものは以下になります。\nElasticsearch 7.6.x + Platinum license Elastic CloudのElasticsearch Service もしくは ダウンロードしてローカルで起動 enterprise-search-7.6.0.tar.gz ダウンロードページはこちら Java 8もしくは11 Long Term Supportの対象であるJavaです。2020/5/7時点では8か11 今回はローカルにElasticsearchの7.6.2をインストールしてから試してみます。30日間のトライアルライセンスが有効になっているので、Platinumの機能を試すことができます。\nJavaの8か11が必要になります。Elasticsearchには7.xからJDKが同梱されるようになりましたが、Workplace SearchがJettyを元に動作しているからです(enterprise-search-7.6.0.tar.gzにjettyというフォルダあり)。\nインストール手順 大まかには以下の3つです。\nJava 8もしくは11のインストール 14でも大丈夫でした(ローカルにはSDKMANでインストールした14.0.1が利用された)。 Elasticsearchのインストール(Elastic Cloudの場合はクラスタの起動) 今回はローカルにインストール Workplace Searchのインストール Javaはもともとインストールされていたので、今回は2と3をインストールしました。どちらもローカルで起動するので、2つをダウンロードしてtar.gzファイルを展開するだけになります。\n起動方法と設定 起動方法に起動前の設定の手順も記載があります。 設定しながら起動していきます。\nElasticsearchの起動 既存のElasticsearchのクラスターがあり、Platinumのライセンスが有効になっている場合はこの手順は必要ありません。\nElasticsearchの設定ファイルでSecurity機能をオンに 7.1から基本的なセキュリティ機能はベーシックの機能に含まれています。 Elasticsearchを起動 まずは起動(パスワードなどを設定するために必要) Elasticsearchのパスワードの設定 Elasticsearchでデフォルトで用意されているユーザーのパスワードを設定してします。手順では自動で生成させる方法ですが、独自に設定することも可能です。 Workplace Searchの起動 Elasticsearchが起動したらWorkplace Searchの設定をして起動します。\nEsへの接続設定をconfig/enterprise-search.ymlに指定 Esのパスワード設定時に生成されたelasticというユーザーのパスワードをここで指定。 yamlファイルに記載があるが、${ELASTICSEARCH_PASSWORD:changeme}という記述をした場合に環境変数を読み込める allow_es_settings_modification: trueをconfig/enterprise-search.yml ここに記載があるような変更をWorkplace SearchがEsのクラスターに対して実行する模様。Workplace Search以外でも使用しているElasticsearchクラスターの場合はallow_es_settings_modificationを有効にする代わりに、リンク先にあるような設定を自分で追加する。 secret_management.encryption_keysを複数設定 Encryption Keysのガイドに少し詳しい説明がある。 opensslコマンドとかで作ればいいかな?? 1.と同じような設定をしようとしたがうまくいかなかったので、ファイルにキーを設定する方式にしました(バグ?) 起動するときにデフォルトユーザーパスワードを指定 指定しなければ勝手に生成してコンソールに出力してくれるので、そちらの方がいいかと。 今回は手順通りに指定した。 起動確認のためhttp://localhost:3002にアクセス 起動するとログが流れ、問題がなければ次のようにデフォルトユーザーの情報が出力されます。\n######################################################### *** Default user credentials have been setup. These are only printed once, so please ensure they are recorded. *** username: enterprise_search password: pas...ple ######################################################### そして無事起動に成功したことも出力されます。\n######################################################### Success! Elastic Workplace Search is starting successfully. In a few moments, you\u0026#39;ll be able to login at the following address: * URL: http://localhost:3002 * If this is your first time starting Workplace Search, check the console output above for your user authentication credentials. * Visit the documentation: https://swiftype.com/documentation/enterprise-search Secret session key has been generated. Set the key in your config file to persist user sessions through process restarts: secret_session_key: c23...3 ######################################################### ブラウザで画面にアクセスすると、次のような画面が表示されました。\n起動時のエラー いくつかのパターンも試してどんなエラーが出るのかを見てみました。 おまけですね。\nElasticsearchが見つからないエラー Esを起動しないでWorkplace Searchを起動してみました。\n200秒間アクセスしようと試みて駄目だったらエラーで終了みたいです。\n[2020-05-07T03:48:33.645+00:00][13709][2002][app-server][INFO]: Failed to connect to Elasticsearch backend. Make sure it is running. ... [2020-05-07T03:51:54.038+00:00][13709][2002][app-server][INFO]: Could not connect to Elasticsearch backend after 200s. Terminating... [2020-05-07T03:51:54.039+00:00][13709][2002][app-server][ERROR]: -------------------------------------------------------------------------------- Error: Workplace Search is unable to connect to Elasticsearch. Ensure a healthy Elasticsearch cluster is running at http://127.0.0.1:9200 for user elastic. -------------------------------------------------------------------------------- ElasticsearchのSecurityがオフのときのエラー ちなみにSecurityをオフにしたままWorkplace Searchを起動した場合は以下のようなエラーが出ました。\n[2020-05-07T03:46:53.474+00:00][13567][2002][app-server][ERROR]: -------------------------------------------------------------------------------- Elastic Workplace Search requires Elasticsearch security features to be enabled. Please enable Elasticsearch security features as outlined here: https://www.elastic.co/guide/en/workplace-search/current/workplace-search-install.html -------------------------------------------------------------------------------- 構成要素 ここまでインストールして起動してきました。 では、Workplace Searchがどういったコンポーネントから構成されているかを予測してみましょう(あくまで外から見た予想となります。そのうちElastic社のウェビナーとかイベントで内部の発表とかあるかも?)。\nインストールページの記載から インストールページに最小ハードウェアという記載があり、そこで何が動く可能性があるかというのがわかります。\n起動するものはこんな感じみたいです。\nElasticsearch - 外部でもOK App Server - Workplace SearchのWeb機能 Worker - クローラーとかかな? Filebeat - Workplace Searchのログ収集用 その他プロセス - なんだろ? という具合です。\n設定などからの予想 次は設定項目や起動時のログなどからの予想です。\nWorklpace Search配下のセキュアなデータストア - アクセストークンなどの管理のため JRubyアプリケーション - App ServerはJRuby上で動いているRailsアプリ Filebeatも起動している - Workplace Searchのログ収集のため? Filebeatの接続設定はWorkplace Searchの設定値を利用 では構成要素は? ということで、現時点でわかった構成要素は以下のとおりです。\nElasticsearch Workplace Search App Server - Railsアプリ on JRuby Webアプリとは別に(内部?で)、いくつかのワーカーが存在する 管理画面と検索画面の2種類が存在 Filebeat - ログ収集 といった感じです。 まだ起動したばかりなのでこのくらいでしょうか。ログを見るともう少しわかりそうな気がします。\n基本的には、EsをバックエンドにしたRailsのミドルウェアになります。コネクターや検索画面はすべてWorkplace Searchのミドルウェア経由でアクセスする形になりますので、普通に検索で利用するユーザーにはElasticsearchの存在は見えない作りになっています。\n次は? Getting Startedを元に、どんなアクターがいて、どんな機能が提供されているのか、どんな利用方法なのか?というのを見ていこうと思います。\n","date":1588818770,"dir":"post/2020/","id":"44db1f1fefc97cd28d55d443f2bd2b63","lang":"ja","lastmod":1588818770,"permalink":"https://blog.johtani.info/blog/2020/05/07/install-workplace-search/","publishdate":"2020-05-07T11:32:50+09:00","summary":"前回はWorkplace Searchの概要について書きましたが、今回はインストールと構成要素について説明します。なお、2020/5/7時点で","tags":["elasticsearch","workplace search"],"title":"ElasticのWorkplace Searchを触ってみる - その2 - インストールと起動"},{"contents":"2月のElastic社のブログですが、Enterprise Searchとこれまで呼んでいた製品をWorkplace Searchという製品名に変更し、App Searchなどを含む製品群をEnterprise Searchという名前に変更しました(ちょっとややこしい)。 Workplace Search自体はまだβ版という位置づけですが、ダウンロードして試すことが可能です。\nきちんと触ったことがないので、ちょっと触って見ようかなと思い、何回かに分けてブログを書いてみます。まずは概要とかから。\nWorkplace Searchとは? Elasticsearchをバックエンドに利用するElastic社が提供するアプリケーション(ミドルウェア?)の1つです。\nもともとはSwiftypeという会社が作っていた、Site Search、App Searchと同じような系列で開発されている統合検索の検索エンジンミドルウェアという感じです。 製品ページを見るとわかりますが、様々なデータソースから、データをクロールしてElasticsearchに保存することで、統合された検索を提供することができるようになる製品です。 最近は会社のドキュメントがさまざまな場所(Google Drive、Saleseforce、GitHub、Dropboxなど)に保存されています。 それぞれで検索窓などはありますが、1箇所で検索することで横断的に検索でき、仕事の効率があがりますよね?ということで作られている製品です。\n提供(利用)方法は? 今後の提供方法としては、Elastic Cloudで利用できるSaaS形式のものと、独自に(クラウドのコンピューティングエンジンやオンプレのサーバーなどで)Workplace Searchのアプリを起動する方法(オンプレ版)があります。後者の場合は、Elasticsearchのクラスターを用意する必要があります。なお、後者の場合、Elasticsearchのサブスクリプションのプラチナライセンスが必要になるようです(ダウンロードページに記載あり)\nまだ、β版という位置づけなので、今後どのように変更されるかはわかりませんが、今回は2020年5月1日時点でのベータ版(7.6.0)を元にどんなものかを紹介します。現時点で利用できるのはβ版のオンプレ版で、MacやLinuxで利用可能です。\nダウンロードとインストール ダウンロードページにインストール方法などの記載があります。\nインストールして触って見るところはまた後日。\nライセンス、価格は? まだ不明です。SaaS版の提供はまだです。 オンプレ版については少なくとも、Elasticのサブスクリプションのプラチナが必要になります。こちらは、価格は公開されていません。Elastich社もしくはパートナー企業での問い合わせが必要になります。 (たぶん、ドキュメントレベルのセキュリティとかSSOとかの仕組みがプラチナで提供されているのでそのあたりを使っているのでは?と想像してます。)\n想定できそうな用途は? 社内の文書検索でしょうか。ただ、いわゆる昔ながらのエンタープライズサーチと呼ばれている、社内のファイルサーバーなどの文書検索ではなく、クラウドサービスを複数利用している会社が利用する想定になっています。\n例えば、開発者は社内Wiki(Confluence)で社内文書を書き、Issue管理にはJIRAやGitHubを活用しており、ただ、社内での説明にはGoogle Driveを利用しているといった場合です。こういう場合、あの機能についての説明や資料ってどこだっけ?というので、あちこち探し回ったりしないといけないです。また、営業部門やサポート、マーケティングなどが絡んでくると更に、SalesforceやZendeskといったデータソースも出てきます。 情報が散らばっていて、それらを探し出したりまとめるだけで時間を取られている場合などに便利かもしれません。\n次は? 実際にインストールしてから起動して、どんな感じで使えるのかといったところを見て、どんな機能が提供されているのかを見ていこうと思います。\n","date":1588318144,"dir":"post/2020/","id":"4d71d2a23c85fb7af20e8d1e8b3e0de8","lang":"ja","lastmod":1588318144,"permalink":"https://blog.johtani.info/blog/2020/05/01/intro-workplace-search/","publishdate":"2020-05-01T16:29:04+09:00","summary":"2月のElastic社のブログですが、Enterprise Searchとこれまで呼んでいた製品をWorkplace Searchという製品名に","tags":["elasticsearch","workplace search"],"title":"ElasticのWorkplace Searchを触ってみる - その1"},{"contents":"先日、Elasticsearchでのカスタム辞書の利用方法についてブログを書きました。\n辞書の設定方法について記載しましたが、今回は辞書の更新について書いていなかったので、書いてみようと思います。 ここで「辞書」としているのは、Kuromojiのユーザー辞書、Synonym Graph Token FilterのSynonym辞書(いわゆる類義語辞書)のことになります。サードパーティのAnalyzer等に関する話ではありません。\n辞書更新に関する制限事項 辞書の更新について、大原則と制限事項が存在します。\n大原則(辞書の更新=データも更新) ElasticsearchはAnalyzerが切り出した単語を元に転置インデックスを作成して、検索を行っています(この仕組みに関するスライドはこちらを参照のこと)。 Analyzerが辞書を持っている場合、その辞書を元に単語を切り出して転置インデックスに利用します。 また、検索クエリの単語に対してもこのAnalyzerの辞書が利用されます。\n辞書に新しい単語を追加するということは、その単語に関連するドキュメントも更新しないと行けないということになります。\n例えば、Kuromojiを利用していて、「グランベリーパーク」という単語「グランベリー」「パーク」という単語に分割できるような新しい単語として辞書に追加する場合を考えてみましょう。ユーザーが「グランベリー」で検索しても検索結果として出てきてほしいという場合です。\n辞書に「グランベリーパーク」を登録していない頃に登録されたドキュメントは「グランベリーパーク」という1単語として転置インデックスの見出し語を切り出します(Kuromojiはカタカナの連続している文字列については未知語として1単語にし、「名詞-一般」の品詞を付与)。\n更新前でのドキュメントのAnalyze結果\n「グランベリーパーク」「で」「ショッピング」 もし、辞書に「グランベリーパーク」を「グランベリー」「パーク」から構成される新規の単語として登録しそれを使用した場合、辞書を更新したあとから、「グランベリーパーク」という単語がAnalyzerからは出てこなくなります。\n更新後でのドキュメントのAnalyze結果\n「グランベリー」「パーク」「で」「ショッピング」 ということは、辞書更新以前のドキュメントは「グランベリーパーク」という見出し語に対して登録されているので、辞書更新以前に登録されているドキュメントは検索にヒットしなくなります。\nこのように転置インデックスを利用している検索エンジンでは、単語の区切りが変更されるような辞書の更新があった場合、最低でも影響があるドキュメントについては再登録が必要となるわけです。\nこれが大原則(辞書更新=データも更新)となります。 基本的には辞書の更新を行った場合は、ドキュメントの再インデックス(再登録)が必要となります。\nElasticsearchでの制限事項 Elasticsearchでは、辞書の更新に関して実装上の制限事項が存在しています。 内部的な実装として、ElasticsearchではAnalyzerのインスタンス(正確にはAnalyzerのFactoryのインスタンス)の生成がインデックスに関する内部のインスタンスが生成されたタイミングの1回のみとなっています。\nこのインスタンスの生成時に設定ファイル(辞書を含む)を読み込んでいます。\n言い換えると、辞書(ファイル、インデックス設定に関わらず)の読み込みは、インデックスが作られたタイミングのみということになります。 なおここで言う「インデックスが作られたタイミング」というのは、以下の2パターンです。\nインデックス新規作成時 インデックスオープン時 では、ここから辞書を更新してそれを既存のインデックスに適用する方法について説明しましょう。\n辞書の更新方法(ファイル編) 前回のブログで説明しましたが、Elasticsearch 7.4よりも古いバージョンでは、ファイルでKuromojiのユーザー辞書を設定していました。まずはこちらの方法について説明します。前提として、すでにユーザー辞書を設定したKuromoji Tokenizerがインデックスに設定されているものとします(ユーザー辞書の設定方法については公式リファレンスを御覧ください)。\n辞書ファイルに新規にエントリーを追加しただけでは、設定は読み込まれていません。新規辞書を反映させるためには以下の手順が必要となります。\n更新した辞書ファイルの配布 複数ノードでElasticsearchのクラスターを構成している場合はすべてのノードに更新した辞書ファイルを配布する必要があります。 インデックスのクローズ(公式リファレンス) 設定ファイルを再読込させるために一度インデックスをクローズします。 クローズするので、書き込み、検索などの処理を停止する必要があります。もし停止していない場合はクライアント側ではインデックスがクローズされているという旨のエラーを受け取ります(400で、index_closed_exception)。 インデックスのオープン(公式リファレンス) 設定ファイルを読み込みます。これで、新規追加された単語が読み込まれます。 再インデックス _update_by_queryを利用することで、対象のインデックスのデータを再インデックスすることができます。条件無しでAPIを呼び出すとすべてのデータが再度登録されます。 _sourceがfalseの場合は_update_by_queryは利用できません。元データをもう一度外部からElasticsearchに対して登録する必要があります。 Kibanaでの手順をGistにしてあります。手順はこちらをご覧ください。\n辞書の更新方法(インデックス設定編) ファイルの場合とは少し手順が異なります。 インデックスの設定としてユーザー辞書を登録しているため、ファイルをElasticsearchのクラスターにあるノードに配布する必要がありません。 また、辞書の設定はインデックスの設定に指定してありますが、こちらは動的に設定変更できる項目ではないため、インデックスを先にクローズする必要があります。\nインデックスのクローズ(公式リファレンス) 辞書の設定を更新するにはインデックスをクローズする必要があります。辞書の設定は動的に更新できる項目にはなっていないためです。 オープンしているインデックスで更新しようとした場合はillegal_argument_exceptionでCan't update non dynamic settings...というメッセージが返ってきます。 辞書の更新(公式リファレンス:インデックス設定の更新) user_dictionary_rulesに単語と追加します。 インデックスのオープン(公式リファレンス) 設定ファイルを読み込みます。これで、新規追加された単語が読み込まれます。 再インデックス _update_by_queryを利用することで、対象のインデックスのデータを再インデックスすることができます。条件無しでAPIを呼び出すとすべてのデータが再度登録されます。 _sourceがfalseの場合は_update_by_queryは利用できません。元データをもう一度外部からElasticsearchに対して登録する必要があります。 Kibanaでの手順をGistにしてあります。手順はこちらをご覧ください。\n第3の方法(新規インデックス作成) ここまで、インデックスのクローズ、オープンで既存のインデックスに対して辞書を更新する方法について説明しました。 ただ、残念なことにAmazon Elasticsearch ServiceではElasticsearchが提供しているすべてのAPIが利用できるわけではありません(Amazon ESの利用可能なAPIの一覧はこちら)。 (_closeは駄目だけど_openは呼べるのかな???)\nということで、新規にインデックスを作成して、新しい辞書の設定を反映したインデックスを用意し、そこにデータをコピーもしくは登録するという方法になります(Amazon ESのカスタム辞書のドキュメントに手順がありますね)。\n手順としては以下のとおりです。\n辞書の更新(用意) 新しい単語などを登録した辞書を用意します。 ファイル、インデックス設定どちらでもOKです。 ファイルの場合は、既存のファイル名とは異なるファイル名にしたほうが混乱がなくなります。 新規インデックス作成 1.で作成した辞書を元に新規インデックスを作成します。 新規インデックスにデータコピー _reindex APIを利用するとデータコピーが簡単です。sourceとdestを指定するだけです。 _sourceがfalseの場合は_update_by_queryは利用できません。元データをもう一度外部からElasticsearchに対して登録する必要があります。 アプリケーション側で新規インデックスを利用するように変更 _aliasを使用しておくと切り替えが簡単です(公式リファレンスはこのあたり)。 考慮すべき点としては、サービスを提供しながら行う場合は、3.の_reindexを実行し始めたタイミング以降の登録・更新データの扱いについてでしょうか。\nまとめ 辞書の更新に関する大原則、制限事項、手順などについて説明しました。 辞書の変更は検索に大きく影響がでます。そのあたりをきちんと考慮しながら更新しましょう。 ユーザー辞書、カスタム辞書を扱う際の参考にしていただければと。 他にもユーザー辞書で気をつけないといけないこともありますが、今日はこのあたりで。\n","date":1587951855,"dir":"post/2020/","id":"be2c49ea5816e7daa6d3b3ff45353291","lang":"ja","lastmod":1587951855,"permalink":"https://blog.johtani.info/blog/2020/04/27/note-updating-dictionary/","publishdate":"2020-04-27T10:44:15+09:00","summary":"先日、Elasticsearchでのカスタム辞書の利用方法についてブログを書きました。 辞書の設定方法について記載しましたが、今回は辞書の更新","tags":["elasticsearch"],"title":"辞書の更新についての注意点"},{"contents":"Elasticsearchで日本語を扱うときに、カスタム辞書を使いたいという要望がよくあります。 AWSのElasticsearch Serviceでカスタム辞書ファイルを読み込める機能が発表されたようです。\n実は、Elasticsearchの7.4からファイルを使用しなくても日本語のTokenizerでカスタム辞書を利用することができるようになっています。\nカスタム辞書をインデックスの設定で指定 やり方はドキュメントに記載があります。\nトークナイザーの設定をインデックスの設定に記述しますが、このときに user_dictionary_rulesという設定を利用することでカスタム辞書を指定できます。\nPUT custom_dic_sample { \u0026#34;settings\u0026#34;: { \u0026#34;index\u0026#34;: { \u0026#34;analysis\u0026#34;: { \u0026#34;tokenizer\u0026#34;: { \u0026#34;kuromoji_user_dict\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;kuromoji_tokenizer\u0026#34;, \u0026#34;mode\u0026#34;: \u0026#34;extended\u0026#34;, \u0026#34;user_dictionary_rules\u0026#34;: [ \u0026#34;グランベリーパーク,グランベリー パーク,グランベリー パーク,カスタム名詞\u0026#34;, \u0026#34;高輪ゲートウェイ,高輪 ゲートウェイ,タカナワ ゲートウェイ,カスタム名詞\u0026#34;] } }, \u0026#34;analyzer\u0026#34;: { \u0026#34;my_analyzer\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji_user_dict\u0026#34; } } } } } } 辞書の内部は\u0026quot;単語,出てきてほしい単語列(スペース区切り),読みの単語列(スペース区切り),品詞名\u0026quot;になります。配列で設定可能で、複数の単語を登録したい場合は、カンマ区切りで登録していきます(上記例では2つの単語を登録しています)。\n_analyzeを利用して設定の確認 実際に上記の設定がうまく動作するかは_analyzeのエンドポイントを利用します。\nGET custom_dic_sample/_analyze { \u0026#34;text\u0026#34;: \u0026#34;グランベリーパークがオープンしました。\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;my_analyzer\u0026#34; } 出力は以下のようになります。\n{ \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;グランベリー\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 6, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 0 }, { \u0026#34;token\u0026#34; : \u0026#34;パーク\u0026#34;, \u0026#34;start_offset\u0026#34; : 6, \u0026#34;end_offset\u0026#34; : 9, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 1 }, { \u0026#34;token\u0026#34; : \u0026#34;が\u0026#34;, \u0026#34;start_offset\u0026#34; : 9, \u0026#34;end_offset\u0026#34; : 10, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 2 }, { \u0026#34;token\u0026#34; : \u0026#34;オープン\u0026#34;, \u0026#34;start_offset\u0026#34; : 10, \u0026#34;end_offset\u0026#34; : 14, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 3 }, ...(省略) ] } ちなみに、デフォルトのkuromojiを利用した場合は、グランベリーパークが1単語として出力されます。\nGET _analyze { \u0026#34;text\u0026#34;: \u0026#34;グランベリーパークがオープンしました。\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34; } ## レスポンス { \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;グランベリーパーク\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 9, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 0 }, { \u0026#34;token\u0026#34; : \u0026#34;オープン\u0026#34;, \u0026#34;start_offset\u0026#34; : 10, \u0026#34;end_offset\u0026#34; : 14, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 2 } ] } これで、カスタム辞書を使用することでグランベリーで検索された場合に、グランベリーパークもヒットするという仕組みです。\n_analyzeはexplainというパラメータも持っており、こちらを利用することで、単語の品詞情報なども取得できます。これを使うことで、実際に設定がきちんと動作しているかの確認に利用できます。\nGET custom_dic_sample/_analyze { \u0026#34;text\u0026#34;: \u0026#34;グランベリーパークがオープンしました。\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;my_analyzer\u0026#34;, \u0026#34;explain\u0026#34;: true } ## レスポンス(一部のみ) { \u0026#34;detail\u0026#34; : { \u0026#34;custom_analyzer\u0026#34; : true, \u0026#34;charfilters\u0026#34; : [ ], \u0026#34;tokenizer\u0026#34; : { \u0026#34;name\u0026#34; : \u0026#34;kuromoji_user_dict\u0026#34;, \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;グランベリー\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 6, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 0, \u0026#34;baseForm\u0026#34; : null, \u0026#34;bytes\u0026#34; : \u0026#34;[e3 82 b0 e3 83 a9 e3 83 b3 e3 83 99 e3 83 aa e3 83 bc]\u0026#34;, \u0026#34;inflectionForm\u0026#34; : null, \u0026#34;inflectionForm (en)\u0026#34; : null, \u0026#34;inflectionType\u0026#34; : null, \u0026#34;inflectionType (en)\u0026#34; : null, \u0026#34;partOfSpeech\u0026#34; : \u0026#34;カスタム名詞\u0026#34;, \u0026#34;partOfSpeech (en)\u0026#34; : null, \u0026#34;positionLength\u0026#34; : 1, \u0026#34;pronunciation\u0026#34; : null, \u0026#34;pronunciation (en)\u0026#34; : null, \u0026#34;reading\u0026#34; : \u0026#34;グランベリー\u0026#34;, \u0026#34;reading (en)\u0026#34; : \u0026#34;guramberi\u0026#34;, \u0026#34;termFrequency\u0026#34; : 1 }, { partOfSpeechにカスタム辞書で設定したカスタム名詞が出力されていますね。 _analyzeのAPIはこのように、アナライザーの挙動の確認に非常に便利なので是非活用してみてください。\nKibanaでこのAPIを使うためのプラグインも開発していますので、こちらも合わせて利用してみてください。\n注意点 ちなみに、user_dictionaryとuser_dictionary_rulesを両方指定した場合はエラーとなります。 ファイルをベースにしつつ、追加の設定をするという使い方はできないので、注意しましょう。\nインデックスの設定で書くことにより、バックアップ・リストアは楽になるかな。ただ、クラスターステートに取り込まれるから、あまりにも巨大なカスタム辞書だと心配かなぁ。ファイルの場合はクラスターステートには取り込まれないので、そこは圧迫しない。\n\u0026mdash; Jun Ohtani (@johtani) April 22, 2020 それ以外の注意点については、別途ブログを書きました。 「辞書の更新についての注意点」、こちらも合わせてご覧ください。\nまとめ カスタム辞書をファイルではなくインデックスの設定値として設定する方法を紹介しました。こちらは、Elasticsearch 7.4で導入された機能になります。7.4以降を利用している場合はこちらを利用することも検討してはいかがでしょうか? また、_analyze APIも便利なので合わせて活用してみてください。\n","date":1587519056,"dir":"post/2020/","id":"15357b6978e83daa2d97692c861dc177","lang":"ja","lastmod":1587519056,"permalink":"https://blog.johtani.info/blog/2020/04/22/custom-dictionary-after-7-4/","publishdate":"2020-04-22T10:30:56+09:00","summary":"Elasticsearchで日本語を扱うときに、カスタム辞書を使いたいという要望がよくあります。 AWSのElasticsearch Servi","tags":["elasticsearch"],"title":"Kuromojiのカスタム辞書をインデックスの設定で指定"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 第8章 7章はパッケージなので後回しにして、8章に入ります。 8章はコレクションです。\nベクタ型 ベクタは同じ型の値だけ保持可能。 ジェネリクスで型を指定可能 - Vec\u0026lt;i32\u0026gt;とか。 vec!マクロで初期値とか設定すると便利。 ベクタに値を追加するのはpush。もちろん値が変わるので元のベクタにはmutが必要 ベクタのスコープ(ライフサイクル)は要素に対する参照があるのとないので話が変わってくる メモリの確保などの影響で、ベクタ全体に対して借用の規則が矯正されると。 ベクタの値を読むのはいくつか方法あり getメソッドはOptionを返す \u0026amp;v[2]の添字記法の場合はパニックの可能性あり 走査(唐突に参照外しが出てきた) 単純に値を取り出す場合はfor - in \u0026amp;v Enumをベクタにいれることで、異なる型も保持可能(まぁ、Enumの型では固定されるけど)。 これだけのためにEnumを使うことってあるのかな? トレイとオブジェクトに関する文章はちょっとわかりにくい。。。 説明以外のメソッドなどについてはAPIドキュメント見ましょうと(リンクも張ってくれてると嬉しいなぁと思ったり。まぁ、バージョンとかの絡みがあるから難しいか)。\n文字列型 文字列はUTF-8でエンコードされた文字を扱うための型。\nstrは文字列データへの参照。\nString型は言語のコアではなく、標準ライブラリに入っている文字列型。\n他にもあるのか。。。OsStringとか。。。 文字リテラルはDisplayトレイトを実装していると。\n.to_string() = String::from\nStringはコレクションだから追加とかが可能なのか、なるほど。\npush_strとpush\n+演算子での参照。\n\u0026amp;Stringは\u0026amp;strに型強制(キャスト?)してくれる。してくれる場合としてくれない場合もあるのかな?s2の所有権は奪わない形で扱うのでs2はこのあとも使えていると。 ここでは、s1を変更したあとに所有権がs3に持っていかれてる? format!を使うとどの所有権も奪わないので、これを使うほうが考え方は簡単そう。ただし、効率がいいかはわからん。 添字記法でのアクセスをStringは許容していない\n文字の境界が必ずしも1バイトとは限らないから。 スライスも同様。 基本的には.chars()で文字としてアクセスするのが良い。\n逆にバイト表現を得る方法はどうするんだろう?\nNLP100本ノックではencode_utf8メソッド使ったけど。 ハッシュマップ いろんな呼び方あるよね。Rustではハッシュマップだよ。 ハッシュマップはuseしないと使えない キーは1つの型、値も1つの型 タプルのベクタからcollectで生成。なるほど。 タプルのベクタだと、タプルの中身は同じものであることが言える? -\u0026gt; 言える。エレメント数が異なるとコンパイルエラーになった 所有権周りの話。 これ、ベクタのときに話してほしい感じがした。 値を渡すか参照を渡すかによって話が変わってくる。詳しくは10章 このあたりが自分が混乱していた元だ。 entryとinsertの違い entryの戻り値はEntryというenumでor_insertというメソッドがありそれを使うと存在しない場合だけinsertが呼ばれる。 これ便利だ。毎回existあたりで存在チェックしてた気がする。 or_insertは可変参照\u0026amp;mut Vを返す。 これをlet countで束縛するときに、中身が可変かどうかをcountには指定しないのか。。。 まとめ 一応、大学などで習ってた(はず)ですが、 スタックとヒープを意識して考えないといけないなぁというのを何度か意識させられた感じです。\nあと、これはRustに限らずですが、それぞれがどんな関数を持っているか、どんなメソッドを持っているか、どんなマクロが存在するかなどを探すときにみんなどうしてるんだろう? 人に教えてもらっているのか、APIリファレンスを探すのか、そういったところをみんながどういう感じにプログラミング言語を勉強しているか、業務で書いているのかと言うのが気になりました。\n","date":1587028650,"dir":"post/2020/","id":"f488aa62d39194824861a134567cadb8","lang":"ja","lastmod":1587028650,"permalink":"https://blog.johtani.info/blog/2020/04/16/chap8-rust-the-book/","publishdate":"2020-04-16T18:17:30+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 第8章 7章はパ","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第8章"},{"contents":"Rustで言語処理100本ノックのリファクタリングの続き。\n前回はこちら。\nコードも載せたほうが見やすいかなぁ?\n03. 円周率 2年前はこちら。 どちらかというとJavaっぽい書き方かな? 入れ物を用意して、入力を整形して、それからループを回す感じで書いてました。\n今回は1行で収めてみました。 Rustっぽく、returnを省略してみました。 あとは、Iteratorを組み合わせる感じでやってます。 アルファベットの文字数ということで、is_alphabetic()メソッドでfilterしてます。\n04. 元素記号 2年前はこちら。 エラー処理が多いのと、文字の扱いがちょっと\nここまで同様に極力イテレータを利用するという方針でリファクタリングしました。 あとは、エラー処理を除去してます。 正常系だけのテストなのでスッキリさせました。\nこういった、ストリーム系?の書き方の場合にエラー処理をどう入れるかってところはちょっと悩みどころになるんじゃないかなぁ?と思いつつ、イレギュラーなものは後回しで(あとにやるのかなぁ?)\n05. n-gram 2年前はこちら。 これまでと同じく、入れ物を作ってから処理をしてます。\n同じく、極力イテレータを利用する形で実装しました。 いくつか型の変換が必要なので、.map()を呼び出して詰め替えたりしています。\n06. 集合 2年前はこちら。 独自に実装しています。\nせっかく05で文字n-gramの配列を返す処理を実装しているので、 そちらを呼び出して、Setに入れるという処理に書き換えました。 その後の集合に対する処理については特にリファクタリングしてないです。\nまとめ 2年前にやってたところまでは追いつきました。 07は特にリファクタリングする必要がないので、次は08からの予定です。\nリファクタリングしているときになるのは、速度とかでしょうか。 実装の違いでなにか差が出るのかどうかはちょっと気になるところですが、 今回の目的ではないので、目をつぶって進める予定です。\n","date":1586423695,"dir":"post/2020/","id":"9a687babb0f44db51dc389b75bdaa19d","lang":"ja","lastmod":1586423695,"permalink":"https://blog.johtani.info/blog/2020/04/09/reboot-nlp100-ch01-03to05/","publishdate":"2020-04-09T18:14:55+09:00","summary":"Rustで言語処理100本ノックのリファクタリングの続き。 前回はこちら。 コードも載せたほうが見やすいかなぁ? 03. 円周率 2年前はこちら。 どちらか","tags":["Rust","nlp100"],"title":"第1章の03から06まで(言語処理100本ノック2020)"},{"contents":"今回もツイートから。\n言語処理100本ノックの2020年版を公開しました。最近の自然言語処理の研究動向を反映し、深層ニューラルネットワークに関する問題を追加しました。留学生も一緒に取り組めるように多言語化を進め、その第１弾として英訳を部分公開しています（40番以降は順次公開予定）。 https://t.co/52h362PIQQ\n\u0026mdash; Naoaki Okazaki (@chokkanorg) April 6, 2020 言語処理100本ノックが2020年版になったそうです。 そうです、2年前に初めて、準備運動で止まっていたんです!(衝撃的な続かなさ。。。)\nということで、Rust the bookも読んでいることだし、過去のプログラムをチェックしつつ再開しようかなと。 ということで、いくつかリファクタリングしてみました。\nソースはリポジトリを御覧ください。\n00. 文字列の逆順 2年前の実装では、chars()メソッドで取り出したあとに、collect()でVecにしていたのですが、RustのIteratorトレイトにrev()という便利なメソッドが存在していました。\nということで、これを取り出すと、最初の文字列の逆順で文字を取り出すIteratorが取得できます。 あとは、Stringが実装してくれているfrom_iterに渡せば文字列が出来上がります。\n01. 「パタトクカシーー」 ストリーム処理っぽい書き方に変更しました。 2年前はIteratorを取り出して、詰替していましたが、 enumerate()で添字と文字のタプルのイテレータに変換し、 filterで添字が偶数のときだけフィルタリングして、 mapで対象の文字をまとめたイテレータにします。 で、最後はそれを元に文字列を生成することにしました。 iterを使わないでそのままString::from_iterの引数に渡すことも可能ですね。\n02. 「パトカー」＋「タクシー」＝「パタトクカシーー」 2年前は2つのIteratorをloopで回して頑張って結合してました。 ではなく、zip()を使って、2つのイテレータを組み合わせる方法に替えてみました。 このとき、2つの文字列が違う文字数の場合の処理として、長い方から取り出した文字をあとに結合する処理を追加で記述しました。 ちょっとスマートな感じになりましたかね?\nzipしたあとに出てきたタプルの文字列を結合するのにformat!マクロを使いましたが、他にいい方法有るかなぁ?\nまとめ とりあえず最初の3つをリファクタリングしてみました。 残りもやりつつ、準備運動以降もがんばるぞと。\n","date":1586338425,"dir":"post/2020/","id":"dc9580308938069159c5afc55b2f3b96","lang":"ja","lastmod":1586338425,"permalink":"https://blog.johtani.info/blog/2020/04/08/reboot-nlp10-with-rust/","publishdate":"2020-04-08T18:33:45+09:00","summary":"今回もツイートから。 言語処理100本ノックの2020年版を公開しました。最近の自然言語処理の研究動向を反映し、深層ニューラルネットワークに関","tags":["Rust","nlp100"],"title":"言語処理100本ノック、再び"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 第6章 Enumです。match式に大活躍\nEnumを定義する 列挙型は取りうる値をすべて列挙できる。これが名前の由来 列挙型と列挙子 2連コロン(::)で列挙子を指定可能 列挙子にデータ(構造体も)が格納可能。 標準ライブラリに実装例あり。 疑問:Write(String)とかはタプルの表現になるのかな? と思ったが、タプルでは1つだけの変数を持つものは定義(正確には定義できるが、内部で普通の変数にもどされてるっぽい)できなかった。 メソッド定義も可能 関連関数もできる? -\u0026gt; できる Optionの紹介 Rustにnullはない。代わりにOptionがある Noneを指定する場合に型が必要。Someの場合はすでに値が入るから推測可能なため。 match制御フロー演算子 アーム -\u0026gt; matchしたときの処理のこと 短い場合は波括弧は不要 returnなしでmatchが書いてあるだけだと、慣れない場合に値を返していることに気づかないかも(実際気づけてないかも) Enumが値を持っているときに、値の束縛がmatch式で可能 すべての列挙子を網羅していないことをコンパイラが検知してくれるのはすごく助かる。 ただし、_を利用していなければだけど if letで簡潔な制御フロー enumで1つのパターンのときに処理をしたい場合に使えるmatchの糖衣構文 elseもかけるよ。 まとめ enumに慣れていないので、値や構造体を持つenumを利用するという想像ができないことがありそうだなぁと読みながら思いました。 それになれると、色々とプログラムがシンプルに書ける部分が多くなりそうかな。\n","date":1586255231,"dir":"post/2020/","id":"4fbdc9c57a37781dc5dd86f470c61d04","lang":"ja","lastmod":1586255231,"permalink":"https://blog.johtani.info/blog/2020/04/07/chap6-rust-the-book/","publishdate":"2020-04-07T19:27:11+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 第6章 Enumです。matc","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第6章"},{"contents":"Kuromoji-CLIの使い方などについては過去のブログを御覧ください。\nKuromojiのCLIコマンドとpicocliとGraalVM GitHubリポジトリ Issueだけ上げていたJSON出力対応をしました。 また、ラティス(後述)の出力対応もしました。\nJSON出力 LinderaがJSON出力に対応してるのでそれを真似しました。 -o jsonで指定していただくと、次のようなJSONが出力されます。\n% echo \u0026#34;春眠暁を覚えず\u0026#34; | build/graal/kuromoji -o json [ { \u0026#34;text\u0026#34;: \u0026#34;春眠\u0026#34;, \u0026#34;detail\u0026#34;: [ \u0026#34;名詞\u0026#34;, \u0026#34;一般\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;春眠\u0026#34;, \u0026#34;シュンミン\u0026#34;, \u0026#34;シュンミン\u0026#34; ] }, { \u0026#34;text\u0026#34;: \u0026#34;暁\u0026#34;, \u0026#34;detail\u0026#34;: [ \u0026#34;名詞\u0026#34;, \u0026#34;一般\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;暁\u0026#34;, \u0026#34;アカツキ\u0026#34;, \u0026#34;アカツキ\u0026#34; ] }, { \u0026#34;text\u0026#34;: \u0026#34;を\u0026#34;, \u0026#34;detail\u0026#34;: [ \u0026#34;助詞\u0026#34;, \u0026#34;格助詞\u0026#34;, \u0026#34;一般\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;を\u0026#34;, \u0026#34;ヲ\u0026#34;, \u0026#34;ヲ\u0026#34; ] }, { \u0026#34;text\u0026#34;: \u0026#34;覚え\u0026#34;, \u0026#34;detail\u0026#34;: [ \u0026#34;動詞\u0026#34;, \u0026#34;自立\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;一段\u0026#34;, \u0026#34;未然形\u0026#34;, \u0026#34;覚える\u0026#34;, \u0026#34;オボエ\u0026#34;, \u0026#34;オボエ\u0026#34; ] }, { \u0026#34;text\u0026#34;: \u0026#34;ず\u0026#34;, \u0026#34;detail\u0026#34;: [ \u0026#34;助動詞\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;特殊・ヌ\u0026#34;, \u0026#34;連用ニ接続\u0026#34;, \u0026#34;ぬ\u0026#34;, \u0026#34;ズ\u0026#34;, \u0026#34;ズ\u0026#34; ] } ] Viterbiラティス出力 Kuromojiが内部でトークンをどのように切り出すかを計算するためのViterbiのラティスです。これをGraphvizというツールのDOTフォーマットのファイルとして出力できるメソッドがデバッグ用ですが、Kuromojiに用意されています。 こちらを呼び出して出力するオプション-v(もしくは--viterbi)を追加しました。 注意点として、このオプションを指定すると、DOTファイルが標準出力に出力され、トークンの結果は標準エラーに出力されます。\necho \u0026#34;春眠暁を覚えず\u0026#34; | build/graal/kuromoji -v \u0026gt; viterbi.dot .dotファイル自体は画像ではないので、Graphvizのdotコマンドにて画像ファイルに変換する必要があります。\ndot -Tpng viterbi.dot -oviterbi.png これで、PNGファイルが出来上がります。出来上がったファイルはこんな感じです。\n画像を見ていただくと、緑色のパスがあるのがわかります。 こちらが、Kuromojiが実際に採用した形態素のリストです。それ以外のパスは不採用だったパスとなります。\nちなみに、macOSで1行で画像表示まで行うにはこんな感じで実行します。 openコマンドでpreviewアプリを指定することで画像が表示できます。 Windowsは。。。わかりません、すみません。\n% echo \u0026#34;春眠暁を覚えず\u0026#34; | build/graal/kuromoji -v -o json | dot -Tpng | open -f -a preview.app まとめ これ以前に複数辞書対応などもしていました。 今回は2つの出力形式を追加してみました。 特にViterbiラティス出力については、内部的にどのようなコスト計算で最終的な結果が出てきているかという理解に役立ちます。想定していない切れ方の場合は、そもそも想定している形態素になっていないか、コスト計算で不採用だったかなどを確認できますので、使ってみると面白いかもです。\n","date":1586143600,"dir":"post/2020/","id":"6fbf7c3d0f4f89e415e89cec28811a94","lang":"ja","lastmod":1586143600,"permalink":"https://blog.johtani.info/blog/2020/04/06/update-kuromoji-cli/","publishdate":"2020-04-06T12:26:40+09:00","summary":"Kuromoji-CLIの使い方などについては過去のブログを御覧ください。 KuromojiのCLIコマンドとpicocliとGraalVM G","tags":["misc"],"title":"KuromojiのCLIコマンドにJSON出力とラティス出力を追加"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 第5章 構造体です。勝手知ったるなんとやら?オブジェクト指向的な部分は問題ないかなぁと。\n定義とインスタンス化 structで定義 インスタンスの生成は引数は順不同でOK 構造体のインスタンスを可変にするとフィールドの値も変更可能 特定のフィールドのみ可変にすることは不可能 インスタンス化する関数の最後でreturnなしでインスタンスの返却を暗黙にできる(return書いてほしいな。。。) インスタンス化時にフィールド初期化省略記法が可能(これはちょっと便利?) 構造体更新記法..user1のように、明示的に設定されていない他のフィールドをコピーしてくれる機能あり タプル構造体 タプル構造体!? struct Color(i32, i32, i32); いつ使うんだろう? ユニット様構造体 ユニット様構造体 = フィールドのない構造体。トレイトを実装したいけどインスタンスで持つ値はない場合に利用 ライフタイム 構造体が参照を持つときにライフタイムという話が出てくる。なるほど。 ライフタイム指定子が必要になる -\u0026gt; 10章での話 プログラム例 タプルを引数かぁ。タプルは慣れないので構造体作りそう Debugトレイトと{:?}という書き方 derive(Debug)でデバッグ用のトレイトを自動で実装=継承してくれる {:#?}だとpretty printになる(改行とか入る) この辺の便利なトレイとは付録Cにあるらしい。この辺はやりながら覚えるしかないか。\nメソッド記法 最初の引数は必ずself implは構造体とは別の場所に書く = Javaのクラスとは違う struct Rectangle { width: u32, height: u32, } impl Rectangle { fn area(\u0026amp;self) -\u0026gt; u32 { self.width * self.height } } 参照じゃないselfも使えるらしい。どういうときに使うんだろう? 関連関数 selfなしの関数をimplにかける。Javaのスタティックメソッドみたいな感じ その他 implブロックがあちこちにかける。これはつらいな。。。 2つにわかれたimplブロックに同じメソッドを書いてみたら、CLionのプラグインではエラーを検知してもらえなかった。 cargo buildではきちんとエラーが表示された。 複数のimplブロックが有用になるケースは第10章で見ますが、そこではジェネリック型と、トレイトについて議論します。\n人の構造体に自分のトレイトを適用したりもできる。 実験 スコープとかどうなりそう?って実験もしてみた。\nfn main() { trait Hoge { fn trim(\u0026amp;self); } impl Hoge for String { fn trim(\u0026amp;self) { println!(\u0026#34;hogehoge {}\u0026#34;, \u0026amp;self); } } let c = String::from(\u0026#34;hoge\u0026#34;); c.trim(); println!(\u0026#34;{}\u0026#34;, fuga(\u0026amp;c)); } fn fuga(d: \u0026amp;String) -\u0026gt; \u0026amp;str { d.trim() } 出力はこんな感じ\nhogehoge hoge hoge まとめ 気になったのは以下の点。そのうち分かるようになってくるのかな。\n構造体更新記法はどういったときに使うのを想定して作ったんだろう?とか 可変長引数はマクロじゃないとだめ ","date":1585807758,"dir":"post/2020/","id":"8d9c3760395e8e0eb40e335b22750b68","lang":"ja","lastmod":1585807758,"permalink":"https://blog.johtani.info/blog/2020/04/02/chap5-rust-the-book/","publishdate":"2020-04-02T15:09:18+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 第5章 構造体です。勝手知ったるなんとやら?","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第5章"},{"contents":"すもけさんが在宅勤務環境をブログに書いてておもしろそうだな(あと、アフィリンク貼れるな)と思ったので自分の環境も書いてみようかなと。\n私自身は昨今の新型コロナウイルスの影響というのではなく、もう10年以上自宅でも作業ができる環境を整えています。 前前職の頃から家でも仕事をすることがよくあったので。今は、お客さんに恵まれていてリモートができる形で働かせていただいてます。\n机周りはこんな感じです。机はこれも15年以上前から使用しているエレクターの机です。椅子も15年以上前から使っているアーロンチェア(購入時は高いと思ったけど、これだけ使えているので大満足)です。\nメインのPCはMac Book Pro16インチを使っています。それとは別にMac miniがMac bookの後ろに隠れています。こっちはブラウジングや音楽を聞いたりするために使っています。\nまずはディスプレイ周りから。\nディスプレイ周り ディスプレイ Acerの31インチディスプレイです。昨年の夏に購入しました。28インチの4Kディスプレイを探していたのですが、セールか何かで2-3000円の違いでこのサイズが買えたので、このサイズになっちゃいました。Mac Book ProはDisplay port-USB-Cケーブルで接続し、PS4をHDMIで接続しています。 【Amazon.co.jp 限定】Acer モニター ディスプレイ ET322QKwmiipx 31.5インチ マイクの左側に写っているのはAppleのサンダーボルトディスプレイです。縦にしてブラウザやミュージックプレイヤーなどで音楽かけながら仕事をしています。 サブディスプレイって感じです。 Mac Book ProとMac miniの両方を操作するのですが、できれば同じキーボード+トラックパッドがいいなということで、Synergyというソフトを使って、Mac Book Proのキーボードとマウスでネットワーク越しにMac miniを操作しています。ただ、マシンの再起動後などにこのソフトが起動していない場合もあるので、Mac Book Proの右側にMac miniのためのトラックパッドがおいてあります。\nディスプレイアーム ディスプレイはそれぞれディスプレイアームを使っています。写真のようにMac Book Proを下に、外部ディスプレイを上にという上下で作業をしています。 16インチの画面だと普通のディスプレイの足だとメインディスプレイにかぶってしまうので、アームに切り替えました。 最初はグリーンハウスの激安を使っていたのですが、31インチのディスプレイだとアームの高さが足りなかったので、2つ目のガススプリング式のアームを追加で購入しました。ガススプリング式なのに5千円しないので、かなりお得感があります。ただ、ディスプレイは基本的に動かさないので、どちらかというとディスプレイの足の部分を効率良く使うことが目的です。\nAmazon | グリーンハウス 液晶ディスプレイアーム 4軸 クランプ式 Amazon | HUANUO PC モニター アーム 液晶ディスプレイ アーム ガススプリング式 サウンド関連 スピーカー 基本、音楽を聞きながら作業をするので、小型だけどしっかりと音がでるスピーカーを買いました。スタイルもいいし気に入ってます。 入力が2系統あるので、31インチディスプレイのヘッドフォン出力とMac miniのからの出力の2つをつないでいます。 仕事中はMac miniで音楽流しつつ、テレカンやゲームのときはメインディスプレイからの音が出る形です。 Amazon | ヤマハ パワードスピーカー NX-50 マイク 前職がDeveloper Advocateということで、インタビューなどに行くこともあるかも?ということで小さめのも運びができるコンデンサマイクを購入してました。結局それほど持ち運びはしてないのですが、値段の割には音がいいんじゃないかな?一応、無指向と単一指向の2種類を切り替えることが可能です。\nAmazon | SAMSON マイク ポータブル USB コンデンサ Go Mic | コンデンサ | 楽器 マイクスタンド マイクはあったのですが、クリップ式でした。PCのディスプレイにクリップしていると、打鍵音を拾ってしまうので、マイクスタンドを最近導入しました。やすかったです。 前まではヘッドフォンのケーブルに付いているマイクで喋っていたのですが、服によってはマイクに擦れてしまい、ノイズが載っていました。 マイクスタンド+スピーカーでもスピーカーの音をマイクが拾わないので、最近はヘッドフォンを使用しないで気楽に話ができるようになっています。 Amazon | Luling Arts マイクスタンド アーム その他 モニタスタンド Mac Book Proの後ろで見えにくいですが、Mac miniが下に入っていて、上にMac mini用のキーボード、スピーカー、Qiの充電パッドが載せてあります。 Mac miniのキーボードをじゃまにならないように置きたいという目的で購入しました。3次元で空間が利用できるので結構重宝してます。 Amazon | サンワサプライ 机上液晶モニタスタンド(D200・黒) MR-LC303BK 充電関連 スマホ充電用にスピーカーの横においてあります。ただ、スイートスポットを探すのがちょっと大変で、時々充電できてないことがあったりします。。。 Amazon | DesertWest Qi 急速充電ワイヤレス充電器 【Qi認証済み/PSEマーク付き】15W USBでの様々な充電用にはMercariさんのカンファレンスでいただいたAnkerの充電器をおいてあります。Mi Band 4、キーボードなどの充電向けです。 Amazon | Anker PowerPort 6(60W 6ポート USB急速充電器) まとめ 簡単ですが作業環境でした。だいたい満足しています。もうちょっと改善したいなと思っているのは次の点です。\nUSB-Cドック?ハブ?みたいなものがほしい 充電ケーブル、マイク、ディスプレイケーブル、有線LANの4つのケーブルがMac Book Proに刺さっており、ポートが全滅です。出先から帰ったときにつなぐのも少し面倒なので、1つか2つのポートでまとめられるといいなぁと思っています。が、ドック系はいい値段するのでまだ置き換わっていない感じです。 スタンディングデスクが気になる 自宅でずっと座っているのはやはり気になるもので。スタンディングデスクにして時々たって作業したいなぁと思うことがあります。ただ、使ったことがないので、どれがいいのかわからず手を出せない状況です。 ウェブカメラいる? Mac Book Proのカメラでオンラインミーティングなどしています。気にするほどのことではないとは思いますが、メインディスプレイを見ながらしゃべると下からカメラで撮影されている形になります。。。 今のところはこんな形です。なにかの参考になればと。 あと、なにかおすすめのもの(特にスタンディングデスク)があれば教えて下さい!\n","date":1585217511,"dir":"post/2020/","id":"3f431bf71ee866f626daf42bc915fa3f","lang":"ja","lastmod":1585217511,"permalink":"https://blog.johtani.info/blog/2020/03/26/working-facility/","publishdate":"2020-03-26T19:11:51+09:00","summary":"すもけさんが在宅勤務環境をブログに書いてておもしろそうだな(あと、アフィリンク貼れるな)と思ったので自分の環境も書いてみようかなと。 私自身は","tags":["misc"],"title":"自宅の作業環境(2020)"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた 第4章 第4章です。たぶん、これがいちばん大事な概念だと思います、Rustの。 そして、つまみ食いしながらRust書いてましたが、ここがきちんと理解できないまま書いてたってのもあります。。。\n所有権とは? drop関数ってのがあって、明示的に呼ぶことも可能。次のような感じで。2つ目のprintln!はエラーになる。sがもう無いのに借用しようとしてるから。 fn main() { let mut s = String::from(\u0026#34;hello\u0026#34;); s.push_str(\u0026#34;, world!\u0026#34;); println!(\u0026#34;{}\u0026#34;, s); drop(s); println!(\u0026#34;{}\u0026#34;, s); } ムーブ - shallow copyではない。以下の2行目がムーブ。 let s1 = String::from(\u0026#34;hello\u0026#34;); let s2 = s1; println!(\u0026#34;{}, world!\u0026#34;, s1); スタックとヒープの話が絡んでくる。あんまり意識すること無いよなぁ。 スタック = 固定長のデータを入れる場所。ポインタ、数値など ヒープ = 可変長のデータが入る場所。可変の文字列とか。\nクローン - ヒープのデータをコピーすること。 コピー - スタックに収まるデータの場合はクローンが必要なくコピーで事足りる。 CopyトレイととDropトレイとは同居できない。 タプルのコピーはややこしそう 所有権と関数でまた、スタックに入れられるような変数と可変のオブジェクトの違いが出てくる。 takes_ownership(s: String)が参照を受け取れば問題なく、このあとも使える。 戻り値でもムーブが発生 参照と借用 借用 - 関数の引数に参照を取ること 可変な参照\u0026amp;mutは1つ(不変な参照も含めて1つ)しか許さない データの競合を防ぐため。 不変な参照を複数用いるのはOK 実際に変更が実行されるタイミングでエラーと判定される場合もある。 let mut s = String::from(\u0026#34;hello\u0026#34;); { let r1 = \u0026amp;mut s; } // r1はここでスコープを抜けるので、問題なく新しい参照を作ることができる let r2 = \u0026amp;mut s; ダングリング参照はテスト書くときとかにやってるかも。。。 fn dangle() -\u0026gt; \u0026amp;String { // dangleはStringへの参照を返す let s = String::from(\u0026#34;hello\u0026#34;); // sは新しいString \u0026amp;s // String sへの参照を返す } // ここで、sはスコープを抜け、ドロップされる。そのメモリは消される。 // 危険だ スライス型 部分的な参照。開始位置+長さで構成されているっぽい \u0026amp;strの説明がよくわからなかった。 引数としての文字列スライスのテクニックは色々と使いまわせそう。\nまとめ 所有権、これまで特に難しいと思ってたのは、固定長の変数と、可変長の変数の違いを意識してなかったのが原因っぽい。 まぁ、Vecとかがどうなるのかとか、他にもいくつか気になるところはあるので、もうちょっとやらないといけないなと思いました。\n","date":1585210331,"dir":"post/2020/","id":"7fded0345c258eea966c0b5ee1b7c7aa","lang":"ja","lastmod":1585210331,"permalink":"https://blog.johtani.info/blog/2020/03/26/chap4-rust-the-book/","publishdate":"2020-03-26T17:12:11+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた 第4章 第4章です。たぶん、これがいちばん大事な概念だと思","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第4章"},{"contents":"先日、Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)というブログを書きました。 このプラグインを作ってたタイミングで、Elasticの河村さん経由で、Microsoft Open Tech Night #9 w/ ElasticでなにかLTしませんか?という打診がありました。\n仕組み的には似たようなものだし、Elasticsearch用の拡張機能も作れるし、発表のネタにもなるし一石二鳥では?ということで、LTを快諾し、昨日発表してきました。\n資料とか 発表資料やGitHubのリポジトリなどは、以下のとおりです。\n発表資料 : Analyze APIのVS Codeプラグインを作ってみた GitHub Repository : https://github.com/johtani/vs-code-es-analyze-client Visual Studio Code Marketplaceページ 機能 まだ、必要最低限の機能を実装した感じです。\nAnalyze APIのパラメータ入力用のエディタ起動(Elasticsearch Analyze Client: Create Elasticsearch Analyze Request) Esにリクエストを送信して結果の表示 インストールからリクエスト送信して結果が出てくるまでのデモです。\n1点LTのデモのときに話すのを忘れていましたが、.esanalyzeという拡張子のファイルであれば、このプラグインが入力値を見つけ出して、「Analyze text with analyzers」というコマンド送信用のリンクをエディタ画面に表示する機能があります。 ですので、パラメータ入力用のエディタを起動し、値を設定したあとにファイルをhoge.esanalyzeというような名前で保存してもらえれば、後日そのファイルを開くことでリクエストが再送できます。\nAzure Search版との機能の違い 先日のAzure Search向けのクライアントとの違いがいくつかあります。 ElasticsearchのAnalyze APIの方が多機能であるため、プラグインとしても違いがあったほうがいいかなと。\n入力がJSON形式 結果画面に詳細表示切り替えボタンを追加 現時点では対応していませんが、Analyze APIはカスタムのtokenizer、filter、char_filterの設定を入力として受け付けることが可能です。そのときに指定するのはJSON形式でtokenizerなどの設定を記述します。 今後、これらの対応をすることを考えると、入力全体をJSON形式で読み込めるほうがわかりやすいかなということで、入力はJSON形式で入力してもらうことを想定しました。\n結果画面に詳細表示切り替えボタンを追加したのは、2つの理由があります。1つはAzure SearchのAnalyze APIよりもTokenの情報としていくつか他の情報も存在するためです。複数のAnalyzerとの比較をする場合は、単語列だけを比較したいですが、Analyzer個別の詳細情報を見たい場合もあるので、切り替えができたほうがよいかなと。 2つ目の理由はまだ実装していませんが、explainパラメータの出力への対応のためです。 explainパラメータを指定すると、カスタムAnalyzerの場合に、Analyzerの設定にあるchar_filter、tokenizer、token_filterのそれぞれのステップでの単語列の出力が結果として返ってきます。この結果には標準の出力よりもさらに多くのtokenの情報(例えば、kuromojiだと品詞情報、読み、原型など)が追加されてきます。これらの表示を切り替えることができたほうがよいかと。\nこれらは、実はKibanaのプラグインとしてすでに実装済みになっています。 同等の機能は実装できるかなという目論見もあり、そちらに合わせた感じにしてあります。\n今後の対応 現時点では、Analyzer名の指定のみが可能となっています。Kibanaのプラグインと同程度の機能はGitHubのIssueとして登録してみました。\nexplainパラメータ対応 fieldパラメータ対応 custom analyzer対応 その他に、インデックス名やアナライザ名の自動補完みたいな機能があると便利かも?と妄想していたりします(実装が大変かもですが。。。)。Kibanaのプラグインの場合は、Mappingやインデックス名を調べるときに、KibanaのConsoleからチェックすればよかったのですが、このプラグイン単体だとそのあたりの情報の取得に他のツール(Kibanaだったり、REST API Clientだったり)を使わないといけないという問題点はあるかなぁと。\nあとは、結果画面がこのままで本当に見やすいかどうか?なども気になってはいます。\nまとめ まだまだ、作ってみたというレベルのプラグインです。 どのくらいの人に使ってもらえるかもわかりませんが、こんな機能あるといい?など要望があればリクエストいただければと。 Twitterで聞いていただいてもいいですし、GitHubのIssueとして登録していただいても構いません。 そもそもいらないなぁなんて意見でももちろん大歓迎です。フィードバックお待ちしてます!\n","date":1585102205,"dir":"post/2020/","id":"a7f0e85fcad4f5bc5ae5c18c10de4f9e","lang":"ja","lastmod":1585102205,"permalink":"https://blog.johtani.info/blog/2020/03/25/vsc-es-analzye-plugin/","publishdate":"2020-03-25T11:10:05+09:00","summary":"先日、Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)というブログを書きました。 このプラグインを作ってたタイミン","tags":["elasticsearch","visual studio code"],"title":"ElasticsearchのAnalyze APIのVisual Studio Codeのクライアントプラグイン"},{"contents":"自転車本を読み始めましたが、その前にRust the bookを読んだほうが良いかも?と知り合いと話をしていてなったので、先にRust the bookを読み始めてます。 コツコツ読むってのが苦手なので、知り合いと小規模オンライン読書会しながら読むことになりました(基本的になにか書きながら、使い方を調べるので、存在そのものを知らない記述や使用法などがあったりする)。\n日本語版Rust the book Rust the book 基本は日本語版を読んでいます。まずは1章から3章あたり。\n気になった点などを。自分用のメモなので、読みやすさとかは考えてないです(あとで自分が死ぬパターン?)。\n1章 rustfmt便利。\nCLionのRustプラグインでは、保存時にrustfmtするというオプションがある。デフォルトはオフ。\u0026ldquo;Run rustfmt on Save\u0026rdquo; cargoの--binオプション。意識してつけたことなかった=デフォルトだった。\nライブラリにするときは--lib 2章 「変数を値に束縛」という言い回しにまだ慣れない。 「代入」という言い方に慣れているから? ただ、エラーにはassignってあるな。\u0026ldquo;error[E0384]: cannot assign twice to immutable variable x\u0026rdquo; preludeというのがデフォルトで読み込まれる型が存在する場所。 .expect()により、Resultが評価済みになる マクロがまだ慣れない extern crate rand;が最新版だと要らなくなっている。 rand::Rngはgen_rangeのためにuseしている。CLionだとかってにuseを推測して追加してくれた。 matchはswitch文みたいな感じ。けど、defaultが必ず実行されるって感じではないな。 ただし、全て網羅しないと怒られるのが便利。 アームという呼び方が新鮮 単一の式のときは{}が省略できる ブロック{}のときは、終わりにカンマを入力するとrustfmtが除去する(最後の条件かどうかは関係ない)。 シャドーイングは面白い。 よく、hoge_strやhoge_intのような変数を書くので、ありがたい。 ただし、コードを読むときに少し混乱しそう? let ... matchで変数への束縛でmatchが使えるのは便利(これまで知らなかったので、変数宣言して条件つけて束縛する処理書いてた)。 シャドーイング? fn main() { let x = 5; let x = x + 1; let x = x * 2; println!(\u0026#34;The value of x is: {}\u0026#34;, x); } とか\nlet spaces = \u0026#34; \u0026#34;; let spaces = spaces.len(); みたいに、同一変数名を使い回せること。再代入ではない\n3章 constは型注釈が必須 100_000のような記述が便利(Javaもできるって言われてびっくりしたw) タプルの中身を一部だけ書き換え可能。(mutを指定すれば) tup.0 = 20;のような感じで。 配列は固定長でかつ、同一の型のものだけが入る 文末にセミコロンがない場合に四季になるというのはちょっと射にくいので辛いのでは。。。 自分は明示的にreturnを書きたくなる。が、returnだと動かない場合もある。。。 let ... ifのような記述もできる。 (1..4)はRange型 おまけ フィボナッチ数列計算してみろというのがまとめにあったので。こんな感じでいいのかな?\nfn calc_fibonacci(n: usize) -\u0026gt; usize { if n == 0 { return 0; } else if n==1 { return 1; } else { return calc_fibonacci(n-1) + calc_fibonacci(n-2); } } その他 知り合いと読みすすめると、人が不思議に思ったところが、自分が理解が曖昧だったことなどに気づけて便利です。\n","date":1584928642,"dir":"post/2020/","id":"48b5ab9805919736382ffea5a9554c02","lang":"ja","lastmod":1584928642,"permalink":"https://blog.johtani.info/blog/2020/03/23/start-reading-rust-the-book/","publishdate":"2020-03-23T10:57:22+09:00","summary":"自転車本を読み始めましたが、その前にRust the bookを読んだほうが良いかも?と知り合いと話をしていてなったので、先にRust the bookを読","tags":["rust","読書","rust-the-book"],"title":"Rust the Bookを読み始めた"},{"contents":"動機 Azure Cognitive Searchを検索エンジンに使っているお客さんを手伝っています。 そこで、検索の基本的な話をさせていただきました(もともとJJUGナイトセミナーでしゃべる予定だったスライドがベース)。\nで、Elasticsearchなどの転置インデックスを利用している検索エンジンで検索の基本的な動作がどうなっているかを理解するのに、 個人的には一番重要だと思っているのがAnalysis(Analyze)の機能です。 転置インデックスの単語の切り出し方がどうなっているかによって、望んだ単語でうまく検索できているかいないかなどがわかります。\nAzure Cognitive SearchもAnalyze TextというAPIを提供してくれています(内部的にはElasticsearchだし)。 APIはあるのですが、返ってくる結果はJSONです。また、他のAnalyzerの設定との違いなどをみたくなったりもします。 やはり、普段使っているツールなどで簡単にどういう単語が出てくるかがわかるとうれしんじゃないかなぁ?と。\nということで、最初はPythonでちょっとAPI呼び出して、カンマ区切りで出力するものを作ってみたのですが、GUIとかあると便利かなぁという話になりました。 最近、ブログ書いたりするのにVisual Studio Codeを使い始めているので、これなら使いやすいかなと。 ということで、Visual Studio Codeの拡張機能(プラグイン?)としてインストールできるツールを作ってみました。 Azure Cognitive Searchを使っている人向けなので、ニッチなツールですが。。。\n余談 Elastic Stack(Elasticsearch)向けにはKibanaのプラグインでAnalyze APIを可視化するツールを作ってます。 analyze-api-ui-pluginです。Elastic Stack、特にKibanaを必ず利用する方はこちらを使うと便利かもです。\n概要と機能 GitHub リポジトリ Visual Studio Marketplaceのページ Marketplaceに公開しているので、johtaniやAzure Search Analyze Clientなどで検索してもらえれば出てきてインストールができます。\n機能としては、以下の2つです。\nテンプレートから入力値設定用のドキュメントを作成(Untitled-1というドキュメントをエディタに新しく開く) Azure Cognitive SearchのAnalyze Text APIを呼び出して、結果をHTMLのテーブル形式で表示 入力値設定用のドキュメント作成 APIの呼び出しに必要な情報を記入してもらうのに、いくつか案を考えました。\nプラグインの設定に記入してもらう 環境変数とかを読み出す テキストとして保存したファイルを使う 設定や環境変数だと、異なる環境に接続したりするときに、わざわざ設定し直すのがめんどくさいかもと。 で、愛用していたREST API Clientを真似するのが良いかもという結論になり、.analyzeという拡張子のファイルから必要な項目を読み出して、APIを呼び出す形にしてあります。\nCommand Palette(左下の歯車マークもしくは、メニューのViewから開ける)からAzure Search Analyze Client: Create Azure Search Analyze Requestというコマンドを選びます。\nすると、以下のようなファイルがエディタに開きます。\nこれらの項目をまずは埋めていきます。 それぞれの値がどういったものかはGitHubのREADMEを御覧ください。\n入力値エラー(存在チェックしかしていない)がある場合は、ダイアログが表示されます。\n結果表示 値を入力したら、設定値と###の間に表示されているAnalyze text with analyzersというグレーの文字をクリックします。すると、APIにリクエストを送信し、結果が返ってきて、別のパネルとして表示されます。\n複数のAnalyzerを入力値に設定すると、それぞれがどのような区切り方をするかがわかります。 文字の下にある[0:2]は、その単語がもとの文章の何文字目から何文字目までに出現しているかというオフセットの表示になります。\nもし、Analyzer名の設定ミスなどで指定されたAnalyzerがない場合は、結果画面にエラーが表示されるようにしています。\n以上が簡単な機能の説明です。 簡単なと言いつつ、これだけしか機能がありませんが。\nVisual Studio Codeのプラグインの作り方 プラグイン自体の作り方に関してはVisual Studio CodeのGetting Startedがわかりやすかったです。 APIや機能が豊富なので、最初はちょっと戸惑いましたが、サンプルもGitHubで多数公開されています。\nあとは、REST API Clientを参考にさせていただきました。\nGetting Startedを一通り読むことで、なんとなくプラグインの作成からMarketplaceへのリリースまでが完了できました。 (TypeScriptに慣れていないのがあるので、プログラミング自体は手間取りましたが。。。)\n今後の対応? いまのところ、こんなところを考えていますが、こんな機能がほしい、バグが有るなどあれば、GitHubにIssueを上げていただければと(使う人すくないだろうけど)。\nいろいろなエラーに関する対応 Readmeに画像をアップ アイコン作成? 自動補完機能? まとめ Visual Studio Codeの拡張機能を作ってみました。 Yeomanによるプロジェクトテンプレートが用意されているので、とりあえず、Hello worldを作るのは簡単でした。 試行錯誤しつつTypeScriptを書いたので、TypeScriptっぽくないところなどもあるかもですが、誰かの役に立つツールになってくれれば良いなぁと。\n","date":1584582615,"dir":"post/2020/","id":"c9d257aba54475c20b3737ce7c779e55","lang":"ja","lastmod":1584582615,"permalink":"https://blog.johtani.info/blog/2020/03/19/azure-search-analyze-plugin/","publishdate":"2020-03-19T10:50:15+09:00","summary":"動機 Azure Cognitive Searchを検索エンジンに使っているお客さんを手伝っています。 そこで、検索の基本的な話をさせていただきました(もともとJJUGナイ","tags":["azure search","visual studio code"],"title":"Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)"},{"contents":"これまで\n実践Rust入門はじめました 実践Rust入門の3章を読んでるところ 3章終了 3章の終わりまで読み終えた。\nいきなり実践的なプログラムで少し面食らっていたが、ステップを追って所有権周りの話まで来たので、 なんとなくRustのいいところが理解できたような気がする。\nただ、最後のsplit_at_mutが実際には内部でどういう形に変換することによって、コンパイルエラーにならずに、 借用がうまく行っているのかあたりは、まだきちんと理解できていない。\nこれは、どの言語にも言えるんだけど、リファレンスをうまく読み解きながら、 自分がやりたい処理ができるかどうかを考えるのって結構むずかしいなぁと思う。\nbenchmark.rsはコピペして実行しただけなので、またあとで読み返してみるかな。\nということで、ここから先は、基本を勉強する感じで4章から読みつつ、なんかプログラムをまた書いてみるか。\n","date":1583140813,"dir":"post/2020/","id":"6f47cb314fd780c122adb8cc1f44f785","lang":"ja","lastmod":1583140813,"permalink":"https://blog.johtani.info/blog/2020/03/02/finish-bicycle-book-chap3/","publishdate":"2020-03-02T18:20:13+09:00","summary":"これまで 実践Rust入門はじめました 実践Rust入門の3章を読んでるところ 3章終了 3章の終わりまで読み終えた。 いきなり実践的なプログラムで少","tags":["rust","読書"],"title":"実践Rust入門の3章を読み終わった"},{"contents":"Kuromoji-CLI Rust初心者がRust製の日本語形態素解析器の開発を引き継いでみたという記事にありますが、LinderaというRust製の日本語形態素解析が出てきました。KuromojiのRustクローンみたいなものです。 で、作者の人とのチャットの中で、「MeCabみたいなKuromojiのCLIないですかね？誰か知りませんか？」という話になりました。\n自分は普段はKuromojiの確認をするのは、Elasticsearch関連もしくは、Azure Searchなどだったりするので、 当たり前のようにKibanaを立ち上げたり、REST APIを叩いてましたが、たしかにコマンドラインインタフェースあると便利かも? と思い、作ってみるかということに。\npicocli いま、JavaでかんたんなCLI作るとなったら何がおすすめ？\n\u0026mdash; Jun Ohtani (@johtani) February 26, 2020 で、いつものツイートです。で、picocliという返信がありました。 JavaでCLIのプログラムを書くのが簡単になりそうだと。 ドキュメントもしっかりしてます。サンプルも載ってるし。\nAnnotationで、コマンドの説明などパラメータ、オプションなどが記述でき、必須チェックなども可能です。\nまた、オプションの説明文に関しては、テンプレートを用いることで、取りうる値をEnumの値で出力してくれたりといった便利機能まで備わっていました。\nGraalVM また、GRAALVMとPICOCLIでJAVAのネイティブコマンドラインアプリを作ろうというスライドも教えてもらい、ネイティブコマンドまで作れるらしいと。 なんて便利なんでしょう!ってことで、こちらもチャレンジしてみました。 GraalVMがどんなものかはなんとなくは知ってたのですが、何者だろう?とツイートしたところ、これまた返信が。\nっ 資料はかなり古いので現行版と乖離はあるけど概念は変わってないので..https://t.co/KRQjhNdD9f\n\u0026mdash; たむたむ🏫 (@tamtam180) February 26, 2020 本当に、Twitter便利ですね。\nGraalVMがどんなものかもいただいた資料でサクッと理解できました。 ただ、picocliが実はものすごく良くできており、自分でインストールする必要も実はありませんでした。\ngradle-graalというGradleのプラグインと、 Picocli Code Generationを利用することで、 以下のコマンドを実行することで、ネイティブコマンドアプリが作成できました。\ngradle nativeImage build.gradleファイルに記述したのは、以下のような項目です。\npluginの利用 picocli-codegenをannotationProcessorとして呼び出し jarに関する記述(メインクラスと依存するJarを含める設定) ネイティブコマンドの名前とか(gradle-graalの設定) 辞書が読み込めなかった で、native imageを作って実行しましたが、Kuromojiが内包している辞書ファイルが読み込めませんでした。 どうやら、picocli-codegenの自動生成では対応できない、リソース関連設定が必要らしいと。\npicocli-godegenの設定を見ていて見つけたのが、other.resource.patternsというオプションでした。\nkuromoji-cliのbuild.gradleに、その設定を加えたら辞書が読み込めるようになりました。\nこの設定をどうやって書くのか?というのを探すのにちょっと時間がかかりました。Picocli作者のRemko Popmaさんのサンプルリポジトリに設定を利用したbuild.gradleがありました。サンプル本当にありがたいですね。\n完成 出来上がったのは、kuromoji-cliというリポジトリになります。 内部で利用しているのはAtilikaのKuromojiです。LuceneのKuromojiではないのでご注意を(LuceneのKuromojiで最初やってみたのですが、リフレクションなどが多用されてて、Single Imageにするのが手間がかかりそうだった)。 コマンドのポータビリティはそれほど無いと理解してる(あってる?)ので、利用してみたい方は、リポジトリをクローンしてからビルドしてみてください。\n参考資料 kuromoji Picocliドキュメント Getting Started GraalVM / GraalVM超入門 一体何モノなの? GraalVM入門編 / GraalVM for beginners まだ途中? ほかにもあると便利かも?という機能があればIssueやPRを上げてください。 とりあえず、頭にあるのは以下のとおりです。\nJSONの出力はまだ未対応 いろんな辞書をAtilikaのKuromojiはサポートしてるのでそのへんも対応してみる? ","date":1582858179,"dir":"post/2020/","id":"d710a073be2da219a388a150eb7b6b6a","lang":"ja","lastmod":1582858179,"permalink":"https://blog.johtani.info/blog/2020/02/28/kuromoji-cli/","publishdate":"2020-02-28T11:49:39+09:00","summary":"Kuromoji-CLI Rust初心者がRust製の日本語形態素解析器の開発を引き継いでみたという記事にありますが、LinderaというRust製の日本語形態素解","tags":["misc"],"title":"KuromojiのCLIコマンドとpicocliとGraalVM"},{"contents":"これまでのはこちら。読書メモなので、本と合わせて読んでいただくのが良いです。\n実践Rust入門はじめました 3章のクイックツアーを読んでます。 バイトニックソート自体の理解はちょっとおいておいて、読み進めています。 いくつか疑問に思ったことがあったので、またメモを。 まだ、3.5.7の手前ですが。\n疑問点 3.4.1のジェネリクス対応のテストケースの部分で、既存のu32用のテストケースの入力のデータ列にVec\u0026lt;u32\u0026gt;という型注釈をつけるのですが、 追加した文字列の入力データには注釈をここではつけないのはなんでなんだろう?ちなみに、なくても動いた。バージョンの違いとかあるのかしら?\n3.4.6のmatch文\nmatch文の引数?が*orderになっていたが、orderでも実行できた。引数にくるのが参照だから*が付いてるんだとも運だが、なくても動くのはコンパイラがよしなに解釈してくれてるからかな? 便利なツール Rust標準のツールの説明がいくつか3章で紹介されてて便利だったのでメモ。\nrustfmt フォーマッター。デフォルトでフォーマット機能が付いてるの便利ですね。言語として決まってると、プロジェクトごとに悩まなくていいってのがありますし。\nrustfmt ファイル名 という形で使えるみたい。 プロジェクトごとだとcargo fmtのほうが楽そうかな。\n標準ライブラリAPIドキュメントをブラウザで閲覧 rustup doc --std これでデフォルトブラウザでRustの公式ドキュメントが開きます。 しかもローカルファイルだからサクサク。検索バーもついてて便利です。\nエラーのドキュメントを閲覧 rustc --explain 308 コンパイル時にエラーが出たときに、error[E0308]のようにコンソールに出てきます。 ヒントも出てくるのですが、詳細が上記のコマンドで読めるみたいです。\n","date":1582443437,"dir":"post/2020/","id":"71cf83ae0f45e9ede3a3f979b9c74933","lang":"ja","lastmod":1582443437,"permalink":"https://blog.johtani.info/blog/2020/02/23/bicycle-book-chap3/","publishdate":"2020-02-23T16:37:17+09:00","summary":"これまでのはこちら。読書メモなので、本と合わせて読んでいただくのが良いです。 実践Rust入門はじめました 3章のクイックツアーを読んでます。 バ","tags":["rust","読書"],"title":"実践Rust入門の3章を読んでるところ"},{"contents":"もう2020年2月になってしまってますが、2019年に買って便利だったもの良かったものをいくつか記録に残しとこうかなと。\nBRAVIA KJ-55X9500G Amazon | ソニー SONY 49V型 液晶 テレビ ブラビア 4Kチューナー内蔵 テレビをやっと買い替えました。 前に使っていたのはプラズマディスプレイで、10年以上たったもので、パネルの一部が赤い残像が残ってたりしました。 もう流石にいいでしょうということで、買い替えたのがSonyのテレビです。 4Kのチューナーもついているし、アップコンバーターもついているので普通の地上波でもきれいです。 まぁ、10年前のテレビに比べればたくさんいいことがありますよねw\n新しいTV買って一番活躍してるのはYouTubeボタンだったりします。 最近はミュージックビデオがYouTubeにたくさんあるので、King Gnuなどの音楽流したりするのに便利です(テレビなのに)。 今は、プライムビデオボタンがより活用される感じになってきてます(テレビなのにw)。\nSodastream Amazon｜スピリット ワンタッチ ホワイト スターターキット ここ数年、炭酸を普段飲んでます。甘いもの飲まないようにって意味でも。。。 で、これを買うまでは、サントリーの天然水スパークリングレモンとかを、箱買いしてました。 が、まぁ、ペットボトルのゴミが半端ないんですよ。場所も取るし。\nソーダストリームのことは知ってたのですが、自分で炭酸の量を考えながら、入れないといけないので避けていました。\nが、今回購入したものは、水の入ったボトルを指して、ボタン一つで3段階の炭酸を入れることができるんです!買って本当に重宝してます。うちでは1Lのボトルを1本追加して、2本で運用してます。 家族はなっちゃんのオレンジとかを炭酸割りしたり、カルピスソーダ作ったりして楽しんでます。 ワンタッチということで、簡単に入れられるので家族も重宝してます。\nNature Remo + Chromecast Amazon | Nature スマートリモコン Nature Remo mini Remo-2W1 Google Home miniがキャンペーンで手に入ったので、ベッドルームの照明やクーラーの操作もできそうなのでNature Remoを導入しました。 Chromecastは余っている液晶モニターにつないで、スマホからキャストできるようにしたり、音楽聞けるようにしてあります。\nNature Remoは温度計などもついているので、部屋の温度に合わせてエアコンのオンオフなども可能で、 暑い夏にとても便利でした。寝る時間にはクーラーが入っているのですんなり寝れたりと。 スマホから電源オンオフできるのも便利ですね。 Chromecastはモニターにつなぎましたが、今は、Google Music Playのプレーヤーになってます。 (最近、家にあるCDを読み込んでGoogle Play Musicにアップしてる)。\nただ、それ以上のことには使えてないので、もうちょっと面白いことしてみないとなぁ。\nモニターアーム Amazon | HUANUO PC モニター アーム 液晶ディスプレイ アーム ガススプリング式 Amazon | グリーンハウス 液晶ディスプレイアーム 4軸 クランプ式 ディスプレイがふるくなってたので、4Kディスプレイに買い替えた(27インチで4万切るとかで安い。。。)んですが、Mac Book Pro 15インチ(今は16インチ)を使っていて、Macの画面がディスプレイにかぶるので モニターアームを買いました。 1つ目がガススプリング式のアームです。なのに、5000円を切ってるんですよ。おそるべし。 2つ目はクランプ式です。アームにしたものの特に動かすことはなく、高さを出したいだけってことがあるので、クランプ式のも使ってます(家ではディスプレイ2枚使ってる)。 コスパ最高です。\nAnker PowerCore 10000 PD Amazon | Anker PowerCore 10000 PD（10000mAh PD対応最小最軽量 大容量 モバイルバッテリー） Pixel 3にしてから、電池の持ちはよくはなってるんですが、もしもの時のためにモバイルバッテリーは話せないですよね。 PD対応なので、Pixel 3に急速充電ができるし、サイズもそれほどじゃまにならないサイズなので便利です。USB-Aもついているので、このあと紹介するイヤホンの充電ケーブルなんかも差し込めて大活躍です。\nサウンドピーツのイヤホン Amazon | SOUNDPEATS(サウンドピーツ) Q35HD ワイヤレス イヤホン 高音質・低遅延 IPX8防水 私が持ってるのはこの前のバージョンで、micro-USBで充電充電するタイプですが、こちらもコスパ最高です。 冬は防寒も兼ねてヘッドフォンをしているのですが、春から秋にかけてはこれまで、優先のイヤホンを使ってました。もしくは、Bluetoothのレシーバーに優先のイヤホンつけてました。電池切れたら、イヤホンさして使う感じで。 が、Pixel 3はイヤホンジャックがありません。ということで、ワイヤレスイヤホンに移行するかということで選んだのがこちらです。 世の中的には、完全ワイヤレスイヤホンが流行っていますが、片方無くなってしまうイメージしかわかなくて。。。 これが壊れても、完全ワイヤレスではなくつながったワイヤレスイヤホンを使うと思います。\nヘッドルーペ Amazon | Tumao ヘッドルーペ ルーペ メガネ LED付拡大鏡 眼鏡の上装着 メガネゴムバンド両用 5レンズ交換調節 プラモデルをちょいちょい作るんですが、もう年ですね。。。細かいところが見にくくて。 ガンダムのRG系のプラモデルだと、1/144なんですよ。小さいんですよ。見えないんですよ。。。\n完成しましたー！ pic.twitter.com/S9QTS4kJDI\n\u0026mdash; Jun Ohtani (@johtani) February 16, 2020 ということで、ヘッドルーペ導入してみました。 最初は、卓上に置けるルーペにしてみたんですが、自分がルーペがあるところに動かないといけないの結構つらくて。 これのおかげで、プラモデル作成に問題はなくなりました。老眼とは関係なく、ちょっと猫背になっちゃうのが今は悩みの種ですが。。。こたつで作ってるからなぁ。\nまとめ ということで、いくつかよかったものを紹介してみました。 今年はちゃんと年末に書こう。。。\n","date":1582272302,"dir":"post/2020/","id":"daa3fe935b0be9f31b6b362ad9e0d2d6","lang":"ja","lastmod":1582272302,"permalink":"https://blog.johtani.info/blog/2020/02/21/best-buy-2019/","publishdate":"2020-02-21T17:05:02+09:00","summary":"もう2020年2月になってしまってますが、2019年に買って便利だったもの良かったものをいくつか記録に残しとこうかなと。 BRAVIA KJ-55X9500G Amazon | ソニー SONY 49","tags":["買い物"],"title":"2019年に買ってよかったもの"},{"contents":"ブログ移行日記(その5)です。前回まではこちら\nブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4) 今回はこれまでとは異なる特殊な話です。\n最初にブログを書き始めたときに利用していたのがJugemのブログでした。 その後、Octopressに移行して、今年、Hugoに移行したという流れです。\nで、よくよく考えると、Jugemのブログも移行できるんじゃないか?となりました。 じゃあ、やってみるかと。なので、今回のブログは自分の備忘録です(興味のない人が大多数じゃないかな)。 一応、Pythonで書いたプログラムはGitHubに上がっています。文字列置換と正規表現のオンパレードです。\nJugemからExport まずは、移行元のデータが取り出せるかどうかを調べたところ、text形式もしくはXML形式でエクスポートが可能でした。\n変換処理が必要なはずなので、XMLでダウンロードします。 独自のXMLですが、記事ごとにXMLのタグ(\u0026lt;entry\u0026gt;)でまとめられているので、処理が楽です。\nXMLをMarkdownに \u0026lt;entry\u0026gt;タグの下に次のような項目が入っているので、抜き出します。\nヘッダ部 title - 記事タイトル author - 著者 category - タグ date - 投稿日付 description : 本文(先頭部分) sequel : 本文(つづき) titleからdateまでをHugoのMarkdownのヘッダ部分として出力します。 日付は形式が違うので合わせるように変換し、 titleは(Jugemより移植)という文字列を追加しました。\nまた、Hugoの個別のコンテンツにするためにそれぞれをMarkdownのファイルに変換しています。 ファイル名は変換後のdateの先頭10文字(yyyy-MM-dd)に-を付け加えて、 タイトルを追加しました。ホントは英語のファイル名にしたかったんですが、ちょっと手抜き。ファイル名に使用できないような文字は-に置換しています。\n本文 本文部分はもう少し複雑です。 まずは、descriptionとsequelから抜き出した文字列を結合します。\nで、内部の文字列に次のようなものがあるので、それぞれMarkdownに変換したりという処理を書いてます。\nHTMLのheadingタグをMarkdown形式に br、hr、del、strongなどのタグもMarkdown形式に aタグの処理 Amazonのアフィリエイトタグの処理 ul、olタグの処理 などです。 アフィリエイトタグは、数行に渡るの複数のHTMLタグで記述されているので、 ASINと商品タイトルだけを抜き出しています。 Hugoでアフィリエイトのリンクを作るために、hugo-amazon-jpという公開されているshortcodeを元に、カスタマイズしたものを使っています。 これ用に、必要なASINとタイトルを別ファイルに出力したりしています。\nまた、いくつか画像を使っている記事があったのですが、これが曲者でした。 XMLに入っているimgタグに画像へのURLがあるのですが、アクセスしても存在しないURL担っています。。。 ブログで公開している画像のファイル名に似たものがXMLに入っていたので、URLを組み直して、ダウンロードするという処理も書いています。\nあとは、昔ちょっと凝った書き方(spanタグで章みたいなことやってた)をしていた部分の処理を加えて完成です。\nまとめ 元のXMLを見たり、抜き出したファイルを見ながら、トライアンドエラーでプログラムを書きました。 なんとなく変換できたなかっていうところで、取り込んで公開しました。 まだ、全部の記事をチェックしてないですが、なんとなく移植できたので一旦これでいいかなと。 昔の記事を見たときにおかしい場所があったら手で治すつもりでいます。\nなんか、もうちょっとうまくプログラムかけた気もしますが、書き捨てのプログラムだと思うのでこんなもんかな。\n1点気になっているところは、コメントの部分です。 ブログにコメントをいただいていたのですが、その部分は移植できてないです。\nOctopresに移植していこうは、Disqusのサービスでコメント部分を提供しています。ここに移植するのも変な話だなぁと思っているので、本文にコメントを取り込む感じかなぁ？\nもともとのJugemのサイトもそのまままだ残してあるので、そのうち気が向いたらで。\n","date":1582254240,"dir":"post/2020/","id":"ef8a399c9679ce4e9710c7c6ecf8bcc7","lang":"ja","lastmod":1582254240,"permalink":"https://blog.johtani.info/blog/2020/02/21/import-jugem-posts/","publishdate":"2020-02-21T12:04:00+09:00","summary":"ブログ移行日記(その5)です。前回まではこちら ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4","tags":["hugo","ブログ"],"title":"ブログ移行日記(その5) - Jugemのブログを移行"},{"contents":"お手伝いしているお客さんがAzure Cognitive Searchを利用してます。 検索周り=Azure Cognitive Searchに関する手伝いをする形で入っており、 いくつか触った感触をブログにまとめてみようかと(お客さんからはOKいただいてます)。\nAzure Cognitive Searchとは？ 公式サイト 「AIを活用した」クラウド検索サービスと紹介されています。\n昔はAzure Searchと呼ばれていましたが、ここ最近はAzure Cognitive Searchと呼ばれているみたいです(Microsoft Igniteで発表された話がまとまっているページもあります)。 もともと、検索エンジンのSaaSサービス(キーワード検索、あいまい検索、オートサジェスト、スコアリングなどの機能)として作られていた部分に、データの登録パイプラインにCognitive Serviceの便利な機能を簡単に使えるようにしたものというイメージでしょうか。\nバックエンドはElasticsearchのはずです。変わってなければ。 昔、Elastic社主催のユーザーカンファレンスでMSの方が公演された資料が公開されていたりします。 ちなみに質問が多いのでしょうか、Azure Cognitive SearchとElasticsearchの違いはなんですか?というページがよくある質問のページに用意されていました。参考までに。\n今回はちょっとしたインデックスをつくって検索する部分を紹介してみようかと思います (Cognitiveなところは機会があればまた)。\n普通の使い方については、Azureのドキュメントなどを読んで頂く形にします。 ポータルと呼ばれるブラウザ上でAzureのサービスを触ることができる画面が用意されています。 ここで、簡単な操作(インデックス作成、フィールドの追加)\nAPIを使ってインデックス(特にAnalyzer)の設定をしたり、データをいれて、クエリしてみるというところをサクッと紹介しようと思います。\nインデックスの作り方 インデックス作成に関するドキュメントも用意されています。最初はポータル(GUI)でインデックスを作成する方法が紹介されています。 ですが、今回はn-gram(n=2)のAnalyzerを利用したかったので、GUIではなくAPIでインデックスを作成しました。 カスタムアナライザーを利用する場合、REST APIを利用しなければ行けないということになっています。 n-gramのAnalyzerを含むインデックス生成のREST APIは以下のとおりです。こちらを実行することで、インデックスが作成されます(JSONの記述ミスなどがある場合はエラーが返ってきます)。\n@host = \u0026lt;サーチのサービス名\u0026gt;.search.windows.net @api-key = \u0026lt;APIキー\u0026gt; ### POST https://{{host}}/indexes/?api-version=2019-05-06 Content-Type: application/json api-key: {{api-key}} { \u0026#34;name\u0026#34;:\u0026#34;ngram-test\u0026#34;, \u0026#34;fields\u0026#34;:[ { \u0026#34;name\u0026#34;:\u0026#34;id\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;Edm.String\u0026#34;, \u0026#34;key\u0026#34;:true, \u0026#34;searchable\u0026#34;:false }, { \u0026#34;name\u0026#34;:\u0026#34;ngram\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;Edm.String\u0026#34;, \u0026#34;searchable\u0026#34;:true, \u0026#34;analyzer\u0026#34;:\u0026#34;bi_gram_analyzer\u0026#34; } ], \u0026#34;analyzers\u0026#34;:[ { \u0026#34;name\u0026#34;:\u0026#34;bi_gram_analyzer\u0026#34;, \u0026#34;@odata.type\u0026#34;:\u0026#34;#Microsoft.Azure.Search.CustomAnalyzer\u0026#34;, \u0026#34;tokenizer\u0026#34;:\u0026#34;bi_gram_tokenizer\u0026#34;, \u0026#34;tokenFilters\u0026#34;:[ \u0026#34;lowercase\u0026#34; ] } ], \u0026#34;tokenizers\u0026#34;:[ { \u0026#34;name\u0026#34;:\u0026#34;bi_gram_tokenizer\u0026#34;, \u0026#34;@odata.type\u0026#34;:\u0026#34;#Microsoft.Azure.Search.NGramTokenizer\u0026#34;, \u0026#34;minGram\u0026#34;:2, \u0026#34;maxGram\u0026#34;:2 } ] } なんだかどこかで見たことのある記述のようなそうでないような。。。 Analyzerは、charFilters(0以上複数可)、tokenizer(1つ必須)、tokenFilters(0以上複数可)から構成されます。 フィールドで指定するのはAnalyzerなので、まずanalyzersにCustomAnalyzerの設定を行います。 名前はbi_gram_analyzerにしました(好きに付けてください)。 tokenizerにはこのあと設定するtokenizerの名前を設定します。ここでは、bi_gram_tokenizerという名前にしています。 また、大文字小文字を気にせずに検索したいため、tokenFiltersにlowercaseを指定しています。こちらはすでに定義済みのため、定義済みの名前で呼び出すだけで使用できます。\n次が、bi_gram_tokenizerの設定です。 n=2としたいので、tokenizers配下にTokenizerの設定をします。 @odata.type\u0026quot;:\u0026quot;#Microsoft.Azure.Search.NGramTokenizerがTokenizerの名前です(ちょっと独特な名前ですね)。 Tokenizerごとにオプションがあり、NGramTokenizerの場合は、minGram、maxGramがオプションに相当します。 今回は2文字ごとにトークンを出力したいので、minとmaxをそれぞれ2としています。\nこれで、あとは、フィールドでanalyzerという設定にbi_gram_analyzerを指定すればそのフィールドはbi_gram_analyzerを使用してアナライズされるようになります(このへんはElasticsearchといっしょですね)。 フィールドは文字列を扱うので、Edm.Stringというタイプにしてあります。データ型については、フィールドコレクションとフィールド属性というドキュメントを参考に設定しましょう。\n閑話休題 - REST Client Exstension for Visual Studio Code なお、今回のサンプルはREST Clinet Extention for Visual Studio Codeを利用する想定の記述になっています。\nVisual Studio Codeで.restもしくは.httpというファイルに以下のAPIを記述すると、Send RequestというリンクがURLの上部に出てくるような拡張機能です。REST APIにリクエストするときに便利なツールになっています。 変数も使えるので、APIのキーやURLの一部をこのように共通化して、他の環境でも使いやすくできるのは素晴らしいなと。\nアナライザーの挙動の確認 設定したAnalyzerがきちんと機能しているかというのを確認する必要があります。 入力した文字列がきちんと想定している単語として切り出されて、転置インデックスの見出し語に使われるかというのが重要になるからです。\nAzure Cognitive Searchでもアナライザーのテスト用APIが用意されています。 使い方はこちら。 APIの仕様のページもありました。 「アナライザーの挙動はどんな感じ？」という文字列が、作成したインデックスの定義したアナライザーbi_gram_analyzerにより、 どのように分割されるかを確認するAPIの呼び出しは以下のとおりです。\n### POST https://{{host}}/indexes/ngram-test/analyze?api-version=2019-05-06 Content-Type: application/json api-key: {{api-key}} { \u0026#34;analyzer\u0026#34;:\u0026#34;bi_gram_analyzer\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;アナライザーの挙動はどんな感じ？\u0026#34; } レスポンスはこんな形です。ヘッダ部分は省略してあります。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;https://{{host}}.search.windows.net/$metadata#Microsoft.Azure.Search.V2019_05_06.AnalyzeResult\u0026#34;, \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;アナ\u0026#34;, \u0026#34;startOffset\u0026#34;: 0, \u0026#34;endOffset\u0026#34;: 2, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;ナラ\u0026#34;, \u0026#34;startOffset\u0026#34;: 1, \u0026#34;endOffset\u0026#34;: 3, \u0026#34;position\u0026#34;: 1 }, { \u0026#34;token\u0026#34;: \u0026#34;ライ\u0026#34;, \u0026#34;startOffset\u0026#34;: 2, \u0026#34;endOffset\u0026#34;: 4, \u0026#34;position\u0026#34;: 2 }, { \u0026#34;token\u0026#34;: \u0026#34;イザ\u0026#34;, \u0026#34;startOffset\u0026#34;: 3, \u0026#34;endOffset\u0026#34;: 5, \u0026#34;position\u0026#34;: 3 }, { \u0026#34;token\u0026#34;: \u0026#34;ザー\u0026#34;, \u0026#34;startOffset\u0026#34;: 4, \u0026#34;endOffset\u0026#34;: 6, \u0026#34;position\u0026#34;: 4 }, { \u0026#34;token\u0026#34;: \u0026#34;ーの\u0026#34;, \u0026#34;startOffset\u0026#34;: 5, \u0026#34;endOffset\u0026#34;: 7, \u0026#34;position\u0026#34;: 5 }, { \u0026#34;token\u0026#34;: \u0026#34;の挙\u0026#34;, \u0026#34;startOffset\u0026#34;: 6, \u0026#34;endOffset\u0026#34;: 8, \u0026#34;position\u0026#34;: 6 }, { \u0026#34;token\u0026#34;: \u0026#34;挙動\u0026#34;, \u0026#34;startOffset\u0026#34;: 7, \u0026#34;endOffset\u0026#34;: 9, \u0026#34;position\u0026#34;: 7 }, { \u0026#34;token\u0026#34;: \u0026#34;動は\u0026#34;, \u0026#34;startOffset\u0026#34;: 8, \u0026#34;endOffset\u0026#34;: 10, \u0026#34;position\u0026#34;: 8 }, { \u0026#34;token\u0026#34;: \u0026#34;はど\u0026#34;, \u0026#34;startOffset\u0026#34;: 9, \u0026#34;endOffset\u0026#34;: 11, \u0026#34;position\u0026#34;: 9 }, { \u0026#34;token\u0026#34;: \u0026#34;どん\u0026#34;, \u0026#34;startOffset\u0026#34;: 10, \u0026#34;endOffset\u0026#34;: 12, \u0026#34;position\u0026#34;: 10 }, { \u0026#34;token\u0026#34;: \u0026#34;んな\u0026#34;, \u0026#34;startOffset\u0026#34;: 11, \u0026#34;endOffset\u0026#34;: 13, \u0026#34;position\u0026#34;: 11 }, { \u0026#34;token\u0026#34;: \u0026#34;な感\u0026#34;, \u0026#34;startOffset\u0026#34;: 12, \u0026#34;endOffset\u0026#34;: 14, \u0026#34;position\u0026#34;: 12 }, { \u0026#34;token\u0026#34;: \u0026#34;感じ\u0026#34;, \u0026#34;startOffset\u0026#34;: 13, \u0026#34;endOffset\u0026#34;: 15, \u0026#34;position\u0026#34;: 13 }, { \u0026#34;token\u0026#34;: \u0026#34;じ？\u0026#34;, \u0026#34;startOffset\u0026#34;: 14, \u0026#34;endOffset\u0026#34;: 16, \u0026#34;position\u0026#34;: 14 } ] } このAzure SearchのAnalyze API、使用できるオプションはすくないですが、ElasticsearchのAnalyze APIと似ています。\nデータの登録の仕方 データ登録もAPIからできます(あたりまえですね)。 APIは1件ずつではなく、バルクで登録できる形で提供されています。\nサンプルとしては、以下のような形です。 @search.actionの部分(searchがあるとわかりにくい気がするけど。。。)が、ドキュメントの登録、更新、削除の命令を書き込むところになります。 今回は単純に登録するだけなので、uploadを指定しました。 ほかにもいくつかアクションが用意されています。用途に合わせて指定する感じになります。 id、ngramはそれぞれフィールド名です。ドキュメントに登録したい値を記述します。\nPOST https://{{host}}/indexes/ngram-test/docs/index?api-version=2019-05-06 Content-Type: application/json api-key: {{api-key}} { \u0026#34;value\u0026#34;: [ { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;ngram\u0026#34;: \u0026#34;新しいAzure Searchの使い方\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;ngram\u0026#34;: \u0026#34;Elasticsearchの紹介\u0026#34; } ] } 検索クエリ 最後は検索クエリです。 検索クエリはいくつかのオプションがあります。 ざっくりだと、queryTypeがsimpleとfullという2種類が用意されており、ちょっとした検索を作る場合はsimpleで事足りそうという感じです。 入力された単語(スペース区切りで複数扱い)をフィールド(複数可)に対していずれかの単語を含むもしくは、すべての単語を含むという検索に行くというパターンですね。 このときの、「いずれか」か「すべて」の設定がsearchModeというパラメータになります。 anyの場合、Googleの検索と同様に、どれかの単語が入っているドキュメントが対象に、allの場合すべての単語が含まれるドキュメントだけがたいしょうになるといった形です。\nqueryType=fullの場合はLuceneの構文でクエリがかけます。ElasticsearchのQuery String Queryみたいな形です。\n簡単なサンプルは次のような感じです。このサンプル\nPOST https://{{host}}/indexes/multi-field-test/docs/search?api-version=2019-05-06 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#39;ngram:\u0026#34;使い方\u0026#34; ngram:\u0026#34;紹介\u0026#34;\u0026#39;, \u0026#34;queryType\u0026#34;: \u0026#34;full\u0026#34;, \u0026#34;searchMode\u0026#34;: \u0026#34;any\u0026#34; } すこしだけクエリの補足を。 searchに入力された単語をダブルクォートで囲んでいます。これは、「使い方」という文字がbi_gram_analyzerにより「使い」「い方」に 分割されるのですが、必ずこの順序で出現したものだけを検索対象にしたい(フレーズ検索)という意味になります(*bi_*gramなので、「紹介」に関してはダブルクォートは厳密には必要ないです)。\nあと、レスポンスは今回記載していませんが、@search.scoreという項目で、スコアが返ってきます。 デフォルトのスコア計算には何を使ってるんだろう?ドキュメントにはTF-IDFとの記述があるのですが。。。カスタマイズもできそうです。\n少しオモシロイと思ったのは、スキーマ(インデックスの設定)に定義されているが、ドキュメントとしては登録していない項目についても、 Azure Cognitive Searchはドキュメントのフィールドがnullという形で返ってくるようでした。 そもそもフィールドが存在しないドキュメントとフィールドの値がnullのものの違いは無いようです。\n簡単ですが、インデックスの設定、ドキュメントの登録、検索の方法の紹介でした。\nちょっと触った感想 一番売りである、Cognitiveの部分はまだ触っていないです、すみません(こっちが売りな気もするんですが)。 検索エンジンの部分としては、Elasticsearchを知っていると、「あー、そんな感じね」という気持ちになれるサービスです。 個々のAPIやデータの形式は異なるので、きちんとAPIのリファレンスなどを確認しつつという形になりますが、なんとなくこういうAPIなどがありそうだな?と予測しつつ使えるかなと。 内部的にはElasticsearchだと思いますが、独自のAPIでラップされているおかげで、バージョンの違いなどを意識せずに使えるのではないかと思います。\nまた、今回は紹介していませんが、マイクロソフト独自の各言語のアナライザー(日本語も含む)があります。 Luceneのアナライザーとマイクロソフトのアナライザーのどちらも利用できますので、ここの違いを見てみるのも面白そうだなと思いました。 緯度経度を利用した検索、フィルター検索(スコア計算対象にならない)、ファセット、スコア調整の機能なども備えているようです。\nなんにせよ、利用する場合やドキュメントを読む場合に、全文検索の仕組みをなんとなく知っておいたほうが読みやすいんじゃないかなというのが感想です。\nここ数年はElasticsearchがメインでほかはほぼ触っていない状況だったので新しい製品に触れるのは面白いですね。 時間があったら、アナライザーの違いなども調べてみたいなと思います。\n","date":1582080481,"dir":"post/2020/","id":"c3053579ae25e2fb9b967076a06373af","lang":"ja","lastmod":1582080481,"permalink":"https://blog.johtani.info/blog/2020/02/19/research-azure-cognitive-search/","publishdate":"2020-02-19T11:48:01+09:00","summary":"お手伝いしているお客さんがAzure Cognitive Searchを利用してます。 検索周り=Azure Cognitive Searchに関する手伝いをする形で入っており、 いく","tags":["azure search"],"title":"Azure Cognitive Searchでインデックスを作って検索"},{"contents":"また、ツイートから始まるお話です。 まだまだ、検索システムってどんなものかを勉強したいしということで、こんなのをツイートしてました。\n「検索システム探訪」みたいな名前がいいかな? https://t.co/sG7BDdGI9h\n\u0026mdash; Jun Ohtani (@johtani) February 6, 2020 検索について知り合いとお茶をしながら話をしていて、こういう話を聞くの面白いなぁと思ったので。 どんなことを個人的には聞きたいかな?というのをまとめといたほうがいいかと思いブログを書いています。 こんなことも面白そうだよね?\nどんなこと聞きたいかな? いまのところ思いついた内容はこんな感じかな? こんなのも聞くと面白そうだよね?などありましたら、コメント欄に書いてもらえればと。\n利用しているシステム・サービスは? 構成やどこのサービスなのか？ 検索ユーザーはどんな人？ ユーザーの種類 ユーザーの検索ニーズ 検索対象データはどんなもの？ データ件数はどのくらい？ 属性、項目がどのくらいあるか？ 検索結果として出したいものは？ ソートはどんなものがあるの？ ランキングで重要なものは？ UI/UXはどんな感じ? ハイライト、ソート、ファセット(Aggs) キーワードサジェスト、オートコンプリート 検索システムの監視(オブザバビリティ??) ビジネス的な指標 クエリログ、クリック(ユーザーに関する情報) システムメトリクス 困っていることは？ ランキング クエリ 検索システム分析 第1回やりました。 ちなみに、最初のツイートに対して、すぐに返事をくれた方がいました。\nうちでよければご説明します！\n\u0026mdash; Kizashi （令和もRailsエンジニア募集中） (@kizashi1122) February 6, 2020 Twitter本当にありがとうございますという感じです。\nで、早速話を聞かせていただきました。大阪の方だったので、テレカンでやらせていただきました。 移動時間とか気にせずにできるので、テレカン形式いいですよね。\n内容は、非常に面白かったです。 使ってるシステムについて、どんなところで、どのようなように検索エンジンをつかっているのか、 どんなことで困っているのかなどをお聞きすることができました。\n2020/02/13 追記 対応していただいたIngageの永田さんから、内容を公開しても良いという承諾をいただいたので、メモを公開します。\nサービス : Re:lation 問い合わせメールなどのチームで対応する対応 利用している検索エンジン Elasticsearch (AWS Es) ノード数 8 - 3 master + 5 data データ データ数 : 約1億5千万 親子関係 : チケット - メール(=1ドキュメント) - コメント 画面としてはチケットの一覧=aggsでチケットIDの一覧を生成してリスト表示 インデックス数 : 5 = テナントごとに振り分けしてる。 8シャード - スケールアウトした場合も対応できるので。 PostgreSQLにマスターは保存 データの単位はメール。コメントはtextの配列でメールに保存されている。 EsはIDの一覧を返す。ただし、チケットのIDの一覧 機能 ハイライト Esではなく独自実装。 クエリ n-gramでやってる = kuromoji使ってない min=1, max=2 悩み事 EBS上だったものをローカルにしたので速くなった。 期間が長いと、検索結果一覧の表示が遅い aggsが遅いのかな? 検索結果一覧はチケットが持っているメールの日付の降順。結果一覧はチケットの一覧。 詳細検索はDB、左のステータスもファセットも現在はDBから生成 Es使ったほうが早いかも? マルチテナントのつらさ 検索ログ 独自ログはとっていない = アプリのログから判別 今後 アドレス帳検索 お誘いお待ちしております! 今後もこれやっていきたいなぁ。話してもいいよ!という方がいらっしゃいましたら、@johtaniまでDMもしくはメンションをください。お待ちしております!\n","date":1581344427,"dir":"post/2020/","id":"7b080dc43fce482af14de61c6ab819a5","lang":"ja","lastmod":1581344427,"permalink":"https://blog.johtani.info/blog/2020/02/10/explore-search-system/","publishdate":"2020-02-10T23:20:27+09:00","summary":"また、ツイートから始まるお話です。 まだまだ、検索システムってどんなものかを勉強したいしということで、こんなのをツイートしてました。 「検索シス","tags":["検索システム探訪"],"title":"「検索システム探訪」したいな=\u003eやりました"},{"contents":"年末、何種類かのボードゲームを家族で楽しみました。 家族の感想を交えて簡単に紹介しようかと思います。 家族や知人でボードゲームを購入するときの参考に参考にしてもらえたらと。 それぞれのゲームの詳細については、それぞれWikipediaなどのリンクを張っておくので、参考にしていただけたらと。 結構有名なボードゲームが多いのかな?\nカタン Amazon | カタン スタンダード版 | ボードゲーム | おもちゃ 簡単な紹介 プレーヤー数 : 3-4名 (拡張版を追加すると5-6名でもプレイできるみたい) 対象年齢 : 10歳以上 種類 : 対戦型 紹介 : 大航海時代に発見された無人島を複数の入植者たちが開拓していき、もっとも繁栄したプレイヤーが勝利するという内容のボードゲーム(Wikipediaより)。 特徴 : 5種類の資源を元に、道を作ったり、開拓地や都市を作ったり、サイコロを使った運も必要ですが、プレーヤー同士で手持ちの資源を交渉することも可能なゲームです。 感想 最初の配置が重要な気がします。資源の組み合わせによってできることが変わってくるので、何をやりたいかというのを元に考えて配置するのが重要そうです(私はまだうまくできてませんがw)。 プレーヤー同士の交渉も1つの手段なので、会話しながら、自然と交渉術も身についてきそうです。 戦略だけじゃなくサイコロを使った運もあるので、子供と大人が混ざっていても偏った結果にはならないです。 自分の道や町が発展していくのも楽しみの1つです。 お化け屋敷の宝石ハンター Amazon | お化け屋敷の宝石ハンター FBH20 | おもちゃ | おもちゃ 簡単な紹介 プレーヤー数 : 2-4名 対象年齢 : 8歳以上 種類 : 協力型 紹介 : お化け屋敷がおばけでいっぱいになる前に、みんなで協力して８つの宝石をみつけて、屋敷から脱出しよう！(メーカーホームページより)。 特徴 : 対戦ではなくプレーヤーみんなで協力してやるボードゲーム。おばけのフィギュアも可愛いです。サイコロを利用した運もありますが、みんなでどういった戦略で宝石を取り出すかなど会話も進むゲームです。上級編という難しめのルールも用意されているので、ハラハラ・ドキドキしながらプレイできます。 感想 負けて悔しくなったり機嫌が悪くなることがないのがいいですね。 普通のルールだと少し物足りない感じですが、上級編のルールはより、みんなで協力する必要が出てきます。 また、上級編のルールは絶妙な難易度で、もう一度やりたいと思わせるのが良い仕組みです。 ラビリンス Amazon | ラビリンス (Labyrinth) ボードゲーム | ボードゲーム | おもちゃ 簡単な紹介 プレーヤー数 : 1-4名 対象年齢 : 8歳以上 種類 : 対戦型 紹介 : 動く迷路で宝探し！通路が動く不思議な迷路の中に、「宝物」や「奇妙な生き物」が隠されています。プレイヤーはこれらを集めてこなければなりませんが、そのためには、巧みに迷路を動かさなければなりません。(メーカーホームページより)。 特徴 : サイコロがないボードゲームです。先を予測しながら人のじゃまをしつつ、自分に有利に進めていくゲームです。プレーヤー個別に難易度を変えられる仕組みがあります(子供だけに有利なルール設定が可能)。 感想 子供ルールがあるので、1度のゲームで別々の難易度が設定できるのがいいです。左右盲の人には子供ルールとかもありです。 ラビリンスが得意な人は地図を読むのが得意な人だと思います。 頭も使うけど、自分が望んだ道ができた時の快感があります。 モノポリー Amazon | ハズブロ ボードゲーム モノポリー クラシック C1009 正規品 | ボードゲーム | おもちゃ 簡単な紹介 プレーヤー数 : 2-6名 対象年齢 : 8歳以上 種類 : 対戦型 紹介 : プレイヤーは双六の要領で盤上を周回しながら他プレイヤーと盤上の不動産を取引することにより同一グループを揃え、家やホテルを建設することで他のプレイヤーから高額なレンタル料を徴収して自らの資産を増やし、最終的に他のプレイヤーを全て破産させることを目的とする。モノポリーとは英語で「独占」を意味する。(Wikipediaより)。 特徴 : 資本主義とは?みたいなのを体験できるゲーム。すごろく型ですが、ゴールがあるわけではなく、決着がつくまでぐるぐる回る感じです。 感想 資本主義を象徴しているゲーム展開。真剣勝負間違いなしです。 負けると途中退場ってのがちょっとつらいです。。。 カタンとは違った感じの交渉術になります。 コマが色んな種類があってかわいいです。 パンデミック Amazon | パンデミック:新たなる試練 (Pandemic) 日本語版 ボードゲーム | ボードゲーム | おもちゃ 簡単な紹介 プレーヤー数 : 2-4名 対象年齢 : 8歳以上 種類 : 協力型 紹介 : 『パンデミック』（Pandemic）は、プレイヤーが新型ウイルス対策チームの一員となり、協力しあい感染症の世界的流行（パンデミック）に立ち向かうというボードゲームである。(Wikipediaより)。 特徴 : プレーヤーが個別のロール(役割)を持っており、よりみんなで協力をしないとウイルスに打ち勝てない感じです。 感想 ルールが結構複雑で、理解しながらだと少し時間かかりました。 8歳以上になっていますが、少しむずかしい印象でした。 戦略、戦術が問われる形のゲームなのでしっかり理解すると楽しそう。 世界地図上で、ウイルスと戦っていく感じは臨場感があって面白いです。 ナインタイル Amazon | ナインタイル | カードゲーム・トランプ | おもちゃ 簡単な紹介 プレーヤー数 : 2-4名 対象年齢 : 6歳以上 種類 : スピード対戦型 紹介 : 「ナインタイル」の基本ルールは、それぞれの手元にある、９枚のタイルを自由に動かしたりひっくり返したりして、誰よりも早くお題どおりに並べるだけ。(公式サイトより)。 特徴 : ボードゲームというか、カードゲーム。ルールは簡単ですが、記憶力と素早さが重要です。 感想 脳トレに良さそう(子供に勝てませんでした。。。)。 瞬発力+記憶力が重要。 デザインがきれい じゃあ、家族の人気は? ラビリンス、カタン、モノポリーあたりが人気です。 ゲーム性もありますが、デザインとしてもきれいなものが多かったです。\nテレビゲームも面白いですが、ワイワイ喋りながらボードゲームをやるのも楽しかったです。 今回紹介したボードゲームはどれもある程度ルールを理解するところから始めないといけないですが、理解力や説明力なども必要になってくるので色んな楽しみがあるかなと思います。\n","date":1580558694,"dir":"post/2020/","id":"90f9355781403b92e844de8568863ae8","lang":"ja","lastmod":1580558694,"permalink":"https://blog.johtani.info/blog/2020/02/01/intro-board-game/","publishdate":"2020-02-01T21:04:54+09:00","summary":"年末、何種類かのボードゲームを家族で楽しみました。 家族の感想を交えて簡単に紹介しようかと思います。 家族や知人でボードゲームを購入するときの参","tags":["ゲーム"],"title":"ボードゲーム紹介"},{"contents":"実践Rust入門という本を買っていた(去年の7月だ。。。)のですが、積んであったので、時間を作って読み始めようかと。\n実践Rust入門[言語仕様から開発手法まで] | κeen, 河野 達也, 小松 礼人 |本 | 通販 | Amazon 経緯 もともとは、言語処理100本ノックはじめました(Rust)という感じで、触っていたのですが、場当たり的にやってても時間を持っていかれるだけだなということに気づいたのが最初です。\n今年の目標は、覚えられなので、ちょっとずつでもアウトプットしていこうってのもあり、 読書記録をつけつつ、読んでいこうかなぁと。\nどこまで読んだ? 2章の2-2-5までです。 前回、Rustの環境はセットアップしていたのですが、新PCに切り替わったので、rustupからはじめました。\nrustup rustupではデフォルト設定のままではなく、PATH変数の書き換えだけはしない形でインストールを行いました。\nPATH変数は.zshrcファイルで変更したかったためです(rustupコマンドに変更して貰う場合は.profileなどのファイルが変更されそうだったため)。\nインストールが終わったあとに.zshrcに以下の行を追加しました。\n### For Rust env source $HOME/.cargo/env 疑問点 ここまで読んだ疑問点です。\ncargo new helloしたあとにmain.rsに以下のmain()関数が出来上がっている!? fn main() { println!(\u0026#34;Hello, world!\u0026#34;); } 驚きましたが、cargo new hogeってやっても、おなじmain.rsができてました。デフォルトで出来上がるんですね。どんな超能力!?と思ってしまいましたw\ncargo new helloして出来上がったCargo.tomlに著者名が入力されていた。 authors = [\u0026#34;Jun Ohtani \u0026lt;メアド\u0026gt;\u0026#34;] なんで?と思いました。まだ解明してないです。 本を読んでいけばわかるかな?\n予想:gitの設定(~/.gitconfig)に氏名とメアドが設定されているので、これを利用しているのかな? ","date":1580475492,"dir":"post/2020/","id":"7fcfaa8dd34dbd508f19e8ca0fcfda0f","lang":"ja","lastmod":1580475492,"permalink":"https://blog.johtani.info/blog/2020/01/31/start-reading-bicycle-book/","publishdate":"2020-01-31T21:58:12+09:00","summary":"実践Rust入門という本を買っていた(去年の7月だ。。。)のですが、積んであったので、時間を作って読み始めようかと。 実践Rust入門[言語仕","tags":["rust","読書"],"title":"実践Rust入門はじめました"},{"contents":"12月に退職しますブログを書きましたが、その後どうなったのか?という話をしてないなと思ったので、一応現在の状況を書き留めておこううかと。\n結論 実際にはフリーランスとして働き始めてます。検索周りをお手伝いするお仕事を。読解いとこあれば所属するつもりでもいるし。\n\u0026mdash; Jun Ohtani (@johtani) January 27, 2020 フリーランスとして最初の仕事はElasticsearchではなく、Azure Cognitive Searchの支援だったりします。Esで困ってる方の手伝いもしますので、興味ある方はDMください。\n\u0026mdash; Jun Ohtani (@johtani) January 31, 2020 2020年1月24日が、正式なElasticの退職日でした(有給休暇消化してた)。 で、現在のステータスはこのツイートです。\n現在の心境 どこかに就職してガッツリ検索もやりたいし、いろんな会社の検索やElastic Stackに関するお手伝いをするのにも興味があるし、どちらにも興味がある状況です。まぁ、検索に興味が尽きないというのだけは決まってますかね。\n悩んでいるところに、幸いにもAzure Search周りで手伝ってほしいという話が舞い込んできたので、フリーランスとしてお手伝いをさせていただいてます(現時点で、半稼働で、が3月末まで)。\nElastic Stackなどの知見もあるのでのお手伝いをするというのもありかなぁと。お仕事発注してもいいな?という方があれば、TwitterのDMなど、連絡をいただければと。\n現在の状況でした。\n副業ができる会社に就職するのがどっちもできていいのかも?\n","date":1580470659,"dir":"post/2020/","id":"c61a5bda3f1667498626ae52ad0362e0","lang":"ja","lastmod":1580470659,"permalink":"https://blog.johtani.info/blog/2020/01/31/start-freelance/","publishdate":"2020-01-31T20:37:39+09:00","summary":"12月に退職しますブログを書きましたが、その後どうなったのか?という話をしてないなと思ったので、一応現在の状況を書き留めておこううかと。 結論","tags":["転職"],"title":"フリーランスはじめました(仮)"},{"contents":"ブログ移行日記(その4)です。その他の記事はこちら。\nブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その5) 前回までで、なんとなく移行は終わってます。 今回はテーマで使えるようになっているブログの検索機能の導入の話です。\n検索サービスはAlgoliaを利用します。 OctopressのころはElastic社のサービスであるElastic Site Searchの機能を利用して、クローリングしてから検索できるようにしていましたが、Hugoで導入できるモジュール?があったので、今回からこちらに移行しました。\n参考記事 Clean White ThemeのREADME(Algoliaの設定方法) 参考ブログ:hugoで作ったblogにalgoliaで全文検索機能を追加する Algoliaとは? 検索のas-a-serviceをやっている会社です。Wikipediaによると本社はサンフランシスコにあるみたいですね(フランスの会社のイメージでした。起業された方がフランス出身だからかなぁ?)。 クラウドで検索インデックスを保持でき、API経由で検索したり登録したりできる感じのサービスです。内部で使われているのはOSSではない独自の検索エンジンです。\nクラウドで提供されているサービスなのでサクッと検索を使い始めることができるのがいい点ですね。 また、小さな非商用のプロジェクトにフリーで利用できるプランも提供されているようです(2020年1月現在)。\nAlgoliaのサービス登録からインデックス作成 私が利用しているテーマで設定する方法の記載があったので手順の通りにやってみました。 大きく2つの作業(Algolia側とHugo側)が必要です。まずは、Algoliaで必要な作業から。作業の流れだけ記載しておきます。詳細は「Static site search with Hugo + Algolia」の3)を確認してください。\nAlgoliaのサインアップ(すでにアカウントがあれば不要) New Applicationの作成(名前とプランの指定) リージョンの指定 インデックス名の指定 APIキーを確認 です。これで、Algolia側の準備は完了です。\n今回は関係ないですが、Algoliaの管理画面で、利用状況(データ登録などの操作回数、クエリの回数、インデックスに保存されているレコード数)の確認が可能です。 ほかにも有料プランを利用するとAnalyticsなどもできるようです。\nHugo側で必要な設定 今度はHugo側です。Hugoのサイトのディレクトリに移動してからの作業です。\n仕組みとしては、\nHugoのoutput機能でAlgolia向けのJSONファイルを生成する Node.jsのライブラリを使用してAlgoliaに1.で生成したJSONを登録、更新する 検索画面の作成 という流れになります。 ですので、作業としては以下のとおりです。\nOutput出力の設定(すでにテーマ側で設定されているので、特に作業は必要なし) npm環境の構築(Hugoのconfig.tomlと同じディレクトリ階層) Node.jsのインストール(必要であれば) npm環境の初期化 npmでatomic-algoliaのインストール atomic-algolia向けの設定(登録のためのAPI関連の設定) Algolia向けJSONの出力設定 検索関連の設定 content/search/placeholder.mdの作成 検索用のAPIキーなどを設定 npm関連の作業 以下、npm関連の作業です。\nNode.jsのインストール(必要であれば) 割愛します。環境に合わせてインストールしてください。私はnvm経由でインストールしています。 npm環境の初期化 Hugoのディレクトリでnvm initを実行 npmでatomic-algoliaのインストール Hugoのディレクトリでnpm install atomic-algolia --save atomic-algolia向けの設定(登録のためのAPI関連の設定) Hugoのディレクトリに.envファイルを作成し、以下を設定します。 Algolia向けJSONの出力設定 特に変更なし(config.tomlに少し設定があります)。 ALGOLIA_APP_ID=AlgoliaのApplication ID ALGOLIA_ADMIN_KEY=AlgoliaのAdmin API Key ALGOLIA_INDEX_NAME=先程作ったインデックス名 ALGOLIA_INDEX_FILE=public/algolia.json 最後のALGOLIA_INDEX_FILEは固定文字列でいいと思います。 hugoコマンドを実行するとpublicディレクトリ配下にalgolia.jsonというファイルが生成され、Algolia登録用のJSONが出力されています。\n余談 : algolia.jsonの出力の設定は、config.tomlに記載があります。また、JSONファイルのテンプレート自体はthemes/hugo-theme-cleanwhite/layouts/_default/list.algolia.jsonにあります。Algoliaに登録するデータの構造など変更をする場合はこのテンプレートをカスタマイズすれば良さそうです。\n検索関連の設定 実際に検索の画面を表示するために、検索用の画面と、検索用のAPIの設定が必要です。\ncontent/search/placeholder.mdの作成 /search/が検索用のページになります。空のファイルです。実際にはJavaScriptが検索用の窓を表示したりしてくれます(これが必要な理由がまだ不明だなぁ)。 検索用のAPIキーなどを設定 検索のためのAPIキーなどの設定が必要となります。テーマ作者の方のサンプルのconfig.tomlにパラメータは用意されています。 以下の値を設定します。\nalgolia_search = true algolia_appId = \u0026#34;AlgoliaのApplication ID\u0026#34; algolia_indexName = \u0026#34;作成したインデックス名\u0026#34; algolia_apiKey = \u0026#34;AlgoliaのSearch-Only API Key\u0026#34; 以上でAlgolia関連の設定などの作業が終了です。\nAlgoliaへのデータ登録方法 最後に、実際にデータを登録する必要があります。 手順は、以下のとおりです。\nhugoコマンドの実行(htmlと一緒に登録データのalgolia.jsonを生成) npm run algoliaコマンドの実行(atomic-algoliaを利用してAlgoliaにデータを登録) 設定などが問題なければ、Algoliaの管理画面で登録ができているはずです。 実際にブログのデプロイにはdeploy.shというファイルをこちらを元に作成して使っています。このなかで、hugoコマンド実行後にnpm run algoliaを実行するようにしいます。\n今後の課題 Hugoで生成された記事はそれぞれのブログポスト以外に、タグごとのページも生成されています。 こちらも実はAlgoliaのインデックスに登録されていて、タグを入力すると、タグ名のリンクが出てきます。\nこちらはelasticsearchで検索したときの検索結果です。1件目はタグページです。\nこれらのページはAlgoliaに登録しないようにするのが良さそうかな?と考えているところです(考えてるだけ)。\n2020/01/29更新\nlist.algolia.jsonを編集して、記事だけをインデックスするように修正しました。 テーマに存在するlayouts/_default/list.algolia.jsonを、自分のところにコピーし、次のように変更しました。if文を1行追加して、postという種類のものだけを出力するようにしました。\n{{/* Generates a valid Algolia search index */}} {{- $.Scratch.Add \u0026#34;index\u0026#34; slice -}} {{- $section := $.Site.GetPage \u0026#34;section\u0026#34; .Section }} {{- range .Site.AllPages -}} {{- if or (and (.IsDescendant $section) (and (not .Draft) (not .Params.private))) $section.IsHome -}} {{- if (and (eq .Section \u0026#34;post\u0026#34;) (ne .URL \u0026#34;/post/\u0026#34;)) -}} {{- $.Scratch.Add \u0026#34;index\u0026#34; (dict \u0026#34;objectID\u0026#34; .UniqueID \u0026#34;date\u0026#34; .Date.UTC.Unix \u0026#34;description\u0026#34; .Description \u0026#34;dir\u0026#34; .Dir \u0026#34;expirydate\u0026#34; .ExpiryDate.UTC.Unix \u0026#34;fuzzywordcount\u0026#34; .FuzzyWordCount \u0026#34;keywords\u0026#34; .Keywords \u0026#34;kind\u0026#34; .Kind \u0026#34;lang\u0026#34; .Lang \u0026#34;lastmod\u0026#34; .Lastmod.UTC.Unix \u0026#34;permalink\u0026#34; .Permalink \u0026#34;publishdate\u0026#34; .PublishDate \u0026#34;readingtime\u0026#34; .ReadingTime \u0026#34;relpermalink\u0026#34; .RelPermalink \u0026#34;html\u0026#34; .Params.Description \u0026#34;title\u0026#34; .Title \u0026#34;type\u0026#34; .Type \u0026#34;url\u0026#34; .URL \u0026#34;weight\u0026#34; .Weight \u0026#34;wordcount\u0026#34; .WordCount \u0026#34;section\u0026#34; .Section \u0026#34;tags\u0026#34; .Params.Tags \u0026#34;categories\u0026#34; .Params.Categories \u0026#34;author\u0026#34; .Params.authors \u0026#34;content\u0026#34; .Params.Description \u0026#34;excerpt_html\u0026#34; .Params.Description \u0026#34;excerpt_text\u0026#34; .Params.Description \u0026#34;summary\u0026#34; .Summary)}} {{- end -}} {{- end -}} {{- end -}} {{- $.Scratch.Get \u0026#34;index\u0026#34; | jsonify -}} まとめ これで、ブログ内記事検索ができるようになります。 Algoliaは個人の非商用利用の場合、フリープランが用意されているのがありがたいですね。 まだ、Hugoと連携しただけで、Algolia自体でどんな機能があって、どんなことができそうかといったところは調べていませんが、簡単に利用できるのはとても助かります。\nまぁ、個人ブログの検索機能ってそんなに使う人はいないんですが、自分としては便利かなぁと。\n","date":1580186404,"dir":"post/2020/","id":"d9018f459d3c94a91e92b459e152f7e7","lang":"ja","lastmod":1580283604,"permalink":"https://blog.johtani.info/blog/2020/01/28/introduce-algolia/","publishdate":"2020-01-28T13:40:04+09:00","summary":"ブログ移行日記(その4)です。その他の記事はこちら。 ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(","tags":["ブログ"],"title":"ブログ移行日記(その4) - 検索機能(Algolia)の導入"},{"contents":"ブログ移行日記(その3)です。その他の記事はこちら。\nブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その4) ブログ移行日記(その5) 今回は、Hugoの設定とテーマの一部変更した点について記載します。\n設定ファイル(config.toml) Hugoの設定ファイルはconfig.tomlになります。hogo new siteコマンドで生成したディレクトリの中にデフォルトで含まれていますが、こちらではなく、テーマの作者が用意してくれたconfig.tomlを元に変更を加えました。\nちなみにテーマの作者の方が設定とコンテンツを含めたサンプルも公開してくれています。設定やディレクトリの構成はこちらを参考にしました。\n設定ファイルで変更した項目は以下のとおりです。\nサイトのタイトルや説明など 特記することはありません。好きなように変えました。\nbaseurl title SEOTitle description keyword slogan sidebar_about_descrption 画像関連(ヘッダーや著者近影) 画像の置き場はstatic/images/ディレクトリですが、設定ファイルには images/から設定します。\nheader_image : ブログのヘッダー背景 sidebar_avatar : 著者近影 言語周り(特に多言語対応する予定は無いのですが) languageCode = \u0026ldquo;ja\u0026rdquo; defaultContentLanguage = \u0026ldquo;ja\u0026rdquo; オフにした機能、削除した項目 freands = false bookmarks = false 上記の設定変更以外に、[[params.bookmark_link]]や[[params.friend_link]]も削除。\n中国のサービスや、特化した設定など。\nBaidu Analytics関連 Disqus proxy関連 Reward(wechat pay \u0026amp; alipay関連) params.social関連 rss = true twitter linkedin github ほかはすべてコメントアウト。\n外部サービス関連 disqusShortname : Disqusのショートネーム googleAnalytics : Gooogle AnalyticsのトラッキングID algolia関連 : 別のブログ記事として、設定方法などを書きます。 追加した設定(昨日のブログで説明済み) Octopressと同じ形のパーマリンク [permalinks] post = \u0026#34;/blog/:year/:month/:day/:slug\u0026#34; Markdownファイル中のHTMLタグ表示 [markup.goldmark.renderer] unsafe = true 以上が設定ファイル関連です。\nテーマの変更点 テーマそのままでは問題があったり、独自に変更したいという点があったので、いくつか変更をしています。\nフォントの変更 そのままテーマを適用するだけでうまく行けばよかったのですが、フォントの問題が発生しました。テーマの作者の方が中国の方だから?かどうかはわかりませんが、デフォルトのままだと中華フォントになってしまいました。\nあー、中華フォントだな。 pic.twitter.com/OvHpY4LSp1\n\u0026mdash; Jun Ohtani (@johtani) January 16, 2020 config.tomlにcustom_cssという設定があり、こちらで指定したCSSのファイルがテーマのlayouts/partials/head.htmlから読み込まれる仕組みがあるようなので、フォントに関するCSSをこの機能を使用して指定するようにしました。\nconfig.tomlの設定は次のとおりです(リスト)になっているので、複数のファイルに分割して、読み込ませることも可能なのかな?。\ncustom_css = [\u0026#34;css/custom-font.css\u0026#34;] cssファイルについては、static/css/custom-font.cssというファイルを作成し、次のような記載になっています。 フォントの指定と右側サイドバーの自己紹介の部分の文字色を変更するためのものです。\nbody, h1, h2, h3, h4, h5, h6, .navbar-custom { font-family: Helvetica,\u0026#34;Sawarabi Gothic\u0026#34;,Meiryo,\u0026#34;メイリオ\u0026#34;,\u0026#34;Hiragino Kaku Gothic ProN\u0026#34;, \u0026#34;ヒラギノ角ゴ ProN\u0026#34;,YuGothic,\u0026#34;游ゴシック\u0026#34;,Arial,sans-serif; } .sidebar-container { color: #404040; font-size: 14px; } faviconの変更 テーマにfavicon.icoが含まれていたのですが、せっかくなので独自のものに変えてみようかと。 ただ、残念ながら、こちらはパスおよびファイル名がlayouts/partials/head.htmlに直書きされていました。\n画像はimages配下にと思っていたのですが、このパスだけを変更するためにhead.htmlを自分の配下にコピーしてカスタマイズするのもどうかと思った(テーマに変更やバグ修正が入るたびに手動でコピーするのはなぁと思った)ので、static/img/favicon.icoファイルを作成しました。\nテーマよりもHugoのプロジェクトにあるファイルを優先するようなので、ファイルだけをプロジェクトに作成しました。\n記事一覧のテンプレート 記事の一覧で表示される、作成者と作成日時が英語表記でかつ、冗長な感じがしたので、スッキリさせるために、layouts/partials/post_list.htmlをテーマからコピーして、次のように変更しました。\n元の形式は : Posted by author Monday, January 2, 2006 現在の形式 : 2006-01-02 by author 記事のテンプレート 今回採用したテーマでは、記事の先頭に記事のセクションを元に目次を生成してくれるものでした。\n目次をコンテンツから自動で作ってくれるの便利だな。 pic.twitter.com/9bU3sLnUrm\n\u0026mdash; Jun Ohtani (@johtani) January 16, 2020 とても便利です。ただ、表示が「TOC」なんです。 英語でしかも「ToC」という表記ならまだ気にならなかったかもですが、大文字だと流石に気になったので、プロジェクトのlayouts/_default/single.htmlにコピーして「目次」という日本語に書き換えました。 このHTMLにテーマで修正が入った場合はどうしようかなぁ。。。というのが目下の悩みです。。。\nArchetypeテンプレートの追加 最後は新規記事を書くときに生成されるMarkdownのメタデータの追加です。 HugoにはArchetypesというのが存在します。\nHugoではhugo new 記事としたときに、記事の種類(content/ディレクトリ名=記事のタイプ)によって、作成するmarkdownファイルをテンプレートから生成する機能があります。この生成時に使われるのがarchetypesというディレクトリにあるファイルです。\n私のブログサイトでは、今のところcontent/postというブログの記事だけを書く予定ですので、archetypes/post.mdというファイルを作って以下のようなメタデータをhugo newしたときに自動で生成するようにしました(テーマにあったpost.mdファイルの代わり)。\n--- layout: post title: \u0026#34;{{ replace .Name \u0026#34;-\u0026#34; \u0026#34; \u0026#34; | title }}\u0026#34; slug: \u0026#34;{{ substr .Name 11 }}\u0026#34; author: johtani date: {{ .Date }} comments: true tags: [] draft: true --- タイトルはファイル名のハイフンを空白に変換したもの(実際にはファイル名は英語にしているので、使いませんが。。。) slugはファイル名の先頭からYYYY-MM-DD-という11文字を除いたもの。これは、OctopressのURLに合わせるために使用するURLの一部の文字列です。 author: johtani : 著者は私だけだから固定文字列 comments: true : ブログ記事にはDisqusのコメント機能を利用 tags: [] : 各内容によってタグを付けるが、生成時には空 draft: true : 明示的にこの行を消すまではドラフト記事としたいため という感じです。ほかにどのよなメタデータがあるのかまではまだ調べていないので、今後また適宜変更していくと思います。\nまとめ Hugoの設定や、テーマそのままではなく独自の変更を加えた部分を思い出して書き出してみました。\nこれで、Algoliaに関する部分以外はだいたい思い出して書いたと思います。 次は、Algoliaの使い方と設定について書き残す予定です。\n","date":1579853081,"dir":"post/2020/","id":"99c9c80a6532e4ea3b535c5a92d07a25","lang":"ja","lastmod":1579853081,"permalink":"https://blog.johtani.info/blog/2020/01/24/setting-hugo/","publishdate":"2020-01-24T17:04:41+09:00","summary":"ブログ移行日記(その3)です。その他の記事はこちら。 ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その4) ブログ移行日記(","tags":["ブログ"],"title":"ブログ移行日記(その3) - Hugoの設定と微調整(テーマに合わせた)"},{"contents":"その他の記事はこちら\nブログ移行日記(その1) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) ブログ移行日記(その2)です。前回はHugoとは?というのと、自分が選んだテーマについて記載しました。 本家の手順などを参考にすると、Hugoにテーマを適用し、でHTMLを生成して、表示するところまでできるはずです。\n今回は、OctopressのmarkdownファイルをHugo用に変換する方法について紹介します。お手製ですが、Pythonスクリプトを作ったので、そちらも合わせて簡単に紹介する予定です。\n参考ブログ 「Octopress Hugo 移行」でググるといくつか出てきます。先人の知恵ありがたいですね。 ということで、私はこちらの2つのブログを参考にさせていただきました。ありがとうございます。\nOctopress から Hugo へ移行した - iriya-ufo\u0026rsquo;s blog OctopressからHugoへ移行する方法 | gam0022.net 画像のコピー 画像はそのまま上記参考ブログを元にsource/imagesからstatic/imagesにコピーしました。特にディレクトリ構造の変更とかもしませんでした。\nコンテンツのコピー こちらは、コピーのタイミングでいくつか変換などの処理を行いました。 ファイルの変換にはPythonのスクリプトを書きました。 自分向けの移行ツールなんで、ディレクトリ名とか引数にすらしてないです。。。\n参考ブログと同様の変換\nメタデータの日付変換 categoriesをtagsに変換 画像タグの変換 タイトル、画像のサイズなどに合わせていくつか分岐があります。 参考ブログとは異なる変換、変更\nコードブロックは無変換 0.60.0からCode Fencesに対応したみたいなので不要でした。 ディレクトリ構造の変更 ファイルを年ごとのディレクトリに格納(これまでは、全てのファイルが同一ディレクトリにあった) 拡張子の変更 (.markdown -\u0026gt; .md) メタデータにauthorの追加(自分しか書かないんですけどね) URLをOctopressに合わせる Google検索からの流入もあり、これまでのURLに変更はかけたくないなと。 こちらも参考ブログに記載があるので、そのまま参考にさせていただきました。\nslugについては、移行ツールでファイル名を元に追加する処理を書きました。\nHTMLを含んだMarkdownの対応 TweetやAmazonのアフィリエイトのリンクがHTMLタグでいくつかの記事に含まれており、デフォルトの設定だと表示されません。 config.tomlファイルに以下の設定を追記することで、出力されるようになりました。\n[markup.goldmark.renderer] unsafe = true 名前がunsafeなので、ちょっと気になりますが。。。 すべての記事を表示してチェックしてみたわけではないので、おかしな記事を見つけた方は連絡をいただけると助かります。\nまとめ OctopressのファイルをHugo用にコピーや変換した方法を思い出しながら書いてみました。基本的には参考ブログに上げた2つのブログを真似したものになります。\n次は、利用したテーマのサンプル設定を元に、自分用に変更した点などについて書き残しておこうかな?\n","date":1579775514,"dir":"post/2020/","id":"018b365b00dd3a6ad17c813d21590549","lang":"ja","lastmod":1579775514,"permalink":"https://blog.johtani.info/blog/2020/01/23/convert-md-from-octopress-to-hugo/","publishdate":"2020-01-23T19:31:54+09:00","summary":"その他の記事はこちら ブログ移行日記(その1) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) ブログ移行日記(その2)","tags":["ブログ"],"title":"ブログ移行日記(その2) - Markdownファイルの変換"},{"contents":"その他の記事はこちら\nブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) 起因 いつものツイートから始まる私の行動です。\n(もしかしたら前に一度おすすめしたかもですが) Goのtemplate構文に拒絶反応がなければHugo割と良いですよ〜。\n\u0026mdash; Nobuyuki Kubota (@nobu_k) October 10, 2019 ってことで、Hugo勧められたし、テーマが豊富だしということで、乗り換えた次第です。\n(元)同僚に教えてもらった記事を見てる。Gatsbyも気になるんだけど、デザインセンスないし、テーマが豊富なのがいいなぁ。/ Comparison of Gatsby vs Jekyll vs Hugo | GatsbyJS - https://t.co/yUbKiBmtMS\n\u0026mdash; Jun Ohtani (@johtani) January 9, 2020 一応Gatsbyのサイトにあった比較も見たのですが、テーマの豊富さが勝ちました。デザインを自分でやれるほどではないので。\n理由 乗り換えるに至ったのは主に2つの理由です。\nOctopressが更新されていない ページが増えてきてサイトの生成に時間がかかる 前に使っていたOctopressもJekyllというものがベースになっていました。 Jekyllは今でも更新があるのですが、Octopressが更新されなくなってしまったのと、Rubyがベースになっているため?なのかはわかりませんが、 ブログのページ数が増えてきて、サイトのビルドに時間がかかってくるようになりました。\n結果 まだ、改良点があるかもですが、とりあえず公開できる感じになったと思ったんで切り替えました。\n前のブログはこんな感じで、\n移行後はこんな感じです。\nHugoとは? 公式サイト こちらにあるように、Go言語で実装されているウェブサイト構築フレームワークです。 Go言語で実装されているのもあり、インストールが簡単でした。 Macを使っていますが、Homebrewでインストールができてしまいます。 他の方法もあるようでしたが、Emacsをインストールするのにbrewを入れているので、brewでインストールしました。\n使い方は色んな人が書いてるし、公式ドキュメントを見ていただけばいいかな。\nテーマとは? Hugoのサイトにテーマの一覧があります。 一応、個人のブログなので、それなりにデザインを入れつつ、他の人と違う感じにしたいなと。 テーマ一覧をざっと眺めて良さそうなのをピックアップしたら、最終的にこちらのテーマになりました。\nClean White それなりに更新されてますし、DisqusとSearch(Algolia)が使えるのでこのテーマに決めました。 テーマのインストール方法などはGitHubのREADMEの「Quick Start」に記載があります。\n私は、Hugo自体の設定などをGitHubで管理したかったので、git submoduleを利用して、次のような構成になりました。\nhugo - main repository ├── archetypes ├── content ├── data ├── layouts ├── public - github.com/johtani/johtani.github.io ├── resources ├── static └── themes └── hugo-theme-cleanwhite - github.com/zhaohuabing/hugo-theme-cleanwhite.git hugo : hugo new siteコマンドで作成されたディレクトリです。このディレクトリでまずgit initしました(このリポジトリはプライベートで管理してます)。 themes/hugo-theme-cleanwhite : テーマのQuick Startにあるgit submodule addコマンドでサブモジュールとしてテーマをインストールしました。 public : hugoが生成するHTMLのトップのディレクトリがこちらです。私はGitHub pagesを利用してブログを公開しているので、git submodule addでjohtani.github.ioをサブモジュールにしました。 Hugoで生成したHTMLなどをGitHub pagesで公開するときの手順などはHugoのドキュメントに記載がありました。\nまとめ Hugoに移行した理由や、Hugoとテーマの簡単な紹介でした。 テーマが豊富なのはデザイン力(りょく)がない身としてはありがたいですよね。 次はOctopressのmarkdownファイルをHugo用に変換したり、それに関する設定周りの話を書く予定です。\n","date":1579659814,"dir":"post/2020/","id":"a65bd31d4c3dab0a41712823a5d6002b","lang":"ja","lastmod":1579659814,"permalink":"https://blog.johtani.info/blog/2020/01/22/intro-hugo-and-theme/","publishdate":"2020-01-22T11:23:34+09:00","summary":"その他の記事はこちら ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) 起因 いつものツイートから","tags":["ブログ"],"title":"ブログ移行日記(その1) - Hugoとテーマ"},{"contents":"5年くらい、Octopressを使用していましたが、更新されなくなっているのと、コンテンツの生成に時間がかかることもあり、 ほかのプラットフォームを使用するように変更しました。\nとりあえず、今回の移行で参考にした記事とかURLをリストアップしてみました。 詳細についてはまた明日以降で。\n参考記事 移行関連 : https://iriya-ufo.net/blog/2018/12/27/octopress-to-hugo/#github-pages- 移行関連 : https://gam0022.net/blog/2016/09/25/migrated-from-octopress-to-hugo/ Hugo自体の日本語紹介記事 : https://knowledge.sakura.ad.jp/22908/ Hugo概要 https://gohugo.io/ テーマ 一覧 : https://themes.gohugo.io/ 利用したテーマ : https://github.com/zhaohuabing/hugo-theme-cleanwhite データ移行 作ったスクリプト : https://github.com/johtani/from-octopress-to-hugo favicon 作ったサイト : http://emblemmatic.org/markmaker/#/ Algoliaセッティング 参考 : https://blog.uni-3.app/2019/01/02/hugo-algolia-search/ GitHub Pagesでの運用 https://gohugo.io/hosting-and-deployment/hosting-on-github/#types-of-github-pages 残タスク Amazonのアフィリンクをきれいに表示するlayoutか何かを用意する?　","date":1579166617,"dir":"post/2020/","id":"3c299a4d77be8b4f886ce9fcd23a2561","lang":"ja","lastmod":1579166617,"permalink":"https://blog.johtani.info/blog/2020/01/16/moving-to-hugo/","publishdate":"2020-01-16T18:23:37+09:00","summary":"5年くらい、Octopressを使用していましたが、更新されなくなっているのと、コンテンツの生成に時間がかかることもあり、 ほかのプラットフォ","tags":["hugo","ブログ","octopress"],"title":"OctopressからHugoへ移行中(まだ途中)"},{"contents":"今年も振り返りブログ書いてます。Sasukeがついてる。\n振り返り（2018年に書いた抱負から） まずは去年の抱負を元に。\nTOEIC 受けました。\nお。TOEICの点上がってた（まだまだだけど。。。）\n\u0026mdash; Jun Ohtani (@johtani) October 21, 2019 無事、上がってました。テストの点数を上げるのが目的ではなく、今の実力が どんな感じかというのを確認するために受けました。 前回までが低かったのもあるんですが。 また、数年後に受けてみるのかな?\nCfP見つけて応募 \u0026amp; いろんな場所に顔を出す 色んな所には顔を出しました。 CfPはそれほど出せていなく、とちぎRubyとDevRelJPで喋った程度かと。 12月に最終出社日を迎えたので、今後は顔を出したりCfP見つけて応募も、 一旦休憩に入る予定です。\nもっとブログ！ 12月に入ってから、一気に増えてますねw Elasticでは結局それほどかけなかったなぁ。\nRustの継続 こっちは、書籍も買ったのに手がついてないです。 来年に書籍を読みながら再入門する予定です。\n開発の継続 一応ほそぼそと続けてますが、メンテナンスですね。 Analyzer向けのKibanaのプラグインのバージョンアップにだけ対応していたり。 年初にReact化には着手しました。 あとは、Luceneにちょっとしたパッチ(Lukeの画面とKuromojiのUniDic対応)を送った感じかな。もっとLucene周りやりたいかな。\n日本でエンジニア獲得! トレーナーやエンジニアが入社してくれました! が、私が退職してしまいますが。。。 私自体が次のステップに移らないとなぁと。 Elasticに興味がある人いたら、中の人を紹介できるので声をかけてください!\n振り返り(今年あったできごと) さて、ここからは今年の出来事を。\n検索技術勉強会発足 勉強会運営座談会 初フロリダ 初カナダ\u0026amp;初ナイアガラの滝 退職(予定) 検索技術勉強会ってのをはじめました(はじめましたブログはこちら)。 やっぱり検索の話を聞いたり考えたりするのが好きなので、もっといろんな話を聞く機会がほしいなぁと。ツイートすると何人かの知り合いが手を上げてくれたので、初めて見たのが2月でした。 所属会社もあったので、自分が全面に出ない形で運営に協力するという形式でやっています。なんだかんだでもう4回も開催できています。スピーカーへの声掛けなど、複数人で運営するとそのあたりが多様性が出るし、楽になるのですごくいいなぁと。 来年も2月か3月にやりたいねと話をしているところです。興味のある方は、ぜひスピーカーを!\nで、その流れで、他の勉強会の運営ってみんなどうしてるんだろう? という疑問も出てきたので、勉強会運営座談会なるものもやってみました。少人数で集まって、勉強会の運営ってどんなやり方してます?どんなことに困ってます?みたいなのを共有してみました。 自分自身がそれほど、ほかの勉強会の運営に顔を出してたわけでもなく、やり方をみんなはどうやって共有してるのかなぁ?というのが気になったので。 思った以上に属人化してるのかもなぁというのが感想でした。 ドタバタしてたので、あれからやってませんが、共有する勉強会みたいなのも面白いのかも?\n今年も2回ほどElasticの社内イベントで海外に行かせてもらいました。 5月にフロリダと11月にトロントでした。 フロリダでは、NASAにも行けたし、トロントでは足を伸ばしてナイアガラの滝を見に行くなどもしてみました。こういう機会が定期的にあるのは、いいですよねぇ。\n最後は、退職イベントですね。5年5ヶ月勤めたElasticでの仕事が、12/6で最終出社日でした。実際の退職日は1/24となっています(現在有給休暇消化中)。長かったような、短かったような。日本で1人目で入社してさまざまなことをやらせてもらい、本当に色んな経験ができました。英語も上達したし。 ただ、外にいることでできることがありそうだなと感じたこともあってのこの決断でした。\n最終出社日以降、色んな人とランチさせてもらったりしています。 次に何をやろうかな?ってのんびり考えながら休んでいるところなので。 やっぱり、検索周りのことをやりたいなぁというのが念頭にあるので、そのあたりで模索中という感じです。 が、せっかくの機会なので、少しのんびりしようかなとも思ってます。 なので、プラモデルの作成や配達業(デス・ストランディング)をやってみたり、16インチMacbookのセットアップしながらブログ書いたりしています。 年明けに入ったら、プログラミングもちょっとやりたいな。\nあとこの場を借りて、ブログの欲しい物リストのものを送っていただいた皆様に感謝を述べさせていただきます。本当にありがとうございました!この感謝はまた何かの機会にでも!\n来年の抱負 ということで、来年の抱負です。\n職につく ブログプラットフォームの移行 プログラミング Rust再入門 検索の勉強 検索技術勉強会の継続 まぁ、まずは職につかないとですね。どこかに在籍しつつ、副業で検索周りのこととかやるのもありかもなぁと考えたりしています(プラモデルつくりながらw)。\nブログのプラットフォームをOctopressからHugoあたりに移行しようかなと思ってます。Octopress自体がもう開発がされてないようですし。Hugoだとテンプレート?テーマ?がそれなりにありそうなので良さそうかなぁと。移行プログラムも書かないとかな。新しいものを調べるのって楽しいですよね。\nプログラミングも復活させたいなと。どうしてもこれまでは、しゃべるのをメインにしていたので、後回しにしてしまっていたのもあります。まぁ、向いてないのかもと思ったりもしますが、下手の横好きなりに少しずつでも何かを改善したり作ったりしたいなと。 勉強会の運営周りですこし楽をするためのプログラム書いたりもしているので、この辺もブログに書こうかな?\nRustはTantivyというプロダクトも出てきているし、勉強しようと思って、自転車本を買いつつ、Kindleの肥やしにしているので、手を動かそうとおもいます。 ブログ書いてサボった場合の可視化しないとなw\n検索の勉強もやりたいなと。これまではElasticsearchに注力していましたが、ほかのプロダクトやサービスも調べてみたいなと。教えを請いに皆さんのところにお邪魔するかもしれないので、そのときは優しくしてください。\n今年始めた検索技術勉強会を今後も継続できるようにしたいなと。 で、運営周りを楽にできるような仕組みをもう少し導入できればなぁと考えていきたいなと思います。\nさて、嵐の曲も始まったし終わりです。\n今年も様々な方々に助けていただきました。また、最終出社日以降にランチを一緒にさせていただいたり、遊びに行かせていただいたりとありがとうございました。年明けもひましてるので、ぜひランチしましょうw\n来年はなにやってるんだろうなぁ? 今後も皆さんよろしくおねがいします!!\n","date":1577764743,"dir":"post/2019/","id":"35aa9e09db936aee7ec407c431816573","lang":"ja","lastmod":1577764743,"permalink":"https://blog.johtani.info/blog/2019/12/31/looking-back-2019/","publishdate":"2019-12-31T12:59:03+09:00","summary":"今年も振り返りブログ書いてます。Sasukeがついてる。 振り返り（2018年に書いた抱負から） まずは去年の抱負を元に。 TOEIC 受けました。 お。TO","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2019）"},{"contents":"このブログ書こうと思って、これまでMacのセットアップしてたんだった。。。\n普段、macOSの標準ターミナルを使ってます。 で、ターミナルを使うシーンは次のような感じです。\nブログのデプロイ（参考：Octopress環境のDockerイメージ化） ElasticsearchとKibanaの動作確認 Elasticsearchの起動用ターミナル Kibanaの起動用ターミナル プラグインの開発(elasticsearch-ingest-csv と analyze_api_ui) elasticsearchのリポジトリ kibanaのリポジトリ ingest-csvのリポジトリ analyze_api_uiのリポジトリ 上記のように1.以外については複数のターミナルをそれぞれのディレクトリで起動して使っています。 これらの3つのパターンのときに、毎回ターミナル(シーンによっては複数のウィンドウ)を開いて、ディレクトリに移動って大変だなと。\nウィンドウグループって？ そこで、ターミナルに便利な機能がないのかな?と思い、メニューを見ていたところ「ウィンドウグループ」というのがあったので調べて、現在の使い方に至っています。\nウィンドウグループの使い方の説明はこちらです。\n使い方にあるようにウィンドウの場所、設定、タブなどを保存できます。 そして、「ウィンドウグループを開く」というメニューから保存しておいたグループを開くと、簡単に作業環境が再現可能になります。\n開くときのメニューはこんな感じです。\n作り方 ウィンドウグループの使い方に載ってます。 まずは、保存したいターミナルを開いて、開いたときに移動していたいディレクトリに移動します。 複数のタブやウィンドウを開いた状態にしたい場合は、複数ターミナルを起動して、それぞれ移動したいディレクトリに移動しておきます。\nグループとしてまとめたいウィンドウが起動できたら、あとは、「ウィンドウ」メニューの「ウィンドウをグループとして保存」を選択します。\nこれだけです。あとは、使いたくなったときに開くだけです。 簡単ですよね?\n作るときの注意点としては、複数のウィンドウグループを作りたいときは、 それぞれグループごとに作成しては、個別にやる必要があります。 現在開いているターミナルのうち、あれとこれをウィンドウにしたいというやり方はできないので、そこだけ注意点です。 環境ごとにプロファイル(バックグラウンドの色やテーマ)を覚えさせることができるので、1.のシーンだとIceberg、2.のシーンではBasic、3.のシーンではHomevrewで設定していたりします。 (ただ、Preztoのテーマをagnosterにしてしまったので、Basicだとプロンプトが見にくくてしょうがないのですが。。。)\n設定はどんな感じ？？ ウィンドウグループの管理については、ターミナルの「環境設定」に管理用の画面があります。\nこの画面でいらないグループを削除したり、設定のエクスポート/インポートも可能です。\n私の使い方 3つの利用シーンは説明しました。 すべてのウィンドウグループを変更するたびにインポート/エクスポートしてます。 上記1.と3.のユースケースはほぼ変更がないので、エクスポートしたものを移植用に管理していますが、2.のユースケースについては、頻繁に更新しています(ElasticsearchとKibanaのバージョンをアップしないといけないので)。\nこのとき、MacのGUIで毎回設定をしているわけではありません。 エクスポートしたファイルは、.terminalという名のXMLファイルになっています。\nその中に、次のようなパスが記述されています。このバージョン番号の部分をアップデートのたびにemacsなどで変更し、ターミナルの管理画面で、削除してからインポートし直すだけで、バージョンアップに対応している感じです。\n\u0026lt;key\u0026gt;Tab Working Directory URL\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;file://johtani-mac-15.local/Users/johtani/tmp/elastic_stack/v7.5/elasticsearch-7.5.1/\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Tab Working Directory URL String\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;file://johtani-mac-15.local/Users/johtani/tmp/elastic_stack/v7.5/elasticsearch-7.5.1\u0026lt;/string\u0026gt; まとめ ということで、標準ターミナルのウィンドウグループを使うと、よく開くディレクトリやウィンドウ、タブを覚えて置かせることができるので、それぞれの環境向けのターミナルを、好きなときに開くことができるようになります。 私は、ウィンドウは1つで複数のタブをウィンドウグループという形で覚えさせておくことで、各シーンの切り替え、もしくは併用を閉じたり開いたりを簡単にできるようにしています。\n他のターミナルソフトを使うと似たようなことが簡単にできたりするのかな? みなさんがどうやってこのような作業やってるのかな?ってのはちょっと気になるところです。\n余談（いつものようにツイートとその反応） ちなみに、みんなどんなターミナル環境なんだろう？と思いツイートしてみた結果はこちらです。 (コメントRTってうまいことひろえないのかなぁ？)\nMac標準のターミナル使ってる人ってどのくらいいるんだろ？iTermとか入れてるのかな？tmuxとか？\n\u0026mdash; Jun Ohtani (@johtani) December 11, 2019 Iterm2使ってtmux使って今はIterm2だなー\ncommand2回押すだけでターミナル出すくせが抜けん https://t.co/P8o4M1HSoj\n\u0026mdash; GO☆ | TAFDATA (@_gogoponz) December 11, 2019 Alacritty + tmux やなー。標準はもう使ってない。 https://t.co/HI7hPCg3uo\n\u0026mdash; Ryo HIGASHIGAWA (@biwakonbu) December 11, 2019 標準です https://t.co/W27e2pcq3j\n\u0026mdash; shin higuchi @Acroquest (@shin0higuchi) December 11, 2019 Macを買って以来、ずっと結局標準ターミナル以外使っていない感じ。珍しかったのか。。 https://t.co/Zjz32SgjC6\n\u0026mdash; Kazuhiro Hara™ (@kara_d) December 11, 2019 ","date":1577063679,"dir":"post/2019/","id":"1a1a8cc0040b356d06eacd22e0526476","lang":"ja","lastmod":1577063679,"permalink":"https://blog.johtani.info/blog/2019/12/23/whats-window-group-of-terminal/","publishdate":"2019-12-23T10:14:39+09:00","summary":"このブログ書こうと思って、これまでMacのセットアップしてたんだった。。。 普段、macOSの標準ターミナルを使ってます。 で、ターミナルを使う","tags":["misc"],"title":"macOS標準のターミナルのウィンドウグループが便利"},{"contents":"ドットファイル系（.emacsとか）をこれまでは、PCを引っ越すたびにコピーしてたんですが、いいかげん、GitHubとかで管理したいなと。\nで、ツイートしたところ（こればっかりだなｗ）、homeshick(homesick)が便利だよとの情報を得たので使ってみました。\nhomesick、正確にいうとhomeshickを使ってます。悪くないです\n\u0026mdash; 🤓k.bigwheel🤓 (@k_bigwheel) December 10, 2019 使い方とか 実物はGitHubで公開されていました。\nhttps://github.com/andsens/homeshick\n何者かというと、ホームディレクトリにあるドットファイル(.zshrcなど)をgitコマンドで管理するのを楽にしてくれるシェルの関数群みたいです。 インストールは至ってかんたんで、git cloneで持ってくるだけです。homeshickのリポジトリのREADMEに記載があります。\n使い方はTutorialsにあります。\nhomeshick generate ほげほげで管理する単位（castle）を作ります。ほげほげが名称です。今回私はdotfilesにしました。 homeshick track ほげほげ .zshrcで管理したいファイルを指定します。すると、homeshickが対象のファイル（ここでは.zshrc）をcastleの保存先ディレクトリにコピーしてから、シンボリックリンクをホームディレクトリ上に作ってくれます。 homeshick cd ほげほげで、castleの実際のディレクトリに移動します。実態は.homeshick/repos/ほげほげです。 git remoteコマンドでcastleとGitHubの関連をつけて、あとは、普通にgitコマンドでコミットしたりすればOKです。 すごく簡単に導入できました。あとは、実際にtrackしたいファイルを追加していく感じです。 現状は、.zshrc、.gitconfigあたりを管理しています。 ついでに、homebrewでインストールしたものもbrew bundle dumpで出力して、homeshickで管理することで、brewでインストールしたものの管理もできそう（参考）。\nってことで、至極かんたんでした。すばらしい。\n参考 homeshick Tutorials Qiita : homeshickを使ったdotfilesの管理 ","date":1576624266,"dir":"post/2019/","id":"80c8fca02ebfecc7a931dad1ec38466e","lang":"ja","lastmod":1576624266,"permalink":"https://blog.johtani.info/blog/2019/12/18/introduce-homeshick/","publishdate":"2019-12-18T08:11:06+09:00","summary":"ドットファイル系（.emacsとか）をこれまでは、PCを引っ越すたびにコピーしてたんですが、いいかげん、GitHubとかで管理したいなと。 で","tags":["misc"],"title":"homeshick導入"},{"contents":"Macbook Proが新しくなり、OSがCatalinaになっちゃいました。 これまで使ってた、.bash_profileをコピーしてターミナルを立ち上げたところ、 なんか色々と設定が動いてないな？と思ったら、zshがデフォルトに切り替わってました。\nということで、デフォルト変わったし、時間あるしzshってどんな感じなのか調べてみようと。\n準備前（ツイート） で、ツイートをしたところ、海外の方？より返信が来ました。\nI have a series of posts explaining the transition: https://t.co/dz8QNjxxGf\n\u0026mdash; Scripting OS X (@scriptingosx) December 10, 2019 おもしろそうなので、ざっくりと読んでみました。zshを利用されているTwitterの知り合いの何人かからはzsh + oh-my-zshがいいよとコメント頂いてたんですが、\nMoving to zsh Catalinaからzshがデフォルトになるからと、手元の環境を変更するための話をブログにまとめてくれてます。\nMoving to zsh\nサラッと読んだので、いくつか抜粋すると\nbashでいくつか今設定しているものがあるのでその説明 alias - ファイルをそれぞれの拡張子ごとにアプリを切り替えてる（openコマンドの利用例があって参考になりました）。 functions - manコマンドのときに新しいWindowひらいたりとか shell settings - 大文字小文字関係なくファイル名をTabで候補を表示したり、historyをターミナル個別ではなく共有できるような設定にしたり prompt - 現在のディレクトリがどこかとか表示したり zshの設定ファイル群の説明 shellオプションの抜粋 といった感じでした（途中で読むのやめましたが。。。）\n面白かったのは、Suffix Aliasesです。 ファイル名だけをターミナルで指定すると、拡張子に応じて起動するコマンドを切り替えたりできると（結局まだ採用はしてないですがｗ）\n結局？ 結局、上記ブログを読んでいろんなオプションあるんだなぁ。と思ったのですが、手っ取り早く試すためにPreztoをインストールしました。 以下のような構成になってます。\nなるほど、これがzsh + prezto + powerline fontか。前までgit-promptを拾ってきてbashに組み込んでたけど、ブランチ表示されるし便利だな。 pic.twitter.com/Z2ArBgRZey\n\u0026mdash; Jun Ohtani (@johtani) December 12, 2019 Mac標準ターミナル Iceberg プロファイル Powerline font Prezto agnoster theme - prompt agnoster or ~/.zpreztorc の変更 .zshrcにいくつかaliasなどを追加。参考:gist Preztoのデフォルトでlessなどからエディタを立ち上げるとnanoが起動したので、vimに変更 Preztoが作る設定と自分の設定を混ぜたくなかったので、.zshrcでinit.zshを呼び出し になりました。フォントサイズだけはちょっと大きくしました（老眼ェ。。。） ターミナルの参考にさせていただいたブログは「preztoでzsh構築した時のメモ 」です。\nターミナルソフト(余談？) terminalも人によっては、色んなものを使ってたなと思いツイートしました。 結構みなさん標準のterminalを使ってるみたいでした。ただ、私が聞いたこともないターミナルソフトもちらほらあったので、色々あるんだなぁと。\nMac標準のターミナル使ってる人ってどのくらいいるんだろ？iTermとか入れてるのかな？tmuxとか？\n\u0026mdash; Jun Ohtani (@johtani) December 11, 2019 ","date":1576542903,"dir":"post/2019/","id":"f3ef819656f68b87a91c53afbd441fec","lang":"ja","lastmod":1576542903,"permalink":"https://blog.johtani.info/blog/2019/12/17/move-to-zsh/","publishdate":"2019-12-17T09:35:03+09:00","summary":"Macbook Proが新しくなり、OSがCatalinaになっちゃいました。 これまで使ってた、.bash_profileをコピーしてターミナルを立ち上げ","tags":["misc"],"title":"zshへの移行"},{"contents":"最近使っていたPCが手元からなくなったので、16インチ Macbook Proをセットアップしているところです。 で、時間もあるのでこれまでほったらかしてきた、このブログの環境をちょっと変更しようかなと。\nまずは、変更するにしても、Octopressのブログの環境自体は必要です。 実際に、移行する前のこの記事自体も書いているわけですし。\nただ、今後なくなる環境をローカル環境にセットアップするのもどうかと思い、Docker環境にしてみました。\n参考 \u0026ldquo;Octopress Docker image\u0026quot;でググって出てきたサイトを参考にしました。\n参考ブログ：Octopress in a Docker Container\nセットアップからDockerイメージのビルドまで Docker for Mac自体もインストールしていなかったので、インストールしておきます。 参考ブログの方がGitHubのリポジトリにDockerfileをアップしてくれているので、手順に従い、cloneします。 cloneしたDockerfileの3行目にENV LC_ALL C.UTF-8を追加します（UTF-8でブログを書いており、previewした場合にエラーが出たため） 参考ブログにある「Build the docker image」の手順に従い、Gemfile、.gitconfigをコピーしてイメージをビルドします。 参考ブログの「Rakefile」にあるように、自分のoctopress/RakefileのProcess.spawn(...)にアドレスを追加します（Dockerコンテナの外からアクセスできるように） 自分のoctopressにあるGemfile.lockを削除しました（ビルドしたイメージにはいるGemと一部バージョンが異なる記載のものがあったため） ここまでで、\nDocker run 実際にコンテナを実行するためのスクリプトを書きました（書いたと言っても参考ブログにある起動コマンドを叩いてるだけですが。。。）\nlaunch-octopress-docker.shというファイル名で以下のコマンドを実行してるだけです。\n!/bin/sh docker run -p 4000:4000 --rm --volume /Users/johtani/projects/blog/octopress:/octopress --volume /Users/johtani/.ssh:/home/blogger/.ssh -ti blog/octopress /bin/bash このシェルを起動すると、Dockerコンテナにbashで接続し、/octopressディレクトリにログインしています。 あとは、いつものようにrake new_post[\u0026quot;....\u0026quot;]で新規記事のテンプレートを作成したりすればOKです。\nrake generate; rake previewと実行してからローカルのブラウザでhttp://localhost:4000に接続すればプレビューも可能。\nということで、このDockerファイルとかを持っておけば、他の環境でもかんたんにOctopressの環境が再現できそうです。 先人の知恵有り難し。 これで、クリーンなまま他のブログ環境に移行できそう。\n追記(2019/12/17) Docker環境でいくつか問題があったので、追記しておきます。\nDocker for Macが再起動しない Docker for MacがCatalina環境だと問題があるみたいでした。 CPUの数やメモリの数を変更してDockerを再起動したところ、ずっとStartingのまま。\n解決方法としては、launchctlの設定に$PATHを追加するみたい。これで、問題なく起動するようになった気がする\nsshの設定ファイルの問題 .ssh/configにMacのKeyChainを利用する設定を記載してるんですが、Ubuntu上だとこの設定のせいで、エラーが出てしまいます。 IgnoreUnknownという設定で、知らないオプションがあったら無視するという設定になる模様。ということで、Dockerコンテナ上でrake deployのときにエラーが出てたのが解消できました。\n","date":1576458061,"dir":"post/2019/","id":"1abc586d67f0b6c05fd5e60f25492340","lang":"ja","lastmod":1576458061,"permalink":"https://blog.johtani.info/blog/2019/12/16/dockernize-octopress/","publishdate":"2019-12-16T10:01:01+09:00","summary":"最近使っていたPCが手元からなくなったので、16インチ Macbook Proをセットアップしているところです。 で、時間もあるのでこれまでほったらかしてきた","tags":["octopress"],"title":"Octopress環境のDockerイメージ化"},{"contents":"本日、Elasticでの最終出社日でした。実際の退職日はまだ先ですが、有休消化という感じです。\n思い返せばもう5年と5ヶ月も前ですが、Elastic（当時はElasticsearchって社名だった）に参加しました。\n社名も変わりましたし、プロダクトの数も増えたし、IPOもしました。 初の外資＋スタートアップということもあり、ものすごくエキサイティングな5年半でした。 Elasticを離れはしますが、検索自体にはまだまだ興味があるので、LuceneやElasticsearchになにかしら関わる感じのことをする予定です。 検索技術勉強会も今後もやっていきますし。\nただ、激動の5年半だったので、退職日までちょっとゆっくりしようと思っています。 次にどんなことをするのかはまた、別の機会にでも。\nおまけ ということで、まぁお約束です。\nほしい物リストはこちら\n","date":1575615090,"dir":"post/2019/","id":"1bbf2ef67f096960e13d8578fa544536","lang":"ja","lastmod":1575615090,"permalink":"https://blog.johtani.info/blog/2019/12/06/leaving-elastic/","publishdate":"2019-12-06T15:51:30+09:00","summary":"本日、Elasticでの最終出社日でした。実際の退職日はまだ先ですが、有休消化という感じです。 思い返せばもう5年と5ヶ月も前ですが、Elas","tags":["転職"],"title":"退職します"},{"contents":"これは、情報検索・検索エンジン Advent Calendar 2019 の 4 日目の記事です。\n1日目から、質の高いエントリーが続いていましたが、一旦休憩して頂く感じの記事になってます。気軽に読んでくださいw。Advent Calendarつくらないの？と煽ったのもあり、穴を埋めようかなと。　発端 ちょっと先ですがこういうのやります。実装寄りの話やOSS開発に興味がある方，きてください～ / Lucene 版 #Kuromoji のコードを読む会（辞書ビルダー編） https://t.co/NgEmUohoPo #kuromoji\n\u0026mdash; Tomoko Uchida (@moco_beta) September 6, 2019 「Lucene 版 #Kuromoji のコードを読む会（辞書ビルダー編）」という勉強会があり、参加したところ、UniDicの辞書のビルドがコケるという話を聞いたんで、ちょっとやってみるかと。\nちなみに、Kuromojiとは、Apache Luceneに入っている、日本語向けの形態素解析ライブラリです。IPAdicの辞書を内包しており、SolrやElasticsearchといった、Apache Luceneを利用している検索エンジンで手軽に使える形態素解析ライブラリになっています。が、対応している辞書がデフォルトだとIPAdicなのです。\n問題点 LUCENE-4056というIssueが上がっています。\nbuild.xmlには記載はないけど、辞書のビルダーは対応していそうな雰囲気を醸し出しているので、試してみたというのが発端？かと。で、実際に動かしてみると動かない点がありましたと。\nまた、Issueの会話で出ていたUniDicの辞書のライセンスの話もありました。 ただ、UniDicがライセンスを変更したので、このあたりはクリアできそうかなと。\nパッチ ということで、動かしてみていくつか修正してパッチを作りました。\nhttps://github.com/apache/lucene-solr/pull/935\n最近のLuceneはGitHubでプルリク遅れるのが便利ですね。 そんなに大したことはやってないです。以下の点が問題だったので直しています。\nIPAdicとUniDicで語彙定義ファイルのCSVの形式（カラムの数）が異なる unk.defのカラム数も異なる あとは、辞書のダウンロードの部分やbuild.xmlでの処理を追加した形です。 このプルリクを適用したlucene-solrのソースディレクトリを持ってきて、手元でjarをビルドすれば普通はIPAdicの辞書を内包したkuromojiのjarファイルが出来上がります。\nlucene/analysis/kuromoji/build.xmlファイルを、このGistにあるように変更して、ant build-dictとやれば辞書のビルドが可能です。 また、cd lucene/;ant jarとすれば、UniDicの辞書を内包したjarファイルもビルドできます(lucene/build/analysis/kuromojiの下にjarファイルができあがります)。\n確認？ 一応、パッチは動くのですが、パッチ自体はUniDicの辞書をビルドする仕組みはオフのままです。なので、テストをどうやろう？というところでやなんで止まっています。。。\nただ、実際に作ったパッチできちんとIPAdicとUniDicがそれぞれビルドできているかの確認はしないとなと。\nということで、2つのjarファイルを読み込んで、それぞれトークナイズして、その出力を表示するツールを作ってみました。\n上記パッチを適用したlucene-solrのソースを持ってきて、IPAdicの辞書を内包したkuromojiのjarファイルと、UniDicの辞書を内包したjarファイルを用意し、ツールの支持に従って、ファイルをディレクトリに配置して、実行すれば以下のような出力がされるようになっています（とりあえず作ったものなので、Javaファイルにトークナイズしたいテキストを書かないといけないのですが）。\nたとえば、「自転車と自動車の違いはなんでしょう？」という文字列を入力すると、以下のような出力になりました。\n+++ ipadic ++++++++++++++ token[0] is [自転車] token[1] is [と] token[2] is [自動車] token[3] is [の] token[4] is [違い] token[5] is [は] token[6] is [なん] token[7] is [でしょ] token[8] is [う] +++ unidic ++++++++++++++ token[0] is [自転] token[1] is [車] token[2] is [と] token[3] is [自動] token[4] is [車] token[5] is [の] token[6] is [違い] token[7] is [は] token[8] is [なん] token[9] is [でしょう] UniDicは[短単位]で語彙が扱われるため、「自転車」や「自動車」がそれぞれ「自転」「車」、「自動」「車」という形でトークナイズされていることがわかります。\nどちらがより便利なのか？というのは用途によっても変わってくるかと思いますが、検索の転置インデックスとしては、より短い単語で区切られている方が、より多くの文書にヒットする可能性が高くなるので、便利な可能性が高いです。\nまとめ ということで、パッチを作ってみたものの、まだ取り込まれていない状況です。 着地点をどうするかって話かなと思っています。興味があれば遊んでみていただければと。\n将来的には、辞書をjarから切り離して別のディレクトリやjarとして使えるようにしようというIssueも作られています。こちらがすすめば、UniDicだけでなく、その他の辞書を切り替えながら使えるようになる日が来るのではないでしょうか？\n","date":1575385200,"dir":"post/2019/","id":"c2d39f2f7fe6cb69fc8efb6c5495c932","lang":"ja","lastmod":1575385200,"permalink":"https://blog.johtani.info/blog/2019/12/04/about-lucene-4056/","publishdate":"2019-12-04T00:00:00+09:00","summary":"これは、情報検索・検索エンジン Advent Calendar 2019 の 4 日目の記事です。 1日目から、質の高いエントリーが続いていましたが、一旦休憩して頂く感じの記事になって","tags":["Lucene"],"title":"Apache LuceneのKuromojiのUniDicビルド対応パッチについて"},{"contents":"Elastic stack (Elasticsearch) Advent Calendar 2019の1日目の記事になります。\nまだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみようと思います。毎年恒例ですね、ここ数年。\nElastic Stack 6.6.0リリース(1月) リリース記事はこちら\nElastic APMが6.6のリリースと同時にElastic CloudでAPM Serverが無料で利用できるようになったのが地味に便利でした。APMのデモをやるために、それまでは手元にAPM Serverの起動が必要だったので。。。\nユーザーの方たちにはIndex Lifecycle Management（インデックスライフサイクル管理：ILM）がリリースされたのが便利だったと思います。 まだ、ベータでしたが、インデックスの世代管理を格段に便利にしてくれるツールになり、現在では必須アイテムとなっています。 もう一つ、地味に便利なのは、KibanaからElasticsearchへの接続を複数指定できるようになった点かと思います。\nElatic Common Schemaのベータリリース(2月) リリース記事はこちら\nElastic Stackではメトリック、APM、ログなど、様々なデータを一元的に可視化することができるという利点があります。ただ、一元的にデータを可視化、検索するためには異なるデータセットに統一されたフィールド名が欠かせません。そのための手段としてElasticが公開したのがElastic Common Schemaです。 各種データの項目名、型などを共通化する仕様をGitHub上で公開しています。最近のBeatsのモジュールはこのElastic Common Schemaに則ってデータが定義されるようになってきています。これにより、ログからメトリックへ、APMからログデータへというシームレスな移動ができるようになっています。\nElastic Stack 6.7.0リリース(3月) リリース記事はこちら\nElastic MapsやUptimeといった、これまでの可視化とは異なる便利なアプリが増え始めました。Mapsでは地図の表現が格段にアップしたので、コレまで以上に地理情報と合わせた可視化が楽しくなりました。\nもちろん、基本的に必要な技術が着実にGAされていくのもElastic Stackの素晴らしい点です。\nIndex Lifecycle Management(ILM)がGA Cross Cluster Replication(CCR)がGA CanvasがGA Logs \u0026amp; Infra UIがGA Elastic Stack 7.0.0リリース(4月) リリース記事はこちら\nメジャーバージョンのリリースです。 KibanaのUIが刷新されたり、Elasticsearchのクラスター管理の機能が新規に構築されたり、様々な改善がこのリリースでも入っています。また、メジャーバージョンのリリースのタイミングが、さまざまな大きな仕様の変更や改善が入るタイミングでもあります。これまで以上にパフォーマンスが改善（Top-Nクエリ高速化など）されたり、新しい機能の追加（ナノ秒のサポート）されたりしました。\nElasticsearchのセキュリティの主要な機能が無料に(5月) リリース記事はこちら\n6.8.0および7.1.0のリリースはこの機能の無償提供となりました。 結構衝撃的な話だったのではないかなぁと。これ以前は有償の機能だったセキュリティの以下の機能をElastic License配下で無料で提供する形に変わりました。まだ、ご存知でない方は、データの安全のためにもセキュリティ機能を利用することをおすすめします。\nTLSによる通信暗号化 ユーザー作成と管理にファイルおよびネイティブのレルム認証を使用可能 クラスターAPIとインデックスに対するユーザーアクセスの管理にロールベースのアクセス制御を使用可能、またSpaces機能でKibanaのマルチテナンシーの安全性を向上 Elastic{ON}19開催(5月) 今年も東京で開催しました。ビデオなどはこちらで公開されています。 https://www.elastic.co/elasticon/tour/2019/tokyo\n今回も偉そうにElatic Stackの新しくなった点を紹介するなどしてました。。。\nElastic Stack 7.2.0リリース(6月) リリース記事はこちら\nElastic SIEMがベータリリースされたのがこのタイミングです。 2月の発表したElastic Common Schemaをフルに活用していると言ってもいいのがこの機能になります。まだ今後もどんどん改善が入るであろうきのうになります。\nまた、Elasticsearchをバックエンドにした検索ミドルウェアとして利用いただけるElastic App Searchのセルフマネージド版もこのタイミングでリリースされています。\nさらに、このリリースの直前にはElastic Cloud on Kuberunetes(ECK)というものベータリリースされました。少しわかりにくいかもですが、ElasticsearchやKibanaをKubernetesのOperatorとして利用できるようになっています。こちらもElastic Licenseでリリースされているのでk8s上でKibanaやEsを管理しようとしている方は触ってみると面白いかもです。\nElastic Cloud Elasticsearch ServiceがGCP日本で利用可能に(7月) リリース記事はこちら\nElastic Cloudもプラットフォームが拡大した年でした。 Google Cloud Platformの東京リージョンを選択できるようになりました。さらなる統合（支払いをGCP経由にまとめたり、GCPのコンソールから利用できたりなど）も進んでいます。\nElastic Stack 7.3.0リリース(8月) リリース記事はこちら\nデータフレームと呼ばれるデータ取り込み時のピボット機能が導入されました。また、MapsのGAリリース、Elastic APMの.NETエージェント正式リリースなど、細かいですが様々なものがリリースされています。\nElastic Cloud Elasticsearch ServiceがAzureで利用可能に(9月) リリース記事はこちら\nMicrosoft Azureへのデプロイも可能になりました。残念ながらまだ日本リージョンには来ていないですが、今後出てくるはずです！さまざまなクラウドベンダーのサポートにより、より多くの人に使っていただけるようになるのかと。\nElastic Stack 7.4.0リリース(10月) リリース記事はこちら\nもう7.4.2まで出ていますが、いい感じの間隔で7.0、7.2、7.3と来ていますね。 7.4では、スナップショットリストアがKibanaから簡単に行えるようになりました。これまではKibanaのConsoleでJSONを見ながら管理されていたかもですが、GUIにより今どんなスナップショットがあるのか、どれをリストアするのかといった操作が簡単にできるようになっています。\nKibanaについてはPKI認証のサポートなども始まり、様々な認証方式でより便利にKibanaが使えるようになっています。\n12月？ 12月ですし、Elasticsearch勉強会では「LT＆忘年会」ということで、懇親会がメインの勉強会として12/6に開催します。悪路クエストの緑川さん、吉岡さんに主体となっていただき、マイクロソフトさんを会場に借りて開催予定です。興味のある方はぜひご参加ください。 LTもおまちしています！\nまとめ 駆け足でしたが今年を振り返ってみました。 今年も色々ありました。残すところあと1ヶ月です！\nさて、Elastic Stack Advent Calendar 2019は今日から25日まで続きます。今年はその2もできています！こらからの記事を楽しみにしています！ 本日はその2で[kaibadash@github]さんが「5分でできるElastic stack環境構築」というのを書いてくれてるはずです！\nということで、次はKunihikoKidoさんの「 Elastic Cloud を使うようになって設計方針やら変わったことについて書きます。」になります。お楽しみに！\n","date":1575126000,"dir":"post/2019/","id":"78da47d61c91c82809a3c97a791d26d2","lang":"ja","lastmod":1575126000,"permalink":"https://blog.johtani.info/blog/2019/12/01/whats-happen-at-elastic-in-2019/","publishdate":"2019-12-01T00:00:00+09:00","summary":"Elastic stack (Elasticsearch) Advent Calendar 2019の1日目の記事になります。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみようと思います。毎年恒例ですね、","tags":["elasticsearch"],"title":"2019年のElastic StackとElastic"},{"contents":"Bonfire Data \u0026amp; Science #1にブログ枠で参加してきました。 ということで、メモです。\n日時 : 2019/10/25 19:00 - 21:30 場所 : Yahoo! Japan サイト : https://yj-meetup.connpass.com/event/148121/ ハッシュタグ: #yjbonfire 概要 Data \u0026amp; Scienceとは？ データとサイエンスに関わる人達の情報共有のための勉強会/交流会\nサイトから引用です。\n第1回のテーマは「画像検索」です！ 最近EC系のサイトで類似画像検索が出来るようになったけどどうやってるの？ 画像検索のモデルってどうしてるの？ 画像検索のインフラはどうしてるの？ 私たちの会社でも画像検索を用いたサービスを構築できるだろうか？ こういった疑問に答えたり、いま抱えている悩みを解決するヒントを得る場になればと思っています。 今回は、画像検索を行なっているヤフー, メルカリ, ZOZOテクノロジーズの3社に事例と基盤技術について登壇いただきます。 QAはこちら。https://app.sli.do/event/w3wayjmv/live/questions\nMercari画像検索について(仮) 発表者：荒瀬晃介(株式会社メルカリ / AIエンジニアリングチーム)\nAIエンジニアチーム\n写真検索プロジェクトのTech Lead\niOSのみで提供の写真検索\nシステムオーバービュー\nMobileNet v2で特徴抽出 ANNのインデックスを使ってDBに入れる 論文も発表済み（3本）\n今日の発表はこの内の2本を元に話をします。 C2Cでの問題点 商品は床やテーブル上で撮影 クエリは着用（着ている）画像が使われやすい。 人が写ってる写真が結果に多いと業者が出展しているように見えてしまう。 提案手法 人が写ってるものから人の代表ベクトルを抜き取る (クエリ時にのみ処理を実施しているので変更が容易) 特徴変換ベクトル トップスなど、分類ごとに学習させてからベクトルを構成 なんでMobileNet v2? エッジデバイスでの処理を見据えて選択 インフラ Docker + k8s\nCRDを使ってる？\ntraining\nコンテナベースパイプライン いくつかのバッチ処理を工程ごとにパイプライン化 バッチ実行情報をカスタムリソースとしている＝再実行が簡単（復旧作業が容易） 画像を扱う＝ダウンロードが時間がかかる -\u0026gt; 復旧しやすいようにPVにある程度キャッシュさせている Serving\u0026hellip;\nGCP側 なぜ2つに別れてるんだろう？実際のサービスも2つに分かれてたりするんだろうか？\n将来の展望 Realtime Image Search カメラでものを写している状態でそれが何かを検索できる。 物体検出＋特徴抽出をエッジで行うためできる エッジの性能により違いが出てきたりするっぽい QA Q: 業者が想定されると、購入意欲を下げるというのは実験した結果？それとも想像？ A: 実験はしていないが、e-commerceにおいての研究がある Q: どういう理由でマルチクラウドにしたんでしょう? A: 画像のマスターがAWS。メルカリのマイクロサービスはGKEなので、サービング環境がGCP Q: 画像の内、服のエリアが大部分で体の面積が少ない場合と、メガネや帽子のように、アイテムの方の面積が少ない場合で、トレーニングに必要なデータ数は変わりましたか？ A: カテゴリによる性質の違うはある。ので、改善は必要。 ZOZO画像検索について(仮) 発表者：平田拓也(株式会社ZOZO / AIエンジニアリングチーム)\n(聞き逃した。。。)\nWEAR\nマルチサイズ\nチーム構成 研究所＋ML Opsチーム 使用しているアルゴリズム 物体検出アルゴリズム 特徴量抽出アルゴリズム 近似最近傍探索（approximate nearest neighbor, ANN） インフラ GCPを採用。 BigQuery上にデータ基盤がある Managed GPUが必要 なんでk8s? コンテナ Cloud Runがなかった アーキテクチャ マイクロサービス化されている Google Cloud Next 2019 Tokyoでsonotsさんの発表があるよ 監視項目 CPUなどは見ていない レスポンスタイムとステータス監視 リクエスト数 APM 使ってるものStackdriver + Datadog + Sentry Warningが30分で続けたら通知などができるのがStackdriver 画像検索の改善のためにやっていること 課題 レイテンシーが大きい 推論が大変？ 急激なトラフィックの増加に対応できない GPUのスケールアウトが問題 -\u0026gt; 先行投資が必要 流れ キャッシュありなし 物体検出 (GPU) 特徴量抽出 (GPU) 近似最近傍探索 DBから取得 2と3が問題\n2と3を特徴量DBという形でデータが登録された時点で特徴量などを計算してしまうことでGPUへの依存をなくした。 Apache AirFlowが便利？ Cloud ComposerとApache AirFlow Cloud Composerに関するいくつかのTipsがありました。\nQA Q: 推論をCPUでやったらどれぐらい遅いんだろう A: GPUインスタンス代金 \u0026lt; それと同等の速度を出すためのCPUインスタンス代金 Q: k8sスケールアウト時のリソース割当を最適化する為、resource limit / request標準化 or 時系列分析などから自動調整するなどはされていますか？ A: \u0026hellip;聞き逃した Q: (TCOを考慮したクラスタ構成) Cloud Composerの値段が高いようなパプリッククラウド利用の課題対策としてプライベートクラウドとのハイブリッド構成にされているのでしょうか？もしハイブリッド構成でしたら、パブリック or クラウドを切り分ける基準はございますか。 A: GKEオンリー Q: cloud composerでairflowを使う辛い点は？ A: 不安定さ。。。 Yahoo!ショッピングにおける画像検索(仮) 発表者：佐藤 純一(ヤフー株式会社) 商品検索APIの開発とか検索エンジンの保守とか 類似画像検索システムの開発が直近の仕事 類似画像検索 ヤフーショッピング 3億の商品 ファッション系はビジュアルが重要＝言語による表現が難しい iOSとAndroid Androidだとカメラで撮影してから検索みたいなことも可能 システム概要 物体検出 ノイズ除去 特徴抽出 インデックス(NGT) -\u0026gt; https://github.com/yahoojapan/NGT 1000万件を超える 検索 アプリの画像をAPIに投げてベクトルから、近いものn件を取得 ベクトル化/インデックス更新 GPUマシン Kafka使ってる クラウドストレージに日次？バックアップみたいに保存 差分更新の仕組みがある メンズとレディースは分けている 絞り込み検索のために分離（インデックスのメタデータとしてタグがある） システム構成 Python Kafka TensolflowServing 可視化？監視？はGrafana＋Prometheus 開発を通しての学び 自動デプロイとかテスト 検索精度の確認ツールを作る コレ重要だよね。何が変更してるかとか、何が正しいかってのが必要だし。。。 復旧可能、早期復旧の仕組みを容易 今後の方針 対象商品の拡大 物体検出特徴抽出モデルの性能改善 NGTの検索システムをValdに移行 Vald k8s上で動作、分散検索、分散インデキシングなどの機能を提供予定 QA Q: iOS(既存の画像)とAndroid(カメラで撮る)で画像検索の方式が違うのはなぜ？ A: アプリの違い Q: 1枚の写真に沢山写っている中で、対象の商品をどう識別しているんでしょう。靴もトップスもボトムスも写っていたら、かなり難しそう A: Yahooブラウザの場合は1番大きな領域のものを選択。Yahoo shoppingだと選択可能 NGTについて(仮) 発表者：岩崎 雅二郎(ヤフー株式会社) 類似画像検索を20年くらいやってる 近傍検索ライブラリ https://github.com/yahoojapan/NGT\n高次元ベクトルの近傍検索 ツリーとグラフによるインデックス 近傍検索とは?\n距離空間上でのクエリの近傍のオブジェクトを取得 k最近傍検索（通常はこっち） 範囲検索（あんまり使われない） NGTの特徴\n世界トップレベルの高速高精度な近似近傍検索 OSS 追加削除が可能（削除がとくに難しいらしい） 多様な利用形態（Python、C++、C、Go、コマンドライン） サーバ版NGT（ngtd、vald）を提供 共有メモリ版でメモリサイズ以上のデータ登録可能 量子化版NGT（NGTQ）により。。。 ANNベンチマークによりテスト\n実行環境が決められているらしい。誰が実行しても比較可能 グラフベースの検索の仕組みのほうが性能がいいというのがベンチマーク結果からわかる なんではやいの？ インデックス生成 ツリー（グラフの探索起点の取得に利用する。DVP-tree） グラフ（ANNG） ノードを逐次追加しつつ、近傍ノードを検索してから接続するというのを繰り返している 検索 ツリーから絞り込みつつ、グラフを検索する ANNGに課題があるのでONNG（Optimized Nearest Neighbors Graph）に ノード単位の次数（入出）を最適化 データセットによって有効な次数が違う。。。 NGTを利用した深層学習で。。。 Yahoo!ラボ FavNavi 特徴量の構成（低次特徴量（300次元）、カテゴリ特徴量（128次元）、領域アスペクト比（1次元）） 個別の特徴量だけだとイマイチな結果になるが、組み合わせるといい感じになる モデル性西洋学習データ スライドがあればいいなぁ（表書くの大変だし。。。）\nQA Q: 実際のお客さまの利用を考えると、近似近隣の密度が異なるので、近いものばかりの検索結果や遠いものも含んでしまった検索結果が出ると思うのですが、遠いものが含まれてしまうと、閾値でフィルタしたりするのでしょうか? A: NGTは近いものしかないので、外れ値ってなんでしょう。。。 検索のフィルタリングをある程度している（カテゴリとか）。 まとめ 慣れない分野の話を聞きながらざっとメモを取ったものなので役に立つかはわかりませんが。。。\nアルゴリズムとかまでは得意ではないんですが、画像「検索」ということで参加してみました。 実際に画像検索の仕組みがどんな感じでできているのか、どんな技術がつかわれているのか？ってのがわかったのは 面白かったです。確かに検索のためのキーワードって出てこないことあるしなぁと。 あー、こんなかばんほしいとか、これなんだろ？みたいなのあるからなぁ。\n","date":1572000002,"dir":"post/2019/","id":"11b3a28b536f34d3606427f835bd3ddf","lang":"ja","lastmod":1572000002,"permalink":"https://blog.johtani.info/blog/2019/10/25/bonefire-01/","publishdate":"2019-10-25T19:40:02+09:00","summary":"Bonfire Data \u0026amp; Science #1にブログ枠で参加してきました。 ということで、メモです。 日時 : 2019/10/25 19:00 - 21:30 場所 : Yahoo! Japan サイト : https://yj-meetup.connpass.com/event/148121/ ハッシュタグ: #yjbonfire 概要 Data \u0026amp; Scienceと","tags":["勉強会"],"title":"Bonfire Data \u0026 Science #1に参加しました"},{"contents":"この間のElasticsearch勉強会でAcroquest Technologyの人たちが技術書展7で販売されていた書籍を頂いてしまいました。なので、軽く読んでの感想と宣伝です（これ、電子版とかで買えないのかな？）。\nElasticのパートナーとしても活躍していただいてますが、こういう感じでさまざまなところでElastic Stackを広めていただいていて感謝しかありません。\n章立てとしては以下の通りです。\nElasticsearchでエンタープライズサーチを実現する 同僚が作成、メンテナンスしているFSCrawlerを使った例も書かれています。ローカルのファイル（PDFやJSONとか）をサクッとElasticsearchにインストールしたりするのには便利です。 Kibana Canvasによる柔軟な可視化 Canvasについてどんなものなのか？というのとelasticcofeeというサンプルを元に、その変更の仕方などが説明されています。 Elastic APMによるアプリケーションパフォーマンス監視 Go AgentとAPM自体の使い方の説明です。最近強化されている他の機能との連携（AlertingやMachine Learning）についても触れてくれています。 Kubernetesクラスタのメトリクス・ログ・性能情報の可視化 Azure上でAzure Kubernetes Serviceの上で動いているアプリなどをBeats、APMでデータを取りつつ、他のAzure上にAzure Marketplaceのテンプレートを用いて起動したElasticsearchとKibanaの環境を用いて可視化する方法が説明されています。 ということで、薄い本ですが、手順をおって説明されていたり、7.3と新しいバージョンで書かれているのですばらしいなぁと。 前作の「Elasticsearch NEXT STEP」に引き続きインプレスさんから出たりするのかなぁ？\nちなみに、Elastic APMのRubyに関して興味がある方は、私が前に発表したときの資料がありますので、こちらを参考にしてみてください。\n","date":1570690589,"dir":"post/2019/","id":"d8041ae308961666b15aa1e57b0f9f35","lang":"ja","lastmod":1570690589,"permalink":"https://blog.johtani.info/blog/2019/10/10/review-es-next-step-2/","publishdate":"2019-10-10T15:56:29+09:00","summary":"この間のElasticsearch勉強会でAcroquest Technologyの人たちが技術書展7で販売されていた書籍を頂いてしまいました","tags":["書籍"],"title":"Elasticsearch NEXT STEP 2を頂きました"},{"contents":"Twitterで「Meetup.comに切り替えたらー」みたいな話があったので、 受付用アプリとかなくてという話になったので、普段Elasticsearch勉強会で使用している QRコード生成の仕組みを紹介してみようかと。\nHTMLだけで済むようにQRコードを生成するjquery.qrcode.min.jsってのを使用してます。\nHTMLコードはこちら。\n仕組み 1枚だけのHTMLを生成 MeetupのOAuth2の仕組みを利用(consumer keyを発行する必要あり。) Meetup APIを利用してユーザー情報取得 取得したユーザー情報をGoogle Formに埋め込んだ形で表示するURLを組み立てる 組み立てたURLをQRコードにしてHTMLに表示 受付で、QRコードリーダーを使って、QRコードを読み込むとGoogle Formが開くので、「送信」ボタンを押す 1. HTMLの作成 QRコードを表示するためのHTMLを作成します。Gistに貼り付けてあるので、参考にしてもらえれば。 いくつか埋め込まないといけないものがあるので、個別にそれは説明します。\n2. Google Formの準備 Elasticsearch勉強会では、出席者の情報として、IDと氏名をリストとして保存しています。 目的としては、何人実際に参加したかを計測するのが目的です。 ですので、参加者リストのGoogle Formを作成します。 で、作成した後に、プレビューを表示する。こんな感じ。\nこの時のプレビューのURLをQRコードのURLとして使いたいので、このURLをQRコード表示のHTMLに埋め込みます。\nfunction createGoogleFormURL(data) { var obj = { \u0026#34;entry.1744035444\u0026#34; : data.id, \u0026#34;entry.2031666715\u0026#34; : data.name }; return \u0026#34;https://docs.google.com/forms/d/e/\u0026lt;GOOGLE_FORM_ID\u0026gt;/viewform?\u0026#34; + $.param(obj); } ここら辺です。 returnに書いてあるhttpsで始まる文字列をまず、先ほどのURLで置き換えます。 次に、プレビューのHTMLの中から\u0026lt;input\u0026gt;タグを探して、nameの値を抜き出します。 それをobjのキーに利用します。entry.で始まる文字列が該当します。\nこれで、このURLをQRコードにすれば、値（ここだとIDと氏名）が埋め込まれた形のGoogle Formがスマホのブラウザで起動します。\n3. Meetup APIの準備 MeetupのAPIを利用できるようにします。Meetup.comにログインするとみれるAPIのページがあります。 https://secure.meetup.com/meetup_api\nまず、OAuthを利用するためのConsumer Keyを発行します。\nメニューのOAuth Consumersをクリックして、\n\u0026ldquo;Create New Consumer\u0026quot;をクリックします。 すると、次のような画面が開きます。\nConsumer nameとRedirect URIが重要です。\nConsumer nameはユーザーがMeetup経由で認証するときに、その認証画面で表示される名前になります。 わかりやすい名前を表示してあげると良いかと。\nRedirect URIが一番重要です。実際にOAuthで認証が通った後に表示するHTMLを提供しているURLを指定します。 Elasticsearch勉強会の場合は、私のドメインにwwwをつけた\u0026quot;https://www.johtani.info\u0026quot;を指定しています。 実際にQRコード表示用のHTMLを配置するHTTPサーバーのトップのURLを指定します。 （ちなみに、私のウェブサーバーはS3で運用してます。ですので、HTMLをS3のバケットにアップロードしてあるだけです）\n必須項目を入力したあと、最下部にあるRegister Consumerボタンを押せばキーが生成されます。 生成されたキーがOAuth2のURLのパラメータに必要になります。\nこれで、リダイレクトの準備が整いました。\nOAuth2のURLには、Implicit Flowを利用します。 これで、リダイレクト先のHTMLにトークンがわたるので、Meetup APIにこのトークンが使えるようになります。\n認証用のURLはこちらです。このURLを参加者宛のメールに入れて毎回送信しています。\nhttps://secure.meetup.com/ja-JP/oauth2/authorize?response_type=token\u0026amp;redirect_uri=\u0026lt;QRコード表示HTMLのURL\u0026gt;\u0026amp;client_id=\u0026lt;コンシューマーキー\u0026gt; 参加者はこのリンクをクリックすることで、次のような画面が出てきます。 ログインしていない場合はLog in画面が表示され、まずはログインを促されます。\nで、Allowをクリックすれば、redirect_uriに指定されているページが表示されるわけです。\nQRコード表示用のHTMLでは、次のAPIを使用して、ログインしているユーザーの情報を取得してきています。\nfunction getMemberId() { $.getJSON(\u0026#39;https://api.meetup.com/2/member/self/?only=id,name\u0026amp;access_token=\u0026#39;+ getToken(), displayQRCode); } ここで取れた値が、先ほどの「2. Google Formの準備」で説明したコードのdataの部分に渡ってくるわけです。\nfunction createGoogleFormURL(data) { var obj = { \u0026#34;entry.1744035444\u0026#34; : data.id, \u0026#34;entry.2031666715\u0026#34; : data.name }; return \u0026#34;https://docs.google.com/forms/d/e/\u0026lt;GOOGLE_FORM_ID\u0026gt;/viewform?\u0026#34; + $.param(obj); } 4. QRコードの表示 あとは、jquery.qrcode.min.jsを使用してURLを表示するだけです。\nfunction displayQRCode(data) { $(\u0026#39;#qrcode\u0026#39;).qrcode({width: 128,height: 128, text:createGoogleFormURL(data)}); } サイズとURLを指定するだけですね。\nまとめ あとは、受付で、参加者の方が表示してくれたQRコードをスマホのQRコードリーダーやカメラで読み込めばGoogle Formが開いて必要な情報は入っているので、「送信ボタン」を押せば参加者リストが出来上がっていくという形になります。\n毎回勉強会の前日に、前回のGoogle Formを「コピー」してから、各回の勉強会の登録者フォームを作成しています。 コピーすることにより、Google Formの\u0026lt;input\u0026gt;タグに使用されるnameもそのままコピーされるので、 QRコード生成用のHTMLを書き換える部分の手間が減る形になっています（気づくまで数回かかったw）。\nですので、QRコードのHTMLの中身としては、「勉強会のページへのリンク」、「Google Formへのリンク」の2つを書き換えてから毎回アップロードしているだけとなっています。\nこのやり方が、スマートかどうかはわからないですが、受付アプリがない中、Meetup.comから取得した参加者リストのExcelやプリントアウトしたリストを元に参加者をチェックするよりは、手間が省けてるんじゃないかなぁと。\n残念ながら、QRコードの存在を知らないでそのまま勉強会にくる人がいるので、受付で最低一人はMeetup.comの参加者リストから、 名前を検索してチェックするという作業もやってもらってます。 QRコードを持ってきた方がすんなり受付を通過できるようになってますので、ぜひQRコードを持って勉強会にきてもらえればと。\n","date":1560939044,"dir":"post/2019/","id":"d96f80f23543850a2ee9fff8cd2cc53f","lang":"ja","lastmod":1560939044,"permalink":"https://blog.johtani.info/blog/2019/06/19/qr-code-with-meetup-dot-com/","publishdate":"2019-06-19T19:10:44+09:00","summary":"Twitterで「Meetup.comに切り替えたらー」みたいな話があったので、 受付用アプリとかなくてという話になったので、普段Elasti","tags":["勉強会"],"title":"勉強会の受付自作？アプリ？HTMLについて"},{"contents":"Elasticsearch勉強会や検索技術勉強会やってるんだけど、独学で勉強会やってるなーと思い、みんなはどうやってるんだろうとツイートしてみたところ。\nあー、勉強会運営座談会したい。\n\u0026mdash; Jun Ohtani (@johtani) 2019年4月2日 面白そう\n\u0026mdash; 機械の体を手に入れるのよ鉄郎 (@tetsuroito) 2019年4月2日 やってみるか。\n\u0026mdash; Jun Ohtani (@johtani) 2019年4月2日 やりましょう\n\u0026mdash; 機械の体を手に入れるのよ鉄郎 (@tetsuroito) 2019年4月2日 ってことで、何人か釣れたので、勉強会運営座談会をやってみました。 会場提供していただいた、Classiさんありがとうございました！\n参加してくれた人たちはまぁ、勉強会のサイトを見ていただければなんとなくわかるかなと。 自己紹介とどんな勉強会、読書会運営してますってとこから始めて、次のようなトピックについてピザ食いながら3時間くらい話しました。\nスピーカーの募集方法 運営側から声かけてる？それとも公募してる？ 登壇時間とかどうしてる？ スピーカーになってもらうためになんかやってる？ スケジュール管理 会場探し、スピーカー探し、イベントページ作るタイミングは？ 複数拠点開催したことある？ ハンズオンとかはどうしてる？ 土日開催？平日開催？ アンケートとってますか？ 使用してるイベントサイトは？ ドタキャン対応どうしてる？出欠とったりしてる？懇親会の規模とかどうやって見積もってる？ 運営費用関連はどうしてる？ グッズとか、ツールとか、スピーカーへの謝礼とか 運営って複数でやってる？ その時のツールは？ 運営メンバーにはどうやってなってもらう？ 録画配信とかまで手が回る？ 会場探すの大変じゃない？ 会場の部屋の使い方はどうしてる？ 行動規範とかどうしてる？ 読書会の場合に人が減ってったりしない？ まぁ、こんな感じです。色々話してメモしてたんですが、まぁトピックくらいで。\nそもそもは、勉強会の運営って本業ではない（はずな）ので、いかに楽をしつつうまく運営できるかってのを知りたいのと、 他の人どうやってるかってのからアイデアもらえるといいなーと思ったんでやってみました。 他のツールがどんなものかとか知れたし、あー、そういうやり方すればいいのねーみたいなのも知れたので、次回以降の勉強会に活かせればなーと。 自分がやってるやり方とかもブログ書くといいのかなぁ？\n残念です！次回もやるかもしれないので、 @johtani さんに期待してください！\n\u0026mdash; 機械の体を手に入れるのよ鉄郎 (@tetsuroito) 2019年4月25日 次回やるのかなぁ？興味ある人いるのかなぁ？\n","date":1556204526,"dir":"post/2019/","id":"538e38fbc3f78cd61e1841d8141ddcc1","lang":"ja","lastmod":1556204526,"permalink":"https://blog.johtani.info/blog/2019/04/26/meetup-organizer-drinkup/","publishdate":"2019-04-26T00:02:06+09:00","summary":"Elasticsearch勉強会や検索技術勉強会やってるんだけど、独学で勉強会やってるなーと思い、みんなはどうやってるんだろうとツイートして","tags":["勉強会"],"title":"勉強会運営座談会ってのをやってみた"},{"contents":"どーも、johtaniです。\nSearch Engineering Tech Talkという勉強会に運営として参加して、第1回の勉強会を開始しました。 本日（2/26）は第1回目だったので、ブログを残しておこうかと。\n勉強会自体の資料については第1回の勉強会のページにあるし、勉強会の感想とかブログはツイートやみんながブログを書いてくれると思うので、勉強会開催の経緯などについてブログを残しておこうかと。\nなんで始めたの？ 私自身が古くはFAST Searchに始まり、何か縁があって、 検索のシステムに長く携わってきたこと（Apache Solrの本書いたり、Elasticsearch勉強会始めたり）もあり、 検索が面白いなと日々思ってます（思ってるだけかもしれないが）。\nで、これまでElasticsearch勉強会をやっているのですが、検索エンジン固有の話ではない、 いわゆる検索の共通の課題というのがあるなぁと。 そういう課題やノウハウって、製品に限らず共有できれば面白いことがもっとできるんじゃないだろうか？ と感じることが多々ありまして。 オープンソースのコミュニティをソースコードをベースではなく、共通の課題・話題を中心としたコミュニティが あってもいいんじゃないかなぁと。\nまぁ、要は、私がみんなの検索で困ってることとか、どうやって検索システム考えてるのかが聞きたかったわけですよ。\nということで、一人でやっても面白くないので、興味ありそうな人を募ってやってみようということを始めたのが2018年12月くらいです。\n運営とかどうしてるの？ まずは、共同主催者（コアメンバー）を募集してみようということで、Googleフォーム作って、 興味ありそうな人がいる場所に投稿してみました。（TwitterとかFBとか） で集まったのが今回紹介したメンバー（スライド参照）です。 ユーザー企業の人もいれば、私みたいな検索エンジンの人もいるので面白い感じにできたかなぁと。 で、スピーカーを運営や知り合いに声をかけて第1回をやってみたという感じです。\n今後どうするの？ 残念ながら次回はまだ未定です。 2ヶ月に1回くらいのペースで開催できればなーと思ってますが、スピーカーが集まるかなどによるかなぁと。 ということで、勉強会のグループのページにスピーカー応募フォームのリンクがありますので、スピーカーに興味がある方は入力していただければと。\nもちろん第2回はやりたいので、勉強会のページからの連絡をお待ちください！！\n","date":1551191880,"dir":"post/2019/","id":"b27bdabd8e1a6b7dc06886867331ceb3","lang":"ja","lastmod":1551191880,"permalink":"https://blog.johtani.info/blog/2019/02/26/start-search-engineering-tech-talk/","publishdate":"2019-02-26T23:38:00+09:00","summary":"どーも、johtaniです。 Search Engineering Tech Talkという勉強会に運営として参加して、第1回の勉強会を開始しました。 本日（2/26）は第1回目だったの","tags":["勉強会","検索"],"title":"Search Engineering Tech Talk(検索技術勉強会)の運営として参加して始めてみました。"},{"contents":"今年も振り返りブログをかけてます。よかったw\n振り返り（2017年に書いた抱負から） まずは去年の抱負を元に。\nもっと英語の継続＆TOEIC まぁ、継続してます。英会話も続けてますし、海外TVドラマや映画見てます。 ただ、昨年書いたTOEICはイベントが被りまくってて受けれてないです。。。 来年は受けれればいいが。 ちなみに見たドラマはこの辺。あんまり見てないなぁ。 「はじまりのうた」は飛行機の中で見たんですが、よかったです。 最近は音楽系の映画が好きなのかなぁ。グレーテストマンショー（ミュージカル風）とかもハマったし。\nGame of Thrones はじまりのうた BEGIN AGAIN (映画) 24 シーズン4まで 今は、ボキャブラリのなさに苦しんでる感じです。キクタンとかするべきなのかもなぁ。 基本勉強が下手だからなー。\n継続的にイベントに登壇 ＆ CfPもっと出すぞ！ OSCには出てました。あとは、いくつかに呼ばれて出たりでしょうか。 CfPはJJUGしか出せてない気がするんで、もっと出さないとですね。。。 春のJJUGでは20分で短すぎた「オープンソースとビジネスモデル」の話（同僚のネタ）が 今年面白かった内容かなぁと。 もっと話を作るのをうまくしないとだろうなぁ。 ユースケースが増えてるんで、もっといろんなところに出ていかないとなぁと。 ブースの出し方とかもちょっと考えないといけないかもなーと思ってたり。 マンネリになってきてる気がするんで、なんか取り入れないとなぁ。\nもっとブログ！ 出だしはよかったんですが、途中でRustネタのブログも止まってしまいましたね。。。 業務が忙しくなったのを言い訳にして時間が取れなくなってるんで、 もっと習慣つけないとなぁ。\n雑誌やWeb系雑誌で記事を。 できてないです。。。どうすっかなぁ。 重い腰上げないのが問題なんですけどね。。。 自社のウェビナーとかはそこそこやってましたが。\nコミュニティを別の方法で盛り上げ フォーラムは皆さんのおかげで盛り上がってきてる気がしてます。 別の方法ではなく、勉強会を9月から毎月開催にして、ユースケースごとに切り替えてみました。 あとは、スピーカー登録用のフォームの用意とかして、継続的に楽にスピーカーの人たちが見つけられるようにと。 私は「全然」関わってないんですが、技術書典でいろんな方に書籍を書いていただきました。 また、Elasticloverという毎週いろんな記事をまとめていただけ助かりました。 少しでも感謝をということで、コミュニティランチというイベントで、フォーラムで回答していただいてる方や、書籍を出していただいた方を招いてCEOのShayとランチするというイベントもやってみました。 少しは盛り上げられたかなぁ。 次は、ハッカソンみたいなのとかやってみるのもありなのかなぁ？（サポートしきれない気がするんだよなぁ）\nElasticsearchなど検索系の開発にも参加 開発。。。 Analyzer向けのKibanaのプラグインの開発は継続してますが、あんまり開発してないですねぇ（GitHubの草をみながら)。 ちょっとしたPRはやったりしてますが、もっとやりたい。。。 とりあえず、来年しょっぱなは、検索系じゃないですが、KibanaのプラグインのReact化をやらないとなぁと。\n振り返り(今年あったできごと) さて、反省が多かったですが、ここからは今年の出来事を。\n初スノーシュー in US オフィス引越し パリで料理w K8sとde:code QNAPとか IPO! 初のオンライン登壇 初アイルランド! Pixel3 XL 今年も初モノがちらほら。\nアメリカでスノーシューやりました。昨年は釣りでしたが、今年はスノーシューでした。 スノーシューはすごくよかったんですが、サンフランシスコから社内ミーティングのある場所までの 移動に10時間バスに缶詰という変な初モノもありました。。。 スノーリゾートのある山の上にバスで移動だったんですが、前日までの天候の生でチェーン規制が出てしまい、登りかけた山を降りて、違う経路で登り直すという長旅でした。。。 途中からずっとゲームオブスローンズみてました。。。\nオフィスが引っ越しました。人数が増えてきたのもあり、銀座のWeWorkに引っ越しました（私はあんまり行かなかったりしますがw）。 ただ、すでに手狭になってきて、来年はまた引っ越してるかもなぁ。 今年の終わりで日本のメンバーが22名に増えました！すごい！4年半前の22倍！\nパリで料理もしましたwセールスのキックオフミーティングがパリで開催され、なぜか参加してきました。 そこで、DevRelチームのミーティング＆ディナーがあったんですが、ディナーがアクティビティ付きで、チームのみんなとパリで料理やカクテル作ってきました。 まさか、パリで手巻き寿司作るとは思わなかった（怖くて食べてないですw）\n今年はイベントが連続することが多かったです。パリから帰ってすぐにde:codeでMSの川崎さんと登壇したりしました。Kubernetesを触る機会ができたんでよかったですが、時差ボケは辛かったw今年は他にもカンファレンス直後にトレーニングだったりと、夏に喉やられちゃいました。喉に負担をかけない話し方の練習すべきなんだろうなぁ。\n自宅の環境もちょっと整えました。10年前から使ってた、TeraStationをQNAPに刷新。快適に検索できるわ、クラウドにバックアップとれるわで、すごく快適です。 あとは、自室のディスプレイをディスプレイアームにつけたり、壊れたモニタースピーカーをYamahaのパワードスピーカーに買い替えたりと。 ちょこちょこ自宅で作業したりするんで、快適です。\n今年はめでたいことに会社がIPOしました。ニューヨーク証券取引所で株式公開しました。 転職して4年、初体験なんで何がどうってのはいまいち実感わかないんですが、順調にきてるのは嬉しい限りです。今後も頑張りますよ！\n自社のウェビナーでは、オンライン登壇してたんですが、インフラ勉強会でオンライン登壇させていただきました。 Elastic Stackの入門的な話をさせていただいたので、興味があればみていただければと。 こういうのにはマイクが非常に重要だなというのが結論です。ウェビナーで使ってるShureのマイクで話したので聞き取りやすかったです。 来年はもっと手軽にちょっとしたウェビナーとかポッドキャストやろうかな、ということで、持ち運び用にSAM SONGo Micを購入してみたのでどっかで試してみたいなー。\nアイルランド（ダブリン）にも行きました。これまた、社内のミーティングなんですけどね。半年に1度エンジニアが集まる社内イベントがあるので、いろんなところに旅をさせてもらっていて、すごく楽しいです。 みんなにも会えるし。ただ、アイルランドの英語はきつかった。。。\n最後はPixel3です。SonyのXperiaをここ数年は使ってたんですが、電池の持ちなどが悪くなったんで、気になってたPixel3に変えました。すごくいい。いらないものが入ってないのもいい。あとカメラがすごくいい。他の機能をまだちゃんと調べてないんで、誰か便利機能知ってたら教えてくださいw\nとまぁ、こんな感じでした。\n来年の抱負 最後は来年の抱負を。\nTOEIC CfP見つけて応募 \u0026amp; いろんな場所に顔を出す もっとブログ！ Rustの継続 開発の継続 日本でエンジニア獲得! まぁ、英語ですね。これは地道にやるしかないんだろうなと思いつつ、コツコツが苦手でw とりあえず、今年はどこかでTOEIC受けないとな。\nいつも行かないけど、弊社プロダクトに関係のあるカンファレンスのCfPを見つけ出して、 応募しまくって、少しでもしゃべらないとなぁ。喋れなくても、Elasticsearchがらみで登壇していただいてる方がいるカンファレンスには顔を出していきたいなぁと。 登壇される方いたら、ぜひ連絡ください！あとは、CfPのサイトを探す仕組みを作らないとなぁ。 検索サイト作るかなぁ。 あとは、カンファレンスではなく、いろんな会社に遊びにいきたいと思ってます。 入門的な話をしてほしいような方、こんな使い方してますっていう話をしていただける方、大募集です。 これもGoogle Formでも作ってみるか。\nブログなぁ。小さな習慣を読んだのに、習慣化できてないので、なんとかしないとという意味で。。。が、頑張ります。。。\nRustの継続＆開発の継続もですね。Java歴が長いので、他の言語を勉強しようと思ってRustやってますがなかなか身についてないというか、時間を取れてない。これもコツコツやらないとなー 検索関連の開発もちょっとずつやりたいなと思ってるんで、LukeへContributeしようかな。\n切実なんですが、日本に弊社のエンジニアを増やしたいなと。特に人前で喋ってもらえる人が増えると助かるんです。弊社最近、ユースケースが増えてきてて、追いつかなくてwダレカタスケテーw\nさーて、そろそろ紅白のサザンが始まるんで終わりです。\n今年も様々な方々に様々な面で助けていただきました。本当にお世話になりました。 この場を借りてお礼申し上げます。\n来年ももちろん、助けてもらうんで、よろしくお願いいたします！ あと、話聞きたい方、声かけてくださーい。\n","date":1546240485,"dir":"post/2018/","id":"6c226ee1519fbf910197cc1d5c5a5756","lang":"ja","lastmod":1546240485,"permalink":"https://blog.johtani.info/blog/2018/12/31/looking-back-2018/","publishdate":"2018-12-31T16:14:45+09:00","summary":"今年も振り返りブログをかけてます。よかったw 振り返り（2017年に書いた抱負から） まずは去年の抱負を元に。 もっと英語の継続＆TOEIC まぁ、","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2018）"},{"contents":"Elastic stack (Elasticsearch) Advent Calendar 2018の25日目の記事になります。 今年最後のAdvent Calendarです！来年も忘れてなければやるはず！\n今日は、すでにalpha2までリリースされた7系でどんな変更が入るのかをちょっとだけ紹介します。 ほんとにちょっとだけですよ。\nKibanaのk7 design (kibana) Kibanaの新デザインです。K7って呼ぶのかな？\nまだ、メニューと一部が実装されているだけですが、7.0.0でガラッと変わりそうです。 そのほかの画面のIssueはこちらです。 \u0026ldquo;k7\u0026quot;で検索しただけですが。メタIssueが見つからなかったんで。例えば、こんな感じでアプリとかのスイッチとかがこんな感じになるよというデザイン案が観れたりします。\nZen2 (elasticsearch) Elasticsearchの新しいクラスター管理機構アルゴリズムになります。 Zenと呼ばれる独自実装のものを6系までは使っていましたが、7系向けに変更がかかりました。 実際には、Nodeを探す仕組み、Masterの選出アルゴリズム、クラスター状態の管理などを行います。 上記のリンクにあるようにドキュメントも詳しくなりました。 信頼性をさらに向上し、設定ミスを起こしにくくして、より使いやすくという目的で様々な変更が加えられています。 これが、メタIssueかな？ アルゴリズムの変更や、クラスターの状態の管理の方法などの変更に関するIssueやPRにリンクが貼ってあります。\n新しいデータタイプ (elasticsearch) Feature/Feature vector datatype ドキュメントはこちらとこちら\nfeature queryと合わせて使用するためのフィールドで、しかもクエリのスコア計算「のみ」に使用するフィールドになります。 検索条件やソート、Aggregationの対象ではなく、クエリのスコアに影響させたい値を入れておくためのフィールドです。 6から追加された機能の「track_total_hits」をfalseにした時と合わせると、function_scoreなどで計算をしていた場合よりも、検索性能が上がるという利点まであります。 ちなみに、「track_total_hits」は検索ヒット数を計算しないで、上位のデータを取得する時にクエリを早くするといったことができる機能になります。 Index Sortingと組み合わせることで威力が発揮できる仕組みになるはずです。\nFilebeat supports NetFlow (beats) NetFlowが入力として追加されます。 Filebeatと言いつつ、File以外の入力が徐々に増えてきてますね（UDPやTCPにも対応しましたし）。 ネットワーク機器などの監視を行う方などにはさらに便利になってくるのではないでしょうか？ （私はこの辺りは不得手なので、誰か使ってみてもらえればと！）\nまとめ まだ、序の口って感じですが、今年はこの辺で。7系ではここであげた以外にも様々な機能が追加されています（もしくは予定です）。 Elasticのドキュメントの良いところは、masterブランチのドキュメントも公開されていることです。 ドキュメントのバージョンを7.0.0-alpha2にすれば、masterブランチで追加されたページが見れるので、 興味のある方は眺めてみていただければと。物によって、リリースノートが書かれていなかったりするので注意は必要ですが。\n今年もあと数日になりましたが、Advent Calendarへの参加ありがとうございました！ 来年ももちろんやりますので、年始からネタを考えてくださいね。\n来年一発目は、第28回Elasticsearch勉強会 - 6.5機能紹介 -になります。ウェビナーでも紹介しましたが、6.5で入った様々な新機能をデモありで紹介する予定です。 興味のある方はぜひご参加ください。\nでは、来年もよろしくお願いいたします。\n","date":1545663601,"dir":"post/2018/","id":"ee62cb0b9a97f990df1ed0266a7027e2","lang":"ja","lastmod":1545663601,"permalink":"https://blog.johtani.info/blog/2018/12/25/whats-new-in-elastic-stack-7/","publishdate":"2018-12-25T00:00:01+09:00","summary":"Elastic stack (Elasticsearch) Advent Calendar 2018の25日目の記事になります。 今年最後のAdvent Calendarです！来年も忘れてなければやるはず！ 今日は、すでにalp","tags":["elasticsearch"],"title":"Elastic Stack 7.0で入ってくる新機能をちょっと紹介"},{"contents":"Elastic stack (Elasticsearch) Advent Calendar 2018の1日目の記事になります。\nちょっと遅れちゃいました。。。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみようと思います。毎年恒例ですね、ここ数年。\nElastic Stack 6.2.0リリース(2月) リリース記事はこちら\nAPMがGAリリースされ、Beats monitoring UIも追加されました。Stackとしての統一度がちょっとずつ上がってきた感じですね。 Kibanaのホーム画面（左メニューのKibanaアイコンをクリックした時）にデータ登録のチュートリアル的な画面が追加されています。 特にBeatsを利用する時の流れが簡単にわかるのがいい感じです。Metricsなどはローカルでちょっと試すのにも簡単な流れですので、ぜひ一度やってみてもらいたいなと。 個人的にはtermsを使ったパイチャートで、その他の数値がどのくらいあるかといった表示ができるようになって、やっと帰ってきた！（Kibana 3の頃にはあった機能）という印象でした。\nElastic{ON}18開催(2月) 第4回目のユーザーカンファレンスがSFで開催されました。 今年のキーノートが今年最大のニュースですね。 X-Packのコードの公開が発表されたのがこの時でした。 個人的に今後もオープンソースに携わっていきたいと思いながら日々働いていますが、 Elasticのオープンソースへのこだわりと、シンプルな考え方を再確認して素晴らしい会社で働けてるなーと。 商用のソースコードを公開してユーザーや顧客の皆さんとより良いものを作っていきたいという形ですので、今後もよろしくお願いします！ キーノートの動画はこちらからご覧いただけます。\nそのほかにも次のような発表が行われました。\nSQL for elasticsearch Canvas Elastic App Search(旧Swiftype) Elastic Stack 6.3.0リリース(6月) リリース記事はこちら\n2月末のElastic{ON}で発表されたX-Packのコードの公開にはやはり時間がかかりました。 有償コードのリポジトリとの統合やライセンスの変更、テスト環境などなど、色々大変だったみたいです。 ようやく公開され、ベーシックのライセンスの扱いなども変わり、より使いやすくなったのがこのタイミングです。\nX-Packをプラグインとしてのインストールが不要に ベーシックライセンスがデフォルトでONに。6.3から登録などが不要に。 Apache 2.0ライセンスの部分のみのディストリビューションも別途ダウンロードできるようになどなど 日本でもリリースウェビナーをやりました。ご覧いただけましたかね？\nElastic Cloud Elasticsearch Serviceがより使いやすく(8月) リリース記事はこちら\nこれまでは、メモリとストレージの比率だけしか指定できなかったのですが、 このリリースで様々なユースケースに応じた組み合わせが可能になりました。 CPUやメモリリソースよりもストレージを大きくしたりなどです。 専用マスターノードを追加できたり、待望の機械学習（Machine Learning）が提供されたりと色々と変更があり使いやすくなったかと。 昔からよく聞かれる、Kuromojiなどのカスタム辞書を登録する機能もあるので、Elastic Cloud便利です。 ご存知ない方は、14日間のトライアルもありますので試していただければと！\nElastic Stack 6.4.0リリース(8月) リリース記事はこちら\nフィールドエイリアスや韓国語のアナライザーがElasticsearchに追加されました。 Kibanaはデザインがここからさらに少しずつ変更が入ってたりします。 Elastic UIフレームワークと呼ばれるデザイン用のライブラリが、ElasticのプロダクトのUIに取り込まれていってる感じです。統一感が取れてきてますよね。私が開発しているAnalyze UIのプラグインにも取り込みました。 あとは、マイクロソフトのde:codeで話をさせていただいた、Logstash向けのAzure Moduleがリリースされたのもこのバージョンでした。AzureのEvent Hubからデータを取り込んで、SQLデータベースのモニタリングや、ユーザーの認証などをとってKibanaで可視化するものです。\nもっとも気に入っているのはサンプルデータの登録が簡単になったことです。これまでは、KibanaとElasticsearchを用意した後に、データを入れるためにFilebeatなどを使ってから、ようやくKibanaで遊べるという形でした。 6.4からは、ElasticsearchとKibanaを立ち上げて、Kibanaのホーム画面の「Sample Data」のリンクを押した後に、「Sample flght data」の「Add」ボタンを押せばKibanaからデータが登録されます（サンプルデータについてはこちら）。とりあえず触ってみたいという方への敷居がさらに下がったのではないかなぁと。\nElastic認定エンジニア第1号(8月) ブログ記事はこちら\n認定制度も始まりました。Elasticsearchの知識、経験を問われるテストを受けていただき、合格すると認定されるというやつです。 なんと、社外で世界初の認定エンジニアがアクロクエストの吉岡さんでした（上記ブログ参照）。 私もトレーナーやってるのもあり、慌てて認定をとったりしましたw。 認定テストは筆記ではなく、実際に作業をするテストなので実践的です。 トレーニングの受講が必須ではないのも面白いなぁと思いました。 トレーニングや認定エンジニアに興味がある方は、Elasticのトレーニングのサイトをご覧ください。 1月末にはまた、日本語でElasticsearchのトレーニングも開催されます！\nElastic Cloud Enterprise 2.0リリース(9月) リリース記事はこちら\nElastic Cloud Enterpriseをご存知ない方もいらっしゃるかもしれません。 Elastic Cloudの裏側で利用しているクラスターの起動などの仕組みを製品として提供しているのがこちらになります。 Elastic Cloudで機械学習や様々な構成ができるようになったものがリリースされたのがこの2.0です。 複数のElasticsearchクラスターを管理したい場合には、こちらが便利なツールになってるんじゃないかなぁと。 部署ごとにクラスターを提供するといったことが可能になるので、乱立する前に利用するのも便利かなーと。\nニューヨーク証券取引所で株式を公開(10月) ブログ記事\n日本語でブログ(10月) Elasticsearchの運用に関する典型的な4つの誤解というブログを書きました。4年も働いてるのに、会社のブログに翻訳以外で書いたことなかったので。。。 Twitterや勉強会、ブログ記事などで見かけるよくある誤解に関する記事を書いてみました。 Elasticは英語のブログも活発に書かれているのですが、今後もこのような形で日本語でのブログも頑張りますので、 読んでみたいものなどあればコメントいただければと。\nまぁ、弊社の大輪は色々書いてるんで、私がもっと頑張れって話ですかね。。。\nElastic Stack 6.5.0リリース(11月) リリース記事はこちら\n昨日（11/30）のウェビナーでも話をさせていただきましたが、Elastic Stack 6.5は「本当にマイナーリリース？？？」と思うほど盛りだくさんの機能がリリースされました。\nインフラUI、ログUI Elastic APMの分散トレーシング対応 Java \u0026amp; Go APM Agent GAリリース Cross Cluster Replication ODBCドライバー Kibana Canvas Kibana Spaces Data Visualizer for files Functionbeat LogstashのApp Search output リストアップしただけでもこれです。45分のウェビナーでは伝えきれてないなぁとも思ってますので、何か検討しようと思います！\nElasticsearch勉強会(3月から12月) Elasticsearch勉強会ページ\n今年は、6回の勉強会を開催（1つは12月19日開催）しました。 9月からは、ユースケースなど、もっと参加者の皆さんの興味があることにフォーカスしながら開催をしてみ始めました。 参加しやすくなってればいいのですが。。。 そろそろまたアンケートをとったりして、参加しやすいか、どんな改善がしてほしいかなどを聞きたいなと思っています。\n12月はもっと皆さんと喋りたいなということで、スピーカーなしの「LT\u0026amp;忘年会」にしてみました。 私やElasticのものも参加するので、ぜひ色々聞いたり、他のコミュニティの方達の使い方を聞き出して、 新しい発見をしていただければなーと思います。LTでスピーカーの練習をするってものありですよ！（まだ誰も応募してくれてない。。。） 発表することで、フィードバックがもらえて、自分の使い方に自信が持てたり、その他の視点を得ることができると思いますので、 ぜひ発表してみていただければと。\n12月のjohtani出没イベント 12月は以下のイベントにブースを出してます。イベントに参加される方ははぜひブースにお立ち寄りください！！\n12/4-5 : Japan Container Days - 東京 12/8 : OSC福岡 - 福岡 12/15 : JJUG CCC 2018 Fall - 東京 12/19 : 第27回Elasticsearch勉強会 - 東京 なんか、忙しそうだな。。。\nまとめ 駆け足でしたが今年を振り返ってみました。 今年も色々ありましたが、今後もよろしくお願いいたします。\nさて、Elastic Stack Advent Calendar 2018は今日から25日まで続きます。こらからの記事を楽しみにしています！\nということで、次はkaibadash@githubさんの「ぼくの考えた最強のElasticsearch index設定を最強にわかりやすく書くぞ！！！」になります。お楽しみに！\n","date":1543628918,"dir":"post/2018/","id":"ba45ddd3042dad59a12e5937644f7246","lang":"ja","lastmod":1543628918,"permalink":"https://blog.johtani.info/blog/2018/12/01/whats-happen-at-elastic-in-2018/","publishdate":"2018-12-01T10:48:38+09:00","summary":"Elastic stack (Elasticsearch) Advent Calendar 2018の1日目の記事になります。 ちょっと遅れちゃいました。。。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみよ","tags":["elasticsearch"],"title":"2018年のElastic StackとElastic"},{"contents":"（転職する少し前までパスポートすら持ってなかったのに）今の会社に転職してから、半年に1度の割合で海外への出張が発生する生活を送っています。 4年目になりますが、今回いくつか新しいガジェット？アイテム？を出張用に導入したので感想を書いておこうかなと。\nとりあえず、以下の4つです。\nFelimoa ネック ピロー これまでは、無印で購入した「フィットするネックピロー」を使ってました。 特に使ってる間は問題ないのですが、どうしてもかさばります。。。 そんな時、FBで見かけたのがこちら。\n厚みがないので、持ち運びが便利でした（商品紹介の中にありますが、リュックにつけると邪魔にならない）。 飛行機の中で使うので、それほど暑くない場所なので、ムレる感じでもなく。 ただ、ヘッドフォン＋真横にフレームがくる形になるとヘッドフォンに干渉するので、 私はフレームを顎の下の方に寄せた形で使ってました。 軽さと場所を取らないのがよかったです。\nノイズキャンセリングヘッドフォン これまでは、SONYのNW-A847という ノイズキャンセリング機能付きのウォークマン＋アクセサリーで外部入力を取り込む形で、飛行機で映画を見ていました。 これ自体が8年前の製品ですね。。。 これとは別に、冬の寒い時期は防寒も兼ねてヘッドフォンを使用しています。 MDR-10Rを使ってたんですが、昨年こんな感じになりまして。。。\n応急処置 pic.twitter.com/uDErZWpPVC\n\u0026mdash; Jun Ohtani (@johtani) 2017年11月10日 で、ヘッドフォンの買い替えを検討してたんです。 そこへ飛び込んできたのがSonyの新しいノイズキャンセリングヘッドフォンでしたと。\nせっかく買い換えるし、今度はいいものを長くということでフライト前日に購入してしまいました。 結論としては高いけど買ってよかったと。よかった点はこんな感じです。\n軽い イヤーパッドが耳を抑えることがないので長時間でも気にならない 人の声だけノイズキャンセリングをオフにする（騒音などはキャンセルしてくれる） バッテリーが長時間 ヘッドフォンを外さないでも案内を聞くことができる「クイックアテンションモード」 などなど。行きのフライトで5時間も遅れが出ましたが、空港、飛行機内で非常に快適に過ごせました。 大事に使おう。。。\ncw-x 知り合いがFBにアップしてて、立ちっぱなしの仕事だったり、長時間のフライトでも足が疲れないという噂を聞いて購入しました。\n長時間のフライトの後に、ホテルで1泊しても足の疲れって結構残ってるんです。 今回、12時間のフライトでズボンの下に履いて行きましたが、足の疲れがほぼありませんでした。 デブになりつつあり、足太くなって来てるので、履くのはちょっと苦労しますが。。。もともときつめに作ってるんじゃないかなぁ（希望的観測）。 帰りも使用しましたが、帰りはフライト前に1万歩ほどダブリンの街中を歩き回ってたので、流石に疲れが出てます。。。 今度は、カンファレンスのブースなどで立つことが多いシーンでも使ってみて、疲れがどうなるかを試してみようと思います。\n携帯ウォシュレット 初めて購入しました。海外のホテルで1週間とか連泊するんですが、トイレットペーパーがやはり硬めなのが気になって。。。\n世界に誇る日本の技術の一つだと確信してますw ドイツに長期出張してた友人が便利だよと言ってたので、思い切って購入して持って行きました。 硬めのトイレットペーパーも気にならなくなるのでとても幸せな気分ですw\nまとめ とりあえず、今回はこんな感じです。 総じて導入してよかったなという感じでした。 他にもおすすめ出張グッズとかあればコメントいただけると嬉しいです。\n普段使ってるものとか、どういうものを持っていってるとか興味ある人いるかなぁ？ ではでは。\n","date":1539794095,"dir":"post/2018/","id":"3fd9052870778e14ab4a5acbc8c24af4","lang":"ja","lastmod":1539794095,"permalink":"https://blog.johtani.info/blog/2018/10/18/items-for-long-businesstrip/","publishdate":"2018-10-18T01:34:55+09:00","summary":"（転職する少し前までパスポートすら持ってなかったのに）今の会社に転職してから、半年に1度の割合で海外への出張が発生する生活を送っています。 4","tags":["misc"],"title":"新規導入した長期出張用のアイテムをいくつか紹介"},{"contents":"毎月開催の2回目になります。 今回は日経さんの会場をお借りしての開催となりました。\n前回から、スピーカーの募集をhttp://bit.ly/SpeakerElasticTokyoMeetup で行なっております。 ぜひ皆さんのノウハウを共有していただけると助かります。 また、次回もすでにスケジュール済みです。次回は「ログ/メトリック分析」回になります。\n以下は、個人的なメモになります。\nメディアコンテンツ向け記事検索DBとして使うElasticsearch / Future Architect 株式会社 村田 靖拓さん (twitter: @famipapamart) メディア記事コンテンツ検索 全ての情報が1indexに入っているようにすること。 typeは少し悩んだ。 範囲検索にはならない場合がある。（文字列で登録してWildcard検索できるようにした） kuromojiで基本対応 異体字についてはchar filterでマッピング 細かな設定とかもスライドにて公開予定。 基本的なプラグインだけで対応した Dynamic Field mappingを有効にしたまま対応 パフォーマンス検証 初回のインデックスのロードはこの辺かなぁ？。 自力でQueryのoffset-limitを構築するのかぁ。 ソート条件が固定らしいのでできる方法 minne での検索運用(仮) / @_shiro16 さん ハンドメイドなものをマーケットプレイスがminne SolrからElasticsearchに切り替えた話 2016/02以降はEs 昔は、DBからSolrへ同期 Es版ではDBからの同期ではなく、Workerに対してリクエストを入れる 現状は独自にEC2で運用中 ユーザーが求めているものがきちんとでているかを計測している 行動ログはどんな感じ？ TDにログを入れて、CTRとかを計算してre:dashで可視化 A/Bテストも実施 指標はキャンペーンなどが実施されている場合にブレる場合もある トレンドをログから知ることができる Function Scoreでスコアを変更してる 季節的な単語でスコアを変更したりする ドリンクの対応などをして聴けてないところが。。。 query_stringのはなし / 加藤遼さん　(日本経済新聞社) 電池が切れそう＋ピザとかの手配をしていたらメモが取れず。\n苦労が滲み出る感じのセッションでした。 query_string queryが実際にどんなクエリになっているかの説明を交えて説明してもらえたのはすごくよかったんじゃないかと。 まとめ 検索は話してくれる人が多いし話題に事欠かないなぁという印象でした。 今回も、スピーカーの皆さん、会場提供をしていただいた日経さんありがとうございました。\n他のユースケースのスピーカーも募集してます。ぜひMeetup.comの概要に記載してあるリンクからスピーカーの応募をお願いします！\n","date":1539765230,"dir":"post/2018/","id":"d3fa23c9066f943f10e8883de9340dea","lang":"ja","lastmod":1539765230,"permalink":"https://blog.johtani.info/blog/2018/10/17/26th-elasticsearch-tokyo-meetup/","publishdate":"2018-10-17T17:33:50+09:00","summary":"毎月開催の2回目になります。 今回は日経さんの会場をお借りしての開催となりました。 前回から、スピーカーの募集をhttp://bit.ly/Sp","tags":["elasticsearch","勉強会"],"title":"第25回Elasticsearch勉強会を開催しました。"},{"contents":"7/25にJJUGナイトセミナーでElastic Stackの紹介とAPMのJava Agentの紹介をしたので、補足のブログです。 （久々に書くな。。。）\nスライドとサンプルアプリのリポジトリはこちら。\nスライド：https://speakerdeck.com/johtani/intro-elastic-stack-and-elastic-apm-java リポジトリ：https://github.com/johtani/apm-beats-kubernetes-demo/tree/master サンプルアプリ 勉強会の頭でサンプルアプリへのアクセス用QRコードを用意して質問してもらう感じにしました。\nアプリ自体が質問の受付と、そこにある質問に対して聞きたいかどうかのVoteができる仕組みになっています。 セッション最後にこの画面をみながら答えました。 手を挙げていただくよりも、匿名（名前入れるようになってますが、実名である必要はない）で登録できるし、 みんなが聞きたいかどうかもわかるので便利だなぁと。\n元は、Elastic{ON} 2018であった「Docker \u0026amp; Kubernetes Log Collection and Monitoring with Beats and Elasticsearch」のサンプルアプリです。 これをSpring Bootに移植して、ちょっとだけサンプルコードを追加したものになります。\n構成とかの補足 スライド、GitHubのリポジトリのREADMEにある図は、k8s上のサンプルアプリケーションの構成だけでした。 ElasticsearchとKibanaを含めた図はこんな感じです。\nk8s上の各種Beats、APM Serverは一旦Elastic CLoud Elasticsearch Service（AWS Tokyoリージョンにデプロイ）に対してデータを投げます。 で、KibanaはGKE(k8s on GCP)で動かして、実際に勉強会ではkubectl proxyで接続してから表示していました。 この構成にしている理由は次の理由です。\nElastic CloudのElasticsearchクラスターにデータを投げている理由 クラスターの起動が簡単。 データを永続化したい。k8sのアプリは必要がなくなったらデータを削除したいから。 k8sのdeploymentを書く手間を省く 普段使ってるので。。。 KibanaをGKEで動かした理由 Elastic Cloudでは*「現時点(7/29現在)」*で、KibanaでAPM専用のUIを起動できない ローカルである必要はない といったところです。 Elastic Cloudのインスタンスを起動したままにしておけば、デモをしなくても、このタイミングのログ、メトリクスを 再利用して話をすることも可能です。\nまとめ ということで、簡単ですが、構成の補足でした。 勉強会では告知したのですが、今後の勉強会はトピックスごとでやりたいなと。ということで、どんなトピックスに興味があるのか、スピーカーの応募にはどんなツールが話しやすいかなどといったことのアンケートを集めております。ぜひご協力ください！ また、アンケート、このブログに関する質問がある場合は、@johtani、もしくはブログへのコメントでお願い致します。\n今後の勉強会のやり方などについてアンケートを実施中です。https://t.co/XU15CHro0n 皆さん是非ご協力ください。ここにない項目については返信をお願いします。 #elasticsearchjp\n\u0026mdash; Jun Ohtani (@johtani) 2018年7月23日 ","date":1532843130,"dir":"post/2018/","id":"10ae016e19fff6ae9cfaeb8534fa47f9","lang":"ja","lastmod":1532843130,"permalink":"https://blog.johtani.info/blog/2018/07/29/apm-java-at-jjug/","publishdate":"2018-07-29T14:45:30+09:00","summary":"7/25にJJUGナイトセミナーでElastic Stackの紹介とAPMのJava Agentの紹介をしたので、補足のブログです。 （久々に書く","tags":["勉強会"],"title":"JJUGナイトセミナーで話しました"},{"contents":"第2回から少し間が空いてしまいましたが、templateで作成したプラグインのディレクトリ構成とどういう流れでデータがやり取りされるかについてみていきます。 （2018/02月時点で作成したディレクトリ構成にしたがって説明します） ちなみに、JavaScriptの優れた開発者ではないので、誤解している点や、効率の悪い書き方などがあるかもしれません。見つけた場合は、連絡をいただければと思います。\nでは、まずは作成したディレクトリ構成についてみていきましょう。\nディレクトリ構成 simple-sample-kibana-pluginがプラグインのプロジェクトのトップディレクトリになります。このディレクトリに次のような構成でサブディレクトリが存在します(なお、画像はIntelliJに取り込んだ後のディレクトリになっているので、.imlなど、不要なファイル/ディレクトリが存在しています)。\n主要なディレクトリ、ファイルについて簡単に一覧で説明します(順不同)。\nファイル/ディレクトリ名 説明 index.js プラグインの本体。Kibanaはこのファイルのオブジェクトを読み込みプラグインを起動。設定などの読み込みもこちら。 package.json npm/yarnのパッケージに関する情報を定義するファイル README.md README。プラグインの説明などを記載する。インストール方法なども記載すると便利 public ブラウザ側に配布されるプログラムや画像一式 public/less/main.less LESS用のファイル。アプリ固有のスタイルなどを記載 public/app.js ブラウザ側で読み込まれるプラグインのモジュールなど。 public/template/index.html HTMLのテンプレート。ブラウザ上での描画に利用 server/routes Kibanaサーバー側で動作するプラグイン。hapi.jsを利用してREST APIを実装する 重要なファイルについて少しだけ説明します。\npackage.json npmやyarnでビルドなどをするときに使用するパッケージ情報を記載するためのファイルです。 プラグインの名前、バージョン、説明などを記載します。 Kibanaのバージョンについてもこちらで管理します。この情報を また、ライブラリなどの依存関係についてもこちらで記載しています。 以下、抜粋。\n{ \u0026#34;name\u0026#34;: \u0026#34;simple-sample-kibana-plugin\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;0.0.0\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;Sample plugin for explaining how to make kibana app\u0026#34;, \u0026#34;main\u0026#34;: \u0026#34;index.js\u0026#34;, \u0026#34;kibana\u0026#34;: { \u0026#34;version\u0026#34;: \u0026#34;6.2.1\u0026#34;, \u0026#34;templateVersion\u0026#34;: \u0026#34;7.2.4\u0026#34; }, \u0026#34;scripts\u0026#34;: { \u0026#34;lint\u0026#34;: \u0026#34;eslint **/*.js\u0026#34;, ... }, \u0026#34;devDependencies\u0026#34;: { \u0026#34;@elastic/eslint-config-kibana\u0026#34;: \u0026#34;^0.14.0\u0026#34;, \u0026#34;@elastic/eslint-import-resolver-kibana\u0026#34;: \u0026#34;^0.9.0\u0026#34;, \u0026#34;@elastic/plugin-helpers\u0026#34;: \u0026#34;^7.1.3\u0026#34;, ... \u0026#34;expect.js\u0026#34;: \u0026#34;^0.3.1\u0026#34; } } ちなみに私は、versionなどをリリースするたびに変更しています。\nindex.js 最初にKibanaに読み込まれるオブジェクトになります。 Kibanaのアプリの名前や、必要なモジュールなどを記載します。\nまた、kibana.ymlから設定など読み込む処理なども書くことができます。\n2行目のexampleRouteはサーバー側のAPIとして利用するhapi.js用のファイルのパスになります。\nuiExportsはこのアプリの画面に関する設定などの記載になります。 appの部分が実際にアプリの情報で、 mainがあとで説明するこのプラグインのUIのためのJavaScriptファイル(public/app.js)になります。mainですので、最初に読み込まれる処理が記載されているものを指定します。app.jsというファイル名を変更する場合は、こちらのappの部分を変更したファイルに合わせましょう。\nconfig(Joi)の関数が設定ファイルの読み込みなどの処理を記載する場所です。\ninit(server, options)の関数が初期化処理を記載する場所になります。 このサンプルアプリでは、2行目のimportで読み込んだhapi.js用のファイルの関数を呼び出しています。引数で渡しているserverがhapi.jsのserverオブジェクトになります。 routeメソッドを使用して作成しているプラグイン用のREST APIを追加しています。\nimport { resolve } from \u0026#39;path\u0026#39;; import exampleRoute from \u0026#39;./server/routes/example\u0026#39;; export default function (kibana) { return new kibana.Plugin({ require: [\u0026#39;elasticsearch\u0026#39;], name: \u0026#39;simple-sample-kibana-plugin\u0026#39;, uiExports: { app: { title: \u0026#39;Simple Sample Kibana Plugin\u0026#39;, description: \u0026#39;Sample plugin for explaining how to make kibana app\u0026#39;, main: \u0026#39;plugins/simple-sample-kibana-plugin/app\u0026#39; }, ... }, config(Joi) { return Joi.object({ enabled: Joi.boolean().default(true), }).default(); }, init(server, options) { // Add server routes and initialize the plugin here exampleRoute(server); } }); }; public/app.js 画面用のモジュールです。 uiRoutesという機能を使用して、アプリの呼び出しURLを定義します。テンプレートで作成したばかりの場合は、/というURLが追加されるのみです。\n実際に画面を表示する際に動くコントローラーの部分はその下の uiModules.controllerに指定してあるfunctionが画面描画の 処理を書く部分になります。 templateで作成したプラグインでは、\u0026ldquo;title\u0026quot;など表示に必要なデータを$scopeというオブジェクトに詰め込んでいます。 これはAngularJS(1系)でのモデルオブジェクトになります。\nimport moment from \u0026#39;moment\u0026#39;; import { uiModules } from \u0026#39;ui/modules\u0026#39;; import uiRoutes from \u0026#39;ui/routes\u0026#39;; import \u0026#39;ui/autoload/styles\u0026#39;; import \u0026#39;./less/main.less\u0026#39;; import template from \u0026#39;./templates/index.html\u0026#39;; uiRoutes.enable(); uiRoutes .when(\u0026#39;/\u0026#39;, { template, resolve: { ... } }); uiModules .get(\u0026#39;app/simple-sample-kibana-plugin\u0026#39;, []) .controller(\u0026#39;simpleSampleKibanaPluginHelloWorld\u0026#39;, function ($scope, $route, $interval) { $scope.title = \u0026#39;Simple Sample Kibana Plugin\u0026#39;; $scope.description = \u0026#39;Sample plugin for explaining how to make kibana app\u0026#39;; ... $scope.$watch(\u0026#39;$destroy\u0026#39;, unsubscribe); }); server/routes/example.js hapi.jsというNode.jsのためのサーバーフレームワークです。 このフレームワークをKibanaは使っており、Kibanaのサーバーとブラウザとのやり取りに使用するREST APIを記述するために使用しています。 例えば、Elasticsearchとのやり取りを実際に行うAPIなどをこのREST API内部で記述します。\nexport default function (server) { server.route({ path: \u0026#39;/api/simple-sample-kibana-plugin/example\u0026#39;, method: \u0026#39;GET\u0026#39;, handler(req, reply) { reply({ time: (new Date()).toISOString() }); } }); } pathの部分がブラウザ側からアクセスするURLになります。 実際にElasticsearchとやり取りする処理の書き方については、次回の記事で説明します。\nアーキテクチャ（簡易版） ざっくりですが、ファイルやディレクトリについて説明しました。 簡単なデータのやり取りについての流れを説明します。\nKibana自体はNode.jsで実装されサーバーとして動作していますが、ブラウザでアクセスすることで画面を描画しています。 簡単なコンポーネントを並べるとデータのやり取りはこのような形です。\nすごく簡易で大雑把な絵ですが。。。\n実際のプラグインとしては大きく、2つの処理があります。\nブラウザ上の処理 クリックなどのイベント処理 HTMLなどのレンダリング処理 Kibanaサーバー上の処理(Elasticsearchなどとの通信が必要な場合) 外部との通信処理 ブラウザ上では重い処理 絵に記載しましたが、ブラウザ上の処理についてはAngularJSが主なフレームワークで、サーバー上の処理についてはhapi.jsがフレームワークとなっています。\nまとめ ということで、今回はディレクトリ構造とファイルの説明、どういったフレームワークが使われ、データのやり取りがどのように行われているか説明しました。\n次回からは、実際に私が作成したAnalyze UIを元にElasticsearchとのデータのやり取りなどについて紹介していきます。\n","date":1524205801,"dir":"post/2018/","id":"04d818cbaac08b2915db15e0bffdcb5b","lang":"ja","lastmod":1524205801,"permalink":"https://blog.johtani.info/blog/2018/04/20/directory-layout-and-architecture/","publishdate":"2018-04-20T15:30:01+09:00","summary":"第2回から少し間が空いてしまいましたが、templateで作成したプラグインのディレクトリ構成とどういう流れでデータがやり取りされるかについ","tags":["Kibana","plugin"],"title":"Analyze UIとKibanaのプラグインの作成方法（第3回）"},{"contents":"#MANABIYA のブースでセッション時間の合間はお客さん少ないので、ブログを書いてみたり。 ここ数年、スポンサーとして色々なカンファレンスに参加してるんですが、それについてちょっと気なることがあったので。\nスポンサー情報ってどうやって探してます？ 職業柄、カンファレンスにCfP出してセッションしてみたり（落ちること多いけど）、スポンサーとしてブースを出したりしています。\nで、疑問があるんですが、みなさんどうやってカンファレンスの情報をゲットしてます？\n数年やって来て、検索したりして見つけてスポンサーした結果、 これまでスポンサーしていたので、情報が流れてくるという感じになりました。 それ以外だと、@yusuke さんに教えてもらったりと言うのがあったんですが。。。\n自分が知らない、自分のTwitterで流れてこないという情報をどうやったら集められるかな？と言うのが今の課題になってます。 と言うことで、ブログを書いてみました。\nカンファレンスを検索できるサイトとか便利？ で、私の会社は検索エンジンの会社なんで、検索できると便利では？と考えるんです。\nCfPの応募期間で絞り込みできたり、場所で検索できたり、スポンサー情報を取得する方法が載ってたりすると便利なのではないかなと。 便利に思うのが自分だけでは？と言うのがあるんですが。。。\nあると嬉しい人、データを掲載したいなと言う人いますでしょうか？ Google Formなどで入力してもらえるようにして何か作るのもありかなぁと考えているところです。 それとも、スポンサーを募っているカンファレンスのスタッフや企業の人は、こういう情報は特定の人にだけ知ってもらったりしたいでしょうか？\n自分だけではわからないことが多いので、懸念事項や、それダメでしょ？ あると便利！などのフィードバックをいただけると助かります。\nそれ以外に、カンファレンス自体の場所、開催日程、サイトへのURLなどが検索できると便利だったりするかも？というのもあります。\nとりあえず、自分が知ってるものだけ、個人的に検索できるようにしたりするのがいいかなぁ。。。 コメントお待ちしてます！\n","date":1521867012,"dir":"post/2018/","id":"8cc6b19cd410e638f4beaf1642f4f52a","lang":"ja","lastmod":1521867012,"permalink":"https://blog.johtani.info/blog/2018/03/24/how-to-find-conferences/","publishdate":"2018-03-24T13:50:12+09:00","summary":"#MANABIYA のブースでセッション時間の合間はお客さん少ないので、ブログを書いてみたり。 ここ数年、スポンサーとして色々なカンファレンスに参加してるんです","tags":["カンファレンス","スポンサー"],"title":"カンファレンス情報の探し方（CfP、スポンサー応募、開催期間など）？"},{"contents":"Rustで言語処理100本ノックの続きで、05と06です。\n05. n-gram 問題はこちら。\nみんな大好きn-gramです。単語と文字があるので、それぞれ別関数として実装しました。問題はbi-gramとn=2だったのですが、一応、nを引数に取る形にして実装しました。\nまずは、単語です。\n前に実装した時は、自分で頑張って、先頭から数えたりしてたんですが、Rustにはwindows(n)という便利なメソッドがsliceにあり、これを利用したらこんな簡単になりました。 sliceは特定のシーケンス（配列）に対してある特定のサイズのViewを作ってくれます（説明あってる？）。 ということで、文字列から、単語の配列（スペース区切りで単語にしている）を作り出して、windows(n)メソッドを通すと、 nで指定した数字の個数だけの単語の配列を先頭から、1単語ずつずらして作ってくれます。まさに、n-gram! 戻り値は配列の配列です。 1点だけ疑問点があるのは、「空白で区切ったものが単語」という考え方で良いかどうか？という点です。特に問題文にはそれが明示されていなかったので、このような前提を置いてあります。\ninvalid_n(text, n)はnの値や入力された文字列をチェックする関数です。入力チェックですね。nが1よりも小さい場合、入力文字列が空文字の場合は、warningでメッセージを出して、空の配列を返す仕組みになっています。\n次は、文字です。\n単語とほぼ一緒ですが、入力文字列を、1文字ずつの配列にしているところが異なります。 また、windowsメソッドで取り出された、1文字ずつのn個の配列を文字列に修正してから、結果の配列に入れています。 ここでも疑問は空白をどう扱うか？になります。 現時点では、空白も1文字とカウントして扱うことにしてあります。 どっちがいいのかなぁ？\n06. 集合 問題はこちら。\nまずは、文字n-gramで出てきた文字列をSetに入れる関数から。\nn-gramの問題で実装した文字n-gramの関数の戻り値を配列ではなく、BTreeSetに変えたものになります。比較などがしやすいように？と思い、BTreeSetを利用していますが、実装としてはHashSetでも問題ないかと。 この関数の集合（Set）を元に、和集合、積集合、差集合を求める関数を実装しました。\nSetのメソッドとして、それぞれ、union＝和集合、intersection＝積集合、difference＝差集合のメソッドが用意されているので、特に困ることはなかったです。 差集合については、1-2と2-1で結果が異なるはずなので、それぞれをテストケース、main.rsで出力するようにしてあります。\n所感 今回は、Rustがすでに実装してくれているメソッドがあったので楽ができました。 やりたいことに相当するメソッドがあるかどうかを調べるためにリファレンスを探さないといけないのがちょっと苦労しましたが。。。 ということで、今日はこの辺りまで。\n","date":1521549285,"dir":"post/2018/","id":"d791eaca9375ca1b36a987af22ee71dd","lang":"ja","lastmod":1521549285,"permalink":"https://blog.johtani.info/blog/2018/03/20/nlp100-ch01-05to06/","publishdate":"2018-03-20T21:34:45+09:00","summary":"Rustで言語処理100本ノックの続きで、05と06です。 05. n-gram 問題はこちら。 みんな大好きn-gramです。単語と文字があるので、それぞれ別関","tags":["Rust","nlp100"],"title":"第1章の05から06までやってみた（言語処理100本ノック）"},{"contents":"Rustで言語処理100本ノックの続きで、03と04です。\n03. 円周率 問題はこちら。\n入力文字列を.split_whitespace()で分割しておいて、単語ごとのベクタを作り出し、そこに対して文字を数えました。「アルファベットの」という注意書きがあるので\u0026quot;,\u0026ldquo;や\u0026rdquo;.\u0026ldquo;は含めずに数えるのかなということで、 charの.is_alphabetic()でA-zまでの判定をしつつ、文字のベクタを作ってから、そのベクタの長さを詰め込むという感じでやりました。\nこれ、ひょっとして、collectでベクタにしなくても、i32とかの変数でカウントするとベクタ作らなくてもいいなじゃにか？というのに書きながら気づいた。。。 必要じゃないオブジェクトを作ってるよなぁ。\n.filter().mapとかかな？この辺りの操作がイマイチ苦手。Javaでもまだ馴染めてないところなんだよなぁ。頭固すぎ。\n04. 元素記号 問題はこちら。\n大作ですね。何だろう、大作。。。 最終的に連想配列（辞書型もしくはマップ型）」ということだったので、BTreeMapに詰め込んでます。 HashMapでもいいんですが、文字列で出力した時にキーが並んで見やすいからという理由で、BTreeMap使いました。それ以上の理由はないです。普通にやるなら、HashMapかな？\n入力として、1文字だけの出力をする場所（インデックス番号）の配列を受け取ってます。1点だけ、チェックしていない、けど入力値の想定をしていて、idx_one_symbolsがソートされていて、小さいものから順番に出てくるものとしてます。関数作って、チェックすべきかな？\nで、指定された場所の最後のものが入力文字列よりも大きいかどうかというチェックもしています。（あー、テストケース書いてないな）この辺りのせいでちょっと長めになってます。\n単語の配列を作るのは03の時と同じやり方です。 回しかたがちょっと違って、.iter().enumerate()で回して、添字と値をタプル？でとりだしてます。添字を見ながら1文字取り出すのか、2文字取り出すのかの判断が必要だからです。あとは一緒ですね。1文字取り出すときは、.first()を使って見ました。 実は、2文字取り出す時と、1文字の時と同じロジック使った方が共通化できて、短くなった？？？\nということで、こんな感じでした。いつものようにツッコミお待ちしてます。\n所感 問題それぞれについてではなく、 やってて思ったのですが、問題に対して想定される結果が記載されていると嬉しいなと思いました。 ロジックについては、各自実装者に寄ったり、言語によって違いが出たりするし、議論するベースになっていいかなと思うんですが、 問題で想定されている結果（出力）があると、自分の実装にケアが足りないところがないのか？とか、ケアしなくていい点とかがわかるのかもなぁと。 ユニットテスト相当のものがあると楽かなぁと。\nこのケースどうするんだろ？みたいなのが、ところどころコメントに残ったりしてます。 出題の意図としては、その部分も議論の対象ということなのかな？\n","date":1519032848,"dir":"post/2018/","id":"e6684944c37dbdd4c08d978af9e47bed","lang":"ja","lastmod":1519032848,"permalink":"https://blog.johtani.info/blog/2018/02/19/nlp100-ch01-03to04/","publishdate":"2018-02-19T18:34:08+09:00","summary":"Rustで言語処理100本ノックの続きで、03と04です。 03. 円周率 問題はこちら。 入力文字列を.split_whitespace()で分割して","tags":["Rust","nlp100"],"title":"第1章の03から04までやってみた（言語処理100本ノック）"},{"contents":"「鉄は熱いうちに打て」ということで、言語処理100本ノックの第1章の00から02を実装してみました。\nさて、これが効率がいいのかどうかはさておき。\n00. 文字列の逆順 問題はこちら。\n最初、Vecのreverse()で逆順にして0からlen()まで回してたんですが、pop()がいい感じに後ろから取れることがわかったんで、切り替えました。 シンプルかな？\n01. 「パタトクカシーー」 問題はこちら。\n1文字ずつ取り出して、インデックスの番号が2で割ってあまりが0なら文字列に追加していくってのでやってみました。 （ブログ書いてるところで、i in 0..char_array.len()じゃなくて、(i, x) in char_array.iter().enumerate()に切り替えました。） matchとか使って綺麗に書けたりするのかなぁ？\n02. 「パトカー」＋「タクシー」＝「パタトクカシーー」 問題はこちら。\nだいぶ思考錯誤してる感じがソースに現れてます。 とりあえず、両方の文字列をcharsの配列にして個々のイテレータを回しながら、next()の戻り値があれば追加していく感じにして、 終了条件が両方Noneを通ったらにしてるけど、、、 なんか、もっと綺麗にできないのかなぁ。。。 next()のタプル返す関数作って、とかでなんかできたりするかなぁ？\ngist-it 関係ないですが、GitHubのコードを貼り付けるのに便利なサービスがあるみたいです。\nhttp://gist-it.appspot.com\nこれほんと便利だな。行数指定もできるし。 説明するのが簡単だ。\nとりあえず、今日はこの辺まで。なんか、いい知恵あれば教えてください！\n","date":1518699541,"dir":"post/2018/","id":"bbe1deec11d459bdb348051b970abdaf","lang":"ja","lastmod":1518699541,"permalink":"https://blog.johtani.info/blog/2018/02/15/nlp100-ch01-00to02/","publishdate":"2018-02-15T21:59:01+09:00","summary":"「鉄は熱いうちに打て」ということで、言語処理100本ノックの第1章の00から02を実装してみました。 さて、これが効率がいいのかどうかはさてお","tags":["Rust","nlp100"],"title":"第1章の00から02までやってみた（言語処理100本ノック）"},{"contents":"ども。新しいもの始めないと頭が退化する。。。ということで、こちら（ happy new year and new language - katsyoshiのめもみたいなもの）のブログに触発されて、言語処理100本ノックをはじめてみました。\n言語処理100本ノックとは、自然言語処理になるのかな、東北大学の研究室の先生が公開している言語処理に関する実践的な課題をベースにプログラミングなどのスキルを学んでいくための問題集です。 元々はPythonを対象とされているようですが、Rustでやってみようかと。 まぁ、先ほどあげたブログの二番煎じです。。。 ちなみに、インスパイアされた元のブログの方はRust book 2nd editionを読み終えたらしいですが、私はかじった程度です（ダメかも？）。\nNLPもRustもかじった程度なので、苦戦しそうですが、ちょっとずつやっていこうかなと。 ということで、準備運動の第1章から始めようかと。 GitHubにちょっとずつあげていく予定です。 https://github.com/johtani/nlp100-rust\nまぁ、まずは宣言のブログを書いてみただけです。 続いてなかったら、叱咤激励してください。叱咤だけかも？\n","date":1518605551,"dir":"post/2018/","id":"a673b3829e62477e01abc75465416b86","lang":"ja","lastmod":1518605551,"permalink":"https://blog.johtani.info/blog/2018/02/14/start-nlp100-with-rust/","publishdate":"2018-02-14T19:52:31+09:00","summary":"ども。新しいもの始めないと頭が退化する。。。ということで、こちら（ happy new year and new language - katsyoshiのめもみたいなもの）のブログに触発されて、","tags":["Rust","nlp100"],"title":"言語処理100本ノックはじめました(Rust)"},{"contents":"第1回では、Analyze UIというプラグインの紹介をしました、ごく簡単にですが。\n第2回では、Kibanaのプラグインの作成方法を順を追って見ていこうと思います。今回は、プラグインのプロジェクトの作り方を説明します。 どんなファイルがあるのかなどについては第3回で説明します（2018/02月現在の方法になります。残念ながら、Kibanaのプラグイン作成自体はまだExperimentalな話になっていますので、変更がある可能性があります）。\n実はそれほど難しいというわけではありません。Kibanaのプラグインを作成するためのテンプレートが用意されています。template-kiban-pluginです。 テンプレートのリポジトリのREADMEに作業手順の記載があります。\nKibanaのリポジトリをClone、Checkout Node.jsの環境を用意する Kibanaを起動できるようにする SAOのインストール テンプレートによるプロジェクトファイルの生成 順を追って説明します。 PLUGIN_DEV_DIRというディレクトリ配下で作業をしている想定になります。\n1. KibanaのリポジトリをClone、Checkout 開発環境として、Kibanaが必要です。Kibanaのプラグインを作るので。 手順などはKibanaのCONTRIBUTING.mdに記載があります。 ということで、まずはKibanaのリポジトリをCloneします。\ncd PLUGIN_DEV_DIR git clone git@github.com:elastic/kibana.git このままだと、masterブランチなので、開発したい対象のKibanaのバージョンのブランチもしくはタグをcloneします。今回は6.2.1向けということで、次のようになります。\ngit checkout v6.2.1 これで、ソースが6.2.1向けになりました。\n2. Node.jsの環境を用意する Node.jsをインストールします。 Kibanaのリポジトリに.node-versionというファイルがあります。 こちらにNode.jsのバージョンが記載されています。 Kibanaが使用しているNode.jsを利用できるようにします。ローカルではnvm利用してインストールしました。後から、切り替えが可能だからです。 nvm自体のインストールについてはnvmのサイトをご覧ください。 nvmがインストールできたら、次のコマンドで、Kibanaが使用しているバージョンをインストールします。\ncd kibana nvm install \u0026#34;$(cat .node-version)\u0026#34; すでにnvmを利用している場合などは、Kibana起動時にKibanaのバージョンに合わせたNode.jsに切り替えるようにしてください。\n3. Kibanaを起動できるようにする Kibanaではyarnというjavascript向けのパッケージマネージャーを利用して起動やビルドなどを行います。まずはyarnをインストールします。最近npmからyarnに切り替えたようです。 私はMacだったので、brewでインストールしました。 インストールできたら、次のコマンドを実行します。\nyarn これにより、package.jsonから必要なライブラリなどをダウンロードして来てくれます。 問題なければ「✨ Done in 439.30s.」というような表示がされます（結構時間かかりますね）。 では、Kibanaを起動できるか確認してみましょう。 さらに、Elasticsearchも起動してみます。 Kibanaのpackage.jsonの中にはElasticsearchを起動するためのスクリプトも用意されています。実際にはgruntを利用してタスクを実行しているようです。Elasticsearchの起動にはJavaが必要になります。 今回は6.2.1なので、JDK 8以降がインストールされている必要があります。 こちらはインストールされているものとします。\nyarn elasticsearch で起動できます。\n\u0026gt;\u0026gt; Started 1 Elasticsearch nodes. という表示が出てればOKです。 次にKibanaです。別のTerminalを起動して、以下のコマンドで起動できます。\nyarn start これだけです。\nserver log [06:58:56.930] [info][listening] Server running at http://localhost:5603 この辺りが出てればKibanaのServerは起動済みです。また、Elasticsearchに接続できていれば、次のログが出ているはずです。\nserver log [07:02:18.010] [info][status][plugin:elasticsearch@6.2.1] Status changed from red to green - Ready Elasticsearch接続用のKibanaのプラグインの状態になります。 これで、Kibanaの環境が整ったことが確認できました。 もちろん、Elasticsearchに関しては、yarnで起動せずに、tar.gzなどでダウンロードして来たElasticsearchを起動しておき、アクセスするといったことも可能です。プラグインなどをElasticsearchにもいれてテストしたい場合などはそちらの方が便利かもしれません。\n4. SAOのインストール では、一度、ElasticsearchとKibanaを停止しましょう。フォワグラウンドで起動しているので、それぞれのTerminalでCtrl+Cで停止できます。 Kibanaのプラグイン作成むけに、テンプレートが作られています。sao.jsというGitHubのリポジトリやnpmのパッケージをテンプレートとして使うことができるツールを利用してプラグインのプロジェクト（リポジトリ）を作成します。 実際にテンプレートとなるリポジトリはtemplate-kibana-pluginになります。 まずはSaoのインストールです。\nnpm install -g sao プラグインのテンプレートのページには上記のようにnpmを利用したインストール方法になっていますが、次のようにyarnでも可能です。\nyarn global add sao これで、saoがインストールできました。\n5. テンプレートによるプロジェクトファイルの生成 あとは、テンプレートを元にプロジェクトを作成します。 PLUGIN_DEV_DIRディレクトリ配下に、kibanaと同じ階層で作成するプラグイン用のディレクトリを作成します。\nmkdir simple-sample-kibana-plugin 以下のような構成になります。\nkibana simple-sample-kibana-plugin 次にテンプレートを適用していきます。\ncd simple-sample-kibana-plugin sao kibana-plugin@7.2.4 2行目がsaoを利用してプロジェクトを作成しているコマンドになります。 すると、次のような質問が出て来ます。 これらに答えるとプロジェクトに必要なファイル（package.jsonやREADME.mdなど）に入力した情報を適用したものを作ってくれます。\n? Name of your plugin? ? Provide a short description ? What Kibana version are you targeting? ? Should an app component be generated? ? Should translation files be generated? ? Should an hack component be generated? ? Should a server API be generated? 実際に答えた内容はこちら。\n? Name of your plugin? simple-sample-kibana-plugin ? Provide a short description Sample plugin for explaining how to make kibana app ? What Kibana version are you targeting? 6.2.1 ? Should an app component be generated? Yes ? Should translation files be generated? Yes ? Should an hack component be generated? Yes ? Should a server API be generated? Yes プラグインの名前などは、ディレクトリ名と同じものを入力補完してくれているので、そのままEnterでもOKです。 Descriptionについてはわかりやすいものを入力しましょう。 バージョンは、先ほどのKibanaのリポジトリに合わせて、6.2.1にしてあります。 あとは、作るプラグインの種類に応じて、必要なコンポーネントを作るかどうかの質問にYes/Noで答えます。 今回はサンプルの説明ということもあるので、全てYesで答えました。 ちなみに、私が実際に作成したanalyze-api-ui-pluginでは、appとtranslationとserverの3つを作成しました。 ただし、translationについては現在はテンプレートで作成したままのファイルが入っており、実際には利用してないです。\n完了したら、プラグインのサンプル入りのプロジェクトが完成です。 もう一度、Elasticsearchを立ち上げて、プラグインのプロジェクトからKibanaを起動してアクセスしてみます。まずは、PLUGIN_DEV_DIR/kibanaディレクトリの下で、Elasticsearchを起動します。\nyarn elasticsearch 次に、PLUGIN_DEV_DIR/simple-sample-kibana-pluginディレクトリの下で、以下のコマンドを実行し、プラグインが入った状態のKibanaを起動します。\nyarn start 問題なく起動すれば、ブラウザでアクセスすると次のような画面が表示されるはずです。\n左側にメニューが1つ増えています。 クリックすると、上記画像のような画面が表示されるはずです。\nこれで、カスタムプラグインの開発ができる環境ができました！ 次回は、プロジェクトのディレクトリ構成や、どんなツールが内部で使用されてデータのやり取りが行われているかについて説明します。お楽しみに。\n","date":1518167857,"dir":"post/2018/","id":"7b6cb59a177abe9767fd22da5a03b1e6","lang":"ja","lastmod":1518167857,"permalink":"https://blog.johtani.info/blog/2018/02/09/getting-started-template-kibana-plugin/","publishdate":"2018-02-09T18:17:37+09:00","summary":"第1回では、Analyze UIというプラグインの紹介をしました、ごく簡単にですが。 第2回では、Kibanaのプラグインの作成方法を順を追って","tags":["Kibana","plugin"],"title":"Analyze UIとKibanaのプラグインの作成方法（第2回）"},{"contents":"あけましておめでとうございます。今年はサボりがちだったブログをちょっとずつ復活させようかと。 ということで、第1弾として、昨年少し作っていたKibanaのプラグインを何度かに分けて紹介したいと思います。\n今回はAnalyze UIというプラグインの紹介です。\n今回はインストール方法と簡単な機能紹介です。 細かな紹介は個別にやりたいと思います。\nAnalyze UI pluginとは？ Elasticsearchの_analyzeというAPI\u0002(個人的に好きなAPIです)をご存知でしょうか？\nElasticsearchは全文検索エンジンで、データの検索には転置インデックスというものを使用します。 Elasticsearchにデータを登録する際に、text型のデータの場合、この転置インデックスのキーとなる単語を決める処理のことをAnalysisと呼びます（Analysisの詳細については割愛します。後日説明するかも？）。 このAnalysisの処理が、入力されたデータの文字列に対してどのように行われて、結果としてどんな単語がキーとして用いられているかを確認できる機能が_analyze APIです。検索で単語がうまくヒットしないな？とか、なんで、こんなので検索結果に出てくるんだ？といった場合、このAPIを利用すると、どのような単語で転置インデックスが作られているかがわかるので、検索にヒットしない/する理由を見つけることができます。\nElasticsearchの便利な点はRESTfulなAPI＋JSONでやりとりができる点なのですが、_analyze APIの結果をJSONで受け取っても、見るのにちょっと苦労します。。。こんな感じ。\nリクエスト：\nPOST _analyze { \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;今年はブログをいっぱい書きますよ！\u0026#34; } レスポンス：\n{ \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;今年\u0026#34;, \u0026#34;start_offset\u0026#34;: 0, \u0026#34;end_offset\u0026#34;: 2, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;ブログ\u0026#34;, \u0026#34;start_offset\u0026#34;: 3, \u0026#34;end_offset\u0026#34;: 6, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 2 }, { \u0026#34;token\u0026#34;: \u0026#34;いっぱい\u0026#34;, \u0026#34;start_offset\u0026#34;: 7, \u0026#34;end_offset\u0026#34;: 11, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 4 }, { \u0026#34;token\u0026#34;: \u0026#34;書く\u0026#34;, \u0026#34;start_offset\u0026#34;: 11, \u0026#34;end_offset\u0026#34;: 13, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 5 } ] } このくらいの量であればまだなんとかなりますが、文章が長くなると辛いですよね。\nということで、GUIがあると便利だろうなぁと。で、作ってみましたというのが今日紹介するKibana用のAnalyze UIプラグインです。 こんな感じで、Kibanaのアプリの一部として動作しブラウザ上で、入力テキストの文字列がどのようにanalyzeされて、単語になるかがわかります。\n（先ほどのAPIのサンプルと同じものを画面で入力した結果になります）。\nインストール方法 現時点の最新版Kibana（6.1.2）に対応しています。 Kibanaのディレクトリでkibana-pluginコマンドを利用してインストールします。\n./bin/kibana-plugin install https://github.com/johtani/analyze-api-ui-plugin/releases/download/6.1.2/analyze-api-ui-plugin-6.1.2.zip これだけです。 で、Kibanaを起動していただくと、左のメニューに「Analyze UI」という項目が増えています。\nクリックすると、Analyze UIが表示されます。\n初期画面は入力された文字を特定のAnalyzerで処理した場合の結果を見るための画面です。綱目の説明は画像をご覧ください。\n先ほどのJSONよりは見やすくなったかと思います。 そのほかにもいくつか画面や機能があるのですが、今日はこの辺りで。 「_analyze API便利なんだけど、JSONは。。。」とか「検索うまくできないなぁなんでだろう？」と思っている方は、ぜひ試して見ていただければと。 問題点などありましたら、GitHubのIssueを登録してください。\n","date":1516343806,"dir":"post/2018/","id":"4afcb20d4d95bcd1bde3aa6b7f552660","lang":"ja","lastmod":1516343806,"permalink":"https://blog.johtani.info/blog/2018/01/19/how-to-make-kibana-plugin-example-analysis-ui/","publishdate":"2018-01-19T15:36:46+09:00","summary":"あけましておめでとうございます。今年はサボりがちだったブログをちょっとずつ復活させようかと。 ということで、第1弾として、昨年少し作っていたK","tags":["Kibana","plugin"],"title":"Analyze UIとKibanaのプラグインの作成方法（第1回）"},{"contents":"今年は紅白を見ながら書いてます。 今年はいろんなところに出張に行ったなぁ。\n振り返り（2016年に書いた抱負から） まずは去年の抱負を元に。\nもちろん英語の継続 もちろん継続してます。英会話しながら海外TVドラマや映画を見てます。 ちょっとずつ英語字幕でも見ようとしてますが、まだまだだなぁ。 あと、TOEICを受けてないんで、それは受けないと。 見たドラマはこの辺です。\nER ウォーキング・デッド Agent of Shield SUITS Mr.Robot(いまいち話の展開についていけなかった) 継続的にイベントに登壇 OSCに今年もブース出してセッション持ってました。 勉強会ももちろんやりました。 あと、外部のカンファレンス（FOSS4G、BigData Analytics、db tech showcaseなど）や 勉強会(monitoring勉強会やCA.ioなど)にも登壇させていただきました。 もっと外部から読んでいただいたり、CfPに応募して通過できるようにしないとなぁ。\nもっと開発＆ブログ ブログはすみません。。。来年頑張ります。。。 ブログの代わりに書籍を出せました。データ分析基盤系の書籍になるので、興味のある方はのぞいて見ていただければ。\n開発はちょっとやってます。今年後半はKibanaのプラグインとかをちょっと書いてました。 Ingest-CSVもちょこちょこバージョンアップに追従してたりします。\nサポートエンジニア獲得！ 獲得しました！（自分の成果かどうかはわかりませんが。。。） 今は3名体制でサポートしてもらってます。おかげさまでだいぶサポートする機会が減ってきました。 開発は世界各地どこでも募集中だったりしますので、ぜひ連絡いただければと。\n個人的な検索勉強会の再開 再開しました。検索エンジン自作入門を知人と隔週くらいで読んでます。読んでるだけではあれなんで、実装もしてたり。全然違う言語でトライして見ようと思ったのでRustで書き始めてます。まずは、単純なところからと思ったんですが、 Rustの書き方の違いにだいぶ戸惑ってます。。。\n振り返り(今年あったできごと) ここからは今年の出来事を。\n初アメリカで釣り Nintendo Switch! 初Japanチームオフサイト チーム変更 初Berlin Buzzword! 母校（大学）訪問 Kibanaプラグイン開発 今年も初モノがちらほらとありますね。 今年もカレンダー振り返ってたら「え？これ今年だったの？」ってのがちらほらありました。。。\nアメリカで釣りやりました。自社のカンファレンスElastic{ON}のあとに、エンジニアが集まるミーティングがあるんですが、そこで1日Fun Dayがあって、そこで釣りをやりました。 魚群探知機とかで魚探すんですね、最近のは。2、3匹釣ったので非常に楽しかったです。 来年はスノーシューにチャレンジする予定。\nNintendo Switch買って、ゼルダやりました。今はイカやってます。 イカ欲はちょっと減ってるかもなぁ、1に比べると。 あとは、子供に買ったマリオやったりしてるかな。\nここ10年くらい行きたいと思っていたカンファレンス、Berlin Buzzwordに行ってきました！ これが今年一番嬉しかった出来事です。Luceneコミッターの方々にも会えたし。特にPoliceman JenkinsのUweさんに会えたのが本当に感激でした。。。 来年も行けるといいなぁ。。。\n今年も出張が多めだったのであちこち飛び回ってたなぁ。 そんな飛び回っている中で、故郷である広島（出身地？）に出張で行ったので、母校に顔を出してきました。 変わってなかった。。。自分が一期生なので、自分が入学した時はまだクレーンとか立ってるような新校舎だったんだけど、それが20年くらい経て、だいぶ古くなってました。。。 広島市内は港近くに高速道路とか出ててだいぶ様変わりしてました。 ただ、小学校も高校も変わってなかったなぁ。久々に高校の同級生にも会えたし。 また、機会があればぜひ行きたいなと。帰省する場所ではなくなったので、行く機会がないんですよね。。。\n開発もちょっとやってます。Kibanaのプラグインに挑戦して見てます。 いまだにJavaScriptは苦手なんですが。。。 ちょっとずつ改良して、ひょっとすると本体とかに取り込めるかな？ あとは、今年始めたRustをちょっとずつ継続して行きたいなと。\n来年の抱負 最後は来年の抱負を。\nもっと英語の継続＆TOEIC 継続的にイベントに登壇 CfPもっと出すぞ！ もっとブログ！ 雑誌やWeb系雑誌で記事を。 コミュニティを別の方法で盛り上げ Elasticsearchなど検索系の開発にも参加 英語はもちろんですね。今年は12月の自社イベントに合わせて多くのAPJチームの人が来て、 チームで会話できたし、もっと英語やらないとなぁと。前よりもちょっとは喋れるようになった気がしてます（気がしてるだけで、喋れてるかどうかは不明）。あとは、TOEIC受けて、実力チェックしてみないとなぁ。\nイベント登壇はまぁ、DevRelですから、一応。 来年もとりあえず、3月までは毎月どこかでブース出してます。 Ask Me Anything的なブースの出し方を今年はしてみようかなと思ってるので、 ちょっと使い始めたけど、この辺よくわからないと思ってる方、ぜひ質問しに来てください。 ブース出すだけじゃなくて、スピーカーとしていろんな場所で喋れるようにしないとなぁと。 もっと幅広く知ってもらえるように雑誌とかで連載できるようにしたいなぁと思ってます。 また、日本語の入り口の情報を増やすためにブログも書かないとなぁ。\n勉強会も継続しますが、別の方法でも盛り上げて行きたいなぁと。 勉強会はどうしても聞く人が多くて、ユーザーの間での交流や情報交換とまでは行ってない気がするし、discuss.elastic.coというフォーラムで質問は増えて来てるけど、もう少し交流しやすい場があると使ってもらえるかなぁ？と思っていたり。 何かおすすめとかあれば、連絡ください。 meetup.comの勉強会のページにも掲示板はついてるんだけど交流しにくそうだし。\n来年は自分が最も興味のある検索系の開発にも参加したいなぁと。 Elasticsearchをちょっとずつ時間見つけてやってたりはしますが、もう少し首を突っ込んで行きたいなぁと。Swiftypeもジョインしたし。もっと検索やって行きたい気持ちが強いので。\nさて、ということで、今年もあと1時間なくなりました。 今年も様々な面で色々な方々に助けていただけました。本当にお世話になりました。 この場を借りてお礼申し上げます。\n来年ももちろん、色々な方に助けてもらうと思いますが、よろしくお願いいたします！\n","date":1514723443,"dir":"post/2017/","id":"7c21b70f9e9c782c1f5153268e0cc1c1","lang":"ja","lastmod":1514723443,"permalink":"https://blog.johtani.info/blog/2017/12/31/looking-back-2017/","publishdate":"2017-12-31T21:30:43+09:00","summary":"今年は紅白を見ながら書いてます。 今年はいろんなところに出張に行ったなぁ。 振り返り（2016年に書いた抱負から） まずは去年の抱負を元に。 もちろ","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2017）"},{"contents":"Merry Christmas! Elastic Stack Advent Calendar 2017の24日目の記事になります。\nちょっとですが、2018年のElasticについて書いてみようかと思います。\nイベント いくつか出展が決まっているイベントがあるのでまずは宣伝を。\nOSC Osaka 2018 まずは、1月25日、26日にOSC Osaka 2018に出展し、話をします。参加者がいそうであれば、25日や26日の夜に勉強会もありかなぁと思っています。 セッションでは入門的な話をする予定です。ブースにいますので、色々質問がある関西の方はぜひご参加ください。\nDeveloper Summit 2018 2月15日、16日はDeveloper Summit 2018に出展します。 こちらでもブースにいますので、AMA（Ask Me Anything）的に使っていただくのもいいかなと。 デブサミに参加される方はぜひお立ち寄りください。\nManabiya 3月23日、24日はManabiyaに出展します。 こちらでもAMAのつもりでブースを出す予定です。質問がある方はぜひお立ち寄りください。 こちらのイベントは初めての開催になるようなので、どんなイベントになるか楽しみにしています。\nイベント回りはこの辺りで。 また、1月末に勉強会を予定しています。決まり次第またMeetup.comの方々にメールを出す予定です。\nElastic Stackの2018年は？ Canvas! 昨年のElastic{ON}でみなさんをCanvasがリリースされるかなぁと。 現在、みなさんにテストしてもらえるようにcanvas.elastic.coというサイトを公開中で、実際にインストールして試すことができるようになっています。 ぜひ、触って、全く新しいUIを体験して見てください。\nSQL? こちらも昨年のElastic{ON}でみなさんから反響があったものです。 もう直ぐでてくるのではないかなぁと。\nその他は？ いくつか面白そうで、取り込み済みのものをピックアップしておきます。\nAdd ranking evaluation API 検索クエリなどに対して検索結果のランクのクオリティを評価するためのAPIの追加（7.0予定） JDK9サポート？ 6.2でサポートされそうです。が、LTSのJDK8が推奨のままの予定です。 High-level REST ClientでいくつかAPIが追加 https://github.com/elastic/elasticsearch/pull/27574、https://github.com/elastic/elasticsearch/pull/27351 APM正式リリース？ ベータ版がリリースされているので、秒読み段階？ ということで より詳しく知りたい方は、サンフランシスコで開催されるElastic{ON} 2018に参加するのが一番です！（ステマ） 私も参加予定ですので、ぜひ、現地でお会いし、色々な情報をゲットしましょう。\n明日で、今年のAdvent Calendarも最後です。micci184さんの記事を楽しみにしましょう！\n","date":1514124616,"dir":"post/2017/","id":"f3a9b931b7f552a4f9dfa61ce4f39f0e","lang":"ja","lastmod":1514124616,"permalink":"https://blog.johtani.info/blog/2017/12/24/elastic-2018/","publishdate":"2017-12-24T23:10:16+09:00","summary":"Merry Christmas! Elastic Stack Advent Calendar 2017の24日目の記事になります。 ちょっとですが、2018年のElasticについて書いてみようかと思います。 イベント いくつか","tags":["elasticsearch"],"title":"2018年のElasticは？"},{"contents":"Elastic stack (Elasticsearch) Advent Calendar 2017の1日目の記事になります。\nまだ、1ヶ月を残していますが、簡単に今年起こったことを振り返ってみようかと思います。思った以上に色々ありましたね。。。\nElastic Stack 5.2.0リリース (1月) リリース記事はこちら\nHeatmapがKibanaで追加されたり、Heartbeatがベータですが追加されました。 個人的には、Terms aggregationのFiltering Valuesによるパーティションが便利になったと思います。Terms Aggsでページングに似たことができるようになりました。\nElastic{ON}17開催 (3月) 第3回目のユーザカンファレンスが開催されました。 バレーダンサーの踊りから始まったキーノート、様々なユーザ企業によるユースケース発表などいろいろありました。 セッションはこちらのサイトからから録画を見ることができます。 SQL for ElasticsearchやAwardが目を引いたと思います。SQL対応まだ出てきていないですが、もうすぐじゃないかと！\nElastic Stack 5.3.0リリース (3月) リリース記事はこちら\nFilebeat moduleが導入され、ログファイルを取り込んでKibanaで可視化するまでの手順がより簡単になりました。Elasticの目指しているものの一つに、シンプルな使い方、簡単にはじめられることといったものがあります。KibanaのTimepickerもより便利になったのも、このバージョンからです。\nShayがCEOに (5月) 2月にすでに発表されていましたが、Elasticsearchの生みの親のShay BanonがCEOに正式に就任しました。CEOになってさらに、精力的に様々なことをやっていて、本当にすごいなと思います。\nElastic Stack 5.4.0、6.0.0-alpha1リリース (5月) 5.4.0リリース記事はこちら、6.0.0-alpha1リリース記事はこちら\n5.4.0は節目になるリリースでした。Machine Learningがベータリリースとして、X-Packに追加されましたし、ElasticsearchではCross Cluster Searchの改善が進みました。LogstashではPersistent QueueがGAになりましたし、KibanaにはTime Series Visual BuilderやEvent Contextなどが追加されますます使いやすくなりました。\nまた、6.0.0のalpha版も同時にリリースされ、様々な方からのフィードバックが集まり始めました。\nElastic Cloud Enterprise GAリリース (5月) Elastic Cloudのバックエンドの技術を製品に採用したものになります。 多くのElasticsearchクラスタを管理しないといけない方には朗報でした。\nOpbeatがJoin (6月) Opbeatチームがジョインしたのが6月です。Elastic StackがAPM\u0002(Application Performance Monitoring)でも活躍することになりそうです。APMの仕組みとしては、APM Agentをアプリ側に配置し、APM Serverへデータを送信し、Elasticsearchに保存、Kibanaで可視化するという流れになります。\nElastic Stack 5.5.0リリース (7月) リリース記事はこちら\nMachime LearningがGAリリースになったのが5.5.0です。色々な方から質問を受けました。それ以外にも、ElasticsearchのWindows MSI InstallerやKibanaのFilter editorなどが追加されました。Filter editorはこれまで検索条件を記述するのが難しいと感じていたKibanaユーザにとても喜んでもらえたものじゃないかなと。 GrokDebuggerが導入されたのもこのタイミングです。\nElastic Stack 5.6.0リリース (9月) リリース記事はこちら\n5系最後のマイナーリリースであり、6へのアップグレードが楽になる様々な仕組みが用意されたのがこのバージョンです。ElasticsearchのJava High level REST clientが導入されたのもこのバージョンです。本当に様々な機能が次のメジャーバージョンとの互換性のために組み込まれています。。。\nElastic Cloud on GCP (9月) リリース記事はこちら\nこれまで、AWS上のみで展開していたElastic CloudがGCP上でも展開されることになりました。残念ながら、日本リージョンはまだありませんが、問い合わせなどが増えれば今後サポートされる可能性が高くなると思います！\nElastic APM alpha (9月) リリース記事はこちら\nOpbeatチームによりElastic StackのAPMがAlphaですがリリースされました。APMがOpen Sourceで利用できるんです！Agentがもっと増えてくると色々なことに使えるようになると思います。ぜひAgentを作成してみてください！\nElastic Stack 6.0.0リリース (11月) リリース記事はこちら\n待ちに待った6.0.0のリリースです。新機能については本日(12/1)の昼に行われるウェビナーをご覧ください！\nSwiftypeがJoin (11月) ニュースリリースはこちら\nSwiftypeと呼ばれる検索のSaaSを提供している会社がジョインしました。 個人的には今年一番嬉しいニュースです。やはり、検索が好きなので。 簡単にSite Searchを構築できる仕組みは非常に面白いものです。 興味のある方は、ぜひ触ってみてください。日本語固有の機能などはまだないので、今後関わっていければなーと。\nElastic{ON} Tour Tokyo開催 (12月) まだ開催前ですが、今年も東京で1dayイベントを開催します。 残念ながら、もうSold outなので、キャンセル待ちになってしまっているみたいですが。私もスピーカーとして喋りますし、AMAブースにも立っています。 参加される方はぜひ声をかけていただければと思います。\nOSC 2017.Enterprise (12月) オープンソースカンファレンスで今年も様々な都市に出張しました。 今年の締めくくりということで、12/8に渋谷で開催されるカンファレンスに出展します。時間のある方は、ぜひブースに遊びに来てください。入門者向けのセッションもあるので、こちらもお待ちしております。\nまとめ 超駆け足ですが、今年を振り返ってみました。 今年もいろんなことがありました。書くのが大変だったw。 OSCなどイベントで声をかけていただいた皆様、ありがとうございました。\nさて、Elastic Stack Advent Calendar 2017は始まったばかりです。これからの記事を楽しみにしています！\nということで、 次はaeroastroさんの「Elasticsearchのインデックスを本当の意味で無停止再構築する方法」（Advent Calendarのページはこちら）になります、お楽しみに！\n","date":1512054000,"dir":"post/2017/","id":"fa0486610d8a02cea245c13c85b6de27","lang":"ja","lastmod":1512054000,"permalink":"https://blog.johtani.info/blog/2017/12/01/whats-happen-at-elastic-in-2017/","publishdate":"2017-12-01T00:00:00+09:00","summary":"Elastic stack (Elasticsearch) Advent Calendar 2017の1日目の記事になります。 まだ、1ヶ月を残していますが、簡単に今年起こったことを振り返ってみようかと思います。思った以上に","tags":["elasticsearch"],"title":"2017年のElastic StackとElastic"},{"contents":"Swiftypeでサイト内検索？ プレスリリース：Elasticがサイト内検索サービス最大手のSwiftypeを買収が出ましたが、SwiftypeチームがElasticにジョインしました！\n自分のブログ検索に導入してみる？ SwiftypeはSite Searchをサービスとして提供しています。 実際に指定したサイトのデータをクロールして、インデキシングし、検索できるようになります。 ものは試しということで、自分のブログを登録してみました。検索窓はつけてないですが。 14日間のFree trialがあるのでそちらで試してみましょう。 検索窓はデモとか作れたらかな。\nということで、Free trialへ まずはユーザ登録です。Googleのアカウントと連携するか、Swiftypeにメルアドを登録するかが選択できます。 登録できたら、次にどちらのプロダクトを使うかという選択画面が出てきます。 今回はサイト検索して見たいので、「Site Search」の「START FREE TRIAL」をクリックします。\nEngineの指定 Web Crawlerを利用するか、独自にSwiftypeのAPIを利用してデータを登録するかを選択します。\n今回は、お手軽な方のCrawlerを選択します。 すると次に、クロールしたいURLの指定画面が出てきます。\n今回は自分のブログなので、\u0026lsquo;http://blog.johtani.info\u0026rsquo;を指定します。\nで少し待つと、URLのチェック（存在チェックとか、接続チェックとか）が終わり、今回作成するEngineに名前をつける画面が出てきます。 「My Blog search」という名前にしてみました。\nsitemapがあるかどうかをCrawlerがチェックしています。 私のBlogはOctopressでできていて、sitemap.xmlも作ってくれているので、これを元にCrawlerはクロールをしてくれます。そのほかにもRSSやAtomサポートもあるみたいですね。 「COMPLETE SETUP」を押すと、Engineの管理画面が出てきます。\n「CRAWLING」という表示が出ています。クロールしている最中です。これが終われば、「PREVIEW」に代わり、検索できる準備ができたことになります。 実際にPREVIEWして見ると、次のような検索ができるようになります。\nそのほかにはWeightの調整画面などもありますね。フィールド毎に重み付けを変えて見たりもできます。\n日本語独自のAnalyzerなどはまだないので、そのあたりができてくるともっと便利になりそうです。 とりあえず、気になる方は触って見てはいかがでしょうか？ 個人的は検索に関するサービスが出てきたのですごく楽しみにしています！\n","date":1510280089,"dir":"post/2017/","id":"c20d71627e66a044b21780f56f2f9504","lang":"ja","lastmod":1510280089,"permalink":"https://blog.johtani.info/blog/2017/11/10/welcome-swiftype/","publishdate":"2017-11-10T11:14:49+09:00","summary":"Swiftypeでサイト内検索？ プレスリリース：Elasticがサイト内検索サービス最大手のSwiftypeを買収が出ましたが、Swifty","title":"Swiftypeがジョインしたので触ってみました"},{"contents":"久々に執筆しました。といっても、以前の書籍の更新版です。 まぁ、更新版といっても、私以外の方々は結構な量を書き直しor新規書き起こしされてますが。。。\nということで、みなさん「買って」から感想をいただけるとうれしいです！\u0002（以下の画像でAmazonにジャンプできます！Kindle版も発売中です。）\n今回もElasticsearchの章を担当しました。 5.4ベースで書きましたが、ちょっとずつ6でどう変わるかなども記載してあります。 また、付録ではLogstashやBeatsにもちょっと触れています。 また、自分が一番好きなKibanaの機能であるDev ToolsのConsoleについても記載してあります。こちらも合わせて目を通していただければと。\nみなさんのフィードバック（ツイート、ブログ、Amazonのコメントなどなど）をお待ちしております！\n","date":1505955750,"dir":"post/2017/","id":"4f88f3eebe44285ded812939553ef94c","lang":"ja","lastmod":1505955750,"permalink":"https://blog.johtani.info/blog/2017/09/21/release-intro-logging-analysis-system/","publishdate":"2017-09-21T10:02:30+09:00","summary":"久々に執筆しました。といっても、以前の書籍の更新版です。 まぁ、更新版といっても、私以外の方々は結構な量を書き直しor新規書き起こしされてます","tags":["elasticsearch","kibana","本"],"title":"データ分析基盤構築入門 を一部執筆しました。"},{"contents":"久々のブログ。 Elasticsearch勉強会を主催してますが、 プロダクトを超えて、検索で共通してある課題とか、悩みとか、あるかなぁと。 その辺りを話す場所を考えてみるのいいかもと思い、検索座談会ってのを5人でやってみた。\nとりあえず、初めてなので、5名ほどで。プロダクトはかぶってない感じでした。\n話した議題はこの辺り。 形態素解析の辞書は何を使ってる？有償のもの？ そもそも形態素解析？ 辞書の更新とかは？ シノニムってどうしてる？ サジェストとかのデータはどう作ってる？どうしてる？ 検索ログとかから作ってる？ 検索結果のランキングって検索結果だけで決めるの？ 検索漏れとかキーワードのミスマッチとかどうしてる？ 今後話したい内容はこの辺かな？ 緯度経度系の検索 画像検索、音声検索 検索のキーワードの調査とかしてる人とかいるかな？ どんな機能が欲しい？ 前処理としてはどんなことをしてる？ このあとどうしていくかはまだ考え中。知り合いを捕まえて、どんなことしてるかを聞きにいくのもいいし、議題みたいなことを決めて、それを話してくれそうな人にコンタクトして議論するのもありかなぁ。 普通の勉強会みたいなのにするかもしれないし。 とりあえず、どのくらい興味を持ってる人がいるのかがわからないので。。。\nもちろん、Elasticsearch勉強会は別でやっていきますよ。\n","date":1495639453,"dir":"post/2017/","id":"29b4c2b5adcd80ced1612128b3ca95a9","lang":"ja","lastmod":1495639453,"permalink":"https://blog.johtani.info/blog/2017/05/25/search-meetup/","publishdate":"2017-05-25T00:24:13+09:00","summary":"久々のブログ。 Elasticsearch勉強会を主催してますが、 プロダクトを超えて、検索で共通してある課題とか、悩みとか、あるかなぁと。 その","tags":["勉強会"],"title":"検索座談会ってのをやってみた"},{"contents":"今年はRioのプレイバック\u000e見ながら書いてます。 今年はなんか長い一年だった気が。\n振り返り（2015年に書いた抱負から） まずは去年の抱負を元に。\n英語の継続 継続してます。まぁ当たり前ですが。もう少し話す機会増やさないとだなぁと思いつつ。英会話しながら、海外TVドラマ見ながら。 見たドラマはこの辺かな？\nER SUITS メンタリスト Numb3rs エレメンタリー Agent of Shield あと、映画も見てます。とりあえず、耳を慣らすために字幕ありで見てるので、 英語だけでとは行きませんが。。。 そろそろ同じ映画を英語字幕で見るとかしたほうがいいのかもなぁ。\nもっとElasticsearchの開発に参加 一応参加してます。ちょっとずつですが。 イベントが重なるとできなくなるので、小さなPRとかを細々とって感じですが。。。\n人員の倍増？ 倍増したかな？現時点で日本は8名になりました。そのうち1人は完全リモートです。 来年も倍増とは行かないだろうなぁ。取り急ぎ、サポートエンジニアが足りてないのでそこを埋めないと。。。\n日本語情報発信 これはちょっと足踏みしてるかも。ブログの翻訳とかはやってるんですが、もう少しなんとかしないとなぁ。ブログも書かないと。。。\nSplatoon S+? なりました！とりあえずS+とSを行ったり来たりしてる感じです。 メインはノヴァネオですが、Sに落ちたら違う武器でS+に上がるまでチャレンジするってのをやってます。わかば、バケスロソーダ、プライム、ワサビくらいはやったかな？ そろそろまた違う武器かなぁ。S+99は無理そうなんで。。。\n振り返り(今年あったできごと) その他の今年の出来事。\n初香港 初プラハ OSCなど、東京以外でのカンファレンス参加 厄年 東京オフィス！ BBLとかトレーニング lucene-gosenをちょっとメンテ Podcastデビュー？ 初モノ今年も多いかな。 今年は、昨年よりは長く感じた一年でした。 月1くらいで出張してたのもあるのかなぁ？ 香港、プラハはもちろん会社のイベントです。 香港はジャッキーチェンの映画を彷彿とさせるところがちょくちょくあって面白かったです。 ビルとかの補修の足場が竹竿とか。 プラハも面白かったです。やっぱりヨーロッパの古い町は歴史のある建物が多くて楽しいです。\nOSCなどのイベントも色々行きました。福岡、名古屋、大阪、京都、札幌と回りました。 それとは別に大阪、福岡も行ったかな。 来年は沖縄と広島に行きたいなぁ。。。 出張のついで？じゃないですが、御朱印集めし始めました。神社仏閣もいいですよねぇ。\n厄年はきつかった。。。たまたまだとは思うけど、お祓いに行ったのが効いたのかなぁ。後半は特に問題なかったかな。腕時計無くしたと思ったら見つかったりしたし。\n弊社東京オフィスができました。（あんまり行ってないけど） ときどきアクロクエストさんがセミナーを開いたりしてます。 昨年のTour Tokyo後のMeetupでもイベントスペースを使って、Drinkup（勉強会の懇親会だけバージョン）もやりました。 今後もちょこちょことイベントをやってみようかな？\nBBLも始めました。あまりきちんと宣伝してないからそれほど依頼は来てないですが。 あとは、今年も2回日本語でトレーニングしました。 前回はほぼ満席にまでなりました。 来年も頑張りたいかな。ショートカットするためにもいいと思うんで、トレーニングを受けて欲しいんです。。。\nlucene-gosenのメンテもしました。 といってもプログラムではなく、ビルドシステムをAntからGradleに変更したんですが。 来年もちょっとずつ触りたいな。機能面で拡充するかはわからないですが。。。\nPodcastにもデビューさせていただきました。 wyukawaさんのPodcastです。「johtaniさんとElasticsearchについて話しました」楽しかったです。 また出たいなぁというか、喋るの面白かった！\n来年の抱負 もちろん英語の継続 継続的にイベントに登壇 もっと開発＆ブログ サポートエンジニア獲得！ 個人的な検索勉強会の再開 英語はまぁ、当たり前ですね。会社の人つかまえてもっと喋る時間増やさないとだな。\n来年もいろんなカンファレンスなどに出てブース出したり、セッション持ったりして もっともっと広めていかないとなぁ。 あとは、勉強会とMeetupもやっていかないと。入門編と上級編みたいに分けてみるのもありかなぁと考えて見たり。 スピーカー、ご意見募集しております。\n開発に時間をさくための時間の活用をしていかないとなぁと。 どうも時間の使い方がまだ上手くないので。ブログも一緒ですね。。。 月1くらいのペースではかきたいな。。。 ブログもそうだけど書籍もかな？？？？ あと、外資系の他の会社の人ともまた飲みたいなー。\n開発の時間を確保という面ではサポートエンジニアも募集中です。 最近、クライアントが増えて来てチケットが増えて来てるんで、サポートしたりもしてるんです。。。 自分の時間を増やすためにもサポートエンジニアを確保しないと。誰かいい人いないかなぁ。\n個人的にやってた勉強会を忙しいって言って中断してるので、再開しないと。。。\nということで、今年もあと數十分になってしまいました。 今年も色々な方に助けていただけました。お世話になりました。 この場を借りてお礼申し上げます。\n来年もいろんな方々に助けてもらうと思いますが、よろしくお願いいたします。\n","date":1483190534,"dir":"post/2016/","id":"16f1046144ad9ee7bb96214ba7ae7516","lang":"ja","lastmod":1483190534,"permalink":"https://blog.johtani.info/blog/2016/12/31/looking-back-2016/","publishdate":"2016-12-31T22:22:14+09:00","summary":"今年はRioのプレイバック\u000e見ながら書いてます。 今年はなんか長い一年だった気が。 振り返り（2015年に書いた抱負から） まずは去年の抱負を元に","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2016）"},{"contents":"Merry Christmas! Elastic stack Advent Calendar 2016 最終日の記事になります。\n簡単に今年の変遷を振り返ってみます。\nElasticsearch 2.2 (2月) Elasticsearch 2.2.0、2.1.2、1.7.5リリース クエリプロファイラやGeo系の性能改善などが取り込まれました。 また、同時期にリリースされたKibana 4.4ではColor pickerやShare用のURLの短縮化機能なども追加されました。\n第2回目のユーザカンファレンス、Elastic{ON}開催（2月） サンフランシスコで、弊社第2回目のカンファレンスが開催されました。 2015年の会場よりも大きくなり、多数の方に参加いただきました。 ここで、以下の発表がありました。\nElastic StackとX-Packの紹介 これまで、ELK stackと呼ばれて意味明日が、Beatsチームの参加により、ELKだけではなくなったこともあり、Elastic Stackと呼び名を変える事になりました。 また、Marvel、Shield、Watcherなどの商用の拡張機能についても、 単体の名称ではなく、X（Extension）-Packと1つの名前になる事に。 詳細については公式のブログをご覧ください。\nElastic CloudとElastic Cloud Enterpriseの発表 2015年にElasticにジョインし、 これまでFound.no（Found）と呼ばれていた弊社のElasticsearch as a ServiceがElastic Cloudと名称変更しました。 また、Elastic Cloudで培っているノウハウを詰め込んだElastic Cloud Enterpriseも発表しました。実際に利用可能になるまでには まだもう少しかかってしまいますが、アルファ版が公開されていますので、興味のある方は触ってみてください。\nElastic{ON}2016で撮影された、「Elasticsearchがないあなたの人生はどうなりますか？」 といった面白い動画も公開されています。\nElasticsearch 2.3リリース（3月） Elasticsearch 2.3.0および2.2.2をリリース Reindex APIが登場し、Mappingの変更やShard数の変更など、色々とデータの更新などがやりやすくなりました。 また、Task Managementの機能も追加され、長時間かかる処理を間違った場合などの対処が楽になりました。 個人的には、Deprecation Loggingの機能が導入されたことが嬉しいこととなります。次期メジャーバージョンで廃止される機能についてログに出力されるようになりました。 実際に運用されているアプリで利用している機能が今後なくなるかどうかをログを見るとわかるという仕組みです。\nRally登場（4月） Rally登場：Elasticsearchのベンチマークツール Elasticsearchのベンチマークツールがリリースされました。 定期的にElasticsearchの性能を計測することは問題点を見つける事に役に立ちます。そういった手助けをしてくれるツールが公開されることは非常に便利なことかと。\nElastic Stack 5 alpha1 リリース（4月） Elastic Stack 5.0.0 alpha 1 リリース Ingest NodeやLucene 6、新しいKibanaのUIなど多くのものが詰まっていました。ここから多くのユーザにテストしてもらい、5.0の正式リリースを迎えることができました。\nElasticsearch 2.4.0リリース（8月） 2.xの最後のマイナーバージョンリリースです。 Reportingなどの追加とドットつきフィールド名の復活がありました。\nElastic Stack 5.0.0 beta1 リリース（9月） Elastic Stack Release - 5.0.0-beta1 ついにベータです。Painlessがスクリプトのデフォルトになったり、TimelionがKibanaに取り込まれるなど、正式リリースまであと少し！\nPrelertチームジョイン（9月） Welcome Prelert to the Elastic Team Machine Learningエンジンを開発し、Elasticsearch,Kibanaとの組み合わせの製品をリリースしていたPrelertという会社がジョインしました。 Elasticsearchに保存された多くのデータをより活用していただくことができるかと思います。 Elastic{ON} Tour 2016 Tokyoで弊社SAの大輪の発表も人気があるものでした。まだベータ段階ですが、利用して見ることも可能です。 ビデオなどが公開されたらまたツイートしようと思います。\nElastic{ON} Tour Tokyo 2016開催（12月） 今年で2回目のTokyoローカルの1日イベントでした。 ブログは「まだ」書いてませんが、、、今回も盛りだくさんのイベントになりました。 早朝のトレーニング（ハンズオンではない）にも80名近くの方に参加していただけましたし、私はKibanaのキーノート＋デモという大役をもらいましたし、ちょっと大変でした。 今年もAMA（Ask Me Anything）ブースが大盛況でした。 色々な方から、弊社のサポート、開発者が色々な質問を受け、それに答えるという形です。楽しんでいただけたかと思います。 来年もぜひ開催したいなと思っています。\nまた、Elastic{ON}17のセッションもいくつか発表されています。 ぜひ、サンフランシスコで行われる本場のカンファレンスにもご参加ください！\n来年は？ 1月後半か2月にElasticsearch勉強会を検討しようと思っています。スピーカーに興味のある方は連絡いただければと。\n会社としては、Elastic{ON}2017が3月にまた開催されます。これで3回目となります。もちろん私も参加予定なので、参加される方は、現地で会いましょう！\nそのほかにもBIG DATA ANALYTICS TOKYOやオープンソースカンファレンス（大阪）、デブサミといったカンファレンスに参加（登壇・ブースなど）予定です。 参加される方は、ぜひブースまでお越しください。\nでは、また来年のAdvent Calendarでお会いしましょう！\n","date":1482591830,"dir":"post/2016/","id":"002d980d74d19b43ff4e2446665e2fe5","lang":"ja","lastmod":1482591830,"permalink":"https://blog.johtani.info/blog/2016/12/25/elasticsearch-6-features/","publishdate":"2016-12-25T00:03:50+09:00","summary":"Merry Christmas! Elastic stack Advent Calendar 2016 最終日の記事になります。 簡単に今年の変遷を振り返ってみます。 Elasticsearch 2.2 (2月) Elasticsearch 2.2.0、2.1.2、1.7.5リリース クエリプロ","tags":["elasticsearch"],"title":"2016年のElastic Stack"},{"contents":"Elastic stack Advent Calendar 1日目の記事になります。\nElasticsearch 5.0が10月末にリリースされました。 リリースのブログでいくつか紹介されているのですが、そこでは紹介されていない機能について2、3紹介しようと思います。\nその前に、5.0、あれ？その前は2.xじゃなかったっけ？？と困惑されている方もいるかと思うので、簡単に5となった経緯の紹介をしようかと。\nバージョン番号 なぜ2から5に飛んだのかという話ですが、このスライドがその紹介になっています。\nhttps://speakerdeck.com/johtani/elastic-stack-5-dot-0-alpha1-alpha5?slide=5\nElastic{ON} 2016のキーノートでも紹介がありましたが、KibanaやLogstashとElasticsearchを組み合わせて使うときにバージョンのミスマッチで動かないというユーザの声が上がっていました。 2.xのリリースから、同じ日にKibana、Logstash、Beatsもリリースするようになったのですが、 やはり、バージョン番号が異なるため、ミスマッチで動かないというユーザが時々いました。\nElastic Stackという名称にもなったため、バージョン番号をそろえようという事になり、 Elasticsearch、Kibana、Logstash、Beats全てが5.0.0としてリリースされ、 今後は同じバージョン番号になります。\nちなみに、「5」になった理由はKibanaのメジャーバージョンが「4」だったためです。\nさて、では、いくつか機能の紹介を。\nReindex from remote cluster Reindexが2.3から導入されました。データの再登録ができるようになり、マッピングの変更や Shardの数の変更などが柔軟に行えるようになりました。 便利でしたが、あくまでも同一のクラスタでデータを登録し直す形でした。\n5.0からはこの機能に加えて、異なるクラスタからデータを取得してReindexを行うことができるようになりました。 こんな形になります。\nPOST _reindex { \u0026#34;source\u0026#34;: { \u0026#34;remote\u0026#34;: { \u0026#34;host\u0026#34;: \u0026#34;http://otherhost:9200\u0026#34;, \u0026#34;username\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;password\u0026#34;: \u0026#34;pass\u0026#34; }, \u0026#34;index\u0026#34;: \u0026#34;source\u0026#34;, \u0026#34;query\u0026#34;: { \u0026#34;match\u0026#34;: { \u0026#34;test\u0026#34;: \u0026#34;data\u0026#34; } } }, \u0026#34;dest\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;dest\u0026#34; } } usernameとpasswordはリモートのクラスタに認証の気候が存在する場合に利用できるオプションです。 また、ReindexのAPIはクエリを使用して、必要なデータだけを取得することが可能です。 この機能により、1.xや2.xのクラスタからデータを移行することが可能になります。\nCustom analyzer test using Analyze API もう一つ、ちょっとだけ便利な機能を紹介します。 独自にAnalyzerを定義（TokenizerとToken Filterなどを個別に設定）して、その挙動を確認するとき、2.xまでは、インデックスを作成してそのインデックスに対して_analyze APIを呼び出す必要がありました。\n5.xからは_analyze APIの読み出しのパラメータで指定できるようになりました。 こんな感じです。ここでは、lowercaseフィルタのあとに、{...}でstopフィルタを パラメータの中で、指定しています。\ncurl -XGET \u0026#39;localhost:9200/_analyze\u0026#39; -d \u0026#39; { \u0026#34;tokenizer\u0026#34; : \u0026#34;whitespace\u0026#34;, \u0026#34;filter\u0026#34; : [\u0026#34;lowercase\u0026#34;, {\u0026#34;type\u0026#34;: \u0026#34;stop\u0026#34;, \u0026#34;stopwords\u0026#34;: [\u0026#34;a\u0026#34;, \u0026#34;is\u0026#34;, \u0026#34;this\u0026#34;]}], \u0026#34;text\u0026#34; : \u0026#34;this is a test\u0026#34; }\u0026#39; ちょっとだけですが、Analyzerなどを試すのが楽になるのではないでしょうか？\nということで、以上が1日目の記事でした。 Logstashなど、他の5.0.0に関する記事もAdvent Calendarに空きがあるようなので、個別にかこうかなと思います。お楽しみに！\n","date":1480581270,"dir":"post/2016/","id":"550becdd08d00fb1e7fd00c2adc3d3d6","lang":"ja","lastmod":1480581270,"permalink":"https://blog.johtani.info/blog/2016/12/01/elasticsearch-5-dot-0-highlight/","publishdate":"2016-12-01T17:34:30+09:00","summary":"Elastic stack Advent Calendar 1日目の記事になります。 Elasticsearch 5.0が10月末にリリースされました。 リリースのブログでいくつか紹介されているのですが、そこでは紹介されて","tags":["elasticsearch"],"title":"Elasticsearch 5.0の便利機能紹介？"},{"contents":"久しぶりに、技術的なブログ書いてます。\nIngest Processorのプラグインを作ってみたくなったので、書いてみました。 ただ書いてみるんじゃ3番煎じになりそうなので、cookiecutterを使ってみました。\nと言っても、同僚のAlexがcookiecutter-elasticsearch-ingest-processorと言うテンプレートを作ってくれているのを使っただけですが。（https://discuss.elastic.co に投稿された記事で、使い方がアニメgifで説明されててわかりやすいです）\ncookiecutterとは、コマンドラインで質問に答えると、テンプレートからプロジェクトが生成できるツールです。 Elasticでは、カスタムBeatを作る時に利用する例がいつかの日本語ブログや発表資料で話題になっていました。 これのIngest Processorのプラグインバージョンです。\n今回は、NEologdも使ってみたかったので、Lucene Kuromoji for NEologdを利用して 指定した品詞の単語だけを抽出するProcessorを作ってみました。\nGitHubのプロジェクト：https://github.com/johtani/elasticsearch-ingest-kuromoji-pos-extract\nCookiecutterの使い方 Cookiecutterのインストールはサイトをご覧ください。\ncookiecutter gh:spinscale/cookiecutter-elasticsearch-ingest-processor あとは、出てくる以下の項目を指定するだけです。\nprocessor_type : Ingest Processorのタイプ名です。kuromoji_part_of_speech_extractとしました。（Alexのだと_を使うとちょっと問題があるので後述） description : readme.mdに利用されます。 developer_name : 名前を記載。Javaのファイルのヘッダに利用 elasticsearch_version : デフォルトで5.0.0-alpha4が指定されているので、特に指定せず 以上の質問に答えたら、プロジェクトのディレクトリ構造が出来上がってます。 プロジェクトのビルドなどにはGradleを利用します。\nプロジェクトのIntelliJ IDEA用のファイルを生成 build.gradleファイルでGradleのideaプラグインがapplyされているので、以下のコマンドを叩けばIntelliJ IDEAのプロジェクトファイル（？）が生成され、IntelliJで開けばすぐに開発ができる状態にできます。\ngradle idea コーディング あとは、必要処理をコーディングします。 実際にコーディングするクラスはorg.elasticsearch.plugin.ingest.kuromoji_part_of_speech_extractのパッケージにある以下の2つです。（パッケージ名にはprocessor_typeの名前が指定されている）\nIngestKuromojiPartOfSpeechExtractPlugin KuromojiPartOfSpeechExtractProcessor IngestKuromojiPartOfSpeechExtractPlugin Pluginというクラスは、プラグインをNodeのModuleとして登録する処理を書くクラスとなります。 生成してすぐは、次のような形になっています。（※importやクラス定義の部分は省略しています。）\n... public static final Setting\u0026lt;String\u0026gt; YOUR_SETTING = new Setting\u0026lt;\u0026gt;(\u0026#34;ingest.kuromoji_part_of_speech_extract.setting\u0026#34;, \u0026#34;foo\u0026#34;, (value) -\u0026gt; value, Setting.Property.NodeScope); @Override public List\u0026lt;Setting\u0026lt;?\u0026gt;\u0026gt; getSettings() { return Arrays.asList(YOUR_SETTING); } public void onModule(NodeModule nodeModule) throws IOException { nodeModule.registerProcessor(KuromojiPartOfSpeechExtractProcessor.TYPE, (registry) -\u0026gt; new KuromojiPartOfSpeechExtractProcessor.Factory()); } ... YOUR_SETTINGプロパティとgetSettings()メソッドはelasticsearch.ymlで指定したい設定を記述する場合の例になります。今回は特に必要ないので両方削除しました。 最終系はGitHubのコードをご覧ください。\nKuromojiPartOfSpeechExtractProcessor Processorは実際にIngest Nodeで行う処理を書くところです。\npublic static final String TYPE = \u0026#34;kuromoji_part_of_speech_extract\u0026#34;; private final String field; private final String targetField; public KuromojiPartOfSpeechExtractProcessor(String tag, String field, String targetField) throws IOException { super(tag); this.field = field; this.targetField = targetField; } @Override public void execute(IngestDocument ingestDocument) throws Exception { String content = ingestDocument.getFieldValue(field, String.class); // TODO implement me! ingestDocument.setFieldValue(targetField, content); } @Override public String getType() { return TYPE; } public static final class Factory extends AbstractProcessorFactory\u0026lt;KuromojiPartOfSpeechExtractProcessor\u0026gt; { @Override public KuromojiPartOfSpeechExtractProcessor doCreate(String processorTag, Map\u0026lt;String, Object\u0026gt; config) throws Exception { String field = readStringProperty(TYPE, processorTag, config, \u0026#34;field\u0026#34;); String targetField = readStringProperty(TYPE, processorTag, config, \u0026#34;target_field\u0026#34;, \u0026#34;default_field_name\u0026#34;); return new KuromojiPartOfSpeechExtractProcessor(processorTag, field, targetField); } } TYPEがIngest APIのPipelineでProcessorを指定するときに使う名前になります。ここは、cookiecutterの時にprocessor_typeに入力した文字列になっています。 kuromoji_part_of_speech_extractだと長いので、kuromoji_pos_extractに変えました。\nexecute()メソッドに// TODO implement me!とあります。 この部分に実際の処理を記述していきます。\nあとは、FactoryクラスでIngest APIで指定された設定項目を読み込みます。 今回作成したelasticsearch-ingest-kuromoji-pos-extractでは品詞を指定する必要があるので、pos_tagsを指定できるように処理を追加しました。\n私が実装したものの説明をするとちょっと長くなりそうなので、GitHubのコードをご覧ください。\nテストのコーディング テストのクラスもテンプレートで生成されています。\nKuromojiPartOfSpeechExtractProcessorTests KuromojiPartOfSpeechExtractRestIT KuromojiPartOfSpeechExtractProcessorTests Processorクラスのテストになります。生成直後は次のような感じです。\npublic void testThatProcessorWorks() throws Exception { Map\u0026lt;String, Object\u0026gt; document = new HashMap\u0026lt;\u0026gt;(); document.put(\u0026#34;source_field\u0026#34;, \u0026#34;fancy source field content\u0026#34;); IngestDocument ingestDocument = RandomDocumentPicks.randomIngestDocument(random(), document); KuromojiPartOfSpeechExtractProcessor processor = new KuromojiPartOfSpeechExtractProcessor(randomAsciiOfLength(10), \u0026#34;source_field\u0026#34;, \u0026#34;target_field\u0026#34;); processor.execute(ingestDocument); Map\u0026lt;String, Object\u0026gt; data = ingestDocument.getSourceAndMetadata(); assertThat(data, hasKey(\u0026#34;target_field\u0026#34;)); assertThat(data.get(\u0026#34;target_field\u0026#34;), is(\u0026#34;fancy source field content\u0026#34;)); // TODO add fancy assertions here } テストメソッドも実装されていますが、パラメータの追加の設定処理やアサーションが書かれてません。 実装に合わせて、アサーションや設定処理を追加しましょう。\nKuromojiPartOfSpeechExtractRestIT こちらはIntegration Testになります。 実際にElasticsearchに対して外部からAPIを叩くような感じです。 APIを叩くときに利用するJSONの設定やアサーションはsrc/test/resourcesにyamlファイルがあります。\n10_basic.yaml 20_kuromoji_part_of_speech_extract_processor.yaml 10_basic.yamlはプラグインがインストールされているかの確認のテストです。特に変更する必要はないです。\n20_kuromoji_part_of_speech_extract_processor.yamlは実際にコーディングしたProcessorが動くかどうかのテストです。\nテストの内容については、GitHubのコードをご覧ください。\nテストの実行とZipの生成 テストの実行とZipの生成は次のコマンドを実行すればOKです。\ngradle check テストに問題があった場合は、コケますし、問題なければSUCCESSと表示が出ます。 成功した場合はbuild/distributions/というディレクトリにzipファイルができています。 これをElasticsearchのpluginコマンドでインストールすれば動きます。\nbin/plugin install file:///path/to/elasticsearch-ingest-kuromoji-pos-extract/build/distribution/ingest-kuromoji_part_of_speech_extract-0.0.1-SNAPSHOT.zip kuromoji_pos_extractの利用方法 Ingest APIには便利なSimulate Pipeline APIがあります。\nということで、mecab-ipadic-NEologdにあったサンプルの文章を使って、使い方の説明です。\nPOST _ingest/pipeline/_simulate { \u0026#34;pipeline\u0026#34; : { \u0026#34;description\u0026#34; : \u0026#34;kuromoji neologd extract test\u0026#34;, \u0026#34;processors\u0026#34; : [ { \u0026#34;kuromoji_pos_extract\u0026#34; : { \u0026#34;field\u0026#34; : \u0026#34;body\u0026#34;, \u0026#34;target_field\u0026#34; : \u0026#34;noun_field\u0026#34;, \u0026#34;pos_tags\u0026#34; : [ \u0026#34;名詞-固有名詞-組織\u0026#34;, \u0026#34;名詞-固有名詞-一般\u0026#34;, \u0026#34;名詞-固有名詞-人名-一般\u0026#34;, \u0026#34;名詞-固有名詞-地域-一般\u0026#34;, \u0026#34;名詞-固有名詞-地域-国\u0026#34; ] } } ] }, \u0026#34;docs\u0026#34; : [ { \u0026#34;_index\u0026#34;: \u0026#34;index\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;type\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;id\u0026#34;, \u0026#34;_source\u0026#34;: { \u0026#34;body\u0026#34; : \u0026#34;10日放送の「中居正広のミになる図書館」（テレビ朝日系）で、SMAPの中居正広が、篠原信一の過去の勘違いを明かす一幕があった。\u0026#34; } } ] } 結果はこちら。\n{ \u0026#34;docs\u0026#34;: [ { \u0026#34;doc\u0026#34;: { \u0026#34;_index\u0026#34;: \u0026#34;index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;id\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;type\u0026#34;, \u0026#34;_source\u0026#34;: { \u0026#34;noun_field\u0026#34;: [ \u0026#34;10日\u0026#34;, \u0026#34;中居正広のミになる図書館\u0026#34;, \u0026#34;テレビ朝日\u0026#34;, \u0026#34;SMAP\u0026#34;, \u0026#34;中居正広\u0026#34;, \u0026#34;篠原信一\u0026#34; ], \u0026#34;body\u0026#34;: \u0026#34;10日放送の「中居正広のミになる図書館」（テレビ朝日系）で、SMAPの中居正広が、篠原信一の過去の勘違いを明かす一幕があった。\u0026#34; }, \u0026#34;_ingest\u0026#34;: { \u0026#34;timestamp\u0026#34;: \u0026#34;2016-07-22T06:18:49.007+0000\u0026#34; } } } ] } noun_fieldに固有名詞の単語が抜き出せているのがわかるかと思います。\nAlexのテンプレートで困った点 テンプレートは便利だったのですが、processor_typeに_を使用したタイプ名を指定すると次のような問題（？）が発生しました。\nクラス名がKuromoji_part_of_speech_extractProcessorとなってしまう 深刻な問題ではないのですが、JavaだとCamel Caseが普通なのでちょっと気になって。 ということで、プルリク作って出してみました。まだ取り込まれてないかな。\n取り込み前に使いたい方は以下のコマンドを実行してください。 processor_class_nameという項目が増えています。 デフォルトだとprocessor_typeの_の部分を取り除きつつCamel Caseにしたものが入ります。\ncookiecutter gh:johtani/cookiecutter-elasticsearch-ingest-processor まとめ ということで、とりあえず作ってみましたというものになります。 特徴的な単語（固有名詞だけ）を抜き出して、別のフィールドにできるので、タグみたいなものをこれを使って前処理で作れるようになるかなぁと。\n参考ブログ（元ネタ？） インスパイア元となったブログです。\nUser Agentを解析するIngest Pluginを書いてみた Elasticsearch 5.0.0のIngest Node用プラグインを書いた話 ","date":1469161616,"dir":"post/2016/","id":"a62186ea292d6db03a087bd5dfcc3f1e","lang":"ja","lastmod":1469161616,"permalink":"https://blog.johtani.info/blog/2016/07/22/making-ingest-processor-plugin-with-cookiecutter/","publishdate":"2016-07-22T13:26:56+09:00","summary":"久しぶりに、技術的なブログ書いてます。 Ingest Processorのプラグインを作ってみたくなったので、書いてみました。 ただ書いてみるんじゃ3番煎じ","tags":["elasticsearch","plugin"],"title":"Lucene Kuromoji for NEologdで指定した品詞の単語を抜き出すIngest Pluginを書いてみた #elasticsearchjp"},{"contents":"なんか、今年はよく物が壊れる、厄年だからかなぁ？\nということで、記念に何が壊れたかをブログに残しておこうかと。\n腕時計（壊れてないかな） 電波腕時計を使ってたんだけど、電池がへたってたのでオーバーホールしてもらった。 Moto 360（壊れたというか。。。） 何度かバージョンアップしてるんだけど、数ヶ月前から、ちょっと触っただけで電源が落ちる現象が。ファームウェアのせいかAndroid Wearのバージョンアップのせいかわからないけど。。。挙げ句の果てに、電源を入れるために充電器にセットしないといけないと言う酷い仕様。。。 自転車前輪 自転車で車道を横切る側溝の蓋の間に前輪がはまってすっ転んでしまい、タイヤのスポークがちょっと曲がってしまう ジーンズその1 自転車で転んだ時に、膝とかこすって破れる ジーンズその2 福岡出張中に雨で滑って派手に転んで、膝に大きな穴が。。。 リュック あー、怪しいなと思ってたんだけど、やっぱりこわれた、、、 pic.twitter.com/CD2Y7t6AOD\n\u0026mdash; Jun Ohtani (@johtani) 2016年6月16日 怪しいとは思ってたんだけど。。。 ということで、リュックを新調しつつ修理に出してるところ。 5. Xperia Z3 * 先週金曜日にカメラのレンズが結露してるなぁと思ったら、電源が入らなくなった。補償サービスに入ってたんで、新しいZ3を次の日に送付してもらい復旧。いろいろなアプリがログインしないといけないのでかなり大変だった。。。\nまだ、半年残ってるので他にも壊れるのかなぁ。。。 お祓いしてもらったので、何もなければいいんだけど。\nということで、なんとなく欲しいものリストを貼っておきますね。\n","date":1467251858,"dir":"post/2016/","id":"167e2a6833d49ce198cb3b88f521991e","lang":"ja","lastmod":1467251858,"permalink":"https://blog.johtani.info/blog/2016/06/30/broken-something-in-this-year/","publishdate":"2016-06-30T10:57:38+09:00","summary":"なんか、今年はよく物が壊れる、厄年だからかなぁ？ ということで、記念に何が壊れたかをブログに残しておこうかと。 腕時計（壊れてないかな） 電波腕時","tags":["misc"],"title":"よく物が壊れる年"},{"contents":"第16回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 今回は、司会だけに注力してみました（）。\nチェックイン数など チェックインした人：141名 キャンセルしなかった人：67名 でした。\n今回は、参加希望者が多くて、当日にも100名近いキャンセル待ちの方がいたので、 240名まで、参加者枠を増枠（会場キャパ190名程度）して対応しました。 まぁ、読み通り、1/3の方はキャンセルしない形でした。 天気も良く電車の遅延などもなさそうだったので、ちょっとドキドキしてたのですが。\n以下は簡単なメモです。\n「LogstashとElasticsearchで作るEnterprise Search Platform」/ Elastic Kosho Owa スライド：https://speakerdeck.com/kosho/enabling-enterprise-search-platform-with-elastic-stack\n使ってるLogstashの設定ファイルを elastic-japan at elastic dot co に送るとTシャツがもらえるらしい。 Logstashのfilter-rubyはここで、evalしてcallしてるから、特にforkとかしてないかと。 「企業・業界情報プラットフォームSPEEDAにおけるElasticsearchの活用」 / 株式会社ユーザベース 北内 啓さん スライド：http://www.slideshare.net/tau3000/speedaelasticsearch-63510388\nアルゴリズム関連の開発担当 企業データをいろんな軸で検索したい データ数が約70億レコードになりそう（通貨 x MySQL） 300万企業データ＋Nestedとかで持ってる。 11万フィールド？？？ 10台の物理サーバに24仮想マシン 企業名の検索 recall重視 NewsPicksの検索機能 「日本 化粧品 売上高」業界のデータとかも観れるのかな？有料会員向け機能 登録済みキーワードかどうかをRDB＋Esに検索して、ID化するっぽい ID（Analyze必要ない）検索だから、termクエリだった、サンプルが。 ノードの役割分担 更新はMasterNode経由でDataNodeへ。 検索はClientNode経由でDataNodeへ。 1.xかぁ。。。 「Elasticsearchベースの全文検索システムFess」 / 株式会社エヌツーエスエム 菅谷信介さん スライド：http://www.slideshare.net/shinsuke/elasticsearchfess\n10.xからSolrをやめてElasticsearchへ。 日本語検索 bigram＋形態素（1文字検索とかに対応するため） NeologDに対応したkuromojiを利用 DBFluteをESFluteとしてEs対応 KOPFを組み込んで使ってる configをREST API経由で更新できるプラグインあり LT 「ElasticsearchとGCPのネットワークでハマった話」 株式会社サイバーエージェント 平田大地 さん @daichild スライド：https://speakerdeck.com/daic_h/gcpfalsenetutowakudehamatutahua\nhhkb2 2刀流！ networkのKeep-alive周りで困ったよというお話。 後で聞いたけど、GCE Cloud Pluginは使ってるそうです。 06/28 17:00追記\nPingを定期的に実行させることで回避も出来るようです。 transport.ping_scheduleに時間を指定します。通常のNode（Transport以外）は\u0026rsquo;-1\u0026rsquo;が指定してあり、動作してません。 「スクリプトフィールドで作るランキングみたいな何か」iwag さん スライド：https://speakerdeck.com/iwag/elasticsearch-dezuo-rurankingu\n1.xかぁ。。。 あとは、function_scoreとかも面白いですよ！ その他、感想などのブログ 第16回elasticsearch勉強会に参加してきた 第16回Elasticsearch勉強会に参加してきた まとめ＋宣伝？ 1.xがまだまだいますねぇ、早く2.xにアップしましょう！（5.0ももう直ぐだし）。懇親会でも色々と話しましたが、https://discuss.elastic.co というフォーラムあるので、ぜひ活用してください。\n次回は8月末か9月頭かでしょうか。 7月末にOSC京都に出没するので、京都で勉強会やりたいと思ってます！ 会場とかスピーカーとか興味ある人連絡ください。\n東京の勉強会のスピーカーも随時募集中ですので、連絡ください。\n","date":1467089755,"dir":"post/2016/","id":"993e58f132740b464ecf06ee289dc7b2","lang":"ja","lastmod":1467089755,"permalink":"https://blog.johtani.info/blog/2016/06/28/16th-elasticsearch-meetup/","publishdate":"2016-06-28T13:55:55+09:00","summary":"第16回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第16回Elasticsearch勉強会を開催しました。 #elasticsearchjp"},{"contents":"第15回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 今回は、Elastic{on} 2016開催直後ということで、大半はElastic{on}に関する話でした。\nチェックイン数など チェックインした人：114名 キャンセルしなかった人：62名 でした。 今回は、少しおそめで1時間前にキャンセル待ちがいない状態にしました。 まぁ、いつもの感じでしょうか。数値も安定してきた感じですかね。\n\u0026ldquo;Elasticsearchと機械学習を実際に連携させる\u0026rdquo; / Preferred Networks America, Inc. CTO 久保田展行(Kubota Nobuyuki) さん スライド：Elasticsearchと機械学習を実際に連携させる\n前回の続きの話で、今回が本題でした。\n勉強会直前に発表されたSensorBeeをElasticsearchと一緒に使うとどんなことができるかというお話です。 まぁ、前処理重要ですよねというのが、いつものことですが、印象的でした。 いつものようにわかりやすい説明だったので、使ってブログを書いて欲しいなと。\n発表の中で、説明に出てきたデモとか。\nCES2016でロボットカーのデモを展示してきました \u0026ldquo;Elastic{ON} 2016レポート\u0026rdquo; / Elastic Jun Ohtani スライド：elastic{on} 2016 レポート\n写真多めで、キーノートをメインに話をしました。\n簡単なまとめとしては\nプロダクトロゴができました。ロゴ画像などはこちら 次のメインバージョンは全て5.0。（5.0に関する通知が欲しい人はこちらで登録できます） elastic{on} 2016のビデオなどはこちら BBL始めます。連絡ください \u0026ldquo;Elastic{ON}の過ごし方\u0026rdquo; / クラスメソッド株式会社 藤本 真司 さん スライド：Elastic{ON}の過ごし方\n印象に残ったのは\n「自他共に認めるブログの会社」 4/12にSAPさんに会場を借りてElastic＆クラスメソッドでイベントやります。 やっぱりご飯が美味しいんですねぇ。 早速ブログが書かれてました。\n\u0026ldquo;Elastic{ON} 2016 見るべきセッション資料 7選\u0026rdquo; / Acroquest Technology株式会社 谷本 心 さん スライド：Elastic{ON} 2016 見るべきセッション資料 7選 #elasticsearchjp\n印象に残ったのは\n東京でハンズオンやる会場提供者募集中！ Ingest Node（参考：Ingest Nodeのドキュメントは公開中。） Reindex API（参考：Backport reindex to 2.x ） その他、感想などのブログ 第15回elasticsearch勉強会にLTで登壇しました #elasticsearch #elasticsearchjp 第15回elasticsearch勉強会に参加してきました #elasticsearch #elasticsearchjp まとめ＋宣伝 来年のElastic{ON}に参加したいと思っていただけたらよかったなと。\n4/12にクラスメソッドさんとイベントを行います。また、ツイートすると思います。\n次回はいつも通りだと5月中旬になるかと思います（大丈夫かな？OSC 2016 Nagoyaでしゃべったり、ブース出したりとかするけど）。 5末に名古屋に出没します。名古屋で勉強会できればやりたいと思ってます。会場とかスピーカーとか興味がある方は連絡ください。\n","date":1458186180,"dir":"post/2016/","id":"c56a76ef8f604a8d87be2a32b1f81fac","lang":"ja","lastmod":1458186180,"permalink":"https://blog.johtani.info/blog/2016/03/17/15th-elasticsearch-jp/","publishdate":"2016-03-17T12:43:00+09:00","summary":"第15回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第15回Elasticsearch勉強会を開催しました。 #elasticsearchjp"},{"contents":"久々のポスト。。。\n久々に、技術書読んでます。「自然言語処理の基本と技術」という本です。\n監修の方のツイートを見て気になったので、買ってみました。 書籍のサイトの説明はこんな感じでした。\n本書は、この未来に不可欠となるに違いない自然言語処理の、技術的、ビジネス的基礎知識をくまなくコンパクトに図解した一冊です。 著者陣もそれぞれの分野の第一線で活躍するエキスパート揃い！\n確かに著者陣がすごいです。\nまだ、「はじめに」と自分に関係のある「情報検索」の章を流し読みしただけなんですが、次のような特徴がある本です。\n平易な単語で説明してある（難しい専門用語が少ない） 数式が出てこない（多分。少なくとも読んだ部分では見てない） 説明には例と図解がある 情報検索の章で言うと、全文検索でよく使われる転置インデックス（索引という単語が使われてる）がなぜ必要なのか、どういう感じで作られるのか、 転置インデックスに利用する索引の単語をどうやって作るのか（文字N-Gramや形態素解析）、単語の正規化（ステミングやストップワード）などの説明が 本当にわかりやすく書かれています。 スコアリングについても触れられています。\nElasticsearchも転置インデックスを用いた検索を行っており、 MappingでAnalyzerの指定をしている理由などの理解に役に立つと思います。\n全文検索システムがどのように検索を処理しているかをざっくり理解するのにはもってこいじゃないかと。 1点残念だなと思ったのは、書籍に「索引」がありませんでした（本の索引を思い浮かべてくださいっていう説明あったんだけど）。。。 Kindle版を購入すれば「検索」できるのかな？\nということで、まだ、流し読みしただけなんですが、「すごく」オススメです。 購入はこちらから！\n","date":1457962452,"dir":"post/2016/","id":"3fc7462a83fa55885067fee629287e8a","lang":"ja","lastmod":1457962452,"permalink":"https://blog.johtani.info/blog/2016/03/14/review-basics-and-tech-of-nlp/","publishdate":"2016-03-14T22:34:12+09:00","summary":"久々のポスト。。。 久々に、技術書読んでます。「自然言語処理の基本と技術」という本です。 監修の方のツイートを見て気になったので、買ってみました","tags":["本"],"title":"「自然言語処理の基本と技術」を読んでる"},{"contents":"あけましておめでとうございます、johtaniです。\n第14回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 今年もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\nチェックイン数など チェックインした人：122名 キャンセルしなかった人：58名 でした。 今回も当日の昼の時点でキャンセル待ちがない状態にしていました。 いくつか電車が止まっていたという話を聞いていたので、開始を5分遅らせ、 受付は45分くらいまで開けておくという対応をしてもらいました。\n\u0026ldquo;ココが辛いよelasticsearch\u0026rdquo; / 株式会社リクルートテクノロジー @tatakaba さん スライド：ココが辛いよelasticsearch\n実際にいくつかのサービスで運用されている内容とどういった機能を利用しているか、 どういったものを独自に作っているかという話をしていただきました。\n独自PluginでA/Bテストしてる Snapshotの活用 Index作成は環境に合わせて行っている。 バージョンは混在 PusnaRSのバージョンアップの話。 2つのバージョンのクラスタを用意してリアルタイムに切り替え。 Elasticsearchの活用 QueryのRewrite： SolrのリクエストをEsで受け付けたり。 辛い話。 バージョンアップが辛い Riverなくなるのつらい データずれるのつらい 補足：\nバージョンアップについて 1.x系から2.x系にアップされるのであれば、こちらを必ず試してください。\nhttps://github.com/elastic/elasticsearch-migration\n「.」が使えなくなるという話は、Solrとの大きな違いになるのかもなぁと。 ネスト構造のデータの表記を「.」で行うというのを厳密に行えるように、 「.」を使えなくしたというのがあるかと。\nRiverについて Riverがなくなった理由については、https://www.elastic.co/blog/deprecating-rivers で記載があります。 便利なのですが、負荷が偏ったり、スケールしないとかいう問題点があるかなと。\n良いサンプルとしては、JDBC Riverなどは、Javaのプログラムとして起動できるように変更されていたりします。\nhttps://github.com/jprante/elasticsearch-jdbc/wiki/jdbc-plugin-feeder-mode-as-an-alternative-to-the-deprecated-elasticsearch-river-api\n（個人的 には、SolrのDIHもRiverもあんまり好きではなかったです。データの変換処理と、ロード処理は別々にしたい人だったので。）\nデータのズレなど 耐障害性とか信頼性に関しては、どういった問題点があるのか、どういった対応をしているのかというのがまとめられたページが用意されています。\nhttps://www.elastic.co/guide/en/elasticsearch/resiliency/current/index.html\n「機械学習を利用したちょっとリッチな検索」 / Preferred Networks America, Inc. CTO 久保田展行(Kubota Nobuyuki) さん スライド：機械学習を利用したちょっとリッチな検索\n来日していただき、機械学習と検索の話をしてもらいました。 本編は次回の発表かもw\n機械学習を元に、検索対象の情報を元の情報から増やしてあげる。 増えた情報を検索できるようにする 今日のゴール： 機械学習とはどういうものか？ データの集め方とか、アノテーションとか 学習の方法（ツールやライブラリに依存） Esでの活用方法 オフラインで学習させて、情報を付与した後に、Elasticsearchに入れる Jubatus＋fluentdで ChainerサポートのOSSのツールを公開予定 「ここからが本当の地獄だ。。。」ってのが聴きたいw\n「Lucene Query 再考 - Domain Specific Query 実装 -」 / Supership株式会社 インフラ事業開発本部検索グループ 大川真吾 さん スライド：Lucene Query 再考 - Domain Specific Query 実装 -\nLuceneのクエリに関する話と、クエリパーサーに関する話でした。 こういった濃い話も勉強会でしてもらえると、色々な参加者に楽しんでいただけるかなぁと。 次回も続きを話してもらう予定です。\n補足：\n参考までにですが、Elasticsearchに入門したての人向けに、 Analyzerとか転置インデックスとかの話をした時のスライドになります。 https://speakerdeck.com/johtani/lucenetori-ben-yu-falsejian-suo\nLT: Fluentd meets Beats / @repeatedly さん スライド：http://www.slideshare.net/repeatedly/fluentpluginbeats-at-elasticsearch-meetup-14\n参考Qiita：http://qiita.com/repeatedly/items/77af41788f0b3ccdefd2\nBeatsの説明をTDの人からしてもらうなどw FluentdにBeatsからのデータを流し込めるようにしたプラグインが出たという話でした。\nfilebeatの性能の件は社内で聞いてみようかと。\nElasticsearchインデクシングのパフォーマンスを測ってみた / 日本IBM　黒澤亮二さん スライド：Elasticsearchインデクシングのパフォーマンスを測ってみた\n参考Qiita：http://qiita.com/rjkuro/items/e79eec7ffb0511b7c678\n細かな性能測定の結果を駆け足で話してもらいました。 皆さんもこの指標をもとに、手元の環境を計測してみたりしてみてもらえればと。\nあとは、2.x系になってるので、同じ方法で計測してもらってまた 発表してもらえると嬉しいなー（棒）\nその他、感想などのブログ Elasticsearch勉強会　第14回フィードバック まとめ＋宣伝 久々に（初めてかな？）、ゲストがいないのに自分が喋りませんでした。 次回は3月中旬を予定してます。 次回は、Elastic{ON}16の報告をする予定です。いろいろと発表あるだろうし。\nあと、今月末の1/29にオープンソースカンファレンス 2016.enterprise@Osakaにブース出展します。 セミナー枠でも弊社OSSプロダクトの概要を話しする予定です。 関西の方は、ぜひ参加していただければと。ブースでお待ちしております。\nまた、スピーカーや場所が用意できたら、出張勉強会もまたやりたいなと思っています。 興味ある方は、連絡ください！\n","date":1452220496,"dir":"post/2016/","id":"4b0a768585da8f9f8f8db1ca409e7ebd","lang":"ja","lastmod":1452220496,"permalink":"https://blog.johtani.info/blog/2016/01/08/14th-elasticcsearch-jp/","publishdate":"2016-01-08T11:34:56+09:00","summary":"あけましておめでとうございます、johtaniです。 第14回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆","tags":["elasticsearch","勉強会"],"title":"第14回Elasticsearch勉強会を開催しました。 #elasticsearchjp"},{"contents":"今年は紅白見ながら書いてます。 早い一年だったなぁ。\n振り返り(2014年に書いた抱負から) まずは去年の抱負を元に振り返りをば。\n英語の継続 海外のイベントへの参加 多岐にわたるイベントでのスピーカー 日本の人員の倍増！？ Elasticsearchに関する日本語の情報発信 Elasticsearch座談会みたいなものの開催 英語はまぁ、継続してます。亀の歩みですが。。。\n海外のイベントへの参加は、自社のイベントだけでした。来年のElastic{ON}ももちろん参加です。来年こそBerlin Buzzwords行きたいな。。。\n多岐にわたるイベントとまではいってないですかね。。。来年はOSC(大阪や東京)に出没予定です。参加される方は、声をかけていただければと。\n人員は倍増しました！営業の方が参画されたのがかなり助かってます。 今現在で4名です！来年も倍増できるかなぁ？\n日本語の情報発信はリリースブログの翻訳が多めでした。来年は独自コンテンツも増やさないとなぁ。 あとやっぱ書籍かなぁ。。。座談会は来年の課題に。。。\n振り返り(今年あったできごと) その他の今年の出来事。\n初渡米 初バルセロナ 東京以外で勉強会 初自社イベント（日本で） 初トレーナー 不惑 今年も初モノ多いですね。今年も楽しい一年でした。 自社イベントでアメリカやバルセロナなどに行きました。40年近く、海外に行ったことないせいか、海外に行って経験することが面白いです。\n東京以外での勉強会もやりました。名古屋、大阪、京都、北海道と。 来年もOSCで訪れた場所で勉強会を開催したいなぁと。\n自社のイベント（Elastic{ON} Tour Tokyo）も東京でやりました。 どうなることかと思っていましたが、朝から大勢の方に来ていただけてホッとしました。 自分のトークがどうだったのかという反応も気になりますが。。。 せっかくShayたちが来ていたので、もっとブースに話しに来てもらえるともっと嬉しかったかもなぁと。\nTour Tokyoを挟んで自社の公式トレーニングのトレーナーもやりました。 日本で3回目にして、初の日本語でのトレーニングでした。前の2回は逐次通訳だったんですが。 トレーニングって大変だなぁと思ったのと、やはり日本語でトレーニングを受けられるとだいぶ違うだろうなという実感がありました。 来年もできればいいなと。トレーニング自体があったことを知らない人もいたのかなぁ？\n来年の抱負 英語の継続 もっとElasticsearchの開発に参加 人員の倍増？ 日本語情報発信 Splatoon S+? 英語あいかわらず出来てないので、頑張らないと。 もっと喋ったりしないとなんだろうなぁ。\n来年は開発をもっとやりたいなと。 来年1月にはセールスのエンジニアが加入するので、開発にもっと時間を割きたいなと。\n人員は倍増できるように頑張りたいです。少なくとも、2人が1月に入ることは決まってるんで、後二人！\nブログももっと書かないとですね。新機能とかこんな使い方できるよとか。 どんな記事が欲しいかとかコメントもらえると楽なので、突っ込みくださいw\n最後は、完全に私用ですね。Splatoonにはまってますw SとA+を行ったり来たりで。。。\nということで、今年はあと、数時間ですが、色々とお世話になりました。 この場を借りてお礼申し上げます。\n来年も、いろんな方に絡んでいくとは思いますが、よろしくお願いいたします。\n","date":1451565182,"dir":"post/2015/","id":"c54909ecf4fb3e9afeea36200fe95dce","lang":"ja","lastmod":1451565182,"permalink":"https://blog.johtani.info/blog/2015/12/31/looking-back-2015/","publishdate":"2015-12-31T21:33:02+09:00","summary":"今年は紅白見ながら書いてます。 早い一年だったなぁ。 振り返り(2014年に書いた抱負から) まずは去年の抱負を元に振り返りをば。 英語の継続 海外の","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2015）"},{"contents":"今年最後のAdvent Calendarとなります。\nこの記事はElasticsearch Advent Calendar 2015の最終日のエントリです。\n簡単に今年の変遷を、Elasticsearchをベースに振り返ってみようかと思います。\nKibana 4リリース（2月） Kibana 4（日本語訳） いきなり、Elasticsearchではない話題ですが。 AggregationベースのKibanaがリリースされました。 画面が黒くないというので、話題になりましたw 12月末時点では、4.3.1になっています。 Sub Aggregationによる強力なグラフ表示や異なるインデックスに対するグラフを 一つのダッシュボードに表示できるといったことができるようになりました。\nセキュリティ向けプラグインShieldのリリース（2月） セキュリティ向けプラグインShieldのリリース（日本語訳） 商用向けのプラグインの第2弾です。 セキュリティ強化のためのプラグインで、いろいろなところで引き合いがあったりします。\n初のユーザカンファレンス、Elastic{ON}開催（3月） #elasticon に参加中 サンフランシスコで、弊社初のカンファレンスが開催されました。（来年（2016年）もサンフランシスコで開催されます。） また、ここで、以下の2点の発表がありました。\nロゴ及びドメイン名などの変更 Foundのジョイン 約1300名が参加する大イベントでした。 初の渡米で楽しんできましたが、ドメインの切り替えなどは大変でした。。。 まだ、ロゴを変えて1年経ってないということが実感できてないです。\nFoundのジョインはまだまだ、日本で知名度が出てないかもなぁと。 もっと広めないと。 利点としては以下の通りです。\n新バージョンがすぐに利用可能に。また、バージョンアップも画面で指定可能 公式プラグイン＋その他いくつかのプラグインが利用可能 Elasticsearch 1.5 リリース（4月） Elasticsearch 1.5.0リリース（日本語訳） 主に、resiliencyに関する改良になります。 毎リリースで信頼性向上につながる改良が含まれる形になっています。 このリリースの近くで初の東京の外での勉強会を名古屋で開催したりもしました。\ndiscuss.elastic.coをオープン（5月） https://discuss.elastic.co これまでは、Google Groupsを使っていましたが、Elasticが提供しているプロダクトが 別々のグループであったために、プロダクトにまたがった質問がやりにくかったり、検索がしにくかったりという問題点がありました。 今では、過去のGoogle Groupsのデータも移行されているので、是非参加して、質問・回答してみてください。 日本語でやりとりできるカテゴリもあるので、どんどん、やりとりしていただければ。\nElasticsearch 1.6 リリース（6月） Elasticsearch 1.6.0リリース（日本語訳） 2.0に向けたUpgrade APIが含まれるなど、次期リリースに向けた準備が整いつつあるリリースでした。 他にもsynced flushの取り込みやレスポンスのJSONのフィルタリングなど細かな改善も取り込まれています。\nFound PremiumとStandardリリース（7月） さらに進化したFound（日本語訳） Foundに弊社のサポートチームがサポートできるプレミアムが追加されました。 これにより、商用プラグインとして提供しているShieldが（現在はWatcherも）利用できるなど、 より便利になりました。また、Kibana 4も無料で提供されていたりします。\n小さなサイズのものですと、無料で試していただけるものもあるので、試してみてもらえればと。\nElasticsearch 1.7 リリース（7月） Elasticsearch 1.7.0 および 1.6.1リリース（日本語訳） 1.x系、最後のリリースでした。 小さい改善ですが、セキュリティフィックス、クラスタの安定化に寄与する機能改善が含まれています。\nこのリリース直前に大阪、京都で勉強会も開催してみました。\nElasticsearch 2.0.0-beta1 リリース（8月） Elasticsearch 2.0.0-beta1リリース（日本語訳） 待ちに待った、Lucene 5ベースのElasticsearchの登場でした。 doc_valuesがデフォルトになったり、エラーが構造化されて見やすくなったり、 Pipeline Aggregationが導入されたりしています。 また、問題点の洗い出しも兼ねて、ベータリリースとして、本リリースまでに多くのIssueをあげていただきました。\nElasticsearch 2.0.0 リリース（10月） 2.0の本リリースです。リリースまでに、beta1、2及び、rc1がリリースされました。\n追加された機能や目玉の改善については「Elasticsearch 2.0の紹介」のスライドを参考にしていただければと。\nまた、Elasticsearch 2.0のリリースに合わせて、商用プラグインやLogstash、Kibanaの新しいバージョンがリリースされました。 Kibanaなどは、プラットフォームとしての機能を備え、SenseやTimelionと言ったプラグインアプリもリリースされています。\nLogstash 2.0.0リリース（日本語訳） Kibana 4.2.0リリース（日本語訳） Senseの歴史 - Sense 2.0.0-beta1の紹介(日本語訳) Shield、Watcher、Marvel 2.0.0 GAリリース（日本語訳） Elasticsearch 2.1.0 リリース（11月） Elasticsearch 2.1.0 and 2.0.1 released Beats 1.0.0のリリース（11月） The Beats 1.0.0 Go言語で書かれた軽量データシッパーになります。 パケットをキャプチャしてElasticsearchに送るPacketbeat、 topコマンドで取れるデータなどをTopbeat、 ログファイルなどを取り込み配送するFilebeatがリリースされました。\nlibbeatと呼ばれる、 ベースとなるライブラリを元にしたプロダクトで、Logstashのエージェントのような使い方もできるようになっています。\nGo言語に興味のある方などは、調べてみてはいかがでしょう？\n来年は？ 日本では、1/7に第14回Elasticsearch勉強会を開催します。 すでに、38名のキャンセル待ちとなっていますが、おそらく、年明けにキャンセルがそこそこ出ると思うので、まだ間に合うんじゃないかなぁと。\n会社としては、Elastic{ON}16が控えています。参加される方は、ぜひ現地で声をかけてください！！\nその他にもイベント、オープンソースカンファレンス（まずは、大阪、東京）などに出没する予定ですので、こちらも参加していただければと。\nでは、また来年のAdvent Calendarでお会いしましょう！\n","date":1451017794,"dir":"post/2015/","id":"d819cea5197e9b8673d6c0b16659a5ea","lang":"ja","lastmod":1451017794,"permalink":"https://blog.johtani.info/blog/2015/12/25/about-elasticsearch-in-2015/","publishdate":"2015-12-25T13:29:54+09:00","summary":"今年最後のAdvent Calendarとなります。 この記事はElasticsearch Advent Calendar 2015の最終日のエントリです。 簡単に今年の変遷を","tags":["elasticsearch"],"title":"2015年のElasticsearch"},{"contents":"こんにちは、@johtaniです。\n早いもので、師走です。今年もあと少しとなりました（今月が一番忙しかったりしますが。。。）。 ということで、Advent Calendarの季節が始まりました。\nこの記事はElasticsearch Advent Calendar 2015の1日目のエントリです。\n今日は、最近公開されたTimelionの紹介をしたいと思います。\nTimelion? 11/12に公開されたばかりのアプリになります。（公式のブログはこちら。ブログでは動画による説明もあり）\nKibanaにプラグインとしてインストールすることで使用することができるようになるアプリです。 Timelionと書いて「Timeline」と読むようです。 Kibanaとは異なるグラフ描画のプラグインになっています。\nKibana 4.2からプラットフォーム化 Kibana 4.2から、Kibanaにプラグイン機構が導入されました。 Kibanaとしての機能以外にも、プラグインとして、アプリを追加できるようになっています。 Timelionもその一つです。\nインストール Timelionを試してみるには、ElasticsearchとKibanaが必要になります。（こちらは、すでにインストールされているとして。。。）\nKibanaのコマンドを利用して、プラグインをインストールします。\nbin/kibana plugin -i kibana/timelion インストールしたら、Kibanaにアクセスして、Timelionを呼び出します。\nTimelionへアクセス ブラウザでlocalhost:5601にアクセスすると、Kibanaが出てきます。 Kibanaのプラグイン選択のアイコンをクリックし、Timelionのアイコンをクリックします。\nすると、初期画面はこんな感じです。 直近15分のElasticsearchに入っているデータがが全部出てきます。 チュートリアルも出てきてます（初回起動時に出たはず）\nKibanaでの検索窓の部分に関数を指定していくことで、グラフが描画できるツールになっています。\nサンプル：気温データを可視化 百聞は一見に如かずということで、 気象庁のデータを使って、 ちょっとしたグラフを書いてみました。 1年間の気温の推移と日照時間になります。\n上のグラフが那覇、下グラフが札幌の気温のグラフになります。\n赤いライン：最高気温 青いライン：最低気温 黄色い棒グラフ：日照時間 最低気温と日照時間はグラフは次のような式で描画しています。\n青いラインの最低気温 気温のグラフになります。\n.es(index=\u0026#39;tenki2\u0026#39;, q=\u0026#39;city:naha\u0026#39;, metric=\u0026#39;avg:temperature_min\u0026#39;).label(\u0026#39;min\u0026#39;), .es()がelasticsearchに対するデータ取得の関数です。 引数は次のような意味になります。\nindex：対象とするインデックス名 q：検索クエリ。ここでは、cityというフィールドにnahaで検索。 metric：描画対象となっているデータの入ったフィールド。temperature_minというフィールドの1日毎の平均値を取得 最低気温と最高気温は別々のフィールドに格納してあります。最高気温の場合は（temperature_max）を指定します。\n.label(min)で、グラフの凡例の指定です。 残念ながら、日本語の指定は現時点（2015年12月01日時点）ではうまくいかなかったです。（https://github.com/elastic/timelion/issues/17）\nデフォルトでは、線グラフが選択されているので、グラフの種類は特に指定はしていません。 明確に指定する場合はlines()を指定します。\n黄色い棒グラフの日照時間 .es(index=\u0026#39;tenki2\u0026#39;, q=\u0026#39;city:naha\u0026#39;, metric=\u0026#39;avg:sunlight\u0026#39;).label(sunlight).bars() .es()に関しては最低気温のグラフとほぼ一緒です。異なるのは、metricの取得対象のフィールド名です。\n.label()で凡例を指定しています。先程と同様です。\n最後に、棒グラフにしたいため、.bars()を指定しています。\nその他に用意されている関数について知りたい場合は、Timelionのヘルプを表示すると説明が出てきます。 cusum()のような値を累積して表示するような関数も用意されています。\nまとめ Kibanaとは少し違うアプローチで時系列データを描画するためのツールとなっています。 線グラフと棒グラフを一つのグラフに描画したりもできますし、 累積のグラフなんかも描画できるようになっています。\n実験的なプロジェクトである、Timelionの紹介でした。 ここでのノウハウがkibanaにフィードバックされると色々と面白いことになるんじゃないかなと。\nということで、 明日は、zoetroさんの「Kibanaのプラグインの話」になります。 お楽しみに！\n","date":1448936891,"dir":"post/2015/","id":"1b56132638912a1ca54fcf7cd38b8e23","lang":"ja","lastmod":1448936891,"permalink":"https://blog.johtani.info/blog/2015/12/01/introduction-timelion/","publishdate":"2015-12-01T11:28:11+09:00","summary":"こんにちは、@johtaniです。 早いもので、師走です。今年もあと少しとなりました（今月が一番忙しかったりしますが。。。）。 ということで、A","tags":["kibana","timelion"],"title":"Timelionの紹介 - Elasticsearch Advent Calendar 2015 1日目"},{"contents":"第13回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 来年もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n7月同様、サムライズムの@yusukeさんに テキスト翻訳していただき、大変助かりました。\nチェックイン数など チェックインした人：100名 キャンセルしなかった人：36名 でした。 今回は当日の時点でキャンセル待ちがない状態にしていました。 雨もあって、これなかった人もいるのでしょうか。\n\u0026ldquo;Beyond the basics with Elasticsearch\u0026rdquo; / Honza Král / Elastic スライド：https://speakerdeck.com/elasticsearch/beyond-the-basics-with-elasticsearch\n参考ビデオ（別のカンファレンスで話した時のビデオ）：https://www.youtube.com/watch?v=yIixWzjTNog\nPycon HKでアジアに来ていたHonzaに、ついでに日本で話をしてもらうという企画で、 前回から1カ月足らずでの開催となりました。 Elasticsearchの基本的な検索機能とは別の機能に関して少し話をしてもらった感じです。 PercolatorとAggregationの話でした。\n詳しくはビデオやスライドを見てもらうのがいいかなと。\n\u0026ldquo;How did we use Found.no for our services?\u0026rdquo; / 株式会社アイリッジ　Takuya Noguchi さん @tn961ir スライド：未定\nFoundユーザー。1.7までの話。 社内で独自にクラスタを構築していたが、managed serviceを利用したいと思っていた。 Found用のACLがShieldに マルチバイトのインデックス名とかも使いたいが、Nginxとの連携でちょっと。。。 セキュリティ関連の話も。Securityに関する報告はこういうものも用意されてるので、こちらに相談してもらうのがいいかも。https://www.elastic.co/community/security 要望がいくつか。 \u0026ldquo;ログ収集の仕組みを再考しよう！　あとマウンテンビューに行ってきました。\u0026rdquo; / Acroquest Technology株式会社 谷本 心さん @cero_t スライド：http://www.slideshare.net/shintanimoto/lets-reconsider-about-collecting-logs-plus-visiting-elasticmoutain-view\nログの小話から始まり、ログに関する考え方とかを披露してもらいました。 さらに踏み込んだログの活用の方法の話になるかと思いきや、 思いっきり話が飛んで、マウンテンビューのElasticオフィスに遊びに行った写真が出てきましたw\n写真の後は、弊社のTanya（来月のElastic{ON} Tour Tokyoで来日予定）から 聞いた弊社製品に関する話をしていただきました。 きっと、Beatsに関して次は話してくれるんだろうなぁ（棒）。 流れ的には、来年の2月にサンフランシスコで開催されるElastic{ON}16につながりそうだったので、ここで宣伝しときますね。 今年3月に開催されたイベントには残念ながら日本の方はいなかったので、次回は日本の方がいると嬉しいなぁと。\nLT \u0026ldquo;「Elasticsearch を使った単語共起頻度の計算」\u0026rdquo; / 株式会社はてな　id:takuya-a さん スライド：未定\n一風変わったElasticsearchの使い方的な話でした。 検索用にデータを登録してあるElasticsearchから単語の頻度情報を抜き出して、 別のインデックスに登録するという感じでしょうか。 こういうのが、実は、Elasticsearchに機能としてあると便利だったりするのかもなぁと思ってみたり。\nLTよりはちょっと長かったですかねw\nその他、感想などのブログ elasticsearch勉強会 まとめ＋宣伝 今回も@yusukeさんのテキスト翻訳に助けていただきました。ほんとありがとうございます。 今年の勉強会はこれがラストになります。 来月は、トレーニングとElastic{ON} Tour Tokyoがあるので忙しくなりそうですが、 参加予定の方は楽しみにしていてください！\nOperations : http://training.elastic.co/class/Operations/Japan/Dec Developer : http://training.elastic.co/class/Developer/Japan/Dec ","date":1447143778,"dir":"post/2015/","id":"2ea86ae5093670df1d4502ea82efa1ac","lang":"ja","lastmod":1447143778,"permalink":"https://blog.johtani.info/blog/2015/11/10/13th-elasticsearch-jp/","publishdate":"2015-11-10T17:22:58+09:00","summary":"第13回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第13回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：The Story of Sense - Announcing Sense 2.0.0-beta1\n誕生 よくある良いプロジェクト同様、Senseもビールを飲みながら考えつきました。 Amstelでの手漕ぎボートのセッションの後で。 友人のJasperと私はJasperの会社で毎年行われる ハッカソンについて話をしていました。 このハッカソンはどのようなアイデアでどんなチームで行うかを聞き取りされる、厳密なハッカソンです。 その時、私とJasperはChromeブラウザに別のヒストリーを表示するという作業をやるとAnne Velingに話をしていました。\nJasperと私はElasticsearchのユーザでしたが、リッチなREST APIにリクエストを送信するための 便利なツールがないと知っていました。 恥ずべきことに、cURLコマンドを利用するターミナルがその時の一番良いツールでした。 皆さん、ターミナルでボディつきのリクエストをサブミットするのがどのくらい不便かというのをわかるために、 5秒ほどターミナルで実行してみてください。 タイプミスのような単純なことでさえ、すべてのコマンドを再タイプしなければならなかったり、 複数行サポートのターミナルと戦ったりです。 ウェブベースのJSONエディタを見つけ出して、それをベースにすることが必要でした。\n終わりなきウィークエンド リサーチをして、Anneに電話しました。 私は彼に、History Pageのプロジェクトにもコミットするが、 Elasticsearchユーザなので、便利なコンソールを開発する時間も欲しいという話をしました。 私たちは、Aceオンラインエディタを利用して、 自動でAPIを認識するナレッジベースを構築し、 コンテキストに沿ったサジェストを大なうようにしました。 Anneはすぐに、それが素晴らしいと同意してくれました。 しかし、彼は、ハッカソンの基本的なルール（週末にそれが終わる必要がある）に違反しているので、 そのアイデアを却下するしかありませんでした。 確かに、私たちが提案していたものは行えませんでした。 最後に、私たちは、ChromeのHistory Pageの素晴らしい置き換えについて実装しました。\nそれでも、私はチャレンジし、それが終わるであろうことを終わるであろうことを証明しなければなりませんでした。 次の週末（といくつかの終業後 :)）に、私はそれを作りました。 Senseの誕生です。 それは、まだバグだらけでしたが、動きました。 これを見せるとみんな興奮しました。\n初期 Knowledge Baseの拡張とバグのフィックスで数日を過ごしました。 Senseは広まり始め、ずっと古いバグのあるバージョンを利用しないといけないのかと私は恐れました。 SenseをChromeのExtentionとしてリリースすることを決め、リリースすると自動的に更新されるようにしました。 History Panelのような機能を一つづつ追加するようにしました。\nElasticにジョインしてから、会社の人たちがSenseを使用しているということを聞き、とても幸せでした。 特に、Clintと話をしたときのことを覚えています。 彼は、\u0026ldquo;You know what Sense should do? It should use this format and allow you to have multiple requests in the editor\u0026rdquo; 「Senseになにをすべきかわかる？フォーマットを使うべきだし、エディタで複数のリクエストを持つようにするべきだ」 と言いました。 もちろん、その他のチャレンジも行いました。これは、簡単なものではなく、Aceの詳細を知る必要がありました。 それは新しいAceモード（Aceによって利用されているハイライティングロジック）です。 これは、Senseのサジェストエンジンに密に統合されました。\n次のものが古いSenseのスクリーンショットです。\n画像あり。Figure 1. Sense 0.7 ※画像に関しては原文をご覧ください。\nAPIのURLを入力すると、JSONのボディが入力されます。 うまく切り離すことができ、AceのスタンダードJSONモードを使っていました。 しかし、ここで、次のようなフォーマットをどうやってサポートするか考える必要がありました。\nGET _cluster/health POST index/_settings { \u0026#34;index\u0026#34;: { \u0026#34;number_of_replicas\u0026#34;: 3 } } これは、Aceが3つの異なるものをどうやってパースするかを知る必要があるということです。 HTTPメソッドとURLとJSONボディです。 また、困ったことに、前に説明した前に説明した通り、明らかに別々にはならないものでした。 JSONボディが完全であることを知る唯一の方法はかっこを数えることです。 それは、いくつかの作業とAceのカスタマイズが必要でしたが、それらを切り離すことができました。 そして、Senseのシンタックスが生まれたのです（Thanks Clint!）\nMarvel時代 就業時間中、私の優先すべき仕事はMarvelの開発になりました。 これは、Elasticsearchのための管理と監視のためのソリューションです。 （side note: Marvelは生まれ変わっています。（\u0026quot;Shield, Watcher, and Marvel 2.0.0 GA Released\u0026quot;）） Marvelは開発環境ではフリーなので、MarvelにSenseを組み込むことにしました。 これにより、Senseの開発が日中も行えるようになり、多くのユーザに利用され始めました。 また、Senseは実際に真のJavaScript開発者によって開発されました。 彼は、コードをクリーンにし、ブラウザにおける最新の技術を私に教えてくれました。\nこの期間のSenseは数回書き換えられています。 最も顕著なものは、個別のURLとJSONのサジェストエンジンを書き換えて、 1つのサジェストエンジンにしこれらのコンテキストで動作するようにし、さらに3つ目のコンテキスト（URLパラメータ）を追加したことです。\n新しいエンジンはまた、複数のサジェストコンテキストをメンテナンスするのが簡単になりました。 例えば、_search APIのソートパラメータを考えます。\nGET _search { \u0026#34;sort\u0026#34;: [ \u0026#34;timestamp\u0026#34;: \u0026#34;desc\u0026#34;, \u0026#34;price\u0026#34;: { \u0026#34;order\u0026#34;: \u0026#34;desc\u0026#34;. \u0026#34;missing\u0026#34;: \u0026#34;last\u0026#34; }, \u0026#34;nested_filter\u0026#34;: { \u0026#34;term\u0026#34;: { ... }}, \u0026#34;_score\u0026#34; ] } ユーザがどこにいるかによって、Senseは単純な値（_scoreのような）か、 複雑な構造（orderとmissingのような）やフィルタ（nested_filterのような）も サジェストする必要があります。 これらのサジェストのパスが一度に処理され、無関係なものは除外されます。\nSense 2.0の紹介！ Marvel 1.xはKibana 3.0をベースにしていました。 これは、データの探索やダッシュボードツールとして素晴らしいものでした。 しかし、Kibanaチームはさらに素晴らしいものを出しました。 Kibana 4.xはElasticsearchをバックエンドとするUIアプリを簡単に構築することができる プラットフォームとして設計されています。 実際に、Marvel 2.0はKibanaの プラットフォームで利用できる最初のアプリです。\nSenseの話に戻します。 ElasticsearchのAPIとやりとりする一般的なコンソールです。 これをKibanaのアプリぴったりだと気付きました。 ということで、Sense 2.0をKibanaアプリとしてオープンソースで公開しました。 開発及び本番環境で利用してください。\nFigure 2. Screenshot Sense 2.0 ※画像に関しては原文をご覧ください。\nリリースのハイライト Sense 2.0の新しい機能をここで簡単に紹介します。 （すべての変更点についてはこちらをご覧ください。）\nElasticsearch 2.0 SenseのナレッジベースをElasticsearch 2.0サポートに更新しました。 新しいPipeline aggregationにも対応しています。\n複数リクエストの実行 テストやいくつかの一連のコマンドを繰り返し実行したい時があるでしょう。 その時に、それら全てをSenseに記述し、 実行したいリクエストを選択状態にしてElasticsearchにリクエストできます。\nFigure 3. Submit multiple requests ※画像に関しては原文をご覧ください。\nSenseは、Elasticsearchにリクエストを一つずつ送信し、それぞれの出力結果を右のパネルに表示します。 これは、問題のデバッグや複数のシナリオでのクエリの組み合わせの実行に非常に便利です。\n複数リクエストのコピーペースト 複数リクストを選択し、フォーマットしたり、cURLのコマンドとしてコピーすることも可能です。\nFigure 4. Copy multiple requests as cURL ※画像に関しては原文をご覧ください。\n# Delete all data in the `website` index curl -XDELETE \u0026#34;http://localhost:9200/website\u0026#34; # Create a document with ID 123 curl -XPUT \u0026#34;http://localhost:9200/website/blog/123\u0026#34; -d\u0026#39; { \u0026#34;title\u0026#34;: \u0026#34;My first blog entry\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;Just trying this out...\u0026#34;, \u0026#34;date\u0026#34;: \u0026#34;2014/01/01\u0026#34; }\u0026#39; もちろん、複数のcURLコマンドをコピーしてSenseにペースとすると、Senseはそれらをパースしてくれます。\nまとめ Sense 2.0.0のベータリリースです。 実際に多くの作業が終わった認識です。すぐにGAが出るでしょう。\nSense 2.0を知り、試していただくために、新しいドキュメントを参考にしてください。 バグやリクエストがある場合は、フォーラムやGitHubのIssueに登録をお願いします。\n","date":1446195306,"dir":"post/2015/","id":"5912529cfd6ce14c5ede5c6c83dae7e8","lang":"ja","lastmod":1446195306,"permalink":"https://blog.johtani.info/blog/2015/10/30/sense-2-0-0-beta1-ja/","publishdate":"2015-10-30T17:55:06+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：The Story of Sense - Announcing Sense 2.0.0-beta1 誕生 よくある良いプロジェクト同様、Senseもビールを飲みながら考","tags":["elasticsearch","sense"],"title":"Senseの歴史 - Sense 2.0.0-beta1の紹介(日本語訳)"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Shield, Watcher, and Marvel 2.0.0 GA Released\n本日（10/28）Shield、WatcherおよびMarvel 2.0をリリースしました。 これが、Elasticsearch 2.0に対応したこれらのプラグインの最初のリリースです。\nElasticsearch 2.0対応のほかに、ShieldとWatcher 2.0は、 セキュリティとアラートを拡張するいくつかの新しい素敵な機能も備えています。\nShield 拡張可能なレルム - Sheild 1.xはユーザ認証のコア的なものを定義するのにフォーカスし 3つの認証メカニズム（esusers、LDAP/AD、PKI）を提供しました。 これらを提供することで、多くのユーザおよびユースケースをカバー出来ましたが、 追加の認証メカニズムを統合する必要があることもわかっていました。 ということで、Shieldのレルムベースの認証システムをユーザが利用、拡張できるようにオープンにし、 ユーザ認証を扱うためのレルム実装をプラグインとして拡張できるようにしました。 特定もしくはプロプライエタリな認証メカニズムが必要なユーザもShieldの強力な セキュリティ機能（ロールベースの認証、セキュアな通信など）をフルに活用できるようになりました。 カスタムレルムの詳細については、こちらをご覧ください。\nフィールドとドキュメントのACL - Shield 2.0はフィールドとドキュメントレベルのアクセス制御機能を提供します。 これは、ロールごとにアクセス可能なフィールドやドキュメントを定義できます。 この新しい機能は、設定の変更するよりも便利です。 このアクセス制御はElasticsearchのLuceneインデックスという最も低レベルで実装されています。 その結果として、このメンテナンスがより簡単であるだけでなく、より良くなっています。 詳細についてはこちらをご覧ください。\nユーザなりすまし - Shield 2.0で、ユーザなりすましの機能が実装されました。 これは、ユーザ（適切なパーミッションを持った）が、他のユーザになることができ、 それらのユーザのためにリクエストを実行できます。 これは、Elasticsearch上に構築されたアプリケーションがすでにユーザ認証を行いますが、 認可はElasticsearchサイドで行う必要があるような場合に有用です。 このシナリオで、アプリケーションの\u0026quot;main\u0026quot;ユーザを設定でき、正しくなりすましを割り当て、 ElasticsearchにアプリケーションユーザとしてリクエストをElasticsearchに実行させることができます。 詳細については、こちらをご覧ください。\nWatcher SlackとHipChatインテグレーション - SlackとHipChatはチーム/グループコラボレーションツールです。 これらは、急速に主流になり、組織の主な内部コミュニケーションハブとなっています。 Watcher 2.0はチャンネル/ルームやユーザにこれらのコミュニケーションチャネル経由で、Watchの通知を行うことができるアクションを 実装しました。 slackやhipchatアクションについてはドキュメントをご覧ください。\nArray Compare Condition - 新しいconditionはタイムシリーズのデータのスパイクを検知するのを簡単にします。 compare conditionは1.xで導入されましたが、このコンディションはElasticsearchのダイナミックスクリプト機能を有効にする必要がアンク使えます。 詳細についてはarray_compare conditionをご覧ください。\nWatchの有効・無効化 - ユーザからの多かったリクエストとして、Watchの無効化がありました。 1.xには、登録済みのWatchを無効にする機能がありませんでした。 これは、Watchを消すか、Watchのトリガーを変更することで回避していました。 これは、全体としてはWatchを管理するのを難しくする回避方法でしかありません。 2.0では、APIを呼び出すだけで、Watchの変更をすることなく、簡単にWatchの有効化・無効化が可能になりました。 これは1.0からあるべき基本的な機能でしたが、ついにこの問題を解決しました。 詳細はこちらをご覧ください。\nMarvel Marvel 2.0を紹介するのに興奮しています。 Kibana 4をベースとした、再設計されたUIを持っています。 Marvel 1.xで学んだ多くのことを導入し、より使いやすく監視しやすいUIになっています。 ShieldとWatcherと同様に、最初のMarvelのリリースは将来的な成長の基盤となり Elasticsearch2.0を効率的に管理するための主要なメトリックにフォーカスしています。\n画像あり。 ※画像に関しては原文をご覧ください。\n再設計により、インタフェースを6ページに減らしています。\nCluster list 画像あり。 ※画像に関しては原文をご覧ください。\nユーザやカスタマーの多くは複数のクラスタを利用しています。 新しいMarvelはそれらを集中的にモニタリングする一つのクラスタからそれらを簡単に監視できます。 各クラスタのデータ送信先をこのモニタリングクラスタにするだけです。\nCluster Overview 画像あり。 ※画像に関しては原文をご覧ください。\nクラスタオーバービューはある一つのクラスタの主要な性能メトリックを見ることができ、 素早くスパイクを発見できます。 このページはまた、アクティブなシャードのリカバリやリロケーションも見ることができます。\nIndices List 画像あり。 ※画像に関しては原文をご覧ください。\nインデックスのリストにはクラスタにあるすべてのインデックスとその属性が表示されます。 テーブルはライブでアップデートされ、フィルタリングやソートも可能です。 一番大きなインデックスは？といったことも調べられます。\nIndex Detail 画像あり。 ※画像に関しては原文をご覧ください。\nインデックス詳細ページはインデックスの主な性能メトリックを見ることができ、シャードの配置についても表示します。\nNodes List 画像あり。 ※画像に関しては原文をご覧ください。\nノードリストはクラスタにあるノードとその主な性能メトリックを見ることができます。 テーブルはライブでアップデートされ、フィルタリングも可能です。 高いCPU利用率やディスクの残り容量なども簡単にわかるようになっています。\nNode Detail 画像あり。 ※画像に関しては原文をご覧ください。\nノード詳細ページは個別のノードに関する主な性能メトリックを見ることができ、ノードにあるシャードのリストも見ることができます。\n新しいMarvelはKibana 4の上に構築されたので、管理方法が変わっています。 Marvelのインストールは2つのステップがあります。 marvel-agentとmarvel user interfaceです。\nMarvel Agent marvel-agentはElasticsearchクラスタにプラグインとしてインストールします。 主なパフォーマンス情報を取得し、ローカルもしくは分離されたモニタリングクラスタにデータを保存・送信します。\nMarvel User Interface Marvel UIはKibanaのプラグインとしてインストールします。 これは、Kibana 4.2の新しいプラグインインフラを利用し、 Marvel Appとして、Kibanaのインタフェースとは個別に提供されます。 Kibanaのアプリの切り替えは次の画像の通りです。\n画像あり。 ※画像に関しては原文をご覧ください。\n2.0リリースは私たちのプロダクトの大きな一歩です。またユーザの意見を常にお待ちしています。 ぜひ、Webフォーラム（https://discuss.elastic.co）やメール（info@elastic.co）でご意見を。\n","date":1446189691,"dir":"post/2015/","id":"15700442e957951307bbcec5fff8643d","lang":"ja","lastmod":1446189691,"permalink":"https://blog.johtani.info/blog/2015/10/30/shield-watcher-and-marvel-2-0-ga-released-ja/","publishdate":"2015-10-30T16:21:31+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Shield, Watcher, and Marvel 2.0.0 GA Released 本日（10/28）Shield、WatcherおよびMarv","tags":["elasticsearch","shield","watcher","marvel"],"title":"Shield、Watcher、Marvel 2.0.0 GAリリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 2.0.0 GA released\nElasticsearch 1.0.0のリリース以降、 477のコミッター2,799のpull requestがあった、 **Elasticsearch 2.0.0 GA（Lucene 5.2.1ベース）**をリリースしました。\nそれだけでなく、Shield（セキュリティプラグイン）とWatcher（アラーティングプラグイン）、 新しくなったMarvel（モニタリングプラグイン）（プロダクション環境でフリー！）、 また、新しくオープンソースとなったSense editorの2.0.0もリリースしました。\nElasticsearch 2.0.0のダウンロードはこちらから。 また、2.0.0での重要な変更点についてはこちらをご覧ください。 全ての変更点については、次をご覧ください。\nChanges list for Elasticsearch 2.0.0 Changes list for Elasticsearch 2.0.0-rc1 Changes list for Elasticsearch 2.0.0-beta2 Changes list for Elasticsearch 2.0.0-beta1 商用プラグインについてはこちらです。\nShield 2.0.0 change logs Watcher 2.0.0 change logs Elasticsearchの新機能 Elasticsearch 2.0.0には素晴らしい新機能があります。\nPipeline Aggregations Aggregationsで導関数や移動平均のような他のAggregationの結果に対する計算が可能となります。 この機能はクライアントサイドで実装しなければなりませんでしたが、 Elasticsearchに計算させることで、より強力な解析のクエリを簡単に組み立て、クライアントのコードを簡略化できます。 これは、予測解析や予測解析や例外検知といった可能性をもたらします。 Pipeline Aggregationについては次をご覧ください。\nOut of this world aggregations. Staying in Control with Moving Averages - Part 1. Staying in Control with Moving Averages - Part 2. Query/Filter merging フィルタはもうありません。 全てのフィルタ条件はクエリとなりました。 クエリコンテキストで使用した場合、関連度のスコアに影響し、フィルタコンテキストで使用した場合、 これまでのフィルタのように、ヒットしなかったドキュメントを除外するだけとなります。 この変更はクエリの実行時に自動的に最も効率的な順序で実行するように最適化されることを意味します。 例えば、遅いクエリ（フレーズやgeo）の最初の実行は速い近似フェーズで実行され、 それから、遅い正確なフェーズで結果を修正します。 フィルタコンテキストでは、直近でよく使われた条件が自動的にキャッシュされます。 詳細については、\u0026quot;Better query execution coming to Elasticsearch 2.0\u0026ldquo;をご覧ください。\n設定可能な圧縮率 _sourceのようなStored fieldsは高速なLZ4（デフォルト）で圧縮するか、インデックスサイズを小さくできるDEFLATE で圧縮できます。 これは、特にロギングのケースで便利です。 古いインデックスをオプティマイズする前にbest_compressionに変更することができます。 詳細については\u0026rdquo;Store compression in Lucene and Elasticsearch\u0026ldquo;をご覧ください。\n堅牢に 新しいElasticsearchはJava Security Managerの元で実行されます。 これは、セキュリティの観点で大きな前進です。 Seciruty ManagerはElastcsearchにより制限をかけ、ハッカーによりシステムに対して何でもできるようなものを制限します。 Elasticsearchはまた、インデキシングの観点でも堅牢になっています。\nドキュメントはインデキシングリクエストに答える前に、耐久性のためにディスクにfsyncされます。 すべてのファイルはチェックサムにより、早期に障害を検知します。 すべてのファイルはどんなファイルへの書き込みもアトミックです 最後に、システム管理者から要請の多かった変更として、 設定されて居ないノードがパブリックなネットワークから参加しないようになりました。 Elasticsearchはデフォルトではローカルホストのみにバインドします。マルチキャストは無くなりました。（プラグインとして残っています。）\nパフォーマンスと信頼性 上記以外にも細かな修正がElasticsearchとLuceneにはあります。 より安定し、信頼性をあげ、簡単に設定できるようにするものです。例えば、次のようなものです。\nヒープの使用率の低減（doc valuesがデフォルト、マージ時のメモリ使用率の削減、 roaring bitsetsによるフィルタキャッシュ） 構造化され読みやすくなった例外 設定の代わりに、フィードバックループを使用した自動調整 安全で明確で信頼性のあるタイプマッピングの大きな修正 クラスタ状態の差分変更による伝搬の高速化および、大きなクラスタでのより安定的に normsの圧縮の改善。これまではヒープスペースを大きく利用していた。 マージの自動的な調整（不可解な設定の微調整が必要ない） より詳細なLuceneのメモリリポート 最適化されたクエリ実行を活用するためにParent/childを書き換え コアプラグイン 公式にサポートされたコアプラグインはElasticsearchと同じバージョン番号で同じタイミングでリリースされます。 インストールするプラグインとElasticsearchの複雑なバージョンの対応表に悩まされる必要はもうありません。 コアプラグインのインストールは次のように簡略化されています。\nbin/plugin install analysis-icu ShieldとWatcherの新機能 商用プラグインも新しい機能をリリースしました。\nShield フィールドおよびドキュメントレベルのアクセス制御 ユーザのなりすまし カスタム拡張可能な認証レルム Watcher 個別のWatchを有効/無効に SlackやHipChatへの通知 これらの詳細については“Shield, Watcher, and Marvel 2.0.0 GA Released”をご覧ください。\nコアプラグイン同様、商用プラグインもElasticsearchのバージョンと同じものが同時にリリースされます。 インストールは次の通りです。\nbin/plugin install license bin/plugin install shield bin/plugin install watcher Marvel 2.0.0はプロダクションでの利用もフリーに Marvelモニタリングプラグインはカスタマに非常に価値のあるもので、 ユーザの発展とともに問題を診断したり見つけたりするのに役に立ってきました。 私たちは、何を改善でき、Mαrvelを一から書き直すことで、いろいろとわかったことがあります。\nMarvel UIを新しいKibanaプラットフォーム上に構築 ダッシュボードにはより簡単に問題を発見するために、最も重要なメトリックを可視化 1つのインストールで、複数のクラスタのモニタリングをサポート（商用サポート対象） 一番良い点はMarvelがすべてのElasticsearchユーザに対してプロダクション環境でフリーになったことです！ ライセンスが必要ですが、課金の必要はありません。 もし、マルチクラスタモニタリングサポートが必要な場合、それは商用サポート対象となります。\n詳細に関しては“Shield, Watcher, and Marvel 2.0.0 GA Released”をご覧ください。\nSense editorがオープンソースに Sense（ブラウザベースのElasticsearchリクエストとDSL向けのエディタ）を Kibanaプラットフォームのアプリとして、オープンソースにしました。 また、このリリースで新しい機能が追加されています。\n複数のcURLリクエストをペースとすると、Sense表記に変更 複数のSenseリクエストをcURL表記にしてコピー 複数のリクエストを一度に実行可能 Elasticsearch 2.0サポートとなった自動補完機能 SenseはKibanaのアプリとして次のようにインストールします。\n./bin/kibana plugin --install elastic/sense Senseの詳細については、\u0026quot;The Story of Sense - Announcing Sense 2.0.0-beta1\u0026ldquo;をご覧ください。\nElasticsearch Migration Plugin Elasticsearch Migration PluginはElasticsearch 1.xから2.0にアップグレードする時の良い出発点となります。 1.xのElasticsearchクラスタにサイトプラグインとしてインストールすると、 アップグレードする前に解決すべき問題があるかどうかを検知してくれます。 （例えば、Lucene 3のような古いインデックスや、2.0.0にした場合に動作しない問題のある マッピング（The Great Mapping Refactoring）のような問題）\nプラグインに関してElasticsearch Migration repositoryをご覧ください。\nまとめ ぜひ、Elasticsearch 2.0.0をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)やWebフォーラムなどで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1446103243,"dir":"post/2015/","id":"018e32a8010960eb17e368a6fdd5a51b","lang":"ja","lastmod":1446103243,"permalink":"https://blog.johtani.info/blog/2015/10/29/elasticsearch-2-0-0-released-ja/","publishdate":"2015-10-29T16:20:43+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0 GA released Elasticsearch 1.0.0のリリース以降、 477のコミッター2,79","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0リリース(日本語訳)"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Kibana 4.2.0 released\nElasticsearch 2.0 + Kibana 4.2 = 💚 Elasticsearch 2.0サポートのKibanaの最初のリリースです。 これが何を意味するでしょう？ 速さ、安定さ、新しい機能。 試してみたい方は、いますぐダウンロードしてください。 そうでない方は、Kibana 4.2の楽しい機能について読んでみてください。\n暗黒面は怖い？ そんなことありません。 私たちは常にチャートチャートとダッシュボードを組み立てている組み立てている間は明るいバックグラウンドを使うことを推奨してきましたが、 時々、巨大なスクリーンで暗い部屋で誰も明るい画面から目を背けないようにしたいでしょう。 その影響を小さくするためにダークモードを導入しました。 あなたは、NOCや天文台、その他の暗い場所でKibanaのダッシュボードを楽しむことができます。\n画像あり。 ※画像に関しては原文をご覧ください。\n地図のカスタマイズ Kibanaの地図は素晴らしいですが、もっと多くのオプションが望まれていると聞きました。 もし地図に関して知識があるなら、Kibana 4.2のWMSバックグラウンド地図サポートを試してみてください。 WMSは非常に強力で、US Geological Surveyを含む多くの無料サービスがあります。 http://viewer.nationalmap.gov/example/services/serviceList.html\n画像あり。 ※画像に関しては原文をご覧ください。\nシナリオは？ 何かおかしい時、何が起こっているかを正しく知ってもらいたいので、Kibanaがそのタイミングで注目したいコンポーネントがあるなら、 どのように動いているかという概要を知るためのサーバステータスページを作りました。 もちろん、全てがOKであるというのを知りたいだけの場合でも、settingメニューのStatusタブからいつでも呼び出せます。\n画像あり。 ※画像に関しては原文をご覧ください。\n全てにおいて速く ブラウザリフレッシュはKibana 4.2の新しいコードビルディングシステムのおかげで、さらに早くなりました。 また、メモリを覚えてます？Pepperidge FarmKibanaが覚えています。 Kibana 4.2は小さな小さな小さなメモリフットプリントを管理している間、長い長い長い時間実行されているダッシュボードを見ることができるような 大きなメモリのクリーンアップも含んでいます。\nもっとありますが。。。 小さな微調整がいくつもあります。また、今後紹介する本当に刺激的なものの基礎を気づき上げてきました。 これからもElasticのブログ、Twitter、KibanaのGitHubリポジトリに注目し、モンスタートラックアナリティクスの瞬間に立ち会ってください。\n","date":1446103219,"dir":"post/2015/","id":"e159a35d1b9a46e03072a3d54780edcb","lang":"ja","lastmod":1446103219,"permalink":"https://blog.johtani.info/blog/2015/10/29/kibana-4-2-0-ja/","publishdate":"2015-10-29T16:20:19+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Kibana 4.2.0 released Elasticsearch 2.0 + Kibana 4.2 = 💚 Elasticsearch 2.0サポートのKibanaの最初のリリースです。 これ","tags":["elastic","kibana"],"title":"Kibana 4.2.0リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Logstash 2.0.0 released\nLogstash 2.0.0が本日（10/28）リリースされました。 このリリースは いくつかの設定に関する重要な変更があります。 詳細については、changelogまたは、新しいbreaking changesドキュメントをご覧下さい。\nこれまでの2.0.0直前のリリースに関する変更点はこちらをご覧ください。\nbeta1 beta2 beta3 RC ここでは、2.0の主な変更点の概要を説明します。\nElasticsearch 2.0との互換性 多くの機能および改善を含んだElasticsearch 2.0がリリースされました。 Logstash 2.0はこのリリースに対応しています。 Logstashのこれまでのリリースでは、デフォルトで、Javaの node clientをElasticsearchとの通信として 使用してきました。 2.0では、HTTPクライアントがデフォルトになります。 これにより、シームレスにユーザのデータを取り込み、付加価値をつけ、Elasticsearchに保存して解析することができます。\nHTTPは他のプロトコル（nodeやtransport）同等の機能を持っていますが、 単一のクライアントに接続する時に、少しだけ遅いですが、管理や動作がより簡単です。 HTTPプロトコルを使うことで、Elasticsearchのバージョンのアップグレードが、Logstashのアップグレードすることなく 行うことができます。 デフォルトをHTTPに変更したさらに詳しい情報についてはbeta1のブログをご覧ください。\n他のプロトコル（nodeとtransport）もサポートしますが、これらを利用する場合には、 プラグインを別途インストールする必要があります。\nbin/plugin install --version 2.0.0 logstash-output-elasticsearch_java 互換性のマトリックス LogstashとElasticsearchのバージョンの互換性は次のようになります。\n画像あり。 ※画像に関しては原文をご覧ください。 #Image https://www.elastic.co/assets/bltde5b69e2164aa82f%2Fcompat_matrix.png\nShield 2.0との互換性 このリリースはShield 2.0リリースにも対応しています。 HTTPプロトコルで、追加のプラグインは必要ありません。 こちらのドキュメントをご覧ください。 transportプロトコルでは、Shield 2.0対応のプラグインを個別にインストールする必要があります。\nbin/plugin install --version 2.0.0 logstash-output-elasticsearch_java_shield パフォーマンスの改善 このリリースはまた、多くの部分のパフォーマンスの改善を含んでおり、Logstashを利用してデータをより早く処理することができます。 いくつかをここで説明します。\nUserAgentとGeoIPフィルタ：これらのフィルタで、LRUキャッシュを追加して改善しています。 これにより、IPとユーザエージェントがまとまって現れるというWebリクエストの特性を用いています。 ユーザエージェントフィルタのケースでは、サンプルデータセットにおいて3.7倍ほど早くなりました。 GeoIPでは、1.69倍早くなっています。\nJSONプロセシング：LogstashでJSONのsiriaraizu/でシリアライズに利用しているJrJacksonを新しいバージョンにしました。 これにより、JSONの処理が改善されています。\nフィルタワーカーのより良い値をデフォルトに：以前のリリースでは、filter_workersの設定は1がデフォルトでした。 これは、フィルタの処理を行うワーカーが1つであるという意味です。 filter_workersの設定のデフォルト値はCPUコア数の半分の値を設定します。フィルタ実行の並列性が上がります。 ですので、複雑なgrokパターンやuseragentフィルタの処理がにとっては重要です。\nFilebeat Support Filebeatのベータバージョンを先日リリースしました。 これは、Logstash Forwarderの次期バージョンです。 Filebeatはファイルベースのログをさらに処理するためにLogstashに送るためのエージェントです。 2.0.0はlogstash-input-beatsプラグインを使えばFilebeat 1.0.0-beta4とすぐに動作します。\nシャットダウン操作 これまでのLogstashでは、シャットダウンが開始した時に、例外の機構でシャットダウンが開始したことを プラグインに通知していました。 この処理はサードパーティのコードを使ったプラグインで問題を起こしていました。 Logstashはどの例外を処理するか知らないため、予期しない動作をしていました。 これを修正するためにAPI呼び出し（例えばstop）を各プラグインにシャットダウンのイベントを通知し、 プラグイン自身がきちんと停止するようにしました。 これは、200以上のプラグインに新しいAPIを利用するように修正しないといけないことを意味しました。 しかし、Logstashの停止についてはまだ完全にはフィックスしていません。 とちゅうでおわっているoutputがシャットダウンを遅らせる可能性があるからです。 2.0でAPIの破壊的な変更は適切なリリースでの変更を繰り返すことができる出発点です。\nプラグインの開発者へ：もし、Logstash　1.5のプラグインを開発しているなら、 シャットダウンに関する新しいAPIのリストに関するbreaking changesのドキュメントに助言をください。 また、example inputリポジトリにて、新しいシャットダウンメカニズムの使い方のサンプルコードを提供しています。\nドキュメント 2.0に更新されたドキュメントはこちらです。設定の変更についてもこちらをご覧ください。\n2.0へのアップデート 2.0へアップデートする前に、アップデートガイドもご覧ください。\nフィードバック 2.0のリリースできたことに、多くのコントリビューター、ユーザに感謝しています。 このリリースに含まれている多くのパッチと全てのプレリリースのテストにも感謝しています。 将来の修正やリリースなどについてはロードマップをご覧ください。 2.0は今日リリースされました。 ご意見ご感想はWebフォーラムで！\n","date":1446103197,"dir":"post/2015/","id":"cc64c2fcdecdb505b3797e1aaaa59adc","lang":"ja","lastmod":1446103197,"permalink":"https://blog.johtani.info/blog/2015/10/29/logstash-2-0-0-released-ja/","publishdate":"2015-10-29T16:19:57+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Logstash 2.0.0 released Logstash 2.0.0が本日（10/28）リリースされました。 このリリースは","tags":["elastic","logstash"],"title":"Logstash 2.0.0リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Relase, we have ※画像に関しては原文をご覧ください。\nElasticにとって大きな1日（社内では「release bonanza」と呼んでいる）です。 多くの主要なプロダクトを新たにリリースしました。 そして、本日、それらを一緒に利用する時にそれらを一緒に利用する時にユーザの体験についてまとめてみました。\n次の通りです。\nElasticsearch 2.0リリース。 大きなマイルストーン、チームによる改善、そして、コミュニティからの素晴らしい貢献。 Pipeline Aggsと呼ばれる新しいタイプのaggregations、 クエリとフィルタのコンセプトを統合することにより簡素化されたクエリDSL、 better compressionオプション、 JavaのSecurity Managerを有効にすることによる強化されたセキュリティ、 FSの挙動に関する強化（fsync、checksum、atmicなリネーム）、 パフォーマンス、マッピングの挙動の一貫性などなどです。 また、我々のチームによる改善も含まれているLucene 5ベースにアップグレードしています。\nKibana 4.2リリース。 Elasticsearch 2.0対応、ダークテーマ、カスタマイズ可能な地図、多くの改善。 Kibana 4.2の多くに作業については外部プラグインサポートといった、内蔵に関するものでした。 この後の説明に続きます。\nMarvel 2.0リリース。 Elasticsearch 2.0対応、合理化されたメトリックス、簡素化されたUI、 多くはKibanaプラグイン（Kibanaプラットフォーム上に構築）としての書き換えです。 このKibana拡張の最初の努力は、Kibanaのプラグインをどうやって書くか、 Kibanaユーザに公式に何をする必要があるかといったものを特定するのに役立ちました。 おっと、忘れるところでした、Marvelを全てのユーザにフリーで使えるようにしました。 マルチクラスタサポートについては有償となります。\nSense 2.0リリース。 2つ目のKibanaプラグインがこれです。 SenseをKibanaプラグインとして書き換えました。 Elasticsearch 2.0サポート、複数リクエストの実行、 curlへのコピーなどです。 おっと、忘れるところでした。オープンソースとすることにしました！\nShield + Watcher 2.0リリース。ElasticsearchのためのセキュリティプラグインであるShieldと、アラート管理のためのプラグインであるWatcherにも 多くの結果が入っています。 最も要求のあった機能である、フィールドお呼びドキュメントレベルでのセキュリティについて、Luceneに落とし込んで実装しました。 また、セキュリティの操作についてプラガブルに実装できるように変更しました。 Watcherは監視の無効化、SlackやHipChatへの通知（bot ops向け）が可能です。\nLogstash 2.0リリース。 Elasticsearch 2.0のサポート、クリーンな停止、全面的なパフォーマンス改善、Beatsサポート。\nご覧の通り、すべてのプロダクトに関する大きな結果です。 チーム間およびFoundの開発者との間での密な連携に感謝します。 これらが私たちが公式にElasticsearch / KibanaをホストしているFoundで 利用可能です。\nひゅう、息切れしました。 チームがしてきたことは、感動的で、謙虚で、刺激的です！ Elasticが会社として、全てのユーザ、コントリビュータがどのように私たちの大きなミッションに対する結果をもたらしたかという素晴らしい良い例です。 ユーザに愛され、楽しまれ、成功に導き、革新させる製品を是非ご利用ください。ありがとうございます。\n\u0026ldquo;A Lion, in Africa?\u0026rdquo; - まだまだ終わりではありません。この文言で終わりにしますが、すぐに（本当にすぐに）戻ってきます。;)\n","date":1446095939,"dir":"post/2015/","id":"4cc08ca51ecf0f963035f039de6194c5","lang":"ja","lastmod":1446095939,"permalink":"https://blog.johtani.info/blog/2015/10/29/release-we-have-ja/","publishdate":"2015-10-29T14:18:59+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Relase, we have ※画像に関しては原文をご覧ください。 Elasticにとって大きな1日","tags":["elasticsearch","kibana","logstash"],"title":"Release, we have（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 2.0.0-beta2 released\n本日（9/17）、Lucene 5.2.1ベースのElasticsearch 2.0.0-beta2をリリースしました。 本リリースが2.0.0のRCの前の最後のベータリリースになります。\n注意事項 本リリースはベータリリースであり、テストを目的としたものとなります。 Elasticsearch 2.0.0-beta2はElasticsearch 2.0.0-beta1と互換がありません。 また、Elasticsearch 2.0.0 GAと互換性があるかどうかの保証はありません。\n本番環境には利用しないでください。\nElasticsearch 2.0.0-beta2のダウンロードおよび、すべての変更についてはリンクをごらんください。\n2.0.0-beta1をテストし、問題点を報告していただいた皆様、ありがとうございます。 2.0.0-beta1のあとのElasticsearchのコアの部分の修正のほとんどはバグフィックスになりますが、 geo_shapeフィールドのpoints_only最適化のようなちょっとした改善も含んでいます。\nまた、本リリースでは、商用プラグインの重要な新機能もあります。 こちらについてはShield and Watcher 2.0.0-beta2 releasedをごらんください。 簡単な紹介は次の通りです。\nShieldの新機能 ドキュメントおよびフィールドレベルのセキュリティ Shieldは、クエリを利用したインデックスにあるドキュメントへのアクセスを制御するためのロールを定義できるようになりました。 また、ドキュメントにある特定のフィールドに関するアクセス制限も可能です。 フィルタされたエイリアスのような形ではなく、ドキュメントを検索したり、IDで取得したりする場合にこれらの制限が利用できます。 詳細はField- and Document-level Securityをごらんください\nユーザなりすまし 特定のユーザーに他のユーザーに扮して、彼らのためにリクエストを実行する能力を与えることが、現在できます。 これは、認証がアプリケーションによって実行される場合に便利です。 そして、それは、ユーザの許可レベルを考慮するようにElasticsearchにリクエストします。 詳細はSubmitting Requests for Other Usersをごらんください。\nプラガブルな認証レルム このリリースで、サードパーティの拡張のための認証レルムのインフラを公開しました。 もし、特定の認証要求があり、Shieldがサポートしていない（が、内部の認証管理システムを使いたいような）場合、 これらの要求に見合う新しい認証レルムを利用するプラグインを作成可能です。 詳細はCustom Realmsをごらんください。\nWatcherの新機能 監視の一時 新しく、active / inactive の状態がwatchに追加されました。 これらは、Watchを中断したり、要求に応じて再開させたりできます。 詳しくは、Active Stateをごらんください。\nチャットのための新しいアクション slackとhipchatアクションが追加されました。 これは、Watcherが通知を、SlackやHipchatのユーザに直接送ったり、 チームのチャットルームに送ったりすることが出来るようにします。 詳細については、Slack actionおよび、Hipchat actionをごらんください。\n2.0に関するこれまでのブログ記事 これまでのリリースについての情報はこれらのブログ記事をごらんください。\n\u0008* Elasticsearch 2.0.0.beta1 released\nElasticsearch 2.0.0.beta1 coming soon! The Great Mapping Refactoring Store compression in Lucene and Elasticsearch Better query execution coming to Elasticsearch 2.0 Out of this world aggregations Staying in Control with Moving Averages - Part 1 Staying in Control with Moving Averages - Part 2 The Delete by Query API Is now a plugin Elasticsearch unplugged - Networking changes in 2.0 また、Elasticsearch 2.0.0-beta2のドキュメントや2.0のbreaking changesのリストもごらんください。\nElsticsearch Migration Plugin Elasticsearch Migration Pluginは、既存のインデックスをアップグレードする 必要があるか、他に必要な行動がないかについて、Elasticsearch 2.0.0-beta2を試す前に確認する助けとなります。 Lucene 3のような古いインデックスや、2.0.0にした場合に動作しない問題のある マッピングのような問題を発見できます。\nプラグインの動作に関しては[Elasticsearch Migration repository](Elasticsearch Migration repository)をごらんください。\nテストしましょう！ Elasticsearch 2.0.0 GAをすぐにリリースできるようにより多くのベータテスターをお待ちしています。\nぜひ、Elasticsearch 2.0.0-beta2をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)やWebフォーラムなどで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1442565101,"dir":"post/2015/","id":"4b227d61f33182579cd3edd0ac6c7c44","lang":"ja","lastmod":1442565101,"permalink":"https://blog.johtani.info/blog/2015/09/18/elasticsearch-2-0-0-beta2-released-ja/","publishdate":"2015-09-18T17:31:41+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0-beta2 released 本日（9/17）、Lucene 5.2.1ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0-beta2リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch unplugged - Networking changes in 2.0\nElasticsearchをローカルのマシンで起動します。 そして、昨日試したデータを削除するためにDELETE *を実行します。 すると、悲しそうな叫びを同僚が発していることに気づき、なぜそんなことになっているのか不思議に思うでしょう。。。\nElasticsearchはいつも、親しみやすいものでした。 複数ノードのクラスタがどのように機能するのかをテストするには、 ローカルのマシンでいくつかのElasticsearchのインスタンスを起動するだけでした。 起動したインスタンスはマルチキャストを利用して自動的にお互いを見つけて、1つのクラスタになり、負荷を共有し始めます。 しかし、これは親しみやすすぎました。 カンファレンスなどで、ローカルのマシンでElasticsearchを起動してみてください。 すると100ノードのクラスタに参加しているのがすぐにわかるでしょう。\nもうすぐリリースされる、2.0.0-beta1では、Elasticsearchが通信先を選択するネットワークの機能に関する変更があります。 ただし、これまで通り、簡単に開発者が経験できる機能も残っています。\nlocalhostへのバインド 以前、Elasticsearchはデフォルトで、利用可能なネットワークインタフェース全てにバインドしていました。 そこから、一番適したインタフェースをpublish_hostとして選択しようとします。 このアドレスはElasticsearchがクラスタの他のノードとやりとりするためのアドレスです。\nElasticsearch 2.0では、デフォルトでは、localhostにのみバインドします。 127.0.0.1（IPv4）と[::1]（IPv6）の両方にバインドしようとします。 また、どちらかのみの環境でも動作します。 この変更は、特に指定がない限り、Elasticsearchがネットワーク上の他のノードと接続しません。 本番環境に移行する場合は、network.hostパラメータを使って設定しましょう。 設定は、elasticsearch.ymlに記述するか、コマンドラインで指定します。\nbin/elasticsearch --network.host 192.168.1.5 bin/elasticsearch --network.host _non_loopback_ network.hostの全てのオプションについては、network settingsのドキュメントをごらんください。\nマルチキャストは廃止 Elasticsearch 1.xはネットワークの他のノードに接続・探索するためにマルチキャストを使用しました。 マルチキャストは魔法のような挙動です。。。 残念ながら、マルチキャストのサポートは良くも悪くもあります。 Linuxはローカルホストでマルチキャストの待ち受けをしていません。 OS/Xは構成されたアドレスの全てのインタフェースにマルチキャストで配信できます。 また、ネットワークによってはマルチキャストはデフォルトでは使用できなくなっています。\nElasticsearch 2.0は異なるアプローチを採用しました。 マルチキャストを廃止します（ただし、新たにプラグインとして提供します）。 代わりに、ローカルホストでは、Elasticsearchはtransport.tcp.portで指定されている範囲（デフォルトは9300-9400）の最初の5ポートに対してユニキャストを使用できるようにします。\nこれは、開発者のための、設定することなく自動的にクラスタを組むという機能を残しています。 しかし、本番に移行するときは、unicast hostsで次のようにリストを指定する必要があります。\ndiscovery.zen.ping.unicast.hosts: [ 192.168.1.2, 192.168.1.3 ] unicast hostsとしてクラスタにあるノードの全てのリストを指定する必要はありません。 少なくとも、マスタノードとして選出されるべきものを指定します。 巨大なクラスタでは、3つの専用のマスタノードを持っており、この3つをunicast hostsとして設定することを推奨しています。\nこれにより、開発の知識・経験が、私たちの推奨する本番でのネットワーク設定に、より近いものとなります。\nノード情報の変更 最後に、inet[/127.0.0.1:9200]といったシンタックスを廃止します。 これは、Elasticsearchがnodes-info APIなどで、使用していたIPアドレスのためのシンタックスです。 今は、RFCに準拠した形で表示します。 127.0.0.1:9200（IPv4）や[::1]:9200（IPv6）のようにです。\n質問がある場合は、ElasticsearchのWebフォーラムで質問してください。ベータはもうすぐです！（翻訳した時点で、すでにベータリリースされています。）\n","date":1440730890,"dir":"post/2015/","id":"0de0edbf2a506143c1739b12e94c0ef9","lang":"ja","lastmod":1440730890,"permalink":"https://blog.johtani.info/blog/2015/08/28/elasticsearch-unplugged-ja/","publishdate":"2015-08-28T12:01:30+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch unplugged - Networking changes in 2.0 Elasticsearchをローカルのマシンで起","tags":["elasticsearch"],"title":"Elasticsearch unplugged - 2.0におけるネットワークの変更(日本語訳)"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 2.0.0-beta1 released\n本日（8/26）、Lucene 5.2.1ベースのElasticsearch 2.0.0-beta1をリリースしました。 本リリースは469名のコミッターからの2,500以上ものpull requestを含んでいます。 pull requestのうち、約850が2.0のための新規のものとなります。\n注意事項 本リリースはベータリリースであり、テストを目的としたものとなります。 Elasticsearch 2.0.0-beta1は Elasticsearch 2.0.0 GAと互換性があるかどうかの保証はありません。\n本番環境には利用しないでください。\nElasticsearch 2.0.0-beta1のダウンロードおよび、すべての変更についてはリンクをごらんください。\nElasticsearch 2.0.0-beta1には次の新しい変更が含まれています。\nPipeline Aggregations：これは、他のaggregationsの結果に対するAggregationを実行できます（導関数、移動平均、Holt Winter予測アルゴリズムなども含む） ディスクやファイルシステムキャッシュにより適したより良いデータの圧縮 doc-valuesがデフォルトになったこと、マージ実行時のメモリ使用量の低減、フィルターキャッシュのためのroaring bitsetsなどにより、ヒープの使用率がより効率的に。 構造化された例外 最適化されたクエリ実行順序、フィルタの自動キャッシュ、より高速なクエリに書き換えられたparent-child 設定の代わりに、フィードバックループを使用した自動調整 トランザクションログへの書き込みがデフォルトで、アトミックでかつ冗長に 安全で明確で信頼性のあるタイプマッピング デフォルトでローカルホストでのみクラスタを構成 クラスタ状態の差分によりより高速に変更を伝搬 上記の変更以外にも、多くのElasticsearchおよびLuceneに対する継続的な変更が含まれています。 これらは、Elasticsearch 2.0をより安全に、より簡単に、より良いものにしています。 本リリースに関するより詳しい情報が次のブログにあるので、参考にしてください。\nElasticsearch 2.0.0.beta1 coming soon! The Great Mapping Refactoring Store compression in Lucene and Elasticsearch Better query execution coming to Elasticsearch 2.0 Out of this world aggregations Staying in Control with Moving Averages - Part 1 Staying in Control with Moving Averages - Part 2 The Delete by Query API Is now a plugin Elasticsearch unplugged - Networking changes in 2.0 また、Elasticsearch 2.0.0-beta1のドキュメントも参考になります。 特に、2.0での重大な変更点については必ずごらんください。\nCore plugins コアプラグインの開発の方法を変更しました。 公式にサポートしているプラグインは、現在elasticsearchのリポジトリに含まれています。 これにより、コアと一緒にテストされ、Elasticsearchと同じタイミングでリリースされます。 コアプラグインはElasticsearchと同じバージョン番号隣ます。 インストールは次のようになります。\nsudo bin/plugin install analysis-icu プラグインの新しいドキュメントは私たちのWebサイトのGuideにあります。\nCommercial plugins 私たちの商用プラグインもElasticsearchと同じバージョン番号となり、Elasticsearchと一緒にリリースされます。 ShieldやWatcherはすでに2.0.0-beta1が利用可能です。 インストールのコマンドはは次のようになります。\nsudo bin/plugin install license sudo bin/plugin install shield sudo bin/plugin install watcher MarvelおよびSenseに関する新しい情報もありますが、もう少しお待ちください。\n2.0.0-beta1の商用プラグインに関するドキュメントは次のリンクからごらんください。\nShield 2.0.0-beta1 Watcher 2.0.0-beta1 Elasticsearch Migration plugin Elasticsearch 2.0.0-beta1を試す前に、 既存のインデックスのアップグレードするためになにか行う必要があるかどうかを確認するためのElasticsearch Migration Pluginもリリースしました。 2.0.0では機能しない、問題のあるマッピングなどを見つけるために便利なプラグインです。\nこのプラグインの利用方法についてはElasticsearch Migration repositoryをごらんください。\n既知の問題 同じインデックスの異なるタイプに、同じ名前のipタイプのフィールドを追加した時に、問題があることがわかっています。 この問題は次のリリースでフィックスされます。詳細は#13112をごらんください。\nテストしましょう！ Elasticsearch 2.0.0 GAをすぐにリリースできるようにより多くのベータテスターをお待ちしています。\nぜひ、Elasticsearch 2.0.0-beta1をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)やWebフォーラムなどで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1440638952,"dir":"post/2015/","id":"744554499cb7880086fbd9b1f080e7e1","lang":"ja","lastmod":1440638952,"permalink":"https://blog.johtani.info/blog/2015/08/27/elasticsearch-2-0-0-beta1-released-ja/","publishdate":"2015-08-27T10:29:12+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0-beta1 released 本日（8/26）、Lucene 5.2.1ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0-beta1リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：The Delete by Query API Is now a plugin\nElasticsearchの2.0.0-beta1では、これまであった Delete by Query APIが削除され、 新しく Delete by Query pluginに置き換えられています。\nもし、Delete by Query を利用する場合、2.0にアップグレードしたあとは、プラグインをインストールし、ドキュメントに従ってください。\nbin/plugin install delete-by-query なぜプラグインに？ ElasticsearchのコアなAPIの品質を保つためであり、以前のDelete by Queryの実装は簡単にはフィックスできない大きな問題がありました。\n各リクエストのあとに、refreshを実行します。これは、削除されたデータが想定外に検索に出てこないようにするためです。\nまた、セグメントが大量にでき、マージが大量に発生し、ヒープが大量に消費されてインデキシングが劇的にスローダウンし、クラスタの複数のノードがクラッシュしてしまう状況も引き起こしました。 このクエリは、プライマリ、レプリカの両方で実行されるため、ことなるドキュメントを削除し、矛盾したレプリカ（データの破損）を引き起こしました。 アップグレードが不安定になります。これは、Delete by Queryリクエストがトランザクションログの中にクエリとして残るためです。そのため、アップグレードのあとに正確にパースされなかったり正確に実行されないかもしれません。例えば、インデックスエイリアスに対するリクエストで、それが削除された後の場合にこのようなバグが発生します。 対照的に、新しいプラグインは、安全な実装です。 scanとscrollリクエストでクエリにマッチしたIDを見つけ、そのIDを使って、bulk indexing APIで削除します。\nこの実装は、遅い必要があります。特に、クエリが多くのドキュメントを削除する場合です。 もし、多くのドキュメントをこのAPIを利用して削除する場合、アプリケーションをテストしてください。 そして、代わりにインデックス全体を消すようなアプローチに切り替えることができないか検討してください。\nDelete by Query pluginのドキュメントに、新しい実装についての違いなどのより詳しい説明があります。\nElasticsearch coreを最小限に プラグインに切り替えることは、簡単な決断ではありませんでした。 多くのユーザは問題なく、Delete by Queryを利用していました。 しかし、危険が常にそこにあり、些細とは言い切れない数のユーザが上記のような深刻な問題に遭遇していました。\nさらに、Elsticsearchのコアは信頼できるものでなければなりません。 他のコアAPIを利用して実装できる機能は、コアに含みません。特に、それがバグを含んでいる場合。 コアのすべての機能は強固であるべきで、Delete by Queryは人気があり、高性能ですが、そうではありませんでした。\n必要に応じて、このような難しいトレードオフの末、信頼性と品質を選びます。\nマッピングの削除の廃止 タイプのマッピングを削除する機能も2.0で廃止されます。 これは、同じフィールド名を、異なるフィールドのタイプで再利用した場合に、インデックスの破損を引き起こす可能性があるためです。\nしかし、Match All Queryで、Delete by Queryプラグインに対してタイプを指定することで、タイプのすべてのドキュメントを削除することはできます。 または、1つのインデックスに異なるタイプを複数含める代わりに、個別のインデックスに分割するようなアプローチに変更することを検討してください。\n","date":1440044644,"dir":"post/2015/","id":"5a9e950f4ac186925e5de978c5f72062","lang":"ja","lastmod":1440044644,"permalink":"https://blog.johtani.info/blog/2015/08/20/core-delete-by-query-is-a-plugin-ja/","publishdate":"2015-08-20T13:24:04+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：The Delete by Query API Is now a plugin Elasticsearchの2.0.0-beta1では、これまで","tags":["elasticsearch"],"title":"Delete by Query APIはプラグインへ（日本語訳）"},{"contents":"第11回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズさん、そして、Shayありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n今回は、CTOのShayが来日していたので、英語でいろいろと喋ってもらいました。 4月同様、サムライズムの@yusukeさんに テキスト翻訳していただき、大変助かりました。 今回はQAベースのトークだったのでちょっときつかったですね、申し訳ない。。。\nチェックイン数など チェックインした人：141名 キャンセルしなかった人：51名 でした。 今回はあらかじめ220名（全員が来たらキャパオーバー）としていたので、キャンセル待ちの人は 当日の午後にはいなくなっていた状態です。まぁ、こんなもんかな。結構入りましたね。ありがたいです。\nLT 今回は、少し趣向を変えて、4社の方達にLTをしていただきました。 Shayが来日しているのもあり、事前に英語でスライドを作っていただけると助かりますとお願いさせていただきました。 英語でスライドを作っていただいていたので、伝わりやすくて助かりました、スピーカーの方々ありがとうございました！\n（海外のユーザにもリンクを紹介しやすいので、英語でスライド作ってもらえるといろいろと知ってもらえるのかも。）\nElasticsearch and Recruit Technologies Co., Ltd. / 株式会社リクルートテクノロジーズ　守谷 純之介さん スライド：未定\nN-Gramと形態素のハイブリッドの話などをしていただきました。 @ITで連載もされてますね。ありがとうございます。\nリクルート全社検索基盤のアーキテクチャ、採用技術、開発体制はどうなっているのか (1/2) ElasticsearchとKuromojiを使った形態素解析とN-Gramによる検索の適合率と再現率の向上 (1/3) Shayからは、elasticsearch-hadoopがあるから検討してねと質問（お願い？）がありましたw。\nElasticsearch as a DMP / 株式会社インティメート・マージャー　松田和樹さん　@mats116 スライド：Elasticsearch as a DMP\nいくつかのデータソースからAEROSPIKE経由でelasticsearchにデータを登録しているようです。 Data Management Platformのエンジンの一部として、elasticsearchを利用しているようです。\nShayからの質問：「どの機能を使って関心のある単語を抽出していますか？」\n回答：「Significant Term Aggregation」です。\nShay：「おぉ、チェックしてみますw」。\nReal-time social big data analytics using elasticsearch / 株式会社ホットリンク宮田洋毅さん　@kakka_jp スライド：未定\nソーシャルメディアのデータを解析するのにelasticsearchにデータを入れて解析。 時間軸での解析やテキストマイニングなんかをしているみたいでした。 いろいろと独自のプラグインを作ってるようです。（興味あるなぁ）\nShayからの質問：「ノード数は？」「30ノードで30シャード」\nElasticsearch in Hatena Bookmark / 株式会社はてな　id:skozawa スライド：Elasticsearch in Hatena Bookmark\nはてなブックマークの検索の歴史（MySQL -\u0026gt; Sedue -\u0026gt; Solr -\u0026gt; Elasticsearch） はてなブックマークの検索（ユーザが利用）と社内利用と、ログ解析で利用してる Shayからの質問：「昨年会いましたよね？今はクラスタのサイズはどのくらいのサイズですか？」「メインクラスタは9データノード」\nOpen QA with Shay 思い出せるものだけ。。。（あとで追記します）\nElasticsearch 2.0の話 Pipeline Aggregationとか。 Spark Streaming対応してる？ まだ検討中 elasticsearch-hadoopってどんなもの？HDFSにインデックス作ったりするの？ いえ、Hadoopの入出力先としてelasticsearchが使える感じ 個人的にAWSのCloudSearchとAWSでElasticsearchはどっちがいい？ 時系列データはCloudSearchだと難しいだろうし、AWS上ならfound.noがあるよ！ PostgreSQLみたいに信頼性の高いデータストアを目指してる（まだ、プライマリデータストアには使わないで） その他、感想などのブログ Elasticsearch勉強会でLTしてきました | Intimate Merger Engineer Blog 『第11回elasticsearch勉強会』のまとめ #elasticsearchjp \u0008* [Elasticsearch] 第11回 Elasticsearch 勉強会へ参加してきた - 雑文発散(2015-07-28) 第11回 Elasticsearch 勉強会に参加したら英語力に危機感を覚えて最高だった まとめ 今回はShayが来日したので特別バージョンでした。 もっと英語を翻訳するサポートしないとですね、反省してます。。。ぜんぜん流暢じゃないしw\n次回は9月に開催予定ですが、12月にまたShayが再度来日する予定です。 丸1日のイベントを検討中で、Shay以外にも開発者が来日すると思います。 どんな話が聞きたい、どんな人と話をしたいなどあれば、コメントいただければ（対応できるかは。。。）\n勉強会のスピーカーは随時募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1438321313,"dir":"post/2015/","id":"73b8194ad8fce0cabb01cd21d5e18500","lang":"ja","lastmod":1438321313,"permalink":"https://blog.johtani.info/blog/2015/07/31/11th-elasticsearch-jp/","publishdate":"2015-07-31T14:41:53+09:00","summary":"第11回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第11回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.7.1 and 1.6.2 released\n本日（7/29）、Lucene 4.10.4ベースのElasticsearch 1.7.1およびElasticsearch 1.6.2 のバグフィックス版をリリースしました。 これらのリリースは稀ですが、データの欠損が発生する重要なバグのフィックスを含んでいます。 すべてのユーザにアップグレードを推奨します。\nダウンロードおよびすべての変更については次のリンクをごらんください。\n最新安定版：Elasticsearch 1.7.1 1.6系バグフィックス：Elasticsearch 1.6.2 問題のバグ(#12487)は、 同時に複数のノードが故障またはリスタートをした場合の非常にまれな状況で、 シャードのすべてのコピーがクラスタから削除されてしまう状況を発生させます。 このバグは1.5.0から含まれています。\nこのリリースはまた、IPv4アドレスのCIDRマスクのバグのフィックス、 Shieldユーザがmore-like-this APIを利用できないバグのフィックスなど、 いくつかの変更も含んでいます（詳細は更新リストをごらんください）。\nぜひ、Elasticsearch 1.7.1をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1438173353,"dir":"post/2015/","id":"100c0a69bea7f02a0f4540ecaa37d0e3","lang":"ja","lastmod":1438173353,"permalink":"https://blog.johtani.info/blog/2015/07/29/elasticsearch-1-7-1-and-1-6-2-released-ja/","publishdate":"2015-07-29T21:35:53+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.1 and 1.6.2 released 本日（7/29）、Lucene 4.10.4ベースのE","tags":["elasticsearch"],"title":"Elasticsearch 1.7.1 および 1.6.2リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.7.0 and 1.6.1 released\n本日（7/16）、Lucene 4.10.4ベースのElasticsearch 1.7.0およびElasticsearch 1.6.1 のバグフィックス版をリリースしました。 これらのリリースはセキュリティフィックスを含んでおり、すべてのユーザにアップグレードを推奨します。\nダウンロードおよびすべての変更については次のリンクをごらんください。\n最新安定版：Elasticsearch 1.7.0 1.6系バグフィックス：Elasticsearch 1.6.1 1.7.0が1.x系の最後のリリースとなります。 今後の新機能については、Elasticsearch 2.0以降で取り込まれる予定です。\nElasticsearch 1.7.0は小さなリリースですが、2つの重要なセキュリティフィックスと クラスタの安定化とリカバリに関する2つの重要な機能を含んでいます。\nセキュリティフィックス シャードアロケーションを遅らせる インデックスリカバリの優先度 セキュリティフィックス Elasticsearch 1.6.1 と 1.7.0 は次の2つのセキュリティフィックスを含んでいます。\nリモートコード実行の脆弱性 Elasticsearch 1.6.1より前のバージョンには、transport protocol（ノードとJavaクライアント間での通信に利用）により、 リモートでコードが実行される脆弱性があります。 これは、CVE-2015-3253でのGroovyに関係しています。\nGroovyのダイナミックスクリプティングがオフでも脆弱性があります。 アップグレードをしないユーザは、transport protocol のポート（デフォルトで9300）信頼したエージェントからのみの アクセスに限定することで、脆弱性から保護できます。\nこの問題をCVE-2015-5377としました。\nディレクトリ探索の脆弱性 Elasticsearch 1.0.0から1.6.0までのバージョンで、ElasticsearchのJVMプロセスによって読み込みが可能なファイルを 取得することができるディレクトリ探索攻撃の脆弱性があります。 アップグレードをしないユーザは、信頼できない場所からのSnapshot-Restore APIの呼び出しを防ぐためにファイアウォール、リバースプロキシやShieldを使用することができます。\nこの問題をCVE-2015-5531としました。\nシャードアロケーションを遅らせる Elasticsearch 1.6.0でSynced Flushingが導入されました。 これは、ノードのリスタート時に、更新が止まっているシャードのリカバリを劇的にスピードアップします。 しかし、この変更は、シャードの配置を無効にしている環境でのみうまく実行されます。 ノードが一時的にクラスタから外れている場合や予期せぬリブートの場合には役に立ちません。\nこのシナリオとは次のようなものです。\nノードの想定外のシャットダウン マスタがたのノードにシャードを再配置 各シャードが新しい場所にネットワーク越しにコピー その間に、外れていたノードが再度クラスタにジョイン マスタは新しいノードにシャードを再配置。新しいノードに存在する既存のシャードが全く再利用されない可能性がある ノードレベルとクラスタレベルの両方の並列的なリカバリを抑制しても、 この\u0026quot;シャードシャッフル\u0026quot;がクラスタに対して負荷をかける可能性があります。 これは、外れたノードが再度ジョインするのを単に待つことにより防げるかもしれません。\n待ちましょう！ Elasticsearch 1.7.0はindex.unassigned.node_left.delayed_timeout設定を追加しました。デフォルトでは1分です。 これは、ノードがクラスタから外れたとき、ほかのノードにこれらのノードを再配置するまでマスタが1分待つということです。 ノードがこの1分の間に復帰した場合、マスタはローカルにあるシャードを再度配置します。\nなぜ1分？ ノードがシャットダウンし、リスタートし、復帰するために十分な時間が1分だからです。 しかし、ノードが復帰しない場合にはまだ再配置が発生することを意味します。 デフォルト値を決定するのは難しいです。 この設定をどのくらいに減らすか、増やすかを決める必要があるかもしれません。\nこのデフォルト値は、config/elasticsearch.ymlファイルに設定できますが、インデックス設定の更新APIを使って設定することも可能です。\nこのデフォルトに関する知見をぜひフィードバックしてください。\nインデックスリカバリの優先度 1.7.0の2つ目の重要な機構はフルクラスタリスタートのような後に、 どの順番でインデックスをリカバリするかという優先度をつけることができるという機能です。\n電源故障による、ロギング用のクラスタのダウンを想像してください。 クラスタが普及した場合、500個のインデックスをリカバリするような場合、499個のインデックスのデータは古く、 500番目のインデックスが重要です。 もっとも最近作成されたインデックスがリカバリされるまで、インデキシングを待つというようなことはできません。\nこれまでは、インデックスはランダムな順序でリカバリされ、重要なインデックスがリカバリされるまで待つしかありませんでした。 1.7.0では、インデックスは優先度の順番でリカバリされます。 この優先度は次のプロパティで指定できます。\nindex.priority設定（大きな値が優先度が高い） インデックス作成日（新しいものが優先度が高い） インデックス名 既存のクラスタについて特に変更せずとも、最も最近作成されたインデックスが古いものよりも復旧されます。 古いインデックスの優先度を上げるためには、index.priority設定に0よりも大きな値を設定します。\nPUT important_index/_settings { \u0026#34;index.priority\u0026#34;: 5 } この設定は、存在するインデックスに対して更新できます。リカバリ中にもです。\nまとめ ぜひ、Elasticsearch 1.7.0をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1437546817,"dir":"post/2015/","id":"809925e891b0456231c374b09cbe4a90","lang":"ja","lastmod":1437546817,"permalink":"https://blog.johtani.info/blog/2015/07/22/elasticsearch-1-7-0-and-1-6-1-released-ja/","publishdate":"2015-07-22T15:33:37+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.0 and 1.6.1 released 本日（7/16）、Lucene 4.10.4ベースのE","tags":["elasticsearch"],"title":"Elasticsearch 1.7.0 および 1.6.1リリース（日本語訳）"},{"contents":"東京以外での勉強会の第2弾として、関西で勉強会を開催してきました。\nElasticsearch勉強会 in 大阪 Elasticsearch勉強会 in 京都 会場提供をしていただいた、Yahoo!大阪、はてなのみなさん、ご協力ありがとうございました！\nここからはいつものメモです。 ちなみに、大阪の勉強会に、@takuya_aさんと@5kozawaさんの両名にお越しいただき話をしていただきました。 なので、勉強会の内容はほぼ同一になります。\nIntroduction Elastic @johtani スライド：Introduction Elasticsearch\n初めての関西での勉強会ということで、ElasticsearchのOSSおよび商用プラグインの紹介をしてきました。 もちろん、Kibanaのデモもちょっとだけ。スプラトゥーンに関するデータをKibanaでちょっとだけ。 突貫でデータをかき集めたのでもう少し改良しないとですが。\nElasticsearch での類似文書検索と More Like This API 詳解 / 株式会社はてな　id:takuya-a スライド：Elasticsearch での類似文書検索と More Like This Query API 詳解\nElasticsearchのMore Like Thisのソースコードリーディングみたいな感じで、 内部でどうやって処理されているかの説明を詳しくしてもらいました。\n前のはてなエンジニアセミナーで話をされていた検索精度の件に絡んだ内容になっているかと。 （大阪で発表してもらった時より京都での発表が分かりやすくなってました。1日で改善されたのすごい！） MoreLikeThisだとチューニングつらいので、自分で作るためにTermVectorAPIでやってみたという流れかと。\n以下は発表後に出てきた質問のいくつかです。\nQ:MoreLikeThisに対してTermVectorで柔軟にできる？ A:TermVectorのAPIで統計情報が取れるので、それを使うことでさらなるデータの更新ができる。\nQ:TFとかの統計情報が必要なら、すべてインデックスをしたあとじゃないとちゃんとした値はとれないのでは？ A:TermVectorで取得したものをどうやって使うか\nQ:TermVectorAPi\u0026hellip;聞こえなかった A:。。。\nElasticsearchを用いたはてなブックマークのトピック生成 / 株式会社はてな　id:skozawa スライド：Elasticsearchを用いたはてなブックマークのトピック生成\nSignificant Terms Aggregationを活用してる話。 トピックページの生成のために、Significant Terms Aggregationをどうやって利用しているかなどのお話でした。\nトピックの集合の重複だったり、精度の判定方法とかいろいろ詳しく説明していただきました。\nQ:2011年と12年で11年の方が多いのは？ A:ブックマークの件数に比例\nQ:Significant terms aggsのsizeはいくつをつかってますか？ A:20を指定してます。\nQ:Yahooとかニュースをストップワードとしてますが、Yahoo自体のニュースに関してはどーしてるんですか？ A:本文とタイトルから別々に作っていて、タイトルからは弾かれますが、本文から作った時に出てきます。\nはてなブックマークにおける Elasticsearch の運用まわりの話 / 株式会社はてな　id:hagihala スライド：未定（おそらく公開される）\n体調が回復しきっていない中の発表ありがとうございました。 大幅に修正された資料が出てくるかなと。（ツイートできない数値がちらほらあったので）\nElasticsearchのクラスタの構成、どういった点で困ってたのでどういう調べ方をしたのか、どういった対処をしたのか。 どのあたりが次の課題かなどの話もありました。\n感想・反省点など 大阪、京都ともに30名弱の方の参加をしていただきました。ありがとうございました。 反省点としては、ハッシュタグを告知し忘れてました。。。\n勉強会はやはり、東京が異常に活発で、大阪や京都はまだそれほどでもないのかなぁとも。 大阪はエンジニアの人や会社も多い気がするんですが。私の告知の仕方もあるかもなぁと。 次回があれば、大阪での事例も聞きたいので、スピーカーをもっと探さないとなと。\n関連ブログなど 見つけたら、リンク追加していきます。\nElasticsearch勉強会 in 大阪/京都で発表しました \u0008* 「Elasticsearch での類似文書検索と More Like This Query API 詳解」というタイトルで発表しました その他（余談） 大阪のYahoo!さんは立地条件（梅田のすぐそば）がよく、\n夜景も綺麗でした。大阪城とかも見えてました。（夜景じゃないけど。。。）\n京都は祇園祭の真っ最中。\n水曜日はお休みをいただいて、観光してました。ちょっと日焼けが。。。 おかげで、リフレッシュできました。三十三間堂とか良かった:)\nあまり、関西に縁がない（大阪15年ぶり、京都10年ぶり）ので、 もっとユーザが増えて勉強会の機運が高まると嬉しいなと。:)\n","date":1437010857,"dir":"post/2015/","id":"dd6c32a722dc815273cd9ed8cd6c671b","lang":"ja","lastmod":1437010857,"permalink":"https://blog.johtani.info/blog/2015/07/16/kansai-1st-elasticsearch-jp/","publishdate":"2015-07-16T10:40:57+09:00","summary":"東京以外での勉強会の第2弾として、関西で勉強会を開催してきました。 Elasticsearch勉強会 in 大阪 Elasticsearch勉強会 in 京","tags":["勉強会","elasticsearch"],"title":"大阪と京都でElasticsearch勉強会を開催しました。 #elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：The Great Mapping Refactoring\nElasticsearchのユーザの悩みの最も大きなものの一つは、 タイプとフィールドのマッピングに関する多義性です。 この多義性は、インデックス時の例外やクエリ時の例外、 正しくない結果、リクエストからリクエストへ変化する結果、 また、インデックスの故障やデータのロスを結果として引き起こします。\nElasticsearchをより強固で予測可能な振る舞いをするようにする作業において、 フィールドやタイプのマッピングをより厳格でより信頼性を高くするかといったことに 多くの変更を費やしました。 多くのケースで、Elasticsearch v2.0で新しいインデックスを作るときにのみ、 新しいルールを強制し、これまでのインデックスに関しては後方互換性を保つようにします。\nしかし、幾つかのケースでは、先ほど説明したようなフィールドマッピングの コンフリクトなどが存在するため、それらを利用できないです。\nコンフリクトしたフィールドのマッピングをもつインデックスはElasticsearch v2.0にはアップグレードできません。\nもし、これらのインデックスのデータが必要ない場合は、インデックスを消せばいいです。 そうでない場合はマッピングを正しくして再度インデックスする必要があるでしょう。\nマッピングを正しく変更することは、私たちが簡単に決めることではありません。 ここからは、現在ある問題点と、私たちがどのように実装して解決したかについて説明します。\nフィールドマッピングのコンフリクト あいまいなフィールドのルックアップ タイプのメタフィールド アナライザ設定 index_nameとpath 同期的なマッピングの更新 マッピングの削除 2.0のための準備 フィールドマッピングのコンフリクト これまで、わたしたちはドキュメントのタイプは「データベースのテーブルのようなもの」と説明していました。 タイプの目的を説明する簡単な方法だったからです。 しかし、残念なことにこれは、真実ではありません。 「同じ」インデックスの「異なるタイプ」にある同じ名前のフィールドは、 内部的に、Luceneのフィールド名が同じものになります。\nもしerrorフィールドとして、ドキュメントタイプがapacheのものには数値（integer）を、 ドキュメントタイプがnginxのものには文字列（string）を割り当てた場合、 Elasticsearchは同じLuceneのフィールドに数値と文字列のデータをもつことになります。 このフィールドに対して、検索やaggregationを行う場合、おかしな結果を受け取るか、例外が帰ってくるか、 インデックスが破損することになります。\nこの問題を解決するために、まず、ドキュメントタイプの名前をフィールドの名前の前に追加することを考えました。 各フィールドは完全に別のものとなります。 このアプローチの利点はドキュメントタイプが実際のテーブルのようになることです。\nしかし、この方法には多くの欠点があります。\nフィールドは常に、他のタイプとは異なるものであると区別するためもしくは、複数のタイプに同じフィールドのクエリのためにワイルドカードをつけた場合、 ドキュメントタイプを前につける必要があります。 複数のドキュメントタイプに対して同じフィールド名で検索する場合、クエリを個別に発行しなければならなく遅くなります。 多くの検索で、既存の多くのクエリを壊してしまうために、単純なmatchやtermクエリの代わりに、multi-fieldクエリを使う必要があります。 圧縮の効率の悪さから、ヒープ利用量、ディスク使用量、I/Oなどが、増加します。 複数のドキュメントタイプに対するaggregationは、global ordinalの利点を利用できなくなるために、遅くなり、メモリの使用量も増えます。 解決方法 最終的に、同じインデックスの同じ名前を持つ全てのフィールドは、同じマッピングを持つ必要があるというルールを採用することに決めました。 ただ、copy_toやenabledのようなパラメータはタイプごとに指定することができるようになっています。 これにより、データの破損、クエリ時の例外そして、おかしな結果が発生する問題を防ぎます。 クエリとaggregationは現在でも高速なままで、圧縮率を最大化し、ヒープ使用量やディスク使用率の低減させます。\nこの解決方法の欠点は、個別のテーブルとしてタイプを扱いたいユーザが彼らの考え方を変える必要があるということです。 これは、思ったよりも問題ではありません。 実際には、多くのフィールド名はデータの明確なタイプを表現しています。 created_dateは常に、日付ですし、number_of_hitsフィールドはいつも数値です。 フィールドマッピングがコンフリクトしているユーザはデータを失ったり、おかしなデータを受け取ったり、データを欠損させています。 ベストプラクティスにユーザが従っているかどうかによらず、インデックス時に正しい振る舞いを強制することが現在の違いです。\nユーザの多くがコンフリクトしていないフィールドマッピングをもっていれば、 コンフリクトが起きた場合、技術がこれらのシチュエーションを扱うことが可能になると思いませんか？ そこにはいくつかの解決方法があります。\nタイプの代わりにインデックスを別々に 最も簡単な解決方法です。インデックスを別々のインデックスとし、実際のデータベーステーブルのようにします。 インデックスをまたいだ検索はタイプをまたいだ検索のように動作しますし、 ソートやaggregationも同じデータタイプへのクエリのように動作します。これまでと同じ制限です。\nコンフリクトしたフィールドの名前の変更 コンフリクトがごくわずかな場合、（Logstashやアプリケーションで使っているものも一緒に）よりわかりやすいフィールド名に変更することで解決できます。 例えば、2つのerrorフィールドがあった場合に、error_codeとerror_messageに変更します。\ncopy_toもしくはmulti-fieldsを利用 異なるドキュメントタイプのフィールドは別々のcopy_toを設定できます。 元のerrorフィールドはindexの設定にnoが設定してあり、全てのドキュメントタイプで無効化されていますが、 特定のタイプだけ、errorフィールドの値を数値のerror_codeフィールドにコピーすることができます。\nPUT my_index/_mapping/mapping_one { \u0026#34;properties\u0026#34;: { \u0026#34;error\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;no\u0026#34;, \u0026#34;copy_to\u0026#34;: \u0026#34;error_code\u0026#34; }, \u0026#34;error_code\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;integer\u0026#34; } } } 他のタイプでは文字列のerror_messageにコピーします。\nPUT my_index/_mapping/mapping_two { \u0026#34;properties\u0026#34;: { \u0026#34;error\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;no\u0026#34;, \u0026#34;copy_to\u0026#34;: \u0026#34;error_message\u0026#34; }, \u0026#34;error_message\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } 同様の解決方法としてmulti-fieldも使えます。\n各データタイプに対してネストしたフィールドに ときどき、Elasticsearchに送ったドキュメントやドキュメントがもっているフィールドを制御できない場合があります。 部分的なコンフリクトに加え、闇雲に、ユーザが送ってきたフィールドを受け入れると、マッピングが肥大化します。 タイムスタンプやIPアドレスをフィールド名に使うようなドキュメントがあると考えてください。\nnested フィールドにすることで、str_val、int_val、date_valというような各データタイプを利用できます。\nこのアプローチによって、次のドキュメントは\n{ \u0026#34;message\u0026#34;: \u0026#34;some string\u0026#34;, \u0026#34;count\u0026#34;: 1, \u0026#34;date\u0026#34;: \u0026#34;2015-06-01\u0026#34; } アプリケーションによって、次のようにフォーマットしなおす必要があります。\n{ \u0026#34;data\u0026#34;: [ {\u0026#34;key\u0026#34;: \u0026#34;message\u0026#34;, \u0026#34;str_val\u0026#34;: \u0026#34;some_string\u0026#34; }, {\u0026#34;key\u0026#34;: \u0026#34;count\u0026#34;, \u0026#34;int_val\u0026#34;: 1 }, {\u0026#34;key\u0026#34;: \u0026#34;date\u0026#34;, \u0026#34;date_val\u0026#34;: \u0026#34;2015-06-01\u0026#34; } ] } この解決方法は、アプリケーションサイドでより多くの作業が必要ですが、コンフリクトの問題とマッピングの肥大化の問題を同時に解決します。\nあいまいなフィールドのルックアップ 現在、フィールドの指定には\u0026quot;short name\u0026quot;、フルパス、ドキュメントタイプを前につけたフルパスが利用できます。 これらのオプションがあいまいさをもたらしています。 サンプルとして次のマッピングをご覧ください。\n{ \u0026#34;mappings\u0026#34;: { \u0026#34;user\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;title\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;blog\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;title\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;user\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;object\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;title\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } } } } } titleはuser.title、blog.title、blog.user.titleのどれでしょう？ user.titleはuser.titleまたはblog.user.titleのどちらでしょう？ 答えは「場合によります。」です。Elasticsearchが最初に見つけたものになります。 フィールドはリクエストごとに変わるため、各ノードでマッピングがどのようにシリアライズされたかに依存します。\n2.0では、フィールドを指定する時に、ドキュメントタイプを除いたフルパス名を使用するべきでしょう。\nuser.titleは、blogタイプのuser.titleを意味します。 titleは、userとblogタイプのtitleフィールドを意味します。 *titleはuser.titleとtitleフィールドの両方にマッチします。 userタイプのtitleフィールドとblogタイプのtitleの違いはどのように指定するのでしょう？\n指定できません。フィールドマッピングのコンフリクトで説明した変更により、 titleフィールドは両方のタイプで同じフィールドになります。 本質的にtitleと呼ばれる1つのフィールドになります。\nuser.やblog.のようなタイプのプレフィックスはタイプを指定することによるフィルタリングで効果があります。 クエリのblog.titleフィールドはblogタイプのドキュメントだけを検索し、userタイプのドキュメントを検索しません。 このシンタックスは誤解を招きやすいです。なぜなら、いつでも動作するわけではないからです。 aggregationやsuggestionはすべてのタイプに関する結果を含みます。 この利用のため、上記の例のあいまいさがあるので、タイプのプレフィックスはサポートしません。\n重要 short nameやタイププレフィックスを利用したpercolatorは更新する必要があります。\nタイプのメタフィールド すべてのタイプはメタフィールドを持っています。_id、_index、_routing、_parent、_timestampなどです。 これらのほとんどはindex、store、pathのような幾つかの設定をサポートしています。 これらの設定について次のようにシンプルにしました。\n_idと_typeは変更不可 _indexは、ドキュメントのもつインデックスを保存するためにenabled _routingはrequiredのみを指定 _sizeはenabledのみ _timestampはデフォルトで保存される _boostと_analyzerは廃止。古いインデックスのものは無視される ドキュメントのフィールドから_idと_routingと_timestampの値を抽出することができました。 この機能は廃止されます。これは、ドキュメントのパースとコンフリクトを起こすためです。 代わりに、これらの値はURLもしくはquery stringで指定可能です。\n_boostと_analyzerフィールドは例外で、すでにあるメタフィールドの設定は古いインデックスのものが採用されます。\nアナライザ設定 これまで、indexとsearchのアナライザがインデックス、タイプ、フィールド、ドキュメント（_analyzerフィールドで）の それぞれのレベルで指定可能でした。 同じフィールドに対して異なるanalysis chainの組み合わせができることにより、おかしな関連度を引き起こしていました。 フィールドマッピングのコンフリクトを解消することに加え、アナライザの設定も簡略化します。\nAnalyzedな文字列フィールドは、analyzer設定とsearch_analyzer設定（analyzer設定の値をデフォルトとする）を指定できます。index_analyzer設定はanalyzerとなります。 複数のタイプで同じ名前のフィールドがある場合、フィールドはすべて、同じアナライザの設定を持たなければなりません。 タイプレベルのデフォルト設定のanalyzer、index_analyzer、search_analyzer設定は廃止されます。 デフォルトアナライザはインデックスごとにインデックスのanalysis設定で設定します。これらはdefaultもしくはdefault_searchという名前で設定します。 ドキュメントごとの_analyzerフィールドはサポートしません。既存のインデックスのものは無視されます。 index_nameとpath index_nameとpath設定は（Elasticsearch v1.0.0から利用できる）copy_toによって置き換わりました。 既存のインデックスについてはこれらは機能しますが、新しいインデックスでは指定できません。\n同期的なマッピングの更新 現在、これまで存在していないフィールドを含むドキュメントをインデキシングするとき、 フィールドはローカルのマッピングに追加され、それから、マスターに変更（新しいマッピングをすべてのシャードに適用する更新）が送信されていました。 同時に2つのシャードに同じフィールドを追加することができます。 また、そのとき、異なる2つのマッピングがある可能性があります。 1つはdoubleでもう1つはlongだったり、stringとdateだったりと。\nこのような場合、マスターに最初に届いたマッピングが採用されます。 しかし、「負けた」マッピングをもつシャードでは、すでに異なるデータのタイプを利用しているため、 これを利用し続けます。 そのご、ノードをリスタートしたときに、シャードが別のノードに移動し、マスターにあるマッピングを適用します。 このとき、インデックスが破損したりデータを失ったりします。\nこれを防ぐために、シャードはインデキシングを続ける前に、新しいマッピングがマスターによって採用されるかどうかを待つようになりました。 これはすべてのマッピングが安全に更新されます。 新しいフィールドをもっているドキュメントをインデキシングすると、前よりも処理が遅くなるでしょう。 受け入れられることを待つ必要があるためです。 しかし、クラスタの状態の更新処理のスピードが次の2つの新しい機能によって大きく改善されています。\nクラスタ状態の差分：可能であれば、クラスタの状態の変更はクラスタ状態全体の変更ではなく、部分的なものとする。 シャードへのリクエストの非同期化：シャードアロケーション処理中に、マスタノードは、 割り当てられていないシャードのコピーの日付が最新のものを持っているかを見つけるために、リクエストをデータノードに対して送信します。 ここで、クラスタ状態を変更する呼び出しがブロッキングで行われていました。v1.6.0から、このリクエストはバックグラウンドで非同期で実行されます。 これにより、マッピング更新のようなペンディングタスクをより早く処理できるようになります。 マッピングの削除 （そのタイプのドキュメントがある場合）タイプマッピングを削除できないようにします。 マッピングを削除した後に、削除されたフィールドの情報は、Luceneレベルでは存在し続け、 もし、後から同じ名前のフィールドが追加されたときにインデックスの破損を引き起こします。 そのようなマッピングは残しておくか、新しいインデックスに再インデックスすることができます。\n2.0のための準備 マッピングがコンフリクトしているかどうかを決めることは、手動で行うには慎重に行う必要があります。 私たちは、Elasticsearch Migration Pluginを提供します。 これは、2.0で非推奨になったり廃止された機能を利用しているかどうかを見つけるために役に立つでしょう。\nもし、コンフリクトしたマッピングを持っている場合、 正しいマッピングを持つ新しいインデックスにデータを再インデックスするか、 必要ないなら削除します。 これらのコンフリクトを解決しない限り2.0にはアップグレードできないでしょう。\n","date":1436346691,"dir":"post/2015/","id":"ee4ff9e4e8a1948795e26af2f3f8a30f","lang":"ja","lastmod":1436346691,"permalink":"https://blog.johtani.info/blog/2015/07/08/great-mapping-refactoring-ja/","publishdate":"2015-07-08T18:11:31+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：The Great Mapping Refactoring Elasticsearchのユーザの悩みの最も大きなものの一つは、 タイプと","tags":["elasticsearch"],"title":"Mappingのすばらしいリファクタリング（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 2.0.0.beta1 coming soon!\nElasticsearch 2.0.0.beta1のリリースの準備をしています。 これは、Lucene 5.2.1に含まれる多くの改善が利用できるようになります。 このリリースに関するいくつかの機能は次のようなものです。\nPipeline Aggregations 差分や移動平均、他のAggregationsの結果に対する series arithmeticのようなaggregationが利用可能になります。 この機能は、これまでは、クライアントサイドで実行する必要がありました。 しかし、この計算をより強力な解析クエリを構築してElasticsearchで 実行することができるようになります。 クライアントのコードをより簡潔にすることができます。 これにより、予測解析や異常検知のようなことができるようになります。\nQuery/Filter merging Filterはなくなります。全てのフィルタは、クエリになります。 クエリコンテキストで利用されると、効率的に関連度スコアを計算し、 フィルタコンテキストで利用されると、単に、 マッチしていないドキュメントを除外する（今のフィルタのようなもの）だけです この変更は、クエリ実行が自動的に、より効率的な順番で実行されるように 最適化されることを意味します。 例えば、フレーズやgeoクエリのような遅いクエリは まず、近似フェーズを実行し、それから、より遅い実際のフェーズが 結果に対して行われます。 フィルタコンテキストにおいて、頻繁に利用される条件は自動的にキャッシュされます。\nConfigurable store compression index.codec設定により、高速化のためのLZ4圧縮（default）か インデックスサイズを小さくするためのDEFLATE（best_compression）を 選択できます。これは、ロギングでとくに役に立ちます。 これにより、古いインデックスオプティマイズする前にbest_compressionに 変更できます。\nこれらに関するブログ記事がすぐに公開されるでしょう。\nPerformance and resilience 以降では、新しいメジャーリリースに関して簡単に紹介します。 2.0の変更の多くは内部の機能に関するものであり、 直接ユーザに関連するわけではないからです。\n新しいメジャーバージョンのテーマは、パフォーマンス、安定性、 堅牢性、予測可能性、そして使い勝手の良さです。\n物事が予測した通りに動作する 何か問題があった場合に、Elasticsearchから役立つフィードバックがある ローレベルの設定を扱う必要はなく、Elasticsearchが良い設定を決定する これらに加え、データがより安全に これらの目標は完全ではありません。 まだ、多くの改善があります。しかし、2.xブランチで、 すでに500コミットを超える大きな改善が実施されています。\non-diskの doc valuesをデフォルトで利用（これまではfielddata）。 ヒープ使用量を減らして、スケーラビリティを向上 セグメントマージ処理中のメモリ使用量の削減 normsの圧縮率の改善。ヒープスペースを利用している大きな処理のひとつだったため。 全てのリクエストの後に、transaction logをfsyncすることで、デフォルトで耐久性を向上 全てのファイル変更をアトミックに（部分的なファイルの書き出しはなし） マージを自動で制限 フレーズクエリやスパンクエリを高速化 フィルタキャッシュをより効率化するための圧縮されたビットセット クラスタ状態の差分更新 構造化されたJSON形式の例外 よりきめ細かいLuceneのメモリレポート デフォルトではlocalhostにのみバインド。開発のノードが他のクラスタにジョインするのを防ぐ parent/childのクエリ実行最適化のためにリライト Java Security Managerで必要最小限なパーミッションで実行 全てのコアなプラグインをelasticsearchリポジトリに移行し、Elasticsearchのバージョンに同期してリリースされる予定 アップグレード前に メジャーバージョンのアップグレードは問題のあるものを一掃する機会を与えてくれます。 できる限り、これらの変更をアップグレードするために、簡単な方法を提供しようとしています。 しかし、Elasticsearch 2.0にアップグレードする前に、必要な処理が2つあります。\n1つ目は、フィールドとタイプマッピングに関することです。 mapping APIは、現在、それほど厳密ではありません。 内蔵された保護機構を提供する代わりに、ユーザがベストプラクティスを知っていると信頼していました。 2.0では、mappingはより厳密で安全ですが、いくつかの変更では、後方互換性を保っていません。 詳細についてはThe Great Mapping Recatoringをごらんください。\n2つ目はElasticsearch 0.20以前のユーザに関する変更です。 これは、Lucene 3.xを使っています。 Elasticsearch 2.xはLucene 5をベースにしています。 Lucene 5はLucene 4.xによって作成されたインデックスの読み込みはサポートしていますが、 Lucene 3.xに関してはサポートしていません。\nElasticsearch 0.20以前のバージョンによって生成されたインデックスを持っている場合、 Elasticsearch 2.xのクラスタをスタートすることはできません。 これらの古いインデックスを削除するか、Elaticsearch 1.6.0以上に含まれている upgrade APIを使用してアップグレードする必要があります。\nupgrade APIの実行は2つのジョブを実行します。\n古いLuceneフォーマットのセグメントを最新のフォーマットで書き換えます Elasticsearch 2.xによって読み込めるようという印をインデックスに追加します 全てのセグメントを最新バージョンにアップグレードするのも良い案ですが、 アップグレード前に必要な処理を最小限に抑えることも可能です。 （Lucene 3.xのセグメントだけをアップグレード） その場合は、only_ancient_segmentsパラメータを指定します。\nElasticsearch Migration Plugin Elasticsearch 2.0 に移行する前に、インデックスがアップグレードが必要なのか、 ほかになにかするべきことがあるのかをチェックする助けになる Elasticsearch Migration Pluginをリリースしました。\nまず、プラグインをインストールします\n./bin/plugin -i elastic/elasticsearch-migration プラグインのインストール後はノードのリスタートは必要ありません。\n以下のリンクをブラウザで開きます。\nhttp://localhost:9200/_plugin/migration\n（localhost:9200はインストールしたホスト名に変更してください。）\nMigration pluginに関してバグやご意見がある場合は、GitHubのIssueにお願いします。\n","date":1436250300,"dir":"post/2015/","id":"f887e1aabf801e351bfb39698f208af1","lang":"ja","lastmod":1436250300,"permalink":"https://blog.johtani.info/blog/2015/07/07/elasticsearch-2-dot-0-0-dot-beta1-coming-soon-ja/","publishdate":"2015-07-07T15:25:00+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0.beta1 coming soon! Elasticsearch 2.0.0.beta1のリリースの準備をしています。","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0.beta1リリース間近（日本語訳）"},{"contents":"4ヶ月前に、Found joined our team at Elasticをアナウンスしました。 Foundの素晴らしいチームと一緒に仕事をしていますが、彼らによって、より素晴らしい hosted Elasticsearchを提供することになりました。\n私たちがともに密接に働くことにより、本日（2015/7/1）、 新しい2つのFoundを提供することになりました。 Found StandardはこれまでのFoundの機能に加え、さらに低価格を提供します。 Found Premiumは、SLAサポートと、ShieldやWatcherを将来Found上で提供します。\nFound Standard Foundは素晴らしいです。専用のElasticsearchクラスタ、簡単なスケール、 ビルトインのセキュリティそして、時間単位での課金などを持っています。 私たちは、hosted Elasticsearchを探している方に、 Foundが適したソリューションであると思っていますし、 すべての方に利用できて手頃な価格であるということを確信したいと思っています。\n本日（2015/07/01）からFoundの価格をかなり低価格にし、 月額50ドル以下でhosted Elasticsearchを簡単に試してもらえるようにしました。\n価格を下げることは正しい重要なステップですが、 Foundを利用している全ての人に、より良い経験を持っていただきたいと考えています。 低価格化と一緒に、free backupsとbuilt in SSDもFoundで提供を始めることになります。\nFoundの重要な特徴の一つが、高可用性のために、クラスタをいくつのデータセンターに持つかを 選択できることです。 データは重要です。これが正しい選択でユーザの助けになると考えています。 これにより、私たちの価格は、複数のデータセンターにより安価に配置することができます。\nまた、KibanaもElasticsearchのデータを可視化する素晴らしい方法だと考えています。 Kibana 4が最新バージョンですが、 これは、サーバサイドコンポーネントを持っています。 これは、サービスとしてこれを提供するために、追加の料金がかかることを意味します。 Foundチームが築いた素晴らしい基盤とKibanaチームの努力により、 hosted Elasticsearchクラスタで無料のKibana 4を7月15日より提供することになりました。\nFound Premium また、私たちは、オープンソースプロダクトに関してサブスクリプションを提供していますが、 Found Standardに対しても提供することになりました。 これが、Found Premiumです。\nフォーラムベースのサポートよりもSLAベースのサポートを望んでいる場合、 プロダクトを開発しているチームからのサポートを受けることができるオプションを 提供し始めました。 クリティカルなイベントを持っていたり、私たちのプロダクトに関する 問題を予測するためのベストなヘルプやガイダンス、アドバイスを探しているような場合にサポートします。\nさらに近い将来、サブスクリプションの一部として、Shield（Elasticasearchのセキュリティプラグイン）やWatcher（アラーティングプラグイン）が利用できるようになります。\n私たちのチームがともに働き、多くのことを可能にし、すばらしい仕事をユーザに提供したかを 将来も楽しみです。 私は非常に誇りに思っていますし、気に入っていただけたらと思っています。 ぜひ、7/15のWebnarに参加してくわしい話を聞いていただき、疑問を解消してください。\n","date":1436250000,"dir":"post/2015/","id":"9cc2a0b6c8be1405cddcdeb4487c59fe","lang":"ja","lastmod":1436250000,"permalink":"https://blog.johtani.info/blog/2015/07/07/we-just-made-found-more-awesome-ja/","publishdate":"2015-07-07T15:20:00+09:00","summary":"4ヶ月前に、Found joined our team at Elasticをアナウンスしました。 Foundの素晴らしいチームと一緒に仕事をしていますが、彼らによって、より","tags":["elasticsearch","found.no"],"title":"さらに進化したFound（日本語訳）"},{"contents":"JustTechTalk#02 形態素解析のあれやこれや@ジャストシステム\nに参加してきました。 ジャストシステムさんの形態素解析器JMATの話とKagome、Janome、Kuromoji.js、ssslaの開発者の パネルディスカッションでした。\nということで、いつものメモです。\nジャストシステムの形態素解析その２（機械学習編） JMATの話\n前回は辞書の話 今回は学習の話 教師あり/教師なし\nJMATは教師あり 教師なしは研究段階 ラティス構造を辞書ベースで構築して、コストの総和が最小の経路を求める\n連接、単語生成とか。 学習は3フェーズ\nベース、能動、部分アノテーション ベース 300万文のコーパスから1万文のみを利用（なぜ？今から説明） 64GBマシン買ってみたけど、複数実験するには追いつかない オンライン学習がメジャーでない時代に作り始めたので、つかってない CRF学習器を改善 結果として50万文くらいで精度が良くなる 辞書チームからNGがでて、方向転換 方向転換した結果が3つのフェーズらしい ピタジョブに採用？ 疑問 \u0008* JMATって、Webの検索の前処理とか分類とかに主に利用するのかな？\nATOKでもこのノウハウって利用してるんかな？ 辞書もあるらしいけど、辞書更新されると学習器のデータとかどーなるんだろ？ 形態素解析器の実装言語Talkについて kuromoji.jsの@takuya_aさん\nTyped Arrayサポートが高速にできてる理由でもあるらしい Kagomeの@ikawahaさん\nGoはいろいろないらしい Janomeの@moco_betaさん\nsssla（茶筌のRuby clone）\nなんで作ったの？\n形態素解析のライブラリ「解析部分」はNLPのHelloWorldだから なんで、その言語？\nPython 3系は文字列とバイト配列の扱いがすごく楽！ その言語で困った点は？\nGoだと、辞書を内包するのが大変 JSは苦労したところしかない（1hくらいしゃべれるぞ！）。基本的なデータ構造とかもない Pythonはパフォーマンスを考えないと Ruby（1.6だったので）もパフォーマンスが その言語を開発するときに必須のものは？\nGoはとくにない。エディタはどれでもOK browserifyが便利 \u0008* ほかの人たちの言語をdisってください * JSは論外。Pythonのコードフォーマッターが揺れるのが。。。Rubyはバージョンが。。。 * Goはブラウザで動かない。Pythonもブラウザで動かない。Rubyも(ry * ほかのは触ったことないので。。。 * Pythonは2.xか3.xか決めてくれ！\nなんで、Kuromojiベースなの？ Java読みやすいから。 MeCabとKuromojiの違いは？ 未知語の処理が結構違う 感想 きれいなロビーで良かったのですが、マイクがあると嬉しかったかもしれません。 前回の辞書の話も聞いてみたかったかも。\n","date":1436147341,"dir":"post/2015/","id":"18b7998a871950ebc36c415a53630477","lang":"ja","lastmod":1436147341,"permalink":"https://blog.johtani.info/blog/2015/07/06/attend-justsystem-techtalk-no2/","publishdate":"2015-07-06T10:49:01+09:00","summary":"JustTechTalk#02 形態素解析のあれやこれや@ジャストシステム に参加してきました。 ジャストシステムさんの形態素解析器JMATの話とKagome、Janome、","tags":["勉強会"],"title":"JustTechTalk#02 形態素解析のあれやこれや@ジャストシステムに参加しました。"},{"contents":"ひさびさに、勉強会メモ。 Hatena Engineer Seminar #5 @ Tokyoに当選したので行ってきました。\nいつもは近寄らないオシャレな街をドキドキしながら行ってきました。\nということで、簡単なメモです。\nはてなブックマーク全文検索の精度改善 id:takuya-a 問題：検索精度がよくない 京都で検索 →　「ポーランドの京都」「京都大学のまるまる教授」のようなもんがヒット 京都っぽいエントリが出て欲しい。 京都っぽい？？？ 問題点をブレイクダウン 課題 クエリ考えるの大変だよね 順序が新着順なのが辛い 適合率と再現率の両立 そして（ドラムロール）、できました！（さすが）\nアイデア：はてブのタグを利用する。 関連キーワードを抽出して、クエリ拡張する。\n関連キーワードとは？ タグ検索する 検索にヒットしたTerm Vectorsを取得 特徴語をTop25件取得 もっともスコアが高いタームを特徴語とする 英語のストップワードとかが問題点となってたり。 →Dynamic stop word listというのを利用して排除（IDF、RIDF、Gain） 今後の課題 再現率の向上 解析用のフィールド・辞書を追加（精度向上や解析ミスなど） トークに出てきた機能など トークに出てきたElasticsearchの機能については、こんなツイートをしてたので、参考にしてもらえれば。\nこれのkuromoji_stemmerを使ってるっぽい？ #hatenatech / elastic/elasticsearch-analysis-kuromoji - https://t.co/3F2sBYXLPH\n\u0026mdash; Jun Ohtani (@johtani) 2015, 6月 16 #hatenatech Term Vectors APIのドキュメントはこちら - https://t.co/HhBmTDr46i\n\u0026mdash; Jun Ohtani (@johtani) 2015, 6月 16 #hatenatech min_score - https://t.co/Sc0exzJRC1\n\u0026mdash; Jun Ohtani (@johtani) 2015, 6月 16 個人的な疑問 Q：クエリにヒットするタグがそもそもなかったら？\nはてなブックマークに基づく関連記事レコメンドエンジンの開発 id:skozawa 課題：一部のエントリに対して関連記事が出ない タグがない記事について関連エントリが出ない＝既存はタグを利用している 例：レシピで考える\n現行システム ユーザがつけたタグ情報を利用してMoreLikeThisで計算 新規システム 類似記事検索 特徴語の抽出 特徴語を分類 関連記事検索 関連記事をスコアリング 個人的な疑問 Q：毎回計算してるのかな？記事登録とかされたタイミングでやってるのかな？ Q：Termの精度などどうなんだろ？\n『BrandSafe はてな』のアドベリフィケーションのしくみ id:tarao BrandSafeはてな：とか。 広告の配信先をフィルタリング\n複数の素朴なフィルタの組み合わせ→AdaBoost\n個人的な疑問 Q：海外とかもいけるのかな？\nまとめと感想 ということで、簡単なメモでした。ピザごちそうさまでした！ 聞いてて少し思ったのは、データ量があるサイトだからうまくいく手法だというのもあるんだろうなというところでした。 あとは、クエリを暗に改善するのとは別に、サジェスト的に表示するのにも使えたりするかも？と思ってみたり。 できるかどうかはわからないですが。。。\nElasticsearchをいろいろと活用してもらってるのがわかって、楽しい勉強会でした。 もっともっといろんなところで宣伝してくださいw\n今日の勉強会を聞いて、俄然、京都・大阪でElasticsearch勉強会を開催したい気になってきました。 特に大阪に知り合いがいないので、だれか紹介してもらえると嬉しいです。 お待ちしてます。\n","date":1434468093,"dir":"post/2015/","id":"ddab6357ff522c0c956ebd7669e83454","lang":"ja","lastmod":1434468093,"permalink":"https://blog.johtani.info/blog/2015/06/17/attend-hatena-engineer-seminar-5/","publishdate":"2015-06-17T00:21:33+09:00","summary":"ひさびさに、勉強会メモ。 Hatena Engineer Seminar #5 @ Tokyoに当選したので行ってきました。 いつもは近寄らないオシャレな街をドキドキしながら行ってきました。 と","tags":["勉強会"],"title":"Hatena Engineer Seminar #5 @ Tokyoに参加しました。 #hatenatech"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.6.0 released\n本日（6/9）、Lucene 4.10.4ベースのElasticsearch 1.6.0をリリースしました。 このリリースはElasticsearchの最新の安定バージョンとなります。 また、素晴らしい新機能がいくつか追加されています。\nsynced flushによるリスタートの高速化 \u0008* シャード配置は保留中のタスクをブロックしない レスポンスボディのJSONのフィルタリング 共有ファイルシステムリポジトリに対するセキュリティフィックス 古いインデックスのためのUpgrade API Kibanaユーザのためのハイライトの強化 Windowsユーザのためのmlockall より詳細なスクリプト設定 すべての変更リストとダウンロードはこちらをごらんください。\nsynced flushによるリスタートの高速化 1.6.0より前のバージョンでは、メンテナンスやローリングアップグレード時の ノードの再起動で、必要であるかどうかに関わらず、多くの場合、 ノードのすべてのシャードのすべてのデータを再度コピーする必要がありました。 この新しいsynced flush機能により、 sync-flushされたインデックスに対して、既存のデータを再利用し、 より早くクラスタを正常な状態にすることができるようにします。\nここで、この変更以前にどのように動いていたかを説明します。 すでにあるレプリカシャードは、ノードがリスタートした後に、 プライマリから復元するときに、 最初のステップはプライマリにあるセグメントとレプリカにあるセグメントを 比較することです。そして、セグメントに違いがあった場合にコピーされます。 問題は、セグメントプライマリのセグメントのマージと レプリカのセグメントのマージが別々に起こっており、 各シャードのセグメントが完全に異なるが、 それらが同じデータを持っているという点です。\n新しいsynced-flush機能では、sync_idがプライマリと レプリカシャードに、シャードのコンテンツが同一であるという判別するために、 書き込まれます。これは、リカバリがセグメントの比較のステップを スキップできることを意味します。 リカバリのスピードを高速にします。\nsynced flushはアイドル状態のインデックスで自動的に実行されます。 直前の5分間でデータが登録、更新削除されていないインデックスに対してです。 これは、ロギングのユースケースで特に役に立ちます。 機能のインデックスはインデキシングがストップしたあとの5分で自動的に syncされるでしょう。\nノードのリスタートやクラスタのリスタートが必要で、 自動的に発生するsyncを待てない場合は次のようなことが可能です。\nインデキシングを停止（実行中のリクエストが停止するのも待つ） シャードのアロケーションを停止 synced-flushリクエストの発行 ノードのリスタート シャードのアロケーションの再開 クラスタの状態がグリーンになるまで待つ インデキシングの再開 NOTE: \u0026ldquo;シャードのアロケーションを停止\u0026quot;のステップが必要です。 これがない場合、Elasticsearchはノードの再起動が始まると、 異なるノードにシャードの再配置を始めます。 これは、新しいノードにシャードデータの全てをコピーする必要があります。\nドキュメントのインデキシング、更新、削除のあとに最初のフラッシュが 発生したときに、 シャードのsync_idが自動的に無効化されます。 詳細については#11336と#11179をごらんください。\nシャード配置は保留中のタスクをブロックしない 多数のノードやインデックスを持っているユーザは クラスタ全体のリスタートのあとのシャードのリカバリで、 長い間、リカバリが止まって見えることに気づいたかもしれません。 これらのリカバリが止まって見える間は、クラスタ設定の更新のような軽微なアクションでさえ、 例外が発生したり、その設定が反映されるまでに長時間かかるといったことが起きていました。 この問題の兆候は保留中のタスクのキューが大きくなることです。\nこれらの遅延の原因はシャードの配置のプロセスにあります。 配置されるべきシャードのコピーを 持っているのがどのノードかを全てのデータノードに聞きます。 多くのシャードや遅いディスクを持ったデータノードは 反応するのに時間がかかります。 特に、シャードのリカバリがすでにI/Oを利用しているような時です。 このバージョン以前のものは、シャード情報のためのリクエストを 同期的に処理していました。 クラスタ状態の更新はアロケーションプロセスを続けるために 必要な情報を待っている間、ブロックされます。\n#11262での変更は この情報のためのリクエストを非同期にします。 クラスタ状態の更新はこのタスクによってブロックされません。 これは、保留中のタスクがより早く処理でき、 クラスタが変更に対してより早く反応できます。 処理中のshard infoリクエストの数は number_of_in_flight_fetchキーとしてcluster-health APIで取得できます。\nさらに、シャードがある理由で復旧に失敗すると、 クラスタは、シャードのリカバリが成功するまで、同じノードに対して シャードをアロケーションしないようにします。\nレスポンスボディのJSONのフィルタリング Elasticsearchは全ての情報を返します。 例えば、検索リクエストは_index、_type、_id、 _score、_sourceを返します。 しかし、全ての情報が必要でない場合があります。 また、これらのデータを遅いネットワークで転送することは 遅延の原因となります。\nユーザはこの検索メタデータを無効にするための特殊な設定を 行ったり、他のAPIのレスポンスのフォーマットを コントロールするための設定があります。 #10980の変更で、任意のレスポンスボディのJSONに対して、 必要な要素だけを取得する機能が追加されました。 filter_pathパラメータを使用します。\n例えば、検索リクエストからはtotal数と、各要素のhitsの配列を欲しい場合、 次のように指定します。\nGET _search?filter_path=hits.total,hits.hits nodes-info APIから各ノードのhttp_addressだけを取得したい場合は、 ノード名の部分にワイルドカード(*)を使用します。\nGET _nodes?filter_path=nodes.*.http_address 単一の*がJSON階層の1つの階層に対しての ワイルドカードとして機能します。 2つの**は複数階層に対してとなります。 複数のフィルタはカンマ区切りで指定可能です。 詳細についてResponse filteringをごらんください。\n共有ファイルシステムリポジトリに対するセキュリティフィックス 本リリースはsnapshot-restoreで使われる 共有ファイルシステムリポジトリに関するセキュリティ強化の変更が含まれます。 現在、Elasticsearchのユーザは、Elasticsearchプロセスによって書き込み可能 任意のディレクトリに.snapshotファイルを書き込むことができます。 #11284の変更で、リポジトリのために使用できるディレクトリを 強制的に指定できるようになりました。 適切なディレクトリがconfig/elasticsearch.yml設定ファイルの path.repoに指定される必要があります。\n次のように設定されたElasticsearchインスタンスはこのセキュリティ問題に対して影響を受けにくいです。\nrootではなくelasticsearchユーザとしてElasticsearchを実行 elasticsearchユーザがdataディレクトリに対してのみ 書き込み権限を持っていて、共有ファイルシステムリポジトリに対しても利用できる ファイアウォールやプロキシ、Shieldを使って、snapshot APIの実行を任意のユーザから実行されるのを防いでいる この問題をCVE-2015-4165としています。\n古いインデックスのためのUpgrade API Elasticsearch 2.0以降では、 Lucene 5ベースとなり、Lucene 3 （Elasticsearchのバージョンでは0.90以前） によって書き出されたセグメントを含んだインデックスを読み込むことが できなくなります。 これらの「古いインデックス」はLucene 4にアップグレードする必要があり、 2.0-compatibleとして印をつける必要があります。 そうしなければ、Elasticsearch 2.0に以降できないでしょう。\nupgrade APIは 、最新のLuceneフォーマットにインデックスにある全てのセグメントを アップグレードするためにすでに利用できます。 また、最新のフォーマットは性能向上やバグフィックスといった利点もあります。 さらに、2.0-compatibleとして古いインデックスをマークする設定も 書き込むことができます。 さらに、upgrade_only_ancient_segmentsオプションが Lucene 3のセグメントだけをアップグレードするために利用でき、 移行前の必要な処理を減らすことができます。\nKibanaユーザのためのハイライトの強化 KibanaユーザはElasticsearchのハイライトについて2つの点で問題を見つけていました。\nワイルドカードでフィールド名を指定した場合に、ハイライトに適さないフィールドも帰ってくる（日付や数値のフィールドなど） 古いインデックスが非常に大きなターム（\u0026gt; 32kB）を含んでいて、ハイライトが失敗する。 最近のバージョンでは、これらの大きなタームはインデックス時に除去される #11364の変更で これらの問題が修正されました。 ワイルドカードを利用したフィールド名では、stringフィールドのみを返し、非常に長いタームによる例外は無視するようになります。\nWindowsユーザのためのmlockall 速いGCはノードの安定性と性能について重要です。 小さなバイトのヒープでさえ、ディスクにスワップすることを許可してしまうと、GCに対して大きな影響が出てしまいます。 ですので、これらのコストは排除されるべきです。\nLinuxユーザはbootstrap.mloclall設定による恩恵を受けています。 これは、RAMにJVMのヒープを起動時にロックします。 #10887では、同様の機能をWindowsユーザにも提供します。\nより詳細なスクリプト設定 Scriptsはリクエストにインラインで指定できます。 .scriptsインデックスにインデックスもでき、config/ディレクトリ配下にファイルとして保存もできます。 これまでは、インラインかインデックスされたスクリプトの両方を同時に有効無効にすることが選択できましたが、 .scriptsインデックスをプロキシやShieldで保護することもできました。\n#10116で追加されたより詳細なスクリプトの設定で、インラインか、インデックスされたものか、ファイル化を個別に言語ごとに設定できるようになりました。 また、例えば、search APIではスクリプトを許可するが、update APIでは許可しないといったような設定も可能です。\n最後に ぜひ、Elasticsearch 1.6.0を試してみてください。 そして、感想をTwitter(@elastic)やWebフォーラムなどで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1433910662,"dir":"post/2015/","id":"55188a318c5998989255253e15ccc1f6","lang":"ja","lastmod":1433910662,"permalink":"https://blog.johtani.info/blog/2015/06/10/elasticsearch-1-6-0-released-ja/","publishdate":"2015-06-10T13:31:02+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.6.0 released 本日（6/9）、Lucene 4.10.4ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 1.6.0リリース（日本語訳）"},{"contents":"第10回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n今回も新規の方が結構いたような気がしました。 最終的に、124人がアプリでチェックインした形になりました。 直前にキャンセル待ちから繰り上がると来れない人がいますよねぇ。 多少キャパシティオーバーするくらいの人数で募集するのがいいのでしょうか。 あと、カードが2枚不明で。。。心あたりある人いないでしょうか？\nさて、いつもの通り簡単なメモです。\nElastic{ON}報告＋有償プラグインの紹介　Elastic Jun Ohtani @johtani スライド：elastic{ON}報告と商用プラグインの紹介\n少し時間が経ってしまいましたが、弊社初のカンファレンスelastic{ON}の紹介をしました。 約1300名の方に参加していただいたカンファレンスで、非常に盛り上がりました。 Microsoft、GitHubなど、いろいろな会社の方が話をしたり、弊社のエンジニアが濃い話をしたりと。 今回は、日本の方はいなかったですが、次回は日本からも参加してもらえると嬉しいです！\nあとは、5月に弊社にも日本の営業の人が入社したので、有償プラグインについて簡単ですが説明をしました。 プラグインなどに興味があるかたがいらっしゃいましたら、Twitterなどで連絡いただければと。 もちろん、弊社サイトからの問い合わせでも大丈夫です。\nカンファレンスの資料やビデオが弊社サイトで公開されています。 ぜひ一度見ていただければと。\nAWSで実現するelasticsearchの大規模運用 株式会社インティメート・マージャー　松田和樹さん　@mats116 スライド：第10回elasticsearch勉強会 公開用資料\nパブリックDMPのサービスの裏側でElasticsearchを利用しているというお話でした。 AWS Auto Scalingに詳しくないので、勉強しないといけないんですが、 リバランスがどのくらいの頻度で発生するのかはちょっと気になります。\nSSDを利用したり、doc valuesを利用したりと、性能を気にしながら利用されている点、負荷試験を行って検証されていたりと、 参考になる話でした。 今回はインフラ側の話に寄っていたので、今度はアプリ側でどんな使い方をしているかといった話を聞いてみたいですね！\nSpark in small or middle scale data processing with Elasticsearch　株式会社ビズリーチ 島本　多可子さん @chibochibo03 スライド：Spark in small or middle scale data processing with Elasticsearch\nScalaとSparkとElasticsearchで検索サービスを作っている話でした。 サービスのアーキテクチャの選別についての説明を順を追って説明していただきました。 失敗と言われていたアーキテクチャを見た時に、「あー、それは。。。」と思っていたら、 思った通りの改善案のアーキテクチャが出てきたので少しホッとしましたw\nJSONのクエリが辛いという話がありましたが、validate APIなどを利用してもらって、事前にチェックをしてもらうと 少しは改善できるかもなぁと。\nSparkをぼんやりとしかわかってないので、もう一度話を聴きたいなぁと思ったので、 押しかけて話を聴きたいと思います。\n話の中で出てきた自作のScalaのElasticsearchクライアントがHTTPのクライアントになった理由が知りたかったです。\nLT Elasticsearchのサジェスト機能を使った話　株式会社アイスタイル　渡邊 紘太朗さん @ktaro_w スライド：Elasticsearchのサジェスト機能を使った話\nぴったり5分でしたwまだ2年目なのにこんなにうまく話をしていただけるとは。。。\nGatling便利そうですね。サーバが1台しかないので、単一インデックスの方が性能が出るだろうなと。 Elasticsearchは1インデックスに対してデフォルトだと5シャードで、シャード単位でLuceneのインデックスが作成されます。 この話で行くと、18インデックスを作ると、かなりの数のファイルI/Oが発生するので、いろいろなインデックスに検索をすると キツいだろうなと。\nサジェストについての日本語の資料が少ないという事だったので、ブログを書いてもらえると嬉しいですw\nElasticsearchで作る形態素解析サーバ　株式会社エヌツーエスエム　菅谷信介さん スライド：Elasticsearchで作る形態素解析サーバ\nいつも発表ありがとうございます。私以外の最多発表者じゃないかという話でした。 今回はElasticsearchを形態素解析サーバにしてしまおうという話で、ちょっと面白い話でした。 Elasticsearch以外の場所で形態素解析したい場合には手軽に使えるかもしれないですし、Elasticsearchと同じ解析結果を別の場所で欲しい場合にも便利かも。\nextended analyze APIの紹介までしていただいて。。。\nちなみに、今は、extended analyze プラグインも指定したAttributeの情報だけ返せるようになってたり、 マルチバリューへの対応もしていたりします。 そのうち本家のanalyze APIに機能を取り込む予定です。（早くしないと）\n開発効率UP! Elasticsearch Client Tool 作ってみた　ナレッジワークス株式会社　木戸国彦さん @9215 スライド：開発効率アップ!Elasticsearch Client Tool 作ってみた\nHello Elasticsearch!にはお世話になっている人が多いんじゃないかなと。 今回はSublime Textのプラグインのお話でした。（すみません、Sublime Text使ってなくて。。。） AtomとかIntellijのプラグインもあるとうれしいなー\n変わり種プラグインの作り方　日本IBM　黒澤亮二さん スライド：変わり種プラグインの作り方\nElasticsearchの拡張ポイントの話と、簡単なプラグインの作り方と少しElasticsearch内部の話をしていただきました。 Foundの資料が上がってました。さすが。あそこのブログは面白い話が多いんですよね。 社内で実際に使われてる話とかも聞いてみたい！\nその他、感想などのブログ 第10回 Elasticsearch 勉強会へ参加してきた昨日の話 第10回elasticsearch勉強会 #elasticsearch #elasticsearchjp 第10回elasticsearch勉強会に行ってきました elasticsearch勉強会に登壇してきました まとめ 懇親会で24Fに移動していただくということで、少し手間をかけてしまいました、すみませんでした。 今回も初参加の方がそこそこいたんじゃないかなと。 あとは、AWSサミットがあるために上京してて参加しましたという方もいらっしゃいました。 大きなカンファレンスの期間の前後に行うとこんなメリットもあるんですね、今後の参考にしたいと思います。 次回は7/27を予定しています。CTOのShayが来日予定です！\nあと、東京以外の勉強会も検討しつつあります。興味のある方はコメントやTwitterで反応をいただけると嬉しいです。\nスピーカーは随時募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1433225196,"dir":"post/2015/","id":"75d9268739fe7787ac02d389ac605feb","lang":"ja","lastmod":1433225196,"permalink":"https://blog.johtani.info/blog/2015/06/02/10th-elasticsearch-jp/","publishdate":"2015-06-02T15:06:36+09:00","summary":"第10回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさ","tags":["elasticsearch","勉強会"],"title":"第10回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Reindex Elasticsearch With Logstash\nThanks David!\nマッピングを変更したり、インデックスの設定を変更したり、あるサーバから他のサーバや、 あるクラスタから他のクラスタ（例えば複数のデータセンターのような場合）にデータを再インデックスしたくなることがあるでしょう。\n後者のような場合はSnapshotやRestoreの機能を利用することもできますが、インデックスの設定を変更をしたい場合は その他の方法が必要になります。\nLogstash 1.5.0で、 elasticsearch inputとelasticsearch outputを使うことで、とても簡単に再インデックスができます。\nではやってみましょう。\n古いクラスタ elasticsearch 1.5.2 はすでにダウンロード済みとして、localhost:9200でoldという名前のクラスタを起動します。\nbin/elasticsearch --cluster.name=old クラスタにpersonという名前のインデックスが存在します。 これは、5シャードで、100万件のドキュメントを持っています。\n新しいクラスタ 次に新しいクラスタを起動します。 localhost:9201でnewという名前のクラスタを起動します。\nbin/elasticsearch --cluster.name=new こちらは、空です。\ncurl -XGET \u0026#34;http://localhost:9201/person\u0026#34; { \u0026#34;error\u0026#34;: \u0026#34;IndexMissingException[[person] missing]\u0026#34;, \u0026#34;status\u0026#34;: 404 } Logstashのインストール 次に、Logstash 1.5.0をダウンロードして、インストールします。\nwget http://download.elastic.co/logstash/logstash/logstash-1.5.0.tar.gz tar xzf logstash-1.5.0.tar.gz cd logstash-1.5.0 logstashの設定ファイルlogstash.confを次のように設定します。\ninput { # We read from the \u0026#34;old\u0026#34; cluster elasticsearch { hosts =\u0026gt; [ \u0026#34;localhost\u0026#34; ] port =\u0026gt; \u0026#34;9200\u0026#34; index =\u0026gt; \u0026#34;person\u0026#34; size =\u0026gt; 500 scroll =\u0026gt; \u0026#34;5m\u0026#34; docinfo =\u0026gt; true } } output { # We write to the \u0026#34;new\u0026#34; cluster elasticsearch { host =\u0026gt; \u0026#34;localhost\u0026#34; port =\u0026gt; \u0026#34;9201\u0026#34; protocol =\u0026gt; \u0026#34;http\u0026#34; index =\u0026gt; \u0026#34;%{[@metadata][_index]}\u0026#34; index_type =\u0026gt; \u0026#34;%{[@metadata][_type]}\u0026#34; document_id =\u0026gt; \u0026#34;%{[@metadata][_id]}\u0026#34; } # We print dots to see it in action stdout { codec =\u0026gt; \u0026#34;dots\u0026#34; } } 実行と修正 実行します。\nbin/logstash -f logstash.conf ドキュメントのチェックと修正 何が起きたでしょう？\ncurl -XGET \u0026#34;http://localhost:9200/person/person/AU1wqyQWZJKU8OibfxgH\u0026#34; { \u0026#34;_index\u0026#34;: \u0026#34;person\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;person\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;AU1wqyQWZJKU8OibfxgH\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;Tali Elyne\u0026#34;, \u0026#34;dateOfBirth\u0026#34;: \u0026#34;1955-05-03\u0026#34;, \u0026#34;gender\u0026#34;: \u0026#34;female\u0026#34;, \u0026#34;children\u0026#34;: 2, \u0026#34;marketing\u0026#34;: { \u0026#34;cars\u0026#34;: null, \u0026#34;shoes\u0026#34;: null, \u0026#34;toys\u0026#34;: null, \u0026#34;fashion\u0026#34;: null, \u0026#34;music\u0026#34;: null, \u0026#34;garden\u0026#34;: null, \u0026#34;electronic\u0026#34;: null, \u0026#34;hifi\u0026#34;: null, \u0026#34;food\u0026#34;: 846 }, \u0026#34;address\u0026#34;: { \u0026#34;country\u0026#34;: \u0026#34;Germany\u0026#34;, \u0026#34;zipcode\u0026#34;: \u0026#34;0099\u0026#34;, \u0026#34;city\u0026#34;: \u0026#34;Bonn\u0026#34;, \u0026#34;countrycode\u0026#34;: \u0026#34;DE\u0026#34;, \u0026#34;location\u0026#34;: [ 7.075943707068682, 50.72883500730124 ] } } } もう一方のクラスタと比較してみましょう。\ncurl -XGET \u0026#34;http://localhost:9201/person/person/AU1wqyQWZJKU8OibfxgH\u0026#34; { \u0026#34;_index\u0026#34;: \u0026#34;person\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;person\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;AU1wqyQWZJKU8OibfxgH\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;Tali Elyne\u0026#34;, \u0026#34;dateOfBirth\u0026#34;: \u0026#34;1955-05-03\u0026#34;, \u0026#34;gender\u0026#34;: \u0026#34;female\u0026#34;, \u0026#34;children\u0026#34;: 2, \u0026#34;marketing\u0026#34;: { \u0026#34;cars\u0026#34;: null, \u0026#34;shoes\u0026#34;: null, \u0026#34;toys\u0026#34;: null, \u0026#34;fashion\u0026#34;: null, \u0026#34;music\u0026#34;: null, \u0026#34;garden\u0026#34;: null, \u0026#34;electronic\u0026#34;: null, \u0026#34;hifi\u0026#34;: null, \u0026#34;food\u0026#34;: 846 }, \u0026#34;address\u0026#34;: { \u0026#34;country\u0026#34;: \u0026#34;Germany\u0026#34;, \u0026#34;zipcode\u0026#34;: \u0026#34;0099\u0026#34;, \u0026#34;city\u0026#34;: \u0026#34;Bonn\u0026#34;, \u0026#34;countrycode\u0026#34;: \u0026#34;DE\u0026#34;, \u0026#34;location\u0026#34;: [ 7.075943707068682, 50.72883500730124 ] }, \u0026#34;@version\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;@timestamp\u0026#34;: \u0026#34;2015-05-20T09:53:44.089Z\u0026#34; } } Logstashは@versionと@timestampフィールドを追加してしました。 これらを除去したいので、Mutate filter pluginのremove_fieldを使います。\nfilter { mutate { remove_field =\u0026gt; [ \u0026#34;@timestamp\u0026#34;, \u0026#34;@version\u0026#34; ] } } マッピングのチェックと修正 実際に、logstashは_sourceフィールドを既存のドキュメントから読み込み、 それらを新しいクラスタに直接投入しています。 しかし、logstashはマッピングについてはケアしていません。\n古いマッピングと新しいマッピングを比較するために、マッピングを取得してみましょう。\ncurl -XGET \u0026#34;http://localhost:9200/person/person/_mapping\u0026#34; { \u0026#34;person\u0026#34;: { \u0026#34;mappings\u0026#34;: { \u0026#34;person\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;address\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;city\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;country\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;countrycode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;location\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;geo_point\u0026#34; }, \u0026#34;zipcode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;children\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;dateOfBirth\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;date\u0026#34;, \u0026#34;format\u0026#34;: \u0026#34;dateOptionalTime\u0026#34; }, \u0026#34;gender\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;marketing\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;cars\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;electronic\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;fashion\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;food\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;garden\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;hifi\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;music\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;shoes\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;toys\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; } } }, \u0026#34;name\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } } } } curl -XGET \u0026#34;http://localhost:9201/person/person/_mapping\u0026#34; { \u0026#34;person\u0026#34;: { \u0026#34;mappings\u0026#34;: { \u0026#34;person\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;address\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;city\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;country\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;countrycode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;location\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;double\u0026#34; }, \u0026#34;zipcode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;children\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;dateOfBirth\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;date\u0026#34;, \u0026#34;format\u0026#34;: \u0026#34;dateOptionalTime\u0026#34; }, \u0026#34;gender\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;marketing\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;cars\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;electronic\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;fashion\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;food\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;garden\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;hifi\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;music\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;shoes\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;toys\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; } } }, \u0026#34;name\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } } } } これにより、いくつかの相違を発見できます。\n\u0026#34;location\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;geo_point\u0026#34; } \u0026#34;location\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;double\u0026#34; } データをインデックスする「前」に、実際に利用したいマッピングでインデックスを作成しておくことで、 この問題に対処できます。 この時点で、オリジナルのマッピングを望んだ形に変更することができます。例えば、アナライザを変更したりです。 また、インデックスの設定を新しく定義することもできます。 デフォルトでは、Elasticsearchは5つのシャードと各シャードに対して1つのレプリカを作成します。 しかし、この時点でもう一度変更することが可能です。\ncurl -XDELETE \u0026#34;http://localhost:9201/person\u0026#34; curl -XPUT \u0026#34;http://localhost:9201/person\u0026#34; -d\u0026#39; { \u0026#34;settings\u0026#34;: { \u0026#34;number_of_shards\u0026#34;: 1, \u0026#34;number_of_replicas\u0026#34;: 0 } }\u0026#39; curl -XPUT \u0026#34;http://localhost:9201/person/person/_mapping\u0026#34; -d\u0026#39; { \u0026#34;person\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;address\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;city\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;country\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;countrycode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;location\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;geo_point\u0026#34; }, \u0026#34;zipcode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;children\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;dateOfBirth\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;date\u0026#34;, \u0026#34;format\u0026#34;: \u0026#34;dateOptionalTime\u0026#34; }, \u0026#34;gender\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;marketing\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;cars\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;electronic\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;fashion\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;food\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;garden\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;hifi\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;music\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;shoes\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;toys\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; } } }, \u0026#34;name\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } }\u0026#39; さて、もう一度再インデックスしましょう！\nbin/logstash -f logstash.conf インデックスやタイプ名の変更 もちろん、インデックス名やタイプ名、IDを変更したい場合も変更が可能です！:)\nelasticsearch { host =\u0026gt; \u0026#34;localhost\u0026#34; port =\u0026gt; \u0026#34;9201\u0026#34; protocol =\u0026gt; \u0026#34;http\u0026#34; index =\u0026gt; \u0026#34;europe_people\u0026#34; index_type =\u0026gt; \u0026#34;someone\u0026#34; document_id =\u0026gt; \u0026#34;%{[@metadata][_id]}\u0026#34; } ","date":1432624090,"dir":"post/2015/","id":"23a22d1411afb787810d68210e6fad4f","lang":"ja","lastmod":1432624090,"permalink":"https://blog.johtani.info/blog/2015/05/26/reindex-elasticsearch-with-logstash-ja/","publishdate":"2015-05-26T16:08:10+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Reindex Elasticsearch With Logstash Thanks David! マッピングを変更したり、インデックスの設定を変更したり、あるサ","tags":["logstash","elasticsearch"],"title":"Logstashを使ったElasticsearchの再インデックス（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Join the Conversation: Discuss.Elastic.Co\n3つのOSSプロジェクトの開発をスケールアップし始め、 コミュニティサポートのために必要なやりとりに対してメーリングリストでは難しいということがわかってきました。 私たちは複数のメーリングリストを持っています。Elasticsearch、Logstash、そして英語以外の様々な言語のメーリングリストです。 このような状況では、あたらしい人たちはどこで質問をするのが良いのか混乱します。\nまた、メーリングリストの流量が増え、「参考になる話題」を見つけるのが難しくなってきました。 様々なユーザに採用してもらい、様々なユースケースが出てくることで、様々な質問が出てきています。 汎用的なメーリングリストではノイズの中から望んだ情報を見つけるのは難しいです。 また、ユーザ全てがメーリングリスト満足しているわけではありません。\nElasticは、ユーザの問題を解くことが大好きです。 コミュニティのメンバー皆さんに気に入っていただけるであろうソリューションを見つけ、フォーラムを https://discuss.elastic.co に移すことにしました。 ぜひ参加して、この新しいツールについてのご意見を聞かせてください。\nメーリングリストは好きだけど、ウェブフォーラムは苦手？問題ありません。 フォーラムにユーザプロファイル（GitHub、Facebook、Twitter、Google Appsのアカウントと連携するか、emailアドレスを利用すれば簡単に作れます）を作り、 email通知の設定をすればOKです。 これで、emailでのやりとりができるようになります。\n利用して、議論を楽しんでください。 もちろん、改善案などにかんするご意見もお待ちしています！\n","date":1432197903,"dir":"post/2015/","id":"615db1a24f36d19a8eaf18d4dceed6b2","lang":"ja","lastmod":1432197903,"permalink":"https://blog.johtani.info/blog/2015/05/21/join-the-conversation-ja/","publishdate":"2015-05-21T17:45:03+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Join the Conversation: Discuss.Elastic.Co 3つのOSSプロジェクトの開発をスケールアップし始め、 コミュニティサポー","title":"discuss.elastic.co にぜひ参加を"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.5.2 Released\n本日（4/27）、Lucene 4.10.4ベースのElasticsearch 1.5.1およびElasticsearch 1.4.5 をセキュリティバグフィックス版をリリースしました。 ダウンロードおよびすべての変更については次のリンクをごらんください。\n最新安定版：Elasticsearch 1.5.2 1.4系バグフィックス：Elasticsearch 1.4.5 本リリースはディレクトリトラバーサルの脆弱性のフィックスです。すべてのユーザにアップグレードを勧めます。\n過去のリリースに関するブログは以下のリンクを参照してください。\n1.5:1.4.1, 1.5.0 1.4:1.4.4,1.4.3, 1.4.2,1.4.1, 1.4.0, 1.4.0.Beta1 すべての1.5.2および1.4.5の変更についてはリンクをごらんください。以下では、セキュリティの問題について紹介します。\nディレクトリトラバーサル脆弱性の発見 1.5.2および1.4.5以前の全バージョンのElasticsearchで、ディレクトリトラバーサル攻撃に対する脆弱性がみつかりました。 攻撃者はElasticsearchを実行しているサーバからファイルを取得することができます。 この脆弱性はインストールしたばかりのElasticsearchには存在しません。 この脆弱性は\u0026quot;site plugin\u0026quot;がインストールされると露呈します。 ElasticのMarvelプラグインおよびコミュニティサポートの多くのプラグイン（例：Kopf、BigDesk、Head）がsite pluginです。 Elastic Shield、Licensing、Cloud-AWS、Cloud-GCE、Cloud-Azure、analysis pluginおよびriverプラグインはsite pluginではありません。\nこの問題をCVE-2015-3337としました。\nバージョン1.5.2と1.4.5はこの脆弱性に対して対策済みで、私たちはすべてのユーザにアップグレードを勧めています。\nアップグレードを望まないユーザはいくつかの方法でこの脆弱性に対して対応可能ですが、これらの方法はsite pluginを動作させなくします。\nsite pluginをインストールしているノードのelasticsearch.ymlのhttp.disable_sitesをtrueに設定し、Elasticsearchのノードを再起動 ファイアウォールもしくはプロキシを利用して、/_pluginへのHTTPリクエストをブロック すべてのsite pluginをすべてのElasticsearchノードからアンインストール この問題を報告していただいた、DocuSignのJohn Heasmanに感謝いたします。\n他の変更について インデックスされたスクリプトおよびテンプレートを上書きもしくは削除時に、キャッシュからも完全に削除する。 geo-shapeの多数のフィックス（distance_error_pctを利用した場合の、重要なprecisionに関するフィックスを含む） インデックステンプレートのデフォルトマッピングがバルクインデキシング中にも考慮するように修正 Shadowレプリカがファイルシステムの遅延に対する対障害性を向上し、プライマリシャードのよりスムーズなリロケーションをサポート geo-contextsをcompletion suggesterで使用した場合のマッピングのリフレッシュループを改善 いくつかの重要な変更がv1.4.5にバックポートされています。\n大きなシャードのリカバリを早くするためのシャードリカバリ中のマージを可能に \u0008* truncated translogsの操作をグレースフルに マージが遅くなる場合に、delete-by-queryを減速 ぜひ、Elasticsearch 1.5.2をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1430201648,"dir":"post/2015/","id":"8d7caf84b3a51cca27291c1f7cfc2d40","lang":"ja","lastmod":1430201648,"permalink":"https://blog.johtani.info/blog/2015/04/28/elasticsearch-1-5-2-and-1-4-5-released-ja/","publishdate":"2015-04-28T15:14:08+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.2 Released 本日（4/27）、Lucene 4.10.4ベースのEla","tags":["elasticsearch"],"title":"Elasticsearch 1.5.2 および 1.4.5リリース（日本語訳）"},{"contents":"第9回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n今回はトレーニングで来日していたIgorとNathanによる特別公演でした。 昨年同様、サムライズムの@yusukeさんに テキスト翻訳していただき、大変助かりました。ほんとうにすごかった。。。\nチェックイン数など 今回はチェックインした人：119名 キャンセルしなかった人：45名 でした。今回はキャンセル待ちのまま当日を迎えた人もいなかったので良かったかなと。 今回から懇親会ページを別にしてみました。本編の勉強会に参加登録していた方には何度かメールを出していたので、 見つけていなかった人は以内とは思うのですが、勉強会のページと間違える人がいたらしいという話を聞きました。 Doorkeeperで1イベントで複数のチケットにそれぞれの参加者数を設定できるようになると嬉しいかもなぁ。\nさて、いつもの通り簡単なメモです。 本当に簡単にですが。\nResiliency in Elasticsearch and Lucene / Igor Motov スライド：https://speakerdeck.com/elastic/resiliency-in-elasticsearch-and-lucene\n※上記スライドは少し古いバージョンです。公開されたら差し替える予定です。\nサンフランシスコで行われたElastic{ON}（弊社初のカンファレンス）で行われたセッションの 改良版といったところでしょうか。 話の中で登場した機能などのリンクをざっとアップしておきます。\nFielddata Doc Values Resiliency Status Kibana4: What\u0026rsquo;s New ? / Nathan Zamecnik スライド：未定\nKibana4の紹介をデモを交えてという感じでした。 こちらは、スライドよりもデモを見てもらうのが一番いいのですが。。。\nいくつかQAがあったので補足を。ちなみに、Issueのラベルに実装される予定のバージョンが付与されてたりします。\nQ：グラフをPDFでエクスポートとかできますか？ A：4.3.0で実装される予定です。関連Issueはこちら。https://github.com/elastic/kibana/issues/509 Q：巨大な数値の場合にKB、MBなどといった表示は可能ですか？ A：4.1.0で実装される予定です。関連Issueはこちら。https://github.com/elastic/kibana/issues/1543 Q：地図のズームを固定することはできますか？ A：4.1.0で実装される予定です。関連Issueはこちら。https://github.com/elastic/kibana/issues/1442 その他、感想などのブログ [Elasticsearch] 第9回 Elasticsearch 勉強会へ参加してきた まとめ 今回は特別バージョンでした。かなり詳しい話だったので面白かったと思います。 Kibanaはデモを見ていただけましたし。また、海外から人を呼べるといいなぁ。\n次回は6月ごろをめどに計画しようかと。 スピーカーは随時募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1429249314,"dir":"post/2015/","id":"7249710187cc2d983709e044dbc78d9d","lang":"ja","lastmod":1429249314,"permalink":"https://blog.johtani.info/blog/2015/04/17/9th-elasticsearch-jp/","publishdate":"2015-04-17T14:41:54+09:00","summary":"第9回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第9回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.5.1 Released\n本日（4/9）、Lucene 4.10.4ベースのElasticsearch 1.5.1 をリリースしました。 このリリースはElasticsearchの最新の安定バージョンとなります。\nすべての変更についてはdownload Elasticsearch 1.5.1 hereをごらんください。\n本リリースはシャードを新しいノードに配置するスピードを改善するためのバグフィックスを含んでいます。 シャードのリカバリーの最初のフェーズで、コピー元のノードからコピー先のノードへすべてのセグメントをコピーします。 このフェーズ中には登録、更新削除のリクエストはトランザクションログに記録され、リカバリが終了したあとに コピー先のノードでトランザクションログが再生されます。 シャードが大きい場合、トランザクションログに多数のイベントがたまってしまいます。\n以前では、新しいセグメントのマージはリカバリ中のコピー先のノードでは、実行できませんでした。 大きなトランザクションログは結果として、小さな新しいセグメントを多く生成し、リカバリのスピードに非常に影響を与えます。 Issue #10463は リカバリ中のコピー先のシャードのマージを可能にする変更です。\nその他の注目すべきバグフィックスは次のものになります。\n多くの削除によりバージョンマップがいっぱいになった場合にrefreshを実行するように変更(#10312) 多数のスナップショットを含んだリポジトリの管理の改善(#10366) 実験的な機能であるinner hitsのバグフィックス(#10388, #10353, #10309, #10235) 最後に、Riverが非推奨となりました、まだ見ていない場合は記事をご覧ください。\nぜひ、Elasticsearch 1.5.1をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1428892471,"dir":"post/2015/","id":"563864a949924c505985a168191dcb84","lang":"ja","lastmod":1428892471,"permalink":"https://blog.johtani.info/blog/2015/04/13/elasticsearch-1-5-1-released-ja/","publishdate":"2015-04-13T11:34:31+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.1 Released 本日（4/9）、Lucene 4.10.4ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 1.5.1リリース（日本語訳）"},{"contents":"Elasticsearch勉強会 in 名古屋を開催しました。 初の東京以外での勉強会です。 企画、セッションなどお手伝いいただいた@smogamiさん、@mzpさんありがとうございました！\nElasticsearch/ELK stack紹介 @johtani スライド：Introduction Elasticsearch\n初回（次回があるかはわかりませんが。。。）ということもあり、Elasticsearchの説明を行いました。 あと、LogstashとKibanaも。 Kibanaについては、手元の環境でいつものアクセスログのデモやなどを行いました。 また、LTの後に時間があったので、前回の勉強会で利用したチェックリストの説明なども。\nスタンドファームにおけるElasticsearch導入事例 @mzp さん スライド：後日アップ？\n\u0008* 使ってるのはKibana3\nアクセスログが保存されてたけど、活用できてなかった。 Fluentd、Elasticsearch、Kibanaをいれて、可視化してみた。 普通にログ検索が簡単にできて嬉しい システムのレスポンスの性能値などを可視化できるようにして性能改善中 Kibanaでログ分析を1年続けてみたら業務システムの保守と運用が捗った(仮) @smogami さん スライド：「Kibanaでログ分析を1年続けてみたら業務システムの保守と運用が捗った」\n名古屋でJavaの勉強会を主催してみたり（最近できてないけど） 導入するのになかなか大変だった（ファイアウォールだったりが）。。。 Kibanaを使ってどんなことをしてるのか？\n既存システムなどの機能の実行回数やレスポンス時間の推移 曜日ごとにもチェック どの機能がよく使われるのか？ 対象となっているシステムはJavaのシステム。 QA\nQ：ログの出力は新規に追加したのか？ A : ログの出力自体はLog4Jの設定を変更しただけ。もともと、各メソッドの開始と終了にそれぞれ時間が出力される仕組みがある。\nログの読み込み自体は自作ツールを利用。 飛び込みLT @dabits さん スライド：未定\nKibanaの使い道\nKPIツール エゴサーチツール - Twitterや2chなどのデータを解析ソーシャル分析みたいな感じ？ \u0008* ダッシュボードを用意してあげる場合もあるが、触っていろんな機能を試す人も。 感想・反省点など 30名弱の方に参加していただきました。ありがとうございました。 東京の勉強会でもそうですが、半分くらいが検索、半分くらいがログ解析関連に興味がある感じでした。 飛び込みLTもしていただけましたし。会場内限定の話もいくつか。\n場所 場所が少しわかりにくかったかなと。。。建物の入り口に看板がないので、1名に看板役として立っていただきました。 ただ、設備は充実していましたし、室内も綺麗でよかったです。\n懇親会 11名（+私）でした。美味しい手羽先などをいただきながら、Elasticsearch以外のことでも盛り上がりましたw。 また、名古屋の観光名所なども教えてもらったりと有意義な時間でしたw。\nということで、少しでもElasticsearch、Kibana、Logstashなどのユーザが増えてくれればうれしいかなと。 私抜きでも勉強会はできると思うので、今後も開いてもらえるとうれしいかぎりです。 初めての東京以外での勉強会でどんな感じの方が利用しているのか、興味があるのかといったことも知ることができました。\n関連ブログなど Kibana4活用事例を話しました その他（余談） コンパルという喫茶店のアイスコーヒー。ちょっと新鮮な体験でした。 あとは、日曜日に観光場所として教えてもらった、トヨタ産業技術記念館にも行ってみました。 一人だったけど、非常に楽しめました。実演とかあって、わかりやすいし。 トヨタが自動織機の会社が始まりだってのは知らなかった。\n","date":1428108439,"dir":"post/2015/","id":"24357fe145c869ec82fdfc8134a1a6d1","lang":"ja","lastmod":1428108439,"permalink":"https://blog.johtani.info/blog/2015/04/04/elasticsearch-study-session-at-nagoya/","publishdate":"2015-04-04T09:47:19+09:00","summary":"Elasticsearch勉強会 in 名古屋を開催しました。 初の東京以外での勉強会です。 企画、セッションなどお手伝いいただいた@smogamiさ","tags":["elasticsearch","勉強会"],"title":"Elasticsearch勉強会 in 名古屋を開催しました。#elasticsearch #elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.5.0 Released\n本日（3/23）、Lucene 4.10.4ベースのElasticsearch 1.5.0 をリリースしました。 このリリースはElasticsearchの最新の安定バージョンとなります。 多くのresiliency(復元性、弾力性) enhancementとバグフィックスを含んでおり、 すべてのユーザにアップグレードを推奨しています。\nすべての変更についてはdownload Elasticsearch 1.5.0 hereをごらんください。\n460PRという大量の変更を含む本リリースは、Elasticsearchをよりresilient(弾力のあるもの)にするために 費やされています。\nInner hits 本リリースで追加された、Elasticsearchに最もリクエストされたものの一つがinner hitsです。 これは、has_childもしくはnestedクエリにマッチした子のドキュメントを、各親ドキュメントと一緒に返すことができます。\n例えば、blogという親ドキュメントとcommentという子ドキュメントを持っているとします。 この時、\u0026ldquo;full text search\u0026quot;というコメントを持ったブログ記事を検索したいとします。\nGET /my_index/blog/_search { \u0026#34;query\u0026#34;: { \u0026#34;has_child\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;comment\u0026#34;, \u0026#34;score_mode\u0026#34;: \u0026#34;sum\u0026#34;, \u0026#34;query\u0026#34;: { \u0026#34;match\u0026#34;: { \u0026#34;body\u0026#34;: \u0026#34;full text search\u0026#34; } } } } } 上記のリクエストは、親のblogドキュメントを返します。 しかし、どのコメントが関係しているのかはわかりません。 関連しているコメントを検索して親ごとにグルーピングするために、 少し手間のかかる2回目のクエリを実行する必要があります。\nInner hitsがこれを変えてくれます。 inner_hitsパラメータを次のように、上記のクエリに追加するだけです！\nGET /my_index/blog/_search { \u0026#34;query\u0026#34;: { \u0026#34;has_child\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;comment\u0026#34;, \u0026#34;score_mode\u0026#34;: \u0026#34;sum\u0026#34;, \u0026#34;query\u0026#34;: { \u0026#34;match\u0026#34;: { \u0026#34;body\u0026#34;: \u0026#34;full text search\u0026#34; } }, \u0026#34;inner_hits\u0026#34;: {} } } } 検索結果の各blog記事に、inner_hitsという項目があり、そこに検索にヒットしたコメントの 上位3件（デフォルト値）が返ってきます。\n... \u0026#34;hits\u0026#34;: [ { \u0026#34;_index\u0026#34;: \u0026#34;my_index\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;blog\u0026#34;, \u0026#34;_id\u0026#34;: 1, \u0026#34;_score\u0026#34;: 3.68, \u0026#34;_source\u0026#34;: { ... }, \u0026#34;inner_hits\u0026#34;: { \u0026#34;comment\u0026#34;: { \u0026#34;total\u0026#34;: 16, \u0026#34;hits\u0026#34;: [ { \u0026#34;_type\u0026#34;: \u0026#34;comment\u0026#34;, \u0026#34;_id\u0026#34;: 5, \u0026#34;_score\u0026#34;: 2.79, \u0026#34;_source\u0026#34;: { \u0026#34;body\u0026#34;: \u0026#34;Full text search is the bomb\u0026#34; } }, { ... }, { ... } ] } } } ] ... inner_hits部分は、第2の検索リクエストに似ています。 sizeやfromパラメータを含めるくことで、挙動をカスタマイズできます。 また、検索から想像するであろう、ページネーション、ソート、ハイライト、_sourceフィルタリングなどといった機能もサポートします。\nInner hitsはparent-childおよび、nestedドキュメントをサポートします。 この機能は、現時点ではexperimentalラベルが付与されています。 このラベルは、この機能が将来変更されたり、削除されたりする可能性があるかもしれないことを意味します。 詳細については、Inner Hits documentationをごらんください。\nShadow replicas Elasticsearchはそれ自身の冗長性に常に気をつけています。 それは、レプリカシャード（各プライマリシャードの冗長なコピー）を持っています。 これは、プライマリシャードを失った時に、データをロスしないようにするためのものです。 レプリカシャードはまた、検索のスループットをスケールアウトするためにも利用できます。 多くのレプリカ（ノードを伴うことで。）はスループットを増加させます。\nしかし、ユーザによってはElsticsearchを分散ファイルシステム上でホスティングしており、すでに、 ファイルシステムがレプリケーションと冗長性を担当しています。 ファイルシステムが同じことしているので、各シャードのコピーを複数持つことはあまり意味がありません。\nShadowレプリカはノードを追加することによる検索スループットをスケールアウトすることが、 余分なストレージやインデキシングのコストを払うことなく、可能になります。 代わりに、各シャドーレプリカはプライマリシャードを持っている共有ファイルシステムにread-onlyでアクセスします。 Shadowレプリカは定期的にファイルシステムのビューをリフレッシュし、プライマリシャードのどんな変更も検知するでしょう。\nプライマリシャードが失敗したら、Shadowレプリカがプライマリに昇格し、 失敗したプライマリによって書き込まれたトランザクションログを読み込みリプレイできます。\nこの機能はexperimentalマークが付いています。詳細についてはShadow Replicas documentationをごらんください。\nResiliency improvements Elasticsearch 1.1 から 1.3では、インデックスのすべてのファイルのチェックサムを追加し、 それらのファイルが壊れているかどうかをチェックするために利用することにフォーカスしました。 1.4では、Zen discoveryと分散モデルについて大きな改良を加えました。\nこれらの変更にともなう、より詳細な統計情報やより詳細なロギングがElasticsearchやLuceneの以前のバージョンに存在した 未知の問題を明るみに出しました。 Elasticsearch 1.5.0では、これらの問題の多くに対処しています。\nElasticsearchとLuceneの以前のバージョンにあるバグがインデックスの故障を引き起こしていました。\nチェックサムコードのおかげで、これらを発見できました。現在は、Elasticsearchの起動時に自動的にLucene3.x\n(Elasticsearch 0.20.x以前)が作成したセグメントを検知して、シャードをオープンする前に、新しいフォーマットを使って、 新しいコミットポイントを書き出します。(#9899)\n1.3.xもしくは以前のバージョンからローリングアップグレードは、ローカルのシャードデータを再利用しようとせずに、\nシャード全体をコピーしようとします。1.3.2と以前のバージョンが実行されているノードからローリングアップグレードすることは 圧縮をオフにしない限りできなくなりました。(#9925)\n1.3.xやそれ以前のバージョンからアップグレードする場合、ローリングアップデートする代わりにクラスタの再起動を考えたほうがいいかもしれません。\n非同期環境は予測することが難しいです。時に、最も予測していないことが起きるからです。\nシャード配置、リカバリ、削除のコードの多くが単純化され、状態変更をよりアトミックで決定的にするための変更によりリファクタリングされました。\n(#8720, #9799, #9784, #9801, #9083, #8579, #8436, #8092, #9902, #6644, #8350, #9770, #9616, #9439, #8350, #8494)\n同様に、変更はクラスタ状態の更新が常に前進するということを確実にしました。更新の受け取り順序が順不同であったり、\nマスターだったノードからの更新を受け取った場合に混乱させていました。 (#9632, #9541, #9503)\nチェックサムとチェックサムのバリデーションの強化(#8723,\n#8599, #8587, #8407, #8010, #8018)\ndisk threshold allocation deciderを速く(#8803)、賢く(#7785)、自動化(#8270)\nauto-generated IDの利用時のインデキシングのスピードアップのためのに追加された最適化を除去。\nたまにドキュメントを重複して登録するため(#7729)\nDownload now ぜひ、Elasticsearch 1.5.0をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1427859496,"dir":"post/2015/","id":"19ecbaa5e12f7a9ebcff703c79534a52","lang":"ja","lastmod":1427859496,"permalink":"https://blog.johtani.info/blog/2015/04/01/elasticsearch-1-5-0-released-ja/","publishdate":"2015-04-01T12:38:16+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.0 Released 本日（3/23）、Lucene 4.10.4ベースのEla","tags":["elasticsearch"],"title":"Elasticsearch 1.5.0リリース（日本語訳）"},{"contents":"サンフランシスコからこんにちは。\n今、私は、弊社初のユーザカンファレンスelastic{ON}に 参加するために、初のアメリカ出張中です。 初のユーザカンファレンスですが、世界各国から約1300人！の登録がありました。\n本日が初日（Welcome Receptionが昨晩開催されましたが）です。 初日のキーノートで重要な発表が2つありました。\nブランド名の変更（Elastic: For - You Know, More Than Search） Found.noの加入（Welcome Found） です。\n昨日までは、elasticsearchでした。 本日からは、elasticになります。 ブランド名の変更と同時にサイト、ロゴなども変更されました。\nもう一つのビッグニュースがFoundの加入です。 found.noはElasticsearchをクラウドサービスとして提供している会社です。 彼らがジョインすることで、elasticsearchをより気軽に利用できるような環境ができてきます。\nKeynoteでの驚きのニュースこれらでした。 もちろん、このカンファレンスはそれだけには止まりません。\nNetflixやGitHub、Verison Mobile、WikimediaといったElasticsearch,ELKスタックのユーザの話や、 弊社の人たちによる今後のロードマップや私たちの考え方など多岐にわたる話を聞くことができます。\nこのような機会を今後も提供できるような会社になれるよう、頑張っていきたいなと思っています。\nちなみに、弊社のカンファレンスは私がこれまで経験したことのないカンファレンスになっています。 DJや各種ゲーム（ビリヤードとかパックマンとか）が楽しめるようなパーティが 懇親会として開催されたり、スポンサーブースでウェルカムレセプションが行われたりと、 面白い取り組みにあふれています。 次回開催されることがあれば、ぜひ日本の方達にも参加してもらえたらうれしいなと。\n","date":1426059991,"dir":"post/2015/","id":"ced9df0d8c8ed14de91c509b31b4c4ae","lang":"ja","lastmod":1426059991,"permalink":"https://blog.johtani.info/blog/2015/03/11/attend-elasticon/","publishdate":"2015-03-11T16:46:31+09:00","summary":"サンフランシスコからこんにちは。 今、私は、弊社初のユーザカンファレンスelastic{ON}に 参加するために、初のアメリカ出張中です。 初のユ","tags":["elastic","elasticon"],"title":"#elasticon に参加中"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：you know, for security: shield goes ga\n1/27にShield 1.0 をリリースしました。 Elasticsearch向けの私たちのセキュリティプラグインの最初のリリースです。 11月にShieldについてアナウンスしてから、Elsaticsearchのためのセキュリティの機能は、 一般的に望まれているものから始まり、具体的な考えと実行できる計画へと変遷し、それが、いま現実となりました。\n十分にセキュアな環境に、Elasticsearchクラスタをセキュアな状態でデプロイできるようにするため、 私たちは継続的にカスタマーやユーザーからのリクエストを受け取り、統合されたソリューションになるようにしてきました。\n私たちは、そのようなプロダクトがどうあるべきか調査することから始め、 カスタマーとユーザが必要とするセキュリティとはどんなものかを理解するために多くの時間を費やしました。 その結果がShieldです。 Shieldは、ElasticsearchクラスタをセキュアにするElasticsearchの有償プラグインです。 私たちは、ShieldをDev、Gold、Platinumサブスクリプションの一部として、追加料金なしで提供します。\n最初のリリースでは、基本的な機能と基盤にフォーカスしています。 Elasticsearch自身に対しても、セキュリティに対して準備してきました。 拡張性の側面だけでなく、Elasticsearchにあるデータフローについても再考してきました。 Elasticsearchクラスタをセキュアにする場合に、具体的な価値を即座に届けるだけでなく、素早く拡張できるようにも開発しました。\n機能 Shield 1.0は次の5つにフォーカスしています。\n認証(Authentication) 認可(Authorization) 暗号化通信とノードの認可(Encrypted Communication \u0026amp; Node Authentication) IPフィルタリング 監査証跡(Audit Trail) 認証(Authentication) セキュリティの大部分はアイデンティティについてです（例えば、だれがこのAPIを呼び出したのか？システムに何のサービスが接続するか？など） サービスのライフタイムのある時点で、サブジェクト（例えばユーザー）を現在実行中のサブプロセスなどに結びつけることです。 この関係性を持つためには、サブプロセスを実行する前にユーザの身元を確認するように命じます。 ユーザの身元の確認のプロセスをAuthenticationと呼び、ElasticsearchのすべてのAPIコールでそれが実行されます。\n認証の手法は多くの異なるものがあります。 それぞれの手法は、ユーザが認証されたという資格（Authentication Token）を、それぞれのタイプで提供するようにユーザに要求します。 Shield 1.0ではシンプルに、必要なauthentication tokenをユーザ/パスワードペアとしています。 （これは、Shieldの認証基盤が簡単に拡張でき、将来は異なるauthentication tokenもサポートできることを意味します。）\nユーザの資格を受け取ることだけでは不十分で、次に、それらをチェックする必要があります。 Shieldでは、これはレルムの責務です。 レルムは認証プロバイダ/サービスとしてみることができます。 妥当なユーザであると判断/解決されたか、 authentication tokenが適切な資格を持っていない/単に知らないユーザであるということで、拒否されたかです。 Shieldの認証メカニズムでは、複数のレルムを設定でき、さらに、あるレルムの戻り値を扱う他のレルム、というようなchainとすることもできます。 Shield 1.0は3つのレルムをサポートします。\nesusers - Elasticsearchによって管理されるファイルベースのレルムです。 これは、ファイルにユーザを定義することができます。（Apacheサーバのhtpasswdファイルのようなもの） このレルムは外部への依存はなく、Shieldをインストールすれば、デフォルトで使用できます。 このレルムは配置が簡単で、マルチテナントなElasticsearchクラスタに対して使用できます。 マルチテナントなElasticsearchクラスタとは、クラスタを複数のアプリでシェアすることをテナントと言います。 また、すべてのユーザがパスワードを忘れてしまうような\u0026quot;emergency\u0026quot;な代替レルムも対応可能です。 (誰もシステムに入れないような状況のことです) LDAP - 外部のLDAPサーバでユーザを認証するレルムです。 このレルムは組織のLDAPサーバで管理/保存されているユーザをすでに持っている組織を対象としています。 Active Directory - LDAPのタイプの1つで、Active Directoryに対する設定になります。 レルムはelasticsearch.yml設定ファイルで、次のように設定可能です。\nshield.authc realms:\nesuser: type: esusers order: 0 ldap: type: ldap order: 1 url: ldaps://url/to/ldap1/server ldap_fallback: type: ldap order: 2 url: ldaps://url/to/ldap2/server 上記のようにrealmsが一つのチェインとして参照されます。 レルムごとに、設定された順序で、それらは参照されます。\nNOTE : Shieldには、esusersファイルに保存されたユーザを管理するためのコマンドラインツールもあります。\n認可(authorization) 認可(Authorization)は保護されたリソースにアクセスするユーザを許可するか拒否するかということです。 モダンなシステムは、ユーザのパーミッションのために、ロールベースのアクセスコントロール（RBAC）モデルを利用します。 このモデルでは、各ユーザはロールの集合に関連していて、それぞれのロールには、パーミッションの集合が定義されています。 これは、洗練された設定で、パーミッションを機能的なグループで共有させることができます。 例えば、次のようなロールを定義したとします。\nemployee - すべての従業員は部門をまたいだ会社のデータへアクセスできます（例えば、コンタクトやディレクトリ情報など） sales - すべての営業職は営業データにアクセスできる（例えば、流通ルート、ルート、顧客） finace - すべての財務の従業員は財務データにアクセスできる（例えば、予算、経費、伝票） 財務部門のAnnは従業員と財務のロールを持っており、会社のディレクトリと財務データにアクセスでできます。\n認可プロセスはユーザがリクエストに関連したユーザが必要で、このプロセスのために、認証フェーズの後に直接実行されます。\nShieldは2つのタイプのリソースを定義します。クラスタとインデックスです。 これらは、すべてのAPIコールで保護されます。 さらに、それらに関連したパーミッションとロールも定義できます。 一度定義をすると、ロールはユーザもしくはLDAP/ADのグループに関係します。 ロールはroles.yml設定ファイルで定義されます。 設定のサンプルは次のようになります。\nadmin: cluster: all indices: \u0026#39;*\u0026#39; : all monitor: cluster: monitor indices: \u0026#39;*\u0026#39;: monitor employee: indices: \u0026#39;company_directory\u0026#39; : read sales: indices: \u0026#39;opportunities\u0026#39; : read, write \u0026#39;accounts\u0026#39; : read, write finance: indices: \u0026#39;expenses\u0026#39; : read, write \u0026#39;purchases\u0026#39; : read, write 上記のサンプルで、次の5つのロールを定義しています。\nadmin - 管理者のロールで、すべてのクラスターレベルの操作とすべてのインデックスに対してすべてのインデックスレベルの操作を実行可能です。 (¥*インデックスはすべてのインデックスにマッチするワイルドカード) monitor - システム/クラスタのモニタリングのためのロール。このロールのユーザはすべてのクラスタとインデックスレベルの情報の読み取りの APIにアクセス可能だが、インデックスのデータへの読み書きや設定の更新は不能 employee - compnay_directoryにあるすべてのデータへの読み取りアクセスを与えられたロール。このロールはクラスタレベルへのアクセスやデータの書き込みアクセスは持っていない (特にcompany。洗濯されたグループの人々はcompanyディレクトリの更新は可能だが、employeeは読み取りのみが可能) sales - opportunitiesとaccountsインデックスの読み書きができるロール finance - expensesとpurchasesの両方に読み書きができるロール 上記のサンプルで定義されているallとreadとwriteとして名前がつけられた権限です。 これらは、予約語で、Elasticsearchのローレベルのアクションを複数含んだ権限です。 （writeはindex, delete, delete_by_query, bulk, updateの操作を含んでいます。） 多くのケースで、これらのハイレベルの名前が付けられた権限で十分ですが、特定のロールに特定のアクションを明示的に指定することもできます。 次のようになります。\nhr: indices: \u0026#39;company_directory\u0026#39; : indices:data/write/index, indices:data/write/update ここまで説明した認可のレルムは、各ユーザに関連するロールを識別するためのものです。 内部のesuserレルムでは、提供されるesuserコマンドラインツールを使ってロールはユーザに割り当てたり変更したりもできます。 LDAPやActive Directoryでは、LDAP/ADグループにShieldのロールを割り当てることができます。\n認証と認可の両方を用いることで、ユーザリクエストに対して、ユーザごとに許可/不許可をすることができます。\n暗号化通信 認可はElasticsearchのデータを機能的な観点（許可されたユーザだけが操作を可能にする）で保護しますが、 クライアントからElasticsearchクラスタへ、もしくはクラスタのノード間では暗号化されていないデータを送るためまだ危険があります。 第三者が登頂したり、オンザフライでデータを書き換えたりといった可能性やクラスタを壊すことができます。\nShield 1.0はElasticsearchのすべての通信チャネルをセキュアにすることができます。 クラスタ内のノード間のチャネルやクライアントに公開されているチャネルです。 これは、SSL/TLS通信を導入して実現します。\nShieldで使えるSSLはElasticsearchのtransportサービスをSSL/TLSで通信できるものに置き換えます。 これは、ノード間通信チャネルと、HTTP transport（REST APIを提供するもの）のそれぞれに設定可能です。\nShieldのSSL/TLSは、スタンダードなJavaのものとkeystoreとtruststoreを基本にしたものが利用可能です。 SSL/TLSを設定すると、各ノードのキーストアに証明書をインポートする必要があります。 CAがサインした証明書を使うことも、CAが信頼したものとして許可許諾されたものを使うことが可能です。 これは、信頼されたすべてのCAとして知られているtrust storeが必要です。 新しいノードをクラスタに追加するときに、すべての必要な少なくとも一つの信頼されたCAから発行されてサインされたものが必要になります。 クラスタで個別のノードがすべてのkeystore/truststoreを更新する必要性なしに。？？\n通信チャネルを安全にする方法やSSL/TLS設定をどのように行うかはShieldのドキュメントをご覧ください。\nノード間認証 強く推奨しますが、許可されたノードだけがクラスタに接続できるようにするために、ノードの認証をSSL transportに設定することができます。 これは、shield.transport.client.authにtrueを設定することで可能です。 設定した場合、ノード間でSSLハンドシェイクが行われ、接続されたノードが接続に来たノードのクライアント認証を要求しチェックします。 もし、チェックに失敗した場合は、SSLシェイクハンドが失敗し接続が拒否されます。\nSSLクライアント認証 transportレベルでノード認証が必要なようなら、次のような疑問がわくでしょう。 Elasticsearchはクラスタに接続するTransportクライアントを使うときはどのように振る舞うのか？ Transportクライアントはクラスタの他のノードと同じチャネルを使うため、コネクションを確立するときに、ノードが他のノードと異なるかどうかを見極めることはできません。\nこの時、もっとも単純な解決は、Transportクライアントも同様に許可を与えることです。 それは、認証を解決するときに、他の問題（潜在的な悪意）を引き起こします。 Transportクライアントが他のクラスタのノードを偽装しようとすることです。これは望んでいません。\n幸いなことに、良い解決方法があります。 トランスポートプロファイルです。 Elasticsearch 1.4で導入されたトランスポートプロファイルは、トランスポートレイヤー（異なるホスト/ポートにバインドされる）のために複数のネットワークチャネルを設定することができます。 Shieldはこのサポートを、プロファイルごとに異なるSSL設定をできるように拡張します。 また、ノードのタイプとクライアントプロファイルタイプの間に明確な違いを設定することも可能です。 これを用いると、2つのプロファイルを設定できるようになります。 ひとつは、クライアントのためのもので、もうひとつはクラスタのノードのためのものです。 これにより、クライアントのための認証の問題が必要なくなり、Shieldはクライアントプロファイルをもった限定されたクライアントからのリクエストを保証します。\nIPフィルタリング これは、厳密には、認証カテゴリではありませんが関係しています。 Shieldはそれ自身がIPフィルタリングのメカニズムを持っています。 これは、許可/不許可のIPのリストを設定することができます。 これらのフィルタリングのルールは複数のレベルで設定可能です。 transportチャネル、transportプロファイルレベル、そして、HTTPチャネルです。 次の設定は、それらの設定のサンプルです。（設定ファイルはelasticsearch.ymlになります）\nshield: transport.filter: allow: - \u0026#39;127.0.0.1\u0026#39; - \u0026#39;2001:0db8:1234:0000:0000:8a2e:0370:73 deny: - \u0026#39;10.0.0.0/8\u0026#39; - \u0026#39;2001:0db8:1234::/48\u0026#39; - \u0026#39;*.google.com\u0026#39; http.filter: allow: [ \u0026#39;10.0.0.0/8\u0026#39; ] deny: [ \u0026#39;127.0.0.1\u0026#39; ] transport.profiles: client: shield.filter.deny: [ \u0026#39;_all\u0026#39; ] このように、IPv4とIPv6、CIDR、ホスト名、ワイルドカードが利用できます。 また、この機能はホストOSのIPテーブルに設定することで追加できるが、Shieldにそれを保持し、それらの設定を単純化し、 デプロイの全体から除去できることにも注意してください（詳細はドキュメントのIPフィルタリングをご覧ください）。\n監査証跡（Audit Trail） セキュアなシステムの必須機能の一つで、監査硝石により、Elasticsearchに発生した重要なイベントをトラッキングすることが可能です。 これらのイベントを保存することは、Elasticsearchクラスタの重要なアクティビティの証拠を提供でき、 不審な/悪意のある可能性のあるイベントを追跡するときの診断ツールにもなります。\nShield 1.0.0で、監査証跡は監査/アクセスlogを一般的なElasticsearchのログとは個別に保存します。 それらは、構造化されているため、読んだりパースするのが容易で、イベントのタイプも分類されています。 また、情報のレベルを設定することができ、各イベントをlogレベルの設定で書き出すことができます。 以下が、イベントのリストです。\nanonymous_access_denied - 認証トークンがないユーザからのリクエストがあった時のログ authentication_failed - リクエストされたユーザの認証に失敗した時のログ access_denied - 認証されたユーザが許可されていない操作を実行した時のログ access_granted - 認証されたユーザが許可された操作を実行した時のログ tampered_request - 不正に書き換えられたリクエストが到着したのを検知した時のログ connection_granted - ノードもしくはtransportクライアントがIPフィルタのルールにパスした時のログ connection_denied - ノードもしくはtransportクライアントがIPフィルタリングルールの制限により却下された時のログ Shieldの監査証跡についてより詳しく知りたい方は、ドキュメントをごらんください。\n次のバージョンでは？ ここまで紹介したように、これはまだ始まりにすぎません。 Shieldに追加される多くの機能があり、しっかりとした基盤を構築したところです。 Shieldの次のバージョンでは、以下の機能の追加にフォーカスするでしょう。（これらだけに限ったわけではありません。）\nAPIによる設定、管理 より拡張され、柔軟なLDAP/Active Directoryサポート レルムタイプの追加（kerberos、anonymous、certificatesなどなど） セッションベースの認証 ShieldはElasticsearch社の2番目の（Marvelに続く）商用プロダクトです。 ダウンロードして開発環境で評価してください。 インストールは他のプラグインと同様の方法です（インストール方法についての詳細はこちら）。 一度インストールすると、30日の試用ライセンスが始まります。 もし、さらに時間が必要な場合は、sales@elasticsearch.comまで連絡してください。\n私たちのすべてのプロダクトについてフィードバックをお待ちしています。 Shieldの商用利用、機能、ロードマップ、その他のセキュリティに関するトピックなど、質問がありましたら、 サイトからご連絡ください。\n","date":1425030596,"dir":"post/2015/","id":"cb13b64d0127c13bb466c4d4677a7b8a","lang":"ja","lastmod":1425030596,"permalink":"https://blog.johtani.info/blog/2015/02/27/you-know-for-security-shield-goes-ga-ja/","publishdate":"2015-02-27T18:49:56+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：you know, for security: shield goes ga 1/27にShield 1.0 をリリースしました。 Elasticsearc","tags":["elasticsearch","shield"],"title":"セキュリティ向けプラグインShieldのリリース（日本語訳）"},{"contents":"4月13日から3日間、ElasticsearchのCoreトレーニングが東京で開催されます。 Early Birdということで、3/14までに申し込みすると割引があります。 興味のある方は、見ていただければと。\nまた、4/15にElasticsearch勉強会を開催します。 トレーニングに弊社のエンジニアが来日しますので、なにか話をしてもらう予定です。\n募集は後日、Elasticsearch勉強会のDoorkeeperで行います。 興味のある方は、登録しておいていただければと。\nトレーニングや勉強会でお待ちしております。\n","date":1425024629,"dir":"post/2015/","id":"f2cbe07bf2ff16d5a5860b4d6edbc5e8","lang":"ja","lastmod":1425024629,"permalink":"https://blog.johtani.info/blog/2015/02/27/2nd-tokyo-training/","publishdate":"2015-02-27T17:10:29+09:00","summary":"4月13日から3日間、ElasticsearchのCoreトレーニングが東京で開催されます。 Early Birdということで、3/14までに申し込みす","tags":["elasticsearch"],"title":"Elasticsearch Coreトレーニング開催"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：kibana 4. literally.\nKibana 4は現在、文字通り、抽象的に、概念的に、精神的に、そしてとても楽しく、プロダクションレディになりました。 1週間前に準備はできていましたが、満足できるものであるという確信を得たいと思っていました。 そして、Kibana 4.0.0 GAをリリースしました。 次のものはサンプルのスクリーンショットと前日譚です。 これらに興奮してしまった方のために、2ステップのプランを用意しました。\nダウンロードする：Kibana 4 downloadsページからダウンロードします。 理解する：Kibana 4 docsページを読んで理解します。 Tip : もし、まだ、あなたのクラスタがElasticsearch 1.4.4でない場合は、アップグレードする必要があります。\nTip2 : Kibana 4 RC1からアップグレードする場合は、configを移行する必要があります。こちらのgistを参照\n前日譚 - the back story Kibanaはすでに問題解決のためのツールになっています。 なぜ、毎晩2時に呼び出されるんでしょう？ そのコードがプロダクションに入ったのはいつですか？ その結果、何を壊しました？ 私たちはそれらを解決しました。 世界的に、長い間、だれも夜中の2時に呼び出されませんでした。知ってます？。\n*しかし、ここには落とし穴があります。*答えが簡単になれば、問題が難しくなります。 楽な勝利は簡単でした。では、難しい問題（深さが3層の問題）を解きましょう。 複数の要素、複数のフィールドそして、複数のデータソースを分析する必要がある問題を解きましょう。 Kibana 4は少ない時間と労力で最も難しい問題を解決してくれます。\nKibana 3で学んだことをKibana 4に取り込みました。 なぜ10億のデータを持っているのに、地図には1000個しかプロットできないのでしょう？ 1つのチャートに1つのフィールドなんでしょう？ なぜ、1つのパネルに1つのチャートなんでしょう？ なぜ、1つのダッシュボードに1つのインデックスなんでしょう？ 5つのシナリオを用意し、2つのフィールドにまたがったデータを比較し、 1つのダッシュボードに3つのインデックスのデータを表示してみましょう。 さぁ、やりましょう。終わったらアイスクリーム（トッピング付きの）を取りに行きましょう。\nthe plot アイスクリームのように、問題には多くの種類があります。 そのために、Kibanaをナポリ風アイスクリーム（3色アイス）のように分割しました。 嫌いな種類は除いて。 もし、あなたがKibanaのユーザ歴が長い場合、最初のタブのDiscoverがホームであることが正しく感じるでしょう。 これにより、短時間で、検索し、レコードを見つけ、簡単な問題を解決できます。 簡単な問題とは、すべてを物語る1行のデータを見つけることによって解決する問題です。\n物事が簡単な検索で説明できるものよりも複雑になった時、チャートとグラフで魔法を作る時間です。 Visualizeタブを開き、Elasticsearchのaggregationの力を利用してデータを解析しましょう。 Visualizeは複数の次元の性質のデータを見せ、今まで尋ねたことがないような質問に対して素早く回答するチャートやテーブル、 地図を作成できます。 あなたが最初に尋ねる質問は「先週サイトが遅かったのはなぜ？」でした。 しかし、データによって明らかにされた質問は「なぜ、クリスマスに東京からの平均ファイルサイズリクエストがスパイクしたのか？」です。\n最後に、Dashboardでこれらを1つにします。\n大きなスクリーンに配置して、こう言います。 「あなたの答えはこのリンクにあります。また、Wikiに埋め込んで、データをCSVにエクスポートしてメールしました。 アイスクリームを食べた後に、自叙伝の第1章を書きました。もっとアイスを持ってきてください。かき混ぜますから。」\nそれぞれのタブで見てきた詳細については、Kibana 4 Beta 1 : Releasedをごらんください。\nto be continued\u0026hellip; 居眠りをする時間はあります？いいえ、Kibana 4.1についてすでに作業中で、将来の大きなプランを持っています。 多くの労力はKibana 4の土台の安定と実用性を構築することに使われました。 また、Elasticsearchアプリケーションの将来を構築するプラットフォームを作りました。 すべてのものは拡張できるように設計されています。 例えば、可視化はより良くなるように構築されています。 オープンソースは私たちのGitHubアカウント以上のものです。 それは、新しく素晴らしいものを誰もが作ることができる構造を作ることが私たちの約束です。\nKibanaでグラフなどを構築したり、Elasticsearchを利用したアプリケーションを作成するために、 私たち開発者のブログを参考にしてください。 ちょっと見てみたいですか？ Elastic{ON}15のSpencer Algerのトークをチェックしてください。\nあなた方なしでは、私たちはここにはいないですし、あなた方の助けがなければ何もできません。 ぜひ、GitHubでのissueや提案、貢献をお待ちしています。 もしくは、IRCでFreenodeの#kibanaに参加してください。\nextra credit Kibana 4のすべての話に興味がありますか？私たちのKibana 4ベータに関する過去のブログをチェックしてください。\nKibana 4 Beta 1: Released Kibana 4 Beta 2: Get it now Kibana 4 Beta 3: Now more filtery Kibana 4 RC1: Freshly baked 最後に、Kibanaの利用に関する話をお持ちなら、ぜひ聞かせてください。 stories at elasticsearch dot comもしくは@elasticsearchに連絡をください。 あなたの話を世界にどのようにシェアしているかごらんください。\n","date":1424408752,"dir":"post/2015/","id":"eee039f49a5b570599cf459c55c649f3","lang":"ja","lastmod":1424408752,"permalink":"https://blog.johtani.info/blog/2015/02/20/kibana-4-literally-ja/","publishdate":"2015-02-20T14:05:52+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：kibana 4. literally. Kibana 4は現在、文字通り、抽象的に、概念的に、精神的に、そしてとても楽しく","tags":["elasticsearch","kibana4"],"title":"Kibana 4（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch 1.4.4 and 1.3.9 released\n本日（2/20）、Elasticsearch 1.4.4とElasticsearch 1.3.9をリリースしました。 これはバグフィックスリリースとなります。 主に、Lucene expression scriptsを使う場合のRPMとDEBパッケージの パッケージング問題のフィックスをしたものです。 1.4.4のダウンロードこちらのリンクからアクセスできます。\nfixes 1.4.3のRPMおよびDEBパッケージにはAntlrとASMの依存関係の不足がありました。 この依存はElasticsearchでLucene expression scriptsを利用する場合に必要になります。 Groovyに関する1.4.3の変更により、多くのユーザがLucene explression scriptsを利用することが予想されるため、すぐに、1.4.4をリリースしました。\nまた、このリリースには、クラスタの保留タスクに関するいくつかのバグフィックスも含まれています。 さらに、date histogramで負のインターバルの場合にOutOfMemoryErrorを引き起こすバグも 修正されています。\nすべての変更については1.4.4のリリースノートおよび1.3.9のリリースノートをごらんください。\nフィードバック 私たちはフィードバックをお待ちしています。 Twitter(@elasticsearch)もしくはGitHub issues pageで教えてください。\n","date":1424408734,"dir":"post/2015/","id":"ddd3e6f6e298d3884abc4d888a043664","lang":"ja","lastmod":1424408734,"permalink":"https://blog.johtani.info/blog/2015/02/20/elasticsearch-1-4-4-and-1-3-9-released-ja/","publishdate":"2015-02-20T14:05:34+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.4 and 1.3.9 released 本日（2/20）、Elasticsearch 1.4.","tags":["elasticsearch"],"title":"Elasticsearch 1.4.4および1.3.9リリース（日本語訳）"},{"contents":"来る、4月4日の土曜日の午後に名古屋でElasticsearch勉強会を開催予定です。 「初」の東京以外の勉強会です。\nTwitterでこのようなツイートを見かけまして。\n名古屋でElasticsearchの勉強会やりたい機運（今のところ2人）。\n\u0026mdash; mogami (@smogami) 2015, 2月 4 これは！ということで、名古屋で勉強会をやろうかと思います。30名程度の場所を借りて実施予定です。 募集はいつもの、elasticsearch勉強会のDoorkeeperで行う予定です。 ページの準備まで少々待ちください。（おそらく、3月中旬くらい） 私自身はElasticsearchやELKについて話をしようと思っています。そのほかに、2,3名のスピーカーの方を予定しています。 LTなど興味がある人がいたら、連絡ください。\nこれを機に（？）他の場所でも勉強会を開催したいと考えています。 ニーズがどのくらいありそうなのかが、まだよくわかっていませんが、関西などでニーズがあるんじゃないかと期待していたり。\n興味のある方は、コメント欄、Twitterなどでコンタクトしてもらえればと。 （連絡来るとうれしいなぁ。）\n","date":1424240573,"dir":"post/2015/","id":"5b97ead91c0dd0bad57b4f43a89149a2","lang":"ja","lastmod":1424240573,"permalink":"https://blog.johtani.info/blog/2015/02/18/preparing-elasticsearch-meetup-in-nagoya/","publishdate":"2015-02-18T15:22:53+09:00","summary":"来る、4月4日の土曜日の午後に名古屋でElasticsearch勉強会を開催予定です。 「初」の東京以外の勉強会です。 Twitterでこのよう","tags":["elasticsearch","勉強会"],"title":"名古屋でElasticsearch勉強会を開催します"},{"contents":"第8回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n今回は出足が好調で、早々に180人の枠を超えるという嬉しい事態でしたが、 キャンセル待ちが残っているにもかからわらず、来られていない方が67名もいるということで、キャンセル待ちの方には申し訳なかったです。 もうすこし、キャンセルをしてもらえると嬉しいんですが。。。 今回はメールを当日に1度しか打ってないからかなぁ。\nさて、いつもの通り簡単なメモです。 本当に簡単にですが。\n「Elasticsearch導入チェックリスト？」 Elasticsearch株式会社 Jun Ohtani @johtani スライド：Elasticsearch導入チェックリスト？\nElasticsearchを開発環境や本番に導入する前に気にかけて欲しいことについて発表しました。 元ネタはelasticsearch pre-flight checklistです。 少々古いのですが、私が今回話した内容以外にもモニタリングなどについての話も盛り込まれています。 時間がある方は、見ていただければと。\n「Elasticsearch クエリとスキーマ定義のすごい細かい話」株式会社ドワンゴ 藤堂淳也 さん スライド：Elasticsearch クエリとスキーマ定義のすごい細かい話\nフィールドのチェックを別途インデキシングするアプリで行っている。利用できるものだけElasticsearchに投げる 実際に本番環境で利用しているマッピングに対してフィールドを追加する手順について 「これもドキュメントに書いてあるんですが」という感じでドキュメントに色々書いてあるので読みましょうというありがたい発表でした。 実際に試行錯誤したり検証するときに行ったことを喋ってもらえたので、どういった点を気にしながら運用、設計するかというのがわかりやすかったです。\n「ElasticsearchとKibanaで実現する、30億req/dayのリアルタイム分析」株式会社サイバーエージェント　山田直行さん　@satully スライド：ElasticsearchとKibanaで実現する、30億req/dayのリアルタイム分析\n会場が21時までしか抑えられていないという失態で、ドタバタしてて前半は聞けてないです。。。\n前回の発表では30日分Elasticsearchに入れていたが、今は3日分のみ保存 レポートなどにはRedshift＋Tableauを利用 Kibana3をメインに使っているが、Kibana4も検討予定？ QA\nQ：なぜ、ELBを挟んでいるのか？ A：特に考えておいているわけではない。 Q：インデックスの構成は？ A：1日に2つのインデックス。Bitされたもの、入札されないもの Q：searchのnodeをやめたのは？ A：前回発表した勉強会での懇親会で話を聞いたり、他の方と話を聞いて、不要と判断したため 「はてなのメディア面を支えるElasticsearch」株式会社はてな　山家雄介さん　@yanbe スライド：未定。おそらく、開発者ブログに公開されるかと。\n\u0008* アドテク系にもやってるらしい。BrandSafeはてな\nはてなブックマークのデータを魅せ方を変える機能などで大活躍。B!KUMAとか その日の話題の見出し自動生成機能。Significant Terms Aggregationsを利用。 こちらの「自然言語処理技術を用いたはてなブックマークの新機能「トピック」をベータリリースしました」エントリに関係あるのかな？ 記事の魅せ方を検索できる管理画面ではElasticsearchのクエリDSLを活用されているとのことでした。 検索専門の人でなくても検索式を簡単にくみたてられる画面を用意して、ElasticsearchのクエリDSLに変換するようにしていると。 確かに、クエリをそのまま組み立ててもらうよりも利用しやすい画面がある方がいいですよね。バックエンドはJSとPerlのライブラリとのことでした。\nその他、感想などのブログ 2015-02-13 第8回 elasticsearch 勉強会 @ 丸の内 リクルート 41Fアカデミーホール [Elasticsearch] 第8回 elasticsearch 勉強会へ参加してきた 第8回elasticsearch勉強会 #elasticsearch #elasticsearchjp 第8回 Elasticsearch 勉強会に行ってきた #elasticsearch #elasticsearchjp 勉強会メモ - 第8回elasticsearch勉強会 まとめ 今回も検索からログまでいろんな話になったので、面白かったかと。 参加された方は新しい方が多かったんじゃないかなぁと。（集計結果で見れないのかな、Doorkeeper）。\n今回は、みなさんに21時に41Fから33Fへ移動していただくという大失態があったので、大変申し訳なかったです。 次回（4月中旬）は、このようなことがないように気をつけますので、今後もよろしくお願いいたします。\nあと、東京以外の勉強会も検討しつつあります。興味のある方はコメントやTwitterで反応をいただけると嬉しいです。\nスピーカーは随時募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1424066543,"dir":"post/2015/","id":"997acc135d01b54f7de77a432fb9133f","lang":"ja","lastmod":1424066543,"permalink":"https://blog.johtani.info/blog/2015/02/16/8th-elasticsearch-jp/","publishdate":"2015-02-16T15:02:23+09:00","summary":"第8回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第8回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：running groovy scripts without dynamic scripting\nElasticsearch1.3.8と1.4.3のリリースにより、デフォルトで、リクエストに含まれるGroovyスクリプトや インデックスに保存されたスクリプトを動的に実行する機能をオフにしました。 しかし、Groovyはまだデフォルトのスクリプト言語です。 本ブログ記事では、少しだけダイナミックだが、サンドボックスではない言語のためのスクリプトを どのように使い続けるかを説明します。\n本ブログ記事は、それが何を意味し、さらに重要なのは、安全に重要なタスクを実行させるためにスクリプトを どのように使用し続けるかを理解する助けとなるはずです。\nダイナミックスクリプトとは？ Elasticsearchに詳しくない方のために、Elasticsearchでは、 さまざまなリクエストの一部としてスクリプトを送信することができます。 search、aggregation、update、upsert、delete by queryなどです。 あなたのユースケースのために、通常の動作よりも拡張した動作をさせるためにスクリプトを追加できます。\n例えば、以下のリクエストは、ダイナミックスクリプトを含んでいます。 field1とfield2 + shiftが同じ値を持っている時だけドキュメントを返します。\nGET /_search { \u0026#34;query\u0026#34;:{ \u0026#34;filtered\u0026#34;:{ \u0026#34;filter\u0026#34;:{ \u0026#34;script\u0026#34;:{ \u0026#34;script\u0026#34;:\u0026#34;doc[\u0026#39;field1\u0026#39;].value == (doc[\u0026#39;field2\u0026#39;].value + shift)\u0026#34;, \u0026#34;lang\u0026#34;:\u0026#34;groovy\u0026#34;, \u0026#34;params\u0026#34;:{ \u0026#34;shift\u0026#34;:3 } } } } } } 言語を変えることもできます。 それは、当然、シンタックスが変わったり、制限が追加（例えば、Groovyスクリプトの代わりにLucene　Expressionsに変更）されることもあります。 langパラメータによって言語を指定できます。\nなぜそれはダイナミック？ 上記の例はダイナミックスクリプトです。 それは、実際のスクリプトの部分はサーバサイドで動的に解釈されコンパイルされる必要があるからです。 ダイナミックスクリプトはElasticsearchのAPIによってデータノードに送信されます。 これは、インデックスされたスクリプト(indexed script)も含みます。\n言い換えると、もし、スクリプトがデータノード全てに保存されていなければ、 それは、ダイナミックスクリプトとして扱われます。\ndynamic scriptingをオフにするとどうなるか？ 最新のリリースでの変更により、Groovyのdynaic scriptingはデフォルトでオフになりました。 先ほどのスクリプトについても同様で、もし、先ほどのリクエストを実行すると、次のようなエラーが発生します。 (一部省略してあります。)\n{ \u0026#34;error\u0026#34;:\u0026#34;SearchPhaseExecutionException[Failed to execute phase [query], all shards failed; shardFailures {[8FJ02MofSnqVvOQ10BXxhQ][test][0]: SearchParseException[[test][0]: from[-1],size[-1]: Parse Failure [Failed to parse source [{...}]]]; nested: ScriptException[dynamic scripting for [groovy] disabled]...\u0026#34;, \u0026#34;status\u0026#34;:400 } エラーメッセージの重要な箇所は「ScriptException[dynamic scripting for [groovy] disabled]」です。\nスクリプティングを使い続けるには？ Elasticsearchでスクリプトを実行するには3つの方法があります。 2つのダイナミックな方法は、リクエストごとのスクリプト（上述）かインデックスされた スクリプト(indexed script)を使う方法です。 インデックスされたスクリプトを使うことは、Elasticsearch自身にGroovyスクリプトを保管することで 利用で、それらを要求に応じて利用することです。 （これは、実際には十分機能しますが、これではまだ、信頼できないユーザに対して彼らのスクリプトを実行できます） RDBのように保存されたプロシージャとして同じ方法で実行させるものと同様です。 前もって、スクリプトを記述しておき、リクエストの一部として後から、名前で呼び出して実行可能です。\nGET /_search { \u0026#34;query\u0026#34;:{ \u0026#34;filtered\u0026#34;:{ \u0026#34;filter\u0026#34;:{ \u0026#34;script\u0026#34;:{ \u0026#34;script_id\u0026#34;:\u0026#34;your_custom_script\u0026#34;, \u0026#34;lang\u0026#34;:\u0026#34;groovy\u0026#34;, \u0026#34;params\u0026#34;:{ \u0026#34;shift\u0026#34;:3 } } } } } } あまり変わっていないことに気づくでしょう。 scriptの部分が、前もって記述されたスクリプトの名前script_idに変更されただけです。\nElasticsearchにスクリプトを提供するダイナミックではない方法はインデックスに保存する代わりに、 ディスクにファイルとしてスクリプトを保存することです。 そうすることで、各スクリプトを設定として保存します。 これは、どのようなスクリプト言語に対してもダイナミックスクリプティングをオフにしたまま、 サンドボックス化されないスクリプトを使い続けることができる方法です。\n最初のサンプルで、Groovyスクリプトはdoc['field1'].value == doc['field2'].value + shiftでした。 これを、.groovy拡張子を持ったファイルとして書き出すことができます。\ndoc[\u0026#39;field1\u0026#39;].value == (doc[\u0026#39;field2\u0026#39;].value + shift) もし、このファイルにyour_custom_script.groovyちう名前をつけて、 Elasticsearchのすべてのデータノードのconfig/scriptsディレクトリに保存すると、 Elasticsearchは60秒（elasticsearch.ymlのwatcher.intervalで変更可能）でこのスクリプトを認識し、今後のリクエストに利用できるようにプリコンパイルするでしょう。 そのファイルはElasticsearch実行ユーザによって読み込みができる必要があります。 これをディスクに書き込んだ後、あなたの設定ディレクトリは次のようになっています。\nconfig/ elasticsearch.yml logging.yml scripts/ your_custom_script.groovy これは、各リクエストやインデックスされたスクリプトをスクリプトとして動的に送信しませんが、 信頼された環境にスクリプトを追加することでダイナミックスクリプトとなることを許します。\nディスクに書かれたスクリプトを使用する スクリプトは、ロードされたスクリプトになるまでは、利用できません。 ログファイルに次のようなログが表示されるまではです。\n[2015-02-11 11:14:47,066][INFO ][script ] [Sergei Kravinoff] compiling script file [/path/to/elasticsearch-1.4.3/config/scripts/your_custom_script.groovy] すべてのElasticsearchのデータノードでスクリプトが読み込まれたら、 それを利用することができます。 利用するために、file（script_idではありません！）としてスクリプト名を指定します。\nGET /_search { \u0026#34;query\u0026#34;:{ \u0026#34;filtered\u0026#34;:{ \u0026#34;filter\u0026#34;:{ \u0026#34;script\u0026#34;:{ \u0026#34;file\u0026#34;:\u0026#34;your_custom_script\u0026#34;, \u0026#34;lang\u0026#34;:\u0026#34;groovy\u0026#34;, \u0026#34;params\u0026#34;:{ \u0026#34;shift\u0026#34;:3 } } } } } } Note:langは必須ではありません。Groovyがデフォルトの言語のためです。 もし、違うスクリプト言語を使いたい、もしくは、デフォルトの言語を（例えば、Lucene Expressionsへ） 変更したい場合、言語が正しいスクリプトを見つけるために提供されている必要があります。 一番良い方法は、アプリケーションがlangパラメータを含んでいることを勧めます。 これは、将来、デフォルトのスクリプト言語が変更されても、問題ないからです。\n質問？ もし、質問があれば、遠慮なくTwitter(@elasticsearch)で教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1423721589,"dir":"post/2015/","id":"1fed22e99b0e11a50eb7b92cb1644e8a","lang":"ja","lastmod":1423721589,"permalink":"https://blog.johtani.info/blog/2015/02/12/running-groovy-scripts-without-dynamic-scripting-ja/","publishdate":"2015-02-12T15:13:09+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：running groovy scripts without dynamic scripting Elasticsearch1.3.8と1.4.3のリリースによ","tags":["elasticsearch"],"title":"Groovyスクリプトをダイナミックスクリプトなしで実行(日本語訳)"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch 1.4.3 and 1.3.8 released\n本日、Lucene 4.10.3をベースにしたElasticsearch 1.4.3と、セキュリティとバグフィックスリリースである、Elasticsearch 1.3.8をリリースしました。 ダウンロードおよび変更リストはそれぞれ次のリンクからアクセスできます。\n最新ステーブルリリース：Elasticsearch 1.4.3 1.3.x系バグフィックス：Elasticsearch 1.3.8 過去のリリースに関するブログ（公式）はこちら。\n1.4:1.4.2, 1.4.1, 1.4.0, 1.4.0.Beta1 1.3:1.3.7, 1.3.6, 1.3.5, 1.3.4, 1.3.3, 1.3.2, 1.3.1, 1.3.0. すべての変更については1.4.3のリリースノートおよび1.3.8のリリースノートをごらんください。 以下では、セキュリティの問題について紹介します。\ngroovy scripting の脆弱性 Elasticsearchのバージョン1.3.0から1.3.7および1.4.0から1.4.2で、Groovyスクリプトエンジンに脆弱性が発見されました。 脆弱性は、攻撃者がGroovyスクリプトをサンドボックスを避けて構築でき、 ElasticsearchのJava VMを実行しているユーザとしてシェルコマンドを実行できます。\nこの問題をCVE-2015-1427として報告済みです。\nバージョン1.3.8と1.4.3では、デフォルトで、Groovyに対してのサンドボックスをオフにしました。 結果として、ダイナミックスクリプトの実行はGroovyに対してもオフとなります。\nもし、脆弱性のあるバージョンで実行している場合、v1.3.8かv1.4.3にアップグレードするか、ダイナミックなGroovyスクリプトをクラスタの すべてのノードに対して次の設定を追加することで、オフにします。\nscript.groovy.sandbox.enabled: false これは、Groovyのサンドボックスをオフにし、リクエストの一部としてインラインで受け付けるダイナミックなGroovyスクリプトや 特殊な.scriptsインデックスに保存されているスクリプトを実行しません。\nそれまでは、各データノードのconfig/scriptsディレクトリにファイルとして保存されたGroovyスクリプトは まだ、利用可能です。詳細の情報についてはRunning scripts without dynamic scriptingをごらんください。\nfuture scripting plans 安全なダイナミックスクリプティング言語としてGroovyを失うことは、Elasticsearchにとって痛手です。 update APIやsearch APIやaggregationsフレームワークの一部としてScriptを使います。 それらは、静的なAPIでは簡単に表現できない、カスタムなトリックをユーザに実行できるようにします。\n残念ながら、Groovyチームとこの問題を議論した後、Groovy言語もサンドボックスによってきちんと保護されている というにはあまりにもダイナミックであるという結論に達しました。 Groovyは、デフォルトでは利用できなくなります。 利用可能なダイナミックスクリプト言語としてはLucene Expressions言語のみとなります。 Expressionsははやいですが、それらは非常に限定されています。数値のフィールドでのみ実行可能で、ループをサポートしていません。\nより強力で（しかし安全な）ミニ言語になるようにExpressionsを拡張することを調査しています。 これは、Scriptユーザが現在持っている最も一般的なユースケースを少なくとも助けるでしょう。 この拡張は長期間のプロジェクトであり、進化には時間がかかるでしょう。\nぜひ、Elasticsearch 1.4.3をダウンロードして、試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1423712393,"dir":"post/2015/","id":"5badf61ecb9cfadd7d6af58712fa5f6f","lang":"ja","lastmod":1423712393,"permalink":"https://blog.johtani.info/blog/2015/02/12/elasticsearch-1-4-3-and-1-3-8-released-ja/","publishdate":"2015-02-12T12:39:53+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElas","tags":["elasticsearch"],"title":"Elasticsearch　1.4.3および1.3.8リリース（日本語訳）"},{"contents":"今年もCROSS参加しました。そして、話もしてきました。 今年は横浜の大さん橋でした。横浜はあんまりこないので、乗り換えでおたおたしてしまいましたが。。。\nなかなかいい景色でした。（寒いけど） 「おおさんばし」って読むんですね。「だいさんばし」だと思ってた。。。\n以下はいつもの、自分用メモです。\n俺はどうしてそのデータストアを選択したのか 〜銀河と小宇宙を語る会〜 http://2015.cross-party.com/program/c1\n遅れて入ったので、ちゃんと聴けてないです。\n最近注目しているデータストアは？ Postgresql。JSON型が気になってる。 AiroSpike。データ型のあるデータストアが気になってる。 MongoDB。JSON使いたいなら、これじゃないの？ AWSのAurora。インスタンスタイプを選ばなくていい（選ばないといけないらしい）とか、勝手にスケールしてくれるし、MySQL互換。 今こそ語るエンジニアの幸せな未来 http://2015.cross-party.com/program/x3\n「無職初日です。」 Web系の人？とか質問されて、自分が何系かいつもわからなくなるなぁ。 「働きがいは会社が提供するのか、個人が見つけるのか？」 個人かなぁ。会社がなにをやってるかにもよる気がするかなぁ。 「辞めると伝えると、やりたいようにやれって言われるw」 リモートできるかできないか。 「働きがい」というキーワードが出てると普通は怪しい会社w 今は、働きやすさを高くしないと人が雇えなくなってきている。 欧米のミドルウェアだと、35歳定年説はない。→日本でもそうじゃないですか？ 漫然と進んでるとダメ。→そりゃそうだ。 全文検索エンジン群雄割拠〜あなたが使うべきはどれだ！〜 http://2015.cross-party.com/program/c4\nスライド：https://speakerdeck.com/johtani/elasticsearchfalseshao-jie-tote-zheng-cross-2015\n楽しんでいただけましたでしょうか？ ちょっと話が長くなってしまい、あとの方の時間が少なかった気がしますが。。。\nKibanaのバックエンドとして認識されている人もいたので、検索エンジンですよというのをアピールするいい機会になったので良かったです。 もちろん、Kibanaとの組み合わせも面白いので、少しでも興味をもっていただき、触っていただけたらなぁと。\n話をする機会を用意していただいた、やまかつさん、その他のスピーカーのみなさん、ありがとうございました！。\nElasticsearchに関して何か興味質問などありましたら、気軽にコンタクトしてください。Twitterとかブログコメントなどで。\nプレモルタイム以降 プレモルの写真撮るの忘れてました。。。重要なのに。。。\n美味しくプレモルをいただきながら、何人かの方に声をかけていただき、話をすることができました。 こういう時間がとってあるのがいいですよね。 色々なところでElasticsearchを使っていただいているようで、うれしい限りです。 DMMの方とも話ができたし。\nまとめ 今年はプレモルを飲みに行くだけかなぁと思っていたのですが、話をする人になってました。（おかしいなぁ） 来年もあれば、きっと参加するかなぁと。ではまた来年！\n夜景きれいですね。（端っこに写ってる船は飛鳥IIでした。）\n","date":1422500368,"dir":"post/2015/","id":"fe6ba10cc6c9509b4b22e9d59e029775","lang":"ja","lastmod":1422500368,"permalink":"https://blog.johtani.info/blog/2015/01/29/talk-at-cross2015/","publishdate":"2015-01-29T11:59:28+09:00","summary":"今年もCROSS参加しました。そして、話もしてきました。 今年は横浜の大さん橋でした。横浜はあんまりこないので、乗り換えでおたおたしてしまいま","tags":["勉強会","elasticsearch"],"title":"CROSS 2015で話をしてきました #cross2015"},{"contents":"今年は大晦日になってしまいました。しかも、ちょっと飲んでたり。。。 第9流しながら書いてます。\n振り返り(2013年に書いた抱負から) まずは昨年書いた抱負からの振り返りです。\nElasticsearch勉強会の継続、Solr勉強会の継続＋ミックスした検索勉強会の開催 IDEAのさらなる活用 もっと開発(プラグインとか) AWSをもう少し活用 海外のイベントに行ってみたい 読書と英語を継続 AWS活用できてないです、、、 ミックスした勉強会は、ドタバタしててできませんでした。\nIDEAはさらなる活用までいってるかは不明ですが、最近は隣にとても詳しい人が座っているので色々と教えてもらってます。 開発については、ちょっとずつですが、PR書いたりしてます。\n振り返り(今年あったできごと) 初海外（ベルリンとアムステルダム） Elasticsearchに転職 初献本? Elasticsearch勉強会の定期開催 ElasticSearch Serverの翻訳 サーバ/インフラエンジニア養成読本の執筆 勉強会以外でもスピーカー 英語の継続（切実） 初ものが多かったです。 初の海外の会社、初の海外旅行（仕事）、初の献本（著者の人から、多分、初）、初の翻訳本、初のムック本執筆などなど。\n初の海外でした。なのに、夏には海外の会社に転職してみてるとか、ちょっと自分でも信じられません。 ベルリンでは、海外の勉強会にも参加できて非常に有意義でした。 ヨーロッパの街並みは、日本では経験できない雰囲気で、向こうの方には普通の街並みも自分にはとても新鮮でした。\n転職自体は2回目ですが、海外の会社というのは初めてです。日々、英語\u0008の勉強になりますし、いろんな刺激を受けています。 英語の勉強自体も継続中です。英語力が不足しているのは自覚してるので、少しでも英語に触れるようにDLifeで海外ドラマを録画して、通勤時間帯にみるなどを試みてます。\n書籍には、昨年につづき関わることができました。来年も何かしらの書籍に関われることができればなと。 （\u0008気になる人は以下のリンクから。。。）\n分かりきったことですが、Elasticsearchな1年でした。 転職してあっという間の半年です。まだまだやりたいことがいっぱいあるので、来年もバランスよく頑張らないと。\n来年の抱負 英語の継続 海外のイベントへの参加 多岐にわたるイベントでのスピーカー 日本の人員の倍増！？ Elasticsearchに関する日本語の情報発信 Elasticsearch座談会みたいなものの開催 英語の継続については書くまでもないですね。 海外のイベントへの参加もかなぁ。3月にサンフランシスコに行くとは思います。 そのほかには、今度こそBerlin Buzzwordsに行きたいです。\nElasticsearch勉強会以外のイベントでもElasticsearchを広めるべく色々なところでスピーカーをしたいなと思っています。 検索、ログ解析で少しは知名度が上がってきていますが、別の言語のコミュニティやイベントでは、まだまだ、elasticsearch自体を知らない人もいると思います。まずは知ってもらうところからかなと。\n日本の人員の倍増については、今年も達成してます（一人が二人になりましたw）。 来年も倍増できればうれしいなと。同じ母国語の同僚がいるのはやっぱりうれしいし、心強いですから。\n来年は（も）、日本語での情報をどんどん発信していきます。サイトやガイドなども 日本語にしたいなと。 あとは、これまで、勉強会でスピーカーをしていただいた人だけを集めた座談会のようなものも開催したいなと考えています。 私自身も色々と聞きたいことがありますし。 そのほかにも色々と要望をお待ちしています。Twitterやブログのコメント欄などで気軽にコンタクトしていただければと。\n最後は、いつものようにですが、来年も勉強会やいろんなイベントに参加する予定です。 ブログも週1程度で書く努力しないとなぁ。 こんな話を書いてくださいとかのリクエストもお待ちしています。\n今年はあと、数時間ですが、色々とお世話になりました。 この場を借りてお礼申し上げます。\n来年も、いろんな方に絡んでいくとは思いますが、よろしくお願いいたします。\n","date":1420026086,"dir":"post/2014/","id":"b36abffbe5d6a0de73a9968604a1a3f9","lang":"ja","lastmod":1420026086,"permalink":"https://blog.johtani.info/blog/2014/12/31/looking-back-2014/","publishdate":"2014-12-31T20:41:26+09:00","summary":"今年は大晦日になってしまいました。しかも、ちょっと飲んでたり。。。 第9流しながら書いてます。 振り返り(2013年に書いた抱負から) まずは昨年","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2014）"},{"contents":"この記事はElasticsearch Advent Calndar 2014の25日目のエントリです。\nあっという間に最終日です。来年につなげるという意味で、Elasticsearchの2系のIssueをいくつかピックアップして紹介してみます。\n現在、ElasticsearchのGitHubリポジトリは、大きく3つのブランチで作業しています。 master、1.x、1.4です。masterと1.xの大きな違いとしては、masterはLuceneの5.x系を採用している点です。\nなお、これから紹介するIssueは現在、確定していない項目も含んでいます。実際に2.0がリリースされるタイミングでは 採用されない場合もあります。\nUpgrade master to lucene 5.0 snapshot #8347 (closed) https://github.com/elasticsearch/elasticsearch/pull/8347\n先ほど書きましたが、Luceneの5に対応するためのPRです。 Lucene 5に関してはLuceneのコミッターのMikeさんのブログ記事も参考になります。\nLucene 5に変更することで、BitSetに関する改善が多く含まれることになります。 メモリの利用量、圧縮などの改善が多く含まれています。 もう1点大事な点としては、Lucene 5系ではLucene 3系のインデックスを読み込むことができなくなる点です。 Luceneの下位互換の範囲は1つ前のメジャーバージョン（5.x系の場合は4.xまでが対象）となっています。\nFilter cache: add a _cache: auto option and make it the default.（closed） https://github.com/elasticsearch/elasticsearch/pull/8573\nFilter cacheは、trueもしくはfalseの設定が利用できますが、filterの種類にも依存します。 その辺りの条件を加味しつつ、よしなにCacheをコントロールしてくれます。\nRemove and/or/not in favour of bool filter #8960（open / discuss） https://github.com/elasticsearch/elasticsearch/issues/8960\n似ているが少し異なるand、or、notフィルタとboolフィルタが存在しています。 これらをわかりやすくするために、boolフィルタに統一しましょうという話し合いをしています。\nInput validation #9059（open / discuss） https://github.com/elasticsearch/elasticsearch/issues/9059\n色々な入力に関するチェックを追加しようというIssueです。 たとえば、ディレクトリ名やファイル名、URLのパスやクエリストリング、フィールドのパスやスクリプトなどです。 Validationがあると、変な設定をして頭をかかえることもなくなるかなぁと。\nRefactor analysis framework #8961（open） https://github.com/elasticsearch/elasticsearch/issues/8961\n新しくAnalyzerを作った場合に、色々な場所に登録必要があったりします。インデックスレベルとノードレベルです。（Kuromojiプラグインなどが参考になります。） また、インデックスごとにカスタムのAnalyzerを設定するので、1つのノードに同じAnalyzerを何度も設定しないといけません。 よりシンプルにするために、Analyzerをノード単位で設定しようという提案です。\nRemove possibility for conflicting field definitions and ambiguous field resolution #8870（open） https://github.com/elasticsearch/elasticsearch/issues/8870\n同じインデックスに、異なるtypeで、同じフィールド名があった場合、いろいろと良くないことがあったりします。 たとえば、フィールドのタイプがintegerとstringと異なる場合に、インデックスレベルで検索を行うとうまく検索できなかったりと。 この問題を解消するために、より明確にしようというIssueです。 たとえば、フィールド名を指定するためには、フルパスで記述をするだとか、フィールドマッピングに関してはインデックスレベルで内部で保持をするなど。\nValidation of mappings request to reject unsupported fields #7205（closed） https://github.com/elasticsearch/elasticsearch/issues/7205\n1.xでも取り込まれますが、嬉しい機能なので紹介します。 これまでは、mappingsでスペルミスをした場合（たとえば、field設定で\u0026quot;indexx\u0026quot;といったミス）には、その項目は単に無視されるだけでした。 これが、v1.xでは、エラーに\nまとめ ということで、簡単ですが、v2.0.0に向けたIssueをピックアップして紹介してみました。 上記以外にも多くの改善、提案が2.0に向けて行われています。 興味のある方は、v2.0.0ラベルでIssueを検索してみてはいかがでしょうか？\n今年もあとわずかとなりました。 今年の2月にElasticsearchの1.0がリリースされ、あっという間に1.4なりました。まだまだ改善しています。\n来年もElasticsearchに興味をもっていただければ嬉しいです。 Elasticsearch初のユーザカンファレンスのサイトもオープンしました。 Elasticsearchに関するいろいろな話が聞ける機会だと思います。登録をお待ちしています。\n","date":1419490380,"dir":"post/2014/","id":"cb9649eca3dfbd356527ffc88f1dcb94","lang":"ja","lastmod":1419490380,"permalink":"https://blog.johtani.info/blog/2014/12/25/pickup-elasticsearch-2-0-0-labels/","publishdate":"2014-12-25T15:53:00+09:00","summary":"この記事はElasticsearch Advent Calndar 2014の25日目のエントリです。 あっという間に最終日です。来年につなげるという意味で、Elasti","tags":["elasticsearch"],"title":"Elasticsearch 2.0系のIssueの紹介"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：marvel 1.3.0 released\n12/17に、Elasticsearch Marvel 1.3.0をリリースしました。 Marvelの以前のリリースから、Elasticsearchでは様々なことがありました（Elasticsearch 1.4のリリースなど）。 このバージョンでは、モニタリングにクエリキャッシュや新しいcircuit breakerなどのような機能を追加してあります。 Senseのナレッジベースは最新のAPIを含むものに拡張されています。 また、Shieldのリリースに向けた準備として、HTTPsのサポートも追加しました。\nアップグレードのために、Elasticsearchの全てのノードに最新版のMarvelプラグインをインストールする必要があります。 また、他のJavaプラグインと同様に、Marvelの新バージョンを有効にするために、各ノードを（1台ずつ）リスタートする必要があるでしょう。 アップグレードプロセスについての詳細は、Marvelドキュメントをごらんください。\nまとめとして、ここに本リリースに関する改善点をいかにリストアップしておきます。\nagent 追加： httpsのサポート デフォルトのMarvelの設定（以前は常に9200）ではなく、ローカルノードのポートを自動的に検出 改善： marvelインデックステンプレートに関するエラーチェックと耐障害性(それに対するチェックと追加時のチェック) エラーログに関するくり返しの抑制 URLパラメータによるインデックス名を指定する_bulk exportコマンド。これは、rest.action.multi.allow_explicit_indexがfalseに設定されているときに有用 修正： ES 1.4.0のtribe nodeがMarvelのインストール時に初期化されない問題 削除： UIで表示されないoptional shard level statsを除去 monitoring ui 追加： ES 1.4.0で導入された新しいcircuit breakerを追加 circuit breakerのlimitをグラフにプロット QueryCacheのグラフを追加 index throttlingのグラフの追加 Index writerとバージョンのmapのメモリ使用量のグラフの追加 修正： Network Transport Bytes Receivedグラフに実際の送信量を表示 Node Statsダッシュボードでいくつかのスレッドプールの不足 sense 追加：\nmappingsをインデックスでオートコンプリートするしないの設定を可能に Cluster Reroute API Search APIのQuery Cacheパラメータ Analyze API Validate Query API Put Percolator API cluster.routing.allocation.*設定 Function Scoreクエリのweightパラメータ Flush API Terms Aggregationのshow_term_doc_count_errorパラメータ Update API _geo_distanceソートオプション Significant Terms aggregationを1.4.0にアップデート Mapping APIにメタデータフィールドを追加 Get Index API Scripted Metric Aggregation simple_query_stringクエリ More Like Thisクエリを1.4.0にアップデート has_childクエリ/フィルタのmin_childrenとmax_childrenオプション terms aggs/significant terms aggsのヒントオプション Mappings APIのtransform インデックスされたscriptとtemplate \u0008* Geo Bounds aggregation Top Hits aggregation Terms aggregationのcollect_modeオプション Percentiles Rank aggregation Disk Threshold Allocator設定 修正：\nURLオートコンプリートの挙動（プロトコルとホストのような組み合わせ） nested typeマッピングのinclude_in_parentとinclude_in_rootの不足 Rangeフィルタでのgt、gte、lt、lte Existsフィルタのオートコンプリート Snapshot、Restore APIのリポジトリ設定の時オートコンプリートの失敗 いつものように、Elasticsearch Marvelを改善するために、フィードバックをお待ちしています。 ElasticsearchユーザMLやTwitterに質問や意見お送りください。\n","date":1418890008,"dir":"post/2014/","id":"7dea465ad52758b10cbceb08c81d1760","lang":"ja","lastmod":1418890008,"permalink":"https://blog.johtani.info/blog/2014/12/18/marvel-1-3-0-released-ja/","publishdate":"2014-12-18T17:06:48+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：marvel 1.3.0 released 12/17に、Elasticsearch Marvel 1.3.0をリリースしました","tags":["elasticsearch","marvel"],"title":"Marvel 1.3.0リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch 1.4.3 and 1.3.8 released\n本日、Lucene 4.10.3をベースにしたElasticsearch 1.4.3と、セキュリティフィックスとバグフィックスリリースである、Elasticsearch 1.3.8をリリースしました。 ダウンロードおよび変更リストはそれぞれ次のリンクからアクセスできます。\n最新ステーブルリリース：Elasticsearch 1.4.3 1.3.x系バグフィックス：Elasticsearch 1.3.8 過去のリリースに関するブログ（公式）はこちら。\n1.4:1.4.1, 1.4.0, 1.4.0.Beta1 1.3:1.3.6, 1.3.5, 1.3.4, 1.3.3, 1.3.2, 1.3.1, 1.3.0. すべての変更については1.4.2のリリースノートおよび1.3.7のリリースノートをごらんください。 以下では、重要な変更について紹介します。\nbug fixes Elasticsearchに対して広範囲にわたってランダムなテストを行っています。以下の問題を見つけ、修正するのに役立っています。\nプライマリシャードを持つnodeがレプリカシャードをプライマリから復旧している間に、リスタートした場合に、プライマリ上のトランザクションログが削除されデータをロスする(#8917) scriptインデックスが普及した場合に、ScriptService全体がデッドロック(#8901) Index Writerのロックを強制的に解放することによるシャードの破損(#8892) パフォーマンス改善 複雑な設定をもつ大きめのクラスタをもつユーザは、小さなスケールではわからない性能ボトルネックに直面します。 彼らの報告が次の改善をもたらす助けとなりました。\n使用可能なディスク空間に基づいてシャードの配置を決定する、disk allocation deciderの速度改善とクラスタリスタート後のリカバリ速度の改善(#8803) 以前よりも高速な共有ファイルシステムでのSnapshot生成(#8749) 不要なクラスタ状態変更の削減とそれによるネットワークトラフィックの削減およびリカバリの速度向上(#8933, #8413) index stats APIはシャードリカバリによるブロックしない(#8910) 試してみてください。 ぜひ、Elasticsearch 1.4.2をダウンロードして、試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1418880374,"dir":"post/2014/","id":"bce2fa6458f39a75e2713f3d687271a1","lang":"ja","lastmod":1418880374,"permalink":"https://blog.johtani.info/blog/2014/12/18/elasticsearch-1-4-2-released-ja/","publishdate":"2014-12-18T14:26:14+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElas","tags":["elasticsearch"],"title":"Elasticsearch 1.4.2および1.3.7リリース（日本語訳）"},{"contents":"「【東京】JJUG ナイト・セミナー「機械学習・自然言語処理特集！」12/17（水）開催」でLuceneの話をしてきました。 本当にごく簡単な入門です。 Luceneをさわるきっかけにしてもらえたら嬉しいです。\nそのほかにも面白い話が聞けましたので、簡単ですがメモを。\nJJUGの2014年振り返り だいたい、毎月ナイトセミナーかCCCを開催 イベント系に、のべ3100名が参加 Java でカジュアルにはじめる機械学習 小宮 篤史さん(スマートニュース株式会社) スライド：#JJUG - Java でカジュアルにはじめる機械学習\nブログ：#JJUG ナイトセミナー「機械学習・自然言語処理特集！」で Java でカジュアルに機械学習する話をしてきました\nガチの人は寝ててください。 機械学習でできること 分類・識別 予測・回帰 パターンマイニング・アソシエーションルール クラスタリング 上2つは教師あり学習/下2つは教師なし学習 データとしては、日構造では扱えないので、「特徴量」を抽出して「特徴ベクトル」を作って、処理をするのが機械学習 得られた結果の正しさの測定などなど\n機械学習の実装は辛いので、車輪の再発明をやめましょう！ \u0008Javaで使える機械学習\nWeka：とりあえず使ってみるならこれ？ MLlib：Sparkで使われてる Mahout：オワコン？ SAMOA：Stormの上で利用できる Jubatus：Javaクライアントあり。 h2o：Deep learningをJavaでやるなら、これ。 ほかにもあったけど、スライド見ていただければ。 機械学習をはじめるのに使えるデータセット\nUCI Machine learning repository\nIris（アヤメデータ）は機械学習界のHello world Wekaを使ったサンプルコード\nSpark/MLlibではじめるスケーラブルな機械学習 猿田 浩輔さん(株式会社エヌ・ティ・ティ・データ) スライド：（後日、リンクがあれば更新予定）\n\u0008* Spark+MLlibを語る上で外せない話題\nHadoopとの違い？\nまずはHadoopの話\nHadoopによるK-meansのデモ\nHadoopの問題点に対するSparkの解決策\nSpark 1.0系からJava8で書ける\nQA：\nQ： データをキャッシュできるという話でしたが、キャッシュするということは、ジョブが途中で失敗した場合は最初からやり直しになるのでしょうか？ A： キャッシュしたデータが残っている場合は、途中から再開出来ます。キャッシュしたデータを持ったマシンがこけたら、最初からやり直しです。\nLuceneと日本語の検索 自分 スライド：Luceneと日本語の検索 サンプルのリポジトリ：jjug-example\n自然言語処理にからめて何か話をしてくださいと話を受けていたのですが、自然言語処理については「形態素解析」くらいしか出てこなかったですけど。。。 Luceneがどんなものかを超概要で話をしてみました。少しでもLuceneがどんなものかをわかってもらえたら嬉しいです。\nもっと詳しく知りたい方は、スライドにある参考資料などを見ていただければと。\nJavaで書くのもいいんですが、もっと簡単に検索したい場合はElasticsearchを使うのが便利ですよ！で締めくくりたかったのですが、発表では失敗してしまいました。。。 Elasticsearchの起動からデータ登録、検索まではこちらのスライドを見ていただければ簡単さがわかると思います。\nまた、Kuromojiを利用した時に、Tokenizerなどが出力するTokenの品詞情報を見たい場合に便利なElasticsearch用プラグインも作っています。 こちらも、Elasticsearchと一緒に使ってみてください。\nまとめ 機械学習に関していろんなツールがあるのだなぁと。 懇親会でもちょっと話しましたが、アルゴリズムの選定とか、アルゴリズムに適したデータの作成など、前処理のノウハウとかが大変そうだなぁといつも思います。 機械学習はいつもぼやーっとしか理解してないので。。。\nJJUGさんはYouTubeの動画もあるようなので、過去の面白そうなセミナーも合わせてみてみると面白いと思います。\n毎度のことですが、なんでも良いので、発表した後のフィードバックをいただけるとうれしいです。 今後の励みや改善につながるので。\n","date":1418809314,"dir":"post/2014/","id":"e5390751969ab21df280b7591854b89f","lang":"ja","lastmod":1418809314,"permalink":"https://blog.johtani.info/blog/2014/12/17/jjug-night-seminar-dec-2014/","publishdate":"2014-12-17T18:41:54+09:00","summary":"「【東京】JJUG ナイト・セミナー「機械学習・自然言語処理特集！」12/17（水）開催」でLuceneの話をしてきました。 本当にごく簡単な入","tags":["elasticsearch","jjug"],"title":"JJUG ナイトセミナーでLuceneの簡単な紹介をしてきました。#JJUG"},{"contents":"たまには、他愛のないブログを。\n仕事しながら、コーヒーを飲んでます。\n最近は、サムライズムさんのオフィスに入り浸って仕事してます。 オフィスには、コーヒーミル付きのコーヒーメーカーがあるんです。\n↓こんな感じ（現物は違うけど）\nで、近所のコーヒー問屋で豆を買ってきてます。 そこのマスターに、いつもサジェストされるんです。\n「この豆は、日が経つにつれて、細かく挽いて飲んでください。」\n「この豆は、細かめに挽いて飲むのがオススメです。」\nなどなど。 オススメされるんですが、全自動のコーヒーメーカーは残念ながらここまでやってくれません。\nということで、手動のミルを買ってみました。家でも使えるし。\nちょっと考え事しながらとか、頭の切り替えに、ミルを回すのもいいかなと。 気持ち、美味しいコーヒーな気がします（気のせいかも）\n","date":1418698892,"dir":"post/2014/","id":"05330c3703d0e2c96cfe657ab33f130c","lang":"ja","lastmod":1418698892,"permalink":"https://blog.johtani.info/blog/2014/12/16/a-coffee-break/","publishdate":"2014-12-16T12:01:32+09:00","summary":"たまには、他愛のないブログを。 仕事しながら、コーヒーを飲んでます。 最近は、サムライズムさんのオフィスに入り浸って仕事してます。 オフィスには、","tags":["misc","coffee"],"title":"コーヒーブレイク"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：exciting logstash plugin ecosystem changes\nLogstash 1.5.0 Beta 1(お試しはこちら)のリリースで、 プラグインのインストール、管理、公開の方法を変更しています。 ユーザやコミュニティからフィードバックをもらいました。 その目的は、プラグインの利用や開発をより簡単にすることです。 このプロジェクトは始まったばかりです。プラグインのコミュニティを探し、 共有するためのワンストップソリューションを提供するこのアイデアを改善していく予定です。 このブログで、この決定を行った理由を説明し、新しいワークフローをと今後のロードマップを説明します。\nプラグインがあります！ Logstashは、プラグイン（input、filter、output、codec）が豊富にあります。 これらは、Elasticsearchにより開発されたものと、コミュニティからコントリビュートされたものです。 Logstashの主な特長の1つは、これらのプラグインの有効性と動作を拡張するプラグインを追加するのが簡単なことです。 現在、165以上のプラグインがエコシステムにあり、これらは、2つのプロジェクトに分かれています。\nlogstash-coreは最もよく使われるプラグインで、Logstashにデフォルトで含まれます logstash-contribはコミュニティにより開発されたプラグインを含み、別途ダウンロードできます 新プラグインエコシステムの変更 1.5.0では、全てのプラグインは、Logstashコアから分離され、rubygemsを使って個別にパッケージングされます。 rubygemsを選択したのは、依存関係のあるライブラリの配布とパッケージングがパワフルで一般的なものだからです。 さらに、rubygems.orgプラットフォームは配布や探索に影響があります。 また、Logstashにプラグインをインストール、アップデート、削除するのが簡単な基盤も追加しました。 contribプロジェクトは徐々に終了します。全てのプラグインは個別のプロジェクトになります。\nプラグインエコシステム変更の理由 多数のプラグインをもっていると、配布と公開に関して難題が出てきます。 私たちが変更するに至った理由は次のようなものです。\n現在は、プラグインの更新に伴い、Logstashの新バージョンのリリースが必要 開発者は、Logstashのリリース間隔とは別に、新バージョンをリリースをしたい プラグイン開発者は、外部依存を記述できるようにしたい Logstashコアの配布パッケージのダウンロードサイズを小さくし、ユーザは必要なプラグインのみインストール logstash-contribを1つのリポジトリとして管理するのは難しい 詳細： ソースコードの場所 Logstashのソースコードは、今後も現在のGitHubのリポジトリのままです。 しかし、プラグインに関するコードやテストコードは含まなくなります。 この分離により、個別のプラグインの改善と同様にコアの改善に集中できます。 これにより、Logstashプロジェクトの全体の品質も向上します。\n全プラグインのソースコードは、新しいGitHub organization、logstash-pluginsにて管理します。 各プラグインは個別のリポジトリとして、ここに配置されます。 一見すると、これはメンテナンスが難しくなるように思えます。しかし、テスト、Issue、依存関係を明確にすることができます。 私たちの目的は、テスト、ドキュメント、gemの公開の自動化であり、これを簡単にするためのツールを追加します。\nしかし、プラグインの開発者はプラグインのソースコードソースコードをlogstash-pluginsに置く必要はありません。 ー コミュニティで利用可能にするために、rubygems.orgでそれを公開するだけで良いです。\nワークフロー ここで、新プラグインエコシステムのやりとり/ワークフローについて、いくつかの観点から説明します。\nlogstashユーザ: ユーザは、これまでのリリース同様にLogstashのバイナリをダウンロードします。 Logstash 1.5.0は、1.4.2でパッケージされていたプラグインと同等のものが含まれています。 新しいシステムに簡単に移行できるようにです。 そして、ユーザは、最初のデプロイの後に、Logstashプラグインのをインストール、アップグレードできるようになります。\n$LS_HOME/bin/pluginスクリプトがプラグイン操作に関連するコマンドになります。\nプラグインのインストール プラグインのほとんどはgemとしてrubygems.orgにアップロードされます。 例えば、もしユーザがApache Kafka outputプラグインをインストールする場合、次のコマンドを実行します。\nbin/plugin install logstash-output-kafka または、ファイルをダウンロード済みの場合は次のコマンドとなります。\nbin/plugin install /path/to/logstash-output-kafka-1.0.0.gem プラグインの削除 bin/plugin uninstall logstash-output-kafka 1つまた全プラグインのアップデート bin/plugin update bin/plugin update logstash-output-kafka プラグインのリストアップ bin/plugin list bin/plugin list elasticsearch ( List all plugins containing a name ) bin/plugin list --group output ( list all outputs ) ドキュメント プラグインが個別に管理されても、全プラグインのドキュメントは1カ所です。\nlogstash plugin開発者: プラグイン開発者と作者は、Logstashエコシステムのためにプラグインを公開することができます。 プラグインは、gemやJavaライブラリの依存関係を宣言できます。 より重要なのは、Logstashのリリース間隔に関係なく、プラグインの改善版をリリースできます。\nRubygemsテクノロジはパッケージングシステム、依存関係管理、ホスティングのために選択されてきました。 Rubyのgemを公開することに慣れている開発者は、Logstashプラグインを簡単に公開することができます。 Elasticsearchはこれらの機能に関して開発者を支援するために、ツールを提供、メンテナンスします。\n開発およびローカルでのテスト JRuby 1.7.16がプラグインを開発するための唯一の前提条件です。 プラグインにパッチを提供するのは以前と同様です。 例えば、logstash-output-kafkaにパッチを送るのは次のようになります。\ngit clone https://github.com/logstash-plugins/logstash-output-kafka.git 変更 プラグインをローカルでテスト bundle install bundle exec rspec Logstashの他のバージョンもしくはローカルでテストする場合、Gemfileを編集し、 次のように別のロケーションを加えます。gem \u0026quot;logstash\u0026quot;, :github =\u0026gt; \u0026quot;elasticsearch/logstash\u0026quot;, :ref =\u0026gt; \u0026quot;master\u0026quot; 新しいPull Requestをlogstash-output-kafkaに対して作成 コミュニティでコードレビューを受け、Elasticsearchがパッチを受け入れ バージョン バージョン情報は、それぞれのプラグインの.gemspecで管理します。 例えば、Apache Kafka outputのgemspecはこちらです。 バージョニングはsemantic versioningのルールに従い、 Logstashのバージョニングとは別に、プラグインの開発者によって管理されます。 Logstash 1.5.0がリリースされると、マイルストーン1のプラグインはバージョン1.0.0となり、マイルストーン2のプラグインはバージョン2.0.0となるでしょう。\n公開 開発者が変更を加えプラグインを公開したいと思った時、.gemspecのバージョン番号を変更します。 全テストが成功した時、Elasticsearchはrubygems.orgにプラグインを手動で公開します。 もし、テストが失敗した場合、プラグインは公開されません。 長期的には、プラグインの公開の自動化を行いたいと思っています。 この変更は新しいため、公開の自動化を提供する前に、自動化についてより理解し、プラグインのテスト基盤を改良したいと思っています。\nIssue Issueは、各プラグインのGitHubリポジトリに対してオープンなければなりません。 Logstashコアのリポジトリは、コアのパイプラインや共通的な機能に関連するIssueについて扱います。\nドキュメント プラグインのドキュメントはソースコード自体から生成されます。 それぞれのプラグインのドキュメントは、そのプラグインのリポジトリに含まれます。 Elasticsearchは elasticsearch.org/guideに全てのプラグインのドキュメントを集め生成できる基盤を提供します。\n移行 全ての新しいpull requestとissueはlogstash-plugin organisation配下にある各プラグインのリポジトリに対してオープンする必要があります。\nすでにあるPRはどうすれば良いですか？ 気にしないでください。すでにあるpull requestは開発者によって移行する必要はありません。 LogstashチームがLogstashコアリポジトリに対してのPRを、個別の関連するプラグインのリポジトリに対してマージします。\ngit clone … # clone the specific plugin repo # now apply the patch curl -s https://github.com/elasticsearch/logstash/pull/XXXX | git am --3way git push Note:このプロセスはすでにあるPRに対してgit historyを管理します\nGitHub Issue 現在、LogstashリポジトリにオープンされているIssueは、それぞれのプラグインのリポジトリに移行します。 Logstashチームがgithub.com APIを利用してこの処理を自動的に行います。 安心してください。私たちが個別のプラグインに対する既存のIssueを移行します。\n今後のロードマップ これは、最初のステップであり、これらの変更は、ユーザや開発者に対してエコシステムをよりよくするために、 しっかりとした基盤を提供します。\n短期的には、開発者のためにpull requestのフィードバックでテスト自動化を提供する基盤を追加していきます。 プラグインリポジトリのブートストラップや管理のためのツールも提供していきます。\n長期的には、すべてのLogstashプラグインを探し、公開するためのコミュニティポータルを提供したいと思っています。 このアイデアは、Puppet ForgeやAWS marketplaceのようなものです。\nLogstash 1.5.0 Beta 1をリリースし、これは新しいエコシステムを提供します。 ぜひ、試していただき、これらの変更に関して感じたことを教えてください。 あなたのフィードバック(TwitterもしくはGitHub)はとても貴重です！\n","date":1418486440,"dir":"post/2014/","id":"4a3c42c9c5ac29db268010bbebf4f579","lang":"ja","lastmod":1418486440,"permalink":"https://blog.johtani.info/blog/2014/12/14/plugin-ecosystem-changes/","publishdate":"2014-12-14T01:00:40+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：exciting logstash plugin ecosystem changes Logstash 1.5.0 Beta 1(お試しはこちら)のリリースで、 プラグインのインストー","tags":["logstash"],"title":"Logstashプラグインのエコシステムの変更（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：logstash 1.5.0.beta1 released\nLogstash 1.5.0 Beta1をリリースしました。こちらのページからダウンロードできます。\nNote: ベータリリースです。本番環境では使用しないでください。\n1.5.0の主な変更点は？ 1.5.0の主なテーマはプラグイン管理、パフォーマンス改善、Apache Kafkaインテグレーションです。Logstashの主な特徴の1つは プラグインを利用できることであり、パイプラインの動作を拡張するためにプラグインを追加するのが簡単なことです。 このリリースで、プラグインの開発、管理、公開がより簡単になります。 また、Logstashの速度をより良くしたため、より多くのデータを短時間に処理することができます。 興味ありませんか？では、詳細を見ていきましょう。\nplugin ecosystemの変更 Logstashは165ものプラグイン(inputs、filters、outputs、codecs)を持っており、 これらはElasticsearchとコミュニティからのコントリビュートで開発されています。 多くのプラグインを管理することは、使いやすさと素早さの間のトレードオフがあります。 Logstashの全てのプラグインをまとめることは使いやすさがある一方、プラグインの更新を取り込むために Logstashの新しいリリースを待ってもらうことになります。 Logstashからプラグインを分離して個別に配布する場合、更新は簡単になりますが、使いやすさ（特に新しいユーザに）に影響が出ます。\n私たちは、プロジェクトを前進させるために、これらのバランスをとることを考えました。 これまで、全ての利用可能なプラグインは’core’と\u0026rsquo;contrib\u0026rsquo;の2つに分割していました。 \u0026lsquo;core\u0026rsquo;にあるよく使われるプラグインは、Logstashに含めていました。 コミュニティによりコントリビュートされたプラグインは\u0026rsquo;contrib\u0026rsquo;パッケージとして分離して配布していました。 1.5.0のリリースで、ユーザに対してより良いプラグイン管理をできるように変更しました。 全てのプラグインは、それ自身によるパッケージに移行しました。 パッケージングフレームワークとしてrubygemsを使い、rubygem.org経由でこれらのプラグインを配布、公開します。 また、Logstashにプラグインのインストール、更新、削除を簡単にするための構造も追加しました。\n例えば、S3 output pluginをインストールするには、以下のコマンドを実行します。\n$LS_HOME/bin/plugin install logstash-output-s3 それだけです！Logstashがgemと依存するgemをrubygems.orgからダウンロードし、インストールします。 あなたは、S3にデータを送ることができるようになります。\nダウンロード可能なLogstashリリースはプラグインをまだ多く含んでいますが、 いつでも、個別にプラグインをアップグレードし、インストールすることができます。 プラグインエコシステムの変更に関する詳細のブログ記事をお待ち下さい。\nパフォーマンス改善 Logstash 1.5.0はより高速になっています。パフォーマンスが改善された2カ所について説明します。\ngrok filter Grok filterはLogstashで、構造化データを抽出するためにパターンを記述するのに使われます。 本リリースで、人気のある幾つかのパターンのgrok filterのスループットを100%に改善しました。 言い換えると、grok filterを使うときに、Logstashを通してより多くのデータを処理することができます。\n私たちのベンチマークテストで、1.5.0と1.4.2のスループットの比較をしました。 利用したデータは690万件のApache Webアクセスlogで、COMBINEDAPACHELOGのgrok patternです。 1.5.0で、スループットは34,000 event per sec(eps)から50,000 epsに増加しました。 両方のテストを8コアのマシンでLogstashで8つのワーカーを実行しました。 これらのテストで、一つのgrok filterを実行し、 stdinとstdoutを使ったパイプラインでイベントのスループットを計測しました。 全体的なパフォーマンスは、様々なハードウェアやLogstashのコンフィグによって変化することに注意してください。\njson serialization / deserialization JSONのシリアライズ/でシリアライズをJrJacksonライブラリを利用して実装しました。 これにより、100%以上のスループットの改善がありました。 先ほど説明したパフォーマンステストにおいて、1.3KBのサイズの500,00 JSONイベントを送信し、 16,000 epsから30,000 epsにスループットが改善しました。 45,000サイズのイベントで、850 epsから3500 epsにスループットが増加しました。 すばらしいです。\napache kafka integration いまでは、Apache Kafkaが大規模スケールデータ処理システムでよく利用されます。 Logstashの配備のスケーリングにおいて、Kafkaもまた、shippingインスタンスとindexingインスタンス間の データを保存するための中間メッセージバッファとして使うことができます。\n1.5.0で、Logstash Kafkaのinputとoutputのプラグインのビルトインサポートを追加しました。 これは、Joseph Lawsonによって最初に開発されました。 私たちは、これらのプラグインにインテグレーションテストとドキュメントを追加することにより改良し、 新しいKafkaの機能を開発し続けます。 また、Apache Avro codecを追加することで、Kafkaに保存されたイベントを 簡単に取得でき、ELKスタックを使ってそれらを解析できるようにしました。\nKafka inputを追加するのは次のコマンドです。\n$LS_HOME/bin/plugin install logstash-input-kafka Kafka outputは次のコマンドです。\n$LS_HOME/bin/plugin install logstash-output-kafka セキュリティに関する改善 認証と経路暗号化のサポートを追加し、Elasticsearchのoutput、input、filterのセキュリティを改良しました。 例えば、HTTPプロトコルでSSL/TLSにより暗号化を有効にでき、 HTTPベーシック認証をユーザ名とパスワードをリクエストに与えることで設定できます。 これらの機能は、時期にリリースされるElasticsearch ShieldセキュリティプロダクトとLogstashを統合できます。\nドキュメント これまで、Logstashのドキュメントは[logstash.net])(http://logstash.net/)に置いてあり、 他のELKスタックと一緒に動かす時に、情報を探すのが厄介でした。 1.5.0および、今後のバージョンのドキュメントはelasticsearch.orgのLogstash Guideに移行します。 この移行でelasticsearch.org/guideにELKスタックを利用、 学習するためにドキュメントが1つになりました。 このベータリリースのイテレーションで、私たちはプレゼンテーションとドキュメントの品質を改善することに活発に取り組んでいきます。 (過去のLogstashのドキュメントの全てはいままでのlogstash.netで引き続き公開していく予定です。)\nバグフィックスと改善 ここまでの新しい機能に加えて、Logstash 1.5.0では、多くのバグフィックスと多くの機能改善があります。 ここで、これらのいくつかを紹介します。\n出力しない\u0026rsquo;metadata\u0026rsquo;をイベントに格納可能に。これは、例えば、date filterに使う中間フィールドのために必要。(#1834, #LOGSTASH-1798) HTTPを利用しているときのファイルデスクリプタリークの修正。Logstashがストールするのを防ぎ、OOMエラーからクラッシュするケースも防ぎます。(#1604) Twitter input:full_tweetオプションの追加、Twitter rate limitingエラーのハンドリング(#1471) イベントを生成するfilter(multiline、clone、split、metrics)により、 後続の条件文にこれらのイベントを正しく伝搬(#1431) Elasticsearch output:Logstashはデフォルトでmessage.rawフィールドを作成しない。messageフィールドはElasticsearch によりnot_analyzedでマルチフィールドとして追加される。マルチフィールドはディスクスペースが2倍必要だが、利点がない。 bin/logstashの複数のサブコマンドを除去(#1797) これらの機能、改善、バグフィックスについては、Logstash 1.5.0.Beta1 のchangelogをごらんください。\n試してみてください！ ぜひ、Logstash 1.5.0 Beta 1をダウンロードして試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1418372246,"dir":"post/2014/","id":"1bc36080b2493aab78c26e4f2152542c","lang":"ja","lastmod":1418372246,"permalink":"https://blog.johtani.info/blog/2014/12/12/logstash-1-5-0-beta1-released-ja/","publishdate":"2014-12-12T17:17:26+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：logstash 1.5.0.beta1 released Logstash 1.5.0 Beta1をリリースしました。こちらのページからダウンロードで","tags":["logstash"],"title":"Logstash 1.5.0 Beta1リリース(日本語訳)"},{"contents":"早いもので、師走です。今年もあと少しとなりました。ということで、Advent Calendarの季節が始まりました。\nこの記事はElasticsearch Advent Calndar 2014の1日目のエントリです。\n1日目ということで、簡単に今年の変遷を振り返りつつ、今年導入された新機能についてピックアップしてみようかと思います。\n1.0リリース(Lucene 4.6.0) 今年一番の目玉と思いますが、1月にRCが公開されて、1.0.0が2月にリリースされました。 （ElasticSearch Serverの翻訳が昨年末に終わってレビューをしていた段階での発表だったので個人的にはきついタイミングでした） 1.0の主な変更点はこちら。\nElasticsearch（Sが小文字に） 1.0からSが小文字になりました。(#4634) 0.90以前のバージョンについては、Sが大文字になっています。 ややこしいですが、今年の3月に出版された黒いElasticSearch Server日本語版は原著が0.20で日本語版にするタイミングで0.90に対応しました。 このため、こちらの書籍のタイトルはSが大文字となっています。 （なお、原著の2nd Editionは小文字になっています）\nSnapshot/Restoreの導入とGatewayの廃止 0.90以前のバージョンでは、gatewayというモジュールで、S3などにインデックスのメタデータなどを保存する機能がありました。 この機能は、0.20からlocal以外はdeprecatedとなりました。\nインデックスのバックアップ、リストアのために、1.0で実装されたのがSnapshot/Restoreです。 Snapshot/Restoreでは、インデックスごと、もしくはクラスタ全体をリモートにあるリポジトリにスナップショットを取ることが可能となりました。 初期リリースの段階では、共有ファイルシステムのみでしたが、現在は、S3やHDFSなどに保存が可能となっています。\nAggregation Facetをより強力にしたものです。Facetでは、指定したフィールドの集計のみでした。 データの解析などを行うには、独自で集計する必要がありました。 この機能をより柔軟に行えるように実装したのがAggregationです。\nたとえば、アクセスログを日毎に集計し、さらに日毎の集計に対して国別の集計やユーザエージェントごとの集計をさらに行うといった感じです。 Facetの場合は、日毎の検索結果に対して個別に集計するのみでしたが、Aggregationを使うことで、1週間の検索結果に対して、 日毎に国別の集計を行うといったことが可能になっっています。\ncat API \u0026ldquo;=^.^=\u0026ldquo;猫が出てくるAPIです。(違う)\nElasticsearchでは、クラスタの状態などが全てREST APIで取得でき、JSONで結果が帰ってきていました。 JSONはプログラムなどで処理を行う場合は便利ですが、コンソールで確認したり、管理系のツールでメールで通知する場合などは見にくいことがあります。 これを解消したのが_cat APIです。（公式の紹介ブログはこちら）\nCircuit Breaker OOMが発生しそうなfielddataの読み込みを検知して、事前に防ぐ機構になります。 初期段階ではFielddataに対してのものから実装されました。\n1.1リリース(Lucene 4.6.1) 3月にリリースされました。Elasticsearchはまだまだ発展しているため、リリースのサイクルが短いのが特徴です。\n1.x系では、Rolling Upgradeが導入されました。このため、クラスタ全体を停止することなく、クラスタのアップグレードが可能になりました。\nsearch templates 検索クエリをテンプレートとして登録することができるsearch templatesです。 JSONでクエリを記述できるのは便利ですが、毎回組み立てるのは大変かもしれません。 特に、固定のクエリをプログラムから利用するような場合などです。 テンプレートとして登録しておくことで、検索時に値を埋め込むだけで検索ができるようになりました。\nAggregationの強化 Aggregationの種類が増えました。\ncardinality：ユニークユーザ数の集計などが行えるaggregationです。HyperLogLog++アルゴリズムを利用した実装になっています。 significant_terms：単語の数による集計ではなく、コレクション全体に対する単語の頻度と、検索結果に対する単語の頻度を計算することで、重要度を計ることができます。 percentiles：パーセンタイル値を計算できます。 1.2リリース(Lucene 4.8系) Java 7必須 利用しているLuceneがJava 7必須となったためです。また、Java 6のEOLも切れてますし。\ndynamic scriptingがデフォルトオフ 採用していたMVELがサンドボックス化に対応していないため、危険を回避するためにオフとなりました。\nインデキシングとマージング インデキシングとマージ処理に関するさまざまな改善。\nflushのthreasholdを操作回数ではなく、サイズや時間によるものに変更 デフォルトをConcurrentMergeSchedulerに変更 1.3リリース(Lucene 4.9.0系) セキュリティ関連 JSONPのデフォルトオフ MVELの非推奨化（1.4で削除）＋script.disable_dynamicのデフォルト値がsandbox aggregationの強化 top hits：Field Collapsing/combiningと呼ばれる機能です。たとえば、いくつかのサイトのHTMLを収集して検索機能を提供する場合に、ドメインごとに1件ずつ検索結果に出したい場合などに利用できる機能です。 その他にも以下のaggregationが追加されています。\npercentile ranks geo bounds mappingのtransform Mappingにtransform機能が追加されました。 mappingにドキュメントの値を元に、インデキシング時に変換処理を記述できます。 たとえば、特定のフィールドにある値がある場合にだけ、あるフィールドに値を入れるなどといったことが可能になります。\nディスク関連 disk based shard allocation deciderが導入されました。ノードのディスクの使用率を元に、シャードを配置しても良いかといった決定を行う機構です。 チェックサムによるファイルのチェック（Lucene4.9で導入されたコードへの切り替え） 1.4リリース(Lucene 4.10系) ベータ版が出されるほど、多くの改善が入っています。\nresiliency メモリ使用量の低下によるノードの安定性向上 DocValues、リクエストごとのcircuit breakerなど discoveryアルゴリズムの改善によるクラスタの安定性向上 チェックサムの導入による破損したデータの検知 セキュリティ関連 CORSをデフォルト無効 Groovyがデフォルトのスクリプト言語に。 Aggregationの強化 以下のaggregationが追加されています。\nfilter、children、scripted_metric Upgrade API インデックスを最新のバージョンのものにアップグレードするためのAPIです。 Luceneは下位互換を保ってくれているため、古いバージョンのインデックスも読み込むことが可能です。 ただ、最新バージョンで使える機能が制限されていたりということもあります。 クラスタにあるインデックスをアップグレードするのにかかる時間や必要かどうかといったことを取得できる仕組みも提供します。\nまた、Lucene自体は、1つ前のメジャーバージョン（4.x系だと3.x系まで）までの互換性は提供していますが、 2つ前のメジャーバージョンの互換性がなくなります。 Luceneも5.x系のブランチが作成されており、5系のリリースにより、3系との互換性がなくなります。 5系のリリースに対応する場合にも、こちらのAPIが助けになるかと。\n1.4.1 11\u0008/27に1.4.1がリリースされました。 シャードの配置やparent/child、nestedドキュメントの改善などが行われています。\nまとめ ということで、駆け足で、1月から11月までのElasticsearchの流れを追ってみました。 1.0で大きな機能追加、改善が行われ、その後も活発に開発が行われています。 要望などがあれば、MLで聞いてみたりやGitHubに登録するなどを行っていただければと。\nあと、今年から来年にかけての大きなイベントとして、 Elasticsearch初のユーザカンファレンスのサイトがオープンしました。 Elasticsearchに関するいろいろな話が聞ける機会だと思うので、興味のある方は見ていただければと。\nでは、また次のAdvent Calendarで！（最終日の予定ですが、空きがあるのでなにか書くかも）\n","date":1417424748,"dir":"post/2014/","id":"2de582c67fca31500621ecd6d3917a07","lang":"ja","lastmod":1417424748,"permalink":"https://blog.johtani.info/blog/2014/12/01/about-elasticsearch-in-2014/","publishdate":"2014-12-01T18:05:48+09:00","summary":"早いもので、師走です。今年もあと少しとなりました。ということで、Advent Calendarの季節が始まりました。 この記事はElastics","tags":["elasticsearch"],"title":"2014年のElasticsearch"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch 1.4.1 and 1.3.6 released\n本日、Lucene 4.10.2をベースにしたElasticsearch 1.4.1と、バグフィックスリリースである、Elasticsearch 1.3.6をリリースしました。 ダウンロードおよび変更リストはそれぞれ次のリンクからアクセスできます。\n最新ステーブルリリース：Elasticsearch 1.4.1 1.3.x系バグフィックス：Elasticsearch 1.3.6 過去のリリースに関するブログ（公式）はこちら。\n1.4:1.4.0, 1.4.0.Beta1 1.3:1.3.5, 1.3.4, 1.3.3, 1.3.2, 1.3.1, 1.3.0. すべての変更については1.4.1のリリースノートおよび1.3.6のリリースノートをごらんください。 以下では、重要な変更について紹介します。\nshard allocation Elasticsearch 1.3.0で、disk based shard allocationが デフォルトで有効になっています。 もし、ノードのディスクの使用量がlawで指定された値（85%）を超えた場合、ノードにはシャードが配置されません。 また、highで指定された値（90%）を超えた場合、シャードを他のノードへ移動します。\nElasticsearch 1.4.1では、disk based shard allocationに3つの改良が追加されました。\nディスク使用量のチェックはシャードがクラスタに配置されるタイミングでのみ実施していた。現在は60秒ごとに使用量をチェック。(#8270) ディスクフルメッセージはDEBUGレベルでログに出力されていました。なぜ、新しいシャードが配置されないのかを説明するのが困難でした。現在はWARNレベルで30秒ごとにログに出力されます。(#8382) 以前は、シャードをもう一つのノードへ動かすべきかどうか決めるとき、allocation deciderはノードにあるシャードのサイズを考慮するだけでした。現在は、動かされるシャードのサイズも考慮します。これにより、必要最小限のシャードの移動量となります。(#8569) parent/child and nested documents Elasticsearch 1.4.0で、parent/childとnestedドキュメントに対して（新しいセグメントを開くときに）固定長ビットセットフィルタを構築しキャッシュしました。クエリ、フィルタおよびAggregationを常に速くするためにです。 多くのnestedフィールドを持つユーザにとっては、以前のバージョンよりもヒープの使用量が大きくなってしまいました。\nnested aggregationによって処理されるドキュメントの順序を変更すること(#8454)によって、固定長ビットセットフィルタが子のドキュメントに対して必要でなくなりました。 現在は、親のドキュメント（つまり、nestedではないドキュメント）を表すフィルタのみをキャッシュしています。これにより必要なキャッシュ空間のサイズを減少しました。(#8414、#8440)\ndate ranges 2つの日付範囲に関する問題がこのリリースで修正されました。 1つ目は、日付を丸めるかというものです。例えば、timestampフィールドに1秒の解像度の値があるとします。 {\u0026quot;lt\u0026quot;: \u0026quot;2014/11/26||/d\u0026quot;}というrangeフィルタは2014/11/26 00:00:00未満のタイムスタンプのデータを結果として返しました。 しかし、ltをlteに変更した場合、2014/11/27 00:00:00以外の値も含めたいです。\n以前は、lteは2014/11/27 00:00:00のタイムスタンプも含めてしまっていました。現在は、想定通りの動作をします。(#8556)\n2つ目のバグは日付の範囲条件にnow()を利用したaliasとpercolatorフィルタです。 now()の値を、フィルタが作成したタイミングで決定していました。フィルタが実行されるたびに更新せずにです。 #8534で、now()はaliasとpercolatorで想定通りの動作をします。\n試してみてください。 ぜひ、Elasticsearch 1.4.1をダウンロードして、試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1417056212,"dir":"post/2014/","id":"0a8183ced0e9e3e895b41286e54e8e4d","lang":"ja","lastmod":1417056212,"permalink":"https://blog.johtani.info/blog/2014/11/27/elasticsearch-1-4-1-released-ja/","publishdate":"2014-11-27T11:43:32+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.1 and 1.3.6 released 本日、Lucene 4.10.2をベースにしたElas","tags":["elasticsearch"],"title":"Elasticsearch 1.4.1および1.3.6リリース（日本語訳）"},{"contents":"前回の「Logstashを利用したApacheアクセスログのインポート」の続きです。 前回の記事では、Logstashの設定ファイルについて説明しました。 今回は「Elasticsearchに設定するインデックステンプレート」について説明します。\nテンプレートの設定 Elasticsearchでは、登録するデータの特性に合わせてMappingを定義する方がデータを効率良く扱うことができる場合があります。 この場合、通常ですと、インデックス作成時にMappingを指定します。\nただ、今回は、インデックス名に「年」を含める形で指定してあります。 「年」はLogstashで処理したデータによって決まります。このため、あらかじめMappingを指定してインデックスを作成するのは難しいです。\nこのような場合に便利な機能として、「インデックステンプレート」があります。\nインデックステンプレートとは 実際のテンプレートの説明に入る前に、少しだけ説明を。 インデックステンプレートとは、インデックスが作成されるタイミングで自動的に適用される設定をテンプレートとして登録できる機能のことです。 実際にテンプレートが適用されるかどうかは、インデックス名で判断されます。\n例えば、大して重要でもなく、データ量も少ないインデックス用のテンプレートとして、シャード数が1、レプリカ数が0、\u0026quot;_source\u0026quot;を保存しない設定のテンプレートを登録する場合、 次のようになります。\ncurl -XPUT localhost:9200/_template/template_1 -d \u0026#39; { \u0026#34;template\u0026#34; : \u0026#34;te*\u0026#34;, \u0026#34;settings\u0026#34; : { \u0026#34;number_of_shards\u0026#34; : 1, \u0026#34;number_of_replicas\u0026#34; : 0 }, \u0026#34;mappings\u0026#34; : { \u0026#34;type1\u0026#34; : { \u0026#34;_source\u0026#34; : { \u0026#34;enabled\u0026#34; : false } } } } \u0026#39; _templateがインデックステンプレートを登録するためのエンドポイントです。 template_1がこのテンプレートのIDです。削除などについては、このIDを利用します。\nそして、重要なのは、\u0026quot;template\u0026ldquo;の設定です。 \u0026ldquo;template\u0026ldquo;には、このテンプレートが適用されるべきインデックス名を記載します。 上記サンプルではte*となっているため、teで始まる名前のインデックスを作成した場合にテンプレートにある設定が適用されます。\n今回利用するテンプレート 私がJJUG CCCや第7回Elasticsearch勉強会のKibana4のデモで利用したインデックスのテンプレートは次のものになります。 \u0026ldquo;template\u0026ldquo;には、前回の記事で紹介したoutput/elasticsearchの設定 に合致するnew_demo_access_log-*を指定しています。\ncurl -XPUT localhost:9200/_template/new_access_log_for_demo -d \u0026#39; { \u0026#34;template\u0026#34;: \u0026#34;new_demo_access_log-*\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;number_of_shards\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;number_of_replicas\u0026#34;: \u0026#34;0\u0026#34; }, \u0026#34;mappings\u0026#34;: { \u0026#34;_default_\u0026#34;: { \u0026#34;dynamic_templates\u0026#34;: [ { \u0026#34;string_template\u0026#34;: { \u0026#34;mapping\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;match_mapping_type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;match\u0026#34;: \u0026#34;*\u0026#34; } } ], \u0026#34;properties\u0026#34;: { \u0026#34;path\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;multi_field\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;no_analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;referer\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;multi_field\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;no_analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;agent\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;multi_field\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;no_analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;geoip\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;object\u0026#34;, \u0026#34;properties\u0026#34;: { \u0026#34;location\u0026#34;: { \u0026#34;geohash\u0026#34;: true, \u0026#34;geohash_precision\u0026#34;: 10, \u0026#34;type\u0026#34;: \u0026#34;geo_point\u0026#34;, \u0026#34;lat_lon\u0026#34;: true, \u0026#34;geohash_prefix\u0026#34;: true } } }, \u0026#34;response\u0026#34;: { \u0026#34;copy_to\u0026#34;: \u0026#34;response_int\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;bytes\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;response_int\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;integer\u0026#34; } } } } } \u0026#39; settings設定 デモ用であり、手元で2台のノードを起動するということもあり、number_of_shardsに2を、number_of_replicasに0を指定してあります。\nmappings設定 インデックスのタイプ Mappingsの指定は通常、特定のタイプを指定します。 今回のデモでは、1種類しかないのですが、タイプ名を特に意識しないために、_default_を使用しました。 この場合、任意のタイプに適用されることとなります。 タイプを指定してMappingの設定を行う場合は_default_の部分に特定のタイプ名を記入します。\n\u0026#34;mappings\u0026#34;: { \u0026#34;_default_\u0026#34;: { ... ダイナミックテンプレート 次はダイナミックテンプレートです。 インデックステンプレートはインデックスの設定をテンプレート化しました。ダイナミックテンプレートはフィールドに対してテンプレートを設定できます。\n以下のダイナミックテンプレートでは、stringタイプのフィールドのデフォルト設定を変更しています。 通常、stringタイプのフィールドはanalyzedとなりますが、not_analyzedに変更してあります。 詳しく検索したいフィールドの方が少ないためです。\n... \u0026#34;dynamic_templates\u0026#34;: [ { \u0026#34;string_template\u0026#34;: { \u0026#34;mapping\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;match_mapping_type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;match\u0026#34;: \u0026#34;*\u0026#34; } } ], ... multi_field指定 検索もしたいし、Terms Aggregationでも利用したいフィールドについては、multi_fieldを利用して、 analyzedとnot_analyzedの2種類のフィールドを用意しています。 multi_field設定を用いることで、1つのJSONのデータから、異なる形のフィールドを用意することが可能です。\n今回のテンプレートでは、path、referer、agentにmulti_fieldを指定しました。\n... \u0026#34;path\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;multi_field\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;no_analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, ... 例えば、上記の設定の場合、入力のJSONはpathというデータのみですが、インデックス上にはpath.no_analyzedと path.analyzedというフィールドができあがります。 実際に検索する場合は、path.analyzed:検索したい文字列という形で検索をすることで、いわゆる部分一致のような検索が可能です。 また、完全一致をしたい場合はpath.no_analyzed:検索したい文字列という指定になります。 用途を考えると、requestも指定したほうが良いかもしれません。\ngeoip Logstashでgeoipデータを付与していました。 このgeoipのデータをKibana4で利用するために、geoデータとして登録する必要があります。\n\u0026#34;geoip\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;object\u0026#34;, \u0026#34;properties\u0026#34;: { \u0026#34;location\u0026#34;: { \u0026#34;geohash\u0026#34;: true, \u0026#34;geohash_precision\u0026#34;: 10, \u0026#34;type\u0026#34;: \u0026#34;geo_point\u0026#34;, \u0026#34;lat_lon\u0026#34;: true, \u0026#34;geohash_prefix\u0026#34;: true } } }, 上記の設定がgeoデータの指定です。 typeにobjectが指定してありますが、これは、geoipのデータがネストしているためです。 geoipオブジェクトのうち、緯度経度のデータはlocationに入っているため、こちらに緯度経度関係の設定を指定します。\n\u0026quot;type\u0026quot;: \u0026quot;geo_point\u0026quot;：geo_pointタイプであることを指定 \u0026quot;geohash\u0026quot;: true：緯度経度のデータをもとに、geohashの値もインデックス \u0026quot;geohash_precision\u0026quot;: 10：geohashの精度の指定 \u0026quot;lat_lon\u0026quot;: true：緯度経度を個別の.lat、.lonというフィールドにもインデックス \u0026quot;geohash_prefix\u0026quot;: true：該当するgeohashのみでなく、その親にあたるgeohashについてもインデックスする response、response_int、bytes 最後は、response、response_int、bytesです。\nresponseには、HTTPステータスコードが入ります。 文字列としても扱いたいですが、integerとして、Renge Aggregationなどを行いたいので、 response_intというフィールドにも値を入れています。 multi_fieldでも可能ですが、ここでは、copy_toを利用しました。 copy_toを用いることで、異なるフィールドに値をコピーすることができます。\nbytesについては、longで扱いたいとういう理由だけです。\n\u0026#34;response\u0026#34;: { \u0026#34;copy_to\u0026#34;: \u0026#34;response_int\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;bytes\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;response_int\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;integer\u0026#34; } まとめ 今回はデモに利用したインデックスてプレートについて説明しました。 前回の、Logstashの設定とこのインデックステンプレートを用いることで、Kibanaで解析するデータの準備ができます。 実際の操作などについては、また次回の記事で説明しようかと思います。\n不明な点、誤植などありましたら、コメント欄へお願いします。\n","date":1416900346,"dir":"post/2014/","id":"4d8f5e581eee602c7fd21da8eb68df9a","lang":"ja","lastmod":1416900346,"permalink":"https://blog.johtani.info/blog/2014/11/25/import-apache-accesslog-using-logstash-2/","publishdate":"2014-11-25T16:25:46+09:00","summary":"前回の「Logstashを利用したApacheアクセスログのインポート」の続きです。 前回の記事では、Logstashの設定ファイルについて説","tags":["logstash","kibana","elasticsearch"],"title":"インデックステンプレートとLogstash"},{"contents":"JJUG CCCや第7回Elasticsearch勉強会のKibana4のデモにアクセスログを利用しました。\nただ、セッションでは、どうやってElasticsearchに投入したのかという詳しい話をしていませんでした。 本記事では、データ取り込み時に利用したLogstashの設定ファイルについて説明します。\nLogstashの設定の説明に入る前に、全体の流れを。 「ApacheアクセスログをKibana4により可視化」です。\n材料の準備 「ApacheアクセスログをKibana4により可視化」に必要な材料は次の通りです。 （今回は起動するところまでいかないので、実際に必要なのは次回以降になります。）\nJava 7（u55以上を1つ） Logstash 1.4.2（1つ） Elasticsearch 1.4.0（1つ） Kibana4 Beta2（1つ） Apacheのアクセスログ（適量） Apacheのアクセスログ以外は、公式サイトからダウンロードできます。 それぞれをダウンロードして、起動できるようにしておきましょう。\n※1台のマシン上で行う場合は、アクセスログの量を少なめにするなどの対策をとりましょう。 ※今回は、1台のマシン（Mac）上で、VMなどを利用せず、それぞれ直接起動するものとします。\n可視化の手順と流れ 可視化の流れとしては、\nLogstashでファイルを読み込み、各種処理（パースしたり、情報を追加したり、切り出したり） Elasticsearchに保存 Kibanaでグラフを作ったり、検索してみたり です。\n今回は、1のLogstashでファイルを読み込んだりする設定ファイルの説明です。\nLogstashの設定 Logstashの基本 まずは、Logstashの設定ですが、簡単にLogstashの説明を。 Logstashは大きく3つのパーツに分かれています。\ninput：データの入力処理 filter：inputで読み込んだデータに対する操作など output：データの出力処理 inputでデータを読み込み（複数可）、filterでデータに対して各種処理を行い、outputでデータを指定されたところに出力（複数可）します。\nアクセスログの読み込み設定 アクセスログの読み込み処理は大まかに次のようなものとなります。\nアクセスログを読み込む（input/file） 読み取ったアクセスログを各フィールド（IPアドレス、ユーザエージェントなど）に分割（filter/grok） 日付のパース（filter/date） クライアントIPアドレスにgeoipの情報を付加（filter/geoip） リクエストのパスの第1階層の抽出（filter/grok） ユーザエージェントのパース（filter/useragent） Elasticsearchへの出力（output/elasticsearch） 設定ファイルは次のようなものになります。\ninput { file { path =\u0026gt; \u0026#34;/Users/johtani/demo_access_log/*/*.log\u0026#34; start_position =\u0026gt; \u0026#34;beginning\u0026#34; } } filter { grok { match =\u0026gt; { \u0026#34;message\u0026#34; =\u0026gt; \u0026#34;%{COMBINEDAPACHELOG}\u0026#34; } break_on_match =\u0026gt; false tag_on_failure =\u0026gt; [\u0026#34;_message_parse_failure\u0026#34;] } date { match =\u0026gt; [\u0026#34;timestamp\u0026#34;, \u0026#34;dd/MMM/YYYY:HH:mm:ss Z\u0026#34;] locale =\u0026gt; en } geoip { source =\u0026gt; [\u0026#34;clientip\u0026#34;] } grok { match =\u0026gt; { \u0026#34;request\u0026#34; =\u0026gt; \u0026#34;^/%{WORD:first_path}/%{GREEDYDATA}$\u0026#34; } tag_on_failure =\u0026gt; [\u0026#34;_request_parse_failure\u0026#34;] } useragent { source =\u0026gt; \u0026#34;agent\u0026#34; target =\u0026gt; \u0026#34;useragent\u0026#34; } } output { elasticsearch { host =\u0026gt; \u0026#34;localhost\u0026#34; index =\u0026gt; \u0026#34;new_demo_access_log-%{year}\u0026#34; cluster =\u0026gt; \u0026#34;demo_cluster\u0026#34; protocol =\u0026gt; \u0026#34;http\u0026#34; } } 1. アクセスログを読み込む（input/file） inputのfileモジュール(a)を使用してアクセスログのファイルを読み込みます。 pathでアクセスログのファイルのパスを指定します。 今回利用したアクセスログはdemo_access_log/2010/access20100201.logといった日毎のファイルに分割されていたため、 *を利用してファイルのパスを指定しました。 また、今回は既存のファイルの読み込みだけのため、start_positionにbeginningを指定してあります。 デフォルトではendが指定されるため、Logstashを起動後に追記されたログから対象になってしまうためです。 その他の設定については、公式ガイドをご覧ください。\ninput { file { # a path =\u0026gt; \u0026#34;/Users/johtani/demo_access_log/*/*.log\u0026#34; # b start_position =\u0026gt; \u0026#34;beginning\u0026#34; # c } } Logstashでは、ファイルをどこまで読み込んだかという情報を保持するために、sincedbを利用しています。 設定変更後に同じファイルを最初から読み込みたい場合などは、こちらのファイルを一旦削除するなどの対応が必要です。\nちなみに、読み込んだデータは次のようなJSONになっています。\n{ \u0026#34;message\u0026#34;: \u0026#34;読み込んだアクセスログ\u0026#34;, \u0026#34;@version\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;@timestamp\u0026#34;:\u0026#34;2014-11-21T06:16:21.644Z\u0026#34;, \u0026#34;host\u0026#34;:\u0026#34;jupiter.local\u0026#34;, \u0026#34;path\u0026#34;:\u0026#34;/Users/johtani/demo_access_log/2010/access20100201.log\u0026#34;} } 特に指定がない場合は、messageに読み込んだデータが入ってきます。 @timestampがLogstashが読み込んだ時刻、hostはLogstashが動作しているホスト名です。 pathはfileモジュールが読み込んだファイルのパスを設定しています。 この後の処理で、どこの項目に対して処理を行うかといったことが重要になるので、\n2. 読み取ったアクセスログを各フィールド（IPアドレス、ユーザエージェントなど）に分割（filter/grok） 2.〜6.の処理は、inputで読み込んだ1アクセスログに対する処理となります。\nここでは、grokフィルタを使用して Apacheのアクセスログを各フィールドに分割します。 Logastashでは、簡単に使えるようにいくつかのパターンが用意されています。 Apacheのログのために、COMBINEDAPACHELOGというのが用意されています。 今回はこちらを使用しています。その他にも日付などパターンが用意されているので、試してみてください。\nmessageにアクセスログが入っているので、こちらの項目に対してCOMBINEDAPACHELOGのパターンを matchで適用してフィールドに抜き出します。 tag_on_failureは、matchでパースに失敗した場合に、tagというフィールドに指定した文字列を出力する機能になります。 デフォルトだと_grokparsefailureが付与されますが、ここでは、どの処理で失敗したがを判別するために文字列を変更しています。\nfilter { grok { match =\u0026gt; { \u0026#34;message\u0026#34; =\u0026gt; \u0026#34;%{COMBINEDAPACHELOG}\u0026#34; } break_on_match =\u0026gt; false tag_on_failure =\u0026gt; [\u0026#34;_message_parse_failure\u0026#34;] } ... clientip、ident、auth、timestamp、verb、request、httpversion、response、bytes、referrer、agentがgrokフィルタにより抜き出された項目です。\n{ \u0026#34;message\u0026#34;:\u0026#34;アクセスログ\u0026#34;, \u0026#34;@version\u0026#34;:\u0026#34;1\u0026#34;, \u0026#34;@timestamp\u0026#34;:\u0026#34;2014-11-21T07:20:54.387Z\u0026#34;, \u0026#34;host\u0026#34;:\u0026#34;jupiter.local\u0026#34;, \u0026#34;path\u0026#34;:\u0026#34;/Users/johtani/demo_access_log/2010/access20100201.log\u0026#34;, \u0026#34;clientip\u0026#34;:\u0026#34;クライアントのIPアドレス\u0026#34;, \u0026#34;ident\u0026#34;:\u0026#34;-\u0026#34;, \u0026#34;auth\u0026#34;:\u0026#34;-\u0026#34;, \u0026#34;timestamp\u0026#34;:\u0026#34;01/Feb/2010:00:00:26 +0900\u0026#34;, \u0026#34;verb\u0026#34;:\u0026#34;GET\u0026#34;, \u0026#34;request\u0026#34;:\u0026#34;/images/favicon.ico\u0026#34;, \u0026#34;httpversion\u0026#34;:\u0026#34;1.1\u0026#34;, \u0026#34;response\u0026#34;:\u0026#34;200\u0026#34;, \u0026#34;bytes\u0026#34;:\u0026#34;318\u0026#34;, \u0026#34;referrer\u0026#34;:\u0026#34;\\\u0026#34;-\\\u0026#34;\u0026#34;, \u0026#34;agent\u0026#34;:\u0026#34;\\\u0026#34;Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)\\\u0026#34;\u0026#34; } 3. 日付のパース（filter/date） Logstashは特に指定がない場合、inputでデータを取り出した日付が@timestampとなります。 そして、このフィールドが特に指定がない場合は、Elasticsearchのデータの日付となり、Kibanaで利用する日付となります。\nリアルタイムにアクセスログを読み込む場合は、読み込んだ日時でもほぼ問題はありませんが、過去データの場合はそうもいきません。 そこで、dateフィルタを使用して、@timestampの値を書き換えます。\ndate { match =\u0026gt; [\u0026#34;timestamp\u0026#34;, \u0026#34;dd/MMM/YYYY:HH:mm:ss Z\u0026#34;] locale =\u0026gt; en } 上記では、timestampという項目に対してdd/MMM/YYYY:HH:mm:ss Zという日付パターンの場合に値を書き換える設定となります。 なお、日付の月の部分がFebとなっているため、localeにenを指定しています。Logstashが動作するマシンのlocaleがjaなどの場合にパースに失敗するためです。\n4. クライアントIPアドレスにgeoipの情報を付加（filter/geoip） どの国からのアクセスかなどを判別したいので、IPアドレスを元にgeoipを利用してより詳細な情報を付与します。 Logstashでもこの機能が用意されており、簡単に利用ができます。\ngeoip { source =\u0026gt; [\u0026#34;clientip\u0026#34;] } これだけです。対象とするIPアドレスのフィールドを指定しているだけです。 geoipというフィールドが追加され、次のような情報が付与されます。 国名、緯度経度、タイムゾーンなどです。\n{ ... \u0026#34;geoip\u0026#34;: { \u0026#34;ip\u0026#34;: \u0026#34;IPアドレス\u0026#34;, \u0026#34;country_code2\u0026#34;: \u0026#34;JP\u0026#34;, \u0026#34;country_code3\u0026#34;: \u0026#34;JPN\u0026#34;, \u0026#34;country_name\u0026#34;: \u0026#34;Japan\u0026#34;, \u0026#34;continent_code\u0026#34;: \u0026#34;AS\u0026#34;, \u0026#34;latitude\u0026#34;: 36, \u0026#34;longitude\u0026#34;: 138, \u0026#34;timezone\u0026#34;: \u0026#34;Asia/Tokyo\u0026#34;, \u0026#34;location\u0026#34;: [ 138, 36 ] } ... } 5. リクエストのパスの第1階層の抽出（filter/grok） リクエストされたURLはrequestフィールドにありますが、個別のURLだと、大まかな集計が大変です。 もちろん、クエリで処理することもできますが、Logstashで処理するついでに、第1階層のディレクトリ名を抽出しておくことで、 検索や集計を行いやすくしておきます。\ngrok { match =\u0026gt; { \u0026#34;request\u0026#34; =\u0026gt; \u0026#34;^/%{WORD:first_path}/%{GREEDYDATA}$\u0026#34; } tag_on_failure =\u0026gt; [\u0026#34;_request_parse_failure\u0026#34;] } また、grokフィルタの登場です。 今回は、WORD:first_pathという記述方法で、WORDパターンにマッチした文字列をfirst_pathというフィールドに展開する指定をしています。\n例えば、サイトのスクリプトなどがscriptsというディレクトリにある場合は、first_pathの値を利用して、 後続のフィルタでログデータを出力しないといった処理にも使えます。\n6. ユーザエージェントのパース（filter/useragent） Logstashではユーザエージェントの文字列から、いくつかの情報を付与するフィルタも用意されています。 useragentフィルタです。\nuseragent { source =\u0026gt; \u0026#34;agent\u0026#34; target =\u0026gt; \u0026#34;useragent\u0026#34; } agentというフィールドにユーザエージェントの文字列があるので、このフィールドに対してフィルタを適用します。 元の文字列も取っておきたいので、useragentという別のフィールドに出力するように指定してあります。\n\u0026#34;useragent\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;Firefox\u0026#34;, \u0026#34;os\u0026#34;: \u0026#34;Windows XP\u0026#34;, \u0026#34;os_name\u0026#34;: \u0026#34;Windows XP\u0026#34;, \u0026#34;device\u0026#34;: \u0026#34;Other\u0026#34;, \u0026#34;major\u0026#34;: \u0026#34;17\u0026#34;, \u0026#34;minor\u0026#34;: \u0026#34;0\u0026#34; }, このように、OS名やバージョン名などが抽出できます。\n7. Elasticsearchへの出力（output/elasticsearch） 最後は、Elasticsearchへのデータの出力設定です。\nindexにて、出力するindex名を指定してあります。 また、年毎のインデックス名にするために%{year}を利用しています。 sprintf formatです。\nelasticsearch { host =\u0026gt; \u0026#34;localhost\u0026#34; index =\u0026gt; \u0026#34;new_demo_access_log-%{year}\u0026#34; cluster =\u0026gt; \u0026#34;demo_cluster\u0026#34; protocol =\u0026gt; \u0026#34;http\u0026#34; } まとめ ということで、今回はアクセスログをLogstashにて読み込む時の設定について説明してきました。 次回は、実際にLogstashを起動してElasticsearchにデータを登録するところまでを説明します。\nJJUG CCCや勉強会のデモに用いたデータは、 Elasticsearchにデータを登録する前にテンプレートも設定してありました。こちらについても、次回説明しようと思います。\n不明な点、誤植などありましたら、コメント欄へお願いします。\n","date":1416558639,"dir":"post/2014/","id":"937a597a8b399fd32caba88a3c1c7bc4","lang":"ja","lastmod":1416558639,"permalink":"https://blog.johtani.info/blog/2014/11/21/import-apache-accesslog-using-logstash/","publishdate":"2014-11-21T17:30:39+09:00","summary":"JJUG CCCや第7回Elasticsearch勉強会のKibana4のデモにアクセスログを利用しました。 ただ、セッションでは、どうやってElas","tags":["logstash","kibana","elasticsearch"],"title":"Logstashを利用したApacheアクセスログのインポート"},{"contents":"第7回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n昨日も紹介しましたが、Elasticsearch Advent Calendar 2014を用意してみました。まだ、空きがありますので、登録お待ちしております！\n今回は出足が好調で、早々に180人の枠を超えるという嬉しい事態でした。 最終的な参加人数は130名程度で、懇親会参加者が50名弱といったところです。\n「Kibana4」 Elasticsearch Inc. Jun Ohtani @johtani スライド：Kibana4\nということで、Kibana4の紹介と、Kibana4のBeta2を利用したデモを行いました。 デモの開始のところで少し環境がうまく動いてなくて手間取ってしまいましたが。。。\n発表で1点だけ修正があります。JRubyを選択しているのがElasticsearchのライブラリを使用するためという説明をしましたが、 こちらは、Logstashに関する話でした。Kibana4は現時点では、ElasticsearchへのProxyとしての動作が主なものとなります。Rubyでも動作可能です。 bin/kibanaについてはJavaを使った起動になります。 参考：https://github.com/elasticsearch/kibana/tree/master/src/server\n発表でも主張しましたが、ダウンロードして、Elasticsearchを用意すれば簡単に動作させることが可能です。 ぜひ、ローカルで試して見てもらえればと思います。 今回のデモのデータを入れるのに利用したLogstashの設定などについては、ブログで記事を書こうと思います。\nniconicoの検索を支えるElasticsearch 株式会社ドワンゴ 伊藤 祥 さん スライド：niconicoの検索を支えるElasticsearch\nリアルタイム検索の実現、新しい検索への対応 検索のアーキテクチャとか。 Capistranoでデプロイとかを管理 1.4.1が出たら、クラスタを更新予定 ということで、実際に導入した話から、現在の運用の仕方、クラスタのアップグレードなど多岐にわたる内容でおもしろかったです。 遭遇した問題点とかもあったので。 Marvel便利なのでぜひ導入を検討してもらえればw\nElasticsearch at CrowdWorks\u2028株式会社クラウドワークス 九岡 佑介 さん @mumoshu スライド：Elasticsearch at CrowdWorks\n会社の紹介 仕事が検索対象 検索時間が1桁減少！ Graceful Degradationで失敗したら、InnoDB FTSで代替：Gracefully found.noのサービスを利用 elasticsearch-modelの拡張を作成してOSSとして公開：elasticsearch-model-extensions Gracefullyで切り替えとかは面白いなと思いました。 検索での利用の話でしたが、他のシーンでも使えそうですよね。 日本にFoundユーザがいるのも初めて知りました。 彼らの開発者ブログも質の良い情報が載っているので、参考になりますよね。\n次は、どんなMappingで運用しているのかとか、どういった工夫をしているかといった点を詳しく聞きたいなと思いました。 またお待ちしております。\n1分で作るElasticsearchプラグイン 株式会社エヌツーエスエム 菅谷 信介 さん スライド：Elasticsearchプラグインの作り方\n\u0008\u0008* プラグインの作り方とか。\n十数個のプラグインの紹介。プラグインはこちらで公開中。https://github.com/codelibs/ 実際に、業務で必要なものから作成 まだまだ作りたいものがある コミュニティ還元できるものはPR送ってもらえるとうれしいです。 前よりは体制も増えてるので、PRも目にとまるようになってるはずです。\nあとは、使ってみたいと思う方も多数いると思うので、ぜひ、OSSなので、貢献しましょう！ フィードバックがあるだけで、OSS活動やってるものにとってはやる気につながると思いますし。\nLT：GISとして活用するElasticsearch\u2028船戸 隆さん スライド：GISとして活用するElasticsearch\u2028java-jaからIngressの青（Registance）の勧誘に来られた方w APIをハックして、情報を取得し、Kibanaで可視化 残念ながら、APIが変更されて見れなくなったらしい。 Ingress実際にやったことはないのですが、おもしろそうでした。 発表される方の会社の採用紹介ではなく、Ingressの勧誘をされるとは想定外でしたw\n興味のあるデータをKibanaで可視化するのも面白い例だと思うので、活用してもらえればと思います。\nその他、感想などのブログ 適当に見つけたブログを列挙してあります。これもあるよ！などあれば、教えてください。\n勉強会メモ - 第7回elasticsearch勉強会 第7回elasticsearch勉強会 #elasticsearch #elasticsearchjp まとめ JJUGの時とは違い、Elasticsearch勉強会ではさすがに、企業としてのElasticsearchの知名度が高かったのはありがたいことでした。 自分の発表のために始めた勉強会でもありますが、まだまだ、発表するときは緊張しますし、分かりにくいんじゃないかなぁと思うことも多々あります。 この辺がわかりにくかった、この辺をもっと知りたいなど、フィードバックをお待ちしております。\n冒頭にも書きましたが、Elasticsearch Advent Calendar 2014の登録をお待ちしております。どんなことでも歓迎なので、Elasticsearch、Kibana、Logstashなどについて書いてもらえるとうれしいです。\n次回ももちろん2ヶ月後くらいに行います。 スピーカー募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1416363547,"dir":"post/2014/","id":"2a8412aa50d07330f1298f0243fa79d3","lang":"ja","lastmod":1416363547,"permalink":"https://blog.johtani.info/blog/2014/11/19/hold-on-7th-elasticsearch-jp/","publishdate":"2014-11-19T11:19:07+09:00","summary":"第7回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第7回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch-1.4.0 and 1.3.5 released\n本日、Lucene 4.10.2をベースにしたElasticsearch 1.4.0と、バグフィックスリリースである、Elasticsearch 1.3.5をリリースしました。 ダウンロードおよび変更リストはそれぞれ次のリンクからアクセスできます。\n最新ステーブルリリース：Elasticsearch 1.4.0 1.3.x系バグフィックス：Elasticsearch 1.3.5 1.3ブランチに関する過去のリリースについてのブログは次のとおりです：1.3.4, 1.3.3, 1.3.2, 1.3.1, 1.3.0.\nBeta1リリースでも言及しましたが、1.4.0の主なテーマは*resiliency(復元性、弾力性)*です。 Elasticsearchをより安定し信頼性のあるものにし、メモリ管理を改善し、ディスカバリアルゴリズムを改善し、破損したデータの検知を改善しました。 Beta1リリースからのハイライトも含んでいます。\nDoc values (インデックス時にディスクに保存されるfielddata)がヒープ利用率を激減 Request circuit breaker: メモリを消費しすぎる検索リクエストの中断 Bloom filterのデフォルト無効、高速なインデキシングのためにもはや必要とされないため。 ノードディスカバリ、シャードリカバリの数多くのバグフィックス及び改善 データ破損の早期検知のためのチェックサムのさらなる利用 GroovyをMVELの代わりにデフォルトスクリプト言語に CORSをデフォルト無効に。XSS攻撃防止の為。 クエリキャッシュ、変更されていないシャードからすぐにaggregation結果を返す 新しいAggregation：filter(ドキュメント)、children(ドキュメント)、scripted_metric(ドキュメント) 新しいGET /indexAPI。インデックスのsettings、mappings、warmers、aliasesを1回のリクエストで返却(ドキュメント) 自動付与ドキュメントIDのためのFlake ID。プライマリキーの探索パフォーマンスの改善。 ドキュメントに変更のない更新によるドキュメントの再インデックスの防止 function_scoreクエリの関数でweightパラメータによる個別の改善を可能に。(ドキュメント) 詳細については1.4.0.Beta1のブログ(英語)(日本語訳)をご覧ください。\nBeta1以降の1.4.0の変更の全てについては、1.4.0 release notesでご覧いただけます。 以下では、2つの主な変更について紹介します。\nHTTP Pipelining HTTP pipeliningは複数のリクエストを1回のコネクションで、関連するレスポンスを待つことなく送信することができます。 そして、レスポンスは、受け取ったリクエストと同じ順序で返却されます。 HTTP/1.1の仕様で、pipeliningのサポートが必要です。ElasticsearchはHTTP/1.1であるとしてきましたが、pipeliningはサポートしていませんでした。この問題は.NETユーザで問題を引き起こしました。\n現在、HTTP pipeliningは公式にサポート済みで、デフォルトで利用できます。#8299をご覧ください。\nUpgrade API Luceneのすべてのリリースではバグフィックスや最適化が提供されます。しかし、多くのユーザは古いバージョンのLuceneで作成されたインデックスを持っており、より最新の改善による利点を利用できないことがあります。 新しいupgradeAPIは、あなたのインデックスすべてもしくは一部を最新のLuceneフォーマットに透過的にアップグレードできます。\nGET _upgradeリクエストは、インデックスのアップグレードが必要かどうかを提示し、アップグレードに必要なセグメントのサイズをリポートすることによって、どのくらいの時間が必要かの目安を提供します。 POST _upgradeコマンドはバックグラウンドでインデックスを最新のLuceneフォーマットに書き換えます。\nより詳しい情報はupgradeAPIドキュメントをご覧ください。\n試してみてください。 Beta1リリースを利用し、経験・体験を報告していただいたベータテスターの方々に感謝します。 1.4.0がこれまでの最高のリリースになると確信しています。 ぜひ、Elasticsearch 1.4.0をダウンロードして、試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1415205033,"dir":"post/2014/","id":"d266a2023c67b7a20c3bd01055b223bc","lang":"ja","lastmod":1415205033,"permalink":"https://blog.johtani.info/blog/2014/11/06/elasticsearch-1-4-0-ja/","publishdate":"2014-11-06T01:30:33+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch-1.4.0 and 1.3.5 released 本日、Lucene 4.10.2をベースにし","tags":["elasticsearch"],"title":"Elasticsearch 1.4.0および1.3.5リリース（日本語訳）"},{"contents":"久しぶりに翻訳ではないブログを。書こうと思いながらかけてなかったので。。。\n今回はvalidate APIの紹介です。\n背景 ElasticsearchのクエリはQuery DSLというJSONで クエリを定義できるものを提供しています。 これは、様々なクエリ、フィルタを定義するために必要です。\n自分の望んでいる条件を記述するために、JSONのネストと格闘することも必要となります。。。 また、クエリ、フィルタには様々なパラメータが用意されています。 これらのパラメータをすべて覚えるのは無理でしょうし、タイプミスなどもありますよね。 タイプミスやカッコのミスマッチなどで格闘して1時間が経過してしまったなどもあると思います。\nそんな時に便利なAPIとして用意されているのがvalidate APIです。\n利用方法 APIが用意されています。\nhttp://ホスト名:ポート番号/インデックス名/タイプ名/_validate/query インデックス名やタイプ名は省略可能ですが、マッピングが異なると思うので、タイプ名まで指定するほうが良いと思います。 上記のAPIに対してクエリを送信するだけです。\nクエリの確認 たとえば、こちらのGistにあるようなマッピングのインデックスに対して 検索クエリを組み立てていて、エラーが出るとします。 ※このクエリはmatch_allのところをmatch_alと、lが1文字足りないクエリになっています。\n検索クエリのリクエスト（エラーあり）\nGET pref_aggs/_search { \u0026#34;query\u0026#34;: { \u0026#34;match_al\u0026#34;: {} } } 実行結果のレスポンス\n{ \u0026#34;error\u0026#34;: \u0026#34;SearchPhaseExecutionException[Failed to execute phase [query], all shards failed; shardFailures {[rwkb01chTZq2V7FD0Tlwrw][pref_aggs][0]: SearchParseException[[pref_aggs][0]: from[-1],size[-1]: Parse Failure [Failed to parse source [{\\n \\\u0026#34;query\\\u0026#34;: {\\n \\\u0026#34;match_al\\\u0026#34;: { }\\n }\\n}\\n]]]; nested: QueryParsingException[[pref_aggs] No query registered for [match_al]]; }{[rwkb01chTZq2V7FD0Tlwrw][pref_aggs][1]: SearchParseException[[pref_aggs][1]: from[-1],size[-1]: Parse Failure [Failed to parse source [{\\n \\\u0026#34;query\\\u0026#34;: {\\n \\\u0026#34;match_al\\\u0026#34;: { }\\n }\\n}\\n]]]; nested: QueryParsingException[[pref_aggs] No query registered for [match_al]]; }]\u0026#34;, \u0026#34;status\u0026#34;: 400 } とこんなかんじで、エラーが帰っては来るのですが、非常に読みづらいです。\nそこで、validate APIを利用します。 リクエスト先を/_searchから/_validate/queryに変更します。\nvalidate API\nGET pref_aggs/_validate/query { \u0026#34;query\u0026#34;: { \u0026#34;match_al\u0026#34;: {} } } validate APIのレスポンス\n{ \u0026#34;valid\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 } } すると、非常にシンプルな結果が返ってきます。 \u0026quot;valid\u0026quot;: falseとなっているため、クエリに問題があることがわかります。\nエラーの詳細 問題がある事自体はわかりましたが、エラーの内容も知りたいですよね？ その場合は、explainというパラメータを追加します。 （正しくはexplain=trueを追加しますが、=trueを省略可能です。）\nvalidate API(explainあり、クエリ自体は省略)\nGET pref_aggs/_validate/query?explain {...} validate APIのレスポンス\n{ \u0026#34;valid\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;explanations\u0026#34;: [ { \u0026#34;index\u0026#34;: \u0026#34;pref_aggs\u0026#34;, \u0026#34;valid\u0026#34;: false, \u0026#34;error\u0026#34;: \u0026#34;org.elasticsearch.index.query.QueryParsingException: [pref_aggs] No query registered for [match_al]\u0026#34; } ] } explanationsという項目が追加されました。 ここにerrorという項目として、エラーの詳細が返ってきます。_searchの時よりも見やすいですね。 今回のエラーは、match_allが正しいクエリですの、match_alというクエリは登録されていないというエラーでした。 では、クエリを修正して実行しましょう。\nvalidate API(エラー無し)\nGET pref_aggs/_validate/query?explain { \u0026#34;query\u0026#34;: { \u0026#34;match_all\u0026#34;: {} } } validate APIのレスポンス\n{ \u0026#34;valid\u0026#34;: true, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;explanations\u0026#34;: [ { \u0026#34;index\u0026#34;: \u0026#34;pref_aggs\u0026#34;, \u0026#34;valid\u0026#34;: true, \u0026#34;explanation\u0026#34;: \u0026#34;ConstantScore(*:*)\u0026#34; } ] } 今度はクエリに問題はありません。\u0026quot;valid\u0026quot;: trueです。 そして、explanationsの項目には、errorの代わりにexplanationという項目が返ってきました。 これが、実際にElasticsearch内部で実行されるクエリになります。\n実際のクエリに利用される単語の確認 この機能はこの他に、クエリの解析にも利用できます。 思ったとおりに検索にヒットしない場合があって、困ったことはないですか？ フィールドに指定されたアナライザによっては、単語を変形したりするものが存在します。\nサンプルマッピング\nPUT /validate_sample { \u0026#34;mappings\u0026#34;: { \u0026#34;several_analyzer\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;title\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;}, \u0026#34;body_ja\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34;}, \u0026#34;body_en\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;english\u0026#34;} } } } } 例えば、このようにkuromoji、english、デフォルト(standard)アナライザを利用したマッピングがあるとします。 このフィールドに対してpowerfulという単語で検索したとします。\nvalidate API\nGET /validate_sample/_validate/query?explain { \u0026#34;query\u0026#34;: { \u0026#34;multi_match\u0026#34;: { \u0026#34;fields\u0026#34;: [\u0026#34;body_en\u0026#34;,\u0026#34;body_ja\u0026#34;,\u0026#34;title\u0026#34;], \u0026#34;query\u0026#34;: \u0026#34;powerful\u0026#34; } } } この場合、レスポンスは次のとおりです。\nvalidate APIのレスポンス\n{ \u0026#34;valid\u0026#34;: true, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;explanations\u0026#34;: [ { \u0026#34;index\u0026#34;: \u0026#34;validate_sample\u0026#34;, \u0026#34;valid\u0026#34;: true, \u0026#34;explanation\u0026#34;: \u0026#34;(title:powerful | body_en:power | body_ja:powerful)\u0026#34; } ] } title、body_jaについては入力された単語がそのままクエリとして利用されています。 body_enについては、powerという単語に変換されて実行されています。 これは、englishアナライザがステミングを行った結果がクエリとして利用されるという意味です。 また、powerfulを秋葉原といった日本語に変更して実行すると次のようになります。 日本語はstandardアナライザなどでは、1文字ずつ区切られてしまうことがわかります。\nvalidate APIのレスポンス\n{ \u0026#34;valid\u0026#34;: true, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;explanations\u0026#34;: [ { \u0026#34;index\u0026#34;: \u0026#34;validate_sample\u0026#34;, \u0026#34;valid\u0026#34;: true, \u0026#34;explanation\u0026#34;: \u0026#34;((title:秋 title:葉 title:原) | (body_en:秋 body_en:葉 body_en:原) | ((body_ja:秋葉 body_ja:秋葉原) body_ja:原))\u0026#34; } ] } このように、クエリの単語がどのような単語に変換されてクエリに利用されているかなども知ることが可能です。\nまた、クエリを組み立てて、ヒットするはずが、0件となってしまうという場合にも、どのようなクエリが組み立てられているかを確認するという点で、 validate APIが役立ちます。 検索がヒットするが、望んだクエリになっていないのでは？という場合は_search APIのexplainパラメータを 利用すれば、クエリの構成がわかるのですが、検索結果が0件の場合はクエリの構成は表示されません。\n解決できない問題は？ 便利なvalidate APIですが、以下の問題に対しては残念ながら確認できません。\nquery以外の項目のvalidate不可 たとえば、_search APIのsizeなどの項目についてはチェックできないです。 存在しないフィールドの指定 上記validate_sampleのマッピングの例でクエリにbody_engという存在しないフィールドを指定してもエラーとはなりません。 まとめ 書いたクエリがうまく動かない、JSONのタグがおかしいといった場合は、 まずはこのvalidate APIで確認してみるのがオススメです。\n","date":1414402951,"dir":"post/2014/","id":"bc2709406a9bb19e8d83a78f81e36244","lang":"ja","lastmod":1414402951,"permalink":"https://blog.johtani.info/blog/2014/10/27/how-to-use-validate-api/","publishdate":"2014-10-27T18:42:31+09:00","summary":"久しぶりに翻訳ではないブログを。書こうと思いながらかけてなかったので。。。 今回はvalidate APIの紹介です。 背景 Elasticsear","tags":["elasticsearch"],"title":"validate APIの利用"},{"contents":"Elasticsearch 1.4.0.Beta1がリリースされました。\n個人でelasticsearch-extended-analyzeというプラグインを開発してます。 こちらも1.4.0.Beta1に対応するべく作業をしてて、少し戸惑ったことがあったので、メモをば。\nここ最近はプラグインのバージョン番号をElasticsearchのバージョン番号と同じものを利用していました。 （プラグインの機能追加をサボってる？？） その時に、1.4.0.Beta1という番号を指定したのですが、意味不明なエラーに悩まされてしまいまして。\nプラグインのリリースでは、以下のコマンドを実行します。\n$ mvn release:prepare $ mvn release:perform 最初のコマンド（prepare）で、パッケージングを実施し、Githubにリリースタグを打ったバージョンがpushされます。 次のコマンド（perform）で、パッケージングされたzipファイルがsonatypeのサイトに公開するためにアップロードされます。\n1.4.0.Beta1というバージョン文字列を利用した場合、prepareは問題なく実行できたのですが、 performで以下の様なエラーが返ってきました。\nReturn code is: 401, ReasonPhrase: Unauthorized. バージョン番号が1.3.0では特に問題はなかったのですが、、、 結局、バージョン番号を1.4.0-beta1に変更すると問題なくリリースが完了しました。\nmike_neckさんと話をしていて、Semantic Versioningに関係しているのかなぁという話にはなったのですが、 詳しく調べていません。。。\nそのうち調べようかなぁ。。。。\n","date":1413354368,"dir":"post/2014/","id":"998eda745d07fd8608f251138384a0b9","lang":"ja","lastmod":1413354368,"permalink":"https://blog.johtani.info/blog/2014/10/15/versioning-of-sonatype/","publishdate":"2014-10-15T15:26:08+09:00","summary":"Elasticsearch 1.4.0.Beta1がリリースされました。 個人でelasticsearch-extended-analyzeというプラグインを開発してま","tags":["Elasticsearch","plugin","sonatype"],"title":"Sonatypeのバージョン番号で困ったので"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch 1.4.0.beta1 released\n本日、Lucene 4.10.1をベースにした、Elasticsearch 1.4.0.Beta1をリリースしました。 Elasticsearch 1.4.0.Beta1からダウンロードできます。 また、すべての変更点に関してもこちらをご覧ください。\n1.4.0のテーマは*resiliency(復元性、弾力性)*です。 resiliencyとはElasticsearchをより安定し信頼性のあるものにすることを意味します。 すべての機能が正常に機能している場合は信頼することは簡単です。 予想外のことが発生した時に難しくなります：ノードでout of memoryの発生、スローGCや重いI/O、ネットワーク障害、不安定なデータの送信によるノードのパフォーマンス低下など。\n本ベータリリースは、resiliencyの主な3つの改善を含んでいます。\nメモリ使用量の低下によるノードの安定性向上 discoveryアルゴリズムの改善によるクラスタの安定性向上 チェックサムの導入による破損したデータの検知 分散システムは複雑です。 決して想像できないような状況をシミュレーションするために、ランダムなシナリオを作成する広範囲なテストスイートを持っています。 しかし、無数のエッジケース(特殊なケース)があることも認識しています。 1.4.0.Beta1はこれまで私たちが行ってきた改善のすべてを含んでいます。 これらの変更を実際にテストしていただき、何か問題があった場合は私たちに教えてください。\nメモリ管理 ヒープ空間は限られたリソースです。 上限を32GBとし、利用可能なRAMの50%をヒープの上限にすることを推奨します。 この上限を超えた場合、JVMは圧縮したポインタを使用することができず、GCが非常に遅くなります。 ノードの不安定性の主な原因は遅いGCです。それは、次のようなことから発生します。\nメモリプレッシャー スワップ(参照：memory settings) 非常に大きなヒープ 本リリースは、メモリ管理の改善し、（結果として）ノードの安定性を改善するいくつかの変更を含んでいます。\ndoc values メモリの利用の最も大きなものの1つはfielddataです aggregation、ソート、スクリプトがフィールドの値に素早くアクセスするために、フィールドの値をメモリにロードして保持します。 ヒープは貴重なため、1ビットも無駄にしないためにメモリ内のデータは高度な圧縮と最適化を行っています。 これは、ヒープスペース以上のデータをもつまでは、非常によく動作します。 これは、多くのノードを追加することによって常に解決できる問題です。 しかし、CPUやI/Oが限界に達してしまうずっと前に、ヒープ空間の容量に到達します。\n最近のリリースは、doc valuesによるサポートがあります。 基本的に、doc valuesはin-memory fielddataと同じ機能を提供します。 doc valuesの提供する利点は、それらが、非常に少量のヒープ空間しか使用しない点です。 doc valuesはメモリからではなく、ディスクから読み込まれます。 ディスクアクセスは遅いですが、doc valuesはカーネルのファイルシステムキャッシュの利点を得られます。 ファイルシステムキャッシュはJVMヒープとはことなり、32GBの制限による束縛がありません。 ヒープからファイルシステムキャッシュにfielddataを移行することによって、より小さなヒープを使うことができます。これは、GCがより早くなり、ノードが更に安定することを意味します。\n本リリースより前は、doc valuesはin-memory fielddataよりもかなり遅かったです。 本リリースに含まれる変更は、パフォーマンスをかなり向上させ、in-memory fielddataとほぼ同じくらいの速度になっています。\nin-memory fielddataの代わりにdoc valuesを利用するために必要なことは、次のように新しいフィールドをマッピングすることです。\nPUT /my_index { \u0026#34;mappings\u0026#34;: { \u0026#34;my_type\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;timestamp\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;date\u0026#34;, \u0026#34;doc_values\u0026#34;: true } } } } } このマッピングで、このフィールドに対するfielddataの利用は、メモリにフィールドをロードする代わりに、自動的にディスクからdoc valuesを利用します。 *注意：*現時点で、doc valuesはanalyzedなstringフィールドはサポートしていません。\nrequest circuit breaker fielddata circuit breakerはfielddataによって利用されるメモリの上限を制限するために追加され、OOMEの最も大きな原因の1つを防ぎました。 そして、リクエストレベルのcircuit-breakerを提供するために、コンセプトを拡張しました。 これは、単一のリクエストによって使用されるメモリの上限を制限します。\nbloom filters Bloom filters はインデキシング(前のバージョンのドキュメントが存在するかどうかのチェックのため)や、 IDによるドキュメントの検索(ドキュメントを含むセグメントがどれかを決定するため)に関する重要な性能最適化を提供しました。 しかし、もちろんそれらはコスト（メモリ）を必要とします。 現在の改善は、bloom filterの必要性を取り除きました。 現在では、Elasticsearchはまだ、インデックス時にそれらを構築します(実世界の経験がテストシナリオにそぐわない場合に備えて)。 しかし、デフォルトではメモリにはロードされません。 すべてが予定通りに運べば、将来のバージョンで完全にこれらは除去します。\nクラスタの安定性 クラスタの安定性向上のために私たちができる最も大きなことは、ノードの安定性の向上です。 もし、ノードが安定しておりタイミングよく反応すれば、クラスタが不安定になる可能性が大いに減少します。 私たちは不完全な世界に住んでいます。- 物事は予想外にうまく行きません。クラスタはデータを失うことなくこのような状況から回復できる必要があります。\n私たちは、improve_zenブランチ上で、Elasticsearchの障害からの復旧するための能力の向上に数ヶ月費やしてきました。 まず、複雑なネットワークレベルの障害を繰り返すためのテストを追加しました。 次に、各テストのための修正を追加しました。 そこには、より多くの行うことが存在します。しかし、私たちは、issue #2488(\u0026ldquo;分割が交差している場合、minimum_master_nodesはsplit-brainを防げない\u0026rdquo;)に含まれる、ユーザが経験してきた大部分の問題を私たちは解決しました。\n私たちはクラスタのresiliencyを非常に真剣に取り組んでいます。 私たちは、Elasticsearchが何ができるか、その上で何が弱点であるかを理解してほしいと思っています。 これを考慮して、私たちはResiliency Status Documentを作成しました。 このドキュメントは、私たち(または私たちユーザ)が遭遇したresiliencyの問題の、何が修正済みで、何が修正されないまま残っているかを記録します。 このドキュメントを慎重に読み、あなたのデータを保護するために適切な方法を選択してください。\nデータ破損の検知 ネットワークをまたいだシャードリカバリのチェックサムは、圧縮ライブラリのバグを発見する助けとなりました。 それは、バージョン1.3.2で修正済みです。 それ以来、私たちはElasticsearchのいたるところにチェックサムとチェックサムの確認を追加しました。\nマージ中に、あるセグメント内すべてのチェックサムの確認(#7360) インデックス再オープン時に、あるセグメント内の最も小さなファイルの完全な確認と、より大きなファイルの軽量な打ち切りチェック(LUCENE-5842) トランザクションログからイベントを再生するとき、各イベントはチェックサムを確認される(#6554) シャードのリカバリ中もしくは、スナップショットからのリストア中にElasticsearchはローカルファイルとリモートのコピーが同一であるか確認する必要がある。ファイルの長さとチェックサムのみを使うのは不十分であることが確認された。このため、現在はセグメントのすべてのファイルの同一性を確認(#7159) その他のハイライト Elasticsearch 1.4.0.Beta1のchangelogに本リリースの多くの機能、改善、バグフィックスについて読むことができます。 ここでは、特筆すべきいくつかの変更について述べます。\ngroovyによるmvelの置き換え Groovyは現在、デフォルトのscripting languageです。 以前のデフォルトはMVELで、古くなってきており、サンドボックス内で実行できないという事実は、セキュリティ問題でした。 Groovyはサンドボックスであり(それは、ボックスの外へは許可が必要)、メンテナンスされており、速いです！ 詳しくはscriptingについてのブログ記事をご覧ください。\nデフォルトでcorsはオフ Elasticsearchのデフォルト設定はクロスサイトスクリプティングに対して脆弱でした。 私たちはデフォルトでCORSをオフにすることで修正しました。 Elasticsearchにインストールされたサイトプラグインはこれまで同様に機能します。 しかし、CORSを再度オンにすることがない限り、外部のウェブサイトがリモートのクラスタにアクセスすることはできません。 ウェブサイトがあなたのクラスタにアクセス可能に制御できるように、さらにCORS settingsを追加しました。 詳しくはsecurity pageをご覧ください。\nクエリキャッシュ 新しい試験的なshardレベルのクエリキャッシュは、静的なインデックスのアグリゲーションをほとんど即座に反応できます。 ウエブサイトのアクセスの日毎のページビュー数を見るダッシュボードを持っていると想像してみてください。 これらの数値は古いインデックスでは変更がありません。しかし、アグリゲーションはダッシュボードのリフレッシュのたびに再計算されます。 新しいクエリキャッシュを利用すると、シャードのデータが変更されない限り、アグリゲーションの結果はキャッシュから直接返却されます。 キャッシュから古い結果を決して取得することはありません。それは、常に、キャッシュされていないリクエストと同じ結果を返します。\n新しいaggregations 3つの新しいaggregationsがあります。\nfilters\nこれはfilter aggregationの拡張です。複数のバケットを定義し、バケット毎に異なるフィルタを利用できます。 children\nnestedアグリゲーションの親子版。children aggは親のドキュメントに属する子のドキュメントを集計できる scripted_metric\nこのaggregationは、データによって計算されたメトリックを完全にコントロールできます。これは、初期化フェーズ、ドキュメント収集フェーズ、shardレベル結合フェーズ、global reduceフェーズを提供します。 get /index api 以前、ある1つのインデックスのaliases、mappings、settings、warmersを取得出来ました。しかし、それらを個別にです。 get-index API はこれらのすべてもしくは一部を、複数もしくはひとつのインデックスに対して一緒に取得できます。 これは、既存のインデックスと同一もしくはほぼ同一であるインデックスを作成したいときに非常に役に立ちます。\n登録と更新 ドキュメントの登録と更新にいくつかの改善があります。\n現在、ドキュメントIDの自動生成のためにFlake IDを使用しています。これは、プライマリキー探索時に素晴らしい性能向上を提供します。 detect_noopにtrueを設定すると、ドキュメントに変更を与えない更新が軽量になります。この設定を有効にすると、_sourceフィールドのコンテンツを変更する更新リクエストだけ、ドキュメントの新しいバージョンを書き込みます。 更新はスクリプトから完全に操作できます。以前は、スクリプトはドキュメントがすでに存在しているときだけ実行可能で、それ以外は、upsertドキュメントで登録しました。script_upsertパラメータでスクリプトから直接ドキュメントの作成が操作できます。 function score すでに非常に便利なfunction_scoreクエリが、新しくweightパラメータをサポートします。 これは、それぞれの指定された関数の影響をチューニングするのに使われます。 これは、人気度よりも更新日時により重みをかけたり、地理情報よりも価格により重みをかけるといったことを可能にします。 また、random_score機能はセグメントマージによる影響を受けません。これにより、より一貫した順序が提供されます。\n試してみてください。 ぜひ、Elasticsearch 1.4.0.Beta1をダウンロードして、試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1412244840,"dir":"post/2014/","id":"853cac0f2d1f90b7c986e7d1dcdbbfde","lang":"ja","lastmod":1412244840,"permalink":"https://blog.johtani.info/blog/2014/10/02/elasticsearch-1-4-0-beta-released-ja/","publishdate":"2014-10-02T19:14:00+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.0.beta1 released 本日、Lucene 4.10.1をベースにした、Elast","tags":["Elasticsearch"],"title":"elasticsearch 1.4.0.Beta1のリリース"},{"contents":"第6回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。 今回は、スタッフが私を含めて3，4名ということで、ドタバタしてしまってスミマセンでした。\n今回はキャンセルが多く、最終的には90人弱の参加となりましたが、今回も多数の方にお集まりいただきありがとうございました。 同じ日に他の勉強会もあった影響でしょうか？\n「Aggregationあれこれ」Elasticsearch Inc. Jun Ohtani @johtani スライド：Aggregationあれこれ\nちょっと長かったですかね。。。 Aggregationの概要、内部動作、種類などを簡単に紹介してみました。 個々のAggregationもいろいろなオプションなどがあるので、色々と試してみていただければと思います。 アニメーション入りのスライドになってましたが、UpしてあるスライドはPDF版になります。 「秒間3万の広告配信ログをElasticSearchでリアルタイム集計してきた戦いの記録」 株式会社サイバーエージェント　山田直行さん　@satully スライド：秒間3万の広告配信ログをElasticSearchでリアルタイム集計してきた戦いの記録\nディスプレイ広告配信DSPの話 システム: Fluentd、S3、Elasticsearch、Redis、MySQL 7月に秒間3万〜4万のリクエストをさばいている。 なぜElasticsearchを選んだのか、今の構成など 実際に苦労された点なども交えて話していただき面白かったです。 7月時点のお話ということで、現時点ではまた違う構成っぽかったので、また話を聞きたいなぁ。 「Elasticsearch 日本語スキーマレス環境構築と、ついでに多言語対応」ナレッジワークス株式会社　木戸国彦さん @9215 スライド：Elasticsearch 日本語スキーマレス環境構築と、ついでに多言語対応\nDynamic TemplateやIndex Templateの説明 日本語や多言語化するときのMappingのサンプルになりそうなものがゴロゴロ紹介されてました。 いくつかの例があって、後で見直したいなと。 途中で出てきた、fielddata（インデックスに入っている単語区切りのデータ）を見るのに使ってたクエリはfield data fieldsだったかな。 「elasticsearchソースコードを読みはじめてみた」@furandon_pig さん スライド：elasticsearchソースコードを読みはじめてみた\nリクエストを受けて検索してる部分から読むといいって言われたらしいが、起動スクリプトから読み始めてみた。 時間かかりそうｗ ただ、人がどんな感じでソースを読んだり理解してるかがわかりやすかったので面白かったです。 定期的に続きを聞いてみたいです。 LT 「reroute APIを使用してシャード配置を制御する」 株式会社富士通ソフトウェアテクノロジーズ 滝田聖己さん @pisatoshi スライド：reroute APIを使用してシャード配置を制御する\nシャードの再配置が自動で行われるので、それをオフにしないと、せっかく移動しても無駄になることがというあるあるネタ Bonsaiロゴを作成するLT 実際にいくら掛かったのかが知りたかった。 「検索のダウンタイム0でバックアップからIndexをリストアする方法」株式会社ドワンゴモバイル 西田和史さん スライド：検索のダウンタイム0でバックアップからIndexをリストアする方法\n擬似無停止のやりかた。 aliasを活用して、かつ、Restoreで再構築するという方法。 aliasまで一緒にリストアされるので注意が必要っていうのは、実際にやってみたからわかることという感じですね。 その他、感想などのブログ 適当に見つけたブログを列挙してあります。これもあるよ！などあれば、教えてください。\n第6回elasticsearch勉強会に行ってきましたのでそのメモ elasticsearch 勉強会 第6回 まとめ 今回も、ためになる話がいっぱい聞けたかなと。 個人的な印象としては、いつものメンバーよりも新しい方が多かった印象です。 また、ほとんどの方が、Elasticsearchをご存知でした。 そこそこ知名度は上がってきているようで嬉しい限りです。（東京以外での知名度なども知りたいかなと。）\nあと、懇親会の部屋の案内が遅くなってしまってスミマセンでした。 さすがにスタッフ3名はきつかったです。。。\n19時半開始にしてみましたが、懇親会の時間がやはり短めになってしまうなぁという印象でした。\n次回ももちろん2ヶ月後くらいに行います。 スピーカー募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1410927720,"dir":"post/2014/","id":"4616fbea6a6dbc1074bc3f1016bbc73b","lang":"ja","lastmod":1410927720,"permalink":"https://blog.johtani.info/blog/2014/09/17/hold-on-6th-elasticsearch-jp/","publishdate":"2014-09-17T13:22:00+09:00","summary":"第6回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第6回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"先日2014年9月9日(火)に『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』　出版記念！執筆者が語る大講演会！で、 「elasticsearch.もうちょっと入門」というタイトルで発表してきました。 会場のGMOのみなさま、Treasure Data、技術評論社のみなさま、どうもありがとうございました。\n書籍に興味のある方は、右のリンクから購入してもらえるとうれしいです。Kindle版も用意されています。\n提供のTDの方に目をつぶってもらいながらLogstashについての発表となってしまいましたが、楽しんでいただけたかなぁと。 書籍では主にKibana3をメインにしたElasticsearchの使い方だったので、それ以外の機能ということで、Aggregationについて説明してみました。\nそのあとは、おそらく初めてですが、パネルディスカッションにも参加しました。 @naoya_itoさんをモデレーターに、rebuild.fm風に進めていただき、話しやすかったかなと。 （少なくとも私は楽しめました！） ただ、私だけバックグラウンドが少し異なることもあり、話をうまく繋げられなかったかもと気にしていたりもしますが。。。\nパネルディスカッションでもありましたが、エンジニアが「趣味」で入れて試してみるのにはもってこいのツール群だと思います。 ちょっと入れてみて、可視化をしてみるといろいろと発見があると思います。 何かを発見するためにもまず試してみるのが何事も重要かなと最近思ってるのもあるので、気軽に試してみてもらえればと。\n不明点などあれば、著者陣に気軽に聞いていただけると良いかと思います（いいですよね、みなさんｗ）。 Fluentd（もちろん、Logstashも）、Elasticsearch、Kibanaを利用して、データについて試行錯誤してもらって、 システムやビジネスに必要なものを探索して見てください。\n参考 他の方々のブログをメモとして。\nサービス改善とログデータ解析について発表してきました Kibanaではじめるダッシュボードについて発表してきました #gihyo_efk Fluentdのお勧めシステム構成パターンについて発表しました ","date":1410841260,"dir":"post/2014/","id":"f15702ae9e55bad42182cf18724d1863","lang":"ja","lastmod":1410841260,"permalink":"https://blog.johtani.info/blog/2014/09/16/book-publication-event/","publishdate":"2014-09-16T13:21:00+09:00","summary":"先日2014年9月9日(火)に『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』 出版記念！執筆者が語る大講演会！で、 「elastics","tags":["勉強会","本"],"title":"elasticsearch.もうちょっと入門という話をしてきました #gihyo_efk"},{"contents":"Elasticsearchのインデキシングに関するパフォーマンス検討\n原文：performance considerations for elasticsearch indexing\nElasticsearchユーザは様々な楽しいユースケースを持っています。小さなログを追加することから、Webスケールの大きなドキュメントの集合をインデキシングするようなことまでです。また、インデキシングのスループットを最大化することが重要で一般的な目標となります。 「典型的な」アプリケーションに対して良いデフォルト値を設定するようにしていますが、次のちょっとした簡単なベストプラクティスによってインデキシングのパフォーマンスをすぐに改善することができます。それらについて記述します。\n第一に、制御できないならば、巨大なJavaヒープを使用しない：必要なサイズ（マシンの持つRAMの半分以下）のheapだけを設定しましょう。Elasticsearchの利用方法のために必要な全体量を設定します。これは、OSにIOキャッシュを制御するためのRAMを残すことを意味します。OSがjavaプロセスをスワップアウトしていないことも確認しましょう。\n最新バージョン（現時点では1.3.2）のElasticsearchにアップグレードしましょう：多数のインデキシングに関連する問題点が最新リリースで修正されています。\n詳細に入る前に警告：ここで述べるすべての情報は現時点での最新（1.3.2）の情報です。しかし、Elasticsearchの更新は日々行われています。この情報をあなたが見た時点では最新ではなく、正確ではなくなっているかもしれません。自信がない場合はユーザメーリングリストで質問してください。\nクラスタのインデキシングスループットをチューニングする場合、Marvelは非常に有用なツールです：ここで述べている各設定を継続的に試し、変更の影響がクラスタの挙動をどのように変更されたかを簡単に可視化することが可能です。\nクライアントサイド bulk APIを常に使いましょう。1リクエストで複数のドキュメントをインデキシングでき、各バルクリクエストで送るのに良いドキュメント数を試しましょう。最適なサイズは多くの要因に依存しますが、最適サイズからずれるならば多すぎるよりも少なすぎる方が良いでしょう。クライアントサイドのスレッドで並列にbulkリクエストを使うか、個別の非同期リクエストを使ってください。\nインデキシングが遅いと結論付ける前に、クラスタのハードウェアの性能を引き出せているかを確認して下さい：すべてのノードでCPUやIOが溢れていないかを確認するためにiostatやtop、psといったツールを使いましょう。もし、溢れていなければ、より多くの並列なリクエストが必要です。しかし、javaクライアントからのEsRejectedExecutionExceptionや、RESTリクエストのHTTPレスポンスとしてTOO_MANY_REQUESTS (429)が返ってきた場合は並列リクエストを多く送りすぎています。もしMarvelを利用しているなら、Node Statistics DashboardのTHREAD POOLS - BULKにリジェクトされた数が表示されます。bulkスレッドプールサイズ（デフォルト値はコア数）を増やすのは得策ではありません。インデキシングスループットを減少させるでしょう。クライアントサイドの並列度を下げるか、ノードを増やすのが良い選択です。\nここでは、1シャードに対してインデキシングスループットを最大化する設定に注目します。1つのLuceneインデックスのドキュメントの容量を測定するために、単一ノード（単一シャード、レプリカなし）で最初にテストをして最適化し、クラスタ全体にスケールする前にチューニングを繰り返します。これはまた、インデキシングスループットの要件を見つけるために、クラスタ全体にどのくらいのノードが必要かをラフに見積もるためのベースラインを与えてくれます。\n単一シャードが十分機能したら、Elasticsearchのスケーラビリティの最大の利点や、クラスタでの複数ノードによるレプリカ数やシャード数の増加の利点が得られます。\n結論を導き出す前に、ある程度の時間（60分）くらいクラスタ全体の性能を計測しましょう。このテストは、巨大なマージ、GCサイクル、シャードの移動、OSのIOキャッシュ、予期しないスワップの可能性などのイベントのライフサイクルをカバーできます。\nストレージデバイス 当然ながらインデックスを保存するストレージデバイスはインデキシングの性能に多大な影響を及ぼします：\nSSDを利用する：これらは最も速いHDDよりも速いです。ランダムアクセスのための消費電力が低いだけでなく、シーケンシャルIOアクセスも高いです。また、同時に発生するインデキシング、マージや検索のための並列的なIOも高速です。 インデックスをリモートマウントされたファイルシステム（例：NFSやSMB/CIFS）上に配置しない：代わりにローカルストレージを使う 仮想化されたストレージ（AmazonのElastic Block Storageなど）に注意：仮想化されたストレージはElasticsearchで十分に動作します。また、十分早く簡単に用意できることから魅力的です。しかし、残念なことに、ローカルストレージと比較すると本質的に遅いです。最近の非公式なテストでは、最高の性能を持つプロビジョニングされたIOPSのSSDオプションのEBSでさえ、ローカルインスタンスにあるSSDよりも遅いです。ローカルインスタンスにあるSSDは物理マシン上のすべての仮想マシンから共有されてアクセスされます。もし他の仮想マシンが急にIOが集中した場合に不可解なスローダウンとなることがあることを覚えておいてください。 複数のSSDを複数のpath.dataディレクトリにインデックスをストライピング（RAID0のように）：2つは同様で、ファイルブロックレベルでストライピングする代わりに、個別にインデックスファイルレベルでElasticsearchの\u0026quot;stripes\u0026quot;となります。これらのアプローチは、いづれかのSSDの故障によりインデックスが壊れるという、1シャードが故障する(IO性能を高速化することとトレードオフ)というリスクを増加させることに注意してください。これは、一般的に行うのに良いトレードオフです：単一シャードで最大のパフォーマンスを最適化し、異なるノード間でレプリカを追加すると、ノードの故障への冗長化ができます。また、snapshotやrestoreを使って保険のためにインデックスのバックアップを取ることもできます。 セグメントとマージ 新しくインデキシングされたドキュメントは最初にLuceneのIndexWriterによってRAMに保存されます。RAMバッファがいっぱいになった時もしくは、Elasticsearchがflushもしくはrefreshを実行した時など定期的にこれらのドキュメントはディスクに新しいセグメントとして書き込まれます。最後に、セグメントが多くなった時に、Merge PolicyとSuchedulerによってそれらがマージされます。このプロセスは連続的に生じます：マージされたセグメントはより大きなセグメントとなり、小さなマージが幾つか実行され、また、大きなセグメントにマージされます。これらがどのように動作するかをわかりやすく可視化したブログはこちらです。\nマージ、特に大きなマージは非常に時間がかかります。これは、通常は問題ありません。そのようなマージはレアで全体のインデックスのコストと比べればささいなものです。しかし、マージすることがインデキシングについていけない場合、インデックスに非常に多くのセグメントがあるような深刻な問題を防ぐために、Elasticsearchはやってくるインデキシングリクエストを単一スレッド(1.2以降)に制限します。\nもし、INFOレベルのログメッセージにnow throttling indexingと表示されていたり、Marvelでのセグメント数が増加しているを見た場合、マージが遅れているとわかります。MarvelはIndex Statistics dashboardのMANAGEMENT EXTENDEDの部分にセグメント数をプロットしており、それは、非常にゆっくりと指数対数的に増加しており、大きなマージが終了したところがのこぎりの歯のような形で見て取れます。\nセグメント数 なぜマージが遅れるのでしょう？デフォルトでElasticsearchはすべてのマージの書き込みのバイト数をわずか20MB/secに制限しています。スピニングディスク（HDD）に対して、これはマージによって典型的なドライブのIOキャパシティを飽和させず、並列に検索を十分に実行させることを保証します。しかし、もし、インデキシング中に検索をしない場合や、検索性能がインデキシングのスループットよりも重要でない場合、インデックスの保存にSSDを使用している場合などは、index.store.throttle.typeにnoneを設定して、マージの速度制限を無効化するべきです（詳細はこちらをご覧ください）。なおバージョン1.2以前には期待以上のマージIO制限の発生といったバグが存在します。アップグレードを！\nもし、不幸にもスピニングディスク（それはSSDと同等の並列なIOを扱えません）をまだ使っている場合、index.merge.scheduler.max_thread_countに1を設定しなければなりません。そうでない場合は、（SSDを支持する）デフォルト値が多くのマージを同時に実行させるでしょう。\n活発に更新が行われているインデックスでoptimizeを実行しないでください。それは、非常にコストの高い操作(すべてのセグメントをマージ)です。しかし、もし、インデックスにドキュメントを追加が終わった直後はオプティマイズのタイミングとしては良いタイミングです。それは、検索時のリソースを減らすからです。例えば、時間ベースのインデックスを持っており、新しいインデックスに日々のログを追加している場合、過去の日付のインデックスをオプティマイズするのは良い考えです。特に、ノードが多くの日付のインデックスを持っている場合です。\n更にチューニングするための設定：\n実際に必要のないフィールドをオフにする。例えば_allフィールドをオフ。また、保持したいフィールドでは、indexedかstoredかを検討する。 もし、_sourceフィールドをオフにしたくなるかもしれないが、インデキシングコストは小さい(保存するだけで、インデキシングしない)、また、それは、将来の更新や、前のインデックスを再インデキシングするために非常に価値があり、それはディスク使用率の懸念事項がない限り、オフにする価値はあまりない。それは、ディスクが比較的安価であるので価値がない。 もし、インデックスされたドキュメントの検索までの遅延を許容できるなら、index.refresh_intervalを30sに増やすか、-1を設定して、オフにする。これは、巨大なセグメントをフラッシュし、マージのプレッシャーを減らすことができる。 Elasticsearch 1.3.2(稀に、フラッシュ時に過度のRAMを使用するという問題を修正した)にアップグレードすることで、index.translog.flush_threshold_sizeをデフォルト(200mb)から1gbに増加し、インデックスファイルのfsyncの頻度を減らす。 MarvelにIndex Statistics dashboardのMANAGEMENTにフラッシュの頻度がプロットされている。 インデックスバッファサイズ 巨大なインデックスを構築中はレプリカ数を0にし、あとから、レプリカを有効にする。レプリカが0ということは、データを失った(ステータスがred)時に冗長性がないので、ノードの故障に注意すること。もし、optimize(ドキュメントの追加をすることがないので)を計画するなら、インデキシングが終わったあとで、レプリカを作成する前に実行するのが良いでしょう。レプリカはオプティマイズされたセグメントをコピーするだけになります。詳細はインデックス設定更新を参照。\nもし、ノードがヘビーなインデキシングを行っているだけなら、アクティブなシャードのインデキシングバッファに多くてい512MBをindices.memory.index_buffer_sizeに与えてください。(超えてもインデキシングのパフォーマンスは一般的には改善されません。)Elasticsearchはその設定(Javaヒープのパーセンテージもしくはバイト数)を受けて、min_index_buffer_sizeとmax_index_buffer_sizeの値を前提にノードのアクティブシャードに均等に割り当てます；大きな値はLuceneが最初のセグメントをより大きくし、将来的なマージのプレッシャーを減らすことを意味します。\nデフォルトは10%で、それで十分です；例えば、もし、5つのアクティブなシャードがノードにあり、ヒープが25GBの場合、各シャードは25GBの10%の1/5=512MB（すでに最大値）を持っています。ヘビーなインデキシングのあと、この設定をデフォルトに下げましょう。検索時のデータ構造のために十分なRAMを確保するために。この設定はまだ動的な設定変更はできません。Issueがここにあります。\nインデックスバッファによって現在利用されているバイト数は1.3.0のindices stats APIに追加されています。indices.segments.index_writer_memoryの値を見ることができます。これはMarvelではまだプロットされていませんが、将来のバージョンで追加される予定です。しかし、自分でグラフに追加することもできます。(Marvelはデータは収集しています)\n1.4.0では、indices.segments.index_writer_max_memoryとして、indices stats APIにアクティブシャードにどのくらいのRAMバッファが割り当てられているかも表示されます。これらの値はインデックスのシャード事の値として見ることができ、http://host:9200/\u0026lt;indexName\u0026gt;/_stats?level=shardsを使ってみることができます；これは、全シャードに対する合計と、各シャードごとのstatsを返すでしょう。\nオートIDの利用もしくは良いIDの利用 もし、ドキュメントのIDがなんでも良い場合、Elasticsearchで採番することができます：これは、(1.2以降)ドキュメントIDをバージョンを探さずに保存できるように最適化され、Elasticsearchの日毎のベンチマークで異なるパフォーマンスを見ることができます。(FastとFastUpdateのグラフを比較)\nもし、IDを自身が持っていて、自分の支配下でLuceneに対して素早く選ぼうとしているなら、1.3.2にアップグレードしましょう、IDのルックアップがさらにオプティマイズされています。JavaのUUID.randomUUID()はやめましょう。それは、セグメントに対してどのようにIDを割り当てるかという予測やパターン性がないため、最悪のケースでセグメントごとのシークが発生します。\nFlake IDsを利用した時のMarvelによるインデックス性能の違い：\nflakeIDsPerf ランダムUUIDを利用した場合：\nuuidsPerf 次の1.4.0では、ElasticsearchのID自動採番をUUIDからFlake IDに変更します。\nもし、Luceneのローレベル操作がインデックスに対してなにをやっているかについて興味があるなら、lucene.iwをTRACEログレベルで出力できるようにしてみましょう(1.2から利用可能)。これは、多くの出力がありますが、LuceneのIndexWriterレベルで何が起きているかを理解するのに非常に役に立ちます。出力は非常にローレベルです：Marvelがインデックスに何が起きているかをよりリアルタイムにグラフを描画してくれます。\nスケールアウト 我々は、単一シャード(Luceneインデックス)性能のチューニングに注目してきました。しかし、一旦それに満足できたならば、Elasticsearchはクラスタ全体にわたってインデキシングや検索を簡単にスケールアウトすることに長けています。シャード数(デフォルトでは5)を増やすのは可能です。それは、マシン全体に対して並列度、巨大なインデックスのサイズ、検索時のレイテンシの低下など得ることができます。また、レプリカを1位上にすることは、ハードウェア故障に対する冗長性を持つことを意味します。\n最後に、このドキュメントを見ても問題解決しない場合はコミュニティに参加しましょう。例えば、ElasticsearchのユーザMLに投稿するなど。おそらく、修正すべきエキサイティングなバグがあるでしょう。(パッチも常に歓迎です！)\n","date":1410250260,"dir":"post/2014/","id":"77d965afaebd7193badc746d52b4173f","lang":"ja","lastmod":1410250260,"permalink":"https://blog.johtani.info/blog/2014/09/09/performance-considerations-for-elasticsearch-indexing/","publishdate":"2014-09-09T17:11:00+09:00","summary":"Elasticsearchのインデキシングに関するパフォーマンス検討 原文：performance considerations for elasticsearch indexing Elasticsearchユーザは様","tags":["Elasticsearch"],"title":"Elasticsearchのインデキシングに関するパフォーマンス検討"},{"contents":"懲りずにまた、執筆してみました。みなさん「買って」から感想をいただけるとうれしいです！\n本書について 共著者の方々のブログが詳しいので、そちらを読んでもらいつつ。 実際にログを収集して解析されている方々と一緒に書かせていただくことで色々と勉強させていただいています。\n共著者の方々のブログ @suzu_vさん：サーバ/インフラエンジニア養成読本 ログ収集~可視化編 を書きました @yoshi_kenさん：ログ収集や可視化で話題のFluentd、Elasticsearch、Kibanaを徹底解説したムック本が発売となります @harukasanさん：書きました: サーバ/インフラエンジニア養成読本 ログ収集~可視化編 どの辺を書いたの？ 「特集３：Elasticsearch入門」（なんか、入門ばっかりだなぁ）を書かせていただきました。 データストア入門ということで、ほんとうに簡単な他のデータストアを説明し、Elasticsearchってどんなものかを単語の説明をしつつ紹介してみました。\nElasticsearch自体は多くの機能を持っており、それ単体で分厚い書籍がかけるので、ログ検索に関係ありそうな部分をピックアップしてみました。 あとは、運用時に気をつける点や便利なツール（Curatorなど）の紹介をしています。\nまた、Hadoopと合わせて利用してみたい、すでにHadoopにあるデータも活用してみたいという話もありそうだということで、elasticsearch-hadoopについても簡単ですが紹介してあります。\nその他感想 個人的に、忙しい時期（参考記事）だったので、あんまり力になれてないので大変申し訳なく思っています。。。 ただ、素晴らしい出来（カラーでKibanaの解説が日本語で読めたり、Fluentdの逆引きのリストがあったり、ログを貯めて可視化する意義を説明してあったり）です。\nぜひ、読んだ感想をいただければと！\n","date":1407156840,"dir":"post/2014/","id":"bdea71d64cdfcc405e65e750fe8d9b86","lang":"ja","lastmod":1407156840,"permalink":"https://blog.johtani.info/blog/2014/08/04/release-magazine-book-of-log-aggs-and-viz/","publishdate":"2014-08-04T21:54:00+09:00","summary":"懲りずにまた、執筆してみました。みなさん「買って」から感想をいただけるとうれしいです！ 本書について 共著者の方々のブログが詳しいので、そちらを","tags":["elasticsearch","kibana","本"],"title":"サーバ/インフラエンジニア養成読本 ログ収集~可視化編 を手伝いました"},{"contents":"Proxy環境で働いている方も結構いると思います。 Twitter上で、Elasticsearchのpluginコマンドでプラグインがインストールできなくて困っている方がいたので、 調べてみたのでメモしておきます。\nプラグインコマンド Elasticsearchでは、プラグインという形でいくつかの便利な機能が公開されています。 形態素解析ライブラリのKuromojiを使うためのプラグインや、クラスタの管理がGUIで可能なkopfプラグインなどがあります。 公式、サードパーティいろいろです。\nこれらのプラグインをElasticsearchにインストールする場合、以下のコマンドを実行すれば 自動的にダウンロードしてpluginsディレクトリにインストールしてくれます。\n./bin/plugin -i elasticsearch/elasticsearch-analysis-kuromoji/2.3.0 ここで、elasticsearch/elasticsearch-analysis-kuromoji/2.3.0がプラグインのパスになります（例では、提供元/プラグイン名/プラグインバージョンとなっています。）。\nこのpluginコマンドがダウンロード元にアクセスに行くのですが、プロキシ環境だとプロキシの設定が必要になります。\nプロキシの指定（Mac/LinuxとWindowsでの違い） Mac/Linux(shコマンド) 以前の記事でプロキシのポート番号などの指定方法を 以下のように説明していました。 （※昔の記事のため、kuromojiプラグインのバージョンが古いです）\nElasticsearchのpluginコマンドはJavaで実装されています。（org.elasticsearch.common.http.client.HttpDownloadHelper） プラグインのダウンロードには、java.net.URL.openConnection()から取得URLConnectionを使用しています。\nですので、pluginのインストールを行う際に、Proxy環境にある場合は以下のようにコマンドを実行します。\n./bin/plugin -DproxyPort=ポート番号 -DproxyHost=ホスト名 -i elasticsearch/elasticsearch-analysis-kuromoji/1.5.0 LinuxやMacの環境であれば、こちらのコマンドでプロキシの指定が可能です。 ただし、Windows環境ではうまくいきません。\nElasticsearchは、環境の違いにより、ダウンロードするファイルが異なります。 Windows環境の方は、zipファイルをダウンロードしてもらうようになっています。 elasticsearchコマンドおよびpluginコマンドがbat形式で提供されているのがzipファイルとなるからです。\nWindows(batコマンド) Windows環境では次のように指定します。\nset JAVA_OPTS=\u0026#34;-DproxyHost=ホスト名 -DproxyPort=ポート番号\u0026#34; bin\\plugin -i elasticsearch/elasticsearch-analysis-kuromoji/2.3.0 コマンドの実装方法が少し異なるために、このようになっています。\nまとめ プロキシ環境で利用される場合は、プラグインコマンドは上記のように実行していただければと。\n公式ガイドには、これらの情報を追記するPRを送る予定です。 また、WindowsのコマンドでもMac/Linuxと同様にできたほうがいい気がするので、Issueをあげようと思います。\n不明点などあれば、コメントいただければと。\n","date":1406874240,"dir":"post/2014/","id":"7cc605e721fdd1d2ccc16f5b6490e830","lang":"ja","lastmod":1406874240,"permalink":"https://blog.johtani.info/blog/2014/08/01/plugin-using-under-proxy-env/","publishdate":"2014-08-01T15:24:00+09:00","summary":"Proxy環境で働いている方も結構いると思います。 Twitter上で、Elasticsearchのpluginコマンドでプラグインがインスト","tags":["elasticsearch","plugin"],"title":"プロキシ環境でのpluginコマンドの実行"},{"contents":"原文：Elasticsearch 1.3.1 Releasedを日本語に翻訳したものです。\nバグフィックス版のElasticsearch 1.3.1をリリースしました。 ダウンロードおよび変更履歴はElasticsearch 1.3.1からお願いいたします。\nこのリリースはインデックスリカバリ時の後方互換性バグ（#7055）への対応です。 このバグはデータの欠損は起こりません。 Elasticsearch 1.3.1へアップグレードすることで問題を回避できます。 このバグは、以下のElasticsearchのバージョンで作成されたセグメントを含むインデックスを1.3.0へアップグレードしようとすると発生します。\nElasticsearch 0.90.7 Elasticsearch 0.90.2 Elasticsearch 0.90.0以前のバージョン このバグは、これらの古いインデックスをレプリカからリカバリできなくします。 これらのバージョンのセグメントを持つインデックスが、レプリカは可能ですが、 ステータスがYellowのままGreenに決してなりません。 ログには次のようなExceptionが発生します。\nIllegalArgumentException[No enum constant org.apache.lucene.util.Version.x.x.x]\nLuceneの特定のバージョンではLuceneのマイナーバージョンを含んでおらず、誤ったバージョン番号がセグメントに記録されました。 LUCENE-5850のチケットがこの問題に対処するためにオープンされています。 この問題は我々の後方互換テストで見つかるべき問題ですが、Luceneで不足しているため発見されませんでした。 テストスイートは今後の可能性のために改良されます。\nこのリリースはその他に、Aggregationのマイナーバグフィックスも含まれています。 詳細はリリースノートをご覧ください\nElasticsearch 1.3.1をダウンロードし、試してください。 もし問題を見つけた場合はGitHubのIssuesへご報告をお願いいたします。\n","date":1406604120,"dir":"post/2014/","id":"fb1da4a6ed74705ad98bb60ad4badaf2","lang":"ja","lastmod":1406604120,"permalink":"https://blog.johtani.info/blog/2014/07/29/elasticsearch-1-3-1-release/","publishdate":"2014-07-29T12:22:00+09:00","summary":"原文：Elasticsearch 1.3.1 Releasedを日本語に翻訳したものです。 バグフィックス版のElasticsearch 1.3.1をリリー","tags":["elasticsearch","release"],"title":"Elasticsearch 1.3.1 リリース（日本語訳）"},{"contents":"Curatorの1.2.0がリリースされました。\n前回のCuratorの記事が古くなってしまった（1.1.0からコマンドのI/Fが変更された）ので 1.1.0および1.2.0に関する記事を翻訳しておきます。\nちなみに、Curatorとは、Elasticsearchに時系列のインデックス（例：LogstashやFluentdでログを保存）を保存している場合にそれらのインデックスを管理（削除したり、クローズしたり）するための便利なツールです。 Curatorの概要については、GitHubリポジトリか前回の記事をご覧ください。\nCurator 1.1.0リリース (2014/06/13公開) 元記事：elasticsearch curator - version 1.1.0 released\nElasticsearch 1.0.0がリリースされ、新しい機能、Snapshot \u0026amp; Restoreが利用できるようになりました。 Snapshotはある時点でのインデックスの写真を撮るように、バックアップを作成することができます。 1.0.0が発表されてすぐに、この機能に関するリクエストが寄せられるようになりました。 「Curatorにスナップショットを追加して！」もしくは「いつCuratorでスナップショットが使えるようになる？」といった感じです。 これがあなたの要望なら、それはついに叶えられました。しかも他の追加機能も一緒にです。\n新機能 Curatorの新機能は以下のとおりです。\n新CLI構造 スナップショット(Snapshot) エイリアス(Aliases) パターンによる除外インデックス指定 配置ルーティング(Allocation Routing) インデックスとスナップショットの表示 リポジトリ管理(個別のスクリプトによる) ドキュメントWiki 新コマンドライン構造 注意：コマンドライン構造の変更とは、Curator 1.1.0以前のcron記述が動作しないことを意味します。Curator 1.1.0にアップグレードする場合はコマンドも修正が必要となるので注意してください。\nシンプルにするために、commandsという概念を追加しました。 また、ヘルプの出力もわかりやすくなっています。 前のバージョンと同じタスクをCuratorは実行できますが、異なるフォーマットを用いるようになりました。\n旧コマンド：\ncurator -d 30 新コマンド：\ncurator delete --older-than 30 コマンドは、フラグとは異なりハイフンを前に付けないことに注意してください。 また、似たような名前のフラグがあることに気をつけてください。 例えば、--older-thanフラグは多くのコマンドに利用できます。 指定される値は各ケースにおいて同一です。「指定された数よりも古いインデックス」となります。\n新しいコマンドのリストは次のとおりです。\nalias allocation bloom close delete optimize show snapshot コマンドのヘルプは次のコマンドで表示されます。\ncurator [COMMAND] --help コマンドに関係あるフラグがすべて表示されます。\nスナップショット(snapshots) snapshotコマンドで、存在しているリポジトリにインデックスのスナップショットを保存することができます。\nCuratorはインデックス毎に1つのスナップショットを作成し、インデックスから名前をつけます。 例えば、インデックスの名前がlogstash-2014.06.10の場合、スナップショットの名前はlogstash-2014.06.10となります。 指定した条件を元に、シーケンシャルに、1つずつインデックスのスナップショットを作成していきます。\ncurator snapshot --older-than 20 --repository REPOSITORY_NAME このコマンドは、20日以上古いインデックスすべてのスナップショットを作成し、REPOSITORY_NAMEで指定されたリポジトリに保存します。\nes_repo_mgrと呼ばれるリポジトリ作成を支援するスクリプトがCuratorには含まれています。 ファイルシステムおよびS3タイプのリポジトリ両方の作成を支援します。\nさらに、古いインデックスのスナップショットを取ることができることに加えて、Curatorは最新のインデックスをアップロードする方法も提供します。 これは、Elasticsearch Marvelのインデックスをアップロードするときに便利です。 トラブルシューティングを目的として、パフォーマンスデータを他の人に見せる場合などです。\ncurator snapshot --most-recent 3 --prefix .marvel- --repository REPOSITORY_NAME このコマンドでは、最新の3つのMarvelインデックスのスナップショットを指定されたリポジトリに保存できます。\nエイリアス(aliases) Curatorはすでに存在するエイリアスにインデックスを追加することも、削除することもできるようになりました。 ただし、エイリアスがすでに存在している必要があります。エイリアスの作成はできません。\nlast_weekという前の一週間のインデックスのエイリアスを保持していること想像してください。 この場合、次の2つのコマンドを利用することで、エイリアスを管理できます。\ncurator alias --alias-older-than 7 --alias last_week curator alias --unalias-older-than 14 --alias last_week 新しく作られたインデックスがインデックステンプレートによって 自動的にエイリアスの一部となるようにElasticsearchに設定しておくと、さらに便利です。 この場合、新しいインデックスが自動的にthis_weekというエイリアスの一部になるようにしてあれば、以下のコマンドのみとなります。\ncurator alias --unalias-older-than 7 --alias this_week this_weekとlast_weekのエイリアスのアップデートを保持できます。\nパターンによる除外(exclude pattern) 時には、指定したインデックスを操作から除外したくなる場合もあるでしょう。 ここまでは、プレフィックスや日付によって選択されたインデックスのみを対象にしてきました。 そこで、--exclude-patternオプションです。これは、指定したインデックスを除いて処理を行うことができます。\nlogstash-2014.06.11というインデックスを決して削除したくないとします。 この場合、次のコマンドのようになります。\ncurator delete --older-than 15 --exclude-pattern 2014.06.11 Curatorはデフォルトでlogstash-というプレフィックスにマッチしますが、2014.06.11というインデックスは対象外となります。\n配置ルーティング(allocation routing) Elasticsearchはノードにタグを付けることができます。 これらのタグはインデックスやシャードをクラスタのどこに配置するかをコントロールするために役立ちます。 一般的なユースケースだと、高性能なSSDドライブを持ったノードをインデキシングのために、ハードディスクを持った性能の低いマシンは検索頻度が低い古いインデックスを配置するといった場合です。 この場合、HDDノードには、elasticsearch.ymlにnode.tag: hdd、SSDノードにはnode.tag: ssdと設定されているべきです。 Curatorはこの時、インデックスをタグに基づいてオフピークの時間帯に再配置させることができます。\nコマンド：\ncurator allocation --older-than 2 --rule tag=hdd index.routing.allocation.require.tag=hddという設定が２日よりも古いインデックスに適用されます。 これは、インデックスのシャードがnode.tag: hddというノードに再配置される必要があると、Elasticsearchに伝えます。\nインデックスとスナップショットの表示(show indices and snapshots) これは、単にあなたの持っているインデックスやスナップショットがどんなものかを表示します。\ncurator show --show-indices これは、デフォルトプレフィックスのlogstash-にマッチするすべてのインデックスを表示します。\ncurator show --show-snapshots --repository REPOSITORY_NAME これは、指定されたリポジトリにある、デフォルトプレフィックスのlogstash-にマッチするすべてのスナップショットを表示します。\nリポジトリ管理(repository management) 前に説明したとおり、es_repo_mgrと呼ばれるヘルパースクリプトをCuratorは含んでいます。 現時点では、fsとs3タイプをサポートしています。 リポジトリを作る前に利用したいタイプのドキュメントを読むようにしてください。 例えば、fsタイプのリポジトリを各ノードで使う場合は、同じ共有ファイルシステムに、同じパスでアクセスできなければなりません。 パスの指定は--locationです。\nfsタイプリポジトリの作成\nes_repo_mgr create_fs --location \u0026#39;/tmp/REPOSITORY_LOCATION\u0026#39; --repository REPOSITORY_NAME 削除\nes_repo_mgr delete --repository REPOSITORY_NAME ドキュメントWiki Curatorのドキュメントが更新され、オンラインにWiki形式でだれでも更新できるようになっています。 コマンドやフラグのより詳細の情報はこちらで見つけることができます。また、もし、興味があれば、ドキュメントを追加することもできます。\nインストールと更新 Curator 1.1.0はPyPiリポジトリにあります。 インストールは以下のとおりです。\npip install elasticsearch-curator バージョン1.0.0からアップグレードする場合は以下のとおりです。\npip uninstall elasticsearch-curator pip install elasticsearch-curator バージョン1.0.0よりも古いバージョンからのアップグレードは以下のとおりです。\npip uninstall elasticsearch-curator pip uninstall elasticsearch pip install elasticsearch-curator pip uninstall elasticsearchで、古いパイションモジュールをを削除します。 適切なバージョンが依存関係により再インストールされます。\nまとめ Curatorの新機能は素晴らしいです！このリリースは大きな改善です。 もし、トラブルや足りないものを見つけた場合はGitHub Issueに報告してください。 また、Curatorが便利だと思ったら、私たちに伝えてください。#elasticsearchタグを付けてツイートしてください！\nCuratorはまだ、始まったばかりです。Curator 2.0のロードマップを作業中です。ここまで読んでいただきありがとうございます。 Happy Curating!\nCurator 1.2.0リリース(2014/07/24) 元記事：curator 1.2.0 released\nCurator v1.1.0のリリースから、数週間が経ちました。 私たちは、Curator 1.2.0をリリースしました。\n新機能(new features) ユーザ指定の日付パターン：長い間リクエストされていた機能 ウィークリーインデックスのサポート：これも長い間リクエストされていた機能 複数のログフォーマットオプション：Logstashフォーマットが利用可能 これらの変更はCuratorドキュメントにも記載されています。\n更新(updates) ログ出力の整理：デフォルトのログ出力を整理しました。デバッグログはすべて表示されます。 ドライランのログ出力の詳細化：テスト実行時に何が起きたかをわかりやすくしました。 日付パターンと--timestring(date patterns and \u0026ndash;timestring) 前のリリースで、セパレータ文字を利用して、インデックス名のエレメントを分離することで、日付を計算しました。 この設計の決定は、プログラムが管理するために設計されたLogstashのインデックスを使うのには簡単でした。 しかし、Curatorは時系列インデックス管理に成長しています。これは、異なる命名規則のインデックスを意味しています。\nまた、インターバルによって、日付の計算が必要になる場合もあります。 --time-unitオプションが残っており、weeksという単位を指定することもできます。 デフォルトの--timestringオプションは、以前のコマンドと同様の動作をしなければなりません。次のようになります。\nTime Unit Timestring days %Y.%m.%d hours %Y.%m.%d.%H weeks %Y.%W これが意味するものは、もし、単位にhoursをした場合、--timestringを指定しなかった場合は%Y.%m.%d.%Hとなります。 これは、Pythonのstrftimeフォーマットで\u0026quot;年.月.日.時\u0026quot;を意味します。 同様に、weeksを単位に指定した場合、Curatorはデフォルトの--timestringは%Y.%Wとなります。\nこの機能は、日付の間にセパレーター文字のないインデックスでも機能します。 例えば、production-20140724のような日時インデックスがある場合、2日よりも古いインデックスに対するブルームフィルタっキャッシュのオフのコマンドは次のようになります。\ncurator bloom --prefix production- --older-than 2 --timestring %Y%m%d この例で、デフォルトの単位はdaysであることに注意してください。hourly-2014072414のような時間インデックスの場合は次のようになります。\ncurator bloom --prefix hourly- --older-than 2 --time-unit hours --timestring %Y%m%d%H --separatorの置き換え もし、Curatorの前のバージョンでカスタムセパレータ文字を利用していた場合、次のように変更すべきです。 前のコマンドでcerberus-2014-07-24のようなインデックスがある場合、コマンドを--separator -の用に置き換える必要があります。 新しいコマンドは次のとおりです。\ncurator delete --prefix cerberus- --older-than 30 --timestring %Y-%m-%d 年(％Y)と月(%m)と日(\u0026rsquo;%d\u0026rsquo;)の間にセパレータ文字を置くだけです。\nこれは、また、Curatorで以前は不可能であったことをできるようにもします。 異なるセパレータ文字の混在です。 logs-2014.07.24-14というようなインデックスを処理するときに--timestringは%Y.%m.%d-%Hのようになります.\n--timestringの詳細はCuratorのドキュメントをご覧ください。\nフィードバック これらの新しい機能はユーザのコメントやリクエストから来ています。もし、機能のリクエストやバグを発見したら、こちらまで連絡してください。\nまた、Twitterでもお待ちしています。私たちのTwitter IDは@elasticsearchです。\nHappy Curating!\n","date":1406524740,"dir":"post/2014/","id":"0c1821d1069578551d0e3c7d9275f16b","lang":"ja","lastmod":1406524740,"permalink":"https://blog.johtani.info/blog/2014/07/28/curator-2-0-and-1-1/","publishdate":"2014-07-28T14:19:00+09:00","summary":"Curatorの1.2.0がリリースされました。 前回のCuratorの記事が古くなってしまった（1.1.0からコマンドのI/Fが変更された）","tags":["elasticsearch","curator"],"title":"Curator 1.2および1.1について"},{"contents":"第5回Elasticsearch勉強会を開催しました。 遅くなってしまいましたが、まとめてみました。\n今回は、Elasticsearchに入って初の勉強会でした。タイミングが良いことに、Honza、Igor、Shayの3名がトレーニングのために 来日していたため、特別回ということにして、話をしてもらいました。\nそして、サムライズムの@yusukeさんにテキスト翻訳してもらいました。 早くて正確なタイピング＋翻訳、本当にありがとうございました。\n開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！ 参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\namazing turnout to the elasticsearch at Tokyo #elasticsearchjp pic.twitter.com/Aa88eVf5dF\n\u0026mdash; Shay Banon (@kimchy) 2014, 7月 14 動画があとで、アップされる予定です。お楽しみに。\nHonza\u0026rsquo;s talk djangoの開発者！であり、ElasticsearchのPythonクライアント、Curatorの開発者 Python Clientを利用しながら、ライブコーディングのような形で説明する方法が新鮮 Aggregationの便利さについての説明 Python Clientがクエリを組み立てるのにすごく便利そうだった Pythonユーザが結構いたので助かりましたｗ Igor\u0026rsquo;s talk スライド：elasticsearch data/\nSnapshot/Restoreの開発などを行っている開発者 Elasticsearchのデータ、ディレクトリ構造に関するお話 シャードの話から、ディレクトリ構造、メタデータに関する説明 transaction logの挙動の説明 検索のフェーズの説明 Igorは、実は私がElasticsearch社の人とコンタクトがとれた最初の人だと思います。 第1回Elasticsearch勉強会が開催する当日に帰国されるという不運だったのですが、1年越しでトークしてもらえました！\n@johtani I am so bummed! I am leaving Tokyo Thursday morning.\n\u0026mdash; Igor Motov (@imotov) 2013, 8月 27 QA ShayをメインにいくつかのQAをしてもらいました。 NetflixなどのMeetupの動画で見てたのですが、こんな形で日本でも実現できるとは。\nQ: なんで、ファイルデスクリプタの設定を大きくするの？ A: Luceneのインデックスは複数のセグメントから構成されている。メモリに作られたあと、ファイルにfsyncされる。 Q: KibanaでAggregation使いたいんだけど？ A: Kibana 4で対応するよ！異なるフィールドの値を1つのグラフにすることも出来るよ！ Q: なんでElasticsearch作ったの？ A: 暇だったからｗ奥さんのレシピ検索を作ってみようと思って作り始めて、Luceneを触って感動して。。。検索すげー、Compassってのを触ってこれもすごいと思いつつ、もっとLucene活用できるんじゃないかということでElasticsearch作ったんだ。奥さんのレシピ検索？まだ完成してないよｗ Q: 2000くらいスナップショット撮ったらパフォーマンスが悪くなっててなんで？ A: 差分でスナップショットを作るんだけど、差分の計算に昔のスナップショットを見るので、定期的に新しくしたほうがいい。もし、気になることがあったらIssue上げたりMLに投げてくれるとうれしい。\n（あとでちょっと聞いたけど、古いスナップショットを消すのも有効っぽい。差分でスナップショットを作るけど、昔のを消した場合は、新しいスナップショットが利用しているファイルは残る仕組みになっているから。） Q: Relevancyのチューニングってどうすればいい？ドキュメントが少なくない？ A: ドキュメンテーションは頑張ってるので、応援してねｗあとは、definitive guideも参考になるよ。スコアはfunction_scoreクエリがすごいのでいろいろ使ってね。MVELをGroovyに帰る予定。性能もだけど、サンドボックス的な意味もあります。 Q: 次のVisionは？現時点は検索だけど。（最後の質問がとてもナイスで、助かりましたｗ私がしたほうがいい気がするｗｗ） A: 今後はアナリティクスのプラットフォームに向かってる。Aggregationとかね。メモリ効率よくしたりしてるよ。あとは、Field-collapsionも実装中だよ。あと、マシンラーニングとかもね。データを探索するための機能を色々作ってくよ。障害性にも。チェックサム機能をLuceneに入れて、ESにも入れていく予定。Zenの機能も改善している。 まとめ 今週は、トレーニングがあったり、いろいろな打ち合わせがあったりと、テンパってたので至らない点が多かったかもしれないですが。。。 楽しんでいただけと思います。 数日、Shay、Honza、Igorと行動を共にして、本当に情熱のあるチームでユーザのことを気にかけているなと感じることができました。 少しでもその片鱗を勉強会で感じてもらえたんじゃないかと。特に、QAでのShayによる情熱が伝わったんじゃないかと。\n懇親会でも数人の方から、日本語のサポートを望んでいるという声も頂きました。 興味のある方は私までコンタクトいただければと。\nあと、@yusukeさんのテキスト翻訳が素晴らしくて、参加してもらった方たちも絶賛してました。 次回も英語スピーカーの場合に助けてもらえると嬉しいです（私もそこまで出来るように頑張ります）\nその他のブログ ブログ記事ありがとうございます！\n第5回elasticsearch勉強会にいってきました - はやさがたりない。 感想戦：aggrigation から見える検索エンジンの次 - 第5回 Elasticsearch勉強会 - よしだのブログ 「第5回elasticsearch勉強会 #elasticsearch #elasticsearchjp」（2014年07月14日）の参加メモ - uchimanajet7のメモ ","date":1405774320,"dir":"post/2014/","id":"e3e146469ed4318eaa2ffbca3510c054","lang":"ja","lastmod":1405774320,"permalink":"https://blog.johtani.info/blog/2014/07/19/hold-on-5th-elasticsearch-jp/","publishdate":"2014-07-19T21:52:00+09:00","summary":"第5回Elasticsearch勉強会を開催しました。 遅くなってしまいましたが、まとめてみました。 今回は、Elasticsearchに入って","tags":["elasticsearch","勉強会"],"title":"第5回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"ということで、転職しました。 どーしてもやりたいことが出てきたので、無理を言って転職することにしてみました。\nサムライズムではなく、Elasticsearchにジョインします。（というか、しました。）\n初出社 #サムライズム\n\u0026mdash; Jun Ohtani (@johtani) 2014, 7月 1 冗談でツイートしたのですが、その前に英語アカウントのツイートがRTされてしまっていまいちでした。。。\nスキポール空港 先週、アムステルダムに行っていたのも退職前に休みをいただき、Elasticsearchの全社会議に参加していたためです。 とてもエキサイティングな経験（英語漬けとか）ができ、もっと精進しないとなという気持ちにもなり、ますます頑張らないとなと。\nということで、今後は日本中にElasticsearchやLogstash、Kibanaを広めるべく、いろいろな場所で話をしたいと思います。 興味のある方は、声をかけていただければと。\nあと、東京でElasticsearchのCoreトレーニングが行われます。 通常は2日間ですが、通訳の方が付く関係で3日間の開催となっています。 開発者2名がトレーナーとして来日します。開発者に質問をできる良い機会ですので、興味のある方は参加してみてはいかがでしょうか。 また、CTOのShay Banonも来日する予定です。\nトレーナー2名とShayは7/14の勉強会でも話をしてくれます。 こちらも興味のある方は参加してみてください。（参加登録はこの後、すぐに開始します。）\nまだまだ、勉強しなければいけないことだらけですが、ElasticsearchのいろいろなプロダクトやOSSについて広めていきたいと思いますので、よろしくお願いいたします。\nおまけ ということで、一度やってみたかったのでリンクを貼ってみます。\nほしい物リストはこちら\n","date":1404181800,"dir":"post/2014/","id":"21a8e6324e9330d4f8ebade604c62b6e","lang":"ja","lastmod":1404181800,"permalink":"https://blog.johtani.info/blog/2014/07/01/join-elasticsearch/","publishdate":"2014-07-01T11:30:00+09:00","summary":"ということで、転職しました。 どーしてもやりたいことが出てきたので、無理を言って転職することにしてみました。 サムライズムではなく、Elasti","tags":["転職"],"title":"転職しました"},{"contents":"退職しました。\n色々と書きたいんですが、時差ボケで頭痛いので、このくらいです。 余裕出たら書くかも。\nほしい物リストはこちら\n新天地についてはまた明日。\n","date":1404137940,"dir":"post/2014/","id":"40abea0a87a64bd832a1fad69458b293","lang":"ja","lastmod":1404137940,"permalink":"https://blog.johtani.info/blog/2014/06/30/resignation/","publishdate":"2014-06-30T23:19:00+09:00","summary":"退職しました。 色々と書きたいんですが、時差ボケで頭痛いので、このくらいです。 余裕出たら書くかも。 ほしい物リストはこちら 新天地についてはまた明","tags":["転職"],"title":"退職しました"},{"contents":"Elasticsearch server 2nd editionが発売されています。\n私が翻訳したのは前のバージョンですが。。。 まずは、目次を元にどのくらい変わってるかを見てみました。 （全部まだ読んでなくて。。。）\n1章 Getting Started with the Elasticsearch Cluster 冒頭に、全文検索とは、転置インデックスとはどんなものか、 Luceneの簡単なアーキテクチャの仕組みについて説明が追加されています。 検索の仕組みを知らない人が読んでもわかりやすくなっています。\nインストール方法なども少し追記されています。 バージョニングと簡単なデータ登録と検索方法についてもここで触れられています。 検索結果の構造の説明もちょっとあります。 まず簡単に触ってみるというところまでが1章でまとめられた感じです。\n2章 Indexing Your Data 新しく、切りだされた形です。 前のバージョンでは1章で説明されていた、Mapping周りが切りだされています。 シャードやレプリカの説明もこちらです。\nIPアドレスタイプ（IPv4のみ）とtoken_countタイプの説明も追加されてます。 similarityやpostingsフォーマットなどは新しく追記されています。 また、メタフィールドと呼ばれる_typeなどはこちらに移動しているようです。 マージ処理などの説明も追記されています。このあたりは、Mastering ElasticSearchに 記載されているものが移植された感じでしょうか。\n3章 Searching Your Data 前のバージョンでは2章だった章です。 クエリについては1.0で追加されたsimple_query_stringなどが追記されています。 constant_scoreやdismaxなどもです。\nまた、前のバージョンの3章で説明されていたハイライトや8章で触れられていたvalidate APIについても 移動しています。\n4章 Extending Your Index Structure 前のバージョンの3章で触れられていた、データの構造に関する部分がこの章になります。 親子や配列、ネスト等のデータのインデックスや検索の方法です。\n5章 Make Your Search Better スクリプティングや言語判定などの仕組みが記載されています。 また、ブーストについても同様です。Synonymについてもここです。 スパンクエリについては省略されたのかな？\n6章 Beyond Full-text Searching 1.0の目玉機能の一つであるAggregationの説明から始まります。 その後、ファセットやPercolatorについてです。メモリに関する注意点もありそうです。 また、Geoについての説明がこちらに移動されていました。 scroll APIについてもこちらで説明されています。\n7章 Elasticsearch Cluster in Detail 前の7章で記載されていたElasticsearchの分散の仕組み（Node Discovery）についての記載があります。 また、1.0で追加されたcircuit breakerやスレッドプール、インデックスのリフレッシュレートなど、Mastering ElasticSearchの 内容も追記されている気がします。\nインデックスやマッピングのテンプレート機能についてもここで説明があるみたいです。\n8章 Administrating Your Cluster 1.0で追加されたsnapshot/restoreの説明から始まります。 あとは、前のバージョンの7章で説明されていたクラスタ管理用のAPIについての説明です。 いくつか（例えばcat API）、1.0で追加されています。\nまた、シャードのリバランスの話も追加されているようです。 エイリアスやプラグインの話はこちらに移動してるみたいです。\n感想 ということで、とりあえず、駆け足で目次ベースで違いを見てみました。 Mastering ElasticSearchでの 知見がフィードバックされ、しかも1.0（すでに1.3が出そうな勢いですが。。。）にバージョンアップされた内容になっています。 冒頭がわかりやすくなっているので、検索をやったことのない方にもおすすめな書籍になった気がします。 英語が苦にならなければ、おすすめの一冊だと思います。\n来月から読み進めるつもりなので、また、面白い内容があったら感想を書いていこうと思います。 （また翻訳できるといいかもなー）\n","date":1402908420,"dir":"post/2014/","id":"916bda59bc7621d5c1790c040572a3c0","lang":"ja","lastmod":1402908420,"permalink":"https://blog.johtani.info/blog/2014/06/16/first-impression-elasticsearch-server-2nd-edition/","publishdate":"2014-06-16T17:47:00+09:00","summary":"Elasticsearch server 2nd editionが発売されています。 私が翻訳したのは前のバージョンですが。。。 まずは、目次を元にどのくらい変わってるかを見てみました。 （","tags":["elasticsearch","本"],"title":"Elasticsearch server 2nd editionのファーストインプレッション"},{"contents":"可視化ツール現状確認会に参加して、カジュアルウォーターじゃなくて可視化ツールの現状を確認してきました。\nということで、いつものメモです。\nMackerel と Graphite について （y_uuk1さん） Graphite 時系列 工夫すればスケーラブル SensuやCollectdと組み合わせたり GrafanaとGrapheneでGUI Mackerel素敵だよと。 架空のわかりやすいグラフが見れた Kibana \u0026amp; Grafana \u0026amp; Influga （hakoberaさん） Kibana\nかっこいい。 JVM大変。 Grafana\nGraphiteがカッコ悪いのでKibanaをフォーク なぜか、ESが必要。 InfluxDBに浮気しそう Influga\n@haoberaさん作 InfluxDB Queryサポート 迷ったら、Kibana入れとけ。\nDistinctがKibana出できないけど、それ以外はある程度行けるらしい。\naggregationがサポートされたら、できると思う。 Kibana以外は、バックエンドがタイムシリーズなので、縛りがある\n可視化ツール紹介（仮） （showyouさん） 誰がチャートを作るの？ 誰が見るの？ 一覧化されてて、あとで眺めたい IPython Notebookのデモ R shiny Serverのデモ Pentaho CE+Saikuのデモはネットワークがダメだったので割愛 分析側の視点を見せたかったので。 可視化とは何だったのか （harukasanさん） インフラ モニタリング、アナライズ、可視化どれ？ 可視化は目的ではないよねと。 熱く、ユーザとサービスプロバイダ間の距離のお話。 ログ 生ファイルで残すのが重要 トータルで必要とか考えないといけないことがわかって面白かったｗ\nあなたの知らないrrdtool （shoichimasuharaさん） すげー！ いろいろできるらしい（ノートPCの前にいなかったｗ） D3.jsとジオマッピング （Takaki_さん） 時空間推進課！すげー！ ジオデータのおはなし。 TopoJSONとかGeoJSONとか Zipkinについて （synkさん） ものすごい数のJVMがThriftで殴りあってるらしい。 ZipkinはTwitterが作ったもの Brave、HTraceというのが、PureJava用のZipkinトレーシングプラグイン 見積もりする必要がないくらいでかいHBaseがあるので、そこにためてる。 まとめ LINEはエンジニアを大募集中 Graphiteについて (mickey19821 さん) ドリコムさんのGraphiteのおはなし Metricsの収集はCollectd Graphite-webがスケールできなくて困ってるらしい。 Graphiteで可視化ツラいｗ まとめ RRDTool最高\nあと、クックパッドの技術力がすごいという発表なんかもありました。\n","date":1401884100,"dir":"post/2014/","id":"5bb6f8322cdbda7a21e4aecbe04462b7","lang":"ja","lastmod":1401884100,"permalink":"https://blog.johtani.info/blog/2014/06/04/attending-visualize-study/","publishdate":"2014-06-04T21:15:00+09:00","summary":"可視化ツール現状確認会に参加して、カジュアルウォーターじゃなくて可視化ツールの現状を確認してきました。 ということで、いつものメモです。 Mackerel と Graphite","tags":["勉強会"],"title":"可視化ツール現状確認会に参加してきました。#可視化"},{"contents":"今月2回目の目黒で、初のドリコムさんです。 「最新インフラエンジニア技術勉強～Fluentd, Elasticsearch,Chefの実践実例～」に参加してきました。 もちろん、Elasticsearchってキーワードがあったからです。\nざっくりメモです。\nドリコムのInfrastructure as Code/ひらしーさん CM：jojoss、トレクル、など サーバ300台、クラウド○○台。月30〜50台の割合で増加中。 少人数でいかに回すか。 Chef Rubyが書ける人が多いから。 serverspec テストだよと。 すみません、色々と聞き逃しました。。。\nWinning the metrics battle/mickeyさん Graphiteとかを触っている。 1300台超えたら、色々大変だった。 失敗談 Cactiを利用して、色々と運用が大変だった。DCが別なのでProxyとか。 成功例？現行システム？ 最大値、平均値、最小値などをプロット collectdを収集、送信に採用して、独自で開発？ 受信して保存するのに、Graphite（carbon-relay、carbon-cache、DRBD、graphite-web）ってなってる。 1300台程度のサーバから、5分間隔で、問題ない。 Graphite良いツールだよ。 Q：過去データはどのくらい？ A：5分間隔で1年分。\nQ：移動平均とかを使ったグラフとか時間かかりませんか？100台だと A：100台でもほとんど時間はかからない。\nFluentd プラグイン開発講座/外山 寛さん Fluentdプラグインを作ることができると威力倍増 Elasticsearchの勉強会の話までしてくれました！ 勉強会スペース貸出しています。 未公開だけど、sedueのプラグインもあるらしい。 CHUNKとBUFFERとか覚えときましょう プラグインの作り方的なのがなかった気がしたので、今回の発表です。 gem作らなくてもディレクトリにおけば使えるよと。 td-agent使ってる人が大多数だよね。（fluentdを素で使ってる人は会場にはいなかった） エンジニア募集中 Q：エラー処理どうしてますか？ A：今は、スルーしています\nQ：単体テストの書き方は？ A：人によってバラバラみたいですね。\nMySQLと組み合わせて始める全文検索エンジン「elasticsearch」/yoshi_ken スライド：http://www.slideshare.net/y-ken/introduce-elasticsearch-mysql-importer\nElasticsearch歴は1年位です。\nMySQLを使っていて、モダンな検索がほしいですよね？ね？\nサジェスト、ファセット、位置情報、ネスト検索などなど。\nGoogleトレンドだとSolrに迫る勢いと。\n実データを用いて、手軽にElasticsearchと連携。\nBinaryLogではなく、SQLの結果を同意する方式。yamabiko\n今日は、新しいものを公開します。\nbulk import file generator as well as nested document from MySQL for elasticsearch bulk api 東京トレーニング\nElasticsearch本については、右にあるリンクをクリックしてくれるとうれしいなぁ。\n","date":1400840280,"dir":"post/2014/","id":"a578acf825a595ce95fe8f804b7208f0","lang":"ja","lastmod":1400840280,"permalink":"https://blog.johtani.info/blog/2014/05/23/attending-drecom-infra-study/","publishdate":"2014-05-23T19:18:00+09:00","summary":"今月2回目の目黒で、初のドリコムさんです。 「最新インフラエンジニア技術勉強～Fluentd, Elasticsearch,Chefの実践実例～","tags":["勉強会","elasticsearch"],"title":"最新インフラエンジニア技術勉強に参加しました。"},{"contents":"どうやら、中身がSolrベース？Luceneベース？になったらしいということで、 今日は「AWSプロダクトシリーズ｜よくわかるAmazon CloudSearch」に行ってきました。\n※ElasticSearchではありません！\nということで、いつものメモ。\nCloudSearch Overview Amazon Web Services, Inc. Pravin Muthukumar(Product Manager) / Vivek Sriram (Business Development) Introduction to Search 検索の紹介。アイアンマンのDVD？のページにいろんな項目（フィールド）があるよねと。（もちろん、Amazonのページ） ファセット、Geo、テキスト処理（Analysis処理）、Postings listとか。とかとか ランキングも Amazon CloudSearch 独自実装orRDB拡張もある。 OSSもあるよね。 Legacy Enterprise SearchとしてFASTとかもある。 Building with CloudSearch 他のサービス同様、コンソールとかあるし、色々できるし、すぐ起動できるよと。 自動で、データが増えたら、パーティションが増えると。\n日本語の形態素解析があるらしい。何を使ってるのかな？ ICUのノーマライズとかもやってくれるらしい。これかな？http://lucene.apache.org/core/4_8_0/analyzers-icu/index.html ユーザが辞書を指定できるのかな？ 備えてる機能の説明\nファセット SimpleQuery Autocomplete Highlight などなど\nMulti-AZにも対応 QA Q：NGramありますか？ A：今はないです。 Q：ユーザ辞書対応してますか？ A：今はないです。 Q：lang-detectあるか？ A：今はないので、自分で判定して、適切なフィールドに入れてね。 Expectation for CloudSearch Apache Solr contributor　大須賀　稔氏 Solr本の宣伝ありがとうございます！（右のアイコンから買ってもらえると更に嬉しいですｗ） Kinesisとかとの組み合わせとか、自然言語処理とか、いろいろとあるAWSのコンポーネントと組み合わせる例が欲しいと。 すばらしい、最後はManifoldCFがらみに持っていくとは。ACLがらみのクローリングとかあるといいじゃないでしょうかと。 Impression of using CloudSearch 吉田　匠氏　(@yoshi0309　http://blog.yoslab.com/) スライド：https://speakerdeck.com/yoshi0309/impression-of-using-cloudsearch\nお見かけしたことある気がするなぁ。 全部置き換えできる！わけではなさそう。。。 いいところ。 UIがいいし、セットアップが簡単 auto scaleがうれしい マルチドメイン、マルチスキーマがいい Luceneのdismaxサポートがいい。（edismaxじゃないのかな？） dismaxって書いてあるな。\nhttp://docs.aws.amazon.com/cloudsearch/latest/developerguide/search-api.html\nフィードの仕方に気をつけて！\nバッチサイズで課金されるので、1件ずつじゃなくて、複数件送ったほうがいい。 いきなりスケールアウトできるわけじゃない？\nウォームアップ機能がない。インスタンス上限がデフォルト50件\nVPC対応してほしい。\nインターネット経由になってしまう フィードのスピードが セキュリティグループ機能が使えない CloudSearch UseCase - SnapDish Vuzz Inc.　清田　史和氏 独自辞書をもって、Tokenizeは独自でやって、空白区切りでデータ登録している。 インデックス更新はSQSを使ってる。 古いAPIを使ってるらしい。 移行が結構大変らしい。 感想 使ったことないんですが、きめ細かい検索したい場合はちょっとテクニックが要るかもと思いました。 AWS初心者なんで、なんとも言えないんですが。。。\nといあえず、テキスト処理（アナライズ処理）で、単語がどうやって区切られるのかってのがわからないのはキツイんじゃなかろうかと。 ただ、簡単に起動できて、オートスケールできるのは素晴らしいと思います。\n","date":1400143800,"dir":"post/2014/","id":"706c033b4483b6d062b66d6e4ea0236a","lang":"ja","lastmod":1400143800,"permalink":"https://blog.johtani.info/blog/2014/05/15/amazon-cloud-seaarch-study-session/","publishdate":"2014-05-15T17:50:00+09:00","summary":"どうやら、中身がSolrベース？Luceneベース？になったらしいということで、 今日は「AWSプロダクトシリーズ｜よくわかるAmazon Cl","tags":["勉強会","CloudSearch","AWS"],"title":"「よくわかるAmazon #CloudSearch 」に行ってきました！"},{"contents":"酔っ払ってなんとなく書きたくなったスピリチュアルなブログなので、流していただければと。\n最近、勉強会やTwitterで知り合いになって話をする人が増えたりで、 その方たちに色々と教えてもらうことが多いなぁと感じてます。 また、知り合いに恵まれてきたなぁとも。\nそもそも私が勉強会に参加し始めたきっかけはSolr勉強会（第1回から参加してて、気づいたら主催者になってた）で、 そのころは、Solr初心者で色々とやってる人、知ってる人がいて無料で話が聞けるのすごいと興奮したのを覚えてます。 （もちろん、ぼっちでしたが）\nSolr勉強会が定期的に開かれて、それに参加しているうちに少しずつ知り合いもできて、 面白そうな勉強会（Hadoopとか）が他にもあるんだ、参加してみようかって思うようになってと。\nそこにプラスで、関口さんと知りあえてSolr本を書く話が出てきて、本を書いてみたら、 今度は勉強会で話してみませんかとなって。\nスピーカーやると、顔を覚えてもらえるようで、また知り合いが増えてと。\n人のつながりって大事だし、自分が発信することで教えてもらえることもあるしと。 前にも書いた気がするけど、Solr勉強会（当時の主催の方）や関口さんやElasticsearch勉強会のスタッフの方や スピーカーやってくれた方、会場提供を心よくしてくれてるVOYAGE GROUP、リクルートテクノロジーズさん、という具合にどんどん頭が上がらなくなってきてるなぁと。\nということで、外の世界を知ると色々とつながりが出来て面白いですよという、個人的な感想でした。 ま、自分が思ってるだけで、違う意見もいっぱいあると思うけど。\nあー、なんか、酔って勢いで書いてしまった。。。 脈略のない文章なきがするけど、エイヤで公開しちゃおう。\n","date":1399999440,"dir":"post/2014/","id":"72df0bf7853e05560d94208817b83468","lang":"ja","lastmod":1399999440,"permalink":"https://blog.johtani.info/blog/2014/05/14/spiritual-entry1/","publishdate":"2014-05-14T01:44:00+09:00","summary":"酔っ払ってなんとなく書きたくなったスピリチュアルなブログなので、流していただければと。 最近、勉強会やTwitterで知り合いになって話をする","tags":["スピリチュアル"],"title":"外の世界を知るということ"},{"contents":"「アジャイルデータサイエンス」の見本をいただいてしまいました。\nなので、感想文でも書いてみようかと。\nどんな本？ 想像以上に薄かったです、物理的に。 なのに、とても幅広い範囲をカバーしています。\nデータの分析にどんな人が関わっているのか、アジャイルにデータを分析する目的から始まり、 データから何かを見つけるための手順、考え方などをさらっとですが、 システムに取り込む流れから取り込んだあとに改良するという流れまで紹介してくれます。 流れはこんな感じ。\nイベント：ログとかのイベントの発生 コレクタ：イベントの収集 バルクストレージ：イベントの一時保存 バッチ処理：ストレージにあるデータに対して処理 分散ストア：処理結果をWebアプリなどで表示するために保存 Webアプリ：処理結果をユーザに提供 Webアプリでデータを見えるようにして、そこから更にフィードバックを受けることで、データの分析などを進めていくという流れです。\n私はデータサイエンス系の人ではないのでこの流れで作業をされているかはわからないのですが、 検索のシステムについてもこの流れに似ているなと感じました。\n検索システムでも、検索したいデータを収集して、加工（検索したい項目の洗い出しやファセットにする項目の選定とか）して、 インデックスを生成するといった処理が必要になるからです。\nこの本では、Python、Hadoop（Pig）、MongoDB、ElasticSearch（バージョンが0.90だから）、d3.jsなどが出てきます。 また、日本語版の付録では、Fluentd、Kibana+Elasticsearchといった組み合わせの紹介もあります。\nコードも書かれていますが、すみません、そこまでちゃんと読んでません。。。\n後半では、データを活用して行くためには順序があるという話が書かれています。\nレコード：レコード1件のアトミックな処理と表示 グラフ：レコードを元に集計したりグラフ作ったり レポート：関係性やトレンドを抽出し、インタラクティブに探求 予測：構造を利用して、推論やレコメンドとか 行動：上記の結果を元にユーザに行動を促す 前のステップがおろそかだと次のステップがうまくいかないという話です。 後半はこの流れに沿って、先ほどのシステムの流れを変更していく方法が展開されます。\n注意点 ちょっとだけ気になる点があったので。\nElasticsearch周りについては少し注意が必要かと。（Pigとかは詳しくないので不明です。） 紹介されているElasticsearchのバージョンが0.90と少し古いのと、 Hadoopとの統合（Pigで処理したデータをElasticsearchに出力）に利用されているWondordogというツールも最近更新がされていないみたいです。 おそらく、1.0系では動かないのではないかと。\n1.0系の場合は、Elasticsearchが提供しているelasticsearch-hadoopを利用するのが良いと思います。\n付録については1.0系で記載されているので問題ないかと。ただし、Elasticsearchは更新が早いので、公式サイトで最新情報を入手するのが良いと思います。\n感想 データを解析するシステムってどんなことやってるの？という全体像を 俯瞰するのに良い本なのではないかと思います。 また、データの解析を活かすために、必要な順序と疎かにできない点もあって面白かったです。\n紹介されているツール類については、OSSのトレンドや開発速度が早いので、参考程度にとどめておいて、 自分たちで使いやすいものを探してきて検討するのがいいと思います。\n付録がとても豪華です。FluentdやKibanaがわかりやすく解説されてます。\nあと、薄いのでさらっと読めます。ｗ\n","date":1399563900,"dir":"post/2014/","id":"91fe03f994e8e85cede4e3bd62f4d6b7","lang":"ja","lastmod":1399563900,"permalink":"https://blog.johtani.info/blog/2014/05/09/reading-agile-data-science/","publishdate":"2014-05-09T00:45:00+09:00","summary":"「アジャイルデータサイエンス」の見本をいただいてしまいました。 なので、感想文でも書いてみようかと。 どんな本？ 想像以上に薄かったです、物理的に","tags":["感想文","オライリー"],"title":"アジャイルデータサイエンスが届きました"},{"contents":"こんなツイートを見つけたので、Aggregationのサンプルでも書こうかなと。（前から書こうと思ってたんですが。。。）\n@elasticsearch Hi, Would you please tell me the way to do \u0026quot;Pivot Faceting\u0026quot; like Solr-4.0 in elasticsearch-1.1.1 or prior version? Thank you.\n\u0026mdash; Y.Kentaro (@yoshi_ken) 2014, 5月 2 ちなみに、Aggregationは1.0.0から導入された機能なので、ElasticSearch Server日本語版には掲載されていない機能になります。（ごめんなさい）\n公式ガイドのAggregationsのページはこちらになりますが、実例があったほうがいいかなと。\n@yoshi_ken さんから実例のサンプルの指定もいただいたので、ブログを書くのが非常に楽です。ありがとうございます。\n問題 元ネタ（gist）\n次のような不動産系のデータがあるとします。\nid 物件名 都道府県（東京、神奈川、\u0026hellip;..） 物件種別（賃貸、売買、\u0026hellip;..） この時、都道府県別に、物件種別ごとの件数を取得したいという趣旨です。\n東京 賃貸: xxx件 売買: yyy件 神奈川 賃貸: xxx件 売買: yyy件 \u0026hellip; これを、Elasticsearchでどうやって取得するかという問題です。\nインデックスとデータの登録 まずは、インデックスを作ります。 あくまでもサンプルなので、全部not_analyzedにしてますが、そのへんは適宜変更してください。\n# create index PUT /pref_aggs { \u0026#34;settings\u0026#34;: { \u0026#34;number_of_shards\u0026#34;: 2 }, \u0026#34;mappings\u0026#34;: { \u0026#34;japan\u0026#34; : { \u0026#34;_id\u0026#34; : { \u0026#34;path\u0026#34; : \u0026#34;id\u0026#34; }, \u0026#34;properties\u0026#34;: { \u0026#34;id\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;}, \u0026#34;name\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;}, \u0026#34;pref\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;}, \u0026#34;type\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;} } } } } _idを使用して、データ登録時にidフィールドにある文字列をそのままIDとして登録できるように指定してあります。\n登録するデータは次のようなものを適当に100件程度作ってりました。\n{\u0026#34;id\u0026#34;: \u0026#34;id0\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name0\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;01_北海道\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;売買\u0026#34;} {\u0026#34;id\u0026#34;: \u0026#34;id1\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name1\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;09_栃木県\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;売買\u0026#34;} {\u0026#34;id\u0026#34;: \u0026#34;id2\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name2\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;38_愛媛県\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;賃貸\u0026#34;} {\u0026#34;id\u0026#34;: \u0026#34;id3\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name3\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;40_福岡県\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;賃貸\u0026#34;} {\u0026#34;id\u0026#34;: \u0026#34;id4\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name4\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;35_山口県\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;売買\u0026#34;} {\u0026#34;id\u0026#34;: \u0026#34;id5\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name5\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;12_千葉県\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;賃貸\u0026#34;} ... データの登録には、前に紹介した方法「stream2esと複数データの登録」を用いました。\nファセット このようなデータがある場合に、まず思いつくのはファセットによる取得です。 いささか強引ですが。。。\nGET /pref_aggs/japan/_search { \u0026#34;size\u0026#34;: 0, \u0026#34;query\u0026#34;: { \u0026#34;match_all\u0026#34;: {} }, \u0026#34;facets\u0026#34;: { \u0026#34;type_賃貸\u0026#34;: { \u0026#34;terms\u0026#34;: { \u0026#34;order\u0026#34;: \u0026#34;term\u0026#34;, \u0026#34;field\u0026#34;: \u0026#34;pref\u0026#34;, \u0026#34;size\u0026#34;: 50 }, \u0026#34;facet_filter\u0026#34;: {\u0026#34;term\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;賃貸\u0026#34; }} }, \u0026#34;type_売買\u0026#34;: { \u0026#34;terms\u0026#34;: { \u0026#34;order\u0026#34;: \u0026#34;term\u0026#34;, \u0026#34;field\u0026#34;: \u0026#34;pref\u0026#34;, \u0026#34;size\u0026#34;: 50 }, \u0026#34;facet_filter\u0026#34;: {\u0026#34;term\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;売買\u0026#34; }} } } } facet_filterを使用して、typeフィールドによる個別の絞込を行っています。 あとは、prefフィールドのファセットを取得すれば、出力は次のようになります。\n{ \u0026#34;took\u0026#34;: 6, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 2, \u0026#34;successful\u0026#34;: 2, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 100, \u0026#34;max_score\u0026#34;: 0, \u0026#34;hits\u0026#34;: [] }, \u0026#34;facets\u0026#34;: { \u0026#34;type_賃貸\u0026#34;: { \u0026#34;_type\u0026#34;: \u0026#34;terms\u0026#34;, \u0026#34;missing\u0026#34;: 0, \u0026#34;total\u0026#34;: 52, \u0026#34;other\u0026#34;: 0, \u0026#34;terms\u0026#34;: [ { \u0026#34;term\u0026#34;: \u0026#34;00_北海道\u0026#34;, \u0026#34;count\u0026#34;: 1 }, { \u0026#34;term\u0026#34;: \u0026#34;01_青森県\u0026#34;, \u0026#34;count\u0026#34;: 2 }, { \u0026#34;term\u0026#34;: \u0026#34;03_宮城県\u0026#34;, \u0026#34;count\u0026#34;: 3 }, ... }, \u0026#34;type_売買\u0026#34;: { \u0026#34;_type\u0026#34;: \u0026#34;terms\u0026#34;, \u0026#34;missing\u0026#34;: 0, \u0026#34;total\u0026#34;: 48, \u0026#34;other\u0026#34;: 0, \u0026#34;terms\u0026#34;: [ { \u0026#34;term\u0026#34;: \u0026#34;00_北海道\u0026#34;, \u0026#34;count\u0026#34;: 2 }, { \u0026#34;term\u0026#34;: \u0026#34;02_岩手県\u0026#34;, \u0026#34;count\u0026#34;: 1 }, { \u0026#34;term\u0026#34;: \u0026#34;04_秋田県\u0026#34;, \u0026#34;count\u0026#34;: 1 }, ... } 望んでいた形式とは少し異なりますが、facet_filterする回数を少なくするため、 ファセットは都道府県のフィールドを指定したためです。 アプリで頑張って入れ替えてください。。。\nこの場合、\u0026rsquo;type\u0026rsquo;の個数がわかっているので、頑張ってこのような記述ができました。 ただ、typeが増えた時にアプリの修正とかが必要になりますよね。\nAggregations ということで、Aggregationsの出番です。 ファセットよりも柔軟に、検索結果に対していろいろな集計が行える機能になります。 一見に如かずということで、クエリを紹介します。\nGET /pref_aggs/japan/_search { \u0026#34;size\u0026#34;: 0, \u0026#34;query\u0026#34;: { \u0026#34;match_all\u0026#34;: {} }, \u0026#34;aggs\u0026#34;: { \u0026#34;pref\u0026#34;: { \u0026#34;terms\u0026#34;: { \u0026#34;order\u0026#34;: { \u0026#34;_term\u0026#34;: \u0026#34;asc\u0026#34; }, \u0026#34;field\u0026#34;: \u0026#34;pref\u0026#34;, \u0026#34;size\u0026#34;: 50 }, \u0026#34;aggs\u0026#34;: { \u0026#34;type\u0026#34;: { \u0026#34;terms\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;type\u0026#34;, \u0026#34;size\u0026#34;: 10 } } } } } } ファセットよりもシンプルですし、賃貸といったような値を指定していません。 aggsというのがaggregations機能を指定している部分になります。 検索結果は次のように出力されます。\n{ \u0026#34;took\u0026#34;: 4, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 2, \u0026#34;successful\u0026#34;: 2, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 100, \u0026#34;max_score\u0026#34;: 0, \u0026#34;hits\u0026#34;: [] }, \u0026#34;aggregations\u0026#34;: { \u0026#34;pref\u0026#34;: { \u0026#34;buckets\u0026#34;: [ { \u0026#34;key\u0026#34;: \u0026#34;00_北海道\u0026#34;, \u0026#34;doc_count\u0026#34;: 3, \u0026#34;type\u0026#34;: { \u0026#34;buckets\u0026#34;: [ { \u0026#34;key\u0026#34;: \u0026#34;売買\u0026#34;, \u0026#34;doc_count\u0026#34;: 2 }, { \u0026#34;key\u0026#34;: \u0026#34;賃貸\u0026#34;, \u0026#34;doc_count\u0026#34;: 1 } ] } }, { \u0026#34;key\u0026#34;: \u0026#34;01_青森県\u0026#34;, \u0026#34;doc_count\u0026#34;: 2, \u0026#34;type\u0026#34;: { \u0026#34;buckets\u0026#34;: [ { \u0026#34;key\u0026#34;: \u0026#34;賃貸\u0026#34;, \u0026#34;doc_count\u0026#34;: 2 } ] } }, ... Aggregationsの結果は、望んでいた通りの出力になっています。\nクエリの構成を見てみましょう。\n\u0026#34;aggs\u0026#34;: { \u0026#34;pref\u0026#34;: { #1 \u0026#34;terms\u0026#34;: { \u0026#34;order\u0026#34;: { \u0026#34;_term\u0026#34;: \u0026#34;asc\u0026#34; }, \u0026#34;field\u0026#34;: \u0026#34;pref\u0026#34;, \u0026#34;size\u0026#34;: 50 }, \u0026#34;aggs\u0026#34;: { #2 \u0026#34;type\u0026#34;: { \u0026#34;terms\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;type\u0026#34;, \u0026#34;size\u0026#34;: 10 } } } } } 最初の#1のprefは出力を扱いやすくするためにつけているラベルになります。好きな名前をつけることが可能です。 次のtermsがAggregationのタイプ（どのような集計をして欲しいか）になります。 今回は、prefフィールドにある単語(term)毎に、集計をしたいので、termsを指定します。 その他にどんなタイプがあるかは、公式ガイドをご覧ください。\n次に、さらにtypeフィールドで集計したいので、#2の部分で後続のAggregationを指定しています。 都道府県同様、typeフィールドにある単語毎に集計するために、termsを指定します。\nこれで、先ほどのような結果が出力できます。 ちなみに、さらにtypeの中に他の種別で集計したいという場合は、さらにaggsを追加していけばOKです。\nAggregationは非常に柔軟な集計を可能にする機能です。ただし、検索結果に対して集計処理を行っているため、 メモリやCPUなどのリソースを消費するので注意が必要です。\nAggregationの説明については、こちらのFound.noのブログ（英語）がわかりやすかったので参考にしてみてください。\nまとめ 非常に簡単ですが、Aggregationsについて紹介しました。 その他にもAggregationsでできることがあるので、後日別のサンプルを用意して説明しようかと思います。\n100件のデータやここまでの操作については、gistにあるので、興味がある方はご覧いただければと。 stream2esの操作以外は、Marvelに付属のsenseを利用しています。\n","date":1399456620,"dir":"post/2014/","id":"ed4f5a398056eef1cf6caa90786b340a","lang":"ja","lastmod":1399456620,"permalink":"https://blog.johtani.info/blog/2014/05/07/aggregation-example/","publishdate":"2014-05-07T18:57:00+09:00","summary":"こんなツイートを見つけたので、Aggregationのサンプルでも書こうかなと。（前から書こうと思ってたんですが。。。） @elasticsearch Hi, Would you please tell me the way to","tags":["elasticsearch"],"title":"Aggregations - ファセットよりも柔軟な集計"},{"contents":"今日はelasticsearch-kopfのAnalysis画面の紹介です。\n（簡単なところから。。。その３）\nちょっとあいだが開いてしまいましたが、再開です。 メニューのaliasesを選択すると、次のような画面が表示されます。\nAliases画面 Elasticsearchのaliasを画面で確認できます。\nエイリアスは、インデックスに別名をつけることができるElasticsearchの機能です。 １エイリアス＝１インデックスでも良いですが、１エイリアスに対して複数のエイリアスを付与することもできます。 この機能を利用することで、次のようなことが可能となります。\nインデックスの切り替えをアプリ側に意識させずに実施（アプリはエイリアス名に対して検索すればOKなので） 直近１週間のログを検索するためのエイリアスの作成（複数のインデックスを１つのエイリアスに割り当て可能） 特定のルーティングによる検索（特定のデータに対する検索だけに絞るためにfilterを指定する） エイリアスについて詳しく知りたい方は公式ガイドをご覧いただくのが良いかと。\n画面は非常にわかりやすい作りになっているので、特に説明必要ないんですよね。。。\n","date":1399132860,"dir":"post/2014/","id":"2824bef72110575c78aeb979170212b8","lang":"ja","lastmod":1399132860,"permalink":"https://blog.johtani.info/blog/2014/05/04/intro-elasticsearch-kopf-alias-percolator/","publishdate":"2014-05-04T01:01:00+09:00","summary":"今日はelasticsearch-kopfのAnalysis画面の紹介です。 （簡単なところから。。。その３） ちょっとあいだが開いてしまいまし","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（aliases画面）"},{"contents":"kopfの記事の続きも書く必要があるんだけど、こんなツイートを見つけてしまったので。。。\nElasticsearchのBulk APIの仕様、JSONファイルをいい感じに加工して置かなければならないしハマりどころ多い。 http://t.co/hmfycqZlqk\n\u0026mdash; Kenta Suzuki (@suzu_v) 2014, 4月 24 前に思いついたけど、放ったらかしにしてた疑問が再浮上してきたので、せっかくだから調べてみようかなと。\n複数JSONデータがある場合にもっと楽にデータを入れる方法ないかなぁと思って、これかな？というのがあったのですが、 そのまま手を動かさずに放置してたので、一念発起してブログ書いてます。\nBulk APIって？ ElasticsearchはURLにアクセスしてデータを登録できます。 基本的には次のように1件毎の登録になります。\n$ curl -XPUT http://localhost:9200/bookshop/books/1 -d \u0026#39; { \u0026#34;book_id\u0026#34; : 1, \u0026#34;title\u0026#34; : \u0026#34;ElasticSearch Server Japanese Edition\u0026#34;, \u0026#34;price\u0026#34; : 3024, \u0026#34;publisher\u0026#34; : \u0026#34;KADOKAWA\u0026#34; }\u0026#39; これでもいいのですが、大量のデータを登録するときは、Elasticsearch側での効率が悪いです。 そこで、Elasticsearchは大量データを登録するためにBulk APIというものを用意しています。\nこれは、次のような形式のJSONを作ってデータを登録します。\n{ \u0026#34;index\u0026#34; : { \u0026#34;_index\u0026#34; : \u0026#34;bookshop\u0026#34;, \u0026#34;_type\u0026#34; : \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34; : \u0026#34;1\u0026#34; } } { \u0026#34;book_id\u0026#34; : 1, \u0026#34;title\u0026#34; : \u0026#34;ElasticSearch Server Japanese Edition\u0026#34;, \u0026#34;price\u0026#34; : 3024, \u0026#34;publisher\u0026#34; : \u0026#34;KADOKAWA\u0026#34;} { \u0026#34;index\u0026#34; : { \u0026#34;_index\u0026#34; : \u0026#34;bookshop\u0026#34;, \u0026#34;_type\u0026#34; : \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34; : \u0026#34;2\u0026#34; } } { \u0026#34;book_id\u0026#34; : 2, \u0026#34;title\u0026#34; : \u0026#34;Introduction of Apache Solr\u0026#34;, \u0026#34;price\u0026#34; : 3888, \u0026#34;publisher\u0026#34; : \u0026#34;gihyo\u0026#34;} これは、次のような構成になっています。\nコマンド データ コマンド データ ... これで効率よくデータが登録できるのですが、このようなJSONデータを別途作って上げる必要が出てきます。 結局、複数のJSONがあるのに、特殊なJSONを生成しないといけないということでプログラム書いて実行することになります。 これだと、Elasticsearchへのアクセスをプログラムで書くのとあまり大差がないかもしれません。\nstream2es もっとお手軽に複数のJSONを登録できないかな？と目をつけていたのが、stream2esです。\nどんなもの？ Clojureで作られた、Elasticsearchにデータを流し込むためのツールです。 Java 7がインストールされていれば、ダウンロードしてくれば動作せることができます。\nインストール 公式ページに載っている方法そのままです。\n$ curl -O download.elasticsearch.org/stream2es/stream2es; chmod +x stream2es 実行したディレクトリにコマンドがコピーされます。 あとは、コマンドを実行すればOKです。\n実行 データは次のような形式でsample.jsonに保存してあるとします。\n{ \u0026#34;book_id\u0026#34; : 1, \u0026#34;title\u0026#34; : \u0026#34;ElasticSearch Server Japanese Edition\u0026#34;, \u0026#34;price\u0026#34; : 3024, \u0026#34;publisher\u0026#34; : \u0026#34;KADOKAWA\u0026#34;} { \u0026#34;book_id\u0026#34; : 2, \u0026#34;title\u0026#34; : \u0026#34;Introduction of Apache Solr\u0026#34;, \u0026#34;price\u0026#34; : 3888, \u0026#34;publisher\u0026#34; : \u0026#34;gihyo\u0026#34;} 先ほどのBulk APIで利用したJSONよりも、スッキリしていますね。 1行1ドキュメント1JSONです。\nあとは、次のコマンドを実行するだけです。\n$ ./stream2es stdin --target http://localhost:9200/bookshop/books \u0026lt; sample.json ファイルをstream2esに流し込んで、stream2esが1行ずつパースして、Elasticsearchに投げ込んでくれます。\n登録されたデータは次のようになります。 IDは自動で付与されています。\n{ \u0026#34;_index\u0026#34;: \u0026#34;bookstore\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;0Hvy4IJCRkKrvGb4Dgam_w\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;book_id\u0026#34;: 1, \u0026#34;title\u0026#34;: \u0026#34;ElasticSearch Server Japanese Edition\u0026#34;, \u0026#34;price\u0026#34;: 3024, \u0026#34;publisher\u0026#34;: \u0026#34;KADOKAWA\u0026#34; } }, { \u0026#34;_index\u0026#34;: \u0026#34;bookstore\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;b9M6TooFQzGYyJeix_t_WA\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;book_id\u0026#34;: 2, \u0026#34;title\u0026#34;: \u0026#34;Introduction of Apache Solr\u0026#34;, \u0026#34;price\u0026#34;: 3888, \u0026#34;publisher\u0026#34;: \u0026#34;gihyo\u0026#34; } } せっかく、book_idがあるんだし、_idをインデックスの設定に指定します。\n$ curl -XDELETE http://localhost:9200/bookshop $ curl -XPUT http://localhost:9200/bookshop -d \u0026#39; { \u0026#34;mappings\u0026#34;: { \u0026#34;books\u0026#34; : { \u0026#34;_id\u0026#34; : { \u0026#34;path\u0026#34;: \u0026#34;book_id\u0026#34; } } } }\u0026#39; あとは、登録すればbook_idが_idに採用されます。\n{ \u0026#34;_index\u0026#34;: \u0026#34;bookshop\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;book_id\u0026#34;: 1, \u0026#34;title\u0026#34;: \u0026#34;ElasticSearch Server Japanese Edition\u0026#34;, \u0026#34;price\u0026#34;: 3024, \u0026#34;publisher\u0026#34;: \u0026#34;KADOKAWA\u0026#34; } }, { \u0026#34;_index\u0026#34;: \u0026#34;bookshop\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;book_id\u0026#34;: 2, \u0026#34;title\u0026#34;: \u0026#34;Introduction of Apache Solr\u0026#34;, \u0026#34;price\u0026#34;: 3888, \u0026#34;publisher\u0026#34;: \u0026#34;gihyo\u0026#34; } } 複数ファイル ディレクトリに複数のJSONファイルが有った場合は、次のようなコマンドでOK\n$ cat sample_data/*.json |./stream2es stdin --target http://localhost:9200/bookshop/books まぁ、catして流してるだけですが。。。\nダメだったケース JSONが複数行になっているようなデータだとエラーが出てしまいました。\n（jqコマンドで1行に整形したりできるかなぁ？）\nまた、1行に2つのJSONが書いてある場合は、1つ目のJSONをパースしたら、そこでおしまいみたいで、その後に記述されたデータは登録されませんでした。\nインデックスがない場合 stream2esで登録するインデックスがElasticsearchに存在しない場合、stream2esがインデックスを作成してくれるのですが、 この時、シャード数などはstream2es内部に記述があるので注意が必要です。 以下がその設定です。\nindex.number_of_shards : 2 index.number_of_replicas : 0 index.refresh_interval : 5s 課題？ 内部的にはおそらく、Bulkでデータを登録していると思うのですが、まだよくわかっていません。 Clojureが読めないので、せっかくだから、Clojureの勉強も兼ねてちょっとソースを読んでみようかなと思います。 それほど量があるわけでもないので。\nあとは、その他にWikipediaのデータやTwitterのデータ登録、 ElasticsearchからデータをScrollで読み出しつつ、別のElasticsearchに流しこむといったこともできそうなので、そちらも試してみようかと。 他にもオプションがいくつかありそうです。\n今回は2件ほどでしたが、大量データを流し込んだ時にどうなるか（stream2esが悲鳴を上げるのか、Elasticsearchで詰まることがあったらどうなるか）なども 気になるので、なんか適当なデータで試してみるのもいいかなぁと。 （ということで、だれか、いろいろ試してみてもらえると楽できるなぁ。）\n","date":1398341460,"dir":"post/2014/","id":"e396cbf9274b590a1d94ee43d823a0bd","lang":"ja","lastmod":1398341460,"permalink":"https://blog.johtani.info/blog/2014/04/24/usage-stream2es/","publishdate":"2014-04-24T21:11:00+09:00","summary":"kopfの記事の続きも書く必要があるんだけど、こんなツイートを見つけてしまったので。。。 ElasticsearchのBulk APIの仕様、J","tags":["elasticsearch","stream2es"],"title":"stream2esと複数データの登録"},{"contents":"第4回Elsticsearch勉強会を開催しました。 今回から、遅刻厳禁にしてみました。 それほど困った人もいないと思うので、次回からも遅刻厳禁で。\nということで、今回も多数の方にお集まりいただきありがとうございました。\nスタッフの皆さん、スピーカーの皆さん、プレゼント用に書籍を用意してくれたKADOKAWAさん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！ 参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\nさて、ブログですが司会業とかやってたので、あんまり書けてないけど。。。\n134番までチケットがはけていたので＋スタッフで140〜150名くらいの参加者だったのではないかと思います。 懇親会まで残っていただいた方々も片付けなどありがとうございました。\nさて、感想とか補足です。\n「アナライズ処理の仕組みとクエリDSL」株式会社シーマーク　大谷　純　@johtani スライド：アナライズ処理の仕組みとクエリDSL※スライドはPDFです。\nプラグイン：elasticsearch-extended-analyze\nプラグインの紹介記事：http://blog.johtani.info/blog/2013/10/25/developing-es-extended-analyze-plugin/\nMarvel：http://www.elasticsearch.com/marvel/\n日本語版メーリングリスト：https://groups.google.com/forum/#!forum/elasticsearch-jp\nなんか、宣伝（本＋プラグイン）ばっかりですみません。 「プラグインの紹介記事」に簡単な使い方が書いてあります。が、情報が古いので、Elasticsearchのバージョンに合わせたバージョンを使ってください。\nまだまだ発表に慣れてないので、頑張ろ。\nアンケート取ってみましたが、ログ検索と全文検索と半々くらいで興味がある人がいるみたいでした。 あと、有料トレーニングは人気ないっすね。。。\n「elasticsearch-hadoopを使ってごにょごにょしてみる」 株式会社マーズフラッグ R\u0026amp;D部　やまかつ さん　@yamakatu スライド：elasticsearch-hadoopを使ってごにょごにょしてみる\nelasticsearch-hadoop：https://github.com/elasticsearch/elasticsearch-hadoop\nQAとして、Elasticsearchにプライマリデータを保存するのは的な話が出てました。 ESにのみデータを入れるのは個人的には考えたことないかなぁ。 どうしても、ElasticsearchのWriteが遅いんじゃないかという懸念事項を持ってる人がいるなぁと。（実際ツラいという話もちらほら）\nお腹痛い中の発表ありがとうございました。。。 次回はMapRの方に紹介してもらえそう（交渉中）なので楽しみです。やまかつさんの続きも聞きたいなぁ。\n「CouchbaseとElasticsearchが手を結んだら」株式会社アットウェア 佐竹雅央さん @madgaoh 河村康爾さん @ijokarumawak スライド：CouchbaseとElasticsearchが手を結んだら\nCouchbaseのElasticsearchに関するページ：http://docs.couchbase.com/couchbase-elastic-search/\nCouchbaseに入れたら、自動的にElasticsearchにもデータを入れてくれる。 デモがあるの、いいっすね。\n最新版はmasterを落としてきてビルドしないとダメらしい。確かに、上のページには0.90.5って書かれてる。 ここでも、やはり、Elasticsearchが詰まった時にどうするの？みたいな話が出てました。 CouchbaseのXDCRだと、後ろが詰まってる時によしなに？データを流すのを制御してくれるってのがあるみたいですが、 Elasticsearchだと悲鳴を上げているのがわかりにくいと。\nあと、Elasticsearchがインデキシングでキューを取りこぼしているのがログからわかりにくいってのも出てました。 （なにか、分かる方法があるかとかも調べてみようかなぁ。）\n自分の宿題：Transportプラグインって何かについて調べてブログに書くこと。\n「Elasticsearch at Wantedly」（タイトルあってるか不安）　Wantedly, Inc 内田誠悟さん @spesnova スライド：Elasticsearch at Wantedly\n参考文献：Elasticsearchチュートリアル\n参考文献：Elasticsearch Workshop\n参考文献：elasticsearch-rails\nWantedlyでどうやって使ってるのか。 あと、オートコンプリートでも使ってます。（この話は次回聞けるといいなぁｗ）\nデータ数は少ないので、参考にまだならないかも。\n公式のサイト見難いですよねと。 ペンギン先生のブログが素晴らしかった！ マッピングすごいｗ\n最後は、苦労して作ってもらったautocompleteの資料は放ったらかしにして、質疑応答してもらいました。 辞書とか、検索漏れとかの話は今後の課題っぽかったですね。\n「Elasticsearchのみに決めてました！」ってセリフがカッコ良かったｗ\nアクセスコントロール周りのノウハウもブログで共有してくれそうなので楽しみにしています！\nあと、「tireがretire」の話が出てましたが（この発表だっけ？）参考文献にあげてある、elasticsearch-railsが今は本流なんじゃないかなぁ？\nLT ###「ElasticsearchのScripting」株式会社富士通ソフトウェアテクノロジーズ 滝田聖己さん @pisatoshi\nスライド：ElasticsearchのScripting\n参考文献：elasticsearch-native-script-example\n色々とScriptがあるという話を説明してもらい感謝です。 もちろん、ElasticSearchServerにも書いてあるので、そちらも参考にしてください！\n「Elasticsearch 向け多言語解析プラグイン」ベイシス・テクノロジー株式会社 江口天さん スライド：Elasticsearch 向け多言語解析プラグイン\n参考文献：Elasticsearchで使えるRosette基本言語解析モジュール\n参考文献：Elasticsearch-inquisitorプラグインの紹介\nベイシステクノロジさんが提供しているRosetteをElasticsearchで活用できるモジュールみたいです。 いまなら、無料で体験できるみたいなので、どんなものか触ってみると面白いかもしれません。\nあと、デモで使用されていたプラグインについて、私が昔に書いた記事があるので、興味のある方は参考にしていただければと。 このプラグインはクエリがどのように内部でLuceneのクエリになっているか、どのフィールドでどうトークンが生成されるか？ といったものが見ることができるプラグインになっています。\n関連ブログ 適当に見つけたブログを列挙してあります。これもあるよ！などあれば、教えてください。\n勉強会メモ - 第4回elasticsearch勉強会 2014/04/21\ntogetter 第4回elasticsearch勉強会 #elasticsearchjp\n参加レポート:第4回elasticsearch勉強会 #elasticsearchjp\n第4回elasticsearch勉強会に参加しました\nまとめ しつこいくらい宣伝してしまいましたが、「ElasticSearch Server日本語版」よろしくお願いします！\n今回も楽しい話が聞けました。メモがちょっと少ないんですが。。。\n次回は6末を目処に、MapRの方などと調整して開催しようと思います。 聞きたい話とか、発表したい方とかあれば、連絡くださいー！\n","date":1398077040,"dir":"post/2014/","id":"50562b09417cd8c4a2348a0a5aabe754","lang":"ja","lastmod":1398077040,"permalink":"https://blog.johtani.info/blog/2014/04/21/hold-on-4th-elasticsearch-jp/","publishdate":"2014-04-21T19:44:00+09:00","summary":"第4回Elsticsearch勉強会を開催しました。 今回から、遅刻厳禁にしてみました。 それほど困った人もいないと思うので、次回からも遅刻厳禁","tags":["elasticsearch","勉強会"],"title":"第4回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"今日はelasticsearch-kopfのAnalysis画面の紹介です。\n（簡単なところから。。。その２）\nメニューのanalysisを選択すると、次のような画面が表示されます。\nAnalysis画面 Elasticsearchの_analyze APIを画面で確認できます。 画面で動作の確認ができるのは嬉しいですよね。\n入力文字列：入力となるドキュメントに含まれる文字列や検索キーワードを入力 フィールドの指定：対象とするインデックス名、タイプ名、フィールド名を選択 analyze：ボタンを押す トークナイズされた結果：入力文字列がどのようなトークンに分割されるか start、end：入力文字列中の文字列の位置 pos：トークンの位置 という形でElasticsearchが指定されたフィールドで入力文字をどのようにトークナイズしたかを確認することができます。\nElasticsearchは内部でこのトークナイズされた単語を元に転置インデックスを作成し、検索に利用します。 ですので、特定のデータが検索に上手くヒットしないときに、この画面でデータの文字列をトークナイズしてみるといった用途に使えます。\nフィールドの設定がどのようにして入力文字列をトークンにしているかといった点については、今度のElasticsearch勉強会で話す予定です。\nフィールドの設定を利用する以外に、アナライザを指定してどのようにトークナイズされるかを見ることもできます。 「ANALYZE BYANALYZER」をクリックすると利用できます。\nANALYZE BY ANALYZER トークナイズしたい文字列を入力し、インデックス名と、インデックスに設定されているアナライザ名を選択してanalyzeボタンを押すと 結果が表示されます。 （例では、kuromojiアナライザを利用して出力になっています。また、出力結果のposの表示位置がFIELD TYPEの時と違うのが少し気になりました。）\nただ、残念ながら、インデックスのマッピングで指定したアナライザしか利用できないみたいなので、 どのアナライザがどんな挙動かを調べたい場合は、以前紹介したelasticsearch-inquisitorを 利用したほうが良さそうです。\nということで、今日はanalysis画面の説明でした。\n","date":1397011260,"dir":"post/2014/","id":"76a1fb7f21fda9eddb95426b65124517","lang":"ja","lastmod":1397011260,"permalink":"https://blog.johtani.info/blog/2014/04/09/intro-elasticsearch-kopf-analysis/","publishdate":"2014-04-09T11:41:00+09:00","summary":"今日はelasticsearch-kopfのAnalysis画面の紹介です。 （簡単なところから。。。その２） メニューのanalysisを選択","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（analysis画面）"},{"contents":"JVM Operation Casual Talksに参加しました。 あんまり、運用とかやってないので、ついていけるか不安ですが、楽しそうだったので。 懇親会は予定されてないらしい。\n@stanaka\t15分でわかるJVMのメモリ管理 スライド：https://speakerdeck.com/stanaka/understanding-memory-management-of-javavm-in-15-minutes\nJVMの基礎知識\n某研究所で。。。\nElasticsearch、Solrの名前が！\nJVM困りどころ。ネットの情報が古いのが多いとか。\n使いこなすにはきちんと知識が必要。\nMemory Model 困ったらJava8に。。。\nHeapのチューニングが重要\nHeapの構成やGC処理の説明\nCMSでもすべて並列ではない\nOlgGenがフラグメントして確保が遅くなっていく G1GCの概念図。YoungやOld、Survivorの区別がない？\nリージョン？ リファレンスリストすばらしい。\n@oranie\tCassandra運用で実施しているJVM監視について スライド：http://www.slideshare.net/oranie/jvm-operation-casual-talks-33218856\nCassandra(1.1)で運用中。 35TBとか エンジニアブログ読め。 Cassandraの監視って何すればいいの？ GC頻度とかグラフで見れる VisualVM便利って教えてもらった。 VisualVMでどんな値があるか見ながら調べて、取りたい値を考える。 SNMPで頑張るの辛い＝JMXかな？＝Javaで叩くの？＝Jolokia どんなことやってる？ Nagios+Jenkins＋。。。あとでスライド yohoushi+GrowthForecastも便利。 @waysaku\tSpray(Akka)運用でJVMをCPUスケールさせるために行った事 スライド：http://www.slideshare.net/waysaku/jvm-operation-casual-talks\nSpray Akkaアプリケーションの運用を任されちゃった人 カットオーバー直前の負荷試験でびっくりするくらいスループットでない。。。 いろんなActorが特定のActorに処理を投げた状態で待ってるという状況。。。 スレッドダンプ追っかけてる様子を追体験してる。 ログ出力がBLOCKしてた I/Oを伴う処理は非常にセンシティブ 以下、LT @oinume\t運用に効く！JVMオプション三選 スライド：http://www.slideshare.net/oinume/jvm-operationcasualtalks20140407\nサーバに入らなくても見れるのは VisualVM 最終形Java Mission Control Flight Recorder（商用だと有償） @y_uuki1\tなにもわからないところから始めるJVMモニタリング スライド：https://speakerdeck.com/yuukit/nanimowakaranaitokorokarashi-merujvmmonitaringu\nブログ：http://yuuki.hatenablog.com/entry/2014/04/08/074507\nなんでここにいるかわかりませんが。 色んな所記事とかのリンクがある。 Graphiteに放り込んでるらしい。 @tagomoris\tNorikraのJVMチューンで苦労している話 スライド：http://www.slideshare.net/tagomoris/norikrajvm\nNorikraで困ったので開催したらみんなしゃべりに来てくれてありがたい世の中ですね。 デフォルト設定で運用。mx4096mで4ヶ月は元気に動いてた 年末に崩壊 -\u0026gt; harukaさんのQiita見ながら設定してほったからした。 3月にまた崩壊OOM SoftRefが悪さしてるのか？ nekopさんのブログにヒントが。 @shot6\tJVM的なナニカを話す、GC戦略をそえて スライド：http://www.slideshare.net/shot6/jvm-33248312\n某A社からきました。 CMSを中心が良い CPUコア少ないとCMS Incremental G1GCは6GB以上とかもっと大きい場合のほうが良さそう（雑感） 基本的に、ドキュメントに書いてあるけど、つらいので、まとめてみました。 後で見たいな、このスライドも。 @kazeburo\tWebアプリケーションとメモリ スライド：http://www.slideshare.net/kazeburo/jvm-casual\nJavaは1行も書いたことありません。 Java運用したけど、まぁ、ひどい目にあってます。 ということで、PerlとApacheの話？ bumpyなんとかってのは頭良くプロセスの処理回数とかをなんとかしてくれる JVMとかどうなの？ ということで、CA社の人が釣れたので良かったですね。 TBD\tJVMの運用について話す会(パネル) なんでJVM？\n全文検索だとJVMだなぁ。SolrとかElasticsearchとか 入社したらあった。 JVMこまったところは？\n突然Dioが出てくる JVMいいところは？\nうーん、あえて言うと。。。スレッド処理 型がある言語を調べるとJVM。というよりScala。 飛び入り参加。落ちないところ。人殺しは良くないｗ 簡単には殺せないところに使えるのは良いのでは。 チューンはどこまでやる？\n7,8割でやめたほうが良い？ そんなに突き詰めなくてもいいのかな。 Cassandraだと、FullGCが走ってる時点で再起動しかない場合が多いです。 言語のランタイムについてチューンすることってJVMの他ある？\nRubyくらい？ 自分たちで何とかできないものを相手にしている人たちは苦労してるんじゃないか\nCaなんとかさんとかHBなんとかさんは困ってる人が多い 最後に一言\nモニタリングツール参考にしたい 最後に 「やりたくなったら誰かやってください。」ということみたいです。\n基礎から監視まで結構幅広くキーワードが出てきたので楽しかったです。\nその他に話に出てきてた方のブログもリンクしとこうかな。\nnekopの日記\n","date":1396866240,"dir":"post/2014/","id":"299abcee56b05b312ed5700f686f79b8","lang":"ja","lastmod":1396866240,"permalink":"https://blog.johtani.info/blog/2014/04/07/attend-jvm-casual-1/","publishdate":"2014-04-07T19:24:00+09:00","summary":"JVM Operation Casual Talksに参加しました。 あんまり、運用とかやってないので、ついていけるか不安ですが、楽しそうだったので。 懇親会は予定されてないらしい","tags":["JVM","Java","勉強会"],"title":"JVM Operation Casual Talksに参加しました #jvmcasual"},{"contents":"今日はelasticsearch-kopfのREST画面の紹介です。\n（簡単なところから。。。）\nメニューのrestを選択すると、次のような画面が表示されます。\nElasticsearch自体が、さまざまな操作をRESTでできる仕組みになっています。 検索にも利用しますが、それ以外の設定などにつてもリクエストを送ればOKです。\nですので、リクエストや設定を自分で組み立てて送ることができる画面が用意されているととても便利です。 （もちろん、curlコマンドでもいいのですが、画面があると便利ですよね）\nREST画面 History 履歴表示画面です。 これまで、kopfのrest画面を利用して送信したリクエストが一覧で表示されます。\nHistoryという文字をクリックすることで、表示/非表示の切り替えが可能です。（最初は非表示） マウスオーバーすると、リクエストボディがポップアップで表示されます。\nHistory 履歴にあるURLはクリック可能で、クリックすると実行されます。 履歴はlocalStorageに保存されるみたいです。（ブラウザの仕様？あんまり詳しくないので。。。） たぶん、30件が上限かと（ソースで確認しただけ）\nURL rest画面でリクエストを送信する先のURLを指定します。 メソッドは右側のSELECTで選択可能です。\nリクエストパラメータも指定が可能です。\nリクエストボディ 検索や設定のJSONを記述するところです。 一応、JSON的にエラーがある場合は行数の左側にバツ印が出てきておかしなところもわかるようになっています。\nインデントなどは行ってくれますが、senseみたいな補完などはないので、少し辛いところです。\nレスポンス 送信したリクエストに対するレスポンスが返ってきます。 インデントされた状態で表示されるので読みやすいかと。 また、入れ子になっているJSONについては、閉じたり開いたりすることも可能です。 （開始のカッコの右側に-が表示されていて、クリックすると閉じることができます。閉じると+に変わります）\n簡単ですが、rest画面の説明でした。 KOPFを使っていて、ちょっとしたクエリを送ったりするのには便利だと思います。\n複雑な検索クエリなどについては、やはりsenseを使うのが良いかと思いますが。。。\n","date":1396837440,"dir":"post/2014/","id":"670744b945088de05866864f7d57bee7","lang":"ja","lastmod":1396837440,"permalink":"https://blog.johtani.info/blog/2014/04/07/intro-elasticsearch-kopf-rest/","publishdate":"2014-04-07T11:24:00+09:00","summary":"今日はelasticsearch-kopfのREST画面の紹介です。 （簡単なところから。。。） メニューのrestを選択すると、次のような画面","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（rest画面）"},{"contents":"なんだか、ドタバタしてて久しぶりの更新です。 ベルリンの旅行記みたいなのも書きたいのですが、まずはこちらかと。\nelasticsearch-kopfプラグインの紹介です。\n今回は概要の説明だけになります。機能が結構多いので。\nelasticsearch-kopfとは？ _siteプラグインの一つで、クラスタ管理用のプラグインになります。 headプラグインやHQプラグインと同様です。\nプラグインの画面 このようにシンプルな画面で、スッキリとしています。 緑を基調にした画面構成はElasticsearchの緑色を意識してるんでしょうか？\n上記の画像に簡単なコメントを入れてあります。\nメニュー KOPF：KOPF自体の設定（接続先とリフレッシュインターバルの変更） cluster：クラスタ管理、情報（デフォルト表示画面） rest：RESTリクエスト送信、結果表示画面 aliases：エイリアス管理 analysis：analysis API percolator：パーコレータ管理 warmup：ウォームアップクエリ管理 上記のようなメニューです。各メニューについては、今後のブログで少しずつ紹介しようかと。 このメニューの色が、クラスタの状態も表しています。ステータスがYELLOWなら黄色、REDなら赤色に変わります。\nインデックス インデックスは列として表示されます。先ほどの画像では、2つのインデックスが表示されている状態です。 インデックス毎に、シャードも表示されます。これは、各ノードがどのシャードを保持しているかという情報です。 色の濃いシャードがプライマリでしょう。 インデックス名やシャードの箱はクリックできるようになっていて、それぞれの情報がJSONで表示されます。 その他にもドキュメント数、サイズなども表示されます。 インデックスの各種操作（closeやdeleteなど）もここからメニューが表示されます。（これも次回詳しく）\nノード ノードの情報が行として表示されます。ノードが増えると下に追加されていきます。 node1というのが、ノード名です。（ヒーローの名前とかが出てくるやつです。）\nその他に、IPアドレス、ポート番号、負荷、ヒープサイズなども表示されています。 電源ボタンはノードのシャットダウンを行うためのボタンです。（確認用のダイアログが表示される）\nその他 その他に、クラスタの概要として、ノード数、インデックス数、シャード数、ドキュメント数なども表示されます。 インデックスの作成などは、アイコンから操作が可能です。 大規模なクラスタを管理している場合、検索ボックスを利用することで、インデックス名やノード名による絞込もできるようになっています。\n感想 シンプルな構成の画面で、個人的にはheadよりも好きな画面です。 HQよりもシャードの分散具合がわかりやすいので、今後はこのプラグインを利用していこうと考えています。\nまずは、簡単な紹介です。今後、各画面についてもう少し説明をブログに書いていこうかと考えています。 待てない方は、触ってみてもらうのが良いかと。 もちろん、続きを書いてもらってもいいですよ！！\n","date":1396707480,"dir":"post/2014/","id":"c1241374502f200cf9fc49c8d6fb5822","lang":"ja","lastmod":1396707480,"permalink":"https://blog.johtani.info/blog/2014/04/05/intro-elasticsearch-kopf-1/","publishdate":"2014-04-05T23:18:00+09:00","summary":"なんだか、ドタバタしてて久しぶりの更新です。 ベルリンの旅行記みたいなのも書きたいのですが、まずはこちらかと。 elasticsearch-ko","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（概要）"},{"contents":"先日、「ElasticSearch Serverを翻訳しました」という記事を書きました。\nこの中で電子版も出ますよと書いていましたが、電子版も発売されたので、再告知も兼ねてブログを書いています。\nなお、最近よく「ElasticsearchのSは小文字」とツイートしていますが、本書は原著のタイトルが「ElasticSearch Server」となっているため、Sは大文字になっています。原著が出版された時期にはまだSが小文字に統一されていなかったためです。\n紙の書籍はすでに書店に並んでいたり、Amazonでも発送されているようです。\n私自身が電子書籍が場所を取らなくて好きというのもあり、電子版も出版していただけるようにお願いしていました。\n電子版についてはAmazonでKindle版、達人出版会からEPUBとPDFが購入可能です。\n達人出版会のElasitcSearch Serverのページ AmazonのKindle版ページ こちらのリンク（Amazonはアフィリンク）を参考にしていただければと。\n書籍の写真入りツイートしたら、原著者の方からレスを頂きました。\n@johtani Thanks for the great work out there :)\n\u0026mdash; Rafał Kuć (@kucrafal) 2014, 3月 23 また、原著者のサイトでも紹介してもらいました（結構うれしい）。 私が窓口をやっていた関係で、私の名前しか入っていませんが。。。 編集者と翻訳者の方々のお陰で良い本が出版できたと思っています。\nThanks for sharing! / ElasticSearch Server book in Japanese | ElasticSearch Server Book Blog http://t.co/fhCP1vVBd3\n\u0026mdash; Jun Ohtani (@johtani) 2014, 3月 24 ということで、Elasticsearchの導入の手助けになればと。 感想（賛否問わず）など、あればコメント、ツイート、ブログなど書いていただければうれしいです。 （その際に、連絡してもらえるとさらにうれしいです）\n","date":1395722580,"dir":"post/2014/","id":"d51032bef3e7117a94336fea18a3fad7","lang":"ja","lastmod":1395722580,"permalink":"https://blog.johtani.info/blog/2014/03/25/release-elasticsearch-server-ja-ebook/","publishdate":"2014-03-25T13:43:00+09:00","summary":"先日、「ElasticSearch Serverを翻訳しました」という記事を書きました。 この中で電子版も出ますよと書いていましたが、電子版も発","tags":["elasticsearch"],"title":"ElasticSearch Server日本語版（電子版も）が発売されました"},{"contents":"GOTO Night elasticsearchに参加しました。 初の海外の勉強会です（海外自体が初だし）。\nベルリンにあるWoogaという会社で開催された勉強会です。\nFull house at the #gotonight about @elasticsearch in the auditorium of @wooga pic.twitter.com/r2Vx2aMcEn\n\u0026mdash; GOTO Berlin (@GOTOber) 2014, 3月 18 会場はこんな感じで、とってもおしゃれです。（なんか、写ってますね、最前列にｗ） ベルリンの古い建物をリノベーションしたオフィスみたいで、そこにこういったひな壇を用意して発表するスペースにしているみたいです。\n内容としては、Elasticsearch1.0の新機能の話として、snapshot/restore、cat、aggregationなどの話題でした。簡単にどういったものかの説明です。\n一人目の発表が終わったら、ブレイクタイムとして上のフロアに用意されている軽食＋ドリンクで軽く交流の時間が用意されていました。 ベーグルなどのサンドイッチとハイネケンやクラブマテ？と呼ばれるチープなレッドブルとかが飲めました。\nちょっと食べて談笑したあとに、次はLogstashとKibanaのお話でした。Logstashってどんなもの？という話がメインで、Kibanaは簡単な紹介という感じでしょうか。最後に、ライブデモがありました。 Kibanaを使ったライブデモはインパクトがあるなというのが感想です。 フィールド名の補完をしてくれたりと便利な機能が操作をしているところでわかるので。\nYoutubeなどでも見てても思っていた感想ですが、こちらの勉強会は質問が結構出てきます。 今日参加した勉強会も質疑応答が結構されてました。\nelasticsearchの方たちと少しだけ話しをできたので、かなり興奮気味でブログを書いています（ミーハー）。\nただ、やっぱり英語のヒアリングがまだまだだなぁとも実感出来ました。 場数踏むしかないと思うので少しずつ耳にしてなれるしかないかなぁと。 はぁ、ちゃんと高校とか大学の頃に単語を覚えとくんだったと軽く後悔。\nこんなツイートもしてもらって、興奮気味です。明日早起きしないといけないので寝ないといけないのにｗ\nMeeting @johtani finally in #berlin watching @spinscale talking about #elasticsearch\n\u0026mdash; Simon Willnauer (@s1m0nw) 2014, 3月 18 ","date":1395151860,"dir":"post/2014/","id":"65453a1ae403679bd2e47398a04205ca","lang":"ja","lastmod":1395151860,"permalink":"https://blog.johtani.info/blog/2014/03/18/attend-goto-night-elasticsearch/","publishdate":"2014-03-18T23:11:00+09:00","summary":"GOTO Night elasticsearchに参加しました。 初の海外の勉強会です（海外自体が初だし）。 ベルリンにあるWoogaという会社で開催された勉強会","tags":["elasticsearch","勉強会"],"title":"GOTO Night elasticsearchに参加しました"},{"contents":"Berlinからおはようございます。\nということで、人生で初めての海外に来ています。\n人生初の海外なのに、一人で乗り換えがあるようなBerlinに来ています。 今年はチャレンジの年になりそう。初めてづくしですが、楽しみたいなと。 会社に感謝です。ESのトレーニングを受けに来たのがメインなのです。 ついでに、Berlinでの勉強会にも参加してみようかなと。\n幸いにも時差ボケはなさそうなので、色々と見て回ろうと思います。 ただ、日曜日はお店が軒並みしまってそう。。。\n","date":1394916660,"dir":"post/2014/","id":"abc5ca9856a61831fd4ed06b402875d2","lang":"ja","lastmod":1394916660,"permalink":"https://blog.johtani.info/blog/2014/03/16/post-from-berlin/","publishdate":"2014-03-16T05:51:00+09:00","summary":"Berlinからおはようございます。 ということで、人生で初めての海外に来ています。 人生初の海外なのに、一人で乗り換えがあるようなBerlin","tags":["misc","travel"],"title":"Berlinからおはようございます"},{"contents":"elasticsearchに、このへん入れるときっと幸せになれるはず・たぶん。\u0026#10;elasticsearch/elasticsearch-analysis-kuromoji/1.6.0\u0026#10;oyrusso/elasticsearch-HQ\u0026#10;mobz/elasticsearch-head\n\u0026mdash; toshi_miura (@toshi_miura) 2014, 3月 5 こんなツイートを見かけたので、普段入れてるプラグインを簡単に紹介してみようかと。\nローカルの環境に普段入れているプラグインの紹介です。 ちゃんとクラスタを管理しているというよりは、最新版の動作などを確認するための環境になります。なので、ちょっと視点が異なるかもしれませんが参考になればと。\nelasticsearch-analysis-kuromoji URL : elasticsearch-analysis-kuromoji\nKuromojiという日本語形態素解析のTokenizerなどを使えるようにするためのプラグインです。 今度、発売される「ElasticSearch Server」日本語版には付録として、利用方法を執筆しました。参考にしていただければと。 READMEにもサンプルは掲載されてるので、こちらを参考にするのもありですが。\nelasticsearch-extended-analyze URL : elasticsearch-extended-analyze\n私が開発しているプラグインです。 ElasticsearchにはanalyzeというAPIが用意されています。 文章を渡すと指定したanalyzerなどでどのような単語に区切られるかがわかるAPIです。\nただ、analyzerの内部ではchar filter、tokenizer、token filterという個別のパーツがそれぞれ入力された文字列に対して処理を実施します。 この過程がanalyze APIではわかりません。 それをわかるようにしてみたのがelasticsearch-extended-analyzeプラグインになります。\n詳細については過去の記事を見ていただければと。 画面があると便利だよなぁと思いつつ、作ってない。。。\npolyfractal/elasticsearch-inquisitor URL : elasticsearch-inquisitor\nクエリのデバッグとかに便利なプラグイン。\nこちらも詳細は過去の記事を見ていただければと。\nmobz/elasticsearch-head URL : elasticsearch-head\nクラスタ管理に便利なプラグインです。クラスタに存在するノードに対してインデックスのデータ（シャード）がどこに配置されているかなどが一目瞭然になる便利なプラグインです。 プライマリシャードやレプリカなどもわかります。 インデックスの削除もできるし、クエリを投げることもできるし、全部入りな感じのプラグインです。\n私個人は、シャードの配置を見るのに主に利用しています。クエリを投げたりインデックスを消したりするのには殆ど使っていません。\nroyrusso/elasticsearch-HQ URL : elasticsearch-HQ\nこれも管理系のプラグインです。こっちのほうが個人的にスッキリしていて好きなプラグインです。 インデックスの管理やノードの停止などはこちらを主に使用しています。 あくまでもローカルの簡易クラスタを管理する目的というのもあります。\npolyfractal/elasticsearch-segmentspy URL : elasticsearch-segmentspy\nこちらはモニタリングでしょうか。 ElasticSearch Serverで紹介されていたのが主な理由で、入れてますがあんまり見てないかも。 インデックスのSegment単位の情報が見ることが可能です。 あと、ちょっと更新されてない感じがしますね。\nelasticsearch/marvel Elasticsearch社から提供されている、モニタリングなどに使えるプラグインです。 開発環境では無償提供という感じです。 渡しの場合、モニタリング目的ではなく、senseと呼ばれるクエリの補完をしてくれるツールの目的のために使用しています。 モニタリング部分を停止する方法とかないかなぁ。\n詳細については過去の記事を参考にしていただければと。\nまとめ？ ということで、簡単にローカルに入っているプラグインの紹介でした。 他にもいっぱいあるので、おすすめがあれば、教えてもらえると助かります。\n","date":1394515380,"dir":"post/2014/","id":"386dc9d1b647a9f3965f1fbe29c7dfb9","lang":"ja","lastmod":1394515380,"permalink":"https://blog.johtani.info/blog/2014/03/11/es-plugin-installed-to-my-env/","publishdate":"2014-03-11T14:23:00+09:00","summary":"elasticsearchに、このへん入れるときっと幸せになれるはず・たぶん。\u0026#10;elasticsearch/elasticsearc","tags":["elasticsearch","plugin"],"title":"いつも入れているElasticsearchのプラグイン"},{"contents":"第3回Elasticsearch勉強会で、軽く触れていましたが、ElasticSearch Server日本語版が発売されます。 ツイートなどもちらほらとして頂いているみたいで嬉しい限りです。\n本書は、私自身、初の翻訳本となります。\nなお、ElasticSearchはAWSのサービスではなく、全文検索・解析サーバのOSSです\n内容、概要 PacktPublishingから発売されているElasticSearch Serverの日本語版となります。 以下の点が、原著とは異なる点になっています。\n0.90.xに対応（原著は0.20） Kibana、Kuromojiに関して追記 もちろん日本語 残念ながら、つい最近、Elasticsearchについては1.0がリリースされました。 1.0で追加された機能（SnapshotやRestore、Aggregatorなど）については触れていませんが、Elasticsearchの機能を網羅的にカバーした良書となっています。 どんな機能があるのか、どんなプラグインがあるのか、どういったことに使えるのかなど、幅広くまとめられた本になっていますので、 Elasticsearchに興味がある方はぜひ読んでいただければと思います。\nまた、現段階では予定ですが電子版の出版も予定されています。電子版が気になる方は、少しお待ちいただければと。\nElasticSearch？Elasticsearch？ 1.0.0がリリースされた現在は、Elasticsearch（SearchのSは小文字）が正式な名称となっています。 ただ、原著が発売された当初（2013年2月時点）では、まだSは小文字と大文字が混在した状況でした（コミットログなどを見るとわかります。） このため、日本語版でもElasticSearchという表記に統一してあります。\n翻訳に関して 初の翻訳書ということもあり、大変でした。英語に精通しているわけではないので（むしろ苦手）。。。 他の翻訳者の方々には大変助けていただきましたし、勉強になりました。 また、監修社であるリクルートテクノロジーズにも色々とサポートしていただき、感謝の限りです。 （Elasticsearch勉強会の開場提供にも協力して頂いています。）\nわかりにくい日本語となっている部分などありましたら、ご指摘いただければ今後の参考にさせていただきます。 英語やElasticsearchについて、学ぶという目的もあって、本書の翻訳を買って出たのが本音です。\n翻訳作業について Githubのリポジトリを編集の方に用意してもらい、翻訳原稿を管理、校正していきました。 Github自体をあまり触っていなかったので、作業をしながらGithubも覚えられ一石二鳥でした。 Issueやプルリクエストによる校正、チェックも便利ですね。 他の原稿を書くようなことがあれば、またこの経験を活かしていきたいなと。 （翻訳の進め方や原稿のチェックなどについてはまた後日何か書こうかと。）\n原著について 原著のサイトが用意されています。 http://elasticsearchserverbook.com/elasticsearch-server-errata/\n原著を翻訳するにあたって見つけた、誤植などを報告し、掲載して頂いています。 原著をお持ちの場合はこちらも参考にしていただければと思います。\nご購入はこちらから ということで、簡単ですが書籍の紹介（というより宣伝！？）でした。 Elasticsearchに関する何かしらの助けになる書籍であれば嬉しい限りです。\n「ElasticSearch Server日本語版」をよろしくお願いします。 （もちろん、購入は下のリンクからですよね！）\n","date":1393836900,"dir":"post/2014/","id":"9ad72c2a5157f21741bd4581a562dfc7","lang":"ja","lastmod":1393836900,"permalink":"https://blog.johtani.info/blog/2014/03/03/release-elasticsearch-server-japanese-edition/","publishdate":"2014-03-03T17:55:00+09:00","summary":"第3回Elasticsearch勉強会で、軽く触れていましたが、ElasticSearch Server日本語版が発売されます。 ツイートなども","tags":["elasticsearch"],"title":"ElasticSearch Serverを翻訳しました"},{"contents":"今年初の「突撃！隣のElasticsearch」ということで、Wantedlyさんにおじゃましました。\n※写真を自分でも撮ったのですが、画像が壊れてたので、一緒に行ったペンギン先生の写真を拝借しました。\n第3回のElasticsearch勉強会を開催中にES使ってるってツイートを見つけたので、アタックかけて遊びに行きました。 交渉に快諾いただきありがとうございました！\nWantedlyさんがどのようにElasticsearchを使用されているかはきっと、ブログを書いてくれると思うので期待しておくとして、書いてくれました！！ 「実践！Elasticsearch」 そこで、nestedでハイライトがなんかうまくいかないって話があったので、ちょっと調べてみました。 （※まだ、調査中です）\n前提条件 再現する手順はgistにあります。（Senseに貼り付ければ動作します。ただし、elasticsearch-analysis-kuromojiが必要です。）https://gist.github.com/johtani/9184287\nなお、このマッピングやデータはWantedlyさんとは全く関係ありません。\nnestedフィールド内部のデータに対して、検索しハイライトしようとするとうまく動作しないという状況です。 マッピングは以下のとおり。\n\u0026#34;books\u0026#34; : { \u0026#34;properties\u0026#34;: { \u0026#34;book\u0026#34; : { \u0026#34;type\u0026#34;: \u0026#34;nested\u0026#34;, \u0026#34;properties\u0026#34;: { \u0026#34;title\u0026#34; : { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34;, \u0026#34;store\u0026#34;: \u0026#34;no\u0026#34;}, \u0026#34;contents\u0026#34; : {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34;, \u0026#34;store\u0026#34;: \u0026#34;yes\u0026#34;} } } } } } このマッピングの特徴は以下のとおり。\n_sourceは保存される（デフォルト値） bookがnestedなオブジェクト titleはstore : no contentsはstore : yes 動作の挙動をわかりやすくするため、titleとcontentsのstore属性に違いを持たせてあります。\n問題点 nestedクエリを使って、検索した時にハイライトが返ってきません。 次のクエリを実行するとわかります。\nGET /bookstore/books/_search { \u0026#34;_source\u0026#34; : [\u0026#34;book.title\u0026#34;,\u0026#34;book.contents\u0026#34;], \u0026#34;fields\u0026#34;: [ \u0026#34;book.title\u0026#34;, \u0026#34;book.contents\u0026#34; ], \u0026#34;query\u0026#34;: { \u0026#34;nested\u0026#34;: { \u0026#34;path\u0026#34;: \u0026#34;book\u0026#34;, \u0026#34;query\u0026#34;: { \u0026#34;query_string\u0026#34; : { \u0026#34;query\u0026#34; : \u0026#34;Solr\u0026#34;, \u0026#34;fields\u0026#34; : [\u0026#34;book.title\u0026#34;, \u0026#34;book.contents\u0026#34;] } } } }, \u0026#34;highlight\u0026#34;: { \u0026#34;pre_tags\u0026#34;: [\u0026#34;\u0026lt;b\u0026gt;\u0026#34;], \u0026#34;post_tags\u0026#34;: [\u0026#34;\u0026lt;/b\u0026gt;\u0026#34;], \u0026#34;fields\u0026#34;: { \u0026#34;*\u0026#34;: {} } } } 結果はこちら。 ハイライトがありません。\n{ \u0026#34;took\u0026#34;: 3, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 5, \u0026#34;successful\u0026#34;: 5, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;max_score\u0026#34;: 0.5, \u0026#34;hits\u0026#34;: [ { \u0026#34;_index\u0026#34;: \u0026#34;bookstore\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;_score\u0026#34;: 0.5, \u0026#34;_source\u0026#34;: { \u0026#34;book\u0026#34;: { \u0026#34;title\u0026#34;: \u0026#34;Apache Solr入門\u0026#34;, \u0026#34;contents\u0026#34;: \u0026#34;Apache Solrについて日本語で書かれた唯一の書籍です。SolrはLuceneをコアにした検索サーバです。\u0026#34; } } } ] } } 次に、ハイライトが帰ってくるパターン。 nestedクエリではなく、_allを対象としたクエリを投げます。\n{ \u0026#34;_source\u0026#34; : [\u0026#34;book.title\u0026#34;,\u0026#34;book.contents\u0026#34;], \u0026#34;fields\u0026#34;: [ \u0026#34;book.title\u0026#34;, \u0026#34;book.contents\u0026#34; ], \u0026#34;query\u0026#34;: { \u0026#34;query_string\u0026#34; : { \u0026#34;query\u0026#34; : \u0026#34;Solr\u0026#34;, \u0026#34;fields\u0026#34;: [ \u0026#34;_all\u0026#34; ] } }, \u0026#34;highlight\u0026#34;: { \u0026#34;pre_tags\u0026#34;: [\u0026#34;\u0026lt;b\u0026gt;\u0026#34;], \u0026#34;post_tags\u0026#34;: [\u0026#34;\u0026lt;/b\u0026gt;\u0026#34;], \u0026#34;fields\u0026#34;: { \u0026#34;book.title\u0026#34; : {}, \u0026#34;book.contents\u0026#34;: {} } } } この場合の結果は次の通り。\n{ \u0026#34;took\u0026#34;: 2, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 5, \u0026#34;successful\u0026#34;: 5, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;max_score\u0026#34;: 0.27063292, \u0026#34;hits\u0026#34;: [ { \u0026#34;_index\u0026#34;: \u0026#34;bookstore\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;_score\u0026#34;: 0.27063292, \u0026#34;_source\u0026#34;: { \u0026#34;book\u0026#34;: { \u0026#34;title\u0026#34;: \u0026#34;Apache Solr入門\u0026#34;, \u0026#34;contents\u0026#34;: \u0026#34;Apache Solrについて日本語で書かれた唯一の書籍です。SolrはLuceneをコアにした検索サーバです。\u0026#34; } }, \u0026#34;highlight\u0026#34;: { \u0026#34;book.title\u0026#34;: [ \u0026#34;Apache \u0026lt;b\u0026gt;Solr\u0026lt;/b\u0026gt;入門\u0026#34; ] } } ] } } ハイライトが返ってきています。\n考察（原因は未特定） 残念ながら、まだ調査してません。 まずは、現象が理解できたというだけです。 問題点が実は２つありそうです。\n問題点１：nestedクエリの場合に、ハイライトされない。 nestedクエリではハイライトが動作していないようです。 想像ですが、検索に利用されたクエリで指定されているフィールドをハイライタ（ハイライトを実行するモジュール）が認識できてないのではないかと。 なぜ認識できていないのかという点を調査する必要がありそうです。\n考察（試してみたパターン） nestedではないクエリで、ハイライトが動作しているのですが、 \u0026quot;book.title\u0026quot; : {\u0026quot;require_field_match\u0026quot; : true},にした場合は、ハイライトが返ってこないです。 このオプションは、検索対象のフィールドでマッチした文字列だけがハイライトされるオプションになります。 したがって、book.titleフィールドに対する検索でSolrという文字を検索していないことになります。 _allに対するクエリであるためです。 このため、例えば、titleだけを検索対象にしたのに、contentsにSolrという文字が入っていてもハイライトされてしまうという状況が発生します。\n問題点２ store : yesのデータがハイライトできない。 GithubにIssueをあげました。https://github.com/elasticsearch/elasticsearch/issues/5245 （2014/02/25追記）\nnestedオブジェクトにあるデータのうち、store : noのものだけがハイライト結果として返ってきました。\n考察 なぜ、store : yesのデータがハイライトされないかを調べるために、fieldsパラメータをリクエストに追加してみました。\n{ \u0026#34;_source\u0026#34; : [\u0026#34;book.title\u0026#34;,\u0026#34;book.contents\u0026#34;], \u0026#34;fields\u0026#34;: [ \u0026#34;book.title\u0026#34;, \u0026#34;book.contents\u0026#34; ], ... } すると、fieldsの戻り値は次のとおりです。\n... \u0026#34;fields\u0026#34;: { \u0026#34;book.title\u0026#34;: [ \u0026#34;Apache Solr入門\u0026#34; ] }, ... このことから、store : noのデータの場合、_sourceから値を取得して返却しているというのがわかります。 ハイライトがされない原因も、fieldsで値が取れていないのも同じ原因であると思われます。 なぜなら、ハイライトは、保存された文字列を内部で取り出し利用して、ハイライトタグを埋め込むという動作をするためです。\n参考？ これらの問題点についてですが、次のIssueが関係あるかもしれません。\nReturn matching nested inner objects per hit #3022\n今後？ 残念ながら、現時点では、問題点がどんなものかというのを理解しただけとなります。 デバッグしたりソースを追っかけたりして何が問題なのかを調べて行ってみようかなぁと。\nなにか、気づいたことなどあればコメントしてもらえると助かります。\n","date":1393231920,"dir":"post/2014/","id":"f55d33371dcff207fd7d201128df2ea3","lang":"ja","lastmod":1393231920,"permalink":"https://blog.johtani.info/blog/2014/02/24/strange-behavior-of-field-in-nested-obj/","publishdate":"2014-02-24T17:52:00+09:00","summary":"今年初の「突撃！隣のElasticsearch」ということで、Wantedlyさんにおじゃましました。 ※写真を自分でも撮ったのですが、画像が","tags":["elasticsearch"],"title":"Nested Objectのフィールドの奇妙な動作"},{"contents":"今回はたまたま日本にいたElasticsearchの人をスペシャルゲストに呼べたので、大満足ですｗ 英語の通訳とかちゃんと勉強しないとなぁ。。。\nとりあえず、てきとーなメモですが、残しておきます。 参加者数は130人＋スタッフ＋リクルートテクノロジーズ社内の人。という感じでした。アンケート集計はもう少々おまちを。\nスライドがそろったら、また、更新すると思いますが、第一報という感じで公開しておきます。 懇親会にも50名も参加していただけて、非常に楽しかったです。 話ができてない方が多数いるかもしれませんが、次回以降、声をかけていただければと。 （物覚え悪いんで、あれですが。。。） 盛り上がってきてて楽しいなぁ。 スタッフの人達の練度も上がってきてるので、すごく楽ができてます。\n至らない点とかあれば、こちらにコメントしてもらったりしていただければと。\nGeohashing with Elasticsearch Florian Schilling, Elasticsearch Inc, スライド：https://speakerdeck.com/chilling/tokyo-es-study-session-iii-geohashes\n自己紹介 Geoのスタッフ Elsticsearchの概要 転置イデックスやREST APIなどの説明 マイクの調子が良くなくて申し訳なかったっす。。。 平賀さん、通訳ありがとう！ Solr本もよろしくお願いします！！\nAWSで構築するsharding 株式会社イプロス　外山　寛さん　@toyama0919 スライド：http://toyama0919.bitbucket.org/elasticsearch.html\nAWS対応の話 ルーティングが重要だよ。（宣伝ありがとうございますｗ） type指定しないとルーティングできない。（内部でtypeも使ってハッシュ値取ってたかなぁ？） 苦労話とかいくつか。 tireはre-tire\u0026hellip; 実サービスでのElasticsearch設定・使用例（仮） 株式会社じげん　多田 雅斗さん　@tady_jp スライド：https://speakerdeck.com/tadyjp/tesutoqu-dong-jian-suo-falsesusume-at-tady-jp\n検索とは的な話がわかりやすい。 全文検索のお話。ログ検索じゃないよと。 書籍ないですよねー（ふふふ） specで検索条件記述しといて、ってのいいですよね。絶対必要だと思う Mapping変更した時にテストやり直す方法とかどうしてますか？ 特にフレームワークは使ってないです。\nMySQLユーザ視点での、小さく始めるElasticsearch 株式会社リブセンス 吉田 健太郎さん @yoshi_ken スライド：http://www.slideshare.net/y-ken/introducing-elasticsearch-for-mysql-users\nやっぱりkuromoji便利だよね MySQLとかと連携したい。 river-pluginもいまいち安定しない なので、Yamabiko作ってみました。 Geo検索とKuromojiの話をしてくれました。（作者とか開発者がいるってのを狙ってたのかすごいなぁ。） Mappingとかはちゃんと指定したほうがいろいろいいですよ。 nodeJS+DynamoDB＋Elasticsearchで全社基盤を作った話 株式会社リクルートテクノロジーズ 相野谷 直樹さん @naokiainoya スライド：http://www.slideshare.net/recruitcojp/elasticsearchnodejsdynamodb-7\nちょっと変わった使い方のElasticsearchで面白いです。 Scroll/Scanについては、Solrでもない機能なので、そういう意味でもElasticsearchなのかもしれないですね。 参加していただいた方々のブログ 第3回elasticsearch勉強会 [2014/02/07(Fri.)]に参加してきました - ほわいとぼーど\nhttp://a3no.hatenablog.com/entry/2014/02/09/022405\n第 3 回 elasticsearch 勉強会に行ってきた - ようへいの日々精進\nhttp://inokara.hateblo.jp/entry/2014/02/07/233057\nhttp://www.smokeymonkey.net/2014/02/3elasticsearch.html\n第3回elasticsearch勉強会でトークしました #elasticsearchjp\nhttp://y-ken.hatenablog.com/entry/elasticsearch-meetup-vol3\n第3回elasticsearch勉強会にいってきました #elasticsearchjp\nhttp://blog.livedoor.jp/ashibuya0128/archives/52058766.html\n","date":1391787720,"dir":"post/2014/","id":"229b7fc784707b1d2c702fbeba080e86","lang":"ja","lastmod":1391787720,"permalink":"https://blog.johtani.info/blog/2014/02/08/hold-3rd-elasticsaerch-meetup-in-tokyo/","publishdate":"2014-02-08T00:42:00+09:00","summary":"今回はたまたま日本にいたElasticsearchの人をスペシャルゲストに呼べたので、大満足ですｗ 英語の通訳とかちゃんと勉強しないとなぁ。。","tags":["elasticsearch","勉強会"],"title":"第3回elasticsearch勉強会を開催しました！ #elasticsearchjp"},{"contents":"すずけんさんがVagrant+puppet使って、VM起動してElasticsearchのクラスタを組んでる記事を書いているのを見て、試してみたくなりました。 ということで、VagrantとかPuppetなに？くらいの私ですが、クラスタを起動するところまで行ったので、その時のメモを残しておきます。\n元記事とか参考 Vagrant環境にpuppet moduleを利用してさくっとelasticsearchをインストールする Vagrant環境にpuppetを利用してさくっとelasticsearchのclusterを作成する puppet-elasticsearch なんとなくの理解 VagrantやPuppetについては、何度か勉強会で話を聞いてはいたのですが、 想像していたレベルだったので良い機会でした。 今のところの認識はこんな感じです。\nVagrant VMを起動したり、VM周りの設定をあれこれできるツール。 VMのネットワーク設定や、インスタンス名？などを指定できる。\nPuppet 起動後のVM（VMとは限らないか。）のゲストOS側の設定周りやアプリのインストールなどを 実行できるツール。\n詰まった箇所 すずけんさんのブログを元に作業をしましたが、自分がVagrantやPuppetに疎いため、以下の部分で躓いたので、備忘録のために残しておきました。\nその１：Puppetのファイルの場所 search01.vm.localのVMを設定（というか、elasticsearchのインストール？）するときに、manifests/search.appとroles/search/manifests/init.ppファイルが必要で作成します。\nこのファイルの配置場所は/vagrant配下に作成する必要がありました。 ssh search01.vm.localでVMにログインした場合は/home/vagrantにログインしており、この場所でファイルを作ってもPuppetがエラーを吐いたためです。\nと思ったのですが、あれ？これひょっとしてVagrantfileがあるところにディレクトリとファイル作ると勝手にVMにコピーしてくれるんですか？destroyして、upしたら、ファイルが勝手にコピーされてる。ひょっとして、/vagrantってディレクトリはVagrantfileがあるディレクトリを共有してたりするのかな？そのうち、Vagrantについても調べてみようかな。\nその２：ネットワーク周り curl http://192.168.10.114:9200/ をホストOSから実行してみましたがうまく行きませんでした。。。 ネットワーク周りの設定だと思うんですが。 少なくとも「sshによるログイン」「ping」コマンドの応答は返ってきてます。\nまた、VM内でcurlコマンドを実行したらレスポンスが返ってきました。\nなんで？ってツイートしたら各所から「iptables」という単語が飛んできて、 service止めたら大正解でした。まぁ、そうですよね。基本ですよね。。。\nということで、Puppetがよくわかっていませんが、ググって変更してみました。\nmanifests/search.appに以下を追加\ninclude iptables roles/iptables/manifests/init.pp\nclass iptables { service { \u0026#39;iptables\u0026#39;: enable =\u0026gt; false, ensure =\u0026gt; stopped, } } iptablesを停止するmanifests？です（良くないことなんですが、よくわかってない）。\nということで、ローカルで1個のVM起動して、elasticsearchにアクセスできることは確認できました。\nと、書いてるそばから、元記事が修正されてしまいましたｗ\nクラスタ編（変更点） クラスタを組むときに、追加でプラグインを入れたのでroles/search/manifests/init.ppは次のようにしました。\nclass search { class { \u0026#39;elasticsearch\u0026#39;: package_url =\u0026gt; \u0026#39;https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-1.0.0.RC2.noarch.rpm\u0026#39;, java_install =\u0026gt; true, config =\u0026gt; { \u0026#39;cluster\u0026#39; =\u0026gt; { \u0026#39;name\u0026#39; =\u0026gt; \u0026#39;test-es-cluster\u0026#39; }, \u0026#39;network.host\u0026#39; =\u0026gt; \u0026#39;_eth1:ipv4_\u0026#39;,, \u0026#39;marvel.agent.exporter.es.hosts\u0026#39; =\u0026gt; [\u0026#39;192.168.10.114:9200\u0026#39;,\u0026#39;192.168.10.115:9200\u0026#39;] } } elasticsearch::plugin{\u0026#39;elasticsearch/marvel/latest\u0026#39;: module_dir =\u0026gt; \u0026#39;marvel\u0026#39; } elasticsearch::plugin{\u0026#39;mobz/elasticsearch-head\u0026#39;: module_dir =\u0026gt; \u0026#39;head\u0026#39; } elasticsearch::plugin{\u0026#39;royrusso/elasticsearch-HQ\u0026#39;: module_dir =\u0026gt; \u0026#39;HQ\u0026#39; } elasticsearch::plugin{\u0026#39;elasticsearch/elasticsearch-analysis-kuromoji/2.0.0.RC1\u0026#39;: module_dir =\u0026gt; \u0026#39;analysis-kuromoji\u0026#39; } elasticsearch::plugin{\u0026#39;info.johtani/elasticsearch-extended-analyze/1.0.0.RC1\u0026#39;: module_dir =\u0026gt; \u0026#39;extended-analyze\u0026#39; } elasticsearch::plugin{\u0026#39;polyfractal/elasticsearch-inquisitor\u0026#39;: module_dir =\u0026gt; \u0026#39;inquisitor\u0026#39; } } とりあえず、今日はクラスタ組んでMarvelやプラグインの動作確認でおしまいです。\n疑問点 いくつか疑問点が。試してみてもないんでなんとも言えませんが。気が向いたら、調べて追記するかも。\n:private_networkはVirtualBox内で完結する（Macから外には影響しない）ネットワークが構築される？たぶん、VagrantというよりはVM、仮想化周りの知識なんだろうけど どこから再開可能？elasticsearch.ymlの設定を書き換えた場合に、最後のコマンドだけ実行するとちゃんとやりなしてくれたりするのかな？ VMのディスク増やすのもVagrantでできるんかな？まぁ、できると思うけど。 :forwarded_portのauto_correctとかわかってない。 JVMをSunのJVMでかつ、7u25に変更したいのだがどうしたものか？(現時点での推奨バージョン) 感想 Vagrantって便利ですね。あれ？って思ったら、destroyして、やり直すのがすごく簡単です。 元記事があるので、なんとなくですが、構成とかどうすればいいかがわかるのは本当に助かりました。 これで、あれこれと検証する環境が簡単に構築できることがわかったので、色々と楽できるかも。ありがとうございます、すずけんさん！\n","date":1391695740,"dir":"post/2014/","id":"c98cbc333fb7d95c6c9fc4924b0526e1","lang":"ja","lastmod":1391695740,"permalink":"https://blog.johtani.info/blog/2014/02/06/es-cluster-start-using-vagrant-and-puppet/","publishdate":"2014-02-06T23:09:00+09:00","summary":"すずけんさんがVagrant+puppet使って、VM起動してElasticsearchのクラスタを組んでる記事を書いているのを見て、試して","tags":["elasticsearch","vagrant","puppet","marvel"],"title":"すずけんさんのメモを元にVagrantでElasticsearchクラスタを起動してみた"},{"contents":"改訂新版Solr入門出版記念ということで、第13回Solr勉強会 #SolrJP 新Solr本出版記念を開催しました。\n出版記念なので、技術評論社様より、プレゼント用にSolr本を用意していただきました！ありがとうございます！！ 書籍をゲット出来た方は、ツイートしたりブログ書いたり書評書いたりして、宣伝してください！！！\n今回は、私は手を抜いて他の人に喋ってもらいました！\n今回は、著者陣（関口さんは特別ゲスト）でスピーカーを固めてみました。 以下は、いつもの簡単なメモです。 スライドが集まったらまた更新していきます。\n1. 「はじめての検索エンジン＆Solr」 株式会社NTTデータCCS　鈴木 教嗣さん スライド：はじめての検索エンジン＆Solr 第13回Solr勉強会\n鈴木さんの発表初めて聞きましたｗ。 趣味が多いなぁ。 ちょこちょこと、宣伝を入れてるのが流石ですｗ\n入門らしい概要 クエリの概要とかも。 スコア計算とか 導入するとうれしいところとか Solr盛り上げましょう！ 2. 「Solr SearchComponent 再訪」 株式会社ロンウイット　関口 宏司さん スライド：公開待ち\nベン図で検索の評価指標の説明 理論的なお話 Solrのサーチコンポーネントを使って何ができるか。ベン図で。 サーチコンポーネント以外にも NGramTokenizerも SynonymFilterも パーソナライズ検索 いきなり話をふられたのでちょっとびっくりしましたｗ\n3. 「自動補完(Autocomplete)ともしかして？(Did You Mean?)」 株式会社 ロンウイット　大須賀 稔さん スライド：Solr AutoComplete and Did You Mean?\nデモ：https://github.com/mosuka/solr-suggester-demo-ui\n職歴が相変わらずおもしろい 編集距離のお話 素晴らしいCM！ 候補のランキングを変更できる？ SpellcheckComponentのパラメータで指定できるものなら楽ですが。。。\n4. 「Lucene Revolution 2013 Dublin振り返り」 楽天株式会社　平賀 一昭さん スライド：公開待ち\nダブリンどこ？（間違ってベルリンって言っちゃいましたｗ） スタジアムで開催。グランドにも入れるのかなぁ？ まずはTwitter Luceneの改良版 ちょっと特殊。１４０文字とか 青いRさんのライバル。Careerbuilder 元FASTユーザ 企業向けに検索キーワードとかの解析画面を用意 検索精度の改良の話とか 転職で引っ越す意思があるかとか。 最後はLinkedIn Luceneのユーザ まとめ ということで、スピーカーの方々のスライドにもありましたが、 改訂新版Apache Solr入門は良い本なので、購入していただけると嬉しいです。\n感想、コメントなど、いつでもお待ちしています！\n","date":1390988760,"dir":"post/2014/","id":"c6107ff57e96a1373c019d252c00ad84","lang":"ja","lastmod":1390988760,"permalink":"https://blog.johtani.info/blog/2014/01/29/hold-to-japan-solr-meetup/","publishdate":"2014-01-29T18:46:00+09:00","summary":"改訂新版Solr入門出版記念ということで、第13回Solr勉強会 #SolrJP 新Solr本出版記念を開催しました。 出版記念なので、技術評論社様より、プレ","tags":["Solr","勉強会"],"title":"第13回Solr勉強会を開催しました"},{"contents":"昨晩、Elasticsearchから初のプロダクトとなるMarvelがリリースされました。ということで、さっそく触ってみて、簡単な紹介と感想を書いてみました。\nMarvelって？ Elasticsearch社が初のプロダクトとしてリリースした、Elasticsearchクラスタモニタリングツールです。 次のような特徴があります。\nplugin形式で提供 GUIがKibana メトリックスはElasticsearchに保存 SenseがChrome以外でも使える プロダクション環境で利用する場合は有料ですが、開発用途では無料で利用できます。 現時点(2014/01/29)では、0.90.9以上のバージョン(1.0.0.RC1含む)で利用が可能です。\nなにができるの？ Elasticsearchクラスタに関するメトリックスを保存、可視化できるプロダクトです。 ドキュメント数やJVMの状況、クラスタの状態など、いろいろなメトリックスが保存されます。\n保存先は、別のElasticsearchクラスタにすることも可能です。 お試しでインストールして見る場合は、同一クラスタにサービスに利用するインデックスとMarvel用のメトリックス保存先インデックスを入れても良いです。\nただ、プロダクション環境では、Marvel用インデックスはあくまでもモニタリングに使用するため、サービスのクラスタへの影響を最小にしたくなります。\nこのような場合、Marvelのプラグインの設定を変更することで、メトリックス送信用のエージェントとして動作させることができます。\n詳しくは、Marvelのドキュメントにあるinstalling a secondary monitoring clusterを御覧ください。\n1/29 16時時点で、上記ドキュメントのエージェントの送信先の設定に関する部分に誤記がありました。 おそらく、configuration optionsの記述が正だと思います。 もう、なおってました。(1/30朝時点)\nキャプチャいろいろ 日本語WikipediaのデータをRiverで登録しながら各画面の動作などを見てみました。\nMarvel Overview 日本語WikipediaをRiverで登録してる途中。Loadが高くなってることなどがわかります。\nOverview (クラスタの状態が変化) クラスタの状態が変化したところに、タグが付くみたいです。 ここでは、ノードの一つを停止、起動しました。\nインデックス終了後に、クラスタを再起動してしまい、クラスタ内のシャードの再配置が実行されてしまったため、クラスタの状態がYellowになってしまうとこんな感じ。ちょっとわかりにくいです。\nSense Chromeプラグインとしてリリースされていたクエリ実行コンソールがMarvelのサイトプラグインとして提供されています。これがあるだけで、Elasticsearchへのクエリの実行が格段に効率良くなります。\nIndex Statistics インデックスに関する情報のグラフが見れるページです。ドキュメント数の他に、容量やリクエスト数なども見れます。\nインデックス終了後のグラフはこんな感じ。\nインデックス終了後のOverviewはこんなかんじです。\nCluster Pulse クラスタで発生したイベントとイベントの詳細を見ることができるページです。各種インデックスがYELLOWからGREENに変わっていっているのがmessageで分かります。\nすべて再配置が終わったらGREENになりました。\nNode Statistics 各ノードに関する情報を見ることができる画面です。 ノードごとにグラフの色を分けることもできます。\nその他 Marvelプラグインにブラウザから接続できなくなるとこんなメッセージが出ました。\n参考までに、elasticsearch-headの画面も。こちらのほうが、シャードの再配置中であるのがひと目で分かります。\n感想 綺麗です。まぁ、Kibanaが綺麗ですから。 クラスタ内で発生したイベントが時系列で保存されるため、あとからどんなことが発生したのかといった原因の追求などには非常に役に立ちそうです。\nただ、インデックスの状態や状況（クラスタ再起動やノード追加時にshard再配置などが実行されている状況とか）はelasticsearch-headのほうがわかりやすかったです。 インデックス単位でのStatusがMarvelの画面ではわからないため、shard再配置が完了したかどうかなどのタイミングがわかりにくかったです。\nある程度、多くのノードを利用したクラスタを利用する場合に、モニタリングツールとして利用するのは便利なのではないでしょうか？ 時系列でログやイベントが保存されるので、ノードが追加されたり外れたりといった状況があとからでも追跡可能なのが便利です。\n疑問点 インデックスの情報などは、5s毎にMarvelのインデックスに保存されているようです。ただ、GUI上では5分毎のデータしか表示されません。 どうやって変更するんだろう？\nまた、Marvelのクラスタへの接続が切れた時のデータはどうなるのか？という部分も気になります。Marvelのクラスタを更新している時や、ネットワークが遮断されてしまった場合のデータがどうなるのかという点です。\n疑問点への回答(2014/01/30追記) 疑問点に対して中の人から回答を頂いたので、追記です。\nQ：GUI上で5分毎のデータしか表示されないんですが？ A：ブラウザの負荷を高くしないようにするために、1つのグラフに20のプロットしてるだけです。ズームしたりすると、もっと細かなデータが見れますよ。 Q：Marvelのクラスタへの接続が切れた時のデータはどうなるんだろう？ A：接続が切れた場合は、ローカルに保存されるけどデータは無視されます。接続が戻ると、戻った後のデータは記録されていきます。将来的には改善するかも。 ちなみに、昨日試してた環境が、足元Linux環境（監視対象のクラスタ）＋手元Mac環境（Marvelモニタリングデータ格納クラスタ）という環境でした。 確かに、出社してから、手元Mac環境を起動すると、データが流れてくるようになりました。 ただ、監視対象のクラスタでは、socket timeoutのログがずっと出てましたが。\n参考文献 リリースブログ プロダクトページ ドキュメント ","date":1390983240,"dir":"post/2014/","id":"f6debed350f20a2b3aa4d970e3227411","lang":"ja","lastmod":1390983240,"permalink":"https://blog.johtani.info/blog/2014/01/29/simple-introduction-and-first-impression-es-marvel/","publishdate":"2014-01-29T17:14:00+09:00","summary":"昨晩、Elasticsearchから初のプロダクトとなるMarvelがリリースされました。ということで、さっそく触ってみて、簡単な紹介と感想","tags":["elasticsearch","marvel"],"title":"Elasticsearch Marvelの紹介と第一印象"},{"contents":"Lucene/Solr 4.6.1がリリースされそう(バイナリ配布待ち)lucene-gosenの4.6.1対応版をリリースしました。\nライブラリのインタフェースなどは特に変更はないのですが、ライブラリのダウンロード先が変更になっているため、注意喚起です。\nGoogle Project Hostingの仕様変更により、Downloadsに新規ファイルがアップロードできなくなっています。（2014年から）\nこのため、プロジェクトの選択肢としては以下の3点となっています。\nGoogle Driveにファイルをアップロードしてダウンロードしてもらう 他のソースコード管理サイトなどを利用する。 他のダウンロードサイトを利用する 1.と3.は場所が違うだけで、方法は一緒です。 今回は、暫定的に1.を利用してダウンロードするように対応しました。\nダウンロード先はプロジェクトのページにリンクが有りますが、わかりにくいのでキャプチャを撮ってみました。\nダウンロード先 これまでのFeatured - Downloadsとは異なり、Links - External linksの下に Downloads lucene-gosen 4.6.1というリンクを用意してあります。\nフォルダとなっており、各種jarファイルがリストされていますので、こちらからダウンロードをお願いします。 今後は、この下にダウンロードリンクを追加していく予定です。\nただし、2.で述べたように「別のソースコード管理サイト」も検討中です。\n","date":1390880040,"dir":"post/2014/","id":"c4e7199a586a308352b7a881add7e356","lang":"ja","lastmod":1390880040,"permalink":"https://blog.johtani.info/blog/2014/01/28/release-lucene-gosen-4-dot-6-1/","publishdate":"2014-01-28T12:34:00+09:00","summary":"Lucene/Solr 4.6.1がリリースされそう(バイナリ配布待ち)lucene-gosenの4.6.1対応版をリリースしました。 ライブラリのインタフェースな","tags":["Solr","Lucene","lucene-gosen"],"title":"lucene-gosen 4.6.1のリリースに関する注意点"},{"contents":"Elasticsearchのcuratorのブログ記事を読んで、日本語でツイートしたところ、Aaron Mildensteinさんから日本語（ローマ字）で返信を頂きました。 せっかくなので、ブログ記事を翻訳してもいいかを尋ねたところ、快くOKを頂いたので、翻訳してみました。参考になればと。（誤訳など見つけたらコメントください。）\n@johtani Kore no hou ga ii. Nihongo de no Curator RT, arigatou gozaimasu! #elasticsearch #curator #logstash\n\u0026mdash; Aaron Mildenstein (@theuntergeek) 2014, 1月 22 curator: 時系列インデックスの管理 原文：curator: tending your time-series indices\n背景 数年前、Elasticsearch、Logstash、Kibana(ELK)を管理し、ここ30日よりも古いインデックスを自動的に削除する方法を必要としていました。 APIドキュメントを読み、#logstashや#elasticsearchのIRCチャネルのコミュニティの助けを借りて、簡単なスクリプトとcronを用意するのが簡単であることを知りました。\ncurl -XDELETE \u0026#39;localhost:9200/logstash-2014.01.01?pretty\u0026#39; もちろん、これも動作しますが、日付を生成するのがめんどくさいのでもっとエレガントな方法が欲しかったです。\n最初に pythonでスクリプトを書き始めました。特定の日数のインデックスを管理するだけのコマンドラインクリーナーを書いてコミュニティにシェアしました。他の人が、新しい機能を追加してくれました。私は、古いインデックスをoptimizeすることができる他のスクリプトも書きました。これは、シャードごとにnセグメント以上存在しないように各シャードのセグメントをマージすることです。これらのスクリプトで1つになるようにマージしたりエンハンスし、古いインデックスを管理する助けになるツールです。\ncuratorの紹介 Curatorで可能なインデックスオペレーション\n削除（日付もしくは、トータル容量による制限） インデックスのクローズ(Close) bloom filter cacheの無効化 Optimize(LuceneのforceMerge) curatorのインストール この記事を書いている時点で、Curator は0.5.1がリリースされ、0.90.10に対応しています。Curatorはまた、Elasticsearchの1.0(現在はRC1)へも対応しています。各リリースへの互換性の保証のためのテストも行っています。\n現時点では、gitリポジトリで配布しています。近い将来、pipによるインストール可能なパッケージにする予定です。利用することを恐れないでください。もし、pythonとpipがあなたのマシンにインストールされていれば、次のようにインストールは簡単です。\ngit clone https://github.com/elasticsearch/curator.git pip install -r requirements.txt インストール後の確認は次のコマンドです。\n$ ./curator.py -v curator.py 0.5.1 利用方法とサンプル サンプルを示す前に、オプションを見ておくとよいでしょう。このリストは長いですが（この記事の最後に含まれています）、どのようなことがコントロールできるかを説明しています。デフォルトがどうなっているかに注意してください。もし、デフォルト値で良い場合は、フラグを指定する必要はありません。\nでは、簡単なサンプルを見ながら、CuratorがELKスタックをどうやって管理するかを見て行きましょう。\n削除(delete) 90日以上のインデックスを保存したくないとしましょう。コマンドは次のようになります。\n$ curator.py --host my-elasticsearch -d 90 -dで日数を指定しているだけです。簡単でしょ？\n容量による削除(delete by space) これは、指定したギガバイト数を超えたインデックスを場合に(最も古いものから)削除を行う特殊なケースです。\n$ curator.py --host my-elasticsearch -C space -g 10024 -Cでspaceによるcurationであること、-gでギガバイト数(10024、10TB)であることを指定しているのがわかります。-gは1.5や0.5という数値を指定できます。\nその他のCuratorオプションはspaceによる削除と組み合わせて使用できないことに注意してください。\nクローズ(close) Open/Close Index APIにより、インデックスをクローズすることができます。\nopen/close index APIを利用すると、インデックスをクローズしたり、あとでオープンしたりすることができます。クローズされたインデックスはクラスタのオーバヘッドにほとんどならず(メタデータの管理を除く)、読み書き操作の妨げにもなりません。クローズされたインデックスは、リカバリプロセス時に、オープンされます。\nインデックスをクローズすることは、存在はするが検索できないという意味です。何が便利なのでしょう？\n90日のインデックスを保存する義務があるが、検索は過去30日のインデックスを対象にする以外は稀であるような場合を想像してください。このような状況で、価値のあるリソース(ヒープスペースなど)を節約するためにインデックスをクローズすることができます。これは、クラスタに検索やインデキシングのためのメモリを与えることができることを意味します。そして、もし、クローズしたインデックスのデータが必要になったら、APIを呼び出してインデックスをオープンすれば検索できます。\nこのような場合、今オープンしているインデックスが再び、クローズされないように、一時的にCuratorのスケジュール実行をオフにしておくのが懸命です。\n$ curator.py --host my-elasticsearch -c 30 -d 90 先ほど説明した例の実行方法です。これは、30日よりも古いインデックスはクローズし、90日より古いインデックスを削除します。本当に簡単でしょ？\nbloom filterの無効化 これは、0.90.9以降のバージョンで利用可能な機能です。(リンク先はIssue #4525)\n心配しないでください。このスクリプトは操作を行う前に、elasticsearchが利用可能なバージョンであるかをチェックします。\nbloom filterとは何でしょう？なぜ、無効化したくなるのでしょう？\nbloom filterはインデキシング操作を高速化するためにリソースを割り当てられます。時系列データで、インデキシングしている間もこれは有用です。インデックスは2日後には、日付が変わると新しいデータはおそらくインデックスされません。そのインデックスにはもはや必要のないリソースをbloom filterはまだ持っています。Curatorはこれらのリソースを開放することができます！\n$ curator.py --host my-elasticsearch -b 2 -c 30 -d 90 これで、bloom filterのリソースは少なくとも2日(1にもできます)よりも古いインデックスについては利用せず、30日より古いインデックスはクローズし、90より古いインデックスは削除します。\noptimizeというよりもforcemerge コマンドの説明をする前に、Elasticsearch APIのoptimizeを見ることは、生きているインデックスや\u0026quot;cold\u0026quot;インデックス(インデキシングがアクティブではないという意味)に実行する必要があるということを理解するために重要です。実際、optimizeはLuceneではforceMergeと名前が変えられ、インデックスを改善するためにoptimizeを呼び出す必要はなくなりました。Elasticsearchのセグメントをマージすることは利点がありますが、coldインデックス全てに対してoptimizeを開始する前に、コストを理解する必要があります。\nforceMerge操作はインデックスにある各シャードのセグメントの数を少なくします。各セグメントはオーバヘッドがあるため、セグメントが多いということは、より多くのリソースを使うという意味です。良さそうですね？リソースが少ない？\nそれは、可能ですが、merge操作を実行するには多くのディスクやネットワークI/Oが必要で、ディスクやクラスタの通常の書き込み操作に悪影響を及ぼします。もし、これが必要なら私のアドバイスを良く考えてください。(数％ほど)検索を速くし、リソースの使用量も減らすことができます。また、管理しているセグメント数が小さくなるということは、クラスタのリカバリを速くすることにもなります。1つのインデックスをoptimizeするためにはおそらく1時間以上の時間がかかります。「使用する前に目立たない場所で試してください」というクリーニングボトル(訳注：洗剤とか漂白剤かな？)の注意書きと同様に、ディスクI/Oが低い時にテストし、もし操作とリソースがあなたのクラスタのユースケースにあっているかを見てください。デフォルトでは、シャードごとに2つのセグメントにマージしますが、--max_num_segmentsフラグで変更可能です。\nここまでのサンプルは次のようなコマンドになります。\n$ curator.py --host my-elasticsearch -b 2 -o 2 -c 30 -d 90 これで、bloom filterは2日より古いインデックスでは向こうにし、2日より古いインデックスは\u0026quot;optimize\u0026quot;し、30日より古いインデックスはクローズし、90日より古いインデックスは削除されます。\n操作の順序 スクリプトは操作が衝突するのを防ぐために次の順序で実行されます。なぜ、クローズされたインデックスはoptimizeしないのでしょう？なぜ、削除予定のインデックスはクローズされないのでしょう？\nDelete (by space or time) Close Disable bloom filters Optimize 使用の検討 最後の例で、3つの操作を1つのコマンドで実行していますが、それらが連続ですべて実行されるのを望んでいないかもしれません。\n$ curator.py --host my-elasticsearch -b 2 -o 2 -c 30 -d 90 これは、次の操作と同様です。\n$ curator.py --host my-elasticsearch -d 90 $ curator.py --host my-elasticsearch -c 30 $ curator.py --host my-elasticsearch -b 2 $ curator.py --host my-elasticsearch -o 2 これらのコマンドを異なる時間に実行したり、異なるその他のオプション(特に、optimize実行で--timeout 3600を追加したり)を指定して実行するのは簡単です。\nまた、デフォルトのlogstash-とは異なるプレフィックスのインデックスを持っているかもしれません。\n$ curator.py --host my-elasticsearch --prefix logstash- -d 30 $ curator.py --host my-elasticsearch --prefix othername- -d 30 最後に Curatorは時系列インデックスの保存ポリシーを管理するのに役立ちます。豊富な設定オプションがインデックスを管理することを簡単にします。クラスタに存在するノードの数に関係なく。https://github.com/elasticsearch/curatorへのフィードバックやコントリビューションをお待ちしています！\n参考(全引数とオプション) $ curator.py -h usage: curator.py [-h] [-v] [--host HOST] [--port PORT] [-t TIMEOUT] [-p PREFIX] [-s SEPARATOR] [-C CURATION_STYLE] [-T TIME_UNIT] [-d DELETE_OLDER] [-c CLOSE_OLDER] [-b BLOOM_OLDER] [-g DISK_SPACE] [--max_num_segments MAX_NUM_SEGMENTS] [-o OPTIMIZE] [-n] [-D] [-l LOG_FILE] Curator for Elasticsearch indices. Can delete (by space or time), close, disable bloom filters and optimize (forceMerge) your indices. optional arguments: -h, --help show this help message and exit -v, --version show program version number and exit --host HOST Elasticsearch host. Default: localhost --port PORT Elasticsearch port. Default: 9200 -t TIMEOUT, --timeout TIMEOUT Elasticsearch timeout. Default: 30 -p PREFIX, --prefix PREFIX Prefix for the indices. Indices that do not have this prefix are skipped. Default: logstash- -s SEPARATOR, --separator SEPARATOR Time unit separator. Default: . -C CURATION_STYLE, --curation-style CURATION_STYLE Curate indices by [time, space] Default: time -T TIME_UNIT, --time-unit TIME_UNIT Unit of time to reckon by: [days, hours] Default: days -d DELETE_OLDER, --delete DELETE_OLDER Delete indices older than n TIME_UNITs. -c CLOSE_OLDER, --close CLOSE_OLDER Close indices older than n TIME_UNITs. -b BLOOM_OLDER, --bloom BLOOM_OLDER Disable bloom filter for indices older than n TIME_UNITs. -g DISK_SPACE, --disk-space DISK_SPACE Delete indices beyond n GIGABYTES. --max_num_segments MAX_NUM_SEGMENTS Maximum number of segments, post-optimize. Default: 2 -o OPTIMIZE, --optimize OPTIMIZE Optimize (Lucene forceMerge) indices older than n TIME_UNITs. Must increase timeout to stay connected throughout optimize operation, recommend no less than 3600. -n, --dry-run If true, does not perform any changes to the Elasticsearch indices. -D, --debug Debug mode -l LOG_FILE, --logfile LOG_FILE log file ","date":1390542480,"dir":"post/2014/","id":"15f501351d482ffd73985a50f5c89d1f","lang":"ja","lastmod":1390542480,"permalink":"https://blog.johtani.info/blog/2014/01/24/curator-tending-your-time-series-indices-in-japanese/","publishdate":"2014-01-24T14:48:00+09:00","summary":"Elasticsearchのcuratorのブログ記事を読んで、日本語でツイートしたところ、Aaron Mildensteinさんから日本語（","tags":["elasticsearch","curator"],"title":"Curator: 時系列インデックスの管理(日本語訳)"},{"contents":"あけましておめでとうございます。今年もSolrやElasticsearchについて色々と頑張っていく所存です。 とまぁ、お決まりの挨拶はおいておいてと。(もう、新年も22日ですが。。。)\nElasticsearchの1.0.0RC1がリリースされました。 ということで、私が作っているExtended-Analyzeプラグインも1.0.0RC1向けに修正してリリースしました。\n1.0.0RC1向けに修正したこと コミットログを見てもらえば、いいのですが、ロジック自体は変更しなくても良かったです。\nただ、正式に、Elasticsearchのつづりが決定したようで、クラス名が「ElasticSearchほげほげ」から、「Elasticsearchほげほげ」と、SearchのSが小文字になりっています。 この影響で、例外クラスなどの名称を幾つか変更しました。 また、バージョン番号を1.0.0RC1とし、0.x系をElasticsearchの0.90系向けのバージョンにしていく予定です。\n今後は、UIを追加したいと思っているので、Elasticsearchのバージョン番号とはずれてくるとは思いますが。。。\nElasticsearch 1.0.0RC1を利用してみて 1点だけですが。 これまでは、-fオプションを指定すると、デーモンではない動作で起動できていました。（デフォルトがデーモン起動）\nこれが、1.0.0から（0.90の最新もかな？詳しく見ていない）デフォルトの挙動が変更され、デーモン起動ではなくなりました。 代わりに、-dオプションを指定することで、デーモン起動ができるようになりました。\nこれで、手元でうっかりデーモン起動することがなくなって、ひと安心です。（他の人は困るかもしれないけど）\nということで 1.0.0RC1が出たので、少しずつ1.0系で追加されたAPIや機能について、ブログで紹介していけたらと思います。\nこんなこと調べてよ？、これわかんないんだけど？などありましたら、コメントいただければと。 気が向いたら記事を書くので。\nあと、Extended-Analyzeプラグインの感想などもお待ちしています！\n今年もよろしくお願いします！\n","date":1390317360,"dir":"post/2014/","id":"6425af51edead39c0e439073986043fb","lang":"ja","lastmod":1390317360,"permalink":"https://blog.johtani.info/blog/2014/01/22/release-extended-plugin-for-1-0-0rc1/","publishdate":"2014-01-22T00:16:00+09:00","summary":"あけましておめでとうございます。今年もSolrやElasticsearchについて色々と頑張っていく所存です。 とまぁ、お決まりの挨拶はおいて","tags":["elasticsearch"],"title":"Extended-Analyze 1.0.0RC1をリリースしました"},{"contents":"昨年は、大晦日に書いてました。 ちょっと進歩したかも。\n振り返り(2012年に書いた抱負から) ということで、まずは昨年書いた抱負からの振り返りです。\nIntelliJ IDEAをメインに使う JIRAを継続して活用 ブログの継続 elasticsearch Luceneのソースコードリーディング 何かOSSのソースを読む Macでもっと開発 読書と英語を継続 お。思ったよりもできてるかも。 IntelliJ IDEAについては、メインになりました。Eclipseを開くことはまずないです。 Macがメインの開発マシンにもなってきてるので。(開発してないんじゃないかという話も。。。)\nJIRAは一応、継続しているという感じです。\n唯一Luceneのソースコードリーディングができてないですね。。。 言い訳をすると、明示的にソースコードリーディングをしているわけではないですが、Luceneのソース自体は時々見ています。 SolrやElasticsearchを調べるとそのままLuceneにたどり着くことがあるので。\nポモドーロのタスク管理用に使っていますが、時々忘れていたり。あと、振り返りがまだちゃんとできてないので、そこをやらないとかなぁと。 読書と英語は今後も継続です。もっと習慣づけないと。\n振り返り(今年あった出来事など) CROSSでモデレータやりました Xperia Zに機種変 メニエール病 リクルートテクノロジーズさんのお手伝い Lucene In Action輪読やってる MIR輪読も継続 Solr勉強会を不定期開催 Elasticsearch勉強会を始めた Solr本の改訂版を執筆 AWSちょっと触った Elasticsearchプラグイン作ってみた Githubの活用 Octopressでブログ こんなかんじです。\nCROSSでは、モデレータをやらせていただきました。すこしは検索を面白いと思ってもらえたかなと思います。 来年のCROSS 2014ではスタッフとして盛り上げていく予定ですので、スタッフに興味ある方は声をかけてください！ 面白い話がいっぱい聞けますし、おいしい物も飲み食いできるかも！？\nXperia Zは良い買い物でした。ただ、すでに2回電源部分が故障してますが。。。 それ以外は非常に快適です。\n2月末から3月は少し休んでました。難聴→めまい→メニエール病という流れで、ちょっとしんどかったです。 ほぼ回復しましたが、原因は不明みたいなので、長く付き合ってくのかなぁと。\n4月からリクルートテクノロジーズさんの仕事を手伝っています(Solr本の著者紹介にも書いてます)。 色々と面白いことをしているATLという部署で面白い人達と仕事させて頂いてます。 来年もよろしくお願いします！(もっと価値を出さないとなぁ。。。)\nその一環で、Lucene In Actionの輪読を社内でやっていたりも。バージョンが3.x系で書かれているので、 ちょっと大変ですが、4だとどう違うかなどの話を交えつつ少しずつ読んでいます。\n輪読会といえば、MIR(Modern Information Retirieval)の輪読も続いています。 私は深いところまでわからないのですが、色々と詳しい方たちとボチボチ読んでます。教えてもらってばかりですが、来年も頑張りますよと。\nSolr勉強会も、引き継いでぼちぼちやっています。来年は1/29に開催します。Solrの入門的な話をしてもらうので、 ぜひ、触ったことがない方や興味がある人に参加していただきたいと。\nElasticsearch勉強会も主催し始めました。興味ある人がいるだろうとは思ったのですが、想像以上でびっくりしてます。 自分が理解を深め、発表するためにも、2ヶ月程度のスパンで来年も開催する予定です。 スピーカーに興味のある方は、elasticsearch-jpのMLや私にコンタクトしてください。\nSolr入門のSolr4対応版も執筆しました。今回は全体のコーディネートもやらせていただきました。 Solr活用のお役に立てていただければと。まだ購入してない方はぜひ、以下のリンクから！(PDF版もあります。) 質問などあれば、ブログにコメントをいただくか、ツイートしていただくか、技術評論社のサポートページに問い合わせていただければと思います。\nAWSをちょっとだけ触りました。 S3にバックアップ取ってるだけですが。。。来年はもう少し。。。 JIRA（さくらVPSに立ててる）のバックアップなどをやってます。\nあとは、Elasticsearchの勉強会も始めたこともあり、Elasticsearchを色々と触っています。 elasticsearch-analysis-kuromojiプラグインのREADMEを記述してコントリビュートしてみたり、 elasticsearch-extended-analysisプラグインを作ってみたり。\n勉強会のスピーカー探しも兼ねて、いろんなところに、「突撃!隣のElasticsearch」と称してElasticsearchの話を聞きに行きたいと思っていますので、使ってるよ！とか使いたいんだけど、どうすればいい？みたいな話があれば、声をかけてください。Twitterでツイート見たら勝手に、アタックすることもあるかもですが、その時はよろしくお願いします。\n来年はSolrやElaticsearchにもっと貢献できればと。\nGithub(git)もようやくまともに触り始めました。 某データの管理やプラグインの開発などでやっと触り始めました。 まだ、チーム開発ってほどではないので、チームで開発するときのやり方なども少しずつ勉強していこうかと。 プルリクとかも少しずつやってみたりしてます。\nあとは、Octopressでブログ始めました。その前はjugemだったのですが、なんとなく。 Markdownに慣れるためというのもありOctopressにしてみました。 (Solr本の原稿もMarkdownで書いてました) 昔のブログもこっちにコピーするプログラムも書いてみようかな。\n来年の抱負 Elasticsearch勉強会、Solr勉強会の継続＋ミックスした検索勉強会の開催 IDEAのさらなる活用 もっと開発(プラグインとか) AWSをもう少し活用 海外のイベントに行ってみたい 読書と英語を継続 勉強会の開催は今後も継続していく予定です。会場を毎回提供して頂いているVOYAGE GROUPさん、リクルートテクノロジーズさんには、 今後もお手数をお掛けしますが、よろしくお願い致します。勉強会の開催を通じて、色々な人のノウハウがうまく共有できて、 もっと本質的な作業（サービスの改善とか）に注力できる環境ができると面白いなぁと思ってるので。\nあと、Elasticsearch、Solrと別々の勉強会になっていますが、検索エンジン勉強会という形でそれぞれのメリット・デメリットを 共有できる勉強会も面白いかもと思っているので、春とかに開催したいなぁと考えてもいます。（まだ考えているだけで何もネタがないですが）\nIDEAは、年貢(13のサブスクリプション)を収めたので、もっと活用しないとという意味で。プラグインの開発、gitやsvnのクライアントとしては 活躍していますが、もっと開発に活用していかないとなぁと。まだ、10%くらいしか活用できてない気がするので。\nもっと開発しないとなと。毎年言ってますが。今年は書籍に注力したのもあり、ソースを読んだり英語を読んだりが多くなってました。 偉そうにしてるためか、開発する機会が減ってきているので、細かなことでもいいので、すこしずつコードを書いていこうかと。 （もっと自分で問題点を見出してそれを補完するようなコードなりプラグインなり書けばいいんだろうな。）\n開発と合わせて、AWSをもう少し触りたいなと。これも数年言っていますができてないです。。。 ネタ探すのが下手なのかなぁ。\n海外イベントにも行ってみたいです。まだ、海外行ったことないんですが。。。 Lucene Revolutionとか。その訓練も兼ねて英語でメール書いたり、プラグインのREADME書いたりしてみてます。\n最後は、毎年恒例ですが、読書と英語です。 Packtのキャンペーンで買ってしまった英語の本とか貯まっているので、読まないと。 nasneが便利で通勤時間にドラマ見てるからなぁ。ま、必要なときにボチボチと読んでいく予定です。\n最後は、いつものようにですが、来年も勉強会やいろんなイベントに参加する予定です。 ブログも週1程度で書く努力しないとなぁ。 こんな話を書いてくださいとかのリクエストもお待ちしています。\n今年もまだ、大晦日が残っていますが、色々とお世話になりました。 この場を借りてお礼申し上げます。\n来年も、いろんな方に絡んでいくとは思いますが、よろしくお願いいたします。\n","date":1388406000,"dir":"post/2013/","id":"10c715f70de25ccb493bbbb532b78ced","lang":"ja","lastmod":1388406000,"permalink":"https://blog.johtani.info/blog/2013/12/30/looking-back-2013/","publishdate":"2013-12-30T21:20:00+09:00","summary":"昨年は、大晦日に書いてました。 ちょっと進歩したかも。 振り返り(2012年に書いた抱負から) ということで、まずは昨年書いた抱負からの振り返りで","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2013）"},{"contents":"昨夜、Elasticsearchの0.90.8がリリースされました。\nリリースされた内容などについては、本家のブログ「0.90.8 released」をご覧いただくこととして。 1点注意したほうが良い点があります。\nelasticsearch-analysis-kuromojiを利用している場合は、0.90.8に対応したバージョンがリリースされるのを待つ必要があります。\nelasticsearch 0.90.8はLuceneのバージョンが4.6.0に変更されています。 Lucene 4.6.0では、TokenStreamというTokenizerのI/Fに変更があり、Tokenizerの実装を変更する必要があります。\n現時点（2013年12月19日現在）のelasticsearch-analysis-kuromojiの1.6.0にはlucene-analyzers-kuromoji-4.5.1.jarが含まれており、この部分でI/Fが異なるためエラーが発生してしまいます。 プラグインをインストールする時点ではエラーは発生せず、実際にKuromojiのTokenizerやAnalyzerを利用するタイミングでエラーが出ます。 以下、0.90.8にanalysis-kuromojiの1.6.0をインストールした状態で_analyzeを実行した時のエラー。\ncurl -XPOST \u0026#39;localhost:9200/_analyze?tokenizer=kuromoji_tokenizer\u0026amp;filters=kuromoji_baseform\u0026amp;pretty\u0026#39; -d \u0026#39;寿司が美味しかった\u0026#39; { \u0026#34;error\u0026#34; : \u0026#34;IllegalStateException[TokenStream contract violation: reset()/close() call missing, reset() called multiple times, or subclass does not call super.reset(). Please see Javadocs of TokenStream class for more information about the correct consuming workflow.]\u0026#34;, \u0026#34;status\u0026#34; : 500 } ということで、1.7.0がリリースされるのを待つか、自分でmvn packageしてビルドする必要があります。 他にも独自でTokenizerなどを造られている方は注意が必要かと。\nたぶん、すぐにリリースされるんじゃないかなぁと。\n2013/12/20追記\nとりあえず、masterブランチが0.90.8に変更されたみたいです。(と書いてるそばから、1.7.0がリリースされました) ということで、0.90.8では1.7.0を使うとエラーが出ないです。 （あと、踊り字対応のcharfilterも追加されたみたいです）\n","date":1387524240,"dir":"post/2013/","id":"c18b12fff24dc87e7f1039bd17c0c6aa","lang":"ja","lastmod":1387524240,"permalink":"https://blog.johtani.info/blog/2013/12/20/release-elasticsearch-0-90-8/","publishdate":"2013-12-20T16:24:00+09:00","summary":"昨夜、Elasticsearchの0.90.8がリリースされました。 リリースされた内容などについては、本家のブログ「0.90.8 releas","tags":["elasticsearch","kuromoji"],"title":"Elasticsearch 0.90.8がリリースされました＆注意点（2013/12/20追記）"},{"contents":"Solr本が出てから、質問を受けてブログ書くと言いながら書いてなかったことを思い出しました。。。\nプラグインの配置方法についてこんな質問を受けてたので、それっぽいエントリを書いておきます。（想像と違ってたらツッコミ入れてください）\n@johtani 追加でプラグインの配置方法とかあると便利かなと思いました\n\u0026mdash; Tsubosaka (@tsubosaka) 2013, 12月 2 改定前のSolr本では、日本語の形態素解析器をjarファイルとして追加する方法が書かれていました。 ただ、改定後のSolr本では、KuromojiがLuceneで実装されているためサンプルとしてjarファイルを追加するような方法の記載が明確にはありません。\n19ページのcollection1の説明ですこしだけ、libディレクトリについて触れています。\n独自のTokenizer（lucene-gosenなど）はjar形式でSolrに追加し、schema.xmlなどに利用するFactoryを指定してから利用します。\nこのとき、追加のjarファイルを配置する先がlibディレクトリです。\nlibディレクトリは2つの種類のスコープのディレクトリが存在します。\nSolr全体で利用可能なlibディレクトリ コア単位で利用可能なlibディレクトリ Solr全体で利用するlibディレクトリ これは、起動しているSolrにある全てのコアで利用するようなjarファイルを配置するディレクトリになります。 場所は$SOLR_HOME/libです。ここにjarファイルを配置することで、この$SOLR_HOMEを利用するすべてのコアで同じjarファイルを利用することができるようになります。\nですので、例えば、lucene-gosenはすべてのコアで利用するという場合にはここに配置すれば、1つのjarファイルを配置するだけで済むことになります。\nコア単位で利用するlibディレクトリ これは、コアごとにlibディレクトリを用意する場合です。 19ページにも記載されていますが、$SOLR_HOME/コアディレクトリ名/libとなります。\n特定のコアのみで利用するライブラリについてはこちらに配置する形になります。 他のコアで利用してほしくないjarファイルなどを配置するのに利用すればよいかと。\n簡単ですが、補足記事でした。 UIMAやlangidの利用方法などもあるとうれしですかね？ そのうち気が向けば書くかもしれません。（他の人に書いてもらうのもありかも。）\n","date":1387447740,"dir":"post/2013/","id":"cb5b6f7ab4d36e90d2619cb907ebb956","lang":"ja","lastmod":1387447740,"permalink":"https://blog.johtani.info/blog/2013/12/19/add-jar-file-to-solr/","publishdate":"2013-12-19T19:09:00+09:00","summary":"Solr本が出てから、質問を受けてブログ書くと言いながら書いてなかったことを思い出しました。。。 プラグインの配置方法についてこんな質問を受け","tags":["Solr"],"title":"Solrへのプラグインの配置方法について"},{"contents":"ども。 プラグインのインストールに長いURL入れるの辛いですよね？ね？\nということで、MavenでリリースしてMaven Repositoryからダウンロードできるようにしてみました。\n流れとしては\nSonatypeにリリースできるように申請する Sonatypeにリリースする SonatypeからMavenにSyncしてもらう という流れです。\nSonatypeにリリースするための方法はイケメンの人(@yusuke)がブログに簡単ですが残してくれてました。 あと、こちらの@vvakameさんのブログも参考にしながら作業しました。\n【最新版】Maven Central Repository へのライブラリ登録方法 #maven JsonPullParser が Maven Central Repository に入るようです pom.xmlについては、プラグインのpom.xmlを参考にしてもらえればと。 1.の作業が終わったら、リリースを実行します。\nこの時、\u0026lt;scm\u0026gt;タグにgithubの情報が記載されているため（？）、githubにタグを打つ作業もmavenコマンドがやってくれるみたいです。\nmvn release:prepare を実行すると、リリースするバージョンやタグ名などを聞いてくれます。 それらに答えると、pom.xmlにバージョンを指定してcommit\u0026amp;pushしてくれ、タグも打ってくれます。（なんて便利）\nその後、release:performにてSonatypeへのリリースが完了します。 あとは、Sonatypeの画面で作業したら、Mavenのリポジトリにそのうち同期してくれます。\nということで、次のコマンドを実行すればプラグインがインストールできるようになりました。0.6.0と0.7.0の違いは実装には差異はありません。リリース方法が変更されただけということになります。\nbin/plugin -i info.johtani/elasticsearch-extended-analyze/0.7.0 これで少しは活用してもらえるようになるかなぁ？ （どのくらいの人が使ってくれてるのかは不明。。。）\n","date":1387249860,"dir":"post/2013/","id":"a0a00c23556fcc5dbfb7b7f43fbbb61d","lang":"ja","lastmod":1387249860,"permalink":"https://blog.johtani.info/blog/2013/12/17/release-es-extended-analyze-plugin-to-maven-and-sonatype/","publishdate":"2013-12-17T12:11:00+09:00","summary":"ども。 プラグインのインストールに長いURL入れるの辛いですよね？ね？ ということで、MavenでリリースしてMaven Repositoryから","tags":["elasticsearch"],"title":"elasticsearch-extended-analyzeプラグインをMavenとSonatypeにリリース"},{"contents":"少し遅くなってしまいましたが、12/05に電子書籍も発売されました。\n技術評論社の電子書籍サイトから購入可能です。\n書籍のページへのリンク PDF版となっております。 購入の際は、技術評論社の電子書籍サイトに会員登録後購入可能となります。\n個人的には電子書籍が便利なので、こちらを普段活用しようと思っています。\nもちろん、紙の書籍も発売中です！購入の際は右の書影をクリックしていただければと！\n","date":1386554880,"dir":"post/2013/","id":"d9560caeb797b302191f667b4264da40","lang":"ja","lastmod":1386554880,"permalink":"https://blog.johtani.info/blog/2013/12/09/release-introduction-solr-ebook/","publishdate":"2013-12-09T11:08:00+09:00","summary":"少し遅くなってしまいましたが、12/05に電子書籍も発売されました。 技術評論社の電子書籍サイトから購入可能です。 書籍のページへのリンク PDF","tags":["Solr"],"title":"改訂版Solr入門のPDF版も発売"},{"contents":"勉強会で宣伝もしましたが、改めて。\nSolr入門の改訂版を執筆しました。 考えてみれば、もう3年も前なんですね、Solr入門は。 Solr勉強会などでも何度も新しいのは出ないのですか？と聞かれていましたが、やっと出ました。（お待たせしました。）\n時が立つのは早いものです。前回のSolr入門はバージョン1.4にて執筆していましたが、今回は4.4をベースにし、4.5.1への対応を行っています。\n月曜日には手元に見本が届き、今週金曜日に発売予定です！\nSolrCloud、SoftCommit、Spatial、Joinなど、多彩な機能についても記載してあります。 また、ManifoldCFというSolrにデータを登録するのに 利用できるコネクタフレームワークについても書いてあります。\nより多彩になったSolrの機能を活用するための一助となれればと思います。 （電子版も出る予定です。詳細についてはもう少々お待ちください）\nまた、出版を記念して少し時期が先になりますが、Solr勉強会を開催しようと思います。\n日時：2014年01月29日 第13回Solr勉強会 #SolrJP 新Solr本出版記念 今回はせっかくのSolr入門の書籍の出版記念ということで入門的な話をしてもらう予定です。 Solr初心者の方、Solrに興味のある方などに来ていただきたいと思っています。 （プレゼントも用意できるかも！？）\nということで、「改訂版Apache Solr入門」をよろしくお願いします。 （もちろん、購入は下のリンクからですよね！）\n","date":1385436420,"dir":"post/2013/","id":"a2012a3c9cdb1d6fd69afdbadc1e76b6","lang":"ja","lastmod":1385436420,"permalink":"https://blog.johtani.info/blog/2013/11/26/introduction-to-solr-new-edition/","publishdate":"2013-11-26T12:27:00+09:00","summary":"勉強会で宣伝もしましたが、改めて。 Solr入門の改訂版を執筆しました。 考えてみれば、もう3年も前なんですね、Solr入門は。 Solr勉強会な","tags":["Solr"],"title":"改訂版Solr入門を執筆しました"},{"contents":"どーも。以前の記事で開発中としていたプラグインですが、とりあえず、pluginコマンドでインストール出来る形にしてみました。\nインストールなどについては、READMEに記載したのでそちらを参照してもらうことにして、試行錯誤した話をメモとして残しておきます。\nプラグインの開発はしいてたのですが、やっぱりpluginコマンドでインストール出来ないと使ってもらえないよなということで、勉強会も終わったのでちょっと調べてました。\nプラグインコマンド コマンドが用意されてますが、実態はJavaで実装されてて、通常はこんなかんじでプラグインをインストールします。\n./bin/plugin -i elasticsearch/elasticsearch-analysis-kuromoji/1.6.0 この「elasticsearch/elasticsearch-analysis-kuromoji/1.6.0」という文字列ですが、「ユーザ名/リポジトリ名/バージョン」という意味になります。\nで、ダウンロードするURLは以下のものの中から選ばれます。\nelasticsearch.orgのダウンロード用サイト search.maven.org oss.sonatype.org Githubのarchive これらのサイトに先ほどのユーザ名、リポジトリ名、バージョンを利用したURLを組み立てて、ダウンロードしてくれるという仕組みになっています。\nelasticsearch.orgについては、本家の人しかアップロードできないと思うので、なし。\nmaven、sonatypeについては、Mavenのリポジトリにリリースする必要があるんじゃないかなと。 で、昔調べてググって途中で挫折したんですが、挫折してます。手順が結構手間で。。。 （参考記事：【最新版】Maven Central Repository へのライブラリ登録方法 #maven）\nということで、Githubにアップしたらなんとかなるんじゃん？ということで色々と調査して試してみました。（結果はイマイチなんですが。。。）\nその１：mvn release:prepare せっかくGithubだし、せっかくMavenなんだしなんか、pom.xmlに便利な設定したらコマンド一発でリリースできるんじゃない？という甘い気持ちで調査したググったらそれっぽい記事が見つかりました。 「MavenとGitHubの連携」って記事です。\nで、pom.xmlの設定にも他のプラグインを真似してコピペしたものに\u0026lt;scm\u0026gt;ってタグがあったなぁと。このコマンドでついでにGithubにアップロードできるんじゃないの？ということで、試してみました。\nmvn release:prepare このコマンドを叩くと、記事にあるとおりにいくつか質問をされます。 タグについては、プロジェクト名-バージョン番号という文字列がデフォルトだと指定されているので、v0.5と変更して実施してみると、Githubのreleaseにv0.5ってのができてるじゃないですか。\n※pluginコマンドはGithubを見に行く時に次のファイルをダウンロードしに行きます。\nhttps://github.com/ユーザ名/リポジトリ名/archive/vバージョン名.zip やった！と思い、早速pluginコマンドを実行してみましたが、エラーが出ました。。。\nTrying https://github.com/johtani/elasticsearch-extended-analyze/archive/v0.5.zip... Downloading ...DONE Installed johtani/elasticsearch-extended-analyze/0.5 into /Users/johtani/projects/tmp/ess_env/second_node/elasticsearch-0.90.7/plugins/extended-analyze Usage: -u, --url [plugin location] : Set exact URL to download the plugin from ...省略... Message: Error while installing plugin, reason: IllegalArgumentException: Plugin installation assumed to be site plugin, but contains source code, aborting installation. あらら、なんで？と。\nで、実際にgithubにアップされてたzipファイルをダウンロードしてみたら、githubのリポジトリにあるディレクトリ構成がそのまま入ってるじゃないですか。。。 そうですか、そうですよね。prepareだし、タグ打ってzipにかためてくれるだけなんですねと。。。\nおそらく、siteプラグインだけの場合はこの方法でpluginコマンド叩けばOKなんでしょうが、私がダウンロードしてもらいたいのは.jarファイルが入ったzipファイルなんです。\nということで、断念しました。（タグ消したりをgitコマンドで叩いて綺麗にし直すとか虚しい作業をしてました）\nその２：github.comのWebでリリース おとなしく、Sonatypeのサイトにアップロードする方向でがんばればいいんですが、とりあえず使えるようにするのが先だと思い、 github.comのページでアップロードしてしまおうと。\n「release」というタブをクリックすると、画面からアップロードできるようになります。\nzipファイルを作ってアップロードしました。（zipファイル自体はmvn packageコマンドを実行したらtarget/releaseというディレクトリに作成されてる）\nこれで行けるだろということで、またpluginコマンドを実行すると\nTrying https://github.com/johtani/elasticsearch-extended-analyze/archive/v0.5.zip... Downloading ...DONE Installed johtani/elasticsearch-extended-analyze/0.5 into /Users/johtani/projects/tmp/ess_env/second_node/elasticsearch-0.90.7/plugins/extended-analyze Usage: -u, --url [plugin location] : Set exact URL to download the plugin from ...省略... Message: Error while installing plugin, reason: IllegalArgumentException: Plugin installation assumed to be site plugin, but contains source code, aborting installation. あれ？同じエラー？なんで？jar入りのzipファイルアップロードしたのに？？？\nと。で、https://github.com/johtani/elasticsearch-extended-analyze/releasesにreleaseのページができてたので見てみると、あら。 アップロードしたファイルについては次のようなURLになってるじゃないですか。\nhttps://github.com/johtani/elasticsearch-extended-analyze/releases/download/v0.5/v0.5.zip で、よく見ると「Source code(zip)」というボタンもあるぞ？このリンクは？\nhttps://github.com/johtani/elasticsearch-extended-analyze/archive/v0.5.zip 。。。あぁ。そうですか。そういうことですか。理解してない私が悪いんですねと。\n結論？ ということで、とりあえず、releaseにjar入りファイルはアップロードできた（手動で）ので -uオプションで直接URL指定すればインストールできるだろ！と諦めました。 いい勉強になりました。。。\nREADME見ていただくとインストール方法が分かりますが、長いです。。。\n時間をとって本腰入れてSonatypeにMavenコマンドでアップロードできるようにしようかな。。。\n","date":1384419300,"dir":"post/2013/","id":"13684d16fdd07d5f0584e29265a270e7","lang":"ja","lastmod":1384419300,"permalink":"https://blog.johtani.info/blog/2013/11/14/release-elasticsearch-extended-analyze-0-dot-5/","publishdate":"2013-11-14T17:55:00+09:00","summary":"どーも。以前の記事で開発中としていたプラグインですが、とりあえず、pluginコマンドでインストール出来る形にしてみました。 インストールなど","tags":["elasticsearch","plugin"],"title":"elasticsearch-extended-analyzeを公開？"},{"contents":"第2回を開催しました！ すごい、140人くらいくらいの参加登録者（参加者は１００人ちょっと！）がいて、びっくりです。 ステキな会場を提供していただいた、リクルートテクノロジーズさん、運営していただいた方々、スピーカーの皆さん、参加者の皆さん本当にありがとうございました。 今回も素敵な看板ありがとうございます。\n今回もしっかり楽しめたので、次回も頑張ります！\n今回は、elasticsearch-jpMLの紹介とかをできたのでよかったかなぁと。 ぜひ、活用してください！どんな質問でもいいので。\nあと、スライドに入ってた例の本もよろしくです。\nということで、懇親会も盛り上がったし楽しかったです。 今後も場の提供＋自分の勉強のトリガーとして、開催していくので、ご協力お願いします！ 聞きたい話など、MLや@ツイートしていただければと。\nelasticsearchのRouting機能：株式会社シーマーク　大谷　純　（@johtani） スライド：Routing機能※スライドはPDFです。\nド緊張で、大した発表ではなかったですが。。。 どちらかと言うとSolr本の紹介だったかもなぁ。スミマセン。\n※スライドが一部文字が消えてるので、作りなおすかも。\nElasticSearchを使ったBaaS基盤の開発(仮)：株式会社富士通ソフトウェアテクノロジーズ 滝田聖己さん（@pisatoshi） スライド：https://speakerdeck.com/pisatoshi/elasticsearch-trial-and-error\n本日はお越しいただきありがとうございました！しかも静岡から！今後もよろしくお願い致します。\nEnchantMoonでシステム構成ｗ\n0.17.0から利用されていると。（スゴイ）\nプライマリのデータストア！ただし、登録元データはMySQLにもある。\n階層も深く、大きめのドキュメント。\nレプリカ１、インデックスのバックアップも取ってないと。。。\nルーティングの機能\nDynamicMappingの問題点\nマッピング定義が肥大、型がコンフリクト。。。苦労しっぱなし\nデータ登録は１台にして、１台で一気に登録してから再配置\n実際に運用とかされてるので、いろんなノウハウがまだまだありそう！\nKibana入門：水戸祐介さん（@y_310） スライド：https://speakerdeck.com/y310/kibanaru-men\n（やっぱりru-menになってるｗ）\n実は、押しかけて話してもらうように説得したのでした。今後もよろしくです。\nCOOKPADの方によるKibanaのお話。 Kibanaの利点とかなんで？とか。 画面構成の説明から ダッシュボードは必ず保存して！リロードしたら悲しい思いをしてしまうので。 sparkline便利そうだなぁ。ほんとに、データサイエンティスト系のツールを目指してるのかな 一通り、ダッシュボードに配置できるパネルの説明してもらえたのですごく参考になりました！ Tips周りが役に立ちそう。not_analyzedは重要ですよね。 LT 「データ集計用ダッシュボードブラウザとしても使えるElasticSearch＋Kibana v3を利用する際の運用ノウハウ紹介」：株式会社リブセンス Y.Kentaro さん (@yoshi_ken) さん スライド：http://www.slideshare.net/y-ken/elasticsearch-kibnana-fluentd-management-tips\nKibanaの紹介とかFluentdの紹介。 Tips満載すばらしい。 JDBC riverは0.90.6ではうまく動かないので、気をつけてと。 「Fluentd as a Kibana」：@repeatedly さん スライド(gist)？：https://gist.github.com/repeatedly/7427856\nKibanaがfluentdの中で動くと！？\n「Authプラグインでアクセスコントロール」：株式会社エヌツーエスエム 菅谷信介さん (@shinsuke_sugaya) スライド：http://www.slideshare.net/shinsuke/es-auth-plugin\nAPI毎？インデックスごと？にアクセス制御ができるプラグイン\n","date":1384247760,"dir":"post/2013/","id":"66f43ab4b823d67f52735bbbe6ba65b0","lang":"ja","lastmod":1384247760,"permalink":"https://blog.johtani.info/blog/2013/11/12/elasticsearch-japan-user-meetup-no2/","publishdate":"2013-11-12T18:16:00+09:00","summary":"第2回を開催しました！ すごい、140人くらいくらいの参加登録者（参加者は１００人ちょっと！）がいて、びっくりです。 ステキな会場を提供していた","tags":["elasticsearch","kibana","fluentd","勉強会"],"title":"第2回elasticsearch勉強会を開催しました！ #elasticsearchjp"},{"contents":"Cloudera World Tokyo 2013に参加してきました。\n午前中はあいにくの雨でしたが、それでも結構な人数が最初の基調講演から参加されてました。 私が参加したセッションは大盛況な感じでした。\nおみやげとしてカステラも頂いちゃいました！\nまた、色々なセッションに現れたこんなメッセージ画像も見つけました！\n昨日の写真データの整理をしていたら、こんなものが・・・ @shiumachi さんよ・・・ #cwt2013 pic.twitter.com/S0JsxSYXIx\n\u0026mdash; Kenichiro HAMANO (@hamaken) November 8, 2013 やっぱり、スーツの人が多いなという印象。\n名刺を毎回回収されるのはちょっとつらかったです。なにか、いい方法ないですかねぇ。\n以下はいつもの個人メモです。\n「ビッグデータプラットフォームとして進化するHadoop」 Cloudera株式会社　代表取締役　ジュセッペ小林氏 Costcoなどの写真を元にビッグデータを可視化 BigDataとHadoopの関係 検索、SQL、機会学習、数理処理、データ管理などにもHadoopの活用されつつある。 セキュリティ、データ管理、クラスタ上でのツールの実行なども増えてきてる。\n「今日ビッグデータは明日のスモールデータ」\nアーキテクチャとしてのビッグデータ 多種多様なデータを一箇所に集約し、生データを直接活用できる。 OSSとしての責任も。\nデータサイエンス Opsだけでないデータ解析にも活用\n「Clouderaのビッグデータプラットフォーム戦略」（仮） 講師：Cloudera, Inc. CTO Dr.Amr Awadallah レガシーな情報アーキテクチャ→スケールできない、可視化の限界、硬直したスキーマなどなど。\nエンタープライズデータハブとしてのHadoopとか。\nビッグデータの歴史と将来展望 講師：国立情報学研究所　アーキテクチャ科学研究系　教授　佐藤一郎氏 ビッグデータの歴史的経緯とか 最初の事例はアメリカの1880年国勢調査。\n「ビッグデータがコンピュータを生み出した」。コンピュータがビッグデータを生み出したんじゃない。\n少量データにもHadoopを\nバッチ処理のリアルタイム化とか（一晩から10分へ） 原点は検索データのインデクシング\nHadoopを使うのが目的じゃないんだから、構築には手を掛けないのがいいよね。\nプラットフォームと発展している\n分散システム研究者から見たHadoop 分散ししテムの難しさを、処理範囲を限定することで巧みに回避 データの近くで処理 研究レベルではリアルタイム化や逐次処理化が活発 全工程で逐次・リアルタイムが必要とは限らない 聞いてばかりじゃなくて、動かしてみましょう。 データサイエンス：超並列分散処理を活用した新たなビジネス価値の創出 講師：アクセンチュア株式会社　工藤卓哉氏 「日経BPのビッグデータ総覧2013」に記事書いてる。 多様化するデータ（社外のデータも）をどうやってうまく活用していくか。 データが教えてくれたこと→まず、データありき、まずデータためましょう。それから解析とかすればいいのでは？というはなし？ 競合他社さんはNGだけど、ブースでデモ？実機？が見れますと。 Hadoopデータプラットフォーム Cloudera株式会社　嶋内　翔氏 まずは宣伝 Cloudera Implaraのフリーブックの日本語版 Hadoop Operationの書籍でるよ プラットフォームを構成するもの Flume Sqoop HBase Hive Impala データ登録してBIアナリストのお仕事にどうやって役立てる？ 外部テーブル：Hiveからはテーブルのように見える仕組み。元ファイルは消えない SerDe（さーでぃー）：データをHiveレコードに変換する仕組み 生データを少し加工しましょう 圧縮したりファイル結合したりはしときましょう。 Hadoop活用のポイント 富豪的プログラミング。リソースケチるな。 ローカルでできることはローカル。むりにHadoopでやんなくてもいいですよねと。バランス重要 スケジューリング実行などはOozie使うと便利。（日次集計とか） Cloudera Searchで元データにインデックス貼れるぞと。検索しながら分析ができる クラスタ管理とか Cloudera manager便利ですよ ストレージリソースの管理。 声掛け、管理者が容量チェック、Cloudera Managerのレポート 少数精鋭でHadoop使おう＝手が回らなくなる。 みんなで使おう＝Kerberos認証とか管理をちゃんと考えないと。けど、文化が根付けば強力。Sentry、Cloudera Navigatorとか。 Hadoopシステムの全体構成図。データの流れと各製品のつながり。 We are hiring!ということで、興味のある方は@shiumachiさんにコンタクトをとりましょうとのこと。 SQLで実現するバッチ処理とストリーム処理 LINE株式会社　田籠 聡氏 資料：Batch and Stream processing with SQL\nLINEのキャラがちらほら出てきた。\nSQL好きですか？\nログの量とか。2.1TB/Day\nバッチ処理とストリーム\n速い集計のためにHadoopが重要 エラー系のログとかはストリームで処理したい\nアーキテクチャ説明\nデータ解析する人って色々。\n管理者 プログラマ サービスディレクタ 経営陣 みんなが集計用処理を理解、編集ができるほうがいい。\n顔あげたらHiveアイコンだらけだったｗ\nShibとか。\nなんでHiveに限るの？\nHiveに着目したバージョンアップだけを考えれば良くなる。 スケジュールクエリが増えてきて、つらい。\nTimeWindowを固定して集計処理をすることで、回避できる。 Norikra!! スキーマレス\nOSS。Esperベース。\nインストールが楽\nクエリの動作のお話。\nhttp://norikra.github.io\nWe Are Hiring!\nHadoop コミュニティと YARN の現状 日本電信電話株式会社　小沢 健史氏 なんでHadoop？ PostgreSQLでやってたけど、大きなデータにはHadoopを使おうという感じになってきた。 なんで使い分けるの？ スキーマ後付け NTTDocomoのモバイル位置情報の統計処理とか？ 技術的な話をするので、HiveTに着替えます！ｗ YARNのなにが嬉しいの？ ImpalaとMapReduceが同時に動くような環境の時に、リソースをうまく管理できないのがV1 そこでYARN Apache Mesosとだいたい一緒。 Apache MesosとYARNの比較 ","date":1383786660,"dir":"post/2013/","id":"a106d7c1b1b277538367f9c8140e3a75","lang":"ja","lastmod":1383786660,"permalink":"https://blog.johtani.info/blog/2013/11/07/cloudera-world-tokyo-2013/","publishdate":"2013-11-07T10:11:00+09:00","summary":"Cloudera World Tokyo 2013に参加してきました。 午前中はあいにくの雨でしたが、それでも結構な人数が最初の基調講演から参加されてました。 私が参加したセッショ","tags":["Cloudera","Hadoop","Norikra"],"title":"Cloudera World Tokyo 2013に参加しました！ #cwt2013 "},{"contents":"またまた、Riak Meetup Tokyo #3に参加してきました。Riak2.0のYokozunaの話があると聞いたので。\nということで、いつものように個人メモです。\n今日は自重して、懇親会はアルコールなしにしました。思いがけずfluentd＋elasticsearch+kibanaという組み合わせの話も聞けて大満足です。 Yokozunaのデモが見れなかったのがちょっと残念だったかなぁ。\n少しだけSolr本の宣伝もしてきちゃいました。\n古城さん@Mixi 「RiakCSとmixi プライベートクラウド環境」 プライベートクラウドとは？ 計算リソースが安い（ストレージは微妙） 開発者が好きに使える環境＋運用側のチケットに追われる毎日からの開放 Riak CSの概要 S3互換の分散ファイルストレージ 検証とか 検証時はRiak CS 1.3\n5ノードで2Mファイルを40万個\n削除は遅延で削除される\nPUT性能とか。\nRiak CSの死活監視にはRiakのstatsとか\n障害対応とか\nクラスタ クラスタは3つ。ログ、サービス（画像） 、バックアップ保存用 ログの収集にfluentd、解析にelasticsearchやkibanaを使っているらしい。 篠原＠Basho 「Riak 2.0: 分散データ型、セキュリティ、そしてより容易な運用へ」 riak 2.0 pre5をリリース アプリ向け機能強化、運用の容易性 設計ポリシーとか、1.xとか 運用、高可用性、水平拡張性 Capabilityネゴシエーションとか 2.0の機能強化 バケットタイプ キーの名前空間としてバケットがあったけど、同種のバケットをまとめて管理とかしたくなった。 データ型の導入（CRDT） Setデータ型 セキュリティとか 強い整合性\u0026hellip; 鈴木@Basho 「Yokozuna: Riak 2.0の新しい全文検索機能」 YokozunaやSolrの概要 1ノードにRiakとSolrが1プロセスずつ SolrプロセスはRiakが管理してくれる SolrCloudは使ってません。 Riakのノードに届いたデータをSolrに裏で書き込んでくれる。 検索時にはRiakのノードが分散検索をしてくれる X-Riak-Metaもインデクシングしてくれる。jsonやxmlの各要素をSolrのフィールドとして認識してくれる。 Extractor Solrは4.4で、JVMは1.7をユーザが入れるらしい。\n","date":1383746460,"dir":"post/2013/","id":"9dca844d353efed03fbaddfc0fab7c76","lang":"ja","lastmod":1383746460,"permalink":"https://blog.johtani.info/blog/2013/11/06/riak-meetup-tokyo-no3/","publishdate":"2013-11-06T23:01:00+09:00","summary":"またまた、Riak Meetup Tokyo #3に参加してきました。Riak2.0のYokozunaの話があると聞いたので。 ということで、いつものように個人メモで","tags":["Riak","Yokozuna"],"title":"Riak Meetup #3 #riakjp に参加しました。"},{"contents":"開発中ですと書きました、elasticsearch-extended-analyzeですが、改良しました。\n改良と変更は以下のとおりです。\nソースのパッケージをorg.elasticsearchからinfo.johtaniに。MLで気になったので質問したら、変えたほうがいいよとのこと。ダウンロード化については、もう少々お待ちを。 出力形式を変更。可能な限りCharFilter、Tokenizer、TokenFilterそれぞれが出力する内容を返すようにしました。 ただし、既存のAnalyzer（JapaneseAnalyzerクラスとか）に関しては、現時点では出力しません。CharFilterなどを取得するI/Fが見えないためです。（改良できるかの調査は未着手） 現時点でできてないのは以下の項目\npluginコマンドでインストール 出力したいAttributeの指定 TokenizeChainで変更されたTokenの追跡（現状はどのTokenがStopFilterで消されたかなどが不明） 画面の用意（簡単に確認できる画面） ということで、README.mdに出力サンプルは貼り付けてるので、興味のある方は試してみてください。 不明点などあれば、コメントかIssueかツイートでも。\n","date":1383570720,"dir":"post/2013/","id":"b5c628b0c1dbf857a475c4be5de4690d","lang":"ja","lastmod":1383570720,"permalink":"https://blog.johtani.info/blog/2013/11/04/improve-output-extended-analyze/","publishdate":"2013-11-04T22:12:00+09:00","summary":"開発中ですと書きました、elasticsearch-extended-analyzeですが、改良しました。 改良と変更は以下のとおりです。 ソー","tags":["elasticsearch","plugin"],"title":"elasticsearch-extended-analyzeの改良"},{"contents":"お久しぶりです。 気づいたらまた、結構ブログを書いてなかったです。。。\n今回は、今開発しているElasticsearchのプラグインに関するお話です。\nいやぁ、名前決めるの難しいですね。これで英語的に合ってるか不安ですが、elasticsearch-extended-analyzeというプラグインを作っています。\nどんなもの？ Solrの管理画面のanalysisに相当する機能が欲しくて作り始めました。\nElasticsearchにはanalyze APIというAPI（名前あってるのかなぁ?）が存在します。\nこれは、文字列を投げると、指定したアナライザやトークナイザでどのようなトークンに分割されるかを調べることができるAPIです。\n例えば、elasticsearch-analysis-kuromojiをインストールしたElasticsearchに対して、以下のcurlコマンドを実行します。\ncurl -XPOST \u0026#39;localhost:9200/_analyze?tokenizer=kuromoji_tokenizer\u0026amp;filters=kuromoji_baseform\u0026amp;pretty\u0026#39; -d \u0026#39;寿司が美味しい\u0026#39; すると、トークナイズされた結果が次のようなJSONで返ってきます。\n{ \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;寿司\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 2, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 1 }, { \u0026#34;token\u0026#34; : \u0026#34;が\u0026#34;, \u0026#34;start_offset\u0026#34; : 2, \u0026#34;end_offset\u0026#34; : 3, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 2 }, { \u0026#34;token\u0026#34; : \u0026#34;美味しい\u0026#34;, \u0026#34;start_offset\u0026#34; : 3, \u0026#34;end_offset\u0026#34; : 7, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 3 } ] } トークナイズの結果がわかるのは嬉しいのですが、どんな品詞なのかといったKuromoji固有のTokenの属性情報がなくなってしまいます。\nSolrでは、こんな画面が用意されていて、品詞情報とかが出力されます。あとは、各TokenFilterでどのトークンがなくなっているかなどもわかるようになっています。\nこれって結構役立つと思うんですよ。 ということで、Pluginも作ってみたかったので、いい機会だから作ってみようかと。\n出力サンプル まずは、その他のAttribute（品詞とか）を表示するところを実装してみました。\ncurl -XPOST \u0026#39;localhost:9200/_extended_analyze?tokenizer=kuromoji_tokenizer\u0026amp;filters=kuromoji_baseform\u0026amp;pretty\u0026#39; -d \u0026#39;寿司が美味しい\u0026#39; 先ほどとほぼ一緒のcurlコマンドを実行します。違う点は**「_analyze」が「_extended_analyze」**となっている点です。\nで、実行結果はこんな感じです。（長いですがそのまま載せてます。続きの文章がしたにあります。）\n{ \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;寿司\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 2, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 1, \u0026#34;extended_attributes\u0026#34; : [ { \u0026#34;org.apache.lucene.analysis.tokenattributes.TermToBytesRefAttribute#bytes\u0026#34; : \u0026#34;[e5 af bf e5 8f b8]\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.PositionLengthAttribute#positionLength\u0026#34; : 1 }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.BaseFormAttribute#baseForm\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech\u0026#34; : \u0026#34;名詞-一般\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech (en)\u0026#34; : \u0026#34;noun-common\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading\u0026#34; : \u0026#34;スシ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading (en)\u0026#34; : \u0026#34;sushi\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation\u0026#34; : \u0026#34;スシ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation (en)\u0026#34; : \u0026#34;sushi\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType (en)\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm (en)\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.KeywordAttribute#keyword\u0026#34; : false } ] }, { \u0026#34;token\u0026#34; : \u0026#34;が\u0026#34;, \u0026#34;start_offset\u0026#34; : 2, \u0026#34;end_offset\u0026#34; : 3, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 2, \u0026#34;extended_attributes\u0026#34; : [ { \u0026#34;org.apache.lucene.analysis.tokenattributes.TermToBytesRefAttribute#bytes\u0026#34; : \u0026#34;[e3 81 8c]\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.PositionLengthAttribute#positionLength\u0026#34; : 1 }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.BaseFormAttribute#baseForm\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech\u0026#34; : \u0026#34;助詞-格助詞-一般\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech (en)\u0026#34; : \u0026#34;particle-case-misc\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading\u0026#34; : \u0026#34;ガ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading (en)\u0026#34; : \u0026#34;ga\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation\u0026#34; : \u0026#34;ガ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation (en)\u0026#34; : \u0026#34;ga\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType (en)\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm (en)\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.KeywordAttribute#keyword\u0026#34; : false } ] }, { \u0026#34;token\u0026#34; : \u0026#34;美味しい\u0026#34;, \u0026#34;start_offset\u0026#34; : 3, \u0026#34;end_offset\u0026#34; : 7, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 3, \u0026#34;extended_attributes\u0026#34; : [ { \u0026#34;org.apache.lucene.analysis.tokenattributes.TermToBytesRefAttribute#bytes\u0026#34; : \u0026#34;[e7 be 8e e5 91 b3 e3 81 97 e3 81 84]\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.PositionLengthAttribute#positionLength\u0026#34; : 1 }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.BaseFormAttribute#baseForm\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech\u0026#34; : \u0026#34;形容詞-自立\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech (en)\u0026#34; : \u0026#34;adjective-main\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading\u0026#34; : \u0026#34;オイシイ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading (en)\u0026#34; : \u0026#34;oishii\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation\u0026#34; : \u0026#34;オイシイ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation (en)\u0026#34; : \u0026#34;oishii\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType\u0026#34; : \u0026#34;形容詞・イ段\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType (en)\u0026#34; : \u0026#34;adj-group-i\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm\u0026#34; : \u0026#34;基本形\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm (en)\u0026#34; : \u0026#34;base\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.KeywordAttribute#keyword\u0026#34; : false } ] } ] } 先ほどの結果に**「extended_attributes」**という配列のオブジェクトが追加された形になっています。 ちょっと長くなってしまいましたが。。。\nSolrの処理を真似して作ったので大したことはやってないんですが、少しは便利になるかもなぁと。\n現時点では、最終的な結果しか取得できないですが、今後は次のような機能を作っていこうかと思っています。 できるかどうかは、やってみてって感じですが。\npluginコマンドでインストール pom.xmlはありますが、まだMavenとかに登録はされていません。ですので、mvn packageしてからjarファイルをpluginsフォルダに配置しないといけません。pluginコマンドでインストールできるともっと使ってもらえるはず？ 出力したいAttributeの指定 リクエストパラメータで、出力したいAttribute名を指定するとか。 出力形式の変更 今は、Solrの真似をしていますが、せっかくJSONだったりするので、もう少し検討しようかと（同じAttributeの異なる値も1オブジェクトとして出力されてる） TokenizeChainの出力 Solr同様、CharFilter、Tokenizer、TokenFilterが動作して、最終的なTokenがインデックスに登録されます。ですので、各処理の直後のTokenがどうなっているかもわかったほうが嬉しいと思うので、それらも取得できるようにしたいなぁと 画面の用意 せっかくプラグインなんだし、画面で見れると嬉しいかなと。これは当分先になっちゃうと思いますが、Webページで確認できるような画面を作ると確認しやすくなるかなぁと。上記対応が終わってから取替かかると思いますが。 とりあえず、思いつくのはこんなかんじです。\nElasticsearchの_analyze APIを真似しただけのコードだし、テストも実装もまだまだですが、とりあえず公開してみました。\n要望などあれば、コメント、Issue、ツイート（もちろん、テストコードなども！）なんでも受け付けてますので、お気軽に。\n","date":1382695560,"dir":"post/2013/","id":"0302e8a57a5e8604342a925b2dc60737","lang":"ja","lastmod":1382695560,"permalink":"https://blog.johtani.info/blog/2013/10/25/developing-es-extended-analyze-plugin/","publishdate":"2013-10-25T19:06:00+09:00","summary":"お久しぶりです。 気づいたらまた、結構ブログを書いてなかったです。。。 今回は、今開発しているElasticsearchのプラグインに関するお話","tags":["elasticsearch","plugin"],"title":"elasticsearch-extended-analyzeプラグインを開発中"},{"contents":"不定期開催ですが第12回Solr勉強会を主催しました。\n今回は、前回ほどの過熱ぶりでは無かったですが、70人ほどの参加者の方がいらっしゃったかと。 ありがとうございます！\n今回は聞きたかったYokozunaの話をしてもらいました。あと、リベンジManifoldCF。 一部、追記しました。Bashoさんからツッコミがあったので。あと、4.5.1の話とか。\nManifoldCFのとSolrの組み合わせ（仮）株式会社 ロンウイット　大須賀　稔さん 前回お休みだったのでリベンジですw。\n英語だ。。。やっぱ英語がいいですか、スライド。。。\nManifoldCFの概要から。 最新版は1.3です。色々サポートしてるなぁ。\nデモもありました。（やっぱりちゃんと動かないので、鬼門みたいですが）\nデモ ManifoldCFのGUIで操作しながら。 いまいちちゃんと動かなかった。。。\nQA Q:Zipはうまく動かなかった A:Solr側で処理してくれてる。 Q:Notes対応するの？ A:いまのところない。 Q:ExcelとかPDFはTika？ A:Tika次第です。 Q:認証周りどこから取ってくるの？ A:クローラ側にはなくて、SharePointとかの権限をみてる。 Q:Web系の認証は？ A:まだないのでは。。。（調査します） あー、デモの続き忘れてましたね。。。\nSolrを組み込んだRiak 2.0の全文検索機能 -Yokozuna- Bashoジャパン株式会社　鈴木　一弘さん Riak色々使われてるよ！アングリーバードとか、Y!とか。 Riakで提供されている1機能としてのYokozuna。単独製品ではないですよと。\nRiakの説明。スケールするよ、いつでもRead/Writeできるよ、運用にフォーカスしてるよと。 マスターレスですよ。 Riak2.0のリリースは2013年末。Yokozunaもかな？\nダイナミックフィールド使ってるので、Yokozunaをonにするだけで簡単に使えるよ。\nRiakがSolrのプロセスを管理。\nインデックスの不整合の検知とかってどうやってるのかなぁ？ インデックス比較用のハッシュツリーをノード間でコピーしつつ検査してる。（Active Anti-Entropy）\n(デモには魔物がいるようだ。。。)\nQA Q:JSONの属性を元にしてフィールドにインデックス可能か？ A:可能です。IIJさんの発表で話が出ます。 Q:ProtocolBufferでSolrにアクセス可能？ A:そのうちできそうです。リリース時にはできるようになっています。 Q:コアのスワップは？スキーマの変更は？ A:事前に設定するのは可能。 Q:RiakのデータとSolrでデータがずれるってのはあるの？ A:可能性はありますが、極力ずれAAEで修復。 Q:復旧中のインデックスにアクセスが行かないようにする仕組みなどはある？ A:今はないです。 Yokozuna ベンチマークしました　株式会社インターネットイニシアティブ　曽我部　崇さん、田中 義久さん いいとこ取りで楽だなぁと。いうことで、試してみてます。 デモが動いてる。\nextractorでXMLやJSONをパースできる。 ベンチマーク結果。\nRiak Meetup Tokyo #2の時のQAも入ってるので助かります。素晴らしい。\nQA Q:スナップショットは両方取れるの？ A:Riakは取れますが、インデックスは今は無理です。 フォロー:0.8はYokozunaにボトルネックがあったので、0.9以降だともっと性能が出るはずですとのこと。また次回とかに発表してもらうのもありですかねぇ。 Solr 4.5の新機能など @johtani 発表資料のPDFです。\nツイート見てて誤解を招いたなと思ったのですが、7u40は4.5限定ではなく、すべてのバージョンと考えてください。 チケットを見ると分かりますが、影響バージョンの記載はありません。\n※あ、4.5のChangesを紹介しましたが、4.5.1が出るかも。このへんが困ってるらしいです。\nSOLR-5306: can not create collection when have over one config SOLR-5317: CoreAdmin API is not persisting data properly LUCENE-5263: Deletes may be silently lost if an IOException is hit and later not hit (e.g., disk fills up and then frees up) LT @haruyama さん 資料：http://haruyama.github.io/solr_20131009/#(1)\n記号が捨てられるTokenizer困るので、捨てないのを作ってみました。\nKuromojiの困ったこと。全角数字を分解しちゃう。→MappingCharFilterFactoryで全角から半角にしましょう。 lucene-gosenデフォで半角記号が未知語になってしまい、半角カナと混ざるので、記号を全角にしましょう。\n","date":1381372500,"dir":"post/2013/","id":"76e127a44931bfefab991be3dd7a08b7","lang":"ja","lastmod":1381372500,"permalink":"https://blog.johtani.info/blog/2013/10/10/solr-meetup-memo/","publishdate":"2013-10-10T11:35:00+09:00","summary":"不定期開催ですが第12回Solr勉強会を主催しました。 今回は、前回ほどの過熱ぶりでは無かったですが、70人ほどの参加者の方がいらっしゃったか","tags":["Solr","Riak","Yokozuna","ManifoldCF"],"title":"第12回Solr勉強会を主催しました。#SolrJP"},{"contents":"今日は、ElasticSearchのMLで見つけたelasticsearch-inquisitorプラグインの紹介です。\nElasticSearchはREST API形式で簡単にコマンドラインからいろいろな処理を実行できて便利ですが、 GUIがあったほうが楽なこともまた事実です。 今回紹介する、inquisitorプラグインもSiteプラグイン（Webブラウザでアクセスできるプラグイン）の1つです。 （ただし、ローカルにインストールしてローカルのElasticSearchにしか接続できませんが。。。）\nインストール プラグインですので、以下のコマンドでインストールが出来ます。インストール後はElasticSearchの再起動が必要です。\nbin/plugin -install polyfractal/elasticsearch-inquisitor ElasticSearch再起動後に、以下のURLにアクセスすればOKです。 ※ローカルでのみ動作可能なプラグインです。（内部で呼び出しているJSにlocalhostと記載があるため）\nhttp://localhost:9200/_plugin/inquisitor/#/ 何ができるの？ 自分の書いたQueryが正しく動作するかや、Analyzerによって文章がどのように、Term（Token）に分割されるかといった挙動をWebブラウザ上で確認することができます。用意されている画面は「Queries」「Analyzers」「Tokenizers」の3種類です。\nQueries クエリの確認、実行が可能な画面です。\n「Index」「Type」はプルダウンになっており、現在ElasticSearchに存在しているものが選択可能です。 その下のテキストエリアがクエリを入力する画面です。\nクエリを入力していると、入力しているクエリがValidかどうかをクエリのコンソール部分（右側上部）に表示してくれます。\n少し残念なことに、Tabを押すと、フォームのフォーカスが切り替わってしまうので、クエリを入力するのがちょっと面倒です。。。（私は通常の検索には、ChromeプラグインのSenseというものを利用してます。）\nクエリに問題がない場合は、「Query」ボタンを押すことで実際の検索が実行されます。 この時、画面真ん中のブルーのテーブル（内部で実行されるクエリ）の部分に、QueryがElasticSearch内部で解釈されたあとの、Luceneで実行されるレベルのクエリに変換されたクエリが表示されます。\nこれが便利です。JSONで記述したり、色々なタイプのクエリがElasticSearchでは実行できますが、望んだ形に単語が区切られているかなどを確認することができるため、非常に便利です。\nElasticSearchのQuery DSLではexplainをtrueにすることで、ヒットしたドキュメントのスコア計算に用いられた単語などがわかるのですが、そもそもヒットしないクエリの場合は、explainでは単語の区切られ方などがわかりません。\nその場合に、このプラグインで確認すると、想定と違う単語の区切られ方やクエリの造られ方がわかるかと思います。\nAnalyzers Analyzerによる文章のアナライズ結果の確認が出来る画面です。 ElasticSearchやSolrにあまり詳しくない場合、どんなAnalyzerが文章をどのように単語に区切って、転置インデックスのキーワードとして利用しているかがわからないと思います。\nこのAnalyzerが文章をどのように単語に区切っているかを確認することができるのがAnalyzers画面です。 こんなかんじの画面になります。\n一番上のテキストエリアが文章を入力する場所です。 文章を入力していくと、その下のテーブルの「Analyzed Text」の部分が変化していくのが分かります。 このグレーの単語が転置インデックスのキーワードとなります。\n予め用意されているAnalyzer以外に、用意されているTokenzier＋Filterの組み合わせも簡単ですが確認可能です。（Tokenizer、Filtersとあるテーブル） ただし、ここまでのどちらも細かな設定は画面上ではできません（Filterの細かな引数の指定など）\n一番下の部分が、ElasticSearchに存在しているインデックスごとに定義されたAnalyzerやフィールドを元にした解析結果を表示することができる領域です。\n自分でマッピングを記述してフィールド定義したものの動作確認や、インデックスを適当に作ったけど、うまくヒットしない場合など、ここで、単語の区切れ方を確認することで、検索になぜヒットしないのかといった問題のヒントを得ることができると思います。\nAnalyzerによっては、インデックス対象の文字として扱わない文字があったりしますので。 先ほどのQueries画面のLuceneに投げられる直前のクエリと、Analyzersでの単語の区切られ方を確認することで、検索がうまくヒットしていないことが判明すると思います。\nTokenizers 最後はTokenizers画面です。Analyzersとほぼ同様ですが、ちがいは、デフォルトで用意されているTokenizerの挙動の確認ができるというだけになります。\n簡単な確認ならここで可能かと。\n注意点は？ まだ開発途中のようで、つぎの部分が課題かと。\nローカルでのみ実行可能 Queries画面の結果の「Explain Result」リンクが未実装 Queries画面のクエリ入力が使いにくい（タブが打てないので） カスタム登録のAnalyzersはインデックスを用意しないと確認できない。（Kuromojiのプラグインを登録しただけでは確認できなかった） 細かな設定のフィールドも用意しないと、Analyzers画面では利用できない まとめ ということで、Inquisitor（読みがわからない）プラグインの簡単な説明でした。 検索にうまくヒットしないという理由は大体の場合、 クエリに入力した文字列が単語に区切られたものと、登録したデータが単語に区切られたものが異なるために検索にヒットしないというものです。\nそのクエリ、データの単語の区切られ方を確認するのに役に立つプラグインじゃないでしょうか。\nちなみに、このプラグイン自体はHTML＋JSで作成されており、実際にはElasticSearchが持っているREST APIをキックしているだけになります。 ですので、Web画面なんか要らないという方は、このプラグインが実際に送信しているリクエストを参考にするとcurlコマンドでどういったリクエストを投げればいいかというのがわかると思います。\n私は軟弱者なので画面があったほうがいいですが。\n","date":1379906820,"dir":"post/2013/","id":"e1870dde155be1a375f155dd1f7ead13","lang":"ja","lastmod":1379906820,"permalink":"https://blog.johtani.info/blog/2013/09/23/intro-elasticsearch-inquisitor/","publishdate":"2013-09-23T12:27:00+09:00","summary":"今日は、ElasticSearchのMLで見つけたelasticsearch-inquisitorプラグインの紹介です。 ElasticSea","tags":["elasticsearch","plugin"],"title":"elasticsearch-inquisitorプラグインの紹介"},{"contents":"river-wikipediaの前々回の記事で書きましたが、bulk_sizeに関連して登録件数がやけにきりが良いのが気になると書いていました。\nで、Riverの仕組みを勉强がてら、elasticsearch-river-wikipediaのソース（1.2.0）を読んでみました。\nRiverの作り Riverはorg.elasticsearch.river.Riverというinterfaceを実装することで作らています。 ただ、Riverがinterfaceとなっていますが、o.e.river.AbstractRiverComponentというクラスを継承して作られています。\nAbstractRiverComponentにはRiverの名前や設定などが用意されています。 ま、ここはそれほど重要じゃないので、軽く流してと。\nRiverの設定関連は実装したRiverクラス（ここでは、WikipediaRiverクラス）のコンストラクタで、設定値の読み取りなどの記述を記載します。 このコンストラクタが、_river/hogehoge/_metaをPUTした時のJSONを元にElasticSearchから呼ばれて、Riverのインスタンスが作成されます。（たぶん、このへんがその処理だと思う。。。このあたりはまた今度）\n実際のRiverの処理はWikipediaRiverクラスのstart()メソッド内部に記述されています。\n@Override public void start() { logger.info(\u0026#34;starting wikipedia stream\u0026#34;); try { ① client.admin().indices().prepareCreate(indexName).execute().actionGet(); } catch (Exception e) { if (ExceptionsHelper.unwrapCause(e) instanceof IndexAlreadyExistsException) { // that\u0026#39;s fine } else if (ExceptionsHelper.unwrapCause(e) instanceof ClusterBlockException) { // ok, not recovered yet..., lets start indexing and hope we recover by the first bulk // TODO: a smarter logic can be to register for cluster event listener here, and only start sampling when the block is removed... } else { logger.warn(\u0026#34;failed to create index [{}], disabling river...\u0026#34;, e, indexName); return; } } ② currentRequest = client.prepareBulk(); ③ WikiXMLParser parser = WikiXMLParserFactory.getSAXParser(url); try { ④ parser.setPageCallback(new PageCallback()); } catch (Exception e) { logger.error(\u0026#34;failed to create parser\u0026#34;, e); return; } ⑤ thread = EsExecutors.daemonThreadFactory(settings.globalSettings(), \u0026#34;wikipedia_slurper\u0026#34;).newThread(new Parser(parser)); thread.start(); } 内部では\nインデックスの作成 バルクアップデート用クライアントの設定 WikiXMLのパーサの初期化 ページごとにキックされるコールバック処理の登録 デーモンスレッドの起動と起動 といった処理の流れになっています。\nで、このスレッドの起動後は、4.で用意したparser.parse()処理がグルグル回ります。\n1ページがパースされるたびに、WikipediaRiver.PageCallbackクラスのproess()メソッドが呼ばれます。 このメソッドの最後で、processBulkIfNeeded()メソッドが呼ばれています。ここで、実際にパースしたページをインデックスに登録する処理が実行されます。\nこのメソッドの1行目が鍵でした。 bulkSize以上の件数がバルクのリクエストに貯まった時だけ、実際にインデックスに登録する処理が実行されます。 このため、スレッドが回っている間は、bulkSize以上のデータが貯まらないと、インデックスへの登録は行われないわけです。\n次に、このスレッドを止めるには、前々回書いたように、_riverにPUTした、Riverの設定をDELETEするしかありません。（あとは、ElasticSearchを停止するとかでしょうか。）\nで、DELETEが実行される呼ばれるのが、WikipediaRiverクラスのclose()メソッドです。\n@Override public void close() { logger.info(\u0026#34;closing wikipedia river\u0026#34;); closed = true; if (thread != null) { thread.interrupt(); } } 見ていただくと分かりますが、スレッド止めて終了です。\n問題点は？ ということで、\nWikipediaのXMLを読み込んでもRiverは停止しない Riverの停止を行ってもスレッドが止められるだけ。 bulkSize以下の件数がcurrentRequestに残っているけど、破棄される とまぁ、こんな流れになっているので、最後の端数のドキュメントがインデックスに登録されないようです。 （まだ、ちゃんと確認してないんですが、備忘録のため先に書いちゃいました。。。）\nじゃあ、全部うまく登録するにはどうしたもんかなぁと。 いまのところ思いついたのはこんな感じです。 他にいい案があったら教えて下さい。\n案１：close()処理の中で、スレッド停止後に、currentRequestに貯まっているデータをインデックスに登録しちゃう 案２：bulkSize以外に、定期的（指定された時間）で登録処理を実行してしまう。 簡単なのでとりあえず、案１を実装してみるかなぁと。 （さっさとコード書けよって話ですね。。。スミマセン） その前にMLで質問ですかねぇ、英語で。\nWikipediaのRiverをざっと眺めてみた感じですが、わかりやすい作りだなぁと。 他のRiverがどうなってるかをちゃんと見てませんが、他にもbulkSize指定をするRiverの場合は、このように件数がbulkSizeに満たない状態ではデータが登録されないといったことがあるかもしれません。\nElasticSearchのソースを読み始める取っ掛かりとしては面白いかと思いますので、興味ある方は読んで作ってみるといいかもしれません。（私は読んだだけですがｗ）\n追記（2013/09/13 21:00） MLで質問してみました。とりあえず、案1を。\nriver-wikipedia does not index all pages\n他のRiverでは対応してるしバグだね、Issue上げてとのことで、あげときました。 ついでにプルリクも出せばいいんでしょうが、プルリクまだやったことないヘタレです。。。\nあと、案2についても同じトピックで質問してます。 どうやら、BulkProcessorにその機能があるよと。 flushintervalというプロパティがありそうです。どうやって設定して、どうやって動くのかとか見てないので、 調査してブログorLTかな。\nbulk udpにはその値を設定できそうなのがあるんだよなぁ。\n追記その２（2013/09/16 23:50） さっそく修正版がコミット(コミットログ)されてました。 結構変わってます。BulkProcessorにflush_intervalの設定をすれば、よしなにやってくれる仕組みがすでに実装されているようです。 bulkSizeについても同様に、BulkProcessorに設定すれば良いようです。 Riverの仕組みが結構スッキリしています。 もともと実装されていた、bulkSizeごとの処理も消されています。 確かに、BulkProcessorの仕組みとして実装されている方がしっくりきますね。\nということで、考える暇もなくコミットされてしまいました。 こうやって質問しつつ、少しずつソースを読んでいこうかなと思ってるとこです。\n","date":1378921080,"dir":"post/2013/","id":"d2e805472f79f0b558f75b90b5e7b4ee","lang":"ja","lastmod":1378921080,"permalink":"https://blog.johtani.info/blog/2013/09/12/question-river-wikipedia/","publishdate":"2013-09-12T02:38:00+09:00","summary":"river-wikipediaの前々回の記事で書きましたが、bulk_sizeに関連して登録件数がやけにきりが良いのが気になると書いていまし","tags":["elasticsearch","wikipedia"],"title":"elasticsearch-river-wikipediaの疑問点"},{"contents":"前々回紹介した、日本語Wikipediaのデータをインデックス登録する記事の続きです。\n今回は、Kuromojiのアナライザを利用してインデックス登録してみます。\n余談（Proxy環境でのプラグインインストール） ElasticSearchのpluginコマンドはJavaで実装されています。（org.elasticsearch.plugins.PluginManager） プラグインのダウンロードには、java.net.URL.openConnection()から取得URLConnectionを使用しています。\nですので、pluginのインストールを行う際に、Proxy環境にある場合は以下のようにコマンドを実行します。\n./bin/plugin -DproxyPort=ポート番号 -DproxyHost=ホスト名 -i elasticsearch/elasticsearch-analysis-kuromoji/1.5.0 elasticsearch-analysis-kuromojiのインストール WikipediaのデータをKuromojiを使って、形態素解析ベースの転置インデックスを作成していきます。 まずは、Kuromojiを利用するために、Analysisプラグインのインストールです。 ElasticSearchのバージョンに対応したプラグインのバージョンがあります。（プラグインのページに対応したバージョンの記載あり） 今回はElasticSearchの0.90.3を利用しているため、1.5.0をインストールします。\n./bin/plugin -i elasticsearch/elasticsearch-analysis-kuromoji/1.5.0 インストール後は再起動しておきます。 なお、Kuromojiを利用して、Wikipediaのデータを登録するばあい、デフォルトの設定では、ヒープが足りなくなるおそれがあります。 ElasticSearchの起動時に以下のオプションを指定して、最大ヒープサイズを2Gとしておきます。\nexport ES_HEAP_SIZE=2g;./bin/elasticsearch Indexの作成（デフォルトでKuromojiのAnalyzerを利用する） Wikipediaのデータを登録する際に、Kuromojiのアナライザを利用したいのが今回の趣旨でした。 一番ラクな方法として、Wikipediaデータのインデックスの設定として、デフォルトのアナライザをKuromojiにしてしまいます。 （きちんと設計する場合は、必要に応じてフィールドごとに指定しましょう）\ncurl -XPUT \u0026#39;localhost:9200/ja-wikipedia-kuromoji\u0026#39; -d \u0026#39;{ \u0026#34;settings\u0026#34;: { \u0026#34;analysis\u0026#34;: { \u0026#34;analyzer\u0026#34;: { \u0026#34;default\u0026#34; : { \u0026#34;type\u0026#34; : \u0026#34;kuromoji\u0026#34; } } } } }\u0026#39; これでkuromojiのアナライザがデフォルトで利用される形となります。 あとは、Riverを起動して登録するだけです。\nRiverの実行 前回と一緒です。 インデックス名（_river/\u0026lt;インデックス名\u0026gt;/_meta）だけは、先ほど作成した「ja-wikipedia-kuromoji」に変更してください。\ncurl -XPUT localhost:9200/_river/ja-wikipedia-kuromoji/_meta -d \u0026#39; { \u0026#34;type\u0026#34; : \u0026#34;wikipedia\u0026#34;, \u0026#34;wikipedia\u0026#34; : { \u0026#34;url\u0026#34; : \u0026#34;file:/home/johtani/src/jawiki-latest-pages-articles.xml\u0026#34; }, \u0026#34;index\u0026#34; : { \u0026#34;bulk_size\u0026#34; : 10000 } }\u0026#39; あとは、インデックスされるのを待つだけです。\nデータ量とか 5.8gbになりました。Kuromojiを利用したため、形態素解析により単語にきちんとトークないずされた結果でしょう。 Uni-gramだと、転置インデックスのボキャブラリも単語に対してヒットするドキュメント数も大きくなるため、 インデックスサイズも大きくなっているのかと。\n検索クエリのサンプルなどはまた後日。（夜遅いので。。。）\n","date":1378138500,"dir":"post/2013/","id":"79e647a3f8b36a1221897f5837c84aff","lang":"ja","lastmod":1378138500,"permalink":"https://blog.johtani.info/blog/2013/09/03/ja-wikipedia-with-kuromoji/","publishdate":"2013-09-03T01:15:00+09:00","summary":"前々回紹介した、日本語Wikipediaのデータをインデックス登録する記事の続きです。 今回は、Kuromojiのアナライザを利用してインデッ","tags":["elasticsearch","kuromoji","wikipedia"],"title":"日本語Wikipediaをインデクシング（Kuromojiバージョン）"},{"contents":"ElasticSearch勉強会 第1回を主催しました。 昨年のpyfesでなんちゃって資料で喋って、1年たちました。\nElasticSearchの書籍（英語）も出てきて、今年はElasticSearchが面白くなりそうだし、使ってる人たちから話も聞きたいなぁということで、主催しました。\n思った以上に興味のある方がいらっしゃったようで、100人応募のところ、チケットがすぐ完売してしまうほど。。。 しかも、当日もほぼ満員ということで、大変な盛況ぶりでした。\nスピーカーの皆様、参加された皆様、会場を提供していただいたリクルートテクノロジーズさん、ありがとうございました！（たぶん、90人くらいいらっしゃってたかと。）\nこんなステキな案内板も用意してもらいました。スタッフのみなさんありがとうございます！ トゥギャっても頂きました。まとめていただいてありがとうございます！\n自分の発表や個々の発表に関する感想は以下のメモに。\nElasticSearch入門 @johtani スライド：ElasticSearch入門※スライドはPDFです。\n緊張しまくりでわかりにくかったですかね。。。 とりあえず、AWSのサービスじゃないってのだけでも覚えて帰っていただければ満足です。 途中で見せたChromeプラグインのSense わからなかった点や質問、ご意見などは、当ブログのコメント、私宛の＠ツイート、なんでもいいので、反応ください。なんでもいいので反応があると、今後の励みになりますので！ ということで、発表でも言いましたが、わからないことがアレば、@johtaniまで投げてもらえれば、「知らない」「ブログのネタにします」「ソレはこんなかんじですかねぇ？（テキトー）」みたいに答えると思います。 Elasticsearch in Actionは帰宅中に、4章追加されたよというメールが届きました。 宿題 クラスタへのノードの追加の処理方法とか、シャーディングの実装とか。 elasticsearchプラグイン入門 ～ mocksolrpluginでSolrと入れ替えてみよう 菅谷さん スライド：elasticsearchプラグイン入門　slideshare\nプラグイン構成とか（公式でまとまってるの見つけられないので助かります。） 作る上でのポイントうれしいです。 パッケージ名変えられるとか、つらい。。。 Solr APIプラグインについて（Solrの振りしてくれる便利なヤツ） 感想 まだ、プラグインを書いたことがないのですが、ちゃんとプラグインはどういう構成で書くんですよというまとまった資料って本家のサイトにもない気がしています。 なので、スライドが公開されたらすごく役に立つかと。 そのまえに、何かプラグイン書いてみます。。。\nDebugging and testing ES systems Chris Birchallさん スライド：Debugging and testing ES systems　slideshare\nテストの方法とか便利なお話（最後のほうしか聞いてなかったですが。。。。） クエリのデバッグは色々とやらないと、なんでヒットしないのってよくあるので。とくに形態素解析を利用した検索の場合、短い文章（クエリ）と長い文章（ドキュメント）で切れ目が変わってうまくヒットしないとかありますよね。 最後に少しだけ話しましたが、n-gramとKuromojiを組み合わせてOR検索とかすると良い場合があります。 インデックスが大きくなったり、OR検索なので遅くなったりというデメリットもありますが。 感想 実際に使われているノウハウを元に話をしていただいたので助かりました。 最初に席を外してたのですが、戻ってきて日本語で普通に発表されててほんとにびっくりしましたｗ テスト用プラグインがあるのとかは知らなかったです。 あと、使われてたIDEがIntelliJ IDEAでしたね！私も使ってます！\nニコニコ動画データセット 25億件を検索可能にしてみよう @PENGUINANA_ スライド：ニコニコ動画を検索可能にしてみよう　slideshare\nkibana@cookpadのお話 どういう挙動するかをやってみればいいじゃんってことで、やってみるのカッコイイ！ http://goo.gl/FYtO5T bigdeskとか。プラグインいろいろ。 感想 さすがです、ペンギン先生。大きなデータセットつかって、構築した環境に関する数値も書かれてる資料ができて素晴らしすぎです。 思った以上にサクサク動いてて、4hでインデクシングできるのもすごいなぁと。 私も見習ってこのくらいがサクッとできるようになりたい。。。 あと、発表後にムチャぶりしましたが、次回はぜひ検索側の性能とかも話してもらえたらと。\n反省点 イベントアテンドだと、キャンセル待ちができない＋どのくらいの方が興味をもっているのかわからない。 イベントページの主催者は複数指定できる方がいい。（土壇場の登録の人が管理できない。私が司会やってたから） マイクが聞こえにくかった（音量調節とかちゃんと調べないと） 懇親会は立食のほうがやはり動きやすい。 懇親会が1時間ちょっとしかできなかった 雑感 ということで、ES勉強会、主催の私が一番楽しめました。ありがとうございます。 （あと、気前よく調べて答えますと言ってしまいました。。。まぁ、いいトリガーになるので、ウェルカムですが）\nやっぱりKibanaについて興味を持ってる人も多いのかなぁという感触がしたので、次回はぜひKibana3の話をしてもらえるように頑張ります。 あと、elasticsearch-headを使われてるんだなぁと。私はelasticsearch-HQを入れて使ってみてます。大きなクラスタ管理まではまだやってないので。\nあとは、やはりいろんな人に助けられてるなぁと実感しつつ、今後も開催するので助けてください！ということで。 （もちろん、Solr勉強会もがんばりますよー）\n関連ブログ ElasticSearch勉強会 第1回 - Go ahead! タムタムの日記 - ElasticSearch勉強会 の参加メモ #elasticsearchjp 第1回ElasticSearch勉強会に行ってきた！ #elasticsearchjp - #侍ズム 第1回 ElasticSearch 勉強会に参加 #elasticsearchjp - seratch 他にもブログを書かれた方がいらっしゃいましたたら、リンクしたいので連絡いただければ。\n","date":1377798120,"dir":"post/2013/","id":"5931f8e3acdac724742c4ee0960d8d40","lang":"ja","lastmod":1377798120,"permalink":"https://blog.johtani.info/blog/2013/08/30/hold-first-elasticsearch-meetup-in-japan/","publishdate":"2013-08-30T02:42:00+09:00","summary":"ElasticSearch勉強会 第1回を主催しました。 昨年のpyfesでなんちゃって資料で喋って、1年たちました。 ElasticSearch","tags":["elasticsearch","勉強会"],"title":"第1回ElasticSearch勉強会を開催しました！ #elasticsearchjp"},{"contents":"久々のブログはElasticSearchネタです。勉強会開催する予定だったりすので、もう少し触っておきたいなと。 お手軽に検索するデータとして、よくWikipediaのデータを使っています。 ElasticSearchにはelasticsearch-river-wikipediaという便利なプラグインがあり、Wikipediaのデータを簡単に検索可能な状態にできます。このRiverを利用して日本語のWikipediaのデータを入れたので、メモを取っておきます。 まずは、river-wikipediaで日本語のデータをインデクシングしてみるまでの説明です。 日本語特有の設定（Kuromojiを利用したインデクシング）などはまた後日。\nプラグインのインストール 対象とするElasticSearchは現時点で最新版の0.90.3とします。 最新版でRiver動かないなぁとつぶやいた影響かどうかはわかりませんが、2013/08/19に最新版のElasticSearchで動作するプラグインが公開されました。\nまずはインストールです。 HPにも書いてありますが、以下のコマンドを実行すればインストールされます。\n$ ./bin/plugin -install elasticsearch/elasticsearch-river-wikipedia/1.2.0 -\u0026gt; Installing elasticsearch/elasticsearch-river-wikipedia/1.2.0... Trying http://download.elasticsearch.org/elasticsearch/elasticsearch-river-wikipedia/elasticsearch-river-wikipedia-1.2.0.zip... Downloading ..........DONE Installed river-wikipedia into /opt/elasticsearch/plugins/river-wikipedia ElasticSearchが起動している場合はプラグインをインストール後、認識させるためにElasticSearchを再起動します。\n日本語Wikipediaのインデクシング 通常は英語のWikipediaがインデクシングされますが、対象となるファイルを変更することで日本語のWikipediaもインデクシング可能です。 手元に日本語Wikipediaのダンプファイルがあるものとします。（ダウンロードはWikipediaデータベースダウンロードのページにあるpages-articles.xml.bz2のファイルです）\nファイルを指定してインデクシングするには、つぎのcurlコマンドを実行します。 コマンドを実行するとすぐにインデクシングが始まりますので注意が必要です。\ncurl -XPUT localhost:9200/_river/ja-wikipedia/_meta -d \u0026#39; { \u0026#34;type\u0026#34; : \u0026#34;wikipedia\u0026#34;, \u0026#34;wikipedia\u0026#34; : { \u0026#34;url\u0026#34; : \u0026#34;file:/home/johtani/src/jawiki-latest-pages-articles.xml\u0026#34; }, \u0026#34;index\u0026#34; : { \u0026#34;bulk_size\u0026#34; : 1000 } }\u0026#39; ここでURLに含まれる「ja-wikipedia」がインデックス名になります。 また、JSONの\u0026quot;url\u0026quot;にはファイルの場所を指定するため、file:で開始するパスを指定します。 例では、bz2を解凍したファイルを指定していますが、bz2のままのファイルでもOKです。\n上記コマンドを実行すると、_riverというインデックスにつぎのようなエントリが増えています。 (curl -XGET 'localhost:9200/_river/ja-wikipedia/_search?pretty)\n{ \u0026#34;took\u0026#34;: 5, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 2, \u0026#34;max_score\u0026#34;: 1, \u0026#34;hits\u0026#34;: [ { \u0026#34;_index\u0026#34;: \u0026#34;_river\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;ja-wikipedia\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;_status\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;ok\u0026#34;: true, \u0026#34;node\u0026#34;: { \u0026#34;id\u0026#34;: \u0026#34;gdyvwpiAR52lqUCcRhVwsg\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Blitzschlag, Baron Von\u0026#34;, \u0026#34;transport_address\u0026#34;: \u0026#34;inet[/192.168.100.7:9300]\u0026#34; } } }, { \u0026#34;_index\u0026#34;: \u0026#34;_river\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;ja-wikipedia\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;_meta\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;wikipedia\u0026#34;, \u0026#34;wikipedia\u0026#34;: { \u0026#34;url\u0026#34;: \u0026#34;file:/home/johtani/src/jawiki-latest-pages-articles.xml\u0026#34; }, \u0026#34;index\u0026#34;: { \u0026#34;bulk_size\u0026#34;: 100 } } } ] } } \u0026quot;_id\u0026quot;: \u0026quot;_meta\u0026quot;というエントリがさきほど登録したWikipediaのRiverに関する設定です。 \u0026quot;_id\u0026quot;: \u0026quot;_status\u0026quot;というエントリが起動したRiverの状態になります。\nRiverの停止 日本語Wikipediaは結構サイズが大きく、手元のAirでインデクシングするのに30分程度かかりました。（bz2圧縮されていないファイルで、何もしていない状態）\n途中でRiverを停止したくなった場合は、以下のcurlコマンドを実行します。\n$ curl -XDELETE \u0026#39;localhost:9200/_river/ja-wikipedia\u0026#39; 先ほど設定した_river/ja-wikipediaの情報を削除すると、エントリが削除されたのを検知してRiverが停止します。ログにはつぎのようなメッセージが表示されます。\n[2013-08-26 18:26:50,130][INFO ][cluster.metadata ] [Blitzschlag, Baron Von] [[_river]] remove_mapping [ja-wikipedia] [2013-08-26 18:26:50,130][INFO ][river.wikipedia ] [Blitzschlag, Baron Von] [wikipedia][ja-wikipedia] closing wikipedia river Riverを停止してもそれまでインデクシングされたデータは検索できます。 データはちょっとだけで良いという場合は、先ほどの_riverのデータを削除してください。 （◯件だけ登録したいとかできるかは調べてないです。）\nサイズとかマッピングとか サイズ インデックス前のXMLのサイズが5.7Gのとき、ElasticSearchのインデックスサイズ（Optimize後）は7.2Gとなりました。すこし古いファイルを利用しているため、最新版とはサイズが異なるかもしれません。\nあと、データ数が、1540000件とやけにきりがいいのがちょっと気になっています。。。 bulkのサイズを10000で指定してインデックスしたので、切れてるのかなぁと。\nということは、データが欠落しているような気がするのでRiverの作りの問題なのか、ElasticSearchの問題なのかはちょっと調べてみないとわからないなと。\nマッピング 出来上がったインデックスのマッピング（Solrでいうスキーマみたいなもの）は次のようになっています。\n{ \u0026#34;ja-wikipedia\u0026#34;: { \u0026#34;page\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;category\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;disambiguation\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;boolean\u0026#34; }, \u0026#34;link\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;redirect\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;boolean\u0026#34; }, \u0026#34;special\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;boolean\u0026#34; }, \u0026#34;stub\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;boolean\u0026#34; }, \u0026#34;text\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;title\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } } } Wikipediaの各種データが上記のフィールドに入っています。 また、マッピングタイプはデフォルトで「page」というタイプになっています。\n検索 先ほどのマッピングを元に検索すればOKです。例えばつぎのような感じです。\ncurl -XPOST \u0026#39;localhost:9200/ja-wikipedia/_search?pretty\u0026#39; -d \u0026#39; { \u0026#34;size\u0026#34; : 3, \u0026#34;script_fields\u0026#34;: { \u0026#34;title_only\u0026#34;: { \u0026#34;script\u0026#34;: \u0026#34;_source.title\u0026#34; } }, \u0026#34;query\u0026#34; : { \u0026#34;query_string\u0026#34;: { \u0026#34;default_field\u0026#34;: \u0026#34;title\u0026#34;, \u0026#34;query\u0026#34; : \u0026#34;千葉\u0026#34; } } }\u0026#39; 結果はこんな感じ。\n{ \u0026#34;took\u0026#34;: 51, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 5, \u0026#34;successful\u0026#34;: 5, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 8616, \u0026#34;max_score\u0026#34;: 5.8075247, \u0026#34;hits\u0026#34;: [ { \u0026#34;_index\u0026#34;: \u0026#34;ja-wikipedia\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;page\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;3582\u0026#34;, \u0026#34;_score\u0026#34;: 5.8075247, \u0026#34;fields\u0026#34;: { \u0026#34;title_only\u0026#34;: \u0026#34;千葉\u0026#34; } }, { \u0026#34;_index\u0026#34;: \u0026#34;ja-wikipedia\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;page\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;2352241\u0026#34;, \u0026#34;_score\u0026#34;: 4.94406, \u0026#34;fields\u0026#34;: { \u0026#34;title_only\u0026#34;: \u0026#34;千葉千枝子\u0026#34; } }, { \u0026#34;_index\u0026#34;: \u0026#34;ja-wikipedia\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;page\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;14020\u0026#34;, \u0026#34;_score\u0026#34;: 4.8754807, \u0026#34;fields\u0026#34;: { \u0026#34;title_only\u0026#34;: \u0026#34;千葉千恵巳\u0026#34; } } ] } } 結果を見やすくするため、タイトルだけを「title_only」という表示にしています。 ただ、この検索だと、一見「千葉」できちんとヒットしているように見えますが、ElasticSearchのフィールドの定義はstring型になっています。なので、実は「千」や「葉」だけのデータもヒットしています。 マルチバイト文字は1文字ずつインデックスされてしまい、query_stringというクエリでは、フレーズ検索などができていないためです。\nまとめ プラグインいれて、XMLファイルがあれば、検索できるデータが出来上がるので、 暇があったら、お試しで触ってみるデータを簡単に入れてみてはどうでしょうか。\nただ、いくつか気になる点も。\n日本語が検索しにくい（string型のフィールドなのでuni-gramっぽくなっている） bulk_sizeの影響で端数が登録できてない（バグ？どうなの？） ということで、ちょっと使いにくいかもなぁということで、つぎはKuromojiを利用してインデックスしてみてみようかなと。次回のエントリで書く予定です。\n","date":1377226920,"dir":"post/2013/","id":"3931327ed463d1568868c5ab8e839148","lang":"ja","lastmod":1377226920,"permalink":"https://blog.johtani.info/blog/2013/08/23/index-wikipedia-ja-to-elasticsearch/","publishdate":"2013-08-23T12:02:00+09:00","summary":"久々のブログはElasticSearchネタです。勉強会開催する予定だったりすので、もう少し触っておきたいなと。 お手軽に検索するデータとして","tags":["elasticsearch","wikipedia"],"title":"ElasticSearchにプラグインで日本語Wikipediaデータを入れてみました"},{"contents":"宿題その2？かな。Solr勉強会でCloudera Searchのスキーマ周りってどうなってるの？という質問が出てて、 なんか調べることになってたので、関係しそうなMorphlinesのLoadSolrコマンドを調べてみました。 こいつが、Solrへの書き込みを実行するコマンドみたいだったので。\n（※Cloudera Searchのスキーマの設定方法とかは調べてないです。）\n（※めんどくさかったので、パッケージ名すっ飛ばしてクラス名書いてます。githubへのリンクを代わりに貼ってます。）\nRecord＝Solrのドキュメント convert()メソッドにて、MorphlinesのRecord（コマンドの処理するデータの１単位）に格納されているKey-ValueデータをSolrInputDocumentクラスのフィールドとして格納しています。 Recordにもフィールドという概念があり、Recordのフィールド＝Solrのフィールドという事みたいです。\nということで、Solrのフィールドは事前に定義しておき、Morphlinesの処理内部でSolrのフィールド名に値を詰めていく感じでしょうか。 別途、sanitizeUnknownSolrFildsというコマンドが用意されていて、Solrのスキーマにないものはこのコマンドを使って、無視するフィールド名に変えたり、雑多なデータを入れるためのフィールド名にするといった処理ができるようです。このコマンド内部で、Solrのスキーマ設定を元に、Solrのフィールドに合致する物があるかをチェックして処理しています。\nSolrへの登録処理は？ Solrへの登録処理自体はLoadSolrクラス内部でDocumentLoaderというクラスのload()メソッドを呼び出しているだけでした。ということで、DocumentBuilderクラスを少し調査。\nDocumentLoader IFでした。。。実クラスは次の条件\nSolrMorphlineContextにDocumentLoaderがあればそちらを採用（他の種類はなにがあるんだろ？） なければ、SolrServerDocumentLoaderをnewしたものを利用 2.の場合がおそらくMapReduceではないパターンのloadSolrだと思われます。SolrServerDocumentBuilderはSolrJのAPIを利用して、Solrへデータ登録していく普通のアプリです。（対象とするSolrは外部に起動しているもののはず＝FlumeのSolrSinkではこちらを採用かな？）\nSolrへの接続情報とか設定ファイルとかSolrCloud用のZooKeeperとかはSolrLocatorクラスに設定される内容が利用されます。\n1.のパターンは、どうやら、Cloudera SearchのMapReduceIndexerToolのクラスにあるMyDocumentLoaderかなぁと。 こちらは、MapReduceを利用する場合に、利用されてるっぽいです（ちゃんと見てないけど） 内部処理は、HadoopのContext.writeメソッドにでSolrInputDocument（＝MorphlinesのRecord）を書きだして、ReducerでSolrOutputFormatでインデックス作成の流れかなと。たぶん、MorphlineMapRunnerあたりを読みこめば解読できるかと。 ちなみに、こちらは、2.とは異なり、SolrLocatorの設定は無視されそう。\n感想＋妄想？ ということで、Morphlinesのデータ流れを考える上で、現時点ではSolrのスキーマを頭の片隅に置きつつ、 Recordの中にあるデータをゴニョゴニョしてデータを形成していくって感じになりそうです。 うまく処理できなかったものとかのカウントとかもとれたりするのかなぁ？とか、また色々と気になるところが出てきますが、一旦ここまでで。。。（だれか、続きを調べて書いてみてくれてもいいんですよ！コマンドもいっぱいあるし！）\nとまぁ、こんなかんじでMorphlinesをちょっとだけ読みました。 よくよく考えたら、こんなの作ったことあるなぁと（こんなに汎用的じゃないけど）。 みんな同じ事考えるんですねぇ。 コマンドパターン？みたいな感じで、I/F決めてSolrとか別のシステムとかにデータ入れる処理を順番に記述できる的なバッチ処理良くかいてます（書いてましたのほうが正解かなぁ）。\n","date":1375434120,"dir":"post/2013/","id":"33e01e2271be22b5ed330045fe6aff50","lang":"ja","lastmod":1375434120,"permalink":"https://blog.johtani.info/blog/2013/08/02/morphlines-loadsolr/","publishdate":"2013-08-02T18:02:00+09:00","summary":"宿題その2？かな。Solr勉強会でCloudera Searchのスキーマ周りってどうなってるの？という質問が出てて、 なんか調べることになって","tags":["Cloudera Search","Morphlines","Solr"],"title":"MorphlinesのloadSolrをちょっとだけ調べてみた"},{"contents":"今朝起きたら、Xperia Zが故障してしまいました。 電源ボタンを押してもスリープにならないんです。しかも、スリープからの復帰もできない。。。\nということで、ドコモショップに行って来ました。対応も良かったです。 やっぱり、ボタンがおかしく再起動してもNGでした。 ということで、トントン拍子で交換品に変更してもらえました。\n2、3回繰り返し言われましたが、データなくなりますよ＆交換品なので、復旧はご自分でとのこと。 ドコモショップ行く前に「Sony Bridge for Mac」というSony製のアプリでバックアップ取ってたし問題ないですと回答して、交換してもらいました。 最後に使ってないオプションとか要らないのでやめたほうが安くなりますよなどの提案もいただき満足でした。 さらに、前の機種に貼ってたフィルムもきちんと張り替えてもらえたし。時間はちょっとかかったけど。\nで、先ほど帰宅して、朝とっておいたバックアップから復旧しようとしたら。\n**「そんなバックアップありません」**みたいなメッセージが表示されて復旧出来ません。。。\nえ？なにそれ？と思い、とりあえず現時点のデータをバックアップ取ってみるかと。 バックアップ取ったあとに、再度復旧しようとしたらちゃんとリストがでてくるじゃないですか。\nなんだこれ？ということで、ファイル探しです。。。\n「Sony Bridge for Mac」バックアップファイルは次の場所に保存されるみたいです。\n/Users/ユーザ名/Library/Application Support/Sony Ericsson Bridge for Mac/Backups/製品番号みたいな文字列/日付 この最後のディレクトリが製品番号？ごとのディレクトリっぽく、２つありました。 どうせ初期化された状態だしということで、古い日付フォルダを新しい製品番号のフォルダにコピーしたら復元は可能でした。 壁紙の設定は再起動したら復活しましたが、復活してないものも。。。 復活してないのは以下のものです。\nインストールしてたアプリ ホーム画面の配置 アカウント色々（Google Playとか） ということで、スマホでインストールするのもだるくなってきたので、PCで黙々とGoogle Playのサイトからインストールしてますが、これもだるいですね。。。\n必要なアプリインストールし直したら、またSonyのアプリで復旧してみて、設定が復活するのを祈って。。。\n続き インストールしなおして、ホーム画面での配置をがんばりました。 Google Playのサイトから既存アプリをインストールするときに、ブラウザバックで戻ってたのですが、 一覧から別タブにインストールしたいアプリのページを開きまくってから、インストールボタン押すのが楽でした（半分くらい終わった所で気づいた。。。）\n一通りインストールしたあとに、ホーム画面の配置をやり直して、「Sony Bridge for Mac」もう一回復元。 twiccaやブクログなど、個別にアカウントとか設定を管理しているアプリについては復活しました。\nけど、Androidがアカウントを管理するもの（例：Facebookなど）については、残念ながら、一部のものはアカウントを再登録しないといけませんでした。\n写真や音楽についてはもともとSDカードに入れていたのもあったので、まぁ、被害は少なかったかなぁと。\nただ、iPadやiPhoneの用に簡単にバックアップ（アプリの情報、配置まで）ができて復元できると助かるなぁと思いました。（今度はホーム画面のキャプチャ撮ってから修理に出すかなぁ。。。）\n","date":1375364280,"dir":"post/2013/","id":"cd9ba1f582642d9cbe500f018afab341","lang":"ja","lastmod":1375364280,"permalink":"https://blog.johtani.info/blog/2013/08/01/replace-xperia-z/","publishdate":"2013-08-01T22:38:00+09:00","summary":"今朝起きたら、Xperia Zが故障してしまいました。 電源ボタンを押してもスリープにならないんです。しかも、スリープからの復帰もできない。。。","tags":["Xperia Z"],"title":"Xperia Zが故障したので交換したのでメモ"},{"contents":"Morphlinesについてちょっとだけ、さらに調べました。\n誤解 Solr勉強会でなんとなく私の認識を話しましたが、ちょっと誤解してたみたいです。スミマセン。\n誤解：Morphlineというプラットフォーム/ミドルウェアがありそうなイメージ まぁ、書いてあるのでちゃんと読めって話ですが、Morphlineはあくまでライブラリだということでした。 私はなんとなくManifoldCFのようなミドルウェアorプラットフォームが存在して、 そこにFlumeのSinkとかMapReduceによるIndexerが動作するのかと思ってました。\nまぁ、これが間違いでした。正解のイメージはこっちですね。\n各プラットフォーム（FlumeとかHadoopとか）に組み込んむライブラリで、 それぞれ組み込んだ先でMorphlineの設定を記述することで、パイプライン処理ができるっぽいです。\nFlumeについては、MorphlineSolrSinkというクラスでMorphlineの設定ファイルを読み込み、いろいろ処理出来ます。\nMap/ReduceだとCloudera Searchに含まれてるMapReduceIndexerToolがMorphlineの設定を読み込んでコマンド実行してくれるみたいです。 MapReduceIndexerToolはまだちゃんと読んでないのですが、MapperとしてMorphlineのコマンドが実行されるのかなぁ？という感じです。 （結構入り組んでるので、ちゃんと読まないとわからない。。。）\nということで、Morphlineというプラットフォームがあって、一元的にFlumeやMap/Reduceに対するコマンドをパイプライン化するという話でありませんでした。\n※ちなみに、上の画像ですが、愛用しているNUBoardを使って書いてます。 考えをまとめるのにすごく役立つ一品です。持ち運び可能なノート型ホワイトボードです。\n疑問点 ただ、読んでてまだ不明な点があります。まぁ、ぼちぼち調べるかなぁと。。。\nSolrのschemaはどーなってんの？ MorphlineにSolrへロードするコマンド（loadSolr）があるけど、FlumeのMorphlineSolrSinkってのもSolrに書き込みそうだけど？ Map/ReduceでSolrに書き込むもMorphlineのコマンドとの違いは？（前にソースを見たときはSOLR-1301がベースになっていて、SolrOutputFormatってクラスがEmbeddedSolrServer起動してインデクシングしてた） GoLiveってなんだろ？（MapReduceIndexerToolに入ってて、M/Rでインデックス作ったあとにSolrのクラスタに配布＋マージするやつっぽい） どんなコマンドがあるの？（Cloudera Morphlines Ref Guide） 以下は、参考資料と参考資料にあるSlideshareの資料を一部訳したものになります。\n参考資料 Using Morphlines for On-the-Fly ETL(slideshare) cloudera/cdk/cdk-morphlines(github) メモ 現在のコマンドライブラリ（スライド 18-19ページ） Solrへのインテグレートとロード フレキシブルなログファイル解析 1行、複数行、CSVファイル 正規表現ベースのパターンマッチと展開 Avro、JSON、XML、HTMLのインテグレーション Hadoop シーケンスファイルのインテグレーション SolrCellとApache Tikaパーサすべてのインテグレーション Tikaを利用したバイナリデータからMIMEタイプの自動判別 動的Javaコードのスクリプティングサポート フィールドの割り当て処理、比較処理 リストやセット書式のフィールド処理 if-then-else条件分岐 簡易ルールエンジン（tryRules） 文字列とタイムスタンプの変換 slf4jロギング Yammerメトリックとカウンター ネストされたファイルフォーマットコンテナの解凍 などなど プラグインコマンド（スライド　20ページ） 簡単に新しいI/Oや変換コマンドが追加可能 サードパーティや既存機能のインテグレード CommandインタフェースかAbstractCommandのサブクラスを実装 Javaクラスパスに新規作成したものを追加 登録処理などは必要ない 新しいプラグインコマンドとして考えられるもの（22ページ） RDBやKVSやローカルファイルなどの外部データソースをレコードにjoin DNS名前解決とか短縮URLの展開とか ソーシャル・ネットワークからリンクされたメタデータのフェッチ（？？） レコードの感情分析とアノテーション？ 31ページの図がわかりやすいかも\n以上。\n","date":1375265520,"dir":"post/2013/","id":"b875f24d3d444fdda82b6bbfb75a4c92","lang":"ja","lastmod":1375265520,"permalink":"https://blog.johtani.info/blog/2013/07/31/introduction-morphlines/","publishdate":"2013-07-31T19:12:00+09:00","summary":"Morphlinesについてちょっとだけ、さらに調べました。 誤解 Solr勉強会でなんとなく私の認識を話しましたが、ちょっと誤解してたみたいで","tags":["Cloudera Search","Morphlines","Solr"],"title":"Morphlines入門？"},{"contents":"不定期開催ですが第11回Solr勉強会を主催しました。\n今回も大入り90人くらい？の参加者の皆さんがいらっしゃいました。ありがたいことです！（20時時点で最終的に補欠17人でした。）\nとりあえず、第一報です。このあと懇親会なので。\nということで、帰りの電車でいくつか感想を（忘れちゃうから）。\n小林さんの苦労話は細かいですが、結構はまりがちな点を共有していただいたので良かったかなぁと。 Solrのexampleの設定とか、ManifoldCFとかちょっとずつ罠があったりするので、あるあるネタはありがたいと思いますｗ\nCloudera Searchについては、安定の嶋内さんの喋りに圧巻でした。検索だけの視点とは異なる観点についての 話は私には足りないしてんだったりするので参考になります。 なんか、気づいたらMorphlineやスキーマ周りを調べてブログ書くことになっちゃったけど。。。 一つ質問しそこねたのがあって、Cloudera社は基本的に公開したOSSについてのトレーニングも立ち上げているイメージです。Cloudera Searchについてもトレーニングが立ち上がるのかなぁと密かに期待をしてみたり（予算の関係上参加できるかは不明ですが。。。）\n牧野さんの話は画像系について、私は詳しくないので、また関口さんのalikeと比較とかしてもらえると面白いかなぁと。とりあえず、青いロボットがちゃんと検索できるようになるといいですねｗｗ\n秀野さんの空間検索は緯度経度以外のPOLYGONなどを利用した検索で、実は私も知らない機能でしたｗ\nなとなくは知ってたんですが、そこまでちゃんと検索できるとは！地図以外にも活用できるような気がします（想像つかないんだけど。。。）\n最後は私の発表で、簡単な資料ですみませんでした。しかも発表よりも宣伝が。。。（ブログの宣伝だったりとか。。。） 最後に宣伝した「「ビッグデータ活用を支えるOSS」特集への論文投稿のご案内」もご検討ください！\n懇親会も楽しかったです。また思いついたら開催しますー\n最後に、今回の発表者の皆様、会場提供していただいたVOYAGE GROUPの皆様ありがとうございました！\n以下はいつものメモです。\nManifoldCFのとSolrの組み合わせ（仮）株式会社 ロンウイット　大須賀さん 残念ながら、発熱のため発表は次回に持ち越しに。\n##社内ファイル及びWEBコンテンツの検索システム構築時に苦労したこと ソフトバンクBB㈱　小林さん\nManifoldCF＋Solrを使って社内ファイルの検索システム構築 約1000万ドキュメント さまざまなDCにドキュメントがある クロールジョブのハング。。。 ログをDEBUGにしたら。。。ログファイル150GB。。。 一定時間ごとにAgentをリスタートするバッチを。。。（力技） MCFエラーによるジョブの停止 CONNECTORS-590 エラーが発生して止まったジョブを起動するバッチをcronで。。。 自作リアルタイムインデクシングの問題 MCF使わないでSlaveにインデックス openSearcher=falseだとautoCommitが実行されてもSearcherを再起動しないので検索にでてこない リプリケーションのNW負荷 別DCからのレプリケーションが複数が一度に実施される→ネットワーク負荷が。。。 cronで別々にレプリすることでNW負荷を分散できてるかな。。。 Cloudera Search 入門(仮) Cloudera 株式会社　嶋内さん マサカリ画像がｗ SolrのコミッターMark Millerさんもジョインしてる ClouderaとHadoop入門とか。 いろいろあるよ、エコシステム 4つの分類。 データの取り込み データの保存 データの活用 Search 検索エンジンなら数十億人が使い方を知ってる（Clouderaのチャールズ・ゼドルースキ） Cloudera Search Hadoopのためのインタラクティブな検索\nCDHとSolrの統合\nOSS！\n利点とか。\nデータ解析にも使えるよね、検索 非構造化データの検索にもいいよね 単一プラットフォームによるコスパ Cloudera Searchの事例 バイオテクノロジー企業で画像検索とか 医療系企業でいろんなログイベントの管理とか Cloudera Searchのアーキテクチャ Flumeでストリーミングで登録 HBaseデータの登録 M/Rでバッチ登録 HueのWebインタフェース Morphlines、HBaseはLinyプロジェクトのもの\nSolr使うならCDH！！\nQA Q：デモで使われたTwitterの検索のデータ料とかは？\nA：デモ環境ですので小さい。\nQ：スキーマってどうするの？\nA：スキーマは。。。私が書こうかなぁ、ブログ。。。\nコンピュータビジョン　株式会社 Curious Vehicle　牧野さん 色々やってます コンピュータビジョンの説明（某ネコ型ロボットのいろんな画像がｗ） 画像検索の流れ 特徴情報の抽出 特徴情報のクラスタリングによるword化 Solrによる画像情報の検索 1. 特徴情報の抽出 SIFT特徴点解析 グレースケールしてからSIFT 注意！SIFTは商用ライセンスが必要です 2. 特徴情報のクラスタリングによるword化 K-meansでクラスタリング クラスタ情報をヒストグラム化してSolrへ 3. Solrによる画像情報の検索 物体認識ベンチマークセット（ケンタッキー大）を使って。 やっぱり良し悪しある。データセットに特化したチューニングしてます。 つぎのステップ 文字認識とか顔認識 つぎはドラえもんじゃねぇ、検索とかも。。。 ガウシアンによる画像ぼかしの例 QA マイク回しててメモ取れず。。。\n国土交通省のデータをSolrで検索　株式会社ネクスト　秀野さん スライドはこちら\n評価の関係で。。。 Spatial検索の話 デモの想定機能 地図上の小学校を起点に物件検索 地図上をクリックしたところを中心に検索 デモ環境 Solr4.3.0、PostGIS 2.0.3、東京都のデータ 事前知識 ジオメトリーデータ（点、線、面がある） WKB/WKT、Intersects（しらなかった。こんなのもあるのか） 環境 EC2上にPostGIS＋Solrで構築 WKT形式でDIHでインポートできるらしい。 Solr＋S3をJSでGoogleMapへ Solr 4.4新機能をちょっと紹介　@johtani 紹介というよりも宣伝。。。\n","date":1375107300,"dir":"post/2013/","id":"59d1b7206e7664e76672d3de4dc9a8ed","lang":"ja","lastmod":1375107300,"permalink":"https://blog.johtani.info/blog/2013/07/29/study-of-solr/","publishdate":"2013-07-29T23:15:00+09:00","summary":"不定期開催ですが第11回Solr勉強会を主催しました。 今回も大入り90人くらい？の参加者の皆さんがいらっしゃいました。ありがたいことです！（","tags":["Solr","Cloudera Search","ManifoldCF"],"title":"第11回Solr勉強会を主催しました。#SolrJP"},{"contents":"Hadoopとか離れちゃってるし、Hive触ったこと無いにもかかわらず参加しました！\n（たまたま近くにいるからって理由なのは内緒で）\n玉川さんの四方山話を聞くのが主目的で参加しました。（ちょっと翻訳が気になってるので）\nイベントページはこちら\n刊行記念イベントにも関わらず、想像以上の人の入りでびっくりしました。Hadoop、Hive界隈はまだまだ人気なんだなぁと。\nプレゼントじゃんけん大会もあったのですが、そうそうに負けてしまったのが悔やまれます。。。\nTeam Geek欲しかったなぁ。もちろん、懇親会まで参加しました。\n以下、いつものメモです。\nHiveの正しい使い方（Cloudera 嶋内さん） 残念ながら、マサカリは持ってなかったです。\nスライドの各所に本の章番号が書いてあるのがうれしい。 Hiveロゴが回ってたのでスライドの時に集中できなかったｗ Impalaの話も出てきた。 速いけど、色々足りない。Hiveの置き換えじゃないよと。 HiveとImpalaのおいしいとこ取り（セラン　須田さん） スライド：http://www.slideshare.net/sudabon/20130724-oreilly-org\nオンプレだとCDH便利だよと教えてもらう いくつかSlideshareにImpalaの性能評価の資料を上げてある（必要になったら検索で。。。） リリースされたその日に性能評価やってレポート書くとかすごすぎ！ 翻訳の四方山話（玉川さん） 翻訳＝写経です 締め切り駆動勉強法ｗ 4page/day 自分から電突してオライリーさんに翻訳させてくださいと。 他の方の本が読めない（チェックしちゃうのでｗ） 動機があるから読めるってのはあるだろうなぁ。 選び方：わくわくするもの、仕事に活きるもの 今年もあと2冊やる予定（Hadoop Operations、Vagrantを翻訳中） 来年の候補（Chefとか） 高可用性HDFSのご紹介（Cloudera 小林さん） スライドにどの版で書いてあったかがわかりやすく書いてある。 3段階の開発フェーズを経てる QJMのお話 Cloudera UniversityとHadoop認定試験（Cloudera 川崎さん） Clouderaデータアナリスト向けトレーニング（3日間、10月日本語で開催予定） Hive、Pig、Impalaなど Data Science入門コースも準備中 出版記念！ 8月管理者向け先着20 or 30名にHadoop第3版贈呈予定 先着20名にプログラミングHive贈呈予定 ","date":1374685860,"dir":"post/2013/","id":"1b9c5ae60ec46be64a1877f0c6920edc","lang":"ja","lastmod":1374685860,"permalink":"https://blog.johtani.info/blog/2013/07/25/hadoop-hive-publication-party/","publishdate":"2013-07-25T02:11:00+09:00","summary":"Hadoopとか離れちゃってるし、Hive触ったこと無いにもかかわらず参加しました！ （たまたま近くにいるからって理由なのは内緒で） 玉川さんの","tags":["Hadoop","Hive","Cloudera","オライリー"],"title":"『プログラミング Hive』 『Hadoop 第3版』刊行記念セミナーに参加しました！ #oreilly0724"},{"contents":"Yokozunaの気になる点というか、自分だったらこのへん調べるだろうなって観点を上げてみます。 別に調べるわけじゃないので、完全に自己満足なメモですけど。\nちなみに、分散システムとかRiakの仕組みは詳しくないので、ズレてる点がいっぱいあるかも。\nというか、分散システムでテストというか、検討する点とかってまとまってる資料とかあるのかなぁ？\nスキーマ変更時の挙動 フィールド型変更とか、フィールド追加とか 既存RiakクラスタにYokozunaの機能を追加する方法と制限 タイムラグとかも Riak＋Yokozunaクラスタに対してノード追加時に発生するオーバーヘッド（ネットワークとかディスクIOとか） 性能検証のためのシナリオ（どっちが先に悲鳴をあげるかとか） Riakメインで、Yokozunaはおまけ程度に検索するというシナリオ Yokozunaメインで使うシナリオ 更新が多い場合のシナリオ Riakのみ、Riak＋Yokozunaの各種統計情報（CPU、メモリ、ディスクサイズ、ネットワークIO） 運用系（監視とか）の手法とか機能？とか バージョンアップなどの対応方法 Solrがコケた時とかの対処 とりあえず、こんな感じかなぁ。\n","date":1373474580,"dir":"post/2013/","id":"50557b455cba1a3ce9b4555fc3fd5433","lang":"ja","lastmod":1373474580,"permalink":"https://blog.johtani.info/blog/2013/07/11/yokozuna-check-point/","publishdate":"2013-07-11T01:43:00+09:00","summary":"Yokozunaの気になる点というか、自分だったらこのへん調べるだろうなって観点を上げてみます。 別に調べるわけじゃないので、完全に自己満足な","tags":["Riak","Solr","Yokozuna"],"title":"Yokozunaの気になる点というかなんというか"},{"contents":"先日、Bashoさんにおじゃましたのもあり、Riak Meetup Tokyo #2に参加しました。\nYokozunaの話も聞けるということで。 懇親会も参加しました。Vさん＆リピさんと話し込んじゃってあんまり他の人と話せなかったけど。。。\n以下はいつものメモです。\nFreakOut 久森さん 「Riak環境をプロダクションで構築＆運用してみた（仮）」 FreakOutとRTB ディスプレイ広告の新しい配信の枠の話 この人には何出すの？いくらで？みたいな感じ 純広告：表示保証、期間保証など RTB：1回の広告表示ごとに買い付け DSP（デマンド・サイト・プラットフォーム） 広告表示は大体0.1秒で表示しないといけない。この間に色々やってる。 50ms or die.で戦ってます。 RTBはCPUバウンド 多コアを安く並べたい Tokyoなんとかとか使ってた。 スケーラビリティがキツイ（クライアント側でアルゴリズム分散してる） データ解析もしたいけど、検索ができない RTBに適したRiakがうまくハマるのではと。 構成とかとか アプリはPerlなので、PerlでRiakクライアントが必要。Memcached互換とかあると嬉しい。 ProtobufサポートもPurePerlしかなかった。 ないなら、作ろうと。githubに上がってます。このへんかな？ 監視はcloudforecastとかでやってる。 課題 Redirectがつらい（haproxy？がつらい？） Setが詰まるとつらい（ケースがまだわからない） 対策１ memcached＋Riak 対応２（案） hashからpartitionに直接取りに行くとか まとめ 素のままRiakはちょっとつらい QA 聞き取れたやつだけ\nQ：1台いくら位ですか？ A：10万から11万くらい Q：どのくらいの性能ですか？ A：同時1000くらいをさばいてる？ Q：50ms以下を出すのに、ネットワーク周りで近さとかを考えることありますか？ A：国内だと10msあればなんとかなる。それよりもアプリ側のチューニングのほうがまだ重要 Q：Cassandraとか候補に挙がらなかったんですか？ A：苦しんでる人が知人にいるので。。。あと、用途的に違うので。 Q：バックエンドとしてはなにを？ A：bitcaskにしてる Q：サーバ構成、ネットワーク構成がどうなってる？ A：。。。 Q：Redirectとは？RiakがやってるRedirect？ A：はい。 Q：他に候補にあがったのは？ A：商用のaerospike（これかな？）がスケールできそうだったけど、クライアントがいまいち。。。 感想 広告業界のことをよくわかってないので、微妙にピンときてなかったりもするのですが、以下に素早く返すかって観点でどこに注力して、問題点を潰していくのかってのは面白そうだなぁと。 リクエスト処理の性能がクリアできたらつぎはスケールの観点（ノード追加時の挙動とか）で検証していくんだろうなと。次回の話も聞いてみたい感じです。\nIIJ 曽我部さん、田中さん 「Yokozuna 日本語検索性能を評価しました」 Yokozunaって？ Riak＋Solrでいいとこ取り データの登録とかはRiakのAPIで。 SolrのAPIが使える。 YokozunaがSolrの分散検索の部分を隠してくれる。 Yokozunaのインストールとか。 SolrのAPIっぽい形で検索できるし、戻りもSolrのXMLっぽいのが出てくるよ。 Wikipediaデータってstoreの性能とか。 Riakのノード32台。（Xeon、メモリ24GB、HDD。。。） yz_extractor：Riakのコンテンツタイプを見てSolrにデータを入れる処理が書いてある。 自分でschema.xmlを書いてYokozunaに指定することもできる。 スキーマの変更とか登録とか。 すでに指定済みスキーマを変更した場合の挙動ってどうなるの？ デモではSolrからid取って、Riakからその他のデータを取り出していた。 Rubyでの性能評価 ベンチマークプログラム側の問題が先に影響が出てしまった。 QA Q：Riak単体とYokozunaつかった時でディスク容量がどのくらい増えた？ A：ちゃんと調べてないが、10%くらい増えた気がする。 Q：Solr側の設定でstored=trueだけど、falseにしてもいいんじゃないの？ A：デモはfalseにしてます。 Q：スキーマってあとから変更できるんですかね？ A：まだ良くわかってないです。 Q：ノードの追加、削除時の挙動とかも気になります。 感想 今回はStore性能に関してでしたが、今後は検索性能やシナリオによる性能（KVSの処理メインで、時々全文検索とか、全文検索の処理も結構あるパターンとか）の測定とか、耐障害性とかの観点で調査を進めてもらってSolr勉強会で話をしてもらえると面白そうだなぁと勝手に思ってみたり。 Solr勉強会へのコンタクトお待ちしてます！ｗ\n","date":1373450220,"dir":"post/2013/","id":"146e8ca40c0d37f36eecea822028dd9e","lang":"ja","lastmod":1373450220,"permalink":"https://blog.johtani.info/blog/2013/07/10/riak-meetup-tokyo-no2/","publishdate":"2013-07-10T18:57:00+09:00","summary":"先日、Bashoさんにおじゃましたのもあり、Riak Meetup Tokyo #2に参加しました。 Yokozunaの話も聞けるということで。 懇親会も参加しました。","tags":["Riak","Yokozuna","Solr"],"title":"Riak Meetup Tokyo #2に参加しました。#riakjp"},{"contents":"Solr 4.4に取り込まれる予定のチケットで、気になるものを見つけたのでいつものごとく調べてみました。\n元となるチケットはこちら。SOLR-4897。\nスキーマレス？ Solrはschema.xmlにデータの定義（フィールドタイプやフィールドなど）を記述して、データを登録する全文検索システムです。 これまでのSolrではこの設定ファイルを元にデータを登録するフィールド名を決定しており、 変更を行う場合はSolrのコアを再起動するなどの手順が必要でした。（※ダイナミックフィールドはすこし特殊）\nそれだと、Solrを管理するのがめんどくさいですね？という感じで現れたのがSchemaREST APIです。（たぶん。）\nSchema REST API Solr 4.2から導入されたSolrのスキーマに関する情報を提供するためのREST APIです。 4.2で導入されたのはあくまでもschema.xmlの情報を取得するためのAPIでした。 たとえば、Fieldの一覧を取得するとか。\n4.4から、フィールドの追加（変更、削除はできない）ができるようになりました。あくまでも、フィールドの追加で、フィールドタイプなどの追加はまだできません。（できるようになるのかもわからないですが。） フィールドの追加方法などはWikiに記載がありました。\nということで、簡単に試してみることに。\n起動方法 exampleディレクトリの下にexample-schemalessというディレクトリが新設されています。 ここに、スキーマレスモード用の設定がされているファイルが入っているので、こちらを利用します。\ncd $SOLR/example java -Dsolr.solr.home=example-schemaless/solr -jar start.jar ログにいくつかWARNが出ますが、影響の内パス設定ミスなので無視してOKです。\n最初に定義されているフィールドは「id」と「_version_」のみになります。（Schema Browserなどで確認できます。あ、REST APIでもいいですね。http://localhost:8983/solr/schema/fields）\nスキーマの更新 さて、フィールドを追加してみます。 PUTを利用すると1フィールドの追加が可能です。 「fugatext」というフィールド名でフィールドを追加しています。今のところJSONのみ対応みたいです。\n$ curl -X PUT http://localhost:8983/solr/schema/fields/fugatext -H \u0026#39;Content-Type: application/json\u0026#39; -d \u0026#39;{\u0026#34;type\u0026#34;:\u0026#34;text_ja\u0026#34;,\u0026#34;stored\u0026#34;:false,\u0026#34;multiValued\u0026#34;:true}\u0026#39; { \u0026#34;responseHeader\u0026#34;:{ \u0026#34;status\u0026#34;:0, \u0026#34;QTime\u0026#34;:18}} 追加できたかどうかもREST APIで取得してみます。\n$ curl http://localhost:8983/solr/schema/fields { \u0026#34;responseHeader\u0026#34;:{ \u0026#34;status\u0026#34;:0, \u0026#34;QTime\u0026#34;:0}, \u0026#34;fields\u0026#34;:[{ \u0026#34;name\u0026#34;:\u0026#34;_version_\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;long\u0026#34;, \u0026#34;indexed\u0026#34;:true, \u0026#34;stored\u0026#34;:true}, { \u0026#34;name\u0026#34;:\u0026#34;fugatext\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;text_ja\u0026#34;, \u0026#34;multiValued\u0026#34;:true, \u0026#34;stored\u0026#34;:false}, { \u0026#34;name\u0026#34;:\u0026#34;id\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;string\u0026#34;, \u0026#34;multiValued\u0026#34;:false, \u0026#34;indexed\u0026#34;:true, \u0026#34;required\u0026#34;:true, \u0026#34;stored\u0026#34;:true, \u0026#34;uniqueKey\u0026#34;:true}]} 追加できました。 ちなみに、同じフィールド名を追加しようとするとエラーが帰ってきます。\n$ curl -X PUT http://localhost:8983/solr/schema/fields/fugatext -H \u0026#39;Content-Type: application/json\u0026#39; -d \u0026#39;{\u0026#34;type\u0026#34;:\u0026#34;text_ja\u0026#34;,\u0026#34;stored\u0026#34;:false,\u0026#34;multiValued\u0026#34;:true}\u0026#39; { \u0026#34;responseHeader\u0026#34;:{ \u0026#34;status\u0026#34;:400, \u0026#34;QTime\u0026#34;:1}, \u0026#34;error\u0026#34;:{ \u0026#34;msg\u0026#34;:\u0026#34;Field \u0026#39;fugatext\u0026#39; already exists.\u0026#34;, \u0026#34;code\u0026#34;:400}} 設定の違い example-schemalessのsolrconfig.xmlは以下の設定が通常のexampleとは異なるようです。\nschemaFactoryの設定 schemaをAPIから変更可能にする設定です。これまでの変更しない設定の場合はClassicIndexSchemaFactoryを指定します。\n... \u0026lt;schemaFactory class=\u0026#34;ManagedIndexSchemaFactory\u0026#34;\u0026gt; \u0026lt;bool name=\u0026#34;mutable\u0026#34;\u0026gt;true\u0026lt;/bool\u0026gt; \u0026lt;str name=\u0026#34;managedSchemaResourceName\u0026#34;\u0026gt;managed-schema\u0026lt;/str\u0026gt; \u0026lt;/schemaFactory\u0026gt; ... update.chainの設定 更新処理（update関連のリクエストハンドラ「/update」とか）には次のような設定が追加されていました。（1006行目あたり）\n\u0026lt;requestHandler name=\u0026#34;/update\u0026#34; class=\u0026#34;solr.UpdateRequestHandler\u0026#34;\u0026gt; \u0026lt;!-- See below for information on defining updateRequestProcessorChains that can be used by name on each Update Request --\u0026gt; \u0026lt;lst name=\u0026#34;defaults\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;update.chain\u0026#34;\u0026gt;add-unknown-fields-to-the-schema\u0026lt;/str\u0026gt; \u0026lt;/lst\u0026gt; \u0026lt;/requestHandler\u0026gt; 「add-unknown-fields-to-the-schema」というupdate.chainが指定されています。このchainの定義自体は1669行目くらいに存在します。 （長い。。。）\n\u0026lt;!-- Add unknown fields to the schema An example field type guessing update processor that will attempt to parse string-typed field values as Booleans, Longs, Doubles, or Dates, and then add schema fields with the guessed field types. This requires that the schema is both managed and mutable, by declaring schemaFactory as ManagedIndexSchemaFactory, with mutable specified as true. See http://wiki.apache.org/solr/GuessingFieldTypes --\u0026gt; \u0026lt;updateRequestProcessorChain name=\u0026#34;add-unknown-fields-to-the-schema\u0026#34;\u0026gt; \u0026lt;processor class=\u0026#34;solr.RemoveBlankFieldUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;processor class=\u0026#34;solr.ParseBooleanFieldUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;processor class=\u0026#34;solr.ParseLongFieldUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;processor class=\u0026#34;solr.ParseDoubleFieldUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;processor class=\u0026#34;solr.ParseDateFieldUpdateProcessorFactory\u0026#34;\u0026gt; \u0026lt;arr name=\u0026#34;format\u0026#34;\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ss.SSSZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ss,SSSZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ss.SSS\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ss,SSS\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ssZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ss\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mmZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ss.SSSZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ss,SSSZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ss.SSS\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ss,SSS\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ssZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ss\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mmZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026lt;/str\u0026gt; \u0026lt;/arr\u0026gt; \u0026lt;/processor\u0026gt; \u0026lt;processor class=\u0026#34;solr.AddSchemaFieldsUpdateProcessorFactory\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;defaultFieldType\u0026#34;\u0026gt;text_general\u0026lt;/str\u0026gt; \u0026lt;lst name=\u0026#34;typeMapping\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;valueClass\u0026#34;\u0026gt;java.lang.Boolean\u0026lt;/str\u0026gt; \u0026lt;str name=\u0026#34;fieldType\u0026#34;\u0026gt;booleans\u0026lt;/str\u0026gt; \u0026lt;/lst\u0026gt; \u0026lt;lst name=\u0026#34;typeMapping\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;valueClass\u0026#34;\u0026gt;java.util.Date\u0026lt;/str\u0026gt; \u0026lt;str name=\u0026#34;fieldType\u0026#34;\u0026gt;tdates\u0026lt;/str\u0026gt; \u0026lt;/lst\u0026gt; \u0026lt;lst name=\u0026#34;typeMapping\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;valueClass\u0026#34;\u0026gt;java.lang.Long\u0026lt;/str\u0026gt; \u0026lt;str name=\u0026#34;valueClass\u0026#34;\u0026gt;java.lang.Integer\u0026lt;/str\u0026gt; \u0026lt;str name=\u0026#34;fieldType\u0026#34;\u0026gt;tlongs\u0026lt;/str\u0026gt; \u0026lt;/lst\u0026gt; \u0026lt;lst name=\u0026#34;typeMapping\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;valueClass\u0026#34;\u0026gt;java.lang.Number\u0026lt;/str\u0026gt; \u0026lt;str name=\u0026#34;fieldType\u0026#34;\u0026gt;tdoubles\u0026lt;/str\u0026gt; \u0026lt;/lst\u0026gt; \u0026lt;/processor\u0026gt; \u0026lt;processor class=\u0026#34;solr.LogUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;processor class=\u0026#34;solr.RunUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;/updateRequestProcessorChain\u0026gt; 使ってるUpdateProcessorはこんな感じみたいです。最後の2つはこれ用じゃないので省略。\nプロセッサ名説明 RemoveBlankFieldUpdateProcessorFactory値がないフィールドは除去 ParseBooleanFieldUpdateProcessorFactoryスキーマに定義されていないフィールドで、値がBooleanとしてパースできたら、Boolean型とする。 ParseLongFieldUpdateProcessorFactoryスキーマに定義されていないフィールドで、値がLongとしてパースできたら、Long型とする。 ParseDoubleFieldUpdateProcessorFactoryスキーマに定義されていないフィールドで、値がDoubleとしてパースできたら、Double型とする。 ParseDateFieldUpdateProcessorFactoryスキーマに定義されていないフィールドで、値がDateとしてパースできたら、Date型とする。（パースの形式がformatで列挙されてる） AddSchemaFieldsUpdateProcessorFactory入力されたドキュメントの中でスキーマに定義されていないフィールド（静的、動的両方）を見つけた時に、フィールドの値の型を元にフィールド型をマッピングする。 とここまで見てきたところで、スキーマレスという名前の意図がちょっとわかったかも。\n定義されてないフィールドを持ったデータを登録 起動時には定義されてないフィールドをもったデータを登録してみます。 boolean型で試してみることに。以下のデータを管理画面のデータ登録画面から登録します。（http://localhost:8983/solr/#/collection1/documents） （タイトルでbooleanってわかりにくいですが）\n{\u0026#34;id\u0026#34;:\u0026#34;change.me\u0026#34;,\u0026#34;title\u0026#34;:true, \u0026#34;price\u0026#34;:1.25, \u0026#34;fuga\u0026#34;:\u0026#34;100,200\u0026#34;} エラーは出ません。で、またフィールド一覧を取得すると。\n$ curl http://localhost:8983/solr/schema/fields { \u0026#34;responseHeader\u0026#34;:{ \u0026#34;status\u0026#34;:0, \u0026#34;QTime\u0026#34;:1}, \u0026#34;fields\u0026#34;:[{ \u0026#34;name\u0026#34;:\u0026#34;_version_\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;long\u0026#34;, \u0026#34;indexed\u0026#34;:true, \u0026#34;stored\u0026#34;:true}, { \u0026#34;name\u0026#34;:\u0026#34;fuga\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;tlongs\u0026#34;}, { \u0026#34;name\u0026#34;:\u0026#34;fugatext\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;text_ja\u0026#34;, \u0026#34;multiValued\u0026#34;:true, \u0026#34;stored\u0026#34;:false}, { \u0026#34;name\u0026#34;:\u0026#34;id\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;string\u0026#34;, \u0026#34;multiValued\u0026#34;:false, \u0026#34;indexed\u0026#34;:true, \u0026#34;required\u0026#34;:true, \u0026#34;stored\u0026#34;:true, \u0026#34;uniqueKey\u0026#34;:true}, { \u0026#34;name\u0026#34;:\u0026#34;price\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;tdoubles\u0026#34;}, { \u0026#34;name\u0026#34;:\u0026#34;title\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;booleans\u0026#34;}]} おー、最後にtitleが追加されてます。他にもfugaやpriceも。（日付は手を抜きました。。。）\n感想 詳細までは追いかけてないですが、こんなかんじです。 フィールド追加が可能になるのはいいんじゃないでしょうか。SolrCloudの機能との関連もあるのかもしれません。ZooKeeperへの出力も実装されてそうなので。\nただ、機械的に出力されたschema.xml（exampleだとmanaged-schemaというファイル）には_「DO NOT EDIT」_との記述があるので、修正するとなにかおきてしまうかもしれないですねぇ。 現時点では、フィールドタイプの変更やフィールドの更新、削除に関してはSolrCoreの再起動などの手順が必要です。 あと、変なデータ（タイプミスとか）が登録されたりしないかってのは気になりますね。\n※ちなみに、別の人が気づいたんですが、ちょっとバグが有ったみたいで、代わりにチケットつくったらキリ番（SOLR-5000） ゲットしましたｗ\n","date":1372867920,"dir":"post/2013/","id":"a98d42be181c01b8077e060b1b5080ec","lang":"ja","lastmod":1372867920,"permalink":"https://blog.johtani.info/blog/2013/07/04/schemaless-example/","publishdate":"2013-07-04T01:12:00+09:00","summary":"Solr 4.4に取り込まれる予定のチケットで、気になるものを見つけたのでいつものごとく調べてみました。 元となるチケットはこちら。SOLR-4897","tags":["Solr"],"title":"スキーマレスモード？（SOLR-4897）を調べて見ました。"},{"contents":"SolrのチケットをML経由で眺めてるんですが、便利そうなチケットが流れてきたのでブログを書いてみみようかと。 元になってるチケットはこちらです。昨日だか、今朝にtrunkとbranch_4xにコミットされたみたいです。試してみたい方は、branch_4xかtrunkをチェックアウトすると触ることができます。\nデータ登録用の画面（JSON） branch_4xをチェックアウトしてexampleを起動し、Solrにアクセスします。\n管理画面に「Dcuments」という項目が追加されてます。開くとこんなかんじです。\nなんと、デフォルトはJSONになってます。これも時代の流れでしょうかｗ\nSolrでは、これまで設定ファイルやデータ登録もXMLがメインになっていました。（Apache Solr入門もXMLを基本に書いてます。このころはまだデフォルトでは対応してなかったので）\n登録するデータをテキストエリアに記述して、「Submit Document」をクリックすればデータは登録されます。基本的には単件登録の画面でしょうか。 （登録されたデータを確認するには「Query」画面を利用すればいいです。） また、JSONのデータ形式はSolrのWikiを参照してください。\nCSVやXMLも この管理画面ではJSON以外の形式でもデータの登録が可能です。 「Document Type」の項目をクリックすると以下のように選択肢があられます。\nCSV、XMLについては、先ほどのJSONの画面の用に、テキストエリアが表示されます。 テキストエリアにCSV（データの形式はこちら）やXML（データの形式はこちら）を入力してボタンを押せば登録できます。\nSolr Command形式も（JOSNかXML） Solr Command というのはXMLやJSONで登録、コミット、削除などを実行するための画面になります。 JSONのコマンドはこちら、XMLのコマンドはこちらをご覧ください。\nあと、便利なのがファイルアップロードです。 こんなかんじで、ファイルを選んでSubmitすればデータが登録出来ます。\nファイルのサイズが大きいとちょっと時間がかかりますが、コマンドを打つより簡単かもしれません。 post.jarツールと違って、デフォルトでコミットをしてくれるわけではないので、「Extracting Req. Handler Params」に「commit=true」をつけないと、データが登録されてない？と思ってしまうかもしれませんが。\n組立もできるみたい（Document Builder） 最後に紹介するのが「Document Builder」というタイプです。\nもっと簡易にデータを記述できるようにということで用意されているようです。 フィールドの情報はSolrに接続して利用できるフィールド？（ダイナミックはないのかな？）が表示されます。\n追記していくとこんなかんじになります。\n日本語のデータもちゃんと登録できました。 ただ、まだ、開発中なんでしょうがないかもしれませんが、以下の様な制約があるようです。\nmultiValuedなフィールドに値を追加できない（上書きされる） 改行が入ったデータをテキストエリアにいれると「Add Field」を押しても反応しない ダイナミックフィールドは自分で書きましょう ただ、これまでXMLでファイルを作ってコマンドで登録したり、curlコマンドでJSON書いたりして登録していたよりはお手軽にさわれるようになるかと思います。つぎの4x系のバージョンが出たときはこちらからデータを登録してみてください。\n","date":1372318080,"dir":"post/2013/","id":"ecf3ac80454654d990d9c07d33d35d1c","lang":"ja","lastmod":1372318080,"permalink":"https://blog.johtani.info/blog/2013/06/27/upload-docs-solr-admin/","publishdate":"2013-06-27T16:28:00+09:00","summary":"SolrのチケットをML経由で眺めてるんですが、便利そうなチケットが流れてきたのでブログを書いてみみようかと。 元になってるチケットはこちらで","tags":["Solr"],"title":"Solrの管理画面でデータ登録"},{"contents":"前回は3番煎じぐらいでしたが、今回は初記事かな？（だといいな）\nKibanaには、前回の記事で書いたものとは別に開発中のKibana3というのが存在します。\nKibana3って？ Kibana2はRubyで書かれていましたが、Kibana3はHTML＋JavaScriptで構成されています。 ですので、ApacheなどのWebサーバに配置することで、利用が可能となります。 ただ、HTML＋JavaScriptのため、ブラウザ上で動作するためブラウザが動作するマシンからElasticSearch（通常だとhttp://マシン名orIPアドレス:9200/とか）にアクセスできなければいけないという制限があります。\nこの条件さえクリア出来れば、Kibana3ではKibana2よりも様々なパネルが用意されていて、色々できそうなのでお勧めです。\nインストール ElasticSearchやログについては、前回の記事の環境を利用しました。 ですので、Kibana3のインストールのみです。（ApacheもCentOSのサーバに入っていたので。）\nダウンロードして、Apacheの公開ディレクトリに置いただけです。（お試し環境のため、権限とかは大目に見てください。\n$ git clone https://github.com/elasticsearch/kibana.git kibana-javascript $ cp -R kibana-javascript /var/www/html 今回はApacheとElasticSearchが同一マシン（＝同一IPアドレスでアクセス可能）で動作している＋ElasticSearchへのアクセスのポートがデフォルト（9200）のため特に設定が必要ありませんでした。\nElasticSeachサーバとKibana3のApacheのサーバが別のサーバの場合やElasticSearchサーバのポートが異なる場合はkibana-javascript/config.jsファイルの編集が必要になります。 cloneしてすぐのconfig.jsは、以下のとおりです。\n/* elasticsearch: URL to your elasticsearch server. You almost certainly don\u0026#39;t want \u0026#39;http://localhost:9200\u0026#39; here. Even if Kibana and ES are on the same host kibana_index: The default ES index to use for storing Kibana specific object such as stored dashboards modules: Panel modules to load. In the future these will be inferred from your initial dashboard, though if you share dashboards you will probably need to list them all here If you need to configure the default dashboard, please see dashboards/default */ var config = new Settings( { // By default this will attempt to reach ES at the same host you have // elasticsearch installed on. You probably want to set it to the FQDN of your // elasticsearch host elasticsearch: \u0026#34;http://\u0026#34;+window.location.hostname+\u0026#34;:9200\u0026#34;, // elasticsearch: \u0026#39;http://localhost:9200\u0026#39;, kibana_index: \u0026#34;kibana-int\u0026#34;, modules: [\u0026#39;histogram\u0026#39;,\u0026#39;map\u0026#39;,\u0026#39;pie\u0026#39;,\u0026#39;table\u0026#39;,\u0026#39;stringquery\u0026#39;,\u0026#39;sort\u0026#39;, \u0026#39;timepicker\u0026#39;,\u0026#39;text\u0026#39;,\u0026#39;fields\u0026#39;,\u0026#39;hits\u0026#39;,\u0026#39;dashcontrol\u0026#39;, \u0026#39;column\u0026#39;,\u0026#39;derivequeries\u0026#39;,\u0026#39;trends\u0026#39;,\u0026#39;bettermap\u0026#39;], } ); ポート番号が異なる場合は、1つ目の「elasticsearch:」で指定されている「9200」を環境に合わせて編集するだけになります。 Kibana3とElasticSearchのホストが異なる場合は、1つ目の「elasticsearch:」の行をコメントアウトし、2つ目を有効にしてから環境に合わせたURLに修正して保存すればOKです。\n以上で、インストールは完了します。あとは、以下のURLにアクセスするだけです。\nhttp://hogehoge/kibana-javascript/ 画面構成 アクセスすると次のような画面が表示されます。\n初期画面 左上に赤い帯で、「 Oops! Could not match index pattern to any ElasticSearch indices」とエラーが表示されました。\nKibanaはElasticSearchに「logstatsh-年.月.日」という日付ごとのインデックスが存在することが前提となっています。 Kibanaに初めてアクセスした場合、「logstash-当日日付」で始まるインデックスを描画しようとします。 これは、私が前回利用したElasticSearchの環境に古いデータ（試したのが19日、データは10日のみ）しか入っていないために出たエラーです。\n日付は「Options」というエラーが出ている付近の「Absolute」というリンクをクリックすると、特定の日付をカレンダーで指定することができるようになります。データは6/10にしか入っていないので、6/10（12時くらいから20時くらいまで）のを指定します。\n日付指定 選択すると無事データが見えるようになりました。\nデータ描画 ダッシュボードの構成（初期） Kibana3では、この画面をダッシュボードというようです。 このダッシュボードは初期状態では、以下のパーツが表示されています。（子要素があとで説明するパネル名です）\nOptions：描画対象の日付の指定やダッシュボードの保存などを行うRow timepickerパネル：日付の指定 dashcontrolパネル：ダッシュボードの制御（保存とか） Query：ログ検索式を入れるところ stringqueryパネル Graph：ヒストグラムの描画（X軸：時間、Y軸：ログ件数） histogramパネル Events：検索にヒットしたログデータの描画領域 fieldsパネル：表示するフィールドの選択（左側。チェックを入れると右側のログ表示領域のカラムが増える） tableパネル：ログデータ（右側。左側でチェックが入ったカラムだけが表示される。） あくまで初期表示です。各パーツの設定アイコン（歯車のマーク）をクリックすると色々と設定が可能です。 また、「Events」など名称はクリック可能となっていて、クリックすると、そのパーツが折りたたまれた状態にすることも可能です。\n折りたたんだ状態 ダッシュボードの設定 ダッシュボードには独自のパネルを簡単に追加することができます。 ダッシュボードの構成はページの一番上にある「Logstash Search」の設定アイコンをクリックすると設定画面が開きます。\nダッシュボード設定 「New row」にタイトル名を適当にいれて「Create Row」するとあたらしくパネルを追加することができるRowが追加されます。「Rows」の「Move」にある矢印でRow自体の表示場所を上下に移動することも可能です。\nRowの設定 追加した「Hoge」にパネルを追加する場合はHogeの上にある設定アイコンをクリックすると設定画面が開きます。\nRowの設定 ここでKibana3で用意されているパネルの追加ができます。\nPanel追加ボタン パネルを選んでボタンを押せばすぐに表示されます。\nパネルの羅列 こんな感じです。とりあえず、ポコポコと追加してみました。\n利用できるパネルの種類は以下の様なパターンです。 適当ですが、表にしてみました。\nパネル名概要 columnRowの中にパネルを配置するコンテナを用意するためのパネル dashcontrolダッシュボードの保存、保存したダッシュボードの表示などの操作ボタン textmarkdown形式などで記述が可能な文章を表示できるパネル stringquery検索クエリ入力用パネル derivequeriesフィールドと検索式がわかれた形式の検索入力用パネル timepickerログ表示の期間を指定するパネル histogramログの件数のヒストグラム表示用パネル hitsヒット件数表示用パネル pieパイチャート表示用パネル trends指定された時間でデータの増減を%表示するパネル sortソート条件指定用のプルダウン表示用パネル（変更したらtableの内容がソートされる） tableログデータ表示用パネル fieldstableパネルに表示するフィールドを選択するための補助パネル bettermapなんか地図が出てきたパネルGeoJSONデータをゴニョゴニョ（表示かな？）できるみたい mapなんか世界地図が出てきたパネル２文字の国コード（jaとかか？）かU.S.の州コードのデータを元に地図に色をつけるのかな？ これらのパネルは個々に色々と設定が可能です。他にもdebug、map2など有りそうでしたがまだ使えないみたいです。\n適当に触ってて気づいた注意点です。\ntableは１ダッシュボードで１つだけが良さそう。 ２つあると、どちらかにしか描画されない。columnに入れるとグルーピングできたりするのかなぁ？ stringquery、timepickerも１ダッシュボードで１つが良さそう。 これもtableと似たような理由です。 ダッシュボード保存し忘れて泣きそうになる JSで実装されてて、自分で色々とカスタマイズできるのですが、保存するのを忘れて泣きそうになりましたｗ カスタマイズしたダッシュボードについては、ローカルに保存する以外にElasticSearchにも保存ができるみたいです。チームで共有することもできそうです。 derivequeriesを表示するとグラフがカラフルに derivequeriesを追加したらグラフが急にカラフルになりました。 どうもderivequeriesのFieldの部分を変更すると、そのフィールドの値を元にグラフを細分化してくれるようです。色の数の上限はderivequeriesのLength属性の数値で制御出来ます。（5だと5個まで色が出る） histogramのパネルで自分でクエリを記載することも可能です。ただ、derivequeriesのフィールド変更すると書き換わっちゃいます。。。 derivequeriesを追加したらカラフルに ヒストグラムは色々なパターンのグラフを描画できました。ラインによる描画（histo1）、総数を100%としたパーセンテージでの表示（histo2）、ライン＋点による描画（histo3）などです。\nヒストグラムのいくつかのパターン 感想 ということで、適当にですが触ってみました。 Kibana2はApacheのアクセスログとかの表示しかできない感じがしましたが、Kibana3だといろいろなデータを描画できそうだなと。 logstash形式のインデックスを用意するのが前提になってるので、時系列データをグラフ描画するのに向いてるんでしょうか。 お手軽にグラフ化できるし、自分でダッシュボードをカスタマイズできるのは素敵です。 ただ、クエリとグラフの関係などはちょっと癖があるかもしれないので、色々と試してみないといけないかもしれないです。 （たとえば、特定のフィールドの値について「A、B、その他」みたいなグラフの描画とかをどうするかとか）\n地図の描画は試してみたいかなぁ。\n","date":1371652980,"dir":"post/2013/","id":"26c47355cbe966a94826cbe2fbf2b355","lang":"ja","lastmod":1371652980,"permalink":"https://blog.johtani.info/blog/2013/06/19/introduction-kibana3/","publishdate":"2013-06-19T23:43:00+09:00","summary":"前回は3番煎じぐらいでしたが、今回は初記事かな？（だといいな） Kibanaには、前回の記事で書いたものとは別に開発中のKibana3というの","tags":["elasticsearch","kibana"],"title":"Kibana3というのもありまして"},{"contents":"ちょくちょく書こうと言いながら、前の記事が1週間以上前になってる。。。\n昨日は、Basho Japanに遊びに行って来ました。 （Riak触ったことないのに。。。Erlangも。。。ゴメンナサイ）\nRiakにSolrを組み合わせたYokozunaというものの名前を最近耳にしていたので、どんなものなのかなぁと興味がありまして。Solrがどんな使い方をされているのかってのが気になったので、 情報交換したいなぁと思っていたところ、Vの人が調整してくれたので色々と有意義な話ができたかなぁと。 （Yokozunaについての最新のスライドはBerlin Buzzword 2013のものがここに） Twitter上で見かけたことのある方々と話ができたり面白かったです。（やっぱ英語で会話できたりスラスラと読めるの必要だよなぁと痛感したりもしました。。。）\nということで、遊びに行ったのに美味しいピザやこんなおみやげまでもらってしまいました。 （ピザの写真撮るの忘れてたw）\nRiak＆Bashoグッズ ちなみに、Yokozunaですが、Riakに登録したデータを裏で起動しているSolにデータを流しこんでくれるものになります。 Solrの機能としては分散検索（Distributed Search）と呼ばれる仕組みを利用しているようです。 YokozunaのI/Fとしては、Solrのインデックスの分散構成は隠してくれていて、かつ、Solr（っぽい？）リクエストを投げれば裏の分散構成に問い合わせた結果をSolrのレスポンスの形で返してくれます。 KVSに全文検索の機能がついてくるお得感が満載な気がしますw。\nRiak自身のデータの取り扱いがどんなものかをまだちゃんと理解していないので（ゴメンナサイ。Little Riak Bookは開いてるんですが読んでなくて。。。）またおじゃましてもう少し情報交換したいかなぁとｗ。\nCloudera Searchといい、Yokozunaといい、Solrを利用したものが少しずつ増えてきて嬉しい限りです。 Solrの作りがしっかりしている？活発？、だから取り込む形が多いんですかねぇ。 Solr本を書いてから数年たちますが、やっと検索のニーズが出てきたのかもしれないなぁと思ってみたり。 （流れのつながりはあまりないですが）ElasticSearchも少しずつ人気が出てきてるし、日本語の本とかのニーズあったりするかなぁ？\n","date":1371603780,"dir":"post/2013/","id":"33919e866426ce8e7b2ce06f19bbf889","lang":"ja","lastmod":1371603780,"permalink":"https://blog.johtani.info/blog/2013/06/19/visited-basho/","publishdate":"2013-06-19T10:03:00+09:00","summary":"ちょくちょく書こうと言いながら、前の記事が1週間以上前になってる。。。 昨日は、Basho Japanに遊びに行って来ました。 （Riak触ったこ","tags":["Riak","Basho","Yokozuna","Solr"],"title":"Basho Japanに遊びに行きました"},{"contents":"Lucene/Solr 4.3.1のRCのVoteが始まっていますが、そのMLできになったコトがあり、ちょっと調べたので メモを残しておきます。\nマルチコアの設定ファイルであるsolr.xmlの記述方法と、コアの探索ロジックが4.4（実装的には4.3から入っている）から変更されるようです。4.x系の最新版である、branch_4xのexampleディレクトリにあるsolr.xmlも新しい記述に変更されていました。\n参考URL 新しいCore探索（4.4以降） 新しいsolr.xml（4.4以降） 4.3までのsolr.xml ちなみに、最後のold styleと呼ばれる4.3までの記述方法はつぎの5.0ではDeprecatedになるようです。（5.0がいつ出るのかはわからないですが。）\nCore探索ロジック 4.4から、$SOLR_HOMEディレクトリ以下の探索ロジックは次のようになるようです。 以下では、「新スタイル」（4.4以降の書式）、「旧スタイル」（4.3以下の書式）として記述します。\nsolr.xmlファイルの存在チェック solr.xmlが存在しない場合→旧スタイルとして処理→3へ（旧スタイル） solr.xmlが存在し\u0026lt;cores\u0026gt;タグが存在しない場合→2へ（新スタイル） solr.xmlが存在し\u0026lt;cores\u0026gt;タグが存在する場合→3へ（旧スタイル） 新スタイルのロジック SOLR_HOMEディレクトリに存在するディレクトリについて以下の処理を繰り返す SOLR_HOME/ディレクトリ/core.propertiesファイルが存在する→後続処理へ。存在しなければ終了 SOLR_HOME/ディレクトリ/conf/solrconfig.xmlを読み込み、コアを起動 旧スタイルのロジック これまで同様、solr.xmlの\u0026lt;core\u0026gt;タグの記載内容を元にコアを起動（instanceDir以下のconf/solrconfig.xmlを使って） solr.xmlが存在しない場合はSOLR_HOME/collection1/conf/solrconfig.xmlが存在するものとしてコアを起動 このようなロジックになります。\nちなみに、以下の場合はエラーとなりSolrは起動しますがログや管理画面にエラーである表示がされます。\n2.3でsolrconfig.xmlが見つけられなかった場合 3.1で\u0026lt;core\u0026gt;タグが存在しなかった場合（この場合、ログにはエラーが出ません） propertiesに記述できる内容やsolr.xmlの記述内容については、Wikiを見てもらうということで。。。 CoreAdminHandlerでコアを生成したりした場合に、新スタイルの設定がどのように出力されるのかといった点が気になりますが、また今度にでも。\n","date":1370945460,"dir":"post/2013/","id":"78292d953eafbdf9e57cc4bbbe6e8964","lang":"ja","lastmod":1370945460,"permalink":"https://blog.johtani.info/blog/2013/06/11/new-solr-xml/","publishdate":"2013-06-11T19:11:00+09:00","summary":"Lucene/Solr 4.3.1のRCのVoteが始まっていますが、そのMLできになったコトがあり、ちょっと調べたので メモを残しておきます。 マルチコアの設定ファ","tags":["Solr"],"title":"新しいsolr.xmlとCore探索ロジック"},{"contents":"もう何番煎じだ？ってくらい書かれてますが、コリもせず書いてみました。 Elasticsearch＋Kibanaの環境を作って、タムタムさんのログ生成ツールからApacheのダミーログを流しこんで入れてみました。\n参考URL memorycraftさんのブログ Kibana Elasticsearch fluentd apache-loggen インストールと起動 今回はCentOSへのインストールです。 基本的にはmemorycraftさんのブログの流れのままです。\nelasticserchのインストールと起動 ダウンロードして、起動するだけ。 お試しということで、-fオプションにてコンソールにログ出力。\ncurl -OL https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-0.90.1.tar.gz tar zxvf elasticsearch-0.90.1.tar.gz cd elasticsearch-0.90.1 ./bin/elasticsearch -f Kibanaのインストールと起動 git cloneしてbundleインストール\ngit clone --branch=kibana-ruby https://github.com/rashidkpc/Kibana.git cd Kibana bundle install ruby kibana.rb これで、Kibana＋ESのインストール＋起動が完了。 下地が完了。\ntd-agentのインストールと起動 ログの流し込みはlogstashなのですが、fluentdのelasticsearchプラグインにて流しこむこともできます。 td.repoとしてtd-agentのリポジトリを登録してから以下を実行します。\nyum install td-agent -y /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-elasticsearch vim　/etc/td-agent/td-agent.conf /etc/init.d/td-agent start これで、td-agentがインストール出来ました。 次は設定です。\n\u0026lt;source\u0026gt; type tail format apache path /var/log/httpd/dummy_access_log tag dummy.apache.access \u0026lt;/source\u0026gt; \u0026lt;match *.apache.*\u0026gt; index_name adminpack type_name apache type elasticsearch include_tag_key true tag_key @log_name host localhost port 9200 logstash_format true flush_interval 10s \u0026lt;/match\u0026gt; 以上が設定です。td-agentはtd-agentというユーザで起動されるので、/var/log/httpdディレクトリにアクセスできるかだけ確認が必要です。\nいくつかの設定値について気になったので調べました。\nindex_name：adminpackとなってるが、elasticsearchではlogstash-xxxとなってる。 これは、logstash_formatがtrueの場合は、利用されないので、指定しなくてもいい。 type_name：Elasticsearchのタイプ名 *　これはlogstash_formatを指定しても有効。ただし、Kibana側で画面からのtype指定は不可能。KibanaConfig.rbにて指定することは可能。 logstash_format：Kibana用にlogstashフォーマットで出力するオプション この指定があるときは、index名が「logstash-YYYY.mm.dd」となる record（ログ）に@timestampとして時刻が追加される。 tag_key：include_tag_keyがtrueと指定されているため、record（ログ）にtag_keyで指定した文字列をキー、値としてtagの値（上記例だとdummy.apache.access）が付与されて登録される。 apache-loggenのインストールと起動 タムタムさんが作成されたApacheのログのダミーを生成するツールです。\ngem化されてるので、インストールは非常に簡単です。\ngem install apache-loggen で、ログを出力します。出力先は先程設定したdummy_access_logです。\napache-loggen --rate=10 --progress /var/log/httpd/dummy_access_log 秒間10アクセスログを出力してくれます。 これで、Kibanaでログが見れるようになりました。 なんて簡単なんでしょう。。。 簡単なログの検索ができてしまいました。 他の形式のログがどうなるのかとかは、また時間があれば。。。\n感想とか 非常に簡単でした。素敵です。いくつかこうなるのかな？というのを試してみたのでメモを。\nいくつか疑問点です。\n溜まったログの削除は手動？ おそらく。日付ごとにindexが出来上がっているので、削除は楽そう。「logstash-年月日」なので。 認証とかかけれるの？ ログ検索は内部でするだろうから、まぁ、なくていいのかな。ログインすらないし。 複数行のログとかってどーすんだろう？（JavaのExceptionとかが混ざるやつ） 本格的に触るようになれば調べるかなぁ。。。\nあと、ログが増えてきた時にどういった分割構成ができるだろう？って思って考えてみたのが以下になります。\n構成パターン ログを複数扱う場合は次のようなパターンがありそうかと。\nタグ（fluentdのタグ）で識別 「@log_name」という名前＝fluentdのタグにてログを識別することで、異なるログを検索することができそうです。 タグであれば、プラグインによってはログ出力時に制御も可能だと思うので、td-agentの設定を変更したりすることもなく対応が可能かと。 ただ、ログの種別ごとにKibanaのプロセスを別にして起動したいといった用途には向いてなさそうです。\ntype_nameによる識別 ElasticSearchの機能であるtypeを利用したログの識別パターンです。\nfluent-plugin-elasticsearchの設定でtype_nameを指定しました。 ここを別の名前にすることで、識別することも可能です。\nただし、この場合はKibanaの画面から指定して検索することができません。 →コメント頂きました。検索条件に「_type:タイプ名」と検索することでtypeを利用した検索が可能です。\nタグ（@log_name）でも識別できるようにするなどの工夫が必要です。 その代わり、タグ識別ではできなかったKibanaのプロセスを別にして起動することは可能になります。\nKibanaConfig.rbのTypeに値を設定することで、起動したKibanaが対象とするログを絞り込むことが可能です。 こうすることで例えば、apache用のKibanaとtomcat用のKibanaは別プロセスにして、ElasticSearchのクラスタは1つという構成も可能になります。\nElasticSearchサーバを別立て ElasticSearchサーバをそもそも別のプロセスor別のサーバで起動し、Kibanaも別々にすればログの識別も可能です。 可能ですが、色々と管理するものが増えてめんどくさそうですね。。。\nインデックス名変更 最後は、fluent-plugin-elasticsearchの設定で「logstash_format」をfalseにすれば、好きなindex_nameを付与できるので、 ログ種別ごとに名前を変更することで識別できます。\nただ、logstash形式でないインデックス名の場合、日付ローテーションができなかったり、Kibana内部で検索時に日付で検索対象を絞り込んで検索することで高速化するといった処理など、使えない機能が多々出てきてしまうのであまりおすすめじゃないかと。。。\nということで、流行りものは触っておこうということで、さわってブログ書いてみました。\n開発中に立てておいて、各サーバのログを流しこんでおくなどにも利用できるかもしれないです。 アラート通知などの機能が出てくるともっと便利かもしれないです。\n","date":1370874840,"dir":"post/2013/","id":"c4d3a917f623f58646ce93015d79e8e0","lang":"ja","lastmod":1370874840,"permalink":"https://blog.johtani.info/blog/2013/06/10/fluent-es-kibana/","publishdate":"2013-06-10T23:34:00+09:00","summary":"もう何番煎じだ？ってくらい書かれてますが、コリもせず書いてみました。 Elasticsearch＋Kibanaの環境を作って、タムタムさんのロ","tags":["kibana","elasticsearch","fluentd"],"title":"apache-loggen + fluentd + elasticsearch + kibana = ログ検索デモ"},{"contents":"昨日に引き続き、AWS Summit Tokyo 2013に行ってきました。\n@ryu_kobayashiさんからパシリを仰せつかるなどあり、忙しかったのですが楽しかったです。\n今日もすごい人出で、昼時の展示ブースは人だかりで、TDの方たち忙しそうでした。 後半はちょっとつかれたなぁ。 1日目よりも空調の温度が上がってたので快適でした。 飲物忘れたので、ちょっと喉がやられ気味でしたが。\nAWSはやっぱり勢いがあるんだなぁってのを実感しました。JAWS-UGまで残った感想です。 あとは、セルフハンズオンに参加するんだったかなぁというのもちょっとあります。あんまり触ったことないんで。\n以下はいつものメモです。\nAmazon Redshiftが切り開くクラウド・データウェアハウス 自己紹介と流れとニュース 6/5からTokyoリージョンでも利用可能に！ Redshiftどんなもの？ Redshift＝クラウド型データウェアハウス オンプレの課題 初期投資、運用管理、費用対効果 EMRと同じで、分析処理向けのサービス 簡単な利用例 各種データストア→S3→Redshift 各種データストア→EMR→Redshift Data Pipelineでデータの流れの処理がかける。 データロードはパラレルに実行可能 バックアップは管理コンソールからボタンででも可能。 クラスタのリサイズも管理コンソールからできるよ。 NRIでの評価 2012年末の限定公開してすぐに先行評価に参加\nRedshiftの性能は？\n500億件からの検索処理（1週間分のデータを抜き出して処理するSQL） 8XLノード2ノードで43秒、4ノードで27.8秒、8ノードで19秒 データロドも線形に性能が上がる 1.2億件の検索処理は4ノードより8ノードのほうが性能劣化 EMRとRedshiftの比較。1.5TB、500億件でのJOIN＋集計処理でRedshiftのほうが早かった。 Redshiftのチューニングポイント\nインデックスが存在得ず、Distribution Keyでノードに分散 Sort Keyも重要。データロード時間はSort Keyをつけると遅くなる ニガテなデータ形式もあるよ。EMRとかの組み合わせにすると安く済むこともあるよ\n簡単につくれるので、気をつけましょう。セキュリティとか。統制されないものが乱立してくるんで。\nそこでNRIですよ！（宣伝） 出てきた性能に関するものだけど、「ケース１」「ケース２」とかってなってるので、その部分の詳細が書かれたレポートが公開されないとどんなのがニガテなのかとかわからなかった。\n事例紹介とか オンプレのデータをどうやってRedshiftに持ってくの？ インフォテリアのASTERIA WARP GUIツールでデータの変換とかして、S3に持って行って、Redshiftと連携できるよと。 無料セミナーの紹介 6/21、8/2にRedshiftの無料セミナーやりますよ。 インターネット上のユーザーの行動の可視化を実現したAWSによるビックデータ解析基盤 C-Finderのサービス紹介 元オプトの方。C-Finderの紹介。 10万ユーザの行動履歴の可視化。\nサイトに来たけど、行動せずに他サイトに移動したとか、サイトに来る前の状態ってのがわからない。これをC-Finderで可視化。\n例１：自動車業界 ライバル企業の動向を自社と比較したい。 Audi、BMW、ベンツで可視化。 例２：化粧品業界 Web上での化粧品のトレンドが見たい。 @cosmeサイトのPVとかから。 ユーザって会員登録とかしてる人を追っかけてるってことなのかなぁ？ よくわかってない。。。\nレポーティングサービスしてたけど、納品まで１ヶ月かかってた。 リアルタイムにみたいという要望が多かったのでASPをTISと開発 ASPサービスの開発したよ AWSで。 可視化というタイトルだったんだけど、期待してた可視化の話ではなかった。。。\nネット選挙クラウド　～オバマ大統領選挙の事例：データ解析からネット募金まで～ ボランティアで構成ってすごいな。 本番まで１年 みんな髭の人だｗ GoogleとかFacebookとかの人がボランティアで開発に参加。 予算は抑えながら、スケールアップダウンがすぐ出来てとか。 秒間10万回のI/OのDB SQSとEC2のSoftware queueの比較。Softwareキュー選ぶと、さらにドレがいいのかってのを選ばないとい。 AWSにあるサービスなら、造らなくてもいいのではとか。 CloudSearchはつかわなかったのかなぁ？ tsunami S3に静的ページをおいて、最後のとりでにしたり。 コードとか、ノウハウってどこまで公開されてるんだろ？ 同時通訳もあったんですが、英語を聞いてみようと聞いてましたが、まだまだダメですねぇ。\nパネルディスカッション「ウェブテクノロジーをエンタープライズで活かすには？」 趣旨 B2B、B2C間でのトレンドのやり取りが加速されてるよねと。 ICTはもはやコモディティ？ TD太田さん Consumerization Of IT 色々なものがSaaSになってきてる TD：Consumerization of Data Infrastructure オンプレ＜AWS＜TD 三井物産黒田さん 三井クラウド（プライベート＆パブリック） ユビキタス これまで使ってきたものがクラウドで動くのかとかが観点 電通平川さん マーケティングダッシュボードはsalesforceでは厳しかった？ ビジネスに注力したいので、柔軟で、質実剛健なICT基盤がほしい。 ディスカッション 新しい技術に対するスタンスは？\nいかにダメな部分を潰していくか（太田さん） R\u0026amp;Dを予算化して評価して取り組んでいく。評価でダメならつぎ。（黒田さん） 消費者の方たちがネットですごい勢いで活動してる。その人達へのアプローチが重要。（平川さん） コンシューマ系技術の懸念事項は？\nセキュリティ面。レベルがある。自分の所だけじゃなく、クラウドベンダーと二人三脚が必要。丸投げはNG（黒田さん） セキュリティ面の攻撃を受けたつぎの手をどう打つかが重要。堅牢性上げると、ユーザビリティが下がる。（平川さん） 法規制的に出せないとかもある。持ちきれないデータもあるよね。（太田さん） 何を見分けてどうやって取り組むか？\nとりあえず、やってみる。そこで見える課題に対応していく。見極めるのは難しい（平川さん） ということは、すぐに出来る環境ってのは当たり前になってますよね。\n尖った技術＝セキュリティ面が弱い？みたいな印象があるのかなぁ？\nJAWS-UG AWSアップデート AmazonのCTO登場 Game Day Game Day。土曜日にやるよ。 障害を発生させて、それを復旧させる。 最もひどい壊し方をしたらかちｗ 最後はかるくボッチでした。。。 AWSあんまり使ってないからなぁ。。。\n","date":1370527200,"dir":"post/2013/","id":"d12c1c2a68be4c7fda5a7737d5493b4d","lang":"ja","lastmod":1370527200,"permalink":"https://blog.johtani.info/blog/2013/06/06/aws-summit-tokyo-day2/","publishdate":"2013-06-06T23:00:00+09:00","summary":"昨日に引き続き、AWS Summit Tokyo 2013に行ってきました。 @ryu_kobayashiさんからパシリを仰せつかるなどあり、忙しかったのですが楽しか","tags":["AWS","勉強会"],"title":"AWS Summit Tokyo 2013に行って来ました。(Day2) #awssummit"},{"contents":"ざっとインストールガイドとかCloudera Searchのソース眺めて、テキトーにメモを書いてみました。 （ユーザガイドはまだ読んでないです。）\nざっくりメモ ストリーム処理でインデックス作るときはFlume経由でSolrに SinkとEventの両方が用意されてる？（Flumeを良く知らないので、違いがわからない） FluemeからはリモートのSolrに対してインデックス登録するクラスがある。SolrServerDocumentLoaderがソレだと思う。 バッチ処理でインデックス作るときはMapReduceIndexerToolsってのを使ってSolrに SOLR-1301がベースになっている。色々と改良されてるようだけど、コアとなってる処理はSOLR-1301。 GoLiveってクラスの処理の中で、現在動作してるSolrに配布したバッチで作成されたIndexをマージする処理が書いてある。 HDFSへ出力されたインデックスはリモートのSolrからアクセスするとオーバヘッドとかどーなるのかなぁ？ 検索処理自体はHueでもできるけど、基本的にSolrCloud任せ インデキシングの処理のフローについてはCloudera Mrophlinesで定義 ということで、 2つの流れがありそう。\nHDFS→Flume→Solr HDFS→MapReduce→Solr で、まだ、わかってないですが、構成要素として\nHadoop（HDFS）：データソース Hadoop（MapReduce）：データ変換処理、バッチインデキシング Zookeeper：SolrCloudのクラスタ管理 Solr：インデキシング、検索エンジン Flume：データをストリーミングでSolrへ Coudera Morphlines：HDFSからSolrまでのETLデータ処理を定義実行する環境 って感じでしょうか。 SolrCloudのクラスタとHadoopのクラスタが同一マシン上なのか、別なのかとか。組み合わせがどんなものができるのかがまだわかってないです。 ユーザガイド読んでみたらなにか出てくるかなぁ。\nちなみに、Cloudera SearchのgithubリポジトリにあるソースはCloudera Morphlinesのコードがメインで、SolrのHDFS対応版のソースがあるわけでは無かったです。\nSolrのHdfsDirectoryってのがClouderaのリポジトリにあるSolrには追加されていて、これが、HDFSのインデックスを読み込んだりする処理が出来る仕組みっぽい。 一応、SolrCloud以外（分散検索）も考慮された形になってるっぽい。 ってとこでしょうか。\n感想 読んでて思ったんですが、Cloudera Searchの肝はじつは、検索じゃなくて、Morphlinesにあるんじゃないかなぁと。今はSolrが出力先ですが、 その他のデータ変換処理とかが増えてくると、処理の流れがMorphlinesで定義できてデータ変換処理が簡便になりそうな気が。\nその他に気になる観点 CDH経由でSolrCloudのクラスタの管理するのかな？ SolrCloud用のクラスタとCDHのクラスタって同一マシンに載るの？別マシンにもできるの？ 併存したらIOがキツそうだけど Hueで検索アプリとか組めるの？（そもそもHueがわかってないんだけど。。。） ま、とりあえず、こんなとこで。 つぎは余力があれば、ユーザガイドかなぁ。 英語力。。。\n","date":1370489160,"dir":"post/2013/","id":"f45069216cd934b80ce882c9a2f2a08a","lang":"ja","lastmod":1370489160,"permalink":"https://blog.johtani.info/blog/2013/06/06/cloudera-search-memo2/","publishdate":"2013-06-06T12:26:00+09:00","summary":"ざっとインストールガイドとかCloudera Searchのソース眺めて、テキトーにメモを書いてみました。 （ユーザガイドはまだ読んでないです。","tags":["Cloudera Search","Hadoop","Solr"],"title":"Cloudera Searchメモ（妄想版）"},{"contents":"AWS Summit Tokyo 2013に行って来ました。\n@cocoatomoさんに行き掛けに出会ったので、アンデルセンの講演を一緒に聞いてました。 TDブースの@ryu_kobayashiさんに挨拶に伺ったりも。\nすごい人で、セッション間の入れ替え時には会場前のスペースが大変なことになってました。もう少し余裕のある建物のほうが良かったのかもしれないですねぇ。\nいつものように以下はメモです。\nRoad to AWS アンデルセンサービス とてもおいしいランチボックスでした。\n広島（ここ重要！）に本社のあるパン屋さん。\n2003年に汎用機からOpenシステムに 内製ではなく外注に。複数のSIerにお願いしてるとデータセンタに マスタ管理と生産管理はオンプレ 2004年に稼動時のネットワーク整備。店舗はISDNで、設定ミスとかを防ぐためにIIJのSMFサービスに PCはレンタル契約にしたので入れ替えを強制できる→レガシーシステムの対応が必要なくなる ネットワーク広帯域化→基本システムにデータセンターに。 2009年にリース満了などで、OSの変更とかミドルの変更という移行SI費用だけで結構な値段が。ものによっては会社もない。 データセンターの月額手数料にして、機器変更などの費用を平準化。仮想化など。 けど、サイジングにどうしても安全係数をかけてしまうことに。結構値段がかかる そこで、今後の方向性 SIerどっぷりのOLTP受発注基幹システムはSIerのホスティングで それ以外のシステムは外に出したい バッチの計算を早くすることができるとノーチラスさんから提案された バッチを外部化するか、性能あげるか。IOネックなどもありスペック上げるとコストになるから、外部化したい Hadoopを組むけど、オンプレじゃなくてAWSにした。ノウハウがないので、ノーチラスさんにお任せした。 AWSのEMRを利用。4時間かかっていたものが40分で。 EDIのサーバを6ヶ月でAWSに移行 S3絡みで2度の問題が。性能劣化があった。 パッケージ開発環境がAWSにあるなら、AWSでも動くでしょ？（NTTイントラマートとか） SIerどっぷりの部分もAWSに持っていく？ アンデルセンサービスの部長さんからのAWSへの要望 メールサーバなどの基本サビスとか、コントロールパネルを充実して欲しい。 クラウド技術を活用したリアルタイム広告\u0026quot;Logicad\u0026quot;の入札・配信・ログ解析 Web広告の歴史 最初は広告主がWebサイト単位で契約 アドネットワークによる仲介 聞きそびれた。。。DSP？ アドネッエクスチェンジ SSP(Supply Side Platform) リアルタイムビッティング（RTB） RTPの仕組みを説明。 AWSとオンプレでシステムを構築してる。\nSSP事業者との取引はオンプレ 配信はAWS オンプレとAWSはAWS Direct Conectで接続 S3とHadoopの接続が安くなったり速くなったりするらしい。 オンプレミス側 Bidリクエスト：秒間数万件。。。 KVSのユーザ数は３億件。。。 AEROSPIKEというSSD向けのKVSを利用してる AWS側 ログはS3に。溜まったデータは定期的にEMRで解析。DynamoDBに入れてレポート作成 RabbitMQを使ってる。 ELBで外部からのリクエストはバランシング データセンタ間通信 遅延を複数コネクションを貼る方法で回避？ 非同期で、複数のMsgとAckをやり取りする。RabbitMQがこれに相当する機能を持ってる QueueとConsumerで多重送信が可能。 配信結果をオンプレ側に送るのにRabbitMQを使ってるのかな？ ハイブリッド構成を支えるAWSテクノロジー 聞くつもりだったんだけど、すごい人だったので、諦めて充電してた。\nAWSクラウドで構築する、ワールドクラスの分散クラウドアーキテクチャ エマージングソリューション部の部長のshot6さん。\nマルチAZ（アベイラビリティゾーン）モデル AWS固有のコンセプト。 ELBやDynamoDBやRDS、S3とか。\nマルチリージョンとは違うよと。マルチリージョンは結構難しいので。 マルチリージョンがどんなに大変かをこれから説明。\nマルチリージョンアーキテクチャ（これは別物） 複数のリージョンを利用して作る。 AWSのビルディングブロックではカバーしない範囲をカバーしないとダメとか。 リージョン間の通信は基本的に非同期 ディザスタリカバリ コストバランス見てから決めるよね。 CAP定理とかもいろいろと出てくるよね。 合意プロトコル。正確性、生存性（時間が制限されても大丈夫）、理論的にパフォーマンス出る？ 非同期レプリケーションになる（1トランザクション当たりのオーバヘッドが大きいから）けど、復旧の難しさがある。 GlusterFSとかでやってるとこもある。 NetflixはCassandraをクオラム＋Geo-Replicationでマルチリージョンを構成してる。 マルチリージョンでのデータ一貫性は維持がむずい 注意点 必要になるまで分散させない。 まずは、マルチAZを考えましょう 物理制限を考慮する 同期型だとタイムラグあるし。 複合障害の伝搬をどう抑えるか。 NetflixはHYSTRIXというのがいて遮断できるようにしている 自動化が重要。ロールバックとかロールアウトとか。 テストをどーするの？ 本番環境でアクティブ/アクティブ構成でのテスト。 ちゃんとフェイルオーバするかなどを実環境でやってる。DB落としたり。。。 障害は避けられないので、受け入れて日常に取り込むべきだよねと。\nAmazon.comではGameDay NetflixはChaos Monkey（OSS） Obama for America リカバリーオリエンテッドコンピューティングパターン\nボーアバグ：再現可能なソフトウェバグ ハイゼンバグ：通常ではありえないパターンで発生するバグで、調査が大変 ということで、マルチAZがいいよ 同期式レプリケーションを前提にできる。 アプリ開発者がアプリにフォーカスできる。分散系の難しいところはAWSが隠蔽してくれるから。 ","date":1370424600,"dir":"post/2013/","id":"1fe14e2e02b6e65e6e6e2ae3d8ddcc9f","lang":"ja","lastmod":1370424600,"permalink":"https://blog.johtani.info/blog/2013/06/05/aws-summit-tokyo-day1/","publishdate":"2013-06-05T18:30:00+09:00","summary":"AWS Summit Tokyo 2013に行って来ました。 @cocoatomoさんに行き掛けに出会ったので、アンデルセンの講演を一緒に聞いてました。 TDブースの@ry","tags":["勉強会","AWS"],"title":"AWS Summit Tokyo 2013に行って来ました。(Day1) #awssummit"},{"contents":"Cloudera Searchは次のようなモジュールから構成されています。 これはCloudera Searchのモジュールで、さらにこれらがSolrとかを使ってるみたいですね。pom.xmlを見たら何を使ってるかがわかるかな。\ncdk-morphlines search-contrib search-core search-flume search-mr search-solrcell てきとーに、README.mdみながらメモを残してみました。ソースとかはまだ読んでないです。 ざっと眺めたけど、インデキシング処理の話がメインで、検索側がどうやって動くかってのがわからなかったなぁ。 ユーザガイド（注：PDF）ってのがあるから、これを読んでみるか。。。\n各モジュールについては、以下。\ncdk-morphlines（Cloudera Morphlines） Cloudera Morphlinesという名前みたい。 検インデキシングアプリの構築、変更をラクにするためのフレームワーク。 ETLの処理チェインを簡単にCloudera Searchにデータを入れる設定（Extract/Transform/Load処理）がかけると。 バッチ処理、Near Real Timeのために使えるみたい。検索結果をさらに入れるとかもできるんかなぁ。？\nUnixパイプラインのの進化版みたいなもので、一般的なレコードに対するStream処理から、Flueme、MapReduce、Pig、Hie、SqoopのようなHadoopコンポーネントも使えるみたい。\nHadoop ETLアプリケーションのプロトタイピングにも使えて、リアルタイムで複雑なStreamやイベント処理やログファイル解析とかに使えるの？\n設定ファイルのフォーマットはHOCONフォーマット。AkkaやPlayで使われてる。\ncdk-morphlines-core Cloudera Morphlinesのコンパイラ、実行環境、コマンドのライブラリを含んでる。 ログファイル解析やsingle-lineレコード、multi-lineレコード、CSVファイル、正規表現パターンマッチ、フィールドごとの比較とか条件分岐とか、文字列変換とか色々なコマンドを含んでる。\ncdk-morphlines-avro Avroファイルやオブジェクトの抽出、変換、読み込み処理コマンド\ncdk-morphlines-tika バイナリデータからMIMEタイプを検出して、解凍するコマンド。Tikaに依存\n雑感 Cloudera Searchへのデータの流し込みを設定ファイルに記述して実行するとデータの変換処理とかが記述できるって感じかな？ Morphlinesのコマンドとして独自処理や使えそうな処理を作ることで、いろんな処理ができるって感じかなぁ。\nsearch-core Solrに対するMorphlineコマンドの上位モジュール\nsearch-solrcell Tikaパーサを使ったSolrCellを使うためのMorphlineコマンド。 HTML、XML、PDF、Wordなど、Tikaがサポートしてるものがサポート対象。\nsearch-flume Flueme Morphline Solr Sink。 Apache Flumeのイベントから検索ドキュメントを抽出、変換し、SolrにNearRealTimeで読み込むためのコマンド\nsearch-mr HDFSに保存されたファイルに含まれる大量データをMapReduceで処理してHDFS上の検索インデックスに焼きこむモジュール。\nMapReduceIndexerToolは入力ファイルの集合からSolrのインデックスシャードの集合を作るためのmorphlineのタスクで、MapReduceのバッチジョブドライバー。 HDFSにインデックスを書き込む。 動作してるSolrサーバに対して出力されたデータをマージするのもサポートしてる。\nとりあえず、Near Real Time検索するにはFlueme使って、バッチ処理でインデックス焼くのはMapReduceIndexerToolみたいだなぁ。\n","date":1370412720,"dir":"post/2013/","id":"e30258aeb8475d4c27f7935945671856","lang":"ja","lastmod":1370412720,"permalink":"https://blog.johtani.info/blog/2013/06/05/cloudera-search-modules/","publishdate":"2013-06-05T15:12:00+09:00","summary":"Cloudera Searchは次のようなモジュールから構成されています。 これはCloudera Searchのモジュールで、さらにこれらがSolrとかを使っ","tags":["Cloudera","Hadoop","Solr","Cloudera Search"],"title":"Cloudera Searchのモジュールたち"},{"contents":"AWS Summitに来ていたのですが、TLでは、Cloudera Searchが賑わってました。 ということで、軽くどんなものか読んだり調べたりしたメモを残しとこうかと。 英語力はあやしいので、おかしいとこがあったらツッコミを。\nCloudera Searchとは？ CDH4.3に対応したCDHユーザ向けの検索システム（beta版）なのかな？ CDHに統合された検索フレームワークなのかな？\n基本はLucene/Solr 4.3でHadoopのペタバイトデータを検索することができるようになるみたいです。\nどんな仕組み？ 次のものを利用しているようです。（GithubのREADMEから。）\n使ってるもの Apache Solr(4.3.0＋α？) Apache Lucene（Solrつかってるからね） Apache SolrCloud（うーん、Solrに含まれるのに別に出してるのなんで？） Apache Flume Apache Hadoop MapReduce \u0026amp; HDFS Apache Tika SolrCellとしてSolrにも組み込まれてる、いろんな文書（WordとかHTMLなどなど）からメタデータと本文データとかを取り出せるライブラリラッパー。実際にはさらにpdfboxとかを使って各文書からのデータを取り出してる。 何ができるの？ HBaseやHDFSの用にZookeeperを使ってインデックスのシャーディングや高可用性ができる。（SolrCloudがZookeeperを使ってるからね。） MapReduceのジョブの出力から自動的にSolrのインデックスにデータをマージできるらしい。 Cloudera Managerを使って、デプロイ、設定モニタリングなどが可能。\nFlumeのフィードをつかって、ストリーミングしてインデックスを作れる。FluemeがデータをSolrに流しこむのかな？ 将来的にはHiveやHBaseのテーブルをインデックスすることも可能になるらしい。Impalaクエリの結果もフィードできるのか？\nApache Blurってキーワードも出てきた。HDFSのデータからLuceneのインデックス作るのかな？ NGDataのチームがSolr/HBaseの統合とかしてるみたい。\n参考URL Cloudera社のブログ Cloudera SearchのFAQ（注：PDF） Githubのリポジトリ ","date":1370412300,"dir":"post/2013/","id":"cd90bce912f5743226af94c1efaaa4a7","lang":"ja","lastmod":1370412300,"permalink":"https://blog.johtani.info/blog/2013/06/05/what-is-cloudera-search/","publishdate":"2013-06-05T15:05:00+09:00","summary":"AWS Summitに来ていたのですが、TLでは、Cloudera Searchが賑わってました。 ということで、軽くどんなものか読んだり調べたりした","tags":["Cloudera","Hadoop","Solr","Cloudera Search"],"title":"Cloudera Searchってのが出たらしい（とりあえず、雑感？）"},{"contents":"憧れ？のfluentを使ってみました。 こちらの記事で紹介したZoomdataを最近触っているのですが、お試しにfluentdでデータ流し込むプラグインを作ってみようかなぁと。（今は、Javaでの接続も書いていて、主にそっちを使っています。） ということで、作ってみました。fluent-plugin-zoomdata。\n基本的にはtagomoris先生のfluent-plugin-growthforecastを参考（パクリ？）にさせてもらいました。 作っている最中もここわからんってツイートに反応していただき、大変助かりました。 私はベースがJavaの人間なので、手探り状態でRubyを書いています。そこおかしいんじゃないの？とかあればコメントもらえると嬉しいです。\nZoomdataのAPI ZoomdataのAPIはこんなかんじで、JSONをHTTPSでPOSTするものになります。\n指定する必要があるものは、以下の項目です。\nsource：Zoomdataのデータ保存先（Zoomdataでのデータを保存する単位。） user：Zoomdataのユーザ名 password：Zoomdataのユーザのパスワード JSONデータ：Zoomdataでグラフ化するデータ sourceはデータ保存先の名称で、この単位でZoomdataはデータを保存、描画します。fluentdのタグをこれにするとわかりやすいかなぁ？と考えていったん、実装してみています。\nで、作成したプログラムを使いつつ、Zoomdataの検証をしたかったので、つぎのような簡単なプログラムを作って動かしてみました。\nサンプルプログラムの構成 基本的にJavaの人なので、クライアントはJavaで書いてます。 CLIプログラムで適当なJSONを作って、fluent-loggerを使って、fluentdに投げ込みます。\nfluentdにfluent-plugin-zoomdataを設定して、localのZoomdataサーバに対してHTTPSでJSONをPostする仕組みです。(初keynote)\n利用しているライブラリなどのバージョンは次の通り\ntd-agent.x86_64：1.1.12-0 fluent-logger：0.2.8 Zoomdata：1.0.3 バグ？ で、Zoomdataにいろんなデータを流し込んでみたのですが、つぎのようなエラーが出て、エラーが出力されたあとはZoomdataにデータが流れ込まなくなってしまいました。\n2013-06-03 14:42:33 +0900 [warn]: emit transaction failed error=\u0026#34;SSL_connect returned=1 errno=0 state=SSLv3 read finished A: sslv3 alert handshake failure\u0026#34; 2013-06-03 14:42:33 +0900 [warn]: /usr/lib64/fluent/ruby/lib/ruby/1.9.1/net/http.rb:799:in `connect\u0026#39; 2013-06-03 14:42:33 +0900 [warn]: /usr/lib64/fluent/ruby/lib/ruby/1.9.1/net/http.rb:799:in `block in connect\u0026#39; 2013-06-03 14:42:33 +0900 [warn]: /usr/lib64/fluent/ruby/lib/ruby/1.9.1/timeout.rb:54:in `timeout\u0026#39; 全ログはこちら。\nまだきちんと問題を調査しないでブログを書いています、すみません。\n現象 ログが発生した時の症状です。\nクライアントプログラムは送信が続いており、エラーは出ない td-agent.logに先ほどのエラーが出力 別途type fileにて出力しているログも停止 想像 とりあえず、ログを見た想像、所感です。\n問題の箇所はfluent-plugin-zoomdataからZoomdataサーバへのデータ送信部分 emit処理内部で、HTTPSでデータをPOSTする処理でエラーが起きて リトライ処理とか書いてないので、emitがコケて、その後データが送信されなくなる emitで例外をつかみそこねてるのがあるから止まってる？ とまぁ、ちゃんと仕組みを理解しないでRubyとか書くからこうなるんですねぇ。 あとでちゃんと調べて考えて、改良してブログ書きます。\n悩んでいる点、今後手を入れたい点 上記バグとは別に作りの点でいくつか悩んでる点も書いてみます。\nBufferedOutputにしてみたい fluentdのバッファリングを使って、Zoomdataが落ちていても使えるようにしたいと思っているのでBufferedOutputで書くのがいいのかなぁとか。 ちょうどいいスライドがあったので、読みながらまずは中身を理解してみよう。\nZoomdataのsource、userなどの扱い 基本的には設定ファイルで切り替えるのが妥当かなぁと思っています。\nただ、Zoomdataのsourceやuserが増えるたびにfluentdの設定を書き換えて再起動するのかなぁと。userはしょうが無いにしても、sourceは設定じゃない所で切り替えたいなぁと。\nで、切り替えるのにつぎの案があるかなぁと。\nタグで指定（今実装してるもの） メッセージにメタ情報とボディ構造を設ける 設定をどんどん増やす（やりたくない） 1と3はまぁ、いいかと。2.のパターンはどうなのかなぁと。 毎回のメッセージでヘッダ部分が送信されるのはなんだか無駄だなぁというのが否めないので悩ましいところです。1、2の両方対応できるように作るのもありか。\n{ \u0026#34;header\u0026#34;: { \u0026#34;source\u0026#34;: \u0026#34;source_name\u0026#34;, \u0026#34;user\u0026#34;: \u0026#34;userid\u0026#34;, \u0026#34;password\u0026#34;: \u0026#34;userid\u0026#34;, }, \u0026#34;body\u0026#34;: { \u0026#34;label\u0026#34;: \u0026#34;label1\u0026#34;, \u0026#34;count\u0026#34;: 1 } } ということで、fluent触って遊ぶの楽しいですね。Rubyの勉強にもなりそうだし。 ちょっとずつ頑張ってみようかなぁと。 まぁ、まだ私以外にニーズは無さそうなプラグインですが。\n","date":1370234580,"dir":"post/2013/","id":"494557db52824555864d1106278cd1f0","lang":"ja","lastmod":1370234580,"permalink":"https://blog.johtani.info/blog/2013/06/03/fluent-plugin-zoomdata-0-0-1/","publishdate":"2013-06-03T13:43:00+09:00","summary":"憧れ？のfluentを使ってみました。 こちらの記事で紹介したZoomdataを最近触っているのですが、お試しにfluentdでデータ流し込む","tags":["Zoomdata","fluentd"],"title":"fluent-plugin-zoomdata作りました＋悩み事とか"},{"contents":"最近、Markdownで文章を書くのに慣れてきました。 ということで、ブログをMarkdownで書けないかなぁと思い、TLの人たちのブログを見たりしていると 「Octopress」というキーワードがあるじゃないですか。 ということで、Github Pages作って、Octopressを使ってブログを書いてみました。 こちらです。\n独自ドメインは昨年から使っているものがあったので、ついでに独自ドメインの設定もしてみました。 ケチなので、.comなどではなく、.infoですが。。。\nということで、徐々にOctopressに移行していこうと考えているところです。 こちらのブログも当面は残しておく予定です。（有料会員は解約して、広告が出る形になると思いますが。。。）\nOctopressでこんなの便利だよとかアレば教えてもらえると助かります。\n","date":1370228038,"dir":"post/2013/","id":"16f10764f0ccce42d5be8cfeac36b446","lang":"ja","lastmod":1370228038,"permalink":"https://blog.johtani.info/blog/2013/06/03/octopress%E3%82%92%E8%A9%A6%E3%81%97%E4%B8%AD/","publishdate":"2013-06-03T11:53:58+09:00","summary":"最近、Markdownで文章を書くのに慣れてきました。 ということで、ブログをMarkdownで書けないかなぁと思い、TLの人たちのブログを見","tags":["misc"],"title":"Octopressを試し中(Jugemより移植)"},{"contents":"昨年から、ブログをどうしようかって話をしていて、そのままになっていたのですが、Octopress＋Github Pagesというのがあるらしいと聞きつけて（Twitterで見かけたのかなぁ？）ちょっとやってみました。\n最近は、ドキュメントをMarkdownで記述しようとして癖をつけているのもあり、 ちょうどいい練習になるかなぁと。\nということで、まずは手始めのエントリーでした。 いくつか書きたいこともあるので、調べながら書いていこうかと。 まだ、イメージできてないこと\n画像をどうやって貼るの？ About meみたいなのも貼り付けたい bitbucketやTwitterのリンクとかも アフィリエイトも貼る（とりあえずSolr本を） 検索とかは？ デザインは？ などなど。ちょっとずつ調べていこうかなぁと。 あ、調べたことも書いてくのもありか。\n","date":1370098620,"dir":"post/2013/","id":"dbcc4002c15afefef853a08a0804ba3a","lang":"ja","lastmod":1370098620,"permalink":"https://blog.johtani.info/blog/2013/06/01/first-octopress/","publishdate":"2013-06-01T23:57:00+09:00","summary":"昨年から、ブログをどうしようかって話をしていて、そのままになっていたのですが、Octopress＋Github Pagesというのがあるらしい","tags":["octopress","misc"],"title":"Octopress始めました"},{"contents":"Lucene/Solr 4.3.0がリリースされた（LuceneのChanges、SolrのChanges）ので、lucene-gosen 4.3.0をリリースしました。（ダウンロードはこちら） なお、lucene-gosen 4.3.0ですが、Lucene/Solr 4.2.1以下のバージョンのLucene/Solrでは利用できません。 注意してください。 また、lucene-gosen 4.2.1もLucene/Solr 4.3.0では動作しませんので注意が必要です。\n現時点（2013/05/06）では、lucene-gosen 4.3.0はLucene/Solr 4.3.0でのみ利用できます。 これは、先日のエントリにも書きましたが、LuceneにてAPIの変更が行われたためとなります。 いくつかのクラスおよびメソッドが廃止されたため、下位互換が保てない変更が入っているためです。\n独自のTokenizerやTokenizerFactory、TokenFilterFactory、CharFilterFactoryを作成されている方は、Lucene/Solrのバージョンアップを行う際は注意が必要です。\n","date":1367850324,"dir":"post/2013/","id":"11d4726484be418849e1f4200ade9535","lang":"ja","lastmod":1367850324,"permalink":"https://blog.johtani.info/blog/2013/05/06/lucene-gosen4-3-0%E3%82%92%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Flucene-solr4-3-0%E4%BB%A5%E4%B8%8A%E3%81%A7%E3%81%AE%E5%88%A9%E7%94%A8%E3%81%8C%E5%8F%AF%E8%83%BD%E3%81%A7%E3%81%99/","publishdate":"2013-05-06T23:25:24+09:00","summary":"Lucene/Solr 4.3.0がリリースされた（LuceneのChanges、SolrのChanges）ので、lucene-gosen 4.3.0をリリースしま","tags":["lucene-gosen"],"title":"lucene-gosen4.3.0をリリースしました。（Lucene/Solr4.3.0以上での利用が可能です）(Jugemより移植)"},{"contents":" アジャイルな時間管理術 ポモドーロテクニック入門 ポモドーロテクニック入門という本を読みました。 きっかけは、Twitter上で何度か「ポモドーロ」という単語を何度か見ていたためです。 最初は、なんだろう？というのが発端です。 「ポモドーロ＝トマト」なのですが、実際にはトマト型のキッチンタイマーが元になっているらしいです。 このタイマーを使った時間（タスク）管理術がポモドーロ・テクニックです。\n私は、ここ数年、複数の仕事がパラで走ることが時々ありました。 このような場合に、日によって異なる複数のタスクが存在します。 このとき、異なるタスクにスイッチするのに結構な時間を取られます。。。 また、急な割り込みが入った時も同様に、以前のタスクに戻るのになにしてたっけ？となることが多々あります。 普通に自己管理ができている方なら問題ないのでしょうが、私は結構ニガテでした。 そのようなときに、Twitter上で「ポモドーロ」という単語を見かけて、軽くググってみたところ、 タスク管理、時間管理によさそうな本だったので、その点を矯正するのも兼ねて、読んだ次第です。 また、タスクに集中できるという利点もあるそうです。\n本については、少し読みにくいところがありました。 ポモドーロテクニックとはどんなものかという全体像や単語に関する説明がないままに、話が進んでいくので。。。 1度読み終わったあとに実践しながらパラパラめくっているような状況です。 実際には、個々人のやり方などを考慮しながら、改善していくべきなのもあり、型を説明してないのかもしれないですが、もうすこし概観がわかる感じのほうが良かったです。\nで、4月初旬くらいから実践してみています。 効果が実際にあるかというと、まだわからないです。\n私がポモドーロテクニックに利用しているのはキッチンタイマーではなく、pomodairoというAdobeAIR上で動くアプリになります。 ほかにもPomodoroAppというのもあるのですが、Free版だと登録できるタスクの上限があったので、pomodairoを選びました。（今見たら、3.0にバージョンが上がって、Limitがなくなってるかも） AIRだと、WinでもMacでも動作するのというも決定した要因です。\nまだ、1ヶ月経ってませんが、私が実践してきて良かった点、できてない点、うまくいってない点はつぎのような感じです。\n良かった点 目の前のタスクに集中できる。（25分スパンなので、Twitterを意識的に見なくできる。。。） 適度な休憩が挟める。25分に5分の休憩が入るので、適度な没頭になる（没頭し過ぎない） 自宅で作業するときにかなり有効。（5分の休憩時にTwitterやFB以外に漫画をパラパラ読んだりもできるので） ということで、自宅で作業するときには結構いいです。 自宅ですと、pomodairoを使っていてタイマーの音を気兼ねなく出せるので、きちんとポモドーロが回せます。\nできてない点 アクティビティ在庫管理。個人的にJIRAを使っていて、そこで管理しようと思っているのですが、うまくできてないです。pomodairoのアプリにもタスクを登録しているのもあり2重登録などを手間に思ってしまって。。。 レコーディングと今日のTodo作成。 インタラプトの記録 アクティビティ在庫管理ができてないのは、レコーディングがきちんと出来てないためでしょう。。。 二重管理になっている＋pomodairoで統計情報が出るが、当日分の統計情報がレコーディングできてないというのが痛いです。 また、このレコーディングが出来てないので、効果が出ているかがわからないという問題かと。。。 きりが悪かったりして、どうしても、仕事時間ギリギリまでタスクをこなしてしまい、レコーディング＋アクティビティ在庫の管理の時間が取れていません。 ここは意識してちゃんとやらないと意味がないよなぁと。今後の大きな課題です。\nうまくいってない点 できてない（やろうとしてできてない）点とは別に、どうもしっくり来ていないのがつぎのような点です。\nプログラミングしていると、25分のタイマーで区切りがすごく悪い時がおおい 自宅以外でのタイマー音が出せない 自宅以外での休憩の取り方 プログラミングをやっていて、乗ってきたタイミングでタイマーが鳴ってしまったり、 ちょっと頭のなかで整理していたあとの今まさに、頭のなかにある処理の流れをコードに落としている途中でタイマーがなってしまったり。 このような状況だと、休憩に入れなくて、ずるずるとコーディングを続けてしまうということが多々あります。 メモ（ソース上のコメントや手元）を残して休憩すればいいのでしょうが、どうしても今までの癖もありズルズルとやってしまい、すごく時間が経ってることが何度もあります。 ポモドーロテクニック的にはやはりNGなんでしょうが、なかなか治らない＋治したくない気もしています。 また、自宅以外の場合、基本的には自社ではなく客先に出ていることが多いのでどうしても音を出すことができません。 これもまた、切り替えができない要因になっています。 タイマーだけ携帯のアプリを使用しするという手もあるのでしょうが、この場合さらにレコーディングが出来ない状況に陥りそうで。。。 また、スマホだと電池が持たないのも問題点です。（Twitterを見るのに利用してるから電池が持たないという話もあるのですが。。。） レコーディングに関しては、手描きのメモを使うのがいいのかなぁと。本では＋や◎などの印を付けるだけにしておけば良いとありますが、アプリのタイマーだと自動でそれができるので、悩みどころです。 最後の休憩の取り方も、ネットやTwitterを見るのもありなのですが、画面から離れる休憩を取りたいなぁと思うところもあり。。。 職場だと技術書やWEB+DBのような雑誌はあるのですが、休憩にはあまり向いていないなぁと。\nつらつらと書いて来ましたが、本を読んで、1ヶ月実践してきた（できてないとこも多いが）現状をメモしておきます。 こうやってるよ、こうしたら良かったよ、こうしてみれば？などありましたら、コメントいただけると助かります。\n来週以降はとりあえず、JIRAできちんとアクティビティ在庫管理をしながら、1日の結果をレコーディングしていくのを意識していこうと思います。\n","date":1367592139,"dir":"post/2013/","id":"db97311c24809f103575d8a7fee19680","lang":"ja","lastmod":1367592139,"permalink":"https://blog.johtani.info/blog/2013/05/03/%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E5%9B%9E%E3%81%97%E3%81%A6%E3%81%BE%E3%81%99%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF%E5%85%A5%E9%96%80%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2013-05-03T23:42:19+09:00","summary":"アジャイルな時間管理術 ポモドーロテクニック入門 ポモドーロテクニック入門という本を読みました。 きっかけは、Twitter上で何度か「ポモドーロ","tags":["読書"],"title":"ポモドーロ回してます。（ポモドーロテクニック入門読みました）(Jugemより移植)"},{"contents":"まだ、Vote公開されていない、Solr 4.3（2013/04/25 11:00現在）ですが、 ひさびさに訳してみた。詳細まで追っていないので、誤訳があるかもしれないですが。 おかしいとこあったらツッコミを。\n○Solr 4.3.0のChanges ・Upgrading from Solr 4.2.0 1.schema REST APIのcopyFields、dynamicFieldsの出力パスをCamelCaseに。他も同様。（SOLR-4623） 2.Slf4j/logging jarをSolrのwarに含めないことに。すべてのlogging jarはexample/lib/extに。（SOLR-3706、SOLR-4651） 3.SolrCloudでハードコードされてたhostContextとhostPortをdeprecatedに。Solr5.0で削除する。（SOLR-4622）\n・New Features 1.SOLR-4648　PreAnalyzedUpdateProcessorFactoryでPreAnalyzedFieldの機能をほかのフィールドタイプでも使えるようにした。詳しくはJavadocとexampleを見て。 2.SOLR-4623　REST APIで現在のschemaのエレメントをすべて読めるように。REST APIの返却の形式として、XMLとJSONとschema.xmlの形式を追加REST APIのパッケージを変更。 クラス名も変更しschemaにフォーカスした機能も除去。今後のschema以外のREST APIのために。 copyFieldsとdynamicFieldsの出力パスをすべてlowercaseのものからCamelCaseに変更。他のREST APIも同様。 3.SOLR-4658　REST APIリクエストでschemaを変更できるようにするために、「managed schema」を導入。solrconfig.xmlに「\u0026lt;schemaFactory class=\u0026ldquo;ManagedSchemaFactory\u0026rdquo; mutable=\u0026ldquo;true\u0026rdquo;/\u0026gt;」を追加。REST APIリクエストでスキーマ変更が可能にするために。 4.SOLR-4656　2つのハイライトパラメータ（hl.maxMultiValuedToMatch、hl.maxMultiValuedToExamine）を追加。 hl.maxMultiValuedToMatchは指定された数のsnippetが見つかったらそれ以降の探索を停止する設定。multiValuedフィールドがどんなに離れてても探索する。 hl.maxMultiValuedToExamineは指定された数のmultiValuedのエントリ数を調査したら探索を停止する設定。 両方を指定した場合、最初のlimitに達したら停止する。ドキュメント全体をハイライトするためにコピーされるのを削減する。これらの最適化はmultiValuedフィールドに大量のエントリが存在する時に効く。。。 5.SOLR-4675　PostingsSolrHighlighterでper-field/クエリ次のパラメータ指定のサポート 6.SOLR-3755　既存のshardを動的にsplitしてshardを追加するための新コレクションAPI（shard splitting） 7.SOLR-4530　DIH：TikaのIdentityHtmlMapperを使う設定の提供 8.SOLR-4662　solr.xmlにあるSolrCoreの定義よりもディレクトリ構造で見つける。また、solr.xmlのフォーマットを変えて、solrconfig.xmlに近くする。Solrのこのバージョンは旧スタイルの例で提供するが、新しいスタイルも試すことができる。Solr 4.4では、新しいスタイルで提供し、Solr 5.0では旧スタイルは廃止する予定。 SOLR-4347　Adminハンドラで新しく生成されたコアがsolr.xmlに永続化される SOLR-1905　Adminリクエストハンドラで生成されたコアもsolr.xmlに永続化される。また、solr.solr.datadirのようなプロパティの用にsolr.xmlに永続化される問題のfix。 9.SOLR-4717/SOLR-1351　SimpleFacetで同じフィールドに異なるファセットを適用出来るlocalParamsを追加 10.SOLR-4671　CSVResponseWriterのpseudoフィールドのサポート 11.SOLR-4358　HttpSolrServerでuseMultiPartPostでstream名を送信できる ・Bug Fixes 1.SOLR-4543：solr.xml/solr.propertiesでshardHandlerFactoryの設定が動作しない 2.SOLR-4634：Java 8\u0026quot;Nashorn\u0026quot;JavaScript実装の動作に関するscripting engineのテストのfix 3.SOLR-4636：SolrIndexSearcherをオープンする時に何かの理由でreaderがオープンできない時に、ディレクトリがリリースされない 4.SOLR-4405：Admin UIのadmin-extraファイルでcore-menuが表示されない 5.SOLR-3956：group.facet=trueでfacet.limitがマイナスの時の動作 6.SOLR-4650：copyFieldでダイナミックフィールドや暗黙的なフィールドがsourceでマッチしない。4.2で入ったバグ 7.SOLR-4641：Schemaで、illegalなフィールドパラメータで例外が発生するようにする。 8.SOLR-3758：SpellCheckComponentが分散groupingで動作しない。 9.SOLR-4652：solr.xmlプラグインのresource loaderで共有ライブラリの挙動がおかしい 10.SOLR-4664：ZkStateReaderがaliasを更新しても見えない 11.SOLR-4682：CoreAdminRequest.mergeIndexが複数コアやindexDirが複数の場合にマージできない 12.SOLR-4581：Solr4.2で数値フィールドのファセットでマイナスの値があるとソートがおかしい 13.SOLR-4699：Admin Handlerでデータディレクトリの場所がファイルシステムだと思い込んでる。（RAMの場合もある） 14.SOLR-4695：non-cloudセットアップでもコア管理のSPLITが使えるように 15.SOLR-4680：exampleのspellcheck設定のqueryAnalyzerFieldTypeの修正 16.SOLR-4702：exampleの/browseの「Did you mean?」のサジェストをFix 17.SOLR-4710：Zookeeperから全ノードをアップせずにコレクションを削除できないのを修正 18.SOLR-4487：HttpSolrServerからのSolrExceptionがリモートのサーバから戻るHTTPステータスコードを含んでない 19.SOLR-4661：Admin UIのレプリケーションで現在のレプリカ可能なマスタのバージョンを正確に表示 20.SOLR-4716,SOLR-4584：SolrCloudリクエストプロキシがTomcatなどJetty出ないコンテナで動作していない 21.SOLR-4746：Distributed groupingのトップレベルグループコマンドでSimpleOrderedMapの代わりにNamedListを使う。non-distributed groupingと出力形式が異なるため。 ","date":1366856040,"dir":"post/2013/","id":"286a9a4ee373398d7d2c93862c5f6661","lang":"ja","lastmod":1366856040,"permalink":"https://blog.johtani.info/blog/2013/04/25/solr4-3-0%E3%81%AEchanges%E3%82%92%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/","publishdate":"2013-04-25T11:14:00+09:00","summary":"まだ、Vote公開されていない、Solr 4.3（2013/04/25 11:00現在）ですが、 ひさびさに訳してみた。詳細まで追っていないので、","tags":["solr"],"title":"Solr4.3.0のChangesを訳してみた。(Jugemより移植)"},{"contents":"現在、RC3のVoteをやっている最中（2013/04/24　16:00時点）で、まだリリースされていない、4.3.0についてです。 開発者MLでChangesの書き方を考えないとね、みたいなエントリーが流れてて気になっていたので、訳してみた。 lucene-gosenの実装を変更しないといけないっぽいなぁ。Lucene/Solr 4.2.1以前と4.3.0でI/Fとかが変わることになりそうです。（3.とか8.とか） （ここで力尽きて、それより下はまだ読んでないです。。。）\n○Changes in backwards compatibility policy 1.LUCENE-4810：EdgeNGramTokenFilterが同じ入力tokenから複数のngramを生成した時にpositionを増加させていないのを修正 2.LUCENE-4822：KeywordMarkerFilterがabstractクラスで、サブクラスがisKeyword()メソッドを実装する必要がある。新しく、SetKeywordTokenFilterというクラスにすでにある機能を分解した。 3.LUCENE-4642：TokenizerとサブクラスのAttributeSourceのコンストラクタを削除。代わりにAttributeFactoryをもつコンストラクタを追加。 4.LUCENE-4833：IndexWriterConfigがsetMergePolicy(null)の時にLogByteSizeMergePolicyを使っているのをデフォルトmerge policyをTieredMergePolicyに。また、nullが引数に渡されたらExceptionを返す。 5.LUCENE-4849：ParallelTaxonomyArraysをDirectoryTaxonomyWriter/Readerのためのabstractとして作成。あと、o.a.l.facet.taxonomyに移動。 6.LUCENE-4876：IndexDeletionPolicyをInterfaceではなく、abstractクラスに。IndexDeletionPolicy、MergeScheduler、InfoStreamでCloneableをimplement。 7.LUCENE-4874：FilterAtomicReaderと関連するクラス（FilterTerms、FilterDocsEnumなど）でフィルタされたインスタンスをforwardしないように。メソッドが他のabstractメソッドを実装している場合に。（？） 8.LUCENE-4642, LUCENE-4877：TokenizerFactory、TokenFilterFactory、CharFilterFactoryの実装者は、少なくともMap\u0026lt;String,String\u0026gt;（SPIフレームワーク（Solrとか）によってロードされる）を引数にするコンストラクタを提供する必要がある。さらに、TokenizerFactoryはcreate(AttributeFactory,Reader)メソッドを実装する必要もある。\n","date":1366786800,"dir":"post/2013/","id":"99f5219da22485d0872a2529599c8440","lang":"ja","lastmod":1366786800,"permalink":"https://blog.johtani.info/blog/2013/04/24/lucene-4-3-0%E3%81%AEchanges%E3%81%AB%E3%81%82%E3%82%8Bchanges-in-backwards-compatibility-policy%E3%81%8C%E6%B0%97%E3%81%AB%E3%81%AA%E3%81%A3%E3%81%9F%E3%81%AE%E3%81%A7%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/","publishdate":"2013-04-24T16:00:00+09:00","summary":"現在、RC3のVoteをやっている最中（2013/04/24 16:00時点）で、まだリリースされていない、4.3.0についてです。 開発者ML","tags":["solr"],"title":"Lucene 4.3.0のChangesにあるChanges in backwards compatibility policyが気になったので訳してみた。(Jugemより移植)"},{"contents":"第2回目も参加しました。 とりあえずメモ。 自分には欠けてる視点の話しなので面白かった。 ちょっと寒かったなぁ。\nエンジニアのためのスキルアップ勉強会『Tech Compass』 #tecomp ― Vol.2 「人気Webサービスの作り方教えます！」 ― 日時：2013/04/23 19:00 場所：パレスサイドビル9F マイナビルーム ◎自己紹介 ●株式会社Zaim／閑歳孝子 小学校3年からFMVで草の根チャットとかにつないでた。（すげー） これがいい記事ですよ。http://www.1101.com/umeda_iwata/ テレビとかで紹介されてるZaimやってます。 3つの基準　・日常的に使うもの ・普通の人が使うもの ・少なくとも自分は使うもの サービスの良さの基準 縦軸：影響の深さ 横軸：影響する人数 この面積が大きいのがいいんでは。 ●株式会社ワディット／和田裕介 いろいろ作ってます「カウントダウンチューブ」とか「君のラジオ」とか30～40くらい作ってます。 ・「ボケて」ってのやってます。 600万ボケ。アプリ120万DL　僕らがつくるための５Wについて ・なぜ？ ・サービスの根本となる「哲学」をみんなで共有できるかが重要 ・内向けのビジョンも大事 ・何を？ ・ユースケースで整理する ・いつ？ ・つくろう！すぐ作れるようにしようねって感じ ・誰と？ ・最強のチーム。意思決定がはやい。 自分主体でサービス設計して、作りなおすのをためらわない ◎ディスカッション Q：どうしてサービス作ったの？ A：エンジニアへのあこがれから、サービスを作った（閑歳さん） ものづくりという意味では、Webサービス以外もあるけど？（馬場さん） 学内のSNSのようなものを作ってて、アクセスが伸びるのが面白かった。（閑歳さん） 大学でlastfmみたいなものを研究してて。。。（和田さん） 社会に出てサービスを作るまでの話は？作って稼ごうって思ったのは？（馬場さん） あんまりなかった。（閑歳さん） すでに起業してた。サービス作ると実績として認められて仕事が入ってきてた。（和田さん） 直接あった時に反応がもらえるのが楽しい。（和田さん） Q：どうやって、チームを組み立てたりして開発とかしてきたのか？（馬場さん） A：「ボケて」まとめサイトでブレイクしたけど、アクセス数が落ちてない。 同年代の知人で色々とチームが組めてて楽しい（和田さん） はじめは一人でやってて、しかも構想とか。あとロゴだけ最初に作ってた。 ノマド的に作業してました。（閑歳さん） Q：チームがバラバラですが、困らないですか？ A：今のところ困ってないです。もっと人が増えると困るかもしれないですけど。（閑歳さん） それぞれが他に職を持ってるので特に困ってないです（和田さん） 向き不向きはあるんじゃないかなぁ。10人とかになるとどうなるか不明（閑歳さん） GoogleのMLでレスが早ければ問題ないかな。（和田さん） あとは、チームが大きくならないように上手く分割してる（？）（ふたりとも） Q：ユーザの声の吸い上げ方、サービス改善の判断材料は？ A：ユーザの声は聞くけど、全部取り込むものではない。 細かな点はユーザの声を取り込むけど、軸はブレないようにしてる（閑歳さん） 古参ユーザよりも新しいユーザを取り込むのが大事。（和田さん） nanapiのけんすうさん Q：品質はどうしてる？ A：セキュリティは絶対。（閑歳さん） 品質を気にするってのは難しい。品質を担保できる仕組みを作るとこまでいけるようにしたい。 投稿される画像はチェックしている。（和田さん） ","date":1366717542,"dir":"post/2013/","id":"36ff37ced0d3211db95a5ac0daac0c35","lang":"ja","lastmod":1366717542,"permalink":"https://blog.johtani.info/blog/2013/04/23/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass--tecomp--vol-2-%E4%BA%BA%E6%B0%97web%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9%E6%95%99%E3%81%88%E3%81%BE%E3%81%99%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2013-04-23T20:45:42+09:00","summary":"第2回目も参加しました。 とりあえずメモ。 自分には欠けてる視点の話しなので面白かった。 ちょっと寒かったなぁ。 エンジニアのためのスキルアップ勉強","tags":["勉強会"],"title":"エンジニアのためのスキルアップ勉強会『Tech Compass』 #tecomp ― Vol.2 「人気Webサービスの作り方教えます！」に参加しました。(Jugemより移植)"},{"contents":"だいぶ、ブログを書くペースが落ちてきてて、危機感を感じている今日このごろです。。。 今回は、個人的に利用しているJIRAのバックアップについて、ブログに残しておこうかと。\nさくらVPSのサーバを借りてJIRAを運用しています。 運用といっても、自分の備忘録のためというのが大半の理由です。 タスクを忘れないように管理するのと合わせて、その作業を行ったときのメモも残したいなと。\nバックアップといっても、同じサーバ内に保存しても意味がない＋AWSを触ると言いつつ1年以上経ってしまったので、 このへんで本腰を入れるという意味も込めてAWSのS3（ゆくゆくはGlacier）にバックアップを取る仕組みを作りました。 「作りました」というと凄そうですが、Cronとシェルだけで終わりました、なんて便利な世の中。 ということで、以下は作業の備忘録です。\n1.AWSのアカウント作成 アカウントを作ってください。ここは特に説明しなくてもいいかと。。。クレジットカードの登録が必要なのが注意点でしょうか。 アカウント作成後の1年間は無料枠と呼ばれる仕組みが用意されており、いろんなことが無料で行えます。 （まだ、S3しか使ってないので、他にももっと使わないと。。。）\n2.S3のバケット作成 AWSのアカウントが作成できたら、Amazon S3（Simple Storage Service）のバケットと呼ばれる、データの保存先を作成します。 作成手順はこちらの公式入門ドキュメント（英語）をそのまま行いました。 簡単な手順はこちら\nAWS Management Consoleと呼ばれるところから、S3のコンソールにアクセス 「Create Bucket」ボタンをクリック 「Bucket Name」を入力し、リージョンを選択したら「Create」ボタンをクリック 以上でバケットが作成されました。これだけです。WebのConsoleからファイルをアップロードすることも可能です。 ただ、今回はさくらVPSから定期的にバックアップしたいのでシェルでアクセスできるようにします。\n3.AWSのアクセスキーとシークレットアクセスキーの取得 次に紹介するs3cmdというツールを利用するのに、AWSのアクセスキーとシークレットキーが必要になります。 取得方法はこちらを参考にしましたが、今は日本語のページが用意されています。 セキュリティ証明書（Security Credentials）のページで、「アクセス証明書」というタブで、「新しいアクセスキーを作成する」リンクをクリックしてください。 アクセスキーIDが新しく表示されます。このアクセスキーIDとシークレットアクセスキー（表示リンククリック後に表示される）をメモしておきます。\n4.s3cmdのインストール 世の中には便利なものを作ってくれる方がいるもので。 s3cmdと呼ばれるS3へアクセスできるコマンドラインツールが存在します。 ということで、こちらをインストール。これまた、便利なものでインストール手順を書いてくれれてるブログもありました。（あれ、なんか、見たことある名前がURLにはいってるなぁ） インストールはこちら。\n# yum -y --enablerepo epel install s3cmd インストール後に、先ほど取得したアクセスキーIDを設定します。\n$ s3cmd --configure Access Key: xxxx Secret Key: xxxx 以上で、s3cmdが使えるようになりました。\n5.バックアップスクリプトの作成 つぎは、本題のJIRAのバックアップです。 バックアップ方法はこちらを参考にしました。ちょっと古いみたいですが。 おもなデータは「JIRAのXMLバックアップユーティリティ」にてバックアップするか、「データベースのバックアップツール」を利用する方法があります。 推奨は「データベースのバックアップツール」のようなので、私の場合は「pg_dump」にてJIRAのデータベースをまるごとバックアップすることにしています。 また、データベースには添付ファイルが保存されていないようなので、別途「/var/atlassian/application-data/jira/data」というディレクトリをtarコマンドで圧縮して保存すようにしました。 あとは、pg_dumpの結果と添付ファイルの保存先の圧縮したデータをまとめてディレクトリに保存して圧縮します。 さいごは、S3にアップロードすればおしまいです。 一応、ファイルが連綿と残り続けるのは嫌だなぁということで、ファイル数で世代管理することにもしました。 これまた、ググって見つけてきたサイトを参考にしただけですが。。。 ということで、こんなかんじのスクリプトを日時でcronに設定して動かしてます。\n#!/bin/sh TODAY=`date +%Y%m%d` BACKUP_HOME=\u0026#34;/var/atlassian/backups\u0026#34; S3SYNC_DIR=\u0026#34;/var/atlassian/backups/s3sync\u0026#34; AGE=7 mkdir -p ${BACKUP_HOME}/${TODAY}/ /usr/bin/pg_dump -U postgres -Fc jiradb \u0026gt; ${BACKUP_HOME}/${TODAY}/jiradb_backup.dump tar zcvf ${BACKUP_HOME}/${TODAY}/attachment.tgz /var/atlassian/application-data/jira/data tar zcvf ${S3SYNC_DIR}/jira_backup_${TODAY}.tgz ${BACKUP_HOME}/${TODAY} rm -rf ${BACKUP_HOME}/${TODAY} NUM=`ls ${S3SYNC_DIR} | wc -l` while [ ${NUM} -ge ${AGE} ] do DEL_FILE=`ls -lt ${S3SYNC_DIR} | tail -1 | awk \u0026#39;{print $9}\u0026#39;` rm -r ${S3SYNC_DIR}/${DEL_FILE} NUM=`ls ${S3SYNC_DIR} | wc -l` done s3cmd sync --delete-removed ${S3SYNC_DIR}/* s3://my_jira_backup/s3sync/ そこへんだよとかあれば、ツッコミを。 今のところ、S3へのsyncだけなので、このあとは、月1くらいでGlacierに落とすとかの仕組みも考えるかなぁ。これまた何かあるんだろうけど。 あとは、この応用で家のNASに溜まっている写真をS3経由もしくは直接Glacierにバックアップする仕組みを考える予定です。\n","date":1366639648,"dir":"post/2013/","id":"1ca04e5339ed1826c12fe61fd984e949","lang":"ja","lastmod":1366639648,"permalink":"https://blog.johtani.info/blog/2013/04/22/jira%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E3%82%92s3%E3%81%B8%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97/","publishdate":"2013-04-22T23:07:28+09:00","summary":"だいぶ、ブログを書くペースが落ちてきてて、危機感を感じている今日このごろです。。。 今回は、個人的に利用しているJIRAのバックアップについて","tags":["備忘録"],"title":"JIRAのデータをS3へバックアップ(Jugemより移植)"},{"contents":" HerokuではじめるRailsプログラミング入門 heroku気になってるのに使ってなくて、TDのアカウント作ってデータアップしてない軟弱者ですが、参加して来ました。。。 とりあえず、大事なことです。まずは、上記の書籍を買ってください（って中の人が言ってました。） イベントページはこちら。\n総じて、herokuの中のエンジニアの方たちがすごく情熱があって、ユーザと会話をしたがっているという感想だったようで、まだまだ、よくなりそうだなぁと。 私は、ベースがJavaなので、JavaやScala、Playで使ってる方の感想とか聞きたいかなぁ。 あと、herokuとS3の組み合わせだと思うんですが、料金とかはAmazonとheroku両方に別々に払うのかな？とかはちょっと気になりました。 AWSのアカウントも作ってS3にバックアップあげるの作ろうと思って手をつけてない軟弱者ですが。。。 今月は余裕がありそうなので、TDとか触ってみようと思います。。。\n懇親会ではTDのmuga-sanとお話できて、いくつか気になってた話ができたのでスッキリしました。 あと、株式会社サムライズムの名刺頂きました。写真載せろって言われたけど、また今度ｗ\n最後に、大事なことです。まずは、上記の書籍を買ってください（って中の人が言ってました。）\n以下は、いつものようなメモです。最後の方はちょっとくたばってたのでメモがおざなりになってます、すみません。\n日時：2013年04月04日(木) 18時30分 - 21時00分 場所：日本創生ビレッジ 事業開発支援オフィス 東京21cクラブ コラボレーションスペース ◯Ayumu Aizawa（Heroku, Inc.） ・■ PostgreSQLが9.2になりました。 ・◆ メモリが2倍。βテスタ向けにスケールアップ。 JavaとかJavaとかJavaとかデプロイしてもいいよね。 けど、メモリ2xは価格も2x！ ・● Heroku OAuthを提供。Experimentalだけど。 heroku-bouncer使うとOAuthが楽になる。 ◯Treasure Data and heroku Masahiro Nakagawa（TreasureData） ・会社紹介 ・フロントエンド部分の担当（fluentd） ・1500億レコード！？ ・投資家の中にHerokuの方がいる。 ・ターゲットは？ Cloud + Big Dataが対象 Hadoopは立ち上げるのはいいんだけどメンテナンスコストが。 Hadoopの処理基板を提供 ・Hadoop生ではなく、Plazmaを使っていたりする。 ・Viki herokuにtd-agent入れて、TDにデータ送って、Postgresに書き出して使ってる。 ・TDはどうやってheroku使ってるの？ Webコンソール。 http://console.treasure-data.com Webサイトは大体heroku fluentdとかも ・herokuのaddonとしてtd-agentを提供してる。 ・STDOUTからTDにデータ送るのもできるよと。 ◯Waza Report ◯吉田雄哉さん（co-meeting） ・まずは、co-meetingの紹介。 1文字ずつ送信してるよと ・Chief Talk Officerらしいｗ ・MongoDB使ってるって言ったら、herokuのPostgreSQLの人と話して、鼻で笑われたｗ ・すごく熱意のある人達がエンジニアとして働いてる ・ユーザの声をきちんと聞いてくれる体制ができてるミーティングだった。 ・「クラウド」って単語を聞いてない。勉強会のレベルもすごい。 ◯山本裕介さん（株式会社サムライズム） ・ニッチなブログ書いてます。 ・Java屋が見るWaza Tシャツプレゼント！ ・OSS好きが多い。 Java/Scala系の話が少なかった。Scala界隈では人気みたい ◯岡村純一さん（株式会社シャノン） ・スライド1枚も作らずに喋る人とかいました。 （すごい。。。） ・Django Playに似てて面白いかもと ・Ruby2.0 Matzが喋ってたとか ・クロージングはビールが出てきてた。 交流パーティみたいになってた。CROSSがそれに似てますね。日本でやってるイベント ◯小西俊司さん（株式会社フレクト） ・バックエンドの性能とかを収集して見ることができるツールがあるらしい。 ・クエリを登録しておくと監視ができるツールとか。（TDとかぶってる？） ・やっぱり、情熱的だし、OSS好きでオープンな感じのエンジニアが多い。 ◯Heroku LT 無慈悲なLTです。3分たったらケーブル引っこ抜きます。 （最後はくたばっててあまり聞けてない。。。） ◯山本 裕介（株式会社サムライズム） ・herokuでJava7！ Java6終わってますからherokuも移行してね！ ◯竹野 淳（Grow!） ・BoxTo？ ・コラボレーター募集！ ◯小西 俊司（株式会社フレクト） ・ExcelのテンプレートをアップロードしてGETでパラメータわたせばいいよみたいなの作ってる。 ◯大久保英樹（Job-Hub） ・CarrierWaveとかの注意点 ","date":1365128443,"dir":"post/2013/","id":"73d2fce4efa52675b35a11ee97bc2db0","lang":"ja","lastmod":1365128443,"permalink":"https://blog.johtani.info/blog/2013/04/05/heroku-meetup--8-treasuredata--waza-report-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/","publishdate":"2013-04-05T11:20:43+09:00","summary":"HerokuではじめるRailsプログラミング入門 heroku気になってるのに使ってなくて、TDのアカウント作ってデータアップしてない軟弱者","tags":["勉強会"],"title":"Heroku Meetup #8 TreasureData + Waza Report!! に参加しました。#herokujp(Jugemより移植)"},{"contents":"記念すべき！？第10回のSolr勉強会です。\n発表者が無事あつまり（本当にありがとうございました！）、今回も盛況な感じでほぼ満員でした。 ツイートのおかげか、キャンセル処理もちゃんと行なってもらえて助かりました。 開場直後にドタバタしてしまい、すみませんでした。。。\nとりあえず、第一報の記事をアップしておきます。 懇親会での話とか感想はまたあとで。\n関口さんの資料は実は、前もって見たことがある資料でした。 最初の発表にしては、少しむずかしいと思った方もいるかなぁと。 ただ、類義語の辞書は結構作るのが大変だし、探しても出てこないものなので、面白い話だったんではないかなぁと。 「ミスチル」はできないけど、「マツケン」ができるのは読みがあるからとかなんですかねぇ？って質問するの忘れてた。\n尾形さんの話は結構、みんな通ってきた道かもなぁと思いました。他の方も同じ経験してるんじゃないかなぁと。 ただ、一人でやるのはすごいですよね。検索って結構人数が割かれてない場合が多いのかなぁ。 あんまり使われていないというのが少し悲しい話でしたが。。。 サーバを要求すれば結構なスペックが用意してもらえるのはうらやましい限りですねぇ。 スキーマ変更については、レプリケーション機能を使うと追加などならうまくいくんじゃないでしょうか。（そんなツイートもありましたよ。togetter読み返すと出てきます。） フィールド名を変更しないで型を変更するなどしたらおかしくなると思いますが。\n野口さんの話はなかなかチャレンジングでいいなぁと思いました。よく挫けずに頑張られているなぁとｗ 試行錯誤した仮定も発表してもらえると同じ轍を踏んだ人が助かると思います。 大きな企業で本格的に横断的な社内検索が出来る仕組みが出来上がっているって話はなかなかきかないかなと。 どうしても、社内検索とかお金が出なくて手を付けられないといいう悲しい話が多いので、こういう話は共有したい情シスの方がいっぱいいるんじゃないかなぁと。 ManifoldCFが結構地雷を多く含んでいるのは大変そうですね。。。 SolrにもTikaが入っていたりしますが、個人的にはTikaがやるべき処理は前処理と思っているので、Solrとは別の場所でやりたいとか考えていたりします。 ManifoldCFがその辺りまでやってくれるかまではちゃんと調べてないんですが。 Solrは検索だけに注力させることで、役割を分割できるので、性能の対処とかを行うのが楽になるんじゃないかなぁとか。 ManifoldCFで困ってる人は他にもいるようなので、ジャンジャン使って、どんどんチケット上げて貢献してもらうといいかと。 また、定期的に発表してもらうと面白そうだなぁと。\n弘瀬さんの話は結構興味ある方がいたんじゃないかなと。 SolrCloudは壮大だなぁと思いつつ、手を出しづらいと思ってる方が多いと思います。 実際のサービスに投入して試行錯誤された話を細かな数値も上げて発表してもらえるのは検証をやる方の助けになります。 残念ながら、私もSolrCloudは興味有りつつちゃんと追っかけてないので、途中でnodeとshardとcoreの関係がわからなくなってしまいましたので。。。 もう一度勉強して、スライドを見たいと思います。。。 分散検索（1つのインデックスが複数のcoreやshardに分割された状態）が絡んでくると、複数台の検索の性能のうち、一番遅い性能が最終的な検索性能に響いてくるので、検索リクエストの偏りとかも影響が出たりするかもしれないなぁと。 そういった意味でも試行回数を3以上で計測した結果で再度発表してもらうと面白そう！（なんか、下心見え見えですがｗ）\n前回、今回も感じたのですが、もう少し質問をしてもらえると発表された方も励みになるかなぁと思いました。 質問しにくい雰囲気になってるのでしょうか？参加者が結構いるから質問しにくく感じたりするのでしょうか？ そのあたりをもう少しうまくやれるようになにかコメントもらえると嬉しいかなぁと。 運営で気になった点などもコメントやツイートをいただけると今後の改善にも役立てますので気兼ねなく連絡いただけると助かります。 開場がドタバタしすぎとか、ハッシュタグがわからなかったとか。\n今回は思ったよりも懇親会に残る方が少なめでした。 コミッターの方（LuceneやManifoldCFとかlucene-gosenとか）が複数いたり、Solrを結構触ってる方がいたりと面白い話が聞けそうだったのですが。。。 Kuromojiのユーザ辞書の改良点をチケットにあげるって約束したのでやらないとなぁ。 早く帰るつもりだったのに気づいたら23時でしたwやっぱり色々と話ができるのが楽しくて。。。 駅前の機動隊とかびっくりしながら帰りました。 今回、お話ができなかった方もいらっしゃるかと思いますが、気兼ねなく、ツイートしてもらったり、声をかけていただければと。\nあと、常に発表していただける方は歓迎しておりますので、連絡いただけると非常に助かります！ こんな話が聞きたいなどでもいいかと思いますので、連絡いただければと。\n#SolrJPもtogetterにまとめてもらいました。ありがとうございます。 以下は、いつものメモになります。\n日時：2013/03/26 19:00 to 21:00 場所：VOYAGE GROUP 会議室 1. 株式会社 ロンウイット　関口　宏司さん タイトル：Wikipediaからの類義語知識の自動獲得について 発表資料はこちら\n・「辞書型コーパス」という単語は造語かもしれません。 ・なんでこんなことを？ →類義語辞書を自動生成したいから。 ・自賠責保険、自動車賠償責任保険を例にSynonymFilterの説明。 ・Wikipediaを入力として、類義語辞書を作成するときにLuceneのインデックスを活用してる。 ・類義語候補の見つけ方 いくつかヒューリスティクスな処理とかも入れてます。 日本語Wikipedia固有なもの。 ・実際に導出された単語も載ってる。 FTPなども導出で来てる。 丸ビルとかも。 ・導出できなかったものもあります。 「十六進法」が「十進法」になってる 「ミスチル」も無理。 ・ミスもあるけど、類義語が存在しない場合になんとなく、使う辞書としては採用できるのでは？ 類義語検索対象のブーストを小さくするなどをすれば役に立つ Q：類似度にしきい値を用意したりしてますか？ A：min.scoreという値を用意し、足切りをしている。 Q：ベクトルを作るという話があったが、品詞でフィルタリングとかしてる？ A：名詞に限って処理してます。名詞に限らなくてもいいかも。。。（若干聴き逃しました） 重みの高いn件をベクトルの対象にしてます。 2. グリー株式会社　尾形　暢俊さん タイトル：GREEにおける全文検索の歴史 発表資料はこちら\n・GREEさん、検索はないがしろにされてる。。。 一人でつくって、一人でメンテナンスしてる。 ・GREEの検索は右上の検索ボックスが ・2007年はSennaつかってました。 Tritonnに移行。2009年くらいまで。 やっぱり安定しない＋MySQLのバージョンアップしたいけど、追従できない ・2012年初頭までLuceneでやってた。（結構古い） フラグメントが発生してOptimizeすると、検索サーバが使えなくなる。。。 検索しにくるサーバが1000台いるので、Optimizeかけるときに、1000台のサーバの設定を書き換えるとかしてた。。。 ・現在まではSolrをつかってる。 Luceneのバージョンも古かったので100倍くらい速くなった。 ・Solr本が必須ですよ！！！ ・Lucene+Tomcatから移行。 移行に気をつける点として、I/FをそのままSolrに置き換えると。 Solr返却のXMLをカスタマイズしたり、クエリをSolr向けに書き換えたり。 あと、メンテナンスが楽になるように。 40数台のインデックスサーバがあると。 一人でメンテナンスしてるから、楽になる方法が重要 ・レプリケーションで、Optimizeの影響が出ないように。 キューをつかって、マスタに登録して、スレーブにレプリカを配布 ・スキーマが7つ あんまり使われてなくてかなしい。。。 ・負荷のグラフもありました。 ・RangeQueryを結構使う。 ・作りこんだ部分 インデックスのMasterへ分散させる処理とか クエリの変換とか人力監視処理とかNGワードとか サーバ監視のための仕組み ・今でも大変なこと スキーマ変更が大変 スレーブをマスタに昇格とかが手動 ・今後改善したいこと 精度を上げたい 辞書を使ってみたいけど、各国語対応 あと、自動化とか 3. ソフトバンクBB株式会社　野口　勝義さん タイトル：企業内の大規模ファイルサーバ検索事例 ・情シスの企画版？という立場のかた。 ・売上に貢献したいのでクラウドサービスとして検索をオプションとして立ち上げてみた！ ・Solr＋ManifoldCFで作ってみたよと ・なんでSolr？ OSSだし、機能が充実 ・なんでManifoldCF？ Active Directory連携が使いたかったと。 社内検索ってやっぱりアクセス権がうるさいので。 ・ManifoldCFの説明はロンウイットさんの画像を使わせてもらいましたｗ ・ファイルサーバが、70TB。。。 ・困ったこと。 ・その１ ・クローラージョブの構成の最適化どうする？ ・マルチコアで、クローラーとファイルサーバを1対1の構成にしてみた。 ・その２ ・ファイル数が増えるとまた問題が。。。 ・ファイルサイズが大きい→Heapが足りないエラーとか、MCFのタイムアウトとか。。。 ファイルサイズのリミットを設けてみた。 mp4とかでエラーがでるとか。既知のエラーでしたとか。 ulimitがたりないとか。 MCFの稀に出るバグとか。。。 ファイルサーバの不良ブロックとか。。。 ・その３ ・クロールに時間がかかる ・MySQLでスロークエリとか MySQLよく知らないとか言われながらコミッターに対応してもらうなど。 SSDつかうとか考え中 ・フルクロールで1週間 差分でも1日強かかる。 ManifoldCFだけで対応できないから、ファイルの特徴を元に →ManifoldCFを経由しないリアルタイムインデックス更新のAPIを経由してMasterじゃなくて、更新かけると。（特定のクライアントからの方法） ・その４ ・本文データをstored=falseに けど、ハイライトできないから、どうにかしたい ・ユーザの要望 ・もしかして検索 類義語？じゃないよねぇ。テザリング、tezaringuとか フロント側で頑張った。（Solr諦めました） ・検索スコアも弄りたいとか 外部データでブーストとかもしたい。External Fieldとか使うといいのでは？とか。 4. 株式会社サイバーエージェント　弘瀬　健さん タイトル：SolrCloudの導入事例 発表資料はこちら\n・Webエンジニアだったのに、検索エンジニアに！ ・SolrCloudもサービスインしてると。 ・SolrCloud概要 4.0以降の機能とか。 ・SolrCloudの構成要素 概念的なもの。Collection、Shard 物理的なもの。Node、Core ・ Simplogってサービスに導入済み。 ZooKeeperが3台、6Shard、3nodeという形式 ・性能 平均レスポンスタイム50msec 思ったより出てないので、調べてみた。node数とかshard数を変えてみて調べてみた（まだ、模索中。） ・色々テストケース試したけど、試行回数が1回だけです。 詳細なデータが出てるのありがたい（全部はまだ理解できてないですｗ） ・検証まとめ ノード当たりのcore数が少ないほうが検索、更新性能がいい 1コレクション当たりのshard数が少ないほうが検索性能がいい ・まとめ ・SolrCloudの利点 クライアントが色々意識しなくていいのがうれしい。 ・SolrCloudの注意点 shardの分割機能がまだないので、大変。 コレクション情報が壊れると検索更新できないとか。4.0だとバグが有った ・性能的には素のSolrのほうがいいよと。 ","date":1364300160,"dir":"post/2013/","id":"26d0c0d8c465087cf160a3bdc479f2b4","lang":"ja","lastmod":1364300160,"permalink":"https://blog.johtani.info/blog/2013/03/26/%E7%AC%AC10%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/","publishdate":"2013-03-26T21:16:00+09:00","summary":"記念すべき！？第10回のSolr勉強会です。 発表者が無事あつまり（本当にありがとうございました！）、今回も盛況な感じでほぼ満員でした。 ツイー","tags":["勉強会"],"title":"第10回Solr勉強会を主催しました。#SolrJP(Jugemより移植)"},{"contents":"なんか、とても久しぶりにイベント参加メモ以外の投稿です。 elastic searchのMLを見てたら、KuromojiのAnalyzerを使うときにユーザ辞書使うのどうするの？という投稿を見かけました。\nKuromojiのユーザ辞書にもちょうど興味があったり、elasticsearchもちょっとずつ触りたかったのでちょっと試してみました。（返信もしてみましたが、テキトーな英語です。。。）\nelasticsearch-kuromoji-pluginのインストールなどはElasticSearch で kuromoji を使う (ES 0.90.Beta1 + kuromoji 1.2.0篇)を参考にしてください。 私もこちらに記述のある組み合わせ（elasticsearch-0.90.0Beta1 + elasticsearch-analysis-kuromoji/1.2.0）を利用しました。 KuromojiのAnalyzerはデフォルトで「kuromoji」として登録済みですが、こちらはユーザ辞書の指定がありません。 ということで、「kuromoji_user_dict」というユーザ辞書指定をしたtokenizerと、それと使う「my_analyzer」というanalyzerを登録したIndexを作成します。 定義する前に、「userdict_ja.txt」を用意して、elasticsearch-0.90.0Beta1/config/ディレクトリに配置しておきます。 （以下のサンプルでは、SOLE_HOME/example/solr/collection1/conf/lang/userdict_ja.txtをコピーして使いました）\n$ curl -XPUT \u0026#39;http://localhost:9200/kuromoji_sample/\u0026#39; -d\u0026#39; { \u0026#34;index\u0026#34;:{ \u0026#34;analysis\u0026#34;:{ \u0026#34;tokenizer\u0026#34; : { \u0026#34;kuromoji_user_dict\u0026#34; : { \u0026#34;type\u0026#34;:\u0026#34;kuromoji_tokenizer\u0026#34;, \u0026#34;user_dictionary\u0026#34;:\u0026#34;userdict_ja.txt\u0026#34; } }, \u0026#34;analyzer\u0026#34; : { \u0026#34;my_analyzer\u0026#34; : { \u0026#34;type\u0026#34; : \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34; : \u0026#34;kuromoji_user_dict\u0026#34; } } } } } \u0026#39; 「user_dictionary」というのがユーザ辞書の定義ファイルになります。 注意点としては、6行目で指定した名前「kuromoji_user_dict」を14行目の「tokenizer」に指定しないとちゃんと動かないという点でしょうか。\n上記で指定したAnalyzerを利用して「朝青龍」という単語をを解析してみます。\n$ curl -XGET \u0026#39;http://localhost:9200/kuromoji_sample/_analyze?analyzer=my_analyzer\u0026amp;pretty\u0026#39; -d \u0026#39;朝青龍\u0026#39; { \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;朝青龍\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 3, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 1 } ] 「朝青龍」という単語がユーザ辞書に登録されているので、1単語として出力されます。 ちなみに、デフォルトの「kuromoji」のanalyzerを指定すると以下の様な出力です。\n$ curl -XGET \u0026#39;http://localhost:9200/kuromoji_sample/_analyze?analyzer=kuromoji\u0026amp;pretty\u0026#39; -d \u0026#39;朝青龍\u0026#39; { \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;朝\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 1, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 1 }, { \u0026#34;token\u0026#34; : \u0026#34;青龍\u0026#34;, \u0026#34;start_offset\u0026#34; : 1, \u0026#34;end_offset\u0026#34; : 3, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 2 } ] とまぁ、こんなかんじです。 ユーザ辞書を書き換えたあとは「close/open」しないと読み込めないのかなぁ？そのへんはまたあとで調べようかな。\nちなみ、以下のページを参考にさせてもらいました。 elasticsearch kuromoji plugin - natural days ElasticSearch で kuromoji を使う (ES 0.90.Beta1 + kuromoji 1.2.0篇)\n","date":1363765380,"dir":"post/2013/","id":"f5f28f42ad234b4389af4cbea54ff60d","lang":"ja","lastmod":1363765380,"permalink":"https://blog.johtani.info/blog/2013/03/20/elasticsearch-analysis-kuromoji%E3%81%A7%E3%83%A6%E3%83%BC%E3%82%B6%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%88%A9%E7%94%A8%E6%96%B9%E6%B3%95/","publishdate":"2013-03-20T16:43:00+09:00","summary":"なんか、とても久しぶりにイベント参加メモ以外の投稿です。 elastic searchのMLを見てたら、KuromojiのAnalyzerを使うときにユーザ","tags":["elasticsearch"],"title":"elasticsearch-analysis-kuromojiでユーザ辞書の利用方法(Jugemより移植)"},{"contents":"久々にブログ＋イベント参加です。 知り合いが開催＋出演したので参加してみました。 「スマホ」ってキーワードはあまりなかったけど、面白かったです。\nとりあえず、メモ。 余力があれば感想追加します。\n日時：2013/03/19 19:00 場所：パレスサイドビル9F マイナビルーム （東京都千代田区一ツ橋1-1-1） URL：http://atnd.org/events/36966 登壇者：@naoya_ito @yusuke ◯@naoya_itoさんの発表 最近、感心してること。 ・RubyMotionやってます。 今年5月に ・AWSもやってるよ。 ・「継続的デリバリー」の話 GREEでは毎日デリバリーしてるよと。 ・Chefの話 DevOpsとか。 ・Obama for Americaの話 GitHubとか使ってた。 身に付けるべきものは？ 「変化に適応する力」が必要だよね。 最近は Ruby、クラウド、AWS、iOS開発とかやってる、どうしてこうなったｗ 先は予測してないけど、変化に適応するには5分でいいからやり続けること。 ◯@yusukeさんの発表 自己紹介が難しい ・今やってること ブログ執筆 刺さるツイート研究 ソフトウェア販売代理店 思わぬ収穫。InDesign/Illustratorのスキル、ビジネスの仕方ｗ 会社設立中。 Webサイト構築・運用 ・ハッタリが大事 ・プログラム好き プログラミング以外を仕事にしてる。 ・人と違うことがしたい。市場がない場所での差別化はしない＝トレンドに逆行し過ぎない。バランス。 ・今は種まき中。 ◯ディスカッション ・2,3年後とか何やってると思いますか？ @naoya_itoさん ドラクエやってると思ってるかもしれませんが、サービス作るコード書いてます。 将来的な見通しでやってるのか？って言われるとそうでもない。 ツールとかよりは、コミュニティとかのサービスを作るほうが好き。 @yusuke 一定の収入がありつつ、プログラミングしてたい。あわよくばサービス作ったのが当たるといいなぁ ・そもそもフリーランスをどう捉えているか？ @naoya_ito いいところ。自由に自分の時間をコントロールできる。 悪いところ。自分でコントロールしないといけない。 自分をコントロールしないと厳しい。 フリーになってわかったのは、会社は人間を働かせるための仕組みをよく考えて出来てる。 フリーでいいのは、選択した結果に自分が責任を持つというのがいい。 @yusuke セフルマネージメントできたほうがいい。 しがらみを捨てるためにフリーになるのはおすすめしない。 ・情報発信を継続してるけど、必要なことか？ @naoya_ito 必要とは思わないけど、みんな書いたらいいと思う。 検索すれば自分が助かるからｗ セルフブランディングのために重要？かなぁ。あまりそれが唯一の方法ではないと思う。 @yusuke 発信することで、何に興味を持ってるかをわかってもらえるから、便利かな。 ブログに残したほうがググって引っかかるよと。 ・技術の方向性？見つけ方？は？ @naoya_ito 直近は、クラウド流行るしiOSはまだ伸びてるしと。 そっから先はどうするの？ わからないよね。じゃあ、どうするの？って変化に対応してボトムアップで見つけてくのがいいんじゃないかなぁ。 人がやってないところを先にやらないと武器にならないけど、どうやって見つけるのか？ プログラミングやってる時に、その先に必要なこととか、気付きがあるので、手を動かさないとだめだよねと。 @yusuke トレンドを追いかけつつ、知ったかぶりするのは重要 ある程度ハッタリ＋手を動かす ","date":1363692480,"dir":"post/2013/","id":"5412fb82160d0f6093e4b6670f505c13","lang":"ja","lastmod":1363692480,"permalink":"https://blog.johtani.info/blog/2013/03/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass%E7%AB%B9%E6%A9%8B--vol1-%E3%82%B9%E3%83%9E%E3%83%9B%E6%99%82%E4%BB%A3%E5%88%B0%E6%9D%A5%E3%81%93%E3%81%AE%E5%85%88%E7%94%9F%E3%81%8D%E3%81%AE%E3%81%93%E3%82%8B%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%A8%E3%81%AF%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-tecomp/","publishdate":"2013-03-19T20:28:00+09:00","summary":"久々にブログ＋イベント参加です。 知り合いが開催＋出演したので参加してみました。 「スマホ」ってキーワードはあまりなかったけど、面白かったです。","tags":["勉強会"],"title":"エンジニアのためのスキルアップ勉強会『Tech Compass』＠竹橋 ― Vol1 「スマホ時代到来、この先生きのこるエンジニアとは！？」に参加しました。#tecomp(Jugemより移植)"},{"contents":"技術ブログから離れていってますが。。。 Xperia Zを購入しました。\n前に使っていたのはXperia arcになります。 もうすぐ２年だったのですが、容量不足に悩まされていたため＋芸の肥やし（仕事の足し）という名目で Xperia Zの購入に踏み切りました。 予約しての購入です。\nいくつか戸惑いなどを感じているので備忘録としてブログに残しておきます。 サイズが大きい___ まぁ、わかっていたことですが、5インチと大きいです。 ステータスバーを表示するのがちょっときついくらいです。 私は手が大きい方なのですがそれでもキツイので、普通の人は両手じゃないと厳しいんじゃないかと。。。 一応、ステータスバーを表示するためのアプリなんかもあるようなので、その辺を検討するのもいいかなぁと（まだインストールもしてませんが。） また、Angry Birdを演ってびっくりしたのですが、解像度が大きいため、startボタンなどが小さくて押しづらいですｗ\n移行がめんどくさい___ iPadも持っていて、ソレと比較するとひどくめんどくさかったです。 実は方法を知らないだけかもしれないんですが。。。 iPadだと、初期化したりしてもiTunesにインストールしたアプリなども覚えていてくれます。 ですので、すぐに同じ環境が出来上がります。 Xperiaに関しては、arcでインストールしてたアプリをインストール履歴を元に一つずつインストールして、 それぞれのアプリやアカウントを設定して行きました。 これが結構面倒で、まだ完全にはアプリがインストールできてないかも（他にも新しいものを入れたいなぁと思いつつ、探す手間を惜しんでます。。。おすすめアプリお待ちしてます。）\nZite、Angry Bird star warsがインストールできない___ Ziteは英語の勉強も兼ねて入れていたのですが、対応していないバージョンですと言われます。 AngryBirdもいっしょですね。 starwarsじゃない奴はインストールできたのですが、肝心のやってみたいstar warsがインストールできなくて。。。\nドコモアプリがいっぱい___ ドコモのアプリやプリインストールアプリがいっぱいあったので、どうしようか悩んでいます。 いくつかはアンインストールしました。HotpepperBeautyとか間違いなく使わないし SFA-QRというよくわからないアプリも入っていたのでこれまたアンインストールしました。\n通知に出さないアプリとか選択できない？___ 容量不足だったのも有り、TwitterクライアントにはTwiccaのみをインストールしていたのですが、今回はTwitter純正のクライアントもインストールしました。 お気に入り登録されたりといった状況も見れるので重宝するのですが、基本的にはtwiccaを使うつもりです。 ですが、通知バー（ステータスバー）に@ツイートが届いたなどといった通知は見なくてもいいと思っているんですが、なにか方法あるんでしょうか。\ndビデオが危険___ いわゆる携帯ショップで機種変更したため、いくつかのサービスに登録しないといけませんでした。 で、dビデオ（月額525円で映画とか見放題）に登録したので、せっかくだからと映画をダウンロードしてみたのですが、危険です。。。 ただでさえ、本読むのが遅かったり、コーディングしてないのにビデオ見ると更に時間ががが。。。 けど、面白くて。。。危険です。（スターシップ・トゥルーパーズ見ちゃいました。。）\nクレードルがもう一つほしい___ 防水なので、あまりキャップを開けたくないんです。 そして、dビデオとか見てるとやっぱり電池の減りがはやいんです。（ディスプレイが大きいのもあるのかなぁ。要らないサービス切るとかしないと） 結局、出先でも充電をしないといけなくて。 ただ、純正のクレードルが2100円と結構な値段でして。。。 あと、イヤホンを指すところもキャップがあるので、Bluetoothレシーバーも気になってたりします。 こちらも結構な値段でして。。。\nとまぁ、新しいものを手に入れて、色々悩んでますが、楽しいですね。購入したての色々と悩む時間がｗ おすすめアプリとかあったらコメントください\n","date":1360687980,"dir":"post/2013/","id":"b051fd352847c06e748b345e8ed0738b","lang":"ja","lastmod":1360687980,"permalink":"https://blog.johtani.info/blog/2013/02/13/xperia-z%E8%B2%B7%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2013-02-13T01:53:00+09:00","summary":"技術ブログから離れていってますが。。。 Xperia Zを購入しました。 前に使っていたのはXperia arcになります。 もうすぐ２年だったのですが、容量不","tags":["備忘録"],"title":"Xperia Z買いました(Jugemより移植)"},{"contents":"金曜日に引き続き、イベントに参加して来ました。（仕事。。。これも仕事だよ。）\n「Hadoop Conference Japan 2013 Winter」です。 普段、Hadoopを触るのも少ないのですが情報を仕入れときたいなぁということで。 今年はビッグサイトですよ。そろそろ無料のカンファレンスもキツイのではないでしょうか。。。 こちらの写真はセッション会場。今回もすごいです。。。 簡単ですが、聞いていた感想です。 全体的に、Hadoop本体の話ではなく、エコシステムと呼ばれる周辺のプロダクトの話や実際に運用している実例が増えていました。 だいぶ普及期に来たのかなぁと。そして、自分の不勉強を実感できたなぁと。 （あと、TreasureDataに絡む話が多いなぁと言うのも印象です。そういうセッションを選んで出ていたのかもしれませんが） 懇親会まで残っていたのですが、結構、すごい方たちの顔ぶれだなぁというのを今更ながらに実感するとか。 （ハチ象Tシャツを着ているすごい集団でもありましたが。。。）\n以下はいつものメモになります。だいぶ金曜日のイベント後で腑抜けてるのでメモが雑ですが。\n◯ご挨拶 Doug Cuttingさんのビデオ（あんまり聞けてない）　さすがのhamakenさんのトークの安定感。 後援はリクルートテクノロジーズさんが大半。 リクルートテクノロジーズの米谷さんが軽く発表 ◯LINEのHBaseを利用した大規模なメッセージストレージ：NHN Japan 中村 俊介 まずは、LINEの紹介が続く。 New Yearのメッセージは3倍位だったけど、何とかなっったよと。 データロスがない。 サーバ故障からのデータリカバリも自動でやってくれる 書き込み1ms、読み出し1-10msでできてる ・IDC onine migration クライアントベースで2つに書き込み Incremental replication（新データ）、BulkMigration（旧データ） 元のHBaseのレプリケータは利用してない（pushだったから。スループットコントロールしたかったから） ・NN failover 2012.10にNameNode障害発生 HA構成にしてたから問題が発生。 VIPはHDFSにつかうとリスキー 現在： 少ないダウンタイムを許容する ・Stabilizing LINE message cluster ※あとでHBase触るときに資料見直すくらいで。。。 Case1：Too many HLogs Case2：Hotspot問題 まぁ、けど1億ユーザのインフラとして使えるってすごいよな。。。　◯Hadoop meets Cloud with Multi-tenancy： Treasure Data 太田 一樹 TDもFluentdも有名だなぁ Hadoopのメンテナンスとか、つらいよねというのを見てきたのでTD作った ・なぜ、BigData+Cloud？ Hadoopだけみてもバージョンが混在してる＋ディストリビューターも多くなってる 十徳ナイフみたいになってきてるけど、必要なのはナタだよね。というのを提示するためにTD立ち上げた。 ・なぜCloud？ ・IaaSベンダーの対象としてるのはSCM。 オンプレだとHWが陳腐化してくよね→HWはクラウドが主流に ・PaaS、SaaSの対象は時は金なり バージョンアップとか大変だよねと ・TDのご紹介 唯一の解析用DBを目指して ・哲学とアーキテクチャ 解析とか運用をいかに楽にしていくかというのを主体においたサービスを提供したい？ いかに速くレポーティングシステムを簡単に構築していくかとかの話 簡単なインタフェースと目的に集中することで、価値を提供 ・AWSとの違いは？ ・アーキテクチャとか技術的な話 データを集める処理がデータ解析に実際には重要なフェーズ ・カラム指向でデータ保存 実装がどーなってるのかとか、TD内部のHadoopクラスタの運用、バージョンアップとかがどうなってるのかもきになる。（企業秘密だろうけど） ◯Amazon Elasti MapReduceとHadoopコミュニティの関わり：Amazon Web Services Peter Sirota ・３つのV Volume、Velocity、Variety ・yelpのAuto-suggestの例 カスタマーのレコメンデーションにElasticMapReduce使ってるよと。 ・razorfishの広告インプレッションの解析に使ってる ・Amazon.comでの話 AWS Public Datasetsの話 http://aws.amazon.com/jp/publicdatasets/ IonFluxのDNA解析の話 ・いろんな分野でのBig Data 事例がちらほら ※わかりやすい英語なんだけど寝不足が。。。 ◯ランチ！ サンドイッチと豚汁とあとなんとかライス。 TDブースにて、fluentdのTシャツもらったよ！ ◯Hadoop\u0026#39;s Power to Transform Business：MapR　Ted Dunning ・Mahaut＋Solrの単語が。8時間のレコメンデーションデータの作成が3分に？？ ・Stormにてリアルタイム処理と連携。バッチ処理はMRで。 ・バッチ処理とリアルタイム処理の間としてのDrill ・Drillの概観とできるところの話。 （あとでスライドで）データ解析のために機会学習の処理とかも投げられそう。 Q：ImplaraとDrillの違いは？ コミュニティベースかなどが違うよね（あまり聞き取れず） Q：Drillの開発はどのくらいすすんでるの？ A：。。。 Q.クエリ言語としてSQLがいいの？ A.No。というのも、単独の言語ですべてにベストというのはないから。SQLはわかりやすくて良いが、実行が非効率な場面も。 ◯Introduction to Impala～Hadoop用のSQLエンジン～：Cloudera　川崎 達夫 ・Impalaとは 分析に特化した低レイテンシクエリ実行基盤 Apacheライセンス バッチ処理要ではなく、データサイエンティストが試行錯誤するときに利用するのを想定 パフォーマンスが良い 実行エンジンはC＋＋とかで実装されてる MapReduceに依存してない ・MapReduceの問題点 MR直接は難しい→Hiveとか、M/Rの実装を隠して使いやすくするものが増えてきた Hiveを例に説明。MRがベースなので高レイテンシ ・Impalaのアーキテクチャ 機能制限やGA版について言及されてる資料なのが良い ・GA以降の話もあり ピンチヒッターなのに落ち着いて発表とか凄すぎです。 jdbcサポートも入ると。 プランナーはjava実装 Hiveとの互換性は？→完全互換を目指す。 開発のプロセスが見えにくいのでは？開発主体がcloudera ◯Flumeを活用したAmebaにおける大規模ログ収集システム：CyberAgent　飯島 賢志 立ち見。 Flumeのコミッターの人がCAにいたんだ。 ◯Log analysis system with Hadoop in livedoor 2013 Winter：NHN Japan　田籠さん@tagomorisさん ・NHNJapanのお話 ・Webサービスのログ解析について話していく 400+Webサービス ・2011年8月にLTしました。 ・1.5TB/day。。。 ・batchとstream Batch集計も重要だし、Stream処理も重要なので、ハイブリッドシステム ・システムーバービュー FluentdClusterを中心にして各種ツール、保存先に転送してる。 これが結構重要。だけど、今日はFluentdの話ではない ・Fluentd周りを一人でやってるのか。。。 ・処理の流れ ・ログの収集と、生ログ保存 ・パース（主にHive用に）、変換、フラグ追加（分類しておくとあとで集計したいとか、保存すべきかを処理可能に） ・Hiveにロード ・第1世代のはなし すべてbatch処理、Scribe 遅延が1時間ちょっとあるため、Hiveクエリで結果が見れないとか。 ・第2世代の話 Fluentdのstream処理にHadoop Streamingを呼び出せるようなプラグインを書いた Fluentd＋HoopServerの構成 ・第3世代 HoopをWebHDFS Fluentdでのオンライン集計 GrowthForcast、HRForcast ・第4世代（ここ1週間でやったこと） CDH4でQJMベースのNameNode（Failoverは手動） Hiveのスキーマを変更（これはブログに今度書くよ） とりあえず、現時点で改善点が思いつかない ・総括 HTTPベースでRPCベースにしたのでコンポーネント切り替えが結構楽 OSSで公開されてるからいいよね 公開することにより色々とドライブするよ！ ◯いかにしてHadoopにデータを集めるか：Treasure Data　古橋 貞之 ・自己紹介 ・ビッグデータ収集の問題点 ・壊れたデータが入ってる ・読み書きの時間がかかる ログはサブケースである。メインはサービスとかだから。 ・トライ＆エラー処理が時間かかる ・データを分割するのが基本的なアイデア 失敗した時のリトライが楽になる。さらに、それをStream処理すれば良いよねと。 ・flumeのお話 ・fluentdのお話 バッファリングは性能アップも兼ねてる 設定のクラスタへの伝搬とかインストールはpuppetとか使おうねと。 プラグインのインストールが楽 ・いくつかのプラグインの紹介 ・TDへのデータ投入のお話 ・最後にmuddydixonさんのプラグインの宣伝がw ◯Hadoopの次に考える分散システム技術：Microsoft　萩原 正義 ・CAP定理の克服をどうしていくか ・CAPのおさらい ・Lease クライアント主導、サーバ手動とか （理論重視の話で最後のセッションには辛かった。。。頭が疲れててついていけませんでした） おまけ 今回頂いたノベルティなどを写真に撮ってみました。（ランチはお腹すいてて写真取らずに食べちゃいました。。。） Hiveロゴへの愛を語ってHive Tシャツをゲット。 FluentdのTシャツももらいました！ Hiveステッカーなどもゲット あと、メッセージボードなるものがあったので書いてみました。一応、Hadoopに絡んだことですよね！？\n","date":1358783400,"dir":"post/2013/","id":"bf4f86812812dab8d39db9aaefe94a78","lang":"ja","lastmod":1358783400,"permalink":"https://blog.johtani.info/blog/2013/01/22/hadoop-conference-japan-2013-winter%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hcj13w/","publishdate":"2013-01-22T00:50:00+09:00","summary":"金曜日に引き続き、イベントに参加して来ました。（仕事。。。これも仕事だよ。） 「Hadoop Conference Japan 2013 Winter」です。 普段、Hadoopを触る","tags":["勉強会"],"title":"Hadoop Conference Japan 2013 Winterに参加しました。#hcj13w(Jugemより移植)"},{"contents":"1/18（金）に開催された、エンジニアサポートCROSS 2013で「検索CROSS」セッションのセッションオーナー（モデレータ）をやって来ました。\n@muddydixonさんに昨年の夏くらいに声をかけていただいたのがきっかけです。 こういったイベントの運営のお手伝い（ほとんど何もしてない）も初めてでしたし、セッションオーナー（モデレータ）も初めての経験で色々といい勉強をさせて頂きました（自分の足りない所とか、考慮すべき点がどういったところにあるとか）。本当にありがとうございます。\nスピーカーとして登壇していただいた久保田さん、佐藤さん、安田さんほんとうにありがとうございました。 頼りないオーナーで、モヤッとした内容を提示したにもかかわらず、意図を汲み取って話の内容をふくらませていただいてすごく助かりました。 また、会場にお越しいただいたみなさん、ありがとうございました。すこしでも検索に興味をもっていただければ、セッションは成功だったと思っています。 朝一だったのと、私の認知度の低さもあったのとで残念ながら満席とはいきませんでしたが。。。\n後日、録画されたセッションの内容を見て色々と反省しようかなぁと。。。 緊張していたので、うまくモデレートできてたのか、話ができていたのか不安ですが。 忌憚ない感想をお待ちしています。\nということで、反省終わり！ここからは、イベントの感想と聞いたセッションに関する感想です。\n###聞いたセッション\n####企業CROSS DeNA x グリー x Aiming： 大企業・ベンチャーが語る「スクラム」開発 (仮)\nGoogleの及川さん見たさで参加しました。 スクラム自体は名前くらいは聞いたことある程度だったのですが、その程度の私でもわかりやすいディスカッションで楽しかったです。 聞いていて感じたのは、次のようなこと。\n「スクラム」という開発手法の話しなんだけど目的はそこじゃなくて、どうやってうまくプロジェクトを回して（ドライブして）、目的（サービスを作るとか顧客の要望を叶えるとか）を達成するかというのが重要だなぁと。 「スクラムマスター」の仕事は子育てに似てる 「スクラムマスター」になりたい人はなかなかいないらしい 「スクラムマスター」の人は、俯瞰してプロジェクト全体を見渡して落穂拾いをしていく人なのかもなぁと 個人的には「スクラムマスター」の仕事がちょっとおもしろそうと思いました。（いつもいろんなことを面白そうと思う自分なのでなんともいえないですが。。。）\n####データ理解を助けるビジュアライゼーション\n昨年からビジュアライゼーションには興味だけ（実践とかできてない）は持っていたので、参加しました。 スピーカーの方々の対立軸がはっきりしていたのが面白かったかと。 聞いていて感じたのは、次のようなこと\nビジネスの視点からのビジュアライゼーションはコスパがどうなのかというのがまだ不明 可視化できたらおしまいじゃなくて、お金につながる可視化に心がけるのが重要そう 可視化して楽しむのも有りだとは思うけど、それは趣味だったり芸術の話かもなぁ 異なるコンテキストの人にでも誤解を与えない可視化というのが重要 何をどう可視化するかというのが実は統計学知ってると必要ないこともある 基本的にはCAの方の内容が一番しっくり来ました。やっぱりビジネス的な視点と学術的な視点は違うのかもなぁと。\n####継続的システム運用のゲンバのハナシ\n面白かったです。のっけから燃料がテーブルにならんでるしｗ 運用とかインフラはそこまで詳しくないのですが、少しは作業したりするので気になってましたが、ぶっ飛んだ話が聞けて楽しめました。 聞いていて感じたのは、次のようなこと\nサービス内容によっては夜中にアクセス数が低いものもある（cookpadは夜中はアクセス数が低い） アプリを修正することでインフラを楽にするという考えもある インフラエンジニアは実はリア充 cookpad面白い人多いw このあとは、おまちかねのプレモルタイムだったので、プレモル片手（失礼だろｗ）にTech10の池本さんに挨拶してきました。（Solr本のときはお世話になりました！） あとは、RedBull片手に知り合いの方々（Twitter上のみやいつもお世話になってる人）に挨拶をして回ってました。（プレモルも美味しかったのですが、プレモルおつまみも美味しかったです！） また、ちょっとつかれて座るために入った「体系的に学ぶ安全な利用規約の作り方」でも、面白い話を聞けました。 （利用規約をきちんと考えて変更している企業のほうが炎上をしてしまうとか無駄だしおかしいよねとか）\nイベント終了まで、会場にいて（いただけで大した手伝いしてないです、すみません。）その後打ち上げに向かって楽しみました。\n####さいごは、イベント通じて感じたことと気になったこと。（若干、意図的なものが入り込んでますが。。。）\n題材にもなってる「CROSS」ですが、ここ数年特に、エンジニアとして複数の技術や考えなどを身につけないといけないなぁと 有名人に会える！（ミーハーです。。。） プレモル美味しい！（いつも飲んでるビールが「え？」って思った） ケンタッキー美味しい！ RedBull美味しい！ いろんな技術分野に触れられる機会ができそう Wi-fiは用意してもらえると助かる。（参加者の方々が一斉にLTEとかでつなごうとするのでみんなが繋がらなくなってツイートされないとかちょっとつらいかも） 各会場が覗けるようになってたのは良かった（ただ、会場の後ろの人はざわつきを感じるためスピーカーの声が聴こえないことも） スクリーンはもう少し高い位置にあると良かった（後ろに座ると下のほうが見えないことも） 飲食の配布は会場内でできたほうが良かったのかも（NGなのかな？）。プレモルやRedBullは配ってくれたので良かったのだが、食べ物を取りに行くために入口付近が混雑してた気がした。 （これで、メッキ剥がれたかなぁ） 会場入り口の写真とか撮ってくるんだった。。。 ということで、総じて楽しかったので来年もあるならまた、手伝いたいです！\nおまけ\nプレモル！ Amebaウォーター プレモル＋プレモルおつまみ＋RedBull いただいたスタッフTシャツとプレモル！\n","date":1358600940,"dir":"post/2013/","id":"322264a17ef7182eb1475bd2eaebc2eb","lang":"ja","lastmod":1358600940,"permalink":"https://blog.johtani.info/blog/2013/01/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88cross-2013%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%8A%E6%89%8B%E4%BC%9D%E3%81%84%E3%83%A2%E3%83%87%E3%83%AC%E3%83%BC%E3%82%BF%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--cross2013/","publishdate":"2013-01-19T22:09:00+09:00","summary":"1/18（金）に開催された、エンジニアサポートCROSS 2013で「検索CROSS」セッションのセッションオーナー（モデレータ）をやって来ま","tags":["勉強会"],"title":"エンジニアサポートCROSS 2013に参加（＋お手伝い＋モデレータ）しました #cross2013(Jugemより移植)"},{"contents":"いまさら感満載ですが、今週の金曜日(1/18)に開催されるCROSS 2013というイベントで「検索CROSS」のセッションを担当することになってます。\nここ数年、検索に携わっていますが、検索は色々な技術の組み合わせ（検索用インデックス、自然言語処理、機械学習などなど）でなりったていて奥が深いなぁと感じる毎日です。 そこで、実際のサービスで検索をやられている方、検索プラットフォーム製品を開発している方、自然言語処理や検索に長けた方を招いてつぎのような話をしてもらおうかと。\n・現在の事例（検索とその周辺技術） ・今後の検索にクロスすると面白い技術\nがっつり検索をやられている方々に登壇していただきますので、検索に興味のある方はぜひ、ご参加を！ 登壇者の方々についてはこちらを御覧ください。\n検索CROSS以外にも楽しみなセッションが多数ありますので、参加をご検討いただければと。 あと、実はこっちがメインなのですが、夕方からのプレモルタイムも期待できるのでこちらへの参加だけでもぜひ！！\n","date":1358267340,"dir":"post/2013/","id":"20110c8f8da8304b6d9d3c2845a38128","lang":"ja","lastmod":1358267340,"permalink":"https://blog.johtani.info/blog/2013/01/16/%E3%81%84%E3%81%BE%E3%81%95%E3%82%89%E3%81%A7%E3%81%99%E3%81%8Ccross-2013%E3%81%A7%E6%A4%9C%E7%B4%A2cross%E3%81%A8%E3%81%84%E3%81%86%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E6%8B%85%E5%BD%93%E3%81%97%E3%81%BE%E3%81%99/","publishdate":"2013-01-16T01:29:00+09:00","summary":"いまさら感満載ですが、今週の金曜日(1/18)に開催されるCROSS 2013というイベントで「検索CROSS」のセッションを担当することにな","tags":["勉強会"],"title":"いまさらですが、CROSS 2013で検索CROSSというセッションを担当します(Jugemより移植)"},{"contents":"年末から年始にかけて、「コード・シンプリシティ」を読みました。\n先日の記事にも書きましたが、Kindle paperwhiteを思いかけず入手できたので、eBookを読みたいなぁと思いまして。 Kindleのお試しも兼ねて読んでみました。\nまずは、本の感想。 短めの書籍＋読み物なので、サクっと読めました。 題名に「コード」と書かれていますが、コードの実例が出てくる書籍ではありません。 「ソフトウェア」を以下にシンプルに保って、管理しやすくするか、機能追加、テストをやりやすくするかといった指針について書かれています。 機能追加に関して検討しないといけないバランス（先読みしすぎずと実装しすぎないとか）の話や定期的なデザインの見直しなどについても書かれています。 ソフトウェアに関しては動くこともだが、デザインが重要であること。（確かに。） すでにあるソフトウェアについて、どのように簡潔にしていくかという話もありました。 ただ、読んでいて一番重要だと思ったのは、「悪いプログラマーと良いプログラマーの違いは理解力だ」という一文です。 何をしているかを「理解」していないと、根本的な問題点の解決もできないですし、どうすればコードが簡潔になるかといったこともわからないです。 また、やっている作業がどんなもので、何のためにやっているのか、それを行うことで今後にどのような影響があるのかといったことも理解しておく必要があるかと。 ま、ある程度考えながら作業とかしましょうってことですかね。（強引なまとめかも。。。）\nで本題です。 Kindle paperwhiteとiPadの使い分けを検討するのも兼ねて本を読んでました。 iPadを持っているのもあり、Kindleはそもそも眼中になかったのですが、めっけ物でした。 やはり実際に使ってみないとわからないことありますねぇと。 paperwihteはつぎのような利点があるかと。\n読書に没頭できる。→本を読むというシンプルな目的を達成するものだけが実装されている 目が疲れない→Twitterでも話に上がったのですが、液晶とは異なり字が読みやすいです 軽いし小さい→電車で立っていても楽に持てるし、カバンからの出し入れも楽です（iPadに比べて） 複数の端末のKindleアプリで同期できる。→あまり異なる端末では読まないですが、paperwhiteで読んだところが、iPadでも同期されるのですんなり続きが読めます 電池長持ち ということで、本を読むのに没頭できるし目が疲れないと。 ただ、つぎの点では不満もあります。\nPDFは読みにくい。→画面のサイズが小さいので大きめの書籍のPDF版は読みにくいです。 PDFは読みにくい。→文字のサイズを変更できないのもキツイです。Kindle専用のmobi形式の書籍が読みやすいです ページめくりに一定時間がかかる→紙の書籍やiPadで書籍を読むのとは異なり、ページをめくるのに時間がかかります。e-inkの再描画の問題かと。パラパラと書籍を読みたい場合は厳しいです 白黒。カラーの電子書籍は読めないですねぇ ソースコードなどもキツイ→長めのコードが書いてある本だとコードが頭に入ってこないです。。。 という感想でした。 今後は基本Kindle paperwhiteを持ち歩きmobi形式の本を読むようにすると思います。 iPadは自炊本やカラーの本を読むとき、映像、ネットを見るような場合に持ち歩くことになりそうです。 私は基本的にMBAを持ち歩いているというのもあるので、paperwhiteのほうが主流になりそうです。 ネットを見るときなどは最悪、MBAを開くでしょうし。 小説とかをメインに読むのであれば断然、paperwhiteだと思います（最近読んでないなぁ）\n","date":1357658880,"dir":"post/2013/","id":"992a00c30242b6217243f3c387ea18b7","lang":"ja","lastmod":1357658880,"permalink":"https://blog.johtani.info/blog/2013/01/09/%E3%82%B3%E3%83%BC%E3%83%89%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AA%E3%82%B7%E3%83%86%E3%82%A3%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9Fkindle-paperwhite%E3%81%AE%E4%BD%BF%E3%81%84%E5%8B%9D%E6%89%8B%E3%81%AE%E7%A2%BA%E8%AA%8D%E3%82%82%E5%85%BC%E3%81%AD%E3%81%A6/","publishdate":"2013-01-09T00:28:00+09:00","summary":"年末から年始にかけて、「コード・シンプリシティ」を読みました。 先日の記事にも書きましたが、Kindle paperwhiteを思いかけず入手で","tags":["読書"],"title":"「コード・シンプリシティ」を読みました。（Kindle paperwhiteの使い勝手の確認も兼ねて）(Jugemより移植)"},{"contents":"書こうと思いながら、気づいたら大晦日。 よくないですね、思いついた時に書かないと。\n昨年も書いたので、昨年書いた抱負から振り返りをと。\nMongoDB触ってみる Scala触ってみる なんかWebサービス作ってみる（Amazonとかで） elasticsearch、IndexTankを調べてみる NewSolrCloudDesignを読み込んで自分なりにまとめる Junsaiに参加する 「7つの言語7つの世界」の続き えーと。。。できてないことばかりですねｗ MongoDBはインストールすらしてないですし、Webサービスも作ってないです。（さくらVPSは借りたんですが） Junsaiは参加したけど何もできてないし。7つの言語もそのままですね。。。 SolrCloudDesignはまとめられてないですしね。 Scalaは少しだけ触りました。結局Javaみたいな記述をしてしまうという良くないくせが出てしまうので、 見送ってしまいましたが。。。 elasticsearchは少しだけやりました。#pyfesで話をさせて貰える機会があったので。\n興味がコロコロ変わってしまうのが問題点かもしれないです。少しは地に足をつけてなんかやったほうがいいのになぁ\n###今年の振り返り 今年はこんなかんじでしょうか。\nいろんな勉強会に出没 #pyfesでelasticsearchのさわりを紹介 個人的にJIRA導入 MIR輪読会開始 Solr勉強会の主催を引き継ぐ Kindle paperwhite当たった 相変わらずいろんな勉強会に出てました。最近は勉強しに行くのもありますが、人に会いに行ってるような気がします。 勉強会から帰ってきて復習したりしないとすぐ忘れちゃうんですよね。。。\n#pyfesではelasticsearchの入門中という話をしてきました。 人の多さに緊張しまくりでよくわかりにくい発表になってしまったのが反省点かと。。。 もっと話をする機会を増やすとなれるのでしょうか。\nJIRAの導入はパラで仕事をしているとタスク管理がおろそかになってくるので導入しました。 フリーのredmineを考えていたのですが、インストールが簡単なJIRAを導入しました。 有料ですが、1-10人までなら、ダウンロード版が$10ですし。いろんな時間を買ったと考えると安いかと\n検索に関してもまだまだ初心者に近いということでModern Information Retrievalという英語の本の輪読を主催しました。 Twitterでの呼びかけに答えてくれた方々に感謝です。 まだ、半分も行ってないですが、何周かしたいと思っています。\nSolr勉強会の主催者も引き継ぎました。Atnd立てるの手伝おうか？って言ったら主催者になってましたｗ 来年も開催するので、喋りたい方、こんな話を聞きたいなどTwitterやブログでコンタクトいただければと。\nあと、会社の忘年会で思いがけずKindle paperwhiteが当たりました！（やったー！） iPadを持っていることもあり、完全に購入する気も無かったのですが。。。 使ってみると結構いいです。画面のギラツキがないのと、他のソフトがないのがいいです。 読書に没頭できます。通常はKindleを持ち歩くことになるかと。（没頭できるけど、読むスピードが遅い＋すぐ忘れるのが難点。。。）\n###来年の抱負 来年の抱負も書いておきます。 昨年の前科があるのでどこまでできるかわかりませんが。 すぐに興味が変わってしまうのもありますし\nIntelliJ IDEAをメインに使う JIRAを継続して活用 ブログの継続 elasticsearch Luceneのソースコードリーディング 何かOSSのソースを読む Macでもっと開発 読書と英語を継続 IDEA（アイデア）は11をインストールしてたのですが、使えていませんでした。 イメケンが主催したJetBrainsユーザー会で洗脳されて＋タイミング良い75%オフセールにやられて購入しました。 普段はEclipseを使っているのですが、これを機にチャレンジしようかと。 少し変化をしてかないとすぐ取り残されちゃうので。。。\nJIRAはまだタスクを登録してクローズするという初歩段階の使い方しかできてないので、少しずつ研究してフィールド追加したり、ワークフローを変更してみたりと研究したいです。\nブログは、今年後半が勉強会参加ブログしかないのを反省して来年は、もう少しSolrやLucene、lucene-gosenについて書いて行きたいです。 （すくなくとも、4.0で動かす話を書かないと。。。）\nelasticsearchはまぁ触れる環境を維持しようという話です。 どこかで導入できればいいんでしょうが、なかなか。 （勉強会開いてみるのも面白いかな？）\nLuceneソースコードリーディングは誘われてるのに、ちゃんと返事をしていなかったので。 来年2月のどこかの土日を候補日にする予定です。\n何かOSSのソースも読もうと思ってます。 「何か」はまだ決めてないですが、人のソースを実はあまり読んでないなぁと。 Vさんと話をした時に人のソースを読むのがいいですよという話になったので。 真似をするためにもなんか読みたいなぁと。Javaになるのかなぁ。\nとある事情で週4はWindowsで開発してます。 Macはちょっとしか触ってないのでMacの環境が成長していないのが難点です。 できれば、Macで開発を継続できる環境を作りたいなぁと。Kobitoとか入れてるけど触ってないし。。。 IntelliJも入れたのでMacで開発したいものです。\n最後は毎年のことですが、本を読むスピードが買うスピードに追いついてないと。。。 英語の本もかってるんですが、これまた読むスピードが。。。 ということで、ざっくり目を通す読書をもっとやりたいなぁと。 買うのはいいのですが、必要にならないと呼んだ内容を忘れてしまうので、読んだあとに実践する機会も設けたいと思ってます（思ってるだけかもしれないですが）\nあと、来年もいろんな人に会うためにいろんな勉強会に出没すると思いますので、声をかけていただければと また、不抜けているのを見かけたらカツを入れてください。（技術内容のブログ書けとか、本読んだ感想をブログにかけとか） 来年もTwitterなどで絡みまくると思いますが、よろしくです。\n","date":1356908460,"dir":"post/2012/","id":"4c08b67e0c1fdeef50b1fdcc32cdcee2","lang":"ja","lastmod":1356908460,"permalink":"https://blog.johtani.info/blog/2012/12/31/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A02012/","publishdate":"2012-12-31T08:01:00+09:00","summary":"書こうと思いながら、気づいたら大晦日。 よくないですね、思いついた時に書かないと。 昨年も書いたので、昨年書いた抱負から振り返りをと。 Mongo","tags":["備忘録"],"title":"今年の振り返りと来年の抱負（2012）(Jugemより移植)"},{"contents":"Atlassian Advent Calendar 2012の20日目。（急遽参戦） （某イケメンにMT（改変リツイート）されたので書いてみました） 久々に、勉強会以外のエントリです。（Solrとかlucene-gosenじゃないんだが。。。）\n私は、最近忘れっぽくなってきてしまったので、さくらVPSを借りてJIRAを立てて、タスク管理とかに使い始めました。 有料ツールなので、まずは、評価版から入れましたと。 評価版をインストールするときに、楽なのでHSQLDBを選択していました。が、 インストール時に「HSQLDBは評価版だけで使用してください。正式版ではサポートしてないです」みたいなことを言われていたので、PostgreSQLに切り替えようかと。 ちなみに、MySQLも選択肢としてはあったのですが、PostgreSQLのほうが触ってるし（つかいこなせてるわけではない）、補完機能になれてるというのもありPostgreSQLを選んでみました。\n作業のログとして、ブログ書いとこうと思いたったのでメモ的に残しておきます。\n作業の流れはこんなかんじでした。 （基本的にはサポートサイトのここに載ってます。サポートいいね。） この手順通りでいいみたい。\n###1. JIRAのデータのバックアップ（JIRAの管理画面からバックアップ）\nまずは管理画面へ。ページ右上に管理へのリンクがあるのでクリック。 開いた管理画面の右下あたりにエクスポート（バックアップ）へのリンクがあります。 クリックしたあとに、エクスポートのファイル指定画面が現れるので、ファイル名を指定してバックアップボタンを押します。 バックアップが完了するとバックアップファイルの場所が表示されます。 ###2. JIRAの停止\nバックアップが終わったのでJIRAを停止します。\n###3. PostgreSQLのインストール（yum） PostgreSQLが入ってないので、yum installします。（軟弱者なので）\nyum install postgresql-server ####initdbで四苦八苦 PostgreSQLはインストールしただけでは起動できません。なので、初期化をします。 yumでインストールしたPostgreSQLだとつぎのコマンドでinitdbできるようです。（これが罠でした）\nservice postgresql initdb このコマンドでinitdbすると、encodingが指定できませんでした。（私がしらないだけという話も。。。） encodingを指定できていないと、このあと4.を実行するときにエラーが出ました。（これも回避方法あるのかも。） ということで、結局、昔とった杵柄なやり方でinitdbコマンドで\u0026ndash;encoding=UTF8 \u0026ndash;no-localeを指定しました。\ninitdb --encoding=UTF8 --no-locale -D/var/lib/pgsql/data service postgresql start これで初期化が完了するので、PostgreSQLを起動します。\n###4. JIRA用DBとユーザの作成\nまずは、ユーザの作成。そして、DB作成\ncreateuser jirauser createdb -E UNICODE jiradb テーブルなど作成しません。あとの処理がやってくれます。\n###5. JIRAにJDBCドライバを入れる（必要なかった。）\nwarじゃないJIRAをインストールした場合はすでに入ってるみたいです。 ここを見るとわかります。JIRA Installation Directoryの下のlibですかね。\n/opt/atlassian/jira/lib ###6. マニュアルでPostgreSQLの接続設定（あれ、これいらないのか。）\n~~　コンソールオンリーなので、JIRAが提供してくれているツールが使えないため、手で設定。 /var/atlassian/application-data/jira にあるdbconfig.xmlを修正~~ ちゃんと英語読めってことですね。。。必要なかったです。。。\n###7. JIRAのdbconfig.xmlを削除\nDB接続の設定を初期セットアップウィザードで再設定するため、dbconfig.xmlを消します。 （一応、インストールディレクトリとホームディレクトリとかバックアップしたほうがいいみたい） 場所はここ。 中身はdbcpとかのデータソースの設定に似てました。 今は、HSQLDBのJDBCドライバが記載されてました。\nrm /var/atlassian/application-data/jira/dbconfig.xml ###8. JIRAの起動\n7.のファイルを消したあとにJIRAを起動します。\nservice jira start ###9. JIRAにアクセスとDB接続設定\nアクセスすると、インストールした時と同じDB接続の指定を行うセットアップウィザードの画面が現れます。 今回はJIRAサーバの外にあるPostgreSQLなので、「外部」を選んで四角で囲んだ部分を入力します。 入力したら、「接続テスト」を押して接続できることを確認したら「次へ」を押します。 マシンのスペックにもよると思いますが、ここでJIRAサーバがDBに接続してテーブルのCREATEなどDBのセットアップを実行してるのでちょっと時間がかかります。\n###10. バックアップしたデータのインポート\nDBのセットアップが終わったら、アプリケーションのセットアップ画面が出てきます。 新規インストールではないので、「ここ」にある「既存のデータをインポート」リンクをクリックします。 すると、インポートファイルの指定画面が現れるので、1.でバックアップしたファイル名を指定してインポートします。 すると、インポート中画面が出てきます。 で、インポートが完了すると無事JIRAにログインできますと。\nとこんなかんじです。 私の場合は、まだJIRAをインストールしてから間もないため、チケットの数が少なかったり、添付ファイルが無かったりなので、すぐにインポートが完了しました。 添付ファイルがある場合は、別途添付ファイルが保存されているディレクトリのバックアップと復旧などもあるみたいです。 最初にも書きましたが、ドキュメントのサイトに「Switching Databases」という項目があり、そのページの手順で問題なく切り替えできました。 次は、定期的にデータをバックアップするのを考えないとですかね。\nいやぁブログ書くのが、思いの外、手こずりました。 手こずった原因はスクリーンショットだったんですけどね。。。 safariでページ全体のスクリーンショットがとれなかったので、結局ChromeでAwesome Screenshotプラグイン使いました。 safariの拡張もあるんですが、ページ全体のスクリーンショットがうまく動かないみたいです。。。 ということで、備忘録でした。（次はちゃんとSolrとかの記事書かないとなー。その前に忘年ブログかな）\n","date":1356002280,"dir":"post/2012/","id":"4a30eeb083acec8460150068ba0c6743","lang":"ja","lastmod":1356002280,"permalink":"https://blog.johtani.info/blog/2012/12/20/jira%E3%81%AEdb%E7%A7%BB%E8%A1%8Chsqldb%E3%81%8B%E3%82%89postgresql%E3%81%B8-augj/","publishdate":"2012-12-20T20:18:00+09:00","summary":"Atlassian Advent Calendar 2012の20日目。（急遽参戦） （某イケメンにMT（改変リツイート）されたので書いてみました） 久々に、勉強会以外のエントリです。（So","tags":["JIRA"],"title":"JIRAのDB移行（HSQLDBからPostgreSQLへ）#augj(Jugemより移植)"},{"contents":"イケメンが主催した「第一回 JetBrainsユーザーグループ #jbugj」に参加してきました。\nいろんな製品があるんだなぁと。入り口には良いイベントだったと思います。 個人的に、WebStorm、IntelliJが気になっていたので、参加しました。（あとは、イケメンがやってるイベントだからというのもあるかも） ちなみに、MBAにしてからインストールはしていたのですが、ほぼ触っていなかったのでこれを機会にちょっと触ってみようかなぁと。\n発表は、全般的な製品紹介、ライセンスの紹介から、ライブコーディングあり、ここがいいよ！という話ありという感じでした。\nMTLさんのおしゃれな空間で発表を聞いたので、いつもとは少し違った感じでしたでしょうか。\n私自身は、発表を聞きつつ、IDEAのCEで色々やってました。 一応、Lucene/SolrのSVNからチェックアウトしたり、lucene-gosenのtrunkをチェックアウトしたり、個人のbitbucketからlucene-gosen-wikiparseとかcloneしてました。 Eclipseで作ったプロジェクトなので、cloneとかチェックアウトしたあとに、Eclipseと並行開発するとどうなるのかなぁ？というのがちょっと気になります。（普通は移行しておしまいなんだろうけど。。。） ちなみに、lucene-gosenのプロジェクトもSVNからチェックアウトしたらすんなり使えそうでした。 こんな感じ。（lucene-gosenのプロジェクト） とりあえず、見た目がカッコイイｗ\nいくつか触ったり、聞いていて気になったのはつぎのような点です。ちょっとずつ触る機会を作った時に調べてみようかなぁと\nEclipseのワーキングセット相当の機能はどうするのか？→モジュールとかでやればいいらしい。 プラグインってどんなものがあるの？探す方法とインストールの仕方 JDKの複数の切り替え方とか Eclipseでやってる人とIntelliJでやってる人の混在チームでの開発とか で、いつものごとく、懇親会に参加しました。 @mike_neckさんや@sue445さんとお話できたのですが、VCSにEclipseの設定ファイルとか挙げないほうがいいですよねとか、テストが無いプロジェクトってないわーなどの話を聞いて、やっぱり自分はまだまだなんだなぁと認識できるとか面白かったです。 lucene-gosenのSVNにはEclipseの設定ファイルとかアップされてるからなぁ。ホントはAntとかMavenのターゲットでこれらの設定ファイルができるようにしとくのがいいんでしょうねぇ。 まだまだ勉強することだらけですが、コツコツ教えてもらいます\nちなみに、イベント参加者にはショートカットキーが印字されたキートップシールや2ヶ月有効な評価ライセンスがあとからもらえるなどの特典もありました。 普段はEclipseなのですが、運良くライセンスが当たったら本気で乗り換えようかなぁｗ\nちなみに、Eclipseでもそうですが、私自身はショートカットキーをほとんど覚えてない軟弱者ですので、メニューの場所などを覚えれば乗り換え自体はこんなんじゃないかと。 Mac自体にKeyRemap４MacBookを入れていて、Emacsっぽいショートカットを使うので、覚えられないというのもありますが。 ライセンス当たらないかなぁー\n以下はいつもの通り、聴きながら自分用にメモしたものになります。\n日時：2012/12/11（火）19:00-21:00 場所：メディアテクノロジーラボ イベントサイト：http://www.zusaar.com/event/450003\n◎JetBrains製品群、ライセンス形態などの紹介 - @yusuke ・日本でヤル気あるの！？→あるある！→じゃあ、ユーザグループ立ち上げるぜー ・あくまで情報交換の場を設けるだけ。 ・アンケート結果 IntelliJが1番人気 WebStromが2番 ・ステッカー（ちょっとかっこ悪いかも。。。） ・2名限定でIDEAのライセンスプレゼント！ ブログ書いて、応募用フォームに登録してランダム抽選 ◎IntelliJの基本(インストール～プロジェクト作成、テスト、実行までのウォークスルー) @yusuke ・JetBRAINSはチェコの会社 ・IntelliJはなんでもできる（AppCodeは違うけど） ・.Net系もある（書きそびれた） ・YouTrack：課題追跡 ・TeamCity：継続インテグレーション ・読み方は「イデア」じゃなくて「アイデア」だよ！ ・Community Editionはあんまり機能がない。 OSSライセンスだと、Ultimateの機能が使えるよと。 ・仙台の人が一人アドベント・カレンダーやってます。 http://d.hatena.ne.jp/masanobuimai/20121201\n・ライブデモ 黒いインタフェースにするのどーすんだろう？ →Preferences→AppearancesでThemeで「Darcula」を選択すると黒くなる。 ・やべ、時間過ぎてたｗ終わり！ ◎IntelliJのここが気持ちいい！→普通IntelliJでしょ？ @mike_neck ・DQXやってます。 ・僕とeclipse ・新規クラス作成：3ステップかかる ・補完の素早さ： ・SprintFramework：Ultimateなら対応してるよ。 関係ないけど、TLで質問したので。 Eclipseのワーキング・セットに相当するもの。 http://d.hatena.ne.jp/masanobuimai/touch/20121024\n◎LT ◯WebStormとRubyMineについて @sue445 ・JavaScriptのIDEとして最強 jsの補完が素晴らしい。（外部のJSはプロジェクトに入れないと難しい。） jsTestDriver pluginがデフォルトで入ってる！ ・RubyMine RubyのIDE ソースを追うのが楽。 erbのインポートしたものも追っかけられるの便利。 viewからhelperクラスにも飛べる。 QA UMLとか出せるの？→出せるよ。 DBクライアントもあるよ。 ◎JetBrains発のJVM言語Kotlinの紹介 - @ngsw_taro アドベントカレンダー（一人）http://atnd.org/events/34627\n・社畜してます ・Androidアプリとか作ってる。 ・Kotlinな活動 Pull Requestしてる ・マイルストーンなど。 M4が3時間前に出た！ ・どんな言語？ 静的型付け、オブジェクト指向、関数型プログラミング的、JSへコンパイル可 産業利用目的（初めて聞いたかも、この言葉ｗ） ・Java大変だよね。 互換性問題とか ・ライブコーディング 大変そうだｗKUnitってのもあるらしい。 （ゴメンナサイ、IDEA触ってて、流してました。。。Eclipseで作ってたプロジェクトをBitbucketから落としてきて四苦八苦してた） （参考にしたサイト（ググった）：http://d.hatena.ne.jp/waman/20100506/1273166533）\n◎AppCodeについて ・IDEAには含まれないので、別途ラインセンス購入が必要。 ・XcodeとAppCodeの違いをライブコーディングで説明。 ・XCodeよりも補完が良くできてるっぽい。 GUIはXCodeで作って、コーディングはAppCodeでやるってのがいいですよ。 ※私が、iOS系のアプリの開発ってやったこと無いからよくわかってないです。。。 XCodeはコードフォーマットがないのが辛い by @yusuke ","date":1355228520,"dir":"post/2012/","id":"898d25a2ab9c0ba1fa9bad462405e475","lang":"ja","lastmod":1355228520,"permalink":"https://blog.johtani.info/blog/2012/12/11/%E7%AC%AC%E4%B8%80%E5%9B%9E-jetbrains%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97--jbugj-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-12-11T21:22:00+09:00","summary":"イケメンが主催した「第一回 JetBrainsユーザーグループ #jbugj」に参加してきました。 いろんな製品があるんだなぁと。入り口には良いイ","tags":["勉強会"],"title":"第一回 JetBrainsユーザーグループ #jbugj に参加してきました(Jugemより移植)"},{"contents":"ヒカリエに行ってみたいという不純な理由で参加してきました。 新しいということもあり、おしゃれで綺麗なカフェでした。 入り口にはおっきな人形も立ってたし。 渋谷の夜景も見下ろせて素敵な場所でした。\nで、内容です。残念ながら、本編の3回めには参加していなかったのですが、 今回も濃い話が聞けたので楽しかったです。 論文読まなかったり、基礎を勉強したのに忘れてたりと抜けてる部分が多いので、 こういう機会が与えてもらえるというだけで目からうろこです。\n@kumagiさんの「あなたの知らないハッシュテーブルの世界」はハッシュテーブルの基本的な話から、最近の論文で発表されてる内容までをカバーする幅広いお話で面白かったです。 （大学でやってると思うんだけどすっかり抜けてる自分がなんとも。。。） こういうコアな中身も知ってると、色々とプログラム書いたりするときの見方や考え方も変わってきますよね。 （そんなプログラム書いてないけど。。。） で、随分おとなしい内容だなぁ？と思いきや、途中からちゃんとLock-Freeの話も出てきてさすがと感心させられましたｗ 最後はJubatusの宣伝まで入ってたし。（某氏のすごい写真入りで。。。）\n@hitoshi_niさんの文書要約の話は、NLPに興味があるので、楽しみにしていた内容でした。 今回もなめらかによどみなく喋られる発表にただただ感心させられるばかりでした。 内容は中級編ということで、文書要約のキモになる処理の文章の短縮の話です。 係り受け木を元にする手法をわかりやすく説明されて、もうなんか、すぐに実装できちゃうんじゃないかと錯覚してしまう始末でした。 係り受け解析というと、CaboChaを思い浮かべてしまうんですが、きっと違う実装なんだろうなぁ。 入門編と次回の重要文抽出の話も聞きたいなぁと。\n最後に、技術評論社さんから「Emacs実践入門」など3冊の書籍のプレゼントまでありました。 その他の2冊は購入済みだったのですが、Emacs本は購入したいリストに入れたままでした。 ということで、欲しいですというアピールをしてゲットしてきました！ Emacsはなんだかんだで、もう10年以上使っていますが、そこまで深入りしないような使い方をしていました。 これを機に、再入門してもっと使いこなせるようになろうかと。 また、読了したタイミングでブログに感想かきます。\nということで、以下はいつもの自分用のメモになります。おかしいところ、それ書いちゃダメでしょ的なところのツッコミをいただければ。\n日時：2012年11月28日(水) 19:00 場所：渋谷ヒカリエ27F NHN Japan カフェ ◎開会、諸注意など　@overlast 人材募集、会場説明など。 前回、本をもらった人はブログ書いてね。オライリー様より 今回も本のプレゼントあり。技術評論社様より ◎あなたの知らないハッシュテーブルの世界(30分 + 質疑応答10分)　@kumagi さん ・まずは前提。 データの集合を扱いたいよね 配列でもできるね。けど、データ増えるとキツイね。 ・ハッシュ関数の話から。 リハッシュとかの話 ・ClosedAddressingとOpenAddressingの話 ・ClosedAddressingの場合、ポインタ使ってるからキャッシュミスあり。 メモリとかの話 ・OpenAddressingメモリに乗るのでキャッシュミスは少ないけど、削除データの扱いがちょっと大変 →削除がいっぱい有ると処理が面倒 ・RubyはClosedAddressing、PythonはOpenAddressing memcachedはClosedAddressing ・Cuckoo Hashing（2001） 密度50%以上になると急にコストが高くなる。 挿入がすごく遅くなる。追い出し操作が増えるから？ ・そこで、Hopscotch ググった参考ページ：http://shnya.jp/blog/?p=639 http://en.wikipedia.org/wiki/Hopscotch_hashing 密度が上がっても性能劣化がない。 ・C++でHashtableが欲しくなったら、google_sparse_hashとdense使うよと。 ・ConcurrentHashmapのお話 テーブル部分がvolatile、Chain部分はfinal insertはChainの先頭に。 削除は遅い。ReadCopyUpdate。 空でも1.7M（K？）持ってく ・ここからはLock-free系 ・Lock-Free Hash Table http://www.azulsystems.com/events/javaone_2007/2007_LockFreeHash.pdf HotSpot VMの人のもの？こんなのやってる。http://www.0xdata.com/faq.html ・（聞きそびれた） ・日立謹製Lock-free hashtable 日立のDBで使ってる部品？ ベンチマークが胡散臭い ・最後はJubatusのCM ◎文書要約入門 中級編(40分 + 質疑応答10分)　@hitoshi_ni ・画数が少ないです。 ・ヒカリエ綺麗ですね。 ・文書要約とは？ 「機械に」要約させる。 ・なんで要約？ 長い文章読みたくない。人件費の削減 ・どうやって要約？ 1.文分割：文書を文に分割 2.文短縮：就職説を削除するなどして、原文より短い文の亜種を出す。 3.重要文抽出：要約にふさわしい文を選び出す。 ・今回は文短縮について ・動機 長い文は文抽出で扱いにくい 文の中にも重要なところとそうでないとこがある ・係り受け木の剪定すると短くできると。 剪定のルール 中間ノードは落としちゃダメ 除去の時に考えること 重要度 言語 ・重要度？ 文節に点数を付ける 文書集合中の出現頻度とかを採用。訓練データからでもいいよ（ロジスティック回帰とか）。 ・言語尤度 言語としての尤もらしさ 典型的にn-gram言語モデルを使う ・そして探索 基本的には2値ラベリング ビタビアルゴリズムではだめ。係り受け制約が考慮できない ナイーブいはビームサーチをする。 ・文短縮の評価 ・人間が書いた短縮文と比較 ・ROUGE-Lという尺度などで評価（これしらないなぁ。） ・幾つかの論点 係り受け解析しない 文節じゃなくて、単語単位でもいいよねとか。 Q：硬い文章以外の要約ってやってるの？ A：あります。 技術的な話だと、係り受け解析がうまく出来ればできる。 係り受け解析がうまくいけば、そこまで大変じゃない。 Q：短さが短くなるほど難易度があがるけどどこまでやってます？ A：短くすればするほど難しい。これは情報の欠落が激しくなるから。 文法性を担保するのも難しい。 10文字くらいならできそう。 Q：実例としてどのくらいの長さをどのくらい短くしてる？ A：ある程度の長さを20文字にしてくれとか。Twitterに入るくらいにしてくれとか。 頂いちゃいました！ Emacs実践入門　～思考を直感的にコード化し、開発を加速する (WEB\u0026#43;DB PRESS plus) ","date":1354122000,"dir":"post/2012/","id":"e01e01d18582c7f69e1b0db7e1b111a0","lang":"ja","lastmod":1354122000,"permalink":"https://blog.johtani.info/blog/2012/11/29/dsirnlp-3-5%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Femacs%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80%E3%82%92%E9%A0%82%E3%81%84%E3%81%A1%E3%82%83%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-11-29T02:00:00+09:00","summary":"ヒカリエに行ってみたいという不純な理由で参加してきました。 新しいということもあり、おしゃれで綺麗なカフェでした。 入り口にはおっきな人形も立っ","tags":["勉強会"],"title":"#DSIRNLP 3.5に参加しました。＆「Emacs実践入門」を頂いちゃいました！(Jugemより移植)"},{"contents":"第9回Solr勉強会に参加しました。 皆勤賞です！というか、主催者になってしまいました。 まだ不定期の開催になると思いますが、話をされたい方などいらっしゃいましたら連絡いただければ助かります。\n今回も面白い話が聞けました。\n最初はKuromojiの開発者でSolrのコミッターでもあるChristianの発表です。 Solr勉強会では初の英語の発表だったんじゃないでしょうか。 Atilikaでやってることの紹介から、Kuromojiの紹介、今後の改良に関する話とひと通り話してもらいました。 途中でKuromoji使ってる人？などの質問があったのですが、残念ながら反応が薄かったです。 漢数字をアラビア数字でも検索できるようにするチケットなど、今後のKuromojiの発展も楽しみです。 （コメントとかパッチを送れというプレッシャーもあったので、パッチ頑張って書きます。。。）\nつぎはニコ生でのSolrのお話。結構、赤裸々（前任者がいない状態で引き取ったとか）に語っていただき、ハラハラしながら聞いてました。 やはり、新語や略語で苦労されてるんだなぁと。 複数のサービスや開発者に対してSolrの環境を提供するという話はなかなか興味深かったです。 いろんな人がSolrを触るような状況になってきてるんだなぁと。 基盤となるラッパーのようなフレームワークとかも作ってるのかなぁ？ 今後は台湾語や英語への展開も考えられているようなので、Language Detectionなどを利用してみた感想とその内容を今度発表してもらいたいですねｗ\nつぎはFacetPivotの話です。 昔から要望が出ていたのですが、4.0系でやっと使えるようになりました。 ファセットはSolrの売りの一つだと思います。 最初はこの考え方がしっくりこない人もいるかもなぁと。特にデータをどのように作れば、いいのかって悩むこともあります。 その悩んだ内容について発表してもらいました。 実際にどうやって使うかを悩んだ内容を発表してもらうのもいいなと思いました。\n最後はSolr勉強会なのに、elasticsearchの洗脳会になってましたｗ elasticsearchはSolrと同じ、Luceneをコアに採用した検索エンジンサーバーになります。 Solrとは別のアプローチでLuceneをラップし、REST APIでアクセスしやすくしたプロダクトです。 Luceneのコミッターの方もelasticsearchの開発に参加しています。 分散インデックスを念頭においた設計や、インストールが簡単なプラグイン構造といったSolrとは違ったアプローチがなされており、面白いものになっています。 残念ながら日本で利用されているという話はまだ聞いた事ないですが、だからこそ、触ってみて事例を紹介してみるのも面白いのではないでしょうか。 今回紹介したKuromojiも使えるようになっていたりしますので、日本語でもある程度使えると思います。\n以上が簡単ですが感想です。主催者だったのに、@hirotakasterさんや@ajiyoshiさんに受付などをやっていただいたので、いつもの様にしっかり話を聞いてしまいました。 発表者の方、会場提供いただいたVOYAGE GROUP、お手伝いいただいた皆さんに感謝です！\n今回初の主催でしたが、本当に助かりました。たどたどしい説明や紹介など至らない点も多々有ったかと思いますが、今後もよろしくお願いいたします。\n主催者的な立場として感じたことも書いておこうかと。 無料の勉強会で、ATNDという参加しやすい環境というのもあるかもしれないのですが、キャンセルをきちんとしていただくほうがいいなと思っています。 幸いにもSolr勉強会はここ数回は盛況で、キャンセル待ちの方が結構いらっしゃいます。 ギリギリまで業務との兼ね合いを見つつ、参加しようと思っていらっしゃる方もいると思うのですが、キャンセル待ちで行けるかな？どうかな？と思っている方もいらっしゃいます。 ドタキャンは問題ないのですが、キャンセルせずに欠席は出来れば避けていただけると助かるなぁと。 （残念ながら、きちんと集計をとれなかったので、次回からは集計取ってみようかなぁと）\n次回の開催は今のところ未定です。発表してみたい方、こんな話を聞いてみたいなど、気兼ねなく連絡いただければと思います。 このブログにコメントを頂いてもいいですし、ツイートしていただいてもいいので、反応をいただけると嬉しいです。 また、今回至らない点があったなどのツッコミ、批判も気兼ねなく言っていただければと思います。 今後の反省点にもしたいので、ぜひ反応をいただければと！\n懇親会でも色々な方とお話できました。（もう少し、Christianと英語で話す努力とかしないとなぁ。。。）\nとりあえず、メモをアップしときます。 リンクとか感想とかはまた（飲んだ）後で。。。\ntogetterでまとめてももらったみたいです。ありがたいです。\n第9回Solr勉強会 場所：VOYAGE GROUP 会議室 日時：11/26(月) 19:00～21:00 1. Atilika Inc.　Christian Moenさん タイトル：Who we are, what we do, and a little bit about Kuromoji ◎Atilikaの紹介。 会社の目指すもの ・BigData、検索、NLP ◎プロダクト Kuromoji：形態素解析エンジン Akahai：日本語クエリサジェストエンジン Keywords：日本語キーフレーズ抽出 ◎Kuromojiの紹介 3.6からデフォルトで使える。 ◎将来の改良の話。 ・踊り字対応（コミット済み） ・漢数字に関するチケット＆パッチのお話。 ・ユーザ辞書の重複エントリ改良とか（すみません、パッチ書きます。。。） 2. 株式会社ドワンゴ　吉村総一郎さん(@sifue) タイトル：Solr@ニコニコ生放送 ◎ニコニコ生放送の紹介 ・1日に10万番組。。。 ・10/17にバージョンQをリリースしたら、トップはひどい叩かれようでした。。。 ◎これまで。 Jackrabbit→Lucene→Solr→ニコ生のSolr ◎退職者と入れ替わりでSolr担当。。。 今回は資料と環境を調べて発掘した機能のお話。。。 ◎機能 キーワード検索。論理クエリ、などなど。 ◎利用してる環境 3.4ベース＋Jetty マスタスレーブ構成（スレーブ2台） 途中は分散インデックスを自分で実装？ ボトルネック自体がDBからのデータ収集だった ◎インデックス対象 ・見れるのは過去1週間と過去の公式番組すべて。 この部分だけ検索可能。 ・更新頻度の高い情報に「来場者数」「コメント数」 ◎インデックス作成 ・バッチにて更新 ◎アナライザ CJKTokenizerFactoryを利用 HTMLStripCharFilterFactory Bi-gramなので、「FF」とか「DQ」に弱い（FF1でFF13とかヒットしちゃう） 検索精度は悪いと言われてるみたい。 ◎1日のリクエスト ピーク時40QPS程度 5分おきにスパイクがある。（ユーザが作ったツールによる検索とか。。。） ◎UPDATEリクエスト ピーク時は80QPS ◎開発用のJettyのマルチテナント機能を利用したSolr環境の提供 ◎台湾語とか英語もやりたいなぁ。　3. 株式会社マーズフラッグ　柳吾朗さん(@hitode7456) タイトル：ドリルダウン色々 ◎Facetの紹介から ◎楽天でのドリルダウン例（これはFacetの紹介での例であり、実際にSolrが利用されているかはわからないです。） ◎多段ドリルダウン（ファセット）のお話。 アプリを実装するときの考え方とか。 ◎実直形、工夫形、PivotFacet Q\u0026amp;A Q：3つの性能系のコストは？ A：まだ調べてないです。残り2つは工夫形がいいですよ。と 次回、調べた結果の発表もやってほしいなぁ。 4. 兼山元太さん (@penguinana_) https://speakerdeck.com/penguinco/solrtoelasticsearchfalsebi-jiao タイトル：SolrとElasticsearchの比較 ◎クックパッド！ ◎elasticsearchの紹介 ◎比較サイトもあるよ！ http://solr-vs-elasticsearch.com ◎サンプルデータ・セット（ライブドアグルメ）でサンプル実装。 https://github.com/penguinco/ld_gourmet_search ◎APIの紹介 REST APIがちゃんと造られてますよと。 設計時点でコレクションなどがURLに含まれてるのがいいよねと。 ◎_analyzeによりアナライザーもAPIとして公開されてるよと。 ◎Kuromojiも対応してるよ！ ◎DynamicFieldよりも便利だよ。 ◎クエリのDSLが違うのでちょっとアレ。 ◎スコアリングも色々できるよ。 ◎感想 ・機能面の不足なし ・APIがいい コア追加とか、curlだけでできるのがいい。 ・習得が容易（Solrやってると機能とか似てる） ・大規模じゃなくても使えそう ◎分散検索がデザイン時に組み込まれてるのがいいよね。 write consistencyなどがインデックスごと（コレクションごと？）に設定可能なので便利。 ◎multi-tenant open/closeなどができる（時系列データとか） shard allocationなどの細かな制御も可能ですよと。 ◎plugin 色々プラグインがあるよ。管理画面もプラグインであります。 プラグインもコマンド一発で追加可能。 ◎クエリキャッシュがないので、自前でnginx、varnishなどでキャッシュが必要。 ","date":1353923040,"dir":"post/2012/","id":"7e23419e4fc69b5b533815681c9bb1a9","lang":"ja","lastmod":1353923040,"permalink":"https://blog.johtani.info/blog/2012/11/26/%E7%AC%AC9%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/","publishdate":"2012-11-26T18:44:00+09:00","summary":"第9回Solr勉強会に参加しました。 皆勤賞です！というか、主催者になってしまいました。 まだ不定期の開催になると思いますが、話をされたい方など","tags":["勉強会"],"title":"第9回Solr勉強会を主催しました。#SolrJP(Jugemより移植)"},{"contents":"初目黒（たぶん）で、初Amazonな感じで、流行りの「ビッグデータ」のセミナーに参加してきました。\nとりあえず、いつもの自分用のメモを残しておきます。 感想はまた後日。。。（たぶん、頑張れ私。。。）\nAWS ビッグデータ活用事例セミナー 日時：2012/11/09 [ 金 ] 9:30 - 12:00 場所：アマゾンデータサービスジャパン目黒オフィス ★AWSビッグデータ概要 @understeer　○Amazonの紹介 ○Amazon Web Serviceの紹介 ・オンプレミスと比べ、初期費投資が不要 ・コストダウンを促進 過去6年で21回の値下げを実施 ・IaaSだけじゃなく、PaaSもやってますよ。 ・OSより上の層は好きに選べるよ。 ○AWSのサービスだけで20ある。 ○3つのV Volume　2012年で1.2ZB。95%が非構造データ。今後も非構造データが増加 Velocity　デバイスの増加、パーソナライゼーション系の増加 Variaty 素粒子のデータの解析とか、地質学、気象予報とかいろいろやってるみたい。 ○BIG DATAの4つのプロセス。 収集、保存、分析、共有を繰り返しやりましょう。 そこで！AWS使いましょう。 ○収集 AWSへのデータアップロード オンプレにあるデータをAWS（S3）にアップロード ・インターネット経由 ・専用線サービス（AWS Direct Connect、1/10Gbps）も可能 ・AWS Import/Export（HDDを送りつけてS3にアップロードしてくれる。Tokyoリージョンにはだない） ・インターネットVPN経由も可能 ・EC2上のデータももちろんできる。 ※WAN高速化ソリューションも利用可能。 ○保存 ・AmazonS3 99.999999999%の耐久性。 同一リージョン内の3箇所以上のDCに自動複製 容量無制限で低コスト（1G 約10円/月） ・Amazon Glacier データの利用準備に3.5～4.5時間かかる。 S3の約1/10という低コスト ○分析　オンプレミスだと運用が大変。 ・Amazon EC2 スケールアップ/ダウン、アウト/インが即座に可能。ライセンス持ち込みや従量課金に対応 スペックの種類が豊富（SSDとかもあるよと） ・Elastic MapReduce Hadoopをサポートしたの仮想サーバが簡単に用意可能。 S3、Dynamoとの連携も可能 ディストリビューションも選択可能（Apache、MapR） 追加のアプリ（Hive、Pig、HBase）なども利用可能。 ジョブの大きさに合わせてクラスタサイズを適切にすることでコスパがよくなる。 →HadoopのMRのデータのローカリティとかはどうなってるんだろう？ ○共有 ・AWS RDS MySQL、Oracle、SQLServerをサポート（PostgreSQLはないのかな？） 自動バックアップ、フェイルオーバー、パッチ適用機能があるよ ・Amazon DynamoDB AmazonオリジナルなNoSQLデータベース。論文有るよ。 運用管理は気にしなくていい。 性能については客指定の性能が出せるようになる。しかも変えられるよと。 ※データサイズに応じて以下を選択しましょう RDS、HBase on EMR、DynamoDB、S3 他にもEC2上で、CassandraやmongoDB、GlusterFSを使ってる事例もありますよ。 ○以上を繰り返すのが意味があります。そこで！ ・Simple Queue Service マネージド分散キューサービス 最低1度のメッセージ到達の保証。複数DC間で複製保存 ・Simple Workflow Service 進捗などの管理も可能 NASAのCURIOSITYの制御に利用？10m前進するのに10時間のバッチ処理がある。。。 データがなくて試せない！そんなあなたに！ ○AWS Public Data Sets すぐ使えるPublic Dataが用意されてるよ。 http://aws.amazon.com/jp/publicdatasets/ ★AWSのビッグデータ事例紹介　@shot6 ○NETFLIX ・どんな会社？ 2500万人以上のストリーミング会員 500億以上のイベント ・AWSの利用は？（保存） 8TB/日のイベントデータを収集しS3に。 Cassandra上の顧客データもS3に。 1PB以上のデータがS3に保存。 ・AWSの利用は？（解析） EMRでレコメンデーション、アドホック分析、パーソナライゼーションなど。 本番クラスタ（ずっと動かしている） アドホック分析用クラスタ（必要に応じて構築） 解析用のアルゴリズムをAPIで叩けて、ジョブとして定義されてるらしい ・Cassandraを使ってるよ。 Cassandraのクラスタをマルチリージョンで対応したりもしてる。 CassandraのBackupもやってる。OSSで公開されてる？ ※HBaseのものもあるよ。 ※AWS上のCassandra事例もいくつか広告系で出てるみたい。 ・High I/O Instances for EC2（SSDのインスタンスまだ東京に無いらしい。） ・AWSスケールアウトだけでなく、スケールアップも徐々に増えています。 ○yelp ・どんな会社？ 口コミサイト。 スペルミスの自動修正、検索ワード自動補完、 ・AWSの利用は？ WebサイトのログをS3に保存。 EMRを利用してHadoopClusterで解析してS3に保存している。 EMRは処理終了後にシャットダウンしてる。 ・データ解析が日常になった ○SHAZAM ・どんな会社？ 広告配信、モバイル系の配信をやってる会社。 Super Bowlの広告配信でAWS、DynamoDBを利用。 ※マイネット・ジャパンでもDynamoDBを利用している ○CLIMATE Corporation ・どんな会社？ 天候保険の会社 ・AWSの利用は？ 200TBの地質、天候データを解析して ○THOMSON REUTERS ・どんな会社？ 情報提供の会社。データの提供が元だけど、解析した結果の情報も提供してるみたい。 ・AWSの利用は？ MarketScanという18年分の個人の医療データ（個人情報自体はないみたい）を販売する、販促ールとして利用。 1500万人分の患者データを提供。 マーケットの分析に使えるデータの提供。 KARMASPHEREとEMRの組み合わせで、ソリューションを提供していますよと。 ・事例 1.MarketScanをS3にアップロード。 2.分析官が、KARMASPHERE経由でEMRにアクセス。 3.EMRにS3からデータロードされ、結果がRDS（Oracle）に保存 4.RDSに他の人達もアクセスして使ってるよと。 ○RANGESPAN ・どんな会社？ ECサイト向けのPaaSサービスを提供してるロンドンの会社。 ・AWSの利用は？ NLP、機械学習にEMRを利用？ mongoDBのクラスタを構築してる。 ※mongoDBの日本の事例としてCAがあるらしい。 ★Huahin Framework活用事例 on AWS @ryu_kobayashi ○Cassandra本とかもやられてるみたい。 ○EMRとは PaaSなんだけど、中身を自分でいじれるらしい。 Management Consoleでは3つのバージョンが使えるが、コマンドラインからだと他にも使えるみい。 ・HBaseはAmazonのDistributionのものだけ。 ・EMRのメリットは？ インフラの面倒を見なくていい。 クラスタの立ち上げも複数あげられるので簡単。本番実行と同じ環境 ・EMRのデメリット オンプレミスにすでにデータがあるとアップロードが大変。実際に物理HDDを送ったこともある（2,3日でAWS上にアップロードされた） 外に出せないデータがあると。。。 ○EMRのTips（EMRの連載に載ってますよ！http://gihyo.jp/dev/serial/01/emr） ・Bootstrapを設定 EMRのクラスタの起動前にメモリ設定とかHadoopの設定が可能にできる。 ・ファイルサイズを適切に Map数=splitを決めるコード を指定することで、処理が早くできるのかな？ ○EMRの起動には いろいろあるけど、HuahinEManagerを使うと使いやすいよ？ ○Huahin Frameworkの構成 ・Huahinの名前の由来は？ 社内のコードはワインの産地にするという決まり。 タイの観光地Hua Hinがワインの産地。 ・他のHadoop関連のマスコットより可愛いでしょ！？ ・Huahin Core MRのプログラムを簡易化 WritableとかSecondary Sortとか書かなくていい 考え方がSQL寄り 素のMRも書ける。Pig、Hiveだとパフォーマンスが難しい Huahin UnitというMRUnitをラップしたものもある ・Huahin Tools 汎用的な処理を集めたツール群だけど、Apache Logの成形のみ。 オンプレミスHadoop、スタンドアロン環境でも動かせるようになってる。 ・Huahin Manager Jobを管理するマネージャ Jobの実行 キューを持ってるので、複数の実行が可能だよ。 EMR対応してる。bootstrapに設定するとできるらしい。 ・Huahin EManager EMRのいろいろが管理できるみたい。 初期設定20までしかインスタンスが挙げられない上限があるらしいので気をつけましょうと。 キュー登録のPOST機能は便利そうだ。（EMR触る機会まだまだないけど。。。） EMRにはJobのkillがない→Job FlowをターミネートすればOK→実際にはEMRのマスタノードにSSHすればできるよ。→めんどくさいよね。。。 EManagerなら可能ですよと。これは必須だよなぁ。 ","date":1352477220,"dir":"post/2012/","id":"98c640616f997a323af625e34ba34850","lang":"ja","lastmod":1352477220,"permalink":"https://blog.johtani.info/blog/2012/11/10/aws-%E3%83%93%E3%83%83%E3%82%B0%E3%83%87%E3%83%BC%E3%82%BF%E6%B4%BB%E7%94%A8%E4%BA%8B%E4%BE%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-jawsug/","publishdate":"2012-11-10T01:07:00+09:00","summary":"初目黒（たぶん）で、初Amazonな感じで、流行りの「ビッグデータ」のセミナーに参加してきました。 とりあえず、いつもの自分用のメモを残してお","tags":["勉強会"],"title":"AWS ビッグデータ活用事例セミナーに参加しました。#jawsug(Jugemより移植)"},{"contents":"##Lucene/Solr 4.0.0リリース ついに、Lucene/Solr4.0.0がリリースされました。 MLで流れていましたが、3年越しのリリースだったようです。 コミッターの方々、JIRAにバグ報告をした方々、お疲れ様でした。\nということで、ちょっと忙しくなりそうです。。。 4.0の機能を調べたりもしたいですし、すこしずつ紹介もしたいです。\n本家サイトのニュースはこちら\n##lucene-gosenの4.0対応版について lucene-gosenも4.0正式版のjarを利用したバージョンを公開する予定です。 branches/4xでは、すでに作業を行なっており、jarファイルの差し替えは終了しています。 お急ぎの方は、branches/4xをエクスポートして、ビルドしていただくと利用可能となっています。 なお、Lucene/Solrのバージョンが上がっているため、lucene-gosenのメジャーバージョンも変更し、lucene-gosen-4.0.0としてリリースする予定ですしました。。（順当に行けば、3.0.0ですが、Luceneのメジャーバージョンに合わせたほうがわかりやすいかと思いまして。） また、現在、trunkが3.6.x対応のソースになっていますが、このあと、現在のbranches/4xのソースをtrunkにする予定です。 3.6.x対応のlucene-gosenについては、branches/lucene-gosen-rel2.0にて作業を行うこととなります。 今後は注意してチェックアウトするようにお願いいたします。\nということで、ダウンロードできるようにしました。 lcuene-gosen-4.0.0*.jarとついているものがLucene/Solr 4.0.0に対応したライブラリになります。\n","date":1350031500,"dir":"post/2012/","id":"922cc71fd28b1dac8f407f1d517f5595","lang":"ja","lastmod":1350031500,"permalink":"https://blog.johtani.info/blog/2012/10/12/lucene-solr-4-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9lucene-gosen%E3%81%AE4-0%E5%AF%BE%E5%BF%9C/","publishdate":"2012-10-12T17:45:00+09:00","summary":"##Lucene/Solr 4.0.0リリース ついに、Lucene/Solr4.0.0がリリースされました。 MLで流れていましたが、3年越しのリリースだったようです。","tags":["lucene-gosen"],"title":"Lucene/Solr 4.0.0リリース＆lucene-gosenの4.0対応(Jugemより移植)"},{"contents":"このイベントにウチダスペクトラムの枠でMahoutのコミッターである、Grant Ingersollさんが講演されるということで、興味があったので聞いて来ました。 （この枠だけ）\nLucidWorks社が現在展開している、LucidWorks BigDataの概要とコンセプトといった話の内容でしょうか。 LucidWorks社（元Lucid Imagination）はLucene/Solrのコミッターの方々が多く在籍している会社です。 検索システムに関するノウハウを元に、発見や解析といった部分にニーズが広がってきているという話の ざっくりした概要のはなしでした。 検索システムを中核にして、ログや検索で提供しているデータの解析などの重要そうなポイントが散りばめられて いるお話でした。\nもっと詳しい話を聞きたいなぁ。\n講演では日本語の資料でしたが、サイトに英語の資料がアップされているとのことでした。 原文が読めるのは非常に助かります。他のイベントなどでもこのように英語の資料も見れるようになると嬉しいです。\n以下は、いつものメモになります。\n場所：富士ソフト　アキバプラザ5Fホール 日時：16:10- ◯サーチ技術による情報の可視化 通常、検索と言うとWebサーチだけど、ウチダスペクトラムのやっている部分はエンタープライズ向け ナイスガイ＝Grant S. Ingersollという紹介 ◯サーチからSDAへ LuceneやSolrのお陰で、検索自体は簡単になってきている。 ◯サーチの進化 ユーザとデータを結びつける意味での検索の進化が必要 ユーザインタラクションや、アクセスの方法とか ◯SDA Search, Discovery and Analytics ・ユーザからのニーズ 検索、優先順序付け、新たな気づき、フィードバックによる学習 ・ビジネスからのニーズ ナレッジの有効活用 ◯ユーザ事例 保険会社での請求に関する不正利用分析を含んだクレーム処理と分析 ◯事例：個人に最適化された医薬品 DNAをベースに検索やファセットで医薬品を検索したり。 ◯事例：通信会社における通話記録処理 ログを元に検索して、不正通話などを解析 ◯SDA基盤に必要な要素 高速で拡張性のある、検索 大規模でのコスト効率が高いストレージと処理 NLPとMLにより解析などが向上 ◯SDAのアーキテクチャ 基盤 LucidWorks Search、Hadoop、HBase、ApachePig、Mahout、 NLP、 管理 Zookeeper インフラ ZABBIX、AWS、Chef データの流し込み Twitterからのデータとか ◯検索部分にフォーカス ・LucidWorks Search SolrCloudによる簡単なshard処理 ・Hadoop ログ、生データ、中間ファイルの保存 WebHDFS 小さなファイルには向いていない ・HBase メトリック、ユーザ履歴などのストレージ 課題 どこに正式に保存する？ リアルタイム処理 vs バッチ処理 分析はどこで行われるべきか？ ◯検索の実装に関連すること 3つのポイント 性能と拡張性 関連性 オペレーション（モニタリング、フェイルオーバーなど） ビジネス側では検索結果の適合性を重要視する 開発側は性能を重視する傾向がある。 ◯適合性に関して テストが重要。 クエリ、クリック、表示したドキュメントなど、すべて保存すべき！ ◯Discoveryにフォーカス ◯MahoutによるDiscovery 3つのC ・協調フィルタリング ・クラシフィケーション ・クラスタリング 追加事項 課題 収束を伴う計算コストの高い機械学習アルゴリズム Mahout ◯余談：Experiment Management ◯Analyticsにフォーカス Rとか、うまく活用 検索エンジン自体でもできることがある。ファセット、TF、DF/IDF SearchとDiscoveryの定量化 ログ、ナビゲーション分析 ","date":1348650492,"dir":"post/2012/","id":"43501cdf0de25278a208cbb9aad80012","lang":"ja","lastmod":1348650492,"permalink":"https://blog.johtani.info/blog/2012/09/26/lucid%E3%81%AEgrant-ingersoll%E3%81%95%E3%82%93%E3%81%AE%E8%AC%9B%E6%BC%94%E3%82%92%E8%81%9E%E3%81%84%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-09-26T18:08:12+09:00","summary":"このイベントにウチダスペクトラムの枠でMahoutのコミッターである、Grant Ingersollさんが講演されるということで、興味があった","tags":["勉強会"],"title":"LucidのGrant Ingersollさんの講演を聞いてきました(Jugemより移植)"},{"contents":"PFIオープンセミナー2012に参加してきました。 対象から微妙に外れてたり、話の内容についていけるか自信がありませんでしたが、参加してきました。 PFIさんは前から面白そうなことやってる会社だなぁと思っていたので。\n面白い話がいっぱい聞けました。 電池が切れそうなので、とりあえず、まずはメモをアップしときます。 かろうじてついていけたという感じですが。 丸山先生の話はアーキテクチャの話に入る前のビッグデータの光と影の話がよかったです。 ビッグデータと言っても、まずは、サンプリングなどで小さなデータで処理できるかもしれないと考えるのも必要なのでは？という話や、相関があるからといって、因果が有るわけではないとか、おそらく、統計やってる人や、数学やってる人にしてみれば、当たり前の事なんでしょうが、その部分に警鐘を鳴らす話が聞けたのは良かったです。 もちろん、ビッグデータでなければ意味が無い解析などもありますという話もきちんと出ていました。\n伊藤さんの話は、Screwと呼ばれる、多言語解析基盤のお話です。その前にSedueの紹介で、SolrとSedueの比較の話も出ていました。（若干、強引な感じもしましたが。。。） 多言語解析基盤は、Solrでも少し入ってきています。ただ、それよりも汎用的な作りになるようなので、今後Solrと組み合わせて使うといったことも可能になるかもしれません。 まだ、対応言語などが少ないので今後に期待という感じでしょうか。 複数の言語が混ざった時の挙動がどうなるのかや、身近な文章での言語判定の正確さは少し気になります。\nサイバーセキュリティの話も面白かったのですが、話が多岐にわたるのと、スライドの情報量の多さに少しついていけませんでした。 資料が公開されたら、もう一度見直したいかなぁと。\n比戸さんの話は、Jubatusと関連のある話でした。機械学習の実際の利用の話が特に興味深かったです。 最近になって、ようやく、実際のデータを利用した話が出てきているみたいで、もっと事例が出てくると機械学習も身近になりそうだなぁと。\n最後は、日経BPの中田さんの話でした。これが、一番想像していたものと内容が違って、驚きつつ、楽しめた話でした。 ビッグデータというバズワードがいかにして生まれたのかがよく分かりました。 私は、バズワードだなぁと思う程度だったのですが、出てきた背景にある程度意味があるという考察に感心して聞き入ってしまいました。\nということで、思っていたよりも話の内容についていけたので、講演された方々の話しのされ方が良かっただと思います。\n少し無理をして参加してよかったと。\n残念だったのは、会場が地下だったため、携帯が入らなかったことでしょうか。 私はe-mobileで接続していたので大丈夫でしたが、docomoの携帯は圏外でした。 ツイートがもう少し盛り上がれば、もっと質問も出たのかもしれないです。\nhttp://preferred.jp/news/seminar/\n資料が公開されたので、リンクを貼っておきます。 PFIの方たちの資料へのリンク： http://preferred.jp/news/?id=1139\nゲスト講師の資料へのリンク： http://preferred.jp/news/?id=1159\n◯「多様化する情報を支える技術」　講師：西川徹（株式会社プリファードインフラストラクチャー　代表取締役） ・PFIの説明 VCに頼らない。製品につながるビジネスにこだわる（受託開発しない）、技術の多様性を重視 ・PFIの技術領域、ビジネス 製品開発（Sedue/Bazil/Jubatus）、自然言語処理、機械学習、分散システムなど ・”人”が生み出すデータと\u0026#34;機械\u0026#34;が生み出すデータ ビッグデータの発端はGoogleが元じゃないか？→最後の公演で解説があるよ 人：質が高いけど、量が少ない 機械：質は低いけど、量が多い ・検索システムについてのお話 社内の資料とか情報が、人によって、まちまちなデータの保存（形式、場所など）が実施されてしまう。 情報検索技術と大規模データ ・人のデータへ必要なアプローチ より検索システムを活用してもらうために、楽に整理できる仕組みなどをどう提供するか 質の高いデータなのに、形式的な共有しかできていないのはもったいない ・機械のデータへ必要なアプローチ 大量データと高度な解析が重要（CEPとか） デバイスが性能向上→流れてくるデータが大量に→蓄積するだけでも問題になってくる →蓄積したデータを扱うだけでも処理コストが高くなる 分析をオンライン化、ストリーム化すること→Jubatusで貯めずに高度な解析をしましょう。 Edge-Heavyになりつつある。　◯「ITアーキテクチャはどこへ向かうのか」 講師：丸山宏氏（統計数理研究所　副所長　モデリング研究系教授　工学博士） ・ビッグデータの光と影 「その数学が戦略を決める」という本がオススメ ・大量データでも、ランダムサンプリングでとければ、ビッグデータじゃなくてもいいよね。 もちろん、ランダムサンプリングだけじゃダメな場合もある。 ・Hadoopが解ける問題領域って少ないのでは。 ・TVを見る時間が長い人ほど、方言の使用率が高い 因果関係と相関関係の違いをきちんと理解しましょう。 ・データをきちんと理解して意思決定などをしたほうがいいよと。 ・つぎのアーキテクチャは何か？ ・コンピュータ・アーキテクチャの歴史 ConnetionMachine CM-1（1985） SPARC Transputer（CSPによる並列性、Occam） SymbolicsLispMachine Intelアーキテクチャの台頭により、アーキテクチャの研究が廃れてくる ・クラサバ、スマホ・クラウドなどのアーキテクチャの話 ・じゃあつぎは？ Edge-Heay Data＝スマホなどデータが保存される場所がEdgeになりつつある ビッグデータのほとんどが廃棄されるデータ ・Edge-Heavy Dataに特化したアーキテクチャとは？ 分散マッチング・プロトコル→サマリ情報を交換することで、絞り込みが可能 X=3とした場合、センサーとかなら、ピンポイントな値ではなく、範囲では。 分布表現を1stクラスオブジェクトとするプログラミング言語が必要では？ ・アーキテクチャの変節点を見極めよう QA： Q：スパースネス問題がランダムサンプリングやフィルタリングじゃ解けないんでは？ A：はい。ただ、その前にやることがあるはずですよねという注意喚起の意味での発表です。 価値に応じて、EdgeにあるデータをCenterに持ってくるという考え方が必要。 今は価値が見いだせないのなら、Centerにまで持ってこなくてもいいのでは。 ◯「グローバル化する情報処理」 講師：伊藤敬彦（株式会社プリファードインフラストラクチャー 研究開発部門　リサーチャー） ・Sedueの説明 NHKニュースなどで ・提供する機能 ・検索補助 レコメンド、サジェストなど ・レコメンド機能の紹介 ・Sedue/Solrの比較 サポート体制：開発チームがサポートしてくれる 安定性：GCがないのがいい 付加機能： 検索の完全性：接尾辞配列による検索 ・多言語処理の話 ・翻訳ではなく、任意の自然言語言語で動作・精度を向上させる処理の話。 ・背景 サービスのグローバル化、会社組織のグローバル化 ・複数言語を扱う場合の難しさ 多言語解析基盤Screwの開発。 1.必要な処理を順番に適用する 処理の順序は設定で。出力はJSONで。 例：言語同定、単語分割、単語正規化 →言語同定処理で 2.言語ごとに必要な処理を適用 ・疑問 ScrewはSolrとの組み合わせもできる？ 複数言語が混ざった文章の場合にどういう形で動作する？ 言語判定は独自実装？ ◯「BigData処理技術とサイバーセキュリティ」→題名変更されてた 講師：桑名栄二氏（NTTセキュアプラットフォーム研究所　所長） ・経歴 Jubatusプロジェクト立ち上げに参画 ・攻撃に関する話 原因のわかっていないケースが多い。 ・端末の初期設定のパスワードとかが狙われるケースも多い ・変化する攻撃、変化するシステム・サービス、変化するデータ ・マルウェアの分類にJubatus ・不正IPアドレスを機械学習して ・ABC 「あたりまえ」のことを「ばかみたいに」「ちゃんとやる」 ◯「先進ビッグデータ応用を支える機械学習に求められる新技術」 講師：比戸将平（株式会社プリファードインフラストラクチャー　研究開発部門　リサーチャー） ・ビッグデータ分析はより深い地検を得られるビッグデータ「解析」へ ・ビッグデータ分析プロセス Volume、Variety、Velocity 蓄積（NoSQL系）、分析（CEP）、両方やるのがHadoop ・分析から深い解析へ 予測、カテゴリ分類、レコメンド、異常検知　これを機械学習で解決する方向で ・機械学習を応用している例 クレジットカードの不正利用検知：FICO ネットワーク攻撃/侵入検出 Jeopardy!でクイズ王に勝利 医療診断支援 ・データ解析技術への過度な期待と現実とのギャップ いろいろできるみたいだけど、何が必要？ ・ビッグデータ処理系を使える人 ・データサイエンティスト ・機械学習ツール ・ビッグデータ処理系での機械学習への対応状況 Hadoop本体（YARN） MapReduce系（Mahout、AllReduce or Vowpal Wabbit、SystemML） 非MapReduce系（Spark） ・機械学習からビッグデータへの歩み寄り ベンチマーク性能への固執とか、応用との乖離を批判する論文もあるらしい。 ・機械学習の応用例 Machine Lerning for the New York City Power Grid[Rudin et al., TPAMI, 2012] 電力配電設備の障害予測・検知 実データを用いた例が今後増えていくのでは。 ・今後重要になる技術とPFIの取り組み ・データ解析の敷居を下げるためのトレーサビリティ 機械学習向けスクリプト言語は敷居が高い WekaやSPSSのようなアイコンベースのデータ処理プロセスの記述は前処理には強力だけど、機械学習とは相性が良くない 結果が見える化部分との統合が不十分。 ・Bazil Farm学習結果分析例 Tweet年齢推定、Tweet性別推定 ◯「“ビッグデータ”が話題になった理由」 講師：中田敦氏（株式会社日経BP社　記者） ・自己紹介 ・バズワードができるまで まずは、「クラウド」のバズワードの歴史 「バズワードはIT企業やThe Economist誌の煽りでなく一般企業の経営陣が納得すると生まれる」 ・なぜ経営者がビッグデータに興味を？ 「ザ・クオンツ」という書籍に金融業界のルールの変化が書かれてる。面白いよ。 Google/Amazonに対する警戒心から。 破壊的な新規産業者へ対抗して行かないといけない思うところからビッグデータが流行ってるのでは。 「買ってきたIT」は差別化要因にならないのでは？→自分で作ったITなら差別化できる。 ・競争力は自分で作るしか無い 日本のとある特殊事情 ITエンジニアの所属先が日米で割合がぜんぜん違う。米国はユーザ企業が75%、日本は25%くらい ・ビッグデータの次はなに？ 3次元プリンタがあれば、好きなモノが作れちゃう。＝消費地の近くで作成しちゃえば良くなるのでは。 ","date":1348214700,"dir":"post/2012/","id":"89abaa7f21cf788ce4744e3e61173291","lang":"ja","lastmod":1348214700,"permalink":"https://blog.johtani.info/blog/2012/09/21/pfi%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC2012%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pfiopen2012/","publishdate":"2012-09-21T17:05:00+09:00","summary":"PFIオープンセミナー2012に参加してきました。 対象から微妙に外れてたり、話の内容についていけるか自信がありませんでしたが、参加してきまし","tags":["勉強会"],"title":"PFIオープンセミナー2012に参加してきました。 #pfiopen2012(Jugemより移植)"},{"contents":"友人にお値打価格で購入したMac miniはMountain Lionにアップデートしてたのですが、手元のAirはまだアップデートしていませんでした。\n夏休み中にバックアップ＋アップデートをしてしまおうと思いMountain Lionにアップデートはしていたのですが、 本格的に触り始めると色々と動かないものがあったので、備忘録としてブログを書いておきます。 （まだ途中ですが。）\n###1.Eclipseが起動しない Java6が未インストール状態になったみたいで、Eclipseを起動すると、Java6をインストールしなさいと言われました。 で、私の記憶が確かなら、前はJavaコマンドを実行するとインストールされたんですが、ターミナルでjavaコマンドを実行するとjavaはすでにインストールされてる模様。。。 あれ？と思い、-versionを実行すると、JDK7u4と出るじゃないですか。 どうやら、Java7u4は別途入れてたものが残ってる模様。 さて、どーする？ということで、ツイートしたりぐぐってみて、「Java Preferences」なる設定用のアプリ？が有ることに気づき、とりあえず開いてみたらJava6ないからインストールしたら？と言われました。 結果オーライということで、インストール開始。 無事、インストールも終了。Eclipseも起動しました。（ただし、今度はMercurialのプラグインがPythonのライブラリが無いとエラーを出すことに） ###2.Xcodeが起動しない。 使ってはいないんですが、Javaの件を調べるのに、起動したらLionじゃないと駄目だよと。 ということで、Xcodeもインストールしなおし。 ###3. homebrewが動かない 1.で書いた方法で、Eclipse自体は起動したんですが、Mercurialのプラグインがエラーを吐き始めました。 で、見てみると、hgコマンドを実行しようとしてなんか、壊れていると。 で、hgコマンドってどうやってインストールしたか思い出さないまま、とりあえず、homebrewだっけ？と勘違いしたまま、「brew update」を実行したらエラーがでて、「brew install git」でしょ？って言われてしまいました。 コメントにもいただいていたように、Xcodeをインストールしたのだが、コマンドラインツールが入ってないというのが影響しているみたいです。。。 で、ググってみると、こんな情報が。[http://labs.torques.jp/2012/07/04/2830/](http://labs.torques.jp/2012/07/04/2830/) ただ、そこに有るようにPreferenceのダウンロードを開いてもなーんにも表示されません。 で、更にググってこちらの情報に。[http://qiita.com/items/9dd797f42e7bea674705](http://qiita.com/items/9dd797f42e7bea674705)（なんだか、TLで見かける人のお名前が！） AppleのDeveloperサイトからダウンロードかぁと思いつつダウンロード用のリンクを踏んだら、アカウント登録しろとのページが。。。 なかなか遠い道のりですね。。。 Appleのアカウント自体は持ってるので、Developerへの追加登録なんですが、日本語が文字化けしまくりの確認ページが出る始末。 もう、めんどくさいので、そのまま登録しちゃいました。 で、ダウンロードする前にもう一回XcodeのPreference見てみたらなんか、ダウンロードする候補が出てきてるじゃないですか！ 結局、XcodeのPereference画面からダウンロードすることにしました。 AppleのDeveloperに登録したからなのか、Xcodeのプロジェクトを作ろうとしてXcodeをきちんと起動したからなのかは結局わかっていません。。。 良くないよなぁ。（ご存知の方いたらコメントもらえると嬉しいです。） で、やっと「homebrew」を入れようかなぁと。 一応その前に「sudo brew update」ってやってみたらどうなる？と挑戦したら今度は動きました。 homebrewが何を判断してinstallでしょ？って言ってたのかもわかっていませんが、updateで良かったみたいです。 ついでに、upgradeもしときました。（こっちは後からインストールしたもののバージョンが上がってるものがあったら更新してくれるコマンドかなぁ？）\n###4. pipの更新 ただ、brewをupdateしても相変わらず、EclipseのMercurialのPluginはエラーを出してました。 で、ターミナルからhgコマンドを実行してみたら同じエラーが。まぁ、そうですよね。 エラーメッセージを頼りにこれまたググってみたら、同じ状況のひとがいました。[https://groups.google.com/forum/#!msg/mercurial-ja/MxY6lejLXxo/OgJA_knXV6cJ](https://groups.google.com/forum/#!msg/mercurial-ja/MxY6lejLXxo/OgJA_knXV6cJ)（ここにもTLでお世話になってる方のお名前が！！） で、書いてあるように「とりあえず pip install mercurial で解決しました. 」ということで、コマンドを実行して見ることに。 これが、また失敗します。。。（日頃の行いが悪い？？てか、日頃MBAをメンテできてないのが悪いのか。。。） そういえば、過去のMBAセットアップのメモを残してたなぁと思い出して「johtani mercurial」でググってみるとちゃんと[書いてある](http://johtani.jugem.jp/?eid=34)じゃないですかー（偉いぞ、自分） ということで、「sudo easy_install pip」でpipを更新してから「sudo pip install Mercurial」で無事、hgコマンドもインストールし直せました。 Eclipseを起動してもエラーが出ない。（まだbitbucketに接続確認まではできてないですが。。。眠さに勝てず寝てしまいました。） ","date":1346650440,"dir":"post/2012/","id":"7604edf307a5e96120606c8dda06458f","lang":"ja","lastmod":1346650440,"permalink":"https://blog.johtani.info/blog/2012/09/03/%E3%83%A1%E3%82%A4%E3%83%B3mba%E3%82%92mountain-lion%E3%81%AB%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88%E3%81%84%E3%82%8D%E3%81%84%E3%82%8D%E7%A2%BA%E8%AA%8D%E4%B8%AD/","publishdate":"2012-09-03T14:34:00+09:00","summary":"友人にお値打価格で購入したMac miniはMountain Lionにアップデートしてたのですが、手元のAirはまだアップデートしていませんで","tags":["備忘録"],"title":"メインMBAをMountain Lionにアップデート（いろいろ確認中）(Jugemより移植)"},{"contents":"興味をもちつつ、触っていない軟弱者ですが、興味があるので今回も話を聞きに行って来ました。\nまずは、作者古橋さんによるFluentdの魅力や次期バージョンのお話。 あいかわらずわかりやすいスライドで話もわかりやすくてよかったです。 どうしても実績という点を懸念事項として上げる人が多いというアンケートを元に、各社が使ってるし導入もしやすいですというお話。 ここまでしてもらってるのに触ってないなんてほんと申し訳ないです。。。\n次は楽天の方によるCloud Foundryのログの問題点解消のためのFluentd導入のお話。 EC2でもそうですが、ファイルが永続化されない？のでログが消えてしまうという問題があるので、 集約しましょうと。 いままでとは少し違う問題点からの話でした。\n次はドリコムの方（浴衣？甚平？でかっこ良く発表）のIDCをまたいだFluentdの活用と、Fluentd自体の監視などについてのお話。 実際にログが増殖して苦労された点を解決するために考えられた監視項目など、あとで見返したくなる資料でした。 実際に試行錯誤されたあとの話はやはりありがたいです。 あと、お子さんが可愛かったｗ\nつぎのCROOZの方のPCがWindowsだったため（？）プロジェクターに繋がらず、急遽QAタイム。 このあたりの@doryokujinの話のつなぎの旨さとかほんとすごいなぁと感心します。\nで、Macに乗り換えてCROOZの方の発表。 Fluentd＋TreasureDataのお話。少人数（というか一人？）でも簡単にログ収集の仕組みが作れて、しかも保存先のサーバを用意せずに簡単な解析もできるというお話。 これは、ちょっとやってみようと思う人（少なくとも、私はやろうと思った）が増えたんじゃないかなぁという発表でした。 スライドがなぜか最後のほうが見えなくなってしまったので、第３回でも発表されるということになってましたｗ 最後は新大阪から文字通り駆けつけた玉川さんのHBase本＋そのた今後の翻訳本の紹介。 つぎはHiveの本も出てくるみたいでした。 日本語の資料ってホント助かります。購入しないと翻訳本が出る機会もないみたいなので皆さん買ってくださいとのこと。 HBaseはまだ触りそうにないから９月に出るAWSの本でも買おうかなぁ。 あ、日本語で解説してあるSolrの本もあるので是非買ってください！\nその後は懇親会でした。今回もTL上でズケズケと私が勝手に絡んでいる方たちにリアルにお会いできたので楽しかったです。\n自分もフロントよりも、バックエンドに興味があるし、実際に運用されてる人の話が多く聞けるので次回も参加したいです。 それまでにどこかで触るかplugin作るかしないとなぁ。\nということで、以下はいつもの適当メモです。\n開催日時：2012/08/22 18:00 ～ 22:00 場所：グリー株式会社 14F セミナールームYosemite ◎「Fluentdの現在と未来」　Treasure Data, Inc.　古橋　貞之 (@frsyuki) ◯アンケートの内訳 ◯ドキュメント欲しい？ ※思ったより日本語のドキュメントじゃなくてもよさそうだった。 ◯loggingってなんでいるの？ いろいろな解析ってあるよね。 ◯ログの集約、保存、などの問題点について フォーマットが混在 集約するのもいろんなスクリプトが混在 ◯メリット ・プラグインアーキテクチャ in/outに合わせてプラグインが用意/開発可能 ・フォーマットがJSON アプリでの解析が楽 ・HA構成が可能 ◯実績がない？→ 誰が使ってる？ COOKPADとか、NHNとか ◯次期バージョンの構想 ・設定ファイルで色々とらくできるよ。 ・MessagePackのv5に対応 ・td-agent-lite などなど ◯QA Q：時刻にミリ秒を持つことは可能？ A：互換性も気になりますが、検討します。 Q：JSONで構造化が売りだが、Flumeとかはテキストだけど、テキスト A：ログのパース時にやるというスタンス。 Q：日本語ドキュメントがやっぱり欲しい。手伝います！ A：別ブランチで翻訳しながら公開して欲しいし、バラバラにやるよりいいので。 Q：Windowsでも動かしたいけど、cool.ioの移植とか考えてないですか。 A：次期で、fluentdのコアからはcool.ioを外す予定です。 ◎「Logging Infrastructure in PaaS by Fluentd」　Rakuten, Inc.　Yohei Sasaki (@yssk22), Waldemar Quevedo (@wallyqs) ◯Cloud Foundryの説明 ◯Cloud Foundryの問題点 解析しようにもログが消えてしまう。。。 なので、Fluentdでログを集める仕組みを作ったよと。 これかな？ https://github.com/rakutentech/dea/ ◎「Fluentdを優しく見守る監視事例」　株式会社ドリコム　外道父 ( @GedowFather ) ◯概要： Fluentdをより穏やかに安定稼働させるための監視項目と自動処理について。また，その実運用における障害例なども紹介したいと思います。 ◯目次 ◯動作環境 ・IDCもバラバラな環境のログを一箇所に集約。 グローバルなネットで、圧縮、暗号化し、VPN使ってない ・tailのプラグインを改良して利用 copy、flow counterを利用 forwardも改良 Flume OGとは比較にならないし、FlumeNGはOGと全然違うから論外だった。 ◯ローカル監視 ・monit使って監視してる。 ログを記録してるか、内容が正しいか td-agentが正しく起動してるか、Collectorに送っているか 重複起動してないかとか、起動してるかとか。 ※重複起動でログが増えてた（@mazgi濡れ衣事件） HDFSに送ってるか、保存されてるか ◯リモート監視 アラート/グラフ作成の集約 状態の可視化 Collectorのキャパシティ管理 Agentにキャパシティの心配はほぼないが、Collectorは足りなくなる可能性がある。 ◯野望 CollectorでAgentを把握したい ◯QA Q：圧縮はどうやって？ A：forwardを改造してやっている。 ◎QAタイム Q：秒間どのくらい出るの？ A；秒間8000メッセージくらいらしい。 Q：ハートビートの取りこぼしは？ A：案1：UDPじゃなくて、TCPにする。案２：TCP接続してたらハートビートのカウントとしてしまう。 Q：CollectorのCPUに影響があるのってなに？ A：ロックがCPUを食う＝ロックが影響→リクエスト量を減らす Q：Windows対応はいつ？（発生源がWindows） A：td-agent-liteをWindows対応にしたいと思ってる。 Q：F#の実装とかテストは？ A：性能値の測定までは行ってない。メッセージが送れたなぁくらい。 Q：設定のDSL化はv11ではなくなったの？ A：ホスト名は入れたい。設定はやっぱり設定だけにしたい（プログラムは入れたくない） プラグイン側がDSL対応してればDSLできるようなものは入れようかと思ってるが、 DSLは延期したい。 A（tagomoris）：DSL化したいパターンが幾つかに絞れるなぁと思ってて、それに合わせたプラグインをいくつか作ってるよー。 ◎「Fluentd \u0026amp; Treasure Data でこっそり始めるログ集計」　CROOZ 株式会社　池田 朋大（ @mikeda ） ◯概要： FluentdとTreasureDataプラットフォームを使って、1インフラエンジニアが勢いでログ集計システムを作ってみたお話です ◯アクセスログ、エラーログ、メールログ（試験中）を集めてる。 ◯TreasureData 500Gまで無料なのかー。 ◯ダマで入れてもばれないぞ！ ◯最後は心の目で見えるスライドでした。 ◎祝・O\u0026#39;Reilly HBase 訳本発売。訳者本人によるPR。　Sky株式会社 玉川 竜司　※ O\u0026#39;Reillyの新刊「HBase 」　http://www.oreilly.co.jp/books/9784873115665/ ◎懇親会 そうそう、ステッカーもらったのでアンケート書きましたｗ ","date":1345657200,"dir":"post/2012/","id":"775894425f5a7436f56fc5a3b4a2cfaa","lang":"ja","lastmod":1345657200,"permalink":"https://blog.johtani.info/blog/2012/08/23/fluentd-meetup-in-japan--2--fluentd-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-08-23T02:40:00+09:00","summary":"興味をもちつつ、触っていない軟弱者ですが、興味があるので今回も話を聞きに行って来ました。 まずは、作者古橋さんによるFluentdの魅力や次期","tags":["勉強会"],"title":"Fluentd meetup in Japan #2 #fluentd に参加しました。(Jugemより移植)"},{"contents":"またまた飲みに行って参加してきました。 今回は、Rails、iOSでのTwitter連携の話から、ツイート分析、クライアントアプリの開発の苦労？楽しい話と、 幅広い話題でこれまた面白かったです。\nRailsはあとで、もう一回資料＋ビデオがみたいかも。あと、発表者の方が言ってたけど他の言語の似たようなサンプルがあると面白いかも。（Solr入門みたいに同じ題材で違う言語のサンプルとか）\nツイート分析は、私の使い方とは異なる分析結果がちょっと意外でした。土日はあんまりツイートしないからなぁ。 利用時間帯とかは、他のSNS（Facebookとかmixiとか）の分析と比較してみると面白いのかも。 まぁ、深夜帯はそれほど利用は無いだろうけど。\nAttaccaは自社や自宅でコーディングするときに利用させてもらってます。 どうしても自分のお気に入りのリストを作ってそれを聞くので満足しちゃうんで、 他の人のお気に入りも一緒にシャッフルして再生とかできると面白いかもなぁ。 もう少し、他にも曲を発見したいんだけど、その導線がもう少しうまく行くと嬉しいかも。\nチャーハン諸島の話は開発者の原点みたいな話で面白かった。やっぱり、自分で作るの大事だよなぁと。 作りたいと思うものがあるのはいいことだし、実際作ってみないとわからないこともいっぱいありますよねぇ。 ただ、何か作ろうかなぁと思うものがあるのはちょっとうらやましいとも思いました。 なかなかサービスとか、ほしいものを作ろうと思うところまで行かないからなぁ。年取ったのかなぁ。\n懇親会では、いつものように@twtrfkさんと喋って、あと Lytroを触らせてもらいました！ 思ったよりも大きいのが第一印象。 ぱっと見で、何の変哲もないところがズームするところだったりと、インタフェースがちょっとおもしろかったです。 ピントが後から合わせられるということで、どうしても同じ構図になっちゃうのがなぁという話も聞けましたｗ けど、ちょっと欲しいかもなぁ。動くものを撮るとどんな感じなのかも聞くんだった。\n次回は9月中旬！らしいので、余力がありそうだったらまた遊びに行きます。\n日時：2012/08/01 19:00 ～ 21:00 場所：デジタルハリウッド東京本校 1Fセミナールーム\nいつもの自己紹介タイム\n@i7a16k(@_gifteeの中の人)　スライドはこちら\n「RailsでTwitter連携アプリをサクっと作る」 ・まずは、Railsの紹介 MVC+routes.rbの紹介 ・Dev Twitterの登録する必要なとことか。 ・Railsのインストールから起動まで。 ・実際にログイン画面を作成するまでの紹介 コーディングするコマンドの紹介。動画付き omniauth_twitter ってのを使うみたい。 ・サインイン、サインアウトまで。 ツイートは次回！ 録画がよくできてて、それに合わせてしゃべるのもうまいなぁ。 @teapipin(ツイッター分析シリーズ の方)　スライドはこちら\n「約173万ツイートを調査して分かったTwitterの利用動向」 ・ハンドル名は午後の紅茶からきてる？＋ピピン＠ ・ブログで色々公開してます。 ・サービス作るのに、下調べをしてみましたというお話 情報が無かったから、自分で調べてみたよと。（すばらしい） ・Streaming APIで取得 タイムゾーンとか言語設定の取得でもうまく取れない。。。 ということで、UnicodeBlockで判定してみたけど、、、 最後は手作業で不要データを除去（すごい！） ・4日間で172万ツイート （金環日食とかスカイツリーのイベントがあったので、4日間で我慢） ・上位5個で50%を占めるクライアントみたい ・日曜日が多いらしい ・携帯が60%くらい ・位置情報（Geoタグつき） 日本が多い。4sqが40%占めてる。 店舗情報や天気情報などもあるらしい。 人口と関係した相関が散布図でわかった。 そこで、ツイート内容との関係を分析 あとで資料みたいなー @i2key(#attacca の関係者)　スライドはこちら\n「iOSのTwitterFrameworkを使ってみたら・・・・」 ・Twitter4Jのほうが楽だったよー デモがいいね！ ・アーキテクチャ play!をバックエンド。Amazonとか。 iOS Twitter framework ・Reverse Authの使い方とか。 申請してから、20日間かかった。 @Mocel(チャーハン諸島 開発者)　スライドはこちら\n「(仮)Twitter クライアントの開発とかについて」 ・趣味プログラマー ・「ラーメン大陸」のクローン：「チャーハン諸島」を開発 Excel溶けこむGUI Javaで実装 コマンドライン風のTL画面もある（自分では使ってないけど） 「電力会社の電力使用量モニター」もクライアント初搭載！ ラーメン大陸のバージョンチェックも可能ｗ ・開発したことで 自分のニーズにジャストフィット 優しい気持ちになれる（苦労がわかる） Twitter APIのテストとかもすぐ試せる ・GUIアプリ開発のノウハウも手に入るからオススメ ・API利用規約は読んどこうね ・自動アップデート機能がいるよ。→バージョンごとのサポートがなくなるよ。 ・通信エラー前提で作りましょう ・鍵付きの非公式RTはやめなさい。 ・Twitterクライアントの作成はおもしろいよ！ 反応がプレッシャーになることもあるけど。 おもしろ機能をつけるのがいいよーと 話が上手で聞きやすかった。 ","date":1343875800,"dir":"post/2012/","id":"8a29f62d1bebfe7b8008d7f264b56b4e","lang":"ja","lastmod":1343875800,"permalink":"https://blog.johtani.info/blog/2012/08/02/twitter-%E5%8B%89%E5%BC%B7%E4%BC%9A--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-08-02T11:50:00+09:00","summary":"またまた飲みに行って参加してきました。 今回は、Rails、iOSでのTwitter連携の話から、ツイート分析、クライアントアプリの開発の苦労","tags":["勉強会"],"title":"Twitter 勉強会 #twtr_hack に参加しました。(Jugemより移植)"},{"contents":"ということで、ステッカー欲しさ？に勉強中の話を恥ずかしげもなく偉そうにしゃべってきました。 #pyfesは以前から、気になっていたんですが、タイミングがあわず初の参加になりました。 TwitterのプロフィールにSenseiDBに興味あると書いていたら、@voluntusさんに声をかけていただけて、 さらになぜかelasticsearchの話をすることにして話をしてきました。 まだまだ、いろんな意味（プレゼン的にも内容的にも）で至らない所だらけだったので反省しまくりですが、 これでまた経験値が稼げたかなと。次回に活かしたいと思いますです。 やっぱり、しっかり勉強して、シナリオを練ってから発表しないとダメですね。。。\n発表のスライドは一番最後にリンクを用意しておきましたので、興味があれば見てもらえればと思います。\nということで、いつものメモを残しておきます。\n日時：日本オラクル青山センター 場所：2012/07/28 10:00 - 20:00 概要：こちらにページあり\n前半（10時から15時）はハンズオンなどをやられてました。参加せずにスライドを微調整して、他の勉強会のスライドをいじったりしてました。 以下は、15時から行われたスライドのメモになります。\n◯PyConJP の宣伝　@shomah4a（LT） 9/15-17 PythonカンファレンスJapan App Engine、Django、Sphinxなどのカンファレンスも併設 遠方参加者支援制度があるらしい。 ◯elasticsearch 入門　@johtani わかりにくい話でしたかねぇ。。。 ◯たのしいうぇっぶくろーら　@tokoroten（LT） index.htmlをクロールしまくってる社畜2.0の人らしい。 ◯Sphinxを使って翻訳してたら本が出てた話　@ymotongpoo（LT） OSSでもドキュメント翻訳でお手伝いできるよ。 そしたら、いつのまにか書籍も出せたよ。 スライド\n◯iOS関連のお話　@Seasons バイナリ解析をしてゴニョゴニョする話。 解析するのに何を使ったとか思考の遷移を説明してくれるのでわかりやすい。 スライドが大きなマインドマップを切り出した形。 ◯HBaseのお話　@shiumachi HBase 分散DB 列ファミリ思考 HBaseなんで？ RDB→シャーディング→だるい。。。 シャーディング→スケールできねー nandeHBase？ 書き込みスケールできるよ。 KVS HBaseのデータ構造 キーがいろいろな情報を含んでる キーがソートされてる HBaseのテーブル構造 リージョンがシャーディングの情報もと？ リージョン見つけなど スライド\n◯PythonではじめるGit　@mkouhei GitPython LXCホスト？ GitもPythonも初心者だわー ◯勉強会を成長させる参加者になろう　@sawonya イラストレーター（スタートアップRubyのイラスト書いた人。サインもらいましたｗ）。 参加者が増えるとなにがいいの？など。 勉強会参加に向けた勉強会の講師とかやられてるらしい。 スライド\n◯IT 系勉強会ネタ(仮)　@tmmkr アジャイルサムライを読んだ情報を共有したくなって読書会を開催してみた！ ビアバッシュのケータリングとかは楽天デリバリーとか、カクヤスがいいよ。 かなり、いいスライドなので、あとで見返す。 今、読書会やったりしてるし、Solr勉強会の役にも立てそうだし。 スライド\n◯Do not invent your RNG...　@kenji_rikitake Androidの乱数のコードがすごいらしい（ひどい） Pythonの乱数ではos.urandomを使うのが安全です。 オレオレ乱数は作っちゃ駄目！ ◯分散ファイルシステム（LeoFS）　@yosukehara LeoFSの開発者の方。 Erlangで98%書いてある。 Masterノードは存在しない。SPOFになるから。 分散システムとして元にした概念とか論文ってあるんだろうか？ ◯継続的デリバリー　@troter CIとデリバリーの話。 いいこと書いてあるんだけど、実際のツールの話しがないのが辛いこともある ということで、Python周りのツールをこうして見たよというお話。 Rubyの方がものがいろいろ揃ってるらしい ◯クライアントサイドのみで作ったダッシュボード　@takufukushima RESTアクセス用のUIのフロントエンドの話？ JSのお話の？node.jsとかの話。 MVCにしたり、CSSフレームワーク使ったり。 backbone.jsつかってるらしい。 実際の画面がみたいなぁ。 現状の話なので、 ◯Meinheld　@mopemope Python3対応とかLoggerとかやってから秋くらいに出るみたい。 このあたりは未知の領域です。。。 ◯3分間で開発環境構築 @tk0miya Vagrant＋Chefみたい。 VeeWeeってのでIOSイメージからVMイメージを作ってくれる。 （githubから持ってこないといろいろ古いらしい） これ、重要だと思う。 実践するようにしよう。 手順書がわりにChefのレシピを書こうよと。 環境マニア募集中！ 継続的デリバリー座談会やってます ◯筋トレ講座　@hiroki_niinuma ジムに通い続けるのはキツイ。 成功率5% 以下の条件に ・10時間以下の仕事時間 ・ジムが近い ・ジムという環境が好き ベンチマークｗ先入観を捨てましょうとｗ ジムで筋トレとかよりも歩くのが全然いいよと。 togetterがあったのでリンク。 http://togetter.com/li/346242 http://togetter.com/li/346270\nスライドはこちら。\n** [Elasticsearch入門 pyfes 201207](http://www.slideshare.net/JunOhtani/elasticsearch-pyfes-201207) ** from **[Jun Ohtani](http://www.slideshare.net/JunOhtani)** それにしても発表するといういい機会を与えてもらえて良かったです！。 継続的にelasticsearchも調べていきたいので、興味ある人は声をかけてくださいー\n","date":1343466900,"dir":"post/2012/","id":"7fa2f0877831b4c924438396760f1841","lang":"ja","lastmod":1343466900,"permalink":"https://blog.johtani.info/blog/2012/07/28/python-developers-festa-2012-07%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%97%E3%82%83%E3%81%B9%E3%81%A3%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pyfes/","publishdate":"2012-07-28T18:15:00+09:00","summary":"ということで、ステッカー欲しさ？に勉強中の話を恥ずかしげもなく偉そうにしゃべってきました。 #pyfesは以前から、気になっていたんですが、タ","tags":["勉強会"],"title":"Python Developers Festa 2012.07に参加してしゃべってきました #pyfes(Jugemより移植)"},{"contents":"今日はSolr 4.0 ALPHAの興味深い機能があったので紹介です。 数日前に「Solr 4.0: Partial documents update」という記事を見つけました。\nSolrには、ドキュメント（RDBで言うレコード）のデータを更新したい場合には、特定のフィールドだけを更新するという機能がありませんでした。 ですので、特定の項目（例えば、priceなど）を更新したい場合、ドキュメントの全データをSolrに再度上書き登録するという処理をしなければなりませんでした。 RDBを触っていた方が、Solrを始めた場合に必ず使いづらいと思われる点だと思います。\nで、4.0でその機能がありますという、「Solr 4.0: Partial documents update」の記事を見つけました。 ただ、SolrのWikiや4.0 ALPHAの紹介のページには「partial update」という記述が見当たりません。 （あれ、これかな？Update semantics） あと、まだ完成していないので、載っていないのかもしれないです。（このチケットSOLR-139が部分更新に関するもののはず。チケット番号をみても古くから望まれている機能だということがわかります。）\nということで、調べてみました。\n###機能概要\nSolrの機能として、特定のフィールドのみを更新するという機能です。 あくまでも、Solrレベルでの機能となり、Luceneの機能を利用したものではありません。 つぎのような流れになっています。\nSolrに対して特定フィールドを更新したいという形のドキュメントを投げる Solrはドキュメントを受け取ると、内部のインデックスに保存してあるデータを取り出す 取り出したドキュメントオブジェクトに対して、更新対象フィールドの値だけデータを更新する ドキュメントオブジェクトをインデックスに保存する このような流れです。 まぁ、言われてみれば当たり前な処理です。 ただし、この機能を使う場合はいくつかの前提条件があります。\n###前提条件\n前提条件はつぎのとおりです。\nすべてのフィールドをstored=\u0026ldquo;true\u0026quot;にする 「version」という特殊なフィールドを用意する 1点目は、データの保存方法についてです。 先ほど流れに書きましたが、Solrが内部に保存してあるデータを取り出して、更新対象以外のデータを保存しなおしてくれます。 このため、stored=\u0026ldquo;true\u0026quot;にしておかないと、元のデータがSolr内部で取得できません。\n2点目の「version」というフィールドは4.0から導入されたフィールドです。 SolrCloudに必要な機能としてドキュメントのバージョン管理を行うために導入されたフィールドだと思います。（あまり詳しく調べていない。。。） SolrCloud内でレプリカの更新などに使ってるのかなぁと（そのうち調べます。） 以上の2点が前提条件です。すべてのデータをstored=\u0026ldquo;true\u0026quot;としなければならない点は、インデックスのサイズや性能に関わってくるので考えて利用するほうがいいかと思います。\n###利用方法\nSolrのサンプルデータ（exampledocs/mem.xml）を例として利用します。 部分更新を行うにはつぎのような形のデータを投げると部分更新が可能です。 （JSONでの更新のサンプルについては、こちらの記事を参考にしてください。） ####XMLのサンプル（partial_update.xmlというファイルで保存する）\n\u0026lt;add\u0026amp;gt; \u0026lt;doc\u0026amp;gt; \u0026lt;field name=\u0026#34;id\u0026#34;\u0026amp;gt;VS1GB400C3\u0026lt;/field\u0026amp;gt; \u0026lt;field name=\u0026#34;_version_\u0026#34;\u0026amp;gt;バージョン番号\u0026lt;/field\u0026amp;gt; \u0026lt;field name=\u0026#34;cat\u0026#34; update=\u0026#34;add\u0026#34;\u0026amp;gt;cats_and_dogs\u0026lt;/field\u0026amp;gt; \u0026lt;field name=\u0026#34;popularity\u0026#34; update=\u0026#34;inc\u0026#34;\u0026amp;gt;10\u0026lt;/field\u0026amp;gt; \u0026lt;!-- set empty for SOLR-3502 bug --\u0026amp;gt; \u0026lt;field name=\u0026#34;price_c\u0026#34; update=\u0026#34;set\u0026#34;\u0026amp;gt;0.0,USD\u0026lt;/field\u0026amp;gt; \u0026lt;/doc\u0026amp;gt; \u0026lt;/add\u0026amp;gt; 上記サンプルのうち、バージョン番号の部分は、現在Solrに登録してある値を指定します。（Solrの管理画面で検索すれば表示されます。） 上記ファイルを「SOLR_HOME/example/exampledocs」に保存し、同フォルダにてつぎのコマンドを実行すると、部分更新されるのがわかります。 Solrに更新であるというフィールドがわかるように、fieldタグにupdateという属性を指定してあります。\njava -Durl=http://localhost:8983/solr/update?versions=on -Dout=yes -jar post.jar partial_update.xml ちなみに、上記post.jarのオプションで、「-Durl」「-Dout」を追加してあります。 「-Durl」はverions=onというパラメータを追加したいためです。 「-Dout」はPOSTした結果をターミナルに表示するために追加しています。 これらのオプションを指定すると、データ更新後のバージョンが取得できるようになります。\n####更新に利用できるコマンド？ 部分更新にはつぎの3つのコマンド？（正式名は不明）が用意されています。fieldタグのupdate属性に指定します。\nコマンド？ 説明 add 値を追加します。multiValuedのフィールドでない場合はエラーが出ます。 set 値を新規に登録しなおします。現在入っているデータは無くなります inc 指定された数値を加算（数値形式のみ） 以上が、部分更新の機能になります。 ちなみに、登録されているバージョンと更新データに入っているバージョンが異なる場合はエラーが発生する仕組みになっているようです。 それとは別に、この機能を調べていて、copyFieldのバグにぶつかってしまいました。。。 multiValuedでない、copyFieldを利用しているしている場合には注意が必要です。\n###copyFieldのバグ（SOLR-3502）\n4.0-ALPHA（3.6.0でも再現しました。）のexampleのデータで部分更新の機能を確認できると言いました。 ただし、「price_c」というフィールドのせいで、2回部分更新を行うと2回目にエラーが発生します。 根本的な問題は、部分更新ではなくcopyFieldのバグのようです。（部分更新の処理にも問題は有るような気がしますが。。。）\nバグの内容はつぎのとおりです。\nmultiValued=\u0026ldquo;false\u0026quot;のフィールドをdestに指定 srcに指定されたフィールドに値を設定（exampleのpriceフィールドに「1」を指定） destに指定されたフィールドに値を設定（exampleのprice_cフィールドに「2,USD」を指定） 上記のように設定した場合、「price_c」フィールドに、指定された値＋「price」の値がcopyにより追加されます。 通常は「price_c」フィールドはmultiValued=\u0026ldquo;false\u0026quot;なのでエラーが出るはずなのですが、エラーが発生せず2つの値が登録されてしまいます。\nこのバグのため、exampleのデータを利用して部分更新を行うとつぎのような状態が発生します。 更新を行う対象のデータはprice、price_cフィールド以外のフィールドとします。\n1回目の登録後：priceフィールド「\u0026ldquo;185.0\u0026rdquo;」、price_cフィールド「\u0026ldquo;185.0,USD\u0026rdquo;」 2回目の登録後：priceフィールド「\u0026ldquo;185.0\u0026rdquo;」、price_cフィールド「[\u0026ldquo;185.0,USD\u0026rdquo;,\u0026ldquo;185.0,USD\u0026rdquo;]」 3回目の登録：エラーが発生 部分更新の処理で、すでに登録済みのデータをSolrが自動で取り出すため、2回目の登録処理にて「price_c」の登録済みの値がSolrから取り出され、さらにcopyField設定により、「price」の値が追加されます。 本当は2回目の登録でエラーが発生すべきなのですが、バグのためエラーが発生せずに登録できてしまいます。 部分更新の処理としては、copyフィールドのdestに指定されているフィールドの値を取り出さないほうがいいような気もしますが、きちんと考えてないのでなんとも言えないです。（制約事項とする形のほうがいいかもしれません）\n","date":1342177320,"dir":"post/2012/","id":"68a8f34c240a42ab521d2f885f7aa33c","lang":"ja","lastmod":1342177320,"permalink":"https://blog.johtani.info/blog/2012/07/13/partial-update%E3%81%A8copyfield%E3%81%AE%E3%83%90%E3%82%B0solr-4-0-alpha/","publishdate":"2012-07-13T20:02:00+09:00","summary":"今日はSolr 4.0 ALPHAの興味深い機能があったので紹介です。 数日前に「Solr 4.0: Partial documents update」という記事を見つけました。 Solrには、","tags":["solr"],"title":"Partial UpdateとcopyFieldのバグ【Solr 4.0 ALPHA】(Jugemより移植)"},{"contents":" Modern Information Retrieval: The Concepts and Technology behind Search (2nd Edition) (ACM Press Books) いやぁ、蒸し暑くてなかなか寝れない日がはじまりましたね。（あんまり関係ないですね。。。）\nModern Information Retrieval 2nd Editionを輪読会という形で読み始めました。 Solrに関わって数年ですが、昔から検索をやっていたわけではありません。 なので、そろそろ基礎的、理論的なところも勉強して行かないとなと思い、この本を買いました。 ただ、約1000ページある英語の本でして。。。 一人で読むと間違いなく挫折するし、理解不能になりそうだなと。。。\nということで、Twitterで呟いたら賛同してくれる方が現れ、輪読会を開催することにしました。 イベントの開催とか初めてなので、手さぐりしながらです。（それにしても、ほんと、Twitterは素晴らしい。賛同してもらえる人が見つかったのもTwitterのおかげだし。）\nさすがに細かく読んでいくと終わらなそうなので、１周目（できれば、２周目もやりたいなぁと思ってる。１週目が１年でも終わりそうにない感じだけど）は公開されているスライドを元に進めようと思ってます。 それにしても検索周りはいろんな技術が必要なのだなぁと分厚い書籍を見て、途方に暮れつつ、楽しみでもあるなと思いながら、輪読会後の飲みを楽しんでましたｗ\nということで、各分野の専門家もいそうなので、特別ゲストとして読んできて話に混ざってもらうのも面白いかもと夢想しつつブログを書いています。 だれかいないかなーｗ\n参考URL： 書籍のHPで公開されているスライドのページです。 http://grupoweb.upf.es/WRG/mir2ed/contents.php\n","date":1342111298,"dir":"post/2012/","id":"9ac7bb94e60dc30a023ce433de027364","lang":"ja","lastmod":1342111298,"permalink":"https://blog.johtani.info/blog/2012/07/13/mir%E8%BC%AA%E8%AA%AD%E4%BC%9A%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-07-13T01:41:38+09:00","summary":"Modern Information Retrieval: The Concepts and Technology behind Search (2nd Edition) (ACM Press Books) いやぁ、蒸し暑くてなかなか寝れない日がはじまりましたね。（あんまり関係ないですね。。。） Modern Information Retrieval 2nd Editionを","tags":["勉強会"],"title":"MIR輪読会始めました(Jugemより移植)"},{"contents":"Lucene/Solrの4.0.0-ALPHAが7/3にリリースされました。\nこれに伴い、lucene-goenの4xブランチのjarファイルも4.0-ALPHAのものに置き換え、現在のtrunkの修正もマージしました。 こちらにあります。チェックアウトしてビルドしてから利用してください。\n※さすがに、jarをダウンロードできるようにすべきかもなぁ。 あと、Maven登録も。。。\n","date":1341457909,"dir":"post/2012/","id":"dcc2e24df32287e89ee3b0f64d617f57","lang":"ja","lastmod":1341457909,"permalink":"https://blog.johtani.info/blog/2012/07/05/lucene-gosen%E3%81%AElucene-solr4-0-alpha%E5%AF%BE%E5%BF%9C/","publishdate":"2012-07-05T12:11:49+09:00","summary":"Lucene/Solrの4.0.0-ALPHAが7/3にリリースされました。 これに伴い、lucene-goenの4xブランチのjarファイル","tags":["lucene-gosen"],"title":"lucene-gosenのLucene/Solr4.0-ALPHA対応(Jugemより移植)"},{"contents":"またまた参加しました。いまだ皆勤賞です。 感想などはあとで。とりあえず、メモとったので第一弾です。\nということで、感想です。 まずは、参加人数。 今回は今までで一番、ATND登録した人が多かったんじゃないかなぁと。 埋まるのも早かったですし。やっとSolrというキーワードが多くの方に触れられるようになってきたんですかねぇ。\nmixiの事例はやはり、SSDを使った11億文書のインデックスが圧巻です。 実際にマイニングに利用していて、ネガポジ分析なども行われているようで楽しそう。 TLにもありましたが、「ヤバイ」はネガ？ポジ？など、そのへんの分析方法をもう少し詳しく聞いてみたい感じもしました。 あとは、Luceneソースコードリーディングの開催が楽しみです！（候補日知らせないと。。。）\nLucene Revolution 2012の参加レポートは、自己紹介がおもしろかったですｗ ずっと検索をやらてているのもあり、色々と理論ではなく、実践的なノウハウを持っていそうで、つぎはそのあたりの話を聞いてみるのも面白そうです（発表してくれないかなーｗ） 残念ながら、私はまだスライドを見ていないので、事例を中心にピックアップして見てみようかなぁと（時間がトレない。。。）\n最後は阿部さんの4.0の紹介です。タイムリーに、前日に4.0-ALPHAがリリースされたので、 資料がすごく参考になりそうです。 SolrCloudについても詳しく書かれてたし。（ちゃんと動くのかなぁ？）\n最後は懇親会です。最近知り合った方から、発表者、昔からの勉強会の参加者といろいろな方と今回も話ができて楽しかったです。 TL上で知り合った方にもお会いできたし。 次回もしゃべってもらえそうな人を捕まえつつあるので、また企画してもらうようにつついてみようかな。\n※そういえば、毎度のことながら4.0ベースで、書籍は出さないのかって言われましたｗ\n※ちなみに、4.0-ALPHAが出たので、lucene-gosenも4xブランチの更新作業をしています。 終わったらまたブログに書くと思います。\n第8回Solr勉強会 場所：VOYAGE GROUP 会議室 日時：7/4(水)　19:00 ～ 1. ＠haruyamaさん mixi での Solr の利用 ・mixiの全文検索 2011年以前：Hyper Etraier、Tokyo Dystopia、Senna 2011年以降：Solrを利用して新規案件の検索システムの構築、入れ替えを行なっている。 ・Anuenueの論理構成など。 ・物理構成 1マスター、2スレーブ インデックスが小さい、QPSが100以下 インデックスサイズが大きいものは今後構築予定 ・今後やりたいこと ・ログ分析 ・パーソナライズ ・外部ストレージ参照のカスタム関数 ・外部ストレージをファンクションカスタム関数クエリ FunctionQueryを活用したい。 ・上記のデモ（検討中のもの？） 現在はjar内部のファイルを読んでるよと。 速度的な面がどうなるかがきになるところ。 ・テキストマイニング mixiボイス haruyamaさん入社前：ダンプして解析してた haruyamaさん入社後：Solrに載せちゃえば 600GのSSD　約11億文書 約450GB 利用してるもの：Solr 4.0（2012/01） lucene-gosen 1.2.1 自作フィルタ haruyama/solr-filter - GitHub ・利用統計の説明。 女性が多い。 「AKB」だと20代前半が多い。男性はおっさんも頑張ってる。 ・mergeindex機能を利用して、過去データとマージしてる。 1日分だけ集計したいこともあるかもしれないから。 updateじゃなくて、mergeindexなのは、ソッチのほうが早かったから。 ・拡張してる分析 ・ポジネガ分析 形容詞＞絵文字＞顔文字でスコアが効く 機械学習して辞書を調整してる ・Luceneソースコードリーディングまたやりますよ！ 2. 楽天株式会社 大須賀 稔さん Lucene Revolution 2012 in Boston参加レポート(仮) ・まずは自己紹介。 infoseekに転職→楽天→Ask.com→楽天（そして英語） ・Lucene Revolutionってなに？ ・トレーニング Scaling Search with Big Data \u0026amp; Solr Hadoopの紹介 SolrとHadoopのMapReduceを利用したインデキシングのハンズオン Solrのスケーリング（Sharding、Replication）、マルチテナント ※http://www.lucidimagination.com/services/training/big-data-training-scaling-solr 日本ではやってない、残念。 ・カンファレンス スライドとかはlucidimaginationのサイトで見れるよと。 http://www.lucidimagination.com/devzone/events/conferences/lucene-revolution-2012 ・Lucidworks Big Dataの紹介 Hadoopとかいろいろ組み合わせて使えるよと ・Microsoftの人がAzureでSolrの紹介 IEとかWindows8の話ばっかり。 ・Kuromojiの紹介 やはり、マイノリティ。 内容は日本語勉強会ｗ 中国語とかは対応するの？日本語しか知らないです。。。 ・ErickさんのSolrCloudの話 4.0は2012年にリリースする予定 スコアリングをプラガブルに。 管理系画面がリッチだよと。 ・一番重要だなぁと思ったのは。。。 「英語」！（会社的な感想ではありません。。。） Q：これはみとけ的なスライドは？ A：Hadoop上でインデキシングして、ビットトレントとかで連携してるという例が面白かった。 Q：FASTとかと比べてSolrってどーなの？ A：ESPは洗練されてる。クローラーとか、ベイシスのトークナイザーを内包してるとか。 Solrは言語処理系が弱かったとかあるけど、そろってきてるのでは。 4.0は互角になるんじゃないかなぁ。 ESPがWindowsオンリーになるので、LinuxユーザがSolrに行きつつある。 3. 株式会社 ロンウイット　阿部さん Solr 4.0の紹介 ・Solr 4.0の主な機能の紹介 3.xは3.6が最後4.0-ALPHAが7/3に出た ・プラガブルなスコアリング BM25、Language Models、Divergence from Randomness、Information-based Models 関口さんがスライド作ってる ・FST対応 Finite State Automata/Transducer オートマトン理論を活用したもの。 TokenStreamはFSAで実装 SynonymFilterがFSTになると、オフセットが変わってくるらしいと。 ・Codecプラグイン Luceneレベルのお話。 ドキュメントをファイルに保存するときの形式をプラガブルに変更可能。 SimpleTextなどもあるらしい。テストに利用できそう。 APIレベルで、マイグレーションの必要があるかも。 ・NRT Near Real Time Search softCommitのお話 Realtime-get：IDを入れたらGETできるよと。 KVSとしても活用できるぞ～と。 ・PivotFacet Facetが階層的（？）な感じで取れる ・JOIN、pseudo-join ローカルパラメータでできるよーと。 ・SolrCloud インデックスの分散配置をやってくれる（3.6まではやってくれない） shardがダウンしたらフェイルオーバーしてくれそう Master/Slave環境 リアルタイムインデクシングとリアルタイム検索とか ・ZooKeeperIntegration実装 リーダー選出、コンフィグの管理などなど ・ManifoldCFの近況 5月にトップレベルに昇格！ http://manifoldcf.apache.org/ja_JP/index.html 0.6は7月に出そう。日本語にもなってる。すげー Alfresco Connector、ElasticSearch Connectorなども Solr Plugin for Enterprise Searchとか ","date":1341402000,"dir":"post/2012/","id":"8acc78be63e27e938ee53ec2c0b90c61","lang":"ja","lastmod":1341402000,"permalink":"https://blog.johtani.info/blog/2012/07/04/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--solrjp/","publishdate":"2012-07-04T20:40:00+09:00","summary":"またまた参加しました。いまだ皆勤賞です。 感想などはあとで。とりあえず、メモとったので第一弾です。 ということで、感想です。 まずは、参加人数。 今","tags":["勉強会"],"title":"Solr勉強会第8回に参加しました。 #SolrJP(Jugemより移植)"},{"contents":"Hadoopからはちょっと離れているのに、面白そうなネタなので参加しました。 Data Science Summit、HBaseCon、Hadoop Summitのイベント参加レポートです。\n最初の草薙さんの発表が実は一番興味を惹かれていたので、参加しました。 データの解析に関するサミットというのはなかなか聞いたことが無いのでどんな内容なのかなぁと。 ちょうどVisualizeなどに興味を持っていたり、データ解析、今後重要ですよねという話が出ていたりしていたので。 実際にデータ解析が今後重要で、どんなことに使えるのかなど、製品に偏らない内容のようで色々とためになりました。 この内容をずっと聞くのは私には無理ですw英語も数学もイマイチなので、ついていけない自信がありますｗ。 「データ分析の結果をビジネスに結び付けられる人とかが今後重要になります」という話が一番気になったキーワードでした。\nHBaseConもかなり濃い内容だったようです。 私は残念ながら、HBaseの概要の概要くらいしか知らないので、内容にはついていけてないですが。。。 Facebookがかなり活用しているようですが、残念ながらスライドが上がっていないようです。 Solrに関連する話もあったようです。HBaseとSolrを組み合わせたLilyプロジェクトに関連する話のようでした。 スライドは登録しないと見れないみたいです。\n最後はHadoop Summitの参加レポートです。 まずは、ユーザ寄りの内容を@muddydixonさんから。個人的に、Twitterの話が多いのかなぁと。 ここでも、Visualizeの話が出ていたとか。 Lucidの話もあったようです。LucidWorks BigDataの話かな？\n最後は@shiumachiさんのHadoopのプロダクト寄りのお話。 YARN（Map/Reduce2.0？）やHBaseの今後の展望など。YARNはキーワードだけ知っていたので、わかりやすい解説で、やっと理解できました。 全体を通して、HBaseが今後もっといろんな局面で使われそうだなぁと。日本語の本も7/24に出るし。（まだページが無いみたいなので、英語のほうを。）\nいつものごとく、途中でビールが入ったので後半はメモが適当ですが、楽しかったです。皆さんお疲れ様でした。\n帰り着いたら、さっそくスライドが上がってました。すごい！ スライドはこちら（2012/06/26 0時現在）\nData Science Summit / EMC Worldレポート HBaseCon 2012 参加レポート』の発表スライドをアップしました。（NTTデータ 猿田 @raspberry1123 ／岩崎） @muddydixonさんのHadoopSummit2012参加レポート @shiumachiさんのHadoopSummit2012参加レポート @muddydixonさんのブログ いろんなキーワード、特に、データサイエンス寄りの話が面白かったです。 次回はJenkins関連のようで、7/30開催みたいです。\n以下はいつものメモです。\n日　時： 2012年6月25日（月） 19:00～21:00 （受付開始 18:40） 場　所： 豊洲センタービルアネックス（NTTデータ、豊洲駅直通） ◯ Data Science Summit / EMC World レポート （EMC Japan 草薙） ・Data Science Summitのレポート 揃ってるようで揃ってないスロットの写真ｗ EMC World2012と併設 今回2回目。 ・OpeningKeynote: What We Can Predict About Prediction by Nate Silver 研究者は不確実性やリスクを包含した、現実的な予測モデルを開発すべき いろいろ ・Roundtable: Economic, Political, \u0026amp; Societal Roles of Social Data ユーザの「query-like intent」を自然言語解析と機械学習で捉える 属性だけじゃなく、活動を コンテンツからコンテキストへ、コンバージョンからカンバセーション ・Big Data Transformation - HealthMap ウィルスのアウトブレイクの検知（160日→20日）に。 ウィルス＝コンピュータじゃない方 ・Big Data Transformation - Intuit int.com？ データがあるから、こういうことが知りたいなどの新しいプロセスが 「https://www.mint.com/」 ・Big Data Transformation - InfoMotion Sports Technologies バスケのボールにセンサーつけて、試合や選手の解析に利用して、 チームが強くなったりしてるらしい。 ・Big Data Transformation - Decide.com アメリカ？の価格比較サイト ソーシャルデータを元に、買い時、売り時を予測して教えてくれる。 もうすぐ新しいモデル出るかもよ？などの噂を利用してる。 ・Analytics Maturity: Master or Novice? 2010年のアメリカの教育事情のレポート データサイエンス系の統計とかがもっと必要なんじゃないか。 ・Keynote: Navigating the Road from Business Intelligence to Data science Piyanka Jain BIの限界とか、データサイエンスの恩恵を受け入れるのに必要なもの？など システムじゃなくて、人やスキルに投資しましょう。 データ分析の結果をビジネスに結び付けられる人とか。 Panel: From Raw Data とValue Data プライバシー問題 データ品質の問題 異常値を除外するなと。最も興味深いデータになることもある。 \u0026#34;Data exhaust\u0026#34;の問題 個人が日々インターネット上で行う様々なインタラクションに関するデータの集合 相関と因果関係の区別が大変難しい。 Panel: Tapping Into the Pulse of the Data Science movement ストーリを持ってデータを語れるのが重要。 Keynote: Data Visualizeation at the Point of Influence by Adam Bly Closing Keynote: The Promise and Peril in the Human / Technology Relationship by Jonathan Harris TEDで有名な人 まとめ アメリカはこの分野での投資は回り始めている. http://www.greenplum.com/datasciencesummit/ ◯ HBaseCon レポート （NTTデータ 猿田／岩崎） ・GeneralSession HBaseの開発に参加してね。 ・レプリケーション、セキュリティ、セカンダリインデックス、スナップショット、バックアップなど特に貢献して欲しいと。 ・HBaseによりカバーできるアプリケーション領域 メッセージング、位置ベースアプリケーション、リアルタイムレコメンデーション、広告最適化 ・開発者への要望 メッセージをちゃんとして 解析用メトリクス 管理ツール ・M/Rジョブとの連携の改善 ・自動チューニングなど ・Applications ・GAPの事例 色々試してHBaseにした。 クラスタ構成、16Slave、3Master、NN Failover via NFS ※ZKはスレーブに置くと、アウト。 ・Tumblr 最初は失敗した。 OpenTSDBを経験して、Motherboy V1に。 テストフェーズまでが目的 →幾つかの知見が得られたよーと。 Motherboy V2を構築中。 ・Facebook ひと月250TBペースで増加中。。。 なんで、HBaseにしたの？ 低レイテンシ、水平スケール、一貫性重視の設計、M/Rとの親和性とか Schema V1＝Snapshot Schema Schema V2＝Split Snapshot Schema Schema V3＝Hybrid Schema HBaseのデータにさらにインデックス作ったりとか。 Schema Vertion Current＝Finer grained schema and Indexer 読み書きの単位を分析して、スキーマを分割して細かくして行っていた。 ・Operations ・HBaseで困ったよ at Facebook ・リージョンサーバに特定データ入れると連鎖的に死亡 ・サーバが死に切らないとか。 ・HBaseは落ちるときは落ちるので、しぶとく生き残れるアプリを作ってねと。 ※Facebook関連のスライドなどがあがってませんと。 ・HBaseバックアップについて Clouderaの人とFacebookの人 ・選択肢 DistCP /hbaseディレクトリまるごとコピー。一貫性が保証されない exportツール MRジョブ。1度に1つのテーブルのみ copytableツール データを別クラスタに保存 exportツールに似てる。 レプリケーション 。。。 アプリケーションから複数クラスタへの書き込み 。。。 ・ユースケース ・HBASE-5509を利用したバックアップ ・開発中バックアップ HBASE-6055スナップショット、HBASE-4618など ・Development ・HBase Schema Design　Salesforce.comの人 非正規化でやりなさいと。Joinはおすすめしないと 最後にデザインパターンが載ってると。 0.行キーの設計がすべて 1.Design for the questions, not the answers. 2.データサイズは2種類しかない。大きすぎるか、そうじゃないか。 3.コンパクトに詰め込め 4.行単位の原子性を活用する。 5.属性は行キー内に移動することができる。（Lars Georgeがfoldingと読んでいる手法） 6.エンティティをネストさせると、データを事前に集計できる。 ・HBase Performance Tuning And Organizations　Facebookの中の人 テーブルの事前スプリット オフピーク時間を設定する。（0.94で入った） コンパクション設定が効いてくるよ ・SolrのバックエンドにHBase？？？ ◯ Hadoop Summit レポート (@muddydixonさん) ・オープニングビデオは必見 ・ショーケース ・Datameerを注目した。Visualizationの専任チームがいる。 UIじゃなくて、解析部隊だけで60名 お値打価格。$2900/年 ・Azure Big Data JavaScriptで ・ショーケースLucid Solr、HBaseとかいろいろ組み合わせて。 ・Session Hadoop... 2015までにApache Hadoopに世界のデータの半分が乗るらしいと。 ・Session Realtime analytics with Storm and Hadoop フォロワのフォロワをunique処理したり。 ・Session Scalding Twitter\u0026#39;s new DSL for Hadoop ※Zipkinにも出てきたな、名前。 ・Hadoop Plugin for MongoDB ・Hadoop and Vertica The Data Analytics Platform at Twitter Twitter社でのHadoop周りのデータフローとか。 Verticaは速度がいるものの処理に利用 80-100TB/dayとか。。。 ・Keynotes ・Big data analyzing system is censor of company. ・It is difficult in blind and deaf. ・Session Large Scale Search, Discovery and Analytics with Hadoop, Mahout and Solr ※@muddydixonさんのブログにセッションに対応するスライドのリンクを公開中。http://d.hatena.ne.jp/muddydixon/20120617/1339919125 ◯Hadoop Summit レポート (@shiumachiさん) ・Hadoop1.x MapReduce 非常に安定 ・課題。。。 ・YARN（Yet Another Resource Negociator） ターゲット：6000～10000ノード 100,000以上のタスクの同時実行 10,000ジョブの同時実行 性能は倍以上 Q：これは同じプログラムを動かして？ A：。。。倍以上です！（わかんないっす。） 今後の予定 幾つかのJIRAの紹介 MAPREDUCE-4327とかHBASE-4329とか まとめ YARNは「汎用」分散処理基盤に向けて一歩踏み出したもの！ 更なる進化に注目と ・HBaseの可用性とリペア ダウンタイムを短くしよう。 障害停止7割くらい。 設定ミスが44% 不安定な機能は使うな、推奨構成を推奨！ HBase 0.92＋Hadoop 2.0 HDFS HAによる高可用性とか 将来：HBase 0.96＋Hadoop 2.x 計画停止時間削減：オンラインスキーマ変更（HBASE-1730） ローリングアップデート：バージョン間互換性が必須 HBase本読みなさい。 金があれば、サポート買ってください。 日本語HBaseトレーニング開催予定（来月） ・HBase NameNode HighAvailability ```　","date":1340642460,"dir":"post/2012/","id":"9f29c6d9719fc6bc09a2981057642b69","lang":"ja","lastmod":1340642460,"permalink":"https://blog.johtani.info/blog/2012/06/26/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC10%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/","publishdate":"2012-06-26T01:41:00+09:00","summary":"Hadoopからはちょっと離れているのに、面白そうなネタなので参加しました。 Data Science Summit、HBaseCon、Hadoop Summitのイ","title":"Hadoopソースコードリーディング第10回に参加しました。#hadoopreading(Jugemより移植)"},{"contents":"Issue 32で上がってきたlucee-gosenのUniDic対応の最初のパッチを書いたので、ブログに残しておきます。\n###UniDicとは___ UniDicとは、日本語テキストを単語に分割し，形態論情報を付与するための電子化辞書です。 UniDicの詳細や特長についてはHPを御覧ください。\n残念ながら、UniDicは利用者登録をして、利用規約に従うと利用が可能となります。 ですので、lucene-gosenでは、Ipadicやnaist-chasenの辞書とは異なり自動で辞書をダウンロードする機能はありません。\n###利用手順___ 以下が、Unidicの辞書を利用したjarファイルの作成方法となります。\n1. lucene-gosenをダウンロードし、パッチを当てる lucene-gosenのリポジトリからソースをエクスポートし、パッチをダウンロードし、パッチを適用します。 コマンドは以下のとおりです。\nsvn co . lucene-gosen-trunk-readonly cd lucene-gosen-trunk-readonly patch -p0 \u0026amp;gt; ...patch （パッチに関しては今後正式版をリリースされたら手順からは必要なくなります。）\n2. Unidic辞書生成のためのディレクトリを作成「$GOSEN_HOME/dictionary/unidic」\nmkdir dictionary/unidic 3. 対象となるUnidicの辞書のソースファイルをダウンロード 利用者登録をし、利用規約に同意の上、以下のファイルをダウンロードします。 「/」に添ってダウンロードページから遷移してダウンロードしてください。\n1.3.12個別ファイル/unidic-chasen/unidic-chasen1312src.tar.gz 4. ダウンロードしたtar.gzファイルを「dictionary/unidic/」にコピー\ncp .. lucene-gosen-trunk-readonly/dictionary/unidic/ 5. Antを実行してjarファイルの作成\nant -Ddictype=unidic 成功すれば、lucene-gosen-trunk-readonly/dist/lucene-gosen-2.1-dev-unidic.jarファイルが生成されます。 あとは、通常通り、SolrやLuceneで利用することが可能です。\n以上がjarファイルの作成手順となります。\n###制約事項（2012/06/18現在）___ 現在（2012/06/18）時点で公開しているパッチは、以下の制約が存在します。\nCOMPOUNDエントリー未対応 品詞情報（発音）の内容の制限 COMPOUNDエントリー未対応 Unidicの辞書のエントリーの中に1件だけ、COMPOUNDと呼ばれるエントリーが1件だけ存在します。 別々の単語を組み合わせて1単語として扱うことができるようになっているようです。 lucene-gosenでは、残念ながら、このような辞書の形式には対応していません。 1件しか存在しないデータでもあることを鑑みて、今回の辞書構築処理では、スキップするようにしました。\n品詞情報（発音）の内容の制限 lucene-gosenの実装上、単語の読みのバリエーション数と発音のバリエーション数には以下の制限が存在します。\n「読み」バリエーション数 ＜ 「発音」バリエーション数 「読み」に対応する形で、「発音」がlucene-gosenでは品詞情報としてデータ登録されています。 UniDicのデータには上記制約を満たさないデータが5件ほど存在します。 現在、これら5件のデータについて、「読み」に対応した「発音」データには空文字が表示されるようになっています。\nまだ、簡単に動作確認をしただけです。UniDicを利用していて問題など有りましたら連絡、Issueへのアップをしていただけると助かります。\n","date":1340028180,"dir":"post/2012/","id":"d13aa56e27fe71ef40ff153c093ecdf8","lang":"ja","lastmod":1340028180,"permalink":"https://blog.johtani.info/blog/2012/06/18/lucene-gosen%E3%81%AEunidic%E5%AF%BE%E5%BF%9C/","publishdate":"2012-06-18T23:03:00+09:00","summary":"Issue 32で上がってきたlucee-gosenのUniDic対応の最初のパッチを書いたので、ブログに残しておきます。 ###UniDicとは___","tags":["lucene-gosen"],"title":"lucene-gosenのUniDic対応(Jugemより移植)"},{"contents":"「鉄は熱いうちに打て」ということで、残りも勢いでメモ。 まだ、見直しとかしてない状態なのでおかしいところとかありますが。。。 図とか入れるのはまた今度。\nTransport（転送）\nZipkinとHadoopに異なるサービスからのトレースを送信するのにScribeを利用します。 ScribeはFacebookにより開発されました。 システムの各サーバで実行できるデーモンとして作成されています。 ログメッセージをListenし、カテゴリごとのcorrectレシーバーに配送します。 Zipkin collector daemon\nトレースデータがZipkinコレクターデーモンに配送されたらvalidかどうかをチェックしてから保管し、インデックスを作成します。 Storage\nストレージにはCassandraを選びました。 スケーラブルで、柔軟なスキーマをもっており、Twitter内部で大変使われています。 このコンポーネントをプラガブルにしようと試みましたが、困難なため、ここでは公開しません。 Zipkin query daemon\n保存、インデックスされたデータを探す方法が必要です。 クエリーデーモンはユーザに対して簡単なThriftAPIを公開しており、トレースを探すことが可能です。Thrift fileを見て下さい。\nUI\n多くのユーザはUI経由でデータにアクセスします。 VisualizeにD3を利用したRailsアプリケーションです。 UIの認証は実装していないことに注意してください。\nモジュール Zipkin内部のモジュール関連図\n##インストール___ Cassandra\nZipkinはCassandraをストレージにしています。Cassandraクラスタが必要になります。 1. Cassandraサイトを参考にしてクラスタを構築してください。 2. Zipkin Cassandraスキーマを利用します。つぎのコマンドでスキーマが作成できます。 bin/cassandra-cli -host localhost -port 9160 -f zipkin-server/src/schema/cassandra-schema.txt Zookeeper\nZipkinは協調のためにZooKeeperを利用します。 これは、保存すべきサーバをサンプルレートで決定し、サーバを登録します。？ 1. ZooKeeperのサイトを参考にインストールしてください。 Scribe\nScribeはトレースデータを配送するのに利用するロギングフレームワークです。 ネットワーク保存先としてZipkinコレクターデーモンを指定する必要があります。 Scribeの設定は次のようにします。 \u0026lt;store\u0026amp;gt; category=zipkin type=network remote_host=zk://zookeeper-hostname:2181/scribe/zipkin remote_port=9410 use_conn_pool=yes default_max_msg_before_reconnect=50000 allowable_delta_before_reconnect=12500 must_succeed=no \u0026lt;/store\u0026amp;gt; 注意：上記設定は、カテゴリーにより送信ホストを見つけるためにZooKeeperを利用するサポートのScribeのTwitterバージョンを使用する方法です。 コレクターのためのDNSエントリーを利用したりもできます。 Zipkinサーバ ZipkinサーバはScala 2.9.1、SBT 0.11.2そしてJDK6で開発しました。\n1. git clone https://github.com/twitter/zipkin.git 2. cd zipkin 3. cp zipkin-scribe/config/collector-dev.scala zipkin-scribe/config/collector-prod.scala 4. cp zipkin-server/config/query-dev.scala zipkin-server/config/query-prod.scala 5. Modify the configs above as needed. Pay particular attention to ZooKeeper and Cassandra server entries. 6. bin/sbt update package-dist (This downloads SBT 0.11.2 if it doesn\u0026#39;t already exist) 7. scp dist/zipkin*.zip [server] 8. ssh [server] 9. unzip zipkin*.zip 10. mkdir -p /var/log/zipkin 11. zipkin-scribe/scripts/collector.sh -f zipkin-scribe/config/collector-prod.scala 12. zipkin-server/scripts/query.sh -f zipkin-server/config/query-prod.scala SBTでコレクターとクエリサービスを起動します。 Scribeコレクターサービスの起動方法は次の通り。 bin/sbt \u0026#39;project zipkin-scribe\u0026#39; \u0026#39;run -f zipkin-scribe/config/collector-dev.scala\u0026#39; クエリサービスは次の通り bin/sbt \u0026#39;project zipkin-server\u0026#39; \u0026#39;run -f zipkin-server/config/query-dev.scala\u0026#39; Zipkin UI\nUIはRails3アプリです。 1. 設定をZooKeeperサーバでアップデートします。これはクエリデーモンを見つけるのに利用します。 2. Rails3アプリケーションサーバにデプロイします。テストの場合は次のようにすることもできます。 bundle install \u0026amp;amp;\u0026amp;amp; bundle exec rails server. zipkin-tracer gem\nzipkin-tracer gemをトレースしたいRailsアプリケーションにRack Handlerで追加します。 config.ruにつぎの記載をします。 use ZipkinTracer::RackHandler run \u0026lt;YOUR_APPLICATION\u0026gt; もし、アプリケーションのstatic assetsがRailsで提供されれば、リクエストがトレースされます。 ##　Running a Hadoop job\nScribeからHadoopにログを保存する設定をすることも可能です。 これをすると、Zipkin自身でオンザフライで簡単に作れないデータから様々なレポートが作成可能です。 ScalaでHadoopのジョブをかけるScaldingというライブラリを利用します。\n``` 1. Hadoopジョブを実行するためのfatなjarを作成します。 2. scald.rbをjarをコピーしたいホスト名とjobを実行するホスト名に書き換えます。 3. 必要なら、scald.rbのjarファイルのバージョンを更新します。 4. scald.rbスクリプトを利用してジョブを実行できます。\n./scald.rb \u0026ndash;hdfs com.twitter.zipkin.hadoop.[classname] \u0026ndash;date yyyy-mm-ddThh:mm yyyy-mm-ddThh:mm \u0026ndash;output [dir]\n##計測ライブラリの利用方法\u0026lt;hr\u0026gt; 計測のためのライブラリとプロトコルがちょっとだけあります。 しかし、もっと計測するための役に立つものを望んでいます。 開始する前にトレースデータがどんな構造なのかを知る必要があります。\n・Annotation - 値、タイムスタンプ、ホストを含みます。 ・Span - 特定のRPCに相当するAnnotationの集合 ・Trace - あるルートSpanにぶら下がるSpanの集合\nZipkinに送信するトレースデータです。\nこれらの詳細な記述は[こちら](https://github.com/twitter/zipkin/blob/master/zipkin-thrift/src/main/thrift/zipkinCore.thrift)を見て下さい。 その他にトレースデータの重要なものは、トレースされたサービス間でやり取りされる情報である、軽量なヘッダーです。 トレースヘッダは次のものから構成されます。\n・Trace Id - トレース全体のID ・Span Id - 個々のリクエストのID ・Optional Parent Span Id - このリクエストが他のリクエストの一部として生成されたら付与される ・Sampled boolean - トレースすべきかどうかを表すフラグ\nデータタイプについて、理解したので、どのように計測が行われるかを順をおってみてみましょう 例はFinagleのHTTPがどのようにトレースされるかを示しています。 他のライブラリやプロトコルはもちろん、異なりますが、基本的な部分は一緒です。\n\u0026lt;b\u0026gt;　サーバサイド\u0026lt;/b\u0026gt; 1. 到達したリクエストのトレースヘッダー存在するかどうかを調べます。存在すれば、なら、このリクエストに対して関連するIDとします。トレースヘッダーがなければ、サンプリング対象かどうかを決めて、新しいTrace Id、Span Idを生成します。参考には[HttpSererTracingFilter](https://github.com/twitter/finagle/blob/master/finagle-http/src/main/scala/com/twitter/finagle/http/Codec.scala)を見て下さい。 2. もし、現在のリクエストがサンプリングされる場合、サービス名、ホスト名、スパン名（例えば、http get/put）、その他のAnnotationのような情報を集めます。 リクエスト受信時には「server received」というAnnotationを生成し、処理が終了して結果を返すときに「server send」というAnnotationを生成します。 参考には[HttpServerTracingFilter](https://github.com/twitter/finagle/blob/master/finagle-http/src/main/scala/com/twitter/finagle/http/Codec.scala)を見てください。 3. 生成されたトレースデータはServerBuilderにより設定されたトレーサーに渡されます。 デバッグのためのConsoleTracerが例としてありますが、ZipkinTracerになります。 トレースデータを[ZipkinTracer](https://github.com/twitter/finagle/tree/master/finagle-zipkin)が受け取った時、Span Idにより集約されます。 4. ZipkinTracerが\u0026#34;end of span\u0026#34;イベント（\u0026#34;server received\u0026#34;アノテーションやタイムアウトのような）を受け取ると、Thrift構造としてデータを集約してScribeに送ります。もし、そのようなイベントが発生しない場合、ZipkinTracerはいつかそのデータを送信します？？？おかしい？。データ送信のための他の方法も追加します。 ThriftやScribeのようなものですが、JSONやHttpかもしれません？ \u0026lt;b\u0026gt;　クライアントサイド\u0026lt;/b\u0026gt; 1. リクエストを送る前にそれがトレースの一部かどうかをチェックします。 サーバで利用されているとします。　サーバは、リクエストを処理してすでに付与されているトレースIDを割り当てます。 トレースIDを再利用しますが、この新しいリクエストには新しいスパンIDを生成します。 また、親のスパンIDが存在すれば、前のスパンIDに設定します。 [ここ(TracingFilter)](https://github.com/twitter/finagle/blob/master/finagle-core/src/main/scala/com/twitter/finagle/tracing/TracingFilter.scala)や[ここ(Trace)](https://github.com/twitter/finagle/blob/master/finagle-core/src/main/scala/com/twitter/finagle/tracing/Trace.scala)が参考になります。 2. サーバサイドと同様に、送信されるHttpリクエストにトレースヘッダーを追加するための[HttpClientTracingFilter](https://github.com/twitter/finagle/blob/master/finagle-http/src/main/scala/com/twitter/finagle/http/Codec.scala)があります。 3. リクエスト送信前の「client send」やサーバからの返信を受信した「client receive」のようなアノテーションを生成します。 4. サーバサイドと同様に、データがZipkinにデータを送るZipkinTracerに到達します。 ","date":1339772520,"dir":"post/2012/","id":"9ccda414c322ebcdf875eacbba2e4b7e","lang":"ja","lastmod":1339772520,"permalink":"https://blog.johtani.info/blog/2012/06/16/zipkin%E3%81%AEreadme%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%81%9D%E3%81%AE%EF%BC%92%E6%AE%8B%E3%82%8A/","publishdate":"2012-06-16T00:02:00+09:00","summary":"「鉄は熱いうちに打て」ということで、残りも勢いでメモ。 まだ、見直しとかしてない状態なのでおかしいところとかありますが。。。 図とか入れるのはま","tags":["Zipkin"],"title":"ZipkinのReadme読んでる（その２、残り）(Jugemより移植)"},{"contents":"ZipkinのGithubにあるReadmeを読んでます。 せっかくというか、頭が悪いので読みながら内容をメモ。 まずは、アーキテクチャとトレースデータ送信のためのクライアント側あたりです。 （誤訳とかおかしいだろというツッコミ大歓迎です。） あとで、リンク貼ったり絵を入れたりするかもしれませんが、とりあえず。\n◯アーキテクチャ（図はこちら）\n・対象とするサービスからScribeでデータを収集し、ZipkinのCollectorに投げる ・CollectorはCassandraにデータを格納 ・WebUIからはQueryでCassandraに問い合わせを行なってデータ取得 ・Scripe、CollectorはZookeeperと連携している（妄想） ◯計測用ライブラリ（図はこちら。図のSと書かれた青い箱）\n・各ホストの計測用ライブラリがトレースデータを集めてZipkinに送信する。 ・ホストは他のサービスへリクエストを飛ばすときに、リクエストにトレース用のIDを付与してます こうすることで、データをあとで、束ねることが可能となります。 ◯計測ライブラリの利用方法 ・Finagle\nJVMのための非同期ネットワークスタックである。 それは、JVMベース言語（JavaやScalaなど）で非同期RPCのクライアント・サーバを構築するのに利用できる。 FinagleはTwitterの内部ですごく利用されていて、トレースサポートを実現するのに当然のポイントです。 現時点で（Finagleは）ThriftやHTTP、Memcache、Redisのクライアント・サーバサポートも持っています。 ScalaでFinagleサーバをセットアップするのはつぎのようなコードになります。 トレースを追加するには、finagle-zipkinを追加して、ServerBuilderのtraceFactory関数を呼ぶだけです。\nServerBuilder() .codec(ThriftServerFramedCodec()) .bindTo(serverAddr) .name(\u0026#34;servicename\u0026#34;) .tracerFactory(ZipkinTracer()) .build(new SomeService.FinagledService(queryService, new TBinaryProtocol.Factory())) クライアント側も同様です。 上記のようにサンプリングしたリクエストにZipkinトレーサーを指定することで 自動的にトレースできるようになります。 サービスやホストでのリクエストの開始と終了を記録できます。 さらに付加的な情報を記録したい場合は、つぎのようなコードを追加します。 Trace.record(\u0026#34;starting that extremely expensive computation\u0026#34;) 上記コードは、上記コードが実行された時間に文字列を付加できます。 キーバリュー情報を付加したい場合は次のようになります。 Trace.recordBinary(\u0026#34;http.response.code\u0026#34;, \u0026#34;500\u0026#34;) Ruby Thrift\nリクエストのトレースに利用できるgemもあります。 リクエストに対してトレースIDを生成し、リクエストに付与し、トレーサーにプッシュするのにRackHandlerのgemを利用できます。 トレーサをトレースするサンプルはzipkin-webを参照。\nRubyからトレースクライアントをコールするのに、Twitter Ruby Thrift clientを使います。 つぎのようなコードを書きます。\nclient = ThriftClient.new(SomeService::Client, \u0026#39;127.0.0.1:1234\u0026#39;) client_id = FinagleThrift::ClientId.new(:name =\u0026gt; \u0026#34;service_example.sample_environment\u0026#34;) FinagleThrift.enable_tracing!(client, client_id), \u0026#34;service_name\u0026#34;) Querulous\nQuerulousはScala用のSQLデータベースのインタフェースライブラリです。 SQLクエリの実行のタイミング情報をトレースに追加できます。 Cassie\nCassieはFinagleベースのCassandraクライアントライブラリです。 CassieのトレーサーはFinagleの例とほぼ一緒ですが、 CassieではKeyspaceBuilderに設定します。 cluster.keyspace(keyspace).tracerFactory(ZipkinTracer()) とりあえず、ここまで。___ 2012/06/22 リンクを貼って体裁を修正\n","date":1339721820,"dir":"post/2012/","id":"69f755dd5b9e90a99c3086543790541c","lang":"ja","lastmod":1339721820,"permalink":"https://blog.johtani.info/blog/2012/06/15/zipkin%E3%81%AEreadme%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E5%91%A8%E3%82%8A%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-06-15T09:57:00+09:00","summary":"ZipkinのGithubにあるReadmeを読んでます。 せっかくというか、頭が悪いので読みながら内容をメモ。 まずは、アーキテクチャとトレー","tags":["Zipkin"],"title":"ZipkinのReadmeを読んでる（クライアント周りについて）(Jugemより移植)"},{"contents":"久々にSolrの話です。 といっても、結構前からの話でして。。。\nschema.xmlのfieldTypeの設定に「autoGeneratePhraseQueries」という属性があります。 Solr3.1で導入されました。動作に関しては関口さんのブログで説明されています。 Solr 1.4までは、Analyzerがトークンを複数返してくる場合（例：lucene-gosenで「Solr入門」という文字列を入れた場合など）にフレーズクエリとして処理していました。 Lucene 3.1.0から、この処理がデフォルトfalse（つまり、フレーズクエリにならない）という挙動になりました。（詳しくは関口さんのブログで。） ただ、Solr 3.1.0では、下位互換性を考慮して、autoGeneratePhraseQueriesの設定値はデフォルトが「true」でした。\nこのデフォルト値がSolr 3.3以降で提供されているschemaのバージョン（1.4以上）からデフォルト値が「false」に変更されています。 schemaのバージョンを1.3以前のものから1.4以上に移行する場合は注意が必要です。\nとまぁ、偉そうに書きましたが、私もちゃんと追えてませんでした。 Solr勉強会第６回で、関口さんの発表できちんと説明されていて、参加してたのに聞けてなかったですし。（メモ取ってるのに、書いてない。）\nということで、Solr入門のサンプルschemaも少し修正しました。 こちらとこちらの記事に追記してありますので、参考にしてください。\n","date":1339603740,"dir":"post/2012/","id":"277f7f2177e2a265a62680ea0158f9b9","lang":"ja","lastmod":1339603740,"permalink":"https://blog.johtani.info/blog/2012/06/14/autogeneratephrasequeries%E3%81%AE%E3%83%87%E3%83%95%E3%82%A9%E3%83%AB%E3%83%88%E5%80%A4%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-06-14T01:09:00+09:00","summary":"久々にSolrの話です。 といっても、結構前からの話でして。。。 schema.xmlのfieldTypeの設定に「autoGeneratePh","tags":["solr"],"title":"autoGeneratePhraseQueriesのデフォルト値について(Jugemより移植)"},{"contents":"すでに読まれた方もいるかも知れませんが、気になったのでメモを書いてみようかと。\n先週の木曜日にTwitterのエンジニアブログでZipkinというOSSを公開したという記事がでました。 非常に興味深いシステムだったので、ちょっとずつ読み解いていきたいなという宣言（というか、ハッパをかけてもらうため）も兼ねて、まずはブログの内容をメモ程度に残しておきます。\nZipkinは分散トレースシステム（distributed tracing system）です。Twitter APIの１リクエストを構成する様々なサービスのタイミングデータ（計時データ）を集めるために作りました。 Firebugのような性能プロファイラのよなもので、しかもバックエンドのサービスもプロファイル可能です。 ZipkinはAPLv2ライセンスでOSSとしてGithubで公開しています。\nZipkinはWebのユーザインタフェースを持っています。（元記事参照） 各サービス（縦軸）でどのくらい時間がかかっているか（横軸）がわかり、クリックすることでより詳細な情報が得られます。 Zipkinはパフォーマンス改善の余地のある部分（遅いMySQLのSELECTなど）を見つけるのに役立ちます。\nZipkinはどのように動くの？ Twitterに届いたリクエストからサンプリングしたリクエストに対してトレース可能なIDを付与して、すべてのサービスに渡していきます。 全リクエストの一部をサンプリングすることで、トレースのオーバヘッドを減らし、常に本番環境で利用できるようにしています。 Zipkinコレクタ（collector）が、Scribe経由でタイミングデータを受け取り、Cassandraに保存してインデックスを作成します。 Zipkinクエリデーモンがインデックスを利用して、WebUIにトレースデータを見つけます。\nZipkinはHack Weekで開始されました。 最初はThriftに対するGoogle Dapperの論文の基本的な部分の実装から始まり、現在ではHttp、Thrift、Memcache、SQL、Redisリクエストをサポートしています。 これらはFinagleライブラリで経由で動作します。Rubyのgemも用意してあります。\nということで、ほぼ直訳ですが、何かの役に立てればと。 ちょっとずつですが、Githubのページやソースを読みながら記事を書いていこうと思っています。\n","date":1339515600,"dir":"post/2012/","id":"ee48516e57684c5a4c22adccac34be92","lang":"ja","lastmod":1339515600,"permalink":"https://blog.johtani.info/blog/2012/06/13/twitter%E3%81%8C%E5%85%AC%E9%96%8B%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%B3%E3%82%B0%E8%BF%BD%E8%B7%A1%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0zipkin/","publishdate":"2012-06-13T00:40:00+09:00","summary":"すでに読まれた方もいるかも知れませんが、気になったのでメモを書いてみようかと。 先週の木曜日にTwitterのエンジニアブログでZipkinと","tags":["OSS"],"title":"Twitterが公開した分散トレーシング（追跡？）システム、Zipkin(Jugemより移植)"},{"contents":"lucene-gosenの最新版（2.0.1）をリリースしました。\nプロジェクトページよりダウンロードが可能です。\n今回の修正では、@haruyama さんからいただいていたパッチの取り込み（リソース周りの改善など）が主な対応となっています。 また、コンパイルに利用するjarファイルがLucene/Solr3.6.0に変更になっています。（Issueはこちら） 3.6.0から追加されたテストケースにて、発生する問題への対処も施したものとなっています。\n","date":1339059234,"dir":"post/2012/","id":"216db319052b5742fc68862cb2f39905","lang":"ja","lastmod":1339059234,"permalink":"https://blog.johtani.info/blog/2012/06/07/lucene-gosen-2-0-2%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E5%91%A8%E3%82%8A%E3%81%AE%E6%94%B9%E5%96%84%E3%81%AA%E3%81%A9/","publishdate":"2012-06-07T17:53:54+09:00","summary":"lucene-gosenの最新版（2.0.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、@haruy","tags":["lucene-gosen"],"title":"lucene-gosen 2.0.2リリース（リソース周りの改善など）(Jugemより移植)"},{"contents":"昨晩に引き続き、情けない内容のブログになってしまいますが。。。\n昨晩、書いた記事の調査をしていた時に気づいた、問題になるケースがあったので調査をしていました。 Issue32に登録した内容になります。 拙い英語を振り絞って書いた英語なので、伝わらないかもしれないのでブログに残しておきます。 昨晩の問題点となったクラス（StreamTagger2.java）の内部処理についてです。 lucene-gosenのLucene向けのTokenizerの内部処理では入力文字列の処理を行うのに、「char buffer[]」を用いて 入力文字列をReaderから読み込むときにバッファリングしています。 このバッファリングにて、特定のケースにて、想定していない場所を単語の切れ目と認識してしまう問題が実装上存在しました。 Issue32に記載した内容は次のようになります。\n上記バッファは4096文字というサイズで固定になっています。 StreamTagger2クラスでは、この4096文字をオーバーするような文字列の場合に、つぎの処理により、4096文字以下の場所に文章の区切りを探そうとします。\n4096文字以上の文字列が入力される バッファに入れられるだけの文字（4096文字）をバッファにコピーする。 バッファの後ろから、つぎの5種類の文字を探索し、見つかった場合（場所をkとし、ｋ＞０の場合）は、その場所を文章の切れ目と判定して、0からk+1文字目までの文字をStringTaggerを利用して形態素解析する。 あとは、繰り返し 上記条件に合致しない場合は、4096文字を文章とみなして形態素解析を行います。 ここで、5種類の文字は以下のとおり。\n0x000D:CARRIAGE RETURN(CR) 0x000A:LINE FEED(LF) 0x0085:NEXT LINE (NEL) 0x2028:LINE SEPARATOR 0x2029:PARAGRAPH SEPARATOR 見ての通り、制御文字ばかりです。 この5文字以外は切れ目と判断してくれません。 ということで、4097文字の文字列が存在し、上記5種類の文字が一度も出てこない場合、バッファのサイズで文字列が途切れてしまい、想定しない区切り位置で区切られた文章に対して形態素解析が実行されてしまいます. HTMLから文字列を抜き出して解析したり、長い文書を解析する場合に、改行文字を削除して処理するといったことも考えられます。 上記5種類の文字列のみで文章の区切り位置を判断してしまうのは問題ではないかと。 まずは、4096文字内に「。」句点が存在した場合に、その部分を区切り位置として認識するようなパッチを記載して、Issue32に添付しました。\n「。」句点を採用した理由はつぎのとおりです。 StreamTagger2では、上記バッファリングした文字列を更に、BreakIterator.getSentenceIterator(Locale.JAPANESE)にて取得したBreakIteratorにて文節単位に区切ってから、各文節ごとに形態素解析を実施しています。 ということは、BraekIteratorにて分節の区切りとして判断される文字については、上記の文字種に追加しても問題無いという判断からです。 ただし、この修正でも、純粋に4096文字以上、句点が出てこない場合には区切り位置がおかしなことになってしまいますが。。。 もう少し、BreakIteratorの挙動を調べて、他にも利用可能な区切り文字が存在しないかを調査していく予定です。。。\n1年以上コミッターをやっているのに、こんなことも理解していないのかよいうツッコミを受けてしまいそうでなんとも情けない話です。。。 まずは、現状報告でした。\n","date":1338913260,"dir":"post/2012/","id":"cbf9587a8187985725963b8bfc67004d","lang":"ja","lastmod":1338913260,"permalink":"https://blog.johtani.info/blog/2012/06/06/issue32%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A64096%E3%81%AE%E5%A3%81/","publishdate":"2012-06-06T01:21:00+09:00","summary":"昨晩に引き続き、情けない内容のブログになってしまいますが。。。 昨晩、書いた記事の調査をしていた時に気づいた、問題になるケースがあったので調査","tags":["lucene-gosen"],"title":"Issue32について（4096の壁）(Jugemより移植)"},{"contents":"久々にlucene-gosenを触っています。 trunkのlibにある、jarファイルが3.5ベースだったので、3.6ベースにしてテストをしたところ、 いくつかある、ランダムテストで結果の不整合が検出されたので、調査していました。 先程、trunkに対応版をコミットしました。もう少しテストケースを追加してからリリースします。 おそらく、通常の使い方では問題無いと思います。\nLuceneでは、ランダムな文字列を利用したテストが実装されています。 lucene-gosenでもこのテストを利用してランダムなテストをしています。 実際にはtest/以下のorg.apache.luceneパッケージにテストケースがあります。 今回、jarファイルを差し替えた時に、このランダムなテスト実施にて、assertが失敗するケースが発生しました。\n原因究明までに、いくつかフェーズがあったので、忘れないように書いておきます。\n1.ランダムテストのテストケースにてエラーがassertが失敗するケースが発生 ※ただし、成功する場合もあり。 2.該当のテストを再現しつつデバッグ＋該当のテストがどんなものかを解読（勉強不足。。。） ※テストは、失敗した場合につぎのようなメッセージが表示され、同じテストが再現可能です。 以下、エラーの出力例。「NOTE: reproduce with: 」のあとにあるantコマンドを実行すれば、同じテストが再現可能です。\n[junit] ------------- Standard Error ----------------- [junit] TEST FAIL: useCharFilter=false text=\u0026#39;wgxznwk\u0026#39; [junit] [junit] ===\u0026gt; [junit] Uncaught exception by thread: Thread[Thread-3,5,main] [junit] org.junit.ComparisonFailure: term 0 expected:\u0026lt;w[gxznwk]\u0026gt; but was:\u0026lt;w[]\u0026gt; [junit] at org.junit.Assert.assertEquals(Assert.java:125) [junit] at org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:146) [junit] at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:565) [junit] at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:396) [junit] at org.apache.lucene.analysis.BaseTokenStreamTestCase.access$000(BaseTokenStreamTestCase.java:51) [junit] at org.apache.lucene.analysis.BaseTokenStreamTestCase$AnalysisThread.run(BaseTokenStreamTestCase.java:337) [junit] \u0026lt;=== [junit] [junit] NOTE: reproduce with: ant test -Dtestcase=TestGosenAnalyzer -Dtestmethod=testReliability -Dtests.seed=4ad9618caecb9fb2:d5476c03b8172df:-9c569f70013ffbb -Dargs=\u0026#34;-Dfile.encoding=SJIS\u0026#34; [junit] ------------- ---------------- --------------- [junit] Testcase: testReliability(org.apache.lucene.analysis.gosen.TestGosenAnalyzer):\tCaused an ERROR 3.デバッグの結果、Luceneのtest-frameworkにある「MockReaderWrapper」というクラスの影響を確認 LuceneのJIRAのLUCENE-3894にて追加されたクラスであるとわかる。 このクラス、Readerのreadメソッド内部で、ランダムな値を元に長さを途中で返すという実装のReaderになっている。 （全部で18文字の文字列なのだが、ランダムな値を元に、12文字として結果を一旦返すという仕組みが実装されている） 4.lucene-gosenの問題箇所を特定。 Readerが途切れた部分を分節として扱ってしまう実装になっていた。 該当の部分に修正をいれてコミット。 という具合です。 一応、テストを数回走らせてランダムテストが問題なく終了するのを確認はしてあります。 今回の問題に対する、個別のテストケースを追加してから近日中リリースする予定です。 対応が遅くなって申し訳ないです。。。\n","date":1338827340,"dir":"post/2012/","id":"0dcb6d0f17794bbca56b6cdb9e20b932","lang":"ja","lastmod":1338827340,"permalink":"https://blog.johtani.info/blog/2012/06/05/trunk%E3%81%AE%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E5%B7%AE%E3%81%97%E6%9B%BF%E3%81%88lucene-solr3-6-0%E3%81%A8%E3%83%A9%E3%83%B3%E3%83%80%E3%83%A0%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E5%A4%B1%E6%95%97%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-06-05T01:29:00+09:00","summary":"久々にlucene-gosenを触っています。 trunkのlibにある、jarファイルが3.5ベースだったので、3.6ベースにしてテストをし","tags":["lucene-gosen"],"title":"trunkのライブラリ差し替え（Lucene/Solr3.6.0）とランダムテストの失敗について(Jugemより移植)"},{"contents":"録画してたEテレのスーパープレゼンテーションを見ててふと書きたくなったので、書いてます。 あとから読んだら恥ずかしくなりそうだけど。。。 「\u0026ldquo;知力の余剰\u0026quot;が世界を変える」というClay Shirkyさんの話を見て思ったことです。 社会的に貢献できる仕組みが最近増えているという話の内容でした。そこで、OSSについても同じことが言えるよなぁと思った次第でして。\n昔からいろんなかたが言ってると思うし、今さら何をとおもわれるかもしれないですが、なんとなく書きたくなってしまったので。\n私はシステム開発を生業にしています。特にOSSにはお世話になっています。 実際に、OSSを利用している方はかなりいると思います。 幸いにも、私はOSSのコミッターもやっています。 OSSに色々と関わってきて常々思っていることがありまして。\nOSSは基本は有志の方々が開発やメンテナンスを行なっています。（最近では会社で行なっているところもありますが。） そんなOSSに貢献する方法はいくつかあるのかなぁと。\nバグを発見したら報告したり、こんな機能を作ってみたけどどうですか？とパッチを送ってみたりするのは素晴らしい貢献だと思います。 ただ、なかなかアクションを起こすのって勇気がいるかなぁと。 実際、私もパッチ書いたりバグ報告するのは気後れすることがありしました。 ただ、貢献する方法ってこれだけじゃないよなぁと、コミッターをやり始めて思いました。\nもちろん、バグ報告してもらえるともっとありがたいですし、新機能とかリクエストを送ってもらえるともっと嬉しいです。 MLに質問するのもありです。ただ、ちょっとハードルが高いと思うこともあります。\nそんな時は、ただ使っているよと、ツイートしたりブログを書いてくれるだけでもありがたいし、ヤル気が出るものです。 使い勝手が悪いなぁというツイートでも、なんでこんなに使いにくいんだというブログでもいいんです。 気になるなぁという形でもいいと思っています。 githubでフォローするだけでもいいかと。 反応があれば、使ったり触ってもらえていることがわかります。 なので、使っているよとかアピールしてもらえると嬉しいよなぁと。\nなんか、締りのない感じになっちゃいましたが、反応があるとうれしいので、お気楽に反応しましょうよというお話です。\n","date":1338394320,"dir":"post/2012/","id":"ffdbd6a7d28c9a63976e9eec38cab0f5","lang":"ja","lastmod":1338394320,"permalink":"https://blog.johtani.info/blog/2012/05/31/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%B8%E3%81%AE%E8%B2%A2%E7%8C%AE%E3%81%AE%E3%82%B9%E3%82%B9%E3%83%A1/","publishdate":"2012-05-31T01:12:00+09:00","summary":"録画してたEテレのスーパープレゼンテーションを見ててふと書きたくなったので、書いてます。 あとから読んだら恥ずかしくなりそうだけど。。。 「\u0026l","tags":["misc"],"title":"オープンソースへの貢献のススメ(Jugemより移植)"},{"contents":"JJUG CCC 2012 Springに参加してきました。 昨年のFallに続き、2回目です。 概要や、タイムテーブルはこちらを御覧ください。 今回は、午後一から参加しました。 色々と迷いましたが、つぎのを聞いて来ました。\nHotSpot vs JRockit ～ HotRockit到来の前に予習しよう！ Play! Framework - モダンで高速なWeb開発 Grails/Groovyの開発活用術 Scala 最新状況報告 From Swing to JavaFX SwingからJavaFXへのマイグレーションガイド JRockitは使ったことがなく（たぶん）、新鮮でした。いろいろなコマンドが用意されているなぁと。 あと、jvisualvmの使い方も知らないこともあったのでいい話が聞けました。 プレゼンに慣れているようで、プレゼン中に、コマンドラインの拡大＋コマンドのオプションに赤い下線を入れるなど、どうやってやっているのか、プレゼンの内容よりも気になってしまったのが本音です\nPlayは今回の目玉の一つでした。まだ、手元でPlayを触り始めたばかりだったので、概観がつかめたのが良かったです。 あとでスライドを見なおさないと。 頭がどうしてもServlet、JSPのため、未だにPlayに切り替えができてないので、もっと触ってみないとなぁと。 ちなみに、紆余曲折してまして、Play 1.2.4→Play 2.0（Javaアプリ）→Play 2.0（Scalaアプリ）と心変わりしまくりで、まだ完全に作ってないのに、ふらふらしてます。。。\nGrailsはGrailsを現場にどのように投入していくのがいいかという、技術よりは、政治的な話でしたが面白かったです。 実際に、あまり有名でないプロダクトを現場に導入するのに、Javaだからと無理やり説得してみたりｗ、開発コストがこれくらい下がりますという話をしてみたりと、いろいろやられているようでした。 あと、PlayのあとにGrailsということもあり、すこしPlayを意識した話もされていました。\nScalaはScalaDaysの話＋Scalaの最近の動向ということで、ある程度Scalaを知っている人がターゲットのようでした。 少し触っただけなので、何となく分かる部分もありましたが、最後の方はついていけてないです、すみません。。。 一番感じたのは、発表者の水島さんのScalaに対する愛情でしょうか。\n最後は桜庭さんのJavaFXのお話です。 一応、昔、JFreeChart＋Swingでちょっとしたものを作ったことがあるので面白かったです。 プレゼン自体もJavaFXで作成されていたり、オープニングがStarWars風だったりと凝ったプレゼンでした。 JavaFXとしては、JavaOneでも聞いたのですが、グラフやHTMLがリッチに書けるようになったことがびっくりです。\n実際のSwingアプリからJavaFXへの移行に関して、注意する点などがわかりやすく聞けました。 FXMLは確かに便利ですよねぇ。レイアウトをJavaで組むのがすごくめんどくさかったもんなぁ。\nさて、簡単ですが、感想でした。 今回一番残念だったのは、長丁場の割に電源の確保が難しかったことでしょうか。 ツイートしたり、メモ取ったりしたかったのですが、電源が乏しいので、Wi-fiオフにしてメモ取るのが限度でした。。。\n場所：オリンピック記念青少年総合センター 日時：2012/05/28 10:00 - 19:00 ◎13:10 - 14:00 C-1 HotSpot vs JRockit ～ HotRockit到来の前に予習しよう！ 谷本 心 @cero_t ◯HotSpot from Sun ◯JRockit from BEA 今は、どちらもOracle ◯違いは？ 1.歴史 2.プラットフォーム JRockitはMacではNG。Solarisは一部。 2.1Oracleさん曰く Solaris/Mac → HotSpot Windows/Linuxのサーバ → JRockit Windows/Linuxのクライアント → HotSpot 2.2谷本さんは？ WebLogic → JRockit 1.4、5の時の開発環境はJRockit 当時はJRockitの解析ツールがカッコ良かった 3.解析ツール 3.1コマンドラインツール プロセス HotSpot ： jps JRockit ： jrcmd スレッドダンプ HotSpot ：jstack JRockit ： jjrcmd \u0026lt;pid\u0026gt; print_threads ヒープ解析 HotSpot：jmap -histo \u0026lt;pid\u0026gt; JRocket：jrcmd \u0026lt;pid\u0026gt; heap_diagnostics HotSpot： JRockit：jrcmd \u0026lt;pid\u0026gt; 他にもJRockitは色いろある。 print_utf8poolとか（内部の文字列が出てくる） 3.2GUIツール HotSpot：jvisualvm　NetBeansベース JRockit：Mission Control　Eclipseベース メモリリークの解消をツールを使ってみてみましょうデモ。 ・hprofファイルを吐き出して、jvisualvmで読みこむのが楽な方法 ・jrmcはヒープダンプファイルを読み込む機能がない。 memleakというツールがある。アプリを起動してから、プロセスを右クリックして選択可能。 タイプグラフや割当てトレースみたいなものが使えるよ。 フライトレコーダーというのもあるよ。 4.HotRockitの紹介 まだいつ出るのかなぁという状態だけど、HotSpotにJRockitのツールも使えるようになるVMが出る模様。（2013？） ※デモ中に画面拡大した時に、赤線でラインを引いているのがすごく気になった。（便利なツールなのかな？そこだけ？） ◎14:15 - 15:05 C-2 Play! Framework - モダンで高速なWeb開発 池田尚史 @ikeike443 ◯自己紹介 Play!Frameworkコミッター 日本Playframeworkユーザ会 ◯アンケート メイン言語は？Java多数 触ったことある？半分くらい？ Play1？Play2？半々くらい プロダクションで使ってる人？3人 ◯Playframeworkって？ JEEではないよ。 Webだよ。 ServletとかXML使ってないよ。 ◯JEEは難しいよね。RailsとかDjangoから流れてくると。 ◯Webフレームワーク なので、Webアプリが作れればいいよね。 開発すべきものに注力して、抽象化とかを頑張らないようにと。 ◯ライブコーディング！ Play2.0のScalaアプリみたい。 プロジェクト作成～編集して起動まで。 エラーを起こして、エラーがどのように表示されるか。 エラーのリンクをクリックして、エディタを起動するということも可能みたい。 TODOとかで、まだ終わってないのも記述可能。 パラメータとControllerの関数の引数が勝手にひもづけられますよと。 ◯歴史 Servletとかもあった。 1.2からNetty、Websocket、Scalaサポート 2.0.1：Scalaで書き直し。Netty+Akkaで非同期 ◯１と２のちがいは？ ・Play1 Javaで書かれたJavaのフレームワーク。Scalaはプラグインサポート ・Play2 Scalaで書かれたScala/Javaのフレームワーク ◯Playの特徴 ステートレスとかノンブロッキングとかリアクティブとか ・高生産性 XMLがないし、unzipするとすぐ使えるよ。 ホットスワップできるよ。 CoffeeScript、LESSサポートも。assetsに入れとくとコンパイルしてくれて静的コンテンツにしてくれる。（Railsにも似たようなのあったっけか？） ・ステートレス HttpSessionがない→必要ならMemcachedとかで管理してね。 「デプロイ→ニーズ・状況に応じて即時スケールアウトという時代じゃないか？」という主張 Playはステートレス養成ギブスであり、時代の要請にマッチ ・広範囲な型安全 コンパイルしてエラー検知 ・ノンブロッキングI/O 非同期処理が手軽に書けるように考えられている。 →リアルタイムWebの時代 NettyやAkkaにより実現されてるのがいい Akkaを使ったアプリを書くと、長い処理のActorを別サーバにするなども設定で変更が可能。 ◯テスタビリティ BDDフレームワーク（Specs2？） Viewもテストできるぞと。 ◯事例 Klout：ソーシャルスコアリング イギリスのガーディアン：コンテンツAPIの実装がPlay2 MinecraftのWebサイト ◎15:20 - 16:10 C-3 Grails/Groovyの開発活用術 ～Java EE資産を活かして開発を加速する～(仮) 上原潤二 山本剛 ◯充電中のためお休み ◎16:25 - 17:15 C-4 Scala 最新状況報告 ～或いはScala Days 2012リポート～ 水島宏太 ◯自己紹介 言語を作るのが夢みたい。 ◯Scala最新状況報告 ScalaDaysの雰囲気を伝えるよと。（どっちかというと、旅行記かも） ◯Scala？ ・オブジェクト指向関数型言語 ハイブリッドじゃなくて、統合したもの ・強力な静的型付け NullPointerExceptionなども起きにくい ・超強力なコレクションフレームワーク ・Javaと同等の実行速度 ・コードが簡潔（1/4くらい） ◯Scala採用企業 Twitter、Amazon.com（どこに使ってるかは不明）、Foursquare、LinkedIn、VMWare、Klout、Tumblrなど ◯Scalaのバージョンは？ 2.10が開発版。2.9.2がステーブル版。 ◯開発体制 Typesafe＋世界のContributor Typesafeメンバの議決でいろいろ決定 githubでオープンに開発 ◯ScalaDays2012の目玉 豪華ゲスト（私は、わからなかった） Scala2.10の新機能紹介 今後のScala、多数の応用例 ◯ScalaDays2012を見ての方向性 ・All-in-oneパッケージの提供 Typesafe Stackの提供 重要なツール sbt（Simple Build Tool） gitter8（プロジェクトテンプレート生成ツール。githubを元に色々取ってくる？） Akka Play 2.0 Framework ・学習コストの削減 言語機能のモジュール化 高度な開発者が使う昨日はデフォルトOff ・バイナリ互換性問題への対処 ・Minor Release間での互換性を維持 MIMAでジドウテキに非互換性を検出 ・Major Release間では互換性は保証しない。 No more java.util.Date ソース互換性は「概ね」保証される deprecatedは次期メジャーバージョン時に削除される。 ・Scala IDEへの注力 インクリメンタルにコンパイルしてくれるから、遅いのも気にならなくなるかも。 デバッガとか、できるよと。 ・さらなるパフォーマンス改善 Value classes AnyValを継承したクラスが作成可能 該クラスのオブジェクトがインライン化 Pimp my libraryによるヒープ使用料が0に！ ◯2.10最新機能紹介 \u0026#34;1+2=#{1+2}\u0026#34;ができない s\u0026#34;1+2=${1+2}\u0026#34;ができるように String = 1 + 2 = 3 f\u0026#34;1=${1}%03d\u0026#34;もできるようにSring = 1 = 001 自分でStringコンテキストにメソッド追加できるらしい（聞き取った日本語が合ってるか？） とか。（かなり不安。。。まだまだわかってない。。。） ◎17:30 - 18:30 BOF-B-1 From Swing to JavaFX SwingからJavaFXへのマイグレーションガイド 櫻庭 祐一 ◯JavaFX 次世代のJava GUI Library Swing+Java2D+α JavaSE8から標準（JavaFX3.0） ◯サンプル クラス名がいろいろ変わってる。 ◯はまりそうなところ コンテナへの追加がちょっと違う イベントリスナは1種類のみになった。（Genericsを使うようになったよと。） ◯Bind 値が変わるとModelが勝手に検知して変わるみたい。 双方向もあり。これだとEventを書かなくても良くなりつつ有るよと。 ◯シナリオベースでマイグレーション考えましょう 1.JavaFX in Swing JavaFXにSwingを埋め込むことはできないぞと。 SwingでできないことをJavaFXでやりますよと。 おー、グラフが動く。JavaDocのHTMLも綺麗に出てる。 使い方：JFXPanelを使う シーングラフを記述可能 データのやり取りが大変。Threadが違うから。 パフォーマンスが落ちます。Java2Dで画像を書くので遅いですよと。 新規のものはJavaFXで書きましょうと。 2.Swing to JavaFX w/o FXML SwingをJavaFXに置き換える。 使い方が違うものはTableViewなど、◯Viewとついてるもの。 ちょっと考えるのはLayout Swing：コンテナ＋レイアウトマネージャー JavaFX：コンテナがレイアウトを含む BorderPaneクラスとか。 問題はTableとか Swing：TableModel JavaFX：BeanをColumnにバインド 3.Swing to JavaFX w/ FXML ・FXML GUIの構造をXMLで表す。 シーングラフを表現。 スキーマレス クラス：要素 プロパティ：属性 or 要素 アノテーションバリバリです。これで、FXMLとJavaのバインディングができるよと。 ツール Java ：NetBeans e(fx)clipseってのがあるかも。 FXML：Scene Builder ","date":1338259500,"dir":"post/2012/","id":"de734259dfb9addebe2b226d96b4f744","lang":"ja","lastmod":1338259500,"permalink":"https://blog.johtani.info/blog/2012/05/29/jjug-ccc-2012-spring%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-05-29T11:45:00+09:00","summary":"JJUG CCC 2012 Springに参加してきました。 昨年のFallに続き、2回目です。 概要や、タイムテーブルはこちらを御覧ください。 今回は、午後一から参加","tags":["勉強会"],"title":"JJUG CCC 2012 Springに参加してきました。(Jugemより移植)"},{"contents":"PlayFramework2.0を触ってみてます。 ちょっとコーディングしたくなったのと、最近のアプリの作成の調査も兼ねて。 まぁ、せっかくなので、Solr検索のアプリでも作ってみようかと言うことで触ってます。 ただ、Solr検索アプリでしかなく、今のところDBを使わないので、実はPlay Frameworkじゃなくてもいいのではないかという疑問も。。。\nまだ、触り始めたばかりなので、なんともですが。感想を。 たぶん、Ruby on Railsに似ているのかなと。 RoRは仕事で少し関わったので、なんとなく知っていますが、アプリの作成手順や、ディレクトリ構成などが似ている気がします。\nコントローラーの生成のタイミングとか、内部でオブジェクトをSingletonで保持する方法とかのイメージがまだ良くつかめていない状態で、まずは、Solr検索部分（Palyにあんまり関係ないところ）を実装しているところです。\n現状で一番の疑問点は、Eclipseプロジェクト化した時の参照ライブラリのパスに関するところでしょうか。 Play Frameworkは「play new ほげほげ」コマンドを実行するとアプリのディレクトリ構成が作成されます。 このあとに、eclipsfyというplayのコマンドを実行すると、Ecilpseのプロジェクトファイルが作成されます。 この時、PlayFrameworkが利用するjarファイルたちが参照ライブラリとしてクラスパスに設定されます。\nこのパスには、PlayFrameworkのインストールディレクトリが含まれた絶対パスが記述されるのですが、 複数人で開発するときにはどうしているのかなぁと。 あと、BitbucketやGitHubにアップするときもどうするのかなぁと。 以前、この疑問ツイートして、頂いた回答としては、環境変数として定義して、各自で設定してもらうというものでした。 私も同じ事を考えていたので、腑に落ちたのですが、他にもっといい方法があったりするんでしょうか？ クラスパスやEclipseプロジェクトのファイルをアップしないというのもあると思いますが、それもちょっとなぁと。 なにか、オススメとかあれば、教えていただけると嬉しいです。\n最近、ブログ更新してなかったのもあったので、まずは、導入編でした。\n","date":1337151314,"dir":"post/2012/","id":"78f002cc3d512ea302c900d1da4dfeec","lang":"ja","lastmod":1337151314,"permalink":"https://blog.johtani.info/blog/2012/05/16/playframework-2-0-java%E3%81%AE%E6%96%B9-%E3%82%92%E8%A7%A6%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%A6%E3%82%8B/","publishdate":"2012-05-16T15:55:14+09:00","summary":"PlayFramework2.0を触ってみてます。 ちょっとコーディングしたくなったのと、最近のアプリの作成の調査も兼ねて。 まぁ、せっかくなの","tags":["備忘録"],"title":"PlayFramework 2.0(Javaの方)を触ってみてる(Jugemより移植)"},{"contents":"lucene-gosenの最新版（2.0.1）をリリースしました。\nプロジェクトページよりダウンロードが可能です。\n今回の修正では、Java7でUnicodeのバージョン変更に伴う対応（詳細はこちらを参照）を行なっています。\nリソース周りの対応はまた後日。。。すみません。2012/05/16 遅くなりましたが、昨晩、JavaDocをアップしました。\n","date":1336494900,"dir":"post/2012/","id":"c4b418764dca70aebfc965899a3fa7e5","lang":"ja","lastmod":1336494900,"permalink":"https://blog.johtani.info/blog/2012/05/09/lucene-gosen-2-0-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9java7%E5%AF%BE%E5%BF%9C/","publishdate":"2012-05-09T01:35:00+09:00","summary":"lucene-gosenの最新版（2.0.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、Java7で","tags":["lucene-gosen"],"title":"lucene-gosen 2.0.1リリース（Java7対応）(Jugemより移植)"},{"contents":" IDの秘密 (丸善ライブラリー―情報研シリーズ) 非常に面白く読めました。 バーコードの話に始まり、最後はシステムで付与するIDに関する考慮点まで幅広くIDについて語られています。\n適度に配置されたコラムがまた面白く、ここまで書いてもいいのかな？と思いながらも楽しく読ませて頂きました。 2次元バーコードが汚れに強いのも知らなかったし、チロルチョコの話は知らなかったし、指コレクションとか面白すぎです。 また、JRのSuicaの導入に7年もかけている点などは、やはりすごい技術なのだなぁというため息混じりの感想です。 それほど長い期間のテストや設計は想像がつかないです。\n最後の2章（７，８章）については、エンジニアの以外のシステムに関わる方やエンジニアになられたばかりの方たちにぜひ読んで欲しいと思いました。 もちろん、エンジニアの方にも読んでほしい内容です。\nいくつか疑問点や気になる点もあったので。\n「静脈や指紋が人によって異なるって確率はどうやって決めたんだろう？」 Twitterの説明文のあとにFBの画面の図番号が書いてある。 日本語がデコードされたけど、QRコードの文字コードって、この中に含まれてるのかな？それとも規格で決まってるのかな？ 最後に、書影がNIIに合ったので撮影しました。写真へのリンクです。\n","date":1335794635,"dir":"post/2012/","id":"95c0a5b8a66950b5f22dd82a8dfe0ce5","lang":"ja","lastmod":1335794635,"permalink":"https://blog.johtani.info/blog/2012/04/30/id%E3%81%AE%E7%A7%98%E5%AF%86%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-04-30T23:03:55+09:00","summary":"IDの秘密 (丸善ライブラリー―情報研シリーズ) 非常に面白く読めました。 バーコードの話に始まり、最後はシステムで付与するIDに関する考慮点まで","tags":["読書"],"title":"「IDの秘密」を読みました。(Jugemより移植)"},{"contents":"WebSolrの話があるらしいというのを嗅ぎつけて、初めてHeroku JP Meetupに参加しました。 herokuもWebSolrも知りつつ、手を出していなかったので、いい機会でした。 （SignUpだけ、勉強会直前に済ませましたｗ）\nHerokuはAWS上に構築されたアプリケーションプラットフォームで、簡単にアプリをデプロイして動作させることができるようです。 Ruby on Railsを使うのが多いみたいですが、他の言語も利用できると。 で、herokuの面白いところは、アドオンとして、開発が簡単にできるようなしくみが用意されていることみたいです。 今回発表のあった、IronMQ、WebSolr、PaperTrailもアドオンとして用意されており、簡単に利用することが可能です。 IronMQはメッセージキューとして利用できます。\nWebsolrはSolrを簡単に利用できる形で提供しているものになります。 今、利用できるのは3.5.0のようで、最新版（3.6.0）になるのはまだ未定のようです。 今回の発表はWebSolrの話しもありましたが、基本は全文検索の仕組みとKuromojiの説明でした。 ただ、残念ながら、Kuromojiは3.6.0からの提供となるので、現時点では利用できないようです。 あとで、聞いた話だと、schema.xmlを自分で変更できるようです。 ただ、jarファイルを置いたりはできないようなので、lucene-gosenを利用するとかはできないみたいですが。。。 ほかにも、bonsai.ioとして、ElasticSearchの提供も行うようです。 まだ、利用はできないようですが。\n最後がPapertrailです。 こちらは、ログを保存して、検索、グラフ化（視覚化）してくれるアドオンです。 まだ、ベータのようですが、ログを保存してくれるようです。無料版もあるようです。 アドオンとしての機能もそうですが、利用しているグラフ化のツールなど、面白そうなものが利用されていました。\nLTはRuby使いの方が多かったです。\nRuby使いではないのですが、いろいろなアドオンが用意されており、サービスを簡単に提供することができそうだという印象をうけ、ちょっと使ってみたいなぁと思いました。 普段参加していない勉強会だったので、普段では知りえない興味ある話が聞けて面白かったです。\n余談ですがPapertrailの人が利用していた、slideshareのようなサービスのSpeaker Deckもよさそうなので登録してみました。 次に何か発表があった時には資料はこっちにアップしてみようかなぁと\n以下は、いつものように自分用のメモです。\n日時2012/04/20 19:00 to 21:00 会場：パソナグループ本部　呉服橋 ◎オープニング – Ayumu AIZAWA (Heroku Evangelist） ◎新入社員からの挨拶 – Koichi SASADA (Ruby Developer） 前職：大学教員 仕事：CRuby開発 Heroku使った事無いですｗRailsもよく知らないですｗ RUby2.0のリリースがゴール。2013/Feb 性能アップのことやってます。 ◎IronMQ – Chad Arimura (Iron.IO)\n「メッセージキューは涼しいです。」 （Google翻訳による日本語訳付きのスライド） Aggregation、Distribution。。。 IronMQ Elastic、RESTful heroku addon ironmq:rust 簡単にheroku上にキューが用意できるアドオンです。 Q：メッセージがキューに到達したのを確認する方法か？ A：ステータスコードが帰ってくる。 Q：データのサイズのリミットは？ A：postのリミットはある。S3とかに巨大データをおいて、ポインタを渡すとかしてほしい。 Q：キューへの到達の成功の保証は？ A：アプリケーション側で判断してください？ ◎Search \u0026amp; Indexing on Heroku – Nick Zadrozny (Websolr) スライドはこちら。\n※ツイートしてて、メモとってなかったので、ツイートをコピペ。 次はWebsolrのお話 Bonsai.io？ Bonsai by onemorecloud - http://bit.ly/JjCuaE SQLのLIKE検索はO(n)でおそいねぇと。 クエリのパースについての話。 今度は転置インデックスのお話。 Termへの分割ってどーすんの？というお話。Tokenizeのお話。 その１：N-GramというTokenizeの方法。N文字ずつ先頭からTermを切り出す。開始位置は1文字ずつずらしていくと。 N-Gramはノイズがのるし、多くのTermがでてきちゃうよと。 その２：そこで、次は形態素解析ですね。 先週、Lucene/Solr 3.6.0がリリースされて、Kuromojiという日本語向けの形態素解析器がでましたよ。 Kuromojiはこちら。（Lucene版とは少し違うけど。）http://atilika.org/ Kuromojiのサーチモードのお話。 通常は、「関西国際空港」という単語になってしまうのを、Kuromojiでは「関西」「国際」　「空港」という切り方の単語も出してくれると。 ちなみに、lucene-gosenでは、サーチモードはないんですねぇ。。。 「の」はどこに消えたんだ？？そこの説明は？ ElasticSearchやSolrのコアの部分でLuceneを使ってるよ。 ElasticSearch　http://bit.ly/qjjvWp Kuromojiはユーザ辞書をサポートしてるよ。 Q：まだ、3.5.0では？ A：もうすぐやります ◎log analysis for your Heroku app – Eric Lindvall (Papertrail)\nheroku上にログを貯めて、検索したりグラフ化したりできるようになりそうなもの。 [スライドはこちら](http://speakerdeck.com/u/lindvall/p/log-analysis-for-your-heroku-app) ログを貯めて、検索や可視化できるようにするサービスみたいです。 まだ、アイデアレベルのものも発表資料には含まれていました。 内部で利用しているツールなど、資料の最後に出てきますが、色々と面白そうなものがありました。 ◎Lightning Talks ◯Receibo ( @shu_0115 ) デザイナーｘエンジニアハッカソンでの成果らしい。 Webベースの家計簿アプリ。 買ったものの名称と料金を入れるだけ。 ◯Heroku + Pusherで作る！リアルタイムアプリケーション ( @satococoa ) WebSocketみたいなことが、Pusherでできるらしい。 http://www.slideshare.net/satococoa/heroku-pusher　◯Herokuアドオンを作ってみてわかったこと ( @takkam ) ◯heroku client のちょっと進んだ使い方 ( @hsbt ) ◯love heroku? – we love herokuのご紹介 ( @ppworks ） ","date":1334935380,"dir":"post/2012/","id":"c92c12a28fa219ad1aab60865046ff05","lang":"ja","lastmod":1334935380,"permalink":"https://blog.johtani.info/blog/2012/04/21/heroku-jp-meetup-4%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/","publishdate":"2012-04-21T00:23:00+09:00","summary":"WebSolrの話があるらしいというのを嗅ぎつけて、初めてHeroku JP Meetupに参加しました。 herokuもWebSolrも知りつつ、","tags":["勉強会"],"title":"Heroku JP Meetup ＃4に参加しました。#herokujp(Jugemより移植)"},{"contents":"先日、Solr入門のサンプルschema.xmlの3.6.0対応版の作成をしていて、気になったことがあったので、 メモとして残しておきます。\nSynonymFilterFactoryの属性「tokenizerFactory」に関連する話です。 （「Apache Solr入門」の36-37ページに記載があります。）\nSynonymFilterFactoryでは、類義語設定ファイルを読み込む際に利用するTokenizerFactoryを「tokenizerFactory」という属性で指定できます。（以下は書籍の記述を抜粋）\n\u0026lt;filter class=\u0026#34;sold.SynonymFilterFactory\u0026#34; synonyms=\u0026#34;synonyms.txt\u0026#34; ... tokenizerFactory=\u0026#34;solrbook.analysis.SenTokenizerFactory\u0026#34;/\u0026gt; このように、TokenizerFactoryが指定できます。\nただ、こちらの記事で書いたように、 Solr 3.6.0のexampleのschema.xmlではCJKのフィールドは次のように設定されています。\n\u0026lt;!-- CJK bigram (see text_ja for a Japanese configuration using morphological analysis) --\u0026gt; \u0026lt;fieldType name=\u0026#34;text_cjk\u0026#34; class=\u0026#34;solr.TextField\u0026#34; positionIncrementGap=\u0026#34;100\u0026#34;\u0026gt; \u0026lt;analyzer\u0026gt; \u0026lt;tokenizer class=\u0026#34;solr.StandardTokenizerFactory\u0026#34;/\u0026gt; \u0026lt;!-- normalize width before bigram, as e.g. half-width dakuten combine --\u0026gt; \u0026lt;filter class=\u0026#34;solr.CJKWidthFilterFactory\u0026#34;/\u0026gt; \u0026lt;!-- for any non-CJK --\u0026gt; \u0026lt;filter class=\u0026#34;solr.LowerCaseFilterFactory\u0026#34;/\u0026gt; \u0026lt;filter class=\u0026#34;solr.CJKBigramFilterFactory\u0026#34;/\u0026gt; \u0026lt;/analyzer\u0026gt; \u0026lt;/fieldType\u0026gt; 3.6.0以前は、solr.CJKTokenizerFactoryを利用していましたが、3.6.0からはCJKTokenizerFactoryがdeprecatedになってしまい、代わりにStandardTokenizerFactory＋CJKBigramFilterFactoryの組み合わせになっています。 exampleのCJKのフィールドタイプ設定を利用して、かつ、そのフィールドにSynonymFilterを利用する場合に、 StandardTokenizerFactoryを指定してしまうと、類義語が展開できなくなってしまうので注意が必要です。\nCJKのフィールドでSynonymFilterを利用する場合は、類義語の設定ファイル内の記述を自力でCJKTokenizerが分割する形で記述する（まぁ、やらないでしょうが）か、deprecatedですが、CJKTokenizerFactoryを利用するのが現時点での対応でしょうか。\nなお、これに絡んで、このようなチケットもできています。\nSyntaxHighlighterを導入してみました。 ちょっとはみやすくなってますかね？ まだ、SyntaxHighlighterの設定を調べながら使っているので、コロコロ変わるかもしれないですが、気にしないでください。 ","date":1334592971,"dir":"post/2012/","id":"12d1e0cf7396dd33a9bbbca8da4cbc68","lang":"ja","lastmod":1334592971,"permalink":"https://blog.johtani.info/blog/2012/04/17/solr-3-6-0%E3%81%AEcjk%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%81%A8synonymfilterfactory%E3%81%AE%E6%B0%97%E3%81%AB%E3%81%AA%E3%82%8B%E7%82%B9/","publishdate":"2012-04-17T01:16:11+09:00","summary":"先日、Solr入門のサンプルschema.xmlの3.6.0対応版の作成をしていて、気になったことがあったので、 メモとして残しておきます。 S","tags":["solr"],"title":"Solr 3.6.0のCJKの設定とSynonymFilterFactoryの気になる点(Jugemより移植)"},{"contents":"先日の続きです。「Apache Solr入門」の2章から4章の説明について、Solr3.6.0で動作させる時の変更点を以下に書いていきます。 なお、前回も説明しましたが、3.6.0からKuromojiという形態素解析器がSolrに同梱されるようになりました。 これから説明する2章の変更点の手順ですが、Kuromojiとlucene-gosenそれぞれの利用方法について説明します。 添付のschema.xmlについては、基本的にKuromojiを利用する形に変更してあります。 それに加えて、lucene-gosen用のフィールドを別途追加で定義しました。 これらのフィールド名については、次の表の用になります。 適宜、書籍のフィールド名と置き換えながら読み進めたり、試したりしてください。\nKuromojiフィールド lucene-gosenフィールド title title_gosen author auther_gosen summary summary_gosen intended_reader intended_reader_gosen from_author from_author_gosen toc toc_gosen 2章 2.1.3 schema.xmlのバージョン（27ページ） Solr3.xではschema.xmlのファイルの最新バージョンは**1.5**になっています。\n2.2.3 代表的なトークナイザ（35ページ） solrbook.analysis.SenTokenizerFactoryは必要ありません。 Solr 3.6.0からはKuromojiと呼ばれる形態素解析器が用意されています。 solr.JapaneseTokenizerFactoryがそれに該当します。 これとは別に、lucene-gosenを利用する場合、Solr向けのトークナイザが用意されています。 solr.GosenTokenizerFactoryがそれに該当します。\n2.2.4 代表的なトークンフィルタ（37ページ） 以下の2つについてはKuromojiが同等のトークンフィルタを提供しています。 また、lucene-gosenを利用する場合は、lucene-gosenに同等のトークンフィルタが存在します。\nsolrbook.analysis.KatakanaStemFilterFactory solrbook.analysis.POSFilterFactory 次のものがSolr 3.6.0に用意されているので、こちらを利用します。\nsolr.JapaneseKatakanaStemFilterFactory solr.JapanesePartOfSpeechStopFilterFactory それぞれ、次のものがlucene-gosenにあるので、こちらを利用します。\nsolr.GosenKatakanaStemFilterFactory solr.GosenPartOfSpeechStopFilterFactory 2章向けのschema.xmlはこちらです。その他のtxtファイルについては、特に変更はありません。\n3,4章は特に変更はありません。Solrの起動の仕方にだけ注意してください。（-Dsen.homeは必要ありません）\n以上が4章までの修正点になります。\n昨日に引き続き、眠い目をこすりながら修正したので、おかしいかも。 動かない、意味がわからないなどあれば、コメントorツイートいただければと思います。\n2012/06/14提供しているschema.xmlに関して修正を加えました。こちらの記事で説明しているautoGeneratePhraseQueriesの値をtext_gosen、text_cjkのフィールドに対してtrueを設定する記述を追記しました。\n","date":1334339880,"dir":"post/2012/","id":"d77cdb466c5063b99c5aea58e6da4d32","lang":"ja","lastmod":1334339880,"permalink":"https://blog.johtani.info/blog/2012/04/14/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C2%E7%AB%A04%E7%AB%A0/","publishdate":"2012-04-14T02:58:00+09:00","summary":"先日の続きです。「Apache Solr入門」の2章から4章の説明について、Solr3.6.0で動作させる時の変更点を以下に書いていきます。 な","tags":["solr"],"title":"「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（2章～4章）(Jugemより移植)"},{"contents":"以前より、アナウンスしていた、Kuromojiという日本語形態素解析が含まれるLucene/Solr 3.6.0がリリースされました。\n以下、各リリース内容について簡単に説明されているページへのリンクです。\nSolrリリースのお知らせ\nLuceneリリースのお知らせ\nSolr 3.6.0の変更の目玉は各言語のAnalyzer/Tokenizerの設定がexampleのschema.xmlに含まれるようになったことです。 Kuromojiという日本語用の形態素解析器もexampleを起動すればすぐに利用できる形になっています。 Kuromojiを利用する場合は、exampleのschema.xmlが参考になるでしょう。\nあと、大きな変更は、Ivyに対応した点です。ソースをダウンロードするとわかりますが、依存するjarファイルが含まれない形に変更されています。 SVNからチェックアウトした場合も同様です。ビルドにはネットワークに接続している環境が必要になりました。\nまた、このリリースに合わせて、以前書いた「Apache Solr入門」のサンプルについての記事も変更が必要かと思い、 前回の記事をベースに以下に変更した記事を書いたので、参考にしてください。 今回は、Kuromojiという日本語形態素解析がデフォルトで含まれるようになったので、 Kuromojiの利用方法とあわせて、lucene-gosenの利用方法も記載します。 サンプルのschema.xmlについては、Kuromoji、lucene-gosenが同時に利用できる形のものを用意しました。\nサンプルのschema.xmlを最新版（Solr 3.6 + lucene-gosen-2.0.0-ipadic）のものを用意しました。 なお、あくまでも、3.xでlucene-gosenを利用する場合の「Apache Solr入門」のサンプルプログラムの変更点（とりあえず、4章まで）の違いについて記述します。 申し訳ございませんが、1.4と3.xの違いについての説明はここでは行いません。\n以下では、各章でschema.xmlに関連する記載のある部分を抜粋して、変更点と変更したschema.xmlのリンクを用意しました。参考にしてもらえればと思います。\n1章 1.6.1 N-gram（17ページ） 1.6.1の手順に変更はありません。 サンプルプログラムが入っているZip「solrbook.zip」のintroduction/ngram/schema.xmlファイルの代わりに こちらのschema.xmlを利用してください。 ※なお、Solr 3.6.0から、SOLR_HOME/example/solr/conf/schema.xmlにデフォルトでN-gramで利用しているCJKTokenizerの設定が入るようになっています。 （実際にはCJKTokenizerではなく、CJKBigramFilterとCJKWidthFilterに変更されています。）\n1.6.2 形態素解析（18ページ～20ページ中盤まで） CJKと同様、exampleにKuromojiを利用した設定がすでに記述されています。text_jaというフィールドタイプになります。書籍の21ページ1行目に記載のある、 「Field」のテキストボックスに入力する文字列を「text_ja」とすると、Kuromojiを利用した形態素解析結果が表示されます。exampleですでに幾つかのフィルタも設定されているため、書籍の出力結果とは異なる表示となるはずです。\nlucene-gosenを利用する場合は手順が大きく変わります。 Senを利用する場合、Senの辞書のビルド、Senのjarファイルの配置、Senを利用するためのTokenizerクラスを含んだサンプルjarの配置という作業があります。 lucene-gosenではコンパイル済みの辞書がjarファイルに含まれています。 また、Solr向けのTokenizerもlucene-gosenのjarファイルに含まれています。 lucene-gosenを利用して形態素解析を体験するための手順は次の流れになります。 なお、schema.xmlについては上記N-gramでダウンロードしたschema.xmlに形態素解析の設定もあわせて記載してあります。\njarファイル（lucene-gosen-2.0.0-ipadic.jar）をダウンロードして、$SOLR/example/solr/lib（libディレクトリがない場合は作成）にコピーします。 コピーが終わりましたら、次のように$SOLR/exampleディレクトリでSolrを起動します。 （-Dsen.homeは必要なし）\n$ java -jar start.jar あとは、書籍の記述にしたがって管理画面のAnalysis画面で動作を確認します。 ほぼ、図1-6と同じ結果になっていると思います。 （lucene-gosenで出力される情報には本書のサンプルよりも多くの情報が含まれています。また、サンプルでは、形態素解析の後の単語に基本形を採用しているため、「な」が「だ」として出力されています。基本形を出力する場合は後述するこちらで紹介したTokenFilterを利用すれば可能です。）\n2章については後日説明することにします（眠くなってきた。。。）\n動作しないなどあれば、コメントください。\n2012/06/14追記提供しているschema.xmlに関して修正を加えました。こちらの記事で説明しているautoGeneratePhraseQueriesの値をtext_gosen、text_cjkのフィールドに対してtrueを設定する記述を追記しました。\n","date":1334339100,"dir":"post/2012/","id":"904b07170a0ce481b7491e7fecce4f79","lang":"ja","lastmod":1334339100,"permalink":"https://blog.johtani.info/blog/2012/04/14/lucene-solr-3-6-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9---apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0/","publishdate":"2012-04-14T02:45:00+09:00","summary":"以前より、アナウンスしていた、Kuromojiという日本語形態素解析が含まれるLucene/Solr 3.6.0がリリースされました。 以下、各","tags":["solr"],"title":"Lucene/Solr 3.6.0リリース / 「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（1章）(Jugemより移植)"},{"contents":"Twitterでこのブログ流れてきて、気になったので、流し読みして簡単にメモ。 Amazonのサービスでスケールする検索サービスみたい。\n主に、機能面です。価格とかはみてないです。\nデータと検索トラフィックに対して自動でスケール（※automaticってのがどういう感じかは調べてないです） CloudSearch APIsでアクセス可能。AWS管理コンソールからオペレーションできる。コマンドツールもある データ登録にHTTPSも使えますよ。データ形式はJSON、XML、SDF（Search Document Format）と呼ばれるものに準拠したもの near real-timeで検索可能になる。RAMにインデックスを保持して更新処理が早くなる（Lucene/Solrと一緒か？） ステミングとかストップワードの設定変えたらre-index ファセット、フィールド指定検索が可能。（ファセットはファセットクエリみたいなのもできるのかな？） データ量が増えたら、サーチインスタンスを追加するか、インスタンスタイプを大きくしてスケールする？ トラフィックが増えたら新しいインスタンスにデータをレプリケートしてインスタンスを追加する 簡単に実現できるよ。ファセット検索、全文検索、And/OR検索式、ランキングのカスタマイズ、フィールド指定ソート、フィールド指定検索、テキスト処理オプション（ストップワード、類義語、ステミングのような） ここから詳細のドキュメントが見れるみたいなので、また、見てみます。\nあと、WikipediaをCloudSearchで動かしてるデモとそれに関する記事もあるみたいです。これも暇を見つけて眺めてみます。\n","date":1334241069,"dir":"post/2012/","id":"bed3b7fcc1294e23639057435ac8756a","lang":"ja","lastmod":1334241069,"permalink":"https://blog.johtani.info/blog/2012/04/12/%E3%83%A1%E3%83%A2amazon-cloudsearch%E3%81%8C%E5%87%BA%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F%E3%82%88/","publishdate":"2012-04-12T23:31:09+09:00","summary":"Twitterでこのブログ流れてきて、気になったので、流し読みして簡単にメモ。 Amazonのサービスでスケールする検索サービスみたい。 主に、","tags":["備忘録"],"title":"【メモ】Amazon CloudSearchが出てきましたよ(Jugemより移植)"},{"contents":"JavaOne Tokyo 2012に参加してきました。 4/4-4/5の2日間開催されていたのですが、子供が体調を崩してしまい、4/5のみの参加となりました。 4/4はTwitterのTLを眺めて、羨ましがってました。\n7年ぶりに日本で開催されたJavaOneみたいです。 そういえば、7年前くらいに参加した記憶があるなぁと。\n会場入りして最初の感想は年齢層が高いなぁと。 最近、勉強会によく顔を出すようになったのですが、勉強会とは年齢層が少し異なりました。 まぁ、私も年齢層を上げている一人ではあるのですが。。。 Javaも熟成してきてるなぁというのが最初の感想でした。 あと、思ったよりもスーツ率は低かったと思いました。（5割はいましたが） 一番違和感を感じたのは、会場の所々の色が「赤い」ことです。。。\n以下は私が参加したセッションのカンタンな感想です。\nJava EE6 Modeling　JS2-01　#jt12_s201\nJavaEEから離れてはや数年。私が関わっていた頃はEJB2.0が出たくらいのタイミングだったので、 色々と変わってきているなぁというのが第一印象です。 CDI、Singleton EJBなど、知らない単語もちらほらと。 earではなく、warファイル1つで済む、jQueryをリソースjarとしてパッケージングしてwarファイルに入れられるなどは簡易になっていいなぁと。 web.xmlがアノテーションで記述できて要らなくなるという話は一長一短だと思いました。 一覧性があるからいいと思うこともあるので。 中国の方？の英語だったので少し特徴的でした。すこしは頑張ってみたものの、やはり同時通訳を聞いてしまって反省しています。。。\nマルチコアCPU時代のJavaプログラミング　JS2-14　#jt12_s214\nF社の方が実際に経験されてきた性能関連のプログラミングについての話でした。 現時点のJavaでマルチコアCPUで気をつけるべきプログラミングの観点をわかりやすく説明されたいいセッションでした。 詳細は下のメモを見ていただけるといいですが、色々とプログラミングで気をつけるべき点を説明されていました。 いいおさらいになりましたし、忘れていることや知らないこともあって勉強になりました。 TLでも見かけましたが、モダンJavaプログラミングみたいな、今のJavaでのプログラミングの気をつけるべき点を書いた書籍があるといいかもなぁと思いました。 あと、もうひとつ私が好印象だと思ったのは、F社の製品の紹介などがなかったからかもしれませんｗ\nサービス維持・発展を踏まえた楽天オークションのJava EEによる開発と運用　JS2-23　#jt12_s223\n楽天オークションの開発をサれている方の立ち上げから現在に至るまでの開発メンバーの管理の仕方や 実際に利用している開発手法、気をつけている点のお話です。 スライドに書いてあること以外のことを発表者の方が話をされており、もう少し、喋る内容に関連した図などを入れてもらえるとわかりやすかったかもしれません。 あとは、WebLogicの管理画面が使いやすくていいという話のあとに、GlassFishに移行していますという話があったりと、少し「？」が浮かぶ部分がありました。。。\nJSR 353: Java API for JSON Processing　JS2-33　#jt12_s233\n最近、Twitterで遊んでもらっている（勝手に絡んでいるだけという話も。。。）@yusukeyさんの発表です。 結構な数の立ち見が出るほどの盛況ぶりで、発表者の@yusukeyさんもびっくりしていました。 JSRがどういった形で実際の仕様として公開されていくのかという話がわかりやすく紹介されていて勉強になりました。 所々で笑いが入るなど、さすがの安定感でした。立ち見が出るはずです。 ようやく、JavaもJSONに関する処理を仕様として取り入れようとしているのはいい傾向かと。 ※残念ながら資料は公開されないようです。\nUI Controls and Charts: Drag-and-Drop, Filtering, Sorting, Table Hookup with Charts　JS2-42　#jt12_s242\n最近、Chartに興味を持っていたので、登録したセッションです。 内容としてはJavaFXのコンポーネントをリストアップして紹介していくというお話でした。 グラフ（Chart）周りも数種類が用意されるようです。 JavaFXをあまり知らないのですが、Swingをすこしやっていたのでなんとかついていくことが出来ました。 発表者の方が、実際にJavaFX内部の実装を行われている方だったようで、QAでいくつかこんなコンポーネントはないのか？という質問に、「私のPCでは動いているのですが、ドキュメントなどの整備が追いついていないので公開できていないです」という回答が出て、なかなか大変なのだなぁとｗ Chartに関しては、グラフの重ね合わせなどがまだできないということで、JFreeChartを触ったことがある身としてはすこし物足りなさそうだなぁというのが印象です。\nLearn how the JVM is fundamental to our architecture.　BoF2-03 #jt12_b203\n今回JavaOneに参加した一番の理由がこのセッションです。 Twitterのアーキテクチャに関するセッションでした。 思った以上に濃い内容で、ツイートしたデータがどんな流れで登録されるのか、登録されたデータを各ユーザのTimelineにどのようにアクセスして表示しているのかが説明されました。 今回は主にFinagleについての話でしたが、非同期処理をどのように活用しているかというお話でした。 負荷分散を行なっているポイントやキャッシュについての考え方などです。 メモを取るのに夢中になってしまい、英語をヒアリングするという目的を見失ってしまいましたが。。。 期待以上の話が聞けて満足しています。\nパネルディスカッション\n最後はJavaに関連するコミュニティを運営されている方々のコミュニティ運営に関するディスカッションです。 コミュニティの運営の苦労している点や、心がけている点など、運営も大変そうだなぁと。 どうしても長くやっているとメンバーが固定化してしまうという話なども出ていました。 これは難しいですよね。会社も同じことが言えますし。 一番印象に残ったのは桜庭さんの「動くものが作れるのが楽しい」という一言でした。 エンジニアをやってるのは確かにそこが面白いからだなぁと。最近忘れかけているので、もっと色々と作っていきたいですね。\n以上がカンタンな感想です。 少し残念なのですが、事前に参加登録していたセッションについては、マイページと呼ばれるところから資料がダウンロードできるものもあるみたいですが、参加登録してないものについてはダウンロードが出来ない様でした。（4/6現在） 参加できなかったセッションの資料こそ見たいと思うのが普通だと思うのですが、どうでしょう？そのうちどこかに公開されるのかなぁ。\n以下は、いつもの通り個人のメモです。\n場所：六本木ヒルズ　アカデミーヒルズ49F 日時：2012/04/05 ○Java EE6 Modeling　JS2-01　#jt12_s201 スーツ禁止。Eva好き？ ・特徴 Web Profile Pruing POJO、Annotation、Less XML Java EE6の半分のAPIは変更なし。新規が11% ・JavaEE6 Web Profile CDI、Interceptors、JSR 250 Singleton EJB JPAはEntityBeanの代わりかな？ ・パッケージングがearではなく、war一つで済むように。 war（ウォーファイル） web.xmlはアノテーションで行えるようになり、要らなくなる。 ◯マルチコアCPU時代のJavaプログラミング　JS2-14　#jt12_s214 HotSpotVM依存のお話ですよ。 ・GCとか ・java.util.concurrent.ForkJoinPool デフォルト並列数は論理CPU数 ・メモリアロケーション TLABが非効率に。先にある程度大きめにスレッドに割り当てを行うため、 スレッド数が上がるとTLABが非効率になる-\u0026gt;Eden全体では未使用領域があるんだけどGC発生とか ・JNIでの問題 GetStringCriticalとReleaseStringCritical間はGCが抑止されるため。 ・無意識のロック HashTableやStringBufferなど。 String#getBytes()も。 InetAddress#getAllByName()が内部でキャッシュを持ってる＝ロック File#renameTo()も内部でキャッシュ（ExpiringCache）持ってる。 Javaでは時間がかかる処理にはキャッシュを利用するという仕組みなので。スレッド数を増加させる場合は注意が必要 ・フェアネスロック lock = new Object(); for (int i=0;i\u0026lt;100;i++0{ synchronized(lock){ System.out.println(\u0026#34;i=\u0026#34;+i+\u0026#34;tid=\u0026#34;+Thread.currentThread().getId()); } } 上記を実行してもかたよることがあるよ。＝フェアじゃない モニターによるスレッド割り当ての説明。 RentrantLockでフェアネスになるよ。 ・性能分析 println()で区間分析。複数スレッドで実行したら実行時間にずれが。 println内部でもsynchronizedを利用している。＝ロックのせいで処理時間が遅くなるスレッドが出てきたりする。 JVMTIで性能分析する場合RawMonitorEnter,RawMonitorExitでロックとりあいなるのでもマルチスレッッドだと正しい値がでない。GetThreadLocalStrage使え。 ・まとめ： ハードウェア更改時にプログラムの変更が必要になることもあるよ。 わずかのロックが命取りに（ロックをあんまり使わない、無意識なロックを見極めなさい） ロックポリシーの選択（レスポンス重視なのか、スループット重視なのか） QA Q：事例が合ったという話でしたが、コードの修正しかないんですか？ A：はい。やっぱり治すのがいいです。あとは、チューニングですが。。。 Q：ReentrantLockが昔はスレッドダンプにでなかったのですが、今は？ A：今は出ます。 Q：各世代とJavaのバージョンのマッピングは？ A：第3世代が1.5くらいから。第2世代が1.3とか1.4？ ◯サービス維持・発展を踏まえた楽天オークションのJava EEによる開発と運用　JS2-23　#jt12_s223 ・短期で人材が参加できるようにしているというお話 ・楽天オークションの成り立ち（郵政とdocomoと楽天） ・商品、コミュニティ系（出品とか検索とか）と流通系（入出金、配送など）の2軸 ・メンバー30人くらい ミドルエンジニア エンジニア プロデューサー ・楽天市場をベースとして機能追加 ・巨大でリリースが大変に。 ・この5年で機能分解して機能ごとのリリースをめざして改善している ・JavaEEを使う理由 WebLogic上にバッチが動いているなどの仕組みをしている？ 管理機能が充実している（WebLogic） ・GlassFishへ移行中 あれ？Weblogicの管理機能がいいんじゃなかったっけ？ EJB実装はWebLogicに依存してるのでWebLogicもバージョンアップしてる。 ※メモはここまで。電池の持ちを気にして ◯ JSR 353: Java API for JSON Processing　JS2-33　#jt12_s233 ・JSONとは JavaScript Object Notation 「軽量な」データ交換フォーマット ・JSON仕様のグラフ ・XMLもあるのになんで？ シンプルで可読性が高い 属性がなく、複雑なスキーマ仕様がない。 ・コンパクト ・Twitter、GoogleMaps、YahooWebServicesなど ・JCP、JSRのお話 JSRの役割とか。 リファレンス実装の話。 ・JSR-353 http://jcp.org/en/jsr/detail?id=353 StAXやDOMに対応するよ。 ・ゴールではないもの JSONをJavaのドメインオブジェクトにバインドするとかもどすとか。 ・メンバー @yusukeyも一人 ・参加になったきっかけ 2011/10にTwitterがJCPに参加 2012/12/6にJSON JSR提出 年越しに採択 @yusukey「これTwitterで重要じゃない？」 @cra　「やりましょう」 ・JSRのコミュニケーション 世界各地の人なので、基本メールベース（今は自己紹介したくらい。。） ・既存のJSONライブラリ json.org、jackson、google-gson ・なんで、いろいろあるのにJSR？ 標準化、クラスパスにデフォ、シンプル、ライセンスで悩まないとか。 ・ロードマップ エキスパートグループ作成→アーリードラフト→パブリックレビュー→ファイナルリリース いま、アーリードラフト ・最新仕様 javax.json.* javax.json.spi.* javax.json.stream.* javax.json.tree.* メソッドチェインできるみたい。 JsonObject.create(reader);みたい JsonObject obj = …; JsonWriter writer = obj.accept(writer.) ・改善案 JSON***にしたいな。 spiはらないんじゃないかな？（いま、一個しか無い） treeもいらないんじゃないかな？（そんなに増えないし） parseじゃないかな？ メソッド追加（asStringで文字列化とか、create(String)とか） QA Q：JSONのスキーマ決めないの？バリデータとか A：JSONスキーマはあんまりもてはやされてない。一応あるのはある。 さすがの安定感。適宜笑いが入ってて楽しかったです。 ◯UI Controls and Charts: Drag-and-Drop, Filtering, Sorting, Table Hookup with Charts　JS2-42　#jt12_s242 ◯JavaFX 2.0のControls ◯Label、Button、ToggleButton、RadioButton、Hyperlink、CheckBox ◯Slider、ScrollBar、ScrollPane、ProgressIndicator、ProgressBar ◯TextField、PasswordField、TextArea ◯新しい機能 TitledPaneとAccordion TabPaneとSplitPane ◯Charts XYChartとPieChart XYChartにはLineChart、AreaChart、BarChart、ScatterChart、BubbleChartがある。 ◯Menu MenuItemの下に色々ある。 CheckMenuItem、RadioMenuItem、CustomMenuItem（SeparatorMenuItemとか) ◯ChoiceBox、ContextMenu、ToolTip ◯ListView ◯2.1の新機能 ComboBox、http://fxexperience.com/2012/03/new-in-javafx-2-1-combobox/ StackedBarChart、 StackedAreaChart MenuBarのMac OSへの対応（窓の中じゃなく、画面上部にちゃんと出る。） LCD Text QA： Q：テキストエリアの日本語入力とかは？ A：JavaFX3.0で対応 Q：FXML（Scene Builder）を使ってコードが生成されるのか？ A：ドラッグ・アンド・ドロップでやる場合はScene Builderでもできるでしょう。私はNetBeansとかでやりますけどね。 Q：Dialogはいつ対応されるんでしょうか？ A：私は使ってるんですけど、JavaFXに入れてもらえませんｗコードは出来てますｗ Q：Chartがありますが、pngやsvgでの出力は可能？ A：できません。そのうちできるかも。 Q：Chartの結合はできる？Axisの時間を便利に使うツールはありますか？ A：できないです。ありません。 Q：FX2.0でカスタムコントロール作るの大変？ A：私のマシンでは動いてるんですがｗ Q：ChartにCSSを適用することは可能？ A：可能です。データはJavaから出力されたものだけですけどね。 Q：JavaFX2.0の起動速度が上がったけど、どういう仕組？ A：私は上の方のエンジニアなのでよくわからないですが、GPUをうまく使ってるみたいです。 ◯Learn how the JVM is fundamental to our architecture.　BoF2-03 #jt12_b203 Java、Scala、Linuxのカーネルまで担当してます。 ・Twitterのアーキテクチャ ・スパイクが急にあがる場合にも対応できるスケールの話。 なでしこ、#バルス、大震災など ・Twitterはプラットフォーム ・最上位層：HTTP Proxy（Routing） ・中層：Twitter App（Models/Biz Objects、Composition） UserService、TweetService、TimelineServiceに分解（Models/Biz Objects） API（Composition） ・最下層：TimelineStorage、TweetStorage、SocialGraph、UserStorage（Storage/Retrieval） ・NEEDS サーバ負荷をハンドルできる必要がある。 言語のフレキシビリティ（JavaとかScalaとか） 成熟したコンカレンシーモデル ・Java が提供してるもの 開発者のエコシステムが素晴らしい。例：Nettyを使っている。Non-blocking I/O world class JITとコンカレンシーモデル メモリ管理 利点：メモリ管理を意識しなくていい 課題：GC。OpenJDKのコミュニティで参加してる。 複数の言語が実行可能な環境 ・OpenJDKについて ・Finagleのお話。 Netty上に作られた非同期なRPCサーバクライアントのライブラリ http://twitter.gthub.com/finagle/ ・TimelineServiceのお話 340M/day 10K/sec（イベント時） ・ツイートが入ってくる仕組み HTTP Proxy → tweet API → queue → tweet daemon → fanout （social graph）→ delivery → timeline cache → redis ・fanout 4000フォロワーごとにdeliveryにツイートが渡される。 ・Timelineを見る仕組み HTTP Proxy → timeline API（user service、） →timeline service →timeline cache ・timeline、tweets、users ・timeline serviceとtimeline cacheの関係 Finagleで負荷分散している ・timeline serviceからtimeline cacheへのリクエストを監視して、 高頻度のリクエストについては、timeline serviceのin-process cacheに入れる仕組み ・Service[Request, Response] Scalaの記述 service(request).onSuccess {response =\u0026gt; println(\u0026#34;got response! \u0026#34; + response) } ・Finagleのコンポーネント コネクション管理 プロトコルデコード　ThriftでService以降がつながってる。 分散トレース　オーバーヘッドを抑えて全体を監視（RPCトレース（呼び出しと処理時間のタイムラインチャート）） サービスディスカバリ　observability ◯パネルディスカッション ・JGGUG、JRuby、Scala、Groovyのコミュニティ運営に関係している方々によるディスカッション。 ","date":1333698660,"dir":"post/2012/","id":"56d5711303378bd333ddb611a53ece94","lang":"ja","lastmod":1333698660,"permalink":"https://blog.johtani.info/blog/2012/04/06/java-one-tokyo-2012-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-javaonejp/","publishdate":"2012-04-06T16:51:00+09:00","summary":"JavaOne Tokyo 2012に参加してきました。 4/4-4/5の2日間開催されていたのですが、子供が体調を崩してしまい、4/5のみの参加となりました。 4/4","tags":["勉強会"],"title":"Java One Tokyo 2012 に参加しました。#JavaOneJp(Jugemより移植)"},{"contents":"先日、2.0.0リリースの記事にも記載しましたが、Java7でテストケースが失敗する問題がありました。\n@haruyamaさんと@hideaki_tさんの協力により問題を解消し、trunkと4xブランチにコミットしました。\nissueにも記載しましたが、Java6からJava7にバージョンアップするタイミングで変更されたUnicodeのバージョンが原因でした。 Java6ではUnicodeのバージョンが4.0です。Java7ではUnicodeのバージョンが6.0に変更されています。 今回の問題は「・」（0x30FB）の文字列のCharacter.getType()がCONNECTOR_PUNCTUATIONからOTHER_PUNCTUATIONに変更されたのが原因です。（この変更自体はUnicode 4.1で変更されたみたい） カタカナ文字種の判別をlucene-gosenのnet.java.sen.tokenizers.ja.JapaneseTokenizerのgetCharClass(char c)メソッドで行なっています。 修正前は、ここで、charの範囲が0x30A0～0x30FFにある文字でかつ、Character.getType()がCONNECTOR_PUNCTUATIONでないものがカタカナとして判別されていました。 issueの添付ファイルにJava6とJava7で上記範囲の文字のCharacter.getType()のリストを生成して、該当する文字を探した所、「・」（0x30FB）のみであることがわかりました。 ということで、このコードの意図としては、「・」はカタカナではないと判別したかったのだと。 上記の確認を行えたので、ソースコードを修正してコミットしました。 2.0.1としてリリースするかは、Issue29のボリュームを見て考えますので、もう少しお待ちください。\n参考にしたサイト： JavaSE 7でメソッド名に使えなくなった文字 UNICODE CHARACTER DATABASEのHistory\n","date":1333552800,"dir":"post/2012/","id":"c7937b6b4bde2a96191dc31db913e1ab","lang":"ja","lastmod":1333552800,"permalink":"https://blog.johtani.info/blog/2012/04/05/lucene-gosen%E3%81%AEjava7%E3%81%A7%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E5%A4%B1%E6%95%97%E5%95%8F%E9%A1%8C%E3%81%AE%E5%AF%BE%E5%BF%9C/","publishdate":"2012-04-05T00:20:00+09:00","summary":"先日、2.0.0リリースの記事にも記載しましたが、Java7でテストケースが失敗する問題がありました。 @haruyamaさんと@hideak","tags":["lucene-gosen"],"title":"lucene-gosenのJava7でのテスト失敗問題の対応(Jugemより移植)"},{"contents":"先日、宣言したとおり、lucene-gosenのパッケージ名＋クラス名の変更を行ったlucene-gosen 2.0.0をリリースしました。 Lucene/Solr 3.6.0のリリースを待つつもりだったのですが、なかなか出ないので先にリリースを行いました。 現時点では、branches/4xについては、パッケージ名、クラス名の修正が追いついていません。 明日までに4xブランチについても修正を反映する予定です。\n参考までに、1.2.1から2.0.0への変更点について以下にまとめました。 また、変更に伴い、Solrのschema.xmlに記述するクラス名も変更になります。 schema.xmlのサンプルについてはこちらをご覧下さい。\n変更点 まずは、パッケージ名の変更点です。 左が旧パッケージ名、右が新パッケージ名となります。\n旧パッケージ名 新パッケージ名 org.apache.lucene.analysis.ja org.apache.lucene.analysis.gosen org.apache.lucene.analysis.ja.tokenAttributes org.apache.lucene.analysis.gosen.tokenAttributes また、パッケージ名とは別に、以下のクラス名も変更になっています。 まずは、org.apache.lucene.analysis.gosenのクラス名の変更点です。\n旧クラス名 新クラス名 JapaneseAnalyzer.java GosenAnalyzer.java JapaneseBasicFormFilter.java GosenBasicFormFilter.java JapaneseKatakanaStemFilter.java GosenKatakanaStemFilter.java JapanesePartOfSpeechKeepFilter.java GosenPartOfSpeechKeepFilter.java JapanesePartOfSpeechStopFilter.java GosenPartOfSpeechStopFilter.java JapanesePunctuationFilter.java GosenPunctuationFilter.java なし GosenReadingsFormFilter.java JapaneseTokenizer.java GosenTokenizer.java JapaneseWidthFilter.java GosenWidthFilter.java 次は**org.apache.solr.analysis**です。 旧クラス名 新クラス名 JapaneseBasicFormFilterFactory.java GosenBasicFormFilterFactory.java JapaneseKatakanaStemFilterFactory.java GosenKatakanaStemFilterFactory.java JapanesePartOfSpeechKeepFilterFactory.java GosenPartOfSpeechKeepFilterFactory.java JapanesePartOfSpeechStopFilterFactory.java GosenPartOfSpeechStopFilterFactory.java JapanesePunctuationFilterFactory.java GosenPunctuationFilterFactory.java なし GosenReadingsFormFilterFactory.java JapaneseTokenizerFactory.java GosenTokenizerFactory.java JapaneseWidthFilterFactory.java GosenWidthFilterFactory.java また、上記クラスに関連するテストクラスの名前も変更になっています。\n以上がクラス名、パッケージ名の対応に関する修正ついてでした。\nまた、現在、Java7にてテストケースが失敗する問題が見つかっています。 こちらの問題の対応版についても近日中にリリースを行う予定です。\n問題点、質問などありましたら、コメントしていただくと回答いたします。\n2012-04-03追記 忘れてました、すみません。今回のリリースで、以下の機能が追加されています。\nAntのパラメータにproxy.user、proxy.passwordの追加 GosenReadingsFormFilterの追加 TokenAttributeの修正（PronunciationsAttributeImpl、ReadingsAttributeImpl） Antは認証が必要なプロキシ環境で辞書のビルドを実施するときにユーザ名、パスワードを指定できるようにしました。\nGosenReadingsFormFilterは単語を読みに変換するTokenFilterになります。 よみは、辞書に登録してある読みになります。オプションとして、romanizedが指定可能です。指定をすると、よみをローマ字に変換します。\nTokenAttributeの修正は、バグフィックスになります。Issueはこちらです。\n","date":1333362120,"dir":"post/2012/","id":"06731164684f90f33ce4017eca9d8ec1","lang":"ja","lastmod":1333362120,"permalink":"https://blog.johtani.info/blog/2012/04/02/%E9%87%8D%E8%A6%81lucene-gosen-2-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2012-04-02T19:22:00+09:00","summary":"先日、宣言したとおり、lucene-gosenのパッケージ名＋クラス名の変更を行ったlucene-gosen 2.0.0をリリースしました。 Lucene/Solr","tags":["lucene-gosen"],"title":"【重要】lucene-gosen 2.0.0リリース(Jugemより移植)"},{"contents":"lucene-gosenを利用して頂いてる皆様に連絡があります。\n連絡事項 次期lucene-gosenのリリース（2.0を予定）にて、org.apache系のパッケージ名および、クラス名の変更を行います。 Lucene/Solrの次期リリース版である3.6.0以降では、lucene-gosen 2.0（予定）を利用するようにしてください。\n経緯 Twitterでは少しずつツイートしていますが、Lucene/Solr 3.6から日本語の形態素解析器がLucene/Solrにて用意されることになりました。 ベースとなっているのは、Atilika社が開発したKuromojiという形態素解析器です。 Lucene/SolrにコントリビュートされたタイミングではKuromojiAnalyzerなど、Kuromojiという名称が残った形で取り込みが行われました。 その後、LUCENE-3909にて、Kuromojiではなく、一般的な名称（Japanese*）に変更する提案が行われました。 この提案で、luene-gosenが利用しているクラス名、パッケージ名と大半のクラスが衝突してしまうこととなりましす。 今後も、lucene-gosenを利用していただけるように、lucene-gosenのIssueを発行し、 現在、lucene-gosenのtrunkにてパッケージ名の変更及びクラス名の変更作業を行なっています。 正式にリリースするタイミングになりましたら、再度連絡いたします。\nブランチなどについて 現時点ではパッケージ名、クラス名の変更はリポジトリの以下のものについてのみ作業を行う予定です。\ntrunk branches/4x 現時点でのリリース版（1.2系）のソースについてはbranches/rel-1.2にて、これまで同様のクラス名、パッケージ名のまま変更を行いません。 1.2系についてはこちらをご覧下さい。\nまた、当ブログにて、提供しているSolr入門のサンプルに利用可能なschema.xmlなどの記事についてもLucene/Solr3.6がリリースされた際には再度修正して掲載いたします。 Kuromojiの利用方法もあわせて記載したいです。\n参考： lucene-gosenとKuromojiの機能などの比較についてはこちらを参考にしてください。\n","date":1332783540,"dir":"post/2012/","id":"f8327953a0f0b80011b939111807999a","lang":"ja","lastmod":1332783540,"permalink":"https://blog.johtani.info/blog/2012/03/27/%E9%87%8D%E8%A6%81lucene-gosen%E3%81%AE%E6%AC%A1%E6%9C%9F%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-03-27T02:39:00+09:00","summary":"lucene-gosenを利用して頂いてる皆様に連絡があります。 連絡事項 次期lucene-gosenのリリース（2.0を予定）にて、org.","tags":["lucene-gosen"],"title":"【重要】lucene-gosenの次期リリースについて(Jugemより移植)"},{"contents":"子供の寝かしつけしてたら、寝かしつけされてしまって、２時に目が覚めてしまいました。 TSUTAYAでCD借りてきてウォークマンに入れようと思っていたのに。。。 ということで、今作業してます。\nMBAを買う前から使っている、もう９年目のWindows自作デスクトップで基本的にはCDの取り込みをしています。 ファイルサーバ（BuffaloのTeraStation）がLionから接続できないというのと、 X-アプリで曲管理していたのでという理由です。 あと、ウォークマンなのでMac用のソフトがなかったりというのも理由です。\nで、眠い目をこすりながらWindowsマシンを起動すると、ネットワークにつながらないじゃないですか。。。 再起動してもダメでした。\nとなってしまったので、せっかく、譲ってもらったMac miniも活用しないといけないなと思い、iTunesでアルバムを取り込んでみています。 ここ数年はWAV形式でデータを取り込んでいたので、WAVでの取り込みを設定して、iTunesで取り込みました。\nとまぁ、ここまでやってから、件のWindows機を再度、再起動したらネットワークに繋がってしまいました。。。 なので、残りのCDはWindows機で取り込みしてます。 けど、そろそろこのPCも危なそうなので、データをサルベージして、Mac miniで作業できるようにしないとなぁ。 Macでウォークマンを運用している人はどうやってるんだろう？ ちなみに私が利用しているウォークマンはNW-A847です。 エンコードはWAV形式で取り込んで、X-アプリでウォークマンに入れています。 iTunes使ってる人は、アップルのロスレスエンコードをつかってるのかなぁ？ ということで、調査・検討したい項目はこんなところですか。\n調査：TeraStationにMacからつなぐ方法（Lionで利用できそうなソフトなにかないかな？） 調査：iTunesでウォークマンに曲転送（やってみればすぐわかるだろう。。。） 調査：iTunesの曲をCDに焼く方法（車で曲聞くのにCDだから） 検討：ファイルサーバのリプレース対象となる機種（ファイルサーバは導入してまだ５年だから余裕がないと買い換えない） 検討：iPodに鞍替え（Sony好きだし、ウォークマン好きだし、買ったばっかりだからまず無い選択肢） 検討：Mac miniにVirtualBox入れて、WindowsからX-アプリ使うとか。（ファイルサーバが見えるようになるかな？） 検討：Mac miniをWindowsとして運用（もったいなさすぎる気がする） とまぁ、まだ悩んでるだけで、取り留めもない事を書いて、しかも結論が出ないままですが、ご容赦ください。 ご意見、提案を大募集してます！！\n","date":1332618420,"dir":"post/2012/","id":"8b76101d185700a8efed148d8722d926","lang":"ja","lastmod":1332618420,"permalink":"https://blog.johtani.info/blog/2012/03/25/%E4%B9%85%E3%80%85%E3%81%ABmac-mini%E3%81%AE%E3%81%93%E3%81%A8%E3%81%A7%E3%82%82/","publishdate":"2012-03-25T04:47:00+09:00","summary":"子供の寝かしつけしてたら、寝かしつけされてしまって、２時に目が覚めてしまいました。 TSUTAYAでCD借りてきてウォークマンに入れようと思っ","tags":["備忘録"],"title":"久々にMac Miniのことでも(Jugemより移植)"},{"contents":"はい。またまた、Twitter API勉強会に参加してきました。（今回から開催回数の記載がなくなった？） 今回は直前でタイムテーブルが変わってしまう波乱がありましたが、個人的には楽しめる内容でした。 Twitterの国際化や形態素解析などの話が聞けたのがすごく面白かったです。 アーキテクチャや利用されている形態素解析器の話など、また、現状の問題点なども話が聞けました。 日々、進化しているんだなぁと。 残念ながら、発表者の方が懇親会にいらっしゃらなかったので、詳しく聞けませんでしたが、挨拶だけは出来ました。 実際のテスト環境や導入方法、A/Bテストとかやってるのかなど、ブログをかきながら色々と気になることが出てきてしまいますｗ 頭の回転がよくないので、話を聞いてる間は質問があんまり思い浮かばなかったなぁ。。。\nその他にも（使ったことなくてすみません。。。）「昼会」のサービスの話、他の言語でのTwitterの活用の話も聞けました。\n途中で帰ってしまいましたが、懇親会でも数人の方とお話できて、楽しかったです。 （今回の懇親会会場はちょっと人数の割に手狭だったかもなぁ）\n次回は4月末を予定しているようでした。今度こそ、利用規約の話になるんですかね？ 忙しさを見つつ、また参加しようかと思います。\nということで、いつものメモです。\n開催日時：2012/03/21 19:00 ～ 21:00場所：ハロー会議室shibuya Zusaarのページ\n◎Twitterの日本語検索、ハッシュタグについて　@keita_f\n◯アーキテクチャ ・Twitterバックエンドの国際化 Before 各言語ごとに独自実装。 After 共通テキスト処理ライブラリ：Penguin ・アーキテクチャ：検索 Firehose → ingester → Earlybird ⇔ Blender ← ユーザの検索 Firehose：ツイートの受信 ingester：ツイート解析 Earlybird：Luceneベースのインデクサ Blender： ・アーキテクチャ：トレンド TrendsはGeo（ユーザ位置情報）を利用してるっぽい。 Term Statisticsは過去ツイートからHadoopで頻出フレーズを解析する。 今頻出しているフレーズ＋過去頻出しているフレーズ ◯日本語関連 ・ツイートの言語判定 言語判定にはIndigenous Tweets（Kevin Scannell）をベースに実装。 ５０言語サポート、Javaで実装 ・文字種チェック ・エンコーディングチェック ・Ngram（the→英語、das→ドイツ語） 問題点： ２つ以上の言語が混じってる場合 絵文字が入ってる場合 Unicodeアルファベット ・形態素解析 日本語：Gomoku 中国語：LuceneのSmartCN その他：N-Gram 問題点： 形態素が小さすぎる →そのままだと細かすぎるので品詞情報を元に大きめに区切るようにしている iPhone4Sなどが数字で区切られる →ASCIIの数字とアルファベットは連結しなおす ・フレーズ抽出 他の言語もあったけど、キー入力間に合わず 日本語の場合： トークンに分割 トークンでNgramを生成 品詞情報を使ってフィルター 最初、最後が助詞はNG、接頭詞で終わるのはNG ・やりたい事はまだまだたくさん ・形態素解析の品質向上 辞書への単語追加 韓国語、タイ語のトークなイザー ・同義語、類義語、翻訳、音訳、略語などのサポート ・フレーズ・トピックのクラスタリング ・Sentiment Analysis ・日本語のできるエンジニア募集中ｗ QA Q：顔文字を手動で抜き出すと言われたんですが、どのくらいあるんでしょうか？　A：正規表現なので、なんとも言えませんが、パターンを Q：Gomokuの選択の理由は？ A：Javaだから。jarに辞書が入るから。スピードが出るから。 ◎ランチタイム共有サービス「昼会(http://www.hirukai.jp/)」のご紹介　@setomits\n◯前提 ・ネットワーキングは重要 ・出会いも重要 ・飲み会だとコスパが悪い ◯ランチだと ・金額が限られる ・必ず食べる ということで、昼会だ！ ◯画面でサービスの説明 パブリックな昼会、プライベートな昼会がある。 ◯なんでTwitter？ LinkedInのOAuthを使ったログイン検討してた。 ビジネス目的＋ 敷居が高いのでTwitterに変更 ◯Twitterのapiで利用しているものなど ◯ユーザの声 ・DMを使ってる＝自分からのDMが気持ち悪い APIの使用制限やフォローしてもらう必要があるのが辛い。 - スパムかと思った - 乗っ取られたかと思った。 - エンジニアからは、「まぁ、こうするよね」 ・OAuthについて - ユーザ登録しなくていいのは嬉しい - イベント参加のためにOAuthでの書き込み権限まで与えたくない ◯８ヶ月経って ・新しい出会いがあった ・昼会を開催する敷居が高い ＝なかなか使ってもらえない ◯今後の計画 募集中！ QA Q：AppEngineで月額どのくらい？ A：料金改定前：数千円/１ヶ月、料金改定後：２万円くらい/１ヶ月 処理数を減らして、現時点では数千円/１ヶ月に最適化した Q：夜会はないんですか？ A：設計していたら、出会い系サイト？になりそうなので、昼にした。 ドメイン的になぁ。まだ悩み中 Q：GAE特化したもの？AWSに移行できる作り？ A：できない作りです。（pythonで書いてます。） GAEが楽なので、移行可能な作りにするのがつらい。 ◎LT ◯Twitter 4 contact　@inda_re ・広告！アジャイルサムライの道場\n・問い合わせフォームをTwitterにしちゃう 今あるHTMLにフォームを入れる方法（MySQLとPHP） githubにサンプルあるよ。 ◯PerlのTwitterモジュールについて　@xtetsuji\n・前回出席したら、ムチャぶりが！ ・いまどきのPerl 進化してるよ、古い情報が検索で出てきてしまうのがネック ・perlbrewってのがある http://perlbrew.pl/ ・AnyEvent::Twitter::Streamをよく使ってます。 ・gistにサンプルあげてあるよ！ ◯KotlinでもTwitter4J　@ngsw_taro ・Kotlinの説明 ・以下のサイトでインストールしなくても動かせるよ！ http://kotlin-demo.jetbrains.com/ ・NULL安全 Nullを許容する型、許容しない型がある。 ・一応、Twitter4Jのサンプルも作ったけど、ブログ見てね http://d.hatena.ne.jp/ngsw_taro/\n◯締め Twitter API勉強会ではスピーカーを常に募集中です。登録はこちら！\n","date":1332343680,"dir":"post/2012/","id":"16b3c9445539e9274282a612dea354c2","lang":"ja","lastmod":1332343680,"permalink":"https://blog.johtani.info/blog/2012/03/22/%E7%AC%AC5%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%B8%8B%E8%B0%B7--twtr_hack/","publishdate":"2012-03-22T00:28:00+09:00","summary":"はい。またまた、Twitter API勉強会に参加してきました。（今回から開催回数の記載がなくなった？） 今回は直前でタイムテーブルが変わってし","tags":["勉強会"],"title":"第5回 Twitter API勉強会 @渋谷 #twtr_hack(Jugemより移植)"},{"contents":"TLで面白いと見かけて、Amazonで買ってしまいました。 SEやってるのに、つい最近Amazonを使い始めた軟弱者です。 それにしてもAmazon危険です。スマートフォンにAmazonの Androidアプリを入れたのですが、これがまた、レコメンドに面白そうな本が出てきて危険です。\n話がそれてしまいましたが、面白い本でした。 久々に、小説でも技術書でもない本を短期間で読みました。 「箱」と呼ばれる概念の中と外について、とある会社に転職した管理職の人が学んでいくという物語風の作りです。 いくつか、自分の経験にカブるシーンがあったので、サクサク読めました。 今までの自分になかった考えである「箱」という視点が得られたのがよかったです。\nただ、いくつか気になる点もあるので、また少し時間を開けてからサラっと流し読みしたいと思います。\nあと、すこしだけ、キリスト教チックな考え方でもあるかなぁと思う部分もありました。（キリスト教をちゃんと勉強してるわけではないので認識が間違ってるかもしれないです）\n人によっては共感出来なかったり、読みにくかったりすると思いますが、私は面白いと思った本でした。 なんとなく、人間関係に違和感を感じていることがある場合は目を通してみるといいかもしれません。\nTwitterで読み終えたというツイートをしたら、「自分を変える気づきの瞑想法」を読むとまた面白いですという＠ツイート（これがmentionの日本語の正式名称らしい？）を@ledsunいただきました。 箱に入る原理が別の視点で書かれているようです。 読んでみたいです。（本会過ぎてる気がするので、図書館で探そうかなぁ。。。）\n自分を変える気づきの瞑想法【増補改訂版】 自分を変える気づきの瞑想法【増補改訂版】 ","date":1332253920,"dir":"post/2012/","id":"ee623aaa99b429863f89da313fffed97","lang":"ja","lastmod":1332253920,"permalink":"https://blog.johtani.info/blog/2012/03/20/%E8%87%AA%E5%88%86%E3%81%AE%E5%B0%8F%E3%81%95%E3%81%AA%E7%AE%B1%E3%81%8B%E3%82%89%E8%84%B1%E5%87%BA%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-03-20T23:32:00+09:00","summary":"TLで面白いと見かけて、Amazonで買ってしまいました。 SEやってるのに、つい最近Amazonを使い始めた軟弱者です。 それにしてもAmaz","tags":["読書"],"title":"「自分の小さな「箱」から脱出する方法」を読みました。(Jugemより移植)"},{"contents":"えーと、ブログ更新してないなぁとふと思ったので。 １年前くらいからずーっと、つぶやいてましたが、やっとScalaを始めました。 長かった。。。 とある、サンプルデータを作成するので、ついでにScalaを勉強してしまえという感じで始めました。\nScalaで学ぶ関数脳入門を買ってもう１年以上経ってました。。。 とりあえず、CSVデータからInsert文を作ってます。 書籍を見ながら、四苦八苦してるところです。 今日は、csvファイルを読み込んで適当に出力した所で終了でした。 現状を忘れないようにというのと、いくつか気になった点があったので、備忘録のため上げておきます。\nscala IDE for Eclipseを利用（もっさりしてる） classとは別にobjectというものがある点に慣れない セミコロンいらないのに、ついつい打ってしまう usingを利用しようとしたが、Eclipseに怒られた（なんで？） メソッドの戻り値を省略出来る場合とできない場合がよくわかってない Javaが混ざる（ファイル出力にBufferedWriterを使う）のがまた戸惑う ということで、四苦八苦してますｗ ７つの言語、７つの世界も参考にしつつ、コップ本をパラパラしながら、ググって書くといった感じです。 Javaだととっくにできていると思うのですが、まだ、読み込んで出力できただけです。\n新しいものに触れるのは頭を使って面白いのですが、思い通りに行かず（とくにIDEがもっさりしてたり、上手く使えなかったり）イライラもしていますｗ まぁ、ちょっとずつ勉強していきます。\n（ほかにもいろいろやらないとなぁ。。。）\nScalaスケーラブルプログラミング第2版 Scalaスケーラブルプログラミング第2版 ","date":1331652421,"dir":"post/2012/","id":"116c9be6d760b4befa6d51ce9e96604c","lang":"ja","lastmod":1331652421,"permalink":"https://blog.johtani.info/blog/2012/03/14/scala%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-03-14T00:27:01+09:00","summary":"えーと、ブログ更新してないなぁとふと思ったので。 １年前くらいからずーっと、つぶやいてましたが、やっとScalaを始めました。 長かった。。。 と","tags":["Scala"],"title":"Scala始めました(Jugemより移植)"},{"contents":"森ビルに行ったことなかったので、参加してみました。 あと、最近まともにコーディングしてないので、そのへんを矯正するためにもと思って。 （まぁ、遊びに行きたかっただけなんですけどね）\nすこし遅刻して参加です。 会場は、Twitter Japanさんの@yakitoriでした。ここだけ、撮影可でした。 で、肝心のハッカソンの中身です（ハッカソン自体、初参加！）。 Twitter APIもTwitter4Jも触ったことがありません。 なので、ソファーに座ってMac Book AirでTwitter4Jのサンプルを眺めながら、とりあえず、Solrに流しこむってのを作ってみました。 今回、Solrに用意したのはlucene-gosenによる形態素解析を行うフィールドとあとは、Solrのexampleについてるダイナミックフィールドたちです。 Twitter4Jからどんなデータが取れるかわからないので、ダイナミックフィールドで型だけ指定してSolrを起動しておきます。 次に、Twitter4Jにあるsample()にてパブリックなツイートの1%を取得（適当なのがこれくらいしか思い浮かばなかったから）。 あとは、SolrJのStreamingUpdateSolrServerを利用して、流し込みです。 あんまり時間がなかった（準備とかウォーミングアップで時間かかった）ので、結局、Screan名とツイート本文を SolrInputDocumentに無理やり詰め込んで登録しただけでした。 ほかにも色々と情報が取れるはずなので、そのへんも格納してファセットとかで遊びたかったなぁ。 とまぁ、こんな感じでタイムアップです。（コードは大したことないので文章だけでｗ） 画面も用意出来なかったので、発表はSolrのダサい管理画面で検索でした。 次回は、もう少し中身を勉強して画面もbootstrapで作ってとかやってみたいですね。 あと、自己紹介スライドに書きましたが、Scalaから使ってみるのもやってみたいです。（その前に、Scalaに入門しないといけないんですけど。。。）\nということで、個人的にいろいろと反省点があるハッカソンでした。 反省点：\n立ち上がりに時間がかかった（普段からコーディングしてないから） Twitter4Jについて事前に勉強してない（ごめんなさい） 環境面が整備しきれてない Twitter API ポケットリファレンス（右の本）を忘れた。。。 スターウォーズのピザの箱の写真取り忘れた＞＜ 普段、コーディングをしていない仇が出てしまいました。 もっと、すぐにコーディングをできる環境、体質を日頃から鍛えておかないといけないなぁと。 （SolrやTwitter4JのJavaDocをオロオロしながら探すとか情けないです。。。）\n場所や雰囲気は全然問題ありませんでした。 ピザを@yusukeyさんからごちそうになったり、飲み物、お菓子が用意されていたりと至れり尽くせりでした。 iPadで音楽も流してくれてたし。 他のハッカソンに参加したことないので比較はできないですが、集中できてよかったです。 あと、ソファーでコーディングもなかなかいいなぁと実感出来ました。（初めて！） 人数的にもこのくらいのほうが話がしやすくていいかなぁと。発表も時間かからないですし。 ただ、帰り道に誰かが言っていましたが、「マラソンというよりは短距離走だったね」というのは否めないかなぁと。 時間は限られちゃうので、準備をしっかりしないとなぁと。 私としては、土日のハッカソンだと参加しづらいので、平日開催がうれしいのですが。 いやぁ、楽しかったです。みなさんの面白いネタも見れたし。（自分のやったのは普通すぎて少し恥ずかしかったです。。。） あと、GoogleDocsの使い方（自己紹介スライドとかアンケートの集計とか）も学べたのが収穫でした。 @yusukeyありがとうございます！ 次回もありそうなので、懲りずに参加しようかな。\nさて、他の方たちのブログやtogetterは@yusukeyさんのページからたどってくださいｗ。 第0回Twitterハッカソンを開催しました #twtr_hack\n今日購入したCD聴きながらブログ書いてます。 タワレコで視聴して購入したCDです。 なかなか大人な雰囲気でオススメです。 Heaven ","date":1331230200,"dir":"post/2012/","id":"4d6c95b0b3ea2ddb30fdd3edf3b82391","lang":"ja","lastmod":1331230200,"permalink":"https://blog.johtani.info/blog/2012/03/09/%E7%AC%AC0%E5%9B%9E-twitter-hack--twtr_hack-%E3%81%AB%E9%81%8A%E3%81%B3%E3%81%AB%E8%A1%8C%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-03-09T03:10:00+09:00","summary":"森ビルに行ったことなかったので、参加してみました。 あと、最近まともにコーディングしてないので、そのへんを矯正するためにもと思って。 （まぁ、遊","tags":["勉強会"],"title":"第0回 Twitter Hack #twtr_hack に遊びに行きました。(Jugemより移植)"},{"contents":" Clean Coder プロフェッショナルプログラマへの道 Clean Coderを読みました。 理由はTwitterで「Clean Code」がいい本だと流れてきたためです。 「Clean Code」はまだ読んでいないのですが、クリーンなコード（メンテナンスしやすく、修正などもやりやすいコード？）を書くために必要な話が書いてあるのだと思います。（まだ妄想）\nそして、何も考えずに、「Clean Code”r”」という本が新しく出ていたので、新しい方に手を出しました。 まぁ、軽い勘違いですｗ（コードの構造の話などは出てこなかったです。） それほど分厚くなく、軽く読めそうだということで読み進めると軽い衝撃を受けました。 Clean Coderはプロのプログラマとして、どのような意識を持つべきか、立ち居振る舞いをするべきかなどが書かれています。 「～したい」はまず守らない約束だという話、ユニットテストを書くことはプロとして当たり前の行為だ、目的意識を明確に持つことなどなど、耳の痛いことが色々と書かれています。 これは、著者の方（パンチカードのころからコーディングをされている！）の実体験を元に、失敗した経験から導きだされているようです。 ところどころ、古くてよくわからない話やちょっとだけしっくりこない表現（ビジネス、QAといった単語）もありましたが、概ねわかりやすい話でした。\n基本的にはアジャイルなスタイルの開発を行うプログラマ（設計書に基づいてコーディングするだけの人ではない）について書かれています。 この本を読んでいて、昨年、仕事をご一緒させていただいたRubyistの方たちの開発スタイルを思い出しました。 私よりもこの本に書かれているプロに近いなぁと。 ペアプロやったり、実装方法について相談していたりと。\n勘違いでしたが、良い本に出会えて本当によかったです。 私もこの本に書かれているようなチームでのプログラミングをやりたい、またなにかコーディングをしたいという気にさせてくれました。（「～したい」じゃダメって書いてあったのに。。。） 自分を戒めるためにも、定期的に読み返したい本です。 プログラマでいたい方、ある程度プログラミングができるようになってきた方にはぜひ読んでいただきたい本です。 （この流れで、アジャイルサムライやClean Codeを読んだら理解が深まりそうだなぁ）\n参考URL： 35歳定年説をブチ破れ！「Clean Coder プロフェッショナルプログラマへの道 Robert C. Martin」 - ledsunの日記 ","date":1330704840,"dir":"post/2012/","id":"10eb415a232ad4be7d05c57eb850036c","lang":"ja","lastmod":1330704840,"permalink":"https://blog.johtani.info/blog/2012/03/03/clean-coder%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A0/","publishdate":"2012-03-03T01:14:00+09:00","summary":"Clean Coder プロフェッショナルプログラマへの道 Clean Coderを読みました。 理由はTwitterで「Clean Code」がいい本だと流れてきたためです。","tags":["読書"],"title":"Clean Coderを読んだ(Jugemより移植)"},{"contents":" 親子で楽しめる 絵本で英語をはじめる本 Twitterでこの本について書かれたブログ記事が流れてきて、購入しました。\n最近、英語を身につけておいたほうがいいなと思うことが多々あり、子供にも英語を勉強してもらいたいなと思っていたところでした。 あとは、私自身が英語が苦手というのもあり、子供をダシにして勉強したいというのもありまして。。。 サラっと読んでみましたが、参考になりました。 特に「多読」というキーワードが面白かったです。こちらが元のようですが。 多読とは、文章を分析しないで大意を把握する読書法だそうです。\n辞書を引かずに楽しめるものを読む わかるところをつなげて読む 自分が面白いと思う本を選んで読む という原則があるようで、確かにいいなと思いました。 絵本だと絵が書かれているので、辞書を引かなくても想像できそうですし、楽しめそうだなぁと。 また、多読は先日読んだ、速読の本に書かれていた本の読み方にも通じるものがあるなと。（まだ、実践できてないんですけどね）\nどうしても英語を勉強させたい！、勉強しないと！と思ってしまいがちですが、この本にも書いてあるように楽に楽しんでやったほうがやっぱいいなぁと。 楽しくないと続かないですからねぇ（実際、何度も挫折してるし、押し付けられるとヤル気がなくなるので。。。）\nということで、実践してみようと思います。（平日は子供が寝てしまってから帰宅なので、まずは土日から）子供のためというよりは、自分の英語の勉強のために。 まずは、簡単な絵本を購入して。 この本の後半半分は、著者の方の感想や説明がついた、オススメの絵本50冊が書かれています。 英語の絵本を入手するのは、結構大変（実際に売ってる店もなかなかないし、手にとって見る機会も少ない）だと思うのですごく参考になりそうです。 いくつかピックアップして、あわよくば本屋で手にとってみようかと。なければ、Amazonで購入しようかなぁと思ってる所です。\n","date":1330186800,"dir":"post/2012/","id":"627a0c45dd07150343c81d856855590e","lang":"ja","lastmod":1330186800,"permalink":"https://blog.johtani.info/blog/2012/02/26/%E8%A6%AA%E5%AD%90%E3%81%A7%E6%A5%BD%E3%81%97%E3%82%81%E3%82%8B-%E7%B5%B5%E6%9C%AC%E3%81%A7%E8%8B%B1%E8%AA%9E%E3%82%92%E3%81%AF%E3%81%98%E3%82%81%E3%82%8B%E6%9C%AC/","publishdate":"2012-02-26T01:20:00+09:00","summary":"親子で楽しめる 絵本で英語をはじめる本 Twitterでこの本について書かれたブログ記事が流れてきて、購入しました。 最近、英語を身につけておいた","tags":["読書"],"title":"親子で楽しめる 絵本で英語をはじめる本(Jugemより移植)"},{"contents":"今週も勉強会に参加しました。 @yusukey さんが開催してるTwitter API勉強会です。 前回とは会場が異なりましたが、広くて大画面で良い会場でした。駅も近いし。（デジタルハリウッドさいこー！） 今回はLT枠のbootstrapの話が聞きたくて参加しました。（ムチャぶり駆動勉強会の現場をTLで目撃してたのでｗ） あと、バーチャファイター（昔、VF目当てでセガサターンを買ったなぁ、懐かしい）の話も聞きたかったので。 （ごめんなさい、Twitter APIはまだ触る機会がなさそうです。。。） 今回も途中で参加者同士を数グループ（座席が近い人）に分けて自己紹介タイムがあり素敵でした。 ちょっと残念だったのはネームプレートが今回はなかったことでしょうか。 自己紹介でツイッターID教える＋聞くのがちょっと辛かったです。（やっぱり個人名刺作ったほうがいいかなぁ） 私はPCを開いていたのでTwitterのページを見せることで対応出来ましたが。 （次やるときはお手伝いするのでこえかけてください。）\n内容はメモをとってあり、下に書いてますので見ていただければ。\nTwitter APIの説明はいろいろ新鮮でした。今回はWebページに貼るリンクやボタンの話でした。 カスタマイズも出来るようになってるってのは知りませんでした。Webサイトやってる人は簡単にカスタマイズできるのは便利ですよね。\nバーチャファイターのTwitter連携の話は結構詳細な話が出てきてびっくりでした。（テーブル名とかまで出てきましたｗ） ゲーム筐体の前のユーザの動きまで考えてシステム作るとかすごいなぁとか。違う業界の話って面白いです。\nBootstrap入門はbootstrapの紹介だけじゃなく、Tips（bootstrap弊害とかw）やその他の便利なサイトの紹介までありました。 スライドもあとから読んでもわかるのがすごく嬉しいです。時間を見て試してみます。 TwitterSphereは懇親会でもデモが見れました。Groovyは名前を知ってるだけだったのですが、Swingとかまで動くんですね。（JVMだから当たり前なんだけどなんか新鮮。） 最後はAndroidのAPI Demoのお話。こちらも普段Android携帯使ってるのに知らないことが多くて。。。 Macでもデモが動くんですね。やっぱり動くものを作ってLTするのって素晴らしいですねぇ（なんか作るかー）\nとまぁ、最近はキーワードだけ知ってて、いろいろ触れてもいないものが多いなぁと思ってたところに、 今日の勉強会で色々見れて面白かったです。 Twitterがいろんな人に興味を持たれているのがわかります。 （けど、Twitterってどうやって儲かってるんだろう？？？） 懇親会は、入り口からは想像できない貸パーティースペースで素敵でした。 開始の乾杯の音頭を取ることもできましたし（もちろん、ムチャぶり）。 学生が多かったのですが、声をかける暇なく懇親会が終わってしまったのが少し心残りですかねぇ。 毛色が違うメンバーが居て面白いので、次回も空きがあれば参加しようと思います。 スタッフとかお手伝いもしますので。\nということで、いつものメモです。\n開催日時：2012/02/23 19:00 ～ 21:00 場所：デジタルハリウッド東京本校 1Fセミナールーム Zusaarのページはこちら。他にも学生枠とかありました。\n◯ Webサイト向けAPI @yusukey\n・Webサイト向けAPI フォローボタン、ツイートボタン、Web Intents、@Anywhere サーバサイドの実装扶養、htmlのみで構成可能 ・Twitterボタン Twitterのサイトで色々カスタマイズ可能なボタンが作れます。 ツイートのカウント表示とか。 ・Web Intents @ツイート、リツイート、お気に入りが簡単にできるものが作成可能。 ツイートの埋め込み用リンクがTwitterのWeb版のツイート詳細から生成可能。 「このツイートをサイトに埋め込む」リンクをクリックするとダイアログが出てきます。 ・@Anywhere あんまりフォローされてないけど、JavaScriptでサーバサイドなしにTwitterと連携可能。 ユーザIDを辞書的に検知してTwitterの情報をホバーで出してくれる。 ・ウィジェット（検索、プロフィール、お気に入り、リストなど） これもTwitterサイトでカスタマイズ可能。 ・ツイートボタンには公式ロゴを利用しましょう ・注意点 charsetを必ず指定しましょう。 IE/Firefoxで問題が発生します。 ◯ グルーブに分かれて簡単に自己紹介\n◯ デジタルハリウッドよりご挨拶\n◯ 「Virtua Fighter5 Final ShowdownのTwitter連動機能について」@twtrfk\n部内にAmitterというSNSを構築して自由に使ってもらって、Twitterを疑似体験してもらった。 VF5FSでの開発中はTwitter4JにAmitterのラッパーを追加してテストしてたらしい。（おもしろいなー） 当時は、筐体にツイート機能を入れることも考えていたらしい。 ツイート自体はバッチで処理してます。 ゲーム筐体にお客さんが座ってる時間もシステムの性能として考慮しないといけない。 苦労した点： テストアカウントを100個地道に作成（連番、内容がバレるアカウント名はNGだから） Twitter4Jがうまく動かなかった。。。 今後の展開： まだ未定 QA Q：FB連携とかは？ A：今は考えてないです。 ◯ LT ・ @making「Twitter Bootstrap入門」 スライドはこちら\n・Bootstrapとは？ Twtter者が提供するWebアプリケーションのフロントエンド 一般的にCSSフレームワークと呼ばれるもの 簡単にかっこいいデザインにするための枠組み ダウンロードしてきてHTMLで読み込むだけ。 ・Bootstrapのコンポーネント紹介 いろいろおしゃれなコンポーネントあるよ。（スライド見ましょう） ・Tips examplesがあるので、それをベースに作るのが簡単です！ Initializrも対応してて、こっちで作るのもいいよ！ bootstrap簡単すぎて、みんな同じデザインのサイトに（弊害） 差別化のサービスが出てきてます。 ・ @kimukou_26 「TwitterSphere of Twitter4J」\nGriffon？ codehausで作られてるGroovy製のMVCイメージのGUIフレームワーク codehausはJetty作ってるとこですね 地球儀にツイートを乗っけることができるアプリ。 Groovyの記述がちょっと新鮮。 ・ @bina1204 「ApiDemos of Twitter4J for Android」\nAPI DemosというAndroidのデモがあり、ここにTwitter4Jを仕込んでみた？ Android系は持ってるのに知らない。。。 ","date":1330015800,"dir":"post/2012/","id":"966fe8d32b86121f8a465a21b95f7e5c","lang":"ja","lastmod":1330015800,"permalink":"https://blog.johtani.info/blog/2012/02/24/%E7%AC%AC4%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E3%83%8F%E3%83%AA%E3%82%A6%E3%83%83%E3%83%89--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-02-24T01:50:00+09:00","summary":"今週も勉強会に参加しました。 @yusukey さんが開催してるTwitter API勉強会です。 前回とは会場が異なりましたが、広くて大画面で良い会場でした。駅","tags":["勉強会"],"title":"第4回 Twitter API勉強会 @デジタルハリウッド #twtr_hack に参加しました。(Jugemより移植)"},{"contents":"久々にlucene-gosenの話です。 しかも、あんまり嬉しくない話しです。\nすでにissueをアップしていますが、lucene-gosenとSynonymFilterを併用する場合に、特定の条件下でNullPointerExceptionが発生してしまいます。\n条件は以下の組み合わせになります。\nSolr 3.5.0以前 lucene-gosen1.2.0 - 1.2.1の辞書なしjar SynonymFilterFactoryにてtokenizerFactoryを指定 根本的にはSolr側の問題のようです。SOLR-2909としてissueが上がっています。\nSynonymFilterFactoryでは、類義語の設定ファイルの単語を読み込むときにtokenizerFactoryを指定できます。 このとき、SynonymFilterFactory内部でtokenizerFactoryに指定されたFactoryのクラスが読み込まれ、 インスタンス化されて、Tokenizerが作成されます。 この、Tokenizerのインスタンス化の処理シーケンスに問題があります。 schema.xmlの\u0026lt;tokenizer\u0026gt;タグで指定されたTokenizerFactoryでは、ResourceLoaderAwareインタフェースのinform(ResourceLoader loader)メソッドが実行されます。 このinform()メソッドがSynonymFilterFactoryのToeknizerのインスタンス化の場合に実行されません。 lucene-gosenのJapaneseTokenizerFactoryではこのinform()メソッドでdictionaryDirのパスの読み込みを行なっています。（このへん）\n上記の条件では、NullPointerExceptionが発生すると書きました。 辞書を内包したjarファイルを利用している場合、NullPointerExceptionが発生しなくても次のような問題点があります。こちらの問題は見た目は動いているように見えてしまうので注意が必要です。 すべて、SynonymFilterを利用する時点でも問題点になります。\ncompositePOS設定が類義語辞書読み込み時に無効 dictionaryDir設定が類義語辞書読み込み時に無効（＝jarに内包されている辞書で動作する） 一見動いているように見えるかもしれませんが、望んでいてる動作になっていない可能性があるので注意が必要です。\n解決策（まだ途中） 先程書きましたが、基本的にはSolr側の修正をするのが妥当です。 SolrのJIRAにパッチもアップされました。 こちらのパッチをSolrに適用し、SynonymFilterFactoryを次のように指定することで問題を回避することが可能になります。\n\u0026lt;tokenizer class=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; compositePOS=\u0026#34;compositePOS.txt\u0026#34; dictionaryDir=\u0026#34;dictionary/naist-chasen\u0026#34;/\u0026amp;gt; ... \u0026lt;filter class=\u0026#34;solr.SynonymFilterFactory\u0026#34; synonyms=\u0026#34;synonyms.txt\u0026#34; ignoreCase=\u0026#34;true\u0026#34; expand=\u0026#34;true\u0026#34; tokenizerFactory=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; **compositePOS=\u0026#34;compositePOS.txt\u0026#34; dictionaryDir=\u0026#34;dictionary/naist-chasen\u0026#34;**/\u0026amp;gt; ... SynonymFilterFactoryの設定にcompositePOS、dictionaryDirを追加します。 ここの設定は\u0026lt;tokenizer\u0026gt;タグで指定された設定と同じ物を指定します。以上で問題なく動作することになります。\nただし、この方法はSolrにパッチを当てなければいけません。 Solrにパッチを当てるのもなかなかな作業だと思います。 ということで、どうにかlucene-gosen側だけでも対応出来る形にしたいなぁと考えているところです。 残念ながら、まだ考えているだけですので、もう少し提供できるのは先になってしまいますが。。。 現時点では、次の方法を考え中です。\ninformメソッドを呼ぶフラグを追加して、どうにかしてinformメソッドを呼び出す SynonymFilterの修正版をlucene-gosenに内包して提供する できれば、a.にて対応できればと思っています。 最悪、b.の方法かと。 悩んでいる間にSolrの次のバージョンが出てしまわないように出来るだけ早く対応しようと思っています。 他にも問題点や気になる点があれば、日本語、英語を問わないので、気兼ねなくissueに上げてもらうか、Twitterで私宛にメンションしてもらえればと。 （あ、issue23へのパッチでもいいですよ！）\n追記： まだ、SOLR-2909のパッチを適用してからの確認はできていません。（ソース見て大丈夫だと思ってるレベル） あと、現時点での対応方法としては、「lucene-gosenとは別のjarにSynonymFilterFactoryなどを入れて提供」が妥当かなぁと考えているところです。（無理やりinformメソッド呼び出すのは骨が折れそう＋パッチが思いの外早く出て、導入されたのでlucene-gosen本体に特殊処理を入れるのはあまりメリットを感じない。）\n","date":1329756060,"dir":"post/2012/","id":"4e7b945feca199bd486653fea1d0e39c","lang":"ja","lastmod":1329756060,"permalink":"https://blog.johtani.info/blog/2012/02/21/lucene-gosen%E3%81%A8synonymfilter%E3%82%92%E5%88%A9%E7%94%A8%E3%81%99%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AE%E6%B3%A8%E6%84%8F%E7%82%B9%E5%95%8F%E9%A1%8C%E7%82%B9%E7%B7%A8/","publishdate":"2012-02-21T01:41:00+09:00","summary":"久々にlucene-gosenの話です。 しかも、あんまり嬉しくない話しです。 すでにissueをアップしていますが、lucene-gosenと","tags":["lucene-gosen"],"title":"lucene-gosenとSynonymFilterを利用するときの注意点（問題点編）(Jugemより移植)"},{"contents":"また、勉強会ログです、すみません。。。 直接業務とは関係ないのですが、今回はリクルートの中野さんが話しをされるというので顔を出してきました。 もちろん、内容も気になりましたというのもありますが。 実際には中野さんは2分くらいしか喋らなかったんですけどね。。。\n今回は、最初のセッションはちゃんとしたソースコードリーディングでした。 Hadoopの入力としてデータをHDFSじゃなくて、MongoDBから取得するときに利用するMultipleInputの実装をしてみたというお話でした。 MongoDBやHadoopを知らないと（私はあんまり知らない。。。）少しきつかったかもしれないです。 幸い、HadoopのMultipleInputについては以前、すこしだけ見たことがあったので、かろうじてついていけました。 最初の部分を聞きのがしてしまったので合っているか自信がないのですが、10genから出ているmongo-hadoopの使い勝手、効率の悪そうなところに手を入れた話しがベースになっているんでしょうか？（ツッコミあるとうれしいです） 気になったのは、MongoDBのデータをHadoopから直接取りに行くというユースケースがどういう場合に出てくるのかという点です。 ネットワークやMongoDBの負荷がHadoop処理へのボトルネックになるんじゃないかしらという懸念がありそうだなと。 発表を聞いていて感じたのは、やっぱりソース書いて動かさないとダメだよねぇ、自分も手を動かそうというところです。 リクルートさんの発表は波乱万丈（？）でした。 最後まで話しを聴いたあとに思った感想は「こんなに話して大丈夫なのかな？」「いろんな人を敵に回してない？」というものです。 実際に昨年の夏くらいからEMCの草薙さんも検証メンバーに入って、リクルート社内での活用シーンをベースにMapRの検証をいろんな項目でやられたようです。（ある程度の詳細は以下のメモ参照） で、最終的な結論はまだ出ていないのですが、最後に出てきた検討中の比較対象が某C社のCDH。 どちらかというとCDHの方に傾いてる感じに取れる終わり方で心配になりました。。。 会場が会場だからというのもあったのかなぁ？ mesosというキーワードが出てきたのが気になりました。単語だけは以前Twitterで流れてきたのを目にしてたのですが、どんなものかという概要がわかったのは収穫でした。 リクルートさんの資料はどこまで公開されるかわからないですが、もう一度見たい気がします。（mesosの部分だけでも公開して欲しい）\nということで、以下はいつもの自分用メモです。\n日時： 2012年2月8日（水） 19:00～21:30 （受付開始 18:40） 場所： 豊洲センタービルアネックス（NTTデータ、豊洲駅直通）\n◎日本OSS貢献者賞・奨励賞のご案内　@hamaken 日本OSS貢献者賞・奨励賞\n◎『オレオレMultipleInputを作る方法（仮）』@muddydixon さん http://www.slideshare.net/muddydixon/multipleinput\nhadoopからMongoDBを利用する方法を紹介 CDH3u2かu3で試しました。 10genからも出てるけど使いにくい？から作った？ MongoMultipleInputs.addInputPath で色々簡単に使えるようにしたかった。 絞り込みしてデータをMapperにとり込みたかったため。 ＝絞り込みできないと必要なデータ以外も取得できてしまいJSONのパース処理がオーバヘッドになるから。 com.mongodb.hadoop.input.DelegatingInputFormat mongodbの環境にあわせて多くのsplitを生成する。 mongosへのアクセスはメタ情報の取り出しだけ。 あとは、個々のサーバにアクセスしてるのでデータ取り出しが高速？ ◎『MapRってどうよ？ - 実際に使ってみた感触を紹介します』 - リクルート 中野さん、高林さん、大坪さん\nMapRの説明資料がなかったので、EMCの草薙さんが出てきて説明を開始。 Greenplum MRはMapRテクノロジが開発した実装のOEM版。 EMCは特に手を加えず。 ※MapRについては前回のMapR勉強会の記事を御覧くださいな。 Q：JavaのAPI互換と言われている部分はHadoopのどのバージョン？ A：CDH3u2に近いパッチが当たってるらしい。 Q：DFSIO性能の比較対象のHadoopはどのバージョン？ A：手元に資料は残念ながらないです。 ここからリクルートさん。 検証内容：性能検証 中古車サイトで利用されている3つのHiveに置き換えてみた。 結果（パーティション圧縮） MapRのほうが約1.3倍高速に（そこまで速くならなかった？） 結果（非パーティション圧縮） MapRのほうが約1.7倍高速に（そこまで速くならなかった？） ビルドイン圧縮はGzip圧縮と比較して高速 ※チューニング次第では結果変わるかもね。 機能検証：マルチテナント検証 目的： 複数ユーザに対して1つのクラスタを提供する セキュリティの担保（） 余剰リソースの有効活用 複数ユーザのJobの並列実行？ 結果１（ユーザ権限まわり） MapRのユーザはLinuxユーザに準拠。 同じmaprユーザでもUIDがずれてるとエラーが起きる。 MapR内のPermissionは内部のクラスタ、ボリュームの権限定義が可能 ※Volumeは管理者に付加的な情報を与えるような存在 Job実行はHadoopと一緒のアクセス権。 結果２（FairScheduler） MapRではデフォルトとなっている。 複数テナントからの同時ジョブ実行の動作を確認。 poolをベースにタスクを割り当ててく。 min/max値にあわせてslotが利用される模様 結果３（Load処理（Hive）、Job実行（HiveのSelect）） じゃらんPVデータ１ヶ月分をロード。 NFS→MFS 結果４（フェイルオーバー） HA機能 ノード切り替え時間、タスクの復旧までの時間とか。 結果５（DirectNFSでの転送） NFSGatewayをクライアント側にした場合との違いなど。 クライアント側に載せた場合、通信量が減るから速度が出てる。 Mesos概要 Apache IncubatorのOSS。C++により実装 効率的なリソース分離、リソース共有機能を提供するクラスタマネージャ。 Mesosでの検証 マルチテナント（ユーザ権限）硬い。 リソース制限ができない。などなど。 MapRとMesosの比較 資料期待！ リクルートとしてのMapRの評価 保守/サポート/教育が充実してるのが重要。速度だけじゃない。 けど、まだ検討中です。 Q：クラスタに対するパーミッションの権限情報はどこで管理されてるの？ どこが落ちたときにそのパーミッションの情報がとれなくなる？ A：CLDBで管理されてます。 Q：CLDB内部でのデータはバイナリ？DBを別途持ってる？ A：HDFS上にボリュームが作られてそこに吐き出されてる。 Q：Jobのスケジュールの情報とかはどこに？ A：Job管理データはJobTracker用のボリュームに保存されてる。 それを別の人が引き継ぐ。 Q：ボリュームが壊れたら？ A：さすがに壊れたら引き継げない。 けど、壊れにくくしてあるのが売り？ Q：MapRのチューニングのポイントはどんなものがあるの？ A：チューニングに関しては256Mのchunkサイズを64Mに減らした場合の化粧しかしてない。Apache Hadoopの方は若干チューニングした。 Q：DFSのシリアライズは？ボンディングとかでもできるんじゃないの？ A：そこはやってないのでやってみます。 Q：MapRでの8台構成で全部のせてみた場合、CLDBのリソースはどのくらいもっていってるの？ A：結構使ってる。CLDBを3台以上にしたらサポート対象外。 Q：CLDBを3台に制限してる理由は？ A：わからない。 Q：本番MapR、検証CDHというのはあり？ A：M3を開発環境で利用して欲しいですね。（ステマ？）開発目的だとM5を無償提供してほしいなー（EMCへのお願い？） Q：Pigの検証は？ A：リクルートではHiveを利用してたので検証してない。 次回は3月ころかなぁ？だそうです。 ","date":1328716980,"dir":"post/2012/","id":"fa16213d24273d386d22332cd01ce774","lang":"ja","lastmod":1328716980,"permalink":"https://blog.johtani.info/blog/2012/02/09/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/","publishdate":"2012-02-09T01:03:00+09:00","summary":"また、勉強会ログです、すみません。。。 直接業務とは関係ないのですが、今回はリクルートの中野さんが話しをされるというので顔を出してきました。 も","tags":["勉強会"],"title":"Hadoopソースコードリーディング第8回に参加しました。#hadoopreading(Jugemより移植)"},{"contents":"Fluentd meetup in Japanに参加しました。いつも面白そうな話を聞いてばっかりなので、役に立つためにスタッフとしても参加してみました。 まずは、会場が綺麗でびっくりしました。しかも電源タップまで用意されていてかなり充実してました。Ustはまだ見ていないのですが、Ustも録画までされていて素晴らしい運営メンバーでした。\n開発者の古橋さんほか、Treasure Data Inc.の方たち（太田さんはいなかった）が集まり、 Fluentdの仕組みから、プラグイン開発の方法、実際にプラグイン開発してしかも本番で利用してる実例まで 「パーフェクトFluentd」という本ががそのまま書けてしまうのではというくらい密度の濃い話が聞けました。 私個人は、いつものごとく興味を持ってるんだけど、仕事、私用では触っていないという腰抜けなので話についていくのが大変でしたが。。。 各セッションごとに、しっかりとしたQA時間が取られていて、質問者も質が高く、中の人や発表者の方も誠実に回答されている感じがすごく良かったです。 （残念ながらLTの時は懇親会の準備を手伝っていたので聞けてないです） 基本はログの中継サーバとして利用するという話でした。 個人的には性能系のデータやログ（遅いクエリのログに関するプラグインの話などもあった）をストレージに保存して、時間を軸にログとグラフを表示するとかいう仕組みに使うと面白いかもなぁと感じました。 今回はFluentdがメインなので、ログを集める部分の話が主だったところでしたが、懇親会直前の@doryokujinさんのスライドでも上がっていた集計後のビジュアライゼーションに関する部分のはなしも聞いてみたいなぁと思ってるところです。\nあとは、いくつか知りたかったことが。 Treasure Data Serviceというサービスをやってるみたいで、SQLライクな問い合わせやビジュアライゼーションされた画面があるみたいな話があがっていたんですが、画面が見てみたかったです。 また、@just_do_neetさんの構想図のその後を聞いてみたいですねぇ。\nそれにしても実例も構成から性能値まで上がっていたので、実際に利用する場合に参考になる資料だらけで普及にはずみがつきそうです。 Ust録画が上がっているようなので復習したいと思います。 （あ、内容とは関係ないけど、Ust録画にハッシュタグつきのツイートを時間軸で重ねて表示するサービスとか機能ってないのかな？）\nということで、以下はいつものメモ書きです。\n2012/02/04 12:30 ～ 19:00\nフューチャーアーキテクト セミナールーム\n参考URL：http://fluentd.org\n◎13:00～14:00 「What\u0026rsquo;s Fluentd? - The missing log collector」 http://www.slideshare.net/treasure-data/fluentd-meetup-in-japan-11410514 Treasure Data, Inc.　古橋 貞之 (@frsyuki)\nまずは、Fluentdの概要。syslogdみたいなもの Fileのtailで流すことが基本。 Clientライブラリから流すことも可能。 他との比較 ScribeとFluentd 構造化されたデータを扱う gemとかapt-get，yumでインストールあg可能 Rubyで書かれてるからカスタマイズもプラグインの追加も簡単。 FluentdとFlume FlumeはZKやマスタノードが必要＝セットアップが面倒 JVMだから面倒、設定も簡単。 Fluentdのアーキテクチャ Bufferプラグイン：スレッドセーフ、バッファ処理など Outputプラグイン：出力だけ out_forwardプラグイン：Cassandraと同じアルゴリズムでHeartBeatしてる out_copyプラグイン：同じ出力を別の出力先にコピー bof_fileプラグイン：バッファ先をファイルにする。Fluentdがこけても大丈夫 out_exec_filterプラグイン：外部プログラムからの入出力を使える in_tailプラグイン：ログのパーサーが内蔵されてるみたい。 開発者用API Unitテストフレームワーク（MRUnitに似てる） TailInput（パーサカスタマイズも簡単） ドキュメントとか http://fluentd.org にあります。 会社紹介！ Treasure Data Service Fluentdでは出力先がいろいろできるけど、自分で解析しないといけない ！ここで、Treasure Data Service（クラウド）に保存すると。。。 データのVisualizationとかがリアルタイムで出来る。 QA： Q：ログ転送にUDP使ってますか？ A：TCPです。UDPはハートビートに利用してます。 Q：文字コードはどういう扱い？ A：バイナリ形式であつかってます。 文字列で扱う場合はプラグインで対応しましょう。 Q：性能大丈夫？ A：Twitterで議論があがって、いろいろ対応しました。 Q：TreasureDataServiceはクラウド対応だけなの？ A：データはクラウド上で管理してるので上げても大丈夫なものだけが現在は対応。暗号化などは行なっている。 Q：TreasureDataServiceはどこで動いてる？ A：AWS上（S3にデータ保存） Q：解析プラットフォームを提供している？SQLだけ？ A：HiveのSQLで解析可能。Visualizationのツールもある。 Q：コンサルタントもあるの？ログ出力系とか。 A：あとから解析できるように。 Q：in_tailでログローテート（iノードが変わって）も大丈夫？　A：大丈夫。動かなかったら連絡ください。 Q：ファイルバッファリングされるデータの順序は保証される？ A：キュー形式なので、保証される。けど、S3とかだと出力先が遅いので、 パラレルモードで対応が可能。だけど、パラレルだと順序は保証されない。 Q：実際のシステムが投げるときにFluentd側で認証とかできる？ A：認証はないです。推奨は同一アプリサーバでFluentdを起動。 Q：Fluentd間のデータ通信のセキュリティ対応は？ A：今はない。プラグインとか作ればOK。 Q：中間層のFluentdを置くのは推奨？なしで直接ストレージ保存も可能？ A：柔軟な対応（送信先、バッファリングとか）が可能にできるように中間層を置くほうがいい。直接出すことも可能。 Q：TDAgentでのセットアップが推奨？gemは？ A：gemはOSS版でtrunkに近い。TDAgentはテストとかしっかりやってる。 バージョンの対応表はリリースノート見ないとわからない。 Q：Flumeのほうが優れているのは？ A：設定ファイルが一元管理ができる。大規模はFlumeのほうがいいかも ただし、includeでHTTPサーバ経由で設定ファイルを取得可能な機能あり。 Q：バッファサイズは指定可能？ A：可能。 Q：ストレージがずっと停止している場合にログがあふれるのを防ぎたい場合の対処法は？ A：セカンダリという機能がある。（ただし、対応できてないプラグインもある） Q：フェイルオーバーでローカルファイル出力とかはできる？ A：out_forwardは対応してる？ Q：Fluentdからのbuf_fileに出力してる部分で遅延、書き込み不可が発生したら？ A：入力と出力がスレッドで分かれてる。 入力スレッドでのエラーはinput_plugin側にException上がる ◎14:15～15:00 「Dive into Fluent Plugin」 http://www.slideshare.net/repeatedly/fluentd-meetup-dive-into-fluent-plugin Preferred Infrastructure, Inc.　Masahiro Nakagawa (@repeatedly)\n好きなプラグインとか言いましょう（発表者さん） MongoDBのプラグインをベースにプラグイン開発の説明 http://bit.ly/fluentd-with-mongo プラグイン名はfluent-plugin-xxxで統一されてます。 fluent-plugin-mongoがダウンロード数が1位に！ （scribeのプラグインがデイリーでテストが走ってダウンロード数が増えるという卑怯なカウント稼ぎしてたらしいｗ） fluentd.confの説明 fluentdの起動は以下のとおり。開発中は-vつけるといいよ fluentd -c fluentd.conf プラグインをどう作る？ Fluentdの構成図による説明 Cool.io、MessagePack、Rubyなど。 それぞれの説明を簡単に。 Cool.ioがファイル監視とかをやってくれるみたい。 プラグイン開発に関する詳細な説明 テスト、gem構成などを書いてくれてる。 QA： Q：複数行のログを扱うのはどこを作ればいい？tailプラグインの正規表現だとうまく行かなかった。 A：tailをoverrideしてparserLineを実装する。複数行のparserは難しいけどね Q：ログのアグリゲーションをやってみたいのだが、どう？CPU利用率とかを1分間バッファしてからアグリゲーションして平均出すとか。 A；fluent-plugin-aggregateってのがあって、forward-pluginを書き換えて作ってる。 TimeSlicedOutputでやると時間の期間指定とかが可能。 管理画面つくろうと思ってるので手伝ってください！@repeatedly Q：fluentd自体が処理した統計データの出力とかある？ A：古橋さんが頑張ります！協力して！=\u0026gt;@tagomoris先生が書いてる！ ◎15:15～16:00 「fluent を使った大規模ウェブサービスのロギング」 http://www.slideshare.net/hotchpotch/20120204fluent-logging COOKPAD, Inc.　舘野 祐一 (id:secondlife, @hotchpotch)\nCOOKPADでの基盤全般を見てる部署の人　PVログ＋MySQL 1日分はオンメモリにのるから高速。けど、1週間前とかになると遅くなる blackholeエンジン（MySQLの一部？）だと速い（ときどきおそくなる） データ保存でも問題 直近データしか保存できない。大きすぎて。 今後スケールしないときつくなる（1日分もメモリに載らなくなる可能性も出てくる） 他のログはMySQLへJSONでシリアライズして出力とかもしてた。 アプリでDBにログ出力はinsertのコストが厳しい。PVとかなら、1リクエスト＝1insertだけど、1リクエストで多数ログ出力とかが厳しい。 そこにFluentd登場！！！ 出力先が色々使える。（MySQL以外もOK） パフォーマンス バッファリング＋転送をやってくれるし、非同期で処理可能なのでレスポンスタイムへの影響が最小限にできてる。 安定性 プラグインはちょっと注意が必要。 バッファリングしてくれてるので、一時的に停止もできるのがうれしい。 6時間止めてもOKだったよ（テヘッｗ） 今後 PV系のログをMySQLから移行検討中 具体例！！ td-agentをrpmで入れてるし、Rubyまで入ってくれる。 構成管理はpuppetを利用してる。 td-agentの設定の注意点 「retry_limit 9」に変更してる。標準だと17なんだけど、2の16乗＝大体1日かかる。9だと大体10分くらい 中央転送用サーバ gitで設定ファイル管理してる。 よく変更するため。　gemfileで各種fluentd/pluginを利用してる。 自分たちで手を入れたソースを利用できるようにもしたいため。 テスト時にテストが書けるのが嬉しい（Rubyで出来てるアプリからもいじりやすいし、アプリのテストでも簡単に使える） ロガーへの実装追加もできる。 Tips バッファからすぐ処理させたい場合とかの説明 こんなのあったら嬉しいな。 設定ファイルの柔軟な設定記述方式 DSLにならないかなぁ（けど、やり過ぎも厳しいし。。。） ログの重要性 統計を考えられるエンジニアが重要。 どのデータにどんな価値があってそれを仕事（お金）に結び付けられるか？ QA： Q：障害対応のノウハウとか？ A：nagios、muninでサーバとか監視してる。 アラートチェックもしてる。 Fluentdの安定性は2ヶ月実際に導入してみて特に問題は出てない。 Q：MongoDBの構成は？ A：master/slave構成。PVログはS3に保存してEMRで処理。 Q：パフォーマンスの測定は？ A：40Mbit/sが処理できてたのは見てる。あとは、後ろの発表ですごいのがある！ Q：設定ミスの防止とかをどうやった？ A：今回はpuppetの設定後のリロードをチェックするような仕組みを入れた。 本来なら、データが流れてるかどうかのチェックを入れるプラグインを書いて欲しいｗ Q：データマイニングエンジニアの定義は？ A：データの価値を見いだせるエンジニア。あとは、きちんと統計学を学んできてるエンジニア。両方募集中！！ Q：DynamoDBは検討は？ A：西海岸でしか動かないのでデータ転送の時間がかかってしまった＋RESTで１件ずつ登録なので今回は見送った。スキーマレスなのでうまく使えそう。 A２（古橋さん）：バルクインポートがないので使いにくい。 Q：ログ出力の形式をFluentdにあわせて変更したとかありますか？ A：もともとアプリで出力してたから特に変更なかった。 ◎16:15～17:00　「fluentをサービスで使ってみた」 http://www.slideshare.net/naverjapan/20120204fluent-public NHN Japan株式会社　Tetsuya Ohira (@just_do_neet)\n自己紹介が面白かったｗ 実例の話。 事例１： 社内向けのログ解析に利用　Fluentd＋Hadoop データノードにFluentdで出力して、データノードからHDFSに書き込んでる。 事例２： NAVERまとめのまとめ作成者へのデータ解析 Fluentd＋Hadopo＋Azkaban Azkaban（個人的にはオススメできないｗ） flutendの負荷は全然上がってない。 監視 tcp portの監視 転送されたデータサイズのチェック。HDFS側のデータ量でチェックしてる。 なぜか半死半生の状態になった（よくわからない。） プラグインを自分で直せるので対応が楽。（Ruby力は必要だけど。） demo 準リアルタイム解析基盤の構成案（おもろそう） fluentd、MongoDB、Hadoop、Jubatus、node.js 地図にアクセス解析結果をのっけて見せる。（maptail.js？） 提案or相談： 動的に設定ファイルの内容を変更できるようにしたい log rotateのタイミングでshell実行でfluentd再起動 必要な情報だけrelayしたい フィルタープラグインみたいなものが書きたい。 fluentd自体のメトリクスを出して欲しい jubatusプラグインはー？ QA：　Q：log rotateへの対応はどーしてる？ A：今はログローテートのタイミングでfluentd再起動してる Q：Apps側のFluentdがコケたときにaccess_logをcopyしてるらしいけど、重複しないの？ A：失敗した対象のログをストレージから一旦廃棄して、再送してる。 Q：Rubyがそこまで得意じゃないのにFluentdを選んだ理由は？ A：他のモノが使いにくかった＋既存システムに手を入れなくて済む＋タイムリーだったという理由。 Q：構成案のデータの流れは？ A：MongoDB、Hadoopへは同一ログを流して、リアルタイムが重要な場合はMongoDB、大量データ回すのはHadoop？ ◎17:15～18:00 「Distributed message stream processing on fluentd」 http://www.slideshare.net/tagomoris/distributed-stream-processing-on-fluentd-fluentd NHN Japan株式会社 ウェブサービス本部　Tagomori Satoshi (@tagomoris)\nsed | grep | wc がメイン。 Hiveで集計してます。 なんでFluentd？（not Storm、Kafka or Flume?） Rubyが好き（ライブドアはJavaが入ってない環境もあるし） プラグインやTimeSlicedOutputがあるのも採用理由 ログ収集の構成図 ブログに別の勉強会の資料があるので見てください。 まだ１０日間しか動いてないので実績は少ない？ 127サーバからのログを流してる。 7万行/sec、ピーク120Mbpsが流れてる。 89 fluentd インスタンスが12ノード（4コアHT）で動いてる。 1行のログを1行のタブ区切りで出力する（Hiveでインポートしやすいから） Apacheのログに幾つか追加したデータなどが出力されてて、それをタブ区切りにするため設定一発では変換できない。 TimeSlicedOutputが重要 時刻単位でログ出力できないとキツイ（ログの流量が半端ないから） ログローテートでは時刻単位できちんと出力されてない。 ログから解析までの流れ図 以前は生ログをHadoopに書き出してたので25分くらいのタイムラグが出てしまっていた。（ノード数が少ないという理由もあるけど、お金的に増やしたくない）＋Hadoopで他のジョブが実行されてるとさらに遅くなる。。。 fluentd でログを流しながらコンバートもかけられ、Hadoopでのデータコンバートの処理遅延が少なくなってハッピーに！ ストリーミング処理の重要な点 バッチでもストリーミング処理でも同じことが可能。（out_exec_filterとHadoop Streaming） SPOFがないこと トポロジ、Fluentdの構成　ログエージェント（scribeline：お手製） pythonで書かれたscribelineというものを利用してる。 フェイルオーバーの処理（primary、secondary構成）が可能 fluentdは入れてない。（ログを拾い上げて流すだけには重い） workerノード serializerノードが必要なのは出力先の競合を減らす必要があるため。 出力先が大量のアクセスに向いてない場合があるから。 あと、ログの流れを元に監視したい項目にもここで対応可能。 watcherノード deliver、serializerからのデータを見ながら監視、統計処理を行える。 設定は自動生成してる。800行くらいになっちゃうから。 workerへの分散具合をよしなにしたいから。 remove_prefix 、add_prefixでデータの流れ先の交通整理してるのか。 GrowthForecastでグラフを出力してる。 https://github.com/kazeburo/GrowthForecast QA Q：大規模環境での移行はどうやったの？ A：もともと流すような仕組みはあって、流し先を変えたので それほど大変ではなかった。ただ、アプリ側で動いてた部分に手を入れたときは配備が大変だった。 Q：workerが1サーバ8の理由は？ A：4コアHT＝8というので8としている。 Q：deliverのカーネルパラメータをいじってたりしない？ A：ライブドア標準の設定がされてる。CentOSのデフォルトでもそれほどきびしくないかな？ Q：deliverノードでラウンドロビン＋out_forwardになってる理由は？out_forwardだけじゃだめ？ A：バッファのタイミングでの切り替えだと溢れてしまうので、最大でも1秒でラウンドロビンしてworkerを切り替える必要がある。 ※懇親会設営の手伝いのためあんまり聞けず。 ◎18:15～19:00(Plugin紹介LT)(各10分)　@shun0102: 「fluent-plugin-dstatを使ったリアルタイムクラスタモニタリング」 http://www.slideshare.net/shun0102/fluent-plugindstat\n@ixixi: 「fluent-plugin-couch」 http://www.slideshare.net/ixixi/fluent-plugins-for-couchdbamazon-sqssns\n@chobi_e: 「Fluentd \u0026amp; PHP」 http://www.slideshare.net/shuheitanuma/fluentd-and-php\n@railute:「Fluent Output Plugin for Cassandra」 https://skydrive.live.com/view.aspx?cid=D105615A0F594518\u0026amp;resid=D105615A0F594518%21333\n","date":1328367780,"dir":"post/2012/","id":"a2679a7d860a0bfb2645809ed92ce138","lang":"ja","lastmod":1328367780,"permalink":"https://blog.johtani.info/blog/2012/02/05/fluentd-meetup-japan%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-02-05T00:03:00+09:00","summary":"Fluentd meetup in Japanに参加しました。いつも面白そうな話を聞いてばっかりなので、役に立つためにスタッフとしても参加してみました。 まずは、会場が綺麗","tags":["勉強会"],"title":"Fluentd Meetup Japanに参加しました。(Jugemより移植)"},{"contents":"昨年末に今年の抱負について書いたのですが、 他にも興味あるものが増えたので備忘録＆公約？を兼ねてブログに書いておきます。 （興味あるものがあれば、シェアしたりできると楽しいので、ツイート、コメント待ってます。）\nZooKeeper SolrCloud SenseiDB Lucene 検索システムのアジャイル開発？ まずは、ZooKeeper。このなんとも言えないアイコンでお馴染みのヤツです。 こんな顔してますが（顔関係ない。。。）、いろんな所に出没します。 Katta、Lilly、SolrCloudにも出てくるんです。SenseiDBにも出てくるんです。分散処理にことごとく絡んできます。 で、これは、知っとかないとまずそうだと。\nSolrCloud。まぁ、妥当です。一応、Solrな人なんで。 昨年、NewSolrDesignを訳してみてもいます。訳しただけでほったらかし。。。 elasticsearchとかSenseiDBとかSolrに似たLuceneを利用している検索サーバがチラホラ話題になってます。 できれば、このあたりの分散の仕組みを比較しながら調べたいなと思ってみたり。 すべてをカバーするのはキツイので、SolrCloudかSenseiDBあたりを調べていきたいなぁと。\nで、SenseiDBです。先日、Publickeyで記事が出て飛びつきました。 Zookeeper使ってるし、分散だし、全文インデックスにLucene使ってるし。 なんだか興味あること、全部入りな感じです。\nLuceneも興味津津です。 Solrがコアとして使ってますし、昨年、Solrと同時にリリースされるようになりました。 Luceneも奥が深く、時々、Solr調べててLuceneのソースも見るのですが、本格的に全体像を把握したりは残念ながらできていません。 そのくせ、Zookeeper同様、いろんな所に出没するんです、これが。 ということで、足元を固めるためにもLuceneに入門しないとなぁと。\nで、最後に検索システムのアジャイル開発です。 lucene-gosenのコミッターをやらせてもらってたり、Solrに絡んだ仕事もしてますが、長期にわたってフィードバックをもらいながら検索システムを育てていくというのが最近興味が出てきてることです。 検索システムは作ったらおしまいとは行かないのが厄介なところです。 データは増加しますし、検索されるキーワードも変わってきます。 また、検索される方法も変わってきたりもします。 ユーザが検索したいものも変化があります。 思ったように検索にヒットしない場合とユーザが離れて行ってしまいますし、検索しにくい場合も同様です。 今日、クックパッドの方の話しを聞いて思い出した次第です。（前に、Solr勉強会でも同じ話しをされて、同じ思いに至ったのですが、いかんせん忘れやすくてｗ） また、ログ解析の話などをTwitterで見てることもあり、検索という側面でのログ解析ってのも重要だよなぁと。 いくつか思いつくこともあるのですが、実践出来る場も限られてます。 色々と話しをする場を設けるのも面白いかもなぁと妄想してる次第です。\n取り留めもなく、現時点で気になってることを書きだして見ました。 また、数ヶ月したら気が変わってるかもしれないですが、とりあえず書き残してみます。 興味がある方がいらっしゃったら声をかけてもらえるとうれしいですね。\n","date":1327596641,"dir":"post/2012/","id":"58e83fb33c120db338132d23b9112805","lang":"ja","lastmod":1327596641,"permalink":"https://blog.johtani.info/blog/2012/01/27/%E4%BB%8A%E8%88%88%E5%91%B3%E3%81%8C%E3%81%82%E3%82%8B%E3%81%93%E3%81%A8/","publishdate":"2012-01-27T01:50:41+09:00","summary":"昨年末に今年の抱負について書いたのですが、 他にも興味あるものが増えたので備忘録＆公約？を兼ねてブログに書いておきます。 （興味あるものがあれば","tags":["備忘録"],"title":"今興味があること(Jugemより移植)"},{"contents":"ということで、いつものように勉強会に参加したメモです。\nhttp://atnd.org/events/23608 日時 :2012/01/26 19:00 to 22:00 会場 :アカデミーヒルズ(六本木ヒルズ内) 49階（タワーホールA） （港区六本木6-10-1） ハッシュタグ :#mnlgy\n■タイムテーブル 司会：CROOZLabs株式会社 研究所 所長 代表取締役社長　小俣 泰明 モーションノロジーの説明があったけど、他のことしてました。すんません。 1. 発表者: 有限会社未来検索ブラジル　森 大二郎 概要：groongaの索引構築の実装 全文検索とは。歴史から 1971：full-text。。。というキーワードが。 現代の全文検索の課題はあんまり変わってない 全文検索の手法 いくつかあるけど、転置索引の説明だけ。groongaも転置索引 groongaはインデックスの動的構築が得意 静的構築も考慮してます。 2. 発表者：CROOZ株式会社　長谷川 博紀 概要：MeCabからの脱出？(仮 CROOZ MALLの解説 MySQLとMeCabでやってます。 Tritonnつかってるのか？ groongaとの性能比較検証やってみました。 MeCabが問題じゃなくて、辞書ありの形態素解析が問題。 辞書にない単語もうまく検索したい 辞書に単語登録したら形態素やり直し ソート用のデータが。。。（ここはわからなかった） QA Q：MeCabの代わりとなっているものは？ A：MeCabを改善してみる？ 3. 発表者 : グリー株式会社　一井 崇 概要：全文検索のちょっとちがった使い方（仮） グリーでの数値指標管理 事前集計してKVSに登録してみてみる 1億パターンのキーが存在する。。。 キーがわからなくなる問題とか事前集計できてる？とか迷子になる。 キーも全文検索に入れてみては？ 「富士山の標高は何メートル？」とかでデータが取れる。 構造化されたキーをkey stringとして全文検索する。 構造化Keyに対応したKVSがあればいいんだけど。 データストアとしての全文検索もいいのでは。 4. 発表者：株式会社クリアコード　須藤 功平 概要：rroongaによる検索サービスの実装 groongaとRubyの組み合わせでrroonga。Rubyによるインタフェース？ groongaとのつながり部分をRubyで書いたライブラリ 多段ドリルダウン機能 絞り込みによる検索結果の比較とかに利用可能 メタデータ抽出にドリルダウンが便利 例：番組説明から出演者を抽出 サジェスト機能もある コンテンツベース すぐできる。候補の精度がいい 統計情報ベース 元データがある程度必要 候補が増えるけど、精度の問題あり 5. 発表者: 株式会社ぐるなび　塩畑 公一 概要: groongaの位置情報検索関連について。 2010年4月からgroongaを利用し始めた レストラン検索、地図検索など 円形、矩形の緯度経度検索が可能。 距離算出もやってる。ソートとか用かな。 球面近似もやってる。 geoの検索速度についてパフォーマンステストしました。 Q：近似手法をいくつもサポートされてるけど必要？ A：距離計算を正確にしないと不利になるお店が出てきちゃうから 6. 発表者: クックパッド株式会社 兼山 元太 概要: Solrを使ったレシピ検索のプロトタイピング クックパッドとは？ 女性多いよ AWS上でRubyで組んであるよ プロトタイピングって？ ユーザの問題を発見してから、プロトタイピング 本番デプロイ（一部ユーザに公開） 問題を抱えているユーザーに向けてそれぞれ数十のバージョンが動いている インタビューとかしてフィードバック受ける。 本番の検索エンジンのフィールドをいっぱい追加 Solrの紹介（MySQL（Tritonn）から移植しました） ダイナミックフィールドやレプリケーションの話。 JSON型でHTTP経由で検索できるのが便利。 Solr本の紹介して頂きました！あざっす！ 気になってるSolrの新機能 not to cache SurroundQuery BloomFilter Q：全部AWS？ A：全部AWSに移行しました。 とまぁ、参加してきました。 初六本木ヒルズで、おしゃれな場所、雰囲気にやられてしまって、あんまりちゃんと聞けてないところがありますが。。。 メモを取りましたので。参考までに。 groongaについては勉強不足のため、いまいちついていけませんでした。 ちょっと英語の記事を読んでいたのもありまして。（内職良くない。。。） MeCabに関する発表に興味があり、勝手にMeCabの代わりorMeCabよりいいものを使ってます！みたいな発表かと想像していました。（ちょっと違ったみたい、妄想は良くないですね。。。）\nグリーの方の発表は興味深かったです。ログ解析とかにも確かに全文検索の技術使えるし。 検討が進んだ次の話も聞いてみたいです groongaの位置情報の話やrroongaでのgroongaの色々な機能のはなしも出てきてgroongaの理解もちょっと進んだのはありがたかったです。\n最後のクックパッドさんの話は、今回もわかりやすくて面白かったです。 検索を成長させていくという姿勢と、実際にどんな形でそれを実施されているかが楽しそうに話されててとても羨ましかったです。 次はSolrで困ってる点とか、検索のログとか利用され方をどのように解析してるのかといった話も聞きたいですね。\nどうしてもSolrに思い入れがあるので、感想が偏ってるかもしれません、すみません。 気になる点やいや、こうなんだよ！ってツッコミがあれば、ぜひコメントやTweetしてもらえるとありがたいです。\n","date":1327593155,"dir":"post/2012/","id":"c6dc6e6567d673436ac41ebc8e79a9ec","lang":"ja","lastmod":1327593155,"permalink":"https://blog.johtani.info/blog/2012/01/27/%E3%83%A2%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%8E%E3%83%AD%E3%82%B8%E3%83%BC2012-1%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-01-27T00:52:35+09:00","summary":"ということで、いつものように勉強会に参加したメモです。 http://atnd.org/events/23608 日時 :2012/01/26 19:00 to 22:00 会場 :アカデミーヒルズ(六本木ヒルズ内) 49階（タワーホールA） （港区六","tags":["勉強会"],"title":"モーショノロジー2012#1に参加しました。(Jugemより移植)"},{"contents":"日時：2012/01/19 18:30-20:30 場所：ベルサール三田Room2シアター\nInside MapR デモ＋内部のお話。 ・自己紹介 Susheel Kaushik 元YahooのHadoop系の人。製品担当責任者。 草薙さん 3台のベアボーンでMapRが動いてるデモが開始。 クラスタ管理画面の説明。 なぜか、NFSのサービスが1台落ちてますがｗ MapReduceなんかの実行結果なども出てくるのか。 ボリューム管理も画面から操作 レプリケーション、スナップショットも管理画面で操作、動作確認できますよ。 ミラー先はリードオンリーでボリュームの同期が可能。 スナップショットによりMapRのクラスタ内部にバックアップが保持可能。 NFSのHA構成可能。VIPの機能などもあるよ。 事前定義された各種Alertの発行も可能。 JobTrackerもMapRで拡張された表示がある。 例：MapTaskPrefetchCapacity：次のジョブのMapperを起動する準備可能な仕組み MapR内で独自に出力してる測定値をGangliaで見ることができるよ。 MapRはHadoopの置き換えとなる製品。 HDFS部分を重点的に性能アップさせるために主に置き換えた製品。 MapReduce部分にも手を入れてる。例：Direct Shuffle（HTTPじゃなくて、RPCでShuffleの通信を行ってるとか）ボリューム活用してるらしい。 分散NameNode、JavaGCの影響の排除、ビルトイン圧縮によるI/O削減など。 Mapperの出力をHDFSに置くと、メタデータ更新が多くなり、NameNodeがパンクする。（Apache Hadoop） Q：中間データもレプリケーションすると性能劣化しないんですか？ A：中間データボリュームは特定ノードしか保持されない（＝レプリカ数は１） ストレージプール（SP） ソフトウェアでストライピング。RAIDしなくてよい。 コンテナ（データ、ネームがある。） データブロックをグループ化したもの ※ストレージプールの数と同数のボリュームを作成すべき。 CLDBがコンテナを管理してる。 Q：トランザクション失敗するのは？ A：どこかにかければトランザクションは成功。 コンテナが復旧してきたら、データがコピーされる。復旧されない場合は別途コンテナを割り当てることもある？ Q：ノードが追加される場合の挙動は？ A：。。。聞き逃した。 トポロジ ノードを階層的にグループ化してデータ配置をコントロール。 Q：トポロジ設定などの権限設定は？ A：Permission画面があるよ。 Q：ボリューム単位のファイルシステムアクセスに関する設定は？ A：？？？聞き逃した？ ボリューム いろいろな設定が可能。 スナップショット Copy-on-Write方式による差分格納 ミラー ソースからミラーにコピー。手動orスケジュールによる起動が必要。 ミラー側はRead-only ※誤解を招きやすいので注意 読み出しが多い場合にミラーを利用することで対応が可能。 ビルトイン圧縮 LZZFの一種を高速化してる ネットワークIOにも効いてくる JobTracker HA 最大３ノードで構成可能。アクティブスタンバイ NFS HA すべてのノードで稼働可能。 NFS機能 NFSv3相当 クライアント側にNFSサービスをインストールするという構成も可能に。 Q：NFSマウントして作成したファイルもブロックサイズ分のファイルサイズになるの？ A：8Kバイト単位で内部的にはファイルを作成してる。8KB単位で圧縮して管理してるので、小さいサイズでもいい。（アロケーションサイズが8KB） Q：8KBにしてしまったために大きなブロックサイズの利点がなくなるのでは？ A：オーバーヘッド内容な構成になってる。シーケンシャルに8KBに並んでるから？ Q：NFSによるとMapReduceによるアクセスの排他制御とかは？ A：独自で頑張らないといけない。Job起動時に効果的にスナップショット取ったりはしてない。 リバランスもバックグラウンドで実行可能 Apache Hadoopが備えるJava APIは100%語幹 Q：なんで、HDFSをがりっと書き換えたの？ A：運用性も、ノード管理も。。。全部です。 なくなっても良いデータなら、別にHadoopでもいいですよね。 けど、基幹システムとかだと、信頼性が必要だし、運用の効率も必要だしいろいろ必要。 Q：実績が必要なんですが、どのような試験を行われているのかという情報が公開される？EMCでやられてるテストのプロセスを適用しているなどの裏付けは公開されないの？ A：内部で6ヶ月利用してデータロスはない。 品質については強化していく。 Q：MapRとしてHadoopコミュニティへの還元していく内容ってどんなもの？ A：Apacheコミュニティに対して1000台のクラスタを提供してスケーラビリティテストとかやってくださいとしている。 Q：このクラスタを実際にはどう使ってもらうの？ A：品質アップするためにテスト環境として使ってもらう？ Q：ApacheのAPIの互換性を死守するのが必ずしもいいとは思えない場合にどうするの？MapR独自APIとかは出さないの？ A：ApacheのAPIに準拠するのは非常に重要。他のHadoop上のアプリが動作しなくなるから。 Q：MapRを容量の大きなファイルシステムとしてだけ利用するなんて想定はありますか？MapReduceを利用しないパターンです。 A：いや、それはｗ Q：MapRはエンタープライズがターゲットだけど、Amazonはパブリッククラウドが対象。マルチテナントなパブリックサービスでMapRを利用するとかは？ A：。。。 Q：ジョブ管理にも手を入れてるの？ A：あんまり手を入れてません。 Q：EMCのストレージ製品でMapRのMapReduceない版みたいの出てない？ A：中身はMapRじゃないですよ。 想定とは異なり、日本の草薙さんが主に説明されたのですごくわかりやすかったです。 しかもかなり内部まで理解されている方だったので突っ込んだ質問にもきちんと回答されてるので更に理解が進みました。 今回利用された資料は現時点では公開の予定はないという話でした。 ただ、かなりまとまってる資料なので、後悔して欲しいものです。 普通にviとかしてるだけなのに、すごいと思うデモってなんか新鮮でした。 MapR自体を触る機会はまだまだないと思うのですが、MapRとしてHadoopに対する思想が垣間見えたのが面白かったです。 すごいメンツが質問を投げまくるのでいろいろな側面で話が聞けました。 ただ、やっぱり英語のヒアリングがダメダメだというのが露呈しました。。。今年は少し頑張らないと、先が思いやられますね。。。 あと、疑問と言うか、感想ですが、MapR自体が結構多機能で、その機能をどう扱うか、どのようなノード構成やボリューム構成を取るかといった設計が結構大事でしかも大変なんじゃないかなぁという印象を受けました。 特にマルチテナントで利用する場合などは、想定されないミラーの利用などでデータ容量が足りなくなったりといった側面も出てくるのかなぁと。\n説明会のあと、Hadoopにあんまり絡んでないのに図々しくも飲み会にまで参加してきました。 これまた濃いメンバーだったので話についていくのも大変でしたが、面白い話が聞けました。やっぱり懇親会重要ですよねぇ。\n事前にこのブログを読んでいたので話しを聞くのが楽でした。 MapR勉強するために必須のページです。（どうやら今日説明した人がかいてるきがしますが。。。）\n追記： トゥギャってくれた人に感謝。 ","date":1326988680,"dir":"post/2012/","id":"7198e10ebcf1bb88dc479b5c5b9f2c15","lang":"ja","lastmod":1326988680,"permalink":"https://blog.johtani.info/blog/2012/01/20/mapr%E4%B8%AD%E8%BA%AB%E8%AA%AC%E6%98%8E%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-01-20T00:58:00+09:00","summary":"日時：2012/01/19 18:30-20:30 場所：ベルサール三田Room2シアター Inside MapR デモ＋内部のお話。 ・自己紹介 Susheel Kaushik 元YahooのHadoop系の人。製品","tags":["勉強会"],"title":"MapR中身説明会に参加しました。(Jugemより移植)"},{"contents":"お久しぶりです。インフルエンザで一家全滅という最悪の状況に陥っていた我が家でした。 流行してるみたいなのでみなさんも気をつけてください。\nさて、そんな中、OSSAJのミニセミナーでSolrについて簡単に話しをしてきました。 人生初Ustだったのですが、ぶっ倒れている中作成した資料だったためなんとも情けない発表だった気がします。（言い訳カッコ悪いですね。。。） 関係者の皆様、申し訳ございませんでした。\n内容としては、Solrの機能を簡単に紹介する程度の資料となっています。デモなどもないのでスライドだけ見てもなんだこれという感じかもしれませんが。\nということで、恥ずかしながら、録画もされているようなので、後で見て反省しようと思います。。。\n[オープンソースソフトウェア検索サーバ Solr入門](http://www.slideshare.net/JunOhtani/solr-11146713)** View more [presentations](http://www.slideshare.net/) from [Jun Ohtani](http://www.slideshare.net/JunOhtani) ","date":1326941184,"dir":"post/2012/","id":"a4462529ab493676987d946019a14945","lang":"ja","lastmod":1326941184,"permalink":"https://blog.johtani.info/blog/2012/01/19/ossaj%E3%81%AE%E3%83%9F%E3%83%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%A7%E8%A9%B1%E3%81%97%E3%82%92%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-01-19T11:46:24+09:00","summary":"お久しぶりです。インフルエンザで一家全滅という最悪の状況に陥っていた我が家でした。 流行してるみたいなのでみなさんも気をつけてください。 さて、","tags":["勉強会"],"title":"OSSAJのミニセミナーで話しをしてきました(Jugemより移植)"},{"contents":"先日のSolr勉強会でLucene/Solr4.x系のlucene-gosenについて質問を受けていたのを忘れないように（年越しちゃいました、すみません。）先週金曜日（1/6）にissueに登録しました。 まずは忘れないようにと思って、登録だけして3連休に突入したのですが、Robertさんが1/7に対応してくれました。 Lucene/Solr 4.x系では3.x系とはパッケージやメソッドが変更されるなど少し異なる部分があります。 lucene-gosenでは、プロジェクトのページにもあるとおり、4.x系にも対応しています。 ただ、この4x系に対応したブランチが、2011年5月から放置されていました。\nということで、Lucene/Solr 4.0系でlucene-gosenを利用されている方、これから利用される方は、この4x系に対応したブランチを利用してください。 なお、このブランチにはLucene/Solrのtrunk (r1228509)のSNAPSHOT版のjarファイルが利用されています。\n今後はlucene-gosen側でバグ修正や機能追加を行った場合にも4xブランチを更新していく予定です。 ※ただし、Lucene/Solr 4.0が正式リリースされていないため、頻繁にSNAPSHOTのjarファイルを入れ替えることはこなわないと思います。\n","date":1326033660,"dir":"post/2012/","id":"f7df7b85af230b2623d3a827b0cbddd2","lang":"ja","lastmod":1326033660,"permalink":"https://blog.johtani.info/blog/2012/01/08/lucene-gosen%E3%81%AElucene-solr4-0%E5%AF%BE%E5%BF%9C%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%9B%B4%E6%96%B0/","publishdate":"2012-01-08T23:41:00+09:00","summary":"先日のSolr勉強会でLucene/Solr4.x系のlucene-gosenについて質問を受けていたのを忘れないように（年越しちゃいました","tags":["lucene-gosen"],"title":"lucene-gosenのLucene/Solr4.0対応ブランチ更新(Jugemより移植)"},{"contents":"あけましておめでとうございます。（もう5日ですが。。。） 今年もlucene-gosenを中心に色々と記事を書いていきますので、ツッコミ、コメント待ってます。\nたまには会社のブログを書かないとイカンということで、会社のブログにNearRealTime検索についての記事をアップしました。 読んでやってください。\nということで、今年もいろんな勉強会に出没しますので、よろしくお願い致します。\n","date":1325735817,"dir":"post/2012/","id":"cc573488dec311655890a205aad4fb65","lang":"ja","lastmod":1325735817,"permalink":"https://blog.johtani.info/blog/2012/01/05/%E3%81%82%E3%81%91%E3%81%BE%E3%81%97%E3%81%A6%E3%81%8A%E3%82%81%E3%81%A7%E3%81%A8%E3%81%86%E3%81%94%E3%81%96%E3%81%84%E3%81%BE%E3%81%99%E4%BC%9A%E7%A4%BE%E3%81%AE%E3%83%96%E3%83%AD%E3%82%B0%E6%9B%B4%E6%96%B0/","publishdate":"2012-01-05T12:56:57+09:00","summary":"あけましておめでとうございます。（もう5日ですが。。。） 今年もlucene-gosenを中心に色々と記事を書いていきますので、ツッコミ、コメ","tags":["misc"],"title":"あけましておめでとうございます＋会社のブログ更新(Jugemより移植)"},{"contents":"他の方たちよりひと足はやいですが、今年の仕事が終わりました。 せっかくブログを始めたので、振り返りと来年の抱負など書いてみようかなと。\n今年の振り返り まずは、今年1年を振り返ってみます。 今年の出来事はこんな感じでした。\n3月に仕事が一区切り lucene-gosenに参加 ブログを始める 色々な勉強会に参加 Twitterでつぶやきまくり Mac Book Airの購入 PSVita買いました 3月に一昨年から参加していた仕事が一区切りつきました。 もう少し色々とやり残した感がある中で区切りがついたのが少し心残りでした。 あと、3月は震災もあり、色々と大変でした。ただ、自分の中では震災の記憶が少し薄れつつあるのが気がかりです。 良くも悪くも忘れて行ってしまうのだなと。今でも頑張っている方々もいるので、少しでも心に留めておきたいものです。\n個人的に一番大きな今年の変化は「lucene-gosenへの参加」です。 関口さんとここ数年ずっと仕事をご一緒させていただいていることもあり、コミッターとして参加させてもらうことが出来ました。 英語が苦手な中、Robertさんへ自己紹介のメールを書いたり、Issueを英語で書いたりと苦労もしていますが、OSSに参加できることがとても楽しいです。 また、使っていただいている方たちからのフィードバックもいただけているのがすごく励みになります。 やはり、OSSは使ってもらってさらに良いものになっていくのかなぁという感想です。 ただ、自分の腰が重いため、なかなか対応が遅かったりといったところもあるなと反省するところも。\n勉強会にも色々と参加しました。Solr勉強会を始めとして、かねてより興味があるHadoopのカンファレンスやソースコードリーディング。MongoDBの勉強会やDSIRNLPといった少し研究よりの勉強会にも参加しました。 Solr勉強会に参加してきた経験もあり、他の勉強会にも気負わずに参加できたので本当にSolr勉強会には感謝しています。 おかげで、社外のいろいろな方と話ができ、様々な刺激をうけることが出来ました。\n勉強会以外にもTwitterで色々な方に絡みまくったのもまた社外の方とのつながりが出来るいい機会でした。 Twitter依存症じゃないかというくらい、つぶやいたり、人に絡んだりしてます。。。（迷惑だったら言ってください。） お陰で@doryokujinさんや@wyukawaさんが主催してくれたログ解析の飲み会に誘ってもらえたり、@nobu_kさんや@ IjokarumawakさんにSolr勉強会で講演してもらえたりしました。 あと、Twitterを通じて勉強会やHadoop関連の情報、lucene-gosenへのフィードバックなどももらえていてかなり助かってます。 @yusukeyさんや@repeatedlyさんに遊んでもらってるのも楽しいですｗ\n最後の大きな変化はApple製品の購入でした。 これまでもブログで書いてきましたが、私は今年の中頃までアンチApple派でした。 それがここ半年足らずでAir、Mini、iPadと3つのApple製品に囲まれています。 Emacsのショートカットが使えるのが最大の要因ですが、何ごとも毛嫌いせずためしてみるのがいいなと思いましたね。 今では、Windowsで開発したくないくらいになってきています。\n2012年の抱負 さて、来年の抱負です。 今年いくつかチャレンジしようとして挫折してるものがあります。\nMongoDB触ってみる Scala触ってみる なんかWebサービス作ってみる（Amazonとかで） elasticsearch、IndexTankを調べてみる NewSolrCloudDesignを読み込んで自分なりにまとめる Junsaiに参加する 「7つの言語7つの世界」の続き 最初の3つはセットですかね。コップ本買ったり、NoSQLの本を買ったりしてるのですが、手付かずです。。。 電子書籍の検索サービスでもつくってみようと思いつつ、腰が重い状態です。 来年は余裕を見ながらちょっとずつやりたいですね。\nelasticsearchやIndexTankは仕事がらみです。 Solr入門を書いたこともあり、検索関連には興味があります。Solrだけでも2ヶ月おきに新バージョンがリリースされたり、4.0系でいろんな機能が実装されているのですが、それ以外にもOSSの検索サーバがいくつかあります。 気になってはいるものの英語が障壁でなかなか手を出して来ませんでした。 来年はSolr以外についてももう少し知識をつけていきたいです。 個人的ですが、分散処理にも少々興味を持っています。 慣れ親しんでいるSolrでもSolrCloudという壮大な計画が上がっていて、少しずつ実装もされています。 ブログでWikiページを翻訳してもみたのですが、翻訳に注力しすぎて理解ができていないです。 このあたりをもう少し理解しつつどのような実装がされているかも調べたいところです。\nJunsaiはSolr入門の著者である武田さんが最新のMeCab（今はMeCabが新しくなってしまったので、少し前のMeCabになってしまいました）をJavaに移植したプロジェクトです。 今年頭のSolr勉強会でお披露目があり、私も一応参画しているのですが、手が出せていない状態です。 lucene-gosenで少しは経験を積んできたので、その部分を生かしつつ、こちらももっと活性化させたいところです。 最後は夏ごろにやっていた「7つの言語7つの世界」の再開です。序盤で止まってしまっています。。。 新しい技術に触れる題材としてちょうどよいので、余裕をつくって続きを再開します。 なんか、抱負と言うよりも積み残しですね。。。 他にもTwitterで情報を仕入れるとやりたいことも変わってくるかもしれませんが、それも含めてブログに少しずつでも書きためていこうと思います。\n先ほども書きましたが、今年はTwitterを通じて色々な方たちと知り合いになれた一年でした。 ここには書ききれていませんが、フォローしてもらっている方々や勝手に絡んでも相手をしてくれている方々に感謝しています。 今後も絡みますのでよろしくお願いしますｗ あと、様々な勉強会に今後も顔を出していくので、かまってやってください。 いやぁ、色々書いたけど恥ずかしいですね。。。 まぁ、何事も経験なので、恥ずかしいと思いつつ今後も色々書いていきます。\n","date":1325006100,"dir":"post/2011/","id":"7164823f504286e3a762ee612ff0a988","lang":"ja","lastmod":1325006100,"permalink":"https://blog.johtani.info/blog/2011/12/28/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A0/","publishdate":"2011-12-28T02:15:00+09:00","summary":"他の方たちよりひと足はやいですが、今年の仕事が終わりました。 せっかくブログを始めたので、振り返りと来年の抱負など書いてみようかなと。 今年の振","tags":["misc"],"title":"今年の振り返りと来年の抱負？(Jugemより移植)"},{"contents":"@yusukeyさんにサインをもらう目的で勉強会に参加してきました。前回もらいそびれたのでｗ 残念ながら、まだTwitter APIを触ってないし、利用したサービスも思いついてないんですが。。。 けど、勉強になりました。 といことで、いつものごとく、自分メモです。\n◎APIの基本と最新動向について @yusukey 資料：http://www.slideshare.net/yusukey/21twitter-api-api\n・検索APIについて http://search.twitter.com/search.json?q=*** %3Aは「:」 詳しくはリファレンスを買ってね。 ・ページ処理のベストプラクティス Pageじゃなくて、MaxIdを利用して取得すると１５００件以上のデータも取れるよ。 ・最近のTwitterAPIアップデートについて - ポケリファでの変更点 ストリーミングのエンドポイントがSSLのみに。（twitter4jは2.2.5以上） - ユーザ名が検索APIのスキーマに追加（１２月以降） - in_reply_toの追加（１２月以降） =\u0026gt;検索結果から会話を追える。 ・include_entitiesが追加 t.coの展開したリンクも取得可能。 けど、t.coリンクの飛び先はt.coリンクにしてね。パトロールとかしてるから。 ・本当にあった怖いt.co - URLのつもりじゃないのにリンクになる。 →仕様です - 日本語を含むURLがおかしくなる。 →少しずつ治ってきてる。 - リンク先のURLがわからない（クライアント依存） そのたいろいろ？ ◎Zusaarについて何か @knj77 資料：\n・特徴 - SNSアカウントでログイン トラブル抑制など - 事前決済可能。最小催行人数が決められて、払い戻しも可能。 ・利用例 旅行とか合宿に使う例がないんだけど、できるんじゃないかな？ ・イベントを依頼する機能 欲しいイベントを提案可能 http://www.zusaar.com/idea/ ・アーキテクチャ GAE/Java、Twitter4j、Yahoo APIのテキスト解析 ・SNS連携 TwitterのDMが送れない。他のSNSのアカウントが主催者とか。 なので、自分からDMが届く。 ・PayPal連携 小さいアプリほど相性がいい 固定費ゼロ、マイクロペイメント（１００円とか可能） 銀行口座の登録不要、返金可能。部分返金も可能。 ・トラブル - SNS側のエラーが適当 ステータスコードは信用できないｗ - PayPalの実装を３回変更 - GAE料金体系の変更 9$/month。追加料金はほとんど使ってない。Googleのアナウンスが下手。 - ブルーオーシャンのはずが... Q：Zusaarで返金できるポイントは？ A：主催者が主導（手動？）で返金可能。 Q：無料イベントで約束手形的に課金するのはできる？ A：やろうと思えば出来ます。ただ、システム的には１００円は手数料としてもらっている。 Q：新しいATNDに対抗意識はありますか？ A：ZusaarはCtoCをターゲットにしてる。ATNDはBtoCなので、補完できる関係だと思ってる。 Q：APIでTwitterIDとかで検索したいんですが。 A：対応予定あります。 Q：できればATNDのAPIと共通化してほしい。 A：追加してるだけのつもりです。 ◎グループに分かれて自己紹介 6人中、懇親会参加者が5人もいたｗ\n◎LT - OAuth Echoについて@tkawa 資料：http://www.slideshare.net/tkawa1/oauth-echo-20111221-10657954\ntwitpicで使ってる。 認証をServiceProviderに委譲する仕組み。 クライアントがOAuth登録してあれば、。。。 ・問題点 非公式仕様 OAuth1.0に基づいてて2.0では変わってそう。 ・Railsで実装してみたよ。 - GroovyとQuartzとTwitter4Jの甘い生活G @mike_neck 資料：\nベトナムから緊急来日らしい。 しかもむちゃぶりされたらしい。 - 認証なしで使えるAPIまとめ？@ts_3156 えごったーの作者で学生！\n- TDD (Twitter4J Driven Development) @sue445 資料：\nAZusaarの作者！ テストドリブンなはなし。 Twitter4Jを利用するときのTDDの簡単に実装できる仕組みの話。 ここにソースがあるのかな？ http:/github.com/sue445/twtrhack/ - 放射線を自動計測してTwitterにつぶやくimaocandeの紹介 @imaoca 松山の方。 とまぁ、APIの話だけでなく、実際にAPIを利用している方のサービスの話など色々と面白い話が聞けました。 厚かましくも懇親会にも参加して、そこでも今までのイベントとは違うクラスタの方たちの話が聞けたのが楽しかったです。 やはり、APIを利用して色々とやってみようと思っている方が多かったのでいつもと違う話が聞けたんですかね。 私自身はサービスを思いついたりしないタイプなので、いい刺激になりました。（まだ、特になにか作る気にはなってないですがｗ） ということで、次回も余力があれば参加したいなー。 ","date":1324485660,"dir":"post/2011/","id":"da67e2f049b5b6babcf7906b85653399","lang":"ja","lastmod":1324485660,"permalink":"https://blog.johtani.info/blog/2011/12/22/%E7%AC%AC2-1%E5%9B%9E-twitter-api-%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%9D%B1%E4%BA%AC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-22T01:41:00+09:00","summary":"@yusukeyさんにサインをもらう目的で勉強会に参加してきました。前回もらいそびれたのでｗ 残念ながら、まだTwitter APIを触ってない","tags":["勉強会"],"title":"第2.1回 Twitter API 勉強会 @東京に参加しました。(Jugemより移植)"},{"contents":"lucene-gosenの最新版（1.2.1）をリリースしました。\nプロジェクトページよりダウンロードが可能です。\n今回の修正では、特定文字列でメモリの使用量が爆発してしまうバグへの対処となっています。 1.2.1以前のバージョンを利用している場合は最新版を利用するようにしてください。\n","date":1324437339,"dir":"post/2011/","id":"584b2b145f362098fc5fc1e634d57de5","lang":"ja","lastmod":1324437339,"permalink":"https://blog.johtani.info/blog/2011/12/21/1-2-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-21T12:15:39+09:00","summary":"lucene-gosenの最新版（1.2.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、特定文字列で","tags":["lucene-gosen"],"title":"1.2.1リリースしました(Jugemより移植)"},{"contents":"いつものようにSolr勉強会に参加してきました。 皆勤賞を継続中です。（暇人というはなしも。。。） 今回は話しを聞きたいですねぇといったら、いやいや、話もしてくださいと言われてしまったので、 発表もしてきました。 発表資料はブログの最後に掲載してあります。\n日時：2011/12/19(月) 19:00～21:00 場所：Voyage Group 8階\n1.Fessについて N2SM菅谷さん 資料：http://www.slideshare.net/shinsuke/solr-fess\nマルチコアで構成されてる。 S2Robotでクロールしてますよ。 ※ごめんなさい、あまり聞けなかった。。。あとで資料を読んで質問します！ 2.lucene-gosenについて @johtani 発表しました。 3.ApacheConに参加しました @Ijokarumawak 資料：http://www.slideshare.net/KojiKawamura/apache-con-2011report\n日本-\u0026gt;カナダ-\u0026gt;ベルリン-\u0026gt;カナダ-\u0026gt;日本 50万円。。。 キーノート１： セキュアな開発について。 キーノート２： Hortonworksのコミュニティ運営大変だよねぇ、頑張るよという話。 キーノート３： 本題：Lucene 4.0の話：Simonさん ヨーロッパの方？ PostingsFormatの話。 Document内部の情報を使うためにどうする？ StoredField：あんまり効率よくないね。 FieldCache（on RAM）：インデックス作る動作の逆を行う。これも効率よくないね。 IndexDocValue：インデックス作成時に作られるので読み込み性能が１００倍！（DocValue） Document Writer Per Thread！ Automaton Query あいまい検索の処理に利用。 Solr Flair Solr同梱 Prism LucidImaginationが出してるJRubyのラッパー GitHubで公開されてるらしい。 Blacklight RoR 図書館むけのパッケージじゃなかったっけ？ VUFind PHP これも図書館向け？ TwigKit JSPのタグリブ おぉ。これ直接読んでるのかな？ Ajax Solr Ajax用 QA Q：TwigKit、Ajax Solrは直接Solrを呼んでるんですかね？ A：たぶん、そうですね。JSPのはSolrJかもしれないですが。 4.サフィックスアレイの話 @nobu_k 資料：http://www.slideshare.net/nobu_k/suffix-arraysolr\nSuffix Arrayの話 全文検索インデックスの話。 Suffix Array＝検索漏れがない。 Suffix＝接尾辞 RedBullがどの文書に入っているか！ SuffixArrayのメリット 検索漏れがない＝n-gramと同様 仕組み上n-gramよりも早くなるケースが多い。 長いクエリに対して速い THIS IS IT：全部ストップワード SuffixArrayのデメリット インデックス構築系 アルゴリズムが難しい。 メモリ上での構築はちょっとだけ楽（けど、簡単ではない） SAISなど。けど、これだとメモリがいっぱいないとキツイ HDDでの構築 ランダムアクセスを排除したアルゴリズムが必要（dc3,dc7） インデックス更新、差分更新できない。 頑張って１台100GB/day Sedueでは？ SA＆インメモリn-gramのハイブリッド 更新分はn-gramに 検索時にはn-gram＋SAの内容をマージして出力 検索 二分探索はHDDとは相性が悪い。 メモリ上で検索できればOKだけど、サイズが大きいからきびしい。 圧縮接尾辞配列なら可能だけど、低速。。。 SSDだとはやいよ！ SSD対応のクラウドはまだないけど。。。 Sedueでは最初の２０段でキャッシュしてる。 VSストップワード ストップワード込でインデックス作るみたい。 1.SAを二分探索 2.該当区間から出現位置をロード 3.出現位置をソート O(n)だけど、CPUのキャッシュミスが激しく影響 4.ソートした出現位置からヒット文書を求める。 同じくキャッシュミスがやばい ・実際にはmallocした領域のページフォルトが一番やばい SAが超活躍する場面 遺伝子の検索 n-gramとか死ぬ。形態素解析も無理。区切りがわからんｗ 5.P2P検索 ORBIS @ceeflyer 資料：http://www.slideshare.net/ceeflyer/p2p-search-engine-orbis\nORBISとは？ラテン語で「目」 ORBISとは？ リアルタイム検索エンジン 自律分散検索エンジン もともとはAmebaなうの検索のため ノード構成 比較的小規模（～１０００台）\u0026lt;=しょ、小規模ですか。すごいな。 Master-Slaveの差がなし MessagePack利用 フルメッシュネットワークを構築 インデックス フィールド： Content（形態素解析対象） Appendix（形態素解析しない） Flag（属性） ハッシュレプリケーションで登録。近いハッシュ値に登録（レプリカ数を指定できるのかな？） 単語に対して転置インデックスを一定数で固定 投稿日時が新しいものだけ検索するため。 検索： マージして結果を返す。 壊れてたら取れたものだけ返す。 QA： Q：ハッシュ値が大きくて１台しか選ばれないとかあるのでは？ A：ハッシュ値は循環しているという形で３台とか選ぶ。 Q：最大何台で稼働させてる？ A：現在はまだ５台程度 Q：障害時にレプリケーションの維持はするのか？ A：現時点はしてない。 Q；Cassandra、Lucendraとかあるけど、それをしなかった理由は？ A：単純にConfigurationができるから、１から作った。 今回はSolr以外の話も聞けたのがとても面白かったです。 やはり、Solr以外の検索エンジンについても知見があると、色々と比較の話しとかしやすいので。 それにしても、一からP2Pの検索エンジンを作っているのにはびっくりしました。 他にもSuffixArray（Sedue）の話も気になっていたのが少し氷解したし、海外旅行のノウハウがApacheConの話で聞けたしｗ やはり、発表をすると話しをしてもらえるのもあって、いい機会だなと再認識しました。 今回も紹介ネタだったので、ちゃんと事例とか測定したものも発表できるようにならねばと。。。\nということで、私の発表資料はこちらになります。疑問点とか質問事項とか、指摘事項など、コメントorTwitterで連絡いただけるとすごく嬉しいです。\n[Lucene gosenの紹介 solr勉強会第7回](http://www.slideshare.net/JunOhtani/lucene-gosen-solr7)** View more [presentations](http://www.slideshare.net/) from [Jun Ohtani](http://www.slideshare.net/JunOhtani) ","date":1324311660,"dir":"post/2011/","id":"c6696a730f7498efb66f5ba3a8b35d08","lang":"ja","lastmod":1324311660,"permalink":"https://blog.johtani.info/blog/2011/12/20/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC%EF%BC%97%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F%E7%99%BA%E8%A1%A8%E3%82%82%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-20T01:21:00+09:00","summary":"いつものようにSolr勉強会に参加してきました。 皆勤賞を継続中です。（暇人というはなしも。。。） 今回は話しを聞きたいですねぇといったら、いや","tags":["勉強会"],"title":"Solr勉強会第７回に参加しました。（発表もしました）(Jugemより移植)"},{"contents":"ということで、懲りずに#DSIRNLPに参加してきました。 基礎的な部分をおろそかにしたくないけど、TokyoNLPとかWebMiningではついていけないので。。。 今回もしがみつくのが精一杯かもしれないと思いつつ、聞いて来ました。\n0. DSIRNLPについて　@overlast 講演者が可能なら実装に関して言及する。 「こうやって作って結果を出す」系の発表をしましょう。 開催に際して協力してくださったみなさんへの感謝の辞。 1.自然言語処理はじめました　@phyllo 資料：http://www.slideshare.net/phyllo/ngram-10539181 ブログ：http://d.hatena.ne.jp/jetbead/20111210/1323499634 某Web企業の新入社員！（すごい） で、入って自然言語処理をはじめたらしい。 N-Gramの説明 Perl？ 1.ナイーブな方法 Perlでハッシュ使って数えてみたよ。これでOK？ いやいや、Nが大きくなったりデータが大きくなるとキツイでしょ 2.SuffixArrayを使う ということで、Suffix Arrayを使ってみた。 SuffixArrayのデータを作ってから、上からN文字数えれば数えられる！ （数式出てきたけど目も取れなかったｗ） これでいいじゃん？いやいや、更に大規模だとどーすんの。1TBのメモリ 3.近似カウント法 いくつかある中からLossy Countingを説明します。 ストリームデータから数えてみよう。 C++の実装？ 4.分散処理を使う方法 近似じゃダメ！正確な頻度が欲しい！ ＝＞Hadoopつかえ！ 色々やってみた感想が良かった。 SuffixArrayのメモリ使用量という話がありましたが、ディスクを使う方法もあります。 by ? 新人から自然言語やり始めたというが、自分が新人の頃にはこんなに出来なかった気がするなぁ。 発表とかもってのほかだったし。 2.AI で AI 創ってみた（LT）　@uchumik 資料： Luaプログラミングが出てきたので、 多クラスロジスティック回帰とListNetを書いて見ました。（ただし、本は読んでないよ。） 学習器のお話。 ラグナロクオンラインのAIがLuaでかけることを思い出した。 動画の途中で終了ｗ GitHubにあげなさい。ブログ書きなさい。動画もあげなさい。 by @overlast 資料の割に時間がｗ　2.5.CMコーナー 技評の方からWEB+DBのCM！（ただし、商品なし） 読者層の95%が男性ｗ 総集編買ってね！WEB+DB plusシリーズも買ってね！ 書いてor買ってね。 技評さんつぎはオライリーさんに負けないように賞品持ってきてねｗ 3.Mahout にパッチを送ってみた　@issay 資料：http://www.slideshare.net/issaymk2/mahout-10539755 人がやめていく会社で検索やHadoopやってます。 ※今日は皆既月食です。 機械学習関連 SGDはMapReduceでの分散に対応していないので、パッチを送ってみた。 MapReduce、Shuffleなどの説明 これをベースにナイーブベイズの説明をあわせて実装を見てみる。 ・単語ｗのカテゴリｃにおける確率 ・文書ｄのカテゴリｃにおける確率 -文書ｄに出てくる単語ｗの確率の積と定義 単語の相関を見ない。 ゼロ頻度問題の解説 文書頻度の逆数（IDF） カテゴリ毎の文書数のばらつきに対応するために、Complement Naive Bayes BayesFeatureDriver 次はランダムフォレスト 決定木とは？ ランダムフォレストとは？ ここでは素性。 Mahoutでの実装は？ 決定木の数だけ処理分散が可能。 Reducerは使ってない。＝Mapperで計算が終わっちゃうから？ 次はロジスティクス回帰 尤度関数、損失関数、確率的勾配降下法（SGD） 先程まではオンライン。バッチ学習もある。 Mahoutでの実装はオンラインで、MapReduceに向いてない！ Adaptive Logistic Regrettion（アダプティブロジスティクス回帰）というのも実装されてる。 送ったパッチの概要 Iterative Parameter Mixisngというのがあるので、それをSGDに適用するパッチ 今後 MapReduce以外も増えるかも。 Q:パッチがはいったバージョンはいつでる？A:3日前に送ったのでまだです Q:ナイーブベイズのMapReduceが一段ムダでは？（文書数のカウントは同時に出来るよね）A:そうですね、ぜひパッチを送ってみてください。 Q:Mahout、Hadoopの未来は明るいんでしょうか？A:HDFSのデータをMapReduce以外のフレームワークで使えるといい。 Q:Hadoopのパッチ送るの大変ですか？どのくらいかかりました？A:4,5ヶ月かかりました。 すみません、途中から頭がパンクしてしまいました。。。 ただ、MahoutがHadoopに乗っかってるからといって、MapReduce活用できてるわけじゃないという話がわかりました。 4.GraphDBのデータ構造　@kimuras 資料：http://www.slideshare.net/skimura/graphdatabase-data-structure LTみたいな資料にになっちゃいました。すみません。 mixiではMySQLだけど、いろんなDB触ってます。 なので、GraphDBに興味持ちました。 Luceneを教科書的に読んでます。 Neo4jモダンな作りでよかった。　http://www.slideshare.net/skimura/ss-8787632 ノードデータの構造 NodeManagerというのがいて、Cache系を管理してる。 プロパティのインデックス、トランザクションManagerもいて、PersistenceManager ここからNodeにアクセス（探索、）。 キャッシュとかいいね。 Soft LRU Cacheってのもあるよ。 その他色々ｗ Q:トランザクション周りでLRUのキャッシュはどうなるんでしょうか@kumagi A:きちんとロックしてました。 Q:分散はネットワーク、HDDどちらがキツイ？A:HDDがかなりきつい Q:プロパティもキャッシュに乗ってたほうがいい？A:プロパティも必要なら載せたほうがいい。メモリのしてはできたはず。 Luceneがほめられてました。Neo４Jの 5.冬のLock-free祭り　@kumagi 資料：https://docs.google.com/viewer?a=v\u0026amp;pid=explorer\u0026amp;chrome=true\u0026amp;srcid=0B72X9w6tG5q0NzMyODgwNDYtNjY4Yy00ZDgwLTliZDMtMjQwYmViMWE5NGU5\u0026amp;hl=en_US ※資料がうまく見れないのは、アニメーションガチガチって話だからかな？ http://twitter.com/#!/kumagi/status/145363169718697984 辻Lock-free活動してます。 Lock-freeとツイートすると補足されるらしい。 CPUの系譜のおさらい ポラックの系譜 最新のIntelManyCoreとか東大とかに配られてるらしい。 なんで、マルチコアのCPUがTSUKUMOとかで売ってないの？ 僕らが使いこなせてないから。＝マルチスレッドの対応がうまくできてないから。 CAS＝Compare And Swap まずは、Lock-free stack ABA問題？ Lock-free Queue QueueのEnqueueの場合は2回のCASが必要になる。 不変条件を守る。ロックだと守りやすい。 2回のCAS処理の間が危険領域 Lock-free List 色々なロックの説明。 Lock-free hash map これも気が狂ってるアルゴリズム？ ConcurrentHashMapなども話が出てきたが、説明しない＝Lock-freeじゃないからｗ Lock-free SkipList SkipList： 順序関係のあるデータをO(log n)で検索・挿入・削除ができるデータ構造（2分木ともろかぶり） DougLea先生がjava.util.concurrentに入っています。 Lock-free Btree 論文ないんですよ。簡単すぎて。 SoftwareTransactionalMemory The Art of Multiprocessor Programmingを読みましょう！ 論文のお話。 http://labs.gree.jp/Top/OpenSource/Flare.html を利用しているらしい。 The Art of Multiprocessor Programming関連サイト http://www.cs.brown.edu/courses/cs176/lectures.shtml すごくわかりやすかった。資料をもっと見たいなぁ。 Q:STMはメモリ使用量が2倍になる？A: Q:STM（Clojure）使ってみたけど残念な性能しか出なかったけど、なんで？A:Clojureのものはロックベース。でうーむ。。。 6.機械学習と最適化の基礎（仮）　@tkng PFIの徳永さん 日本語入力を支える技術（技評）2012年2月発売予定 最適化の話、機械学習の話、学習率の話。 大域的最適、局所的最適の説明。（言いにくそう、大域的最適ｗ） 凸最適化問題＝最適解が1つしかない？ 大域的最適解＝局所的最適解 機械学習なはなし。 スパムメールの例で説明 淡々と語られてましたが、わかりやすい説明でした。もっと昔にこんな形で数学の説明聞きたかった。。。 7.機械学習・言語処理技術を用いた誤り検出・訂正（LT）　@mamoruk 資料： スペル誤り訂正とかに機械学習とか使われてます。 8.神の言語による自然言語処理（LT）　@AntiBayes 資料：http://www.slideshare.net/AntiBayesian/ss-10539347# Lispさいこー Clojureさいこー lucene-gosenもいいよーｗ 9.言語判定へのいざない（LT）　@shuyo 資料： Solrで採用されたlanguage-detection libraryの紹介。 アゼルバイジャン語とか大変みたい。 12.作ろう！簡潔ビットベクトル　@echizen_tm 資料：http://www.scribd.com/doc/73565169/Lets-Impl-Sbv 入門編： 簡潔データ構造 データサイズをほぼ情報量的下限にまで小さくしたデータ構造 データは小さいし、速度速いというのがこれ。 実用化されてる。 mozc（LOUDSが使われてます） Sedue（圧縮接尾辞配列（デフォルトではなくなった by @tkng）） 種類： ビット列：ここの説明がこのあと 木構造：トライ木をLOUDSが結構で実装するケースが多い。データサイズが小さくなる 文字列：ウェーブレット木が有名。全文検索、転置インデックスにウェーブレット木を使う研究が多い。 中級編 簡潔ビットベクトル： rank(i)関数：i番目より前の立っているビットの数。 疎なデータ列の効率的な実装に使える。検索結果が少ない場合のFacetとかに使える？ select(i)関数：？ 可変長データ列の効率的な実装 上級編 ダメでした。。。ごめんなさい。。。 体力的に厳しかったです。。。けど面白いし、わかりやすい。どういった所でこれらを使うべきかを取捨選択するのがすこし難しそうです。Luceneとかの内部ソース見ると実はこのあたりで実装されてる部分があったりするのかも。 11.類似文字列検索の仕組み　@overlast 資料： 使い所のはなし 例：辞書メンテナンスコストを軽減したい 架空の事例から類似検索を適用できるというストーリー 既存データが活用されるうれしさの例？ Apporoのデータ構造とかの話かな？ 11.5.審査委員長から賞品持って帰る人の発表 @kumagi @tkng @echizen_tm の方たちでしたー 12.懇親会 いやぁ、前回も感じましたが、基礎ができてないなぁと実感できた勉強会です。 そして幅も広い。やはり、数学的な要素が時々出てくるのでその部分をもっと身につけないといけないなぁと。。。 ついていけなかったところも多々ありましたが、頭の中にキーワードが入ってればなんとかなるかなぁと。 Neo4jやLuceneのソースコードリーディングをやるのが仕事に役立ちそうなので、少しずつでもやろう。 これから懇親会なので、とりあえず、このへんで。 あとで、見返しながら、リンク貼り直したりすると思います。\n","date":1323529475,"dir":"post/2011/","id":"16fa0e4aefe18e1446bf6baefd3ba400","lang":"ja","lastmod":1323529475,"permalink":"https://blog.johtani.info/blog/2011/12/11/%E7%AC%AC2%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-11T00:04:35+09:00","summary":"ということで、懲りずに#DSIRNLPに参加してきました。 基礎的な部分をおろそかにしたくないけど、TokyoNLPとかWebMiningでは","title":"第2回 データ構造と情報検索と言語処理勉強会に参加しました(Jugemより移植)"},{"contents":"ひさびさに、MBAのお話です。 セットアップといっても、物理的な方ですね。 以前、ケース（カバー）について記載しました。 この記事にも書いてあったのですが、付属の滑り止めが簡易なシールで、カバンの中から出し入れすると剥がれるは、作業をしてるとずれるわで、悩んでいました。 今日、たまたま、東急ハンズに行くことがあったので、店員さんに相談してすべり止め対策のグッズを購入しました。 相談した所、カバーは傷がつきにくくなるような素材ですから、シールもつきにくいとのこと。（言われてみればそりゃそうか。） 対策としては紙ヤスリで傷つけたところに薄手のシールゴムをつければはがれにくくなりますよとのこと。 ということで、やってみました。まぁ、ゴムにホコリはつくかもしれませんが、今のところ滑らず快適！ いやぁ、ハンズの店員さんすごいですわ。 MBAについてはこんなとこです。最近また、出先に行っていてMBA使えないので、ブログを書くかメールにしか使ってないです。。。\nで、もう一つはMac Mini（2009 late：Core2Duo 2.26GHz、メモリ4G、HDD250G）です。 前職の同期から安く譲ってもらいました。音声が出力されないという問題点があるとFacebookでつぶやいているのをみて、興味を持ったらゲット出来ましたｗ で、セットアップをしたのです。 大変でした。まずつまずいたのが、キーボードとマウスでした。 これまで使っていたデスクトップのキーボードがあるのですが、これがPS/2ということで使えません。（軽いジャブ） MBAのキー配列にも慣れてきていたので、ビックカメラで悩みながらもApple純正のワイヤレスキーボードとまじっくトラックパッドを購入。 で、まずは、付属のLeopardで初期化。 このときは、ワイヤレスキーボードは認識したのですが、マジックトラックパッドはこの時代に無かったらしく、反応せず（さらに軽いジャブ） さすがに前のPCのマウスはUSBだったので、これを利用してセットアップ再開 次にSnow Leopard（これもつけてくれた）にアップグレードして最後にLionです。 Snow Leopardでソフトウェアアップデートしたところでようやくトラックパッドが認識できたと。 で、やっと使い始めたのですが、MBA（2011）に慣れていたので、思いの外もっさりした動きをしているMacMiniに 戸惑ってます。（トドメのストレート。現在ここ） ということで、どうやれば快適に使えるかアイデア募集中です。 とりあえず、Lionの設定のウィンドウ復元機能やアニメーションをオフにするなど対策してます。 HDDのSSD化とかメモリ増設とか考えないとダメかなぁ。 あと、ついでにBootcampも興味があるので、せっかくだから実験する予定です。 Windowsが前のデスクトップより快適に使えるようになるなら、Windowsマシンとするのもありかなぁと。。。\nセットアップ系はこのへんで。 あとは、最近興味が有ること2点です。（技術系ではありません） 1つ目は最近発売されたゼルダ。夜な夜なやってます。 もともとゲーム好きでゼルダも欠かさずやってきてますが、ゼルダらしさを残しつつ新しい要素やアクションも取り入れとなかなか楽しいです。 ただ、Wii全般に言えることですが難しい！まぁ、楽しんでますけどね 2つ目は前からつぶやいてるのですが、電子書籍を読むためのタブレットがすごく気になってます。 最初は財布に優しく、MBAを普段持ち歩いてるのもあるから、LenovoのA1（7インチ）で決まりだと思っていたのですが、技術書を読むのは少しキツイかもという印象。 どうしてもオライリー本などの大きめのサイズになるため、7インチの画面でPDFを表示したところ、字が小さくなってしまい拡大しないと見づらいのです。 ただ、拡大してしまうと今度はパッと見るという一覧性が下がってしまいます。。。 少々重くなってもいいので10インチにしたほうがいいのかな、けど、電車で立って読むの辛いかもなどなど考えているところで最終的な決断ができない次第です。。。 最初は毛嫌いしていたiPad2もいいかもと思う始末で困ってるとこです。 安い中華パッド（2万ちょっと）に手を出すか、7インチで我慢するか、Galaxy Tab 10.1のWifi版を輸入業者から購入するかと悩んでるところ。 ただ、長く使うのを考えると、OSのバージョンアップなどを保証してくれるiPad2が実はいいじゃないかなぁなど。 皆さんからしてみればくだらないなぁと思われるかもしれないけどずーっと悩んでつぶやいたりしております。 はぁ、こまった。（そもそもそんなにスペックいらないんじゃないかというのもあるからなぁ。メインはPDF読むことだから。） ゼルダの伝説 スカイウォードソード (期間限定生産 スペシャルCD同梱) ","date":1322668828,"dir":"post/2011/","id":"6e970d0818d58ff2d50c5bf037b1a565","lang":"ja","lastmod":1322668828,"permalink":"https://blog.johtani.info/blog/2011/12/01/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%95%E3%81%A8mac-mini2009late%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E3%81%A8%E3%81%9D%E3%81%AE%E4%BB%96%E3%81%8F%E3%81%A0%E3%82%89%E3%81%AA%E3%81%84%E8%A9%B1/","publishdate":"2011-12-01T01:00:28+09:00","summary":"ひさびさに、MBAのお話です。 セットアップといっても、物理的な方ですね。 以前、ケース（カバー）について記載しました。 この記事にも書いてあった","tags":["備忘録"],"title":"MBAセットアップ備忘録その５とMac Mini（2009late）セットアップとその他くだらない話(Jugemより移植)"},{"contents":" どんな本でも大量に読める「速読」の本 Twitterで知り合った方がこの本について書かれていたブログ記事を読んで興味を持ち、読みました。 書籍（特に技術書）が山になっていたこともあり、速読に興味を持っていたところちょうど記事を目にしたのは きっと何かのタイミングなんだろうなと。\n悪い癖で、電車で読もうと本を常に持ち歩くのですが、ついついスマートフォンやゲームで遊んでしまい、今回も読むのに時間がかかってしまいました。 ３章の途中までを今月頭に読んでいたのですが、そこから少しほったらかしで、読み終わったのが昨日でした。\n本の内容ですが、先ほどのブログにも書かれていますが、速読は技術ではない。 ### 速読　＝　速読技術　X　ストック（知識、経験、情報） であると。あとは、わからなくてもいいから、ざっと目を通す感じで繰り返し読みなさいと。 さらに、１回でわからんくてもいいから、とにかく繰り返し読むことが重要だということでした。\n確かに「速読＝１回で速く読む」、「読書＝１回で理解する」という意識がどこかにあったなぁと気付かされました。 プログラム組んだり、あることを覚えるときは繰り返しを意識してたのに、読書は１回読んで「はい、おしまい。」という気になってました。（マンガは繰り返し読むんですけどねぇ）\n他の速読の本は胡散臭いし、絶対無理だよなぁと思ってたのですが、この本に書かれている話は筋が通っているように感じました。 ただ、考えずにサラサラ読みなさいという部分の実践はなかなか難しいかな。どうしても頭の中で音読してしまうので。 私は間を開けてしまったせいで、時間がかかってしまいましたが普通なら１日あれば読める内容なので速読に関してちょっとと思ってる方は読んでみると面白いかと思います。\nちょっとだけショックだったのは、この本の論理だと電子書籍は速読に向いていないというところです。 せっかく溜まった書籍をPDF化して、タブレット購入して（まだ買ってない。。。）読もうと思っていたところなのに。。。\n","date":1322542620,"dir":"post/2011/","id":"0ebe78077c8b48410cf52a0bccdff866","lang":"ja","lastmod":1322542620,"permalink":"https://blog.johtani.info/blog/2011/11/29/%E3%81%A9%E3%82%93%E3%81%AA%E6%9C%AC%E3%81%A7%E3%82%82%E5%A4%A7%E9%87%8F%E3%81%AB%E8%AA%AD%E3%82%81%E3%82%8B%E9%80%9F%E8%AA%AD%E3%81%AE%E6%9C%AC%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-29T13:57:00+09:00","summary":"どんな本でも大量に読める「速読」の本 Twitterで知り合った方がこの本について書かれていたブログ記事を読んで興味を持ち、読みました。 書籍（","tags":["読書"],"title":"「どんな本でも大量に読める「速読」の本」を読みました(Jugemより移植)"},{"contents":"Hadoopソースコードリーディング第7回に参加しました。 いつものごとく、自分用のメモをとっていたので。 第6回（2010/12）には参加してたのですが、あれからそういえば、話が無いなぁと思っていたところに 再開するという話がTwitterに流れてきたので、即申し込みしました。 思い返せば、Hadoopに興味をもって少し触っているところで参加したのだったなぁと感慨深い思いを思い出しました。\n今回は場所を変えて豊洲のNTTデータさんで開催されました。\n日時：2011/11/28（月）19:00～22:00 場所：豊洲センタービルアネックス NTTデータ\n◎アジェンダ＋導入（NTTデータ 濱野さん） ちょっと間が空きましたが隔月で行う予定。 2012/01/12くらいに次回を予定。ネタ募集中。 ◎Hadoop World NYC 2011 参加レポート - NTTデータ 下垣 徹さん （Hadoop徹底入門著者の一人です！） ・イベント概要：2011/11/08～09にNYで開催 スポンサー企業の数がどんどん大きくなってる。 ・会場の様子 最初のキーノートは立ち見が出るほど。 個別に5並列でセッションが開催されてましたと。 ・キーノート紹介 1.Hadoop World（Michael Olson） アンケートからの概観 HadoopはNext Generation DataCenterだそうで。 2.JP Morgan（Larry Feinsmith） コスト削減＋収入増加のためにHadoopつかうぞと。 BigData分析の戦略 ユースケース１：ETL（Extract/Transfer/Load）ツールとして ユースケース２：共通データ基盤 検索頻度が低いデータの低コストストレージなどなど。 ユースケース３：データマイニング 異常値検出とか。 3.eBay（E. Williams） Cassini：オークション情報の検索エンジン 柔軟な検索＋協力なランキング機能 Hadoopで転置インデックス作成＝Luceneは使ってるってことかな？ HBaseも利用。データはHBaseに登録してる。 4.Informatica（James Markarian） データとプロセス Hadoopが賑わうからRDBMSも活気づく Hadoopはプラットフォームになるよと 5.Cloudera（Doug Cutting） Hadoopの背景と今後について BigDataを分散処理するためのカーネルになりつつあるよと。 Apacheプロジェクトの良さ 類似するプロジェクトも共存させてるよと。 Hadoopの今とこれから（0.20（今）、0.23（将来）） 0.23はHDFSの性能面改善、スケーラビリティの強化、HA MapReduce2.0 CDH4のはなし。 Hadoopコミュニティはまだまだ若い ・HadoopWorldの傾向 HBaseの利用増加 利用理由？ 小さいレコードにも強い。 ランダムアクセス 大手ベンダ参加 Oracleすげー。Hadoopの周りを固めていくぞと。 Hadoopの周りを各社がどう固めていくかというはなし。 事例が多い WibiData：HBaseの利用事例。Fonedoctor Walt Disney：Big Dataに対する機会損失があるから、導入するよと。 テーマパークの交通流解析にも使うぞ！ イケメンによる来年（2012年）のHadoop Worldの動向！？ 参加者3000人！ ラスベガスで開催？ スポンサー拡大で食事が美味しく！？ 全方位戦略vs.特化型 BIツールベンダの巻き込み 利用事例のアピール合戦 HBaseの利用事例が続々！（Salesforce.comあたりがセッション持つんじゃね？） Hadoop対抗アプリケーション、業界特化型キラーアプリケーションがますます増える？ Mahout事例の増加 データマイニング＋Web勉強会 - NTTデータ 政谷さんのHadoopNYでの発表のダイジェスト まずは印象。深く使っている人は去年より減っている。バズワードになってるからかな？ 今後もHadoopコミュニティは健全なコミュニティになりそう。（いろんな所が出てきたけど、大丈夫そうだなぁ） ・発表スライドのダイジェスト版 日本でのHadoopの盛り上がりの話。 Hadoopと他との住み分けの話。 Sqoopのお話。PostgreSQLに向けたインテグレーションの話。これはPostしてコミット待ち。 Low-Latency Serving Systemへの受け渡し（前処理はHadoopでGPGPU使ってデータをクラスタリングして処理速度をあげる） FujitsuのETERNUSにHDFS APIが用意されたという話。 MapRの話に似ているよと。小さめのクラスタの場合に有効？セッションの後に少し話題になった。 扇子を配りましたよと。 ※ビールが配られ始めた！（ビールじゃないという声もチラホラｗ） ◎『Hadoop Troubleshooting 101』 セッションレポート - Cloudera 嶋内さん （@shiumachi） Hadoopを壊す7つの方法 Hadoop設定したりしたことある人？＝結構いた。さすがソースコードリーディング Clouderaでは木曜日に重要なミーティング（ボードゲームするかFPSするか）というのがあるらしい。 チケット分析 設定ミス？ HadoopやOSの設定ファイルの変更を必要とするあらゆるチケットの事 35%が該当 問題の原因別のグラフ 1番は設定ミス 2番はバグ（これはベータ版リリースからチケット管理してるから） メモリの管理ミス Task Out Of Memory Error io.sort.mb \u0026lt; mapred.child.java.optsとなるように設定すること io.sort.mb = mapバッファのサイズ mapperとreducerを減らす。 mapper＝ノード上のコア数 これは机にはっとけ！ Total RAM = (Mappers + Reducers) * Child Task Heap + DN heap + 3GB + RS heap + ？ JobTracker Out Of Memory Error JTのメモリ使用量の合計　＞　割り当てRAM 原因は？ タスクが小さすぎ jobヒストリが多すぎ 解決は？ maximumを減らしなさい？ Unable to Create New Native Thread どういう意味？ プロセスが起動中にもかかわらずDNが障害ノードとして表示されている。 原因は？ nprocのデフォルト値が低すぎる 対応は？ /etc/seurity/limits.confの値を考えろ Too Many Fetch-Failures 元スライドの発表者はこれが大好きらしい どういう意味？ Reducerのfetch操作がmapperの出力の取得に失敗 ブラックリスト入りのTTで発生するらしい 原因は？ DNSの問題 対応は？ mapred.reduce.slowstart.completed.maps = 0.80 reducerの開始を遅らせることで対応 tasktracker.http.threads = 80 Jetty 6.1.26は使うな！CDH3u2に上げましょう。 Not Able to Place Enough Replicas 。。。きっとどっかにスライドあるからメモはこのへんでいいか。。。 ◎Hadoop World NYC 2011 参加レポート - Acroquest Technology 阪本 雄一郎さん （@frutescens） 落合 雄介さん （@taro_x） ・RとHadoopの融合（Revolution AnalyticsのDavid Champagneさん） R言語の紹介 Rとの接続点（rmr、rhdfs、？） R言語の利点がHadoopで使えるから、記述が少なくて済むよと。 統計処理がわからなくてもRが使えると分析ができるよ。（そう言われても、その分析で正しいのかとかは結局統計とかをある程度理解してないと厳しいんじゃないか？） ・Hadoopを使った衛星画像解析 スケールとかしたいからHadoopにしたけど、ジョブ起動遅いし、科学計算ライブラリが不十分 ・Hadoopをクラウド上に展開（vmware） Hadoopだけじゃなく、NoSQLとかもスケールしてから使いたいよねぇ。 ということで、vmwareの色々なものを使ってHadoopと他をうまく構築しますよ事例紹介。 マルチテナントのHadoopの話とかもありますよねと。 ◎最後はHadoopには関係ないのが多かったけどおみやげ争奪戦。 なぜか、MongoDBのシールをもらいました。 ということで、HadoopWorld2011の総括＋各スライドの紹介でした。 これまでのHadoopWorldの傾向などから、参加者などのトレンドがどうなっているかなどの話が聞けたのが面白かったです。 ClouderaのスライドはHadoopのトラブルシューティングとして必見になりそうな感じでした。 内容が濃くて、それほど触っていない私にはわからないところもチラホラ。（日本語資料の公開されるかなぁ？） 案の定、ビール（発泡酒）を飲んだので、途中から一部が飲み会状態になってたし、ピザ食べてたので、私のメモも途中から適当になってしまいました。 あとは、とある件についていろんなかたからの知見を入手できたのが良かったですね。 他にもLilyプロジェクト（Solrが利用されているOSSの話）の話もあったようなのですが（HPの方が教えてくれました）、今回の参加レポートでは含まれてなかったです。（話聞きたかったなぁ。余力があれば、スライド読むかなぁ。誰か発表してくれないかなぁ） 今日もまた、Twitterで絡んでいた方たち数人と面識が得られました。 今後は定期開催の流れになるようなので、これからもHadoopにしがみついていくためにも参加するようにがんばりますよと。\n会場提供のNTTデータのみなさん、発表者の皆さんお疲れ様でした。次回も期待してます！！\n2011/12/01追記 Togetterのまとめ\n","date":1322499060,"dir":"post/2011/","id":"924727b6f380cf3cdfe5650163e92054","lang":"ja","lastmod":1322499060,"permalink":"https://blog.johtani.info/blog/2011/11/29/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC7%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-29T01:51:00+09:00","summary":"Hadoopソースコードリーディング第7回に参加しました。 いつものごとく、自分用のメモをとっていたので。 第6回（2010/12）には参加して","tags":["勉強会"],"title":"Hadoopソースコードリーディング第7回に参加しました。(Jugemより移植)"},{"contents":"先週末から勤労感謝の日まで風邪で寝こんでました。。。 みなさん、朝晩、冷え込みが激しいので風邪には気をつけてください。\n季節の言葉も入れたので本題です。 つい最近、「Apache Solr入門」のサンプルをlucene-gosenでどうやって動かすんですかー？という質問を受けました。 確かに、「Apache Solr入門」を書いたのはSolrのバージョンが1.4が出る直前でしたし、lucene-gosenは存在せず、 当時はSenを元にした日本語の形態素解析のサンプルとなっていました。 そのSenも入手しづらくなってきており、私もlucene-gosenのプロジェクトに携わるようになってきてある程度時間が 経ちました。 せっかくなので、サンプルのschema.xmlだけでも最新版（Solr 3.4 + lucene-gosen-1.2.0-ipadic）のものを用意しました。 なお、あくまでも、3.xでlucene-gosenを利用する場合の「Apache Solr入門」のサンプルプログラムの変更点（とりあえず、4章まで）の違いについて記述します。 申し訳ございませんが、1.4と3.xの違いについての説明はここでは行いません。\n以下では、各章でschema.xmlに関連する記載のある部分を抜粋して、変更点と変更したschema.xmlのリンクを用意しました。参考にしてもらえればと思います。\n1章 1.6.1 N-gram（17ページ） 1.6.1の手順に変更はありません。 サンプルプログラムが入っているZip「solrbook.zip」のintroduction/ngram/schema.xmlファイルの代わりに こちらのschema.xmlを利用してください。\n1.6.2 形態素解析（18ページ～20ページ中盤まで） 手順が大きく変わります。 Senを利用する場合、Senの辞書のビルド、Senのjarファイルの配置、Senを利用するためのTokenizerクラスを含んだサンプルjarの配置という作業があります。 lucene-gosenではコンパイル済みの辞書がjarファイルに含まれています。 また、Solr向けのTokenizerもlucene-gosenのjarファイルに含まれています。 lucene-gosenを利用して形態素解析を体験するための手順は次の流れになります。 なお、schema.xmlについては上記N-gramでダウンロードしたschema.xmlに形態素解析の設定もあわせて記載してあります。\njarファイル（lucene-gosen-1.2.0-ipadic.jar）をダウンロードして、$SOLR/example/solr/lib（libディレクトリがない場合は作成）にコピーします。 コピーが終わりましたら、次のように$SOLR/exampleディレクトリでSolrを起動します。 （-Dsen.homeは必要なし）\n$ java -jar start.jar あとは、書籍の記述にしたがって管理画面のAnalysis画面で動作を確認します。 ほぼ、図1-6と同じ結果になっていると思います。 （lucene-gosenで出力される情報には本書のサンプルよりも多くの情報が含まれています。また、サンプルでは、形態素解析の後の単語に基本形を採用しているため、「な」が「だ」として出力されています。基本形を出力する場合は後述するこちらで紹介したTokenFilterを利用すれば可能です。）\n2章 2.1.3 schema.xmlのバージョン（27ページ） Solr3.xではschema.xmlのファイルの最新バージョンは1.4になっています。\n2.2.3 代表的なトークナイザ（35ページ） solrbook.analysis.SenTokenizerFactoryは必要ありません。 先ほども説明しましたが、lucene-gosenにはSolr向けのトークナイザが用意されています。 solr.JapaneseTokenizerFactoryがそれに該当します。\n2.2.4 代表的なトークンフィルタ（37ページ） 以下の2つについてはlucene-gosenに同等のトークンフィルタが存在します。\nsolrbook.analysis.KatakanaStemFilterFactory solrbook.analysis.POSFilterFactory それぞれ、次のものがlucene-gosenにあるので、こちらを利用します。\nsolr.JapaneseKatakanaStemFilterFactory solr.JapanesePartOfSpeechStopFilterFactory 2章向けのschema.xmlはこちらです。その他のtxtファイルについては、特に変更はありません。\n3,4章は特に変更はありません。Solrの起動の仕方にだけ注意してください。（-Dsen.homeは必要ありません）\n以上が4章までの修正点になります。 動作しないなどあれば、コメントください。 サンプルアプリについてはまた後日余裕があれば。。。\n","date":1322244000,"dir":"post/2011/","id":"26d48d68b28f927bfebad454658f9425","lang":"ja","lastmod":1322244000,"permalink":"https://blog.johtani.info/blog/2011/11/26/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AElucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0%E3%81%8B%E3%82%894%E7%AB%A0/","publishdate":"2011-11-26T03:00:00+09:00","summary":"先週末から勤労感謝の日まで風邪で寝こんでました。。。 みなさん、朝晩、冷え込みが激しいので風邪には気をつけてください。 季節の言葉も入れたので本","tags":["lucene-gosen"],"title":"「Apache Solr入門」のサンプルのlucene-gosen対応（1章から4章）(Jugemより移植)"},{"contents":"今回は、触ろうと思って触れていないMongoDBの勉強会に行って来ました。 2週連続の渋谷で、さすがに今回は出口をすんなりでれました。 今回は初のGMOさんのビルへの潜入です。 ということで、いつものごとく自分のメモを残しておきます。\n日時 :2011/11/15 14:30 to 20:00 定員 :140 人 会場 :GMO Yours （セルリアンタワー（11階）） ハッシュタグ :#mongotokyo\n1.fluentd plugins for MongoDB @doryokujin スライドはこちら。\nFluentとMongoDBのコラボレーション ・Fluentとは？ 解析対象のログについて。データ量が膨大 これまでのログの扱い方。日次でS3に送信して、ログ解析サーバにて前日分を解析する。 これではリアルタイム性がないのが問題！しかも1日分なので、データ量が半端ない。 そこでFluentにてストリーミングアプローチ。 リレーサーバ（Fluentd）にログを流すと、適宜、解析サーバに流れていく仕組みが可能。 これにより、ネットワークに負荷をあまりかけずにログを定期的（時次とか）で流せる。 ※splunkに近い考えかな。 ここで、Fluentのスライドで説明が入りました。http://www.scribd.com/doc/70897187/Fluent-event-collector-update ・Out Mongo For Local Back-Up MongoDBへの出力。 信頼性をあげるためにローカルにmongoDBを置いておき、スプールしておく。 リレーサーバにも配置してみるという仕組み。 バッファリングにMongoDBを使うので Aggregation Mongoってのを作ったらしい。そのせいで、スライドの作成が遅れたらしいw ・Aggregation Mongo Map/Reduceの集約のようなプラグイン。 fluentdのアプリを通して、特定のキーをベースに集計してから、outputする仕組み。 更に、キーに対してshufleが行われて、次のfluentdにデータが集まる。　fluentdを使ってM/Rっぽいことが可能なのかな。 QA 最終的な流れ込み先のMongoDBはCappedCollectionじゃなくしたほうがいい。検索とかしたくなるから。 2.about Server Density and MongoDB @davidmytton スライドはこちら\nQueuingシステムで利用。 MongoDBとRabbitMQとの比較？ MongoDB関連のノウハウかな。 データ量に関する話。メモリに載せたほうがいいのかとか、ログ出力の設定とか、ジャーナルとか。 HDDの見積もりに関連しそう。 健康状態の監視方法。 コネクションプールの話とか。 rs＝ReplicaSet？ mongostatってコマンドがあるのか。 ServerDensityのツールとダッシュボードなどについて。 ※英語のスライド見ながら話聞くとメモがとれない。　まとめ： Keep it in Ram インデックスはメモリに載せましょう。 Watch your Strage ストレージのサイズは監視しましょう。（ログ、データ、ジャーナルなどなど） db.serverStatus()　コマンドあるよ。これで見れるデータが重要なのかな？ rs.stats()　コマンドあるよ。これで見れるデータが重要なのかな？ QA：残念ながら聞き取れなかったっすｗ Q：MongoDBのクエリログの統計の質問。DBごと？＝コレクションごと？のクエリ統計のとり方は？ A：MongoDBにはないので、ログレベルを下げて統計取ったりする方法しかないかなぁ。 3.MongoDB: Case Study for AMN @koyhoge スライドはこちら\nサービス（アジャイルメディア・ネットワーク）で利用している実例について 広告配信に関連して利用してる。 最初にPostgreSQLにて実装。5分おきにCronで再起動するはめに。。。 PostgreSQLの次にSimpleDBへ（インサートが遅い。分散インサート） SimpleDB＋SQSに変更。1日130$で断念。 SaaSなKVSはやめてMongoDBに移行してみる。 負荷も軽いし、インサートも速い！ EC2でMongoDB。しかもレプリカを東京A、B、シンガポールAにしてみよう。 shardingは残念ながらうまく行かず。 ストレージはEBSの1TB 4.「MongoDBとHadoopの蜜月関係」 @muddydixon スライドはこちら\nお父さんエンジニアなので、土曜日の勉強会は無理です！＝同じく辛いです！ HadoopとMongoDBのつなぎについて。 MongoDBからデータを読み込んで、Hadoopで計算してMongoDBに戻すものがmongo-hadoop データロストがニュースになってて心配してる。データロストはめったにない（by @doryokujin） Hadoopを計算だけに利用できるのでクラスタが落ちても気にせず立ち上げができそう。 MongoDBからデータを取得する時点でフィルタリングが可能なので、Hadoopでの演算が楽。 AdHocなクエリをMongoDBに投げれるのがうれしいのかな？ HBaseとかHiveに入れてやったりはダメなんかな？ QA Q：なんで、みんなMongoDBにログ入れるの？@kzk_mover A：様々な形式を入れやすいから。 Q：捨てるのどーするの？ A：コンパクションが大変（ただし、2.0以降は良くなる予定） Q：MongoDBのMap/Reduceは？ A：時間がかかった上に死ぬというひどい目にあったので。。。 5.Fusion-io @hasegaw\n340の仮想マシンが4台で動きます！ すごそう。。。一回は触ってみたいかも。 Fusion-ioすげーーーって感じ。（Ustストップ） 6.MongoDB on Cloud Foundry @yssk22\nVMWare社のPaaSオファリングの名称 感想など： mongoDBに興味はあるのに、腰が引けてるおじさんになって結局触らずに会場入りしてしまいました。 会場に入っていきなり、Treasure Dataの太田さんがマグカップを売っているという場面に遭遇するというインパクトがあるスタート。（思わず1個購入） 最初はMongoDB JPの主催者でもある@doryokujinさんの話から。今熱いfluentdとmongoDBの組み合わせに関する話で、面白かったです。 途中でfluentdを作っている古橋さんのスライドを用いてfluentdの解説まで入りました。 TL上では、その古橋さんが時々フォローを入れているという贅沢な流れ。 なんとなく仕組みはスライドなどを見ていたのですが、更に理解が深まりました。 次が、イギリスから来日されていた@davidmyttonさん（なんと24歳という若さ！）のお話。 残念ながら英語のヒアリングは微妙な私なので、あまり理解できなかったのですが、どうやら、MongoDBの運用でのTipsのお話だったようです。スライドを後で見なおしたほうがいいかな。 次は、実際のMongoDBを利用した事例の紹介。PostgreSQLから試行錯誤してMongoDB＋AWSの組み合わせのお話。 やはり実例があると面白いですね。試行錯誤された部分があるので、非常にわかりやすかったです。 次が、HadoopとMongoDBの組み合わせのお話。HadoopのMap/Reduceの部分だけを利用して、データ保存先はMongoDBにしましょうという割りきった話でした。 いくつか疑問点がメモにもありますが、残念ながら質問する勇気なしという腰抜けっぷり（もうちょっと積極的にならないと。。。） で、このあとFusion-ioとCloud Foundryの話になるのですが、体力切れ＋lucene-gosenのjavadocが古いことに気づいてしまい、作業をしながら聞いていたのであまり頭に残っていません。（ほんとに申し訳ない。。。） とまぁ、最近、Twitter上でいろんな人に絡みまくってまして、@doryokujinにも絡みまくってたというのもあり、今回参加することにしたという次第でした。 懇親会にも多くの人が残っており、良いコミュニティができてるなぁというのが正直な感想です。 各セッションでも@doryokujinさんが適宜QAなどのフォローをされていて感心しっぱなしでした。 あとは、Twitter上で会話をしていた方たちとも顔合わせができたので、大収穫でした。\n次は、少しでもいいので、触ってから参加することにしようかと思います。 来年1月にはMongo Tokyo 2012というイベントも開かれるようで、ますます注目を浴びていきそうですね。主催者もミドルウェアもｗ\nあ、そうそう、そんなMongoDBの勉強会でしたが、CouchDBの話もちらほら出てまして、CouchConf TOKYOというチラシも@Ijokarumawakさんから頂きました。こちらも1月開催のようです。\n追記： 戦利品の画像です。マグカップ（500円）以外は貰い物です。 なんと、このUSBにはMongoDBのコマンドやクエリのチートシート（PDF）が入ってました。びっくり！\n","date":1321376880,"dir":"post/2011/","id":"bda9a5da86ec9790262e14f953bbadcb","lang":"ja","lastmod":1321376880,"permalink":"https://blog.johtani.info/blog/2011/11/16/mongodb%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC7%E5%9B%9E%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-16T02:08:00+09:00","summary":"今回は、触ろうと思って触れていないMongoDBの勉強会に行って来ました。 2週連続の渋谷で、さすがに今回は出口をすんなりでれました。 今回は初","tags":["勉強会"],"title":"MongoDB勉強会（第7回）に行って来ました。(Jugemより移植)"},{"contents":"Solr本の武田さんから教えていただいたSplunkの イベントに行って来ました。 Splunkとは様々な機器のログなどを一箇所に集めてリアルタイムに検索、分析できるようにするための製品です。（ざっくりした説明ですが。。。） ちなみに、データ量が小さければフリー版も用意されています。 以前、話しを聞いていて気になっていた所イベントが開催されるということだったので参加してきました。 以下に、その時取ったメモを記載しておきます。いつものごとく、自分用のメモなので、役に立つかはわかりませんが。\nSplunk Live! in toyosu\n日時：2011/11/02　10:00-12:00 場所：豊洲\n1.挨拶＋アジェンダ紹介 2.ビッグデータ取り込み、ロードマップ（Splunk Inc.）CEO Godfrey Sullivan 英語でした。。。 データの種類と量が大きくなってきてるのに、ツールが追いつかないし、回答するのもはやくしろと言われる。 非構造化データの例としてApacheのログが出ていた。 TimeSeriesのフラットファイルがsplunkのデータのインデックス。（No RDB＝スキーマいらないよと。）　※ここが重要な点かもしれない。 リアルタイムに解析できるのが売り。Jubatusとの違いとか聞くと面白いかも。 Machine Data Engine＝Splunk データの関連付けの方法がどんなものか？ 事前のスキーマが不要＝流しこむ前には定義が必要？だよね？ ？No need to filter/forward？？ デベロッパーフレームワークってなんだ？？ Splunkbaseと呼ばれる場所にSplunk Appsと呼ばれるアプリケーションがある。色々な場所、OS、アプリで利用できるものらしい。 ？自動監視も学習する仕組みがある？？ それとも定義するのか？ あくまでもMachine Dataと言っている。これは、ユーザのリレーションの解析などはないということか？ Leading Social Gaming Company＝Zynga Introscopeのログバージョンに似てるかもなぁ。 Cloudベースのアプリの解析にも利用（saleforce） 色々な利用シーンのお話。 3.適用事例（独立行政法人理化学研究所） 和光と神戸で利用。10G程度のデータを扱ってる？ ログから情報基盤を監視するのに利用している。 syslogベースでsplunkにログを送信している。 事例１：VPNに接続できない（接続数上限がある？） CISCOのログから解析 どの研究室で発生しているかも検索。 事例２：DHCPの接続ミス？（IPアドレスロスト） ここまでは問題が発生してからログを漁るという使い方。 事例３：LINK FLAPのアラート 短時間にUPDOWNを繰り返す場合にスイッチがおかしくなってるんでは？ 事例４：メール大量送信（ウィルス感染） 不特定多数のサーバに短時間でメールを配信している ※使い方としては情報基盤環境すべて（ネットワークとかサーバなど）のログを集めておいて監視＋解析に利用して障害対応などに利用している？データセンターとかに入れるのか？ あくまでも、ログを保存して、検索できる仕組みが１箇所にまとめられているという感じ。 そのログの解析について（どういった問題に対して、どういったクエリを投げるか？どういったトラップを仕込むか？）は利用する側の腕にかかっている印象。 ※実際に触ってみたいなぁ。500M/dayか。ご近所に入れてみるか？syslogで転送設定＋入れるサーバが必要。 4.最新アプリなどの紹介（Splunk Inc.） GUIがきれいだなー（最近のgoogleっぽいが。。。） リアルタイムにデータが入っているのが見えるのか。おもろいな。 どこのフィールドにヒットしたかがファセットで表示できるらしい。おもろい。 flashでできたビューがすごくおもろかったぞ。（ドキュメントどこだ？） 5.最新の取り組み（NTTデータ先端） やっぱり武田さんだった。 複数の監視システムのメッセージを統合して検索、アラートを出せるようにする。 消費電力を算出するためにログを集めて集計する。 6.QA ロードマップ ・２年以内にビジネスサイドでの利用に向けての動きを見せていく予定。 ・アプリケーションフレームワークにして、他のパートナーのアプリを載せていきたい。 ということで、感想ですが、事例紹介などを聴いた感じだと今のところはインフラ系のログを一元化して検索、監視、アラートをあげるということに活用するためのツールの用に感じました。 当初の使い方がそういったところにあるためだとは思いますが。 開発者としての視点で話しを聞いていて、活用できそうだというのは次のシーンでしょうか。\n開発時の開発環境のログ集約 性能試験などでのログ、性能データ集約 開発時点もしくは性能試験時ですが、色々なサーバ（DBやアプリサーバ）の時間を横串にして表示検索などができると思うので、問題があった時の各種サーバの状態を一元的に見れるため、どのサーバにどういった負荷がかかっていたか、 どこに問題があったかなどをグラフ化して見ることが簡単にできるのではないかなぁという感想です。 あとは、ログが一元化されているので、問題があったときにまずログを検索すればいいのが楽ですかね。\n基本的にはログが集まってるからあとは、どう使うかはご自由にという印象でした。 どのようなログを集めておき、どういったトラップでアラートさせるか、どのような検索をすれば望んでいるログが出てくるか、どのような集計をしたいかなどについては、やはり導入してからノウハウを貯めていくか、導入時にコンサルしてもらうなどが必要かと。 また、このツールを入れることでどのようなフィードバックをどのように活用できるかをイメージしていなければ、 宝の持ち腐れになりそうです。 あとは、使い方次第ですが、サーバログ以外にアプリログ（ユーザの行動履歴とか）などを入れることで、インフラ以外での使い道もありそうです。 とりあえず、保存しておいて、あとから特定の傾向を見出すのに検索できるのはちょっと面白いかも。\nあ、そうそう、ストラップとUSBメモリ（4G）のノベルティをお土産にもらいました。無料セミナーなのに。\n","date":1320822000,"dir":"post/2011/","id":"cc1a3b2f107510ac664e491d5f2412aa","lang":"ja","lastmod":1320822000,"permalink":"https://blog.johtani.info/blog/2011/11/09/splunk-live%E3%81%AE%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-09T16:00:00+09:00","summary":"Solr本の武田さんから教えていただいたSplunkの イベントに行って来ました。 Splunkとは様々な機器のログなどを一箇所に集めてリアルタ","tags":["misc"],"title":"Splunk Live!のイベントに行って来ました。(Jugemより移植)"},{"contents":"最近忘れやすいので、記録しておこうかと。 読んだスライドの簡単な内容と感想です。 ちなみに、スライドの一覧はこちらです。 ※スライドへのリンクはすべてPDFへのリンクになっていますので、注意が必要です。\nSolr 4 Highlights（PDF）\nSolrの次期バージョン4.0で採用される機能の紹介でした。 紹介されているのは次の機能。各機能について、JIRAの番号も記載があるので便利ですね。\nDirectSolrSpellChecker NRT (Near RealTime search) Realtime Get SolrCloud - search side SolrCloud - indexing side (WIP) これまでと異なるSpellChecker、Commit前のデータが検索できるNRT（なんでNRSじゃないんだろう？）、Commit前の登録済みデータを取得することが出来るRealtime Getなどの簡単な紹介です。 あと、個人的に興味のあるSolrCloud周りが絵付きで紹介されてます。ZooKeeperもちょっと出てきます。 まだ、ちゃんとまとめてないですが、NewSolrCloudDesignの翻訳したものも参考までに。（その１、その２）\nArchive-It: Scaling Beyond a Billion Archival Web-pages\nInternetArchiveの事例紹介。1996年からWebページのアーカイブを行なっているサイトですね。 その一部でSolrが利用されています。 「1,375,473,187 unique documents」との記述もあり、データ量が巨大です。 データ量が多いのに、ここでFieldCollapsing/Groupingも利用しているようで、インデックス作成、検索両方に対してカスタマイズしたものをgithubで公開している模様です。\n[**Scaling search at Trovit with Solr and Hadoop**](http://www.lucidimagination.com/sites/default/files/file/Eurocon2011/MarcSturlese_scalingsearchTrovit_eurocon2011.pdf) 次は、Trovitという会社のSolr＋Hadoopの事例紹介です。 最初はLuceneをベースに検索サーバ作ってたけど、Solrが出てきたので、Solrを使うようになったようで。 データ保存先として最初はMySQLを利用してDataImportHandlerでSolrにデータ登録してたけど、 データ量が増加するが、MySQLのShardingが面倒なので、Hadoop（Hive）でデータをパイプライン処理してSolrのインデックスを作成しましょうという流れになったようです。 私が以前、Solr勉強会で紹介したSOLR-1301のパッチをベースにMap/Reduceの処理を2段階にして性能をアップさせたという話が記載されてました。 ただ、これで早くなるのかはよくわからないんですが。。。 一応、資料では、いきなり大きなSolrのインデックスを作らずに、最初のM/Rで小さなインデックスを作成し（TaskTrackerの数＞＞Solrのshardサーバ数だから小さくしたほうが速い？）、 2段目のM/Rでインデックスをマージしてshardサーバ数のインデックスに集約する？という形みたいです。 （英語力のなさが。。。） あとは、テキスト処理を幾つかHadoopでやってますよという紹介でした。 SOLR-1301の利用者が他にもいて、違うアプローチをとっていたのが印象的。 毎回全データインデックス生成するときは、SOLR-1301を利用してshard数が増えてもすぐに対応が可能になるので、 かなり便利ですよ。\nSolr @ Etsy\nEtsyは個人の作家（編み物とかシールとか）の方が出店するためのショッピングモールのようなサイトです。 実は、最近、MacBookAirのステッカーを購入したのがここでした。 で、検索にSolrを使っています。 面白いのが、検索サーバとWebアプリ（PHPで書かれている）の間のデータのやり取りにThriftを利用していること。 Solrの前にThriftを話すサーバを別途用意しているようです。ネットワークのデータ量を減らすことが目的らしいです。 そのあとは、少しThriftのサーバでのLoadBalancingの話が続きます。 次にレプリケーションの性能問題のはなし。定期的にレプリケーションに異様に時間がかかるのが問題になったようで、 Multicast-Rsyncを試してみたけどダメでしたというはなし。 Bit Torrent + Solrという組み合わせで回避したらしいのですが、いまいち仕組みがわからなかったです。。。 こちらもgithubに公開されている模様。 あとは、QParser、Stemmerをカスタマイズしたものの話です。\nArchitecting the Future of Big Data and Search\nLuceneのカンファレンスにHortonworksが出てきてびっくりしました。 まぁ、Luceneの生みの親＝Hadoopの生みの親ですから、問題ないのかもしれないですが。 大半が予想通り、Hadoopに関する話でした。 知らないApacheのプロジェクト「Ambari」というのが出てきました。これは、HadoopConferenceJapan2011 Fallでの発表にもチラッと出てきたようです。 「Ambari is a monitoring, administration and lifecycle management project for Apache Hadoop clusters.」ということで、Hadoopクラスタの統合管理のツールになるんでしょうか？ 最後の2枚くらいにLuceneが出てきます。絡めてみたって感じですかね。\nConfiguring mahout Clustering Jobs\n今度はMahoutが出てきました。はやりのものが満載です。 まぁ、MahoutもLuceneのインデックスを利用するという話もありますので。 スライドはクラスタリングとはどういうものか、Mahoutの説明とテキストクラスタリング処理のお話、最後はstuckoverflowでのMahoutとSolrの活用の仕方について。\nということで、英語力がない中、かなり流し読みな感じですが、あとで思い出すために書きだして見ました。 何かの役に立てれば幸いです。\n他に、こんなスライドが面白かったとか、このスライドについても書いてほしいなどあれば、コメントください。\n","date":1320724920,"dir":"post/2011/","id":"d9c6ab5c6630a4a84e242c5765103d2d","lang":"ja","lastmod":1320724920,"permalink":"https://blog.johtani.info/blog/2011/11/08/lucene-eurocon-2011-barcelona-%E3%81%AE%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%89%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-08T13:02:00+09:00","summary":"最近忘れやすいので、記録しておこうかと。 読んだスライドの簡単な内容と感想です。 ちなみに、スライドの一覧はこちらです。 ※スライドへのリンクはす","tags":["solr"],"title":"Lucene Eurocon 2011 Barcelona のスライド読みました(Jugemより移植)"},{"contents":"Bookscanというサービスがあります。 書籍を電子化（PDF）して原本を破棄してくれるサービスです。\n電子書籍にはずっと興味を持っていました。 技術書を購入するのですが、技術書は３００ページ超の大きな書籍が大半です。 また、日本語の技術書については、なかなか電子書籍が見つからないもしくは、電子化されるのが遅いとうのが現状です。 海外では、Manningなど、電子書籍も同時に発売（もしくは、製本前から電子書籍が売られている）サイトがありますが、やはり英語の書籍はハードルが高いなぁと。\nそんな中、Bookscanの噂を耳にしました。 ということで、どんどん、積ん読になっていく技術書だったので、思い切って、電子化してみることにしました。 ※残念ながらまだタブレット（電子書籍端末）は持っていないのですが。。。もうすぐ発売されるlenovoの7inchタブレットを待ちかねているところです。\nBookscanでは、１冊１００円で書籍をPDFにしてくれます。（ページ数により変わってくる） この場合、あくまでも書籍をスキャンするだけで、検索などはできません。 OCR処理については別途１冊１００円（これもページ数による）のオプションが必要になります。 詳しいサービス内容はこちらを御覧ください。 基本的には書籍をBookscanに発送してから約３ヶ月ほど電子化するのに時間がかかります。 これでは、すぐに見たい場合に手元にないという状態になってしまいます。 この電子化までの時間を短くできる、「プレミアム会員」というオプションが存在します。 月額固定の費用（９９８０円）を支払うことで、５０冊（※ページ数により１冊の単位が異なります）まで無料で、「スキャン＋OCR＋書籍名をファイル名」のPDFファイルを書籍到着後１週間以内で作成してもらうことができます。 また、プレミアム会員は月単位での契約が可能なようで、１ヶ月（＝５０冊）だけ早く電子化してもらうといった利用方法もできるようです。\nで、実際にプレミアム会員となって４９冊の書籍を送付して電子化してもらいました。 先週金曜日に発送、Bookscanに書籍が到着したのが翌土曜日、電子化が完了したのが火曜日の夜という感じでした。 すごくはやい！かなり感動してます。自炊自体をしたことがないので、出来上がりが自炊と比べてという比較はできないのですが、ざっと見ている感じでは全然問題なく読めそうです。\nただ、１冊の２ページだけ、ページの端が文章の途中で切れているPDFがありました。 この書籍に関しては、サポートサービスにお願いして、再スキャンをしてもらいました。 昨日夜に頼んで今日の午後には問題なく電子化されているというサービスの質でとても満足しています。 なお、原本の破棄が電子化後から１０日後に行われるため、問題ないかの確認はそれまでに行う必要があるようです。 大量の本を送る場合は小分けに送ったほうが確認するのが楽になると思います。（送料は小分けにした分、かかってしまいますが。）\n書籍の山になっていた机がすっきりして、とても満足しています。 せっかく電子化したので、早くタブレットが欲しいなと思う今日この頃。。。 基本的には今後は電子書籍を購入するようにしていく予定なので、プレミアム会員を継続することはないと思いますが、 家に溜まっている漫画を電子化するのもありかなぁと思っているところです 漫画の場合はOCRに掛ける必要もないですし。\n個人的にはBookscanさんには悪いのですが、もっと電子書籍が増えると助かります。 技術書はページ数が多く、重たいうえ、実際に利用するときは検索したくなることが多々ありますので。 あとは、電子書籍を検索できるサイトがあるといいなと思ってもいるところです。 現在は、各出版社が個別に電子書籍のHPを持っている状況で、会社によっては検索すらできないです。 電子書籍があるかないかだけでも簡単に検索できると、いいなと思っています。（小説などはまた別なのかもしれないですが。） みんなはどう思ってるんですかねぇ？検索したくないですか？\n","date":1320225060,"dir":"post/2011/","id":"7a9609a971a8f31685e88da563eea5ce","lang":"ja","lastmod":1320225060,"permalink":"https://blog.johtani.info/blog/2011/11/02/bookscan%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-02T18:11:00+09:00","summary":"Bookscanというサービスがあります。 書籍を電子化（PDF）して原本を破棄してくれるサービスです。 電子書籍にはずっと興味を持っていました","tags":["misc"],"title":"Bookscanを使ってみました(Jugemより移植)"},{"contents":"lucene-gosenの最新版（1.2.0）をリリースしました。\nプロジェクトページよりダウンロードが可能です。\n新規追加機能についてはこちらのエントリを御覧ください。\nバグなどありましたら、容赦なく報告をいただけると助かります。\n","date":1320043560,"dir":"post/2011/","id":"14cf6e75aec1ead888e7101d3d94d28a","lang":"ja","lastmod":1320043560,"permalink":"https://blog.johtani.info/blog/2011/10/31/1-2-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2011-10-31T15:46:00+09:00","summary":"lucene-gosenの最新版（1.2.0）をリリースしました。 プロジェクトページよりダウンロードが可能です。 新規追加機能についてはこちら","tags":["lucene-gosen"],"title":"1.2.0リリース(Jugemより移植)"},{"contents":"すぐやりますと言いつつ、はや1ヶ月。。。 腰が重い、ダメエンジニアですね。。。\nすみませんでした。。。 ようやくtrunkにコミットしました。 すぐにリリース版を用意すると思います。\n1ヶ月もあいてしまったので、追加した機能に関するまとめと、 用途別の利用方法を記載しておきます。 （lucene-gosenのWikiにもそろそろ書かないとなぁ。日本語でもいいから。）\n追加した機能\nこれまでのlucene-gosenはjarに辞書を含む形でライブラリを提供していました。 ただ、この場合、カスタム辞書を利用している環境ではカスタム辞書を修正し、ビルドしなおすたびに、 jarファイルを作成しなければなりません。 また、jarファイルをSolrなどに配布する必要も出てきます。 この手間を考慮して、辞書を外部ディレクトリで指定することができるようにしたものが 今回の修正になります。 また、修正の過程で同一VM内で異なる辞書を使えるようにする機能も副産物として生まれました。 今回追加した機能は次のようなものになります。 辞書を含まないjarのビルドおよび提供 ディレクトリ指定による辞書の指定 同一VM内での複数辞書の利用 辞書リビルド用のAntターゲットの追加 Lucene/Solr jarファイルの最新化（3.4.0対応） ディレクトリ指定による辞書の指定ですが、以下のような形になります。 まずは、LuceneのTokenizerでの指定方法です。 「辞書のディレクトリ」という引数が追加になっています。 ここに、辞書ディレクトリ（*.senファイルが存在するディレクトリ）を相対/絶対パスで指定します。\n... Tokenizer tokenizer = new JapaneseTokenizer(reader, null, \u0026#34;辞書のディレクトリ\u0026#34;); ... つぎは、Solrでの設定の方法です。 schema.xmlにて次のような設定を行います。\n... \u0026lt;fieldType name=\u0026#34;text_ja\u0026#34; ...\u0026gt; \u0026lt;analyzer\u0026gt; ... \u0026lt;tokenizer class=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; compositePOS=\u0026#34;compositePOS.txt\u0026#34; dictionaryDir=\u0026#34;辞書のディレクトリ\u0026#34;/\u0026amp;gt; ... \u0026lt;/analyzer\u0026gt; \u0026lt;/fieldType\u0026gt; ... schema.xmlの設定については、example/schema.xml.snippetにも説明がありますので、こちらもあわせて参考に。 なお、Solrの設定については、先ほどのLuceneでの辞書のディレクトリの指定方法（絶対/相対パス）に加えて、 $SOLR_HOME/conf からの相対パスでの指定も可能になっています。\nAntのターゲットについて\n辞書なしjarファイルを作成するターゲットなどを追加しています。 実際に追加したターゲットは以下のとおりです。 ターゲット名 説明 nodic-jar 辞書なしのjarファイルを生成するためのターゲット。辞書のダウンロード、コンパイルは行いません。 rebuild-dic lucene-gosenのビルド済み辞書（.senファイル）を削除してから辞書のコンパイル（ビルド）を行います。-Ddictypeにより辞書のタイプ（ipadic|naist-chasen）の指定が必要です。また、-Dcustom.dicsによりカスタム辞書の指定もあわせて可能です。 build-dic-ipadic テスト用に追加。-Ddictype=ipadicを指定してbuild-dicを実行。 build-dic-naist-chasen ついでに追加。-Ddictype=naist-chasenを指定してbuild-dicを実行。 最後の２つはあまり関係ありません。内部的に有ると便利だったため、作りました。 重要なのは最初の２つです。 ひとつめの「nodic-jar」は辞書を含まないjarファイルをビルドします。 このjarファイル＋辞書の入ったディレクトリを利用することで、辞書の外部化が可能となります。\nそして、「rebuild-dic」です。こちらは、以前記事に書きましたが、カスタム辞書のコンパイルが思いの外面倒だったので、ターゲットを追加しました。 次のように指定することで、辞書のリビルドが可能です。\n$ ant -Ddictype=naist-chasen -Dcustom.dcs=\u0026#34;custom1.csv custom2.csv\u0026#34; rebuild-dic 提供されるjarファイルについて\n提供されるjarファイルは次のようになる予定です。 1番目のjarファイルが今回追加になる、辞書なしのjarファイルになります。\nlucene-gosen-1.x.x.jar lucene-gosen-1.x.x-ipadic.jar lucene-gosen-1.x.x-naist-chasen.jar 用途別の利用方法 利用用途別に利用するjarファイルやantのターゲットを利用シーンを交えて想定を書いてみます。 Solrでの利用シーンを想定します。\nお手軽に使う。辞書ありjarファイルで一発インストール。 これまでどおりの使い方になります。 辞書込みのjarファイルを利用すれば、すぐに利用可能になります。\nカスタム辞書を使い倒す。定期的に辞書をメンテナンス。 定期的にシステム固有の単語が増える（例：製品名、新語など）場合です。\n利用するjar：lucene-gosen-1.x.x.jar 辞書のコンパイル＋配置：ant -Ddictype=naist-chasen -Dcustom.dics=\u0026ldquo;custom1.csv\u0026rdquo; rebuild-dir Solrの該当コアのRELOAD Solrのマルチコア環境を利用します。なお、sharedLib設定にlucene-gosen-1.x.x.jarを配置すると、辞書の再読み込みができないので注意してください。 設定は、上記のようにTokenizerFactoryの設定でdictionaryDirにて辞書のディレクトリを設定しておきます。 カスタム辞書に単語を追加後、antにて、辞書のリビルドを行います。 リビルドした辞書ファイルを必要に応じて対象の辞書ディレクトリにコピーします。（ビルド後のディレクトリをそのまま利用している場合はコピーの必要はないです。） 最後に、Solrの該当コアのリロードを行います。（リロードの仕方はこちらを参考に。） コアのリロードにより、辞書の再読み込みが行われるので、リロード後から新しい辞書が適用されます。\n異なる辞書を使い倒す。TokenizerごとにdictionaryDir設定するぞ 1つのSolrで異なる辞書を使ったフィールドを使いたい場合です。 ipadicとnaist-chasenといった異なる場合はあまり想定できないですが、カスタム辞書の部分が異なるという形が想定できるでしょうか。（例：製品名のフィールド、企業名のフィールド。。。など）\n利用するjar：lucene-gosen-1.x.x.jar 設定：schema.xmlに異なるdictionaryDirを設定したTokenizerFactoryを設定 上記、カスタム辞書の定期更新も一緒に行うことも可能です。コアをリロードすれば、リロードしたコアで利用している 辞書がすべてリロードされます。\n最後に 遅くなってしまいましたが、ようやく、trunkにコミットしました。 できるだけ速く、リリースしますので、もう少々お待ちを。\nSolrのconfディレクトリからの指定については、＠shinobu_aokiさんにパッチを提供してもらいました。 また、trunkにコミットしていないパッチを適用して記事を書いてくれた方もいらっしゃいました。こちらもあわせて参考に。私より説明が上手です。 Java製形態素解析ライブラリ「lucene-gosen」を試してみる\n","date":1319559120,"dir":"post/2011/","id":"14a6d294550c9760aec57ba29682a750","lang":"ja","lastmod":1319559120,"permalink":"https://blog.johtani.info/blog/2011/10/26/%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%A4%96%E9%83%A8%E5%8C%96%E3%81%A8lucene-solr3-4%E5%AF%BE%E5%BF%9C/","publishdate":"2011-10-26T01:12:00+09:00","summary":"すぐやりますと言いつつ、はや1ヶ月。。。 腰が重い、ダメエンジニアですね。。。 すみませんでした。。。 ようやくtrunkにコミットしました。 すぐ","tags":["lucene-gosen"],"title":"辞書の外部化とLucene/Solr3.4対応(Jugemより移植)"},{"contents":"JJUG CCC 2011 Fallに参加してきました。 個人的にはかなり久々のJavaのカンファレンスです。（※あくまで「Javaの」という話で。SolrやHadoopとは別という意味です。）\n概要やタイムテーブルはこちら。 予定があったので、残念ながら最後の２つのセッション（Scala、Twitter）しか参加できませんでした。 Hadoopの話も聞きたかったのですが、しょうがないかと。 いつものごとく、メモを個人的に取ったので。\n★楽々Scalaプログラミング 浅海 ◎OOPからOFPへの道しるべ ・関数型の使い所、プログラミングのコツ ・つながりの部分 ◎最近の活動 モデリングからモデル駆動によるソース生成などに利用。 Scala、2008年から使い始めている ◎Scalaと他の機能との比較図 ◎Scalaの用途 ・高い生産性 体感で3倍。コード量が少なくなる。 IDEのサポートを考えるとまだ、Java+Eclipseのほうが高い！ ・DSL ドメインモデルの記述 フレームワークAPI ・並行プログラミング Many Core 消費電力的に複数のコアで動かす＝関数型のほうが並行性が上がる（スレッドさわるJavaだけだときつい） Parallel Everything Object指向＋関数型が扱いやすい。 ◎関数型言語とは ・公開関数をあつかえる 関数を値として扱える、引数と返却地に関数を渡せる。（やさしめ） ＜＝＞ 数学（ラムダ計算、圏論など）的にプログラムを記述できる（きびしめ） ある程度使えるはず。厳しめの部分も ◎関数型言語の長所と短所 長所 ・高階関数を使った技が使える List（？？？） 短所 ・メモリ、関数実行オーバーヘッド、スタックの大きさが読めない（再帰的） ◎関数型言語の系譜 純粋関数型言語 pure Lisp 伝統的関数型言語 OCaml 新世代関数型言語 Haskell Scala 型クラス 代数データ型、モナド Parametric polymorphism ◎関数型でしたいこと DSL（Domain Specific Lanuguage） 昨年の資料を参考に！ ◎準備 scalaの文法 ◎並列コレクション スレッドを利用しないで並列に動作実行させるか？ ※List().par.map(sitelen).sum これで並行実行させられる。 ◎Future （これってJavaでもあるよね？＝あるよ） 処理を非同期で先行実行し、あとから結果を取得可能 Scalaではアクターライブラリでサポート（cala.actors） 関数合成するとFutureの実行結果を取り出す所でブロックされる！！ ◎Promise Futureより強力 関数合成すると、合成関数全体が非同期実行される！ scalazを利用してた ◎5つのコツ コツ１：　y=f(x) 引数がひとつの関数が基本 関数合成のビルディングブロックになるよ 引数が複数ある関数は他の関数（map関数とか）で合成しにくい 対処方法：カリー化（関数の戻りを関数とする） addc(a: Int)(b: Int) : Int = a + b とすることで、 コツ２：分割統治 コツ３：演算は転換 flatMapとかfoldLeftとか ※永続データ構造 前に作ったデータ コツ４：オブジェクトの世界と関数の世界を分ける 更新指示書の形でObjectに渡す？ 関数型データ構造 コツ５：新しいデザインパターン 関数型プログラミングの用語 ・Functor（関手） ・Subgroup（半群） ・Monoid（モノイド） ・Monad（モナド） OOPのデザインパターン的に考えれば、数学的なところまで理解しなくてもよさそう？ ★Twitterとオープンソース　@yusukey http://dev.twitter.com http://bit.ly/tdt-ja id：twj_dev ◎OSSとの関わり 支援してます。 Apache、Eclipse、Open Invention、JCP、OpenJDK パフォーマンス系のためにもOpenJDKに参画してる ◎Twitter API オープンなAPIで無償提供 １３言語でAPIライブラリがあるよ ◎Twitter4Jのこれまで ほぼ全てをカバー APIはだいぶ落ち着いてきていて、追加変更は少なくなってる。 ◎立ち位置 Twitterはコミュニティを活発にするためにもライブラリを出さないらしい。 ◎Twitter4Jのこれから キャッシング ストリーミングAPI利用を簡単に モックテスト レートリミットの影響を受けると辛いから。。。 ツイート/ユーザの永続化機能 jClouds対応？ ライブラリからフレームワークへ 半公式ライブラリへ github/twitter/twitter4jへ JSR Social API Twitter4Jが参照実装に？？？ スケーラビリティの話。 Hadoopはユーザのデータ解析とかに使ってる。 メッセージはキューイングしている。デモ。 memcachedプロトコルなんだけど、値を取ると値が消えるよ。（memcachedとは動きが違うよねー。プロトコル的にはクライアントがいっぱいあっていいよねー） RubyのGCがきつかったのでJavaベースに変更 Kestrel（Scalaで記述。） Kestrelのフォーカス外 メッセージの順序保証（してないよ） トランザクション memcachedプロトコルの拡張１ ブロックフェッチ コンシューマから取りに行くというのが特徴 memcachedプロトコルの拡張２ リライアブルフェッチ ということで感想。\nScalaは前から気になっていて、本までかってるのになかなか手を付けられていない始末でした。 そんな時にこのJJUGの話があったので、ちょうどいいと聞きに。 関数型やScalaのぼんやりしたイメージのみを持って聴いていたのですが、思った以上にキーワードが多くてついていくのがやっとというイメージ。 で、いつものごとく、Twitterでつぶやいていた所、色々な反応が。（わからずにつぶやいたのもあり、波紋を呼んだ模様） お陰で、Scala関連の方たちをフォローできたので結果オーライでした。 話の内容自体はサラっとながす感じだったので、再度資料を見る＋Scalaをもっと勉強しないと理解出来ないなぁという印象でした。 ちなみに、資料はこちら。\n次は、最近Twitterの中の人になった山本さん（@yusukey）の話しを聞きました。 Twitter4Jの話と、TwitterのOSSへの関わりの話。あとは、実際にTwitterが作成しているOSSのひとつKestrelについて。 TwitterはRubyベースで色々と作ってきていたのだが、Java（JVM上で動く言語（Scalaなど））に徐々にシフトしているというのが一番の印象です。あとは、Lucene、Hadoopなど私の興味のあるOSSも利用しているなど。 Kestrelについてはデモを交えながら、実際の動きを説明されていたのでとてもわかり易かったです。 プレゼン中もTweetを表示しながらという、さすがTwitterの中の人という印象でした。 Twitterでは少し前から知り合いだったのですが、実際にお会いできた（イケメンでしたよ！）のも収穫でした。 次はStormの話も聞きたいかなぁ\nで、２セッション（山本さんの話のあとにLT大会にも参加）だけですが、全体の感想を。 「クロスコミュニティカンファレンス」というだけあり、Java以外の話題（CouchDBとか名前がありました）もちらほらあったようです。 ただ、最近の他の勉強会やカンファレンスに比べると人が少ない印象でした。 私が参加したセッションは比較的大きな部屋だったせいもあり、40～50人くらい入っていたと思うのですが、ガラガラな印象でした。良い意味で、Javaも安定してきているため、参加者が少なかったのかなぁと あとは、年齢層がHadoopなどに比べると高めかなぁという印象（かく言う私も年齢層を上げている一人ですが。。。）。Javaも長いですからねぇ。 午前中から参加していると違った印象だったかもしれないですが。。。 あと、初めて行った会場で、しかも大きめの施設でした。午後の途中から行ったせいもあるかもしれないですが、 案内が出ていなくて若干迷子に。。。 ただ、セッションの部屋自体は各席に机があり、電源も比較的多めにあったので、PC持ち込みでメモを取るには最適でした。\n","date":1318922443,"dir":"post/2011/","id":"5d827a1e8ea70edb11d946b54f076cae","lang":"ja","lastmod":1318922443,"permalink":"https://blog.johtani.info/blog/2011/10/18/jjug-ccc-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-10-18T16:20:43+09:00","summary":"JJUG CCC 2011 Fallに参加してきました。 個人的にはかなり久々のJavaのカンファレンスです。（※あくまで「Javaの」という話で。SolrやHad","tags":["備忘録"],"title":"JJUG CCC 2011 Fallに参加してきました。(Jugemより移植)"},{"contents":"昨日、文章から特定の単語（リストあり）を探したいという話を聞き、lucene-gosenでもできるねぇという話になりました。 まぁ、考えてみればごくごく当たり前なのですが。。。（その筋の方たちにしてみれば常識なのかもしれないですが。。。） 一応やってみたので、こんなこともできるなという一例ですということで、記録を残しておきます。\n今回の例文として野田首相の所信表明演説の一部を活用させてもらいます。 単語のリストは次のようにします。\n内閣総理大臣 正心誠意 東日本 日本 今回も結果をわかりやすくするためにSolrのanalysis画面を利用します。 作業手順は以下のとおり。\ndictionary.csvの編集 辞書のコンパイル fieldTypeの定義（Solrのschema.xmlの設定） 文章からキーワード抽出（Solrのanalysis画面） ### **1.dictionary.csvの編集** 今回はnaist-chasenディレクトリで作業します。 なお、今回利用するlucene-gosenは[ここ](http://johtani.jugem.jp/?eid=21)で紹介した辞書分離バージョンです。（はやくtrunkにコミットせねば。。。） dictionary.csvを先ほど上げた単語だけのエントリに変更します。 キーワードだけを抽出したいので、他の単語は必要ないからです。 ``` \u0026ldquo;内閣総理大臣\u0026rdquo;,1,名詞,一般,,,,,\u0026ldquo;内閣総理大臣\u0026rdquo;,\u0026ldquo;ナイカクソウリダイジン\u0026rdquo;,\u0026ldquo;ナイカクソウリダイジン\u0026rdquo; \u0026ldquo;正心誠意\u0026rdquo;,1,名詞,一般,,,,,\u0026ldquo;正心誠意\u0026rdquo;,\u0026ldquo;セイシンセイイ\u0026rdquo;,\u0026ldquo;セイシンセイイ\u0026rdquo; \u0026ldquo;東日本\u0026rdquo;,1,名詞,一般,,,,,\u0026ldquo;東日本\u0026rdquo;,\u0026ldquo;ヒガシニホン\u0026rdquo;,\u0026ldquo;ヒガシニホン\u0026rdquo; \u0026ldquo;日本\u0026rdquo;,1,名詞,一般,,,,,\u0026ldquo;日本\u0026rdquo;,\u0026ldquo;ニホン\u0026rdquo;,\u0026ldquo;ニホン\u0026rdquo;\n\u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; ### **2.辞書のコンパイル** 先ほど作成した辞書をコンパイルし、lucene-gosen用バイナリ辞書を作成します。 $ cd $LUCENE_GOSEN_HOME¥dictionary $ ant -Ddictype=naist-chasen clean-sen compile\n\u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; ### **3.fieldTypeの定義（Solrのschema.xmlの設定）** Solrのschema.xmlにlucene-gosenを利用するフィールドタイプを定義します。 追加するのは次の通り \u0026lt;fieldType name=\u0026quot;text_ja\u0026quot; class=\u0026quot;solr.TextField\u0026quot; positionIncrementGap=\u0026quot;100\u0026quot; autoGeneratePhraseQueries=\u0026quot;false\u0026quot;\u0026amp;gt; \u0026lt;analyzer\u0026amp;gt; \u0026lt;tokenizer class=\u0026quot;solr.JapaneseTokenizerFactory\u0026quot; compositePOS=\u0026quot;compositePOS.txt\u0026quot; dictionaryDir=\u0026quot;keyword-dic\u0026quot;/\u0026amp;gt; \u0026lt;filter class=\u0026quot;solr.JapanesePartOfSpeechKeepFilterFactory\u0026quot; tags=\u0026quot;keeptags_ja.txt\u0026quot; enablePositionIncrements=\u0026quot;true\u0026quot;/\u0026amp;gt; \u0026lt;/analyzer\u0026amp;gt; \u0026lt;/fieldType\u0026amp;gt; また、ここで定義しているcompositePOS.txt、keeptags_ja.txtは次のようになります。 compositePOS.txt 未知語\nkeeptags_ja.txt 名詞-一般\n未知語がバラバラに出現しないようにして見やすくするためと、必要な単語（今回は「名詞-一般」しか利用しないため。）だけを抽出したいための設定です。 \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; **### 4.文章からキーワード抽出（Solrのanalysis画面）** あとは、analysis画面で解析して見るだけになります。 ということで、辞書に登録された単語だけが抽出されてますね。 この例ではインデックスに登録となりますが。 ただし、「東日本」「日本」のような一部を含む単語の場合、「東日本」が見つかった場合は「日本」は抽出されません。 あくまでも、ベストな解が見つかるのみという形です。 すべての単語を出したい場合はもう少しやり方を考えたほうがいいかもしれません。 （まぁ、このやり方でキーワードを抽出するかも考えたほうがいいかもしれませんが。。。） \u0026lt;/div\u0026gt; 最近、頭が硬くなってきてるなぁと実感してしまいました。まぁ、こんな使い方もあるかなぁと。 もっと頭を柔らかくして問題を解けるけるようになりたいなぁと。 ","date":1318389420,"dir":"post/2011/","id":"b9d4f73fa7ca8ef66891554b66b2cded","lang":"ja","lastmod":1318389420,"permalink":"https://blog.johtani.info/blog/2011/10/12/lucene-gosen%E3%81%A7%E6%96%87%E7%AB%A0%E3%81%8B%E3%82%89%E3%82%AD%E3%83%BC%E3%83%AF%E3%83%BC%E3%83%89%E6%8A%BD%E5%87%BA%E3%82%A4%E3%83%AC%E3%82%AE%E3%83%A5%E3%83%A9%E3%83%BC/","publishdate":"2011-10-12T12:17:00+09:00","summary":"昨日、文章から特定の単語（リストあり）を探したいという話を聞き、lucene-gosenでもできるねぇという話になりました。 まぁ、考えてみれ","tags":["lucene-gosen"],"title":"lucene-gosenで文章からキーワード抽出（イレギュラー？）(Jugemより移植)"},{"contents":"ちょっと間があいてしまったが、ようやくIoの1日目を終了。 なれない感じの言語なので苦労しました。 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大募集です。コメント欄にどしどしコメントください。そこは違うだろ？こっちのほうがいいのでは？という感じで。\n感想： プロトタイプ言語であり、すべての言語はクローンだそうです。\n○手始めに スロット、オブジェクトのクローンについて。 メッセージとその送信について。 あくまでもオブジェクトだけの世界。クローンであり、クラスのインスタンスではない。（まだつかめない。。。） ### ○オブジェクト、プロトタイプ、継承 slotNamesで取れないけど、継承してる。クローンで元をコピーしてるだけか？ 頭文字が大文字かどうかがtypeかどうかの違い。大文字＝type（クラスもどき＝） オブジェクト＝スロットの入れ物 オブジェクトのクローン＝オブジェクトのチェーン？（Object ＝＞ Vehicle ＝＞ Car ＝＞ ferrari） 疑問点： 存在しないスロット名をgetSlot()で呼び出したら？＝＞nilが返る 存在しないスロットをメッセージとして送信したら？＝＞Exceptionが出る ○メソッド method()で定義 メソッドもオブジェクト＝スロットに入れることができる（まだつかめない。。。） メソッドをスロットから呼び出すと実行される。 ○リストとマップ リスト、マップは簡単。幾つか（スタックやキュー）のメソッドも用意されてる。 ○true、false、nil、singleton cloneメソッドを最定義することでsingletonの動作にする。（言われてみれば当たり前か） Object cloneをオーバーライドすることもできるが、プロセス停止などしないとダメ。（恐るべし。。。） ○インタビュー SIMD（Single Instruction Multiple Data）http://ja.wikipedia.org/wiki/SIMD やりながら感想： シンタックスが全然違うのでかなり戸惑い。 ただ、考え方はシンプル。slotとか。 まだ、予約語がわかってない（cloneとかprintとかslotNamesとか）ので。 ★セルフスタディ （探してみよう） ○Ioのいくつかの問題点の例 見つけられず。。。英語がダメダメ。。。　○質問に答えてくれるIoコミュニティ\nML：http://tech.groups.yahoo.com/group/iolanguage/ twitter：http://twitter.com/#!/iolanguage **○Ioのイディオムに関するスタイルガイド** Io Note（英語） [http://iota.flowsnake.org/](http://iota.flowsnake.org/) Ioプログラミングガイド [http://iolanguage.com/scm/io/docs/IoGuide.html](http://iolanguage.com/scm/io/docs/IoGuide.html) [http://xole.net/docs/IoGuide_ja.html](http://xole.net/docs/IoGuide_ja.html)（日本語） Ioスタイルガイド [http://en.wikibooks.org/wiki/Io_Programming/Io_Style_Guide](http://en.wikibooks.org/wiki/Io_Programming/Io_Style_Guide) [http://d.hatena.ne.jp/katzchang/20080819/p1](http://d.hatena.ne.jp/katzchang/20080819/p1)（日本語訳してくれてるブログ） （確認してみよう） ○1 + 1を評価してから、1 + \u0026ldquo;one\u0026quot;を評価する。Ioは強く型付けされた言語か？\n``` Io\u0026gt; 1 + 1 ==\u0026gt; 2 Io\u0026gt; 1 + \u0026ldquo;one\u0026rdquo;\nException: argument 0 to method \u0026lsquo;+\u0026rsquo; must be a Number, not a \u0026lsquo;Sequence\u0026rsquo; message \u0026lsquo;+\u0026rsquo; in \u0026lsquo;Command Line\u0026rsquo; on line 1\nということで、型付けは強いです。 \u0026lt;/div\u0026gt; **○0は真か偽か？空文字列はどうか？nilは真か偽か？** \u0026lt;div\u0026gt; Io\u0026gt; 0 ==\u0026gt; 0 Io\u0026gt; true and 0 ==\u0026gt; true Io\u0026gt; true and \u0026quot;\u0026rdquo; ==\u0026gt; true Io\u0026gt; \u0026quot;\u0026quot; ==\u0026gt; Io\u0026gt; true and nil ==\u0026gt; false Io\u0026gt;\n0、空文字列はtrue、nilはfalseでした。 \u0026lt;/div\u0026gt; **○プロトタイプに存在するスロットを確認するにはどうすればよいか？** \u0026lt;div\u0026gt; Io\u0026gt; Highlander := Object clone ==\u0026gt; Highlander_0x1a233a0: type = \u0026ldquo;Highlander\u0026rdquo;\nIo\u0026gt; hoge := Highlander clone ==\u0026gt; Highlander_0x1a83630:\nIo\u0026gt; hoge proto slotNames ==\u0026gt; list(type) Io\u0026gt; Highlander name := \u0026ldquo;arnold\u0026rdquo; ==\u0026gt; arnold Io\u0026gt; hoge slotNames ==\u0026gt; list() Io\u0026gt; hoge proto slotNames ==\u0026gt; list(type, name) Io\u0026gt; Highlander slotNames ==\u0026gt; list(type, name) Io\u0026gt; hoge name ==\u0026gt; arnold Io\u0026gt; hoge getSlot(\u0026ldquo;name\u0026rdquo;) ==\u0026gt; arnold\nこんな感じ。slotNamesでスロット名を確認し、スロット内部についてはgetSlotで確認できます。 \u0026lt;/div\u0026gt; **○等号（=）、コロン等号（:=）および、コロンコロン等号（::=）の違いはなにか？どのようなときに使うか？** \u0026lt;div\u0026gt; \u0026lt;table class=\u0026#34;list_view\u0026#34;\u0026gt; \u0026lt;thead\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;th\u0026gt;演算子\u0026lt;/th\u0026gt; \u0026lt;th\u0026gt;説明\u0026lt;/th\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;/thead\u0026gt; \u0026lt;tbody\u0026gt; \u0026lt;tr class=\u0026#34;spec\u0026#34;\u0026gt; \u0026lt;td\u0026gt;:::=\u0026lt;/td\u0026gt; \u0026lt;td\u0026gt;スロットへの代入＋setterの追加\u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr class=\u0026#34;specalt\u0026#34;\u0026gt; \u0026lt;td class=\u0026#34;alt\u0026#34;\u0026gt;:=\u0026lt;/td\u0026gt; \u0026lt;td class=\u0026#34;alt\u0026#34;\u0026gt;スロットへの代入\u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr class=\u0026#34;spec\u0026#34;\u0026gt; \u0026lt;td\u0026gt;=\u0026lt;/td\u0026gt; \u0026lt;td\u0026gt;スロットへの代入（ただし、スロットが存在しない場合は例外が発生）\u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;/tbody\u0026gt; \u0026lt;/table\u0026gt; とまぁ、記載したが、実際に動かして確認しました。 Io\u0026gt; Highlander := Object clone ==\u0026gt; Highlander_0x223b800: type = \u0026ldquo;Highlander\u0026rdquo;\nIo\u0026gt; hoge := Highlander clone ==\u0026gt; Highlander_0x21acd60:\nIo\u0026gt; hoge slotNames ==\u0026gt; list() Io\u0026gt; hoge name ::= \u0026ldquo;arnold\u0026rdquo; ==\u0026gt; arnold Io\u0026gt; hoge slotNames ==\u0026gt; list(setName, name) Io\u0026gt; hoge sword := \u0026ldquo;long sword\u0026rdquo; ==\u0026gt; long sword Io\u0026gt; hoge slotNames ==\u0026gt; list(setName, name, sword) Io\u0026gt; hoge clothes = \u0026ldquo;armor\u0026rdquo;\nException: Slot clothes not found. Must define slot using := operator before updating. message \u0026lsquo;updateSlot\u0026rsquo; in \u0026lsquo;Command Line\u0026rsquo; on line 1\n\u0026lt;/div\u0026gt; ### （試してみよう） **○ファイルからIoプログラムを実行せよ** \u0026lt;div\u0026gt; ファイル「great.io」を作成し、以下を入力。 Highlander := Object clone Highlander giveWarCry := \u0026ldquo;Woooooooo!!\u0026rdquo; println Highlander giveWarCry()\nで、以下のコマンドを実行する。 $ io great.io Woooooooo!!\n\u0026lt;/div\u0026gt; **○スロットの名前を指定して格納されているコードを実行せよ** \u0026lt;div\u0026gt; Io\u0026gt; Masason := Object clone ==\u0026gt; Masason_0x20ae7d0: type = \u0026ldquo;Masason\u0026rdquo;\nIo\u0026gt; Masason recieveNiceTweet := method(\u0026ldquo;やりましょう\u0026rdquo; println) ==\u0026gt; method( \u0026ldquo;やりましょう\u0026rdquo; println ) Io\u0026gt; Masason getSlot(\u0026ldquo;recieveNiceTweet\u0026rdquo;) ==\u0026gt; method( \u0026ldquo;やりましょう\u0026rdquo; println ) Io\u0026gt; Masason getSlot(\u0026ldquo;recieveNiceTweet\u0026rdquo;) call やりましょう ==\u0026gt; やりましょう\ncallとgetSlotが鍵ですね。 \u0026lt;/div\u0026gt; 1日目の途中で間があいてしまったのでシンタックスを忘れてしまう始末。。。 ただ、そんなに込み入った記述もないので、最初に勉強することは少ないかもしれないです。 まだメソッドをあとから追加とか、cloneしたあとにまたプロトタイプを変更して反映可能など、考え方になれないもところがありますが、良い頭の体操になってます。 間を置かずに3日目まで行かないと！！ ","date":1317990120,"dir":"post/2011/","id":"dc962e34780f0374b7eb3d583f6d7eb6","lang":"ja","lastmod":1317990120,"permalink":"https://blog.johtani.info/blog/2011/10/07/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-1%E6%97%A5%E7%9B%AE/","publishdate":"2011-10-07T21:22:00+09:00","summary":"ちょっと間があいてしまったが、ようやくIoの1日目を終了。 なれない感じの言語なので苦労しました。 今回もセルフスタディの私の回答が最後の方に記","title":"「7つの言語　7つの世界」 Io 1日目(Jugemより移植)"},{"contents":"久々に、MBAの備忘録です。 あれから色々入れました。 なので、入れたソフトの一覧を追加。\nAIR：TweetDeckをインストールするのに必要だったため TweetDeck（AIR版）：TwitterとFacebookを同じ画面で見ることができるため。 TextWrangler：テキストエディタ（まだあんまり使ってない） Skitch：Evernoteに買収されて無料に。先日のSolr管理画面の説明書きにもちょっと使用 ClamXav：フリーのセキュリティソフト。 SourceTree：Twitterで知ったMac用のgit、mercurialのクライアントソフト。AtlassianがSourceTreeを買収したのを機に一時的に無料公開されていたので。 Firefox：基本はSafariを使ってます。WindowsではChromeを使ってます。ただ、Webページを表示されていない部分もまるごとキャプチャするのにChromeのプラグインだとダメだったので入れました。今のところキャプチャ用のブラウザです。 Full Screen enable for Eclipse on Lion：Eclipseをフルスクリーン対応するためのプラグイン MercurialEclipse：bitbucketにアカウントをもっているので。 mercurial：pipを使ってインストール。MercurialEclipseでコマンドが必要だから。「sudo pip install Mercurial」 pip：mercurialをインストールするためにインストール。「sudo easy_install pip」でインストール iStat pro（ウィジェット）：CPUなどの情報を表示するウィジェット。ウィジェットがアップルのサイト（AppStoreではない）から検索できるというのを人から聞いた。ウィジェットってあんまり使われないのか？ Mac Blu-ray Player：現時点で有料ソフトはこれだけ。こちら。もともとNASのデータのバックアップ用にBlu-rayのドライブ買ったんですが、せっかくだからMacにも使ってみようと思い、MacでBlu-rayを見るために購入しました。所用で長距離移動もあったので、新幹線で映画見てました。 このくらいです。 ほんとはリンクを貼ればいいのですが、そこまでの元気がないので、ご勘弁を。\nSkitchがおすすめです。簡単に画像編集＋説明書きが入れられて、矢印などがよくある画像編集の野暮ったさがないので、画面キャプチャに説明書くのに今後活躍する予定です。\nあと、ソフトではなく、サービスなのですが、Cacooというサービスが便利です。 ここ最近、ちょっとした作図にはこのサービスを使うようにしています。オンラインで利用できるので、いろんな場所で編集できます。 また、図の作成もさることながら、図を共有することが可能です。 先日は、lucene-gosenが思ったように動かないという相談を受けて、このCacooでanalysis画面や設定をを貼ってもらったりしながら使いました。結構便利ですね。 ただ、付属のチャットを使ったのですが、このチャットの内容がテキスト形式でコピー出来なかったのが残念でした。今後の改修に期待ということで。\nあと、セットアップとは少し違いますが、ジャケット買ってつけました。 ステッカーを直接貼るのがちょっと気になったので、ジャケットつけてステッカーを貼ってます。 ただ、ステッカーは思ったよりチープな感じが。。。ジャケットの中に貼らないとダメだったかも。まぁ、それが嫌でジャケット買ったんですが。。。 エアージャケットセット for Macbook Air 13inch(クリア)PMC-81 ","date":1317968700,"dir":"post/2011/","id":"de1ab82817c0fb24e591b9a89a82f736","lang":"ja","lastmod":1317968700,"permalink":"https://blog.johtani.info/blog/2011/10/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%94/","publishdate":"2011-10-07T15:25:00+09:00","summary":"久々に、MBAの備忘録です。 あれから色々入れました。 なので、入れたソフトの一覧を追加。 AIR：TweetDeckをインストールするのに必要だ","tags":["備忘録"],"title":"MBAセットアップ備忘録その４(Jugemより移植)"},{"contents":"Lucene/SolrのMLでSolrの管理画面を新しくするというチケットが流れていたのでちょっと触って見ました。 ほんとにちょっと触っただけですが、いくつかキャプチャ撮ってみたので、アップしときます。 ※以下ではサムネイル画像に元画像（100Kくらいの画像）へのリンクが設定されています。携帯などでは見づらいかもしれませんが、ご容赦を。\nURLは旧管理画面とことなり、http://localhost:8983/solr/になります。\nまずはトップ画面 ダッシュボードと呼ばれるトップ画面。メモリの利用率や起動してからの時間、Luceneなどのバージョンが表示されます。 次は検索画面すっきりしてます。facetが指定できるようになったのは大きいかな。ただし、facet.fieldを複数指定などができないが。結果についてはとくに指定がなければXMLで帰ってきます。ただ、パラメータの追加ができなくなってる気がするなぁ ちなみに、Solrを止めて検索したらこんな感じの画面になりました。クエリの実行ならこのようにエラーがわかったのですが、停止後に左のメニューにあるSchemaなどをクリックしても白い画面が出るだけで、エラーかどうかがわかりにくいです。 Analysis画面。入力画面がシンプルになりました。フィールド名はリストで表示されるので選択するだけです。あとは、これまでどおり。サンプルはlucene-gosenの解析結果です。ハイライトもきちんと表示されます。ただし、長い文章の場合は結果部分だけがスクロールできる形になり、ちょっとわかりにくかったです。 Analysisの入力画面を表示したあとにSolrを停止して解析してみたらこんなエラー画面が出ました。ちなみに、その後、画面を切り替えずにSolrを起動して解析したら、赤い帯のエラーは出たままでした。一度別画面にすれば、元に戻りますが。 Pluginsの画面（旧管理画面のstatisticsに相当）。 キャッシュの状態が確認できます。今まであった画面と情報的には一緒かと。一段カテゴリ（CACHEとかCOREとか）の選択ができるようになり、見やすくなりました。 同じくPluginsの画面。 こちらはupdateHandlerについての情報です。commit数やoptimizeの回数、updateして、commitする前の状態のドキュメント数などが表示されます。前より表示される項目が多くなってるかな？ 最後はスキーマブラウザこの画面が一番良くなっています。旧管理画面では、フィールド名がすべて大文字で表示され、しかもソートがされていない状態だったため、ダイナミックフィールドを利用しているとフィールドを探すのが一苦労でした。 今回は、プルダウンでフィールドやフィールドタイプのリストが表示され、辞書順で並んでいます。Filterなどもわかりやすい表示になっているかと。 おまけ Solritasと呼ばれるVelocityを使った、3.x系で入ってきた新しいサンプル画面です。URLはhttp://localhost:8983/solr/browseです。ファセットなどを使った簡単なサンプル画面なので、検索結果画面でこんなことができるというデモにも使えるかと。ただ、これも旧管理画面よりはましですが、デザインが。。。 とまぁ、簡単ですが、4.x系の管理画面をいくつか触ってみて、キャプチャをとって見ました。 デザインは前よりもすっきりしています。ただ、クエリについてはパラメータの追加ができなくなっているので、もう少し改良されるといいかなぁ（自分でやれよと言われそうですが。。。）\n","date":1317811380,"dir":"post/2011/","id":"09677934e13a5d728f00c6ed7c8870a9","lang":"ja","lastmod":1317811380,"permalink":"https://blog.johtani.info/blog/2011/10/05/solr%E3%81%AE%E6%96%B0%E3%81%97%E3%81%84%E7%AE%A1%E7%90%86%E7%94%BB%E9%9D%A2solr4-x-trunk%E7%B3%BB/","publishdate":"2011-10-05T19:43:00+09:00","summary":"Lucene/SolrのMLでSolrの管理画面を新しくするというチケットが流れていたのでちょっと触って見ました。 ほんとにちょっと触っただけ","tags":["solr"],"title":"Solrの新しい管理画面（Solr4.x trunk系）(Jugemより移植)"},{"contents":"遅くなりましたが、続きです。 さらに英語力のなさを痛感して凹んでいるところですが、何かの役に立てばと恥を晒すところです。。。\n一応、訳してみたのですが、訳すのに必死になってしまい、つながりがわかっていない点もちらほら。 このあと一旦見直しつつ、再度理解する「理解編」をアップしようかと思います。 できれば、シーケンス図とかも交えつつ。（そうしないと理解ができない可能性が。。。） 前回同様、原文は最後に付加しておきます。\nBoot Strapping Cluster Startup（クラスタの起動） ノードはZookeeperのホストとポートを指定することから始めます。 クラスタの最初のノードはクラスタのschema/configとクラスタの設定を指定するとこから開始します。 最初のノードはZookeeperに設定をアップロードしてクラスタをブートします。 クラスタは「ブートストラップ」状態です。 この状態ではノード-\u0026gt;パーティションマッピングは計算されず、クラスタはクラスタ管理コマンド以外のどんなread/writeリクエストも受け付けません。\nクラスタの最初のノード集合が起動した後、クラスタ管理コマンド（TBD記述？？？）が管理者によって発行されます。このコマンドは整数「partitions」パラメータを受け取り、次のステップを実行します。\nCluster Lockを取得 「partitions」をパーティション数として割り当て 各パーティションのためのノードを取得 ZooKeeperのノード-\u0026gt;パーティションマッピングを更新 Cluster Lockをリリース 全ノードに対して最新版のノード-\u0026gt;パーティションマッピングをZooKeeper経由で更新させる Node Startup ノードが起動すると、自分がすでに存在するシャードの一部かどうかZooKeeperでチェックします。 もし、ZooKeeperがノードのレコードを持っていない、またはどのシャードの一部でもないと判断したら、 ノードは後述の「New Node」のステップを実行します。すでに存在するノードの場合は後述の「Node Restart」のステップを実行します。\nNew Node\n新しいノードはクラスタの一部ではなく、クラスタのキャパシティを増強するためのものです。\n「auto_add_new_nodes」クラスタプロパティが「false」の場合、新しいノードはZooKeeperに「idle」として登録され、他のノードが参加してくれと言うまで待機します。 そうでない場合（auto_add_new_nods=true）は次のステップを実行します。\nCluster Lockを取得します。 適切なnode-\u0026gt;partitionエントリを選び出します。 利用可能なパーティションのリストをスキャンして「replication_factor」のノード数以下のパーティションのエントリを探します。複数ある場合はノード数が最小のエントリを選びます。それも一緒ならランダムに選びます。 全パーティションが「replication_factor」以上のノードを持っている場合、ノードはパーティションが最も多いものをスキャンします。複数ある場合はパーティション内のドキュメント数が最大のエントリを選びます。ドキュメント数が同一なら任意のエントリを選びます。 もし、選んだノード-\u0026gt;パーティションエントリを現在のノードに移動させることでがクラスタのパーティション：ノード比率の最大値を小さくするなら、現在のエントリを返します。。それ以外の場合選ばれたエントリがないので、アルゴリズムは終了です。。 ZooKeeper内のノード-\u0026gt;パーティションマッピングを更新します ZooKeeper内のノードステータスを「リカバリ」状態にします Cluster Lockをリリースします 「リカバリ」はパーティションのリーダーから開始します。 リカバリが終了したら、再度、Cluster Lockを取得します。 元のエントリはZooKeeperのノード-\u0026gt;パーティションマッピングから削除されます。 Cluster Lockをリリースします 元のノードはZooKeeperからノード-\u0026gt;パーティションマッピングを更新させられます ステップ1に戻ります。 Node Restart ノードの再起動とは次のいずれかを意味しています。\nJVMがクラッシュし、手動または自動でのリスタート ノードが一時的にネットワークから切り離された。もしくは、ZooKeeperに接続できなかった（死んでいると思われた）。または、ある一定期間、リーダーからの更新を受信できなかった。 このシナリオが表す書き込み処理のライフサイクルの間にネットワークから分断された ハード故障もしくはメンテナンスウインドウによりクラスタからノードが分断され、ノードをクラスタにrejoinさせるために起動した。 ノードが各パーティションに対してメンバーであるパーティションのリストを読み、パーティションのリーダーがリカバリプロセスを実行する。その時、ノードは「auto_add_new_nods」プロパティをチェックして、「New Node」処理のステップを実行する。 これはクラスタが。。。（元の文章が切れてて意味が不明）\nクライアントは標準的なSolrの更新形式を利用して書き込みできます。 書き込み処理はクラスタの任意のノードに送信されます。 ノードはハッシュ関数を利用して、どのパーティションに所属するか決めるためにrange-パーティションマッピングを使います。 ZooKeeperはシャードのリーダーを識別して、書き込み処理をそこに送ります。 SolrJはリーダーに対して書き込みを直接送信するための拡張がされています。\nリーダーはPartitionバージョンの操作を割り当て、そのトランザクションログの操作を書き込み、シャードに属する他のノードにドキュメントバージョンハッシュを転送します。 ノードはインデックスにドキュメントハッシュを書き込み、トランザクションログに操作を記録します。 リーダーは、min_writesの最小数のノード以上のノードが「OK」とレスポンスを返したら「OK」とレスポンスを返します。 クラスタプロパティのmin_writesは書き込みリクエスト時に指定することで、異なる値を指定できます。\nクラウドモードはコミット/ロールバック操作を明示的には行いません。 コミットは特定の間隔で（commit_within）リーダーによりオートコミットにより管理されます。 また、シャードの全メンバーのコミットはトリガーにより管理されます。 ノードが利用可能な最新バージョンはコミットの時点で記録されます。\nTransaction Log トランザクションログは2つのコミットの間にインデックスに対して実行された操作全てを記録したもの コミットはそれ以前に実行された操作の耐久性を保証するために、新しいトランザクションログを開始します。 同期は調整が可能です。例えば、flush vs fsynです。fsyncがデフォルトで、JVMクラッシュに対して保証できるが、電源異常の場合には保証できないが、速度的には早いです。 Recovery 次のトリガーにより復旧が可能です。\nBootstrap パーティション分割 クラスタの再構築 ノードは自身に「recovering」というステータスを設定して復旧を開始します。 このフェーズの間、ノードは読み込みリクエストを受けることができませんが、トランザくkションログに書きこまれるすべての新しい書き込みリクエストを受け取ります。 ノードは自身が持つインデックスのバージョンを調べて、パーティションの最新バージョンのリーダーに問い合わせます。 リーダーはシャード内の残りのノードと同期する前に実行されるべき操作の集合を返します（？？？）。\n最初にインデックスをコピーし、最新のノードにあるトランザクションログをリプレイします。 もし、インデックスのコピーが必要ならば、インデックスファイルをローカルにまずコピーし、その後トランザクションログをリプレイします。 トランザクションログのリプレイは通常の書き込みリクエストの流れと同じです。 この時、ノードは新しい書き込みを受け付けるかもしれません。その書き込みはインデックスに再生されるべきです。 ある時点でノードは最新のコミットポイントに追いつき、自身のステータスを「ready」にします。 この時点で、このノードは読み込みリクエストを処理できます。\nHandling Node Failures 一時的にネットワークが分断され、幾つかのノードとZooKeeperの間の通信が遮断されるかもしれません。 クラスタはデータの再構築（リバランシング）の前にしばらく待ちが発生します。\nLeader failure\nノードが故障し、もしそれがシャードのリーダだった場合、他のメンバーがリーダー選出のプロセスを開始します。 新しいリーダーが選出されるまで、このパーティションへの書き込みは受け付けられません。 この時、これはリーダー以外の故障ステップを処理します。（？？？）\nLeader failure\nシャードの一部に新しいノードが割り当てられる前にリーダーはmin_reaction_timeの間待ちます。 リーダーはCluster Lockを取得し、シャードの新規メンバーとしてノードを割り当てるためのノード-シャード割り当てアルゴリズムを使用します。 ZooKeeperのノード-\u0026gt;パーティションマッピングが更新され、Cluster Lockがリリースされます。 新しいノードはZooKeeperからノード-\u0026gt;パーティションマッピングを強制的にリロードされます。\nSplitting partitions 明示的なクラスタ管理コマンドもしくはSolrによる自動的な分割戦略（ストラテジ）はパーティションを分割することができます。 明示的な分割コマンド（split command）は対象となるパーティションを分割するために実行されます。\nパーティションXが100から199のハッシュの範囲を持つものとし、X（100から149）、Y（150～199）に分割するとします。 Xのリーダーは、XとYの新しい値の範囲をZooKeeperに分割アクションを記録します。 ノードはこの分割アクションもしくは新しいパーティションの存在については通知を受けません。（？？？）\nXのリーダはCluster Lockを取得し、パーティションY（アルゴリズムはto be determined）を割り当てるノードを決定し、新しいパーティションを知らせ、パーティション-\u0026gt;ノードマッピングを更新します。Xのリーダはノードのレスポンスを街、新しいパーティションがコマンドを受付可能な状態になったら次の処理を実行します。 Xのリーダーは分割が完了するまですべてのコミットを停止します。 Xのリーダーは最新のコミットポイント（バージョンVとする）のIndexReaderをオープンし、同じバージョンのIndexReaderもオープンするように命じます XのリーダーはYのリーダーに対してバージョンV以降のトランザクションログのうちハッシュ値の範囲が150から199のものを流します。 Yのリーダーはトランザクションログの#2（#3の間違い？）で送られたリクエストだけを記録します？？？ Xのリーダーはステップ#2で開いたIndexReaderに対してインデックスの分割を開始します。 #5で作成されたインデックスはYのリーダーに送られ、登録されます。 Yのリーダーは「recovery」プロセスを開始するように（シャードの）他のノード命令し、インデックスのトランザクションログを再生し始めます。 パーティションYのすべてのノードがバージョンVに到達したならば YのリーダーはXのリーダーに#2で作成されたReaderの上に、ハッシュの範囲が100から149だけに属しているドキュメントを抽出するようにするFilteredIndexReaderを準備するように頼みます。 Xのリーダーは#8aのリクエストが完了したのを検知したら、YのリーダーがCluster Lockを取得し、クラスタ全体の検索/登録リクエストの受信を開始するためにレンジ-\u0026gt;パーティションマッピングを変更します。 YのリーダーはXのリーダーに検索リクエストのために#8aで作成されたFilteredIndexReaderの利用開始を頼みます YのリーダーはXのリーダーに、ZooKeeperからレンジ-\u0026gt;パーティションマッピングを矯正リフレッシュするように頼みます。この時点で#3で開始されたトランザクションログの流しこみが停止されるのが保証されます。 Xのリーダーは自身のパーティションに存在するべきでないハッシュ値をもつドキュメントを削除し、最新のコミットポイントのsearcherを再度開きます。 この時点で分割は完全に終了し、Xのリーダーはcommit_withinパラメータによるコミットをレジュームします（？？？） Notes:\n分割操作が完了するまで、commit_withinパラメータによるパーティションの分割は実行されない #8b開始から#8c終了までの間の分散検索は一貫しない検索結果を帰す場合がある（例えば：検索結果が異なる） Cluster Re-balancing クラスタは明示的なクラスタ管理コマンドにより再構築（リバランシング）できる。\nTBD （to be determined）\nCluster Re-balancing TBD （to be determined）\nConfiguration solr_cluster.properties これはクラスタ内の全ノードにわたって適用される一般的なSolr設定ファイルとは別のプロパティファイルの集合である。\nreplication_factor：クラスタによって管理されるドキュメントのレプリカの数 min_writes：書き込み操作が成功になる前の最小の書き込み？？？？。これは書き込みごとに上書き設定可能 commit_within：検索に現れるまでの書き込み操作の最大回数 hash_function：ドキュメントのハッシュ値を計算するための関数の実装 max_hash_value：ハッシュ関数が出力することができる最大値。理論的には、この値はクラスタが保持できるパーティションの最大数でもある min_reaction_time：起動、停止の後に再配分/分割にかかる時間（？？） min_replica_for_reaction：レプリカノード数がこの値以下になったら、min_reaction_timeにならなくても分割が実行される。 auto_add_new_nodes：booleanフラグ。もしtrueなら新しいノードは自動的にパーティションからレプリカを読み込む。そうでない場合は新しいノードはクラスタに「idle」状態で登録される Cluster Admin Commands すべてのクラスタ管理コマンドはすべてのノードでパス（/cluster_admin）を与えることで実行できます。 全ノードは同じコマンドを受け付けることができ、振る舞いも同じものになるでしょう。 以下のコマンドはユーザが利用できるパブリックなコマンドです。\ninit_cluster：（パラメータ：パーティション）このコマンドはノードの集合の初期化後に実施されます。このコマンドが実行されるまで、クラスタは読み込み/書き込みコマンドを受け付けません。 split_partition：（パラメータ：パーティション（任意））パーティションを2つに分割します。もしパーティションパラメータが指定されない場合は、ドキュメント数が最大の add_idle_nodes：このコマンドはauto_add_new_nodes=falseの場合に利用できます。このコマンドはクラスタに対して「idle」状態のすべてのノードを追加するトリガーとなります。 move_partition：（パラメータ：パーティション、from、to）fromのノードからtoの別のノードに引数で指定されたパーティションを移動します。 command_status：（パラメータ：completion_id（任意））上記コマンドはすべて非同期で実行され、completion_idを返します。このコマンドは特定の実行中のコマンドもしくは全ての実行中のコマンドの状態を表示するために利用できます。 status：（パラメータ：パーティション（任意））パーティションのリストを表示し各パーティションの次の情報を表示します。 リーダーノード ノードのリスト ドキュメント数 平均読み込み回数（reads/sec） 平均書き込み回数（writes/sec） 平均読み込み時間（time/read） 平均書き込み時間（time/write） Migrating from Solr to SolrCloud クラウドに移行するときに幾つかの特徴は不要かもしれないし、サポートされないかもしれません。 既存の（クラウドでない）バージョンでのすべての特徴をSolrCloudでサポートし続けなければなりません。\nレプリケーション：これは必要ありません。 CoreAdminコマンド：明示的なコアの操作は許可されません。内部にコアがあるかもしれないが、暗黙的に管理されるでしょう 複数スキーマのサポート？：単純化のため、ver1.0ではサポートしないかもしれない solr.xml：SolrCloudでほんとに必要？ Alternative to a Cluster Lock リーダーを選出する常設の調停ノード（masterはインデックスレプリケーションで利用している用語なので、「調停」とする）を持つほうが単純かもしれません。 「truth」状態をZookeeperの状態としてみなすような次のパターンでは、将来の柔軟性（クラスタを制御するためのZookeeperの状態を直接変更するような外部管理ツールのような）を考慮に入れることができます。 （毎回ロックを取得するよりも）調停ノードを持つことにより、よりスケーラブルになるかもしれません。 特定条件下でのみCluster Lockを利用するハイブリッドも意味があるでしょう。\nSingle Node Simplest Use Case 単一ノードでスタートして、ドキュメントをインデックス登録できないといけません。 また、あとで、クラスタに2番目のノードを追加できないと行けません。\n1つのノードから開始し、最初にZookeeperに設定ファイルをアップロードし、shard1にノードを作成＋登録します。 他の情報がない状態で設定が作成され、1つのシャードのシステムとなります。 いくつかのドキュメントをインデックスします 他のノードが起動し、「まだ割り当てられていない場合、レプリカの最小の数をもつshardに割り当てられ、「recovery」プロセスを開始します」というパラメータを受け取ります。 * 出来れば、同一ホスト上に同じシャードはコピーしない * この時点の後で、ノードが停止したら、再起動し、同じ役割が再開されるべきです。（Zookeeperでそれ自身であると判別されれば） 原文はこちらからです。\nBoot Strapping Cluster Startup A node is started pointing to a Zookeeper host and port. The first node in the cluster may be started with cluster configuration properties and the schema/config files for the cluster. The first node would upload the configuration into zookeeper and bootstrap the cluster. The cluster is deemed to be in the “bootstrap” state. In this state, the node -\u0026gt; partition mapping is not computed and the cluster does not accept any read/write requests except for clusteradmin commands.\nAfter the initial set of nodes in the cluster have started up, a clusteradmin command (TBD description) is issued by the administrator. This command accepts an integer “partitions” parameter and it performs the following steps:\nAcquire the Cluster Lock Allocate the “partitions” number of partitions Acquires nodes for each partition Updates the node -\u0026gt; partition mapping in ZooKeeper Release the Cluster Lock Informs all nodes to force update their own node -\u0026gt; partition mapping from ZooKeeper The Cluster Lock is acquired A suitable source (node, partition) tuple is chosen: The list of available partitions are scanned to find partitions which has less then “replication_factor” number of nodes. In case of tie, the partition with the least number of nodes is selected. In case of another tie, a random partition is chosen. If all partitions have enough replicas, the nodes are scanned to find one which has most number of partitions. In case of tie, of all the partitions in such nodes, the one which has the most number of documents is chosen. In case of tie, a random partition on a random node is chosen. If moving the chosen (node, partition) tuple to the current node will decrease the maximum number of partition:node ratio of the cluster, the chosen tuple is returned.Otherwise, no (node, partition) is chosen and the algorithm terminates The node -\u0026gt; partition mapping is updated in ZooKeeper The node status in ZooKeeper is updated to “recovery” state The Cluster Lock is released A “recovery” is initiated against the leader of the chosen partition After the recovery is complete, the Cluster Lock is acquired again The source (node, partition) is removed from the node -\u0026gt; partition map in ZooKeeper The Cluster Lock is released The source node is instructed to force refresh the node -\u0026gt; partition map from ZooKeeper Goto step #1 Node Restart A node restart can mean one of the following things:\nThe JVM crashed and was manually or automatically restarted The node was in a temporary network partition and either could not reach ZooKeeper (and was supposed to be dead) or could not receive updates from the leader for a period of time. A node restart ine node failure. Lifecycle of a Write Operation this scenario signifies the removal of the network partition. A hardware failure or maintenance window caused the removal of the node from the cluster and the node has been started again to rejoin the cluster. The node reads the list of partitions for which it is a member and for each partition, starts a recovery process from each partition’s leader respectively. Then, the node follows the steps in the New Node section without checking for the auto_add_new_nodes property. This ensures that the cluster recovers from the imbalance created by th\nWrites are performed by clients using the standard Solr update formats. A write operation can be sent to any node in the cluster. The node uses the hash_function , and the Range-Partition mapping to identify the partition where the doc belongs to. A zookeeper lookup is performed to identify the leader of the shard and the operation is forwarded there. A SolrJ enhancement may enable it to send the write directly to the leader\nThe leader assigns the operation a Partition Version and writes the operation to its transaction log and forwards the document + version + hash to other nodes belonging to the shard. The nodes write the document + hash to the index and record the operation in the transaction log. The leader responds with an ‘OK’ if at least min_writes number of nodes respond with ‘OK’. The min_writes in the cluster properties can be overridden by specifying it in the write request.\nThe cloud mode would not offer any explicit commit/rollback operations. The commits are managed by auto-commits at intervals (commit_within) by the leader and triggers a commit on all members on the shard. The latest version available to a node is recorded with the commit point.\nTransaction Log A transaction log records all operations performed on an Index between two commits Each commit starts a new transaction log because a commit guarantees durability of operations performed before it The sync can be tunable e.g. flush vs fsync by default can protect against JVM crashes but not against power failure and can be much faster Recovery A recovery can be triggered during:\nBootstrap Partition splits Cluster re-balancing The node starts by setting its status as ‘recovering’. During this phase, the node will not receive any read requests but it will receive all new write requests which shall be written to a separate transaction log. The node looks up the version of index it has and queries the ‘leader’ for the latest version of the partition. The leader responds with the set of operations to be performed before the node can be in sync with the rest of the nodes in the shard.\nThis may involve copying the index first and replaying the transaction log depending on where the node is w.r.t the state of the art. If an index copy is required, the index files are replicated first to the local index and then the transaction logs are replayed. The replay of transaction log is nothing but a stream of regular write requests. During this time, the node may have accumulated new writes, which should then be played back on the index. The moment the node catches up with the latest commit point, it marks itself as “ready”. At this point, read requests can be handled by the node.\nHandling Node Failures There may be temporary network partitions between some nodes or between a node and ZooKeeper. The cluster should wait for some time before re-balancing data.\nLeader failure\nIf node fails and if it is a leader of any of the shards, the other members will initiate a leader election process. Writes to this partition are not accepted until the new leader is elected. Then it follows the steps in non-leader failure\nNon-Leader failure\nThe leader would wait for the min_reaction_time before identifying a new node to be a part of the shard. The leader acquires the Cluster Lock and uses the node-shard assignment algorithm to identify a node as the new member of the shard. The node -\u0026gt; partition mapping is updated in ZooKeeper and the cluster lock is released. The new node is then instructed to force reload the node -\u0026gt; partition mapping from ZooKeeper.\nSplitting partitions A partition can be split either by an explicit cluster admin command or automatically by splitting strategies provided by Solr. An explicit split command may give specify target partition(s) for split.\nAssume the partition ‘X’ with hash range 100 - 199 is identified to be split into X (100 - 149) and a new partition Y (150 - 199). The leader of X records the split action in ZooKeeper with the new desired range values of X as well as Y. No nodes are notified of this split action or the existence of the new partition.\nThe leader of X, acquires the Cluster Lock and identifies nodes which can be assigned to partition Y (algorithm TBD) and informs them of the new partition and updates the partition -\u0026gt; node mapping. The leader of X waits for the nodes to respond and once it determines that the new partition is ready to accept commands, it proceeds as follows: The leader of X suspends all commits until the split is complete. The leader of X opens an IndexReader on the latest commit point (say version V) and instructs its peers to do the same. The leader of X starts streaming the transaction log after version V for the hash range 150 - 199 to the leader of Y. The leader of Y records the requests sent in #2 in its transaction log only i.e. it is not played on the index. The leader of X initiates an index split on the IndexReader opened in step #2. The index created in #5 is sent to the leader of Y and is installed. The leader of Y instructs its peers to start recovery process. At the same time, it starts playing its transaction log on the index. Once all peers of partition Y have reached at least version V: The leader of Y asks the leader of X to prepare a FilteredIndexReader on top of the reader created in step #2 which will have documents belonging to hash range 100 - 149 only. Once the leader of X acknowledges the completion of request in #8a, the leader of Y acquires the Cluster Lock and modifies the range -\u0026gt; partition mapping to start receiving regular search/write requests from the whole cluster. The leader of Y asks leader of X to start using the FilteredIndexReader created in #8a for search requests. The leader of Y asks leader of X to force refresh the range -\u0026gt; partition mapping from ZooKeeper. At this point, it is guaranteed that the transaction log streaming which started in #3 will be stopped. The leader of X will delete all documents with hash values not belonging to its partitions, commits and re-opens the searcher on the latest commit point. At this point, the split is considered complete and leader of X resumes commits according to the commit_within parameters. Notes:\nThe partition being split does not honor commit_within parameter until the split operation completes Any distributed search operation performed starting at the time of #8b and till the end of #8c can return inconsistent results i.e. the number of search results may be wrong. Cluster Re-balancing The cluster can be rebalanced by an explicit cluster admin command.\nTBD\nMonitoring TBD\nConfiguration solr_cluster.properties This are the set of properties which are outside of the regular Solr configuration and is applicable across all nodes in the cluster:\nreplication_factor : The number of replicas of a doc maintained by the cluster min_writes : Minimum no:of successful writes before the write operation is signaled as successful . This may me overridden on a per write basis commit_within : This is the max time within which write operation is visible in a search hash_function : The implementation which computes the hash of a given doc max_hash_value : The maximum value that a hash_function can output. Theoretically, this is also the maximum number of partitions the cluster can ever have min_reaction_time : The time before any reallocation/splitting is done after a node comes up or goes down (in secs) min_replica_for_reaction : If the number of replica nodes go below this threshold the splitting is triggered even if the min_reaction_time is not met auto_add_new_nodes : A Boolean flag. If true, new nodes are automatically used as read replicas to existing partitions, otherwise, new nodes sit idle until the cluster needs them. Cluster Admin Commands All cluster admin commands run on all nodes at a given path (say /cluster_admin). All nodes are capable of accepting the same commands and the behavior would be same. These are the public commands which a user can use to manage a cluster:\ninit_cluster : (params : partition) This command is issued after the initial set of nodes are started. Till this command is issued, the cluster would not accept any read/write commands split_partition : (params : partitionoptional). The partition is split into two halves. If the partition parameter is not supplied, the partition with the largest number of documents is identified as the candidate. add_idle_nodes : This can be used if auto_add_new_nodes=false. This command triggers the addition of all ‘idle’ nodes to the cluster. move_partition : (params : partition, from, to). Move the given partition from a given node from to another node command_status :(params : completion_idoptional) . All the above commands are asynchronous and returns with a completion_id . This command can be used to know the status of a particular running command or all the current running commands status : (params : partitionoptional) Shows the list of partitions and for each partition, the following info is provided leader node nodes list doc count average reads/sec average writes/sec average time/read average time/write Migrating from Solr to SolrCloud A few features may be redundant or not supported when we move to cloud such as. We should continue to support the non cloud version which supports all the existing features\nReplication. This feature is not required anymore CoreAdmin commands. Explicit manipulation of cores will not be allowed. Though cores may exist internally and they meay be managed implicitly Multiple schema support ? Should we just remove it from ver 1.0 for simplicity? solr.xml . Is there a need at all for this in the cloud mode? Alternative to a Cluster Lock It may be simpler to have a coordinator node (we avoid the term master since that is associated with traditional index replication) that is established via leader election. Following a pattern of treating the zookeeper state as the \u0026ldquo;truth\u0026rdquo; and having nodes react to changes in that state allow for more future flexibility (such as allowing an external management tool directly change the zookeeper state to control the cluster). Having a coordinator (as opposed to grabbing a lock every time) can be more scalable too. A hybrid model where a cluster lock is used only in certain circumstances can also make sense.\nSingle Node Simplest Use Case We should be able to easily start up a single node and start indexing documents. At a later point in time, we should be able to start up a second node and have it join the cluster.\nstart up a single node, upload it\u0026rsquo;s configuration (the first time) to zookeeper, and create+assign the node to shard1. in the absence of other information when the config is created, a single shard system is assumed index some documents start up another node and pass it a parameter that says \u0026ldquo;if you are not already assigned, assign yourself to any shard that has the lowest number of replicas and start recovery process\u0026rdquo; avoid replicating a shard on the same host if possible after this point, one should be able to kill the node and start it up again and have it resume the same role (since it should see itself in zookeeper)\n","date":1317720720,"dir":"post/2011/","id":"7052598d2355984237d126afea2f6e88","lang":"ja","lastmod":1317720720,"permalink":"https://blog.johtani.info/blog/2011/10/04/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE2/","publishdate":"2011-10-04T18:32:00+09:00","summary":"遅くなりましたが、続きです。 さらに英語力のなさを痛感して凹んでいるところですが、何かの役に立てばと恥を晒すところです。。。 一応、訳してみたの","tags":["solr"],"title":"New SolrCloud Designの翻訳（その2）(Jugemより移植)"},{"contents":"ちょっと興味があるので、訳してみました。（Wikiのページはこちら） 更新されているようなので、もとの文章も残しておきます。（ページ下部の続きはこちら部分以降） 全部訳そうと思ったのですが、終わらなかったので、まずは前半部分です。まだ、訳しただけで理解できてない。。。 （英語力のなさをさらけ出してしまうのですが、これも修行です。。。おかしいところはツッコミを。）\nWhat is SolrCloud? Solrクラウドはクラウドでの検索サービスとしてのSolrを管理、運用するための既存のSolrを拡張するものです。\n用語集 Cluster：クラスタは1単位として管理されるSolrノードの集合です。クラスタ全体で単一のschema、solrconfigをもたないといけません。 Node：ひとつのJVMインスタンスで起動しているSolrのこと Partition：パーティションはドキュメント集合全体のサブセット（部分集合）のことです。パーティションは部分集合のドキュメントが単一のインデックスに含まれるような形で作られます。 Shard：パーティションはn（＝replication factor）個のノードに保存される必要があります。このn個のノードすべてでひとつのshardです。1つのノードはいくつかのshardの一部にで有る場合があります。 Leader：各Shardは1つのリーダとなるノードを持っています。パーティションに登録されたドキュメントリーダーからコピーされます Replication Factor：クラスタによって保持されるレプリカの最小限の数 Transaction Log：各ノードによって保持される書き込み処理の追記ログ Partition version：これは各shardのリーダーが持っているカウンターで、書き込み処理ごとに増加し、レプリカに送られます。 Cluster Lock：これはrange（※後述されているハッシュ値の範囲のことか？）-\u0026gt;パーティションもしくはパーティション-\u0026gt;ノードのマッピングを変更するために取得しなければいけないグローバルなロックのことです。 ※用語だけだと関係がわかりづらかったので、図を書いてみました。\nドキュメントの集合とパーティションについての考え方\nクラスタ、ノード、シャードの考え方。\n処理原則 任意の処理はクラスタにある任意のノードに実行可能です。 リカバリできないSPOFはありません。 クラスタは伸縮自在（elastic）でなければならない 書き込みが失われないこと（耐久性）を保証する 書き込み順序が保証されなければならない 2つのクライアントが2つの「A」というドキュメントを同時に送信してきた場合、すべてのレプリカで一貫してどちらか一方が保存されなければならない。 クラスタの設定は中央管理されなければならない。また、クラスタのどのノードからもクラスタ設定が更新できます。 読み込み（検索）の自動的なフェイルオーバー 書き込み（インデクシング）の自動的なフェイルオーバー ノードの故障が発生しても自動的にrepcation factorの数は守られます。（故障したら動的にレプリカを再配置？） Zookeeper ZooKeeperクラスタは次のために使用されます。\nクラスタ設定の集中管理 分散同期に必要な操作のコーディネータ クラスタ構成を保存するためのシステム Partitioning クラスタは固定されたmax_hash_value＝「N」が設定されます。 max_hash_valueは1000のような大きな値が設定されます。\nhash = hash_function(doc.getKey()) % N ハッシュ値の範囲がパーティションに割り当てられ、ZooKeeperに保存されます。 次の例のような形で、パーティションに対して範囲が設定されます。\nrange : partition ------ ---------- 0 - 99 : 1 100-199: 2 200-299: 3 ハッシュはドキュメントにインデックスフィールドとして追加され、変更されない値です。 これは、インデックスを分割するときにも利用します。\nハッシュ関数はプラガブルです。これはドキュメントを受け取り、一貫した正整数ハッシュ値を返します。デフォルトのハッシュ関数として、必須でかつ変更されないフィールド（デフォルトはユニークキーフィールド）からハッシュ値を計算する関数が提供されます。\nUsing full hash range max_hash_valueは必ずしも必要ではありません。各shardはいずれにしろハッシュ値の範囲持っているので、完全な32 bitsハッシュを使うこともできます。 設定可能なmax_hash_valueを利用しないで、クライアントからの値をもとにハッシュ値を作ることができます。 例えば、電子メールの検索アプリでは次のようにハッシュ関数を作ることができます。\n(hash(user_id)\u0026lt;\u0026lt;24) | (hash(message_id)\u0026gt;\u0026gt;\u0026gt;8) ユーザIDから8bitのハッシュコードの先頭8ビットを利用することで、任意のユーザのメールがクラスタの同じ256番目（のノード？）にあるのを保証します。検索時はこの情報をもとにクラスタのその部分への問い合わせだけで情報が得られます。\nおそらく、私たちは最大値から最小値をカバーする範囲を表現するのにハッシュ空間を輪（固定のハッシュではなく）とみなしたいです。（？？？円状のハッシュ空間とすることで、クラスタ内のノード数の増減に耐えられるようにするよということかな？）\nshard naming シャードからハッシュ値の範囲へのマッピングを別々に管理するよりも、ハッシュコードによりパーティションを構成するときに実際にはハッシュの範囲をシャード名にします。 （シャード「1-1000」は1から1000の間のハッシュコードを持つドキュメントが含まれるという形）\n現時点では（コレクション1つに対してシングルコアの1Solrサーバと仮定して）solrコア名はコレクション名をつけるようになっています。 同一コレクションのためのマルチコアに対してのいい命名規則をつけるという課題が残っています。 （※コレクションに対する説明がここまでないかな？）\nShard Assignment ノード-\u0026gt;パーティションのマッピングはZooKeeperにあるCluster Lockを取得したノードによってのみ変更が可能です。 ノードの追加時に、まず、Cluster Lockを取得し、次にそれがどのパーティションを取得できるかを識別します。\nNode to a shard assignment 新しいノードを探しているノードはまずCluster Lockを取得しないといけません。 第一に、リーダーはシャードを決めます。 シャードが持つ、すべての利用可能なノード数で最小の値を持つノードが選び出されます。 もし、同値ならランダムにノードを選びます。\n原文はこちらからです。\nNew SolrCloud Design (Work in progress)\nWhat is SolrCloud? SolrCloud is an enhancement to the existing Solr to manage and operate Solr as a search service in a cloud.\nGlossary Cluster : Cluster is a set of Solr nodes managed as a single unit. The entire cluster must have a single schema and solrconfig Node : A JVM instance running Solr Partition : A partition is a subset of the entire document collection. A partition is created in such a way that all its documents can be contained in a single index. Shard : A Partition needs to be stored in multiple nodes as specified by the replication factor. All these nodes collectively form a shard. A node may be a part of multiple shards Leader : Each Shard has one node identified as its leader. All the writes for documents belonging to a partition should be routed through the leader. Replication Factor : Minimum number of copies of a document maintained by the cluster Transaction Log : An append-only log of write operations maintained by each node Partition version : This is a counter maintained with the leader of each shard and incremented on each write operation and sent to the peers Cluster Lock : This is a global lock which must be acquired in order to change the range -\u0026gt; partition or the partition -\u0026gt; node mappings. Guiding Principles Any operation can be invoked on any node in the cluster. No non-recoverable single point of failures Cluster should be elastic Writes must never be lost i.e. durability is guaranteed Order of writes should be preserved If two clients send document \u0026ldquo;A\u0026rdquo; to two different replicas at the same time, one should consistently \u0026ldquo;win\u0026rdquo; on all replicas. Cluster configuration should be managed centrally and can be updated through any node in the cluster. No per node configuration other than local values such as the port, index/logs storage locations should be required Automatic failover of reads Automatic failover of writes Automatically honour the replication factor in the event of a node failure Zookeeper A ZooKeeper cluster is used as:\nThe central configuration store for the cluster A co-ordinator for operations requiring distributed synchronization The system-of-record for cluster topology Partitioning The cluster is configured with a fixed max_hash_value (which is set to a fairly large value, say 1000) ‘N’. Each document’s hash is calculated as:\nhash = hash_function(doc.getKey()) % N Ranges of hash values are assigned to partitions and stored in Zookeeper. For example we may have a range to partition mapping as follows\nrange : partition ------ ---------- 0 - 99 : 1 100-199: 2 200-299: 3 The hash is added as an indexed field in the doc and it is immutable. This may also be used during an index split\nThe hash function is pluggable. It can accept a document and return a consistent \u0026amp; positive integer hash value. The system provides a default hash function which uses the content of a configured, required \u0026amp; immutable field (default is unique_key field) to calculate hash values.\nUsing full hash range Alternatively, there need not be any max_hash_value - the full 32 bits of the hash can be used since each shard will have a range of hash values anyway. Avoiding a configurable max_hash_value makes things easier on clients wanting related hash values next to each other. For example, in an email search application, one could construct a hashcode as follows:\n(hash(user_id)\u0026lt;\u0026lt;24) | (hash(message_id)\u0026gt;\u0026gt;\u0026gt;8) By deriving the top 8 bits of the hashcode from the user_id, it guarantees that any users emails are in the same 256th portion of the cluster. At search time, this information can be used to only query that portion of the cluster.\nWe probably also want to view the hash space as a ring (as is done with consistent hashing) in order to express ranges that wrap (cross from the maximum value to the minimum value).\nshard naming When partitioning is by hash code, rather than maintaining a separate mapping from shard to hash range, the shard name could actually be the hash range (i.e. shard \u0026ldquo;1-1000\u0026rdquo; would contain docs with a hashcode between 1 and 1000).\nThe current convention for solr-core naming is that it match the collection name (assuming a single core in a solr server for the collection). We still need a good naming scheme for when there are multiple cores for the same collection.\nShard Assignment The node -\u0026gt; partition mapping can only be changed by a node which has acquired the Cluster Lock in ZooKeeper. So when a node comes up, it first attempts to acquire the cluster lock, waits for it to be acquired and then identifies the partition to which it can subscribe to.\nNode to a shard assignment The node which is trying to find a new node should acquire the cluster lock first. First of all the leader is identified for the shard. Out of the all the available nodes, the node with the least number of shards is selected. If there is a tie, the node which is a leader to the least number of shard is chosen. If there is a tie, a random node is chosen.\n","date":1317210300,"dir":"post/2011/","id":"927612b57ba01ca878b2d7edce52a563","lang":"ja","lastmod":1317210300,"permalink":"https://blog.johtani.info/blog/2011/09/28/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE%EF%BC%91/","publishdate":"2011-09-28T20:45:00+09:00","summary":"ちょっと興味があるので、訳してみました。（Wikiのページはこちら） 更新されているようなので、もとの文章も残しておきます。（ページ下部の続き","tags":["solr"],"title":"New SolrCloud Designの翻訳（その１）(Jugemより移植)"},{"contents":"Hadoop Conference Japan 2011 Fallに行ってきました。 まずは、ユーザ会の方々、運営の方々、発表された方々お疲れ様でした。こんな機会を用意していただき、ありがとうございます。 Hadoopは昨年触っていたのですが、最近は縁がなくなってしまいました。 ただ、触っていたときに面白かったので参加してきました。 ということで、今回も自分用にメモを取ったので。（今回は英語のヒアリングがあって、メモがひどい事になってます。。。） いつものことながら、おかしいところとかあれば、ツッコミなどフィードバックをもらえると嬉しいです。\n場所：ベルサール汐留 日時：2011/09/26 10:00～18:00＋懇親会：18:30～21:00\nオープニングトーク：濱野、太田 参加者：1100名超！（実際は800名弱？） Hadoopの経験：利用経験なしな方が580名 カンファレンスの認知：Twitterよりも知人、その他が多かった。 会場提供：リクルート様 リクルート米谷様より一言。 Question VOTE！！サイトを用意。 http://mit.recruit.co.jpにて情報提供。 ※残念ながら地下だったため、E-mobileにつながらず、あと、電源確保が難しかったのでMBAをスタンドアロンにしてメモをとっていたので、 QAサイトにはアクセスしませんでした。もう少し活用したかったんですが、携帯でTwitterを追っかけるので精一杯。。。\n◎The role of the Distribution in the Apache Hadoop Ecosystem：Todd Lipcon（Cloudera）\n1.Introduction Todd Lipcon：Clouderaエンジニア Hadoop とHBaseのコミッター 2. Hadoop Overview HDFS＋MapReduceの説明 Hadoopの生まれてきた経緯　様々な形式のデータが大量に存在し、データのハンドリングが難しくなってきたため。 Flexible, Scalable Solutionが必要に。 Hadoop の2つのユースケース 1.Advanced Analytics SNS（Web）、Content Optimization（Media）、Network Analytics（Telco）、 2.Data Processing Clickstream SessionizationEngagement 3.Cloudera Overview ClouderaCustomers ・Large National Bank ・Web-Based Media click-through dataや広告のログ ・Wireless Telecom 大量のデータ 目標：大量データからビジネスを引き出すこと。 Cloudera Japan：トレーニング。NTTDと協業して開発支援も 4.CDH Overview 100% pure Apache Hadoop SCM Epress(Service \u0026amp;amp; Configuration Manager) Free なぜ、CDHを利用するの？ Linuxを利用する場合にLinux.orgからはダウンロードしないように、Hadoopも同じように提供したい。 RedHat系を目指しているみたい。 様々なパッケージの依存関係が混乱を招く。 CDHならテストが終わってるものが提供されてる。 ※SolrはLWEがLucidWorksEnterpriseがこれを目指してるのか。 5.Cloudera Enterprise Activity Monitor：Jobのパフォーマンスをリアルタイムに監視 SCM：設定のvalidateや管理。 Resource Manager：。。。 6.まとめ CDH：簡単にHadopが使えるよ。 SCM Express：簡単にHadoopの設定ができてフリーだよ Cloudera：Hadoopに関していろいろサポートしているよ。（Enterprise用ソフトやトレーニングなど） ◎About Hortonworks：Owen O\u0026rsquo;Malley（Hortonworks）\n1.About Hortonworks 2011/2月に設立 22人のYahooからのアーキテクトとコミッタにより設立 2.Credentials Yahooのクラスタの経験者がいますよ。 OSSに長けた人達によるチームです。 3.What is Apache Hadoop Hadoopの説明（別の側面が幾つかあり。） Commodity Hardwareで動く 簡単にプログラムできる 典型的なアプリケーションのタグクラウド（あとでちゃんと見る） HadoopのほとんどのソースコードはYahooで作られてるよ。 Clouderaとか目じゃないよ 4.Hadoop @ Yahoo! 各種サーバや規模など Science Hadoop Cluster \u0026lt;-\u0026amp;gt; Production Hadoop Cluster \u0026lt;-\u0026amp;gt; Serving Systems という構成で、いろいろやってます。 5.Hadoop Market ビジネス：ビッグデータを扱って色々やろうね 金融系：IT系のコストをOSSとHadoopで削減 技術系： 6.Hortonworks Strategy Hadoopを利用、管理しやすくするためのいろんなことをコミュニティに還元しますよ。 性能などについても同様。 トレーニングやテクニカルサポートやりますよ。 QA： Q：42Kのノードの管理ツールはなに？ A：手で管理してます。 Q：社名の由来は？ A：童話でHortonという名前の象の話がある。 Q：CDHはおすすめ？それともほかのものがいい？ A：※聞き取れず。。。 Q：500万Query/月はアドホックQueryもあるの？ A：幾つかのクラスタに分けて使ってる。アドホックは不明 ◎How Hadoop needs to evolve and integrate into the enterprise：Ted Dunning（MapR）\n・Quick History ・英語わからない身には辛い。。。 Zookeeperの人らしい。 Narrow Foundations HDFSとNASの間には大きな壁があり、大きなデータを移動するのはコストが掛かる。 Broad Foundation HDFSの代わりにNAS、RDBMSの下に位置するMapRを用意 ど、どんな仕組み？-\u0026amp;gt;テクニカルセッションで。 QA： Q：MapRはOSSにしないのか？ A：MapRで開発したものはApacheに還元はしますが、OSSにはしないよ。フリー版は提供するかも ここで昼食。午前中からいた人にはランチボックスが提供されました。 午後からはコミュニティトラックとテクニカルトラックの2トラックがありましたが、LTが聞きたかった（それよりも英語が辛かった？）のでコミュニティトラックのど真ん中、最前列に入り浸りました。 ★コミュニティトラック ◎Elastic MapReduce Amazonが提供するHadoop：大谷晋平（Amazon）\n・Amazonとは Eコマース 流通 AWS の3つのサービス ・AWS Low-level、High-level、Cross Service、Tools to access services、アプリケーション 色々あるなー ・Bigデータが大変な理由 ケタ違いのデータ量、異なる形式データ、即時性 現状システムはスケールしない ビジネスとして成立する？ 成立するならすぐスケールだめならすぐ縮小 ・Hadoopとは？ これまでのお話。 スケーラブル、低価格なハード 誰でも入手可能で、実績多数。 ・Amazon EMR AWS上でスケーラブルなインフラ上に構築が可能 オンプレミスからMapReduceアプリを移行可能なため、分析、解析に集中可能 S3からデータIN/OUTするので、データ欠損がない。 Hadoopそのままではチューニングやクラスタサイズ見積もりも難しい ＝＞クラスタサイズを動的に拡張伸縮可能。パフォーマンス最適化もできるよ。 0.18、0.20が利用可能。 EMRはHDFSとジョブ（タスク）トラッカーを別構成にしている。 EC2上にMaster、Core、タスクノードを展開 S3にデータを格納 SimpleDB（KVS）を利用 ・EMR注目機能 ジョブフローの高速化 ジョブの再起動無しにコスト/パフォーマンス比を変更可能。 タスクノードを動的に増やせる 柔軟なデータウェアハウスクラスタ タスクノードをバッチ実行時にのみ増やせる。 ※増減できるのはタスクノード Coreノードは増加のみ EMR＋Spotインスタンスの活用 コスト削減効果が非常に高い AWSの余剰リソースをリーズナブルに提供（Amazon的にもウハハだ） ・その他の機能 東海岸だけだけど、スパコンレベルのインスタンスも利用可能 AWS上での最適化設計など ※ちょっと時間足りなくなってきたｗ ・EMRの事例 1.Razorfish ROAS（広告費用対効果）を500%改善（すげー） 2.So-net ・EMR都市伝説 物理vs仮想 そりゃ、物理が速いよ EMRの柔軟性・拡張性がセールスポイント ビッグデータは成功/失敗が読めないのもあるので、 インフラに投資する部分を少なくできるよ。 オンプレミスが安い？ いやいや、HWの購入から設定など時間かかる。 ・Beyond Hadoop HadoopのIn/Out含めてスケーラブル、フレキシビリティが重要 運用管理の仕組みも重要 まだまだやってくよ。 QA Q：EMRは複数サービスから構築してるけど、一部がダウンするとどーなる？（例：SimpleDBが落ちてるとか） A：ジョブはReRunしてもらうか、SimpleDBの状態をみてリカバリをしてもらう。 Q：上記にともない、SLAの計算は？ A：SLAはEMRについては定義できてない。S3などはリージョン跨いで Q：S3のセキュリティが心配だが、どう考えてるか？ A：いままで脆弱性を晒してデータをロストしてない。 ユーザコントロールなどもできる。基本的には問題ない Q：EMRでS3を使う＝Hadoopのローカリティの利点が失われるのでは？ A：オーバヘッドはあるが、実際のデータはS3で守られているので、HDFSが飛んでも大丈夫。 Q：S3からのコピーオーバヘッドはどーなるか？ A：Single5で少しずつor分割して全部送るも可能 Q：EMRはマルチテナントだけど他のユーザのネットワークの影響を受けないの？ A：マルチテナントだと起こる可能性がある。 M1（？）だと内部ネットワークは専有可能らしい。 ◎LT\n・Hadoop and Subsystems in livedoor @tagomoris ピーク時に15Gbps。 10ノード（36コア） CDH3b2を利用 データマイニングではなく、ログからレポーティングをするのに利用している。 hadoop streaming + Hiveで実施 580G/dayが96サーバから来る ScribeにてHadoop Streaming（Perl）でper hourでHiveにload scribelineをWebサーバに入れててログ配送してくれる。 **　・Lightweight　@stanaka（はてなCTO：田中慎司さん）**\nEMR以前 自前20台クラスタ ジョブがあふれてきた ナマMapReduceを利用 PerlでMapper/Reducerを記述（Hadoop Streaming） EMR導入 リソース増やせて便利！ 必要な台数に伸縮可能 問題点： S3にアップしないとダメ ＝＞ログデータをS3に展開するlog2s3.plを作成。毎時実行。 起動、ジョブキック、結果改修どーする？ ＝＞Net::Amazon::EMR::Wrapperを作成した。 クラスタ起動、ジョブキック、クラスタ停止などできる 作ってみて思ったこと よかったところ： Perlでかける。Cronで実行可能。HiveQL便利。 悪かったところ。 途中で失敗してクラスタ起動しっぱなしとかがある。S3にデータを展開が大変。複雑な計算がきつい。 慣れてないエンジニアにも触れるようにしたい ＝＞Perlで書けるようにした？。 **　・HBaseでグラフ構造を扱う（開発中）：アメーバ鈴木**\n自己紹介@brfrnl69 アメーバのソーシャルグラフ 基本はMySQL マスタ分散が難しい、シャーディング管理が面倒 ＝＞HBaseでやってみるか。 目的　グラフデータに対して高速に更新追加したい。 隣接ノードが取れればいい（これを高速化したい） オンライン処理したい 運用コストの削減したい。 Not目的 マルチホップはどうでもいい。 アーキテクチャ JavaでGatewayつくってみる。 ・Large-Scale Graph Processing：井上さん（@doryokujin）さん Map/Reduceではグラフ計算だめ？ Vertex基本だとShuffleに問題ががが。 BSPの紹介 Bulk Synchronous Processing Google Pregel SSSP：MapReduce Model すごい計算時間が掛かりそう。MRの組み合わせが何回回ることやら。 枝が少ないとこっちのほうがいいのか？ SSSP：PregelModel シンプルなアルゴリズム Pregel使えるのあるの？ Hama GoldenOrb Giraph YERN？YARN？ ◎リクルート式Hadoopの使い方：石川（リクルート）\n@ground_beetle ・導入の課題点 バッチ処理時間対策のため。 ＝＞実は入れたかっただけｗ ・導入の障壁 現行システムへの影響＋開発工数 ＝＞これへの対処がこのあとの話 ・課題の克服と活用シーン Azkaban知らなかった。ジョブスケジューリングツール Hadoop単体ではなく、エコシステム（関連ツール）が魅力 ・活用シーン：Hive SQLゆーがざ多く、HiveQLがSQLライクのため導入が簡単に！ 既存機能のリプレイス系案件に活躍（低工数＋簡単に高速化） とりあえず、Hive実装 ＝＞性能アップのためにMapReduceで書きなおし Hotpepperなどのアトリビューション分析に利用 ・活用シーン：Sqoop＋Hive RDBとHadoop連携のツール：Sqoop 現行システムの横にHadoopを配置でき、RDBMSの利点も利用しつつHiveも利用できるようになる。 （※気を付けないといけないけどねぇ。） ゼクシィで活用しようとしてるところ。 ・活用シーン：Mahout マイニング用ツール カーセンサーのレコメンド（同時に閲覧される車種） アソシエーション分析＋クラスタリング ・活用シーン：BIツールの導入 何度か導入しようとして失敗してます。。。 BIツールの前処理（クレンジングなど）にHadoopを活用 ・インフラリソースは？ 全部で118台。 最小のクラスタ構成はサーバ6台で構成してる ・Hadoopで複数処理を回す方法 ここまで紹介したものを入れてますよ。Hive、Sqoop、Solr。。。 ・Azkaban TomcatにWar配置で利用可能。 LinedInのチームにより作成 ※若干マシントラブルで中断 ・今後のHadoop導入 ログ基盤 分析エンジン・レコメンドエンジンとして バッチ処理短縮＝トライアンドエラーが簡単にできるようになる。＝色々な気づきが出てくる。 アジャイル的な解析が可能に。 ・開発サイクルの短縮ができるエコシステムでビジネスが回りだす。 ・今後の展開 MapRが気になってる。 マルチテナント対応ができてうはうはできそう。 EMCと共同して検証中 QA： Q：性能監視ツールの選別の理由は？ A：Zabbix、Cactiです。今から利用しようと思っている段階。 Q：CDH、GreenPlum、Apacheをそれぞれ利用してるけど、使い分けのシーンは？比較は？ A：CDH3u0です。GreenPlumは使ってないです。理由は言うとクビが飛ぶ可能性ががが。 Q：高度なデータ分析ができる技術者はどこからヘッドハントしてるの？ A：MITに別途分析チームが存在し、高度な分析をしてくれる。 Q：NameNodeの冗長化はどーやってんの？ A：象本と一緒DRBD＋HeartBeat Q：EMRの導入を検討してる？ A：今後、サーバ数が多くなると導入の検討をしていくと思う。 現時点は、運用ノウハウも入手するために社内で使ってる。 EMRになるかRCloud（リクルート社内クラウド）になるかは不明。 Q：HBaseを利用してる？ A：してないです。スペック的にサーバが買ってもらえないと厳しいです。 ◎The history and the future of Hadoop use case at Rakuten：Tarje Marthinussen（楽天）\n・Introduction（self、rakuten） NextGeneration Search Group Norwayから来ましたよ。 ・RakutenのBigDataとは ・Hadoop at rakuten　Recommendation（2009） ProductRanking、GenreRanking、Log解析、（2010） Enhance Search。。。（2011） ・PigやHiveのようなものが簡単に利用できるようになってきた ・新しい検索プラットフォームを構築中 index 10k docs/sec search 400qps ・What\u0026#39;s Next Generation Search 20%はインデックスとQuery評価の 50%がデータの前処理（データとQuery） 30%がアナライズ ・Collecting Data？ ログの取得はバッチ処理だった。これをStreamingに（Flume） ・Flume Zookeeperを利用してFlumeを管理してる？？？ ・気になる部分があったので、改善のコーディングしてるよ。 ・セキュリティ マスタで管理できるように ・Pools Agentが送信先がコケてると他のPoolにスイッチ可能に。 ・MasterlessACKs QA Q：パッチ作成は何人でやってるの？ A：50人が働いていてOSSコミッターが何人いるかはわからんです。 Q：ログはテキストだけど、パース処理はどこで？（古橋さん） A：Flumeは各ノードでうまい構成になっていて Decorator 性能問題は？ HiveはJSONデータをうまく活用できてるよ。 Q：Masterlessとそうじゃないバージョンの性能比は？ A：ノード数が増えると Q：HBaseじゃなくてCassandraなの？ A：（※英語きつい。。。聞き取れず） ◎マーケティング向け大規模ログ解析事例紹介：原謙治（NTTコミュニケーション）\n・自己紹介 ・BizCITYというクラウドサービスを展開中 まずは、宣伝。 Bizストレージ、Bizマーケティングとして大規模データ、分散処理を実施してる。 ・Hadoop in Bizマーケティング CGMデータを解析して口コミ情報抽出 アクセスログから行動情報抽出 ・Hadoop in BuzzFinder CGM DBからHDFSにインポートして解析開始。DBはPostgreSQL 処理フローは資料参照。 リッチインデクシング技術（NTT研究所が開発した日本語解析技術） ※検索インデックスってどんなものなんだろう？ ポジネガ分析気になる。 ・Fast Map-Reduce for PaaS Services アクセス解析やマーケティング解析を行う上でShuffleコストが大きくなるため大量マシンが必要 ＝＞マシン数を減らすことが目的？ Map Multi-Reduce、PJoinはNTT研究所が開発した技術！？（子象本にないっけ？？） ＝＞Multi-Reduce。同一ノード上のMap出力をReduceすることで、shuffleフェーズに渡るデータを削減している。 ＝＞PJoin　QA Q：Map multi-reduce、PJoinはどう実現してるのか？公開するのか？ A：Hadoopの0.19に改造をしてる。 公開できるかどうかはわかりません。NTT研究所が研究しているものを試しに実装してみてるから。 なのでパッチにはなりませんかね（研究所に聞いてみないとわからないっす） Q：性能が向上したパターンはあったが、悪化する場合などはあるのか？ A：不明 Q：Map-side Joinとの違いは？ A：。。。 ※この辺で少し集中力が途切れてしまいました、すみません。（次に集中したかったので。。。） ◎ミクシィにおけるHadoopの利用：伊藤敬彦（mixi）\nLSH-Based Recommendation engine powered by hadoop ・実はmixiの話はすくないよ。 ・利用している環境。5or6台/クラスタ ・Hadoopの活用 ログデータをHDFSに保存 DBコンテンツをHDFSに入れることで、DBに負荷をかけずに解析する。 ・マイニングも検証中 検索クエリログをベースにデータマイニング では、本題。 ・LSHを利用した推薦 ・推薦とは？ mixiにはいろいろ推薦（レコメンド）を付加できるサービスがある。 ・推薦するには？ 類似インスタンス集合を抽出する。 インスタンスは文書だったりユーザだったり ・類似インスタンスとは？ 同じ特徴を持つ集合 例：同一商品購入したユーザとか同一単語を持つ文書とか ・抽出するには？ 全ユーザごとに全ユーザとの類似性をチェックすると時間がかかりすぎる！ ＝＞LSHを利用しよう！ ・LSHについて 特徴： ・速い！ ・精度はそれほどではない 事例： ・Google Newsのレコメンド（USロケール） ・LSHの処理ステップ 2つだけ。 1.インスタンスベクトルを計算（似ているデータは同じ値が返りやすい関数） 2.同一値が帰ってきたデータが類似インスタンス ・インスタンスベクトル例（あとでスライド見ようね） ・Likelikeがいち実装。Hadoopでうごくよ ・実験について トップページに表示されていない記事を知ってもらうために推薦してみるぞ！ ・実験１ 性能を測ってみた ・実験２ 精度を調べてみた。 精度はほんとにひどいな。。。 ＝＞同一カテゴリの遷移を元に計算したらそれなりになってきた。 ・今後 データソースを増やしたい。 他のアルゴリズムも実装したい ・CM 以下も作ってますよ。 Oluolu Anuenue QA Q：Mahoutは使わないんですか？ A：Likelikeを作った頃にMahoutになかったので作った。 性能比較したいと思ってる。 Q：ログサーバのデータ転送はどーやってる？ A：伊藤さんのところにはどういう仕組みかは上がって来てない。 Q：ベクトルの次元数はどのくらいまで耐えられる？ A：高次元のデータに対して耐えられるように作られてる。 次元数が低くて良い制度が欲しければ他のアルゴリズムがいいかも。 Q：ユーザのベクトルを作るテクニックは？ A：画像などであれば大変だけど、ユーザであれば、単語とかキーワードとかで Q：ニュース以外のデータは？ A：まだまだ実験中。まだやってない。 Q：推薦される記事数のばらつきはどういった理由が考えられる？ A：後ほど考察してQAサイトに入れます。 Q：LSHをMapReduceに載せたということだけど、関数の計算をさせてる？ A：Iterationはしてない。 Map側でLSH関数計算してる。Reduceにて類似インスタンスを導出してる。 Q：今後の予定の空間木とは？R-Treeだと高次元できついのでは？ A：低次元にて利用できるように用意したい。 Q：HamaとかGiraphで高速化させてみるのはどう？ A：イテレーションがいらないからあまり利用用途がないかなぁ。 ◎懇親会\nAWSを採用しない企業がいくつかあったのでそのあたりを質問してみた。 AWSは通常運用に利用すると結構なコストがかかる場合があるので、ノウハウがある企業や データ量が多い場合は、オンプレミスの場合を選択しているらしい。 やはりスポットで利用する方がお得感があるみたいだった。 Twitter上だけの知り合いだった方々と面識が持てたのが一番の収穫でした。 感想＋調べること\n感想\n会場規模とかQAサイトとかオープニングムービーとかすごかったです。しかも無料。さすがリクルートさん。 ランチボックスとか出てきたし。装飾もとても無料のカンファレンスと思えない出来でした。 午前中はHadoopをもとにした各社の戦略とCMという感じが色濃かったです。少しずつ各社の立ち位置が違いそれはそれで面白かったです。 AWSの説明を聞いてやはりAWSを扱える技術は必要だと再認識。 お金かけないで触ってみれるレベルでまずは触ってみるかなぁ。 洗脳されてるのかもしれないけど、自社or自前でHadoop運用するのは厳しそうです。（懇親会ですこし認識が変わった） カフェコーナーでは、リクルートのMITの冊子が配られていたり、映像や案内に使われていたHadoopマスコットのシールが配られていたりと小技も聞いてました。 あと、オライリーの販売コーナーも用意されていて、思わず子象本を買ってしまう罠にはまったりもしましたが。。。 mixiの伊藤さんの話は最後で疲れていたのですが、ストーリーが上手くできていて、実験や事例もあったのでわかりやすかったです。 Hadoopはエコシステムと呼ばれるHadoopを活用するツール群（Hiveの話が多かった？）、Hadoopの今後、Hadoopを活用したログ解析の話など、 話題が豊富でそれぞれの話が面白くて困ってしいまうくらいです。 いくつかのセッションで出てきたのですが、アクセスログなどをHDFS上に集めるための仕組みがまだ乱立（定番がまだない）している感じを受けました。 Flume、Scribe、MapR。。。などなど あとは、テクニカルセッションのビデオがアップされたらまた目を通さないと。。。 残念ながらHadoopから少し縁遠くなっていますが、これからもネタや参考になりそうな話には事欠かなそうなのでかじりついていこうと思います。 ※一番やらないといけないのは英語の勉強かもしれないです。。。 調べること 一応Solrの人なので、Solrに関連しそうな話に興味がいってしまいます。\nNTT研究所のリッチインデクシング技術 やっぱりAWS触ってみる。EMRまでとは言わないが。（herokuもちょっと興味あるが。） Mesos、GreenPlum、Scribe、Storm、Flume、Giraphこれらの概要 関連サイト 公式QAサイト。後日録画していたセッションがアップされるそうです Hadoop Conferene Japan Fall 2011 - 急がば回れ、選ぶなら近道 Hadoopカンファレンスが開催、本格普及を見据えた支援サービスや先進事例が充実 - ニュース：ITpro Hadoop Conference Japan 2011 fallで使用された資料 #hcj11f | インフラエンジニアのつぶやき（スライドをまとめてくれてます。）\n","date":1317113460,"dir":"post/2011/","id":"97402287d8c6c03f0b63848e17e9d944","lang":"ja","lastmod":1317113460,"permalink":"https://blog.johtani.info/blog/2011/09/27/hadoop-conference-japan-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-09-27T17:51:00+09:00","summary":"Hadoop Conference Japan 2011 Fallに行ってきました。 まずは、ユーザ会の方々、運営の方々、発表された方々お疲れ様でした。こんな機会を用意していただき、ありがとう","tags":["hadoop"],"title":"Hadoop Conference Japan 2011 Fallに参加してきました。(Jugemより移植)"},{"contents":"台風15号すごかったですね。幸いにも（？）夏休みだったので、通勤などでひどい目に合わずにすみました。 風雨はすごくてちょっと怖かったですが。。。\nさて、夏休みに進める予定が、子供の寝かしつけで一緒に寝てしまう日が続いてしまい、 間が開いてしまいました。\n0日目というタイトルになっているのは、まだ、1日目に入ってないからです。。。 Ioという未知の言語をMBAにそのままインストールするのも抵抗があり、VirtualBox上にLinuxをインストールしてから 進めようとして思いの外手こずってしまったためです。 ということで、0日目として、VirtualBox上にScientific Linux 6.1をインストールしてIoのインストールまでではまった箇所を記録として残しておきます。\n罠その１ 罠と言うよりは、私の無知に関する部類なのですが。。。 Scientific Linux 6.1のインストールは特に手こずることなくインストールでき、 起動も出来ました。 次にscpコマンドでダウンロードしてきたIoのソースをLinuxに渡そうとしてはまりました。 問題となったのはネットワーク接続が「NAT」のみだったため。 NATのため、Linux（ゲストOS）から外部への接続は可能だったのですが、Mac（ホストOS）からLinux（ゲストOS）への接続ができませんでした。 で、変更したのは以下の2点。\nVirtualBoxの環境設定-\u0026gt;ネットワーク-\u0026gt;ホストオンリーネットワークの追加 仮想マシン（Linux）の設定-\u0026gt;ネットワーク-\u0026gt;アダプタ2を有効にしてホストオンリーアダプタを割り当て 1番目のホストオンリーネットワークの追加をしておかないと、2番目のアダプタ2でホストオンリーアダプタを選択したときにエラーが出て、設定ができませんでした。割り当てるべきアダプタを先に用意しとかないとダメですよね、そりゃあ。\n罠その２ これも罠というほどではないのですが。。。 Ioのビルドにはcmakeが必要なのですが、Scientific Linux 6.1に入っているcmakeはバージョンが古い（2.6.4）ため、必要なバージョン（2.8以上）をインストールしないとダメでした。 インストール自体はcmakeのサイトにある手順通りのため割愛します。\n罠その３ これもちゃんとドキュメント読めよというレベルですが。。。 Ioのインストールは以下のコマンドを実行するという話です。 私がcmakeについて知らなかったと言われればそれまで。。。\n$ cd io $ mkdir build \u0026amp;amp;\u0026amp;amp; cd build $ ccmake .. $ make $ sudo make install 3つ目の「ccmake」の部分がIoのGetting Startedの下の方にありました。上の方に記載がある「cmake」ではエラーがでてうまく行かなかったので。 IoのGetting Startedにもありますが、ccmakeの場合はCUI上にGUIのようなものが起動するので、「c」（configure）と実行後、「g」（generate）を実行して最後に「e」（exit）でccmakeを離れます。 するとmakeが実行できるようになりました。\nあとは、/etc/ld.so.conf.d/io.confファイルを作成し、「/usr/local/lib」と記述。ldconfigを実行することで、Ioが実行可能になります。 ということで、1日目に入れず終了。。。\n明日は出来るかなぁ。\n","date":1316716440,"dir":"post/2011/","id":"62f31128a21b0e240bdb7b3d5b121c04","lang":"ja","lastmod":1316716440,"permalink":"https://blog.johtani.info/blog/2011/09/23/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-0%E6%97%A5%E7%9B%AE/","publishdate":"2011-09-23T03:34:00+09:00","summary":"台風15号すごかったですね。幸いにも（？）夏休みだったので、通勤などでひどい目に合わずにすみました。 風雨はすごくてちょっと怖かったですが。。","tags":["読書"],"title":"「7つの言語　7つの世界」 Io 0日目(Jugemより移植)"},{"contents":"Solr/Lucene 3.4がリリースされました。（速報）\n以下、各サイトへのリンクです。\nSolrリリースのお知らせ\nLuceneリリースのお知らせ\nちなみに、先日のSolr勉強会で関口さんが話されていたインデックスが壊れるバグですが、 先日のアメリカのハリケーン（Irene）で実際に電源が落ちて見つかったみたいです。\nということで、3.4がリリースされたので、3.1~3.3は利用しないほうがいいようです。\n追記： lucidimagination.jpのサイトに日本語のリリースノートが公開されていたので、リンクを記載しておきます。\n","date":1316046660,"dir":"post/2011/","id":"54da1b916f49ef40c822fab61d37cf66","lang":"ja","lastmod":1316046660,"permalink":"https://blog.johtani.info/blog/2011/09/15/lucene-solr-3-4%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/","publishdate":"2011-09-15T09:31:00+09:00","summary":"Solr/Lucene 3.4がリリースされました。（速報） 以下、各サイトへのリンクです。 Solrリリースのお知らせ Luceneリリースのお知らせ ちなみに、先日の","tags":["solr"],"title":"Lucene/Solr 3.4リリース（速報）(Jugemより移植)"},{"contents":"ということで、Rubyの最終日の感想。 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大募集です。コメント欄にどしどしコメントください。そこは違うだろ？こっちのほうがいいのでは？という感じで。\n感想： ◎メタプログラミングが特徴 例：ActiveRecordのhas_many、has_oneがいい例\n◎オープンクラス クラス定義をいつでも変更可能。 あらゆるクラスやオブジェクトをいつでも再定義できる 書きやすいコードのために再定義が可能＝何でもできるが気を付ける必要あり。 DSLの定義に便利。 確かに便利。ただ、範囲を限定しないと予期せぬ場所で問題が発生しそう。 ※解析するための手段はいいのがあるのかな？=\u0026gt;method_missingみたい\n◎method_missing 対象メソッドが見つからない場合に最後に実行されるメソッド 通常はNoMethodErrorが発行される。\n◎モジュールによるメタプログラミング defやattr_accessorなどその一例。 DSLではモジュール内にメソッドを定義してメソッド＋定数を利用 ActsAs\u0026hellip;ってそういう意味合いだったのか。 親クラスバージョン、親クラス＋マクロ、モジュールそれぞれの実装の仕方の紹介。 ※マクロもinclude同様、実行順で、メソッドの上書きが発生するのか？ ActiveRecordではメタプログラミングを利用してDBのカラム名からアクセサを追加。 シンタックスの美しさ＝読みやすさ\n感想＆疑問点： メタプログラミングはフレームワークを作成するのが便利そう。 ただし、エラーや問題が起きた時の対処をきちんと準備しておかないとひどい目に合いそう。 クラスやモジュールはわかりやすい単位で1ファイルにまとめるもの？ ファイル名の規則とかあったりする？ ディレクトリ構成でパッケージ構成が可能？ 複数のモジュール（gemとか）を組み合わせて使っている場合にincludeの順序がどのようになるかが気になる。 予期せぬ順序でincludeされて利用しようと思ったメソッドがオーバーライドされてるとかありそう。 追っかけるのがまた大変そうだ。 異なるパフォーマンス（開発者の開発速度）の観点が一番おもしろかった。ただ、なれるまでは大変そう。すんなりinjectとかコードブロックをうまく利用するイメージがわかない。 まぁ、思考については反復練習かな。これは他の言語でも一緒かな\nようやく、Rubyの世界が終わりました。楽しかった。次は未知の言語である「Io」です。\n（試してみよう：） ○eachメソッドがCsvRowオブジェクトを返すようにCSVアプリケーションを変更せよ。そのCsvRowのmethod_mmissingを使って、与えられた見出しの列の値を返すようにせよ。 モジュールにて実装してみた。 ``` module ActsAsCsv\ndef self.included(base) base.extend ClassMethods end module ClassMethods def acts_as_csv include InstanceMethods end end\nmodule InstanceMethods\ndef read @csv_rows = [] file = File.new(self.class.to_s.downcase + '.txt') headers = file.gets.chomp.split(', ') file.each do |row| @csv_rows \u0026lt;\u0026lt; CsvRow.new(headers,row.chomp.split(', ')) end end def each(\u0026amp;block) csv_rows.each(\u0026amp;block) end attr_accessor :csv_rows def initialize read end end\nclass CsvRow def initialize(headers, csv_contents) @headers = headers @csv_contents = csv_contents end\nattr_accessor :headers, :csv_contents def method_missing name, *args csv_contents.fetch(headers.find_index(name.to_s)) end end end\nここまでが実装したモジュール＋クラス。 以下は実行例。id,name,sizeというheaderをもつCSVを使ってみた。 require \u0026lsquo;acts_as_csv_module_mod.rb\u0026rsquo; =\u0026gt; true class RubyCsv include ActsAsCsv acts_as_csv end =\u0026gt; RubyCsv csv = RubyCsv.new =\u0026gt; #\u0026lt;RubyCsv:0x103c4c530 @csv_rows=[#\u0026lt;ActsAsCsv::CsvRow:0x103c4c030 @csv_contents=[\u0026ldquo;1\u0026rdquo;, \u0026ldquo;RubyCsv.class\u0026rdquo;, \u0026ldquo;20\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;, #\u0026lt;ActsAsCsv::CsvRow:0x103c4be78 @csv_contents=[\u0026ldquo;2\u0026rdquo;, \u0026ldquo;JRubyCsv.class\u0026rdquo;, \u0026ldquo;50\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;]\u0026gt; csv.each {|row| puts row.name} RubyCsv.class JRubyCsv.class =\u0026gt; [#\u0026lt;ActsAsCsv::CsvRow:0x103c4c030 @csv_contents=[\u0026ldquo;1\u0026rdquo;, \u0026ldquo;RubyCsv.class\u0026rdquo;, \u0026ldquo;20\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;, #\u0026lt;ActsAsCsv::CsvRow:0x103c4be78 @csv_contents=[\u0026ldquo;2\u0026rdquo;, \u0026ldquo;JRubyCsv.class\u0026rdquo;, \u0026ldquo;50\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;] csv.each {|row| puts row.id} (irb):8: warning: Object#id will be deprecated; use Object#object_id 2179096600 (irb):8: warning: Object#id will be deprecated; use Object#object_id 2179096380 =\u0026gt; [#\u0026lt;ActsAsCsv::CsvRow:0x103c4c030 @csv_contents=[\u0026ldquo;1\u0026rdquo;, \u0026ldquo;RubyCsv.class\u0026rdquo;, \u0026ldquo;20\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;, #\u0026lt;ActsAsCsv::CsvRow:0x103c4be78 @csv_contents=[\u0026ldquo;2\u0026rdquo;, \u0026ldquo;JRubyCsv.class\u0026rdquo;, \u0026ldquo;50\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;]\n\u0026lt;span style=\u0026#34;color:#FF0000\u0026#34;\u0026gt;※idというcsvフィールド名にしたら、object_idとかぶっているようでwarningが出てしまった。\u0026lt;/span\u0026gt; CsvRowクラスの定義がモジュールの中に入っているが、この実装でも動くみたい。ただ、パッケージみたいな感じ7日までは調査してない。。。 ","date":1315992060,"dir":"post/2011/","id":"41b811063b9425de1934e77d89118022","lang":"ja","lastmod":1315992060,"permalink":"https://blog.johtani.info/blog/2011/09/14/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-3%E6%97%A5%E7%9B%AE%E6%9C%80%E7%B5%82%E6%97%A5/","publishdate":"2011-09-14T18:21:00+09:00","summary":"ということで、Rubyの最終日の感想。 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大","tags":["読書"],"title":"「7つの言語　7つの世界」 Ruby 3日目（最終日）(Jugemより移植)"},{"contents":"「第6回Solr勉強会」に参加しました。 なんだかんだと第6回で、今のところ皆勤賞です。\nということで、主に自分用ですが、メモなどとったので。\n概要\n日時 :2011/09/12 19:00 to 21:00 定員 :110 人 会場 :株式会社 ECナビ 1.「Lucene/Solr 3.2-3.4」 by ロンウイット 関口 宏司さん ※Solr2.9.4、3.1でデグレードし、Solr3.4で修正されたバグがあります。 インデックス中にPCがシャットダウンされた場合にインデックスが壊れてしまうものあり。 Solr3.1-3.3は使用しないようにとのこと。 ○index ・IndexWriter.addDocuments(docs) 複数ドキュメントの更新が可能になった。 ※検索で話をする親子関係のNestedQuery向けの登録にも利用する。 この登録では途中でフラッシュされないため、セグメントが分割されない特徴あり。 複数だけでなく、 ・TieredMergePolicy ※Lucene3.2/Solr3.3からデフォルトになった。 新しいインデックスのマージポリシー。（amebaの開発者ブログに説明があった。） インデックスの登録順が守られていたが、このマージ処理では保証がされなくなったので注意が必要。 ・update.chain update.processorがdeprecatedに。 update.chainというパラメータに変更 ○index(cont\u0026#39;d) ・TwoPhaseCommit ・UniqFieldsUpdateProcessor 重複した値を削除するための機能。 UIMAでの提案から取り込まれた ○search ・group=on 検索グルーピング機能を使えるパラメータ ・{!term} クエリパーサを通さないでTermQueryをかける機能。 ・structured explanation debug=onの算出根拠を XMLタグで構造化されたExplanationが取得可能に ・ReloadCacheRequestHandler 関口さん担当。ExternalFileField インデックス外（外部ファイル）を元にFunctionQueryの情報を利用可能にできるのだが、 このファイルのリロードが可能になる。 ・Carrot2　3.5.0 アップグレード。 デモあり。Carrot2のworkbenchとか　○search(cont\u0026#39;d) ・hl.phraseLimit parameter FastVectorHighlighterの高速化用パラメータ。 ・{!cache=false} キャッシュを利用しないためのローカルパラメータ。fqのローカルパラメータに利用可能。 検索セッション内でキャッシュへの処理（参照・登録）をしなくなる ・BlockJoinQuery NestedDocumentQueryの名前が変更された。 （Luceneで登録されたところまで。） ○schema ・KStemFilter PoterStemmerとは別のstemmer ・ReversePathHierarchyTokenizer パスの構造化インデックスの逆バージョン ・ommitPositions=\u0026#34;true\u0026#34; 指定が可能になった。 ・version 1.4 スキーマのバージョンが新しくなった。 ○admin/tools ・action=MERGEINDEXES\u0026amp;srcCore=coreName コア名指定可能。 ・action=UNLOAD\u0026amp;deleteIndex=true UNLOAD時にインデックス削除 ・action=CREATE\u0026amp;property.name ※ぎゃーーー。打ち込み失敗。 ○ぎゃーーーー失敗。 ○技術者大募集中！！ Q\u0026amp;A Q：クラスタリングの日本語は大丈夫？入門には制限があると記載があったが。 A：analyzerが記載が簡単になってるかは不明 前処理をして別フィールドにメタデータ的にある程度単語で区切ったようなものを作成したほうがいい。 Q：グルーピングで、グルーピング後のファセット件数が取得可能か？ A：3.4ではグループ数で表示可能。 パラメータ指定で可能。 2.「Solr＠cookpad」 by ＠PENGUINANA_ さん ○COOKPADとは？ ・レシピ投稿サイト ・105万のユーザのレシピ ・30代女性の1/2が利用 ○レシピ検索 ・PC：1307万UU、1億回強/月 ・モバイルで利用が多く、スーパの店頭などで利用？ ・Androidもあるよ。 ○人気順検索（Solrですよ） ○自己紹介 ・＠PNGUINANA_ ・情報可視化＋検索が好き！！ yats、など ○Solrはどのように利用 ・レシピ検索 ・もしかして ○Tritonnから移行 同じ検索結果になるようにして徐々に移行 ○なぜ？ パフォーマンスが良い。 フィールド追加が簡単 レプリケーション-\u0026gt;ファイルベース プロトタイピングが楽 ○Solr4 nightly（on Oracle JVM） ・マルチコア利用 ・Ruby on Railsから ○簡単な構成＋説明 ・バッチからSolrへの更新をしている。 ※Analyzerを利用せず、バッチ側で分かち書き、正規化、同義語展開を行っている。 Rubyで全部かけるほうが社内に展開しやすい。 ・バッチ終了後、可能ならoptimize ※検索速度がmax20%高速になる。 ・マスタ-\u0026gt;スレーブレプリケーションはschema.xmlもレプリケート 新規フィールド追加などはレプリケーションだけで実行できて楽。 ・アプリはMySQLとSolrのSlaveにアクセス。 Solrにはidのみ。本文はMySQLから取得 インデックスサイズを小さくできる＝レプリケーション時間が短くなる オンメモリにできるため検索速度も向上 ○監視（munin） ・監視項目（コア別）： クエリ：QTime/QPS キャッシュ：hit/eviction キャッシュから漏れている数をみてキャッシュサイズを定期的に変更して無駄をなくす インデックス：サイズ/docの数 運用してから重要。開始当初は気にしてるが、そのうち気にならなくなるため。 レプリケーション：所要時間 スレーブ間でのズレを検知するため。 ※コアごとに監視することで、問題点を把握しやすくしている。 ○監視（nagios） ・監視項目（コア別）： サーバの基本的なヘルスチェック Solrが動いてるサーバのはなし。 レプリ：インデックスバージョンのチェック ズレが長いとメールが飛ぶ ○便利だった機能 ・DynamicField フィールドをあとから簡単に追加可能。 例：人気順のアルゴリズムの違うフィールド。検索用フィールド ・FacetQuery 絞り込み検索をクエリで記載可能。 現時点では社内向け検索機能で利用。 ※ファセットで簡単な解析もやってる。 例：鍋の季節ごとの登録件数。 ・HTTP経由で色々可能 検索の並列化 通常検索画面：3クエリを同時実行 あるプロトタイプ画面だと8クエリで実行したりしてる。 ・分散検索（Distributed Search） 簡単にsharding可能 思いクエリは４shardで投げる オーバヘッドが大きいので思いクエリにだけ利用しているらしい。 ○開発の流れ ・まずはステージングを更新 ・問題なければマスターも更新 例外： フィールド追加するだけだったら直接マスタへ 例：ファセット追加など。 ○パフォーマンスとか大丈夫？ 本番で複数のバージョンを持っており、 バグっていても自動フォールバックするらしい。 価値があったらパフォーマンス向上＋テスト追加 例：スニペット変更 ○気になっている機能 ・not to cache(SOLR-2429) ・SurroundQuery(Solr-2703) ・JOIN(SOLR-2272) SQLのJOINなイメージ ・BloomFilter(SOLR-1375) 単語が存在するかどうかのチェック ○Solr入門おすすめ ○おすすめ ・http://blog.sematext.com 月一で新機能が出てくる ・SolrのJIRA ・@otisg ○今後やりたいこと ・わかち書きの精度向上 ・検索セッションの分析 nDCG、クエリ分類、検索意図 ・デバイス対応 ・パーソナライズ Q\u0026amp;A Q：同義語は誰が集めている？ A：外部辞書を利用。０件キーワードから解析して取得 単語登録も一緒。 Q：プチトマトとトマトの違いはどうやってる？ A：上位、下位の概念で同義語を利用している。 本にあるよ。 Q：もしかしてはSolrの機能？ A：Solrではない。訂正候補の単語をSolrに検索してからチェックして表示する。 Q：人気順はどういった計算をしてるんですか？計算してから登録？By 大谷 A：１フィールドに外から入れている。 Q：RubyからSolrの利用方法は？独自？ライブラリ？By 大谷 A：Rsolrを利用しており、コネクション管理にだけ利用している。 あとは、ラッパーを独自で作成。 Q：4.0を利用している理由は？なかなかチャレンジャー。By関口 A：グループクエリを利用したかったため。 実際には重くて使えていない。 今は必要ないかもと思っている。年始のバージョンを利用。いつでも入れ替え可能。 マスタスレーブ構成のsolrのバージョンアップはサービスアウトしてから入れ替える。 3. 「Solrを用いた検索システムの構築」　by データセクション株式会社 高井さん いろいろな試行錯誤について ○データセクションについて 言語処理を元にデータの解析（Twitterとかブログとか）している会社。 ・昔は自社で検索サーバを構築していた ・Luceneを利用して検索サーバを構築するように変更。 ○構成（過去？） ・Lucene＋RMI 3.0から縮小で、4.0で廃止に ○SolrにするかLuceneにするか？ ・いろいろ機能があるからSolr使ってみるかｗ ○Solr導入は1.4.1から スペック マスタ： メモリ：16G Disk：2Tｘ12 スレーブ： 256GのSSDを利用 JavaVMが32bit ○ひと月分を1shardにして登録 ○検証＋手探り？ メモリが足りない。 Solrのキャッシュを全Offに。 BOBO SolrPluginってのを利用 compressオプションも利用。 各スレーブにキューを用意して1つだけしか処理しない。（なんでだ？？） ○結果 キャッシュはフィルタキャッシュのみ利用 ユーザが同じクエリを投げるのはほぼないので。 フィルタキャッシュのエントリのメモリ量の計算式（あとで資料が出てくるかなぁ。） ○問題点 ・レプリケーションでインデックスサイズの2倍の容量が必要になる。 ・レプリケーションの日時フォーマットのバグ（SOLR-1995）を踏んでしまった。 ・レプリケーション後にインデックスが消えない場合がある ○検討（1.4.1-\u0026gt;3.2） うれしい要素 レプリケーションバグがfix 省メモリや範囲検索の高速化など　かなしい要素 compressが使えなく（しかも回答してからriindexしてくれる） ○検討 余計なインデックス消す nearinfinityが出しているlucene-compressionを利用 https://github.com/nearinfinity/lucene-compression ○残った問題 facet.rangeが使えないなど。 ○じゃあ集約サーバつくっちゃえ（すごいな。） facet書き換えコンポーネントなど。 ○シャードのインデックスサイズが下がった 130GiB-\u0026gt;90GiB これはlucene-compressionの効果 ○ここまでの変更はプラグインにて対応（この一覧いいかも） ○感想 コンポーネント化されてて、簡単に追加機能が実装可能 用途次第であまりスペック高くなくても使える。 Q\u0026amp;A Q：Twitterのデータのクロール方法は？ A：HTMLをスクレイピングしている。publicなTLのみ。 Q：いきなりSolrに入れる？Solrの前処理は？ A：SolrJを利用して前処理済みのデータを登録している。 4. 「Anuenueの紹介と最近の進捗」 by @takahi_i さん（mixi） ○自己紹介 ・NAIST出身 ・ファストサーチ ・今はmixi ○mixiとは？ ○社内の緊急タスク ・内製検索エンジンをメンテナンスしやすいOSSにしたい！ -\u0026gt;Solrを選択 Anuenueも実装 ○Anuenueの作成理由は？ インデックス運用が面倒（検索（distributed search）はあるがインデックスは自前） クラスタ用のコマンドが提供されていない。 ○Anuenueが提供する機能 ・検索クラスタの簡単設定 ・クラスタ用コマンド ・もしかして機能 ○機能：Anuenueのクラスタ設定 Merger：クライアントからのクエリをMasterに分散 Master：インデックス作成側 Slave：検索用スレーブ。マスタからコピー ○クラスタの管理コマンド クラスタのコマンドを用意。 起動、コミット、登録など ○SolrCloud向けのAnuenueを検討中 branch-cloudにあります。 今後の予定 インスタンス追加削除を動的に実行できるようにしたい ○Hadoop Conferenceの宣伝ｗ Oluolu：Hadoop上で動くクエリログマイニングツール Likelike：LSHをHadoopで実装（Hadoop Conference 2011 Fallで発表） 5. LT 5.1　「solrとRの連携について」　by @yutakashino さん（BakFoo） Python本、Zope本を書いてます。 ○NHKの実証実験で利用？ ○TwitterストリームをSolrにストア facet.date ○Rでキーワード頻度グラフ Node.js、Redis、R、Solrを使ってる。しかもPython ○デモ キーワード＋日付でグラフが出てくる。 Rでプロット。 GoogleのチャートAPIを利用すると面白いことができる。 5.2　「 Apache ManifoldCF」　by 阿部さん(ロンウィット) ○Apache Incubator ○Manifold Connector Framework Solr ＜－ MCF ＜－ web＋non-web repositories すぐに利用可能。 ○概要 出力はSolr。 接続先はWeb、DB、CMS、などなどいろいろRepositoryConnectorというのがあります。 ○Crawler Agent クロールに関するJobの管理 接続先、スケジュールなど ○Windowsサーバのクロールもできる 社内のナレッジ共有などに使える。権限周りも簡単に対応可能。 JCIFS.jarによりWindowsの権限情報を取得 ○クロール設定画面もある デモ ○導入が簡単なのがおすすめ。 ○ManifoldCFの資料関連 http://www.manning.com/wright 懇親会についてはあとで記載します！！ ということで追記です。 懇親会でも色々と面白い話を聞けました。 @PENGUINANA_さんにはCOOKPADのCI関連の話を聞けました。 1日に数度リリースするという話もあるようでした。\nあとは、Rについても@yutakashinoさんから概要が聞けたのが良かったです。\nちょっとだけ追記。まだ成形する予定ですが、とりあえず。\n追記：スライドが公開され始めたので。\n関口さんのスライドはこちら 阿部さんのスライドはこちら ＠PENGUINANA_さんのスライドはこちら。 @takahi_iさんのスライドはこちらからPDFダウンロード可能。\nその他に関連するブログも見つけましたので。 「Solr@Cookpad」- Solr勉強会で発表してきました Ars longa, vita brevis: 第６回 Solr 勉強会に行ってきた\n勉強会で出てきた各製品などのリンク： 色々とURLが出てきていたので、リンクをまとめておきます。\nlucene-compression Anuenue Apache Solr のラッパー Likelike LSH (Localtiy Sensitive Hashing)の実装 OluOlu 検索ログマイニングツール @takahi_iさんのLuceneRevolution2011のスライド Kuromoji 形態素解析器 lucene-gosen 形態素解析器（Senの後継） Apache ManifoldCF ","date":1315810980,"dir":"post/2011/","id":"37b622eaad1f79e759a722aacebf48ec","lang":"ja","lastmod":1315810980,"permalink":"https://blog.johtani.info/blog/2011/09/12/%E7%AC%AC6%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-09-12T16:03:00+09:00","summary":"「第6回Solr勉強会」に参加しました。 なんだかんだと第6回で、今のところ皆勤賞です。 ということで、主に自分用ですが、メモなどとったので。 概","tags":["勉強会"],"title":"第6回Solr勉強会に参加しました。(Jugemより移植)"},{"contents":"ということで、Ruby2日目の感想（2日目だけで2日間かかったのは内緒。。。） 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大募集です。コメント欄にどしどしコメントください。そこは違うだろ？こっちのほうがいいのでは？という感じで。\n感想： ◎関数の定義：ありゃ、利用するのはダメなんだ、これじゃ。\u0026ndash;\u0026gt;単なるタイプミスでした。お恥ずかしい。。。 \u0026gt;\u0026gt; def tell_the_truth \u0026gt;\u0026gt; true \u0026gt;\u0026gt; end =\u0026gt; nil \u0026gt;\u0026gt; tell_the_trueth() NoMethodError: undefined method `tell_the_trueth\u0026#39; for main:Object from (irb):4 ◎配列：そしてシンタックスシュガー puts animalsで内容が出力されるのはうれしい。JavaだとHashCodeが出てくるから。出力メソッド書かないといけなくなる。 animals[-1]で最後の要素とかかなり便利。 animals[0..1]はRangeクラスを利用する形。Rangeはやはり便利。substringなどもできそう。 カラ配列の定義は必要。a = [] 1.9と1.8でinclude?の書き方が異なるので注意！ 配列（Array）クラスは中はObjectが入る。 多次元配列もOK。popやpushでキューとしても利用可能。\n◎ハッシュ： Mapのようなもの。任意のキーが利用可能。:付きの文字列はシンボルと呼ばれる定数値を簡単に定義する方法。 object_idという属性？関数によりObjectのハッシュコードが取れるらしい。 ブレース＝「{}」のカッコのこと。do～endでも代用可能\n◎コードブロックとyeild コードブロック＝名前なし関数。習慣では複数行の場合、do/endで、１行は{}みたい。Javaと混同しそう。 コードブロックは引数も指定可能。 「yield」予約語？を利用してコードブロック自体をメソッド内部などで呼び出し可能。 ということで、コードブロックは引数にも指定できると。コードブロック＝関数もObjectとして扱われてる感じか？ 実行遅延、分岐、共通関数とか？Javaだとabstractメソッドを利用して処理するようなイメージか？ちょっと違うなぁ。 なれると、yieldはコードを読みやすくできそう。また、シンタックスハイライトしてくれるツールがあれば、更に便利。\n◎ファイルの実行 ruby ファイル名 vi、Emacs、TextMateなどがあるよ。\n◎クラスの定義 ※数字で始まる変数は利用できない！Javaと一緒 Tree.rbとログを参考にすること。 \u0026amp;使うとブロックに名前が付けられる。yieldじゃなくてもいい？ クラス名はキャメルケース。 変数とメソッド名は「_」アンダーバーつなぎ インスタンス変数の頭は@ クラス変数は@@ 定数は大文字 ※メソッド名、変数名には違和感が。なんでこんな規則？？ 判定用関数とメソッドには「?」（if test?）をつける！！Javaでいう「is」か。\n◎Mixin（多重継承？モジュールと呼ばれるものを利用） 多重継承のような類似の振る舞いを伝搬する仕組み。 Javaではインタフェースでやること。 Rubyではモジュールといい、関数と定数の集まり。 クラスに機能を盛り込む場合はincludeする ※複数includeして、includeしたものの中に同じメソッドとかあったらどーなる？ \u0026ndash;\u0026gt;Overrideされた＝includeがあとにあるもので上書きされる Abstractにできないものをモジュール化できるの楽。 javaだとstaticメソッドだらけのUtilクラスを別途起こすイメージだけど、内部で呼ばれるメソッド（コードブロック）が同じインタフェースじゃないと行けないから、インタフェースの記述もしないと行けない。 ただし、同一名のメソッドを持ってるとややこしそう。 ※モジュールからモジュールは呼べる？\n◎モジュール、Enumerable、セット EnumerableとComparable（JavaのCollectionまわりかな。） 宇宙船演算子（\u0026lt;=\u0026gt;）Javaのequalsに似てる any?とかCollectionUtils？？に似たのあったな。 ※今利用しているクラスが何をincludeしてるかってのは分かる仕組みあるのかな？ ※そういえば、メソッドごとに戻り値があるが、全部newされてインスタンス化されてGCの対象になってるのか？irbだけ？ injectはすんなり使うイメージが出にくそう。また、ソースをぱっと見て理解出来ない。なれだろうけど。 ※injectしながらinjectとかあるんだろうな。\n（探してみよう：） ○コードブロックを使った場合と使わない場合の両方について、ファイルにアクセスするコードを書く。コードブロックの利点は？ ※コードブロックあり。 ``` File.open(\u0026ldquo;tree.rb\u0026rdquo;, \u0026lsquo;r\u0026rsquo;) {|f| f.each {|line| puts \u0026ldquo;#{f.lineno} : #{line}\u0026rdquo;}}\n※コードブロックなし f = File.open(\u0026ldquo;tree.rb\u0026rdquo;, \u0026lsquo;r\u0026rsquo;) while line = f.gets puts \u0026ldquo;#{f.lineno} : #{line}\u0026rdquo; end\nコードブロックの利点： 見通しの良さ。行数が少なくてすむ。繰り返し処理が簡単に記述できる。 ※うーん、まだきちんと理解できてないか？ \u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○ハッシュを配列に変換するにはどうすればよいか？また、逆に配列をハッシュに変換する方法は？\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt; ※間違えた。。。 h = [:key1 =\u0026gt; \u0026ldquo;hoge\u0026rdquo;, :key2 =\u0026gt; \u0026ldquo;boke\u0026rdquo;, :key3 =\u0026gt; \u0026ldquo;fuga\u0026rdquo;] h.each {|key, value| puts \u0026ldquo;#{key} is #{value}\u0026rdquo;} =\u0026gt;key1hogekey2bokekey3fuga is\nハッシュ-\u0026amp;gt;配列変換 h.to_a\n配列-\u0026amp;gt;ハッシュ変換 a = [\u0026ldquo;value1\u0026rdquo;, \u0026ldquo;valu2\u0026rdquo;, \u0026ldquo;value3\u0026rdquo;] h = {} a.each {|i| h.store(a.index(i),i) }\n※また間違い？なんでそうなる？ a.inject(h2) {|hoge, i| hoge[a.index(i).to_s] = i}\nこっちならいいみたい。まだinjectがわかってない。 a.inject(h2) {|hoge, i| hoge[a.index(i).to_s] = i;puts \u0026ldquo;#{i}\u0026rdquo;; hoge}\n\u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○ハッシュの各要素について繰り返すにはどうすればよいか？\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt; h.each {|key, value| puts \u0026ldquo;#{key} is #{value}\u0026rdquo;}\n\u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○Rubyの配列はスタックとしても使える。スタック以外に配列で実現可能なよくあるデータ構造体を挙げよ。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;キュー。 他にある？Treeとか？Treeはハッシュじゃないか？Set？順番が関係ないけど。\u0026lt;/dd\u0026gt; \u0026lt;/dl\u0026gt; ### **（試してみよう：）** \u0026lt;dl\u0026gt; \u0026lt;dt\u0026gt;○最初に、eachだけを用いて、１６個の数値と４個の数値の配列の中身を同時に出力せよ。次に、同じ事をEnumerableのeach_sliceを用いて実行せよ。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt; \u0026lt;span style=\u0026#34;color:#FF0000\u0026#34;\u0026gt;\u0026lt;em\u0026gt;※これ日本語がわからないんだが、4個ずつ出せってことか？？\u0026lt;/em\u0026gt;\u0026lt;/span\u0026gt;ということで、「16個の数字の配列の中身を4個ずつ同時に出力せよ。」と解釈して実装してみた ※each利用版 a = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16] s = [] a.each do |b| unless s.length \u0026lt; 4 puts s.inspect s.clear end s \u0026laquo; b end\n※each_slice a = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16] a.each_slice(4) {|b| puts b.inspect}\nまた、えらい違いだな。 \u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○Treeクラスは面白いクラスだったが、きれいなインタフェースを用いて新しいツリーを指定することは出来なかった。そこで、initializerにハッシュと配列が入れ子になった構造体を指定できるようにせよ。具体的には、次のようなツリーを指定できるようにしたい。{\u0026#39;grandpa\u0026#39; =\u0026amp;gt; { \u0026#39;dad\u0026#39; =\u0026amp;gt; {\u0026#39;child 1\u0026#39; =\u0026amp;gt; [], \u0026#39;child 2\u0026#39; =\u0026amp;gt; [] }, \u0026#39;uncle\u0026#39; =\u0026amp;gt; {\u0026#39;child 3\u0026#39; =\u0026amp;gt; [], \u0026#39;child 4\u0026#39; =\u0026lt; [] } } }\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;\u0026lt;span style=\u0026#34;color:#FF0000\u0026#34;\u0026gt;※root（ここではgrandpaレベル）が複数あると破綻しないのか？\u0026lt;/span\u0026gt; class Tree attr_accessor :children, :node_name\ndef initialize(name, children=[]) @children = children @node_name = name end\ndef initialize(hash) hash.each do |key, value| @node_name = key @children = value.inject([]) do |array, (child_key, child_val)| puts \u0026ldquo;inject! #{key}\u0026rdquo; [Tree.new({child_key =\u0026gt; child_val})] + array end end end\ndef visit_all(\u0026amp;block) visit \u0026amp;block children.each {|c| c.visit_all \u0026amp;block} end\ndef visit(\u0026amp;block) block.call self end end\n残念ながらちょっとカンニングしてしまいました。。。 \u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt; ○ファイル内で、あるフレーズを含む全ての行を出力する簡単なgrepをかけ。簡単な正規表現でマッチングを行い、ファイルから行を読み出す必要がある（この処理はRubyでは驚くほど簡単にかける）。必要なら行番号も出力してみると良い。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;※メソッドだけでいいな。\u0026lt;span style=\u0026#34;color:#0000FF\u0026#34;\u0026gt;ファイルクローズはこの記述の場合はコーディングブロックのendのタイミングでクローズされるのか？\u0026lt;/span\u0026gt; class RegGrep def grep(filename, regexp) File.open(filename, \u0026lsquo;r\u0026rsquo;) do |f| f.each do |line| puts \u0026ldquo;#{f.lineno} : #{line}\u0026rdquo; if line.match(regexp) end end end end\n\u0026lt;/dd\u0026gt; \u0026lt;/dl\u0026gt; ということで、2日目終了。 恥ずかしいコードだらけだけど、ぜひツッコミ入れてもらえると助かります。 数年前までは、恥ずかしいからとか見せられるレベルじゃないからと、ほとんどアウトプットしなかったのですが、 最近はそれではものすごく損をしていると思っています。 ホントは発表するとか議論するとかする場もあればいいのですが。 アウトプットすることで、フィードバックが貰えて、いろんなかたの考えが参考になり、糧となり成長していけるのかと。 （これじゃ成長できないレベルだよという話でなければいいのだが。。。） 一度、Rubyのプロフェッショナル各位に見てもらいたいなぁｗ ","date":1315588260,"dir":"post/2011/","id":"73262345214f9b7794f2cc4a612b15e8","lang":"ja","lastmod":1315588260,"permalink":"https://blog.johtani.info/blog/2011/09/10/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-2%E6%97%A5%E7%9B%AE/","publishdate":"2011-09-10T02:11:00+09:00","summary":"ということで、Ruby2日目の感想（2日目だけで2日間かかったのは内緒。。。） 今回もセルフスタディの私の回答が最後の方に記載されてます。見た","tags":["読書"],"title":"「7つの言語　7つの世界」 Ruby 2日目(Jugemより移植)"},{"contents":"実に3年ぶりくらいにゆっくりできる日々が訪れたので、積読状態の本を消化しようと「7つの言語　7つの世界」を読み始めました。\nせっかくブログも始めたので、備忘録も兼ねて感想などを書いていこうかと。\nこの本ですが、以下の7つの言語についてエッセンスがまとめられています。\nRuby Io Prolog Scala Erlang Clojure Haskell まずはRubyからです。 ここ2年ほどRuby（Rails）に関連する仕事をしていたのですが、Ruby周りはプロフェッショナルな方たちがいたので、きちんと勉強していないことがこの本を読み始めてわかりました。\nということで、前置きはそれなりな記述ですが、感想は適当になりますので、あしからず。\n感想： irbが便利。簡単に動作確認ができるのが便利。Javaだとコンパイルが必要。 変数を定義する必要がない気軽さはある。 必ず戻り値が帰ってくる「puts \u0026lsquo;hello, world\u0026rsquo;」でも。=\u0026gt;nil putsは楽かな。まぁ、Eclipse使ってると一緒か。 「4」もオブジェクトとなっている。ここもJavaと異なる。 (x \u0026lt;= 4).classという記述でTrueClassというクラスだとわかる。 unlessが結構便利。ただし、記述方法が多数あるので、可読性は落ちる？場合によってはわかりやすいか？ あと、括弧()がないのも慣れない。（まぁ、これは慣れの問題。ただし、カッコありでもOK） {}のかわりがif～endなのはわかりやすいかも。 if not はわかりやすくていい。!はだいたい間違えるから。。。 whileも１行形式で書けるのか。「x = x + 1 while x \u0026lt; 10」慣れないと厳しい。個人的には混在すると読めないなぁ。 nilとfalse以外がすべてtrueに評価されるのは厳しいのでは？型のチェックがないので、booleanが入ってると想定してない場合に挙動を読めないかも。実行時に動作が変だなーと思うことが出てきそう。 and、orの記述が使えるのは読みやすい。ただし、混在するとやっかい。 判定結果が明らかになった時点で実行が中止されるのは普通。\u0026amp;、|の挙動はJava同様。\nやりながら疑問点：\nNetBeansとかIDEでフォーマッタやcheckstyleみたいなのはあるのか？ コーディング規約はあるのか？（2日目に「習慣」があるらしいとの記載があった。） 必ず戻り値が戻ってくるのは、必ずGC対象になりうるオブジェクトが生成されるってことか？ ここまでが感想と疑問点。で、この本の面白いところは最後に調査、コーディングを行う練習問題的なものがある部分です。 一応、私なりの答えを書いておこうかと。（一覧などで見えないようにはしますが、ネタバレがあるので注意してください。）\nということで、セルフスタディの回答。\n（探してみよう） ○Ruby API http://ruby-doc.org/core/ ○Programming Ruby: The Pragmatic Programmer's Guideのオンライン版 http://www.ruby-doc.org/docs/ProgrammingRuby/参考資料：http://www.swlab.it.okayama-u.ac.jp/man/ruby/uguide/uguide00.html ○文字列の一部を置換するメソッド \"hello\".gsub(/[aeiou]/, '*') ○Rubyの正規表現に関する情報 日本語：http://www.namaraii.com/rubytips/?%A5%D1%A5%BF%A1%BC%A5%F3%A5%DE%A5%C3%A5%C1 英語の試せるサイト（irbが動けば必要ないかもね）：http://rubular.com/ ○Rubyの範囲に関する情報 日本語：http://doc.okkez.net/static/192/class/Range.html 英語：RDocのRangeクラスに相当するのかな。 （試してみよう） ○文字列\"Hello, world\"を出力する。 ``` ○文字列\"Hello, Ruby\"の中の\"Ruby\"という単語のインデックスを検索する。 ``` s = \u0026lsquo;Hello, Ruby\u0026rsquo; s.index(\u0026lsquo;Ruby\u0026rsquo;) //indexofで間違えた\n\u0026lt;dt\u0026gt;○自分の名前を10回出力する。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;``` ※まずは、正統派。 i = 0 while i \u0026lt; 10 puts \u0026#34;johtani\u0026#34; i = i + 1 end ※Rangeを利用 (1..10).each {|n| puts \u0026#34;johtani #{n}\u0026#34;} ※forもあるよね for i in 1..10 puts \u0026#34;johtani\u0026#34; end ※timesってのもある。（0始まり） 10.times {|n| puts \u0026#34;johtani #{n}\u0026#34;} ※uptoなんてのもあるのか。 1.upto(10) {|n| puts \u0026#34;johtani #{n}\u0026#34;} ※downtoも 10.downto(1) {puts \u0026#34;johtani\u0026#34;} ※stepもある。 10.step(1, -1) {puts \u0026#34;johtani\u0026#34;}//step(上限,ステップ) ```\u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○文字列\u0026#34;This is sentence number 1\u0026#34;の1を10までカウントアップしながら10回出力する。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;``` 1.upto(10) {|n| puts \u0026#34;This is sentence number #{n}\u0026#34;} ※あとは上記と一緒 ```\u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○ファイルに格納されているRubyプログラムを実行する。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;``` vi hoge.rb ※#上記処理をどれか記述 $ ruby hoge.rb ○ボーナス問題：少し物足りない人は、乱数を選択するプログラムを書いてみてほしい。プレーヤーに数字を選択してもらい、その数字が生成された乱数よりも大きいか小さいかを返す。 ``` -- coding: utf-8 -- range = (1..100) while true puts \u0026ldquo;#{range.min}から#{range.max}の数字を入力してください\u0026rdquo; n = gets n = n.to_i if range.include?(n) break; else puts \u0026ldquo;範囲外の入力値です。もう一度入力してください\u0026rdquo; end end i = rand(range.max) if i \u0026lt; n puts \u0026ldquo;入力「#{n}」は乱数「#{i}」より大きいです\u0026rdquo; elsif i == n puts \u0026ldquo;入力「#{n}」は乱数「#{i}」と等しいです\u0026rdquo; else puts \u0026ldquo;入力「#{n}」は乱数「#{i}」より小さいです\u0026rdquo; end\n\u0026lt;/dl\u0026gt; とまぁ、こんな感じ。こんな方法もあるよ、ここおかしくない？などあれば、コメント欄まで。 リアクション大募集です。 はやく、シンタックスライター導入せねば。 ","date":1315545120,"dir":"post/2011/","id":"9baedcd033169611a42c3cfd58b3ae03","lang":"ja","lastmod":1315545120,"permalink":"https://blog.johtani.info/blog/2011/09/09/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-1%E6%97%A5%E7%9B%AE/","publishdate":"2011-09-09T14:12:00+09:00","summary":"実に3年ぶりくらいにゆっくりできる日々が訪れたので、積読状態の本を消化しようと「7つの言語 7つの世界」を読み始めました。 せっかくブログも始め","tags":["読書"],"title":"「7つの言語　7つの世界」 Ruby 1日目(Jugemより移植)"},{"contents":"現在の出先でMBAを使えないので、なかなか進んでいないMBAのセットアップです。。。\nとりあえず、Eclipse、homebrewをインストールしたので、lucene-gosenの開発やビルドには支障がない程度になってきました。（肝心のSolrがまだ動く状況になかった。。。）\nあとは、Windowsで使用頻度の高いソフトを列挙して、対応するMacのアプリを探そうかと。 まずは、Windowsでよく利用するソフトのリストアップ\nEclipse Cygwin TeraTerm WinSCP meadow サクラエディタ WinMerge PDF-XChange Viewer Evernote FreeMind VMWare こんなところかな。 a.～e.についてはMacOS特に問題なし。Eclipseは入れたし、その他は標準で入ってるものでまかなえると。 f.についてもEmacsで当面対応する予定。ただ、OmmWriter やCotEditorがおすすめらしいと聞いてます。 g.についてはFileMergeなるものがあるらしいので、試してみようかと。 h.は現状Adobe Readerです。ほかにいいのあるのかしら。PDF-XChange Viewerはちなみに、Solr入門を書くときに編集の方から教えてもらったPDFのビューワです。コメントとかハイライトできるのが便利でした。 i.はMacOS版をインストールして、すでに活用中。 j.については一時期活用していたのですが、最近利用していないです。なので、保留 k.についてはVirtualBoxをインストールしてみました。フリーだったので。WindowsではVMWareだったのですが。。。\nほんとにこれくらいで大丈夫かどうかはもう少し使ってみてからかなぁと。 その他におすすめ、これがあるとかなり便利などあれば、教えてもらえると助かります。 まだ、MacOSに触り始めたところなので、細かな部分のカスタマイズなどができていないので、その辺りもオイオイ考えていこうかと。\n※余談ですが、現在「７つの言語　７つの世界」を読み始めました。いろいろな言語の特徴について学べる本のようでかなり楽しく感じています。どうしてもJavaで仕事優先だとコーディングする速度優先でJavaばかり使ってしまうので。 いい頭の体操にもなりそうなのでオススメです。（といってもまだ、最初の言語Rubyなのですが。。。）\n","date":1315329480,"dir":"post/2011/","id":"f23ca2aa066b1ee0fa4df1f2f865be4c","lang":"ja","lastmod":1315329480,"permalink":"https://blog.johtani.info/blog/2011/09/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%93/","publishdate":"2011-09-07T02:18:00+09:00","summary":"現在の出先でMBAを使えないので、なかなか進んでいないMBAのセットアップです。。。 とりあえず、Eclipse、homebrewをインストー","tags":["備忘録"],"title":"MBAセットアップ備忘録その３(Jugemより移植)"},{"contents":"すぐにテストケース追加しますといいつつ、はや一週間。\nようやく仕事が落ち着いたので、テストケースを追記しました。まだパッチの段階です。 一応、異なる辞書の読み込みのテストケースなどを追加し、テストケース追加時点で いくつか気になったところもあったので、ついでに修正を加えました。 一応、辞書の分離＋複数辞書対応については現時点ではこんなところかと。\nあと、もう１項目対応してからtrunkに取り込む予定です。 対応する項目とは以下の項目です。\nカスタム辞書ビルドの簡易化 以前の記事にも書いていますが、カスタム辞書のビルドが思いのほか手間がかかります。 辞書の外部化は対応したのですが、せっかく辞書が外部化できたのですから、コマンド（ant？）で一発で カスタム辞書を含んだビルドをしたくなるのが人情です。 辞書なしのjarファイルもあることなので、すぐに対応可能かと。 ということで、今週中には対応する予定です（宣言しないとまた先延ばしになりそう）\n忘れてそうだったらTwitterやコメントでツッコミを入れてもらえると助かります。\n","date":1315328188,"dir":"post/2011/","id":"3c2523e65ff953fd73579aaaf5d7ce36","lang":"ja","lastmod":1315328188,"permalink":"https://blog.johtani.info/blog/2011/09/07/%E8%BE%9E%E6%9B%B8%E5%88%86%E9%9B%A2%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E3%82%B1%E3%83%BC%E3%82%B9%E8%BF%BD%E5%8A%A0%E3%81%A8%E6%AE%8B%E3%82%BF%E3%82%B9%E3%82%AF/","publishdate":"2011-09-07T01:56:28+09:00","summary":"すぐにテストケース追加しますといいつつ、はや一週間。 ようやく仕事が落ち着いたので、テストケースを追記しました。まだパッチの段階です。 一応、異","tags":["lucene-gosen"],"title":"辞書分離のテストケース追加と残タスク(Jugemより移植)"},{"contents":"先日、辞書のjarファイルからの分離についてパッチと記事を書きました。\nIssueにあげていたパッチをRobertさんが見ていたらしく、次のようなコメントをもらいました。\nMaybe if we change SenFactory.getInstance to use a ConcurrentHashMap then you can easily use multiple dictionaries at the same time? 「SenFactory.getInstanceメソッドでConcurrentHashMap使ったら複数辞書対応できるんじゃない？」（訳） たしかに。。。なんで思いつかなかったのだろう。。。\nということで、実装してみました。 パッチはこちら。\n使い方ですが、先日の記事と代わりはありません。 ただし、あった制限事項が次のようになります。\nマルチコアの設定でsharedLibにlucene-gosenのjarを含まない 同一コア内で異なるdictinaryDirの指定はできない ソースの変更点ですが、ものすごく単純です。 dictionaryDirに指定された文字列をキー、その辞書ディレクトリを利用したSenFactoryのインスタンスを値に持つmapをSenFactory内に保持します。あとは、SenFactoryのgetInstance(String dictionaryDir)メソッドで取得する際にmapに対応するインスタンスがあれば、そのインスタンスをなければ、dictionaryDirから辞書を読み込んでインスタンス生成してmapにキャッシュしつつ返すという実装に変えただけです。 ということで、次のようなIPADICとNAIST-JDIC for ChaSenを同時に使う設定も可能となります。\n\u0026lt;fieldType name=\u0026#34;text_ja_ipadic\u0026#34; class=\u0026#34;solr.TextField\u0026#34; positionIncrementGap=\u0026#34;100\u0026#34;\u0026amp;gt; \u0026lt;analyzer\u0026amp;gt; \u0026lt;tokenizer class=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; dictionaryDir=\u0026#34;/tmp/lucene-gosen/dictionary/ipadic\u0026#34;/\u0026amp;gt; \u0026lt;/analyzer\u0026amp;gt; \u0026lt;/fieldType\u0026amp;gt; \u0026lt;fieldType name=\u0026#34;text_ja_naist_chasen\u0026#34; class=\u0026#34;solr.TextField\u0026#34; positionIncrementGap=\u0026#34;100\u0026#34;\u0026amp;gt; \u0026lt;analyzer\u0026amp;gt; \u0026lt;tokenizer class=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; dictionaryDir=\u0026#34;/tmp/lucene-gosen/dictionary/naist-chasen\u0026#34;/\u0026amp;gt; \u0026lt;/analyzer\u0026amp;gt; \u0026lt;/fieldType\u0026amp;gt; あと、注意事項です。 普通に考えるとわかることですが、辞書を複数読み込めるようになったことで、読み込んだ複数の辞書をメモリに保持することになります。ですので、今までよりも多くのメモリを利用するので、Heapのサイズには注意が必要です。 例のごとく（ほんとよくない。。。）テストコードを書いていない状態のパッチをまずはアップしました。 テスト書かないと。。。次回はテストコードかきましたと言う報告をしたいな\nあと、Robertさんのコメントの前に@shinobu_aokiさんからJapaneseTokenizerFactoryの設定では辞書のディレクトリを$SOLR_HOME/confからの相対パスで記述できるというパッチもいただいています。 この部分については先日と使い方が異なります。 （すみません、まだきちんとソースを見れてないです。。。）\n","date":1314668040,"dir":"post/2011/","id":"88a8e608108be939da9aab5a9a8af7d1","lang":"ja","lastmod":1314668040,"permalink":"https://blog.johtani.info/blog/2011/08/30/%E8%A4%87%E6%95%B0%E8%BE%9E%E6%9B%B8%E3%81%AE%E8%AA%AD%E3%81%BF%E8%BE%BC%E3%81%BF%E6%A9%9F%E8%83%BD%E8%BF%BD%E5%8A%A0%E4%BB%AE/","publishdate":"2011-08-30T10:34:00+09:00","summary":"先日、辞書のjarファイルからの分離についてパッチと記事を書きました。 IssueにあげていたパッチをRobertさんが見ていたらしく、次のよ","tags":["lucene-gosen"],"title":"複数辞書の読み込み機能追加（仮）(Jugemより移植)"},{"contents":"ひさびさに、lucene-gosenの話題です。\nlucene-gosenはjarファイルに辞書も同梱されており、jarファイルをクラスパスに取り込むだけで、 簡単に形態素解析器が利用できるといお手軽さがあり、便利です。\nですが、以前カスタム辞書の登録について記事を書いたように、カスタム辞書の登録は思いのほか手間がかかります。 lucene-gosenのソースをダウンロードし、lucene-gosenを一度コンパイルし、カスタム辞書のcsvファイルを作成し、カスタム辞書を取り込んだ辞書のバイナリを生成し、最後にjarファイルにするという作業です。（書くだけでいやになってきました。。。）さらに作成したjarファイルをSolrや各プログラムに再度配布するという具合です。\nそこで、辞書ファイルの外部化ができないかという話があがっていました。 すこし時間ができたので、山積みになっているissueを横目に軽く実装をしてpatchをissueにアップしました。\n機能としてはごく簡単で、JapaneseTokenizerのコンストラクタに辞書のディレクトリ（*.senファイルのあるディレクトリ）を指定可能にしただけです。 また、JapaneseTokenizerFactoryでもdictionaryDir属性で指定可能になっています。 まずは、コンパイルの方法から。 trunkをSVNでcheckoutし、issueにあるpatchをダウンロードして適用します。（svnのチェックアウトについてはこちらを参考にしてください。）\n$ cd lucene-gosen-trunk $ patch -p0 --dry-run \u0026lt; lucene-gosen-separate-dictionary.patch $ patch -p0 \u0026lt; lucene-gosen-separate-dictionary.patch 次に、antを実行し辞書なし版のjarファイルをビルドします。\n$ ant nodic-jar これで、dictディレクトリに「lucene-gosen-1.2-dev.jar」というjarファイルが出来上がります。 （※ただし、これだけでは動作しないので、別途辞書のコンパイルは必要です。）\n次に、指定の仕方です。JapaneseTokenizerのコンストラクタは第3引数に辞書のディレクトリ（フルパスor実行ディレクトリからの相対パス）を渡すだけです。\nTokenizer tokenizer = new JapaneseTokenizer(reader, compositeTokenFilter, dictionaryDir); 最後に、Solrのtokenizerタグでの指定方法です。\n\u0026lt;fieldType name=\u0026#34;text_ja\u0026#34; class=\u0026#34;solr.TextField\u0026#34; positionIncrementGap=\u0026#34;100\u0026#34;\u0026amp;gt; \u0026lt;analyzer\u0026amp;gt; \u0026lt;tokenizer class=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; dictionaryDir=\u0026#34;/hoge/dictionarydir\u0026#34;/\u0026amp;gt; \u0026lt;/analyzer\u0026amp;gt; \u0026lt;/fieldType\u0026amp;gt; 以上が、簡単な設定の仕方です。なお、辞書を内包したjarファイルでもdictionaryDirは利用可能です。優先度としては、dictionaryDirが指定されている場合はdictionaryDirを探索しファイルがなければRuntimeExceptionです。指定がnullもしくは空文字の場合はjarファイルの辞書の読み込みを行います。\n次に利用シーン、制限事項についてです。 利用シーンとしてはカスタム辞書を定期的にメンテナンス（追加更新）しながらSolrを運用するというのが想定されます。定期的に辞書の再読み込みをしたい場合です。 利用方法は次のようになります。\nSolrのマルチコア構成を利用する 各コアごとにlib/lucene-gosen-1.2-dev.jarを用意 辞書の更新が終わったらコアのRELOADを実施 コアをリロードすることで、lucene-gosenが辞書を再読み込みようになります。（現状でも再読み込みするが、jarファイルを再配置しないといけない。）あとは、定期的に辞書ファイルを更新、再構築しコアをリロードすれば、 リロード後に新しい辞書が利用できるという具合です。 （もちろん、辞書更新後に入った単語は辞書更新以前に作成したインデックスにはでてこないですが。。。） また、コアごとにdictinaryDirを別々に指定することも可能です。\n制限事項は次のようになります。\nマルチコアの設定でsharedLibにlucene-gosenのjarを含まない 同一コア内で異なるdictinaryDirの指定はできない 以上が、辞書の外部ファイル化のパッチについてでした。 少しテストケースを追加したら、trunkにコミットする予定です。興味があれば、パッチを利用してみてください。\nSyntaxHighlighterの導入をしないとソースコードが見にくいですね。。。導入を検討しないと。。。どこかにWebサーバ用意しないとダメかも\n","date":1314062760,"dir":"post/2011/","id":"2f1ec795216d5bafa33a810af3421942","lang":"ja","lastmod":1314062760,"permalink":"https://blog.johtani.info/blog/2011/08/23/%E8%BE%9E%E6%9B%B8%E3%81%AEjar%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%8B%E3%82%89%E3%81%AE%E5%88%86%E9%9B%A2/","publishdate":"2011-08-23T10:26:00+09:00","summary":"ひさびさに、lucene-gosenの話題です。 lucene-gosenはjarファイルに辞書も同梱されており、jarファイルをクラスパスに","tags":["lucene-gosen"],"title":"辞書のjarファイルからの分離(Jugemより移植)"},{"contents":"すみません、また、MBA関連の記事になってしまいました。 ということで、備忘録その２です。\n前回からいくつかインストールや環境の設定をしたので、リストアップ。\nVirtualBoxとWindowsのインストール homebrewのインストール KeyRemap4MacBookのインストール Growlのインストール Time Machine用HDDの購入と設定 VirtualBoxのインストールとWindowsXPのセットアップ。会社関連でどうしてもWindowsが必要なので、 とりあえず、VirtualBoxとWIndowsを入れました。これまでのWindows環境ではVMWareを利用してたのですが、 Macだと有償ということで、無償版が存在するVirtualBoxを選択。 MBAにはDVDのドライブがなく、また、ケチって購入しなかったので、ちょっと手間取りました。 自宅のデスクトップでXPのイメージをisoにして、MBAにコピーしてからインストールと。。。 ただ、MBAのSSDの効果なのか、XPの起動がすごく速くてびっくりです。\nhomebrewのインストールは、まだインストールしただけの状態。。。 MacPortsってのがあるというのは知っていたのですが、最近はこちらがいいとのこと。 ちなみに、MacPortsにはSolrがあるらしいです。デフォルトのため、lucene-gosenとか入れる必要がありますが。\nKeyRemap4MacBookのインストール。入れた方がいいですよと言われてたのだが、きちんと調査してなく、 キーの入れ替えができる程度だと思ってました。昨日、EmacsModeなるものが存在するというのをKeyRemap4MacBookのドキュメントを読んでいて発見し即インストール。 とりあえず、Ctrl-x,Ctrl-cでEvernoteが終了できて喜んでるところです。\nGrowlのインストール。KeyRemap4MacBookのCtrl-xを通知してくれます。ほかにも使い方があるかは調査が必要。\nあとは、昨日、ビックカメラでWDの2TBのHDDを購入してTimeMachineの設定をしてバックアップをとりました。 まだバックアップをとっただけで、差分を見たりはしていないです。帰ってからやってみようかと。\n最後に、ケースを買いました。封筒とかいろいろ考えたのですが、やはり機能重視ということで、以下のケースです。 できれば、ファスナーが２つついていて、両方からあけられるとよかったのですが。リュックとショルダーバッグを使い分けるので、横でも縦でも取り出しが楽なものがよかったので、このケースを買いました。 一応、がんばれば縦でも出せるので。あとは、PCだけもって移動することもあるため、取っ手があるのが便利かと。\nとまぁ、お盆なので、このエントリーで許してください。次回は技術的なことを書きますので。。。 CaseLogic 機能的なモバイルコンピュータケース(13~14.1インチPC対応)、MacBookやMacBook Proにも対応 ダークグレー UNS-114J-DG ","date":1313369460,"dir":"post/2011/","id":"ce0aea06d44878b4a373efe090a66a62","lang":"ja","lastmod":1313369460,"permalink":"https://blog.johtani.info/blog/2011/08/15/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%92/","publishdate":"2011-08-15T09:51:00+09:00","summary":"すみません、また、MBA関連の記事になってしまいました。 ということで、備忘録その２です。 前回からいくつかインストールや環境の設定をしたので、","tags":["備忘録"],"title":"MBAセットアップ備忘録その２(Jugemより移植)"},{"contents":"Mac Book Airのセットアップ関連の備忘録\n（今回は備忘録なので、文体も変かも）\nインストールしたもの（順不同）だいたい、このサイトを参考にした。\nEvernote Dropbox XCode Twitter YoruFukurou GNU Emacs For Mac OS X Java Office for mac 現状はこんなところ。\nまだ、キーボードの配列とショートカット、ウィンドウの切り替えなどがすぐにできないので、かなりおぼつかない状態。\nCtrl+aなどの操作は快適なのだが、ウインドウを閉じたりする場合のcommandキーの扱いがまだなれない。キー配置を切り替えたりした方がいいのか悩み中。 Windowsでは長年XKeymacsを使ってきたため、通常のOfficeなどもCtrl+x　Ctrl+sなどで閉じていたので、command＋qなどがすんなり出てこない。。。\nあとは、VirtualBoxにWindowsを入れて、Eclipseを入れればなんとか、WindowsPCからMBAへの切り替えができそう。\n残っている課題は以下の通り。\nTime Machine環境の整備USB接続のHDDの導入（ミラーリング対応にするか悩み中）※ちなみにうちで使ってるNASは古い＋NFSマウントできない機種だった。。。　対応可能だったらScientific Linux＋Netatalk環境などを用意するのも考えたんだが。 homebrewのインストール 日本語入力（GoogleIME？SKK？） ウォークマン、Xperia arcの運用方法まぁ、今まで使ってたPCで対応かな キーの配置Emacsのショートカットに変更できたりするか調査したい データの移行Windowsに入ってるデータのうち移行するものしないものの選別Macでは利用できないデータやファイルもあると思う。 解凍ツールの選別？いるのかな？ ブラウザのインストールchrome、Firefoxはいれるかな。 メーラーのインストールWindwosではBecky!を使ってたのだが、どうするか。デフォルトメーラで様子見？ ウイルス対策ソフトの導入Macってどんなソフトがあるかがわからない。。。 あと、１週間触っての感想\nまずは、良かった点。\nいろんなUIがよくできてるセットアップなどきれいな画面で説明が進むのが新鮮だった。あと、フォントのきれいさも新鮮。これは、今までのPCが古いからかもしれないが。 トラックパッドがいいまだなれてないけど、スイスイ動くのでストレスなく作業できる。スワイプとかも画面の移動が楽でいい。 静かで速いSSDのため、静かだし起動がすごく速い。会社で支給されてるPCもSSD（３年くらい前のもの）だけど、こんなに起動などがはやくない。 あとは、気になった点。\nAppStoreでページ間のスワイプができない。かなり使いづらい。Safariと同じイメージでいるので。 手首がいたい手前のエッジ部分が手首に当たってちょっといたい。 アプリインストール時にファンがうるさい動画などはまだ見てないが、Office、XCodeのインストール時にファンの排気音がうるさくなり、結構な熱を発していた ファーストインプレッションはこんな感じ。\nただ、前回も書いたようにうらやましかったのもあり、かなり満足している。 もっと触る時間が欲しいのだが、なかなかとれないのが歯がゆい。。。\n持ち歩くようになったらとりあえず、「７つの言語　７つの世界」を読み進め＋写経をやる予定。\n","date":1312904760,"dir":"post/2011/","id":"c0e423f9ac41cc5b265c95a3e97e3fcb","lang":"ja","lastmod":1312904760,"permalink":"https://blog.johtani.info/blog/2011/08/10/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2/","publishdate":"2011-08-10T00:46:00+09:00","summary":"Mac Book Airのセットアップ関連の備忘録 （今回は備忘録なので、文体も変かも） インストールしたもの（順不同）だいたい、このサイトを参考にした。 Evernote Dropbox","tags":["備忘録"],"title":"MBAセットアップ備忘録(Jugemより移植)"},{"contents":"個人用のPCを８年ぶりに新調しました。\n前回購入した家のデスクトップPCがもう８年ものになりつつあるということで、\nさすがに今年はPCを買おうと思い、年初からいろいろと調べていました。\n当初は次もデスクトップPCを購入する予定でした。ただ、次のような状況ということもあり\nデスクトップは見送ることにし、代わりにノートPCにすることに。\n通勤時間が１時間を超えること\n基本、客先に出向いての仕事\n家でPCに触る時間が少ない（家族サービスのため。）\nで、ここ数週間悩んでいたのですが、Mac Book Air 13インチを購入しました。（そのMBAから初投稿です。）\n実は、Apple製品はこれが初の購入となります。\n対抗馬としてあがっていたのはSonyのVAIO Type Zでした。\n元々ソニスト（ソニー大好き）であり、携帯（Xperia arc）、ウォークマン（Sony）、PSP go、ハンディカムなど、\nソニー製品に囲まれており、デザインもType Zのほうが好みなのですが、MBAを購入しました。\nこの理由なのですが、私が大学時代にさかのぼります。\n情報系の大学の出身で、はじめてきちんと触ったマシンがSunOS4.1（最後の数年はSolaris2.6）でした。\nその後、大学６年間は基本的にEmacsでメールをみて、Emacsで文章を書いていました。\nそのため、社会人になってからもEmacsのキーバインドから抜け出せない日々を送っていました。\n社会人ではやはりWindowsでしたが、XKeymacsというフリーソフトのおかげ（せい？）でEmacsの\nショートカットからは抜け出せないまま。（家のPCはXPで、XKeymacsがインストールされてます。）\n今までの流れだと、何も考えずにWindows7+XKeymacsの流れだったのですが。。。\n職場でWindows7のPCを使う機会があり、XKeymacsを入れてみたのですが、これまでとことなり、\nうまく機能しないことこの上なし（例：chromeのアドレスバーでCtrl+Kとかできないなど）。\nさらに、64bit版の場合、XKeymacsを32bit、64bitの２つインストールしないといけないことに。（32bit用アプリのために32bitを入れないといけない）\nで、数ヶ月使っているのですが、ちょっとずつストレスがたまっている始末。。。\n今までは、「Mac？今更恥ずかしくてかえない」「Mac？おしゃれすぎて無理」「Apple？MSにかわって独占してるの気に食わん」と公言していたのですが。。。\nやはりUnixベースであり、Ctrl+aやCtrl+kが意識せずに利用できるということでコーディングなどを行う場合のストレスよりも保守的な思考を変える方が今後のためにも良さそうだということで、心機一転MBAを購入しました。\nということで、ついにApple教へ入信です。\nまだ、１時間も触ってないですが、すでに洗脳されつつあります。。。\n新しいものに触れるのって楽しいですよね。当分は何をインストールするかなど楽しい悩みでいっぱいになれそうです。（次回はちゃんとした技術的な記事書きたいと、書けるかな、書くぞ、たぶん。。。）\nとまぁ、いろいろと理由を書いてみましたが、要は（オシャレさに）憧れてて、あまのじゃくになって思ってもないこと言ってたんです！\n理由が欲しかったんです！！\nMacかっこえーわーw\nMac miniとかiMacとかもほしーわー\n","date":1312389240,"dir":"post/2011/","id":"7ed1d2efa3e0f0ed6b77eb4eff3d86b3","lang":"ja","lastmod":1312389240,"permalink":"https://blog.johtani.info/blog/2011/08/04/apple%E6%95%99%E3%81%AB%E5%85%A5%E4%BF%A1%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-08-04T01:34:00+09:00","summary":"個人用のPCを８年ぶりに新調しました。 前回購入した家のデスクトップPCがもう８年ものになりつつあるということで、 さすがに今年はPCを買おうと","tags":["備忘録"],"title":"Apple教に入信しました(Jugemより移植)"},{"contents":"かなり遅くなりましたが、第1回 データ構造と情報検索と言語処理勉強会 #DSIRNLPに参加しました。\n帰ってから２日半ほど寝込んでしまい、更新が遅れました。。。\n初の土曜日開催の勉強会でしたが、家族を説得してなんとか参加しました。\nおかげで色々と面白そうなキーワードが拾えてよかったです。（拾っただけで理解するのはかなり時間がかかりそうですが。。。）\nということで、前回同様、個人的にメモを取ったので。誤記などあるかもしれませんが、その時はコメントいただければと。\n0.DSIRNLPについて\n※ボランティアで受付してたので聞けず。\n1.TRIEにトライ！～今日からはじめるTRIE入門～\n@echizen_tm さん\n資料：http://www.scribd.com/doc/58688141/Try-for-Trie\n1.TRIEの説明\n実装についてはあとでスライドをみればいいか。（※ボランティアで受付してたので前半聞けず）\n・パトリシア木\n・Double Array\n・LOUDS\n・XBW\n2.作ってみた\nその1　ベーシック\nQ.ノードのラベルどーする？\n・固定長（ラベル＝1文字）\n定数時間でアクセス可能\n・可変長（ラベル＝任意文字列）\nPatricia木に拡張可能\nA.拡張性を考えて可変長に！\n3.LOUDSとは？\n概要\nJacobsonが提案　Level-Order Unary Degree Sequenceの略（いつからLOUDSになったのか不明）\n構築済みTRIEからLOUDSを構築\n作業領域がO(NlogN)からO(N)に\n・ノードに幅優先で順番（Level-Order）をつける\n・子ノードの数を付ける。Unary符号で実装\n作ってみた\n・UnaryよりVerticalCodeのほうがよさそう\nhttp://d.hatena.ne.jp/echizen_tm/20100531/1275323074\n・dag_vectorを使ってもいいかもよ？\n4.QA\nQ.可変長を配列にすればいいんじゃね？\nA.単純にやると効率悪そう？\n※LOUDSをlucene-gosenに適用するとなんか嬉しいことあるかな？\n現状はDouble-Arrayだけど。\n2. ランキング学習ことはじめ（Solr系に利用できそうな予感。。。ごごご。。。むずかしい。。。）\n@sleepy_yoshi さん NTTのSuharaさん「話がうまい」\n数原　良彦\n自己紹介\n情報検索、ランキング学習をやってる。\n三浦半島在住\nねらい\nランキング学習の認知度を高める、ざっくり伝える。　ごめんなさい　「実装」についてをわすれてた。\n・ランキング学習とは？\nLearning to rank\npreference learningとは違う\n教師あり機械学習で検索ランキングに適用\n・歴史\n従来は単一ランキング\nクエリ・文書関連度（TF-IDF、BM25）\n文書の重要度（PageRank、HITS、SALSAなど）\n近代的なランキングの実装方法\n上記データを利用して関数を適用する。\n・何を正解とするのか？\n適合性評価の作成方法\n評価点数を多段階で点数化\nランキング評価方法\nランキングを正解データと比較\nNDCG（Normalized Discounted Cumulative Gain）　※分類問題におけるモデルの生成\nTraining Data＋学習アルゴリズム＝＞モデル\nランキング学習の訓練データ\n素性や評価はクエリごとに変わってくるTraining data（ここが違う）\nここまでのまとめ\n正解データは適合度至上主義！\nランキング学習手法\n３つのアプローチ\n教師あり機械学習（識別学習）≒\nどのような目的関数/損失関数を\nどのように最適化するのか\nアプローチ\n1.Pointwise手法\n単一のデータに対して損失関数を設定\n2.Pairwise手法\n同一クエリのペアに対して損失関数を設定\n3.Listwise手法\n同一クエリのリストに対して損失関数を設定\nPointwise：あまりつかえない。\n例：二値分類（適合＋１不適合－１）で学習\n補足：Perceptron\n例：PRank\nしきい値と重み両方修正する。\nPairwise：Pointwiseよりいいらしい\n文書ペアで損失を設定\nMQ2007、MQ2008データセットの結果\nPairwise手法とListwise手法を比較しても\nそんなに悪くないらしい\nIR-SVMってので偏りなどを排除できて、精度向上になるよ\nNLP2011でPARankっての発表したよ（手前味噌）\nQA\nQ.じゃんけんみたいに循環しない？（nokuno）\nA.半順序のデータだと起きるが、検索の場合は全順序なので大丈夫だよ\nListwise：Pairwiseよりいいらしい\nListNetってのあり。\nAdaRank\n検索評価指標を直接最適化するブースティング手法\n性能はいまいち？実装は簡単\nその他の話題\nClick-through logs\nQuery-dependent ranking\nFeature selection\nTransfer learning/Domain adaptation\nDiversity/Novelty\n公開Dataset\nLETOR3.0/4.0 Dataset\nMSLR-WEB Datasetなど\n実装\nRankingSVM\nStoch\u0026hellip;.\nLearning to Rank教科書\n英語の資料が今年複数出たみたい\nまとめ\n近代的な検索エンジンは多数のランキング素性を利用\n評価データを用いてランキング素性の最適な重み付けを求める方法\n。。。\n機械学習手法は論文≒実装\nなので、ソースコード見るほうが重要（論文にないノウハウがあるよ）\n3.snappy調べてみた\n@machy　町永圭吾（赤いポータルサイト）\nTopCoderなどで活躍中？\n・snappyは圧縮/伸張ライブラリ\nzlibよりサイズが大きいけど一桁はやいですぞ。\n・インストールなど\ngoogle－gflagsってのがないと動作しないよ。\n・比較してみた（zlib）\n一桁は言い過ぎだけど、はやかった。\n・比較してみた（lzo）\nHadoopで利用されているlzo\nはやかった。\n・仕組みは？\nzlib　辞書式符号化＋ハフマン符号化＝出力\nsnappy　辞書式符号化＋リテラル＝出力\n・辞書式符号化は？\n前に出てきたデータで同じ文字列の部分について端折る\n・ハフマン符号化\nよく出てくる記号を短い符号で置き換えることで圧縮する。\n・snappyの符号化\n基本バイト単位での処理にすることで、高速化してるみたい。\n・snappyの辞書参照元の探し方\nハッシュテーブル利用してマッチする位置を検索\n4byte窓でハッシュ値を計算してハッシュテーブルを更新\n・圧縮しにくいデータ（同じ単語が出てこないパターン）について\n圧縮をあきらめ始める（32回同じのが見つからないと窓の移動幅が1つずつ大きくなる）\n16KB（フラグメント内）での比較回数が1008回に抑えられる。\n・特徴\nハッシュがしょうと移したらあるはずのマッチが見つからないこともある。\nメモリ消費量を抑えるためのハッシュのサイズ？\n最悪ケースのサイズを予め確保してから処理するため、メモリの再確保が起きないのではやいぞ。\n4.類似文字列検索してますか？\n@overlast さん　Yな会社\n1.曖昧な情報を処理する能力\n曖昧な情報を解決しようとする能力が高い。\n例：お笑い芸人の芸がサンプルｗ\n画像検索は曖昧クエリに答える例。。。\nスターバックス、スタバ、SUTABA\nスータバでも画像が出てきた。-\u0026gt;女子高生とかが「スータバ」で画像をアップしてたりするから。\n文字列を使った検索は現代のインフラになってるよね。\n例：iタウンページ\nタイトルとかに「スターバックスコーヒー」って書いてないとだめ。？\n「スタバ」800件くらい　-\u0026gt;　正規化で「ー」消してるんじゃないの？\n「スータバックスコーヒー」0件　ちがうな。シノニム辞書登録してるな。\n曖昧なクエリ（キーワード）から検索できないかなぁ？\n曖昧情報の処理は文字列処理にこそ必要\nなんでヒットしたかがわかるのが正解　なんでヒットしたかわからないけど、ちゃんと出てきたから正解！\n2.ゼロ件ヒット問題（ゼロマッチ）\nピクシブ百科事典\n「ピングドラム」だと17件\n「ピンクドラム」だと0件　しかも真っ白！！\n使いにくいよね。けど、一般的な検索システムの問題だよね。\nGoogleだと出てくる「ピンクドラム」の結果の最初にはピングドラムが出てくる。\n-\u0026gt;リンクがはられているから出てきた？みんなの間違いで助けられてる\n食べログ\n「俺のハンバーグ」\n「俺はハンバーグ」で検索したら。。。「俺はハンバーグで連れは。。。」がヒット-\u0026gt;しらねーよｗ\nまとめ\nゼロ件ヒットは機会損失！！\n3.曖昧な文字列で正しい文字列を探す方法\n正しい文字列って？\n1.表記誤りがない\n2.心の底で求めている\n※異表記同義、同表記異義、異言語表記（日本語の情報を英語で検索）などもある\n正しさはユーザによって変わる。\n正しい文字列をさがす手法\nクエリ表記の正誤という軸\n誤の場合表記をヒントに似た文字列を検索してみる。\n探したい対象が正確か曖昧か\n表記意外がヒントで同じ対象に到達できる？\nどんな情報を手がかりにする？\n編集距離（レーベンシュタイン）\n検索ログ\n4.Apporoの紹介\nチョコ？いや、ロケット？いや、Approximate \u0026hellip;\nhttp://code.google.com/p/apporo/\n中小規模だと使えそう\nSimString\n今後\nよみかな、ローマ字表記に基づく類似文字列検索＋高速化の予定\n技術概要\nSuffix Array\nN-gram Searchベースの近似文字列照合\nBit Parallel Matchingによる編集距離計算\n5.検索と言語と文化（仮）\n@mizuno_takaaki さん\n放送禁止のためメモなし。\n7.自然言語処理におけるargmax操作\n@hitoshi_ni さん\n※順番変更\n・近似解法\nその１　全探索\nいや、無理でしょ、計算が。\nその２　貪欲法\n最適解が出るかは不明。\nその３　ビームサーチ\n上位kこの仮説を保持しながら幅優先探索\n・動的計画法\nすでに最大値がわかっていて、ゴールから眺めてみる。\n逆からたどるとルートがわかるんじゃないか。\nマルコフ性につけ込むことで、わかるんじゃないか。\n計算量：品詞数の2乗\n（品詞数の2乗）＊形態素数\nDPの実装\nViterbiかなぁ？\n・整数計画法（線形-\u0026gt;整数）\n自然言語処理としては整数計画法でだいたいOK。\nアルゴリズム\n・手元の解空間中から許容解を得る\n・分枝してそこから最大値を求める\n最大値＞許容解ならそちらを探索。\nプログラム実装する？\nすごく大変じゃないけど簡単でもないね。\n問題の弱点がわかってるなら実装してもいいよね。\n整数計画法の場合lp_solveなどのフリーのソフトで解くのがいいよ。エクセルでも解けるよ\nILP（整数計画法？）\n問題の切り分けに使える。\nまとめ\nILPで解けたら、いろいろ自分で考えると面白いよ。\nその他のバズワード\n参考資料\n組み合わせ最適化＝1万円超\nアリ本\n6.ソーシャルグラフ分析(導入編)\n@kimuras さん　mixiの木村さん\n・グラフ探索部分はまた今度。\n・テキストマイニングや検索エンジンまわりやってる。\n・ノードが数1千万、エッジが数億のオーダー\n・分散技術の発展によるアルゴリズムの多様化\nこれまで\nRDBからDumpしたデータをKVSに入れて頑張ってた。\nDump部分でデータ構造を毎回構築\n問題点\n変更による再実装、メンテナンスコスト、\nこれから\ngraphDBに取組中。マイニングに最適な感じ\ngraphDBの実装\nOrientDB、Neo4jとか\nNeo4jって\nACIDトランザクション可能\nEmbeddedGraphDatabaseだとAGPLｖ３だから気をつけてね。\nluceneで全文検索インデックスつくってるみたい。\nGremlinってのがquery言語を汎化してるらし。\nとあるSNSのデータを使ってみたよ。\nメモリ64G、CPUは1コアしか使えなかったよ。\nノード：15million、枝：600million\nまとめ\nということで、色々と面白い話が聞けました。特にTRIEの話はかなり興味を持ちました。\n検索周りで嫌というほど出てくるので。まだまだきちんと理解できてないので復習しないと。。。\nlucene-gosenにも関係あるので、しっかり資料をみて復習する予定です。\n基本的に検索系の話に関連があることが多くて面白く聞くことができました。\n「類似文字列検索してますか？」や「ランキング学習ことはじめ」などは身近な話（だけど、なかなかきちんと学習できてない話）でした。\nまた、「自然言語処理におけるargmax操作」では大学でやっていた線形計画法などのわかりやすい説明で10年経ってようやく理解ができた次第です。。。（もっとちゃんと勉強しとけば。。。）\n懇親会にも参加し、研究に近い分野の方が多い中でいろいろな話が聞けたのはよかったと思います。\n次回もいろいろなキーワードを拾いたいのでぜひ参加したいです。\n","date":1311737580,"dir":"post/2011/","id":"3811b40721f7ca651887aac4eb17f9f0","lang":"ja","lastmod":1311737580,"permalink":"https://blog.johtani.info/blog/2011/07/27/%E7%AC%AC1%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-07-27T12:33:00+09:00","summary":"かなり遅くなりましたが、第1回 データ構造と情報検索と言語処理勉強会 #DSIRNLPに参加しました。 帰ってから２日半ほど寝込んでしまい、更新が","tags":["勉強会"],"title":"第1回 データ構造と情報検索と言語処理勉強会に参加しました。(Jugemより移植)"},{"contents":"以前から春山さんのブログ（リンク）や勉強会で耳にはしていたのですがソースは読んでいませんでした。 先日、Luceneにcontributeされた（リンク）ので軽くソースを読んでみました。\n公式サイトはこちら\nまずはMeCabのページにある比較表（リンク）を基準に特徴を調べてみました。せっかくなので、lucene-gosenも隣に。\n\u0026nbsp; Kuromoji lucene-gosen 解析モデル なし（学習機能なし） なし（学習機能なし） コスト推定 なし（学習機能なし） なし（学習機能なし） 学習モデル なし（学習機能なし） なし（学習機能なし） 辞書引きアルゴリズム Double Array Trie Double Array Trie 解探索アルゴリズム Viterbi Viterbi 連接表の実装 2次元 Table 3次元 Table 品詞の階層 無制限多階層品詞？ipadic、unidic形式に対応 無制限多階層品詞 未知語処理 字種 (動作定義を変更可能)（おそらく。） 字種（変更不可能） 制約つき解析 たぶん、不可？ たぶん、不可？ N-best解 不可能 不可能 こうやって比較してみるとlucene-gosen（Sen）とあまりかわりはありませんが、lucene-gosenが少し古いのがわかりますね。。。\nKuromojiで利用出来る辞書は現時点ではMeCab IPADIC、UNIDICの2種類のようです。\nソースを読んでの感想ですが、やはりMeCabが偉大だということがよくわかりました。 Senよりも新しいMeCabの処理に似ている点が多いです。解探索アルゴリズムや連接コスト表が特に。 MeCab向けの辞書を利用しているためというのもあるかと思います。\nKuromojiが特徴的なのは「searchモード」と呼ばれるモードが用意されていることです。 公式サイトにある例ですと、「関西国際空港」が「関西」「国際」「空港」というTokenで出力されます。 ソースを見たところViterbiアルゴリズムで辞書を探索しているときに特定の条件でコストをカサ増しすることで、結果を変えるという処理を行っているようです。\n全て漢字の単語：3文字以上の場合に「(単語の長さ-3)*10000」をコストに加算 その他の単語：7文字以上の場合に「(単語の長さ-7)*10000」をコストに加算 このようにコストを変化させることで「空港」でも「関西国際空港」という文字を含む文章が検索できる仕組みになっています。 また、「拡張searchモード」と呼ばれるモードも存在し、こちらは、未知語をuni-gramで区切って出力を行うようです。\nソース上で確認しただけで、未確認ですが、GraphvizFormatterというクラスがあるので、Graphvizで読み込める形式で形態素解析の結果が出力されるかもしれません。（すみません、確認してなくて。）\n未知語の処理やsearchモードなど面白い機能があるので、試してみるのもいいかもしれません。lucene-gosenを考えていく上でも参考になりそうです。\n最後に余談ですが、FAQのページ（リンク）が面白いです。。。\n","date":1311132540,"dir":"post/2011/","id":"5a765f9668608a39333fa90cf462657e","lang":"ja","lastmod":1311132540,"permalink":"https://blog.johtani.info/blog/2011/07/20/kuromoji%E3%82%92%E8%AA%BF%E3%81%B9%E3%81%A6%E3%81%BF%E3%81%9F/","publishdate":"2011-07-20T12:29:00+09:00","summary":"以前から春山さんのブログ（リンク）や勉強会で耳にはしていたのですがソースは読んでいませんでした。 先日、Luceneにcontributeされ","tags":["形態素解析"],"title":"Kuromojiを調べてみた(Jugemより移植)"},{"contents":"忘れてしまうので、備忘録を残しておきます。 一応、ソースには少しずつコメントをいれてはいるのですが。 私は残念ながら、自然言語処理は初心者に毛が生えた程度（現在、鋭意勉強中）で、対応方法に問題があるかもしれません。気づいた方はコメントをいただけると助かります。\n辞書ファイルについて NAIST-JDic for MeCabの辞書ファイルは以下の構成になっています。\nファイル名 メモ char.def 文字種の設定 feature.def 辞書学習用の設定？ left-id.def左文脈IDのマスタ（左文脈ID、品詞情報） matrix.def 連接コスト表（前件文脈ID,後件文脈ID,連接コスト） pos-id.def 品詞IDのマスタ（品詞情報、ID） rewrite.def rewrite情報（左右文脈に出現した場合のそれぞれの品詞情報のrewriteルール。辞書学習で主に利用） right-id.def 右文脈IDのマスタ（右文脈ID、品詞情報） unk.def 未知語の品詞情報（文字種ごとに未知語のコスト、左右文脈ID、品詞情報が記載されている） naist-jdic.csv 単語辞書（単語、左右文脈ID、単語コスト、品詞情報、読みなど記載） 現時点では、MeCabDicPreprocessorでは以下のファイルを利用しています。\nleft-id.def matrix.def right-id.def naist-jdic.csv 上記以外のファイルは現時点では利用しない実装になっています。 ただし、rewrite.def、unk.def、char.defについては利用したほうがよりMeCabに近い結果が得られるような気がしています。（特に文字種ごとのコストを利用することは有効と思われます。）\nPreprocessorでの処理について lucene-gosenはSenの後継であり、MeCabの昔のバージョンを移植したものがベースとなっています。 lucene-gosenとMeCabの現時点での実装の大きな違いとして、連接コスト表の違いがあります。 ここからは憶測になってしまいますので、注意してください。（論文を探せばどこかにこの実装の変化の過程が記載してあるかもしれないですが、まだ探していません、すみません。） 過去のMeCabではChaSen向けの辞書を利用していました。 ChaSenでは連接コスト表が3つの項（前の前、前、後）から構成されていました。（n項まで定義可能らしい） ですので、lucene-gosenのViterbiアルゴリズムの引数も3つのノードが引数となっています。 lucene-gosen向けの連接コスト辞書も同様の作りになっています。 一方、現在のMeCabは先ほど書いたとおり、matrix.defでは2項の連接コスト表（前、後）となっています。この違いを保管するために、Preprocessorでは、matrix.defを3項にするために一番左（前の前）については任意の品詞を採用できるように「,,,,,,*」のみを設定しています。\n現時点では、Preprocessorの出力である中間ファイルを共通の形式に出力することで、DictinaryBuilder以降の処理に変更を加えることなくNAIST-JDic for MeCabへの対応を行う形を取りました。まずは使えるようにするのが先かと思いまして。 ただ、MeCabの辞書の構成から考えると中間ファイルに落とし込む処理に無駄があると感じています。 matrix.defでせっかく、IDによる連接コスト表を構成しているのに、IDを品詞情報の文字列に戻したconnection.csvを生成していますので。\nということで、備忘録でした。 あとは、テストをどうするか（正解をどう考えるか）なども考える必要があります。現時点での悩みの種です。。。アイデア募集中です。\n","date":1310432760,"dir":"post/2011/","id":"c70b78fd0b5dffcd38322355e9c2471e","lang":"ja","lastmod":1310432760,"permalink":"https://blog.johtani.info/blog/2011/07/12/naist-jdic-for-mecab%E3%81%AEpreprocessor%E3%81%AE%E5%AE%9F%E8%A3%85%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E5%82%99%E5%BF%98%E9%8C%B2/","publishdate":"2011-07-12T10:06:00+09:00","summary":"忘れてしまうので、備忘録を残しておきます。 一応、ソースには少しずつコメントをいれてはいるのですが。 私は残念ながら、自然言語処理は初心者に毛が","tags":["lucene-gosen"],"title":"NAIST-JDic for MeCabのPreprocessorの実装に関する備忘録(Jugemより移植)"},{"contents":"lucene-gosen 1.1.1をリリースしました。\n先日お知らせしたバグ修正を取り込んだjarを用意いしました。\nダウンロードはこちらから\n","date":1309777240,"dir":"post/2011/","id":"229975f1e84b5088e819cd5f2dc43080","lang":"ja","lastmod":1309777240,"permalink":"https://blog.johtani.info/blog/2011/07/04/lucene-gosen-1-1-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2011-07-04T20:00:40+09:00","summary":"lucene-gosen 1.1.1をリリースしました。 先日お知らせしたバグ修正を取り込んだjarを用意いしました。 ダウンロードはこちらから","tags":["lucene-gosen"],"title":"lucene-gosen 1.1.1リリース(Jugemより移植)"},{"contents":"Solr/Lucene 3.3がリリースされました。（速報）\n以下、各サイトへのリンクです。\nSolrリリースのお知らせ\nLuceneリリースのお知らせ\nリリースのタイミングがどんどん早くなってる。。。\n","date":1309501779,"dir":"post/2011/","id":"10eb1e7dc64d8ca3dad92641dadb5de7","lang":"ja","lastmod":1309501779,"permalink":"https://blog.johtani.info/blog/2011/07/01/lucene-solr-3-3%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/","publishdate":"2011-07-01T15:29:39+09:00","summary":"Solr/Lucene 3.3がリリースされました。（速報） 以下、各サイトへのリンクです。 Solrリリースのお知らせ Luceneリリースのお知らせ リリースのタイミ","tags":["solr"],"title":"Lucene/Solr 3.3リリース（速報）(Jugemより移植)"},{"contents":"「Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）」に参加しました。300名入るイベントルームでしたが、後ろの方まで人が埋まっていました。\nということで、主に自分用ですが、メモを取ったので。\n※二次会行きたかった。。。\n1.「鉄道システムへの誘い」\n@ayasehiro（本名無理w）\nHadoopの話はありません。\n○鉄道系基幹システムの開発\n実態：\n耐用年数：１０年以上\n開発期間：数年～５年程度\n開発規模：～10Mステップ、10k人月～\nほとんどテスト、しかも異常系が主体。\n夜間に実際に鉄道を走らせて試験したり。\n開発サイクルが長い\n人材育成が難しい、ノウハウがたまらない。\n開発自体はほとんど時間がなく、設計・製造・試験など新規技術の採用が難しい。\n開発４年前の調査・検証自体が２年程度。\nHadoopも調査中。\n○鉄道システム３大システム\nマルス（予約オンラインシステム）（1960～）\nコムトラック（運行管理システム）（1972～）\nヤックス（ヤード自動化システム）（1968～1984）\n○鉄道輸送システムとは\n用語：\n運行を計画する=\u0026gt;輸送計画\n列車を運行する=\u0026gt;運行管理\n需要想定＋営業施策＋その他（お召し列車など）＝列車ダイヤ作成\n基本計画（長期）＋短期計画（数日～四半期程度）＝列車ダイヤ（重ねあわせてできあがり）\nダイヤの計画（発車時刻など）と車両運用（車両自体の走る組み合わせ（仮の車両））の作成\n＋乗務員運用（乗務員の運用計画）\n運行管理：\nなにも起きなければすることなし。（車両故障、天候、人身事故などによる整合性を取る作業）\n＝事前に計画した輸送計画をすべて見直し\n遅延の検知は？\n昔：人による伝令\n今：システムによる検知（レールに電流流して検知）\n運転整理（実際に遅れた）：\n部分運休、折り返し駅の変更などにより対応\n元の計画になるべく近づく形で修正していく。\n新幹線、山手線、京浜東北線などは速度信号という信号が表示される。\n線路上に信号はないらしい。\n○鉄道システムを取り巻く情勢\n少子高齢化・人口減少のため凋落産業となっている。\n社会インフラの責務＝動くのが当たり前\n2007年問題（ベテランの引退）＝スジ屋さんは最近いないらしい。\n高度な判断支援をするシステムが必要\n連続稼動＝分散技術を適用できない？\n関係各所との情報共有\n計画立案のための情報支援＝最適化技術を適用できない？\n○分散処理技術の適用\n個人的な感想\n可用性（連続稼動）のための仕組み\nバッチ処理\n○分散技術の適用\n・連続稼動\nactive-active構成がメイン\n主系の出力だけを行う。問題が出れば副系の出力。\n3系統の出力を比較器にて出力もある\nmagiシステム\n問題点：\nハードが高い（H社）\nソフトウェアの作り込みが複雑＝テストが前パターンできない\n解決案：\n汎用的なハードが使いたい。\n作り込みも減らしたい\n・バッチ処理：\nAsakusa使えないかなーw\n○最適化技術の採用\nコンピュータ技術の発展\n2007年問題\n職人に言わせれば最適化はいらない、俺の言うことを聞けｗ\n・車両運用のモデリング\n車両数大=\u0026gt;組み合わせ大\n制約条件が多い\n車両運用の場合、走行累積キロの条件もある\n-\u0026gt;有向グラフにモデル化される。（ただし、グラフ化するまでが大変）\n・乗務員運用のモデリング\n車両と違い、乗務員は1回で2人とか運べる（運転士＋移動する人とか）\n・車両割当のモデリング\nやはり、グラフ化が可能\n・乗務員交番のモデリング。。。など\n結構一般的なモデルに落とし込める。ただし、落し込みが大変。\n机上研究だったものが、コンピュータの発展により実証研究になりつつある。\n○まとめ\n鉄道システムはまだまだ未到の領域が残っている。\n開発サイクルが長いため、保守的な開発になる（35年前の設計思想からあまり変わってなかったりする）\nしかし業務要件やシステム利用者の意識は変化している\n興味を持たれた方は、ぜひ、我社に！（社名は2次会でｗ）\n○Q\u0026amp;A\nQ：鉄道システムのカルチャーってイケイケ？保守的？（@okachimachiorgさん）\nA：最新技術も知らないとだめじゃないかという人が出てきている。\nコア部分（安全第一なところ）＋周辺領域（ある程度融通が効きそうな部分）と考えることができるんじゃないかって人も出てきている。\nJR九○＝先進的\nJR四○、北○道＝お金ない\nJR○海＝超保守（企業的に超保守）\nJR東、西＝うーむ？\n東京メト○（運行計画）、阪○＝先進的\n京○急行＝基本人間で進路制御w\n基本的には新しいものには興味をもつ人たちでは。\nQ：Su○caとかで分散処理は利用出来るんでは？\nA：匿名なので外側から見ていると分散処理はいろいろ使えるんでは？\nログデータからいろいろできるんじゃないの？活かすべきでないの？\n使いどころはいっぱいある。\nQ：鉄道システムでどうしようもなくなったことはあるか？\nA：保守体制が一番気になる。\nOSSとかならまだ調べられる。ミドルウェアなどの保守契約が必要。\n保守体制が確立されてればある程度の保守費用は飲み込む。\nどうしようもないことはないが、今すごく困ってることは\nExcelで帳票を出したいとかいわれること。（ちょっと前に作ったシステムでExcel2003。バージョンあげると速度が遅くなったりするｗ）\nilog社のものを使ってたが、IBMに買収されて保守費用があがってこまってるｗ\n保守が10年と長いため、サポートなどの折衝が必要。\nQ：最適化の適用範囲は？\nA：走行順序（どこで追い抜くか）の算出に活用。ほぼ完成でユーザ教育中。\n1列車の波及がかなり影響が出る。ダイヤだけ見ると列車だけだが、乗務員も関係しており、大変。\nある時点から終電までを最適化の対象としたりして割り切っている。\nまた、不足分について算出が出来れば、そこで打ち切ったりもする。\n2.「九州電力におけるHadoopの取り組みについて」\n株式会社キューデンインフォコム e－ビジネス部　@hisashi_yano\n概要：2年間関係したOSSをメインにしたシステムの話。\n○九州電力の概要\n現在風当たりが強い業界。\n東電の1/10くらい\n部門ごとに大手ベンダーが関わってる。\n○Hadoop採用の経緯\n部門ごとに個別最適なシステムを導入していてベンダーロックインされてる。\n・ホストのリプレース\n・両現用センター構成への対応\n・スマートグリッドへの対応\n問題点\n・コスト削減\n・技術革新への中の人の対応（内部でも問題を理解できるように）\n・商用パッケージのカスタマイズの限界\n・脱ベンダーロックイン（実は楽なんだけど。。。）\n○過去2年間の研究内容\n・H21年度の結果\nテーマ：クラウドの要素技術の研究\nKVM、Eucalyptus、wakame、hadoop　性能比較：VMWareとKVM-\u0026gt;ベンチマーク比較\n結論：性能的にあまり問題なし。\nMapReduceの耐障害性など\nダミーデータにより台数増加による影響を検証\n結論：台数大-\u0026gt;性能向上\nストリーミングは性能劣化する\nスループットはリニアに向上\n信頼性は？\n実行中にノードを抜いたりして検証。\n結論：問題なし。\nクラウド環境におけるシステム管理手法\n複数ハードで1アプリという構成になる。\n監視対象が膨大になる。\n障害発生時の切り離しや監視対象も膨大。\nデータセンター自体を監視する仕組みが必要では？というところで終了。\n・H22年度の結果\n分散に特化した研究\n前年度の課題\nサーバの仮想化・管理に関する課題\n分散処理に関する課題\n分散処理環境の運用監視に関する課題\n目的：\nHadoopを本番への適用（実際にはダミーデータ＋本番の仕組み）\n柔軟なサーバ統合基盤（サーバを起動-\u0026gt;バッチを起動-\u0026gt;回す仕組み）＝MonkeyMagic\nlibvirtを使ってる\n50台の仮想サーバの起動が10数分で完了。\n運用監視基盤（monkey magic）\n仮想、実サーバ混在の監視\n監視状況（サーバの状況）から判断して制御する仕組みを構築\nDSLにてルール（判断＋制御）を指定\n・ジョブの監視\n・ジョブの実行管理\n・構成管理の省力化\nvolanteと連携が可能＝AmazonWebServiceとも連携可能\n・サーバリソース＋アプリケーションの一括監視が可能\n分散バッチ処理の概要\nRDBからKV形式にして抽出し、MRで回してRDBに戻すという研究\n対象：\n配電部門（電柱の設備情報の目視検査）のデータの月間バッチ処理\n現状：\n19時間程度かかってる。\nテスト環境：\n実サーバ2台（仮想10台）\nMySQL、Javaで実装\n処理内容\n電柱104万本\n巨大バッチを分割して実装\n結果\nMySQL1台では15日以上かかる処理（現行システムで19時間）\n処理が32分で終了！他でも効果でるよね。\nバッチ短縮の理由は？\n1.データアクセスが分散された\n2.処理の並列化（多重化出来る部分がうまくできた）\n分散処理を書くのに2名死亡。。。\n適用基準の策定、開発ガイドライン、フレームワーク整備などが必要。\n・H23年度は？\nAsakusaの適用など。\n・さらに今後は？\nスマートグリッドへの適用\n-\u0026gt;メーターの交換が必要だが、10年くらいかかる\n-\u0026gt;スパンが長い（10年）ので商用製品だときつい？\nデータ量も半端ない。\nテネシー州とClouderaでOpenPDCってのやってるらしい。\n電力と気温の関係は密接な関係あり。\nエアコンが割合を占めてるから。\n過去実績と予想気温データから分析するのにHadoop使える！\n・2年間やってきて思うこと\n将来目指すべき理想像を掲げるのが重要\n新技術導入は段階を踏むことが必要\nコミュニケーション大切！\n○Q\u0026amp;A\nQ：仮想化環境のオーバヘッドは？（I/O）\nA：台数を増やしたときにどうなるか？というのを検証したかった。\nアプリ配布も考えていたので、物理サーバに縛られたくなかった。\nQ：仮想化に関して気をつけたM/RのPGで気をつけたことありますか？\nA：まったくないです。\nQ：日本でスマートグリッドははやるの？\nA：電力会社的にはやりたくない。費用対効果があまりない。\nQ：今後のスケジュールは？\nA：文書管理システムの組織名変更などの処理時間が540時間とかでてくるらしい。\nこれをHadoopで対応してみようかと思ってる。\nQ：Asakusaをどう評価していくのか？\nA：開発効率性があがるか？は検証する予定。1/3くらい楽になるんじゃないかなぁ？byのぐちさん\nバッチの種類などにもよると思うが、標準化も指標にする予定。\n結果はまたこの場で報告する予定。\nQ：Asakusa＋MonkeyMagicの連携はどんなこと考えてる？\nA：MonkeyMagicを運用基盤として行く予定。合意が取れればだけど。\n※MonkeyMagicもOSSにするよー\nまとめ\nHadoopから少しずつ離れつつありますが、やはり興味があるので、非常に楽しく話を聞けました。\nまた、今回はインフラ分野のシステムということで、システムに要求されるレベルや\n運用周りにも気を配っている話が聞けたのが収穫でした。保守期間が長いため、テストが長い＝\n運用もしっかりと考慮を入れた設計、実装が必要になるというのは最もだと思います。\nただ、少しずつ修正が入るアジャイルなども同様かと。\nMonkeyMagicが出来上がってきた背景の話を聞いて、さらに興味が湧いてきたところです。\n今後もかかわりが少ないかもしれないですが、ウォッチしていきたいと思いました。\nただ、興味あるモノが多すぎるので、優先度をつけつつこなして行かないと。。。\n少しずつでも身につけていきたいと思う今日このごろです。\n※追記：Twitterでコメントを頂いたので、忘れないように追記。\nコメントを貰えるだけでもうれしい。やはり、アウトプットしたらフィードバック貰いたいし。\nありがとうございます！\nTwitter / @cocoatomo: あの質問をまとめるとこうなるのかぁ…… 最適化そのも \u0026hellip;\nTwitter / @cocoatomo: @johtani すみません, コメントはコメント欄 \u0026hellip;\nTwitter / @cocoatomo: @johtani そこらへんの理論って最後には計算量 \u0026hellip;\nTwitter / @cocoatomo: @johtani あの話し振りだとどうもまだ本格的に \u0026hellip;\nあと、まとめも出来ていたので、ついでに。\nTogetter - 「2011/06/29_Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回） #hadoopmodeling」\n関連するブログも見つけたので。\n第5回Hadoop座談会の感想 - ひしだまの変更履歴\nHadoopモデリング座談会（第5回）へ行ってきました - 虎塚\n","date":1309356600,"dir":"post/2011/","id":"49ba23148db9effdc3979aa0fe5876ea","lang":"ja","lastmod":1309356600,"permalink":"https://blog.johtani.info/blog/2011/06/29/hadoop%E3%82%92%E4%B8%AD%E5%BF%83%E3%81%A8%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E7%92%B0%E5%A2%83%E3%81%A7%E3%81%AE%E9%96%8B%E7%99%BA%E6%96%B9%E6%B3%95%E8%AB%96%E3%83%A2%E3%83%87%E3%83%AA%E3%83%B3%E3%82%B0%E8%A8%AD%E8%A8%88%E6%89%8B%E6%B3%95%E7%AD%89%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E5%BA%A7%E8%AB%87%E4%BC%9A-%E7%AC%AC5%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-06-29T23:10:00+09:00","summary":"「Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）」に参加しました。300名入るイベントルー","tags":["hadoop"],"title":"Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）に参加しました。(Jugemより移植)"},{"contents":"以前、こちらで話題に上がっていた「未知語」に関するcompositePOSのエラーの件を調査しました。（Twitterでも流れてました。） 次のような条件の場合にエラーが発生するようです。\ncompositePOSの設定に構成品詞として「未知語」が指定されたエントリが存在する。 未知語が連続して出現する文字列をanalyzeする。（例：ニンテンドーDSi） ということで、trunkに修正版をコミットしました。 Issueはこちら。\n※お茶をにごす感じの日記になってしまいました。次回はマシな記事を書く予定です。。。\n6/29追記：恥ずかしいバグをいれこんでしましました。。。 ということで、trunkに再度修正版をコミットしました。\n","date":1309232160,"dir":"post/2011/","id":"f6dff70097776e24c2a7c9c0f2514f79","lang":"ja","lastmod":1309232160,"permalink":"https://blog.johtani.info/blog/2011/06/28/compositeposcompositetokenfilter%E3%81%AE%E3%83%90%E3%82%B0%E4%BF%AE%E6%AD%A3/","publishdate":"2011-06-28T12:36:00+09:00","summary":"以前、こちらで話題に上がっていた「未知語」に関するcompositePOSのエラーの件を調査しました。（Twitterでも流れてました。） 次","tags":["lucene-gosen"],"title":"compositePOS（CompositeTokenFilter）のバグ修正(Jugemより移植)"},{"contents":"lucene-gosenのtrunkbranches/impl-mecab-dicにNAIST-JDic for MeCabの辞書を利用出来るPreprocessorをコミットしました。\nビルド方法は次のとおりです。\n$ cd lucene-gosen-trunk $ ant -Ddictype=naist-mecab 現在のstable版で利用できる辞書は「ipadic」「naist-chasen」の2種類でした。\n[以前の記事](http://johtani.jugem.jp/?eid=4)に書きましたが、naist-chasenの辞書でも2008年の更新となっています。\n今回コミットしたPreprocessorでは[NAIST-JDicのサイト](http://sourceforge.jp/projects/naist-jdic/)で公開されているMeCab向けの辞書である「mecab-naist-jdic-0.6.3-20100801」を利用出来るようになります。\nただし、lucene-gosenは昔のMeCabから派生したSenをもとにしていますので、最新のMeCabが持っている機能は\n利用できません。\nMeCab向けの辞書のうち一部のもの（matrix.def、naist-jdic.csvなど）を利用してlucene-gosen向けの辞書の中間ファイルを生成する仕組みになっています。\nまだ、仮実装版ということで、とりあえず動作するバージョンとなっています。\nまだテストが不十分ですが。。。\n利用してみて問題などあれば、lucene-gosenの[issue](http://code.google.com/p/lucene-gosen/issues/list)に登録していただくか、コメントを頂ければと思います。\n※更新が週1回に落ちてきてるので、もう少し頑張らねば。\n※2011/07/04追記 trunkにコミットしていましたが、branchに一旦移動しました。 仮実装として一旦コミットしたので、trunkとは別でテストする必要があるかと思った次第です。 ということで、試してみたい方は、[branches/impl-mecab-dic](http://code.google.com/p/lucene-gosen/source/browse/#svn%2Fbranches%2Fimpl-mecab-dic)にありますので、触ってみてください。 ","date":1308609480,"dir":"post/2011/","id":"991285e3967c3295b4ff2dcd835f7c61","lang":"ja","lastmod":1308609480,"permalink":"https://blog.johtani.info/blog/2011/06/21/naist-jdic-for-mecab%E5%AF%BE%E5%BF%9C%E7%89%88%E4%BB%AE%E5%AE%9F%E8%A3%85/","publishdate":"2011-06-21T07:38:00+09:00","summary":"lucene-gosenのtrunkbranches/impl-mecab-dicにNAIST-JDic for MeCabの辞書を利用出来るPre","tags":["lucene-gosen"],"title":"NAIST-JDic for MeCab対応版（仮実装）(Jugemより移植)"},{"contents":"前回、naist-chasenではアルファベットが別々の単語としてanalyzeされてしまうという話をしました。\nただ、これだと、英単語が含まれた文章を形態素解析すると、英単語がアルファベット単位に区切られてしまい、 単語の意味をなさなくなってしまいます。\nlucene-gosenでは、この問題に対応するための方法が提供されています。 CompositeTokenFilter（compositePOS）という機能です。\n文字通り「トークン」を「合成」するための機能になります。\n利用するためには以下の作業が必要です。（※Solrでのの利用方法を説明します。）\ncompositePOS設定ファイル（composite_pos_ja_naist-chasen.txt）の用意 schema.xmlのtokenizerにcompositePOS設定を追加 まずは、compositePOS設定ファイルの記述方法について説明します。 compositePOS設定ファイルには１行につき１つのcompositeの設定を記述していきます。 記述方法は次のようになります。品詞名を半角スペース区切りで記述します。\n連結品詞名 構成品詞名1 構成品詞名2 ... 構成品詞名n それぞれは次のような意味を持ちます。\n連結品詞名：合成したあとのトークンの品詞として出力する品詞名 構成品詞名：合成したい品詞名（スペース区切りで複数指定可能） TokenizerのcompositePOS機能は、構成品詞に定義されたトークンが連続して出力された場合に、 結合（合成）して１つのトークン（連結品詞名）として出力します。 また、以下のように構成品詞名が１種類で連続品詞名としても利用する場合は次のように省略した記述も可能です。\n以下にcompositePOSファイルの設定例を上げます。 ※なお、現時点では#によるコメント機能はありません。ので、記述した内容がそのまま利用されます。\n名詞-数 未知語 記号-アルファベット １行目は連続した数字を1つのトークン（名詞-数）として出力する設定です。（連続品詞名＝構成品詞名として省略して記述した例になります。） 2行目は連続したアルファベットを１つのトークン（未知語）として出力する設定です。\n次にSolrのschema.xmlにlucene-gosenのtokenizerを利用するフィールドタイプの設定を記述します。 $SOLR_HOME/conf/schema.xmlに以下を追加します。\u0026lt;types\u0026gt;～\u0026lt;/types\u0026gt;タグの間に記載します。\n... \u0026lt;types\u0026amp;gt; ... \u0026lt;fieldType name=\u0026amp;quot;text_ja\u0026amp;quot; class=\u0026amp;quot;solr.TextField\u0026amp;quot; positionIncrementGap=\u0026amp;quot;100\u0026amp;quot;\u0026amp;gt; \u0026lt;analyzer\u0026amp;gt; \u0026lt;tokenizer class=\u0026amp;quot;solr.JapaneseTokenizerFactory\u0026amp;quot; compositePOS=\u0026amp;quot;composite_pos_ja_naist-chasen.txt\u0026amp;quot;/\u0026amp;gt; \u0026lt;/analyzer\u0026amp;gt; \u0026lt;/fieldType\u0026amp;gt; \u0026lt;/types\u0026amp;gt; ... 重要なのはtokenizerタグのcompositePOS属性になります。ここに1.で記載したファイルを指定します。指定したファイルはschema.xmlと同じディレクトリに配置します。 以上が利用するための設定です。\n前回同様、「このComputerは、10回に1回の割合で起動中に青い画面が表示されます。」という文章をanalyze画面で解析した結果を示します。\nとまぁ、記事を書きましたが、すでにこちらで出ている話ですね。。。\nみなさん手が早くて困ってますｗ\nちなみに、上記の設定の場合、「100,000」や「3.14」といった文字列は「100」「,」「000」という形で出力されてしまいます。これらも数字とみなしたい場合は「名詞-数 名詞-数 記号-句点 記号-読点」という設定で１つのトークンとして出力されます。ただし、「。」も「記号-句点」なので注意が必要です。\n※なお、今回はlucene-gosen-1.1.0、Solr3.2を利用した例になっています。 ","date":1307977200,"dir":"post/2011/","id":"50f43b1726cf61066ef8656477b226be","lang":"ja","lastmod":1307977200,"permalink":"https://blog.johtani.info/blog/2011/06/14/compositepos%E3%81%AE%E5%88%A9%E7%94%A8%E4%BE%8Bnaist-chasen%E3%81%A7%E3%81%AE%E8%8B%B1%E5%8D%98%E8%AA%9E%E3%81%AE%E5%87%BA%E5%8A%9B%E6%96%B9%E6%B3%95%E4%BE%8B/","publishdate":"2011-06-14T00:00:00+09:00","summary":"前回、naist-chasenではアルファベットが別々の単語としてanalyzeされてしまうという話をしました。 ただ、これだと、英単語が含ま","tags":["lucene-gosen"],"title":"compositePOSの利用例（naist-chasenでの英単語の出力方法例）(Jugemより移植)"},{"contents":"lucene-gosenの1.1.0がリリースされました。\n大きな目玉はJapaneseTokenizerが出力する形態素に関するデータを遅延ロードすることで、パフォーマンスの改善を行ったことです。\n詳しくは関口さんのブログで実測されてます。さすが、早い。。。 あと、先日リリースされたLucene/Solr 3.2への対応も行われています。\nlucene-gosen-1.1.0のダウンロードはこちらから。\nうーん、中身がない記事だ。。。\n","date":1307934480,"dir":"post/2011/","id":"eeef60efe889349870426d10edc694be","lang":"ja","lastmod":1307934480,"permalink":"https://blog.johtani.info/blog/2011/06/13/lucene-gosen-1-1-0-%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2011-06-13T12:08:00+09:00","summary":"lucene-gosenの1.1.0がリリースされました。 大きな目玉はJapaneseTokenizerが出力する形態素に関するデータを遅延","tags":["lucene-gosen"],"title":"lucene-gosen 1.1.0 リリース(Jugemより移植)"},{"contents":"lucene-gosenをSolr/Luceneで利用する場合、TokenFilterを利用してTokenizerが出力したToken対してさまざまな処理（Tokenに対する正規化や展開など）を追加することが可能です。\n今回は現在（ver. 1.0.1）用意されているTokenFilterについて説明します。 以下はTokenFilterの一覧です。 「フィルタ名」にはSolrのschema.xmlで記述するクラス名を書いてあります。\nフィルタ名(Factory名) 概要 solr.JapaneseWidthFilterFactory 全角のASCII文字を半角に、半角カタカナを全角にするフィルタ。例：「Ｃｏｍｐｕｔｅｒ」-\u0026gt;「Computer」 solr.JapanesePunctuationFilterFactory 区切り文字、記号などを除外するフィルタ。[※1](#token_filter_kome_1) solr.JapanesePartOfSpeechStopFilterFactory 設定ファイルに記載した品詞に該当するTokenを除外するフィルタ。ファイルは「tags=\"ファイル名\"」とfilterに記載。なお、ここで記述する品詞とはanalysis画面に表示される「partOfSpeech」の完全一致となります。 solr.JapanesePartOfSpeechKeepFilterFactory 設定ファイルに記載した品詞に該当するToken\"以外\"を除去フィルタ。ファイルは「tags=\"ファイル名\"」とfilterに記載。なお、ここで記述する品詞とはanalysis画面に表示される「partOfSpeech」の完全一致となります。 solr.JapaneseBasicFormFilterFactory Tokenを基本形に変換するフィルタ。例：「悲しき」-\u0026gt;「悲しい」 solr.JapaneseKatakanaStemFilterFactory カタカナの長音（ー）の正規化フィルタ。4文字以上のカタカナのみの文字列の最後の長音（ー）を除去した文字列に変換します。例：「コンピューター」-\u0026gt;「コンピュータ」、「コピー」-\u0026gt;「コピー」 上記のTokenFilterをJapanizeTokenizerを利用するフィールドタイプに設定することで 各フィルタによる機能が有効になります。 schema.xmlの記載に関する詳細についてはこちらを参考にしてください。\n※1　Characterクラスの以下の定数に相当する文字が。SPACE_SEPARATOR、LINE_SEPARATOR、PARAGRAPH_SEPARATOR、CONTROL、FORMAT、DASH_PUNCTUATION、START_PUNCTUATION、END_PUNCTUATION、CONNECTOR_PUNCTUATION、OTHER_PUNCTUATION、MATH_SYMBOL、CURRENCY_SYMBOL、MODIFIER_SYMBOL、OTHER_SYMBOL、INITIAL_QUOTE_PUNCTUATION、FINAL_QUOTE_PUNCTUATION\n","date":1307344980,"dir":"post/2011/","id":"4b046ac6a4796fb1338f0481dbd4003d","lang":"ja","lastmod":1307344980,"permalink":"https://blog.johtani.info/blog/2011/06/06/lucene-gosen%E3%81%AEtokenfilter%E3%81%9F%E3%81%A1/","publishdate":"2011-06-06T16:23:00+09:00","summary":"lucene-gosenをSolr/Luceneで利用する場合、TokenFilterを利用してTokenizerが出力したToken対して","tags":["lucene-gosen"],"title":"lucene-gosenのTokenFilterたち(Jugemより移植)"},{"contents":"辞書の特性について 現在lucene-gosenでは以下の2つの辞書が利用可能です。 簡単に違いについて説明します。\nIPAdicの辞書について\nバージョン：2.6.0（※IPAdicとして公開されている最新は2.7.0） 最終更新日：2003/06/19 登録単語数：約24万語 NAIST-Jdicができたためか、更新されていない NAIST-Jdic-for-ChaSenの辞書について\nバージョン：0.4.3（※NAISTとして公開されている最新はMeCab用の辞書0.6.3） 最終更新日：2008/07/07 登録単語数：約28万語 IPAdicの後継として整備。品詞の定義など大まかな仕様は共通。 IPAdicと異なり、アルファベットや数字が1文字ずつ単語として登録されている。 IPAdicとNAIST-Jdicで大きな違いはアルファベットと数字の扱いについてです。 次のような文章をそれぞれの辞書で解析した結果は次のようになります。(SolrのField Analysisの画面です。思いの外大きいのでサムネイルのみですが。) 「このComputerは、10回に1回の割合で起動中に青い画面が表示されます。」 ○IPAdicの場合 ○NAIST-Jdicの場合 「Computer」と「10」という単語の区切り方が異なることがわかります。 この違いは、辞書のエントリが異なるために発生します。 NAIST-Jdicでは、数字（例：「1」）やアルファベット（例：「a」）が個々のエントリで登録されているため、分割された単語として認識されます。\n※この問題への対応方法はまた後日。\nカスタム辞書について 実際のデータを形態素解析したい場合、辞書に存在しない単語を登録して、1単語として認識させたい場合があります。（固有名詞など） このような場合にカスタム辞書を利用することで、新しい単語を辞書に登録することが可能になります。 カスタム辞書を利用する手順としては次のようになります。\nカスタム辞書ファイルの作成 作成した辞書ファイルを利用したjarファイルの生成 まずは辞書ファイルの作成についてです。 以下では、naist-chasen(NAIST-Jdic)の辞書を例として説明します。（ディレクトリの違いだけで、IPAdicでも同じ方法でOKです。）\nlucene-gosenでは辞書のコンパイルに2つのフェーズが存在します。\ngosen用辞書を生成する前処理（中間csvファイルの生成） gosen用バイナリ辞書の生成 カスタム辞書は1の出力の形式(=中間csvファイル=dictionary.csv)にあわせたCSVファイルとして作成します。 CSVの各カラムは次のような意味を持っています。\n単語 単語の生起コスト 品詞 品詞細分類1 品詞細分類2 品詞細分類3 活用型 活用形 基本形 読み 発音 3カラム目以降は「素性（そせい？）」と呼ばれる項目です。ipadic、naist-jdicでは「品詞」「品詞細分類1」「品詞細分類2」「品詞細分類3」「活用型」「活用形」「基本形」「読み」「発音」となります。 ※「見出し語」「形態素生起コスト」「素性」と呼ばれる項目を表形式にする。 厳密な品詞の体系に関してはIPAdicやNAIST-Jdicのサイトをご覧ください（説明できるレベルにはまだまだなっていないので。。。） 今回は、固有名詞（人名、地名など）を追加するという例でカスタム辞書について説明します。 固有名詞として「達川」という人名を追加してみましょう。 まずは、次のようなエントリをもつ「custom-dic.csv」ファイルを作成します。ファイルはUTF-8で保存してください。 コストはすでにあるエントリで似たようなエントリのコストを真似します。（今回は固有名詞,人名で似ているものを採用）。ちなみに、コストは小さいほど単語として出てきやすくなります。 ※カスタム辞書にはSenで利用していたものが利用できます。 **\"達川\",2245,名詞,固有名詞,人名,名,*,*,\"達川\",\"タツカワ\",\"タツカワ\"** 上記ファイルを、先日紹介した$LUCENE-GOSEN/dictionary/ディレクトリにコピーします。 では、カスタム辞書を含んだlucene-gosenのjarを作成しましょう。 カスタム辞書のビルドは$LUCENE-GOSEN/dictionary/で行います。 また、カスタム辞書の指定はCSVファイル名をantの引数で指定します。次がコマンドの例になります。\n$ cd lucene-gosen-trunk $ cd dictionary $ ant -Ddictype=naist-chasen clean-sen $ ant -Ddictype=naist-chasen -Dcustom.dics=\u0026#34;../custom-dic.csv\u0026#34; compile $ cd .. $ ant -Ddictype=naist-chasen 上記コマンドの例で\u0026quot;clean-sen\u0026quot;というタスクを実行しています。これは、すでに出来上がっているgosen用のバイナリ辞書を削除するタスクになります。すでにgosen用の辞書が作成されている場合には辞書の再生成が行われないためです。 また、複数のファイルを利用したい場合は-Dcustom.dics=\u0026ldquo;custom-dic.csv custom-dic2.csv\u0026quot;という形でスペース区切りでファイル名を記述すればOKです。\nカスタム辞書を適用する前と適用後の違いは次のとおりです。 適用前 適用後 簡単ですが、以上がカスタマイズ辞書を利用する方法でした。 ちなみに、この記事を書く前にすでにカスタム辞書の件を書いているブログがありました。。。こちらも参考にしてください。 今回の例でいくつかSolrのanalysis画面を利用して説明してきました。Solrでのlucene-gosenの利用方法についてはまた後日記載したいと思います。 ※参考までに。Solrでの利用方法はこちらにも記載してあります。\nまた、IPAdicなどの辞書について記載のある書籍を見つけましたので、参考になれば。\nアプリケーションソフトの基礎 (講座ITと日本語研究) ","date":1307002560,"dir":"post/2011/","id":"b2621497b3313c97855ed951f0d9b291","lang":"ja","lastmod":1307002560,"permalink":"https://blog.johtani.info/blog/2011/06/02/%E8%BE%9E%E6%9B%B8%E3%81%A8%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E8%BE%9E%E6%9B%B8%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2011-06-02T17:16:00+09:00","summary":"辞書の特性について 現在lucene-gosenでは以下の2つの辞書が利用可能です。 簡単に違いについて説明します。 IPAdicの辞書について バ","tags":["lucene-gosen"],"title":"辞書とカスタム辞書について(Jugemより移植)"},{"contents":"今回はソースのダウンロードとビルドについてです。\n最新版のソースを利用したり、JavaDocを見たい場合はソースをダウンロードしてからビルドすることになります。 ソースのダウンロードからビルドまでの手順について説明します。\nまずはソースのダウンロードです。\n$ mkdir ~/work $ cd work $ svn co http://lucene-gosen.googlecode.com/svn/trunk/ lucene-gosen-trunk $ cd lucene-gosen-trunk ダウンロードしたソースは次のようなディレクトリ構成です。\n.classpathEclipse用ファイル .projectEclipse用ファイル .settingsEclipse用ファイル AUTHORS作者のリスト（Sen、GoSen） CHANGES.txtlucene-gosenにおける更新履歴 COPYING.LGPLライセンス README.txtReadme build.xmlAntのビルドファイル dictionary辞書コンパイル用ディレクトリ docsAPIドキュメント用ディレクトリ libライブラリ prettifyGoogle Code Prettify用ディレクトリ（APIドキュメントでの色づけ用） srcソースコード また、辞書やソースのコンパイルにはAntを利用します。 通常利用するAntのタスクには次のようなものがあります。\ncleanプロジェクトのクリーンアップ build-dic辞書のコンパイル（辞書のダウンロードも行う） jarjarファイル生成 dist配布パッケージの生成（2つのjarファイル生成） javadocJavaDocの生成 jarファイルの生成までの大まかな流れは「javaソースのコンパイル」～「辞書のダウンロード」～「辞書のプレコンパイル」～「辞書のコンパイル」～「jarファイルの生成」となります。 Antのタスク以外にjarファイルを生成する場合に利用するオプションは以下の通りです。\n-Dproxy.hostプロキシのホスト -Dproxy.portプロキシのポート -Ddictype辞書の指定（指定可能なものは次の通り。naist-chasen、ipadic） 以下はNaist-Jdicのjarファイルを生成するコマンドの実行例になります。プロキシサーバを利用する環境の場合は-Dproxy.hostと-Dproxy.portも指定してください。（※認証が必要なプロキシの場合はAntのビルドファイルを修正する必要が出てきます。）\n$ ant -Ddictype=naist-chasen jarファイルはdistディレクトリに生成されます。 これで、jarファイルが利用できるようになります。\n次回は、ipadicとNaist-chasenの辞書の違いとカスタム辞書を利用する方法について書こうと思います。\n","date":1306398840,"dir":"post/2011/","id":"ff1441a42144a7de9a3eaf9f5e7cfea9","lang":"ja","lastmod":1306398840,"permalink":"https://blog.johtani.info/blog/2011/05/26/%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%8B%E3%82%89%E3%81%AE%E3%83%93%E3%83%AB%E3%83%89%E3%81%A8%E6%A7%8B%E6%88%90/","publishdate":"2011-05-26T17:34:00+09:00","summary":"今回はソースのダウンロードとビルドについてです。 最新版のソースを利用したり、JavaDocを見たい場合はソースをダウンロードしてからビルドす","tags":["lucene-gosen"],"title":"ソースからのビルドと構成(Jugemより移植)"},{"contents":"概要： Lucene/SolrのコミッターであるRobert Muirさんが始めたプロジェクト 歴史： MeCabのJava移植版としてスタートしたSenがベースになります。 その後、辞書の構築部分をPerlからJavaに置き換えたGoSenが登場しました。 が、どちらもメンテナンスされなくなってきたので、Robertさんが引き継いでメンテナンスとLucene/Solr対応をはじめました。そして、現在にいたります。 ライセンス： LGPLライセンス（ベースになったMeCabのライセンスにならって） 特徴： 以下のような特徴があります。 ・Lucene/Solrですぐに利用可能（3.1、4.0に対応済み） ・jarファイル1つで利用可能（辞書をjarファイルに内包） ・LuceneのAttributeをベースにしたTokenの解析 ・その他（パフォーマンス改善、テスト改善など） プロジェクトのサイト： http://code.google.com/p/lucene-gosen/ ダウンロード： http://code.google.com/p/lucene-gosen/downloads/list 現時点では2つの辞書を内包したjarファイルが用意されています。 Naist-jdic 0.4.3（for ChaSen） 参考サイト：http://sourceforge.jp/projects/naist-jdic/ IpaDic 2.6.0　参考サイト：http://sourceforge.jp/projects/ipadic/ ","date":1306130400,"dir":"post/2011/","id":"5988b62a0c0785a303b77c74608e8b55","lang":"ja","lastmod":1306130400,"permalink":"https://blog.johtani.info/blog/2011/05/23/lucene-gosen%E3%81%A8%E3%81%AF/","publishdate":"2011-05-23T15:00:00+09:00","summary":"概要： Lucene/SolrのコミッターであるRobert Muirさんが始めたプロジェクト 歴史： MeCabのJava移植版としてスタートした","tags":["lucene-gosen"],"title":"lucene-gosenとは(Jugemより移植)"},{"contents":"今さらですが、ブログをはじめてみようかと。今さらですが…\nはじめてみようと思った一番の理由は、自分で調べたことをメモがわりに残すためです。 あとは、自分を追い込むためもありますが。(こっちが一番の理由かも)最近勉強してないなぁと感じているので。 ということで、まずは、lucene-gosenやsolrについて書いていく予定です。\n","date":1305859440,"dir":"post/2011/","id":"94b85ba716dbb7c20b230e69248b8208","lang":"ja","lastmod":1305859440,"permalink":"https://blog.johtani.info/blog/2011/05/20/%E3%83%96%E3%83%AD%E3%82%B0%E3%81%AF%E3%81%98%E3%82%81%E3%81%BE%E3%81%99/","publishdate":"2011-05-20T11:44:00+09:00","summary":"今さらですが、ブログをはじめてみようかと。今さらですが… はじめてみようと思った一番の理由は、自分で調べたことをメモがわりに残すためです。 あと","tags":["misc"],"title":"ブログはじめます(Jugemより移植)"}]
\ No newline at end of file
+[{"contents":"日常でよく、形態素解析したくなることがありますよね？ そして、Slackも日常的に立ち上がってますよね？ ということは、Slackのボットとして常駐してもらえばできるのでは？\nkagome-bot 知り合いがkagomeという形態素解析ライブラリを開発しています。 その知り合いが、ボットにもしてくれています（複数辞書対応してみたかったので、PR作って取り込んでもらいました）。\nhttps://github.com/ikawaha/kagome-bot ただ、デプロイはしてなかったので、我が家にあるUbuntuのサーバーにデプロイして動かすことにしました。 ボットについては、上記のリポジトリを見てもらえればいいかなと。\nとりあえず動けばいいや、ということで、適当なshell scriptにnohupで起動していたのですが、Ubuntuの更新後の再起動で毎回ログインしてスクリプトの実行はめんどくさいな？ということでググって調べてみました。\nsystemdでユーザーのサービスとして登録 参考ブログにある手順ほぼそのままでした。知見ありがたいです。\nサービスの登録自体は、指定のディレクトリにファイルを作るのではなく、systemdコマンドをしようしました。\n$ systemctl --user --force --full edit kagome これで、参考ブログにあるようにkagome.serviceというファイルが~/.config/systemd/user/ディレクトリに作られます。 ファイルの内容などはほぼ参考ブログにある通りです。こんなかんじ。\n[Unit] Description=kagome bot [Service] ExecStart=/home/johtani/kagome-bot/start_kagomebot_service.sh ExecStop=/bin/kill ${MAINPID} Restart=always [Install] WantedBy=default.target start_kagomebot_service.shの中で、kagome-botコマンドを実行しますが、こちらは絶対パスで記述しておきました。 サービス起動時のパスは~/のようなのですが、念のために。\nあとは、次の手順でサービスを登録して開始します。\n$ systemctl --user enable kagome $ systemctl --user start kagome ログを見るのはjournalctlコマンドです。\n$ journalctl --user -u kagome あとは、以下のコマンドを実行しないと、マシン再起動後にログインするまでサービスが起動しないので忘れないようにしましょう。 （忘れてログインしてみて起動してるじゃん？というコントみたいなことをしてしまいました）。\n$ sudo loginctl enable-linger username 参考ブログ本当にありがたいですね。 備忘録のついでにブログにしておきます。\n参考ブログ ユーザー権限で systemd のサービスを稼働させる方法 - pyopyopyo - Linuxとかプログラミングの覚え書き - ","date":1706175053,"dir":"post/2024/","id":"c4dba56f2db4851cd31b561d92dc5e35","lang":"ja","lastmod":1706175053,"permalink":"https://blog.johtani.info/blog/2024/01/25/kagome-bot-as-a-user-service/","publishdate":"2024-01-25T09:30:53Z","summary":"日常でよく、形態素解析したくなることがありますよね？ そして、Slackも日常的に立ち上がってますよね？ ということは、Slackのボットとして","tags":["go"],"title":"kagome-botのユーザーサービス化"},{"contents":"今年も振り返りブログをリビングで書いています（ドミノ倒しすごいな）。 FMVのキーボードで書いているのでタイポがつらい。。。\n振り返り（2022年に書いた抱負から） まずは振り返りをと。\nフリーランス継続 今年も個人事業主として乗り越えられました。 ZOZOさんには今年も引き続きお世話になっている感じです。 そのほかにベクトル検索のお手伝いをしたり、OpenSearchを調べたりといった仕事を手伝っています。 今年も完全にリモートで作業していましたが、イベントに出かけたりできました。 来年はもう少し出かける感じになるかな？ 今年はすこしのんびり仕事をしていたので、来年はもう少し仕事探さないとかな（営業しないとなあ）\nプログラミング 今年はプログラムを書いたほうかなと。 Goで個人用ですが、Slackのボットを書いてみたり（GoでSlackのボットを作った話 | @johtaniの日記 3rd | @johtani\u0026rsquo;s blog 3rd edition）、公開されているAmazonのプロダクトデータを使って検索アプリを書いてみたり。 プロダクト用のアプリを書いているわけではないですが、ちょっとずつコードを読んだり書いたりしています。\nベクトル検索まわりをさわる がっつりとまではいかないですが、Elasticsearchのベクトル検索の調査をやったりしました。 Amazonのプロダクトデータを使ってもうちょっとやろうと思いつつ、そこまでは手が回せてない感じですが。 速度という面でどうやって折り合いをつけつつ導入するのか？ どういうシーンでつかうのがいいのか？ どのモデル選ぶのか？とか気になることだらけ。 なんか、みなさんがどうしてるのか気になってしょうがないので、話をしてもいいよという方は連絡をもらえるとうれしいかもなぁ。 ベクトル検索とかLLMの周りの動きがはやすぎてついていけてるのかどうか。。。\n本を読む 今年は比較的読んだかも？\n単体テストの考え方/使い方 ユーザーの問題解決とプロダクトの成功を導く　エンジニアのためのドキュメントライティング ザ・ダークパターン ユーザーの心や行動をあざむくデザイン これまでの仕事 これからの仕事 機械学習による検索ランキング改善ガイド ソフトウェア設計のトレードオフと誤り 初めてのGo言語 買って読んでない本ももっとあるんですが。。。\n振り返り(今年あったできごと) ここからは今年の出来事を。 今年もずっと自宅でしごとしてました。 あとは少し仕事が少なめだったのでゲームが多くなってしまったかも？（本読めばいいのに。。。）\nゲーム（ONI、ゼルダ、FactorioのSpace Exploration） Dev container導入 検索技術勉強会の再開 ゼルダの新作面白かったですね。年初はOxigen Not Includedをやっていたのに、ゼルダが出てからはご無沙汰中です。ゼルダが終わった後は、ゼルダロスになってPythonを書いたりしていたのですが、うっかりFactorioのSpace Explorationを始めてしまい大変なことに。。。 全然終わる気配がないｗ\nローカルでの開発環境などをDev containerにちょっとずつしています。 Slackのボット、検索の遊び場、このブログ環境など。Dockerが必要にはなりますが、VSCodeとDev containerで環境を隔離できるし、VSCodeの拡張もコンテナごとに入れるのもできたりと便利です。\n最後は、検索技術勉強会を再開したことです。再始動という感じで4年ぶり？に再開しました（12月に開催した時のページ）。残念ながら私は裏方をしてただけで、当日は参加できてないのですが、次回（たぶん4月くらい）は参加するつもりです。再開の声を上げてくれた@takuya_aさんありがとう。絶賛スピーカーを募集中です。\n来年の抱負 さて、来年の抱負です。\nフリーランス継続 プログラミング継続 ベクトル検索の使い方をいろいろ試す 本を読んだブログを書く 今年もなんとかフリーランスを継続できましたが、そろそろ営業をしないといけないのかも？ ということで、外でしゃべったりもしていかないとなぁと。 あとは、検索ってどうやって導入すればいいのか？検索どうすれば改善できる？みたいなところのお手伝いをもっとしたいと思っています。 昨年出したこの本もあるので（『検索システム ― 実務者のための開発改善ガイドブック』 – 技術書出版と販売のラムダノート）、勉強会をやろうとしているところに顔を出したりしたいなあ。 外部の人を呼んで社内勉強会とかをできるというところがあれば参加したいので、声をかけてもらえればと。\nプログラミングはGo言語を触ったし、今年後半には検索の画面回りのプロダクトを触ってTypeScriptを勉強していこうかなという気になっています（なっているだけかもしれない？）。\nベクトル検索の使い方は、LLMだったりRAGだったりが世の中を席巻しているのもあり、いろんな記事が出てきて全然追いつけていません。だれか、少人数で勉強会とかやると興味ある人とかいるかなぁ？ こんなブログ見つけたよ、こんな論文があったよ、こんな使い方したらよかったよとかの共有をやるとみんな楽になったりしないかなぁ？\n今年は時々出かけて移動するタイミングで書籍を読んでいました。 読んだだけになってるのもあるので、少しでもいいからブログか何かに残しとかないとな。\nさて、今年は少しゆっくりできたので、来年はもうちょっといろんなところに顔を出しつつ、新しい仕事もできるといいなぁ。 勉強会もスピーカー集めをがんばるぞと。\nということで、今年もあと少しというところで無事書き終わりました。 来年もよろしくお願いいたします。よいお年をー\n","date":1704008961,"dir":"post/2023/","id":"d869fb48cb9acba03dc639481524ee80","lang":"ja","lastmod":1704008961,"permalink":"https://blog.johtani.info/blog/2023/12/31/review-2023/","publishdate":"2023-12-31T07:49:21Z","summary":"今年も振り返りブログをリビングで書いています（ドミノ倒しすごいな）。 FMVのキーボードで書いているのでタイポがつらい。。。 振り返り（2022","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2023）"},{"contents":"この記事は、情報検索・検索技術 Advent Calendar 2023の15日目の記事です。\n昨年に続き2回目の情報検索のAdvent Calendar参戦です。\n今年は、夏にオンライン参加したBerlin Buzzwordsの「The Debate Returns (with more vectors) Which Search Engine?」というセッションでPhilippさんが話題に出したOrama searchという検索エンジンを紹介してみようと思います（Oramaが正式名称なのかな？）。\nOramaという検索エンジン 公式サイトのトップにも記載がありますが、エッジで動作する全文検索＆ベクトル検索エンジンというもののようです。 なにそれ？という感じがしますが、オープンソース版のドキュメントを見るともう少しわかりやすい説明になっています。\nOrama is a fast, batteries-included, full-text and vector search engine entirely written in TypeScript, with zero dependencies.\nOramaはTypeScriptで書かれた、依存なしで利用できる検索エンジンということです（batteries-includedって初めて見たかも。「必要なものがそろってる」とかいう意味みたい（参考：英語のWikipedia））。\n以下は公式サイトにあるサンプルです。\ncreateでスキーマの定義をした検索エンジンのインスタンスを生成します。 insertで先ほど生成した検索エンジンにデータをインデックスします（後で紹介しますが、一括でインデックスするメソッドも用意されています）。 searchで検索し、検索した結果が返ってきます。 以上です。あとは、必要に応じてGUIを用意するだけです。\nimport { create, insert, search } from \u0026#39;@orama/orama\u0026#39; const db = await create({ schema: { title: \u0026#39;string\u0026#39;, director: \u0026#39;string\u0026#39;, isFavorite: \u0026#39;boolean\u0026#39;, year: \u0026#39;number\u0026#39; } }) await insert(db, { title: \u0026#39;The Prestige\u0026#39;, director: \u0026#39;Christopher Nolan\u0026#39;, isFavorite: true, year: 2006 }) const searchResults = await search(db, { term: \u0026#39;prestige\u0026#39;, where: { isFavorite: true, year: { between: [2000, 2008] } } }) サクッと動きそうですよね？依存関係がなくTypeScriptで書かれているということは静的なサイトなどでコンテンツを検索するのに使えるのでは？\nということで、自分のブログに組み込んでみました。 今回は組み込んだ時の流れと気になった点などを紹介します。 Hugoに組み込む際になるべく簡単にしたかったので、unpkg.comで公開されているJavaScriptだけを利用する形で検索ページを作ってみました。 JavaScriptやTypeScriptは不慣れなので効率がよくなかったり、間違っている点があればコメントなどをいただけると嬉しいです。\n構成 私のブログサイトはHugoで生成（参考：Hugo導入時の記事）して、GitHub Pagesとして公開しています。 現在のブログ検索にはAlgoliaを利用しているのですが、テスト目的としてOramaも使えるようにしてみました（右上のメニューでOramaをクリックすると以下で説明するOramaによる検索を試すことができます。\n今回実装してみたのは次のような流れです（日本語検索対応については後で説明します）。\nHugoでJSONのリストを生成（これまでと一緒） 1.で生成したリストをもとにNodeのスクリプトでOramaのインデックスファイルを作成 2.で作成したファイルを公開 画面で3.のファイルをダウンロードして検索 1. HugoでJSONのリストを生成（これまでと一緒） HugoでJSONのリストを生成します。Algoliaに記事を登録するのにも利用している仕組みです。 検索に利用する記事の情報を1記事を1つのオブジェクトとして出力します。1つの配列に記事ごとのオブジェクトが入っているJSONファイルになります。\n少しだけ特殊なことをしています。 ブログ記事にTagsというフィールドのありなしで処理を分岐しています。 Oramaが配列にNullを受け取った場合にうまく動かなかったので出力するJSON側で調整しています（あとで再確認してIssueあげておかないと）\n2. 1.で生成したリストをもとにNodeのスクリプトでOramaのインデックスファイルを作成 最初に紹介した公式のサンプルの場合、毎回Oramaのインスタンスを生成した後にインデックス登録の処理を行わなければいけません。 ただ、Hugoで生成したコンテンツは特に動的に更新があるわけでもないので、検索画面を表示するたびにインデックス登録するのも無駄が多い気がします。 Orama単体で最初に実装した時には、1.で作成した記事一覧のJSONをOramaで実装した検索ページのスクリプトが呼ばれたタイミングでフェッチし、insertMultiple（複数登録用のメソッド）を呼び出す実装にしていました。\nOramaでは、あらかじめ作成したOramaのデータベースを永続化・リストアするためのData Persistenceプラグインが提供されています。 インデックスに登録する処理コストはHugoでコンテンツを生成した直後に行い、検索画面では作成済みのインデックスファイルをフェッチしてリストアする形にすることにしました。インデックスと記事のJSONデータを含んだファイルになるので、元の記事一覧のJSONよりはファイルサイズが大きくなってしまいますが、処理時間も含めて考えると許容できるサイズではないかなと。\n次のスクリプトは1.で生成したJSONファイルを読み込んで、Oramaでインデックスした後にdpackというバイナリ形式でファイルに保存しています。 こののプラグインで選択できる形式は現時点ではjson、binary（デフォルト＝msgpack）、dpackの3種類になります。 残念ながら今回試したところ、binaryではエラーが発生したので、dpackを使用しました。\n3. 2.で作成したファイルを公開 単にGitHub Pagesに公開しているだけです。 ブラウザが2.で作成したインデックスファイルをフェッチしてから利用するためです。\n4. 画面で3.のファイルをダウンロードして検索 あとは検索画面です（長すぎるので、styleの部分は省略しています）。\nまず、必要なライブラリなどを読み込みます（下のソースコードの1行目から14行目）。\nOramaだけであれば問題ないのですが、OramaのプラグインがOramaをモジュールとして参照しているため、importmapとして定義しています。 Oramaのプラグインがいくつか利用しているものがあったので、まとめてimportmapに定義してあります。\n次に、検索窓（search-searchbar）や検索結果（search-hits）などのHTMLタグを用意します。 ヒット件数と検索にかかった時間も取れるので、表示する場所としてstatsも用意してあります。\n22行目からが実際の処理になります。\n28行目で、手順2.で作成したインデックスのファイルをフェッチします。 32行目でフェッチしたファイルから取り出した文字列をリストアして、Oramaのインスタンスを生成します。 34行目のtokenizerに関しては日本語対応で説明します。\n48行目のquery関数がクエリの組み立て＋検索の処理です。search-inputで入力されたテキストをtermとして渡して検索をしています（56行目）。 検索した結果のリストをもとに検索結果のHTMLタグを組み上げていきます。 検索結果には後述する@orama/highlightのモジュールを利用してスニペットを追加しています。\n日本語対応 残念ながらOramaは公式には日本語をサポートしていません（サポートしているスキーマに設定できるlanguageの一覧（＝STEMMERSにあるものだけ指定可能）。一覧と実装分けたほうがいい気がするけど？）。 ただ、tokenize関数を変更できるようにしてくれています。これを利用して、少しトリッキーな形で日本語対応しました。\n先ほどの手順2.でOramaのcreate関数として、componentsに次のtokenizerを渡します。\nlanguageはenglishですが、日本語をtokenizeする処理に次のように書き換えました。 stemmingは今回は行わない（＝用意されているstemmerを使えない）のでfalse、normalizationCacheは空のMapを用意しておかないとエラーが出るので、new Map()しています。 この設定を使ってcreateすることで、\ncomponents: { tokenizer: { language: \u0026#34;english\u0026#34;, stemming: false, normalizationCache: new Map(), tokenize: (raw) =\u0026gt; { return tokenize(raw) }, }, }, 少しわかりにくいですが、tokenizerのtokenize関数の中で呼び出しているreturn tokenize(raw)の部分はwakachigakiというライブラリのtokenize関数となっています。\nwakachigakiというライブラリ Elasticsearchなどのサーバー上で動作させる検索エンジンではkuromojiなどの辞書を内包した形態素解析器を利用するのが通常です。 ただ、今回はブラウザだけで完結した簡単な検索を行う仕組みをOramaを使って提供しようと考えました（kuromoji.jsというのもありますが、辞書のサイズがそこそこのサイズです）。 ですので、辞書ファイルのない軽量の形態素解析ライブラリとして、wakachigakiというライブラリ（＝6.2Kbの軽量日本語分かち書きライブラリ）を利用してみました。\n最初はTinySegmenterの利用をしていたのですが、wakachigakiのサイトにもあるように、TypeScriptやES Moduleでも利用できる形式となっていたのでこちらに切り替えました。\n辞書もっていないため、品詞でのフィルタリングや読みを利用した処理はできませんが、日本語の文章を分かち書きしてくれます。\ntokenize関数の設定 OramaのTokenizerインタフェースのtokenizeは入力の文字列をstring[]として返すことを期待しています。 wakachigakiのtokenizeも文字列を引数にとり、string[]を返すので、そのまま呼び出すだけにしてあります。\nただ、今回のブログ検索の実装では、検索窓に入力された文字列も特に何も処理せずにtokenizeに渡す形にしています。 クエリパーサーなどを考える場合は、検索窓に入力された文字列を前処理したりする必要がありますが今回はいったんこれで。。。\ndata-persistenceはcomponentsはpersistしない 手順2.で導入した、data-persistenceプラグインですが、現在の実装ではOramaが生成したデータベース（転置インデックス）だけを永続化しています。 独自に設定したtokenizerは残念ながら含まれていませんでした。 手順4.の検索画面のコードの34行目の部分（下記）で、フェッチしたインデックスデータからrestoreした後のOramaのインスタンスのtokenizerに手順2.と同じ設定のtokenizerを設定することで検索時にも同じトークナイズがされるようになります（今の仕組みだと修正した場合には、両方のソースコードを修正しないといけないのがちょっと面倒かも？）。\ndb.tokenizer = { language: \u0026#34;english\u0026#34;, stemming: false, normalizationCache: new Map(), tokenize: (raw) =\u0026gt; { return tokenize(raw) }, } tokenizerはOramaの検索エンジンのインスタンスに紐づく設定となっているので、フィールドごとに切り替えるといったことも現在では想定されていない気がします。\nハイライト ハイライトのために、インデックスデータに単語のポジションを保存するためのプラグインも提供されています。 このポジションは検索の単語がヒットしドキュメントのどの位置に出てくるのか？をあらかじめデータとして保存しておくことで、ハイライトのたびに単語の位置を毎回計算しなくてもよくするためのものと思われます。\nこれを利用してもよかったのですが、今回は@orama/highlightというモジュールを利用することにしました。 検索にヒットしたドキュメントの元の文章と検索のキーワードを入力すると検索キーワードの周りにハイライトのHTMLタグを埋め込んでくれるライブラリを利用しました。これは普通に他でも便利かも？\n余力があればプラグインを利用した時のインデックスのサイズの違いや検索時の速度の違いを調べてみるのもいいかもしれないです。\nそのほかの機能 今回は利用していませんが、Oramaにはそのほかの機能も用意されています（公式ドキュメントの検索の紹介のページ）。詳細は公式ドキュメントをご覧ください。\nTypo tolerance Facet/Filter Vector Search Geo Search Grouping Threshold Preflight Oramaで（まだ？）できないこと 今回触ってみて、現在のOramaの実装ではできなそうなことがいくつかあったので書き出しておきます。 あくまでも現時点のことです。今後実装される可能性もあります。\nデフォルトでは、searchのtermに渡した文字列をtokenizeし、出力されたトークン列（単語の配列）のそれぞれのトークン（単語）にヒットしたドキュメントが全て検索結果に含まれます。 検索結果のドキュメントはBM25でスコアリングされるので、多くのトークンが含まれるものが上位に来る可能性が高いです。\nただ、特定の単語を含まない検索、ANDやOR検索など凝ったクエリは現在は書けないようです（Issueがある）。\nfilterは別途用意されているので、例えばファセットで表示したカテゴリで絞り込んだ状態にするといったことはできそうです。\n残課題 とりあえず日本語をなんとなく検索できるようにすることはできました。 が、気になることもいっぱいありました。 時間を見つけてTypeScriptなどを勉強しながら探っていく感じでしょうか。\nインデックスを小さくする方法 今回はブログ記事のサマリー（Hugoで生成されるSummary）でインデックスを作ったので、インデックスのサイズはまだ小さくなっています（といっても1MB超えてるけど）。ブログ記事全体を検索できるようにする場合は、インデックスファイルが大きくなります。\nこれは、OramaがデフォルトではインデックスしたJSON自体もインデックス（ドキュメントストア）に保存しているためです。 ですので、Oramaに登録したJSONデータ＋検索用のインデックスがインデックスファイルとなります。 ただ、検索だけができればよい場合は、出来上がったインデックスがあればドキュメントのIDは取得できます。\n公式ドキュメントでもそのことに触れているページがあります（参考：Remote document storing）。\nまだちゃんと実装を見ていませんが、ブログ記事本体の文字列はドキュメントストアに保存しないようにすれば検索はできるが、容量が大きくならないといった工夫ができそうです。\nただ、検索結果にハイライトを含んだスニペットを表示したい場合は、コンテンツ文字列が必要になってくるので、代わりに何かしらの仕組みを考える必要が出てきます（例えばサマリー部分の文字列だけ保存しておいて、ハイライトはそこだけを対象とするなど）。\nそのほか そのほかに思いつくのはこの辺でしょうか？\nオートコンプリート：Oramaというよりも、JavaScriptやTypeScriptでうまく実装できるのか？という話のような気がしますが。。。 ファセット対応：機能としては存在していますが、今回は実装が間に合いませんでした。 Vector Search：検索キーワードのベクトルをどうやって作るのか？という問題が残りそう。コンテンツのベクトルだけで関連ページの表示みたいなことはできるかも？（動的にやる必要がないので、事前計算して各ページに埋め込むほうがよさそうだけど） Geo Search：緯度経度があるデータを探し出してこないと？ relevanceの処理の変更：BM25以外に切り替えることができるかどうか（Oramaのソースとにらめっこしないといけなそう） tokenizeの改良：辞書を利用する形態素解析ライブラリやAPIを利用してみたり、「てにをは」といった1文字のひらがなを削ることで、無駄な検索ヒットを減らしてみたり。大文字小文字の正規化も必要。 検索ログの解析：検索ログを保存する仕組みなどはないので、Google AnalyticsやほかのAPIなどを用意する？ まとめ ということで、Oramaという検索エンジン？ライブラリ？を利用して日本語のブログ検索を実装してみました。 まだ、機能が少ない部分もありますが、少数のデータをブラウザだけで簡単に検索できる仕組みをGitHub Pagesだけで提供することができそうです。 今回は静的なファイルだけで完結する形にしましたが、TypeScriptで利用できる簡単な検索エンジンライブラリとして使ってみるとまた別の面白さもあるかもしれないです。 まだ触っていない機能は思いついたこと（＝残課題に書いたこと）もあるので、ちょっと試行錯誤してみようかなぁ。\n","date":1702566000,"dir":"post/2023/","id":"476e17b6f854414033d5cec1470774ee","lang":"ja","lastmod":1702566000,"permalink":"https://blog.johtani.info/blog/2023/12/15/introduce-orama-to-blog/","publishdate":"2023-12-15T00:00:00+09:00","summary":"この記事は、情報検索・検索技術 Advent Calendar 2023の15日目の記事です。 昨年に続き2回目の情報検索のAdvent Calendar参戦です。 今年は、夏","tags":["orama","search"],"title":"Oramaという検索エンジンでブログ検索を作ってみた"},{"contents":"PySpaアドベントカレンダーの12/08のエントリーです。昨日は渋川さんのアンラーニングで失敗した話でした。\n私は、今年は昨年の続きっぽい話を。\n音楽の再生とか停止とか 今年もリモートで仕事を継続しています。 昨年、OwnToneという音楽サーバーを導入しましたが、ミーティング開始時や終了後に音楽の停止や再生をするのに、ブラウザで操作するのはちょっと面倒です。 加えて、ミーティングする際には実際には\n音楽を止める 電気をつける といったことをっやります。 音楽再生についても\n音楽を再生する アンプの音は音楽再生用の音量にする といった複数のことを行います。\n基本的にPCの前にいるし、Slackを常に開いているからSlackのBotを作ると便利になるのでは？ ということで、自分専用のSlack Botを作ってみました。\nGitHubリポジトリ 全く誰の役にも立たないけど、公開しています。\nhttps://github.com/johtani/smarthome Goで実装 知り合いに勧められたということもあり、Goをあまり触ったことがなかったので、Goでやってみました。時々新しい言語を触ってみたくなるので。。。\nコマンドパターンのような作りで、コマンド（操作）を増やしていく感じで実装してはみたのですが、この書き方がいいのかはまだよくわかっていないです。\nActionという単体の操作(例：OwnToneの一時停止)を、操作したい機器の操作ごとに作成しています。 インターフェースとしてはRunだけを定義しています。\ntype Action interface { Run() (string, error) } それらの操作（Action）をひとまとめにしたものをSubcommandという形で定義して、SlackのBotにはSubcommandの名前を送って処理を実行する形にしています。\ntype Subcommand struct { Definition actions []action.Action ignoreError bool } やりたいことを追加するタイミングで時々リファクタしたりもしていますが、基本はこんな感じです。 細かな実装はさておき、今回ボットを作るときの観点をいくつか。\n宅内ネットワーク 音楽サーバーのOwnToneもですが、YAMAHAのアンプのAPIも見つけたのでこれらの操作をボットから行っています。どちらも自宅のネットワークにあるので、今回作成したボットも同じネットワークで動作します。\n外部に公開されたHTTPのエンドポイントがあればよいのですが、今回は用意していません。 SlackのAPIではこれに対応したアプリを作るときのためにSocket Modeを用意してくれています。\nドキュメントがしっかりしているのもあり、チュートリアルなどを見つつ特に迷うことなく構築できました。\n基本的には「特定のチャンネルでボットがメンションされたら動作する」という挙動だけしか実装していないので、特に今回はこれで困ることもありませんでした（世の中の人たちはもっとすごいSlackの使い方をしていそうだけど。。。）。\n対象となるものたち ボットから操作しているのは今のところ3種類です。\nSwitchBot OwnTone YAMAHAのアンプ SwitchBot SwitchBotについては、go-siwtchbotを利用しています。 電気、エアコン、空気清浄機、サーキュレーターのオンオフをSwitchBot経由でやっています。\n室内灯の明るさのために、SwitchBot側でシーンを設定している（一番暗い明るさで電気をつける）ので、そこが少しと特殊でしょうか？\nあとは、SwitchBotの温湿度計を3つ（室内2つ、室外1つ）おいてあるので、これらの温度を表示するコマンドも用意しました。\nそれぞれの機器の電池残量（電池の絵文字の右側）を表示してます（書斎が2つあるように見えますが、温湿度計の名前なので、同じ部屋においてあります。。。温度が高いほうがデスクトップPCの近くにある）。 防水の温湿度計があるので、外の気温もわかるのは便利です。\nOwnTone JSONのAPIが用意されていますが、特にクライアントライブラリなどは用意されていません。 今回は、用意されているAPIのごく一部だけを利用するので、net/httpのClientでJSONを投げています。 必要になったらowntone/clientにメソッドを追加していく感じです。\nhttps://github.com/johtani/smarthome/blob/master/subcommand/action/owntone/client.go#L45 再生、一時停止、プレイリストの取得、音量指定あたりを実装しています。 音の出力先はAirPlay（次に出てくるYamahaのアンプ）になっています。\nあと、JSON APIのサンプルをChatGPTに渡して、「このJSONをレスポンスに受け取る処理をGoで書いてください」と聞いて処理を書いたりしました（細かいのはどう聞いたか覚えてないけど）。\nYAMAHAのアンプ ググって探してきましたが、利用しているYAMAHAのアンプにYXC（Yamaha Extented Control）と呼ばれるAPIが用意されていました。 PDFでAPIの仕様が公開されていたので、この資料とにらめっこしながら、必要そうなAPIを実行するクライアントを実装しました。 こちらは、OwnToneのAPIの処理をすでに書いた後だったので、それをもとに必要な実装を追加しただけです。\nちなみに、アンプの電源をONにするAPIは実装していません。\nOwnToneで音楽を再生する(AirPlayで信号が送られるみたい) シーン選択（Nintendo SwitchやPS5のシーンを用意している）のAPIを呼び出す という処理をすると自動で電源がONになりました。スタンバイしている状態でもAPIはリクエストを受け付ける状態になっているようです。 また、PS5のシーンを呼び出したら、PS5自体も起動するのが便利だったりします。HDMI経由で信号が飛んでるのかな？ 「ミーティング開始」や「音楽停止」コマンドではアンプの電源をオフするAPIを呼び出すようにしています。\nタイポ対応 「入力間違いしちゃうんです、人間だもの。。。」\nということで、10月にタイポ対応の処理を入れてみました。 タイポ対応前の実装では、入力された文字列がコマンドの文字列と完全一致した場合にだけ、コマンドが実行される形になっていました。 結構タイポしちゃうので、完全一致で見つからない場合の処理として、入力された文字列とコマンド名のレーベンシュタイン距離が2以下のものを探し、その中で距離が一番小さな値のコマンドを実行する形にしてみました。 コマンド数はたかが知れているのでコマンドのリストを全部チェックする形にしています。 タイポするとこんな感じ。\nレーベンシュタイン距離の計算にはGo-edlibを利用しています。OSS便利ですね。\nやってよかったこと ミーティング開始時などのいくつかの手順が簡素化できたので満足しています。 SwitchBotの操作もスマホをわざわざ操作しなくてもいいですし（仕事してるとキーボードとSlackは常に使ってるし）。 また、副次的な効果として、部屋の外から電源を切り忘れていたり、エアコンの切り忘れなどの場合に、スマホから遠隔でまとめた処理ができるのが便利です。\n今後やってみたいこと こういうのがあるともうちょっと便利かもなぁ？というのもあるので今後も気が向いたらコマンドなどを追加していく予定です。 今のところこんなことやりたいなというのがいくつかあります。\nキーワードに関連する曲の再生 OwnTone自体に検索の仕組みがついているので、キーワードを受け付けてそれに関する曲を流す Flexispotの操作 ミーティングの時は立ち上がっているので、机をスタンディングの状態にしたい 電子工作しないとだめかも？ Webカメラ用ライトの点灯 ミーティング時に明かりが必要なのですが、物理スイッチのOn/Off これも電子工作かな？ 定期的に温度をBotに表示させるとと面白いかも？ まとめ ということで、新しいプログラミング言語にも触れたし、作業環境も便利になって一石二鳥でした。 新しいプログラミング言語触るのはやっぱたのしいですね。\n","date":1701961200,"dir":"post/2023/","id":"516a7aa07f8faa6b7aa38beb5010cf8c","lang":"ja","lastmod":1701961200,"permalink":"https://blog.johtani.info/blog/2023/12/08/smarthome-bot/","publishdate":"2023-12-08T00:00:00+09:00","summary":"PySpaアドベントカレンダーの12/08のエントリーです。昨日は渋川さんのアンラーニングで失敗した話でした。 私は、今年は昨年の続きっぽい話","tags":["misc","music","bot"],"title":"GoでSlackのボットを作った話"},{"contents":"「機械学習による検索ランキング改善ガイド」を読みました。\n著者の鈴木さんより献本いただいたのを読み終わったのでレビューと、あとおまけです。\n紹介とレビュー どんな本なのか？は打田さんが書かれたブログ、「ブックレビュー：『機械学習による検索ランキング改善ガイド』 - Tomoko Uchida - Medium」に詳しく書かれているので、そちらも参考にしてもらうほうがわかりやすいと思います（丸投げ）。\n読みながらいくつかツイートしていたので、そちらも参考のために貼っておきいます。\nオライリーの検索ランキング本、負荷テストのことも書いてある、すごいhttps://t.co/YPnB6kxFY2\n\u0026mdash; Jun Ohtani (@johtani) August 28, 2023 私のレビュー わかりやすく検索の基本を紹介しつつ、本書のメインであるランキング改善について全体の流れが書かれています。 ランキング改善のやり方といっても、手法の話だけではなく、プロジェクトとしてどの様に進めていくべきなのか？また、関係するものはどんなものがあり（システムだけではなくチームについても書かれていたり）、どういう判断をもちながら運用していくのか？、負荷テストにまで言及されています。\n読んでいて特に私が気に入ったのは以下のような話でした\nランキング改善を進める前にきちんと解ける問題なのか？それ以前にやることはないのかを考えましょう マッチング改善についても少しだけ触れられているが、メインはランキングについてだと明記されている 実際に体験されたのであろう落とし穴の話 負荷テストについて1章設けてある！ ハンズオンのパートでもレイテンシの話がされている 付録としてベクトル検索についても触れてある 日本語でまとまって読める本があるのは本当に幸せですよね。\nおまけ 書籍ではハンズオンで、Elasticsearchとランキング学習のプラグインであるelasticsearch-learning-to-rankを利用しています（GitHubにサンプルが公開されています）。 書籍ではElasticsearchが7.13.4、プラグインが1.5.7-es7.13.4というバージョンになっていました。\nブログを書いている時点でのElasticsearchは8.x系になっています。せっかくなので、書籍を読みながら現時点で最新のものに置き換えてみるというのをやってみました。\nElasticsearchは8.10.2が最新なのですが、ランキング学習のプラグインはサードパティ製で、1.5.8-es8.8.2が最新版となっています。 ハンズオンのサンプルコードをフォークして、以下の構成にして動くようにしてみました。\nElasticsearch : 8.8.2 learning-to-rankプラグイン : 1.5.8-es8.8.2 Kibana : 8.8.2 Python : 3.10 Elasticsearch、プラグイン、Kibanaのアップグレード Elastic社が提供しているDockerイメージが利用されているので、バージョン番号を書き換えました。 あとは、learning-to-rankプラグインのバージョンを書き換えるついでに、elasticsearch-pluginコマンドで直接ダウンロードさせる形に書き換えました。\nhttps://github.com/johtani/building-search-app-w-ml/blob/es8/part2/app/search-engine/Dockerfile\nPython3.10にアップグレード 本当は必要なかったのですが、Pythonのイメージもついでに3.10にしました。 ただ、このおかげでインストールされるXGBoostのバージョンも1系から2系に上がってしまい、XGBoostを利用してモデル生成をする処理でエラーが出るようになってしまいました。。。\n2系へのアップグレードは手間がかかりそうだということで、pipコマンドでのインストールでのバージョンを\u0026lt;2として、1系をインストールすることで回避しました。\nhttps://github.com/johtani/building-search-app-w-ml/blob/es8/part2/app/workspace/Dockerfile\nelasticsearch-pyのアップグレード Elasticsearchを8系にしたので、クライアントライブラリ側も8系に書き換えました（元は7.17以下に固定されていた）。 pipで7系に固定されていたものを外して最新のもの（8系）をインストールするようにしました。 これだけでも特に問題なく動いたのですが、「DeprecationWarning」が出ている部分が1か所だけあります（サンプルではDeprecationWarningが出力されない形になっていましたが、出力するように変更しました）。\nElastic公式のドキュメントにMigrate to 8.0というページが公開されています。Pythonクライアントのアップグレードを行う際はこちらを参考にすると指針が記載されています。\n今回のサンプルコードではsearchの時の引数としてbodyを渡していたのですが、8系のクライアントライブラリからこちらが廃止になり、queryやrescoreなど個別の引数を渡す形に変更されています（search APIのリファレンス）。 ですので、bodyを**bodyでアンパックして渡すようにしただけです。サンプルコードがわかりやすく書かれているので変更も少しで済みました。\nhttps://github.com/johtani/building-search-app-w-ml/blob/es8/part2/app/workspace/collect_responses.py#L59\n一応、これでエラーが出ないで動きました。 すべて適用した、フォークして修正したブランチはhttps://github.com/johtani/building-search-app-w-ml/tree/es8で公開しています。\nまとめ すごくわかりやすいうえに、手を動かしながらどんなデータを使ってどんなことをやるのかが体験できる良い本でした。 理論的な話だけでなく、システムとしてどういうものが必要で、どういうことをやらないといけないのか？というのがわかるのがイメージできるのは重要だと思います。\n最後は広告ですが、ランキング改善以外の検索システムについて学べる本を検索システム ― 実務者のための開発改善ガイドブック – 技術書出版と販売のラムダノート出していますので、こちらも参考書として読んでいただけるとうれしいです。\n","date":1695612744,"dir":"post/2023/","id":"7f78b02c531f09602ba4e140132d26a2","lang":"ja","lastmod":1695612744,"permalink":"https://blog.johtani.info/blog/2023/09/25/read-search-raking-guide/","publishdate":"2023-09-25T03:32:24Z","summary":"「機械学習による検索ランキング改善ガイド」を読みました。 著者の鈴木さんより献本いただいたのを読み終わったのでレビューと、あとおまけです。 紹介","tags":["読書","elasticsearch"],"title":"機械学習による検索ランキング改善ガイドを読みました"},{"contents":"趣味？（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書いています。 ベクトル検索などの確認なども含めて、Jupyter Notebookで簡単なAPIの呼び出しを書いていましたが、検索はやはり画面があるほうがにぎやかでいいですよね。 ということで、画面周りで調べものをしていた時のことを後日の自分のためのメモとして残しておきます。\nSearch UIとSearchkit ということで、それほど手がかからないで検索の画面をサクッと作る方法がないか？ということでちょっとだけ探してみました。 最初にElasticsearchを利用していることもあり、すぐに検索の画面を作れるライブラリ・フレームワーク・コンポーネントがないかな？ということで思いついたのが次の2つでした。\nElastic Search UI Searchkit どちらも直接Elasticsearchに接続して検索をすることができるコンポーネントです。 Elasticsearchだけで完結していればそれでおしまいだったのですが、今回はバックエンド経由でElasticsearchに検索を書ける必要があります（ベクトル検索の仕組みもデモをしたいため、クエリの文字列をLLMなどでベクトルにしてからknn検索をすることになります）。\nSearch UIの構成 もともとSearch UIはElasticのApp SearchのGUI構築向けのコンポーネントとして作られました。 最近になって、直接Elasticsearchに接続できるコネクターを提供しています（ベータだけど）。 このコネクターを利用した場合は、ざっくりですが、このような流れになります。\nまた、Search UIはCustom Connectorの仕組みも用意しており（ConnectorのAPIが宣言されているのでそのAPIで独自実装が可能）、これを利用することで、ブラウザではなくバックエンド（Node）でElasticsearch Connectorを利用するような構成も取れるようになっています。\n改めて要件をまとめると ということで、やりたいことは\n簡単にUIが作れる バックエンドはPythonを経由して検索したい となります。 Searchkitも調べようかと思いましたが、いったんはSearch UIのCustom ConnectorでPythonでFastAPIでバックエンドのAPIを実装して、Search UIの想定しているリクエスト・レスポンスに変換すればいいかな？ということにしました。\nとりあえずSearch UI＋Custom Connectorからのリクエスト・レスポンス（フロントからバックエンドへの出入りの部分）を記録し、 Search UI＋Elasticsearch Connectorのときのリクエスト・レスポンス（バックエンドからEsへのの出入りの部分）も記録して、 参考にしながらバックエンドを実装しようと試みました。 Search UIのCustom Connectorのサンプルとなっていた、Node上でElasticsearch Connectorを動かしている部分をPythonで簡単に再実装しようという試みです（まったく同じ実装にする必要はなく、必要最低限の機能（検索窓、ファセット、ページング）が動作するところを目指します）。\nElasticsearch API connectorの調査 方針が決まったので、Search UIがElasticsearch API Connectorに渡しているリクエストをブラウザのデバッグ機能を使って追いかけてみると。。。 内部でSearchkitを読んでいる？？ことがわかりました。\nElasticsearch API Connectorがリクエストを変換しているのかと思っていたのですが、実は内部にもう一段変換が行われていました。\n方針を決めたつもりが、Searchkitが出てきてしまったので、Searchkitも調べてみることに。。。 なお、Search UIにElasticsearch API Connectorを導入したのがどうやら、Searchkitの作者で、現在はElasticのエンジニアになられているようです。\nSearchkitとは？ Search UIが利用しているSearchkitは、3.0ですが、Searchkit本家のリポジトリを見ると4.x.0となっています。\nどうして新しいものをSearch UIで使っていないのかな？と思いつつ調べてみたところ、Searchkit V4のブログを発見しました。\nSearchkit V4 integrates with Algolia’s Instantsearch library, which is a Search UI library built by Algolia. Instantsearch is an amazing library, and it’s been used by many companies and supports many frameworks like React, Vue and Angular. ブログより引用\nどうやら、V4ではコンセプトをガラッと変更されたようで、Algoliaがオープンソースとして開発しているInstantSearchのコネクター（アダプター）としてSearchkit V4を開発しているようです。 これは最近出てきている検索エンジンのTypesenseやMeilisearchの戦略にもなっています。\nなお、SearchkitのGitHubリポジトリやSearch UIのリポジトリを見ていると、Search UIの開発（およびSearchkitの3系）は現在は活発に行われていないように見えました。 Searchkit V4はちょっとずつ開発が進んでいるようです。\nまとめ？ 一応Searchkit V4の現状やInstantSearchもすこしだけ見てみたのですが、今回の私のプロジェクトでは検索画面はまだそこまで重要度は高くないので、いったん調べていたSearch UI＋Pythonのバックエンドの構成で動作する最小限を実装したところで終わりにしました。 なので、Searchkit V4＋InstantSearchの構成はまた今度という感じです。\nなお、Search UIの方は5月からコミットがされていないようです。どうも開発しているチームが別件で忙しそうだなというのを感じました。\n","date":1692768764,"dir":"post/2023/","id":"8f58cbe5f2ce85c22569af765de3f8d3","lang":"ja","lastmod":1692768764,"permalink":"https://blog.johtani.info/blog/2023/08/23/search-ui-and-searchkit/","publishdate":"2023-08-23T05:32:44Z","summary":"趣味？（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書いています。 ベクトル検索などの確認なども含めて、Jupyter N","tags":["searchkit","search-ui","画面"],"title":"search-UIとSearchkitと検索画面"},{"contents":"いくつかある環境をDev Containerで動くように変えていますが、最初に導入した時に疑問点だった「コンテナ名」について解消したのでメモを残しておきます。\nコンテナ名の指定 最初のDev Container導入の記事で、起動したコンテナの名前が自動で付与されて、ランダムに変わるという疑問点を書いていました。\ndocker-compose.yml対応の記事ではdocker-compose.ymlを利用すると、コンテナ名はファイル内で定義されたサービス名で起動されて見やすくなると気づきました。\nやはり、Dev Containerでイメージを指定している場合もわかりやすいコンテナ名がいいなと思ったところで、「runArgs」を思い出しました。 Dev Containerからコンテナを起動するときに渡す引数が書けるじゃないですか。そういえば、むかしdockerコマンドを使う時に名前を指定した記憶があったなと。ということで、Google検索です。「docker command args container name」で検索しましたｗ\n--nameというオプションで起動時のコンテナの名前の指定ができます。ということで、このブログを生成するためのdevcontainer.jsonに\u0026quot;runArgs\u0026quot;でコンテナ名を指定してコンテナ起動ができるようになりました（「ブログ記述環境としてのDev Container」という記事のdevcontainer.jsonにrunArgsの行を追加しただけ）。\n{ \u0026#34;name\u0026#34;: \u0026#34;Hugo - blog generator\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;mcr.microsoft.com/devcontainers/javascript-node:16\u0026#34;, \u0026#34;runArgs\u0026#34;: [\u0026#34;--name\u0026#34;, \u0026#34;blog_generator\u0026#34;], \u0026#34;postCreateCommand\u0026#34;: \u0026#34;/bin/sh ./.devcontainer/postCreateCommand.sh\u0026#34;, ... ","date":1690420969,"dir":"post/2023/","id":"f9e847ee886bdb9ab5583eeb6eabbd51","lang":"ja","lastmod":1690420969,"permalink":"https://blog.johtani.info/blog/2023/07/27/container-name-in-devcontainer/","publishdate":"2023-07-27T01:22:49Z","summary":"いくつかある環境をDev Containerで動くように変えていますが、最初に導入した時に疑問点だった「コンテナ名」について解消したのでメモを","tags":["dev container"],"title":"VS CodeとDev Container(コンテナ名の指定)"},{"contents":"このブログの生成には、Hugoを利用しています。 ブログ移行日記（その1）に書いてありますが、当時はbrewでインストールしていました。 また、Windowsに移行したタイミングで、WSL2のUbuntuにaptでhugoをインストールして利用していました。 WSL2の環境が壊れなければこのままでもいいのですが、最近Dev Containerを触っていたので、このブログを書く環境（おもにHugo）もDev Containerにできるのでは？と気づきました。\nということで、Hugo＋αの環境をDev Container化したので、そのメモです。\n必要なもの ブログを書いて、記事を構築して、公開するところまでに利用するのは次のようなものです。\ngit Hugo node atomic-algolia GitHubのプライベートリポジトリでHugoのプロジェクトを管理しています。 また、GitHub Pagesで公開しており、生成したHTMLもgitコマンドを利用してGitHubにpushしています。 このため、gitコマンドが必要です。\nコンテンツの生成はHugoコマンドを利用します（テーマの適用とかいろいろ）。\nあと、Algoliaでブログを検索できるようにしており（ブログ移行日記（その4）参照）、Algoliaへドキュメントのデータをアップロードするために、atomic-algoliaを利用しています。こちらは、nodeのモジュールであるので、nodeの環境も必要です。\nベースにするイメージ Dev Container Templatesというリポジトリが公開されています。 こちらを探すと、元となるdevcontainer.jsonが見つかることがあります。 Hugoのものがあるか探してみましたが、残念ながら見つかったのはJekyllのテンプレートでした。 今回は、nodeの環境が必要なのでjavascript-nodeを元に編集していきます。\n手元のUbuntuのnodeのバージョンが16だったので、バージョン16のイメージを指定します(devcontainer.jsonは後述)。\nHugoの追加 Hugoのテンプレートはなかったのですが、Dev Container FeaturesにHugoのfeatureが用意されていました。 featuresに1行追加するだけでコンテナにHugoをインストールしてくれる便利ものです。\nMarkdownの環境 Dev Container Templatesを探索していて見つけたMarkdownのテンプレートも参考にしてみました。 VS CodeのMarkdown向けの拡張機能がいくつかリストアップされていたので、ついでに追加です。 markdown-all-in-oneやmarkdownlintはこれまでも利用していたので、他のものも便利だろうということで。 他の物はどんなものかを後で調べてみる予定です。\n作った.devcontainerの設定はこちら ということで、出来上がった設定は以下の通りです。\ndevcontainer.json { \u0026#34;name\u0026#34;: \u0026#34;Hugo - blog generator\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;mcr.microsoft.com/devcontainers/javascript-node:16\u0026#34;, \u0026#34;postCreateCommand\u0026#34;: \u0026#34;/bin/sh ./.devcontainer/postCreateCommand.sh\u0026#34;, \u0026#34;features\u0026#34;: { \u0026#34;ghcr.io/devcontainers/features/hugo:1\u0026#34;: {} }, \u0026#34;customizations\u0026#34;: { \u0026#34;vscode\u0026#34;: { \u0026#34;extensions\u0026#34;: [ \u0026#34;yzhang.markdown-all-in-one\u0026#34;, \u0026#34;streetsidesoftware.code-spell-checker\u0026#34;, \u0026#34;DavidAnson.vscode-markdownlint\u0026#34;, \u0026#34;shd101wyy.markdown-preview-enhanced\u0026#34;, \u0026#34;bierner.github-markdown-preview\u0026#34; ] } } } postCreateCommand.shでは、npm installで、必要なモジュールのインストールをコンテナビルド後に実行できるようにしました。 （apt updateはなくてもいいな）\npostCreateCommand.sh #!/bin/sh # postCreateCommand.sh echo \u0026#34;START Install\u0026#34; sudo apt update sudo chown -R vscode:vscode . npm install echo \u0026#34;FINISH Install\u0026#34; まとめ ということで、ここ最近Dev Containerについて色々調べていたのでサクッとDev Container化ができました。 まぁ、HugoのFeatureが用意されていて、他に大したことをやっていないというのが大きいのですが。 このブログは今回構築したDev Containerで生成して公開した記事になります。\n","date":1690189832,"dir":"post/2023/","id":"7884b62c561b999b9358d52779a18218","lang":"ja","lastmod":1690189832,"permalink":"https://blog.johtani.info/blog/2023/07/24/introduce-dev-container-to-hugo-env/","publishdate":"2023-07-24T09:10:32Z","summary":"このブログの生成には、Hugoを利用しています。 ブログ移行日記（その1）に書いてありますが、当時はbrewでインストールしていました。 また、","tags":["hugo","dev container"],"title":"ブログ記述環境としてのDev Container"},{"contents":"WSL2にUbuntuを入れて、開発とかはこちらを利用しています。 また、Docker DesktopもWSL2のバックエンドエンジンを利用しています。\n知り合いとの話で、Ubuntuの外付けのSSDをマウントしたという話が出てきて、それだと遅くない？Ubuntu自体を移動できるんじゃないかな？という 流れになりました。 知り合いは、特に移動とかは考えてなかったのですが、自分のディスクの容量が今どのくらい使われているのかが気になり、調べてみると、 Cドライブの使用率が90%を超えてるじゃないですか。\nWizTreeというソフトを前回入れていたのを思い出して、再度調べてみたところUbuntuらしきvhdxファイルのサイズが171GB、Docker Desktopのデータ領域のvhdxファイルのサイズが81GBと、結構な割合です。\n前回は、Hyper-V管理ツールで仮想ディスクの圧縮処理を行ったのですが、Dドライブに移行したほうが安心できそうな気がしたので、移動の方法を調べました。\nWSLコマンドのドキュメントが公式で公開されています。こちらのコマンドを元に作業をしました。 また、ググって出てきた記事も参考にさせていただきました。ありがとうございます。\nwsl をDドライブに入れ直してディスク拡張する | blog.ojisan.io WSL2環境をコピー（複製）する方法 - Qiita まずは確認と停止 WSL2で使っているディストリビューションを確認します。コマンドは以下の通り。 実行した結果も含まれています。コマンドの実行にはコマンドプロンプトを使用しました。公式ドキュメントのドキュメントではスニペットはPower Shellと書かれてますが、コマンドプロンプトでも大丈夫そうでした。\nD:\\\u0026gt;wsl -l -v NAME STATE VERSION * Ubuntu Running 2 docker-desktop Running 2 docker-desktop-data Running 2 残念ながら、wslのコマンドでは実体がどこにあるのかを調べることができなかったですが、WizTreeでディレクトリ名などを見ていたのでなんとなう予測ができました。 （これ、他に知る方法あるのかなぁ？）\nディストリビューションの移動は次のような手順になります。\nwslのshutdown エクスポート（ディストリビューションのコピー） 今あるディストリビューションを削除 インポート（今ある名前で2.のファイルをインポート） まずは停止です。これをやらないとエクスポートができないので。\nD:\\\u0026gt;wsl --shutdown エクスポート 次にエクスポートです。 今回は以下の2種類の仮想環境をエクスポートします。\nUbuntu docker-desktop-data エクスポートでは、元のディストリビューションのファイル（Cドライブにあるファイル）が消えることはありません。 また、エクスポートの形式として、tarとvhdxの2種類が指定できます。 エクスポートのコマンドのデフォルトはtar形式ですが、エクスポート元のファイルがvhdxなので、vhdxでエクスポートしたほうがCPUにやさしかったです。 ちなみに、docker-desktop-dataはtar形式でエクスポートしてインポートしました。tar形式の場合は、ディスクのサイズが小さくなる可能性があるみたいです（不要なデータがvhdxの中に残っていたりする影響かと）。\nコマンドは以下の通りです（詳細は公式ドキュメントを参照してください）。出力ディレクトリはあらかじめ作っておきました（作ってない場合の挙動は未確認です。）\nD:\\\u0026gt;wsl --export Ubuntu .\\wsl\\Ubuntu\\ext4.vhdx --vhd docker-desktop-dataはtar形式です。\nD:\\\u0026gt;wsl --export docker-desktop-data .\\Docker\\ docker-desktop-data.tar ディストリビューションの削除（こわい？） 今ついているディストリビューション名を利用したいので、いったん、Cドライブ上にあるディストリビューションを削除する必要があります。 コマンドは公式ドキュメントにある--unregisterオプションを利用します。 以下のコマンドはUbuntuですが、docker-desktop-dataもやりました。\nD:\\\u0026gt;wsl --unregister Ubuntu ちなみに、このコマンドを実行すると、Cドライブの容量がいきなり空きました。 コマンドいっぱつでなくなりました。きちんとエクスポートしてから実行しましょう。 （なんなら、一度、別名でインポートして動作確認するのもいいかもしれないです。私はしましたｗ）\nインポート インポートするオプションも2種類あります。vhdxファイルの場合は、インプレースでのインポート（vhdxファイルをそのまま利用する形式）が可能です。 Ubuntuについてはこちらを利用しました。この場合、vhdxファイルがそのまま利用されるため、バックアップとしては利用できなくなります。今回は170GBもあるので、これでいいかと。\nD:\\\u0026gt;wsl --import-in-place Ubuntu .\\wsl\\Ubuntu\\ext4.vhdx tarファイル（docker-desktop-data）の場合は、通常のインポートを行いました。\nwsl --import docker-desktop-data D:\\Docker\\docker-desktop-data\\ D:\\Docker\\docker-desktop-data.tar この場合、tarファイルは残ったままで、新たにD:\\Docker\\docker-desktop-data\\ディレクトリにext4.vhdxファイルが作られました。 バックアップも取りつつ移行したい場合は--importがいいかもしれません。 また、WSLはバージョン1とバージョン2があり、インポートの際にこの部分も気にする必要があるようです。 今回はすべてバージョン2で、かつ、wslのデフォルトのバージョンを2にしてあったので特に意識していません。\nUbuntu起動ユーザーの指定と注意点 公式ドキュメントに、既存のユーザーを変更するコマンドの記載があります。 インポートしたディストリビューションは、デフォルトユーザーがrootになっていることがあるようなので、Ubuntuのユーザーを次のようなコマンドで変更しました。\nubuntu config --default-user johtani 公式ドキュメントの警告にもありますが、実行可能ランチャーがない場合があります。 今回のubuntuは、WSL2でUbuntuをインストールした時に作成されたコマンドで、unregisterした後にimportしてもきちんと動いたので問題にはなりませんでした。これは、インポートするときに、既存のディストリビューション名を利用したためと思われます。\nエクスポートやインポートの検証するために、NewUbuntuという名前で別途インポートした時には、NewUbuntuという実行可能ランチャーは作成されず、上記のデフォルトユーザーの設定は別の方法が必要になります（罠だ）\ndocker-desktop-dataのほうは、特に変更してないけど動いてそうだからいいのかな？ 前の設定の確認とかやっておくのがいいんだろうな、本当は。。。\nまとめ ということで、Cドライブに300GB近い空きができて、心の余裕もできました。 今回は、同じPC内で別のドライブへの移動でしたが、他のPCにもこれで移行ができそうですね。 たまにはバックアップをとっておくのもいいのかも？と思いました（やるかどうかはまた別の話）\n","date":1690180128,"dir":"post/2023/","id":"ed431877ce11fe403fee77f7d26ce637","lang":"ja","lastmod":1690180128,"permalink":"https://blog.johtani.info/blog/2023/07/24/move-distribution-to-another-disk/","publishdate":"2023-07-24T06:28:48Z","summary":"WSL2にUbuntuを入れて、開発とかはこちらを利用しています。 また、Docker DesktopもWSL2のバックエンドエンジンを利用して","tags":["wsl","windows"],"title":"WSL2のディストリビューションの環境移行"},{"contents":"前回の記事で、VS Code＋Dev Containerを導入しました。 残課題として「マルチコンテナ化」があるという話もしました。今回はDev Containerのdocker-compose.yml対応をした話をメモとして残しておきます。 実際、VS Code + Dev Containerに移行した後に、Esを起動してアプリからつなげるというのがうまくいかないというのがあったので対応がんばりました。。。\nDev Containerのdocker compose設定 この記事ではすでにdocker-compose.ymlが存在している状態の話をします。 変更する前は、devcontainer.jsonでベースのコンテナイメージの指定、マウントの設定などを行っていましたが、docker-compose.ymlにいくつかを移動しないといけません。 対応した時の作業の流れは以下のような感じです。\nワークスペース用のDockerfileの作成 docker-compose.ymlにワークスペース用のサービスを追加 devcontainer.jsonをdokcer-compose.ymlを利用する形に書き換え アプリでの接続文字列をlocalhostからdocker-compose.ymlのサービス名に変更 参考：対応した時のコミットです。差分などはこちらをごらんください。\ndevcontainerのリポジトリにPython+PostgreSQLのサンプルが公開されており、こちらを参考にしながら作業をしました。\n1. Dockerfileの作成 docker-compose.ymlだけでも完結するのかもしれないですが、いろいろやりたいことも出てくるかもしれないので別のファイルに切り出しました。 といっても、コンテナのイメージはdevcontainer.jsonに記述していたものを使っています。\nARG VARIANT=3.11-bookworm FROM mcr.microsoft.com/devcontainers/python:${VARIANT} ENV PYTHONUNBUFFERED 1 ENV TZ Asia/Tokyo TZはdevcontainer.jsonで指定していたものを、こちらに移行した形になります。 PYTHONUNBUFFEREDは参考にしたDockerfileの記載です。標準出力・エラーをバッファリングしない指定になっています。\n2. dokcer-compose.ymlにサービス追加 backendという名前のサービスをdevcontainer（VS Code）から接続するコンテナのサービス名にしています。\nservices: backend: build: context: . dockerfile: .devcontainer/Dockerfile init: true environment: - TZ=Asia/Tokyo command: sleep infinity volumes: - .:/workspace/search-research:cached - venv-search-research-backend:/workspace/search-research/.venv ... volumes: venv-search-research-backend: 1.で作成したDockerfileを利用します。docker-compose.ymlファイル自体は、プロジェクトのルートディレクトリに配置していますが、Dockerfileは.devcontainerディレクトリに入れたため、contextとdockerfileはこのような指定になっています。\ninitは、devcontainer.jsonで指定していた\u0026quot;runArgs\u0026quot;: [\u0026quot;--init\u0026quot;],の設定になります。\ncommandの部分は、コンテナが起動したままにしておくための設定です。\nvolumesでは2つのボリュームに関しての指定があります。 1つ目の/workspace...は、VS Codeがコンテナにプロジェクトをマウントする場所の指定です。 devcontainer.jsonだけを利用していた場合は意識していませんでしたが、/workspace/プロジェクト名というディレクトリにプロジェクトがマウントされていました。 docker-compose.ymlを利用する場合は、明示的に指定が必要です。 2つ目のvenv-...は.venvのディレクトリをコンテナの中だけのものにする設定を移植したものになります。 前回の記事ではコンテナIDをボリューム名に含めていましたが、こちらのほうがわかりやすいかと思い、プロジェクトの名前とサービス名をつけるようにしてみました。 Dev Containerで起動した場合はsearch-research_venv-search-research-backendという名前がついています（最初の部分はDev Containerがつけてるのかな？）\n3. dovcontainer.jsonの変更 devcountainer.jsonから呼び出すものの準備ができたので、devcontainer.jsonを書き換えます。 公式のドキュメントとしてDocker Compose向けのプロパティが紹介されています。 変更したものは次のような形です。\n{ \u0026#34;name\u0026#34;: \u0026#34;search-research\u0026#34;, \u0026#34;dockerComposeFile\u0026#34;: \u0026#34;../docker-compose.yml\u0026#34;, \u0026#34;service\u0026#34;: \u0026#34;backend\u0026#34;, \u0026#34;workspaceFolder\u0026#34;: \u0026#34;/workspace/search-research\u0026#34;, \u0026#34;postCreateCommand\u0026#34;: \u0026#34;/bin/sh ./.devcontainer/postCreateCommand.sh\u0026#34;, \u0026#34;customizations\u0026#34;: { ... dockerComposeFile : 利用するdocker-compose.ymlのファイルパス service：VS Codeが利用するワークスペース用のサービス名 workspaceFoldeer：VS Codeがコンテナに接続したときに開くフォルダのパス を指定します。これで、VS Codeでこのプロジェクトを開いた時に、Dev Containerがdocker-compose.ymlを使ってコンテナの起動（ビルドとか）を行ってくれます。\n4. アプリの接続文字列の書き換え こちらはおまけです。 PythonのアプリからElasticsearchに接続するときの文字列として、Dev Container化の前は、http://localhost:9200と指定をしていました。 Elasticsearch用のサービス（es）で、ポートフォワードをしていたためです。\nアプリ側もコンテナ化したので、Docker Composeが名前の解決をしてくれるので、http://es:9200という接続文字列で接続ができるようになりました。\nということで、ここまでで、VS Codeでプロジェクトを開くと、2つのコンテナ（backendとes）が起動してVS Code上でPythonアプリからEsへの接続ができるようになりました。\n追加の変更 参考のプルリクでは、上記まででしたがさらにいくつかの変更をそのあとやっています。\n起動するサービスの指定(開発だけするときはEsを起動したくない) devcontainer.jsonでrunServicesを使って指定できます（公式ドキュメント） GPUをコンテナから利用できるように devcontainer.jsonでfeaturesのnvidia-cudaを指定し、docker-compose.ymlでnvidiaのドライバーなどを設定することで対応しました。 nvidiaが公開しているcuda対応のコンテナイメージでもよかったのですが、こちらのほうが楽そうだったという理由です。featuresとコンテナのビルド、postCreateCommandの順序などはもうちょっと勉強しないといけない気がしています。 これらの対応はこちらのコミットで対応しています。\nGPUの対応は、私個人の環境はこれでいいのですが、複数の人がこのリポジトリを使う場合はどうやって切り替えたりするんだろう？という疑問が残っています。。。 今回はrinna/japanese-clipのモデルを使って、テキストからベクトルを生成する部分の処理のためにGPUを使いたいというモチベーションがあり、コンテナでもGPUを使えるようにしています（CPUだと時間がすごくかかる。。。）。\nサービス起動の新たな問題点 runServicesで起動するサービス名を指定したのはよかったのですが、Elasticsearchのサービスを起動して、データ登録や検索の確認を行おうと思った時に、EsのコンテナをVS Codeだけで起動する方法がまだわかっていません。。。 一度コンテナをビルドした後なら、「Remote Explorer」でOther Containerというくくりで表示され、右クリックで起動や停止ができそうなのだけど、新規サービスをdocker-compose.ymlに追加した場合は、自分でターミナルなどでコンテナのビルドをしないといけないかもしれないです。もうちょっと調べてみないとなぁ。\n副次的な効果 Docker Compose対応をしたことで、前回の記事での疑問点のうち、「コンテナ名」「VolumeのID」については懸念点がなくなりました。\n「コンテナ名」は、docker-compose.ymlのサービス名がコンテナ起動時に名前として利用されるため、Docker Desktopで見た時などの探しにくさはなくなりました。 ただ、「イメージ名」については、いまだに2つできています。「-uid」がつかないものの代わりに、search-research-backendというイメージが作られています。 ただし、実際に利用されるのは前回の記事に書いたようなvsc-search-research-bf04371c017c8d2f1dd5ad2529841b02e9ea1d1aaa4354c19edf53cef3f0c13b-uidという名前のイメージです。\n「VolumeのID」については、docker-compose.ymlのファイルで自分で名前をつけるようにしたので、コンテナのIDが利用されなくなったという次第です。 代わりに、プロジェクト名である「search-research」という名前を直接記述しているので、変数などで置き換えたほうがいいのかも？という気がしています。\nまとめ ということで、複数のコンテナを利用するプロジェクトでVS Code+Dev Container対応ができそうだということがわかりました。 ついでに、GPU対応もできたのでこれで、やっと他の検索エンジン対応などができる気がしています。 （その前にpre-commitを保存時にチェックする形に変更かなぁ） やりたいことからちょっとずつ外れている気もするけれど、新しいことを調べるのは楽しいですね。\n","date":1689902010,"dir":"post/2023/","id":"086b4fd5f77021a0a2aa6b0e90061486","lang":"ja","lastmod":1689902010,"permalink":"https://blog.johtani.info/blog/2023/07/21/multi-containers-with-dev-container/","publishdate":"2023-07-21T10:13:30+09:00","summary":"前回の記事で、VS Code＋Dev Containerを導入しました。 残課題として「マルチコンテナ化」があるという話もしました。今回はDev C","tags":["python","dev container"],"title":"VS CodeとDev Container（docker-compose.yml対応）"},{"contents":"前回の記事で、pre-commitとPyCharmとWindowsの組み合わせで困っていることを書きました。 これについて、知り合いとチャットで話をしていて、それほどPyCharmにこだわりもないよなぁということになり、 であれば、ISIDのブログ（Dev Containerを使ってステップバイステップで作るPythonアプリケーション開発環境 - ISID テックブログ）を試してみるとすっきりするかもしれないとなり、Dev Container対応をブログを参考に行ってみました。\n順を追ってブログで説明されているので、どういう仕組みなのか、どの設定が何を意味しているのか？がとてもよくわかりやすくすんなり対応することができました。\nブログの手順をなぞっているところでいくつか固有の手順や疑問点が出てきたのでブログに書き記しておきます。 結果は、コミットしてあるものを見てください。\nブログとは違う手順 まずはISIDのブログとは違う点をいくつか。\n.venvはいったん削除 ブログでは新規のプロジェクトを作成していく過程で、コンテナ化した環境を作った後に.venvをDockerコンテナのボリュームにして、最後に仮想環境のPythonを生成していました。 私の場合は、すでにホストOS（実際にはWSL2のUbuntuだけど）で.venvのディレクトリを作成してある状態だったので、いったん削除する必要がありました。 すでに存在する.venvがbindマウントされてしまっている状態になるため、Dockerのボリュームとの整合性が取れなくなるようです。\nこの作業を行う前か、途中でDev Containerを停止した状態で、.venvを削除することで問題なくDockerのボリュームに仮想環境のPythonが登録されるようになります。\npostCreateCommand.shの呼び出し方 ファイルに実行権限がないと、実行権限エラーが出ました。 実行権限を与えるか、次のような記述で動くようになりました。 今は、ファイルに実行権限をつけるのではなく、次のような記述にしていますが、何か問題あるかな？\n\u0026#34;postCreateCommand\u0026#34;: \u0026#34;/bin/sh ./.devcontainer/postCreateCommand.sh\u0026#34;, 実際に動作しているログを見ると\n/bin/sh -c /bin/sh ./.devcontainer/postCreateCommand.sh\nとなっているので、少し気持ち悪いのだけれども。。。\npostCreateCommand.shの追加処理 今回Dev Containerを適用したプロジェクトでは、sentencepieceを利用します。 この、sentencepieceをpoetryがインストールするタイミングで、cmakeを要求してきました。 今回利用しているDocker Imageにはcmakeは含まれていないため、以下の処理を追加しています。\nsudo apt update sudo apt-get install cmake -y また、rinna/japanese-clipも利用しているのですが、こちらは、poetryで追加してインストールでは依存するパッケージがインストールされないため、pipコマンドを利用するようにしています。\npip install git+https://github.com/rinnakk/japanese-clip.git コンテナイメージを作った後にやりたいことを、自由にスクリプトで書けるのは便利ですね。\npre-commitのスクリプトの再生成 こちらも、既存の環境が残っているとPythonへのパスの違いの問題が出たので、作り直しました。 .git/hooks/pre-commitのファイルを削除し、pre-commit installをやったものをリポジトリにコミットしてあります。\n疑問点 作業をしていて疑問点もいくつか出てきたのでメモを残しておきます。ちなみに、これらの疑問について実際に調べるまでには至っていません。 時間を見て解決できればなぁと（できるのか？）。\nImageが2つ Dev Containerの設定を書いた後に、コンテナをビルドすると、Docker DesktopのImagesにイメージが出来上がります。 この時、イメージが2つできあがっています（なぜ？）。\nREPOSITORY TAG IMAGE ID CREATED SIZE vsc-search-research-bf04371c017c8d2f1dd5ad2529841b02e9ea1d1aaa4354c19edf53cef3f0c13b-features-uid latest 25c7e23416ec 3 days ago 1.69GB vsc-search-research-bf04371c017c8d2f1dd5ad2529841b02e9ea1d1aaa4354c19edf53cef3f0c13b-features latest fcf9eaeb2187 3 days ago 1.69GB こんな感じで、最後に-uidがついているかいないかの違いです。 実際にコンテナ起動時に利用されるのは-uidがついているものになります。 なぜ2つになっているのか、1つにする設定などがあるのか？といったところが気になるところです。\nContainerの名前 devcontainer.jsonの設定を書き換えて、コンテナをリビルドすると起動したコンテナの名前が自動で割り振られているようです。 今は、fervent_hopperとなっています。ランダムにつけられているようなのですが、名前を付ける方法はないのかなぁ？と。\ndevcontainer.jsonにはnameというプロパティもあるのですが、この値がどこで使われているのかはよくわかっていません。 Remote Explorerでコンテナの一覧が見えますが、ここでは、リポジトリ名が利用されているようです。\nVolumeのIDはどこから？ devcontainer.jsonで次のような記述で、.venvのディレクトリようにDockerにボリュームを作っています。\n\u0026#34;mounts\u0026#34;: [ \u0026#34;source=venv-${devcontainerId},target=${containerWorkspaceFolder}/.venv,type=volume\u0026#34; ], 実際にコンテナでマウントされている情報を見ると\n/workspaces/search-research/.venv /var/lib/docker/volumes/venv-04emir9hi2caivtjunfe3l17452hkbb3hdut1qflbrn8n924ho5c/_data となっています。 04emir9hi2caivtjunfe3l17452hkbb3hdut1qflbrn8n924ho5cがdevcontainerIdに相当するのだとは思うのですが、誰がつけたものかなどがまだよくわかっていません。 もうちょっとわかりやすいものが使えるほうが嬉しいかも？と思っていたりします。 （複数Dev Containerを使い始めると、Docker Desktopで見ると、どのボリュームがどのDev Containerに紐づいているかがぱっと見ではわからない）\n.vscodeディレクトリどうしよう？ たぶん、VS Codeを触っている過程で、何かの設定をしてしまったのだとは思うのですが、 .vscode/settings.jsonというファイルができており、次のような内容になっています。\n{ \u0026#34;git.ignoreLimitWarning\u0026#34;: true } 何か意味があるかも？ということで、コミットしてリポジトリに入れたのですが、いらないのかもしれないなぁと。\n残作業 とりあえず、VS CodeでPython環境ができて、VS CodeのTerminalでPythonのプログラムが実行できるのはわかった段階です。 いくつか、今後調べながらやる必要があるものが残っているのでメモとして残しておきます。\nマルチコンテナ化 今回Dev Containerに対応したプロジェクトでは、検索エンジンもDockerのコンテナとして起動して、Pythonのプログラムから接続したいと思っています。 となると、docker composeでいろいろと起動するほうがネットワークなどの設定も楽になるのでは？と思っているところです。 Dev Containerのテンプレートがいくつか用意されており、その中に「Python 3 \u0026amp; PostgreSQL (postgres)」というのを見つけたので、このあたりが参考になるのでは？と考えているところです。\npre-commitではなく、保存時にフォーマット pre-commit＋localのコマンドも動くようにはなったのですが、保存時にフォーマットなどをかける設定もISIDのブログで記載がありました。 コミットしようとして、怒られるよりも、保存時に怒られたりするほうがいいかも？という気分になってきています。 どこまでが切り替え可能なのか？なども見ながら対応してみようかなと。\nもう少し開発してみて改善点を探っていく とりあえず動いたという段階です。 PyCharmとの違いがあるはずで（たとえば、git周りのGUIの違いとか）、そのあたりでどんな違いがあり、どんなものがあると嬉しいのか？といったものを調べる必要もあるかなと考えています。 TerminalでCtrl+rがうまく使えなかったり(Auto Hot Keyで検索のショートカットに割り当ててしまっているから。。。)などもあるので、この辺も調べていきたいなと。 Windows Terminalを使えたりするのかなぁ？\nまとめ さて、とりあえず、VS CodeでPythonのDev Container環境を作って動くところまでは来ました。 PyCharmを使いこなしていなかったのもあり、それほど違和感なく移行できるような気がしています。 調べることはまだまだあるし、プログラム書くつもりが、環境を整える方向に話がずれている気もしますが、まぁ面白いのでよしとするかなぁ。 いろいろまだまだ知らないことだらけです。。。\n","date":1689254123,"dir":"post/2023/","id":"a12474027c91fad5a861aa9919817d72","lang":"ja","lastmod":1689254123,"permalink":"https://blog.johtani.info/blog/2023/07/13/introduce-vs-code-and-dev-container/","publishdate":"2023-07-13T22:15:23+09:00","summary":"前回の記事で、pre-commitとPyCharmとWindowsの組み合わせで困っていることを書きました。 これについて、知り合いとチャット","tags":["python","dev container"],"title":"VS CodeとDev Containerの導入（まだ途中）"},{"contents":"最近、趣味（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書き始めました。\nきちんとPythonのプログラムをプロジェクトとして書いたことがないので、 Pythonのプロジェクトのディレクトリ構成などを手探りで進めているところです。 コードのフォーマットとかもやらないとなぁ？と知り合いのいるSlackでつぶやいたところ、gitのpre-commitフェーズでblackなどのフォーマットやスタイルを修正してくれるツールを実行する方法を教えてもらいました（PRまで送ってもらえたのでありがたい）。\nで、pre-commit周りの設定などを変えている段階で遭遇した問題点についてログを残しておこうと重いブログを書いています。 残念ながら現時点では解決してないんですけどね。。。\n手元の環境 簡単に環境を書いておくとこんな感じです。\nWindows上のPyCharmを開発で使用 プロジェクトのディレクトリはWSL2のUbuntu上 Python、gitはUbuntuのものを利用 プロジェクトのルートディレクトリにある.venvにvenvでPythonの仮想環境を作成してある 問題点 遭遇したpre-commitの問題点は次の通りです。\npre-commitの設定でrepo:localでローカルのプロジェクトにインストールしたコマンドを利用するように変更 すると、PyCharmでコミットすると、blackなどのコマンドが見つからない ターミナルでコミットするときはきちんと動作する 色々調べて試行錯誤した結果、現在はrepo:localでのローカルコマンドを使用する方法はあきらめました。 移行は、作業記録みたいなものです。どういう流れでpre-commitを取り込み、ローカルに切り替え、切り戻したかという話です。\npre-commitとpre-commit 最初に少し戸惑ったのは、pre-commitというツールとgitのpre-commitフックです。 gitのpre-commitのフックのために作られたPython製のpre-commitというツールがあります。\nこのPython製のツールを利用することで、プロジェクトに.pre-commit-config.yamlという設定ファイルを置けば設定に記述されたツールをgit commitのタイミングで実行してくれます。 実際には、pre-commitというツールの初期設定のタイミングでpre-commit installというコマンドを実行して .git/hooks/pre-commitというスクリプトが生成されます。 gitコマンドはcommitされた時に（commit前のフェーズ）でこのスクリプトを実行し、そこで.pre-commit-config.yamlが参照されています。\n.pre-commit-config.yamlの記述は次のようなものになります（最初にもらったPRより）。\nrepos: - repo: https://github.com/psf/black rev: 23.3.0 hooks: - id: black args: [\u0026#34;--line-length\u0026#34;, \u0026#34;120\u0026#34;, \u0026#34;.\u0026#34;] - repo: https://github.com/pycqa/flake8 rev: 6.0.0 hooks: - id: flake8 - repo: https://github.com/pycqa/isort rev: 5.12.0 hooks: - id: isort args: [\u0026#34;--profile\u0026#34;, \u0026#34;black\u0026#34;, \u0026#34;--filter-files\u0026#34;, \u0026#34;--multi-line\u0026#34;, \u0026#34;3\u0026#34;] - repo: https://github.com/pre-commit/mirrors-mypy rev: v1.4.1 hooks: - id: mypy 実際に、PRを取り込んで動かしてみたところ、blackなどが動いて行末のスーペースの除去や未使用のimportについて指摘をしてくれました。 便利だなと思ったのですが、ここで疑問が。\n今回は対象とするプロジェクトはpoetryで依存パッケージの管理を行っています。 今回、上記を動かすためにpoetryに追加されたものはpre-commitだけでした。 「あれ？blackとかはどこにあって、どうやって動いてるんだ？」という疑問が出てきます。 コンフィグファイルにはパスなどの記載をせず、それぞれのgithubリポジトリの記載とバージョンがあるからです。\npre-commitが使用するツールのインストール先 調べてみたところ、どうやらホームディレクトリにある.cache/pre-commitにblackなどのコマンドが見つかりました。 pre-commitツールが設定ファイルを基に、必要なコマンドをgithubからダウンロードしてきて実行時に利用しているようです。 pre-commitは便利なのだけど、せっかくPythonのプロジェクトだしそれぞれのツールはpoetryでpyproject.tomlでバージョンや設定を管理したほうがすっきりするのではないか？ということで、少し調べてみました。\n同じようなことを考えている方がブログを残していてくれました（Pythonレポジトリ用のpre-commit環境を整える）。 設定をpyproject.tomlに移行し、そのあと、ローカルのpetryでblackなどのコマンド類をインストールして利用する設定に書き換えています。 先人の肩に乗っかって、手元で同じようにpre-commitの設定ファイルのrepoをlocalに書き換えていき（その時のコミット）、ターミナルでpoetry run pre-commit run -aで動作確認できました。\nPyCharmでコミットしたらエラー ですが、実際に変更した状態でPyCharmからコミットしたら、コマンドが見つかりませんというエラーが出ます。。。 WSL2のターミナルでgit commitした場合は問題ありません。 どうして？となりますよね。。。。\n.git/hooks/pre-commitはPyCharm、ターミナルのどちらからも実行されています。 ですが、PyCharmではblackなどが見つからないというエラーが出ました。\n.git/hooks/pre-commitを見てみると、python実行するためのpythonのパスはプロジェクトにある.venv/bin/pythonを指定しています。 デバッグのために、このスクリプトにecho $PATHを差し込んで、git commitをPyCharmとターミナルからそれぞれ実行してみたところ、大きな違いがあります。\nターミナルで実行した場合は、\u0026lt;プロジェクトのディレクトリ\u0026gt;/.venv/binもPATH環境変数に存在していました。このため、.venv/binにあるblackなどを実行できています。\nPyCharmはWindowsから起動しています。プロジェクトのインタプリタとしては、WSL2のUbuntuにある.venv/bin/pythonを指定しているためもあり（？）、出力されたパスは/mnt/c/などのWindowsのパスなども入っていたりしますが、\u0026lt;プロジェクトのディレクトリ\u0026gt;/.venv/binは見つかりません。\nここからはソースコードは読んでいないので憶測ですが、.git/hooks/pre-commitで呼び出されているpre-commitツール（Python製）は、設定ファイルで指定されたコマンド（blackなど）を、コマンドとして今の呼び出されたコンテキストで実行しているのではないかということです。 実際、ターミナル上でもsource .venv/bin/activateを実行していない状態だとコマンドが見つからないというエラーが出ました。\n対処方法は？ ということで、今考えられる対処方法としては次の通りです。\n.git/hooks/pre-commitのスクリプトを修正して、\u0026lt;プロジェクトのディレクトリ\u0026gt;/.venv/binのパスを見えるようにする PyCharmで何かしらの設定を探す PyCharmではgit操作しない repo:localはあきらめて、.pre-commit-config.yamlでblackなどは管理して、pyproject.tomlからは除外する 1.ですが、.git/hooks/pre-commitはprecommit intallを実行すると自動で生成されるスクリプトです。自分の環境で書き換えたとしても他の人が同じ環境を作るときにパッチを当てるなどをしないといけなくなります。\n2.はそれらしい設定を見つけることができませんでした。\n3.はめんどくさいですよね。。。ターミナルでgitのコメントを日本語で書くためにいくつか他の設定を考えないといけないです。。。\nということで、今回は4.の対処をとりました。やりたいことは、ツールや環境をそろえるのではなく、プロジェクトでやりたいことをやることなので。。。\nまとめ 最終的には元に戻ってしまいました（pyproject.tomlに設定周りは移動した）。 Windows環境がちょっとややこしくしてるかもな？というのと、個人のプロジェクトなのでそこまで気にしなくてもいいのでは？というのもありそうです。 それにしても、世の中の皆さんはフォーマッターとかどのタイミングで動かしてるんだろう？とかどういう環境構築してるんだろう？とか気になってます。 最近だとこういうディレクトリ構造にする、こういうツールを使うと便利などあれば、コメントいただけると嬉しいです。\n教えてもらったISIDのブログ（Dev Containerを使ってステップバイステップで作るPythonアプリケーション開発環境 - ISID テックブログ）も参考にさせてもらおうと思ってるところです。Pythonの環境をコンテナに移動したいなぁというのもあるので。ただ、PyCharmだからこのブログの通りには行かないけど（VS Codeに移るのも検討したほうがいいのかなぁ）。\n参考サイト Git - Git フック pre-commit Pythonレポジトリ用のpre-commit環境を整える Dev Containerを使ってステップバイステップで作るPythonアプリケーション開発環境 - ISID テックブログ ","date":1688954148,"dir":"post/2023/","id":"698cf3cbd796161d82c9ac438ebab5d2","lang":"ja","lastmod":1688954148,"permalink":"https://blog.johtani.info/blog/2023/07/10/pre-commit-and-python/","publishdate":"2023-07-10T10:55:48+09:00","summary":"最近、趣味（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書き始めました。 きちんとPythonのプログラムをプロジェクト","tags":["python"],"title":"pre-commitとvenvとPyCharm（困ったな？）"},{"contents":"今年もこの季節がやってきました。 Berlin Buzzwordsにオンラインで出張してました。 今年もハイブリッド開催をしてくれたので、オンラインで参加できました。 現地ではブースが出たり、朝食なども用意されているようでした。今年は昨年と違いマスク必須でもなくなったようです。 MICESも去年同様、現地開催のみのようです（今見たら、昨年のビデオとスライドが公開されてるので、時間見つけてみてみよう）。\n今年はうれしいことに検索に絡むセッションが大多数でした。世の中的にChatGPTの盛り上がりやベクトル検索がいろんな検索エンジンで使えるようになってきたこともあり、 大規模言語モデルと検索エンジン、ベクトルデータベースに関する話がたくさんありました（昨年まではKafkaやストリーム処理の話も多かったんですが）。\nということで、今年もセッションを見ながら残したメモを公開しておきます。\n簡単にメモ What defines the “open” in “open AI”? セッションページ：What defines the “open” in “open AI”? 動画： Jennifer Ding - What defines the \u0026ldquo;open\u0026rdquo; in \u0026ldquo;open AI\u0026rdquo;? - YouTube \u0026ldquo;OpenAI\u0026quot;の話ではなく、オープンなAIとは？という話で、ライセンスの話であったり、コミュニティ（データセットの公開とかベンチマークの共有とか）に関する話であったり。 後半は気を抜いてしまって話をうまく聞き取れてないので、興味がある方はビデオで。。。\nVectorize Your Open Source Search Engine セッションページ：Vectorize Your Open Source Search Engine 動画： Atita Arora - Vectorize Your Open Source Search Engine - YouTube ベクトル検索が流行ってきてるけど、これまでの検索（エンジン）に対して、どうやってベクトル検索を取り入れる？という話です。 ベクトル検索ってどんなもので、どういうことの助けになりそうか？じゃあ、どうやって、これまでの検索が改善したかを見ていくのか？ という、これからベクトル検索を取り入れようとしている時にどのようなアーキテクチャにして、 どのような考慮するポイント（モデルの選択とかスケーラビリティとか）にどんなものがあるのか？といった紹介でした。 ざっくりですが、ベクトル検索やるのにどんなことをやっていけばよいのか？という地図になるようなセッションでした。\nSupercharging your transformers with synthetic query generation and lexical search セッションページ： Supercharging your transformers with synthetic query generation and lexical search 動画： Milind Shyani - Supercharging your transformers with synthetic query generation and lexical search - YouTube AWSの人の話でした。こちらもトランスフォーマーが検索に使えると便利だよねという話なのですが。 LLMを使うと高コストでサイズがどんどん大きくなっていて、小さな学習済みのモデルだといまいちな精度でだし、 ファインチューニングしたい場合、ドメインに特化したデータはなかなかないよね。とくにデータ（検索したいもの）はあるけど、クエリがないということがよくあるよね。 そこで、LLMを使って、データからクエリを作って、正解データを作り、それでファインチューニングすればいいのでは？ ということで、やってみました、どうでしたという話でした。\nブログなどもあるので参考にすると面白いかも\nThe Debate Returns (with more vectors) Which Search Engine? セッションページ：The Debate Returns (with more vectors) Which Search Engine? 動画：Charlie Hull - The Debate Returns (with more vectors) Which Search Engine? - YouTube 今年も検索エンジンの人を集めてパネルディスカッションです。今年は次の方たちが参加してディスカッションでした。\n参加者 Jo：Vespaの人。ランキングとかがよくできてるからVespa好き Alessandro：Apache Solrの人。SolrのPMCメンバー。なんでSolr？Pure OSSだし。スケーラブルだ Etienne：Weaviateの人。新しいAI nativeなベクトルデータベース Philipp：Elasticの人。 Kacper：Qdrantの人。 質問は次のようなものでした。\n最初の質問：スケールの話。スケールアウトかな？ 2つ目の質問：どんなアプリケーションが適していないか？ 3つ目の質問：どうやってAIをサポートできるの？ 4つ目の質問：どうやってコミュニティにアプローチしてる？ 5つ目の質問：自分の検索エンジンが使えない時に何を使う？ 6つ目の質問：今後に何が面白そう？ 最後の質問：あなたの検索エンジンが使われてるユースケースで一番好きなものは？ 2つ目や5つ目の質問が面白いですよね。実際の内容はぜひビデオを見ていただくのがいいかと（メモも取ったけど、聞いてもらうほうが面白そうだし）。\nWhat\u0026rsquo;s coming next with Apache Lucene? セッションページ：What\u0026rsquo;s coming next with Apache Lucene? 動画：Uwe Schindler - What\u0026rsquo;s coming next with Apache Lucene? - YouTube 毎年恒例Uweさん。今年Luceneが25周年という話で、これまでの進化の話を駆け足でしてくれました。 あとは、後半は来週9.7が出るよということで、9.7で入ってくるベクトルの距離計算の最適化に関して説明してくれています。 次のバージョンのElasticsearchでもこの最適化が使えるようになるという話もされていましたので、ベクトル検索を使ってる方は、次のバージョンも楽しみですね。\nBuilding MLOps Infrastructure at Japan\u0026rsquo;s Largest C2C E-Commerce Site セッションページ：Building MLOps Infrastructure at Japan\u0026rsquo;s Largest C2C E-Commerce Site 動画：Berlin Buzzwords 2023： Building MLOps Infrastructure at Japan\u0026rsquo;s Largest C2C E-Commerce Site - YouTube メルカリの検索システムに関係しているMLOps周りがどうやって進化してきたのか？という話でした。 英語にいらすとやの絵があるスライドがドイツで使われているのがとても新鮮ですｗ\nHighly Available Search at Shopify セッションページ：Highly Available Search at Shopify 動画：Khosrow Ebrahimpour - Highly Available Search at Shopify - YouTube Shopifyの検索プラットフォームチームの人の、Shopifyの検索プラットフォームがどういったものか？（EsとKafka使ってる）どんな工夫をしているか？という話です。 Kubeconでも他の同僚の方が話をされている見たいで、そちらも参考になるとのことでした（動画）。 スキーマ変更時の話とかもあり、実践的でした。最後に将来的な話でやはりベクトル検索というキーワードが出てきていました。あとは、データ量が大きいのでスケーリングの挑戦もあるとのこと。\nUsing Dense Vector search at the EU Publications Office セッションページ：Using Dense Vector search at the EU Publications Office 動画：Martin Bayton - Using Dense Vector search at the EU Publications Office - YouTube EUのPublication Office（日本だと公文書館とかになるのかなぁ？）の検索サービスで、Googleみたいなこと（検索結果の上にスニペットが出たり、そこにハイライトされたり）をやってみたいよね？という話みたいでした。実際公開してるかはわからないですが、途中からはPureinsightsという会社のプラットフォームで似たようなことをやるデモになってました。\nGoogleでも12%のクエリが、質問の自然文になっているという話で、検索結果にナレッジグラフからの情報（スニペットとか、質問に対する答えとか、地図とか）が出るようになってきていますと。 それをPublication Officeのデータで再現したデモを行った後に、どんな感じのアーキテクチャなのか？という概略を説明されています。国会図書館とかの検索サービスやってる方が興味を持ったりするかもなーと思ったり、思わなかったり？\nLearning to hybrid search セッションページ：Learning to hybrid search 動画：Berlin Buzzwords 2023： Learning to hybrid search - YouTube これまたキーワード検索とセマンティック検索のハイブリッドの話です。 よくハイブリッド検索というのを聞きますが、データだったりベンチマークなどの話があまりないですよね？昨年AmazonがECSIというデータセットを公開したりしています（rejasupotaroさんが年末に書かれた記事にも出てきていました）。 これにLearn to Rankとかもテストできるようなデータ（レビューや評価、カテゴリーとか）を拡張したものを作って、それをもとにいろいろとハイブリッド検索で精度を測ってみたというお話でした。 Metarankというリランキングエンジンの会社の方たちで、Metarankを使ってハイブリッドな検索結果のリランキングで精度がどのように上げられるか？という話です。 今年のTRECのProduct Search Trackの話もされていました。 これが元ネタのブログかな？\nCatch the fraud — with observability and analytics セッションページ：Catch the fraud — with observability and analytics 動画：まだ？ 最後は元同僚のセッションです。こちらは検索ではなく、ちょっと自虐的なネタをもとにしたオブザバビリティおよび分析のお話です。 コミュニティの人たちの貢献（ブログ書いたりプルリク送ったり、どこかで話をしたり）を計測して、年間の貢献者に対してプレゼントを上げるというのをやっているみたいです。 で、昨年の最も貢献した人にMac Bookをプレゼントするというすばらしい（暴挙）話で、チートしようとした人がいてそれを分析した話でしたｗ 締め切り直前に信じられない量の貢献したという登録がブラジルからあり、何かおかしいよね？ということで、Elastic Stackのオブザバビリティの機能などを元に分析してチートした人を除外していったよという話でした。 Kibanaが使いやすくなってるのがわかるセッションで面白かったです。\nまとめ 検索がまたすごく盛り上がってきたなーという時間があるカンファレンスでした。みんな似たような話（ベクトル検索、LLM、AIなど）だったりしますが、 知らないプロダクトで興味が出てくるものもあったし、Amazonのデータセットがあるからいろいろ試してみることもできそうだなぁと。\nすでにビデオが公開されはじめているので、気になったセッションのビデオも見てから後日またブログを書こうとおもいます （たぶん、一覧が作成されるので後日リンクを貼っておきます）。\n来年の予定（6月11日から開催）も公開されていましたし。来年も楽しみですね。 来年はプロダクションでベクトル検索やってみた話とかがさらに出てくるのかなぁ？\n","date":1687278645,"dir":"post/2023/","id":"9335522f4c8dbc7256a42a091e6e00bc","lang":"ja","lastmod":1687278645,"permalink":"https://blog.johtani.info/blog/2023/06/21/attend-berlin-buzzwords-2023/","publishdate":"2023-06-21T01:30:45+09:00","summary":"今年もこの季節がやってきました。 Berlin Buzzwordsにオンラインで出張してました。 今年もハイブリッド開催をしてくれたので、オンラインで参加で","tags":["conference","belin buzzwords"],"title":"今年もオンラインでBerlin Buzzwordsに参加した"},{"contents":"今年もなんとか振り返りブログを書いてます（時間大丈夫かな？w）。紅白をリアタイで見ながら。\n振り返り（2021年に書いた抱負から） まずは振り返りをと。\nフリーランス継続 ありがたいことに個人事業主として今年も１年乗り越えられました。 ZOZOさんには引き続きお世話になっている感じです。 10月からは今月末まで別のお客さんを手伝っていたりという感じでした（アップグレードの手伝いとか）。 相変わらず完全リモートで作業をさせていただいてます。\nただ、来年は今の所、余力がある感じになっているので、新しい仕事を見つけたいところだなあという感じです。 検索で何かお手伝いできることあれば、気軽にお声がけいただければと。\nプログラミング Linderaの大須賀さんのおかげで、レビューは定期的にやらせていただいてますw 業務がっつりというほどではないのですが、検証用のコードを書いたりはしています。\n個人用では、BGM環境のためにシェルを書いたり、文字化けしてるデータを解析したりするのにコードを書いてますが、もうちょっと量を増やしたいところです。 コードがっつり書く仕事をやらせてもらうのとかやらせてもらうのがいいかもなぁ。\n書くよりもどうしても読むほうが多くなってる気がします。\nブッチャー本ちゃんと読む 全部ではないですが、ZOZOさんで輪読をしたりしていました。 が、自分で全部読むといったところまではできてないです。\n読んだ本のブログを書く これはできてないですね。 読むのはちょとちゃってるんですが、ブログを書くところまではできてない。 メモとりながら読みたいですね。\n振り返り(今年あったできごと) ここからは今年の出来事を。 今年もずっと自宅で仕事した。来年は出張とかできるのかなあ？\n自宅環境 今年もDIY 検索ペンギン本が出版された 仕事場を模様替えしました。 今年もずっとWindows環境をメインで仕事をしていました。 年末まではM1 Macを借りて作業するという経験もできたのでよかったです。 今年仕事の環境は少し変わって、AVアンプ（譲り受けたもの）＋Polk Audioのスピーカーで音が良くなりましたw あと、机の天板を大きくして、作業がやりやすくなりました。写真はそのうち。\n仕事場の模様替えにもなるのですが、今年のDIYはラブリコ＋有孔ボードでケーブルやキーボードをすっきり片付けられる環境を作ってみました。 壁を有効活用できるのはよかったです。こちらについては、別途ブログを書こうと思います。\n今年最大のニュースは検索ペンギン本を出版したことです。 声をかけていただいた打田さんには感謝です。著者の皆さん検索システムを色々と手掛けられているので良い本になったと思います。\n『検索システム ― 実務者のための開発改善ガイドブック』 – 技術書出版と販売のラムダノート おー、届いたー pic.twitter.com/RbY5tOe9GB\n\u0026mdash; Jun Ohtani (@johtani) May 17, 2022 いろんなところで輪読も開催されているようで、顔を出してみたいなぁ。 輪読やってます！外部の人を呼んでもOKという方がいたら、参加してみたいのでTwitterでメンションしてもらえると嬉しいです。\n来年の抱負 ということで、来年の抱負です。\nフリーランス継続 プログラミング ベクトル検索まわりをさわる 本を読む 今年もありがたいことに仕事を継続していただけて、乗り越えられました。 来年も価値を提供できるように頑張っていきます。 もっといろんな会社の検索システムを見てみたいですし、検索エンジン入れてみたけどここからどうすればいい？という方も増えて来ているような気がするので、気軽に声をかけていただければと。\nプログラミングは、家の音楽ファイルの文字化けを直すプログラムをもう少しちゃんと書いてからブログを書きたいなと。まぁ、個人的なプログラムなので誰も嬉しくないかもですが（色々検討した結果Javaで書いてる）。 あとは、オライリーさんの初めてのGo言語を買ったのもあるので、前にRustで書いたElasticsearchへのBulk登録のツールをGoで書いてみようかなと考えているところです。みんなはデータ登録するときはどうしてるんだろう？\nNLPでBERTなどによる目まぐるしい進歩の影響もあり、ベクトル検索やセマンティック検索といった検索技術が各社から出て来ています。 ElasticsearchでもGAされたのもあり、今後ますます注目を浴びる技術になるのだろうなと。 ただ、これまでの検索とどう組み合わせるのがいいのか？どう言ったメリットデメリットがあるのか？向き不向きは？といったものもあるので、仕組みを調べながら色々と試行錯誤してみたいと思っています。\nさいごは、毎年書いてる気もしますが、本を読むのもやらんとなぁ。 あたらしいネタを仕入れては実践できる時間もとりつつ、他のことにも目を向けたいと思っています。\n今年は仕事の変化も少し出て来ているので、来年は新しいことをいくつかやってみたいところです。 あとは、外に出る機会が増やせるといいなぁ、少しずつ人から刺激をもらいたいと思っています。\nさて、今年は年内に無事描き終わりました。 来年もよろしくお願いいたします、良い年にしたいなー。\n","date":1672486684,"dir":"post/2022/","id":"df30d810068e4656498e5972c6de7e3d","lang":"ja","lastmod":1672486684,"permalink":"https://blog.johtani.info/blog/2022/12/31/review-2022/","publishdate":"2022-12-31T20:38:04+09:00","summary":"今年もなんとか振り返りブログを書いてます（時間大丈夫かな？w）。紅白をリアタイで見ながら。 振り返り（2021年に書いた抱負から） まずは振り返","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2022）"},{"contents":"PySpaアドベントカレンダーの12/15のエントリーです。昨日はtaichiさんでした。 今年はDIYではなく、PCにまつわる話を。\n仕事中はBGMが基本 フリーランスを始めて（2020年初頭）からすぐに、自宅で仕事をする情勢になりました。 打合せをしていないとき、カンファレンスの発表などの動画を見ていないときは基本的にBGMをかけて作業をしています。 音源としては、CDなどから音楽ファイルにしたり、AmazonやSonyのサイトで購入した音楽ファイルなどがNASにあります。\n今年10月までの環境 2020年の後半に次のような環境を構築して今年の10月まで使っていました。\nLibreELECをラズパイ4に入れて、Kodiのリモコンをスマホに入れたら快適になった\n\u0026mdash; Jun Ohtani (@johtani) October 20, 2020 KODIと呼ばれるマルチメディアセンター？のようなソフトで、それを動かす最小限のOSとして、LibreELECが公開されています。 これをラズパイ4に入れて、NASからファイルをSSDにコピーしてそれをラズパイに接続して音楽を聞いていました。 毎回ラズパイの画面を見に行くのも面倒なので、再生などの操作にはAndroid用のKodiのリモコンアプリを使っていました。\n場所も取らないのでよかったのですが、使っているといくつか問題点が。\n時々調子悪（音が出ない、リモコンからつながらない、無反応など）くなって、ラズパイ再起動 音楽ファイルを購入して増えた時に、外付けSSDを取り外してPCでコピーしたり スマホじゃないと再生できない（PCのクライアントもあったのかもだけど調べてなかった） Ubuntu on Mac mini 10月に模様替えをして、2012年製のMac Miniが宙ぶらりんになりました。 さすがに古いしメインマシンがWindowsになっているのもあり、macOSである必要も特にないので、Ubuntu 22.04を入れて何かに使えるのでは？と。 また、1TBのSSDに内臓ディスクを乗せ換えていたのもあり、音楽再生に使ってみようということに。 なので、Kodiの環境で困っていた点も考慮して、ほしい機能を元にちょっと探してみました。\n音楽再生 on Ubuntu 音楽再生でほしい要件としては次のようなものです。\nUbuntuで音楽再生できるソフト（あたりまえ） PCから操作したい（できればブラウザ） 音楽ファイルの更新（ローカルでもいいけどNASからもってきたり） 日本語の曲情報も表示 対象音楽ファイルが豊富（そんなに制限があるものはないだろうなぁ） 上記の要件をもとに適当にググって見つけてきたのがOwnToneというソフトでした。\nOwnTone OwnToneの説明は公式サイトを見ていただくとして、OwnToneにしてよかったなというのが以下の点です。\nインストールが簡単（apt-getでインストールできる） サポートフォーマットが豊富 Web UIがついてる（ブラウザで見えるし、スマホでもOK。どのブラウザから見ても今の状況も分かる） 簡単だけど検索できる プレイリスト対応（ファイルパスを入れるだけ） サムネイルとかも出てくる（どうやってんだろう？ｗ） AirPlayで再生できる（AVアンプを利用しており、そこにAirPlayで再生できてる） OSS（まだソースは見たことないですがｗ） 再生画面例\nやっぱ検索も気になるよね？\n日本語も検索できるな。 pic.twitter.com/EF6WHkJKli\n\u0026mdash; Jun Ohtani (@johtani) October 19, 2022 とりあえず、インストールして画面もすぐに出て操作も簡単で、便利な世の中になったなーと感動しましたｗ\nただ、音がヘッドフォン端子に刺したアナログ出力先のスピーカーではなく、本体のスピーカーで最初はなってしまいましたｗｗ Linuxの音周りが全然わかってない問題が発覚。\n幸い、先週のPyspa Advent Calendarのエントリーを書いていたaodag先生に助言をいただき、alsamixerで音の設定を見たところ、ヘッドフォン端子がミュートされていたので、ミュートを外して無事再生できました。 インストール当初はYAMAHAのアクティブスピーカーにJust Mixer経由でヘッドフォン端子（アナログ）で出力して音楽再生をしていました。 今は（この記事を書いてる現時点で）、AVアンプのAirPlayにOwnToneから音を流している形で聞いています（便利なんだけど、当初の想定とは異なる、理由は後述）。\nファイルのコピーとか さて、上にも書きましたが、NASにバックアップもかねて音楽ファイルを保存してあります。 新しく買ったファイルもここに置くようになっています。 OwnToneのMac MiniからNASをネットワーク経由で見に行くのもいいのですが、できればローカルにあったほうがネットに影響も出ないなと。\nということで、定期的にNASをウォッチしてMac Miniにファイルをコピーするようなプログラム（Bashスクリプト）を書いてみました。 毎回購入後に手で実行もめんどくさいので毎日夜中にcron実行するような設定になっています。\nスクリプトの中身は次のような感じです。\nfindコマンドで特定の日時（最近コピーしたファイルの日付）以降(-newermtオプション)のファイルのリスト（音楽ファイルの拡張子に限定）を取得 取得したリストをもとに以下の操作 ファイルをコピー コピーしたファイルをコピーした日付のプレイリストを作って入れる（プレイリストはパスだけ書けばOK） mp4形式だと聞けない端末もあるので、soundconverterコマンドでmp3に変換してNASに戻す 最新のファイルの日付を保存（次回のfindコマンド） ファイルがあったら、OwnToneの再読み込みのエンドポイントをcurlでキック NASはSambaでマウントして、見えるようにしてあります。 やっぱり、自動化便利ですねぇ。 気に入った曲を買ってNASに入れとけば聞けるようになるのは本当に便利。\n他にもスマートプレイリストとかもあるので、活用しないとな。\n今後の課題 さて、すごく便利になったのですが、課題も残っています。\n音声出力問題 アナログ出力はaodag先生の助言ですぐに解決したのですが、takabowから譲り受けたAVアンプを導入してから実は音の出力がうまくいっていません。\nHDMI、光端子出力でAVアンプにつなごうとしたのですが、私のUbuntu力（Linux力？）が全然不足しているのでうまくいっていません。ググりつつ、HDMI、光出力でamixerというコマンドで音声ファイルを鳴らすところまでは行ったのですが、OwnToneに設定するとうまくいかない状況です。 結局、解決してないのですが、AVアンプのAirPlayのレシーバー経由で音楽再生ができてしまったので、とりあえずAirPlayで運用することにしました。時間を見つけてaodag先生の記事を読み直して再チャレンジしないとな（けど、鳴ってるしなぁ、音ｗ）。\n文字化け問題 これは、OwnToneというよりはもともとあった問題です。 古い音楽ファイルだったり、Wav形式のファイルなど、様々な形式のファイルを持っています。 音楽サーバーとは別に、音楽ファイルの検索をできるようにしつつ、付加的な情報（Wikimediaなどのデータとか）を付与して、検索できるようにしてみようと思い、音楽ファイルからメタデータを抜き出して、ElasticのApp Searchにいれるデータを作るツールを書いたりしています。 この時にも文字化けに遭遇しました。\n様々な音楽ファイルにはメタデータを付与することができる仕様が決まっています（ID3タグ - Wikipediaなど）。 ただ、文字コードの情報が入っていなかったり、デフォルトとは違う文字コードでデータを付与したファイルがあったり、いろいろな原因で文字化けしているものがあります。 昨年Amazonで購入したmp3の中にも文字化けしているものもあったりします。Wavファイルに付与されたタグなどは、容赦なくShift-JISだったりしますが、読み込むソフトはUTF-8で読もうとしたり。。。\n検索サーバーにデータを抜き出して入れるツールを書いているときは、元のファイルを変更することなく、抜き出す時点でいくつかの文字化けに対応した処理を書いたのですが、今回のOwnToneで曲を流すと結局、元のファイルをきれいにしないとダメだということに気づきました（すぐわかるだろ。。。）\nということで、書いている途中のツールをもとに、根本的な文字化けのファイルのメタデータをきれいにするプログラムを書かないといけないなぁと。\nちなみに、メタデータの抜き出しにはJavaでプログラムを書いており、JAudiotaggerというライブラリを利用しています。 Pythonや他のJavaのライブラリを試そうとしたのですが、文字コードが決め打ちで抜かれているものが多く、ライブラリから読みだした時点ですでにどうしようもない状態のものが多いといった問題からこのライブラリにたどり着きました（まぁ、まだちゃんとしたものができていないんですけどね）。\n検索サーバー OwnToneのUIはブラウザでうごきます。 検索窓もついています。 が、先ほども書いたように、他にもデータを追加して、いろんな検索をしてみたいなぁと（ドラマに使われてたとか、CMにつかわれてたとかとか）。 検索が好きでいろいろとやってるので、その辺も遊んでみたいなぁと思っているところです（実際、ElasticのApp SearchにWikidataから生成した類義語を入れてみたりしている）。\nこうやってブログにしてしまったので、課題をつぶしていなかったら、Twitterなどでつついてくださいｗ\nまとめ 構成図とかは書かなかったですが、OwnToneを使うと簡単にWeb UIが入った音楽サーバーが使えるようになって、仕事がはかどりますよという記事でした。 他にもこれに関するネタを募集してますので、コメントもらえるとうれしいです（Twitterでメンションも大歓迎）。\n","date":1671030358,"dir":"post/2022/","id":"67c2ae6761e89be0fa66db9623b40d30","lang":"ja","lastmod":1671030358,"permalink":"https://blog.johtani.info/blog/2022/12/15/music-server-on-mac-mini/","publishdate":"2022-12-15T00:05:58+09:00","summary":"PySpaアドベントカレンダーの12/15のエントリーです。昨日はtaichiさんでした。 今年はDIYではなく、PCにまつわる話を。 仕事中は","tags":["misc","music"],"title":"仕事中のBGM環境"},{"contents":"本記事は情報検索・検索技術 Advent Calendar 2022の9日目の記事です。\nだいぶ間が空いてしまいましたが、日本語のオートコンプリートに関する記事の続きです。 という感じで、Suggesterのデータ構造とか仕組みを書こうと思っていたのですが、思ったよりも調べないといけないことが多くて挫折しました。。。 （これの続きは年末年始で調べて書くはず？）\nということで、代わりにElasticsearch/OpenSearchのアーキテクチャの変更に関してさらっとまとめてお茶を濁してみようと思います。\n発端はElasticON Tokyo？ 先週の11月30日に、ElasticのオフラインイベントであるElasticON Tokyoが開催され参加しました。 参加しようと思ったのは、10月の頭にElasticのブログで公開された「Stateless — your new state of find with Elasticsearch」というアーキテクチャの変更がきっかけです。\n（図はElasticのブログから引用）\nElasticsearchはLuceneのインデックスを分散したシステムとしてスケールアウトできるようにするという目的でリリースされました。 インデックスをシャードという単位で複数のElasticsearchのノードにデータを保存し、レプリカを作ることで分散する仕組みを実装していました。 Elasticsearchでは、インデックスのレプリカは、作成したインデックスを定期的にコピーするのではなく、登録するデータがElasticsearchのクラスターにやってきた時に、 データ自体をコピー先にも配り、プライマリーやレプリカとなるシャードがあるノード上でそれぞれインデックスに登録する処理を行うという処理の流れです（古いけど、わかりやすい説明はこちら）。 この場合、インデックスにデータを登録する処理（転置インデックスのデータ構造に変換する処理など）は、レプリカの数だけ同じ処理がクラスター上で発生します。\nこの基本的なアーキテクチャをもとに、保持するデータの鮮度（新しいデータのほうが検索頻度が高い、インデックス登録する時はマシンは多く、古くなったデータが入ったインデックスはコストが低いマシンになど）などを元に、クラスター内のノードの特性を異なるものが混在するような複雑な仕組みを作ってきました。 いろいろなデータの持ち方などで多くのデータなどを保持できるようにしてきたのですが、クラスター全体としては、検索の負荷のピークをさばけるような構成を基本的に保持しておくというかんがえです。\nただ、昨今は必要に応じてスケールアウト（リクエストが増えたりデータ量が増えた時）、スケールイン（夜中は利用者が少ないからクラスターを小さくしたい時）できるような仕組みのほうが求められています。 そこで、発表されたのが上記のブログであり、上図の新しいアーキテクチャです。 計算処理（データを登録、検索する処理）とストレージを分離し、さらに登録する処理と検索する処理も分離した構成です。 このようなアーキテクチャにすることで、登録処理の演算コストがレプリカごとに必要ではなくなり、検索の部分だけだったり、登録の部分だけをスケールアウト・インできるような自由度が手に入ります。 また、ストレージ部分でレプリカを担保（S3とかのオブジェクトストレージで冗長性を担保）できれば、レプリカのストレージコストも必要なくなります。\nというブログが発表されたのですが、詳細などはまだよくわからなかったのでElasticON Tokyoに参加して詳しい話が聞けるのかなぁと期待していました。\n参加当日の朝のびっくりするニュース 11月30日の朝に起きて、出かけようかと思っていたところに、AWSのre:Inventで発表されたニュースが舞い込んできました。\nほー（まだタイトルしか読んでない）https://t.co/KK22duaBNH\n\u0026mdash; Jun Ohtani (@johtani) November 29, 2022 Amazon OpenSearchがServerlessオプションを発表というニュースです。 （Amazon OpenSearchとは、AWSがElasticsearchをフォークして始めた検索エンジンで、Amazon OpenSearch Serviceというのは、AWSがそれをSaaSとして提供しているものです）\nまぁ、気になりますよね、「Serverless」ってキーワードに。 ElasticON Tokyoに向かう電車でブログを読んだり、どんな仕組みかを調べたので、それを簡単にまとめておきます。\nプレビュー段階（Tokyoリージョンではもう試せる） これまでのAmazon OpenSearch Serviceとは別（オンザフライで移行はできない？） 「コレクション」という単位でクラスターを管理（スケールインとかアウトとか） コレクションにはタイプがあり、タイムシリーズ（ログとか）か検索のユースケースなのかで使い分ける（公式ドキュメント） インデックス処理と検索処理で計算ユニット（OCU）が別々にスケールできる（下図） 作成されたインデックスはAmazon S3に保存され、そこで冗長性は担保される。（下図） 検索処理のユニットはS3のデータをローカルに持ってきて処理をできる データ登録とかのAPIは基本的にServerlessかどうかで違いはなさそう(これまで通りのクライアントでアクセスとかで競う) 設定した範囲でいいかんじにスケールアウトインしてくれそう（ほんとかな？） もちろん、いくつか制限がある（サポートしてないプラグインとか操作もある） （図はAWSのドキュメントより引用）\n発表時のブログでは詳しくはわからないのですが、公式ドキュメントではさらに詳しく説明がありました。 こちらを読むほうが仕組みがわかると思います。 今後もどんどんドキュメントは充実していくんだろうなと。今ならまだサクッと読める量ですｗ\nただ、「サーバーレス」という定義が私はよくわかりませんでした。 公式ドキュメントを読むとコレクションを作ると少なくとも4つのOCUが起動しているみたいで課金されると記載があります。\nまぁ、Elasticの発表と同様に、これまでは最大負荷の時を元にクラスターを維持せずとも、より柔軟に検索だけ、登録処理だけを一時的にスケールできるとコストを下げられそうですね。 すぐに誰かが使ってみたブログなどを出してくれると思うので、細かな使用感などはそのうちわかってくるかと。\n今後は？ ElasticもAWSも考え方の基本となっているのは、Berlin BuzzwordsでAmazonのMikeさん（Luceneのコミッター）が2019年に発表されたものだと思っています。 アーキテクチャの変更がどんな影響が出るかはわからないですが、少なくとも検索のユースケースでよりスケールアウトしやすくなるだろうなと。 どちらもSaaSとしての仕組みとして提供するので、検索エンジンそのものの機能として公開されるかはわからないです。 ですが、そのほかの検索エンジンも出てきていますし、今後も検索エンジンから目をはなせないです。 今回は残念ながら触っていませんが、時間を見つけて使ってみたいです（Elasticも早く出してくれないかなー）\nということで、当初の予定とは違うブログになってしまいました。。。 技術的な深い話はまたどこかで。。。\n参考文献 Stateless — your new state of find with Elasticsearch | Elastic Blog Preview： Amazon OpenSearch Serverless – Run Search and Analytics Workloads without Managing Clusters | AWS News Blog Berlin Buzzwords 2019： Michael Sokolov \u0026amp; Mike McCandless–E-Commerce search at scale on Apache Lucene - YouTube ","date":1670516125,"dir":"post/2022/","id":"9693a1e77dee5785b1dc61ccffd2e906","lang":"ja","lastmod":1670516125,"permalink":"https://blog.johtani.info/blog/2022/12/09/open-search-serverless/","publishdate":"2022-12-09T01:15:25+09:00","summary":"本記事は情報検索・検索技術 Advent Calendar 2022の9日目の記事です。 だいぶ間が空いてしまいましたが、日本語のオートコンプリートに関する記事の続きです。","tags":["elasticsearch","opensearch"],"title":"ElasticsearchのアーキテクチャとStateless / Serverless"},{"contents":"前回は日本語用オートコンプリートのためのAnalyzerとして、どうやって使うのかを簡単に紹介しました。\n今回はもう少し、いろんなパターンを試してみたいと思います。\nローマ字入力のゆれ 前回のサンプルでも「吾輩\u0026hellip;」のデータをサジェストするためのサンプルとして、「wagah」という「わがはい」をローマ字にしたものを利用しました。\nちなみにローマ字というとどんなものを思い起こしますか？ 普通は学校で習ったヘボン式あたりだと思います。 Kuromojiの読みでローマ字出力するには通常、kuromoji_readingformでuse_romajiをtrueにします。 以下、「吾輩」のサンプルです。\nGET _analyze { \u0026#34;text\u0026#34;: [\u0026#34;吾輩\u0026#34;], \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji_tokenizer\u0026#34;, \u0026#34;filter\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;kuromoji_readingform\u0026#34;, \u0026#34;use_romaji\u0026#34;: true } ] } レスポンス { \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;wagahai\u0026#34;, \u0026#34;start_offset\u0026#34;: 0, \u0026#34;end_offset\u0026#34;: 2, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 0 } ] } 「吾輩」の場合は特に問題ないのですが、ローマ字による日本語入力の場合、次のような単語を入力するときに、ゆれが生じます。\nシャボン＝「shabon」 新橋＝「shimbashi」 括弧内はkuromoji_readingformで出力したもの（＝ヘボン式のローマ字）です。 ですが、ローマ字入力の場合は「syabon」や「shabon」と入力したり、「sinbasi」や「sinnbasi」と入力すると思います。 JapaneseCompletionAnalyzerを利用したCompletion Suggesterの場合、これらのゆれも考慮してサジェストしてくれるようになっています。 前回のサンプルデータを用いると次のような感じです。\nGET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;sha\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } } } GET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;sya\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } } } これらのリクエストは、「しゃ」について2パターンになっていますが、結果はどちらも次のものが返ってきます（このレスはsyaのレスになります）。\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;sya\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 3, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;シャドウ・ワーク\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;000739\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;シャドウ・ワーク\u0026#34;, \u0026#34;朝倉 克彦\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;シャボン玉\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;045054\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;シャボン玉\u0026#34;, \u0026#34;豊島 与志雄\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;上海\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;050899\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;上海\u0026#34;, \u0026#34;横光 利一\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;斜坑\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;002095\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;斜坑\u0026#34;, \u0026#34;夢野 久作\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;社会事情と科学的精神\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;053864\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;社会事情と科学的精神\u0026#34;, \u0026#34;石原 純\u0026#34; ] } } ] } ] } } 「sinnba」や「shinba」も試してみました。\nGET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;sinnba\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } }, \u0026#34;_source\u0026#34;: [\u0026#34;suggest_ja\u0026#34;] } GET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;shinba\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } }, \u0026#34;_source\u0026#34;: [\u0026#34;suggest_ja\u0026#34;] } これらも同じ結果です。\n{ \u0026#34;took\u0026#34;: 0, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;shinba\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 6, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;しんばい\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;044942\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;しんばい\u0026#34;, \u0026#34;村山 籌子\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;新橋\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;002409\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;新橋\u0026#34;, \u0026#34;北原 白秋\u0026#34; ] } } ] } ] } } 入力されるパターンを想定した実装がされているので対応できている形です。 使い方が楽なだけでなく、より使いやすくなってるのは便利ですね。\nうまくいかないパターン 万事OKかというと残念ながらそうでもありません。 うまくいかないパターンもあります（これが本当にうまくいかないかは難しい話な気がしますが）。 「日本」という漢字ですが、「にほん」「にっぽん」どちらとも読めますよね？ これらを試してみると次のようになります（リクエストは省略します）。\nまず「にほん」\n{ \u0026#34;took\u0026#34;: 0, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;にほん\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 3, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;日本橋\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;004565\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本橋\u0026#34;, \u0026#34;泉 鏡花\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本橋\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;045357\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本橋\u0026#34;, \u0026#34;牧野 信一\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本橋あたり\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;047648\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本橋あたり\u0026#34;, \u0026#34;長谷川 時雨\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本橋附近\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;055666\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本橋附近\u0026#34;, \u0026#34;田山 花袋\u0026#34; ] } } ] } ] } } 次に「にっぽん」\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;にっぽん\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 4, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;日本アルプスの五仙境\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;056269\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本アルプスの五仙境\u0026#34;, \u0026#34;木暮 理太郎\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本出版協会論\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;049436\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本出版協会論\u0026#34;, \u0026#34;嶋中 雄作\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化と科学的思想\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;055750\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化と科学的思想\u0026#34;, \u0026#34;石原 純\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化のために\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;003183\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化のために\u0026#34;, \u0026#34;宮本 百合子\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化の特殊性\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;055290\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化の特殊性\u0026#34;, \u0026#34;戸坂 潤\u0026#34; ] } } ] } ] } } 最後に「日本」\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;日本\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 2, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;日本アルプスの五仙境\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;056269\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本アルプスの五仙境\u0026#34;, \u0026#34;木暮 理太郎\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本出版協会論\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;049436\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本出版協会論\u0026#34;, \u0026#34;嶋中 雄作\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化とは何ぞや（其二）\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;002940\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化とは何ぞや（其二）\u0026#34;, \u0026#34;内藤 湖南\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化と科学的思想\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;055750\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化と科学的思想\u0026#34;, \u0026#34;石原 純\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;日本文化のために\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;003183\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;日本文化のために\u0026#34;, \u0026#34;宮本 百合子\u0026#34; ] } } ] } ] } } 最初の「にほん」は「日本橋」がヒットしているようです。返ってきたoptionsの数は4件しかなく、どうやらこれがすべてのようです（取得件数はデフォルト5件）。 2番目の「にっぽん」は「日本」という単語から始まるものがヒットしていますが、「日本橋」はなさそうでした。 最後に「日本」という漢字を入力にした場合は2つの合計が帰ってきているようです（今回のレスポンス例にはありませんが、サイズを大きくすると「日本橋」が帰ってきていました）。\nどうしてそうなるの？ JapaneseCompletionAnalyzerの基本的な動作としては、\nKuromojiが単語に区切る 区切られた単語ごとに読みを持っている 元の単語と読みをローマ字にしたものが最終的に出てくる というような動きです。 この時、単語には「1つ」の読みが対応しています。 読みから単語を探そうとすると、読みの違い（ゆれ）を吸収することはできないためです。 JapaneseCompletionAanlyzerは3点目のローマ字のゆれに対応していますが、入力となる読みのゆれまでは対応できないです。 対応しているといいかどうかというのも難しい判断になる気もします。。。\nそのほかの例としては次のようなものもあります。 これは、今回のオートコンプリートの話とは少しずれてるかもしれませんが、1番目の処理の結果が変わってくる例です。 「南方熊楠」という名前の間にスペースがあるかないかで、出力される読みが変わってくる例です。\nGET _analyze { \u0026#34;text\u0026#34;: [\u0026#34;南方 熊楠\u0026#34;], \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji_tokenizer\u0026#34;, \u0026#34;filter\u0026#34;: [\u0026#34;kuromoji_readingform\u0026#34;] } GET _analyze { \u0026#34;text\u0026#34;: [\u0026#34;南方熊楠\u0026#34;], \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji_tokenizer\u0026#34;, \u0026#34;filter\u0026#34;: [\u0026#34;kuromoji_readingform\u0026#34;] } # GET _analyze { \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;ナンポウ\u0026#34;, \u0026#34;start_offset\u0026#34;: 0, \u0026#34;end_offset\u0026#34;: 2, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;クマグス\u0026#34;, \u0026#34;start_offset\u0026#34;: 3, \u0026#34;end_offset\u0026#34;: 5, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 1 } ] } # GET _analyze { \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;ミナカタ\u0026#34;, \u0026#34;start_offset\u0026#34;: 0, \u0026#34;end_offset\u0026#34;: 2, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;クマグス\u0026#34;, \u0026#34;start_offset\u0026#34;: 2, \u0026#34;end_offset\u0026#34;: 4, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 1 } ] } 人名や地名は1つの漢字に対して多くの読みが存在しているので大変です。。。 どうしてこれは出てこないんだろう？と不思議に思った場合は、_analyze APIを使ってどういう動きなのかを見てみるのがいいかと。\nまとめ ということで、少しだけですが、こんなことができるよ、できないよというのを書いてみました。 挙動をしっていれば、なんでこうなってるんだっけ？といったことを調べる役に立つかと思います。 入力された文字をもとにどれをサジェストするかなどについてはもう少し違う動きなので、中の仕組みをそろそろ書かないとなぁ。\n参考 同形異音語 - Wikipedia ","date":1660099802,"dir":"post/2022/","id":"73279888a8fe482c836fb19ca23318dc","lang":"ja","lastmod":1660099802,"permalink":"https://blog.johtani.info/blog/2022/08/10/jp-auto-completion-2/","publishdate":"2022-08-10T11:50:02+09:00","summary":"前回は日本語用オートコンプリートのためのAnalyzerとして、どうやって使うのかを簡単に紹介しました。 今回はもう少し、いろんなパターンを試","tags":["elasticsearch","lucene"],"title":"ローマ字入力のゆれと読み（JapaneseCompletionAnalyzerその2）"},{"contents":"風のうわさで、日本語用のオートコンプリートのためのTokenFilterとAnalyzerがLuceneに取り込まれたと聞きました（LUCENE-10102）。 Elasticsearchでも使えるかなぁ？ということで調べたところ（調べた？聞いた？）、どうやら8.1から利用できるようになっている（GitHub Issue #81858）みたいです（まだ、公式ドキュメントには記載がないのですが）。\n8/17追記\n作者の打田さんがブログ書いてたの見落としてた（もしくは見たけど忘れてた）ので貼っておきます。マルチテナンシー下での Query Auto Completion 設計・運用戦略 - LegalForce Engineering Blog\nということで、こんな感じで使えるよというのを試してみました。\nどういうもの？ 日本語入力方法を考慮したオートコンプリート用のトークンを生成してくれるTokenFilterと、 それをLuceneのSuggesterで動くようにしたAnalyzerが用意されています。 Elasticsearchでは、Kuromojiプラグインにそれらを使えるようになっています（バージョン8.1.0以降）。 KuromojiTokenizerと一緒に利用する前提の仕組みとなります。\nオートコンプリートとは？ 検索窓などでキー入力をしていると、入力した文字で始まる単語の一覧が現れることがあると思います。 あの機能がオートコンプリートと呼ばれるものです。search-as-you-typeとも呼ばれることもあります。 （検索ペンギン本にも書いてあるので興味のある方はぜひ！（ステマ）） 入力された文字列を含むパターンもありますが、今回紹介するものは入力された文字で始まる単語を見つけてくる機能になります。\n何がなんで追加されたの？ 日本語の入力方法は、かな入力の人もいればローマ字入力の人もいます。 ですので、オートコンプリートでの入力として、「しゃ」という入力が来る場合もあれば、「sha」というローマ字入力途中のものが来る場合もあります。 これらを考慮したトークンの扱いができるように、 JapaneseCompletionFilterというクラスが追加されています。 内部的にはKuromojiTokenizerでトークンに分割された後に、もともとのトークンと同じポジションで読みをローマ字にしたものを出力します。 JapaneseCompletionAnalyzerは上記Filterをすぐに使えるようにしたAnalyzerです。\n動かし方 百聞は一見に如かずということで、Elasticsearchでの使い方を見たほうが分かりやすいので、簡単に動かしてみることにします。\nインストールとインデックスの用意 Elasticsearch（8.1以上）とKuromojiのプラグインをインストールします（今回試したのは8.3.1）。\nサンプルデータ なにかいいデータはないものか？と思っていたところ夏休みだというのを思い出しました。 夏休みといえば読書感想文だ、ということで、書籍のタイトルがいいかもなと。 青空文庫の著者名と書籍のタイトルの一覧を見つけたのでそちらのデータを使って試してみました。\nCSV to JSON CSVファイルは最後の参考にある青空文庫のページから、「公開中　作家別作品一覧：全て(CSV形式、zip圧縮）」をダウンロードしたものを利用しました。 CSVファイルだったので、jqコマンドで必要な部分だけをNDJSONの形でとりあえずファイルに出力します。\ncat list_person_all_utf8.csv | tr -d \u0026#39;\u0026#34;\u0026#39; | jq -c -R \u0026#39;split(\u0026#34;,\u0026#34;) | {\u0026#34;auth_id\u0026#34;: .[0] | tonumber, \u0026#34;author\u0026#34;: .[1], \u0026#34;id\u0026#34;: .[2] , \u0026#34;title\u0026#34;: .[3], \u0026#34;suggest_ja\u0026#34;: [.[3], .[1]]}\u0026#39; 次のようなJSONが1行ずつ出力されます。\n{\u0026#34;auth_id\u0026#34;:1257,\u0026#34;author\u0026#34;:\u0026#34;アーヴィング ワシントン\u0026#34;,\u0026#34;id\u0026#34;:\u0026#34;056078\u0026#34;,\u0026#34;title\u0026#34;:\u0026#34;駅伝馬車\u0026#34;,\u0026#34;suggest_ja\u0026#34;:[\u0026#34;駅伝馬車\u0026#34;,\u0026#34;アーヴィング ワシントン\u0026#34;]} suggest_jaがオートコンプリートの対象となるデータになります。今回は著作と著者にしてみました。 あとは次に紹介するスキーマでインデックスを作成して、適当なプログラムを使ってBulkでElasticsearchに登録しましょう（私は個人作のツールで入れました）。\nインデックス オートコンプリート用のSuggesterを利用するための特殊なフィールド（completion）を利用したフィールドを用意します。 ちなみに、今回はLUCENE-10102に記載があった設定をそのまま使わせていただきました。 そのほかのフィールドは今回は特に必要はないのでおまけです。\nPUT aozora_index { \u0026#34;mappings\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;completion\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;japanese_completion_index\u0026#34;, \u0026#34;search_analyzer\u0026#34;: \u0026#34;japanese_completion_query\u0026#34;, \u0026#34;preserve_separators\u0026#34;: false, \u0026#34;preserve_position_increments\u0026#34;: true, \u0026#34;max_input_length\u0026#34;: 50 }, \u0026#34;auth_id\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;author\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;text\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;keyword\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;keyword\u0026#34;, \u0026#34;ignore_above\u0026#34;: 256 } }, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34; }, \u0026#34;author_id\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;integer\u0026#34; }, \u0026#34;id\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;integer\u0026#34; }, \u0026#34;title\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;text\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;keyword\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;keyword\u0026#34;, \u0026#34;ignore_above\u0026#34;: 256 } }, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34; } } }, \u0026#34;settings\u0026#34;: { \u0026#34;index\u0026#34;: { \u0026#34;number_of_shards\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;analysis\u0026#34;: { \u0026#34;analyzer\u0026#34;: { \u0026#34;japanese_completion_index\u0026#34;: { \u0026#34;mode\u0026#34;: \u0026#34;index\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;kuromoji_completion\u0026#34; }, \u0026#34;japanese_completion_query\u0026#34;: { \u0026#34;mode\u0026#34;: \u0026#34;query\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;kuromoji_completion\u0026#34; } } } } } } 動作確認 ここまでで、インデックスとデータの用意ができました。 オートコンプリートを実現するためにはElasticsearchのSuggesterという機能の、Completion Suggesterを利用します。検索の仕方が通常のものとは少し異なります。 ちなみに、速度重視のためにインメモリで動いているとの記載がドキュメントにあります。\nCompletion Suggesterのクエリ Suggester用のクエリがあるのでこちらを使います。 例えば、「wagah」という入力がある時に、サジェストする内容を取得するには次のようなリクエストになります。\nGET aozora_index/_search { \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;wagah\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } }, \u0026#34;_source\u0026#34;: [\u0026#34;title\u0026#34;, \u0026#34;author\u0026#34;] } 最初の「suggest」がsuggest用のパラメータを意味しています。 次の「title-suggest」は好きな名前をつけられます。レスポンスにこの名前がついた配列がサジェストの結果になります（同時に3. 複数suggestを呼び出せるので、対応した結果が分かるように名前が付けられます）。 「prefix」に入力の文字列を渡します。 「completion」がsuggesterのタイプの指定です。今回はCompletion Suggesterなので「completion」を指定します。その中に「field」でcompletionに利用するフィールド名を指定します。先ほどのスキーマでcompletionタイプを指定したフィールドです。今回は「suggest_ja」になります。 「_source」は結果を見やすくするために、ヒットしたデータの一部だけ取得するオプションです。 すると、次のような結果が返ってきます。\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;wagah\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 5, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;『吾輩は猫である』中篇自序\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;002671\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;『吾輩は猫である』中篇自序\u0026#34;, \u0026#34;夏目 漱石\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;わが俳諧修業\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;003771\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;わが俳諧修業\u0026#34;, \u0026#34;芥川 竜之介\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;わが母をおもう\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;003997\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;わが母をおもう\u0026#34;, \u0026#34;宮本 百合子\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;わが母を語る\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;049723\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;わが母を語る\u0026#34;, \u0026#34;上村 松園\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;吾輩は猫である\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;000789\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;吾輩は猫である\u0026#34;, \u0026#34;夏目 漱石\u0026#34; ] } } ] } ] } } 「suggest」の「title-suggest」がCompletion Suggesterのレスポンスになります。 最初の「text」は入力の「prefix」の値です。「offset」、「length」もこの文字に関する情報なので特に気にしなくてもいいかと。 「options」がサジェストされた内容になります。それぞれの「text」がサジェストされた文字列になります。「suggest_ja」には著作と著者名を入れましたが、今回は著作が「text」に帰ってきていることがわかります。 次に著者名でもやってみましょう。 「太宰」という入力が来たものとしてリクエストを投げます。\nGET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;太宰\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34; } } } } レスポンスは次のようになります。\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;太宰\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 2, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;000236\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;ア、秋\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;001572\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;I can speak\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;001578\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;愛と美について\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;046597\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;青森\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;004357\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;青森\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } } ] } ] } } 先ほどとは異なり、「options」の中の個々の「text」はすべて「太宰 治」になってしまいました。 登録したデータは著作の一覧ですが、「suggest_ja」には著作と著者名を入れたためです。 これでは、実際に検索窓に実装したときに同じものが並んでしまいます。 こんな時のためのオプション「skip_duplicates」が用意されています。 先ほどのリクエストに「\u0026ldquo;skip_duplicates\u0026rdquo;: true」を追加します。\nGET aozora_index/_search { \u0026#34;explain\u0026#34;: true, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: { \u0026#34;prefix\u0026#34;: \u0026#34;太宰\u0026#34;, \u0026#34;completion\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;suggest_ja\u0026#34;, \u0026#34;skip_duplicates\u0026#34;: true } } }, \u0026#34;_source\u0026#34;: [\u0026#34;suggest_ja\u0026#34;] } するとレスポンスは次のように変化します。\n{ \u0026#34;took\u0026#34;: 1, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;skipped\u0026#34;: 0, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: { \u0026#34;value\u0026#34;: 0, \u0026#34;relation\u0026#34;: \u0026#34;eq\u0026#34; }, \u0026#34;max_score\u0026#34;: null, \u0026#34;hits\u0026#34;: [] }, \u0026#34;suggest\u0026#34;: { \u0026#34;title-suggest\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;太宰\u0026#34;, \u0026#34;offset\u0026#34;: 0, \u0026#34;length\u0026#34;: 2, \u0026#34;options\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;太宰 治\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;000236\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;ア、秋\u0026#34;, \u0026#34;太宰 治\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰治との一日\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;042582\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;太宰治との一日\u0026#34;, \u0026#34;豊島 与志雄\u0026#34; ] } }, { \u0026#34;text\u0026#34;: \u0026#34;太宰治情死考\u0026#34;, \u0026#34;_index\u0026#34;: \u0026#34;aozora_index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;043137\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;suggest_ja\u0026#34;: [ \u0026#34;太宰治情死考\u0026#34;, \u0026#34;坂口 安吾\u0026#34; ] } } ] } ] } } 「options」は3つに減り、重複していないことがわかります。 「text」が同じ場合は最初に出てきたものを返すようです（注意：結果から観測しているだけで、実装はまだ見ていません）。 （なお、今回は説明を省きますが、入力データでスコアを指定することも可能になっています）。 そのほかにもCompletion Suggesterにはいくつか仕組みが用意されているのですが、それはまた今度にでも。\nまとめ ということで、Luceneコミッターの打田さんに感謝です。 便利な仕組みが簡単に使えるようになるのはとてもありがたいですね。\nまずは簡単にどういうものかとどうやって使うのかを記事にしてみました。 中の動きや、注意点、これまでとの違いなどは次の記事にしようと思います。 そういえば、公式ドキュメントにはまだ出てきてないな、それを書こうと思ってついでに動かしてみたんだけど、追加するのはまた後日かな。。。\n参考資料 青空文庫 - 公開中　作家リスト：全て ［LUCENE-10102］ Add JapaneseCompletionFilter for Input Method-aware auto-completion - ASF JIRA Expose Japanese completion filter to kuromoji analysis plugin by mocobeta · Pull Request #81858 · elastic/elasticsearch Suggesters | Elasticsearch Guide ［8.3］ | Elastic ","date":1660028402,"dir":"post/2022/","id":"6639ec6f88c4976f8ca20fa840f169e3","lang":"ja","lastmod":1660028402,"permalink":"https://blog.johtani.info/blog/2022/08/09/japanese-auto-completion/","publishdate":"2022-08-09T16:00:02+09:00","summary":"風のうわさで、日本語用のオートコンプリートのためのTokenFilterとAnalyzerがLuceneに取り込まれたと聞きました（LUCE","tags":["lucene","elasticsearch"],"title":"日本語用オートコンプリートのためのAnalyzer"},{"contents":"Hugoを0.84から0.92にアップデートをする際に、これまでのブログ記事やレイアウトファイルを修正したので個人的にメモを残しておきます。\nなんでアップデート？ うっかり魔がさして、メインのWSL2のUbuntuを20.04から22.04にアップグレードしました。。。 新規に22.04を落としてきて移行ではなく。 皆さんはまねしないほうがいいですよ！ アップデートした後にGitの環境がおかしくなったりと大変でした。 WSL2のUbuntuではHugoでブログのビルド、いろんな確認のためのElasticsearchの起動、個人的なプログラムとかを書く環境として利用しています。\nで、Ubuntuを上げたところ無事（？）Hugoもアップデートされたわけです。 最初はGitでfetchが出来なくなって修正していましたが、そのほかの動作確認を行なう段階でHugoでブログがビルドできなくなっていることが判明しました。\nバージョンアップに伴う修正 hugoコマンドを実行すると、いくつかのERRORとWARNが出力されました。 次のようなものです。\nhugo v0.92.2+extended linux/amd64 BuildDate=2022-02-23T16:47:50Z VendorInfo=ubuntu:0.92.2-1 ERROR 2022/08/05 13:22:32 Page.URL is deprecated and will be removed in Hugo 0.93.0. Use .Permalink or .RelPermalink. If what you want is the front matter URL value, use .Params.url WARN 2022/08/05 13:22:32 The \u0026#34;tweet\u0026#34; shortcode will soon require two named parameters: user and id. See \u0026#34;/home/johtani/blog_generator/content/post/2020/2020-12-04-build_corne_choc.md:46:1\u0026#34; ... ERROR 2022/08/05 13:22:33 Failed to get JSON resource \u0026#34;https://publish.twitter.com/oembed?dnt=fa... If you feel that this should not be logged as an ERROR, you can ignore it by adding this to your site config: ignoreErrors = [\u0026#34;error-remote-getjson\u0026#34;] ERROR 2022/08/05 18:44:11 Page.UniqueID is deprecated and will be removed in Hugo 0.93.0. Use .File.UniqueID ERROR 2022/08/05 18:44:11 Page.Dir is deprecated and will be removed in Hugo 0.93.0. Use .File.Dir Page.URLなどがdeprecatedに 最初と最後2行のERRORがこちらになります。 どうやら、Pageオブジェクトの変数に変更があったようです（まだdeprecatedであり、存在はしていそう？）。 レイアウト（テンプレート）ファイルで「Previous Post」や「Next Post」といったリンクを作ったり、 Algoliaに登録するためのJSONファイルを生成するところでURL文字列を取得するために参照していました。\nログ出力でどのように変更すればよいのか？という記載があるので便利ですね。 ただ、どのファイルにこの記述があるのかはログに出てなかったので少しだけ苦労しました。\n実際には「UniqueID」という文字列でディレクトリ内を検索してあたりを付けた感じです。 利用させていただいているテーマ（Clean White）がすでにアップデートに対応されていたのでそちらが参考になりました。\nいくつか、テーマをもとに修正したテンプレートがlayoutsディレクトリにあったので、それらを修正した形です（参考のリンクはテーマのファイルになります）。\n.URLを.Permalinkに変更（参考：single.html） .UniqueIDを.File.UniqueIDに変更（参考：list.algolia.json） tweetのshortcodeの引数が増えた これまでは以下のようにIDだけで良かったのですが、userとidという2つの引数が必須になるという変更が入ったようです。\n変更前：\n{{ \u0026lt;tweet 1449214872143609860\u0026gt; }} 変更後：\n{{ \u0026lt;tweet user=\u0026#34;johtani\u0026#34; id=\u0026#34;1449214872143609860\u0026#34;\u0026gt; }} WARNにはファイル名、行番号が出力されていたので、1つずつ修正していきました。 結構な量があったので、地味に大変でした、 公開しているブログを見ながら、該当するツイートを見つけてはuserを指定していく部分が特に。 自分のツイート以外もブログに貼っていたので画一的には対処できなくて。。。\nなにかプログラムで機械的に対応ができたかもなぁ。\n鍵付きツイートによるエラー tweetのshortcode対応を行なった後でもビルドがエラーになっており、次のようなエラーが消えないままでした（エラーの一部は省略しています）。 （幸いにも）1つのツイートだけ、ブログ記事を書いた後で鍵付きになってしまった方のツイートがあったようで、ツイート用のJSONが取得できなくてエラーになっていました。\nERROR 2022/08/05 13:22:33 Failed to get JSON resource \u0026#34;https://publish.twitter.com/oembed?dnt=fa... If you feel that this should not be logged as an ERROR, you can ignore it by adding this to your site config: ignoreErrors = [\u0026#34;error-remote-getjson\u0026#34;] こちらもログに対処方法が出ています。 config.tomlにignoreErrors = [\u0026quot;error-remote-getjson\u0026quot;]を追加すれば、エラーが出力されなくなりビルドも成功するようになります。 ただ、tweet以外でもエラーが出る可能性がありそうで、その場合に、ブログに書いたつもりが一部が出力されないまま公開されそうな気がします。 なので、今回はconfig.tomlに該当の設定を追加するのではなく、ブログ記事から該当のツイートを消す対応をしました。 幸いにも、ツイートを消してもブログ記事自体には影響がありませんでした。\n.hugo_build.lockファイルが生成される これは、エラーではないのですがgit addしようとした際に、ファイルが増えていたのでどういったファイルなのかを調べました。 0.89.0から追加されたロックファイルのようです（参考：0.89.0のリリースノート）。 こちらは特に保管する必要もなさそうなので.gitignoreに追加して対処しました。\nまとめ ということで、気軽にUbuntuをアップグレードしないほうがいいですね。。。 期せずしてHugoのアップグレードができたのは良かったかもなｗ\n参考 【WSL2】Ubuntu 20.04.4 LTS を 22.04 LTS へアップグレードした ","date":1659689954,"dir":"post/2022/","id":"167a7c9d579ce6f2cebf64a6f6329ecb","lang":"ja","lastmod":1659689954,"permalink":"https://blog.johtani.info/blog/2022/08/05/upgrade-hugo-accidentally/","publishdate":"2022-08-05T17:59:14+09:00","summary":"Hugoを0.84から0.92にアップデートをする際に、これまでのブログ記事やレイアウトファイルを修正したので個人的にメモを残しておきます。","tags":["hugo"],"title":"Hugoをアップデートした"},{"contents":"今回はQuerqyのElasticsearchのプラグインがどんなつくりになっているか？をちょっとだけ調べてみました。 SolrでもElasticsearchでも使えるという形なので、どんなつくりになっているのかな？と思ったのが発端です。\nGitHubのリポジトリ GitHubにリポジトリが公開されています。 2つのリポジトリに分かれています。\nEs向けのプラグイン コアのライブラリ どちらもJavaのライブラリで、ビルドシステムとしてはMavenを利用しています。 コアのライブラリのリポジトリにはさらに、以下の2つが存在しています。\nlucene向けライブラリ（Solr向けのモジュールもこちらに含まれる） コアライブラリ pom.xmlを読んだところ、次のような依存関係になっています（それ以外にも使ってるライブラリはあるけど）。\nEsプラグイン -\u0026gt; Lucene向けライブラリ -\u0026gt; コアライブラリ Esプラグイン Es向けのエンドポイントの実装、Esのクエリの組み立てを行なっています。 Rewriterの実装については、Lucene向けライブラリ、コアライブラリを利用する形になります。\nquerqy用のQueryBuilderを実装しており、EsがクエリをパースするタイミングでRewriterなどを呼び出してクエリの書き換えを行う仕組みです。 なお、Es向けのクエリの組み立てと書きましたが、ほとんどLuceneのクエリの組み立てになっています（そりゃそうだ）。 実際にquerqyのクエリ組み立て処理を行っているのは、Lucene向けライブラリのQueryParsingControllerになります。 いくつかのRewriterは、生のEsクエリをルールなどとして登録することができるようになっています。 これらのクエリのパースをEs側にやらせる処理の部分もこちらで定義されている感じです。\nそのほかに、ドキュメントには記載がないエンドポイントが2つ用意されていました。 インデックスに登録してあるRewriterの設定を各ノードでキャッシュする仕組みがあって、そのキャッシュの操作（クリア、リロード）用みたいです。 これらは、Rewriterの追加、削除のアクションの内部で呼び出されているので、ユーザー側で呼び出す必要はなさそうです。\nLucene向けライブラリ Luceneに関連する処理がまとめられています。 Es内部ではLuceneを使って検索処理が行なわれるため、Luceneのクエリを組み立てる必要があります。 querqyとしてLuceneのクエリを組み立てるときに必要なクラスがこのライブラリに含まれています。\nまた、Word Break Rewriterの実装はコアライブラリではなくこちらのライブラリに実装されています。 これは、Luceneのタームディクショナリを活用したRewriterになっているため、Lucene必須となっているからのようです。 （まだちゃんと実装を見ていないので、どんな活用の仕方をしているのかまではわかっていませんが。。。）\nコアライブラリ Rewriterの設定のパース処理、クエリのリライト処理の実装がまとめられています。 querqyのクエリが、Rewriterの処理に基づいて、querqyとして定義されたクエリのモデルに一旦変換される作りになっています。 Lucene向けライブラリやEs向けプラグインはこの内部のクエリモデルになったものをもとに、Lucene向けのクエリに書き換えていくというながれになっています。\nまとめ ざっくりですが、どんな構成なのかを見てみました。 Esのプラグインとなっているのですが、プラグインではなく、外部に出すことってできるのかな？と思いつつ、なんとなくソースを読んでみました。 パターンとしては、Lucene向けのクエリからEs向けのクエリを組み立てるとかの無駄な努力が必要になる気もするけど。。。 Luceneを使っていない検索エンジンに対しては、コアライブラリをもとに、それぞれの検索エンジンむけのクエリを組み立てる仕組みを作る形になると思います。 その際、Rewriterの設定を保持する仕組み、querqyが置き換えたクエリのマッピングができるか？といった点を考える必要がありそうです。 デバッグとかするときに、EsのクエリDSLのJSONとして見れるといいなぁと思ってたけど、そんなことできるかなぁ？\n","date":1658300650,"dir":"post/2022/","id":"3384ea6bb47d70f8ca94b4510813f36a","lang":"ja","lastmod":1658300650,"permalink":"https://blog.johtani.info/blog/2022/07/20/querqy-architecture/","publishdate":"2022-07-20T16:04:10+09:00","summary":"今回はQuerqyのElasticsearchのプラグインがどんなつくりになっているか？をちょっとだけ調べてみました。 SolrでもElast","tags":["elasticsearch"],"title":"Querqyの調査（その2：アーキテクチャ）"},{"contents":"Querqyというクエリのリライト用のプラグインがあるのでどんなものかを調べてみました。とりあえずは概要をドキュメントから追いかけてみた感じです。対応しているのはSolrとElasticsearch（以降、Es）になります。手元にはEsの環境があるのでそちらで試してみました。\nなにもの？ EsやSolrのプラグインで、ルールやパラメータを利用して、クエリの書き換えをEsやSolr側で行えるプラグインです。 なお、本記事ではEsのプラグインを説明します。 今回はドキュメントを読みながらメモを取った感じなので、詳細については公式ドキュメントを見ていただくのが良いかと。 手元では動作させてみましたが、今回の記事ではざっとメモを取っただけになります。\nインストール Esのpluginコマンドでインストール可能ですが、Mavenにアップロードされているバージョンは限定的なので、必要に応じて自分でビルドする必要があります。 対応しているかは、公式ドキュメントのInstallationのプルダウンが参考になります。\nどうやって使うの？ Query DSLにquerqyというクエリが追加されるので、あとはドキュメントをもとにクエリを組み立てるクエリを書いていきます。 すると、プラグインが指定されたルールに従い、EsのQueryに書き換え、実際の検索が実行して結果が返ってきます。 普通にmatchなどの既存のQueryと同レベルのものになるので、既存のEsのクエリと組み合わせた使い方もできるようです。\nサンプルとして紹介されている短めのクエリ（このクエリではルールによるクエリの書き換えはない）。\nGET ecommerce/_search { \u0026#34;query\u0026#34;: { \u0026#34;querqy\u0026#34;: { \u0026#34;matching_query\u0026#34;: { \u0026#34;query\u0026#34;: \u0026#34;notebook\u0026#34; }, \u0026#34;query_fields\u0026#34;: [ \u0026#34;title^3.0\u0026#34;, \u0026#34;brand^2.1\u0026#34;, \u0026#34;short_description\u0026#34;] } } } また、書き換え（Rewriter）の設定をElasticsearchに対して保存できるエンドポイント_querqy/rewriterが用意されています。\nSynonymの書き換えを行なうサンプル（後述するCommon Rules Rewriterの設定）。\nPUT /_querqy/rewriter/common_rules { \u0026#34;class\u0026#34;: \u0026#34;querqy.elasticsearch.rewriter.SimpleCommonRulesRewriterFactory\u0026#34;, \u0026#34;config\u0026#34;: { \u0026#34;rules\u0026#34; : \u0026#34;notebook =\u0026gt;\\nSYNONYM: laptop\u0026#34; } } どんな書き換えができるの？ 用意されているRewriterは2022年7月時点では次のようなものになります（がんばれば、Javaで実装すれば自作もできそう）。\nCommon Rules Rewriter Replace Rewriter Number Unit Rewriter Word Break Rewriter また、複数のRewriterをチェインして使うこともできる。記述した順番で適用されます。 それぞれのRewriterについて簡単にメモを。\nCommon Rules Rewriter シノニム、結果のブースト、フィルター、結果に対して追加情報を付与したりできます。\nrulesにルールを記載していきます。 以下のようなフォーマットになっています。 クエリが入力に合致したら、ルールが適用される形です。プロパティは後述しますが、ルールの適用する順序などをハンドリングするために使用します。\n入力 =\u0026gt; ルール ルール @プロパティ @プロパティ 入力部分に関する書式 ルールの左辺に該当する部分で、クエリに入力された文字列がマッチするかどうかで、右辺のルールを適用するかがきまります。\n入力の一致の条件は次のような感じです。 完全一致、前方一致、後方一致の使い分けが可能。ダブルクォート\u0026quot;で制御 デフォルトでは、大文字小文字の区別なし（後述するオプションで変更可能） 単語の末尾にワイルドカード*で1文字以上にマッチ。入力の最後にだけ利用可能 書き換えの命令（ルール） 右辺に利用できる命令で、次のようなものがあります。\nSYNONYM 同義語展開するための命令です。Synonym Token Filterとの違いは、複数のルールを同時に適用できます。 フィールドに依存しない設定なのでメンテナンスが楽になるとのこと。 ただし、双方向の設定はないため、例えば\u0026quot;personal computer\u0026quot;と\u0026quot;pc\u0026quot;の場合、2つの設定を個別に定義する必要があります。 また、ステミングなどには未対応なので、\u0026ldquo;personal computers\u0026quot;も対応する場合はこれも追加する必要があります。 類義語ごとに重みを変えることが可能になっています。同列ではなく、同義語のスコアを下げるなどで、リコールを増加させつつ、入力語のスコアを上位にすると行ったことが可能です。\nUP/DOWN 入力文字列がマッチした場合に、追加のクエリを正か負のブーストをしつつ追加できます。 例えば、「iphone」と検索された場合に、「apple」もクエリとして追加しつつスコアをブーストし、「case」のクエリをスコアを下げるように追加できます。 これにより、アクセサリーではなく本体が検索結果の上位に出てくるような仕組みを提供できます。\nFILTER UP/DOWNではクエリとして追加されていたが、こちらはフィルターとして追加されます（＝スコアで調整ではなく、結果から除外される）。\nDELETE クエリからキーワードを削除できます。 単語自体をそのまま削除することも、入力された単語に合わせて他の単語を削除することもできます。\nDECORATE 2022年7月時点でEsでは利用不可で、Solrのみで利用可能です（なので読み飛ばしました）。\nプロパティ 各ルールの設定にタグをつけられるような機能です。 このプロパティを利用して、ルールのソートやフィルタリングなどが可能になります。 複数のルールにクエリがマッチした場合に、優先度が最高のものだけを適用したり、プロパティに特定の値を持っているものだけを採用したりできます。 なお、プロパティは命令のあとに記述する必要があります（パーサーの関係かな？）。\nReplace Rewriter クエリタームの置き換え用のRewriterです。クエリの正規化処理として、他のRewriterの前処理に利用したりできます。 サンプルではタイポの修正などに利用したり、不要な語の除去などがあげてありました。\nWord Break Rewriter クエリトークンを分解・結合します。 たとえばドイツ語は、複合語と呼ばれる個別の意味の単語を結合した1つの単語を持っているため、個別の意味に分解して検索すると便利なことがあります。 そういった単語を辞書を基にして分割できるようにする機能です。 辞書とは実際のインデックスのタームディクショナリのことと思われます（要調査。どのインデックスのフィールドを指し示すのかなど、設定とドキュメントではよくわからない）。 なお、利用可能な形態素解析を基にした実装はドイツ語のみとなっており、また、分解の時には形態素解析を考慮しますが結合時には考慮しません。\nNumber-Unit Rewriter クエリの数値と単位を判別し、対象となるフィールドにマッチさせます。範囲での一致や完全一致やブーストが可能です。 単位をもとにして、特定のフィールドに対する数値のクエリに書き換えることができます。\nShingle Rewriter Solrのみで利用可能なので読み飛ばしました。\nルールはどこに保存されるの？ .querqyというインデックスが内部で作成され、そこに保存されます（公式ドキュメントより）。 （ちなみに、Mappingはこんな感じみたいです）。 現状、プラグインでは設定したRewriterの取得ができないようなので、自分で登録した設定がどんなものかは、このインデックスを検索する必要がありそうです。\n気になった点・改善点？ 気になった点があったので。\nRewriterのエンドポイントは、登録・更新・削除のみ対応しており、登録したものの確認は直接インデックスを見に行くしかなさそうです（Issueは作られてた）。 [要検証]書き換えられたクエリがどんなものか？は残念ながら確認できなそうで、_validate/queryで最終的なLuceneレベルのクエリで確認するしかなさそう？ スキーマ側で定義したものと、Querqyで定義したものの兼ね合いがどういう形になるのか？などを気にする必要があるのが注意点かも。組み合わせたときの副作用などがどんなことになりそうか？が予測がつきにくそう。 Rewriterの定義自体のテストはどうしたものか？ まとめ とりあえず、ざっとドキュメントを見ながらメモを取った感じです。 設定などの記述が独自のものなので、そこに慣れていく必要がありそうです（特にルールの改行の部分とか）。 次は実際にどんな感じで使えそうか、既存の仕組みとの違いは？みたいなところをもう少し見ていきたいとおもいます。\n参考文献 querqy/querqy： Query preprocessor for Java-based search engines (Querqy Core and Solr implementation) Getting started with Querqy — querqy.org documentation ","date":1658285563,"dir":"post/2022/","id":"779e444b4bc720a9eed97f19c41e8773","lang":"ja","lastmod":1658285563,"permalink":"https://blog.johtani.info/blog/2022/07/20/intro-querqy/","publishdate":"2022-07-20T11:52:43+09:00","summary":"Querqyというクエリのリライト用のプラグインがあるのでどんなものかを調べてみました。とりあえずは概要をドキュメントから追いかけてみた感じ","tags":["elasticsearch"],"title":"Querqyの調査（その１）"},{"contents":"今年もBerlin Buzzwordsにオンライン出張してました。 今年はハイブリッドな開催だったようで、現地で再開している人もいるようでした。 ブースもあったみたいです。ちなみに、現地で参加する人はマスク必須のようでした（Health \u0026amp; Safetyというページが用意されていました）。 昨年オンラインだったMICESは現地のみでの開催みたいで見ることはできなかったです（録画公開されないかなぁ）。\nさて、いくつか見たセッションで面白かったものがあったので簡単にメモを。 すでにセッションのビデオがYouTubeで公開されているので、興味のある方は見てみてください。\n面白かったセッション The future of Lucene\u0026rsquo;s MMapDirectory: Why use it and what\u0026rsquo;s coming with Java 19 and later? セッションページ： The future of Lucene\u0026rsquo;s MMapDirectory： Why use it and what\u0026rsquo;s coming with Java 19 and later? ：： Berlin Buzzwords 2022 動画：Uwe Schindler – The future of Lucene\u0026rsquo;s MMapDirectory： Why use it \u0026amp; what\u0026rsquo;s coming with Java19 \u0026amp; later - YouTube 毎年恒例になってる気も？ 前半は昨年も話をした内容で、後半はJava 19がリリースされたら、Previewという形でフラグを立てて使えるようになるようです。 使えるようにするから、テストしてみて！という感じで終わっていますｗ\nScaling an online search engine to thousands of physical stores セッションページ：Scaling an online search engine to thousands of physical stores ：： Berlin Buzzwords 2022 ：： pretalx 動画：Aline Paponaud – Scaling an online search engine to thousands of physical stores - YouTube 数千の実店舗の商品をオンラインで検索できるようにしつつ、オンラインのマーケットプレイスのような検索も一緒にできるようにしたというお話でした。 インデックスの構成をどう工夫したのか？とかどういうクラスター構成にして、どんなことをモニタリングしてるよ？というお話です。 実際の店舗がどんなものかなどは出てこなかったので、少しイメージは沸きにくかったのですが、どんなことを考えながらインデックスの構成とか考慮したよという話はおもしろかったです。 実際に検索したときに、実店舗のデータがどんな感じで結果として表示されたりするのか？といった点はわからなかったので、そのあたりの話をもうちょっと聞いてみたかったなぁ。\nOffline Ranking Validation - Predicting A/B Test Results セッションページ：Offline Ranking Validation - Predicting A/B Test Results ：： Berlin Buzzwords 2022 ：： pretalx 動画：Andrea Schütt \u0026amp; Yunus Lutz – Offline Ranking Validation - Predicting A/B Test Results - YouTube otto.deというECサイトでのランキングをどうやって改善していくか？という話。 現在はマニュアルなチューニングをコンテキストごとにやっているけど、リクエスト量とかデータとかが増えてきてて、このままマニュアルで改善していくのも大変なので、 モデルベースのランキングを開発できないか？というのをはじめていますよと。 そのために、これまでのデータから、A/Bテストの結果を予測できるモデルが作れないか？というのをやっていますという話。 いくつかわからない単語も出てきたので、誰か詳しい人教えて！\nAI-powered Semantic Search; A story of broken promises? セッションページ：AI-powered Semantic Search; A story of broken promises? ：： Berlin Buzzwords 2022 ：： pretalx 動画：Jo Kristian Bergum – AI-powered Semantic Search; A story of broken promises? - YouTube Vespaの開発にかかわってる方の、Semantic Searchに関する話。 Semantic Searchが流行り始めていて、どうやればできるのか？という話が出てきています。 けど、どういうものでどういう点に気を付けたほうがいい？という話でした。 LtRってこんなもの、そのあとに出てきたLLM（Large Language Model）でどうやって検索の改善に使えるの？というのが分かりやすく説明されていました。 それらの説明の後、BEIRという論文を紹介しつつ、LLMを使うときの注意点の話がありました。\nBERTとかをちょっと勉強してたのもあり、なんとなくそうだよなぁと思っていた結論と同じ結論が出てきたので面白いと感じました。 BEIRの論文は時間を見つけて読んでみないとな。\nHybrid search \u0026gt; sum of its parts? セッションページ： Hybrid search \u0026gt; sum of its parts? ：： Berlin Buzzwords 2022 ：： pretalx 動画：Lester Solbakken – Hybrid search： Greater than the sum of its parts? - YouTube こちらもVespaの人の話。 先ほどのSemantic Searchの話では、Semantic Searchがどんなものか？という話でした。 が、それだけで検索ができるわけでもないので、キーワードサーチとSemantic Searchの両方をうまく活用するには？というのがこのセッションでした。 最終的にはVespaを使うとうまくハイブリッドできるよという話ですが、考え方は参考になるかなと。 Vespaも触ってみたいなぁ。\nThe life of a search engine administrator セッションページ：The life of a search engine administrator ：： Berlin Buzzwords 2022 ：： pretalx 動画：Lucian Precup \u0026amp; Vincent Bréhin – The life of a search engine administrator - YouTube 検索システムの管理者ってどんなことやるの？それにはどんなことができるツールがあるといいの？という話です。 まぁ、ツールについてはこの会社の人たちのツールの宣伝なのですが、検索システムを作って育てていくのにどんなことを考えたりするのか？という参考になるかなぁと。\nShould we stop using distance in our location-based data recommendation models? セッションページ：Should we stop using distance in our location-based data recommendation models? ：： Berlin Buzzwords 2022 ：： pretalx 動画：Charlie Davies – Should we stop using distance in our location-based data recommendation models? - YouTube TravelTimeという会社を立ち上げた人の話。 位置に関する情報って重要だし、検索するときに利用しますよね？例えば、ホテル決めたりとか、仕事探したりするときに。 ということで、位置情報を検索エンジンで利用する方法（Bounding Box、ポリゴン、距離）をまず紹介して、どんなユースケースで使えるかという話があります。 また、それとは別に検索速度（いかに検索を速く返すか）も重要だという話があります（ウォルマートはページロード時間を1秒早くしてコンバージョンが2%あがったとか）。 で、実際に検索結果に距離とかでるけど、実際に知りたいのはどのくらいの時間で行けるのか？という話だったりしませんか？と。 公共交通機関を使ったりする場合に、実際に45分で移動できる距離というのは半径5マイルとかできまるものではないのに、単純に位置情報を利用した距離だけでソートしていいの？という問いかけから、 その辺を考慮した検索ができるAPIを開発しているよ、検索速度もはやいよというお話でした。 残念ながら具体的にどうやって作っているのか？というのはなかったですが、観点がおもしろかったです。\nWord2Vec model to generate synonyms on the fly in Apache Lucene セッションページ：Word2Vec model to generate synonyms on the fly in Apache Lucene ：： Berlin Buzzwords 2022 ：： pretalx 動画：Daniele Antuzi \u0026amp; Ilaria Petreti – Word2Vec model to generate synonyms on the fly in Apache Lucene - YouTube Word2Vecのモデルを使った、Apache LuceneのSynonym Filterを開発中だよという話 DeepLearning4Jを使ってみたが、遅くて使えなかったんだけど、最近Luceneに入ったkNNを使うことでそれなりの速度で使えそうなものができるかもよ？って感じでした。 モデル学習用のツールも作ってて、イタリア語のWikipediaで学習したものでちょっと動かしたらそれっぽい感じになってるという話でした。 まだ途中でいくつかやりたいことがあるという話で、実用はまだ先のようでした。例えば、1単語のSynonymにしか対応してないとか、モデルをインメモリでしか動かせないとか。\nQAでも出たのですが、Word2Vecだと対義語も類似していると判定されてしまうと思うので、その辺がどうなっているのかなぁ？という疑問があります。 ルールベースの類義語ではないので、調整するのはどうやるのかなぁ、学習用のコーパスをいい感じにするとかなのかな？とか、気になるところです。\nNrtSearch: Yelp’s fast, scalable, and cost-effective open source search engine セッションページ：NrtSearch： Yelp’s fast, scalable, and cost-effective open source search engine ：： Berlin Buzzwords 2022 ：： pretalx 動画：Umesh Dangat – NrtSearch： Yelp’s fast, scalable, and cost-effective open source search engine - YouTube YelpがLuceneベースで開発をしているNrtSearchというOSSの話です。 Elasticsearchを使っていたんだけど、どういった点が問題点になってどういうモチベーションでNrtSearchを開発したのか？を説明しています。 アーキテクチャがどんなもので、実際に動かしてみてどんな利点があって、どんな点が問題として出てきているか、将来どんなことをやろうとしているかがわかります。 QAでもいろんな質問が出ていて面白いです。\nまとめ ということで、簡単でしたがセッションの感想でした。 Neural/Semantic Searchというのがセッションのタイトルなどに入っているのが多くなってるなぁという感想です（ちょっとやってみたい気はしてるんだよなぁ）。 すでにYouTubeに動画が公開されているので興味があるセッションを見つけてみてください。 Berlin Buzzwordsの次の日に開催されたMICESも観てみたかったですが、オンラインでも参加できる形式で海外のカンファレンスが開催されるのはとても助かりますね（ヨーロッパだと時差もそれほど大変じゃないし）。 けど、落ち着いたらまたオフラインで参加してみたいなぁ。\n","date":1655283615,"dir":"post/2022/","id":"f56c19442484b3e4f47875b58b3f72b2","lang":"ja","lastmod":1655283615,"permalink":"https://blog.johtani.info/blog/2022/06/15/ttend-berlin-buzzwords-online/","publishdate":"2022-06-15T18:00:15+09:00","summary":"今年もBerlin Buzzwordsにオンライン出張してました。 今年はハイブリッドな開催だったようで、現地で再開している人もいるようでした。","tags":["conference","berlin buzzwords"],"title":"今年もオンラインでBerlin Buzzwordsに参加した"},{"contents":"7.16で正式リリースされましたが、Elasticsearchの新しいJavaのクライアントが出ています。 使ってみたので、ちょっとだけ紹介でもしてみようかな。\nこのクライアントが出るまでは、ElasticsearchのJavaクライアント（REST版）はElasticsearch本体の一部として実装・管理されていました（Elasticsearchのリポジトリにあるclientディレクトリ）。\nHTTP経由でElasticsearchにアクセスするクライアントだったのですが、Elasticsearch本体のリポジトリで管理されていることもあり、Elasticsearch本体で利用されているクラスを使用していました。 このため、クライアントライブラリなのですが、Elasticsearch本体のJarが必要になりサイズが大きくなっていました。 また、JavaのObjectへの詰め替えなどの機能も備えておらず、すこし古臭い感じでもあります。 この辺りを刷新する目的もあり新しいクライアントが公開されたようです。 3月くらいに触った時はまだ、ドキュメントが揃ってなかったのですが利用方法などが増えているので移行も楽になってきているようです。 根本的に作り直されたため、これまでのREST Clientとは使い方が違います。ですので、jarだけの差し替えでこれまで動いていたプログラムを移行ができるわけではないので注意が必要です。\nどの辺が便利？ 順次移行が可能 これまでのRESTクライアントとはパッケージ名もjarも別モノになっています。 ですので、少しずつ新しいJava Clientに切り替えていくことが可能になっています。 根本的に使い方が変わっているので、大きなシステムのクライアントを全部切り替えるのは結構大変かと思います。 ですので、Indexをしている部分だけとか、検索部分だけなどといった部分的な置き換えをしつつ新しいクライアントに慣れていくことができます。\nラムダっぽく書ける 検索のクエリのサンプルを見るとわかりますが、こんな感じでクエリが書けます(公式ドキュメントより抜粋)。\nSearchResponse\u0026lt;Product\u0026gt; response = esClient.search(s -\u0026gt; s .index(\u0026#34;products\u0026#34;) .query(q -\u0026gt; q .match(t -\u0026gt; t .field(\u0026#34;name\u0026#34;) .query(searchText) ) ), Product.class ); また、最後で渡しているProduct.classは、検索結果をどのクラスのインスタンスにして返すかの指定です。 Elasticsearchのレスポンス（JSON）から値をコピーして返してくれるようになっています。 ですので、値を入れ替える処理を書く必要がなくなっています。\nJSON文字列をそのまま使える 触り始めてからリリース（7.17.2より後なら使える）された、JSON文字列からリクエストを作る機能もあります。\nこれまでのREST Clientだと、Elasticsearchへのリクエストを必ずJavaのメソッドで構築する必要がありました。 今回のこの機能を利用すると、JSON文字列（やファイル）からリクエストオブジェクトを作るためのメソッド.withJson()が提供されています。 例えば、スキーマや設定変更用のリクエストのJSONなどは、Kibanaやcurlから試験的に投げたリクエスト（JSON）と同じものを使いたいことが多いです。また、ElasticsearchのAPIは数が多く、ドキュメントを見ながら利用方法を調べてJSONでまず試行錯誤することが多いです。 このwithJsonメソッドを利用することで、動作確認などをしたJSONがそのままソースにも利用できるので、リクエスト変更時の確認なども容易になると思います。\n使ってみて困ったのは？ 便利な面も多いのですが、使っていて少し困ったこともあったのでそれもメモを残しておきます。\nどんなリクエストを投げているかが不明 先ほども書きましたが、Elasticsearchのリクエストを試行錯誤するときは公式ドキュメントを見ながら、Kibanaなどを利用して試すことが多いです。 ですので、自分がやりたいことのJSONは手元にあることが多いです。 ただ、プログラムでクエリを組み立てる必要も出てきます。この時、実際にRESTリクエストとしてどんなJSONを投げているのかを知りたいことがあります（実際、検索クエリ作っててメソッドの使い方がうまくいかなくて四苦八苦してました）。 4月時点では簡単にリクエストで投げているJSONを文字列としてログに出すメソッドなどは用意されていないようでした。 デバッグ用に次のようなメソッドを書いてみました。 Elasticsearchへ投げるRequestのクラス（例：CreateTemplateRequestとか）を引数に渡すことで、JSON文字列に変換できるようになっています（StringWriterに書き出されてる）。 ここのLoggerはサンプルです。writer.toString()で取り出せる文字列がJSON文字列になっているので、ログに出してみるなり、ファイルに落とすなりしてデバッグのお供にしてください。\nimport java.io.StringWriter; import co.elastic.clients.elasticsearch._types.RequestBase; import co.elastic.clients.json.SimpleJsonpMapper; import jakarta.json.stream.JsonGenerator; ... private void printRequestBodyJsonForDebug(RequestBase request) { //for debug Logger.log(\u0026#34;** Debug print start **\u0026#34;); StringWriter writer = new StringWriter(); SimpleJsonpMapper mapper = new SimpleJsonpMapper(); JsonGenerator generator = mapper.jsonProvider().createGenerator(writer); mapper.serialize(request, generator); generator.close(); Logger.log(writer.toString()); Logger.log(\u0026#34;** Debug print finish **\u0026#34;); } プラグインなどで提供されるクエリが書けない LtRプラグインなどは、Elasticsearchの検索クエリを拡張しています。 残念ながら、現時点（2022/06/13）ではカスタムクエリを新しいJavaクライアントで利用しようとした場合、エラーが発生してしまいます（知らないJSONだと判断されてしまいます）。\nGitHubのIssueとして「［roadmap］ Add support for plugin-defined custom components · Issue #252 · elastic/elasticsearch-java」があります。 これに対応されたら、拡張されたクエリも利用できるようになるでしょう。 プラグインなどで拡張されているものを使いたい場合は、残念ながら既存のRESTクライアントを当面は使うことになりそうです。\nまとめ 新しいElasticsearchのJavaクライアントを簡単ですが触ってみて、気になった点を記事にしました。 JavaのObjectに詰め替えてくれる機能など便利になっているので使ってみてください。 ドキュメントもちょっとずつ増えているようで、使い方も分かりやすくなっていました（触った時はレスポンスの扱い方などがJavaDocしか用意されてなかったんです）。 説明が欲しいなぁと思うことがあれば、GitHubにIssueを上げてみるといいかもです。\n参考 公式ドキュメント Java Clientチームの人がカンファレンスで利用したスライド ","date":1655119446,"dir":"post/2022/","id":"5eebdf85fd1726db301194bfeeee4377","lang":"ja","lastmod":1655119446,"permalink":"https://blog.johtani.info/blog/2022/06/13/new-elasticsearch-java-client/","publishdate":"2022-06-13T20:24:06+09:00","summary":"7.16で正式リリースされましたが、Elasticsearchの新しいJavaのクライアントが出ています。 使ってみたので、ちょっとだけ紹介で","tags":["elasticsearch","java"],"title":"Elasticsearchの新しいJavaクライアント"},{"contents":"Azure Cognitive Searchで2月に新しい機能が公開されました。 「Index Alias」（インデックスの別名）です。まだ、パブリックプレビューの段階ですが、ドキュメントなどが公開されていたのでどんな機能かを調べてみました。なお、本ブログの内容は2022/05/18時点での内容となります、ご注意ください。\n公式ドキュメント まずは公式ドキュメントです。1つ目の「インデックスの別名を作成する」の冒頭で別名（エイリアス）がどんなものかを説明しています。\nインデックスの別名を作成する - Azure Cognitive Search | Microsoft Docs エイリアスの作成または更新 (2021-04-30-Preview) - Azure Cognitive Search | Microsoft Docs Alias Operations (2021-04-30-Preview) - Azure Cognitive Search | Microsoft Docs REST APIのドキュメント（2022/05/18現在、日本語のページだと左のメニューが壊れているため、どんなAPIがあるかがわかりにくいため、Alias Operationsのページは英語のリンクになっています）\nインデックスエイリアスってどんなもの？ 文字通り、インデックスにエイリアス（別名）をつけることができるようになります。 Azure Cognitive Searchでは残念ながらインデックスを作成するタイミング以外ではインデックスの名前を変更できません。 このため、インデックスのスキーマ（Analyzerの設定変更など）を変更したい場合、新しいインデックスを作成します。 新しいインデックスの名前はこれまでのものとは別の名前になってしまうため、アプリケーションで指定しているインデックス名も書き換える必要が出てきます。 利用しているアプリが複数ある場合は、すべて変更が必要です。\n今回出てきたエイリアスを利用することで、アプリケーションではエイリアスを指定することで、アプリケーション側の変更なくインデックスを入れ替えることができるようになります。\nエイリアスの操作方法 公式ドキュメントにAPIの一覧や利用方法の記載があるので詳細はそちらをご覧ください。 本ブログでは、いくつか利用するときに気になった点を書き残しておきます。\n作成 aliasesというエンドポイントにエイリアスの名前とインデックス名をPOSTすることで作成できます。 以下のサンプルは公式ドキュメントの例です。\nPOST /aliases?api-version=2021-04-30-preview { \u0026#34;name\u0026#34;: \u0026#34;my-alias\u0026#34;, \u0026#34;indexes\u0026#34;: [\u0026#34;hotel-samples-index\u0026#34;] } ちなみに、インデックスの指定がindexesで配列になっていますが、公式ドキュメントに以下の記述があり、複数の指定はできないです（エラーが返ってきます）。\nindexes 配列に指定できるインデックスの名前は 1 つだけです。\nまた、1つのインデックスに対して複数のエイリアスをつけることは問題ありません。\n確認 エイリアスのリストも取得できます。\nGET /aliases?api-version=2021-04-30-preview 現在どんなエイリアスが、どのインデックスに対して付与されているかがリストで取得できます。 きちんと作成されたかどうかなどの確認にも使えるかと思います（もちろんエイリアス名を指定したGETも可能です）\n検索での利用 検索のREST APIでインデックス名を指定していた部分をエイリアス名に置き換えるだけです。\nPOST /indexes/my-alias/docs/search?api-version=2021-04-30-preview { \u0026#34;search\u0026#34;: \u0026#34;pool spa +airport\u0026#34;, \u0026#34;searchMode\u0026#34;: any, \u0026#34;queryType\u0026#34;: \u0026#34;simple\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;HotelId, HotelName, Category, Description\u0026#34;, \u0026#34;count\u0026#34;: true } 更新 エイリアスの更新（インデックスの入れ替え）は作成と同じリクエストです。 更新が成功すれば204のステータスコードが返ってきます（エイリアス初回作成時は201） なお、ドキュメントには以下のような記述があります。入れ替え時の注意点になるかと（入れ替えのタイミングをきちんと制御したい場合は、少しだけアプリケーションを停止するなどが必要かと思います）。\n別名に対する更新がシステムに反映されるまでに最大 10 秒かかります。以前その別名が対応付けられていたインデックスを削除するのは、10 秒以上待ってからにしてください。\n削除 もちろん削除もできます。\nDELETE /aliases/my-alias エイリアスを利用する場合の注意点 便利なエイリアスですが、エイリアスが使用できない場合もあるので注意が必要です。\nデータ登録のAPIと検索のAPIでのみエイリアス名を利用可能 インデックスの設定変更やAnalyze Text APIではこれまで通りインデックス名を指定します。 また、エイリアス名はインデクサー機能でtargetIndexNameにも指定できません。 エイリアス名がついているインデックスは削除不可 エイリアスがついているインデックスを削除しようとした場合はエラーが出るようになっています。 まずはエイリアスを削除してからインデックスを削除するという手順になります。 まとめ 簡単ですが、インデックスのエイリアスに関しての紹介でした。まだパブリックプレビューなので正式リリース時点では利用方法が変わっている可能性もあります。こちらは注意してください。\n正式公開されればですが、今後Azure Cognitive Searchを使ったアプリを開発する場合はインデックスエイリアスを利用することを基本にするのがいいかもなと思います （ちなみに、Elasticsearchにもインデックスエイリアスの機能がありますが、異なる点が多いので同じものとは思わないほうがよさそうです）。\n","date":1652856857,"dir":"post/2022/","id":"7cc21814165879f72529e91682ece5c6","lang":"ja","lastmod":1652856857,"permalink":"https://blog.johtani.info/blog/2022/05/18/index-alias-in-azure-cognitive-search/","publishdate":"2022-05-18T15:54:17+09:00","summary":"Azure Cognitive Searchで2月に新しい機能が公開されました。 「Index Alias」（インデックスの別名）です。まだ、パブリックプレビューの段階です","tags":["azure search"],"title":"インデックスエイリアス - Azure Cognitive Searchの新機能"},{"contents":"年末までに知り合いと次の論文を読んだので軽くまとめておきます。\nExtreme Multi-label Learning for Semantic Matching in Product Search なんで読んだの？ 前回読んだ理由と一緒ですが、Semantic Searchに絡んだ検索の論文であり、Amazonの製品検索での話も関係していたので読みました。\nどんな論文？ Amazonの製品検索でセマンティックマッチングを利用する方法、レイテンシを低くしつつ再現率を改善できるような仕組みを検討して評価した論文です。 実際には商品検索のマッチングを大規模なマルチラベル問題（Extreme Multi-label Classification：以下ではXMC問題とする）として定義して、その問題を効率よく解く方法について検討評価しています。\n検索には大きく2つのフェーズがあります。マッチング（クエリにヒットした文書の集合を求める）とランキング（マッチングのデータを関連性の高い順序で並べる）です。 前回のMSの論文では、マッチング後のランキングのフェーズで言語モデルを利用した並び替えを行う話でした。 今回の論文ではマッチングに関してセマンティックサーチを有効活用できないか？という論文になります。 転置インデックスベースの（語彙による）検索では、スペルミスや類義語などを検索することが難しいです。 語彙以外のデータ（クリックや購入といったユーザーの行動や製品の意味的表現など）を学習できる埋め込みベースのニューラルモデルを活用して、マッチングを補完する方法を検討しています。 下図のようにあくまで転置インデックスベースの検索の補完として利用するみたいです（論文に掲載されていたアーキテクチャ）。\nXMC問題とは？ セマンティックサーチを行なう場合、埋め込みベースのニューラルモデル（例えばBERTとか）を利用することが多いですが、 クエリトークンを埋め込み空間にベクトル化する部分が推論のボトルネック（レイテンシが高くなる）になることが多いです。 これは、ニューラルネットワークの複雑さに依存します。 低レイテンシになるように、複雑ではないエンコーダーを用いることもありますが今度は性能（精度）が良くなくなります。\nそこで、この論文ではセマンティックマッチングをXMC問題として定義し、これを効率よく解くための手法を提案しています。 ここで、XMCの問題とは、入力（今回はクエリ）に対して、最も関連性の高い複数のラベル（今回は製品）を出力することとなります。 Amazonでの製品なのでほんとに大規模（ラベル＝製品＝1億件）です。\n従来のXMC問題を解くための手法として、疎な線形モデルの手法、パーティションベースの手法、グラフベースの手法などが列挙されています。 疎な線形モデルの手法では、ナイーブなOVR(one-versus-rest)だと出力となるラベルの数に対して線形に推論時間も大きくなるため、今回の用途には適しません。 この論文ではパーティションベースの手法として、推論時間を短くできるツリーベースで疎な線形モデルの手法を評価しています。\nどういう仕組み？ ツリーベースのモデルは次のような感じです。 PECOSのXR-Linearモデルを利用しています。 モデルに関する詳細についてはこちらの論文に詳しく載っているようです（まだ読んでいないです、、、）。\n一番上に入力として与えられるxがクエリ（ベクトル）で一番下の四角が製品にあたるラベル（Y={1,...,l,...L}）です。 これらが与えられたときに最も関連性の高い上位k件のラベル（製品）を出力するモデルを生成します。 モデルのパラメータは、学習データとして(x, y)(ここで、y∈{0, 1}^𝐿、すなわちクエリに製品がマッチするかしないかの二値)を使って調整します。\nこれは、ツリーのそれぞれの階層のノードで、その下の層に関連するデータがあるかどうか？という分類を学習すればよいことになります。 学習データとしては、入力と最下層のラベルにマッチするかどうかというデータです。 これをもとに、ツリーの最下層のデータをもとにひとつ上の層の分類器の学習をすればよいことになります。\n推論は出来上がったツリーベースのモデルに対して、ビームサーチで行ないます。 この時、それぞれの層のノードの分類器では推論の効率化のために枝刈りの閾値を設定しています。 本論文で閾値の違いによる精度とレイテンシの比較も行われています。 また、ビームサーチのビームサイズを変化させた場合の性能についても実験しています。\nどうやって検証した？ 次のようなデータを用いてAWS上にモデル構築、推論のシステムを用意し実験しています。\n10億件以上のポジティブなクエリ-商品ペアのデータセット クエリ：2億4千万、商品：1億 ポジティブなペアとは、クリック数や購入数の集計値が閾値以上。ただし、データセットとしては集計値は利用していない。 トレーニングセット：12か月分の検索ログ 評価用テストセット：1か月分の検索ログ（12％の製品はトレーニングセットには出てこない） というデーセットをもとに上記のモデルを学習しています。 特徴量はクエリテキストと製品のタイトルをもとにTF-IDFをいくつかのパターンで導出したものが使われています。 詳しくは論文の結果に関する表などを見ていただくとして。。。\n結果として、1億件の商品カタログで60.9%のRecall@100を1.25ミリ秒/リクエストという低レイテンシで達成したとなっています。\n気になる点は？ 知り合いと3人で読んでいて次のような気になる点が出てきました。\nツリーの構築をするときに、製品のラベルの並び順（製品のクラスタリング？に他製品が似た場所に来る感じ）が推論の効率の良し悪しに影響するんじゃないの？＝Amazonではないところではうまくいかない？ PECOSの論文読まないといけない？ 製品が増えたときにモデルの組み換えとかどうするの？ コールドスタート問題という形で今後の課題として書かれていたので、今後に期待 転置インデックスでのマッチングの補完として利用しているということだったけど、ランキングはどうしてるんだろう？ 別のランキング用の指標があるのかな？上位k件とした場合にどうやって、決めているのか？ モデル更新のタイミングはどのくらいのスパンなんだろう？ まとめ＆感想 セマンティック検索の処理を分類問題に置き換えてその手法を用いて行い、実際のシステムに適用できそうな速度と精度を出しているのが面白かったです。 セマンティック検索にもいろんな手法があるのだなと（そして、いろいろ勉強しないといけないんだなと。。。）。\n気になる点にも書きましたが、ツリーの作り方になにかコツがあるのか？他の検索結果と組み合わせるときに、どのような基準で上位を選択しているのか？など疑問点も残っています。 個人的には特にどのように既存のシステムにくっつけていくのかというところが気になっています。 論文の続編でその辺の話が出てくるのかなぁ？\nツリーの作り方に関するPECOSの論文を誰か解説してくれると嬉しいかもなぁと思いつつ、とりあえずブログに書き残してみました。参考になるかなぁ。。。\n参考文献 Extreme Multi-label Learning for Semantic Matching in Product Search - ACM Extreme multi-label learning for semantic matching in product search - Amazon Science PECOS： Prediction for Enormous and Correlated Output Spaces 数えきれないほどの分類を行うExtreme Classification - Technical Hedgehog ","date":1641980462,"dir":"post/2022/","id":"0645bdb1cdf88ec74288d503eb71839c","lang":"ja","lastmod":1641980462,"permalink":"https://blog.johtani.info/blog/2022/01/12/reading-xmc-for-semantic-search-in-prod/","publishdate":"2022-01-12T18:41:02+09:00","summary":"年末までに知り合いと次の論文を読んだので軽くまとめておきます。 Extreme Multi-label Learning for Semantic Matching in Product Search なんで読んだの？ 前回読んだ理由と一緒ですが、Semantic","tags":["search","paper"],"title":"Extreme Multi-label Learning for Semantic Matching in Product Searchという論文を読んだ"},{"contents":"今年も振り返りブログです。録画した紅白をオッかけ再生して気になるアーティストだけ見ながら書ています。\n振り返り（2020年に書いた抱負から） まずは去年の抱負を元に書きます。今年もコロナウィルスの影響が年末まで続き、ほとんどで書けなかったです。\nフリーランス継続? ありがたいことに個人事業主として無事1年を終えられました。 夏頃は5社ほどお手伝いをさせていただき、年末時点では3社をお手伝いさせていただいています。\n昨年の振り返りで書いた2社はありがたいことに継続していただいています。\n今年も完全リモートで仕事が終わりました。オミクロン株が来ているし、来年春くらいにはミーティングに出かけられるかなぁ。 相変わらず検索のお手伝いをしています。手伝いをしつつ勉強させていただいている感じです。 ありがたし。\nプログラミング ちょっとペースダウンしています。。。\nextract-kana-java 新しく書いたのはこれくらいかな。 SudachiやNeologdのkuromojiでフリガナを出力して違いを見るというコマンドツールです。 ちょっと比較してみたくなったので書いて公開しました。\nあとは、Sudachiをいろいろと触り始めています。 来年はそのへんをもうちょっと何かできるかなぁ。 コーディングしないとよくないなぁと思っているので、強制的になんかやらないとだ。\n検索の勉強 仕事でやってます。ブッチャー本は昨年買って手を付けてませんが。。。 来年は少しずつやる予定です。 あとは、Azure Cognitive SearchのSemantic Searchを触った関係でSemantic Searchに関する論文を探してちょっとずつ読んでいます。 知り合いと読んでいたAmazonの論文をブログにまとめるのは来年早々に。。。\n検索のポッドキャスト? これはできませんでした。重い腰が上がらない。 公開しないまでも雑談したいなぁ。\n振り返り(今年あったできごと) ここからは今年の出来事を。\n自宅環境 キーボード以外もDIY 検索Slack爆誕 車買い替えた WindowsノートPC買った 今年もずっと自宅で仕事でした。 昨年だいぶそろえていたのでそれほど変更はないですが。\n2月バージョン 切り替えてからずっとWindowsです。Macもブラウズ用に使ってはいますが。 ただ、Windowsといっても、プログラムなどに関する環境はほぼWSL2になっています。コマンドプロンプトは触ってないなぁ。 今年最後に更新された自宅環境は椅子になります。 詳しくは昨日のブログをご覧ください。\nキーボードもDIYしましたが、今年はほかにも少しDIYしました。\n今年のDIYキーボードとコントローラーラック このブログにも書きましたが、来年はキーマップやファーム関連を触っていきたいなと。あとロータリーエンコーダー。。。 BLE化は快適で、3台のPCの切り替えがとっても便利です。\ntakuya_aさんの鶴の一声で検索のSlackが爆誕しました。 検索に関連する情報交換ができる場として楽しませてもらってます。 年末には検索100本ノックの話が立ち上がってきています。 来年も面白い話が聞けそうでワクワクしています。\nあとは、車を買い替えました。初のハイブリッドです。 まだまだ慣れないですが、燃費とかがとても楽しみです。\n結局まだ出かけていませんが、出かけられるようにFMV Zeroを購入しました。 このブログもリビングでFMV Zeroで書いています（まだちゃんとセットアップしていないので、実際にはリモートデスクトップでデスクトップにつないでそこのVSCodeで書いちゃってますが。。。）。 ブログ書いたりコード書ける程度の環境は作らないとな。\n来年の抱負 ということで、来年の抱負です。\nフリーランス継続 プログラミング ブッチャー本ちゃんと読む 読んだ本のブログを書く 今年もありがたいことに仕事を継続していただけて、乗り越えられました。 来年も価値を提供できるように頑張っていきます。\nプログラミングは失速気味のでなにかテーマを見つけないとなあ。\nブッチャー本は読み始めます。必ずｗ\nブログのペースが落ちていたり、本を読むペースが落ちているので、 本を読んで自分のためにもブログを書こうと思います。 書いてないって思ったら叱咤してください。。。\n今年も出かけられませんでしたが、仕事も安定してあり、無事乗り切れました。 人と話をする機会は減っているので雑談したいな、オンラインなどで。 相手をしてやってもいいぞという方はぜひ連絡ください。\nさて、来年（もう年あけちゃったけど）は出かけられるかなぁ。 何はともあれ、今年もよろしくお願いします！\n","date":1640957359,"dir":"post/2021/","id":"104b8ee17a8bf1f7043d236659680493","lang":"ja","lastmod":1640957359,"permalink":"https://blog.johtani.info/blog/2021/12/31/looking-back-2021/","publishdate":"2021-12-31T22:29:19+09:00","summary":"今年も振り返りブログです。録画した紅白をオッかけ再生して気になるアーティストだけ見ながら書ています。 振り返り（2020年に書いた抱負から） ま","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2021）"},{"contents":"2021年もあと少しですが、今年買って良かったものをリストアップしておこうかと思います。 今年買ったといいながら、昨年このネタを書くといいつつ書いてないので、昨年の分も入っているかも？ Amazonのアフィリンクを貼っていますが、急いでないものはAliExpressで購入したりもしています。\n象印のポット Amazon | 象印 電気ケトル 1.0L コーヒードリップ用機能付き ホワイト CK-AX10-WA | 象印マホービン(ZOJIRUSHI) いわゆる電気ケトルというやつです。これが来るまでは鍋で湯を沸かしていました。 水を入れてボタンを押し、湯を沸かしている間に他のことができるのはやはり便利です。 また、コーヒーを入れるためのコーヒードリップモードがあるので、ドリップするためにわざわざ湯を他のものに入れたり、 専用のヤカンを使わなくても簡単にドリップができるのがさらに便利で重宝しています。\nウォータードリップコーヒーサーバー Amazon | iwaki(イワキ) コーヒーサーバー SNOWTOP ウォータードリップ ここ数年、冬以外は水出しコーヒーを飲んでいます。 麦茶のポットのような水出しコーヒー用ポットを使っていたのですが、滴下式のほうがえぐみが少ないというのを見かけてウォータードリップのサーバーに変えてみました。 このひとつ前に水のタンクの部分がプラスチックのものを利用していたのですが、ドリップする部分を壊してしまったので、部品を購入することができるこちらに切り替えました。 朝、仕事をする前に豆を挽いて仕込んでおくと、昼にはコーヒーが落ちています。 夏は入れ終わったポットごと冷蔵庫に入れておくと氷を入れなくてもアイスコーヒーが飲めるので気に入っています。\neufyの掃除機 Amazon | Anker Eufy HomeVac H11（ハンディクリーナー） USB充電 仕事に使っている机でプラモデルを作ったり、DIYキーボードの工作をしたりと細かなごみが出る作業を行ないます。 ちょっとごみを吸いたいだけなのに、掃除機を毎回取りに行くのも面倒なので充電式のクリーナーを買ってみました。 仕組みも簡単だし、USBで充電できるのでおすすめです。アタッチメントを利用してキーボードの掃除なんかもしています。\n電動精密ドライバー Amazon | Wowstick 1F\u0026#43; 69in1 電動精密ドライバー ビット56種セット ケース USB充電式 LEDライト付き [並行輸入品] キースイッチを付け替えたり、工作したりでねじの開け閉めを頻繁に行います。 思ったよりも頻度が高くなってきたので、電動の精密ドライバーを試しに使ってみたらすごく楽ができました。 電池の入れ替えなどでもねじの開け閉めは行なうので、すごく役に立っています。 ビットが56種類もついていますが、プラスとマイナス以外はまだ使ってないかも。。。\n磁石のUSBケーブル Amazon | SUNTAIHO マグネット充電ケーブル DIYキーボード、エネループの充電器、上記のドライバーや掃除機など、USBで充電したり、接続するものが結構あります。 毎回ケーブルを差し替えるのも大変なのですが、@ymotongpooに教えてもらった磁石のUSBケーブルがお気に入りです。 先端部分（USB-C、micro）とケーブル部分が別々になっており、また、ケーブルと先端は磁石でくっつく構造なので、充電したい機器に先端部分を刺しておきます。 充電や接続したいときにケーブルを近づけると磁石でくっついてくれるのでケーブルの抜き差しが必要なくなります。 先端部分だけを個別に購入できたので、色々な機器にあらかじめつけてあります。\nMaker hart Just Mixer 5 Amazon | Maker hart Just Mixer 5 ステレオ5入力音声ミキサー/Bluetoothオーディオ入力対応 3台のPC＋音楽サーバーとしてラズパイを主に利用しており、通知音などを1つのスピーカーから聞きたいので、ミキサーを導入しました。 5つの入力個別に音量調節できるので打ち合わせの時だけ他の音源を小さくしたりなど重宝しています。 ただ、入力が増えるとノイズが乗っている気もしますが。。。\nリストレスト（アームレスト） Amazon | エレコム リストレスト アームレスト 肘起き 扇形 左右で使える2個セット ブラック MOH-EL01BK 扇形のものを分割キーボードの手間においてリストレストとして使っています。 使用例の写真を見ると肘を置いていますが、手のひらをおくのにちょうどいいです。 これまでいくつかパームレストを試してみましたが、凹凸もなく適度な硬さで気に入っています。\nコンテッサセコンダ Amazon | オカムラ オフィスチェア コンテッサ セコンダ 10月に注文してクリスマスに届きました。部品が不足しているようで年内に届かないかもといわれていたのですが。 2003年くらいからアーロンチェアを使っていたのですが、さすがに買い替えるかということで奮発しました。 アーロンチェアは座面がメッシュなのですが、ももが疲れるのもあり、クッション座面のものにしてみました。 冬寒くないのがいいですねｗまだ届いたばかりなので調整しないと。\nKindle paperwhite Amazon | Kindle Paperwhite - 大きくなった6.8インチディスプレイ 防水機能搭載 wifi 8GB 電子書籍リーダー 車の点検などでちょっとした待ち時間があるようなときに新書や小説が読めるようにセールで安くなったタイミングで購入しました。 健康診断で読書がはかどりました。もっと本を読まないとなぁ。\nということで、ここ数年で買って便利なものをまとめてみました。 他にもある気がするけど、とりあえずこの辺で。\n","date":1640784504,"dir":"post/2021/","id":"218e2c36d5945ece02fdc55d6cbcbc38","lang":"ja","lastmod":1640784504,"permalink":"https://blog.johtani.info/blog/2021/12/29/best-buy-2021/","publishdate":"2021-12-29T22:28:24+09:00","summary":"2021年もあと少しですが、今年買って良かったものをリストアップしておこうかと思います。 今年買ったといいながら、昨年このネタを書くといいつつ","tags":["misc"],"title":"2021年かって良かったもの"},{"contents":"Azure Cognitive Searchのスキーマの確認をするときに、Azureのポータルでは次のようにフィールドの一覧として見ることができます。\nただ、実際のインデックス定義はJSON形式でやり取りする形になっています（JSONの例：Create Index | Microsoft Docs）。 上記のスクリーンショットのようにフィールド数が少ない場合はそれほど気にならないのですが、フィールド数が大きくなると一覧で見たくなることがあります。 また、ポータルを自分で確認できない場合にJSONファイルを受け取って確認することもあります。 こういう時は、Excel（CSV）って便利ですよね？\nということで、サクッと確認するときには、次のようなjqコマンドをWSL2上で利用して、CSVに変換して確認しています。\necho \u0026#34;Name\u0026#34;, \u0026#34;Type\u0026#34;, \u0026#34;Searchable\u0026#34;, \u0026#34;Facetable\u0026#34;, \u0026#34;Filterable\u0026#34;, \u0026#34;Retrievable\u0026#34;, \u0026#34;Sortable\u0026#34;, \u0026#34;Analyzer\u0026#34;, \u0026#34;IndexAnalyzer\u0026#34;, \u0026#34;SearchAnalyzer\u0026#34; \u0026gt; index_schema.csv cat index_schema.json | jq -r \u0026#39;.fields[]|[.name, .type, .searchable, .facetable, .filterable, .retrievable, .sortable, .analyzer, .indexAnalyzer, .searchAnalyzer]|@csv\u0026#39; \u0026gt;\u0026gt; index_schema.csv 例えばこんな感じになります（上記のポータルのスクショとは別のスキーマですが。。。）。\nどんなフィールドオプションが利用されているか？などをExcelで開いてフィルターなどを活用してチェックするのには便利かなと。 jqコマンドをもっとうまく使うと、ヘッダ行ももっとスマートに出せるかもしれないんですが。。。\nちなみに、上記のコマンドでは残念ながらEdm.ComplexType（参考： 複合データ型をモデル化する方法 - Azure Cognitive Search | Microsoft Docs）には対応していません。 必要になった時に考えるかな。。。\n","date":1640141671,"dir":"post/2021/","id":"f0fdc140e18514362a4e52376a6fecba","lang":"ja","lastmod":1640141671,"permalink":"https://blog.johtani.info/blog/2021/12/22/azure-search-schema-json2csv/","publishdate":"2021-12-22T11:54:31+09:00","summary":"Azure Cognitive Searchのスキーマの確認をするときに、Azureのポータルでは次のようにフィールドの一覧として見ることができます。 ただ、実際のインデ","tags":["azure search","misc"],"title":"Azure Cognitive SearchのIndex Schema JSONをCSVで見たくなる"},{"contents":"今年もアドベントカレンダーの季節になってしまいました。 今年で2回目となる、pyspa Advent Calendar 2021の投稿です。 昨年に引き続きDIYがらみの投稿です。\nコントローラーラック 3つのコントローラーがあるのですが、結構場所を取ります。 また、それぞれ充電しないといけません。\n充電しつつ、邪魔にならない置き方はできないものか？と思っていたところ次のようなコントローラーラックを見つけました。\nAmazon | 山崎実業(Yamazaki) ゲームコントローラー収納ラック これそのものは場所を取るので購入は見送りましたが、エレクターの棚にワイヤーネットをつけると似たようなものができるのでは？ということで、DIYしてみることにしました。\n材料 材料は以下の通りです。 書いていない材料としてあとは、結束バンドがあります。\nワイヤーネット４４×２９．５ｃｍ オフホワイトＢ２８ | 【公式】DAISO（ダイソー）ネットストア スリム型ネットフック５０ｍｍ ２本入り | 【公式】DAISO（ダイソー）ネットストア クロームメッキワイヤーフック（２連、Ｕ字、２個） | 【公式】DAISO（ダイソー）ネットストア Amazon | マグネット 充電ケーブル SUNTAIHO USBケーブル LEDインジケーター付き Amazon | Anker PowerPort Atom III Slim （PD 充電器 65W 4ポート USB-C） 設置 まずは、2連のワイヤーフックでワイヤーネットをエレクターの棚にぶら下げました。\nそのままでは固定されないので、下のエレクターの棚とワイヤーネットを結束バンドで固定。 これで、コントローラーを置いたり取ったりしてもぐらぐらしません。\n固定したワイヤーネットの表（コントローラーを配置する側）に、ネットフック50mmをコントローラーの数だけ配置しました（上の写真でフックとコントローラーの関係がわかります）。\n前から見るとこのような形です。 裏側に、2連フックを使って、Ankerの充電器を固定し、USBのケーブルをコントローラーの上に来るように配置します（写真ではPS4とPS5のコントローラーの上の部分にぶら下がる形です）。\nコントローラーには磁石の端子をコントローラーに差し込んでおきます。\n磁石のUSBケーブルを利用していることで、コントローラーを取り出すときは少し力を入れて引っ張るだけ、収めるときは、ケーブルに近づけて充電できる状態にした後にフックに載せるだけとなりました。 ケーブルの抜き差しをしなくてもよいのでとても便利。 全体像は次の写真のようになっています。一番上のコントローラーはエネループを利用しているのでケーブルは不要になっています。\n磁石のUSBケーブルをpyspaでとんぷーに教えてもらって思いついたアイデアです。 磁石の端子は色々と使い勝手が良いので、DIYキーボードやテンキー、MX Ergo、Kindleなど色々なところに使っています。\n今年のDIYキーボード キーボードを作ったのは2つですが、改造を色々やってました。 ブログに記載したものはリンクだけにしておきます。\nケーブル自作 自作ケーブルキット – 遊舎工房 ケーブルも自作できるみたいなので作ってみました。 現在はテンキーの配置の問題もあって、メインでは利用はしていませんが工作としては面白かったです。 熱収縮チューブを処理するための道具を持っていなかったので、チューブの固定が甘いのが失敗でした。ドライヤーくらいの熱では足りないので作ろうと思っている方は要注意かと。\nCorne Light v2のBLE+LPME-IO対応 詳細はブログ記事を。Corneはこれ以外に、キースイッチの付け替えも行ないました。ルブしたGateronクリアをハンダでつけなおしました。\nCorne Light v2のBLE+LPME-IO対応 #DIYキーボード Sofle keyboard v2のBLE+LPME-IO対応 詳細はブログ記事を。このブログはSofleで書いています。現在メインに利用しているキーボードです。\nSofle v2を組み立てて、BLE+LPME-IO化してみた #DIYキーボード 10月には電池モジュールを次のものに付け替えました。家で主に使用するのもあり、充電池のほうが使い勝手がよさそうだという判断です。スイッチのON/OFFもしやすくなって満足しています。\n単4電池昇圧モジュール - のぎけす屋 - BOOTH Sofleの電池モジュールをボタン電池から単4電池用に差し替えた。 pic.twitter.com/TUizwr2qmw\n\u0026mdash; Jun Ohtani (@johtani) October 16, 2021 Lunakey Miniの組み立てとBLE+LPME-IO対応 詳細はブログ記事を。Sofleと時々入れ替えて使っています。小指のあたりのずれの大きさ、親指のキーの多さが使い勝手のよいキーボードです。コンパクトなのもあり、こちらは持ち運びにも利用できるかなと考えています。\nLunakey Miniを組み立てて、BLE+LPME-IO化してみた #DIYキーボード Soyuzの組み立て（Numpadキット） Soyuz （黒基板） – 遊舎工房 自宅の作業環境(2021/02)の写真にもありますが、分割したキーボードとは別にテンキーを利用しています。 WindowsのログインでPinコードを入力したり、色々な場面で数字の入力をすることがあるためです。 Soyuzを組み立てる前は素 - Shiro – 遊舎工房を利用していたのですが、これでは「⁺」や「Enter」など、電卓のような利用方法の場合にはキーが足りません。 かゆいところに手が届かないので、きちんとしたNumpadをということでSoyuzを組み立てました。\nShiroよりもだいぶ存在感があります。\nGK21S（Numpad） USB Type C充電器付きの滑らかな交換用キーボードキット (Gk21s/k21),スイッチ,デュアルモードPCB|Keyboards| - AliExpress 最後は独身の日のセールで見つけたNumpadキットです。キットといってもこちらは、基盤からケースまで組み立てが終わっているキットで、キースイッチを差し込んで、キーキャップを付けるだけというものになります。 現在はこれをメインに利用しています。通常のNumpadの上に1列キーが多く、Backspaceなどを割り当てられるのが便利です。 ドライバーソフトも用意されており、キーマップのカスタマイズも可能です（まだそこまでやってないけど）。\nお気に入りキースイッチ Kailh Box Silent ピンク軸 5個 | Kochi Keyboard Input Club Hako スイッチ（10個入り） – 遊舎工房 最後はキースイッチの紹介です。 現時点ではこの2種類を組み合わせるのが私の好みに合っているようです（今のところ）。 Box Silentのピンクをアルファベットのキーに、Input Club HakoのVioletをCtrlやShift、Enterなどのキーに割り当てて使っています（下の写真の左側で、キーキャップをつけている部分がHako Violetになっています）。\nまとめ ということで、pyspa Advent Calendar 2021の8日目の記事でした。 それほど作ったりしてないなと思っていたのですが、記事にしてみると今年も色々とDIYしてたみたいです。 キースイッチやキーキャップも自分の好みが固まってきたので、来年はファームウェアやキーマップ周りをいじっていきたいと思っています。\n","date":1638889200,"dir":"post/2021/","id":"26e44dfd16a2963d4c18e99806c26fd7","lang":"ja","lastmod":1638889200,"permalink":"https://blog.johtani.info/blog/2021/12/08/controller-rack/","publishdate":"2021-12-08T00:00:00+09:00","summary":"今年もアドベントカレンダーの季節になってしまいました。 今年で2回目となる、pyspa Advent Calendar 2021の投稿です。 昨年に引き続きDIYがらみの投稿","tags":["DIYキーボード","misc"],"title":"今年のDIYキーボードとコントローラーラック"},{"contents":"Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだので軽くメモを残しておきます。論文自体はリンクから参照してください。\n読んだ理由 Azure Cognitive SearchでSemantic Searchが利用可能になったこともあり、「Semantic Search」に関するMSのリサーチチームが発表している論文をたまたま見つけたためです。 Elasticsearchとニューラルモデルを利用したランカーでのリランクする仕組みがSemantic Searchと似ていたので読んでみました。\nざっくりメモ どんなもの？ クリックログなどで関連度を改善できないような場合に、ドメイン固有の言語モデルを利用して検索結果の改善をする方法が提案されているので、バイオメディカル検索で実際に評価してみたという論文です。 特定分野の大量の文書から検索をするときに、ドメイン固有の事前学習した言語モデルを用意して、さらにファインチューニングする方法を評価しています。 言語モデルの生成に利用されたのはBERTになります。\n技術や手法のキモはどこ？ 医療分野のデータを利用して評価していますが、ほかのドメインにも一般化できる可能性があることや、実際のシステムを提示している部分が肝になりそうです。\n論文から引用した言語モデルを用いてランキングを行う仕組みを構築する部分の構成です。\n左半分が、ドメイン固有の事前学習についてです。Wikipediaなどを利用したBERTのモデルが公開されたりしていますが、大量のドメイン固有データが用意できるのであれば、ドメイン固有のデータで事前学習することが有効であるという主張です（参考文献。これもMS Researchでした。同じチームなのかな？）。 この論文ではBERTの学習データとして、ドメイン固有のテキストを用いています。 実際にはPubMedBERTを利用しています。\n右半分がドメイン固有のデータで生成された言語モデルを利用して、ドメイン固有のニューラルランカー（検索結果のランキングを行なう仕組み）をファインチューニングする処理です。 MS MARCOと呼ばれるMSが公開している機械学習向けのデータセットのうち、ドメイン固有のサブセットを取り出して利用しているようです。\nこの論文では、L1検索（第1段階の検索）にBM25を利用して、L2検索にここで作成したニューラルランカーを利用し、検索結果を返す仕組みとなっています。 これは、Azure Cognitive SearchのSemantic Searchのシステムに似ています。\nこの論文では、BM25で検索した結果の上位60件の結果がL2のランカーの入力となっています。\n以下の2つが主な論文の成果となっています。\nドメイン固有の事前学習を利用することで、高度な学習コンポーネントなどの追加することなく高い精度が出た。 既存のBM25の検索エンジンと組み合わせてニューラルランカーを使うことで、計算コストを下げつつより良い上位の検索結果を返す仕組みを構築した。 どうやって有効だと検証した？ TREC-COVIDデータセットを用いて評価して、TREC-COVIDに参加しているシステムと論文で提案している構成のシステムとの比較をしています。 また、ドメイン固有の事前学習が、一般ドメインなどの事前学習と比較して影響があるかどうかの評価もしています。\n実際にAzure上で構築した仕組みをMicrosoft Biomedical Searchとして公開しているようです。 上記のシステム構成のように、Elasticsearchで検索して、ニューラルランカーはKubernetes上に展開されたGPUで計算をしています。 論文には使用しているマシンの構成や台数なども記載があります。\n実際に構築したシステムをユーザーに利用して体験したもらった結果としては、 複雑な意図を持った長いクエリに対してはPubMedなどの他の検索ツールとしても良い結果が返ってきたことが確認されたとなっています。 ただし、一般的な短いクエリの場合は十分な結果にならない場合があったとのことです。\n議論はある？ 実際にほかのドメイン（金融、法律、小売りなど）で適用してもうまくいくかは今後の研究に期待だと思います。 また、ファインチューニングするときに利用できるデータが今回の論文にあるようにMS MARCOのサブセットとして抽出できればよさそうです。\n他に読むべき論文は？ TREC-COVIDに参加しているほかのシステムがどのような学習や仕組みが必要なのかを見ることで、どのくらいの手間・コストが軽減しているのかがわかるはずです。\n感想 ということで、読んでみました。 細かなほかの手法については調べていませんが、システム構成としてはAzure Cognitive SearchのSemantic Searchの仕組みと同じだと思われます。 違いは、ドメイン固有の事前学習のモデルではないことでしょうか。 ある程度のドメイン固有のモデルを利用できる仕組みができると、さらにSemantic Searchがうまく使えるようになるのかもしれません（前回書いたブログではWikipediaのデータを利用してみましたが、思ったほど良い感じはしなかったです。。。ファインチューニングの仕組みもないしなぁ）。 また、短いクエリでは芳しくない結果もあったというのは、おそらくニューラルランカーで評価するための情報が少なくなってしまうのだと思います。Semantic Searchに向いているクエリの作り方とかが出てくるのかな？\n","date":1636522396,"dir":"post/2021/","id":"35200cbf0b5b45d7f5f0b343cb18868b","lang":"ja","lastmod":1636522396,"permalink":"https://blog.johtani.info/blog/2021/11/10/reading-ms-biomedical-search-paper/","publishdate":"2021-11-10T14:33:16+09:00","summary":"Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだので軽くメモを残しておきます。論文自体はリンクから参照してください。 読んだ理由 Azure Cognitive S","tags":["search","paper"],"title":"Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだ"},{"contents":"今年もMICESにも参加してました。 昨年はBerlin Buzzwordsと共同開催でしたが、今年は別開催（別日程）でした。\nMICESは2017年から始まったe-commerceの検索にフォーカスしたカンファレンスです。 ECに関連する話に特化されていますが、話題は多岐にわたっています。色々やることありますねぇ、ECも。\n参加したセッション 参加したセッションの個人メモを今回も残しておきます。 セッション個別のリンクは用意されていないみたいですが、公式サイトにタイムテーブルがあり、セッションのタイトル、概要に加えて、スライドのPDFもリンクがあります。動画が公開されているものもあります。\nDreaming Search ビデオが公開されています。スライドがざっくりしたものなので最初に聞いた時にはしっくりこなかったので、聞き直してのメモです。 GDPRのような話で、個人の情報を自分たちで管理しようと流れがあります。 それぞれのECサイトなどでのユーザーのイベント（何を検索して、何をクリックした）情報はそれぞれのサイトで閉じた情報になっています。このため、自分の興味のある情報が断片化された情報でそれぞれのサイトで管理されてしまい、パーソナライゼーションされるもの（ランキングだったりレコメンドだったり）がいまいちな場合があります。 この個人の情報（ユーザーのイベント）をユーザー自身がハンドリングして、どの情報までをどこまで公開できるようにするというように管理できる仕組みができないか？という話のようでした。実際にそのための仕組み（もっと大きな話の仕様）を検討しているプロジェクトがあり、それに関連して検索という観点で夢を語っているセッションです。\nざっくり私が理解したのをまとめましたが、empathy.coという会社としてはいくつかPoCなども実施されているようでした。 個人の情報の扱い方に関する話は新鮮で面白かったです。 仕組みが出来上がり、各サイトが対応するとより個人が欲しい情報が集まりやすくなるのかなぁ？\nForget Facets, welcome Refinements (TM) Berlin BuzzwordsでいくつかLTをやられていた方によるファセットとその応用（彼らはRefinementsと名前をつけたみたい）についての話でした（ビデオとスライドが公開済み。）。 検索エンジンとファセットの関係の歴史から始まって、Kibanaでの使い方、モバイルや音声検索・チャットボットでのファセットは難しいよね？という話につながります。 ということで、Refinementsとして、ファセットを提示してユーザーに選んでもらうだけでなく状況に応じて、提案するための情報としてファセットを使うといいのでは？という話でした。例えば、チャットボットや音声検索での結果の場合、検索結果数が多くなるとユーザーが望んだものが返せるとは限らないです。その時に、ファセットの情報をもとに絞り込み条件を聞き返すネタに使うのはどうか？というような話でした。オートサジェスト（検索があいまいな時に、追加のキーワードを提案するもの）のような形でブランド名だったり、カテゴリーなどを表示する仕組みです。 実際の実装の話は、彼らが過去にBerlin Buzzwordsなどで話をしているのでそちらが参考になるとのことでした（参考：berlin buzzwords 2019 / Heystack 2019）\nReinforcement learning in search 検索における強化学習の話みたいです。ビデオとスライドが公開されています。ビジネス的に検索のランキングが重要だが、そのランキングをどうやって良くしていくのか？という話です。 ランキングでデフォルトのBM25から始まり、LtRを導入し、A/Bテストなどをしつつ、モデルの変化がどのようにビジネスに影響するかをはかるのが難しくなります。 LtRに対するオンライン機械学習のアプローチについて実際に直面した課題の話などがされている（はず？）です（どうも、実際にCTRなどを用いたところまでは行ってなさそう）。\n多腕バンディットなどの強化学習の話が続いたあたりでギブアップしてしまいました。。。\nBetter Search through Query Understanding - Panel Query Understandingに関するパネルとして3社の人がそれぞれどういった取り組みをしてるか？という話をしたあと質問などに答えていく形式でした。残念ながらビデオはまだ公開されていませんが、スライドが公開されています。QA部分も結構な時間だったのでビデオの公開がされるといいなぁ。\nUnderstanding queries by analysing user interaction / Andrea Schütt (OTTO) OTTOというECサイトでのQuery Understandingの紹介と、LtR導入にまつわる話。 データサイエンスとして最初はQuery Understandingやってたけど、スケールしないのでLtR導入して色々と試行錯誤しているところのようだった。\nQuery Understanding AI search eBayの方の発表。Query Understanding = ユーザーの興味をクエリから類推するという定義から、クエリを分類する、同定するためにどうしているか？という話でっした。 単語の表面的な文字としての近さだけでは、語順が変わると意味が変わるものや、ステミングのせいで同じになってしまうものといった例を紹介しつつ、クエリをベクトルにして表現（コンバージョン、クリックなどの情報を元にプロダクトのベクトルにしてみたり）し似ているかどうか？を判断している話です。\nCase study : Autocomplete Search Suggestions Digitec Galaxusというサイトでのオートコンプリートをもっと使いやすくするためにどんなデータを集めて、どうやって表示しているか？という話でした。 とりあえず入力されたものにヒットしたものを出すような実装だった場合に、サジェストされる量が多く、ノイズも多いので使いにくかったものをどうやって改善して行ったかという処理の流れなどの説明もありました。\nThe need for an open web search in Europe - The approach of the Open Search Foundation and its implications for E-Commerce-Companies Speaker: Alexander Decker / OPEN SEARCH FOUNDATION\nもっとオープンな検索システムを作っていこうという団体の話でした。 AWSが最近1.0をリリースしたやつとは別物です。 Googleでみんな検索しているけど、ブラックボックスなのでバイアスがかかっている。 もっとバイアスフリーなインデックスを提供できると、使いやすくなるよね？みんなでそういうインデックスを作っていかないか？という話でした。 ECとの直接の関係はセッションからは読み取れませんでした。 どうやって、集めるデータの基準（入れるべき、入れるべきではないなど）を作るんだろう？という疑問が残っています。公共的なものやオープンデータについてはあるとよさそうかもなぁ。\n101 hints to improving the customer satisfaction on search engines in the retail industry Speaker: Marion Hemery (Carrefour France) \u0026amp; Lucian Precup (a// \u0026amp; Adelean)\nカルフールのECサイトでの検索に関する顧客満足度の改善についての話です。 どんなものをどうやって図るのか、フィードバックを取るための仕組みは？ そこからわかったものをどうやってシステムに優先度をつけながら取り込んでいくのか？ というのをどんなものを使っているかという説明を交えながらのセッションです。 スライドが結構細かく書かれているのでスライドを見るだけでもわかりやすいかな。\n“An ounce of prevention is worth a pound of cure”: establishing a gold standard-based evaluation in customer projects Speaker: Bertram Sändig \u0026amp; Cornelia Werk / NEOFONIE\n検索の性能指標（速度ではないほうの性能）をきちんと評価する仕組みが重要だよというセッションです。 検索の仕組みを変更（例ではステミングを導入するはなしをしてました）した場合に、現行システムにどういう影響が出るのか？それをどうやって図るのか、どうやってテストしていくのか？という話です。 ステミングを導入したら、検索にヒットしやすくなったものも出てきたけどその弊害として今までよかった検索の結果にノイズが増え多という話をもとに、検索結果としてこうあってほしいというゴールデンスタンダードをきちんと作って育てていくべきですよという話でした。完ぺきなものなどないので少しずつやっていきましょうと。\nということで、見ていないもの（LTや最後のワークショップ）もありますが、見たものに関してメモを残してみました。\n","date":1626160103,"dir":"post/2021/","id":"10a7f69bd03d2632722300194f01e93d","lang":"ja","lastmod":1626160103,"permalink":"https://blog.johtani.info/blog/2021/07/13/attend-mices-2021/","publishdate":"2021-07-13T16:08:23+09:00","summary":"今年もMICESにも参加してました。 昨年はBerlin Buzzwordsと共同開催でしたが、今年は別開催（別日程）でした。 MICESは201","tags":["conference","berlin buzzwords","MICES"],"title":"今年もMICESにオンライン出張してた"},{"contents":"今年もBerlin Buzzwordsにオンライン出張してました。 今年の開催は6月14日から17日まででした。 どんなカンファレンスなのかは昨年のブログ記事をごらんください。\n今年はHAYSTACKは共同開催で、MICESは別開催でした。 MICESにも参加していたので、また後日にブログ記事を公開する予定です。\n参加したセッション 参加したセッションの個人用のメモを取ってあるので、簡単にまとめておきます。 セッションページに動画やスライドも追加されつつあります。興味のある方はそちらをご覧いただければと。 （今のところYouTubeに上がっているビデオは69本あります。再生リストはこちら） 気になっていたセッションもあるので、ビデオを見てまたメモを公開すると思いますが、まずは第1弾を。 ちなみに、検索をメインに見ています。Berlin Buzzwords自体はオブザバビリティやOSSコミュニティ、データのストリーミングの話などの話題もあるので、この辺りも興味があれば探してみても面白いかもです。\nHow to measure Diversity of Search Results セッションページ： How to measure Diversity of Search Results | Berlin Buzzwords 2021 従来の検索では、クエリに対して精度の高い検索結果を1件または数件返すのはどうするか？というものだったが、最近、あるユースケース（ほかの物の発見を促したいケース）では 検索結果の多様性を高めつつ、精度もある程度確保したいという場合があります。\nざっくりした検索クエリ（例えば自転車）の場合に、自転車だけが1ページ目にある場合よりも自転車とは別に自転車グッズも表示された場合のほうがクリック率やGMV（Gross Merchandice Value?）が上がったという話が紹介されていました。 この時どのくらい混ぜればいいのか？というのを、シャノンのエントロピーを使って、検索結果の多様性を保つための具体的なヒントについて話をされています。 実際にこういう計算をしてやれますねという紹介がされています。\nFrom text search and recommendation to ads and online dating; approximate nearest neighbors in real world applications セッションページ: From text search and recommendation to ads and online dating; approximate nearest neighbors in real world applications | Berlin Buzzwords 2021 Vespa.ai（OSS）の紹介でANNの話でした。通常、ANNを用いた検索の場合に他の検索条件（地理情報、日付など）をANNの結果に対して適用すると、望んでいる数がとれないです。その場合に、Vespaは内部でいい感じの動きをしますよという紹介でした。\n\u0026ldquo;Are You Sure?\u0026quot;： blending product comparisons and recommendations with A.I. セッションページ: \u0026ldquo;Are You Sure?\u0026quot;： blending product comparisons and recommendations with A.I. | Berlin Buzzwords 2021 Amazonの製品ページにある、類似商品との比較一覧のような一覧をどうやって実現するか？という話でした。比較一覧に掲載する商品を選出するパイプラインをこうやれますよね?という話でした。ログ（クリックやカートに入れたかどうかなど）を元にkNNで似ているデータを洗い出し、どの商品、どの項目を比較一覧として選ぶかという流れでした（セッションではもっと詳しい話がされています）。オフライン実験の話までがセッションでされています。\nThe future of Lucene\u0026rsquo;s MMapDirectory： Why use it and what\u0026rsquo;s coming with Java 16 and later? セッションページ: The future of Lucene\u0026rsquo;s MMapDirectory： Why use it and what\u0026rsquo;s coming with Java 16 and later? | Berlin Buzzwords 2021 Apache Lucene PMCのUweさんによるLuceneのMMapDirectoryの話です。 ファイルシステムとJavaに関する歴史と、なぜMMapなのか、現在のMMapの実装の問題点とJDK 16でどうなっているか（どんな感触か）、さらにその先（JDK17）は？という話です。 Luceneでの利用方法からJDKへのフィードバックが行われている話や、そのフィードバックをもとに今後どのようにしていくのか?という話がされています。\nSearch and Sushi; Freshness Counts セッションページ: Search and Sushi; Freshness Counts | Berlin Buzzwords 2021 こちらもVespa.aiの紹介です（今年はスポンサーしてるから多いのかも？）。Yahoo!とVerizon Mediaで利用している話をしたあと、Vespaでのリアルタイムインデキシングに関するアーキテクチャの紹介でした。内部で転置インデックスやそれ以外のデータをどのように保持しているのか？どういったことができるのか？というのをアーキテクチャ、ストレージの観点から紹介しています。\nEncores? - Going beyond matching and ranking of search results セッションページ(動画がまだない): Encores? - Going beyond matching and ranking of search results | Berlin Buzzwords 2021 検索のマッチングやランキング以外のいくつかの機能についての紹介をワークショップ形式で行うセッションです。ファセット、クエリオートコンプリート、スペル訂正、クエリリラクゼーションについて、データとSolrのクエリを基準に説明をしてくれます。\nThe Invasion of Transformers - Boosting Search with Latest NLP セッションページ: The Invasion of Transformers - Boosting Search with Latest NLP | Berlin Buzzwords 2021 deepsetという会社のCTOの方で、自社で作っているOSSのhaystackという製品の紹介です。 最近のGoogleの検索結果にはいろんなもの（問いかけに関する答えそのもの、またそのプレビューやサマリー）が出てきているという話から、Transformersを使って検索ができないかということで自社のOSSの仕組みを紹介しています。\n参考 Google： BERT now used on almost every English query deepset-ai/haystack： End-to-end Python framework for building natural language search interfaces to data. Leverages Transformers and the State-of-the-Art of NLP. Supports DPR, Elasticsearch, Hugging Face’s Hub, and much more! Learning to Judge セッションページ: Learning to Judge | Berlin Buzzwords 2021 otto.deというECサイトでLtRを導入し、そのLtRにどんな特徴を利用しどうやって実験したかというセッションでした。Apache Solrで検索ができていて、これまでは検索の管理を人手で行っていたがスケールしない（扱う商品などは増えているのに）のでLtRを導入し始めたという感じでした。LtRの導入の過程でどういう仮定を置いて、どうモデルを決め、それをどうやってテストしてどう分析したか?という流れでした。\nText categorization with Apache Lucene セッションページ: Text categorization with Apache Lucene | Berlin Buzzwords 2021 LTなので短めです。BBCのデータセットをインデックスに登録し、そのデータをもとにLucene（デモではKibana＋Esを利用していた）でテキスト分類を行なう方法について紹介しています。BBCのデータセットは記事（テキスト）とカテゴリ（タグ）というデータです。 このデータが登録されているインデックスに対して、More Like Thisクエリに分類したい文章を与え、ヒットしたデータをもとにAggregationでカテゴリを取得し、上位のカテゴリが分類された結果になるというデモでした。 テキストフィールドにはEdge N-Gramを利用していること、Aggregationのソートの条件はMore Like Thisクエリでのスコアの平均を利用していることというのがこの方法がうまくいくことのようでした（なるほど！）。ただ、日本語でもこれが使えるかな？というのはやってみないとわからないかなぁと（やってないです）。\nとりあえず、メモしておいたのはこの辺でした。 他にもセッション一覧を眺めながら面白そうな話をピックアップしてメモを取っていこうかなぁ？気になるセッション、メモがおかしいなどあればコメントいただければと。\n","date":1625815493,"dir":"post/2021/","id":"59b7b60e6bbf4858d72643d22ad90451","lang":"ja","lastmod":1625815493,"permalink":"https://blog.johtani.info/blog/2021/07/09/berlin-buzzwords-2021-1/","publishdate":"2021-07-09T16:24:53+09:00","summary":"今年もBerlin Buzzwordsにオンライン出張してました。 今年の開催は6月14日から17日まででした。 どんなカンファレンスなのかは昨年","tags":["conference","berlin buzzwords"],"title":"今年もBerlin Buzzwordsにオンライン出張してた"},{"contents":"Azure Cognitive Searchで新機能「Semantic Search（セマンティック検索）」という機能の日本語対応が発表されました。 実際にはPublic Previewという状態ではありますが、どんな機能か気になったので調べてみました。 なお、本ブログは2021年6月時点での内容となります。\n公式ドキュメント 公式ドキュメントでいろいろと説明されています。まずは公式ドキュメントを見ていただくのが良いかなと。最初のドキュメントには10分ちょっとの紹介ビデオもあります。ピックアップしたのは概要、クエリ、レスポンスの構造、紹介ブログになります。ブログ以外は日本語（たぶん機械翻訳？）になっています(新機能の紹介の日本語ページにはまだ記載がありません)。\nSemantic search - Azure Cognitive Search | Microsoft Docs Create a semantic query - Azure Cognitive Search | Microsoft Docs Structure a semantic response - Azure Cognitive Search | Microsoft Docs The science behind semantic search： How AI from Bing is powering Azure Cognitive Search - Microsoft Research 簡単にですがデータを入れて試してみたので、どんな仕組みなのかどういう挙動なのかを紹介します。\nSemantic Searchとは？ 言語理解、セマンティック関連性などを提供する機能です。BingとMSリサーチにより開発されて、Azure Cognitive Searchに導入されました。 クエリの書き方を少し変更する必要がありますが、再インデックスや設定変更などは必要ないという仕組みになっています。\n検索クエリからコンテキストを読み取って、検索し、リランクするアルゴリズム(Semantic Ranker) 関連する一節を強調表示（Semantic Caption） クエリに対するセマンティック回答(Semantic Answer) スペルチェック機能 言語によって利用できる機能が異なります。\nSemantic Searchの利点は先ほどの紹介にも書きましたが、インデキシング時に特殊処理をする必要がないことかなと。 すでに登録してあるデータ（制限がありますが）でもすぐに試すことができます。\n仕組み https://docs.microsoft.com/ja-jp/azure/search/media/semantic-search-overview/semantic-query-architecture.png\nスペル修正機能 クエリパース スコアリング 上位50件に対してSemantic Rankerにより再評価（検索ヒットが50件以上の場合でも上位50件のみがリランクの対象） 言語表現モデルを利用 結果の要約として最適な部分をキャプションとして抽出。 クエリが質問形式の場合は一番よさそうな場所を回答として選択 1および4番目の処理が今回新しく使えるSemantic Searchの機能になります。スペルチェックは日本語がまだ対象外なので、4番目の機能について紹介します。\n利用できる環境と制限 冒頭でも書きましたが、Public Previewの段階です。実際に利用するにはリクエストページから申し込みが必要になっています。\n利用リクエスト時に利用するAzure Cognitive Searchのサービス名が必要になるので、あらかじめ起動しておかなければいけません。 また、利用できるリージョンが限定されているのでサービス起動時のリージョンには気を付けてください。\n利用できるリージョン 米国中北部、米国西部、米国西部 2、米国東部 2、北ヨーロッパ、西ヨーロッパ 利用できるTier セマンティック検索はStandardレベル スペルチェックはレベル制限なし 価格（セマンティック検索のみ） 7月初旬までは25万クエリで500ドル Analyzerの制限 Azure Cognitive Searchが提供する言語アナライザーが対象（Custom Analyzerでは利用不可） サービス起動後にプレビュープログラムを申請すると、利用できるようになるとメールが届きます。そこから利用ができるようになります。\n今回は日本語のWikipediaのデータをいれてどんな機能なのかを確認してみました。\nWikipediaのデータを入れて試してみた 日本語のWikipedia（あとで英語も入れました）を一部（10万件程度）登録してSemantic Search（主にRanker）の動きを確認してみました。\nデータの登録には自作ツールを利用。\nJSONデータ生成ツール：https://github.com/johtani/wiki-extractor-rs JSONデータ登録ツール：https://github.com/johtani/wiki-json-loader 日本語Wikipediaの2020年6月のデータ、英語Wikipediaの2021年6月のデータを利用。上記ツールで生成したもののうち約10万件をAzure Cognitive Searchに登録して動作確認をしました（英語のデータでJSONデータ生成ツールでバグがあるのですが修正していません。。。）。 また、クエリの実行にはVisual Studio CodeのREST Client拡張(どんなものかは以前のブログをご覧ください)を使いました。簡単にREST APIを呼び出せるのはすばらしい。\n日本語のWikipedia 日本語のWikipediaのデータを「96,344件」登録し実験しました。 スキーマは次のような形です（説明に必要なものだけ抽出してあります）。自然分が入っているtitle、contents、headingsの3つのフィールドを今回はSemantic Searchの対象にしてみるので、AnalyzerをLuceneベースの日本語Analyzerであるja.luceneを設定しました。\nフィールド名 : タイプ / Analyzer id : Edm.String / keyword categories : Collection(Edm.String) / keyword title : Edm.String / ja.lucene contents : Edm.String / ja.lucene headings : Edm.String / ja.lucene Analyzerに言語Analyzerを設定するくらいで、他の設定は特に必要ありません。\nクエリとデータの確認 デモの動画や説明のサンプルを見たところ英語で「Where was Alan Turing born?」や「What\u0026rsquo;s the capital of France?」のような自然文のクエリが出てきたので、次のようなクエリで試してみました。\nフランスの首都はどこですか？ 実際にパリのページがインデックスに存在していることは以下のクエリで確認しました。\nパリ：3047件 POST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;パリ\u0026#34;, \u0026#34;top\u0026#34;: 10, \u0026#34;searchFields\u0026#34;: \u0026#34;title, categories, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id, contents\u0026#34; } ※ここで{{host}}などはREST Client拡張で変数として定義したものです。\nhost : Azure Cognitive Searchのサービス名 index-name : インデックス名 api-key : 接続のためのAPIキー URLパラメータのapi-version=2020-06-30-PreviewがPreview機能を呼び出すための指定になっています。\n3047件の1件目が「パリ」のページで以下のようなWikipediaの文章をセクションごとに文字列としてページ全体を配列に入れてcontentsに登録してあります。\n\u0026#34;パリ（、巴里）は、フランス北部、イル＝ド＝フランス地域圏にある都市。フランスの首都であり、イル＝ド＝フランス地域圏の首府である。\\nフランス最大の都市であり、同国の政治、経済、文化などの中心である。ロンドンと共に欧州を代表する世界都市。行政上では、1コミューン単独で県を構成する特別市であり、ルーヴル美術館を含む1区を中心に、時計回りに20の行政区が並ぶ（エスカルゴと形容される）。\u0026#34;, このインデックスに対して「フランスの首都はどこですか？」というクエリを、セマンティック検索のクエリと通常のクエリの2パターンで検索をしてみました。\nこれまでのクエリ（セマンティックではない検索） まずは通常のクエリです。 searchがクエリ文字列、searchFieldsが検索対象フィールドになります。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;フランスの首都はどこですか？\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34; } クエリを実行するとヒット件数が'13996\u0026rsquo;件で、トップ5件のデータは次のようになりました。\n\u0026#34;@odata.count\u0026#34;: 13996, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 17.059355, \u0026#34;id\u0026#34;: \u0026#34;462\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;首都\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 16.086372, \u0026#34;id\u0026#34;: \u0026#34;21053\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;首都圏\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 15.059893, \u0026#34;id\u0026#34;: \u0026#34;71414\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;どこでもドア\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 14.086605, \u0026#34;id\u0026#34;: \u0026#34;51972\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;首都機能移転\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.996841, \u0026#34;id\u0026#34;: \u0026#34;3877\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;首都の一覧\u0026#34; }, 見るとわかりますが、「首都」「どこ」といった単語を含むデータが上位に入っています。「フランス」を含むデータは8件目と10件目に「フランス植民地帝国」、「ラ・フランス」といったデータが出てきます。\n{ \u0026#34;@search.score\u0026#34;: 12.705561, \u0026#34;id\u0026#34;: \u0026#34;129279\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランス植民地帝国\u0026#34; }, ... { \u0026#34;@search.score\u0026#34;: 12.036648, \u0026#34;id\u0026#34;: \u0026#34;3173\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ラ・フランス\u0026#34; }, 残念ながら望んでいる結果にはほど遠いかと。\nどんな検索になっているのでしょうか？まずは、クエリの解釈から。 デフォルトで、Azure Cognitive Searchはデフォルトでは、入力された文字列をtype=simple、mode=anyで検索します（クエリパラメータ参照）。 対象となるフィールドはsearchFieldsで今回は指定してあるので、これらのフィールドに対して、入力された文字列を渡してAnalyzerで単語分割し（今回はsimpleクエリ用の特殊文字が入っていないため文字列として扱われる）、 出てきた単語で（mode=anyだから）OR検索します。 ja.luceneのAnalyzerが出力する単語列がどんなものかは以下のリクエストを実行するとわかります。\nPOST https://{{host}}/indexes/{{index-name}}/analyze?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;analyzer\u0026#34;:\u0026#34;ja.lucene\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;フランスの首都はどこですか？\u0026#34; } 結果は以下の通りです。\n\u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;フランス\u0026#34;, \u0026#34;startOffset\u0026#34;: 0, \u0026#34;endOffset\u0026#34;: 4, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;首都\u0026#34;, \u0026#34;startOffset\u0026#34;: 5, \u0026#34;endOffset\u0026#34;: 7, \u0026#34;position\u0026#34;: 2 }, { \u0026#34;token\u0026#34;: \u0026#34;どこ\u0026#34;, \u0026#34;startOffset\u0026#34;: 8, \u0026#34;endOffset\u0026#34;: 10, \u0026#34;position\u0026#34;: 4 } ] これで、どのような単語が出てきているかがわかりました。 それぞれのフィールドでどのようなスコアになっているかまではわからないですが、検索結果には上記3つの単語のいずれかがsearchFieldsにヒットすれば出てきます。おそらく、ヒットした単語数が多い、短い文字列のフィールドがより高いスコアになるというような動きになっていると思われます（BM25になってるはず）。\nセマンティック検索 では、セマンティック検索のクエリに変更してみましょう。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;フランスの首都はどこですか？\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34;, \u0026#34;queryType\u0026#34;: \u0026#34;semantic\u0026#34;, \u0026#34;queryLanguage\u0026#34;: \u0026#34;ja-jp\u0026#34; } queryType、queryLanguageがセマンティック検索のクエリを実行するためのパラメータになります（公式ガイド参照）。 今回は日本語のデータであるため、日本語のモデルを利用するようにqueryLanguageを指定します（許可されていない文字列を渡すとエラーになる）。 この2つを追加するだけです。簡単ですね。\n結果は次のようになります（上位5件抜粋）。\n\u0026#34;@odata.count\u0026#34;: 13996, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 12.036648, \u0026#34;@search.rerankerScore\u0026#34;: 2.3456064984202385, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;ラ・フランス\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;ラ・フランス\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;3173\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ラ・フランス\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 11.144733, \u0026#34;@search.rerankerScore\u0026#34;: 2.3173404783010483, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;ラン (フランス)\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;ラン\u0026lt;/em\u0026gt; (\u0026lt;em\u0026gt;フランス)\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;108094\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ラン (フランス)\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 11.144793, \u0026#34;@search.rerankerScore\u0026#34;: 2.1937477812170982, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;ブレスト (フランス)\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;ブレスト\u0026lt;/em\u0026gt; (\u0026lt;em\u0026gt;フランス)\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;116154\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ブレスト (フランス)\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 10.199907, \u0026#34;@search.rerankerScore\u0026#34;: 2.1590753793716431, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;フランス・ハルス\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;フランス・ハルス\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;81566\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランス・ハルス\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 11.273148, \u0026#34;@search.rerankerScore\u0026#34;: 2.1434053033590317, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;バカロレア (フランス)\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;バカロレア\u0026lt;/em\u0026gt; (\u0026lt;em\u0026gt;フランス\u0026lt;/em\u0026gt;)\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;54514\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;バカロレア (フランス)\u0026#34; }, 検索結果数を見ると、通常のクエリと同じ値です。 これは、公式ドキュメントのセマンティック検索に説明があるように、 セマンティック検索が通常のクエリで実行した後の検索結果に対して、上位50件のデータだけに対してsemantic rankerによってスコアを再計算するという仕様のためです（ドキュメントからの推測）。\n実際に検索結果の50件目、51件目は次のようになっていました。50件目までのデータには@search.rerankerScoreというスコア（と@search.captions）が追加されています。 51件目のデータについては、前の通常のクエリの51件目のデータと同じデータでした。\n{ \u0026#34;@search.score\u0026#34;: 10.909212, \u0026#34;@search.rerankerScore\u0026#34;: 0.07321979058906436, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;首都高速埼玉大宮線\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;67667\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;首都高速埼玉大宮線\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 10.049902, \u0026#34;id\u0026#34;: \u0026#34;68569\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;スタッド・ド・フランス\u0026#34; }, 上位5件のデータに戻ります。 これらは、通常のクエリとは異なる結果となりました。 見ると@search.captionsというところにハイライトされた項目が表示されています。 検索クエリをもとにそれっぽい部分がキャプションという形で返ってくる仕組みです。\n結果を見るとわかりますが、残念ながら「パリ」のページは返ってきませんでした。 もともと通常のクエリを実行したときの「326」番目の結果として返ってきているため、セマンティック検索の対象とはならなかったためです。 ただ、「首都」「どこ」といった単語よりも「フランス」に関するドキュメントが通常の検索よりも上位に来ています。 クエリに存在する単語で「フランス」がより重要であると判断されているようです。\nSemantic Rankerに処理させてみる ちなみに、今回登録したデータにはWikipediaのカテゴリも登録してあります。 「ヨーロッパの首都」というカテゴリで絞り込んでから検索してみるとどうなるかもやってみました。 filterのパラメータが絞り込み条件です。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;フランスの首都はどこですか？\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34;, \u0026#34;queryType\u0026#34;: \u0026#34;semantic\u0026#34;, \u0026#34;queryLanguage\u0026#34;: \u0026#34;ja-jp\u0026#34;, \u0026#34;filter\u0026#34;: \u0026#34;search.ismatch(\u0026#39;ヨーロッパの首都\u0026#39;, \u0026#39;categories\u0026#39;)\u0026#34; } 結果は次の通りです。カテゴリで絞り込みをしているので検索結果数は39件となります。このため、すべてのデータがSemantic Rankerの対象です。 ですが、「パリ」のページは11件目に出てきました。\n\u0026#34;@odata.count\u0026#34;: 39, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 3.8405614, \u0026#34;@search.rerankerScore\u0026#34;: 2.0472740978002548, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;ウィーン\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;9465\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ウィーン\u0026#34; }, ... { \u0026#34;@search.score\u0026#34;: 4.8915977, \u0026#34;@search.rerankerScore\u0026#34;: 1.8480307757854462, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;レイキャヴィーク\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;レイキャヴィーク\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;112253\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;レイキャヴィーク\u0026#34; }, ... { \u0026#34;@search.score\u0026#34;: 7.277628, \u0026#34;@search.rerankerScore\u0026#34;: 1.7982495501637459, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;パリ\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;パリ\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;31\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;パリ\u0026#34; }, キャプションは入力された単語だけではなく、クエリが持っている単語をもとにした何かしらの基準（おそらく言語モデルで近い単語？）で選択されていると思われます。首都というカテゴリーで絞り込んでしまったので、ヒットした文章が似たようなものが多くなったせいか、残念ながらそこまでSemantic Rankerが意図を汲み取るところまでは行きませんでした。\nフランスの歴史 視点を変えてみましょう。質問そのものの答えではなく、クエリの意図に近いものが出てくるかを見てみましょう。 ここまでのクエリでフランスに関するクエリを投げていました。今回のインデックスに「フランスの歴史」で検索すると「30820」件のドキュメントがヒットし、上位にはフランスには関係ない「歴史」のページや「フランス」の文学、都市など「フランスの歴史」とは少し離れた意味のものが上位に来ています。\n\u0026#34;@odata.count\u0026#34;: 30820, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 12.888079, \u0026#34;id\u0026#34;: \u0026#34;17875\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;スコットランドの歴史\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.718105, \u0026#34;id\u0026#34;: \u0026#34;10665\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;世界の歴史\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.701981, \u0026#34;id\u0026#34;: \u0026#34;31397\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ベトナムの歴史\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.579847, \u0026#34;id\u0026#34;: \u0026#34;22433\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランス文学\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.524254, \u0026#34;id\u0026#34;: \u0026#34;34667\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランスの国旗\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.52136, \u0026#34;id\u0026#34;: \u0026#34;108094\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ラン (フランス)\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.41088, \u0026#34;id\u0026#34;: \u0026#34;20717\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;歴史小説\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.388911, \u0026#34;id\u0026#34;: \u0026#34;56229\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;演劇の歴史\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.343941, \u0026#34;id\u0026#34;: \u0026#34;39669\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;イギリスの歴史\u0026#34; }, このクエリをセマンティッククエリで検索すると次のようになりました。\n\u0026#34;@odata.count\u0026#34;: 30820, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 12.274498, \u0026#34;@search.rerankerScore\u0026#34;: 1.482184374704957, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;自由フランス\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;自由フランス\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;96475\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;自由フランス\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 11.446766, \u0026#34;@search.rerankerScore\u0026#34;: 1.3535655084997416, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;フランスの地域圏\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;フランスの地域圏\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;51845\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランスの地域圏\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 10.926437, \u0026#34;@search.rerankerScore\u0026#34;: 1.3261859538033605, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;フランス第一帝政\u0026#34;, \u0026#34;highlights\u0026#34;: \u0026#34;\u0026lt;em\u0026gt;フランス第一帝政\u0026lt;/em\u0026gt;\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;57573\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;フランス第一帝政\u0026#34; }, 上位には「フランスの歴史」に関連しそうなタイトルが上がってきています。 また、先ほど「歴史」という単語でヒットして上位に来ていた「スコットランドの歴史」は@search.rerankerScoreの値が低くなっていました（31件目に出現）。\n{ \u0026#34;@search.score\u0026#34;: 12.888079, \u0026#34;@search.rerankerScore\u0026#34;: 0.42768346797674894, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;スコットランドの歴史\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;17875\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;スコットランドの歴史\u0026#34; }, 考察 日本語のWikipediaを約10万件入れたインデックスでセマンティック検索を試してみました。 デモや説明などでクエリが自然文の質問だったこともあり、質問の回答になりそうなページが上に来るかと期待しましたが、期待しすぎました。\nこれは、Azure Cognitive Searchのセマンティック検索の仕組みを考えると納得のいくものです。 説明を読んだ時にも感じたのですが、入力された文字列でまず検索をし、上位50件をセマンティック検索の対象としています。\nですので、そもそもクエリの文章に出てくる単語が含まれたデータだけが対象となります。 このため、クエリに出てこない単語のみで構成されているものは残念ながら対象とできません。 また、上位50件だけがSemantic Rankerの対象となっているため、検索にヒットしたとしても上位に食い込まなければ言語モデルによるランキングの対象にもなりません。 セマンティック検索といっても、残念ながらドキュメントに出てこない単語（似た単語、質問に対するそのものの回答）まで読み取る機能はありません。\nただ、「フランスの歴史」の検索で見たようにそれぞれの単語だけで検索をしていた場合とは異なり、 クエリの意味に沿ったスコアづけにより、通常の検索よりも意図したものに近いデータが出ていることが確認できました。 複数の単語で構成されるクエリの場合に、単語だけでスコアを計算した場合よりもよさそうな結果が上位に出てくることがわかりました。\nただし、重要なのは「上位50件」までしかSemantic Rankerの対象にはならない点です。\n英語のWikipedia セマンティックは英語対応が一番最初にリリースされているので、英語のWikipediaについてもデータを登録してみました。\n英語のWikipediaのデータを「111,649件」登録しました。 スキーマは以下の通り（今回の調査に利用していないものは省略）です。日本語と異なる点はAnalyzerがen.luceneになっていることぐらいです。\nフィールド名 : タイプ / Analyzer id : Edm.String / keyword categories : Collection(Edm.String) / keyword title : Edm.String / en.lucene contents : Edm.String / en.lucene headings : Edm.String / en.lucene クエリとデータの確認 日本語同様に首都に関する質問形式にしてみました。\nWhat\u0026rsquo;s the capital of Italy? 実際にRomeのページがインデックスに存在していることは以下のクエリで確認済みです。\nRome：2302件\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;Rome\u0026#34;, \u0026#34;top\u0026#34;: 10, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id, contents\u0026#34; } 以下のようなWikipediaの文章をセクションごとに文字列としてページ全体を配列に入れてcontentsに登録してあります（これも日本語と同じです）。\n\u0026#34;\u0026#34;\\n\\nRome (Italian and Latin: Roma ) is the capital city and a special comune of Italy (named Comune di Roma Capitale), as well as the capital of the Lazio region. The city has been a major human settlement for almost three millennia. With 2,860,009 residents in , it is also the country\u0026#39;s most populated comune...\u0026#34;, このデータ群に対して「What\u0026rsquo;s the capital of Italy?」というクエリを、Semantic Searchのクエリと通常のクエリの2パターンで検索をしてみる。\nこれまでのクエリ（セマンティックではない検索） まずは、Semantic Searchではないクエリです。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;What\u0026#39;s the capital of Italy?\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34; } ヒット件数は18049件で、トップ5件は次のような形です。\n\u0026#34;@odata.count\u0026#34;: 18049, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 17.870815, \u0026#34;id\u0026#34;: \u0026#34;14532\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Italy\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 16.596167, \u0026#34;id\u0026#34;: \u0026#34;14702\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Economy of Italy\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 16.180624, \u0026#34;id\u0026#34;: \u0026#34;183878\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Louis II of Italy\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 15.917025, \u0026#34;id\u0026#34;: \u0026#34;29665\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;State capitalism\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 15.88901, \u0026#34;id\u0026#34;: \u0026#34;215741\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Capitalization\u0026#34; }, 日本語の場合よりもItalyに関連するものが上位に多く含まれます。 ただ、Rome自体のページは上位50件には出てきていませんでした。 また、capitalとは意味の異なるcapitalizationやcapitalismが上位に来ています。 日本語の場合と同様にクエリがどのように解釈されているのか？も見てみます。\nPOST https://{{host}}/indexes/{{index-name}}/analyze?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;analyzer\u0026#34;:\u0026#34;en.lucene\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;What\u0026#39;s the capital of Italy?\u0026#34; } 結果は以下の通りです。\n\u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;what\u0026#34;, \u0026#34;startOffset\u0026#34;: 0, \u0026#34;endOffset\u0026#34;: 6, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;capit\u0026#34;, \u0026#34;startOffset\u0026#34;: 11, \u0026#34;endOffset\u0026#34;: 18, \u0026#34;position\u0026#34;: 2 }, { \u0026#34;token\u0026#34;: \u0026#34;itali\u0026#34;, \u0026#34;startOffset\u0026#34;: 22, \u0026#34;endOffset\u0026#34;: 27, \u0026#34;position\u0026#34;: 4 } ] 日本語とあまり変わってはいません。ただ、単語が入力されたものとは少し変わっています。 これは、en.luceneの処理で、stemmingが行われているためだと思われます。たとえば、「capital」の場合、Stemmingにより「capital」「capitalize」などの単語が元になりますが、動詞、名詞などの違いなく検索できるようにするためにこのようなStemmingの処理が行われます。 ということで、これらの単語を含むドキュメントがヒットしています。Italyが一番上に来ているのはItalyという単語が多く含まれるからのようです。\nSemantic Searchクエリ では、Semantic Searchのクエリに変更してみましょう。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;What\u0026#39;s the capital of Italy?\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34;, \u0026#34;queryType\u0026#34;: \u0026#34;semantic\u0026#34;, \u0026#34;queryLanguage\u0026#34;: \u0026#34;en_us\u0026#34; } queryType、queryLanguageがsemantic searchのクエリを実行するためのパラメータになります（公式ガイド参照）。 今回は英語のデータであるため、英語のモデルを利用するようにqueryLanguageを指定します（許可されていない文字列を渡すとエラーになる）。\n結果は次のようになります（上位5件抜粋）。\n\u0026#34;@odata.count\u0026#34;: 18049, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 17.870815, \u0026#34;@search.rerankerScore\u0026#34;: 1.9688458815217018, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Italy\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;14532\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Italy\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 14.239678, \u0026#34;@search.rerankerScore\u0026#34;: 1.9419755563139915, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Capital city\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;181337\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Capital city\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 10.181764, \u0026#34;@search.rerankerScore\u0026#34;: 1.8902588561177254, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Lepontii\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;325133\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Lepontii\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 10.865718, \u0026#34;@search.rerankerScore\u0026#34;: 1.875102698802948, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;ItalY\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;14482\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;ItalY\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 11.689348, \u0026#34;@search.rerankerScore\u0026#34;: 1.8201303631067276, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Savoy\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;27885\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Savoy\u0026#34; }, 日本語で見てきたように、検索結果数を見ると、通常のクエリと同じ値で、残念ながら50件までにRomeは入っていないため、Semantic Rankerによるブーストもかかりませんでした。 ただし、「Capitalization」や「State capitalism」といった別の意味（地理に関するものではない単語）のものが上位に出てこなくなっています。 これは、capitalという単語が地理に関する意味を持っていると判断された結果のように見えます。 Capitalizationの@search.rerankerScoreは上位のスコアに比べて小さいものとなっています。\n{ \u0026#34;@search.score\u0026#34;: 15.88901, \u0026#34;@search.rerankerScore\u0026#34;: 0.93921028636395931, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Capitalization\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;215741\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Capitalization\u0026#34; }, What\u0026rsquo;s the capital of Finland? 上位50件以内(20件目)に「Helsinki」のページが出てくるクエリでセマンティック検索をしてみました。\nPOST https://{{host}}/indexes/{{index-name}}/docs/search?api-version=2020-06-30-Preview Content-Type: application/json api-key: {{api-key}} { \u0026#34;top\u0026#34;: 100, \u0026#34;count\u0026#34;: true, \u0026#34;search\u0026#34;: \u0026#34;What\u0026#39;s the captial of Finland?\u0026#34;, \u0026#34;searchFields\u0026#34;: \u0026#34;title, contents\u0026#34;, \u0026#34;select\u0026#34;: \u0026#34;title, id\u0026#34;, \u0026#34;queryType\u0026#34;: \u0026#34;semantic\u0026#34;, \u0026#34;queryLanguage\u0026#34;: \u0026#34;en-us\u0026#34; } 結果としては、2件目にHelsinkiが返ってきていたので、Semantic Rankerがによる並び替えがうまくいきました。 （下記の結果は上位3件を抜粋したものです）。\n\u0026#34;@odata.count\u0026#34;: 16673, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.score\u0026#34;: 14.026371, \u0026#34;@search.rerankerScore\u0026#34;: 2.42378556355834, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Vanaja (Finland)\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;7132102\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Vanaja (Finland)\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 12.434971, \u0026#34;@search.rerankerScore\u0026#34;: 2.383675143122673, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Helsinki\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;13696\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Helsinki\u0026#34; }, { \u0026#34;@search.score\u0026#34;: 13.380153, \u0026#34;@search.rerankerScore\u0026#34;: 2.2026549801230431, \u0026#34;@search.captions\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;Rauma, Finland\u0026#34;, \u0026#34;highlights\u0026#34;: null } ], \u0026#34;id\u0026#34;: \u0026#34;178635\u0026#34;, \u0026#34;title\u0026#34;: \u0026#34;Rauma, Finland\u0026#34; }, 考察 今回の英語のクエリではSemantic Rankerがある程度の役割をはたしていそうだということはわかりました。 Capitalがいくつもの意味を持っていることもあり、文章をもとにより意味の近いドキュメントが上位に来たということです。 ただ、英語の場合も基本的には上位50件以内のデータに対して処理が行われるので上位50件以内にデータが入らなければうまくいかないようです。\nまとめ Azure Cognitive Searchの新機能であるセマンティック検索について調べてみました。 まだPublic Previewですが、簡単に使えるような仕組み（データの再登録なし、クエリでパラメータを追加するだけ）が用意されているのは便利でした。 ただ、最初に想像していたもの（私の早とちりもありますが）ほどのセマンティック検索とは行きませんでした。 似たような言葉の意味を持ったものを探してくれたり、答えそのもののページのスコアがすごく高くなるといったものではありませんでした。\n仕組み上、クエリに含まれる単語で検索し、上位50件以内のデータだけが対象になる(残念ながら現時点ではこの件数の変更はできません。)ため、これまでの検索とは劇的に変化するものではないことはわかりました（銀の弾丸はないんですけどね）。\nある程度の挙動をわかっていれば、Wikipediaのようなデータでもそれなりの結果は取得できそうだということはわかりました。\n「言語モデル」でクエリとヒットしたデータをもとにスコア計算をし直しているようですが、この部分がどのようなデータ・クエリだと有効活用できるのか？というのをもう少しいろいろな角度で試してみる必要がある気がします（適材適所が何なのか？）。 あとは、上位50件までが対象なので、それ以上の件数のデータの並びに関してはこれまでと同様の結果となる点は注意しないといけません。 また、今回試していないほかの機能（スペルチェック、Semantic Answerなど）にメリットがあるのかもしれません。\nざっくりですがセマンティック検索について調べてみました。 こんなデータだとどうなの？ここの考え方が間違ってるのでは？などの指摘がありましたら、コメント欄またはTwitter（@johtani）でコメントを頂けたらと。\n","date":1625130583,"dir":"post/2021/","id":"43caef5d41c4e74826e4a8d82088739d","lang":"ja","lastmod":1625130583,"permalink":"https://blog.johtani.info/blog/2021/07/01/semantic-search-in-azure-cognitive-search/","publishdate":"2021-07-01T18:09:43+09:00","summary":"Azure Cognitive Searchで新機能「Semantic Search（セマンティック検索）」という機能の日本語対応が発表されました。 実際にはPublic P","tags":["azure search"],"title":"Azure Cognitive Searchの新機能、Semantic Searchを試してみた"},{"contents":"Sofle v2を長らく使っていましたが、コンパクトなのもやっぱりいいよなぁというときにKochi KeyboardからLunakey Miniが発売していました。 小指のあたりの傾斜が使いやすいかも？ということで、組み立ててみました。\nもちろん購入はKochi Keyboardさんからです（購入はこちらから）。\nLunakey Miniビルドガイド 作者のYoichiroさんが公開しているビルドガイドが詳細まで書かれています。 こちらをまずは参照してください。\nLunakey Mini ビルドガイド (Rev.4以降) ビルドログ（主にツイート） 私の組み立てについては、Twitterでツイートしていたものがありますので、そちらを貼っておきます。 ちなみに、ツイートしていて躓いているときに、作者のYoichiroさんからたびたびコメントをいただきました。 ありがとうございました！！\n間にいくつかコメントを差し込んでいます。\n結局両方のダイオードつけてしまいました。今日はここまで pic.twitter.com/3qLI6EpfXB\n\u0026mdash; Jun Ohtani (@johtani) April 12, 2021 ハンダはつけた pic.twitter.com/ySE9SA3gZn\n\u0026mdash; Jun Ohtani (@johtani) April 13, 2021 コンスルー問題 左手じゃん、T。Tのダイオード浮いてた。右手も一回全部見直すか\n\u0026mdash; Jun Ohtani (@johtani) April 13, 2021 ここで問題が発覚。右手（ツイートではぼけていて、左手と書いています）についてはダイオードが1か所浮いていただけなので、はんだ付けですぐ直りました。 左手側が大問題です。そもそも右手につけたProMicroへの書き込みができませんでした。 キーボードによっては、ダイオードなどを付ける前からまず、リセットボタンを付けて、ProMicroを指して書き込みをする場合もあります。 ただ、その書き込みができない。 （ちなみにこのタイミングでテスターをつけっぱなしにしていたのが発覚し、9V電池切れのため翌日に持ち越した。。。）\nさて、デバッグのお時間です pic.twitter.com/CaEOv4E5Bg\n\u0026mdash; Jun Ohtani (@johtani) April 14, 2021 ただ、ProMicro刺した状態で、リセットボタン、リセットボタンの足をショートさせても書き込みはできず、ProMicroのGndとResetの足のショートでは書き込みができる。\n\u0026mdash; Jun Ohtani (@johtani) April 14, 2021 テスターで調べてみたところ、リセットボタンとProMicroがうまく通電していません。\nだいぶ進んだけど、Eの列がおかしいなぁ。さて、どこの接触だ？ pic.twitter.com/5tci12Vk05\n\u0026mdash; Jun Ohtani (@johtani) April 14, 2021 どうも、左手の基盤のProMicroの足の穴がコンスルーとの接触が悪いみたいでした。 コンスルーの足を無理やりまげて（3個のコンスルーの足を折りました。。。）、通電できるようにして解決（結局あとでいくつかの足についてははんだ付けしました）。\n終わった。LEDの予備はんだまでやってからおしまいにしよ\n\u0026mdash; Jun Ohtani (@johtani) April 16, 2021 LED実装 鬼門の表面実装ですが、LEDを1個破損するだけで乗り切りました。ちょっと色はおかしかったですが、これはおそらくProMicroの足のせい。\n一個逆につけてしまい、お亡くなりになりましたが、まぁ、良いかな。まずは右手 pic.twitter.com/zldu6fRsXR\n\u0026mdash; Jun Ohtani (@johtani) April 18, 2021 ソケットの実装x2 ロープロファイル（Kailh choc v1）のキースイッチも試してみたいので、MXと両方のソケットをはんだ付けしました。 両方利用できるのは便利ですね。はんだ付けも楽しいし。\nソケットを片手だけ(両方のソケットつけるのでまだ、1/4) pic.twitter.com/7XFRDx0D0I\n\u0026mdash; Jun Ohtani (@johtani) April 18, 2021 キースイッチ設置 親指以外にはKailh Box Silentのピンク軸（Kochi Keyboardから）、親指にはKailh Input Club Hako Violet（AliExpressで購入したもの。リンクは遊舎工房のもの）をつけました。 どちらもそれほどぶれもないものです。Silent ピンクはリニアで静かでそれほど力がいらないスイッチになっています。 親指はタクタイルで小気味のいい音が気に入っています。Sofleもこのキースイッチになってます。\n残りのソケットつけて、キースイッチも設置して、動確してボトムプレートも装着。残りはキーキャップ。 pic.twitter.com/hGc1TtI6fu\n\u0026mdash; Jun Ohtani (@johtani) April 25, 2021 キーキャップ＋キーマップ お試しにXDAのキーキャップをはめてみたのですが、キーの境目がわかりにくく、タイプミスが多かったです。 その後のツイートにあるようにOEMに切り替えています。\nキーマップについては、Lunakey Miniの作者のYoichiroさんが作ったRemapというブラウザベースでキーマップの書き換えができるツールで楽々変更ができました。JISキーまで対応しているのでJISベースでキーマップを作成している私にはうってつけでした。 Remapの利用方法についてはサリチル酸さんのブログが詳しく書いてあります（本当に頭が下がります）。\nRemap使ってキーマップいじったら、すごく楽だった。\n\u0026mdash; Jun Ohtani (@johtani) April 26, 2021 BLE + LPME-IO化 ここまでで、USB接続で動作はしていたのですが、Sofle同様に3台をBluetoothで切り替えながら使いたかったので、 Corne Light v2につけていたBLE+LPME-IO(Corneの実装などは前のブログを参照)を抜き取って、Lunakey Miniに移植してみました。\nBLE ProMicro化は作者の方のブログで行われていたので、LPME-IO対応も何とかなるだろうと。\nBLE+LPMEに変えた。後でブログ書こう pic.twitter.com/mGePN52v6k\n\u0026mdash; Jun Ohtani (@johtani) April 29, 2021 LPME-IOへの対応はCorneとSofleの時に行なったこともあり、なんとなくあたりがついていました。 流れとしては、以下の通りです。\nBLE Micro Pro用の設定ファイルを作成 BLE Micro Proのサイトの「キーボードの設定ファイルを編集する」のコマンドでコンフィグファイルを生成 LPME-IOのジャンパをはんだでブリッジ 1.で生成したコンフィグから、Corne Lightと同じ個所のジャンプをすれば良いとわかったので今回はスキップ TRRSのI2C対応 Corne LightのLPME-IO対応の時と同様にSDAとSCLをTRRSの足にショートカット ただ、今回右手側は、下記ツイートのようにOLEDの足からTRRSの足にショートカットしました。Corneの基盤を見ていた時にこれでも行けそうだな？と思っていたので、試してみた次第です。ちなみに、左手はCorneの時と同じPro Microから長い銅線を引っ張っています（電池基盤があったので、外すのがめんどくさかったため）。 BLE Micro Proにファームウェア書き込み BLE Micro Proのサイトの手順に従います。 設定ファイルには1.で出力されているLPME用のファイルを使用。 といった感じです。キーマップが設定されていないので、Remapで設定しなおしました。 Remapは、キーマップをPDFで出力する機能までついていて、すごくいいですね。サイコー\nあと、足。 pic.twitter.com/W0Wpf5k5SE\n\u0026mdash; Jun Ohtani (@johtani) April 29, 2021 傾斜がつくように奥側に高さを出すためのゴム足を貼り付けました。 あとは、3台のPCにBluetoothで接続すれば終了です。 （AD_WO_Lのキーを利用して追加していくのを毎回忘れる。。。）\n疑問点 ちょっとだけ疑問点がありますが、時間があればそのうち調べるかな。\nRemapはクラウドに設定ファイルをセーブできるけど、json形式で手元にダウンロードしたりはできないのかなぁ？ LEDは有線じゃないと点かないみたいだけど、音はどうなんだろう？ 音が出せそうなら、Bluetoothの接続切り替えするときに音の出方を変えるとかをやってみたいなぁ。 まとめ ということで、Lunakey Miniを組み立てて、BLE+LPME-IO対応してみました。 はんだ付けはだいぶ慣れてきましたし、今回もトラブルがあったおかげでテスターを利用して、どのあたりがおかしいかという調査をするのも慣れてきました。 あとは、キーの配置の違いを体感して、どれが自分に合ってるかなぁ？というのを試したり仕様と思います。 ロープロファイルも試してみようかな。\nあ。もちろん、このブログは組み立ててBluetoothで接続したLunakey Mini Rev5、Kailh Box Silentピンク軸＋Input Club Hako Violetで書きました！！久々に数字列がないので記号入力とかがちょっとバタバタしましたｗ\n","date":1619709972,"dir":"post/2021/","id":"f4baa43cc7ca712d83b99a794c4e2dbd","lang":"ja","lastmod":1619709972,"permalink":"https://blog.johtani.info/blog/2021/04/30/build-lunakey-mini-ble/","publishdate":"2021-04-30T00:26:12+09:00","summary":"Sofle v2を長らく使っていましたが、コンパクトなのもやっぱりいいよなぁというときにKochi KeyboardからLunakey Miniが発売して","tags":["DIYキーボード","misc"],"title":"Lunakey Miniを組み立てて、BLE+LPME-IO化してみた #DIYキーボード"},{"contents":"みなさんは、スライドの作成には何を使っていますか？ Keynote？Powerpoint？Google Slides？\n私は、Macでスライドを作るときは前職ではテンプレートもあったのでKeynoteでしたが、ちょっとしたものはMarkdownベースのDecksetを利用していました（買い切りタイプの有料ソフト）。\nフリーランスになってもこちらを利用していたのですが、Windows環境に切り替えたので使えなくなってしまいました。 一度はGoogle Slidesで作ったのですが（第39回Es勉強会スライド）、既存の資産を流用したくなりどうしたものかと悩んでい(ツイートし)たら。\nMacの頃はDecksetってアプリでMarkdownで書いてたんだけど、Winに移動したのでこのタイミングでGoogle Slidesにでもしようかなと考えてるところ。Markdownでスライド作るのほかになんかあるか探すほうがいいかなぁ？\n\u0026mdash; Jun Ohtani (@johtani) March 18, 2021 僕はこれ使ってますhttps://t.co/sFaAmKZY6V\n\u0026mdash; miyake | ZEN (@kazuyukimiyake) March 18, 2021 ということで、利用してみようかなとなりました。\nMarpとは？ Markdownでプレゼンテーションのスライドを作ることができるOSS?になります。\nMarp公式サイト といっても、これ自体を使わなくても、VS Code上でプレビューしたりHTML形式で動作するスライドを吐き出すことが可能です。 なので、VS Code用のプラグインを利用しています。\nサンプル この間利用したスライドはこんな感じのMarkdownになってます。 ---でページを区切りつつ、記述していく形です。\n--- marp: true theme: poster --- \u0026lt;!-- _class: big-center --\u0026gt; # 本当にその検索は\u0026lt;br/\u0026gt;自分が想像している検索に\u0026lt;br/\u0026gt;なってますか？ \u0026lt;br/\u0026gt; \u0026lt;br/\u0026gt; \u0026gt; 2021/03 \u0026gt; Jun Ohtani / @johtani --- ![bg right:40% 40%](johtani_face.jpg) # 自己紹介 - フリーランスエンジニア - 検索技術勉強会主催者 - Apache Solr入門(第2版まで)や データ分析基盤構築入門の著者の一人 --- プレビューで見るとこんな感じです。\nプラグイン Marp for VS Code プラグインをインストールするのも簡単ですよね。 マーケットプレイスからインストールすれば完了です。\n機能については上記のページにあるように、プレビューとスライドの出力です。 プレビューでは、Markdownのプレビューみたいな形で、スライドが表示できます。\n先日この機能を利用して作成して、HTMLで出力して利用しました。 PDFとかPPTX出も出せるようなので、今後試してみようかなと。\nDecksetのスライドとの違い ページの区切りなども同じだったので、大筋ではそれほど違いはありませんでした。 ただ、画像周りとスタイルの設定は細かく修正をしました。\n変更した点としては、以下のようなものがあります。\nヘッダ部分の変更 上のサンプルにありますが、marp: trueを含む部分がMarp独自の記述です。 ページごとのちょっとした変更 ページごとにスタイルの変更ができるみたいで（Decksetではできなかったはず？）、タイトルページのスタイルを変えてあります。 画像の指定 画像の読み込み自体は違いはないのですが、画像の配置についての指定方法は カスタムテーマ用CSSの作成 デフォルトではなく、Decksetで用意されているような感じのスタイルに変更してみてます。 カスタムテーマはCSSで設定できるので、CSSファイルを用意して、VS Codeの拡張機能の設定からファイルパスを指定する形です。\nということで、当面はMarpでスライドを作っていくことになるかと思います。 まぁ、ただ、スライドを作るいこと自体が減ってきてはいるのですが。 ほかの配色を試したり、ヘッダフッタとかも試してみるのもいいかもな。\n気が向いたら、CSSをどこかにアップロードするかもです。\n※今回のブログはGateronサイレントクリア軸をルブしてみた、Corne Light v2で最後の数行を書いてみました。 キースイッチだけだとこすれる音が減った気がしてましたが、キーキャップを付けたら少しこすれる音が気になる感じです。\n","date":1617615911,"dir":"post/2021/","id":"f41d4fde94cbd7bbd28808dc080a2019","lang":"ja","lastmod":1617615911,"permalink":"https://blog.johtani.info/blog/2021/04/05/intro-marp/","publishdate":"2021-04-05T18:45:11+09:00","summary":"みなさんは、スライドの作成には何を使っていますか？ Keynote？Powerpoint？Google Slides？ 私は、Macでスライドを作","tags":["勉強会"],"title":"スライド作成の環境をMarpにしてみた"},{"contents":"新型コロナウィルスの影響もあり、オフラインで集まって勉強会も開催できなくなっています。 検索技術勉強会も、もう1年以上開催できていないです。\nスピーカーの人にオンラインでしゃべってもらうのもありだとは思うのですが、 懇親会とセットでその価値があったかもなぁと思うところもあり、オンラインでの開催に乗り気になれないまま時間がたってしまいました。 (配信周りを調べるのがめんどくさいなぁというのもあったかも（反省）)\nそんな中、takuya-aさんと話をしていて、エンジニア同士のゆるいつながりができる場所が欲しいですねぇということに。\nはー、検索技術勉強会、オフラインでできないまま１年以上たってしまったのか。オンライン勉強会とかはスピーカーの人の負担とかもあるし、Discordみたいなオープンな場だけ用意してみるのありかなぁ？ただ、活発に話がされるのかどうかわからんし、ROMな人ばかりだとアレなんだけどなぁ。\n\u0026mdash; Jun Ohtani (@johtani) March 30, 2021 そこからの、このツイートです。 ちらほらと興味のありそうな人が出てきたねという話をしていたら、Slackのワークスペースが出来上がってましたｗ\n検索技術に関する情報交換を目的とした Slack を立ち上げました！こちらの招待リンクからご参加ください。 https://t.co/Tca70vuMff\n\u0026mdash; takuya-a (@takuya_b) March 31, 2021 ありがとう、takuya-aさん！\nということで、検索周りでわいわいできる場になればいいなぁと。 盛り上がってくれば、オンラインでの勉強会とかもありかもしれないですね！ 興味のある方は、上記ツイート内のリンクからご参加下さい！！\n","date":1617200894,"dir":"post/2021/","id":"ce426b7f3190c8a4a47d45ac799e91a4","lang":"ja","lastmod":1617200894,"permalink":"https://blog.johtani.info/blog/2021/03/31/search-tech-jp-slack/","publishdate":"2021-03-31T23:28:14+09:00","summary":"新型コロナウィルスの影響もあり、オフラインで集まって勉強会も開催できなくなっています。 検索技術勉強会も、もう1年以上開催できていないです。 ス","tags":["勉強会"],"title":"検索技術に関する情報交換を目的としたSlackができました！"},{"contents":"Azure Cognitive SearchにはOData式という書式で条件が書ける仕組みがあります。 ODataは検索条件（$filter）やソート条件（$orderby）、取得する項目名の指定（$select）です。\n私は、Luceneの構文に慣れているので、普通のsearchパラメータを利用しようとします。 が、OData式として特殊な書き方がいくつかあるようなのでこちらの利用方法も調べてみました。 その時、N-Gram（よくやるのはN=2）で陥る問題の話もあるのでこちらについても言及します。\nOData式で検索 次のような3件のドキュメント(フィールド名はbodyとします)をN-Gramで登録していたとします。\nミルクティを飲みたいです。 マティーニはカクテルですが、ミルクセーキは？ 風呂上がりのミルクは最高です。 この時、OData式でミルクティという単語で検索してみましょう。\n検索条件は$filterで指定します。 フルテキスト検索用に関数が用意されており、こちらに単語を指定します。\n$filter=search.ismatchscoring(\u0026#39;ミルクティ\u0026#39;) こんな感じ。フィールドの指定がない場合、対象のフィールドは検索可能なフィールドすべてが検索対象になります（公式ガイドのクエリパラメータのqueryTypeに説明あり）。\nでは、実行してみましょう。で返ってくるのは？1だけかな？と思う人が多いかもしれません。 が、結果は3件とも帰ってきます。\n問題点は？ では問題点はどこでしょう？ ismatchscoringのオプションなどを見る前に、転置インデックスを用いた検索エンジンの挙動をおさらいしましょう。 転置インデックスの仕組みを理解することで、なぜそんな挙動になるのか？というのがわかりやすくなります。 おさらいにはElasticsearchをベースに話をしますが、Azure Cognitive Searchでも同じような挙動になります。\n転置インデックスとトークナイザー（アナライザー）の関係（おさらい） 昨年、オンラインで開催されたOSC広島で発表した資料（録画あり）でもざっくりと説明しています。\nView 本当にその検索は自分が想像している検索になってますか？ on Notist.\nざっくりですが、おさらいです。\n検索エンジンでは、入力された文章を、ある規則（アナライザー）で単語に分割し、その単語ごとにどのドキュメントに出現したのか？というリストが作られます。 このリストが転置インデックスです。書籍の後ろにある索引を想像するとどんなものかがわかりやすいです。 単語に対してその単語が出てくるページ番号がわかるという仕組みです（下図は本の索引の一例）。\n書籍の索引は著者や編集の方により厳選された単語のみが採用されています。 が、検索エンジンでは文章を単語に区切る機能が存在します。 この「ある規則」で単語を区切る仕組みが「アナライザー（トークナイザー）」と呼ばれる機能です。 例えば英語用のアナライザーに英語の文章が入力されたとき、文章はこのように単語に区切られたもの（単語列）を出力します（下図）。\n今回はNGramの話なので、NGramのAnalyzerを利用してみるとこんな感じになります。\n実際に出来上がる転置インデックスは次のような形になります。 検索の仕組み（おさらい） 出来上がっている転置インデックスに対して検索をする場合、入力文字列（検索条件）に対して、転置インデックス作成時と同様にAnalyzerが動作します。 処理としては、\nクエリのパース フィールドのAnalyzerで処理 転置インデックスを検索 という形です。 例えばこんな感じ。\n同じAnalyzerの処理が入ることで、転置インデックスに採用されているのと同じ単語が出てくるため、検索がきちんとできるということになります。\n英語と日本語（NGram）の違い 英語と日本語の違いは、スペースの意味になります。 英語の場合は、スペースが単語の区切りになりますが、日本語の場合スペースでは区切られていません。\nですので、検索窓に入力された文字列は、英語の場合、クエリのパースの時点で単語に区切られます。そのあとにAnalyzerになるので、基本的には単語単位でAnalyzerの処理が動きます。そのあと、転置インデックスへの検索となります。なので、多くの場合はAnalyzerの出力は1単語です（類義語などを利用していたりする場合は異なりますが）。\n日本語の場合、スペースでは区切られていないので、クエリのパースの時点で入力された文字列がそのままAnalyzerにわたります。 今回はAnalyzer（NGram）が単語に分割し、それをもとに検索処理が実行されます。\nismatchscoringの問題点は？（やっと帰ってきました） さて、回り道をし、簡単ですが転置インデックスやAnalyzerについて説明しました。 では本題です。\n$filter=search.ismatchscoring(\u0026#39;ミルクティ\u0026#39;) このismatchscoring関数ですが、そのほかにも引数の指定が可能で、省略した場合にデフォルトで採用される値がいくつかあります。 公式のドキュメントにパラメータの意味が掲載されています。\n今回は、第4引数のsearchModeの値が問題点です。デフォルトでは、anyが指定されます。 この、anyは検索語（今回はミルクティ）の任意の検索語句が一致する必要があることになります。 「検索語句」？なんでしょう？これが、ここまで回り道をして説明してきた、Analyzerの出力した単語になります。 「ミルクティ」はNGram（N=2）のAnalyzerを通すと、\n「ミル」「ルク」「クテ」「ティ」\nという4つの単語が出力されます。 これが、「検索語句」です。「任意の」とあるので、上記4つの2文字のどれか？が出現すれば検索条件にヒットしたこととなります。\nですので、以下のように（一部のみ色を変えてます）3つの文章にはそれぞれの文字が含まれているため、先ほどの条件では3件の結果が返ってくることになります。\nミルクティを飲みたいです。 マティーニはカクテルですが、ミルクセーキは？ 風呂上がりのミルクは最高です。 NGramで一部分の単語だけで一致したものがヒットしてしまうと違和感があるので、allに変更します。\n$filter=search.ismatchscoring(\u0026#39;ミルクティ\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;all\u0026#39;) 今度はどうなるでしょう？\nミルクティを飲みたいです。 マティーニはカクテルですが、ミルクセーキは？ 先ほどよりもマシになりました。 3がヒットしなくなっています。3の文章には「ティ」などが出てこないためです。 ただ、感覚的に2番目がヒットするのは少し違和感がありますよね？ 確かに4つの単語がすべて出てきていますが、「ミルクティ」とは少し遠いです。\nさらに「ミルクティ」にヒットさせるにはフレーズ検索にする必要があります。 Elastic社のブログの日本語の検索に関する記事でも出てきますが、フレーズで検索することで「ミルクティ」だけにヒットさせることができます。\n「フレーズ検索＝語順を保証する検索」となります。 ですので、\n「ミル」「ルク」「クテ」「ティ」\nこの順序で出てきた場合のみ、検索にヒットしたことになります。 OData式でフレーズ検索する場合は、単語をダブルクォート\u0026quot;でくくる必要があります（公式ドキュメントの例に記載あり）。\n$filter=search.ismatchscoring(\u0026#39;\u0026#34;ミルクティ\u0026#34;\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;all\u0026#39;) これで結果は以下の1件だけとなります。\nミルクティを飲みたいです。 これでNGramで部分一致のような挙動で日本語の検索ができるようになりました。\nちなみに、フレーズにした場合は第4引数はanyに変更しても1件だけの検索結果となります。 フレーズ検索には「すべての語が含まれる」、「すべての語が順番に現れる」という2つの条件が含まれるためです。\n$filter=search.ismatchscoring(\u0026#39;\u0026#34;ミルクティ\u0026#34;\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;any\u0026#39;) この例の引数をミルクティを\u0026quot;ミルク\u0026quot; \u0026quot;最高\u0026quot;のような検索条件に変えた場合、「\u0026ldquo;ミルク\u0026rdquo;」「\u0026ldquo;最高\u0026rdquo;」の2つの条件をanyで扱うため、 「\u0026ldquo;ミルク\u0026rdquo;」「\u0026ldquo;最高\u0026rdquo;」のどちらかが出てくれば良い結果となり、3件の結果が返ってきます。 第4引数をallに変更すると、「\u0026ldquo;ミルク\u0026rdquo;」「\u0026ldquo;最高\u0026rdquo;」の両方が出てこなければならないため、3件目のデータのみが返ってきます。\n$filter=search.ismatchscoring(\u0026#39;\u0026#34;ミルクティ\u0026#34; \u0026#34;最高\u0026#34;\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;all\u0026#39;) これは、\n$filter=search.ismatchscoring(\u0026#39;\u0026#34;ミルクティ\u0026#34;\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;any\u0026#39;) and search.ismatchscoring(\u0026#39;\u0026#34;最高\u0026#34;\u0026#39;, \u0026#39;body\u0026#39;, \u0026#39;simple\u0026#39;, \u0026#39;any\u0026#39;) と同じ意味となります。 少し長くはなりますが、後者の書き方をプログラムで書くと思います、私の場合は。 検索窓に入力された単語に必ず\u0026quot;を追加する処理を書くために、画面入力の文字列を一旦パースをすることになるからです。\nまとめ 簡単？にですが、OData式でのフルテキスト検索と、NGramでのフレーズ検索について説明しました。 英語の場合、もともとスペースで区切られているので、フレーズといわれてピンときますが、日本語の場合はAnalyzerの挙動をわかっていないと「？」となるかと思います。 なぜフレーズ検索が必要なのか？というのが少しでもわかっていただければと。 ちなみに、NGramのTokenizerには別の落とし穴もありますが、その話はまた後日にでも。\n参考として日本語関連の検索に関する記事のリンクを残しておきます。\n参考 Elasticsearch日本語でフレーズ検索が必要なわけ NGramも含め、Elasticsearchでの日本語の検索の設定やクエリについては、Elastic社のブログで日本語で書かれた記事が詳しいのでこちらをご覧いただくのがいいです。 ","date":1614756213,"dir":"post/2021/","id":"eced95e5f301a8340e83d81d3c0d5c0d","lang":"ja","lastmod":1614756213,"permalink":"https://blog.johtani.info/blog/2021/03/03/phrase-query-in-japanese/","publishdate":"2021-03-03T16:23:33+09:00","summary":"Azure Cognitive SearchにはOData式という書式で条件が書ける仕組みがあります。 ODataは検索条件（$filter）やソート条件（$orderb","tags":["azure search","elasticsearch"],"title":"OData式と日本語の検索(NGram)とフレーズ検索"},{"contents":"自宅の環境がいろいろと変わったのですが、書いていなかったので更新版です。 前回のブログ(2020/09)、前々回のブログ(2020/03)はそれぞれリンクをたどってください。\n現状のデスクトップはこんな感じ\nPC 別のブログにまとめましたが、Windowsメインに切り替えました。 ハードの話以外に、Windows OSに切り替えたときにいくつか入れたものもあります。 それは、移行のブログに少しだけ書いてあります。\nひさびさにWindowsに戻ってきていますが、だいぶ慣れました。 まぁ、それほど大したことをやってないというのもあるかもですが。。。\nメインPC以外にこれまでのmacをブラウジング用にサブディスプレイにつなぎ、マウスをLogicool Flowで行き来できるようにし、 キーボードはKVMスイッチで切り替えてやりくりしていました（最新環境はキーボードのところを参照してください）。\nAmazon | サンワダイレクト USB切替器 キーボード・マウス用 KVMスイッチ キーボード いくつかDIYしましたが、今はメインでSofle Keyboard v2を利用しています（Kochi Keyboardさんで購入できます）\nSofle keyboard v2を有線で使っていましたが、最近Bluetooth対応して無線化しました（その時のブログはこちら）。 ですので、PCとの接続の切り替えはキーボード上で特定のキーの組み合わせを押すことで、切り替えられるようになっています。 KVMとは異なり、Bluetoothの接続が切り替わるのにタイムラグがある＋どこにつながっているのか？というのがわからないので、想定していないところでキーが入力されていることがあります。 これは、何とかしたいかもなぁと考えてはいるところ。\nマイク＆オーディオインターフェース 基本的に自宅でリモート作業をしています（ありがとうございます）。 なので、ミーティングもオンラインです。 となるとやはり、音がいいほうがお客さんにも喜ばれるかなぁと。 2020年3月時点ではSAMSONのGoMicを利用していました。 これもいい音なのですが、大きいマイクでもいいかなと。 あとは、ほかの使い道もあるかも？ということで、オーディオテクニカのマイク（＋ポップガード）とフォーカスライトのオーディオインターフェースに変えてみました。 自分は実感ないですが、きっと役に立っていると思いますｗ\nAmazon | audio-technica サイドアドレス コンデンサーマイクロホン AT2050 | コンデンサ | 楽器 Amazon | AUDIO-TECHNICA AT-PF2 ポップフィルター | マイクアクセサリ | 楽器 Amazon | Focusrite フォーカスライト オーディオインターフェイス 2イン/2アウト 24bit/192kHz Scarlett Solo (3rd Gen) ステッカー付きセット 【国内正規品】 | 楽器・音響機器 | 楽器 ディスプレイ 以前は、MacBookProの16インチで、メインディスプレイの下に2枚目のディスプレイも兼ねて開いて利用していました（前回のブログ参照）。 自作PCに切り替えたので、ディスプレイがなくなってしまうので、同じような大きさのモバイルモニターを利用しています。 今のところは据え置きになっていますが、持ち運べるので、ほかの部屋や外出時にも使えるんではないかなと。 ディスプレイの足などはないので、邪魔にもならず便利ですね。\nAmazon | モバイルモニター モバイルディスプレイ 4K 15.6インチ cocoparスイッチ用モニター 非光沢IPSパネル 薄い 軽量HDRモード/FreeSync対応/ブルーライト機能 3840x2160 UHD/USB Type-C/標準HDMI/mini DP/カバー付3年保証付 | cocopar | ディスプレイ 通販 音楽再生環境 サブディスプレイにサンダーボルトディスプレイを使用していたので、Mac Miniを接続していましたがサンダーボルトディスプレイには退役してもらいました。 それに伴って、Mac Miniも別の場所に移動しました。音楽再生環境にラズパイ４を復活させました。 以前購入したセットについていたケースではファンの音が気になっていたので、ヒートシンク型に変えました。 結構重いですが、冷えてそうです。\nAmazon | Geekworm Raspberry Pi(ラズベリーパイ) 4 B 用アーマー金属ケース パッシブ冷却/シェル熱放散 ラズベリーパイ4 コンピュ ータモデルB適用 (アーマーケース（ファン無し）) | Geekworm | 冷却パーツ・ファン 通販 Webカメラ カメラ自体に変更はないですが、付属品をいくつか。 Webカメラではないカメラもつけてみたいなと思い、モニターアームにカメラを付けられるものを付けてみました。 ただ、おっさんの顔をきれいに映してもなぁという結論に至ったので、Webカメラが乗っかっています。。。 あとは、デスクトップPCになり、カメラのケーブルだけではPCまで届かなくなってしまったのでUSB Type-Cの延長コードを買ってみました。実はこれ2本目ですが。。。 スタンディングデスクの昇降でケーブルに負荷がかかってしまったことがなんどかあり、1本目の延長コードは接触が悪くなってしまいました。。。時々外したりしていて、ケーブルの配置がおかしいときがあるので、気を付けるようにしています。\nAmazon | 長尾製作所 モニターアーム用 VESA カメラ＆マイクマウント NB-MV001MH | 長尾製作所 | モニタアーム\u0026amp;スタンド 通販 Amazon | iVANKY USB Type C 延長ケーブル USB 3.1 Gen 2(4K@60Hz/1.0m/オス－メス)10Gbps高速データ転送 3A急速充電 usb-c 変換 Huawei MateBook13, iPad Pro11, Nintendo Switch, MacBook等対応 | IVANKY | USBケーブル 通販 照明 裸の蛍光管だったのですが、リモコンで点灯したり、照度を変えられるようにしたかったので、 パナソニックの照明に変えました。\nAmazon | パナソニック LEDシーリングライト 調光・調色タイプ リモコン付 6畳 3, 699lm HH-CD0620AZ 【Amazon.co.jp限定】 | パナソニック(Panasonic) | ホーム＆キッチン 変えたのはよかったのですが、部屋が長細い＋Webカメラの位置（自分から見て左にカメラを置いて、部屋の奥への画角？になっている）のせいで、右半分の顔が暗くなる場合がありました。 幸い、右にはスチールラックが組んであるので、そこにつけられる照明を購入して女優ライトみたいな感じで使っています（頻繁ではないですが）\nAmazon｜ルミナス メタルラック用 LEDライト 磁石で簡単設置 連結可能 幅60cm 昼白色 LED60R-N｜メタルラックパーツ オンライン通販 フットレスト 昨年3月くらいに配置して、座っているときに足を置くのに便利に使っていました。 が、1台だと幅が足りないので最近2つ目を購入して並べて使っています。 片足ずつ載せられるのは便利ですね（基本ガニ股なので。。。）。\nAmazon | サンワダイレクト フットレスト スチール製 角度10° 幅40×奥行30cm 足置き台 100-FR011 | フットレスト | 文房具・オフィス用品 ということで、最近はこんな環境で仕事をしています。 当分これで更新しないんじゃないかなぁ。 （サブディスプレイが左に寄っているので、局面ディスプレイが気になっているところですが。。。）\n","date":1614246182,"dir":"post/2021/","id":"fcb0105fa6b5777a133f247784b9d930","lang":"ja","lastmod":1614246182,"permalink":"https://blog.johtani.info/blog/2021/02/25/update-working-facility/","publishdate":"2021-02-25T18:43:02+09:00","summary":"自宅の環境がいろいろと変わったのですが、書いていなかったので更新版です。 前回のブログ(2020/09)、前々回のブログ(2020/03)はそ","tags":["misc"],"title":"自宅の作業環境(2021/02)"},{"contents":"Azure Cognitive SearchにSuggestやAutocompleteの機能があるのを見つけたので、どんな挙動なのかを調べてログとして残しておきます。\n公式ドキュメント 日本語で公式ドキュメントが公開されています。使い方や流れについてはこちらをまずは見れば使えると思います。\n本ブログでは、ざっくりとした機能の紹介と内部がどんな挙動をしていそうか？、日本語だとどういう感じになるのか？という点を紹介しようと思います。\nどんな機能？ 検索窓でよく、キーワードを入力しているときに検索キーワードの候補が表示されることがあります。 このキーワードの候補を表示するための機能が今回紹介するSuggesterと呼ばれる機能です（日本語の公式ドキュメントでは「先行入力エクスペリエンス」）。 Suggesterには、以下の2つの機能が用意されています。\nAutocomplete：キー入力しているときに、入力されている文字列で始まる単語で、検索できるもの（転置インデックスに登録されている単語）をリストで返す機能 Suggestion：入力した文字列で始まるキーワードを含む、元のデータを返す機能 利用方法 Suggesterの機能を利用するにはインデックスに設定を追加する必要があります（新規、既存どちらでも可）。 ただ、既存のインデックスに設定を追加した場合、内部にすでに存在するドキュメント（データ）については、このSuggesterのデータは作られません。 ですので、既存データを再度登録しなおすといった作業が必要となるので注意が必要です。\n本ブログでは、いくつかAzure Cognitive Searchのサンプルのリクエストが出てきます。Visual Studio CodeのREST Client Extensionの書式となります。拡張機能の簡単な紹介は昨年のブログをご覧ください。\n設定編 Suggesterの設定では、主に以下の2つを設定する必要があります。\nname: suggesterの名称。クエリ時に指定します。 sourceFields: 入力データのもととなるフィールド名。 String型のみ指定可能。また、Azureで用意されたアナライザーだけが利用可能です。自分で用意するカスタムアナライザーは利用できないので注意が必要です（制限についてはこちら）。 今回使用するサンプルのインデックス設定は次の通りです。\nインデックス作成のリクエスト（@host、@api-keyはご自身のものに置き換えてください。）\n## 設定 @host = 名前.search.windows.netと記載 @api-key = APIキーを入力 ### Create index with suggester POST https://{{host}}/indexes/?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;name\u0026#34;:\u0026#34;suggester-test\u0026#34;, \u0026#34;fields\u0026#34;:[ { \u0026#34;name\u0026#34;:\u0026#34;id\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;Edm.String\u0026#34;, \u0026#34;key\u0026#34;:true, \u0026#34;searchable\u0026#34;:false }, { \u0026#34;name\u0026#34;:\u0026#34;name\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;Edm.String\u0026#34;, \u0026#34;searchable\u0026#34;:true, \u0026#34;analyzer\u0026#34;:\u0026#34;ngram_analyzer\u0026#34; }, { \u0026#34;name\u0026#34;:\u0026#34;category\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;Edm.String\u0026#34;, \u0026#34;filterable\u0026#34;:true, \u0026#34;facetable\u0026#34;: true } ], \u0026#34;suggesters\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;name_suggester\u0026#34;, \u0026#34;searchMode\u0026#34;: \u0026#34;analyzingInfixMatching\u0026#34;, \u0026#34;sourceFields\u0026#34;: [ \u0026#34;name\u0026#34; ] } ] } 公式ドキュメントのサンプルでは日本語がないので、日本語のデータも入力しています。\nデータ登録リクエスト\n### Index data POST https://{{host}}/indexes/suggester-test/docs/index?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;value\u0026#34;: [ { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Microsoft Office\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;microsoft\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Microsoft Azure\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;microsoft\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;3\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;GitHub Enterprise\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;github\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;4\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;GitHub dot com\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;github\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;5\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Bluetooth Mic\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;hardware\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;6\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;東京スカイツリー\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;japanese\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;7\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;東京タワー\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;japanese\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;8\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;東京特許許可局\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;japanese\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;9\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;グランメゾン東京\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;japanese\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;10\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;東京都庁\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;japanese\u0026#34; } ] } 以上が事前準備です。データ登録時に内部でSuggester用のデータを内部で生成しているようです（公式ドキュメント）。\nクエリ編 最初に説明しましたが、Suggesterの中ではAutocompleteとSuggestionという2種類の機能が用意されています。それぞれについて例をもとに説明していきます。\nAutocomplete API 検索窓に入力された文字を元に、前方一致でどのような単語で検索できるか？という候補を表示するための機能です（2単語も対応していますが今回は省略。APIの仕様はこちら）。\nたとえば、micという文字が入力されているところでAutocomplete APIを呼び出す時は、次のようなリクエストです。searchというパラメータに入力値を与えます。suggesterNameはインデックス作成時につけた名前になります。\nPOST https://{{host}}/indexes/suggester-test/docs/autocomplete?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;mic\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } レスポンスとして、次のようなJSONが返ってきます。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;microsoft\u0026#34;, \u0026#34;queryPlusText\u0026#34;: \u0026#34;microsoft\u0026#34; }, { \u0026#34;text\u0026#34;: \u0026#34;mic\u0026#34;, \u0026#34;queryPlusText\u0026#34;: \u0026#34;mic\u0026#34; } ] } サンプルデータとして登録したデータにcategoryというフィールドを入れていました。 Autocompleteは条件を絞り込んで結果を返すこともできます。 filterにODataの書式で条件を書けます。 categoryフィールドにmicrosoftが設定されているデータだけを取得するということができます。\n### Autocomplete with filter POST https://{{host}}/indexes/suggester-test/docs/autocomplete?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;mic\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34;, \u0026#34;filter\u0026#34;: \u0026#34;category eq \u0026#39;microsoft\u0026#39;\u0026#34; } レスポンスはこちら。先ほどとは違い、micというデータは返ってきていません。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;microsoft\u0026#34;, \u0026#34;queryPlusText\u0026#34;: \u0026#34;microsoft\u0026#34; } ] } 英語の場合、「単語」の単位は字面の通りです。スペースで単語が区切られているのでわかりやすいです。 日本語の場合は普通の人には少し想像しにくいです。 東京という文字を入力してみます。\n### Autocomplete in Japanese POST https://{{host}}/indexes/suggester-test/docs/autocomplete?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;東京\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } すると返ってくるのは以下の通り「東京」だけになります。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;東京\u0026#34;, \u0026#34;queryPlusText\u0026#34;: \u0026#34;東京\u0026#34; } ] } 入っているデータは「東京スカイツリー」、「東京タワー」などです。 普通に考えると、これらがそのまま返ってくると思うかもしれませんが、違います。\nこれは、Suggesterの元となるフィールドのAnalyzerの挙動によります。 今回のインデックスのnameフィールドのanalyzerにはja.luceneです。これは、日本語用のアナライザー（Kuromoji）になります。いわゆる形態素解析器で日本語の文字列を「単語」に分割します。 英語についてはスペース区切りで分割しますが、日本語についてはKuromojiが内部の辞書とアルゴリズムに基づいて単語に分割してくれます。 Azure Cognitive Searchでは、Analyzerの挙動を確認するためのAPIも用意してあるので実行しみると、\n### Autocomplete in Japanese POST https://{{host}}/indexes/suggester-test/analyze?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;text\u0026#34;: \u0026#34;東京スカイツリー\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;ja.lucene\u0026#34; } このような結果が返ってきます。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;東京\u0026#34;, \u0026#34;startOffset\u0026#34;: 0, \u0026#34;endOffset\u0026#34;: 2, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;スカイ\u0026#34;, \u0026#34;startOffset\u0026#34;: 2, \u0026#34;endOffset\u0026#34;: 5, \u0026#34;position\u0026#34;: 1 }, { \u0026#34;token\u0026#34;: \u0026#34;ツリー\u0026#34;, \u0026#34;startOffset\u0026#34;: 5, \u0026#34;endOffset\u0026#34;: 8, \u0026#34;position\u0026#34;: 2 } ] } ja.luceneのAnalyzerによって、3つの単語に分割されているのがわかります。 Autocomplete APIの実行結果も、このAnalyzerによって分割された単語をもとに、候補となる単語を前方一致で検索して結果を返しているのです。 ですので、「東」と入れても「東京」が返ってくるのがわかります。 一方で、「東京ス」と入力した場合は次のような結果となります。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;text\u0026#34;: \u0026#34;スカイ\u0026#34;, \u0026#34;queryPlusText\u0026#34;: \u0026#34;東京スカイ\u0026#34; } ] } これは、autocompleteModeと呼ばれるパラメータの挙動となります。 デフォルトでは、oneTermという設定で、最後の単語（例の「東京ス」の場合は「東京」「ス」と区切られるので「ス」という文字を単語とみなす）にマッチする単語（例では「スカイ」）が返ってきます。 queryPlusTextについては、入力された文字にtextで返ってきた単語をくっつけたものが取得できます。\n英語であれば、スペースで区切られており、単語が切れているのが簡単にイメージできますが、日本語の場合は少し違和感が出るかと。\nこのように、入力された文字が含まれる「単語」を基本的に返す動作をするのがAutocomplete APIです。\nSuggest API では、もうひとつのSuggest APIはどういったものでしょうか？ autocomplete APIに似ていますが、返ってくるデータが登録されたデータそのものになります。\nたとえば、micという文字列を入力とした場合、\nPOST https://{{host}}/indexes/suggester-test/docs/suggest?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;mic\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } 次のような結果が返ってきます。Autocompleteの時は単語でしたが、こちらは入力データがそのまま返ってきています。 入力データの中にmicで始まる単語が含まれたものが候補となっています。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.text\u0026#34;: \u0026#34;Bluetooth Mic\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;5\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;Microsoft Office\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;Microsoft Azure\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;2\u0026#34; } ] } 日本語の場合、Autocompleteとは異なり、その単語を含むものがサジェストされるので、「東京」をsearchに指定すると「東京」を含むデータが出てきます。\n### Suggest in Japanese POST https://{{host}}/indexes/suggester-test/docs/suggest?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;東京\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } レスポンスはこちら。単語を含む元の文字列が返ってきます。ここまでは違和感はありません。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.text\u0026#34;: \u0026#34;東京タワー\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;7\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;グランメゾン東京\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;9\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;東京都庁\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;10\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;東京スカイツリー\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;6\u0026#34; }, { \u0026#34;@search.text\u0026#34;: \u0026#34;東京特許許可局\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;8\u0026#34; } ] } では、「東京」「特許」という2つの単語をスペースで区切ったものが入力されたとするとどうでしょう？\n### Suggest in Japanese POST https://{{host}}/indexes/suggester-test/docs/suggest?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;東京 特許\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } スペースがありますが、内部処理では形態素解析器が分割した後でこの単語の順番で出てくるものを探しているので、出てくることになります。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;value\u0026#34;: [ { \u0026#34;@search.text\u0026#34;: \u0026#34;東京特許許可局\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;8\u0026#34; } ] } なお、このSuggestのAPIは、単語の語順を気を付ける必要があります。 「特許」「東京」と順序を入れ替えたスペース区切りの場合は、\n### Suggest in Japanese POST https://{{host}}/indexes/suggester-test/docs/suggest?api-version=2020-06-30 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#34;特許 東京\u0026#34;, \u0026#34;suggesterName\u0026#34;: \u0026#34;name_suggester\u0026#34; } 結果は返ってこないです。おそらく内部では、フレーズクエリで、最後の単語だけを前方一致で検索するような仕組みが動いているのだと思われます。 スペースで区切られてはいるが、順序があるので少し違和感を感じるかもしれません。英語だとフレーズの部分のイメージは沸きやすいのですが。\n短い文章のデータ（例：本のタイトルやランドマーク名など）では、このSuggestAPIを利用するとデータそのものが返却されるので、便利かもしれません。\nまとめ ということで、Azure Cognitive SearchのSuggesterの簡単な紹介でした。APIのページにはそのほかのパラメータについても説明があるので、使ってみようと思う方は目を通していただくのがよいかと。\n今回のブログは裏の仕組みがどんな感じなのか？を想像しながらAPIについて調べた形になります。日本語の場合に、少し違和感を覚える人もいそうだろうなということでブログを書いてみました。 今回は書いていませんが日本語でAutocompleteをやりたい場合は、読み仮名でも漢字が表示されるほうがよいという場合もあると思います。 その場合は、用意されている機能では難しいので、独自実装するといった方法になりそうです。 英語や、読みを利用しない場合は、挙動を理解していれば役に立つ場面もありそうです。\n","date":1612515120,"dir":"post/2021/","id":"931b2ebd9bfaeb5dcf1973e724a1f8d0","lang":"ja","lastmod":1612515120,"permalink":"https://blog.johtani.info/blog/2021/02/05/autocomplete-and-suggest-on-azure-search/","publishdate":"2021-02-05T17:52:00+09:00","summary":"Azure Cognitive SearchにSuggestやAutocompleteの機能があるのを見つけたので、どんな挙動なのかを調べてログとして残しておきます。 公","tags":["azure search"],"title":"Azure Cognitive Searchでオートコンプリートやサジェストをしてみる"},{"contents":"オライリー・ジャパンから出ている「コンピュータシステムの理論と実装」を読み始めたのでメモを取ることに。\n原著はオライリーじゃないのかというのが、まず最初の気づきでした。\nNANDからテトリス コンピュータのハードウェアからOS、さらにその上で動くアプリケーションまでを動作させるというのを少しずつやっていくという書籍みたいです。 イントロと1章を読みましたが、1章では論理回路の話でした。\n実際に物理的に作るわけではなく、シミュレーターなどのソフトウェアが用意されており、 そのソフトウェア上で動くものを作っていくことになります。 ソフトウェアのために専用のサイトが用意されて、ダウンロードもできるようになっているので、実際に手を動かしながら理解を進める感じになるのかと。\n目次を見ていただくとわかりますが、すごく幅が広いです。 1年で読み終われるかなぁ？まぁ、のんびりやっていこうかなと。\n用意されているソフトウェアなどで便利だなと思ったのは、どの章からでも興味のある部分から始められるようになっているようです（まだ始めてなくて。。。） 内部ではすべてのパーツがそろえてあるけど、章ごとのプロジェクトでは、個別に自分で実装したものがあればそちらが動くという挙動のようです。\nということで、ちょっとずつやっていこうかなと。 ほんとにテトリス動くのかなぁ？\n","date":1612424444,"dir":"post/2021/","id":"aa61b4543e8a7c67fccabee27a6e99cd","lang":"ja","lastmod":1612424444,"permalink":"https://blog.johtani.info/blog/2021/02/04/reading-elements-of-computing-systems/","publishdate":"2021-02-04T16:40:44+09:00","summary":"オライリー・ジャパンから出ている「コンピュータシステムの理論と実装」を読み始めたのでメモを取ることに。 原著はオライリーじゃないのかというのが","tags":["輪読","Nand2Tetris"],"title":"「コンピュータシステムの理論と実装」を読み始めた #Nand2Tetris"},{"contents":"Corne使ってましたが、数字キーがあるとどうなのかな？というのがやはり気になって。 そこに、Kochi KeyboardさんからSofle Keyboard v2というのが発売されたので組み立ててみました（去年末に）。また、先日Corne Light v2のBLE化に成功したので、Sofle keyboard v2のBLE Pro Micro + LPME-IO化にもチャレンジしてみました。\nSofle keyboard v2 ビルドログ 自分で書くよりもすごくよくできたビルドログがKochi Keyboardさんで公開されているので、そちらを参考にしてください。\nSofle Keyboard v2ビルドガイド すごく詳しく書いてあります。なので、こちらを見ていただければ問題ないかなと。 ただ、自分ではいくつか失敗したので自戒を込めてログを残しておきます。\nOLED用のジャンパをはんだ付けし忘れ 単にビルドログを流し読みしたツケが。。。 Sofleは同じ基盤を左右で利用します。なので、右手と左手で、同じ基盤の表と裏を利用します。 OLED用のジャンパする部分は両面に用意されていますが、はんだでジャンプするのはPro Microが実装される面となります。\n両面にジャンプ用のランドがあるとは気づかないで、左手の裏面をジャンプしてすべて実装し終わってから、OLEDが表示されないことに気づいてしまいました（ビルドログ用にと思って撮った写真に証拠が残ってますねｗ）。。。\nということで、またはんダッシュ太郎くんのお世話になりました（Pro Microを外してジャンプしました）。本当に有能ですよ彼は。。。\nAmazon | サンハヤト はんだシュッ太郎NEO 45Wタイプ HSK-300 | ハンダゴテパーツ ソケットのはんだ付け甘すぎ あとは、慣れてきたなぁと思っていたところに天罰が。 キースイッチのソケットを付けるの慣れてきたなーと思って、サクサクとつけていたのですが、 いざキースイッチをはめるときにボロボロとはがれていきましたｗ 半分くらいは外れたんじゃないかな？ちゃんとはんだ付けした後にピンセットなどで軽くいじってみるべきですね。。。\n滑り止め 利用しているキーキャップがOEMプロファイルということもあり、数字キー側を少し高くしたほうが入力しやすいです。そのために、少し大きめのソフトクッションを購入しました。\nAmazon | WAKI ソフトクッションCN-020 クリアータイプ: 産業・研究開発用品 上の左右の角に貼り付けると、がたつきがあったので少しずらして貼り付けて安定させています。 OLEDのプレートの部分を押すと手前が浮き上がってしまいますが、そこにはキーはないので問題ないかと。\nということで、毎回気づきがあって面白いですね。。。\nSofle keyboardのBLE化 Corne LightのBLE化がうまくいったので、もうひとセットのぎけす屋さんから購入しました。 BLE Micro ProやLPME-IO、電池基盤などについては前回のCorneのBLE化の記事を参照してください。\nハードウェア編 Sofle keyboard v2は残念ながらせきごんさんの公式ページの対応キーボード一覧には掲載されていません。 が、Sofle KeyboardのGitHubのページには次のような記載があります。\nSofle is 6×4+5 keys column-staggered split keyboard with encoder support. Based on Lily58, Corne and Helix keyboards.\n基盤の写真のPro Micro周りもCorneに似ています。 ということで、おそらくBLE + LPME-IO化が行けるのでは？と予測して作業に取り掛かりました。\nPCBの確認 Sofle Keyboardの基盤の設計図はGitHub上に公開されています。 この設計図を見る方法をまずは探しました。\n自作キーボードについて探すにはまずはサリチル酸さんのブログ「自作キーボード温泉街の歩き方」です。 回路図なので、設計ノウハウあたりのカテゴリーにあるだろうと探したところ見つかりました。\n（設計者向け）オートルーターを使って睡眠時間を確保しよう 配線のテクニックというブログですが、回路図を書くためのツールKiCadについて記載があります。 このブログにある以下の記事をもとに、KiCadのインストールや使い方をちょっとだけ勉強しました。\nfoostanさんのMeishi Keyboardの開発者向けガイド(JP) KiCadことはじめ KiCadの中の回路図エディタ「Eeschema」でSofle keyboardのPCBのフォルダを開くと回路図が開きます。 実際の基盤になる前に、Pro Microのどの足と何がつながっているのか？などが見て取れます。 前回のCorneのBLE化でLPME-IO対応したときに、学習しましたが、 TRRSの足とPro MicroのSDAとSCLをつなぐことで、LPME-IOを使うことができるようになるというのがわかっています。 それをもとに回路図を見たところ、以下のような記述がありました。\nどうも、JP9とJP10というはんだでジャンプする場所を用意してくれていそうです。 先を見越した設計本当にありがたいですね。\nJP9とJP10のはんだ付け 今ついているPro Microを外し（またはんダッシュ太郎が活躍）、基板を確認したところ対象の個所がありました。下の写真は左手の裏側です。\nこれらをはんだでジャンプします。\n右手は表側にあるので、Pro Microを外した後にジャンプしました。 左手は裏側です。 Corne Lightでは、Pro Microの足から導線を使ってTRRSの足につなぎましたが、今回はすっきり実装できました。 ジャンプした後はBLE Micro Proをはんだ付けします（はんだ付けせずに動作確認しようとしましたが、うまく通電しなくてちゃんと動かなかったです）。\nLPME-IOのジャンパ LPME-IOのGitHubページにあるように、利用するキーボードによって、いくつかはんだでジャンプする必要があります。 これは、BLE Micro Pro用のConfigファイルを見て、対象を決める必要があります。 が、Sofleは事前に用意されたものがありません。\nConfigファイルの生成 用意されていないConfigファイルが、QMKの設定ファイルから生成することができるようななっています（本当に感謝しかないですね）。 手順はBLE Micro Proのドキュメントにありました。\n新しいキーボード用の設定を作成する - QMK用の設定から変換する この変換スクリプトで３種類のconfig（右手用、左手用、LPME-IO用）が生成されます。 私の場合はLPMEを利用するので、lpmeという名前の入ったconfigを利用します。 中を見るとcol以下の記載が以下の通りだったので、8からDをジャンプします。\n\u0026#34;col_pins\u0026#34;:[18, 17, 16, 15, 14, 13, 18, 17, 16, 15, 14, 13], ここまででハードウェア側が終了です。\nファームウェア・設定編 ハードウェアの実装が終わったので、ファームウェアおよびアプリの設定です。\nファームウェアのセットアップ キーボードをUSBで接続し、BLE Micro Pro Web Configuratorのページにアクセスすると、 セットアップ初期画面が出てきます。\n公式ページの「キーボードを選ぶ」を参考にファームウェア、アプリのアップデートを行います。 「設定ファイルの書き込み」のタイミングでupload your ownを選択すると、ファイル選択画面が出てくるので、変換スクリプトで生成したJSONファイルを選択します。 このとき、Mas Storage Classとしてキーボードが認識されている状態だとうまく書き込めなかったので、キーボードのドライブを「取り出し」してからファイルをアップロードしました。\nキーマップの設定 BLE Micro Proのアプリが設定をきちんと認識すれば、あとはWeb Configuratorでキーマップの設定が可能になります。 これまた、残念なことに、BLE化する前のキーマップをJSONファイルで保存してなかったので（泣きそうｗ）、QMKのkeymap.cのファイルをもとに、ブラウザ上でがんばって設定しましたｗ また、新しい設定ではBLE関連のキーをマッピングとして追加しています。\nBluetooth接続 あとは、接続確認です。 MacとWin２台と接続するのですが、Win→Mac→Winの順番でBluetoothの接続をやっていたら、なぜか３つ目のWindowsで接続候補に出てくるけど、接続しようとするとタイムアウトをするという現象に遭遇しました。 MacのBluetoothの設定を一旦削除してから、Win→Win→Macの順番でペアリングしたところ問題なく接続できました。ただ、これが本当の対処なのかどうかは不明です。３番目だと接続できなかったWindowsマシンは再起動もしてみたのですがダメでした。この辺よくわかってないなぁ。\nまとめ ということで、Corne Lightに引き続き、Sofle Keyboard v2もBLE＋LPME化に成功しました。 導線なども使わずにLPME対応ができたので見た目もすっきりしています。 これで、KVMスイッチだと２台までしか切り替えできなかったのが、３台をひとつのキーボードで操ることができるようになりました。 だいぶ楽になりそうな予感がしています。\nまだ、完ぺきではないので、次のような対応をやっていく予定です。\nロータリーエンコーダー対応：BLE以前はQMKのkeymap.cの中でロータリーエンコーダーの動作を記述していたので、BLE Micro Proでどうやるのかを調べたい。encorder.jsonというファイルがあったのでその辺ではないかな？ OLED対応：Corne Lightの時と同様に、OLEDが点かなくなったのでこの辺りを調べたい。 ということで、とりあえずキー入力するのには困らない程度にはできたので、より便利にする方法を時間を見つけて模索する感じになりそうです。 あと、KiCadも面白そうなのでこっちもちょっと触ってみたくなってきたかも？\n","date":1612106122,"dir":"post/2021/","id":"d95522c691013bfe66dd46ded85a98ed","lang":"ja","lastmod":1612106122,"permalink":"https://blog.johtani.info/blog/2021/02/01/apply-ble-to-sofle/","publishdate":"2021-02-01T00:15:22+09:00","summary":"Corne使ってましたが、数字キーがあるとどうなのかな？というのがやはり気になって。 そこに、Kochi KeyboardさんからSofle Keyboard v","tags":["DIYキーボード","misc"],"title":"Sofle v2を組み立てて、BLE+LPME-IO化してみた #DIYキーボード"},{"contents":"メインマシンとMacは下記のサンワサプライのUSB接続のKVMスイッチを使っていますが、もう一台ノートPCがありここに接続しているCorne（初めてのDIYキーボード）が長いUSBケーブルでつながっています。\nAmazon | サンワダイレクト USB切替器 キーボード・マウス用 KVMスイッチ 時々必要になって、デスクにキーボードだけ引っ張ってきて利用するのですが、ケーブルの取り回しがまぁ邪魔で。。。 BLE対応（BLE Micro Pro）をしてみようかなということに。\nBLE + LPME-IO対応 分割キーボードをBLE対応(それぞれにBLE Micro Proを実装)すると、キーボード間のつながりがいまいちになることもあるというのをちらほら見ていたので、BLE Micro Pro + LPME-IOという構成で、 Corneのキーボード同士はTRRSケーブルで接続し、PCとCorne間をBluetoothで接続する構成にしてみました。\nBLE Micro Proについては、公式ドキュメントにいろいろと記載があります。\n材料 ということで、材料は以下の通り。セット販売は売り切れていたので、個別に購入しました。 コンスルーと電池以外は１つずつです。\nBLE Micro Pro(のぎけす屋) x 1 LPME-IO(のぎけす屋) x 1 BLE Micro Pro用電池基盤(遊舎工房) x 1 コンスルー(Kochi Keyboard) x 4 CR1632ボタン電池（近所のスーパー） x 2 実装 まずは、それぞれ組み立てです。\n電池基盤 以下の記事を参考にはんだ付けしました。\nQiita: 自作キーボードビルドログ：その２「ErgoDash」無線化対応 ハードウェア編 - 電池基盤の組み立て・半田付け yfuku docs - Claw44 / 無線接続について 注意点は以下の通りです。\n基盤が軽いので固定が必要（マスキングテープでマットに貼り付けたらましになった） 電池ホルダーが変形しやすい（設置して、足を折るために上から押さえつけたら、本体が曲がってしまった。。。） 部品が細かいので大変（老眼だから？） BLE Micro Proとの接続は参考にしたyfuku docsにある方法（余っていたピンヘッダを１本ずつ使ってはんだ付け）を採用しました。 （パッと見大丈夫そうだったので電池基盤の裏に絶縁テープは貼ってないです貼ってないです）\nBLE Micro Pro（もげ対策） BLE Micro Pro自体はコンスルーをはんだ付けするだけですが、今回はもげ対策として、ダイソーで買ってきたグルーガンで ちょっとだけ補強してみました。 初グルーガンだったので不細工だけど。これ難しいな。\n効き目あればいいけど？\nLPME-IO対応 いくつかのジャンパをはんだでブリッジ まずは、LPME-IOのREADMEのページの導入手順を読み、いくつかのピンをジャンプしました。 せきごんさんのBLE-Micro-Proのリポジトリに、CorneのLPME用コンフィグファイルを見ると、ジャンプするのは20, 19, 18, 17, 16, 15に対応している、F,E,D,C,B,Aの６つです（写真撮り忘れた。。。）。\nTRRSのI2C対応（って言い方であってるのかなぁ？） ジャンプだけでいけないかなぁ？と思いましたがダメでした（USBでつないでみたけど、左手（BLE-Micro-Proがついている側）だけ入力可能です。\nBLE Micro Proの公式サイトにLPME-IOについても記載があります。 実績のあるキーボード一覧にCorne Lightの記載もあったので、試してみようと思ったのが発端です。\nただ、LPME-IOの欄に注意書きが。\n*LPME-IOを使うには改造が必要\nまた、一覧の最初にも記載があります。\nLPME-IOを使うにはキーボードの左右の有線通信がI2Cである必要があります。とくにOLEDに対応しているキーボード等の場合は、I2C用のピンをTRRSジャックに接続する改造を施すことでI2C化できる場合があります。\nまだ、自作キーボードの仕組みをがっつり理解しているわけではない初心者なので、まぁ、ちょっとわからないかなと。。。 BLE Micro Proのはじめにのページを見ると、 Self Made keyboard in JapanのDiscordに専用チャネルがあるようで、過去ログを検索してみました。 検索したところ、Corneの場合Micro ProのSDA(写真の青い線)とSCL(写真の黄色い線)（参考：Corneの基盤の図）をそれぞれ、TRRSの２つのピンに接続する必要がありそうだというコメントがありました。\nCorne Cherry v2の場合は、接続するためのショートカットが用意されていましたが、Corne Light v2だと見当たりませんでした。 ということで、線を使って物理ショートカットしました。ちなみに、ショートカットは両手ともに必要なようです。\nUSB-Cで接続テスト 上記対応が終わって、基板に設置してUSB-Cケーブルで接続したところ、外部ドライブとして見えるようになりました。\nキーマップの書き換えとか 公式ドキュメントのBLE Micro Pro Web Configuratorを使うの手順通りに書き込みを行っていくと、特に問題なく接続できました。 便利すぎですね。キーマップの変更は、これまでのCorneのキーマップJSONファイルからコピペして書き込んだだけです。 （この後、BLE用のキーマップを書き足すためにもう一度変更しますが）\nLPME-IO対応なので、Micro Proは片側しかないので、書き換えも楽々でした。\nBLEで接続テスト 今回の目的だったWindowsにBluetoothで接続できるようにしてみました。 最初はサリチル酸さんの記事を見ていたのですが、キーコードがちょっと変わっているようでした。\nで、よくよく見ると、BLE Micro Pro Web ConfiguratorにBLE関連のキーも用意されているじゃないですか。。。\nBLE関連のキーを割り当てた後は、USBをオフにして、Bluetoothをオン、BTNEWで新しくペアリングするようにすれば接続完了でした。\n課題 これまでと違い、すんなり実装ができましたがまだいくつか気になる点が。\n複数の機器とペアリングして切り替え Macともペアリングしてみようとしたのですが、切り替えがうまくいかないようで。。。 OLEDつけるにはどうするんだろう？ 左手側は電池が乗っているのですが、右手側はLPME-IOだけなので、上にOLEDを載せる余裕があります。 なので載せてみましたが点かないですね。ファームウェアを何かしないといけないんじゃないかな？調べないとなぁ。 という感じです。 まだちゃんと長時間使っていないので、他の問題点も出てくるかもしれませんが、まぁとりあえず使ってみてからかな。 うまくいくようなら、メインマシンにBluetoothモジュール追加してみるのもありかと考えているところです。\n調べながら、自分なりに対応してみましたが他にもいい方法とかあれば教えてもらえると助かります。\n","date":1610332951,"dir":"post/2021/","id":"4ad8239a37f641bcd17abeb96106314e","lang":"ja","lastmod":1610332951,"permalink":"https://blog.johtani.info/blog/2021/01/11/apply-ble-and-lpme-to-corne/","publishdate":"2021-01-11T11:42:31+09:00","summary":"メインマシンとMacは下記のサンワサプライのUSB接続のKVMスイッチを使っていますが、もう一台ノートPCがありここに接続しているCorne","tags":["DIYキーボード","misc"],"title":"Corne Light v2のBLE+LPME-IO対応 #DIYキーボード"},{"contents":"振り返りブログにも書きましたが、デスクトップPCを自作(DIY)しました。 組み立てたに使ったパーツのアフィリンクを貼っておきます。\n10月くらいにPC組もうと思って、組み上がったのは11月半ばでした。 最初はもうちょっと小さいPCにしようと思ってたのに気づいたらATXになってました。 パーツの選定の基準は以下のツイートです。影響されやすいなぁ。\nタワーってほど大きくなくていいと思いますが、NZXT H510 ぐらいの大きさは欲しいですね。https://t.co/s1c1fOnPyI\n単純に、スペースがないと組みにくいのと冷えにくい、買ってきたものがやっぱりこれだと入らない、というリスクがかなり減るので。\n\u0026mdash; さぼてん（さぼ福）🌵 (@cactusman) October 9, 2020 今年3台作りました。ノートPC使えない体になります。 pic.twitter.com/8zDmeRwNkS\n\u0026mdash; miyake | ZEN (@kazuyukimiyake) October 9, 2020 白いケースいいなぁという感じで、ケースとCPUクーラーが決まったんで、ググってこちらのHAKKAさんのYouTube見ながら妄想してました。 パーツがなかなか揃わなくて。 そして、PCが光るのどうなの?と思ってたのに、気づいたら光ってました(なぜ?)。\nグラボがない状態(CPU内蔵GPU)で12月頭までは動作してました。\n購入自体はTSUKUMO、ビックカメラオンライン、パソコンSHOPアーク、イートレンドオンラインショップでオンラインで購入しました。\nPCケース Amazon | NZXT H510i White CA-H510I-W1 CS7946 | NZXT | PCバッグ・ケース・スリーブ 電源 Amazon | NZXT E850 デジタル電源ユニット 80 Plus Gold 認証 [ 定格 850W 出力 ] NP-1PM-E850A-JP NP-1PM-E850A-JP SP947 | NZXT | パソコン・周辺機器 通販 マザーボード Amazon | ASRock AMD Ryzen 3000シリーズ CPU(Soket AM4)対応 X570チップセット搭載 ATX マザーボード X570 Steel Legend | ASROCK CPU AMD Ryzen 4750G\nCPUクーラー Amazon | NZXT KRAKEN Z63 簡易水冷CPUクーラー 液晶モニタ搭載 RGB対応 280mm RL-KRZ63-01 FN1441 | NZXT | CPUファン 通販 メモリ Amazon | G.SKILL 128GB（4 x 32GB）Trident Z NeoシリーズDDR4 SDRAM 3200MHz PC4-25600デスクトップメモリモデルF4-3200C16Q-128GTZN | G.Skill | メモリ 通販 SSD Amazon | Seagate FireCuda 520 M.2 1TB PCIe Gen4x4 内蔵SSD M.2 2280 3D TLC ZP1000GM3A002 | SEAGATE グラボ Amazon | GIGABYTE NVIDIA GeForce RTX3080搭載 グラフィックボード GDDR6X 10GB ホワイトモデル【国内正規代理店品】GV-N3080VISION OC-10GD | 日本ギガバイト 拡張カード Amazon | ASRock 拡張インターフェースボード Thunderbolt 3 AIC R2.0 | ASROCK | インターフェースカード 通販 拡張カードは実は差し込んだら最初うまく動かなくてサポートに連絡しました。同じ構成の検証機を用意して解決方法を見つけてもらいました。しかも数日で。サイコーのエクスペリエンスでした!\n日本語でサポートしてもらえてしかも数日で解決してもらった。ASRockのサポートすばらしかったです！ https://t.co/8FasCInIqt\n\u0026mdash; Jun Ohtani (@johtani) December 8, 2020 その他 ケースのフロントパネルのUSB-Cポートを使えるようにするために。\nAmazon | Cablecc USB 3.1フロントパネルソケットType-E-マザーボード用USB 3.0 20ピンヘッダーオス拡張アダプター | cablecc | PCアクセサリ・サプライ 通販 最近のPCパーツはUSBでモニタリングできるみたいで、マザボのUSBポートが足りなかったので拡張しました。\nAmazon | マザーボードのUSB 9ピン 増設 内部用4ポートUSB2.0 HUB | ノーブランド品 | USBハブ 通販 白いケースだし、「映え」のために白いケーブルを。\nAmazon | Novonest 電源専用延長スリーブ 補助電源モジュラーケーブル 長さ300mm 6本1セット スリーブガイド24点セット付き 【SC304】 | ｎｏｖｏｎｅｓｔ | 電源ユニット 通販 組み立て中 手元にあったCPUでBiosアップデート(Ryzen 5000シリーズにしたかったから。まだできてないけど)。\n応急処置でBiosアップデートしてる pic.twitter.com/mXf2B5kwqB\n\u0026mdash; Jun Ohtani (@johtani) November 8, 2020 さーて、頑張るぞー pic.twitter.com/HmlGqREjmP\n\u0026mdash; Jun Ohtani (@johtani) November 13, 2020 さて、仮起動実験ですよと pic.twitter.com/5HP3cbs6SH\n\u0026mdash; Jun Ohtani (@johtani) November 13, 2020 きたきたー pic.twitter.com/4sL3ymecEo\n\u0026mdash; Jun Ohtani (@johtani) November 13, 2020 コネクター刺しまくらないと pic.twitter.com/Soye3lS4M9\n\u0026mdash; Jun Ohtani (@johtani) November 13, 2020 完成はこんなかんじ 初期構成\n組み上がったよー pic.twitter.com/sBwpvLsZh3\n\u0026mdash; Jun Ohtani (@johtani) November 14, 2020 グラボデプロイ\n設置完了してこんな感じ。なんかベンチマーク走らせるかなぁ。何がいいだろ pic.twitter.com/aZufAE9fJA\n\u0026mdash; Jun Ohtani (@johtani) December 4, 2020 グラボのおまけも付けてみた。\nまぁ、せっかくついてきたので取り付けてみました（グラボ下の光ってるパネル）。 pic.twitter.com/068IxaV1ps\n\u0026mdash; Jun Ohtani (@johtani) December 4, 2020 とまぁ、こんな感じでした。 メモリは多分使い切れないだろうなぁと思いながら、やってみたかったという感じです。。。\n","date":1609422526,"dir":"post/2020/","id":"64a421c2367372c3199c66a6420faf89","lang":"ja","lastmod":1609422526,"permalink":"https://blog.johtani.info/blog/2020/12/31/diy-pc/","publishdate":"2020-12-31T22:48:46+09:00","summary":"振り返りブログにも書きましたが、デスクトップPCを自作(DIY)しました。 組み立てたに使ったパーツのアフィリンクを貼っておきます。 10月くら","tags":["misc"],"title":"PCもDIYしました"},{"contents":"今年も振り返りブログ書いてます。カタンの航海者版を購入して家族とやってましたが、負けてしまいました。\n振り返り（2019年に書いた抱負から） まずは去年の抱負を元に書きますが、3月以降はコロナウィルスの影響でいろいろと生活が変わってしまいましたね。\n職につく 厳密には達成してないことになるのかな？\n1月末にフリーランスはじめました(仮)という記事を書きましたが、 そのまま、現時点では個人事業主でフリーランスとして4社ほどお手伝いさせていただいています。\nお手伝いしてるお客さんの事例が出てた。直接的に類似画像検索の部分を手伝ってるわけではないんですが、Azure Cognitive Searchの調査とかやってます。 / 「ハッカソン」で社外の知見を積極的に活用! 富士フイルムソフトウエアが実践するサービス開発の理想形 - https://t.co/yDIwYmYDBM\n\u0026mdash; Jun Ohtani (@johtani) June 19, 2020 名前出てた。ZOZOさんの手伝いさせていただいております。 / ZOZOTOWNにおける検索速度改善までの道のり - ZOZO Technologies TECH BLOG - https://t.co/OqaFMYe0TY\n\u0026mdash; Jun Ohtani (@johtani) August 20, 2020 こんな感じです。 コロナウィルスの影響もあり、完全リモートで仕事をさせていただいています。 感謝しかないです。\nブログプラットフォームの移行 昨年の振り返りの時点で目を付けていたHugoへの乗り換えを行いました。 乗り換えについてもまとめてあります。\nOctopressからHugoへ移行中(まだ途中) ブログ移行日記(その1) - Hugoとテーマ ブログ移行日記(その2) - Markdownファイルの変換 ブログ移行日記(その3) - Hugoの設定と微調整(テーマに合わせた) ブログ移行日記(その4) - 検索機能(Algolia)の導入 ブログ移行日記(その5) - Jugemのブログを移行 無事移行できて、特に困ってない感じです。\nプログラミング 昨年よりは書いた気がしています。 まぁ、書きなぐって放置してるのもありますが。。。\n細々としたツールがいくつか。\nfrom-octopress-to-hugo bulk2es-rs azure-search-analyze-client wiki-extractor-rs kuromoji-graphviz-output kuromoji-cli あとは、Linderaという形態素解析も手伝ってみました。 ちょっと後半は忙しくなり、コーディングが減ってるんで、また復活させないと。\nRust再入門 Tantivyは結局触れてないけど、Linderaを手伝えました。あとは、ちょっとしたツール(bulk2es-rs)なども作りました。 知り合いとやっていたRust the bookを読むのも一通り終わりました。 Linderaまわりのリファクタとかを年明けにやろうかな?\n検索の勉強 仕事になりました。というか、しました。 ブッチャー本も買ったんですが、手を付けられてないので、年明けから心機一転、よみ始めようと思います。\n検索技術勉強会の継続 残念ながらだめでした。 年初にスピーカーの方に連絡は入れて履いたのですが、コロナウイルスの影響で 今年はオフラインの勉強会は無理だろうとい事で延期したままです。 オンラインの勉強会もいくつか開催されていましたが、検索技術勉強会は残念ながらモチベーションもわかずのまま今年も終わってしまいました。 単に話を聴くセミナーのようなものよりは、Podcastのような形を取るのがいいのかもなぁとは思っているのですが。。。 だれか、サクッと話したい人いたらやってみませんか?\n振り返り(今年あったできごと) さて、ここからは今年の出来事を。\n自宅環境の改善 Windowsへの移行 キーボードDIY フリーランス ブログ書いたなぁ 3月以降はずーっと自宅で仕事してました。 ということで、自宅の環境がどんどんアップデートされていった1年でした。 最終バージョンは年内に間に合わなくて、年明けに書きますが。。。 途中経過はこんな感じでした。今は更に変わっていますが。\n3月バージョン 9月バージョン 12月バージョンでも書きますが、ずっと自宅で作業だったのもあり、自作PCをやりたくなったので、久々にWindowsに帰ってきました。Ubuntuもチョット検討しましたが、Windowsに今は落ち着いています。自作PCはこんな感じ。 自作PCブログも後で書きますね。\n設置完了してこんな感じ。なんかベンチマーク走らせるかなぁ。何がいいだろ pic.twitter.com/aZufAE9fJA\n\u0026mdash; Jun Ohtani (@johtani) December 4, 2020 Windowsをお試し中 Windowsへの移行（その１） AutoHotKeyで色々と弄っているので、素のWindowsは触れる気がしないけど。。。\n自作つながりで、キーボードもDIYしました。\nDozen0を作成した Corne Light v2を作成した Corne Chocolateを組み立てた Sofle Keyboardも組み立てた(けど、ビルドブログはまだ) 分離キーボードには昨年から興味があったのですが、手を付けていませんでした。 今年は自宅でずっと作業でしたから、これを機会に作ってみました。 既製品(Moonlander)も気になってはいたのですが、DIYキーボードはプラモデル感覚で作れそうだし面白そうだなと。 今年一番ハマったものかもしれないです。 知り合いが始めたKochi Keyboardで最初に発売されたのがCorne Light v2だったので、これが初めての分割キーボードです。 40%キーボードからいきなり入ったので最初はかなり大変でしたが、なれると入力が早くなる気がします。ホームポジションからほぼ動かないのはいいですね。最初は数字列がないのでアホか???と思っていましたが。 今は、Sofle(60%キーボード)がメインになっています。40%から60%に移行すると 数字のキーが遠いなと思ってしまいますねw\nどうなるものかと思いつつ、フリーランスを続けています。 最初に仕事をいただいた富士フイルムソフトウェアさんには非常にお世話になっています(今もお手伝いさせてもらっています、ありがたい)。来年も精進していきます!\n今年はブログを書きました、最後はちょっと息切れしてる感じになってるけど。。。 もっとカジュアルに書くようにしないとなぁ。 年明けにまだ書いてないブログを書いていかないと。「自作PCブログ」「Sofleのビルドブログ」「2020年買ってよかったブログ」とか。\n来年の抱負 ということで、来年の抱負です。\nフリーランス継続? プログラミング 検索の勉強 検索のポッドキャスト? とりあえず今年は乗り切れました。来年も食べていくためにもフリーランスを継続できるように、お手伝いさせて頂いてる各社に 継続してもらえるように精進していきます。色々と勉強させて頂いてるのでほんとうにありがたいです。\nプログラミングは今年の後半はスローダウンしてしまったのでがんばらないと。 検証用のコードやちょっとしたツールを書くほうが多いので、もう少し継続してメンテナンスするようなものも書きたいなぁと。\n検索の勉強はまずはブッチャー本を買ってしまったので、ここからでしょうか。 値段も厚みもすごいので、コツコツ元を取れるようにがんばります。。。\n来年もまだまだ自宅で仕事が続きそうなので、勉強会というよりもポッドキャストみたいなものをやるのがいいのかもなと。 2020年初にやらせていただいた、「検索システム探訪」をポッドキャスト風にやるのもありなのかもなぁ。 興味ある人いたら連絡ください。公開しない雑談とかもありだと思ってるので。\n今年は色々ありましたが、無事に乗り切れました。 気軽にランチなどで遊びに行けない状況ですが、雑談相手になっていいなと思う方、連絡お待ちしています。\nさて、来年はどんなキーボード作るのかなぁ(え?また作るの??)。 今後もよろしくおねがいしまーす!\n","date":1609406004,"dir":"post/2020/","id":"a5b2ee641e10d3e4db8f888217ab9ecc","lang":"ja","lastmod":1609406004,"permalink":"https://blog.johtani.info/blog/2020/12/31/looking-back-2020/","publishdate":"2020-12-31T18:13:24+09:00","summary":"今年も振り返りブログ書いてます。カタンの航海者版を購入して家族とやってましたが、負けてしまいました。 振り返り（2019年に書いた抱負から） ま","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2020）"},{"contents":"Elastic stack (Elasticsearch) Advent Calendar 2020の18日目の記事になります。\n本日の勉強会でLTをしましたが、しゃべり足りなかったんで。 Elasticsearch 7.8でこっそりとリリースされたIndex Template V2について調べたのでどんなものかをまとめてみます。 リリースブログには出てきてない（7.8のEsのページのWhat\u0026rsquo;s newには出てた）ので気づいてない人も多いのではないでしょうか？\nIndex Templateとは？ まずはIndex Templateがどんなものかを説明しましょう。\nIndexの設定やマッピングはデフォルト値以外を設定したい場合に、毎回\u0026quot;mappings\u0026quot;や\u0026quot;settings\u0026quot;の設定を指定してIndexを作成するのは手間がかかります。 そこで便利な機能として提供されているのがIndex Templateです。このIndex TemplateはCluster Stateに保管されます。\nIndex Templateを利用するときの流れは以下の通りです。\nIndex Templateの作成 Indexの作成 例えば、3ノード構成のクラスターでインデックスを作成するときに常に\u0026quot;number_of_shards: 3\u0026quot;を設定したいとします。 Index Templateは次のような感じになります。\nPUT _template/blog_num_shards { \u0026#34;index_patterns\u0026#34;: \u0026#34;blog_*\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;index\u0026#34;: { \u0026#34;number_of_shards\u0026#34;: 3 } } } または日本語のシンプルな形態素解析のアナライザーの設定を\u0026quot;jp_\u0026ldquo;という名前でるようできるようにしたい場合には次のような感じになります。\nPUT _template/jp_simple_kuromoji { \u0026#34;index_patterns\u0026#34;: \u0026#34;jp_\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;index\u0026#34;: { \u0026#34;analysis\u0026#34;: { \u0026#34;simple_jp\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji\u0026#34; } } } } } インデックステンプレートの登録が終われば、インデックスを作成するタイミングでIndex Templateが適用されます。 例えば、blog_2020というインデックスを作成すると、number_of_shards: 3のインデックスが作成されます（デフォルトは1）。 jp_blog_2020というインデックスを作成すると、simple_jpというAnalyzerが設定されています。 このように、インデックス名を意識するだけで設定が適用されていくのが利点です。\nちなみに、Index TemplateはIndex作成時に適用されるだけなので、Index Templateを変更してもこれまでのインデックスへは影響はありません。\nこれまでのIndex Templateの問題点 と、Index Templateが便利なのはわかりましたが、ではなぜ今回V2がリリースされたのでしょうか？ 先ほどの例を見るとわかりますが、これまでのIndex Templateは部品化が難しいのが問題でした。 Index Templateはそれぞれがインデックスの作成時に適用されます。 が、Index TemplateにIndex Templateを組み込むことはできません。 例えば、先ほどサンプルとして作成したjp_simple_kuromojiのIndex Templateはjp_で始まるインデックスにしか適用できません。\nでは、blog_で始まるインデックスにもkuromojiのシンプルなアナライザーを使いたくなった場合はどうなるでしょう？ 残念ながら、jp_simple_kuromojiと同じ設定をblog_num_shardsのテンプレートに追加するか、jp_simple_kuromojiのindex_patternsの部分だけを書き換えた新しいテンプレートを用意するか、jp_simple_kuromojiのindex_patternsにjp_を追加する方法です。 いずれにしてもIndex Templateの継承（複数のテンプレートを1つのインデックスに紐づける）が必要となります。 この時、複数のIndex Templateが適用されるため、適用する順番が出てきます。 この順番をIndex Templateのorderパラメータで指定できます。\nただ、これも問題のもととなっていました。 複数あるIndex Templateのどれがどの順番で適用されるのか？それはインデックスを作成時にようやくわかります。 使いたい側（インデックス）が、使いたいもの（テンプレート）を指定するのではなく、その逆（使いたいものに使いたい側の情報を設定しなくてはならない（index_patternsやorder））になっているのでわかりにくくなっていました。\nということで解決策としてリリースされたのがIndex Template V2です（ちなみに名前にV2とは言ってるわけではなく、現在のIndex Templateの機能がlegacy index templateという名前になり、Deprecatedになっています（まだログには出ない））。\nIndex Template V2 7.8のWhat\u0026rsquo;s newドキュメントではComposable Index Templateと紹介されています。 大きく3つのエンドポイントが提供されます。\nComponent Template 用API テンプレートのコンポーネントという単位で管理するためのAPI。 登録更新、削除、取得が可能 Index Template 用API Index Templateを管理するためのAPI 登録更新、削除、取得が可能 Simulate index template API(Experimental) Index Template Legacy Index Templateとの大きな違いは、\nテンプレートをコンポーネントにできる 1つのインデックスに適用されれるテンプレートは1つだけ という点です。これまでとは挙動が異なるので注意が必要です。\n新しいIndex Templateを利用する際の流れは次のようになります。\nComponent Templateの作成 Index Templateの作成 作成したIndex Templateの挙動を確認 実際にIndex名を指定してIndex Templateの挙動を確認 という形です。では、それぞれの機能を見ていきましょう。\nCoponent Template API テンプレートコンポーネントを管理するためのAPIです。 具体的なAPIごとに説明していきます。\nPUT _component_template コンポーネントを登録、変更するためのAPIです。公式ドキュメントはこちらです。 先ほどのkuromojiのAnalzyerをコンポーネントとして登録してみましょう。\nPUT _component_template/jp_simple_kuromoji { \u0026#34;template\u0026#34;: { \u0026#34;settings\u0026#34;: { \u0026#34;index\u0026#34;: { \u0026#34;analysis\u0026#34;: { \u0026#34;analyzer\u0026#34;: { \u0026#34;simple_jp\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji_tokenizer\u0026#34; } } } } } }, \u0026#34;version\u0026#34;: 1, \u0026#34;_meta\u0026#34;: { \u0026#34;description\u0026#34;: \u0026#34;simpleなKuromoji analyzer\u0026#34; } } 先ほどと特に違いはありません。templateという階層が1段増え、index_patternsがなくなりました。 template部分はIndexに設定するsettings、mappings、aliasesが指定可能です。 ちなみに、\u0026ldquo;template\u0026quot;の中身をそのままIndex作成時に使用した場合にエラーにならない設定である必要があります。 ここは注意が必要です。例えば、component Aでkuromojiのアナライザーの設定をし、component Bでそのアナライザーを使用するフィールドのmappingだけを記述した場合、component Bでエラーが発生します。上記のようなシチュエーションでは、Index Templateで利用するフィールドを定義し、component Aを利用する宣言をすれば問題ありません。\nそのほかに使えるパラメータで便利なものを紹介しておきます。\nクエリパラメータ\ncreate: URLに指定するパラメータ。trueを指定することで、既に存在する場合にエラーを返してくれる。更新も同じAPIなので間違わないようにするために利用すると便利。デフォルトはfalse リクエストボディ\n_meta: テンプレートにメタ情報を付与できる。_metaの中は自由に記述可能。コメントなどを書いておくとあとでわかりやすい GET _component_template コンポーネントを取得するためのAPIです。公式ドキュメントはこちらです。 一覧での取得とリストでの取得が可能です。\n一覧取得サンプル\nGET /_component_template GET /_component_template/* これ以外に、IDを指定して取得することも可能です。\nGET _component_template/jp_simple_kuromoji *を利用して複数取得も可能です。\nGET _component_template/jp* GET _component_template/j*_* DELETE _component_template コンポーネントを削除するためのAPIです。公式ドキュメントはこちらです。 IDを指定してコンポーネントを削除できます。\nDELETE /_component_template/jp_simple_kuromoji ID指定以外に*を利用することも可能ですが気を付けて使用しましょう。\nDELETE /_component_template/jp_* DELETE /_component_template/* ちなみにIndex Templateで利用されているコンポーネントを削除しようとした場合はエラー（ステータスコード400）が返ってきます。 *などを使用して削除しようとした場合は、ひとつでも利用されているものが含まれている場合は削除は実行されずにエラーだけが返ってくるようになっています。\nIndex Template API Index Templateを管理するためのAPIです。 Component Template APIで定義したコンポーネントを利用してテンプレートを作成できます。コンポーネントを利用しないで単体で完結したテンプレートも作成可能です。 具体的なAPIごとに説明していきます。\nPUT _index_template Index Templateを登録・更新するためのAPIです。公式ドキュメントはこちらです。\nこれまでのLegacy Index TemplateのAPIのエンドポイント(_template)ではなく、(_index_template)というエンドポイントになっていることにまず注意してください。 先ほど作成したjp_simple_kuromojiコンポーネントと、追加で作成した3_shardsというコンポーネントを利用して blog_で始まるインデックスに適用できるIndex Templateを作成してみましょう。\nPUT _index_template/blog_template { \u0026#34;index_patterns\u0026#34;: [\u0026#34;blog_*\u0026#34;], \u0026#34;template\u0026#34;: { \u0026#34;mappings\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;hoge\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;text\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;simple_jp\u0026#34; } } } }, \u0026#34;priority\u0026#34;: 100, \u0026#34;composed_of\u0026#34;: [\u0026#34;jp_simple_kuromoji\u0026#34;, \u0026#34;3_shards\u0026#34;] } composed_ofというパラメータに利用したいコンポーネントを配列で記述していきます。 Index Templateが適用される時に、ここに記述されている順番でコンポーネントが適用されていきます。 ですので、最後に書いてあるテンプレートが一番強いことになります。 これは例えば、同じ設定値number_of_shardsを2つのコンポーネントが設定している場合に、最後に設定した値がインデックスに採用されるという意味です (公式ドキュメントにサンプルが掲載されています)。 なお、存在しないコンポーネントをcomposed_ofに指定した場合は400エラーが返ってきます。同じコンポーネントを複数重複して指定した場合は特にエラーにはなりませんでした。 composed_ofを指定しなければ、単体で完結したテンプレートを定義可能です。\n次に重要な設定はpriorityです。これまでのテンプレート機能と異なる点で説明しましたが、\n1つのインデックスに適用されれるテンプレートは1つだけ となっています。 この1つを決めるための値がpriorityになります。 インデックス名によってはindex_patternの定義によって、複数のIndex Templateにマッチします。例えばblog_*と*_2020のIndex Templateがあった場合にblog_2020というインデックスを作った場合です。 この時、Elasticsearchはpriorityの大きい値を持ったIndex Templateだけを適用します。 blog_*のIndex Templateのpropertyが10、*_2020のIndex Templateのpropertyが100だった場合、*_2020のテンプレートが適用されます。Legacy Index Templateではorderという似たパラメータがありましたが、こちらは適用する順序を決定するためのものでした。挙動が違うので注意しましょう。\nちなみに、blog_*と*_2020のpropertyがどちらも10というIndex TemplateをPUTしようとした場合、2番目にIndex TemplateをPUTするタイミングでエラーが返ってきます。\nそのほかに使えるパラメータで便利なものはPUT _component_templateと同様にcreateと_metaです。\nGET _index_template Index Templateを取得するためのAPIです。公式ドキュメントはこちらです。 一覧での取得とリストでの取得が可能です。\n一覧取得サンプル\nGET /_index_template GET /_index_template/* これ以外に、IDを指定して取得することも可能です。\nGET _index_template/blog_template *を利用して複数取得も可能です。\nGET _index_template/blog_* GET _index_template/b*_* DELETE _index_template Index Templateを削除するためのAPIです。公式ドキュメントはこちらです。\nIDを指定してコンポーネントを削除できます。\nDELETE /_component_template/jp_simple_kuromoji ID指定以外に*を利用することも可能ですが気を付けて使用しましょう。\nDELETE /_component_template/jp_* DELETE /_component_template/* 最後のサンプルを実行すると、Elasticのツールなどが登録したIndex Template以外はすべて削除されてしまうので本当に気を付けましょう。\nSimulalte API さて、コンポーネントとテンプレートを作成したので確認をしましょう。 Legacy Index Templateでは確認するためには実際にインデックスを作成するしかありませんでしたが、V2ではSimulate APIが用意されています。 このSimulate APIには2つのAPIがあります。\nPOST /_index_template/_simulate/\u0026lt;テンプレート名\u0026gt; POST /_index_template/_simulate_index/\u0026lt;インデックス名\u0026gt; Index Templateの確認のためのAPIとインデックス名を指定したときに出来上がるIndexの設定を確認するためのAPIです。 Indexを実際に作成しなくても確認できるのは便利ですね。\n例えば先ほど作成したblog_templateを試してみましょう。\n_index_template/_simulate API POST _index_template/_simulate/blog_template レスポンスはこんな感じです。\n{ \u0026#34;template\u0026#34; : { \u0026#34;settings\u0026#34; : { \u0026#34;index\u0026#34; : { \u0026#34;analysis\u0026#34; : { \u0026#34;analyzer\u0026#34; : { \u0026#34;simple_jp\u0026#34; : { \u0026#34;filter\u0026#34; : [ \u0026#34;kuromoji_readingform\u0026#34; ], \u0026#34;type\u0026#34; : \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34; : \u0026#34;kuromoji_tokenizer\u0026#34; } } }, \u0026#34;number_of_shards\u0026#34; : \u0026#34;3\u0026#34; } }, \u0026#34;mappings\u0026#34; : { \u0026#34;properties\u0026#34; : { \u0026#34;hoge\u0026#34; : { \u0026#34;type\u0026#34; : \u0026#34;text\u0026#34;, \u0026#34;analyzer\u0026#34; : \u0026#34;simple_jp\u0026#34; } } }, \u0026#34;aliases\u0026#34; : { } }, \u0026#34;overlapping\u0026#34; : [ { \u0026#34;name\u0026#34; : \u0026#34;blog_template2\u0026#34;, \u0026#34;index_patterns\u0026#34; : [ \u0026#34;blog_*\u0026#34; ] } ] } templateにコンポーネントがマージされた結果が出力されます。 overlappingはindex_patternsがかぶる可能性があるIndex Templateの情報が出力されます。 サンプル用にblog_template2という、同じindex_patternsでpriorityが低いものを登録してあるためです。 index_patternsが完全に同じではなくとも、重複する可能性があるものはここに出力されます。 例えば、index_patternsがb*という別のIndex Templateを作成してからSimulate APIを実行すると、overlappingにそのIndex Templateも出力されます。\nSimulate Index Template APIのもう一つの機能は登録前のIndex Templateの確認です。 リクエストのURLのテンプレート名をなくし、PUT _index_templateと同じJSONをリクエストボディとして送信した場合、コンポーネントをマージしたテンプレートがどんなものかを確認できます。\nPOST _index_template/_simulate { \u0026#34;index_patterns\u0026#34;: [\u0026#34;blog_*\u0026#34;], \u0026#34;template\u0026#34;: { \u0026#34;mappings\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;hoge\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;text\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;simple_jp\u0026#34; } } } }, \u0026#34;priority\u0026#34;: 10, \u0026#34;composed_of\u0026#34;: [\u0026#34;jp_simple_kuromoji\u0026#34;] } このリクエストを送信すると、コンポーネントがマージされた結果が返ってきます。index_patternsがかぶるものがある場合はoverlappingも一緒に返却されます。\n_index_template/_simulate_index API 今度はインデックス名を指定するSimulate APIを試してみましょう。\nPOST _index_template/_simulate_index/blog_2021 これだけです。\n{ \u0026#34;template\u0026#34; : { \u0026#34;settings\u0026#34; : { \u0026#34;index\u0026#34; : { \u0026#34;analysis\u0026#34; : { \u0026#34;analyzer\u0026#34; : { \u0026#34;simple_jp\u0026#34; : { \u0026#34;filter\u0026#34; : [ \u0026#34;kuromoji_readingform\u0026#34; ], \u0026#34;type\u0026#34; : \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34; : \u0026#34;kuromoji_tokenizer\u0026#34; } } }, \u0026#34;number_of_shards\u0026#34; : \u0026#34;3\u0026#34; } }, \u0026#34;mappings\u0026#34; : { \u0026#34;properties\u0026#34; : { \u0026#34;hoge\u0026#34; : { \u0026#34;type\u0026#34; : \u0026#34;text\u0026#34;, \u0026#34;analyzer\u0026#34; : \u0026#34;simple_jp\u0026#34; } } }, \u0026#34;aliases\u0026#34; : { } }, \u0026#34;overlapping\u0026#34; : [ { \u0026#34;name\u0026#34; : \u0026#34;fuga\u0026#34;, \u0026#34;index_patterns\u0026#34; : [ \u0026#34;b*\u0026#34; ] }, { \u0026#34;name\u0026#34; : \u0026#34;2021\u0026#34;, \u0026#34;index_patterns\u0026#34; : [ \u0026#34;*_2021\u0026#34; ] } ] } 例で作成したblog_templateが適用されていますが、それ以外にindex_patternsに合致したがpriorityが低くて適用されなかったものがoverlappingに出力されています。 実際に適用されたテンプレートの名前も別途出力してくれるとわかりやすいかもしれないですね。 (*_2021というインデックスパターンのテンプレートを試しに作ってみたのですが、これはバグがありそうです。2021に合致するインデックス名をSimulateしたらoverlappingに合致しないものがたくさん出てきました。バグ報告しとくか)。\nKibana対応 ここまで、Index Template V2のAPIの説明でしたが、Kibanaでの対応についても調べてみました。\nIndex Management（Stack Management機能。Elasticライセンスが必要だが無償の機能） 7.9からKibanaのIndex管理画面でComposable Templateが利用できるようになっています（GitHub Issue）。 画面のスクショを一通り貼っておきます。残念ながら、それぞれのJSONの編集部分では補完などはサポートされていないようでした。 頑張って自分でsettingsやmappingsのJSONを記述していく感じになります。JSONとして正しいかどうかはチェックしてくれます。 Index Templateのウィザードでは、ボタンでコンポーネントを追加したり削除したり、順序を入れ替えたりといった作業が可能になっています。 また、プレビュー表示が可能なので、composed_ofで選択したものが今どのように適用されているか？といったのも確認できるようになっていました。 結構便利に管理できそうです。ちなみにスクショは7.10の画面になります。\nComponent Template周り 一覧表示とウィザード Index Template周り 一覧表示とウィザード Console(Dev Tools。OSSで利用可能) リクエストを実行は可能ですが、自動補完機能は一部のみ対応しているようです(GitHub Issue)。\n対応済みの機能\nDELETE _component_template (ただし、ここまで。存在するコンポーネント名は補完されない) 上記以外はまだ未対応のようです。 プルリクエストチャンスかも？\n参考 Composable Templates · Issue #53101 · elastic/elasticsearch What’s new in 7.8 | Elasticsearch Reference ［7.8］ | Elastic Index management | Elasticsearch Reference ［7.10］ | Elastic ［Composable template］ Create / Edit wizard by sebelga · Pull Request #70220 · elastic/kibana ［Console］ Support suggesting index templates v2 · Issue #75967 · elastic/kibana まとめ ちょっと長くなってしまいましたが、新しいIndex Templateについての紹介でした。 これまでと違い、複数のテンプレートが適用されない点があるのでそこは注意が必要そうです。 コンポーネントをうまく使えば、管理が簡易化はされそうですね。\n","date":1608216955,"dir":"post/2020/","id":"c6fc88bd57a0e57ddf22e2eb1bef892c","lang":"ja","lastmod":1608216955,"permalink":"https://blog.johtani.info/blog/2020/12/17/index_template_v2/","publishdate":"2020-12-17T23:55:55+09:00","summary":"Elastic stack (Elasticsearch) Advent Calendar 2020の18日目の記事になります。 本日の勉強会でLTをしましたが、しゃべり足りなかったんで。 Elasticsearch 7.8でこっそりとリリースされたI","tags":["elasticsearch"],"title":"Index Template V2"},{"contents":"はじめまして、pyspa。 ということで、pyspa Advent Calendar 2020の4日目(大谷コンビの2号)の投稿になります。 コンビそろってキーボード記事ですね。\n今年はDIYキーボードにはまった（はめられた？）年でした。 もともと分割キーボードには興味があり、自宅で作業するのが基本となったのもあり手を出した次第です。 まだまだ使いこなすところまでは来てないかもしれないですが、組み立てたり、問題点のキリ分けしたり、試行錯誤するのは楽しいなと。\n今回はCorne Chocolateというキーボードを組み立てたのでそちらのビルドログ（かつ今後のための教訓）になります。 LEDを使ったキーボードがどんなものなのか＋薄いキーボードも気になるなということで取り組んでみました。 今回もいくつか失敗をしつつ、リカバリーして動くものができました。\nパーツ（材料） 基本のパーツは今回もKochi Keyboardさんから購入しました。\nキット : Corne Chocolate（ベースキット） キースイッチ : Kailh Choc v1 Blue (25gf リニア) 5個 キーキャップ : Kailhロープロ刻印キーキャップ ケーブル類は家に転がっていたケーブルを利用しました。 キースイッチセットもあるのですが、軽いキータッチが好みなので、一番軽いKailh ChocのBlueを試してみたくキースイッチを個別に選択しました。 キーキャップはShiroを作るときに調達していたものを利用した形です。\n今回も公式のビルドガイドにざっと目を通してから着手しました。\n準備 ビルドログにもあるようにPCBがリバーシルブなので、作業中に迷子にならないようにこんな感じで表にマスキングテープで目印をつけておきました。\n今回から耐熱ワーキングマットで作業をすることにしました。机の天板に傷つくの嫌だし。 気兼ねなくはんだできるのでおすすめです。\nhttps://t.co/0qntPD8qIa\n2ヶ月ぐらいにここで買いました！\n\u0026mdash; 西田和史(k.bigwheel) 開発基盤EM (@k_bigwheel) November 11, 2020 ダイオード、OLEDソケット、コンスルー、TRRSソケット、 こちらは前回のCorneとほぼ同様だったのでビルドガイド通りに進めます（写真撮り損ねました。。。） 前回との違いはダイオードの形です。 表面実装するタイプのダイオードなので向きに気を付けつつ、つけていきます。\nビルドガイドに向きやダイオードのつけ方が紹介されています。 拡大鏡とピンセット必須ですね。 前回同様に、ここまででいったんqmk_toolsでファームウェアをインストールして、ピンセットを使いながらキーの認識とOLEDの動作確認を行いました。 今使っているファームウェアがあるのでそれを入れて問題ないかを確認しました。\nLED実装 今回のメインイベントです（そして苦杯をなめたイベントでもあります）。 ビルドガイドにも記載がありますが、信号が流れる順番があるようなので1番から取り付けていきます。 また、ビルドガイドにLEDに関する注意事項もいくつか掲載されています。必ず読みましょう。\nこの1～6までのLEDがすごく大変でした。。。\n表面実装のLED（Underglow LED）で四苦八苦 いくつかのブログを参考にしながら作業を進めました。\nコルネキーボードを作りました ～LED取り付けに四苦八苦記～ | キオクノロンダリング SK6812miniの仕様などについて書いてあります。デバッグするのにすごく役に立ちました。 Corne Chocolateビルドログ - nokの雑記 手書きでどんな感じでやればいいのかを解説してくれています。最終的にはこの方法が一番だったのかも？ 自作キーボードキット「Corne Cherry」のレビュー - 自作キーボード温泉街の歩き方 あとで出てきますが、リカバリ方法の参考になりました。 皆さん苦労されてますね、そして私も苦労しました。。。\n試してみた方法、考察は次の通りです。\nLEDチェック用のファームウェアをインストールして1つつけては動作確認 HelixのLEDテスト用ファームウェアをインストールしました。 白光 1C型こて先 失敗した後にリカバリするために購入しました。 LEDのランドなどが2Cよりも面積が小さいので、そのサイズに合わせたこて先のほうがよかったようです。 はんだの温度（温調できるはんだごて必須） 最初は250℃でやっていましたが、なかなかはんだが溶けません。そのせいで焦りも出てきます。 最終的には270度で作業しましたが、温度のせいでLEDが壊れたのはなかった気がします。1Cのこて先だったので無事だったのかもしれません。 フラックスなし あると楽だったのかも？残念ながら試してないです。 予備はんだ手法（だめっぽかった） 基盤のランド4か所に予備はんだをし、はんだを温めつつLEDを乗せる方法 LEDの裏にも予備はんだ どちらも試してみましたが、温めている個所以外のはんだと高さの違いが出てしまい、LEDが浮いてしまいます。4か所を同時に温めることはできないので、すこしずつ調整しているうちにLEDを物理的に壊してしまうことがありました。。。 ちょっとコツが分かったかも？ pic.twitter.com/ruwrmEWCAe\n\u0026mdash; Jun Ohtani (@johtani) November 19, 2020 わかった気になっていますが結局失敗しました。。。\n結局最後までこれというコツはわかってない気がします。結局3つか4つのLEDがお亡くなりになりました。 うまくいかなかった原因は、予備はんだで傾きなどができ、それを修正していくうちに基盤やLEDにダメージを与えてしまったのだと思います。\nよく見ると基盤が一部剥がれかけてるのがわかるかなぁと。\nリカバリー 右手側の表面実装の4番と5番が失敗しました。\n4番目（以下のツイート右側画像の上） こちらは、1度付けたLEDをはがすときにはんだを取り除くのが不十分な状態でLEDをはがしたために、基板のランドごとはがれてしまいました。 なのでここはLEDはつかないです。。。 5番目(以下のツイート右側画像の真ん中あたりの黄色い線がつながっているLED) LED自体はつけてありますが、青色しか発光しなくなっています。 4番目が完全に死んでしまったので、無事な3番目のLEDのDINに流れている信号を 5番目のLEDのDINにも流れるようにするために10芯コードでショートカットさせました。 （リカバリ方法は先ほど紹介したブログが非常に参考になりました、先人の知恵ありがたし）。 黒い線も売っていたのですが、自戒も込めて目立つ色にしてみました。\n勉強させていただきました、、、 pic.twitter.com/Zp16fJKziM\n\u0026mdash; Jun Ohtani (@johtani) November 22, 2020 ちなみに、左側のショートカットのコードはつけた後に1か所LEDの向きが違うことに気づき必要なくなっています （上記の基盤が傷ついている画像をよく見ると上下が逆になってるのがわかる人にはわかるかも）。\n片方は導線なくて良くなった。表から見たら向きが違うのに気がついたわ、、、 pic.twitter.com/7TSDMPPxlX\n\u0026mdash; Jun Ohtani (@johtani) November 22, 2020 最終的に2か所おかしいLEDにはなりましたが、幸いにもアンダーグローです。 Kochi Keyboardさんで購入したキットのボトムプレートはFR4なのでほぼ見えません！（負け惜しみ）\nソケット さて、気を取り直してソケットをつけていきます。 Dozen0にて経験済みなのでそれほど手間はかかりませんでした。 LEDの失敗の時に1Cのこて先を購入していたため、ソケットの横の隙間からこて先が差し込めたのが便利でした（LEDでダメージを受けていたのもあり写真撮り忘れ）。\n完成 ということで完成です。デフォルトで赤く光ってます。キーキャップがLEDを透過してくれるタイプだったのがこれまたよかったですね。 作る前は光らなくてもなんて思ってたのに。\nキーマップ(v2) Corne Lightで作業を数週間ほどして、いくつか入力しにくい部分があったのでマッピングを少しだけ変えました。 相変わらず日本語キーボードベースですが、数字のレイヤーにいくつかの記号を使えるように割り当てました。 コーディングをするときに、ライブラリのバージョン（例：7.10.0とか）やIPアドレスを入力していてレイヤー切り替えのためのキーを押したり話したりするのは効率が悪すぎたためです。 数字との組み合わせでよく使いそうな以下のキーを数字のレイヤーに移動しました。\nセミコロン（JP_SCLN） コロン（KC_QUOT） アンダースコア（JP_UNDS） コンマ（KC_COMM） ピリオド（KC_DOT） スラッシュ（KC_SLSH） #include \u0026#34;keymap_jp.h\u0026#34; const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = { [0] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_TAB, KC_Q, KC_W, KC_E, KC_R, KC_T, KC_Y, KC_U, KC_I, KC_O, KC_P, JP_MINS, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, KC_A, KC_S, KC_D, KC_F, KC_G, KC_H, KC_J, KC_K, KC_L, JP_SCLN, KC_QUOT, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, KC_Z, KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_COMM, KC_DOT, KC_SLSH, KC_RSFT, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, MO(1), KC_SPC, KC_ENT, MO(2), KC_RALT //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [1] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_ESC, KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0, KC_BSPC, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, KC_LEFT, KC_DOWN, KC_UP,KC_RIGHT, JP_SCLN, KC_QUOT, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, JP_UNDS, XXXXXXX, KC_COMM, KC_DOT, KC_SLSH, XXXXXXX, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, _______, KC_SPC, KC_ENT, MO(3), KC_RALT\\ //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [2] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_TAB, JP_EXLM, JP_DQUO, JP_HASH, JP_DLR, JP_PERC, JP_AMPR, JP_QUOT, JP_LPRN, JP_RPRN, JP_CIRC, KC_BSPC, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, JP_MINS, JP_EQL, JP_LBRC, JP_RBRC, JP_YEN, JP_AT, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, JP_UNDS, JP_PLUS, JP_LCBR, JP_RCBR, JP_PIPE, JP_TILD, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, MO(3), KC_SPC, KC_ENT, _______, KC_RALT //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [3] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. RESET, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| RGB_TOG, RGB_HUI, RGB_SAI, RGB_VAI, RGB_SPI, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| RGB_MOD, RGB_HUD, RGB_SAD, RGB_VAD, RGB_SPD, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, _______, KC_SPC, KC_ENT, _______, KC_RALT\\ //`--------------------------\u0026#39; `--------------------------\u0026#39; ) }; LEDの色が変えられる！（気づくの遅い） あと、キーマップを変更しているときに4つ目のレイヤーにRGBなどのボタンがあるのに気付いて押してみたら、LEDのパターンや色を変えることができるのに気付きました。 （遅すぎでは。。。）\nキーキャップが白いのもありこんな感じの色にしてみています。\nユニコーンガンダムっぽくなった pic.twitter.com/vHxZkMrYyP\n\u0026mdash; Jun Ohtani (@johtani) November 28, 2020 まとめ ということで、失敗も多々ありましたがキーボードとしてはちゃんと動くできたものができたので安心しました。 今後、状況が落ち着いてきて自宅以外で仕事をするときにはCorne ChocolateをPCと一緒に持ち歩くと思います。 薄くて邪魔にならなくてよさそうです。\n今回もはんだっしゅ太郎大活躍でした。本当に買ってよかった。 LEDがつかないときはちょっと落ち込みましたが、これのおかげで立ち直れたのもありますし。 あとは、試行錯誤しつつLEDとかの理解ができたのも楽しかったです。 キーマップの変更時にLEDの変更などができるのに気づいたのはちょっと遅すぎたので、qmkの仕組みや割り当てられるキーにどんなものがあるのかをもう少し研究したいなと思います。\nさて、次はどんなことを試すかなぁ。\n","date":1607004824,"dir":"post/2020/","id":"a46c601d03a3a26bc418d0096fe83a42","lang":"ja","lastmod":1607004824,"permalink":"https://blog.johtani.info/blog/2020/12/03/build_corne_choc/","publishdate":"2020-12-03T23:13:44+09:00","summary":"はじめまして、pyspa。 ということで、pyspa Advent Calendar 2020の4日目(大谷コンビの2号)の投稿になります。 コンビそろってキーボード記事です","tags":["DIYキーボード","misc"],"title":"Corne Chocolateを組み立てた #DIYキーボード"},{"contents":"前回のブログのまとめに書いたように、セパレートタイプのキーボードであるCorne Light v2を作成したのでそのビルドログです。DIYキーボードとしては2つ目になります。\nまとめで書いていたお店が開店したので、購入してみました。 購入したのはこちらのKOCHI KEYBOARDさんです。 ついこの間オープンしたばっかりのお店です！\nなんで作ったの？ スプリット型（セパレートタイプ？どっちが正しいんだろう？）のキーボードに興味があって、KOCHI KEYBOARDさんで買えたのがこれだったというのが大きな理由です。こういうのってタイミングだと思うので。 あとは、組み立てていくのがプラモデルみたいで面白いというのもあります。 基本的にここのところ自宅で仕事をしているので、ノートPCのキーボードにこだわる必要もないなというのも理由ですね。今後も当面は自宅で仕事になると思いますので。\nCorne Light v2 foostanさんが設計された（って言い方であってるのかな？）、3x6のサイズに親指の3キーが配置された分離型のキーボードの一種です。 シリーズ？の名前としてはCorne Keyboardと呼ばれています。 （そういえば、由来は何だろう？自作キーボードがどうやって設計されていくのかという流れがまとめられた作者の方のブログがおもしろいです。） また、基板の設計などがGitHub上でMITライセンスで公開されています。 オープンソースなハードウェアというのも面白いです。\nビルドログ 作者の方がビルドガイドを公開してくれています。ですので、こちらに沿って作業をしていきます。 ちなみに、私は今回Gateronのクリア軸を選択してみました。さらさらと入力できるのが好きなので。 サイレント軸にも興味はあるのですが、今回は実際にスプリット型のキーボードを早く触ってみたいというのが勝ちました。キーキャップについては後述します。 ツイートに都度、写真をアップしていたので組み立ては画像でお楽しみください（時々取り忘れてるけどｗ）。\nうむ pic.twitter.com/svW9WdzaZv\n\u0026mdash; Jun Ohtani (@johtani) October 21, 2020 刺して曲げる pic.twitter.com/M0jfQJg2k8\n\u0026mdash; Jun Ohtani (@johtani) October 22, 2020 両方できたと。ハンダまでやって今日はおしまいにすっか pic.twitter.com/HgsSrxqpcg\n\u0026mdash; Jun Ohtani (@johtani) October 22, 2020 写真取り忘れたけど、ProMicroつけた pic.twitter.com/RS4z0lqsUZ\n\u0026mdash; Jun Ohtani (@johtani) October 22, 2020 OLEDもついたと。今日はここまで pic.twitter.com/p6Z8MMP0Xz\n\u0026mdash; Jun Ohtani (@johtani) October 22, 2020 ここまでは順調です。\nOLEDがつかない？ ビルドガイドに従って、この後キースイッチをつけちゃうと問題の切り分けが難しくなるということで、 ここまでの段階でQMK Toolboxを使ってProMicroにファームウェアを書き込んで、それぞれのキーのソケットの取り付け部をピンセットでショートさせつつ、キーが入力されるかどうかを見ていきます。 QMK Toolboxについてはサリチル酸さんのブログがわかりやすいので参考にさせていただきました（わかりやすい記事をありがとうございます）。 で、ビルドガイドにあるように動いてるかを確認しようとしたのですが。。。\nさて、ファームウェア書き込んだけど、OLEDがつかないな。どっかつながってないのか？\n\u0026mdash; Jun Ohtani (@johtani) October 24, 2020 ビルドガイドのようにはいかず。。。 USBでPCとつないだ状態で、QMK Configuratorをサイトで開いて、キーボード入力テストを開くと、ショートさせたキーがPC側で認識されているかのテストができます。 これで、一通りキーは認識できていそうだというのはピンセットでショートさせながら確認しました。 ただ、OLEDには何も表示されないんです。。。\n前回Dozen0を組み立てた時に、ソケットのはんだ付けが甘かったというのもあったので、 OLEDやソケットのはんだを温めなおしたりしてみて、何度か確認してみたものの特に進展がなしです。 （ちなみにうまくいかないのもあって、ぼけたツイートしたりもしてます。）\nまぁ、OLEDはビルドガイドを見てもオプション扱いなので、それよりも触ってみたい衝動に駆られて、 キースイッチをはんだ付けしていきます。\nちなみに昨晩、OLEDはとりあえず置いといてって感じでキースイッチつけてた。キーキャップはまだない pic.twitter.com/SzLmzNg60Y\n\u0026mdash; Jun Ohtani (@johtani) October 26, 2020 それも終わって、問題点の切り分けに何かできないかな？と思ってやったのがOLED単体でArduinoと接続してみて動くかどうかです。 Qiitaにちょうどいい感じの記事を見つけたのでこれまた参考にさせていただきました(4本のジャンパー線を一人で持ちながら確認するの大変だったｗ)。\nはんだでの修正にしっぱい で、自分の中での結論として、「OLEDソケットのはんだ付けが怪しい」となりました。 そこで、まずは外してみようかと思ったのが間違いでした。 はんだごてとはんだ吸い取り線で何とか外せるだろうと思っちゃったんですよ。 OLEDピンソケットは足が4本あって、とりあえずとれるところまではんだ吸い取り線で吸い取ってみましたが、 さすがに基盤の穴に流れ込んだはんだまでは吸い取れず、頑張って温めながらソケットを抜こうとがんばって、 ラジオペンチでピンソケットを引っ張りながら引き抜きました。かろうじて引き抜きはできたのですが、ソケットは足が折れてしまいました。\n作者登場（OLED問題の解決） そんなところにCorneの作者の方がツイートを拾ってくれたみたいで以下のような返信を頂きました。\nOLEDが点かないのはファームのせいかもしれません(最近以前のファームで動かない新しいタイプのOLEDモジュールが出回るようになりました)。お手数ですが、https://t.co/vfSBfIeeJX のブランチのものを試して頂けますか？(ただいまPRレビュー中でまだマージされていない状態です)\n\u0026mdash; c7s (@foostan) October 25, 2020 暗闇に光明とはこのことです。 教えていただいたブランチを手元でビルドしてファームウェアを書き込むと、\nすごい、出ました！右側のディスプレイにロゴが。ありがとうございます（左側のOLEDはソケットのはんだ付け直し失敗したのでもうちょっと先になりますが）！\n\u0026mdash; Jun Ohtani (@johtani) October 26, 2020 なんと、ファームウェア書き込んだ瞬間にOLEDが点くじゃないですか。 感謝感激ってやつです。お礼を言うのに便乗してOLEDの問題の切り分けの方法についても聞いてしまいました。\nOLEDリベンジ 片側は無事だったのですが、もう一方は修復が困難になったので救世主を発注します。 自作キーボードの作成に便利なものリストとして、いくつかのブログに上がっていたのですが、必要ないだろうと見送っていたツールです。\nAmazon | サンハヤト はんだシュッ太郎NEO 45Wタイプ HSK-300 | ハンダゴテパーツ 本当にすごく使いやすかったです。 OLEDのピンソケットが修復不可能だったのですが、ProMicro用に付属して余っているピンヘッダがちょうどいい長さでした。 なので、これを4本分切り取り、OLEDモジュールにつけてしまったOLEDヘッダピンを抜き取って、代わりに切り取ったピンヘッダをつかって、OLEDと基盤を直接はんだ付けすれば修復できそうだと判断しました。\nはんだシュッ太郎君を使ってOLEDについてるヘッダピンをまずは除去。 そのあとはこんな感じで繋げました。\n見にくいかもだけど pic.twitter.com/YAHoxjgppN\n\u0026mdash; Jun Ohtani (@johtani) November 5, 2020 取り外しにくくはなったけど、無事両方のOLEDが点くのも確認できました。やったー。\nヤッター、両方のOLEDがついたよー pic.twitter.com/6KLDWvnaEC\n\u0026mdash; Jun Ohtani (@johtani) October 28, 2020 キースイッチがご機嫌斜め キーキャップは別途、AliExpressで発注をかけたのですが、ここまで来たら待ちきれないですよね？ ということで、手元にあった上海問屋のキーボードのキーキャップが同じMXキースイッチ用のものだったので移植しました。キーキャップ付けてみないとわかならいものですね、1つだけキースイッチがうまくはまっておらず、斜めについているのがこの時点で判明しました（ボトムプレート付けた後だったので、プレート外してから、はんだで修正）。\nちなみにキーキャップはめてる途中で、一箇所キースイッチが斜めにはんだ付けされちゃってるのを発見して慌てて直しました。 pic.twitter.com/qofHp3o4Pc\n\u0026mdash; Jun Ohtani (@johtani) October 30, 2020 無事使えるようになりました。\nアンスコが打てない＆Escどこ？ キーキャップ付けたので仮運用ということで、まずはデフォルトのキーマップをもとにどんな感じで入力できるのかを試してみました。 ここにも罠がｗ ブラウザでQMK Configuratorを開いてデフォルトのキーマップを確認しながら試し打ちをしていたのですが、どうも思ったのと違う動きをしているキーが。\nまずBASEレイヤー（レイヤー0）の右側のシフトと、LOWERレイヤーやRAISEレイヤーのEscです。 入力しているとどうも、右のシフトがEscで、レイヤーを切り替えてもTabのままだなと。 しょうがないので、OLEDが出なくてもいいのでQMK Toolboxでダウンロードしてきたものを利用したら想定通りなのにと。 きちんとqmk_firmwareの構成を理解しないままやってたつけでしたね。 結論としては、OLED用に教えてもらったブランチではキーマップが書き換わっていたようでした。 make crkbd:defautでビルドした時に利用されるkeymap.cがキーマップの定義が書いてあるファイルです。 qmk/qmk_firmwareのリポジトリにあるkeymap.cとfoostanさんにもらったブランチでは差分があったみたいでした。\nおかげで、qmk_firmwareのkeymap.cの仕組みがわかったし結果オーライです。 問題があって調べるとどんな作りになってるかとかちゃんと確認できますしね。 手順通りにやってるだけで問題が起きないと、どんな仕組みになってるのかがわからないので人に聞きまくるしかできなくなっちゃいますしね。\nこれでEsc問題は解決したのですが、アンスコがどうしても入力できません。 自作キーボード以外はすべて日本語配列のキーボードを使用しているのもあり、 日本語配列のキーボードだとどうもキーのマッピングが異なるようだと。\nググって参考にしたのはこの辺でした。\n【QMK】JPキーコードでキーマップを定義する - 天高工房 自作キーボードキット「Corne Cherry」のレビュー - 自作キーボード温泉街の歩き方 そのほかにもVIAのファームなども試したのですが、どれもうまくいかず。 色々ググってみて最終的な解決策はkeymap.cでkeymap_jp.hというファイルが読み込まれていないので、日本語用の設定とかを読み込んでみたつもりがうまく反映されていないという感じでした。\nJISにする場合、keymap_jp.hっていうヘッダファイル読み込んだほうがいいです\n\u0026mdash; Yoshi Yamaguchi (@ymotongpoo) November 3, 2020 今の時点ではこんなキーマップにしてあります。 今後も日本語配列のキーボードをベースに考えていくつもりです。\n#include QMK_KEYBOARD_H #include \u0026#34;keymap_jp.h\u0026#34; const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = { [0] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_TAB, KC_Q, KC_W, KC_E, KC_R, KC_T, KC_Y, KC_U, KC_I, KC_O, KC_P, JP_MINS, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, KC_A, KC_S, KC_D, KC_F, KC_G, KC_H, KC_J, KC_K, KC_L, JP_SCLN, KC_QUOT, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, KC_Z, KC_X, KC_C, KC_V, KC_B, KC_N, KC_M, KC_COMM, KC_DOT, KC_SLSH, KC_RSFT, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, MO(1), KC_SPC, KC_ENT, MO(2), KC_RALT //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [1] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_ESC, KC_1, KC_2, KC_3, KC_4, KC_5, KC_6, KC_7, KC_8, KC_9, KC_0, KC_BSPC, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, KC_LEFT, KC_DOWN, KC_UP,KC_RIGHT, XXXXXXX, XXXXXXX, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, _______, KC_SPC, KC_ENT, MO(3), KC_RALT\\ //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [2] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. KC_TAB, JP_EXLM, JP_DQUO, JP_HASH, JP_DLR, JP_PERC, JP_AMPR, JP_QUOT, JP_LPRN, JP_RPRN, JP_CIRC, KC_BSPC, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LCTL, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, JP_MINS, JP_EQL, JP_LBRC, JP_RBRC, JP_YEN, JP_AT, //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| KC_LSFT, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, JP_UNDS, JP_PLUS, JP_LCBR, JP_RCBR, JP_PIPE, JP_TILD, //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, MO(3), KC_SPC, KC_ENT, _______, KC_RALT //`--------------------------\u0026#39; `--------------------------\u0026#39; ), [3] = LAYOUT_split_3x6_3( \\ //,-----------------------------------------------------. ,-----------------------------------------------------. RESET, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| RGB_TOG, RGB_HUI, RGB_SAI, RGB_VAI, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------| RGB_MOD, RGB_HUD, RGB_SAD, RGB_VAD, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX, XXXXXXX,\\ //|--------+--------+--------+--------+--------+--------+--------| |--------+--------+--------+--------+--------+--------+--------| KC_LGUI, _______, KC_SPC, KC_ENT, _______, KC_RALT\\ //`--------------------------\u0026#39; `--------------------------\u0026#39; ) }; キーキャップが待ちきれなくて この右下のトンガリがちょっと気になる pic.twitter.com/W0A0z67cns\n\u0026mdash; Jun Ohtani (@johtani) October 30, 2020 キーキャップが待ちきれなくて上海問屋のキーキャップを付けてみて、いろいろ試行錯誤してみました。\nあー。上下関係ないのか。だからみんなこんな感じにしてるのか？ pic.twitter.com/KTBlPLespr\n\u0026mdash; Jun Ohtani (@johtani) October 30, 2020 どのくらい離すのが良いか実験中 pic.twitter.com/ozK4WyBXY8\n\u0026mdash; Jun Ohtani (@johtani) November 2, 2020 キーキャップもいろいろあるのね 届いた。 pic.twitter.com/jccNW1ZcEM\n\u0026mdash; Jun Ohtani (@johtani) November 2, 2020 もう一個 pic.twitter.com/9y6qat4JiN\n\u0026mdash; Jun Ohtani (@johtani) November 2, 2020 とりあえずセミコロンの位置につけてみた。 pic.twitter.com/TDk5213IHi\n\u0026mdash; Jun Ohtani (@johtani) November 3, 2020 今はこのDSAプロファイルの青いグラデーションのキーキャップを使っています（Dukeはここにはいないですｗ）。 キーキャップのプロファイルはこれまた、サリチル酸さんのブログがわかりやすく書かれています（ほんとすごいなぁ。）。\n高さ調節 そのまま使っていたのですが、やはりもうちょっと奥側に高さがほしいなと。 ダイソーなどで打っているケーブルクリップがお試しには良さそうだったのでこんな感じで内側がちょっとだけ高くなるような感じにして使っています。\nこうなった。とりあえず仮運用 pic.twitter.com/VkhjawdhLM\n\u0026mdash; Jun Ohtani (@johtani) November 4, 2020 まとめ ということで、駆け足ですがCorne Light v2のビルドログでした。 いきなりフルキーボードから40％キーボードかつ異なる並びにしたので、 混乱しっぱなしですが、いい頭の運動になっているし、なにより作って動かすまでの間に いろいろと調べたり試行錯誤できたのがすごく楽しかったです。\nあとは、スプリット型＋Column Staggeredになったので「c」や「b」を間違えまくっていますが、 いい気付きでした。まだまだ記号とかの入力に慣れていないですが、ちょっとずつ身に着けていけたらなと。\nただ、もう次のキーボードをDIYしたい気持ちも出てきているので困っているところです。\n書ききれてないこともあるかと思うので、ここはどうしてるの？これはどうやったの？などあれば、Tweetなりコメントなりを頂けたらなと思います。いやぁ、DIYキーボード楽しいわ。\n","date":1604503527,"dir":"post/2020/","id":"b16bddd1a6d3e5f4136446bebe7ffbc7","lang":"ja","lastmod":1604503527,"permalink":"https://blog.johtani.info/blog/2020/11/05/build-corne-light-v2/","publishdate":"2020-11-05T00:25:27+09:00","summary":"前回のブログのまとめに書いたように、セパレートタイプのキーボードであるCorne Light v2を作成したのでそのビルドログです。DIYキーボードとし","tags":["DIYキーボード","misc"],"title":"Corne Light v2を作成した #DIYキーボード"},{"contents":"ヒゲが不評だったのでいつも通りの長さに切りました。\n前回「Windowsをお試し中」と書きましたが、いくつかソフトをインストールしたりしたので現状を忘れないようにブログに残しておきます（また同じ作業する予定なので）\nインストールしたものたち 今のところインストールしたのはこの辺。 特にコメントしたいものについてこのあと明記します。\nドライバインストール from CD MX Ergoのソフトインストール。接続はコネクター Windowsアップデート Chrome Visual Studio ビルドツール(Lindera用) JetBrains Toolbox IntelliJ CLion Rider Visual Studio Code Slack Teams Google Drive共有 Gitter Divvy for Windows Zoom DeepL Sophos Twitter for Windows Office 365 AutoHotKey WSL2 - Ubuntu Windows Terminal Rustup Git for Windows wsl-ssh-agent PeaZip Speccy Hugo (WSL2のUbuntuにapt-get install hugoした) PowerToys AutoHotKey 前回のブログに書いたように、カーソル系のEmacsショートカットが体に染みついて離れないのです。 そこで、ググって見つけた記事はこちら。 AutoHotKeyというツールが Windowsに常駐して、特定のキー入力の時に、別の操作を実行してくれるツールです。\n見つけた記事にあった、https://github.com/lintaro-jp/gtk-emacs-theme-like.ahkのキーマップをもとに、いくつか変更したものを使用させていただいています。\n書き換えたのは、以下の通りです。\nCtrl+\\でIMEの切り替え（Wnn風） Ctrl+kをEmacsと同じ挙動に（もとにしたキーマップでは、カーソルから行末までが削除されてしまう） Win+sでもファイル保存（Ctrl+sと同じ挙動に。デフォルトではCortanaが起動して邪魔くさいので） すごく快適です。そのうち、もう少し自分が使いやすいようにキーマップを追加していったりするかもしれません。 特に、Macのショートカットがしみついているものについてなどです（仮想デスクトップ切り替えとか？）\nPowerToys Divvyをインストールしたのですが、グローバルショートカットがうまく動かなくていまいちでした（なんでだろ？） そこでググって見つけたのが@ITのPowerToysの記事でした。 PowerToysはMS製のOSSツールで、GitHub上で公開されています。 中には「ColorPicker」、「FancyZones」、「File Explowrer Add-ons」など、複数のツールが入っています。 「FancyZones」です。\nWindowsでは、デフォルトで、アプリにフォーカスしているときにWin＋カーソルでウィンドウの配置場所をいくつか（左右どちらかに半分、4分の1(右上、左上など)）に配置してくれるAero Snapというものが動いています。が、上半分などデフォルトにない柔軟な配置を設定することができません。 MacではDivvyというツールをいれて、それを実施していたのですが、先ほど書いたようにWindows版はあるものの、なぜかグローバルショートカットが動かず、システムタスクトレイのアイコンをクリックしなければいけませんでした。\nそれを解消してくれるのがFancyZonesです。 FancyZonesの設定項目で、自分で画面上にどのような割り当て領域を作るかを設定できます。さらに、マルチディスプレイ、仮想デスクトップを使っている場合、それぞれのディスプレイかつ仮想デスクトップで個別にレイアウトが設定できるようになります。 レイアウトを設定した後は、Shiftキーを押しながらウィンドウを移動すると、設定した領域が出てきて、あとは、割り当てたい領域にウィンドウを移動するだけでその領域いっぱいにウィンドウをリサイズしてくれます。 また、設定を変えることで、Shiftキーを押さなくてもウィンドウ移動するだけで領域にリサイズすることも可能です。また、Aero Snapの機能をオーバーライドしてWin＋カーソルで動作させることも可能になります。\nWSL2 + Windows Terminal 三宅さんからコメントを頂いたので。\nもう少し幅広い感じですかね。あわせて Windows Terminal 使うとわりと快適です。\n\u0026mdash; miyake | ZEN (@kazuyukimiyake) October 15, 2020 なんとなく噂は聞いていましたがということで、MSのドキュメントを見ながらインストールしました。クイックスタートに則って作業するだけで特に問題なくUbuntuまで無事インストールできました。 Windows Terminalも同様です（クイックスタートで入れることになる）。\nGit for Windows + wsl-ssh-agent 少してこずったのがこちらです。 チュートリアルに記述はあったのですが、どちらで作業するのか？などが少しわかりにくかったので。ググって出てきた記事をもとに作用しました。\nRustのプロジェクトファイルをMacから丸ごとコピーしていたのですが、Git for Windowsを入れるまでは、CLion+Rust pluginの環境では、.gitファイルをきちんと認識してくれませんでした（この時WSL2と少し混同してた）。\n無事環境は用意できました。 作業の手順は以下のような感じです。 Macで使用していた.sshのディレクトリを持ってきて作業しました。\nWindows側での作業 Macから.sshディレクトリをc:\\\\Users\\johta\\にコピー Git for Windowsのインストール OpenSSHクライアントの設定 管理者権限でコマンドプロンプトを起動して sc config ssh-agent start=auto sc start ssh-agent [wsl-ssh-agent(https://github.com/rupor-github/wsl-ssh-agent)のインストール ダウンロードして.7zファイルを展開 wsl-ssh-agent-gui.exeとnpiperelay.exeをc:\\\\Users\\johta\\binに移動 c:\\\\Users\\johta\\bin\\wsl-ssh-agent-gui.exeのショートカットをスタートアップに作成 作成したスタートアップのリンク先に -setenv -envname=WSL_AUTH_SOCKを追加 Git BashでOpenSSHを利用するように設定 setx GIT_SSH C:\\\\Windows\\system32\\OpenSSH\\ssh.exe ssh-addで秘密鍵を登録 ssh-add .ssh/id_rsa WSL2のUbuntuでの作業 Ubuntuはgitがすでに入っていたのでインストールはスキップ git config --global user.name \u0026quot;Jun Ohtani\u0026quot; git config --global user.email \u0026quot;メールアドレス\u0026quot; mkdir .ssh .bashrcの最後行にwsl-ssh-agentのWSL2 compatibilityにあるexportからfiまでをコピー。この時、パスを自分のパスに変更すること(私の場合$HOME/winhome/.wslの部分を/mnt/c/Users/johta/binに書き換えました) これで、WSL2側では.sshのファイルを管理しなくても、Windows側のOpenSSHに接続してssh周りの処理をしてくれるようになりました。\nPeaZip wsl-ssh-agentが.7z形式で圧縮されていたので、ダウンロードしました。 とりあえずこれを入れてみたのですが、ほかにお勧めがあれば教えてほしいです。\nSpeccy CPUの温度やスレッドごとのCPU使用率などを見てみたいので入れてみました。 これもとりあえず入れてみた感じなので、ほかにお勧めのソフトがあれば教えてもらえればと。 リソースマネージャーでもスレッドごとのCPU使用率は見れたのですが、温度が見れなかったので。\nHugo + WSL2にあるUbuntuにsudo apt-get install hugoしてインストールしました。\nそこで、VS Code の Remote Extension です。WSL2 から ‘code’ で起動できます😎\n\u0026mdash; Daiyu Hatakeyama@Microsoft, Hack in ChatGPT (@dahatake) October 17, 2020 あとは、畠山さんに教えてもらったVSCodeのRemote - WSLを入れて、 WLSに接続した状態でVSCodeを起動して記事のMarkdownを書くと、VSCodeのターミナルを開くとWSL2に接続してくれて、hugoコマンドが実行できます。\nまとめ とりあえず、ブログが書ける環境ができました。 Mac上にあった各種プロジェクトのディレクトリをコピーして、Rustの開発もできるようになりました。\n今後も環境構築は続いていきます。Javaとか入ってないし。 SDKMan使ってたけど、切り替えどうしよう？とか。\nそういえばSDKMAN!をJDK切替に使ってたけど、結局windows側のパスは通らんので自力インストールになった。scoopがよさげ\n\u0026mdash; きしだൠ(K1S) (@kis) October 17, 2020 IDE系から呼び出すターミナルはWSL2がいいなぁとか。\nhttps://t.co/X4Jj4tih1I\n\u0026mdash; そーだい@初代ALF (@soudai1025) October 17, 2020 ほかにもおすすめなどがあれば教えてください！\n","date":1603029710,"dir":"post/2020/","id":"188c1ee5132a6752dfce5a0235354070","lang":"ja","lastmod":1603029710,"permalink":"https://blog.johtani.info/blog/2020/10/18/restart-windows-no1/","publishdate":"2020-10-18T23:01:50+09:00","summary":"ヒゲが不評だったのでいつも通りの長さに切りました。 前回「Windowsをお試し中」と書きましたが、いくつかソフトをインストールしたりしたので","tags":["misc","windows"],"title":"Windowsへの移行（その１）"},{"contents":"ヒゲが伸びてきて(試しに伸ばしてる)不評を買っている今日このごろです。\n自宅で作業することが多くなってきたので、自作PCでもと思っていますが、OSをどうしようか悩み中。 とりあえず、試しにWindowsにしてみるかということで、10年ぶりくらいにWindowsに帰ってきました (この文章はMacで入力してますが)。\nむかしむかし もともとはWindowsを使っていたのですが、Win7くらいに32bitと64bit混在の時期に、 Xkeymacsを利用するときに少し手間がかかるなぁと思ったのもあり、Macに移行しました。 Macだと自分がよく使うEmacsっぽいショートカットがデフォルトいろんなアプリで使用できる利点があったからです。\nただ、最近、TL上で光るPCとかを見てしまったのもあり、 自作PC(どちらかというとDIYかな?)熱が復活しました。 まだ、OSをWindows、Ubuntuのどちらをメインにしようかな?と悩んでいるところではありますが、まずはWndowsをちょっと試してみるかなと。\nまずは、やりたいことをちょっとリストアップしておこうかなと思います(きっと、先人の知見が集まってくるはず!)。\nどうしてもほしい機能 大学の頃にSunOSやSolarisを使用し、Emacsでメールを読んだしていたせいで、Emacsのショートカット操作が体から抜けない状態です(抜こうとしてないという話もあるが)。 ですので、社会人になってからWindowsを利用していたときはXkeymacsというソフトのお世話になっていました(神アプリでした。まだあるのかな?)。\nショートカット操作とか カーソル移動(必須) 上下左右：Ctrl+n、p、f、b 行頭、行末：Ctrl+a、e 編集 デリートキー：Ctrl+d Ctrl+hがバックスペースだけど使わないな、そういえば カーソルから行末までをカット：Ctrl+k 必須! カーソル移動がホームポジションから移動しなくてもいいのもあって、多用してしまっています。 これ、WindowsとかUbuntuでいい感じにできるのあるのかな? できれば、IMEやブラウザのURLのサジェストなどもこのカーソル移動で移動できると嬉しいです。 (昔はM-%とかで置換などもやってたけど最近はやらないな。)\nデスクトップ操作系 仮想デスクトップ やることごとにデスクトップを切り替えて使うので ウィンドウのリサイズ? DivvyというアプリをmacOSで利用中 自分で登録したサイズ(例：画面右半分)にウィンドウサイズを変更などがショートカットで可能 仮想デスクトップはあると思うけど、ウィンドウのリサイズの便利なツールあるかなぁ?\n利用するアプリ SNS、オンラインミーティング Twitter macOSではTweetDeckと夜フクロウを使用 Slack ネイティブアプリ Gitter ネイティブアプリ Chatwork ブラウザ Teams ネイティブアプリ Zoom ネイティブアプリ Google Meet ブラウザ Discord ネイティブアプリ(最近使ってないな) 色々使ってますが、最悪ブラウザで使う感じかな?\nオンラインストレージ Google Drive 同期アプリ使ってる Dropbox あんまり使ってない 開発系 JetBrainsのIDE Toolbox App IntelliJ CLion + Rust plugin Rider zsh macOSで標準になったから コマンド系 git SDKman ant gradle JDK Rust Hugo Jasper GitHubのIssueとかを見るネイティブアプリ 自分が関連しているIssueとかが楽に見える(メールだと埋もれてしまう) エディタ Visual Studio Code 開発系では?と思われるかもだけど、Markdownエディタとして使ってる Emacs by Homebrew 最近は起動してない その他 カレンダー macOSのカレンダーで複数のGoogleカレンダーを取り込んでる ScanSnap Ubuntuで使えるやつあるのかな? Mac miniにつないであるので、画面共有とかで入れればそれでOK 画面共有 winやubuntuからMac miniとか見えるかな? キーボード共有 macも使うので、KVMスイッチとかかな? マウス共有 MX ErgoのFlowを使うと行き来が簡単にできたので良さそう。 ただし、Ubuntuだとどうなるのか? システム監視系 CPUの温度とかCPU、メモリの使用率とか まとめ とりあえずこんなところです。カーソル移動系が一番重要なので、そのへんから色々とちょっとずつ試していく予定。 ぜひオススメアプリとかあれば教えていただければと。\n","date":1602727442,"dir":"post/2020/","id":"de37d9fae011687eb1eb5a127fcb89e3","lang":"ja","lastmod":1602727442,"permalink":"https://blog.johtani.info/blog/2020/10/15/restart-windows/","publishdate":"2020-10-15T11:04:02+09:00","summary":"ヒゲが伸びてきて(試しに伸ばしてる)不評を買っている今日このごろです。 自宅で作業することが多くなってきたので、自作PCでもと思っていますが、","tags":["misc","windows"],"title":"Windowsをお試し中"},{"contents":"今年の春くらいから、セパレートタイプのキーボードが気になっています。 また、なんか知らないですが、Twitterのタイムラインが自作キーボード(DIYキーボード)で盛り上がってる気がします。 (たぶん、気になってるから余計目についてる)。 これとか。このスライドから、自分がやってるのは「まだ」DIYキーボードだなということで、タイトルに使ってみました。\n#toruby \u0026quot;DIYキーボードは実質Ruby\u0026quot; 本日のスライドです! とちぎでこの話をできてよかった!!!q: https://t.co/RJot71Ngu9\n\u0026mdash; Kakutani Shintaro (@kakutani) September 12, 2020 セパレートタイプのキーボード 今年の夏まではMac Book Pro 16インチのキーボードを利用していました(参考:自宅の作業環境(2020))。 これまで、自宅で作業することよりも、外で仕事をすることが多く、また、外といっても様々な場所(サムライズムだったり、オフィスだったり、カフェだったり)で作業をすることが多かったので、ノートPCのキーボードにしていました。流石にキーボードを持って歩くほどは気にしていなかったので。\nただ、コロナウイルスの影響もあり、ほぼ自宅で作業することとなりました。 となると、前から気になっていたセパレートタイプのキーボードが俄然気になり始めます。 (といいつつ、寄り道してたりしますが)\n気になっていたのはこのあたりなのですが、\nErgodox EZ Moonlander Mark I 流石にいきなり行くにはちょっと気が引けるなぁと(なかなかいいお値段)。 また、自分が日本語キーボードを利用しているというのもちょっとあります。\nキースイッチの感触を知りたくて ただ、日々、楽しそうな自作キーボードの記事や画像が流れてきます。 で、思い出したのが自分の趣味。プラモデルです。色を塗ったりはしないですが、組み立てるのは楽しいなと。 じゃあ、趣味と実益を兼ねればいいのでは?(ほんとか?)となり、作る気になってきました。\nただ、全く知らない世界だし、どんなものなんだろう?と。 市販のキーボードでも、キーの押し具合が色々合ったり、形もまちまちです。 また、このご時世ですので、自宅からあまり出ていないので遊舎工房さんなどに遊びにも行けず。\nそんなところに流れてきたのがキースイッチのテスターでした(世の中誘惑だらけ)。\nスイッチテスター人気スイッチ詰め合わせ 18個セット 「なるほど、これでどんな感触かわかるじゃないか!」と、気づけばポチッと押していました。。。 届いて、「ふむふむ、これがこういう感触なのか。なるほど」ポチポチ押しながら、さらに自作キーボードについて調べていきます。\nいろんな感触なんだなぁ pic.twitter.com/PaGDMIRJiv\n\u0026mdash; Jun Ohtani (@johtani) September 22, 2020 キースイッチのストロークの深さを知りたくて まぁ、当たり前なのですが、先程のキースイッチテスターどこにもつながっていません。 キーボード触ってるとわかりますが、ストロークが違いがあるんですよ。 ただ、これだとわからない。けど知りたい。\nで、ググっているとArduinoを使ってLチカやってる人とか、キー入力させている人がいるじゃないですか。 これでは?そういえば、Arduinoもどきうちにもあるぞ?と。 で、準備をしていたときに見かけてしまったのがこのツイートでした。。。\nhttps://t.co/ALl7OcRVRa 高機能テスターとしてもおすすめ\n\u0026mdash; Kakutani Shintaro (@kakutani) October 4, 2020 やられてしまいました。。。\ndozen0作りました ということで、前置き長かったですが、Dozen0というキーボード(マクロパッド?)を遊舎工房さんから購入して作ってみました。 手順はビルドガイドという形でまとまっています。\n基本的にはこれに沿って作成しました。\nパーツと手順の確認 さてと。 pic.twitter.com/GTBJ7zDleN\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 まずは入っているパーツがきちんとあるか確認します。 また、ビルドガイドでどんな作業があるのかをざっと眺めておきます。 まぁ、プラモデルといっしょですよね。\nキットにはキースイッチとキーキャップは含まれていません。これはご注意ください。 私は、キースイッチテスターとして入手していたキースイッチとキーキャップがどんな押し具合なのかを確認したかったので特に問題ありません。\nハンダづけ Amazon | 白光 ダイヤル式温度制御はんだこて FX600 | ハンダゴテ Amazon | 白光 こて先 2C型 T18-C2 | ハンダゴテパーツ Amazon | 白光(HAKKO) セラミックヒーターはんだこて専用こて台 クリーニングスポンジ付き FH300-81 | ハンダゴテパーツ Amazon | goot(グット) 高密度集積基板用 鉛入りはんだ Φ0.6mm スズ60%/鉛40% ヤニ入り SD-60 | ハンダゴテ はんだ付け用に揃えた道具です。「自作キーボード ハンダゴテ」とかでググると出てきたものがこれだったので。 デフォルトのコテ先ではなく、2Cのコテ先に付け替えてから作業を開始しました。\n私の持っていたソケットはCherry MX系なのですが、気が向いたらKailh Chocも試したくなるかも?ということで、 すべてはんだ付けしました。本格的にはんだ付けしたのは大学以来だからもう20年近く経ってますね。 ソケットの足をプリント基板にはんだ付けするのですが、2Cのコテ先が大きくなかなか手こずりました(これがこのあと問題を引き起こしました)。\nソケット、リセットスイッチ、ProMicroをはんだ付けすればはんだの作業は終了です。\npic.twitter.com/jjUo162n54\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 pic.twitter.com/p5atvtHfFN\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 スイッチの取付と組みたて 試したいキースイッチを選んでトッププレートにつけていきます。\nキーテスターからスイッチとキーキャップ持ってきて完成。動作確認はまだなのでまた、最初に戻るかもだけど、、、 pic.twitter.com/ZmBd3bgOKI\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 組み立ても終わり次は実際の動作確認です(ツイートしていますが、予想通りの展開でした)。\nファームウェアの書き込み USBで接続して、ファームウェアの書き込みです。 書き込み手順はビルドガイドにありますが、QMK Toolboxの使い方やQMK Configuratorの使い方は以下のサリチル酸さんのブログがわかりやすかったです。\n（初心者編）自作キーボードにファームウェアを書き込む （初心者編）QMK Configuratorを使ってキーマップを書き換えよう 実際に書き込んで動かしてみると。。。。\nうーん、上半分が死んでる気がするなぁ。\nデフォルトキーマップの書き込みはできたけど、カーソルの上とかバックスペースが入らないw\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 とりあえず、もう一回確認してみた。デフォルトのキーマップで、「Cut」「Paste」が強く押さないと入力されない。UpとDeleteは動くようになってた。CopyとBkSpがうんともすんとも言わない。下段のキーは全部動く。https://t.co/zEyINdAK6t\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 といった具合に上半分が動作があやしいです。\n再度、はんだ付け ということで、ネジを外して上の段のソケットをはんだで温めてみると、片側だけ温めるとはずれるじゃないですか。 どうやら、うまくソケットの足が基盤にはんだ付けできていなかったようです。 この時、最初に作業したときに2C型のコテ先が大きくて、ソケットの足に入らなかったのを思い出したので、 最初にはんだごてについていたコテ先に戻してから作業をしました。 これだとソケットの足の隙間に入るんです。ということで、挙動のおかしい上段のソケットをすべてつけ直したところ無事動作しました。\n上の段、全体的にソケットがうまくはんだ付けできてなかったみたいだった。今回はMX系のスイッチしかないので、Kailh Chocのソケットの導通は未確認。ざっとブログにまとめるか。\n\u0026mdash; Jun Ohtani (@johtani) October 10, 2020 現在のキーマップ これが今のキーマップです。仕事中のBGMをラズパイ4の音楽プレーヤーで流していますが、 部屋から出るときや、打ち合わせがあるときに音楽の停止、開始などを画面共有経由でやっています。 が、わざわざマウス移動するのもめんどくさいなと。これに使えそうだというのもあったので、Dozen0を購入したというのがあります。 残念ながら、Prev Trackとかがうまく動かないので、ショートカットを調べてキーマップ書き換える予定ですが、非常に便利になりました。\nまとめ ということで、Dozen0を作ってみましたが、楽しかったです。すんなりと行かなかったのがまた良かったです。 試行錯誤して動いたときの喜びが何倍もありました。また、キースイッチの感触も知ることができました。 たぶんGateron Silentクリア軸もしくは赤軸くらいが良さそうだなぁと(こうやって沼へ。。。)。 キーマップの仕組みを調べたり、もっと面白い使い方できないかな?と探りつつ、次のステップに進もうかなと。\n次は本格的なセパレートタイプのキーボードを作る予定です。が、お店のオープンを待ってからということになってます。はやくオープンしないかなぁ!!\nがんばって!!\n\u0026mdash; Jun Ohtani (@johtani) September 29, 2020 ","date":1602428006,"dir":"post/2020/","id":"c377351433a941a927aab543931f6026","lang":"ja","lastmod":1602428006,"permalink":"https://blog.johtani.info/blog/2020/10/11/build-dozen0/","publishdate":"2020-10-11T23:53:26+09:00","summary":"今年の春くらいから、セパレートタイプのキーボードが気になっています。 また、なんか知らないですが、Twitterのタイムラインが自作キーボード","tags":["DIYキーボード","misc"],"title":"Dozen0を作成した #DIYキーボード"},{"contents":" 2020/10/06 11:00くらいにマージされました。\n@minoru_osuka さんが開発を引き継いだLinderaというKuromojiのRustクローンがあります(リポジトリ) 。 最近趣味でRustを勉強しているので、こちらを少し手伝っています。\nRustの勉強仲間である@takuya_bさんや@ikawahaさんと話をしているときに、FST部分をDouble Array Trieに置き換えると速度が向上するのでは?という話が出まして、@takuya_bさんがDouble Array Trieを作るらしいという話になったので、下準備などをしつつ、作ってもらったライブラリyadaを組み込んでみたという話です。\nベンチマークの追加 下準備として、今のLindera(FST実装)がどのくらいの性能なのか?というのを計っておく必要があります。 幸いにも、Linderaのオリジナルの開発者の方が、criterion.rsというライブラリを使ったベンチマークプログラムを作成してくれていました。\nただ、1種類だけだと少し心もとないなというのと、長い文章やパターンを増やしたほうが良さそうだなということで、 ベンチマーク自体をいくつか追加しました(追加したときのPR)。\n種類としては、5種類のベンチマークです。\nシステム辞書のみのTokenizerのコンストラクタ呼び出し カスタム辞書ありのTokenizerのコンストラクタ呼び出し システム辞書のみのTokenizerのtokenize処理の呼び出し カスタム辞書ありのTokenizerのtokenize処理の呼び出し 青空文庫の坊っちゃんのテキストをシステム辞書のみのTokenizerでtokenize 1,2はコンストラクタ部分だけの処理をベンチマークテストする目的で作成しました。 LinderaはTokenizerがtokenize処理するのに利用するデータをいくつか内部で保持しています。 これらはファイルにシリアライズされており、Tokenizerのオブジェクト生成時に読み込みやデシリアライズ処理が発生します。 この部分だけも速度を計測したい目的でコンストラクタだけを切り出しました。\n3,4はTokenizerのメインの処理です。コンストラクタはベンチマークの対象外にしました。 純粋にtokenizeの処理だけを切り出して計測するためです。 カスタム辞書がある場合、ない場合は念の為切り出した形になっています。\n5は長い文章(文章が多いのでバリエーションも増える)を扱いたいために別にしました。\nこれで、一応下準備が完了です。 ちなみに、Criterionは賢くて、前のベンチマークの結果と最新の結果を比較してくれる機能があります。 どんな感じで出てくるかはベンチマーク結果をご覧ください。\nyadaの組み込み ベンチマークの準備をしていたところyadaがリリースされたので、Linderaへの組み込みを検討し始めました。\nというわけで、またダブル配列を書いてしまったので crate として公開しました。フィードバックお待ちしております！ https://t.co/As7h0tfmjf\n\u0026mdash; takuya-a (@takuya_b) September 20, 2020 中身の理解 lindera-fstを利用して、prefix searchしている処理があるので、そこで利用しているFSTをyadaに置き換えれば良さそうだと判断して、 処理を読んでいきます。\nTokenizerは、PrefixDictという構造体でlindera-fstを利用している prefixメソッドが入力文字列を元に、FSTを前方一致検索して、ヒットした単語の情報をIteratorとして取り出せる(単語の情報は「入力文字列の先頭からの文字数」と「ヒットした単語のWordEntry構造体」) PrefixDictのfstは辞書(例：ipadic)ごとにlindera-\u0026lt;辞書名\u0026gt;-builderで生成される システム辞書としては、デフォルトではlindera-ipadic-builderでfstを構築している 構築処理はこの辺 という感じです。 また、辞書周りのファイルがそれぞれどんな役割なのか、どんなデータの持ち方をしているのか?といった点を、変更点の調査のついでに書き出してみました。lindera-dictionary/FILES.md。TODOになっている部分も追記が終わっています(PR)\n変更点 実際に変更したプログラムの詳細についてはのPRを見ていただくとして、簡単には以下の点になります。\nRustのバージョンを1.46.0に(おもにREADME.md) yadaが利用している機能に1.46.0で導入された機能があるため lindera-fstをyadaに変更(lindera-core/Cargo.toml, lindera-ipadic-builder/Cargo.toml) 合わせて、dict.fstというファイル名をdict.daに変更 dict.daに関して構築部分と検索部分を変更 FSTではFSTから返ってくる値(入力文字列に出てきた単語に関連する値)はu64だったが、yadaのDoubleArrayがu32しか扱えないため、u32に変更。テストの記述はしていないが、扱うデータ的にu32で問題なさそうだったので。 検索部分：PrefixDict構造体のprefixメソッドでDoubleArrayのprefix_common_searchを使用 DoubleArray自体がprefix_common_searchのメソッドを持っていたので、処理が簡単に置き換え可能だった。FSTはprefixメソッド内で独自で前方一致検索を実装していた。 構築部分：lindera-ipadic-builder/src/lib.rsのbuild_dictとbuild_user_dictのdict.da構築処理 ipadicのCSVファイルを読み込んで、見出し語をキーに、辞書にある単語情報のベクタを値とするBTreeMapを生成し、このBTreeMapに基づいてFSTを構築していた部分をDoubleArray構築処理に置き換えた。 シフト演算などで、実際の値(dict.vals)へのポインタを作っていたのだが、ここの処理を読み解くためにFILES.mdを書き出した。 という感じです。そもそもデータ構造がどうなっているのか?から読み解いて、変更部分を洗い出して変更していった形になります。 取り込み作業中にいくつかyadaに要望(このへん)を上げて、変更を取り込んでもらい、最終的にyadaのバージョン0.3.2で問題なく動きそうだという形になりました。@takuya_bさん、対応ありがとうございました。\nエッジケースバグの発見 作っててよかった、テストケースでした(実際にはベンチマークテストですが)。 取り込み作業中に、Lindera本体のcargo testはすべてOKになるが、ベンチマークを取ろうとしたときに、坊っちゃんの文字列を入力にしたベンチマークが失敗するという事象が発生しました(PRのコメント参照)。 切り分けのために、入力の文章のどこでおかしくなるのか?DoubleArrayのbuildメソッドに渡している値がおかしくないか?などをすこしずつ調べていくと次のバグが判明したという感じです。\n特定のデータ(ipadicの見出し語一覧)をDoubleArrayに入れて、特定の文字列(「は相」)をcommon_prefix_searchにいれたら、 返ってくる情報(0から何バイト目の文字が一覧に存在した)が、不正な値が返ってくるというバグでした。 @takuya_bさんに見てもらいつつ(DoubleArrayの中身わからん。。。)、修正してもらいました。素早い対応ありがとうございます。\nyada 0.3.1 をリリースしています。特定の条件で不正な遷移を許すダブル配列が構築されてしまうバグを修正しています。このエッジケースは @johtani さんが見つけてくださいました。ありがとうございました！ https://t.co/CiftZi5GDn\n\u0026mdash; takuya-a (@takuya_b) September 30, 2020 やはり、いろんな文字列入れてテストしてみるの重要ですね。 ということで、ベンチマークだけでなく、テストケースとしても坊っちゃんのファイルを読み込んでトークナイズするようにPRでテストケースを追加しています。\nベンチマーク結果 yadaを利用した変更が終わったので、再度cargo benchを実行して計測です。 計測としては、masterブランチでまずcargo benchを実行し、yadaの実装をしたブランチに切り替えてからcargo benchを実行します。 すると、Criterion? cargo benchが、最終的な結果に前回との差分でどのくらい性能が改善、改悪したかも合わせて出力してくれます。 実行環境と結果は以下のとおりです。\nMacBook Pro 16インチ CPU：Core i7 6コア 2.6GHz メモリ：32GB コンストラクタのベンチマークについては10%ほど性能が悪くなっています。 これは、FSTよりもDoubleArrayTrieのほうがデータが大きくなってしまうためだと思われます。 実際にファイルのサイズは次のようになりました。yada(DoubleArrayTrie)のほうが2倍以上大きいことがわかります。 また、このファイル以外にもLinderaが利用しているデータはありますが、それらは今回変更の対象にはなっていません。 なので、単純にこのファイルの読み込みの処理に時間がかかっているのだと想像できます。\n2147765 / FST / dict.fst 5425152 / yada / dict.da tokenizeのベンチマークについては、11%〜28%の改善が見られました。 文章から、内部に保持している辞書に存在する単語を見つけ出す処理に利用されるのがFST、DoubleArrayTrieです。 今回の変更では、この処理に利用しているデータ構造だけを変更しました。 実際には\nDoubleArrayTrieを用いた単語の検索処理 見つかった単語の持つ値(data.valsのオフセット情報)を元にシフト演算 といった処理が実行されます。シフト演算はu64だったものがu32に変更されたくらいなので、大した処理量ではないかと。 大部分はDoubleArrayTrieを利用したルックアップ処理が速度向上に寄与していると思います。\nまとめ 最近Linderaに加えた変更、作ったPRについて少しブログにまとめてみました。 ちなみに、まだPRの段階でレビュー\u0026amp;リリース待ちという感じです。\n実際には作ってもらったライブラリを組み込んでみたというだけなのですが、速度が向上した結果が見れたのは面白いです。 また、基本的なデータ構造とかアルゴリズムの勉強にもなりました(2次元配列を1次元配列に押し込むとか)。このへんも今後も勉強していきたいです。\n組み込む際に色々と協力していただいた@takuya_bさん、@ikawahaさん、巻き込んでくれた@minoru_osukaさんに改めて感謝いたします。\nRustや形態素解析のプログラムの勉強を兼ねて、今後もなにか改善できる部分がないかなどを見ていこうと思っています。 Rustで形態素解析をしたいという人がどのくらいいるかはわかりませんが、おかしなところや疑問点などあればコメントください。\n","date":1601865378,"dir":"post/2020/","id":"15932a656f7acfac897d27766eadc9e2","lang":"ja","lastmod":1601865378,"permalink":"https://blog.johtani.info/blog/2020/10/05/switch-fst-2-da/","publishdate":"2020-10-05T11:36:18+09:00","summary":"2020/10/06 11:00くらいにマージされました。 @minoru_osuka さんが開発を引き継いだLinderaというKuromojiのRustクローンがあります(リポジトリ)","tags":["Rust","Lindera"],"title":"LinderaのFSTをDoubleArrayTrieに変更した話"},{"contents":"先日は「検索システムを構成するパーツ」ということで検索システムを構成しているパーツについて書いてみました。\n大体、検索がうまくヒットしないといった場合に、問題になるのがコンテンツ自体のデータもしくは、転置インデックスのキーワードだったりします。 そこで今回は、前回のパーツの「データソース・コンテンツ」周りについて少し書いてみようと思います。言葉の定義、それぞれがどんなことをやるのか、とりあえず導入したあとにコンテンツ周りでどんな改善ができるかなどを書いてみます。\n言葉の定義 コンテンツ 実際に検索させたいデータになります。 コンテンツにはWebページ、データベースのレコード(CMSで登録されたデータなど)、ファイルサーバーにある文書(PDF、Word、Excelなど)などになります。\nデータソース コンテンツのマスタデータが保存されている先です。 よくあるデータソースとしては以下のものが考えられます。\nWebサイト - 自社もしくはインターネットに存在しているWebサイトです。 ファイルサーバー - ローカルネットワーク上のファイルサーバーもありますが、最近ではGoogle DriveやDropboxといった外部のWebサービスもあります。 RDB - CMSや自社システムでのデータの保存先です。 クローラー コンテンツをデータソースから収集してくるプログラムのことです。 Webサイトやファイルサーバーからコンテンツを収集して検索エンジンに登録するところまでを担当します。 RDBにあるデータを検索エンジンに登録する場合はクローラーがデータを登録するというよりは、RDBにデータを登録するシステムが検索エンジンに登録する機能を持っていることが多いです。\nデータの収集と登録 収集 クローラーを使用した収集の場合は、サービスの特性とデータソースによって、どの程度の頻度でクロールするのか、クロール対象はどこまでか?といったものを決める必要が出てきます。 これらが決まれば収集ができるかと(他に権限とかもありますが。)。 収集コンテンツは、そのままでは利用しにくかったり、利用できないことがあるので、次はデータの変換を行います。\nデータ変換 コンテンツはそのままの形では検索エンジンには扱いにくいデータ形式である場合があります。\nWebページの場合 Webページの場合、コンテンツにはHTMLタグが入っていたり、JavaScriptなど検索対象にはしたくないデータなどが入っています。これらを除去して、検索させたいものを取り出す必要があります。 また、Titleタグなど、いくつかメタデータとして扱えるものがHTMLで規定されているので、これらを別の項目として取り出して個別に検索できるようにすると便利です。 HTMLをパースしてデータを抜き出す処理ができるライブラリなどがあるので活用します。\nファイル PDFファイルなど、ファイルの場合もメタデータと呼ばれるファイル自体が持っている情報が存在します。作成者、更新日時、ファイル名、パスなどです。 これらも検索時に有効な情報になります。 また、ファイルから文字列を抜き出す処理も必要になります。 それぞれデータフォーマットが異なりますので、そのフォーマットに合わせて文章データを抜き出す処理が必要です。OSSや製品がありますので、それらを利用して、ファイルから文章を抜き出します。\nRDB RDBのデータの場合、データが正規化されています。 検索エンジンでは、非正規化のデータを登録して検索することが基本となるため、まずは非正規化して取り出す必要が出てきます。\n例えば、ジャンルやカテゴリ、各種IDなどが実際のコンテンツのレコードに入っていると思いますが、これらをユーザーが入力したキーワードで検索したい場合などは、IDではなく表示名を取り出して、検索エンジンに登録する必要が出てきます。\nその他 データごとの変換処理について説明しました。 その他に、データのクリーニング処理などと言ったことも必要になってきます。例えば、HTMLのタイトルに必ずサイト名が入っているが、除去したいといった場合や、検索エンジン固有のデータの前処理などもあります。\n登録 最後は検索エンジンへの登録です。 最近の検索エンジンはJSON形式でデータを受け取る場合が多いので、JSONに変換することが多いです。 基本的には各種プログラミング言語のライブラリが用意されているのでこれらを利用するのが基本となります。\n検索したい項目、検索させたい方法などを洗い出し、必要なデータを作成して検索エンジンに登録します。 登録と書いていますが、更新、削除などもここでの対象となります。\nここまでの流れで、データソースからコンテンツを取得し、変換して、検索エンジンへの登録が終わりました。\n検索の改善 検索のログから分析して改善していくのが良いですが、ユーザーからの質問や意見などからも改善すべき点が見えてくると思います。 検索ログでは、次のようなものを元に、検索がうまく行かないものを見つけ出します。\n0件ヒット 0件クリック ヒットしていない検索ワードがある場合、コンテンツに問題がある場合があります。まずはこのあたりをとってみるのが良いかと。 そもそも、入力されたキーワードにマッチするコンテンツを扱っていないこともわかりますし、入力されたキーワードに似た単語を持ったコンテンツなども存在するはずです。 類義語の辞書を用意して、検索にヒットできるようにするといった分析と改善にも利用できます。\nあとは、検索エンジン側の話ですが、形態素解析器などを利用している場合に、意図した区切りになっていないために、うまくキーワードがヒットしないと言ったこともあります。\nコンテンツの理解 実はこれが一番だったりします。 どんなコンテンツを自分たちが扱っているのか?どんなデータがどういった項目でコンテンツに入っているのか?といったところから、 コンテンツのデータを元に検索にヒットさせる方法が改善できます。\nCMSなど人が入力したデータをコンテンツとして扱う場合、入力画面を改良することで、望んでいるデータを入れてもらえたり、不要なデータが入らなくなる可能性があります。 例えば、ECサイトなどで商品の説明文やタイトルにいろいろなキーワードが入っている場合などがあります。むりやりどんなキーワードでもヒットさせたいという入力者の意図もあるのですが、検索しているユーザーにはノイズになることも多いです。適切にカテゴリやジャンル、属性といった項目に分けることでおかしな入力データを減らすことも可能です。\nWebサイトなどをクローリングしたものの場合は、サイトごとに文章の特徴があったり、重複している部分などが合ったりする場合があります。 これらもコンテンツをよく調べることで、不要な情報を除去したりといったことが可能になります。\nまとめ 簡単ですが、検索のデータソースやコンテンツにまつわる話を紹介しました。 もちろんここでは紹介しきれていない項目がいっぱいあります。 また、具体例ではなく概略をざっくりと書いているのでわかりにくい場合もあるかもしれません。 すこしユースケースを絞り込んで書いたほうがわかりやすくなるのかも?\n次はUIとか書くかも?\n不明点とか疑問点、指摘事項などあればコメントしていただければと。 要望などもお待ちしております。\n","date":1600136614,"dir":"post/2020/","id":"b2c4cf0fb96d02d37f03668caaecbc57","lang":"ja","lastmod":1600136614,"permalink":"https://blog.johtani.info/blog/2020/09/15/improve-search-no3/","publishdate":"2020-09-15T11:23:34+09:00","summary":"先日は「検索システムを構成するパーツ」ということで検索システムを構成しているパーツについて書いてみました。 大体、検索がうまくヒットしないとい","tags":["検索"],"title":"検索対象のデータとデータソース(検索システムに関する妄想その3)"},{"contents":"自宅環境に少しアップデートがあったので更新版です。 お客さんのおかげで相変わらず自宅で作業させてもらってるのもあり、昨今のコロナウイルスの影響で出かけることもないので、自室の作業環境が更新されている感じです。 前回のブログはこちらです。 前回のまとめで触れていた2点について更新されています。\nまずは、現状のデスクの上の写真です。\n基本的には前回紹介したものと大きくは変わっていません(?)。 変わったものについて紹介していきます。\nデスク 先程の写真ではちょっとわかりにくいですが、スタンディングデスクになりました。\nタイマーついてるの便利 pic.twitter.com/E9engTIMnM\n\u0026mdash; Jun Ohtani (@johtani) April 30, 2020 Flexispotの天板と足の組み合わせにしました。 前のElectaの天板が明るめの色だったのもあって、メープルの天板です。 組み立てはちょっと大変でした。 足が重たいのと、天板にはネジ穴がなく電動ドライバーもないので、ネジ締めと机を起こすのがちょっと大変です。子供に手伝ってもらいながら組み立て設置をしました。 オンラインミーティングなどのときには基本、立って作業しています。 あとは、デフォルトのタイマー設定のままですが、45分ごとに立ったり座ったりを数回繰り返す感じです。\nAmazon | FLEXISPOT オフィスデスク用天板 スタンディングデスク120×60cm Amazon | FLEXISPOT スタンディングデスク 電動式 昇降デスク メモリー機能付き ブラック EN1B（天板別売り） スタンディングデスクマット フローリングに45分立ちっぱなしだと結構、足の裏がつかれるんですよ。なので、クッション性が高いフロアマットを立ってるときは利用しています。ちょっとめんどくさいのですが、椅子のときは壁に立て掛けて、立つときにマットを敷くようにして使っています。\nちなみに、ウレタン素材なので開封直後はすごい匂いでした。。。 数日は陰干しみたいなのが必要です、ご注意を。 ただ、これを利用してから膝やかかとが痛いことはなくなっています。\nAmazon | 疲労軽減マット スタンディングデスクマット 滑り止め加工 立ち仕事 耐水 耐油 耐菌 (ブラック, 75cm*50cm*2cm) ケーブルトレー スタンディングデスクだとケーブルをぶら下げた状態だと危なそうだなということで、ケーブルトレーも机の下に追加してあります。電源タップを配置して、ディスプレイなどの電源はこちらから取るようにして、ケーブルトレーからは電源タップとスタンディングデスクの電源コードを垂らすという感じです。実際にはLANケーブルも伸びてたりはしますが。。。 また、後で出てくるラズパイ+SSDも最近こちらに移設しました。 最初にチャコールグレーを発注したのですが、配送日が未定になったので、Lサイズのシルバーを発注するという慌てようでした。 結局、今は両方使っています。テーブルタップにラズパイと、結構乗せるものがあるんですよね。見えない場所だし、色が揃ってないのは気にならないかなと。\nAmazon | プラス Garage ワイヤーケーブルトレー Lサイズ 幅63.7cm シルバー Amazon | プラス Garage 配線ケーブルトレー 幅40cm チャコールグレー キーボード+パームレスト 10数年ぶりに外付けキーボードじゃないかな? 少なくともMacに移行してからは、ずっとMac bookのキーボードを使ってました(極稀にMac mini起動後とかにMagic Keyboard使うくらい)。 外出して仕事をすることが多かったのもあり、体をキーボードに合わせる感じでした。\nが、ずっと在宅で仕事をしていますし、ふるさと納税でRealforce(リンクは楽天)がということで、申し込んでみました。2週間ちょっとで到着。 箱が厳重でびっくりしました。\nAmazon | 東プレ REALFORCE SA for Mac ホワイト R2SA-JP3M-WH | Realforce まだ深いキーに慣れつつあると言った感じです。 付属の2mmのキースペーサーでAPCを2.2mmの設定で使用しています。最初は3mm+APC 1.5mmでやっていたのですが、流石にキーが敏感すぎてちょっとキーボードに手をおいたまま考え事をしているだけで「lllllllllll」のようになってしまったので現在の組み合わせに落ち着いています。\nあと、特殊な設定としてはスペースの横のeng/kanaキーを設定でキーロックして使えなくしました。どうも、ご入力の原因になっているようだったので。 日本語の入力切替は、昨日まではCtrl+Spaceを使用していましたが、このブログを書き始めてからCtrl+\\に変更しています。 むかーし、使っていたIME切り替えのショートカットです(知っている人は知っているやつ)。\nマウスは使用しておらず、キーボードの手前にトラックパッドをおいて使っています。パームレストの部分は、サムライズムさんのトラックパッドがきれいに入るmagicTrayPalmです。 Mac book Proと同じような感じでトラックパッドが使えるのがいいですね。 興味がある方は、侍割のリンクをたどってもらうと、初めてサムライズムさんで買い物をする方に限り割引がつくようになってるみたいです(なんと、私もなんか割引になる!)。\nディスプレイアーム 外付けキーボードになったのですが、Mac Book Proの画面も活用したく、さらに上下での配置がやはり目線の移動距離が少ないので気に入っていました。ただ、前回のブログで紹介したアームでは少し高さが足りず。。。 思案しながらAmazonを回遊していたら、同じ会社の新しいアームがあり、調べると高さが取れそうだということで付け替えました。 アーム2本ありますが、今のところ1本だけを使っています。 2本目のアームにカメラを乗せるのもあり?と思いながらまだ試していませんが。玉突き式に前に使っていたアームがサンダーボルトディスプレイ(縦置き)のアームになっています。前にサンダーボルトにつけていたアームは重量オーバーで悲鳴を上げていたので。。。\nAmazon | HUANUO 2画面 アーム デュアル ガススプリング式 スマホ充電器 寝室で利用していた斜めに立てかけるタイプのワイヤレス充電器を作業デスクに持ってきました。 実は部屋に時計がなく、Pixel 3 XLを使っているので、スマホの画面に常に表示されている時計を置き時計の代わりに使えそうだなと (スマホで写真を撮っているので上の画像ではスマホがありませんが)。 結構便利です。ちょっと時間を確認したいときに、メニューバーの時計では流石に小さすぎるのでw\nAmazon | Anker PowerWave 7.5 Stand, Qi ワイヤレス充電器 ミキサー 音声のミキサーです。Yamahaのスピーカーは入力が2系統あるのですが、入力したい音声は3系統あります(ラズパイ4、Mac mini、メインディスプレイ)。2入力を1系統にまとめるプラグを試しに買ってみて、Mac miniとラズパイをまとめてみたのですが、残念ながら切り替わるときに数分無音状態が続くという問題が発生しました。 USB給電できるタイプを購入しました。スライダーとかいらないなと思っていたのですが、電話やミーティング時にBGMの音を下げたりするのに地味に便利だったりします。 ただ、スライダーを動かそうとすると本体も動いてしまっていたので、本体裏に滑り止めを貼ってあります。\nAmazon | Maker hart Just Mixer ステレオ3入力音声ミキサー/電池とUSB電源可能 Webカメラ おっさんの顔がきれいに写っても仕方ないんですが、下からのアングルよりはいいかなぁということと、今後の勉強会で使えそうかな?ということで、購入してみました。 縦でも横でも使える便利なカメラです。また、あんまりないのですが、部屋の中などを写すときにカメラを持ち回せるの便利ですね。 ディスプレイの上に置いてしまうと高さがありすぎるということで、スピーカーの上に乗っけています。仮置きなのですが、このままになるんじゃないかな? 打ち合わせ中は画面共有してることが多いのでオンライン飲み会などで主に活躍してる気も。。。\nAmazon | ロジクール ウェブカメラ フルHD 1080P 60FPS StreamCam C980OW オフホワイト USB-C接続 Mac miniのSSD化 見えないところですが、Mac miniのHDDをSSDに差し替えました。 性能検証用のマシンとしてMac miniを利用し始めたのですが、 計測するたびに速度の差がありすぎるのでおかしいな?と。 よくよく考えてみると、このMac miniはFusion Driveだったんです。。。 開発などで使う分には大容量だし便利だったのですが、負荷計測に利用する場合は挙動をハンドリングできないので、弊害でしかないです。。。 ということで、頑張って差し替えました。想像以上の大手術でした。 「Mac mini HDD 交換」などでググると換装している方たちがいらっしゃいます。興味ある方はググってみてください。\nさて、復路 pic.twitter.com/SwndXPoKqn\n\u0026mdash; Jun Ohtani (@johtani) July 25, 2020 Amazon | シリコンパワー SSD 1TB SATA3 6Gb/s 2.5インチ ラズパイ4 Mac miniの負荷検証マシン化のため+Linuxを触りたかったというのもあり、ラズパイ4を追加しました。 Mac miniは主な使用用途が音楽再生だったのでラズパイ4で肩代わりできるだろう+その他の検証にもラズパイ4が使えそうだと。 現在はUbuntuをインストールして、画面共有で操作しています。\nAmazon | LABISTS Raspberry Pi 4 4B MicroSDHCカード64G まとめ かなり快適になりました。キーボードもうるさくないですし、熱くもありません。マイクのポップガードは意味がなさそうなので外しました。\nまだいくつか気になってるものもあるので、また更新するかもしれません。\n分離式キーボード - 胸を広げた状態でキーを打ったほうがいいのでは?という気がしています。ただ、最近はずっと日本語キーボードを使っているので選択肢が少ないんですよね。。。\nサンダーボルト?USB-C?ドック - MacBook Proのポートがすべて埋まっているし、もう少しケーブルを減らせると幸せになれそうなきが。。。\nモバイルディスプレイ - MacBook Proのディスプレイを使っているのですが、キーボードの上にかぶってるんですよね、結構。。。クラムシェルにしてiPadもしくはモバイルディスプレイに置き換えたほうがスッキリはしそうかなと。ただ、Touch IDが使えなくなったり、クラムシェル状態でMacBook Proの電源を入れられないというはなしなので、あまり意味がなさそうだなというのもあります。\n","date":1599531445,"dir":"post/2020/","id":"d08a3fdc040bbbdd81c9927ce296318c","lang":"ja","lastmod":1599531445,"permalink":"https://blog.johtani.info/blog/2020/09/08/update-working-facility/","publishdate":"2020-09-08T11:17:25+09:00","summary":"自宅環境に少しアップデートがあったので更新版です。 お客さんのおかげで相変わらず自宅で作業させてもらってるのもあり、昨今のコロナウイルスの影響","tags":["misc"],"title":"自宅の作業環境(2020/09)"},{"contents":"Rustで便利なクレートを見つけたので、紹介がてら、自分のメモのためにブログに残しておきます。\nそもそもの問題 Rustで処理を書いていて、なんかちょっと遅いな?どこの処理で時間がかかってるんだろう? ということがありませんか?ありますよね?\nというのを調べるために、最初に思いつくのは自分で計測する方法です。 流石にそれはなぁ、と思ったのでググって出てきた方法を最初は使っていました。\nRustで実行時間計測 3年前の記事ですが、とりあえず計測する分には問題なかったのでこちらの方が書いていたマクロを拝借していました。 が、ちょっと面倒なのが戻り値がある処理などのときに、このマクロを挟むのが結構めんどくさいなと。 また、処理の時間を測りたいのは基本的にはメソッドや関数単位であることが多いです。\nで、さらにググっていて見つけたのが、meteredでした。\nどんなもの? 計測したい部分に#[metric]のようなアノテーションを追加することで計測対象としてくれます。 あとは、計測したものを保存するレジストリという場所を指定するだけです。 処理が終わったタイミングなどで、そのレジストリの内容を出力することで、次の情報を計測することができます。\nHitCount : 実行された回数 ErrorCount : エラーを返した数(Resultを戻り値にしているメソッドが対象) InFlight : 処理中の回数かな? ResponseTime : レスポンスタイム(処理に何秒かかったか) Throughput : スループット(1秒あたり何回呼ばれたか) とりあえず試してみたのは、ResponseTimeとThroughputです。他のメトリクスはまた後日(機会があれば)。 また、metered::metric::Metricトレイトというものが用意されているようで、これを実装した独自のメトリクスも扱うことができるようです。\n使い方 使い方としては次のようになります。\n計測対象となるメソッドがある構造体に、メトリクスを保持するためのレジストリを用意 計測対象にしたい構造体のメソッドに#[measure]を追加(このとき、計測したいものも指定する。) あとは、実行したあとに構造体をダンプするとメトリクスが出力されます。\nレジストリの用意 #[derive(Default, Debug, Serialize)] pub struct NekoParser { metric_reg: NekoParserMetricRegistry, } NekoParserMetricRegistryという型はこのあとのimplのアノテーションで指定する名前になります。 実際にはこの型の構造体を自分で定義する必要はありません。 構造体のderiveでDefaultを指定します。構造体のインスタンス化のときにdefault()メソッドを呼び出して初期化したいためです(おそらくレジストリの初期化をやってくれるのだと思う(要確認))。 レジストリの用意はこれだけです。\nレジストリの指定と計測対象の指定 計測対象側です。少し長いですが、NekoParserのメソッドすべてを掲載しました。 まずは、1行目でレジストリの名前の指定(registry = NekoParserMetricRegistry)、レジストリのフィールド名(registry_expr = self.metric_reg)、レジストリの可視性(visibility = pub(self))を定義します。 2行目では、implブロック全体で計測したいメトリクスを指定しています。今回は、スループットとレスポンスタイムを計測したかったので #measure([ResponseTime, Throughput])]と2種類を指定しています。 メトリクスが2種類のため配列で指定していますが、1種類だけの場合は[]の記号は必要ありません。\nあとは、計測したい各メソッドに#[measure]をつけるだけです。 なお、メソッドごとに#[measure(ErrorCount)]といったかたちで個別にメトリクスを指定することも可能です。 今回はお試しということもあり、すべて#[measure]だけになっています。 アノテーションを付けただけで、メソッド自体を変更はしていません。\n#[metered(registry = NekoParserMetricRegistry, registry_expr = self.metric_reg, visibility = pub(self))] #[measure([ResponseTime, Throughput])] impl NekoParser { #[measure] pub fn load_and_parse_neko(\u0026amp;self) { let file_path = \u0026#34;./data/chap04/neko.txt\u0026#34;; let file = File::open(file_path).unwrap(); let buf = BufReader::new(file); let mut out = File::create(\u0026#34;./data/chap04/neko.txt.lindera.json\u0026#34;).unwrap(); buf.lines().filter_map(|item| item.ok()).for_each(|line| { let tokens = self.tokenize(line.as_str()); self.output_tokens(\u0026amp;tokens, \u0026amp;mut out); }); } #[measure] pub fn output_tokens(\u0026amp;self, tokens: \u0026amp;Vec\u0026lt;Token\u0026gt;, buf: \u0026amp;mut File) { writeln!(buf, \u0026#34;{}\u0026#34;, serde_json::to_string(tokens).unwrap()) .expect(\u0026#34;Error during output json\u0026#34;); } #[measure] pub fn tokenize(\u0026amp;self, line: \u0026amp;str) -\u0026gt; Vec\u0026lt;Token\u0026gt; { let mut tokenizer = lindera::tokenizer::Tokenizer::new(\u0026#34;normal\u0026#34;, \u0026#34;\u0026#34;); let lindera_tokens = tokenizer.tokenize(line); let tokens = lindera_tokens .iter() .map(|lindera_token| { let surface = lindera_token.text.to_string(); let pos = lindera_token.detail[0].to_string(); let pos1 = if pos != \u0026#34;UNK\u0026#34; { lindera_token.detail[1].to_string() } else { String::new() }; let base = if pos != \u0026#34;UNK\u0026#34; { lindera_token.detail[6].to_string() } else { String::new() }; Token { surface, base, pos, pos1, } }) .collect(); return tokens; } } 計測結果の出力 最後は計測結果の出力です。 今回はテストメソッドで実行して結果を出力する処理を書きました。\nlet parser = NekoParser::default();で構造体をインスタンス化します。 あとは、処理をそのまま実行します。\n最後に出力結果をJSON形式の文字列にしてから出力しました。 let serialized ... println!(\u0026quot;{}\u0026quot;, serialized);という形です。 簡単ですね!\n#[cfg(test)] mod tests { use crate::chapter04::answer::NekoParser; use std::path::Path; #[test] fn success_output_tokenlists() { let parser = NekoParser::default(); parser.load_and_parse_neko(); let serialized = serde_json::to_string(\u0026amp;parser).unwrap(); println!(\u0026#34;{}\u0026#34;, serialized); assert!(Path::new(\u0026#34;./data/chap04/neko.txt.lindera.json\u0026#34;).exists()); } } 出力結果 ここまで紹介したものの実行結果は次のような形でした。 レスポンスタイム、スループットともに、最小、最大、99パーセンタイルなどを出力してくれます。 出力はメソッド名ごとにくくられているのでとても便利です。\n{ \u0026#34;metric_reg\u0026#34;: { \u0026#34;load_and_parse_neko\u0026#34;: { \u0026#34;response_time\u0026#34;: { \u0026#34;samples\u0026#34;: 1, \u0026#34;min\u0026#34;: 176128, \u0026#34;max\u0026#34;: 177151, \u0026#34;mean\u0026#34;: 176640.0, \u0026#34;stdev\u0026#34;: 0.0, \u0026#34;90%ile\u0026#34;: 177151, \u0026#34;95%ile\u0026#34;: 177151, \u0026#34;99%ile\u0026#34;: 177151, \u0026#34;99.9%ile\u0026#34;: 177151, \u0026#34;99.99%ile\u0026#34;: 177151 }, \u0026#34;throughput\u0026#34;: { \u0026#34;samples\u0026#34;: 0, \u0026#34;min\u0026#34;: 0, \u0026#34;max\u0026#34;: 0, \u0026#34;mean\u0026#34;: 0.0, \u0026#34;stdev\u0026#34;: 0.0, \u0026#34;90%ile\u0026#34;: 0, \u0026#34;95%ile\u0026#34;: 0, \u0026#34;99%ile\u0026#34;: 0, \u0026#34;99.9%ile\u0026#34;: 0, \u0026#34;99.99%ile\u0026#34;: 0 } }, \u0026#34;output_tokens\u0026#34;: { \u0026#34;response_time\u0026#34;: { \u0026#34;samples\u0026#34;: 9964, \u0026#34;min\u0026#34;: 0, \u0026#34;max\u0026#34;: 143, \u0026#34;mean\u0026#34;: 0.03592934564431955, \u0026#34;stdev\u0026#34;: 1.5152489085107463, \u0026#34;90%ile\u0026#34;: 0, \u0026#34;95%ile\u0026#34;: 0, \u0026#34;99%ile\u0026#34;: 0, \u0026#34;99.9%ile\u0026#34;: 6, \u0026#34;99.99%ile\u0026#34;: 143 }, \u0026#34;throughput\u0026#34;: { \u0026#34;samples\u0026#34;: 174, \u0026#34;min\u0026#34;: 39, \u0026#34;max\u0026#34;: 71, \u0026#34;mean\u0026#34;: 57.103448275862064, \u0026#34;stdev\u0026#34;: 3.8417981983375835, \u0026#34;90%ile\u0026#34;: 60, \u0026#34;95%ile\u0026#34;: 61, \u0026#34;99%ile\u0026#34;: 64, \u0026#34;99.9%ile\u0026#34;: 71, \u0026#34;99.99%ile\u0026#34;: 71 } }, \u0026#34;tokenize\u0026#34;: { \u0026#34;response_time\u0026#34;: { \u0026#34;samples\u0026#34;: 9964, \u0026#34;min\u0026#34;: 12, \u0026#34;max\u0026#34;: 79, \u0026#34;mean\u0026#34;: 16.897230028101177, \u0026#34;stdev\u0026#34;: 2.331145559054724, \u0026#34;90%ile\u0026#34;: 19, \u0026#34;95%ile\u0026#34;: 20, \u0026#34;99%ile\u0026#34;: 24, \u0026#34;99.9%ile\u0026#34;: 46, \u0026#34;99.99%ile\u0026#34;: 79 }, \u0026#34;throughput\u0026#34;: { \u0026#34;samples\u0026#34;: 174, \u0026#34;min\u0026#34;: 39, \u0026#34;max\u0026#34;: 71, \u0026#34;mean\u0026#34;: 57.103448275862064, \u0026#34;stdev\u0026#34;: 3.819293076427424, \u0026#34;90%ile\u0026#34;: 60, \u0026#34;95%ile\u0026#34;: 61, \u0026#34;99%ile\u0026#34;: 64, \u0026#34;99.9%ile\u0026#34;: 71, \u0026#34;99.99%ile\u0026#34;: 71 } } } } 出力内容で気になったのはoutput_tokensとtokenizeのthroughputが全く同じ結果が出ていることです。 なにかバグを踏んでいる気がします。。。(時間を見つけてソースコード読んでみるか。)\n気をつけること meteredの導入時にわかりにくいコンパイルエラーが出たので備忘録として残しておきます。 (下からコンパイルエラーを読んでしまうくせがあったのが問題なのですが。。。) エラーメッセージは次のとおりです。\nerror[E0412]: cannot find type `ResponseTime` in this scope --\u0026gt; src/chapter04/answer.rs:13:12 | 13 | #[measure([ResponseTime, Throughput])] | ^^^^^^^^^^^^ not found in this scope | help: consider importing one of these items | 1 | use metered::ResponseTime; | 1 | use metered::common::ResponseTime; | error[E0283]: type annotations needed --\u0026gt; src/chapter04/answer.rs:12:1 | 12 | #[metered(registry = NekoParserMetricRegistry, /* default = self.metrics */ registry_expr = self.metric_reg)] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type | = note: cannot satisfy `_: std::default::Default` = note: required by `std::default::Default::default` = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info) 最初のメッセージにはわかりやすく出ていますが、ResponseTimeをuseせずに利用しようとした場合に以下のようなエラーが出ていました。 ターミナル画面が狭かったのでE0283のエラーが目に入り、何を言ってるんだろう?という状態になってしまいました。 スクロールアップしたら、答えが載っているのに。。。\nコード全体 元ネタはNLP100本ノックの第4章です。 コードの全体はGitHubのソースをご覧ください。\nまとめ meteredを簡単ですが紹介してみました。 導入自体も簡単で、想像していたような使い方ができたので満足しています。 ほかにもプロファイラなどはあるのかもしれませんが、まずはこれを使っていこうかと思っています。\nバグらしきものがありそうだったりするので、そのへんは今後調査してみようかと。 まだ、ちょっと試してみただけなので、metered自体のオーバーヘッドや、独自のメトリクスの実装方法、メソッドではなく関数に対して利用する場合にはどうするのか?などいくつか疑問点があるので、今後試してみてまたブログに残しておこうと思います。\n","date":1599487900,"dir":"post/2020/","id":"827de2d7a9d231f6bcb44caf35896c1f","lang":"ja","lastmod":1599487900,"permalink":"https://blog.johtani.info/blog/2020/09/07/intro-metered-rs/","publishdate":"2020-09-07T23:11:40+09:00","summary":"Rustで便利なクレートを見つけたので、紹介がてら、自分のメモのためにブログに残しておきます。 そもそもの問題 Rustで処理を書いていて、なん","tags":["Rust"],"title":"meteredクレートの紹介"},{"contents":"Rustで言語処理100本ノックの第4章です。\n前回はこちら。\n今回は早めに続きをやりました。 「形態素解析」ですしね。\n第4章の概要 吾輩は猫であるの文章が用意されていて、MaCabで形態素解析した結果をファイルに保存したところからが開始となります。\nが、せっかくRustでやっているのでKuromojiのRust版であるLinderaを利用して形態素解析した結果を保存する部分から作成しました。 3章に引き続き、大きな流れのところの説明だけにしておきます。\n形態素解析 もとのneko.txtが文章が1行ごとになっているので、そのまま1行ずつ読みならが、形態素解析していきます。読み込みの部分は3章とあまり変わらないので割愛します。 以下は、形態素解析の処理と形態素解析結果用の構造体です。\n#[derive(Clone, Debug, Serialize, Deserialize)] struct Token { surface: String, base: String, pos: String, pos1: String, } まずは構造体です。今回の問題では、必要な情報は4種類だったのでそれを構造体にしました。\n表層形（surface） 基本形（base） 品詞（pos） 品詞細分類1（pos1） deriveでSerialize、Deserializeを付与しているのは、形態素解析の結果をJSON文字列として保存し、あとのそれぞれの課題で読み出すためにserde_jsonを利用するためです。\nfn tokenize(line: \u0026amp;str) -\u0026gt; Vec\u0026lt;Token\u0026gt; { let mut tokenizer = lindera::tokenizer::Tokenizer::new(\u0026#34;normal\u0026#34;, \u0026#34;\u0026#34;); let lindera_tokens = tokenizer.tokenize(line); let tokens = lindera_tokens .iter() .map(|lindera_token| { let surface = lindera_token.text.to_string(); let pos = lindera_token.detail[0].to_string(); let pos1 = if pos != \u0026#34;UNK\u0026#34; { lindera_token.detail[1].to_string() } else { String::new() }; let base = if pos != \u0026#34;UNK\u0026#34; { lindera_token.detail[6].to_string() } else { String::new() }; Token { surface, base, pos, pos1, } }) .collect(); return tokens; } 次が形態素解析の処理です。 入力に1行分の文章を受け取り、出力として、さきほどの構造体をベクタに入れたものVec\u0026lt;Token\u0026gt;を返します。 内部ではLinderaのTokenizerをnormalモードでインスタンス化してそのtokenizer()メソッドを叩いているだけです。 インスタンス化のときの第2引数は辞書のディレクトリですが、今回はデフォルト辞書(IPADIC)を利用しています。 戻り値はLinderaが用意したToken構造体なので、これを今回作成したToken構造体に詰め替えているだけです。\n注意点としてLinderaはMeCabとは異なり、未知語(辞書に出てこない単語)の処理が実装されていないので、品詞が\u0026quot;UNK\u0026quot;の場合にはその他の情報が取得できないので、空文字を構造体に設定するようにしました。\n結果の保存 形態素解析の結果はJSONで保存しました。 もとのファイルが1文が1行になっていたので、 1行を読み込み、形態素解析し、それをVecで取り出して、1行1配列JSONの形で保存するようにしてあります。\nfn output_tokens(tokens: \u0026amp;Vec\u0026lt;Token\u0026gt;, buf: \u0026amp;mut File) { writeln!(buf, \u0026#34;{}\u0026#34;, serde_json::to_string(tokens).unwrap()).expect(\u0026#34;Error during output json\u0026#34;); } serde_json::to_stringにVec\u0026lt;Token\u0026gt;を渡しているだけですが、構造体にderiveをつけているのでよしなにやってくれます(便利ー)。\nJSONの読み込み処理 1行1JSONの読み込み処理です。 今回も3章のように読み込みながら、各文章ごとの形態素解析結果に対して処理を実施するために、処理を実行するためのtraitをCommandとして用意し、それぞれの問題で形態素解析結果に対して処理を書くような実装にしました。また、設問37で「猫」と共起している単語を処理するという課題があるので、文章に「猫」が入っているものだけを処理できるようにするためのFilterも用意し、これをJSONの読み込み処理のイテレータのfilterにわたすようにしています。 特にフィルタリングが必要ない場合ように、NonFilterを予め実装済みです。\ntrait Command { fn execute(\u0026amp;mut self, tokens: \u0026amp;Vec\u0026lt;Token\u0026gt;); } trait Filter { fn is_target(\u0026amp;self, line: \u0026amp;str) -\u0026gt; bool; } struct NonFilter {} impl Filter for NonFilter { fn is_target(\u0026amp;self, line: \u0026amp;str) -\u0026gt; bool { true } } // ch04-30. 形態素解析結果の読み込み fn load_json\u0026lt;T: Command\u0026gt;(cmd: \u0026amp;mut T) { load_json_with_filter(cmd, \u0026amp;NonFilter {}); } fn load_json_with_filter\u0026lt;T: Command, U: Filter\u0026gt;(cmd: \u0026amp;mut T, filter: \u0026amp;U) { let file = File::open(\u0026#34;./data/chap04/neko.txt.lindera.json\u0026#34;).unwrap(); let buf = BufReader::new(file); buf.lines() .filter_map(|item| item.ok()) .filter(|line| filter.is_target(line)) .for_each(|line| { let tokens = parse_line_json(line.as_str()); cmd.execute(\u0026amp;tokens); }); } output_tokensではserde_json::to_stringを呼び出してましたが、読み込みでは、serde_json::from_strを使うと構造体にしてくれます。\nfn parse_line_json(line: \u0026amp;str) -\u0026gt; Vec\u0026lt;Token\u0026gt; { return serde_json::from_str(line).unwrap(); } あとは、設問ごとにCommandトレイトを実装していく形です。 たとえば、32.の動詞の原形を出力する場合は次のようになります。\nstruct ExtractVerbBase { out: File, } impl Command for ExtractVerbBase { fn execute(\u0026amp;mut self, tokens: \u0026amp;Vec\u0026lt;Token\u0026gt;) { tokens .iter() .filter(|token| token.pos == \u0026#34;動詞\u0026#34;) .for_each(|token| { writeln!(self.out, \u0026#34;{}\u0026#34;, token.base).expect(\u0026#34;Error during writeln\u0026#34;); println!(\u0026#34;{}\u0026#34;, token.base); }) } } 標準出力とは別にファイルにも出力できるようにExtractVerbBaseにoutでファイルを保持しています。\n34. 名詞の連接 「名詞の連接（連続して出現する名詞）を最長一致で抽出せよ．」という課題だったのですが、最初は読み間違えて、名詞の連接の最も長いものだけを出力するようにしてました。。。 やっぱり、出力結果とかのサンプルは用意しといてほしいなぁ。。。\nimpl Command for ExtractMaxConjunctionNoun { fn execute(\u0026amp;mut self, tokens: \u0026amp;Vec\u0026lt;Token\u0026gt;) { let mut nouns = vec![]; // TODO 参照保持でどうにかしたいけどなぁ。 tokens.iter().map(|token| token.clone()).for_each(|token| { if token.pos == \u0026#34;名詞\u0026#34; { nouns.push(token); } else { if nouns.len() \u0026gt; 1 { self.buffer.push(nouns.clone()); } nouns = vec![] } }); } } 名詞の場合に、nounsにバッファリングしつつ、違う品詞が来たら出力するという処理になっています。 cloneを呼び出していますが、これを参照を引き回す感じにできるといいのかもなぁ(結構めんどくさい)。\n36. 頻度上位10語 頻度を数えるのにはBTreeMapを利用しています。 数えながら、Top10を保持する方法がいい気がしたのですが、いい入れ物を見つけられなかったので、数え上げたあとにBTreeMapのIteratorを回しながら、キーバリューのVecをまず生成します。 その生成したVecに値でソートし、その後Iteratorから最初の10件を取得して表示する方法にしました。\nソートして取り出すという処理がついでにかかっています。。。 BinaryHeapがなにか使えそうな気もしたのですが、いい方法が思いつきませんでした。\nfn print_top10(\u0026amp;mut self) { let mut key_values: Vec\u0026lt;(\u0026amp;String, \u0026amp;u32)\u0026gt; = self.terms_count.iter().collect::\u0026lt;Vec\u0026lt;(\u0026amp;String, \u0026amp;u32)\u0026gt;\u0026gt;(); key_values.sort_by(|x, y| y.1.cmp(\u0026amp;x.1)); key_values.iter().take(10).for_each(|(key, value)| { writeln!(\u0026amp;self.out, \u0026#34;{}, {}\u0026#34;, key, value).expect(\u0026#34;Error during writeln\u0026#34;); println!(\u0026#34;{}, {}\u0026#34;, key, value); }); } まとめ 形態素解析結果をちゃんと眺めてはいないですが、処理としてはこんなところかなと。 グラフはめんどくさいのでスキップしてしまいました。。。 Kibana/Esに食わせて見てみるのもありかなぁ?\n次は係り受け解析です。Rustで使えるライブラリとかあるかなぁ?\n","date":1599445027,"dir":"post/2020/","id":"3c5d4d351e0fb9e33e0e8b6d1d43c0f2","lang":"ja","lastmod":1599445027,"permalink":"https://blog.johtani.info/blog/2020/09/07/reboot-nlp100-ch04/","publishdate":"2020-09-07T11:17:07+09:00","summary":"Rustで言語処理100本ノックの第4章です。 前回はこちら。 今回は早めに続きをやりました。 「形態素解析」ですしね。 第4章の概要 吾輩は猫である","tags":["Rust","nlp100"],"title":"第4章終了(言語処理100本ノック2020)"},{"contents":"Rustで言語処理100本ノックの第3章です。\n前回はこちら。\n少し間が空きましたが、再開しました。 間が空いた理由は。。。「正規表現」ですかね。。。 苦手なんです、正規表現。 なので、28はちょっとギブアップしてしまいました。\n第3章の概要 個別に説明はせずに大きな流れのところだけ。 それぞれの問題の解についてはリポジトリを御覧ください(興味ある人いるのかなぁ?)\n第3章はNDJSON(new line delimited JSON)という、 1行に1JSONという形式のデータを格納したファイルがgzipで圧縮された状態で提供されます。 まずは、このJSONファイルからJSONを読み込むのが主な処理になります。\n読み込んだデータに「イギリス」のWikipediaの記事が入っているので、そこから正規表現で必要なデータを抽出します。\n最後の問題が少し特殊で、抜き出した情報の「国旗」のファイル名を元に、MediaWikiのREST APIを叩いて、結果を取得し、その一部の情報を抜き出すというものです。\nJSONの読み込み処理 gzipファイルを読み込んでから、1行ずつ抜き出してVecに入れる処理が次のようになります。 今回のgzipファイルは大した量が入っていないので、全部先に抜き出す処理としてまとめました。 もっと巨大なファイルの場合は個別のJSONに対する処理を buf.lines().map()のmapのなかで実行する形にすると思います。 gzipのファイルを開くのにflate2というクレート(ライブラリ)を利用しました。便利なのは、BufReaderにlines()というメソッドがあるところですかね。\n// https://docs.rs/flate2/1.0.14/flate2/read/struct.GzDecoder.html pub fn extract_ndjson_from_gzip(input_file_name: \u0026amp;str) -\u0026gt; Vec\u0026lt;String\u0026gt; { let f = File::open(input_file_name).expect(\u0026#34;file not found?\u0026#34;); let gz = GzDecoder::new(f); let buf = BufReader::new(gz); let lines: Vec\u0026lt;String\u0026gt; = buf.lines().map(|l| l.unwrap()).collect(); return lines; } こちらは、上記のメソッドで抜き出したVecを元に、記事の情報を抜き出す処理をしています。 JSONをパースして構造体Articleにデシリアライズするために、serdeというライブラリを使用しています。 serde自体は様々なデータ形式(JSON、YAMLなど)をパースするためのフレームワークです。今回はJSONなので、serde_jsonの実装を利用しています。 また、JSON文字列から構造体にデシリアライズするのを簡単にできるように構造体に#[derive(Deserialize)]をつけています。 あとは、let article: Article = serde_json::from_str(json.as_str())という処理を実行すればserde_jsonがJSONをパースして構造体に変換してくれます。形式がわかっているJSONの扱いはこれが楽ですね。変数に型を明記してあるので、型の推論もしてくれてるようです。\n#[derive(Deserialize)] pub struct Article { title: String, text: String, } // ch03-20. JSONデータの読み込み // https://serde.rs/ pub fn load_json(input_file_name: \u0026amp;str, target_title: \u0026amp;str) -\u0026gt; Vec\u0026lt;Article\u0026gt; { let mut results = vec![]; let ndjson = extract_ndjson_from_gzip(input_file_name); for json in ndjson { let article: Article = serde_json::from_str(json.as_str()).expect(\u0026#34;json parse error\u0026#34;); if article.title == target_title { results.push(article); } } return results; } 後続の処理ではパースしたArticleから記事情報を取得して色々と処理をしています。\n正規表現 正規表現用のクレートregexがRustに用意されています。Regex::new(正規表現)で、正規表現をコンパイルし、あとは、この構造体のメソッドを利用して文字列を処理していきます。 問題では、マッチするかどうか、マッチした一部の文字列を抜き出す、不要なタグを削除するといった処理を正規表現で行いました(Rust書くよりも正規表現の書き方とかを調べるのに大半の時間をもっていかれてます。。。)。\npub fn extract_category_lines(article: \u0026amp;Article) -\u0026gt; Vec\u0026lt;String\u0026gt; { let re = Regex::new(r\u0026#34;\\[\\[Category:(.*)\\]\\]\u0026#34;).expect(\u0026#34;syntax error in regex\u0026#34;); let mut lines = vec![]; article.lines_from_text().iter().for_each(|line| { if re.is_match(line) { lines.push(line.to_string()); } }); return lines; } MediaWiki APIリクエスト処理 最後の問題で国旗のファイル名を元にMediaWiki APIを叩いて、URLの文字列を取得しましょうという問題がありました。 ファイル名をREST APIの引数に渡してHTTP経由でリクエストを送信し、返ってくるJSONレスポンスからURLを抜き出すという処理です。\nHTTPのリクエストの送受信にreqwestというクレートを利用しました。 ちょっと長いけど、APIコールしている箇所はこんな形です。\nこの関数にはasyncとついています。非同期処理の関数です。内部で2回ほど(リクエスト送信の結果待ちとレスポンスのパース待ち).awaitがあります。\nclientに.get(URL)やquery(\u0026amp;[])といったメソッドが用意されているので、URLやクエリパラメータを用意してsend()でリクエスト送信します。\nasync fn call_api(file_name: \u0026amp;str) -\u0026gt; Result\u0026lt;String, String\u0026gt; { let client = reqwest::Client::new(); let file_name2 = format!(\u0026#34;File:{}\u0026#34;, file_name); //let mut file_name2 = file_name.to_string().replace(\u0026#34; \u0026#34;, \u0026#34;_\u0026#34;); let query = [ (\u0026#34;action\u0026#34;, \u0026#34;query\u0026#34;), (\u0026#34;format\u0026#34;, \u0026#34;json\u0026#34;), (\u0026#34;prop\u0026#34;, \u0026#34;imageinfo\u0026#34;), (\u0026#34;iiprop\u0026#34;, \u0026#34;url\u0026#34;), (\u0026#34;titles\u0026#34;, file_name2.as_str()), ]; let result = client .get(\u0026#34;https://en.wikipedia.org/w/api.php\u0026#34;) .query(\u0026amp;query) .send() .await; match result { Ok(response) =\u0026gt; match response.status() { StatusCode::OK =\u0026gt; { let body = response.json::\u0026lt;MediaWikiResponse\u0026gt;().await; match body { Ok(obj) =\u0026gt; match obj.get_url() { Some(url) =\u0026gt; Ok(url), None =\u0026gt; Err(String::from(\u0026#34;Cannot get url...\u0026#34;)), }, Err(error) =\u0026gt; Err(error.to_string()), } } _ =\u0026gt; Err(String::from(format!( \u0026#34;Status code is {}.\u0026#34;, response.status() ))), }, Err(error) =\u0026gt; { let error_msg = format!(\u0026#34;Error occurred... {:?}\u0026#34;, error); println!(\u0026#34;{}\u0026#34;, error_msg.as_str()); Err(error_msg) } } } あとは、呼び出し元で非同期の処理を実行するために、tokioというクレートを利用しています。 block_on()でcall_api()の実行をして、結果が返ってくるのを待ち受けています。結果が返ってきて、問題なければ、call_apiの戻り値Result\u0026lt;String, String\u0026gt;の左側のStringの値が取り出され、get_image_urlの戻り値となります。\nfn get_image_url(file_name: \u0026amp;str) -\u0026gt; String { let mut _rt = tokio::runtime::Runtime::new().expect(\u0026#34;Fail initializing runtime\u0026#34;); let task = call_api(file_name); _rt.block_on(task).expect(\u0026#34;Something wrong...\u0026#34;) } 一応、非同期に関して説明してみましたが、合っているのかどうか。。。 クレートの関係などはまだちょっと自身がないです。。。 あとは、エラーの処理の仕方とかももうちょっと勉強したいかな。\nまとめ 一応、3章を終わらせました。だいぶ強引かつ1つスキップしましたが。。。 次は第4章の形態素解析です。\n","date":1599230785,"dir":"post/2020/","id":"eb2a5824e03996c1966bee38866ce349","lang":"ja","lastmod":1599230785,"permalink":"https://blog.johtani.info/blog/2020/09/04/reboot-nlp100-ch03/","publishdate":"2020-09-04T23:46:25+09:00","summary":"Rustで言語処理100本ノックの第3章です。 前回はこちら。 少し間が空きましたが、再開しました。 間が空いた理由は。。。「正規表現」ですかね。","tags":["Rust","nlp100"],"title":"第3章終了(言語処理100本ノック2020)"},{"contents":"負荷を計測するために、数回、Azure Cognitive Searchのクラスターを起動したり、停止したりしてました。 これは、Terraformでやると楽できるのでは?と思ったので、やってみました。 1パーティションのクラスターなので、全然大したことはないのですが、メモを残しておくためにブログに書いておきます。\n基本的にはTerraformの公式ドキュメントにあったものを自分用に変数を抽出しただけです。\nファイルたち 単にクラスターを起動するためだけなので、2種類のファイルだけ作成しました(1個でもいいかも)。\nvariables.tf - 変数用のファイル。いくつかの設定を変数として定義しました。 terraform.tf - Terraform本体のファイル。 variables.tf まずはvariables.tfです(ファイル内の並びは異なりますが。。。)。terraform.tfで利用する5つの変数です。\nresource_group - リソースグループ名。既存とは異なるリソースグループ名にしました(変に壊してもいいので)。 machine_type - 価格レベル(SKU)。公式ドキュメントに設定できる値の一覧があります。今回はWikipediaのデータを登録していたのでそれが入るサイズにしています。 region - 場所(リージョン)。リージョンの一覧はどこにあるんだろう?これを参考にしましたが。 partition_size - パーティションのサイズ(=Elasticsearchでのシャードかな?)です。今回は1つでの性能を計測したかったので1にしてあります。 search_cluster_name - Azure Cognitive Searchのサービス名。search.windows.net名前空間で一意である必要があったので、他の人が使わなそうな名前をつけています。 variable \u0026#34;machine_type\u0026#34; { default = \u0026#34;standard\u0026#34; } variable \u0026#34;region\u0026#34; { default = \u0026#34;East Asia\u0026#34; } variable \u0026#34;resource_group\u0026#34; { default = \u0026#34;johtani-wiki-test\u0026#34; } variable \u0026#34;search_cluster_name\u0026#34; { default = \u0026#34;johtani-wikipedia\u0026#34; } variable \u0026#34;partition_size\u0026#34; { default = 1 } terraform.tf terraform.tfは以下の通り。Terraformの公式ドキュメントにある例にproviderを追加しただけのものになります。\nprovider - プロバイダーの設定。Azureを利用するという宣言です。features {}がないとエラーになります。空でも必ず指定が必要です。認証周りについては、azure-cli経由で認証する方式を採用しました。azure-cliはHomebrewでインストールしています。 azurerm_resource_group - リソースグループの設定。variables.tfのresource_groupとregionを利用しています。必須項目はこの2種類だけです。 azurerm_search_service - Azure Cognitive Searchの設定。partition_count以外は必須項目です。variables.tfとazurerm_resource_groupの設定を利用しています。今回は利用していませんが、レプリカ数なども指定できるようになっています。 # Azureのproviderを指定。 provider \u0026#34;azurerm\u0026#34; { features {} } # リソースグループの設定 resource \u0026#34;azurerm_resource_group\u0026#34; \u0026#34;wiki-test\u0026#34; { name = var.resource_group location = var.region } # Azure Cognitive Searchの設定 resource \u0026#34;azurerm_search_service\u0026#34; \u0026#34;search_service\u0026#34; { name = var.search_cluster_name resource_group_name = azurerm_resource_group.wiki-test.name location = azurerm_resource_group.wiki-test.location sku = var.machine_type partition_count = var.partition_size } 以上がファイルです。ほぼ公式ドキュメントのサンプル通りですねw\nデプロイとか ファイルの準備ができたら実際にデプロイします。 Azureの環境への認証にはAzure CLIを利用して、事前にログインした状態にします。 実際にデプロイするまでの手順は次のようになります。\naz login - Azureの認証。ブラウザが起動してログイン画面が表示されます。無事認証がOKなら、azコマンドでAzure Cloudの情報が取得できます。 terraform init - 初回だけです。Terraformのワーキングディレクトリの初期化処理を実行します。 terraform plan - Terraform \u0026lt; 0.12の場合は実行。最新版だともういらないみたいだ。 terraform apply - 実際にAzure上にクラスターを起動します。Terraformが隠蔽してくれているので、実際にどんなことをやっているかはわかってないですが。 以上で、Azure Cognitive Searchのクラスターが起動します。 すごく簡単です。Webコンソールでチェックすれば、起動していることも確認できます。\nこの状態では、クラスターが起動しただけなので、あとは必要に応じてデータをロードしたり、アプリから検索したりと行ったことが可能になります。 そのへんの話はまた機会があれば。\nDestroy 今回は負荷テスト用にクラスターを起動していましたので、必要なくなれば、クラスターを削除します。Terraformを導入したもう一つの理由がこの簡略化です。 terraform destroyを実行するだけで、Azure Cognitive Searchのクラスターおよび、リソースグループが削除されます。\nまとめ ということで、ほぼ公式ドキュメントのままですが、TerraformでAzure Cognitive Searchのクラスターを起動する方法の紹介でした。 ブログを書いていて、1点気になったのは、ロケーション(リージョン)の一覧はどこにあるんだろう?という点です。azコマンドとかで出てくるのかなぁ?\n","date":1597742807,"dir":"post/2020/","id":"f5effd616a3f8db6193b482caec37912","lang":"ja","lastmod":1597742807,"permalink":"https://blog.johtani.info/blog/2020/08/18/azure-search-with-terraform/","publishdate":"2020-08-18T18:26:47+09:00","summary":"負荷を計測するために、数回、Azure Cognitive Searchのクラスターを起動したり、停止したりしてました。 これは、Terraformでやると楽でき","tags":["azure search"],"title":"TerraformでAzure Cognitive Searchのクラスターを起動"},{"contents":"先日は「システムの特徴と検索機能について」という感じでふんわり書きました。 まぁ、頭の中でぼんやり考えてることを文章にしてみた感じです。 他にもぼんやりしてるものはいくつかあるので今日も書いてみることに。 検索システム?みたいなツイートも見かけたので、検索システムってこんなイメージですというブログを書いてみました。\n検索システム(機能)を構成するパーツ 今回はシステムに組み込まれる検索機能を構成するパーツについて書き出してみようかなと思います。 パーツといってもユーザー、UI、コンテンツなども入れています。\nユーザー 検索UI 検索窓 オートコンプリート 検索結果画面 ファセット ソート ハイライト 詳細画面 レコメンド 検索エンジン コンテンツ 検索ログ クリックログとかも サービス提供者 ざっくり書くとこんな感じです。 システム構成だったり、機能だったり、アクターだったりといろいろなものが混ざってしまっていますが、登場するものはこんなものです。\nざっくりした繋がりの図はこんな感じです。\nそれぞれの役割について見ていきましょう。\nユーザー サイト、システムのユーザーです。 検索UIを経由して望んだコンテンツを探します。 探す目的は、サイトによって異なります。 「何かを購入(ECサイトやオークション)する」だったり、「情報(レシピや社内文書)を見つける」だったりします。 図では「キーワード」と記載しましたが、最近では自然文(文章)を受け付ける検索もあります。\n検索UI サイト、システムが提供するUIです。ユーザーはこのUIにキーワード(質問)を入力し、検索結果を取得します。 UIにはいくつものパーツがさらに存在します。簡単に例を上げると以下のようなものです。\n検索窓 - キーワードを入れるための入力ボックスです。 オートコンプリート(自動補完) - サイトによっては、検索窓に何かを入力すると、キーワードを保管したりサジェストしたりしてくれます。 検索結果画面 - 質問にマッチしたコンテンツの一覧を表示する画面です。一覧以外にもいくつか情報が表示されます。 検索結果一覧 - コンテンツの一覧です。何かしらの基準(日付順や人気順など)によってソートされたものが表示されます。 ファセット - 検索結果が持っている属性(価格帯、カテゴリ、メーカー名など)の一覧で、絞り込み検索のヒントです。 ハイライト - 入力したキーワードがどこにマッチしたかがわかるように、強調表示されたスニペット(情報の一部)が出ます。 検索APIとUIに分かれている場合が多いでしょうか? 処理の流れとしては、検索窓に入力されたキーワードを検索エンジンに問い合わせができるクエリに書き換えてからリクエストを投げます。 あとは、検索エンジンからのレスポンスにある検索結果を表示できる形に変換して表示するのが役割です。 また、検索ログの出力もこの部分で担当することが多いです(もしくは、検索エンジン自体がログ出力の機能を持っている場合もあります)。\n検索エンジン 検索に特化したデータ構造を内部に持っているサーバーもしくはサービスです。 ElasticsearchやApache Solr、Azure Cognitive Searchなどは転置インデックスと呼ばれるデータ構造になっています。 検索エンジンの検索処理に対しての主な役割は次の2つです。\nクエリにマッチするコンテンツの集合を決定する マッチしたコンテンツを特定の条件で並び替える(ランキング) クエリを受け取り、検索結果のリストを返すのが処理の大きな流れです。 その他に、ファセット、ハイライトといった付加的な処理を実行することがあります。\nまた、データ登録(インデキシング/インデクシング)の処理もあります。\n登録するコンテンツを検索に特化したデータ構造にして格納する 転置インデックスの場合は、入力されたデータ(文章)から単語列を作り出して、単語からコンテンツのIDが判別できる形にする処理になります。\nAlgoliaやElastic App SearchのようなSaaSであったり、RDBの機能を利用するといった選択肢もあります。\nデータソース・コンテンツ 実際に提供したいコンテンツになります。 コンテンツが保存されている場所は、サイトによって異なります。\nWebの検索サイト - インターネット上のホームページ ECサイト - データベースに格納されているアイテムのデータ 社内文書検索 - ファイルサーバーやWikiなどのファイル、文書 といった感じです。 実際には、データソースからコンテンツを検索エンジンに登録する場合は、いくつかの処理(いわゆる前処理)が必要になります。 社内文書検索やWebの検索サイトの場合は、データを収集するためのクローラーが必要ですし、 収集したデータから、検索エンジンに登録するデータを加工したり(HTMLタグを除去したり、メタデータ(URL、収集日、タイトル)を付与したり)もします(ETL処理とか言われる)。\n検索ログ 検索を提供するだけであれば、必要ありません。 が、実際に検索がどのような使われ方をしているか?を知るために必要な機能になります。 この検索ログがユーザーのニーズを読み解くための情報になります。 検索ログには次のような情報が入ります。\n検索窓に入力された文字列 入力された文字列でヒットした件数 検索結果を出したタイミングでのログです。他にも実際にヒットしたコンテンツのIDなどをログに残したり、他のユーザーと区別をつけるために、ユーザーのセッションごとにIDを発行してログに残したりもします。\nまた、検索に満足してもらえているかを見るために、実際に検索結果のどのコンテンツに興味をもったのか?という情報も検索ログとして残すことがあります。クリックログなどとも呼ばれます。検索結果のどのドキュメントが実際にクリックされたか(詳細画面に遷移したか)という情報です。1回の検索結果に対してクリックされるごとにログが残ります。 もちろん、結果に満足しない場合は、クリックされずに、キーワードを変えたり、絞り込み条件がクリックされたりします。\nECサイトなどの場合は更に、実際に購入されたかどうかといった情報もユーザーのニーズを読み解くための情報となります。 詳細画面へのクリックログや購入ログについては、検索以外からの流れ(広告やDMだったり、レコメンドだったり)なども考えられます。 これらのログを元に、検索を改善していくことになります。\nサービス提供者 サイト・システムの提供者です。 コンテンツの準備、検索UIにはどんな物が必要なのか、サイト・システムにとって良い検索とはなにか?、検索ログからユーザーのニーズを分析して何を改善していくのか?といったことを考えます。 例としては次のようなことです。\n検索結果に表示するコンテンツとはなにか? コンテンツの持っている項目・属性の何を検索対象とするか? 検索結果の並び順(ランキング)がどんなものがよいのか? 検索UIにはどんなものを表示するのか? 検索機能を作るときの流れ 検索機能を構成するパーツにどんなものがあるかを紹介しました。 実際にシステムに検索機能を追加する場合は、最低限、次のものが必要になります。\n検索UI 検索エンジン(RDB?SaaS?ミドルウェア?) データソース・コンテンツ とりあえずこれらがあれば、検索機能を作ることはできるかと。 ただ、作っただけでは、いいか悪いかの判断がつかないので、どういった使われ方をしているかを知るために検索ログをとったりして、 改善をしていく必要が出てきます。\nまとめ わかってるよそんなことはと言われそうな感じになったかもしれないですが、 検索の機能を構成するパーツについて紹介してみました。 細かなはなしは色々とありますが、大まかにはこのような役割のパーツがあります。\n実際にはこれらのパーツを用意すればよいわけではなく、それぞれで検索を良くしていくためにどんなことを考えていくのか?などが出てきます。そのあたりの話はまた、別のブログで書いていく感じでしょうか。こんな感じで書いてくと、終わらない気がしてきたけど。。。 次はどんなはなしを書くかなぁ。\n","date":1595907282,"dir":"post/2020/","id":"11a61827e80739a6065960eb188d5758","lang":"ja","lastmod":1595907282,"permalink":"https://blog.johtani.info/blog/2020/07/28/improve-search-no2/","publishdate":"2020-07-28T12:34:42+09:00","summary":"先日は「システムの特徴と検索機能について」という感じでふんわり書きました。 まぁ、頭の中でぼんやり考えてることを文章にしてみた感じです。 他にも","tags":["検索"],"title":"検索システムを構成するパーツ(検索システムに関する妄想その2)"},{"contents":"今年の頭からシステムの検索周りを手伝う仕事をフリーランスとしてやっています。 検索の仕組みを知れば知るほど面白くなってきたからという理由になるのかな? LuceneやSolr、Elasticsearchなどを長く触っているというのもあるかと思います。\nということで、検索についていつも考えています。 頭の中でまとまっていない状況ですが、システムにおける検索機能についていくつか頭の中にあることを書き出して、 いろんな方にダメ出しやコメントをもらいたいなと思ったので、色々と書いてみようかと。 思いつきのままに書いているので、はなしがあちこち飛ぶ可能性もありますが、あしからず。\n検索って難しい 「「検索」とは、データの集合から目的のデータを探し出すこと」By Wikipedia\n一言で「検索」といっても、使う人、ユースケースによっていろいろな「検索」があります。 例えば、新しいスマホを買ったときに、スクリーンロックの時間を設定する機能を「検索」したりします。 また、PCで仕事をしているときに、ファイルの中身をある文字列で「検索」したりもします。 TSUTAYAに行って、欲しかった本がおいてあるかどうか店内の端末で「検索」もします。 Rustを書いていて、こんなことをやるライブラリありそうだよな?と思ってGoogleでウェブの検索をしたりもします。\n私が特にそうだと思いますが、なにかあったらまず検索をするという生活をしています。 ただ、このとき、「検索」といっても望んでいる挙動が違ったりするものです。 以下は自分が「検索」しているときに想定していることになります。\nファイル内の検索をしているときはgrep的な検索を想定していることが多い。 書籍の検索をしているときは、特定の項目(著者など)に対してgrep的な検索を想定しているが、名前の読みなどでも検索されることを想定している(漢字覚えてなかったりする。。。)。 Rustを書いているときに機能をGoogleで検索するときは、いい感じに検索してくれることを望んでいる(入力するキーワードが曖昧なことが多々ある。例えば、そのものズバリの名前をしらないときとか) あくまでも私が想像している挙動です。他の人とは違う可能性もあります。 なので、「検索」といってもさまざまな要素があるし、想定しているシーンも異なるので「難しい」なと思っています。 また、そんな「検索」ですが、世の中的にはあって当たり前だと思われていたり、お金や時間がかかるものと思われてなかったりもします。ま、けどそういったことも含めてやればやるほど面白いなと感じている今日このごろです。\n前置きはこのくらいにして、今回はシステムの特徴と検索機能について感じていることを書いてみようと思います。\nシステムの特徴と検索機能 先ほども書きましたが、検索は今やシステムに欠かせない機能となっています。 が、あればいいというものでもないのではないかなと。とりあえず検索できるべきだということで 検索機能を追加しても使いにくいものや、想定している動きをしない場合は使われないものになってしまいます。\nシステムでの検索機能は特に、「情報検索」(Wikipediaはこちら)と呼ばれたりもします。Wikipediaによるとこんな説明です。\n情報検索（じょうほうけんさく）とは、コンピュータを用いて大量のデータ群から目的に合致したものを取り出すこと。検索の対象となるデータには文書や画像、音声、映像、その他さまざまなメディアやその組み合わせとして記録されたデータなどが含まれる。\n「目的」と呼ばれるものは「ユーザーのニーズ」と呼ばれたりもします。 「合致したもの」というのがシステムが返す「検索結果」になります。検索結果は大体の場合、何かしらの順序でソートされていることが多いです。 ざっくり話をすると、「ユーザーのニーズ」を元に「(何かしらの順序でソートされている)検索結果」を返すという処理です。\nただ、この「ユーザーのニーズ」や「何かしらの順序でソートされている検索結果」はシステムの特性、特徴によってぜんぜん違うものになります。検索エンジンを入れただけで解決するものではありません。\nまた、システムは提供する側のニーズもあります。 ECサイトであればより多くのユーザーに購買してもらったり、 コミュニティサイトの場合は利用ユーザーを増やしてコンテンツや広告の収入を増やしたりといったニーズがあります。\nこれらの両方のニーズが検索機能に影響を与えたりもします。\nいくつか例を上げてみましょう。\n書籍の検索の場合 ユーザーのニーズは、「ある本を探す」ことです。そのためにユーザーがクエリを入力します。 クエリは、例にも出しましたがタイトルや著者名の読みだったりします。 検索窓が1つしかないというよりは、著者やタイトル、出版社などそれぞれの項目ごとに検索できるほうが便利だったりしますよね。 検索結果については、完全一致したものが一番最初に出てきてほしいこともあれば、出版年月日の降順で並べたいことなど、 その時々でやりたいことが変わったりもします。\n場合によっては、説明文などでも検索できると嬉しいこともあります。また、システムからは離れますが、図書館や書店で時々、「〇〇について書かれている本ありますか?」といった聞き方をしたりもします。\nまた、書店としては、探している本を見つけてもらうために検索端末などを用意しますが、そ れ以外の本も買ってもらえるといいですよね。 オンラインの書店などでは、検索結果や書籍詳細の画面に関連書籍が出ていることもあります。\n検索とは少し異なり、探索(なにか面白い本とかないかな?というようなニーズ)をしに、書店に行くこともあります。 書店で平積みされた本やポップなどを見て新しい本に興味を持つこともあります。\nオークションサイトやECサイトでの検索の場合 ユーザーのニーズは、「欲しい物を探す」ことです。 ユーザーが入力するクエリは、幅広いものになると思います。製品の型番を入力する人もいれば、 メーカー名や製品名だったり、ジャンルで絞り込んで検索することもあります。\n探されるもの(コンテンツ、アイテム)も多数に渡ります。 検索窓は1つかもしれませんが、検索結果には、絞り込み条件(ファセット)がいくつか並んで、絞り込んでいける仕組みが用意されていることが多いです。\n検索結果のソートは、価格順だったり人気順だったりします。 ただ、オークションサイトの場合は新しいもの順や、終了日時の早い物順だったりします。\nサイト提供者のニーズとしては、より多くのアイテムを購入してもらうこと(売上)です。 また、オークションサイトの場合は、アイテムを提供している人のニーズも影響してくるでしょう。 売りたい人はより多くの人の目に止まってほしいと思うはずなので、 様々な情報を付与していかに目にとまるか?といったことを考えてくると思います。\nまた、様々な商品を扱うECサイトの場合は、さらに色々と大変になってきます。たとえば、「iPhone」で検索されたときに、 iPhoneそのものが上位に来るべきなのか、ケースなどの周辺商品なのかだったりといった問題が出てきます。 商品の提供者が多数に渡る場合は、同一商品でもさまざまなお店から提供されてしまうために、検索結果一覧に多数同じ商品が並んだりもしますよね。\nレシピサイトでの検索の場合 ユーザーのニーズは「レシピを探す」です。が、探し方はユーザーによって様々です。 冷蔵庫にある材料を入力して検索することもあれば、食べたいものが決まっていてそのレシピを検索することもあります。 このとき、重要なのは類義語だったりするでしょう。食材やレシピは同じものでも様々な名前(例:パクチー、コリアンダー、シャンツァイ(香菜)など)を持っていたりします。また、部位や形によっても名前が変わったりもします。\n検索結果は人気順で並ぶことが多いでしょうか? ただ、レシピの提供がユーザーによるものなのか、サイト運営者が提供しているものかによっても変わってくるでしょう。\nサイト提供者のニーズとしては、レシピコミュニティサイトの場合は、ユーザー数の増加や広告の売上などがあるでしょう。 調味料などのメーカーがレシピサイトをやっている場合は、調味料の売上だったりします。この場合は、検索がどの程度売上に寄与しているのか?などを測ることが難しかったりしそうです。\n社内文書検索の場合 ユーザーのニーズは「文書を探す」です。探し方はファイル名であったり、ファイルのなかに出てくる単語だったりします。 社内用語・略語のような特殊な単語で検索されることもあるでしょう。ユーザーによっては、ぼんやりとした「こんな資料を探している」といったふんわりとした検索をしたくなることもあります。\n検索結果の表示順は「それっぽいもの」が上位に出てくることが望まれそうです。 ただ、古い文書が出てきても役に立たないこともあります。新しい文書のほうが役に立つことが多いので、最近作られたものというのも重要な情報になります。ただし、権限によっては見ることができなかったり、そもそも探すこともNGだったりもします。\n社内文書検索の提供者は、素早く検索できるものを提供することで仕事の効率を上げてもらったり、無駄を省くことができることを期待しているでしょう。\n昔からですが、社内の文書は様々な場所に散らばっていることが多いです。顧客管理システム、ファイルサーバー、Wiki、ウェブサイトなどこれらをまとめて検索できるシステムなどが望まれていることも多いです(使われるかはまた別ですが。。。)。\nスマートスピーカーの場合 ちょっと特殊な面白い例かなと思ってます。 音声で検索(というかお願い?)します。 システムとしては、ユーザーのニーズを理解するのに2段階あるのかなと。\n音声認識 認識した文章・キーワードで検索(場合によってはコマンド発行) これだけでも難易度が増します。\nさらに、画面のないスピーカーの場合は、結果は1件だけになります。これって結構難しいことだと思うんです。 画面があれば、検索結果を上位10件などのリストで表示して、あとはユーザーに選んでもらうことができますが、 音声の場合は1件だけしか返せません。 また、レスポンスタイムもシビアなものだと想定されます。ずっとスピーカーに黙っていられると困りますよね? きっと大変なんだろうなぁ(妄想)。\nこのように、検索と言っても、システムごとに要求・想定されるものは変わってきます。\nまとめ 例をいくつか上げましたが、ざっくりしすぎて発散してますかね。。。 想像している部分もあるので、この通りではないと思います。 ただ、システムによって、「検索」といってもシステムの特性上、 さまざまな物事、思惑が絡んでくるというのは想像してもらえたと思います?(思いたい)。\nシステムに検索機能を追加すると言っても、探したいものが何なのか?、探してもらうものはどういったものなのか?、 検索機能を追加することで何を達成したいのか?など考えることは色々あります。 どうやって、検索機能を実装するのか、その検索機能を実装するためにはどんな情報が必要なのか?などの検索機能のコアな部分を考えるだけでなく、提供しているシステム、コンテンツがどんなものかなど、システム全体を考えながら検索機能を考えていく事が検索をより良いものとして行くことだと思います。\nまた、検索されるものも検索する人もシステムが成長するのに合わせて変化していきいます。システム同様、一度作ればおしまいというものではないので、やることはいっぱいあるのかなと。\n次は、検索のパーツについてなにか書こうかなぁ。\nボヤキ もう少しまとめてから書いたほうがいいのかもなぁ。 もしくは、出てくる要素を整理するとか。 ユーザー、コンテンツ、コンテンツ提供者とかで。 ふんわりとしたブログになってしまった。 個別のシステムごとにもっと書けることもありそう。\n","date":1595842134,"dir":"post/2020/","id":"9da845cd31310b8952efd1be1881e651","lang":"ja","lastmod":1595842134,"permalink":"https://blog.johtani.info/blog/2020/07/27/improve-search-no1/","publishdate":"2020-07-27T18:28:54+09:00","summary":"今年の頭からシステムの検索周りを手伝う仕事をフリーランスとしてやっています。 検索の仕組みを知れば知るほど面白くなってきたからという理由になる","tags":["検索"],"title":"システムの特徴と検索機能について(検索システムに関する妄想その1)"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章 Rust the book - 第9章 Rust the book - 第10章 Rust the book - 第13章 14章は飛ばして、15章です(Cargoはまた別途調べればいいかな?と思って)。\n第15章 スマートポインタ たぶん、これを理解すれば、参照とベクタや構造体とかの組み合わせがもう少し効率よく使えるようになるのかなぁ?\nポインタの強い版? 参照カウント方式のスマートポインタ型 - Luceneとかで実装されてた気がするなぁ 複数の所有者!? DerefとDropトレイトを実装している構造体 ヒープのデータを指すBoxを使用する これはコンパイルエラー。let yのタイミングで借用してるので、書き換えでエラーになる。\nfn main() { let mut x = 5; let y = \u0026amp;x; assert_eq!(5, x); assert_eq!(5, *y); x = 6; assert_eq!(6, x); assert_eq!(6, *y); } こっちはOK。\nfn main() { let mut x = 5; // in stack let y = Box::new(x); // in heap assert_eq!(5, x); assert_eq!(5, *y); x = 6; assert_eq!(6, x); assert_eq!(6, *y); } 余談:コンパイラが変なワーニングを出してくれた。\nuse std::ops::Deref; impl\u0026lt;T, Z\u0026gt; Deref for MyBox\u0026lt;T, Z\u0026gt; { type Target = T; fn deref(\u0026amp;self) -\u0026gt; \u0026amp;T { \u0026amp;self.0 } } struct MyBox\u0026lt;T, Z\u0026gt;(T, Z); impl\u0026lt;T, Z\u0026gt; MyBox\u0026lt;T, Z\u0026gt; { fn new(x: T, y: Z) -\u0026gt; MyBox\u0026lt;T, Z\u0026gt; { MyBox(x, y) } } fn main() { let x = 5; let z = \u0026#34;10\u0026#34;; let y = MyBox::new(x, z); assert_eq!(5, x); assert_eq!(5, *y); } Derefトレイトでスマートポインタを普通の参照のように扱う 参照外し型強制 : 日本語ムズカシイネ Derefを自分で実装しないといけない場面がちょっと想像できてない。たぶん、Boxとかの説明に必要なので出てきたって感じなんだろうけど。 Dropトレイトで片付け時にコードを走らせる こっちは、リソース開放とかでいい感じにできそうだってのはわかった。 Dropはどんなときに実装するんだろう?Tantivyだとオブジェクトプールとかで使ってた。 Rcは、参照カウント方式のスマートポインタ これ、ここで作ったConsのリストを追っかけるためのサンプルも書いてほしい。 #[derive(Debug)] enum List { Cons(i32, Rc\u0026lt;List\u0026gt;), Nil, } fn print_typename\u0026lt;T\u0026gt;(_: T) { println!(\u0026#34;{}\u0026#34;, std::any::type_name::\u0026lt;T\u0026gt;()); } use List::{Cons, Nil}; use std::rc::Rc; use std::borrow::Borrow; fn main() { let z = Cons(5, Rc::new(Cons(10, Rc::new(Nil)))); let a = Rc::new(z); let _b = Cons(3, Rc::clone(\u0026amp;a)); let _c = Cons(4, Rc::clone(\u0026amp;a)); match \u0026amp;(*a) { Cons(v1, v2) =\u0026gt; { print_typename(v2); println!(\u0026#34;{}, {:?}\u0026#34;, v1, v2); }, Nil =\u0026gt; println!(\u0026#34;Nil!!\u0026#34;) }; } RefCellと内部可変性パターン 循環参照は、メモリをリークすることもある ","date":1594288778,"dir":"post/2020/","id":"208a8c072ea521c813b86ca7730eb880","lang":"ja","lastmod":1594288778,"permalink":"https://blog.johtani.info/blog/2020/07/09/hap15-rust-the-book/","publishdate":"2020-07-09T18:59:38+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第15章"},{"contents":"6月7日の週に開催されたBerlin Buzzwordsにオンライン出張してました。\nBerlin Buzzwordsとは? ベルリンで開催されている、Big Data、Scarability、Storage and Searchabilityに関するカンファレンスです。 今年はコロナウイルスの影響で、オンラインで開催されました。 また、同時期に検索に関する他のカンファレンス(以下の2つ)もベルリンで毎年開催されているのですが、今年はこれら3つのカンファレンスが1つのチケットで参加できる形で開催されました。\nMICES - MIX-CAMP E-COMMERCE SEARCH HAYSTACK - The Search Relevance Conference! sponsored by OpenSource Connections MICES、HAYSTACKは初参加ですが、検索に関するいくつかのトピックが聞けたので楽しかったです。\n6/7から6/12まで(がんばって)参加したので、その感想などをブログにとどめておきます。\nオンラインってどんな感じで開催されてた? まずは、オンライン開催がどのような感じだったのかをメモしておきます。\n有料のオンラインカンファレンス(事前にチケット購入が必要) 参加者用Slack カンファレンス数日前まではここで連絡とか質問が可能だった(もちろん、メールも来ましたけど)。 基本的なプラットフォームはBrellaのバーチャルイベントプラットフォーム 参加者同士のSNS機能 - 参加者同士の興味によって参加登録時に似たような人ですよとマッチングしたり。ビデオチャット機能もあり。 カンファレンスのスケジュール確認 - セッションのスケジュールの他に、参加者同士でのチャットのスケジュールも可能。一番便利だったのは自分のタイムゾーンも表示してくれること。 ストリームチャネル - セッションが行われている場所への誘導 スピーカー・スポンサーのリスト - スピーカーやスポンサーを探せる機能。スポンサー企業からは参加者も見ることができる セッションはYouTubeライブ ストリーム中だったらちょっと戻ったり、ポーズもできるので、便利だった セッション後の質疑応答にはJitsiというオープンソース!?のビデオカンファレンスの部屋が用意されてた(GitHubで公開されてるのか。https://github.com/jitsi)。 2日目、3日目はLTとかが終わったあとに、オンライン飲み会やってたっぽい(不参加) 主催者側も初めてだとは思うのですが、目立ったトラブルはなかったです。 ちょっとだけ遅れたりしてましたが、それほど影響はなかったです。 オンラインでの開催の一番のネックは、日本だと時差が辛いということです。 ベルリンが開催地なのですが、スピーカーや参加者はアメリカからの方が結構います。 そのため、開始時間が日本の23時といった具合になりました。\n面白かった\u0026amp;気になったセッション いくつか面白かった\u0026amp;もう一度見ないとなと思ったセッションと感想を。\nNatural Language queries at Salesforce scale セッションのページはこちら(2020年7月現在) Salesforceでどのような自然言語のようなクエリに対して書き換え、サジェストのようなことをやっているか?という話です。 Salesforceはテナント(企業)ごとに、データ構造などがカスタマイズ可能なため、 それぞれ個別に入力クエリ(例: new leads in sf)に対して、どういったパーツ(時間?場所?状態?)なのか?、どのフィールドへの条件なのか?といったものをNERのディープラーニングモデルとして捉えて解析しているという話でした。 企業毎にパーソナライズもされていると。実際にはパイプラインの一部でこの処理をやっており、それ以外にも処理はされているという話もありました。評価の話もされています。\nAMA - AI-Powered Search セッションのページはこちら(2020年7月現在) ManningでMEAP(絶賛書いているところ)のAI-Powered Searchの著者2名がAMA形式でいろんな質問に答えていく感じのやつです。 最初は近況報告(Treyさんがカンファレンス直前に転職してた)と、書籍がどんなものかを簡単に紹介したあと、質問に答えていく形式で2時間あります。ディープラーニングのモデルに関する話なども出てきています。 もう一度見たいと思ってたやつなので見ないとな。。。 (パネルっぽいセッションは、ヒントがなにもないので結構辛い)\nAsk Me Anything: Lucene 9 セッションのページはこちら(2020年7月現在) LuceneのPMCメンバーのUweさんが今後のLucene/Solrのいくつかの質問に答える感じのAMAです。 出てきた話(質問の前の)としては、Lucene 8の現状(Bloc-Max WANDとか)や、Java 11対応になるよとかです。 QAでは、SIMDの話、Approximate Nearest Neighborがどんな感じか?などの話でした。\nFrom commercial search to owned search セッションのページはこちら(2020年7月現在) カルフールスペインがECの検索をどのように導入したかという概要レベルの話でした。 モノリシックなものをマイクロサービスでk8s上に載せ替えたという大きなアーキテクチャ以降の話です。 Empathy.coが提供しているものを最終的には使用したみたいだけど、 どんな検索がされているのかといったニーズの調査ができるようになり、検索に絡んだKPIが改善した話でした。 COVID-19に絡んだクエリの変化についてもちょっと話が出てました。\nNeural Search in Practice セッションのページはこちら(2020年7月現在) Zalandoの検索の一部でNIR(Neural IRモデル)を利用してクエリの改善をやって、それをどうやってトレーニングして、テストしたかなどの話。 NIRを利用することで、複数の言語に対して改善が見られたという話だった。 今までは、クエリをいくつかの処理を元に翻訳して、入力された単語がカテゴリーに対するものなのか、スタイルに関するものなのか?などを判別して、クエリの補強?を行っている手法だった。 これに対して、ディープラーニングでクエリに対するクリックデータを元にトレーニングして、どういうクエリに対してどんなアイテムを出すのか?というモデルで検索を改善していた。 ヒット件数が0件だったり少ないものを対象にして上記の処理を入れているらしい。 (ということで、ディープラーニングをしっかり勉強しないといけないみたいなので、どうにかしたい。。。)\nTop 10 Lessons learned in search projects the past 10 years セッションのページはこちら(2020年7月現在) 10年検索プロジェクトをやってきた10個の気づきという感じのセッション。 ごく当たり前のことなんだけど、検索の導入・改善に関して、こういう事あって、何も考えないとこうなっちゃうよね。 だから、こんなことをやるべきだよね?という話です。 たとえば、検索窓はあるけど分析すらしていない状況(レッスン1)だとまずはこういうのやらないとね。とか、 検索クエリの分析・改善ばかりして、コンテンツの分析・改善を怠っていないか?という当たり前の話です。 当たり前なんだけどまとめてくれてるのは、やはりいいなぁと。\nClick logs and insights: Putting the search experts in your audience to work セッションのページはこちら(2020年7月現在) 検索ログとクリックログがあったときに、どういったことに使えるのかを料理のレシピに見立ててデモをするセッションで説明が面白かったです。 「こんなログがあったときに、ログのこの項目とこの項目を材料にすると、こんなのができますね」というのを、Elasticsearchにログを取り込んで、JupyterNotebookでデモをしていました。やはり動くものがあるとわかりやすいですねぇ。\nMixing and Matching: Diversifying Search Results セッションのページはこちら(2020年7月現在) これまたパネルセッションです。 検索結果の多様性に関するディスカッションでした。 これは、ECだからこその課題でもあるのかなと。検索自体は「何かを見つける」ための手段です。 普通に考えた場合は、ピンポイントで探していたものが見つかるのが嬉しいです。 が、例えば、ユーザーが検索した単語そのものが入っているだけのものが見つかるよりも、似たような商品も一緒に出てきてほしいことありますよね?また、ECサイトだと、回遊してほしいというのもあります。ということで、それぞれの方がどんな観点で多様性を考えているのかという話をするディスカッションになっていました。\nThought Vectors, Knowledge Graphs, and Curious Death(?) of Keyword Search セッションのページはこちら(2020年7月現在) AI-Powered Searchの著者の一人、Treyさんのセッション。ベクトルを検索にどうやって使うのか、 ベクトルで表現できるものはどんなものがあるのか?どんな検索エンジンで使えるのか?という話でした。 歴史的な話も交えつつ、検索だとこのへんで使えるんじゃないか?というような話でした。\n録画は? 気になったセッションをいくつか書き出してみました。 ちなみに、全セッションのビデオが公開されています。興味がある方は、ご覧いただければと。\nThe recordings from this year\u0026#39;s Berlin Buzzwords / MICES / Haystack joint event are now online. You can watch them all on our YouTube channel. Thank you once again to all of our wonderful speakers. https://t.co/hTRDmKNdpd\n\u0026mdash; @berlinbuzzwords@floss.social (@berlinbuzzwords) July 6, 2020 感想そして来年は? 楽しかったです。検索に関する話が色々聞けるのはやっぱ楽しいですね。サイトの特性(ECなのか、Wikipediaなのかなど)によっても「良い検索」の定義も変わるので、サービスなどがどんなものか、そしてそれを良くするためには検索はどんなことができるのか?といった話や、技術的な濃い話までいろいろな話を聞けました。 ただ、パネルは英語の聞き取りが辛いですね。。。あと、時差が。日本にいながらにして時差ボケは辛い。。。 オンライン飲み会には流石に参加できませんでした(4時とか5時から始まるし)。\n来年もオンラインで開催されたら間違いなく参加します。 オフラインのみだった場合はどうなるかなぁ。。。\n","date":1594005164,"dir":"post/2020/","id":"e5cb2e5d501d3db2db5d8f14984a66d4","lang":"ja","lastmod":1594005164,"permalink":"https://blog.johtani.info/blog/2020/07/06/attend-berlin-buzzwords/","publishdate":"2020-07-06T12:12:44+09:00","summary":"6月7日の週に開催されたBerlin Buzzwordsにオンライン出張してました。 Berlin Buzzwordsとは? ベルリンで開催されている、Big","tags":["conference","berlin buzzwords"],"title":"Berlin Buzzwordsにオンライン出張してた"},{"contents":"luceneutil - マニアックなツールのセットアップの続きです。 今回も誰得?なブログなので興味ない場合は飛ばしましょう。\n一応、luceneutilのREADMEにあるlocalrun.pyを動かせるところまでいったんですが、そこで一旦本題を思い返してみました。\nKuromojiの性能が落ちてるらしいし、Analyzer系のベンチマーク測ってるグラフに載せたほうがいいよね。\nこれが、そもそも動かしてみようと思った本題です。 READMEに書いてある手順で動いたんですが、よくよく調べてみると、Analyzer系の性能テストをやってるのは、別物っぽいぞと。 なんとなく、「ソフトウェア考古学」っぽくなってきましたね。\nAnalyzerの性能テストやってるのは? Analyzerのパフォーマンステストのグラフに出てきたTokenizerの名前を元にluceneutilのリポジトリを検索してみました。 EgdeNGrams当たりで検索するとヒットしたのが以下のファイルです。\nsrc/main/perf/TestAnalyzerPerf.java src/main/perf/TestAnalyzerPerf4x.java src/python/sumAnalyzerPerf.py 本命はsrc/main/perf/TestAnalyzerPerf.javaっぽいですね。 これを動かしている人はどれかな?ということで、今度はこのファイル名で検索します。\nsrc/python/runAnalyzerPerf.py どうやら、このPythonのファイルが先程のJavaファイルを実行して、性能を計測しているみたいです。 最初に出てきた、sumAnalyzerPerf.pyはrunAnalyzerPerf.pyの実行結果をAnalyzerの計測結果のグラフに追加する処理をしているようだということまでがわかりました。\nKuromojiをTestAnalyzerPerfに追加してみる 動かす対象がわかったので、あとは、やることを追加しましょうと。\nKuromojiの実行をTestAnalyzerPerfに追加 引数を追加して日本語版のWikipediaのファイルも読み込むようにする runAnalyzerPerf.pyに引数の追加とクラスパスの追加 JapaneseAnalyzerはlucene/analysis/kuromojiにビルドされるのでクラスパスを追加 引数に日本語版のWikipediaのファイルを追加 日本語版のWikipediaのデータの用意 こんなものかな?と。\n1と2はそれほど大変ではないので、3をまずはというところから始めてみました。\nWikipediaのXMLから1行1データのTSVファイルに まずは、どんなファイルを想定して動いているのかな?ということで、英語版のファイルがどんなものかを探してみることに。\nTestAnalyzerPerf.javaでは入力ファイルから1行ずつ文字列を読み込んでAnalyzerに処理させているだけというのがわかっています。なので、とりあえず、1行ずつ読めるような形式だと。 次に、runAnalyzerPerf.pyの55行目でenwiki-20130102-lines.txtというものを読み込んでいます。 が、これがよくわからないw\n前回とりあえず動いたときに、src/python/constants.pyにいろんなファイルへのパスとかが記載されていたのを覚えていたので、その当たりから調べてみます。 52行目に約665万件のドキュメントだというような記載があります。 前回のlocalrun.pyのファイルと似たような構造(1行に1記事が埋め込まれたTSVファイル)だろうと判断して、それを作りそうなプログラムを探してみました。 Wikiとかで検索して見つけたのがこのソースたちでした。\nsrc/python/wikiXMLToText.py - それっぽい名前ですよね? 中身を見ると、第1引数のファイル(XML)からpageタグごとにデータを抜き出し、処理をしてからタブ区切りで第2引数のファイルに書き出してます。 src/python/WikipediaExtractor.py - これもそれっぽいですね。 WikipediaExtractory.pyは界隈では有名なhttps://github.com/attardi/wikiextractorみたいです。こっちはなんとなく使い方はわかっています。 src/python/combineWikiFiles.py - これまたそれっぽい。 中身を見ると、1番目のコードで出力したデータに、2番めのコードで出力されたデータを元になにかしら処理をして、引数で与えられたファイルに出力する感じになってます。 ということで、完全に憶測ですが、日本語のWikipediaのXMLファイルを元に次のような流れでファイル作ってみればいいのかな?と。\njawiki-20200620-pages-articles.xml.bz2をwikimediaからダウンロードして、unbzip2で展開 python src/python/wikiXMLToText.py jawiki-20200620-pages-articles.xml jawiki-lines.txtで、1行ごとのデータを作る ちなみに、このプログラムは2箇所ほど修正しました。usernameタグが存在しないpageが出力されなさそうなので、デフォルトでusername: \u0026quot;\u0026quot;みたいなデータをattrってディクショナリに設定しました。 cat jawiki-20200620-pages-articles.xml | python -u src/python/WikipediaExtractor.py -b102400m -o extractedで別途XMLからデータを抽出 python src/python/combineWikiFiles.py jawiki-lines.txt extracted/AA/wiki_00 jawiki-20200620-lines.txtで2と3の出力をかけ合わせる で、まぁ、一応ファイルはできたんですが。。。 前回のブログ記事でセットアップしたときにダウンロードされたファイルはtitle、日付、本文の3つのカラムしかないんですが、上記の手順で作り出したファイルにはいろんなカラムが存在するんですよね(2が出力する項目が結構ある)。。。\n性能テスト用プログラムの書き換え 入力ファイルは出来上がったので、あとは、性能テストを走らせる部分の修正です。 修正部分はプルリク見たほうが明確なので省略で。\n実行してみた で、実行してみました。 せっかくなので、ブランチをbranch_8_5とmasterを対象にしてやってみました。 実際にはsrc/python/runAnalyzerPerf.pyにディレクトリ名やブランチ名が直書きされてたので書き換えつつ実施した結果はこちら。\n他の英語系のAnalyzerと同じグラフに載せてみたのですが、遅いので、下の方に表示されてます。 で、下に凹んだ部分(23 Juneのところ)がbranch_8_5で実行したときの性能値でした。 実際に遅くなってますね。ただ、他のAnalyzerの振れ幅も大きいので、別のグラフにしたほうがわかりやすくなるのかもなぁと思った次第です。\nということで、一応動いたんでプルリク出してみました。 採用されるかなぁ?\n一応誰得ブログはこれでおしまい。 Noriとかもこの感じで対応できるんじゃないかな?\n","date":1593050518,"dir":"post/2020/","id":"bbd2824ff0d5b801bb6f5da3a2a1a888","lang":"ja","lastmod":1593050518,"permalink":"https://blog.johtani.info/blog/2020/06/25/analyzer-perf-test-with-luceneutil/","publishdate":"2020-06-25T11:01:58+09:00","summary":"luceneutil - マニアックなツールのセットアップの続きです。 今回も誰得?なブログなので興味ない場合は飛ばしましょう。 一応、luceneutilのREAD","tags":["lucene"],"title":"luceneutil - Analyzer性能テストへのkuromojiの追加"},{"contents":"LuceneのFSTの修正に関連して、Kuromojiのパフォーマンス問題が出ているようです。 この問題自体はLucene 8.6.0以降で直る予定のようなのです(Elasticsearchへの影響範囲についてはこれが参考になるかな?)。 で、これに関連して、ベンチマーク計らないとねという話が出ていて、 昔から、LuceneのMikeさんがやっているベンチマークのグラフに載せるのがいいよねという話になっていました。 どうも、これについては、Luceneの中にあるbenchmarkというプロジェクトではなく、MikeさんのGitHubリポジトリにあるプログラムで計測しているようです。\nじゃあ、手元でこれどうやって動かすんだろう?ということでやってみたブログになります。 おそらく、99.99%の人は興味ないと思うのでスルーしていただくのがいいと思います。備忘録のために書いてます。\nとりあえずgit clone 公開されているリポジトリはこちらです。\n手順通りに? とりあえず、READMEにセットアップなどのやり方があったんで追っていくことに。 とりあえず動くまでの手順は以下のとおりです。\nディレクトリを決める $LUCENE_BENCH_HOMEが起点になります。名前は何でもいいみたいです。 cd $LUCENE_BENCH_HOME リポジトリをクローン - git clone https://github.com/mikemccand/luceneutil.git utilです。 コレ自体は問題なし。 cd util セットアップスクリプトを実行 - python src/python/setup.py -download ここがすごく時間かかります。6GBのファイルをゆっくりダウンロードしてきますので、一晩置いておきましょう(起きたら終わってた) $LUCENE_BENCH_HOME/dataにenwiki-20120502-lines-1k.txt.lzmaとwikimedium500.tasksいうファイルがダウンロードされている。 ダウンロードした圧縮ファイルを展開 - unlzma enwiki-20120502-lines-1k.txt.lzma macOSにlzmaのコマンド入ってるんですね。知らなかった。 終わったらcd ../で$LUCENE_BENCH_HOMEに戻っておく ベンチマーク対象となるLuceneを用意 - git clone https://github.com/apache/lucene-solr.git READMEにはlucene_candidateとlucene_baselineって名前でって書いてあったのですが、これだと、この後の実行フェーズでエラーになりました。 trunkとpatchというディレクトリにそれぞれ変更しました。localrun.pyを実行したらこのディレクトリ名だったので(相変わらず、自分、行きあたりばったりな対応してるなぁ。。。) とりあえず動くかどうかを確認したかったので、trunkとpatchはどちらもリポジトリをcloneしたものになってます。動いたのを確認したら、タグを指定して比較したいブランチをチェックアウトする予定。 trunkとpatchをビルド - ant jar * localrun.pyを実行 - cd utilそして。。。 5.で記述したディレクトリ以外に1箇所Pythonのコードを書き換えた。 src/python/benchUtil.py内部にhppc-0.8.1.jarのファイルの存在チェックをしているのだが、2020/06/23時点でのLuceneのリポジトリの依存関係だとhppc-0.8.2.jarになっており、ファイルが見つからないエラーが出たため、0.8.2に書き換えた。970行目付近。 改めて実行したら成功した。 まだ途中 とりあえず、実行するところまではできましたが、結果の見方とかちゃんと調べないとなぁ。 いくつかローカルで対応したものについてはあとでGitHubにIssue立てとくべきだな。\nと、動くのを確認したので、日本語周りの準備をしてみてるところです。\n終わったこと\n日本語のWikipediaのデータjawiki-20200620-pages-articles.xml.bz2をダウンロードして展開 試している途中\nWikipediaExtractorでXMLからデータを抽出 - cat ~/tmp/wiki/jawiki-20200620-pages-articles.xml | python -u src/python/WikipediaExtractor.py -b102400m -o extracted これは手順が違うかも???? python src/python/wikiXMLToText.py ~/tmp/wiki/20200620-pages-articles.xml ./hoge.txt これで、title、日付、本文が抜き出せそう? この後にcombineWikiFiles.pyの実行かな? って感じです。 誰得だろうこれ???\n","date":1592917109,"dir":"post/2020/","id":"8a1ea5d5cf843bc5955a94cfcc321e92","lang":"ja","lastmod":1592917109,"permalink":"https://blog.johtani.info/blog/2020/06/23/how-to-use-luceneutil/","publishdate":"2020-06-23T21:58:29+09:00","summary":"LuceneのFSTの修正に関連して、Kuromojiのパフォーマンス問題が出ているようです。 この問題自体はLucene 8.6.0以降で直る","tags":["lucene"],"title":"luceneutil - マニアックなツールのセットアップ"},{"contents":"Azure Cognitive Searchで日本語を扱うときに、形態素解析器を使いたい場合、2種類のAnalyzerが用意されています。今回はこれらの違いがどんなものかを見ていくことにします。\nAnalyzerとは? まずは、その前にAnalyzerとは何者か?というのを少しだけ。 Azure Cognitive Searchは転置インデックスを内部で作成して、検索を行っています。 この、転置インデックスは、「単語」がどのドキュメントに入っているか?を素早く見つけることができるデータ構造となっています。\nAzure Cognitive Searchは、この「単語」を入力された文章から生成するときに、Analyzerというものを利用します。 Analyzerは入力された文章をある規則に則って単語に分割する機能です。 この「ある規則」が、各種言語や用途によって様々に用意されています。 今回はこの中のja.luceneとja.microsoftという2種類のAnalyzerについて違いを見ていきます。\n2種類のAnalyzerの違いはどんなもの? このAnalyzerの挙動を見るためのエンドポイントとしてanalyzeというAPIがあります(詳細は昔のブログを参照)。\nこのAPIを利用して、Wikipediaのいくつかの文章を単語に区切って見て、 ja.microsoftがどんな動きをしているのか想像してみます(残念ながらja.microsoftの仕様?や挙動についてはページが見つからないため)。\nもとの文章と解析結果(一部抜粋) 文章は、手元のElasticsearchに登録したjawikiのデータからランダムに抽出しています。また、自前のツールで生成したWikipediaのデータなので、まだ一部、見苦しい文字列になっています(そっちもなおさないと)。\n1. 砂川（熊本県） thumb|250px|right|上砂川橋より上流方砂川（すながわ）は、熊本県宇城市・八代郡氷川町を流れる二級河川。\nこの文字列から抽出された単語で特徴的なものを一部抜粋しました。\nja.microsoft ja.lucene 250px 250 px 上砂 上, 上砂川 川橋 砂川 橋 宇城 宇 市 城市 二級 二 ^ 級 まず、最初の250pxですが、ja.microsoftでは、pxが単位であると判定しているのか、数値と合わせた単語として抽出されています。この場合、250で検索しても、この文字列はヒットしない形になるので、ノイズが減ることが考えられるかと。\n上砂川橋という文字は、分割の仕方が別れました。 ja.luceneでは、上砂川という単語が地名として辞書に存在するために、このような分割になっています。ja.microsoftのデータは品詞の情報が取れないのですが、上砂、川橋ともに、名詞として辞書に存在しているのではないかなと。ja.luceneには川橋という単語は存在していないようでした。\n宇城市(うきし)については、2005年に合併でできた市のようで、ja.luceneが利用している辞書には存在しない可能性があり、宇城という文字が抽出できてないと思われます。\n最後は二級です。ja.luceneでは、数字と助数詞として分割されています。こちらも何かしらのロジックにより、二級という1単語でヒットできるように数字と単位?が合わせた単語で出てくる仕組みがja.microsoftなのかなと。\n2. UEFA U-18女子選手権2000 UEFA U-18女子選手権2000は第3回目のUEFA U-18女子選手権である。決勝トーナメントは2000年7月27日から8月4日までフランスで行われ、ドイツが初優勝を果たした。\nこの文字列から抽出された単語で特徴的なものを一部抜粋しました。\nja.microsoft ja.lucene u-18, u u 18, nn18 18 第3回目 第 3 回 目 トーナメント, トナメント トーナメント 2000年 2000 年 7月 7 月 27日 27 日 数字を含む単語第3回目や2000年、7月などは、ja.microsoftは先程と同様、数字と単位の組み合わせを1単語として出力しています。\nまた、トーナメントという単語をトナメントという形で、長音を除去した形で出力しています。 今回の文字列ではないですが、この他に、センターをセンターとセンタの2パターンの単語で出力するといったことを行っています。 ja.luceneの場合、単語の最後に長音がある場合だけセンタとして、長音を除去した単語が出力されます。 これは、長音の表記ゆれに対応するためではないかなと。たとえば、インターフェースとインタフェース、インターフェイスのように、人や文章によって、間にでてくる長音を使ったり使わなかったりという表記ゆれに対応するためだと思われます。 その他にも、イプロゥヴェトをイプロゥベトに、ネクストをネキストに、バラエティをバラエチにも変換するなどといった処理をしてくれるようです。カタカナの表記ゆれには強そうですね(これどうやってるんだろう?)。\nja.microsoftでは、nn18というちょっと変わった単語も出てきていました。純粋な数字の場合はnnと入力してくれるようで、数字だけで検索したい場合に利用できるのかな?これはドキュメントに書いておいてほしいかも?\n共通点 ja.lucene、ja.microsoftともに、共通している動作として、「てにをは」といった単語は除去されていました。違いがあるものとしては、「より」(助詞-格助詞-一般)、「されている」(動詞-自立、動詞-接尾、助詞-接続助詞、動詞-非自立)、「ある」(助動詞)といったものはja.microsoftでは除去されずに出てきていました。 ストップワード的に「てにをは」あたりを除去をしている感じでしょうか?\nアルファベットで構成されている単語についても、基本はそのまま出力される挙動のようでした。\nじゃあどっちがいいの? 残念ながらどちらがいいかは、一長一短かなぁと。 ja.luceneに関しては、Luceneの仕組みを利用しているので、Elasticsearchなどを使えば、個別の単語についてより詳細の情報を取得することが可能です(品詞、読みなど)。ja.microsoftについては、残念ながら手の入れようがないので、そういう動きのものだという割り切った使い方になるでしょうか? ただ、長音の除去による表記ゆれなどについては、便利な機能なので、そのあたりの問題に対応したい場合は、ja.microsoftを活用するのも良いかと思います。\n個人的には、より細かい単語としてインデックスに登録できるもののほうが、柔軟な検索には対応できるのではないかなぁと考えています(Kuromojiの辞書をUniDicにするとか?も考えますが、これはAzure Searchではできないですが)。\nまとめ Wikipediaのデータをいくつか使って、ja.microsoftとja.luceneの違いについて、考察してみました。何かの役に立てばと。 他に、これはどんな感じになるの?などありましたら、コメントいただければと。\n","date":1591692240,"dir":"post/2020/","id":"82a115ab8d617e4e96813587fe3a6049","lang":"ja","lastmod":1591692240,"permalink":"https://blog.johtani.info/blog/2020/06/09/difference-analyzers-in-azure-search/","publishdate":"2020-06-09T17:44:00+09:00","summary":"Azure Cognitive Searchで日本語を扱うときに、形態素解析器を使いたい場合、2種類のAnalyzerが用意されています。今回はこれらの違いがどんなもの","tags":["azure search","kuromoji"],"title":"Azure Cognitive Searchでの日本語向けAnalyzerの違い"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章 Rust the book - 第9章 Rust the book - 第10章 11章、12章はちょっと飛ばして、13章です。\n第13章 イテレータ、クロージャです。 12章の話もちょっと出てくるのか。\nクロージャ 基本的に、「変数には値が束縛されている」という固定観念がずっと頭にこびりついたままなので、クロージャに慣れないんだろうなぁ。そろそろこの固定概念をどうにかしないと。\n匿名関数で、変数に保存したり引数に渡せる ちょっと面白い話(ワークアウト)で実際に考えられる手法の説明がいくつか行われる 関数でリファクタリング これが自分がよくやるパターンかなぁ。クロージャになれてないので。。。 クロージャーを変数に束縛 呼び出しは関数みたいな感じ(ここで少し混乱) これだと、結局呼び出されたタイミングが複数回あるよね? -\u0026gt; あはりそうだった ここで、閑話休題で、クロージャの型推論とか注釈の話。 クロージャは狭い文脈だし、外に公開しているものでもないので、戻り値なども定義してなくてもいいよねとのこと。書くことも可能?なので、書いてわかりやすくするのもありなんだろうな。\n推論についてはこれまで通りで、2回異なる型の変数で呼び出すと、2回目で怒られていた。\n遅延評価(クロージャを保持する構造体!?) Fnトレイト トレイトとMatchの組み合わせだからこのへんで説明する形になるのか。 これを真似すれば、いくつか処理を簡素化できるかもしれないなぁ、たしかに。 なければ実行するみたいな処理を書きたいことがよくあるし。Javaだとnullで定義しといて、nullだったらみたいなのがあるから。 Cacherはサンプルだからこの名前でいいけど、自分だと、どんな名前にするかなぁ?\n振る舞いは難しくなるのか。Cacher実装の限界を読むと。\n関数にするとスコープが変わるのでアクセスできなくなると。。。コンパイラが教えてくれるのは便利だな。\n環境から値をキャプチャする3つの方法\n多分この話が一番クロージャに意味がある話なんだと思う。 イテレータ 回しましょう。\n便利。ただ、こういう書き方に自分が慣れてないので、そっちを補正しないとなぁ。 どれがイテレータ?っていうのを判別するのがちょっとむずかしい(慣れの問題かなぁ) イテレータアダプタ便利。どんなのがあるのか?とかがやっとわかってきた。 パフォーマンスに関しては、うーん、どうなんだろう?という感想だった。 ","date":1591259849,"dir":"post/2020/","id":"e74d071363645a588f858b35231128c4","lang":"ja","lastmod":1591259849,"permalink":"https://blog.johtani.info/blog/2020/06/04/chap13-rust-the-book/","publishdate":"2020-06-04T17:37:29+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第13章"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章 Rust the book - 第9章 第10章 ジェネリック、トレイト、ライフタイムです。 手強そう。\nいきなり関数の切り出し方みたいな話が始まって面食らいました。\nジェネリックなデータ型 ジェネリックはJavaにもあるので、それほど理解に苦しむことはなかったです。 また、OptionやResultですでに経験済みでしたし。\nただ、impl\u0026lt;T\u0026gt; Point\u0026lt;T\u0026gt;{、このメソッド定義は少し最初は戸惑いました。 言われてみれば、なるほどなんですけど。\nコンパイル時にコンパイラが単相化を行うことにより、必要最低限なコードを生成してくるというのは理にかなっているなぁと。\nトレイト: 共通の振る舞いを定義する 出だしにもありますが、「インターフェイス」という機能に類似していると考えると割とすんなりと理解が進みました。 ただ、Javaだと、インターフェースはクラスとセットなため、トレイとの実装に関する記述方法は少し戸惑いが。\nデフォルト実装との組み合わせはAbstractに似た処理になるなと考えながら読みすすめました。\n「トレイト境界」という日本語には少し違和感を覚えましたが、線引をして、制限をかけるという理解でいいのかな?\n実際には#[derive()]などで、トレイトを自分で実装する必要がないなどの、便利機能も用意されており、このあたりのコードの追い方がまだ少し慣れていないかもなぁと。便利なんですけど。。。\n少しだけ気になったので、動作確認したのは次の実装です。\nトレイトで宣言されている関数と構造体が独自に実装する関数の名前がかぶるとどうなるのかという実験です。 構造体独自のメソッドが優先される感じになりそう。\npub struct Tweet { pub username: String, pub content: String, pub reply: bool, pub retweet: bool, } pub trait Summary { fn summarize_author(\u0026amp;self) -\u0026gt; String; fn summarize(\u0026amp;self) -\u0026gt; String { // {}さんからもっと読む format!(\u0026#34;(Read more from {}...)\u0026#34;, self.summarize_author()) } } impl Tweet { fn summarize_author(\u0026amp;self) -\u0026gt; String { format!(\u0026#34;hoge {}\u0026#34;, self.username) } fn to_string(\u0026amp;self) -\u0026gt; String { format!(\u0026#34;fuga\u0026#34;) } } impl Summary for Tweet { fn summarize_author(\u0026amp;self) -\u0026gt; String { format!(\u0026#34;@{}\u0026#34;, self.username) } } pub fn summary\u0026lt;T: Summary\u0026gt;(hoge: \u0026amp;T) { println!(\u0026#34;{}\u0026#34;, hoge.summarize_author()); } pub fn main() { let tweet = Tweet { username: String::from(\u0026#34;horse_ebooks\u0026#34;), content: String::from(\u0026#34;of course, as you probably already know, people\u0026#34;), reply: false, retweet: false, }; println!(\u0026#34;{}\u0026#34;, tweet.summarize_author()); summary(\u0026amp;tweet); println!(\u0026#34;{}\u0026#34;, Summary::summarize_author(\u0026amp;tweet)); } ライフタイムで参照を有効化する 言われてみればそうですが、プログラマが色々考えないとまぁ、行けないんですねという感想。\nただ、借用チェッカーが賢くやってくれるおかげで、全てにライフタイム注釈をつけなくて良くなっているというのがわかりました。 逆に言うと、なんとなくRustを書き始めてしまったので、それを知らずに書いたせいで、コンパイラに怒られてても「?」となっていたのかと。。。\n疑問点がいくつかあって、\n通常はどんなライフタイム注釈をみんな書いてるんだろう?'aとかざっくりしすぎてる? 1つのメソッド、関数にライフタイム注釈が大量に出てくるような書き方をした場合は設計がおかしいのでは?って考えたほうがいいのかも? ジェネリックな型とライフタイム引数の順序を入れ替えてみても動くだろ?とおもって入れ替えてみたら怒られた。 あとは、構造体+ジェネリックが絡んできたら少しこんがらがってきそうっという感じです。 まぁ、これから先は実際に書いてみないことにはわからないんだろうなと。\nまとめ 読みました。 実際にはプログラムを書きながら慣れていく感じだろうなぁと。 まだまだ、あれ?ジェネリックってどう書くんだっけ?とか、ライフタイム注釈どうやって付けて、使うときはどうすんだ?みたいになりながら、 出てくるサンプルを少し変えてみてはどうやって動くんだろうこの場合?みたいなことをやってました。 次は、11章、12章を少しだけ自習しつつ、13章に入る予定です(知り合いと一緒に読みすすめてる)。\n","date":1590656815,"dir":"post/2020/","id":"163beeae9620c1a6a46a38aa7ebd9663","lang":"ja","lastmod":1590656815,"permalink":"https://blog.johtani.info/blog/2020/05/28/chap10-rust-the-book/","publishdate":"2020-05-28T18:06:55+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第10章"},{"contents":"今回はAzure Cognitive SearchのSDKを利用したアプリケーションが、実際にAzure Cognitive Searchに対して送信しているリクエストのパラメータとボディをログに保存する方法について紹介します。\n動機 アプリケーションでリクエストを組み立てて、SDK経由で送信していると、最終的にAzure Cognitive Searchに対して送信されているリクエストのパラメータや検索条件などをひと目で見たいことがあります。 アプリケーションでは、ソート条件や、クエリ文字列の組み立てなどの処理は異なる場所で行われたりしますので。\nまた、公式リファレンスでは、機能の説明はRest APIの使い方と組み合わせで説明されることが多いです。\nということで、SDKを利用しているアプリからAzure Searchへ送信されているリクエストをログに保存する方法を調べてみました。\n方法 調べてみるといくつかの手段を取ることができそうだとわかりました。実際に調べて実装する方法を4種類ほど試してみたのでブログに残しておきます。なお、2020年4月時点でのSDKとAzureの仕組みに基づいたブログになります。最新版ではお手軽な方法があるかもしれません。\nDelegatingHandlerを利用する ServiceClientTracingの機能を利用する Azure Application Insightsを活用する Azure Cognitive Searchのコンソールにある診断情報の機能を利用する 1、2はAzure Cognitive SearchのSDKのリファレンスから当たりを付けて見つけた方法です。 3はApplication Insights、4はAzure Cognitive Searchの機能になります。 これらの方法について個別に説明していきます。\n1. DelegatingHandleを利用する まずは、SDKでロギングの機能がないかを調べて見つけた機能がこちらです。 SDKのSearchServiceClientのコンストラクタの引数にDelegatingHandlerというものが渡せることを発見しました。\nこれは、.NET FrameworkのHttpのAPIに存在するクラスで、HTTPのクライアントがHTTPの送受信時に、処理を挟むことができる機能です。フレームワーク側で、LoggingHttpMessaggeHandlerというクラスを用意してくれていましたが、残念ながらこちらは、リクエストとレスポンスのヘッダのみをロギングするクラスでした。 ということで、リクエストボディをログに出力したい場合は独自に拡張してやる必要があります。なお、ロギングにはMicrosoft.Extensions.LoggingのILoggerを使用します。\nまた、Azure Cognitive SearchのSDK側に違う問題点もありました。チュートリアルにあるように、検索するときには、SDKは次のような使い方を想定しています。\n// Create a service and index client. _serviceClient = new SearchServiceClient(searchServiceName, new SearchCredentials(queryApiKey)); _indexClient = _serviceClient.Indexes.GetClient(\u0026#34;hotels\u0026#34;); インデックス用のクライアントを取得するために、GetClient(インデックス名)というメソッドを使用します。このGetClientメソッドのバリエーションとして、DelegatingHandlerを受け取るメソッドがないのです。。。\nということで、DelegationHandlerを活用する方法としては、以下の2つを実装する必要があります。\nCustomなLoggingHttpMessageHandlerクラスを実装 GetClientと同等の処理をDelegatingHandlerを引数にしたものを実装する 以上の2つを実装し、アプリケーション側から2で作成したGetClientを呼び出すことで、リクエストをボディも含めてログ出力することが可能になります。以下は実装例です。\nCustomHttpMessageHandlerクラス。\nusing System; using System.Collections.Generic; using System.Diagnostics; using System.Net.Http; using System.Net.Http.Headers; using System.Text; using System.Threading; using System.Threading.Tasks; using Microsoft.Extensions.Logging; namespace AzureSearchSample { public class CustomLoggingHttpMessageHandler : DelegatingHandler { private readonly ILogger _logger; private readonly bool _logContent = false; public CustomLoggingHttpMessageHandler(ILogger logger, bool logContent) { if (logger == null) { throw new ArgumentNullException(nameof(logger)); } this._logger = logger; this._logContent = logContent; } protected override async Task\u0026lt;HttpResponseMessage\u0026gt; SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) { if (request == null) { throw new ArgumentNullException(nameof(request)); } await Log.RequestStart(this._logger, request, this._logContent); var stopwatch = new Stopwatch(); HttpResponseMessage response = await base.SendAsync(request, cancellationToken).ConfigureAwait(false); stopwatch.Stop(); await Log.RequestEnd(this._logger, response, stopwatch.Elapsed); return response; } private static class Log { private static class EventIds { public static readonly EventId RequestStart = new EventId(100, \u0026#34;RequestStart\u0026#34;); public static readonly EventId RequestEnd = new EventId(101, \u0026#34;RequestEnd\u0026#34;); } public static async Task RequestStart(ILogger logger, HttpRequestMessage request, bool logContent) { StringBuilder message = new StringBuilder(); message.AppendLine($\u0026#34;Sending HTTP request {request.Method} {request.RequestUri}\u0026#34;); if (logger.IsEnabled(LogLevel.Trace)) { LogHttpHeaders(message, request.Headers); await LogHttpContent(message, request.Content, logContent); logger.Log( LogLevel.Trace, EventIds.RequestStart, message, null, (state, ex) =\u0026gt; state.ToString()); } } public static async Task RequestEnd(ILogger logger, HttpResponseMessage response, TimeSpan duration) { StringBuilder message = new StringBuilder(); message.AppendLine( $\u0026#34;Recieving HTTP response after {duration.TotalMilliseconds}ms - {response.StatusCode}\u0026#34;); if (logger.IsEnabled(LogLevel.Trace)) { LogHttpHeaders(message, response.Headers); await LogHttpContent(message, response.Content, false); logger.Log( LogLevel.Trace, EventIds.RequestEnd, message, null, (state, ex) =\u0026gt; state.ToString() ); } } private static void LogHttpHeaders(StringBuilder message, HttpHeaders headers) { if (headers == null) throw new ArgumentNullException(nameof(headers)); foreach (KeyValuePair\u0026lt;string, IEnumerable\u0026lt;string\u0026gt;\u0026gt; header in headers) { foreach (string value in header.Value) { message.AppendLine($\u0026#34;{header.Key}: {value}\u0026#34;); } } } private static async Task LogHttpContent(StringBuilder message, HttpContent content, bool logContent) { if (content != null) { foreach (KeyValuePair\u0026lt;string,IEnumerable\u0026lt;string\u0026gt;\u0026gt; header in content.Headers) { foreach (string value in header.Value) { message.AppendLine($\u0026#34;{header.Key}: {value}\u0026#34;); } } if (logContent) { string contentBody = await content.ReadAsStringAsync(); message.AppendLine(contentBody); } } } } } } GetClientの実装\nprivate ISearchIndexClient GetClient(string indexName, params DelegatingHandler[] handlers) { var rootHandler = _searchServiceClient.HttpMessageHandlers.OfType\u0026lt;HttpClientHandler\u0026gt;().SingleOrDefault(); var indexClient = new SearchIndexClient(_searchServiceClient.SearchServiceName, indexName, _searchServiceClient.SearchCredentials, rootHandler, handlers) { SearchDnsSuffix = _searchServiceClient.SearchDnsSuffix }; indexClient.HttpClient.Timeout = _searchServiceClient.HttpClient.Timeout; return indexClient; } 出力されるログ例\n2020/04/14 19:17:53.591|TRACE|Sending HTTP request POST https://サービス名.search.windows.net/indexes(\u0026#39;インデックス名\u0026#39;)/docs/search.post.search?api-version=2019-05-06 client-request-id: be02140f-3a07-48cc-b018-d8aa5e819bc3 Accept-Language: en-US Accept: application/json; odata.metadata=none api-key: APIキー User-Agent: FxVersion/4.700.20.11803 User-Agent: OSName/MacOs User-Agent: OSVersion/Darwin.19.4.0.Darwin.Kernel.Version.19.4.0.Wed.Mar.4.22.28.40.PST.2020.root.xnu.6153.101.6.15RELEASE.X86.64 User-Agent: Microsoft.Azure.Search.SearchIndexClient/10.100.19.52907 Content-Type: application/json; charset=utf-8 { \u0026#34;count\u0026#34;: false, \u0026#34;facets\u0026#34;: [], \u0026#34;queryType\u0026#34;: \u0026#34;simple\u0026#34;, \u0026#34;scoringParameters\u0026#34;: [], \u0026#34;search\u0026#34;: \u0026#34;azure\u0026#34;, \u0026#34;searchMode\u0026#34;: \u0026#34;any\u0026#34; } |AzureSearchSample.SearchService|EventId_Id=100, EventId_Name=RequestStart, EventId=RequestStart メリット、デメリット Azure Cognitive Searchの検索の処理だけを対象にリクエストのログを出力することが可能です。また、影響範囲はアプリケーションだけに閉じていますので、デバッグ目的などでログ出力したい場合に、自分だけの手元でログの確認が可能になります。\nデメリットとしては、独自に実装しなければいけない範囲が広いことです。\n2. ServiceClientTracingの機能を利用する Microsoft.Rest.ClientRuntimeというライブラリをAzure Cognitive Searchは利用しています。 このライブラリにServiceClientTracingというクラスが存在します。 なにやら、クライアントの処理のトレースができそうです。\nAzure Cognitive SearchのSDKの実装がGitHubに公開されており、検索リクエストの処理を投げる直前に、このトレースの仕組がONになっていると、ServiceClientTracing.SendRequestメソッドを呼び出していました。\n実際にSendRequestメソッドに送られたものに対して何かしらの処理を行うのは、IServiceClientTracingIntercepterインターフェースを実装したクラスになります。 このインターフェースの実装がLog4Netに存在します。Log4Netを利用している場合は、これを活用すれば楽ができます。\n実際にServiceClientTracingを有効にするには、以下の2行を呼び出すだけです。\nServiceClientTracing.IsEnabled = true; ServiceClientTracing.AddTracingInterceptor(new Log4NetTracingInterceptor()); あとは、Rest.ClientRuntimeがよしなにやってくれます。 1とは異なり、トレースログなので、リクエストのボディについても出力してくれます。\n2020-05-26 19:09:04,058 [1] DEBUG Microsoft.Rest.Tracing.Log4Net.Log4NetTracingInterceptor [(null)] - invocationId: 1 instance: Microsoft.Azure.Search.DocumentsProxyOperations method: SearchPost parameters: {searchRequest=Microsoft.Azure.Search.Models.SearchRequest,clientRequestId=,cancellationToken=System.Threading.CancellationToken} 2020-05-26 19:09:04,164 [1] DEBUG Microsoft.Rest.Tracing.Log4Net.Log4NetTracingInterceptor [(null)] - invocationId: 1 request: Method: POST, RequestUri: \u0026#39;https://サービス名.search.windows.net/indexes(\u0026#39;インデックス名\u0026#39;)/docs/search.post.search?api-version=2019-05-06\u0026#39;, Version: 2.0, Content: System.Net.Http.StringContent, Headers: { client-request-id: 591cb14f-e5c2-4a85-977d-01d1f6431ddc Accept-Language: en-US Accept: application/json; odata.metadata=none api-key: APIキー Content-Type: application/json; charset=utf-8 } Body: { { \u0026#34;count\u0026#34;: false, \u0026#34;facets\u0026#34;: [], \u0026#34;queryType\u0026#34;: \u0026#34;simple\u0026#34;, \u0026#34;scoringParameters\u0026#34;: [], \u0026#34;search\u0026#34;: \u0026#34;azure\u0026#34;, \u0026#34;searchMode\u0026#34;: \u0026#34;any\u0026#34; } } 2020-05-26 19:09:04,459 [Thread Pool Worker] DEBUG Microsoft.Rest.Tracing.Log4Net.Log4NetTracingInterceptor [(null)] - invocationId: 1 response: StatusCode: 200, ReasonPhrase: \u0026#39;OK\u0026#39;, Version: 1.1, Content: System.Net.Http.StreamContent, Headers: { Cache-Control: no-cache Pragma: no-cache request-id: 591cb14f-e5c2-4a85-977d-01d1f6431ddc elapsed-time: 72 OData-Version: 4.0 Preference-Applied: odata.include-annotations=\u0026#34;*\u0026#34; Strict-Transport-Security: max-age=15724800; includeSubDomains Date: Tue, 26 May 2020 10:09:04 GMT Content-Type: application/json; odata.metadata=none Expires: -1 Content-Length: 376 } メリット、デメリット Log4Netを利用しているアプリの場合、2行だけを追加することで実装が完了するのがお手軽な点です。\n難点としては、Rest Client全てにたいしてトレース処理が入ってしまうので、Azure Cognitive Search以外にもRestクライアントを利用しているものが存在した場合、ログの量が増えてしまいます。また、検索以外の処理でもトレースされてしまうのもデメリットになります。\nLog4Net以外のログ機構を使用している場合は、自分でIServiceClientTracingInterceptorを実装する必要も出てきます(参考:StackOverflow)。\n3. Azure Application Insightsを活用する ここから紹介する3と4については、ログの出力先がAzure上になります。\nAzureのApplication Insightsを利用する方法です。 Azure?.NET?のアプリケーションパフォーマンスモニタリングのサービスです。\nApplication Insightsを自分のアプリケーションに設定することで、アプリケーションのパフォーマンス監視に関する情報がAzure上のApplication Insightsリソースに送信されるようになります。\nただ、Application Insightsのデフォルトの機能では、URL程度の情報だけが送信されます(参考:しばやんさんのブログ)\nこちらも拡張機能が用意されており、ITelemetryInitializerのインターフェースを実装したクラスを用意することで、独自の情報をApplication Insightsに出力することが可能となります。詳細についてはしばやんさんのブログを参考にしてもらうのが良いかと。\nHttpリクエストを出力する実装例は次のとおりです。ただ、ちょっとうまく行かないパターンがあったので、コメントアウトとして残してあったりします(なんでだろう?)\nusing System.Collections.Generic; using System.Net.Http; using System.Net.Http.Headers; using Microsoft.ApplicationInsights.Channel; using Microsoft.ApplicationInsights.DataContracts; using Microsoft.ApplicationInsights.Extensibility; namespace AzureSearchWebSample.ApplicationInsights { public class HttpRequestInitializer : ITelemetryInitializer { public void Initialize(ITelemetry telemetry) { if (!(telemetry is DependencyTelemetry dependency)) { return; } HttpRequestMessage requestMessage = null; HttpRequestHeaders requestHeaders; if (dependency.TryGetOperationDetail(\u0026#34;HttpRequest\u0026#34;, out var details) \u0026amp;\u0026amp; details is HttpRequestMessage request) { requestMessage = request; requestHeaders = request.Headers; if (requestMessage.Method == HttpMethod.Post) { string contentBody = requestMessage.Content.ReadAsStringAsync().GetAwaiter().GetResult(); dependency.Properties.Add(\u0026#34;RequestBody\u0026#34;,contentBody); } } else if (dependency.TryGetOperationDetail(\u0026#34;HttpRequestHeaders\u0026#34;, out details) \u0026amp;\u0026amp; details is HttpRequestHeaders headers) { requestHeaders = headers; } else { return; } foreach (KeyValuePair\u0026lt;string,IEnumerable\u0026lt;string\u0026gt;\u0026gt; header in requestHeaders) { foreach (string value in header.Value) { dependency.Properties.Add(header.Key, value); } } //この実装の場合は出力されなかった。なぜ? // if (requestMessage != null \u0026amp;\u0026amp; requestMessage.Method == HttpMethod.Post) // { // string contentBody = requestMessage.Content.ReadAsStringAsync().GetAwaiter().GetResult(); // dependency.Properties.Add(\u0026#34;RequestBody\u0026#34;,contentBody); // } } } } メリット、デメリット すでにApplication Insightsを利用している場合はついでに情報が出力されるので便利です。かつ、常にリクエストログを見れるようにしておく場合はとても便利だと思います。\nApplication Insightsを利用していない場合は、そこから導入しなければならなくなるので、手間が増えるかもしれないです。\n4. Azure Cognitive Searchのコンソールにある診断情報の機能を利用する。 最後はAzure Cognitive Searchの診断ログを有効にする方法です。 ここまで説明してきた方法の中で、一番お手軽な方法です。。。\nこれまでは、リクエストボディを出力する方法を考えていましたが、Azure Cognitive Search側の診断ログを有効にすると、リクエストボディで送信したものが、Azure Cognitive Search側で、クエリパラーメータとして、診断ログに出力されます(診断ログのQuery_s)。\nあとは、Azureのコンソールで当該時間のログを見ればよいだけです。以下は出力されたログの一部です。Description_sにはURLのパスが記載されています。\n診断ログ例(一部)\nDescription_s POST /indexes(\u0026#39;multi-field-test\u0026#39;)/docs/search.post.search Query_s ?api-version=2019-05-06\u0026amp;searchMode=Any\u0026amp;search=azure\u0026amp;queryType=Simple\u0026amp;$count=false メリット、デメリット アプリケーション側に手を入れる必要がなのでお手軽です。 一度設定しておけばコンソール側でログをいつでも見れるので便利です。\nリクエスト量が多くなってしまうと、ログの量も多くなり、費用がかさむ恐れがあります。また、複数の人が触る環境の場合は自分で送信したリクエストがどれだったのか?といった状況に陥る可能性はあります。\nその他は? Azureに対してではないですが、昔似たようなことをやるときにやっていた方法として、ローカルにプロキシサーバーを起動し、そのプロキシサーバー経由でアプリケーションから、Azureに接続することで、リクエストを保存する方法もあります。 ざんねんながら、未調査ですがアプリなどにはそれほど手を入れる必要はないかと思います。\nまとめ ちょっと送信リクエストの内容が見てみたいという話でしたが、いろいろな手段が存在しました。 自分の状況、環境に合わせて手段を選択肢てみるのがいいかと思います。 まずは、簡単な診断ログあたりからでしょうか?\n","date":1590481367,"dir":"post/2020/","id":"36dd94159e3e60076c0c6098086e255f","lang":"ja","lastmod":1590481367,"permalink":"https://blog.johtani.info/blog/2020/05/26/logging-azure-search-request/","publishdate":"2020-05-26T17:22:47+09:00","summary":"今回はAzure Cognitive SearchのSDKを利用したアプリケーションが、実際にAzure Cognitive Searchに対して送信しているリクエストのパラメータ","tags":["azure search",".net"],"title":"Azure Cognitive Searchのリクエストのロギング"},{"contents":"Mircosoft Buildというイベントが今週ありました(MSの方やお客さんに教えてもらった)。\nそこで、Azure Cognitive Searchのセッション(MyBuild - Cognitive Search： The pocket-knife for knowledge mining)があったので、見てみました。 内容がどんなものかをメモっておきます。 最初はCognitive Searchがどんなものよという説明でした。\nビルトインスキルの拡充の話 データソースからデータを取り出し、エンリッチし、検索エンジンに保存するという、パイプラインが組めるようになっています。\nこのパイプラインで利用できる処理のことがスキルと呼ばれています。ここで利用できるビルトインスキルが拡充されますよという話でした。ちょっとだけ抜き出すと以下のとおりです。\nAzure Machine Learning Text translation Brand detection Object detection スキルのリファレンスには載ってるものと載ってないものがあるので、今後追加されてくのかな? Brand detectionがどんなものなんだろう?ってのがちょっと気になりました。どっかにデモとかあるかなぁ?\nスキルセットのための新機能 : Debug Sessionのデモ 上記のスキルを組み合わせてパイプラインを組んで、データソースから取り出したデータをエンリッチしてから、検索エンジンに入れる処理をかけるのですが、その処理のデバッグ用に新しいGUIの機能が追加されてますよという紹介とデモでした。\nTutorial： Use Debug sessions to diagnose, fix, and commit changes to your skillset - Azure Cognitive Search | Microsoft Docs Manage Identityの話 Azure Cognitive Searchにデータを登録するパイプランの最初の段階で、各種データソースにアクセスが必要です。 このアクセス時にコネクションの設定にアカウントキーなども含めてましたが、これをコネクション設定ではなく、専用の管理機能が用意されましたよという話でした。\nSet up a connection to a data source using a managed identity (preview) - Azure Cognitive Search | Microsoft Docs QA Similarityとかの話 BM25になってるよとか SDKの話とか ほかにRelevancyの話 Analyzerをデフォルトのままじゃなくてちゃんと考えて使いましょう(例:各言語用のAnalyzerがいっぱいあるよとか) こんな感じでした。\n","date":1590117041,"dir":"post/2020/","id":"21982f43bc435f22efef22b309a48c66","lang":"ja","lastmod":1590117041,"permalink":"https://blog.johtani.info/blog/2020/05/22/watching-azure-cognirive-search-session-at-ms-build/","publishdate":"2020-05-22T12:10:41+09:00","summary":"Mircosoft Buildというイベントが今週ありました(MSの方やお客さんに教えてもらった)。 そこで、Azure Cognitive Searchのセッション(MyBuil","tags":["azure search"],"title":"Microsoft Build(2020)のAzure Cognirive Searchのセッションを見たのでメモ"},{"contents":"ElasticのWorkplace Searchを触ってみています(その1、その2)が、Elastic Stackの7.7.0がリリースされてしまいました。\n簡単ですが、リリースブログを見ながら気になった点をメモしとこうかと。\n本家のリリースブログ いっぱいあるんですよ、これが。まぁ、内容かぶってるのもあるんですが。\nElastic Stack Elastic Stack 7.7.0をリリース Elasticsearch 7.7.0 released Kibana 7.7.0 released Logstash 7.7.0 released Enterprise Search系 Elastic Enterprise Search 7.7 released, featuring Workplace Search GA | Elastic Blog Elastic App Search updates： Scale your way with new configuration options | Elastic Blog Elastic Workplace Search： 新しい、統合された働き方へ Observability系 Elastic Observability 7.7 released | Elastic Blog\nElastic APM 7.7.0 released with service maps, async profiler, and more | Elastic Blog\nElastic Logs 7.7.0 released with PCF support, MQTT support, and more | Elastic Blog\nElastic Metrics 7.7.0 released with enhanced Prometheus integration and PCF support, | Elastic Blog\nElastic Uptime Monitoring 7.7.0 released with alerting, anomaly detection and more | Elastic Blog\nNew alerting framework released for Observability, Security and the Elastic Stack | Elastic Blog\nIntroducing Elastic Security 7.7.0 | Elastic Blog\n個人的に気になったもの で、全部読んだわけではないのですが、個人的に気になった機能についてメモを残しておきます。 多分に検索によっている可能性がありますが、お気になさらず。 また、ブログとドキュメントを元に気になるところをピックアップしてます。 実際の実装とか動作に関してはまだ未調査の段階です。\nAsync Search - Elasticsearch ElasticsearchのAPIとして非同期に検索できるAPIが実装されました (公式リファレンス)。 大量データを検索が終了してから検索結果を返すのではなく、クエリは実行しつつわかったところまでは都度取得したいという要望だったり、Coldインデックスのように遅いストレージ上にあるデータへの検索でも少しずつ取得できるようにという具合だと思います。ログとか大量に扱う場合にまぁ、ほしいですよね。今回はEsのリリースがメインで、今後はKibanaなどとの連携だったり色々改善していくよという話みたいです(Kibanaの一部の機能は利用しているみたい)。\nライセンスとサブスクリプションのレベル Elastic License Basic 気になるところ(と、予想とか) 仕組みがどうなっているか? Search APIと同等のリクエストパラメータが使える。が、いくつか制約はありそう おそらくTask Manageerで検索してる処理が管理され、レスポンスにはIDが発行されて、そのIDで処理の進み具合を取得する感じ。 Shard単位?Segment単位? 内部的にはShard単位で検索処理を扱ってるので、Shard単位がとりあえず楽そう? Aggsとかも? 対象の模様 Sortは? 有効。ソートのフィールドがインデックス対象だった場合は、そのデータの統計値を使ってShardをソートするっぽい(公式リファレンスのNOTE参照) 関連しそうなGitHubのIssuesとか まだ読んでない\nAsync search · Issue #49091 · elastic/elasticsearch Add a listener to track the progress of a search request locally by jimczi · Pull Request #49471 · elastic/elasticsearch Pre-sort shards based on the max/min value of the primary sort field by jimczi · Pull Request #49092 · elastic/elasticsearch Async search： store intermediate results · Issue #55464 · elastic/elasticsearch Reduced consumption of heap - Elasticsearch ヒープの使用量が7.7で減ってるよというブログも別途ありました。\n元になっているLuceneの実装に関するIssueが「［LUCENE-8635］ Lazy loading Lucene FST offheap using mmap - ASF JIRA」です。ヒープ上に展開していたデータをmmapで扱えるようにすることで、ヒープのメモリを削減してる。\nで関連して、これがLuceneで操作できるようになって(「Use reader attributes to control term dict memory useage by s1monw · Pull Request #42838 · elastic/elasticsearch」)、そこからEsに取り込まれたと。\n_idをoff-heapにする話は[ここ](Move the terms index of _id off-heap. by jpountz · Pull Request #52405 · elastic/elasticsearch)にあった。\nこれに関連して、ヒープサイズの推奨について再考が必要かも?というIssue(Reconsider our recommendations for heap size? · Issue #52561 · elastic/elasticsearch)も上がってる。\nPainless Lab - Kibana ほんとにPainless?と言う話はさておき、_script APIでexecuteはできていましたが、やはりもう少し楽に実行したいですよね?ということで画面ができたみたいです。\nシンタックスハイライトとかもできるので、より簡単に使えるようになってますね。 まだ、ベータなので足りないContextとかもあるっぽいけど。\nライセンスとサブスクリプションのレベル Elastic License Basic? まだベータだからか、サブスクリプションのページにはなかった。 公式ドキュメントとGitHubのリポジトリから、Elastic Licenseであることは判明。\n気になるところ(と、予想とか?) 制限事項がどんなものか? 使えるContextがまだ少ない?まだGAではない サジェストがどのくらい効くのか? シンタックスハイライトはあるけど。まだかなぁ? その他Elasticsearch関連 7.7リリースのハイライトが別途用意されています。\n7.7.0 release highlights | Elasticsearch Reference ［7.7］ | Elastic こっちで気になるのは、ClassificationとかTransformsあたりかなぁ。ML関連の機能で。\nWorkplace Search GA これは別のブログに書くかな。\n気になるところ Betaと何が変わったのか? APIとかどういう形で提供されるのか?そもそも提供されるのか? どんな機能?みたいなのも書く予定です。\nData VisualizerでFilebeatのConfigをサジェスト - Kibana and Filebeat Kibanaの画面からデータをちょっと?(100MB)だけアップロードして、Elasticsearchにサクッとデータ登録できる機能が実はあります。この機能の拡張として、Filebeatの設定だとこんな感じに作れるよ?というのを提示してくれるようになったみたいです。 手元にあるファイルを定期的に読み込むときに、設定を書く下地ができるのは便利じゃないかな?\nライセンスとサブスクリプションのレベル Elastic License Basic Data Visualizerってどんなもの?というのはここにブログがあります。残念ながらKibanaとかの公式リファレンスには使い方のページがないんだよなぁ。\nAPMのサービスマップ - APM and Kibana アプリケーションアーキテクチャのどこでAPMが動作しているか、どこと通信しているかという、APMのエージェントが入っているアプリ間のつながりをKibana上で可視化できる機能っぽいです。まだ、ベータみたいですが、面白そう。Azure Application Insightのアプリケーションマップに似てる気がします。\nライセンスとサブスクリプションのレベル Elastic License Platinum 気になるところ どうやって作ってる(つながりをどうやて判断してる)のか? 分散トレーシングのデータを元に誰がどこと通信してるってのは取れるんじゃなかろうか? Log categorization and contextual examples - Kibana and Elasticsearch 7.6から入ってたっぽいですが、ログの分類をMLの機能を使ってできるものが、LogsのUIとかでさらに使いやすくなった模様。\nライセンスとサブスクリプションのレベル Elastic License Platinum 気になるところ 7.6の機能から追いかけないとなぁ。。。 似たようなログをカテゴリーごとに分析できるようになるので、プラスMLの仕組みでこれまでとは異なる種類のログが出始めたみたいなことが分析できそう。 まとめ 眺めるだけで時間かかりましたが、まぁ、相変わらずいっぱいありますね。 興味のあるところの濃淡が出た感じになりましたが、気になる点をピックアップしてみました。 おかしなところとか、ここはどういう意味?などあればツッコミお願いします。\n","date":1589509037,"dir":"post/2020/","id":"306cecb32320ead508346ad8fed3394d","lang":"ja","lastmod":1589509037,"permalink":"https://blog.johtani.info/blog/2020/05/15/elastic-stack-7_7/","publishdate":"2020-05-15T11:17:17+09:00","summary":"ElasticのWorkplace Searchを触ってみています(その1、その2)が、Elastic Stackの7.7.0がリリースされてし","tags":["elastic stack"],"title":"Elastic Stack 7.7がリリースされた"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章 第9章 エラー処理です。 NLP100とか、いくつかのプログラムを書いていて、なんとなくは扱っていますが、きちんと勉強しないと。\nとりあえず、「Rustには例外は存在しません。」が一番知っておくことかな。\npanic!で回復不能なエラー panic!マクロでスタックを巻き戻して掃除をして終了。 異常終了(panic = 'abort')にもできる。 「RUST_BACKTRACEを0以外の変数にセットして実行」 * Resultで回復可能なエラー expect()は気持ち悪い名前じゃないかなぁ? ここでio::Errorではないものもエラーが発生する場合には panic!すべきかするまいか まとめ 「Rustには例外は存在しない」ので、回復不能か可能かを考えつつ処理を書こうと。\n","date":1589449406,"dir":"post/2020/","id":"1e220a934e16fd941bd804ca03865b60","lang":"ja","lastmod":1589449406,"permalink":"https://blog.johtani.info/blog/2020/05/14/chap9-rust-the-book/","publishdate":"2020-05-14T18:43:26+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第9章"},{"contents":"Rustで言語処理100本ノックの第2章の残りです。\n前回はこちら。\nちなみに、標準入力から受け取る処理は書いてないです。 出力に関してはファイル分割、保存と支持があるもの以外は文字列として取り出すところで終わっています。\n12. 1列目をcol1.txtに，2列目をcol2.txtに保存 pub fn extract_column(input_file_name: \u0026amp;str, num: usize, output_file_name: \u0026amp;str) { let input_f = File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;); let read_buf = BufReader::new(input_f); let mut output_f = OpenOptions::new() .write(true) .create(true) .open(output_file_name) .expect(format!(\u0026#34;can\u0026#39;t open file[{}] with write option\u0026#34;, output_file_name).as_str()); read_buf.lines().for_each(|line| match line { Ok(line) =\u0026gt; { let columns: Vec\u0026lt;_\u0026gt; = line.split(\u0026#39;\\t\u0026#39;).collect(); writeln!(output_f, \u0026#34;{}\u0026#34;, columns[num]); output_f.flush().expect(\u0026#34;Error during flush\u0026#34;); } Err(_) =\u0026gt; panic!(\u0026#34;parse error \u0026#34;), }); } 13で出力結果を利用するので入力として出力ファイル名も受け取るようにしました。 問題としては、1列目と2列目を別々に出力すればいいので、1回の処理で書いても良かったのですが、1回1ファイルの出力という形で実装しました(効率は悪い)。\n改行コードあたりを考えるのがめんどくさかったのでwriteln!マクロでファイルに書き出しています。が、普通にwriteメソッドで改行コードを追加しても良かったのかなと。\nあとは、出力先ファイルが存在しない場合だけopenするようにOpenOptionsを利用してみています。\nflushを呼び出すべきなのかどうか?を調べないとな。。。\n13. col1.txtとcol2.txtをマージ pub fn merge_files(col1_file: \u0026amp;str, col2_file: \u0026amp;str, output_file_name: \u0026amp;str) { let col1_buf = BufReader::new(File::open(col1_file).expect(\u0026#34;file not found\u0026#34;)); let col2_buf = BufReader::new(File::open(col2_file).expect(\u0026#34;file not found\u0026#34;)); let mut output_f = OpenOptions::new() .write(true) .create(true) .open(output_file_name) .expect(format!(\u0026#34;can\u0026#39;t open file[{}] with write option\u0026#34;, output_file_name).as_str()); col1_buf .lines() .zip(col2_buf.lines()) .for_each(|(col1, col2)| { let col1 = col1.expect(\u0026#34;parse error col1\u0026#34;); let col2 = col2.expect(\u0026#34;parse error col2\u0026#34;); writeln!(output_f, \u0026#34;{}\\t{}\u0026#34;, col1, col2); output_f.flush().expect(\u0026#34;Error during flush\u0026#34;); }); } 2つのファイル名を入力として受け取り、タブでくっつけて出力します。 zipを利用することで、2つのイテレーターを同時に回しています。\n14. 先頭からN行を出力 pub fn head(input_file_name: \u0026amp;str, lines: usize) -\u0026gt; String { let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); let mut head = String::new(); buf.lines().take(lines).for_each(|line| { head.push_str(format!(\u0026#34;{}\\n\u0026#34;, line.expect(\u0026#34;parse error\u0026#34;)).as_str()); }); return head; } イテレーターのメソッドにtakeがあります。 これを利用することで、引数に指定した数のエレメントが取得できるので、これでheadが実現できます。\n15. 末尾のN行を出力 pub fn tail(input_file_name: \u0026amp;str, lines: usize) -\u0026gt; String { let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); let mut tail = String::new(); let line_count = word_count(input_file_name); buf.lines().skip(line_count - lines).for_each(|line| { tail.push_str(format!(\u0026#34;{}\\n\u0026#34;, line.expect(\u0026#34;parse error\u0026#34;)).as_str()); }); return tail; } tailの場合は少し複雑で、11で作成した行数をカウントするメソッドで総行数を取り出し、そこから引数で指定された行数を引き算した数(=出力しない行数)を、イテレーターのskipメソッドの引数に渡しています。これにより、指定された数のエレメントをスキップしたあとの処理がかけます。\n16. ファイルをN分割する pub fn split_files( input_file_name: \u0026amp;str, num: usize, output_file_prefix: \u0026amp;str, output_file_suffix: \u0026amp;str, ) { let total = word_count(input_file_name) as f64; let lines_in_file = total / num as f64; let lines_in_file = lines_in_file.ceil() as usize; // let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); let output_files: Vec\u0026lt;File\u0026gt; = create_file_vec(output_file_prefix, num, output_file_suffix); println!(\u0026#34;split file each {} lines.\u0026#34;, lines_in_file); let mut lines = buf.lines(); for mut output_f in output_files { let mut current = 1; while current \u0026lt; lines_in_file + 1 { let line = lines.next(); if let Some(line_rs) = line { if let Ok(line_str) = line_rs { writeln!(output_f, \u0026#34;{}\u0026#34;, line_str); } } current = current + 1; } output_f.flush().expect(\u0026#34;error during flush\u0026#34;); } } fn create_file_vec(output_file_prefix: \u0026amp;str, num: usize, output_file_suffix: \u0026amp;str) -\u0026gt; Vec\u0026lt;File\u0026gt; { let mut files = Vec::with_capacity(num); for i in 0..num { let output_file_name = format!(\u0026#34;{}{}{}\u0026#34;, output_file_prefix, i + 1, output_file_suffix); let output_f = OpenOptions::new() .write(true) .create(true) .open(output_file_name.as_str()) .expect(format!(\u0026#34;can\u0026#39;t open file[{}] with write option\u0026#34;, output_file_name).as_str()); files.push(output_f); } return files; } ちょっと長いですね。\n入力としては、分割するファイル数Nが指定されます。まずは、総行数/Nで各ファイルに保存されるべき行数を計算します。 次に、2つ目の関数をつかって、必要な数のファイルオブジェクトをベクトルとして生成します。\nファイルオブジェクトのベクトルの要素を元にしたfor文を回しつつ、それぞれのファイルに必要な行数を出力している処理になっています。\n総行数がNで割り切れない場合にceilで切り上げした行数にするというちょっとした処理を入れてあります。\n17. １列目の文字列の異なり pub fn count_uniq_words(input_file_name: \u0026amp;str, col: usize) -\u0026gt; usize { let mut words = HashSet::new(); let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); buf.lines().for_each(|line| match line { Ok(line_str) =\u0026gt; { let columns: Vec\u0026lt;_\u0026gt; = line_str.split(\u0026#39;\\t\u0026#39;).collect(); words.insert(columns[col].to_string()); } Err(_) =\u0026gt; panic!(\u0026#34;parse error \u0026#34;), }); return words.len(); } HashSetを利用することでユニーク性を担保して、最後はHashSetの数を数え上げれば終了です。\n18. 各行を3コラム目の数値の降順にソート pub fn sort_on_col3(input_file_name: \u0026amp;str) -\u0026gt; String { let mut lines: BTreeSet\u0026lt;Line\u0026gt; = BTreeSet::new(); let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); buf.lines().for_each(|line| match line { Ok(line_str) =\u0026gt; { let columns: Vec\u0026lt;_\u0026gt; = line_str.split(\u0026#39;\\t\u0026#39;).collect(); let num: u32 = columns[2].parse().expect(\u0026#34;parse error\u0026#34;); let line = Line { line: line_str, num, }; lines.insert(line); } Err(_) =\u0026gt; panic!(\u0026#34;parse error\u0026#34;), }); let mut sorted = String::new(); lines.iter().for_each(|line| { sorted.push_str(format!(\u0026#34;{}\\n\u0026#34;, line.line).as_str()); }); return sorted; } #[derive(Eq)] struct Line { line: String, num: u32, } impl Ord for Line { fn cmp(\u0026amp;self, other: \u0026amp;Self) -\u0026gt; Ordering { let ord = other.num.cmp(\u0026amp;self.num); if let Ordering::Equal = ord { other.line.cmp(\u0026amp;self.line) } else { ord } } } impl PartialOrd for Line { fn partial_cmp(\u0026amp;self, other: \u0026amp;Self) -\u0026gt; Option\u0026lt;Ordering\u0026gt; { Some(self.cmp(other)) } } impl PartialEq for Line { fn eq(\u0026amp;self, other: \u0026amp;Self) -\u0026gt; bool { self.eq(other) } } Lineという、行の文章と第3カラム目の値をもった構造体を作成しました。そこにEq、Ord、PartialOrd、PartialEqを実装し、3カラム目での大小比較できるようにしました。 この構造体をBTeeSetに格納していき、イテレーターで回すことで、ソートされた状態にしてあります。 同一数値の場合は行の降順でソートできるようにOrdを実装してあります。\n19. 各行の1コラム目の文字列の出現頻度を求め，出現頻度の高い順に並べる pub fn sort_on_frequency(input_file_name: \u0026amp;str) -\u0026gt; String { let mut names: HashMap\u0026lt;String, u32\u0026gt; = HashMap::new(); let buf = BufReader::new(File::open(input_file_name).expect(\u0026#34;file not found\u0026#34;)); buf.lines().for_each(|line| match line { Ok(line_str) =\u0026gt; { let columns: Vec\u0026lt;_\u0026gt; = line_str.split(\u0026#39;\\t\u0026#39;).collect(); let name_str = columns[0].to_string(); let count = names.entry(name_str).or_insert(0); *count += 1; } Err(_) =\u0026gt; panic!(\u0026#34;parse error\u0026#34;), }); let mut sorted = String::new(); let mut sorted_names: Vec\u0026lt;(\u0026amp;String, \u0026amp;u32)\u0026gt; = names.iter().collect(); sorted_names.sort_by(|(aname, acount), (bname, bcount)| { let ord = bcount.cmp(acount); if let Ordering::Equal = ord { bname.cmp(aname) } else { ord } }); sorted_names.iter().for_each(|(name, count)| { sorted.push_str(format!(\u0026#34;{} {}\\n\u0026#34;, count, name).as_str()); }); return sorted; } もうすこしうまくできる気がしますが、いったんこれで。 数え上げのためにまずはHashMapに第1カラムの文字列, 個数という組み合わせでデータを入れていきます。 出来上がったHashMapをタプルのベクターに変換し、変換したベクターのsort_byメソッドに比較用の関数を渡すことで個数の降順に並べています。同一個数の場合は文字列の降順になっています。 で、最後に並びかわったベクターのイテレーターを使って出力しておしまいです。 内部的には最悪3回回る感じでしょうか? 最初からベクトルに入れつつソートできる仕組みにするようなのがいいのかなぁ?\nまとめ Unixコマンドの勉強になりましたw あとは、HashMapなどの勉強にもなりました。 最後の方は効率がいまいち良くない気もしてはいますが、とりあえず第3章に進もうかと思います。\n","date":1589253809,"dir":"post/2020/","id":"09155bf417a93847b538ad607f78cca2","lang":"ja","lastmod":1589253809,"permalink":"https://blog.johtani.info/blog/2020/05/12/reboot-nlp100-ch02-12to19/","publishdate":"2020-05-12T12:23:29+09:00","summary":"Rustで言語処理100本ノックの第2章の残りです。 前回はこちら。 ちなみに、標準入力から受け取る処理は書いてないです。 出力に関してはファイル","tags":["Rust","nlp100"],"title":"第2章の12から19まで(言語処理100本ノック2020)"},{"contents":"気づいたら1ヶ月サボってました、ごめんなさい。。。\nRustで言語処理100本ノックの第2章をはじめました。\n前回はこちら。\n確認用のUnixコマンド 確認用のファイルを先に生成して置きました。 これで、Rustでコードを書いて、作成済みの確認ファイルを元にassert_eq!でチェックするという方式を取ろうかと。\nで、コマンド群はこちらです。\nUnix/Linuxコマンド、昔から使っています。が、なにかちょっとした文字列処理やファイル処理をやるときは、Javaのプログラム(最近だとPython)を書くというのが基本になってるので、結構、使ったことの無いコマンドが今回ありました。使ったことがなかったのはこちらです。\nsed tr expand paste cut split sedとかは普通さわってるだろ?って思われそうですね。。。\nで、コマンドをmanで調べつつやりました、macOS上で。 これがまたいくつか罠があったので書き残しておきます(自分が知らないだけかもしれないので、おかしいところがあったらツッコミお願いします。)。\nsedコマンドでのタブの扱い ## sed command for macOS. If using Linux, use \u0026#34;\\t\u0026#34; for tab character cat $INPUT_FILE_NAME | sed -e \u0026#39;s/\t/ /g\u0026#39; \u0026gt; $OUTPUT_DIR/11_sed.txt \\tで行けると思ったのですが、うまく動きませんでした。\u0026lt;tab\u0026gt;みたいな書き方もあると思うのですが、これも駄目で、結局タブ文字をそのまま打ち込みました。。。 これ、めんどくさくないですか??? ちなみに、ターミナルで動作確認して、GitHubにあげてあるシェルファイルにコピペしてたのですが、CLionに貼り付けたらタブ文字がスペースに変換されてしまってて20分くらい悩みました。。。\nsplitコマンドに-nオプションがない LINES=`cat $OUTPUT_DIR/10.txt` SPLIT_LINES=`echo $LINES/$N | bc` split -a 1 -l $SPLIT_LINES $INPUT_FILE_NAME $OUTPUT_DIR/16_ splitコマンドについてググると、-nで指定した数のファイルに分割できるという記事がいくつも出てくるのですが、man splitをターミナル上でやるとそんなオプションがないと。。。 macOSがBSD系だからっぽいです。 ということで、行数を元に、指定した数(N)で行数を割ってから、指定行数ごとにファイルを分割する方式にしました。\nこれらのコマンドの違いはHomebrewとかでインストールするとなくなるのかなぁ?(めんどくさいので確認してないですが。。。)\nってことで、2章のそれぞれの課題の正解ファイルの生成はこれでできたはずです。\n10. 行数のカウント wc -lですね。\n// ch02-10 行数のカウント pub fn word_count(file_name: \u0026amp;str) -\u0026gt; usize { let f = File::open(file_name).expect(\u0026#34;file not found\u0026#34;); let buf = BufReader::new(f); return buf.lines().count(); } ファイルを読み込んで行数を数えます。 文字列として読み込んで改行コードの数を数えるというのもありかな?と思いましたが、RustのBufReaderにlines()という行のイテレータ?が取れることがわかったので、それでカウントを取りました。\n11. タブをスペースに置換 // ch02-11 タブをスペースに置換 pub fn tab_2_space(file_name: \u0026amp;str) -\u0026gt; String { let mut f = File::open(file_name).expect(\u0026#34;file not found\u0026#34;); let mut contents= String::new(); f.read_to_string(\u0026amp;mut contents).expect(\u0026#34;read error\u0026#34;); return contents.replace(\u0026#34;\\t\u0026#34;, \u0026#34; \u0026#34;); } こっちはファイル全体を文字列に読み込んでしまってから、文字列のreplaceで置換するという方式です。 ファイルが大きい場合にこれでいいのか?という問題がある気がしますが、まずはこの実装にしました。 やるとしたら、readメソッドとbufferを用意して、少しずつ読みながら、置換して吐き出す感じでしょうか? ちゃんとした文字コードの区切りで取れるかどうかを気にしないと行けないと思うので、思ったよりはめんどくさくなりそう。\nBufReaderをつかってread_lineのほうがましかも?\nまとめ ということで、サボっていたのを再開しました。 Rustのコードを書く前に、Unixコマンドの処理に結構悩みましたw\nRustのコードとしてはファイル処理なので、今後も役立つ気がしてます。 ということで、頑張っていくぞと。\n","date":1588948640,"dir":"post/2020/","id":"c098c6f0901979bd914ed7a345200f90","lang":"ja","lastmod":1588948640,"permalink":"https://blog.johtani.info/blog/2020/05/08/rebootnlp100-ch02-10to11/","publishdate":"2020-05-08T23:37:20+09:00","summary":"気づいたら1ヶ月サボってました、ごめんなさい。。。 Rustで言語処理100本ノックの第2章をはじめました。 前回はこちら。 確認用のUnixコマ","tags":["Rust","nlp100"],"title":"第2章の10から11まで(言語処理100本ノック2020)"},{"contents":"Rustで言語処理100本ノックのリファクタリングの続き。\n前回はこちら。\nとっくに終わってたのに、ブログ書いてなかった。。。\n08. 暗号文 pub fn cipher(text: \u0026amp;str) -\u0026gt; String { return String::from_iter(text.chars().map(|x| { if x.is_ascii_alphanumeric() \u0026amp;\u0026amp; x.is_lowercase() { let mut b = [0; 4]; x.encode_utf8(\u0026amp;mut b); b[0] = 219 - b[0]; char::from(b[0]) } else { x } })); } Rustの文字列はUTF-8でエンコードされたテキストを保持しているので、文字コード自体は意識していないです。 chars()でUnicodeスカラー値のイテレータが返ってくるので、1文字ずつ扱えるようになります。\nただ、1文字をバイトとして扱うのに手こずりました。 encode_utf8というメソッドを利用して1バイトだけ取り出して、計算するというのをやっています。 文字種の判別のメソッドが用意されているのは便利ですね。\nなんかもうちょっとスマートにできないのかな?と思いつつ動いたのでこれになってます。\n09. Typoglycemia pub fn typoglycemia(text: \u0026amp;str) -\u0026gt; String { return text .split_whitespace() .map(|word| { if word.len() \u0026lt;= 4 { word.to_string() } else { let original = word.chars().collect::\u0026lt;Vec\u0026lt;char\u0026gt;\u0026gt;(); let first = original.get(0).unwrap(); let last = original.last().unwrap(); let mut typo = original[1..original.len() - 1] .iter() .map(|x| x.clone()) .collect::\u0026lt;Vec\u0026lt;char\u0026gt;\u0026gt;(); let mut rng = thread_rng(); typo.shuffle(\u0026amp;mut rng); let mut typo = String::from_iter(typo.iter()); typo.insert(0, first.clone()); typo.push(last.clone()); typo } }) .collect::\u0026lt;Vec\u0026lt;String\u0026gt;\u0026gt;() .join(\u0026#34; \u0026#34;); } 一応、1行で記述できたかな? まずは、スペースで単語ごとに区切った後に、word(単語)の長さによって、処理を分岐し、単語が5文字以上の場合にランダムに並び替えを行うというのをやっています。 文字単位で処理を行うために、chars()で1文字ずつ取り出しています。 最初と最後の文字だけはそのままに、間の文字をランダムにシャッフルするというのをやるのに、もとのwordのスライスからコピーした文字列を作り出してから組み立て直すということをやっています。\nコピーしないでゴニョゴニョする方法ってあるのかなぁ? 思いつかなかったので、結構泥臭い感じの実装になってしまいました。\nまとめ めんどくさいので、コードをGitHubのソースコードからではなく、ブログにコードスニペットとしてコピペしました。Hugoでいい感じにGitHubのコードスニペット表示するのないかなぁ?\nということで、2年越しで1章が終了しました。 2章もやらないとなぁ。\n","date":1588923657,"dir":"post/2020/","id":"2c3270f8797ace2fb37402ea6a09d126","lang":"ja","lastmod":1588923657,"permalink":"https://blog.johtani.info/blog/2020/05/08/reboot-nlp100-finish-ch01/","publishdate":"2020-05-08T16:40:57+09:00","summary":"Rustで言語処理100本ノックのリファクタリングの続き。 前回はこちら。 とっくに終わってたのに、ブログ書いてなかった。。。 08. 暗号文 pub fn cipher(text: \u0026amp;str) -\u0026gt;","tags":["Rust","nlp100"],"title":"第1章の08から09まで(言語処理100本ノック2020)"},{"contents":"前回はWorkplace Searchの概要について書きましたが、今回はインストールと構成要素について説明します。なお、2020/5/7時点での情報を元に本記事は書いていますのでご注意ください。基本的にはインストールと起動方法についての手順を元に書いています。所々に考察を挟んだ形の記事になっていますので、気になるところだけ呼んでいただければと。\n記事一覧 ElasticのWorkplace Searchを触ってみる - その1 インストール インストール方法は公式リファレンスもしくはダウンロードページに記載があります。 現時点ではMacもしくはLinuxが対象でWindowsはまだサポート対象外となっています。\n必要なもの インストールに必要なものは以下になります。\nElasticsearch 7.6.x + Platinum license Elastic CloudのElasticsearch Service もしくは ダウンロードしてローカルで起動 enterprise-search-7.6.0.tar.gz ダウンロードページはこちら Java 8もしくは11 Long Term Supportの対象であるJavaです。2020/5/7時点では8か11 今回はローカルにElasticsearchの7.6.2をインストールしてから試してみます。30日間のトライアルライセンスが有効になっているので、Platinumの機能を試すことができます。\nJavaの8か11が必要になります。Elasticsearchには7.xからJDKが同梱されるようになりましたが、Workplace SearchがJettyを元に動作しているからです(enterprise-search-7.6.0.tar.gzにjettyというフォルダあり)。\nインストール手順 大まかには以下の3つです。\nJava 8もしくは11のインストール 14でも大丈夫でした(ローカルにはSDKMANでインストールした14.0.1が利用された)。 Elasticsearchのインストール(Elastic Cloudの場合はクラスタの起動) 今回はローカルにインストール Workplace Searchのインストール Javaはもともとインストールされていたので、今回は2と3をインストールしました。どちらもローカルで起動するので、2つをダウンロードしてtar.gzファイルを展開するだけになります。\n起動方法と設定 起動方法に起動前の設定の手順も記載があります。 設定しながら起動していきます。\nElasticsearchの起動 既存のElasticsearchのクラスターがあり、Platinumのライセンスが有効になっている場合はこの手順は必要ありません。\nElasticsearchの設定ファイルでSecurity機能をオンに 7.1から基本的なセキュリティ機能はベーシックの機能に含まれています。 Elasticsearchを起動 まずは起動(パスワードなどを設定するために必要) Elasticsearchのパスワードの設定 Elasticsearchでデフォルトで用意されているユーザーのパスワードを設定してします。手順では自動で生成させる方法ですが、独自に設定することも可能です。 Workplace Searchの起動 Elasticsearchが起動したらWorkplace Searchの設定をして起動します。\nEsへの接続設定をconfig/enterprise-search.ymlに指定 Esのパスワード設定時に生成されたelasticというユーザーのパスワードをここで指定。 yamlファイルに記載があるが、${ELASTICSEARCH_PASSWORD:changeme}という記述をした場合に環境変数を読み込める allow_es_settings_modification: trueをconfig/enterprise-search.yml ここに記載があるような変更をWorkplace SearchがEsのクラスターに対して実行する模様。Workplace Search以外でも使用しているElasticsearchクラスターの場合はallow_es_settings_modificationを有効にする代わりに、リンク先にあるような設定を自分で追加する。 secret_management.encryption_keysを複数設定 Encryption Keysのガイドに少し詳しい説明がある。 opensslコマンドとかで作ればいいかな?? 1.と同じような設定をしようとしたがうまくいかなかったので、ファイルにキーを設定する方式にしました(バグ?) 起動するときにデフォルトユーザーパスワードを指定 指定しなければ勝手に生成してコンソールに出力してくれるので、そちらの方がいいかと。 今回は手順通りに指定した。 起動確認のためhttp://localhost:3002にアクセス 起動するとログが流れ、問題がなければ次のようにデフォルトユーザーの情報が出力されます。\n######################################################### *** Default user credentials have been setup. These are only printed once, so please ensure they are recorded. *** username: enterprise_search password: pas...ple ######################################################### そして無事起動に成功したことも出力されます。\n######################################################### Success! Elastic Workplace Search is starting successfully. In a few moments, you\u0026#39;ll be able to login at the following address: * URL: http://localhost:3002 * If this is your first time starting Workplace Search, check the console output above for your user authentication credentials. * Visit the documentation: https://swiftype.com/documentation/enterprise-search Secret session key has been generated. Set the key in your config file to persist user sessions through process restarts: secret_session_key: c23...3 ######################################################### ブラウザで画面にアクセスすると、次のような画面が表示されました。\n起動時のエラー いくつかのパターンも試してどんなエラーが出るのかを見てみました。 おまけですね。\nElasticsearchが見つからないエラー Esを起動しないでWorkplace Searchを起動してみました。\n200秒間アクセスしようと試みて駄目だったらエラーで終了みたいです。\n[2020-05-07T03:48:33.645+00:00][13709][2002][app-server][INFO]: Failed to connect to Elasticsearch backend. Make sure it is running. ... [2020-05-07T03:51:54.038+00:00][13709][2002][app-server][INFO]: Could not connect to Elasticsearch backend after 200s. Terminating... [2020-05-07T03:51:54.039+00:00][13709][2002][app-server][ERROR]: -------------------------------------------------------------------------------- Error: Workplace Search is unable to connect to Elasticsearch. Ensure a healthy Elasticsearch cluster is running at http://127.0.0.1:9200 for user elastic. -------------------------------------------------------------------------------- ElasticsearchのSecurityがオフのときのエラー ちなみにSecurityをオフにしたままWorkplace Searchを起動した場合は以下のようなエラーが出ました。\n[2020-05-07T03:46:53.474+00:00][13567][2002][app-server][ERROR]: -------------------------------------------------------------------------------- Elastic Workplace Search requires Elasticsearch security features to be enabled. Please enable Elasticsearch security features as outlined here: https://www.elastic.co/guide/en/workplace-search/current/workplace-search-install.html -------------------------------------------------------------------------------- 構成要素 ここまでインストールして起動してきました。 では、Workplace Searchがどういったコンポーネントから構成されているかを予測してみましょう(あくまで外から見た予想となります。そのうちElastic社のウェビナーとかイベントで内部の発表とかあるかも?)。\nインストールページの記載から インストールページに最小ハードウェアという記載があり、そこで何が動く可能性があるかというのがわかります。\n起動するものはこんな感じみたいです。\nElasticsearch - 外部でもOK App Server - Workplace SearchのWeb機能 Worker - クローラーとかかな? Filebeat - Workplace Searchのログ収集用 その他プロセス - なんだろ? という具合です。\n設定などからの予想 次は設定項目や起動時のログなどからの予想です。\nWorklpace Search配下のセキュアなデータストア - アクセストークンなどの管理のため JRubyアプリケーション - App ServerはJRuby上で動いているRailsアプリ Filebeatも起動している - Workplace Searchのログ収集のため? Filebeatの接続設定はWorkplace Searchの設定値を利用 では構成要素は? ということで、現時点でわかった構成要素は以下のとおりです。\nElasticsearch Workplace Search App Server - Railsアプリ on JRuby Webアプリとは別に(内部?で)、いくつかのワーカーが存在する 管理画面と検索画面の2種類が存在 Filebeat - ログ収集 といった感じです。 まだ起動したばかりなのでこのくらいでしょうか。ログを見るともう少しわかりそうな気がします。\n基本的には、EsをバックエンドにしたRailsのミドルウェアになります。コネクターや検索画面はすべてWorkplace Searchのミドルウェア経由でアクセスする形になりますので、普通に検索で利用するユーザーにはElasticsearchの存在は見えない作りになっています。\n次は? Getting Startedを元に、どんなアクターがいて、どんな機能が提供されているのか、どんな利用方法なのか?というのを見ていこうと思います。\n","date":1588818770,"dir":"post/2020/","id":"44db1f1fefc97cd28d55d443f2bd2b63","lang":"ja","lastmod":1588818770,"permalink":"https://blog.johtani.info/blog/2020/05/07/install-workplace-search/","publishdate":"2020-05-07T11:32:50+09:00","summary":"前回はWorkplace Searchの概要について書きましたが、今回はインストールと構成要素について説明します。なお、2020/5/7時点で","tags":["elasticsearch","workplace search"],"title":"ElasticのWorkplace Searchを触ってみる - その2 - インストールと起動"},{"contents":"2月のElastic社のブログですが、Enterprise Searchとこれまで呼んでいた製品をWorkplace Searchという製品名に変更し、App Searchなどを含む製品群をEnterprise Searchという名前に変更しました(ちょっとややこしい)。 Workplace Search自体はまだβ版という位置づけですが、ダウンロードして試すことが可能です。\nきちんと触ったことがないので、ちょっと触って見ようかなと思い、何回かに分けてブログを書いてみます。まずは概要とかから。\nWorkplace Searchとは? Elasticsearchをバックエンドに利用するElastic社が提供するアプリケーション(ミドルウェア?)の1つです。\nもともとはSwiftypeという会社が作っていた、Site Search、App Searchと同じような系列で開発されている統合検索の検索エンジンミドルウェアという感じです。 製品ページを見るとわかりますが、様々なデータソースから、データをクロールしてElasticsearchに保存することで、統合された検索を提供することができるようになる製品です。 最近は会社のドキュメントがさまざまな場所(Google Drive、Saleseforce、GitHub、Dropboxなど)に保存されています。 それぞれで検索窓などはありますが、1箇所で検索することで横断的に検索でき、仕事の効率があがりますよね?ということで作られている製品です。\n提供(利用)方法は? 今後の提供方法としては、Elastic Cloudで利用できるSaaS形式のものと、独自に(クラウドのコンピューティングエンジンやオンプレのサーバーなどで)Workplace Searchのアプリを起動する方法(オンプレ版)があります。後者の場合は、Elasticsearchのクラスターを用意する必要があります。なお、後者の場合、Elasticsearchのサブスクリプションのプラチナライセンスが必要になるようです(ダウンロードページに記載あり)\nまだ、β版という位置づけなので、今後どのように変更されるかはわかりませんが、今回は2020年5月1日時点でのベータ版(7.6.0)を元にどんなものかを紹介します。現時点で利用できるのはβ版のオンプレ版で、MacやLinuxで利用可能です。\nダウンロードとインストール ダウンロードページにインストール方法などの記載があります。\nインストールして触って見るところはまた後日。\nライセンス、価格は? まだ不明です。SaaS版の提供はまだです。 オンプレ版については少なくとも、Elasticのサブスクリプションのプラチナが必要になります。こちらは、価格は公開されていません。Elastich社もしくはパートナー企業での問い合わせが必要になります。 (たぶん、ドキュメントレベルのセキュリティとかSSOとかの仕組みがプラチナで提供されているのでそのあたりを使っているのでは?と想像してます。)\n想定できそうな用途は? 社内の文書検索でしょうか。ただ、いわゆる昔ながらのエンタープライズサーチと呼ばれている、社内のファイルサーバーなどの文書検索ではなく、クラウドサービスを複数利用している会社が利用する想定になっています。\n例えば、開発者は社内Wiki(Confluence)で社内文書を書き、Issue管理にはJIRAやGitHubを活用しており、ただ、社内での説明にはGoogle Driveを利用しているといった場合です。こういう場合、あの機能についての説明や資料ってどこだっけ?というので、あちこち探し回ったりしないといけないです。また、営業部門やサポート、マーケティングなどが絡んでくると更に、SalesforceやZendeskといったデータソースも出てきます。 情報が散らばっていて、それらを探し出したりまとめるだけで時間を取られている場合などに便利かもしれません。\n次は? 実際にインストールしてから起動して、どんな感じで使えるのかといったところを見て、どんな機能が提供されているのかを見ていこうと思います。\n","date":1588318144,"dir":"post/2020/","id":"4d71d2a23c85fb7af20e8d1e8b3e0de8","lang":"ja","lastmod":1588318144,"permalink":"https://blog.johtani.info/blog/2020/05/01/intro-workplace-search/","publishdate":"2020-05-01T16:29:04+09:00","summary":"2月のElastic社のブログですが、Enterprise Searchとこれまで呼んでいた製品をWorkplace Searchという製品名に","tags":["elasticsearch","workplace search"],"title":"ElasticのWorkplace Searchを触ってみる - その1"},{"contents":"先日、Elasticsearchでのカスタム辞書の利用方法についてブログを書きました。\n辞書の設定方法について記載しましたが、今回は辞書の更新について書いていなかったので、書いてみようと思います。 ここで「辞書」としているのは、Kuromojiのユーザー辞書、Synonym Graph Token FilterのSynonym辞書(いわゆる類義語辞書)のことになります。サードパーティのAnalyzer等に関する話ではありません。\n辞書更新に関する制限事項 辞書の更新について、大原則と制限事項が存在します。\n大原則(辞書の更新=データも更新) ElasticsearchはAnalyzerが切り出した単語を元に転置インデックスを作成して、検索を行っています(この仕組みに関するスライドはこちらを参照のこと)。 Analyzerが辞書を持っている場合、その辞書を元に単語を切り出して転置インデックスに利用します。 また、検索クエリの単語に対してもこのAnalyzerの辞書が利用されます。\n辞書に新しい単語を追加するということは、その単語に関連するドキュメントも更新しないと行けないということになります。\n例えば、Kuromojiを利用していて、「グランベリーパーク」という単語「グランベリー」「パーク」という単語に分割できるような新しい単語として辞書に追加する場合を考えてみましょう。ユーザーが「グランベリー」で検索しても検索結果として出てきてほしいという場合です。\n辞書に「グランベリーパーク」を登録していない頃に登録されたドキュメントは「グランベリーパーク」という1単語として転置インデックスの見出し語を切り出します(Kuromojiはカタカナの連続している文字列については未知語として1単語にし、「名詞-一般」の品詞を付与)。\n更新前でのドキュメントのAnalyze結果\n「グランベリーパーク」「で」「ショッピング」 もし、辞書に「グランベリーパーク」を「グランベリー」「パーク」から構成される新規の単語として登録しそれを使用した場合、辞書を更新したあとから、「グランベリーパーク」という単語がAnalyzerからは出てこなくなります。\n更新後でのドキュメントのAnalyze結果\n「グランベリー」「パーク」「で」「ショッピング」 ということは、辞書更新以前のドキュメントは「グランベリーパーク」という見出し語に対して登録されているので、辞書更新以前に登録されているドキュメントは検索にヒットしなくなります。\nこのように転置インデックスを利用している検索エンジンでは、単語の区切りが変更されるような辞書の更新があった場合、最低でも影響があるドキュメントについては再登録が必要となるわけです。\nこれが大原則(辞書更新=データも更新)となります。 基本的には辞書の更新を行った場合は、ドキュメントの再インデックス(再登録)が必要となります。\nElasticsearchでの制限事項 Elasticsearchでは、辞書の更新に関して実装上の制限事項が存在しています。 内部的な実装として、ElasticsearchではAnalyzerのインスタンス(正確にはAnalyzerのFactoryのインスタンス)の生成がインデックスに関する内部のインスタンスが生成されたタイミングの1回のみとなっています。\nこのインスタンスの生成時に設定ファイル(辞書を含む)を読み込んでいます。\n言い換えると、辞書(ファイル、インデックス設定に関わらず)の読み込みは、インデックスが作られたタイミングのみということになります。 なおここで言う「インデックスが作られたタイミング」というのは、以下の2パターンです。\nインデックス新規作成時 インデックスオープン時 では、ここから辞書を更新してそれを既存のインデックスに適用する方法について説明しましょう。\n辞書の更新方法(ファイル編) 前回のブログで説明しましたが、Elasticsearch 7.4よりも古いバージョンでは、ファイルでKuromojiのユーザー辞書を設定していました。まずはこちらの方法について説明します。前提として、すでにユーザー辞書を設定したKuromoji Tokenizerがインデックスに設定されているものとします(ユーザー辞書の設定方法については公式リファレンスを御覧ください)。\n辞書ファイルに新規にエントリーを追加しただけでは、設定は読み込まれていません。新規辞書を反映させるためには以下の手順が必要となります。\n更新した辞書ファイルの配布 複数ノードでElasticsearchのクラスターを構成している場合はすべてのノードに更新した辞書ファイルを配布する必要があります。 インデックスのクローズ(公式リファレンス) 設定ファイルを再読込させるために一度インデックスをクローズします。 クローズするので、書き込み、検索などの処理を停止する必要があります。もし停止していない場合はクライアント側ではインデックスがクローズされているという旨のエラーを受け取ります(400で、index_closed_exception)。 インデックスのオープン(公式リファレンス) 設定ファイルを読み込みます。これで、新規追加された単語が読み込まれます。 再インデックス _update_by_queryを利用することで、対象のインデックスのデータを再インデックスすることができます。条件無しでAPIを呼び出すとすべてのデータが再度登録されます。 _sourceがfalseの場合は_update_by_queryは利用できません。元データをもう一度外部からElasticsearchに対して登録する必要があります。 Kibanaでの手順をGistにしてあります。手順はこちらをご覧ください。\n辞書の更新方法(インデックス設定編) ファイルの場合とは少し手順が異なります。 インデックスの設定としてユーザー辞書を登録しているため、ファイルをElasticsearchのクラスターにあるノードに配布する必要がありません。 また、辞書の設定はインデックスの設定に指定してありますが、こちらは動的に設定変更できる項目ではないため、インデックスを先にクローズする必要があります。\nインデックスのクローズ(公式リファレンス) 辞書の設定を更新するにはインデックスをクローズする必要があります。辞書の設定は動的に更新できる項目にはなっていないためです。 オープンしているインデックスで更新しようとした場合はillegal_argument_exceptionでCan't update non dynamic settings...というメッセージが返ってきます。 辞書の更新(公式リファレンス:インデックス設定の更新) user_dictionary_rulesに単語と追加します。 インデックスのオープン(公式リファレンス) 設定ファイルを読み込みます。これで、新規追加された単語が読み込まれます。 再インデックス _update_by_queryを利用することで、対象のインデックスのデータを再インデックスすることができます。条件無しでAPIを呼び出すとすべてのデータが再度登録されます。 _sourceがfalseの場合は_update_by_queryは利用できません。元データをもう一度外部からElasticsearchに対して登録する必要があります。 Kibanaでの手順をGistにしてあります。手順はこちらをご覧ください。\n第3の方法(新規インデックス作成) ここまで、インデックスのクローズ、オープンで既存のインデックスに対して辞書を更新する方法について説明しました。 ただ、残念なことにAmazon Elasticsearch ServiceではElasticsearchが提供しているすべてのAPIが利用できるわけではありません(Amazon ESの利用可能なAPIの一覧はこちら)。 (_closeは駄目だけど_openは呼べるのかな???)\nということで、新規にインデックスを作成して、新しい辞書の設定を反映したインデックスを用意し、そこにデータをコピーもしくは登録するという方法になります(Amazon ESのカスタム辞書のドキュメントに手順がありますね)。\n手順としては以下のとおりです。\n辞書の更新(用意) 新しい単語などを登録した辞書を用意します。 ファイル、インデックス設定どちらでもOKです。 ファイルの場合は、既存のファイル名とは異なるファイル名にしたほうが混乱がなくなります。 新規インデックス作成 1.で作成した辞書を元に新規インデックスを作成します。 新規インデックスにデータコピー _reindex APIを利用するとデータコピーが簡単です。sourceとdestを指定するだけです。 _sourceがfalseの場合は_update_by_queryは利用できません。元データをもう一度外部からElasticsearchに対して登録する必要があります。 アプリケーション側で新規インデックスを利用するように変更 _aliasを使用しておくと切り替えが簡単です(公式リファレンスはこのあたり)。 考慮すべき点としては、サービスを提供しながら行う場合は、3.の_reindexを実行し始めたタイミング以降の登録・更新データの扱いについてでしょうか。\nまとめ 辞書の更新に関する大原則、制限事項、手順などについて説明しました。 辞書の変更は検索に大きく影響がでます。そのあたりをきちんと考慮しながら更新しましょう。 ユーザー辞書、カスタム辞書を扱う際の参考にしていただければと。 他にもユーザー辞書で気をつけないといけないこともありますが、今日はこのあたりで。\n","date":1587951855,"dir":"post/2020/","id":"be2c49ea5816e7daa6d3b3ff45353291","lang":"ja","lastmod":1587951855,"permalink":"https://blog.johtani.info/blog/2020/04/27/note-updating-dictionary/","publishdate":"2020-04-27T10:44:15+09:00","summary":"先日、Elasticsearchでのカスタム辞書の利用方法についてブログを書きました。 辞書の設定方法について記載しましたが、今回は辞書の更新","tags":["elasticsearch"],"title":"辞書の更新についての注意点"},{"contents":"Elasticsearchで日本語を扱うときに、カスタム辞書を使いたいという要望がよくあります。 AWSのElasticsearch Serviceでカスタム辞書ファイルを読み込める機能が発表されたようです。\n実は、Elasticsearchの7.4からファイルを使用しなくても日本語のTokenizerでカスタム辞書を利用することができるようになっています。\nカスタム辞書をインデックスの設定で指定 やり方はドキュメントに記載があります。\nトークナイザーの設定をインデックスの設定に記述しますが、このときに user_dictionary_rulesという設定を利用することでカスタム辞書を指定できます。\nPUT custom_dic_sample { \u0026#34;settings\u0026#34;: { \u0026#34;index\u0026#34;: { \u0026#34;analysis\u0026#34;: { \u0026#34;tokenizer\u0026#34;: { \u0026#34;kuromoji_user_dict\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;kuromoji_tokenizer\u0026#34;, \u0026#34;mode\u0026#34;: \u0026#34;extended\u0026#34;, \u0026#34;user_dictionary_rules\u0026#34;: [ \u0026#34;グランベリーパーク,グランベリー パーク,グランベリー パーク,カスタム名詞\u0026#34;, \u0026#34;高輪ゲートウェイ,高輪 ゲートウェイ,タカナワ ゲートウェイ,カスタム名詞\u0026#34;] } }, \u0026#34;analyzer\u0026#34;: { \u0026#34;my_analyzer\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34;: \u0026#34;kuromoji_user_dict\u0026#34; } } } } } } 辞書の内部は\u0026quot;単語,出てきてほしい単語列(スペース区切り),読みの単語列(スペース区切り),品詞名\u0026quot;になります。配列で設定可能で、複数の単語を登録したい場合は、カンマ区切りで登録していきます(上記例では2つの単語を登録しています)。\n_analyzeを利用して設定の確認 実際に上記の設定がうまく動作するかは_analyzeのエンドポイントを利用します。\nGET custom_dic_sample/_analyze { \u0026#34;text\u0026#34;: \u0026#34;グランベリーパークがオープンしました。\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;my_analyzer\u0026#34; } 出力は以下のようになります。\n{ \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;グランベリー\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 6, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 0 }, { \u0026#34;token\u0026#34; : \u0026#34;パーク\u0026#34;, \u0026#34;start_offset\u0026#34; : 6, \u0026#34;end_offset\u0026#34; : 9, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 1 }, { \u0026#34;token\u0026#34; : \u0026#34;が\u0026#34;, \u0026#34;start_offset\u0026#34; : 9, \u0026#34;end_offset\u0026#34; : 10, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 2 }, { \u0026#34;token\u0026#34; : \u0026#34;オープン\u0026#34;, \u0026#34;start_offset\u0026#34; : 10, \u0026#34;end_offset\u0026#34; : 14, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 3 }, ...(省略) ] } ちなみに、デフォルトのkuromojiを利用した場合は、グランベリーパークが1単語として出力されます。\nGET _analyze { \u0026#34;text\u0026#34;: \u0026#34;グランベリーパークがオープンしました。\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34; } ## レスポンス { \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;グランベリーパーク\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 9, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 0 }, { \u0026#34;token\u0026#34; : \u0026#34;オープン\u0026#34;, \u0026#34;start_offset\u0026#34; : 10, \u0026#34;end_offset\u0026#34; : 14, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 2 } ] } これで、カスタム辞書を使用することでグランベリーで検索された場合に、グランベリーパークもヒットするという仕組みです。\n_analyzeはexplainというパラメータも持っており、こちらを利用することで、単語の品詞情報なども取得できます。これを使うことで、実際に設定がきちんと動作しているかの確認に利用できます。\nGET custom_dic_sample/_analyze { \u0026#34;text\u0026#34;: \u0026#34;グランベリーパークがオープンしました。\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;my_analyzer\u0026#34;, \u0026#34;explain\u0026#34;: true } ## レスポンス(一部のみ) { \u0026#34;detail\u0026#34; : { \u0026#34;custom_analyzer\u0026#34; : true, \u0026#34;charfilters\u0026#34; : [ ], \u0026#34;tokenizer\u0026#34; : { \u0026#34;name\u0026#34; : \u0026#34;kuromoji_user_dict\u0026#34;, \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;グランベリー\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 6, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 0, \u0026#34;baseForm\u0026#34; : null, \u0026#34;bytes\u0026#34; : \u0026#34;[e3 82 b0 e3 83 a9 e3 83 b3 e3 83 99 e3 83 aa e3 83 bc]\u0026#34;, \u0026#34;inflectionForm\u0026#34; : null, \u0026#34;inflectionForm (en)\u0026#34; : null, \u0026#34;inflectionType\u0026#34; : null, \u0026#34;inflectionType (en)\u0026#34; : null, \u0026#34;partOfSpeech\u0026#34; : \u0026#34;カスタム名詞\u0026#34;, \u0026#34;partOfSpeech (en)\u0026#34; : null, \u0026#34;positionLength\u0026#34; : 1, \u0026#34;pronunciation\u0026#34; : null, \u0026#34;pronunciation (en)\u0026#34; : null, \u0026#34;reading\u0026#34; : \u0026#34;グランベリー\u0026#34;, \u0026#34;reading (en)\u0026#34; : \u0026#34;guramberi\u0026#34;, \u0026#34;termFrequency\u0026#34; : 1 }, { partOfSpeechにカスタム辞書で設定したカスタム名詞が出力されていますね。 _analyzeのAPIはこのように、アナライザーの挙動の確認に非常に便利なので是非活用してみてください。\nKibanaでこのAPIを使うためのプラグインも開発していますので、こちらも合わせて利用してみてください。\n注意点 ちなみに、user_dictionaryとuser_dictionary_rulesを両方指定した場合はエラーとなります。 ファイルをベースにしつつ、追加の設定をするという使い方はできないので、注意しましょう。\nインデックスの設定で書くことにより、バックアップ・リストアは楽になるかな。ただ、クラスターステートに取り込まれるから、あまりにも巨大なカスタム辞書だと心配かなぁ。ファイルの場合はクラスターステートには取り込まれないので、そこは圧迫しない。\n\u0026mdash; Jun Ohtani (@johtani) April 22, 2020 それ以外の注意点については、別途ブログを書きました。 「辞書の更新についての注意点」、こちらも合わせてご覧ください。\nまとめ カスタム辞書をファイルではなくインデックスの設定値として設定する方法を紹介しました。こちらは、Elasticsearch 7.4で導入された機能になります。7.4以降を利用している場合はこちらを利用することも検討してはいかがでしょうか? また、_analyze APIも便利なので合わせて活用してみてください。\n","date":1587519056,"dir":"post/2020/","id":"15357b6978e83daa2d97692c861dc177","lang":"ja","lastmod":1587519056,"permalink":"https://blog.johtani.info/blog/2020/04/22/custom-dictionary-after-7-4/","publishdate":"2020-04-22T10:30:56+09:00","summary":"Elasticsearchで日本語を扱うときに、カスタム辞書を使いたいという要望がよくあります。 AWSのElasticsearch Servi","tags":["elasticsearch"],"title":"Kuromojiのカスタム辞書をインデックスの設定で指定"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 第8章 7章はパッケージなので後回しにして、8章に入ります。 8章はコレクションです。\nベクタ型 ベクタは同じ型の値だけ保持可能。 ジェネリクスで型を指定可能 - Vec\u0026lt;i32\u0026gt;とか。 vec!マクロで初期値とか設定すると便利。 ベクタに値を追加するのはpush。もちろん値が変わるので元のベクタにはmutが必要 ベクタのスコープ(ライフサイクル)は要素に対する参照があるのとないので話が変わってくる メモリの確保などの影響で、ベクタ全体に対して借用の規則が矯正されると。 ベクタの値を読むのはいくつか方法あり getメソッドはOptionを返す \u0026amp;v[2]の添字記法の場合はパニックの可能性あり 走査(唐突に参照外しが出てきた) 単純に値を取り出す場合はfor - in \u0026amp;v Enumをベクタにいれることで、異なる型も保持可能(まぁ、Enumの型では固定されるけど)。 これだけのためにEnumを使うことってあるのかな? トレイとオブジェクトに関する文章はちょっとわかりにくい。。。 説明以外のメソッドなどについてはAPIドキュメント見ましょうと(リンクも張ってくれてると嬉しいなぁと思ったり。まぁ、バージョンとかの絡みがあるから難しいか)。\n文字列型 文字列はUTF-8でエンコードされた文字を扱うための型。\nstrは文字列データへの参照。\nString型は言語のコアではなく、標準ライブラリに入っている文字列型。\n他にもあるのか。。。OsStringとか。。。 文字リテラルはDisplayトレイトを実装していると。\n.to_string() = String::from\nStringはコレクションだから追加とかが可能なのか、なるほど。\npush_strとpush\n+演算子での参照。\n\u0026amp;Stringは\u0026amp;strに型強制(キャスト?)してくれる。してくれる場合としてくれない場合もあるのかな?s2の所有権は奪わない形で扱うのでs2はこのあとも使えていると。 ここでは、s1を変更したあとに所有権がs3に持っていかれてる? format!を使うとどの所有権も奪わないので、これを使うほうが考え方は簡単そう。ただし、効率がいいかはわからん。 添字記法でのアクセスをStringは許容していない\n文字の境界が必ずしも1バイトとは限らないから。 スライスも同様。 基本的には.chars()で文字としてアクセスするのが良い。\n逆にバイト表現を得る方法はどうするんだろう?\nNLP100本ノックではencode_utf8メソッド使ったけど。 ハッシュマップ いろんな呼び方あるよね。Rustではハッシュマップだよ。 ハッシュマップはuseしないと使えない キーは1つの型、値も1つの型 タプルのベクタからcollectで生成。なるほど。 タプルのベクタだと、タプルの中身は同じものであることが言える? -\u0026gt; 言える。エレメント数が異なるとコンパイルエラーになった 所有権周りの話。 これ、ベクタのときに話してほしい感じがした。 値を渡すか参照を渡すかによって話が変わってくる。詳しくは10章 このあたりが自分が混乱していた元だ。 entryとinsertの違い entryの戻り値はEntryというenumでor_insertというメソッドがありそれを使うと存在しない場合だけinsertが呼ばれる。 これ便利だ。毎回existあたりで存在チェックしてた気がする。 or_insertは可変参照\u0026amp;mut Vを返す。 これをlet countで束縛するときに、中身が可変かどうかをcountには指定しないのか。。。 まとめ 一応、大学などで習ってた(はず)ですが、 スタックとヒープを意識して考えないといけないなぁというのを何度か意識させられた感じです。\nあと、これはRustに限らずですが、それぞれがどんな関数を持っているか、どんなメソッドを持っているか、どんなマクロが存在するかなどを探すときにみんなどうしてるんだろう? 人に教えてもらっているのか、APIリファレンスを探すのか、そういったところをみんながどういう感じにプログラミング言語を勉強しているか、業務で書いているのかと言うのが気になりました。\n","date":1587028650,"dir":"post/2020/","id":"f488aa62d39194824861a134567cadb8","lang":"ja","lastmod":1587028650,"permalink":"https://blog.johtani.info/blog/2020/04/16/chap8-rust-the-book/","publishdate":"2020-04-16T18:17:30+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 第8章 7章はパ","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第8章"},{"contents":"Rustで言語処理100本ノックのリファクタリングの続き。\n前回はこちら。\nコードも載せたほうが見やすいかなぁ?\n03. 円周率 2年前はこちら。 どちらかというとJavaっぽい書き方かな? 入れ物を用意して、入力を整形して、それからループを回す感じで書いてました。\n今回は1行で収めてみました。 Rustっぽく、returnを省略してみました。 あとは、Iteratorを組み合わせる感じでやってます。 アルファベットの文字数ということで、is_alphabetic()メソッドでfilterしてます。\n04. 元素記号 2年前はこちら。 エラー処理が多いのと、文字の扱いがちょっと\nここまで同様に極力イテレータを利用するという方針でリファクタリングしました。 あとは、エラー処理を除去してます。 正常系だけのテストなのでスッキリさせました。\nこういった、ストリーム系?の書き方の場合にエラー処理をどう入れるかってところはちょっと悩みどころになるんじゃないかなぁ?と思いつつ、イレギュラーなものは後回しで(あとにやるのかなぁ?)\n05. n-gram 2年前はこちら。 これまでと同じく、入れ物を作ってから処理をしてます。\n同じく、極力イテレータを利用する形で実装しました。 いくつか型の変換が必要なので、.map()を呼び出して詰め替えたりしています。\n06. 集合 2年前はこちら。 独自に実装しています。\nせっかく05で文字n-gramの配列を返す処理を実装しているので、 そちらを呼び出して、Setに入れるという処理に書き換えました。 その後の集合に対する処理については特にリファクタリングしてないです。\nまとめ 2年前にやってたところまでは追いつきました。 07は特にリファクタリングする必要がないので、次は08からの予定です。\nリファクタリングしているときになるのは、速度とかでしょうか。 実装の違いでなにか差が出るのかどうかはちょっと気になるところですが、 今回の目的ではないので、目をつぶって進める予定です。\n","date":1586423695,"dir":"post/2020/","id":"9a687babb0f44db51dc389b75bdaa19d","lang":"ja","lastmod":1586423695,"permalink":"https://blog.johtani.info/blog/2020/04/09/reboot-nlp100-ch01-03to05/","publishdate":"2020-04-09T18:14:55+09:00","summary":"Rustで言語処理100本ノックのリファクタリングの続き。 前回はこちら。 コードも載せたほうが見やすいかなぁ? 03. 円周率 2年前はこちら。 どちらか","tags":["Rust","nlp100"],"title":"第1章の03から06まで(言語処理100本ノック2020)"},{"contents":"今回もツイートから。\n言語処理100本ノックの2020年版を公開しました。最近の自然言語処理の研究動向を反映し、深層ニューラルネットワークに関する問題を追加しました。留学生も一緒に取り組めるように多言語化を進め、その第１弾として英訳を部分公開しています（40番以降は順次公開予定）。 https://t.co/52h362PIQQ\n\u0026mdash; Naoaki Okazaki (@chokkanorg) April 6, 2020 言語処理100本ノックが2020年版になったそうです。 そうです、2年前に初めて、準備運動で止まっていたんです!(衝撃的な続かなさ。。。)\nということで、Rust the bookも読んでいることだし、過去のプログラムをチェックしつつ再開しようかなと。 ということで、いくつかリファクタリングしてみました。\nソースはリポジトリを御覧ください。\n00. 文字列の逆順 2年前の実装では、chars()メソッドで取り出したあとに、collect()でVecにしていたのですが、RustのIteratorトレイトにrev()という便利なメソッドが存在していました。\nということで、これを取り出すと、最初の文字列の逆順で文字を取り出すIteratorが取得できます。 あとは、Stringが実装してくれているfrom_iterに渡せば文字列が出来上がります。\n01. 「パタトクカシーー」 ストリーム処理っぽい書き方に変更しました。 2年前はIteratorを取り出して、詰替していましたが、 enumerate()で添字と文字のタプルのイテレータに変換し、 filterで添字が偶数のときだけフィルタリングして、 mapで対象の文字をまとめたイテレータにします。 で、最後はそれを元に文字列を生成することにしました。 iterを使わないでそのままString::from_iterの引数に渡すことも可能ですね。\n02. 「パトカー」＋「タクシー」＝「パタトクカシーー」 2年前は2つのIteratorをloopで回して頑張って結合してました。 ではなく、zip()を使って、2つのイテレータを組み合わせる方法に替えてみました。 このとき、2つの文字列が違う文字数の場合の処理として、長い方から取り出した文字をあとに結合する処理を追加で記述しました。 ちょっとスマートな感じになりましたかね?\nzipしたあとに出てきたタプルの文字列を結合するのにformat!マクロを使いましたが、他にいい方法有るかなぁ?\nまとめ とりあえず最初の3つをリファクタリングしてみました。 残りもやりつつ、準備運動以降もがんばるぞと。\n","date":1586338425,"dir":"post/2020/","id":"dc9580308938069159c5afc55b2f3b96","lang":"ja","lastmod":1586338425,"permalink":"https://blog.johtani.info/blog/2020/04/08/reboot-nlp10-with-rust/","publishdate":"2020-04-08T18:33:45+09:00","summary":"今回もツイートから。 言語処理100本ノックの2020年版を公開しました。最近の自然言語処理の研究動向を反映し、深層ニューラルネットワークに関","tags":["Rust","nlp100"],"title":"言語処理100本ノック、再び"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 第6章 Enumです。match式に大活躍\nEnumを定義する 列挙型は取りうる値をすべて列挙できる。これが名前の由来 列挙型と列挙子 2連コロン(::)で列挙子を指定可能 列挙子にデータ(構造体も)が格納可能。 標準ライブラリに実装例あり。 疑問:Write(String)とかはタプルの表現になるのかな? と思ったが、タプルでは1つだけの変数を持つものは定義(正確には定義できるが、内部で普通の変数にもどされてるっぽい)できなかった。 メソッド定義も可能 関連関数もできる? -\u0026gt; できる Optionの紹介 Rustにnullはない。代わりにOptionがある Noneを指定する場合に型が必要。Someの場合はすでに値が入るから推測可能なため。 match制御フロー演算子 アーム -\u0026gt; matchしたときの処理のこと 短い場合は波括弧は不要 returnなしでmatchが書いてあるだけだと、慣れない場合に値を返していることに気づかないかも(実際気づけてないかも) Enumが値を持っているときに、値の束縛がmatch式で可能 すべての列挙子を網羅していないことをコンパイラが検知してくれるのはすごく助かる。 ただし、_を利用していなければだけど if letで簡潔な制御フロー enumで1つのパターンのときに処理をしたい場合に使えるmatchの糖衣構文 elseもかけるよ。 まとめ enumに慣れていないので、値や構造体を持つenumを利用するという想像ができないことがありそうだなぁと読みながら思いました。 それになれると、色々とプログラムがシンプルに書ける部分が多くなりそうかな。\n","date":1586255231,"dir":"post/2020/","id":"4fbdc9c57a37781dc5dd86f470c61d04","lang":"ja","lastmod":1586255231,"permalink":"https://blog.johtani.info/blog/2020/04/07/chap6-rust-the-book/","publishdate":"2020-04-07T19:27:11+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 第6章 Enumです。matc","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第6章"},{"contents":"Kuromoji-CLIの使い方などについては過去のブログを御覧ください。\nKuromojiのCLIコマンドとpicocliとGraalVM GitHubリポジトリ Issueだけ上げていたJSON出力対応をしました。 また、ラティス(後述)の出力対応もしました。\nJSON出力 LinderaがJSON出力に対応してるのでそれを真似しました。 -o jsonで指定していただくと、次のようなJSONが出力されます。\n% echo \u0026#34;春眠暁を覚えず\u0026#34; | build/graal/kuromoji -o json [ { \u0026#34;text\u0026#34;: \u0026#34;春眠\u0026#34;, \u0026#34;detail\u0026#34;: [ \u0026#34;名詞\u0026#34;, \u0026#34;一般\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;春眠\u0026#34;, \u0026#34;シュンミン\u0026#34;, \u0026#34;シュンミン\u0026#34; ] }, { \u0026#34;text\u0026#34;: \u0026#34;暁\u0026#34;, \u0026#34;detail\u0026#34;: [ \u0026#34;名詞\u0026#34;, \u0026#34;一般\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;暁\u0026#34;, \u0026#34;アカツキ\u0026#34;, \u0026#34;アカツキ\u0026#34; ] }, { \u0026#34;text\u0026#34;: \u0026#34;を\u0026#34;, \u0026#34;detail\u0026#34;: [ \u0026#34;助詞\u0026#34;, \u0026#34;格助詞\u0026#34;, \u0026#34;一般\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;を\u0026#34;, \u0026#34;ヲ\u0026#34;, \u0026#34;ヲ\u0026#34; ] }, { \u0026#34;text\u0026#34;: \u0026#34;覚え\u0026#34;, \u0026#34;detail\u0026#34;: [ \u0026#34;動詞\u0026#34;, \u0026#34;自立\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;一段\u0026#34;, \u0026#34;未然形\u0026#34;, \u0026#34;覚える\u0026#34;, \u0026#34;オボエ\u0026#34;, \u0026#34;オボエ\u0026#34; ] }, { \u0026#34;text\u0026#34;: \u0026#34;ず\u0026#34;, \u0026#34;detail\u0026#34;: [ \u0026#34;助動詞\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;*\u0026#34;, \u0026#34;特殊・ヌ\u0026#34;, \u0026#34;連用ニ接続\u0026#34;, \u0026#34;ぬ\u0026#34;, \u0026#34;ズ\u0026#34;, \u0026#34;ズ\u0026#34; ] } ] Viterbiラティス出力 Kuromojiが内部でトークンをどのように切り出すかを計算するためのViterbiのラティスです。これをGraphvizというツールのDOTフォーマットのファイルとして出力できるメソッドがデバッグ用ですが、Kuromojiに用意されています。 こちらを呼び出して出力するオプション-v(もしくは--viterbi)を追加しました。 注意点として、このオプションを指定すると、DOTファイルが標準出力に出力され、トークンの結果は標準エラーに出力されます。\necho \u0026#34;春眠暁を覚えず\u0026#34; | build/graal/kuromoji -v \u0026gt; viterbi.dot .dotファイル自体は画像ではないので、Graphvizのdotコマンドにて画像ファイルに変換する必要があります。\ndot -Tpng viterbi.dot -oviterbi.png これで、PNGファイルが出来上がります。出来上がったファイルはこんな感じです。\n画像を見ていただくと、緑色のパスがあるのがわかります。 こちらが、Kuromojiが実際に採用した形態素のリストです。それ以外のパスは不採用だったパスとなります。\nちなみに、macOSで1行で画像表示まで行うにはこんな感じで実行します。 openコマンドでpreviewアプリを指定することで画像が表示できます。 Windowsは。。。わかりません、すみません。\n% echo \u0026#34;春眠暁を覚えず\u0026#34; | build/graal/kuromoji -v -o json | dot -Tpng | open -f -a preview.app まとめ これ以前に複数辞書対応などもしていました。 今回は2つの出力形式を追加してみました。 特にViterbiラティス出力については、内部的にどのようなコスト計算で最終的な結果が出てきているかという理解に役立ちます。想定していない切れ方の場合は、そもそも想定している形態素になっていないか、コスト計算で不採用だったかなどを確認できますので、使ってみると面白いかもです。\n","date":1586143600,"dir":"post/2020/","id":"6fbf7c3d0f4f89e415e89cec28811a94","lang":"ja","lastmod":1586143600,"permalink":"https://blog.johtani.info/blog/2020/04/06/update-kuromoji-cli/","publishdate":"2020-04-06T12:26:40+09:00","summary":"Kuromoji-CLIの使い方などについては過去のブログを御覧ください。 KuromojiのCLIコマンドとpicocliとGraalVM G","tags":["misc"],"title":"KuromojiのCLIコマンドにJSON出力とラティス出力を追加"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた Rust the book - 第4章 第5章 構造体です。勝手知ったるなんとやら?オブジェクト指向的な部分は問題ないかなぁと。\n定義とインスタンス化 structで定義 インスタンスの生成は引数は順不同でOK 構造体のインスタンスを可変にするとフィールドの値も変更可能 特定のフィールドのみ可変にすることは不可能 インスタンス化する関数の最後でreturnなしでインスタンスの返却を暗黙にできる(return書いてほしいな。。。) インスタンス化時にフィールド初期化省略記法が可能(これはちょっと便利?) 構造体更新記法..user1のように、明示的に設定されていない他のフィールドをコピーしてくれる機能あり タプル構造体 タプル構造体!? struct Color(i32, i32, i32); いつ使うんだろう? ユニット様構造体 ユニット様構造体 = フィールドのない構造体。トレイトを実装したいけどインスタンスで持つ値はない場合に利用 ライフタイム 構造体が参照を持つときにライフタイムという話が出てくる。なるほど。 ライフタイム指定子が必要になる -\u0026gt; 10章での話 プログラム例 タプルを引数かぁ。タプルは慣れないので構造体作りそう Debugトレイトと{:?}という書き方 derive(Debug)でデバッグ用のトレイトを自動で実装=継承してくれる {:#?}だとpretty printになる(改行とか入る) この辺の便利なトレイとは付録Cにあるらしい。この辺はやりながら覚えるしかないか。\nメソッド記法 最初の引数は必ずself implは構造体とは別の場所に書く = Javaのクラスとは違う struct Rectangle { width: u32, height: u32, } impl Rectangle { fn area(\u0026amp;self) -\u0026gt; u32 { self.width * self.height } } 参照じゃないselfも使えるらしい。どういうときに使うんだろう? 関連関数 selfなしの関数をimplにかける。Javaのスタティックメソッドみたいな感じ その他 implブロックがあちこちにかける。これはつらいな。。。 2つにわかれたimplブロックに同じメソッドを書いてみたら、CLionのプラグインではエラーを検知してもらえなかった。 cargo buildではきちんとエラーが表示された。 複数のimplブロックが有用になるケースは第10章で見ますが、そこではジェネリック型と、トレイトについて議論します。\n人の構造体に自分のトレイトを適用したりもできる。 実験 スコープとかどうなりそう?って実験もしてみた。\nfn main() { trait Hoge { fn trim(\u0026amp;self); } impl Hoge for String { fn trim(\u0026amp;self) { println!(\u0026#34;hogehoge {}\u0026#34;, \u0026amp;self); } } let c = String::from(\u0026#34;hoge\u0026#34;); c.trim(); println!(\u0026#34;{}\u0026#34;, fuga(\u0026amp;c)); } fn fuga(d: \u0026amp;String) -\u0026gt; \u0026amp;str { d.trim() } 出力はこんな感じ\nhogehoge hoge hoge まとめ 気になったのは以下の点。そのうち分かるようになってくるのかな。\n構造体更新記法はどういったときに使うのを想定して作ったんだろう?とか 可変長引数はマクロじゃないとだめ ","date":1585807758,"dir":"post/2020/","id":"8d9c3760395e8e0eb40e335b22750b68","lang":"ja","lastmod":1585807758,"permalink":"https://blog.johtani.info/blog/2020/04/02/chap5-rust-the-book/","publishdate":"2020-04-02T15:09:18+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 第5章 構造体です。勝手知ったるなんとやら?","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第5章"},{"contents":"すもけさんが在宅勤務環境をブログに書いてておもしろそうだな(あと、アフィリンク貼れるな)と思ったので自分の環境も書いてみようかなと。\n私自身は昨今の新型コロナウイルスの影響というのではなく、もう10年以上自宅でも作業ができる環境を整えています。 前前職の頃から家でも仕事をすることがよくあったので。今は、お客さんに恵まれていてリモートができる形で働かせていただいてます。\n机周りはこんな感じです。机はこれも15年以上前から使用しているエレクターの机です。椅子も15年以上前から使っているアーロンチェア(購入時は高いと思ったけど、これだけ使えているので大満足)です。\nメインのPCはMac Book Pro16インチを使っています。それとは別にMac miniがMac bookの後ろに隠れています。こっちはブラウジングや音楽を聞いたりするために使っています。\nまずはディスプレイ周りから。\nディスプレイ周り ディスプレイ Acerの31インチディスプレイです。昨年の夏に購入しました。28インチの4Kディスプレイを探していたのですが、セールか何かで2-3000円の違いでこのサイズが買えたので、このサイズになっちゃいました。Mac Book ProはDisplay port-USB-Cケーブルで接続し、PS4をHDMIで接続しています。 【Amazon.co.jp 限定】Acer モニター ディスプレイ ET322QKwmiipx 31.5インチ マイクの左側に写っているのはAppleのサンダーボルトディスプレイです。縦にしてブラウザやミュージックプレイヤーなどで音楽かけながら仕事をしています。 サブディスプレイって感じです。 Mac Book ProとMac miniの両方を操作するのですが、できれば同じキーボード+トラックパッドがいいなということで、Synergyというソフトを使って、Mac Book Proのキーボードとマウスでネットワーク越しにMac miniを操作しています。ただ、マシンの再起動後などにこのソフトが起動していない場合もあるので、Mac Book Proの右側にMac miniのためのトラックパッドがおいてあります。\nディスプレイアーム ディスプレイはそれぞれディスプレイアームを使っています。写真のようにMac Book Proを下に、外部ディスプレイを上にという上下で作業をしています。 16インチの画面だと普通のディスプレイの足だとメインディスプレイにかぶってしまうので、アームに切り替えました。 最初はグリーンハウスの激安を使っていたのですが、31インチのディスプレイだとアームの高さが足りなかったので、2つ目のガススプリング式のアームを追加で購入しました。ガススプリング式なのに5千円しないので、かなりお得感があります。ただ、ディスプレイは基本的に動かさないので、どちらかというとディスプレイの足の部分を効率良く使うことが目的です。\nAmazon | グリーンハウス 液晶ディスプレイアーム 4軸 クランプ式 Amazon | HUANUO PC モニター アーム 液晶ディスプレイ アーム ガススプリング式 サウンド関連 スピーカー 基本、音楽を聞きながら作業をするので、小型だけどしっかりと音がでるスピーカーを買いました。スタイルもいいし気に入ってます。 入力が2系統あるので、31インチディスプレイのヘッドフォン出力とMac miniのからの出力の2つをつないでいます。 仕事中はMac miniで音楽流しつつ、テレカンやゲームのときはメインディスプレイからの音が出る形です。 Amazon | ヤマハ パワードスピーカー NX-50 マイク 前職がDeveloper Advocateということで、インタビューなどに行くこともあるかも?ということで小さめのも運びができるコンデンサマイクを購入してました。結局それほど持ち運びはしてないのですが、値段の割には音がいいんじゃないかな?一応、無指向と単一指向の2種類を切り替えることが可能です。\nAmazon | SAMSON マイク ポータブル USB コンデンサ Go Mic | コンデンサ | 楽器 マイクスタンド マイクはあったのですが、クリップ式でした。PCのディスプレイにクリップしていると、打鍵音を拾ってしまうので、マイクスタンドを最近導入しました。やすかったです。 前まではヘッドフォンのケーブルに付いているマイクで喋っていたのですが、服によってはマイクに擦れてしまい、ノイズが載っていました。 マイクスタンド+スピーカーでもスピーカーの音をマイクが拾わないので、最近はヘッドフォンを使用しないで気楽に話ができるようになっています。 Amazon | Luling Arts マイクスタンド アーム その他 モニタスタンド Mac Book Proの後ろで見えにくいですが、Mac miniが下に入っていて、上にMac mini用のキーボード、スピーカー、Qiの充電パッドが載せてあります。 Mac miniのキーボードをじゃまにならないように置きたいという目的で購入しました。3次元で空間が利用できるので結構重宝してます。 Amazon | サンワサプライ 机上液晶モニタスタンド(D200・黒) MR-LC303BK 充電関連 スマホ充電用にスピーカーの横においてあります。ただ、スイートスポットを探すのがちょっと大変で、時々充電できてないことがあったりします。。。 Amazon | DesertWest Qi 急速充電ワイヤレス充電器 【Qi認証済み/PSEマーク付き】15W USBでの様々な充電用にはMercariさんのカンファレンスでいただいたAnkerの充電器をおいてあります。Mi Band 4、キーボードなどの充電向けです。 Amazon | Anker PowerPort 6(60W 6ポート USB急速充電器) まとめ 簡単ですが作業環境でした。だいたい満足しています。もうちょっと改善したいなと思っているのは次の点です。\nUSB-Cドック?ハブ?みたいなものがほしい 充電ケーブル、マイク、ディスプレイケーブル、有線LANの4つのケーブルがMac Book Proに刺さっており、ポートが全滅です。出先から帰ったときにつなぐのも少し面倒なので、1つか2つのポートでまとめられるといいなぁと思っています。が、ドック系はいい値段するのでまだ置き換わっていない感じです。 スタンディングデスクが気になる 自宅でずっと座っているのはやはり気になるもので。スタンディングデスクにして時々たって作業したいなぁと思うことがあります。ただ、使ったことがないので、どれがいいのかわからず手を出せない状況です。 ウェブカメラいる? Mac Book Proのカメラでオンラインミーティングなどしています。気にするほどのことではないとは思いますが、メインディスプレイを見ながらしゃべると下からカメラで撮影されている形になります。。。 今のところはこんな形です。なにかの参考になればと。 あと、なにかおすすめのもの(特にスタンディングデスク)があれば教えて下さい!\n","date":1585217511,"dir":"post/2020/","id":"3f431bf71ee866f626daf42bc915fa3f","lang":"ja","lastmod":1585217511,"permalink":"https://blog.johtani.info/blog/2020/03/26/working-facility/","publishdate":"2020-03-26T19:11:51+09:00","summary":"すもけさんが在宅勤務環境をブログに書いてておもしろそうだな(あと、アフィリンク貼れるな)と思ったので自分の環境も書いてみようかなと。 私自身は","tags":["misc"],"title":"自宅の作業環境(2020)"},{"contents":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。\nRust the Bookを読み始めた 第4章 第4章です。たぶん、これがいちばん大事な概念だと思います、Rustの。 そして、つまみ食いしながらRust書いてましたが、ここがきちんと理解できないまま書いてたってのもあります。。。\n所有権とは? drop関数ってのがあって、明示的に呼ぶことも可能。次のような感じで。2つ目のprintln!はエラーになる。sがもう無いのに借用しようとしてるから。 fn main() { let mut s = String::from(\u0026#34;hello\u0026#34;); s.push_str(\u0026#34;, world!\u0026#34;); println!(\u0026#34;{}\u0026#34;, s); drop(s); println!(\u0026#34;{}\u0026#34;, s); } ムーブ - shallow copyではない。以下の2行目がムーブ。 let s1 = String::from(\u0026#34;hello\u0026#34;); let s2 = s1; println!(\u0026#34;{}, world!\u0026#34;, s1); スタックとヒープの話が絡んでくる。あんまり意識すること無いよなぁ。 スタック = 固定長のデータを入れる場所。ポインタ、数値など ヒープ = 可変長のデータが入る場所。可変の文字列とか。\nクローン - ヒープのデータをコピーすること。 コピー - スタックに収まるデータの場合はクローンが必要なくコピーで事足りる。 CopyトレイととDropトレイとは同居できない。 タプルのコピーはややこしそう 所有権と関数でまた、スタックに入れられるような変数と可変のオブジェクトの違いが出てくる。 takes_ownership(s: String)が参照を受け取れば問題なく、このあとも使える。 戻り値でもムーブが発生 参照と借用 借用 - 関数の引数に参照を取ること 可変な参照\u0026amp;mutは1つ(不変な参照も含めて1つ)しか許さない データの競合を防ぐため。 不変な参照を複数用いるのはOK 実際に変更が実行されるタイミングでエラーと判定される場合もある。 let mut s = String::from(\u0026#34;hello\u0026#34;); { let r1 = \u0026amp;mut s; } // r1はここでスコープを抜けるので、問題なく新しい参照を作ることができる let r2 = \u0026amp;mut s; ダングリング参照はテスト書くときとかにやってるかも。。。 fn dangle() -\u0026gt; \u0026amp;String { // dangleはStringへの参照を返す let s = String::from(\u0026#34;hello\u0026#34;); // sは新しいString \u0026amp;s // String sへの参照を返す } // ここで、sはスコープを抜け、ドロップされる。そのメモリは消される。 // 危険だ スライス型 部分的な参照。開始位置+長さで構成されているっぽい \u0026amp;strの説明がよくわからなかった。 引数としての文字列スライスのテクニックは色々と使いまわせそう。\nまとめ 所有権、これまで特に難しいと思ってたのは、固定長の変数と、可変長の変数の違いを意識してなかったのが原因っぽい。 まぁ、Vecとかがどうなるのかとか、他にもいくつか気になるところはあるので、もうちょっとやらないといけないなと思いました。\n","date":1585210331,"dir":"post/2020/","id":"7fded0345c258eea966c0b5ee1b7c7aa","lang":"ja","lastmod":1585210331,"permalink":"https://blog.johtani.info/blog/2020/03/26/chap4-rust-the-book/","publishdate":"2020-03-26T17:12:11+09:00","summary":"前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた 第4章 第4章です。たぶん、これがいちばん大事な概念だと思","tags":["rust","読書","rust-the-book"],"title":"Rust the book - 第4章"},{"contents":"先日、Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)というブログを書きました。 このプラグインを作ってたタイミングで、Elasticの河村さん経由で、Microsoft Open Tech Night #9 w/ ElasticでなにかLTしませんか?という打診がありました。\n仕組み的には似たようなものだし、Elasticsearch用の拡張機能も作れるし、発表のネタにもなるし一石二鳥では?ということで、LTを快諾し、昨日発表してきました。\n資料とか 発表資料やGitHubのリポジトリなどは、以下のとおりです。\n発表資料 : Analyze APIのVS Codeプラグインを作ってみた GitHub Repository : https://github.com/johtani/vs-code-es-analyze-client Visual Studio Code Marketplaceページ 機能 まだ、必要最低限の機能を実装した感じです。\nAnalyze APIのパラメータ入力用のエディタ起動(Elasticsearch Analyze Client: Create Elasticsearch Analyze Request) Esにリクエストを送信して結果の表示 インストールからリクエスト送信して結果が出てくるまでのデモです。\n1点LTのデモのときに話すのを忘れていましたが、.esanalyzeという拡張子のファイルであれば、このプラグインが入力値を見つけ出して、「Analyze text with analyzers」というコマンド送信用のリンクをエディタ画面に表示する機能があります。 ですので、パラメータ入力用のエディタを起動し、値を設定したあとにファイルをhoge.esanalyzeというような名前で保存してもらえれば、後日そのファイルを開くことでリクエストが再送できます。\nAzure Search版との機能の違い 先日のAzure Search向けのクライアントとの違いがいくつかあります。 ElasticsearchのAnalyze APIの方が多機能であるため、プラグインとしても違いがあったほうがいいかなと。\n入力がJSON形式 結果画面に詳細表示切り替えボタンを追加 現時点では対応していませんが、Analyze APIはカスタムのtokenizer、filter、char_filterの設定を入力として受け付けることが可能です。そのときに指定するのはJSON形式でtokenizerなどの設定を記述します。 今後、これらの対応をすることを考えると、入力全体をJSON形式で読み込めるほうがわかりやすいかなということで、入力はJSON形式で入力してもらうことを想定しました。\n結果画面に詳細表示切り替えボタンを追加したのは、2つの理由があります。1つはAzure SearchのAnalyze APIよりもTokenの情報としていくつか他の情報も存在するためです。複数のAnalyzerとの比較をする場合は、単語列だけを比較したいですが、Analyzer個別の詳細情報を見たい場合もあるので、切り替えができたほうがよいかなと。 2つ目の理由はまだ実装していませんが、explainパラメータの出力への対応のためです。 explainパラメータを指定すると、カスタムAnalyzerの場合に、Analyzerの設定にあるchar_filter、tokenizer、token_filterのそれぞれのステップでの単語列の出力が結果として返ってきます。この結果には標準の出力よりもさらに多くのtokenの情報(例えば、kuromojiだと品詞情報、読み、原型など)が追加されてきます。これらの表示を切り替えることができたほうがよいかと。\nこれらは、実はKibanaのプラグインとしてすでに実装済みになっています。 同等の機能は実装できるかなという目論見もあり、そちらに合わせた感じにしてあります。\n今後の対応 現時点では、Analyzer名の指定のみが可能となっています。Kibanaのプラグインと同程度の機能はGitHubのIssueとして登録してみました。\nexplainパラメータ対応 fieldパラメータ対応 custom analyzer対応 その他に、インデックス名やアナライザ名の自動補完みたいな機能があると便利かも?と妄想していたりします(実装が大変かもですが。。。)。Kibanaのプラグインの場合は、Mappingやインデックス名を調べるときに、KibanaのConsoleからチェックすればよかったのですが、このプラグイン単体だとそのあたりの情報の取得に他のツール(Kibanaだったり、REST API Clientだったり)を使わないといけないという問題点はあるかなぁと。\nあとは、結果画面がこのままで本当に見やすいかどうか?なども気になってはいます。\nまとめ まだまだ、作ってみたというレベルのプラグインです。 どのくらいの人に使ってもらえるかもわかりませんが、こんな機能あるといい?など要望があればリクエストいただければと。 Twitterで聞いていただいてもいいですし、GitHubのIssueとして登録していただいても構いません。 そもそもいらないなぁなんて意見でももちろん大歓迎です。フィードバックお待ちしてます!\n","date":1585102205,"dir":"post/2020/","id":"a7f0e85fcad4f5bc5ae5c18c10de4f9e","lang":"ja","lastmod":1585102205,"permalink":"https://blog.johtani.info/blog/2020/03/25/vsc-es-analzye-plugin/","publishdate":"2020-03-25T11:10:05+09:00","summary":"先日、Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)というブログを書きました。 このプラグインを作ってたタイミン","tags":["elasticsearch","visual studio code"],"title":"ElasticsearchのAnalyze APIのVisual Studio Codeのクライアントプラグイン"},{"contents":"自転車本を読み始めましたが、その前にRust the bookを読んだほうが良いかも?と知り合いと話をしていてなったので、先にRust the bookを読み始めてます。 コツコツ読むってのが苦手なので、知り合いと小規模オンライン読書会しながら読むことになりました(基本的になにか書きながら、使い方を調べるので、存在そのものを知らない記述や使用法などがあったりする)。\n日本語版Rust the book Rust the book 基本は日本語版を読んでいます。まずは1章から3章あたり。\n気になった点などを。自分用のメモなので、読みやすさとかは考えてないです(あとで自分が死ぬパターン?)。\n1章 rustfmt便利。\nCLionのRustプラグインでは、保存時にrustfmtするというオプションがある。デフォルトはオフ。\u0026ldquo;Run rustfmt on Save\u0026rdquo; cargoの--binオプション。意識してつけたことなかった=デフォルトだった。\nライブラリにするときは--lib 2章 「変数を値に束縛」という言い回しにまだ慣れない。 「代入」という言い方に慣れているから? ただ、エラーにはassignってあるな。\u0026ldquo;error[E0384]: cannot assign twice to immutable variable x\u0026rdquo; preludeというのがデフォルトで読み込まれる型が存在する場所。 .expect()により、Resultが評価済みになる マクロがまだ慣れない extern crate rand;が最新版だと要らなくなっている。 rand::Rngはgen_rangeのためにuseしている。CLionだとかってにuseを推測して追加してくれた。 matchはswitch文みたいな感じ。けど、defaultが必ず実行されるって感じではないな。 ただし、全て網羅しないと怒られるのが便利。 アームという呼び方が新鮮 単一の式のときは{}が省略できる ブロック{}のときは、終わりにカンマを入力するとrustfmtが除去する(最後の条件かどうかは関係ない)。 シャドーイングは面白い。 よく、hoge_strやhoge_intのような変数を書くので、ありがたい。 ただし、コードを読むときに少し混乱しそう? let ... matchで変数への束縛でmatchが使えるのは便利(これまで知らなかったので、変数宣言して条件つけて束縛する処理書いてた)。 シャドーイング? fn main() { let x = 5; let x = x + 1; let x = x * 2; println!(\u0026#34;The value of x is: {}\u0026#34;, x); } とか\nlet spaces = \u0026#34; \u0026#34;; let spaces = spaces.len(); みたいに、同一変数名を使い回せること。再代入ではない\n3章 constは型注釈が必須 100_000のような記述が便利(Javaもできるって言われてびっくりしたw) タプルの中身を一部だけ書き換え可能。(mutを指定すれば) tup.0 = 20;のような感じで。 配列は固定長でかつ、同一の型のものだけが入る 文末にセミコロンがない場合に四季になるというのはちょっと射にくいので辛いのでは。。。 自分は明示的にreturnを書きたくなる。が、returnだと動かない場合もある。。。 let ... ifのような記述もできる。 (1..4)はRange型 おまけ フィボナッチ数列計算してみろというのがまとめにあったので。こんな感じでいいのかな?\nfn calc_fibonacci(n: usize) -\u0026gt; usize { if n == 0 { return 0; } else if n==1 { return 1; } else { return calc_fibonacci(n-1) + calc_fibonacci(n-2); } } その他 知り合いと読みすすめると、人が不思議に思ったところが、自分が理解が曖昧だったことなどに気づけて便利です。\n","date":1584928642,"dir":"post/2020/","id":"48b5ab9805919736382ffea5a9554c02","lang":"ja","lastmod":1584928642,"permalink":"https://blog.johtani.info/blog/2020/03/23/start-reading-rust-the-book/","publishdate":"2020-03-23T10:57:22+09:00","summary":"自転車本を読み始めましたが、その前にRust the bookを読んだほうが良いかも?と知り合いと話をしていてなったので、先にRust the bookを読","tags":["rust","読書","rust-the-book"],"title":"Rust the Bookを読み始めた"},{"contents":"動機 Azure Cognitive Searchを検索エンジンに使っているお客さんを手伝っています。 そこで、検索の基本的な話をさせていただきました(もともとJJUGナイトセミナーでしゃべる予定だったスライドがベース)。\nで、Elasticsearchなどの転置インデックスを利用している検索エンジンで検索の基本的な動作がどうなっているかを理解するのに、 個人的には一番重要だと思っているのがAnalysis(Analyze)の機能です。 転置インデックスの単語の切り出し方がどうなっているかによって、望んだ単語でうまく検索できているかいないかなどがわかります。\nAzure Cognitive SearchもAnalyze TextというAPIを提供してくれています(内部的にはElasticsearchだし)。 APIはあるのですが、返ってくる結果はJSONです。また、他のAnalyzerの設定との違いなどをみたくなったりもします。 やはり、普段使っているツールなどで簡単にどういう単語が出てくるかがわかるとうれしんじゃないかなぁ?と。\nということで、最初はPythonでちょっとAPI呼び出して、カンマ区切りで出力するものを作ってみたのですが、GUIとかあると便利かなぁという話になりました。 最近、ブログ書いたりするのにVisual Studio Codeを使い始めているので、これなら使いやすいかなと。 ということで、Visual Studio Codeの拡張機能(プラグイン?)としてインストールできるツールを作ってみました。 Azure Cognitive Searchを使っている人向けなので、ニッチなツールですが。。。\n余談 Elastic Stack(Elasticsearch)向けにはKibanaのプラグインでAnalyze APIを可視化するツールを作ってます。 analyze-api-ui-pluginです。Elastic Stack、特にKibanaを必ず利用する方はこちらを使うと便利かもです。\n概要と機能 GitHub リポジトリ Visual Studio Marketplaceのページ Marketplaceに公開しているので、johtaniやAzure Search Analyze Clientなどで検索してもらえれば出てきてインストールができます。\n機能としては、以下の2つです。\nテンプレートから入力値設定用のドキュメントを作成(Untitled-1というドキュメントをエディタに新しく開く) Azure Cognitive SearchのAnalyze Text APIを呼び出して、結果をHTMLのテーブル形式で表示 入力値設定用のドキュメント作成 APIの呼び出しに必要な情報を記入してもらうのに、いくつか案を考えました。\nプラグインの設定に記入してもらう 環境変数とかを読み出す テキストとして保存したファイルを使う 設定や環境変数だと、異なる環境に接続したりするときに、わざわざ設定し直すのがめんどくさいかもと。 で、愛用していたREST API Clientを真似するのが良いかもという結論になり、.analyzeという拡張子のファイルから必要な項目を読み出して、APIを呼び出す形にしてあります。\nCommand Palette(左下の歯車マークもしくは、メニューのViewから開ける)からAzure Search Analyze Client: Create Azure Search Analyze Requestというコマンドを選びます。\nすると、以下のようなファイルがエディタに開きます。\nこれらの項目をまずは埋めていきます。 それぞれの値がどういったものかはGitHubのREADMEを御覧ください。\n入力値エラー(存在チェックしかしていない)がある場合は、ダイアログが表示されます。\n結果表示 値を入力したら、設定値と###の間に表示されているAnalyze text with analyzersというグレーの文字をクリックします。すると、APIにリクエストを送信し、結果が返ってきて、別のパネルとして表示されます。\n複数のAnalyzerを入力値に設定すると、それぞれがどのような区切り方をするかがわかります。 文字の下にある[0:2]は、その単語がもとの文章の何文字目から何文字目までに出現しているかというオフセットの表示になります。\nもし、Analyzer名の設定ミスなどで指定されたAnalyzerがない場合は、結果画面にエラーが表示されるようにしています。\n以上が簡単な機能の説明です。 簡単なと言いつつ、これだけしか機能がありませんが。\nVisual Studio Codeのプラグインの作り方 プラグイン自体の作り方に関してはVisual Studio CodeのGetting Startedがわかりやすかったです。 APIや機能が豊富なので、最初はちょっと戸惑いましたが、サンプルもGitHubで多数公開されています。\nあとは、REST API Clientを参考にさせていただきました。\nGetting Startedを一通り読むことで、なんとなくプラグインの作成からMarketplaceへのリリースまでが完了できました。 (TypeScriptに慣れていないのがあるので、プログラミング自体は手間取りましたが。。。)\n今後の対応? いまのところ、こんなところを考えていますが、こんな機能がほしい、バグが有るなどあれば、GitHubにIssueを上げていただければと(使う人すくないだろうけど)。\nいろいろなエラーに関する対応 Readmeに画像をアップ アイコン作成? 自動補完機能? まとめ Visual Studio Codeの拡張機能を作ってみました。 Yeomanによるプロジェクトテンプレートが用意されているので、とりあえず、Hello worldを作るのは簡単でした。 試行錯誤しつつTypeScriptを書いたので、TypeScriptっぽくないところなどもあるかもですが、誰かの役に立つツールになってくれれば良いなぁと。\n","date":1584582615,"dir":"post/2020/","id":"c9d257aba54475c20b3737ce7c779e55","lang":"ja","lastmod":1584582615,"permalink":"https://blog.johtani.info/blog/2020/03/19/azure-search-analyze-plugin/","publishdate":"2020-03-19T10:50:15+09:00","summary":"動機 Azure Cognitive Searchを検索エンジンに使っているお客さんを手伝っています。 そこで、検索の基本的な話をさせていただきました(もともとJJUGナイ","tags":["azure search","visual studio code"],"title":"Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)"},{"contents":"これまで\n実践Rust入門はじめました 実践Rust入門の3章を読んでるところ 3章終了 3章の終わりまで読み終えた。\nいきなり実践的なプログラムで少し面食らっていたが、ステップを追って所有権周りの話まで来たので、 なんとなくRustのいいところが理解できたような気がする。\nただ、最後のsplit_at_mutが実際には内部でどういう形に変換することによって、コンパイルエラーにならずに、 借用がうまく行っているのかあたりは、まだきちんと理解できていない。\nこれは、どの言語にも言えるんだけど、リファレンスをうまく読み解きながら、 自分がやりたい処理ができるかどうかを考えるのって結構むずかしいなぁと思う。\nbenchmark.rsはコピペして実行しただけなので、またあとで読み返してみるかな。\nということで、ここから先は、基本を勉強する感じで4章から読みつつ、なんかプログラムをまた書いてみるか。\n","date":1583140813,"dir":"post/2020/","id":"6f47cb314fd780c122adb8cc1f44f785","lang":"ja","lastmod":1583140813,"permalink":"https://blog.johtani.info/blog/2020/03/02/finish-bicycle-book-chap3/","publishdate":"2020-03-02T18:20:13+09:00","summary":"これまで 実践Rust入門はじめました 実践Rust入門の3章を読んでるところ 3章終了 3章の終わりまで読み終えた。 いきなり実践的なプログラムで少","tags":["rust","読書"],"title":"実践Rust入門の3章を読み終わった"},{"contents":"Kuromoji-CLI Rust初心者がRust製の日本語形態素解析器の開発を引き継いでみたという記事にありますが、LinderaというRust製の日本語形態素解析が出てきました。KuromojiのRustクローンみたいなものです。 で、作者の人とのチャットの中で、「MeCabみたいなKuromojiのCLIないですかね？誰か知りませんか？」という話になりました。\n自分は普段はKuromojiの確認をするのは、Elasticsearch関連もしくは、Azure Searchなどだったりするので、 当たり前のようにKibanaを立ち上げたり、REST APIを叩いてましたが、たしかにコマンドラインインタフェースあると便利かも? と思い、作ってみるかということに。\npicocli いま、JavaでかんたんなCLI作るとなったら何がおすすめ？\n\u0026mdash; Jun Ohtani (@johtani) February 26, 2020 で、いつものツイートです。で、picocliという返信がありました。 JavaでCLIのプログラムを書くのが簡単になりそうだと。 ドキュメントもしっかりしてます。サンプルも載ってるし。\nAnnotationで、コマンドの説明などパラメータ、オプションなどが記述でき、必須チェックなども可能です。\nまた、オプションの説明文に関しては、テンプレートを用いることで、取りうる値をEnumの値で出力してくれたりといった便利機能まで備わっていました。\nGraalVM また、GRAALVMとPICOCLIでJAVAのネイティブコマンドラインアプリを作ろうというスライドも教えてもらい、ネイティブコマンドまで作れるらしいと。 なんて便利なんでしょう!ってことで、こちらもチャレンジしてみました。 GraalVMがどんなものかはなんとなくは知ってたのですが、何者だろう?とツイートしたところ、これまた返信が。\nっ 資料はかなり古いので現行版と乖離はあるけど概念は変わってないので..https://t.co/KRQjhNdD9f\n\u0026mdash; たむたむ🏫 (@tamtam180) February 26, 2020 本当に、Twitter便利ですね。\nGraalVMがどんなものかもいただいた資料でサクッと理解できました。 ただ、picocliが実はものすごく良くできており、自分でインストールする必要も実はありませんでした。\ngradle-graalというGradleのプラグインと、 Picocli Code Generationを利用することで、 以下のコマンドを実行することで、ネイティブコマンドアプリが作成できました。\ngradle nativeImage build.gradleファイルに記述したのは、以下のような項目です。\npluginの利用 picocli-codegenをannotationProcessorとして呼び出し jarに関する記述(メインクラスと依存するJarを含める設定) ネイティブコマンドの名前とか(gradle-graalの設定) 辞書が読み込めなかった で、native imageを作って実行しましたが、Kuromojiが内包している辞書ファイルが読み込めませんでした。 どうやら、picocli-codegenの自動生成では対応できない、リソース関連設定が必要らしいと。\npicocli-godegenの設定を見ていて見つけたのが、other.resource.patternsというオプションでした。\nkuromoji-cliのbuild.gradleに、その設定を加えたら辞書が読み込めるようになりました。\nこの設定をどうやって書くのか?というのを探すのにちょっと時間がかかりました。Picocli作者のRemko Popmaさんのサンプルリポジトリに設定を利用したbuild.gradleがありました。サンプル本当にありがたいですね。\n完成 出来上がったのは、kuromoji-cliというリポジトリになります。 内部で利用しているのはAtilikaのKuromojiです。LuceneのKuromojiではないのでご注意を(LuceneのKuromojiで最初やってみたのですが、リフレクションなどが多用されてて、Single Imageにするのが手間がかかりそうだった)。 コマンドのポータビリティはそれほど無いと理解してる(あってる?)ので、利用してみたい方は、リポジトリをクローンしてからビルドしてみてください。\n参考資料 kuromoji Picocliドキュメント Getting Started GraalVM / GraalVM超入門 一体何モノなの? GraalVM入門編 / GraalVM for beginners まだ途中? ほかにもあると便利かも?という機能があればIssueやPRを上げてください。 とりあえず、頭にあるのは以下のとおりです。\nJSONの出力はまだ未対応 いろんな辞書をAtilikaのKuromojiはサポートしてるのでそのへんも対応してみる? ","date":1582858179,"dir":"post/2020/","id":"d710a073be2da219a388a150eb7b6b6a","lang":"ja","lastmod":1582858179,"permalink":"https://blog.johtani.info/blog/2020/02/28/kuromoji-cli/","publishdate":"2020-02-28T11:49:39+09:00","summary":"Kuromoji-CLI Rust初心者がRust製の日本語形態素解析器の開発を引き継いでみたという記事にありますが、LinderaというRust製の日本語形態素解","tags":["misc"],"title":"KuromojiのCLIコマンドとpicocliとGraalVM"},{"contents":"これまでのはこちら。読書メモなので、本と合わせて読んでいただくのが良いです。\n実践Rust入門はじめました 3章のクイックツアーを読んでます。 バイトニックソート自体の理解はちょっとおいておいて、読み進めています。 いくつか疑問に思ったことがあったので、またメモを。 まだ、3.5.7の手前ですが。\n疑問点 3.4.1のジェネリクス対応のテストケースの部分で、既存のu32用のテストケースの入力のデータ列にVec\u0026lt;u32\u0026gt;という型注釈をつけるのですが、 追加した文字列の入力データには注釈をここではつけないのはなんでなんだろう?ちなみに、なくても動いた。バージョンの違いとかあるのかしら?\n3.4.6のmatch文\nmatch文の引数?が*orderになっていたが、orderでも実行できた。引数にくるのが参照だから*が付いてるんだとも運だが、なくても動くのはコンパイラがよしなに解釈してくれてるからかな? 便利なツール Rust標準のツールの説明がいくつか3章で紹介されてて便利だったのでメモ。\nrustfmt フォーマッター。デフォルトでフォーマット機能が付いてるの便利ですね。言語として決まってると、プロジェクトごとに悩まなくていいってのがありますし。\nrustfmt ファイル名 という形で使えるみたい。 プロジェクトごとだとcargo fmtのほうが楽そうかな。\n標準ライブラリAPIドキュメントをブラウザで閲覧 rustup doc --std これでデフォルトブラウザでRustの公式ドキュメントが開きます。 しかもローカルファイルだからサクサク。検索バーもついてて便利です。\nエラーのドキュメントを閲覧 rustc --explain 308 コンパイル時にエラーが出たときに、error[E0308]のようにコンソールに出てきます。 ヒントも出てくるのですが、詳細が上記のコマンドで読めるみたいです。\n","date":1582443437,"dir":"post/2020/","id":"71cf83ae0f45e9ede3a3f979b9c74933","lang":"ja","lastmod":1582443437,"permalink":"https://blog.johtani.info/blog/2020/02/23/bicycle-book-chap3/","publishdate":"2020-02-23T16:37:17+09:00","summary":"これまでのはこちら。読書メモなので、本と合わせて読んでいただくのが良いです。 実践Rust入門はじめました 3章のクイックツアーを読んでます。 バ","tags":["rust","読書"],"title":"実践Rust入門の3章を読んでるところ"},{"contents":"もう2020年2月になってしまってますが、2019年に買って便利だったもの良かったものをいくつか記録に残しとこうかなと。\nBRAVIA KJ-55X9500G Amazon | ソニー SONY 49V型 液晶 テレビ ブラビア 4Kチューナー内蔵 テレビをやっと買い替えました。 前に使っていたのはプラズマディスプレイで、10年以上たったもので、パネルの一部が赤い残像が残ってたりしました。 もう流石にいいでしょうということで、買い替えたのがSonyのテレビです。 4Kのチューナーもついているし、アップコンバーターもついているので普通の地上波でもきれいです。 まぁ、10年前のテレビに比べればたくさんいいことがありますよねw\n新しいTV買って一番活躍してるのはYouTubeボタンだったりします。 最近はミュージックビデオがYouTubeにたくさんあるので、King Gnuなどの音楽流したりするのに便利です(テレビなのに)。 今は、プライムビデオボタンがより活用される感じになってきてます(テレビなのにw)。\nSodastream Amazon｜スピリット ワンタッチ ホワイト スターターキット ここ数年、炭酸を普段飲んでます。甘いもの飲まないようにって意味でも。。。 で、これを買うまでは、サントリーの天然水スパークリングレモンとかを、箱買いしてました。 が、まぁ、ペットボトルのゴミが半端ないんですよ。場所も取るし。\nソーダストリームのことは知ってたのですが、自分で炭酸の量を考えながら、入れないといけないので避けていました。\nが、今回購入したものは、水の入ったボトルを指して、ボタン一つで3段階の炭酸を入れることができるんです!買って本当に重宝してます。うちでは1Lのボトルを1本追加して、2本で運用してます。 家族はなっちゃんのオレンジとかを炭酸割りしたり、カルピスソーダ作ったりして楽しんでます。 ワンタッチということで、簡単に入れられるので家族も重宝してます。\nNature Remo + Chromecast Amazon | Nature スマートリモコン Nature Remo mini Remo-2W1 Google Home miniがキャンペーンで手に入ったので、ベッドルームの照明やクーラーの操作もできそうなのでNature Remoを導入しました。 Chromecastは余っている液晶モニターにつないで、スマホからキャストできるようにしたり、音楽聞けるようにしてあります。\nNature Remoは温度計などもついているので、部屋の温度に合わせてエアコンのオンオフなども可能で、 暑い夏にとても便利でした。寝る時間にはクーラーが入っているのですんなり寝れたりと。 スマホから電源オンオフできるのも便利ですね。 Chromecastはモニターにつなぎましたが、今は、Google Music Playのプレーヤーになってます。 (最近、家にあるCDを読み込んでGoogle Play Musicにアップしてる)。\nただ、それ以上のことには使えてないので、もうちょっと面白いことしてみないとなぁ。\nモニターアーム Amazon | HUANUO PC モニター アーム 液晶ディスプレイ アーム ガススプリング式 Amazon | グリーンハウス 液晶ディスプレイアーム 4軸 クランプ式 ディスプレイがふるくなってたので、4Kディスプレイに買い替えた(27インチで4万切るとかで安い。。。)んですが、Mac Book Pro 15インチ(今は16インチ)を使っていて、Macの画面がディスプレイにかぶるので モニターアームを買いました。 1つ目がガススプリング式のアームです。なのに、5000円を切ってるんですよ。おそるべし。 2つ目はクランプ式です。アームにしたものの特に動かすことはなく、高さを出したいだけってことがあるので、クランプ式のも使ってます(家ではディスプレイ2枚使ってる)。 コスパ最高です。\nAnker PowerCore 10000 PD Amazon | Anker PowerCore 10000 PD（10000mAh PD対応最小最軽量 大容量 モバイルバッテリー） Pixel 3にしてから、電池の持ちはよくはなってるんですが、もしもの時のためにモバイルバッテリーは話せないですよね。 PD対応なので、Pixel 3に急速充電ができるし、サイズもそれほどじゃまにならないサイズなので便利です。USB-Aもついているので、このあと紹介するイヤホンの充電ケーブルなんかも差し込めて大活躍です。\nサウンドピーツのイヤホン Amazon | SOUNDPEATS(サウンドピーツ) Q35HD ワイヤレス イヤホン 高音質・低遅延 IPX8防水 私が持ってるのはこの前のバージョンで、micro-USBで充電充電するタイプですが、こちらもコスパ最高です。 冬は防寒も兼ねてヘッドフォンをしているのですが、春から秋にかけてはこれまで、優先のイヤホンを使ってました。もしくは、Bluetoothのレシーバーに優先のイヤホンつけてました。電池切れたら、イヤホンさして使う感じで。 が、Pixel 3はイヤホンジャックがありません。ということで、ワイヤレスイヤホンに移行するかということで選んだのがこちらです。 世の中的には、完全ワイヤレスイヤホンが流行っていますが、片方無くなってしまうイメージしかわかなくて。。。 これが壊れても、完全ワイヤレスではなくつながったワイヤレスイヤホンを使うと思います。\nヘッドルーペ Amazon | Tumao ヘッドルーペ ルーペ メガネ LED付拡大鏡 眼鏡の上装着 メガネゴムバンド両用 5レンズ交換調節 プラモデルをちょいちょい作るんですが、もう年ですね。。。細かいところが見にくくて。 ガンダムのRG系のプラモデルだと、1/144なんですよ。小さいんですよ。見えないんですよ。。。\n完成しましたー！ pic.twitter.com/S9QTS4kJDI\n\u0026mdash; Jun Ohtani (@johtani) February 16, 2020 ということで、ヘッドルーペ導入してみました。 最初は、卓上に置けるルーペにしてみたんですが、自分がルーペがあるところに動かないといけないの結構つらくて。 これのおかげで、プラモデル作成に問題はなくなりました。老眼とは関係なく、ちょっと猫背になっちゃうのが今は悩みの種ですが。。。こたつで作ってるからなぁ。\nまとめ ということで、いくつかよかったものを紹介してみました。 今年はちゃんと年末に書こう。。。\n","date":1582272302,"dir":"post/2020/","id":"daa3fe935b0be9f31b6b362ad9e0d2d6","lang":"ja","lastmod":1582272302,"permalink":"https://blog.johtani.info/blog/2020/02/21/best-buy-2019/","publishdate":"2020-02-21T17:05:02+09:00","summary":"もう2020年2月になってしまってますが、2019年に買って便利だったもの良かったものをいくつか記録に残しとこうかなと。 BRAVIA KJ-55X9500G Amazon | ソニー SONY 49","tags":["買い物"],"title":"2019年に買ってよかったもの"},{"contents":"ブログ移行日記(その5)です。前回まではこちら\nブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4) 今回はこれまでとは異なる特殊な話です。\n最初にブログを書き始めたときに利用していたのがJugemのブログでした。 その後、Octopressに移行して、今年、Hugoに移行したという流れです。\nで、よくよく考えると、Jugemのブログも移行できるんじゃないか?となりました。 じゃあ、やってみるかと。なので、今回のブログは自分の備忘録です(興味のない人が大多数じゃないかな)。 一応、Pythonで書いたプログラムはGitHubに上がっています。文字列置換と正規表現のオンパレードです。\nJugemからExport まずは、移行元のデータが取り出せるかどうかを調べたところ、text形式もしくはXML形式でエクスポートが可能でした。\n変換処理が必要なはずなので、XMLでダウンロードします。 独自のXMLですが、記事ごとにXMLのタグ(\u0026lt;entry\u0026gt;)でまとめられているので、処理が楽です。\nXMLをMarkdownに \u0026lt;entry\u0026gt;タグの下に次のような項目が入っているので、抜き出します。\nヘッダ部 title - 記事タイトル author - 著者 category - タグ date - 投稿日付 description : 本文(先頭部分) sequel : 本文(つづき) titleからdateまでをHugoのMarkdownのヘッダ部分として出力します。 日付は形式が違うので合わせるように変換し、 titleは(Jugemより移植)という文字列を追加しました。\nまた、Hugoの個別のコンテンツにするためにそれぞれをMarkdownのファイルに変換しています。 ファイル名は変換後のdateの先頭10文字(yyyy-MM-dd)に-を付け加えて、 タイトルを追加しました。ホントは英語のファイル名にしたかったんですが、ちょっと手抜き。ファイル名に使用できないような文字は-に置換しています。\n本文 本文部分はもう少し複雑です。 まずは、descriptionとsequelから抜き出した文字列を結合します。\nで、内部の文字列に次のようなものがあるので、それぞれMarkdownに変換したりという処理を書いてます。\nHTMLのheadingタグをMarkdown形式に br、hr、del、strongなどのタグもMarkdown形式に aタグの処理 Amazonのアフィリエイトタグの処理 ul、olタグの処理 などです。 アフィリエイトタグは、数行に渡るの複数のHTMLタグで記述されているので、 ASINと商品タイトルだけを抜き出しています。 Hugoでアフィリエイトのリンクを作るために、hugo-amazon-jpという公開されているshortcodeを元に、カスタマイズしたものを使っています。 これ用に、必要なASINとタイトルを別ファイルに出力したりしています。\nまた、いくつか画像を使っている記事があったのですが、これが曲者でした。 XMLに入っているimgタグに画像へのURLがあるのですが、アクセスしても存在しないURL担っています。。。 ブログで公開している画像のファイル名に似たものがXMLに入っていたので、URLを組み直して、ダウンロードするという処理も書いています。\nあとは、昔ちょっと凝った書き方(spanタグで章みたいなことやってた)をしていた部分の処理を加えて完成です。\nまとめ 元のXMLを見たり、抜き出したファイルを見ながら、トライアンドエラーでプログラムを書きました。 なんとなく変換できたなかっていうところで、取り込んで公開しました。 まだ、全部の記事をチェックしてないですが、なんとなく移植できたので一旦これでいいかなと。 昔の記事を見たときにおかしい場所があったら手で治すつもりでいます。\nなんか、もうちょっとうまくプログラムかけた気もしますが、書き捨てのプログラムだと思うのでこんなもんかな。\n1点気になっているところは、コメントの部分です。 ブログにコメントをいただいていたのですが、その部分は移植できてないです。\nOctopresに移植していこうは、Disqusのサービスでコメント部分を提供しています。ここに移植するのも変な話だなぁと思っているので、本文にコメントを取り込む感じかなぁ？\nもともとのJugemのサイトもそのまままだ残してあるので、そのうち気が向いたらで。\n","date":1582254240,"dir":"post/2020/","id":"ef8a399c9679ce4e9710c7c6ecf8bcc7","lang":"ja","lastmod":1582254240,"permalink":"https://blog.johtani.info/blog/2020/02/21/import-jugem-posts/","publishdate":"2020-02-21T12:04:00+09:00","summary":"ブログ移行日記(その5)です。前回まではこちら ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4","tags":["hugo","ブログ"],"title":"ブログ移行日記(その5) - Jugemのブログを移行"},{"contents":"お手伝いしているお客さんがAzure Cognitive Searchを利用してます。 検索周り=Azure Cognitive Searchに関する手伝いをする形で入っており、 いくつか触った感触をブログにまとめてみようかと(お客さんからはOKいただいてます)。\nAzure Cognitive Searchとは？ 公式サイト 「AIを活用した」クラウド検索サービスと紹介されています。\n昔はAzure Searchと呼ばれていましたが、ここ最近はAzure Cognitive Searchと呼ばれているみたいです(Microsoft Igniteで発表された話がまとまっているページもあります)。 もともと、検索エンジンのSaaSサービス(キーワード検索、あいまい検索、オートサジェスト、スコアリングなどの機能)として作られていた部分に、データの登録パイプラインにCognitive Serviceの便利な機能を簡単に使えるようにしたものというイメージでしょうか。\nバックエンドはElasticsearchのはずです。変わってなければ。 昔、Elastic社主催のユーザーカンファレンスでMSの方が公演された資料が公開されていたりします。 ちなみに質問が多いのでしょうか、Azure Cognitive SearchとElasticsearchの違いはなんですか?というページがよくある質問のページに用意されていました。参考までに。\n今回はちょっとしたインデックスをつくって検索する部分を紹介してみようかと思います (Cognitiveなところは機会があればまた)。\n普通の使い方については、Azureのドキュメントなどを読んで頂く形にします。 ポータルと呼ばれるブラウザ上でAzureのサービスを触ることができる画面が用意されています。 ここで、簡単な操作(インデックス作成、フィールドの追加)\nAPIを使ってインデックス(特にAnalyzer)の設定をしたり、データをいれて、クエリしてみるというところをサクッと紹介しようと思います。\nインデックスの作り方 インデックス作成に関するドキュメントも用意されています。最初はポータル(GUI)でインデックスを作成する方法が紹介されています。 ですが、今回はn-gram(n=2)のAnalyzerを利用したかったので、GUIではなくAPIでインデックスを作成しました。 カスタムアナライザーを利用する場合、REST APIを利用しなければ行けないということになっています。 n-gramのAnalyzerを含むインデックス生成のREST APIは以下のとおりです。こちらを実行することで、インデックスが作成されます(JSONの記述ミスなどがある場合はエラーが返ってきます)。\n@host = \u0026lt;サーチのサービス名\u0026gt;.search.windows.net @api-key = \u0026lt;APIキー\u0026gt; ### POST https://{{host}}/indexes/?api-version=2019-05-06 Content-Type: application/json api-key: {{api-key}} { \u0026#34;name\u0026#34;:\u0026#34;ngram-test\u0026#34;, \u0026#34;fields\u0026#34;:[ { \u0026#34;name\u0026#34;:\u0026#34;id\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;Edm.String\u0026#34;, \u0026#34;key\u0026#34;:true, \u0026#34;searchable\u0026#34;:false }, { \u0026#34;name\u0026#34;:\u0026#34;ngram\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;Edm.String\u0026#34;, \u0026#34;searchable\u0026#34;:true, \u0026#34;analyzer\u0026#34;:\u0026#34;bi_gram_analyzer\u0026#34; } ], \u0026#34;analyzers\u0026#34;:[ { \u0026#34;name\u0026#34;:\u0026#34;bi_gram_analyzer\u0026#34;, \u0026#34;@odata.type\u0026#34;:\u0026#34;#Microsoft.Azure.Search.CustomAnalyzer\u0026#34;, \u0026#34;tokenizer\u0026#34;:\u0026#34;bi_gram_tokenizer\u0026#34;, \u0026#34;tokenFilters\u0026#34;:[ \u0026#34;lowercase\u0026#34; ] } ], \u0026#34;tokenizers\u0026#34;:[ { \u0026#34;name\u0026#34;:\u0026#34;bi_gram_tokenizer\u0026#34;, \u0026#34;@odata.type\u0026#34;:\u0026#34;#Microsoft.Azure.Search.NGramTokenizer\u0026#34;, \u0026#34;minGram\u0026#34;:2, \u0026#34;maxGram\u0026#34;:2 } ] } なんだかどこかで見たことのある記述のようなそうでないような。。。 Analyzerは、charFilters(0以上複数可)、tokenizer(1つ必須)、tokenFilters(0以上複数可)から構成されます。 フィールドで指定するのはAnalyzerなので、まずanalyzersにCustomAnalyzerの設定を行います。 名前はbi_gram_analyzerにしました(好きに付けてください)。 tokenizerにはこのあと設定するtokenizerの名前を設定します。ここでは、bi_gram_tokenizerという名前にしています。 また、大文字小文字を気にせずに検索したいため、tokenFiltersにlowercaseを指定しています。こちらはすでに定義済みのため、定義済みの名前で呼び出すだけで使用できます。\n次が、bi_gram_tokenizerの設定です。 n=2としたいので、tokenizers配下にTokenizerの設定をします。 @odata.type\u0026quot;:\u0026quot;#Microsoft.Azure.Search.NGramTokenizerがTokenizerの名前です(ちょっと独特な名前ですね)。 Tokenizerごとにオプションがあり、NGramTokenizerの場合は、minGram、maxGramがオプションに相当します。 今回は2文字ごとにトークンを出力したいので、minとmaxをそれぞれ2としています。\nこれで、あとは、フィールドでanalyzerという設定にbi_gram_analyzerを指定すればそのフィールドはbi_gram_analyzerを使用してアナライズされるようになります(このへんはElasticsearchといっしょですね)。 フィールドは文字列を扱うので、Edm.Stringというタイプにしてあります。データ型については、フィールドコレクションとフィールド属性というドキュメントを参考に設定しましょう。\n閑話休題 - REST Client Exstension for Visual Studio Code なお、今回のサンプルはREST Clinet Extention for Visual Studio Codeを利用する想定の記述になっています。\nVisual Studio Codeで.restもしくは.httpというファイルに以下のAPIを記述すると、Send RequestというリンクがURLの上部に出てくるような拡張機能です。REST APIにリクエストするときに便利なツールになっています。 変数も使えるので、APIのキーやURLの一部をこのように共通化して、他の環境でも使いやすくできるのは素晴らしいなと。\nアナライザーの挙動の確認 設定したAnalyzerがきちんと機能しているかというのを確認する必要があります。 入力した文字列がきちんと想定している単語として切り出されて、転置インデックスの見出し語に使われるかというのが重要になるからです。\nAzure Cognitive Searchでもアナライザーのテスト用APIが用意されています。 使い方はこちら。 APIの仕様のページもありました。 「アナライザーの挙動はどんな感じ？」という文字列が、作成したインデックスの定義したアナライザーbi_gram_analyzerにより、 どのように分割されるかを確認するAPIの呼び出しは以下のとおりです。\n### POST https://{{host}}/indexes/ngram-test/analyze?api-version=2019-05-06 Content-Type: application/json api-key: {{api-key}} { \u0026#34;analyzer\u0026#34;:\u0026#34;bi_gram_analyzer\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;アナライザーの挙動はどんな感じ？\u0026#34; } レスポンスはこんな形です。ヘッダ部分は省略してあります。\n{ \u0026#34;@odata.context\u0026#34;: \u0026#34;https://{{host}}.search.windows.net/$metadata#Microsoft.Azure.Search.V2019_05_06.AnalyzeResult\u0026#34;, \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;アナ\u0026#34;, \u0026#34;startOffset\u0026#34;: 0, \u0026#34;endOffset\u0026#34;: 2, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;ナラ\u0026#34;, \u0026#34;startOffset\u0026#34;: 1, \u0026#34;endOffset\u0026#34;: 3, \u0026#34;position\u0026#34;: 1 }, { \u0026#34;token\u0026#34;: \u0026#34;ライ\u0026#34;, \u0026#34;startOffset\u0026#34;: 2, \u0026#34;endOffset\u0026#34;: 4, \u0026#34;position\u0026#34;: 2 }, { \u0026#34;token\u0026#34;: \u0026#34;イザ\u0026#34;, \u0026#34;startOffset\u0026#34;: 3, \u0026#34;endOffset\u0026#34;: 5, \u0026#34;position\u0026#34;: 3 }, { \u0026#34;token\u0026#34;: \u0026#34;ザー\u0026#34;, \u0026#34;startOffset\u0026#34;: 4, \u0026#34;endOffset\u0026#34;: 6, \u0026#34;position\u0026#34;: 4 }, { \u0026#34;token\u0026#34;: \u0026#34;ーの\u0026#34;, \u0026#34;startOffset\u0026#34;: 5, \u0026#34;endOffset\u0026#34;: 7, \u0026#34;position\u0026#34;: 5 }, { \u0026#34;token\u0026#34;: \u0026#34;の挙\u0026#34;, \u0026#34;startOffset\u0026#34;: 6, \u0026#34;endOffset\u0026#34;: 8, \u0026#34;position\u0026#34;: 6 }, { \u0026#34;token\u0026#34;: \u0026#34;挙動\u0026#34;, \u0026#34;startOffset\u0026#34;: 7, \u0026#34;endOffset\u0026#34;: 9, \u0026#34;position\u0026#34;: 7 }, { \u0026#34;token\u0026#34;: \u0026#34;動は\u0026#34;, \u0026#34;startOffset\u0026#34;: 8, \u0026#34;endOffset\u0026#34;: 10, \u0026#34;position\u0026#34;: 8 }, { \u0026#34;token\u0026#34;: \u0026#34;はど\u0026#34;, \u0026#34;startOffset\u0026#34;: 9, \u0026#34;endOffset\u0026#34;: 11, \u0026#34;position\u0026#34;: 9 }, { \u0026#34;token\u0026#34;: \u0026#34;どん\u0026#34;, \u0026#34;startOffset\u0026#34;: 10, \u0026#34;endOffset\u0026#34;: 12, \u0026#34;position\u0026#34;: 10 }, { \u0026#34;token\u0026#34;: \u0026#34;んな\u0026#34;, \u0026#34;startOffset\u0026#34;: 11, \u0026#34;endOffset\u0026#34;: 13, \u0026#34;position\u0026#34;: 11 }, { \u0026#34;token\u0026#34;: \u0026#34;な感\u0026#34;, \u0026#34;startOffset\u0026#34;: 12, \u0026#34;endOffset\u0026#34;: 14, \u0026#34;position\u0026#34;: 12 }, { \u0026#34;token\u0026#34;: \u0026#34;感じ\u0026#34;, \u0026#34;startOffset\u0026#34;: 13, \u0026#34;endOffset\u0026#34;: 15, \u0026#34;position\u0026#34;: 13 }, { \u0026#34;token\u0026#34;: \u0026#34;じ？\u0026#34;, \u0026#34;startOffset\u0026#34;: 14, \u0026#34;endOffset\u0026#34;: 16, \u0026#34;position\u0026#34;: 14 } ] } このAzure SearchのAnalyze API、使用できるオプションはすくないですが、ElasticsearchのAnalyze APIと似ています。\nデータの登録の仕方 データ登録もAPIからできます(あたりまえですね)。 APIは1件ずつではなく、バルクで登録できる形で提供されています。\nサンプルとしては、以下のような形です。 @search.actionの部分(searchがあるとわかりにくい気がするけど。。。)が、ドキュメントの登録、更新、削除の命令を書き込むところになります。 今回は単純に登録するだけなので、uploadを指定しました。 ほかにもいくつかアクションが用意されています。用途に合わせて指定する感じになります。 id、ngramはそれぞれフィールド名です。ドキュメントに登録したい値を記述します。\nPOST https://{{host}}/indexes/ngram-test/docs/index?api-version=2019-05-06 Content-Type: application/json api-key: {{api-key}} { \u0026#34;value\u0026#34;: [ { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;ngram\u0026#34;: \u0026#34;新しいAzure Searchの使い方\u0026#34; }, { \u0026#34;@search.action\u0026#34;: \u0026#34;upload\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;ngram\u0026#34;: \u0026#34;Elasticsearchの紹介\u0026#34; } ] } 検索クエリ 最後は検索クエリです。 検索クエリはいくつかのオプションがあります。 ざっくりだと、queryTypeがsimpleとfullという2種類が用意されており、ちょっとした検索を作る場合はsimpleで事足りそうという感じです。 入力された単語(スペース区切りで複数扱い)をフィールド(複数可)に対していずれかの単語を含むもしくは、すべての単語を含むという検索に行くというパターンですね。 このときの、「いずれか」か「すべて」の設定がsearchModeというパラメータになります。 anyの場合、Googleの検索と同様に、どれかの単語が入っているドキュメントが対象に、allの場合すべての単語が含まれるドキュメントだけがたいしょうになるといった形です。\nqueryType=fullの場合はLuceneの構文でクエリがかけます。ElasticsearchのQuery String Queryみたいな形です。\n簡単なサンプルは次のような感じです。このサンプル\nPOST https://{{host}}/indexes/multi-field-test/docs/search?api-version=2019-05-06 Content-Type: application/json api-key: {{api-key}} { \u0026#34;search\u0026#34;: \u0026#39;ngram:\u0026#34;使い方\u0026#34; ngram:\u0026#34;紹介\u0026#34;\u0026#39;, \u0026#34;queryType\u0026#34;: \u0026#34;full\u0026#34;, \u0026#34;searchMode\u0026#34;: \u0026#34;any\u0026#34; } すこしだけクエリの補足を。 searchに入力された単語をダブルクォートで囲んでいます。これは、「使い方」という文字がbi_gram_analyzerにより「使い」「い方」に 分割されるのですが、必ずこの順序で出現したものだけを検索対象にしたい(フレーズ検索)という意味になります(*bi_*gramなので、「紹介」に関してはダブルクォートは厳密には必要ないです)。\nあと、レスポンスは今回記載していませんが、@search.scoreという項目で、スコアが返ってきます。 デフォルトのスコア計算には何を使ってるんだろう?ドキュメントにはTF-IDFとの記述があるのですが。。。カスタマイズもできそうです。\n少しオモシロイと思ったのは、スキーマ(インデックスの設定)に定義されているが、ドキュメントとしては登録していない項目についても、 Azure Cognitive Searchはドキュメントのフィールドがnullという形で返ってくるようでした。 そもそもフィールドが存在しないドキュメントとフィールドの値がnullのものの違いは無いようです。\n簡単ですが、インデックスの設定、ドキュメントの登録、検索の方法の紹介でした。\nちょっと触った感想 一番売りである、Cognitiveの部分はまだ触っていないです、すみません(こっちが売りな気もするんですが)。 検索エンジンの部分としては、Elasticsearchを知っていると、「あー、そんな感じね」という気持ちになれるサービスです。 個々のAPIやデータの形式は異なるので、きちんとAPIのリファレンスなどを確認しつつという形になりますが、なんとなくこういうAPIなどがありそうだな?と予測しつつ使えるかなと。 内部的にはElasticsearchだと思いますが、独自のAPIでラップされているおかげで、バージョンの違いなどを意識せずに使えるのではないかと思います。\nまた、今回は紹介していませんが、マイクロソフト独自の各言語のアナライザー(日本語も含む)があります。 Luceneのアナライザーとマイクロソフトのアナライザーのどちらも利用できますので、ここの違いを見てみるのも面白そうだなと思いました。 緯度経度を利用した検索、フィルター検索(スコア計算対象にならない)、ファセット、スコア調整の機能なども備えているようです。\nなんにせよ、利用する場合やドキュメントを読む場合に、全文検索の仕組みをなんとなく知っておいたほうが読みやすいんじゃないかなというのが感想です。\nここ数年はElasticsearchがメインでほかはほぼ触っていない状況だったので新しい製品に触れるのは面白いですね。 時間があったら、アナライザーの違いなども調べてみたいなと思います。\n","date":1582080481,"dir":"post/2020/","id":"c3053579ae25e2fb9b967076a06373af","lang":"ja","lastmod":1582080481,"permalink":"https://blog.johtani.info/blog/2020/02/19/research-azure-cognitive-search/","publishdate":"2020-02-19T11:48:01+09:00","summary":"お手伝いしているお客さんがAzure Cognitive Searchを利用してます。 検索周り=Azure Cognitive Searchに関する手伝いをする形で入っており、 いく","tags":["azure search"],"title":"Azure Cognitive Searchでインデックスを作って検索"},{"contents":"また、ツイートから始まるお話です。 まだまだ、検索システムってどんなものかを勉強したいしということで、こんなのをツイートしてました。\n「検索システム探訪」みたいな名前がいいかな? https://t.co/sG7BDdGI9h\n\u0026mdash; Jun Ohtani (@johtani) February 6, 2020 検索について知り合いとお茶をしながら話をしていて、こういう話を聞くの面白いなぁと思ったので。 どんなことを個人的には聞きたいかな?というのをまとめといたほうがいいかと思いブログを書いています。 こんなことも面白そうだよね?\nどんなこと聞きたいかな? いまのところ思いついた内容はこんな感じかな? こんなのも聞くと面白そうだよね?などありましたら、コメント欄に書いてもらえればと。\n利用しているシステム・サービスは? 構成やどこのサービスなのか？ 検索ユーザーはどんな人？ ユーザーの種類 ユーザーの検索ニーズ 検索対象データはどんなもの？ データ件数はどのくらい？ 属性、項目がどのくらいあるか？ 検索結果として出したいものは？ ソートはどんなものがあるの？ ランキングで重要なものは？ UI/UXはどんな感じ? ハイライト、ソート、ファセット(Aggs) キーワードサジェスト、オートコンプリート 検索システムの監視(オブザバビリティ??) ビジネス的な指標 クエリログ、クリック(ユーザーに関する情報) システムメトリクス 困っていることは？ ランキング クエリ 検索システム分析 第1回やりました。 ちなみに、最初のツイートに対して、すぐに返事をくれた方がいました。\nうちでよければご説明します！\n\u0026mdash; Kizashi （令和もRailsエンジニア募集中） (@kizashi1122) February 6, 2020 Twitter本当にありがとうございますという感じです。\nで、早速話を聞かせていただきました。大阪の方だったので、テレカンでやらせていただきました。 移動時間とか気にせずにできるので、テレカン形式いいですよね。\n内容は、非常に面白かったです。 使ってるシステムについて、どんなところで、どのようなように検索エンジンをつかっているのか、 どんなことで困っているのかなどをお聞きすることができました。\n2020/02/13 追記 対応していただいたIngageの永田さんから、内容を公開しても良いという承諾をいただいたので、メモを公開します。\nサービス : Re:lation 問い合わせメールなどのチームで対応する対応 利用している検索エンジン Elasticsearch (AWS Es) ノード数 8 - 3 master + 5 data データ データ数 : 約1億5千万 親子関係 : チケット - メール(=1ドキュメント) - コメント 画面としてはチケットの一覧=aggsでチケットIDの一覧を生成してリスト表示 インデックス数 : 5 = テナントごとに振り分けしてる。 8シャード - スケールアウトした場合も対応できるので。 PostgreSQLにマスターは保存 データの単位はメール。コメントはtextの配列でメールに保存されている。 EsはIDの一覧を返す。ただし、チケットのIDの一覧 機能 ハイライト Esではなく独自実装。 クエリ n-gramでやってる = kuromoji使ってない min=1, max=2 悩み事 EBS上だったものをローカルにしたので速くなった。 期間が長いと、検索結果一覧の表示が遅い aggsが遅いのかな? 検索結果一覧はチケットが持っているメールの日付の降順。結果一覧はチケットの一覧。 詳細検索はDB、左のステータスもファセットも現在はDBから生成 Es使ったほうが早いかも? マルチテナントのつらさ 検索ログ 独自ログはとっていない = アプリのログから判別 今後 アドレス帳検索 お誘いお待ちしております! 今後もこれやっていきたいなぁ。話してもいいよ!という方がいらっしゃいましたら、@johtaniまでDMもしくはメンションをください。お待ちしております!\n","date":1581344427,"dir":"post/2020/","id":"7b080dc43fce482af14de61c6ab819a5","lang":"ja","lastmod":1581344427,"permalink":"https://blog.johtani.info/blog/2020/02/10/explore-search-system/","publishdate":"2020-02-10T23:20:27+09:00","summary":"また、ツイートから始まるお話です。 まだまだ、検索システムってどんなものかを勉強したいしということで、こんなのをツイートしてました。 「検索シス","tags":["検索システム探訪"],"title":"「検索システム探訪」したいな=\u003eやりました"},{"contents":"年末、何種類かのボードゲームを家族で楽しみました。 家族の感想を交えて簡単に紹介しようかと思います。 家族や知人でボードゲームを購入するときの参考に参考にしてもらえたらと。 それぞれのゲームの詳細については、それぞれWikipediaなどのリンクを張っておくので、参考にしていただけたらと。 結構有名なボードゲームが多いのかな?\nカタン Amazon | カタン スタンダード版 | ボードゲーム | おもちゃ 簡単な紹介 プレーヤー数 : 3-4名 (拡張版を追加すると5-6名でもプレイできるみたい) 対象年齢 : 10歳以上 種類 : 対戦型 紹介 : 大航海時代に発見された無人島を複数の入植者たちが開拓していき、もっとも繁栄したプレイヤーが勝利するという内容のボードゲーム(Wikipediaより)。 特徴 : 5種類の資源を元に、道を作ったり、開拓地や都市を作ったり、サイコロを使った運も必要ですが、プレーヤー同士で手持ちの資源を交渉することも可能なゲームです。 感想 最初の配置が重要な気がします。資源の組み合わせによってできることが変わってくるので、何をやりたいかというのを元に考えて配置するのが重要そうです(私はまだうまくできてませんがw)。 プレーヤー同士の交渉も1つの手段なので、会話しながら、自然と交渉術も身についてきそうです。 戦略だけじゃなくサイコロを使った運もあるので、子供と大人が混ざっていても偏った結果にはならないです。 自分の道や町が発展していくのも楽しみの1つです。 お化け屋敷の宝石ハンター Amazon | お化け屋敷の宝石ハンター FBH20 | おもちゃ | おもちゃ 簡単な紹介 プレーヤー数 : 2-4名 対象年齢 : 8歳以上 種類 : 協力型 紹介 : お化け屋敷がおばけでいっぱいになる前に、みんなで協力して８つの宝石をみつけて、屋敷から脱出しよう！(メーカーホームページより)。 特徴 : 対戦ではなくプレーヤーみんなで協力してやるボードゲーム。おばけのフィギュアも可愛いです。サイコロを利用した運もありますが、みんなでどういった戦略で宝石を取り出すかなど会話も進むゲームです。上級編という難しめのルールも用意されているので、ハラハラ・ドキドキしながらプレイできます。 感想 負けて悔しくなったり機嫌が悪くなることがないのがいいですね。 普通のルールだと少し物足りない感じですが、上級編のルールはより、みんなで協力する必要が出てきます。 また、上級編のルールは絶妙な難易度で、もう一度やりたいと思わせるのが良い仕組みです。 ラビリンス Amazon | ラビリンス (Labyrinth) ボードゲーム | ボードゲーム | おもちゃ 簡単な紹介 プレーヤー数 : 1-4名 対象年齢 : 8歳以上 種類 : 対戦型 紹介 : 動く迷路で宝探し！通路が動く不思議な迷路の中に、「宝物」や「奇妙な生き物」が隠されています。プレイヤーはこれらを集めてこなければなりませんが、そのためには、巧みに迷路を動かさなければなりません。(メーカーホームページより)。 特徴 : サイコロがないボードゲームです。先を予測しながら人のじゃまをしつつ、自分に有利に進めていくゲームです。プレーヤー個別に難易度を変えられる仕組みがあります(子供だけに有利なルール設定が可能)。 感想 子供ルールがあるので、1度のゲームで別々の難易度が設定できるのがいいです。左右盲の人には子供ルールとかもありです。 ラビリンスが得意な人は地図を読むのが得意な人だと思います。 頭も使うけど、自分が望んだ道ができた時の快感があります。 モノポリー Amazon | ハズブロ ボードゲーム モノポリー クラシック C1009 正規品 | ボードゲーム | おもちゃ 簡単な紹介 プレーヤー数 : 2-6名 対象年齢 : 8歳以上 種類 : 対戦型 紹介 : プレイヤーは双六の要領で盤上を周回しながら他プレイヤーと盤上の不動産を取引することにより同一グループを揃え、家やホテルを建設することで他のプレイヤーから高額なレンタル料を徴収して自らの資産を増やし、最終的に他のプレイヤーを全て破産させることを目的とする。モノポリーとは英語で「独占」を意味する。(Wikipediaより)。 特徴 : 資本主義とは?みたいなのを体験できるゲーム。すごろく型ですが、ゴールがあるわけではなく、決着がつくまでぐるぐる回る感じです。 感想 資本主義を象徴しているゲーム展開。真剣勝負間違いなしです。 負けると途中退場ってのがちょっとつらいです。。。 カタンとは違った感じの交渉術になります。 コマが色んな種類があってかわいいです。 パンデミック Amazon | パンデミック:新たなる試練 (Pandemic) 日本語版 ボードゲーム | ボードゲーム | おもちゃ 簡単な紹介 プレーヤー数 : 2-4名 対象年齢 : 8歳以上 種類 : 協力型 紹介 : 『パンデミック』（Pandemic）は、プレイヤーが新型ウイルス対策チームの一員となり、協力しあい感染症の世界的流行（パンデミック）に立ち向かうというボードゲームである。(Wikipediaより)。 特徴 : プレーヤーが個別のロール(役割)を持っており、よりみんなで協力をしないとウイルスに打ち勝てない感じです。 感想 ルールが結構複雑で、理解しながらだと少し時間かかりました。 8歳以上になっていますが、少しむずかしい印象でした。 戦略、戦術が問われる形のゲームなのでしっかり理解すると楽しそう。 世界地図上で、ウイルスと戦っていく感じは臨場感があって面白いです。 ナインタイル Amazon | ナインタイル | カードゲーム・トランプ | おもちゃ 簡単な紹介 プレーヤー数 : 2-4名 対象年齢 : 6歳以上 種類 : スピード対戦型 紹介 : 「ナインタイル」の基本ルールは、それぞれの手元にある、９枚のタイルを自由に動かしたりひっくり返したりして、誰よりも早くお題どおりに並べるだけ。(公式サイトより)。 特徴 : ボードゲームというか、カードゲーム。ルールは簡単ですが、記憶力と素早さが重要です。 感想 脳トレに良さそう(子供に勝てませんでした。。。)。 瞬発力+記憶力が重要。 デザインがきれい じゃあ、家族の人気は? ラビリンス、カタン、モノポリーあたりが人気です。 ゲーム性もありますが、デザインとしてもきれいなものが多かったです。\nテレビゲームも面白いですが、ワイワイ喋りながらボードゲームをやるのも楽しかったです。 今回紹介したボードゲームはどれもある程度ルールを理解するところから始めないといけないですが、理解力や説明力なども必要になってくるので色んな楽しみがあるかなと思います。\n","date":1580558694,"dir":"post/2020/","id":"90f9355781403b92e844de8568863ae8","lang":"ja","lastmod":1580558694,"permalink":"https://blog.johtani.info/blog/2020/02/01/intro-board-game/","publishdate":"2020-02-01T21:04:54+09:00","summary":"年末、何種類かのボードゲームを家族で楽しみました。 家族の感想を交えて簡単に紹介しようかと思います。 家族や知人でボードゲームを購入するときの参","tags":["ゲーム"],"title":"ボードゲーム紹介"},{"contents":"実践Rust入門という本を買っていた(去年の7月だ。。。)のですが、積んであったので、時間を作って読み始めようかと。\n実践Rust入門[言語仕様から開発手法まで] | κeen, 河野 達也, 小松 礼人 |本 | 通販 | Amazon 経緯 もともとは、言語処理100本ノックはじめました(Rust)という感じで、触っていたのですが、場当たり的にやってても時間を持っていかれるだけだなということに気づいたのが最初です。\n今年の目標は、覚えられなので、ちょっとずつでもアウトプットしていこうってのもあり、 読書記録をつけつつ、読んでいこうかなぁと。\nどこまで読んだ? 2章の2-2-5までです。 前回、Rustの環境はセットアップしていたのですが、新PCに切り替わったので、rustupからはじめました。\nrustup rustupではデフォルト設定のままではなく、PATH変数の書き換えだけはしない形でインストールを行いました。\nPATH変数は.zshrcファイルで変更したかったためです(rustupコマンドに変更して貰う場合は.profileなどのファイルが変更されそうだったため)。\nインストールが終わったあとに.zshrcに以下の行を追加しました。\n### For Rust env source $HOME/.cargo/env 疑問点 ここまで読んだ疑問点です。\ncargo new helloしたあとにmain.rsに以下のmain()関数が出来上がっている!? fn main() { println!(\u0026#34;Hello, world!\u0026#34;); } 驚きましたが、cargo new hogeってやっても、おなじmain.rsができてました。デフォルトで出来上がるんですね。どんな超能力!?と思ってしまいましたw\ncargo new helloして出来上がったCargo.tomlに著者名が入力されていた。 authors = [\u0026#34;Jun Ohtani \u0026lt;メアド\u0026gt;\u0026#34;] なんで?と思いました。まだ解明してないです。 本を読んでいけばわかるかな?\n予想:gitの設定(~/.gitconfig)に氏名とメアドが設定されているので、これを利用しているのかな? ","date":1580475492,"dir":"post/2020/","id":"7fcfaa8dd34dbd508f19e8ca0fcfda0f","lang":"ja","lastmod":1580475492,"permalink":"https://blog.johtani.info/blog/2020/01/31/start-reading-bicycle-book/","publishdate":"2020-01-31T21:58:12+09:00","summary":"実践Rust入門という本を買っていた(去年の7月だ。。。)のですが、積んであったので、時間を作って読み始めようかと。 実践Rust入門[言語仕","tags":["rust","読書"],"title":"実践Rust入門はじめました"},{"contents":"12月に退職しますブログを書きましたが、その後どうなったのか?という話をしてないなと思ったので、一応現在の状況を書き留めておこううかと。\n結論 実際にはフリーランスとして働き始めてます。検索周りをお手伝いするお仕事を。読解いとこあれば所属するつもりでもいるし。\n\u0026mdash; Jun Ohtani (@johtani) January 27, 2020 フリーランスとして最初の仕事はElasticsearchではなく、Azure Cognitive Searchの支援だったりします。Esで困ってる方の手伝いもしますので、興味ある方はDMください。\n\u0026mdash; Jun Ohtani (@johtani) January 31, 2020 2020年1月24日が、正式なElasticの退職日でした(有給休暇消化してた)。 で、現在のステータスはこのツイートです。\n現在の心境 どこかに就職してガッツリ検索もやりたいし、いろんな会社の検索やElastic Stackに関するお手伝いをするのにも興味があるし、どちらにも興味がある状況です。まぁ、検索に興味が尽きないというのだけは決まってますかね。\n悩んでいるところに、幸いにもAzure Search周りで手伝ってほしいという話が舞い込んできたので、フリーランスとしてお手伝いをさせていただいてます(現時点で、半稼働で、が3月末まで)。\nElastic Stackなどの知見もあるのでのお手伝いをするというのもありかなぁと。お仕事発注してもいいな?という方があれば、TwitterのDMなど、連絡をいただければと。\n現在の状況でした。\n副業ができる会社に就職するのがどっちもできていいのかも?\n","date":1580470659,"dir":"post/2020/","id":"c61a5bda3f1667498626ae52ad0362e0","lang":"ja","lastmod":1580470659,"permalink":"https://blog.johtani.info/blog/2020/01/31/start-freelance/","publishdate":"2020-01-31T20:37:39+09:00","summary":"12月に退職しますブログを書きましたが、その後どうなったのか?という話をしてないなと思ったので、一応現在の状況を書き留めておこううかと。 結論","tags":["転職"],"title":"フリーランスはじめました(仮)"},{"contents":"ブログ移行日記(その4)です。その他の記事はこちら。\nブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その5) 前回までで、なんとなく移行は終わってます。 今回はテーマで使えるようになっているブログの検索機能の導入の話です。\n検索サービスはAlgoliaを利用します。 OctopressのころはElastic社のサービスであるElastic Site Searchの機能を利用して、クローリングしてから検索できるようにしていましたが、Hugoで導入できるモジュール?があったので、今回からこちらに移行しました。\n参考記事 Clean White ThemeのREADME(Algoliaの設定方法) 参考ブログ:hugoで作ったblogにalgoliaで全文検索機能を追加する Algoliaとは? 検索のas-a-serviceをやっている会社です。Wikipediaによると本社はサンフランシスコにあるみたいですね(フランスの会社のイメージでした。起業された方がフランス出身だからかなぁ?)。 クラウドで検索インデックスを保持でき、API経由で検索したり登録したりできる感じのサービスです。内部で使われているのはOSSではない独自の検索エンジンです。\nクラウドで提供されているサービスなのでサクッと検索を使い始めることができるのがいい点ですね。 また、小さな非商用のプロジェクトにフリーで利用できるプランも提供されているようです(2020年1月現在)。\nAlgoliaのサービス登録からインデックス作成 私が利用しているテーマで設定する方法の記載があったので手順の通りにやってみました。 大きく2つの作業(Algolia側とHugo側)が必要です。まずは、Algoliaで必要な作業から。作業の流れだけ記載しておきます。詳細は「Static site search with Hugo + Algolia」の3)を確認してください。\nAlgoliaのサインアップ(すでにアカウントがあれば不要) New Applicationの作成(名前とプランの指定) リージョンの指定 インデックス名の指定 APIキーを確認 です。これで、Algolia側の準備は完了です。\n今回は関係ないですが、Algoliaの管理画面で、利用状況(データ登録などの操作回数、クエリの回数、インデックスに保存されているレコード数)の確認が可能です。 ほかにも有料プランを利用するとAnalyticsなどもできるようです。\nHugo側で必要な設定 今度はHugo側です。Hugoのサイトのディレクトリに移動してからの作業です。\n仕組みとしては、\nHugoのoutput機能でAlgolia向けのJSONファイルを生成する Node.jsのライブラリを使用してAlgoliaに1.で生成したJSONを登録、更新する 検索画面の作成 という流れになります。 ですので、作業としては以下のとおりです。\nOutput出力の設定(すでにテーマ側で設定されているので、特に作業は必要なし) npm環境の構築(Hugoのconfig.tomlと同じディレクトリ階層) Node.jsのインストール(必要であれば) npm環境の初期化 npmでatomic-algoliaのインストール atomic-algolia向けの設定(登録のためのAPI関連の設定) Algolia向けJSONの出力設定 検索関連の設定 content/search/placeholder.mdの作成 検索用のAPIキーなどを設定 npm関連の作業 以下、npm関連の作業です。\nNode.jsのインストール(必要であれば) 割愛します。環境に合わせてインストールしてください。私はnvm経由でインストールしています。 npm環境の初期化 Hugoのディレクトリでnvm initを実行 npmでatomic-algoliaのインストール Hugoのディレクトリでnpm install atomic-algolia --save atomic-algolia向けの設定(登録のためのAPI関連の設定) Hugoのディレクトリに.envファイルを作成し、以下を設定します。 Algolia向けJSONの出力設定 特に変更なし(config.tomlに少し設定があります)。 ALGOLIA_APP_ID=AlgoliaのApplication ID ALGOLIA_ADMIN_KEY=AlgoliaのAdmin API Key ALGOLIA_INDEX_NAME=先程作ったインデックス名 ALGOLIA_INDEX_FILE=public/algolia.json 最後のALGOLIA_INDEX_FILEは固定文字列でいいと思います。 hugoコマンドを実行するとpublicディレクトリ配下にalgolia.jsonというファイルが生成され、Algolia登録用のJSONが出力されています。\n余談 : algolia.jsonの出力の設定は、config.tomlに記載があります。また、JSONファイルのテンプレート自体はthemes/hugo-theme-cleanwhite/layouts/_default/list.algolia.jsonにあります。Algoliaに登録するデータの構造など変更をする場合はこのテンプレートをカスタマイズすれば良さそうです。\n検索関連の設定 実際に検索の画面を表示するために、検索用の画面と、検索用のAPIの設定が必要です。\ncontent/search/placeholder.mdの作成 /search/が検索用のページになります。空のファイルです。実際にはJavaScriptが検索用の窓を表示したりしてくれます(これが必要な理由がまだ不明だなぁ)。 検索用のAPIキーなどを設定 検索のためのAPIキーなどの設定が必要となります。テーマ作者の方のサンプルのconfig.tomlにパラメータは用意されています。 以下の値を設定します。\nalgolia_search = true algolia_appId = \u0026#34;AlgoliaのApplication ID\u0026#34; algolia_indexName = \u0026#34;作成したインデックス名\u0026#34; algolia_apiKey = \u0026#34;AlgoliaのSearch-Only API Key\u0026#34; 以上でAlgolia関連の設定などの作業が終了です。\nAlgoliaへのデータ登録方法 最後に、実際にデータを登録する必要があります。 手順は、以下のとおりです。\nhugoコマンドの実行(htmlと一緒に登録データのalgolia.jsonを生成) npm run algoliaコマンドの実行(atomic-algoliaを利用してAlgoliaにデータを登録) 設定などが問題なければ、Algoliaの管理画面で登録ができているはずです。 実際にブログのデプロイにはdeploy.shというファイルをこちらを元に作成して使っています。このなかで、hugoコマンド実行後にnpm run algoliaを実行するようにしいます。\n今後の課題 Hugoで生成された記事はそれぞれのブログポスト以外に、タグごとのページも生成されています。 こちらも実はAlgoliaのインデックスに登録されていて、タグを入力すると、タグ名のリンクが出てきます。\nこちらはelasticsearchで検索したときの検索結果です。1件目はタグページです。\nこれらのページはAlgoliaに登録しないようにするのが良さそうかな?と考えているところです(考えてるだけ)。\n2020/01/29更新\nlist.algolia.jsonを編集して、記事だけをインデックスするように修正しました。 テーマに存在するlayouts/_default/list.algolia.jsonを、自分のところにコピーし、次のように変更しました。if文を1行追加して、postという種類のものだけを出力するようにしました。\n{{/* Generates a valid Algolia search index */}} {{- $.Scratch.Add \u0026#34;index\u0026#34; slice -}} {{- $section := $.Site.GetPage \u0026#34;section\u0026#34; .Section }} {{- range .Site.AllPages -}} {{- if or (and (.IsDescendant $section) (and (not .Draft) (not .Params.private))) $section.IsHome -}} {{- if (and (eq .Section \u0026#34;post\u0026#34;) (ne .URL \u0026#34;/post/\u0026#34;)) -}} {{- $.Scratch.Add \u0026#34;index\u0026#34; (dict \u0026#34;objectID\u0026#34; .UniqueID \u0026#34;date\u0026#34; .Date.UTC.Unix \u0026#34;description\u0026#34; .Description \u0026#34;dir\u0026#34; .Dir \u0026#34;expirydate\u0026#34; .ExpiryDate.UTC.Unix \u0026#34;fuzzywordcount\u0026#34; .FuzzyWordCount \u0026#34;keywords\u0026#34; .Keywords \u0026#34;kind\u0026#34; .Kind \u0026#34;lang\u0026#34; .Lang \u0026#34;lastmod\u0026#34; .Lastmod.UTC.Unix \u0026#34;permalink\u0026#34; .Permalink \u0026#34;publishdate\u0026#34; .PublishDate \u0026#34;readingtime\u0026#34; .ReadingTime \u0026#34;relpermalink\u0026#34; .RelPermalink \u0026#34;html\u0026#34; .Params.Description \u0026#34;title\u0026#34; .Title \u0026#34;type\u0026#34; .Type \u0026#34;url\u0026#34; .URL \u0026#34;weight\u0026#34; .Weight \u0026#34;wordcount\u0026#34; .WordCount \u0026#34;section\u0026#34; .Section \u0026#34;tags\u0026#34; .Params.Tags \u0026#34;categories\u0026#34; .Params.Categories \u0026#34;author\u0026#34; .Params.authors \u0026#34;content\u0026#34; .Params.Description \u0026#34;excerpt_html\u0026#34; .Params.Description \u0026#34;excerpt_text\u0026#34; .Params.Description \u0026#34;summary\u0026#34; .Summary)}} {{- end -}} {{- end -}} {{- end -}} {{- $.Scratch.Get \u0026#34;index\u0026#34; | jsonify -}} まとめ これで、ブログ内記事検索ができるようになります。 Algoliaは個人の非商用利用の場合、フリープランが用意されているのがありがたいですね。 まだ、Hugoと連携しただけで、Algolia自体でどんな機能があって、どんなことができそうかといったところは調べていませんが、簡単に利用できるのはとても助かります。\nまぁ、個人ブログの検索機能ってそんなに使う人はいないんですが、自分としては便利かなぁと。\n","date":1580186404,"dir":"post/2020/","id":"d9018f459d3c94a91e92b459e152f7e7","lang":"ja","lastmod":1580283604,"permalink":"https://blog.johtani.info/blog/2020/01/28/introduce-algolia/","publishdate":"2020-01-28T13:40:04+09:00","summary":"ブログ移行日記(その4)です。その他の記事はこちら。 ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(","tags":["ブログ"],"title":"ブログ移行日記(その4) - 検索機能(Algolia)の導入"},{"contents":"ブログ移行日記(その3)です。その他の記事はこちら。\nブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その4) ブログ移行日記(その5) 今回は、Hugoの設定とテーマの一部変更した点について記載します。\n設定ファイル(config.toml) Hugoの設定ファイルはconfig.tomlになります。hogo new siteコマンドで生成したディレクトリの中にデフォルトで含まれていますが、こちらではなく、テーマの作者が用意してくれたconfig.tomlを元に変更を加えました。\nちなみにテーマの作者の方が設定とコンテンツを含めたサンプルも公開してくれています。設定やディレクトリの構成はこちらを参考にしました。\n設定ファイルで変更した項目は以下のとおりです。\nサイトのタイトルや説明など 特記することはありません。好きなように変えました。\nbaseurl title SEOTitle description keyword slogan sidebar_about_descrption 画像関連(ヘッダーや著者近影) 画像の置き場はstatic/images/ディレクトリですが、設定ファイルには images/から設定します。\nheader_image : ブログのヘッダー背景 sidebar_avatar : 著者近影 言語周り(特に多言語対応する予定は無いのですが) languageCode = \u0026ldquo;ja\u0026rdquo; defaultContentLanguage = \u0026ldquo;ja\u0026rdquo; オフにした機能、削除した項目 freands = false bookmarks = false 上記の設定変更以外に、[[params.bookmark_link]]や[[params.friend_link]]も削除。\n中国のサービスや、特化した設定など。\nBaidu Analytics関連 Disqus proxy関連 Reward(wechat pay \u0026amp; alipay関連) params.social関連 rss = true twitter linkedin github ほかはすべてコメントアウト。\n外部サービス関連 disqusShortname : Disqusのショートネーム googleAnalytics : Gooogle AnalyticsのトラッキングID algolia関連 : 別のブログ記事として、設定方法などを書きます。 追加した設定(昨日のブログで説明済み) Octopressと同じ形のパーマリンク [permalinks] post = \u0026#34;/blog/:year/:month/:day/:slug\u0026#34; Markdownファイル中のHTMLタグ表示 [markup.goldmark.renderer] unsafe = true 以上が設定ファイル関連です。\nテーマの変更点 テーマそのままでは問題があったり、独自に変更したいという点があったので、いくつか変更をしています。\nフォントの変更 そのままテーマを適用するだけでうまく行けばよかったのですが、フォントの問題が発生しました。テーマの作者の方が中国の方だから?かどうかはわかりませんが、デフォルトのままだと中華フォントになってしまいました。\nあー、中華フォントだな。 pic.twitter.com/OvHpY4LSp1\n\u0026mdash; Jun Ohtani (@johtani) January 16, 2020 config.tomlにcustom_cssという設定があり、こちらで指定したCSSのファイルがテーマのlayouts/partials/head.htmlから読み込まれる仕組みがあるようなので、フォントに関するCSSをこの機能を使用して指定するようにしました。\nconfig.tomlの設定は次のとおりです(リスト)になっているので、複数のファイルに分割して、読み込ませることも可能なのかな?。\ncustom_css = [\u0026#34;css/custom-font.css\u0026#34;] cssファイルについては、static/css/custom-font.cssというファイルを作成し、次のような記載になっています。 フォントの指定と右側サイドバーの自己紹介の部分の文字色を変更するためのものです。\nbody, h1, h2, h3, h4, h5, h6, .navbar-custom { font-family: Helvetica,\u0026#34;Sawarabi Gothic\u0026#34;,Meiryo,\u0026#34;メイリオ\u0026#34;,\u0026#34;Hiragino Kaku Gothic ProN\u0026#34;, \u0026#34;ヒラギノ角ゴ ProN\u0026#34;,YuGothic,\u0026#34;游ゴシック\u0026#34;,Arial,sans-serif; } .sidebar-container { color: #404040; font-size: 14px; } faviconの変更 テーマにfavicon.icoが含まれていたのですが、せっかくなので独自のものに変えてみようかと。 ただ、残念ながら、こちらはパスおよびファイル名がlayouts/partials/head.htmlに直書きされていました。\n画像はimages配下にと思っていたのですが、このパスだけを変更するためにhead.htmlを自分の配下にコピーしてカスタマイズするのもどうかと思った(テーマに変更やバグ修正が入るたびに手動でコピーするのはなぁと思った)ので、static/img/favicon.icoファイルを作成しました。\nテーマよりもHugoのプロジェクトにあるファイルを優先するようなので、ファイルだけをプロジェクトに作成しました。\n記事一覧のテンプレート 記事の一覧で表示される、作成者と作成日時が英語表記でかつ、冗長な感じがしたので、スッキリさせるために、layouts/partials/post_list.htmlをテーマからコピーして、次のように変更しました。\n元の形式は : Posted by author Monday, January 2, 2006 現在の形式 : 2006-01-02 by author 記事のテンプレート 今回採用したテーマでは、記事の先頭に記事のセクションを元に目次を生成してくれるものでした。\n目次をコンテンツから自動で作ってくれるの便利だな。 pic.twitter.com/9bU3sLnUrm\n\u0026mdash; Jun Ohtani (@johtani) January 16, 2020 とても便利です。ただ、表示が「TOC」なんです。 英語でしかも「ToC」という表記ならまだ気にならなかったかもですが、大文字だと流石に気になったので、プロジェクトのlayouts/_default/single.htmlにコピーして「目次」という日本語に書き換えました。 このHTMLにテーマで修正が入った場合はどうしようかなぁ。。。というのが目下の悩みです。。。\nArchetypeテンプレートの追加 最後は新規記事を書くときに生成されるMarkdownのメタデータの追加です。 HugoにはArchetypesというのが存在します。\nHugoではhugo new 記事としたときに、記事の種類(content/ディレクトリ名=記事のタイプ)によって、作成するmarkdownファイルをテンプレートから生成する機能があります。この生成時に使われるのがarchetypesというディレクトリにあるファイルです。\n私のブログサイトでは、今のところcontent/postというブログの記事だけを書く予定ですので、archetypes/post.mdというファイルを作って以下のようなメタデータをhugo newしたときに自動で生成するようにしました(テーマにあったpost.mdファイルの代わり)。\n--- layout: post title: \u0026#34;{{ replace .Name \u0026#34;-\u0026#34; \u0026#34; \u0026#34; | title }}\u0026#34; slug: \u0026#34;{{ substr .Name 11 }}\u0026#34; author: johtani date: {{ .Date }} comments: true tags: [] draft: true --- タイトルはファイル名のハイフンを空白に変換したもの(実際にはファイル名は英語にしているので、使いませんが。。。) slugはファイル名の先頭からYYYY-MM-DD-という11文字を除いたもの。これは、OctopressのURLに合わせるために使用するURLの一部の文字列です。 author: johtani : 著者は私だけだから固定文字列 comments: true : ブログ記事にはDisqusのコメント機能を利用 tags: [] : 各内容によってタグを付けるが、生成時には空 draft: true : 明示的にこの行を消すまではドラフト記事としたいため という感じです。ほかにどのよなメタデータがあるのかまではまだ調べていないので、今後また適宜変更していくと思います。\nまとめ Hugoの設定や、テーマそのままではなく独自の変更を加えた部分を思い出して書き出してみました。\nこれで、Algoliaに関する部分以外はだいたい思い出して書いたと思います。 次は、Algoliaの使い方と設定について書き残す予定です。\n","date":1579853081,"dir":"post/2020/","id":"99c9c80a6532e4ea3b535c5a92d07a25","lang":"ja","lastmod":1579853081,"permalink":"https://blog.johtani.info/blog/2020/01/24/setting-hugo/","publishdate":"2020-01-24T17:04:41+09:00","summary":"ブログ移行日記(その3)です。その他の記事はこちら。 ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その4) ブログ移行日記(","tags":["ブログ"],"title":"ブログ移行日記(その3) - Hugoの設定と微調整(テーマに合わせた)"},{"contents":"その他の記事はこちら\nブログ移行日記(その1) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) ブログ移行日記(その2)です。前回はHugoとは?というのと、自分が選んだテーマについて記載しました。 本家の手順などを参考にすると、Hugoにテーマを適用し、でHTMLを生成して、表示するところまでできるはずです。\n今回は、OctopressのmarkdownファイルをHugo用に変換する方法について紹介します。お手製ですが、Pythonスクリプトを作ったので、そちらも合わせて簡単に紹介する予定です。\n参考ブログ 「Octopress Hugo 移行」でググるといくつか出てきます。先人の知恵ありがたいですね。 ということで、私はこちらの2つのブログを参考にさせていただきました。ありがとうございます。\nOctopress から Hugo へ移行した - iriya-ufo\u0026rsquo;s blog OctopressからHugoへ移行する方法 | gam0022.net 画像のコピー 画像はそのまま上記参考ブログを元にsource/imagesからstatic/imagesにコピーしました。特にディレクトリ構造の変更とかもしませんでした。\nコンテンツのコピー こちらは、コピーのタイミングでいくつか変換などの処理を行いました。 ファイルの変換にはPythonのスクリプトを書きました。 自分向けの移行ツールなんで、ディレクトリ名とか引数にすらしてないです。。。\n参考ブログと同様の変換\nメタデータの日付変換 categoriesをtagsに変換 画像タグの変換 タイトル、画像のサイズなどに合わせていくつか分岐があります。 参考ブログとは異なる変換、変更\nコードブロックは無変換 0.60.0からCode Fencesに対応したみたいなので不要でした。 ディレクトリ構造の変更 ファイルを年ごとのディレクトリに格納(これまでは、全てのファイルが同一ディレクトリにあった) 拡張子の変更 (.markdown -\u0026gt; .md) メタデータにauthorの追加(自分しか書かないんですけどね) URLをOctopressに合わせる Google検索からの流入もあり、これまでのURLに変更はかけたくないなと。 こちらも参考ブログに記載があるので、そのまま参考にさせていただきました。\nslugについては、移行ツールでファイル名を元に追加する処理を書きました。\nHTMLを含んだMarkdownの対応 TweetやAmazonのアフィリエイトのリンクがHTMLタグでいくつかの記事に含まれており、デフォルトの設定だと表示されません。 config.tomlファイルに以下の設定を追記することで、出力されるようになりました。\n[markup.goldmark.renderer] unsafe = true 名前がunsafeなので、ちょっと気になりますが。。。 すべての記事を表示してチェックしてみたわけではないので、おかしな記事を見つけた方は連絡をいただけると助かります。\nまとめ OctopressのファイルをHugo用にコピーや変換した方法を思い出しながら書いてみました。基本的には参考ブログに上げた2つのブログを真似したものになります。\n次は、利用したテーマのサンプル設定を元に、自分用に変更した点などについて書き残しておこうかな?\n","date":1579775514,"dir":"post/2020/","id":"018b365b00dd3a6ad17c813d21590549","lang":"ja","lastmod":1579775514,"permalink":"https://blog.johtani.info/blog/2020/01/23/convert-md-from-octopress-to-hugo/","publishdate":"2020-01-23T19:31:54+09:00","summary":"その他の記事はこちら ブログ移行日記(その1) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) ブログ移行日記(その2)","tags":["ブログ"],"title":"ブログ移行日記(その2) - Markdownファイルの変換"},{"contents":"その他の記事はこちら\nブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) 起因 いつものツイートから始まる私の行動です。\n(もしかしたら前に一度おすすめしたかもですが) Goのtemplate構文に拒絶反応がなければHugo割と良いですよ〜。\n\u0026mdash; Nobuyuki Kubota (@nobu_k) October 10, 2019 ってことで、Hugo勧められたし、テーマが豊富だしということで、乗り換えた次第です。\n(元)同僚に教えてもらった記事を見てる。Gatsbyも気になるんだけど、デザインセンスないし、テーマが豊富なのがいいなぁ。/ Comparison of Gatsby vs Jekyll vs Hugo | GatsbyJS - https://t.co/yUbKiBmtMS\n\u0026mdash; Jun Ohtani (@johtani) January 9, 2020 一応Gatsbyのサイトにあった比較も見たのですが、テーマの豊富さが勝ちました。デザインを自分でやれるほどではないので。\n理由 乗り換えるに至ったのは主に2つの理由です。\nOctopressが更新されていない ページが増えてきてサイトの生成に時間がかかる 前に使っていたOctopressもJekyllというものがベースになっていました。 Jekyllは今でも更新があるのですが、Octopressが更新されなくなってしまったのと、Rubyがベースになっているため?なのかはわかりませんが、 ブログのページ数が増えてきて、サイトのビルドに時間がかかってくるようになりました。\n結果 まだ、改良点があるかもですが、とりあえず公開できる感じになったと思ったんで切り替えました。\n前のブログはこんな感じで、\n移行後はこんな感じです。\nHugoとは? 公式サイト こちらにあるように、Go言語で実装されているウェブサイト構築フレームワークです。 Go言語で実装されているのもあり、インストールが簡単でした。 Macを使っていますが、Homebrewでインストールができてしまいます。 他の方法もあるようでしたが、Emacsをインストールするのにbrewを入れているので、brewでインストールしました。\n使い方は色んな人が書いてるし、公式ドキュメントを見ていただけばいいかな。\nテーマとは? Hugoのサイトにテーマの一覧があります。 一応、個人のブログなので、それなりにデザインを入れつつ、他の人と違う感じにしたいなと。 テーマ一覧をざっと眺めて良さそうなのをピックアップしたら、最終的にこちらのテーマになりました。\nClean White それなりに更新されてますし、DisqusとSearch(Algolia)が使えるのでこのテーマに決めました。 テーマのインストール方法などはGitHubのREADMEの「Quick Start」に記載があります。\n私は、Hugo自体の設定などをGitHubで管理したかったので、git submoduleを利用して、次のような構成になりました。\nhugo - main repository ├── archetypes ├── content ├── data ├── layouts ├── public - github.com/johtani/johtani.github.io ├── resources ├── static └── themes └── hugo-theme-cleanwhite - github.com/zhaohuabing/hugo-theme-cleanwhite.git hugo : hugo new siteコマンドで作成されたディレクトリです。このディレクトリでまずgit initしました(このリポジトリはプライベートで管理してます)。 themes/hugo-theme-cleanwhite : テーマのQuick Startにあるgit submodule addコマンドでサブモジュールとしてテーマをインストールしました。 public : hugoが生成するHTMLのトップのディレクトリがこちらです。私はGitHub pagesを利用してブログを公開しているので、git submodule addでjohtani.github.ioをサブモジュールにしました。 Hugoで生成したHTMLなどをGitHub pagesで公開するときの手順などはHugoのドキュメントに記載がありました。\nまとめ Hugoに移行した理由や、Hugoとテーマの簡単な紹介でした。 テーマが豊富なのはデザイン力(りょく)がない身としてはありがたいですよね。 次はOctopressのmarkdownファイルをHugo用に変換したり、それに関する設定周りの話を書く予定です。\n","date":1579659814,"dir":"post/2020/","id":"a65bd31d4c3dab0a41712823a5d6002b","lang":"ja","lastmod":1579659814,"permalink":"https://blog.johtani.info/blog/2020/01/22/intro-hugo-and-theme/","publishdate":"2020-01-22T11:23:34+09:00","summary":"その他の記事はこちら ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) 起因 いつものツイートから","tags":["ブログ"],"title":"ブログ移行日記(その1) - Hugoとテーマ"},{"contents":"5年くらい、Octopressを使用していましたが、更新されなくなっているのと、コンテンツの生成に時間がかかることもあり、 ほかのプラットフォームを使用するように変更しました。\nとりあえず、今回の移行で参考にした記事とかURLをリストアップしてみました。 詳細についてはまた明日以降で。\n参考記事 移行関連 : https://iriya-ufo.net/blog/2018/12/27/octopress-to-hugo/#github-pages- 移行関連 : https://gam0022.net/blog/2016/09/25/migrated-from-octopress-to-hugo/ Hugo自体の日本語紹介記事 : https://knowledge.sakura.ad.jp/22908/ Hugo概要 https://gohugo.io/ テーマ 一覧 : https://themes.gohugo.io/ 利用したテーマ : https://github.com/zhaohuabing/hugo-theme-cleanwhite データ移行 作ったスクリプト : https://github.com/johtani/from-octopress-to-hugo favicon 作ったサイト : http://emblemmatic.org/markmaker/#/ Algoliaセッティング 参考 : https://blog.uni-3.app/2019/01/02/hugo-algolia-search/ GitHub Pagesでの運用 https://gohugo.io/hosting-and-deployment/hosting-on-github/#types-of-github-pages 残タスク Amazonのアフィリンクをきれいに表示するlayoutか何かを用意する?　","date":1579166617,"dir":"post/2020/","id":"3c299a4d77be8b4f886ce9fcd23a2561","lang":"ja","lastmod":1579166617,"permalink":"https://blog.johtani.info/blog/2020/01/16/moving-to-hugo/","publishdate":"2020-01-16T18:23:37+09:00","summary":"5年くらい、Octopressを使用していましたが、更新されなくなっているのと、コンテンツの生成に時間がかかることもあり、 ほかのプラットフォ","tags":["hugo","ブログ","octopress"],"title":"OctopressからHugoへ移行中(まだ途中)"},{"contents":"今年も振り返りブログ書いてます。Sasukeがついてる。\n振り返り（2018年に書いた抱負から） まずは去年の抱負を元に。\nTOEIC 受けました。\nお。TOEICの点上がってた（まだまだだけど。。。）\n\u0026mdash; Jun Ohtani (@johtani) October 21, 2019 無事、上がってました。テストの点数を上げるのが目的ではなく、今の実力が どんな感じかというのを確認するために受けました。 前回までが低かったのもあるんですが。 また、数年後に受けてみるのかな?\nCfP見つけて応募 \u0026amp; いろんな場所に顔を出す 色んな所には顔を出しました。 CfPはそれほど出せていなく、とちぎRubyとDevRelJPで喋った程度かと。 12月に最終出社日を迎えたので、今後は顔を出したりCfP見つけて応募も、 一旦休憩に入る予定です。\nもっとブログ！ 12月に入ってから、一気に増えてますねw Elasticでは結局それほどかけなかったなぁ。\nRustの継続 こっちは、書籍も買ったのに手がついてないです。 来年に書籍を読みながら再入門する予定です。\n開発の継続 一応ほそぼそと続けてますが、メンテナンスですね。 Analyzer向けのKibanaのプラグインのバージョンアップにだけ対応していたり。 年初にReact化には着手しました。 あとは、Luceneにちょっとしたパッチ(Lukeの画面とKuromojiのUniDic対応)を送った感じかな。もっとLucene周りやりたいかな。\n日本でエンジニア獲得! トレーナーやエンジニアが入社してくれました! が、私が退職してしまいますが。。。 私自体が次のステップに移らないとなぁと。 Elasticに興味がある人いたら、中の人を紹介できるので声をかけてください!\n振り返り(今年あったできごと) さて、ここからは今年の出来事を。\n検索技術勉強会発足 勉強会運営座談会 初フロリダ 初カナダ\u0026amp;初ナイアガラの滝 退職(予定) 検索技術勉強会ってのをはじめました(はじめましたブログはこちら)。 やっぱり検索の話を聞いたり考えたりするのが好きなので、もっといろんな話を聞く機会がほしいなぁと。ツイートすると何人かの知り合いが手を上げてくれたので、初めて見たのが2月でした。 所属会社もあったので、自分が全面に出ない形で運営に協力するという形式でやっています。なんだかんだでもう4回も開催できています。スピーカーへの声掛けなど、複数人で運営するとそのあたりが多様性が出るし、楽になるのですごくいいなぁと。 来年も2月か3月にやりたいねと話をしているところです。興味のある方は、ぜひスピーカーを!\nで、その流れで、他の勉強会の運営ってみんなどうしてるんだろう? という疑問も出てきたので、勉強会運営座談会なるものもやってみました。少人数で集まって、勉強会の運営ってどんなやり方してます?どんなことに困ってます?みたいなのを共有してみました。 自分自身がそれほど、ほかの勉強会の運営に顔を出してたわけでもなく、やり方をみんなはどうやって共有してるのかなぁ?というのが気になったので。 思った以上に属人化してるのかもなぁというのが感想でした。 ドタバタしてたので、あれからやってませんが、共有する勉強会みたいなのも面白いのかも?\n今年も2回ほどElasticの社内イベントで海外に行かせてもらいました。 5月にフロリダと11月にトロントでした。 フロリダでは、NASAにも行けたし、トロントでは足を伸ばしてナイアガラの滝を見に行くなどもしてみました。こういう機会が定期的にあるのは、いいですよねぇ。\n最後は、退職イベントですね。5年5ヶ月勤めたElasticでの仕事が、12/6で最終出社日でした。実際の退職日は1/24となっています(現在有給休暇消化中)。長かったような、短かったような。日本で1人目で入社してさまざまなことをやらせてもらい、本当に色んな経験ができました。英語も上達したし。 ただ、外にいることでできることがありそうだなと感じたこともあってのこの決断でした。\n最終出社日以降、色んな人とランチさせてもらったりしています。 次に何をやろうかな?ってのんびり考えながら休んでいるところなので。 やっぱり、検索周りのことをやりたいなぁというのが念頭にあるので、そのあたりで模索中という感じです。 が、せっかくの機会なので、少しのんびりしようかなとも思ってます。 なので、プラモデルの作成や配達業(デス・ストランディング)をやってみたり、16インチMacbookのセットアップしながらブログ書いたりしています。 年明けに入ったら、プログラミングもちょっとやりたいな。\nあとこの場を借りて、ブログの欲しい物リストのものを送っていただいた皆様に感謝を述べさせていただきます。本当にありがとうございました!この感謝はまた何かの機会にでも!\n来年の抱負 ということで、来年の抱負です。\n職につく ブログプラットフォームの移行 プログラミング Rust再入門 検索の勉強 検索技術勉強会の継続 まぁ、まずは職につかないとですね。どこかに在籍しつつ、副業で検索周りのこととかやるのもありかもなぁと考えたりしています(プラモデルつくりながらw)。\nブログのプラットフォームをOctopressからHugoあたりに移行しようかなと思ってます。Octopress自体がもう開発がされてないようですし。Hugoだとテンプレート?テーマ?がそれなりにありそうなので良さそうかなぁと。移行プログラムも書かないとかな。新しいものを調べるのって楽しいですよね。\nプログラミングも復活させたいなと。どうしてもこれまでは、しゃべるのをメインにしていたので、後回しにしてしまっていたのもあります。まぁ、向いてないのかもと思ったりもしますが、下手の横好きなりに少しずつでも何かを改善したり作ったりしたいなと。 勉強会の運営周りですこし楽をするためのプログラム書いたりもしているので、この辺もブログに書こうかな?\nRustはTantivyというプロダクトも出てきているし、勉強しようと思って、自転車本を買いつつ、Kindleの肥やしにしているので、手を動かそうとおもいます。 ブログ書いてサボった場合の可視化しないとなw\n検索の勉強もやりたいなと。これまではElasticsearchに注力していましたが、ほかのプロダクトやサービスも調べてみたいなと。教えを請いに皆さんのところにお邪魔するかもしれないので、そのときは優しくしてください。\n今年始めた検索技術勉強会を今後も継続できるようにしたいなと。 で、運営周りを楽にできるような仕組みをもう少し導入できればなぁと考えていきたいなと思います。\nさて、嵐の曲も始まったし終わりです。\n今年も様々な方々に助けていただきました。また、最終出社日以降にランチを一緒にさせていただいたり、遊びに行かせていただいたりとありがとうございました。年明けもひましてるので、ぜひランチしましょうw\n来年はなにやってるんだろうなぁ? 今後も皆さんよろしくおねがいします!!\n","date":1577764743,"dir":"post/2019/","id":"35aa9e09db936aee7ec407c431816573","lang":"ja","lastmod":1577764743,"permalink":"https://blog.johtani.info/blog/2019/12/31/looking-back-2019/","publishdate":"2019-12-31T12:59:03+09:00","summary":"今年も振り返りブログ書いてます。Sasukeがついてる。 振り返り（2018年に書いた抱負から） まずは去年の抱負を元に。 TOEIC 受けました。 お。TO","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2019）"},{"contents":"このブログ書こうと思って、これまでMacのセットアップしてたんだった。。。\n普段、macOSの標準ターミナルを使ってます。 で、ターミナルを使うシーンは次のような感じです。\nブログのデプロイ（参考：Octopress環境のDockerイメージ化） ElasticsearchとKibanaの動作確認 Elasticsearchの起動用ターミナル Kibanaの起動用ターミナル プラグインの開発(elasticsearch-ingest-csv と analyze_api_ui) elasticsearchのリポジトリ kibanaのリポジトリ ingest-csvのリポジトリ analyze_api_uiのリポジトリ 上記のように1.以外については複数のターミナルをそれぞれのディレクトリで起動して使っています。 これらの3つのパターンのときに、毎回ターミナル(シーンによっては複数のウィンドウ)を開いて、ディレクトリに移動って大変だなと。\nウィンドウグループって？ そこで、ターミナルに便利な機能がないのかな?と思い、メニューを見ていたところ「ウィンドウグループ」というのがあったので調べて、現在の使い方に至っています。\nウィンドウグループの使い方の説明はこちらです。\n使い方にあるようにウィンドウの場所、設定、タブなどを保存できます。 そして、「ウィンドウグループを開く」というメニューから保存しておいたグループを開くと、簡単に作業環境が再現可能になります。\n開くときのメニューはこんな感じです。\n作り方 ウィンドウグループの使い方に載ってます。 まずは、保存したいターミナルを開いて、開いたときに移動していたいディレクトリに移動します。 複数のタブやウィンドウを開いた状態にしたい場合は、複数ターミナルを起動して、それぞれ移動したいディレクトリに移動しておきます。\nグループとしてまとめたいウィンドウが起動できたら、あとは、「ウィンドウ」メニューの「ウィンドウをグループとして保存」を選択します。\nこれだけです。あとは、使いたくなったときに開くだけです。 簡単ですよね?\n作るときの注意点としては、複数のウィンドウグループを作りたいときは、 それぞれグループごとに作成しては、個別にやる必要があります。 現在開いているターミナルのうち、あれとこれをウィンドウにしたいというやり方はできないので、そこだけ注意点です。 環境ごとにプロファイル(バックグラウンドの色やテーマ)を覚えさせることができるので、1.のシーンだとIceberg、2.のシーンではBasic、3.のシーンではHomevrewで設定していたりします。 (ただ、Preztoのテーマをagnosterにしてしまったので、Basicだとプロンプトが見にくくてしょうがないのですが。。。)\n設定はどんな感じ？？ ウィンドウグループの管理については、ターミナルの「環境設定」に管理用の画面があります。\nこの画面でいらないグループを削除したり、設定のエクスポート/インポートも可能です。\n私の使い方 3つの利用シーンは説明しました。 すべてのウィンドウグループを変更するたびにインポート/エクスポートしてます。 上記1.と3.のユースケースはほぼ変更がないので、エクスポートしたものを移植用に管理していますが、2.のユースケースについては、頻繁に更新しています(ElasticsearchとKibanaのバージョンをアップしないといけないので)。\nこのとき、MacのGUIで毎回設定をしているわけではありません。 エクスポートしたファイルは、.terminalという名のXMLファイルになっています。\nその中に、次のようなパスが記述されています。このバージョン番号の部分をアップデートのたびにemacsなどで変更し、ターミナルの管理画面で、削除してからインポートし直すだけで、バージョンアップに対応している感じです。\n\u0026lt;key\u0026gt;Tab Working Directory URL\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;file://johtani-mac-15.local/Users/johtani/tmp/elastic_stack/v7.5/elasticsearch-7.5.1/\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Tab Working Directory URL String\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;file://johtani-mac-15.local/Users/johtani/tmp/elastic_stack/v7.5/elasticsearch-7.5.1\u0026lt;/string\u0026gt; まとめ ということで、標準ターミナルのウィンドウグループを使うと、よく開くディレクトリやウィンドウ、タブを覚えて置かせることができるので、それぞれの環境向けのターミナルを、好きなときに開くことができるようになります。 私は、ウィンドウは1つで複数のタブをウィンドウグループという形で覚えさせておくことで、各シーンの切り替え、もしくは併用を閉じたり開いたりを簡単にできるようにしています。\n他のターミナルソフトを使うと似たようなことが簡単にできたりするのかな? みなさんがどうやってこのような作業やってるのかな?ってのはちょっと気になるところです。\n余談（いつものようにツイートとその反応） ちなみに、みんなどんなターミナル環境なんだろう？と思いツイートしてみた結果はこちらです。 (コメントRTってうまいことひろえないのかなぁ？)\nMac標準のターミナル使ってる人ってどのくらいいるんだろ？iTermとか入れてるのかな？tmuxとか？\n\u0026mdash; Jun Ohtani (@johtani) December 11, 2019 Iterm2使ってtmux使って今はIterm2だなー\ncommand2回押すだけでターミナル出すくせが抜けん https://t.co/P8o4M1HSoj\n\u0026mdash; GO☆ | TAFDATA (@_gogoponz) December 11, 2019 Alacritty + tmux やなー。標準はもう使ってない。 https://t.co/HI7hPCg3uo\n\u0026mdash; Ryo HIGASHIGAWA (@biwakonbu) December 11, 2019 標準です https://t.co/W27e2pcq3j\n\u0026mdash; shin higuchi @Acroquest (@shin0higuchi) December 11, 2019 Macを買って以来、ずっと結局標準ターミナル以外使っていない感じ。珍しかったのか。。 https://t.co/Zjz32SgjC6\n\u0026mdash; Kazuhiro Hara™ (@kara_d) December 11, 2019 ","date":1577063679,"dir":"post/2019/","id":"1a1a8cc0040b356d06eacd22e0526476","lang":"ja","lastmod":1577063679,"permalink":"https://blog.johtani.info/blog/2019/12/23/whats-window-group-of-terminal/","publishdate":"2019-12-23T10:14:39+09:00","summary":"このブログ書こうと思って、これまでMacのセットアップしてたんだった。。。 普段、macOSの標準ターミナルを使ってます。 で、ターミナルを使う","tags":["misc"],"title":"macOS標準のターミナルのウィンドウグループが便利"},{"contents":"ドットファイル系（.emacsとか）をこれまでは、PCを引っ越すたびにコピーしてたんですが、いいかげん、GitHubとかで管理したいなと。\nで、ツイートしたところ（こればっかりだなｗ）、homeshick(homesick)が便利だよとの情報を得たので使ってみました。\nhomesick、正確にいうとhomeshickを使ってます。悪くないです\n\u0026mdash; 🤓k.bigwheel🤓 (@k_bigwheel) December 10, 2019 使い方とか 実物はGitHubで公開されていました。\nhttps://github.com/andsens/homeshick\n何者かというと、ホームディレクトリにあるドットファイル(.zshrcなど)をgitコマンドで管理するのを楽にしてくれるシェルの関数群みたいです。 インストールは至ってかんたんで、git cloneで持ってくるだけです。homeshickのリポジトリのREADMEに記載があります。\n使い方はTutorialsにあります。\nhomeshick generate ほげほげで管理する単位（castle）を作ります。ほげほげが名称です。今回私はdotfilesにしました。 homeshick track ほげほげ .zshrcで管理したいファイルを指定します。すると、homeshickが対象のファイル（ここでは.zshrc）をcastleの保存先ディレクトリにコピーしてから、シンボリックリンクをホームディレクトリ上に作ってくれます。 homeshick cd ほげほげで、castleの実際のディレクトリに移動します。実態は.homeshick/repos/ほげほげです。 git remoteコマンドでcastleとGitHubの関連をつけて、あとは、普通にgitコマンドでコミットしたりすればOKです。 すごく簡単に導入できました。あとは、実際にtrackしたいファイルを追加していく感じです。 現状は、.zshrc、.gitconfigあたりを管理しています。 ついでに、homebrewでインストールしたものもbrew bundle dumpで出力して、homeshickで管理することで、brewでインストールしたものの管理もできそう（参考）。\nってことで、至極かんたんでした。すばらしい。\n参考 homeshick Tutorials Qiita : homeshickを使ったdotfilesの管理 ","date":1576624266,"dir":"post/2019/","id":"80c8fca02ebfecc7a931dad1ec38466e","lang":"ja","lastmod":1576624266,"permalink":"https://blog.johtani.info/blog/2019/12/18/introduce-homeshick/","publishdate":"2019-12-18T08:11:06+09:00","summary":"ドットファイル系（.emacsとか）をこれまでは、PCを引っ越すたびにコピーしてたんですが、いいかげん、GitHubとかで管理したいなと。 で","tags":["misc"],"title":"homeshick導入"},{"contents":"Macbook Proが新しくなり、OSがCatalinaになっちゃいました。 これまで使ってた、.bash_profileをコピーしてターミナルを立ち上げたところ、 なんか色々と設定が動いてないな？と思ったら、zshがデフォルトに切り替わってました。\nということで、デフォルト変わったし、時間あるしzshってどんな感じなのか調べてみようと。\n準備前（ツイート） で、ツイートをしたところ、海外の方？より返信が来ました。\nI have a series of posts explaining the transition: https://t.co/dz8QNjxxGf\n\u0026mdash; Scripting OS X (@scriptingosx) December 10, 2019 おもしろそうなので、ざっくりと読んでみました。zshを利用されているTwitterの知り合いの何人かからはzsh + oh-my-zshがいいよとコメント頂いてたんですが、\nMoving to zsh Catalinaからzshがデフォルトになるからと、手元の環境を変更するための話をブログにまとめてくれてます。\nMoving to zsh\nサラッと読んだので、いくつか抜粋すると\nbashでいくつか今設定しているものがあるのでその説明 alias - ファイルをそれぞれの拡張子ごとにアプリを切り替えてる（openコマンドの利用例があって参考になりました）。 functions - manコマンドのときに新しいWindowひらいたりとか shell settings - 大文字小文字関係なくファイル名をTabで候補を表示したり、historyをターミナル個別ではなく共有できるような設定にしたり prompt - 現在のディレクトリがどこかとか表示したり zshの設定ファイル群の説明 shellオプションの抜粋 といった感じでした（途中で読むのやめましたが。。。）\n面白かったのは、Suffix Aliasesです。 ファイル名だけをターミナルで指定すると、拡張子に応じて起動するコマンドを切り替えたりできると（結局まだ採用はしてないですがｗ）\n結局？ 結局、上記ブログを読んでいろんなオプションあるんだなぁ。と思ったのですが、手っ取り早く試すためにPreztoをインストールしました。 以下のような構成になってます。\nなるほど、これがzsh + prezto + powerline fontか。前までgit-promptを拾ってきてbashに組み込んでたけど、ブランチ表示されるし便利だな。 pic.twitter.com/Z2ArBgRZey\n\u0026mdash; Jun Ohtani (@johtani) December 12, 2019 Mac標準ターミナル Iceberg プロファイル Powerline font Prezto agnoster theme - prompt agnoster or ~/.zpreztorc の変更 .zshrcにいくつかaliasなどを追加。参考:gist Preztoのデフォルトでlessなどからエディタを立ち上げるとnanoが起動したので、vimに変更 Preztoが作る設定と自分の設定を混ぜたくなかったので、.zshrcでinit.zshを呼び出し になりました。フォントサイズだけはちょっと大きくしました（老眼ェ。。。） ターミナルの参考にさせていただいたブログは「preztoでzsh構築した時のメモ 」です。\nターミナルソフト(余談？) terminalも人によっては、色んなものを使ってたなと思いツイートしました。 結構みなさん標準のterminalを使ってるみたいでした。ただ、私が聞いたこともないターミナルソフトもちらほらあったので、色々あるんだなぁと。\nMac標準のターミナル使ってる人ってどのくらいいるんだろ？iTermとか入れてるのかな？tmuxとか？\n\u0026mdash; Jun Ohtani (@johtani) December 11, 2019 ","date":1576542903,"dir":"post/2019/","id":"f3ef819656f68b87a91c53afbd441fec","lang":"ja","lastmod":1576542903,"permalink":"https://blog.johtani.info/blog/2019/12/17/move-to-zsh/","publishdate":"2019-12-17T09:35:03+09:00","summary":"Macbook Proが新しくなり、OSがCatalinaになっちゃいました。 これまで使ってた、.bash_profileをコピーしてターミナルを立ち上げ","tags":["misc"],"title":"zshへの移行"},{"contents":"最近使っていたPCが手元からなくなったので、16インチ Macbook Proをセットアップしているところです。 で、時間もあるのでこれまでほったらかしてきた、このブログの環境をちょっと変更しようかなと。\nまずは、変更するにしても、Octopressのブログの環境自体は必要です。 実際に、移行する前のこの記事自体も書いているわけですし。\nただ、今後なくなる環境をローカル環境にセットアップするのもどうかと思い、Docker環境にしてみました。\n参考 \u0026ldquo;Octopress Docker image\u0026quot;でググって出てきたサイトを参考にしました。\n参考ブログ：Octopress in a Docker Container\nセットアップからDockerイメージのビルドまで Docker for Mac自体もインストールしていなかったので、インストールしておきます。 参考ブログの方がGitHubのリポジトリにDockerfileをアップしてくれているので、手順に従い、cloneします。 cloneしたDockerfileの3行目にENV LC_ALL C.UTF-8を追加します（UTF-8でブログを書いており、previewした場合にエラーが出たため） 参考ブログにある「Build the docker image」の手順に従い、Gemfile、.gitconfigをコピーしてイメージをビルドします。 参考ブログの「Rakefile」にあるように、自分のoctopress/RakefileのProcess.spawn(...)にアドレスを追加します（Dockerコンテナの外からアクセスできるように） 自分のoctopressにあるGemfile.lockを削除しました（ビルドしたイメージにはいるGemと一部バージョンが異なる記載のものがあったため） ここまでで、\nDocker run 実際にコンテナを実行するためのスクリプトを書きました（書いたと言っても参考ブログにある起動コマンドを叩いてるだけですが。。。）\nlaunch-octopress-docker.shというファイル名で以下のコマンドを実行してるだけです。\n!/bin/sh docker run -p 4000:4000 --rm --volume /Users/johtani/projects/blog/octopress:/octopress --volume /Users/johtani/.ssh:/home/blogger/.ssh -ti blog/octopress /bin/bash このシェルを起動すると、Dockerコンテナにbashで接続し、/octopressディレクトリにログインしています。 あとは、いつものようにrake new_post[\u0026quot;....\u0026quot;]で新規記事のテンプレートを作成したりすればOKです。\nrake generate; rake previewと実行してからローカルのブラウザでhttp://localhost:4000に接続すればプレビューも可能。\nということで、このDockerファイルとかを持っておけば、他の環境でもかんたんにOctopressの環境が再現できそうです。 先人の知恵有り難し。 これで、クリーンなまま他のブログ環境に移行できそう。\n追記(2019/12/17) Docker環境でいくつか問題があったので、追記しておきます。\nDocker for Macが再起動しない Docker for MacがCatalina環境だと問題があるみたいでした。 CPUの数やメモリの数を変更してDockerを再起動したところ、ずっとStartingのまま。\n解決方法としては、launchctlの設定に$PATHを追加するみたい。これで、問題なく起動するようになった気がする\nsshの設定ファイルの問題 .ssh/configにMacのKeyChainを利用する設定を記載してるんですが、Ubuntu上だとこの設定のせいで、エラーが出てしまいます。 IgnoreUnknownという設定で、知らないオプションがあったら無視するという設定になる模様。ということで、Dockerコンテナ上でrake deployのときにエラーが出てたのが解消できました。\n","date":1576458061,"dir":"post/2019/","id":"1abc586d67f0b6c05fd5e60f25492340","lang":"ja","lastmod":1576458061,"permalink":"https://blog.johtani.info/blog/2019/12/16/dockernize-octopress/","publishdate":"2019-12-16T10:01:01+09:00","summary":"最近使っていたPCが手元からなくなったので、16インチ Macbook Proをセットアップしているところです。 で、時間もあるのでこれまでほったらかしてきた","tags":["octopress"],"title":"Octopress環境のDockerイメージ化"},{"contents":"本日、Elasticでの最終出社日でした。実際の退職日はまだ先ですが、有休消化という感じです。\n思い返せばもう5年と5ヶ月も前ですが、Elastic（当時はElasticsearchって社名だった）に参加しました。\n社名も変わりましたし、プロダクトの数も増えたし、IPOもしました。 初の外資＋スタートアップということもあり、ものすごくエキサイティングな5年半でした。 Elasticを離れはしますが、検索自体にはまだまだ興味があるので、LuceneやElasticsearchになにかしら関わる感じのことをする予定です。 検索技術勉強会も今後もやっていきますし。\nただ、激動の5年半だったので、退職日までちょっとゆっくりしようと思っています。 次にどんなことをするのかはまた、別の機会にでも。\nおまけ ということで、まぁお約束です。\nほしい物リストはこちら\n","date":1575615090,"dir":"post/2019/","id":"1bbf2ef67f096960e13d8578fa544536","lang":"ja","lastmod":1575615090,"permalink":"https://blog.johtani.info/blog/2019/12/06/leaving-elastic/","publishdate":"2019-12-06T15:51:30+09:00","summary":"本日、Elasticでの最終出社日でした。実際の退職日はまだ先ですが、有休消化という感じです。 思い返せばもう5年と5ヶ月も前ですが、Elas","tags":["転職"],"title":"退職します"},{"contents":"これは、情報検索・検索エンジン Advent Calendar 2019 の 4 日目の記事です。\n1日目から、質の高いエントリーが続いていましたが、一旦休憩して頂く感じの記事になってます。気軽に読んでくださいw。Advent Calendarつくらないの？と煽ったのもあり、穴を埋めようかなと。　発端 ちょっと先ですがこういうのやります。実装寄りの話やOSS開発に興味がある方，きてください～ / Lucene 版 #Kuromoji のコードを読む会（辞書ビルダー編） https://t.co/NgEmUohoPo #kuromoji\n\u0026mdash; Tomoko Uchida (@moco_beta) September 6, 2019 「Lucene 版 #Kuromoji のコードを読む会（辞書ビルダー編）」という勉強会があり、参加したところ、UniDicの辞書のビルドがコケるという話を聞いたんで、ちょっとやってみるかと。\nちなみに、Kuromojiとは、Apache Luceneに入っている、日本語向けの形態素解析ライブラリです。IPAdicの辞書を内包しており、SolrやElasticsearchといった、Apache Luceneを利用している検索エンジンで手軽に使える形態素解析ライブラリになっています。が、対応している辞書がデフォルトだとIPAdicなのです。\n問題点 LUCENE-4056というIssueが上がっています。\nbuild.xmlには記載はないけど、辞書のビルダーは対応していそうな雰囲気を醸し出しているので、試してみたというのが発端？かと。で、実際に動かしてみると動かない点がありましたと。\nまた、Issueの会話で出ていたUniDicの辞書のライセンスの話もありました。 ただ、UniDicがライセンスを変更したので、このあたりはクリアできそうかなと。\nパッチ ということで、動かしてみていくつか修正してパッチを作りました。\nhttps://github.com/apache/lucene-solr/pull/935\n最近のLuceneはGitHubでプルリク遅れるのが便利ですね。 そんなに大したことはやってないです。以下の点が問題だったので直しています。\nIPAdicとUniDicで語彙定義ファイルのCSVの形式（カラムの数）が異なる unk.defのカラム数も異なる あとは、辞書のダウンロードの部分やbuild.xmlでの処理を追加した形です。 このプルリクを適用したlucene-solrのソースディレクトリを持ってきて、手元でjarをビルドすれば普通はIPAdicの辞書を内包したkuromojiのjarファイルが出来上がります。\nlucene/analysis/kuromoji/build.xmlファイルを、このGistにあるように変更して、ant build-dictとやれば辞書のビルドが可能です。 また、cd lucene/;ant jarとすれば、UniDicの辞書を内包したjarファイルもビルドできます(lucene/build/analysis/kuromojiの下にjarファイルができあがります)。\n確認？ 一応、パッチは動くのですが、パッチ自体はUniDicの辞書をビルドする仕組みはオフのままです。なので、テストをどうやろう？というところでやなんで止まっています。。。\nただ、実際に作ったパッチできちんとIPAdicとUniDicがそれぞれビルドできているかの確認はしないとなと。\nということで、2つのjarファイルを読み込んで、それぞれトークナイズして、その出力を表示するツールを作ってみました。\n上記パッチを適用したlucene-solrのソースを持ってきて、IPAdicの辞書を内包したkuromojiのjarファイルと、UniDicの辞書を内包したjarファイルを用意し、ツールの支持に従って、ファイルをディレクトリに配置して、実行すれば以下のような出力がされるようになっています（とりあえず作ったものなので、Javaファイルにトークナイズしたいテキストを書かないといけないのですが）。\nたとえば、「自転車と自動車の違いはなんでしょう？」という文字列を入力すると、以下のような出力になりました。\n+++ ipadic ++++++++++++++ token[0] is [自転車] token[1] is [と] token[2] is [自動車] token[3] is [の] token[4] is [違い] token[5] is [は] token[6] is [なん] token[7] is [でしょ] token[8] is [う] +++ unidic ++++++++++++++ token[0] is [自転] token[1] is [車] token[2] is [と] token[3] is [自動] token[4] is [車] token[5] is [の] token[6] is [違い] token[7] is [は] token[8] is [なん] token[9] is [でしょう] UniDicは[短単位]で語彙が扱われるため、「自転車」や「自動車」がそれぞれ「自転」「車」、「自動」「車」という形でトークナイズされていることがわかります。\nどちらがより便利なのか？というのは用途によっても変わってくるかと思いますが、検索の転置インデックスとしては、より短い単語で区切られている方が、より多くの文書にヒットする可能性が高くなるので、便利な可能性が高いです。\nまとめ ということで、パッチを作ってみたものの、まだ取り込まれていない状況です。 着地点をどうするかって話かなと思っています。興味があれば遊んでみていただければと。\n将来的には、辞書をjarから切り離して別のディレクトリやjarとして使えるようにしようというIssueも作られています。こちらがすすめば、UniDicだけでなく、その他の辞書を切り替えながら使えるようになる日が来るのではないでしょうか？\n","date":1575385200,"dir":"post/2019/","id":"c2d39f2f7fe6cb69fc8efb6c5495c932","lang":"ja","lastmod":1575385200,"permalink":"https://blog.johtani.info/blog/2019/12/04/about-lucene-4056/","publishdate":"2019-12-04T00:00:00+09:00","summary":"これは、情報検索・検索エンジン Advent Calendar 2019 の 4 日目の記事です。 1日目から、質の高いエントリーが続いていましたが、一旦休憩して頂く感じの記事になって","tags":["Lucene"],"title":"Apache LuceneのKuromojiのUniDicビルド対応パッチについて"},{"contents":"Elastic stack (Elasticsearch) Advent Calendar 2019の1日目の記事になります。\nまだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみようと思います。毎年恒例ですね、ここ数年。\nElastic Stack 6.6.0リリース(1月) リリース記事はこちら\nElastic APMが6.6のリリースと同時にElastic CloudでAPM Serverが無料で利用できるようになったのが地味に便利でした。APMのデモをやるために、それまでは手元にAPM Serverの起動が必要だったので。。。\nユーザーの方たちにはIndex Lifecycle Management（インデックスライフサイクル管理：ILM）がリリースされたのが便利だったと思います。 まだ、ベータでしたが、インデックスの世代管理を格段に便利にしてくれるツールになり、現在では必須アイテムとなっています。 もう一つ、地味に便利なのは、KibanaからElasticsearchへの接続を複数指定できるようになった点かと思います。\nElatic Common Schemaのベータリリース(2月) リリース記事はこちら\nElastic Stackではメトリック、APM、ログなど、様々なデータを一元的に可視化することができるという利点があります。ただ、一元的にデータを可視化、検索するためには異なるデータセットに統一されたフィールド名が欠かせません。そのための手段としてElasticが公開したのがElastic Common Schemaです。 各種データの項目名、型などを共通化する仕様をGitHub上で公開しています。最近のBeatsのモジュールはこのElastic Common Schemaに則ってデータが定義されるようになってきています。これにより、ログからメトリックへ、APMからログデータへというシームレスな移動ができるようになっています。\nElastic Stack 6.7.0リリース(3月) リリース記事はこちら\nElastic MapsやUptimeといった、これまでの可視化とは異なる便利なアプリが増え始めました。Mapsでは地図の表現が格段にアップしたので、コレまで以上に地理情報と合わせた可視化が楽しくなりました。\nもちろん、基本的に必要な技術が着実にGAされていくのもElastic Stackの素晴らしい点です。\nIndex Lifecycle Management(ILM)がGA Cross Cluster Replication(CCR)がGA CanvasがGA Logs \u0026amp; Infra UIがGA Elastic Stack 7.0.0リリース(4月) リリース記事はこちら\nメジャーバージョンのリリースです。 KibanaのUIが刷新されたり、Elasticsearchのクラスター管理の機能が新規に構築されたり、様々な改善がこのリリースでも入っています。また、メジャーバージョンのリリースのタイミングが、さまざまな大きな仕様の変更や改善が入るタイミングでもあります。これまで以上にパフォーマンスが改善（Top-Nクエリ高速化など）されたり、新しい機能の追加（ナノ秒のサポート）されたりしました。\nElasticsearchのセキュリティの主要な機能が無料に(5月) リリース記事はこちら\n6.8.0および7.1.0のリリースはこの機能の無償提供となりました。 結構衝撃的な話だったのではないかなぁと。これ以前は有償の機能だったセキュリティの以下の機能をElastic License配下で無料で提供する形に変わりました。まだ、ご存知でない方は、データの安全のためにもセキュリティ機能を利用することをおすすめします。\nTLSによる通信暗号化 ユーザー作成と管理にファイルおよびネイティブのレルム認証を使用可能 クラスターAPIとインデックスに対するユーザーアクセスの管理にロールベースのアクセス制御を使用可能、またSpaces機能でKibanaのマルチテナンシーの安全性を向上 Elastic{ON}19開催(5月) 今年も東京で開催しました。ビデオなどはこちらで公開されています。 https://www.elastic.co/elasticon/tour/2019/tokyo\n今回も偉そうにElatic Stackの新しくなった点を紹介するなどしてました。。。\nElastic Stack 7.2.0リリース(6月) リリース記事はこちら\nElastic SIEMがベータリリースされたのがこのタイミングです。 2月の発表したElastic Common Schemaをフルに活用していると言ってもいいのがこの機能になります。まだ今後もどんどん改善が入るであろうきのうになります。\nまた、Elasticsearchをバックエンドにした検索ミドルウェアとして利用いただけるElastic App Searchのセルフマネージド版もこのタイミングでリリースされています。\nさらに、このリリースの直前にはElastic Cloud on Kuberunetes(ECK)というものベータリリースされました。少しわかりにくいかもですが、ElasticsearchやKibanaをKubernetesのOperatorとして利用できるようになっています。こちらもElastic Licenseでリリースされているのでk8s上でKibanaやEsを管理しようとしている方は触ってみると面白いかもです。\nElastic Cloud Elasticsearch ServiceがGCP日本で利用可能に(7月) リリース記事はこちら\nElastic Cloudもプラットフォームが拡大した年でした。 Google Cloud Platformの東京リージョンを選択できるようになりました。さらなる統合（支払いをGCP経由にまとめたり、GCPのコンソールから利用できたりなど）も進んでいます。\nElastic Stack 7.3.0リリース(8月) リリース記事はこちら\nデータフレームと呼ばれるデータ取り込み時のピボット機能が導入されました。また、MapsのGAリリース、Elastic APMの.NETエージェント正式リリースなど、細かいですが様々なものがリリースされています。\nElastic Cloud Elasticsearch ServiceがAzureで利用可能に(9月) リリース記事はこちら\nMicrosoft Azureへのデプロイも可能になりました。残念ながらまだ日本リージョンには来ていないですが、今後出てくるはずです！さまざまなクラウドベンダーのサポートにより、より多くの人に使っていただけるようになるのかと。\nElastic Stack 7.4.0リリース(10月) リリース記事はこちら\nもう7.4.2まで出ていますが、いい感じの間隔で7.0、7.2、7.3と来ていますね。 7.4では、スナップショットリストアがKibanaから簡単に行えるようになりました。これまではKibanaのConsoleでJSONを見ながら管理されていたかもですが、GUIにより今どんなスナップショットがあるのか、どれをリストアするのかといった操作が簡単にできるようになっています。\nKibanaについてはPKI認証のサポートなども始まり、様々な認証方式でより便利にKibanaが使えるようになっています。\n12月？ 12月ですし、Elasticsearch勉強会では「LT＆忘年会」ということで、懇親会がメインの勉強会として12/6に開催します。悪路クエストの緑川さん、吉岡さんに主体となっていただき、マイクロソフトさんを会場に借りて開催予定です。興味のある方はぜひご参加ください。 LTもおまちしています！\nまとめ 駆け足でしたが今年を振り返ってみました。 今年も色々ありました。残すところあと1ヶ月です！\nさて、Elastic Stack Advent Calendar 2019は今日から25日まで続きます。今年はその2もできています！こらからの記事を楽しみにしています！ 本日はその2で[kaibadash@github]さんが「5分でできるElastic stack環境構築」というのを書いてくれてるはずです！\nということで、次はKunihikoKidoさんの「 Elastic Cloud を使うようになって設計方針やら変わったことについて書きます。」になります。お楽しみに！\n","date":1575126000,"dir":"post/2019/","id":"78da47d61c91c82809a3c97a791d26d2","lang":"ja","lastmod":1575126000,"permalink":"https://blog.johtani.info/blog/2019/12/01/whats-happen-at-elastic-in-2019/","publishdate":"2019-12-01T00:00:00+09:00","summary":"Elastic stack (Elasticsearch) Advent Calendar 2019の1日目の記事になります。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみようと思います。毎年恒例ですね、","tags":["elasticsearch"],"title":"2019年のElastic StackとElastic"},{"contents":"Bonfire Data \u0026amp; Science #1にブログ枠で参加してきました。 ということで、メモです。\n日時 : 2019/10/25 19:00 - 21:30 場所 : Yahoo! Japan サイト : https://yj-meetup.connpass.com/event/148121/ ハッシュタグ: #yjbonfire 概要 Data \u0026amp; Scienceとは？ データとサイエンスに関わる人達の情報共有のための勉強会/交流会\nサイトから引用です。\n第1回のテーマは「画像検索」です！ 最近EC系のサイトで類似画像検索が出来るようになったけどどうやってるの？ 画像検索のモデルってどうしてるの？ 画像検索のインフラはどうしてるの？ 私たちの会社でも画像検索を用いたサービスを構築できるだろうか？ こういった疑問に答えたり、いま抱えている悩みを解決するヒントを得る場になればと思っています。 今回は、画像検索を行なっているヤフー, メルカリ, ZOZOテクノロジーズの3社に事例と基盤技術について登壇いただきます。 QAはこちら。https://app.sli.do/event/w3wayjmv/live/questions\nMercari画像検索について(仮) 発表者：荒瀬晃介(株式会社メルカリ / AIエンジニアリングチーム)\nAIエンジニアチーム\n写真検索プロジェクトのTech Lead\niOSのみで提供の写真検索\nシステムオーバービュー\nMobileNet v2で特徴抽出 ANNのインデックスを使ってDBに入れる 論文も発表済み（3本）\n今日の発表はこの内の2本を元に話をします。 C2Cでの問題点 商品は床やテーブル上で撮影 クエリは着用（着ている）画像が使われやすい。 人が写ってる写真が結果に多いと業者が出展しているように見えてしまう。 提案手法 人が写ってるものから人の代表ベクトルを抜き取る (クエリ時にのみ処理を実施しているので変更が容易) 特徴変換ベクトル トップスなど、分類ごとに学習させてからベクトルを構成 なんでMobileNet v2? エッジデバイスでの処理を見据えて選択 インフラ Docker + k8s\nCRDを使ってる？\ntraining\nコンテナベースパイプライン いくつかのバッチ処理を工程ごとにパイプライン化 バッチ実行情報をカスタムリソースとしている＝再実行が簡単（復旧作業が容易） 画像を扱う＝ダウンロードが時間がかかる -\u0026gt; 復旧しやすいようにPVにある程度キャッシュさせている Serving\u0026hellip;\nGCP側 なぜ2つに別れてるんだろう？実際のサービスも2つに分かれてたりするんだろうか？\n将来の展望 Realtime Image Search カメラでものを写している状態でそれが何かを検索できる。 物体検出＋特徴抽出をエッジで行うためできる エッジの性能により違いが出てきたりするっぽい QA Q: 業者が想定されると、購入意欲を下げるというのは実験した結果？それとも想像？ A: 実験はしていないが、e-commerceにおいての研究がある Q: どういう理由でマルチクラウドにしたんでしょう? A: 画像のマスターがAWS。メルカリのマイクロサービスはGKEなので、サービング環境がGCP Q: 画像の内、服のエリアが大部分で体の面積が少ない場合と、メガネや帽子のように、アイテムの方の面積が少ない場合で、トレーニングに必要なデータ数は変わりましたか？ A: カテゴリによる性質の違うはある。ので、改善は必要。 ZOZO画像検索について(仮) 発表者：平田拓也(株式会社ZOZO / AIエンジニアリングチーム)\n(聞き逃した。。。)\nWEAR\nマルチサイズ\nチーム構成 研究所＋ML Opsチーム 使用しているアルゴリズム 物体検出アルゴリズム 特徴量抽出アルゴリズム 近似最近傍探索（approximate nearest neighbor, ANN） インフラ GCPを採用。 BigQuery上にデータ基盤がある Managed GPUが必要 なんでk8s? コンテナ Cloud Runがなかった アーキテクチャ マイクロサービス化されている Google Cloud Next 2019 Tokyoでsonotsさんの発表があるよ 監視項目 CPUなどは見ていない レスポンスタイムとステータス監視 リクエスト数 APM 使ってるものStackdriver + Datadog + Sentry Warningが30分で続けたら通知などができるのがStackdriver 画像検索の改善のためにやっていること 課題 レイテンシーが大きい 推論が大変？ 急激なトラフィックの増加に対応できない GPUのスケールアウトが問題 -\u0026gt; 先行投資が必要 流れ キャッシュありなし 物体検出 (GPU) 特徴量抽出 (GPU) 近似最近傍探索 DBから取得 2と3が問題\n2と3を特徴量DBという形でデータが登録された時点で特徴量などを計算してしまうことでGPUへの依存をなくした。 Apache AirFlowが便利？ Cloud ComposerとApache AirFlow Cloud Composerに関するいくつかのTipsがありました。\nQA Q: 推論をCPUでやったらどれぐらい遅いんだろう A: GPUインスタンス代金 \u0026lt; それと同等の速度を出すためのCPUインスタンス代金 Q: k8sスケールアウト時のリソース割当を最適化する為、resource limit / request標準化 or 時系列分析などから自動調整するなどはされていますか？ A: \u0026hellip;聞き逃した Q: (TCOを考慮したクラスタ構成) Cloud Composerの値段が高いようなパプリッククラウド利用の課題対策としてプライベートクラウドとのハイブリッド構成にされているのでしょうか？もしハイブリッド構成でしたら、パブリック or クラウドを切り分ける基準はございますか。 A: GKEオンリー Q: cloud composerでairflowを使う辛い点は？ A: 不安定さ。。。 Yahoo!ショッピングにおける画像検索(仮) 発表者：佐藤 純一(ヤフー株式会社) 商品検索APIの開発とか検索エンジンの保守とか 類似画像検索システムの開発が直近の仕事 類似画像検索 ヤフーショッピング 3億の商品 ファッション系はビジュアルが重要＝言語による表現が難しい iOSとAndroid Androidだとカメラで撮影してから検索みたいなことも可能 システム概要 物体検出 ノイズ除去 特徴抽出 インデックス(NGT) -\u0026gt; https://github.com/yahoojapan/NGT 1000万件を超える 検索 アプリの画像をAPIに投げてベクトルから、近いものn件を取得 ベクトル化/インデックス更新 GPUマシン Kafka使ってる クラウドストレージに日次？バックアップみたいに保存 差分更新の仕組みがある メンズとレディースは分けている 絞り込み検索のために分離（インデックスのメタデータとしてタグがある） システム構成 Python Kafka TensolflowServing 可視化？監視？はGrafana＋Prometheus 開発を通しての学び 自動デプロイとかテスト 検索精度の確認ツールを作る コレ重要だよね。何が変更してるかとか、何が正しいかってのが必要だし。。。 復旧可能、早期復旧の仕組みを容易 今後の方針 対象商品の拡大 物体検出特徴抽出モデルの性能改善 NGTの検索システムをValdに移行 Vald k8s上で動作、分散検索、分散インデキシングなどの機能を提供予定 QA Q: iOS(既存の画像)とAndroid(カメラで撮る)で画像検索の方式が違うのはなぜ？ A: アプリの違い Q: 1枚の写真に沢山写っている中で、対象の商品をどう識別しているんでしょう。靴もトップスもボトムスも写っていたら、かなり難しそう A: Yahooブラウザの場合は1番大きな領域のものを選択。Yahoo shoppingだと選択可能 NGTについて(仮) 発表者：岩崎 雅二郎(ヤフー株式会社) 類似画像検索を20年くらいやってる 近傍検索ライブラリ https://github.com/yahoojapan/NGT\n高次元ベクトルの近傍検索 ツリーとグラフによるインデックス 近傍検索とは?\n距離空間上でのクエリの近傍のオブジェクトを取得 k最近傍検索（通常はこっち） 範囲検索（あんまり使われない） NGTの特徴\n世界トップレベルの高速高精度な近似近傍検索 OSS 追加削除が可能（削除がとくに難しいらしい） 多様な利用形態（Python、C++、C、Go、コマンドライン） サーバ版NGT（ngtd、vald）を提供 共有メモリ版でメモリサイズ以上のデータ登録可能 量子化版NGT（NGTQ）により。。。 ANNベンチマークによりテスト\n実行環境が決められているらしい。誰が実行しても比較可能 グラフベースの検索の仕組みのほうが性能がいいというのがベンチマーク結果からわかる なんではやいの？ インデックス生成 ツリー（グラフの探索起点の取得に利用する。DVP-tree） グラフ（ANNG） ノードを逐次追加しつつ、近傍ノードを検索してから接続するというのを繰り返している 検索 ツリーから絞り込みつつ、グラフを検索する ANNGに課題があるのでONNG（Optimized Nearest Neighbors Graph）に ノード単位の次数（入出）を最適化 データセットによって有効な次数が違う。。。 NGTを利用した深層学習で。。。 Yahoo!ラボ FavNavi 特徴量の構成（低次特徴量（300次元）、カテゴリ特徴量（128次元）、領域アスペクト比（1次元）） 個別の特徴量だけだとイマイチな結果になるが、組み合わせるといい感じになる モデル性西洋学習データ スライドがあればいいなぁ（表書くの大変だし。。。）\nQA Q: 実際のお客さまの利用を考えると、近似近隣の密度が異なるので、近いものばかりの検索結果や遠いものも含んでしまった検索結果が出ると思うのですが、遠いものが含まれてしまうと、閾値でフィルタしたりするのでしょうか? A: NGTは近いものしかないので、外れ値ってなんでしょう。。。 検索のフィルタリングをある程度している（カテゴリとか）。 まとめ 慣れない分野の話を聞きながらざっとメモを取ったものなので役に立つかはわかりませんが。。。\nアルゴリズムとかまでは得意ではないんですが、画像「検索」ということで参加してみました。 実際に画像検索の仕組みがどんな感じでできているのか、どんな技術がつかわれているのか？ってのがわかったのは 面白かったです。確かに検索のためのキーワードって出てこないことあるしなぁと。 あー、こんなかばんほしいとか、これなんだろ？みたいなのあるからなぁ。\n","date":1572000002,"dir":"post/2019/","id":"11b3a28b536f34d3606427f835bd3ddf","lang":"ja","lastmod":1572000002,"permalink":"https://blog.johtani.info/blog/2019/10/25/bonefire-01/","publishdate":"2019-10-25T19:40:02+09:00","summary":"Bonfire Data \u0026amp; Science #1にブログ枠で参加してきました。 ということで、メモです。 日時 : 2019/10/25 19:00 - 21:30 場所 : Yahoo! Japan サイト : https://yj-meetup.connpass.com/event/148121/ ハッシュタグ: #yjbonfire 概要 Data \u0026amp; Scienceと","tags":["勉強会"],"title":"Bonfire Data \u0026 Science #1に参加しました"},{"contents":"この間のElasticsearch勉強会でAcroquest Technologyの人たちが技術書展7で販売されていた書籍を頂いてしまいました。なので、軽く読んでの感想と宣伝です（これ、電子版とかで買えないのかな？）。\nElasticのパートナーとしても活躍していただいてますが、こういう感じでさまざまなところでElastic Stackを広めていただいていて感謝しかありません。\n章立てとしては以下の通りです。\nElasticsearchでエンタープライズサーチを実現する 同僚が作成、メンテナンスしているFSCrawlerを使った例も書かれています。ローカルのファイル（PDFやJSONとか）をサクッとElasticsearchにインストールしたりするのには便利です。 Kibana Canvasによる柔軟な可視化 Canvasについてどんなものなのか？というのとelasticcofeeというサンプルを元に、その変更の仕方などが説明されています。 Elastic APMによるアプリケーションパフォーマンス監視 Go AgentとAPM自体の使い方の説明です。最近強化されている他の機能との連携（AlertingやMachine Learning）についても触れてくれています。 Kubernetesクラスタのメトリクス・ログ・性能情報の可視化 Azure上でAzure Kubernetes Serviceの上で動いているアプリなどをBeats、APMでデータを取りつつ、他のAzure上にAzure Marketplaceのテンプレートを用いて起動したElasticsearchとKibanaの環境を用いて可視化する方法が説明されています。 ということで、薄い本ですが、手順をおって説明されていたり、7.3と新しいバージョンで書かれているのですばらしいなぁと。 前作の「Elasticsearch NEXT STEP」に引き続きインプレスさんから出たりするのかなぁ？\nちなみに、Elastic APMのRubyに関して興味がある方は、私が前に発表したときの資料がありますので、こちらを参考にしてみてください。\n","date":1570690589,"dir":"post/2019/","id":"d8041ae308961666b15aa1e57b0f9f35","lang":"ja","lastmod":1570690589,"permalink":"https://blog.johtani.info/blog/2019/10/10/review-es-next-step-2/","publishdate":"2019-10-10T15:56:29+09:00","summary":"この間のElasticsearch勉強会でAcroquest Technologyの人たちが技術書展7で販売されていた書籍を頂いてしまいました","tags":["書籍"],"title":"Elasticsearch NEXT STEP 2を頂きました"},{"contents":"Twitterで「Meetup.comに切り替えたらー」みたいな話があったので、 受付用アプリとかなくてという話になったので、普段Elasticsearch勉強会で使用している QRコード生成の仕組みを紹介してみようかと。\nHTMLだけで済むようにQRコードを生成するjquery.qrcode.min.jsってのを使用してます。\nHTMLコードはこちら。\n仕組み 1枚だけのHTMLを生成 MeetupのOAuth2の仕組みを利用(consumer keyを発行する必要あり。) Meetup APIを利用してユーザー情報取得 取得したユーザー情報をGoogle Formに埋め込んだ形で表示するURLを組み立てる 組み立てたURLをQRコードにしてHTMLに表示 受付で、QRコードリーダーを使って、QRコードを読み込むとGoogle Formが開くので、「送信」ボタンを押す 1. HTMLの作成 QRコードを表示するためのHTMLを作成します。Gistに貼り付けてあるので、参考にしてもらえれば。 いくつか埋め込まないといけないものがあるので、個別にそれは説明します。\n2. Google Formの準備 Elasticsearch勉強会では、出席者の情報として、IDと氏名をリストとして保存しています。 目的としては、何人実際に参加したかを計測するのが目的です。 ですので、参加者リストのGoogle Formを作成します。 で、作成した後に、プレビューを表示する。こんな感じ。\nこの時のプレビューのURLをQRコードのURLとして使いたいので、このURLをQRコード表示のHTMLに埋め込みます。\nfunction createGoogleFormURL(data) { var obj = { \u0026#34;entry.1744035444\u0026#34; : data.id, \u0026#34;entry.2031666715\u0026#34; : data.name }; return \u0026#34;https://docs.google.com/forms/d/e/\u0026lt;GOOGLE_FORM_ID\u0026gt;/viewform?\u0026#34; + $.param(obj); } ここら辺です。 returnに書いてあるhttpsで始まる文字列をまず、先ほどのURLで置き換えます。 次に、プレビューのHTMLの中から\u0026lt;input\u0026gt;タグを探して、nameの値を抜き出します。 それをobjのキーに利用します。entry.で始まる文字列が該当します。\nこれで、このURLをQRコードにすれば、値（ここだとIDと氏名）が埋め込まれた形のGoogle Formがスマホのブラウザで起動します。\n3. Meetup APIの準備 MeetupのAPIを利用できるようにします。Meetup.comにログインするとみれるAPIのページがあります。 https://secure.meetup.com/meetup_api\nまず、OAuthを利用するためのConsumer Keyを発行します。\nメニューのOAuth Consumersをクリックして、\n\u0026ldquo;Create New Consumer\u0026quot;をクリックします。 すると、次のような画面が開きます。\nConsumer nameとRedirect URIが重要です。\nConsumer nameはユーザーがMeetup経由で認証するときに、その認証画面で表示される名前になります。 わかりやすい名前を表示してあげると良いかと。\nRedirect URIが一番重要です。実際にOAuthで認証が通った後に表示するHTMLを提供しているURLを指定します。 Elasticsearch勉強会の場合は、私のドメインにwwwをつけた\u0026quot;https://www.johtani.info\u0026quot;を指定しています。 実際にQRコード表示用のHTMLを配置するHTTPサーバーのトップのURLを指定します。 （ちなみに、私のウェブサーバーはS3で運用してます。ですので、HTMLをS3のバケットにアップロードしてあるだけです）\n必須項目を入力したあと、最下部にあるRegister Consumerボタンを押せばキーが生成されます。 生成されたキーがOAuth2のURLのパラメータに必要になります。\nこれで、リダイレクトの準備が整いました。\nOAuth2のURLには、Implicit Flowを利用します。 これで、リダイレクト先のHTMLにトークンがわたるので、Meetup APIにこのトークンが使えるようになります。\n認証用のURLはこちらです。このURLを参加者宛のメールに入れて毎回送信しています。\nhttps://secure.meetup.com/ja-JP/oauth2/authorize?response_type=token\u0026amp;redirect_uri=\u0026lt;QRコード表示HTMLのURL\u0026gt;\u0026amp;client_id=\u0026lt;コンシューマーキー\u0026gt; 参加者はこのリンクをクリックすることで、次のような画面が出てきます。 ログインしていない場合はLog in画面が表示され、まずはログインを促されます。\nで、Allowをクリックすれば、redirect_uriに指定されているページが表示されるわけです。\nQRコード表示用のHTMLでは、次のAPIを使用して、ログインしているユーザーの情報を取得してきています。\nfunction getMemberId() { $.getJSON(\u0026#39;https://api.meetup.com/2/member/self/?only=id,name\u0026amp;access_token=\u0026#39;+ getToken(), displayQRCode); } ここで取れた値が、先ほどの「2. Google Formの準備」で説明したコードのdataの部分に渡ってくるわけです。\nfunction createGoogleFormURL(data) { var obj = { \u0026#34;entry.1744035444\u0026#34; : data.id, \u0026#34;entry.2031666715\u0026#34; : data.name }; return \u0026#34;https://docs.google.com/forms/d/e/\u0026lt;GOOGLE_FORM_ID\u0026gt;/viewform?\u0026#34; + $.param(obj); } 4. QRコードの表示 あとは、jquery.qrcode.min.jsを使用してURLを表示するだけです。\nfunction displayQRCode(data) { $(\u0026#39;#qrcode\u0026#39;).qrcode({width: 128,height: 128, text:createGoogleFormURL(data)}); } サイズとURLを指定するだけですね。\nまとめ あとは、受付で、参加者の方が表示してくれたQRコードをスマホのQRコードリーダーやカメラで読み込めばGoogle Formが開いて必要な情報は入っているので、「送信ボタン」を押せば参加者リストが出来上がっていくという形になります。\n毎回勉強会の前日に、前回のGoogle Formを「コピー」してから、各回の勉強会の登録者フォームを作成しています。 コピーすることにより、Google Formの\u0026lt;input\u0026gt;タグに使用されるnameもそのままコピーされるので、 QRコード生成用のHTMLを書き換える部分の手間が減る形になっています（気づくまで数回かかったw）。\nですので、QRコードのHTMLの中身としては、「勉強会のページへのリンク」、「Google Formへのリンク」の2つを書き換えてから毎回アップロードしているだけとなっています。\nこのやり方が、スマートかどうかはわからないですが、受付アプリがない中、Meetup.comから取得した参加者リストのExcelやプリントアウトしたリストを元に参加者をチェックするよりは、手間が省けてるんじゃないかなぁと。\n残念ながら、QRコードの存在を知らないでそのまま勉強会にくる人がいるので、受付で最低一人はMeetup.comの参加者リストから、 名前を検索してチェックするという作業もやってもらってます。 QRコードを持ってきた方がすんなり受付を通過できるようになってますので、ぜひQRコードを持って勉強会にきてもらえればと。\n","date":1560939044,"dir":"post/2019/","id":"d96f80f23543850a2ee9fff8cd2cc53f","lang":"ja","lastmod":1560939044,"permalink":"https://blog.johtani.info/blog/2019/06/19/qr-code-with-meetup-dot-com/","publishdate":"2019-06-19T19:10:44+09:00","summary":"Twitterで「Meetup.comに切り替えたらー」みたいな話があったので、 受付用アプリとかなくてという話になったので、普段Elasti","tags":["勉強会"],"title":"勉強会の受付自作？アプリ？HTMLについて"},{"contents":"Elasticsearch勉強会や検索技術勉強会やってるんだけど、独学で勉強会やってるなーと思い、みんなはどうやってるんだろうとツイートしてみたところ。\nあー、勉強会運営座談会したい。\n\u0026mdash; Jun Ohtani (@johtani) 2019年4月2日 面白そう\n\u0026mdash; 機械の体を手に入れるのよ鉄郎 (@tetsuroito) 2019年4月2日 やってみるか。\n\u0026mdash; Jun Ohtani (@johtani) 2019年4月2日 やりましょう\n\u0026mdash; 機械の体を手に入れるのよ鉄郎 (@tetsuroito) 2019年4月2日 ってことで、何人か釣れたので、勉強会運営座談会をやってみました。 会場提供していただいた、Classiさんありがとうございました！\n参加してくれた人たちはまぁ、勉強会のサイトを見ていただければなんとなくわかるかなと。 自己紹介とどんな勉強会、読書会運営してますってとこから始めて、次のようなトピックについてピザ食いながら3時間くらい話しました。\nスピーカーの募集方法 運営側から声かけてる？それとも公募してる？ 登壇時間とかどうしてる？ スピーカーになってもらうためになんかやってる？ スケジュール管理 会場探し、スピーカー探し、イベントページ作るタイミングは？ 複数拠点開催したことある？ ハンズオンとかはどうしてる？ 土日開催？平日開催？ アンケートとってますか？ 使用してるイベントサイトは？ ドタキャン対応どうしてる？出欠とったりしてる？懇親会の規模とかどうやって見積もってる？ 運営費用関連はどうしてる？ グッズとか、ツールとか、スピーカーへの謝礼とか 運営って複数でやってる？ その時のツールは？ 運営メンバーにはどうやってなってもらう？ 録画配信とかまで手が回る？ 会場探すの大変じゃない？ 会場の部屋の使い方はどうしてる？ 行動規範とかどうしてる？ 読書会の場合に人が減ってったりしない？ まぁ、こんな感じです。色々話してメモしてたんですが、まぁトピックくらいで。\nそもそもは、勉強会の運営って本業ではない（はずな）ので、いかに楽をしつつうまく運営できるかってのを知りたいのと、 他の人どうやってるかってのからアイデアもらえるといいなーと思ったんでやってみました。 他のツールがどんなものかとか知れたし、あー、そういうやり方すればいいのねーみたいなのも知れたので、次回以降の勉強会に活かせればなーと。 自分がやってるやり方とかもブログ書くといいのかなぁ？\n残念です！次回もやるかもしれないので、 @johtani さんに期待してください！\n\u0026mdash; 機械の体を手に入れるのよ鉄郎 (@tetsuroito) 2019年4月25日 次回やるのかなぁ？興味ある人いるのかなぁ？\n","date":1556204526,"dir":"post/2019/","id":"538e38fbc3f78cd61e1841d8141ddcc1","lang":"ja","lastmod":1556204526,"permalink":"https://blog.johtani.info/blog/2019/04/26/meetup-organizer-drinkup/","publishdate":"2019-04-26T00:02:06+09:00","summary":"Elasticsearch勉強会や検索技術勉強会やってるんだけど、独学で勉強会やってるなーと思い、みんなはどうやってるんだろうとツイートして","tags":["勉強会"],"title":"勉強会運営座談会ってのをやってみた"},{"contents":"どーも、johtaniです。\nSearch Engineering Tech Talkという勉強会に運営として参加して、第1回の勉強会を開始しました。 本日（2/26）は第1回目だったので、ブログを残しておこうかと。\n勉強会自体の資料については第1回の勉強会のページにあるし、勉強会の感想とかブログはツイートやみんながブログを書いてくれると思うので、勉強会開催の経緯などについてブログを残しておこうかと。\nなんで始めたの？ 私自身が古くはFAST Searchに始まり、何か縁があって、 検索のシステムに長く携わってきたこと（Apache Solrの本書いたり、Elasticsearch勉強会始めたり）もあり、 検索が面白いなと日々思ってます（思ってるだけかもしれないが）。\nで、これまでElasticsearch勉強会をやっているのですが、検索エンジン固有の話ではない、 いわゆる検索の共通の課題というのがあるなぁと。 そういう課題やノウハウって、製品に限らず共有できれば面白いことがもっとできるんじゃないだろうか？ と感じることが多々ありまして。 オープンソースのコミュニティをソースコードをベースではなく、共通の課題・話題を中心としたコミュニティが あってもいいんじゃないかなぁと。\nまぁ、要は、私がみんなの検索で困ってることとか、どうやって検索システム考えてるのかが聞きたかったわけですよ。\nということで、一人でやっても面白くないので、興味ありそうな人を募ってやってみようということを始めたのが2018年12月くらいです。\n運営とかどうしてるの？ まずは、共同主催者（コアメンバー）を募集してみようということで、Googleフォーム作って、 興味ありそうな人がいる場所に投稿してみました。（TwitterとかFBとか） で集まったのが今回紹介したメンバー（スライド参照）です。 ユーザー企業の人もいれば、私みたいな検索エンジンの人もいるので面白い感じにできたかなぁと。 で、スピーカーを運営や知り合いに声をかけて第1回をやってみたという感じです。\n今後どうするの？ 残念ながら次回はまだ未定です。 2ヶ月に1回くらいのペースで開催できればなーと思ってますが、スピーカーが集まるかなどによるかなぁと。 ということで、勉強会のグループのページにスピーカー応募フォームのリンクがありますので、スピーカーに興味がある方は入力していただければと。\nもちろん第2回はやりたいので、勉強会のページからの連絡をお待ちください！！\n","date":1551191880,"dir":"post/2019/","id":"b27bdabd8e1a6b7dc06886867331ceb3","lang":"ja","lastmod":1551191880,"permalink":"https://blog.johtani.info/blog/2019/02/26/start-search-engineering-tech-talk/","publishdate":"2019-02-26T23:38:00+09:00","summary":"どーも、johtaniです。 Search Engineering Tech Talkという勉強会に運営として参加して、第1回の勉強会を開始しました。 本日（2/26）は第1回目だったの","tags":["勉強会","検索"],"title":"Search Engineering Tech Talk(検索技術勉強会)の運営として参加して始めてみました。"},{"contents":"今年も振り返りブログをかけてます。よかったw\n振り返り（2017年に書いた抱負から） まずは去年の抱負を元に。\nもっと英語の継続＆TOEIC まぁ、継続してます。英会話も続けてますし、海外TVドラマや映画見てます。 ただ、昨年書いたTOEICはイベントが被りまくってて受けれてないです。。。 来年は受けれればいいが。 ちなみに見たドラマはこの辺。あんまり見てないなぁ。 「はじまりのうた」は飛行機の中で見たんですが、よかったです。 最近は音楽系の映画が好きなのかなぁ。グレーテストマンショー（ミュージカル風）とかもハマったし。\nGame of Thrones はじまりのうた BEGIN AGAIN (映画) 24 シーズン4まで 今は、ボキャブラリのなさに苦しんでる感じです。キクタンとかするべきなのかもなぁ。 基本勉強が下手だからなー。\n継続的にイベントに登壇 ＆ CfPもっと出すぞ！ OSCには出てました。あとは、いくつかに呼ばれて出たりでしょうか。 CfPはJJUGしか出せてない気がするんで、もっと出さないとですね。。。 春のJJUGでは20分で短すぎた「オープンソースとビジネスモデル」の話（同僚のネタ）が 今年面白かった内容かなぁと。 もっと話を作るのをうまくしないとだろうなぁ。 ユースケースが増えてるんで、もっといろんなところに出ていかないとなぁと。 ブースの出し方とかもちょっと考えないといけないかもなーと思ってたり。 マンネリになってきてる気がするんで、なんか取り入れないとなぁ。\nもっとブログ！ 出だしはよかったんですが、途中でRustネタのブログも止まってしまいましたね。。。 業務が忙しくなったのを言い訳にして時間が取れなくなってるんで、 もっと習慣つけないとなぁ。\n雑誌やWeb系雑誌で記事を。 できてないです。。。どうすっかなぁ。 重い腰上げないのが問題なんですけどね。。。 自社のウェビナーとかはそこそこやってましたが。\nコミュニティを別の方法で盛り上げ フォーラムは皆さんのおかげで盛り上がってきてる気がしてます。 別の方法ではなく、勉強会を9月から毎月開催にして、ユースケースごとに切り替えてみました。 あとは、スピーカー登録用のフォームの用意とかして、継続的に楽にスピーカーの人たちが見つけられるようにと。 私は「全然」関わってないんですが、技術書典でいろんな方に書籍を書いていただきました。 また、Elasticloverという毎週いろんな記事をまとめていただけ助かりました。 少しでも感謝をということで、コミュニティランチというイベントで、フォーラムで回答していただいてる方や、書籍を出していただいた方を招いてCEOのShayとランチするというイベントもやってみました。 少しは盛り上げられたかなぁ。 次は、ハッカソンみたいなのとかやってみるのもありなのかなぁ？（サポートしきれない気がするんだよなぁ）\nElasticsearchなど検索系の開発にも参加 開発。。。 Analyzer向けのKibanaのプラグインの開発は継続してますが、あんまり開発してないですねぇ（GitHubの草をみながら)。 ちょっとしたPRはやったりしてますが、もっとやりたい。。。 とりあえず、来年しょっぱなは、検索系じゃないですが、KibanaのプラグインのReact化をやらないとなぁと。\n振り返り(今年あったできごと) さて、反省が多かったですが、ここからは今年の出来事を。\n初スノーシュー in US オフィス引越し パリで料理w K8sとde:code QNAPとか IPO! 初のオンライン登壇 初アイルランド! Pixel3 XL 今年も初モノがちらほら。\nアメリカでスノーシューやりました。昨年は釣りでしたが、今年はスノーシューでした。 スノーシューはすごくよかったんですが、サンフランシスコから社内ミーティングのある場所までの 移動に10時間バスに缶詰という変な初モノもありました。。。 スノーリゾートのある山の上にバスで移動だったんですが、前日までの天候の生でチェーン規制が出てしまい、登りかけた山を降りて、違う経路で登り直すという長旅でした。。。 途中からずっとゲームオブスローンズみてました。。。\nオフィスが引っ越しました。人数が増えてきたのもあり、銀座のWeWorkに引っ越しました（私はあんまり行かなかったりしますがw）。 ただ、すでに手狭になってきて、来年はまた引っ越してるかもなぁ。 今年の終わりで日本のメンバーが22名に増えました！すごい！4年半前の22倍！\nパリで料理もしましたwセールスのキックオフミーティングがパリで開催され、なぜか参加してきました。 そこで、DevRelチームのミーティング＆ディナーがあったんですが、ディナーがアクティビティ付きで、チームのみんなとパリで料理やカクテル作ってきました。 まさか、パリで手巻き寿司作るとは思わなかった（怖くて食べてないですw）\n今年はイベントが連続することが多かったです。パリから帰ってすぐにde:codeでMSの川崎さんと登壇したりしました。Kubernetesを触る機会ができたんでよかったですが、時差ボケは辛かったw今年は他にもカンファレンス直後にトレーニングだったりと、夏に喉やられちゃいました。喉に負担をかけない話し方の練習すべきなんだろうなぁ。\n自宅の環境もちょっと整えました。10年前から使ってた、TeraStationをQNAPに刷新。快適に検索できるわ、クラウドにバックアップとれるわで、すごく快適です。 あとは、自室のディスプレイをディスプレイアームにつけたり、壊れたモニタースピーカーをYamahaのパワードスピーカーに買い替えたりと。 ちょこちょこ自宅で作業したりするんで、快適です。\n今年はめでたいことに会社がIPOしました。ニューヨーク証券取引所で株式公開しました。 転職して4年、初体験なんで何がどうってのはいまいち実感わかないんですが、順調にきてるのは嬉しい限りです。今後も頑張りますよ！\n自社のウェビナーでは、オンライン登壇してたんですが、インフラ勉強会でオンライン登壇させていただきました。 Elastic Stackの入門的な話をさせていただいたので、興味があればみていただければと。 こういうのにはマイクが非常に重要だなというのが結論です。ウェビナーで使ってるShureのマイクで話したので聞き取りやすかったです。 来年はもっと手軽にちょっとしたウェビナーとかポッドキャストやろうかな、ということで、持ち運び用にSAM SONGo Micを購入してみたのでどっかで試してみたいなー。\nアイルランド（ダブリン）にも行きました。これまた、社内のミーティングなんですけどね。半年に1度エンジニアが集まる社内イベントがあるので、いろんなところに旅をさせてもらっていて、すごく楽しいです。 みんなにも会えるし。ただ、アイルランドの英語はきつかった。。。\n最後はPixel3です。SonyのXperiaをここ数年は使ってたんですが、電池の持ちなどが悪くなったんで、気になってたPixel3に変えました。すごくいい。いらないものが入ってないのもいい。あとカメラがすごくいい。他の機能をまだちゃんと調べてないんで、誰か便利機能知ってたら教えてくださいw\nとまぁ、こんな感じでした。\n来年の抱負 最後は来年の抱負を。\nTOEIC CfP見つけて応募 \u0026amp; いろんな場所に顔を出す もっとブログ！ Rustの継続 開発の継続 日本でエンジニア獲得! まぁ、英語ですね。これは地道にやるしかないんだろうなと思いつつ、コツコツが苦手でw とりあえず、今年はどこかでTOEIC受けないとな。\nいつも行かないけど、弊社プロダクトに関係のあるカンファレンスのCfPを見つけ出して、 応募しまくって、少しでもしゃべらないとなぁ。喋れなくても、Elasticsearchがらみで登壇していただいてる方がいるカンファレンスには顔を出していきたいなぁと。 登壇される方いたら、ぜひ連絡ください！あとは、CfPのサイトを探す仕組みを作らないとなぁ。 検索サイト作るかなぁ。 あとは、カンファレンスではなく、いろんな会社に遊びにいきたいと思ってます。 入門的な話をしてほしいような方、こんな使い方してますっていう話をしていただける方、大募集です。 これもGoogle Formでも作ってみるか。\nブログなぁ。小さな習慣を読んだのに、習慣化できてないので、なんとかしないとという意味で。。。が、頑張ります。。。\nRustの継続＆開発の継続もですね。Java歴が長いので、他の言語を勉強しようと思ってRustやってますがなかなか身についてないというか、時間を取れてない。これもコツコツやらないとなー 検索関連の開発もちょっとずつやりたいなと思ってるんで、LukeへContributeしようかな。\n切実なんですが、日本に弊社のエンジニアを増やしたいなと。特に人前で喋ってもらえる人が増えると助かるんです。弊社最近、ユースケースが増えてきてて、追いつかなくてwダレカタスケテーw\nさーて、そろそろ紅白のサザンが始まるんで終わりです。\n今年も様々な方々に様々な面で助けていただきました。本当にお世話になりました。 この場を借りてお礼申し上げます。\n来年ももちろん、助けてもらうんで、よろしくお願いいたします！ あと、話聞きたい方、声かけてくださーい。\n","date":1546240485,"dir":"post/2018/","id":"6c226ee1519fbf910197cc1d5c5a5756","lang":"ja","lastmod":1546240485,"permalink":"https://blog.johtani.info/blog/2018/12/31/looking-back-2018/","publishdate":"2018-12-31T16:14:45+09:00","summary":"今年も振り返りブログをかけてます。よかったw 振り返り（2017年に書いた抱負から） まずは去年の抱負を元に。 もっと英語の継続＆TOEIC まぁ、","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2018）"},{"contents":"Elastic stack (Elasticsearch) Advent Calendar 2018の25日目の記事になります。 今年最後のAdvent Calendarです！来年も忘れてなければやるはず！\n今日は、すでにalpha2までリリースされた7系でどんな変更が入るのかをちょっとだけ紹介します。 ほんとにちょっとだけですよ。\nKibanaのk7 design (kibana) Kibanaの新デザインです。K7って呼ぶのかな？\nまだ、メニューと一部が実装されているだけですが、7.0.0でガラッと変わりそうです。 そのほかの画面のIssueはこちらです。 \u0026ldquo;k7\u0026quot;で検索しただけですが。メタIssueが見つからなかったんで。例えば、こんな感じでアプリとかのスイッチとかがこんな感じになるよというデザイン案が観れたりします。\nZen2 (elasticsearch) Elasticsearchの新しいクラスター管理機構アルゴリズムになります。 Zenと呼ばれる独自実装のものを6系までは使っていましたが、7系向けに変更がかかりました。 実際には、Nodeを探す仕組み、Masterの選出アルゴリズム、クラスター状態の管理などを行います。 上記のリンクにあるようにドキュメントも詳しくなりました。 信頼性をさらに向上し、設定ミスを起こしにくくして、より使いやすくという目的で様々な変更が加えられています。 これが、メタIssueかな？ アルゴリズムの変更や、クラスターの状態の管理の方法などの変更に関するIssueやPRにリンクが貼ってあります。\n新しいデータタイプ (elasticsearch) Feature/Feature vector datatype ドキュメントはこちらとこちら\nfeature queryと合わせて使用するためのフィールドで、しかもクエリのスコア計算「のみ」に使用するフィールドになります。 検索条件やソート、Aggregationの対象ではなく、クエリのスコアに影響させたい値を入れておくためのフィールドです。 6から追加された機能の「track_total_hits」をfalseにした時と合わせると、function_scoreなどで計算をしていた場合よりも、検索性能が上がるという利点まであります。 ちなみに、「track_total_hits」は検索ヒット数を計算しないで、上位のデータを取得する時にクエリを早くするといったことができる機能になります。 Index Sortingと組み合わせることで威力が発揮できる仕組みになるはずです。\nFilebeat supports NetFlow (beats) NetFlowが入力として追加されます。 Filebeatと言いつつ、File以外の入力が徐々に増えてきてますね（UDPやTCPにも対応しましたし）。 ネットワーク機器などの監視を行う方などにはさらに便利になってくるのではないでしょうか？ （私はこの辺りは不得手なので、誰か使ってみてもらえればと！）\nまとめ まだ、序の口って感じですが、今年はこの辺で。7系ではここであげた以外にも様々な機能が追加されています（もしくは予定です）。 Elasticのドキュメントの良いところは、masterブランチのドキュメントも公開されていることです。 ドキュメントのバージョンを7.0.0-alpha2にすれば、masterブランチで追加されたページが見れるので、 興味のある方は眺めてみていただければと。物によって、リリースノートが書かれていなかったりするので注意は必要ですが。\n今年もあと数日になりましたが、Advent Calendarへの参加ありがとうございました！ 来年ももちろんやりますので、年始からネタを考えてくださいね。\n来年一発目は、第28回Elasticsearch勉強会 - 6.5機能紹介 -になります。ウェビナーでも紹介しましたが、6.5で入った様々な新機能をデモありで紹介する予定です。 興味のある方はぜひご参加ください。\nでは、来年もよろしくお願いいたします。\n","date":1545663601,"dir":"post/2018/","id":"ee62cb0b9a97f990df1ed0266a7027e2","lang":"ja","lastmod":1545663601,"permalink":"https://blog.johtani.info/blog/2018/12/25/whats-new-in-elastic-stack-7/","publishdate":"2018-12-25T00:00:01+09:00","summary":"Elastic stack (Elasticsearch) Advent Calendar 2018の25日目の記事になります。 今年最後のAdvent Calendarです！来年も忘れてなければやるはず！ 今日は、すでにalp","tags":["elasticsearch"],"title":"Elastic Stack 7.0で入ってくる新機能をちょっと紹介"},{"contents":"Elastic stack (Elasticsearch) Advent Calendar 2018の1日目の記事になります。\nちょっと遅れちゃいました。。。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみようと思います。毎年恒例ですね、ここ数年。\nElastic Stack 6.2.0リリース(2月) リリース記事はこちら\nAPMがGAリリースされ、Beats monitoring UIも追加されました。Stackとしての統一度がちょっとずつ上がってきた感じですね。 Kibanaのホーム画面（左メニューのKibanaアイコンをクリックした時）にデータ登録のチュートリアル的な画面が追加されています。 特にBeatsを利用する時の流れが簡単にわかるのがいい感じです。Metricsなどはローカルでちょっと試すのにも簡単な流れですので、ぜひ一度やってみてもらいたいなと。 個人的にはtermsを使ったパイチャートで、その他の数値がどのくらいあるかといった表示ができるようになって、やっと帰ってきた！（Kibana 3の頃にはあった機能）という印象でした。\nElastic{ON}18開催(2月) 第4回目のユーザーカンファレンスがSFで開催されました。 今年のキーノートが今年最大のニュースですね。 X-Packのコードの公開が発表されたのがこの時でした。 個人的に今後もオープンソースに携わっていきたいと思いながら日々働いていますが、 Elasticのオープンソースへのこだわりと、シンプルな考え方を再確認して素晴らしい会社で働けてるなーと。 商用のソースコードを公開してユーザーや顧客の皆さんとより良いものを作っていきたいという形ですので、今後もよろしくお願いします！ キーノートの動画はこちらからご覧いただけます。\nそのほかにも次のような発表が行われました。\nSQL for elasticsearch Canvas Elastic App Search(旧Swiftype) Elastic Stack 6.3.0リリース(6月) リリース記事はこちら\n2月末のElastic{ON}で発表されたX-Packのコードの公開にはやはり時間がかかりました。 有償コードのリポジトリとの統合やライセンスの変更、テスト環境などなど、色々大変だったみたいです。 ようやく公開され、ベーシックのライセンスの扱いなども変わり、より使いやすくなったのがこのタイミングです。\nX-Packをプラグインとしてのインストールが不要に ベーシックライセンスがデフォルトでONに。6.3から登録などが不要に。 Apache 2.0ライセンスの部分のみのディストリビューションも別途ダウンロードできるようになどなど 日本でもリリースウェビナーをやりました。ご覧いただけましたかね？\nElastic Cloud Elasticsearch Serviceがより使いやすく(8月) リリース記事はこちら\nこれまでは、メモリとストレージの比率だけしか指定できなかったのですが、 このリリースで様々なユースケースに応じた組み合わせが可能になりました。 CPUやメモリリソースよりもストレージを大きくしたりなどです。 専用マスターノードを追加できたり、待望の機械学習（Machine Learning）が提供されたりと色々と変更があり使いやすくなったかと。 昔からよく聞かれる、Kuromojiなどのカスタム辞書を登録する機能もあるので、Elastic Cloud便利です。 ご存知ない方は、14日間のトライアルもありますので試していただければと！\nElastic Stack 6.4.0リリース(8月) リリース記事はこちら\nフィールドエイリアスや韓国語のアナライザーがElasticsearchに追加されました。 Kibanaはデザインがここからさらに少しずつ変更が入ってたりします。 Elastic UIフレームワークと呼ばれるデザイン用のライブラリが、ElasticのプロダクトのUIに取り込まれていってる感じです。統一感が取れてきてますよね。私が開発しているAnalyze UIのプラグインにも取り込みました。 あとは、マイクロソフトのde:codeで話をさせていただいた、Logstash向けのAzure Moduleがリリースされたのもこのバージョンでした。AzureのEvent Hubからデータを取り込んで、SQLデータベースのモニタリングや、ユーザーの認証などをとってKibanaで可視化するものです。\nもっとも気に入っているのはサンプルデータの登録が簡単になったことです。これまでは、KibanaとElasticsearchを用意した後に、データを入れるためにFilebeatなどを使ってから、ようやくKibanaで遊べるという形でした。 6.4からは、ElasticsearchとKibanaを立ち上げて、Kibanaのホーム画面の「Sample Data」のリンクを押した後に、「Sample flght data」の「Add」ボタンを押せばKibanaからデータが登録されます（サンプルデータについてはこちら）。とりあえず触ってみたいという方への敷居がさらに下がったのではないかなぁと。\nElastic認定エンジニア第1号(8月) ブログ記事はこちら\n認定制度も始まりました。Elasticsearchの知識、経験を問われるテストを受けていただき、合格すると認定されるというやつです。 なんと、社外で世界初の認定エンジニアがアクロクエストの吉岡さんでした（上記ブログ参照）。 私もトレーナーやってるのもあり、慌てて認定をとったりしましたw。 認定テストは筆記ではなく、実際に作業をするテストなので実践的です。 トレーニングの受講が必須ではないのも面白いなぁと思いました。 トレーニングや認定エンジニアに興味がある方は、Elasticのトレーニングのサイトをご覧ください。 1月末にはまた、日本語でElasticsearchのトレーニングも開催されます！\nElastic Cloud Enterprise 2.0リリース(9月) リリース記事はこちら\nElastic Cloud Enterpriseをご存知ない方もいらっしゃるかもしれません。 Elastic Cloudの裏側で利用しているクラスターの起動などの仕組みを製品として提供しているのがこちらになります。 Elastic Cloudで機械学習や様々な構成ができるようになったものがリリースされたのがこの2.0です。 複数のElasticsearchクラスターを管理したい場合には、こちらが便利なツールになってるんじゃないかなぁと。 部署ごとにクラスターを提供するといったことが可能になるので、乱立する前に利用するのも便利かなーと。\nニューヨーク証券取引所で株式を公開(10月) ブログ記事\n日本語でブログ(10月) Elasticsearchの運用に関する典型的な4つの誤解というブログを書きました。4年も働いてるのに、会社のブログに翻訳以外で書いたことなかったので。。。 Twitterや勉強会、ブログ記事などで見かけるよくある誤解に関する記事を書いてみました。 Elasticは英語のブログも活発に書かれているのですが、今後もこのような形で日本語でのブログも頑張りますので、 読んでみたいものなどあればコメントいただければと。\nまぁ、弊社の大輪は色々書いてるんで、私がもっと頑張れって話ですかね。。。\nElastic Stack 6.5.0リリース(11月) リリース記事はこちら\n昨日（11/30）のウェビナーでも話をさせていただきましたが、Elastic Stack 6.5は「本当にマイナーリリース？？？」と思うほど盛りだくさんの機能がリリースされました。\nインフラUI、ログUI Elastic APMの分散トレーシング対応 Java \u0026amp; Go APM Agent GAリリース Cross Cluster Replication ODBCドライバー Kibana Canvas Kibana Spaces Data Visualizer for files Functionbeat LogstashのApp Search output リストアップしただけでもこれです。45分のウェビナーでは伝えきれてないなぁとも思ってますので、何か検討しようと思います！\nElasticsearch勉強会(3月から12月) Elasticsearch勉強会ページ\n今年は、6回の勉強会を開催（1つは12月19日開催）しました。 9月からは、ユースケースなど、もっと参加者の皆さんの興味があることにフォーカスしながら開催をしてみ始めました。 参加しやすくなってればいいのですが。。。 そろそろまたアンケートをとったりして、参加しやすいか、どんな改善がしてほしいかなどを聞きたいなと思っています。\n12月はもっと皆さんと喋りたいなということで、スピーカーなしの「LT\u0026amp;忘年会」にしてみました。 私やElasticのものも参加するので、ぜひ色々聞いたり、他のコミュニティの方達の使い方を聞き出して、 新しい発見をしていただければなーと思います。LTでスピーカーの練習をするってものありですよ！（まだ誰も応募してくれてない。。。） 発表することで、フィードバックがもらえて、自分の使い方に自信が持てたり、その他の視点を得ることができると思いますので、 ぜひ発表してみていただければと。\n12月のjohtani出没イベント 12月は以下のイベントにブースを出してます。イベントに参加される方ははぜひブースにお立ち寄りください！！\n12/4-5 : Japan Container Days - 東京 12/8 : OSC福岡 - 福岡 12/15 : JJUG CCC 2018 Fall - 東京 12/19 : 第27回Elasticsearch勉強会 - 東京 なんか、忙しそうだな。。。\nまとめ 駆け足でしたが今年を振り返ってみました。 今年も色々ありましたが、今後もよろしくお願いいたします。\nさて、Elastic Stack Advent Calendar 2018は今日から25日まで続きます。こらからの記事を楽しみにしています！\nということで、次はkaibadash@githubさんの「ぼくの考えた最強のElasticsearch index設定を最強にわかりやすく書くぞ！！！」になります。お楽しみに！\n","date":1543628918,"dir":"post/2018/","id":"ba45ddd3042dad59a12e5937644f7246","lang":"ja","lastmod":1543628918,"permalink":"https://blog.johtani.info/blog/2018/12/01/whats-happen-at-elastic-in-2018/","publishdate":"2018-12-01T10:48:38+09:00","summary":"Elastic stack (Elasticsearch) Advent Calendar 2018の1日目の記事になります。 ちょっと遅れちゃいました。。。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみよ","tags":["elasticsearch"],"title":"2018年のElastic StackとElastic"},{"contents":"（転職する少し前までパスポートすら持ってなかったのに）今の会社に転職してから、半年に1度の割合で海外への出張が発生する生活を送っています。 4年目になりますが、今回いくつか新しいガジェット？アイテム？を出張用に導入したので感想を書いておこうかなと。\nとりあえず、以下の4つです。\nFelimoa ネック ピロー これまでは、無印で購入した「フィットするネックピロー」を使ってました。 特に使ってる間は問題ないのですが、どうしてもかさばります。。。 そんな時、FBで見かけたのがこちら。\n厚みがないので、持ち運びが便利でした（商品紹介の中にありますが、リュックにつけると邪魔にならない）。 飛行機の中で使うので、それほど暑くない場所なので、ムレる感じでもなく。 ただ、ヘッドフォン＋真横にフレームがくる形になるとヘッドフォンに干渉するので、 私はフレームを顎の下の方に寄せた形で使ってました。 軽さと場所を取らないのがよかったです。\nノイズキャンセリングヘッドフォン これまでは、SONYのNW-A847という ノイズキャンセリング機能付きのウォークマン＋アクセサリーで外部入力を取り込む形で、飛行機で映画を見ていました。 これ自体が8年前の製品ですね。。。 これとは別に、冬の寒い時期は防寒も兼ねてヘッドフォンを使用しています。 MDR-10Rを使ってたんですが、昨年こんな感じになりまして。。。\n応急処置 pic.twitter.com/uDErZWpPVC\n\u0026mdash; Jun Ohtani (@johtani) 2017年11月10日 で、ヘッドフォンの買い替えを検討してたんです。 そこへ飛び込んできたのがSonyの新しいノイズキャンセリングヘッドフォンでしたと。\nせっかく買い換えるし、今度はいいものを長くということでフライト前日に購入してしまいました。 結論としては高いけど買ってよかったと。よかった点はこんな感じです。\n軽い イヤーパッドが耳を抑えることがないので長時間でも気にならない 人の声だけノイズキャンセリングをオフにする（騒音などはキャンセルしてくれる） バッテリーが長時間 ヘッドフォンを外さないでも案内を聞くことができる「クイックアテンションモード」 などなど。行きのフライトで5時間も遅れが出ましたが、空港、飛行機内で非常に快適に過ごせました。 大事に使おう。。。\ncw-x 知り合いがFBにアップしてて、立ちっぱなしの仕事だったり、長時間のフライトでも足が疲れないという噂を聞いて購入しました。\n長時間のフライトの後に、ホテルで1泊しても足の疲れって結構残ってるんです。 今回、12時間のフライトでズボンの下に履いて行きましたが、足の疲れがほぼありませんでした。 デブになりつつあり、足太くなって来てるので、履くのはちょっと苦労しますが。。。もともときつめに作ってるんじゃないかなぁ（希望的観測）。 帰りも使用しましたが、帰りはフライト前に1万歩ほどダブリンの街中を歩き回ってたので、流石に疲れが出てます。。。 今度は、カンファレンスのブースなどで立つことが多いシーンでも使ってみて、疲れがどうなるかを試してみようと思います。\n携帯ウォシュレット 初めて購入しました。海外のホテルで1週間とか連泊するんですが、トイレットペーパーがやはり硬めなのが気になって。。。\n世界に誇る日本の技術の一つだと確信してますw ドイツに長期出張してた友人が便利だよと言ってたので、思い切って購入して持って行きました。 硬めのトイレットペーパーも気にならなくなるのでとても幸せな気分ですw\nまとめ とりあえず、今回はこんな感じです。 総じて導入してよかったなという感じでした。 他にもおすすめ出張グッズとかあればコメントいただけると嬉しいです。\n普段使ってるものとか、どういうものを持っていってるとか興味ある人いるかなぁ？ ではでは。\n","date":1539794095,"dir":"post/2018/","id":"3fd9052870778e14ab4a5acbc8c24af4","lang":"ja","lastmod":1539794095,"permalink":"https://blog.johtani.info/blog/2018/10/18/items-for-long-businesstrip/","publishdate":"2018-10-18T01:34:55+09:00","summary":"（転職する少し前までパスポートすら持ってなかったのに）今の会社に転職してから、半年に1度の割合で海外への出張が発生する生活を送っています。 4","tags":["misc"],"title":"新規導入した長期出張用のアイテムをいくつか紹介"},{"contents":"毎月開催の2回目になります。 今回は日経さんの会場をお借りしての開催となりました。\n前回から、スピーカーの募集をhttp://bit.ly/SpeakerElasticTokyoMeetup で行なっております。 ぜひ皆さんのノウハウを共有していただけると助かります。 また、次回もすでにスケジュール済みです。次回は「ログ/メトリック分析」回になります。\n以下は、個人的なメモになります。\nメディアコンテンツ向け記事検索DBとして使うElasticsearch / Future Architect 株式会社 村田 靖拓さん (twitter: @famipapamart) メディア記事コンテンツ検索 全ての情報が1indexに入っているようにすること。 typeは少し悩んだ。 範囲検索にはならない場合がある。（文字列で登録してWildcard検索できるようにした） kuromojiで基本対応 異体字についてはchar filterでマッピング 細かな設定とかもスライドにて公開予定。 基本的なプラグインだけで対応した Dynamic Field mappingを有効にしたまま対応 パフォーマンス検証 初回のインデックスのロードはこの辺かなぁ？。 自力でQueryのoffset-limitを構築するのかぁ。 ソート条件が固定らしいのでできる方法 minne での検索運用(仮) / @_shiro16 さん ハンドメイドなものをマーケットプレイスがminne SolrからElasticsearchに切り替えた話 2016/02以降はEs 昔は、DBからSolrへ同期 Es版ではDBからの同期ではなく、Workerに対してリクエストを入れる 現状は独自にEC2で運用中 ユーザーが求めているものがきちんとでているかを計測している 行動ログはどんな感じ？ TDにログを入れて、CTRとかを計算してre:dashで可視化 A/Bテストも実施 指標はキャンペーンなどが実施されている場合にブレる場合もある トレンドをログから知ることができる Function Scoreでスコアを変更してる 季節的な単語でスコアを変更したりする ドリンクの対応などをして聴けてないところが。。。 query_stringのはなし / 加藤遼さん　(日本経済新聞社) 電池が切れそう＋ピザとかの手配をしていたらメモが取れず。\n苦労が滲み出る感じのセッションでした。 query_string queryが実際にどんなクエリになっているかの説明を交えて説明してもらえたのはすごくよかったんじゃないかと。 まとめ 検索は話してくれる人が多いし話題に事欠かないなぁという印象でした。 今回も、スピーカーの皆さん、会場提供をしていただいた日経さんありがとうございました。\n他のユースケースのスピーカーも募集してます。ぜひMeetup.comの概要に記載してあるリンクからスピーカーの応募をお願いします！\n","date":1539765230,"dir":"post/2018/","id":"d3fa23c9066f943f10e8883de9340dea","lang":"ja","lastmod":1539765230,"permalink":"https://blog.johtani.info/blog/2018/10/17/26th-elasticsearch-tokyo-meetup/","publishdate":"2018-10-17T17:33:50+09:00","summary":"毎月開催の2回目になります。 今回は日経さんの会場をお借りしての開催となりました。 前回から、スピーカーの募集をhttp://bit.ly/Sp","tags":["elasticsearch","勉強会"],"title":"第25回Elasticsearch勉強会を開催しました。"},{"contents":"7/25にJJUGナイトセミナーでElastic Stackの紹介とAPMのJava Agentの紹介をしたので、補足のブログです。 （久々に書くな。。。）\nスライドとサンプルアプリのリポジトリはこちら。\nスライド：https://speakerdeck.com/johtani/intro-elastic-stack-and-elastic-apm-java リポジトリ：https://github.com/johtani/apm-beats-kubernetes-demo/tree/master サンプルアプリ 勉強会の頭でサンプルアプリへのアクセス用QRコードを用意して質問してもらう感じにしました。\nアプリ自体が質問の受付と、そこにある質問に対して聞きたいかどうかのVoteができる仕組みになっています。 セッション最後にこの画面をみながら答えました。 手を挙げていただくよりも、匿名（名前入れるようになってますが、実名である必要はない）で登録できるし、 みんなが聞きたいかどうかもわかるので便利だなぁと。\n元は、Elastic{ON} 2018であった「Docker \u0026amp; Kubernetes Log Collection and Monitoring with Beats and Elasticsearch」のサンプルアプリです。 これをSpring Bootに移植して、ちょっとだけサンプルコードを追加したものになります。\n構成とかの補足 スライド、GitHubのリポジトリのREADMEにある図は、k8s上のサンプルアプリケーションの構成だけでした。 ElasticsearchとKibanaを含めた図はこんな感じです。\nk8s上の各種Beats、APM Serverは一旦Elastic CLoud Elasticsearch Service（AWS Tokyoリージョンにデプロイ）に対してデータを投げます。 で、KibanaはGKE(k8s on GCP)で動かして、実際に勉強会ではkubectl proxyで接続してから表示していました。 この構成にしている理由は次の理由です。\nElastic CloudのElasticsearchクラスターにデータを投げている理由 クラスターの起動が簡単。 データを永続化したい。k8sのアプリは必要がなくなったらデータを削除したいから。 k8sのdeploymentを書く手間を省く 普段使ってるので。。。 KibanaをGKEで動かした理由 Elastic Cloudでは*「現時点(7/29現在)」*で、KibanaでAPM専用のUIを起動できない ローカルである必要はない といったところです。 Elastic Cloudのインスタンスを起動したままにしておけば、デモをしなくても、このタイミングのログ、メトリクスを 再利用して話をすることも可能です。\nまとめ ということで、簡単ですが、構成の補足でした。 勉強会では告知したのですが、今後の勉強会はトピックスごとでやりたいなと。ということで、どんなトピックスに興味があるのか、スピーカーの応募にはどんなツールが話しやすいかなどといったことのアンケートを集めております。ぜひご協力ください！ また、アンケート、このブログに関する質問がある場合は、@johtani、もしくはブログへのコメントでお願い致します。\n今後の勉強会のやり方などについてアンケートを実施中です。https://t.co/XU15CHro0n 皆さん是非ご協力ください。ここにない項目については返信をお願いします。 #elasticsearchjp\n\u0026mdash; Jun Ohtani (@johtani) 2018年7月23日 ","date":1532843130,"dir":"post/2018/","id":"10ae016e19fff6ae9cfaeb8534fa47f9","lang":"ja","lastmod":1532843130,"permalink":"https://blog.johtani.info/blog/2018/07/29/apm-java-at-jjug/","publishdate":"2018-07-29T14:45:30+09:00","summary":"7/25にJJUGナイトセミナーでElastic Stackの紹介とAPMのJava Agentの紹介をしたので、補足のブログです。 （久々に書く","tags":["勉強会"],"title":"JJUGナイトセミナーで話しました"},{"contents":"第2回から少し間が空いてしまいましたが、templateで作成したプラグインのディレクトリ構成とどういう流れでデータがやり取りされるかについてみていきます。 （2018/02月時点で作成したディレクトリ構成にしたがって説明します） ちなみに、JavaScriptの優れた開発者ではないので、誤解している点や、効率の悪い書き方などがあるかもしれません。見つけた場合は、連絡をいただければと思います。\nでは、まずは作成したディレクトリ構成についてみていきましょう。\nディレクトリ構成 simple-sample-kibana-pluginがプラグインのプロジェクトのトップディレクトリになります。このディレクトリに次のような構成でサブディレクトリが存在します(なお、画像はIntelliJに取り込んだ後のディレクトリになっているので、.imlなど、不要なファイル/ディレクトリが存在しています)。\n主要なディレクトリ、ファイルについて簡単に一覧で説明します(順不同)。\nファイル/ディレクトリ名 説明 index.js プラグインの本体。Kibanaはこのファイルのオブジェクトを読み込みプラグインを起動。設定などの読み込みもこちら。 package.json npm/yarnのパッケージに関する情報を定義するファイル README.md README。プラグインの説明などを記載する。インストール方法なども記載すると便利 public ブラウザ側に配布されるプログラムや画像一式 public/less/main.less LESS用のファイル。アプリ固有のスタイルなどを記載 public/app.js ブラウザ側で読み込まれるプラグインのモジュールなど。 public/template/index.html HTMLのテンプレート。ブラウザ上での描画に利用 server/routes Kibanaサーバー側で動作するプラグイン。hapi.jsを利用してREST APIを実装する 重要なファイルについて少しだけ説明します。\npackage.json npmやyarnでビルドなどをするときに使用するパッケージ情報を記載するためのファイルです。 プラグインの名前、バージョン、説明などを記載します。 Kibanaのバージョンについてもこちらで管理します。この情報を また、ライブラリなどの依存関係についてもこちらで記載しています。 以下、抜粋。\n{ \u0026#34;name\u0026#34;: \u0026#34;simple-sample-kibana-plugin\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;0.0.0\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;Sample plugin for explaining how to make kibana app\u0026#34;, \u0026#34;main\u0026#34;: \u0026#34;index.js\u0026#34;, \u0026#34;kibana\u0026#34;: { \u0026#34;version\u0026#34;: \u0026#34;6.2.1\u0026#34;, \u0026#34;templateVersion\u0026#34;: \u0026#34;7.2.4\u0026#34; }, \u0026#34;scripts\u0026#34;: { \u0026#34;lint\u0026#34;: \u0026#34;eslint **/*.js\u0026#34;, ... }, \u0026#34;devDependencies\u0026#34;: { \u0026#34;@elastic/eslint-config-kibana\u0026#34;: \u0026#34;^0.14.0\u0026#34;, \u0026#34;@elastic/eslint-import-resolver-kibana\u0026#34;: \u0026#34;^0.9.0\u0026#34;, \u0026#34;@elastic/plugin-helpers\u0026#34;: \u0026#34;^7.1.3\u0026#34;, ... \u0026#34;expect.js\u0026#34;: \u0026#34;^0.3.1\u0026#34; } } ちなみに私は、versionなどをリリースするたびに変更しています。\nindex.js 最初にKibanaに読み込まれるオブジェクトになります。 Kibanaのアプリの名前や、必要なモジュールなどを記載します。\nまた、kibana.ymlから設定など読み込む処理なども書くことができます。\n2行目のexampleRouteはサーバー側のAPIとして利用するhapi.js用のファイルのパスになります。\nuiExportsはこのアプリの画面に関する設定などの記載になります。 appの部分が実際にアプリの情報で、 mainがあとで説明するこのプラグインのUIのためのJavaScriptファイル(public/app.js)になります。mainですので、最初に読み込まれる処理が記載されているものを指定します。app.jsというファイル名を変更する場合は、こちらのappの部分を変更したファイルに合わせましょう。\nconfig(Joi)の関数が設定ファイルの読み込みなどの処理を記載する場所です。\ninit(server, options)の関数が初期化処理を記載する場所になります。 このサンプルアプリでは、2行目のimportで読み込んだhapi.js用のファイルの関数を呼び出しています。引数で渡しているserverがhapi.jsのserverオブジェクトになります。 routeメソッドを使用して作成しているプラグイン用のREST APIを追加しています。\nimport { resolve } from \u0026#39;path\u0026#39;; import exampleRoute from \u0026#39;./server/routes/example\u0026#39;; export default function (kibana) { return new kibana.Plugin({ require: [\u0026#39;elasticsearch\u0026#39;], name: \u0026#39;simple-sample-kibana-plugin\u0026#39;, uiExports: { app: { title: \u0026#39;Simple Sample Kibana Plugin\u0026#39;, description: \u0026#39;Sample plugin for explaining how to make kibana app\u0026#39;, main: \u0026#39;plugins/simple-sample-kibana-plugin/app\u0026#39; }, ... }, config(Joi) { return Joi.object({ enabled: Joi.boolean().default(true), }).default(); }, init(server, options) { // Add server routes and initialize the plugin here exampleRoute(server); } }); }; public/app.js 画面用のモジュールです。 uiRoutesという機能を使用して、アプリの呼び出しURLを定義します。テンプレートで作成したばかりの場合は、/というURLが追加されるのみです。\n実際に画面を表示する際に動くコントローラーの部分はその下の uiModules.controllerに指定してあるfunctionが画面描画の 処理を書く部分になります。 templateで作成したプラグインでは、\u0026ldquo;title\u0026quot;など表示に必要なデータを$scopeというオブジェクトに詰め込んでいます。 これはAngularJS(1系)でのモデルオブジェクトになります。\nimport moment from \u0026#39;moment\u0026#39;; import { uiModules } from \u0026#39;ui/modules\u0026#39;; import uiRoutes from \u0026#39;ui/routes\u0026#39;; import \u0026#39;ui/autoload/styles\u0026#39;; import \u0026#39;./less/main.less\u0026#39;; import template from \u0026#39;./templates/index.html\u0026#39;; uiRoutes.enable(); uiRoutes .when(\u0026#39;/\u0026#39;, { template, resolve: { ... } }); uiModules .get(\u0026#39;app/simple-sample-kibana-plugin\u0026#39;, []) .controller(\u0026#39;simpleSampleKibanaPluginHelloWorld\u0026#39;, function ($scope, $route, $interval) { $scope.title = \u0026#39;Simple Sample Kibana Plugin\u0026#39;; $scope.description = \u0026#39;Sample plugin for explaining how to make kibana app\u0026#39;; ... $scope.$watch(\u0026#39;$destroy\u0026#39;, unsubscribe); }); server/routes/example.js hapi.jsというNode.jsのためのサーバーフレームワークです。 このフレームワークをKibanaは使っており、Kibanaのサーバーとブラウザとのやり取りに使用するREST APIを記述するために使用しています。 例えば、Elasticsearchとのやり取りを実際に行うAPIなどをこのREST API内部で記述します。\nexport default function (server) { server.route({ path: \u0026#39;/api/simple-sample-kibana-plugin/example\u0026#39;, method: \u0026#39;GET\u0026#39;, handler(req, reply) { reply({ time: (new Date()).toISOString() }); } }); } pathの部分がブラウザ側からアクセスするURLになります。 実際にElasticsearchとやり取りする処理の書き方については、次回の記事で説明します。\nアーキテクチャ（簡易版） ざっくりですが、ファイルやディレクトリについて説明しました。 簡単なデータのやり取りについての流れを説明します。\nKibana自体はNode.jsで実装されサーバーとして動作していますが、ブラウザでアクセスすることで画面を描画しています。 簡単なコンポーネントを並べるとデータのやり取りはこのような形です。\nすごく簡易で大雑把な絵ですが。。。\n実際のプラグインとしては大きく、2つの処理があります。\nブラウザ上の処理 クリックなどのイベント処理 HTMLなどのレンダリング処理 Kibanaサーバー上の処理(Elasticsearchなどとの通信が必要な場合) 外部との通信処理 ブラウザ上では重い処理 絵に記載しましたが、ブラウザ上の処理についてはAngularJSが主なフレームワークで、サーバー上の処理についてはhapi.jsがフレームワークとなっています。\nまとめ ということで、今回はディレクトリ構造とファイルの説明、どういったフレームワークが使われ、データのやり取りがどのように行われているか説明しました。\n次回からは、実際に私が作成したAnalyze UIを元にElasticsearchとのデータのやり取りなどについて紹介していきます。\n","date":1524205801,"dir":"post/2018/","id":"04d818cbaac08b2915db15e0bffdcb5b","lang":"ja","lastmod":1524205801,"permalink":"https://blog.johtani.info/blog/2018/04/20/directory-layout-and-architecture/","publishdate":"2018-04-20T15:30:01+09:00","summary":"第2回から少し間が空いてしまいましたが、templateで作成したプラグインのディレクトリ構成とどういう流れでデータがやり取りされるかについ","tags":["Kibana","plugin"],"title":"Analyze UIとKibanaのプラグインの作成方法（第3回）"},{"contents":"#MANABIYA のブースでセッション時間の合間はお客さん少ないので、ブログを書いてみたり。 ここ数年、スポンサーとして色々なカンファレンスに参加してるんですが、それについてちょっと気なることがあったので。\nスポンサー情報ってどうやって探してます？ 職業柄、カンファレンスにCfP出してセッションしてみたり（落ちること多いけど）、スポンサーとしてブースを出したりしています。\nで、疑問があるんですが、みなさんどうやってカンファレンスの情報をゲットしてます？\n数年やって来て、検索したりして見つけてスポンサーした結果、 これまでスポンサーしていたので、情報が流れてくるという感じになりました。 それ以外だと、@yusuke さんに教えてもらったりと言うのがあったんですが。。。\n自分が知らない、自分のTwitterで流れてこないという情報をどうやったら集められるかな？と言うのが今の課題になってます。 と言うことで、ブログを書いてみました。\nカンファレンスを検索できるサイトとか便利？ で、私の会社は検索エンジンの会社なんで、検索できると便利では？と考えるんです。\nCfPの応募期間で絞り込みできたり、場所で検索できたり、スポンサー情報を取得する方法が載ってたりすると便利なのではないかなと。 便利に思うのが自分だけでは？と言うのがあるんですが。。。\nあると嬉しい人、データを掲載したいなと言う人いますでしょうか？ Google Formなどで入力してもらえるようにして何か作るのもありかなぁと考えているところです。 それとも、スポンサーを募っているカンファレンスのスタッフや企業の人は、こういう情報は特定の人にだけ知ってもらったりしたいでしょうか？\n自分だけではわからないことが多いので、懸念事項や、それダメでしょ？ あると便利！などのフィードバックをいただけると助かります。\nそれ以外に、カンファレンス自体の場所、開催日程、サイトへのURLなどが検索できると便利だったりするかも？というのもあります。\nとりあえず、自分が知ってるものだけ、個人的に検索できるようにしたりするのがいいかなぁ。。。 コメントお待ちしてます！\n","date":1521867012,"dir":"post/2018/","id":"8cc6b19cd410e638f4beaf1642f4f52a","lang":"ja","lastmod":1521867012,"permalink":"https://blog.johtani.info/blog/2018/03/24/how-to-find-conferences/","publishdate":"2018-03-24T13:50:12+09:00","summary":"#MANABIYA のブースでセッション時間の合間はお客さん少ないので、ブログを書いてみたり。 ここ数年、スポンサーとして色々なカンファレンスに参加してるんです","tags":["カンファレンス","スポンサー"],"title":"カンファレンス情報の探し方（CfP、スポンサー応募、開催期間など）？"},{"contents":"Rustで言語処理100本ノックの続きで、05と06です。\n05. n-gram 問題はこちら。\nみんな大好きn-gramです。単語と文字があるので、それぞれ別関数として実装しました。問題はbi-gramとn=2だったのですが、一応、nを引数に取る形にして実装しました。\nまずは、単語です。\n前に実装した時は、自分で頑張って、先頭から数えたりしてたんですが、Rustにはwindows(n)という便利なメソッドがsliceにあり、これを利用したらこんな簡単になりました。 sliceは特定のシーケンス（配列）に対してある特定のサイズのViewを作ってくれます（説明あってる？）。 ということで、文字列から、単語の配列（スペース区切りで単語にしている）を作り出して、windows(n)メソッドを通すと、 nで指定した数字の個数だけの単語の配列を先頭から、1単語ずつずらして作ってくれます。まさに、n-gram! 戻り値は配列の配列です。 1点だけ疑問点があるのは、「空白で区切ったものが単語」という考え方で良いかどうか？という点です。特に問題文にはそれが明示されていなかったので、このような前提を置いてあります。\ninvalid_n(text, n)はnの値や入力された文字列をチェックする関数です。入力チェックですね。nが1よりも小さい場合、入力文字列が空文字の場合は、warningでメッセージを出して、空の配列を返す仕組みになっています。\n次は、文字です。\n単語とほぼ一緒ですが、入力文字列を、1文字ずつの配列にしているところが異なります。 また、windowsメソッドで取り出された、1文字ずつのn個の配列を文字列に修正してから、結果の配列に入れています。 ここでも疑問は空白をどう扱うか？になります。 現時点では、空白も1文字とカウントして扱うことにしてあります。 どっちがいいのかなぁ？\n06. 集合 問題はこちら。\nまずは、文字n-gramで出てきた文字列をSetに入れる関数から。\nn-gramの問題で実装した文字n-gramの関数の戻り値を配列ではなく、BTreeSetに変えたものになります。比較などがしやすいように？と思い、BTreeSetを利用していますが、実装としてはHashSetでも問題ないかと。 この関数の集合（Set）を元に、和集合、積集合、差集合を求める関数を実装しました。\nSetのメソッドとして、それぞれ、union＝和集合、intersection＝積集合、difference＝差集合のメソッドが用意されているので、特に困ることはなかったです。 差集合については、1-2と2-1で結果が異なるはずなので、それぞれをテストケース、main.rsで出力するようにしてあります。\n所感 今回は、Rustがすでに実装してくれているメソッドがあったので楽ができました。 やりたいことに相当するメソッドがあるかどうかを調べるためにリファレンスを探さないといけないのがちょっと苦労しましたが。。。 ということで、今日はこの辺りまで。\n","date":1521549285,"dir":"post/2018/","id":"d791eaca9375ca1b36a987af22ee71dd","lang":"ja","lastmod":1521549285,"permalink":"https://blog.johtani.info/blog/2018/03/20/nlp100-ch01-05to06/","publishdate":"2018-03-20T21:34:45+09:00","summary":"Rustで言語処理100本ノックの続きで、05と06です。 05. n-gram 問題はこちら。 みんな大好きn-gramです。単語と文字があるので、それぞれ別関","tags":["Rust","nlp100"],"title":"第1章の05から06までやってみた（言語処理100本ノック）"},{"contents":"Rustで言語処理100本ノックの続きで、03と04です。\n03. 円周率 問題はこちら。\n入力文字列を.split_whitespace()で分割しておいて、単語ごとのベクタを作り出し、そこに対して文字を数えました。「アルファベットの」という注意書きがあるので\u0026quot;,\u0026ldquo;や\u0026rdquo;.\u0026ldquo;は含めずに数えるのかなということで、 charの.is_alphabetic()でA-zまでの判定をしつつ、文字のベクタを作ってから、そのベクタの長さを詰め込むという感じでやりました。\nこれ、ひょっとして、collectでベクタにしなくても、i32とかの変数でカウントするとベクタ作らなくてもいいなじゃにか？というのに書きながら気づいた。。。 必要じゃないオブジェクトを作ってるよなぁ。\n.filter().mapとかかな？この辺りの操作がイマイチ苦手。Javaでもまだ馴染めてないところなんだよなぁ。頭固すぎ。\n04. 元素記号 問題はこちら。\n大作ですね。何だろう、大作。。。 最終的に連想配列（辞書型もしくはマップ型）」ということだったので、BTreeMapに詰め込んでます。 HashMapでもいいんですが、文字列で出力した時にキーが並んで見やすいからという理由で、BTreeMap使いました。それ以上の理由はないです。普通にやるなら、HashMapかな？\n入力として、1文字だけの出力をする場所（インデックス番号）の配列を受け取ってます。1点だけ、チェックしていない、けど入力値の想定をしていて、idx_one_symbolsがソートされていて、小さいものから順番に出てくるものとしてます。関数作って、チェックすべきかな？\nで、指定された場所の最後のものが入力文字列よりも大きいかどうかというチェックもしています。（あー、テストケース書いてないな）この辺りのせいでちょっと長めになってます。\n単語の配列を作るのは03の時と同じやり方です。 回しかたがちょっと違って、.iter().enumerate()で回して、添字と値をタプル？でとりだしてます。添字を見ながら1文字取り出すのか、2文字取り出すのかの判断が必要だからです。あとは一緒ですね。1文字取り出すときは、.first()を使って見ました。 実は、2文字取り出す時と、1文字の時と同じロジック使った方が共通化できて、短くなった？？？\nということで、こんな感じでした。いつものようにツッコミお待ちしてます。\n所感 問題それぞれについてではなく、 やってて思ったのですが、問題に対して想定される結果が記載されていると嬉しいなと思いました。 ロジックについては、各自実装者に寄ったり、言語によって違いが出たりするし、議論するベースになっていいかなと思うんですが、 問題で想定されている結果（出力）があると、自分の実装にケアが足りないところがないのか？とか、ケアしなくていい点とかがわかるのかもなぁと。 ユニットテスト相当のものがあると楽かなぁと。\nこのケースどうするんだろ？みたいなのが、ところどころコメントに残ったりしてます。 出題の意図としては、その部分も議論の対象ということなのかな？\n","date":1519032848,"dir":"post/2018/","id":"e6684944c37dbdd4c08d978af9e47bed","lang":"ja","lastmod":1519032848,"permalink":"https://blog.johtani.info/blog/2018/02/19/nlp100-ch01-03to04/","publishdate":"2018-02-19T18:34:08+09:00","summary":"Rustで言語処理100本ノックの続きで、03と04です。 03. 円周率 問題はこちら。 入力文字列を.split_whitespace()で分割して","tags":["Rust","nlp100"],"title":"第1章の03から04までやってみた（言語処理100本ノック）"},{"contents":"「鉄は熱いうちに打て」ということで、言語処理100本ノックの第1章の00から02を実装してみました。\nさて、これが効率がいいのかどうかはさておき。\n00. 文字列の逆順 問題はこちら。\n最初、Vecのreverse()で逆順にして0からlen()まで回してたんですが、pop()がいい感じに後ろから取れることがわかったんで、切り替えました。 シンプルかな？\n01. 「パタトクカシーー」 問題はこちら。\n1文字ずつ取り出して、インデックスの番号が2で割ってあまりが0なら文字列に追加していくってのでやってみました。 （ブログ書いてるところで、i in 0..char_array.len()じゃなくて、(i, x) in char_array.iter().enumerate()に切り替えました。） matchとか使って綺麗に書けたりするのかなぁ？\n02. 「パトカー」＋「タクシー」＝「パタトクカシーー」 問題はこちら。\nだいぶ思考錯誤してる感じがソースに現れてます。 とりあえず、両方の文字列をcharsの配列にして個々のイテレータを回しながら、next()の戻り値があれば追加していく感じにして、 終了条件が両方Noneを通ったらにしてるけど、、、 なんか、もっと綺麗にできないのかなぁ。。。 next()のタプル返す関数作って、とかでなんかできたりするかなぁ？\ngist-it 関係ないですが、GitHubのコードを貼り付けるのに便利なサービスがあるみたいです。\nhttp://gist-it.appspot.com\nこれほんと便利だな。行数指定もできるし。 説明するのが簡単だ。\nとりあえず、今日はこの辺まで。なんか、いい知恵あれば教えてください！\n","date":1518699541,"dir":"post/2018/","id":"bbe1deec11d459bdb348051b970abdaf","lang":"ja","lastmod":1518699541,"permalink":"https://blog.johtani.info/blog/2018/02/15/nlp100-ch01-00to02/","publishdate":"2018-02-15T21:59:01+09:00","summary":"「鉄は熱いうちに打て」ということで、言語処理100本ノックの第1章の00から02を実装してみました。 さて、これが効率がいいのかどうかはさてお","tags":["Rust","nlp100"],"title":"第1章の00から02までやってみた（言語処理100本ノック）"},{"contents":"ども。新しいもの始めないと頭が退化する。。。ということで、こちら（ happy new year and new language - katsyoshiのめもみたいなもの）のブログに触発されて、言語処理100本ノックをはじめてみました。\n言語処理100本ノックとは、自然言語処理になるのかな、東北大学の研究室の先生が公開している言語処理に関する実践的な課題をベースにプログラミングなどのスキルを学んでいくための問題集です。 元々はPythonを対象とされているようですが、Rustでやってみようかと。 まぁ、先ほどあげたブログの二番煎じです。。。 ちなみに、インスパイアされた元のブログの方はRust book 2nd editionを読み終えたらしいですが、私はかじった程度です（ダメかも？）。\nNLPもRustもかじった程度なので、苦戦しそうですが、ちょっとずつやっていこうかなと。 ということで、準備運動の第1章から始めようかと。 GitHubにちょっとずつあげていく予定です。 https://github.com/johtani/nlp100-rust\nまぁ、まずは宣言のブログを書いてみただけです。 続いてなかったら、叱咤激励してください。叱咤だけかも？\n","date":1518605551,"dir":"post/2018/","id":"a673b3829e62477e01abc75465416b86","lang":"ja","lastmod":1518605551,"permalink":"https://blog.johtani.info/blog/2018/02/14/start-nlp100-with-rust/","publishdate":"2018-02-14T19:52:31+09:00","summary":"ども。新しいもの始めないと頭が退化する。。。ということで、こちら（ happy new year and new language - katsyoshiのめもみたいなもの）のブログに触発されて、","tags":["Rust","nlp100"],"title":"言語処理100本ノックはじめました(Rust)"},{"contents":"第1回では、Analyze UIというプラグインの紹介をしました、ごく簡単にですが。\n第2回では、Kibanaのプラグインの作成方法を順を追って見ていこうと思います。今回は、プラグインのプロジェクトの作り方を説明します。 どんなファイルがあるのかなどについては第3回で説明します（2018/02月現在の方法になります。残念ながら、Kibanaのプラグイン作成自体はまだExperimentalな話になっていますので、変更がある可能性があります）。\n実はそれほど難しいというわけではありません。Kibanaのプラグインを作成するためのテンプレートが用意されています。template-kiban-pluginです。 テンプレートのリポジトリのREADMEに作業手順の記載があります。\nKibanaのリポジトリをClone、Checkout Node.jsの環境を用意する Kibanaを起動できるようにする SAOのインストール テンプレートによるプロジェクトファイルの生成 順を追って説明します。 PLUGIN_DEV_DIRというディレクトリ配下で作業をしている想定になります。\n1. KibanaのリポジトリをClone、Checkout 開発環境として、Kibanaが必要です。Kibanaのプラグインを作るので。 手順などはKibanaのCONTRIBUTING.mdに記載があります。 ということで、まずはKibanaのリポジトリをCloneします。\ncd PLUGIN_DEV_DIR git clone git@github.com:elastic/kibana.git このままだと、masterブランチなので、開発したい対象のKibanaのバージョンのブランチもしくはタグをcloneします。今回は6.2.1向けということで、次のようになります。\ngit checkout v6.2.1 これで、ソースが6.2.1向けになりました。\n2. Node.jsの環境を用意する Node.jsをインストールします。 Kibanaのリポジトリに.node-versionというファイルがあります。 こちらにNode.jsのバージョンが記載されています。 Kibanaが使用しているNode.jsを利用できるようにします。ローカルではnvm利用してインストールしました。後から、切り替えが可能だからです。 nvm自体のインストールについてはnvmのサイトをご覧ください。 nvmがインストールできたら、次のコマンドで、Kibanaが使用しているバージョンをインストールします。\ncd kibana nvm install \u0026#34;$(cat .node-version)\u0026#34; すでにnvmを利用している場合などは、Kibana起動時にKibanaのバージョンに合わせたNode.jsに切り替えるようにしてください。\n3. Kibanaを起動できるようにする Kibanaではyarnというjavascript向けのパッケージマネージャーを利用して起動やビルドなどを行います。まずはyarnをインストールします。最近npmからyarnに切り替えたようです。 私はMacだったので、brewでインストールしました。 インストールできたら、次のコマンドを実行します。\nyarn これにより、package.jsonから必要なライブラリなどをダウンロードして来てくれます。 問題なければ「✨ Done in 439.30s.」というような表示がされます（結構時間かかりますね）。 では、Kibanaを起動できるか確認してみましょう。 さらに、Elasticsearchも起動してみます。 Kibanaのpackage.jsonの中にはElasticsearchを起動するためのスクリプトも用意されています。実際にはgruntを利用してタスクを実行しているようです。Elasticsearchの起動にはJavaが必要になります。 今回は6.2.1なので、JDK 8以降がインストールされている必要があります。 こちらはインストールされているものとします。\nyarn elasticsearch で起動できます。\n\u0026gt;\u0026gt; Started 1 Elasticsearch nodes. という表示が出てればOKです。 次にKibanaです。別のTerminalを起動して、以下のコマンドで起動できます。\nyarn start これだけです。\nserver log [06:58:56.930] [info][listening] Server running at http://localhost:5603 この辺りが出てればKibanaのServerは起動済みです。また、Elasticsearchに接続できていれば、次のログが出ているはずです。\nserver log [07:02:18.010] [info][status][plugin:elasticsearch@6.2.1] Status changed from red to green - Ready Elasticsearch接続用のKibanaのプラグインの状態になります。 これで、Kibanaの環境が整ったことが確認できました。 もちろん、Elasticsearchに関しては、yarnで起動せずに、tar.gzなどでダウンロードして来たElasticsearchを起動しておき、アクセスするといったことも可能です。プラグインなどをElasticsearchにもいれてテストしたい場合などはそちらの方が便利かもしれません。\n4. SAOのインストール では、一度、ElasticsearchとKibanaを停止しましょう。フォワグラウンドで起動しているので、それぞれのTerminalでCtrl+Cで停止できます。 Kibanaのプラグイン作成むけに、テンプレートが作られています。sao.jsというGitHubのリポジトリやnpmのパッケージをテンプレートとして使うことができるツールを利用してプラグインのプロジェクト（リポジトリ）を作成します。 実際にテンプレートとなるリポジトリはtemplate-kibana-pluginになります。 まずはSaoのインストールです。\nnpm install -g sao プラグインのテンプレートのページには上記のようにnpmを利用したインストール方法になっていますが、次のようにyarnでも可能です。\nyarn global add sao これで、saoがインストールできました。\n5. テンプレートによるプロジェクトファイルの生成 あとは、テンプレートを元にプロジェクトを作成します。 PLUGIN_DEV_DIRディレクトリ配下に、kibanaと同じ階層で作成するプラグイン用のディレクトリを作成します。\nmkdir simple-sample-kibana-plugin 以下のような構成になります。\nkibana simple-sample-kibana-plugin 次にテンプレートを適用していきます。\ncd simple-sample-kibana-plugin sao kibana-plugin@7.2.4 2行目がsaoを利用してプロジェクトを作成しているコマンドになります。 すると、次のような質問が出て来ます。 これらに答えるとプロジェクトに必要なファイル（package.jsonやREADME.mdなど）に入力した情報を適用したものを作ってくれます。\n? Name of your plugin? ? Provide a short description ? What Kibana version are you targeting? ? Should an app component be generated? ? Should translation files be generated? ? Should an hack component be generated? ? Should a server API be generated? 実際に答えた内容はこちら。\n? Name of your plugin? simple-sample-kibana-plugin ? Provide a short description Sample plugin for explaining how to make kibana app ? What Kibana version are you targeting? 6.2.1 ? Should an app component be generated? Yes ? Should translation files be generated? Yes ? Should an hack component be generated? Yes ? Should a server API be generated? Yes プラグインの名前などは、ディレクトリ名と同じものを入力補完してくれているので、そのままEnterでもOKです。 Descriptionについてはわかりやすいものを入力しましょう。 バージョンは、先ほどのKibanaのリポジトリに合わせて、6.2.1にしてあります。 あとは、作るプラグインの種類に応じて、必要なコンポーネントを作るかどうかの質問にYes/Noで答えます。 今回はサンプルの説明ということもあるので、全てYesで答えました。 ちなみに、私が実際に作成したanalyze-api-ui-pluginでは、appとtranslationとserverの3つを作成しました。 ただし、translationについては現在はテンプレートで作成したままのファイルが入っており、実際には利用してないです。\n完了したら、プラグインのサンプル入りのプロジェクトが完成です。 もう一度、Elasticsearchを立ち上げて、プラグインのプロジェクトからKibanaを起動してアクセスしてみます。まずは、PLUGIN_DEV_DIR/kibanaディレクトリの下で、Elasticsearchを起動します。\nyarn elasticsearch 次に、PLUGIN_DEV_DIR/simple-sample-kibana-pluginディレクトリの下で、以下のコマンドを実行し、プラグインが入った状態のKibanaを起動します。\nyarn start 問題なく起動すれば、ブラウザでアクセスすると次のような画面が表示されるはずです。\n左側にメニューが1つ増えています。 クリックすると、上記画像のような画面が表示されるはずです。\nこれで、カスタムプラグインの開発ができる環境ができました！ 次回は、プロジェクトのディレクトリ構成や、どんなツールが内部で使用されてデータのやり取りが行われているかについて説明します。お楽しみに。\n","date":1518167857,"dir":"post/2018/","id":"7b6cb59a177abe9767fd22da5a03b1e6","lang":"ja","lastmod":1518167857,"permalink":"https://blog.johtani.info/blog/2018/02/09/getting-started-template-kibana-plugin/","publishdate":"2018-02-09T18:17:37+09:00","summary":"第1回では、Analyze UIというプラグインの紹介をしました、ごく簡単にですが。 第2回では、Kibanaのプラグインの作成方法を順を追って","tags":["Kibana","plugin"],"title":"Analyze UIとKibanaのプラグインの作成方法（第2回）"},{"contents":"あけましておめでとうございます。今年はサボりがちだったブログをちょっとずつ復活させようかと。 ということで、第1弾として、昨年少し作っていたKibanaのプラグインを何度かに分けて紹介したいと思います。\n今回はAnalyze UIというプラグインの紹介です。\n今回はインストール方法と簡単な機能紹介です。 細かな紹介は個別にやりたいと思います。\nAnalyze UI pluginとは？ Elasticsearchの_analyzeというAPI\u0002(個人的に好きなAPIです)をご存知でしょうか？\nElasticsearchは全文検索エンジンで、データの検索には転置インデックスというものを使用します。 Elasticsearchにデータを登録する際に、text型のデータの場合、この転置インデックスのキーとなる単語を決める処理のことをAnalysisと呼びます（Analysisの詳細については割愛します。後日説明するかも？）。 このAnalysisの処理が、入力されたデータの文字列に対してどのように行われて、結果としてどんな単語がキーとして用いられているかを確認できる機能が_analyze APIです。検索で単語がうまくヒットしないな？とか、なんで、こんなので検索結果に出てくるんだ？といった場合、このAPIを利用すると、どのような単語で転置インデックスが作られているかがわかるので、検索にヒットしない/する理由を見つけることができます。\nElasticsearchの便利な点はRESTfulなAPI＋JSONでやりとりができる点なのですが、_analyze APIの結果をJSONで受け取っても、見るのにちょっと苦労します。。。こんな感じ。\nリクエスト：\nPOST _analyze { \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;今年はブログをいっぱい書きますよ！\u0026#34; } レスポンス：\n{ \u0026#34;tokens\u0026#34;: [ { \u0026#34;token\u0026#34;: \u0026#34;今年\u0026#34;, \u0026#34;start_offset\u0026#34;: 0, \u0026#34;end_offset\u0026#34;: 2, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 0 }, { \u0026#34;token\u0026#34;: \u0026#34;ブログ\u0026#34;, \u0026#34;start_offset\u0026#34;: 3, \u0026#34;end_offset\u0026#34;: 6, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 2 }, { \u0026#34;token\u0026#34;: \u0026#34;いっぱい\u0026#34;, \u0026#34;start_offset\u0026#34;: 7, \u0026#34;end_offset\u0026#34;: 11, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 4 }, { \u0026#34;token\u0026#34;: \u0026#34;書く\u0026#34;, \u0026#34;start_offset\u0026#34;: 11, \u0026#34;end_offset\u0026#34;: 13, \u0026#34;type\u0026#34;: \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34;: 5 } ] } このくらいの量であればまだなんとかなりますが、文章が長くなると辛いですよね。\nということで、GUIがあると便利だろうなぁと。で、作ってみましたというのが今日紹介するKibana用のAnalyze UIプラグインです。 こんな感じで、Kibanaのアプリの一部として動作しブラウザ上で、入力テキストの文字列がどのようにanalyzeされて、単語になるかがわかります。\n（先ほどのAPIのサンプルと同じものを画面で入力した結果になります）。\nインストール方法 現時点の最新版Kibana（6.1.2）に対応しています。 Kibanaのディレクトリでkibana-pluginコマンドを利用してインストールします。\n./bin/kibana-plugin install https://github.com/johtani/analyze-api-ui-plugin/releases/download/6.1.2/analyze-api-ui-plugin-6.1.2.zip これだけです。 で、Kibanaを起動していただくと、左のメニューに「Analyze UI」という項目が増えています。\nクリックすると、Analyze UIが表示されます。\n初期画面は入力された文字を特定のAnalyzerで処理した場合の結果を見るための画面です。綱目の説明は画像をご覧ください。\n先ほどのJSONよりは見やすくなったかと思います。 そのほかにもいくつか画面や機能があるのですが、今日はこの辺りで。 「_analyze API便利なんだけど、JSONは。。。」とか「検索うまくできないなぁなんでだろう？」と思っている方は、ぜひ試して見ていただければと。 問題点などありましたら、GitHubのIssueを登録してください。\n","date":1516343806,"dir":"post/2018/","id":"4afcb20d4d95bcd1bde3aa6b7f552660","lang":"ja","lastmod":1516343806,"permalink":"https://blog.johtani.info/blog/2018/01/19/how-to-make-kibana-plugin-example-analysis-ui/","publishdate":"2018-01-19T15:36:46+09:00","summary":"あけましておめでとうございます。今年はサボりがちだったブログをちょっとずつ復活させようかと。 ということで、第1弾として、昨年少し作っていたK","tags":["Kibana","plugin"],"title":"Analyze UIとKibanaのプラグインの作成方法（第1回）"},{"contents":"今年は紅白を見ながら書いてます。 今年はいろんなところに出張に行ったなぁ。\n振り返り（2016年に書いた抱負から） まずは去年の抱負を元に。\nもちろん英語の継続 もちろん継続してます。英会話しながら海外TVドラマや映画を見てます。 ちょっとずつ英語字幕でも見ようとしてますが、まだまだだなぁ。 あと、TOEICを受けてないんで、それは受けないと。 見たドラマはこの辺です。\nER ウォーキング・デッド Agent of Shield SUITS Mr.Robot(いまいち話の展開についていけなかった) 継続的にイベントに登壇 OSCに今年もブース出してセッション持ってました。 勉強会ももちろんやりました。 あと、外部のカンファレンス（FOSS4G、BigData Analytics、db tech showcaseなど）や 勉強会(monitoring勉強会やCA.ioなど)にも登壇させていただきました。 もっと外部から読んでいただいたり、CfPに応募して通過できるようにしないとなぁ。\nもっと開発＆ブログ ブログはすみません。。。来年頑張ります。。。 ブログの代わりに書籍を出せました。データ分析基盤系の書籍になるので、興味のある方はのぞいて見ていただければ。\n開発はちょっとやってます。今年後半はKibanaのプラグインとかをちょっと書いてました。 Ingest-CSVもちょこちょこバージョンアップに追従してたりします。\nサポートエンジニア獲得！ 獲得しました！（自分の成果かどうかはわかりませんが。。。） 今は3名体制でサポートしてもらってます。おかげさまでだいぶサポートする機会が減ってきました。 開発は世界各地どこでも募集中だったりしますので、ぜひ連絡いただければと。\n個人的な検索勉強会の再開 再開しました。検索エンジン自作入門を知人と隔週くらいで読んでます。読んでるだけではあれなんで、実装もしてたり。全然違う言語でトライして見ようと思ったのでRustで書き始めてます。まずは、単純なところからと思ったんですが、 Rustの書き方の違いにだいぶ戸惑ってます。。。\n振り返り(今年あったできごと) ここからは今年の出来事を。\n初アメリカで釣り Nintendo Switch! 初Japanチームオフサイト チーム変更 初Berlin Buzzword! 母校（大学）訪問 Kibanaプラグイン開発 今年も初モノがちらほらとありますね。 今年もカレンダー振り返ってたら「え？これ今年だったの？」ってのがちらほらありました。。。\nアメリカで釣りやりました。自社のカンファレンスElastic{ON}のあとに、エンジニアが集まるミーティングがあるんですが、そこで1日Fun Dayがあって、そこで釣りをやりました。 魚群探知機とかで魚探すんですね、最近のは。2、3匹釣ったので非常に楽しかったです。 来年はスノーシューにチャレンジする予定。\nNintendo Switch買って、ゼルダやりました。今はイカやってます。 イカ欲はちょっと減ってるかもなぁ、1に比べると。 あとは、子供に買ったマリオやったりしてるかな。\nここ10年くらい行きたいと思っていたカンファレンス、Berlin Buzzwordに行ってきました！ これが今年一番嬉しかった出来事です。Luceneコミッターの方々にも会えたし。特にPoliceman JenkinsのUweさんに会えたのが本当に感激でした。。。 来年も行けるといいなぁ。。。\n今年も出張が多めだったのであちこち飛び回ってたなぁ。 そんな飛び回っている中で、故郷である広島（出身地？）に出張で行ったので、母校に顔を出してきました。 変わってなかった。。。自分が一期生なので、自分が入学した時はまだクレーンとか立ってるような新校舎だったんだけど、それが20年くらい経て、だいぶ古くなってました。。。 広島市内は港近くに高速道路とか出ててだいぶ様変わりしてました。 ただ、小学校も高校も変わってなかったなぁ。久々に高校の同級生にも会えたし。 また、機会があればぜひ行きたいなと。帰省する場所ではなくなったので、行く機会がないんですよね。。。\n開発もちょっとやってます。Kibanaのプラグインに挑戦して見てます。 いまだにJavaScriptは苦手なんですが。。。 ちょっとずつ改良して、ひょっとすると本体とかに取り込めるかな？ あとは、今年始めたRustをちょっとずつ継続して行きたいなと。\n来年の抱負 最後は来年の抱負を。\nもっと英語の継続＆TOEIC 継続的にイベントに登壇 CfPもっと出すぞ！ もっとブログ！ 雑誌やWeb系雑誌で記事を。 コミュニティを別の方法で盛り上げ Elasticsearchなど検索系の開発にも参加 英語はもちろんですね。今年は12月の自社イベントに合わせて多くのAPJチームの人が来て、 チームで会話できたし、もっと英語やらないとなぁと。前よりもちょっとは喋れるようになった気がしてます（気がしてるだけで、喋れてるかどうかは不明）。あとは、TOEIC受けて、実力チェックしてみないとなぁ。\nイベント登壇はまぁ、DevRelですから、一応。 来年もとりあえず、3月までは毎月どこかでブース出してます。 Ask Me Anything的なブースの出し方を今年はしてみようかなと思ってるので、 ちょっと使い始めたけど、この辺よくわからないと思ってる方、ぜひ質問しに来てください。 ブース出すだけじゃなくて、スピーカーとしていろんな場所で喋れるようにしないとなぁと。 もっと幅広く知ってもらえるように雑誌とかで連載できるようにしたいなぁと思ってます。 また、日本語の入り口の情報を増やすためにブログも書かないとなぁ。\n勉強会も継続しますが、別の方法でも盛り上げて行きたいなぁと。 勉強会はどうしても聞く人が多くて、ユーザーの間での交流や情報交換とまでは行ってない気がするし、discuss.elastic.coというフォーラムで質問は増えて来てるけど、もう少し交流しやすい場があると使ってもらえるかなぁ？と思っていたり。 何かおすすめとかあれば、連絡ください。 meetup.comの勉強会のページにも掲示板はついてるんだけど交流しにくそうだし。\n来年は自分が最も興味のある検索系の開発にも参加したいなぁと。 Elasticsearchをちょっとずつ時間見つけてやってたりはしますが、もう少し首を突っ込んで行きたいなぁと。Swiftypeもジョインしたし。もっと検索やって行きたい気持ちが強いので。\nさて、ということで、今年もあと1時間なくなりました。 今年も様々な面で色々な方々に助けていただけました。本当にお世話になりました。 この場を借りてお礼申し上げます。\n来年ももちろん、色々な方に助けてもらうと思いますが、よろしくお願いいたします！\n","date":1514723443,"dir":"post/2017/","id":"7c21b70f9e9c782c1f5153268e0cc1c1","lang":"ja","lastmod":1514723443,"permalink":"https://blog.johtani.info/blog/2017/12/31/looking-back-2017/","publishdate":"2017-12-31T21:30:43+09:00","summary":"今年は紅白を見ながら書いてます。 今年はいろんなところに出張に行ったなぁ。 振り返り（2016年に書いた抱負から） まずは去年の抱負を元に。 もちろ","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2017）"},{"contents":"Merry Christmas! Elastic Stack Advent Calendar 2017の24日目の記事になります。\nちょっとですが、2018年のElasticについて書いてみようかと思います。\nイベント いくつか出展が決まっているイベントがあるのでまずは宣伝を。\nOSC Osaka 2018 まずは、1月25日、26日にOSC Osaka 2018に出展し、話をします。参加者がいそうであれば、25日や26日の夜に勉強会もありかなぁと思っています。 セッションでは入門的な話をする予定です。ブースにいますので、色々質問がある関西の方はぜひご参加ください。\nDeveloper Summit 2018 2月15日、16日はDeveloper Summit 2018に出展します。 こちらでもブースにいますので、AMA（Ask Me Anything）的に使っていただくのもいいかなと。 デブサミに参加される方はぜひお立ち寄りください。\nManabiya 3月23日、24日はManabiyaに出展します。 こちらでもAMAのつもりでブースを出す予定です。質問がある方はぜひお立ち寄りください。 こちらのイベントは初めての開催になるようなので、どんなイベントになるか楽しみにしています。\nイベント回りはこの辺りで。 また、1月末に勉強会を予定しています。決まり次第またMeetup.comの方々にメールを出す予定です。\nElastic Stackの2018年は？ Canvas! 昨年のElastic{ON}でみなさんをCanvasがリリースされるかなぁと。 現在、みなさんにテストしてもらえるようにcanvas.elastic.coというサイトを公開中で、実際にインストールして試すことができるようになっています。 ぜひ、触って、全く新しいUIを体験して見てください。\nSQL? こちらも昨年のElastic{ON}でみなさんから反響があったものです。 もう直ぐでてくるのではないかなぁと。\nその他は？ いくつか面白そうで、取り込み済みのものをピックアップしておきます。\nAdd ranking evaluation API 検索クエリなどに対して検索結果のランクのクオリティを評価するためのAPIの追加（7.0予定） JDK9サポート？ 6.2でサポートされそうです。が、LTSのJDK8が推奨のままの予定です。 High-level REST ClientでいくつかAPIが追加 https://github.com/elastic/elasticsearch/pull/27574、https://github.com/elastic/elasticsearch/pull/27351 APM正式リリース？ ベータ版がリリースされているので、秒読み段階？ ということで より詳しく知りたい方は、サンフランシスコで開催されるElastic{ON} 2018に参加するのが一番です！（ステマ） 私も参加予定ですので、ぜひ、現地でお会いし、色々な情報をゲットしましょう。\n明日で、今年のAdvent Calendarも最後です。micci184さんの記事を楽しみにしましょう！\n","date":1514124616,"dir":"post/2017/","id":"f3a9b931b7f552a4f9dfa61ce4f39f0e","lang":"ja","lastmod":1514124616,"permalink":"https://blog.johtani.info/blog/2017/12/24/elastic-2018/","publishdate":"2017-12-24T23:10:16+09:00","summary":"Merry Christmas! Elastic Stack Advent Calendar 2017の24日目の記事になります。 ちょっとですが、2018年のElasticについて書いてみようかと思います。 イベント いくつか","tags":["elasticsearch"],"title":"2018年のElasticは？"},{"contents":"Elastic stack (Elasticsearch) Advent Calendar 2017の1日目の記事になります。\nまだ、1ヶ月を残していますが、簡単に今年起こったことを振り返ってみようかと思います。思った以上に色々ありましたね。。。\nElastic Stack 5.2.0リリース (1月) リリース記事はこちら\nHeatmapがKibanaで追加されたり、Heartbeatがベータですが追加されました。 個人的には、Terms aggregationのFiltering Valuesによるパーティションが便利になったと思います。Terms Aggsでページングに似たことができるようになりました。\nElastic{ON}17開催 (3月) 第3回目のユーザカンファレンスが開催されました。 バレーダンサーの踊りから始まったキーノート、様々なユーザ企業によるユースケース発表などいろいろありました。 セッションはこちらのサイトからから録画を見ることができます。 SQL for ElasticsearchやAwardが目を引いたと思います。SQL対応まだ出てきていないですが、もうすぐじゃないかと！\nElastic Stack 5.3.0リリース (3月) リリース記事はこちら\nFilebeat moduleが導入され、ログファイルを取り込んでKibanaで可視化するまでの手順がより簡単になりました。Elasticの目指しているものの一つに、シンプルな使い方、簡単にはじめられることといったものがあります。KibanaのTimepickerもより便利になったのも、このバージョンからです。\nShayがCEOに (5月) 2月にすでに発表されていましたが、Elasticsearchの生みの親のShay BanonがCEOに正式に就任しました。CEOになってさらに、精力的に様々なことをやっていて、本当にすごいなと思います。\nElastic Stack 5.4.0、6.0.0-alpha1リリース (5月) 5.4.0リリース記事はこちら、6.0.0-alpha1リリース記事はこちら\n5.4.0は節目になるリリースでした。Machine Learningがベータリリースとして、X-Packに追加されましたし、ElasticsearchではCross Cluster Searchの改善が進みました。LogstashではPersistent QueueがGAになりましたし、KibanaにはTime Series Visual BuilderやEvent Contextなどが追加されますます使いやすくなりました。\nまた、6.0.0のalpha版も同時にリリースされ、様々な方からのフィードバックが集まり始めました。\nElastic Cloud Enterprise GAリリース (5月) Elastic Cloudのバックエンドの技術を製品に採用したものになります。 多くのElasticsearchクラスタを管理しないといけない方には朗報でした。\nOpbeatがJoin (6月) Opbeatチームがジョインしたのが6月です。Elastic StackがAPM\u0002(Application Performance Monitoring)でも活躍することになりそうです。APMの仕組みとしては、APM Agentをアプリ側に配置し、APM Serverへデータを送信し、Elasticsearchに保存、Kibanaで可視化するという流れになります。\nElastic Stack 5.5.0リリース (7月) リリース記事はこちら\nMachime LearningがGAリリースになったのが5.5.0です。色々な方から質問を受けました。それ以外にも、ElasticsearchのWindows MSI InstallerやKibanaのFilter editorなどが追加されました。Filter editorはこれまで検索条件を記述するのが難しいと感じていたKibanaユーザにとても喜んでもらえたものじゃないかなと。 GrokDebuggerが導入されたのもこのタイミングです。\nElastic Stack 5.6.0リリース (9月) リリース記事はこちら\n5系最後のマイナーリリースであり、6へのアップグレードが楽になる様々な仕組みが用意されたのがこのバージョンです。ElasticsearchのJava High level REST clientが導入されたのもこのバージョンです。本当に様々な機能が次のメジャーバージョンとの互換性のために組み込まれています。。。\nElastic Cloud on GCP (9月) リリース記事はこちら\nこれまで、AWS上のみで展開していたElastic CloudがGCP上でも展開されることになりました。残念ながら、日本リージョンはまだありませんが、問い合わせなどが増えれば今後サポートされる可能性が高くなると思います！\nElastic APM alpha (9月) リリース記事はこちら\nOpbeatチームによりElastic StackのAPMがAlphaですがリリースされました。APMがOpen Sourceで利用できるんです！Agentがもっと増えてくると色々なことに使えるようになると思います。ぜひAgentを作成してみてください！\nElastic Stack 6.0.0リリース (11月) リリース記事はこちら\n待ちに待った6.0.0のリリースです。新機能については本日(12/1)の昼に行われるウェビナーをご覧ください！\nSwiftypeがJoin (11月) ニュースリリースはこちら\nSwiftypeと呼ばれる検索のSaaSを提供している会社がジョインしました。 個人的には今年一番嬉しいニュースです。やはり、検索が好きなので。 簡単にSite Searchを構築できる仕組みは非常に面白いものです。 興味のある方は、ぜひ触ってみてください。日本語固有の機能などはまだないので、今後関わっていければなーと。\nElastic{ON} Tour Tokyo開催 (12月) まだ開催前ですが、今年も東京で1dayイベントを開催します。 残念ながら、もうSold outなので、キャンセル待ちになってしまっているみたいですが。私もスピーカーとして喋りますし、AMAブースにも立っています。 参加される方はぜひ声をかけていただければと思います。\nOSC 2017.Enterprise (12月) オープンソースカンファレンスで今年も様々な都市に出張しました。 今年の締めくくりということで、12/8に渋谷で開催されるカンファレンスに出展します。時間のある方は、ぜひブースに遊びに来てください。入門者向けのセッションもあるので、こちらもお待ちしております。\nまとめ 超駆け足ですが、今年を振り返ってみました。 今年もいろんなことがありました。書くのが大変だったw。 OSCなどイベントで声をかけていただいた皆様、ありがとうございました。\nさて、Elastic Stack Advent Calendar 2017は始まったばかりです。これからの記事を楽しみにしています！\nということで、 次はaeroastroさんの「Elasticsearchのインデックスを本当の意味で無停止再構築する方法」（Advent Calendarのページはこちら）になります、お楽しみに！\n","date":1512054000,"dir":"post/2017/","id":"fa0486610d8a02cea245c13c85b6de27","lang":"ja","lastmod":1512054000,"permalink":"https://blog.johtani.info/blog/2017/12/01/whats-happen-at-elastic-in-2017/","publishdate":"2017-12-01T00:00:00+09:00","summary":"Elastic stack (Elasticsearch) Advent Calendar 2017の1日目の記事になります。 まだ、1ヶ月を残していますが、簡単に今年起こったことを振り返ってみようかと思います。思った以上に","tags":["elasticsearch"],"title":"2017年のElastic StackとElastic"},{"contents":"Swiftypeでサイト内検索？ プレスリリース：Elasticがサイト内検索サービス最大手のSwiftypeを買収が出ましたが、SwiftypeチームがElasticにジョインしました！\n自分のブログ検索に導入してみる？ SwiftypeはSite Searchをサービスとして提供しています。 実際に指定したサイトのデータをクロールして、インデキシングし、検索できるようになります。 ものは試しということで、自分のブログを登録してみました。検索窓はつけてないですが。 14日間のFree trialがあるのでそちらで試してみましょう。 検索窓はデモとか作れたらかな。\nということで、Free trialへ まずはユーザ登録です。Googleのアカウントと連携するか、Swiftypeにメルアドを登録するかが選択できます。 登録できたら、次にどちらのプロダクトを使うかという選択画面が出てきます。 今回はサイト検索して見たいので、「Site Search」の「START FREE TRIAL」をクリックします。\nEngineの指定 Web Crawlerを利用するか、独自にSwiftypeのAPIを利用してデータを登録するかを選択します。\n今回は、お手軽な方のCrawlerを選択します。 すると次に、クロールしたいURLの指定画面が出てきます。\n今回は自分のブログなので、\u0026lsquo;http://blog.johtani.info\u0026rsquo;を指定します。\nで少し待つと、URLのチェック（存在チェックとか、接続チェックとか）が終わり、今回作成するEngineに名前をつける画面が出てきます。 「My Blog search」という名前にしてみました。\nsitemapがあるかどうかをCrawlerがチェックしています。 私のBlogはOctopressでできていて、sitemap.xmlも作ってくれているので、これを元にCrawlerはクロールをしてくれます。そのほかにもRSSやAtomサポートもあるみたいですね。 「COMPLETE SETUP」を押すと、Engineの管理画面が出てきます。\n「CRAWLING」という表示が出ています。クロールしている最中です。これが終われば、「PREVIEW」に代わり、検索できる準備ができたことになります。 実際にPREVIEWして見ると、次のような検索ができるようになります。\nそのほかにはWeightの調整画面などもありますね。フィールド毎に重み付けを変えて見たりもできます。\n日本語独自のAnalyzerなどはまだないので、そのあたりができてくるともっと便利になりそうです。 とりあえず、気になる方は触って見てはいかがでしょうか？ 個人的は検索に関するサービスが出てきたのですごく楽しみにしています！\n","date":1510280089,"dir":"post/2017/","id":"c20d71627e66a044b21780f56f2f9504","lang":"ja","lastmod":1510280089,"permalink":"https://blog.johtani.info/blog/2017/11/10/welcome-swiftype/","publishdate":"2017-11-10T11:14:49+09:00","summary":"Swiftypeでサイト内検索？ プレスリリース：Elasticがサイト内検索サービス最大手のSwiftypeを買収が出ましたが、Swifty","title":"Swiftypeがジョインしたので触ってみました"},{"contents":"久々に執筆しました。といっても、以前の書籍の更新版です。 まぁ、更新版といっても、私以外の方々は結構な量を書き直しor新規書き起こしされてますが。。。\nということで、みなさん「買って」から感想をいただけるとうれしいです！\u0002（以下の画像でAmazonにジャンプできます！Kindle版も発売中です。）\n今回もElasticsearchの章を担当しました。 5.4ベースで書きましたが、ちょっとずつ6でどう変わるかなども記載してあります。 また、付録ではLogstashやBeatsにもちょっと触れています。 また、自分が一番好きなKibanaの機能であるDev ToolsのConsoleについても記載してあります。こちらも合わせて目を通していただければと。\nみなさんのフィードバック（ツイート、ブログ、Amazonのコメントなどなど）をお待ちしております！\n","date":1505955750,"dir":"post/2017/","id":"4f88f3eebe44285ded812939553ef94c","lang":"ja","lastmod":1505955750,"permalink":"https://blog.johtani.info/blog/2017/09/21/release-intro-logging-analysis-system/","publishdate":"2017-09-21T10:02:30+09:00","summary":"久々に執筆しました。といっても、以前の書籍の更新版です。 まぁ、更新版といっても、私以外の方々は結構な量を書き直しor新規書き起こしされてます","tags":["elasticsearch","kibana","本"],"title":"データ分析基盤構築入門 を一部執筆しました。"},{"contents":"久々のブログ。 Elasticsearch勉強会を主催してますが、 プロダクトを超えて、検索で共通してある課題とか、悩みとか、あるかなぁと。 その辺りを話す場所を考えてみるのいいかもと思い、検索座談会ってのを5人でやってみた。\nとりあえず、初めてなので、5名ほどで。プロダクトはかぶってない感じでした。\n話した議題はこの辺り。 形態素解析の辞書は何を使ってる？有償のもの？ そもそも形態素解析？ 辞書の更新とかは？ シノニムってどうしてる？ サジェストとかのデータはどう作ってる？どうしてる？ 検索ログとかから作ってる？ 検索結果のランキングって検索結果だけで決めるの？ 検索漏れとかキーワードのミスマッチとかどうしてる？ 今後話したい内容はこの辺かな？ 緯度経度系の検索 画像検索、音声検索 検索のキーワードの調査とかしてる人とかいるかな？ どんな機能が欲しい？ 前処理としてはどんなことをしてる？ このあとどうしていくかはまだ考え中。知り合いを捕まえて、どんなことしてるかを聞きにいくのもいいし、議題みたいなことを決めて、それを話してくれそうな人にコンタクトして議論するのもありかなぁ。 普通の勉強会みたいなのにするかもしれないし。 とりあえず、どのくらい興味を持ってる人がいるのかがわからないので。。。\nもちろん、Elasticsearch勉強会は別でやっていきますよ。\n","date":1495639453,"dir":"post/2017/","id":"29b4c2b5adcd80ced1612128b3ca95a9","lang":"ja","lastmod":1495639453,"permalink":"https://blog.johtani.info/blog/2017/05/25/search-meetup/","publishdate":"2017-05-25T00:24:13+09:00","summary":"久々のブログ。 Elasticsearch勉強会を主催してますが、 プロダクトを超えて、検索で共通してある課題とか、悩みとか、あるかなぁと。 その","tags":["勉強会"],"title":"検索座談会ってのをやってみた"},{"contents":"今年はRioのプレイバック\u000e見ながら書いてます。 今年はなんか長い一年だった気が。\n振り返り（2015年に書いた抱負から） まずは去年の抱負を元に。\n英語の継続 継続してます。まぁ当たり前ですが。もう少し話す機会増やさないとだなぁと思いつつ。英会話しながら、海外TVドラマ見ながら。 見たドラマはこの辺かな？\nER SUITS メンタリスト Numb3rs エレメンタリー Agent of Shield あと、映画も見てます。とりあえず、耳を慣らすために字幕ありで見てるので、 英語だけでとは行きませんが。。。 そろそろ同じ映画を英語字幕で見るとかしたほうがいいのかもなぁ。\nもっとElasticsearchの開発に参加 一応参加してます。ちょっとずつですが。 イベントが重なるとできなくなるので、小さなPRとかを細々とって感じですが。。。\n人員の倍増？ 倍増したかな？現時点で日本は8名になりました。そのうち1人は完全リモートです。 来年も倍増とは行かないだろうなぁ。取り急ぎ、サポートエンジニアが足りてないのでそこを埋めないと。。。\n日本語情報発信 これはちょっと足踏みしてるかも。ブログの翻訳とかはやってるんですが、もう少しなんとかしないとなぁ。ブログも書かないと。。。\nSplatoon S+? なりました！とりあえずS+とSを行ったり来たりしてる感じです。 メインはノヴァネオですが、Sに落ちたら違う武器でS+に上がるまでチャレンジするってのをやってます。わかば、バケスロソーダ、プライム、ワサビくらいはやったかな？ そろそろまた違う武器かなぁ。S+99は無理そうなんで。。。\n振り返り(今年あったできごと) その他の今年の出来事。\n初香港 初プラハ OSCなど、東京以外でのカンファレンス参加 厄年 東京オフィス！ BBLとかトレーニング lucene-gosenをちょっとメンテ Podcastデビュー？ 初モノ今年も多いかな。 今年は、昨年よりは長く感じた一年でした。 月1くらいで出張してたのもあるのかなぁ？ 香港、プラハはもちろん会社のイベントです。 香港はジャッキーチェンの映画を彷彿とさせるところがちょくちょくあって面白かったです。 ビルとかの補修の足場が竹竿とか。 プラハも面白かったです。やっぱりヨーロッパの古い町は歴史のある建物が多くて楽しいです。\nOSCなどのイベントも色々行きました。福岡、名古屋、大阪、京都、札幌と回りました。 それとは別に大阪、福岡も行ったかな。 来年は沖縄と広島に行きたいなぁ。。。 出張のついで？じゃないですが、御朱印集めし始めました。神社仏閣もいいですよねぇ。\n厄年はきつかった。。。たまたまだとは思うけど、お祓いに行ったのが効いたのかなぁ。後半は特に問題なかったかな。腕時計無くしたと思ったら見つかったりしたし。\n弊社東京オフィスができました。（あんまり行ってないけど） ときどきアクロクエストさんがセミナーを開いたりしてます。 昨年のTour Tokyo後のMeetupでもイベントスペースを使って、Drinkup（勉強会の懇親会だけバージョン）もやりました。 今後もちょこちょことイベントをやってみようかな？\nBBLも始めました。あまりきちんと宣伝してないからそれほど依頼は来てないですが。 あとは、今年も2回日本語でトレーニングしました。 前回はほぼ満席にまでなりました。 来年も頑張りたいかな。ショートカットするためにもいいと思うんで、トレーニングを受けて欲しいんです。。。\nlucene-gosenのメンテもしました。 といってもプログラムではなく、ビルドシステムをAntからGradleに変更したんですが。 来年もちょっとずつ触りたいな。機能面で拡充するかはわからないですが。。。\nPodcastにもデビューさせていただきました。 wyukawaさんのPodcastです。「johtaniさんとElasticsearchについて話しました」楽しかったです。 また出たいなぁというか、喋るの面白かった！\n来年の抱負 もちろん英語の継続 継続的にイベントに登壇 もっと開発＆ブログ サポートエンジニア獲得！ 個人的な検索勉強会の再開 英語はまぁ、当たり前ですね。会社の人つかまえてもっと喋る時間増やさないとだな。\n来年もいろんなカンファレンスなどに出てブース出したり、セッション持ったりして もっともっと広めていかないとなぁ。 あとは、勉強会とMeetupもやっていかないと。入門編と上級編みたいに分けてみるのもありかなぁと考えて見たり。 スピーカー、ご意見募集しております。\n開発に時間をさくための時間の活用をしていかないとなぁと。 どうも時間の使い方がまだ上手くないので。ブログも一緒ですね。。。 月1くらいのペースではかきたいな。。。 ブログもそうだけど書籍もかな？？？？ あと、外資系の他の会社の人ともまた飲みたいなー。\n開発の時間を確保という面ではサポートエンジニアも募集中です。 最近、クライアントが増えて来てチケットが増えて来てるんで、サポートしたりもしてるんです。。。 自分の時間を増やすためにもサポートエンジニアを確保しないと。誰かいい人いないかなぁ。\n個人的にやってた勉強会を忙しいって言って中断してるので、再開しないと。。。\nということで、今年もあと數十分になってしまいました。 今年も色々な方に助けていただけました。お世話になりました。 この場を借りてお礼申し上げます。\n来年もいろんな方々に助けてもらうと思いますが、よろしくお願いいたします。\n","date":1483190534,"dir":"post/2016/","id":"16f1046144ad9ee7bb96214ba7ae7516","lang":"ja","lastmod":1483190534,"permalink":"https://blog.johtani.info/blog/2016/12/31/looking-back-2016/","publishdate":"2016-12-31T22:22:14+09:00","summary":"今年はRioのプレイバック\u000e見ながら書いてます。 今年はなんか長い一年だった気が。 振り返り（2015年に書いた抱負から） まずは去年の抱負を元に","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2016）"},{"contents":"Merry Christmas! Elastic stack Advent Calendar 2016 最終日の記事になります。\n簡単に今年の変遷を振り返ってみます。\nElasticsearch 2.2 (2月) Elasticsearch 2.2.0、2.1.2、1.7.5リリース クエリプロファイラやGeo系の性能改善などが取り込まれました。 また、同時期にリリースされたKibana 4.4ではColor pickerやShare用のURLの短縮化機能なども追加されました。\n第2回目のユーザカンファレンス、Elastic{ON}開催（2月） サンフランシスコで、弊社第2回目のカンファレンスが開催されました。 2015年の会場よりも大きくなり、多数の方に参加いただきました。 ここで、以下の発表がありました。\nElastic StackとX-Packの紹介 これまで、ELK stackと呼ばれて意味明日が、Beatsチームの参加により、ELKだけではなくなったこともあり、Elastic Stackと呼び名を変える事になりました。 また、Marvel、Shield、Watcherなどの商用の拡張機能についても、 単体の名称ではなく、X（Extension）-Packと1つの名前になる事に。 詳細については公式のブログをご覧ください。\nElastic CloudとElastic Cloud Enterpriseの発表 2015年にElasticにジョインし、 これまでFound.no（Found）と呼ばれていた弊社のElasticsearch as a ServiceがElastic Cloudと名称変更しました。 また、Elastic Cloudで培っているノウハウを詰め込んだElastic Cloud Enterpriseも発表しました。実際に利用可能になるまでには まだもう少しかかってしまいますが、アルファ版が公開されていますので、興味のある方は触ってみてください。\nElastic{ON}2016で撮影された、「Elasticsearchがないあなたの人生はどうなりますか？」 といった面白い動画も公開されています。\nElasticsearch 2.3リリース（3月） Elasticsearch 2.3.0および2.2.2をリリース Reindex APIが登場し、Mappingの変更やShard数の変更など、色々とデータの更新などがやりやすくなりました。 また、Task Managementの機能も追加され、長時間かかる処理を間違った場合などの対処が楽になりました。 個人的には、Deprecation Loggingの機能が導入されたことが嬉しいこととなります。次期メジャーバージョンで廃止される機能についてログに出力されるようになりました。 実際に運用されているアプリで利用している機能が今後なくなるかどうかをログを見るとわかるという仕組みです。\nRally登場（4月） Rally登場：Elasticsearchのベンチマークツール Elasticsearchのベンチマークツールがリリースされました。 定期的にElasticsearchの性能を計測することは問題点を見つける事に役に立ちます。そういった手助けをしてくれるツールが公開されることは非常に便利なことかと。\nElastic Stack 5 alpha1 リリース（4月） Elastic Stack 5.0.0 alpha 1 リリース Ingest NodeやLucene 6、新しいKibanaのUIなど多くのものが詰まっていました。ここから多くのユーザにテストしてもらい、5.0の正式リリースを迎えることができました。\nElasticsearch 2.4.0リリース（8月） 2.xの最後のマイナーバージョンリリースです。 Reportingなどの追加とドットつきフィールド名の復活がありました。\nElastic Stack 5.0.0 beta1 リリース（9月） Elastic Stack Release - 5.0.0-beta1 ついにベータです。Painlessがスクリプトのデフォルトになったり、TimelionがKibanaに取り込まれるなど、正式リリースまであと少し！\nPrelertチームジョイン（9月） Welcome Prelert to the Elastic Team Machine Learningエンジンを開発し、Elasticsearch,Kibanaとの組み合わせの製品をリリースしていたPrelertという会社がジョインしました。 Elasticsearchに保存された多くのデータをより活用していただくことができるかと思います。 Elastic{ON} Tour 2016 Tokyoで弊社SAの大輪の発表も人気があるものでした。まだベータ段階ですが、利用して見ることも可能です。 ビデオなどが公開されたらまたツイートしようと思います。\nElastic{ON} Tour Tokyo 2016開催（12月） 今年で2回目のTokyoローカルの1日イベントでした。 ブログは「まだ」書いてませんが、、、今回も盛りだくさんのイベントになりました。 早朝のトレーニング（ハンズオンではない）にも80名近くの方に参加していただけましたし、私はKibanaのキーノート＋デモという大役をもらいましたし、ちょっと大変でした。 今年もAMA（Ask Me Anything）ブースが大盛況でした。 色々な方から、弊社のサポート、開発者が色々な質問を受け、それに答えるという形です。楽しんでいただけたかと思います。 来年もぜひ開催したいなと思っています。\nまた、Elastic{ON}17のセッションもいくつか発表されています。 ぜひ、サンフランシスコで行われる本場のカンファレンスにもご参加ください！\n来年は？ 1月後半か2月にElasticsearch勉強会を検討しようと思っています。スピーカーに興味のある方は連絡いただければと。\n会社としては、Elastic{ON}2017が3月にまた開催されます。これで3回目となります。もちろん私も参加予定なので、参加される方は、現地で会いましょう！\nそのほかにもBIG DATA ANALYTICS TOKYOやオープンソースカンファレンス（大阪）、デブサミといったカンファレンスに参加（登壇・ブースなど）予定です。 参加される方は、ぜひブースまでお越しください。\nでは、また来年のAdvent Calendarでお会いしましょう！\n","date":1482591830,"dir":"post/2016/","id":"002d980d74d19b43ff4e2446665e2fe5","lang":"ja","lastmod":1482591830,"permalink":"https://blog.johtani.info/blog/2016/12/25/elasticsearch-6-features/","publishdate":"2016-12-25T00:03:50+09:00","summary":"Merry Christmas! Elastic stack Advent Calendar 2016 最終日の記事になります。 簡単に今年の変遷を振り返ってみます。 Elasticsearch 2.2 (2月) Elasticsearch 2.2.0、2.1.2、1.7.5リリース クエリプロ","tags":["elasticsearch"],"title":"2016年のElastic Stack"},{"contents":"Elastic stack Advent Calendar 1日目の記事になります。\nElasticsearch 5.0が10月末にリリースされました。 リリースのブログでいくつか紹介されているのですが、そこでは紹介されていない機能について2、3紹介しようと思います。\nその前に、5.0、あれ？その前は2.xじゃなかったっけ？？と困惑されている方もいるかと思うので、簡単に5となった経緯の紹介をしようかと。\nバージョン番号 なぜ2から5に飛んだのかという話ですが、このスライドがその紹介になっています。\nhttps://speakerdeck.com/johtani/elastic-stack-5-dot-0-alpha1-alpha5?slide=5\nElastic{ON} 2016のキーノートでも紹介がありましたが、KibanaやLogstashとElasticsearchを組み合わせて使うときにバージョンのミスマッチで動かないというユーザの声が上がっていました。 2.xのリリースから、同じ日にKibana、Logstash、Beatsもリリースするようになったのですが、 やはり、バージョン番号が異なるため、ミスマッチで動かないというユーザが時々いました。\nElastic Stackという名称にもなったため、バージョン番号をそろえようという事になり、 Elasticsearch、Kibana、Logstash、Beats全てが5.0.0としてリリースされ、 今後は同じバージョン番号になります。\nちなみに、「5」になった理由はKibanaのメジャーバージョンが「4」だったためです。\nさて、では、いくつか機能の紹介を。\nReindex from remote cluster Reindexが2.3から導入されました。データの再登録ができるようになり、マッピングの変更や Shardの数の変更などが柔軟に行えるようになりました。 便利でしたが、あくまでも同一のクラスタでデータを登録し直す形でした。\n5.0からはこの機能に加えて、異なるクラスタからデータを取得してReindexを行うことができるようになりました。 こんな形になります。\nPOST _reindex { \u0026#34;source\u0026#34;: { \u0026#34;remote\u0026#34;: { \u0026#34;host\u0026#34;: \u0026#34;http://otherhost:9200\u0026#34;, \u0026#34;username\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;password\u0026#34;: \u0026#34;pass\u0026#34; }, \u0026#34;index\u0026#34;: \u0026#34;source\u0026#34;, \u0026#34;query\u0026#34;: { \u0026#34;match\u0026#34;: { \u0026#34;test\u0026#34;: \u0026#34;data\u0026#34; } } }, \u0026#34;dest\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;dest\u0026#34; } } usernameとpasswordはリモートのクラスタに認証の気候が存在する場合に利用できるオプションです。 また、ReindexのAPIはクエリを使用して、必要なデータだけを取得することが可能です。 この機能により、1.xや2.xのクラスタからデータを移行することが可能になります。\nCustom analyzer test using Analyze API もう一つ、ちょっとだけ便利な機能を紹介します。 独自にAnalyzerを定義（TokenizerとToken Filterなどを個別に設定）して、その挙動を確認するとき、2.xまでは、インデックスを作成してそのインデックスに対して_analyze APIを呼び出す必要がありました。\n5.xからは_analyze APIの読み出しのパラメータで指定できるようになりました。 こんな感じです。ここでは、lowercaseフィルタのあとに、{...}でstopフィルタを パラメータの中で、指定しています。\ncurl -XGET \u0026#39;localhost:9200/_analyze\u0026#39; -d \u0026#39; { \u0026#34;tokenizer\u0026#34; : \u0026#34;whitespace\u0026#34;, \u0026#34;filter\u0026#34; : [\u0026#34;lowercase\u0026#34;, {\u0026#34;type\u0026#34;: \u0026#34;stop\u0026#34;, \u0026#34;stopwords\u0026#34;: [\u0026#34;a\u0026#34;, \u0026#34;is\u0026#34;, \u0026#34;this\u0026#34;]}], \u0026#34;text\u0026#34; : \u0026#34;this is a test\u0026#34; }\u0026#39; ちょっとだけですが、Analyzerなどを試すのが楽になるのではないでしょうか？\nということで、以上が1日目の記事でした。 Logstashなど、他の5.0.0に関する記事もAdvent Calendarに空きがあるようなので、個別にかこうかなと思います。お楽しみに！\n","date":1480581270,"dir":"post/2016/","id":"550becdd08d00fb1e7fd00c2adc3d3d6","lang":"ja","lastmod":1480581270,"permalink":"https://blog.johtani.info/blog/2016/12/01/elasticsearch-5-dot-0-highlight/","publishdate":"2016-12-01T17:34:30+09:00","summary":"Elastic stack Advent Calendar 1日目の記事になります。 Elasticsearch 5.0が10月末にリリースされました。 リリースのブログでいくつか紹介されているのですが、そこでは紹介されて","tags":["elasticsearch"],"title":"Elasticsearch 5.0の便利機能紹介？"},{"contents":"久しぶりに、技術的なブログ書いてます。\nIngest Processorのプラグインを作ってみたくなったので、書いてみました。 ただ書いてみるんじゃ3番煎じになりそうなので、cookiecutterを使ってみました。\nと言っても、同僚のAlexがcookiecutter-elasticsearch-ingest-processorと言うテンプレートを作ってくれているのを使っただけですが。（https://discuss.elastic.co に投稿された記事で、使い方がアニメgifで説明されててわかりやすいです）\ncookiecutterとは、コマンドラインで質問に答えると、テンプレートからプロジェクトが生成できるツールです。 Elasticでは、カスタムBeatを作る時に利用する例がいつかの日本語ブログや発表資料で話題になっていました。 これのIngest Processorのプラグインバージョンです。\n今回は、NEologdも使ってみたかったので、Lucene Kuromoji for NEologdを利用して 指定した品詞の単語だけを抽出するProcessorを作ってみました。\nGitHubのプロジェクト：https://github.com/johtani/elasticsearch-ingest-kuromoji-pos-extract\nCookiecutterの使い方 Cookiecutterのインストールはサイトをご覧ください。\ncookiecutter gh:spinscale/cookiecutter-elasticsearch-ingest-processor あとは、出てくる以下の項目を指定するだけです。\nprocessor_type : Ingest Processorのタイプ名です。kuromoji_part_of_speech_extractとしました。（Alexのだと_を使うとちょっと問題があるので後述） description : readme.mdに利用されます。 developer_name : 名前を記載。Javaのファイルのヘッダに利用 elasticsearch_version : デフォルトで5.0.0-alpha4が指定されているので、特に指定せず 以上の質問に答えたら、プロジェクトのディレクトリ構造が出来上がってます。 プロジェクトのビルドなどにはGradleを利用します。\nプロジェクトのIntelliJ IDEA用のファイルを生成 build.gradleファイルでGradleのideaプラグインがapplyされているので、以下のコマンドを叩けばIntelliJ IDEAのプロジェクトファイル（？）が生成され、IntelliJで開けばすぐに開発ができる状態にできます。\ngradle idea コーディング あとは、必要処理をコーディングします。 実際にコーディングするクラスはorg.elasticsearch.plugin.ingest.kuromoji_part_of_speech_extractのパッケージにある以下の2つです。（パッケージ名にはprocessor_typeの名前が指定されている）\nIngestKuromojiPartOfSpeechExtractPlugin KuromojiPartOfSpeechExtractProcessor IngestKuromojiPartOfSpeechExtractPlugin Pluginというクラスは、プラグインをNodeのModuleとして登録する処理を書くクラスとなります。 生成してすぐは、次のような形になっています。（※importやクラス定義の部分は省略しています。）\n... public static final Setting\u0026lt;String\u0026gt; YOUR_SETTING = new Setting\u0026lt;\u0026gt;(\u0026#34;ingest.kuromoji_part_of_speech_extract.setting\u0026#34;, \u0026#34;foo\u0026#34;, (value) -\u0026gt; value, Setting.Property.NodeScope); @Override public List\u0026lt;Setting\u0026lt;?\u0026gt;\u0026gt; getSettings() { return Arrays.asList(YOUR_SETTING); } public void onModule(NodeModule nodeModule) throws IOException { nodeModule.registerProcessor(KuromojiPartOfSpeechExtractProcessor.TYPE, (registry) -\u0026gt; new KuromojiPartOfSpeechExtractProcessor.Factory()); } ... YOUR_SETTINGプロパティとgetSettings()メソッドはelasticsearch.ymlで指定したい設定を記述する場合の例になります。今回は特に必要ないので両方削除しました。 最終系はGitHubのコードをご覧ください。\nKuromojiPartOfSpeechExtractProcessor Processorは実際にIngest Nodeで行う処理を書くところです。\npublic static final String TYPE = \u0026#34;kuromoji_part_of_speech_extract\u0026#34;; private final String field; private final String targetField; public KuromojiPartOfSpeechExtractProcessor(String tag, String field, String targetField) throws IOException { super(tag); this.field = field; this.targetField = targetField; } @Override public void execute(IngestDocument ingestDocument) throws Exception { String content = ingestDocument.getFieldValue(field, String.class); // TODO implement me! ingestDocument.setFieldValue(targetField, content); } @Override public String getType() { return TYPE; } public static final class Factory extends AbstractProcessorFactory\u0026lt;KuromojiPartOfSpeechExtractProcessor\u0026gt; { @Override public KuromojiPartOfSpeechExtractProcessor doCreate(String processorTag, Map\u0026lt;String, Object\u0026gt; config) throws Exception { String field = readStringProperty(TYPE, processorTag, config, \u0026#34;field\u0026#34;); String targetField = readStringProperty(TYPE, processorTag, config, \u0026#34;target_field\u0026#34;, \u0026#34;default_field_name\u0026#34;); return new KuromojiPartOfSpeechExtractProcessor(processorTag, field, targetField); } } TYPEがIngest APIのPipelineでProcessorを指定するときに使う名前になります。ここは、cookiecutterの時にprocessor_typeに入力した文字列になっています。 kuromoji_part_of_speech_extractだと長いので、kuromoji_pos_extractに変えました。\nexecute()メソッドに// TODO implement me!とあります。 この部分に実際の処理を記述していきます。\nあとは、FactoryクラスでIngest APIで指定された設定項目を読み込みます。 今回作成したelasticsearch-ingest-kuromoji-pos-extractでは品詞を指定する必要があるので、pos_tagsを指定できるように処理を追加しました。\n私が実装したものの説明をするとちょっと長くなりそうなので、GitHubのコードをご覧ください。\nテストのコーディング テストのクラスもテンプレートで生成されています。\nKuromojiPartOfSpeechExtractProcessorTests KuromojiPartOfSpeechExtractRestIT KuromojiPartOfSpeechExtractProcessorTests Processorクラスのテストになります。生成直後は次のような感じです。\npublic void testThatProcessorWorks() throws Exception { Map\u0026lt;String, Object\u0026gt; document = new HashMap\u0026lt;\u0026gt;(); document.put(\u0026#34;source_field\u0026#34;, \u0026#34;fancy source field content\u0026#34;); IngestDocument ingestDocument = RandomDocumentPicks.randomIngestDocument(random(), document); KuromojiPartOfSpeechExtractProcessor processor = new KuromojiPartOfSpeechExtractProcessor(randomAsciiOfLength(10), \u0026#34;source_field\u0026#34;, \u0026#34;target_field\u0026#34;); processor.execute(ingestDocument); Map\u0026lt;String, Object\u0026gt; data = ingestDocument.getSourceAndMetadata(); assertThat(data, hasKey(\u0026#34;target_field\u0026#34;)); assertThat(data.get(\u0026#34;target_field\u0026#34;), is(\u0026#34;fancy source field content\u0026#34;)); // TODO add fancy assertions here } テストメソッドも実装されていますが、パラメータの追加の設定処理やアサーションが書かれてません。 実装に合わせて、アサーションや設定処理を追加しましょう。\nKuromojiPartOfSpeechExtractRestIT こちらはIntegration Testになります。 実際にElasticsearchに対して外部からAPIを叩くような感じです。 APIを叩くときに利用するJSONの設定やアサーションはsrc/test/resourcesにyamlファイルがあります。\n10_basic.yaml 20_kuromoji_part_of_speech_extract_processor.yaml 10_basic.yamlはプラグインがインストールされているかの確認のテストです。特に変更する必要はないです。\n20_kuromoji_part_of_speech_extract_processor.yamlは実際にコーディングしたProcessorが動くかどうかのテストです。\nテストの内容については、GitHubのコードをご覧ください。\nテストの実行とZipの生成 テストの実行とZipの生成は次のコマンドを実行すればOKです。\ngradle check テストに問題があった場合は、コケますし、問題なければSUCCESSと表示が出ます。 成功した場合はbuild/distributions/というディレクトリにzipファイルができています。 これをElasticsearchのpluginコマンドでインストールすれば動きます。\nbin/plugin install file:///path/to/elasticsearch-ingest-kuromoji-pos-extract/build/distribution/ingest-kuromoji_part_of_speech_extract-0.0.1-SNAPSHOT.zip kuromoji_pos_extractの利用方法 Ingest APIには便利なSimulate Pipeline APIがあります。\nということで、mecab-ipadic-NEologdにあったサンプルの文章を使って、使い方の説明です。\nPOST _ingest/pipeline/_simulate { \u0026#34;pipeline\u0026#34; : { \u0026#34;description\u0026#34; : \u0026#34;kuromoji neologd extract test\u0026#34;, \u0026#34;processors\u0026#34; : [ { \u0026#34;kuromoji_pos_extract\u0026#34; : { \u0026#34;field\u0026#34; : \u0026#34;body\u0026#34;, \u0026#34;target_field\u0026#34; : \u0026#34;noun_field\u0026#34;, \u0026#34;pos_tags\u0026#34; : [ \u0026#34;名詞-固有名詞-組織\u0026#34;, \u0026#34;名詞-固有名詞-一般\u0026#34;, \u0026#34;名詞-固有名詞-人名-一般\u0026#34;, \u0026#34;名詞-固有名詞-地域-一般\u0026#34;, \u0026#34;名詞-固有名詞-地域-国\u0026#34; ] } } ] }, \u0026#34;docs\u0026#34; : [ { \u0026#34;_index\u0026#34;: \u0026#34;index\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;type\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;id\u0026#34;, \u0026#34;_source\u0026#34;: { \u0026#34;body\u0026#34; : \u0026#34;10日放送の「中居正広のミになる図書館」（テレビ朝日系）で、SMAPの中居正広が、篠原信一の過去の勘違いを明かす一幕があった。\u0026#34; } } ] } 結果はこちら。\n{ \u0026#34;docs\u0026#34;: [ { \u0026#34;doc\u0026#34;: { \u0026#34;_index\u0026#34;: \u0026#34;index\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;id\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;type\u0026#34;, \u0026#34;_source\u0026#34;: { \u0026#34;noun_field\u0026#34;: [ \u0026#34;10日\u0026#34;, \u0026#34;中居正広のミになる図書館\u0026#34;, \u0026#34;テレビ朝日\u0026#34;, \u0026#34;SMAP\u0026#34;, \u0026#34;中居正広\u0026#34;, \u0026#34;篠原信一\u0026#34; ], \u0026#34;body\u0026#34;: \u0026#34;10日放送の「中居正広のミになる図書館」（テレビ朝日系）で、SMAPの中居正広が、篠原信一の過去の勘違いを明かす一幕があった。\u0026#34; }, \u0026#34;_ingest\u0026#34;: { \u0026#34;timestamp\u0026#34;: \u0026#34;2016-07-22T06:18:49.007+0000\u0026#34; } } } ] } noun_fieldに固有名詞の単語が抜き出せているのがわかるかと思います。\nAlexのテンプレートで困った点 テンプレートは便利だったのですが、processor_typeに_を使用したタイプ名を指定すると次のような問題（？）が発生しました。\nクラス名がKuromoji_part_of_speech_extractProcessorとなってしまう 深刻な問題ではないのですが、JavaだとCamel Caseが普通なのでちょっと気になって。 ということで、プルリク作って出してみました。まだ取り込まれてないかな。\n取り込み前に使いたい方は以下のコマンドを実行してください。 processor_class_nameという項目が増えています。 デフォルトだとprocessor_typeの_の部分を取り除きつつCamel Caseにしたものが入ります。\ncookiecutter gh:johtani/cookiecutter-elasticsearch-ingest-processor まとめ ということで、とりあえず作ってみましたというものになります。 特徴的な単語（固有名詞だけ）を抜き出して、別のフィールドにできるので、タグみたいなものをこれを使って前処理で作れるようになるかなぁと。\n参考ブログ（元ネタ？） インスパイア元となったブログです。\nUser Agentを解析するIngest Pluginを書いてみた Elasticsearch 5.0.0のIngest Node用プラグインを書いた話 ","date":1469161616,"dir":"post/2016/","id":"a62186ea292d6db03a087bd5dfcc3f1e","lang":"ja","lastmod":1469161616,"permalink":"https://blog.johtani.info/blog/2016/07/22/making-ingest-processor-plugin-with-cookiecutter/","publishdate":"2016-07-22T13:26:56+09:00","summary":"久しぶりに、技術的なブログ書いてます。 Ingest Processorのプラグインを作ってみたくなったので、書いてみました。 ただ書いてみるんじゃ3番煎じ","tags":["elasticsearch","plugin"],"title":"Lucene Kuromoji for NEologdで指定した品詞の単語を抜き出すIngest Pluginを書いてみた #elasticsearchjp"},{"contents":"なんか、今年はよく物が壊れる、厄年だからかなぁ？\nということで、記念に何が壊れたかをブログに残しておこうかと。\n腕時計（壊れてないかな） 電波腕時計を使ってたんだけど、電池がへたってたのでオーバーホールしてもらった。 Moto 360（壊れたというか。。。） 何度かバージョンアップしてるんだけど、数ヶ月前から、ちょっと触っただけで電源が落ちる現象が。ファームウェアのせいかAndroid Wearのバージョンアップのせいかわからないけど。。。挙げ句の果てに、電源を入れるために充電器にセットしないといけないと言う酷い仕様。。。 自転車前輪 自転車で車道を横切る側溝の蓋の間に前輪がはまってすっ転んでしまい、タイヤのスポークがちょっと曲がってしまう ジーンズその1 自転車で転んだ時に、膝とかこすって破れる ジーンズその2 福岡出張中に雨で滑って派手に転んで、膝に大きな穴が。。。 リュック あー、怪しいなと思ってたんだけど、やっぱりこわれた、、、 pic.twitter.com/CD2Y7t6AOD\n\u0026mdash; Jun Ohtani (@johtani) 2016年6月16日 怪しいとは思ってたんだけど。。。 ということで、リュックを新調しつつ修理に出してるところ。 5. Xperia Z3 * 先週金曜日にカメラのレンズが結露してるなぁと思ったら、電源が入らなくなった。補償サービスに入ってたんで、新しいZ3を次の日に送付してもらい復旧。いろいろなアプリがログインしないといけないのでかなり大変だった。。。\nまだ、半年残ってるので他にも壊れるのかなぁ。。。 お祓いしてもらったので、何もなければいいんだけど。\nということで、なんとなく欲しいものリストを貼っておきますね。\n","date":1467251858,"dir":"post/2016/","id":"167e2a6833d49ce198cb3b88f521991e","lang":"ja","lastmod":1467251858,"permalink":"https://blog.johtani.info/blog/2016/06/30/broken-something-in-this-year/","publishdate":"2016-06-30T10:57:38+09:00","summary":"なんか、今年はよく物が壊れる、厄年だからかなぁ？ ということで、記念に何が壊れたかをブログに残しておこうかと。 腕時計（壊れてないかな） 電波腕時","tags":["misc"],"title":"よく物が壊れる年"},{"contents":"第16回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 今回は、司会だけに注力してみました（）。\nチェックイン数など チェックインした人：141名 キャンセルしなかった人：67名 でした。\n今回は、参加希望者が多くて、当日にも100名近いキャンセル待ちの方がいたので、 240名まで、参加者枠を増枠（会場キャパ190名程度）して対応しました。 まぁ、読み通り、1/3の方はキャンセルしない形でした。 天気も良く電車の遅延などもなさそうだったので、ちょっとドキドキしてたのですが。\n以下は簡単なメモです。\n「LogstashとElasticsearchで作るEnterprise Search Platform」/ Elastic Kosho Owa スライド：https://speakerdeck.com/kosho/enabling-enterprise-search-platform-with-elastic-stack\n使ってるLogstashの設定ファイルを elastic-japan at elastic dot co に送るとTシャツがもらえるらしい。 Logstashのfilter-rubyはここで、evalしてcallしてるから、特にforkとかしてないかと。 「企業・業界情報プラットフォームSPEEDAにおけるElasticsearchの活用」 / 株式会社ユーザベース 北内 啓さん スライド：http://www.slideshare.net/tau3000/speedaelasticsearch-63510388\nアルゴリズム関連の開発担当 企業データをいろんな軸で検索したい データ数が約70億レコードになりそう（通貨 x MySQL） 300万企業データ＋Nestedとかで持ってる。 11万フィールド？？？ 10台の物理サーバに24仮想マシン 企業名の検索 recall重視 NewsPicksの検索機能 「日本 化粧品 売上高」業界のデータとかも観れるのかな？有料会員向け機能 登録済みキーワードかどうかをRDB＋Esに検索して、ID化するっぽい ID（Analyze必要ない）検索だから、termクエリだった、サンプルが。 ノードの役割分担 更新はMasterNode経由でDataNodeへ。 検索はClientNode経由でDataNodeへ。 1.xかぁ。。。 「Elasticsearchベースの全文検索システムFess」 / 株式会社エヌツーエスエム 菅谷信介さん スライド：http://www.slideshare.net/shinsuke/elasticsearchfess\n10.xからSolrをやめてElasticsearchへ。 日本語検索 bigram＋形態素（1文字検索とかに対応するため） NeologDに対応したkuromojiを利用 DBFluteをESFluteとしてEs対応 KOPFを組み込んで使ってる configをREST API経由で更新できるプラグインあり LT 「ElasticsearchとGCPのネットワークでハマった話」 株式会社サイバーエージェント 平田大地 さん @daichild スライド：https://speakerdeck.com/daic_h/gcpfalsenetutowakudehamatutahua\nhhkb2 2刀流！ networkのKeep-alive周りで困ったよというお話。 後で聞いたけど、GCE Cloud Pluginは使ってるそうです。 06/28 17:00追記\nPingを定期的に実行させることで回避も出来るようです。 transport.ping_scheduleに時間を指定します。通常のNode（Transport以外）は\u0026rsquo;-1\u0026rsquo;が指定してあり、動作してません。 「スクリプトフィールドで作るランキングみたいな何か」iwag さん スライド：https://speakerdeck.com/iwag/elasticsearch-dezuo-rurankingu\n1.xかぁ。。。 あとは、function_scoreとかも面白いですよ！ その他、感想などのブログ 第16回elasticsearch勉強会に参加してきた 第16回Elasticsearch勉強会に参加してきた まとめ＋宣伝？ 1.xがまだまだいますねぇ、早く2.xにアップしましょう！（5.0ももう直ぐだし）。懇親会でも色々と話しましたが、https://discuss.elastic.co というフォーラムあるので、ぜひ活用してください。\n次回は8月末か9月頭かでしょうか。 7月末にOSC京都に出没するので、京都で勉強会やりたいと思ってます！ 会場とかスピーカーとか興味ある人連絡ください。\n東京の勉強会のスピーカーも随時募集中ですので、連絡ください。\n","date":1467089755,"dir":"post/2016/","id":"993e58f132740b464ecf06ee289dc7b2","lang":"ja","lastmod":1467089755,"permalink":"https://blog.johtani.info/blog/2016/06/28/16th-elasticsearch-meetup/","publishdate":"2016-06-28T13:55:55+09:00","summary":"第16回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第16回Elasticsearch勉強会を開催しました。 #elasticsearchjp"},{"contents":"第15回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 今回は、Elastic{on} 2016開催直後ということで、大半はElastic{on}に関する話でした。\nチェックイン数など チェックインした人：114名 キャンセルしなかった人：62名 でした。 今回は、少しおそめで1時間前にキャンセル待ちがいない状態にしました。 まぁ、いつもの感じでしょうか。数値も安定してきた感じですかね。\n\u0026ldquo;Elasticsearchと機械学習を実際に連携させる\u0026rdquo; / Preferred Networks America, Inc. CTO 久保田展行(Kubota Nobuyuki) さん スライド：Elasticsearchと機械学習を実際に連携させる\n前回の続きの話で、今回が本題でした。\n勉強会直前に発表されたSensorBeeをElasticsearchと一緒に使うとどんなことができるかというお話です。 まぁ、前処理重要ですよねというのが、いつものことですが、印象的でした。 いつものようにわかりやすい説明だったので、使ってブログを書いて欲しいなと。\n発表の中で、説明に出てきたデモとか。\nCES2016でロボットカーのデモを展示してきました \u0026ldquo;Elastic{ON} 2016レポート\u0026rdquo; / Elastic Jun Ohtani スライド：elastic{on} 2016 レポート\n写真多めで、キーノートをメインに話をしました。\n簡単なまとめとしては\nプロダクトロゴができました。ロゴ画像などはこちら 次のメインバージョンは全て5.0。（5.0に関する通知が欲しい人はこちらで登録できます） elastic{on} 2016のビデオなどはこちら BBL始めます。連絡ください \u0026ldquo;Elastic{ON}の過ごし方\u0026rdquo; / クラスメソッド株式会社 藤本 真司 さん スライド：Elastic{ON}の過ごし方\n印象に残ったのは\n「自他共に認めるブログの会社」 4/12にSAPさんに会場を借りてElastic＆クラスメソッドでイベントやります。 やっぱりご飯が美味しいんですねぇ。 早速ブログが書かれてました。\n\u0026ldquo;Elastic{ON} 2016 見るべきセッション資料 7選\u0026rdquo; / Acroquest Technology株式会社 谷本 心 さん スライド：Elastic{ON} 2016 見るべきセッション資料 7選 #elasticsearchjp\n印象に残ったのは\n東京でハンズオンやる会場提供者募集中！ Ingest Node（参考：Ingest Nodeのドキュメントは公開中。） Reindex API（参考：Backport reindex to 2.x ） その他、感想などのブログ 第15回elasticsearch勉強会にLTで登壇しました #elasticsearch #elasticsearchjp 第15回elasticsearch勉強会に参加してきました #elasticsearch #elasticsearchjp まとめ＋宣伝 来年のElastic{ON}に参加したいと思っていただけたらよかったなと。\n4/12にクラスメソッドさんとイベントを行います。また、ツイートすると思います。\n次回はいつも通りだと5月中旬になるかと思います（大丈夫かな？OSC 2016 Nagoyaでしゃべったり、ブース出したりとかするけど）。 5末に名古屋に出没します。名古屋で勉強会できればやりたいと思ってます。会場とかスピーカーとか興味がある方は連絡ください。\n","date":1458186180,"dir":"post/2016/","id":"c56a76ef8f604a8d87be2a32b1f81fac","lang":"ja","lastmod":1458186180,"permalink":"https://blog.johtani.info/blog/2016/03/17/15th-elasticsearch-jp/","publishdate":"2016-03-17T12:43:00+09:00","summary":"第15回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第15回Elasticsearch勉強会を開催しました。 #elasticsearchjp"},{"contents":"久々のポスト。。。\n久々に、技術書読んでます。「自然言語処理の基本と技術」という本です。\n監修の方のツイートを見て気になったので、買ってみました。 書籍のサイトの説明はこんな感じでした。\n本書は、この未来に不可欠となるに違いない自然言語処理の、技術的、ビジネス的基礎知識をくまなくコンパクトに図解した一冊です。 著者陣もそれぞれの分野の第一線で活躍するエキスパート揃い！\n確かに著者陣がすごいです。\nまだ、「はじめに」と自分に関係のある「情報検索」の章を流し読みしただけなんですが、次のような特徴がある本です。\n平易な単語で説明してある（難しい専門用語が少ない） 数式が出てこない（多分。少なくとも読んだ部分では見てない） 説明には例と図解がある 情報検索の章で言うと、全文検索でよく使われる転置インデックス（索引という単語が使われてる）がなぜ必要なのか、どういう感じで作られるのか、 転置インデックスに利用する索引の単語をどうやって作るのか（文字N-Gramや形態素解析）、単語の正規化（ステミングやストップワード）などの説明が 本当にわかりやすく書かれています。 スコアリングについても触れられています。\nElasticsearchも転置インデックスを用いた検索を行っており、 MappingでAnalyzerの指定をしている理由などの理解に役に立つと思います。\n全文検索システムがどのように検索を処理しているかをざっくり理解するのにはもってこいじゃないかと。 1点残念だなと思ったのは、書籍に「索引」がありませんでした（本の索引を思い浮かべてくださいっていう説明あったんだけど）。。。 Kindle版を購入すれば「検索」できるのかな？\nということで、まだ、流し読みしただけなんですが、「すごく」オススメです。 購入はこちらから！\n","date":1457962452,"dir":"post/2016/","id":"3fc7462a83fa55885067fee629287e8a","lang":"ja","lastmod":1457962452,"permalink":"https://blog.johtani.info/blog/2016/03/14/review-basics-and-tech-of-nlp/","publishdate":"2016-03-14T22:34:12+09:00","summary":"久々のポスト。。。 久々に、技術書読んでます。「自然言語処理の基本と技術」という本です。 監修の方のツイートを見て気になったので、買ってみました","tags":["本"],"title":"「自然言語処理の基本と技術」を読んでる"},{"contents":"あけましておめでとうございます、johtaniです。\n第14回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 今年もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\nチェックイン数など チェックインした人：122名 キャンセルしなかった人：58名 でした。 今回も当日の昼の時点でキャンセル待ちがない状態にしていました。 いくつか電車が止まっていたという話を聞いていたので、開始を5分遅らせ、 受付は45分くらいまで開けておくという対応をしてもらいました。\n\u0026ldquo;ココが辛いよelasticsearch\u0026rdquo; / 株式会社リクルートテクノロジー @tatakaba さん スライド：ココが辛いよelasticsearch\n実際にいくつかのサービスで運用されている内容とどういった機能を利用しているか、 どういったものを独自に作っているかという話をしていただきました。\n独自PluginでA/Bテストしてる Snapshotの活用 Index作成は環境に合わせて行っている。 バージョンは混在 PusnaRSのバージョンアップの話。 2つのバージョンのクラスタを用意してリアルタイムに切り替え。 Elasticsearchの活用 QueryのRewrite： SolrのリクエストをEsで受け付けたり。 辛い話。 バージョンアップが辛い Riverなくなるのつらい データずれるのつらい 補足：\nバージョンアップについて 1.x系から2.x系にアップされるのであれば、こちらを必ず試してください。\nhttps://github.com/elastic/elasticsearch-migration\n「.」が使えなくなるという話は、Solrとの大きな違いになるのかもなぁと。 ネスト構造のデータの表記を「.」で行うというのを厳密に行えるように、 「.」を使えなくしたというのがあるかと。\nRiverについて Riverがなくなった理由については、https://www.elastic.co/blog/deprecating-rivers で記載があります。 便利なのですが、負荷が偏ったり、スケールしないとかいう問題点があるかなと。\n良いサンプルとしては、JDBC Riverなどは、Javaのプログラムとして起動できるように変更されていたりします。\nhttps://github.com/jprante/elasticsearch-jdbc/wiki/jdbc-plugin-feeder-mode-as-an-alternative-to-the-deprecated-elasticsearch-river-api\n（個人的 には、SolrのDIHもRiverもあんまり好きではなかったです。データの変換処理と、ロード処理は別々にしたい人だったので。）\nデータのズレなど 耐障害性とか信頼性に関しては、どういった問題点があるのか、どういった対応をしているのかというのがまとめられたページが用意されています。\nhttps://www.elastic.co/guide/en/elasticsearch/resiliency/current/index.html\n「機械学習を利用したちょっとリッチな検索」 / Preferred Networks America, Inc. CTO 久保田展行(Kubota Nobuyuki) さん スライド：機械学習を利用したちょっとリッチな検索\n来日していただき、機械学習と検索の話をしてもらいました。 本編は次回の発表かもw\n機械学習を元に、検索対象の情報を元の情報から増やしてあげる。 増えた情報を検索できるようにする 今日のゴール： 機械学習とはどういうものか？ データの集め方とか、アノテーションとか 学習の方法（ツールやライブラリに依存） Esでの活用方法 オフラインで学習させて、情報を付与した後に、Elasticsearchに入れる Jubatus＋fluentdで ChainerサポートのOSSのツールを公開予定 「ここからが本当の地獄だ。。。」ってのが聴きたいw\n「Lucene Query 再考 - Domain Specific Query 実装 -」 / Supership株式会社 インフラ事業開発本部検索グループ 大川真吾 さん スライド：Lucene Query 再考 - Domain Specific Query 実装 -\nLuceneのクエリに関する話と、クエリパーサーに関する話でした。 こういった濃い話も勉強会でしてもらえると、色々な参加者に楽しんでいただけるかなぁと。 次回も続きを話してもらう予定です。\n補足：\n参考までにですが、Elasticsearchに入門したての人向けに、 Analyzerとか転置インデックスとかの話をした時のスライドになります。 https://speakerdeck.com/johtani/lucenetori-ben-yu-falsejian-suo\nLT: Fluentd meets Beats / @repeatedly さん スライド：http://www.slideshare.net/repeatedly/fluentpluginbeats-at-elasticsearch-meetup-14\n参考Qiita：http://qiita.com/repeatedly/items/77af41788f0b3ccdefd2\nBeatsの説明をTDの人からしてもらうなどw FluentdにBeatsからのデータを流し込めるようにしたプラグインが出たという話でした。\nfilebeatの性能の件は社内で聞いてみようかと。\nElasticsearchインデクシングのパフォーマンスを測ってみた / 日本IBM　黒澤亮二さん スライド：Elasticsearchインデクシングのパフォーマンスを測ってみた\n参考Qiita：http://qiita.com/rjkuro/items/e79eec7ffb0511b7c678\n細かな性能測定の結果を駆け足で話してもらいました。 皆さんもこの指標をもとに、手元の環境を計測してみたりしてみてもらえればと。\nあとは、2.x系になってるので、同じ方法で計測してもらってまた 発表してもらえると嬉しいなー（棒）\nその他、感想などのブログ Elasticsearch勉強会　第14回フィードバック まとめ＋宣伝 久々に（初めてかな？）、ゲストがいないのに自分が喋りませんでした。 次回は3月中旬を予定してます。 次回は、Elastic{ON}16の報告をする予定です。いろいろと発表あるだろうし。\nあと、今月末の1/29にオープンソースカンファレンス 2016.enterprise@Osakaにブース出展します。 セミナー枠でも弊社OSSプロダクトの概要を話しする予定です。 関西の方は、ぜひ参加していただければと。ブースでお待ちしております。\nまた、スピーカーや場所が用意できたら、出張勉強会もまたやりたいなと思っています。 興味ある方は、連絡ください！\n","date":1452220496,"dir":"post/2016/","id":"4b0a768585da8f9f8f8db1ca409e7ebd","lang":"ja","lastmod":1452220496,"permalink":"https://blog.johtani.info/blog/2016/01/08/14th-elasticcsearch-jp/","publishdate":"2016-01-08T11:34:56+09:00","summary":"あけましておめでとうございます、johtaniです。 第14回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆","tags":["elasticsearch","勉強会"],"title":"第14回Elasticsearch勉強会を開催しました。 #elasticsearchjp"},{"contents":"今年は紅白見ながら書いてます。 早い一年だったなぁ。\n振り返り(2014年に書いた抱負から) まずは去年の抱負を元に振り返りをば。\n英語の継続 海外のイベントへの参加 多岐にわたるイベントでのスピーカー 日本の人員の倍増！？ Elasticsearchに関する日本語の情報発信 Elasticsearch座談会みたいなものの開催 英語はまぁ、継続してます。亀の歩みですが。。。\n海外のイベントへの参加は、自社のイベントだけでした。来年のElastic{ON}ももちろん参加です。来年こそBerlin Buzzwords行きたいな。。。\n多岐にわたるイベントとまではいってないですかね。。。来年はOSC(大阪や東京)に出没予定です。参加される方は、声をかけていただければと。\n人員は倍増しました！営業の方が参画されたのがかなり助かってます。 今現在で4名です！来年も倍増できるかなぁ？\n日本語の情報発信はリリースブログの翻訳が多めでした。来年は独自コンテンツも増やさないとなぁ。 あとやっぱ書籍かなぁ。。。座談会は来年の課題に。。。\n振り返り(今年あったできごと) その他の今年の出来事。\n初渡米 初バルセロナ 東京以外で勉強会 初自社イベント（日本で） 初トレーナー 不惑 今年も初モノ多いですね。今年も楽しい一年でした。 自社イベントでアメリカやバルセロナなどに行きました。40年近く、海外に行ったことないせいか、海外に行って経験することが面白いです。\n東京以外での勉強会もやりました。名古屋、大阪、京都、北海道と。 来年もOSCで訪れた場所で勉強会を開催したいなぁと。\n自社のイベント（Elastic{ON} Tour Tokyo）も東京でやりました。 どうなることかと思っていましたが、朝から大勢の方に来ていただけてホッとしました。 自分のトークがどうだったのかという反応も気になりますが。。。 せっかくShayたちが来ていたので、もっとブースに話しに来てもらえるともっと嬉しかったかもなぁと。\nTour Tokyoを挟んで自社の公式トレーニングのトレーナーもやりました。 日本で3回目にして、初の日本語でのトレーニングでした。前の2回は逐次通訳だったんですが。 トレーニングって大変だなぁと思ったのと、やはり日本語でトレーニングを受けられるとだいぶ違うだろうなという実感がありました。 来年もできればいいなと。トレーニング自体があったことを知らない人もいたのかなぁ？\n来年の抱負 英語の継続 もっとElasticsearchの開発に参加 人員の倍増？ 日本語情報発信 Splatoon S+? 英語あいかわらず出来てないので、頑張らないと。 もっと喋ったりしないとなんだろうなぁ。\n来年は開発をもっとやりたいなと。 来年1月にはセールスのエンジニアが加入するので、開発にもっと時間を割きたいなと。\n人員は倍増できるように頑張りたいです。少なくとも、2人が1月に入ることは決まってるんで、後二人！\nブログももっと書かないとですね。新機能とかこんな使い方できるよとか。 どんな記事が欲しいかとかコメントもらえると楽なので、突っ込みくださいw\n最後は、完全に私用ですね。Splatoonにはまってますw SとA+を行ったり来たりで。。。\nということで、今年はあと、数時間ですが、色々とお世話になりました。 この場を借りてお礼申し上げます。\n来年も、いろんな方に絡んでいくとは思いますが、よろしくお願いいたします。\n","date":1451565182,"dir":"post/2015/","id":"c54909ecf4fb3e9afeea36200fe95dce","lang":"ja","lastmod":1451565182,"permalink":"https://blog.johtani.info/blog/2015/12/31/looking-back-2015/","publishdate":"2015-12-31T21:33:02+09:00","summary":"今年は紅白見ながら書いてます。 早い一年だったなぁ。 振り返り(2014年に書いた抱負から) まずは去年の抱負を元に振り返りをば。 英語の継続 海外の","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2015）"},{"contents":"今年最後のAdvent Calendarとなります。\nこの記事はElasticsearch Advent Calendar 2015の最終日のエントリです。\n簡単に今年の変遷を、Elasticsearchをベースに振り返ってみようかと思います。\nKibana 4リリース（2月） Kibana 4（日本語訳） いきなり、Elasticsearchではない話題ですが。 AggregationベースのKibanaがリリースされました。 画面が黒くないというので、話題になりましたw 12月末時点では、4.3.1になっています。 Sub Aggregationによる強力なグラフ表示や異なるインデックスに対するグラフを 一つのダッシュボードに表示できるといったことができるようになりました。\nセキュリティ向けプラグインShieldのリリース（2月） セキュリティ向けプラグインShieldのリリース（日本語訳） 商用向けのプラグインの第2弾です。 セキュリティ強化のためのプラグインで、いろいろなところで引き合いがあったりします。\n初のユーザカンファレンス、Elastic{ON}開催（3月） #elasticon に参加中 サンフランシスコで、弊社初のカンファレンスが開催されました。（来年（2016年）もサンフランシスコで開催されます。） また、ここで、以下の2点の発表がありました。\nロゴ及びドメイン名などの変更 Foundのジョイン 約1300名が参加する大イベントでした。 初の渡米で楽しんできましたが、ドメインの切り替えなどは大変でした。。。 まだ、ロゴを変えて1年経ってないということが実感できてないです。\nFoundのジョインはまだまだ、日本で知名度が出てないかもなぁと。 もっと広めないと。 利点としては以下の通りです。\n新バージョンがすぐに利用可能に。また、バージョンアップも画面で指定可能 公式プラグイン＋その他いくつかのプラグインが利用可能 Elasticsearch 1.5 リリース（4月） Elasticsearch 1.5.0リリース（日本語訳） 主に、resiliencyに関する改良になります。 毎リリースで信頼性向上につながる改良が含まれる形になっています。 このリリースの近くで初の東京の外での勉強会を名古屋で開催したりもしました。\ndiscuss.elastic.coをオープン（5月） https://discuss.elastic.co これまでは、Google Groupsを使っていましたが、Elasticが提供しているプロダクトが 別々のグループであったために、プロダクトにまたがった質問がやりにくかったり、検索がしにくかったりという問題点がありました。 今では、過去のGoogle Groupsのデータも移行されているので、是非参加して、質問・回答してみてください。 日本語でやりとりできるカテゴリもあるので、どんどん、やりとりしていただければ。\nElasticsearch 1.6 リリース（6月） Elasticsearch 1.6.0リリース（日本語訳） 2.0に向けたUpgrade APIが含まれるなど、次期リリースに向けた準備が整いつつあるリリースでした。 他にもsynced flushの取り込みやレスポンスのJSONのフィルタリングなど細かな改善も取り込まれています。\nFound PremiumとStandardリリース（7月） さらに進化したFound（日本語訳） Foundに弊社のサポートチームがサポートできるプレミアムが追加されました。 これにより、商用プラグインとして提供しているShieldが（現在はWatcherも）利用できるなど、 より便利になりました。また、Kibana 4も無料で提供されていたりします。\n小さなサイズのものですと、無料で試していただけるものもあるので、試してみてもらえればと。\nElasticsearch 1.7 リリース（7月） Elasticsearch 1.7.0 および 1.6.1リリース（日本語訳） 1.x系、最後のリリースでした。 小さい改善ですが、セキュリティフィックス、クラスタの安定化に寄与する機能改善が含まれています。\nこのリリース直前に大阪、京都で勉強会も開催してみました。\nElasticsearch 2.0.0-beta1 リリース（8月） Elasticsearch 2.0.0-beta1リリース（日本語訳） 待ちに待った、Lucene 5ベースのElasticsearchの登場でした。 doc_valuesがデフォルトになったり、エラーが構造化されて見やすくなったり、 Pipeline Aggregationが導入されたりしています。 また、問題点の洗い出しも兼ねて、ベータリリースとして、本リリースまでに多くのIssueをあげていただきました。\nElasticsearch 2.0.0 リリース（10月） 2.0の本リリースです。リリースまでに、beta1、2及び、rc1がリリースされました。\n追加された機能や目玉の改善については「Elasticsearch 2.0の紹介」のスライドを参考にしていただければと。\nまた、Elasticsearch 2.0のリリースに合わせて、商用プラグインやLogstash、Kibanaの新しいバージョンがリリースされました。 Kibanaなどは、プラットフォームとしての機能を備え、SenseやTimelionと言ったプラグインアプリもリリースされています。\nLogstash 2.0.0リリース（日本語訳） Kibana 4.2.0リリース（日本語訳） Senseの歴史 - Sense 2.0.0-beta1の紹介(日本語訳) Shield、Watcher、Marvel 2.0.0 GAリリース（日本語訳） Elasticsearch 2.1.0 リリース（11月） Elasticsearch 2.1.0 and 2.0.1 released Beats 1.0.0のリリース（11月） The Beats 1.0.0 Go言語で書かれた軽量データシッパーになります。 パケットをキャプチャしてElasticsearchに送るPacketbeat、 topコマンドで取れるデータなどをTopbeat、 ログファイルなどを取り込み配送するFilebeatがリリースされました。\nlibbeatと呼ばれる、 ベースとなるライブラリを元にしたプロダクトで、Logstashのエージェントのような使い方もできるようになっています。\nGo言語に興味のある方などは、調べてみてはいかがでしょう？\n来年は？ 日本では、1/7に第14回Elasticsearch勉強会を開催します。 すでに、38名のキャンセル待ちとなっていますが、おそらく、年明けにキャンセルがそこそこ出ると思うので、まだ間に合うんじゃないかなぁと。\n会社としては、Elastic{ON}16が控えています。参加される方は、ぜひ現地で声をかけてください！！\nその他にもイベント、オープンソースカンファレンス（まずは、大阪、東京）などに出没する予定ですので、こちらも参加していただければと。\nでは、また来年のAdvent Calendarでお会いしましょう！\n","date":1451017794,"dir":"post/2015/","id":"d819cea5197e9b8673d6c0b16659a5ea","lang":"ja","lastmod":1451017794,"permalink":"https://blog.johtani.info/blog/2015/12/25/about-elasticsearch-in-2015/","publishdate":"2015-12-25T13:29:54+09:00","summary":"今年最後のAdvent Calendarとなります。 この記事はElasticsearch Advent Calendar 2015の最終日のエントリです。 簡単に今年の変遷を","tags":["elasticsearch"],"title":"2015年のElasticsearch"},{"contents":"こんにちは、@johtaniです。\n早いもので、師走です。今年もあと少しとなりました（今月が一番忙しかったりしますが。。。）。 ということで、Advent Calendarの季節が始まりました。\nこの記事はElasticsearch Advent Calendar 2015の1日目のエントリです。\n今日は、最近公開されたTimelionの紹介をしたいと思います。\nTimelion? 11/12に公開されたばかりのアプリになります。（公式のブログはこちら。ブログでは動画による説明もあり）\nKibanaにプラグインとしてインストールすることで使用することができるようになるアプリです。 Timelionと書いて「Timeline」と読むようです。 Kibanaとは異なるグラフ描画のプラグインになっています。\nKibana 4.2からプラットフォーム化 Kibana 4.2から、Kibanaにプラグイン機構が導入されました。 Kibanaとしての機能以外にも、プラグインとして、アプリを追加できるようになっています。 Timelionもその一つです。\nインストール Timelionを試してみるには、ElasticsearchとKibanaが必要になります。（こちらは、すでにインストールされているとして。。。）\nKibanaのコマンドを利用して、プラグインをインストールします。\nbin/kibana plugin -i kibana/timelion インストールしたら、Kibanaにアクセスして、Timelionを呼び出します。\nTimelionへアクセス ブラウザでlocalhost:5601にアクセスすると、Kibanaが出てきます。 Kibanaのプラグイン選択のアイコンをクリックし、Timelionのアイコンをクリックします。\nすると、初期画面はこんな感じです。 直近15分のElasticsearchに入っているデータがが全部出てきます。 チュートリアルも出てきてます（初回起動時に出たはず）\nKibanaでの検索窓の部分に関数を指定していくことで、グラフが描画できるツールになっています。\nサンプル：気温データを可視化 百聞は一見に如かずということで、 気象庁のデータを使って、 ちょっとしたグラフを書いてみました。 1年間の気温の推移と日照時間になります。\n上のグラフが那覇、下グラフが札幌の気温のグラフになります。\n赤いライン：最高気温 青いライン：最低気温 黄色い棒グラフ：日照時間 最低気温と日照時間はグラフは次のような式で描画しています。\n青いラインの最低気温 気温のグラフになります。\n.es(index=\u0026#39;tenki2\u0026#39;, q=\u0026#39;city:naha\u0026#39;, metric=\u0026#39;avg:temperature_min\u0026#39;).label(\u0026#39;min\u0026#39;), .es()がelasticsearchに対するデータ取得の関数です。 引数は次のような意味になります。\nindex：対象とするインデックス名 q：検索クエリ。ここでは、cityというフィールドにnahaで検索。 metric：描画対象となっているデータの入ったフィールド。temperature_minというフィールドの1日毎の平均値を取得 最低気温と最高気温は別々のフィールドに格納してあります。最高気温の場合は（temperature_max）を指定します。\n.label(min)で、グラフの凡例の指定です。 残念ながら、日本語の指定は現時点（2015年12月01日時点）ではうまくいかなかったです。（https://github.com/elastic/timelion/issues/17）\nデフォルトでは、線グラフが選択されているので、グラフの種類は特に指定はしていません。 明確に指定する場合はlines()を指定します。\n黄色い棒グラフの日照時間 .es(index=\u0026#39;tenki2\u0026#39;, q=\u0026#39;city:naha\u0026#39;, metric=\u0026#39;avg:sunlight\u0026#39;).label(sunlight).bars() .es()に関しては最低気温のグラフとほぼ一緒です。異なるのは、metricの取得対象のフィールド名です。\n.label()で凡例を指定しています。先程と同様です。\n最後に、棒グラフにしたいため、.bars()を指定しています。\nその他に用意されている関数について知りたい場合は、Timelionのヘルプを表示すると説明が出てきます。 cusum()のような値を累積して表示するような関数も用意されています。\nまとめ Kibanaとは少し違うアプローチで時系列データを描画するためのツールとなっています。 線グラフと棒グラフを一つのグラフに描画したりもできますし、 累積のグラフなんかも描画できるようになっています。\n実験的なプロジェクトである、Timelionの紹介でした。 ここでのノウハウがkibanaにフィードバックされると色々と面白いことになるんじゃないかなと。\nということで、 明日は、zoetroさんの「Kibanaのプラグインの話」になります。 お楽しみに！\n","date":1448936891,"dir":"post/2015/","id":"1b56132638912a1ca54fcf7cd38b8e23","lang":"ja","lastmod":1448936891,"permalink":"https://blog.johtani.info/blog/2015/12/01/introduction-timelion/","publishdate":"2015-12-01T11:28:11+09:00","summary":"こんにちは、@johtaniです。 早いもので、師走です。今年もあと少しとなりました（今月が一番忙しかったりしますが。。。）。 ということで、A","tags":["kibana","timelion"],"title":"Timelionの紹介 - Elasticsearch Advent Calendar 2015 1日目"},{"contents":"第13回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 来年もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n7月同様、サムライズムの@yusukeさんに テキスト翻訳していただき、大変助かりました。\nチェックイン数など チェックインした人：100名 キャンセルしなかった人：36名 でした。 今回は当日の時点でキャンセル待ちがない状態にしていました。 雨もあって、これなかった人もいるのでしょうか。\n\u0026ldquo;Beyond the basics with Elasticsearch\u0026rdquo; / Honza Král / Elastic スライド：https://speakerdeck.com/elasticsearch/beyond-the-basics-with-elasticsearch\n参考ビデオ（別のカンファレンスで話した時のビデオ）：https://www.youtube.com/watch?v=yIixWzjTNog\nPycon HKでアジアに来ていたHonzaに、ついでに日本で話をしてもらうという企画で、 前回から1カ月足らずでの開催となりました。 Elasticsearchの基本的な検索機能とは別の機能に関して少し話をしてもらった感じです。 PercolatorとAggregationの話でした。\n詳しくはビデオやスライドを見てもらうのがいいかなと。\n\u0026ldquo;How did we use Found.no for our services?\u0026rdquo; / 株式会社アイリッジ　Takuya Noguchi さん @tn961ir スライド：未定\nFoundユーザー。1.7までの話。 社内で独自にクラスタを構築していたが、managed serviceを利用したいと思っていた。 Found用のACLがShieldに マルチバイトのインデックス名とかも使いたいが、Nginxとの連携でちょっと。。。 セキュリティ関連の話も。Securityに関する報告はこういうものも用意されてるので、こちらに相談してもらうのがいいかも。https://www.elastic.co/community/security 要望がいくつか。 \u0026ldquo;ログ収集の仕組みを再考しよう！　あとマウンテンビューに行ってきました。\u0026rdquo; / Acroquest Technology株式会社 谷本 心さん @cero_t スライド：http://www.slideshare.net/shintanimoto/lets-reconsider-about-collecting-logs-plus-visiting-elasticmoutain-view\nログの小話から始まり、ログに関する考え方とかを披露してもらいました。 さらに踏み込んだログの活用の方法の話になるかと思いきや、 思いっきり話が飛んで、マウンテンビューのElasticオフィスに遊びに行った写真が出てきましたw\n写真の後は、弊社のTanya（来月のElastic{ON} Tour Tokyoで来日予定）から 聞いた弊社製品に関する話をしていただきました。 きっと、Beatsに関して次は話してくれるんだろうなぁ（棒）。 流れ的には、来年の2月にサンフランシスコで開催されるElastic{ON}16につながりそうだったので、ここで宣伝しときますね。 今年3月に開催されたイベントには残念ながら日本の方はいなかったので、次回は日本の方がいると嬉しいなぁと。\nLT \u0026ldquo;「Elasticsearch を使った単語共起頻度の計算」\u0026rdquo; / 株式会社はてな　id:takuya-a さん スライド：未定\n一風変わったElasticsearchの使い方的な話でした。 検索用にデータを登録してあるElasticsearchから単語の頻度情報を抜き出して、 別のインデックスに登録するという感じでしょうか。 こういうのが、実は、Elasticsearchに機能としてあると便利だったりするのかもなぁと思ってみたり。\nLTよりはちょっと長かったですかねw\nその他、感想などのブログ elasticsearch勉強会 まとめ＋宣伝 今回も@yusukeさんのテキスト翻訳に助けていただきました。ほんとありがとうございます。 今年の勉強会はこれがラストになります。 来月は、トレーニングとElastic{ON} Tour Tokyoがあるので忙しくなりそうですが、 参加予定の方は楽しみにしていてください！\nOperations : http://training.elastic.co/class/Operations/Japan/Dec Developer : http://training.elastic.co/class/Developer/Japan/Dec ","date":1447143778,"dir":"post/2015/","id":"2ea86ae5093670df1d4502ea82efa1ac","lang":"ja","lastmod":1447143778,"permalink":"https://blog.johtani.info/blog/2015/11/10/13th-elasticsearch-jp/","publishdate":"2015-11-10T17:22:58+09:00","summary":"第13回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第13回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：The Story of Sense - Announcing Sense 2.0.0-beta1\n誕生 よくある良いプロジェクト同様、Senseもビールを飲みながら考えつきました。 Amstelでの手漕ぎボートのセッションの後で。 友人のJasperと私はJasperの会社で毎年行われる ハッカソンについて話をしていました。 このハッカソンはどのようなアイデアでどんなチームで行うかを聞き取りされる、厳密なハッカソンです。 その時、私とJasperはChromeブラウザに別のヒストリーを表示するという作業をやるとAnne Velingに話をしていました。\nJasperと私はElasticsearchのユーザでしたが、リッチなREST APIにリクエストを送信するための 便利なツールがないと知っていました。 恥ずべきことに、cURLコマンドを利用するターミナルがその時の一番良いツールでした。 皆さん、ターミナルでボディつきのリクエストをサブミットするのがどのくらい不便かというのをわかるために、 5秒ほどターミナルで実行してみてください。 タイプミスのような単純なことでさえ、すべてのコマンドを再タイプしなければならなかったり、 複数行サポートのターミナルと戦ったりです。 ウェブベースのJSONエディタを見つけ出して、それをベースにすることが必要でした。\n終わりなきウィークエンド リサーチをして、Anneに電話しました。 私は彼に、History Pageのプロジェクトにもコミットするが、 Elasticsearchユーザなので、便利なコンソールを開発する時間も欲しいという話をしました。 私たちは、Aceオンラインエディタを利用して、 自動でAPIを認識するナレッジベースを構築し、 コンテキストに沿ったサジェストを大なうようにしました。 Anneはすぐに、それが素晴らしいと同意してくれました。 しかし、彼は、ハッカソンの基本的なルール（週末にそれが終わる必要がある）に違反しているので、 そのアイデアを却下するしかありませんでした。 確かに、私たちが提案していたものは行えませんでした。 最後に、私たちは、ChromeのHistory Pageの素晴らしい置き換えについて実装しました。\nそれでも、私はチャレンジし、それが終わるであろうことを終わるであろうことを証明しなければなりませんでした。 次の週末（といくつかの終業後 :)）に、私はそれを作りました。 Senseの誕生です。 それは、まだバグだらけでしたが、動きました。 これを見せるとみんな興奮しました。\n初期 Knowledge Baseの拡張とバグのフィックスで数日を過ごしました。 Senseは広まり始め、ずっと古いバグのあるバージョンを利用しないといけないのかと私は恐れました。 SenseをChromeのExtentionとしてリリースすることを決め、リリースすると自動的に更新されるようにしました。 History Panelのような機能を一つづつ追加するようにしました。\nElasticにジョインしてから、会社の人たちがSenseを使用しているということを聞き、とても幸せでした。 特に、Clintと話をしたときのことを覚えています。 彼は、\u0026ldquo;You know what Sense should do? It should use this format and allow you to have multiple requests in the editor\u0026rdquo; 「Senseになにをすべきかわかる？フォーマットを使うべきだし、エディタで複数のリクエストを持つようにするべきだ」 と言いました。 もちろん、その他のチャレンジも行いました。これは、簡単なものではなく、Aceの詳細を知る必要がありました。 それは新しいAceモード（Aceによって利用されているハイライティングロジック）です。 これは、Senseのサジェストエンジンに密に統合されました。\n次のものが古いSenseのスクリーンショットです。\n画像あり。Figure 1. Sense 0.7 ※画像に関しては原文をご覧ください。\nAPIのURLを入力すると、JSONのボディが入力されます。 うまく切り離すことができ、AceのスタンダードJSONモードを使っていました。 しかし、ここで、次のようなフォーマットをどうやってサポートするか考える必要がありました。\nGET _cluster/health POST index/_settings { \u0026#34;index\u0026#34;: { \u0026#34;number_of_replicas\u0026#34;: 3 } } これは、Aceが3つの異なるものをどうやってパースするかを知る必要があるということです。 HTTPメソッドとURLとJSONボディです。 また、困ったことに、前に説明した前に説明した通り、明らかに別々にはならないものでした。 JSONボディが完全であることを知る唯一の方法はかっこを数えることです。 それは、いくつかの作業とAceのカスタマイズが必要でしたが、それらを切り離すことができました。 そして、Senseのシンタックスが生まれたのです（Thanks Clint!）\nMarvel時代 就業時間中、私の優先すべき仕事はMarvelの開発になりました。 これは、Elasticsearchのための管理と監視のためのソリューションです。 （side note: Marvelは生まれ変わっています。（\u0026quot;Shield, Watcher, and Marvel 2.0.0 GA Released\u0026quot;）） Marvelは開発環境ではフリーなので、MarvelにSenseを組み込むことにしました。 これにより、Senseの開発が日中も行えるようになり、多くのユーザに利用され始めました。 また、Senseは実際に真のJavaScript開発者によって開発されました。 彼は、コードをクリーンにし、ブラウザにおける最新の技術を私に教えてくれました。\nこの期間のSenseは数回書き換えられています。 最も顕著なものは、個別のURLとJSONのサジェストエンジンを書き換えて、 1つのサジェストエンジンにしこれらのコンテキストで動作するようにし、さらに3つ目のコンテキスト（URLパラメータ）を追加したことです。\n新しいエンジンはまた、複数のサジェストコンテキストをメンテナンスするのが簡単になりました。 例えば、_search APIのソートパラメータを考えます。\nGET _search { \u0026#34;sort\u0026#34;: [ \u0026#34;timestamp\u0026#34;: \u0026#34;desc\u0026#34;, \u0026#34;price\u0026#34;: { \u0026#34;order\u0026#34;: \u0026#34;desc\u0026#34;. \u0026#34;missing\u0026#34;: \u0026#34;last\u0026#34; }, \u0026#34;nested_filter\u0026#34;: { \u0026#34;term\u0026#34;: { ... }}, \u0026#34;_score\u0026#34; ] } ユーザがどこにいるかによって、Senseは単純な値（_scoreのような）か、 複雑な構造（orderとmissingのような）やフィルタ（nested_filterのような）も サジェストする必要があります。 これらのサジェストのパスが一度に処理され、無関係なものは除外されます。\nSense 2.0の紹介！ Marvel 1.xはKibana 3.0をベースにしていました。 これは、データの探索やダッシュボードツールとして素晴らしいものでした。 しかし、Kibanaチームはさらに素晴らしいものを出しました。 Kibana 4.xはElasticsearchをバックエンドとするUIアプリを簡単に構築することができる プラットフォームとして設計されています。 実際に、Marvel 2.0はKibanaの プラットフォームで利用できる最初のアプリです。\nSenseの話に戻します。 ElasticsearchのAPIとやりとりする一般的なコンソールです。 これをKibanaのアプリぴったりだと気付きました。 ということで、Sense 2.0をKibanaアプリとしてオープンソースで公開しました。 開発及び本番環境で利用してください。\nFigure 2. Screenshot Sense 2.0 ※画像に関しては原文をご覧ください。\nリリースのハイライト Sense 2.0の新しい機能をここで簡単に紹介します。 （すべての変更点についてはこちらをご覧ください。）\nElasticsearch 2.0 SenseのナレッジベースをElasticsearch 2.0サポートに更新しました。 新しいPipeline aggregationにも対応しています。\n複数リクエストの実行 テストやいくつかの一連のコマンドを繰り返し実行したい時があるでしょう。 その時に、それら全てをSenseに記述し、 実行したいリクエストを選択状態にしてElasticsearchにリクエストできます。\nFigure 3. Submit multiple requests ※画像に関しては原文をご覧ください。\nSenseは、Elasticsearchにリクエストを一つずつ送信し、それぞれの出力結果を右のパネルに表示します。 これは、問題のデバッグや複数のシナリオでのクエリの組み合わせの実行に非常に便利です。\n複数リクエストのコピーペースト 複数リクストを選択し、フォーマットしたり、cURLのコマンドとしてコピーすることも可能です。\nFigure 4. Copy multiple requests as cURL ※画像に関しては原文をご覧ください。\n# Delete all data in the `website` index curl -XDELETE \u0026#34;http://localhost:9200/website\u0026#34; # Create a document with ID 123 curl -XPUT \u0026#34;http://localhost:9200/website/blog/123\u0026#34; -d\u0026#39; { \u0026#34;title\u0026#34;: \u0026#34;My first blog entry\u0026#34;, \u0026#34;text\u0026#34;: \u0026#34;Just trying this out...\u0026#34;, \u0026#34;date\u0026#34;: \u0026#34;2014/01/01\u0026#34; }\u0026#39; もちろん、複数のcURLコマンドをコピーしてSenseにペースとすると、Senseはそれらをパースしてくれます。\nまとめ Sense 2.0.0のベータリリースです。 実際に多くの作業が終わった認識です。すぐにGAが出るでしょう。\nSense 2.0を知り、試していただくために、新しいドキュメントを参考にしてください。 バグやリクエストがある場合は、フォーラムやGitHubのIssueに登録をお願いします。\n","date":1446195306,"dir":"post/2015/","id":"5912529cfd6ce14c5ede5c6c83dae7e8","lang":"ja","lastmod":1446195306,"permalink":"https://blog.johtani.info/blog/2015/10/30/sense-2-0-0-beta1-ja/","publishdate":"2015-10-30T17:55:06+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：The Story of Sense - Announcing Sense 2.0.0-beta1 誕生 よくある良いプロジェクト同様、Senseもビールを飲みながら考","tags":["elasticsearch","sense"],"title":"Senseの歴史 - Sense 2.0.0-beta1の紹介(日本語訳)"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Shield, Watcher, and Marvel 2.0.0 GA Released\n本日（10/28）Shield、WatcherおよびMarvel 2.0をリリースしました。 これが、Elasticsearch 2.0に対応したこれらのプラグインの最初のリリースです。\nElasticsearch 2.0対応のほかに、ShieldとWatcher 2.0は、 セキュリティとアラートを拡張するいくつかの新しい素敵な機能も備えています。\nShield 拡張可能なレルム - Sheild 1.xはユーザ認証のコア的なものを定義するのにフォーカスし 3つの認証メカニズム（esusers、LDAP/AD、PKI）を提供しました。 これらを提供することで、多くのユーザおよびユースケースをカバー出来ましたが、 追加の認証メカニズムを統合する必要があることもわかっていました。 ということで、Shieldのレルムベースの認証システムをユーザが利用、拡張できるようにオープンにし、 ユーザ認証を扱うためのレルム実装をプラグインとして拡張できるようにしました。 特定もしくはプロプライエタリな認証メカニズムが必要なユーザもShieldの強力な セキュリティ機能（ロールベースの認証、セキュアな通信など）をフルに活用できるようになりました。 カスタムレルムの詳細については、こちらをご覧ください。\nフィールドとドキュメントのACL - Shield 2.0はフィールドとドキュメントレベルのアクセス制御機能を提供します。 これは、ロールごとにアクセス可能なフィールドやドキュメントを定義できます。 この新しい機能は、設定の変更するよりも便利です。 このアクセス制御はElasticsearchのLuceneインデックスという最も低レベルで実装されています。 その結果として、このメンテナンスがより簡単であるだけでなく、より良くなっています。 詳細についてはこちらをご覧ください。\nユーザなりすまし - Shield 2.0で、ユーザなりすましの機能が実装されました。 これは、ユーザ（適切なパーミッションを持った）が、他のユーザになることができ、 それらのユーザのためにリクエストを実行できます。 これは、Elasticsearch上に構築されたアプリケーションがすでにユーザ認証を行いますが、 認可はElasticsearchサイドで行う必要があるような場合に有用です。 このシナリオで、アプリケーションの\u0026quot;main\u0026quot;ユーザを設定でき、正しくなりすましを割り当て、 ElasticsearchにアプリケーションユーザとしてリクエストをElasticsearchに実行させることができます。 詳細については、こちらをご覧ください。\nWatcher SlackとHipChatインテグレーション - SlackとHipChatはチーム/グループコラボレーションツールです。 これらは、急速に主流になり、組織の主な内部コミュニケーションハブとなっています。 Watcher 2.0はチャンネル/ルームやユーザにこれらのコミュニケーションチャネル経由で、Watchの通知を行うことができるアクションを 実装しました。 slackやhipchatアクションについてはドキュメントをご覧ください。\nArray Compare Condition - 新しいconditionはタイムシリーズのデータのスパイクを検知するのを簡単にします。 compare conditionは1.xで導入されましたが、このコンディションはElasticsearchのダイナミックスクリプト機能を有効にする必要がアンク使えます。 詳細についてはarray_compare conditionをご覧ください。\nWatchの有効・無効化 - ユーザからの多かったリクエストとして、Watchの無効化がありました。 1.xには、登録済みのWatchを無効にする機能がありませんでした。 これは、Watchを消すか、Watchのトリガーを変更することで回避していました。 これは、全体としてはWatchを管理するのを難しくする回避方法でしかありません。 2.0では、APIを呼び出すだけで、Watchの変更をすることなく、簡単にWatchの有効化・無効化が可能になりました。 これは1.0からあるべき基本的な機能でしたが、ついにこの問題を解決しました。 詳細はこちらをご覧ください。\nMarvel Marvel 2.0を紹介するのに興奮しています。 Kibana 4をベースとした、再設計されたUIを持っています。 Marvel 1.xで学んだ多くのことを導入し、より使いやすく監視しやすいUIになっています。 ShieldとWatcherと同様に、最初のMarvelのリリースは将来的な成長の基盤となり Elasticsearch2.0を効率的に管理するための主要なメトリックにフォーカスしています。\n画像あり。 ※画像に関しては原文をご覧ください。\n再設計により、インタフェースを6ページに減らしています。\nCluster list 画像あり。 ※画像に関しては原文をご覧ください。\nユーザやカスタマーの多くは複数のクラスタを利用しています。 新しいMarvelはそれらを集中的にモニタリングする一つのクラスタからそれらを簡単に監視できます。 各クラスタのデータ送信先をこのモニタリングクラスタにするだけです。\nCluster Overview 画像あり。 ※画像に関しては原文をご覧ください。\nクラスタオーバービューはある一つのクラスタの主要な性能メトリックを見ることができ、 素早くスパイクを発見できます。 このページはまた、アクティブなシャードのリカバリやリロケーションも見ることができます。\nIndices List 画像あり。 ※画像に関しては原文をご覧ください。\nインデックスのリストにはクラスタにあるすべてのインデックスとその属性が表示されます。 テーブルはライブでアップデートされ、フィルタリングやソートも可能です。 一番大きなインデックスは？といったことも調べられます。\nIndex Detail 画像あり。 ※画像に関しては原文をご覧ください。\nインデックス詳細ページはインデックスの主な性能メトリックを見ることができ、シャードの配置についても表示します。\nNodes List 画像あり。 ※画像に関しては原文をご覧ください。\nノードリストはクラスタにあるノードとその主な性能メトリックを見ることができます。 テーブルはライブでアップデートされ、フィルタリングも可能です。 高いCPU利用率やディスクの残り容量なども簡単にわかるようになっています。\nNode Detail 画像あり。 ※画像に関しては原文をご覧ください。\nノード詳細ページは個別のノードに関する主な性能メトリックを見ることができ、ノードにあるシャードのリストも見ることができます。\n新しいMarvelはKibana 4の上に構築されたので、管理方法が変わっています。 Marvelのインストールは2つのステップがあります。 marvel-agentとmarvel user interfaceです。\nMarvel Agent marvel-agentはElasticsearchクラスタにプラグインとしてインストールします。 主なパフォーマンス情報を取得し、ローカルもしくは分離されたモニタリングクラスタにデータを保存・送信します。\nMarvel User Interface Marvel UIはKibanaのプラグインとしてインストールします。 これは、Kibana 4.2の新しいプラグインインフラを利用し、 Marvel Appとして、Kibanaのインタフェースとは個別に提供されます。 Kibanaのアプリの切り替えは次の画像の通りです。\n画像あり。 ※画像に関しては原文をご覧ください。\n2.0リリースは私たちのプロダクトの大きな一歩です。またユーザの意見を常にお待ちしています。 ぜひ、Webフォーラム（https://discuss.elastic.co）やメール（info@elastic.co）でご意見を。\n","date":1446189691,"dir":"post/2015/","id":"15700442e957951307bbcec5fff8643d","lang":"ja","lastmod":1446189691,"permalink":"https://blog.johtani.info/blog/2015/10/30/shield-watcher-and-marvel-2-0-ga-released-ja/","publishdate":"2015-10-30T16:21:31+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Shield, Watcher, and Marvel 2.0.0 GA Released 本日（10/28）Shield、WatcherおよびMarv","tags":["elasticsearch","shield","watcher","marvel"],"title":"Shield、Watcher、Marvel 2.0.0 GAリリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 2.0.0 GA released\nElasticsearch 1.0.0のリリース以降、 477のコミッター2,799のpull requestがあった、 **Elasticsearch 2.0.0 GA（Lucene 5.2.1ベース）**をリリースしました。\nそれだけでなく、Shield（セキュリティプラグイン）とWatcher（アラーティングプラグイン）、 新しくなったMarvel（モニタリングプラグイン）（プロダクション環境でフリー！）、 また、新しくオープンソースとなったSense editorの2.0.0もリリースしました。\nElasticsearch 2.0.0のダウンロードはこちらから。 また、2.0.0での重要な変更点についてはこちらをご覧ください。 全ての変更点については、次をご覧ください。\nChanges list for Elasticsearch 2.0.0 Changes list for Elasticsearch 2.0.0-rc1 Changes list for Elasticsearch 2.0.0-beta2 Changes list for Elasticsearch 2.0.0-beta1 商用プラグインについてはこちらです。\nShield 2.0.0 change logs Watcher 2.0.0 change logs Elasticsearchの新機能 Elasticsearch 2.0.0には素晴らしい新機能があります。\nPipeline Aggregations Aggregationsで導関数や移動平均のような他のAggregationの結果に対する計算が可能となります。 この機能はクライアントサイドで実装しなければなりませんでしたが、 Elasticsearchに計算させることで、より強力な解析のクエリを簡単に組み立て、クライアントのコードを簡略化できます。 これは、予測解析や予測解析や例外検知といった可能性をもたらします。 Pipeline Aggregationについては次をご覧ください。\nOut of this world aggregations. Staying in Control with Moving Averages - Part 1. Staying in Control with Moving Averages - Part 2. Query/Filter merging フィルタはもうありません。 全てのフィルタ条件はクエリとなりました。 クエリコンテキストで使用した場合、関連度のスコアに影響し、フィルタコンテキストで使用した場合、 これまでのフィルタのように、ヒットしなかったドキュメントを除外するだけとなります。 この変更はクエリの実行時に自動的に最も効率的な順序で実行するように最適化されることを意味します。 例えば、遅いクエリ（フレーズやgeo）の最初の実行は速い近似フェーズで実行され、 それから、遅い正確なフェーズで結果を修正します。 フィルタコンテキストでは、直近でよく使われた条件が自動的にキャッシュされます。 詳細については、\u0026quot;Better query execution coming to Elasticsearch 2.0\u0026ldquo;をご覧ください。\n設定可能な圧縮率 _sourceのようなStored fieldsは高速なLZ4（デフォルト）で圧縮するか、インデックスサイズを小さくできるDEFLATE で圧縮できます。 これは、特にロギングのケースで便利です。 古いインデックスをオプティマイズする前にbest_compressionに変更することができます。 詳細については\u0026rdquo;Store compression in Lucene and Elasticsearch\u0026ldquo;をご覧ください。\n堅牢に 新しいElasticsearchはJava Security Managerの元で実行されます。 これは、セキュリティの観点で大きな前進です。 Seciruty ManagerはElastcsearchにより制限をかけ、ハッカーによりシステムに対して何でもできるようなものを制限します。 Elasticsearchはまた、インデキシングの観点でも堅牢になっています。\nドキュメントはインデキシングリクエストに答える前に、耐久性のためにディスクにfsyncされます。 すべてのファイルはチェックサムにより、早期に障害を検知します。 すべてのファイルはどんなファイルへの書き込みもアトミックです 最後に、システム管理者から要請の多かった変更として、 設定されて居ないノードがパブリックなネットワークから参加しないようになりました。 Elasticsearchはデフォルトではローカルホストのみにバインドします。マルチキャストは無くなりました。（プラグインとして残っています。）\nパフォーマンスと信頼性 上記以外にも細かな修正がElasticsearchとLuceneにはあります。 より安定し、信頼性をあげ、簡単に設定できるようにするものです。例えば、次のようなものです。\nヒープの使用率の低減（doc valuesがデフォルト、マージ時のメモリ使用率の削減、 roaring bitsetsによるフィルタキャッシュ） 構造化され読みやすくなった例外 設定の代わりに、フィードバックループを使用した自動調整 安全で明確で信頼性のあるタイプマッピングの大きな修正 クラスタ状態の差分変更による伝搬の高速化および、大きなクラスタでのより安定的に normsの圧縮の改善。これまではヒープスペースを大きく利用していた。 マージの自動的な調整（不可解な設定の微調整が必要ない） より詳細なLuceneのメモリリポート 最適化されたクエリ実行を活用するためにParent/childを書き換え コアプラグイン 公式にサポートされたコアプラグインはElasticsearchと同じバージョン番号で同じタイミングでリリースされます。 インストールするプラグインとElasticsearchの複雑なバージョンの対応表に悩まされる必要はもうありません。 コアプラグインのインストールは次のように簡略化されています。\nbin/plugin install analysis-icu ShieldとWatcherの新機能 商用プラグインも新しい機能をリリースしました。\nShield フィールドおよびドキュメントレベルのアクセス制御 ユーザのなりすまし カスタム拡張可能な認証レルム Watcher 個別のWatchを有効/無効に SlackやHipChatへの通知 これらの詳細については“Shield, Watcher, and Marvel 2.0.0 GA Released”をご覧ください。\nコアプラグイン同様、商用プラグインもElasticsearchのバージョンと同じものが同時にリリースされます。 インストールは次の通りです。\nbin/plugin install license bin/plugin install shield bin/plugin install watcher Marvel 2.0.0はプロダクションでの利用もフリーに Marvelモニタリングプラグインはカスタマに非常に価値のあるもので、 ユーザの発展とともに問題を診断したり見つけたりするのに役に立ってきました。 私たちは、何を改善でき、Mαrvelを一から書き直すことで、いろいろとわかったことがあります。\nMarvel UIを新しいKibanaプラットフォーム上に構築 ダッシュボードにはより簡単に問題を発見するために、最も重要なメトリックを可視化 1つのインストールで、複数のクラスタのモニタリングをサポート（商用サポート対象） 一番良い点はMarvelがすべてのElasticsearchユーザに対してプロダクション環境でフリーになったことです！ ライセンスが必要ですが、課金の必要はありません。 もし、マルチクラスタモニタリングサポートが必要な場合、それは商用サポート対象となります。\n詳細に関しては“Shield, Watcher, and Marvel 2.0.0 GA Released”をご覧ください。\nSense editorがオープンソースに Sense（ブラウザベースのElasticsearchリクエストとDSL向けのエディタ）を Kibanaプラットフォームのアプリとして、オープンソースにしました。 また、このリリースで新しい機能が追加されています。\n複数のcURLリクエストをペースとすると、Sense表記に変更 複数のSenseリクエストをcURL表記にしてコピー 複数のリクエストを一度に実行可能 Elasticsearch 2.0サポートとなった自動補完機能 SenseはKibanaのアプリとして次のようにインストールします。\n./bin/kibana plugin --install elastic/sense Senseの詳細については、\u0026quot;The Story of Sense - Announcing Sense 2.0.0-beta1\u0026ldquo;をご覧ください。\nElasticsearch Migration Plugin Elasticsearch Migration PluginはElasticsearch 1.xから2.0にアップグレードする時の良い出発点となります。 1.xのElasticsearchクラスタにサイトプラグインとしてインストールすると、 アップグレードする前に解決すべき問題があるかどうかを検知してくれます。 （例えば、Lucene 3のような古いインデックスや、2.0.0にした場合に動作しない問題のある マッピング（The Great Mapping Refactoring）のような問題）\nプラグインに関してElasticsearch Migration repositoryをご覧ください。\nまとめ ぜひ、Elasticsearch 2.0.0をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)やWebフォーラムなどで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1446103243,"dir":"post/2015/","id":"018e32a8010960eb17e368a6fdd5a51b","lang":"ja","lastmod":1446103243,"permalink":"https://blog.johtani.info/blog/2015/10/29/elasticsearch-2-0-0-released-ja/","publishdate":"2015-10-29T16:20:43+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0 GA released Elasticsearch 1.0.0のリリース以降、 477のコミッター2,79","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0リリース(日本語訳)"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Kibana 4.2.0 released\nElasticsearch 2.0 + Kibana 4.2 = 💚 Elasticsearch 2.0サポートのKibanaの最初のリリースです。 これが何を意味するでしょう？ 速さ、安定さ、新しい機能。 試してみたい方は、いますぐダウンロードしてください。 そうでない方は、Kibana 4.2の楽しい機能について読んでみてください。\n暗黒面は怖い？ そんなことありません。 私たちは常にチャートチャートとダッシュボードを組み立てている組み立てている間は明るいバックグラウンドを使うことを推奨してきましたが、 時々、巨大なスクリーンで暗い部屋で誰も明るい画面から目を背けないようにしたいでしょう。 その影響を小さくするためにダークモードを導入しました。 あなたは、NOCや天文台、その他の暗い場所でKibanaのダッシュボードを楽しむことができます。\n画像あり。 ※画像に関しては原文をご覧ください。\n地図のカスタマイズ Kibanaの地図は素晴らしいですが、もっと多くのオプションが望まれていると聞きました。 もし地図に関して知識があるなら、Kibana 4.2のWMSバックグラウンド地図サポートを試してみてください。 WMSは非常に強力で、US Geological Surveyを含む多くの無料サービスがあります。 http://viewer.nationalmap.gov/example/services/serviceList.html\n画像あり。 ※画像に関しては原文をご覧ください。\nシナリオは？ 何かおかしい時、何が起こっているかを正しく知ってもらいたいので、Kibanaがそのタイミングで注目したいコンポーネントがあるなら、 どのように動いているかという概要を知るためのサーバステータスページを作りました。 もちろん、全てがOKであるというのを知りたいだけの場合でも、settingメニューのStatusタブからいつでも呼び出せます。\n画像あり。 ※画像に関しては原文をご覧ください。\n全てにおいて速く ブラウザリフレッシュはKibana 4.2の新しいコードビルディングシステムのおかげで、さらに早くなりました。 また、メモリを覚えてます？Pepperidge FarmKibanaが覚えています。 Kibana 4.2は小さな小さな小さなメモリフットプリントを管理している間、長い長い長い時間実行されているダッシュボードを見ることができるような 大きなメモリのクリーンアップも含んでいます。\nもっとありますが。。。 小さな微調整がいくつもあります。また、今後紹介する本当に刺激的なものの基礎を気づき上げてきました。 これからもElasticのブログ、Twitter、KibanaのGitHubリポジトリに注目し、モンスタートラックアナリティクスの瞬間に立ち会ってください。\n","date":1446103219,"dir":"post/2015/","id":"e159a35d1b9a46e03072a3d54780edcb","lang":"ja","lastmod":1446103219,"permalink":"https://blog.johtani.info/blog/2015/10/29/kibana-4-2-0-ja/","publishdate":"2015-10-29T16:20:19+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Kibana 4.2.0 released Elasticsearch 2.0 + Kibana 4.2 = 💚 Elasticsearch 2.0サポートのKibanaの最初のリリースです。 これ","tags":["elastic","kibana"],"title":"Kibana 4.2.0リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Logstash 2.0.0 released\nLogstash 2.0.0が本日（10/28）リリースされました。 このリリースは いくつかの設定に関する重要な変更があります。 詳細については、changelogまたは、新しいbreaking changesドキュメントをご覧下さい。\nこれまでの2.0.0直前のリリースに関する変更点はこちらをご覧ください。\nbeta1 beta2 beta3 RC ここでは、2.0の主な変更点の概要を説明します。\nElasticsearch 2.0との互換性 多くの機能および改善を含んだElasticsearch 2.0がリリースされました。 Logstash 2.0はこのリリースに対応しています。 Logstashのこれまでのリリースでは、デフォルトで、Javaの node clientをElasticsearchとの通信として 使用してきました。 2.0では、HTTPクライアントがデフォルトになります。 これにより、シームレスにユーザのデータを取り込み、付加価値をつけ、Elasticsearchに保存して解析することができます。\nHTTPは他のプロトコル（nodeやtransport）同等の機能を持っていますが、 単一のクライアントに接続する時に、少しだけ遅いですが、管理や動作がより簡単です。 HTTPプロトコルを使うことで、Elasticsearchのバージョンのアップグレードが、Logstashのアップグレードすることなく 行うことができます。 デフォルトをHTTPに変更したさらに詳しい情報についてはbeta1のブログをご覧ください。\n他のプロトコル（nodeとtransport）もサポートしますが、これらを利用する場合には、 プラグインを別途インストールする必要があります。\nbin/plugin install --version 2.0.0 logstash-output-elasticsearch_java 互換性のマトリックス LogstashとElasticsearchのバージョンの互換性は次のようになります。\n画像あり。 ※画像に関しては原文をご覧ください。 #Image https://www.elastic.co/assets/bltde5b69e2164aa82f%2Fcompat_matrix.png\nShield 2.0との互換性 このリリースはShield 2.0リリースにも対応しています。 HTTPプロトコルで、追加のプラグインは必要ありません。 こちらのドキュメントをご覧ください。 transportプロトコルでは、Shield 2.0対応のプラグインを個別にインストールする必要があります。\nbin/plugin install --version 2.0.0 logstash-output-elasticsearch_java_shield パフォーマンスの改善 このリリースはまた、多くの部分のパフォーマンスの改善を含んでおり、Logstashを利用してデータをより早く処理することができます。 いくつかをここで説明します。\nUserAgentとGeoIPフィルタ：これらのフィルタで、LRUキャッシュを追加して改善しています。 これにより、IPとユーザエージェントがまとまって現れるというWebリクエストの特性を用いています。 ユーザエージェントフィルタのケースでは、サンプルデータセットにおいて3.7倍ほど早くなりました。 GeoIPでは、1.69倍早くなっています。\nJSONプロセシング：LogstashでJSONのsiriaraizu/でシリアライズに利用しているJrJacksonを新しいバージョンにしました。 これにより、JSONの処理が改善されています。\nフィルタワーカーのより良い値をデフォルトに：以前のリリースでは、filter_workersの設定は1がデフォルトでした。 これは、フィルタの処理を行うワーカーが1つであるという意味です。 filter_workersの設定のデフォルト値はCPUコア数の半分の値を設定します。フィルタ実行の並列性が上がります。 ですので、複雑なgrokパターンやuseragentフィルタの処理がにとっては重要です。\nFilebeat Support Filebeatのベータバージョンを先日リリースしました。 これは、Logstash Forwarderの次期バージョンです。 Filebeatはファイルベースのログをさらに処理するためにLogstashに送るためのエージェントです。 2.0.0はlogstash-input-beatsプラグインを使えばFilebeat 1.0.0-beta4とすぐに動作します。\nシャットダウン操作 これまでのLogstashでは、シャットダウンが開始した時に、例外の機構でシャットダウンが開始したことを プラグインに通知していました。 この処理はサードパーティのコードを使ったプラグインで問題を起こしていました。 Logstashはどの例外を処理するか知らないため、予期しない動作をしていました。 これを修正するためにAPI呼び出し（例えばstop）を各プラグインにシャットダウンのイベントを通知し、 プラグイン自身がきちんと停止するようにしました。 これは、200以上のプラグインに新しいAPIを利用するように修正しないといけないことを意味しました。 しかし、Logstashの停止についてはまだ完全にはフィックスしていません。 とちゅうでおわっているoutputがシャットダウンを遅らせる可能性があるからです。 2.0でAPIの破壊的な変更は適切なリリースでの変更を繰り返すことができる出発点です。\nプラグインの開発者へ：もし、Logstash　1.5のプラグインを開発しているなら、 シャットダウンに関する新しいAPIのリストに関するbreaking changesのドキュメントに助言をください。 また、example inputリポジトリにて、新しいシャットダウンメカニズムの使い方のサンプルコードを提供しています。\nドキュメント 2.0に更新されたドキュメントはこちらです。設定の変更についてもこちらをご覧ください。\n2.0へのアップデート 2.0へアップデートする前に、アップデートガイドもご覧ください。\nフィードバック 2.0のリリースできたことに、多くのコントリビューター、ユーザに感謝しています。 このリリースに含まれている多くのパッチと全てのプレリリースのテストにも感謝しています。 将来の修正やリリースなどについてはロードマップをご覧ください。 2.0は今日リリースされました。 ご意見ご感想はWebフォーラムで！\n","date":1446103197,"dir":"post/2015/","id":"cc64c2fcdecdb505b3797e1aaaa59adc","lang":"ja","lastmod":1446103197,"permalink":"https://blog.johtani.info/blog/2015/10/29/logstash-2-0-0-released-ja/","publishdate":"2015-10-29T16:19:57+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Logstash 2.0.0 released Logstash 2.0.0が本日（10/28）リリースされました。 このリリースは","tags":["elastic","logstash"],"title":"Logstash 2.0.0リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Relase, we have ※画像に関しては原文をご覧ください。\nElasticにとって大きな1日（社内では「release bonanza」と呼んでいる）です。 多くの主要なプロダクトを新たにリリースしました。 そして、本日、それらを一緒に利用する時にそれらを一緒に利用する時にユーザの体験についてまとめてみました。\n次の通りです。\nElasticsearch 2.0リリース。 大きなマイルストーン、チームによる改善、そして、コミュニティからの素晴らしい貢献。 Pipeline Aggsと呼ばれる新しいタイプのaggregations、 クエリとフィルタのコンセプトを統合することにより簡素化されたクエリDSL、 better compressionオプション、 JavaのSecurity Managerを有効にすることによる強化されたセキュリティ、 FSの挙動に関する強化（fsync、checksum、atmicなリネーム）、 パフォーマンス、マッピングの挙動の一貫性などなどです。 また、我々のチームによる改善も含まれているLucene 5ベースにアップグレードしています。\nKibana 4.2リリース。 Elasticsearch 2.0対応、ダークテーマ、カスタマイズ可能な地図、多くの改善。 Kibana 4.2の多くに作業については外部プラグインサポートといった、内蔵に関するものでした。 この後の説明に続きます。\nMarvel 2.0リリース。 Elasticsearch 2.0対応、合理化されたメトリックス、簡素化されたUI、 多くはKibanaプラグイン（Kibanaプラットフォーム上に構築）としての書き換えです。 このKibana拡張の最初の努力は、Kibanaのプラグインをどうやって書くか、 Kibanaユーザに公式に何をする必要があるかといったものを特定するのに役立ちました。 おっと、忘れるところでした、Marvelを全てのユーザにフリーで使えるようにしました。 マルチクラスタサポートについては有償となります。\nSense 2.0リリース。 2つ目のKibanaプラグインがこれです。 SenseをKibanaプラグインとして書き換えました。 Elasticsearch 2.0サポート、複数リクエストの実行、 curlへのコピーなどです。 おっと、忘れるところでした。オープンソースとすることにしました！\nShield + Watcher 2.0リリース。ElasticsearchのためのセキュリティプラグインであるShieldと、アラート管理のためのプラグインであるWatcherにも 多くの結果が入っています。 最も要求のあった機能である、フィールドお呼びドキュメントレベルでのセキュリティについて、Luceneに落とし込んで実装しました。 また、セキュリティの操作についてプラガブルに実装できるように変更しました。 Watcherは監視の無効化、SlackやHipChatへの通知（bot ops向け）が可能です。\nLogstash 2.0リリース。 Elasticsearch 2.0のサポート、クリーンな停止、全面的なパフォーマンス改善、Beatsサポート。\nご覧の通り、すべてのプロダクトに関する大きな結果です。 チーム間およびFoundの開発者との間での密な連携に感謝します。 これらが私たちが公式にElasticsearch / KibanaをホストしているFoundで 利用可能です。\nひゅう、息切れしました。 チームがしてきたことは、感動的で、謙虚で、刺激的です！ Elasticが会社として、全てのユーザ、コントリビュータがどのように私たちの大きなミッションに対する結果をもたらしたかという素晴らしい良い例です。 ユーザに愛され、楽しまれ、成功に導き、革新させる製品を是非ご利用ください。ありがとうございます。\n\u0026ldquo;A Lion, in Africa?\u0026rdquo; - まだまだ終わりではありません。この文言で終わりにしますが、すぐに（本当にすぐに）戻ってきます。;)\n","date":1446095939,"dir":"post/2015/","id":"4cc08ca51ecf0f963035f039de6194c5","lang":"ja","lastmod":1446095939,"permalink":"https://blog.johtani.info/blog/2015/10/29/release-we-have-ja/","publishdate":"2015-10-29T14:18:59+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Relase, we have ※画像に関しては原文をご覧ください。 Elasticにとって大きな1日","tags":["elasticsearch","kibana","logstash"],"title":"Release, we have（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 2.0.0-beta2 released\n本日（9/17）、Lucene 5.2.1ベースのElasticsearch 2.0.0-beta2をリリースしました。 本リリースが2.0.0のRCの前の最後のベータリリースになります。\n注意事項 本リリースはベータリリースであり、テストを目的としたものとなります。 Elasticsearch 2.0.0-beta2はElasticsearch 2.0.0-beta1と互換がありません。 また、Elasticsearch 2.0.0 GAと互換性があるかどうかの保証はありません。\n本番環境には利用しないでください。\nElasticsearch 2.0.0-beta2のダウンロードおよび、すべての変更についてはリンクをごらんください。\n2.0.0-beta1をテストし、問題点を報告していただいた皆様、ありがとうございます。 2.0.0-beta1のあとのElasticsearchのコアの部分の修正のほとんどはバグフィックスになりますが、 geo_shapeフィールドのpoints_only最適化のようなちょっとした改善も含んでいます。\nまた、本リリースでは、商用プラグインの重要な新機能もあります。 こちらについてはShield and Watcher 2.0.0-beta2 releasedをごらんください。 簡単な紹介は次の通りです。\nShieldの新機能 ドキュメントおよびフィールドレベルのセキュリティ Shieldは、クエリを利用したインデックスにあるドキュメントへのアクセスを制御するためのロールを定義できるようになりました。 また、ドキュメントにある特定のフィールドに関するアクセス制限も可能です。 フィルタされたエイリアスのような形ではなく、ドキュメントを検索したり、IDで取得したりする場合にこれらの制限が利用できます。 詳細はField- and Document-level Securityをごらんください\nユーザなりすまし 特定のユーザーに他のユーザーに扮して、彼らのためにリクエストを実行する能力を与えることが、現在できます。 これは、認証がアプリケーションによって実行される場合に便利です。 そして、それは、ユーザの許可レベルを考慮するようにElasticsearchにリクエストします。 詳細はSubmitting Requests for Other Usersをごらんください。\nプラガブルな認証レルム このリリースで、サードパーティの拡張のための認証レルムのインフラを公開しました。 もし、特定の認証要求があり、Shieldがサポートしていない（が、内部の認証管理システムを使いたいような）場合、 これらの要求に見合う新しい認証レルムを利用するプラグインを作成可能です。 詳細はCustom Realmsをごらんください。\nWatcherの新機能 監視の一時 新しく、active / inactive の状態がwatchに追加されました。 これらは、Watchを中断したり、要求に応じて再開させたりできます。 詳しくは、Active Stateをごらんください。\nチャットのための新しいアクション slackとhipchatアクションが追加されました。 これは、Watcherが通知を、SlackやHipchatのユーザに直接送ったり、 チームのチャットルームに送ったりすることが出来るようにします。 詳細については、Slack actionおよび、Hipchat actionをごらんください。\n2.0に関するこれまでのブログ記事 これまでのリリースについての情報はこれらのブログ記事をごらんください。\n\u0008* Elasticsearch 2.0.0.beta1 released\nElasticsearch 2.0.0.beta1 coming soon! The Great Mapping Refactoring Store compression in Lucene and Elasticsearch Better query execution coming to Elasticsearch 2.0 Out of this world aggregations Staying in Control with Moving Averages - Part 1 Staying in Control with Moving Averages - Part 2 The Delete by Query API Is now a plugin Elasticsearch unplugged - Networking changes in 2.0 また、Elasticsearch 2.0.0-beta2のドキュメントや2.0のbreaking changesのリストもごらんください。\nElsticsearch Migration Plugin Elasticsearch Migration Pluginは、既存のインデックスをアップグレードする 必要があるか、他に必要な行動がないかについて、Elasticsearch 2.0.0-beta2を試す前に確認する助けとなります。 Lucene 3のような古いインデックスや、2.0.0にした場合に動作しない問題のある マッピングのような問題を発見できます。\nプラグインの動作に関しては[Elasticsearch Migration repository](Elasticsearch Migration repository)をごらんください。\nテストしましょう！ Elasticsearch 2.0.0 GAをすぐにリリースできるようにより多くのベータテスターをお待ちしています。\nぜひ、Elasticsearch 2.0.0-beta2をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)やWebフォーラムなどで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1442565101,"dir":"post/2015/","id":"4b227d61f33182579cd3edd0ac6c7c44","lang":"ja","lastmod":1442565101,"permalink":"https://blog.johtani.info/blog/2015/09/18/elasticsearch-2-0-0-beta2-released-ja/","publishdate":"2015-09-18T17:31:41+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0-beta2 released 本日（9/17）、Lucene 5.2.1ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0-beta2リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch unplugged - Networking changes in 2.0\nElasticsearchをローカルのマシンで起動します。 そして、昨日試したデータを削除するためにDELETE *を実行します。 すると、悲しそうな叫びを同僚が発していることに気づき、なぜそんなことになっているのか不思議に思うでしょう。。。\nElasticsearchはいつも、親しみやすいものでした。 複数ノードのクラスタがどのように機能するのかをテストするには、 ローカルのマシンでいくつかのElasticsearchのインスタンスを起動するだけでした。 起動したインスタンスはマルチキャストを利用して自動的にお互いを見つけて、1つのクラスタになり、負荷を共有し始めます。 しかし、これは親しみやすすぎました。 カンファレンスなどで、ローカルのマシンでElasticsearchを起動してみてください。 すると100ノードのクラスタに参加しているのがすぐにわかるでしょう。\nもうすぐリリースされる、2.0.0-beta1では、Elasticsearchが通信先を選択するネットワークの機能に関する変更があります。 ただし、これまで通り、簡単に開発者が経験できる機能も残っています。\nlocalhostへのバインド 以前、Elasticsearchはデフォルトで、利用可能なネットワークインタフェース全てにバインドしていました。 そこから、一番適したインタフェースをpublish_hostとして選択しようとします。 このアドレスはElasticsearchがクラスタの他のノードとやりとりするためのアドレスです。\nElasticsearch 2.0では、デフォルトでは、localhostにのみバインドします。 127.0.0.1（IPv4）と[::1]（IPv6）の両方にバインドしようとします。 また、どちらかのみの環境でも動作します。 この変更は、特に指定がない限り、Elasticsearchがネットワーク上の他のノードと接続しません。 本番環境に移行する場合は、network.hostパラメータを使って設定しましょう。 設定は、elasticsearch.ymlに記述するか、コマンドラインで指定します。\nbin/elasticsearch --network.host 192.168.1.5 bin/elasticsearch --network.host _non_loopback_ network.hostの全てのオプションについては、network settingsのドキュメントをごらんください。\nマルチキャストは廃止 Elasticsearch 1.xはネットワークの他のノードに接続・探索するためにマルチキャストを使用しました。 マルチキャストは魔法のような挙動です。。。 残念ながら、マルチキャストのサポートは良くも悪くもあります。 Linuxはローカルホストでマルチキャストの待ち受けをしていません。 OS/Xは構成されたアドレスの全てのインタフェースにマルチキャストで配信できます。 また、ネットワークによってはマルチキャストはデフォルトでは使用できなくなっています。\nElasticsearch 2.0は異なるアプローチを採用しました。 マルチキャストを廃止します（ただし、新たにプラグインとして提供します）。 代わりに、ローカルホストでは、Elasticsearchはtransport.tcp.portで指定されている範囲（デフォルトは9300-9400）の最初の5ポートに対してユニキャストを使用できるようにします。\nこれは、開発者のための、設定することなく自動的にクラスタを組むという機能を残しています。 しかし、本番に移行するときは、unicast hostsで次のようにリストを指定する必要があります。\ndiscovery.zen.ping.unicast.hosts: [ 192.168.1.2, 192.168.1.3 ] unicast hostsとしてクラスタにあるノードの全てのリストを指定する必要はありません。 少なくとも、マスタノードとして選出されるべきものを指定します。 巨大なクラスタでは、3つの専用のマスタノードを持っており、この3つをunicast hostsとして設定することを推奨しています。\nこれにより、開発の知識・経験が、私たちの推奨する本番でのネットワーク設定に、より近いものとなります。\nノード情報の変更 最後に、inet[/127.0.0.1:9200]といったシンタックスを廃止します。 これは、Elasticsearchがnodes-info APIなどで、使用していたIPアドレスのためのシンタックスです。 今は、RFCに準拠した形で表示します。 127.0.0.1:9200（IPv4）や[::1]:9200（IPv6）のようにです。\n質問がある場合は、ElasticsearchのWebフォーラムで質問してください。ベータはもうすぐです！（翻訳した時点で、すでにベータリリースされています。）\n","date":1440730890,"dir":"post/2015/","id":"0de0edbf2a506143c1739b12e94c0ef9","lang":"ja","lastmod":1440730890,"permalink":"https://blog.johtani.info/blog/2015/08/28/elasticsearch-unplugged-ja/","publishdate":"2015-08-28T12:01:30+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch unplugged - Networking changes in 2.0 Elasticsearchをローカルのマシンで起","tags":["elasticsearch"],"title":"Elasticsearch unplugged - 2.0におけるネットワークの変更(日本語訳)"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 2.0.0-beta1 released\n本日（8/26）、Lucene 5.2.1ベースのElasticsearch 2.0.0-beta1をリリースしました。 本リリースは469名のコミッターからの2,500以上ものpull requestを含んでいます。 pull requestのうち、約850が2.0のための新規のものとなります。\n注意事項 本リリースはベータリリースであり、テストを目的としたものとなります。 Elasticsearch 2.0.0-beta1は Elasticsearch 2.0.0 GAと互換性があるかどうかの保証はありません。\n本番環境には利用しないでください。\nElasticsearch 2.0.0-beta1のダウンロードおよび、すべての変更についてはリンクをごらんください。\nElasticsearch 2.0.0-beta1には次の新しい変更が含まれています。\nPipeline Aggregations：これは、他のaggregationsの結果に対するAggregationを実行できます（導関数、移動平均、Holt Winter予測アルゴリズムなども含む） ディスクやファイルシステムキャッシュにより適したより良いデータの圧縮 doc-valuesがデフォルトになったこと、マージ実行時のメモリ使用量の低減、フィルターキャッシュのためのroaring bitsetsなどにより、ヒープの使用率がより効率的に。 構造化された例外 最適化されたクエリ実行順序、フィルタの自動キャッシュ、より高速なクエリに書き換えられたparent-child 設定の代わりに、フィードバックループを使用した自動調整 トランザクションログへの書き込みがデフォルトで、アトミックでかつ冗長に 安全で明確で信頼性のあるタイプマッピング デフォルトでローカルホストでのみクラスタを構成 クラスタ状態の差分によりより高速に変更を伝搬 上記の変更以外にも、多くのElasticsearchおよびLuceneに対する継続的な変更が含まれています。 これらは、Elasticsearch 2.0をより安全に、より簡単に、より良いものにしています。 本リリースに関するより詳しい情報が次のブログにあるので、参考にしてください。\nElasticsearch 2.0.0.beta1 coming soon! The Great Mapping Refactoring Store compression in Lucene and Elasticsearch Better query execution coming to Elasticsearch 2.0 Out of this world aggregations Staying in Control with Moving Averages - Part 1 Staying in Control with Moving Averages - Part 2 The Delete by Query API Is now a plugin Elasticsearch unplugged - Networking changes in 2.0 また、Elasticsearch 2.0.0-beta1のドキュメントも参考になります。 特に、2.0での重大な変更点については必ずごらんください。\nCore plugins コアプラグインの開発の方法を変更しました。 公式にサポートしているプラグインは、現在elasticsearchのリポジトリに含まれています。 これにより、コアと一緒にテストされ、Elasticsearchと同じタイミングでリリースされます。 コアプラグインはElasticsearchと同じバージョン番号隣ます。 インストールは次のようになります。\nsudo bin/plugin install analysis-icu プラグインの新しいドキュメントは私たちのWebサイトのGuideにあります。\nCommercial plugins 私たちの商用プラグインもElasticsearchと同じバージョン番号となり、Elasticsearchと一緒にリリースされます。 ShieldやWatcherはすでに2.0.0-beta1が利用可能です。 インストールのコマンドはは次のようになります。\nsudo bin/plugin install license sudo bin/plugin install shield sudo bin/plugin install watcher MarvelおよびSenseに関する新しい情報もありますが、もう少しお待ちください。\n2.0.0-beta1の商用プラグインに関するドキュメントは次のリンクからごらんください。\nShield 2.0.0-beta1 Watcher 2.0.0-beta1 Elasticsearch Migration plugin Elasticsearch 2.0.0-beta1を試す前に、 既存のインデックスのアップグレードするためになにか行う必要があるかどうかを確認するためのElasticsearch Migration Pluginもリリースしました。 2.0.0では機能しない、問題のあるマッピングなどを見つけるために便利なプラグインです。\nこのプラグインの利用方法についてはElasticsearch Migration repositoryをごらんください。\n既知の問題 同じインデックスの異なるタイプに、同じ名前のipタイプのフィールドを追加した時に、問題があることがわかっています。 この問題は次のリリースでフィックスされます。詳細は#13112をごらんください。\nテストしましょう！ Elasticsearch 2.0.0 GAをすぐにリリースできるようにより多くのベータテスターをお待ちしています。\nぜひ、Elasticsearch 2.0.0-beta1をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)やWebフォーラムなどで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1440638952,"dir":"post/2015/","id":"744554499cb7880086fbd9b1f080e7e1","lang":"ja","lastmod":1440638952,"permalink":"https://blog.johtani.info/blog/2015/08/27/elasticsearch-2-0-0-beta1-released-ja/","publishdate":"2015-08-27T10:29:12+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0-beta1 released 本日（8/26）、Lucene 5.2.1ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0-beta1リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：The Delete by Query API Is now a plugin\nElasticsearchの2.0.0-beta1では、これまであった Delete by Query APIが削除され、 新しく Delete by Query pluginに置き換えられています。\nもし、Delete by Query を利用する場合、2.0にアップグレードしたあとは、プラグインをインストールし、ドキュメントに従ってください。\nbin/plugin install delete-by-query なぜプラグインに？ ElasticsearchのコアなAPIの品質を保つためであり、以前のDelete by Queryの実装は簡単にはフィックスできない大きな問題がありました。\n各リクエストのあとに、refreshを実行します。これは、削除されたデータが想定外に検索に出てこないようにするためです。\nまた、セグメントが大量にでき、マージが大量に発生し、ヒープが大量に消費されてインデキシングが劇的にスローダウンし、クラスタの複数のノードがクラッシュしてしまう状況も引き起こしました。 このクエリは、プライマリ、レプリカの両方で実行されるため、ことなるドキュメントを削除し、矛盾したレプリカ（データの破損）を引き起こしました。 アップグレードが不安定になります。これは、Delete by Queryリクエストがトランザクションログの中にクエリとして残るためです。そのため、アップグレードのあとに正確にパースされなかったり正確に実行されないかもしれません。例えば、インデックスエイリアスに対するリクエストで、それが削除された後の場合にこのようなバグが発生します。 対照的に、新しいプラグインは、安全な実装です。 scanとscrollリクエストでクエリにマッチしたIDを見つけ、そのIDを使って、bulk indexing APIで削除します。\nこの実装は、遅い必要があります。特に、クエリが多くのドキュメントを削除する場合です。 もし、多くのドキュメントをこのAPIを利用して削除する場合、アプリケーションをテストしてください。 そして、代わりにインデックス全体を消すようなアプローチに切り替えることができないか検討してください。\nDelete by Query pluginのドキュメントに、新しい実装についての違いなどのより詳しい説明があります。\nElasticsearch coreを最小限に プラグインに切り替えることは、簡単な決断ではありませんでした。 多くのユーザは問題なく、Delete by Queryを利用していました。 しかし、危険が常にそこにあり、些細とは言い切れない数のユーザが上記のような深刻な問題に遭遇していました。\nさらに、Elsticsearchのコアは信頼できるものでなければなりません。 他のコアAPIを利用して実装できる機能は、コアに含みません。特に、それがバグを含んでいる場合。 コアのすべての機能は強固であるべきで、Delete by Queryは人気があり、高性能ですが、そうではありませんでした。\n必要に応じて、このような難しいトレードオフの末、信頼性と品質を選びます。\nマッピングの削除の廃止 タイプのマッピングを削除する機能も2.0で廃止されます。 これは、同じフィールド名を、異なるフィールドのタイプで再利用した場合に、インデックスの破損を引き起こす可能性があるためです。\nしかし、Match All Queryで、Delete by Queryプラグインに対してタイプを指定することで、タイプのすべてのドキュメントを削除することはできます。 または、1つのインデックスに異なるタイプを複数含める代わりに、個別のインデックスに分割するようなアプローチに変更することを検討してください。\n","date":1440044644,"dir":"post/2015/","id":"5a9e950f4ac186925e5de978c5f72062","lang":"ja","lastmod":1440044644,"permalink":"https://blog.johtani.info/blog/2015/08/20/core-delete-by-query-is-a-plugin-ja/","publishdate":"2015-08-20T13:24:04+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：The Delete by Query API Is now a plugin Elasticsearchの2.0.0-beta1では、これまで","tags":["elasticsearch"],"title":"Delete by Query APIはプラグインへ（日本語訳）"},{"contents":"第11回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズさん、そして、Shayありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n今回は、CTOのShayが来日していたので、英語でいろいろと喋ってもらいました。 4月同様、サムライズムの@yusukeさんに テキスト翻訳していただき、大変助かりました。 今回はQAベースのトークだったのでちょっときつかったですね、申し訳ない。。。\nチェックイン数など チェックインした人：141名 キャンセルしなかった人：51名 でした。 今回はあらかじめ220名（全員が来たらキャパオーバー）としていたので、キャンセル待ちの人は 当日の午後にはいなくなっていた状態です。まぁ、こんなもんかな。結構入りましたね。ありがたいです。\nLT 今回は、少し趣向を変えて、4社の方達にLTをしていただきました。 Shayが来日しているのもあり、事前に英語でスライドを作っていただけると助かりますとお願いさせていただきました。 英語でスライドを作っていただいていたので、伝わりやすくて助かりました、スピーカーの方々ありがとうございました！\n（海外のユーザにもリンクを紹介しやすいので、英語でスライド作ってもらえるといろいろと知ってもらえるのかも。）\nElasticsearch and Recruit Technologies Co., Ltd. / 株式会社リクルートテクノロジーズ　守谷 純之介さん スライド：未定\nN-Gramと形態素のハイブリッドの話などをしていただきました。 @ITで連載もされてますね。ありがとうございます。\nリクルート全社検索基盤のアーキテクチャ、採用技術、開発体制はどうなっているのか (1/2) ElasticsearchとKuromojiを使った形態素解析とN-Gramによる検索の適合率と再現率の向上 (1/3) Shayからは、elasticsearch-hadoopがあるから検討してねと質問（お願い？）がありましたw。\nElasticsearch as a DMP / 株式会社インティメート・マージャー　松田和樹さん　@mats116 スライド：Elasticsearch as a DMP\nいくつかのデータソースからAEROSPIKE経由でelasticsearchにデータを登録しているようです。 Data Management Platformのエンジンの一部として、elasticsearchを利用しているようです。\nShayからの質問：「どの機能を使って関心のある単語を抽出していますか？」\n回答：「Significant Term Aggregation」です。\nShay：「おぉ、チェックしてみますw」。\nReal-time social big data analytics using elasticsearch / 株式会社ホットリンク宮田洋毅さん　@kakka_jp スライド：未定\nソーシャルメディアのデータを解析するのにelasticsearchにデータを入れて解析。 時間軸での解析やテキストマイニングなんかをしているみたいでした。 いろいろと独自のプラグインを作ってるようです。（興味あるなぁ）\nShayからの質問：「ノード数は？」「30ノードで30シャード」\nElasticsearch in Hatena Bookmark / 株式会社はてな　id:skozawa スライド：Elasticsearch in Hatena Bookmark\nはてなブックマークの検索の歴史（MySQL -\u0026gt; Sedue -\u0026gt; Solr -\u0026gt; Elasticsearch） はてなブックマークの検索（ユーザが利用）と社内利用と、ログ解析で利用してる Shayからの質問：「昨年会いましたよね？今はクラスタのサイズはどのくらいのサイズですか？」「メインクラスタは9データノード」\nOpen QA with Shay 思い出せるものだけ。。。（あとで追記します）\nElasticsearch 2.0の話 Pipeline Aggregationとか。 Spark Streaming対応してる？ まだ検討中 elasticsearch-hadoopってどんなもの？HDFSにインデックス作ったりするの？ いえ、Hadoopの入出力先としてelasticsearchが使える感じ 個人的にAWSのCloudSearchとAWSでElasticsearchはどっちがいい？ 時系列データはCloudSearchだと難しいだろうし、AWS上ならfound.noがあるよ！ PostgreSQLみたいに信頼性の高いデータストアを目指してる（まだ、プライマリデータストアには使わないで） その他、感想などのブログ Elasticsearch勉強会でLTしてきました | Intimate Merger Engineer Blog 『第11回elasticsearch勉強会』のまとめ #elasticsearchjp \u0008* [Elasticsearch] 第11回 Elasticsearch 勉強会へ参加してきた - 雑文発散(2015-07-28) 第11回 Elasticsearch 勉強会に参加したら英語力に危機感を覚えて最高だった まとめ 今回はShayが来日したので特別バージョンでした。 もっと英語を翻訳するサポートしないとですね、反省してます。。。ぜんぜん流暢じゃないしw\n次回は9月に開催予定ですが、12月にまたShayが再度来日する予定です。 丸1日のイベントを検討中で、Shay以外にも開発者が来日すると思います。 どんな話が聞きたい、どんな人と話をしたいなどあれば、コメントいただければ（対応できるかは。。。）\n勉強会のスピーカーは随時募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1438321313,"dir":"post/2015/","id":"73b8194ad8fce0cabb01cd21d5e18500","lang":"ja","lastmod":1438321313,"permalink":"https://blog.johtani.info/blog/2015/07/31/11th-elasticsearch-jp/","publishdate":"2015-07-31T14:41:53+09:00","summary":"第11回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ","tags":["elasticsearch","勉強会"],"title":"第11回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.7.1 and 1.6.2 released\n本日（7/29）、Lucene 4.10.4ベースのElasticsearch 1.7.1およびElasticsearch 1.6.2 のバグフィックス版をリリースしました。 これらのリリースは稀ですが、データの欠損が発生する重要なバグのフィックスを含んでいます。 すべてのユーザにアップグレードを推奨します。\nダウンロードおよびすべての変更については次のリンクをごらんください。\n最新安定版：Elasticsearch 1.7.1 1.6系バグフィックス：Elasticsearch 1.6.2 問題のバグ(#12487)は、 同時に複数のノードが故障またはリスタートをした場合の非常にまれな状況で、 シャードのすべてのコピーがクラスタから削除されてしまう状況を発生させます。 このバグは1.5.0から含まれています。\nこのリリースはまた、IPv4アドレスのCIDRマスクのバグのフィックス、 Shieldユーザがmore-like-this APIを利用できないバグのフィックスなど、 いくつかの変更も含んでいます（詳細は更新リストをごらんください）。\nぜひ、Elasticsearch 1.7.1をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1438173353,"dir":"post/2015/","id":"100c0a69bea7f02a0f4540ecaa37d0e3","lang":"ja","lastmod":1438173353,"permalink":"https://blog.johtani.info/blog/2015/07/29/elasticsearch-1-7-1-and-1-6-2-released-ja/","publishdate":"2015-07-29T21:35:53+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.1 and 1.6.2 released 本日（7/29）、Lucene 4.10.4ベースのE","tags":["elasticsearch"],"title":"Elasticsearch 1.7.1 および 1.6.2リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.7.0 and 1.6.1 released\n本日（7/16）、Lucene 4.10.4ベースのElasticsearch 1.7.0およびElasticsearch 1.6.1 のバグフィックス版をリリースしました。 これらのリリースはセキュリティフィックスを含んでおり、すべてのユーザにアップグレードを推奨します。\nダウンロードおよびすべての変更については次のリンクをごらんください。\n最新安定版：Elasticsearch 1.7.0 1.6系バグフィックス：Elasticsearch 1.6.1 1.7.0が1.x系の最後のリリースとなります。 今後の新機能については、Elasticsearch 2.0以降で取り込まれる予定です。\nElasticsearch 1.7.0は小さなリリースですが、2つの重要なセキュリティフィックスと クラスタの安定化とリカバリに関する2つの重要な機能を含んでいます。\nセキュリティフィックス シャードアロケーションを遅らせる インデックスリカバリの優先度 セキュリティフィックス Elasticsearch 1.6.1 と 1.7.0 は次の2つのセキュリティフィックスを含んでいます。\nリモートコード実行の脆弱性 Elasticsearch 1.6.1より前のバージョンには、transport protocol（ノードとJavaクライアント間での通信に利用）により、 リモートでコードが実行される脆弱性があります。 これは、CVE-2015-3253でのGroovyに関係しています。\nGroovyのダイナミックスクリプティングがオフでも脆弱性があります。 アップグレードをしないユーザは、transport protocol のポート（デフォルトで9300）信頼したエージェントからのみの アクセスに限定することで、脆弱性から保護できます。\nこの問題をCVE-2015-5377としました。\nディレクトリ探索の脆弱性 Elasticsearch 1.0.0から1.6.0までのバージョンで、ElasticsearchのJVMプロセスによって読み込みが可能なファイルを 取得することができるディレクトリ探索攻撃の脆弱性があります。 アップグレードをしないユーザは、信頼できない場所からのSnapshot-Restore APIの呼び出しを防ぐためにファイアウォール、リバースプロキシやShieldを使用することができます。\nこの問題をCVE-2015-5531としました。\nシャードアロケーションを遅らせる Elasticsearch 1.6.0でSynced Flushingが導入されました。 これは、ノードのリスタート時に、更新が止まっているシャードのリカバリを劇的にスピードアップします。 しかし、この変更は、シャードの配置を無効にしている環境でのみうまく実行されます。 ノードが一時的にクラスタから外れている場合や予期せぬリブートの場合には役に立ちません。\nこのシナリオとは次のようなものです。\nノードの想定外のシャットダウン マスタがたのノードにシャードを再配置 各シャードが新しい場所にネットワーク越しにコピー その間に、外れていたノードが再度クラスタにジョイン マスタは新しいノードにシャードを再配置。新しいノードに存在する既存のシャードが全く再利用されない可能性がある ノードレベルとクラスタレベルの両方の並列的なリカバリを抑制しても、 この\u0026quot;シャードシャッフル\u0026quot;がクラスタに対して負荷をかける可能性があります。 これは、外れたノードが再度ジョインするのを単に待つことにより防げるかもしれません。\n待ちましょう！ Elasticsearch 1.7.0はindex.unassigned.node_left.delayed_timeout設定を追加しました。デフォルトでは1分です。 これは、ノードがクラスタから外れたとき、ほかのノードにこれらのノードを再配置するまでマスタが1分待つということです。 ノードがこの1分の間に復帰した場合、マスタはローカルにあるシャードを再度配置します。\nなぜ1分？ ノードがシャットダウンし、リスタートし、復帰するために十分な時間が1分だからです。 しかし、ノードが復帰しない場合にはまだ再配置が発生することを意味します。 デフォルト値を決定するのは難しいです。 この設定をどのくらいに減らすか、増やすかを決める必要があるかもしれません。\nこのデフォルト値は、config/elasticsearch.ymlファイルに設定できますが、インデックス設定の更新APIを使って設定することも可能です。\nこのデフォルトに関する知見をぜひフィードバックしてください。\nインデックスリカバリの優先度 1.7.0の2つ目の重要な機構はフルクラスタリスタートのような後に、 どの順番でインデックスをリカバリするかという優先度をつけることができるという機能です。\n電源故障による、ロギング用のクラスタのダウンを想像してください。 クラスタが普及した場合、500個のインデックスをリカバリするような場合、499個のインデックスのデータは古く、 500番目のインデックスが重要です。 もっとも最近作成されたインデックスがリカバリされるまで、インデキシングを待つというようなことはできません。\nこれまでは、インデックスはランダムな順序でリカバリされ、重要なインデックスがリカバリされるまで待つしかありませんでした。 1.7.0では、インデックスは優先度の順番でリカバリされます。 この優先度は次のプロパティで指定できます。\nindex.priority設定（大きな値が優先度が高い） インデックス作成日（新しいものが優先度が高い） インデックス名 既存のクラスタについて特に変更せずとも、最も最近作成されたインデックスが古いものよりも復旧されます。 古いインデックスの優先度を上げるためには、index.priority設定に0よりも大きな値を設定します。\nPUT important_index/_settings { \u0026#34;index.priority\u0026#34;: 5 } この設定は、存在するインデックスに対して更新できます。リカバリ中にもです。\nまとめ ぜひ、Elasticsearch 1.7.0をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1437546817,"dir":"post/2015/","id":"809925e891b0456231c374b09cbe4a90","lang":"ja","lastmod":1437546817,"permalink":"https://blog.johtani.info/blog/2015/07/22/elasticsearch-1-7-0-and-1-6-1-released-ja/","publishdate":"2015-07-22T15:33:37+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.0 and 1.6.1 released 本日（7/16）、Lucene 4.10.4ベースのE","tags":["elasticsearch"],"title":"Elasticsearch 1.7.0 および 1.6.1リリース（日本語訳）"},{"contents":"東京以外での勉強会の第2弾として、関西で勉強会を開催してきました。\nElasticsearch勉強会 in 大阪 Elasticsearch勉強会 in 京都 会場提供をしていただいた、Yahoo!大阪、はてなのみなさん、ご協力ありがとうございました！\nここからはいつものメモです。 ちなみに、大阪の勉強会に、@takuya_aさんと@5kozawaさんの両名にお越しいただき話をしていただきました。 なので、勉強会の内容はほぼ同一になります。\nIntroduction Elastic @johtani スライド：Introduction Elasticsearch\n初めての関西での勉強会ということで、ElasticsearchのOSSおよび商用プラグインの紹介をしてきました。 もちろん、Kibanaのデモもちょっとだけ。スプラトゥーンに関するデータをKibanaでちょっとだけ。 突貫でデータをかき集めたのでもう少し改良しないとですが。\nElasticsearch での類似文書検索と More Like This API 詳解 / 株式会社はてな　id:takuya-a スライド：Elasticsearch での類似文書検索と More Like This Query API 詳解\nElasticsearchのMore Like Thisのソースコードリーディングみたいな感じで、 内部でどうやって処理されているかの説明を詳しくしてもらいました。\n前のはてなエンジニアセミナーで話をされていた検索精度の件に絡んだ内容になっているかと。 （大阪で発表してもらった時より京都での発表が分かりやすくなってました。1日で改善されたのすごい！） MoreLikeThisだとチューニングつらいので、自分で作るためにTermVectorAPIでやってみたという流れかと。\n以下は発表後に出てきた質問のいくつかです。\nQ:MoreLikeThisに対してTermVectorで柔軟にできる？ A:TermVectorのAPIで統計情報が取れるので、それを使うことでさらなるデータの更新ができる。\nQ:TFとかの統計情報が必要なら、すべてインデックスをしたあとじゃないとちゃんとした値はとれないのでは？ A:TermVectorで取得したものをどうやって使うか\nQ:TermVectorAPi\u0026hellip;聞こえなかった A:。。。\nElasticsearchを用いたはてなブックマークのトピック生成 / 株式会社はてな　id:skozawa スライド：Elasticsearchを用いたはてなブックマークのトピック生成\nSignificant Terms Aggregationを活用してる話。 トピックページの生成のために、Significant Terms Aggregationをどうやって利用しているかなどのお話でした。\nトピックの集合の重複だったり、精度の判定方法とかいろいろ詳しく説明していただきました。\nQ:2011年と12年で11年の方が多いのは？ A:ブックマークの件数に比例\nQ:Significant terms aggsのsizeはいくつをつかってますか？ A:20を指定してます。\nQ:Yahooとかニュースをストップワードとしてますが、Yahoo自体のニュースに関してはどーしてるんですか？ A:本文とタイトルから別々に作っていて、タイトルからは弾かれますが、本文から作った時に出てきます。\nはてなブックマークにおける Elasticsearch の運用まわりの話 / 株式会社はてな　id:hagihala スライド：未定（おそらく公開される）\n体調が回復しきっていない中の発表ありがとうございました。 大幅に修正された資料が出てくるかなと。（ツイートできない数値がちらほらあったので）\nElasticsearchのクラスタの構成、どういった点で困ってたのでどういう調べ方をしたのか、どういった対処をしたのか。 どのあたりが次の課題かなどの話もありました。\n感想・反省点など 大阪、京都ともに30名弱の方の参加をしていただきました。ありがとうございました。 反省点としては、ハッシュタグを告知し忘れてました。。。\n勉強会はやはり、東京が異常に活発で、大阪や京都はまだそれほどでもないのかなぁとも。 大阪はエンジニアの人や会社も多い気がするんですが。私の告知の仕方もあるかもなぁと。 次回があれば、大阪での事例も聞きたいので、スピーカーをもっと探さないとなと。\n関連ブログなど 見つけたら、リンク追加していきます。\nElasticsearch勉強会 in 大阪/京都で発表しました \u0008* 「Elasticsearch での類似文書検索と More Like This Query API 詳解」というタイトルで発表しました その他（余談） 大阪のYahoo!さんは立地条件（梅田のすぐそば）がよく、\n夜景も綺麗でした。大阪城とかも見えてました。（夜景じゃないけど。。。）\n京都は祇園祭の真っ最中。\n水曜日はお休みをいただいて、観光してました。ちょっと日焼けが。。。 おかげで、リフレッシュできました。三十三間堂とか良かった:)\nあまり、関西に縁がない（大阪15年ぶり、京都10年ぶり）ので、 もっとユーザが増えて勉強会の機運が高まると嬉しいなと。:)\n","date":1437010857,"dir":"post/2015/","id":"dd6c32a722dc815273cd9ed8cd6c671b","lang":"ja","lastmod":1437010857,"permalink":"https://blog.johtani.info/blog/2015/07/16/kansai-1st-elasticsearch-jp/","publishdate":"2015-07-16T10:40:57+09:00","summary":"東京以外での勉強会の第2弾として、関西で勉強会を開催してきました。 Elasticsearch勉強会 in 大阪 Elasticsearch勉強会 in 京","tags":["勉強会","elasticsearch"],"title":"大阪と京都でElasticsearch勉強会を開催しました。 #elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：The Great Mapping Refactoring\nElasticsearchのユーザの悩みの最も大きなものの一つは、 タイプとフィールドのマッピングに関する多義性です。 この多義性は、インデックス時の例外やクエリ時の例外、 正しくない結果、リクエストからリクエストへ変化する結果、 また、インデックスの故障やデータのロスを結果として引き起こします。\nElasticsearchをより強固で予測可能な振る舞いをするようにする作業において、 フィールドやタイプのマッピングをより厳格でより信頼性を高くするかといったことに 多くの変更を費やしました。 多くのケースで、Elasticsearch v2.0で新しいインデックスを作るときにのみ、 新しいルールを強制し、これまでのインデックスに関しては後方互換性を保つようにします。\nしかし、幾つかのケースでは、先ほど説明したようなフィールドマッピングの コンフリクトなどが存在するため、それらを利用できないです。\nコンフリクトしたフィールドのマッピングをもつインデックスはElasticsearch v2.0にはアップグレードできません。\nもし、これらのインデックスのデータが必要ない場合は、インデックスを消せばいいです。 そうでない場合はマッピングを正しくして再度インデックスする必要があるでしょう。\nマッピングを正しく変更することは、私たちが簡単に決めることではありません。 ここからは、現在ある問題点と、私たちがどのように実装して解決したかについて説明します。\nフィールドマッピングのコンフリクト あいまいなフィールドのルックアップ タイプのメタフィールド アナライザ設定 index_nameとpath 同期的なマッピングの更新 マッピングの削除 2.0のための準備 フィールドマッピングのコンフリクト これまで、わたしたちはドキュメントのタイプは「データベースのテーブルのようなもの」と説明していました。 タイプの目的を説明する簡単な方法だったからです。 しかし、残念なことにこれは、真実ではありません。 「同じ」インデックスの「異なるタイプ」にある同じ名前のフィールドは、 内部的に、Luceneのフィールド名が同じものになります。\nもしerrorフィールドとして、ドキュメントタイプがapacheのものには数値（integer）を、 ドキュメントタイプがnginxのものには文字列（string）を割り当てた場合、 Elasticsearchは同じLuceneのフィールドに数値と文字列のデータをもつことになります。 このフィールドに対して、検索やaggregationを行う場合、おかしな結果を受け取るか、例外が帰ってくるか、 インデックスが破損することになります。\nこの問題を解決するために、まず、ドキュメントタイプの名前をフィールドの名前の前に追加することを考えました。 各フィールドは完全に別のものとなります。 このアプローチの利点はドキュメントタイプが実際のテーブルのようになることです。\nしかし、この方法には多くの欠点があります。\nフィールドは常に、他のタイプとは異なるものであると区別するためもしくは、複数のタイプに同じフィールドのクエリのためにワイルドカードをつけた場合、 ドキュメントタイプを前につける必要があります。 複数のドキュメントタイプに対して同じフィールド名で検索する場合、クエリを個別に発行しなければならなく遅くなります。 多くの検索で、既存の多くのクエリを壊してしまうために、単純なmatchやtermクエリの代わりに、multi-fieldクエリを使う必要があります。 圧縮の効率の悪さから、ヒープ利用量、ディスク使用量、I/Oなどが、増加します。 複数のドキュメントタイプに対するaggregationは、global ordinalの利点を利用できなくなるために、遅くなり、メモリの使用量も増えます。 解決方法 最終的に、同じインデックスの同じ名前を持つ全てのフィールドは、同じマッピングを持つ必要があるというルールを採用することに決めました。 ただ、copy_toやenabledのようなパラメータはタイプごとに指定することができるようになっています。 これにより、データの破損、クエリ時の例外そして、おかしな結果が発生する問題を防ぎます。 クエリとaggregationは現在でも高速なままで、圧縮率を最大化し、ヒープ使用量やディスク使用率の低減させます。\nこの解決方法の欠点は、個別のテーブルとしてタイプを扱いたいユーザが彼らの考え方を変える必要があるということです。 これは、思ったよりも問題ではありません。 実際には、多くのフィールド名はデータの明確なタイプを表現しています。 created_dateは常に、日付ですし、number_of_hitsフィールドはいつも数値です。 フィールドマッピングがコンフリクトしているユーザはデータを失ったり、おかしなデータを受け取ったり、データを欠損させています。 ベストプラクティスにユーザが従っているかどうかによらず、インデックス時に正しい振る舞いを強制することが現在の違いです。\nユーザの多くがコンフリクトしていないフィールドマッピングをもっていれば、 コンフリクトが起きた場合、技術がこれらのシチュエーションを扱うことが可能になると思いませんか？ そこにはいくつかの解決方法があります。\nタイプの代わりにインデックスを別々に 最も簡単な解決方法です。インデックスを別々のインデックスとし、実際のデータベーステーブルのようにします。 インデックスをまたいだ検索はタイプをまたいだ検索のように動作しますし、 ソートやaggregationも同じデータタイプへのクエリのように動作します。これまでと同じ制限です。\nコンフリクトしたフィールドの名前の変更 コンフリクトがごくわずかな場合、（Logstashやアプリケーションで使っているものも一緒に）よりわかりやすいフィールド名に変更することで解決できます。 例えば、2つのerrorフィールドがあった場合に、error_codeとerror_messageに変更します。\ncopy_toもしくはmulti-fieldsを利用 異なるドキュメントタイプのフィールドは別々のcopy_toを設定できます。 元のerrorフィールドはindexの設定にnoが設定してあり、全てのドキュメントタイプで無効化されていますが、 特定のタイプだけ、errorフィールドの値を数値のerror_codeフィールドにコピーすることができます。\nPUT my_index/_mapping/mapping_one { \u0026#34;properties\u0026#34;: { \u0026#34;error\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;no\u0026#34;, \u0026#34;copy_to\u0026#34;: \u0026#34;error_code\u0026#34; }, \u0026#34;error_code\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;integer\u0026#34; } } } 他のタイプでは文字列のerror_messageにコピーします。\nPUT my_index/_mapping/mapping_two { \u0026#34;properties\u0026#34;: { \u0026#34;error\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;no\u0026#34;, \u0026#34;copy_to\u0026#34;: \u0026#34;error_message\u0026#34; }, \u0026#34;error_message\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } 同様の解決方法としてmulti-fieldも使えます。\n各データタイプに対してネストしたフィールドに ときどき、Elasticsearchに送ったドキュメントやドキュメントがもっているフィールドを制御できない場合があります。 部分的なコンフリクトに加え、闇雲に、ユーザが送ってきたフィールドを受け入れると、マッピングが肥大化します。 タイムスタンプやIPアドレスをフィールド名に使うようなドキュメントがあると考えてください。\nnested フィールドにすることで、str_val、int_val、date_valというような各データタイプを利用できます。\nこのアプローチによって、次のドキュメントは\n{ \u0026#34;message\u0026#34;: \u0026#34;some string\u0026#34;, \u0026#34;count\u0026#34;: 1, \u0026#34;date\u0026#34;: \u0026#34;2015-06-01\u0026#34; } アプリケーションによって、次のようにフォーマットしなおす必要があります。\n{ \u0026#34;data\u0026#34;: [ {\u0026#34;key\u0026#34;: \u0026#34;message\u0026#34;, \u0026#34;str_val\u0026#34;: \u0026#34;some_string\u0026#34; }, {\u0026#34;key\u0026#34;: \u0026#34;count\u0026#34;, \u0026#34;int_val\u0026#34;: 1 }, {\u0026#34;key\u0026#34;: \u0026#34;date\u0026#34;, \u0026#34;date_val\u0026#34;: \u0026#34;2015-06-01\u0026#34; } ] } この解決方法は、アプリケーションサイドでより多くの作業が必要ですが、コンフリクトの問題とマッピングの肥大化の問題を同時に解決します。\nあいまいなフィールドのルックアップ 現在、フィールドの指定には\u0026quot;short name\u0026quot;、フルパス、ドキュメントタイプを前につけたフルパスが利用できます。 これらのオプションがあいまいさをもたらしています。 サンプルとして次のマッピングをご覧ください。\n{ \u0026#34;mappings\u0026#34;: { \u0026#34;user\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;title\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;blog\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;title\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;user\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;object\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;title\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } } } } } titleはuser.title、blog.title、blog.user.titleのどれでしょう？ user.titleはuser.titleまたはblog.user.titleのどちらでしょう？ 答えは「場合によります。」です。Elasticsearchが最初に見つけたものになります。 フィールドはリクエストごとに変わるため、各ノードでマッピングがどのようにシリアライズされたかに依存します。\n2.0では、フィールドを指定する時に、ドキュメントタイプを除いたフルパス名を使用するべきでしょう。\nuser.titleは、blogタイプのuser.titleを意味します。 titleは、userとblogタイプのtitleフィールドを意味します。 *titleはuser.titleとtitleフィールドの両方にマッチします。 userタイプのtitleフィールドとblogタイプのtitleの違いはどのように指定するのでしょう？\n指定できません。フィールドマッピングのコンフリクトで説明した変更により、 titleフィールドは両方のタイプで同じフィールドになります。 本質的にtitleと呼ばれる1つのフィールドになります。\nuser.やblog.のようなタイプのプレフィックスはタイプを指定することによるフィルタリングで効果があります。 クエリのblog.titleフィールドはblogタイプのドキュメントだけを検索し、userタイプのドキュメントを検索しません。 このシンタックスは誤解を招きやすいです。なぜなら、いつでも動作するわけではないからです。 aggregationやsuggestionはすべてのタイプに関する結果を含みます。 この利用のため、上記の例のあいまいさがあるので、タイプのプレフィックスはサポートしません。\n重要 short nameやタイププレフィックスを利用したpercolatorは更新する必要があります。\nタイプのメタフィールド すべてのタイプはメタフィールドを持っています。_id、_index、_routing、_parent、_timestampなどです。 これらのほとんどはindex、store、pathのような幾つかの設定をサポートしています。 これらの設定について次のようにシンプルにしました。\n_idと_typeは変更不可 _indexは、ドキュメントのもつインデックスを保存するためにenabled _routingはrequiredのみを指定 _sizeはenabledのみ _timestampはデフォルトで保存される _boostと_analyzerは廃止。古いインデックスのものは無視される ドキュメントのフィールドから_idと_routingと_timestampの値を抽出することができました。 この機能は廃止されます。これは、ドキュメントのパースとコンフリクトを起こすためです。 代わりに、これらの値はURLもしくはquery stringで指定可能です。\n_boostと_analyzerフィールドは例外で、すでにあるメタフィールドの設定は古いインデックスのものが採用されます。\nアナライザ設定 これまで、indexとsearchのアナライザがインデックス、タイプ、フィールド、ドキュメント（_analyzerフィールドで）の それぞれのレベルで指定可能でした。 同じフィールドに対して異なるanalysis chainの組み合わせができることにより、おかしな関連度を引き起こしていました。 フィールドマッピングのコンフリクトを解消することに加え、アナライザの設定も簡略化します。\nAnalyzedな文字列フィールドは、analyzer設定とsearch_analyzer設定（analyzer設定の値をデフォルトとする）を指定できます。index_analyzer設定はanalyzerとなります。 複数のタイプで同じ名前のフィールドがある場合、フィールドはすべて、同じアナライザの設定を持たなければなりません。 タイプレベルのデフォルト設定のanalyzer、index_analyzer、search_analyzer設定は廃止されます。 デフォルトアナライザはインデックスごとにインデックスのanalysis設定で設定します。これらはdefaultもしくはdefault_searchという名前で設定します。 ドキュメントごとの_analyzerフィールドはサポートしません。既存のインデックスのものは無視されます。 index_nameとpath index_nameとpath設定は（Elasticsearch v1.0.0から利用できる）copy_toによって置き換わりました。 既存のインデックスについてはこれらは機能しますが、新しいインデックスでは指定できません。\n同期的なマッピングの更新 現在、これまで存在していないフィールドを含むドキュメントをインデキシングするとき、 フィールドはローカルのマッピングに追加され、それから、マスターに変更（新しいマッピングをすべてのシャードに適用する更新）が送信されていました。 同時に2つのシャードに同じフィールドを追加することができます。 また、そのとき、異なる2つのマッピングがある可能性があります。 1つはdoubleでもう1つはlongだったり、stringとdateだったりと。\nこのような場合、マスターに最初に届いたマッピングが採用されます。 しかし、「負けた」マッピングをもつシャードでは、すでに異なるデータのタイプを利用しているため、 これを利用し続けます。 そのご、ノードをリスタートしたときに、シャードが別のノードに移動し、マスターにあるマッピングを適用します。 このとき、インデックスが破損したりデータを失ったりします。\nこれを防ぐために、シャードはインデキシングを続ける前に、新しいマッピングがマスターによって採用されるかどうかを待つようになりました。 これはすべてのマッピングが安全に更新されます。 新しいフィールドをもっているドキュメントをインデキシングすると、前よりも処理が遅くなるでしょう。 受け入れられることを待つ必要があるためです。 しかし、クラスタの状態の更新処理のスピードが次の2つの新しい機能によって大きく改善されています。\nクラスタ状態の差分：可能であれば、クラスタの状態の変更はクラスタ状態全体の変更ではなく、部分的なものとする。 シャードへのリクエストの非同期化：シャードアロケーション処理中に、マスタノードは、 割り当てられていないシャードのコピーの日付が最新のものを持っているかを見つけるために、リクエストをデータノードに対して送信します。 ここで、クラスタ状態を変更する呼び出しがブロッキングで行われていました。v1.6.0から、このリクエストはバックグラウンドで非同期で実行されます。 これにより、マッピング更新のようなペンディングタスクをより早く処理できるようになります。 マッピングの削除 （そのタイプのドキュメントがある場合）タイプマッピングを削除できないようにします。 マッピングを削除した後に、削除されたフィールドの情報は、Luceneレベルでは存在し続け、 もし、後から同じ名前のフィールドが追加されたときにインデックスの破損を引き起こします。 そのようなマッピングは残しておくか、新しいインデックスに再インデックスすることができます。\n2.0のための準備 マッピングがコンフリクトしているかどうかを決めることは、手動で行うには慎重に行う必要があります。 私たちは、Elasticsearch Migration Pluginを提供します。 これは、2.0で非推奨になったり廃止された機能を利用しているかどうかを見つけるために役に立つでしょう。\nもし、コンフリクトしたマッピングを持っている場合、 正しいマッピングを持つ新しいインデックスにデータを再インデックスするか、 必要ないなら削除します。 これらのコンフリクトを解決しない限り2.0にはアップグレードできないでしょう。\n","date":1436346691,"dir":"post/2015/","id":"ee4ff9e4e8a1948795e26af2f3f8a30f","lang":"ja","lastmod":1436346691,"permalink":"https://blog.johtani.info/blog/2015/07/08/great-mapping-refactoring-ja/","publishdate":"2015-07-08T18:11:31+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：The Great Mapping Refactoring Elasticsearchのユーザの悩みの最も大きなものの一つは、 タイプと","tags":["elasticsearch"],"title":"Mappingのすばらしいリファクタリング（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 2.0.0.beta1 coming soon!\nElasticsearch 2.0.0.beta1のリリースの準備をしています。 これは、Lucene 5.2.1に含まれる多くの改善が利用できるようになります。 このリリースに関するいくつかの機能は次のようなものです。\nPipeline Aggregations 差分や移動平均、他のAggregationsの結果に対する series arithmeticのようなaggregationが利用可能になります。 この機能は、これまでは、クライアントサイドで実行する必要がありました。 しかし、この計算をより強力な解析クエリを構築してElasticsearchで 実行することができるようになります。 クライアントのコードをより簡潔にすることができます。 これにより、予測解析や異常検知のようなことができるようになります。\nQuery/Filter merging Filterはなくなります。全てのフィルタは、クエリになります。 クエリコンテキストで利用されると、効率的に関連度スコアを計算し、 フィルタコンテキストで利用されると、単に、 マッチしていないドキュメントを除外する（今のフィルタのようなもの）だけです この変更は、クエリ実行が自動的に、より効率的な順番で実行されるように 最適化されることを意味します。 例えば、フレーズやgeoクエリのような遅いクエリは まず、近似フェーズを実行し、それから、より遅い実際のフェーズが 結果に対して行われます。 フィルタコンテキストにおいて、頻繁に利用される条件は自動的にキャッシュされます。\nConfigurable store compression index.codec設定により、高速化のためのLZ4圧縮（default）か インデックスサイズを小さくするためのDEFLATE（best_compression）を 選択できます。これは、ロギングでとくに役に立ちます。 これにより、古いインデックスオプティマイズする前にbest_compressionに 変更できます。\nこれらに関するブログ記事がすぐに公開されるでしょう。\nPerformance and resilience 以降では、新しいメジャーリリースに関して簡単に紹介します。 2.0の変更の多くは内部の機能に関するものであり、 直接ユーザに関連するわけではないからです。\n新しいメジャーバージョンのテーマは、パフォーマンス、安定性、 堅牢性、予測可能性、そして使い勝手の良さです。\n物事が予測した通りに動作する 何か問題があった場合に、Elasticsearchから役立つフィードバックがある ローレベルの設定を扱う必要はなく、Elasticsearchが良い設定を決定する これらに加え、データがより安全に これらの目標は完全ではありません。 まだ、多くの改善があります。しかし、2.xブランチで、 すでに500コミットを超える大きな改善が実施されています。\non-diskの doc valuesをデフォルトで利用（これまではfielddata）。 ヒープ使用量を減らして、スケーラビリティを向上 セグメントマージ処理中のメモリ使用量の削減 normsの圧縮率の改善。ヒープスペースを利用している大きな処理のひとつだったため。 全てのリクエストの後に、transaction logをfsyncすることで、デフォルトで耐久性を向上 全てのファイル変更をアトミックに（部分的なファイルの書き出しはなし） マージを自動で制限 フレーズクエリやスパンクエリを高速化 フィルタキャッシュをより効率化するための圧縮されたビットセット クラスタ状態の差分更新 構造化されたJSON形式の例外 よりきめ細かいLuceneのメモリレポート デフォルトではlocalhostにのみバインド。開発のノードが他のクラスタにジョインするのを防ぐ parent/childのクエリ実行最適化のためにリライト Java Security Managerで必要最小限なパーミッションで実行 全てのコアなプラグインをelasticsearchリポジトリに移行し、Elasticsearchのバージョンに同期してリリースされる予定 アップグレード前に メジャーバージョンのアップグレードは問題のあるものを一掃する機会を与えてくれます。 できる限り、これらの変更をアップグレードするために、簡単な方法を提供しようとしています。 しかし、Elasticsearch 2.0にアップグレードする前に、必要な処理が2つあります。\n1つ目は、フィールドとタイプマッピングに関することです。 mapping APIは、現在、それほど厳密ではありません。 内蔵された保護機構を提供する代わりに、ユーザがベストプラクティスを知っていると信頼していました。 2.0では、mappingはより厳密で安全ですが、いくつかの変更では、後方互換性を保っていません。 詳細についてはThe Great Mapping Recatoringをごらんください。\n2つ目はElasticsearch 0.20以前のユーザに関する変更です。 これは、Lucene 3.xを使っています。 Elasticsearch 2.xはLucene 5をベースにしています。 Lucene 5はLucene 4.xによって作成されたインデックスの読み込みはサポートしていますが、 Lucene 3.xに関してはサポートしていません。\nElasticsearch 0.20以前のバージョンによって生成されたインデックスを持っている場合、 Elasticsearch 2.xのクラスタをスタートすることはできません。 これらの古いインデックスを削除するか、Elaticsearch 1.6.0以上に含まれている upgrade APIを使用してアップグレードする必要があります。\nupgrade APIの実行は2つのジョブを実行します。\n古いLuceneフォーマットのセグメントを最新のフォーマットで書き換えます Elasticsearch 2.xによって読み込めるようという印をインデックスに追加します 全てのセグメントを最新バージョンにアップグレードするのも良い案ですが、 アップグレード前に必要な処理を最小限に抑えることも可能です。 （Lucene 3.xのセグメントだけをアップグレード） その場合は、only_ancient_segmentsパラメータを指定します。\nElasticsearch Migration Plugin Elasticsearch 2.0 に移行する前に、インデックスがアップグレードが必要なのか、 ほかになにかするべきことがあるのかをチェックする助けになる Elasticsearch Migration Pluginをリリースしました。\nまず、プラグインをインストールします\n./bin/plugin -i elastic/elasticsearch-migration プラグインのインストール後はノードのリスタートは必要ありません。\n以下のリンクをブラウザで開きます。\nhttp://localhost:9200/_plugin/migration\n（localhost:9200はインストールしたホスト名に変更してください。）\nMigration pluginに関してバグやご意見がある場合は、GitHubのIssueにお願いします。\n","date":1436250300,"dir":"post/2015/","id":"f887e1aabf801e351bfb39698f208af1","lang":"ja","lastmod":1436250300,"permalink":"https://blog.johtani.info/blog/2015/07/07/elasticsearch-2-dot-0-0-dot-beta1-coming-soon-ja/","publishdate":"2015-07-07T15:25:00+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0.beta1 coming soon! Elasticsearch 2.0.0.beta1のリリースの準備をしています。","tags":["elasticsearch"],"title":"Elasticsearch 2.0.0.beta1リリース間近（日本語訳）"},{"contents":"4ヶ月前に、Found joined our team at Elasticをアナウンスしました。 Foundの素晴らしいチームと一緒に仕事をしていますが、彼らによって、より素晴らしい hosted Elasticsearchを提供することになりました。\n私たちがともに密接に働くことにより、本日（2015/7/1）、 新しい2つのFoundを提供することになりました。 Found StandardはこれまでのFoundの機能に加え、さらに低価格を提供します。 Found Premiumは、SLAサポートと、ShieldやWatcherを将来Found上で提供します。\nFound Standard Foundは素晴らしいです。専用のElasticsearchクラスタ、簡単なスケール、 ビルトインのセキュリティそして、時間単位での課金などを持っています。 私たちは、hosted Elasticsearchを探している方に、 Foundが適したソリューションであると思っていますし、 すべての方に利用できて手頃な価格であるということを確信したいと思っています。\n本日（2015/07/01）からFoundの価格をかなり低価格にし、 月額50ドル以下でhosted Elasticsearchを簡単に試してもらえるようにしました。\n価格を下げることは正しい重要なステップですが、 Foundを利用している全ての人に、より良い経験を持っていただきたいと考えています。 低価格化と一緒に、free backupsとbuilt in SSDもFoundで提供を始めることになります。\nFoundの重要な特徴の一つが、高可用性のために、クラスタをいくつのデータセンターに持つかを 選択できることです。 データは重要です。これが正しい選択でユーザの助けになると考えています。 これにより、私たちの価格は、複数のデータセンターにより安価に配置することができます。\nまた、KibanaもElasticsearchのデータを可視化する素晴らしい方法だと考えています。 Kibana 4が最新バージョンですが、 これは、サーバサイドコンポーネントを持っています。 これは、サービスとしてこれを提供するために、追加の料金がかかることを意味します。 Foundチームが築いた素晴らしい基盤とKibanaチームの努力により、 hosted Elasticsearchクラスタで無料のKibana 4を7月15日より提供することになりました。\nFound Premium また、私たちは、オープンソースプロダクトに関してサブスクリプションを提供していますが、 Found Standardに対しても提供することになりました。 これが、Found Premiumです。\nフォーラムベースのサポートよりもSLAベースのサポートを望んでいる場合、 プロダクトを開発しているチームからのサポートを受けることができるオプションを 提供し始めました。 クリティカルなイベントを持っていたり、私たちのプロダクトに関する 問題を予測するためのベストなヘルプやガイダンス、アドバイスを探しているような場合にサポートします。\nさらに近い将来、サブスクリプションの一部として、Shield（Elasticasearchのセキュリティプラグイン）やWatcher（アラーティングプラグイン）が利用できるようになります。\n私たちのチームがともに働き、多くのことを可能にし、すばらしい仕事をユーザに提供したかを 将来も楽しみです。 私は非常に誇りに思っていますし、気に入っていただけたらと思っています。 ぜひ、7/15のWebnarに参加してくわしい話を聞いていただき、疑問を解消してください。\n","date":1436250000,"dir":"post/2015/","id":"9cc2a0b6c8be1405cddcdeb4487c59fe","lang":"ja","lastmod":1436250000,"permalink":"https://blog.johtani.info/blog/2015/07/07/we-just-made-found-more-awesome-ja/","publishdate":"2015-07-07T15:20:00+09:00","summary":"4ヶ月前に、Found joined our team at Elasticをアナウンスしました。 Foundの素晴らしいチームと一緒に仕事をしていますが、彼らによって、より","tags":["elasticsearch","found.no"],"title":"さらに進化したFound（日本語訳）"},{"contents":"JustTechTalk#02 形態素解析のあれやこれや@ジャストシステム\nに参加してきました。 ジャストシステムさんの形態素解析器JMATの話とKagome、Janome、Kuromoji.js、ssslaの開発者の パネルディスカッションでした。\nということで、いつものメモです。\nジャストシステムの形態素解析その２（機械学習編） JMATの話\n前回は辞書の話 今回は学習の話 教師あり/教師なし\nJMATは教師あり 教師なしは研究段階 ラティス構造を辞書ベースで構築して、コストの総和が最小の経路を求める\n連接、単語生成とか。 学習は3フェーズ\nベース、能動、部分アノテーション ベース 300万文のコーパスから1万文のみを利用（なぜ？今から説明） 64GBマシン買ってみたけど、複数実験するには追いつかない オンライン学習がメジャーでない時代に作り始めたので、つかってない CRF学習器を改善 結果として50万文くらいで精度が良くなる 辞書チームからNGがでて、方向転換 方向転換した結果が3つのフェーズらしい ピタジョブに採用？ 疑問 \u0008* JMATって、Webの検索の前処理とか分類とかに主に利用するのかな？\nATOKでもこのノウハウって利用してるんかな？ 辞書もあるらしいけど、辞書更新されると学習器のデータとかどーなるんだろ？ 形態素解析器の実装言語Talkについて kuromoji.jsの@takuya_aさん\nTyped Arrayサポートが高速にできてる理由でもあるらしい Kagomeの@ikawahaさん\nGoはいろいろないらしい Janomeの@moco_betaさん\nsssla（茶筌のRuby clone）\nなんで作ったの？\n形態素解析のライブラリ「解析部分」はNLPのHelloWorldだから なんで、その言語？\nPython 3系は文字列とバイト配列の扱いがすごく楽！ その言語で困った点は？\nGoだと、辞書を内包するのが大変 JSは苦労したところしかない（1hくらいしゃべれるぞ！）。基本的なデータ構造とかもない Pythonはパフォーマンスを考えないと Ruby（1.6だったので）もパフォーマンスが その言語を開発するときに必須のものは？\nGoはとくにない。エディタはどれでもOK browserifyが便利 \u0008* ほかの人たちの言語をdisってください * JSは論外。Pythonのコードフォーマッターが揺れるのが。。。Rubyはバージョンが。。。 * Goはブラウザで動かない。Pythonもブラウザで動かない。Rubyも(ry * ほかのは触ったことないので。。。 * Pythonは2.xか3.xか決めてくれ！\nなんで、Kuromojiベースなの？ Java読みやすいから。 MeCabとKuromojiの違いは？ 未知語の処理が結構違う 感想 きれいなロビーで良かったのですが、マイクがあると嬉しかったかもしれません。 前回の辞書の話も聞いてみたかったかも。\n","date":1436147341,"dir":"post/2015/","id":"18b7998a871950ebc36c415a53630477","lang":"ja","lastmod":1436147341,"permalink":"https://blog.johtani.info/blog/2015/07/06/attend-justsystem-techtalk-no2/","publishdate":"2015-07-06T10:49:01+09:00","summary":"JustTechTalk#02 形態素解析のあれやこれや@ジャストシステム に参加してきました。 ジャストシステムさんの形態素解析器JMATの話とKagome、Janome、","tags":["勉強会"],"title":"JustTechTalk#02 形態素解析のあれやこれや@ジャストシステムに参加しました。"},{"contents":"ひさびさに、勉強会メモ。 Hatena Engineer Seminar #5 @ Tokyoに当選したので行ってきました。\nいつもは近寄らないオシャレな街をドキドキしながら行ってきました。\nということで、簡単なメモです。\nはてなブックマーク全文検索の精度改善 id:takuya-a 問題：検索精度がよくない 京都で検索 →　「ポーランドの京都」「京都大学のまるまる教授」のようなもんがヒット 京都っぽいエントリが出て欲しい。 京都っぽい？？？ 問題点をブレイクダウン 課題 クエリ考えるの大変だよね 順序が新着順なのが辛い 適合率と再現率の両立 そして（ドラムロール）、できました！（さすが）\nアイデア：はてブのタグを利用する。 関連キーワードを抽出して、クエリ拡張する。\n関連キーワードとは？ タグ検索する 検索にヒットしたTerm Vectorsを取得 特徴語をTop25件取得 もっともスコアが高いタームを特徴語とする 英語のストップワードとかが問題点となってたり。 →Dynamic stop word listというのを利用して排除（IDF、RIDF、Gain） 今後の課題 再現率の向上 解析用のフィールド・辞書を追加（精度向上や解析ミスなど） トークに出てきた機能など トークに出てきたElasticsearchの機能については、こんなツイートをしてたので、参考にしてもらえれば。\nこれのkuromoji_stemmerを使ってるっぽい？ #hatenatech / elastic/elasticsearch-analysis-kuromoji - https://t.co/3F2sBYXLPH\n\u0026mdash; Jun Ohtani (@johtani) 2015, 6月 16 #hatenatech Term Vectors APIのドキュメントはこちら - https://t.co/HhBmTDr46i\n\u0026mdash; Jun Ohtani (@johtani) 2015, 6月 16 #hatenatech min_score - https://t.co/Sc0exzJRC1\n\u0026mdash; Jun Ohtani (@johtani) 2015, 6月 16 個人的な疑問 Q：クエリにヒットするタグがそもそもなかったら？\nはてなブックマークに基づく関連記事レコメンドエンジンの開発 id:skozawa 課題：一部のエントリに対して関連記事が出ない タグがない記事について関連エントリが出ない＝既存はタグを利用している 例：レシピで考える\n現行システム ユーザがつけたタグ情報を利用してMoreLikeThisで計算 新規システム 類似記事検索 特徴語の抽出 特徴語を分類 関連記事検索 関連記事をスコアリング 個人的な疑問 Q：毎回計算してるのかな？記事登録とかされたタイミングでやってるのかな？ Q：Termの精度などどうなんだろ？\n『BrandSafe はてな』のアドベリフィケーションのしくみ id:tarao BrandSafeはてな：とか。 広告の配信先をフィルタリング\n複数の素朴なフィルタの組み合わせ→AdaBoost\n個人的な疑問 Q：海外とかもいけるのかな？\nまとめと感想 ということで、簡単なメモでした。ピザごちそうさまでした！ 聞いてて少し思ったのは、データ量があるサイトだからうまくいく手法だというのもあるんだろうなというところでした。 あとは、クエリを暗に改善するのとは別に、サジェスト的に表示するのにも使えたりするかも？と思ってみたり。 できるかどうかはわからないですが。。。\nElasticsearchをいろいろと活用してもらってるのがわかって、楽しい勉強会でした。 もっともっといろんなところで宣伝してくださいw\n今日の勉強会を聞いて、俄然、京都・大阪でElasticsearch勉強会を開催したい気になってきました。 特に大阪に知り合いがいないので、だれか紹介してもらえると嬉しいです。 お待ちしてます。\n","date":1434468093,"dir":"post/2015/","id":"ddab6357ff522c0c956ebd7669e83454","lang":"ja","lastmod":1434468093,"permalink":"https://blog.johtani.info/blog/2015/06/17/attend-hatena-engineer-seminar-5/","publishdate":"2015-06-17T00:21:33+09:00","summary":"ひさびさに、勉強会メモ。 Hatena Engineer Seminar #5 @ Tokyoに当選したので行ってきました。 いつもは近寄らないオシャレな街をドキドキしながら行ってきました。 と","tags":["勉強会"],"title":"Hatena Engineer Seminar #5 @ Tokyoに参加しました。 #hatenatech"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.6.0 released\n本日（6/9）、Lucene 4.10.4ベースのElasticsearch 1.6.0をリリースしました。 このリリースはElasticsearchの最新の安定バージョンとなります。 また、素晴らしい新機能がいくつか追加されています。\nsynced flushによるリスタートの高速化 \u0008* シャード配置は保留中のタスクをブロックしない レスポンスボディのJSONのフィルタリング 共有ファイルシステムリポジトリに対するセキュリティフィックス 古いインデックスのためのUpgrade API Kibanaユーザのためのハイライトの強化 Windowsユーザのためのmlockall より詳細なスクリプト設定 すべての変更リストとダウンロードはこちらをごらんください。\nsynced flushによるリスタートの高速化 1.6.0より前のバージョンでは、メンテナンスやローリングアップグレード時の ノードの再起動で、必要であるかどうかに関わらず、多くの場合、 ノードのすべてのシャードのすべてのデータを再度コピーする必要がありました。 この新しいsynced flush機能により、 sync-flushされたインデックスに対して、既存のデータを再利用し、 より早くクラスタを正常な状態にすることができるようにします。\nここで、この変更以前にどのように動いていたかを説明します。 すでにあるレプリカシャードは、ノードがリスタートした後に、 プライマリから復元するときに、 最初のステップはプライマリにあるセグメントとレプリカにあるセグメントを 比較することです。そして、セグメントに違いがあった場合にコピーされます。 問題は、セグメントプライマリのセグメントのマージと レプリカのセグメントのマージが別々に起こっており、 各シャードのセグメントが完全に異なるが、 それらが同じデータを持っているという点です。\n新しいsynced-flush機能では、sync_idがプライマリと レプリカシャードに、シャードのコンテンツが同一であるという判別するために、 書き込まれます。これは、リカバリがセグメントの比較のステップを スキップできることを意味します。 リカバリのスピードを高速にします。\nsynced flushはアイドル状態のインデックスで自動的に実行されます。 直前の5分間でデータが登録、更新削除されていないインデックスに対してです。 これは、ロギングのユースケースで特に役に立ちます。 機能のインデックスはインデキシングがストップしたあとの5分で自動的に syncされるでしょう。\nノードのリスタートやクラスタのリスタートが必要で、 自動的に発生するsyncを待てない場合は次のようなことが可能です。\nインデキシングを停止（実行中のリクエストが停止するのも待つ） シャードのアロケーションを停止 synced-flushリクエストの発行 ノードのリスタート シャードのアロケーションの再開 クラスタの状態がグリーンになるまで待つ インデキシングの再開 NOTE: \u0026ldquo;シャードのアロケーションを停止\u0026quot;のステップが必要です。 これがない場合、Elasticsearchはノードの再起動が始まると、 異なるノードにシャードの再配置を始めます。 これは、新しいノードにシャードデータの全てをコピーする必要があります。\nドキュメントのインデキシング、更新、削除のあとに最初のフラッシュが 発生したときに、 シャードのsync_idが自動的に無効化されます。 詳細については#11336と#11179をごらんください。\nシャード配置は保留中のタスクをブロックしない 多数のノードやインデックスを持っているユーザは クラスタ全体のリスタートのあとのシャードのリカバリで、 長い間、リカバリが止まって見えることに気づいたかもしれません。 これらのリカバリが止まって見える間は、クラスタ設定の更新のような軽微なアクションでさえ、 例外が発生したり、その設定が反映されるまでに長時間かかるといったことが起きていました。 この問題の兆候は保留中のタスクのキューが大きくなることです。\nこれらの遅延の原因はシャードの配置のプロセスにあります。 配置されるべきシャードのコピーを 持っているのがどのノードかを全てのデータノードに聞きます。 多くのシャードや遅いディスクを持ったデータノードは 反応するのに時間がかかります。 特に、シャードのリカバリがすでにI/Oを利用しているような時です。 このバージョン以前のものは、シャード情報のためのリクエストを 同期的に処理していました。 クラスタ状態の更新はアロケーションプロセスを続けるために 必要な情報を待っている間、ブロックされます。\n#11262での変更は この情報のためのリクエストを非同期にします。 クラスタ状態の更新はこのタスクによってブロックされません。 これは、保留中のタスクがより早く処理でき、 クラスタが変更に対してより早く反応できます。 処理中のshard infoリクエストの数は number_of_in_flight_fetchキーとしてcluster-health APIで取得できます。\nさらに、シャードがある理由で復旧に失敗すると、 クラスタは、シャードのリカバリが成功するまで、同じノードに対して シャードをアロケーションしないようにします。\nレスポンスボディのJSONのフィルタリング Elasticsearchは全ての情報を返します。 例えば、検索リクエストは_index、_type、_id、 _score、_sourceを返します。 しかし、全ての情報が必要でない場合があります。 また、これらのデータを遅いネットワークで転送することは 遅延の原因となります。\nユーザはこの検索メタデータを無効にするための特殊な設定を 行ったり、他のAPIのレスポンスのフォーマットを コントロールするための設定があります。 #10980の変更で、任意のレスポンスボディのJSONに対して、 必要な要素だけを取得する機能が追加されました。 filter_pathパラメータを使用します。\n例えば、検索リクエストからはtotal数と、各要素のhitsの配列を欲しい場合、 次のように指定します。\nGET _search?filter_path=hits.total,hits.hits nodes-info APIから各ノードのhttp_addressだけを取得したい場合は、 ノード名の部分にワイルドカード(*)を使用します。\nGET _nodes?filter_path=nodes.*.http_address 単一の*がJSON階層の1つの階層に対しての ワイルドカードとして機能します。 2つの**は複数階層に対してとなります。 複数のフィルタはカンマ区切りで指定可能です。 詳細についてResponse filteringをごらんください。\n共有ファイルシステムリポジトリに対するセキュリティフィックス 本リリースはsnapshot-restoreで使われる 共有ファイルシステムリポジトリに関するセキュリティ強化の変更が含まれます。 現在、Elasticsearchのユーザは、Elasticsearchプロセスによって書き込み可能 任意のディレクトリに.snapshotファイルを書き込むことができます。 #11284の変更で、リポジトリのために使用できるディレクトリを 強制的に指定できるようになりました。 適切なディレクトリがconfig/elasticsearch.yml設定ファイルの path.repoに指定される必要があります。\n次のように設定されたElasticsearchインスタンスはこのセキュリティ問題に対して影響を受けにくいです。\nrootではなくelasticsearchユーザとしてElasticsearchを実行 elasticsearchユーザがdataディレクトリに対してのみ 書き込み権限を持っていて、共有ファイルシステムリポジトリに対しても利用できる ファイアウォールやプロキシ、Shieldを使って、snapshot APIの実行を任意のユーザから実行されるのを防いでいる この問題をCVE-2015-4165としています。\n古いインデックスのためのUpgrade API Elasticsearch 2.0以降では、 Lucene 5ベースとなり、Lucene 3 （Elasticsearchのバージョンでは0.90以前） によって書き出されたセグメントを含んだインデックスを読み込むことが できなくなります。 これらの「古いインデックス」はLucene 4にアップグレードする必要があり、 2.0-compatibleとして印をつける必要があります。 そうしなければ、Elasticsearch 2.0に以降できないでしょう。\nupgrade APIは 、最新のLuceneフォーマットにインデックスにある全てのセグメントを アップグレードするためにすでに利用できます。 また、最新のフォーマットは性能向上やバグフィックスといった利点もあります。 さらに、2.0-compatibleとして古いインデックスをマークする設定も 書き込むことができます。 さらに、upgrade_only_ancient_segmentsオプションが Lucene 3のセグメントだけをアップグレードするために利用でき、 移行前の必要な処理を減らすことができます。\nKibanaユーザのためのハイライトの強化 KibanaユーザはElasticsearchのハイライトについて2つの点で問題を見つけていました。\nワイルドカードでフィールド名を指定した場合に、ハイライトに適さないフィールドも帰ってくる（日付や数値のフィールドなど） 古いインデックスが非常に大きなターム（\u0026gt; 32kB）を含んでいて、ハイライトが失敗する。 最近のバージョンでは、これらの大きなタームはインデックス時に除去される #11364の変更で これらの問題が修正されました。 ワイルドカードを利用したフィールド名では、stringフィールドのみを返し、非常に長いタームによる例外は無視するようになります。\nWindowsユーザのためのmlockall 速いGCはノードの安定性と性能について重要です。 小さなバイトのヒープでさえ、ディスクにスワップすることを許可してしまうと、GCに対して大きな影響が出てしまいます。 ですので、これらのコストは排除されるべきです。\nLinuxユーザはbootstrap.mloclall設定による恩恵を受けています。 これは、RAMにJVMのヒープを起動時にロックします。 #10887では、同様の機能をWindowsユーザにも提供します。\nより詳細なスクリプト設定 Scriptsはリクエストにインラインで指定できます。 .scriptsインデックスにインデックスもでき、config/ディレクトリ配下にファイルとして保存もできます。 これまでは、インラインかインデックスされたスクリプトの両方を同時に有効無効にすることが選択できましたが、 .scriptsインデックスをプロキシやShieldで保護することもできました。\n#10116で追加されたより詳細なスクリプトの設定で、インラインか、インデックスされたものか、ファイル化を個別に言語ごとに設定できるようになりました。 また、例えば、search APIではスクリプトを許可するが、update APIでは許可しないといったような設定も可能です。\n最後に ぜひ、Elasticsearch 1.6.0を試してみてください。 そして、感想をTwitter(@elastic)やWebフォーラムなどで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1433910662,"dir":"post/2015/","id":"55188a318c5998989255253e15ccc1f6","lang":"ja","lastmod":1433910662,"permalink":"https://blog.johtani.info/blog/2015/06/10/elasticsearch-1-6-0-released-ja/","publishdate":"2015-06-10T13:31:02+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.6.0 released 本日（6/9）、Lucene 4.10.4ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 1.6.0リリース（日本語訳）"},{"contents":"第10回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n今回も新規の方が結構いたような気がしました。 最終的に、124人がアプリでチェックインした形になりました。 直前にキャンセル待ちから繰り上がると来れない人がいますよねぇ。 多少キャパシティオーバーするくらいの人数で募集するのがいいのでしょうか。 あと、カードが2枚不明で。。。心あたりある人いないでしょうか？\nさて、いつもの通り簡単なメモです。\nElastic{ON}報告＋有償プラグインの紹介　Elastic Jun Ohtani @johtani スライド：elastic{ON}報告と商用プラグインの紹介\n少し時間が経ってしまいましたが、弊社初のカンファレンスelastic{ON}の紹介をしました。 約1300名の方に参加していただいたカンファレンスで、非常に盛り上がりました。 Microsoft、GitHubなど、いろいろな会社の方が話をしたり、弊社のエンジニアが濃い話をしたりと。 今回は、日本の方はいなかったですが、次回は日本からも参加してもらえると嬉しいです！\nあとは、5月に弊社にも日本の営業の人が入社したので、有償プラグインについて簡単ですが説明をしました。 プラグインなどに興味があるかたがいらっしゃいましたら、Twitterなどで連絡いただければと。 もちろん、弊社サイトからの問い合わせでも大丈夫です。\nカンファレンスの資料やビデオが弊社サイトで公開されています。 ぜひ一度見ていただければと。\nAWSで実現するelasticsearchの大規模運用 株式会社インティメート・マージャー　松田和樹さん　@mats116 スライド：第10回elasticsearch勉強会 公開用資料\nパブリックDMPのサービスの裏側でElasticsearchを利用しているというお話でした。 AWS Auto Scalingに詳しくないので、勉強しないといけないんですが、 リバランスがどのくらいの頻度で発生するのかはちょっと気になります。\nSSDを利用したり、doc valuesを利用したりと、性能を気にしながら利用されている点、負荷試験を行って検証されていたりと、 参考になる話でした。 今回はインフラ側の話に寄っていたので、今度はアプリ側でどんな使い方をしているかといった話を聞いてみたいですね！\nSpark in small or middle scale data processing with Elasticsearch　株式会社ビズリーチ 島本　多可子さん @chibochibo03 スライド：Spark in small or middle scale data processing with Elasticsearch\nScalaとSparkとElasticsearchで検索サービスを作っている話でした。 サービスのアーキテクチャの選別についての説明を順を追って説明していただきました。 失敗と言われていたアーキテクチャを見た時に、「あー、それは。。。」と思っていたら、 思った通りの改善案のアーキテクチャが出てきたので少しホッとしましたw\nJSONのクエリが辛いという話がありましたが、validate APIなどを利用してもらって、事前にチェックをしてもらうと 少しは改善できるかもなぁと。\nSparkをぼんやりとしかわかってないので、もう一度話を聴きたいなぁと思ったので、 押しかけて話を聴きたいと思います。\n話の中で出てきた自作のScalaのElasticsearchクライアントがHTTPのクライアントになった理由が知りたかったです。\nLT Elasticsearchのサジェスト機能を使った話　株式会社アイスタイル　渡邊 紘太朗さん @ktaro_w スライド：Elasticsearchのサジェスト機能を使った話\nぴったり5分でしたwまだ2年目なのにこんなにうまく話をしていただけるとは。。。\nGatling便利そうですね。サーバが1台しかないので、単一インデックスの方が性能が出るだろうなと。 Elasticsearchは1インデックスに対してデフォルトだと5シャードで、シャード単位でLuceneのインデックスが作成されます。 この話で行くと、18インデックスを作ると、かなりの数のファイルI/Oが発生するので、いろいろなインデックスに検索をすると キツいだろうなと。\nサジェストについての日本語の資料が少ないという事だったので、ブログを書いてもらえると嬉しいですw\nElasticsearchで作る形態素解析サーバ　株式会社エヌツーエスエム　菅谷信介さん スライド：Elasticsearchで作る形態素解析サーバ\nいつも発表ありがとうございます。私以外の最多発表者じゃないかという話でした。 今回はElasticsearchを形態素解析サーバにしてしまおうという話で、ちょっと面白い話でした。 Elasticsearch以外の場所で形態素解析したい場合には手軽に使えるかもしれないですし、Elasticsearchと同じ解析結果を別の場所で欲しい場合にも便利かも。\nextended analyze APIの紹介までしていただいて。。。\nちなみに、今は、extended analyze プラグインも指定したAttributeの情報だけ返せるようになってたり、 マルチバリューへの対応もしていたりします。 そのうち本家のanalyze APIに機能を取り込む予定です。（早くしないと）\n開発効率UP! Elasticsearch Client Tool 作ってみた　ナレッジワークス株式会社　木戸国彦さん @9215 スライド：開発効率アップ!Elasticsearch Client Tool 作ってみた\nHello Elasticsearch!にはお世話になっている人が多いんじゃないかなと。 今回はSublime Textのプラグインのお話でした。（すみません、Sublime Text使ってなくて。。。） AtomとかIntellijのプラグインもあるとうれしいなー\n変わり種プラグインの作り方　日本IBM　黒澤亮二さん スライド：変わり種プラグインの作り方\nElasticsearchの拡張ポイントの話と、簡単なプラグインの作り方と少しElasticsearch内部の話をしていただきました。 Foundの資料が上がってました。さすが。あそこのブログは面白い話が多いんですよね。 社内で実際に使われてる話とかも聞いてみたい！\nその他、感想などのブログ 第10回 Elasticsearch 勉強会へ参加してきた昨日の話 第10回elasticsearch勉強会 #elasticsearch #elasticsearchjp 第10回elasticsearch勉強会に行ってきました elasticsearch勉強会に登壇してきました まとめ 懇親会で24Fに移動していただくということで、少し手間をかけてしまいました、すみませんでした。 今回も初参加の方がそこそこいたんじゃないかなと。 あとは、AWSサミットがあるために上京してて参加しましたという方もいらっしゃいました。 大きなカンファレンスの期間の前後に行うとこんなメリットもあるんですね、今後の参考にしたいと思います。 次回は7/27を予定しています。CTOのShayが来日予定です！\nあと、東京以外の勉強会も検討しつつあります。興味のある方はコメントやTwitterで反応をいただけると嬉しいです。\nスピーカーは随時募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1433225196,"dir":"post/2015/","id":"75d9268739fe7787ac02d389ac605feb","lang":"ja","lastmod":1433225196,"permalink":"https://blog.johtani.info/blog/2015/06/02/10th-elasticsearch-jp/","publishdate":"2015-06-02T15:06:36+09:00","summary":"第10回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさ","tags":["elasticsearch","勉強会"],"title":"第10回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Reindex Elasticsearch With Logstash\nThanks David!\nマッピングを変更したり、インデックスの設定を変更したり、あるサーバから他のサーバや、 あるクラスタから他のクラスタ（例えば複数のデータセンターのような場合）にデータを再インデックスしたくなることがあるでしょう。\n後者のような場合はSnapshotやRestoreの機能を利用することもできますが、インデックスの設定を変更をしたい場合は その他の方法が必要になります。\nLogstash 1.5.0で、 elasticsearch inputとelasticsearch outputを使うことで、とても簡単に再インデックスができます。\nではやってみましょう。\n古いクラスタ elasticsearch 1.5.2 はすでにダウンロード済みとして、localhost:9200でoldという名前のクラスタを起動します。\nbin/elasticsearch --cluster.name=old クラスタにpersonという名前のインデックスが存在します。 これは、5シャードで、100万件のドキュメントを持っています。\n新しいクラスタ 次に新しいクラスタを起動します。 localhost:9201でnewという名前のクラスタを起動します。\nbin/elasticsearch --cluster.name=new こちらは、空です。\ncurl -XGET \u0026#34;http://localhost:9201/person\u0026#34; { \u0026#34;error\u0026#34;: \u0026#34;IndexMissingException[[person] missing]\u0026#34;, \u0026#34;status\u0026#34;: 404 } Logstashのインストール 次に、Logstash 1.5.0をダウンロードして、インストールします。\nwget http://download.elastic.co/logstash/logstash/logstash-1.5.0.tar.gz tar xzf logstash-1.5.0.tar.gz cd logstash-1.5.0 logstashの設定ファイルlogstash.confを次のように設定します。\ninput { # We read from the \u0026#34;old\u0026#34; cluster elasticsearch { hosts =\u0026gt; [ \u0026#34;localhost\u0026#34; ] port =\u0026gt; \u0026#34;9200\u0026#34; index =\u0026gt; \u0026#34;person\u0026#34; size =\u0026gt; 500 scroll =\u0026gt; \u0026#34;5m\u0026#34; docinfo =\u0026gt; true } } output { # We write to the \u0026#34;new\u0026#34; cluster elasticsearch { host =\u0026gt; \u0026#34;localhost\u0026#34; port =\u0026gt; \u0026#34;9201\u0026#34; protocol =\u0026gt; \u0026#34;http\u0026#34; index =\u0026gt; \u0026#34;%{[@metadata][_index]}\u0026#34; index_type =\u0026gt; \u0026#34;%{[@metadata][_type]}\u0026#34; document_id =\u0026gt; \u0026#34;%{[@metadata][_id]}\u0026#34; } # We print dots to see it in action stdout { codec =\u0026gt; \u0026#34;dots\u0026#34; } } 実行と修正 実行します。\nbin/logstash -f logstash.conf ドキュメントのチェックと修正 何が起きたでしょう？\ncurl -XGET \u0026#34;http://localhost:9200/person/person/AU1wqyQWZJKU8OibfxgH\u0026#34; { \u0026#34;_index\u0026#34;: \u0026#34;person\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;person\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;AU1wqyQWZJKU8OibfxgH\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;Tali Elyne\u0026#34;, \u0026#34;dateOfBirth\u0026#34;: \u0026#34;1955-05-03\u0026#34;, \u0026#34;gender\u0026#34;: \u0026#34;female\u0026#34;, \u0026#34;children\u0026#34;: 2, \u0026#34;marketing\u0026#34;: { \u0026#34;cars\u0026#34;: null, \u0026#34;shoes\u0026#34;: null, \u0026#34;toys\u0026#34;: null, \u0026#34;fashion\u0026#34;: null, \u0026#34;music\u0026#34;: null, \u0026#34;garden\u0026#34;: null, \u0026#34;electronic\u0026#34;: null, \u0026#34;hifi\u0026#34;: null, \u0026#34;food\u0026#34;: 846 }, \u0026#34;address\u0026#34;: { \u0026#34;country\u0026#34;: \u0026#34;Germany\u0026#34;, \u0026#34;zipcode\u0026#34;: \u0026#34;0099\u0026#34;, \u0026#34;city\u0026#34;: \u0026#34;Bonn\u0026#34;, \u0026#34;countrycode\u0026#34;: \u0026#34;DE\u0026#34;, \u0026#34;location\u0026#34;: [ 7.075943707068682, 50.72883500730124 ] } } } もう一方のクラスタと比較してみましょう。\ncurl -XGET \u0026#34;http://localhost:9201/person/person/AU1wqyQWZJKU8OibfxgH\u0026#34; { \u0026#34;_index\u0026#34;: \u0026#34;person\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;person\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;AU1wqyQWZJKU8OibfxgH\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;Tali Elyne\u0026#34;, \u0026#34;dateOfBirth\u0026#34;: \u0026#34;1955-05-03\u0026#34;, \u0026#34;gender\u0026#34;: \u0026#34;female\u0026#34;, \u0026#34;children\u0026#34;: 2, \u0026#34;marketing\u0026#34;: { \u0026#34;cars\u0026#34;: null, \u0026#34;shoes\u0026#34;: null, \u0026#34;toys\u0026#34;: null, \u0026#34;fashion\u0026#34;: null, \u0026#34;music\u0026#34;: null, \u0026#34;garden\u0026#34;: null, \u0026#34;electronic\u0026#34;: null, \u0026#34;hifi\u0026#34;: null, \u0026#34;food\u0026#34;: 846 }, \u0026#34;address\u0026#34;: { \u0026#34;country\u0026#34;: \u0026#34;Germany\u0026#34;, \u0026#34;zipcode\u0026#34;: \u0026#34;0099\u0026#34;, \u0026#34;city\u0026#34;: \u0026#34;Bonn\u0026#34;, \u0026#34;countrycode\u0026#34;: \u0026#34;DE\u0026#34;, \u0026#34;location\u0026#34;: [ 7.075943707068682, 50.72883500730124 ] }, \u0026#34;@version\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;@timestamp\u0026#34;: \u0026#34;2015-05-20T09:53:44.089Z\u0026#34; } } Logstashは@versionと@timestampフィールドを追加してしました。 これらを除去したいので、Mutate filter pluginのremove_fieldを使います。\nfilter { mutate { remove_field =\u0026gt; [ \u0026#34;@timestamp\u0026#34;, \u0026#34;@version\u0026#34; ] } } マッピングのチェックと修正 実際に、logstashは_sourceフィールドを既存のドキュメントから読み込み、 それらを新しいクラスタに直接投入しています。 しかし、logstashはマッピングについてはケアしていません。\n古いマッピングと新しいマッピングを比較するために、マッピングを取得してみましょう。\ncurl -XGET \u0026#34;http://localhost:9200/person/person/_mapping\u0026#34; { \u0026#34;person\u0026#34;: { \u0026#34;mappings\u0026#34;: { \u0026#34;person\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;address\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;city\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;country\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;countrycode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;location\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;geo_point\u0026#34; }, \u0026#34;zipcode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;children\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;dateOfBirth\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;date\u0026#34;, \u0026#34;format\u0026#34;: \u0026#34;dateOptionalTime\u0026#34; }, \u0026#34;gender\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;marketing\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;cars\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;electronic\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;fashion\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;food\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;garden\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;hifi\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;music\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;shoes\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;toys\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; } } }, \u0026#34;name\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } } } } curl -XGET \u0026#34;http://localhost:9201/person/person/_mapping\u0026#34; { \u0026#34;person\u0026#34;: { \u0026#34;mappings\u0026#34;: { \u0026#34;person\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;address\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;city\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;country\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;countrycode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;location\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;double\u0026#34; }, \u0026#34;zipcode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;children\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;dateOfBirth\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;date\u0026#34;, \u0026#34;format\u0026#34;: \u0026#34;dateOptionalTime\u0026#34; }, \u0026#34;gender\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;marketing\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;cars\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;electronic\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;fashion\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;food\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;garden\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;hifi\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;music\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;shoes\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;toys\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; } } }, \u0026#34;name\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } } } } これにより、いくつかの相違を発見できます。\n\u0026#34;location\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;geo_point\u0026#34; } \u0026#34;location\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;double\u0026#34; } データをインデックスする「前」に、実際に利用したいマッピングでインデックスを作成しておくことで、 この問題に対処できます。 この時点で、オリジナルのマッピングを望んだ形に変更することができます。例えば、アナライザを変更したりです。 また、インデックスの設定を新しく定義することもできます。 デフォルトでは、Elasticsearchは5つのシャードと各シャードに対して1つのレプリカを作成します。 しかし、この時点でもう一度変更することが可能です。\ncurl -XDELETE \u0026#34;http://localhost:9201/person\u0026#34; curl -XPUT \u0026#34;http://localhost:9201/person\u0026#34; -d\u0026#39; { \u0026#34;settings\u0026#34;: { \u0026#34;number_of_shards\u0026#34;: 1, \u0026#34;number_of_replicas\u0026#34;: 0 } }\u0026#39; curl -XPUT \u0026#34;http://localhost:9201/person/person/_mapping\u0026#34; -d\u0026#39; { \u0026#34;person\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;address\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;city\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;country\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;countrycode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;location\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;geo_point\u0026#34; }, \u0026#34;zipcode\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;children\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;dateOfBirth\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;date\u0026#34;, \u0026#34;format\u0026#34;: \u0026#34;dateOptionalTime\u0026#34; }, \u0026#34;gender\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34; }, \u0026#34;marketing\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;cars\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;electronic\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;fashion\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;food\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;garden\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;hifi\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;music\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;shoes\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;toys\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; } } }, \u0026#34;name\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } }\u0026#39; さて、もう一度再インデックスしましょう！\nbin/logstash -f logstash.conf インデックスやタイプ名の変更 もちろん、インデックス名やタイプ名、IDを変更したい場合も変更が可能です！:)\nelasticsearch { host =\u0026gt; \u0026#34;localhost\u0026#34; port =\u0026gt; \u0026#34;9201\u0026#34; protocol =\u0026gt; \u0026#34;http\u0026#34; index =\u0026gt; \u0026#34;europe_people\u0026#34; index_type =\u0026gt; \u0026#34;someone\u0026#34; document_id =\u0026gt; \u0026#34;%{[@metadata][_id]}\u0026#34; } ","date":1432624090,"dir":"post/2015/","id":"23a22d1411afb787810d68210e6fad4f","lang":"ja","lastmod":1432624090,"permalink":"https://blog.johtani.info/blog/2015/05/26/reindex-elasticsearch-with-logstash-ja/","publishdate":"2015-05-26T16:08:10+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Reindex Elasticsearch With Logstash Thanks David! マッピングを変更したり、インデックスの設定を変更したり、あるサ","tags":["logstash","elasticsearch"],"title":"Logstashを使ったElasticsearchの再インデックス（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Join the Conversation: Discuss.Elastic.Co\n3つのOSSプロジェクトの開発をスケールアップし始め、 コミュニティサポートのために必要なやりとりに対してメーリングリストでは難しいということがわかってきました。 私たちは複数のメーリングリストを持っています。Elasticsearch、Logstash、そして英語以外の様々な言語のメーリングリストです。 このような状況では、あたらしい人たちはどこで質問をするのが良いのか混乱します。\nまた、メーリングリストの流量が増え、「参考になる話題」を見つけるのが難しくなってきました。 様々なユーザに採用してもらい、様々なユースケースが出てくることで、様々な質問が出てきています。 汎用的なメーリングリストではノイズの中から望んだ情報を見つけるのは難しいです。 また、ユーザ全てがメーリングリスト満足しているわけではありません。\nElasticは、ユーザの問題を解くことが大好きです。 コミュニティのメンバー皆さんに気に入っていただけるであろうソリューションを見つけ、フォーラムを https://discuss.elastic.co に移すことにしました。 ぜひ参加して、この新しいツールについてのご意見を聞かせてください。\nメーリングリストは好きだけど、ウェブフォーラムは苦手？問題ありません。 フォーラムにユーザプロファイル（GitHub、Facebook、Twitter、Google Appsのアカウントと連携するか、emailアドレスを利用すれば簡単に作れます）を作り、 email通知の設定をすればOKです。 これで、emailでのやりとりができるようになります。\n利用して、議論を楽しんでください。 もちろん、改善案などにかんするご意見もお待ちしています！\n","date":1432197903,"dir":"post/2015/","id":"615db1a24f36d19a8eaf18d4dceed6b2","lang":"ja","lastmod":1432197903,"permalink":"https://blog.johtani.info/blog/2015/05/21/join-the-conversation-ja/","publishdate":"2015-05-21T17:45:03+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Join the Conversation: Discuss.Elastic.Co 3つのOSSプロジェクトの開発をスケールアップし始め、 コミュニティサポー","title":"discuss.elastic.co にぜひ参加を"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.5.2 Released\n本日（4/27）、Lucene 4.10.4ベースのElasticsearch 1.5.1およびElasticsearch 1.4.5 をセキュリティバグフィックス版をリリースしました。 ダウンロードおよびすべての変更については次のリンクをごらんください。\n最新安定版：Elasticsearch 1.5.2 1.4系バグフィックス：Elasticsearch 1.4.5 本リリースはディレクトリトラバーサルの脆弱性のフィックスです。すべてのユーザにアップグレードを勧めます。\n過去のリリースに関するブログは以下のリンクを参照してください。\n1.5:1.4.1, 1.5.0 1.4:1.4.4,1.4.3, 1.4.2,1.4.1, 1.4.0, 1.4.0.Beta1 すべての1.5.2および1.4.5の変更についてはリンクをごらんください。以下では、セキュリティの問題について紹介します。\nディレクトリトラバーサル脆弱性の発見 1.5.2および1.4.5以前の全バージョンのElasticsearchで、ディレクトリトラバーサル攻撃に対する脆弱性がみつかりました。 攻撃者はElasticsearchを実行しているサーバからファイルを取得することができます。 この脆弱性はインストールしたばかりのElasticsearchには存在しません。 この脆弱性は\u0026quot;site plugin\u0026quot;がインストールされると露呈します。 ElasticのMarvelプラグインおよびコミュニティサポートの多くのプラグイン（例：Kopf、BigDesk、Head）がsite pluginです。 Elastic Shield、Licensing、Cloud-AWS、Cloud-GCE、Cloud-Azure、analysis pluginおよびriverプラグインはsite pluginではありません。\nこの問題をCVE-2015-3337としました。\nバージョン1.5.2と1.4.5はこの脆弱性に対して対策済みで、私たちはすべてのユーザにアップグレードを勧めています。\nアップグレードを望まないユーザはいくつかの方法でこの脆弱性に対して対応可能ですが、これらの方法はsite pluginを動作させなくします。\nsite pluginをインストールしているノードのelasticsearch.ymlのhttp.disable_sitesをtrueに設定し、Elasticsearchのノードを再起動 ファイアウォールもしくはプロキシを利用して、/_pluginへのHTTPリクエストをブロック すべてのsite pluginをすべてのElasticsearchノードからアンインストール この問題を報告していただいた、DocuSignのJohn Heasmanに感謝いたします。\n他の変更について インデックスされたスクリプトおよびテンプレートを上書きもしくは削除時に、キャッシュからも完全に削除する。 geo-shapeの多数のフィックス（distance_error_pctを利用した場合の、重要なprecisionに関するフィックスを含む） インデックステンプレートのデフォルトマッピングがバルクインデキシング中にも考慮するように修正 Shadowレプリカがファイルシステムの遅延に対する対障害性を向上し、プライマリシャードのよりスムーズなリロケーションをサポート geo-contextsをcompletion suggesterで使用した場合のマッピングのリフレッシュループを改善 いくつかの重要な変更がv1.4.5にバックポートされています。\n大きなシャードのリカバリを早くするためのシャードリカバリ中のマージを可能に \u0008* truncated translogsの操作をグレースフルに マージが遅くなる場合に、delete-by-queryを減速 ぜひ、Elasticsearch 1.5.2をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1430201648,"dir":"post/2015/","id":"8d7caf84b3a51cca27291c1f7cfc2d40","lang":"ja","lastmod":1430201648,"permalink":"https://blog.johtani.info/blog/2015/04/28/elasticsearch-1-5-2-and-1-4-5-released-ja/","publishdate":"2015-04-28T15:14:08+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.2 Released 本日（4/27）、Lucene 4.10.4ベースのEla","tags":["elasticsearch"],"title":"Elasticsearch 1.5.2 および 1.4.5リリース（日本語訳）"},{"contents":"第9回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n今回はトレーニングで来日していたIgorとNathanによる特別公演でした。 昨年同様、サムライズムの@yusukeさんに テキスト翻訳していただき、大変助かりました。ほんとうにすごかった。。。\nチェックイン数など 今回はチェックインした人：119名 キャンセルしなかった人：45名 でした。今回はキャンセル待ちのまま当日を迎えた人もいなかったので良かったかなと。 今回から懇親会ページを別にしてみました。本編の勉強会に参加登録していた方には何度かメールを出していたので、 見つけていなかった人は以内とは思うのですが、勉強会のページと間違える人がいたらしいという話を聞きました。 Doorkeeperで1イベントで複数のチケットにそれぞれの参加者数を設定できるようになると嬉しいかもなぁ。\nさて、いつもの通り簡単なメモです。 本当に簡単にですが。\nResiliency in Elasticsearch and Lucene / Igor Motov スライド：https://speakerdeck.com/elastic/resiliency-in-elasticsearch-and-lucene\n※上記スライドは少し古いバージョンです。公開されたら差し替える予定です。\nサンフランシスコで行われたElastic{ON}（弊社初のカンファレンス）で行われたセッションの 改良版といったところでしょうか。 話の中で登場した機能などのリンクをざっとアップしておきます。\nFielddata Doc Values Resiliency Status Kibana4: What\u0026rsquo;s New ? / Nathan Zamecnik スライド：未定\nKibana4の紹介をデモを交えてという感じでした。 こちらは、スライドよりもデモを見てもらうのが一番いいのですが。。。\nいくつかQAがあったので補足を。ちなみに、Issueのラベルに実装される予定のバージョンが付与されてたりします。\nQ：グラフをPDFでエクスポートとかできますか？ A：4.3.0で実装される予定です。関連Issueはこちら。https://github.com/elastic/kibana/issues/509 Q：巨大な数値の場合にKB、MBなどといった表示は可能ですか？ A：4.1.0で実装される予定です。関連Issueはこちら。https://github.com/elastic/kibana/issues/1543 Q：地図のズームを固定することはできますか？ A：4.1.0で実装される予定です。関連Issueはこちら。https://github.com/elastic/kibana/issues/1442 その他、感想などのブログ [Elasticsearch] 第9回 Elasticsearch 勉強会へ参加してきた まとめ 今回は特別バージョンでした。かなり詳しい話だったので面白かったと思います。 Kibanaはデモを見ていただけましたし。また、海外から人を呼べるといいなぁ。\n次回は6月ごろをめどに計画しようかと。 スピーカーは随時募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1429249314,"dir":"post/2015/","id":"7249710187cc2d983709e044dbc78d9d","lang":"ja","lastmod":1429249314,"permalink":"https://blog.johtani.info/blog/2015/04/17/9th-elasticsearch-jp/","publishdate":"2015-04-17T14:41:54+09:00","summary":"第9回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第9回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.5.1 Released\n本日（4/9）、Lucene 4.10.4ベースのElasticsearch 1.5.1 をリリースしました。 このリリースはElasticsearchの最新の安定バージョンとなります。\nすべての変更についてはdownload Elasticsearch 1.5.1 hereをごらんください。\n本リリースはシャードを新しいノードに配置するスピードを改善するためのバグフィックスを含んでいます。 シャードのリカバリーの最初のフェーズで、コピー元のノードからコピー先のノードへすべてのセグメントをコピーします。 このフェーズ中には登録、更新削除のリクエストはトランザクションログに記録され、リカバリが終了したあとに コピー先のノードでトランザクションログが再生されます。 シャードが大きい場合、トランザクションログに多数のイベントがたまってしまいます。\n以前では、新しいセグメントのマージはリカバリ中のコピー先のノードでは、実行できませんでした。 大きなトランザクションログは結果として、小さな新しいセグメントを多く生成し、リカバリのスピードに非常に影響を与えます。 Issue #10463は リカバリ中のコピー先のシャードのマージを可能にする変更です。\nその他の注目すべきバグフィックスは次のものになります。\n多くの削除によりバージョンマップがいっぱいになった場合にrefreshを実行するように変更(#10312) 多数のスナップショットを含んだリポジトリの管理の改善(#10366) 実験的な機能であるinner hitsのバグフィックス(#10388, #10353, #10309, #10235) 最後に、Riverが非推奨となりました、まだ見ていない場合は記事をご覧ください。\nぜひ、Elasticsearch 1.5.1をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1428892471,"dir":"post/2015/","id":"563864a949924c505985a168191dcb84","lang":"ja","lastmod":1428892471,"permalink":"https://blog.johtani.info/blog/2015/04/13/elasticsearch-1-5-1-released-ja/","publishdate":"2015-04-13T11:34:31+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.1 Released 本日（4/9）、Lucene 4.10.4ベースのElas","tags":["elasticsearch"],"title":"Elasticsearch 1.5.1リリース（日本語訳）"},{"contents":"Elasticsearch勉強会 in 名古屋を開催しました。 初の東京以外での勉強会です。 企画、セッションなどお手伝いいただいた@smogamiさん、@mzpさんありがとうございました！\nElasticsearch/ELK stack紹介 @johtani スライド：Introduction Elasticsearch\n初回（次回があるかはわかりませんが。。。）ということもあり、Elasticsearchの説明を行いました。 あと、LogstashとKibanaも。 Kibanaについては、手元の環境でいつものアクセスログのデモやなどを行いました。 また、LTの後に時間があったので、前回の勉強会で利用したチェックリストの説明なども。\nスタンドファームにおけるElasticsearch導入事例 @mzp さん スライド：後日アップ？\n\u0008* 使ってるのはKibana3\nアクセスログが保存されてたけど、活用できてなかった。 Fluentd、Elasticsearch、Kibanaをいれて、可視化してみた。 普通にログ検索が簡単にできて嬉しい システムのレスポンスの性能値などを可視化できるようにして性能改善中 Kibanaでログ分析を1年続けてみたら業務システムの保守と運用が捗った(仮) @smogami さん スライド：「Kibanaでログ分析を1年続けてみたら業務システムの保守と運用が捗った」\n名古屋でJavaの勉強会を主催してみたり（最近できてないけど） 導入するのになかなか大変だった（ファイアウォールだったりが）。。。 Kibanaを使ってどんなことをしてるのか？\n既存システムなどの機能の実行回数やレスポンス時間の推移 曜日ごとにもチェック どの機能がよく使われるのか？ 対象となっているシステムはJavaのシステム。 QA\nQ：ログの出力は新規に追加したのか？ A : ログの出力自体はLog4Jの設定を変更しただけ。もともと、各メソッドの開始と終了にそれぞれ時間が出力される仕組みがある。\nログの読み込み自体は自作ツールを利用。 飛び込みLT @dabits さん スライド：未定\nKibanaの使い道\nKPIツール エゴサーチツール - Twitterや2chなどのデータを解析ソーシャル分析みたいな感じ？ \u0008* ダッシュボードを用意してあげる場合もあるが、触っていろんな機能を試す人も。 感想・反省点など 30名弱の方に参加していただきました。ありがとうございました。 東京の勉強会でもそうですが、半分くらいが検索、半分くらいがログ解析関連に興味がある感じでした。 飛び込みLTもしていただけましたし。会場内限定の話もいくつか。\n場所 場所が少しわかりにくかったかなと。。。建物の入り口に看板がないので、1名に看板役として立っていただきました。 ただ、設備は充実していましたし、室内も綺麗でよかったです。\n懇親会 11名（+私）でした。美味しい手羽先などをいただきながら、Elasticsearch以外のことでも盛り上がりましたw。 また、名古屋の観光名所なども教えてもらったりと有意義な時間でしたw。\nということで、少しでもElasticsearch、Kibana、Logstashなどのユーザが増えてくれればうれしいかなと。 私抜きでも勉強会はできると思うので、今後も開いてもらえるとうれしいかぎりです。 初めての東京以外での勉強会でどんな感じの方が利用しているのか、興味があるのかといったことも知ることができました。\n関連ブログなど Kibana4活用事例を話しました その他（余談） コンパルという喫茶店のアイスコーヒー。ちょっと新鮮な体験でした。 あとは、日曜日に観光場所として教えてもらった、トヨタ産業技術記念館にも行ってみました。 一人だったけど、非常に楽しめました。実演とかあって、わかりやすいし。 トヨタが自動織機の会社が始まりだってのは知らなかった。\n","date":1428108439,"dir":"post/2015/","id":"24357fe145c869ec82fdfc8134a1a6d1","lang":"ja","lastmod":1428108439,"permalink":"https://blog.johtani.info/blog/2015/04/04/elasticsearch-study-session-at-nagoya/","publishdate":"2015-04-04T09:47:19+09:00","summary":"Elasticsearch勉強会 in 名古屋を開催しました。 初の東京以外での勉強会です。 企画、セッションなどお手伝いいただいた@smogamiさ","tags":["elasticsearch","勉強会"],"title":"Elasticsearch勉強会 in 名古屋を開催しました。#elasticsearch #elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：Elasticsearch 1.5.0 Released\n本日（3/23）、Lucene 4.10.4ベースのElasticsearch 1.5.0 をリリースしました。 このリリースはElasticsearchの最新の安定バージョンとなります。 多くのresiliency(復元性、弾力性) enhancementとバグフィックスを含んでおり、 すべてのユーザにアップグレードを推奨しています。\nすべての変更についてはdownload Elasticsearch 1.5.0 hereをごらんください。\n460PRという大量の変更を含む本リリースは、Elasticsearchをよりresilient(弾力のあるもの)にするために 費やされています。\nInner hits 本リリースで追加された、Elasticsearchに最もリクエストされたものの一つがinner hitsです。 これは、has_childもしくはnestedクエリにマッチした子のドキュメントを、各親ドキュメントと一緒に返すことができます。\n例えば、blogという親ドキュメントとcommentという子ドキュメントを持っているとします。 この時、\u0026ldquo;full text search\u0026quot;というコメントを持ったブログ記事を検索したいとします。\nGET /my_index/blog/_search { \u0026#34;query\u0026#34;: { \u0026#34;has_child\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;comment\u0026#34;, \u0026#34;score_mode\u0026#34;: \u0026#34;sum\u0026#34;, \u0026#34;query\u0026#34;: { \u0026#34;match\u0026#34;: { \u0026#34;body\u0026#34;: \u0026#34;full text search\u0026#34; } } } } } 上記のリクエストは、親のblogドキュメントを返します。 しかし、どのコメントが関係しているのかはわかりません。 関連しているコメントを検索して親ごとにグルーピングするために、 少し手間のかかる2回目のクエリを実行する必要があります。\nInner hitsがこれを変えてくれます。 inner_hitsパラメータを次のように、上記のクエリに追加するだけです！\nGET /my_index/blog/_search { \u0026#34;query\u0026#34;: { \u0026#34;has_child\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;comment\u0026#34;, \u0026#34;score_mode\u0026#34;: \u0026#34;sum\u0026#34;, \u0026#34;query\u0026#34;: { \u0026#34;match\u0026#34;: { \u0026#34;body\u0026#34;: \u0026#34;full text search\u0026#34; } }, \u0026#34;inner_hits\u0026#34;: {} } } } 検索結果の各blog記事に、inner_hitsという項目があり、そこに検索にヒットしたコメントの 上位3件（デフォルト値）が返ってきます。\n... \u0026#34;hits\u0026#34;: [ { \u0026#34;_index\u0026#34;: \u0026#34;my_index\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;blog\u0026#34;, \u0026#34;_id\u0026#34;: 1, \u0026#34;_score\u0026#34;: 3.68, \u0026#34;_source\u0026#34;: { ... }, \u0026#34;inner_hits\u0026#34;: { \u0026#34;comment\u0026#34;: { \u0026#34;total\u0026#34;: 16, \u0026#34;hits\u0026#34;: [ { \u0026#34;_type\u0026#34;: \u0026#34;comment\u0026#34;, \u0026#34;_id\u0026#34;: 5, \u0026#34;_score\u0026#34;: 2.79, \u0026#34;_source\u0026#34;: { \u0026#34;body\u0026#34;: \u0026#34;Full text search is the bomb\u0026#34; } }, { ... }, { ... } ] } } } ] ... inner_hits部分は、第2の検索リクエストに似ています。 sizeやfromパラメータを含めるくことで、挙動をカスタマイズできます。 また、検索から想像するであろう、ページネーション、ソート、ハイライト、_sourceフィルタリングなどといった機能もサポートします。\nInner hitsはparent-childおよび、nestedドキュメントをサポートします。 この機能は、現時点ではexperimentalラベルが付与されています。 このラベルは、この機能が将来変更されたり、削除されたりする可能性があるかもしれないことを意味します。 詳細については、Inner Hits documentationをごらんください。\nShadow replicas Elasticsearchはそれ自身の冗長性に常に気をつけています。 それは、レプリカシャード（各プライマリシャードの冗長なコピー）を持っています。 これは、プライマリシャードを失った時に、データをロスしないようにするためのものです。 レプリカシャードはまた、検索のスループットをスケールアウトするためにも利用できます。 多くのレプリカ（ノードを伴うことで。）はスループットを増加させます。\nしかし、ユーザによってはElsticsearchを分散ファイルシステム上でホスティングしており、すでに、 ファイルシステムがレプリケーションと冗長性を担当しています。 ファイルシステムが同じことしているので、各シャードのコピーを複数持つことはあまり意味がありません。\nShadowレプリカはノードを追加することによる検索スループットをスケールアウトすることが、 余分なストレージやインデキシングのコストを払うことなく、可能になります。 代わりに、各シャドーレプリカはプライマリシャードを持っている共有ファイルシステムにread-onlyでアクセスします。 Shadowレプリカは定期的にファイルシステムのビューをリフレッシュし、プライマリシャードのどんな変更も検知するでしょう。\nプライマリシャードが失敗したら、Shadowレプリカがプライマリに昇格し、 失敗したプライマリによって書き込まれたトランザクションログを読み込みリプレイできます。\nこの機能はexperimentalマークが付いています。詳細についてはShadow Replicas documentationをごらんください。\nResiliency improvements Elasticsearch 1.1 から 1.3では、インデックスのすべてのファイルのチェックサムを追加し、 それらのファイルが壊れているかどうかをチェックするために利用することにフォーカスしました。 1.4では、Zen discoveryと分散モデルについて大きな改良を加えました。\nこれらの変更にともなう、より詳細な統計情報やより詳細なロギングがElasticsearchやLuceneの以前のバージョンに存在した 未知の問題を明るみに出しました。 Elasticsearch 1.5.0では、これらの問題の多くに対処しています。\nElasticsearchとLuceneの以前のバージョンにあるバグがインデックスの故障を引き起こしていました。\nチェックサムコードのおかげで、これらを発見できました。現在は、Elasticsearchの起動時に自動的にLucene3.x\n(Elasticsearch 0.20.x以前)が作成したセグメントを検知して、シャードをオープンする前に、新しいフォーマットを使って、 新しいコミットポイントを書き出します。(#9899)\n1.3.xもしくは以前のバージョンからローリングアップグレードは、ローカルのシャードデータを再利用しようとせずに、\nシャード全体をコピーしようとします。1.3.2と以前のバージョンが実行されているノードからローリングアップグレードすることは 圧縮をオフにしない限りできなくなりました。(#9925)\n1.3.xやそれ以前のバージョンからアップグレードする場合、ローリングアップデートする代わりにクラスタの再起動を考えたほうがいいかもしれません。\n非同期環境は予測することが難しいです。時に、最も予測していないことが起きるからです。\nシャード配置、リカバリ、削除のコードの多くが単純化され、状態変更をよりアトミックで決定的にするための変更によりリファクタリングされました。\n(#8720, #9799, #9784, #9801, #9083, #8579, #8436, #8092, #9902, #6644, #8350, #9770, #9616, #9439, #8350, #8494)\n同様に、変更はクラスタ状態の更新が常に前進するということを確実にしました。更新の受け取り順序が順不同であったり、\nマスターだったノードからの更新を受け取った場合に混乱させていました。 (#9632, #9541, #9503)\nチェックサムとチェックサムのバリデーションの強化(#8723,\n#8599, #8587, #8407, #8010, #8018)\ndisk threshold allocation deciderを速く(#8803)、賢く(#7785)、自動化(#8270)\nauto-generated IDの利用時のインデキシングのスピードアップのためのに追加された最適化を除去。\nたまにドキュメントを重複して登録するため(#7729)\nDownload now ぜひ、Elasticsearch 1.5.0をダウンロードして、試してみてください。 そして、感想をTwitter(@elastic)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1427859496,"dir":"post/2015/","id":"19ecbaa5e12f7a9ebcff703c79534a52","lang":"ja","lastmod":1427859496,"permalink":"https://blog.johtani.info/blog/2015/04/01/elasticsearch-1-5-0-released-ja/","publishdate":"2015-04-01T12:38:16+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.0 Released 本日（3/23）、Lucene 4.10.4ベースのEla","tags":["elasticsearch"],"title":"Elasticsearch 1.5.0リリース（日本語訳）"},{"contents":"サンフランシスコからこんにちは。\n今、私は、弊社初のユーザカンファレンスelastic{ON}に 参加するために、初のアメリカ出張中です。 初のユーザカンファレンスですが、世界各国から約1300人！の登録がありました。\n本日が初日（Welcome Receptionが昨晩開催されましたが）です。 初日のキーノートで重要な発表が2つありました。\nブランド名の変更（Elastic: For - You Know, More Than Search） Found.noの加入（Welcome Found） です。\n昨日までは、elasticsearchでした。 本日からは、elasticになります。 ブランド名の変更と同時にサイト、ロゴなども変更されました。\nもう一つのビッグニュースがFoundの加入です。 found.noはElasticsearchをクラウドサービスとして提供している会社です。 彼らがジョインすることで、elasticsearchをより気軽に利用できるような環境ができてきます。\nKeynoteでの驚きのニュースこれらでした。 もちろん、このカンファレンスはそれだけには止まりません。\nNetflixやGitHub、Verison Mobile、WikimediaといったElasticsearch,ELKスタックのユーザの話や、 弊社の人たちによる今後のロードマップや私たちの考え方など多岐にわたる話を聞くことができます。\nこのような機会を今後も提供できるような会社になれるよう、頑張っていきたいなと思っています。\nちなみに、弊社のカンファレンスは私がこれまで経験したことのないカンファレンスになっています。 DJや各種ゲーム（ビリヤードとかパックマンとか）が楽しめるようなパーティが 懇親会として開催されたり、スポンサーブースでウェルカムレセプションが行われたりと、 面白い取り組みにあふれています。 次回開催されることがあれば、ぜひ日本の方達にも参加してもらえたらうれしいなと。\n","date":1426059991,"dir":"post/2015/","id":"ced9df0d8c8ed14de91c509b31b4c4ae","lang":"ja","lastmod":1426059991,"permalink":"https://blog.johtani.info/blog/2015/03/11/attend-elasticon/","publishdate":"2015-03-11T16:46:31+09:00","summary":"サンフランシスコからこんにちは。 今、私は、弊社初のユーザカンファレンスelastic{ON}に 参加するために、初のアメリカ出張中です。 初のユ","tags":["elastic","elasticon"],"title":"#elasticon に参加中"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：you know, for security: shield goes ga\n1/27にShield 1.0 をリリースしました。 Elasticsearch向けの私たちのセキュリティプラグインの最初のリリースです。 11月にShieldについてアナウンスしてから、Elsaticsearchのためのセキュリティの機能は、 一般的に望まれているものから始まり、具体的な考えと実行できる計画へと変遷し、それが、いま現実となりました。\n十分にセキュアな環境に、Elasticsearchクラスタをセキュアな状態でデプロイできるようにするため、 私たちは継続的にカスタマーやユーザーからのリクエストを受け取り、統合されたソリューションになるようにしてきました。\n私たちは、そのようなプロダクトがどうあるべきか調査することから始め、 カスタマーとユーザが必要とするセキュリティとはどんなものかを理解するために多くの時間を費やしました。 その結果がShieldです。 Shieldは、ElasticsearchクラスタをセキュアにするElasticsearchの有償プラグインです。 私たちは、ShieldをDev、Gold、Platinumサブスクリプションの一部として、追加料金なしで提供します。\n最初のリリースでは、基本的な機能と基盤にフォーカスしています。 Elasticsearch自身に対しても、セキュリティに対して準備してきました。 拡張性の側面だけでなく、Elasticsearchにあるデータフローについても再考してきました。 Elasticsearchクラスタをセキュアにする場合に、具体的な価値を即座に届けるだけでなく、素早く拡張できるようにも開発しました。\n機能 Shield 1.0は次の5つにフォーカスしています。\n認証(Authentication) 認可(Authorization) 暗号化通信とノードの認可(Encrypted Communication \u0026amp; Node Authentication) IPフィルタリング 監査証跡(Audit Trail) 認証(Authentication) セキュリティの大部分はアイデンティティについてです（例えば、だれがこのAPIを呼び出したのか？システムに何のサービスが接続するか？など） サービスのライフタイムのある時点で、サブジェクト（例えばユーザー）を現在実行中のサブプロセスなどに結びつけることです。 この関係性を持つためには、サブプロセスを実行する前にユーザの身元を確認するように命じます。 ユーザの身元の確認のプロセスをAuthenticationと呼び、ElasticsearchのすべてのAPIコールでそれが実行されます。\n認証の手法は多くの異なるものがあります。 それぞれの手法は、ユーザが認証されたという資格（Authentication Token）を、それぞれのタイプで提供するようにユーザに要求します。 Shield 1.0ではシンプルに、必要なauthentication tokenをユーザ/パスワードペアとしています。 （これは、Shieldの認証基盤が簡単に拡張でき、将来は異なるauthentication tokenもサポートできることを意味します。）\nユーザの資格を受け取ることだけでは不十分で、次に、それらをチェックする必要があります。 Shieldでは、これはレルムの責務です。 レルムは認証プロバイダ/サービスとしてみることができます。 妥当なユーザであると判断/解決されたか、 authentication tokenが適切な資格を持っていない/単に知らないユーザであるということで、拒否されたかです。 Shieldの認証メカニズムでは、複数のレルムを設定でき、さらに、あるレルムの戻り値を扱う他のレルム、というようなchainとすることもできます。 Shield 1.0は3つのレルムをサポートします。\nesusers - Elasticsearchによって管理されるファイルベースのレルムです。 これは、ファイルにユーザを定義することができます。（Apacheサーバのhtpasswdファイルのようなもの） このレルムは外部への依存はなく、Shieldをインストールすれば、デフォルトで使用できます。 このレルムは配置が簡単で、マルチテナントなElasticsearchクラスタに対して使用できます。 マルチテナントなElasticsearchクラスタとは、クラスタを複数のアプリでシェアすることをテナントと言います。 また、すべてのユーザがパスワードを忘れてしまうような\u0026quot;emergency\u0026quot;な代替レルムも対応可能です。 (誰もシステムに入れないような状況のことです) LDAP - 外部のLDAPサーバでユーザを認証するレルムです。 このレルムは組織のLDAPサーバで管理/保存されているユーザをすでに持っている組織を対象としています。 Active Directory - LDAPのタイプの1つで、Active Directoryに対する設定になります。 レルムはelasticsearch.yml設定ファイルで、次のように設定可能です。\nshield.authc realms:\nesuser: type: esusers order: 0 ldap: type: ldap order: 1 url: ldaps://url/to/ldap1/server ldap_fallback: type: ldap order: 2 url: ldaps://url/to/ldap2/server 上記のようにrealmsが一つのチェインとして参照されます。 レルムごとに、設定された順序で、それらは参照されます。\nNOTE : Shieldには、esusersファイルに保存されたユーザを管理するためのコマンドラインツールもあります。\n認可(authorization) 認可(Authorization)は保護されたリソースにアクセスするユーザを許可するか拒否するかということです。 モダンなシステムは、ユーザのパーミッションのために、ロールベースのアクセスコントロール（RBAC）モデルを利用します。 このモデルでは、各ユーザはロールの集合に関連していて、それぞれのロールには、パーミッションの集合が定義されています。 これは、洗練された設定で、パーミッションを機能的なグループで共有させることができます。 例えば、次のようなロールを定義したとします。\nemployee - すべての従業員は部門をまたいだ会社のデータへアクセスできます（例えば、コンタクトやディレクトリ情報など） sales - すべての営業職は営業データにアクセスできる（例えば、流通ルート、ルート、顧客） finace - すべての財務の従業員は財務データにアクセスできる（例えば、予算、経費、伝票） 財務部門のAnnは従業員と財務のロールを持っており、会社のディレクトリと財務データにアクセスでできます。\n認可プロセスはユーザがリクエストに関連したユーザが必要で、このプロセスのために、認証フェーズの後に直接実行されます。\nShieldは2つのタイプのリソースを定義します。クラスタとインデックスです。 これらは、すべてのAPIコールで保護されます。 さらに、それらに関連したパーミッションとロールも定義できます。 一度定義をすると、ロールはユーザもしくはLDAP/ADのグループに関係します。 ロールはroles.yml設定ファイルで定義されます。 設定のサンプルは次のようになります。\nadmin: cluster: all indices: \u0026#39;*\u0026#39; : all monitor: cluster: monitor indices: \u0026#39;*\u0026#39;: monitor employee: indices: \u0026#39;company_directory\u0026#39; : read sales: indices: \u0026#39;opportunities\u0026#39; : read, write \u0026#39;accounts\u0026#39; : read, write finance: indices: \u0026#39;expenses\u0026#39; : read, write \u0026#39;purchases\u0026#39; : read, write 上記のサンプルで、次の5つのロールを定義しています。\nadmin - 管理者のロールで、すべてのクラスターレベルの操作とすべてのインデックスに対してすべてのインデックスレベルの操作を実行可能です。 (¥*インデックスはすべてのインデックスにマッチするワイルドカード) monitor - システム/クラスタのモニタリングのためのロール。このロールのユーザはすべてのクラスタとインデックスレベルの情報の読み取りの APIにアクセス可能だが、インデックスのデータへの読み書きや設定の更新は不能 employee - compnay_directoryにあるすべてのデータへの読み取りアクセスを与えられたロール。このロールはクラスタレベルへのアクセスやデータの書き込みアクセスは持っていない (特にcompany。洗濯されたグループの人々はcompanyディレクトリの更新は可能だが、employeeは読み取りのみが可能) sales - opportunitiesとaccountsインデックスの読み書きができるロール finance - expensesとpurchasesの両方に読み書きができるロール 上記のサンプルで定義されているallとreadとwriteとして名前がつけられた権限です。 これらは、予約語で、Elasticsearchのローレベルのアクションを複数含んだ権限です。 （writeはindex, delete, delete_by_query, bulk, updateの操作を含んでいます。） 多くのケースで、これらのハイレベルの名前が付けられた権限で十分ですが、特定のロールに特定のアクションを明示的に指定することもできます。 次のようになります。\nhr: indices: \u0026#39;company_directory\u0026#39; : indices:data/write/index, indices:data/write/update ここまで説明した認可のレルムは、各ユーザに関連するロールを識別するためのものです。 内部のesuserレルムでは、提供されるesuserコマンドラインツールを使ってロールはユーザに割り当てたり変更したりもできます。 LDAPやActive Directoryでは、LDAP/ADグループにShieldのロールを割り当てることができます。\n認証と認可の両方を用いることで、ユーザリクエストに対して、ユーザごとに許可/不許可をすることができます。\n暗号化通信 認可はElasticsearchのデータを機能的な観点（許可されたユーザだけが操作を可能にする）で保護しますが、 クライアントからElasticsearchクラスタへ、もしくはクラスタのノード間では暗号化されていないデータを送るためまだ危険があります。 第三者が登頂したり、オンザフライでデータを書き換えたりといった可能性やクラスタを壊すことができます。\nShield 1.0はElasticsearchのすべての通信チャネルをセキュアにすることができます。 クラスタ内のノード間のチャネルやクライアントに公開されているチャネルです。 これは、SSL/TLS通信を導入して実現します。\nShieldで使えるSSLはElasticsearchのtransportサービスをSSL/TLSで通信できるものに置き換えます。 これは、ノード間通信チャネルと、HTTP transport（REST APIを提供するもの）のそれぞれに設定可能です。\nShieldのSSL/TLSは、スタンダードなJavaのものとkeystoreとtruststoreを基本にしたものが利用可能です。 SSL/TLSを設定すると、各ノードのキーストアに証明書をインポートする必要があります。 CAがサインした証明書を使うことも、CAが信頼したものとして許可許諾されたものを使うことが可能です。 これは、信頼されたすべてのCAとして知られているtrust storeが必要です。 新しいノードをクラスタに追加するときに、すべての必要な少なくとも一つの信頼されたCAから発行されてサインされたものが必要になります。 クラスタで個別のノードがすべてのkeystore/truststoreを更新する必要性なしに。？？\n通信チャネルを安全にする方法やSSL/TLS設定をどのように行うかはShieldのドキュメントをご覧ください。\nノード間認証 強く推奨しますが、許可されたノードだけがクラスタに接続できるようにするために、ノードの認証をSSL transportに設定することができます。 これは、shield.transport.client.authにtrueを設定することで可能です。 設定した場合、ノード間でSSLハンドシェイクが行われ、接続されたノードが接続に来たノードのクライアント認証を要求しチェックします。 もし、チェックに失敗した場合は、SSLシェイクハンドが失敗し接続が拒否されます。\nSSLクライアント認証 transportレベルでノード認証が必要なようなら、次のような疑問がわくでしょう。 Elasticsearchはクラスタに接続するTransportクライアントを使うときはどのように振る舞うのか？ Transportクライアントはクラスタの他のノードと同じチャネルを使うため、コネクションを確立するときに、ノードが他のノードと異なるかどうかを見極めることはできません。\nこの時、もっとも単純な解決は、Transportクライアントも同様に許可を与えることです。 それは、認証を解決するときに、他の問題（潜在的な悪意）を引き起こします。 Transportクライアントが他のクラスタのノードを偽装しようとすることです。これは望んでいません。\n幸いなことに、良い解決方法があります。 トランスポートプロファイルです。 Elasticsearch 1.4で導入されたトランスポートプロファイルは、トランスポートレイヤー（異なるホスト/ポートにバインドされる）のために複数のネットワークチャネルを設定することができます。 Shieldはこのサポートを、プロファイルごとに異なるSSL設定をできるように拡張します。 また、ノードのタイプとクライアントプロファイルタイプの間に明確な違いを設定することも可能です。 これを用いると、2つのプロファイルを設定できるようになります。 ひとつは、クライアントのためのもので、もうひとつはクラスタのノードのためのものです。 これにより、クライアントのための認証の問題が必要なくなり、Shieldはクライアントプロファイルをもった限定されたクライアントからのリクエストを保証します。\nIPフィルタリング これは、厳密には、認証カテゴリではありませんが関係しています。 Shieldはそれ自身がIPフィルタリングのメカニズムを持っています。 これは、許可/不許可のIPのリストを設定することができます。 これらのフィルタリングのルールは複数のレベルで設定可能です。 transportチャネル、transportプロファイルレベル、そして、HTTPチャネルです。 次の設定は、それらの設定のサンプルです。（設定ファイルはelasticsearch.ymlになります）\nshield: transport.filter: allow: - \u0026#39;127.0.0.1\u0026#39; - \u0026#39;2001:0db8:1234:0000:0000:8a2e:0370:73 deny: - \u0026#39;10.0.0.0/8\u0026#39; - \u0026#39;2001:0db8:1234::/48\u0026#39; - \u0026#39;*.google.com\u0026#39; http.filter: allow: [ \u0026#39;10.0.0.0/8\u0026#39; ] deny: [ \u0026#39;127.0.0.1\u0026#39; ] transport.profiles: client: shield.filter.deny: [ \u0026#39;_all\u0026#39; ] このように、IPv4とIPv6、CIDR、ホスト名、ワイルドカードが利用できます。 また、この機能はホストOSのIPテーブルに設定することで追加できるが、Shieldにそれを保持し、それらの設定を単純化し、 デプロイの全体から除去できることにも注意してください（詳細はドキュメントのIPフィルタリングをご覧ください）。\n監査証跡（Audit Trail） セキュアなシステムの必須機能の一つで、監査硝石により、Elasticsearchに発生した重要なイベントをトラッキングすることが可能です。 これらのイベントを保存することは、Elasticsearchクラスタの重要なアクティビティの証拠を提供でき、 不審な/悪意のある可能性のあるイベントを追跡するときの診断ツールにもなります。\nShield 1.0.0で、監査証跡は監査/アクセスlogを一般的なElasticsearchのログとは個別に保存します。 それらは、構造化されているため、読んだりパースするのが容易で、イベントのタイプも分類されています。 また、情報のレベルを設定することができ、各イベントをlogレベルの設定で書き出すことができます。 以下が、イベントのリストです。\nanonymous_access_denied - 認証トークンがないユーザからのリクエストがあった時のログ authentication_failed - リクエストされたユーザの認証に失敗した時のログ access_denied - 認証されたユーザが許可されていない操作を実行した時のログ access_granted - 認証されたユーザが許可された操作を実行した時のログ tampered_request - 不正に書き換えられたリクエストが到着したのを検知した時のログ connection_granted - ノードもしくはtransportクライアントがIPフィルタのルールにパスした時のログ connection_denied - ノードもしくはtransportクライアントがIPフィルタリングルールの制限により却下された時のログ Shieldの監査証跡についてより詳しく知りたい方は、ドキュメントをごらんください。\n次のバージョンでは？ ここまで紹介したように、これはまだ始まりにすぎません。 Shieldに追加される多くの機能があり、しっかりとした基盤を構築したところです。 Shieldの次のバージョンでは、以下の機能の追加にフォーカスするでしょう。（これらだけに限ったわけではありません。）\nAPIによる設定、管理 より拡張され、柔軟なLDAP/Active Directoryサポート レルムタイプの追加（kerberos、anonymous、certificatesなどなど） セッションベースの認証 ShieldはElasticsearch社の2番目の（Marvelに続く）商用プロダクトです。 ダウンロードして開発環境で評価してください。 インストールは他のプラグインと同様の方法です（インストール方法についての詳細はこちら）。 一度インストールすると、30日の試用ライセンスが始まります。 もし、さらに時間が必要な場合は、sales@elasticsearch.comまで連絡してください。\n私たちのすべてのプロダクトについてフィードバックをお待ちしています。 Shieldの商用利用、機能、ロードマップ、その他のセキュリティに関するトピックなど、質問がありましたら、 サイトからご連絡ください。\n","date":1425030596,"dir":"post/2015/","id":"cb13b64d0127c13bb466c4d4677a7b8a","lang":"ja","lastmod":1425030596,"permalink":"https://blog.johtani.info/blog/2015/02/27/you-know-for-security-shield-goes-ga-ja/","publishdate":"2015-02-27T18:49:56+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：you know, for security: shield goes ga 1/27にShield 1.0 をリリースしました。 Elasticsearc","tags":["elasticsearch","shield"],"title":"セキュリティ向けプラグインShieldのリリース（日本語訳）"},{"contents":"4月13日から3日間、ElasticsearchのCoreトレーニングが東京で開催されます。 Early Birdということで、3/14までに申し込みすると割引があります。 興味のある方は、見ていただければと。\nまた、4/15にElasticsearch勉強会を開催します。 トレーニングに弊社のエンジニアが来日しますので、なにか話をしてもらう予定です。\n募集は後日、Elasticsearch勉強会のDoorkeeperで行います。 興味のある方は、登録しておいていただければと。\nトレーニングや勉強会でお待ちしております。\n","date":1425024629,"dir":"post/2015/","id":"f2cbe07bf2ff16d5a5860b4d6edbc5e8","lang":"ja","lastmod":1425024629,"permalink":"https://blog.johtani.info/blog/2015/02/27/2nd-tokyo-training/","publishdate":"2015-02-27T17:10:29+09:00","summary":"4月13日から3日間、ElasticsearchのCoreトレーニングが東京で開催されます。 Early Birdということで、3/14までに申し込みす","tags":["elasticsearch"],"title":"Elasticsearch Coreトレーニング開催"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：kibana 4. literally.\nKibana 4は現在、文字通り、抽象的に、概念的に、精神的に、そしてとても楽しく、プロダクションレディになりました。 1週間前に準備はできていましたが、満足できるものであるという確信を得たいと思っていました。 そして、Kibana 4.0.0 GAをリリースしました。 次のものはサンプルのスクリーンショットと前日譚です。 これらに興奮してしまった方のために、2ステップのプランを用意しました。\nダウンロードする：Kibana 4 downloadsページからダウンロードします。 理解する：Kibana 4 docsページを読んで理解します。 Tip : もし、まだ、あなたのクラスタがElasticsearch 1.4.4でない場合は、アップグレードする必要があります。\nTip2 : Kibana 4 RC1からアップグレードする場合は、configを移行する必要があります。こちらのgistを参照\n前日譚 - the back story Kibanaはすでに問題解決のためのツールになっています。 なぜ、毎晩2時に呼び出されるんでしょう？ そのコードがプロダクションに入ったのはいつですか？ その結果、何を壊しました？ 私たちはそれらを解決しました。 世界的に、長い間、だれも夜中の2時に呼び出されませんでした。知ってます？。\n*しかし、ここには落とし穴があります。*答えが簡単になれば、問題が難しくなります。 楽な勝利は簡単でした。では、難しい問題（深さが3層の問題）を解きましょう。 複数の要素、複数のフィールドそして、複数のデータソースを分析する必要がある問題を解きましょう。 Kibana 4は少ない時間と労力で最も難しい問題を解決してくれます。\nKibana 3で学んだことをKibana 4に取り込みました。 なぜ10億のデータを持っているのに、地図には1000個しかプロットできないのでしょう？ 1つのチャートに1つのフィールドなんでしょう？ なぜ、1つのパネルに1つのチャートなんでしょう？ なぜ、1つのダッシュボードに1つのインデックスなんでしょう？ 5つのシナリオを用意し、2つのフィールドにまたがったデータを比較し、 1つのダッシュボードに3つのインデックスのデータを表示してみましょう。 さぁ、やりましょう。終わったらアイスクリーム（トッピング付きの）を取りに行きましょう。\nthe plot アイスクリームのように、問題には多くの種類があります。 そのために、Kibanaをナポリ風アイスクリーム（3色アイス）のように分割しました。 嫌いな種類は除いて。 もし、あなたがKibanaのユーザ歴が長い場合、最初のタブのDiscoverがホームであることが正しく感じるでしょう。 これにより、短時間で、検索し、レコードを見つけ、簡単な問題を解決できます。 簡単な問題とは、すべてを物語る1行のデータを見つけることによって解決する問題です。\n物事が簡単な検索で説明できるものよりも複雑になった時、チャートとグラフで魔法を作る時間です。 Visualizeタブを開き、Elasticsearchのaggregationの力を利用してデータを解析しましょう。 Visualizeは複数の次元の性質のデータを見せ、今まで尋ねたことがないような質問に対して素早く回答するチャートやテーブル、 地図を作成できます。 あなたが最初に尋ねる質問は「先週サイトが遅かったのはなぜ？」でした。 しかし、データによって明らかにされた質問は「なぜ、クリスマスに東京からの平均ファイルサイズリクエストがスパイクしたのか？」です。\n最後に、Dashboardでこれらを1つにします。\n大きなスクリーンに配置して、こう言います。 「あなたの答えはこのリンクにあります。また、Wikiに埋め込んで、データをCSVにエクスポートしてメールしました。 アイスクリームを食べた後に、自叙伝の第1章を書きました。もっとアイスを持ってきてください。かき混ぜますから。」\nそれぞれのタブで見てきた詳細については、Kibana 4 Beta 1 : Releasedをごらんください。\nto be continued\u0026hellip; 居眠りをする時間はあります？いいえ、Kibana 4.1についてすでに作業中で、将来の大きなプランを持っています。 多くの労力はKibana 4の土台の安定と実用性を構築することに使われました。 また、Elasticsearchアプリケーションの将来を構築するプラットフォームを作りました。 すべてのものは拡張できるように設計されています。 例えば、可視化はより良くなるように構築されています。 オープンソースは私たちのGitHubアカウント以上のものです。 それは、新しく素晴らしいものを誰もが作ることができる構造を作ることが私たちの約束です。\nKibanaでグラフなどを構築したり、Elasticsearchを利用したアプリケーションを作成するために、 私たち開発者のブログを参考にしてください。 ちょっと見てみたいですか？ Elastic{ON}15のSpencer Algerのトークをチェックしてください。\nあなた方なしでは、私たちはここにはいないですし、あなた方の助けがなければ何もできません。 ぜひ、GitHubでのissueや提案、貢献をお待ちしています。 もしくは、IRCでFreenodeの#kibanaに参加してください。\nextra credit Kibana 4のすべての話に興味がありますか？私たちのKibana 4ベータに関する過去のブログをチェックしてください。\nKibana 4 Beta 1: Released Kibana 4 Beta 2: Get it now Kibana 4 Beta 3: Now more filtery Kibana 4 RC1: Freshly baked 最後に、Kibanaの利用に関する話をお持ちなら、ぜひ聞かせてください。 stories at elasticsearch dot comもしくは@elasticsearchに連絡をください。 あなたの話を世界にどのようにシェアしているかごらんください。\n","date":1424408752,"dir":"post/2015/","id":"eee039f49a5b570599cf459c55c649f3","lang":"ja","lastmod":1424408752,"permalink":"https://blog.johtani.info/blog/2015/02/20/kibana-4-literally-ja/","publishdate":"2015-02-20T14:05:52+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：kibana 4. literally. Kibana 4は現在、文字通り、抽象的に、概念的に、精神的に、そしてとても楽しく","tags":["elasticsearch","kibana4"],"title":"Kibana 4（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch 1.4.4 and 1.3.9 released\n本日（2/20）、Elasticsearch 1.4.4とElasticsearch 1.3.9をリリースしました。 これはバグフィックスリリースとなります。 主に、Lucene expression scriptsを使う場合のRPMとDEBパッケージの パッケージング問題のフィックスをしたものです。 1.4.4のダウンロードこちらのリンクからアクセスできます。\nfixes 1.4.3のRPMおよびDEBパッケージにはAntlrとASMの依存関係の不足がありました。 この依存はElasticsearchでLucene expression scriptsを利用する場合に必要になります。 Groovyに関する1.4.3の変更により、多くのユーザがLucene explression scriptsを利用することが予想されるため、すぐに、1.4.4をリリースしました。\nまた、このリリースには、クラスタの保留タスクに関するいくつかのバグフィックスも含まれています。 さらに、date histogramで負のインターバルの場合にOutOfMemoryErrorを引き起こすバグも 修正されています。\nすべての変更については1.4.4のリリースノートおよび1.3.9のリリースノートをごらんください。\nフィードバック 私たちはフィードバックをお待ちしています。 Twitter(@elasticsearch)もしくはGitHub issues pageで教えてください。\n","date":1424408734,"dir":"post/2015/","id":"ddd3e6f6e298d3884abc4d888a043664","lang":"ja","lastmod":1424408734,"permalink":"https://blog.johtani.info/blog/2015/02/20/elasticsearch-1-4-4-and-1-3-9-released-ja/","publishdate":"2015-02-20T14:05:34+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.4 and 1.3.9 released 本日（2/20）、Elasticsearch 1.4.","tags":["elasticsearch"],"title":"Elasticsearch 1.4.4および1.3.9リリース（日本語訳）"},{"contents":"来る、4月4日の土曜日の午後に名古屋でElasticsearch勉強会を開催予定です。 「初」の東京以外の勉強会です。\nTwitterでこのようなツイートを見かけまして。\n名古屋でElasticsearchの勉強会やりたい機運（今のところ2人）。\n\u0026mdash; mogami (@smogami) 2015, 2月 4 これは！ということで、名古屋で勉強会をやろうかと思います。30名程度の場所を借りて実施予定です。 募集はいつもの、elasticsearch勉強会のDoorkeeperで行う予定です。 ページの準備まで少々待ちください。（おそらく、3月中旬くらい） 私自身はElasticsearchやELKについて話をしようと思っています。そのほかに、2,3名のスピーカーの方を予定しています。 LTなど興味がある人がいたら、連絡ください。\nこれを機に（？）他の場所でも勉強会を開催したいと考えています。 ニーズがどのくらいありそうなのかが、まだよくわかっていませんが、関西などでニーズがあるんじゃないかと期待していたり。\n興味のある方は、コメント欄、Twitterなどでコンタクトしてもらえればと。 （連絡来るとうれしいなぁ。）\n","date":1424240573,"dir":"post/2015/","id":"5b97ead91c0dd0bad57b4f43a89149a2","lang":"ja","lastmod":1424240573,"permalink":"https://blog.johtani.info/blog/2015/02/18/preparing-elasticsearch-meetup-in-nagoya/","publishdate":"2015-02-18T15:22:53+09:00","summary":"来る、4月4日の土曜日の午後に名古屋でElasticsearch勉強会を開催予定です。 「初」の東京以外の勉強会です。 Twitterでこのよう","tags":["elasticsearch","勉強会"],"title":"名古屋でElasticsearch勉強会を開催します"},{"contents":"第8回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n今回は出足が好調で、早々に180人の枠を超えるという嬉しい事態でしたが、 キャンセル待ちが残っているにもかからわらず、来られていない方が67名もいるということで、キャンセル待ちの方には申し訳なかったです。 もうすこし、キャンセルをしてもらえると嬉しいんですが。。。 今回はメールを当日に1度しか打ってないからかなぁ。\nさて、いつもの通り簡単なメモです。 本当に簡単にですが。\n「Elasticsearch導入チェックリスト？」 Elasticsearch株式会社 Jun Ohtani @johtani スライド：Elasticsearch導入チェックリスト？\nElasticsearchを開発環境や本番に導入する前に気にかけて欲しいことについて発表しました。 元ネタはelasticsearch pre-flight checklistです。 少々古いのですが、私が今回話した内容以外にもモニタリングなどについての話も盛り込まれています。 時間がある方は、見ていただければと。\n「Elasticsearch クエリとスキーマ定義のすごい細かい話」株式会社ドワンゴ 藤堂淳也 さん スライド：Elasticsearch クエリとスキーマ定義のすごい細かい話\nフィールドのチェックを別途インデキシングするアプリで行っている。利用できるものだけElasticsearchに投げる 実際に本番環境で利用しているマッピングに対してフィールドを追加する手順について 「これもドキュメントに書いてあるんですが」という感じでドキュメントに色々書いてあるので読みましょうというありがたい発表でした。 実際に試行錯誤したり検証するときに行ったことを喋ってもらえたので、どういった点を気にしながら運用、設計するかというのがわかりやすかったです。\n「ElasticsearchとKibanaで実現する、30億req/dayのリアルタイム分析」株式会社サイバーエージェント　山田直行さん　@satully スライド：ElasticsearchとKibanaで実現する、30億req/dayのリアルタイム分析\n会場が21時までしか抑えられていないという失態で、ドタバタしてて前半は聞けてないです。。。\n前回の発表では30日分Elasticsearchに入れていたが、今は3日分のみ保存 レポートなどにはRedshift＋Tableauを利用 Kibana3をメインに使っているが、Kibana4も検討予定？ QA\nQ：なぜ、ELBを挟んでいるのか？ A：特に考えておいているわけではない。 Q：インデックスの構成は？ A：1日に2つのインデックス。Bitされたもの、入札されないもの Q：searchのnodeをやめたのは？ A：前回発表した勉強会での懇親会で話を聞いたり、他の方と話を聞いて、不要と判断したため 「はてなのメディア面を支えるElasticsearch」株式会社はてな　山家雄介さん　@yanbe スライド：未定。おそらく、開発者ブログに公開されるかと。\n\u0008* アドテク系にもやってるらしい。BrandSafeはてな\nはてなブックマークのデータを魅せ方を変える機能などで大活躍。B!KUMAとか その日の話題の見出し自動生成機能。Significant Terms Aggregationsを利用。 こちらの「自然言語処理技術を用いたはてなブックマークの新機能「トピック」をベータリリースしました」エントリに関係あるのかな？ 記事の魅せ方を検索できる管理画面ではElasticsearchのクエリDSLを活用されているとのことでした。 検索専門の人でなくても検索式を簡単にくみたてられる画面を用意して、ElasticsearchのクエリDSLに変換するようにしていると。 確かに、クエリをそのまま組み立ててもらうよりも利用しやすい画面がある方がいいですよね。バックエンドはJSとPerlのライブラリとのことでした。\nその他、感想などのブログ 2015-02-13 第8回 elasticsearch 勉強会 @ 丸の内 リクルート 41Fアカデミーホール [Elasticsearch] 第8回 elasticsearch 勉強会へ参加してきた 第8回elasticsearch勉強会 #elasticsearch #elasticsearchjp 第8回 Elasticsearch 勉強会に行ってきた #elasticsearch #elasticsearchjp 勉強会メモ - 第8回elasticsearch勉強会 まとめ 今回も検索からログまでいろんな話になったので、面白かったかと。 参加された方は新しい方が多かったんじゃないかなぁと。（集計結果で見れないのかな、Doorkeeper）。\n今回は、みなさんに21時に41Fから33Fへ移動していただくという大失態があったので、大変申し訳なかったです。 次回（4月中旬）は、このようなことがないように気をつけますので、今後もよろしくお願いいたします。\nあと、東京以外の勉強会も検討しつつあります。興味のある方はコメントやTwitterで反応をいただけると嬉しいです。\nスピーカーは随時募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1424066543,"dir":"post/2015/","id":"997acc135d01b54f7de77a432fb9133f","lang":"ja","lastmod":1424066543,"permalink":"https://blog.johtani.info/blog/2015/02/16/8th-elasticsearch-jp/","publishdate":"2015-02-16T15:02:23+09:00","summary":"第8回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第8回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：running groovy scripts without dynamic scripting\nElasticsearch1.3.8と1.4.3のリリースにより、デフォルトで、リクエストに含まれるGroovyスクリプトや インデックスに保存されたスクリプトを動的に実行する機能をオフにしました。 しかし、Groovyはまだデフォルトのスクリプト言語です。 本ブログ記事では、少しだけダイナミックだが、サンドボックスではない言語のためのスクリプトを どのように使い続けるかを説明します。\n本ブログ記事は、それが何を意味し、さらに重要なのは、安全に重要なタスクを実行させるためにスクリプトを どのように使用し続けるかを理解する助けとなるはずです。\nダイナミックスクリプトとは？ Elasticsearchに詳しくない方のために、Elasticsearchでは、 さまざまなリクエストの一部としてスクリプトを送信することができます。 search、aggregation、update、upsert、delete by queryなどです。 あなたのユースケースのために、通常の動作よりも拡張した動作をさせるためにスクリプトを追加できます。\n例えば、以下のリクエストは、ダイナミックスクリプトを含んでいます。 field1とfield2 + shiftが同じ値を持っている時だけドキュメントを返します。\nGET /_search { \u0026#34;query\u0026#34;:{ \u0026#34;filtered\u0026#34;:{ \u0026#34;filter\u0026#34;:{ \u0026#34;script\u0026#34;:{ \u0026#34;script\u0026#34;:\u0026#34;doc[\u0026#39;field1\u0026#39;].value == (doc[\u0026#39;field2\u0026#39;].value + shift)\u0026#34;, \u0026#34;lang\u0026#34;:\u0026#34;groovy\u0026#34;, \u0026#34;params\u0026#34;:{ \u0026#34;shift\u0026#34;:3 } } } } } } 言語を変えることもできます。 それは、当然、シンタックスが変わったり、制限が追加（例えば、Groovyスクリプトの代わりにLucene　Expressionsに変更）されることもあります。 langパラメータによって言語を指定できます。\nなぜそれはダイナミック？ 上記の例はダイナミックスクリプトです。 それは、実際のスクリプトの部分はサーバサイドで動的に解釈されコンパイルされる必要があるからです。 ダイナミックスクリプトはElasticsearchのAPIによってデータノードに送信されます。 これは、インデックスされたスクリプト(indexed script)も含みます。\n言い換えると、もし、スクリプトがデータノード全てに保存されていなければ、 それは、ダイナミックスクリプトとして扱われます。\ndynamic scriptingをオフにするとどうなるか？ 最新のリリースでの変更により、Groovyのdynaic scriptingはデフォルトでオフになりました。 先ほどのスクリプトについても同様で、もし、先ほどのリクエストを実行すると、次のようなエラーが発生します。 (一部省略してあります。)\n{ \u0026#34;error\u0026#34;:\u0026#34;SearchPhaseExecutionException[Failed to execute phase [query], all shards failed; shardFailures {[8FJ02MofSnqVvOQ10BXxhQ][test][0]: SearchParseException[[test][0]: from[-1],size[-1]: Parse Failure [Failed to parse source [{...}]]]; nested: ScriptException[dynamic scripting for [groovy] disabled]...\u0026#34;, \u0026#34;status\u0026#34;:400 } エラーメッセージの重要な箇所は「ScriptException[dynamic scripting for [groovy] disabled]」です。\nスクリプティングを使い続けるには？ Elasticsearchでスクリプトを実行するには3つの方法があります。 2つのダイナミックな方法は、リクエストごとのスクリプト（上述）かインデックスされた スクリプト(indexed script)を使う方法です。 インデックスされたスクリプトを使うことは、Elasticsearch自身にGroovyスクリプトを保管することで 利用で、それらを要求に応じて利用することです。 （これは、実際には十分機能しますが、これではまだ、信頼できないユーザに対して彼らのスクリプトを実行できます） RDBのように保存されたプロシージャとして同じ方法で実行させるものと同様です。 前もって、スクリプトを記述しておき、リクエストの一部として後から、名前で呼び出して実行可能です。\nGET /_search { \u0026#34;query\u0026#34;:{ \u0026#34;filtered\u0026#34;:{ \u0026#34;filter\u0026#34;:{ \u0026#34;script\u0026#34;:{ \u0026#34;script_id\u0026#34;:\u0026#34;your_custom_script\u0026#34;, \u0026#34;lang\u0026#34;:\u0026#34;groovy\u0026#34;, \u0026#34;params\u0026#34;:{ \u0026#34;shift\u0026#34;:3 } } } } } } あまり変わっていないことに気づくでしょう。 scriptの部分が、前もって記述されたスクリプトの名前script_idに変更されただけです。\nElasticsearchにスクリプトを提供するダイナミックではない方法はインデックスに保存する代わりに、 ディスクにファイルとしてスクリプトを保存することです。 そうすることで、各スクリプトを設定として保存します。 これは、どのようなスクリプト言語に対してもダイナミックスクリプティングをオフにしたまま、 サンドボックス化されないスクリプトを使い続けることができる方法です。\n最初のサンプルで、Groovyスクリプトはdoc['field1'].value == doc['field2'].value + shiftでした。 これを、.groovy拡張子を持ったファイルとして書き出すことができます。\ndoc[\u0026#39;field1\u0026#39;].value == (doc[\u0026#39;field2\u0026#39;].value + shift) もし、このファイルにyour_custom_script.groovyちう名前をつけて、 Elasticsearchのすべてのデータノードのconfig/scriptsディレクトリに保存すると、 Elasticsearchは60秒（elasticsearch.ymlのwatcher.intervalで変更可能）でこのスクリプトを認識し、今後のリクエストに利用できるようにプリコンパイルするでしょう。 そのファイルはElasticsearch実行ユーザによって読み込みができる必要があります。 これをディスクに書き込んだ後、あなたの設定ディレクトリは次のようになっています。\nconfig/ elasticsearch.yml logging.yml scripts/ your_custom_script.groovy これは、各リクエストやインデックスされたスクリプトをスクリプトとして動的に送信しませんが、 信頼された環境にスクリプトを追加することでダイナミックスクリプトとなることを許します。\nディスクに書かれたスクリプトを使用する スクリプトは、ロードされたスクリプトになるまでは、利用できません。 ログファイルに次のようなログが表示されるまではです。\n[2015-02-11 11:14:47,066][INFO ][script ] [Sergei Kravinoff] compiling script file [/path/to/elasticsearch-1.4.3/config/scripts/your_custom_script.groovy] すべてのElasticsearchのデータノードでスクリプトが読み込まれたら、 それを利用することができます。 利用するために、file（script_idではありません！）としてスクリプト名を指定します。\nGET /_search { \u0026#34;query\u0026#34;:{ \u0026#34;filtered\u0026#34;:{ \u0026#34;filter\u0026#34;:{ \u0026#34;script\u0026#34;:{ \u0026#34;file\u0026#34;:\u0026#34;your_custom_script\u0026#34;, \u0026#34;lang\u0026#34;:\u0026#34;groovy\u0026#34;, \u0026#34;params\u0026#34;:{ \u0026#34;shift\u0026#34;:3 } } } } } } Note:langは必須ではありません。Groovyがデフォルトの言語のためです。 もし、違うスクリプト言語を使いたい、もしくは、デフォルトの言語を（例えば、Lucene Expressionsへ） 変更したい場合、言語が正しいスクリプトを見つけるために提供されている必要があります。 一番良い方法は、アプリケーションがlangパラメータを含んでいることを勧めます。 これは、将来、デフォルトのスクリプト言語が変更されても、問題ないからです。\n質問？ もし、質問があれば、遠慮なくTwitter(@elasticsearch)で教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1423721589,"dir":"post/2015/","id":"1fed22e99b0e11a50eb7b92cb1644e8a","lang":"ja","lastmod":1423721589,"permalink":"https://blog.johtani.info/blog/2015/02/12/running-groovy-scripts-without-dynamic-scripting-ja/","publishdate":"2015-02-12T15:13:09+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：running groovy scripts without dynamic scripting Elasticsearch1.3.8と1.4.3のリリースによ","tags":["elasticsearch"],"title":"Groovyスクリプトをダイナミックスクリプトなしで実行(日本語訳)"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch 1.4.3 and 1.3.8 released\n本日、Lucene 4.10.3をベースにしたElasticsearch 1.4.3と、セキュリティとバグフィックスリリースである、Elasticsearch 1.3.8をリリースしました。 ダウンロードおよび変更リストはそれぞれ次のリンクからアクセスできます。\n最新ステーブルリリース：Elasticsearch 1.4.3 1.3.x系バグフィックス：Elasticsearch 1.3.8 過去のリリースに関するブログ（公式）はこちら。\n1.4:1.4.2, 1.4.1, 1.4.0, 1.4.0.Beta1 1.3:1.3.7, 1.3.6, 1.3.5, 1.3.4, 1.3.3, 1.3.2, 1.3.1, 1.3.0. すべての変更については1.4.3のリリースノートおよび1.3.8のリリースノートをごらんください。 以下では、セキュリティの問題について紹介します。\ngroovy scripting の脆弱性 Elasticsearchのバージョン1.3.0から1.3.7および1.4.0から1.4.2で、Groovyスクリプトエンジンに脆弱性が発見されました。 脆弱性は、攻撃者がGroovyスクリプトをサンドボックスを避けて構築でき、 ElasticsearchのJava VMを実行しているユーザとしてシェルコマンドを実行できます。\nこの問題をCVE-2015-1427として報告済みです。\nバージョン1.3.8と1.4.3では、デフォルトで、Groovyに対してのサンドボックスをオフにしました。 結果として、ダイナミックスクリプトの実行はGroovyに対してもオフとなります。\nもし、脆弱性のあるバージョンで実行している場合、v1.3.8かv1.4.3にアップグレードするか、ダイナミックなGroovyスクリプトをクラスタの すべてのノードに対して次の設定を追加することで、オフにします。\nscript.groovy.sandbox.enabled: false これは、Groovyのサンドボックスをオフにし、リクエストの一部としてインラインで受け付けるダイナミックなGroovyスクリプトや 特殊な.scriptsインデックスに保存されているスクリプトを実行しません。\nそれまでは、各データノードのconfig/scriptsディレクトリにファイルとして保存されたGroovyスクリプトは まだ、利用可能です。詳細の情報についてはRunning scripts without dynamic scriptingをごらんください。\nfuture scripting plans 安全なダイナミックスクリプティング言語としてGroovyを失うことは、Elasticsearchにとって痛手です。 update APIやsearch APIやaggregationsフレームワークの一部としてScriptを使います。 それらは、静的なAPIでは簡単に表現できない、カスタムなトリックをユーザに実行できるようにします。\n残念ながら、Groovyチームとこの問題を議論した後、Groovy言語もサンドボックスによってきちんと保護されている というにはあまりにもダイナミックであるという結論に達しました。 Groovyは、デフォルトでは利用できなくなります。 利用可能なダイナミックスクリプト言語としてはLucene Expressions言語のみとなります。 Expressionsははやいですが、それらは非常に限定されています。数値のフィールドでのみ実行可能で、ループをサポートしていません。\nより強力で（しかし安全な）ミニ言語になるようにExpressionsを拡張することを調査しています。 これは、Scriptユーザが現在持っている最も一般的なユースケースを少なくとも助けるでしょう。 この拡張は長期間のプロジェクトであり、進化には時間がかかるでしょう。\nぜひ、Elasticsearch 1.4.3をダウンロードして、試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1423712393,"dir":"post/2015/","id":"5badf61ecb9cfadd7d6af58712fa5f6f","lang":"ja","lastmod":1423712393,"permalink":"https://blog.johtani.info/blog/2015/02/12/elasticsearch-1-4-3-and-1-3-8-released-ja/","publishdate":"2015-02-12T12:39:53+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElas","tags":["elasticsearch"],"title":"Elasticsearch　1.4.3および1.3.8リリース（日本語訳）"},{"contents":"今年もCROSS参加しました。そして、話もしてきました。 今年は横浜の大さん橋でした。横浜はあんまりこないので、乗り換えでおたおたしてしまいましたが。。。\nなかなかいい景色でした。（寒いけど） 「おおさんばし」って読むんですね。「だいさんばし」だと思ってた。。。\n以下はいつもの、自分用メモです。\n俺はどうしてそのデータストアを選択したのか 〜銀河と小宇宙を語る会〜 http://2015.cross-party.com/program/c1\n遅れて入ったので、ちゃんと聴けてないです。\n最近注目しているデータストアは？ Postgresql。JSON型が気になってる。 AiroSpike。データ型のあるデータストアが気になってる。 MongoDB。JSON使いたいなら、これじゃないの？ AWSのAurora。インスタンスタイプを選ばなくていい（選ばないといけないらしい）とか、勝手にスケールしてくれるし、MySQL互換。 今こそ語るエンジニアの幸せな未来 http://2015.cross-party.com/program/x3\n「無職初日です。」 Web系の人？とか質問されて、自分が何系かいつもわからなくなるなぁ。 「働きがいは会社が提供するのか、個人が見つけるのか？」 個人かなぁ。会社がなにをやってるかにもよる気がするかなぁ。 「辞めると伝えると、やりたいようにやれって言われるw」 リモートできるかできないか。 「働きがい」というキーワードが出てると普通は怪しい会社w 今は、働きやすさを高くしないと人が雇えなくなってきている。 欧米のミドルウェアだと、35歳定年説はない。→日本でもそうじゃないですか？ 漫然と進んでるとダメ。→そりゃそうだ。 全文検索エンジン群雄割拠〜あなたが使うべきはどれだ！〜 http://2015.cross-party.com/program/c4\nスライド：https://speakerdeck.com/johtani/elasticsearchfalseshao-jie-tote-zheng-cross-2015\n楽しんでいただけましたでしょうか？ ちょっと話が長くなってしまい、あとの方の時間が少なかった気がしますが。。。\nKibanaのバックエンドとして認識されている人もいたので、検索エンジンですよというのをアピールするいい機会になったので良かったです。 もちろん、Kibanaとの組み合わせも面白いので、少しでも興味をもっていただき、触っていただけたらなぁと。\n話をする機会を用意していただいた、やまかつさん、その他のスピーカーのみなさん、ありがとうございました！。\nElasticsearchに関して何か興味質問などありましたら、気軽にコンタクトしてください。Twitterとかブログコメントなどで。\nプレモルタイム以降 プレモルの写真撮るの忘れてました。。。重要なのに。。。\n美味しくプレモルをいただきながら、何人かの方に声をかけていただき、話をすることができました。 こういう時間がとってあるのがいいですよね。 色々なところでElasticsearchを使っていただいているようで、うれしい限りです。 DMMの方とも話ができたし。\nまとめ 今年はプレモルを飲みに行くだけかなぁと思っていたのですが、話をする人になってました。（おかしいなぁ） 来年もあれば、きっと参加するかなぁと。ではまた来年！\n夜景きれいですね。（端っこに写ってる船は飛鳥IIでした。）\n","date":1422500368,"dir":"post/2015/","id":"fe6ba10cc6c9509b4b22e9d59e029775","lang":"ja","lastmod":1422500368,"permalink":"https://blog.johtani.info/blog/2015/01/29/talk-at-cross2015/","publishdate":"2015-01-29T11:59:28+09:00","summary":"今年もCROSS参加しました。そして、話もしてきました。 今年は横浜の大さん橋でした。横浜はあんまりこないので、乗り換えでおたおたしてしまいま","tags":["勉強会","elasticsearch"],"title":"CROSS 2015で話をしてきました #cross2015"},{"contents":"今年は大晦日になってしまいました。しかも、ちょっと飲んでたり。。。 第9流しながら書いてます。\n振り返り(2013年に書いた抱負から) まずは昨年書いた抱負からの振り返りです。\nElasticsearch勉強会の継続、Solr勉強会の継続＋ミックスした検索勉強会の開催 IDEAのさらなる活用 もっと開発(プラグインとか) AWSをもう少し活用 海外のイベントに行ってみたい 読書と英語を継続 AWS活用できてないです、、、 ミックスした勉強会は、ドタバタしててできませんでした。\nIDEAはさらなる活用までいってるかは不明ですが、最近は隣にとても詳しい人が座っているので色々と教えてもらってます。 開発については、ちょっとずつですが、PR書いたりしてます。\n振り返り(今年あったできごと) 初海外（ベルリンとアムステルダム） Elasticsearchに転職 初献本? Elasticsearch勉強会の定期開催 ElasticSearch Serverの翻訳 サーバ/インフラエンジニア養成読本の執筆 勉強会以外でもスピーカー 英語の継続（切実） 初ものが多かったです。 初の海外の会社、初の海外旅行（仕事）、初の献本（著者の人から、多分、初）、初の翻訳本、初のムック本執筆などなど。\n初の海外でした。なのに、夏には海外の会社に転職してみてるとか、ちょっと自分でも信じられません。 ベルリンでは、海外の勉強会にも参加できて非常に有意義でした。 ヨーロッパの街並みは、日本では経験できない雰囲気で、向こうの方には普通の街並みも自分にはとても新鮮でした。\n転職自体は2回目ですが、海外の会社というのは初めてです。日々、英語\u0008の勉強になりますし、いろんな刺激を受けています。 英語の勉強自体も継続中です。英語力が不足しているのは自覚してるので、少しでも英語に触れるようにDLifeで海外ドラマを録画して、通勤時間帯にみるなどを試みてます。\n書籍には、昨年につづき関わることができました。来年も何かしらの書籍に関われることができればなと。 （\u0008気になる人は以下のリンクから。。。）\n分かりきったことですが、Elasticsearchな1年でした。 転職してあっという間の半年です。まだまだやりたいことがいっぱいあるので、来年もバランスよく頑張らないと。\n来年の抱負 英語の継続 海外のイベントへの参加 多岐にわたるイベントでのスピーカー 日本の人員の倍増！？ Elasticsearchに関する日本語の情報発信 Elasticsearch座談会みたいなものの開催 英語の継続については書くまでもないですね。 海外のイベントへの参加もかなぁ。3月にサンフランシスコに行くとは思います。 そのほかには、今度こそBerlin Buzzwordsに行きたいです。\nElasticsearch勉強会以外のイベントでもElasticsearchを広めるべく色々なところでスピーカーをしたいなと思っています。 検索、ログ解析で少しは知名度が上がってきていますが、別の言語のコミュニティやイベントでは、まだまだ、elasticsearch自体を知らない人もいると思います。まずは知ってもらうところからかなと。\n日本の人員の倍増については、今年も達成してます（一人が二人になりましたw）。 来年も倍増できればうれしいなと。同じ母国語の同僚がいるのはやっぱりうれしいし、心強いですから。\n来年は（も）、日本語での情報をどんどん発信していきます。サイトやガイドなども 日本語にしたいなと。 あとは、これまで、勉強会でスピーカーをしていただいた人だけを集めた座談会のようなものも開催したいなと考えています。 私自身も色々と聞きたいことがありますし。 そのほかにも色々と要望をお待ちしています。Twitterやブログのコメント欄などで気軽にコンタクトしていただければと。\n最後は、いつものようにですが、来年も勉強会やいろんなイベントに参加する予定です。 ブログも週1程度で書く努力しないとなぁ。 こんな話を書いてくださいとかのリクエストもお待ちしています。\n今年はあと、数時間ですが、色々とお世話になりました。 この場を借りてお礼申し上げます。\n来年も、いろんな方に絡んでいくとは思いますが、よろしくお願いいたします。\n","date":1420026086,"dir":"post/2014/","id":"b36abffbe5d6a0de73a9968604a1a3f9","lang":"ja","lastmod":1420026086,"permalink":"https://blog.johtani.info/blog/2014/12/31/looking-back-2014/","publishdate":"2014-12-31T20:41:26+09:00","summary":"今年は大晦日になってしまいました。しかも、ちょっと飲んでたり。。。 第9流しながら書いてます。 振り返り(2013年に書いた抱負から) まずは昨年","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2014）"},{"contents":"この記事はElasticsearch Advent Calndar 2014の25日目のエントリです。\nあっという間に最終日です。来年につなげるという意味で、Elasticsearchの2系のIssueをいくつかピックアップして紹介してみます。\n現在、ElasticsearchのGitHubリポジトリは、大きく3つのブランチで作業しています。 master、1.x、1.4です。masterと1.xの大きな違いとしては、masterはLuceneの5.x系を採用している点です。\nなお、これから紹介するIssueは現在、確定していない項目も含んでいます。実際に2.0がリリースされるタイミングでは 採用されない場合もあります。\nUpgrade master to lucene 5.0 snapshot #8347 (closed) https://github.com/elasticsearch/elasticsearch/pull/8347\n先ほど書きましたが、Luceneの5に対応するためのPRです。 Lucene 5に関してはLuceneのコミッターのMikeさんのブログ記事も参考になります。\nLucene 5に変更することで、BitSetに関する改善が多く含まれることになります。 メモリの利用量、圧縮などの改善が多く含まれています。 もう1点大事な点としては、Lucene 5系ではLucene 3系のインデックスを読み込むことができなくなる点です。 Luceneの下位互換の範囲は1つ前のメジャーバージョン（5.x系の場合は4.xまでが対象）となっています。\nFilter cache: add a _cache: auto option and make it the default.（closed） https://github.com/elasticsearch/elasticsearch/pull/8573\nFilter cacheは、trueもしくはfalseの設定が利用できますが、filterの種類にも依存します。 その辺りの条件を加味しつつ、よしなにCacheをコントロールしてくれます。\nRemove and/or/not in favour of bool filter #8960（open / discuss） https://github.com/elasticsearch/elasticsearch/issues/8960\n似ているが少し異なるand、or、notフィルタとboolフィルタが存在しています。 これらをわかりやすくするために、boolフィルタに統一しましょうという話し合いをしています。\nInput validation #9059（open / discuss） https://github.com/elasticsearch/elasticsearch/issues/9059\n色々な入力に関するチェックを追加しようというIssueです。 たとえば、ディレクトリ名やファイル名、URLのパスやクエリストリング、フィールドのパスやスクリプトなどです。 Validationがあると、変な設定をして頭をかかえることもなくなるかなぁと。\nRefactor analysis framework #8961（open） https://github.com/elasticsearch/elasticsearch/issues/8961\n新しくAnalyzerを作った場合に、色々な場所に登録必要があったりします。インデックスレベルとノードレベルです。（Kuromojiプラグインなどが参考になります。） また、インデックスごとにカスタムのAnalyzerを設定するので、1つのノードに同じAnalyzerを何度も設定しないといけません。 よりシンプルにするために、Analyzerをノード単位で設定しようという提案です。\nRemove possibility for conflicting field definitions and ambiguous field resolution #8870（open） https://github.com/elasticsearch/elasticsearch/issues/8870\n同じインデックスに、異なるtypeで、同じフィールド名があった場合、いろいろと良くないことがあったりします。 たとえば、フィールドのタイプがintegerとstringと異なる場合に、インデックスレベルで検索を行うとうまく検索できなかったりと。 この問題を解消するために、より明確にしようというIssueです。 たとえば、フィールド名を指定するためには、フルパスで記述をするだとか、フィールドマッピングに関してはインデックスレベルで内部で保持をするなど。\nValidation of mappings request to reject unsupported fields #7205（closed） https://github.com/elasticsearch/elasticsearch/issues/7205\n1.xでも取り込まれますが、嬉しい機能なので紹介します。 これまでは、mappingsでスペルミスをした場合（たとえば、field設定で\u0026quot;indexx\u0026quot;といったミス）には、その項目は単に無視されるだけでした。 これが、v1.xでは、エラーに\nまとめ ということで、簡単ですが、v2.0.0に向けたIssueをピックアップして紹介してみました。 上記以外にも多くの改善、提案が2.0に向けて行われています。 興味のある方は、v2.0.0ラベルでIssueを検索してみてはいかがでしょうか？\n今年もあとわずかとなりました。 今年の2月にElasticsearchの1.0がリリースされ、あっという間に1.4なりました。まだまだ改善しています。\n来年もElasticsearchに興味をもっていただければ嬉しいです。 Elasticsearch初のユーザカンファレンスのサイトもオープンしました。 Elasticsearchに関するいろいろな話が聞ける機会だと思います。登録をお待ちしています。\n","date":1419490380,"dir":"post/2014/","id":"cb9649eca3dfbd356527ffc88f1dcb94","lang":"ja","lastmod":1419490380,"permalink":"https://blog.johtani.info/blog/2014/12/25/pickup-elasticsearch-2-0-0-labels/","publishdate":"2014-12-25T15:53:00+09:00","summary":"この記事はElasticsearch Advent Calndar 2014の25日目のエントリです。 あっという間に最終日です。来年につなげるという意味で、Elasti","tags":["elasticsearch"],"title":"Elasticsearch 2.0系のIssueの紹介"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：marvel 1.3.0 released\n12/17に、Elasticsearch Marvel 1.3.0をリリースしました。 Marvelの以前のリリースから、Elasticsearchでは様々なことがありました（Elasticsearch 1.4のリリースなど）。 このバージョンでは、モニタリングにクエリキャッシュや新しいcircuit breakerなどのような機能を追加してあります。 Senseのナレッジベースは最新のAPIを含むものに拡張されています。 また、Shieldのリリースに向けた準備として、HTTPsのサポートも追加しました。\nアップグレードのために、Elasticsearchの全てのノードに最新版のMarvelプラグインをインストールする必要があります。 また、他のJavaプラグインと同様に、Marvelの新バージョンを有効にするために、各ノードを（1台ずつ）リスタートする必要があるでしょう。 アップグレードプロセスについての詳細は、Marvelドキュメントをごらんください。\nまとめとして、ここに本リリースに関する改善点をいかにリストアップしておきます。\nagent 追加： httpsのサポート デフォルトのMarvelの設定（以前は常に9200）ではなく、ローカルノードのポートを自動的に検出 改善： marvelインデックステンプレートに関するエラーチェックと耐障害性(それに対するチェックと追加時のチェック) エラーログに関するくり返しの抑制 URLパラメータによるインデックス名を指定する_bulk exportコマンド。これは、rest.action.multi.allow_explicit_indexがfalseに設定されているときに有用 修正： ES 1.4.0のtribe nodeがMarvelのインストール時に初期化されない問題 削除： UIで表示されないoptional shard level statsを除去 monitoring ui 追加： ES 1.4.0で導入された新しいcircuit breakerを追加 circuit breakerのlimitをグラフにプロット QueryCacheのグラフを追加 index throttlingのグラフの追加 Index writerとバージョンのmapのメモリ使用量のグラフの追加 修正： Network Transport Bytes Receivedグラフに実際の送信量を表示 Node Statsダッシュボードでいくつかのスレッドプールの不足 sense 追加：\nmappingsをインデックスでオートコンプリートするしないの設定を可能に Cluster Reroute API Search APIのQuery Cacheパラメータ Analyze API Validate Query API Put Percolator API cluster.routing.allocation.*設定 Function Scoreクエリのweightパラメータ Flush API Terms Aggregationのshow_term_doc_count_errorパラメータ Update API _geo_distanceソートオプション Significant Terms aggregationを1.4.0にアップデート Mapping APIにメタデータフィールドを追加 Get Index API Scripted Metric Aggregation simple_query_stringクエリ More Like Thisクエリを1.4.0にアップデート has_childクエリ/フィルタのmin_childrenとmax_childrenオプション terms aggs/significant terms aggsのヒントオプション Mappings APIのtransform インデックスされたscriptとtemplate \u0008* Geo Bounds aggregation Top Hits aggregation Terms aggregationのcollect_modeオプション Percentiles Rank aggregation Disk Threshold Allocator設定 修正：\nURLオートコンプリートの挙動（プロトコルとホストのような組み合わせ） nested typeマッピングのinclude_in_parentとinclude_in_rootの不足 Rangeフィルタでのgt、gte、lt、lte Existsフィルタのオートコンプリート Snapshot、Restore APIのリポジトリ設定の時オートコンプリートの失敗 いつものように、Elasticsearch Marvelを改善するために、フィードバックをお待ちしています。 ElasticsearchユーザMLやTwitterに質問や意見お送りください。\n","date":1418890008,"dir":"post/2014/","id":"7dea465ad52758b10cbceb08c81d1760","lang":"ja","lastmod":1418890008,"permalink":"https://blog.johtani.info/blog/2014/12/18/marvel-1-3-0-released-ja/","publishdate":"2014-12-18T17:06:48+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：marvel 1.3.0 released 12/17に、Elasticsearch Marvel 1.3.0をリリースしました","tags":["elasticsearch","marvel"],"title":"Marvel 1.3.0リリース（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch 1.4.3 and 1.3.8 released\n本日、Lucene 4.10.3をベースにしたElasticsearch 1.4.3と、セキュリティフィックスとバグフィックスリリースである、Elasticsearch 1.3.8をリリースしました。 ダウンロードおよび変更リストはそれぞれ次のリンクからアクセスできます。\n最新ステーブルリリース：Elasticsearch 1.4.3 1.3.x系バグフィックス：Elasticsearch 1.3.8 過去のリリースに関するブログ（公式）はこちら。\n1.4:1.4.1, 1.4.0, 1.4.0.Beta1 1.3:1.3.6, 1.3.5, 1.3.4, 1.3.3, 1.3.2, 1.3.1, 1.3.0. すべての変更については1.4.2のリリースノートおよび1.3.7のリリースノートをごらんください。 以下では、重要な変更について紹介します。\nbug fixes Elasticsearchに対して広範囲にわたってランダムなテストを行っています。以下の問題を見つけ、修正するのに役立っています。\nプライマリシャードを持つnodeがレプリカシャードをプライマリから復旧している間に、リスタートした場合に、プライマリ上のトランザクションログが削除されデータをロスする(#8917) scriptインデックスが普及した場合に、ScriptService全体がデッドロック(#8901) Index Writerのロックを強制的に解放することによるシャードの破損(#8892) パフォーマンス改善 複雑な設定をもつ大きめのクラスタをもつユーザは、小さなスケールではわからない性能ボトルネックに直面します。 彼らの報告が次の改善をもたらす助けとなりました。\n使用可能なディスク空間に基づいてシャードの配置を決定する、disk allocation deciderの速度改善とクラスタリスタート後のリカバリ速度の改善(#8803) 以前よりも高速な共有ファイルシステムでのSnapshot生成(#8749) 不要なクラスタ状態変更の削減とそれによるネットワークトラフィックの削減およびリカバリの速度向上(#8933, #8413) index stats APIはシャードリカバリによるブロックしない(#8910) 試してみてください。 ぜひ、Elasticsearch 1.4.2をダウンロードして、試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1418880374,"dir":"post/2014/","id":"bce2fa6458f39a75e2713f3d687271a1","lang":"ja","lastmod":1418880374,"permalink":"https://blog.johtani.info/blog/2014/12/18/elasticsearch-1-4-2-released-ja/","publishdate":"2014-12-18T14:26:14+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElas","tags":["elasticsearch"],"title":"Elasticsearch 1.4.2および1.3.7リリース（日本語訳）"},{"contents":"「【東京】JJUG ナイト・セミナー「機械学習・自然言語処理特集！」12/17（水）開催」でLuceneの話をしてきました。 本当にごく簡単な入門です。 Luceneをさわるきっかけにしてもらえたら嬉しいです。\nそのほかにも面白い話が聞けましたので、簡単ですがメモを。\nJJUGの2014年振り返り だいたい、毎月ナイトセミナーかCCCを開催 イベント系に、のべ3100名が参加 Java でカジュアルにはじめる機械学習 小宮 篤史さん(スマートニュース株式会社) スライド：#JJUG - Java でカジュアルにはじめる機械学習\nブログ：#JJUG ナイトセミナー「機械学習・自然言語処理特集！」で Java でカジュアルに機械学習する話をしてきました\nガチの人は寝ててください。 機械学習でできること 分類・識別 予測・回帰 パターンマイニング・アソシエーションルール クラスタリング 上2つは教師あり学習/下2つは教師なし学習 データとしては、日構造では扱えないので、「特徴量」を抽出して「特徴ベクトル」を作って、処理をするのが機械学習 得られた結果の正しさの測定などなど\n機械学習の実装は辛いので、車輪の再発明をやめましょう！ \u0008Javaで使える機械学習\nWeka：とりあえず使ってみるならこれ？ MLlib：Sparkで使われてる Mahout：オワコン？ SAMOA：Stormの上で利用できる Jubatus：Javaクライアントあり。 h2o：Deep learningをJavaでやるなら、これ。 ほかにもあったけど、スライド見ていただければ。 機械学習をはじめるのに使えるデータセット\nUCI Machine learning repository\nIris（アヤメデータ）は機械学習界のHello world Wekaを使ったサンプルコード\nSpark/MLlibではじめるスケーラブルな機械学習 猿田 浩輔さん(株式会社エヌ・ティ・ティ・データ) スライド：（後日、リンクがあれば更新予定）\n\u0008* Spark+MLlibを語る上で外せない話題\nHadoopとの違い？\nまずはHadoopの話\nHadoopによるK-meansのデモ\nHadoopの問題点に対するSparkの解決策\nSpark 1.0系からJava8で書ける\nQA：\nQ： データをキャッシュできるという話でしたが、キャッシュするということは、ジョブが途中で失敗した場合は最初からやり直しになるのでしょうか？ A： キャッシュしたデータが残っている場合は、途中から再開出来ます。キャッシュしたデータを持ったマシンがこけたら、最初からやり直しです。\nLuceneと日本語の検索 自分 スライド：Luceneと日本語の検索 サンプルのリポジトリ：jjug-example\n自然言語処理にからめて何か話をしてくださいと話を受けていたのですが、自然言語処理については「形態素解析」くらいしか出てこなかったですけど。。。 Luceneがどんなものかを超概要で話をしてみました。少しでもLuceneがどんなものかをわかってもらえたら嬉しいです。\nもっと詳しく知りたい方は、スライドにある参考資料などを見ていただければと。\nJavaで書くのもいいんですが、もっと簡単に検索したい場合はElasticsearchを使うのが便利ですよ！で締めくくりたかったのですが、発表では失敗してしまいました。。。 Elasticsearchの起動からデータ登録、検索まではこちらのスライドを見ていただければ簡単さがわかると思います。\nまた、Kuromojiを利用した時に、Tokenizerなどが出力するTokenの品詞情報を見たい場合に便利なElasticsearch用プラグインも作っています。 こちらも、Elasticsearchと一緒に使ってみてください。\nまとめ 機械学習に関していろんなツールがあるのだなぁと。 懇親会でもちょっと話しましたが、アルゴリズムの選定とか、アルゴリズムに適したデータの作成など、前処理のノウハウとかが大変そうだなぁといつも思います。 機械学習はいつもぼやーっとしか理解してないので。。。\nJJUGさんはYouTubeの動画もあるようなので、過去の面白そうなセミナーも合わせてみてみると面白いと思います。\n毎度のことですが、なんでも良いので、発表した後のフィードバックをいただけるとうれしいです。 今後の励みや改善につながるので。\n","date":1418809314,"dir":"post/2014/","id":"e5390751969ab21df280b7591854b89f","lang":"ja","lastmod":1418809314,"permalink":"https://blog.johtani.info/blog/2014/12/17/jjug-night-seminar-dec-2014/","publishdate":"2014-12-17T18:41:54+09:00","summary":"「【東京】JJUG ナイト・セミナー「機械学習・自然言語処理特集！」12/17（水）開催」でLuceneの話をしてきました。 本当にごく簡単な入","tags":["elasticsearch","jjug"],"title":"JJUG ナイトセミナーでLuceneの簡単な紹介をしてきました。#JJUG"},{"contents":"たまには、他愛のないブログを。\n仕事しながら、コーヒーを飲んでます。\n最近は、サムライズムさんのオフィスに入り浸って仕事してます。 オフィスには、コーヒーミル付きのコーヒーメーカーがあるんです。\n↓こんな感じ（現物は違うけど）\nで、近所のコーヒー問屋で豆を買ってきてます。 そこのマスターに、いつもサジェストされるんです。\n「この豆は、日が経つにつれて、細かく挽いて飲んでください。」\n「この豆は、細かめに挽いて飲むのがオススメです。」\nなどなど。 オススメされるんですが、全自動のコーヒーメーカーは残念ながらここまでやってくれません。\nということで、手動のミルを買ってみました。家でも使えるし。\nちょっと考え事しながらとか、頭の切り替えに、ミルを回すのもいいかなと。 気持ち、美味しいコーヒーな気がします（気のせいかも）\n","date":1418698892,"dir":"post/2014/","id":"05330c3703d0e2c96cfe657ab33f130c","lang":"ja","lastmod":1418698892,"permalink":"https://blog.johtani.info/blog/2014/12/16/a-coffee-break/","publishdate":"2014-12-16T12:01:32+09:00","summary":"たまには、他愛のないブログを。 仕事しながら、コーヒーを飲んでます。 最近は、サムライズムさんのオフィスに入り浸って仕事してます。 オフィスには、","tags":["misc","coffee"],"title":"コーヒーブレイク"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：exciting logstash plugin ecosystem changes\nLogstash 1.5.0 Beta 1(お試しはこちら)のリリースで、 プラグインのインストール、管理、公開の方法を変更しています。 ユーザやコミュニティからフィードバックをもらいました。 その目的は、プラグインの利用や開発をより簡単にすることです。 このプロジェクトは始まったばかりです。プラグインのコミュニティを探し、 共有するためのワンストップソリューションを提供するこのアイデアを改善していく予定です。 このブログで、この決定を行った理由を説明し、新しいワークフローをと今後のロードマップを説明します。\nプラグインがあります！ Logstashは、プラグイン（input、filter、output、codec）が豊富にあります。 これらは、Elasticsearchにより開発されたものと、コミュニティからコントリビュートされたものです。 Logstashの主な特長の1つは、これらのプラグインの有効性と動作を拡張するプラグインを追加するのが簡単なことです。 現在、165以上のプラグインがエコシステムにあり、これらは、2つのプロジェクトに分かれています。\nlogstash-coreは最もよく使われるプラグインで、Logstashにデフォルトで含まれます logstash-contribはコミュニティにより開発されたプラグインを含み、別途ダウンロードできます 新プラグインエコシステムの変更 1.5.0では、全てのプラグインは、Logstashコアから分離され、rubygemsを使って個別にパッケージングされます。 rubygemsを選択したのは、依存関係のあるライブラリの配布とパッケージングがパワフルで一般的なものだからです。 さらに、rubygems.orgプラットフォームは配布や探索に影響があります。 また、Logstashにプラグインをインストール、アップデート、削除するのが簡単な基盤も追加しました。 contribプロジェクトは徐々に終了します。全てのプラグインは個別のプロジェクトになります。\nプラグインエコシステム変更の理由 多数のプラグインをもっていると、配布と公開に関して難題が出てきます。 私たちが変更するに至った理由は次のようなものです。\n現在は、プラグインの更新に伴い、Logstashの新バージョンのリリースが必要 開発者は、Logstashのリリース間隔とは別に、新バージョンをリリースをしたい プラグイン開発者は、外部依存を記述できるようにしたい Logstashコアの配布パッケージのダウンロードサイズを小さくし、ユーザは必要なプラグインのみインストール logstash-contribを1つのリポジトリとして管理するのは難しい 詳細： ソースコードの場所 Logstashのソースコードは、今後も現在のGitHubのリポジトリのままです。 しかし、プラグインに関するコードやテストコードは含まなくなります。 この分離により、個別のプラグインの改善と同様にコアの改善に集中できます。 これにより、Logstashプロジェクトの全体の品質も向上します。\n全プラグインのソースコードは、新しいGitHub organization、logstash-pluginsにて管理します。 各プラグインは個別のリポジトリとして、ここに配置されます。 一見すると、これはメンテナンスが難しくなるように思えます。しかし、テスト、Issue、依存関係を明確にすることができます。 私たちの目的は、テスト、ドキュメント、gemの公開の自動化であり、これを簡単にするためのツールを追加します。\nしかし、プラグインの開発者はプラグインのソースコードソースコードをlogstash-pluginsに置く必要はありません。 ー コミュニティで利用可能にするために、rubygems.orgでそれを公開するだけで良いです。\nワークフロー ここで、新プラグインエコシステムのやりとり/ワークフローについて、いくつかの観点から説明します。\nlogstashユーザ: ユーザは、これまでのリリース同様にLogstashのバイナリをダウンロードします。 Logstash 1.5.0は、1.4.2でパッケージされていたプラグインと同等のものが含まれています。 新しいシステムに簡単に移行できるようにです。 そして、ユーザは、最初のデプロイの後に、Logstashプラグインのをインストール、アップグレードできるようになります。\n$LS_HOME/bin/pluginスクリプトがプラグイン操作に関連するコマンドになります。\nプラグインのインストール プラグインのほとんどはgemとしてrubygems.orgにアップロードされます。 例えば、もしユーザがApache Kafka outputプラグインをインストールする場合、次のコマンドを実行します。\nbin/plugin install logstash-output-kafka または、ファイルをダウンロード済みの場合は次のコマンドとなります。\nbin/plugin install /path/to/logstash-output-kafka-1.0.0.gem プラグインの削除 bin/plugin uninstall logstash-output-kafka 1つまた全プラグインのアップデート bin/plugin update bin/plugin update logstash-output-kafka プラグインのリストアップ bin/plugin list bin/plugin list elasticsearch ( List all plugins containing a name ) bin/plugin list --group output ( list all outputs ) ドキュメント プラグインが個別に管理されても、全プラグインのドキュメントは1カ所です。\nlogstash plugin開発者: プラグイン開発者と作者は、Logstashエコシステムのためにプラグインを公開することができます。 プラグインは、gemやJavaライブラリの依存関係を宣言できます。 より重要なのは、Logstashのリリース間隔に関係なく、プラグインの改善版をリリースできます。\nRubygemsテクノロジはパッケージングシステム、依存関係管理、ホスティングのために選択されてきました。 Rubyのgemを公開することに慣れている開発者は、Logstashプラグインを簡単に公開することができます。 Elasticsearchはこれらの機能に関して開発者を支援するために、ツールを提供、メンテナンスします。\n開発およびローカルでのテスト JRuby 1.7.16がプラグインを開発するための唯一の前提条件です。 プラグインにパッチを提供するのは以前と同様です。 例えば、logstash-output-kafkaにパッチを送るのは次のようになります。\ngit clone https://github.com/logstash-plugins/logstash-output-kafka.git 変更 プラグインをローカルでテスト bundle install bundle exec rspec Logstashの他のバージョンもしくはローカルでテストする場合、Gemfileを編集し、 次のように別のロケーションを加えます。gem \u0026quot;logstash\u0026quot;, :github =\u0026gt; \u0026quot;elasticsearch/logstash\u0026quot;, :ref =\u0026gt; \u0026quot;master\u0026quot; 新しいPull Requestをlogstash-output-kafkaに対して作成 コミュニティでコードレビューを受け、Elasticsearchがパッチを受け入れ バージョン バージョン情報は、それぞれのプラグインの.gemspecで管理します。 例えば、Apache Kafka outputのgemspecはこちらです。 バージョニングはsemantic versioningのルールに従い、 Logstashのバージョニングとは別に、プラグインの開発者によって管理されます。 Logstash 1.5.0がリリースされると、マイルストーン1のプラグインはバージョン1.0.0となり、マイルストーン2のプラグインはバージョン2.0.0となるでしょう。\n公開 開発者が変更を加えプラグインを公開したいと思った時、.gemspecのバージョン番号を変更します。 全テストが成功した時、Elasticsearchはrubygems.orgにプラグインを手動で公開します。 もし、テストが失敗した場合、プラグインは公開されません。 長期的には、プラグインの公開の自動化を行いたいと思っています。 この変更は新しいため、公開の自動化を提供する前に、自動化についてより理解し、プラグインのテスト基盤を改良したいと思っています。\nIssue Issueは、各プラグインのGitHubリポジトリに対してオープンなければなりません。 Logstashコアのリポジトリは、コアのパイプラインや共通的な機能に関連するIssueについて扱います。\nドキュメント プラグインのドキュメントはソースコード自体から生成されます。 それぞれのプラグインのドキュメントは、そのプラグインのリポジトリに含まれます。 Elasticsearchは elasticsearch.org/guideに全てのプラグインのドキュメントを集め生成できる基盤を提供します。\n移行 全ての新しいpull requestとissueはlogstash-plugin organisation配下にある各プラグインのリポジトリに対してオープンする必要があります。\nすでにあるPRはどうすれば良いですか？ 気にしないでください。すでにあるpull requestは開発者によって移行する必要はありません。 LogstashチームがLogstashコアリポジトリに対してのPRを、個別の関連するプラグインのリポジトリに対してマージします。\ngit clone … # clone the specific plugin repo # now apply the patch curl -s https://github.com/elasticsearch/logstash/pull/XXXX | git am --3way git push Note:このプロセスはすでにあるPRに対してgit historyを管理します\nGitHub Issue 現在、LogstashリポジトリにオープンされているIssueは、それぞれのプラグインのリポジトリに移行します。 Logstashチームがgithub.com APIを利用してこの処理を自動的に行います。 安心してください。私たちが個別のプラグインに対する既存のIssueを移行します。\n今後のロードマップ これは、最初のステップであり、これらの変更は、ユーザや開発者に対してエコシステムをよりよくするために、 しっかりとした基盤を提供します。\n短期的には、開発者のためにpull requestのフィードバックでテスト自動化を提供する基盤を追加していきます。 プラグインリポジトリのブートストラップや管理のためのツールも提供していきます。\n長期的には、すべてのLogstashプラグインを探し、公開するためのコミュニティポータルを提供したいと思っています。 このアイデアは、Puppet ForgeやAWS marketplaceのようなものです。\nLogstash 1.5.0 Beta 1をリリースし、これは新しいエコシステムを提供します。 ぜひ、試していただき、これらの変更に関して感じたことを教えてください。 あなたのフィードバック(TwitterもしくはGitHub)はとても貴重です！\n","date":1418486440,"dir":"post/2014/","id":"4a3c42c9c5ac29db268010bbebf4f579","lang":"ja","lastmod":1418486440,"permalink":"https://blog.johtani.info/blog/2014/12/14/plugin-ecosystem-changes/","publishdate":"2014-12-14T01:00:40+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：exciting logstash plugin ecosystem changes Logstash 1.5.0 Beta 1(お試しはこちら)のリリースで、 プラグインのインストー","tags":["logstash"],"title":"Logstashプラグインのエコシステムの変更（日本語訳）"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：logstash 1.5.0.beta1 released\nLogstash 1.5.0 Beta1をリリースしました。こちらのページからダウンロードできます。\nNote: ベータリリースです。本番環境では使用しないでください。\n1.5.0の主な変更点は？ 1.5.0の主なテーマはプラグイン管理、パフォーマンス改善、Apache Kafkaインテグレーションです。Logstashの主な特徴の1つは プラグインを利用できることであり、パイプラインの動作を拡張するためにプラグインを追加するのが簡単なことです。 このリリースで、プラグインの開発、管理、公開がより簡単になります。 また、Logstashの速度をより良くしたため、より多くのデータを短時間に処理することができます。 興味ありませんか？では、詳細を見ていきましょう。\nplugin ecosystemの変更 Logstashは165ものプラグイン(inputs、filters、outputs、codecs)を持っており、 これらはElasticsearchとコミュニティからのコントリビュートで開発されています。 多くのプラグインを管理することは、使いやすさと素早さの間のトレードオフがあります。 Logstashの全てのプラグインをまとめることは使いやすさがある一方、プラグインの更新を取り込むために Logstashの新しいリリースを待ってもらうことになります。 Logstashからプラグインを分離して個別に配布する場合、更新は簡単になりますが、使いやすさ（特に新しいユーザに）に影響が出ます。\n私たちは、プロジェクトを前進させるために、これらのバランスをとることを考えました。 これまで、全ての利用可能なプラグインは’core’と\u0026rsquo;contrib\u0026rsquo;の2つに分割していました。 \u0026lsquo;core\u0026rsquo;にあるよく使われるプラグインは、Logstashに含めていました。 コミュニティによりコントリビュートされたプラグインは\u0026rsquo;contrib\u0026rsquo;パッケージとして分離して配布していました。 1.5.0のリリースで、ユーザに対してより良いプラグイン管理をできるように変更しました。 全てのプラグインは、それ自身によるパッケージに移行しました。 パッケージングフレームワークとしてrubygemsを使い、rubygem.org経由でこれらのプラグインを配布、公開します。 また、Logstashにプラグインのインストール、更新、削除を簡単にするための構造も追加しました。\n例えば、S3 output pluginをインストールするには、以下のコマンドを実行します。\n$LS_HOME/bin/plugin install logstash-output-s3 それだけです！Logstashがgemと依存するgemをrubygems.orgからダウンロードし、インストールします。 あなたは、S3にデータを送ることができるようになります。\nダウンロード可能なLogstashリリースはプラグインをまだ多く含んでいますが、 いつでも、個別にプラグインをアップグレードし、インストールすることができます。 プラグインエコシステムの変更に関する詳細のブログ記事をお待ち下さい。\nパフォーマンス改善 Logstash 1.5.0はより高速になっています。パフォーマンスが改善された2カ所について説明します。\ngrok filter Grok filterはLogstashで、構造化データを抽出するためにパターンを記述するのに使われます。 本リリースで、人気のある幾つかのパターンのgrok filterのスループットを100%に改善しました。 言い換えると、grok filterを使うときに、Logstashを通してより多くのデータを処理することができます。\n私たちのベンチマークテストで、1.5.0と1.4.2のスループットの比較をしました。 利用したデータは690万件のApache Webアクセスlogで、COMBINEDAPACHELOGのgrok patternです。 1.5.0で、スループットは34,000 event per sec(eps)から50,000 epsに増加しました。 両方のテストを8コアのマシンでLogstashで8つのワーカーを実行しました。 これらのテストで、一つのgrok filterを実行し、 stdinとstdoutを使ったパイプラインでイベントのスループットを計測しました。 全体的なパフォーマンスは、様々なハードウェアやLogstashのコンフィグによって変化することに注意してください。\njson serialization / deserialization JSONのシリアライズ/でシリアライズをJrJacksonライブラリを利用して実装しました。 これにより、100%以上のスループットの改善がありました。 先ほど説明したパフォーマンステストにおいて、1.3KBのサイズの500,00 JSONイベントを送信し、 16,000 epsから30,000 epsにスループットが改善しました。 45,000サイズのイベントで、850 epsから3500 epsにスループットが増加しました。 すばらしいです。\napache kafka integration いまでは、Apache Kafkaが大規模スケールデータ処理システムでよく利用されます。 Logstashの配備のスケーリングにおいて、Kafkaもまた、shippingインスタンスとindexingインスタンス間の データを保存するための中間メッセージバッファとして使うことができます。\n1.5.0で、Logstash Kafkaのinputとoutputのプラグインのビルトインサポートを追加しました。 これは、Joseph Lawsonによって最初に開発されました。 私たちは、これらのプラグインにインテグレーションテストとドキュメントを追加することにより改良し、 新しいKafkaの機能を開発し続けます。 また、Apache Avro codecを追加することで、Kafkaに保存されたイベントを 簡単に取得でき、ELKスタックを使ってそれらを解析できるようにしました。\nKafka inputを追加するのは次のコマンドです。\n$LS_HOME/bin/plugin install logstash-input-kafka Kafka outputは次のコマンドです。\n$LS_HOME/bin/plugin install logstash-output-kafka セキュリティに関する改善 認証と経路暗号化のサポートを追加し、Elasticsearchのoutput、input、filterのセキュリティを改良しました。 例えば、HTTPプロトコルでSSL/TLSにより暗号化を有効にでき、 HTTPベーシック認証をユーザ名とパスワードをリクエストに与えることで設定できます。 これらの機能は、時期にリリースされるElasticsearch ShieldセキュリティプロダクトとLogstashを統合できます。\nドキュメント これまで、Logstashのドキュメントは[logstash.net])(http://logstash.net/)に置いてあり、 他のELKスタックと一緒に動かす時に、情報を探すのが厄介でした。 1.5.0および、今後のバージョンのドキュメントはelasticsearch.orgのLogstash Guideに移行します。 この移行でelasticsearch.org/guideにELKスタックを利用、 学習するためにドキュメントが1つになりました。 このベータリリースのイテレーションで、私たちはプレゼンテーションとドキュメントの品質を改善することに活発に取り組んでいきます。 (過去のLogstashのドキュメントの全てはいままでのlogstash.netで引き続き公開していく予定です。)\nバグフィックスと改善 ここまでの新しい機能に加えて、Logstash 1.5.0では、多くのバグフィックスと多くの機能改善があります。 ここで、これらのいくつかを紹介します。\n出力しない\u0026rsquo;metadata\u0026rsquo;をイベントに格納可能に。これは、例えば、date filterに使う中間フィールドのために必要。(#1834, #LOGSTASH-1798) HTTPを利用しているときのファイルデスクリプタリークの修正。Logstashがストールするのを防ぎ、OOMエラーからクラッシュするケースも防ぎます。(#1604) Twitter input:full_tweetオプションの追加、Twitter rate limitingエラーのハンドリング(#1471) イベントを生成するfilter(multiline、clone、split、metrics)により、 後続の条件文にこれらのイベントを正しく伝搬(#1431) Elasticsearch output:Logstashはデフォルトでmessage.rawフィールドを作成しない。messageフィールドはElasticsearch によりnot_analyzedでマルチフィールドとして追加される。マルチフィールドはディスクスペースが2倍必要だが、利点がない。 bin/logstashの複数のサブコマンドを除去(#1797) これらの機能、改善、バグフィックスについては、Logstash 1.5.0.Beta1 のchangelogをごらんください。\n試してみてください！ ぜひ、Logstash 1.5.0 Beta 1をダウンロードして試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1418372246,"dir":"post/2014/","id":"1bc36080b2493aab78c26e4f2152542c","lang":"ja","lastmod":1418372246,"permalink":"https://blog.johtani.info/blog/2014/12/12/logstash-1-5-0-beta1-released-ja/","publishdate":"2014-12-12T17:17:26+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：logstash 1.5.0.beta1 released Logstash 1.5.0 Beta1をリリースしました。こちらのページからダウンロードで","tags":["logstash"],"title":"Logstash 1.5.0 Beta1リリース(日本語訳)"},{"contents":"早いもので、師走です。今年もあと少しとなりました。ということで、Advent Calendarの季節が始まりました。\nこの記事はElasticsearch Advent Calndar 2014の1日目のエントリです。\n1日目ということで、簡単に今年の変遷を振り返りつつ、今年導入された新機能についてピックアップしてみようかと思います。\n1.0リリース(Lucene 4.6.0) 今年一番の目玉と思いますが、1月にRCが公開されて、1.0.0が2月にリリースされました。 （ElasticSearch Serverの翻訳が昨年末に終わってレビューをしていた段階での発表だったので個人的にはきついタイミングでした） 1.0の主な変更点はこちら。\nElasticsearch（Sが小文字に） 1.0からSが小文字になりました。(#4634) 0.90以前のバージョンについては、Sが大文字になっています。 ややこしいですが、今年の3月に出版された黒いElasticSearch Server日本語版は原著が0.20で日本語版にするタイミングで0.90に対応しました。 このため、こちらの書籍のタイトルはSが大文字となっています。 （なお、原著の2nd Editionは小文字になっています）\nSnapshot/Restoreの導入とGatewayの廃止 0.90以前のバージョンでは、gatewayというモジュールで、S3などにインデックスのメタデータなどを保存する機能がありました。 この機能は、0.20からlocal以外はdeprecatedとなりました。\nインデックスのバックアップ、リストアのために、1.0で実装されたのがSnapshot/Restoreです。 Snapshot/Restoreでは、インデックスごと、もしくはクラスタ全体をリモートにあるリポジトリにスナップショットを取ることが可能となりました。 初期リリースの段階では、共有ファイルシステムのみでしたが、現在は、S3やHDFSなどに保存が可能となっています。\nAggregation Facetをより強力にしたものです。Facetでは、指定したフィールドの集計のみでした。 データの解析などを行うには、独自で集計する必要がありました。 この機能をより柔軟に行えるように実装したのがAggregationです。\nたとえば、アクセスログを日毎に集計し、さらに日毎の集計に対して国別の集計やユーザエージェントごとの集計をさらに行うといった感じです。 Facetの場合は、日毎の検索結果に対して個別に集計するのみでしたが、Aggregationを使うことで、1週間の検索結果に対して、 日毎に国別の集計を行うといったことが可能になっっています。\ncat API \u0026ldquo;=^.^=\u0026ldquo;猫が出てくるAPIです。(違う)\nElasticsearchでは、クラスタの状態などが全てREST APIで取得でき、JSONで結果が帰ってきていました。 JSONはプログラムなどで処理を行う場合は便利ですが、コンソールで確認したり、管理系のツールでメールで通知する場合などは見にくいことがあります。 これを解消したのが_cat APIです。（公式の紹介ブログはこちら）\nCircuit Breaker OOMが発生しそうなfielddataの読み込みを検知して、事前に防ぐ機構になります。 初期段階ではFielddataに対してのものから実装されました。\n1.1リリース(Lucene 4.6.1) 3月にリリースされました。Elasticsearchはまだまだ発展しているため、リリースのサイクルが短いのが特徴です。\n1.x系では、Rolling Upgradeが導入されました。このため、クラスタ全体を停止することなく、クラスタのアップグレードが可能になりました。\nsearch templates 検索クエリをテンプレートとして登録することができるsearch templatesです。 JSONでクエリを記述できるのは便利ですが、毎回組み立てるのは大変かもしれません。 特に、固定のクエリをプログラムから利用するような場合などです。 テンプレートとして登録しておくことで、検索時に値を埋め込むだけで検索ができるようになりました。\nAggregationの強化 Aggregationの種類が増えました。\ncardinality：ユニークユーザ数の集計などが行えるaggregationです。HyperLogLog++アルゴリズムを利用した実装になっています。 significant_terms：単語の数による集計ではなく、コレクション全体に対する単語の頻度と、検索結果に対する単語の頻度を計算することで、重要度を計ることができます。 percentiles：パーセンタイル値を計算できます。 1.2リリース(Lucene 4.8系) Java 7必須 利用しているLuceneがJava 7必須となったためです。また、Java 6のEOLも切れてますし。\ndynamic scriptingがデフォルトオフ 採用していたMVELがサンドボックス化に対応していないため、危険を回避するためにオフとなりました。\nインデキシングとマージング インデキシングとマージ処理に関するさまざまな改善。\nflushのthreasholdを操作回数ではなく、サイズや時間によるものに変更 デフォルトをConcurrentMergeSchedulerに変更 1.3リリース(Lucene 4.9.0系) セキュリティ関連 JSONPのデフォルトオフ MVELの非推奨化（1.4で削除）＋script.disable_dynamicのデフォルト値がsandbox aggregationの強化 top hits：Field Collapsing/combiningと呼ばれる機能です。たとえば、いくつかのサイトのHTMLを収集して検索機能を提供する場合に、ドメインごとに1件ずつ検索結果に出したい場合などに利用できる機能です。 その他にも以下のaggregationが追加されています。\npercentile ranks geo bounds mappingのtransform Mappingにtransform機能が追加されました。 mappingにドキュメントの値を元に、インデキシング時に変換処理を記述できます。 たとえば、特定のフィールドにある値がある場合にだけ、あるフィールドに値を入れるなどといったことが可能になります。\nディスク関連 disk based shard allocation deciderが導入されました。ノードのディスクの使用率を元に、シャードを配置しても良いかといった決定を行う機構です。 チェックサムによるファイルのチェック（Lucene4.9で導入されたコードへの切り替え） 1.4リリース(Lucene 4.10系) ベータ版が出されるほど、多くの改善が入っています。\nresiliency メモリ使用量の低下によるノードの安定性向上 DocValues、リクエストごとのcircuit breakerなど discoveryアルゴリズムの改善によるクラスタの安定性向上 チェックサムの導入による破損したデータの検知 セキュリティ関連 CORSをデフォルト無効 Groovyがデフォルトのスクリプト言語に。 Aggregationの強化 以下のaggregationが追加されています。\nfilter、children、scripted_metric Upgrade API インデックスを最新のバージョンのものにアップグレードするためのAPIです。 Luceneは下位互換を保ってくれているため、古いバージョンのインデックスも読み込むことが可能です。 ただ、最新バージョンで使える機能が制限されていたりということもあります。 クラスタにあるインデックスをアップグレードするのにかかる時間や必要かどうかといったことを取得できる仕組みも提供します。\nまた、Lucene自体は、1つ前のメジャーバージョン（4.x系だと3.x系まで）までの互換性は提供していますが、 2つ前のメジャーバージョンの互換性がなくなります。 Luceneも5.x系のブランチが作成されており、5系のリリースにより、3系との互換性がなくなります。 5系のリリースに対応する場合にも、こちらのAPIが助けになるかと。\n1.4.1 11\u0008/27に1.4.1がリリースされました。 シャードの配置やparent/child、nestedドキュメントの改善などが行われています。\nまとめ ということで、駆け足で、1月から11月までのElasticsearchの流れを追ってみました。 1.0で大きな機能追加、改善が行われ、その後も活発に開発が行われています。 要望などがあれば、MLで聞いてみたりやGitHubに登録するなどを行っていただければと。\nあと、今年から来年にかけての大きなイベントとして、 Elasticsearch初のユーザカンファレンスのサイトがオープンしました。 Elasticsearchに関するいろいろな話が聞ける機会だと思うので、興味のある方は見ていただければと。\nでは、また次のAdvent Calendarで！（最終日の予定ですが、空きがあるのでなにか書くかも）\n","date":1417424748,"dir":"post/2014/","id":"2de582c67fca31500621ecd6d3917a07","lang":"ja","lastmod":1417424748,"permalink":"https://blog.johtani.info/blog/2014/12/01/about-elasticsearch-in-2014/","publishdate":"2014-12-01T18:05:48+09:00","summary":"早いもので、師走です。今年もあと少しとなりました。ということで、Advent Calendarの季節が始まりました。 この記事はElastics","tags":["elasticsearch"],"title":"2014年のElasticsearch"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch 1.4.1 and 1.3.6 released\n本日、Lucene 4.10.2をベースにしたElasticsearch 1.4.1と、バグフィックスリリースである、Elasticsearch 1.3.6をリリースしました。 ダウンロードおよび変更リストはそれぞれ次のリンクからアクセスできます。\n最新ステーブルリリース：Elasticsearch 1.4.1 1.3.x系バグフィックス：Elasticsearch 1.3.6 過去のリリースに関するブログ（公式）はこちら。\n1.4:1.4.0, 1.4.0.Beta1 1.3:1.3.5, 1.3.4, 1.3.3, 1.3.2, 1.3.1, 1.3.0. すべての変更については1.4.1のリリースノートおよび1.3.6のリリースノートをごらんください。 以下では、重要な変更について紹介します。\nshard allocation Elasticsearch 1.3.0で、disk based shard allocationが デフォルトで有効になっています。 もし、ノードのディスクの使用量がlawで指定された値（85%）を超えた場合、ノードにはシャードが配置されません。 また、highで指定された値（90%）を超えた場合、シャードを他のノードへ移動します。\nElasticsearch 1.4.1では、disk based shard allocationに3つの改良が追加されました。\nディスク使用量のチェックはシャードがクラスタに配置されるタイミングでのみ実施していた。現在は60秒ごとに使用量をチェック。(#8270) ディスクフルメッセージはDEBUGレベルでログに出力されていました。なぜ、新しいシャードが配置されないのかを説明するのが困難でした。現在はWARNレベルで30秒ごとにログに出力されます。(#8382) 以前は、シャードをもう一つのノードへ動かすべきかどうか決めるとき、allocation deciderはノードにあるシャードのサイズを考慮するだけでした。現在は、動かされるシャードのサイズも考慮します。これにより、必要最小限のシャードの移動量となります。(#8569) parent/child and nested documents Elasticsearch 1.4.0で、parent/childとnestedドキュメントに対して（新しいセグメントを開くときに）固定長ビットセットフィルタを構築しキャッシュしました。クエリ、フィルタおよびAggregationを常に速くするためにです。 多くのnestedフィールドを持つユーザにとっては、以前のバージョンよりもヒープの使用量が大きくなってしまいました。\nnested aggregationによって処理されるドキュメントの順序を変更すること(#8454)によって、固定長ビットセットフィルタが子のドキュメントに対して必要でなくなりました。 現在は、親のドキュメント（つまり、nestedではないドキュメント）を表すフィルタのみをキャッシュしています。これにより必要なキャッシュ空間のサイズを減少しました。(#8414、#8440)\ndate ranges 2つの日付範囲に関する問題がこのリリースで修正されました。 1つ目は、日付を丸めるかというものです。例えば、timestampフィールドに1秒の解像度の値があるとします。 {\u0026quot;lt\u0026quot;: \u0026quot;2014/11/26||/d\u0026quot;}というrangeフィルタは2014/11/26 00:00:00未満のタイムスタンプのデータを結果として返しました。 しかし、ltをlteに変更した場合、2014/11/27 00:00:00以外の値も含めたいです。\n以前は、lteは2014/11/27 00:00:00のタイムスタンプも含めてしまっていました。現在は、想定通りの動作をします。(#8556)\n2つ目のバグは日付の範囲条件にnow()を利用したaliasとpercolatorフィルタです。 now()の値を、フィルタが作成したタイミングで決定していました。フィルタが実行されるたびに更新せずにです。 #8534で、now()はaliasとpercolatorで想定通りの動作をします。\n試してみてください。 ぜひ、Elasticsearch 1.4.1をダウンロードして、試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1417056212,"dir":"post/2014/","id":"0a8183ced0e9e3e895b41286e54e8e4d","lang":"ja","lastmod":1417056212,"permalink":"https://blog.johtani.info/blog/2014/11/27/elasticsearch-1-4-1-released-ja/","publishdate":"2014-11-27T11:43:32+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.1 and 1.3.6 released 本日、Lucene 4.10.2をベースにしたElas","tags":["elasticsearch"],"title":"Elasticsearch 1.4.1および1.3.6リリース（日本語訳）"},{"contents":"前回の「Logstashを利用したApacheアクセスログのインポート」の続きです。 前回の記事では、Logstashの設定ファイルについて説明しました。 今回は「Elasticsearchに設定するインデックステンプレート」について説明します。\nテンプレートの設定 Elasticsearchでは、登録するデータの特性に合わせてMappingを定義する方がデータを効率良く扱うことができる場合があります。 この場合、通常ですと、インデックス作成時にMappingを指定します。\nただ、今回は、インデックス名に「年」を含める形で指定してあります。 「年」はLogstashで処理したデータによって決まります。このため、あらかじめMappingを指定してインデックスを作成するのは難しいです。\nこのような場合に便利な機能として、「インデックステンプレート」があります。\nインデックステンプレートとは 実際のテンプレートの説明に入る前に、少しだけ説明を。 インデックステンプレートとは、インデックスが作成されるタイミングで自動的に適用される設定をテンプレートとして登録できる機能のことです。 実際にテンプレートが適用されるかどうかは、インデックス名で判断されます。\n例えば、大して重要でもなく、データ量も少ないインデックス用のテンプレートとして、シャード数が1、レプリカ数が0、\u0026quot;_source\u0026quot;を保存しない設定のテンプレートを登録する場合、 次のようになります。\ncurl -XPUT localhost:9200/_template/template_1 -d \u0026#39; { \u0026#34;template\u0026#34; : \u0026#34;te*\u0026#34;, \u0026#34;settings\u0026#34; : { \u0026#34;number_of_shards\u0026#34; : 1, \u0026#34;number_of_replicas\u0026#34; : 0 }, \u0026#34;mappings\u0026#34; : { \u0026#34;type1\u0026#34; : { \u0026#34;_source\u0026#34; : { \u0026#34;enabled\u0026#34; : false } } } } \u0026#39; _templateがインデックステンプレートを登録するためのエンドポイントです。 template_1がこのテンプレートのIDです。削除などについては、このIDを利用します。\nそして、重要なのは、\u0026quot;template\u0026ldquo;の設定です。 \u0026ldquo;template\u0026ldquo;には、このテンプレートが適用されるべきインデックス名を記載します。 上記サンプルではte*となっているため、teで始まる名前のインデックスを作成した場合にテンプレートにある設定が適用されます。\n今回利用するテンプレート 私がJJUG CCCや第7回Elasticsearch勉強会のKibana4のデモで利用したインデックスのテンプレートは次のものになります。 \u0026ldquo;template\u0026ldquo;には、前回の記事で紹介したoutput/elasticsearchの設定 に合致するnew_demo_access_log-*を指定しています。\ncurl -XPUT localhost:9200/_template/new_access_log_for_demo -d \u0026#39; { \u0026#34;template\u0026#34;: \u0026#34;new_demo_access_log-*\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;number_of_shards\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;number_of_replicas\u0026#34;: \u0026#34;0\u0026#34; }, \u0026#34;mappings\u0026#34;: { \u0026#34;_default_\u0026#34;: { \u0026#34;dynamic_templates\u0026#34;: [ { \u0026#34;string_template\u0026#34;: { \u0026#34;mapping\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;match_mapping_type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;match\u0026#34;: \u0026#34;*\u0026#34; } } ], \u0026#34;properties\u0026#34;: { \u0026#34;path\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;multi_field\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;no_analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;referer\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;multi_field\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;no_analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;agent\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;multi_field\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;no_analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, \u0026#34;geoip\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;object\u0026#34;, \u0026#34;properties\u0026#34;: { \u0026#34;location\u0026#34;: { \u0026#34;geohash\u0026#34;: true, \u0026#34;geohash_precision\u0026#34;: 10, \u0026#34;type\u0026#34;: \u0026#34;geo_point\u0026#34;, \u0026#34;lat_lon\u0026#34;: true, \u0026#34;geohash_prefix\u0026#34;: true } } }, \u0026#34;response\u0026#34;: { \u0026#34;copy_to\u0026#34;: \u0026#34;response_int\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;bytes\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;response_int\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;integer\u0026#34; } } } } } \u0026#39; settings設定 デモ用であり、手元で2台のノードを起動するということもあり、number_of_shardsに2を、number_of_replicasに0を指定してあります。\nmappings設定 インデックスのタイプ Mappingsの指定は通常、特定のタイプを指定します。 今回のデモでは、1種類しかないのですが、タイプ名を特に意識しないために、_default_を使用しました。 この場合、任意のタイプに適用されることとなります。 タイプを指定してMappingの設定を行う場合は_default_の部分に特定のタイプ名を記入します。\n\u0026#34;mappings\u0026#34;: { \u0026#34;_default_\u0026#34;: { ... ダイナミックテンプレート 次はダイナミックテンプレートです。 インデックステンプレートはインデックスの設定をテンプレート化しました。ダイナミックテンプレートはフィールドに対してテンプレートを設定できます。\n以下のダイナミックテンプレートでは、stringタイプのフィールドのデフォルト設定を変更しています。 通常、stringタイプのフィールドはanalyzedとなりますが、not_analyzedに変更してあります。 詳しく検索したいフィールドの方が少ないためです。\n... \u0026#34;dynamic_templates\u0026#34;: [ { \u0026#34;string_template\u0026#34;: { \u0026#34;mapping\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;match_mapping_type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;match\u0026#34;: \u0026#34;*\u0026#34; } } ], ... multi_field指定 検索もしたいし、Terms Aggregationでも利用したいフィールドについては、multi_fieldを利用して、 analyzedとnot_analyzedの2種類のフィールドを用意しています。 multi_field設定を用いることで、1つのJSONのデータから、異なる形のフィールドを用意することが可能です。\n今回のテンプレートでは、path、referer、agentにmulti_fieldを指定しました。\n... \u0026#34;path\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;multi_field\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;no_analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;analyzed\u0026#34;: { \u0026#34;index\u0026#34;: \u0026#34;analyzed\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } }, ... 例えば、上記の設定の場合、入力のJSONはpathというデータのみですが、インデックス上にはpath.no_analyzedと path.analyzedというフィールドができあがります。 実際に検索する場合は、path.analyzed:検索したい文字列という形で検索をすることで、いわゆる部分一致のような検索が可能です。 また、完全一致をしたい場合はpath.no_analyzed:検索したい文字列という指定になります。 用途を考えると、requestも指定したほうが良いかもしれません。\ngeoip Logstashでgeoipデータを付与していました。 このgeoipのデータをKibana4で利用するために、geoデータとして登録する必要があります。\n\u0026#34;geoip\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;object\u0026#34;, \u0026#34;properties\u0026#34;: { \u0026#34;location\u0026#34;: { \u0026#34;geohash\u0026#34;: true, \u0026#34;geohash_precision\u0026#34;: 10, \u0026#34;type\u0026#34;: \u0026#34;geo_point\u0026#34;, \u0026#34;lat_lon\u0026#34;: true, \u0026#34;geohash_prefix\u0026#34;: true } } }, 上記の設定がgeoデータの指定です。 typeにobjectが指定してありますが、これは、geoipのデータがネストしているためです。 geoipオブジェクトのうち、緯度経度のデータはlocationに入っているため、こちらに緯度経度関係の設定を指定します。\n\u0026quot;type\u0026quot;: \u0026quot;geo_point\u0026quot;：geo_pointタイプであることを指定 \u0026quot;geohash\u0026quot;: true：緯度経度のデータをもとに、geohashの値もインデックス \u0026quot;geohash_precision\u0026quot;: 10：geohashの精度の指定 \u0026quot;lat_lon\u0026quot;: true：緯度経度を個別の.lat、.lonというフィールドにもインデックス \u0026quot;geohash_prefix\u0026quot;: true：該当するgeohashのみでなく、その親にあたるgeohashについてもインデックスする response、response_int、bytes 最後は、response、response_int、bytesです。\nresponseには、HTTPステータスコードが入ります。 文字列としても扱いたいですが、integerとして、Renge Aggregationなどを行いたいので、 response_intというフィールドにも値を入れています。 multi_fieldでも可能ですが、ここでは、copy_toを利用しました。 copy_toを用いることで、異なるフィールドに値をコピーすることができます。\nbytesについては、longで扱いたいとういう理由だけです。\n\u0026#34;response\u0026#34;: { \u0026#34;copy_to\u0026#34;: \u0026#34;response_int\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;bytes\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;long\u0026#34; }, \u0026#34;response_int\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;integer\u0026#34; } まとめ 今回はデモに利用したインデックスてプレートについて説明しました。 前回の、Logstashの設定とこのインデックステンプレートを用いることで、Kibanaで解析するデータの準備ができます。 実際の操作などについては、また次回の記事で説明しようかと思います。\n不明な点、誤植などありましたら、コメント欄へお願いします。\n","date":1416900346,"dir":"post/2014/","id":"4d8f5e581eee602c7fd21da8eb68df9a","lang":"ja","lastmod":1416900346,"permalink":"https://blog.johtani.info/blog/2014/11/25/import-apache-accesslog-using-logstash-2/","publishdate":"2014-11-25T16:25:46+09:00","summary":"前回の「Logstashを利用したApacheアクセスログのインポート」の続きです。 前回の記事では、Logstashの設定ファイルについて説","tags":["logstash","kibana","elasticsearch"],"title":"インデックステンプレートとLogstash"},{"contents":"JJUG CCCや第7回Elasticsearch勉強会のKibana4のデモにアクセスログを利用しました。\nただ、セッションでは、どうやってElasticsearchに投入したのかという詳しい話をしていませんでした。 本記事では、データ取り込み時に利用したLogstashの設定ファイルについて説明します。\nLogstashの設定の説明に入る前に、全体の流れを。 「ApacheアクセスログをKibana4により可視化」です。\n材料の準備 「ApacheアクセスログをKibana4により可視化」に必要な材料は次の通りです。 （今回は起動するところまでいかないので、実際に必要なのは次回以降になります。）\nJava 7（u55以上を1つ） Logstash 1.4.2（1つ） Elasticsearch 1.4.0（1つ） Kibana4 Beta2（1つ） Apacheのアクセスログ（適量） Apacheのアクセスログ以外は、公式サイトからダウンロードできます。 それぞれをダウンロードして、起動できるようにしておきましょう。\n※1台のマシン上で行う場合は、アクセスログの量を少なめにするなどの対策をとりましょう。 ※今回は、1台のマシン（Mac）上で、VMなどを利用せず、それぞれ直接起動するものとします。\n可視化の手順と流れ 可視化の流れとしては、\nLogstashでファイルを読み込み、各種処理（パースしたり、情報を追加したり、切り出したり） Elasticsearchに保存 Kibanaでグラフを作ったり、検索してみたり です。\n今回は、1のLogstashでファイルを読み込んだりする設定ファイルの説明です。\nLogstashの設定 Logstashの基本 まずは、Logstashの設定ですが、簡単にLogstashの説明を。 Logstashは大きく3つのパーツに分かれています。\ninput：データの入力処理 filter：inputで読み込んだデータに対する操作など output：データの出力処理 inputでデータを読み込み（複数可）、filterでデータに対して各種処理を行い、outputでデータを指定されたところに出力（複数可）します。\nアクセスログの読み込み設定 アクセスログの読み込み処理は大まかに次のようなものとなります。\nアクセスログを読み込む（input/file） 読み取ったアクセスログを各フィールド（IPアドレス、ユーザエージェントなど）に分割（filter/grok） 日付のパース（filter/date） クライアントIPアドレスにgeoipの情報を付加（filter/geoip） リクエストのパスの第1階層の抽出（filter/grok） ユーザエージェントのパース（filter/useragent） Elasticsearchへの出力（output/elasticsearch） 設定ファイルは次のようなものになります。\ninput { file { path =\u0026gt; \u0026#34;/Users/johtani/demo_access_log/*/*.log\u0026#34; start_position =\u0026gt; \u0026#34;beginning\u0026#34; } } filter { grok { match =\u0026gt; { \u0026#34;message\u0026#34; =\u0026gt; \u0026#34;%{COMBINEDAPACHELOG}\u0026#34; } break_on_match =\u0026gt; false tag_on_failure =\u0026gt; [\u0026#34;_message_parse_failure\u0026#34;] } date { match =\u0026gt; [\u0026#34;timestamp\u0026#34;, \u0026#34;dd/MMM/YYYY:HH:mm:ss Z\u0026#34;] locale =\u0026gt; en } geoip { source =\u0026gt; [\u0026#34;clientip\u0026#34;] } grok { match =\u0026gt; { \u0026#34;request\u0026#34; =\u0026gt; \u0026#34;^/%{WORD:first_path}/%{GREEDYDATA}$\u0026#34; } tag_on_failure =\u0026gt; [\u0026#34;_request_parse_failure\u0026#34;] } useragent { source =\u0026gt; \u0026#34;agent\u0026#34; target =\u0026gt; \u0026#34;useragent\u0026#34; } } output { elasticsearch { host =\u0026gt; \u0026#34;localhost\u0026#34; index =\u0026gt; \u0026#34;new_demo_access_log-%{year}\u0026#34; cluster =\u0026gt; \u0026#34;demo_cluster\u0026#34; protocol =\u0026gt; \u0026#34;http\u0026#34; } } 1. アクセスログを読み込む（input/file） inputのfileモジュール(a)を使用してアクセスログのファイルを読み込みます。 pathでアクセスログのファイルのパスを指定します。 今回利用したアクセスログはdemo_access_log/2010/access20100201.logといった日毎のファイルに分割されていたため、 *を利用してファイルのパスを指定しました。 また、今回は既存のファイルの読み込みだけのため、start_positionにbeginningを指定してあります。 デフォルトではendが指定されるため、Logstashを起動後に追記されたログから対象になってしまうためです。 その他の設定については、公式ガイドをご覧ください。\ninput { file { # a path =\u0026gt; \u0026#34;/Users/johtani/demo_access_log/*/*.log\u0026#34; # b start_position =\u0026gt; \u0026#34;beginning\u0026#34; # c } } Logstashでは、ファイルをどこまで読み込んだかという情報を保持するために、sincedbを利用しています。 設定変更後に同じファイルを最初から読み込みたい場合などは、こちらのファイルを一旦削除するなどの対応が必要です。\nちなみに、読み込んだデータは次のようなJSONになっています。\n{ \u0026#34;message\u0026#34;: \u0026#34;読み込んだアクセスログ\u0026#34;, \u0026#34;@version\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;@timestamp\u0026#34;:\u0026#34;2014-11-21T06:16:21.644Z\u0026#34;, \u0026#34;host\u0026#34;:\u0026#34;jupiter.local\u0026#34;, \u0026#34;path\u0026#34;:\u0026#34;/Users/johtani/demo_access_log/2010/access20100201.log\u0026#34;} } 特に指定がない場合は、messageに読み込んだデータが入ってきます。 @timestampがLogstashが読み込んだ時刻、hostはLogstashが動作しているホスト名です。 pathはfileモジュールが読み込んだファイルのパスを設定しています。 この後の処理で、どこの項目に対して処理を行うかといったことが重要になるので、\n2. 読み取ったアクセスログを各フィールド（IPアドレス、ユーザエージェントなど）に分割（filter/grok） 2.〜6.の処理は、inputで読み込んだ1アクセスログに対する処理となります。\nここでは、grokフィルタを使用して Apacheのアクセスログを各フィールドに分割します。 Logastashでは、簡単に使えるようにいくつかのパターンが用意されています。 Apacheのログのために、COMBINEDAPACHELOGというのが用意されています。 今回はこちらを使用しています。その他にも日付などパターンが用意されているので、試してみてください。\nmessageにアクセスログが入っているので、こちらの項目に対してCOMBINEDAPACHELOGのパターンを matchで適用してフィールドに抜き出します。 tag_on_failureは、matchでパースに失敗した場合に、tagというフィールドに指定した文字列を出力する機能になります。 デフォルトだと_grokparsefailureが付与されますが、ここでは、どの処理で失敗したがを判別するために文字列を変更しています。\nfilter { grok { match =\u0026gt; { \u0026#34;message\u0026#34; =\u0026gt; \u0026#34;%{COMBINEDAPACHELOG}\u0026#34; } break_on_match =\u0026gt; false tag_on_failure =\u0026gt; [\u0026#34;_message_parse_failure\u0026#34;] } ... clientip、ident、auth、timestamp、verb、request、httpversion、response、bytes、referrer、agentがgrokフィルタにより抜き出された項目です。\n{ \u0026#34;message\u0026#34;:\u0026#34;アクセスログ\u0026#34;, \u0026#34;@version\u0026#34;:\u0026#34;1\u0026#34;, \u0026#34;@timestamp\u0026#34;:\u0026#34;2014-11-21T07:20:54.387Z\u0026#34;, \u0026#34;host\u0026#34;:\u0026#34;jupiter.local\u0026#34;, \u0026#34;path\u0026#34;:\u0026#34;/Users/johtani/demo_access_log/2010/access20100201.log\u0026#34;, \u0026#34;clientip\u0026#34;:\u0026#34;クライアントのIPアドレス\u0026#34;, \u0026#34;ident\u0026#34;:\u0026#34;-\u0026#34;, \u0026#34;auth\u0026#34;:\u0026#34;-\u0026#34;, \u0026#34;timestamp\u0026#34;:\u0026#34;01/Feb/2010:00:00:26 +0900\u0026#34;, \u0026#34;verb\u0026#34;:\u0026#34;GET\u0026#34;, \u0026#34;request\u0026#34;:\u0026#34;/images/favicon.ico\u0026#34;, \u0026#34;httpversion\u0026#34;:\u0026#34;1.1\u0026#34;, \u0026#34;response\u0026#34;:\u0026#34;200\u0026#34;, \u0026#34;bytes\u0026#34;:\u0026#34;318\u0026#34;, \u0026#34;referrer\u0026#34;:\u0026#34;\\\u0026#34;-\\\u0026#34;\u0026#34;, \u0026#34;agent\u0026#34;:\u0026#34;\\\u0026#34;Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)\\\u0026#34;\u0026#34; } 3. 日付のパース（filter/date） Logstashは特に指定がない場合、inputでデータを取り出した日付が@timestampとなります。 そして、このフィールドが特に指定がない場合は、Elasticsearchのデータの日付となり、Kibanaで利用する日付となります。\nリアルタイムにアクセスログを読み込む場合は、読み込んだ日時でもほぼ問題はありませんが、過去データの場合はそうもいきません。 そこで、dateフィルタを使用して、@timestampの値を書き換えます。\ndate { match =\u0026gt; [\u0026#34;timestamp\u0026#34;, \u0026#34;dd/MMM/YYYY:HH:mm:ss Z\u0026#34;] locale =\u0026gt; en } 上記では、timestampという項目に対してdd/MMM/YYYY:HH:mm:ss Zという日付パターンの場合に値を書き換える設定となります。 なお、日付の月の部分がFebとなっているため、localeにenを指定しています。Logstashが動作するマシンのlocaleがjaなどの場合にパースに失敗するためです。\n4. クライアントIPアドレスにgeoipの情報を付加（filter/geoip） どの国からのアクセスかなどを判別したいので、IPアドレスを元にgeoipを利用してより詳細な情報を付与します。 Logstashでもこの機能が用意されており、簡単に利用ができます。\ngeoip { source =\u0026gt; [\u0026#34;clientip\u0026#34;] } これだけです。対象とするIPアドレスのフィールドを指定しているだけです。 geoipというフィールドが追加され、次のような情報が付与されます。 国名、緯度経度、タイムゾーンなどです。\n{ ... \u0026#34;geoip\u0026#34;: { \u0026#34;ip\u0026#34;: \u0026#34;IPアドレス\u0026#34;, \u0026#34;country_code2\u0026#34;: \u0026#34;JP\u0026#34;, \u0026#34;country_code3\u0026#34;: \u0026#34;JPN\u0026#34;, \u0026#34;country_name\u0026#34;: \u0026#34;Japan\u0026#34;, \u0026#34;continent_code\u0026#34;: \u0026#34;AS\u0026#34;, \u0026#34;latitude\u0026#34;: 36, \u0026#34;longitude\u0026#34;: 138, \u0026#34;timezone\u0026#34;: \u0026#34;Asia/Tokyo\u0026#34;, \u0026#34;location\u0026#34;: [ 138, 36 ] } ... } 5. リクエストのパスの第1階層の抽出（filter/grok） リクエストされたURLはrequestフィールドにありますが、個別のURLだと、大まかな集計が大変です。 もちろん、クエリで処理することもできますが、Logstashで処理するついでに、第1階層のディレクトリ名を抽出しておくことで、 検索や集計を行いやすくしておきます。\ngrok { match =\u0026gt; { \u0026#34;request\u0026#34; =\u0026gt; \u0026#34;^/%{WORD:first_path}/%{GREEDYDATA}$\u0026#34; } tag_on_failure =\u0026gt; [\u0026#34;_request_parse_failure\u0026#34;] } また、grokフィルタの登場です。 今回は、WORD:first_pathという記述方法で、WORDパターンにマッチした文字列をfirst_pathというフィールドに展開する指定をしています。\n例えば、サイトのスクリプトなどがscriptsというディレクトリにある場合は、first_pathの値を利用して、 後続のフィルタでログデータを出力しないといった処理にも使えます。\n6. ユーザエージェントのパース（filter/useragent） Logstashではユーザエージェントの文字列から、いくつかの情報を付与するフィルタも用意されています。 useragentフィルタです。\nuseragent { source =\u0026gt; \u0026#34;agent\u0026#34; target =\u0026gt; \u0026#34;useragent\u0026#34; } agentというフィールドにユーザエージェントの文字列があるので、このフィールドに対してフィルタを適用します。 元の文字列も取っておきたいので、useragentという別のフィールドに出力するように指定してあります。\n\u0026#34;useragent\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;Firefox\u0026#34;, \u0026#34;os\u0026#34;: \u0026#34;Windows XP\u0026#34;, \u0026#34;os_name\u0026#34;: \u0026#34;Windows XP\u0026#34;, \u0026#34;device\u0026#34;: \u0026#34;Other\u0026#34;, \u0026#34;major\u0026#34;: \u0026#34;17\u0026#34;, \u0026#34;minor\u0026#34;: \u0026#34;0\u0026#34; }, このように、OS名やバージョン名などが抽出できます。\n7. Elasticsearchへの出力（output/elasticsearch） 最後は、Elasticsearchへのデータの出力設定です。\nindexにて、出力するindex名を指定してあります。 また、年毎のインデックス名にするために%{year}を利用しています。 sprintf formatです。\nelasticsearch { host =\u0026gt; \u0026#34;localhost\u0026#34; index =\u0026gt; \u0026#34;new_demo_access_log-%{year}\u0026#34; cluster =\u0026gt; \u0026#34;demo_cluster\u0026#34; protocol =\u0026gt; \u0026#34;http\u0026#34; } まとめ ということで、今回はアクセスログをLogstashにて読み込む時の設定について説明してきました。 次回は、実際にLogstashを起動してElasticsearchにデータを登録するところまでを説明します。\nJJUG CCCや勉強会のデモに用いたデータは、 Elasticsearchにデータを登録する前にテンプレートも設定してありました。こちらについても、次回説明しようと思います。\n不明な点、誤植などありましたら、コメント欄へお願いします。\n","date":1416558639,"dir":"post/2014/","id":"937a597a8b399fd32caba88a3c1c7bc4","lang":"ja","lastmod":1416558639,"permalink":"https://blog.johtani.info/blog/2014/11/21/import-apache-accesslog-using-logstash/","publishdate":"2014-11-21T17:30:39+09:00","summary":"JJUG CCCや第7回Elasticsearch勉強会のKibana4のデモにアクセスログを利用しました。 ただ、セッションでは、どうやってElas","tags":["logstash","kibana","elasticsearch"],"title":"Logstashを利用したApacheアクセスログのインポート"},{"contents":"第7回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\n昨日も紹介しましたが、Elasticsearch Advent Calendar 2014を用意してみました。まだ、空きがありますので、登録お待ちしております！\n今回は出足が好調で、早々に180人の枠を超えるという嬉しい事態でした。 最終的な参加人数は130名程度で、懇親会参加者が50名弱といったところです。\n「Kibana4」 Elasticsearch Inc. Jun Ohtani @johtani スライド：Kibana4\nということで、Kibana4の紹介と、Kibana4のBeta2を利用したデモを行いました。 デモの開始のところで少し環境がうまく動いてなくて手間取ってしまいましたが。。。\n発表で1点だけ修正があります。JRubyを選択しているのがElasticsearchのライブラリを使用するためという説明をしましたが、 こちらは、Logstashに関する話でした。Kibana4は現時点では、ElasticsearchへのProxyとしての動作が主なものとなります。Rubyでも動作可能です。 bin/kibanaについてはJavaを使った起動になります。 参考：https://github.com/elasticsearch/kibana/tree/master/src/server\n発表でも主張しましたが、ダウンロードして、Elasticsearchを用意すれば簡単に動作させることが可能です。 ぜひ、ローカルで試して見てもらえればと思います。 今回のデモのデータを入れるのに利用したLogstashの設定などについては、ブログで記事を書こうと思います。\nniconicoの検索を支えるElasticsearch 株式会社ドワンゴ 伊藤 祥 さん スライド：niconicoの検索を支えるElasticsearch\nリアルタイム検索の実現、新しい検索への対応 検索のアーキテクチャとか。 Capistranoでデプロイとかを管理 1.4.1が出たら、クラスタを更新予定 ということで、実際に導入した話から、現在の運用の仕方、クラスタのアップグレードなど多岐にわたる内容でおもしろかったです。 遭遇した問題点とかもあったので。 Marvel便利なのでぜひ導入を検討してもらえればw\nElasticsearch at CrowdWorks\u2028株式会社クラウドワークス 九岡 佑介 さん @mumoshu スライド：Elasticsearch at CrowdWorks\n会社の紹介 仕事が検索対象 検索時間が1桁減少！ Graceful Degradationで失敗したら、InnoDB FTSで代替：Gracefully found.noのサービスを利用 elasticsearch-modelの拡張を作成してOSSとして公開：elasticsearch-model-extensions Gracefullyで切り替えとかは面白いなと思いました。 検索での利用の話でしたが、他のシーンでも使えそうですよね。 日本にFoundユーザがいるのも初めて知りました。 彼らの開発者ブログも質の良い情報が載っているので、参考になりますよね。\n次は、どんなMappingで運用しているのかとか、どういった工夫をしているかといった点を詳しく聞きたいなと思いました。 またお待ちしております。\n1分で作るElasticsearchプラグイン 株式会社エヌツーエスエム 菅谷 信介 さん スライド：Elasticsearchプラグインの作り方\n\u0008\u0008* プラグインの作り方とか。\n十数個のプラグインの紹介。プラグインはこちらで公開中。https://github.com/codelibs/ 実際に、業務で必要なものから作成 まだまだ作りたいものがある コミュニティ還元できるものはPR送ってもらえるとうれしいです。 前よりは体制も増えてるので、PRも目にとまるようになってるはずです。\nあとは、使ってみたいと思う方も多数いると思うので、ぜひ、OSSなので、貢献しましょう！ フィードバックがあるだけで、OSS活動やってるものにとってはやる気につながると思いますし。\nLT：GISとして活用するElasticsearch\u2028船戸 隆さん スライド：GISとして活用するElasticsearch\u2028java-jaからIngressの青（Registance）の勧誘に来られた方w APIをハックして、情報を取得し、Kibanaで可視化 残念ながら、APIが変更されて見れなくなったらしい。 Ingress実際にやったことはないのですが、おもしろそうでした。 発表される方の会社の採用紹介ではなく、Ingressの勧誘をされるとは想定外でしたw\n興味のあるデータをKibanaで可視化するのも面白い例だと思うので、活用してもらえればと思います。\nその他、感想などのブログ 適当に見つけたブログを列挙してあります。これもあるよ！などあれば、教えてください。\n勉強会メモ - 第7回elasticsearch勉強会 第7回elasticsearch勉強会 #elasticsearch #elasticsearchjp まとめ JJUGの時とは違い、Elasticsearch勉強会ではさすがに、企業としてのElasticsearchの知名度が高かったのはありがたいことでした。 自分の発表のために始めた勉強会でもありますが、まだまだ、発表するときは緊張しますし、分かりにくいんじゃないかなぁと思うことも多々あります。 この辺がわかりにくかった、この辺をもっと知りたいなど、フィードバックをお待ちしております。\n冒頭にも書きましたが、Elasticsearch Advent Calendar 2014の登録をお待ちしております。どんなことでも歓迎なので、Elasticsearch、Kibana、Logstashなどについて書いてもらえるとうれしいです。\n次回ももちろん2ヶ月後くらいに行います。 スピーカー募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1416363547,"dir":"post/2014/","id":"2a8412aa50d07330f1298f0243fa79d3","lang":"ja","lastmod":1416363547,"permalink":"https://blog.johtani.info/blog/2014/11/19/hold-on-7th-elasticsearch-jp/","publishdate":"2014-11-19T11:19:07+09:00","summary":"第7回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第7回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch-1.4.0 and 1.3.5 released\n本日、Lucene 4.10.2をベースにしたElasticsearch 1.4.0と、バグフィックスリリースである、Elasticsearch 1.3.5をリリースしました。 ダウンロードおよび変更リストはそれぞれ次のリンクからアクセスできます。\n最新ステーブルリリース：Elasticsearch 1.4.0 1.3.x系バグフィックス：Elasticsearch 1.3.5 1.3ブランチに関する過去のリリースについてのブログは次のとおりです：1.3.4, 1.3.3, 1.3.2, 1.3.1, 1.3.0.\nBeta1リリースでも言及しましたが、1.4.0の主なテーマは*resiliency(復元性、弾力性)*です。 Elasticsearchをより安定し信頼性のあるものにし、メモリ管理を改善し、ディスカバリアルゴリズムを改善し、破損したデータの検知を改善しました。 Beta1リリースからのハイライトも含んでいます。\nDoc values (インデックス時にディスクに保存されるfielddata)がヒープ利用率を激減 Request circuit breaker: メモリを消費しすぎる検索リクエストの中断 Bloom filterのデフォルト無効、高速なインデキシングのためにもはや必要とされないため。 ノードディスカバリ、シャードリカバリの数多くのバグフィックス及び改善 データ破損の早期検知のためのチェックサムのさらなる利用 GroovyをMVELの代わりにデフォルトスクリプト言語に CORSをデフォルト無効に。XSS攻撃防止の為。 クエリキャッシュ、変更されていないシャードからすぐにaggregation結果を返す 新しいAggregation：filter(ドキュメント)、children(ドキュメント)、scripted_metric(ドキュメント) 新しいGET /indexAPI。インデックスのsettings、mappings、warmers、aliasesを1回のリクエストで返却(ドキュメント) 自動付与ドキュメントIDのためのFlake ID。プライマリキーの探索パフォーマンスの改善。 ドキュメントに変更のない更新によるドキュメントの再インデックスの防止 function_scoreクエリの関数でweightパラメータによる個別の改善を可能に。(ドキュメント) 詳細については1.4.0.Beta1のブログ(英語)(日本語訳)をご覧ください。\nBeta1以降の1.4.0の変更の全てについては、1.4.0 release notesでご覧いただけます。 以下では、2つの主な変更について紹介します。\nHTTP Pipelining HTTP pipeliningは複数のリクエストを1回のコネクションで、関連するレスポンスを待つことなく送信することができます。 そして、レスポンスは、受け取ったリクエストと同じ順序で返却されます。 HTTP/1.1の仕様で、pipeliningのサポートが必要です。ElasticsearchはHTTP/1.1であるとしてきましたが、pipeliningはサポートしていませんでした。この問題は.NETユーザで問題を引き起こしました。\n現在、HTTP pipeliningは公式にサポート済みで、デフォルトで利用できます。#8299をご覧ください。\nUpgrade API Luceneのすべてのリリースではバグフィックスや最適化が提供されます。しかし、多くのユーザは古いバージョンのLuceneで作成されたインデックスを持っており、より最新の改善による利点を利用できないことがあります。 新しいupgradeAPIは、あなたのインデックスすべてもしくは一部を最新のLuceneフォーマットに透過的にアップグレードできます。\nGET _upgradeリクエストは、インデックスのアップグレードが必要かどうかを提示し、アップグレードに必要なセグメントのサイズをリポートすることによって、どのくらいの時間が必要かの目安を提供します。 POST _upgradeコマンドはバックグラウンドでインデックスを最新のLuceneフォーマットに書き換えます。\nより詳しい情報はupgradeAPIドキュメントをご覧ください。\n試してみてください。 Beta1リリースを利用し、経験・体験を報告していただいたベータテスターの方々に感謝します。 1.4.0がこれまでの最高のリリースになると確信しています。 ぜひ、Elasticsearch 1.4.0をダウンロードして、試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1415205033,"dir":"post/2014/","id":"d266a2023c67b7a20c3bd01055b223bc","lang":"ja","lastmod":1415205033,"permalink":"https://blog.johtani.info/blog/2014/11/06/elasticsearch-1-4-0-ja/","publishdate":"2014-11-06T01:30:33+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch-1.4.0 and 1.3.5 released 本日、Lucene 4.10.2をベースにし","tags":["elasticsearch"],"title":"Elasticsearch 1.4.0および1.3.5リリース（日本語訳）"},{"contents":"久しぶりに翻訳ではないブログを。書こうと思いながらかけてなかったので。。。\n今回はvalidate APIの紹介です。\n背景 ElasticsearchのクエリはQuery DSLというJSONで クエリを定義できるものを提供しています。 これは、様々なクエリ、フィルタを定義するために必要です。\n自分の望んでいる条件を記述するために、JSONのネストと格闘することも必要となります。。。 また、クエリ、フィルタには様々なパラメータが用意されています。 これらのパラメータをすべて覚えるのは無理でしょうし、タイプミスなどもありますよね。 タイプミスやカッコのミスマッチなどで格闘して1時間が経過してしまったなどもあると思います。\nそんな時に便利なAPIとして用意されているのがvalidate APIです。\n利用方法 APIが用意されています。\nhttp://ホスト名:ポート番号/インデックス名/タイプ名/_validate/query インデックス名やタイプ名は省略可能ですが、マッピングが異なると思うので、タイプ名まで指定するほうが良いと思います。 上記のAPIに対してクエリを送信するだけです。\nクエリの確認 たとえば、こちらのGistにあるようなマッピングのインデックスに対して 検索クエリを組み立てていて、エラーが出るとします。 ※このクエリはmatch_allのところをmatch_alと、lが1文字足りないクエリになっています。\n検索クエリのリクエスト（エラーあり）\nGET pref_aggs/_search { \u0026#34;query\u0026#34;: { \u0026#34;match_al\u0026#34;: {} } } 実行結果のレスポンス\n{ \u0026#34;error\u0026#34;: \u0026#34;SearchPhaseExecutionException[Failed to execute phase [query], all shards failed; shardFailures {[rwkb01chTZq2V7FD0Tlwrw][pref_aggs][0]: SearchParseException[[pref_aggs][0]: from[-1],size[-1]: Parse Failure [Failed to parse source [{\\n \\\u0026#34;query\\\u0026#34;: {\\n \\\u0026#34;match_al\\\u0026#34;: { }\\n }\\n}\\n]]]; nested: QueryParsingException[[pref_aggs] No query registered for [match_al]]; }{[rwkb01chTZq2V7FD0Tlwrw][pref_aggs][1]: SearchParseException[[pref_aggs][1]: from[-1],size[-1]: Parse Failure [Failed to parse source [{\\n \\\u0026#34;query\\\u0026#34;: {\\n \\\u0026#34;match_al\\\u0026#34;: { }\\n }\\n}\\n]]]; nested: QueryParsingException[[pref_aggs] No query registered for [match_al]]; }]\u0026#34;, \u0026#34;status\u0026#34;: 400 } とこんなかんじで、エラーが帰っては来るのですが、非常に読みづらいです。\nそこで、validate APIを利用します。 リクエスト先を/_searchから/_validate/queryに変更します。\nvalidate API\nGET pref_aggs/_validate/query { \u0026#34;query\u0026#34;: { \u0026#34;match_al\u0026#34;: {} } } validate APIのレスポンス\n{ \u0026#34;valid\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 } } すると、非常にシンプルな結果が返ってきます。 \u0026quot;valid\u0026quot;: falseとなっているため、クエリに問題があることがわかります。\nエラーの詳細 問題がある事自体はわかりましたが、エラーの内容も知りたいですよね？ その場合は、explainというパラメータを追加します。 （正しくはexplain=trueを追加しますが、=trueを省略可能です。）\nvalidate API(explainあり、クエリ自体は省略)\nGET pref_aggs/_validate/query?explain {...} validate APIのレスポンス\n{ \u0026#34;valid\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;explanations\u0026#34;: [ { \u0026#34;index\u0026#34;: \u0026#34;pref_aggs\u0026#34;, \u0026#34;valid\u0026#34;: false, \u0026#34;error\u0026#34;: \u0026#34;org.elasticsearch.index.query.QueryParsingException: [pref_aggs] No query registered for [match_al]\u0026#34; } ] } explanationsという項目が追加されました。 ここにerrorという項目として、エラーの詳細が返ってきます。_searchの時よりも見やすいですね。 今回のエラーは、match_allが正しいクエリですの、match_alというクエリは登録されていないというエラーでした。 では、クエリを修正して実行しましょう。\nvalidate API(エラー無し)\nGET pref_aggs/_validate/query?explain { \u0026#34;query\u0026#34;: { \u0026#34;match_all\u0026#34;: {} } } validate APIのレスポンス\n{ \u0026#34;valid\u0026#34;: true, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;explanations\u0026#34;: [ { \u0026#34;index\u0026#34;: \u0026#34;pref_aggs\u0026#34;, \u0026#34;valid\u0026#34;: true, \u0026#34;explanation\u0026#34;: \u0026#34;ConstantScore(*:*)\u0026#34; } ] } 今度はクエリに問題はありません。\u0026quot;valid\u0026quot;: trueです。 そして、explanationsの項目には、errorの代わりにexplanationという項目が返ってきました。 これが、実際にElasticsearch内部で実行されるクエリになります。\n実際のクエリに利用される単語の確認 この機能はこの他に、クエリの解析にも利用できます。 思ったとおりに検索にヒットしない場合があって、困ったことはないですか？ フィールドに指定されたアナライザによっては、単語を変形したりするものが存在します。\nサンプルマッピング\nPUT /validate_sample { \u0026#34;mappings\u0026#34;: { \u0026#34;several_analyzer\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;title\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;}, \u0026#34;body_ja\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34;}, \u0026#34;body_en\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;english\u0026#34;} } } } } 例えば、このようにkuromoji、english、デフォルト(standard)アナライザを利用したマッピングがあるとします。 このフィールドに対してpowerfulという単語で検索したとします。\nvalidate API\nGET /validate_sample/_validate/query?explain { \u0026#34;query\u0026#34;: { \u0026#34;multi_match\u0026#34;: { \u0026#34;fields\u0026#34;: [\u0026#34;body_en\u0026#34;,\u0026#34;body_ja\u0026#34;,\u0026#34;title\u0026#34;], \u0026#34;query\u0026#34;: \u0026#34;powerful\u0026#34; } } } この場合、レスポンスは次のとおりです。\nvalidate APIのレスポンス\n{ \u0026#34;valid\u0026#34;: true, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;explanations\u0026#34;: [ { \u0026#34;index\u0026#34;: \u0026#34;validate_sample\u0026#34;, \u0026#34;valid\u0026#34;: true, \u0026#34;explanation\u0026#34;: \u0026#34;(title:powerful | body_en:power | body_ja:powerful)\u0026#34; } ] } title、body_jaについては入力された単語がそのままクエリとして利用されています。 body_enについては、powerという単語に変換されて実行されています。 これは、englishアナライザがステミングを行った結果がクエリとして利用されるという意味です。 また、powerfulを秋葉原といった日本語に変更して実行すると次のようになります。 日本語はstandardアナライザなどでは、1文字ずつ区切られてしまうことがわかります。\nvalidate APIのレスポンス\n{ \u0026#34;valid\u0026#34;: true, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;explanations\u0026#34;: [ { \u0026#34;index\u0026#34;: \u0026#34;validate_sample\u0026#34;, \u0026#34;valid\u0026#34;: true, \u0026#34;explanation\u0026#34;: \u0026#34;((title:秋 title:葉 title:原) | (body_en:秋 body_en:葉 body_en:原) | ((body_ja:秋葉 body_ja:秋葉原) body_ja:原))\u0026#34; } ] } このように、クエリの単語がどのような単語に変換されてクエリに利用されているかなども知ることが可能です。\nまた、クエリを組み立てて、ヒットするはずが、0件となってしまうという場合にも、どのようなクエリが組み立てられているかを確認するという点で、 validate APIが役立ちます。 検索がヒットするが、望んだクエリになっていないのでは？という場合は_search APIのexplainパラメータを 利用すれば、クエリの構成がわかるのですが、検索結果が0件の場合はクエリの構成は表示されません。\n解決できない問題は？ 便利なvalidate APIですが、以下の問題に対しては残念ながら確認できません。\nquery以外の項目のvalidate不可 たとえば、_search APIのsizeなどの項目についてはチェックできないです。 存在しないフィールドの指定 上記validate_sampleのマッピングの例でクエリにbody_engという存在しないフィールドを指定してもエラーとはなりません。 まとめ 書いたクエリがうまく動かない、JSONのタグがおかしいといった場合は、 まずはこのvalidate APIで確認してみるのがオススメです。\n","date":1414402951,"dir":"post/2014/","id":"bc2709406a9bb19e8d83a78f81e36244","lang":"ja","lastmod":1414402951,"permalink":"https://blog.johtani.info/blog/2014/10/27/how-to-use-validate-api/","publishdate":"2014-10-27T18:42:31+09:00","summary":"久しぶりに翻訳ではないブログを。書こうと思いながらかけてなかったので。。。 今回はvalidate APIの紹介です。 背景 Elasticsear","tags":["elasticsearch"],"title":"validate APIの利用"},{"contents":"Elasticsearch 1.4.0.Beta1がリリースされました。\n個人でelasticsearch-extended-analyzeというプラグインを開発してます。 こちらも1.4.0.Beta1に対応するべく作業をしてて、少し戸惑ったことがあったので、メモをば。\nここ最近はプラグインのバージョン番号をElasticsearchのバージョン番号と同じものを利用していました。 （プラグインの機能追加をサボってる？？） その時に、1.4.0.Beta1という番号を指定したのですが、意味不明なエラーに悩まされてしまいまして。\nプラグインのリリースでは、以下のコマンドを実行します。\n$ mvn release:prepare $ mvn release:perform 最初のコマンド（prepare）で、パッケージングを実施し、Githubにリリースタグを打ったバージョンがpushされます。 次のコマンド（perform）で、パッケージングされたzipファイルがsonatypeのサイトに公開するためにアップロードされます。\n1.4.0.Beta1というバージョン文字列を利用した場合、prepareは問題なく実行できたのですが、 performで以下の様なエラーが返ってきました。\nReturn code is: 401, ReasonPhrase: Unauthorized. バージョン番号が1.3.0では特に問題はなかったのですが、、、 結局、バージョン番号を1.4.0-beta1に変更すると問題なくリリースが完了しました。\nmike_neckさんと話をしていて、Semantic Versioningに関係しているのかなぁという話にはなったのですが、 詳しく調べていません。。。\nそのうち調べようかなぁ。。。。\n","date":1413354368,"dir":"post/2014/","id":"998eda745d07fd8608f251138384a0b9","lang":"ja","lastmod":1413354368,"permalink":"https://blog.johtani.info/blog/2014/10/15/versioning-of-sonatype/","publishdate":"2014-10-15T15:26:08+09:00","summary":"Elasticsearch 1.4.0.Beta1がリリースされました。 個人でelasticsearch-extended-analyzeというプラグインを開発してま","tags":["Elasticsearch","plugin","sonatype"],"title":"Sonatypeのバージョン番号で困ったので"},{"contents":"※この記事は次のブログを翻訳したものになります。\n原文：elasticsearch 1.4.0.beta1 released\n本日、Lucene 4.10.1をベースにした、Elasticsearch 1.4.0.Beta1をリリースしました。 Elasticsearch 1.4.0.Beta1からダウンロードできます。 また、すべての変更点に関してもこちらをご覧ください。\n1.4.0のテーマは*resiliency(復元性、弾力性)*です。 resiliencyとはElasticsearchをより安定し信頼性のあるものにすることを意味します。 すべての機能が正常に機能している場合は信頼することは簡単です。 予想外のことが発生した時に難しくなります：ノードでout of memoryの発生、スローGCや重いI/O、ネットワーク障害、不安定なデータの送信によるノードのパフォーマンス低下など。\n本ベータリリースは、resiliencyの主な3つの改善を含んでいます。\nメモリ使用量の低下によるノードの安定性向上 discoveryアルゴリズムの改善によるクラスタの安定性向上 チェックサムの導入による破損したデータの検知 分散システムは複雑です。 決して想像できないような状況をシミュレーションするために、ランダムなシナリオを作成する広範囲なテストスイートを持っています。 しかし、無数のエッジケース(特殊なケース)があることも認識しています。 1.4.0.Beta1はこれまで私たちが行ってきた改善のすべてを含んでいます。 これらの変更を実際にテストしていただき、何か問題があった場合は私たちに教えてください。\nメモリ管理 ヒープ空間は限られたリソースです。 上限を32GBとし、利用可能なRAMの50%をヒープの上限にすることを推奨します。 この上限を超えた場合、JVMは圧縮したポインタを使用することができず、GCが非常に遅くなります。 ノードの不安定性の主な原因は遅いGCです。それは、次のようなことから発生します。\nメモリプレッシャー スワップ(参照：memory settings) 非常に大きなヒープ 本リリースは、メモリ管理の改善し、（結果として）ノードの安定性を改善するいくつかの変更を含んでいます。\ndoc values メモリの利用の最も大きなものの1つはfielddataです aggregation、ソート、スクリプトがフィールドの値に素早くアクセスするために、フィールドの値をメモリにロードして保持します。 ヒープは貴重なため、1ビットも無駄にしないためにメモリ内のデータは高度な圧縮と最適化を行っています。 これは、ヒープスペース以上のデータをもつまでは、非常によく動作します。 これは、多くのノードを追加することによって常に解決できる問題です。 しかし、CPUやI/Oが限界に達してしまうずっと前に、ヒープ空間の容量に到達します。\n最近のリリースは、doc valuesによるサポートがあります。 基本的に、doc valuesはin-memory fielddataと同じ機能を提供します。 doc valuesの提供する利点は、それらが、非常に少量のヒープ空間しか使用しない点です。 doc valuesはメモリからではなく、ディスクから読み込まれます。 ディスクアクセスは遅いですが、doc valuesはカーネルのファイルシステムキャッシュの利点を得られます。 ファイルシステムキャッシュはJVMヒープとはことなり、32GBの制限による束縛がありません。 ヒープからファイルシステムキャッシュにfielddataを移行することによって、より小さなヒープを使うことができます。これは、GCがより早くなり、ノードが更に安定することを意味します。\n本リリースより前は、doc valuesはin-memory fielddataよりもかなり遅かったです。 本リリースに含まれる変更は、パフォーマンスをかなり向上させ、in-memory fielddataとほぼ同じくらいの速度になっています。\nin-memory fielddataの代わりにdoc valuesを利用するために必要なことは、次のように新しいフィールドをマッピングすることです。\nPUT /my_index { \u0026#34;mappings\u0026#34;: { \u0026#34;my_type\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;timestamp\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;date\u0026#34;, \u0026#34;doc_values\u0026#34;: true } } } } } このマッピングで、このフィールドに対するfielddataの利用は、メモリにフィールドをロードする代わりに、自動的にディスクからdoc valuesを利用します。 *注意：*現時点で、doc valuesはanalyzedなstringフィールドはサポートしていません。\nrequest circuit breaker fielddata circuit breakerはfielddataによって利用されるメモリの上限を制限するために追加され、OOMEの最も大きな原因の1つを防ぎました。 そして、リクエストレベルのcircuit-breakerを提供するために、コンセプトを拡張しました。 これは、単一のリクエストによって使用されるメモリの上限を制限します。\nbloom filters Bloom filters はインデキシング(前のバージョンのドキュメントが存在するかどうかのチェックのため)や、 IDによるドキュメントの検索(ドキュメントを含むセグメントがどれかを決定するため)に関する重要な性能最適化を提供しました。 しかし、もちろんそれらはコスト（メモリ）を必要とします。 現在の改善は、bloom filterの必要性を取り除きました。 現在では、Elasticsearchはまだ、インデックス時にそれらを構築します(実世界の経験がテストシナリオにそぐわない場合に備えて)。 しかし、デフォルトではメモリにはロードされません。 すべてが予定通りに運べば、将来のバージョンで完全にこれらは除去します。\nクラスタの安定性 クラスタの安定性向上のために私たちができる最も大きなことは、ノードの安定性の向上です。 もし、ノードが安定しておりタイミングよく反応すれば、クラスタが不安定になる可能性が大いに減少します。 私たちは不完全な世界に住んでいます。- 物事は予想外にうまく行きません。クラスタはデータを失うことなくこのような状況から回復できる必要があります。\n私たちは、improve_zenブランチ上で、Elasticsearchの障害からの復旧するための能力の向上に数ヶ月費やしてきました。 まず、複雑なネットワークレベルの障害を繰り返すためのテストを追加しました。 次に、各テストのための修正を追加しました。 そこには、より多くの行うことが存在します。しかし、私たちは、issue #2488(\u0026ldquo;分割が交差している場合、minimum_master_nodesはsplit-brainを防げない\u0026rdquo;)に含まれる、ユーザが経験してきた大部分の問題を私たちは解決しました。\n私たちはクラスタのresiliencyを非常に真剣に取り組んでいます。 私たちは、Elasticsearchが何ができるか、その上で何が弱点であるかを理解してほしいと思っています。 これを考慮して、私たちはResiliency Status Documentを作成しました。 このドキュメントは、私たち(または私たちユーザ)が遭遇したresiliencyの問題の、何が修正済みで、何が修正されないまま残っているかを記録します。 このドキュメントを慎重に読み、あなたのデータを保護するために適切な方法を選択してください。\nデータ破損の検知 ネットワークをまたいだシャードリカバリのチェックサムは、圧縮ライブラリのバグを発見する助けとなりました。 それは、バージョン1.3.2で修正済みです。 それ以来、私たちはElasticsearchのいたるところにチェックサムとチェックサムの確認を追加しました。\nマージ中に、あるセグメント内すべてのチェックサムの確認(#7360) インデックス再オープン時に、あるセグメント内の最も小さなファイルの完全な確認と、より大きなファイルの軽量な打ち切りチェック(LUCENE-5842) トランザクションログからイベントを再生するとき、各イベントはチェックサムを確認される(#6554) シャードのリカバリ中もしくは、スナップショットからのリストア中にElasticsearchはローカルファイルとリモートのコピーが同一であるか確認する必要がある。ファイルの長さとチェックサムのみを使うのは不十分であることが確認された。このため、現在はセグメントのすべてのファイルの同一性を確認(#7159) その他のハイライト Elasticsearch 1.4.0.Beta1のchangelogに本リリースの多くの機能、改善、バグフィックスについて読むことができます。 ここでは、特筆すべきいくつかの変更について述べます。\ngroovyによるmvelの置き換え Groovyは現在、デフォルトのscripting languageです。 以前のデフォルトはMVELで、古くなってきており、サンドボックス内で実行できないという事実は、セキュリティ問題でした。 Groovyはサンドボックスであり(それは、ボックスの外へは許可が必要)、メンテナンスされており、速いです！ 詳しくはscriptingについてのブログ記事をご覧ください。\nデフォルトでcorsはオフ Elasticsearchのデフォルト設定はクロスサイトスクリプティングに対して脆弱でした。 私たちはデフォルトでCORSをオフにすることで修正しました。 Elasticsearchにインストールされたサイトプラグインはこれまで同様に機能します。 しかし、CORSを再度オンにすることがない限り、外部のウェブサイトがリモートのクラスタにアクセスすることはできません。 ウェブサイトがあなたのクラスタにアクセス可能に制御できるように、さらにCORS settingsを追加しました。 詳しくはsecurity pageをご覧ください。\nクエリキャッシュ 新しい試験的なshardレベルのクエリキャッシュは、静的なインデックスのアグリゲーションをほとんど即座に反応できます。 ウエブサイトのアクセスの日毎のページビュー数を見るダッシュボードを持っていると想像してみてください。 これらの数値は古いインデックスでは変更がありません。しかし、アグリゲーションはダッシュボードのリフレッシュのたびに再計算されます。 新しいクエリキャッシュを利用すると、シャードのデータが変更されない限り、アグリゲーションの結果はキャッシュから直接返却されます。 キャッシュから古い結果を決して取得することはありません。それは、常に、キャッシュされていないリクエストと同じ結果を返します。\n新しいaggregations 3つの新しいaggregationsがあります。\nfilters\nこれはfilter aggregationの拡張です。複数のバケットを定義し、バケット毎に異なるフィルタを利用できます。 children\nnestedアグリゲーションの親子版。children aggは親のドキュメントに属する子のドキュメントを集計できる scripted_metric\nこのaggregationは、データによって計算されたメトリックを完全にコントロールできます。これは、初期化フェーズ、ドキュメント収集フェーズ、shardレベル結合フェーズ、global reduceフェーズを提供します。 get /index api 以前、ある1つのインデックスのaliases、mappings、settings、warmersを取得出来ました。しかし、それらを個別にです。 get-index API はこれらのすべてもしくは一部を、複数もしくはひとつのインデックスに対して一緒に取得できます。 これは、既存のインデックスと同一もしくはほぼ同一であるインデックスを作成したいときに非常に役に立ちます。\n登録と更新 ドキュメントの登録と更新にいくつかの改善があります。\n現在、ドキュメントIDの自動生成のためにFlake IDを使用しています。これは、プライマリキー探索時に素晴らしい性能向上を提供します。 detect_noopにtrueを設定すると、ドキュメントに変更を与えない更新が軽量になります。この設定を有効にすると、_sourceフィールドのコンテンツを変更する更新リクエストだけ、ドキュメントの新しいバージョンを書き込みます。 更新はスクリプトから完全に操作できます。以前は、スクリプトはドキュメントがすでに存在しているときだけ実行可能で、それ以外は、upsertドキュメントで登録しました。script_upsertパラメータでスクリプトから直接ドキュメントの作成が操作できます。 function score すでに非常に便利なfunction_scoreクエリが、新しくweightパラメータをサポートします。 これは、それぞれの指定された関数の影響をチューニングするのに使われます。 これは、人気度よりも更新日時により重みをかけたり、地理情報よりも価格により重みをかけるといったことを可能にします。 また、random_score機能はセグメントマージによる影響を受けません。これにより、より一貫した順序が提供されます。\n試してみてください。 ぜひ、Elasticsearch 1.4.0.Beta1をダウンロードして、試してみてください。 そして、感想をTwitter(@elasticsearch)などで教えて下さい。 また、問題がありましたら、GitHub issues pageで報告をお願いします。\n","date":1412244840,"dir":"post/2014/","id":"853cac0f2d1f90b7c986e7d1dcdbbfde","lang":"ja","lastmod":1412244840,"permalink":"https://blog.johtani.info/blog/2014/10/02/elasticsearch-1-4-0-beta-released-ja/","publishdate":"2014-10-02T19:14:00+09:00","summary":"※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.0.beta1 released 本日、Lucene 4.10.1をベースにした、Elast","tags":["Elasticsearch"],"title":"elasticsearch 1.4.0.Beta1のリリース"},{"contents":"第6回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。 今回は、スタッフが私を含めて3，4名ということで、ドタバタしてしまってスミマセンでした。\n今回はキャンセルが多く、最終的には90人弱の参加となりましたが、今回も多数の方にお集まりいただきありがとうございました。 同じ日に他の勉強会もあった影響でしょうか？\n「Aggregationあれこれ」Elasticsearch Inc. Jun Ohtani @johtani スライド：Aggregationあれこれ\nちょっと長かったですかね。。。 Aggregationの概要、内部動作、種類などを簡単に紹介してみました。 個々のAggregationもいろいろなオプションなどがあるので、色々と試してみていただければと思います。 アニメーション入りのスライドになってましたが、UpしてあるスライドはPDF版になります。 「秒間3万の広告配信ログをElasticSearchでリアルタイム集計してきた戦いの記録」 株式会社サイバーエージェント　山田直行さん　@satully スライド：秒間3万の広告配信ログをElasticSearchでリアルタイム集計してきた戦いの記録\nディスプレイ広告配信DSPの話 システム: Fluentd、S3、Elasticsearch、Redis、MySQL 7月に秒間3万〜4万のリクエストをさばいている。 なぜElasticsearchを選んだのか、今の構成など 実際に苦労された点なども交えて話していただき面白かったです。 7月時点のお話ということで、現時点ではまた違う構成っぽかったので、また話を聞きたいなぁ。 「Elasticsearch 日本語スキーマレス環境構築と、ついでに多言語対応」ナレッジワークス株式会社　木戸国彦さん @9215 スライド：Elasticsearch 日本語スキーマレス環境構築と、ついでに多言語対応\nDynamic TemplateやIndex Templateの説明 日本語や多言語化するときのMappingのサンプルになりそうなものがゴロゴロ紹介されてました。 いくつかの例があって、後で見直したいなと。 途中で出てきた、fielddata（インデックスに入っている単語区切りのデータ）を見るのに使ってたクエリはfield data fieldsだったかな。 「elasticsearchソースコードを読みはじめてみた」@furandon_pig さん スライド：elasticsearchソースコードを読みはじめてみた\nリクエストを受けて検索してる部分から読むといいって言われたらしいが、起動スクリプトから読み始めてみた。 時間かかりそうｗ ただ、人がどんな感じでソースを読んだり理解してるかがわかりやすかったので面白かったです。 定期的に続きを聞いてみたいです。 LT 「reroute APIを使用してシャード配置を制御する」 株式会社富士通ソフトウェアテクノロジーズ 滝田聖己さん @pisatoshi スライド：reroute APIを使用してシャード配置を制御する\nシャードの再配置が自動で行われるので、それをオフにしないと、せっかく移動しても無駄になることがというあるあるネタ Bonsaiロゴを作成するLT 実際にいくら掛かったのかが知りたかった。 「検索のダウンタイム0でバックアップからIndexをリストアする方法」株式会社ドワンゴモバイル 西田和史さん スライド：検索のダウンタイム0でバックアップからIndexをリストアする方法\n擬似無停止のやりかた。 aliasを活用して、かつ、Restoreで再構築するという方法。 aliasまで一緒にリストアされるので注意が必要っていうのは、実際にやってみたからわかることという感じですね。 その他、感想などのブログ 適当に見つけたブログを列挙してあります。これもあるよ！などあれば、教えてください。\n第6回elasticsearch勉強会に行ってきましたのでそのメモ elasticsearch 勉強会 第6回 まとめ 今回も、ためになる話がいっぱい聞けたかなと。 個人的な印象としては、いつものメンバーよりも新しい方が多かった印象です。 また、ほとんどの方が、Elasticsearchをご存知でした。 そこそこ知名度は上がってきているようで嬉しい限りです。（東京以外での知名度なども知りたいかなと。）\nあと、懇親会の部屋の案内が遅くなってしまってスミマセンでした。 さすがにスタッフ3名はきつかったです。。。\n19時半開始にしてみましたが、懇親会の時間がやはり短めになってしまうなぁという印象でした。\n次回ももちろん2ヶ月後くらいに行います。 スピーカー募集中ですので、コメント、メール、ツイートなど、コンタクトしていただければと思います。 よろしくお願いいたします。\n","date":1410927720,"dir":"post/2014/","id":"4616fbea6a6dbc1074bc3f1016bbc73b","lang":"ja","lastmod":1410927720,"permalink":"https://blog.johtani.info/blog/2014/09/17/hold-on-6th-elasticsearch-jp/","publishdate":"2014-09-17T13:22:00+09:00","summary":"第6回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん","tags":["elasticsearch","勉強会"],"title":"第6回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"先日2014年9月9日(火)に『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』　出版記念！執筆者が語る大講演会！で、 「elasticsearch.もうちょっと入門」というタイトルで発表してきました。 会場のGMOのみなさま、Treasure Data、技術評論社のみなさま、どうもありがとうございました。\n書籍に興味のある方は、右のリンクから購入してもらえるとうれしいです。Kindle版も用意されています。\n提供のTDの方に目をつぶってもらいながらLogstashについての発表となってしまいましたが、楽しんでいただけたかなぁと。 書籍では主にKibana3をメインにしたElasticsearchの使い方だったので、それ以外の機能ということで、Aggregationについて説明してみました。\nそのあとは、おそらく初めてですが、パネルディスカッションにも参加しました。 @naoya_itoさんをモデレーターに、rebuild.fm風に進めていただき、話しやすかったかなと。 （少なくとも私は楽しめました！） ただ、私だけバックグラウンドが少し異なることもあり、話をうまく繋げられなかったかもと気にしていたりもしますが。。。\nパネルディスカッションでもありましたが、エンジニアが「趣味」で入れて試してみるのにはもってこいのツール群だと思います。 ちょっと入れてみて、可視化をしてみるといろいろと発見があると思います。 何かを発見するためにもまず試してみるのが何事も重要かなと最近思ってるのもあるので、気軽に試してみてもらえればと。\n不明点などあれば、著者陣に気軽に聞いていただけると良いかと思います（いいですよね、みなさんｗ）。 Fluentd（もちろん、Logstashも）、Elasticsearch、Kibanaを利用して、データについて試行錯誤してもらって、 システムやビジネスに必要なものを探索して見てください。\n参考 他の方々のブログをメモとして。\nサービス改善とログデータ解析について発表してきました Kibanaではじめるダッシュボードについて発表してきました #gihyo_efk Fluentdのお勧めシステム構成パターンについて発表しました ","date":1410841260,"dir":"post/2014/","id":"f15702ae9e55bad42182cf18724d1863","lang":"ja","lastmod":1410841260,"permalink":"https://blog.johtani.info/blog/2014/09/16/book-publication-event/","publishdate":"2014-09-16T13:21:00+09:00","summary":"先日2014年9月9日(火)に『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』 出版記念！執筆者が語る大講演会！で、 「elastics","tags":["勉強会","本"],"title":"elasticsearch.もうちょっと入門という話をしてきました #gihyo_efk"},{"contents":"Elasticsearchのインデキシングに関するパフォーマンス検討\n原文：performance considerations for elasticsearch indexing\nElasticsearchユーザは様々な楽しいユースケースを持っています。小さなログを追加することから、Webスケールの大きなドキュメントの集合をインデキシングするようなことまでです。また、インデキシングのスループットを最大化することが重要で一般的な目標となります。 「典型的な」アプリケーションに対して良いデフォルト値を設定するようにしていますが、次のちょっとした簡単なベストプラクティスによってインデキシングのパフォーマンスをすぐに改善することができます。それらについて記述します。\n第一に、制御できないならば、巨大なJavaヒープを使用しない：必要なサイズ（マシンの持つRAMの半分以下）のheapだけを設定しましょう。Elasticsearchの利用方法のために必要な全体量を設定します。これは、OSにIOキャッシュを制御するためのRAMを残すことを意味します。OSがjavaプロセスをスワップアウトしていないことも確認しましょう。\n最新バージョン（現時点では1.3.2）のElasticsearchにアップグレードしましょう：多数のインデキシングに関連する問題点が最新リリースで修正されています。\n詳細に入る前に警告：ここで述べるすべての情報は現時点での最新（1.3.2）の情報です。しかし、Elasticsearchの更新は日々行われています。この情報をあなたが見た時点では最新ではなく、正確ではなくなっているかもしれません。自信がない場合はユーザメーリングリストで質問してください。\nクラスタのインデキシングスループットをチューニングする場合、Marvelは非常に有用なツールです：ここで述べている各設定を継続的に試し、変更の影響がクラスタの挙動をどのように変更されたかを簡単に可視化することが可能です。\nクライアントサイド bulk APIを常に使いましょう。1リクエストで複数のドキュメントをインデキシングでき、各バルクリクエストで送るのに良いドキュメント数を試しましょう。最適なサイズは多くの要因に依存しますが、最適サイズからずれるならば多すぎるよりも少なすぎる方が良いでしょう。クライアントサイドのスレッドで並列にbulkリクエストを使うか、個別の非同期リクエストを使ってください。\nインデキシングが遅いと結論付ける前に、クラスタのハードウェアの性能を引き出せているかを確認して下さい：すべてのノードでCPUやIOが溢れていないかを確認するためにiostatやtop、psといったツールを使いましょう。もし、溢れていなければ、より多くの並列なリクエストが必要です。しかし、javaクライアントからのEsRejectedExecutionExceptionや、RESTリクエストのHTTPレスポンスとしてTOO_MANY_REQUESTS (429)が返ってきた場合は並列リクエストを多く送りすぎています。もしMarvelを利用しているなら、Node Statistics DashboardのTHREAD POOLS - BULKにリジェクトされた数が表示されます。bulkスレッドプールサイズ（デフォルト値はコア数）を増やすのは得策ではありません。インデキシングスループットを減少させるでしょう。クライアントサイドの並列度を下げるか、ノードを増やすのが良い選択です。\nここでは、1シャードに対してインデキシングスループットを最大化する設定に注目します。1つのLuceneインデックスのドキュメントの容量を測定するために、単一ノード（単一シャード、レプリカなし）で最初にテストをして最適化し、クラスタ全体にスケールする前にチューニングを繰り返します。これはまた、インデキシングスループットの要件を見つけるために、クラスタ全体にどのくらいのノードが必要かをラフに見積もるためのベースラインを与えてくれます。\n単一シャードが十分機能したら、Elasticsearchのスケーラビリティの最大の利点や、クラスタでの複数ノードによるレプリカ数やシャード数の増加の利点が得られます。\n結論を導き出す前に、ある程度の時間（60分）くらいクラスタ全体の性能を計測しましょう。このテストは、巨大なマージ、GCサイクル、シャードの移動、OSのIOキャッシュ、予期しないスワップの可能性などのイベントのライフサイクルをカバーできます。\nストレージデバイス 当然ながらインデックスを保存するストレージデバイスはインデキシングの性能に多大な影響を及ぼします：\nSSDを利用する：これらは最も速いHDDよりも速いです。ランダムアクセスのための消費電力が低いだけでなく、シーケンシャルIOアクセスも高いです。また、同時に発生するインデキシング、マージや検索のための並列的なIOも高速です。 インデックスをリモートマウントされたファイルシステム（例：NFSやSMB/CIFS）上に配置しない：代わりにローカルストレージを使う 仮想化されたストレージ（AmazonのElastic Block Storageなど）に注意：仮想化されたストレージはElasticsearchで十分に動作します。また、十分早く簡単に用意できることから魅力的です。しかし、残念なことに、ローカルストレージと比較すると本質的に遅いです。最近の非公式なテストでは、最高の性能を持つプロビジョニングされたIOPSのSSDオプションのEBSでさえ、ローカルインスタンスにあるSSDよりも遅いです。ローカルインスタンスにあるSSDは物理マシン上のすべての仮想マシンから共有されてアクセスされます。もし他の仮想マシンが急にIOが集中した場合に不可解なスローダウンとなることがあることを覚えておいてください。 複数のSSDを複数のpath.dataディレクトリにインデックスをストライピング（RAID0のように）：2つは同様で、ファイルブロックレベルでストライピングする代わりに、個別にインデックスファイルレベルでElasticsearchの\u0026quot;stripes\u0026quot;となります。これらのアプローチは、いづれかのSSDの故障によりインデックスが壊れるという、1シャードが故障する(IO性能を高速化することとトレードオフ)というリスクを増加させることに注意してください。これは、一般的に行うのに良いトレードオフです：単一シャードで最大のパフォーマンスを最適化し、異なるノード間でレプリカを追加すると、ノードの故障への冗長化ができます。また、snapshotやrestoreを使って保険のためにインデックスのバックアップを取ることもできます。 セグメントとマージ 新しくインデキシングされたドキュメントは最初にLuceneのIndexWriterによってRAMに保存されます。RAMバッファがいっぱいになった時もしくは、Elasticsearchがflushもしくはrefreshを実行した時など定期的にこれらのドキュメントはディスクに新しいセグメントとして書き込まれます。最後に、セグメントが多くなった時に、Merge PolicyとSuchedulerによってそれらがマージされます。このプロセスは連続的に生じます：マージされたセグメントはより大きなセグメントとなり、小さなマージが幾つか実行され、また、大きなセグメントにマージされます。これらがどのように動作するかをわかりやすく可視化したブログはこちらです。\nマージ、特に大きなマージは非常に時間がかかります。これは、通常は問題ありません。そのようなマージはレアで全体のインデックスのコストと比べればささいなものです。しかし、マージすることがインデキシングについていけない場合、インデックスに非常に多くのセグメントがあるような深刻な問題を防ぐために、Elasticsearchはやってくるインデキシングリクエストを単一スレッド(1.2以降)に制限します。\nもし、INFOレベルのログメッセージにnow throttling indexingと表示されていたり、Marvelでのセグメント数が増加しているを見た場合、マージが遅れているとわかります。MarvelはIndex Statistics dashboardのMANAGEMENT EXTENDEDの部分にセグメント数をプロットしており、それは、非常にゆっくりと指数対数的に増加しており、大きなマージが終了したところがのこぎりの歯のような形で見て取れます。\nセグメント数 なぜマージが遅れるのでしょう？デフォルトでElasticsearchはすべてのマージの書き込みのバイト数をわずか20MB/secに制限しています。スピニングディスク（HDD）に対して、これはマージによって典型的なドライブのIOキャパシティを飽和させず、並列に検索を十分に実行させることを保証します。しかし、もし、インデキシング中に検索をしない場合や、検索性能がインデキシングのスループットよりも重要でない場合、インデックスの保存にSSDを使用している場合などは、index.store.throttle.typeにnoneを設定して、マージの速度制限を無効化するべきです（詳細はこちらをご覧ください）。なおバージョン1.2以前には期待以上のマージIO制限の発生といったバグが存在します。アップグレードを！\nもし、不幸にもスピニングディスク（それはSSDと同等の並列なIOを扱えません）をまだ使っている場合、index.merge.scheduler.max_thread_countに1を設定しなければなりません。そうでない場合は、（SSDを支持する）デフォルト値が多くのマージを同時に実行させるでしょう。\n活発に更新が行われているインデックスでoptimizeを実行しないでください。それは、非常にコストの高い操作(すべてのセグメントをマージ)です。しかし、もし、インデックスにドキュメントを追加が終わった直後はオプティマイズのタイミングとしては良いタイミングです。それは、検索時のリソースを減らすからです。例えば、時間ベースのインデックスを持っており、新しいインデックスに日々のログを追加している場合、過去の日付のインデックスをオプティマイズするのは良い考えです。特に、ノードが多くの日付のインデックスを持っている場合です。\n更にチューニングするための設定：\n実際に必要のないフィールドをオフにする。例えば_allフィールドをオフ。また、保持したいフィールドでは、indexedかstoredかを検討する。 もし、_sourceフィールドをオフにしたくなるかもしれないが、インデキシングコストは小さい(保存するだけで、インデキシングしない)、また、それは、将来の更新や、前のインデックスを再インデキシングするために非常に価値があり、それはディスク使用率の懸念事項がない限り、オフにする価値はあまりない。それは、ディスクが比較的安価であるので価値がない。 もし、インデックスされたドキュメントの検索までの遅延を許容できるなら、index.refresh_intervalを30sに増やすか、-1を設定して、オフにする。これは、巨大なセグメントをフラッシュし、マージのプレッシャーを減らすことができる。 Elasticsearch 1.3.2(稀に、フラッシュ時に過度のRAMを使用するという問題を修正した)にアップグレードすることで、index.translog.flush_threshold_sizeをデフォルト(200mb)から1gbに増加し、インデックスファイルのfsyncの頻度を減らす。 MarvelにIndex Statistics dashboardのMANAGEMENTにフラッシュの頻度がプロットされている。 インデックスバッファサイズ 巨大なインデックスを構築中はレプリカ数を0にし、あとから、レプリカを有効にする。レプリカが0ということは、データを失った(ステータスがred)時に冗長性がないので、ノードの故障に注意すること。もし、optimize(ドキュメントの追加をすることがないので)を計画するなら、インデキシングが終わったあとで、レプリカを作成する前に実行するのが良いでしょう。レプリカはオプティマイズされたセグメントをコピーするだけになります。詳細はインデックス設定更新を参照。\nもし、ノードがヘビーなインデキシングを行っているだけなら、アクティブなシャードのインデキシングバッファに多くてい512MBをindices.memory.index_buffer_sizeに与えてください。(超えてもインデキシングのパフォーマンスは一般的には改善されません。)Elasticsearchはその設定(Javaヒープのパーセンテージもしくはバイト数)を受けて、min_index_buffer_sizeとmax_index_buffer_sizeの値を前提にノードのアクティブシャードに均等に割り当てます；大きな値はLuceneが最初のセグメントをより大きくし、将来的なマージのプレッシャーを減らすことを意味します。\nデフォルトは10%で、それで十分です；例えば、もし、5つのアクティブなシャードがノードにあり、ヒープが25GBの場合、各シャードは25GBの10%の1/5=512MB（すでに最大値）を持っています。ヘビーなインデキシングのあと、この設定をデフォルトに下げましょう。検索時のデータ構造のために十分なRAMを確保するために。この設定はまだ動的な設定変更はできません。Issueがここにあります。\nインデックスバッファによって現在利用されているバイト数は1.3.0のindices stats APIに追加されています。indices.segments.index_writer_memoryの値を見ることができます。これはMarvelではまだプロットされていませんが、将来のバージョンで追加される予定です。しかし、自分でグラフに追加することもできます。(Marvelはデータは収集しています)\n1.4.0では、indices.segments.index_writer_max_memoryとして、indices stats APIにアクティブシャードにどのくらいのRAMバッファが割り当てられているかも表示されます。これらの値はインデックスのシャード事の値として見ることができ、http://host:9200/\u0026lt;indexName\u0026gt;/_stats?level=shardsを使ってみることができます；これは、全シャードに対する合計と、各シャードごとのstatsを返すでしょう。\nオートIDの利用もしくは良いIDの利用 もし、ドキュメントのIDがなんでも良い場合、Elasticsearchで採番することができます：これは、(1.2以降)ドキュメントIDをバージョンを探さずに保存できるように最適化され、Elasticsearchの日毎のベンチマークで異なるパフォーマンスを見ることができます。(FastとFastUpdateのグラフを比較)\nもし、IDを自身が持っていて、自分の支配下でLuceneに対して素早く選ぼうとしているなら、1.3.2にアップグレードしましょう、IDのルックアップがさらにオプティマイズされています。JavaのUUID.randomUUID()はやめましょう。それは、セグメントに対してどのようにIDを割り当てるかという予測やパターン性がないため、最悪のケースでセグメントごとのシークが発生します。\nFlake IDsを利用した時のMarvelによるインデックス性能の違い：\nflakeIDsPerf ランダムUUIDを利用した場合：\nuuidsPerf 次の1.4.0では、ElasticsearchのID自動採番をUUIDからFlake IDに変更します。\nもし、Luceneのローレベル操作がインデックスに対してなにをやっているかについて興味があるなら、lucene.iwをTRACEログレベルで出力できるようにしてみましょう(1.2から利用可能)。これは、多くの出力がありますが、LuceneのIndexWriterレベルで何が起きているかを理解するのに非常に役に立ちます。出力は非常にローレベルです：Marvelがインデックスに何が起きているかをよりリアルタイムにグラフを描画してくれます。\nスケールアウト 我々は、単一シャード(Luceneインデックス)性能のチューニングに注目してきました。しかし、一旦それに満足できたならば、Elasticsearchはクラスタ全体にわたってインデキシングや検索を簡単にスケールアウトすることに長けています。シャード数(デフォルトでは5)を増やすのは可能です。それは、マシン全体に対して並列度、巨大なインデックスのサイズ、検索時のレイテンシの低下など得ることができます。また、レプリカを1位上にすることは、ハードウェア故障に対する冗長性を持つことを意味します。\n最後に、このドキュメントを見ても問題解決しない場合はコミュニティに参加しましょう。例えば、ElasticsearchのユーザMLに投稿するなど。おそらく、修正すべきエキサイティングなバグがあるでしょう。(パッチも常に歓迎です！)\n","date":1410250260,"dir":"post/2014/","id":"77d965afaebd7193badc746d52b4173f","lang":"ja","lastmod":1410250260,"permalink":"https://blog.johtani.info/blog/2014/09/09/performance-considerations-for-elasticsearch-indexing/","publishdate":"2014-09-09T17:11:00+09:00","summary":"Elasticsearchのインデキシングに関するパフォーマンス検討 原文：performance considerations for elasticsearch indexing Elasticsearchユーザは様","tags":["Elasticsearch"],"title":"Elasticsearchのインデキシングに関するパフォーマンス検討"},{"contents":"懲りずにまた、執筆してみました。みなさん「買って」から感想をいただけるとうれしいです！\n本書について 共著者の方々のブログが詳しいので、そちらを読んでもらいつつ。 実際にログを収集して解析されている方々と一緒に書かせていただくことで色々と勉強させていただいています。\n共著者の方々のブログ @suzu_vさん：サーバ/インフラエンジニア養成読本 ログ収集~可視化編 を書きました @yoshi_kenさん：ログ収集や可視化で話題のFluentd、Elasticsearch、Kibanaを徹底解説したムック本が発売となります @harukasanさん：書きました: サーバ/インフラエンジニア養成読本 ログ収集~可視化編 どの辺を書いたの？ 「特集３：Elasticsearch入門」（なんか、入門ばっかりだなぁ）を書かせていただきました。 データストア入門ということで、ほんとうに簡単な他のデータストアを説明し、Elasticsearchってどんなものかを単語の説明をしつつ紹介してみました。\nElasticsearch自体は多くの機能を持っており、それ単体で分厚い書籍がかけるので、ログ検索に関係ありそうな部分をピックアップしてみました。 あとは、運用時に気をつける点や便利なツール（Curatorなど）の紹介をしています。\nまた、Hadoopと合わせて利用してみたい、すでにHadoopにあるデータも活用してみたいという話もありそうだということで、elasticsearch-hadoopについても簡単ですが紹介してあります。\nその他感想 個人的に、忙しい時期（参考記事）だったので、あんまり力になれてないので大変申し訳なく思っています。。。 ただ、素晴らしい出来（カラーでKibanaの解説が日本語で読めたり、Fluentdの逆引きのリストがあったり、ログを貯めて可視化する意義を説明してあったり）です。\nぜひ、読んだ感想をいただければと！\n","date":1407156840,"dir":"post/2014/","id":"bdea71d64cdfcc405e65e750fe8d9b86","lang":"ja","lastmod":1407156840,"permalink":"https://blog.johtani.info/blog/2014/08/04/release-magazine-book-of-log-aggs-and-viz/","publishdate":"2014-08-04T21:54:00+09:00","summary":"懲りずにまた、執筆してみました。みなさん「買って」から感想をいただけるとうれしいです！ 本書について 共著者の方々のブログが詳しいので、そちらを","tags":["elasticsearch","kibana","本"],"title":"サーバ/インフラエンジニア養成読本 ログ収集~可視化編 を手伝いました"},{"contents":"Proxy環境で働いている方も結構いると思います。 Twitter上で、Elasticsearchのpluginコマンドでプラグインがインストールできなくて困っている方がいたので、 調べてみたのでメモしておきます。\nプラグインコマンド Elasticsearchでは、プラグインという形でいくつかの便利な機能が公開されています。 形態素解析ライブラリのKuromojiを使うためのプラグインや、クラスタの管理がGUIで可能なkopfプラグインなどがあります。 公式、サードパーティいろいろです。\nこれらのプラグインをElasticsearchにインストールする場合、以下のコマンドを実行すれば 自動的にダウンロードしてpluginsディレクトリにインストールしてくれます。\n./bin/plugin -i elasticsearch/elasticsearch-analysis-kuromoji/2.3.0 ここで、elasticsearch/elasticsearch-analysis-kuromoji/2.3.0がプラグインのパスになります（例では、提供元/プラグイン名/プラグインバージョンとなっています。）。\nこのpluginコマンドがダウンロード元にアクセスに行くのですが、プロキシ環境だとプロキシの設定が必要になります。\nプロキシの指定（Mac/LinuxとWindowsでの違い） Mac/Linux(shコマンド) 以前の記事でプロキシのポート番号などの指定方法を 以下のように説明していました。 （※昔の記事のため、kuromojiプラグインのバージョンが古いです）\nElasticsearchのpluginコマンドはJavaで実装されています。（org.elasticsearch.common.http.client.HttpDownloadHelper） プラグインのダウンロードには、java.net.URL.openConnection()から取得URLConnectionを使用しています。\nですので、pluginのインストールを行う際に、Proxy環境にある場合は以下のようにコマンドを実行します。\n./bin/plugin -DproxyPort=ポート番号 -DproxyHost=ホスト名 -i elasticsearch/elasticsearch-analysis-kuromoji/1.5.0 LinuxやMacの環境であれば、こちらのコマンドでプロキシの指定が可能です。 ただし、Windows環境ではうまくいきません。\nElasticsearchは、環境の違いにより、ダウンロードするファイルが異なります。 Windows環境の方は、zipファイルをダウンロードしてもらうようになっています。 elasticsearchコマンドおよびpluginコマンドがbat形式で提供されているのがzipファイルとなるからです。\nWindows(batコマンド) Windows環境では次のように指定します。\nset JAVA_OPTS=\u0026#34;-DproxyHost=ホスト名 -DproxyPort=ポート番号\u0026#34; bin\\plugin -i elasticsearch/elasticsearch-analysis-kuromoji/2.3.0 コマンドの実装方法が少し異なるために、このようになっています。\nまとめ プロキシ環境で利用される場合は、プラグインコマンドは上記のように実行していただければと。\n公式ガイドには、これらの情報を追記するPRを送る予定です。 また、WindowsのコマンドでもMac/Linuxと同様にできたほうがいい気がするので、Issueをあげようと思います。\n不明点などあれば、コメントいただければと。\n","date":1406874240,"dir":"post/2014/","id":"7cc605e721fdd1d2ccc16f5b6490e830","lang":"ja","lastmod":1406874240,"permalink":"https://blog.johtani.info/blog/2014/08/01/plugin-using-under-proxy-env/","publishdate":"2014-08-01T15:24:00+09:00","summary":"Proxy環境で働いている方も結構いると思います。 Twitter上で、Elasticsearchのpluginコマンドでプラグインがインスト","tags":["elasticsearch","plugin"],"title":"プロキシ環境でのpluginコマンドの実行"},{"contents":"原文：Elasticsearch 1.3.1 Releasedを日本語に翻訳したものです。\nバグフィックス版のElasticsearch 1.3.1をリリースしました。 ダウンロードおよび変更履歴はElasticsearch 1.3.1からお願いいたします。\nこのリリースはインデックスリカバリ時の後方互換性バグ（#7055）への対応です。 このバグはデータの欠損は起こりません。 Elasticsearch 1.3.1へアップグレードすることで問題を回避できます。 このバグは、以下のElasticsearchのバージョンで作成されたセグメントを含むインデックスを1.3.0へアップグレードしようとすると発生します。\nElasticsearch 0.90.7 Elasticsearch 0.90.2 Elasticsearch 0.90.0以前のバージョン このバグは、これらの古いインデックスをレプリカからリカバリできなくします。 これらのバージョンのセグメントを持つインデックスが、レプリカは可能ですが、 ステータスがYellowのままGreenに決してなりません。 ログには次のようなExceptionが発生します。\nIllegalArgumentException[No enum constant org.apache.lucene.util.Version.x.x.x]\nLuceneの特定のバージョンではLuceneのマイナーバージョンを含んでおらず、誤ったバージョン番号がセグメントに記録されました。 LUCENE-5850のチケットがこの問題に対処するためにオープンされています。 この問題は我々の後方互換テストで見つかるべき問題ですが、Luceneで不足しているため発見されませんでした。 テストスイートは今後の可能性のために改良されます。\nこのリリースはその他に、Aggregationのマイナーバグフィックスも含まれています。 詳細はリリースノートをご覧ください\nElasticsearch 1.3.1をダウンロードし、試してください。 もし問題を見つけた場合はGitHubのIssuesへご報告をお願いいたします。\n","date":1406604120,"dir":"post/2014/","id":"fb1da4a6ed74705ad98bb60ad4badaf2","lang":"ja","lastmod":1406604120,"permalink":"https://blog.johtani.info/blog/2014/07/29/elasticsearch-1-3-1-release/","publishdate":"2014-07-29T12:22:00+09:00","summary":"原文：Elasticsearch 1.3.1 Releasedを日本語に翻訳したものです。 バグフィックス版のElasticsearch 1.3.1をリリー","tags":["elasticsearch","release"],"title":"Elasticsearch 1.3.1 リリース（日本語訳）"},{"contents":"Curatorの1.2.0がリリースされました。\n前回のCuratorの記事が古くなってしまった（1.1.0からコマンドのI/Fが変更された）ので 1.1.0および1.2.0に関する記事を翻訳しておきます。\nちなみに、Curatorとは、Elasticsearchに時系列のインデックス（例：LogstashやFluentdでログを保存）を保存している場合にそれらのインデックスを管理（削除したり、クローズしたり）するための便利なツールです。 Curatorの概要については、GitHubリポジトリか前回の記事をご覧ください。\nCurator 1.1.0リリース (2014/06/13公開) 元記事：elasticsearch curator - version 1.1.0 released\nElasticsearch 1.0.0がリリースされ、新しい機能、Snapshot \u0026amp; Restoreが利用できるようになりました。 Snapshotはある時点でのインデックスの写真を撮るように、バックアップを作成することができます。 1.0.0が発表されてすぐに、この機能に関するリクエストが寄せられるようになりました。 「Curatorにスナップショットを追加して！」もしくは「いつCuratorでスナップショットが使えるようになる？」といった感じです。 これがあなたの要望なら、それはついに叶えられました。しかも他の追加機能も一緒にです。\n新機能 Curatorの新機能は以下のとおりです。\n新CLI構造 スナップショット(Snapshot) エイリアス(Aliases) パターンによる除外インデックス指定 配置ルーティング(Allocation Routing) インデックスとスナップショットの表示 リポジトリ管理(個別のスクリプトによる) ドキュメントWiki 新コマンドライン構造 注意：コマンドライン構造の変更とは、Curator 1.1.0以前のcron記述が動作しないことを意味します。Curator 1.1.0にアップグレードする場合はコマンドも修正が必要となるので注意してください。\nシンプルにするために、commandsという概念を追加しました。 また、ヘルプの出力もわかりやすくなっています。 前のバージョンと同じタスクをCuratorは実行できますが、異なるフォーマットを用いるようになりました。\n旧コマンド：\ncurator -d 30 新コマンド：\ncurator delete --older-than 30 コマンドは、フラグとは異なりハイフンを前に付けないことに注意してください。 また、似たような名前のフラグがあることに気をつけてください。 例えば、--older-thanフラグは多くのコマンドに利用できます。 指定される値は各ケースにおいて同一です。「指定された数よりも古いインデックス」となります。\n新しいコマンドのリストは次のとおりです。\nalias allocation bloom close delete optimize show snapshot コマンドのヘルプは次のコマンドで表示されます。\ncurator [COMMAND] --help コマンドに関係あるフラグがすべて表示されます。\nスナップショット(snapshots) snapshotコマンドで、存在しているリポジトリにインデックスのスナップショットを保存することができます。\nCuratorはインデックス毎に1つのスナップショットを作成し、インデックスから名前をつけます。 例えば、インデックスの名前がlogstash-2014.06.10の場合、スナップショットの名前はlogstash-2014.06.10となります。 指定した条件を元に、シーケンシャルに、1つずつインデックスのスナップショットを作成していきます。\ncurator snapshot --older-than 20 --repository REPOSITORY_NAME このコマンドは、20日以上古いインデックスすべてのスナップショットを作成し、REPOSITORY_NAMEで指定されたリポジトリに保存します。\nes_repo_mgrと呼ばれるリポジトリ作成を支援するスクリプトがCuratorには含まれています。 ファイルシステムおよびS3タイプのリポジトリ両方の作成を支援します。\nさらに、古いインデックスのスナップショットを取ることができることに加えて、Curatorは最新のインデックスをアップロードする方法も提供します。 これは、Elasticsearch Marvelのインデックスをアップロードするときに便利です。 トラブルシューティングを目的として、パフォーマンスデータを他の人に見せる場合などです。\ncurator snapshot --most-recent 3 --prefix .marvel- --repository REPOSITORY_NAME このコマンドでは、最新の3つのMarvelインデックスのスナップショットを指定されたリポジトリに保存できます。\nエイリアス(aliases) Curatorはすでに存在するエイリアスにインデックスを追加することも、削除することもできるようになりました。 ただし、エイリアスがすでに存在している必要があります。エイリアスの作成はできません。\nlast_weekという前の一週間のインデックスのエイリアスを保持していること想像してください。 この場合、次の2つのコマンドを利用することで、エイリアスを管理できます。\ncurator alias --alias-older-than 7 --alias last_week curator alias --unalias-older-than 14 --alias last_week 新しく作られたインデックスがインデックステンプレートによって 自動的にエイリアスの一部となるようにElasticsearchに設定しておくと、さらに便利です。 この場合、新しいインデックスが自動的にthis_weekというエイリアスの一部になるようにしてあれば、以下のコマンドのみとなります。\ncurator alias --unalias-older-than 7 --alias this_week this_weekとlast_weekのエイリアスのアップデートを保持できます。\nパターンによる除外(exclude pattern) 時には、指定したインデックスを操作から除外したくなる場合もあるでしょう。 ここまでは、プレフィックスや日付によって選択されたインデックスのみを対象にしてきました。 そこで、--exclude-patternオプションです。これは、指定したインデックスを除いて処理を行うことができます。\nlogstash-2014.06.11というインデックスを決して削除したくないとします。 この場合、次のコマンドのようになります。\ncurator delete --older-than 15 --exclude-pattern 2014.06.11 Curatorはデフォルトでlogstash-というプレフィックスにマッチしますが、2014.06.11というインデックスは対象外となります。\n配置ルーティング(allocation routing) Elasticsearchはノードにタグを付けることができます。 これらのタグはインデックスやシャードをクラスタのどこに配置するかをコントロールするために役立ちます。 一般的なユースケースだと、高性能なSSDドライブを持ったノードをインデキシングのために、ハードディスクを持った性能の低いマシンは検索頻度が低い古いインデックスを配置するといった場合です。 この場合、HDDノードには、elasticsearch.ymlにnode.tag: hdd、SSDノードにはnode.tag: ssdと設定されているべきです。 Curatorはこの時、インデックスをタグに基づいてオフピークの時間帯に再配置させることができます。\nコマンド：\ncurator allocation --older-than 2 --rule tag=hdd index.routing.allocation.require.tag=hddという設定が２日よりも古いインデックスに適用されます。 これは、インデックスのシャードがnode.tag: hddというノードに再配置される必要があると、Elasticsearchに伝えます。\nインデックスとスナップショットの表示(show indices and snapshots) これは、単にあなたの持っているインデックスやスナップショットがどんなものかを表示します。\ncurator show --show-indices これは、デフォルトプレフィックスのlogstash-にマッチするすべてのインデックスを表示します。\ncurator show --show-snapshots --repository REPOSITORY_NAME これは、指定されたリポジトリにある、デフォルトプレフィックスのlogstash-にマッチするすべてのスナップショットを表示します。\nリポジトリ管理(repository management) 前に説明したとおり、es_repo_mgrと呼ばれるヘルパースクリプトをCuratorは含んでいます。 現時点では、fsとs3タイプをサポートしています。 リポジトリを作る前に利用したいタイプのドキュメントを読むようにしてください。 例えば、fsタイプのリポジトリを各ノードで使う場合は、同じ共有ファイルシステムに、同じパスでアクセスできなければなりません。 パスの指定は--locationです。\nfsタイプリポジトリの作成\nes_repo_mgr create_fs --location \u0026#39;/tmp/REPOSITORY_LOCATION\u0026#39; --repository REPOSITORY_NAME 削除\nes_repo_mgr delete --repository REPOSITORY_NAME ドキュメントWiki Curatorのドキュメントが更新され、オンラインにWiki形式でだれでも更新できるようになっています。 コマンドやフラグのより詳細の情報はこちらで見つけることができます。また、もし、興味があれば、ドキュメントを追加することもできます。\nインストールと更新 Curator 1.1.0はPyPiリポジトリにあります。 インストールは以下のとおりです。\npip install elasticsearch-curator バージョン1.0.0からアップグレードする場合は以下のとおりです。\npip uninstall elasticsearch-curator pip install elasticsearch-curator バージョン1.0.0よりも古いバージョンからのアップグレードは以下のとおりです。\npip uninstall elasticsearch-curator pip uninstall elasticsearch pip install elasticsearch-curator pip uninstall elasticsearchで、古いパイションモジュールをを削除します。 適切なバージョンが依存関係により再インストールされます。\nまとめ Curatorの新機能は素晴らしいです！このリリースは大きな改善です。 もし、トラブルや足りないものを見つけた場合はGitHub Issueに報告してください。 また、Curatorが便利だと思ったら、私たちに伝えてください。#elasticsearchタグを付けてツイートしてください！\nCuratorはまだ、始まったばかりです。Curator 2.0のロードマップを作業中です。ここまで読んでいただきありがとうございます。 Happy Curating!\nCurator 1.2.0リリース(2014/07/24) 元記事：curator 1.2.0 released\nCurator v1.1.0のリリースから、数週間が経ちました。 私たちは、Curator 1.2.0をリリースしました。\n新機能(new features) ユーザ指定の日付パターン：長い間リクエストされていた機能 ウィークリーインデックスのサポート：これも長い間リクエストされていた機能 複数のログフォーマットオプション：Logstashフォーマットが利用可能 これらの変更はCuratorドキュメントにも記載されています。\n更新(updates) ログ出力の整理：デフォルトのログ出力を整理しました。デバッグログはすべて表示されます。 ドライランのログ出力の詳細化：テスト実行時に何が起きたかをわかりやすくしました。 日付パターンと--timestring(date patterns and \u0026ndash;timestring) 前のリリースで、セパレータ文字を利用して、インデックス名のエレメントを分離することで、日付を計算しました。 この設計の決定は、プログラムが管理するために設計されたLogstashのインデックスを使うのには簡単でした。 しかし、Curatorは時系列インデックス管理に成長しています。これは、異なる命名規則のインデックスを意味しています。\nまた、インターバルによって、日付の計算が必要になる場合もあります。 --time-unitオプションが残っており、weeksという単位を指定することもできます。 デフォルトの--timestringオプションは、以前のコマンドと同様の動作をしなければなりません。次のようになります。\nTime Unit Timestring days %Y.%m.%d hours %Y.%m.%d.%H weeks %Y.%W これが意味するものは、もし、単位にhoursをした場合、--timestringを指定しなかった場合は%Y.%m.%d.%Hとなります。 これは、Pythonのstrftimeフォーマットで\u0026quot;年.月.日.時\u0026quot;を意味します。 同様に、weeksを単位に指定した場合、Curatorはデフォルトの--timestringは%Y.%Wとなります。\nこの機能は、日付の間にセパレーター文字のないインデックスでも機能します。 例えば、production-20140724のような日時インデックスがある場合、2日よりも古いインデックスに対するブルームフィルタっキャッシュのオフのコマンドは次のようになります。\ncurator bloom --prefix production- --older-than 2 --timestring %Y%m%d この例で、デフォルトの単位はdaysであることに注意してください。hourly-2014072414のような時間インデックスの場合は次のようになります。\ncurator bloom --prefix hourly- --older-than 2 --time-unit hours --timestring %Y%m%d%H --separatorの置き換え もし、Curatorの前のバージョンでカスタムセパレータ文字を利用していた場合、次のように変更すべきです。 前のコマンドでcerberus-2014-07-24のようなインデックスがある場合、コマンドを--separator -の用に置き換える必要があります。 新しいコマンドは次のとおりです。\ncurator delete --prefix cerberus- --older-than 30 --timestring %Y-%m-%d 年(％Y)と月(%m)と日(\u0026rsquo;%d\u0026rsquo;)の間にセパレータ文字を置くだけです。\nこれは、また、Curatorで以前は不可能であったことをできるようにもします。 異なるセパレータ文字の混在です。 logs-2014.07.24-14というようなインデックスを処理するときに--timestringは%Y.%m.%d-%Hのようになります.\n--timestringの詳細はCuratorのドキュメントをご覧ください。\nフィードバック これらの新しい機能はユーザのコメントやリクエストから来ています。もし、機能のリクエストやバグを発見したら、こちらまで連絡してください。\nまた、Twitterでもお待ちしています。私たちのTwitter IDは@elasticsearchです。\nHappy Curating!\n","date":1406524740,"dir":"post/2014/","id":"0c1821d1069578551d0e3c7d9275f16b","lang":"ja","lastmod":1406524740,"permalink":"https://blog.johtani.info/blog/2014/07/28/curator-2-0-and-1-1/","publishdate":"2014-07-28T14:19:00+09:00","summary":"Curatorの1.2.0がリリースされました。 前回のCuratorの記事が古くなってしまった（1.1.0からコマンドのI/Fが変更された）","tags":["elasticsearch","curator"],"title":"Curator 1.2および1.1について"},{"contents":"第5回Elasticsearch勉強会を開催しました。 遅くなってしまいましたが、まとめてみました。\n今回は、Elasticsearchに入って初の勉強会でした。タイミングが良いことに、Honza、Igor、Shayの3名がトレーニングのために 来日していたため、特別回ということにして、話をしてもらいました。\nそして、サムライズムの@yusukeさんにテキスト翻訳してもらいました。 早くて正確なタイピング＋翻訳、本当にありがとうございました。\n開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！ 参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\namazing turnout to the elasticsearch at Tokyo #elasticsearchjp pic.twitter.com/Aa88eVf5dF\n\u0026mdash; Shay Banon (@kimchy) 2014, 7月 14 動画があとで、アップされる予定です。お楽しみに。\nHonza\u0026rsquo;s talk djangoの開発者！であり、ElasticsearchのPythonクライアント、Curatorの開発者 Python Clientを利用しながら、ライブコーディングのような形で説明する方法が新鮮 Aggregationの便利さについての説明 Python Clientがクエリを組み立てるのにすごく便利そうだった Pythonユーザが結構いたので助かりましたｗ Igor\u0026rsquo;s talk スライド：elasticsearch data/\nSnapshot/Restoreの開発などを行っている開発者 Elasticsearchのデータ、ディレクトリ構造に関するお話 シャードの話から、ディレクトリ構造、メタデータに関する説明 transaction logの挙動の説明 検索のフェーズの説明 Igorは、実は私がElasticsearch社の人とコンタクトがとれた最初の人だと思います。 第1回Elasticsearch勉強会が開催する当日に帰国されるという不運だったのですが、1年越しでトークしてもらえました！\n@johtani I am so bummed! I am leaving Tokyo Thursday morning.\n\u0026mdash; Igor Motov (@imotov) 2013, 8月 27 QA ShayをメインにいくつかのQAをしてもらいました。 NetflixなどのMeetupの動画で見てたのですが、こんな形で日本でも実現できるとは。\nQ: なんで、ファイルデスクリプタの設定を大きくするの？ A: Luceneのインデックスは複数のセグメントから構成されている。メモリに作られたあと、ファイルにfsyncされる。 Q: KibanaでAggregation使いたいんだけど？ A: Kibana 4で対応するよ！異なるフィールドの値を1つのグラフにすることも出来るよ！ Q: なんでElasticsearch作ったの？ A: 暇だったからｗ奥さんのレシピ検索を作ってみようと思って作り始めて、Luceneを触って感動して。。。検索すげー、Compassってのを触ってこれもすごいと思いつつ、もっとLucene活用できるんじゃないかということでElasticsearch作ったんだ。奥さんのレシピ検索？まだ完成してないよｗ Q: 2000くらいスナップショット撮ったらパフォーマンスが悪くなっててなんで？ A: 差分でスナップショットを作るんだけど、差分の計算に昔のスナップショットを見るので、定期的に新しくしたほうがいい。もし、気になることがあったらIssue上げたりMLに投げてくれるとうれしい。\n（あとでちょっと聞いたけど、古いスナップショットを消すのも有効っぽい。差分でスナップショットを作るけど、昔のを消した場合は、新しいスナップショットが利用しているファイルは残る仕組みになっているから。） Q: Relevancyのチューニングってどうすればいい？ドキュメントが少なくない？ A: ドキュメンテーションは頑張ってるので、応援してねｗあとは、definitive guideも参考になるよ。スコアはfunction_scoreクエリがすごいのでいろいろ使ってね。MVELをGroovyに帰る予定。性能もだけど、サンドボックス的な意味もあります。 Q: 次のVisionは？現時点は検索だけど。（最後の質問がとてもナイスで、助かりましたｗ私がしたほうがいい気がするｗｗ） A: 今後はアナリティクスのプラットフォームに向かってる。Aggregationとかね。メモリ効率よくしたりしてるよ。あとは、Field-collapsionも実装中だよ。あと、マシンラーニングとかもね。データを探索するための機能を色々作ってくよ。障害性にも。チェックサム機能をLuceneに入れて、ESにも入れていく予定。Zenの機能も改善している。 まとめ 今週は、トレーニングがあったり、いろいろな打ち合わせがあったりと、テンパってたので至らない点が多かったかもしれないですが。。。 楽しんでいただけと思います。 数日、Shay、Honza、Igorと行動を共にして、本当に情熱のあるチームでユーザのことを気にかけているなと感じることができました。 少しでもその片鱗を勉強会で感じてもらえたんじゃないかと。特に、QAでのShayによる情熱が伝わったんじゃないかと。\n懇親会でも数人の方から、日本語のサポートを望んでいるという声も頂きました。 興味のある方は私までコンタクトいただければと。\nあと、@yusukeさんのテキスト翻訳が素晴らしくて、参加してもらった方たちも絶賛してました。 次回も英語スピーカーの場合に助けてもらえると嬉しいです（私もそこまで出来るように頑張ります）\nその他のブログ ブログ記事ありがとうございます！\n第5回elasticsearch勉強会にいってきました - はやさがたりない。 感想戦：aggrigation から見える検索エンジンの次 - 第5回 Elasticsearch勉強会 - よしだのブログ 「第5回elasticsearch勉強会 #elasticsearch #elasticsearchjp」（2014年07月14日）の参加メモ - uchimanajet7のメモ ","date":1405774320,"dir":"post/2014/","id":"e3e146469ed4318eaa2ffbca3510c054","lang":"ja","lastmod":1405774320,"permalink":"https://blog.johtani.info/blog/2014/07/19/hold-on-5th-elasticsearch-jp/","publishdate":"2014-07-19T21:52:00+09:00","summary":"第5回Elasticsearch勉強会を開催しました。 遅くなってしまいましたが、まとめてみました。 今回は、Elasticsearchに入って","tags":["elasticsearch","勉強会"],"title":"第5回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"ということで、転職しました。 どーしてもやりたいことが出てきたので、無理を言って転職することにしてみました。\nサムライズムではなく、Elasticsearchにジョインします。（というか、しました。）\n初出社 #サムライズム\n\u0026mdash; Jun Ohtani (@johtani) 2014, 7月 1 冗談でツイートしたのですが、その前に英語アカウントのツイートがRTされてしまっていまいちでした。。。\nスキポール空港 先週、アムステルダムに行っていたのも退職前に休みをいただき、Elasticsearchの全社会議に参加していたためです。 とてもエキサイティングな経験（英語漬けとか）ができ、もっと精進しないとなという気持ちにもなり、ますます頑張らないとなと。\nということで、今後は日本中にElasticsearchやLogstash、Kibanaを広めるべく、いろいろな場所で話をしたいと思います。 興味のある方は、声をかけていただければと。\nあと、東京でElasticsearchのCoreトレーニングが行われます。 通常は2日間ですが、通訳の方が付く関係で3日間の開催となっています。 開発者2名がトレーナーとして来日します。開発者に質問をできる良い機会ですので、興味のある方は参加してみてはいかがでしょうか。 また、CTOのShay Banonも来日する予定です。\nトレーナー2名とShayは7/14の勉強会でも話をしてくれます。 こちらも興味のある方は参加してみてください。（参加登録はこの後、すぐに開始します。）\nまだまだ、勉強しなければいけないことだらけですが、ElasticsearchのいろいろなプロダクトやOSSについて広めていきたいと思いますので、よろしくお願いいたします。\nおまけ ということで、一度やってみたかったのでリンクを貼ってみます。\nほしい物リストはこちら\n","date":1404181800,"dir":"post/2014/","id":"21a8e6324e9330d4f8ebade604c62b6e","lang":"ja","lastmod":1404181800,"permalink":"https://blog.johtani.info/blog/2014/07/01/join-elasticsearch/","publishdate":"2014-07-01T11:30:00+09:00","summary":"ということで、転職しました。 どーしてもやりたいことが出てきたので、無理を言って転職することにしてみました。 サムライズムではなく、Elasti","tags":["転職"],"title":"転職しました"},{"contents":"退職しました。\n色々と書きたいんですが、時差ボケで頭痛いので、このくらいです。 余裕出たら書くかも。\nほしい物リストはこちら\n新天地についてはまた明日。\n","date":1404137940,"dir":"post/2014/","id":"40abea0a87a64bd832a1fad69458b293","lang":"ja","lastmod":1404137940,"permalink":"https://blog.johtani.info/blog/2014/06/30/resignation/","publishdate":"2014-06-30T23:19:00+09:00","summary":"退職しました。 色々と書きたいんですが、時差ボケで頭痛いので、このくらいです。 余裕出たら書くかも。 ほしい物リストはこちら 新天地についてはまた明","tags":["転職"],"title":"退職しました"},{"contents":"Elasticsearch server 2nd editionが発売されています。\n私が翻訳したのは前のバージョンですが。。。 まずは、目次を元にどのくらい変わってるかを見てみました。 （全部まだ読んでなくて。。。）\n1章 Getting Started with the Elasticsearch Cluster 冒頭に、全文検索とは、転置インデックスとはどんなものか、 Luceneの簡単なアーキテクチャの仕組みについて説明が追加されています。 検索の仕組みを知らない人が読んでもわかりやすくなっています。\nインストール方法なども少し追記されています。 バージョニングと簡単なデータ登録と検索方法についてもここで触れられています。 検索結果の構造の説明もちょっとあります。 まず簡単に触ってみるというところまでが1章でまとめられた感じです。\n2章 Indexing Your Data 新しく、切りだされた形です。 前のバージョンでは1章で説明されていた、Mapping周りが切りだされています。 シャードやレプリカの説明もこちらです。\nIPアドレスタイプ（IPv4のみ）とtoken_countタイプの説明も追加されてます。 similarityやpostingsフォーマットなどは新しく追記されています。 また、メタフィールドと呼ばれる_typeなどはこちらに移動しているようです。 マージ処理などの説明も追記されています。このあたりは、Mastering ElasticSearchに 記載されているものが移植された感じでしょうか。\n3章 Searching Your Data 前のバージョンでは2章だった章です。 クエリについては1.0で追加されたsimple_query_stringなどが追記されています。 constant_scoreやdismaxなどもです。\nまた、前のバージョンの3章で説明されていたハイライトや8章で触れられていたvalidate APIについても 移動しています。\n4章 Extending Your Index Structure 前のバージョンの3章で触れられていた、データの構造に関する部分がこの章になります。 親子や配列、ネスト等のデータのインデックスや検索の方法です。\n5章 Make Your Search Better スクリプティングや言語判定などの仕組みが記載されています。 また、ブーストについても同様です。Synonymについてもここです。 スパンクエリについては省略されたのかな？\n6章 Beyond Full-text Searching 1.0の目玉機能の一つであるAggregationの説明から始まります。 その後、ファセットやPercolatorについてです。メモリに関する注意点もありそうです。 また、Geoについての説明がこちらに移動されていました。 scroll APIについてもこちらで説明されています。\n7章 Elasticsearch Cluster in Detail 前の7章で記載されていたElasticsearchの分散の仕組み（Node Discovery）についての記載があります。 また、1.0で追加されたcircuit breakerやスレッドプール、インデックスのリフレッシュレートなど、Mastering ElasticSearchの 内容も追記されている気がします。\nインデックスやマッピングのテンプレート機能についてもここで説明があるみたいです。\n8章 Administrating Your Cluster 1.0で追加されたsnapshot/restoreの説明から始まります。 あとは、前のバージョンの7章で説明されていたクラスタ管理用のAPIについての説明です。 いくつか（例えばcat API）、1.0で追加されています。\nまた、シャードのリバランスの話も追加されているようです。 エイリアスやプラグインの話はこちらに移動してるみたいです。\n感想 ということで、とりあえず、駆け足で目次ベースで違いを見てみました。 Mastering ElasticSearchでの 知見がフィードバックされ、しかも1.0（すでに1.3が出そうな勢いですが。。。）にバージョンアップされた内容になっています。 冒頭がわかりやすくなっているので、検索をやったことのない方にもおすすめな書籍になった気がします。 英語が苦にならなければ、おすすめの一冊だと思います。\n来月から読み進めるつもりなので、また、面白い内容があったら感想を書いていこうと思います。 （また翻訳できるといいかもなー）\n","date":1402908420,"dir":"post/2014/","id":"916bda59bc7621d5c1790c040572a3c0","lang":"ja","lastmod":1402908420,"permalink":"https://blog.johtani.info/blog/2014/06/16/first-impression-elasticsearch-server-2nd-edition/","publishdate":"2014-06-16T17:47:00+09:00","summary":"Elasticsearch server 2nd editionが発売されています。 私が翻訳したのは前のバージョンですが。。。 まずは、目次を元にどのくらい変わってるかを見てみました。 （","tags":["elasticsearch","本"],"title":"Elasticsearch server 2nd editionのファーストインプレッション"},{"contents":"可視化ツール現状確認会に参加して、カジュアルウォーターじゃなくて可視化ツールの現状を確認してきました。\nということで、いつものメモです。\nMackerel と Graphite について （y_uuk1さん） Graphite 時系列 工夫すればスケーラブル SensuやCollectdと組み合わせたり GrafanaとGrapheneでGUI Mackerel素敵だよと。 架空のわかりやすいグラフが見れた Kibana \u0026amp; Grafana \u0026amp; Influga （hakoberaさん） Kibana\nかっこいい。 JVM大変。 Grafana\nGraphiteがカッコ悪いのでKibanaをフォーク なぜか、ESが必要。 InfluxDBに浮気しそう Influga\n@haoberaさん作 InfluxDB Queryサポート 迷ったら、Kibana入れとけ。\nDistinctがKibana出できないけど、それ以外はある程度行けるらしい。\naggregationがサポートされたら、できると思う。 Kibana以外は、バックエンドがタイムシリーズなので、縛りがある\n可視化ツール紹介（仮） （showyouさん） 誰がチャートを作るの？ 誰が見るの？ 一覧化されてて、あとで眺めたい IPython Notebookのデモ R shiny Serverのデモ Pentaho CE+Saikuのデモはネットワークがダメだったので割愛 分析側の視点を見せたかったので。 可視化とは何だったのか （harukasanさん） インフラ モニタリング、アナライズ、可視化どれ？ 可視化は目的ではないよねと。 熱く、ユーザとサービスプロバイダ間の距離のお話。 ログ 生ファイルで残すのが重要 トータルで必要とか考えないといけないことがわかって面白かったｗ\nあなたの知らないrrdtool （shoichimasuharaさん） すげー！ いろいろできるらしい（ノートPCの前にいなかったｗ） D3.jsとジオマッピング （Takaki_さん） 時空間推進課！すげー！ ジオデータのおはなし。 TopoJSONとかGeoJSONとか Zipkinについて （synkさん） ものすごい数のJVMがThriftで殴りあってるらしい。 ZipkinはTwitterが作ったもの Brave、HTraceというのが、PureJava用のZipkinトレーシングプラグイン 見積もりする必要がないくらいでかいHBaseがあるので、そこにためてる。 まとめ LINEはエンジニアを大募集中 Graphiteについて (mickey19821 さん) ドリコムさんのGraphiteのおはなし Metricsの収集はCollectd Graphite-webがスケールできなくて困ってるらしい。 Graphiteで可視化ツラいｗ まとめ RRDTool最高\nあと、クックパッドの技術力がすごいという発表なんかもありました。\n","date":1401884100,"dir":"post/2014/","id":"5bb6f8322cdbda7a21e4aecbe04462b7","lang":"ja","lastmod":1401884100,"permalink":"https://blog.johtani.info/blog/2014/06/04/attending-visualize-study/","publishdate":"2014-06-04T21:15:00+09:00","summary":"可視化ツール現状確認会に参加して、カジュアルウォーターじゃなくて可視化ツールの現状を確認してきました。 ということで、いつものメモです。 Mackerel と Graphite","tags":["勉強会"],"title":"可視化ツール現状確認会に参加してきました。#可視化"},{"contents":"今月2回目の目黒で、初のドリコムさんです。 「最新インフラエンジニア技術勉強～Fluentd, Elasticsearch,Chefの実践実例～」に参加してきました。 もちろん、Elasticsearchってキーワードがあったからです。\nざっくりメモです。\nドリコムのInfrastructure as Code/ひらしーさん CM：jojoss、トレクル、など サーバ300台、クラウド○○台。月30〜50台の割合で増加中。 少人数でいかに回すか。 Chef Rubyが書ける人が多いから。 serverspec テストだよと。 すみません、色々と聞き逃しました。。。\nWinning the metrics battle/mickeyさん Graphiteとかを触っている。 1300台超えたら、色々大変だった。 失敗談 Cactiを利用して、色々と運用が大変だった。DCが別なのでProxyとか。 成功例？現行システム？ 最大値、平均値、最小値などをプロット collectdを収集、送信に採用して、独自で開発？ 受信して保存するのに、Graphite（carbon-relay、carbon-cache、DRBD、graphite-web）ってなってる。 1300台程度のサーバから、5分間隔で、問題ない。 Graphite良いツールだよ。 Q：過去データはどのくらい？ A：5分間隔で1年分。\nQ：移動平均とかを使ったグラフとか時間かかりませんか？100台だと A：100台でもほとんど時間はかからない。\nFluentd プラグイン開発講座/外山 寛さん Fluentdプラグインを作ることができると威力倍増 Elasticsearchの勉強会の話までしてくれました！ 勉強会スペース貸出しています。 未公開だけど、sedueのプラグインもあるらしい。 CHUNKとBUFFERとか覚えときましょう プラグインの作り方的なのがなかった気がしたので、今回の発表です。 gem作らなくてもディレクトリにおけば使えるよと。 td-agent使ってる人が大多数だよね。（fluentdを素で使ってる人は会場にはいなかった） エンジニア募集中 Q：エラー処理どうしてますか？ A：今は、スルーしています\nQ：単体テストの書き方は？ A：人によってバラバラみたいですね。\nMySQLと組み合わせて始める全文検索エンジン「elasticsearch」/yoshi_ken スライド：http://www.slideshare.net/y-ken/introduce-elasticsearch-mysql-importer\nElasticsearch歴は1年位です。\nMySQLを使っていて、モダンな検索がほしいですよね？ね？\nサジェスト、ファセット、位置情報、ネスト検索などなど。\nGoogleトレンドだとSolrに迫る勢いと。\n実データを用いて、手軽にElasticsearchと連携。\nBinaryLogではなく、SQLの結果を同意する方式。yamabiko\n今日は、新しいものを公開します。\nbulk import file generator as well as nested document from MySQL for elasticsearch bulk api 東京トレーニング\nElasticsearch本については、右にあるリンクをクリックしてくれるとうれしいなぁ。\n","date":1400840280,"dir":"post/2014/","id":"a578acf825a595ce95fe8f804b7208f0","lang":"ja","lastmod":1400840280,"permalink":"https://blog.johtani.info/blog/2014/05/23/attending-drecom-infra-study/","publishdate":"2014-05-23T19:18:00+09:00","summary":"今月2回目の目黒で、初のドリコムさんです。 「最新インフラエンジニア技術勉強～Fluentd, Elasticsearch,Chefの実践実例～","tags":["勉強会","elasticsearch"],"title":"最新インフラエンジニア技術勉強に参加しました。"},{"contents":"どうやら、中身がSolrベース？Luceneベース？になったらしいということで、 今日は「AWSプロダクトシリーズ｜よくわかるAmazon CloudSearch」に行ってきました。\n※ElasticSearchではありません！\nということで、いつものメモ。\nCloudSearch Overview Amazon Web Services, Inc. Pravin Muthukumar(Product Manager) / Vivek Sriram (Business Development) Introduction to Search 検索の紹介。アイアンマンのDVD？のページにいろんな項目（フィールド）があるよねと。（もちろん、Amazonのページ） ファセット、Geo、テキスト処理（Analysis処理）、Postings listとか。とかとか ランキングも Amazon CloudSearch 独自実装orRDB拡張もある。 OSSもあるよね。 Legacy Enterprise SearchとしてFASTとかもある。 Building with CloudSearch 他のサービス同様、コンソールとかあるし、色々できるし、すぐ起動できるよと。 自動で、データが増えたら、パーティションが増えると。\n日本語の形態素解析があるらしい。何を使ってるのかな？ ICUのノーマライズとかもやってくれるらしい。これかな？http://lucene.apache.org/core/4_8_0/analyzers-icu/index.html ユーザが辞書を指定できるのかな？ 備えてる機能の説明\nファセット SimpleQuery Autocomplete Highlight などなど\nMulti-AZにも対応 QA Q：NGramありますか？ A：今はないです。 Q：ユーザ辞書対応してますか？ A：今はないです。 Q：lang-detectあるか？ A：今はないので、自分で判定して、適切なフィールドに入れてね。 Expectation for CloudSearch Apache Solr contributor　大須賀　稔氏 Solr本の宣伝ありがとうございます！（右のアイコンから買ってもらえると更に嬉しいですｗ） Kinesisとかとの組み合わせとか、自然言語処理とか、いろいろとあるAWSのコンポーネントと組み合わせる例が欲しいと。 すばらしい、最後はManifoldCFがらみに持っていくとは。ACLがらみのクローリングとかあるといいじゃないでしょうかと。 Impression of using CloudSearch 吉田　匠氏　(@yoshi0309　http://blog.yoslab.com/) スライド：https://speakerdeck.com/yoshi0309/impression-of-using-cloudsearch\nお見かけしたことある気がするなぁ。 全部置き換えできる！わけではなさそう。。。 いいところ。 UIがいいし、セットアップが簡単 auto scaleがうれしい マルチドメイン、マルチスキーマがいい Luceneのdismaxサポートがいい。（edismaxじゃないのかな？） dismaxって書いてあるな。\nhttp://docs.aws.amazon.com/cloudsearch/latest/developerguide/search-api.html\nフィードの仕方に気をつけて！\nバッチサイズで課金されるので、1件ずつじゃなくて、複数件送ったほうがいい。 いきなりスケールアウトできるわけじゃない？\nウォームアップ機能がない。インスタンス上限がデフォルト50件\nVPC対応してほしい。\nインターネット経由になってしまう フィードのスピードが セキュリティグループ機能が使えない CloudSearch UseCase - SnapDish Vuzz Inc.　清田　史和氏 独自辞書をもって、Tokenizeは独自でやって、空白区切りでデータ登録している。 インデックス更新はSQSを使ってる。 古いAPIを使ってるらしい。 移行が結構大変らしい。 感想 使ったことないんですが、きめ細かい検索したい場合はちょっとテクニックが要るかもと思いました。 AWS初心者なんで、なんとも言えないんですが。。。\nといあえず、テキスト処理（アナライズ処理）で、単語がどうやって区切られるのかってのがわからないのはキツイんじゃなかろうかと。 ただ、簡単に起動できて、オートスケールできるのは素晴らしいと思います。\n","date":1400143800,"dir":"post/2014/","id":"706c033b4483b6d062b66d6e4ea0236a","lang":"ja","lastmod":1400143800,"permalink":"https://blog.johtani.info/blog/2014/05/15/amazon-cloud-seaarch-study-session/","publishdate":"2014-05-15T17:50:00+09:00","summary":"どうやら、中身がSolrベース？Luceneベース？になったらしいということで、 今日は「AWSプロダクトシリーズ｜よくわかるAmazon Cl","tags":["勉強会","CloudSearch","AWS"],"title":"「よくわかるAmazon #CloudSearch 」に行ってきました！"},{"contents":"酔っ払ってなんとなく書きたくなったスピリチュアルなブログなので、流していただければと。\n最近、勉強会やTwitterで知り合いになって話をする人が増えたりで、 その方たちに色々と教えてもらうことが多いなぁと感じてます。 また、知り合いに恵まれてきたなぁとも。\nそもそも私が勉強会に参加し始めたきっかけはSolr勉強会（第1回から参加してて、気づいたら主催者になってた）で、 そのころは、Solr初心者で色々とやってる人、知ってる人がいて無料で話が聞けるのすごいと興奮したのを覚えてます。 （もちろん、ぼっちでしたが）\nSolr勉強会が定期的に開かれて、それに参加しているうちに少しずつ知り合いもできて、 面白そうな勉強会（Hadoopとか）が他にもあるんだ、参加してみようかって思うようになってと。\nそこにプラスで、関口さんと知りあえてSolr本を書く話が出てきて、本を書いてみたら、 今度は勉強会で話してみませんかとなって。\nスピーカーやると、顔を覚えてもらえるようで、また知り合いが増えてと。\n人のつながりって大事だし、自分が発信することで教えてもらえることもあるしと。 前にも書いた気がするけど、Solr勉強会（当時の主催の方）や関口さんやElasticsearch勉強会のスタッフの方や スピーカーやってくれた方、会場提供を心よくしてくれてるVOYAGE GROUP、リクルートテクノロジーズさん、という具合にどんどん頭が上がらなくなってきてるなぁと。\nということで、外の世界を知ると色々とつながりが出来て面白いですよという、個人的な感想でした。 ま、自分が思ってるだけで、違う意見もいっぱいあると思うけど。\nあー、なんか、酔って勢いで書いてしまった。。。 脈略のない文章なきがするけど、エイヤで公開しちゃおう。\n","date":1399999440,"dir":"post/2014/","id":"72df0bf7853e05560d94208817b83468","lang":"ja","lastmod":1399999440,"permalink":"https://blog.johtani.info/blog/2014/05/14/spiritual-entry1/","publishdate":"2014-05-14T01:44:00+09:00","summary":"酔っ払ってなんとなく書きたくなったスピリチュアルなブログなので、流していただければと。 最近、勉強会やTwitterで知り合いになって話をする","tags":["スピリチュアル"],"title":"外の世界を知るということ"},{"contents":"「アジャイルデータサイエンス」の見本をいただいてしまいました。\nなので、感想文でも書いてみようかと。\nどんな本？ 想像以上に薄かったです、物理的に。 なのに、とても幅広い範囲をカバーしています。\nデータの分析にどんな人が関わっているのか、アジャイルにデータを分析する目的から始まり、 データから何かを見つけるための手順、考え方などをさらっとですが、 システムに取り込む流れから取り込んだあとに改良するという流れまで紹介してくれます。 流れはこんな感じ。\nイベント：ログとかのイベントの発生 コレクタ：イベントの収集 バルクストレージ：イベントの一時保存 バッチ処理：ストレージにあるデータに対して処理 分散ストア：処理結果をWebアプリなどで表示するために保存 Webアプリ：処理結果をユーザに提供 Webアプリでデータを見えるようにして、そこから更にフィードバックを受けることで、データの分析などを進めていくという流れです。\n私はデータサイエンス系の人ではないのでこの流れで作業をされているかはわからないのですが、 検索のシステムについてもこの流れに似ているなと感じました。\n検索システムでも、検索したいデータを収集して、加工（検索したい項目の洗い出しやファセットにする項目の選定とか）して、 インデックスを生成するといった処理が必要になるからです。\nこの本では、Python、Hadoop（Pig）、MongoDB、ElasticSearch（バージョンが0.90だから）、d3.jsなどが出てきます。 また、日本語版の付録では、Fluentd、Kibana+Elasticsearchといった組み合わせの紹介もあります。\nコードも書かれていますが、すみません、そこまでちゃんと読んでません。。。\n後半では、データを活用して行くためには順序があるという話が書かれています。\nレコード：レコード1件のアトミックな処理と表示 グラフ：レコードを元に集計したりグラフ作ったり レポート：関係性やトレンドを抽出し、インタラクティブに探求 予測：構造を利用して、推論やレコメンドとか 行動：上記の結果を元にユーザに行動を促す 前のステップがおろそかだと次のステップがうまくいかないという話です。 後半はこの流れに沿って、先ほどのシステムの流れを変更していく方法が展開されます。\n注意点 ちょっとだけ気になる点があったので。\nElasticsearch周りについては少し注意が必要かと。（Pigとかは詳しくないので不明です。） 紹介されているElasticsearchのバージョンが0.90と少し古いのと、 Hadoopとの統合（Pigで処理したデータをElasticsearchに出力）に利用されているWondordogというツールも最近更新がされていないみたいです。 おそらく、1.0系では動かないのではないかと。\n1.0系の場合は、Elasticsearchが提供しているelasticsearch-hadoopを利用するのが良いと思います。\n付録については1.0系で記載されているので問題ないかと。ただし、Elasticsearchは更新が早いので、公式サイトで最新情報を入手するのが良いと思います。\n感想 データを解析するシステムってどんなことやってるの？という全体像を 俯瞰するのに良い本なのではないかと思います。 また、データの解析を活かすために、必要な順序と疎かにできない点もあって面白かったです。\n紹介されているツール類については、OSSのトレンドや開発速度が早いので、参考程度にとどめておいて、 自分たちで使いやすいものを探してきて検討するのがいいと思います。\n付録がとても豪華です。FluentdやKibanaがわかりやすく解説されてます。\nあと、薄いのでさらっと読めます。ｗ\n","date":1399563900,"dir":"post/2014/","id":"91fe03f994e8e85cede4e3bd62f4d6b7","lang":"ja","lastmod":1399563900,"permalink":"https://blog.johtani.info/blog/2014/05/09/reading-agile-data-science/","publishdate":"2014-05-09T00:45:00+09:00","summary":"「アジャイルデータサイエンス」の見本をいただいてしまいました。 なので、感想文でも書いてみようかと。 どんな本？ 想像以上に薄かったです、物理的に","tags":["感想文","オライリー"],"title":"アジャイルデータサイエンスが届きました"},{"contents":"こんなツイートを見つけたので、Aggregationのサンプルでも書こうかなと。（前から書こうと思ってたんですが。。。）\n@elasticsearch Hi, Would you please tell me the way to do \u0026quot;Pivot Faceting\u0026quot; like Solr-4.0 in elasticsearch-1.1.1 or prior version? Thank you.\n\u0026mdash; Y.Kentaro (@yoshi_ken) 2014, 5月 2 ちなみに、Aggregationは1.0.0から導入された機能なので、ElasticSearch Server日本語版には掲載されていない機能になります。（ごめんなさい）\n公式ガイドのAggregationsのページはこちらになりますが、実例があったほうがいいかなと。\n@yoshi_ken さんから実例のサンプルの指定もいただいたので、ブログを書くのが非常に楽です。ありがとうございます。\n問題 元ネタ（gist）\n次のような不動産系のデータがあるとします。\nid 物件名 都道府県（東京、神奈川、\u0026hellip;..） 物件種別（賃貸、売買、\u0026hellip;..） この時、都道府県別に、物件種別ごとの件数を取得したいという趣旨です。\n東京 賃貸: xxx件 売買: yyy件 神奈川 賃貸: xxx件 売買: yyy件 \u0026hellip; これを、Elasticsearchでどうやって取得するかという問題です。\nインデックスとデータの登録 まずは、インデックスを作ります。 あくまでもサンプルなので、全部not_analyzedにしてますが、そのへんは適宜変更してください。\n# create index PUT /pref_aggs { \u0026#34;settings\u0026#34;: { \u0026#34;number_of_shards\u0026#34;: 2 }, \u0026#34;mappings\u0026#34;: { \u0026#34;japan\u0026#34; : { \u0026#34;_id\u0026#34; : { \u0026#34;path\u0026#34; : \u0026#34;id\u0026#34; }, \u0026#34;properties\u0026#34;: { \u0026#34;id\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;}, \u0026#34;name\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;}, \u0026#34;pref\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;}, \u0026#34;type\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;index\u0026#34;: \u0026#34;not_analyzed\u0026#34;} } } } } _idを使用して、データ登録時にidフィールドにある文字列をそのままIDとして登録できるように指定してあります。\n登録するデータは次のようなものを適当に100件程度作ってりました。\n{\u0026#34;id\u0026#34;: \u0026#34;id0\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name0\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;01_北海道\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;売買\u0026#34;} {\u0026#34;id\u0026#34;: \u0026#34;id1\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name1\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;09_栃木県\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;売買\u0026#34;} {\u0026#34;id\u0026#34;: \u0026#34;id2\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name2\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;38_愛媛県\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;賃貸\u0026#34;} {\u0026#34;id\u0026#34;: \u0026#34;id3\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name3\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;40_福岡県\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;賃貸\u0026#34;} {\u0026#34;id\u0026#34;: \u0026#34;id4\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name4\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;35_山口県\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;売買\u0026#34;} {\u0026#34;id\u0026#34;: \u0026#34;id5\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name5\u0026#34;, \u0026#34;pref\u0026#34;: \u0026#34;12_千葉県\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;賃貸\u0026#34;} ... データの登録には、前に紹介した方法「stream2esと複数データの登録」を用いました。\nファセット このようなデータがある場合に、まず思いつくのはファセットによる取得です。 いささか強引ですが。。。\nGET /pref_aggs/japan/_search { \u0026#34;size\u0026#34;: 0, \u0026#34;query\u0026#34;: { \u0026#34;match_all\u0026#34;: {} }, \u0026#34;facets\u0026#34;: { \u0026#34;type_賃貸\u0026#34;: { \u0026#34;terms\u0026#34;: { \u0026#34;order\u0026#34;: \u0026#34;term\u0026#34;, \u0026#34;field\u0026#34;: \u0026#34;pref\u0026#34;, \u0026#34;size\u0026#34;: 50 }, \u0026#34;facet_filter\u0026#34;: {\u0026#34;term\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;賃貸\u0026#34; }} }, \u0026#34;type_売買\u0026#34;: { \u0026#34;terms\u0026#34;: { \u0026#34;order\u0026#34;: \u0026#34;term\u0026#34;, \u0026#34;field\u0026#34;: \u0026#34;pref\u0026#34;, \u0026#34;size\u0026#34;: 50 }, \u0026#34;facet_filter\u0026#34;: {\u0026#34;term\u0026#34;: {\u0026#34;type\u0026#34;: \u0026#34;売買\u0026#34; }} } } } facet_filterを使用して、typeフィールドによる個別の絞込を行っています。 あとは、prefフィールドのファセットを取得すれば、出力は次のようになります。\n{ \u0026#34;took\u0026#34;: 6, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 2, \u0026#34;successful\u0026#34;: 2, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 100, \u0026#34;max_score\u0026#34;: 0, \u0026#34;hits\u0026#34;: [] }, \u0026#34;facets\u0026#34;: { \u0026#34;type_賃貸\u0026#34;: { \u0026#34;_type\u0026#34;: \u0026#34;terms\u0026#34;, \u0026#34;missing\u0026#34;: 0, \u0026#34;total\u0026#34;: 52, \u0026#34;other\u0026#34;: 0, \u0026#34;terms\u0026#34;: [ { \u0026#34;term\u0026#34;: \u0026#34;00_北海道\u0026#34;, \u0026#34;count\u0026#34;: 1 }, { \u0026#34;term\u0026#34;: \u0026#34;01_青森県\u0026#34;, \u0026#34;count\u0026#34;: 2 }, { \u0026#34;term\u0026#34;: \u0026#34;03_宮城県\u0026#34;, \u0026#34;count\u0026#34;: 3 }, ... }, \u0026#34;type_売買\u0026#34;: { \u0026#34;_type\u0026#34;: \u0026#34;terms\u0026#34;, \u0026#34;missing\u0026#34;: 0, \u0026#34;total\u0026#34;: 48, \u0026#34;other\u0026#34;: 0, \u0026#34;terms\u0026#34;: [ { \u0026#34;term\u0026#34;: \u0026#34;00_北海道\u0026#34;, \u0026#34;count\u0026#34;: 2 }, { \u0026#34;term\u0026#34;: \u0026#34;02_岩手県\u0026#34;, \u0026#34;count\u0026#34;: 1 }, { \u0026#34;term\u0026#34;: \u0026#34;04_秋田県\u0026#34;, \u0026#34;count\u0026#34;: 1 }, ... } 望んでいた形式とは少し異なりますが、facet_filterする回数を少なくするため、 ファセットは都道府県のフィールドを指定したためです。 アプリで頑張って入れ替えてください。。。\nこの場合、\u0026rsquo;type\u0026rsquo;の個数がわかっているので、頑張ってこのような記述ができました。 ただ、typeが増えた時にアプリの修正とかが必要になりますよね。\nAggregations ということで、Aggregationsの出番です。 ファセットよりも柔軟に、検索結果に対していろいろな集計が行える機能になります。 一見に如かずということで、クエリを紹介します。\nGET /pref_aggs/japan/_search { \u0026#34;size\u0026#34;: 0, \u0026#34;query\u0026#34;: { \u0026#34;match_all\u0026#34;: {} }, \u0026#34;aggs\u0026#34;: { \u0026#34;pref\u0026#34;: { \u0026#34;terms\u0026#34;: { \u0026#34;order\u0026#34;: { \u0026#34;_term\u0026#34;: \u0026#34;asc\u0026#34; }, \u0026#34;field\u0026#34;: \u0026#34;pref\u0026#34;, \u0026#34;size\u0026#34;: 50 }, \u0026#34;aggs\u0026#34;: { \u0026#34;type\u0026#34;: { \u0026#34;terms\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;type\u0026#34;, \u0026#34;size\u0026#34;: 10 } } } } } } ファセットよりもシンプルですし、賃貸といったような値を指定していません。 aggsというのがaggregations機能を指定している部分になります。 検索結果は次のように出力されます。\n{ \u0026#34;took\u0026#34;: 4, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 2, \u0026#34;successful\u0026#34;: 2, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 100, \u0026#34;max_score\u0026#34;: 0, \u0026#34;hits\u0026#34;: [] }, \u0026#34;aggregations\u0026#34;: { \u0026#34;pref\u0026#34;: { \u0026#34;buckets\u0026#34;: [ { \u0026#34;key\u0026#34;: \u0026#34;00_北海道\u0026#34;, \u0026#34;doc_count\u0026#34;: 3, \u0026#34;type\u0026#34;: { \u0026#34;buckets\u0026#34;: [ { \u0026#34;key\u0026#34;: \u0026#34;売買\u0026#34;, \u0026#34;doc_count\u0026#34;: 2 }, { \u0026#34;key\u0026#34;: \u0026#34;賃貸\u0026#34;, \u0026#34;doc_count\u0026#34;: 1 } ] } }, { \u0026#34;key\u0026#34;: \u0026#34;01_青森県\u0026#34;, \u0026#34;doc_count\u0026#34;: 2, \u0026#34;type\u0026#34;: { \u0026#34;buckets\u0026#34;: [ { \u0026#34;key\u0026#34;: \u0026#34;賃貸\u0026#34;, \u0026#34;doc_count\u0026#34;: 2 } ] } }, ... Aggregationsの結果は、望んでいた通りの出力になっています。\nクエリの構成を見てみましょう。\n\u0026#34;aggs\u0026#34;: { \u0026#34;pref\u0026#34;: { #1 \u0026#34;terms\u0026#34;: { \u0026#34;order\u0026#34;: { \u0026#34;_term\u0026#34;: \u0026#34;asc\u0026#34; }, \u0026#34;field\u0026#34;: \u0026#34;pref\u0026#34;, \u0026#34;size\u0026#34;: 50 }, \u0026#34;aggs\u0026#34;: { #2 \u0026#34;type\u0026#34;: { \u0026#34;terms\u0026#34;: { \u0026#34;field\u0026#34;: \u0026#34;type\u0026#34;, \u0026#34;size\u0026#34;: 10 } } } } } 最初の#1のprefは出力を扱いやすくするためにつけているラベルになります。好きな名前をつけることが可能です。 次のtermsがAggregationのタイプ（どのような集計をして欲しいか）になります。 今回は、prefフィールドにある単語(term)毎に、集計をしたいので、termsを指定します。 その他にどんなタイプがあるかは、公式ガイドをご覧ください。\n次に、さらにtypeフィールドで集計したいので、#2の部分で後続のAggregationを指定しています。 都道府県同様、typeフィールドにある単語毎に集計するために、termsを指定します。\nこれで、先ほどのような結果が出力できます。 ちなみに、さらにtypeの中に他の種別で集計したいという場合は、さらにaggsを追加していけばOKです。\nAggregationは非常に柔軟な集計を可能にする機能です。ただし、検索結果に対して集計処理を行っているため、 メモリやCPUなどのリソースを消費するので注意が必要です。\nAggregationの説明については、こちらのFound.noのブログ（英語）がわかりやすかったので参考にしてみてください。\nまとめ 非常に簡単ですが、Aggregationsについて紹介しました。 その他にもAggregationsでできることがあるので、後日別のサンプルを用意して説明しようかと思います。\n100件のデータやここまでの操作については、gistにあるので、興味がある方はご覧いただければと。 stream2esの操作以外は、Marvelに付属のsenseを利用しています。\n","date":1399456620,"dir":"post/2014/","id":"ed4f5a398056eef1cf6caa90786b340a","lang":"ja","lastmod":1399456620,"permalink":"https://blog.johtani.info/blog/2014/05/07/aggregation-example/","publishdate":"2014-05-07T18:57:00+09:00","summary":"こんなツイートを見つけたので、Aggregationのサンプルでも書こうかなと。（前から書こうと思ってたんですが。。。） @elasticsearch Hi, Would you please tell me the way to","tags":["elasticsearch"],"title":"Aggregations - ファセットよりも柔軟な集計"},{"contents":"今日はelasticsearch-kopfのAnalysis画面の紹介です。\n（簡単なところから。。。その３）\nちょっとあいだが開いてしまいましたが、再開です。 メニューのaliasesを選択すると、次のような画面が表示されます。\nAliases画面 Elasticsearchのaliasを画面で確認できます。\nエイリアスは、インデックスに別名をつけることができるElasticsearchの機能です。 １エイリアス＝１インデックスでも良いですが、１エイリアスに対して複数のエイリアスを付与することもできます。 この機能を利用することで、次のようなことが可能となります。\nインデックスの切り替えをアプリ側に意識させずに実施（アプリはエイリアス名に対して検索すればOKなので） 直近１週間のログを検索するためのエイリアスの作成（複数のインデックスを１つのエイリアスに割り当て可能） 特定のルーティングによる検索（特定のデータに対する検索だけに絞るためにfilterを指定する） エイリアスについて詳しく知りたい方は公式ガイドをご覧いただくのが良いかと。\n画面は非常にわかりやすい作りになっているので、特に説明必要ないんですよね。。。\n","date":1399132860,"dir":"post/2014/","id":"2824bef72110575c78aeb979170212b8","lang":"ja","lastmod":1399132860,"permalink":"https://blog.johtani.info/blog/2014/05/04/intro-elasticsearch-kopf-alias-percolator/","publishdate":"2014-05-04T01:01:00+09:00","summary":"今日はelasticsearch-kopfのAnalysis画面の紹介です。 （簡単なところから。。。その３） ちょっとあいだが開いてしまいまし","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（aliases画面）"},{"contents":"kopfの記事の続きも書く必要があるんだけど、こんなツイートを見つけてしまったので。。。\nElasticsearchのBulk APIの仕様、JSONファイルをいい感じに加工して置かなければならないしハマりどころ多い。 http://t.co/hmfycqZlqk\n\u0026mdash; Kenta Suzuki (@suzu_v) 2014, 4月 24 前に思いついたけど、放ったらかしにしてた疑問が再浮上してきたので、せっかくだから調べてみようかなと。\n複数JSONデータがある場合にもっと楽にデータを入れる方法ないかなぁと思って、これかな？というのがあったのですが、 そのまま手を動かさずに放置してたので、一念発起してブログ書いてます。\nBulk APIって？ ElasticsearchはURLにアクセスしてデータを登録できます。 基本的には次のように1件毎の登録になります。\n$ curl -XPUT http://localhost:9200/bookshop/books/1 -d \u0026#39; { \u0026#34;book_id\u0026#34; : 1, \u0026#34;title\u0026#34; : \u0026#34;ElasticSearch Server Japanese Edition\u0026#34;, \u0026#34;price\u0026#34; : 3024, \u0026#34;publisher\u0026#34; : \u0026#34;KADOKAWA\u0026#34; }\u0026#39; これでもいいのですが、大量のデータを登録するときは、Elasticsearch側での効率が悪いです。 そこで、Elasticsearchは大量データを登録するためにBulk APIというものを用意しています。\nこれは、次のような形式のJSONを作ってデータを登録します。\n{ \u0026#34;index\u0026#34; : { \u0026#34;_index\u0026#34; : \u0026#34;bookshop\u0026#34;, \u0026#34;_type\u0026#34; : \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34; : \u0026#34;1\u0026#34; } } { \u0026#34;book_id\u0026#34; : 1, \u0026#34;title\u0026#34; : \u0026#34;ElasticSearch Server Japanese Edition\u0026#34;, \u0026#34;price\u0026#34; : 3024, \u0026#34;publisher\u0026#34; : \u0026#34;KADOKAWA\u0026#34;} { \u0026#34;index\u0026#34; : { \u0026#34;_index\u0026#34; : \u0026#34;bookshop\u0026#34;, \u0026#34;_type\u0026#34; : \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34; : \u0026#34;2\u0026#34; } } { \u0026#34;book_id\u0026#34; : 2, \u0026#34;title\u0026#34; : \u0026#34;Introduction of Apache Solr\u0026#34;, \u0026#34;price\u0026#34; : 3888, \u0026#34;publisher\u0026#34; : \u0026#34;gihyo\u0026#34;} これは、次のような構成になっています。\nコマンド データ コマンド データ ... これで効率よくデータが登録できるのですが、このようなJSONデータを別途作って上げる必要が出てきます。 結局、複数のJSONがあるのに、特殊なJSONを生成しないといけないということでプログラム書いて実行することになります。 これだと、Elasticsearchへのアクセスをプログラムで書くのとあまり大差がないかもしれません。\nstream2es もっとお手軽に複数のJSONを登録できないかな？と目をつけていたのが、stream2esです。\nどんなもの？ Clojureで作られた、Elasticsearchにデータを流し込むためのツールです。 Java 7がインストールされていれば、ダウンロードしてくれば動作せることができます。\nインストール 公式ページに載っている方法そのままです。\n$ curl -O download.elasticsearch.org/stream2es/stream2es; chmod +x stream2es 実行したディレクトリにコマンドがコピーされます。 あとは、コマンドを実行すればOKです。\n実行 データは次のような形式でsample.jsonに保存してあるとします。\n{ \u0026#34;book_id\u0026#34; : 1, \u0026#34;title\u0026#34; : \u0026#34;ElasticSearch Server Japanese Edition\u0026#34;, \u0026#34;price\u0026#34; : 3024, \u0026#34;publisher\u0026#34; : \u0026#34;KADOKAWA\u0026#34;} { \u0026#34;book_id\u0026#34; : 2, \u0026#34;title\u0026#34; : \u0026#34;Introduction of Apache Solr\u0026#34;, \u0026#34;price\u0026#34; : 3888, \u0026#34;publisher\u0026#34; : \u0026#34;gihyo\u0026#34;} 先ほどのBulk APIで利用したJSONよりも、スッキリしていますね。 1行1ドキュメント1JSONです。\nあとは、次のコマンドを実行するだけです。\n$ ./stream2es stdin --target http://localhost:9200/bookshop/books \u0026lt; sample.json ファイルをstream2esに流し込んで、stream2esが1行ずつパースして、Elasticsearchに投げ込んでくれます。\n登録されたデータは次のようになります。 IDは自動で付与されています。\n{ \u0026#34;_index\u0026#34;: \u0026#34;bookstore\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;0Hvy4IJCRkKrvGb4Dgam_w\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;book_id\u0026#34;: 1, \u0026#34;title\u0026#34;: \u0026#34;ElasticSearch Server Japanese Edition\u0026#34;, \u0026#34;price\u0026#34;: 3024, \u0026#34;publisher\u0026#34;: \u0026#34;KADOKAWA\u0026#34; } }, { \u0026#34;_index\u0026#34;: \u0026#34;bookstore\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;b9M6TooFQzGYyJeix_t_WA\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;book_id\u0026#34;: 2, \u0026#34;title\u0026#34;: \u0026#34;Introduction of Apache Solr\u0026#34;, \u0026#34;price\u0026#34;: 3888, \u0026#34;publisher\u0026#34;: \u0026#34;gihyo\u0026#34; } } せっかく、book_idがあるんだし、_idをインデックスの設定に指定します。\n$ curl -XDELETE http://localhost:9200/bookshop $ curl -XPUT http://localhost:9200/bookshop -d \u0026#39; { \u0026#34;mappings\u0026#34;: { \u0026#34;books\u0026#34; : { \u0026#34;_id\u0026#34; : { \u0026#34;path\u0026#34;: \u0026#34;book_id\u0026#34; } } } }\u0026#39; あとは、登録すればbook_idが_idに採用されます。\n{ \u0026#34;_index\u0026#34;: \u0026#34;bookshop\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;book_id\u0026#34;: 1, \u0026#34;title\u0026#34;: \u0026#34;ElasticSearch Server Japanese Edition\u0026#34;, \u0026#34;price\u0026#34;: 3024, \u0026#34;publisher\u0026#34;: \u0026#34;KADOKAWA\u0026#34; } }, { \u0026#34;_index\u0026#34;: \u0026#34;bookshop\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;_version\u0026#34;: 1, \u0026#34;found\u0026#34;: true, \u0026#34;_source\u0026#34;: { \u0026#34;book_id\u0026#34;: 2, \u0026#34;title\u0026#34;: \u0026#34;Introduction of Apache Solr\u0026#34;, \u0026#34;price\u0026#34;: 3888, \u0026#34;publisher\u0026#34;: \u0026#34;gihyo\u0026#34; } } 複数ファイル ディレクトリに複数のJSONファイルが有った場合は、次のようなコマンドでOK\n$ cat sample_data/*.json |./stream2es stdin --target http://localhost:9200/bookshop/books まぁ、catして流してるだけですが。。。\nダメだったケース JSONが複数行になっているようなデータだとエラーが出てしまいました。\n（jqコマンドで1行に整形したりできるかなぁ？）\nまた、1行に2つのJSONが書いてある場合は、1つ目のJSONをパースしたら、そこでおしまいみたいで、その後に記述されたデータは登録されませんでした。\nインデックスがない場合 stream2esで登録するインデックスがElasticsearchに存在しない場合、stream2esがインデックスを作成してくれるのですが、 この時、シャード数などはstream2es内部に記述があるので注意が必要です。 以下がその設定です。\nindex.number_of_shards : 2 index.number_of_replicas : 0 index.refresh_interval : 5s 課題？ 内部的にはおそらく、Bulkでデータを登録していると思うのですが、まだよくわかっていません。 Clojureが読めないので、せっかくだから、Clojureの勉強も兼ねてちょっとソースを読んでみようかなと思います。 それほど量があるわけでもないので。\nあとは、その他にWikipediaのデータやTwitterのデータ登録、 ElasticsearchからデータをScrollで読み出しつつ、別のElasticsearchに流しこむといったこともできそうなので、そちらも試してみようかと。 他にもオプションがいくつかありそうです。\n今回は2件ほどでしたが、大量データを流し込んだ時にどうなるか（stream2esが悲鳴を上げるのか、Elasticsearchで詰まることがあったらどうなるか）なども 気になるので、なんか適当なデータで試してみるのもいいかなぁと。 （ということで、だれか、いろいろ試してみてもらえると楽できるなぁ。）\n","date":1398341460,"dir":"post/2014/","id":"e396cbf9274b590a1d94ee43d823a0bd","lang":"ja","lastmod":1398341460,"permalink":"https://blog.johtani.info/blog/2014/04/24/usage-stream2es/","publishdate":"2014-04-24T21:11:00+09:00","summary":"kopfの記事の続きも書く必要があるんだけど、こんなツイートを見つけてしまったので。。。 ElasticsearchのBulk APIの仕様、J","tags":["elasticsearch","stream2es"],"title":"stream2esと複数データの登録"},{"contents":"第4回Elsticsearch勉強会を開催しました。 今回から、遅刻厳禁にしてみました。 それほど困った人もいないと思うので、次回からも遅刻厳禁で。\nということで、今回も多数の方にお集まりいただきありがとうございました。\nスタッフの皆さん、スピーカーの皆さん、プレゼント用に書籍を用意してくれたKADOKAWAさん、開場提供していただいたリクルートテクノロジーズさん、ありがとうございました！ 次回もよろしくお願いします！ 参加していただき盛り上げていただいた参加者の皆さんもありがとうございました。\nさて、ブログですが司会業とかやってたので、あんまり書けてないけど。。。\n134番までチケットがはけていたので＋スタッフで140〜150名くらいの参加者だったのではないかと思います。 懇親会まで残っていただいた方々も片付けなどありがとうございました。\nさて、感想とか補足です。\n「アナライズ処理の仕組みとクエリDSL」株式会社シーマーク　大谷　純　@johtani スライド：アナライズ処理の仕組みとクエリDSL※スライドはPDFです。\nプラグイン：elasticsearch-extended-analyze\nプラグインの紹介記事：http://blog.johtani.info/blog/2013/10/25/developing-es-extended-analyze-plugin/\nMarvel：http://www.elasticsearch.com/marvel/\n日本語版メーリングリスト：https://groups.google.com/forum/#!forum/elasticsearch-jp\nなんか、宣伝（本＋プラグイン）ばっかりですみません。 「プラグインの紹介記事」に簡単な使い方が書いてあります。が、情報が古いので、Elasticsearchのバージョンに合わせたバージョンを使ってください。\nまだまだ発表に慣れてないので、頑張ろ。\nアンケート取ってみましたが、ログ検索と全文検索と半々くらいで興味がある人がいるみたいでした。 あと、有料トレーニングは人気ないっすね。。。\n「elasticsearch-hadoopを使ってごにょごにょしてみる」 株式会社マーズフラッグ R\u0026amp;D部　やまかつ さん　@yamakatu スライド：elasticsearch-hadoopを使ってごにょごにょしてみる\nelasticsearch-hadoop：https://github.com/elasticsearch/elasticsearch-hadoop\nQAとして、Elasticsearchにプライマリデータを保存するのは的な話が出てました。 ESにのみデータを入れるのは個人的には考えたことないかなぁ。 どうしても、ElasticsearchのWriteが遅いんじゃないかという懸念事項を持ってる人がいるなぁと。（実際ツラいという話もちらほら）\nお腹痛い中の発表ありがとうございました。。。 次回はMapRの方に紹介してもらえそう（交渉中）なので楽しみです。やまかつさんの続きも聞きたいなぁ。\n「CouchbaseとElasticsearchが手を結んだら」株式会社アットウェア 佐竹雅央さん @madgaoh 河村康爾さん @ijokarumawak スライド：CouchbaseとElasticsearchが手を結んだら\nCouchbaseのElasticsearchに関するページ：http://docs.couchbase.com/couchbase-elastic-search/\nCouchbaseに入れたら、自動的にElasticsearchにもデータを入れてくれる。 デモがあるの、いいっすね。\n最新版はmasterを落としてきてビルドしないとダメらしい。確かに、上のページには0.90.5って書かれてる。 ここでも、やはり、Elasticsearchが詰まった時にどうするの？みたいな話が出てました。 CouchbaseのXDCRだと、後ろが詰まってる時によしなに？データを流すのを制御してくれるってのがあるみたいですが、 Elasticsearchだと悲鳴を上げているのがわかりにくいと。\nあと、Elasticsearchがインデキシングでキューを取りこぼしているのがログからわかりにくいってのも出てました。 （なにか、分かる方法があるかとかも調べてみようかなぁ。）\n自分の宿題：Transportプラグインって何かについて調べてブログに書くこと。\n「Elasticsearch at Wantedly」（タイトルあってるか不安）　Wantedly, Inc 内田誠悟さん @spesnova スライド：Elasticsearch at Wantedly\n参考文献：Elasticsearchチュートリアル\n参考文献：Elasticsearch Workshop\n参考文献：elasticsearch-rails\nWantedlyでどうやって使ってるのか。 あと、オートコンプリートでも使ってます。（この話は次回聞けるといいなぁｗ）\nデータ数は少ないので、参考にまだならないかも。\n公式のサイト見難いですよねと。 ペンギン先生のブログが素晴らしかった！ マッピングすごいｗ\n最後は、苦労して作ってもらったautocompleteの資料は放ったらかしにして、質疑応答してもらいました。 辞書とか、検索漏れとかの話は今後の課題っぽかったですね。\n「Elasticsearchのみに決めてました！」ってセリフがカッコ良かったｗ\nアクセスコントロール周りのノウハウもブログで共有してくれそうなので楽しみにしています！\nあと、「tireがretire」の話が出てましたが（この発表だっけ？）参考文献にあげてある、elasticsearch-railsが今は本流なんじゃないかなぁ？\nLT ###「ElasticsearchのScripting」株式会社富士通ソフトウェアテクノロジーズ 滝田聖己さん @pisatoshi\nスライド：ElasticsearchのScripting\n参考文献：elasticsearch-native-script-example\n色々とScriptがあるという話を説明してもらい感謝です。 もちろん、ElasticSearchServerにも書いてあるので、そちらも参考にしてください！\n「Elasticsearch 向け多言語解析プラグイン」ベイシス・テクノロジー株式会社 江口天さん スライド：Elasticsearch 向け多言語解析プラグイン\n参考文献：Elasticsearchで使えるRosette基本言語解析モジュール\n参考文献：Elasticsearch-inquisitorプラグインの紹介\nベイシステクノロジさんが提供しているRosetteをElasticsearchで活用できるモジュールみたいです。 いまなら、無料で体験できるみたいなので、どんなものか触ってみると面白いかもしれません。\nあと、デモで使用されていたプラグインについて、私が昔に書いた記事があるので、興味のある方は参考にしていただければと。 このプラグインはクエリがどのように内部でLuceneのクエリになっているか、どのフィールドでどうトークンが生成されるか？ といったものが見ることができるプラグインになっています。\n関連ブログ 適当に見つけたブログを列挙してあります。これもあるよ！などあれば、教えてください。\n勉強会メモ - 第4回elasticsearch勉強会 2014/04/21\ntogetter 第4回elasticsearch勉強会 #elasticsearchjp\n参加レポート:第4回elasticsearch勉強会 #elasticsearchjp\n第4回elasticsearch勉強会に参加しました\nまとめ しつこいくらい宣伝してしまいましたが、「ElasticSearch Server日本語版」よろしくお願いします！\n今回も楽しい話が聞けました。メモがちょっと少ないんですが。。。\n次回は6末を目処に、MapRの方などと調整して開催しようと思います。 聞きたい話とか、発表したい方とかあれば、連絡くださいー！\n","date":1398077040,"dir":"post/2014/","id":"50562b09417cd8c4a2348a0a5aabe754","lang":"ja","lastmod":1398077040,"permalink":"https://blog.johtani.info/blog/2014/04/21/hold-on-4th-elasticsearch-jp/","publishdate":"2014-04-21T19:44:00+09:00","summary":"第4回Elsticsearch勉強会を開催しました。 今回から、遅刻厳禁にしてみました。 それほど困った人もいないと思うので、次回からも遅刻厳禁","tags":["elasticsearch","勉強会"],"title":"第4回Elasticsearch勉強会を開催しました。#elasticsearchjp"},{"contents":"今日はelasticsearch-kopfのAnalysis画面の紹介です。\n（簡単なところから。。。その２）\nメニューのanalysisを選択すると、次のような画面が表示されます。\nAnalysis画面 Elasticsearchの_analyze APIを画面で確認できます。 画面で動作の確認ができるのは嬉しいですよね。\n入力文字列：入力となるドキュメントに含まれる文字列や検索キーワードを入力 フィールドの指定：対象とするインデックス名、タイプ名、フィールド名を選択 analyze：ボタンを押す トークナイズされた結果：入力文字列がどのようなトークンに分割されるか start、end：入力文字列中の文字列の位置 pos：トークンの位置 という形でElasticsearchが指定されたフィールドで入力文字をどのようにトークナイズしたかを確認することができます。\nElasticsearchは内部でこのトークナイズされた単語を元に転置インデックスを作成し、検索に利用します。 ですので、特定のデータが検索に上手くヒットしないときに、この画面でデータの文字列をトークナイズしてみるといった用途に使えます。\nフィールドの設定がどのようにして入力文字列をトークンにしているかといった点については、今度のElasticsearch勉強会で話す予定です。\nフィールドの設定を利用する以外に、アナライザを指定してどのようにトークナイズされるかを見ることもできます。 「ANALYZE BYANALYZER」をクリックすると利用できます。\nANALYZE BY ANALYZER トークナイズしたい文字列を入力し、インデックス名と、インデックスに設定されているアナライザ名を選択してanalyzeボタンを押すと 結果が表示されます。 （例では、kuromojiアナライザを利用して出力になっています。また、出力結果のposの表示位置がFIELD TYPEの時と違うのが少し気になりました。）\nただ、残念ながら、インデックスのマッピングで指定したアナライザしか利用できないみたいなので、 どのアナライザがどんな挙動かを調べたい場合は、以前紹介したelasticsearch-inquisitorを 利用したほうが良さそうです。\nということで、今日はanalysis画面の説明でした。\n","date":1397011260,"dir":"post/2014/","id":"76a1fb7f21fda9eddb95426b65124517","lang":"ja","lastmod":1397011260,"permalink":"https://blog.johtani.info/blog/2014/04/09/intro-elasticsearch-kopf-analysis/","publishdate":"2014-04-09T11:41:00+09:00","summary":"今日はelasticsearch-kopfのAnalysis画面の紹介です。 （簡単なところから。。。その２） メニューのanalysisを選択","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（analysis画面）"},{"contents":"JVM Operation Casual Talksに参加しました。 あんまり、運用とかやってないので、ついていけるか不安ですが、楽しそうだったので。 懇親会は予定されてないらしい。\n@stanaka\t15分でわかるJVMのメモリ管理 スライド：https://speakerdeck.com/stanaka/understanding-memory-management-of-javavm-in-15-minutes\nJVMの基礎知識\n某研究所で。。。\nElasticsearch、Solrの名前が！\nJVM困りどころ。ネットの情報が古いのが多いとか。\n使いこなすにはきちんと知識が必要。\nMemory Model 困ったらJava8に。。。\nHeapのチューニングが重要\nHeapの構成やGC処理の説明\nCMSでもすべて並列ではない\nOlgGenがフラグメントして確保が遅くなっていく G1GCの概念図。YoungやOld、Survivorの区別がない？\nリージョン？ リファレンスリストすばらしい。\n@oranie\tCassandra運用で実施しているJVM監視について スライド：http://www.slideshare.net/oranie/jvm-operation-casual-talks-33218856\nCassandra(1.1)で運用中。 35TBとか エンジニアブログ読め。 Cassandraの監視って何すればいいの？ GC頻度とかグラフで見れる VisualVM便利って教えてもらった。 VisualVMでどんな値があるか見ながら調べて、取りたい値を考える。 SNMPで頑張るの辛い＝JMXかな？＝Javaで叩くの？＝Jolokia どんなことやってる？ Nagios+Jenkins＋。。。あとでスライド yohoushi+GrowthForecastも便利。 @waysaku\tSpray(Akka)運用でJVMをCPUスケールさせるために行った事 スライド：http://www.slideshare.net/waysaku/jvm-operation-casual-talks\nSpray Akkaアプリケーションの運用を任されちゃった人 カットオーバー直前の負荷試験でびっくりするくらいスループットでない。。。 いろんなActorが特定のActorに処理を投げた状態で待ってるという状況。。。 スレッドダンプ追っかけてる様子を追体験してる。 ログ出力がBLOCKしてた I/Oを伴う処理は非常にセンシティブ 以下、LT @oinume\t運用に効く！JVMオプション三選 スライド：http://www.slideshare.net/oinume/jvm-operationcasualtalks20140407\nサーバに入らなくても見れるのは VisualVM 最終形Java Mission Control Flight Recorder（商用だと有償） @y_uuki1\tなにもわからないところから始めるJVMモニタリング スライド：https://speakerdeck.com/yuukit/nanimowakaranaitokorokarashi-merujvmmonitaringu\nブログ：http://yuuki.hatenablog.com/entry/2014/04/08/074507\nなんでここにいるかわかりませんが。 色んな所記事とかのリンクがある。 Graphiteに放り込んでるらしい。 @tagomoris\tNorikraのJVMチューンで苦労している話 スライド：http://www.slideshare.net/tagomoris/norikrajvm\nNorikraで困ったので開催したらみんなしゃべりに来てくれてありがたい世の中ですね。 デフォルト設定で運用。mx4096mで4ヶ月は元気に動いてた 年末に崩壊 -\u0026gt; harukaさんのQiita見ながら設定してほったからした。 3月にまた崩壊OOM SoftRefが悪さしてるのか？ nekopさんのブログにヒントが。 @shot6\tJVM的なナニカを話す、GC戦略をそえて スライド：http://www.slideshare.net/shot6/jvm-33248312\n某A社からきました。 CMSを中心が良い CPUコア少ないとCMS Incremental G1GCは6GB以上とかもっと大きい場合のほうが良さそう（雑感） 基本的に、ドキュメントに書いてあるけど、つらいので、まとめてみました。 後で見たいな、このスライドも。 @kazeburo\tWebアプリケーションとメモリ スライド：http://www.slideshare.net/kazeburo/jvm-casual\nJavaは1行も書いたことありません。 Java運用したけど、まぁ、ひどい目にあってます。 ということで、PerlとApacheの話？ bumpyなんとかってのは頭良くプロセスの処理回数とかをなんとかしてくれる JVMとかどうなの？ ということで、CA社の人が釣れたので良かったですね。 TBD\tJVMの運用について話す会(パネル) なんでJVM？\n全文検索だとJVMだなぁ。SolrとかElasticsearchとか 入社したらあった。 JVMこまったところは？\n突然Dioが出てくる JVMいいところは？\nうーん、あえて言うと。。。スレッド処理 型がある言語を調べるとJVM。というよりScala。 飛び入り参加。落ちないところ。人殺しは良くないｗ 簡単には殺せないところに使えるのは良いのでは。 チューンはどこまでやる？\n7,8割でやめたほうが良い？ そんなに突き詰めなくてもいいのかな。 Cassandraだと、FullGCが走ってる時点で再起動しかない場合が多いです。 言語のランタイムについてチューンすることってJVMの他ある？\nRubyくらい？ 自分たちで何とかできないものを相手にしている人たちは苦労してるんじゃないか\nCaなんとかさんとかHBなんとかさんは困ってる人が多い 最後に一言\nモニタリングツール参考にしたい 最後に 「やりたくなったら誰かやってください。」ということみたいです。\n基礎から監視まで結構幅広くキーワードが出てきたので楽しかったです。\nその他に話に出てきてた方のブログもリンクしとこうかな。\nnekopの日記\n","date":1396866240,"dir":"post/2014/","id":"299abcee56b05b312ed5700f686f79b8","lang":"ja","lastmod":1396866240,"permalink":"https://blog.johtani.info/blog/2014/04/07/attend-jvm-casual-1/","publishdate":"2014-04-07T19:24:00+09:00","summary":"JVM Operation Casual Talksに参加しました。 あんまり、運用とかやってないので、ついていけるか不安ですが、楽しそうだったので。 懇親会は予定されてないらしい","tags":["JVM","Java","勉強会"],"title":"JVM Operation Casual Talksに参加しました #jvmcasual"},{"contents":"今日はelasticsearch-kopfのREST画面の紹介です。\n（簡単なところから。。。）\nメニューのrestを選択すると、次のような画面が表示されます。\nElasticsearch自体が、さまざまな操作をRESTでできる仕組みになっています。 検索にも利用しますが、それ以外の設定などにつてもリクエストを送ればOKです。\nですので、リクエストや設定を自分で組み立てて送ることができる画面が用意されているととても便利です。 （もちろん、curlコマンドでもいいのですが、画面があると便利ですよね）\nREST画面 History 履歴表示画面です。 これまで、kopfのrest画面を利用して送信したリクエストが一覧で表示されます。\nHistoryという文字をクリックすることで、表示/非表示の切り替えが可能です。（最初は非表示） マウスオーバーすると、リクエストボディがポップアップで表示されます。\nHistory 履歴にあるURLはクリック可能で、クリックすると実行されます。 履歴はlocalStorageに保存されるみたいです。（ブラウザの仕様？あんまり詳しくないので。。。） たぶん、30件が上限かと（ソースで確認しただけ）\nURL rest画面でリクエストを送信する先のURLを指定します。 メソッドは右側のSELECTで選択可能です。\nリクエストパラメータも指定が可能です。\nリクエストボディ 検索や設定のJSONを記述するところです。 一応、JSON的にエラーがある場合は行数の左側にバツ印が出てきておかしなところもわかるようになっています。\nインデントなどは行ってくれますが、senseみたいな補完などはないので、少し辛いところです。\nレスポンス 送信したリクエストに対するレスポンスが返ってきます。 インデントされた状態で表示されるので読みやすいかと。 また、入れ子になっているJSONについては、閉じたり開いたりすることも可能です。 （開始のカッコの右側に-が表示されていて、クリックすると閉じることができます。閉じると+に変わります）\n簡単ですが、rest画面の説明でした。 KOPFを使っていて、ちょっとしたクエリを送ったりするのには便利だと思います。\n複雑な検索クエリなどについては、やはりsenseを使うのが良いかと思いますが。。。\n","date":1396837440,"dir":"post/2014/","id":"670744b945088de05866864f7d57bee7","lang":"ja","lastmod":1396837440,"permalink":"https://blog.johtani.info/blog/2014/04/07/intro-elasticsearch-kopf-rest/","publishdate":"2014-04-07T11:24:00+09:00","summary":"今日はelasticsearch-kopfのREST画面の紹介です。 （簡単なところから。。。） メニューのrestを選択すると、次のような画面","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（rest画面）"},{"contents":"なんだか、ドタバタしてて久しぶりの更新です。 ベルリンの旅行記みたいなのも書きたいのですが、まずはこちらかと。\nelasticsearch-kopfプラグインの紹介です。\n今回は概要の説明だけになります。機能が結構多いので。\nelasticsearch-kopfとは？ _siteプラグインの一つで、クラスタ管理用のプラグインになります。 headプラグインやHQプラグインと同様です。\nプラグインの画面 このようにシンプルな画面で、スッキリとしています。 緑を基調にした画面構成はElasticsearchの緑色を意識してるんでしょうか？\n上記の画像に簡単なコメントを入れてあります。\nメニュー KOPF：KOPF自体の設定（接続先とリフレッシュインターバルの変更） cluster：クラスタ管理、情報（デフォルト表示画面） rest：RESTリクエスト送信、結果表示画面 aliases：エイリアス管理 analysis：analysis API percolator：パーコレータ管理 warmup：ウォームアップクエリ管理 上記のようなメニューです。各メニューについては、今後のブログで少しずつ紹介しようかと。 このメニューの色が、クラスタの状態も表しています。ステータスがYELLOWなら黄色、REDなら赤色に変わります。\nインデックス インデックスは列として表示されます。先ほどの画像では、2つのインデックスが表示されている状態です。 インデックス毎に、シャードも表示されます。これは、各ノードがどのシャードを保持しているかという情報です。 色の濃いシャードがプライマリでしょう。 インデックス名やシャードの箱はクリックできるようになっていて、それぞれの情報がJSONで表示されます。 その他にもドキュメント数、サイズなども表示されます。 インデックスの各種操作（closeやdeleteなど）もここからメニューが表示されます。（これも次回詳しく）\nノード ノードの情報が行として表示されます。ノードが増えると下に追加されていきます。 node1というのが、ノード名です。（ヒーローの名前とかが出てくるやつです。）\nその他に、IPアドレス、ポート番号、負荷、ヒープサイズなども表示されています。 電源ボタンはノードのシャットダウンを行うためのボタンです。（確認用のダイアログが表示される）\nその他 その他に、クラスタの概要として、ノード数、インデックス数、シャード数、ドキュメント数なども表示されます。 インデックスの作成などは、アイコンから操作が可能です。 大規模なクラスタを管理している場合、検索ボックスを利用することで、インデックス名やノード名による絞込もできるようになっています。\n感想 シンプルな構成の画面で、個人的にはheadよりも好きな画面です。 HQよりもシャードの分散具合がわかりやすいので、今後はこのプラグインを利用していこうと考えています。\nまずは、簡単な紹介です。今後、各画面についてもう少し説明をブログに書いていこうかと考えています。 待てない方は、触ってみてもらうのが良いかと。 もちろん、続きを書いてもらってもいいですよ！！\n","date":1396707480,"dir":"post/2014/","id":"c1241374502f200cf9fc49c8d6fb5822","lang":"ja","lastmod":1396707480,"permalink":"https://blog.johtani.info/blog/2014/04/05/intro-elasticsearch-kopf-1/","publishdate":"2014-04-05T23:18:00+09:00","summary":"なんだか、ドタバタしてて久しぶりの更新です。 ベルリンの旅行記みたいなのも書きたいのですが、まずはこちらかと。 elasticsearch-ko","tags":["elasticsearch","plugin"],"title":"elasticsearch-kopfの紹介（概要）"},{"contents":"先日、「ElasticSearch Serverを翻訳しました」という記事を書きました。\nこの中で電子版も出ますよと書いていましたが、電子版も発売されたので、再告知も兼ねてブログを書いています。\nなお、最近よく「ElasticsearchのSは小文字」とツイートしていますが、本書は原著のタイトルが「ElasticSearch Server」となっているため、Sは大文字になっています。原著が出版された時期にはまだSが小文字に統一されていなかったためです。\n紙の書籍はすでに書店に並んでいたり、Amazonでも発送されているようです。\n私自身が電子書籍が場所を取らなくて好きというのもあり、電子版も出版していただけるようにお願いしていました。\n電子版についてはAmazonでKindle版、達人出版会からEPUBとPDFが購入可能です。\n達人出版会のElasitcSearch Serverのページ AmazonのKindle版ページ こちらのリンク（Amazonはアフィリンク）を参考にしていただければと。\n書籍の写真入りツイートしたら、原著者の方からレスを頂きました。\n@johtani Thanks for the great work out there :)\n\u0026mdash; Rafał Kuć (@kucrafal) 2014, 3月 23 また、原著者のサイトでも紹介してもらいました（結構うれしい）。 私が窓口をやっていた関係で、私の名前しか入っていませんが。。。 編集者と翻訳者の方々のお陰で良い本が出版できたと思っています。\nThanks for sharing! / ElasticSearch Server book in Japanese | ElasticSearch Server Book Blog http://t.co/fhCP1vVBd3\n\u0026mdash; Jun Ohtani (@johtani) 2014, 3月 24 ということで、Elasticsearchの導入の手助けになればと。 感想（賛否問わず）など、あればコメント、ツイート、ブログなど書いていただければうれしいです。 （その際に、連絡してもらえるとさらにうれしいです）\n","date":1395722580,"dir":"post/2014/","id":"d51032bef3e7117a94336fea18a3fad7","lang":"ja","lastmod":1395722580,"permalink":"https://blog.johtani.info/blog/2014/03/25/release-elasticsearch-server-ja-ebook/","publishdate":"2014-03-25T13:43:00+09:00","summary":"先日、「ElasticSearch Serverを翻訳しました」という記事を書きました。 この中で電子版も出ますよと書いていましたが、電子版も発","tags":["elasticsearch"],"title":"ElasticSearch Server日本語版（電子版も）が発売されました"},{"contents":"GOTO Night elasticsearchに参加しました。 初の海外の勉強会です（海外自体が初だし）。\nベルリンにあるWoogaという会社で開催された勉強会です。\nFull house at the #gotonight about @elasticsearch in the auditorium of @wooga pic.twitter.com/r2Vx2aMcEn\n\u0026mdash; GOTO Berlin (@GOTOber) 2014, 3月 18 会場はこんな感じで、とってもおしゃれです。（なんか、写ってますね、最前列にｗ） ベルリンの古い建物をリノベーションしたオフィスみたいで、そこにこういったひな壇を用意して発表するスペースにしているみたいです。\n内容としては、Elasticsearch1.0の新機能の話として、snapshot/restore、cat、aggregationなどの話題でした。簡単にどういったものかの説明です。\n一人目の発表が終わったら、ブレイクタイムとして上のフロアに用意されている軽食＋ドリンクで軽く交流の時間が用意されていました。 ベーグルなどのサンドイッチとハイネケンやクラブマテ？と呼ばれるチープなレッドブルとかが飲めました。\nちょっと食べて談笑したあとに、次はLogstashとKibanaのお話でした。Logstashってどんなもの？という話がメインで、Kibanaは簡単な紹介という感じでしょうか。最後に、ライブデモがありました。 Kibanaを使ったライブデモはインパクトがあるなというのが感想です。 フィールド名の補完をしてくれたりと便利な機能が操作をしているところでわかるので。\nYoutubeなどでも見てても思っていた感想ですが、こちらの勉強会は質問が結構出てきます。 今日参加した勉強会も質疑応答が結構されてました。\nelasticsearchの方たちと少しだけ話しをできたので、かなり興奮気味でブログを書いています（ミーハー）。\nただ、やっぱり英語のヒアリングがまだまだだなぁとも実感出来ました。 場数踏むしかないと思うので少しずつ耳にしてなれるしかないかなぁと。 はぁ、ちゃんと高校とか大学の頃に単語を覚えとくんだったと軽く後悔。\nこんなツイートもしてもらって、興奮気味です。明日早起きしないといけないので寝ないといけないのにｗ\nMeeting @johtani finally in #berlin watching @spinscale talking about #elasticsearch\n\u0026mdash; Simon Willnauer (@s1m0nw) 2014, 3月 18 ","date":1395151860,"dir":"post/2014/","id":"65453a1ae403679bd2e47398a04205ca","lang":"ja","lastmod":1395151860,"permalink":"https://blog.johtani.info/blog/2014/03/18/attend-goto-night-elasticsearch/","publishdate":"2014-03-18T23:11:00+09:00","summary":"GOTO Night elasticsearchに参加しました。 初の海外の勉強会です（海外自体が初だし）。 ベルリンにあるWoogaという会社で開催された勉強会","tags":["elasticsearch","勉強会"],"title":"GOTO Night elasticsearchに参加しました"},{"contents":"Berlinからおはようございます。\nということで、人生で初めての海外に来ています。\n人生初の海外なのに、一人で乗り換えがあるようなBerlinに来ています。 今年はチャレンジの年になりそう。初めてづくしですが、楽しみたいなと。 会社に感謝です。ESのトレーニングを受けに来たのがメインなのです。 ついでに、Berlinでの勉強会にも参加してみようかなと。\n幸いにも時差ボケはなさそうなので、色々と見て回ろうと思います。 ただ、日曜日はお店が軒並みしまってそう。。。\n","date":1394916660,"dir":"post/2014/","id":"abc5ca9856a61831fd4ed06b402875d2","lang":"ja","lastmod":1394916660,"permalink":"https://blog.johtani.info/blog/2014/03/16/post-from-berlin/","publishdate":"2014-03-16T05:51:00+09:00","summary":"Berlinからおはようございます。 ということで、人生で初めての海外に来ています。 人生初の海外なのに、一人で乗り換えがあるようなBerlin","tags":["misc","travel"],"title":"Berlinからおはようございます"},{"contents":"elasticsearchに、このへん入れるときっと幸せになれるはず・たぶん。\u0026#10;elasticsearch/elasticsearch-analysis-kuromoji/1.6.0\u0026#10;oyrusso/elasticsearch-HQ\u0026#10;mobz/elasticsearch-head\n\u0026mdash; toshi_miura (@toshi_miura) 2014, 3月 5 こんなツイートを見かけたので、普段入れてるプラグインを簡単に紹介してみようかと。\nローカルの環境に普段入れているプラグインの紹介です。 ちゃんとクラスタを管理しているというよりは、最新版の動作などを確認するための環境になります。なので、ちょっと視点が異なるかもしれませんが参考になればと。\nelasticsearch-analysis-kuromoji URL : elasticsearch-analysis-kuromoji\nKuromojiという日本語形態素解析のTokenizerなどを使えるようにするためのプラグインです。 今度、発売される「ElasticSearch Server」日本語版には付録として、利用方法を執筆しました。参考にしていただければと。 READMEにもサンプルは掲載されてるので、こちらを参考にするのもありですが。\nelasticsearch-extended-analyze URL : elasticsearch-extended-analyze\n私が開発しているプラグインです。 ElasticsearchにはanalyzeというAPIが用意されています。 文章を渡すと指定したanalyzerなどでどのような単語に区切られるかがわかるAPIです。\nただ、analyzerの内部ではchar filter、tokenizer、token filterという個別のパーツがそれぞれ入力された文字列に対して処理を実施します。 この過程がanalyze APIではわかりません。 それをわかるようにしてみたのがelasticsearch-extended-analyzeプラグインになります。\n詳細については過去の記事を見ていただければと。 画面があると便利だよなぁと思いつつ、作ってない。。。\npolyfractal/elasticsearch-inquisitor URL : elasticsearch-inquisitor\nクエリのデバッグとかに便利なプラグイン。\nこちらも詳細は過去の記事を見ていただければと。\nmobz/elasticsearch-head URL : elasticsearch-head\nクラスタ管理に便利なプラグインです。クラスタに存在するノードに対してインデックスのデータ（シャード）がどこに配置されているかなどが一目瞭然になる便利なプラグインです。 プライマリシャードやレプリカなどもわかります。 インデックスの削除もできるし、クエリを投げることもできるし、全部入りな感じのプラグインです。\n私個人は、シャードの配置を見るのに主に利用しています。クエリを投げたりインデックスを消したりするのには殆ど使っていません。\nroyrusso/elasticsearch-HQ URL : elasticsearch-HQ\nこれも管理系のプラグインです。こっちのほうが個人的にスッキリしていて好きなプラグインです。 インデックスの管理やノードの停止などはこちらを主に使用しています。 あくまでもローカルの簡易クラスタを管理する目的というのもあります。\npolyfractal/elasticsearch-segmentspy URL : elasticsearch-segmentspy\nこちらはモニタリングでしょうか。 ElasticSearch Serverで紹介されていたのが主な理由で、入れてますがあんまり見てないかも。 インデックスのSegment単位の情報が見ることが可能です。 あと、ちょっと更新されてない感じがしますね。\nelasticsearch/marvel Elasticsearch社から提供されている、モニタリングなどに使えるプラグインです。 開発環境では無償提供という感じです。 渡しの場合、モニタリング目的ではなく、senseと呼ばれるクエリの補完をしてくれるツールの目的のために使用しています。 モニタリング部分を停止する方法とかないかなぁ。\n詳細については過去の記事を参考にしていただければと。\nまとめ？ ということで、簡単にローカルに入っているプラグインの紹介でした。 他にもいっぱいあるので、おすすめがあれば、教えてもらえると助かります。\n","date":1394515380,"dir":"post/2014/","id":"386dc9d1b647a9f3965f1fbe29c7dfb9","lang":"ja","lastmod":1394515380,"permalink":"https://blog.johtani.info/blog/2014/03/11/es-plugin-installed-to-my-env/","publishdate":"2014-03-11T14:23:00+09:00","summary":"elasticsearchに、このへん入れるときっと幸せになれるはず・たぶん。\u0026#10;elasticsearch/elasticsearc","tags":["elasticsearch","plugin"],"title":"いつも入れているElasticsearchのプラグイン"},{"contents":"第3回Elasticsearch勉強会で、軽く触れていましたが、ElasticSearch Server日本語版が発売されます。 ツイートなどもちらほらとして頂いているみたいで嬉しい限りです。\n本書は、私自身、初の翻訳本となります。\nなお、ElasticSearchはAWSのサービスではなく、全文検索・解析サーバのOSSです\n内容、概要 PacktPublishingから発売されているElasticSearch Serverの日本語版となります。 以下の点が、原著とは異なる点になっています。\n0.90.xに対応（原著は0.20） Kibana、Kuromojiに関して追記 もちろん日本語 残念ながら、つい最近、Elasticsearchについては1.0がリリースされました。 1.0で追加された機能（SnapshotやRestore、Aggregatorなど）については触れていませんが、Elasticsearchの機能を網羅的にカバーした良書となっています。 どんな機能があるのか、どんなプラグインがあるのか、どういったことに使えるのかなど、幅広くまとめられた本になっていますので、 Elasticsearchに興味がある方はぜひ読んでいただければと思います。\nまた、現段階では予定ですが電子版の出版も予定されています。電子版が気になる方は、少しお待ちいただければと。\nElasticSearch？Elasticsearch？ 1.0.0がリリースされた現在は、Elasticsearch（SearchのSは小文字）が正式な名称となっています。 ただ、原著が発売された当初（2013年2月時点）では、まだSは小文字と大文字が混在した状況でした（コミットログなどを見るとわかります。） このため、日本語版でもElasticSearchという表記に統一してあります。\n翻訳に関して 初の翻訳書ということもあり、大変でした。英語に精通しているわけではないので（むしろ苦手）。。。 他の翻訳者の方々には大変助けていただきましたし、勉強になりました。 また、監修社であるリクルートテクノロジーズにも色々とサポートしていただき、感謝の限りです。 （Elasticsearch勉強会の開場提供にも協力して頂いています。）\nわかりにくい日本語となっている部分などありましたら、ご指摘いただければ今後の参考にさせていただきます。 英語やElasticsearchについて、学ぶという目的もあって、本書の翻訳を買って出たのが本音です。\n翻訳作業について Githubのリポジトリを編集の方に用意してもらい、翻訳原稿を管理、校正していきました。 Github自体をあまり触っていなかったので、作業をしながらGithubも覚えられ一石二鳥でした。 Issueやプルリクエストによる校正、チェックも便利ですね。 他の原稿を書くようなことがあれば、またこの経験を活かしていきたいなと。 （翻訳の進め方や原稿のチェックなどについてはまた後日何か書こうかと。）\n原著について 原著のサイトが用意されています。 http://elasticsearchserverbook.com/elasticsearch-server-errata/\n原著を翻訳するにあたって見つけた、誤植などを報告し、掲載して頂いています。 原著をお持ちの場合はこちらも参考にしていただければと思います。\nご購入はこちらから ということで、簡単ですが書籍の紹介（というより宣伝！？）でした。 Elasticsearchに関する何かしらの助けになる書籍であれば嬉しい限りです。\n「ElasticSearch Server日本語版」をよろしくお願いします。 （もちろん、購入は下のリンクからですよね！）\n","date":1393836900,"dir":"post/2014/","id":"9ad72c2a5157f21741bd4581a562dfc7","lang":"ja","lastmod":1393836900,"permalink":"https://blog.johtani.info/blog/2014/03/03/release-elasticsearch-server-japanese-edition/","publishdate":"2014-03-03T17:55:00+09:00","summary":"第3回Elasticsearch勉強会で、軽く触れていましたが、ElasticSearch Server日本語版が発売されます。 ツイートなども","tags":["elasticsearch"],"title":"ElasticSearch Serverを翻訳しました"},{"contents":"今年初の「突撃！隣のElasticsearch」ということで、Wantedlyさんにおじゃましました。\n※写真を自分でも撮ったのですが、画像が壊れてたので、一緒に行ったペンギン先生の写真を拝借しました。\n第3回のElasticsearch勉強会を開催中にES使ってるってツイートを見つけたので、アタックかけて遊びに行きました。 交渉に快諾いただきありがとうございました！\nWantedlyさんがどのようにElasticsearchを使用されているかはきっと、ブログを書いてくれると思うので期待しておくとして、書いてくれました！！ 「実践！Elasticsearch」 そこで、nestedでハイライトがなんかうまくいかないって話があったので、ちょっと調べてみました。 （※まだ、調査中です）\n前提条件 再現する手順はgistにあります。（Senseに貼り付ければ動作します。ただし、elasticsearch-analysis-kuromojiが必要です。）https://gist.github.com/johtani/9184287\nなお、このマッピングやデータはWantedlyさんとは全く関係ありません。\nnestedフィールド内部のデータに対して、検索しハイライトしようとするとうまく動作しないという状況です。 マッピングは以下のとおり。\n\u0026#34;books\u0026#34; : { \u0026#34;properties\u0026#34;: { \u0026#34;book\u0026#34; : { \u0026#34;type\u0026#34;: \u0026#34;nested\u0026#34;, \u0026#34;properties\u0026#34;: { \u0026#34;title\u0026#34; : { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34;, \u0026#34;store\u0026#34;: \u0026#34;no\u0026#34;}, \u0026#34;contents\u0026#34; : {\u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;analyzer\u0026#34;: \u0026#34;kuromoji\u0026#34;, \u0026#34;store\u0026#34;: \u0026#34;yes\u0026#34;} } } } } } このマッピングの特徴は以下のとおり。\n_sourceは保存される（デフォルト値） bookがnestedなオブジェクト titleはstore : no contentsはstore : yes 動作の挙動をわかりやすくするため、titleとcontentsのstore属性に違いを持たせてあります。\n問題点 nestedクエリを使って、検索した時にハイライトが返ってきません。 次のクエリを実行するとわかります。\nGET /bookstore/books/_search { \u0026#34;_source\u0026#34; : [\u0026#34;book.title\u0026#34;,\u0026#34;book.contents\u0026#34;], \u0026#34;fields\u0026#34;: [ \u0026#34;book.title\u0026#34;, \u0026#34;book.contents\u0026#34; ], \u0026#34;query\u0026#34;: { \u0026#34;nested\u0026#34;: { \u0026#34;path\u0026#34;: \u0026#34;book\u0026#34;, \u0026#34;query\u0026#34;: { \u0026#34;query_string\u0026#34; : { \u0026#34;query\u0026#34; : \u0026#34;Solr\u0026#34;, \u0026#34;fields\u0026#34; : [\u0026#34;book.title\u0026#34;, \u0026#34;book.contents\u0026#34;] } } } }, \u0026#34;highlight\u0026#34;: { \u0026#34;pre_tags\u0026#34;: [\u0026#34;\u0026lt;b\u0026gt;\u0026#34;], \u0026#34;post_tags\u0026#34;: [\u0026#34;\u0026lt;/b\u0026gt;\u0026#34;], \u0026#34;fields\u0026#34;: { \u0026#34;*\u0026#34;: {} } } } 結果はこちら。 ハイライトがありません。\n{ \u0026#34;took\u0026#34;: 3, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 5, \u0026#34;successful\u0026#34;: 5, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;max_score\u0026#34;: 0.5, \u0026#34;hits\u0026#34;: [ { \u0026#34;_index\u0026#34;: \u0026#34;bookstore\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;_score\u0026#34;: 0.5, \u0026#34;_source\u0026#34;: { \u0026#34;book\u0026#34;: { \u0026#34;title\u0026#34;: \u0026#34;Apache Solr入門\u0026#34;, \u0026#34;contents\u0026#34;: \u0026#34;Apache Solrについて日本語で書かれた唯一の書籍です。SolrはLuceneをコアにした検索サーバです。\u0026#34; } } } ] } } 次に、ハイライトが帰ってくるパターン。 nestedクエリではなく、_allを対象としたクエリを投げます。\n{ \u0026#34;_source\u0026#34; : [\u0026#34;book.title\u0026#34;,\u0026#34;book.contents\u0026#34;], \u0026#34;fields\u0026#34;: [ \u0026#34;book.title\u0026#34;, \u0026#34;book.contents\u0026#34; ], \u0026#34;query\u0026#34;: { \u0026#34;query_string\u0026#34; : { \u0026#34;query\u0026#34; : \u0026#34;Solr\u0026#34;, \u0026#34;fields\u0026#34;: [ \u0026#34;_all\u0026#34; ] } }, \u0026#34;highlight\u0026#34;: { \u0026#34;pre_tags\u0026#34;: [\u0026#34;\u0026lt;b\u0026gt;\u0026#34;], \u0026#34;post_tags\u0026#34;: [\u0026#34;\u0026lt;/b\u0026gt;\u0026#34;], \u0026#34;fields\u0026#34;: { \u0026#34;book.title\u0026#34; : {}, \u0026#34;book.contents\u0026#34;: {} } } } この場合の結果は次の通り。\n{ \u0026#34;took\u0026#34;: 2, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 5, \u0026#34;successful\u0026#34;: 5, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;max_score\u0026#34;: 0.27063292, \u0026#34;hits\u0026#34;: [ { \u0026#34;_index\u0026#34;: \u0026#34;bookstore\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;books\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;_score\u0026#34;: 0.27063292, \u0026#34;_source\u0026#34;: { \u0026#34;book\u0026#34;: { \u0026#34;title\u0026#34;: \u0026#34;Apache Solr入門\u0026#34;, \u0026#34;contents\u0026#34;: \u0026#34;Apache Solrについて日本語で書かれた唯一の書籍です。SolrはLuceneをコアにした検索サーバです。\u0026#34; } }, \u0026#34;highlight\u0026#34;: { \u0026#34;book.title\u0026#34;: [ \u0026#34;Apache \u0026lt;b\u0026gt;Solr\u0026lt;/b\u0026gt;入門\u0026#34; ] } } ] } } ハイライトが返ってきています。\n考察（原因は未特定） 残念ながら、まだ調査してません。 まずは、現象が理解できたというだけです。 問題点が実は２つありそうです。\n問題点１：nestedクエリの場合に、ハイライトされない。 nestedクエリではハイライトが動作していないようです。 想像ですが、検索に利用されたクエリで指定されているフィールドをハイライタ（ハイライトを実行するモジュール）が認識できてないのではないかと。 なぜ認識できていないのかという点を調査する必要がありそうです。\n考察（試してみたパターン） nestedではないクエリで、ハイライトが動作しているのですが、 \u0026quot;book.title\u0026quot; : {\u0026quot;require_field_match\u0026quot; : true},にした場合は、ハイライトが返ってこないです。 このオプションは、検索対象のフィールドでマッチした文字列だけがハイライトされるオプションになります。 したがって、book.titleフィールドに対する検索でSolrという文字を検索していないことになります。 _allに対するクエリであるためです。 このため、例えば、titleだけを検索対象にしたのに、contentsにSolrという文字が入っていてもハイライトされてしまうという状況が発生します。\n問題点２ store : yesのデータがハイライトできない。 GithubにIssueをあげました。https://github.com/elasticsearch/elasticsearch/issues/5245 （2014/02/25追記）\nnestedオブジェクトにあるデータのうち、store : noのものだけがハイライト結果として返ってきました。\n考察 なぜ、store : yesのデータがハイライトされないかを調べるために、fieldsパラメータをリクエストに追加してみました。\n{ \u0026#34;_source\u0026#34; : [\u0026#34;book.title\u0026#34;,\u0026#34;book.contents\u0026#34;], \u0026#34;fields\u0026#34;: [ \u0026#34;book.title\u0026#34;, \u0026#34;book.contents\u0026#34; ], ... } すると、fieldsの戻り値は次のとおりです。\n... \u0026#34;fields\u0026#34;: { \u0026#34;book.title\u0026#34;: [ \u0026#34;Apache Solr入門\u0026#34; ] }, ... このことから、store : noのデータの場合、_sourceから値を取得して返却しているというのがわかります。 ハイライトがされない原因も、fieldsで値が取れていないのも同じ原因であると思われます。 なぜなら、ハイライトは、保存された文字列を内部で取り出し利用して、ハイライトタグを埋め込むという動作をするためです。\n参考？ これらの問題点についてですが、次のIssueが関係あるかもしれません。\nReturn matching nested inner objects per hit #3022\n今後？ 残念ながら、現時点では、問題点がどんなものかというのを理解しただけとなります。 デバッグしたりソースを追っかけたりして何が問題なのかを調べて行ってみようかなぁと。\nなにか、気づいたことなどあればコメントしてもらえると助かります。\n","date":1393231920,"dir":"post/2014/","id":"f55d33371dcff207fd7d201128df2ea3","lang":"ja","lastmod":1393231920,"permalink":"https://blog.johtani.info/blog/2014/02/24/strange-behavior-of-field-in-nested-obj/","publishdate":"2014-02-24T17:52:00+09:00","summary":"今年初の「突撃！隣のElasticsearch」ということで、Wantedlyさんにおじゃましました。 ※写真を自分でも撮ったのですが、画像が","tags":["elasticsearch"],"title":"Nested Objectのフィールドの奇妙な動作"},{"contents":"今回はたまたま日本にいたElasticsearchの人をスペシャルゲストに呼べたので、大満足ですｗ 英語の通訳とかちゃんと勉強しないとなぁ。。。\nとりあえず、てきとーなメモですが、残しておきます。 参加者数は130人＋スタッフ＋リクルートテクノロジーズ社内の人。という感じでした。アンケート集計はもう少々おまちを。\nスライドがそろったら、また、更新すると思いますが、第一報という感じで公開しておきます。 懇親会にも50名も参加していただけて、非常に楽しかったです。 話ができてない方が多数いるかもしれませんが、次回以降、声をかけていただければと。 （物覚え悪いんで、あれですが。。。） 盛り上がってきてて楽しいなぁ。 スタッフの人達の練度も上がってきてるので、すごく楽ができてます。\n至らない点とかあれば、こちらにコメントしてもらったりしていただければと。\nGeohashing with Elasticsearch Florian Schilling, Elasticsearch Inc, スライド：https://speakerdeck.com/chilling/tokyo-es-study-session-iii-geohashes\n自己紹介 Geoのスタッフ Elsticsearchの概要 転置イデックスやREST APIなどの説明 マイクの調子が良くなくて申し訳なかったっす。。。 平賀さん、通訳ありがとう！ Solr本もよろしくお願いします！！\nAWSで構築するsharding 株式会社イプロス　外山　寛さん　@toyama0919 スライド：http://toyama0919.bitbucket.org/elasticsearch.html\nAWS対応の話 ルーティングが重要だよ。（宣伝ありがとうございますｗ） type指定しないとルーティングできない。（内部でtypeも使ってハッシュ値取ってたかなぁ？） 苦労話とかいくつか。 tireはre-tire\u0026hellip; 実サービスでのElasticsearch設定・使用例（仮） 株式会社じげん　多田 雅斗さん　@tady_jp スライド：https://speakerdeck.com/tadyjp/tesutoqu-dong-jian-suo-falsesusume-at-tady-jp\n検索とは的な話がわかりやすい。 全文検索のお話。ログ検索じゃないよと。 書籍ないですよねー（ふふふ） specで検索条件記述しといて、ってのいいですよね。絶対必要だと思う Mapping変更した時にテストやり直す方法とかどうしてますか？ 特にフレームワークは使ってないです。\nMySQLユーザ視点での、小さく始めるElasticsearch 株式会社リブセンス 吉田 健太郎さん @yoshi_ken スライド：http://www.slideshare.net/y-ken/introducing-elasticsearch-for-mysql-users\nやっぱりkuromoji便利だよね MySQLとかと連携したい。 river-pluginもいまいち安定しない なので、Yamabiko作ってみました。 Geo検索とKuromojiの話をしてくれました。（作者とか開発者がいるってのを狙ってたのかすごいなぁ。） Mappingとかはちゃんと指定したほうがいろいろいいですよ。 nodeJS+DynamoDB＋Elasticsearchで全社基盤を作った話 株式会社リクルートテクノロジーズ 相野谷 直樹さん @naokiainoya スライド：http://www.slideshare.net/recruitcojp/elasticsearchnodejsdynamodb-7\nちょっと変わった使い方のElasticsearchで面白いです。 Scroll/Scanについては、Solrでもない機能なので、そういう意味でもElasticsearchなのかもしれないですね。 参加していただいた方々のブログ 第3回elasticsearch勉強会 [2014/02/07(Fri.)]に参加してきました - ほわいとぼーど\nhttp://a3no.hatenablog.com/entry/2014/02/09/022405\n第 3 回 elasticsearch 勉強会に行ってきた - ようへいの日々精進\nhttp://inokara.hateblo.jp/entry/2014/02/07/233057\nhttp://www.smokeymonkey.net/2014/02/3elasticsearch.html\n第3回elasticsearch勉強会でトークしました #elasticsearchjp\nhttp://y-ken.hatenablog.com/entry/elasticsearch-meetup-vol3\n第3回elasticsearch勉強会にいってきました #elasticsearchjp\nhttp://blog.livedoor.jp/ashibuya0128/archives/52058766.html\n","date":1391787720,"dir":"post/2014/","id":"229b7fc784707b1d2c702fbeba080e86","lang":"ja","lastmod":1391787720,"permalink":"https://blog.johtani.info/blog/2014/02/08/hold-3rd-elasticsaerch-meetup-in-tokyo/","publishdate":"2014-02-08T00:42:00+09:00","summary":"今回はたまたま日本にいたElasticsearchの人をスペシャルゲストに呼べたので、大満足ですｗ 英語の通訳とかちゃんと勉強しないとなぁ。。","tags":["elasticsearch","勉強会"],"title":"第3回elasticsearch勉強会を開催しました！ #elasticsearchjp"},{"contents":"すずけんさんがVagrant+puppet使って、VM起動してElasticsearchのクラスタを組んでる記事を書いているのを見て、試してみたくなりました。 ということで、VagrantとかPuppetなに？くらいの私ですが、クラスタを起動するところまで行ったので、その時のメモを残しておきます。\n元記事とか参考 Vagrant環境にpuppet moduleを利用してさくっとelasticsearchをインストールする Vagrant環境にpuppetを利用してさくっとelasticsearchのclusterを作成する puppet-elasticsearch なんとなくの理解 VagrantやPuppetについては、何度か勉強会で話を聞いてはいたのですが、 想像していたレベルだったので良い機会でした。 今のところの認識はこんな感じです。\nVagrant VMを起動したり、VM周りの設定をあれこれできるツール。 VMのネットワーク設定や、インスタンス名？などを指定できる。\nPuppet 起動後のVM（VMとは限らないか。）のゲストOS側の設定周りやアプリのインストールなどを 実行できるツール。\n詰まった箇所 すずけんさんのブログを元に作業をしましたが、自分がVagrantやPuppetに疎いため、以下の部分で躓いたので、備忘録のために残しておきました。\nその１：Puppetのファイルの場所 search01.vm.localのVMを設定（というか、elasticsearchのインストール？）するときに、manifests/search.appとroles/search/manifests/init.ppファイルが必要で作成します。\nこのファイルの配置場所は/vagrant配下に作成する必要がありました。 ssh search01.vm.localでVMにログインした場合は/home/vagrantにログインしており、この場所でファイルを作ってもPuppetがエラーを吐いたためです。\nと思ったのですが、あれ？これひょっとしてVagrantfileがあるところにディレクトリとファイル作ると勝手にVMにコピーしてくれるんですか？destroyして、upしたら、ファイルが勝手にコピーされてる。ひょっとして、/vagrantってディレクトリはVagrantfileがあるディレクトリを共有してたりするのかな？そのうち、Vagrantについても調べてみようかな。\nその２：ネットワーク周り curl http://192.168.10.114:9200/ をホストOSから実行してみましたがうまく行きませんでした。。。 ネットワーク周りの設定だと思うんですが。 少なくとも「sshによるログイン」「ping」コマンドの応答は返ってきてます。\nまた、VM内でcurlコマンドを実行したらレスポンスが返ってきました。\nなんで？ってツイートしたら各所から「iptables」という単語が飛んできて、 service止めたら大正解でした。まぁ、そうですよね。基本ですよね。。。\nということで、Puppetがよくわかっていませんが、ググって変更してみました。\nmanifests/search.appに以下を追加\ninclude iptables roles/iptables/manifests/init.pp\nclass iptables { service { \u0026#39;iptables\u0026#39;: enable =\u0026gt; false, ensure =\u0026gt; stopped, } } iptablesを停止するmanifests？です（良くないことなんですが、よくわかってない）。\nということで、ローカルで1個のVM起動して、elasticsearchにアクセスできることは確認できました。\nと、書いてるそばから、元記事が修正されてしまいましたｗ\nクラスタ編（変更点） クラスタを組むときに、追加でプラグインを入れたのでroles/search/manifests/init.ppは次のようにしました。\nclass search { class { \u0026#39;elasticsearch\u0026#39;: package_url =\u0026gt; \u0026#39;https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-1.0.0.RC2.noarch.rpm\u0026#39;, java_install =\u0026gt; true, config =\u0026gt; { \u0026#39;cluster\u0026#39; =\u0026gt; { \u0026#39;name\u0026#39; =\u0026gt; \u0026#39;test-es-cluster\u0026#39; }, \u0026#39;network.host\u0026#39; =\u0026gt; \u0026#39;_eth1:ipv4_\u0026#39;,, \u0026#39;marvel.agent.exporter.es.hosts\u0026#39; =\u0026gt; [\u0026#39;192.168.10.114:9200\u0026#39;,\u0026#39;192.168.10.115:9200\u0026#39;] } } elasticsearch::plugin{\u0026#39;elasticsearch/marvel/latest\u0026#39;: module_dir =\u0026gt; \u0026#39;marvel\u0026#39; } elasticsearch::plugin{\u0026#39;mobz/elasticsearch-head\u0026#39;: module_dir =\u0026gt; \u0026#39;head\u0026#39; } elasticsearch::plugin{\u0026#39;royrusso/elasticsearch-HQ\u0026#39;: module_dir =\u0026gt; \u0026#39;HQ\u0026#39; } elasticsearch::plugin{\u0026#39;elasticsearch/elasticsearch-analysis-kuromoji/2.0.0.RC1\u0026#39;: module_dir =\u0026gt; \u0026#39;analysis-kuromoji\u0026#39; } elasticsearch::plugin{\u0026#39;info.johtani/elasticsearch-extended-analyze/1.0.0.RC1\u0026#39;: module_dir =\u0026gt; \u0026#39;extended-analyze\u0026#39; } elasticsearch::plugin{\u0026#39;polyfractal/elasticsearch-inquisitor\u0026#39;: module_dir =\u0026gt; \u0026#39;inquisitor\u0026#39; } } とりあえず、今日はクラスタ組んでMarvelやプラグインの動作確認でおしまいです。\n疑問点 いくつか疑問点が。試してみてもないんでなんとも言えませんが。気が向いたら、調べて追記するかも。\n:private_networkはVirtualBox内で完結する（Macから外には影響しない）ネットワークが構築される？たぶん、VagrantというよりはVM、仮想化周りの知識なんだろうけど どこから再開可能？elasticsearch.ymlの設定を書き換えた場合に、最後のコマンドだけ実行するとちゃんとやりなしてくれたりするのかな？ VMのディスク増やすのもVagrantでできるんかな？まぁ、できると思うけど。 :forwarded_portのauto_correctとかわかってない。 JVMをSunのJVMでかつ、7u25に変更したいのだがどうしたものか？(現時点での推奨バージョン) 感想 Vagrantって便利ですね。あれ？って思ったら、destroyして、やり直すのがすごく簡単です。 元記事があるので、なんとなくですが、構成とかどうすればいいかがわかるのは本当に助かりました。 これで、あれこれと検証する環境が簡単に構築できることがわかったので、色々と楽できるかも。ありがとうございます、すずけんさん！\n","date":1391695740,"dir":"post/2014/","id":"c98cbc333fb7d95c6c9fc4924b0526e1","lang":"ja","lastmod":1391695740,"permalink":"https://blog.johtani.info/blog/2014/02/06/es-cluster-start-using-vagrant-and-puppet/","publishdate":"2014-02-06T23:09:00+09:00","summary":"すずけんさんがVagrant+puppet使って、VM起動してElasticsearchのクラスタを組んでる記事を書いているのを見て、試して","tags":["elasticsearch","vagrant","puppet","marvel"],"title":"すずけんさんのメモを元にVagrantでElasticsearchクラスタを起動してみた"},{"contents":"改訂新版Solr入門出版記念ということで、第13回Solr勉強会 #SolrJP 新Solr本出版記念を開催しました。\n出版記念なので、技術評論社様より、プレゼント用にSolr本を用意していただきました！ありがとうございます！！ 書籍をゲット出来た方は、ツイートしたりブログ書いたり書評書いたりして、宣伝してください！！！\n今回は、私は手を抜いて他の人に喋ってもらいました！\n今回は、著者陣（関口さんは特別ゲスト）でスピーカーを固めてみました。 以下は、いつもの簡単なメモです。 スライドが集まったらまた更新していきます。\n1. 「はじめての検索エンジン＆Solr」 株式会社NTTデータCCS　鈴木 教嗣さん スライド：はじめての検索エンジン＆Solr 第13回Solr勉強会\n鈴木さんの発表初めて聞きましたｗ。 趣味が多いなぁ。 ちょこちょこと、宣伝を入れてるのが流石ですｗ\n入門らしい概要 クエリの概要とかも。 スコア計算とか 導入するとうれしいところとか Solr盛り上げましょう！ 2. 「Solr SearchComponent 再訪」 株式会社ロンウイット　関口 宏司さん スライド：公開待ち\nベン図で検索の評価指標の説明 理論的なお話 Solrのサーチコンポーネントを使って何ができるか。ベン図で。 サーチコンポーネント以外にも NGramTokenizerも SynonymFilterも パーソナライズ検索 いきなり話をふられたのでちょっとびっくりしましたｗ\n3. 「自動補完(Autocomplete)ともしかして？(Did You Mean?)」 株式会社 ロンウイット　大須賀 稔さん スライド：Solr AutoComplete and Did You Mean?\nデモ：https://github.com/mosuka/solr-suggester-demo-ui\n職歴が相変わらずおもしろい 編集距離のお話 素晴らしいCM！ 候補のランキングを変更できる？ SpellcheckComponentのパラメータで指定できるものなら楽ですが。。。\n4. 「Lucene Revolution 2013 Dublin振り返り」 楽天株式会社　平賀 一昭さん スライド：公開待ち\nダブリンどこ？（間違ってベルリンって言っちゃいましたｗ） スタジアムで開催。グランドにも入れるのかなぁ？ まずはTwitter Luceneの改良版 ちょっと特殊。１４０文字とか 青いRさんのライバル。Careerbuilder 元FASTユーザ 企業向けに検索キーワードとかの解析画面を用意 検索精度の改良の話とか 転職で引っ越す意思があるかとか。 最後はLinkedIn Luceneのユーザ まとめ ということで、スピーカーの方々のスライドにもありましたが、 改訂新版Apache Solr入門は良い本なので、購入していただけると嬉しいです。\n感想、コメントなど、いつでもお待ちしています！\n","date":1390988760,"dir":"post/2014/","id":"c6107ff57e96a1373c019d252c00ad84","lang":"ja","lastmod":1390988760,"permalink":"https://blog.johtani.info/blog/2014/01/29/hold-to-japan-solr-meetup/","publishdate":"2014-01-29T18:46:00+09:00","summary":"改訂新版Solr入門出版記念ということで、第13回Solr勉強会 #SolrJP 新Solr本出版記念を開催しました。 出版記念なので、技術評論社様より、プレ","tags":["Solr","勉強会"],"title":"第13回Solr勉強会を開催しました"},{"contents":"昨晩、Elasticsearchから初のプロダクトとなるMarvelがリリースされました。ということで、さっそく触ってみて、簡単な紹介と感想を書いてみました。\nMarvelって？ Elasticsearch社が初のプロダクトとしてリリースした、Elasticsearchクラスタモニタリングツールです。 次のような特徴があります。\nplugin形式で提供 GUIがKibana メトリックスはElasticsearchに保存 SenseがChrome以外でも使える プロダクション環境で利用する場合は有料ですが、開発用途では無料で利用できます。 現時点(2014/01/29)では、0.90.9以上のバージョン(1.0.0.RC1含む)で利用が可能です。\nなにができるの？ Elasticsearchクラスタに関するメトリックスを保存、可視化できるプロダクトです。 ドキュメント数やJVMの状況、クラスタの状態など、いろいろなメトリックスが保存されます。\n保存先は、別のElasticsearchクラスタにすることも可能です。 お試しでインストールして見る場合は、同一クラスタにサービスに利用するインデックスとMarvel用のメトリックス保存先インデックスを入れても良いです。\nただ、プロダクション環境では、Marvel用インデックスはあくまでもモニタリングに使用するため、サービスのクラスタへの影響を最小にしたくなります。\nこのような場合、Marvelのプラグインの設定を変更することで、メトリックス送信用のエージェントとして動作させることができます。\n詳しくは、Marvelのドキュメントにあるinstalling a secondary monitoring clusterを御覧ください。\n1/29 16時時点で、上記ドキュメントのエージェントの送信先の設定に関する部分に誤記がありました。 おそらく、configuration optionsの記述が正だと思います。 もう、なおってました。(1/30朝時点)\nキャプチャいろいろ 日本語WikipediaのデータをRiverで登録しながら各画面の動作などを見てみました。\nMarvel Overview 日本語WikipediaをRiverで登録してる途中。Loadが高くなってることなどがわかります。\nOverview (クラスタの状態が変化) クラスタの状態が変化したところに、タグが付くみたいです。 ここでは、ノードの一つを停止、起動しました。\nインデックス終了後に、クラスタを再起動してしまい、クラスタ内のシャードの再配置が実行されてしまったため、クラスタの状態がYellowになってしまうとこんな感じ。ちょっとわかりにくいです。\nSense Chromeプラグインとしてリリースされていたクエリ実行コンソールがMarvelのサイトプラグインとして提供されています。これがあるだけで、Elasticsearchへのクエリの実行が格段に効率良くなります。\nIndex Statistics インデックスに関する情報のグラフが見れるページです。ドキュメント数の他に、容量やリクエスト数なども見れます。\nインデックス終了後のグラフはこんな感じ。\nインデックス終了後のOverviewはこんなかんじです。\nCluster Pulse クラスタで発生したイベントとイベントの詳細を見ることができるページです。各種インデックスがYELLOWからGREENに変わっていっているのがmessageで分かります。\nすべて再配置が終わったらGREENになりました。\nNode Statistics 各ノードに関する情報を見ることができる画面です。 ノードごとにグラフの色を分けることもできます。\nその他 Marvelプラグインにブラウザから接続できなくなるとこんなメッセージが出ました。\n参考までに、elasticsearch-headの画面も。こちらのほうが、シャードの再配置中であるのがひと目で分かります。\n感想 綺麗です。まぁ、Kibanaが綺麗ですから。 クラスタ内で発生したイベントが時系列で保存されるため、あとからどんなことが発生したのかといった原因の追求などには非常に役に立ちそうです。\nただ、インデックスの状態や状況（クラスタ再起動やノード追加時にshard再配置などが実行されている状況とか）はelasticsearch-headのほうがわかりやすかったです。 インデックス単位でのStatusがMarvelの画面ではわからないため、shard再配置が完了したかどうかなどのタイミングがわかりにくかったです。\nある程度、多くのノードを利用したクラスタを利用する場合に、モニタリングツールとして利用するのは便利なのではないでしょうか？ 時系列でログやイベントが保存されるので、ノードが追加されたり外れたりといった状況があとからでも追跡可能なのが便利です。\n疑問点 インデックスの情報などは、5s毎にMarvelのインデックスに保存されているようです。ただ、GUI上では5分毎のデータしか表示されません。 どうやって変更するんだろう？\nまた、Marvelのクラスタへの接続が切れた時のデータはどうなるのか？という部分も気になります。Marvelのクラスタを更新している時や、ネットワークが遮断されてしまった場合のデータがどうなるのかという点です。\n疑問点への回答(2014/01/30追記) 疑問点に対して中の人から回答を頂いたので、追記です。\nQ：GUI上で5分毎のデータしか表示されないんですが？ A：ブラウザの負荷を高くしないようにするために、1つのグラフに20のプロットしてるだけです。ズームしたりすると、もっと細かなデータが見れますよ。 Q：Marvelのクラスタへの接続が切れた時のデータはどうなるんだろう？ A：接続が切れた場合は、ローカルに保存されるけどデータは無視されます。接続が戻ると、戻った後のデータは記録されていきます。将来的には改善するかも。 ちなみに、昨日試してた環境が、足元Linux環境（監視対象のクラスタ）＋手元Mac環境（Marvelモニタリングデータ格納クラスタ）という環境でした。 確かに、出社してから、手元Mac環境を起動すると、データが流れてくるようになりました。 ただ、監視対象のクラスタでは、socket timeoutのログがずっと出てましたが。\n参考文献 リリースブログ プロダクトページ ドキュメント ","date":1390983240,"dir":"post/2014/","id":"f6debed350f20a2b3aa4d970e3227411","lang":"ja","lastmod":1390983240,"permalink":"https://blog.johtani.info/blog/2014/01/29/simple-introduction-and-first-impression-es-marvel/","publishdate":"2014-01-29T17:14:00+09:00","summary":"昨晩、Elasticsearchから初のプロダクトとなるMarvelがリリースされました。ということで、さっそく触ってみて、簡単な紹介と感想","tags":["elasticsearch","marvel"],"title":"Elasticsearch Marvelの紹介と第一印象"},{"contents":"Lucene/Solr 4.6.1がリリースされそう(バイナリ配布待ち)lucene-gosenの4.6.1対応版をリリースしました。\nライブラリのインタフェースなどは特に変更はないのですが、ライブラリのダウンロード先が変更になっているため、注意喚起です。\nGoogle Project Hostingの仕様変更により、Downloadsに新規ファイルがアップロードできなくなっています。（2014年から）\nこのため、プロジェクトの選択肢としては以下の3点となっています。\nGoogle Driveにファイルをアップロードしてダウンロードしてもらう 他のソースコード管理サイトなどを利用する。 他のダウンロードサイトを利用する 1.と3.は場所が違うだけで、方法は一緒です。 今回は、暫定的に1.を利用してダウンロードするように対応しました。\nダウンロード先はプロジェクトのページにリンクが有りますが、わかりにくいのでキャプチャを撮ってみました。\nダウンロード先 これまでのFeatured - Downloadsとは異なり、Links - External linksの下に Downloads lucene-gosen 4.6.1というリンクを用意してあります。\nフォルダとなっており、各種jarファイルがリストされていますので、こちらからダウンロードをお願いします。 今後は、この下にダウンロードリンクを追加していく予定です。\nただし、2.で述べたように「別のソースコード管理サイト」も検討中です。\n","date":1390880040,"dir":"post/2014/","id":"c4e7199a586a308352b7a881add7e356","lang":"ja","lastmod":1390880040,"permalink":"https://blog.johtani.info/blog/2014/01/28/release-lucene-gosen-4-dot-6-1/","publishdate":"2014-01-28T12:34:00+09:00","summary":"Lucene/Solr 4.6.1がリリースされそう(バイナリ配布待ち)lucene-gosenの4.6.1対応版をリリースしました。 ライブラリのインタフェースな","tags":["Solr","Lucene","lucene-gosen"],"title":"lucene-gosen 4.6.1のリリースに関する注意点"},{"contents":"Elasticsearchのcuratorのブログ記事を読んで、日本語でツイートしたところ、Aaron Mildensteinさんから日本語（ローマ字）で返信を頂きました。 せっかくなので、ブログ記事を翻訳してもいいかを尋ねたところ、快くOKを頂いたので、翻訳してみました。参考になればと。（誤訳など見つけたらコメントください。）\n@johtani Kore no hou ga ii. Nihongo de no Curator RT, arigatou gozaimasu! #elasticsearch #curator #logstash\n\u0026mdash; Aaron Mildenstein (@theuntergeek) 2014, 1月 22 curator: 時系列インデックスの管理 原文：curator: tending your time-series indices\n背景 数年前、Elasticsearch、Logstash、Kibana(ELK)を管理し、ここ30日よりも古いインデックスを自動的に削除する方法を必要としていました。 APIドキュメントを読み、#logstashや#elasticsearchのIRCチャネルのコミュニティの助けを借りて、簡単なスクリプトとcronを用意するのが簡単であることを知りました。\ncurl -XDELETE \u0026#39;localhost:9200/logstash-2014.01.01?pretty\u0026#39; もちろん、これも動作しますが、日付を生成するのがめんどくさいのでもっとエレガントな方法が欲しかったです。\n最初に pythonでスクリプトを書き始めました。特定の日数のインデックスを管理するだけのコマンドラインクリーナーを書いてコミュニティにシェアしました。他の人が、新しい機能を追加してくれました。私は、古いインデックスをoptimizeすることができる他のスクリプトも書きました。これは、シャードごとにnセグメント以上存在しないように各シャードのセグメントをマージすることです。これらのスクリプトで1つになるようにマージしたりエンハンスし、古いインデックスを管理する助けになるツールです。\ncuratorの紹介 Curatorで可能なインデックスオペレーション\n削除（日付もしくは、トータル容量による制限） インデックスのクローズ(Close) bloom filter cacheの無効化 Optimize(LuceneのforceMerge) curatorのインストール この記事を書いている時点で、Curator は0.5.1がリリースされ、0.90.10に対応しています。Curatorはまた、Elasticsearchの1.0(現在はRC1)へも対応しています。各リリースへの互換性の保証のためのテストも行っています。\n現時点では、gitリポジトリで配布しています。近い将来、pipによるインストール可能なパッケージにする予定です。利用することを恐れないでください。もし、pythonとpipがあなたのマシンにインストールされていれば、次のようにインストールは簡単です。\ngit clone https://github.com/elasticsearch/curator.git pip install -r requirements.txt インストール後の確認は次のコマンドです。\n$ ./curator.py -v curator.py 0.5.1 利用方法とサンプル サンプルを示す前に、オプションを見ておくとよいでしょう。このリストは長いですが（この記事の最後に含まれています）、どのようなことがコントロールできるかを説明しています。デフォルトがどうなっているかに注意してください。もし、デフォルト値で良い場合は、フラグを指定する必要はありません。\nでは、簡単なサンプルを見ながら、CuratorがELKスタックをどうやって管理するかを見て行きましょう。\n削除(delete) 90日以上のインデックスを保存したくないとしましょう。コマンドは次のようになります。\n$ curator.py --host my-elasticsearch -d 90 -dで日数を指定しているだけです。簡単でしょ？\n容量による削除(delete by space) これは、指定したギガバイト数を超えたインデックスを場合に(最も古いものから)削除を行う特殊なケースです。\n$ curator.py --host my-elasticsearch -C space -g 10024 -Cでspaceによるcurationであること、-gでギガバイト数(10024、10TB)であることを指定しているのがわかります。-gは1.5や0.5という数値を指定できます。\nその他のCuratorオプションはspaceによる削除と組み合わせて使用できないことに注意してください。\nクローズ(close) Open/Close Index APIにより、インデックスをクローズすることができます。\nopen/close index APIを利用すると、インデックスをクローズしたり、あとでオープンしたりすることができます。クローズされたインデックスはクラスタのオーバヘッドにほとんどならず(メタデータの管理を除く)、読み書き操作の妨げにもなりません。クローズされたインデックスは、リカバリプロセス時に、オープンされます。\nインデックスをクローズすることは、存在はするが検索できないという意味です。何が便利なのでしょう？\n90日のインデックスを保存する義務があるが、検索は過去30日のインデックスを対象にする以外は稀であるような場合を想像してください。このような状況で、価値のあるリソース(ヒープスペースなど)を節約するためにインデックスをクローズすることができます。これは、クラスタに検索やインデキシングのためのメモリを与えることができることを意味します。そして、もし、クローズしたインデックスのデータが必要になったら、APIを呼び出してインデックスをオープンすれば検索できます。\nこのような場合、今オープンしているインデックスが再び、クローズされないように、一時的にCuratorのスケジュール実行をオフにしておくのが懸命です。\n$ curator.py --host my-elasticsearch -c 30 -d 90 先ほど説明した例の実行方法です。これは、30日よりも古いインデックスはクローズし、90日より古いインデックスを削除します。本当に簡単でしょ？\nbloom filterの無効化 これは、0.90.9以降のバージョンで利用可能な機能です。(リンク先はIssue #4525)\n心配しないでください。このスクリプトは操作を行う前に、elasticsearchが利用可能なバージョンであるかをチェックします。\nbloom filterとは何でしょう？なぜ、無効化したくなるのでしょう？\nbloom filterはインデキシング操作を高速化するためにリソースを割り当てられます。時系列データで、インデキシングしている間もこれは有用です。インデックスは2日後には、日付が変わると新しいデータはおそらくインデックスされません。そのインデックスにはもはや必要のないリソースをbloom filterはまだ持っています。Curatorはこれらのリソースを開放することができます！\n$ curator.py --host my-elasticsearch -b 2 -c 30 -d 90 これで、bloom filterのリソースは少なくとも2日(1にもできます)よりも古いインデックスについては利用せず、30日より古いインデックスはクローズし、90より古いインデックスは削除します。\noptimizeというよりもforcemerge コマンドの説明をする前に、Elasticsearch APIのoptimizeを見ることは、生きているインデックスや\u0026quot;cold\u0026quot;インデックス(インデキシングがアクティブではないという意味)に実行する必要があるということを理解するために重要です。実際、optimizeはLuceneではforceMergeと名前が変えられ、インデックスを改善するためにoptimizeを呼び出す必要はなくなりました。Elasticsearchのセグメントをマージすることは利点がありますが、coldインデックス全てに対してoptimizeを開始する前に、コストを理解する必要があります。\nforceMerge操作はインデックスにある各シャードのセグメントの数を少なくします。各セグメントはオーバヘッドがあるため、セグメントが多いということは、より多くのリソースを使うという意味です。良さそうですね？リソースが少ない？\nそれは、可能ですが、merge操作を実行するには多くのディスクやネットワークI/Oが必要で、ディスクやクラスタの通常の書き込み操作に悪影響を及ぼします。もし、これが必要なら私のアドバイスを良く考えてください。(数％ほど)検索を速くし、リソースの使用量も減らすことができます。また、管理しているセグメント数が小さくなるということは、クラスタのリカバリを速くすることにもなります。1つのインデックスをoptimizeするためにはおそらく1時間以上の時間がかかります。「使用する前に目立たない場所で試してください」というクリーニングボトル(訳注：洗剤とか漂白剤かな？)の注意書きと同様に、ディスクI/Oが低い時にテストし、もし操作とリソースがあなたのクラスタのユースケースにあっているかを見てください。デフォルトでは、シャードごとに2つのセグメントにマージしますが、--max_num_segmentsフラグで変更可能です。\nここまでのサンプルは次のようなコマンドになります。\n$ curator.py --host my-elasticsearch -b 2 -o 2 -c 30 -d 90 これで、bloom filterは2日より古いインデックスでは向こうにし、2日より古いインデックスは\u0026quot;optimize\u0026quot;し、30日より古いインデックスはクローズし、90日より古いインデックスは削除されます。\n操作の順序 スクリプトは操作が衝突するのを防ぐために次の順序で実行されます。なぜ、クローズされたインデックスはoptimizeしないのでしょう？なぜ、削除予定のインデックスはクローズされないのでしょう？\nDelete (by space or time) Close Disable bloom filters Optimize 使用の検討 最後の例で、3つの操作を1つのコマンドで実行していますが、それらが連続ですべて実行されるのを望んでいないかもしれません。\n$ curator.py --host my-elasticsearch -b 2 -o 2 -c 30 -d 90 これは、次の操作と同様です。\n$ curator.py --host my-elasticsearch -d 90 $ curator.py --host my-elasticsearch -c 30 $ curator.py --host my-elasticsearch -b 2 $ curator.py --host my-elasticsearch -o 2 これらのコマンドを異なる時間に実行したり、異なるその他のオプション(特に、optimize実行で--timeout 3600を追加したり)を指定して実行するのは簡単です。\nまた、デフォルトのlogstash-とは異なるプレフィックスのインデックスを持っているかもしれません。\n$ curator.py --host my-elasticsearch --prefix logstash- -d 30 $ curator.py --host my-elasticsearch --prefix othername- -d 30 最後に Curatorは時系列インデックスの保存ポリシーを管理するのに役立ちます。豊富な設定オプションがインデックスを管理することを簡単にします。クラスタに存在するノードの数に関係なく。https://github.com/elasticsearch/curatorへのフィードバックやコントリビューションをお待ちしています！\n参考(全引数とオプション) $ curator.py -h usage: curator.py [-h] [-v] [--host HOST] [--port PORT] [-t TIMEOUT] [-p PREFIX] [-s SEPARATOR] [-C CURATION_STYLE] [-T TIME_UNIT] [-d DELETE_OLDER] [-c CLOSE_OLDER] [-b BLOOM_OLDER] [-g DISK_SPACE] [--max_num_segments MAX_NUM_SEGMENTS] [-o OPTIMIZE] [-n] [-D] [-l LOG_FILE] Curator for Elasticsearch indices. Can delete (by space or time), close, disable bloom filters and optimize (forceMerge) your indices. optional arguments: -h, --help show this help message and exit -v, --version show program version number and exit --host HOST Elasticsearch host. Default: localhost --port PORT Elasticsearch port. Default: 9200 -t TIMEOUT, --timeout TIMEOUT Elasticsearch timeout. Default: 30 -p PREFIX, --prefix PREFIX Prefix for the indices. Indices that do not have this prefix are skipped. Default: logstash- -s SEPARATOR, --separator SEPARATOR Time unit separator. Default: . -C CURATION_STYLE, --curation-style CURATION_STYLE Curate indices by [time, space] Default: time -T TIME_UNIT, --time-unit TIME_UNIT Unit of time to reckon by: [days, hours] Default: days -d DELETE_OLDER, --delete DELETE_OLDER Delete indices older than n TIME_UNITs. -c CLOSE_OLDER, --close CLOSE_OLDER Close indices older than n TIME_UNITs. -b BLOOM_OLDER, --bloom BLOOM_OLDER Disable bloom filter for indices older than n TIME_UNITs. -g DISK_SPACE, --disk-space DISK_SPACE Delete indices beyond n GIGABYTES. --max_num_segments MAX_NUM_SEGMENTS Maximum number of segments, post-optimize. Default: 2 -o OPTIMIZE, --optimize OPTIMIZE Optimize (Lucene forceMerge) indices older than n TIME_UNITs. Must increase timeout to stay connected throughout optimize operation, recommend no less than 3600. -n, --dry-run If true, does not perform any changes to the Elasticsearch indices. -D, --debug Debug mode -l LOG_FILE, --logfile LOG_FILE log file ","date":1390542480,"dir":"post/2014/","id":"15f501351d482ffd73985a50f5c89d1f","lang":"ja","lastmod":1390542480,"permalink":"https://blog.johtani.info/blog/2014/01/24/curator-tending-your-time-series-indices-in-japanese/","publishdate":"2014-01-24T14:48:00+09:00","summary":"Elasticsearchのcuratorのブログ記事を読んで、日本語でツイートしたところ、Aaron Mildensteinさんから日本語（","tags":["elasticsearch","curator"],"title":"Curator: 時系列インデックスの管理(日本語訳)"},{"contents":"あけましておめでとうございます。今年もSolrやElasticsearchについて色々と頑張っていく所存です。 とまぁ、お決まりの挨拶はおいておいてと。(もう、新年も22日ですが。。。)\nElasticsearchの1.0.0RC1がリリースされました。 ということで、私が作っているExtended-Analyzeプラグインも1.0.0RC1向けに修正してリリースしました。\n1.0.0RC1向けに修正したこと コミットログを見てもらえば、いいのですが、ロジック自体は変更しなくても良かったです。\nただ、正式に、Elasticsearchのつづりが決定したようで、クラス名が「ElasticSearchほげほげ」から、「Elasticsearchほげほげ」と、SearchのSが小文字になりっています。 この影響で、例外クラスなどの名称を幾つか変更しました。 また、バージョン番号を1.0.0RC1とし、0.x系をElasticsearchの0.90系向けのバージョンにしていく予定です。\n今後は、UIを追加したいと思っているので、Elasticsearchのバージョン番号とはずれてくるとは思いますが。。。\nElasticsearch 1.0.0RC1を利用してみて 1点だけですが。 これまでは、-fオプションを指定すると、デーモンではない動作で起動できていました。（デフォルトがデーモン起動）\nこれが、1.0.0から（0.90の最新もかな？詳しく見ていない）デフォルトの挙動が変更され、デーモン起動ではなくなりました。 代わりに、-dオプションを指定することで、デーモン起動ができるようになりました。\nこれで、手元でうっかりデーモン起動することがなくなって、ひと安心です。（他の人は困るかもしれないけど）\nということで 1.0.0RC1が出たので、少しずつ1.0系で追加されたAPIや機能について、ブログで紹介していけたらと思います。\nこんなこと調べてよ？、これわかんないんだけど？などありましたら、コメントいただければと。 気が向いたら記事を書くので。\nあと、Extended-Analyzeプラグインの感想などもお待ちしています！\n今年もよろしくお願いします！\n","date":1390317360,"dir":"post/2014/","id":"6425af51edead39c0e439073986043fb","lang":"ja","lastmod":1390317360,"permalink":"https://blog.johtani.info/blog/2014/01/22/release-extended-plugin-for-1-0-0rc1/","publishdate":"2014-01-22T00:16:00+09:00","summary":"あけましておめでとうございます。今年もSolrやElasticsearchについて色々と頑張っていく所存です。 とまぁ、お決まりの挨拶はおいて","tags":["elasticsearch"],"title":"Extended-Analyze 1.0.0RC1をリリースしました"},{"contents":"昨年は、大晦日に書いてました。 ちょっと進歩したかも。\n振り返り(2012年に書いた抱負から) ということで、まずは昨年書いた抱負からの振り返りです。\nIntelliJ IDEAをメインに使う JIRAを継続して活用 ブログの継続 elasticsearch Luceneのソースコードリーディング 何かOSSのソースを読む Macでもっと開発 読書と英語を継続 お。思ったよりもできてるかも。 IntelliJ IDEAについては、メインになりました。Eclipseを開くことはまずないです。 Macがメインの開発マシンにもなってきてるので。(開発してないんじゃないかという話も。。。)\nJIRAは一応、継続しているという感じです。\n唯一Luceneのソースコードリーディングができてないですね。。。 言い訳をすると、明示的にソースコードリーディングをしているわけではないですが、Luceneのソース自体は時々見ています。 SolrやElasticsearchを調べるとそのままLuceneにたどり着くことがあるので。\nポモドーロのタスク管理用に使っていますが、時々忘れていたり。あと、振り返りがまだちゃんとできてないので、そこをやらないとかなぁと。 読書と英語は今後も継続です。もっと習慣づけないと。\n振り返り(今年あった出来事など) CROSSでモデレータやりました Xperia Zに機種変 メニエール病 リクルートテクノロジーズさんのお手伝い Lucene In Action輪読やってる MIR輪読も継続 Solr勉強会を不定期開催 Elasticsearch勉強会を始めた Solr本の改訂版を執筆 AWSちょっと触った Elasticsearchプラグイン作ってみた Githubの活用 Octopressでブログ こんなかんじです。\nCROSSでは、モデレータをやらせていただきました。すこしは検索を面白いと思ってもらえたかなと思います。 来年のCROSS 2014ではスタッフとして盛り上げていく予定ですので、スタッフに興味ある方は声をかけてください！ 面白い話がいっぱい聞けますし、おいしい物も飲み食いできるかも！？\nXperia Zは良い買い物でした。ただ、すでに2回電源部分が故障してますが。。。 それ以外は非常に快適です。\n2月末から3月は少し休んでました。難聴→めまい→メニエール病という流れで、ちょっとしんどかったです。 ほぼ回復しましたが、原因は不明みたいなので、長く付き合ってくのかなぁと。\n4月からリクルートテクノロジーズさんの仕事を手伝っています(Solr本の著者紹介にも書いてます)。 色々と面白いことをしているATLという部署で面白い人達と仕事させて頂いてます。 来年もよろしくお願いします！(もっと価値を出さないとなぁ。。。)\nその一環で、Lucene In Actionの輪読を社内でやっていたりも。バージョンが3.x系で書かれているので、 ちょっと大変ですが、4だとどう違うかなどの話を交えつつ少しずつ読んでいます。\n輪読会といえば、MIR(Modern Information Retirieval)の輪読も続いています。 私は深いところまでわからないのですが、色々と詳しい方たちとボチボチ読んでます。教えてもらってばかりですが、来年も頑張りますよと。\nSolr勉強会も、引き継いでぼちぼちやっています。来年は1/29に開催します。Solrの入門的な話をしてもらうので、 ぜひ、触ったことがない方や興味がある人に参加していただきたいと。\nElasticsearch勉強会も主催し始めました。興味ある人がいるだろうとは思ったのですが、想像以上でびっくりしてます。 自分が理解を深め、発表するためにも、2ヶ月程度のスパンで来年も開催する予定です。 スピーカーに興味のある方は、elasticsearch-jpのMLや私にコンタクトしてください。\nSolr入門のSolr4対応版も執筆しました。今回は全体のコーディネートもやらせていただきました。 Solr活用のお役に立てていただければと。まだ購入してない方はぜひ、以下のリンクから！(PDF版もあります。) 質問などあれば、ブログにコメントをいただくか、ツイートしていただくか、技術評論社のサポートページに問い合わせていただければと思います。\nAWSをちょっとだけ触りました。 S3にバックアップ取ってるだけですが。。。来年はもう少し。。。 JIRA（さくらVPSに立ててる）のバックアップなどをやってます。\nあとは、Elasticsearchの勉強会も始めたこともあり、Elasticsearchを色々と触っています。 elasticsearch-analysis-kuromojiプラグインのREADMEを記述してコントリビュートしてみたり、 elasticsearch-extended-analysisプラグインを作ってみたり。\n勉強会のスピーカー探しも兼ねて、いろんなところに、「突撃!隣のElasticsearch」と称してElasticsearchの話を聞きに行きたいと思っていますので、使ってるよ！とか使いたいんだけど、どうすればいい？みたいな話があれば、声をかけてください。Twitterでツイート見たら勝手に、アタックすることもあるかもですが、その時はよろしくお願いします。\n来年はSolrやElaticsearchにもっと貢献できればと。\nGithub(git)もようやくまともに触り始めました。 某データの管理やプラグインの開発などでやっと触り始めました。 まだ、チーム開発ってほどではないので、チームで開発するときのやり方なども少しずつ勉強していこうかと。 プルリクとかも少しずつやってみたりしてます。\nあとは、Octopressでブログ始めました。その前はjugemだったのですが、なんとなく。 Markdownに慣れるためというのもありOctopressにしてみました。 (Solr本の原稿もMarkdownで書いてました) 昔のブログもこっちにコピーするプログラムも書いてみようかな。\n来年の抱負 Elasticsearch勉強会、Solr勉強会の継続＋ミックスした検索勉強会の開催 IDEAのさらなる活用 もっと開発(プラグインとか) AWSをもう少し活用 海外のイベントに行ってみたい 読書と英語を継続 勉強会の開催は今後も継続していく予定です。会場を毎回提供して頂いているVOYAGE GROUPさん、リクルートテクノロジーズさんには、 今後もお手数をお掛けしますが、よろしくお願い致します。勉強会の開催を通じて、色々な人のノウハウがうまく共有できて、 もっと本質的な作業（サービスの改善とか）に注力できる環境ができると面白いなぁと思ってるので。\nあと、Elasticsearch、Solrと別々の勉強会になっていますが、検索エンジン勉強会という形でそれぞれのメリット・デメリットを 共有できる勉強会も面白いかもと思っているので、春とかに開催したいなぁと考えてもいます。（まだ考えているだけで何もネタがないですが）\nIDEAは、年貢(13のサブスクリプション)を収めたので、もっと活用しないとという意味で。プラグインの開発、gitやsvnのクライアントとしては 活躍していますが、もっと開発に活用していかないとなぁと。まだ、10%くらいしか活用できてない気がするので。\nもっと開発しないとなと。毎年言ってますが。今年は書籍に注力したのもあり、ソースを読んだり英語を読んだりが多くなってました。 偉そうにしてるためか、開発する機会が減ってきているので、細かなことでもいいので、すこしずつコードを書いていこうかと。 （もっと自分で問題点を見出してそれを補完するようなコードなりプラグインなり書けばいいんだろうな。）\n開発と合わせて、AWSをもう少し触りたいなと。これも数年言っていますができてないです。。。 ネタ探すのが下手なのかなぁ。\n海外イベントにも行ってみたいです。まだ、海外行ったことないんですが。。。 Lucene Revolutionとか。その訓練も兼ねて英語でメール書いたり、プラグインのREADME書いたりしてみてます。\n最後は、毎年恒例ですが、読書と英語です。 Packtのキャンペーンで買ってしまった英語の本とか貯まっているので、読まないと。 nasneが便利で通勤時間にドラマ見てるからなぁ。ま、必要なときにボチボチと読んでいく予定です。\n最後は、いつものようにですが、来年も勉強会やいろんなイベントに参加する予定です。 ブログも週1程度で書く努力しないとなぁ。 こんな話を書いてくださいとかのリクエストもお待ちしています。\n今年もまだ、大晦日が残っていますが、色々とお世話になりました。 この場を借りてお礼申し上げます。\n来年も、いろんな方に絡んでいくとは思いますが、よろしくお願いいたします。\n","date":1388406000,"dir":"post/2013/","id":"10c715f70de25ccb493bbbb532b78ced","lang":"ja","lastmod":1388406000,"permalink":"https://blog.johtani.info/blog/2013/12/30/looking-back-2013/","publishdate":"2013-12-30T21:20:00+09:00","summary":"昨年は、大晦日に書いてました。 ちょっと進歩したかも。 振り返り(2012年に書いた抱負から) ということで、まずは昨年書いた抱負からの振り返りで","tags":["振り返り"],"title":"今年の振り返りと来年の抱負（2013）"},{"contents":"昨夜、Elasticsearchの0.90.8がリリースされました。\nリリースされた内容などについては、本家のブログ「0.90.8 released」をご覧いただくこととして。 1点注意したほうが良い点があります。\nelasticsearch-analysis-kuromojiを利用している場合は、0.90.8に対応したバージョンがリリースされるのを待つ必要があります。\nelasticsearch 0.90.8はLuceneのバージョンが4.6.0に変更されています。 Lucene 4.6.0では、TokenStreamというTokenizerのI/Fに変更があり、Tokenizerの実装を変更する必要があります。\n現時点（2013年12月19日現在）のelasticsearch-analysis-kuromojiの1.6.0にはlucene-analyzers-kuromoji-4.5.1.jarが含まれており、この部分でI/Fが異なるためエラーが発生してしまいます。 プラグインをインストールする時点ではエラーは発生せず、実際にKuromojiのTokenizerやAnalyzerを利用するタイミングでエラーが出ます。 以下、0.90.8にanalysis-kuromojiの1.6.0をインストールした状態で_analyzeを実行した時のエラー。\ncurl -XPOST \u0026#39;localhost:9200/_analyze?tokenizer=kuromoji_tokenizer\u0026amp;filters=kuromoji_baseform\u0026amp;pretty\u0026#39; -d \u0026#39;寿司が美味しかった\u0026#39; { \u0026#34;error\u0026#34; : \u0026#34;IllegalStateException[TokenStream contract violation: reset()/close() call missing, reset() called multiple times, or subclass does not call super.reset(). Please see Javadocs of TokenStream class for more information about the correct consuming workflow.]\u0026#34;, \u0026#34;status\u0026#34; : 500 } ということで、1.7.0がリリースされるのを待つか、自分でmvn packageしてビルドする必要があります。 他にも独自でTokenizerなどを造られている方は注意が必要かと。\nたぶん、すぐにリリースされるんじゃないかなぁと。\n2013/12/20追記\nとりあえず、masterブランチが0.90.8に変更されたみたいです。(と書いてるそばから、1.7.0がリリースされました) ということで、0.90.8では1.7.0を使うとエラーが出ないです。 （あと、踊り字対応のcharfilterも追加されたみたいです）\n","date":1387524240,"dir":"post/2013/","id":"c18b12fff24dc87e7f1039bd17c0c6aa","lang":"ja","lastmod":1387524240,"permalink":"https://blog.johtani.info/blog/2013/12/20/release-elasticsearch-0-90-8/","publishdate":"2013-12-20T16:24:00+09:00","summary":"昨夜、Elasticsearchの0.90.8がリリースされました。 リリースされた内容などについては、本家のブログ「0.90.8 releas","tags":["elasticsearch","kuromoji"],"title":"Elasticsearch 0.90.8がリリースされました＆注意点（2013/12/20追記）"},{"contents":"Solr本が出てから、質問を受けてブログ書くと言いながら書いてなかったことを思い出しました。。。\nプラグインの配置方法についてこんな質問を受けてたので、それっぽいエントリを書いておきます。（想像と違ってたらツッコミ入れてください）\n@johtani 追加でプラグインの配置方法とかあると便利かなと思いました\n\u0026mdash; Tsubosaka (@tsubosaka) 2013, 12月 2 改定前のSolr本では、日本語の形態素解析器をjarファイルとして追加する方法が書かれていました。 ただ、改定後のSolr本では、KuromojiがLuceneで実装されているためサンプルとしてjarファイルを追加するような方法の記載が明確にはありません。\n19ページのcollection1の説明ですこしだけ、libディレクトリについて触れています。\n独自のTokenizer（lucene-gosenなど）はjar形式でSolrに追加し、schema.xmlなどに利用するFactoryを指定してから利用します。\nこのとき、追加のjarファイルを配置する先がlibディレクトリです。\nlibディレクトリは2つの種類のスコープのディレクトリが存在します。\nSolr全体で利用可能なlibディレクトリ コア単位で利用可能なlibディレクトリ Solr全体で利用するlibディレクトリ これは、起動しているSolrにある全てのコアで利用するようなjarファイルを配置するディレクトリになります。 場所は$SOLR_HOME/libです。ここにjarファイルを配置することで、この$SOLR_HOMEを利用するすべてのコアで同じjarファイルを利用することができるようになります。\nですので、例えば、lucene-gosenはすべてのコアで利用するという場合にはここに配置すれば、1つのjarファイルを配置するだけで済むことになります。\nコア単位で利用するlibディレクトリ これは、コアごとにlibディレクトリを用意する場合です。 19ページにも記載されていますが、$SOLR_HOME/コアディレクトリ名/libとなります。\n特定のコアのみで利用するライブラリについてはこちらに配置する形になります。 他のコアで利用してほしくないjarファイルなどを配置するのに利用すればよいかと。\n簡単ですが、補足記事でした。 UIMAやlangidの利用方法などもあるとうれしですかね？ そのうち気が向けば書くかもしれません。（他の人に書いてもらうのもありかも。）\n","date":1387447740,"dir":"post/2013/","id":"cb5b6f7ab4d36e90d2619cb907ebb956","lang":"ja","lastmod":1387447740,"permalink":"https://blog.johtani.info/blog/2013/12/19/add-jar-file-to-solr/","publishdate":"2013-12-19T19:09:00+09:00","summary":"Solr本が出てから、質問を受けてブログ書くと言いながら書いてなかったことを思い出しました。。。 プラグインの配置方法についてこんな質問を受け","tags":["Solr"],"title":"Solrへのプラグインの配置方法について"},{"contents":"ども。 プラグインのインストールに長いURL入れるの辛いですよね？ね？\nということで、MavenでリリースしてMaven Repositoryからダウンロードできるようにしてみました。\n流れとしては\nSonatypeにリリースできるように申請する Sonatypeにリリースする SonatypeからMavenにSyncしてもらう という流れです。\nSonatypeにリリースするための方法はイケメンの人(@yusuke)がブログに簡単ですが残してくれてました。 あと、こちらの@vvakameさんのブログも参考にしながら作業しました。\n【最新版】Maven Central Repository へのライブラリ登録方法 #maven JsonPullParser が Maven Central Repository に入るようです pom.xmlについては、プラグインのpom.xmlを参考にしてもらえればと。 1.の作業が終わったら、リリースを実行します。\nこの時、\u0026lt;scm\u0026gt;タグにgithubの情報が記載されているため（？）、githubにタグを打つ作業もmavenコマンドがやってくれるみたいです。\nmvn release:prepare を実行すると、リリースするバージョンやタグ名などを聞いてくれます。 それらに答えると、pom.xmlにバージョンを指定してcommit\u0026amp;pushしてくれ、タグも打ってくれます。（なんて便利）\nその後、release:performにてSonatypeへのリリースが完了します。 あとは、Sonatypeの画面で作業したら、Mavenのリポジトリにそのうち同期してくれます。\nということで、次のコマンドを実行すればプラグインがインストールできるようになりました。0.6.0と0.7.0の違いは実装には差異はありません。リリース方法が変更されただけということになります。\nbin/plugin -i info.johtani/elasticsearch-extended-analyze/0.7.0 これで少しは活用してもらえるようになるかなぁ？ （どのくらいの人が使ってくれてるのかは不明。。。）\n","date":1387249860,"dir":"post/2013/","id":"a0a00c23556fcc5dbfb7b7f43fbbb61d","lang":"ja","lastmod":1387249860,"permalink":"https://blog.johtani.info/blog/2013/12/17/release-es-extended-analyze-plugin-to-maven-and-sonatype/","publishdate":"2013-12-17T12:11:00+09:00","summary":"ども。 プラグインのインストールに長いURL入れるの辛いですよね？ね？ ということで、MavenでリリースしてMaven Repositoryから","tags":["elasticsearch"],"title":"elasticsearch-extended-analyzeプラグインをMavenとSonatypeにリリース"},{"contents":"少し遅くなってしまいましたが、12/05に電子書籍も発売されました。\n技術評論社の電子書籍サイトから購入可能です。\n書籍のページへのリンク PDF版となっております。 購入の際は、技術評論社の電子書籍サイトに会員登録後購入可能となります。\n個人的には電子書籍が便利なので、こちらを普段活用しようと思っています。\nもちろん、紙の書籍も発売中です！購入の際は右の書影をクリックしていただければと！\n","date":1386554880,"dir":"post/2013/","id":"d9560caeb797b302191f667b4264da40","lang":"ja","lastmod":1386554880,"permalink":"https://blog.johtani.info/blog/2013/12/09/release-introduction-solr-ebook/","publishdate":"2013-12-09T11:08:00+09:00","summary":"少し遅くなってしまいましたが、12/05に電子書籍も発売されました。 技術評論社の電子書籍サイトから購入可能です。 書籍のページへのリンク PDF","tags":["Solr"],"title":"改訂版Solr入門のPDF版も発売"},{"contents":"勉強会で宣伝もしましたが、改めて。\nSolr入門の改訂版を執筆しました。 考えてみれば、もう3年も前なんですね、Solr入門は。 Solr勉強会などでも何度も新しいのは出ないのですか？と聞かれていましたが、やっと出ました。（お待たせしました。）\n時が立つのは早いものです。前回のSolr入門はバージョン1.4にて執筆していましたが、今回は4.4をベースにし、4.5.1への対応を行っています。\n月曜日には手元に見本が届き、今週金曜日に発売予定です！\nSolrCloud、SoftCommit、Spatial、Joinなど、多彩な機能についても記載してあります。 また、ManifoldCFというSolrにデータを登録するのに 利用できるコネクタフレームワークについても書いてあります。\nより多彩になったSolrの機能を活用するための一助となれればと思います。 （電子版も出る予定です。詳細についてはもう少々お待ちください）\nまた、出版を記念して少し時期が先になりますが、Solr勉強会を開催しようと思います。\n日時：2014年01月29日 第13回Solr勉強会 #SolrJP 新Solr本出版記念 今回はせっかくのSolr入門の書籍の出版記念ということで入門的な話をしてもらう予定です。 Solr初心者の方、Solrに興味のある方などに来ていただきたいと思っています。 （プレゼントも用意できるかも！？）\nということで、「改訂版Apache Solr入門」をよろしくお願いします。 （もちろん、購入は下のリンクからですよね！）\n","date":1385436420,"dir":"post/2013/","id":"a2012a3c9cdb1d6fd69afdbadc1e76b6","lang":"ja","lastmod":1385436420,"permalink":"https://blog.johtani.info/blog/2013/11/26/introduction-to-solr-new-edition/","publishdate":"2013-11-26T12:27:00+09:00","summary":"勉強会で宣伝もしましたが、改めて。 Solr入門の改訂版を執筆しました。 考えてみれば、もう3年も前なんですね、Solr入門は。 Solr勉強会な","tags":["Solr"],"title":"改訂版Solr入門を執筆しました"},{"contents":"どーも。以前の記事で開発中としていたプラグインですが、とりあえず、pluginコマンドでインストール出来る形にしてみました。\nインストールなどについては、READMEに記載したのでそちらを参照してもらうことにして、試行錯誤した話をメモとして残しておきます。\nプラグインの開発はしいてたのですが、やっぱりpluginコマンドでインストール出来ないと使ってもらえないよなということで、勉強会も終わったのでちょっと調べてました。\nプラグインコマンド コマンドが用意されてますが、実態はJavaで実装されてて、通常はこんなかんじでプラグインをインストールします。\n./bin/plugin -i elasticsearch/elasticsearch-analysis-kuromoji/1.6.0 この「elasticsearch/elasticsearch-analysis-kuromoji/1.6.0」という文字列ですが、「ユーザ名/リポジトリ名/バージョン」という意味になります。\nで、ダウンロードするURLは以下のものの中から選ばれます。\nelasticsearch.orgのダウンロード用サイト search.maven.org oss.sonatype.org Githubのarchive これらのサイトに先ほどのユーザ名、リポジトリ名、バージョンを利用したURLを組み立てて、ダウンロードしてくれるという仕組みになっています。\nelasticsearch.orgについては、本家の人しかアップロードできないと思うので、なし。\nmaven、sonatypeについては、Mavenのリポジトリにリリースする必要があるんじゃないかなと。 で、昔調べてググって途中で挫折したんですが、挫折してます。手順が結構手間で。。。 （参考記事：【最新版】Maven Central Repository へのライブラリ登録方法 #maven）\nということで、Githubにアップしたらなんとかなるんじゃん？ということで色々と調査して試してみました。（結果はイマイチなんですが。。。）\nその１：mvn release:prepare せっかくGithubだし、せっかくMavenなんだしなんか、pom.xmlに便利な設定したらコマンド一発でリリースできるんじゃない？という甘い気持ちで調査したググったらそれっぽい記事が見つかりました。 「MavenとGitHubの連携」って記事です。\nで、pom.xmlの設定にも他のプラグインを真似してコピペしたものに\u0026lt;scm\u0026gt;ってタグがあったなぁと。このコマンドでついでにGithubにアップロードできるんじゃないの？ということで、試してみました。\nmvn release:prepare このコマンドを叩くと、記事にあるとおりにいくつか質問をされます。 タグについては、プロジェクト名-バージョン番号という文字列がデフォルトだと指定されているので、v0.5と変更して実施してみると、Githubのreleaseにv0.5ってのができてるじゃないですか。\n※pluginコマンドはGithubを見に行く時に次のファイルをダウンロードしに行きます。\nhttps://github.com/ユーザ名/リポジトリ名/archive/vバージョン名.zip やった！と思い、早速pluginコマンドを実行してみましたが、エラーが出ました。。。\nTrying https://github.com/johtani/elasticsearch-extended-analyze/archive/v0.5.zip... Downloading ...DONE Installed johtani/elasticsearch-extended-analyze/0.5 into /Users/johtani/projects/tmp/ess_env/second_node/elasticsearch-0.90.7/plugins/extended-analyze Usage: -u, --url [plugin location] : Set exact URL to download the plugin from ...省略... Message: Error while installing plugin, reason: IllegalArgumentException: Plugin installation assumed to be site plugin, but contains source code, aborting installation. あらら、なんで？と。\nで、実際にgithubにアップされてたzipファイルをダウンロードしてみたら、githubのリポジトリにあるディレクトリ構成がそのまま入ってるじゃないですか。。。 そうですか、そうですよね。prepareだし、タグ打ってzipにかためてくれるだけなんですねと。。。\nおそらく、siteプラグインだけの場合はこの方法でpluginコマンド叩けばOKなんでしょうが、私がダウンロードしてもらいたいのは.jarファイルが入ったzipファイルなんです。\nということで、断念しました。（タグ消したりをgitコマンドで叩いて綺麗にし直すとか虚しい作業をしてました）\nその２：github.comのWebでリリース おとなしく、Sonatypeのサイトにアップロードする方向でがんばればいいんですが、とりあえず使えるようにするのが先だと思い、 github.comのページでアップロードしてしまおうと。\n「release」というタブをクリックすると、画面からアップロードできるようになります。\nzipファイルを作ってアップロードしました。（zipファイル自体はmvn packageコマンドを実行したらtarget/releaseというディレクトリに作成されてる）\nこれで行けるだろということで、またpluginコマンドを実行すると\nTrying https://github.com/johtani/elasticsearch-extended-analyze/archive/v0.5.zip... Downloading ...DONE Installed johtani/elasticsearch-extended-analyze/0.5 into /Users/johtani/projects/tmp/ess_env/second_node/elasticsearch-0.90.7/plugins/extended-analyze Usage: -u, --url [plugin location] : Set exact URL to download the plugin from ...省略... Message: Error while installing plugin, reason: IllegalArgumentException: Plugin installation assumed to be site plugin, but contains source code, aborting installation. あれ？同じエラー？なんで？jar入りのzipファイルアップロードしたのに？？？\nと。で、https://github.com/johtani/elasticsearch-extended-analyze/releasesにreleaseのページができてたので見てみると、あら。 アップロードしたファイルについては次のようなURLになってるじゃないですか。\nhttps://github.com/johtani/elasticsearch-extended-analyze/releases/download/v0.5/v0.5.zip で、よく見ると「Source code(zip)」というボタンもあるぞ？このリンクは？\nhttps://github.com/johtani/elasticsearch-extended-analyze/archive/v0.5.zip 。。。あぁ。そうですか。そういうことですか。理解してない私が悪いんですねと。\n結論？ ということで、とりあえず、releaseにjar入りファイルはアップロードできた（手動で）ので -uオプションで直接URL指定すればインストールできるだろ！と諦めました。 いい勉強になりました。。。\nREADME見ていただくとインストール方法が分かりますが、長いです。。。\n時間をとって本腰入れてSonatypeにMavenコマンドでアップロードできるようにしようかな。。。\n","date":1384419300,"dir":"post/2013/","id":"13684d16fdd07d5f0584e29265a270e7","lang":"ja","lastmod":1384419300,"permalink":"https://blog.johtani.info/blog/2013/11/14/release-elasticsearch-extended-analyze-0-dot-5/","publishdate":"2013-11-14T17:55:00+09:00","summary":"どーも。以前の記事で開発中としていたプラグインですが、とりあえず、pluginコマンドでインストール出来る形にしてみました。 インストールなど","tags":["elasticsearch","plugin"],"title":"elasticsearch-extended-analyzeを公開？"},{"contents":"第2回を開催しました！ すごい、140人くらいくらいの参加登録者（参加者は１００人ちょっと！）がいて、びっくりです。 ステキな会場を提供していただいた、リクルートテクノロジーズさん、運営していただいた方々、スピーカーの皆さん、参加者の皆さん本当にありがとうございました。 今回も素敵な看板ありがとうございます。\n今回もしっかり楽しめたので、次回も頑張ります！\n今回は、elasticsearch-jpMLの紹介とかをできたのでよかったかなぁと。 ぜひ、活用してください！どんな質問でもいいので。\nあと、スライドに入ってた例の本もよろしくです。\nということで、懇親会も盛り上がったし楽しかったです。 今後も場の提供＋自分の勉強のトリガーとして、開催していくので、ご協力お願いします！ 聞きたい話など、MLや@ツイートしていただければと。\nelasticsearchのRouting機能：株式会社シーマーク　大谷　純　（@johtani） スライド：Routing機能※スライドはPDFです。\nド緊張で、大した発表ではなかったですが。。。 どちらかと言うとSolr本の紹介だったかもなぁ。スミマセン。\n※スライドが一部文字が消えてるので、作りなおすかも。\nElasticSearchを使ったBaaS基盤の開発(仮)：株式会社富士通ソフトウェアテクノロジーズ 滝田聖己さん（@pisatoshi） スライド：https://speakerdeck.com/pisatoshi/elasticsearch-trial-and-error\n本日はお越しいただきありがとうございました！しかも静岡から！今後もよろしくお願い致します。\nEnchantMoonでシステム構成ｗ\n0.17.0から利用されていると。（スゴイ）\nプライマリのデータストア！ただし、登録元データはMySQLにもある。\n階層も深く、大きめのドキュメント。\nレプリカ１、インデックスのバックアップも取ってないと。。。\nルーティングの機能\nDynamicMappingの問題点\nマッピング定義が肥大、型がコンフリクト。。。苦労しっぱなし\nデータ登録は１台にして、１台で一気に登録してから再配置\n実際に運用とかされてるので、いろんなノウハウがまだまだありそう！\nKibana入門：水戸祐介さん（@y_310） スライド：https://speakerdeck.com/y310/kibanaru-men\n（やっぱりru-menになってるｗ）\n実は、押しかけて話してもらうように説得したのでした。今後もよろしくです。\nCOOKPADの方によるKibanaのお話。 Kibanaの利点とかなんで？とか。 画面構成の説明から ダッシュボードは必ず保存して！リロードしたら悲しい思いをしてしまうので。 sparkline便利そうだなぁ。ほんとに、データサイエンティスト系のツールを目指してるのかな 一通り、ダッシュボードに配置できるパネルの説明してもらえたのですごく参考になりました！ Tips周りが役に立ちそう。not_analyzedは重要ですよね。 LT 「データ集計用ダッシュボードブラウザとしても使えるElasticSearch＋Kibana v3を利用する際の運用ノウハウ紹介」：株式会社リブセンス Y.Kentaro さん (@yoshi_ken) さん スライド：http://www.slideshare.net/y-ken/elasticsearch-kibnana-fluentd-management-tips\nKibanaの紹介とかFluentdの紹介。 Tips満載すばらしい。 JDBC riverは0.90.6ではうまく動かないので、気をつけてと。 「Fluentd as a Kibana」：@repeatedly さん スライド(gist)？：https://gist.github.com/repeatedly/7427856\nKibanaがfluentdの中で動くと！？\n「Authプラグインでアクセスコントロール」：株式会社エヌツーエスエム 菅谷信介さん (@shinsuke_sugaya) スライド：http://www.slideshare.net/shinsuke/es-auth-plugin\nAPI毎？インデックスごと？にアクセス制御ができるプラグイン\n","date":1384247760,"dir":"post/2013/","id":"66f43ab4b823d67f52735bbbe6ba65b0","lang":"ja","lastmod":1384247760,"permalink":"https://blog.johtani.info/blog/2013/11/12/elasticsearch-japan-user-meetup-no2/","publishdate":"2013-11-12T18:16:00+09:00","summary":"第2回を開催しました！ すごい、140人くらいくらいの参加登録者（参加者は１００人ちょっと！）がいて、びっくりです。 ステキな会場を提供していた","tags":["elasticsearch","kibana","fluentd","勉強会"],"title":"第2回elasticsearch勉強会を開催しました！ #elasticsearchjp"},{"contents":"Cloudera World Tokyo 2013に参加してきました。\n午前中はあいにくの雨でしたが、それでも結構な人数が最初の基調講演から参加されてました。 私が参加したセッションは大盛況な感じでした。\nおみやげとしてカステラも頂いちゃいました！\nまた、色々なセッションに現れたこんなメッセージ画像も見つけました！\n昨日の写真データの整理をしていたら、こんなものが・・・ @shiumachi さんよ・・・ #cwt2013 pic.twitter.com/S0JsxSYXIx\n\u0026mdash; Kenichiro HAMANO (@hamaken) November 8, 2013 やっぱり、スーツの人が多いなという印象。\n名刺を毎回回収されるのはちょっとつらかったです。なにか、いい方法ないですかねぇ。\n以下はいつもの個人メモです。\n「ビッグデータプラットフォームとして進化するHadoop」 Cloudera株式会社　代表取締役　ジュセッペ小林氏 Costcoなどの写真を元にビッグデータを可視化 BigDataとHadoopの関係 検索、SQL、機会学習、数理処理、データ管理などにもHadoopの活用されつつある。 セキュリティ、データ管理、クラスタ上でのツールの実行なども増えてきてる。\n「今日ビッグデータは明日のスモールデータ」\nアーキテクチャとしてのビッグデータ 多種多様なデータを一箇所に集約し、生データを直接活用できる。 OSSとしての責任も。\nデータサイエンス Opsだけでないデータ解析にも活用\n「Clouderaのビッグデータプラットフォーム戦略」（仮） 講師：Cloudera, Inc. CTO Dr.Amr Awadallah レガシーな情報アーキテクチャ→スケールできない、可視化の限界、硬直したスキーマなどなど。\nエンタープライズデータハブとしてのHadoopとか。\nビッグデータの歴史と将来展望 講師：国立情報学研究所　アーキテクチャ科学研究系　教授　佐藤一郎氏 ビッグデータの歴史的経緯とか 最初の事例はアメリカの1880年国勢調査。\n「ビッグデータがコンピュータを生み出した」。コンピュータがビッグデータを生み出したんじゃない。\n少量データにもHadoopを\nバッチ処理のリアルタイム化とか（一晩から10分へ） 原点は検索データのインデクシング\nHadoopを使うのが目的じゃないんだから、構築には手を掛けないのがいいよね。\nプラットフォームと発展している\n分散システム研究者から見たHadoop 分散ししテムの難しさを、処理範囲を限定することで巧みに回避 データの近くで処理 研究レベルではリアルタイム化や逐次処理化が活発 全工程で逐次・リアルタイムが必要とは限らない 聞いてばかりじゃなくて、動かしてみましょう。 データサイエンス：超並列分散処理を活用した新たなビジネス価値の創出 講師：アクセンチュア株式会社　工藤卓哉氏 「日経BPのビッグデータ総覧2013」に記事書いてる。 多様化するデータ（社外のデータも）をどうやってうまく活用していくか。 データが教えてくれたこと→まず、データありき、まずデータためましょう。それから解析とかすればいいのでは？というはなし？ 競合他社さんはNGだけど、ブースでデモ？実機？が見れますと。 Hadoopデータプラットフォーム Cloudera株式会社　嶋内　翔氏 まずは宣伝 Cloudera Implaraのフリーブックの日本語版 Hadoop Operationの書籍でるよ プラットフォームを構成するもの Flume Sqoop HBase Hive Impala データ登録してBIアナリストのお仕事にどうやって役立てる？ 外部テーブル：Hiveからはテーブルのように見える仕組み。元ファイルは消えない SerDe（さーでぃー）：データをHiveレコードに変換する仕組み 生データを少し加工しましょう 圧縮したりファイル結合したりはしときましょう。 Hadoop活用のポイント 富豪的プログラミング。リソースケチるな。 ローカルでできることはローカル。むりにHadoopでやんなくてもいいですよねと。バランス重要 スケジューリング実行などはOozie使うと便利。（日次集計とか） Cloudera Searchで元データにインデックス貼れるぞと。検索しながら分析ができる クラスタ管理とか Cloudera manager便利ですよ ストレージリソースの管理。 声掛け、管理者が容量チェック、Cloudera Managerのレポート 少数精鋭でHadoop使おう＝手が回らなくなる。 みんなで使おう＝Kerberos認証とか管理をちゃんと考えないと。けど、文化が根付けば強力。Sentry、Cloudera Navigatorとか。 Hadoopシステムの全体構成図。データの流れと各製品のつながり。 We are hiring!ということで、興味のある方は@shiumachiさんにコンタクトをとりましょうとのこと。 SQLで実現するバッチ処理とストリーム処理 LINE株式会社　田籠 聡氏 資料：Batch and Stream processing with SQL\nLINEのキャラがちらほら出てきた。\nSQL好きですか？\nログの量とか。2.1TB/Day\nバッチ処理とストリーム\n速い集計のためにHadoopが重要 エラー系のログとかはストリームで処理したい\nアーキテクチャ説明\nデータ解析する人って色々。\n管理者 プログラマ サービスディレクタ 経営陣 みんなが集計用処理を理解、編集ができるほうがいい。\n顔あげたらHiveアイコンだらけだったｗ\nShibとか。\nなんでHiveに限るの？\nHiveに着目したバージョンアップだけを考えれば良くなる。 スケジュールクエリが増えてきて、つらい。\nTimeWindowを固定して集計処理をすることで、回避できる。 Norikra!! スキーマレス\nOSS。Esperベース。\nインストールが楽\nクエリの動作のお話。\nhttp://norikra.github.io\nWe Are Hiring!\nHadoop コミュニティと YARN の現状 日本電信電話株式会社　小沢 健史氏 なんでHadoop？ PostgreSQLでやってたけど、大きなデータにはHadoopを使おうという感じになってきた。 なんで使い分けるの？ スキーマ後付け NTTDocomoのモバイル位置情報の統計処理とか？ 技術的な話をするので、HiveTに着替えます！ｗ YARNのなにが嬉しいの？ ImpalaとMapReduceが同時に動くような環境の時に、リソースをうまく管理できないのがV1 そこでYARN Apache Mesosとだいたい一緒。 Apache MesosとYARNの比較 ","date":1383786660,"dir":"post/2013/","id":"a106d7c1b1b277538367f9c8140e3a75","lang":"ja","lastmod":1383786660,"permalink":"https://blog.johtani.info/blog/2013/11/07/cloudera-world-tokyo-2013/","publishdate":"2013-11-07T10:11:00+09:00","summary":"Cloudera World Tokyo 2013に参加してきました。 午前中はあいにくの雨でしたが、それでも結構な人数が最初の基調講演から参加されてました。 私が参加したセッショ","tags":["Cloudera","Hadoop","Norikra"],"title":"Cloudera World Tokyo 2013に参加しました！ #cwt2013 "},{"contents":"またまた、Riak Meetup Tokyo #3に参加してきました。Riak2.0のYokozunaの話があると聞いたので。\nということで、いつものように個人メモです。\n今日は自重して、懇親会はアルコールなしにしました。思いがけずfluentd＋elasticsearch+kibanaという組み合わせの話も聞けて大満足です。 Yokozunaのデモが見れなかったのがちょっと残念だったかなぁ。\n少しだけSolr本の宣伝もしてきちゃいました。\n古城さん@Mixi 「RiakCSとmixi プライベートクラウド環境」 プライベートクラウドとは？ 計算リソースが安い（ストレージは微妙） 開発者が好きに使える環境＋運用側のチケットに追われる毎日からの開放 Riak CSの概要 S3互換の分散ファイルストレージ 検証とか 検証時はRiak CS 1.3\n5ノードで2Mファイルを40万個\n削除は遅延で削除される\nPUT性能とか。\nRiak CSの死活監視にはRiakのstatsとか\n障害対応とか\nクラスタ クラスタは3つ。ログ、サービス（画像） 、バックアップ保存用 ログの収集にfluentd、解析にelasticsearchやkibanaを使っているらしい。 篠原＠Basho 「Riak 2.0: 分散データ型、セキュリティ、そしてより容易な運用へ」 riak 2.0 pre5をリリース アプリ向け機能強化、運用の容易性 設計ポリシーとか、1.xとか 運用、高可用性、水平拡張性 Capabilityネゴシエーションとか 2.0の機能強化 バケットタイプ キーの名前空間としてバケットがあったけど、同種のバケットをまとめて管理とかしたくなった。 データ型の導入（CRDT） Setデータ型 セキュリティとか 強い整合性\u0026hellip; 鈴木@Basho 「Yokozuna: Riak 2.0の新しい全文検索機能」 YokozunaやSolrの概要 1ノードにRiakとSolrが1プロセスずつ SolrプロセスはRiakが管理してくれる SolrCloudは使ってません。 Riakのノードに届いたデータをSolrに裏で書き込んでくれる。 検索時にはRiakのノードが分散検索をしてくれる X-Riak-Metaもインデクシングしてくれる。jsonやxmlの各要素をSolrのフィールドとして認識してくれる。 Extractor Solrは4.4で、JVMは1.7をユーザが入れるらしい。\n","date":1383746460,"dir":"post/2013/","id":"9dca844d353efed03fbaddfc0fab7c76","lang":"ja","lastmod":1383746460,"permalink":"https://blog.johtani.info/blog/2013/11/06/riak-meetup-tokyo-no3/","publishdate":"2013-11-06T23:01:00+09:00","summary":"またまた、Riak Meetup Tokyo #3に参加してきました。Riak2.0のYokozunaの話があると聞いたので。 ということで、いつものように個人メモで","tags":["Riak","Yokozuna"],"title":"Riak Meetup #3 #riakjp に参加しました。"},{"contents":"開発中ですと書きました、elasticsearch-extended-analyzeですが、改良しました。\n改良と変更は以下のとおりです。\nソースのパッケージをorg.elasticsearchからinfo.johtaniに。MLで気になったので質問したら、変えたほうがいいよとのこと。ダウンロード化については、もう少々お待ちを。 出力形式を変更。可能な限りCharFilter、Tokenizer、TokenFilterそれぞれが出力する内容を返すようにしました。 ただし、既存のAnalyzer（JapaneseAnalyzerクラスとか）に関しては、現時点では出力しません。CharFilterなどを取得するI/Fが見えないためです。（改良できるかの調査は未着手） 現時点でできてないのは以下の項目\npluginコマンドでインストール 出力したいAttributeの指定 TokenizeChainで変更されたTokenの追跡（現状はどのTokenがStopFilterで消されたかなどが不明） 画面の用意（簡単に確認できる画面） ということで、README.mdに出力サンプルは貼り付けてるので、興味のある方は試してみてください。 不明点などあれば、コメントかIssueかツイートでも。\n","date":1383570720,"dir":"post/2013/","id":"b5c628b0c1dbf857a475c4be5de4690d","lang":"ja","lastmod":1383570720,"permalink":"https://blog.johtani.info/blog/2013/11/04/improve-output-extended-analyze/","publishdate":"2013-11-04T22:12:00+09:00","summary":"開発中ですと書きました、elasticsearch-extended-analyzeですが、改良しました。 改良と変更は以下のとおりです。 ソー","tags":["elasticsearch","plugin"],"title":"elasticsearch-extended-analyzeの改良"},{"contents":"お久しぶりです。 気づいたらまた、結構ブログを書いてなかったです。。。\n今回は、今開発しているElasticsearchのプラグインに関するお話です。\nいやぁ、名前決めるの難しいですね。これで英語的に合ってるか不安ですが、elasticsearch-extended-analyzeというプラグインを作っています。\nどんなもの？ Solrの管理画面のanalysisに相当する機能が欲しくて作り始めました。\nElasticsearchにはanalyze APIというAPI（名前あってるのかなぁ?）が存在します。\nこれは、文字列を投げると、指定したアナライザやトークナイザでどのようなトークンに分割されるかを調べることができるAPIです。\n例えば、elasticsearch-analysis-kuromojiをインストールしたElasticsearchに対して、以下のcurlコマンドを実行します。\ncurl -XPOST \u0026#39;localhost:9200/_analyze?tokenizer=kuromoji_tokenizer\u0026amp;filters=kuromoji_baseform\u0026amp;pretty\u0026#39; -d \u0026#39;寿司が美味しい\u0026#39; すると、トークナイズされた結果が次のようなJSONで返ってきます。\n{ \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;寿司\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 2, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 1 }, { \u0026#34;token\u0026#34; : \u0026#34;が\u0026#34;, \u0026#34;start_offset\u0026#34; : 2, \u0026#34;end_offset\u0026#34; : 3, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 2 }, { \u0026#34;token\u0026#34; : \u0026#34;美味しい\u0026#34;, \u0026#34;start_offset\u0026#34; : 3, \u0026#34;end_offset\u0026#34; : 7, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 3 } ] } トークナイズの結果がわかるのは嬉しいのですが、どんな品詞なのかといったKuromoji固有のTokenの属性情報がなくなってしまいます。\nSolrでは、こんな画面が用意されていて、品詞情報とかが出力されます。あとは、各TokenFilterでどのトークンがなくなっているかなどもわかるようになっています。\nこれって結構役立つと思うんですよ。 ということで、Pluginも作ってみたかったので、いい機会だから作ってみようかと。\n出力サンプル まずは、その他のAttribute（品詞とか）を表示するところを実装してみました。\ncurl -XPOST \u0026#39;localhost:9200/_extended_analyze?tokenizer=kuromoji_tokenizer\u0026amp;filters=kuromoji_baseform\u0026amp;pretty\u0026#39; -d \u0026#39;寿司が美味しい\u0026#39; 先ほどとほぼ一緒のcurlコマンドを実行します。違う点は**「_analyze」が「_extended_analyze」**となっている点です。\nで、実行結果はこんな感じです。（長いですがそのまま載せてます。続きの文章がしたにあります。）\n{ \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;寿司\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 2, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 1, \u0026#34;extended_attributes\u0026#34; : [ { \u0026#34;org.apache.lucene.analysis.tokenattributes.TermToBytesRefAttribute#bytes\u0026#34; : \u0026#34;[e5 af bf e5 8f b8]\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.PositionLengthAttribute#positionLength\u0026#34; : 1 }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.BaseFormAttribute#baseForm\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech\u0026#34; : \u0026#34;名詞-一般\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech (en)\u0026#34; : \u0026#34;noun-common\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading\u0026#34; : \u0026#34;スシ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading (en)\u0026#34; : \u0026#34;sushi\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation\u0026#34; : \u0026#34;スシ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation (en)\u0026#34; : \u0026#34;sushi\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType (en)\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm (en)\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.KeywordAttribute#keyword\u0026#34; : false } ] }, { \u0026#34;token\u0026#34; : \u0026#34;が\u0026#34;, \u0026#34;start_offset\u0026#34; : 2, \u0026#34;end_offset\u0026#34; : 3, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 2, \u0026#34;extended_attributes\u0026#34; : [ { \u0026#34;org.apache.lucene.analysis.tokenattributes.TermToBytesRefAttribute#bytes\u0026#34; : \u0026#34;[e3 81 8c]\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.PositionLengthAttribute#positionLength\u0026#34; : 1 }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.BaseFormAttribute#baseForm\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech\u0026#34; : \u0026#34;助詞-格助詞-一般\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech (en)\u0026#34; : \u0026#34;particle-case-misc\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading\u0026#34; : \u0026#34;ガ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading (en)\u0026#34; : \u0026#34;ga\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation\u0026#34; : \u0026#34;ガ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation (en)\u0026#34; : \u0026#34;ga\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType (en)\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm (en)\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.KeywordAttribute#keyword\u0026#34; : false } ] }, { \u0026#34;token\u0026#34; : \u0026#34;美味しい\u0026#34;, \u0026#34;start_offset\u0026#34; : 3, \u0026#34;end_offset\u0026#34; : 7, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 3, \u0026#34;extended_attributes\u0026#34; : [ { \u0026#34;org.apache.lucene.analysis.tokenattributes.TermToBytesRefAttribute#bytes\u0026#34; : \u0026#34;[e7 be 8e e5 91 b3 e3 81 97 e3 81 84]\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.PositionLengthAttribute#positionLength\u0026#34; : 1 }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.BaseFormAttribute#baseForm\u0026#34; : null }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech\u0026#34; : \u0026#34;形容詞-自立\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.PartOfSpeechAttribute#partOfSpeech (en)\u0026#34; : \u0026#34;adjective-main\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading\u0026#34; : \u0026#34;オイシイ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#reading (en)\u0026#34; : \u0026#34;oishii\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation\u0026#34; : \u0026#34;オイシイ\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.ReadingAttribute#pronunciation (en)\u0026#34; : \u0026#34;oishii\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType\u0026#34; : \u0026#34;形容詞・イ段\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionType (en)\u0026#34; : \u0026#34;adj-group-i\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm\u0026#34; : \u0026#34;基本形\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.ja.tokenattributes.InflectionAttribute#inflectionForm (en)\u0026#34; : \u0026#34;base\u0026#34; }, { \u0026#34;org.apache.lucene.analysis.tokenattributes.KeywordAttribute#keyword\u0026#34; : false } ] } ] } 先ほどの結果に**「extended_attributes」**という配列のオブジェクトが追加された形になっています。 ちょっと長くなってしまいましたが。。。\nSolrの処理を真似して作ったので大したことはやってないんですが、少しは便利になるかもなぁと。\n現時点では、最終的な結果しか取得できないですが、今後は次のような機能を作っていこうかと思っています。 できるかどうかは、やってみてって感じですが。\npluginコマンドでインストール pom.xmlはありますが、まだMavenとかに登録はされていません。ですので、mvn packageしてからjarファイルをpluginsフォルダに配置しないといけません。pluginコマンドでインストールできるともっと使ってもらえるはず？ 出力したいAttributeの指定 リクエストパラメータで、出力したいAttribute名を指定するとか。 出力形式の変更 今は、Solrの真似をしていますが、せっかくJSONだったりするので、もう少し検討しようかと（同じAttributeの異なる値も1オブジェクトとして出力されてる） TokenizeChainの出力 Solr同様、CharFilter、Tokenizer、TokenFilterが動作して、最終的なTokenがインデックスに登録されます。ですので、各処理の直後のTokenがどうなっているかもわかったほうが嬉しいと思うので、それらも取得できるようにしたいなぁと 画面の用意 せっかくプラグインなんだし、画面で見れると嬉しいかなと。これは当分先になっちゃうと思いますが、Webページで確認できるような画面を作ると確認しやすくなるかなぁと。上記対応が終わってから取替かかると思いますが。 とりあえず、思いつくのはこんなかんじです。\nElasticsearchの_analyze APIを真似しただけのコードだし、テストも実装もまだまだですが、とりあえず公開してみました。\n要望などあれば、コメント、Issue、ツイート（もちろん、テストコードなども！）なんでも受け付けてますので、お気軽に。\n","date":1382695560,"dir":"post/2013/","id":"0302e8a57a5e8604342a925b2dc60737","lang":"ja","lastmod":1382695560,"permalink":"https://blog.johtani.info/blog/2013/10/25/developing-es-extended-analyze-plugin/","publishdate":"2013-10-25T19:06:00+09:00","summary":"お久しぶりです。 気づいたらまた、結構ブログを書いてなかったです。。。 今回は、今開発しているElasticsearchのプラグインに関するお話","tags":["elasticsearch","plugin"],"title":"elasticsearch-extended-analyzeプラグインを開発中"},{"contents":"不定期開催ですが第12回Solr勉強会を主催しました。\n今回は、前回ほどの過熱ぶりでは無かったですが、70人ほどの参加者の方がいらっしゃったかと。 ありがとうございます！\n今回は聞きたかったYokozunaの話をしてもらいました。あと、リベンジManifoldCF。 一部、追記しました。Bashoさんからツッコミがあったので。あと、4.5.1の話とか。\nManifoldCFのとSolrの組み合わせ（仮）株式会社 ロンウイット　大須賀　稔さん 前回お休みだったのでリベンジですw。\n英語だ。。。やっぱ英語がいいですか、スライド。。。\nManifoldCFの概要から。 最新版は1.3です。色々サポートしてるなぁ。\nデモもありました。（やっぱりちゃんと動かないので、鬼門みたいですが）\nデモ ManifoldCFのGUIで操作しながら。 いまいちちゃんと動かなかった。。。\nQA Q:Zipはうまく動かなかった A:Solr側で処理してくれてる。 Q:Notes対応するの？ A:いまのところない。 Q:ExcelとかPDFはTika？ A:Tika次第です。 Q:認証周りどこから取ってくるの？ A:クローラ側にはなくて、SharePointとかの権限をみてる。 Q:Web系の認証は？ A:まだないのでは。。。（調査します） あー、デモの続き忘れてましたね。。。\nSolrを組み込んだRiak 2.0の全文検索機能 -Yokozuna- Bashoジャパン株式会社　鈴木　一弘さん Riak色々使われてるよ！アングリーバードとか、Y!とか。 Riakで提供されている1機能としてのYokozuna。単独製品ではないですよと。\nRiakの説明。スケールするよ、いつでもRead/Writeできるよ、運用にフォーカスしてるよと。 マスターレスですよ。 Riak2.0のリリースは2013年末。Yokozunaもかな？\nダイナミックフィールド使ってるので、Yokozunaをonにするだけで簡単に使えるよ。\nRiakがSolrのプロセスを管理。\nインデックスの不整合の検知とかってどうやってるのかなぁ？ インデックス比較用のハッシュツリーをノード間でコピーしつつ検査してる。（Active Anti-Entropy）\n(デモには魔物がいるようだ。。。)\nQA Q:JSONの属性を元にしてフィールドにインデックス可能か？ A:可能です。IIJさんの発表で話が出ます。 Q:ProtocolBufferでSolrにアクセス可能？ A:そのうちできそうです。リリース時にはできるようになっています。 Q:コアのスワップは？スキーマの変更は？ A:事前に設定するのは可能。 Q:RiakのデータとSolrでデータがずれるってのはあるの？ A:可能性はありますが、極力ずれAAEで修復。 Q:復旧中のインデックスにアクセスが行かないようにする仕組みなどはある？ A:今はないです。 Yokozuna ベンチマークしました　株式会社インターネットイニシアティブ　曽我部　崇さん、田中 義久さん いいとこ取りで楽だなぁと。いうことで、試してみてます。 デモが動いてる。\nextractorでXMLやJSONをパースできる。 ベンチマーク結果。\nRiak Meetup Tokyo #2の時のQAも入ってるので助かります。素晴らしい。\nQA Q:スナップショットは両方取れるの？ A:Riakは取れますが、インデックスは今は無理です。 フォロー:0.8はYokozunaにボトルネックがあったので、0.9以降だともっと性能が出るはずですとのこと。また次回とかに発表してもらうのもありですかねぇ。 Solr 4.5の新機能など @johtani 発表資料のPDFです。\nツイート見てて誤解を招いたなと思ったのですが、7u40は4.5限定ではなく、すべてのバージョンと考えてください。 チケットを見ると分かりますが、影響バージョンの記載はありません。\n※あ、4.5のChangesを紹介しましたが、4.5.1が出るかも。このへんが困ってるらしいです。\nSOLR-5306: can not create collection when have over one config SOLR-5317: CoreAdmin API is not persisting data properly LUCENE-5263: Deletes may be silently lost if an IOException is hit and later not hit (e.g., disk fills up and then frees up) LT @haruyama さん 資料：http://haruyama.github.io/solr_20131009/#(1)\n記号が捨てられるTokenizer困るので、捨てないのを作ってみました。\nKuromojiの困ったこと。全角数字を分解しちゃう。→MappingCharFilterFactoryで全角から半角にしましょう。 lucene-gosenデフォで半角記号が未知語になってしまい、半角カナと混ざるので、記号を全角にしましょう。\n","date":1381372500,"dir":"post/2013/","id":"76e127a44931bfefab991be3dd7a08b7","lang":"ja","lastmod":1381372500,"permalink":"https://blog.johtani.info/blog/2013/10/10/solr-meetup-memo/","publishdate":"2013-10-10T11:35:00+09:00","summary":"不定期開催ですが第12回Solr勉強会を主催しました。 今回は、前回ほどの過熱ぶりでは無かったですが、70人ほどの参加者の方がいらっしゃったか","tags":["Solr","Riak","Yokozuna","ManifoldCF"],"title":"第12回Solr勉強会を主催しました。#SolrJP"},{"contents":"今日は、ElasticSearchのMLで見つけたelasticsearch-inquisitorプラグインの紹介です。\nElasticSearchはREST API形式で簡単にコマンドラインからいろいろな処理を実行できて便利ですが、 GUIがあったほうが楽なこともまた事実です。 今回紹介する、inquisitorプラグインもSiteプラグイン（Webブラウザでアクセスできるプラグイン）の1つです。 （ただし、ローカルにインストールしてローカルのElasticSearchにしか接続できませんが。。。）\nインストール プラグインですので、以下のコマンドでインストールが出来ます。インストール後はElasticSearchの再起動が必要です。\nbin/plugin -install polyfractal/elasticsearch-inquisitor ElasticSearch再起動後に、以下のURLにアクセスすればOKです。 ※ローカルでのみ動作可能なプラグインです。（内部で呼び出しているJSにlocalhostと記載があるため）\nhttp://localhost:9200/_plugin/inquisitor/#/ 何ができるの？ 自分の書いたQueryが正しく動作するかや、Analyzerによって文章がどのように、Term（Token）に分割されるかといった挙動をWebブラウザ上で確認することができます。用意されている画面は「Queries」「Analyzers」「Tokenizers」の3種類です。\nQueries クエリの確認、実行が可能な画面です。\n「Index」「Type」はプルダウンになっており、現在ElasticSearchに存在しているものが選択可能です。 その下のテキストエリアがクエリを入力する画面です。\nクエリを入力していると、入力しているクエリがValidかどうかをクエリのコンソール部分（右側上部）に表示してくれます。\n少し残念なことに、Tabを押すと、フォームのフォーカスが切り替わってしまうので、クエリを入力するのがちょっと面倒です。。。（私は通常の検索には、ChromeプラグインのSenseというものを利用してます。）\nクエリに問題がない場合は、「Query」ボタンを押すことで実際の検索が実行されます。 この時、画面真ん中のブルーのテーブル（内部で実行されるクエリ）の部分に、QueryがElasticSearch内部で解釈されたあとの、Luceneで実行されるレベルのクエリに変換されたクエリが表示されます。\nこれが便利です。JSONで記述したり、色々なタイプのクエリがElasticSearchでは実行できますが、望んだ形に単語が区切られているかなどを確認することができるため、非常に便利です。\nElasticSearchのQuery DSLではexplainをtrueにすることで、ヒットしたドキュメントのスコア計算に用いられた単語などがわかるのですが、そもそもヒットしないクエリの場合は、explainでは単語の区切られ方などがわかりません。\nその場合に、このプラグインで確認すると、想定と違う単語の区切られ方やクエリの造られ方がわかるかと思います。\nAnalyzers Analyzerによる文章のアナライズ結果の確認が出来る画面です。 ElasticSearchやSolrにあまり詳しくない場合、どんなAnalyzerが文章をどのように単語に区切って、転置インデックスのキーワードとして利用しているかがわからないと思います。\nこのAnalyzerが文章をどのように単語に区切っているかを確認することができるのがAnalyzers画面です。 こんなかんじの画面になります。\n一番上のテキストエリアが文章を入力する場所です。 文章を入力していくと、その下のテーブルの「Analyzed Text」の部分が変化していくのが分かります。 このグレーの単語が転置インデックスのキーワードとなります。\n予め用意されているAnalyzer以外に、用意されているTokenzier＋Filterの組み合わせも簡単ですが確認可能です。（Tokenizer、Filtersとあるテーブル） ただし、ここまでのどちらも細かな設定は画面上ではできません（Filterの細かな引数の指定など）\n一番下の部分が、ElasticSearchに存在しているインデックスごとに定義されたAnalyzerやフィールドを元にした解析結果を表示することができる領域です。\n自分でマッピングを記述してフィールド定義したものの動作確認や、インデックスを適当に作ったけど、うまくヒットしない場合など、ここで、単語の区切れ方を確認することで、検索になぜヒットしないのかといった問題のヒントを得ることができると思います。\nAnalyzerによっては、インデックス対象の文字として扱わない文字があったりしますので。 先ほどのQueries画面のLuceneに投げられる直前のクエリと、Analyzersでの単語の区切られ方を確認することで、検索がうまくヒットしていないことが判明すると思います。\nTokenizers 最後はTokenizers画面です。Analyzersとほぼ同様ですが、ちがいは、デフォルトで用意されているTokenizerの挙動の確認ができるというだけになります。\n簡単な確認ならここで可能かと。\n注意点は？ まだ開発途中のようで、つぎの部分が課題かと。\nローカルでのみ実行可能 Queries画面の結果の「Explain Result」リンクが未実装 Queries画面のクエリ入力が使いにくい（タブが打てないので） カスタム登録のAnalyzersはインデックスを用意しないと確認できない。（Kuromojiのプラグインを登録しただけでは確認できなかった） 細かな設定のフィールドも用意しないと、Analyzers画面では利用できない まとめ ということで、Inquisitor（読みがわからない）プラグインの簡単な説明でした。 検索にうまくヒットしないという理由は大体の場合、 クエリに入力した文字列が単語に区切られたものと、登録したデータが単語に区切られたものが異なるために検索にヒットしないというものです。\nそのクエリ、データの単語の区切られ方を確認するのに役に立つプラグインじゃないでしょうか。\nちなみに、このプラグイン自体はHTML＋JSで作成されており、実際にはElasticSearchが持っているREST APIをキックしているだけになります。 ですので、Web画面なんか要らないという方は、このプラグインが実際に送信しているリクエストを参考にするとcurlコマンドでどういったリクエストを投げればいいかというのがわかると思います。\n私は軟弱者なので画面があったほうがいいですが。\n","date":1379906820,"dir":"post/2013/","id":"e1870dde155be1a375f155dd1f7ead13","lang":"ja","lastmod":1379906820,"permalink":"https://blog.johtani.info/blog/2013/09/23/intro-elasticsearch-inquisitor/","publishdate":"2013-09-23T12:27:00+09:00","summary":"今日は、ElasticSearchのMLで見つけたelasticsearch-inquisitorプラグインの紹介です。 ElasticSea","tags":["elasticsearch","plugin"],"title":"elasticsearch-inquisitorプラグインの紹介"},{"contents":"river-wikipediaの前々回の記事で書きましたが、bulk_sizeに関連して登録件数がやけにきりが良いのが気になると書いていました。\nで、Riverの仕組みを勉强がてら、elasticsearch-river-wikipediaのソース（1.2.0）を読んでみました。\nRiverの作り Riverはorg.elasticsearch.river.Riverというinterfaceを実装することで作らています。 ただ、Riverがinterfaceとなっていますが、o.e.river.AbstractRiverComponentというクラスを継承して作られています。\nAbstractRiverComponentにはRiverの名前や設定などが用意されています。 ま、ここはそれほど重要じゃないので、軽く流してと。\nRiverの設定関連は実装したRiverクラス（ここでは、WikipediaRiverクラス）のコンストラクタで、設定値の読み取りなどの記述を記載します。 このコンストラクタが、_river/hogehoge/_metaをPUTした時のJSONを元にElasticSearchから呼ばれて、Riverのインスタンスが作成されます。（たぶん、このへんがその処理だと思う。。。このあたりはまた今度）\n実際のRiverの処理はWikipediaRiverクラスのstart()メソッド内部に記述されています。\n@Override public void start() { logger.info(\u0026#34;starting wikipedia stream\u0026#34;); try { ① client.admin().indices().prepareCreate(indexName).execute().actionGet(); } catch (Exception e) { if (ExceptionsHelper.unwrapCause(e) instanceof IndexAlreadyExistsException) { // that\u0026#39;s fine } else if (ExceptionsHelper.unwrapCause(e) instanceof ClusterBlockException) { // ok, not recovered yet..., lets start indexing and hope we recover by the first bulk // TODO: a smarter logic can be to register for cluster event listener here, and only start sampling when the block is removed... } else { logger.warn(\u0026#34;failed to create index [{}], disabling river...\u0026#34;, e, indexName); return; } } ② currentRequest = client.prepareBulk(); ③ WikiXMLParser parser = WikiXMLParserFactory.getSAXParser(url); try { ④ parser.setPageCallback(new PageCallback()); } catch (Exception e) { logger.error(\u0026#34;failed to create parser\u0026#34;, e); return; } ⑤ thread = EsExecutors.daemonThreadFactory(settings.globalSettings(), \u0026#34;wikipedia_slurper\u0026#34;).newThread(new Parser(parser)); thread.start(); } 内部では\nインデックスの作成 バルクアップデート用クライアントの設定 WikiXMLのパーサの初期化 ページごとにキックされるコールバック処理の登録 デーモンスレッドの起動と起動 といった処理の流れになっています。\nで、このスレッドの起動後は、4.で用意したparser.parse()処理がグルグル回ります。\n1ページがパースされるたびに、WikipediaRiver.PageCallbackクラスのproess()メソッドが呼ばれます。 このメソッドの最後で、processBulkIfNeeded()メソッドが呼ばれています。ここで、実際にパースしたページをインデックスに登録する処理が実行されます。\nこのメソッドの1行目が鍵でした。 bulkSize以上の件数がバルクのリクエストに貯まった時だけ、実際にインデックスに登録する処理が実行されます。 このため、スレッドが回っている間は、bulkSize以上のデータが貯まらないと、インデックスへの登録は行われないわけです。\n次に、このスレッドを止めるには、前々回書いたように、_riverにPUTした、Riverの設定をDELETEするしかありません。（あとは、ElasticSearchを停止するとかでしょうか。）\nで、DELETEが実行される呼ばれるのが、WikipediaRiverクラスのclose()メソッドです。\n@Override public void close() { logger.info(\u0026#34;closing wikipedia river\u0026#34;); closed = true; if (thread != null) { thread.interrupt(); } } 見ていただくと分かりますが、スレッド止めて終了です。\n問題点は？ ということで、\nWikipediaのXMLを読み込んでもRiverは停止しない Riverの停止を行ってもスレッドが止められるだけ。 bulkSize以下の件数がcurrentRequestに残っているけど、破棄される とまぁ、こんな流れになっているので、最後の端数のドキュメントがインデックスに登録されないようです。 （まだ、ちゃんと確認してないんですが、備忘録のため先に書いちゃいました。。。）\nじゃあ、全部うまく登録するにはどうしたもんかなぁと。 いまのところ思いついたのはこんな感じです。 他にいい案があったら教えて下さい。\n案１：close()処理の中で、スレッド停止後に、currentRequestに貯まっているデータをインデックスに登録しちゃう 案２：bulkSize以外に、定期的（指定された時間）で登録処理を実行してしまう。 簡単なのでとりあえず、案１を実装してみるかなぁと。 （さっさとコード書けよって話ですね。。。スミマセン） その前にMLで質問ですかねぇ、英語で。\nWikipediaのRiverをざっと眺めてみた感じですが、わかりやすい作りだなぁと。 他のRiverがどうなってるかをちゃんと見てませんが、他にもbulkSize指定をするRiverの場合は、このように件数がbulkSizeに満たない状態ではデータが登録されないといったことがあるかもしれません。\nElasticSearchのソースを読み始める取っ掛かりとしては面白いかと思いますので、興味ある方は読んで作ってみるといいかもしれません。（私は読んだだけですがｗ）\n追記（2013/09/13 21:00） MLで質問してみました。とりあえず、案1を。\nriver-wikipedia does not index all pages\n他のRiverでは対応してるしバグだね、Issue上げてとのことで、あげときました。 ついでにプルリクも出せばいいんでしょうが、プルリクまだやったことないヘタレです。。。\nあと、案2についても同じトピックで質問してます。 どうやら、BulkProcessorにその機能があるよと。 flushintervalというプロパティがありそうです。どうやって設定して、どうやって動くのかとか見てないので、 調査してブログorLTかな。\nbulk udpにはその値を設定できそうなのがあるんだよなぁ。\n追記その２（2013/09/16 23:50） さっそく修正版がコミット(コミットログ)されてました。 結構変わってます。BulkProcessorにflush_intervalの設定をすれば、よしなにやってくれる仕組みがすでに実装されているようです。 bulkSizeについても同様に、BulkProcessorに設定すれば良いようです。 Riverの仕組みが結構スッキリしています。 もともと実装されていた、bulkSizeごとの処理も消されています。 確かに、BulkProcessorの仕組みとして実装されている方がしっくりきますね。\nということで、考える暇もなくコミットされてしまいました。 こうやって質問しつつ、少しずつソースを読んでいこうかなと思ってるとこです。\n","date":1378921080,"dir":"post/2013/","id":"d2e805472f79f0b558f75b90b5e7b4ee","lang":"ja","lastmod":1378921080,"permalink":"https://blog.johtani.info/blog/2013/09/12/question-river-wikipedia/","publishdate":"2013-09-12T02:38:00+09:00","summary":"river-wikipediaの前々回の記事で書きましたが、bulk_sizeに関連して登録件数がやけにきりが良いのが気になると書いていまし","tags":["elasticsearch","wikipedia"],"title":"elasticsearch-river-wikipediaの疑問点"},{"contents":"前々回紹介した、日本語Wikipediaのデータをインデックス登録する記事の続きです。\n今回は、Kuromojiのアナライザを利用してインデックス登録してみます。\n余談（Proxy環境でのプラグインインストール） ElasticSearchのpluginコマンドはJavaで実装されています。（org.elasticsearch.plugins.PluginManager） プラグインのダウンロードには、java.net.URL.openConnection()から取得URLConnectionを使用しています。\nですので、pluginのインストールを行う際に、Proxy環境にある場合は以下のようにコマンドを実行します。\n./bin/plugin -DproxyPort=ポート番号 -DproxyHost=ホスト名 -i elasticsearch/elasticsearch-analysis-kuromoji/1.5.0 elasticsearch-analysis-kuromojiのインストール WikipediaのデータをKuromojiを使って、形態素解析ベースの転置インデックスを作成していきます。 まずは、Kuromojiを利用するために、Analysisプラグインのインストールです。 ElasticSearchのバージョンに対応したプラグインのバージョンがあります。（プラグインのページに対応したバージョンの記載あり） 今回はElasticSearchの0.90.3を利用しているため、1.5.0をインストールします。\n./bin/plugin -i elasticsearch/elasticsearch-analysis-kuromoji/1.5.0 インストール後は再起動しておきます。 なお、Kuromojiを利用して、Wikipediaのデータを登録するばあい、デフォルトの設定では、ヒープが足りなくなるおそれがあります。 ElasticSearchの起動時に以下のオプションを指定して、最大ヒープサイズを2Gとしておきます。\nexport ES_HEAP_SIZE=2g;./bin/elasticsearch Indexの作成（デフォルトでKuromojiのAnalyzerを利用する） Wikipediaのデータを登録する際に、Kuromojiのアナライザを利用したいのが今回の趣旨でした。 一番ラクな方法として、Wikipediaデータのインデックスの設定として、デフォルトのアナライザをKuromojiにしてしまいます。 （きちんと設計する場合は、必要に応じてフィールドごとに指定しましょう）\ncurl -XPUT \u0026#39;localhost:9200/ja-wikipedia-kuromoji\u0026#39; -d \u0026#39;{ \u0026#34;settings\u0026#34;: { \u0026#34;analysis\u0026#34;: { \u0026#34;analyzer\u0026#34;: { \u0026#34;default\u0026#34; : { \u0026#34;type\u0026#34; : \u0026#34;kuromoji\u0026#34; } } } } }\u0026#39; これでkuromojiのアナライザがデフォルトで利用される形となります。 あとは、Riverを起動して登録するだけです。\nRiverの実行 前回と一緒です。 インデックス名（_river/\u0026lt;インデックス名\u0026gt;/_meta）だけは、先ほど作成した「ja-wikipedia-kuromoji」に変更してください。\ncurl -XPUT localhost:9200/_river/ja-wikipedia-kuromoji/_meta -d \u0026#39; { \u0026#34;type\u0026#34; : \u0026#34;wikipedia\u0026#34;, \u0026#34;wikipedia\u0026#34; : { \u0026#34;url\u0026#34; : \u0026#34;file:/home/johtani/src/jawiki-latest-pages-articles.xml\u0026#34; }, \u0026#34;index\u0026#34; : { \u0026#34;bulk_size\u0026#34; : 10000 } }\u0026#39; あとは、インデックスされるのを待つだけです。\nデータ量とか 5.8gbになりました。Kuromojiを利用したため、形態素解析により単語にきちんとトークないずされた結果でしょう。 Uni-gramだと、転置インデックスのボキャブラリも単語に対してヒットするドキュメント数も大きくなるため、 インデックスサイズも大きくなっているのかと。\n検索クエリのサンプルなどはまた後日。（夜遅いので。。。）\n","date":1378138500,"dir":"post/2013/","id":"79e647a3f8b36a1221897f5837c84aff","lang":"ja","lastmod":1378138500,"permalink":"https://blog.johtani.info/blog/2013/09/03/ja-wikipedia-with-kuromoji/","publishdate":"2013-09-03T01:15:00+09:00","summary":"前々回紹介した、日本語Wikipediaのデータをインデックス登録する記事の続きです。 今回は、Kuromojiのアナライザを利用してインデッ","tags":["elasticsearch","kuromoji","wikipedia"],"title":"日本語Wikipediaをインデクシング（Kuromojiバージョン）"},{"contents":"ElasticSearch勉強会 第1回を主催しました。 昨年のpyfesでなんちゃって資料で喋って、1年たちました。\nElasticSearchの書籍（英語）も出てきて、今年はElasticSearchが面白くなりそうだし、使ってる人たちから話も聞きたいなぁということで、主催しました。\n思った以上に興味のある方がいらっしゃったようで、100人応募のところ、チケットがすぐ完売してしまうほど。。。 しかも、当日もほぼ満員ということで、大変な盛況ぶりでした。\nスピーカーの皆様、参加された皆様、会場を提供していただいたリクルートテクノロジーズさん、ありがとうございました！（たぶん、90人くらいいらっしゃってたかと。）\nこんなステキな案内板も用意してもらいました。スタッフのみなさんありがとうございます！ トゥギャっても頂きました。まとめていただいてありがとうございます！\n自分の発表や個々の発表に関する感想は以下のメモに。\nElasticSearch入門 @johtani スライド：ElasticSearch入門※スライドはPDFです。\n緊張しまくりでわかりにくかったですかね。。。 とりあえず、AWSのサービスじゃないってのだけでも覚えて帰っていただければ満足です。 途中で見せたChromeプラグインのSense わからなかった点や質問、ご意見などは、当ブログのコメント、私宛の＠ツイート、なんでもいいので、反応ください。なんでもいいので反応があると、今後の励みになりますので！ ということで、発表でも言いましたが、わからないことがアレば、@johtaniまで投げてもらえれば、「知らない」「ブログのネタにします」「ソレはこんなかんじですかねぇ？（テキトー）」みたいに答えると思います。 Elasticsearch in Actionは帰宅中に、4章追加されたよというメールが届きました。 宿題 クラスタへのノードの追加の処理方法とか、シャーディングの実装とか。 elasticsearchプラグイン入門 ～ mocksolrpluginでSolrと入れ替えてみよう 菅谷さん スライド：elasticsearchプラグイン入門　slideshare\nプラグイン構成とか（公式でまとまってるの見つけられないので助かります。） 作る上でのポイントうれしいです。 パッケージ名変えられるとか、つらい。。。 Solr APIプラグインについて（Solrの振りしてくれる便利なヤツ） 感想 まだ、プラグインを書いたことがないのですが、ちゃんとプラグインはどういう構成で書くんですよというまとまった資料って本家のサイトにもない気がしています。 なので、スライドが公開されたらすごく役に立つかと。 そのまえに、何かプラグイン書いてみます。。。\nDebugging and testing ES systems Chris Birchallさん スライド：Debugging and testing ES systems　slideshare\nテストの方法とか便利なお話（最後のほうしか聞いてなかったですが。。。。） クエリのデバッグは色々とやらないと、なんでヒットしないのってよくあるので。とくに形態素解析を利用した検索の場合、短い文章（クエリ）と長い文章（ドキュメント）で切れ目が変わってうまくヒットしないとかありますよね。 最後に少しだけ話しましたが、n-gramとKuromojiを組み合わせてOR検索とかすると良い場合があります。 インデックスが大きくなったり、OR検索なので遅くなったりというデメリットもありますが。 感想 実際に使われているノウハウを元に話をしていただいたので助かりました。 最初に席を外してたのですが、戻ってきて日本語で普通に発表されててほんとにびっくりしましたｗ テスト用プラグインがあるのとかは知らなかったです。 あと、使われてたIDEがIntelliJ IDEAでしたね！私も使ってます！\nニコニコ動画データセット 25億件を検索可能にしてみよう @PENGUINANA_ スライド：ニコニコ動画を検索可能にしてみよう　slideshare\nkibana@cookpadのお話 どういう挙動するかをやってみればいいじゃんってことで、やってみるのカッコイイ！ http://goo.gl/FYtO5T bigdeskとか。プラグインいろいろ。 感想 さすがです、ペンギン先生。大きなデータセットつかって、構築した環境に関する数値も書かれてる資料ができて素晴らしすぎです。 思った以上にサクサク動いてて、4hでインデクシングできるのもすごいなぁと。 私も見習ってこのくらいがサクッとできるようになりたい。。。 あと、発表後にムチャぶりしましたが、次回はぜひ検索側の性能とかも話してもらえたらと。\n反省点 イベントアテンドだと、キャンセル待ちができない＋どのくらいの方が興味をもっているのかわからない。 イベントページの主催者は複数指定できる方がいい。（土壇場の登録の人が管理できない。私が司会やってたから） マイクが聞こえにくかった（音量調節とかちゃんと調べないと） 懇親会は立食のほうがやはり動きやすい。 懇親会が1時間ちょっとしかできなかった 雑感 ということで、ES勉強会、主催の私が一番楽しめました。ありがとうございます。 （あと、気前よく調べて答えますと言ってしまいました。。。まぁ、いいトリガーになるので、ウェルカムですが）\nやっぱりKibanaについて興味を持ってる人も多いのかなぁという感触がしたので、次回はぜひKibana3の話をしてもらえるように頑張ります。 あと、elasticsearch-headを使われてるんだなぁと。私はelasticsearch-HQを入れて使ってみてます。大きなクラスタ管理まではまだやってないので。\nあとは、やはりいろんな人に助けられてるなぁと実感しつつ、今後も開催するので助けてください！ということで。 （もちろん、Solr勉強会もがんばりますよー）\n関連ブログ ElasticSearch勉強会 第1回 - Go ahead! タムタムの日記 - ElasticSearch勉強会 の参加メモ #elasticsearchjp 第1回ElasticSearch勉強会に行ってきた！ #elasticsearchjp - #侍ズム 第1回 ElasticSearch 勉強会に参加 #elasticsearchjp - seratch 他にもブログを書かれた方がいらっしゃいましたたら、リンクしたいので連絡いただければ。\n","date":1377798120,"dir":"post/2013/","id":"5931f8e3acdac724742c4ee0960d8d40","lang":"ja","lastmod":1377798120,"permalink":"https://blog.johtani.info/blog/2013/08/30/hold-first-elasticsearch-meetup-in-japan/","publishdate":"2013-08-30T02:42:00+09:00","summary":"ElasticSearch勉強会 第1回を主催しました。 昨年のpyfesでなんちゃって資料で喋って、1年たちました。 ElasticSearch","tags":["elasticsearch","勉強会"],"title":"第1回ElasticSearch勉強会を開催しました！ #elasticsearchjp"},{"contents":"久々のブログはElasticSearchネタです。勉強会開催する予定だったりすので、もう少し触っておきたいなと。 お手軽に検索するデータとして、よくWikipediaのデータを使っています。 ElasticSearchにはelasticsearch-river-wikipediaという便利なプラグインがあり、Wikipediaのデータを簡単に検索可能な状態にできます。このRiverを利用して日本語のWikipediaのデータを入れたので、メモを取っておきます。 まずは、river-wikipediaで日本語のデータをインデクシングしてみるまでの説明です。 日本語特有の設定（Kuromojiを利用したインデクシング）などはまた後日。\nプラグインのインストール 対象とするElasticSearchは現時点で最新版の0.90.3とします。 最新版でRiver動かないなぁとつぶやいた影響かどうかはわかりませんが、2013/08/19に最新版のElasticSearchで動作するプラグインが公開されました。\nまずはインストールです。 HPにも書いてありますが、以下のコマンドを実行すればインストールされます。\n$ ./bin/plugin -install elasticsearch/elasticsearch-river-wikipedia/1.2.0 -\u0026gt; Installing elasticsearch/elasticsearch-river-wikipedia/1.2.0... Trying http://download.elasticsearch.org/elasticsearch/elasticsearch-river-wikipedia/elasticsearch-river-wikipedia-1.2.0.zip... Downloading ..........DONE Installed river-wikipedia into /opt/elasticsearch/plugins/river-wikipedia ElasticSearchが起動している場合はプラグインをインストール後、認識させるためにElasticSearchを再起動します。\n日本語Wikipediaのインデクシング 通常は英語のWikipediaがインデクシングされますが、対象となるファイルを変更することで日本語のWikipediaもインデクシング可能です。 手元に日本語Wikipediaのダンプファイルがあるものとします。（ダウンロードはWikipediaデータベースダウンロードのページにあるpages-articles.xml.bz2のファイルです）\nファイルを指定してインデクシングするには、つぎのcurlコマンドを実行します。 コマンドを実行するとすぐにインデクシングが始まりますので注意が必要です。\ncurl -XPUT localhost:9200/_river/ja-wikipedia/_meta -d \u0026#39; { \u0026#34;type\u0026#34; : \u0026#34;wikipedia\u0026#34;, \u0026#34;wikipedia\u0026#34; : { \u0026#34;url\u0026#34; : \u0026#34;file:/home/johtani/src/jawiki-latest-pages-articles.xml\u0026#34; }, \u0026#34;index\u0026#34; : { \u0026#34;bulk_size\u0026#34; : 1000 } }\u0026#39; ここでURLに含まれる「ja-wikipedia」がインデックス名になります。 また、JSONの\u0026quot;url\u0026quot;にはファイルの場所を指定するため、file:で開始するパスを指定します。 例では、bz2を解凍したファイルを指定していますが、bz2のままのファイルでもOKです。\n上記コマンドを実行すると、_riverというインデックスにつぎのようなエントリが増えています。 (curl -XGET 'localhost:9200/_river/ja-wikipedia/_search?pretty)\n{ \u0026#34;took\u0026#34;: 5, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 1, \u0026#34;successful\u0026#34;: 1, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 2, \u0026#34;max_score\u0026#34;: 1, \u0026#34;hits\u0026#34;: [ { \u0026#34;_index\u0026#34;: \u0026#34;_river\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;ja-wikipedia\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;_status\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;ok\u0026#34;: true, \u0026#34;node\u0026#34;: { \u0026#34;id\u0026#34;: \u0026#34;gdyvwpiAR52lqUCcRhVwsg\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Blitzschlag, Baron Von\u0026#34;, \u0026#34;transport_address\u0026#34;: \u0026#34;inet[/192.168.100.7:9300]\u0026#34; } } }, { \u0026#34;_index\u0026#34;: \u0026#34;_river\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;ja-wikipedia\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;_meta\u0026#34;, \u0026#34;_score\u0026#34;: 1, \u0026#34;_source\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;wikipedia\u0026#34;, \u0026#34;wikipedia\u0026#34;: { \u0026#34;url\u0026#34;: \u0026#34;file:/home/johtani/src/jawiki-latest-pages-articles.xml\u0026#34; }, \u0026#34;index\u0026#34;: { \u0026#34;bulk_size\u0026#34;: 100 } } } ] } } \u0026quot;_id\u0026quot;: \u0026quot;_meta\u0026quot;というエントリがさきほど登録したWikipediaのRiverに関する設定です。 \u0026quot;_id\u0026quot;: \u0026quot;_status\u0026quot;というエントリが起動したRiverの状態になります。\nRiverの停止 日本語Wikipediaは結構サイズが大きく、手元のAirでインデクシングするのに30分程度かかりました。（bz2圧縮されていないファイルで、何もしていない状態）\n途中でRiverを停止したくなった場合は、以下のcurlコマンドを実行します。\n$ curl -XDELETE \u0026#39;localhost:9200/_river/ja-wikipedia\u0026#39; 先ほど設定した_river/ja-wikipediaの情報を削除すると、エントリが削除されたのを検知してRiverが停止します。ログにはつぎのようなメッセージが表示されます。\n[2013-08-26 18:26:50,130][INFO ][cluster.metadata ] [Blitzschlag, Baron Von] [[_river]] remove_mapping [ja-wikipedia] [2013-08-26 18:26:50,130][INFO ][river.wikipedia ] [Blitzschlag, Baron Von] [wikipedia][ja-wikipedia] closing wikipedia river Riverを停止してもそれまでインデクシングされたデータは検索できます。 データはちょっとだけで良いという場合は、先ほどの_riverのデータを削除してください。 （◯件だけ登録したいとかできるかは調べてないです。）\nサイズとかマッピングとか サイズ インデックス前のXMLのサイズが5.7Gのとき、ElasticSearchのインデックスサイズ（Optimize後）は7.2Gとなりました。すこし古いファイルを利用しているため、最新版とはサイズが異なるかもしれません。\nあと、データ数が、1540000件とやけにきりがいいのがちょっと気になっています。。。 bulkのサイズを10000で指定してインデックスしたので、切れてるのかなぁと。\nということは、データが欠落しているような気がするのでRiverの作りの問題なのか、ElasticSearchの問題なのかはちょっと調べてみないとわからないなと。\nマッピング 出来上がったインデックスのマッピング（Solrでいうスキーマみたいなもの）は次のようになっています。\n{ \u0026#34;ja-wikipedia\u0026#34;: { \u0026#34;page\u0026#34;: { \u0026#34;properties\u0026#34;: { \u0026#34;category\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;disambiguation\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;boolean\u0026#34; }, \u0026#34;link\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;redirect\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;boolean\u0026#34; }, \u0026#34;special\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;boolean\u0026#34; }, \u0026#34;stub\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;boolean\u0026#34; }, \u0026#34;text\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; }, \u0026#34;title\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34; } } } } } Wikipediaの各種データが上記のフィールドに入っています。 また、マッピングタイプはデフォルトで「page」というタイプになっています。\n検索 先ほどのマッピングを元に検索すればOKです。例えばつぎのような感じです。\ncurl -XPOST \u0026#39;localhost:9200/ja-wikipedia/_search?pretty\u0026#39; -d \u0026#39; { \u0026#34;size\u0026#34; : 3, \u0026#34;script_fields\u0026#34;: { \u0026#34;title_only\u0026#34;: { \u0026#34;script\u0026#34;: \u0026#34;_source.title\u0026#34; } }, \u0026#34;query\u0026#34; : { \u0026#34;query_string\u0026#34;: { \u0026#34;default_field\u0026#34;: \u0026#34;title\u0026#34;, \u0026#34;query\u0026#34; : \u0026#34;千葉\u0026#34; } } }\u0026#39; 結果はこんな感じ。\n{ \u0026#34;took\u0026#34;: 51, \u0026#34;timed_out\u0026#34;: false, \u0026#34;_shards\u0026#34;: { \u0026#34;total\u0026#34;: 5, \u0026#34;successful\u0026#34;: 5, \u0026#34;failed\u0026#34;: 0 }, \u0026#34;hits\u0026#34;: { \u0026#34;total\u0026#34;: 8616, \u0026#34;max_score\u0026#34;: 5.8075247, \u0026#34;hits\u0026#34;: [ { \u0026#34;_index\u0026#34;: \u0026#34;ja-wikipedia\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;page\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;3582\u0026#34;, \u0026#34;_score\u0026#34;: 5.8075247, \u0026#34;fields\u0026#34;: { \u0026#34;title_only\u0026#34;: \u0026#34;千葉\u0026#34; } }, { \u0026#34;_index\u0026#34;: \u0026#34;ja-wikipedia\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;page\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;2352241\u0026#34;, \u0026#34;_score\u0026#34;: 4.94406, \u0026#34;fields\u0026#34;: { \u0026#34;title_only\u0026#34;: \u0026#34;千葉千枝子\u0026#34; } }, { \u0026#34;_index\u0026#34;: \u0026#34;ja-wikipedia\u0026#34;, \u0026#34;_type\u0026#34;: \u0026#34;page\u0026#34;, \u0026#34;_id\u0026#34;: \u0026#34;14020\u0026#34;, \u0026#34;_score\u0026#34;: 4.8754807, \u0026#34;fields\u0026#34;: { \u0026#34;title_only\u0026#34;: \u0026#34;千葉千恵巳\u0026#34; } } ] } } 結果を見やすくするため、タイトルだけを「title_only」という表示にしています。 ただ、この検索だと、一見「千葉」できちんとヒットしているように見えますが、ElasticSearchのフィールドの定義はstring型になっています。なので、実は「千」や「葉」だけのデータもヒットしています。 マルチバイト文字は1文字ずつインデックスされてしまい、query_stringというクエリでは、フレーズ検索などができていないためです。\nまとめ プラグインいれて、XMLファイルがあれば、検索できるデータが出来上がるので、 暇があったら、お試しで触ってみるデータを簡単に入れてみてはどうでしょうか。\nただ、いくつか気になる点も。\n日本語が検索しにくい（string型のフィールドなのでuni-gramっぽくなっている） bulk_sizeの影響で端数が登録できてない（バグ？どうなの？） ということで、ちょっと使いにくいかもなぁということで、つぎはKuromojiを利用してインデックスしてみてみようかなと。次回のエントリで書く予定です。\n","date":1377226920,"dir":"post/2013/","id":"3931327ed463d1568868c5ab8e839148","lang":"ja","lastmod":1377226920,"permalink":"https://blog.johtani.info/blog/2013/08/23/index-wikipedia-ja-to-elasticsearch/","publishdate":"2013-08-23T12:02:00+09:00","summary":"久々のブログはElasticSearchネタです。勉強会開催する予定だったりすので、もう少し触っておきたいなと。 お手軽に検索するデータとして","tags":["elasticsearch","wikipedia"],"title":"ElasticSearchにプラグインで日本語Wikipediaデータを入れてみました"},{"contents":"宿題その2？かな。Solr勉強会でCloudera Searchのスキーマ周りってどうなってるの？という質問が出てて、 なんか調べることになってたので、関係しそうなMorphlinesのLoadSolrコマンドを調べてみました。 こいつが、Solrへの書き込みを実行するコマンドみたいだったので。\n（※Cloudera Searchのスキーマの設定方法とかは調べてないです。）\n（※めんどくさかったので、パッケージ名すっ飛ばしてクラス名書いてます。githubへのリンクを代わりに貼ってます。）\nRecord＝Solrのドキュメント convert()メソッドにて、MorphlinesのRecord（コマンドの処理するデータの１単位）に格納されているKey-ValueデータをSolrInputDocumentクラスのフィールドとして格納しています。 Recordにもフィールドという概念があり、Recordのフィールド＝Solrのフィールドという事みたいです。\nということで、Solrのフィールドは事前に定義しておき、Morphlinesの処理内部でSolrのフィールド名に値を詰めていく感じでしょうか。 別途、sanitizeUnknownSolrFildsというコマンドが用意されていて、Solrのスキーマにないものはこのコマンドを使って、無視するフィールド名に変えたり、雑多なデータを入れるためのフィールド名にするといった処理ができるようです。このコマンド内部で、Solrのスキーマ設定を元に、Solrのフィールドに合致する物があるかをチェックして処理しています。\nSolrへの登録処理は？ Solrへの登録処理自体はLoadSolrクラス内部でDocumentLoaderというクラスのload()メソッドを呼び出しているだけでした。ということで、DocumentBuilderクラスを少し調査。\nDocumentLoader IFでした。。。実クラスは次の条件\nSolrMorphlineContextにDocumentLoaderがあればそちらを採用（他の種類はなにがあるんだろ？） なければ、SolrServerDocumentLoaderをnewしたものを利用 2.の場合がおそらくMapReduceではないパターンのloadSolrだと思われます。SolrServerDocumentBuilderはSolrJのAPIを利用して、Solrへデータ登録していく普通のアプリです。（対象とするSolrは外部に起動しているもののはず＝FlumeのSolrSinkではこちらを採用かな？）\nSolrへの接続情報とか設定ファイルとかSolrCloud用のZooKeeperとかはSolrLocatorクラスに設定される内容が利用されます。\n1.のパターンは、どうやら、Cloudera SearchのMapReduceIndexerToolのクラスにあるMyDocumentLoaderかなぁと。 こちらは、MapReduceを利用する場合に、利用されてるっぽいです（ちゃんと見てないけど） 内部処理は、HadoopのContext.writeメソッドにでSolrInputDocument（＝MorphlinesのRecord）を書きだして、ReducerでSolrOutputFormatでインデックス作成の流れかなと。たぶん、MorphlineMapRunnerあたりを読みこめば解読できるかと。 ちなみに、こちらは、2.とは異なり、SolrLocatorの設定は無視されそう。\n感想＋妄想？ ということで、Morphlinesのデータ流れを考える上で、現時点ではSolrのスキーマを頭の片隅に置きつつ、 Recordの中にあるデータをゴニョゴニョしてデータを形成していくって感じになりそうです。 うまく処理できなかったものとかのカウントとかもとれたりするのかなぁ？とか、また色々と気になるところが出てきますが、一旦ここまでで。。。（だれか、続きを調べて書いてみてくれてもいいんですよ！コマンドもいっぱいあるし！）\nとまぁ、こんなかんじでMorphlinesをちょっとだけ読みました。 よくよく考えたら、こんなの作ったことあるなぁと（こんなに汎用的じゃないけど）。 みんな同じ事考えるんですねぇ。 コマンドパターン？みたいな感じで、I/F決めてSolrとか別のシステムとかにデータ入れる処理を順番に記述できる的なバッチ処理良くかいてます（書いてましたのほうが正解かなぁ）。\n","date":1375434120,"dir":"post/2013/","id":"33e01e2271be22b5ed330045fe6aff50","lang":"ja","lastmod":1375434120,"permalink":"https://blog.johtani.info/blog/2013/08/02/morphlines-loadsolr/","publishdate":"2013-08-02T18:02:00+09:00","summary":"宿題その2？かな。Solr勉強会でCloudera Searchのスキーマ周りってどうなってるの？という質問が出てて、 なんか調べることになって","tags":["Cloudera Search","Morphlines","Solr"],"title":"MorphlinesのloadSolrをちょっとだけ調べてみた"},{"contents":"今朝起きたら、Xperia Zが故障してしまいました。 電源ボタンを押してもスリープにならないんです。しかも、スリープからの復帰もできない。。。\nということで、ドコモショップに行って来ました。対応も良かったです。 やっぱり、ボタンがおかしく再起動してもNGでした。 ということで、トントン拍子で交換品に変更してもらえました。\n2、3回繰り返し言われましたが、データなくなりますよ＆交換品なので、復旧はご自分でとのこと。 ドコモショップ行く前に「Sony Bridge for Mac」というSony製のアプリでバックアップ取ってたし問題ないですと回答して、交換してもらいました。 最後に使ってないオプションとか要らないのでやめたほうが安くなりますよなどの提案もいただき満足でした。 さらに、前の機種に貼ってたフィルムもきちんと張り替えてもらえたし。時間はちょっとかかったけど。\nで、先ほど帰宅して、朝とっておいたバックアップから復旧しようとしたら。\n**「そんなバックアップありません」**みたいなメッセージが表示されて復旧出来ません。。。\nえ？なにそれ？と思い、とりあえず現時点のデータをバックアップ取ってみるかと。 バックアップ取ったあとに、再度復旧しようとしたらちゃんとリストがでてくるじゃないですか。\nなんだこれ？ということで、ファイル探しです。。。\n「Sony Bridge for Mac」バックアップファイルは次の場所に保存されるみたいです。\n/Users/ユーザ名/Library/Application Support/Sony Ericsson Bridge for Mac/Backups/製品番号みたいな文字列/日付 この最後のディレクトリが製品番号？ごとのディレクトリっぽく、２つありました。 どうせ初期化された状態だしということで、古い日付フォルダを新しい製品番号のフォルダにコピーしたら復元は可能でした。 壁紙の設定は再起動したら復活しましたが、復活してないものも。。。 復活してないのは以下のものです。\nインストールしてたアプリ ホーム画面の配置 アカウント色々（Google Playとか） ということで、スマホでインストールするのもだるくなってきたので、PCで黙々とGoogle Playのサイトからインストールしてますが、これもだるいですね。。。\n必要なアプリインストールし直したら、またSonyのアプリで復旧してみて、設定が復活するのを祈って。。。\n続き インストールしなおして、ホーム画面での配置をがんばりました。 Google Playのサイトから既存アプリをインストールするときに、ブラウザバックで戻ってたのですが、 一覧から別タブにインストールしたいアプリのページを開きまくってから、インストールボタン押すのが楽でした（半分くらい終わった所で気づいた。。。）\n一通りインストールしたあとに、ホーム画面の配置をやり直して、「Sony Bridge for Mac」もう一回復元。 twiccaやブクログなど、個別にアカウントとか設定を管理しているアプリについては復活しました。\nけど、Androidがアカウントを管理するもの（例：Facebookなど）については、残念ながら、一部のものはアカウントを再登録しないといけませんでした。\n写真や音楽についてはもともとSDカードに入れていたのもあったので、まぁ、被害は少なかったかなぁと。\nただ、iPadやiPhoneの用に簡単にバックアップ（アプリの情報、配置まで）ができて復元できると助かるなぁと思いました。（今度はホーム画面のキャプチャ撮ってから修理に出すかなぁ。。。）\n","date":1375364280,"dir":"post/2013/","id":"cd9ba1f582642d9cbe500f018afab341","lang":"ja","lastmod":1375364280,"permalink":"https://blog.johtani.info/blog/2013/08/01/replace-xperia-z/","publishdate":"2013-08-01T22:38:00+09:00","summary":"今朝起きたら、Xperia Zが故障してしまいました。 電源ボタンを押してもスリープにならないんです。しかも、スリープからの復帰もできない。。。","tags":["Xperia Z"],"title":"Xperia Zが故障したので交換したのでメモ"},{"contents":"Morphlinesについてちょっとだけ、さらに調べました。\n誤解 Solr勉強会でなんとなく私の認識を話しましたが、ちょっと誤解してたみたいです。スミマセン。\n誤解：Morphlineというプラットフォーム/ミドルウェアがありそうなイメージ まぁ、書いてあるのでちゃんと読めって話ですが、Morphlineはあくまでライブラリだということでした。 私はなんとなくManifoldCFのようなミドルウェアorプラットフォームが存在して、 そこにFlumeのSinkとかMapReduceによるIndexerが動作するのかと思ってました。\nまぁ、これが間違いでした。正解のイメージはこっちですね。\n各プラットフォーム（FlumeとかHadoopとか）に組み込んむライブラリで、 それぞれ組み込んだ先でMorphlineの設定を記述することで、パイプライン処理ができるっぽいです。\nFlumeについては、MorphlineSolrSinkというクラスでMorphlineの設定ファイルを読み込み、いろいろ処理出来ます。\nMap/ReduceだとCloudera Searchに含まれてるMapReduceIndexerToolがMorphlineの設定を読み込んでコマンド実行してくれるみたいです。 MapReduceIndexerToolはまだちゃんと読んでないのですが、MapperとしてMorphlineのコマンドが実行されるのかなぁ？という感じです。 （結構入り組んでるので、ちゃんと読まないとわからない。。。）\nということで、Morphlineというプラットフォームがあって、一元的にFlumeやMap/Reduceに対するコマンドをパイプライン化するという話でありませんでした。\n※ちなみに、上の画像ですが、愛用しているNUBoardを使って書いてます。 考えをまとめるのにすごく役立つ一品です。持ち運び可能なノート型ホワイトボードです。\n疑問点 ただ、読んでてまだ不明な点があります。まぁ、ぼちぼち調べるかなぁと。。。\nSolrのschemaはどーなってんの？ MorphlineにSolrへロードするコマンド（loadSolr）があるけど、FlumeのMorphlineSolrSinkってのもSolrに書き込みそうだけど？ Map/ReduceでSolrに書き込むもMorphlineのコマンドとの違いは？（前にソースを見たときはSOLR-1301がベースになっていて、SolrOutputFormatってクラスがEmbeddedSolrServer起動してインデクシングしてた） GoLiveってなんだろ？（MapReduceIndexerToolに入ってて、M/Rでインデックス作ったあとにSolrのクラスタに配布＋マージするやつっぽい） どんなコマンドがあるの？（Cloudera Morphlines Ref Guide） 以下は、参考資料と参考資料にあるSlideshareの資料を一部訳したものになります。\n参考資料 Using Morphlines for On-the-Fly ETL(slideshare) cloudera/cdk/cdk-morphlines(github) メモ 現在のコマンドライブラリ（スライド 18-19ページ） Solrへのインテグレートとロード フレキシブルなログファイル解析 1行、複数行、CSVファイル 正規表現ベースのパターンマッチと展開 Avro、JSON、XML、HTMLのインテグレーション Hadoop シーケンスファイルのインテグレーション SolrCellとApache Tikaパーサすべてのインテグレーション Tikaを利用したバイナリデータからMIMEタイプの自動判別 動的Javaコードのスクリプティングサポート フィールドの割り当て処理、比較処理 リストやセット書式のフィールド処理 if-then-else条件分岐 簡易ルールエンジン（tryRules） 文字列とタイムスタンプの変換 slf4jロギング Yammerメトリックとカウンター ネストされたファイルフォーマットコンテナの解凍 などなど プラグインコマンド（スライド　20ページ） 簡単に新しいI/Oや変換コマンドが追加可能 サードパーティや既存機能のインテグレード CommandインタフェースかAbstractCommandのサブクラスを実装 Javaクラスパスに新規作成したものを追加 登録処理などは必要ない 新しいプラグインコマンドとして考えられるもの（22ページ） RDBやKVSやローカルファイルなどの外部データソースをレコードにjoin DNS名前解決とか短縮URLの展開とか ソーシャル・ネットワークからリンクされたメタデータのフェッチ（？？） レコードの感情分析とアノテーション？ 31ページの図がわかりやすいかも\n以上。\n","date":1375265520,"dir":"post/2013/","id":"b875f24d3d444fdda82b6bbfb75a4c92","lang":"ja","lastmod":1375265520,"permalink":"https://blog.johtani.info/blog/2013/07/31/introduction-morphlines/","publishdate":"2013-07-31T19:12:00+09:00","summary":"Morphlinesについてちょっとだけ、さらに調べました。 誤解 Solr勉強会でなんとなく私の認識を話しましたが、ちょっと誤解してたみたいで","tags":["Cloudera Search","Morphlines","Solr"],"title":"Morphlines入門？"},{"contents":"不定期開催ですが第11回Solr勉強会を主催しました。\n今回も大入り90人くらい？の参加者の皆さんがいらっしゃいました。ありがたいことです！（20時時点で最終的に補欠17人でした。）\nとりあえず、第一報です。このあと懇親会なので。\nということで、帰りの電車でいくつか感想を（忘れちゃうから）。\n小林さんの苦労話は細かいですが、結構はまりがちな点を共有していただいたので良かったかなぁと。 Solrのexampleの設定とか、ManifoldCFとかちょっとずつ罠があったりするので、あるあるネタはありがたいと思いますｗ\nCloudera Searchについては、安定の嶋内さんの喋りに圧巻でした。検索だけの視点とは異なる観点についての 話は私には足りないしてんだったりするので参考になります。 なんか、気づいたらMorphlineやスキーマ周りを調べてブログ書くことになっちゃったけど。。。 一つ質問しそこねたのがあって、Cloudera社は基本的に公開したOSSについてのトレーニングも立ち上げているイメージです。Cloudera Searchについてもトレーニングが立ち上がるのかなぁと密かに期待をしてみたり（予算の関係上参加できるかは不明ですが。。。）\n牧野さんの話は画像系について、私は詳しくないので、また関口さんのalikeと比較とかしてもらえると面白いかなぁと。とりあえず、青いロボットがちゃんと検索できるようになるといいですねｗｗ\n秀野さんの空間検索は緯度経度以外のPOLYGONなどを利用した検索で、実は私も知らない機能でしたｗ\nなとなくは知ってたんですが、そこまでちゃんと検索できるとは！地図以外にも活用できるような気がします（想像つかないんだけど。。。）\n最後は私の発表で、簡単な資料ですみませんでした。しかも発表よりも宣伝が。。。（ブログの宣伝だったりとか。。。） 最後に宣伝した「「ビッグデータ活用を支えるOSS」特集への論文投稿のご案内」もご検討ください！\n懇親会も楽しかったです。また思いついたら開催しますー\n最後に、今回の発表者の皆様、会場提供していただいたVOYAGE GROUPの皆様ありがとうございました！\n以下はいつものメモです。\nManifoldCFのとSolrの組み合わせ（仮）株式会社 ロンウイット　大須賀さん 残念ながら、発熱のため発表は次回に持ち越しに。\n##社内ファイル及びWEBコンテンツの検索システム構築時に苦労したこと ソフトバンクBB㈱　小林さん\nManifoldCF＋Solrを使って社内ファイルの検索システム構築 約1000万ドキュメント さまざまなDCにドキュメントがある クロールジョブのハング。。。 ログをDEBUGにしたら。。。ログファイル150GB。。。 一定時間ごとにAgentをリスタートするバッチを。。。（力技） MCFエラーによるジョブの停止 CONNECTORS-590 エラーが発生して止まったジョブを起動するバッチをcronで。。。 自作リアルタイムインデクシングの問題 MCF使わないでSlaveにインデックス openSearcher=falseだとautoCommitが実行されてもSearcherを再起動しないので検索にでてこない リプリケーションのNW負荷 別DCからのレプリケーションが複数が一度に実施される→ネットワーク負荷が。。。 cronで別々にレプリすることでNW負荷を分散できてるかな。。。 Cloudera Search 入門(仮) Cloudera 株式会社　嶋内さん マサカリ画像がｗ SolrのコミッターMark Millerさんもジョインしてる ClouderaとHadoop入門とか。 いろいろあるよ、エコシステム 4つの分類。 データの取り込み データの保存 データの活用 Search 検索エンジンなら数十億人が使い方を知ってる（Clouderaのチャールズ・ゼドルースキ） Cloudera Search Hadoopのためのインタラクティブな検索\nCDHとSolrの統合\nOSS！\n利点とか。\nデータ解析にも使えるよね、検索 非構造化データの検索にもいいよね 単一プラットフォームによるコスパ Cloudera Searchの事例 バイオテクノロジー企業で画像検索とか 医療系企業でいろんなログイベントの管理とか Cloudera Searchのアーキテクチャ Flumeでストリーミングで登録 HBaseデータの登録 M/Rでバッチ登録 HueのWebインタフェース Morphlines、HBaseはLinyプロジェクトのもの\nSolr使うならCDH！！\nQA Q：デモで使われたTwitterの検索のデータ料とかは？\nA：デモ環境ですので小さい。\nQ：スキーマってどうするの？\nA：スキーマは。。。私が書こうかなぁ、ブログ。。。\nコンピュータビジョン　株式会社 Curious Vehicle　牧野さん 色々やってます コンピュータビジョンの説明（某ネコ型ロボットのいろんな画像がｗ） 画像検索の流れ 特徴情報の抽出 特徴情報のクラスタリングによるword化 Solrによる画像情報の検索 1. 特徴情報の抽出 SIFT特徴点解析 グレースケールしてからSIFT 注意！SIFTは商用ライセンスが必要です 2. 特徴情報のクラスタリングによるword化 K-meansでクラスタリング クラスタ情報をヒストグラム化してSolrへ 3. Solrによる画像情報の検索 物体認識ベンチマークセット（ケンタッキー大）を使って。 やっぱり良し悪しある。データセットに特化したチューニングしてます。 つぎのステップ 文字認識とか顔認識 つぎはドラえもんじゃねぇ、検索とかも。。。 ガウシアンによる画像ぼかしの例 QA マイク回しててメモ取れず。。。\n国土交通省のデータをSolrで検索　株式会社ネクスト　秀野さん スライドはこちら\n評価の関係で。。。 Spatial検索の話 デモの想定機能 地図上の小学校を起点に物件検索 地図上をクリックしたところを中心に検索 デモ環境 Solr4.3.0、PostGIS 2.0.3、東京都のデータ 事前知識 ジオメトリーデータ（点、線、面がある） WKB/WKT、Intersects（しらなかった。こんなのもあるのか） 環境 EC2上にPostGIS＋Solrで構築 WKT形式でDIHでインポートできるらしい。 Solr＋S3をJSでGoogleMapへ Solr 4.4新機能をちょっと紹介　@johtani 紹介というよりも宣伝。。。\n","date":1375107300,"dir":"post/2013/","id":"59d1b7206e7664e76672d3de4dc9a8ed","lang":"ja","lastmod":1375107300,"permalink":"https://blog.johtani.info/blog/2013/07/29/study-of-solr/","publishdate":"2013-07-29T23:15:00+09:00","summary":"不定期開催ですが第11回Solr勉強会を主催しました。 今回も大入り90人くらい？の参加者の皆さんがいらっしゃいました。ありがたいことです！（","tags":["Solr","Cloudera Search","ManifoldCF"],"title":"第11回Solr勉強会を主催しました。#SolrJP"},{"contents":"Hadoopとか離れちゃってるし、Hive触ったこと無いにもかかわらず参加しました！\n（たまたま近くにいるからって理由なのは内緒で）\n玉川さんの四方山話を聞くのが主目的で参加しました。（ちょっと翻訳が気になってるので）\nイベントページはこちら\n刊行記念イベントにも関わらず、想像以上の人の入りでびっくりしました。Hadoop、Hive界隈はまだまだ人気なんだなぁと。\nプレゼントじゃんけん大会もあったのですが、そうそうに負けてしまったのが悔やまれます。。。\nTeam Geek欲しかったなぁ。もちろん、懇親会まで参加しました。\n以下、いつものメモです。\nHiveの正しい使い方（Cloudera 嶋内さん） 残念ながら、マサカリは持ってなかったです。\nスライドの各所に本の章番号が書いてあるのがうれしい。 Hiveロゴが回ってたのでスライドの時に集中できなかったｗ Impalaの話も出てきた。 速いけど、色々足りない。Hiveの置き換えじゃないよと。 HiveとImpalaのおいしいとこ取り（セラン　須田さん） スライド：http://www.slideshare.net/sudabon/20130724-oreilly-org\nオンプレだとCDH便利だよと教えてもらう いくつかSlideshareにImpalaの性能評価の資料を上げてある（必要になったら検索で。。。） リリースされたその日に性能評価やってレポート書くとかすごすぎ！ 翻訳の四方山話（玉川さん） 翻訳＝写経です 締め切り駆動勉強法ｗ 4page/day 自分から電突してオライリーさんに翻訳させてくださいと。 他の方の本が読めない（チェックしちゃうのでｗ） 動機があるから読めるってのはあるだろうなぁ。 選び方：わくわくするもの、仕事に活きるもの 今年もあと2冊やる予定（Hadoop Operations、Vagrantを翻訳中） 来年の候補（Chefとか） 高可用性HDFSのご紹介（Cloudera 小林さん） スライドにどの版で書いてあったかがわかりやすく書いてある。 3段階の開発フェーズを経てる QJMのお話 Cloudera UniversityとHadoop認定試験（Cloudera 川崎さん） Clouderaデータアナリスト向けトレーニング（3日間、10月日本語で開催予定） Hive、Pig、Impalaなど Data Science入門コースも準備中 出版記念！ 8月管理者向け先着20 or 30名にHadoop第3版贈呈予定 先着20名にプログラミングHive贈呈予定 ","date":1374685860,"dir":"post/2013/","id":"1b9c5ae60ec46be64a1877f0c6920edc","lang":"ja","lastmod":1374685860,"permalink":"https://blog.johtani.info/blog/2013/07/25/hadoop-hive-publication-party/","publishdate":"2013-07-25T02:11:00+09:00","summary":"Hadoopとか離れちゃってるし、Hive触ったこと無いにもかかわらず参加しました！ （たまたま近くにいるからって理由なのは内緒で） 玉川さんの","tags":["Hadoop","Hive","Cloudera","オライリー"],"title":"『プログラミング Hive』 『Hadoop 第3版』刊行記念セミナーに参加しました！ #oreilly0724"},{"contents":"Yokozunaの気になる点というか、自分だったらこのへん調べるだろうなって観点を上げてみます。 別に調べるわけじゃないので、完全に自己満足なメモですけど。\nちなみに、分散システムとかRiakの仕組みは詳しくないので、ズレてる点がいっぱいあるかも。\nというか、分散システムでテストというか、検討する点とかってまとまってる資料とかあるのかなぁ？\nスキーマ変更時の挙動 フィールド型変更とか、フィールド追加とか 既存RiakクラスタにYokozunaの機能を追加する方法と制限 タイムラグとかも Riak＋Yokozunaクラスタに対してノード追加時に発生するオーバーヘッド（ネットワークとかディスクIOとか） 性能検証のためのシナリオ（どっちが先に悲鳴をあげるかとか） Riakメインで、Yokozunaはおまけ程度に検索するというシナリオ Yokozunaメインで使うシナリオ 更新が多い場合のシナリオ Riakのみ、Riak＋Yokozunaの各種統計情報（CPU、メモリ、ディスクサイズ、ネットワークIO） 運用系（監視とか）の手法とか機能？とか バージョンアップなどの対応方法 Solrがコケた時とかの対処 とりあえず、こんな感じかなぁ。\n","date":1373474580,"dir":"post/2013/","id":"50557b455cba1a3ce9b4555fc3fd5433","lang":"ja","lastmod":1373474580,"permalink":"https://blog.johtani.info/blog/2013/07/11/yokozuna-check-point/","publishdate":"2013-07-11T01:43:00+09:00","summary":"Yokozunaの気になる点というか、自分だったらこのへん調べるだろうなって観点を上げてみます。 別に調べるわけじゃないので、完全に自己満足な","tags":["Riak","Solr","Yokozuna"],"title":"Yokozunaの気になる点というかなんというか"},{"contents":"先日、Bashoさんにおじゃましたのもあり、Riak Meetup Tokyo #2に参加しました。\nYokozunaの話も聞けるということで。 懇親会も参加しました。Vさん＆リピさんと話し込んじゃってあんまり他の人と話せなかったけど。。。\n以下はいつものメモです。\nFreakOut 久森さん 「Riak環境をプロダクションで構築＆運用してみた（仮）」 FreakOutとRTB ディスプレイ広告の新しい配信の枠の話 この人には何出すの？いくらで？みたいな感じ 純広告：表示保証、期間保証など RTB：1回の広告表示ごとに買い付け DSP（デマンド・サイト・プラットフォーム） 広告表示は大体0.1秒で表示しないといけない。この間に色々やってる。 50ms or die.で戦ってます。 RTBはCPUバウンド 多コアを安く並べたい Tokyoなんとかとか使ってた。 スケーラビリティがキツイ（クライアント側でアルゴリズム分散してる） データ解析もしたいけど、検索ができない RTBに適したRiakがうまくハマるのではと。 構成とかとか アプリはPerlなので、PerlでRiakクライアントが必要。Memcached互換とかあると嬉しい。 ProtobufサポートもPurePerlしかなかった。 ないなら、作ろうと。githubに上がってます。このへんかな？ 監視はcloudforecastとかでやってる。 課題 Redirectがつらい（haproxy？がつらい？） Setが詰まるとつらい（ケースがまだわからない） 対策１ memcached＋Riak 対応２（案） hashからpartitionに直接取りに行くとか まとめ 素のままRiakはちょっとつらい QA 聞き取れたやつだけ\nQ：1台いくら位ですか？ A：10万から11万くらい Q：どのくらいの性能ですか？ A：同時1000くらいをさばいてる？ Q：50ms以下を出すのに、ネットワーク周りで近さとかを考えることありますか？ A：国内だと10msあればなんとかなる。それよりもアプリ側のチューニングのほうがまだ重要 Q：Cassandraとか候補に挙がらなかったんですか？ A：苦しんでる人が知人にいるので。。。あと、用途的に違うので。 Q：バックエンドとしてはなにを？ A：bitcaskにしてる Q：サーバ構成、ネットワーク構成がどうなってる？ A：。。。 Q：Redirectとは？RiakがやってるRedirect？ A：はい。 Q：他に候補にあがったのは？ A：商用のaerospike（これかな？）がスケールできそうだったけど、クライアントがいまいち。。。 感想 広告業界のことをよくわかってないので、微妙にピンときてなかったりもするのですが、以下に素早く返すかって観点でどこに注力して、問題点を潰していくのかってのは面白そうだなぁと。 リクエスト処理の性能がクリアできたらつぎはスケールの観点（ノード追加時の挙動とか）で検証していくんだろうなと。次回の話も聞いてみたい感じです。\nIIJ 曽我部さん、田中さん 「Yokozuna 日本語検索性能を評価しました」 Yokozunaって？ Riak＋Solrでいいとこ取り データの登録とかはRiakのAPIで。 SolrのAPIが使える。 YokozunaがSolrの分散検索の部分を隠してくれる。 Yokozunaのインストールとか。 SolrのAPIっぽい形で検索できるし、戻りもSolrのXMLっぽいのが出てくるよ。 Wikipediaデータってstoreの性能とか。 Riakのノード32台。（Xeon、メモリ24GB、HDD。。。） yz_extractor：Riakのコンテンツタイプを見てSolrにデータを入れる処理が書いてある。 自分でschema.xmlを書いてYokozunaに指定することもできる。 スキーマの変更とか登録とか。 すでに指定済みスキーマを変更した場合の挙動ってどうなるの？ デモではSolrからid取って、Riakからその他のデータを取り出していた。 Rubyでの性能評価 ベンチマークプログラム側の問題が先に影響が出てしまった。 QA Q：Riak単体とYokozunaつかった時でディスク容量がどのくらい増えた？ A：ちゃんと調べてないが、10%くらい増えた気がする。 Q：Solr側の設定でstored=trueだけど、falseにしてもいいんじゃないの？ A：デモはfalseにしてます。 Q：スキーマってあとから変更できるんですかね？ A：まだ良くわかってないです。 Q：ノードの追加、削除時の挙動とかも気になります。 感想 今回はStore性能に関してでしたが、今後は検索性能やシナリオによる性能（KVSの処理メインで、時々全文検索とか、全文検索の処理も結構あるパターンとか）の測定とか、耐障害性とかの観点で調査を進めてもらってSolr勉強会で話をしてもらえると面白そうだなぁと勝手に思ってみたり。 Solr勉強会へのコンタクトお待ちしてます！ｗ\n","date":1373450220,"dir":"post/2013/","id":"146e8ca40c0d37f36eecea822028dd9e","lang":"ja","lastmod":1373450220,"permalink":"https://blog.johtani.info/blog/2013/07/10/riak-meetup-tokyo-no2/","publishdate":"2013-07-10T18:57:00+09:00","summary":"先日、Bashoさんにおじゃましたのもあり、Riak Meetup Tokyo #2に参加しました。 Yokozunaの話も聞けるということで。 懇親会も参加しました。","tags":["Riak","Yokozuna","Solr"],"title":"Riak Meetup Tokyo #2に参加しました。#riakjp"},{"contents":"Solr 4.4に取り込まれる予定のチケットで、気になるものを見つけたのでいつものごとく調べてみました。\n元となるチケットはこちら。SOLR-4897。\nスキーマレス？ Solrはschema.xmlにデータの定義（フィールドタイプやフィールドなど）を記述して、データを登録する全文検索システムです。 これまでのSolrではこの設定ファイルを元にデータを登録するフィールド名を決定しており、 変更を行う場合はSolrのコアを再起動するなどの手順が必要でした。（※ダイナミックフィールドはすこし特殊）\nそれだと、Solrを管理するのがめんどくさいですね？という感じで現れたのがSchemaREST APIです。（たぶん。）\nSchema REST API Solr 4.2から導入されたSolrのスキーマに関する情報を提供するためのREST APIです。 4.2で導入されたのはあくまでもschema.xmlの情報を取得するためのAPIでした。 たとえば、Fieldの一覧を取得するとか。\n4.4から、フィールドの追加（変更、削除はできない）ができるようになりました。あくまでも、フィールドの追加で、フィールドタイプなどの追加はまだできません。（できるようになるのかもわからないですが。） フィールドの追加方法などはWikiに記載がありました。\nということで、簡単に試してみることに。\n起動方法 exampleディレクトリの下にexample-schemalessというディレクトリが新設されています。 ここに、スキーマレスモード用の設定がされているファイルが入っているので、こちらを利用します。\ncd $SOLR/example java -Dsolr.solr.home=example-schemaless/solr -jar start.jar ログにいくつかWARNが出ますが、影響の内パス設定ミスなので無視してOKです。\n最初に定義されているフィールドは「id」と「_version_」のみになります。（Schema Browserなどで確認できます。あ、REST APIでもいいですね。http://localhost:8983/solr/schema/fields）\nスキーマの更新 さて、フィールドを追加してみます。 PUTを利用すると1フィールドの追加が可能です。 「fugatext」というフィールド名でフィールドを追加しています。今のところJSONのみ対応みたいです。\n$ curl -X PUT http://localhost:8983/solr/schema/fields/fugatext -H \u0026#39;Content-Type: application/json\u0026#39; -d \u0026#39;{\u0026#34;type\u0026#34;:\u0026#34;text_ja\u0026#34;,\u0026#34;stored\u0026#34;:false,\u0026#34;multiValued\u0026#34;:true}\u0026#39; { \u0026#34;responseHeader\u0026#34;:{ \u0026#34;status\u0026#34;:0, \u0026#34;QTime\u0026#34;:18}} 追加できたかどうかもREST APIで取得してみます。\n$ curl http://localhost:8983/solr/schema/fields { \u0026#34;responseHeader\u0026#34;:{ \u0026#34;status\u0026#34;:0, \u0026#34;QTime\u0026#34;:0}, \u0026#34;fields\u0026#34;:[{ \u0026#34;name\u0026#34;:\u0026#34;_version_\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;long\u0026#34;, \u0026#34;indexed\u0026#34;:true, \u0026#34;stored\u0026#34;:true}, { \u0026#34;name\u0026#34;:\u0026#34;fugatext\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;text_ja\u0026#34;, \u0026#34;multiValued\u0026#34;:true, \u0026#34;stored\u0026#34;:false}, { \u0026#34;name\u0026#34;:\u0026#34;id\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;string\u0026#34;, \u0026#34;multiValued\u0026#34;:false, \u0026#34;indexed\u0026#34;:true, \u0026#34;required\u0026#34;:true, \u0026#34;stored\u0026#34;:true, \u0026#34;uniqueKey\u0026#34;:true}]} 追加できました。 ちなみに、同じフィールド名を追加しようとするとエラーが帰ってきます。\n$ curl -X PUT http://localhost:8983/solr/schema/fields/fugatext -H \u0026#39;Content-Type: application/json\u0026#39; -d \u0026#39;{\u0026#34;type\u0026#34;:\u0026#34;text_ja\u0026#34;,\u0026#34;stored\u0026#34;:false,\u0026#34;multiValued\u0026#34;:true}\u0026#39; { \u0026#34;responseHeader\u0026#34;:{ \u0026#34;status\u0026#34;:400, \u0026#34;QTime\u0026#34;:1}, \u0026#34;error\u0026#34;:{ \u0026#34;msg\u0026#34;:\u0026#34;Field \u0026#39;fugatext\u0026#39; already exists.\u0026#34;, \u0026#34;code\u0026#34;:400}} 設定の違い example-schemalessのsolrconfig.xmlは以下の設定が通常のexampleとは異なるようです。\nschemaFactoryの設定 schemaをAPIから変更可能にする設定です。これまでの変更しない設定の場合はClassicIndexSchemaFactoryを指定します。\n... \u0026lt;schemaFactory class=\u0026#34;ManagedIndexSchemaFactory\u0026#34;\u0026gt; \u0026lt;bool name=\u0026#34;mutable\u0026#34;\u0026gt;true\u0026lt;/bool\u0026gt; \u0026lt;str name=\u0026#34;managedSchemaResourceName\u0026#34;\u0026gt;managed-schema\u0026lt;/str\u0026gt; \u0026lt;/schemaFactory\u0026gt; ... update.chainの設定 更新処理（update関連のリクエストハンドラ「/update」とか）には次のような設定が追加されていました。（1006行目あたり）\n\u0026lt;requestHandler name=\u0026#34;/update\u0026#34; class=\u0026#34;solr.UpdateRequestHandler\u0026#34;\u0026gt; \u0026lt;!-- See below for information on defining updateRequestProcessorChains that can be used by name on each Update Request --\u0026gt; \u0026lt;lst name=\u0026#34;defaults\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;update.chain\u0026#34;\u0026gt;add-unknown-fields-to-the-schema\u0026lt;/str\u0026gt; \u0026lt;/lst\u0026gt; \u0026lt;/requestHandler\u0026gt; 「add-unknown-fields-to-the-schema」というupdate.chainが指定されています。このchainの定義自体は1669行目くらいに存在します。 （長い。。。）\n\u0026lt;!-- Add unknown fields to the schema An example field type guessing update processor that will attempt to parse string-typed field values as Booleans, Longs, Doubles, or Dates, and then add schema fields with the guessed field types. This requires that the schema is both managed and mutable, by declaring schemaFactory as ManagedIndexSchemaFactory, with mutable specified as true. See http://wiki.apache.org/solr/GuessingFieldTypes --\u0026gt; \u0026lt;updateRequestProcessorChain name=\u0026#34;add-unknown-fields-to-the-schema\u0026#34;\u0026gt; \u0026lt;processor class=\u0026#34;solr.RemoveBlankFieldUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;processor class=\u0026#34;solr.ParseBooleanFieldUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;processor class=\u0026#34;solr.ParseLongFieldUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;processor class=\u0026#34;solr.ParseDoubleFieldUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;processor class=\u0026#34;solr.ParseDateFieldUpdateProcessorFactory\u0026#34;\u0026gt; \u0026lt;arr name=\u0026#34;format\u0026#34;\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ss.SSSZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ss,SSSZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ss.SSS\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ss,SSS\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ssZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm:ss\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mmZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026#39;T\u0026#39;HH:mm\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ss.SSSZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ss,SSSZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ss.SSS\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ss,SSS\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ssZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm:ss\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mmZ\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd HH:mm\u0026lt;/str\u0026gt; \u0026lt;str\u0026gt;yyyy-MM-dd\u0026lt;/str\u0026gt; \u0026lt;/arr\u0026gt; \u0026lt;/processor\u0026gt; \u0026lt;processor class=\u0026#34;solr.AddSchemaFieldsUpdateProcessorFactory\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;defaultFieldType\u0026#34;\u0026gt;text_general\u0026lt;/str\u0026gt; \u0026lt;lst name=\u0026#34;typeMapping\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;valueClass\u0026#34;\u0026gt;java.lang.Boolean\u0026lt;/str\u0026gt; \u0026lt;str name=\u0026#34;fieldType\u0026#34;\u0026gt;booleans\u0026lt;/str\u0026gt; \u0026lt;/lst\u0026gt; \u0026lt;lst name=\u0026#34;typeMapping\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;valueClass\u0026#34;\u0026gt;java.util.Date\u0026lt;/str\u0026gt; \u0026lt;str name=\u0026#34;fieldType\u0026#34;\u0026gt;tdates\u0026lt;/str\u0026gt; \u0026lt;/lst\u0026gt; \u0026lt;lst name=\u0026#34;typeMapping\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;valueClass\u0026#34;\u0026gt;java.lang.Long\u0026lt;/str\u0026gt; \u0026lt;str name=\u0026#34;valueClass\u0026#34;\u0026gt;java.lang.Integer\u0026lt;/str\u0026gt; \u0026lt;str name=\u0026#34;fieldType\u0026#34;\u0026gt;tlongs\u0026lt;/str\u0026gt; \u0026lt;/lst\u0026gt; \u0026lt;lst name=\u0026#34;typeMapping\u0026#34;\u0026gt; \u0026lt;str name=\u0026#34;valueClass\u0026#34;\u0026gt;java.lang.Number\u0026lt;/str\u0026gt; \u0026lt;str name=\u0026#34;fieldType\u0026#34;\u0026gt;tdoubles\u0026lt;/str\u0026gt; \u0026lt;/lst\u0026gt; \u0026lt;/processor\u0026gt; \u0026lt;processor class=\u0026#34;solr.LogUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;processor class=\u0026#34;solr.RunUpdateProcessorFactory\u0026#34;/\u0026gt; \u0026lt;/updateRequestProcessorChain\u0026gt; 使ってるUpdateProcessorはこんな感じみたいです。最後の2つはこれ用じゃないので省略。\nプロセッサ名説明 RemoveBlankFieldUpdateProcessorFactory値がないフィールドは除去 ParseBooleanFieldUpdateProcessorFactoryスキーマに定義されていないフィールドで、値がBooleanとしてパースできたら、Boolean型とする。 ParseLongFieldUpdateProcessorFactoryスキーマに定義されていないフィールドで、値がLongとしてパースできたら、Long型とする。 ParseDoubleFieldUpdateProcessorFactoryスキーマに定義されていないフィールドで、値がDoubleとしてパースできたら、Double型とする。 ParseDateFieldUpdateProcessorFactoryスキーマに定義されていないフィールドで、値がDateとしてパースできたら、Date型とする。（パースの形式がformatで列挙されてる） AddSchemaFieldsUpdateProcessorFactory入力されたドキュメントの中でスキーマに定義されていないフィールド（静的、動的両方）を見つけた時に、フィールドの値の型を元にフィールド型をマッピングする。 とここまで見てきたところで、スキーマレスという名前の意図がちょっとわかったかも。\n定義されてないフィールドを持ったデータを登録 起動時には定義されてないフィールドをもったデータを登録してみます。 boolean型で試してみることに。以下のデータを管理画面のデータ登録画面から登録します。（http://localhost:8983/solr/#/collection1/documents） （タイトルでbooleanってわかりにくいですが）\n{\u0026#34;id\u0026#34;:\u0026#34;change.me\u0026#34;,\u0026#34;title\u0026#34;:true, \u0026#34;price\u0026#34;:1.25, \u0026#34;fuga\u0026#34;:\u0026#34;100,200\u0026#34;} エラーは出ません。で、またフィールド一覧を取得すると。\n$ curl http://localhost:8983/solr/schema/fields { \u0026#34;responseHeader\u0026#34;:{ \u0026#34;status\u0026#34;:0, \u0026#34;QTime\u0026#34;:1}, \u0026#34;fields\u0026#34;:[{ \u0026#34;name\u0026#34;:\u0026#34;_version_\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;long\u0026#34;, \u0026#34;indexed\u0026#34;:true, \u0026#34;stored\u0026#34;:true}, { \u0026#34;name\u0026#34;:\u0026#34;fuga\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;tlongs\u0026#34;}, { \u0026#34;name\u0026#34;:\u0026#34;fugatext\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;text_ja\u0026#34;, \u0026#34;multiValued\u0026#34;:true, \u0026#34;stored\u0026#34;:false}, { \u0026#34;name\u0026#34;:\u0026#34;id\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;string\u0026#34;, \u0026#34;multiValued\u0026#34;:false, \u0026#34;indexed\u0026#34;:true, \u0026#34;required\u0026#34;:true, \u0026#34;stored\u0026#34;:true, \u0026#34;uniqueKey\u0026#34;:true}, { \u0026#34;name\u0026#34;:\u0026#34;price\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;tdoubles\u0026#34;}, { \u0026#34;name\u0026#34;:\u0026#34;title\u0026#34;, \u0026#34;type\u0026#34;:\u0026#34;booleans\u0026#34;}]} おー、最後にtitleが追加されてます。他にもfugaやpriceも。（日付は手を抜きました。。。）\n感想 詳細までは追いかけてないですが、こんなかんじです。 フィールド追加が可能になるのはいいんじゃないでしょうか。SolrCloudの機能との関連もあるのかもしれません。ZooKeeperへの出力も実装されてそうなので。\nただ、機械的に出力されたschema.xml（exampleだとmanaged-schemaというファイル）には_「DO NOT EDIT」_との記述があるので、修正するとなにかおきてしまうかもしれないですねぇ。 現時点では、フィールドタイプの変更やフィールドの更新、削除に関してはSolrCoreの再起動などの手順が必要です。 あと、変なデータ（タイプミスとか）が登録されたりしないかってのは気になりますね。\n※ちなみに、別の人が気づいたんですが、ちょっとバグが有ったみたいで、代わりにチケットつくったらキリ番（SOLR-5000） ゲットしましたｗ\n","date":1372867920,"dir":"post/2013/","id":"a98d42be181c01b8077e060b1b5080ec","lang":"ja","lastmod":1372867920,"permalink":"https://blog.johtani.info/blog/2013/07/04/schemaless-example/","publishdate":"2013-07-04T01:12:00+09:00","summary":"Solr 4.4に取り込まれる予定のチケットで、気になるものを見つけたのでいつものごとく調べてみました。 元となるチケットはこちら。SOLR-4897","tags":["Solr"],"title":"スキーマレスモード？（SOLR-4897）を調べて見ました。"},{"contents":"SolrのチケットをML経由で眺めてるんですが、便利そうなチケットが流れてきたのでブログを書いてみみようかと。 元になってるチケットはこちらです。昨日だか、今朝にtrunkとbranch_4xにコミットされたみたいです。試してみたい方は、branch_4xかtrunkをチェックアウトすると触ることができます。\nデータ登録用の画面（JSON） branch_4xをチェックアウトしてexampleを起動し、Solrにアクセスします。\n管理画面に「Dcuments」という項目が追加されてます。開くとこんなかんじです。\nなんと、デフォルトはJSONになってます。これも時代の流れでしょうかｗ\nSolrでは、これまで設定ファイルやデータ登録もXMLがメインになっていました。（Apache Solr入門もXMLを基本に書いてます。このころはまだデフォルトでは対応してなかったので）\n登録するデータをテキストエリアに記述して、「Submit Document」をクリックすればデータは登録されます。基本的には単件登録の画面でしょうか。 （登録されたデータを確認するには「Query」画面を利用すればいいです。） また、JSONのデータ形式はSolrのWikiを参照してください。\nCSVやXMLも この管理画面ではJSON以外の形式でもデータの登録が可能です。 「Document Type」の項目をクリックすると以下のように選択肢があられます。\nCSV、XMLについては、先ほどのJSONの画面の用に、テキストエリアが表示されます。 テキストエリアにCSV（データの形式はこちら）やXML（データの形式はこちら）を入力してボタンを押せば登録できます。\nSolr Command形式も（JOSNかXML） Solr Command というのはXMLやJSONで登録、コミット、削除などを実行するための画面になります。 JSONのコマンドはこちら、XMLのコマンドはこちらをご覧ください。\nあと、便利なのがファイルアップロードです。 こんなかんじで、ファイルを選んでSubmitすればデータが登録出来ます。\nファイルのサイズが大きいとちょっと時間がかかりますが、コマンドを打つより簡単かもしれません。 post.jarツールと違って、デフォルトでコミットをしてくれるわけではないので、「Extracting Req. Handler Params」に「commit=true」をつけないと、データが登録されてない？と思ってしまうかもしれませんが。\n組立もできるみたい（Document Builder） 最後に紹介するのが「Document Builder」というタイプです。\nもっと簡易にデータを記述できるようにということで用意されているようです。 フィールドの情報はSolrに接続して利用できるフィールド？（ダイナミックはないのかな？）が表示されます。\n追記していくとこんなかんじになります。\n日本語のデータもちゃんと登録できました。 ただ、まだ、開発中なんでしょうがないかもしれませんが、以下の様な制約があるようです。\nmultiValuedなフィールドに値を追加できない（上書きされる） 改行が入ったデータをテキストエリアにいれると「Add Field」を押しても反応しない ダイナミックフィールドは自分で書きましょう ただ、これまでXMLでファイルを作ってコマンドで登録したり、curlコマンドでJSON書いたりして登録していたよりはお手軽にさわれるようになるかと思います。つぎの4x系のバージョンが出たときはこちらからデータを登録してみてください。\n","date":1372318080,"dir":"post/2013/","id":"ecf3ac80454654d990d9c07d33d35d1c","lang":"ja","lastmod":1372318080,"permalink":"https://blog.johtani.info/blog/2013/06/27/upload-docs-solr-admin/","publishdate":"2013-06-27T16:28:00+09:00","summary":"SolrのチケットをML経由で眺めてるんですが、便利そうなチケットが流れてきたのでブログを書いてみみようかと。 元になってるチケットはこちらで","tags":["Solr"],"title":"Solrの管理画面でデータ登録"},{"contents":"前回は3番煎じぐらいでしたが、今回は初記事かな？（だといいな）\nKibanaには、前回の記事で書いたものとは別に開発中のKibana3というのが存在します。\nKibana3って？ Kibana2はRubyで書かれていましたが、Kibana3はHTML＋JavaScriptで構成されています。 ですので、ApacheなどのWebサーバに配置することで、利用が可能となります。 ただ、HTML＋JavaScriptのため、ブラウザ上で動作するためブラウザが動作するマシンからElasticSearch（通常だとhttp://マシン名orIPアドレス:9200/とか）にアクセスできなければいけないという制限があります。\nこの条件さえクリア出来れば、Kibana3ではKibana2よりも様々なパネルが用意されていて、色々できそうなのでお勧めです。\nインストール ElasticSearchやログについては、前回の記事の環境を利用しました。 ですので、Kibana3のインストールのみです。（ApacheもCentOSのサーバに入っていたので。）\nダウンロードして、Apacheの公開ディレクトリに置いただけです。（お試し環境のため、権限とかは大目に見てください。\n$ git clone https://github.com/elasticsearch/kibana.git kibana-javascript $ cp -R kibana-javascript /var/www/html 今回はApacheとElasticSearchが同一マシン（＝同一IPアドレスでアクセス可能）で動作している＋ElasticSearchへのアクセスのポートがデフォルト（9200）のため特に設定が必要ありませんでした。\nElasticSeachサーバとKibana3のApacheのサーバが別のサーバの場合やElasticSearchサーバのポートが異なる場合はkibana-javascript/config.jsファイルの編集が必要になります。 cloneしてすぐのconfig.jsは、以下のとおりです。\n/* elasticsearch: URL to your elasticsearch server. You almost certainly don\u0026#39;t want \u0026#39;http://localhost:9200\u0026#39; here. Even if Kibana and ES are on the same host kibana_index: The default ES index to use for storing Kibana specific object such as stored dashboards modules: Panel modules to load. In the future these will be inferred from your initial dashboard, though if you share dashboards you will probably need to list them all here If you need to configure the default dashboard, please see dashboards/default */ var config = new Settings( { // By default this will attempt to reach ES at the same host you have // elasticsearch installed on. You probably want to set it to the FQDN of your // elasticsearch host elasticsearch: \u0026#34;http://\u0026#34;+window.location.hostname+\u0026#34;:9200\u0026#34;, // elasticsearch: \u0026#39;http://localhost:9200\u0026#39;, kibana_index: \u0026#34;kibana-int\u0026#34;, modules: [\u0026#39;histogram\u0026#39;,\u0026#39;map\u0026#39;,\u0026#39;pie\u0026#39;,\u0026#39;table\u0026#39;,\u0026#39;stringquery\u0026#39;,\u0026#39;sort\u0026#39;, \u0026#39;timepicker\u0026#39;,\u0026#39;text\u0026#39;,\u0026#39;fields\u0026#39;,\u0026#39;hits\u0026#39;,\u0026#39;dashcontrol\u0026#39;, \u0026#39;column\u0026#39;,\u0026#39;derivequeries\u0026#39;,\u0026#39;trends\u0026#39;,\u0026#39;bettermap\u0026#39;], } ); ポート番号が異なる場合は、1つ目の「elasticsearch:」で指定されている「9200」を環境に合わせて編集するだけになります。 Kibana3とElasticSearchのホストが異なる場合は、1つ目の「elasticsearch:」の行をコメントアウトし、2つ目を有効にしてから環境に合わせたURLに修正して保存すればOKです。\n以上で、インストールは完了します。あとは、以下のURLにアクセスするだけです。\nhttp://hogehoge/kibana-javascript/ 画面構成 アクセスすると次のような画面が表示されます。\n初期画面 左上に赤い帯で、「 Oops! Could not match index pattern to any ElasticSearch indices」とエラーが表示されました。\nKibanaはElasticSearchに「logstatsh-年.月.日」という日付ごとのインデックスが存在することが前提となっています。 Kibanaに初めてアクセスした場合、「logstash-当日日付」で始まるインデックスを描画しようとします。 これは、私が前回利用したElasticSearchの環境に古いデータ（試したのが19日、データは10日のみ）しか入っていないために出たエラーです。\n日付は「Options」というエラーが出ている付近の「Absolute」というリンクをクリックすると、特定の日付をカレンダーで指定することができるようになります。データは6/10にしか入っていないので、6/10（12時くらいから20時くらいまで）のを指定します。\n日付指定 選択すると無事データが見えるようになりました。\nデータ描画 ダッシュボードの構成（初期） Kibana3では、この画面をダッシュボードというようです。 このダッシュボードは初期状態では、以下のパーツが表示されています。（子要素があとで説明するパネル名です）\nOptions：描画対象の日付の指定やダッシュボードの保存などを行うRow timepickerパネル：日付の指定 dashcontrolパネル：ダッシュボードの制御（保存とか） Query：ログ検索式を入れるところ stringqueryパネル Graph：ヒストグラムの描画（X軸：時間、Y軸：ログ件数） histogramパネル Events：検索にヒットしたログデータの描画領域 fieldsパネル：表示するフィールドの選択（左側。チェックを入れると右側のログ表示領域のカラムが増える） tableパネル：ログデータ（右側。左側でチェックが入ったカラムだけが表示される。） あくまで初期表示です。各パーツの設定アイコン（歯車のマーク）をクリックすると色々と設定が可能です。 また、「Events」など名称はクリック可能となっていて、クリックすると、そのパーツが折りたたまれた状態にすることも可能です。\n折りたたんだ状態 ダッシュボードの設定 ダッシュボードには独自のパネルを簡単に追加することができます。 ダッシュボードの構成はページの一番上にある「Logstash Search」の設定アイコンをクリックすると設定画面が開きます。\nダッシュボード設定 「New row」にタイトル名を適当にいれて「Create Row」するとあたらしくパネルを追加することができるRowが追加されます。「Rows」の「Move」にある矢印でRow自体の表示場所を上下に移動することも可能です。\nRowの設定 追加した「Hoge」にパネルを追加する場合はHogeの上にある設定アイコンをクリックすると設定画面が開きます。\nRowの設定 ここでKibana3で用意されているパネルの追加ができます。\nPanel追加ボタン パネルを選んでボタンを押せばすぐに表示されます。\nパネルの羅列 こんな感じです。とりあえず、ポコポコと追加してみました。\n利用できるパネルの種類は以下の様なパターンです。 適当ですが、表にしてみました。\nパネル名概要 columnRowの中にパネルを配置するコンテナを用意するためのパネル dashcontrolダッシュボードの保存、保存したダッシュボードの表示などの操作ボタン textmarkdown形式などで記述が可能な文章を表示できるパネル stringquery検索クエリ入力用パネル derivequeriesフィールドと検索式がわかれた形式の検索入力用パネル timepickerログ表示の期間を指定するパネル histogramログの件数のヒストグラム表示用パネル hitsヒット件数表示用パネル pieパイチャート表示用パネル trends指定された時間でデータの増減を%表示するパネル sortソート条件指定用のプルダウン表示用パネル（変更したらtableの内容がソートされる） tableログデータ表示用パネル fieldstableパネルに表示するフィールドを選択するための補助パネル bettermapなんか地図が出てきたパネルGeoJSONデータをゴニョゴニョ（表示かな？）できるみたい mapなんか世界地図が出てきたパネル２文字の国コード（jaとかか？）かU.S.の州コードのデータを元に地図に色をつけるのかな？ これらのパネルは個々に色々と設定が可能です。他にもdebug、map2など有りそうでしたがまだ使えないみたいです。\n適当に触ってて気づいた注意点です。\ntableは１ダッシュボードで１つだけが良さそう。 ２つあると、どちらかにしか描画されない。columnに入れるとグルーピングできたりするのかなぁ？ stringquery、timepickerも１ダッシュボードで１つが良さそう。 これもtableと似たような理由です。 ダッシュボード保存し忘れて泣きそうになる JSで実装されてて、自分で色々とカスタマイズできるのですが、保存するのを忘れて泣きそうになりましたｗ カスタマイズしたダッシュボードについては、ローカルに保存する以外にElasticSearchにも保存ができるみたいです。チームで共有することもできそうです。 derivequeriesを表示するとグラフがカラフルに derivequeriesを追加したらグラフが急にカラフルになりました。 どうもderivequeriesのFieldの部分を変更すると、そのフィールドの値を元にグラフを細分化してくれるようです。色の数の上限はderivequeriesのLength属性の数値で制御出来ます。（5だと5個まで色が出る） histogramのパネルで自分でクエリを記載することも可能です。ただ、derivequeriesのフィールド変更すると書き換わっちゃいます。。。 derivequeriesを追加したらカラフルに ヒストグラムは色々なパターンのグラフを描画できました。ラインによる描画（histo1）、総数を100%としたパーセンテージでの表示（histo2）、ライン＋点による描画（histo3）などです。\nヒストグラムのいくつかのパターン 感想 ということで、適当にですが触ってみました。 Kibana2はApacheのアクセスログとかの表示しかできない感じがしましたが、Kibana3だといろいろなデータを描画できそうだなと。 logstash形式のインデックスを用意するのが前提になってるので、時系列データをグラフ描画するのに向いてるんでしょうか。 お手軽にグラフ化できるし、自分でダッシュボードをカスタマイズできるのは素敵です。 ただ、クエリとグラフの関係などはちょっと癖があるかもしれないので、色々と試してみないといけないかもしれないです。 （たとえば、特定のフィールドの値について「A、B、その他」みたいなグラフの描画とかをどうするかとか）\n地図の描画は試してみたいかなぁ。\n","date":1371652980,"dir":"post/2013/","id":"26c47355cbe966a94826cbe2fbf2b355","lang":"ja","lastmod":1371652980,"permalink":"https://blog.johtani.info/blog/2013/06/19/introduction-kibana3/","publishdate":"2013-06-19T23:43:00+09:00","summary":"前回は3番煎じぐらいでしたが、今回は初記事かな？（だといいな） Kibanaには、前回の記事で書いたものとは別に開発中のKibana3というの","tags":["elasticsearch","kibana"],"title":"Kibana3というのもありまして"},{"contents":"ちょくちょく書こうと言いながら、前の記事が1週間以上前になってる。。。\n昨日は、Basho Japanに遊びに行って来ました。 （Riak触ったことないのに。。。Erlangも。。。ゴメンナサイ）\nRiakにSolrを組み合わせたYokozunaというものの名前を最近耳にしていたので、どんなものなのかなぁと興味がありまして。Solrがどんな使い方をされているのかってのが気になったので、 情報交換したいなぁと思っていたところ、Vの人が調整してくれたので色々と有意義な話ができたかなぁと。 （Yokozunaについての最新のスライドはBerlin Buzzword 2013のものがここに） Twitter上で見かけたことのある方々と話ができたり面白かったです。（やっぱ英語で会話できたりスラスラと読めるの必要だよなぁと痛感したりもしました。。。）\nということで、遊びに行ったのに美味しいピザやこんなおみやげまでもらってしまいました。 （ピザの写真撮るの忘れてたw）\nRiak＆Bashoグッズ ちなみに、Yokozunaですが、Riakに登録したデータを裏で起動しているSolにデータを流しこんでくれるものになります。 Solrの機能としては分散検索（Distributed Search）と呼ばれる仕組みを利用しているようです。 YokozunaのI/Fとしては、Solrのインデックスの分散構成は隠してくれていて、かつ、Solr（っぽい？）リクエストを投げれば裏の分散構成に問い合わせた結果をSolrのレスポンスの形で返してくれます。 KVSに全文検索の機能がついてくるお得感が満載な気がしますw。\nRiak自身のデータの取り扱いがどんなものかをまだちゃんと理解していないので（ゴメンナサイ。Little Riak Bookは開いてるんですが読んでなくて。。。）またおじゃましてもう少し情報交換したいかなぁとｗ。\nCloudera Searchといい、Yokozunaといい、Solrを利用したものが少しずつ増えてきて嬉しい限りです。 Solrの作りがしっかりしている？活発？、だから取り込む形が多いんですかねぇ。 Solr本を書いてから数年たちますが、やっと検索のニーズが出てきたのかもしれないなぁと思ってみたり。 （流れのつながりはあまりないですが）ElasticSearchも少しずつ人気が出てきてるし、日本語の本とかのニーズあったりするかなぁ？\n","date":1371603780,"dir":"post/2013/","id":"33919e866426ce8e7b2ce06f19bbf889","lang":"ja","lastmod":1371603780,"permalink":"https://blog.johtani.info/blog/2013/06/19/visited-basho/","publishdate":"2013-06-19T10:03:00+09:00","summary":"ちょくちょく書こうと言いながら、前の記事が1週間以上前になってる。。。 昨日は、Basho Japanに遊びに行って来ました。 （Riak触ったこ","tags":["Riak","Basho","Yokozuna","Solr"],"title":"Basho Japanに遊びに行きました"},{"contents":"Lucene/Solr 4.3.1のRCのVoteが始まっていますが、そのMLできになったコトがあり、ちょっと調べたので メモを残しておきます。\nマルチコアの設定ファイルであるsolr.xmlの記述方法と、コアの探索ロジックが4.4（実装的には4.3から入っている）から変更されるようです。4.x系の最新版である、branch_4xのexampleディレクトリにあるsolr.xmlも新しい記述に変更されていました。\n参考URL 新しいCore探索（4.4以降） 新しいsolr.xml（4.4以降） 4.3までのsolr.xml ちなみに、最後のold styleと呼ばれる4.3までの記述方法はつぎの5.0ではDeprecatedになるようです。（5.0がいつ出るのかはわからないですが。）\nCore探索ロジック 4.4から、$SOLR_HOMEディレクトリ以下の探索ロジックは次のようになるようです。 以下では、「新スタイル」（4.4以降の書式）、「旧スタイル」（4.3以下の書式）として記述します。\nsolr.xmlファイルの存在チェック solr.xmlが存在しない場合→旧スタイルとして処理→3へ（旧スタイル） solr.xmlが存在し\u0026lt;cores\u0026gt;タグが存在しない場合→2へ（新スタイル） solr.xmlが存在し\u0026lt;cores\u0026gt;タグが存在する場合→3へ（旧スタイル） 新スタイルのロジック SOLR_HOMEディレクトリに存在するディレクトリについて以下の処理を繰り返す SOLR_HOME/ディレクトリ/core.propertiesファイルが存在する→後続処理へ。存在しなければ終了 SOLR_HOME/ディレクトリ/conf/solrconfig.xmlを読み込み、コアを起動 旧スタイルのロジック これまで同様、solr.xmlの\u0026lt;core\u0026gt;タグの記載内容を元にコアを起動（instanceDir以下のconf/solrconfig.xmlを使って） solr.xmlが存在しない場合はSOLR_HOME/collection1/conf/solrconfig.xmlが存在するものとしてコアを起動 このようなロジックになります。\nちなみに、以下の場合はエラーとなりSolrは起動しますがログや管理画面にエラーである表示がされます。\n2.3でsolrconfig.xmlが見つけられなかった場合 3.1で\u0026lt;core\u0026gt;タグが存在しなかった場合（この場合、ログにはエラーが出ません） propertiesに記述できる内容やsolr.xmlの記述内容については、Wikiを見てもらうということで。。。 CoreAdminHandlerでコアを生成したりした場合に、新スタイルの設定がどのように出力されるのかといった点が気になりますが、また今度にでも。\n","date":1370945460,"dir":"post/2013/","id":"78292d953eafbdf9e57cc4bbbe6e8964","lang":"ja","lastmod":1370945460,"permalink":"https://blog.johtani.info/blog/2013/06/11/new-solr-xml/","publishdate":"2013-06-11T19:11:00+09:00","summary":"Lucene/Solr 4.3.1のRCのVoteが始まっていますが、そのMLできになったコトがあり、ちょっと調べたので メモを残しておきます。 マルチコアの設定ファ","tags":["Solr"],"title":"新しいsolr.xmlとCore探索ロジック"},{"contents":"もう何番煎じだ？ってくらい書かれてますが、コリもせず書いてみました。 Elasticsearch＋Kibanaの環境を作って、タムタムさんのログ生成ツールからApacheのダミーログを流しこんで入れてみました。\n参考URL memorycraftさんのブログ Kibana Elasticsearch fluentd apache-loggen インストールと起動 今回はCentOSへのインストールです。 基本的にはmemorycraftさんのブログの流れのままです。\nelasticserchのインストールと起動 ダウンロードして、起動するだけ。 お試しということで、-fオプションにてコンソールにログ出力。\ncurl -OL https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-0.90.1.tar.gz tar zxvf elasticsearch-0.90.1.tar.gz cd elasticsearch-0.90.1 ./bin/elasticsearch -f Kibanaのインストールと起動 git cloneしてbundleインストール\ngit clone --branch=kibana-ruby https://github.com/rashidkpc/Kibana.git cd Kibana bundle install ruby kibana.rb これで、Kibana＋ESのインストール＋起動が完了。 下地が完了。\ntd-agentのインストールと起動 ログの流し込みはlogstashなのですが、fluentdのelasticsearchプラグインにて流しこむこともできます。 td.repoとしてtd-agentのリポジトリを登録してから以下を実行します。\nyum install td-agent -y /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-elasticsearch vim　/etc/td-agent/td-agent.conf /etc/init.d/td-agent start これで、td-agentがインストール出来ました。 次は設定です。\n\u0026lt;source\u0026gt; type tail format apache path /var/log/httpd/dummy_access_log tag dummy.apache.access \u0026lt;/source\u0026gt; \u0026lt;match *.apache.*\u0026gt; index_name adminpack type_name apache type elasticsearch include_tag_key true tag_key @log_name host localhost port 9200 logstash_format true flush_interval 10s \u0026lt;/match\u0026gt; 以上が設定です。td-agentはtd-agentというユーザで起動されるので、/var/log/httpdディレクトリにアクセスできるかだけ確認が必要です。\nいくつかの設定値について気になったので調べました。\nindex_name：adminpackとなってるが、elasticsearchではlogstash-xxxとなってる。 これは、logstash_formatがtrueの場合は、利用されないので、指定しなくてもいい。 type_name：Elasticsearchのタイプ名 *　これはlogstash_formatを指定しても有効。ただし、Kibana側で画面からのtype指定は不可能。KibanaConfig.rbにて指定することは可能。 logstash_format：Kibana用にlogstashフォーマットで出力するオプション この指定があるときは、index名が「logstash-YYYY.mm.dd」となる record（ログ）に@timestampとして時刻が追加される。 tag_key：include_tag_keyがtrueと指定されているため、record（ログ）にtag_keyで指定した文字列をキー、値としてtagの値（上記例だとdummy.apache.access）が付与されて登録される。 apache-loggenのインストールと起動 タムタムさんが作成されたApacheのログのダミーを生成するツールです。\ngem化されてるので、インストールは非常に簡単です。\ngem install apache-loggen で、ログを出力します。出力先は先程設定したdummy_access_logです。\napache-loggen --rate=10 --progress /var/log/httpd/dummy_access_log 秒間10アクセスログを出力してくれます。 これで、Kibanaでログが見れるようになりました。 なんて簡単なんでしょう。。。 簡単なログの検索ができてしまいました。 他の形式のログがどうなるのかとかは、また時間があれば。。。\n感想とか 非常に簡単でした。素敵です。いくつかこうなるのかな？というのを試してみたのでメモを。\nいくつか疑問点です。\n溜まったログの削除は手動？ おそらく。日付ごとにindexが出来上がっているので、削除は楽そう。「logstash-年月日」なので。 認証とかかけれるの？ ログ検索は内部でするだろうから、まぁ、なくていいのかな。ログインすらないし。 複数行のログとかってどーすんだろう？（JavaのExceptionとかが混ざるやつ） 本格的に触るようになれば調べるかなぁ。。。\nあと、ログが増えてきた時にどういった分割構成ができるだろう？って思って考えてみたのが以下になります。\n構成パターン ログを複数扱う場合は次のようなパターンがありそうかと。\nタグ（fluentdのタグ）で識別 「@log_name」という名前＝fluentdのタグにてログを識別することで、異なるログを検索することができそうです。 タグであれば、プラグインによってはログ出力時に制御も可能だと思うので、td-agentの設定を変更したりすることもなく対応が可能かと。 ただ、ログの種別ごとにKibanaのプロセスを別にして起動したいといった用途には向いてなさそうです。\ntype_nameによる識別 ElasticSearchの機能であるtypeを利用したログの識別パターンです。\nfluent-plugin-elasticsearchの設定でtype_nameを指定しました。 ここを別の名前にすることで、識別することも可能です。\nただし、この場合はKibanaの画面から指定して検索することができません。 →コメント頂きました。検索条件に「_type:タイプ名」と検索することでtypeを利用した検索が可能です。\nタグ（@log_name）でも識別できるようにするなどの工夫が必要です。 その代わり、タグ識別ではできなかったKibanaのプロセスを別にして起動することは可能になります。\nKibanaConfig.rbのTypeに値を設定することで、起動したKibanaが対象とするログを絞り込むことが可能です。 こうすることで例えば、apache用のKibanaとtomcat用のKibanaは別プロセスにして、ElasticSearchのクラスタは1つという構成も可能になります。\nElasticSearchサーバを別立て ElasticSearchサーバをそもそも別のプロセスor別のサーバで起動し、Kibanaも別々にすればログの識別も可能です。 可能ですが、色々と管理するものが増えてめんどくさそうですね。。。\nインデックス名変更 最後は、fluent-plugin-elasticsearchの設定で「logstash_format」をfalseにすれば、好きなindex_nameを付与できるので、 ログ種別ごとに名前を変更することで識別できます。\nただ、logstash形式でないインデックス名の場合、日付ローテーションができなかったり、Kibana内部で検索時に日付で検索対象を絞り込んで検索することで高速化するといった処理など、使えない機能が多々出てきてしまうのであまりおすすめじゃないかと。。。\nということで、流行りものは触っておこうということで、さわってブログ書いてみました。\n開発中に立てておいて、各サーバのログを流しこんでおくなどにも利用できるかもしれないです。 アラート通知などの機能が出てくるともっと便利かもしれないです。\n","date":1370874840,"dir":"post/2013/","id":"c4d3a917f623f58646ce93015d79e8e0","lang":"ja","lastmod":1370874840,"permalink":"https://blog.johtani.info/blog/2013/06/10/fluent-es-kibana/","publishdate":"2013-06-10T23:34:00+09:00","summary":"もう何番煎じだ？ってくらい書かれてますが、コリもせず書いてみました。 Elasticsearch＋Kibanaの環境を作って、タムタムさんのロ","tags":["kibana","elasticsearch","fluentd"],"title":"apache-loggen + fluentd + elasticsearch + kibana = ログ検索デモ"},{"contents":"昨日に引き続き、AWS Summit Tokyo 2013に行ってきました。\n@ryu_kobayashiさんからパシリを仰せつかるなどあり、忙しかったのですが楽しかったです。\n今日もすごい人出で、昼時の展示ブースは人だかりで、TDの方たち忙しそうでした。 後半はちょっとつかれたなぁ。 1日目よりも空調の温度が上がってたので快適でした。 飲物忘れたので、ちょっと喉がやられ気味でしたが。\nAWSはやっぱり勢いがあるんだなぁってのを実感しました。JAWS-UGまで残った感想です。 あとは、セルフハンズオンに参加するんだったかなぁというのもちょっとあります。あんまり触ったことないんで。\n以下はいつものメモです。\nAmazon Redshiftが切り開くクラウド・データウェアハウス 自己紹介と流れとニュース 6/5からTokyoリージョンでも利用可能に！ Redshiftどんなもの？ Redshift＝クラウド型データウェアハウス オンプレの課題 初期投資、運用管理、費用対効果 EMRと同じで、分析処理向けのサービス 簡単な利用例 各種データストア→S3→Redshift 各種データストア→EMR→Redshift Data Pipelineでデータの流れの処理がかける。 データロードはパラレルに実行可能 バックアップは管理コンソールからボタンででも可能。 クラスタのリサイズも管理コンソールからできるよ。 NRIでの評価 2012年末の限定公開してすぐに先行評価に参加\nRedshiftの性能は？\n500億件からの検索処理（1週間分のデータを抜き出して処理するSQL） 8XLノード2ノードで43秒、4ノードで27.8秒、8ノードで19秒 データロドも線形に性能が上がる 1.2億件の検索処理は4ノードより8ノードのほうが性能劣化 EMRとRedshiftの比較。1.5TB、500億件でのJOIN＋集計処理でRedshiftのほうが早かった。 Redshiftのチューニングポイント\nインデックスが存在得ず、Distribution Keyでノードに分散 Sort Keyも重要。データロード時間はSort Keyをつけると遅くなる ニガテなデータ形式もあるよ。EMRとかの組み合わせにすると安く済むこともあるよ\n簡単につくれるので、気をつけましょう。セキュリティとか。統制されないものが乱立してくるんで。\nそこでNRIですよ！（宣伝） 出てきた性能に関するものだけど、「ケース１」「ケース２」とかってなってるので、その部分の詳細が書かれたレポートが公開されないとどんなのがニガテなのかとかわからなかった。\n事例紹介とか オンプレのデータをどうやってRedshiftに持ってくの？ インフォテリアのASTERIA WARP GUIツールでデータの変換とかして、S3に持って行って、Redshiftと連携できるよと。 無料セミナーの紹介 6/21、8/2にRedshiftの無料セミナーやりますよ。 インターネット上のユーザーの行動の可視化を実現したAWSによるビックデータ解析基盤 C-Finderのサービス紹介 元オプトの方。C-Finderの紹介。 10万ユーザの行動履歴の可視化。\nサイトに来たけど、行動せずに他サイトに移動したとか、サイトに来る前の状態ってのがわからない。これをC-Finderで可視化。\n例１：自動車業界 ライバル企業の動向を自社と比較したい。 Audi、BMW、ベンツで可視化。 例２：化粧品業界 Web上での化粧品のトレンドが見たい。 @cosmeサイトのPVとかから。 ユーザって会員登録とかしてる人を追っかけてるってことなのかなぁ？ よくわかってない。。。\nレポーティングサービスしてたけど、納品まで１ヶ月かかってた。 リアルタイムにみたいという要望が多かったのでASPをTISと開発 ASPサービスの開発したよ AWSで。 可視化というタイトルだったんだけど、期待してた可視化の話ではなかった。。。\nネット選挙クラウド　～オバマ大統領選挙の事例：データ解析からネット募金まで～ ボランティアで構成ってすごいな。 本番まで１年 みんな髭の人だｗ GoogleとかFacebookとかの人がボランティアで開発に参加。 予算は抑えながら、スケールアップダウンがすぐ出来てとか。 秒間10万回のI/OのDB SQSとEC2のSoftware queueの比較。Softwareキュー選ぶと、さらにドレがいいのかってのを選ばないとい。 AWSにあるサービスなら、造らなくてもいいのではとか。 CloudSearchはつかわなかったのかなぁ？ tsunami S3に静的ページをおいて、最後のとりでにしたり。 コードとか、ノウハウってどこまで公開されてるんだろ？ 同時通訳もあったんですが、英語を聞いてみようと聞いてましたが、まだまだダメですねぇ。\nパネルディスカッション「ウェブテクノロジーをエンタープライズで活かすには？」 趣旨 B2B、B2C間でのトレンドのやり取りが加速されてるよねと。 ICTはもはやコモディティ？ TD太田さん Consumerization Of IT 色々なものがSaaSになってきてる TD：Consumerization of Data Infrastructure オンプレ＜AWS＜TD 三井物産黒田さん 三井クラウド（プライベート＆パブリック） ユビキタス これまで使ってきたものがクラウドで動くのかとかが観点 電通平川さん マーケティングダッシュボードはsalesforceでは厳しかった？ ビジネスに注力したいので、柔軟で、質実剛健なICT基盤がほしい。 ディスカッション 新しい技術に対するスタンスは？\nいかにダメな部分を潰していくか（太田さん） R\u0026amp;Dを予算化して評価して取り組んでいく。評価でダメならつぎ。（黒田さん） 消費者の方たちがネットですごい勢いで活動してる。その人達へのアプローチが重要。（平川さん） コンシューマ系技術の懸念事項は？\nセキュリティ面。レベルがある。自分の所だけじゃなく、クラウドベンダーと二人三脚が必要。丸投げはNG（黒田さん） セキュリティ面の攻撃を受けたつぎの手をどう打つかが重要。堅牢性上げると、ユーザビリティが下がる。（平川さん） 法規制的に出せないとかもある。持ちきれないデータもあるよね。（太田さん） 何を見分けてどうやって取り組むか？\nとりあえず、やってみる。そこで見える課題に対応していく。見極めるのは難しい（平川さん） ということは、すぐに出来る環境ってのは当たり前になってますよね。\n尖った技術＝セキュリティ面が弱い？みたいな印象があるのかなぁ？\nJAWS-UG AWSアップデート AmazonのCTO登場 Game Day Game Day。土曜日にやるよ。 障害を発生させて、それを復旧させる。 最もひどい壊し方をしたらかちｗ 最後はかるくボッチでした。。。 AWSあんまり使ってないからなぁ。。。\n","date":1370527200,"dir":"post/2013/","id":"d12c1c2a68be4c7fda5a7737d5493b4d","lang":"ja","lastmod":1370527200,"permalink":"https://blog.johtani.info/blog/2013/06/06/aws-summit-tokyo-day2/","publishdate":"2013-06-06T23:00:00+09:00","summary":"昨日に引き続き、AWS Summit Tokyo 2013に行ってきました。 @ryu_kobayashiさんからパシリを仰せつかるなどあり、忙しかったのですが楽しか","tags":["AWS","勉強会"],"title":"AWS Summit Tokyo 2013に行って来ました。(Day2) #awssummit"},{"contents":"ざっとインストールガイドとかCloudera Searchのソース眺めて、テキトーにメモを書いてみました。 （ユーザガイドはまだ読んでないです。）\nざっくりメモ ストリーム処理でインデックス作るときはFlume経由でSolrに SinkとEventの両方が用意されてる？（Flumeを良く知らないので、違いがわからない） FluemeからはリモートのSolrに対してインデックス登録するクラスがある。SolrServerDocumentLoaderがソレだと思う。 バッチ処理でインデックス作るときはMapReduceIndexerToolsってのを使ってSolrに SOLR-1301がベースになっている。色々と改良されてるようだけど、コアとなってる処理はSOLR-1301。 GoLiveってクラスの処理の中で、現在動作してるSolrに配布したバッチで作成されたIndexをマージする処理が書いてある。 HDFSへ出力されたインデックスはリモートのSolrからアクセスするとオーバヘッドとかどーなるのかなぁ？ 検索処理自体はHueでもできるけど、基本的にSolrCloud任せ インデキシングの処理のフローについてはCloudera Mrophlinesで定義 ということで、 2つの流れがありそう。\nHDFS→Flume→Solr HDFS→MapReduce→Solr で、まだ、わかってないですが、構成要素として\nHadoop（HDFS）：データソース Hadoop（MapReduce）：データ変換処理、バッチインデキシング Zookeeper：SolrCloudのクラスタ管理 Solr：インデキシング、検索エンジン Flume：データをストリーミングでSolrへ Coudera Morphlines：HDFSからSolrまでのETLデータ処理を定義実行する環境 って感じでしょうか。 SolrCloudのクラスタとHadoopのクラスタが同一マシン上なのか、別なのかとか。組み合わせがどんなものができるのかがまだわかってないです。 ユーザガイド読んでみたらなにか出てくるかなぁ。\nちなみに、Cloudera SearchのgithubリポジトリにあるソースはCloudera Morphlinesのコードがメインで、SolrのHDFS対応版のソースがあるわけでは無かったです。\nSolrのHdfsDirectoryってのがClouderaのリポジトリにあるSolrには追加されていて、これが、HDFSのインデックスを読み込んだりする処理が出来る仕組みっぽい。 一応、SolrCloud以外（分散検索）も考慮された形になってるっぽい。 ってとこでしょうか。\n感想 読んでて思ったんですが、Cloudera Searchの肝はじつは、検索じゃなくて、Morphlinesにあるんじゃないかなぁと。今はSolrが出力先ですが、 その他のデータ変換処理とかが増えてくると、処理の流れがMorphlinesで定義できてデータ変換処理が簡便になりそうな気が。\nその他に気になる観点 CDH経由でSolrCloudのクラスタの管理するのかな？ SolrCloud用のクラスタとCDHのクラスタって同一マシンに載るの？別マシンにもできるの？ 併存したらIOがキツそうだけど Hueで検索アプリとか組めるの？（そもそもHueがわかってないんだけど。。。） ま、とりあえず、こんなとこで。 つぎは余力があれば、ユーザガイドかなぁ。 英語力。。。\n","date":1370489160,"dir":"post/2013/","id":"f45069216cd934b80ce882c9a2f2a08a","lang":"ja","lastmod":1370489160,"permalink":"https://blog.johtani.info/blog/2013/06/06/cloudera-search-memo2/","publishdate":"2013-06-06T12:26:00+09:00","summary":"ざっとインストールガイドとかCloudera Searchのソース眺めて、テキトーにメモを書いてみました。 （ユーザガイドはまだ読んでないです。","tags":["Cloudera Search","Hadoop","Solr"],"title":"Cloudera Searchメモ（妄想版）"},{"contents":"AWS Summit Tokyo 2013に行って来ました。\n@cocoatomoさんに行き掛けに出会ったので、アンデルセンの講演を一緒に聞いてました。 TDブースの@ryu_kobayashiさんに挨拶に伺ったりも。\nすごい人で、セッション間の入れ替え時には会場前のスペースが大変なことになってました。もう少し余裕のある建物のほうが良かったのかもしれないですねぇ。\nいつものように以下はメモです。\nRoad to AWS アンデルセンサービス とてもおいしいランチボックスでした。\n広島（ここ重要！）に本社のあるパン屋さん。\n2003年に汎用機からOpenシステムに 内製ではなく外注に。複数のSIerにお願いしてるとデータセンタに マスタ管理と生産管理はオンプレ 2004年に稼動時のネットワーク整備。店舗はISDNで、設定ミスとかを防ぐためにIIJのSMFサービスに PCはレンタル契約にしたので入れ替えを強制できる→レガシーシステムの対応が必要なくなる ネットワーク広帯域化→基本システムにデータセンターに。 2009年にリース満了などで、OSの変更とかミドルの変更という移行SI費用だけで結構な値段が。ものによっては会社もない。 データセンターの月額手数料にして、機器変更などの費用を平準化。仮想化など。 けど、サイジングにどうしても安全係数をかけてしまうことに。結構値段がかかる そこで、今後の方向性 SIerどっぷりのOLTP受発注基幹システムはSIerのホスティングで それ以外のシステムは外に出したい バッチの計算を早くすることができるとノーチラスさんから提案された バッチを外部化するか、性能あげるか。IOネックなどもありスペック上げるとコストになるから、外部化したい Hadoopを組むけど、オンプレじゃなくてAWSにした。ノウハウがないので、ノーチラスさんにお任せした。 AWSのEMRを利用。4時間かかっていたものが40分で。 EDIのサーバを6ヶ月でAWSに移行 S3絡みで2度の問題が。性能劣化があった。 パッケージ開発環境がAWSにあるなら、AWSでも動くでしょ？（NTTイントラマートとか） SIerどっぷりの部分もAWSに持っていく？ アンデルセンサービスの部長さんからのAWSへの要望 メールサーバなどの基本サビスとか、コントロールパネルを充実して欲しい。 クラウド技術を活用したリアルタイム広告\u0026quot;Logicad\u0026quot;の入札・配信・ログ解析 Web広告の歴史 最初は広告主がWebサイト単位で契約 アドネットワークによる仲介 聞きそびれた。。。DSP？ アドネッエクスチェンジ SSP(Supply Side Platform) リアルタイムビッティング（RTB） RTPの仕組みを説明。 AWSとオンプレでシステムを構築してる。\nSSP事業者との取引はオンプレ 配信はAWS オンプレとAWSはAWS Direct Conectで接続 S3とHadoopの接続が安くなったり速くなったりするらしい。 オンプレミス側 Bidリクエスト：秒間数万件。。。 KVSのユーザ数は３億件。。。 AEROSPIKEというSSD向けのKVSを利用してる AWS側 ログはS3に。溜まったデータは定期的にEMRで解析。DynamoDBに入れてレポート作成 RabbitMQを使ってる。 ELBで外部からのリクエストはバランシング データセンタ間通信 遅延を複数コネクションを貼る方法で回避？ 非同期で、複数のMsgとAckをやり取りする。RabbitMQがこれに相当する機能を持ってる QueueとConsumerで多重送信が可能。 配信結果をオンプレ側に送るのにRabbitMQを使ってるのかな？ ハイブリッド構成を支えるAWSテクノロジー 聞くつもりだったんだけど、すごい人だったので、諦めて充電してた。\nAWSクラウドで構築する、ワールドクラスの分散クラウドアーキテクチャ エマージングソリューション部の部長のshot6さん。\nマルチAZ（アベイラビリティゾーン）モデル AWS固有のコンセプト。 ELBやDynamoDBやRDS、S3とか。\nマルチリージョンとは違うよと。マルチリージョンは結構難しいので。 マルチリージョンがどんなに大変かをこれから説明。\nマルチリージョンアーキテクチャ（これは別物） 複数のリージョンを利用して作る。 AWSのビルディングブロックではカバーしない範囲をカバーしないとダメとか。 リージョン間の通信は基本的に非同期 ディザスタリカバリ コストバランス見てから決めるよね。 CAP定理とかもいろいろと出てくるよね。 合意プロトコル。正確性、生存性（時間が制限されても大丈夫）、理論的にパフォーマンス出る？ 非同期レプリケーションになる（1トランザクション当たりのオーバヘッドが大きいから）けど、復旧の難しさがある。 GlusterFSとかでやってるとこもある。 NetflixはCassandraをクオラム＋Geo-Replicationでマルチリージョンを構成してる。 マルチリージョンでのデータ一貫性は維持がむずい 注意点 必要になるまで分散させない。 まずは、マルチAZを考えましょう 物理制限を考慮する 同期型だとタイムラグあるし。 複合障害の伝搬をどう抑えるか。 NetflixはHYSTRIXというのがいて遮断できるようにしている 自動化が重要。ロールバックとかロールアウトとか。 テストをどーするの？ 本番環境でアクティブ/アクティブ構成でのテスト。 ちゃんとフェイルオーバするかなどを実環境でやってる。DB落としたり。。。 障害は避けられないので、受け入れて日常に取り込むべきだよねと。\nAmazon.comではGameDay NetflixはChaos Monkey（OSS） Obama for America リカバリーオリエンテッドコンピューティングパターン\nボーアバグ：再現可能なソフトウェバグ ハイゼンバグ：通常ではありえないパターンで発生するバグで、調査が大変 ということで、マルチAZがいいよ 同期式レプリケーションを前提にできる。 アプリ開発者がアプリにフォーカスできる。分散系の難しいところはAWSが隠蔽してくれるから。 ","date":1370424600,"dir":"post/2013/","id":"1fe14e2e02b6e65e6e6e2ae3d8ddcc9f","lang":"ja","lastmod":1370424600,"permalink":"https://blog.johtani.info/blog/2013/06/05/aws-summit-tokyo-day1/","publishdate":"2013-06-05T18:30:00+09:00","summary":"AWS Summit Tokyo 2013に行って来ました。 @cocoatomoさんに行き掛けに出会ったので、アンデルセンの講演を一緒に聞いてました。 TDブースの@ry","tags":["勉強会","AWS"],"title":"AWS Summit Tokyo 2013に行って来ました。(Day1) #awssummit"},{"contents":"Cloudera Searchは次のようなモジュールから構成されています。 これはCloudera Searchのモジュールで、さらにこれらがSolrとかを使ってるみたいですね。pom.xmlを見たら何を使ってるかがわかるかな。\ncdk-morphlines search-contrib search-core search-flume search-mr search-solrcell てきとーに、README.mdみながらメモを残してみました。ソースとかはまだ読んでないです。 ざっと眺めたけど、インデキシング処理の話がメインで、検索側がどうやって動くかってのがわからなかったなぁ。 ユーザガイド（注：PDF）ってのがあるから、これを読んでみるか。。。\n各モジュールについては、以下。\ncdk-morphlines（Cloudera Morphlines） Cloudera Morphlinesという名前みたい。 検インデキシングアプリの構築、変更をラクにするためのフレームワーク。 ETLの処理チェインを簡単にCloudera Searchにデータを入れる設定（Extract/Transform/Load処理）がかけると。 バッチ処理、Near Real Timeのために使えるみたい。検索結果をさらに入れるとかもできるんかなぁ。？\nUnixパイプラインのの進化版みたいなもので、一般的なレコードに対するStream処理から、Flueme、MapReduce、Pig、Hie、SqoopのようなHadoopコンポーネントも使えるみたい。\nHadoop ETLアプリケーションのプロトタイピングにも使えて、リアルタイムで複雑なStreamやイベント処理やログファイル解析とかに使えるの？\n設定ファイルのフォーマットはHOCONフォーマット。AkkaやPlayで使われてる。\ncdk-morphlines-core Cloudera Morphlinesのコンパイラ、実行環境、コマンドのライブラリを含んでる。 ログファイル解析やsingle-lineレコード、multi-lineレコード、CSVファイル、正規表現パターンマッチ、フィールドごとの比較とか条件分岐とか、文字列変換とか色々なコマンドを含んでる。\ncdk-morphlines-avro Avroファイルやオブジェクトの抽出、変換、読み込み処理コマンド\ncdk-morphlines-tika バイナリデータからMIMEタイプを検出して、解凍するコマンド。Tikaに依存\n雑感 Cloudera Searchへのデータの流し込みを設定ファイルに記述して実行するとデータの変換処理とかが記述できるって感じかな？ Morphlinesのコマンドとして独自処理や使えそうな処理を作ることで、いろんな処理ができるって感じかなぁ。\nsearch-core Solrに対するMorphlineコマンドの上位モジュール\nsearch-solrcell Tikaパーサを使ったSolrCellを使うためのMorphlineコマンド。 HTML、XML、PDF、Wordなど、Tikaがサポートしてるものがサポート対象。\nsearch-flume Flueme Morphline Solr Sink。 Apache Flumeのイベントから検索ドキュメントを抽出、変換し、SolrにNearRealTimeで読み込むためのコマンド\nsearch-mr HDFSに保存されたファイルに含まれる大量データをMapReduceで処理してHDFS上の検索インデックスに焼きこむモジュール。\nMapReduceIndexerToolは入力ファイルの集合からSolrのインデックスシャードの集合を作るためのmorphlineのタスクで、MapReduceのバッチジョブドライバー。 HDFSにインデックスを書き込む。 動作してるSolrサーバに対して出力されたデータをマージするのもサポートしてる。\nとりあえず、Near Real Time検索するにはFlueme使って、バッチ処理でインデックス焼くのはMapReduceIndexerToolみたいだなぁ。\n","date":1370412720,"dir":"post/2013/","id":"e30258aeb8475d4c27f7935945671856","lang":"ja","lastmod":1370412720,"permalink":"https://blog.johtani.info/blog/2013/06/05/cloudera-search-modules/","publishdate":"2013-06-05T15:12:00+09:00","summary":"Cloudera Searchは次のようなモジュールから構成されています。 これはCloudera Searchのモジュールで、さらにこれらがSolrとかを使っ","tags":["Cloudera","Hadoop","Solr","Cloudera Search"],"title":"Cloudera Searchのモジュールたち"},{"contents":"AWS Summitに来ていたのですが、TLでは、Cloudera Searchが賑わってました。 ということで、軽くどんなものか読んだり調べたりしたメモを残しとこうかと。 英語力はあやしいので、おかしいとこがあったらツッコミを。\nCloudera Searchとは？ CDH4.3に対応したCDHユーザ向けの検索システム（beta版）なのかな？ CDHに統合された検索フレームワークなのかな？\n基本はLucene/Solr 4.3でHadoopのペタバイトデータを検索することができるようになるみたいです。\nどんな仕組み？ 次のものを利用しているようです。（GithubのREADMEから。）\n使ってるもの Apache Solr(4.3.0＋α？) Apache Lucene（Solrつかってるからね） Apache SolrCloud（うーん、Solrに含まれるのに別に出してるのなんで？） Apache Flume Apache Hadoop MapReduce \u0026amp; HDFS Apache Tika SolrCellとしてSolrにも組み込まれてる、いろんな文書（WordとかHTMLなどなど）からメタデータと本文データとかを取り出せるライブラリラッパー。実際にはさらにpdfboxとかを使って各文書からのデータを取り出してる。 何ができるの？ HBaseやHDFSの用にZookeeperを使ってインデックスのシャーディングや高可用性ができる。（SolrCloudがZookeeperを使ってるからね。） MapReduceのジョブの出力から自動的にSolrのインデックスにデータをマージできるらしい。 Cloudera Managerを使って、デプロイ、設定モニタリングなどが可能。\nFlumeのフィードをつかって、ストリーミングしてインデックスを作れる。FluemeがデータをSolrに流しこむのかな？ 将来的にはHiveやHBaseのテーブルをインデックスすることも可能になるらしい。Impalaクエリの結果もフィードできるのか？\nApache Blurってキーワードも出てきた。HDFSのデータからLuceneのインデックス作るのかな？ NGDataのチームがSolr/HBaseの統合とかしてるみたい。\n参考URL Cloudera社のブログ Cloudera SearchのFAQ（注：PDF） Githubのリポジトリ ","date":1370412300,"dir":"post/2013/","id":"cd90bce912f5743226af94c1efaaa4a7","lang":"ja","lastmod":1370412300,"permalink":"https://blog.johtani.info/blog/2013/06/05/what-is-cloudera-search/","publishdate":"2013-06-05T15:05:00+09:00","summary":"AWS Summitに来ていたのですが、TLでは、Cloudera Searchが賑わってました。 ということで、軽くどんなものか読んだり調べたりした","tags":["Cloudera","Hadoop","Solr","Cloudera Search"],"title":"Cloudera Searchってのが出たらしい（とりあえず、雑感？）"},{"contents":"憧れ？のfluentを使ってみました。 こちらの記事で紹介したZoomdataを最近触っているのですが、お試しにfluentdでデータ流し込むプラグインを作ってみようかなぁと。（今は、Javaでの接続も書いていて、主にそっちを使っています。） ということで、作ってみました。fluent-plugin-zoomdata。\n基本的にはtagomoris先生のfluent-plugin-growthforecastを参考（パクリ？）にさせてもらいました。 作っている最中もここわからんってツイートに反応していただき、大変助かりました。 私はベースがJavaの人間なので、手探り状態でRubyを書いています。そこおかしいんじゃないの？とかあればコメントもらえると嬉しいです。\nZoomdataのAPI ZoomdataのAPIはこんなかんじで、JSONをHTTPSでPOSTするものになります。\n指定する必要があるものは、以下の項目です。\nsource：Zoomdataのデータ保存先（Zoomdataでのデータを保存する単位。） user：Zoomdataのユーザ名 password：Zoomdataのユーザのパスワード JSONデータ：Zoomdataでグラフ化するデータ sourceはデータ保存先の名称で、この単位でZoomdataはデータを保存、描画します。fluentdのタグをこれにするとわかりやすいかなぁ？と考えていったん、実装してみています。\nで、作成したプログラムを使いつつ、Zoomdataの検証をしたかったので、つぎのような簡単なプログラムを作って動かしてみました。\nサンプルプログラムの構成 基本的にJavaの人なので、クライアントはJavaで書いてます。 CLIプログラムで適当なJSONを作って、fluent-loggerを使って、fluentdに投げ込みます。\nfluentdにfluent-plugin-zoomdataを設定して、localのZoomdataサーバに対してHTTPSでJSONをPostする仕組みです。(初keynote)\n利用しているライブラリなどのバージョンは次の通り\ntd-agent.x86_64：1.1.12-0 fluent-logger：0.2.8 Zoomdata：1.0.3 バグ？ で、Zoomdataにいろんなデータを流し込んでみたのですが、つぎのようなエラーが出て、エラーが出力されたあとはZoomdataにデータが流れ込まなくなってしまいました。\n2013-06-03 14:42:33 +0900 [warn]: emit transaction failed error=\u0026#34;SSL_connect returned=1 errno=0 state=SSLv3 read finished A: sslv3 alert handshake failure\u0026#34; 2013-06-03 14:42:33 +0900 [warn]: /usr/lib64/fluent/ruby/lib/ruby/1.9.1/net/http.rb:799:in `connect\u0026#39; 2013-06-03 14:42:33 +0900 [warn]: /usr/lib64/fluent/ruby/lib/ruby/1.9.1/net/http.rb:799:in `block in connect\u0026#39; 2013-06-03 14:42:33 +0900 [warn]: /usr/lib64/fluent/ruby/lib/ruby/1.9.1/timeout.rb:54:in `timeout\u0026#39; 全ログはこちら。\nまだきちんと問題を調査しないでブログを書いています、すみません。\n現象 ログが発生した時の症状です。\nクライアントプログラムは送信が続いており、エラーは出ない td-agent.logに先ほどのエラーが出力 別途type fileにて出力しているログも停止 想像 とりあえず、ログを見た想像、所感です。\n問題の箇所はfluent-plugin-zoomdataからZoomdataサーバへのデータ送信部分 emit処理内部で、HTTPSでデータをPOSTする処理でエラーが起きて リトライ処理とか書いてないので、emitがコケて、その後データが送信されなくなる emitで例外をつかみそこねてるのがあるから止まってる？ とまぁ、ちゃんと仕組みを理解しないでRubyとか書くからこうなるんですねぇ。 あとでちゃんと調べて考えて、改良してブログ書きます。\n悩んでいる点、今後手を入れたい点 上記バグとは別に作りの点でいくつか悩んでる点も書いてみます。\nBufferedOutputにしてみたい fluentdのバッファリングを使って、Zoomdataが落ちていても使えるようにしたいと思っているのでBufferedOutputで書くのがいいのかなぁとか。 ちょうどいいスライドがあったので、読みながらまずは中身を理解してみよう。\nZoomdataのsource、userなどの扱い 基本的には設定ファイルで切り替えるのが妥当かなぁと思っています。\nただ、Zoomdataのsourceやuserが増えるたびにfluentdの設定を書き換えて再起動するのかなぁと。userはしょうが無いにしても、sourceは設定じゃない所で切り替えたいなぁと。\nで、切り替えるのにつぎの案があるかなぁと。\nタグで指定（今実装してるもの） メッセージにメタ情報とボディ構造を設ける 設定をどんどん増やす（やりたくない） 1と3はまぁ、いいかと。2.のパターンはどうなのかなぁと。 毎回のメッセージでヘッダ部分が送信されるのはなんだか無駄だなぁというのが否めないので悩ましいところです。1、2の両方対応できるように作るのもありか。\n{ \u0026#34;header\u0026#34;: { \u0026#34;source\u0026#34;: \u0026#34;source_name\u0026#34;, \u0026#34;user\u0026#34;: \u0026#34;userid\u0026#34;, \u0026#34;password\u0026#34;: \u0026#34;userid\u0026#34;, }, \u0026#34;body\u0026#34;: { \u0026#34;label\u0026#34;: \u0026#34;label1\u0026#34;, \u0026#34;count\u0026#34;: 1 } } ということで、fluent触って遊ぶの楽しいですね。Rubyの勉強にもなりそうだし。 ちょっとずつ頑張ってみようかなぁと。 まぁ、まだ私以外にニーズは無さそうなプラグインですが。\n","date":1370234580,"dir":"post/2013/","id":"494557db52824555864d1106278cd1f0","lang":"ja","lastmod":1370234580,"permalink":"https://blog.johtani.info/blog/2013/06/03/fluent-plugin-zoomdata-0-0-1/","publishdate":"2013-06-03T13:43:00+09:00","summary":"憧れ？のfluentを使ってみました。 こちらの記事で紹介したZoomdataを最近触っているのですが、お試しにfluentdでデータ流し込む","tags":["Zoomdata","fluentd"],"title":"fluent-plugin-zoomdata作りました＋悩み事とか"},{"contents":"最近、Markdownで文章を書くのに慣れてきました。 ということで、ブログをMarkdownで書けないかなぁと思い、TLの人たちのブログを見たりしていると 「Octopress」というキーワードがあるじゃないですか。 ということで、Github Pages作って、Octopressを使ってブログを書いてみました。 こちらです。\n独自ドメインは昨年から使っているものがあったので、ついでに独自ドメインの設定もしてみました。 ケチなので、.comなどではなく、.infoですが。。。\nということで、徐々にOctopressに移行していこうと考えているところです。 こちらのブログも当面は残しておく予定です。（有料会員は解約して、広告が出る形になると思いますが。。。）\nOctopressでこんなの便利だよとかアレば教えてもらえると助かります。\n","date":1370228038,"dir":"post/2013/","id":"16f10764f0ccce42d5be8cfeac36b446","lang":"ja","lastmod":1370228038,"permalink":"https://blog.johtani.info/blog/2013/06/03/octopress%E3%82%92%E8%A9%A6%E3%81%97%E4%B8%AD/","publishdate":"2013-06-03T11:53:58+09:00","summary":"最近、Markdownで文章を書くのに慣れてきました。 ということで、ブログをMarkdownで書けないかなぁと思い、TLの人たちのブログを見","tags":["misc"],"title":"Octopressを試し中(Jugemより移植)"},{"contents":"昨年から、ブログをどうしようかって話をしていて、そのままになっていたのですが、Octopress＋Github Pagesというのがあるらしいと聞きつけて（Twitterで見かけたのかなぁ？）ちょっとやってみました。\n最近は、ドキュメントをMarkdownで記述しようとして癖をつけているのもあり、 ちょうどいい練習になるかなぁと。\nということで、まずは手始めのエントリーでした。 いくつか書きたいこともあるので、調べながら書いていこうかと。 まだ、イメージできてないこと\n画像をどうやって貼るの？ About meみたいなのも貼り付けたい bitbucketやTwitterのリンクとかも アフィリエイトも貼る（とりあえずSolr本を） 検索とかは？ デザインは？ などなど。ちょっとずつ調べていこうかなぁと。 あ、調べたことも書いてくのもありか。\n","date":1370098620,"dir":"post/2013/","id":"dbcc4002c15afefef853a08a0804ba3a","lang":"ja","lastmod":1370098620,"permalink":"https://blog.johtani.info/blog/2013/06/01/first-octopress/","publishdate":"2013-06-01T23:57:00+09:00","summary":"昨年から、ブログをどうしようかって話をしていて、そのままになっていたのですが、Octopress＋Github Pagesというのがあるらしい","tags":["octopress","misc"],"title":"Octopress始めました"},{"contents":"Lucene/Solr 4.3.0がリリースされた（LuceneのChanges、SolrのChanges）ので、lucene-gosen 4.3.0をリリースしました。（ダウンロードはこちら） なお、lucene-gosen 4.3.0ですが、Lucene/Solr 4.2.1以下のバージョンのLucene/Solrでは利用できません。 注意してください。 また、lucene-gosen 4.2.1もLucene/Solr 4.3.0では動作しませんので注意が必要です。\n現時点（2013/05/06）では、lucene-gosen 4.3.0はLucene/Solr 4.3.0でのみ利用できます。 これは、先日のエントリにも書きましたが、LuceneにてAPIの変更が行われたためとなります。 いくつかのクラスおよびメソッドが廃止されたため、下位互換が保てない変更が入っているためです。\n独自のTokenizerやTokenizerFactory、TokenFilterFactory、CharFilterFactoryを作成されている方は、Lucene/Solrのバージョンアップを行う際は注意が必要です。\n","date":1367850324,"dir":"post/2013/","id":"11d4726484be418849e1f4200ade9535","lang":"ja","lastmod":1367850324,"permalink":"https://blog.johtani.info/blog/2013/05/06/lucene-gosen4-3-0%E3%82%92%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Flucene-solr4-3-0%E4%BB%A5%E4%B8%8A%E3%81%A7%E3%81%AE%E5%88%A9%E7%94%A8%E3%81%8C%E5%8F%AF%E8%83%BD%E3%81%A7%E3%81%99/","publishdate":"2013-05-06T23:25:24+09:00","summary":"Lucene/Solr 4.3.0がリリースされた（LuceneのChanges、SolrのChanges）ので、lucene-gosen 4.3.0をリリースしま","tags":["lucene-gosen"],"title":"lucene-gosen4.3.0をリリースしました。（Lucene/Solr4.3.0以上での利用が可能です）(Jugemより移植)"},{"contents":" アジャイルな時間管理術 ポモドーロテクニック入門 ポモドーロテクニック入門という本を読みました。 きっかけは、Twitter上で何度か「ポモドーロ」という単語を何度か見ていたためです。 最初は、なんだろう？というのが発端です。 「ポモドーロ＝トマト」なのですが、実際にはトマト型のキッチンタイマーが元になっているらしいです。 このタイマーを使った時間（タスク）管理術がポモドーロ・テクニックです。\n私は、ここ数年、複数の仕事がパラで走ることが時々ありました。 このような場合に、日によって異なる複数のタスクが存在します。 このとき、異なるタスクにスイッチするのに結構な時間を取られます。。。 また、急な割り込みが入った時も同様に、以前のタスクに戻るのになにしてたっけ？となることが多々あります。 普通に自己管理ができている方なら問題ないのでしょうが、私は結構ニガテでした。 そのようなときに、Twitter上で「ポモドーロ」という単語を見かけて、軽くググってみたところ、 タスク管理、時間管理によさそうな本だったので、その点を矯正するのも兼ねて、読んだ次第です。 また、タスクに集中できるという利点もあるそうです。\n本については、少し読みにくいところがありました。 ポモドーロテクニックとはどんなものかという全体像や単語に関する説明がないままに、話が進んでいくので。。。 1度読み終わったあとに実践しながらパラパラめくっているような状況です。 実際には、個々人のやり方などを考慮しながら、改善していくべきなのもあり、型を説明してないのかもしれないですが、もうすこし概観がわかる感じのほうが良かったです。\nで、4月初旬くらいから実践してみています。 効果が実際にあるかというと、まだわからないです。\n私がポモドーロテクニックに利用しているのはキッチンタイマーではなく、pomodairoというAdobeAIR上で動くアプリになります。 ほかにもPomodoroAppというのもあるのですが、Free版だと登録できるタスクの上限があったので、pomodairoを選びました。（今見たら、3.0にバージョンが上がって、Limitがなくなってるかも） AIRだと、WinでもMacでも動作するのというも決定した要因です。\nまだ、1ヶ月経ってませんが、私が実践してきて良かった点、できてない点、うまくいってない点はつぎのような感じです。\n良かった点 目の前のタスクに集中できる。（25分スパンなので、Twitterを意識的に見なくできる。。。） 適度な休憩が挟める。25分に5分の休憩が入るので、適度な没頭になる（没頭し過ぎない） 自宅で作業するときにかなり有効。（5分の休憩時にTwitterやFB以外に漫画をパラパラ読んだりもできるので） ということで、自宅で作業するときには結構いいです。 自宅ですと、pomodairoを使っていてタイマーの音を気兼ねなく出せるので、きちんとポモドーロが回せます。\nできてない点 アクティビティ在庫管理。個人的にJIRAを使っていて、そこで管理しようと思っているのですが、うまくできてないです。pomodairoのアプリにもタスクを登録しているのもあり2重登録などを手間に思ってしまって。。。 レコーディングと今日のTodo作成。 インタラプトの記録 アクティビティ在庫管理ができてないのは、レコーディングがきちんと出来てないためでしょう。。。 二重管理になっている＋pomodairoで統計情報が出るが、当日分の統計情報がレコーディングできてないというのが痛いです。 また、このレコーディングが出来てないので、効果が出ているかがわからないという問題かと。。。 きりが悪かったりして、どうしても、仕事時間ギリギリまでタスクをこなしてしまい、レコーディング＋アクティビティ在庫の管理の時間が取れていません。 ここは意識してちゃんとやらないと意味がないよなぁと。今後の大きな課題です。\nうまくいってない点 できてない（やろうとしてできてない）点とは別に、どうもしっくり来ていないのがつぎのような点です。\nプログラミングしていると、25分のタイマーで区切りがすごく悪い時がおおい 自宅以外でのタイマー音が出せない 自宅以外での休憩の取り方 プログラミングをやっていて、乗ってきたタイミングでタイマーが鳴ってしまったり、 ちょっと頭のなかで整理していたあとの今まさに、頭のなかにある処理の流れをコードに落としている途中でタイマーがなってしまったり。 このような状況だと、休憩に入れなくて、ずるずるとコーディングを続けてしまうということが多々あります。 メモ（ソース上のコメントや手元）を残して休憩すればいいのでしょうが、どうしても今までの癖もありズルズルとやってしまい、すごく時間が経ってることが何度もあります。 ポモドーロテクニック的にはやはりNGなんでしょうが、なかなか治らない＋治したくない気もしています。 また、自宅以外の場合、基本的には自社ではなく客先に出ていることが多いのでどうしても音を出すことができません。 これもまた、切り替えができない要因になっています。 タイマーだけ携帯のアプリを使用しするという手もあるのでしょうが、この場合さらにレコーディングが出来ない状況に陥りそうで。。。 また、スマホだと電池が持たないのも問題点です。（Twitterを見るのに利用してるから電池が持たないという話もあるのですが。。。） レコーディングに関しては、手描きのメモを使うのがいいのかなぁと。本では＋や◎などの印を付けるだけにしておけば良いとありますが、アプリのタイマーだと自動でそれができるので、悩みどころです。 最後の休憩の取り方も、ネットやTwitterを見るのもありなのですが、画面から離れる休憩を取りたいなぁと思うところもあり。。。 職場だと技術書やWEB+DBのような雑誌はあるのですが、休憩にはあまり向いていないなぁと。\nつらつらと書いて来ましたが、本を読んで、1ヶ月実践してきた（できてないとこも多いが）現状をメモしておきます。 こうやってるよ、こうしたら良かったよ、こうしてみれば？などありましたら、コメントいただけると助かります。\n来週以降はとりあえず、JIRAできちんとアクティビティ在庫管理をしながら、1日の結果をレコーディングしていくのを意識していこうと思います。\n","date":1367592139,"dir":"post/2013/","id":"db97311c24809f103575d8a7fee19680","lang":"ja","lastmod":1367592139,"permalink":"https://blog.johtani.info/blog/2013/05/03/%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E5%9B%9E%E3%81%97%E3%81%A6%E3%81%BE%E3%81%99%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF%E5%85%A5%E9%96%80%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2013-05-03T23:42:19+09:00","summary":"アジャイルな時間管理術 ポモドーロテクニック入門 ポモドーロテクニック入門という本を読みました。 きっかけは、Twitter上で何度か「ポモドーロ","tags":["読書"],"title":"ポモドーロ回してます。（ポモドーロテクニック入門読みました）(Jugemより移植)"},{"contents":"まだ、Vote公開されていない、Solr 4.3（2013/04/25 11:00現在）ですが、 ひさびさに訳してみた。詳細まで追っていないので、誤訳があるかもしれないですが。 おかしいとこあったらツッコミを。\n○Solr 4.3.0のChanges ・Upgrading from Solr 4.2.0 1.schema REST APIのcopyFields、dynamicFieldsの出力パスをCamelCaseに。他も同様。（SOLR-4623） 2.Slf4j/logging jarをSolrのwarに含めないことに。すべてのlogging jarはexample/lib/extに。（SOLR-3706、SOLR-4651） 3.SolrCloudでハードコードされてたhostContextとhostPortをdeprecatedに。Solr5.0で削除する。（SOLR-4622）\n・New Features 1.SOLR-4648　PreAnalyzedUpdateProcessorFactoryでPreAnalyzedFieldの機能をほかのフィールドタイプでも使えるようにした。詳しくはJavadocとexampleを見て。 2.SOLR-4623　REST APIで現在のschemaのエレメントをすべて読めるように。REST APIの返却の形式として、XMLとJSONとschema.xmlの形式を追加REST APIのパッケージを変更。 クラス名も変更しschemaにフォーカスした機能も除去。今後のschema以外のREST APIのために。 copyFieldsとdynamicFieldsの出力パスをすべてlowercaseのものからCamelCaseに変更。他のREST APIも同様。 3.SOLR-4658　REST APIリクエストでschemaを変更できるようにするために、「managed schema」を導入。solrconfig.xmlに「\u0026lt;schemaFactory class=\u0026ldquo;ManagedSchemaFactory\u0026rdquo; mutable=\u0026ldquo;true\u0026rdquo;/\u0026gt;」を追加。REST APIリクエストでスキーマ変更が可能にするために。 4.SOLR-4656　2つのハイライトパラメータ（hl.maxMultiValuedToMatch、hl.maxMultiValuedToExamine）を追加。 hl.maxMultiValuedToMatchは指定された数のsnippetが見つかったらそれ以降の探索を停止する設定。multiValuedフィールドがどんなに離れてても探索する。 hl.maxMultiValuedToExamineは指定された数のmultiValuedのエントリ数を調査したら探索を停止する設定。 両方を指定した場合、最初のlimitに達したら停止する。ドキュメント全体をハイライトするためにコピーされるのを削減する。これらの最適化はmultiValuedフィールドに大量のエントリが存在する時に効く。。。 5.SOLR-4675　PostingsSolrHighlighterでper-field/クエリ次のパラメータ指定のサポート 6.SOLR-3755　既存のshardを動的にsplitしてshardを追加するための新コレクションAPI（shard splitting） 7.SOLR-4530　DIH：TikaのIdentityHtmlMapperを使う設定の提供 8.SOLR-4662　solr.xmlにあるSolrCoreの定義よりもディレクトリ構造で見つける。また、solr.xmlのフォーマットを変えて、solrconfig.xmlに近くする。Solrのこのバージョンは旧スタイルの例で提供するが、新しいスタイルも試すことができる。Solr 4.4では、新しいスタイルで提供し、Solr 5.0では旧スタイルは廃止する予定。 SOLR-4347　Adminハンドラで新しく生成されたコアがsolr.xmlに永続化される SOLR-1905　Adminリクエストハンドラで生成されたコアもsolr.xmlに永続化される。また、solr.solr.datadirのようなプロパティの用にsolr.xmlに永続化される問題のfix。 9.SOLR-4717/SOLR-1351　SimpleFacetで同じフィールドに異なるファセットを適用出来るlocalParamsを追加 10.SOLR-4671　CSVResponseWriterのpseudoフィールドのサポート 11.SOLR-4358　HttpSolrServerでuseMultiPartPostでstream名を送信できる ・Bug Fixes 1.SOLR-4543：solr.xml/solr.propertiesでshardHandlerFactoryの設定が動作しない 2.SOLR-4634：Java 8\u0026quot;Nashorn\u0026quot;JavaScript実装の動作に関するscripting engineのテストのfix 3.SOLR-4636：SolrIndexSearcherをオープンする時に何かの理由でreaderがオープンできない時に、ディレクトリがリリースされない 4.SOLR-4405：Admin UIのadmin-extraファイルでcore-menuが表示されない 5.SOLR-3956：group.facet=trueでfacet.limitがマイナスの時の動作 6.SOLR-4650：copyFieldでダイナミックフィールドや暗黙的なフィールドがsourceでマッチしない。4.2で入ったバグ 7.SOLR-4641：Schemaで、illegalなフィールドパラメータで例外が発生するようにする。 8.SOLR-3758：SpellCheckComponentが分散groupingで動作しない。 9.SOLR-4652：solr.xmlプラグインのresource loaderで共有ライブラリの挙動がおかしい 10.SOLR-4664：ZkStateReaderがaliasを更新しても見えない 11.SOLR-4682：CoreAdminRequest.mergeIndexが複数コアやindexDirが複数の場合にマージできない 12.SOLR-4581：Solr4.2で数値フィールドのファセットでマイナスの値があるとソートがおかしい 13.SOLR-4699：Admin Handlerでデータディレクトリの場所がファイルシステムだと思い込んでる。（RAMの場合もある） 14.SOLR-4695：non-cloudセットアップでもコア管理のSPLITが使えるように 15.SOLR-4680：exampleのspellcheck設定のqueryAnalyzerFieldTypeの修正 16.SOLR-4702：exampleの/browseの「Did you mean?」のサジェストをFix 17.SOLR-4710：Zookeeperから全ノードをアップせずにコレクションを削除できないのを修正 18.SOLR-4487：HttpSolrServerからのSolrExceptionがリモートのサーバから戻るHTTPステータスコードを含んでない 19.SOLR-4661：Admin UIのレプリケーションで現在のレプリカ可能なマスタのバージョンを正確に表示 20.SOLR-4716,SOLR-4584：SolrCloudリクエストプロキシがTomcatなどJetty出ないコンテナで動作していない 21.SOLR-4746：Distributed groupingのトップレベルグループコマンドでSimpleOrderedMapの代わりにNamedListを使う。non-distributed groupingと出力形式が異なるため。 ","date":1366856040,"dir":"post/2013/","id":"286a9a4ee373398d7d2c93862c5f6661","lang":"ja","lastmod":1366856040,"permalink":"https://blog.johtani.info/blog/2013/04/25/solr4-3-0%E3%81%AEchanges%E3%82%92%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/","publishdate":"2013-04-25T11:14:00+09:00","summary":"まだ、Vote公開されていない、Solr 4.3（2013/04/25 11:00現在）ですが、 ひさびさに訳してみた。詳細まで追っていないので、","tags":["solr"],"title":"Solr4.3.0のChangesを訳してみた。(Jugemより移植)"},{"contents":"現在、RC3のVoteをやっている最中（2013/04/24　16:00時点）で、まだリリースされていない、4.3.0についてです。 開発者MLでChangesの書き方を考えないとね、みたいなエントリーが流れてて気になっていたので、訳してみた。 lucene-gosenの実装を変更しないといけないっぽいなぁ。Lucene/Solr 4.2.1以前と4.3.0でI/Fとかが変わることになりそうです。（3.とか8.とか） （ここで力尽きて、それより下はまだ読んでないです。。。）\n○Changes in backwards compatibility policy 1.LUCENE-4810：EdgeNGramTokenFilterが同じ入力tokenから複数のngramを生成した時にpositionを増加させていないのを修正 2.LUCENE-4822：KeywordMarkerFilterがabstractクラスで、サブクラスがisKeyword()メソッドを実装する必要がある。新しく、SetKeywordTokenFilterというクラスにすでにある機能を分解した。 3.LUCENE-4642：TokenizerとサブクラスのAttributeSourceのコンストラクタを削除。代わりにAttributeFactoryをもつコンストラクタを追加。 4.LUCENE-4833：IndexWriterConfigがsetMergePolicy(null)の時にLogByteSizeMergePolicyを使っているのをデフォルトmerge policyをTieredMergePolicyに。また、nullが引数に渡されたらExceptionを返す。 5.LUCENE-4849：ParallelTaxonomyArraysをDirectoryTaxonomyWriter/Readerのためのabstractとして作成。あと、o.a.l.facet.taxonomyに移動。 6.LUCENE-4876：IndexDeletionPolicyをInterfaceではなく、abstractクラスに。IndexDeletionPolicy、MergeScheduler、InfoStreamでCloneableをimplement。 7.LUCENE-4874：FilterAtomicReaderと関連するクラス（FilterTerms、FilterDocsEnumなど）でフィルタされたインスタンスをforwardしないように。メソッドが他のabstractメソッドを実装している場合に。（？） 8.LUCENE-4642, LUCENE-4877：TokenizerFactory、TokenFilterFactory、CharFilterFactoryの実装者は、少なくともMap\u0026lt;String,String\u0026gt;（SPIフレームワーク（Solrとか）によってロードされる）を引数にするコンストラクタを提供する必要がある。さらに、TokenizerFactoryはcreate(AttributeFactory,Reader)メソッドを実装する必要もある。\n","date":1366786800,"dir":"post/2013/","id":"99f5219da22485d0872a2529599c8440","lang":"ja","lastmod":1366786800,"permalink":"https://blog.johtani.info/blog/2013/04/24/lucene-4-3-0%E3%81%AEchanges%E3%81%AB%E3%81%82%E3%82%8Bchanges-in-backwards-compatibility-policy%E3%81%8C%E6%B0%97%E3%81%AB%E3%81%AA%E3%81%A3%E3%81%9F%E3%81%AE%E3%81%A7%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/","publishdate":"2013-04-24T16:00:00+09:00","summary":"現在、RC3のVoteをやっている最中（2013/04/24 16:00時点）で、まだリリースされていない、4.3.0についてです。 開発者ML","tags":["solr"],"title":"Lucene 4.3.0のChangesにあるChanges in backwards compatibility policyが気になったので訳してみた。(Jugemより移植)"},{"contents":"第2回目も参加しました。 とりあえずメモ。 自分には欠けてる視点の話しなので面白かった。 ちょっと寒かったなぁ。\nエンジニアのためのスキルアップ勉強会『Tech Compass』 #tecomp ― Vol.2 「人気Webサービスの作り方教えます！」 ― 日時：2013/04/23 19:00 場所：パレスサイドビル9F マイナビルーム ◎自己紹介 ●株式会社Zaim／閑歳孝子 小学校3年からFMVで草の根チャットとかにつないでた。（すげー） これがいい記事ですよ。http://www.1101.com/umeda_iwata/ テレビとかで紹介されてるZaimやってます。 3つの基準　・日常的に使うもの ・普通の人が使うもの ・少なくとも自分は使うもの サービスの良さの基準 縦軸：影響の深さ 横軸：影響する人数 この面積が大きいのがいいんでは。 ●株式会社ワディット／和田裕介 いろいろ作ってます「カウントダウンチューブ」とか「君のラジオ」とか30～40くらい作ってます。 ・「ボケて」ってのやってます。 600万ボケ。アプリ120万DL　僕らがつくるための５Wについて ・なぜ？ ・サービスの根本となる「哲学」をみんなで共有できるかが重要 ・内向けのビジョンも大事 ・何を？ ・ユースケースで整理する ・いつ？ ・つくろう！すぐ作れるようにしようねって感じ ・誰と？ ・最強のチーム。意思決定がはやい。 自分主体でサービス設計して、作りなおすのをためらわない ◎ディスカッション Q：どうしてサービス作ったの？ A：エンジニアへのあこがれから、サービスを作った（閑歳さん） ものづくりという意味では、Webサービス以外もあるけど？（馬場さん） 学内のSNSのようなものを作ってて、アクセスが伸びるのが面白かった。（閑歳さん） 大学でlastfmみたいなものを研究してて。。。（和田さん） 社会に出てサービスを作るまでの話は？作って稼ごうって思ったのは？（馬場さん） あんまりなかった。（閑歳さん） すでに起業してた。サービス作ると実績として認められて仕事が入ってきてた。（和田さん） 直接あった時に反応がもらえるのが楽しい。（和田さん） Q：どうやって、チームを組み立てたりして開発とかしてきたのか？（馬場さん） A：「ボケて」まとめサイトでブレイクしたけど、アクセス数が落ちてない。 同年代の知人で色々とチームが組めてて楽しい（和田さん） はじめは一人でやってて、しかも構想とか。あとロゴだけ最初に作ってた。 ノマド的に作業してました。（閑歳さん） Q：チームがバラバラですが、困らないですか？ A：今のところ困ってないです。もっと人が増えると困るかもしれないですけど。（閑歳さん） それぞれが他に職を持ってるので特に困ってないです（和田さん） 向き不向きはあるんじゃないかなぁ。10人とかになるとどうなるか不明（閑歳さん） GoogleのMLでレスが早ければ問題ないかな。（和田さん） あとは、チームが大きくならないように上手く分割してる（？）（ふたりとも） Q：ユーザの声の吸い上げ方、サービス改善の判断材料は？ A：ユーザの声は聞くけど、全部取り込むものではない。 細かな点はユーザの声を取り込むけど、軸はブレないようにしてる（閑歳さん） 古参ユーザよりも新しいユーザを取り込むのが大事。（和田さん） nanapiのけんすうさん Q：品質はどうしてる？ A：セキュリティは絶対。（閑歳さん） 品質を気にするってのは難しい。品質を担保できる仕組みを作るとこまでいけるようにしたい。 投稿される画像はチェックしている。（和田さん） ","date":1366717542,"dir":"post/2013/","id":"36ff37ced0d3211db95a5ac0daac0c35","lang":"ja","lastmod":1366717542,"permalink":"https://blog.johtani.info/blog/2013/04/23/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass--tecomp--vol-2-%E4%BA%BA%E6%B0%97web%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9%E6%95%99%E3%81%88%E3%81%BE%E3%81%99%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2013-04-23T20:45:42+09:00","summary":"第2回目も参加しました。 とりあえずメモ。 自分には欠けてる視点の話しなので面白かった。 ちょっと寒かったなぁ。 エンジニアのためのスキルアップ勉強","tags":["勉強会"],"title":"エンジニアのためのスキルアップ勉強会『Tech Compass』 #tecomp ― Vol.2 「人気Webサービスの作り方教えます！」に参加しました。(Jugemより移植)"},{"contents":"だいぶ、ブログを書くペースが落ちてきてて、危機感を感じている今日このごろです。。。 今回は、個人的に利用しているJIRAのバックアップについて、ブログに残しておこうかと。\nさくらVPSのサーバを借りてJIRAを運用しています。 運用といっても、自分の備忘録のためというのが大半の理由です。 タスクを忘れないように管理するのと合わせて、その作業を行ったときのメモも残したいなと。\nバックアップといっても、同じサーバ内に保存しても意味がない＋AWSを触ると言いつつ1年以上経ってしまったので、 このへんで本腰を入れるという意味も込めてAWSのS3（ゆくゆくはGlacier）にバックアップを取る仕組みを作りました。 「作りました」というと凄そうですが、Cronとシェルだけで終わりました、なんて便利な世の中。 ということで、以下は作業の備忘録です。\n1.AWSのアカウント作成 アカウントを作ってください。ここは特に説明しなくてもいいかと。。。クレジットカードの登録が必要なのが注意点でしょうか。 アカウント作成後の1年間は無料枠と呼ばれる仕組みが用意されており、いろんなことが無料で行えます。 （まだ、S3しか使ってないので、他にももっと使わないと。。。）\n2.S3のバケット作成 AWSのアカウントが作成できたら、Amazon S3（Simple Storage Service）のバケットと呼ばれる、データの保存先を作成します。 作成手順はこちらの公式入門ドキュメント（英語）をそのまま行いました。 簡単な手順はこちら\nAWS Management Consoleと呼ばれるところから、S3のコンソールにアクセス 「Create Bucket」ボタンをクリック 「Bucket Name」を入力し、リージョンを選択したら「Create」ボタンをクリック 以上でバケットが作成されました。これだけです。WebのConsoleからファイルをアップロードすることも可能です。 ただ、今回はさくらVPSから定期的にバックアップしたいのでシェルでアクセスできるようにします。\n3.AWSのアクセスキーとシークレットアクセスキーの取得 次に紹介するs3cmdというツールを利用するのに、AWSのアクセスキーとシークレットキーが必要になります。 取得方法はこちらを参考にしましたが、今は日本語のページが用意されています。 セキュリティ証明書（Security Credentials）のページで、「アクセス証明書」というタブで、「新しいアクセスキーを作成する」リンクをクリックしてください。 アクセスキーIDが新しく表示されます。このアクセスキーIDとシークレットアクセスキー（表示リンククリック後に表示される）をメモしておきます。\n4.s3cmdのインストール 世の中には便利なものを作ってくれる方がいるもので。 s3cmdと呼ばれるS3へアクセスできるコマンドラインツールが存在します。 ということで、こちらをインストール。これまた、便利なものでインストール手順を書いてくれれてるブログもありました。（あれ、なんか、見たことある名前がURLにはいってるなぁ） インストールはこちら。\n# yum -y --enablerepo epel install s3cmd インストール後に、先ほど取得したアクセスキーIDを設定します。\n$ s3cmd --configure Access Key: xxxx Secret Key: xxxx 以上で、s3cmdが使えるようになりました。\n5.バックアップスクリプトの作成 つぎは、本題のJIRAのバックアップです。 バックアップ方法はこちらを参考にしました。ちょっと古いみたいですが。 おもなデータは「JIRAのXMLバックアップユーティリティ」にてバックアップするか、「データベースのバックアップツール」を利用する方法があります。 推奨は「データベースのバックアップツール」のようなので、私の場合は「pg_dump」にてJIRAのデータベースをまるごとバックアップすることにしています。 また、データベースには添付ファイルが保存されていないようなので、別途「/var/atlassian/application-data/jira/data」というディレクトリをtarコマンドで圧縮して保存すようにしました。 あとは、pg_dumpの結果と添付ファイルの保存先の圧縮したデータをまとめてディレクトリに保存して圧縮します。 さいごは、S3にアップロードすればおしまいです。 一応、ファイルが連綿と残り続けるのは嫌だなぁということで、ファイル数で世代管理することにもしました。 これまた、ググって見つけてきたサイトを参考にしただけですが。。。 ということで、こんなかんじのスクリプトを日時でcronに設定して動かしてます。\n#!/bin/sh TODAY=`date +%Y%m%d` BACKUP_HOME=\u0026#34;/var/atlassian/backups\u0026#34; S3SYNC_DIR=\u0026#34;/var/atlassian/backups/s3sync\u0026#34; AGE=7 mkdir -p ${BACKUP_HOME}/${TODAY}/ /usr/bin/pg_dump -U postgres -Fc jiradb \u0026gt; ${BACKUP_HOME}/${TODAY}/jiradb_backup.dump tar zcvf ${BACKUP_HOME}/${TODAY}/attachment.tgz /var/atlassian/application-data/jira/data tar zcvf ${S3SYNC_DIR}/jira_backup_${TODAY}.tgz ${BACKUP_HOME}/${TODAY} rm -rf ${BACKUP_HOME}/${TODAY} NUM=`ls ${S3SYNC_DIR} | wc -l` while [ ${NUM} -ge ${AGE} ] do DEL_FILE=`ls -lt ${S3SYNC_DIR} | tail -1 | awk \u0026#39;{print $9}\u0026#39;` rm -r ${S3SYNC_DIR}/${DEL_FILE} NUM=`ls ${S3SYNC_DIR} | wc -l` done s3cmd sync --delete-removed ${S3SYNC_DIR}/* s3://my_jira_backup/s3sync/ そこへんだよとかあれば、ツッコミを。 今のところ、S3へのsyncだけなので、このあとは、月1くらいでGlacierに落とすとかの仕組みも考えるかなぁ。これまた何かあるんだろうけど。 あとは、この応用で家のNASに溜まっている写真をS3経由もしくは直接Glacierにバックアップする仕組みを考える予定です。\n","date":1366639648,"dir":"post/2013/","id":"1ca04e5339ed1826c12fe61fd984e949","lang":"ja","lastmod":1366639648,"permalink":"https://blog.johtani.info/blog/2013/04/22/jira%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E3%82%92s3%E3%81%B8%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97/","publishdate":"2013-04-22T23:07:28+09:00","summary":"だいぶ、ブログを書くペースが落ちてきてて、危機感を感じている今日このごろです。。。 今回は、個人的に利用しているJIRAのバックアップについて","tags":["備忘録"],"title":"JIRAのデータをS3へバックアップ(Jugemより移植)"},{"contents":" HerokuではじめるRailsプログラミング入門 heroku気になってるのに使ってなくて、TDのアカウント作ってデータアップしてない軟弱者ですが、参加して来ました。。。 とりあえず、大事なことです。まずは、上記の書籍を買ってください（って中の人が言ってました。） イベントページはこちら。\n総じて、herokuの中のエンジニアの方たちがすごく情熱があって、ユーザと会話をしたがっているという感想だったようで、まだまだ、よくなりそうだなぁと。 私は、ベースがJavaなので、JavaやScala、Playで使ってる方の感想とか聞きたいかなぁ。 あと、herokuとS3の組み合わせだと思うんですが、料金とかはAmazonとheroku両方に別々に払うのかな？とかはちょっと気になりました。 AWSのアカウントも作ってS3にバックアップあげるの作ろうと思って手をつけてない軟弱者ですが。。。 今月は余裕がありそうなので、TDとか触ってみようと思います。。。\n懇親会ではTDのmuga-sanとお話できて、いくつか気になってた話ができたのでスッキリしました。 あと、株式会社サムライズムの名刺頂きました。写真載せろって言われたけど、また今度ｗ\n最後に、大事なことです。まずは、上記の書籍を買ってください（って中の人が言ってました。）\n以下は、いつものようなメモです。最後の方はちょっとくたばってたのでメモがおざなりになってます、すみません。\n日時：2013年04月04日(木) 18時30分 - 21時00分 場所：日本創生ビレッジ 事業開発支援オフィス 東京21cクラブ コラボレーションスペース ◯Ayumu Aizawa（Heroku, Inc.） ・■ PostgreSQLが9.2になりました。 ・◆ メモリが2倍。βテスタ向けにスケールアップ。 JavaとかJavaとかJavaとかデプロイしてもいいよね。 けど、メモリ2xは価格も2x！ ・● Heroku OAuthを提供。Experimentalだけど。 heroku-bouncer使うとOAuthが楽になる。 ◯Treasure Data and heroku Masahiro Nakagawa（TreasureData） ・会社紹介 ・フロントエンド部分の担当（fluentd） ・1500億レコード！？ ・投資家の中にHerokuの方がいる。 ・ターゲットは？ Cloud + Big Dataが対象 Hadoopは立ち上げるのはいいんだけどメンテナンスコストが。 Hadoopの処理基板を提供 ・Hadoop生ではなく、Plazmaを使っていたりする。 ・Viki herokuにtd-agent入れて、TDにデータ送って、Postgresに書き出して使ってる。 ・TDはどうやってheroku使ってるの？ Webコンソール。 http://console.treasure-data.com Webサイトは大体heroku fluentdとかも ・herokuのaddonとしてtd-agentを提供してる。 ・STDOUTからTDにデータ送るのもできるよと。 ◯Waza Report ◯吉田雄哉さん（co-meeting） ・まずは、co-meetingの紹介。 1文字ずつ送信してるよと ・Chief Talk Officerらしいｗ ・MongoDB使ってるって言ったら、herokuのPostgreSQLの人と話して、鼻で笑われたｗ ・すごく熱意のある人達がエンジニアとして働いてる ・ユーザの声をきちんと聞いてくれる体制ができてるミーティングだった。 ・「クラウド」って単語を聞いてない。勉強会のレベルもすごい。 ◯山本裕介さん（株式会社サムライズム） ・ニッチなブログ書いてます。 ・Java屋が見るWaza Tシャツプレゼント！ ・OSS好きが多い。 Java/Scala系の話が少なかった。Scala界隈では人気みたい ◯岡村純一さん（株式会社シャノン） ・スライド1枚も作らずに喋る人とかいました。 （すごい。。。） ・Django Playに似てて面白いかもと ・Ruby2.0 Matzが喋ってたとか ・クロージングはビールが出てきてた。 交流パーティみたいになってた。CROSSがそれに似てますね。日本でやってるイベント ◯小西俊司さん（株式会社フレクト） ・バックエンドの性能とかを収集して見ることができるツールがあるらしい。 ・クエリを登録しておくと監視ができるツールとか。（TDとかぶってる？） ・やっぱり、情熱的だし、OSS好きでオープンな感じのエンジニアが多い。 ◯Heroku LT 無慈悲なLTです。3分たったらケーブル引っこ抜きます。 （最後はくたばっててあまり聞けてない。。。） ◯山本 裕介（株式会社サムライズム） ・herokuでJava7！ Java6終わってますからherokuも移行してね！ ◯竹野 淳（Grow!） ・BoxTo？ ・コラボレーター募集！ ◯小西 俊司（株式会社フレクト） ・ExcelのテンプレートをアップロードしてGETでパラメータわたせばいいよみたいなの作ってる。 ◯大久保英樹（Job-Hub） ・CarrierWaveとかの注意点 ","date":1365128443,"dir":"post/2013/","id":"73d2fce4efa52675b35a11ee97bc2db0","lang":"ja","lastmod":1365128443,"permalink":"https://blog.johtani.info/blog/2013/04/05/heroku-meetup--8-treasuredata--waza-report-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/","publishdate":"2013-04-05T11:20:43+09:00","summary":"HerokuではじめるRailsプログラミング入門 heroku気になってるのに使ってなくて、TDのアカウント作ってデータアップしてない軟弱者","tags":["勉強会"],"title":"Heroku Meetup #8 TreasureData + Waza Report!! に参加しました。#herokujp(Jugemより移植)"},{"contents":"記念すべき！？第10回のSolr勉強会です。\n発表者が無事あつまり（本当にありがとうございました！）、今回も盛況な感じでほぼ満員でした。 ツイートのおかげか、キャンセル処理もちゃんと行なってもらえて助かりました。 開場直後にドタバタしてしまい、すみませんでした。。。\nとりあえず、第一報の記事をアップしておきます。 懇親会での話とか感想はまたあとで。\n関口さんの資料は実は、前もって見たことがある資料でした。 最初の発表にしては、少しむずかしいと思った方もいるかなぁと。 ただ、類義語の辞書は結構作るのが大変だし、探しても出てこないものなので、面白い話だったんではないかなぁと。 「ミスチル」はできないけど、「マツケン」ができるのは読みがあるからとかなんですかねぇ？って質問するの忘れてた。\n尾形さんの話は結構、みんな通ってきた道かもなぁと思いました。他の方も同じ経験してるんじゃないかなぁと。 ただ、一人でやるのはすごいですよね。検索って結構人数が割かれてない場合が多いのかなぁ。 あんまり使われていないというのが少し悲しい話でしたが。。。 サーバを要求すれば結構なスペックが用意してもらえるのはうらやましい限りですねぇ。 スキーマ変更については、レプリケーション機能を使うと追加などならうまくいくんじゃないでしょうか。（そんなツイートもありましたよ。togetter読み返すと出てきます。） フィールド名を変更しないで型を変更するなどしたらおかしくなると思いますが。\n野口さんの話はなかなかチャレンジングでいいなぁと思いました。よく挫けずに頑張られているなぁとｗ 試行錯誤した仮定も発表してもらえると同じ轍を踏んだ人が助かると思います。 大きな企業で本格的に横断的な社内検索が出来る仕組みが出来上がっているって話はなかなかきかないかなと。 どうしても、社内検索とかお金が出なくて手を付けられないといいう悲しい話が多いので、こういう話は共有したい情シスの方がいっぱいいるんじゃないかなぁと。 ManifoldCFが結構地雷を多く含んでいるのは大変そうですね。。。 SolrにもTikaが入っていたりしますが、個人的にはTikaがやるべき処理は前処理と思っているので、Solrとは別の場所でやりたいとか考えていたりします。 ManifoldCFがその辺りまでやってくれるかまではちゃんと調べてないんですが。 Solrは検索だけに注力させることで、役割を分割できるので、性能の対処とかを行うのが楽になるんじゃないかなぁとか。 ManifoldCFで困ってる人は他にもいるようなので、ジャンジャン使って、どんどんチケット上げて貢献してもらうといいかと。 また、定期的に発表してもらうと面白そうだなぁと。\n弘瀬さんの話は結構興味ある方がいたんじゃないかなと。 SolrCloudは壮大だなぁと思いつつ、手を出しづらいと思ってる方が多いと思います。 実際のサービスに投入して試行錯誤された話を細かな数値も上げて発表してもらえるのは検証をやる方の助けになります。 残念ながら、私もSolrCloudは興味有りつつちゃんと追っかけてないので、途中でnodeとshardとcoreの関係がわからなくなってしまいましたので。。。 もう一度勉強して、スライドを見たいと思います。。。 分散検索（1つのインデックスが複数のcoreやshardに分割された状態）が絡んでくると、複数台の検索の性能のうち、一番遅い性能が最終的な検索性能に響いてくるので、検索リクエストの偏りとかも影響が出たりするかもしれないなぁと。 そういった意味でも試行回数を3以上で計測した結果で再度発表してもらうと面白そう！（なんか、下心見え見えですがｗ）\n前回、今回も感じたのですが、もう少し質問をしてもらえると発表された方も励みになるかなぁと思いました。 質問しにくい雰囲気になってるのでしょうか？参加者が結構いるから質問しにくく感じたりするのでしょうか？ そのあたりをもう少しうまくやれるようになにかコメントもらえると嬉しいかなぁと。 運営で気になった点などもコメントやツイートをいただけると今後の改善にも役立てますので気兼ねなく連絡いただけると助かります。 開場がドタバタしすぎとか、ハッシュタグがわからなかったとか。\n今回は思ったよりも懇親会に残る方が少なめでした。 コミッターの方（LuceneやManifoldCFとかlucene-gosenとか）が複数いたり、Solrを結構触ってる方がいたりと面白い話が聞けそうだったのですが。。。 Kuromojiのユーザ辞書の改良点をチケットにあげるって約束したのでやらないとなぁ。 早く帰るつもりだったのに気づいたら23時でしたwやっぱり色々と話ができるのが楽しくて。。。 駅前の機動隊とかびっくりしながら帰りました。 今回、お話ができなかった方もいらっしゃるかと思いますが、気兼ねなく、ツイートしてもらったり、声をかけていただければと。\nあと、常に発表していただける方は歓迎しておりますので、連絡いただけると非常に助かります！ こんな話が聞きたいなどでもいいかと思いますので、連絡いただければと。\n#SolrJPもtogetterにまとめてもらいました。ありがとうございます。 以下は、いつものメモになります。\n日時：2013/03/26 19:00 to 21:00 場所：VOYAGE GROUP 会議室 1. 株式会社 ロンウイット　関口　宏司さん タイトル：Wikipediaからの類義語知識の自動獲得について 発表資料はこちら\n・「辞書型コーパス」という単語は造語かもしれません。 ・なんでこんなことを？ →類義語辞書を自動生成したいから。 ・自賠責保険、自動車賠償責任保険を例にSynonymFilterの説明。 ・Wikipediaを入力として、類義語辞書を作成するときにLuceneのインデックスを活用してる。 ・類義語候補の見つけ方 いくつかヒューリスティクスな処理とかも入れてます。 日本語Wikipedia固有なもの。 ・実際に導出された単語も載ってる。 FTPなども導出で来てる。 丸ビルとかも。 ・導出できなかったものもあります。 「十六進法」が「十進法」になってる 「ミスチル」も無理。 ・ミスもあるけど、類義語が存在しない場合になんとなく、使う辞書としては採用できるのでは？ 類義語検索対象のブーストを小さくするなどをすれば役に立つ Q：類似度にしきい値を用意したりしてますか？ A：min.scoreという値を用意し、足切りをしている。 Q：ベクトルを作るという話があったが、品詞でフィルタリングとかしてる？ A：名詞に限って処理してます。名詞に限らなくてもいいかも。。。（若干聴き逃しました） 重みの高いn件をベクトルの対象にしてます。 2. グリー株式会社　尾形　暢俊さん タイトル：GREEにおける全文検索の歴史 発表資料はこちら\n・GREEさん、検索はないがしろにされてる。。。 一人でつくって、一人でメンテナンスしてる。 ・GREEの検索は右上の検索ボックスが ・2007年はSennaつかってました。 Tritonnに移行。2009年くらいまで。 やっぱり安定しない＋MySQLのバージョンアップしたいけど、追従できない ・2012年初頭までLuceneでやってた。（結構古い） フラグメントが発生してOptimizeすると、検索サーバが使えなくなる。。。 検索しにくるサーバが1000台いるので、Optimizeかけるときに、1000台のサーバの設定を書き換えるとかしてた。。。 ・現在まではSolrをつかってる。 Luceneのバージョンも古かったので100倍くらい速くなった。 ・Solr本が必須ですよ！！！ ・Lucene+Tomcatから移行。 移行に気をつける点として、I/FをそのままSolrに置き換えると。 Solr返却のXMLをカスタマイズしたり、クエリをSolr向けに書き換えたり。 あと、メンテナンスが楽になるように。 40数台のインデックスサーバがあると。 一人でメンテナンスしてるから、楽になる方法が重要 ・レプリケーションで、Optimizeの影響が出ないように。 キューをつかって、マスタに登録して、スレーブにレプリカを配布 ・スキーマが7つ あんまり使われてなくてかなしい。。。 ・負荷のグラフもありました。 ・RangeQueryを結構使う。 ・作りこんだ部分 インデックスのMasterへ分散させる処理とか クエリの変換とか人力監視処理とかNGワードとか サーバ監視のための仕組み ・今でも大変なこと スキーマ変更が大変 スレーブをマスタに昇格とかが手動 ・今後改善したいこと 精度を上げたい 辞書を使ってみたいけど、各国語対応 あと、自動化とか 3. ソフトバンクBB株式会社　野口　勝義さん タイトル：企業内の大規模ファイルサーバ検索事例 ・情シスの企画版？という立場のかた。 ・売上に貢献したいのでクラウドサービスとして検索をオプションとして立ち上げてみた！ ・Solr＋ManifoldCFで作ってみたよと ・なんでSolr？ OSSだし、機能が充実 ・なんでManifoldCF？ Active Directory連携が使いたかったと。 社内検索ってやっぱりアクセス権がうるさいので。 ・ManifoldCFの説明はロンウイットさんの画像を使わせてもらいましたｗ ・ファイルサーバが、70TB。。。 ・困ったこと。 ・その１ ・クローラージョブの構成の最適化どうする？ ・マルチコアで、クローラーとファイルサーバを1対1の構成にしてみた。 ・その２ ・ファイル数が増えるとまた問題が。。。 ・ファイルサイズが大きい→Heapが足りないエラーとか、MCFのタイムアウトとか。。。 ファイルサイズのリミットを設けてみた。 mp4とかでエラーがでるとか。既知のエラーでしたとか。 ulimitがたりないとか。 MCFの稀に出るバグとか。。。 ファイルサーバの不良ブロックとか。。。 ・その３ ・クロールに時間がかかる ・MySQLでスロークエリとか MySQLよく知らないとか言われながらコミッターに対応してもらうなど。 SSDつかうとか考え中 ・フルクロールで1週間 差分でも1日強かかる。 ManifoldCFだけで対応できないから、ファイルの特徴を元に →ManifoldCFを経由しないリアルタイムインデックス更新のAPIを経由してMasterじゃなくて、更新かけると。（特定のクライアントからの方法） ・その４ ・本文データをstored=falseに けど、ハイライトできないから、どうにかしたい ・ユーザの要望 ・もしかして検索 類義語？じゃないよねぇ。テザリング、tezaringuとか フロント側で頑張った。（Solr諦めました） ・検索スコアも弄りたいとか 外部データでブーストとかもしたい。External Fieldとか使うといいのでは？とか。 4. 株式会社サイバーエージェント　弘瀬　健さん タイトル：SolrCloudの導入事例 発表資料はこちら\n・Webエンジニアだったのに、検索エンジニアに！ ・SolrCloudもサービスインしてると。 ・SolrCloud概要 4.0以降の機能とか。 ・SolrCloudの構成要素 概念的なもの。Collection、Shard 物理的なもの。Node、Core ・ Simplogってサービスに導入済み。 ZooKeeperが3台、6Shard、3nodeという形式 ・性能 平均レスポンスタイム50msec 思ったより出てないので、調べてみた。node数とかshard数を変えてみて調べてみた（まだ、模索中。） ・色々テストケース試したけど、試行回数が1回だけです。 詳細なデータが出てるのありがたい（全部はまだ理解できてないですｗ） ・検証まとめ ノード当たりのcore数が少ないほうが検索、更新性能がいい 1コレクション当たりのshard数が少ないほうが検索性能がいい ・まとめ ・SolrCloudの利点 クライアントが色々意識しなくていいのがうれしい。 ・SolrCloudの注意点 shardの分割機能がまだないので、大変。 コレクション情報が壊れると検索更新できないとか。4.0だとバグが有った ・性能的には素のSolrのほうがいいよと。 ","date":1364300160,"dir":"post/2013/","id":"26d0c0d8c465087cf160a3bdc479f2b4","lang":"ja","lastmod":1364300160,"permalink":"https://blog.johtani.info/blog/2013/03/26/%E7%AC%AC10%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/","publishdate":"2013-03-26T21:16:00+09:00","summary":"記念すべき！？第10回のSolr勉強会です。 発表者が無事あつまり（本当にありがとうございました！）、今回も盛況な感じでほぼ満員でした。 ツイー","tags":["勉強会"],"title":"第10回Solr勉強会を主催しました。#SolrJP(Jugemより移植)"},{"contents":"なんか、とても久しぶりにイベント参加メモ以外の投稿です。 elastic searchのMLを見てたら、KuromojiのAnalyzerを使うときにユーザ辞書使うのどうするの？という投稿を見かけました。\nKuromojiのユーザ辞書にもちょうど興味があったり、elasticsearchもちょっとずつ触りたかったのでちょっと試してみました。（返信もしてみましたが、テキトーな英語です。。。）\nelasticsearch-kuromoji-pluginのインストールなどはElasticSearch で kuromoji を使う (ES 0.90.Beta1 + kuromoji 1.2.0篇)を参考にしてください。 私もこちらに記述のある組み合わせ（elasticsearch-0.90.0Beta1 + elasticsearch-analysis-kuromoji/1.2.0）を利用しました。 KuromojiのAnalyzerはデフォルトで「kuromoji」として登録済みですが、こちらはユーザ辞書の指定がありません。 ということで、「kuromoji_user_dict」というユーザ辞書指定をしたtokenizerと、それと使う「my_analyzer」というanalyzerを登録したIndexを作成します。 定義する前に、「userdict_ja.txt」を用意して、elasticsearch-0.90.0Beta1/config/ディレクトリに配置しておきます。 （以下のサンプルでは、SOLE_HOME/example/solr/collection1/conf/lang/userdict_ja.txtをコピーして使いました）\n$ curl -XPUT \u0026#39;http://localhost:9200/kuromoji_sample/\u0026#39; -d\u0026#39; { \u0026#34;index\u0026#34;:{ \u0026#34;analysis\u0026#34;:{ \u0026#34;tokenizer\u0026#34; : { \u0026#34;kuromoji_user_dict\u0026#34; : { \u0026#34;type\u0026#34;:\u0026#34;kuromoji_tokenizer\u0026#34;, \u0026#34;user_dictionary\u0026#34;:\u0026#34;userdict_ja.txt\u0026#34; } }, \u0026#34;analyzer\u0026#34; : { \u0026#34;my_analyzer\u0026#34; : { \u0026#34;type\u0026#34; : \u0026#34;custom\u0026#34;, \u0026#34;tokenizer\u0026#34; : \u0026#34;kuromoji_user_dict\u0026#34; } } } } } \u0026#39; 「user_dictionary」というのがユーザ辞書の定義ファイルになります。 注意点としては、6行目で指定した名前「kuromoji_user_dict」を14行目の「tokenizer」に指定しないとちゃんと動かないという点でしょうか。\n上記で指定したAnalyzerを利用して「朝青龍」という単語をを解析してみます。\n$ curl -XGET \u0026#39;http://localhost:9200/kuromoji_sample/_analyze?analyzer=my_analyzer\u0026amp;pretty\u0026#39; -d \u0026#39;朝青龍\u0026#39; { \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;朝青龍\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 3, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 1 } ] 「朝青龍」という単語がユーザ辞書に登録されているので、1単語として出力されます。 ちなみに、デフォルトの「kuromoji」のanalyzerを指定すると以下の様な出力です。\n$ curl -XGET \u0026#39;http://localhost:9200/kuromoji_sample/_analyze?analyzer=kuromoji\u0026amp;pretty\u0026#39; -d \u0026#39;朝青龍\u0026#39; { \u0026#34;tokens\u0026#34; : [ { \u0026#34;token\u0026#34; : \u0026#34;朝\u0026#34;, \u0026#34;start_offset\u0026#34; : 0, \u0026#34;end_offset\u0026#34; : 1, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 1 }, { \u0026#34;token\u0026#34; : \u0026#34;青龍\u0026#34;, \u0026#34;start_offset\u0026#34; : 1, \u0026#34;end_offset\u0026#34; : 3, \u0026#34;type\u0026#34; : \u0026#34;word\u0026#34;, \u0026#34;position\u0026#34; : 2 } ] とまぁ、こんなかんじです。 ユーザ辞書を書き換えたあとは「close/open」しないと読み込めないのかなぁ？そのへんはまたあとで調べようかな。\nちなみ、以下のページを参考にさせてもらいました。 elasticsearch kuromoji plugin - natural days ElasticSearch で kuromoji を使う (ES 0.90.Beta1 + kuromoji 1.2.0篇)\n","date":1363765380,"dir":"post/2013/","id":"f5f28f42ad234b4389af4cbea54ff60d","lang":"ja","lastmod":1363765380,"permalink":"https://blog.johtani.info/blog/2013/03/20/elasticsearch-analysis-kuromoji%E3%81%A7%E3%83%A6%E3%83%BC%E3%82%B6%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%88%A9%E7%94%A8%E6%96%B9%E6%B3%95/","publishdate":"2013-03-20T16:43:00+09:00","summary":"なんか、とても久しぶりにイベント参加メモ以外の投稿です。 elastic searchのMLを見てたら、KuromojiのAnalyzerを使うときにユーザ","tags":["elasticsearch"],"title":"elasticsearch-analysis-kuromojiでユーザ辞書の利用方法(Jugemより移植)"},{"contents":"久々にブログ＋イベント参加です。 知り合いが開催＋出演したので参加してみました。 「スマホ」ってキーワードはあまりなかったけど、面白かったです。\nとりあえず、メモ。 余力があれば感想追加します。\n日時：2013/03/19 19:00 場所：パレスサイドビル9F マイナビルーム （東京都千代田区一ツ橋1-1-1） URL：http://atnd.org/events/36966 登壇者：@naoya_ito @yusuke ◯@naoya_itoさんの発表 最近、感心してること。 ・RubyMotionやってます。 今年5月に ・AWSもやってるよ。 ・「継続的デリバリー」の話 GREEでは毎日デリバリーしてるよと。 ・Chefの話 DevOpsとか。 ・Obama for Americaの話 GitHubとか使ってた。 身に付けるべきものは？ 「変化に適応する力」が必要だよね。 最近は Ruby、クラウド、AWS、iOS開発とかやってる、どうしてこうなったｗ 先は予測してないけど、変化に適応するには5分でいいからやり続けること。 ◯@yusukeさんの発表 自己紹介が難しい ・今やってること ブログ執筆 刺さるツイート研究 ソフトウェア販売代理店 思わぬ収穫。InDesign/Illustratorのスキル、ビジネスの仕方ｗ 会社設立中。 Webサイト構築・運用 ・ハッタリが大事 ・プログラム好き プログラミング以外を仕事にしてる。 ・人と違うことがしたい。市場がない場所での差別化はしない＝トレンドに逆行し過ぎない。バランス。 ・今は種まき中。 ◯ディスカッション ・2,3年後とか何やってると思いますか？ @naoya_itoさん ドラクエやってると思ってるかもしれませんが、サービス作るコード書いてます。 将来的な見通しでやってるのか？って言われるとそうでもない。 ツールとかよりは、コミュニティとかのサービスを作るほうが好き。 @yusuke 一定の収入がありつつ、プログラミングしてたい。あわよくばサービス作ったのが当たるといいなぁ ・そもそもフリーランスをどう捉えているか？ @naoya_ito いいところ。自由に自分の時間をコントロールできる。 悪いところ。自分でコントロールしないといけない。 自分をコントロールしないと厳しい。 フリーになってわかったのは、会社は人間を働かせるための仕組みをよく考えて出来てる。 フリーでいいのは、選択した結果に自分が責任を持つというのがいい。 @yusuke セフルマネージメントできたほうがいい。 しがらみを捨てるためにフリーになるのはおすすめしない。 ・情報発信を継続してるけど、必要なことか？ @naoya_ito 必要とは思わないけど、みんな書いたらいいと思う。 検索すれば自分が助かるからｗ セルフブランディングのために重要？かなぁ。あまりそれが唯一の方法ではないと思う。 @yusuke 発信することで、何に興味を持ってるかをわかってもらえるから、便利かな。 ブログに残したほうがググって引っかかるよと。 ・技術の方向性？見つけ方？は？ @naoya_ito 直近は、クラウド流行るしiOSはまだ伸びてるしと。 そっから先はどうするの？ わからないよね。じゃあ、どうするの？って変化に対応してボトムアップで見つけてくのがいいんじゃないかなぁ。 人がやってないところを先にやらないと武器にならないけど、どうやって見つけるのか？ プログラミングやってる時に、その先に必要なこととか、気付きがあるので、手を動かさないとだめだよねと。 @yusuke トレンドを追いかけつつ、知ったかぶりするのは重要 ある程度ハッタリ＋手を動かす ","date":1363692480,"dir":"post/2013/","id":"5412fb82160d0f6093e4b6670f505c13","lang":"ja","lastmod":1363692480,"permalink":"https://blog.johtani.info/blog/2013/03/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass%E7%AB%B9%E6%A9%8B--vol1-%E3%82%B9%E3%83%9E%E3%83%9B%E6%99%82%E4%BB%A3%E5%88%B0%E6%9D%A5%E3%81%93%E3%81%AE%E5%85%88%E7%94%9F%E3%81%8D%E3%81%AE%E3%81%93%E3%82%8B%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%A8%E3%81%AF%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-tecomp/","publishdate":"2013-03-19T20:28:00+09:00","summary":"久々にブログ＋イベント参加です。 知り合いが開催＋出演したので参加してみました。 「スマホ」ってキーワードはあまりなかったけど、面白かったです。","tags":["勉強会"],"title":"エンジニアのためのスキルアップ勉強会『Tech Compass』＠竹橋 ― Vol1 「スマホ時代到来、この先生きのこるエンジニアとは！？」に参加しました。#tecomp(Jugemより移植)"},{"contents":"技術ブログから離れていってますが。。。 Xperia Zを購入しました。\n前に使っていたのはXperia arcになります。 もうすぐ２年だったのですが、容量不足に悩まされていたため＋芸の肥やし（仕事の足し）という名目で Xperia Zの購入に踏み切りました。 予約しての購入です。\nいくつか戸惑いなどを感じているので備忘録としてブログに残しておきます。 サイズが大きい___ まぁ、わかっていたことですが、5インチと大きいです。 ステータスバーを表示するのがちょっときついくらいです。 私は手が大きい方なのですがそれでもキツイので、普通の人は両手じゃないと厳しいんじゃないかと。。。 一応、ステータスバーを表示するためのアプリなんかもあるようなので、その辺を検討するのもいいかなぁと（まだインストールもしてませんが。） また、Angry Birdを演ってびっくりしたのですが、解像度が大きいため、startボタンなどが小さくて押しづらいですｗ\n移行がめんどくさい___ iPadも持っていて、ソレと比較するとひどくめんどくさかったです。 実は方法を知らないだけかもしれないんですが。。。 iPadだと、初期化したりしてもiTunesにインストールしたアプリなども覚えていてくれます。 ですので、すぐに同じ環境が出来上がります。 Xperiaに関しては、arcでインストールしてたアプリをインストール履歴を元に一つずつインストールして、 それぞれのアプリやアカウントを設定して行きました。 これが結構面倒で、まだ完全にはアプリがインストールできてないかも（他にも新しいものを入れたいなぁと思いつつ、探す手間を惜しんでます。。。おすすめアプリお待ちしてます。）\nZite、Angry Bird star warsがインストールできない___ Ziteは英語の勉強も兼ねて入れていたのですが、対応していないバージョンですと言われます。 AngryBirdもいっしょですね。 starwarsじゃない奴はインストールできたのですが、肝心のやってみたいstar warsがインストールできなくて。。。\nドコモアプリがいっぱい___ ドコモのアプリやプリインストールアプリがいっぱいあったので、どうしようか悩んでいます。 いくつかはアンインストールしました。HotpepperBeautyとか間違いなく使わないし SFA-QRというよくわからないアプリも入っていたのでこれまたアンインストールしました。\n通知に出さないアプリとか選択できない？___ 容量不足だったのも有り、TwitterクライアントにはTwiccaのみをインストールしていたのですが、今回はTwitter純正のクライアントもインストールしました。 お気に入り登録されたりといった状況も見れるので重宝するのですが、基本的にはtwiccaを使うつもりです。 ですが、通知バー（ステータスバー）に@ツイートが届いたなどといった通知は見なくてもいいと思っているんですが、なにか方法あるんでしょうか。\ndビデオが危険___ いわゆる携帯ショップで機種変更したため、いくつかのサービスに登録しないといけませんでした。 で、dビデオ（月額525円で映画とか見放題）に登録したので、せっかくだからと映画をダウンロードしてみたのですが、危険です。。。 ただでさえ、本読むのが遅かったり、コーディングしてないのにビデオ見ると更に時間ががが。。。 けど、面白くて。。。危険です。（スターシップ・トゥルーパーズ見ちゃいました。。）\nクレードルがもう一つほしい___ 防水なので、あまりキャップを開けたくないんです。 そして、dビデオとか見てるとやっぱり電池の減りがはやいんです。（ディスプレイが大きいのもあるのかなぁ。要らないサービス切るとかしないと） 結局、出先でも充電をしないといけなくて。 ただ、純正のクレードルが2100円と結構な値段でして。。。 あと、イヤホンを指すところもキャップがあるので、Bluetoothレシーバーも気になってたりします。 こちらも結構な値段でして。。。\nとまぁ、新しいものを手に入れて、色々悩んでますが、楽しいですね。購入したての色々と悩む時間がｗ おすすめアプリとかあったらコメントください\n","date":1360687980,"dir":"post/2013/","id":"b051fd352847c06e748b345e8ed0738b","lang":"ja","lastmod":1360687980,"permalink":"https://blog.johtani.info/blog/2013/02/13/xperia-z%E8%B2%B7%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2013-02-13T01:53:00+09:00","summary":"技術ブログから離れていってますが。。。 Xperia Zを購入しました。 前に使っていたのはXperia arcになります。 もうすぐ２年だったのですが、容量不","tags":["備忘録"],"title":"Xperia Z買いました(Jugemより移植)"},{"contents":"金曜日に引き続き、イベントに参加して来ました。（仕事。。。これも仕事だよ。）\n「Hadoop Conference Japan 2013 Winter」です。 普段、Hadoopを触るのも少ないのですが情報を仕入れときたいなぁということで。 今年はビッグサイトですよ。そろそろ無料のカンファレンスもキツイのではないでしょうか。。。 こちらの写真はセッション会場。今回もすごいです。。。 簡単ですが、聞いていた感想です。 全体的に、Hadoop本体の話ではなく、エコシステムと呼ばれる周辺のプロダクトの話や実際に運用している実例が増えていました。 だいぶ普及期に来たのかなぁと。そして、自分の不勉強を実感できたなぁと。 （あと、TreasureDataに絡む話が多いなぁと言うのも印象です。そういうセッションを選んで出ていたのかもしれませんが） 懇親会まで残っていたのですが、結構、すごい方たちの顔ぶれだなぁというのを今更ながらに実感するとか。 （ハチ象Tシャツを着ているすごい集団でもありましたが。。。）\n以下はいつものメモになります。だいぶ金曜日のイベント後で腑抜けてるのでメモが雑ですが。\n◯ご挨拶 Doug Cuttingさんのビデオ（あんまり聞けてない）　さすがのhamakenさんのトークの安定感。 後援はリクルートテクノロジーズさんが大半。 リクルートテクノロジーズの米谷さんが軽く発表 ◯LINEのHBaseを利用した大規模なメッセージストレージ：NHN Japan 中村 俊介 まずは、LINEの紹介が続く。 New Yearのメッセージは3倍位だったけど、何とかなっったよと。 データロスがない。 サーバ故障からのデータリカバリも自動でやってくれる 書き込み1ms、読み出し1-10msでできてる ・IDC onine migration クライアントベースで2つに書き込み Incremental replication（新データ）、BulkMigration（旧データ） 元のHBaseのレプリケータは利用してない（pushだったから。スループットコントロールしたかったから） ・NN failover 2012.10にNameNode障害発生 HA構成にしてたから問題が発生。 VIPはHDFSにつかうとリスキー 現在： 少ないダウンタイムを許容する ・Stabilizing LINE message cluster ※あとでHBase触るときに資料見直すくらいで。。。 Case1：Too many HLogs Case2：Hotspot問題 まぁ、けど1億ユーザのインフラとして使えるってすごいよな。。。　◯Hadoop meets Cloud with Multi-tenancy： Treasure Data 太田 一樹 TDもFluentdも有名だなぁ Hadoopのメンテナンスとか、つらいよねというのを見てきたのでTD作った ・なぜ、BigData+Cloud？ Hadoopだけみてもバージョンが混在してる＋ディストリビューターも多くなってる 十徳ナイフみたいになってきてるけど、必要なのはナタだよね。というのを提示するためにTD立ち上げた。 ・なぜCloud？ ・IaaSベンダーの対象としてるのはSCM。 オンプレだとHWが陳腐化してくよね→HWはクラウドが主流に ・PaaS、SaaSの対象は時は金なり バージョンアップとか大変だよねと ・TDのご紹介 唯一の解析用DBを目指して ・哲学とアーキテクチャ 解析とか運用をいかに楽にしていくかというのを主体においたサービスを提供したい？ いかに速くレポーティングシステムを簡単に構築していくかとかの話 簡単なインタフェースと目的に集中することで、価値を提供 ・AWSとの違いは？ ・アーキテクチャとか技術的な話 データを集める処理がデータ解析に実際には重要なフェーズ ・カラム指向でデータ保存 実装がどーなってるのかとか、TD内部のHadoopクラスタの運用、バージョンアップとかがどうなってるのかもきになる。（企業秘密だろうけど） ◯Amazon Elasti MapReduceとHadoopコミュニティの関わり：Amazon Web Services Peter Sirota ・３つのV Volume、Velocity、Variety ・yelpのAuto-suggestの例 カスタマーのレコメンデーションにElasticMapReduce使ってるよと。 ・razorfishの広告インプレッションの解析に使ってる ・Amazon.comでの話 AWS Public Datasetsの話 http://aws.amazon.com/jp/publicdatasets/ IonFluxのDNA解析の話 ・いろんな分野でのBig Data 事例がちらほら ※わかりやすい英語なんだけど寝不足が。。。 ◯ランチ！ サンドイッチと豚汁とあとなんとかライス。 TDブースにて、fluentdのTシャツもらったよ！ ◯Hadoop\u0026#39;s Power to Transform Business：MapR　Ted Dunning ・Mahaut＋Solrの単語が。8時間のレコメンデーションデータの作成が3分に？？ ・Stormにてリアルタイム処理と連携。バッチ処理はMRで。 ・バッチ処理とリアルタイム処理の間としてのDrill ・Drillの概観とできるところの話。 （あとでスライドで）データ解析のために機会学習の処理とかも投げられそう。 Q：ImplaraとDrillの違いは？ コミュニティベースかなどが違うよね（あまり聞き取れず） Q：Drillの開発はどのくらいすすんでるの？ A：。。。 Q.クエリ言語としてSQLがいいの？ A.No。というのも、単独の言語ですべてにベストというのはないから。SQLはわかりやすくて良いが、実行が非効率な場面も。 ◯Introduction to Impala～Hadoop用のSQLエンジン～：Cloudera　川崎 達夫 ・Impalaとは 分析に特化した低レイテンシクエリ実行基盤 Apacheライセンス バッチ処理要ではなく、データサイエンティストが試行錯誤するときに利用するのを想定 パフォーマンスが良い 実行エンジンはC＋＋とかで実装されてる MapReduceに依存してない ・MapReduceの問題点 MR直接は難しい→Hiveとか、M/Rの実装を隠して使いやすくするものが増えてきた Hiveを例に説明。MRがベースなので高レイテンシ ・Impalaのアーキテクチャ 機能制限やGA版について言及されてる資料なのが良い ・GA以降の話もあり ピンチヒッターなのに落ち着いて発表とか凄すぎです。 jdbcサポートも入ると。 プランナーはjava実装 Hiveとの互換性は？→完全互換を目指す。 開発のプロセスが見えにくいのでは？開発主体がcloudera ◯Flumeを活用したAmebaにおける大規模ログ収集システム：CyberAgent　飯島 賢志 立ち見。 Flumeのコミッターの人がCAにいたんだ。 ◯Log analysis system with Hadoop in livedoor 2013 Winter：NHN Japan　田籠さん@tagomorisさん ・NHNJapanのお話 ・Webサービスのログ解析について話していく 400+Webサービス ・2011年8月にLTしました。 ・1.5TB/day。。。 ・batchとstream Batch集計も重要だし、Stream処理も重要なので、ハイブリッドシステム ・システムーバービュー FluentdClusterを中心にして各種ツール、保存先に転送してる。 これが結構重要。だけど、今日はFluentdの話ではない ・Fluentd周りを一人でやってるのか。。。 ・処理の流れ ・ログの収集と、生ログ保存 ・パース（主にHive用に）、変換、フラグ追加（分類しておくとあとで集計したいとか、保存すべきかを処理可能に） ・Hiveにロード ・第1世代のはなし すべてbatch処理、Scribe 遅延が1時間ちょっとあるため、Hiveクエリで結果が見れないとか。 ・第2世代の話 Fluentdのstream処理にHadoop Streamingを呼び出せるようなプラグインを書いた Fluentd＋HoopServerの構成 ・第3世代 HoopをWebHDFS Fluentdでのオンライン集計 GrowthForcast、HRForcast ・第4世代（ここ1週間でやったこと） CDH4でQJMベースのNameNode（Failoverは手動） Hiveのスキーマを変更（これはブログに今度書くよ） とりあえず、現時点で改善点が思いつかない ・総括 HTTPベースでRPCベースにしたのでコンポーネント切り替えが結構楽 OSSで公開されてるからいいよね 公開することにより色々とドライブするよ！ ◯いかにしてHadoopにデータを集めるか：Treasure Data　古橋 貞之 ・自己紹介 ・ビッグデータ収集の問題点 ・壊れたデータが入ってる ・読み書きの時間がかかる ログはサブケースである。メインはサービスとかだから。 ・トライ＆エラー処理が時間かかる ・データを分割するのが基本的なアイデア 失敗した時のリトライが楽になる。さらに、それをStream処理すれば良いよねと。 ・flumeのお話 ・fluentdのお話 バッファリングは性能アップも兼ねてる 設定のクラスタへの伝搬とかインストールはpuppetとか使おうねと。 プラグインのインストールが楽 ・いくつかのプラグインの紹介 ・TDへのデータ投入のお話 ・最後にmuddydixonさんのプラグインの宣伝がw ◯Hadoopの次に考える分散システム技術：Microsoft　萩原 正義 ・CAP定理の克服をどうしていくか ・CAPのおさらい ・Lease クライアント主導、サーバ手動とか （理論重視の話で最後のセッションには辛かった。。。頭が疲れててついていけませんでした） おまけ 今回頂いたノベルティなどを写真に撮ってみました。（ランチはお腹すいてて写真取らずに食べちゃいました。。。） Hiveロゴへの愛を語ってHive Tシャツをゲット。 FluentdのTシャツももらいました！ Hiveステッカーなどもゲット あと、メッセージボードなるものがあったので書いてみました。一応、Hadoopに絡んだことですよね！？\n","date":1358783400,"dir":"post/2013/","id":"bf4f86812812dab8d39db9aaefe94a78","lang":"ja","lastmod":1358783400,"permalink":"https://blog.johtani.info/blog/2013/01/22/hadoop-conference-japan-2013-winter%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hcj13w/","publishdate":"2013-01-22T00:50:00+09:00","summary":"金曜日に引き続き、イベントに参加して来ました。（仕事。。。これも仕事だよ。） 「Hadoop Conference Japan 2013 Winter」です。 普段、Hadoopを触る","tags":["勉強会"],"title":"Hadoop Conference Japan 2013 Winterに参加しました。#hcj13w(Jugemより移植)"},{"contents":"1/18（金）に開催された、エンジニアサポートCROSS 2013で「検索CROSS」セッションのセッションオーナー（モデレータ）をやって来ました。\n@muddydixonさんに昨年の夏くらいに声をかけていただいたのがきっかけです。 こういったイベントの運営のお手伝い（ほとんど何もしてない）も初めてでしたし、セッションオーナー（モデレータ）も初めての経験で色々といい勉強をさせて頂きました（自分の足りない所とか、考慮すべき点がどういったところにあるとか）。本当にありがとうございます。\nスピーカーとして登壇していただいた久保田さん、佐藤さん、安田さんほんとうにありがとうございました。 頼りないオーナーで、モヤッとした内容を提示したにもかかわらず、意図を汲み取って話の内容をふくらませていただいてすごく助かりました。 また、会場にお越しいただいたみなさん、ありがとうございました。すこしでも検索に興味をもっていただければ、セッションは成功だったと思っています。 朝一だったのと、私の認知度の低さもあったのとで残念ながら満席とはいきませんでしたが。。。\n後日、録画されたセッションの内容を見て色々と反省しようかなぁと。。。 緊張していたので、うまくモデレートできてたのか、話ができていたのか不安ですが。 忌憚ない感想をお待ちしています。\nということで、反省終わり！ここからは、イベントの感想と聞いたセッションに関する感想です。\n###聞いたセッション\n####企業CROSS DeNA x グリー x Aiming： 大企業・ベンチャーが語る「スクラム」開発 (仮)\nGoogleの及川さん見たさで参加しました。 スクラム自体は名前くらいは聞いたことある程度だったのですが、その程度の私でもわかりやすいディスカッションで楽しかったです。 聞いていて感じたのは、次のようなこと。\n「スクラム」という開発手法の話しなんだけど目的はそこじゃなくて、どうやってうまくプロジェクトを回して（ドライブして）、目的（サービスを作るとか顧客の要望を叶えるとか）を達成するかというのが重要だなぁと。 「スクラムマスター」の仕事は子育てに似てる 「スクラムマスター」になりたい人はなかなかいないらしい 「スクラムマスター」の人は、俯瞰してプロジェクト全体を見渡して落穂拾いをしていく人なのかもなぁと 個人的には「スクラムマスター」の仕事がちょっとおもしろそうと思いました。（いつもいろんなことを面白そうと思う自分なのでなんともいえないですが。。。）\n####データ理解を助けるビジュアライゼーション\n昨年からビジュアライゼーションには興味だけ（実践とかできてない）は持っていたので、参加しました。 スピーカーの方々の対立軸がはっきりしていたのが面白かったかと。 聞いていて感じたのは、次のようなこと\nビジネスの視点からのビジュアライゼーションはコスパがどうなのかというのがまだ不明 可視化できたらおしまいじゃなくて、お金につながる可視化に心がけるのが重要そう 可視化して楽しむのも有りだとは思うけど、それは趣味だったり芸術の話かもなぁ 異なるコンテキストの人にでも誤解を与えない可視化というのが重要 何をどう可視化するかというのが実は統計学知ってると必要ないこともある 基本的にはCAの方の内容が一番しっくり来ました。やっぱりビジネス的な視点と学術的な視点は違うのかもなぁと。\n####継続的システム運用のゲンバのハナシ\n面白かったです。のっけから燃料がテーブルにならんでるしｗ 運用とかインフラはそこまで詳しくないのですが、少しは作業したりするので気になってましたが、ぶっ飛んだ話が聞けて楽しめました。 聞いていて感じたのは、次のようなこと\nサービス内容によっては夜中にアクセス数が低いものもある（cookpadは夜中はアクセス数が低い） アプリを修正することでインフラを楽にするという考えもある インフラエンジニアは実はリア充 cookpad面白い人多いw このあとは、おまちかねのプレモルタイムだったので、プレモル片手（失礼だろｗ）にTech10の池本さんに挨拶してきました。（Solr本のときはお世話になりました！） あとは、RedBull片手に知り合いの方々（Twitter上のみやいつもお世話になってる人）に挨拶をして回ってました。（プレモルも美味しかったのですが、プレモルおつまみも美味しかったです！） また、ちょっとつかれて座るために入った「体系的に学ぶ安全な利用規約の作り方」でも、面白い話を聞けました。 （利用規約をきちんと考えて変更している企業のほうが炎上をしてしまうとか無駄だしおかしいよねとか）\nイベント終了まで、会場にいて（いただけで大した手伝いしてないです、すみません。）その後打ち上げに向かって楽しみました。\n####さいごは、イベント通じて感じたことと気になったこと。（若干、意図的なものが入り込んでますが。。。）\n題材にもなってる「CROSS」ですが、ここ数年特に、エンジニアとして複数の技術や考えなどを身につけないといけないなぁと 有名人に会える！（ミーハーです。。。） プレモル美味しい！（いつも飲んでるビールが「え？」って思った） ケンタッキー美味しい！ RedBull美味しい！ いろんな技術分野に触れられる機会ができそう Wi-fiは用意してもらえると助かる。（参加者の方々が一斉にLTEとかでつなごうとするのでみんなが繋がらなくなってツイートされないとかちょっとつらいかも） 各会場が覗けるようになってたのは良かった（ただ、会場の後ろの人はざわつきを感じるためスピーカーの声が聴こえないことも） スクリーンはもう少し高い位置にあると良かった（後ろに座ると下のほうが見えないことも） 飲食の配布は会場内でできたほうが良かったのかも（NGなのかな？）。プレモルやRedBullは配ってくれたので良かったのだが、食べ物を取りに行くために入口付近が混雑してた気がした。 （これで、メッキ剥がれたかなぁ） 会場入り口の写真とか撮ってくるんだった。。。 ということで、総じて楽しかったので来年もあるならまた、手伝いたいです！\nおまけ\nプレモル！ Amebaウォーター プレモル＋プレモルおつまみ＋RedBull いただいたスタッフTシャツとプレモル！\n","date":1358600940,"dir":"post/2013/","id":"322264a17ef7182eb1475bd2eaebc2eb","lang":"ja","lastmod":1358600940,"permalink":"https://blog.johtani.info/blog/2013/01/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88cross-2013%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%8A%E6%89%8B%E4%BC%9D%E3%81%84%E3%83%A2%E3%83%87%E3%83%AC%E3%83%BC%E3%82%BF%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--cross2013/","publishdate":"2013-01-19T22:09:00+09:00","summary":"1/18（金）に開催された、エンジニアサポートCROSS 2013で「検索CROSS」セッションのセッションオーナー（モデレータ）をやって来ま","tags":["勉強会"],"title":"エンジニアサポートCROSS 2013に参加（＋お手伝い＋モデレータ）しました #cross2013(Jugemより移植)"},{"contents":"いまさら感満載ですが、今週の金曜日(1/18)に開催されるCROSS 2013というイベントで「検索CROSS」のセッションを担当することになってます。\nここ数年、検索に携わっていますが、検索は色々な技術の組み合わせ（検索用インデックス、自然言語処理、機械学習などなど）でなりったていて奥が深いなぁと感じる毎日です。 そこで、実際のサービスで検索をやられている方、検索プラットフォーム製品を開発している方、自然言語処理や検索に長けた方を招いてつぎのような話をしてもらおうかと。\n・現在の事例（検索とその周辺技術） ・今後の検索にクロスすると面白い技術\nがっつり検索をやられている方々に登壇していただきますので、検索に興味のある方はぜひ、ご参加を！ 登壇者の方々についてはこちらを御覧ください。\n検索CROSS以外にも楽しみなセッションが多数ありますので、参加をご検討いただければと。 あと、実はこっちがメインなのですが、夕方からのプレモルタイムも期待できるのでこちらへの参加だけでもぜひ！！\n","date":1358267340,"dir":"post/2013/","id":"20110c8f8da8304b6d9d3c2845a38128","lang":"ja","lastmod":1358267340,"permalink":"https://blog.johtani.info/blog/2013/01/16/%E3%81%84%E3%81%BE%E3%81%95%E3%82%89%E3%81%A7%E3%81%99%E3%81%8Ccross-2013%E3%81%A7%E6%A4%9C%E7%B4%A2cross%E3%81%A8%E3%81%84%E3%81%86%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E6%8B%85%E5%BD%93%E3%81%97%E3%81%BE%E3%81%99/","publishdate":"2013-01-16T01:29:00+09:00","summary":"いまさら感満載ですが、今週の金曜日(1/18)に開催されるCROSS 2013というイベントで「検索CROSS」のセッションを担当することにな","tags":["勉強会"],"title":"いまさらですが、CROSS 2013で検索CROSSというセッションを担当します(Jugemより移植)"},{"contents":"年末から年始にかけて、「コード・シンプリシティ」を読みました。\n先日の記事にも書きましたが、Kindle paperwhiteを思いかけず入手できたので、eBookを読みたいなぁと思いまして。 Kindleのお試しも兼ねて読んでみました。\nまずは、本の感想。 短めの書籍＋読み物なので、サクっと読めました。 題名に「コード」と書かれていますが、コードの実例が出てくる書籍ではありません。 「ソフトウェア」を以下にシンプルに保って、管理しやすくするか、機能追加、テストをやりやすくするかといった指針について書かれています。 機能追加に関して検討しないといけないバランス（先読みしすぎずと実装しすぎないとか）の話や定期的なデザインの見直しなどについても書かれています。 ソフトウェアに関しては動くこともだが、デザインが重要であること。（確かに。） すでにあるソフトウェアについて、どのように簡潔にしていくかという話もありました。 ただ、読んでいて一番重要だと思ったのは、「悪いプログラマーと良いプログラマーの違いは理解力だ」という一文です。 何をしているかを「理解」していないと、根本的な問題点の解決もできないですし、どうすればコードが簡潔になるかといったこともわからないです。 また、やっている作業がどんなもので、何のためにやっているのか、それを行うことで今後にどのような影響があるのかといったことも理解しておく必要があるかと。 ま、ある程度考えながら作業とかしましょうってことですかね。（強引なまとめかも。。。）\nで本題です。 Kindle paperwhiteとiPadの使い分けを検討するのも兼ねて本を読んでました。 iPadを持っているのもあり、Kindleはそもそも眼中になかったのですが、めっけ物でした。 やはり実際に使ってみないとわからないことありますねぇと。 paperwihteはつぎのような利点があるかと。\n読書に没頭できる。→本を読むというシンプルな目的を達成するものだけが実装されている 目が疲れない→Twitterでも話に上がったのですが、液晶とは異なり字が読みやすいです 軽いし小さい→電車で立っていても楽に持てるし、カバンからの出し入れも楽です（iPadに比べて） 複数の端末のKindleアプリで同期できる。→あまり異なる端末では読まないですが、paperwhiteで読んだところが、iPadでも同期されるのですんなり続きが読めます 電池長持ち ということで、本を読むのに没頭できるし目が疲れないと。 ただ、つぎの点では不満もあります。\nPDFは読みにくい。→画面のサイズが小さいので大きめの書籍のPDF版は読みにくいです。 PDFは読みにくい。→文字のサイズを変更できないのもキツイです。Kindle専用のmobi形式の書籍が読みやすいです ページめくりに一定時間がかかる→紙の書籍やiPadで書籍を読むのとは異なり、ページをめくるのに時間がかかります。e-inkの再描画の問題かと。パラパラと書籍を読みたい場合は厳しいです 白黒。カラーの電子書籍は読めないですねぇ ソースコードなどもキツイ→長めのコードが書いてある本だとコードが頭に入ってこないです。。。 という感想でした。 今後は基本Kindle paperwhiteを持ち歩きmobi形式の本を読むようにすると思います。 iPadは自炊本やカラーの本を読むとき、映像、ネットを見るような場合に持ち歩くことになりそうです。 私は基本的にMBAを持ち歩いているというのもあるので、paperwhiteのほうが主流になりそうです。 ネットを見るときなどは最悪、MBAを開くでしょうし。 小説とかをメインに読むのであれば断然、paperwhiteだと思います（最近読んでないなぁ）\n","date":1357658880,"dir":"post/2013/","id":"992a00c30242b6217243f3c387ea18b7","lang":"ja","lastmod":1357658880,"permalink":"https://blog.johtani.info/blog/2013/01/09/%E3%82%B3%E3%83%BC%E3%83%89%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AA%E3%82%B7%E3%83%86%E3%82%A3%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9Fkindle-paperwhite%E3%81%AE%E4%BD%BF%E3%81%84%E5%8B%9D%E6%89%8B%E3%81%AE%E7%A2%BA%E8%AA%8D%E3%82%82%E5%85%BC%E3%81%AD%E3%81%A6/","publishdate":"2013-01-09T00:28:00+09:00","summary":"年末から年始にかけて、「コード・シンプリシティ」を読みました。 先日の記事にも書きましたが、Kindle paperwhiteを思いかけず入手で","tags":["読書"],"title":"「コード・シンプリシティ」を読みました。（Kindle paperwhiteの使い勝手の確認も兼ねて）(Jugemより移植)"},{"contents":"書こうと思いながら、気づいたら大晦日。 よくないですね、思いついた時に書かないと。\n昨年も書いたので、昨年書いた抱負から振り返りをと。\nMongoDB触ってみる Scala触ってみる なんかWebサービス作ってみる（Amazonとかで） elasticsearch、IndexTankを調べてみる NewSolrCloudDesignを読み込んで自分なりにまとめる Junsaiに参加する 「7つの言語7つの世界」の続き えーと。。。できてないことばかりですねｗ MongoDBはインストールすらしてないですし、Webサービスも作ってないです。（さくらVPSは借りたんですが） Junsaiは参加したけど何もできてないし。7つの言語もそのままですね。。。 SolrCloudDesignはまとめられてないですしね。 Scalaは少しだけ触りました。結局Javaみたいな記述をしてしまうという良くないくせが出てしまうので、 見送ってしまいましたが。。。 elasticsearchは少しだけやりました。#pyfesで話をさせて貰える機会があったので。\n興味がコロコロ変わってしまうのが問題点かもしれないです。少しは地に足をつけてなんかやったほうがいいのになぁ\n###今年の振り返り 今年はこんなかんじでしょうか。\nいろんな勉強会に出没 #pyfesでelasticsearchのさわりを紹介 個人的にJIRA導入 MIR輪読会開始 Solr勉強会の主催を引き継ぐ Kindle paperwhite当たった 相変わらずいろんな勉強会に出てました。最近は勉強しに行くのもありますが、人に会いに行ってるような気がします。 勉強会から帰ってきて復習したりしないとすぐ忘れちゃうんですよね。。。\n#pyfesではelasticsearchの入門中という話をしてきました。 人の多さに緊張しまくりでよくわかりにくい発表になってしまったのが反省点かと。。。 もっと話をする機会を増やすとなれるのでしょうか。\nJIRAの導入はパラで仕事をしているとタスク管理がおろそかになってくるので導入しました。 フリーのredmineを考えていたのですが、インストールが簡単なJIRAを導入しました。 有料ですが、1-10人までなら、ダウンロード版が$10ですし。いろんな時間を買ったと考えると安いかと\n検索に関してもまだまだ初心者に近いということでModern Information Retrievalという英語の本の輪読を主催しました。 Twitterでの呼びかけに答えてくれた方々に感謝です。 まだ、半分も行ってないですが、何周かしたいと思っています。\nSolr勉強会の主催者も引き継ぎました。Atnd立てるの手伝おうか？って言ったら主催者になってましたｗ 来年も開催するので、喋りたい方、こんな話を聞きたいなどTwitterやブログでコンタクトいただければと。\nあと、会社の忘年会で思いがけずKindle paperwhiteが当たりました！（やったー！） iPadを持っていることもあり、完全に購入する気も無かったのですが。。。 使ってみると結構いいです。画面のギラツキがないのと、他のソフトがないのがいいです。 読書に没頭できます。通常はKindleを持ち歩くことになるかと。（没頭できるけど、読むスピードが遅い＋すぐ忘れるのが難点。。。）\n###来年の抱負 来年の抱負も書いておきます。 昨年の前科があるのでどこまでできるかわかりませんが。 すぐに興味が変わってしまうのもありますし\nIntelliJ IDEAをメインに使う JIRAを継続して活用 ブログの継続 elasticsearch Luceneのソースコードリーディング 何かOSSのソースを読む Macでもっと開発 読書と英語を継続 IDEA（アイデア）は11をインストールしてたのですが、使えていませんでした。 イメケンが主催したJetBrainsユーザー会で洗脳されて＋タイミング良い75%オフセールにやられて購入しました。 普段はEclipseを使っているのですが、これを機にチャレンジしようかと。 少し変化をしてかないとすぐ取り残されちゃうので。。。\nJIRAはまだタスクを登録してクローズするという初歩段階の使い方しかできてないので、少しずつ研究してフィールド追加したり、ワークフローを変更してみたりと研究したいです。\nブログは、今年後半が勉強会参加ブログしかないのを反省して来年は、もう少しSolrやLucene、lucene-gosenについて書いて行きたいです。 （すくなくとも、4.0で動かす話を書かないと。。。）\nelasticsearchはまぁ触れる環境を維持しようという話です。 どこかで導入できればいいんでしょうが、なかなか。 （勉強会開いてみるのも面白いかな？）\nLuceneソースコードリーディングは誘われてるのに、ちゃんと返事をしていなかったので。 来年2月のどこかの土日を候補日にする予定です。\n何かOSSのソースも読もうと思ってます。 「何か」はまだ決めてないですが、人のソースを実はあまり読んでないなぁと。 Vさんと話をした時に人のソースを読むのがいいですよという話になったので。 真似をするためにもなんか読みたいなぁと。Javaになるのかなぁ。\nとある事情で週4はWindowsで開発してます。 Macはちょっとしか触ってないのでMacの環境が成長していないのが難点です。 できれば、Macで開発を継続できる環境を作りたいなぁと。Kobitoとか入れてるけど触ってないし。。。 IntelliJも入れたのでMacで開発したいものです。\n最後は毎年のことですが、本を読むスピードが買うスピードに追いついてないと。。。 英語の本もかってるんですが、これまた読むスピードが。。。 ということで、ざっくり目を通す読書をもっとやりたいなぁと。 買うのはいいのですが、必要にならないと呼んだ内容を忘れてしまうので、読んだあとに実践する機会も設けたいと思ってます（思ってるだけかもしれないですが）\nあと、来年もいろんな人に会うためにいろんな勉強会に出没すると思いますので、声をかけていただければと また、不抜けているのを見かけたらカツを入れてください。（技術内容のブログ書けとか、本読んだ感想をブログにかけとか） 来年もTwitterなどで絡みまくると思いますが、よろしくです。\n","date":1356908460,"dir":"post/2012/","id":"4c08b67e0c1fdeef50b1fdcc32cdcee2","lang":"ja","lastmod":1356908460,"permalink":"https://blog.johtani.info/blog/2012/12/31/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A02012/","publishdate":"2012-12-31T08:01:00+09:00","summary":"書こうと思いながら、気づいたら大晦日。 よくないですね、思いついた時に書かないと。 昨年も書いたので、昨年書いた抱負から振り返りをと。 Mongo","tags":["備忘録"],"title":"今年の振り返りと来年の抱負（2012）(Jugemより移植)"},{"contents":"Atlassian Advent Calendar 2012の20日目。（急遽参戦） （某イケメンにMT（改変リツイート）されたので書いてみました） 久々に、勉強会以外のエントリです。（Solrとかlucene-gosenじゃないんだが。。。）\n私は、最近忘れっぽくなってきてしまったので、さくらVPSを借りてJIRAを立てて、タスク管理とかに使い始めました。 有料ツールなので、まずは、評価版から入れましたと。 評価版をインストールするときに、楽なのでHSQLDBを選択していました。が、 インストール時に「HSQLDBは評価版だけで使用してください。正式版ではサポートしてないです」みたいなことを言われていたので、PostgreSQLに切り替えようかと。 ちなみに、MySQLも選択肢としてはあったのですが、PostgreSQLのほうが触ってるし（つかいこなせてるわけではない）、補完機能になれてるというのもありPostgreSQLを選んでみました。\n作業のログとして、ブログ書いとこうと思いたったのでメモ的に残しておきます。\n作業の流れはこんなかんじでした。 （基本的にはサポートサイトのここに載ってます。サポートいいね。） この手順通りでいいみたい。\n###1. JIRAのデータのバックアップ（JIRAの管理画面からバックアップ）\nまずは管理画面へ。ページ右上に管理へのリンクがあるのでクリック。 開いた管理画面の右下あたりにエクスポート（バックアップ）へのリンクがあります。 クリックしたあとに、エクスポートのファイル指定画面が現れるので、ファイル名を指定してバックアップボタンを押します。 バックアップが完了するとバックアップファイルの場所が表示されます。 ###2. JIRAの停止\nバックアップが終わったのでJIRAを停止します。\n###3. PostgreSQLのインストール（yum） PostgreSQLが入ってないので、yum installします。（軟弱者なので）\nyum install postgresql-server ####initdbで四苦八苦 PostgreSQLはインストールしただけでは起動できません。なので、初期化をします。 yumでインストールしたPostgreSQLだとつぎのコマンドでinitdbできるようです。（これが罠でした）\nservice postgresql initdb このコマンドでinitdbすると、encodingが指定できませんでした。（私がしらないだけという話も。。。） encodingを指定できていないと、このあと4.を実行するときにエラーが出ました。（これも回避方法あるのかも。） ということで、結局、昔とった杵柄なやり方でinitdbコマンドで\u0026ndash;encoding=UTF8 \u0026ndash;no-localeを指定しました。\ninitdb --encoding=UTF8 --no-locale -D/var/lib/pgsql/data service postgresql start これで初期化が完了するので、PostgreSQLを起動します。\n###4. JIRA用DBとユーザの作成\nまずは、ユーザの作成。そして、DB作成\ncreateuser jirauser createdb -E UNICODE jiradb テーブルなど作成しません。あとの処理がやってくれます。\n###5. JIRAにJDBCドライバを入れる（必要なかった。）\nwarじゃないJIRAをインストールした場合はすでに入ってるみたいです。 ここを見るとわかります。JIRA Installation Directoryの下のlibですかね。\n/opt/atlassian/jira/lib ###6. マニュアルでPostgreSQLの接続設定（あれ、これいらないのか。）\n~~　コンソールオンリーなので、JIRAが提供してくれているツールが使えないため、手で設定。 /var/atlassian/application-data/jira にあるdbconfig.xmlを修正~~ ちゃんと英語読めってことですね。。。必要なかったです。。。\n###7. JIRAのdbconfig.xmlを削除\nDB接続の設定を初期セットアップウィザードで再設定するため、dbconfig.xmlを消します。 （一応、インストールディレクトリとホームディレクトリとかバックアップしたほうがいいみたい） 場所はここ。 中身はdbcpとかのデータソースの設定に似てました。 今は、HSQLDBのJDBCドライバが記載されてました。\nrm /var/atlassian/application-data/jira/dbconfig.xml ###8. JIRAの起動\n7.のファイルを消したあとにJIRAを起動します。\nservice jira start ###9. JIRAにアクセスとDB接続設定\nアクセスすると、インストールした時と同じDB接続の指定を行うセットアップウィザードの画面が現れます。 今回はJIRAサーバの外にあるPostgreSQLなので、「外部」を選んで四角で囲んだ部分を入力します。 入力したら、「接続テスト」を押して接続できることを確認したら「次へ」を押します。 マシンのスペックにもよると思いますが、ここでJIRAサーバがDBに接続してテーブルのCREATEなどDBのセットアップを実行してるのでちょっと時間がかかります。\n###10. バックアップしたデータのインポート\nDBのセットアップが終わったら、アプリケーションのセットアップ画面が出てきます。 新規インストールではないので、「ここ」にある「既存のデータをインポート」リンクをクリックします。 すると、インポートファイルの指定画面が現れるので、1.でバックアップしたファイル名を指定してインポートします。 すると、インポート中画面が出てきます。 で、インポートが完了すると無事JIRAにログインできますと。\nとこんなかんじです。 私の場合は、まだJIRAをインストールしてから間もないため、チケットの数が少なかったり、添付ファイルが無かったりなので、すぐにインポートが完了しました。 添付ファイルがある場合は、別途添付ファイルが保存されているディレクトリのバックアップと復旧などもあるみたいです。 最初にも書きましたが、ドキュメントのサイトに「Switching Databases」という項目があり、そのページの手順で問題なく切り替えできました。 次は、定期的にデータをバックアップするのを考えないとですかね。\nいやぁブログ書くのが、思いの外、手こずりました。 手こずった原因はスクリーンショットだったんですけどね。。。 safariでページ全体のスクリーンショットがとれなかったので、結局ChromeでAwesome Screenshotプラグイン使いました。 safariの拡張もあるんですが、ページ全体のスクリーンショットがうまく動かないみたいです。。。 ということで、備忘録でした。（次はちゃんとSolrとかの記事書かないとなー。その前に忘年ブログかな）\n","date":1356002280,"dir":"post/2012/","id":"4a30eeb083acec8460150068ba0c6743","lang":"ja","lastmod":1356002280,"permalink":"https://blog.johtani.info/blog/2012/12/20/jira%E3%81%AEdb%E7%A7%BB%E8%A1%8Chsqldb%E3%81%8B%E3%82%89postgresql%E3%81%B8-augj/","publishdate":"2012-12-20T20:18:00+09:00","summary":"Atlassian Advent Calendar 2012の20日目。（急遽参戦） （某イケメンにMT（改変リツイート）されたので書いてみました） 久々に、勉強会以外のエントリです。（So","tags":["JIRA"],"title":"JIRAのDB移行（HSQLDBからPostgreSQLへ）#augj(Jugemより移植)"},{"contents":"イケメンが主催した「第一回 JetBrainsユーザーグループ #jbugj」に参加してきました。\nいろんな製品があるんだなぁと。入り口には良いイベントだったと思います。 個人的に、WebStorm、IntelliJが気になっていたので、参加しました。（あとは、イケメンがやってるイベントだからというのもあるかも） ちなみに、MBAにしてからインストールはしていたのですが、ほぼ触っていなかったのでこれを機会にちょっと触ってみようかなぁと。\n発表は、全般的な製品紹介、ライセンスの紹介から、ライブコーディングあり、ここがいいよ！という話ありという感じでした。\nMTLさんのおしゃれな空間で発表を聞いたので、いつもとは少し違った感じでしたでしょうか。\n私自身は、発表を聞きつつ、IDEAのCEで色々やってました。 一応、Lucene/SolrのSVNからチェックアウトしたり、lucene-gosenのtrunkをチェックアウトしたり、個人のbitbucketからlucene-gosen-wikiparseとかcloneしてました。 Eclipseで作ったプロジェクトなので、cloneとかチェックアウトしたあとに、Eclipseと並行開発するとどうなるのかなぁ？というのがちょっと気になります。（普通は移行しておしまいなんだろうけど。。。） ちなみに、lucene-gosenのプロジェクトもSVNからチェックアウトしたらすんなり使えそうでした。 こんな感じ。（lucene-gosenのプロジェクト） とりあえず、見た目がカッコイイｗ\nいくつか触ったり、聞いていて気になったのはつぎのような点です。ちょっとずつ触る機会を作った時に調べてみようかなぁと\nEclipseのワーキングセット相当の機能はどうするのか？→モジュールとかでやればいいらしい。 プラグインってどんなものがあるの？探す方法とインストールの仕方 JDKの複数の切り替え方とか Eclipseでやってる人とIntelliJでやってる人の混在チームでの開発とか で、いつものごとく、懇親会に参加しました。 @mike_neckさんや@sue445さんとお話できたのですが、VCSにEclipseの設定ファイルとか挙げないほうがいいですよねとか、テストが無いプロジェクトってないわーなどの話を聞いて、やっぱり自分はまだまだなんだなぁと認識できるとか面白かったです。 lucene-gosenのSVNにはEclipseの設定ファイルとかアップされてるからなぁ。ホントはAntとかMavenのターゲットでこれらの設定ファイルができるようにしとくのがいいんでしょうねぇ。 まだまだ勉強することだらけですが、コツコツ教えてもらいます\nちなみに、イベント参加者にはショートカットキーが印字されたキートップシールや2ヶ月有効な評価ライセンスがあとからもらえるなどの特典もありました。 普段はEclipseなのですが、運良くライセンスが当たったら本気で乗り換えようかなぁｗ\nちなみに、Eclipseでもそうですが、私自身はショートカットキーをほとんど覚えてない軟弱者ですので、メニューの場所などを覚えれば乗り換え自体はこんなんじゃないかと。 Mac自体にKeyRemap４MacBookを入れていて、Emacsっぽいショートカットを使うので、覚えられないというのもありますが。 ライセンス当たらないかなぁー\n以下はいつもの通り、聴きながら自分用にメモしたものになります。\n日時：2012/12/11（火）19:00-21:00 場所：メディアテクノロジーラボ イベントサイト：http://www.zusaar.com/event/450003\n◎JetBrains製品群、ライセンス形態などの紹介 - @yusuke ・日本でヤル気あるの！？→あるある！→じゃあ、ユーザグループ立ち上げるぜー ・あくまで情報交換の場を設けるだけ。 ・アンケート結果 IntelliJが1番人気 WebStromが2番 ・ステッカー（ちょっとかっこ悪いかも。。。） ・2名限定でIDEAのライセンスプレゼント！ ブログ書いて、応募用フォームに登録してランダム抽選 ◎IntelliJの基本(インストール～プロジェクト作成、テスト、実行までのウォークスルー) @yusuke ・JetBRAINSはチェコの会社 ・IntelliJはなんでもできる（AppCodeは違うけど） ・.Net系もある（書きそびれた） ・YouTrack：課題追跡 ・TeamCity：継続インテグレーション ・読み方は「イデア」じゃなくて「アイデア」だよ！ ・Community Editionはあんまり機能がない。 OSSライセンスだと、Ultimateの機能が使えるよと。 ・仙台の人が一人アドベント・カレンダーやってます。 http://d.hatena.ne.jp/masanobuimai/20121201\n・ライブデモ 黒いインタフェースにするのどーすんだろう？ →Preferences→AppearancesでThemeで「Darcula」を選択すると黒くなる。 ・やべ、時間過ぎてたｗ終わり！ ◎IntelliJのここが気持ちいい！→普通IntelliJでしょ？ @mike_neck ・DQXやってます。 ・僕とeclipse ・新規クラス作成：3ステップかかる ・補完の素早さ： ・SprintFramework：Ultimateなら対応してるよ。 関係ないけど、TLで質問したので。 Eclipseのワーキング・セットに相当するもの。 http://d.hatena.ne.jp/masanobuimai/touch/20121024\n◎LT ◯WebStormとRubyMineについて @sue445 ・JavaScriptのIDEとして最強 jsの補完が素晴らしい。（外部のJSはプロジェクトに入れないと難しい。） jsTestDriver pluginがデフォルトで入ってる！ ・RubyMine RubyのIDE ソースを追うのが楽。 erbのインポートしたものも追っかけられるの便利。 viewからhelperクラスにも飛べる。 QA UMLとか出せるの？→出せるよ。 DBクライアントもあるよ。 ◎JetBrains発のJVM言語Kotlinの紹介 - @ngsw_taro アドベントカレンダー（一人）http://atnd.org/events/34627\n・社畜してます ・Androidアプリとか作ってる。 ・Kotlinな活動 Pull Requestしてる ・マイルストーンなど。 M4が3時間前に出た！ ・どんな言語？ 静的型付け、オブジェクト指向、関数型プログラミング的、JSへコンパイル可 産業利用目的（初めて聞いたかも、この言葉ｗ） ・Java大変だよね。 互換性問題とか ・ライブコーディング 大変そうだｗKUnitってのもあるらしい。 （ゴメンナサイ、IDEA触ってて、流してました。。。Eclipseで作ってたプロジェクトをBitbucketから落としてきて四苦八苦してた） （参考にしたサイト（ググった）：http://d.hatena.ne.jp/waman/20100506/1273166533）\n◎AppCodeについて ・IDEAには含まれないので、別途ラインセンス購入が必要。 ・XcodeとAppCodeの違いをライブコーディングで説明。 ・XCodeよりも補完が良くできてるっぽい。 GUIはXCodeで作って、コーディングはAppCodeでやるってのがいいですよ。 ※私が、iOS系のアプリの開発ってやったこと無いからよくわかってないです。。。 XCodeはコードフォーマットがないのが辛い by @yusuke ","date":1355228520,"dir":"post/2012/","id":"898d25a2ab9c0ba1fa9bad462405e475","lang":"ja","lastmod":1355228520,"permalink":"https://blog.johtani.info/blog/2012/12/11/%E7%AC%AC%E4%B8%80%E5%9B%9E-jetbrains%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97--jbugj-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-12-11T21:22:00+09:00","summary":"イケメンが主催した「第一回 JetBrainsユーザーグループ #jbugj」に参加してきました。 いろんな製品があるんだなぁと。入り口には良いイ","tags":["勉強会"],"title":"第一回 JetBrainsユーザーグループ #jbugj に参加してきました(Jugemより移植)"},{"contents":"ヒカリエに行ってみたいという不純な理由で参加してきました。 新しいということもあり、おしゃれで綺麗なカフェでした。 入り口にはおっきな人形も立ってたし。 渋谷の夜景も見下ろせて素敵な場所でした。\nで、内容です。残念ながら、本編の3回めには参加していなかったのですが、 今回も濃い話が聞けたので楽しかったです。 論文読まなかったり、基礎を勉強したのに忘れてたりと抜けてる部分が多いので、 こういう機会が与えてもらえるというだけで目からうろこです。\n@kumagiさんの「あなたの知らないハッシュテーブルの世界」はハッシュテーブルの基本的な話から、最近の論文で発表されてる内容までをカバーする幅広いお話で面白かったです。 （大学でやってると思うんだけどすっかり抜けてる自分がなんとも。。。） こういうコアな中身も知ってると、色々とプログラム書いたりするときの見方や考え方も変わってきますよね。 （そんなプログラム書いてないけど。。。） で、随分おとなしい内容だなぁ？と思いきや、途中からちゃんとLock-Freeの話も出てきてさすがと感心させられましたｗ 最後はJubatusの宣伝まで入ってたし。（某氏のすごい写真入りで。。。）\n@hitoshi_niさんの文書要約の話は、NLPに興味があるので、楽しみにしていた内容でした。 今回もなめらかによどみなく喋られる発表にただただ感心させられるばかりでした。 内容は中級編ということで、文書要約のキモになる処理の文章の短縮の話です。 係り受け木を元にする手法をわかりやすく説明されて、もうなんか、すぐに実装できちゃうんじゃないかと錯覚してしまう始末でした。 係り受け解析というと、CaboChaを思い浮かべてしまうんですが、きっと違う実装なんだろうなぁ。 入門編と次回の重要文抽出の話も聞きたいなぁと。\n最後に、技術評論社さんから「Emacs実践入門」など3冊の書籍のプレゼントまでありました。 その他の2冊は購入済みだったのですが、Emacs本は購入したいリストに入れたままでした。 ということで、欲しいですというアピールをしてゲットしてきました！ Emacsはなんだかんだで、もう10年以上使っていますが、そこまで深入りしないような使い方をしていました。 これを機に、再入門してもっと使いこなせるようになろうかと。 また、読了したタイミングでブログに感想かきます。\nということで、以下はいつもの自分用のメモになります。おかしいところ、それ書いちゃダメでしょ的なところのツッコミをいただければ。\n日時：2012年11月28日(水) 19:00 場所：渋谷ヒカリエ27F NHN Japan カフェ ◎開会、諸注意など　@overlast 人材募集、会場説明など。 前回、本をもらった人はブログ書いてね。オライリー様より 今回も本のプレゼントあり。技術評論社様より ◎あなたの知らないハッシュテーブルの世界(30分 + 質疑応答10分)　@kumagi さん ・まずは前提。 データの集合を扱いたいよね 配列でもできるね。けど、データ増えるとキツイね。 ・ハッシュ関数の話から。 リハッシュとかの話 ・ClosedAddressingとOpenAddressingの話 ・ClosedAddressingの場合、ポインタ使ってるからキャッシュミスあり。 メモリとかの話 ・OpenAddressingメモリに乗るのでキャッシュミスは少ないけど、削除データの扱いがちょっと大変 →削除がいっぱい有ると処理が面倒 ・RubyはClosedAddressing、PythonはOpenAddressing memcachedはClosedAddressing ・Cuckoo Hashing（2001） 密度50%以上になると急にコストが高くなる。 挿入がすごく遅くなる。追い出し操作が増えるから？ ・そこで、Hopscotch ググった参考ページ：http://shnya.jp/blog/?p=639 http://en.wikipedia.org/wiki/Hopscotch_hashing 密度が上がっても性能劣化がない。 ・C++でHashtableが欲しくなったら、google_sparse_hashとdense使うよと。 ・ConcurrentHashmapのお話 テーブル部分がvolatile、Chain部分はfinal insertはChainの先頭に。 削除は遅い。ReadCopyUpdate。 空でも1.7M（K？）持ってく ・ここからはLock-free系 ・Lock-Free Hash Table http://www.azulsystems.com/events/javaone_2007/2007_LockFreeHash.pdf HotSpot VMの人のもの？こんなのやってる。http://www.0xdata.com/faq.html ・（聞きそびれた） ・日立謹製Lock-free hashtable 日立のDBで使ってる部品？ ベンチマークが胡散臭い ・最後はJubatusのCM ◎文書要約入門 中級編(40分 + 質疑応答10分)　@hitoshi_ni ・画数が少ないです。 ・ヒカリエ綺麗ですね。 ・文書要約とは？ 「機械に」要約させる。 ・なんで要約？ 長い文章読みたくない。人件費の削減 ・どうやって要約？ 1.文分割：文書を文に分割 2.文短縮：就職説を削除するなどして、原文より短い文の亜種を出す。 3.重要文抽出：要約にふさわしい文を選び出す。 ・今回は文短縮について ・動機 長い文は文抽出で扱いにくい 文の中にも重要なところとそうでないとこがある ・係り受け木の剪定すると短くできると。 剪定のルール 中間ノードは落としちゃダメ 除去の時に考えること 重要度 言語 ・重要度？ 文節に点数を付ける 文書集合中の出現頻度とかを採用。訓練データからでもいいよ（ロジスティック回帰とか）。 ・言語尤度 言語としての尤もらしさ 典型的にn-gram言語モデルを使う ・そして探索 基本的には2値ラベリング ビタビアルゴリズムではだめ。係り受け制約が考慮できない ナイーブいはビームサーチをする。 ・文短縮の評価 ・人間が書いた短縮文と比較 ・ROUGE-Lという尺度などで評価（これしらないなぁ。） ・幾つかの論点 係り受け解析しない 文節じゃなくて、単語単位でもいいよねとか。 Q：硬い文章以外の要約ってやってるの？ A：あります。 技術的な話だと、係り受け解析がうまく出来ればできる。 係り受け解析がうまくいけば、そこまで大変じゃない。 Q：短さが短くなるほど難易度があがるけどどこまでやってます？ A：短くすればするほど難しい。これは情報の欠落が激しくなるから。 文法性を担保するのも難しい。 10文字くらいならできそう。 Q：実例としてどのくらいの長さをどのくらい短くしてる？ A：ある程度の長さを20文字にしてくれとか。Twitterに入るくらいにしてくれとか。 頂いちゃいました！ Emacs実践入門　～思考を直感的にコード化し、開発を加速する (WEB\u0026#43;DB PRESS plus) ","date":1354122000,"dir":"post/2012/","id":"e01e01d18582c7f69e1b0db7e1b111a0","lang":"ja","lastmod":1354122000,"permalink":"https://blog.johtani.info/blog/2012/11/29/dsirnlp-3-5%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Femacs%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80%E3%82%92%E9%A0%82%E3%81%84%E3%81%A1%E3%82%83%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-11-29T02:00:00+09:00","summary":"ヒカリエに行ってみたいという不純な理由で参加してきました。 新しいということもあり、おしゃれで綺麗なカフェでした。 入り口にはおっきな人形も立っ","tags":["勉強会"],"title":"#DSIRNLP 3.5に参加しました。＆「Emacs実践入門」を頂いちゃいました！(Jugemより移植)"},{"contents":"第9回Solr勉強会に参加しました。 皆勤賞です！というか、主催者になってしまいました。 まだ不定期の開催になると思いますが、話をされたい方などいらっしゃいましたら連絡いただければ助かります。\n今回も面白い話が聞けました。\n最初はKuromojiの開発者でSolrのコミッターでもあるChristianの発表です。 Solr勉強会では初の英語の発表だったんじゃないでしょうか。 Atilikaでやってることの紹介から、Kuromojiの紹介、今後の改良に関する話とひと通り話してもらいました。 途中でKuromoji使ってる人？などの質問があったのですが、残念ながら反応が薄かったです。 漢数字をアラビア数字でも検索できるようにするチケットなど、今後のKuromojiの発展も楽しみです。 （コメントとかパッチを送れというプレッシャーもあったので、パッチ頑張って書きます。。。）\nつぎはニコ生でのSolrのお話。結構、赤裸々（前任者がいない状態で引き取ったとか）に語っていただき、ハラハラしながら聞いてました。 やはり、新語や略語で苦労されてるんだなぁと。 複数のサービスや開発者に対してSolrの環境を提供するという話はなかなか興味深かったです。 いろんな人がSolrを触るような状況になってきてるんだなぁと。 基盤となるラッパーのようなフレームワークとかも作ってるのかなぁ？ 今後は台湾語や英語への展開も考えられているようなので、Language Detectionなどを利用してみた感想とその内容を今度発表してもらいたいですねｗ\nつぎはFacetPivotの話です。 昔から要望が出ていたのですが、4.0系でやっと使えるようになりました。 ファセットはSolrの売りの一つだと思います。 最初はこの考え方がしっくりこない人もいるかもなぁと。特にデータをどのように作れば、いいのかって悩むこともあります。 その悩んだ内容について発表してもらいました。 実際にどうやって使うかを悩んだ内容を発表してもらうのもいいなと思いました。\n最後はSolr勉強会なのに、elasticsearchの洗脳会になってましたｗ elasticsearchはSolrと同じ、Luceneをコアに採用した検索エンジンサーバーになります。 Solrとは別のアプローチでLuceneをラップし、REST APIでアクセスしやすくしたプロダクトです。 Luceneのコミッターの方もelasticsearchの開発に参加しています。 分散インデックスを念頭においた設計や、インストールが簡単なプラグイン構造といったSolrとは違ったアプローチがなされており、面白いものになっています。 残念ながら日本で利用されているという話はまだ聞いた事ないですが、だからこそ、触ってみて事例を紹介してみるのも面白いのではないでしょうか。 今回紹介したKuromojiも使えるようになっていたりしますので、日本語でもある程度使えると思います。\n以上が簡単ですが感想です。主催者だったのに、@hirotakasterさんや@ajiyoshiさんに受付などをやっていただいたので、いつもの様にしっかり話を聞いてしまいました。 発表者の方、会場提供いただいたVOYAGE GROUP、お手伝いいただいた皆さんに感謝です！\n今回初の主催でしたが、本当に助かりました。たどたどしい説明や紹介など至らない点も多々有ったかと思いますが、今後もよろしくお願いいたします。\n主催者的な立場として感じたことも書いておこうかと。 無料の勉強会で、ATNDという参加しやすい環境というのもあるかもしれないのですが、キャンセルをきちんとしていただくほうがいいなと思っています。 幸いにもSolr勉強会はここ数回は盛況で、キャンセル待ちの方が結構いらっしゃいます。 ギリギリまで業務との兼ね合いを見つつ、参加しようと思っていらっしゃる方もいると思うのですが、キャンセル待ちで行けるかな？どうかな？と思っている方もいらっしゃいます。 ドタキャンは問題ないのですが、キャンセルせずに欠席は出来れば避けていただけると助かるなぁと。 （残念ながら、きちんと集計をとれなかったので、次回からは集計取ってみようかなぁと）\n次回の開催は今のところ未定です。発表してみたい方、こんな話を聞いてみたいなど、気兼ねなく連絡いただければと思います。 このブログにコメントを頂いてもいいですし、ツイートしていただいてもいいので、反応をいただけると嬉しいです。 また、今回至らない点があったなどのツッコミ、批判も気兼ねなく言っていただければと思います。 今後の反省点にもしたいので、ぜひ反応をいただければと！\n懇親会でも色々な方とお話できました。（もう少し、Christianと英語で話す努力とかしないとなぁ。。。）\nとりあえず、メモをアップしときます。 リンクとか感想とかはまた（飲んだ）後で。。。\ntogetterでまとめてももらったみたいです。ありがたいです。\n第9回Solr勉強会 場所：VOYAGE GROUP 会議室 日時：11/26(月) 19:00～21:00 1. Atilika Inc.　Christian Moenさん タイトル：Who we are, what we do, and a little bit about Kuromoji ◎Atilikaの紹介。 会社の目指すもの ・BigData、検索、NLP ◎プロダクト Kuromoji：形態素解析エンジン Akahai：日本語クエリサジェストエンジン Keywords：日本語キーフレーズ抽出 ◎Kuromojiの紹介 3.6からデフォルトで使える。 ◎将来の改良の話。 ・踊り字対応（コミット済み） ・漢数字に関するチケット＆パッチのお話。 ・ユーザ辞書の重複エントリ改良とか（すみません、パッチ書きます。。。） 2. 株式会社ドワンゴ　吉村総一郎さん(@sifue) タイトル：Solr@ニコニコ生放送 ◎ニコニコ生放送の紹介 ・1日に10万番組。。。 ・10/17にバージョンQをリリースしたら、トップはひどい叩かれようでした。。。 ◎これまで。 Jackrabbit→Lucene→Solr→ニコ生のSolr ◎退職者と入れ替わりでSolr担当。。。 今回は資料と環境を調べて発掘した機能のお話。。。 ◎機能 キーワード検索。論理クエリ、などなど。 ◎利用してる環境 3.4ベース＋Jetty マスタスレーブ構成（スレーブ2台） 途中は分散インデックスを自分で実装？ ボトルネック自体がDBからのデータ収集だった ◎インデックス対象 ・見れるのは過去1週間と過去の公式番組すべて。 この部分だけ検索可能。 ・更新頻度の高い情報に「来場者数」「コメント数」 ◎インデックス作成 ・バッチにて更新 ◎アナライザ CJKTokenizerFactoryを利用 HTMLStripCharFilterFactory Bi-gramなので、「FF」とか「DQ」に弱い（FF1でFF13とかヒットしちゃう） 検索精度は悪いと言われてるみたい。 ◎1日のリクエスト ピーク時40QPS程度 5分おきにスパイクがある。（ユーザが作ったツールによる検索とか。。。） ◎UPDATEリクエスト ピーク時は80QPS ◎開発用のJettyのマルチテナント機能を利用したSolr環境の提供 ◎台湾語とか英語もやりたいなぁ。　3. 株式会社マーズフラッグ　柳吾朗さん(@hitode7456) タイトル：ドリルダウン色々 ◎Facetの紹介から ◎楽天でのドリルダウン例（これはFacetの紹介での例であり、実際にSolrが利用されているかはわからないです。） ◎多段ドリルダウン（ファセット）のお話。 アプリを実装するときの考え方とか。 ◎実直形、工夫形、PivotFacet Q\u0026amp;A Q：3つの性能系のコストは？ A：まだ調べてないです。残り2つは工夫形がいいですよ。と 次回、調べた結果の発表もやってほしいなぁ。 4. 兼山元太さん (@penguinana_) https://speakerdeck.com/penguinco/solrtoelasticsearchfalsebi-jiao タイトル：SolrとElasticsearchの比較 ◎クックパッド！ ◎elasticsearchの紹介 ◎比較サイトもあるよ！ http://solr-vs-elasticsearch.com ◎サンプルデータ・セット（ライブドアグルメ）でサンプル実装。 https://github.com/penguinco/ld_gourmet_search ◎APIの紹介 REST APIがちゃんと造られてますよと。 設計時点でコレクションなどがURLに含まれてるのがいいよねと。 ◎_analyzeによりアナライザーもAPIとして公開されてるよと。 ◎Kuromojiも対応してるよ！ ◎DynamicFieldよりも便利だよ。 ◎クエリのDSLが違うのでちょっとアレ。 ◎スコアリングも色々できるよ。 ◎感想 ・機能面の不足なし ・APIがいい コア追加とか、curlだけでできるのがいい。 ・習得が容易（Solrやってると機能とか似てる） ・大規模じゃなくても使えそう ◎分散検索がデザイン時に組み込まれてるのがいいよね。 write consistencyなどがインデックスごと（コレクションごと？）に設定可能なので便利。 ◎multi-tenant open/closeなどができる（時系列データとか） shard allocationなどの細かな制御も可能ですよと。 ◎plugin 色々プラグインがあるよ。管理画面もプラグインであります。 プラグインもコマンド一発で追加可能。 ◎クエリキャッシュがないので、自前でnginx、varnishなどでキャッシュが必要。 ","date":1353923040,"dir":"post/2012/","id":"7e23419e4fc69b5b533815681c9bb1a9","lang":"ja","lastmod":1353923040,"permalink":"https://blog.johtani.info/blog/2012/11/26/%E7%AC%AC9%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/","publishdate":"2012-11-26T18:44:00+09:00","summary":"第9回Solr勉強会に参加しました。 皆勤賞です！というか、主催者になってしまいました。 まだ不定期の開催になると思いますが、話をされたい方など","tags":["勉強会"],"title":"第9回Solr勉強会を主催しました。#SolrJP(Jugemより移植)"},{"contents":"初目黒（たぶん）で、初Amazonな感じで、流行りの「ビッグデータ」のセミナーに参加してきました。\nとりあえず、いつもの自分用のメモを残しておきます。 感想はまた後日。。。（たぶん、頑張れ私。。。）\nAWS ビッグデータ活用事例セミナー 日時：2012/11/09 [ 金 ] 9:30 - 12:00 場所：アマゾンデータサービスジャパン目黒オフィス ★AWSビッグデータ概要 @understeer　○Amazonの紹介 ○Amazon Web Serviceの紹介 ・オンプレミスと比べ、初期費投資が不要 ・コストダウンを促進 過去6年で21回の値下げを実施 ・IaaSだけじゃなく、PaaSもやってますよ。 ・OSより上の層は好きに選べるよ。 ○AWSのサービスだけで20ある。 ○3つのV Volume　2012年で1.2ZB。95%が非構造データ。今後も非構造データが増加 Velocity　デバイスの増加、パーソナライゼーション系の増加 Variaty 素粒子のデータの解析とか、地質学、気象予報とかいろいろやってるみたい。 ○BIG DATAの4つのプロセス。 収集、保存、分析、共有を繰り返しやりましょう。 そこで！AWS使いましょう。 ○収集 AWSへのデータアップロード オンプレにあるデータをAWS（S3）にアップロード ・インターネット経由 ・専用線サービス（AWS Direct Connect、1/10Gbps）も可能 ・AWS Import/Export（HDDを送りつけてS3にアップロードしてくれる。Tokyoリージョンにはだない） ・インターネットVPN経由も可能 ・EC2上のデータももちろんできる。 ※WAN高速化ソリューションも利用可能。 ○保存 ・AmazonS3 99.999999999%の耐久性。 同一リージョン内の3箇所以上のDCに自動複製 容量無制限で低コスト（1G 約10円/月） ・Amazon Glacier データの利用準備に3.5～4.5時間かかる。 S3の約1/10という低コスト ○分析　オンプレミスだと運用が大変。 ・Amazon EC2 スケールアップ/ダウン、アウト/インが即座に可能。ライセンス持ち込みや従量課金に対応 スペックの種類が豊富（SSDとかもあるよと） ・Elastic MapReduce Hadoopをサポートしたの仮想サーバが簡単に用意可能。 S3、Dynamoとの連携も可能 ディストリビューションも選択可能（Apache、MapR） 追加のアプリ（Hive、Pig、HBase）なども利用可能。 ジョブの大きさに合わせてクラスタサイズを適切にすることでコスパがよくなる。 →HadoopのMRのデータのローカリティとかはどうなってるんだろう？ ○共有 ・AWS RDS MySQL、Oracle、SQLServerをサポート（PostgreSQLはないのかな？） 自動バックアップ、フェイルオーバー、パッチ適用機能があるよ ・Amazon DynamoDB AmazonオリジナルなNoSQLデータベース。論文有るよ。 運用管理は気にしなくていい。 性能については客指定の性能が出せるようになる。しかも変えられるよと。 ※データサイズに応じて以下を選択しましょう RDS、HBase on EMR、DynamoDB、S3 他にもEC2上で、CassandraやmongoDB、GlusterFSを使ってる事例もありますよ。 ○以上を繰り返すのが意味があります。そこで！ ・Simple Queue Service マネージド分散キューサービス 最低1度のメッセージ到達の保証。複数DC間で複製保存 ・Simple Workflow Service 進捗などの管理も可能 NASAのCURIOSITYの制御に利用？10m前進するのに10時間のバッチ処理がある。。。 データがなくて試せない！そんなあなたに！ ○AWS Public Data Sets すぐ使えるPublic Dataが用意されてるよ。 http://aws.amazon.com/jp/publicdatasets/ ★AWSのビッグデータ事例紹介　@shot6 ○NETFLIX ・どんな会社？ 2500万人以上のストリーミング会員 500億以上のイベント ・AWSの利用は？（保存） 8TB/日のイベントデータを収集しS3に。 Cassandra上の顧客データもS3に。 1PB以上のデータがS3に保存。 ・AWSの利用は？（解析） EMRでレコメンデーション、アドホック分析、パーソナライゼーションなど。 本番クラスタ（ずっと動かしている） アドホック分析用クラスタ（必要に応じて構築） 解析用のアルゴリズムをAPIで叩けて、ジョブとして定義されてるらしい ・Cassandraを使ってるよ。 Cassandraのクラスタをマルチリージョンで対応したりもしてる。 CassandraのBackupもやってる。OSSで公開されてる？ ※HBaseのものもあるよ。 ※AWS上のCassandra事例もいくつか広告系で出てるみたい。 ・High I/O Instances for EC2（SSDのインスタンスまだ東京に無いらしい。） ・AWSスケールアウトだけでなく、スケールアップも徐々に増えています。 ○yelp ・どんな会社？ 口コミサイト。 スペルミスの自動修正、検索ワード自動補完、 ・AWSの利用は？ WebサイトのログをS3に保存。 EMRを利用してHadoopClusterで解析してS3に保存している。 EMRは処理終了後にシャットダウンしてる。 ・データ解析が日常になった ○SHAZAM ・どんな会社？ 広告配信、モバイル系の配信をやってる会社。 Super Bowlの広告配信でAWS、DynamoDBを利用。 ※マイネット・ジャパンでもDynamoDBを利用している ○CLIMATE Corporation ・どんな会社？ 天候保険の会社 ・AWSの利用は？ 200TBの地質、天候データを解析して ○THOMSON REUTERS ・どんな会社？ 情報提供の会社。データの提供が元だけど、解析した結果の情報も提供してるみたい。 ・AWSの利用は？ MarketScanという18年分の個人の医療データ（個人情報自体はないみたい）を販売する、販促ールとして利用。 1500万人分の患者データを提供。 マーケットの分析に使えるデータの提供。 KARMASPHEREとEMRの組み合わせで、ソリューションを提供していますよと。 ・事例 1.MarketScanをS3にアップロード。 2.分析官が、KARMASPHERE経由でEMRにアクセス。 3.EMRにS3からデータロードされ、結果がRDS（Oracle）に保存 4.RDSに他の人達もアクセスして使ってるよと。 ○RANGESPAN ・どんな会社？ ECサイト向けのPaaSサービスを提供してるロンドンの会社。 ・AWSの利用は？ NLP、機械学習にEMRを利用？ mongoDBのクラスタを構築してる。 ※mongoDBの日本の事例としてCAがあるらしい。 ★Huahin Framework活用事例 on AWS @ryu_kobayashi ○Cassandra本とかもやられてるみたい。 ○EMRとは PaaSなんだけど、中身を自分でいじれるらしい。 Management Consoleでは3つのバージョンが使えるが、コマンドラインからだと他にも使えるみい。 ・HBaseはAmazonのDistributionのものだけ。 ・EMRのメリットは？ インフラの面倒を見なくていい。 クラスタの立ち上げも複数あげられるので簡単。本番実行と同じ環境 ・EMRのデメリット オンプレミスにすでにデータがあるとアップロードが大変。実際に物理HDDを送ったこともある（2,3日でAWS上にアップロードされた） 外に出せないデータがあると。。。 ○EMRのTips（EMRの連載に載ってますよ！http://gihyo.jp/dev/serial/01/emr） ・Bootstrapを設定 EMRのクラスタの起動前にメモリ設定とかHadoopの設定が可能にできる。 ・ファイルサイズを適切に Map数=splitを決めるコード を指定することで、処理が早くできるのかな？ ○EMRの起動には いろいろあるけど、HuahinEManagerを使うと使いやすいよ？ ○Huahin Frameworkの構成 ・Huahinの名前の由来は？ 社内のコードはワインの産地にするという決まり。 タイの観光地Hua Hinがワインの産地。 ・他のHadoop関連のマスコットより可愛いでしょ！？ ・Huahin Core MRのプログラムを簡易化 WritableとかSecondary Sortとか書かなくていい 考え方がSQL寄り 素のMRも書ける。Pig、Hiveだとパフォーマンスが難しい Huahin UnitというMRUnitをラップしたものもある ・Huahin Tools 汎用的な処理を集めたツール群だけど、Apache Logの成形のみ。 オンプレミスHadoop、スタンドアロン環境でも動かせるようになってる。 ・Huahin Manager Jobを管理するマネージャ Jobの実行 キューを持ってるので、複数の実行が可能だよ。 EMR対応してる。bootstrapに設定するとできるらしい。 ・Huahin EManager EMRのいろいろが管理できるみたい。 初期設定20までしかインスタンスが挙げられない上限があるらしいので気をつけましょうと。 キュー登録のPOST機能は便利そうだ。（EMR触る機会まだまだないけど。。。） EMRにはJobのkillがない→Job FlowをターミネートすればOK→実際にはEMRのマスタノードにSSHすればできるよ。→めんどくさいよね。。。 EManagerなら可能ですよと。これは必須だよなぁ。 ","date":1352477220,"dir":"post/2012/","id":"98c640616f997a323af625e34ba34850","lang":"ja","lastmod":1352477220,"permalink":"https://blog.johtani.info/blog/2012/11/10/aws-%E3%83%93%E3%83%83%E3%82%B0%E3%83%87%E3%83%BC%E3%82%BF%E6%B4%BB%E7%94%A8%E4%BA%8B%E4%BE%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-jawsug/","publishdate":"2012-11-10T01:07:00+09:00","summary":"初目黒（たぶん）で、初Amazonな感じで、流行りの「ビッグデータ」のセミナーに参加してきました。 とりあえず、いつもの自分用のメモを残してお","tags":["勉強会"],"title":"AWS ビッグデータ活用事例セミナーに参加しました。#jawsug(Jugemより移植)"},{"contents":"##Lucene/Solr 4.0.0リリース ついに、Lucene/Solr4.0.0がリリースされました。 MLで流れていましたが、3年越しのリリースだったようです。 コミッターの方々、JIRAにバグ報告をした方々、お疲れ様でした。\nということで、ちょっと忙しくなりそうです。。。 4.0の機能を調べたりもしたいですし、すこしずつ紹介もしたいです。\n本家サイトのニュースはこちら\n##lucene-gosenの4.0対応版について lucene-gosenも4.0正式版のjarを利用したバージョンを公開する予定です。 branches/4xでは、すでに作業を行なっており、jarファイルの差し替えは終了しています。 お急ぎの方は、branches/4xをエクスポートして、ビルドしていただくと利用可能となっています。 なお、Lucene/Solrのバージョンが上がっているため、lucene-gosenのメジャーバージョンも変更し、lucene-gosen-4.0.0としてリリースする予定ですしました。。（順当に行けば、3.0.0ですが、Luceneのメジャーバージョンに合わせたほうがわかりやすいかと思いまして。） また、現在、trunkが3.6.x対応のソースになっていますが、このあと、現在のbranches/4xのソースをtrunkにする予定です。 3.6.x対応のlucene-gosenについては、branches/lucene-gosen-rel2.0にて作業を行うこととなります。 今後は注意してチェックアウトするようにお願いいたします。\nということで、ダウンロードできるようにしました。 lcuene-gosen-4.0.0*.jarとついているものがLucene/Solr 4.0.0に対応したライブラリになります。\n","date":1350031500,"dir":"post/2012/","id":"922cc71fd28b1dac8f407f1d517f5595","lang":"ja","lastmod":1350031500,"permalink":"https://blog.johtani.info/blog/2012/10/12/lucene-solr-4-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9lucene-gosen%E3%81%AE4-0%E5%AF%BE%E5%BF%9C/","publishdate":"2012-10-12T17:45:00+09:00","summary":"##Lucene/Solr 4.0.0リリース ついに、Lucene/Solr4.0.0がリリースされました。 MLで流れていましたが、3年越しのリリースだったようです。","tags":["lucene-gosen"],"title":"Lucene/Solr 4.0.0リリース＆lucene-gosenの4.0対応(Jugemより移植)"},{"contents":"このイベントにウチダスペクトラムの枠でMahoutのコミッターである、Grant Ingersollさんが講演されるということで、興味があったので聞いて来ました。 （この枠だけ）\nLucidWorks社が現在展開している、LucidWorks BigDataの概要とコンセプトといった話の内容でしょうか。 LucidWorks社（元Lucid Imagination）はLucene/Solrのコミッターの方々が多く在籍している会社です。 検索システムに関するノウハウを元に、発見や解析といった部分にニーズが広がってきているという話の ざっくりした概要のはなしでした。 検索システムを中核にして、ログや検索で提供しているデータの解析などの重要そうなポイントが散りばめられて いるお話でした。\nもっと詳しい話を聞きたいなぁ。\n講演では日本語の資料でしたが、サイトに英語の資料がアップされているとのことでした。 原文が読めるのは非常に助かります。他のイベントなどでもこのように英語の資料も見れるようになると嬉しいです。\n以下は、いつものメモになります。\n場所：富士ソフト　アキバプラザ5Fホール 日時：16:10- ◯サーチ技術による情報の可視化 通常、検索と言うとWebサーチだけど、ウチダスペクトラムのやっている部分はエンタープライズ向け ナイスガイ＝Grant S. Ingersollという紹介 ◯サーチからSDAへ LuceneやSolrのお陰で、検索自体は簡単になってきている。 ◯サーチの進化 ユーザとデータを結びつける意味での検索の進化が必要 ユーザインタラクションや、アクセスの方法とか ◯SDA Search, Discovery and Analytics ・ユーザからのニーズ 検索、優先順序付け、新たな気づき、フィードバックによる学習 ・ビジネスからのニーズ ナレッジの有効活用 ◯ユーザ事例 保険会社での請求に関する不正利用分析を含んだクレーム処理と分析 ◯事例：個人に最適化された医薬品 DNAをベースに検索やファセットで医薬品を検索したり。 ◯事例：通信会社における通話記録処理 ログを元に検索して、不正通話などを解析 ◯SDA基盤に必要な要素 高速で拡張性のある、検索 大規模でのコスト効率が高いストレージと処理 NLPとMLにより解析などが向上 ◯SDAのアーキテクチャ 基盤 LucidWorks Search、Hadoop、HBase、ApachePig、Mahout、 NLP、 管理 Zookeeper インフラ ZABBIX、AWS、Chef データの流し込み Twitterからのデータとか ◯検索部分にフォーカス ・LucidWorks Search SolrCloudによる簡単なshard処理 ・Hadoop ログ、生データ、中間ファイルの保存 WebHDFS 小さなファイルには向いていない ・HBase メトリック、ユーザ履歴などのストレージ 課題 どこに正式に保存する？ リアルタイム処理 vs バッチ処理 分析はどこで行われるべきか？ ◯検索の実装に関連すること 3つのポイント 性能と拡張性 関連性 オペレーション（モニタリング、フェイルオーバーなど） ビジネス側では検索結果の適合性を重要視する 開発側は性能を重視する傾向がある。 ◯適合性に関して テストが重要。 クエリ、クリック、表示したドキュメントなど、すべて保存すべき！ ◯Discoveryにフォーカス ◯MahoutによるDiscovery 3つのC ・協調フィルタリング ・クラシフィケーション ・クラスタリング 追加事項 課題 収束を伴う計算コストの高い機械学習アルゴリズム Mahout ◯余談：Experiment Management ◯Analyticsにフォーカス Rとか、うまく活用 検索エンジン自体でもできることがある。ファセット、TF、DF/IDF SearchとDiscoveryの定量化 ログ、ナビゲーション分析 ","date":1348650492,"dir":"post/2012/","id":"43501cdf0de25278a208cbb9aad80012","lang":"ja","lastmod":1348650492,"permalink":"https://blog.johtani.info/blog/2012/09/26/lucid%E3%81%AEgrant-ingersoll%E3%81%95%E3%82%93%E3%81%AE%E8%AC%9B%E6%BC%94%E3%82%92%E8%81%9E%E3%81%84%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-09-26T18:08:12+09:00","summary":"このイベントにウチダスペクトラムの枠でMahoutのコミッターである、Grant Ingersollさんが講演されるということで、興味があった","tags":["勉強会"],"title":"LucidのGrant Ingersollさんの講演を聞いてきました(Jugemより移植)"},{"contents":"PFIオープンセミナー2012に参加してきました。 対象から微妙に外れてたり、話の内容についていけるか自信がありませんでしたが、参加してきました。 PFIさんは前から面白そうなことやってる会社だなぁと思っていたので。\n面白い話がいっぱい聞けました。 電池が切れそうなので、とりあえず、まずはメモをアップしときます。 かろうじてついていけたという感じですが。 丸山先生の話はアーキテクチャの話に入る前のビッグデータの光と影の話がよかったです。 ビッグデータと言っても、まずは、サンプリングなどで小さなデータで処理できるかもしれないと考えるのも必要なのでは？という話や、相関があるからといって、因果が有るわけではないとか、おそらく、統計やってる人や、数学やってる人にしてみれば、当たり前の事なんでしょうが、その部分に警鐘を鳴らす話が聞けたのは良かったです。 もちろん、ビッグデータでなければ意味が無い解析などもありますという話もきちんと出ていました。\n伊藤さんの話は、Screwと呼ばれる、多言語解析基盤のお話です。その前にSedueの紹介で、SolrとSedueの比較の話も出ていました。（若干、強引な感じもしましたが。。。） 多言語解析基盤は、Solrでも少し入ってきています。ただ、それよりも汎用的な作りになるようなので、今後Solrと組み合わせて使うといったことも可能になるかもしれません。 まだ、対応言語などが少ないので今後に期待という感じでしょうか。 複数の言語が混ざった時の挙動がどうなるのかや、身近な文章での言語判定の正確さは少し気になります。\nサイバーセキュリティの話も面白かったのですが、話が多岐にわたるのと、スライドの情報量の多さに少しついていけませんでした。 資料が公開されたら、もう一度見直したいかなぁと。\n比戸さんの話は、Jubatusと関連のある話でした。機械学習の実際の利用の話が特に興味深かったです。 最近になって、ようやく、実際のデータを利用した話が出てきているみたいで、もっと事例が出てくると機械学習も身近になりそうだなぁと。\n最後は、日経BPの中田さんの話でした。これが、一番想像していたものと内容が違って、驚きつつ、楽しめた話でした。 ビッグデータというバズワードがいかにして生まれたのかがよく分かりました。 私は、バズワードだなぁと思う程度だったのですが、出てきた背景にある程度意味があるという考察に感心して聞き入ってしまいました。\nということで、思っていたよりも話の内容についていけたので、講演された方々の話しのされ方が良かっただと思います。\n少し無理をして参加してよかったと。\n残念だったのは、会場が地下だったため、携帯が入らなかったことでしょうか。 私はe-mobileで接続していたので大丈夫でしたが、docomoの携帯は圏外でした。 ツイートがもう少し盛り上がれば、もっと質問も出たのかもしれないです。\nhttp://preferred.jp/news/seminar/\n資料が公開されたので、リンクを貼っておきます。 PFIの方たちの資料へのリンク： http://preferred.jp/news/?id=1139\nゲスト講師の資料へのリンク： http://preferred.jp/news/?id=1159\n◯「多様化する情報を支える技術」　講師：西川徹（株式会社プリファードインフラストラクチャー　代表取締役） ・PFIの説明 VCに頼らない。製品につながるビジネスにこだわる（受託開発しない）、技術の多様性を重視 ・PFIの技術領域、ビジネス 製品開発（Sedue/Bazil/Jubatus）、自然言語処理、機械学習、分散システムなど ・”人”が生み出すデータと\u0026#34;機械\u0026#34;が生み出すデータ ビッグデータの発端はGoogleが元じゃないか？→最後の公演で解説があるよ 人：質が高いけど、量が少ない 機械：質は低いけど、量が多い ・検索システムについてのお話 社内の資料とか情報が、人によって、まちまちなデータの保存（形式、場所など）が実施されてしまう。 情報検索技術と大規模データ ・人のデータへ必要なアプローチ より検索システムを活用してもらうために、楽に整理できる仕組みなどをどう提供するか 質の高いデータなのに、形式的な共有しかできていないのはもったいない ・機械のデータへ必要なアプローチ 大量データと高度な解析が重要（CEPとか） デバイスが性能向上→流れてくるデータが大量に→蓄積するだけでも問題になってくる →蓄積したデータを扱うだけでも処理コストが高くなる 分析をオンライン化、ストリーム化すること→Jubatusで貯めずに高度な解析をしましょう。 Edge-Heavyになりつつある。　◯「ITアーキテクチャはどこへ向かうのか」 講師：丸山宏氏（統計数理研究所　副所長　モデリング研究系教授　工学博士） ・ビッグデータの光と影 「その数学が戦略を決める」という本がオススメ ・大量データでも、ランダムサンプリングでとければ、ビッグデータじゃなくてもいいよね。 もちろん、ランダムサンプリングだけじゃダメな場合もある。 ・Hadoopが解ける問題領域って少ないのでは。 ・TVを見る時間が長い人ほど、方言の使用率が高い 因果関係と相関関係の違いをきちんと理解しましょう。 ・データをきちんと理解して意思決定などをしたほうがいいよと。 ・つぎのアーキテクチャは何か？ ・コンピュータ・アーキテクチャの歴史 ConnetionMachine CM-1（1985） SPARC Transputer（CSPによる並列性、Occam） SymbolicsLispMachine Intelアーキテクチャの台頭により、アーキテクチャの研究が廃れてくる ・クラサバ、スマホ・クラウドなどのアーキテクチャの話 ・じゃあつぎは？ Edge-Heay Data＝スマホなどデータが保存される場所がEdgeになりつつある ビッグデータのほとんどが廃棄されるデータ ・Edge-Heavy Dataに特化したアーキテクチャとは？ 分散マッチング・プロトコル→サマリ情報を交換することで、絞り込みが可能 X=3とした場合、センサーとかなら、ピンポイントな値ではなく、範囲では。 分布表現を1stクラスオブジェクトとするプログラミング言語が必要では？ ・アーキテクチャの変節点を見極めよう QA： Q：スパースネス問題がランダムサンプリングやフィルタリングじゃ解けないんでは？ A：はい。ただ、その前にやることがあるはずですよねという注意喚起の意味での発表です。 価値に応じて、EdgeにあるデータをCenterに持ってくるという考え方が必要。 今は価値が見いだせないのなら、Centerにまで持ってこなくてもいいのでは。 ◯「グローバル化する情報処理」 講師：伊藤敬彦（株式会社プリファードインフラストラクチャー 研究開発部門　リサーチャー） ・Sedueの説明 NHKニュースなどで ・提供する機能 ・検索補助 レコメンド、サジェストなど ・レコメンド機能の紹介 ・Sedue/Solrの比較 サポート体制：開発チームがサポートしてくれる 安定性：GCがないのがいい 付加機能： 検索の完全性：接尾辞配列による検索 ・多言語処理の話 ・翻訳ではなく、任意の自然言語言語で動作・精度を向上させる処理の話。 ・背景 サービスのグローバル化、会社組織のグローバル化 ・複数言語を扱う場合の難しさ 多言語解析基盤Screwの開発。 1.必要な処理を順番に適用する 処理の順序は設定で。出力はJSONで。 例：言語同定、単語分割、単語正規化 →言語同定処理で 2.言語ごとに必要な処理を適用 ・疑問 ScrewはSolrとの組み合わせもできる？ 複数言語が混ざった文章の場合にどういう形で動作する？ 言語判定は独自実装？ ◯「BigData処理技術とサイバーセキュリティ」→題名変更されてた 講師：桑名栄二氏（NTTセキュアプラットフォーム研究所　所長） ・経歴 Jubatusプロジェクト立ち上げに参画 ・攻撃に関する話 原因のわかっていないケースが多い。 ・端末の初期設定のパスワードとかが狙われるケースも多い ・変化する攻撃、変化するシステム・サービス、変化するデータ ・マルウェアの分類にJubatus ・不正IPアドレスを機械学習して ・ABC 「あたりまえ」のことを「ばかみたいに」「ちゃんとやる」 ◯「先進ビッグデータ応用を支える機械学習に求められる新技術」 講師：比戸将平（株式会社プリファードインフラストラクチャー　研究開発部門　リサーチャー） ・ビッグデータ分析はより深い地検を得られるビッグデータ「解析」へ ・ビッグデータ分析プロセス Volume、Variety、Velocity 蓄積（NoSQL系）、分析（CEP）、両方やるのがHadoop ・分析から深い解析へ 予測、カテゴリ分類、レコメンド、異常検知　これを機械学習で解決する方向で ・機械学習を応用している例 クレジットカードの不正利用検知：FICO ネットワーク攻撃/侵入検出 Jeopardy!でクイズ王に勝利 医療診断支援 ・データ解析技術への過度な期待と現実とのギャップ いろいろできるみたいだけど、何が必要？ ・ビッグデータ処理系を使える人 ・データサイエンティスト ・機械学習ツール ・ビッグデータ処理系での機械学習への対応状況 Hadoop本体（YARN） MapReduce系（Mahout、AllReduce or Vowpal Wabbit、SystemML） 非MapReduce系（Spark） ・機械学習からビッグデータへの歩み寄り ベンチマーク性能への固執とか、応用との乖離を批判する論文もあるらしい。 ・機械学習の応用例 Machine Lerning for the New York City Power Grid[Rudin et al., TPAMI, 2012] 電力配電設備の障害予測・検知 実データを用いた例が今後増えていくのでは。 ・今後重要になる技術とPFIの取り組み ・データ解析の敷居を下げるためのトレーサビリティ 機械学習向けスクリプト言語は敷居が高い WekaやSPSSのようなアイコンベースのデータ処理プロセスの記述は前処理には強力だけど、機械学習とは相性が良くない 結果が見える化部分との統合が不十分。 ・Bazil Farm学習結果分析例 Tweet年齢推定、Tweet性別推定 ◯「“ビッグデータ”が話題になった理由」 講師：中田敦氏（株式会社日経BP社　記者） ・自己紹介 ・バズワードができるまで まずは、「クラウド」のバズワードの歴史 「バズワードはIT企業やThe Economist誌の煽りでなく一般企業の経営陣が納得すると生まれる」 ・なぜ経営者がビッグデータに興味を？ 「ザ・クオンツ」という書籍に金融業界のルールの変化が書かれてる。面白いよ。 Google/Amazonに対する警戒心から。 破壊的な新規産業者へ対抗して行かないといけない思うところからビッグデータが流行ってるのでは。 「買ってきたIT」は差別化要因にならないのでは？→自分で作ったITなら差別化できる。 ・競争力は自分で作るしか無い 日本のとある特殊事情 ITエンジニアの所属先が日米で割合がぜんぜん違う。米国はユーザ企業が75%、日本は25%くらい ・ビッグデータの次はなに？ 3次元プリンタがあれば、好きなモノが作れちゃう。＝消費地の近くで作成しちゃえば良くなるのでは。 ","date":1348214700,"dir":"post/2012/","id":"89abaa7f21cf788ce4744e3e61173291","lang":"ja","lastmod":1348214700,"permalink":"https://blog.johtani.info/blog/2012/09/21/pfi%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC2012%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pfiopen2012/","publishdate":"2012-09-21T17:05:00+09:00","summary":"PFIオープンセミナー2012に参加してきました。 対象から微妙に外れてたり、話の内容についていけるか自信がありませんでしたが、参加してきまし","tags":["勉強会"],"title":"PFIオープンセミナー2012に参加してきました。 #pfiopen2012(Jugemより移植)"},{"contents":"友人にお値打価格で購入したMac miniはMountain Lionにアップデートしてたのですが、手元のAirはまだアップデートしていませんでした。\n夏休み中にバックアップ＋アップデートをしてしまおうと思いMountain Lionにアップデートはしていたのですが、 本格的に触り始めると色々と動かないものがあったので、備忘録としてブログを書いておきます。 （まだ途中ですが。）\n###1.Eclipseが起動しない Java6が未インストール状態になったみたいで、Eclipseを起動すると、Java6をインストールしなさいと言われました。 で、私の記憶が確かなら、前はJavaコマンドを実行するとインストールされたんですが、ターミナルでjavaコマンドを実行するとjavaはすでにインストールされてる模様。。。 あれ？と思い、-versionを実行すると、JDK7u4と出るじゃないですか。 どうやら、Java7u4は別途入れてたものが残ってる模様。 さて、どーする？ということで、ツイートしたりぐぐってみて、「Java Preferences」なる設定用のアプリ？が有ることに気づき、とりあえず開いてみたらJava6ないからインストールしたら？と言われました。 結果オーライということで、インストール開始。 無事、インストールも終了。Eclipseも起動しました。（ただし、今度はMercurialのプラグインがPythonのライブラリが無いとエラーを出すことに） ###2.Xcodeが起動しない。 使ってはいないんですが、Javaの件を調べるのに、起動したらLionじゃないと駄目だよと。 ということで、Xcodeもインストールしなおし。 ###3. homebrewが動かない 1.で書いた方法で、Eclipse自体は起動したんですが、Mercurialのプラグインがエラーを吐き始めました。 で、見てみると、hgコマンドを実行しようとしてなんか、壊れていると。 で、hgコマンドってどうやってインストールしたか思い出さないまま、とりあえず、homebrewだっけ？と勘違いしたまま、「brew update」を実行したらエラーがでて、「brew install git」でしょ？って言われてしまいました。 コメントにもいただいていたように、Xcodeをインストールしたのだが、コマンドラインツールが入ってないというのが影響しているみたいです。。。 で、ググってみると、こんな情報が。[http://labs.torques.jp/2012/07/04/2830/](http://labs.torques.jp/2012/07/04/2830/) ただ、そこに有るようにPreferenceのダウンロードを開いてもなーんにも表示されません。 で、更にググってこちらの情報に。[http://qiita.com/items/9dd797f42e7bea674705](http://qiita.com/items/9dd797f42e7bea674705)（なんだか、TLで見かける人のお名前が！） AppleのDeveloperサイトからダウンロードかぁと思いつつダウンロード用のリンクを踏んだら、アカウント登録しろとのページが。。。 なかなか遠い道のりですね。。。 Appleのアカウント自体は持ってるので、Developerへの追加登録なんですが、日本語が文字化けしまくりの確認ページが出る始末。 もう、めんどくさいので、そのまま登録しちゃいました。 で、ダウンロードする前にもう一回XcodeのPreference見てみたらなんか、ダウンロードする候補が出てきてるじゃないですか！ 結局、XcodeのPereference画面からダウンロードすることにしました。 AppleのDeveloperに登録したからなのか、Xcodeのプロジェクトを作ろうとしてXcodeをきちんと起動したからなのかは結局わかっていません。。。 良くないよなぁ。（ご存知の方いたらコメントもらえると嬉しいです。） で、やっと「homebrew」を入れようかなぁと。 一応その前に「sudo brew update」ってやってみたらどうなる？と挑戦したら今度は動きました。 homebrewが何を判断してinstallでしょ？って言ってたのかもわかっていませんが、updateで良かったみたいです。 ついでに、upgradeもしときました。（こっちは後からインストールしたもののバージョンが上がってるものがあったら更新してくれるコマンドかなぁ？）\n###4. pipの更新 ただ、brewをupdateしても相変わらず、EclipseのMercurialのPluginはエラーを出してました。 で、ターミナルからhgコマンドを実行してみたら同じエラーが。まぁ、そうですよね。 エラーメッセージを頼りにこれまたググってみたら、同じ状況のひとがいました。[https://groups.google.com/forum/#!msg/mercurial-ja/MxY6lejLXxo/OgJA_knXV6cJ](https://groups.google.com/forum/#!msg/mercurial-ja/MxY6lejLXxo/OgJA_knXV6cJ)（ここにもTLでお世話になってる方のお名前が！！） で、書いてあるように「とりあえず pip install mercurial で解決しました. 」ということで、コマンドを実行して見ることに。 これが、また失敗します。。。（日頃の行いが悪い？？てか、日頃MBAをメンテできてないのが悪いのか。。。） そういえば、過去のMBAセットアップのメモを残してたなぁと思い出して「johtani mercurial」でググってみるとちゃんと[書いてある](http://johtani.jugem.jp/?eid=34)じゃないですかー（偉いぞ、自分） ということで、「sudo easy_install pip」でpipを更新してから「sudo pip install Mercurial」で無事、hgコマンドもインストールし直せました。 Eclipseを起動してもエラーが出ない。（まだbitbucketに接続確認まではできてないですが。。。眠さに勝てず寝てしまいました。） ","date":1346650440,"dir":"post/2012/","id":"7604edf307a5e96120606c8dda06458f","lang":"ja","lastmod":1346650440,"permalink":"https://blog.johtani.info/blog/2012/09/03/%E3%83%A1%E3%82%A4%E3%83%B3mba%E3%82%92mountain-lion%E3%81%AB%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88%E3%81%84%E3%82%8D%E3%81%84%E3%82%8D%E7%A2%BA%E8%AA%8D%E4%B8%AD/","publishdate":"2012-09-03T14:34:00+09:00","summary":"友人にお値打価格で購入したMac miniはMountain Lionにアップデートしてたのですが、手元のAirはまだアップデートしていませんで","tags":["備忘録"],"title":"メインMBAをMountain Lionにアップデート（いろいろ確認中）(Jugemより移植)"},{"contents":"興味をもちつつ、触っていない軟弱者ですが、興味があるので今回も話を聞きに行って来ました。\nまずは、作者古橋さんによるFluentdの魅力や次期バージョンのお話。 あいかわらずわかりやすいスライドで話もわかりやすくてよかったです。 どうしても実績という点を懸念事項として上げる人が多いというアンケートを元に、各社が使ってるし導入もしやすいですというお話。 ここまでしてもらってるのに触ってないなんてほんと申し訳ないです。。。\n次は楽天の方によるCloud Foundryのログの問題点解消のためのFluentd導入のお話。 EC2でもそうですが、ファイルが永続化されない？のでログが消えてしまうという問題があるので、 集約しましょうと。 いままでとは少し違う問題点からの話でした。\n次はドリコムの方（浴衣？甚平？でかっこ良く発表）のIDCをまたいだFluentdの活用と、Fluentd自体の監視などについてのお話。 実際にログが増殖して苦労された点を解決するために考えられた監視項目など、あとで見返したくなる資料でした。 実際に試行錯誤されたあとの話はやはりありがたいです。 あと、お子さんが可愛かったｗ\nつぎのCROOZの方のPCがWindowsだったため（？）プロジェクターに繋がらず、急遽QAタイム。 このあたりの@doryokujinの話のつなぎの旨さとかほんとすごいなぁと感心します。\nで、Macに乗り換えてCROOZの方の発表。 Fluentd＋TreasureDataのお話。少人数（というか一人？）でも簡単にログ収集の仕組みが作れて、しかも保存先のサーバを用意せずに簡単な解析もできるというお話。 これは、ちょっとやってみようと思う人（少なくとも、私はやろうと思った）が増えたんじゃないかなぁという発表でした。 スライドがなぜか最後のほうが見えなくなってしまったので、第３回でも発表されるということになってましたｗ 最後は新大阪から文字通り駆けつけた玉川さんのHBase本＋そのた今後の翻訳本の紹介。 つぎはHiveの本も出てくるみたいでした。 日本語の資料ってホント助かります。購入しないと翻訳本が出る機会もないみたいなので皆さん買ってくださいとのこと。 HBaseはまだ触りそうにないから９月に出るAWSの本でも買おうかなぁ。 あ、日本語で解説してあるSolrの本もあるので是非買ってください！\nその後は懇親会でした。今回もTL上でズケズケと私が勝手に絡んでいる方たちにリアルにお会いできたので楽しかったです。\n自分もフロントよりも、バックエンドに興味があるし、実際に運用されてる人の話が多く聞けるので次回も参加したいです。 それまでにどこかで触るかplugin作るかしないとなぁ。\nということで、以下はいつもの適当メモです。\n開催日時：2012/08/22 18:00 ～ 22:00 場所：グリー株式会社 14F セミナールームYosemite ◎「Fluentdの現在と未来」　Treasure Data, Inc.　古橋　貞之 (@frsyuki) ◯アンケートの内訳 ◯ドキュメント欲しい？ ※思ったより日本語のドキュメントじゃなくてもよさそうだった。 ◯loggingってなんでいるの？ いろいろな解析ってあるよね。 ◯ログの集約、保存、などの問題点について フォーマットが混在 集約するのもいろんなスクリプトが混在 ◯メリット ・プラグインアーキテクチャ in/outに合わせてプラグインが用意/開発可能 ・フォーマットがJSON アプリでの解析が楽 ・HA構成が可能 ◯実績がない？→ 誰が使ってる？ COOKPADとか、NHNとか ◯次期バージョンの構想 ・設定ファイルで色々とらくできるよ。 ・MessagePackのv5に対応 ・td-agent-lite などなど ◯QA Q：時刻にミリ秒を持つことは可能？ A：互換性も気になりますが、検討します。 Q：JSONで構造化が売りだが、Flumeとかはテキストだけど、テキスト A：ログのパース時にやるというスタンス。 Q：日本語ドキュメントがやっぱり欲しい。手伝います！ A：別ブランチで翻訳しながら公開して欲しいし、バラバラにやるよりいいので。 Q：Windowsでも動かしたいけど、cool.ioの移植とか考えてないですか。 A：次期で、fluentdのコアからはcool.ioを外す予定です。 ◎「Logging Infrastructure in PaaS by Fluentd」　Rakuten, Inc.　Yohei Sasaki (@yssk22), Waldemar Quevedo (@wallyqs) ◯Cloud Foundryの説明 ◯Cloud Foundryの問題点 解析しようにもログが消えてしまう。。。 なので、Fluentdでログを集める仕組みを作ったよと。 これかな？ https://github.com/rakutentech/dea/ ◎「Fluentdを優しく見守る監視事例」　株式会社ドリコム　外道父 ( @GedowFather ) ◯概要： Fluentdをより穏やかに安定稼働させるための監視項目と自動処理について。また，その実運用における障害例なども紹介したいと思います。 ◯目次 ◯動作環境 ・IDCもバラバラな環境のログを一箇所に集約。 グローバルなネットで、圧縮、暗号化し、VPN使ってない ・tailのプラグインを改良して利用 copy、flow counterを利用 forwardも改良 Flume OGとは比較にならないし、FlumeNGはOGと全然違うから論外だった。 ◯ローカル監視 ・monit使って監視してる。 ログを記録してるか、内容が正しいか td-agentが正しく起動してるか、Collectorに送っているか 重複起動してないかとか、起動してるかとか。 ※重複起動でログが増えてた（@mazgi濡れ衣事件） HDFSに送ってるか、保存されてるか ◯リモート監視 アラート/グラフ作成の集約 状態の可視化 Collectorのキャパシティ管理 Agentにキャパシティの心配はほぼないが、Collectorは足りなくなる可能性がある。 ◯野望 CollectorでAgentを把握したい ◯QA Q：圧縮はどうやって？ A：forwardを改造してやっている。 ◎QAタイム Q：秒間どのくらい出るの？ A；秒間8000メッセージくらいらしい。 Q：ハートビートの取りこぼしは？ A：案1：UDPじゃなくて、TCPにする。案２：TCP接続してたらハートビートのカウントとしてしまう。 Q：CollectorのCPUに影響があるのってなに？ A：ロックがCPUを食う＝ロックが影響→リクエスト量を減らす Q：Windows対応はいつ？（発生源がWindows） A：td-agent-liteをWindows対応にしたいと思ってる。 Q：F#の実装とかテストは？ A：性能値の測定までは行ってない。メッセージが送れたなぁくらい。 Q：設定のDSL化はv11ではなくなったの？ A：ホスト名は入れたい。設定はやっぱり設定だけにしたい（プログラムは入れたくない） プラグイン側がDSL対応してればDSLできるようなものは入れようかと思ってるが、 DSLは延期したい。 A（tagomoris）：DSL化したいパターンが幾つかに絞れるなぁと思ってて、それに合わせたプラグインをいくつか作ってるよー。 ◎「Fluentd \u0026amp; Treasure Data でこっそり始めるログ集計」　CROOZ 株式会社　池田 朋大（ @mikeda ） ◯概要： FluentdとTreasureDataプラットフォームを使って、1インフラエンジニアが勢いでログ集計システムを作ってみたお話です ◯アクセスログ、エラーログ、メールログ（試験中）を集めてる。 ◯TreasureData 500Gまで無料なのかー。 ◯ダマで入れてもばれないぞ！ ◯最後は心の目で見えるスライドでした。 ◎祝・O\u0026#39;Reilly HBase 訳本発売。訳者本人によるPR。　Sky株式会社 玉川 竜司　※ O\u0026#39;Reillyの新刊「HBase 」　http://www.oreilly.co.jp/books/9784873115665/ ◎懇親会 そうそう、ステッカーもらったのでアンケート書きましたｗ ","date":1345657200,"dir":"post/2012/","id":"775894425f5a7436f56fc5a3b4a2cfaa","lang":"ja","lastmod":1345657200,"permalink":"https://blog.johtani.info/blog/2012/08/23/fluentd-meetup-in-japan--2--fluentd-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-08-23T02:40:00+09:00","summary":"興味をもちつつ、触っていない軟弱者ですが、興味があるので今回も話を聞きに行って来ました。 まずは、作者古橋さんによるFluentdの魅力や次期","tags":["勉強会"],"title":"Fluentd meetup in Japan #2 #fluentd に参加しました。(Jugemより移植)"},{"contents":"またまた飲みに行って参加してきました。 今回は、Rails、iOSでのTwitter連携の話から、ツイート分析、クライアントアプリの開発の苦労？楽しい話と、 幅広い話題でこれまた面白かったです。\nRailsはあとで、もう一回資料＋ビデオがみたいかも。あと、発表者の方が言ってたけど他の言語の似たようなサンプルがあると面白いかも。（Solr入門みたいに同じ題材で違う言語のサンプルとか）\nツイート分析は、私の使い方とは異なる分析結果がちょっと意外でした。土日はあんまりツイートしないからなぁ。 利用時間帯とかは、他のSNS（Facebookとかmixiとか）の分析と比較してみると面白いのかも。 まぁ、深夜帯はそれほど利用は無いだろうけど。\nAttaccaは自社や自宅でコーディングするときに利用させてもらってます。 どうしても自分のお気に入りのリストを作ってそれを聞くので満足しちゃうんで、 他の人のお気に入りも一緒にシャッフルして再生とかできると面白いかもなぁ。 もう少し、他にも曲を発見したいんだけど、その導線がもう少しうまく行くと嬉しいかも。\nチャーハン諸島の話は開発者の原点みたいな話で面白かった。やっぱり、自分で作るの大事だよなぁと。 作りたいと思うものがあるのはいいことだし、実際作ってみないとわからないこともいっぱいありますよねぇ。 ただ、何か作ろうかなぁと思うものがあるのはちょっとうらやましいとも思いました。 なかなかサービスとか、ほしいものを作ろうと思うところまで行かないからなぁ。年取ったのかなぁ。\n懇親会では、いつものように@twtrfkさんと喋って、あと Lytroを触らせてもらいました！ 思ったよりも大きいのが第一印象。 ぱっと見で、何の変哲もないところがズームするところだったりと、インタフェースがちょっとおもしろかったです。 ピントが後から合わせられるということで、どうしても同じ構図になっちゃうのがなぁという話も聞けましたｗ けど、ちょっと欲しいかもなぁ。動くものを撮るとどんな感じなのかも聞くんだった。\n次回は9月中旬！らしいので、余力がありそうだったらまた遊びに行きます。\n日時：2012/08/01 19:00 ～ 21:00 場所：デジタルハリウッド東京本校 1Fセミナールーム\nいつもの自己紹介タイム\n@i7a16k(@_gifteeの中の人)　スライドはこちら\n「RailsでTwitter連携アプリをサクっと作る」 ・まずは、Railsの紹介 MVC+routes.rbの紹介 ・Dev Twitterの登録する必要なとことか。 ・Railsのインストールから起動まで。 ・実際にログイン画面を作成するまでの紹介 コーディングするコマンドの紹介。動画付き omniauth_twitter ってのを使うみたい。 ・サインイン、サインアウトまで。 ツイートは次回！ 録画がよくできてて、それに合わせてしゃべるのもうまいなぁ。 @teapipin(ツイッター分析シリーズ の方)　スライドはこちら\n「約173万ツイートを調査して分かったTwitterの利用動向」 ・ハンドル名は午後の紅茶からきてる？＋ピピン＠ ・ブログで色々公開してます。 ・サービス作るのに、下調べをしてみましたというお話 情報が無かったから、自分で調べてみたよと。（すばらしい） ・Streaming APIで取得 タイムゾーンとか言語設定の取得でもうまく取れない。。。 ということで、UnicodeBlockで判定してみたけど、、、 最後は手作業で不要データを除去（すごい！） ・4日間で172万ツイート （金環日食とかスカイツリーのイベントがあったので、4日間で我慢） ・上位5個で50%を占めるクライアントみたい ・日曜日が多いらしい ・携帯が60%くらい ・位置情報（Geoタグつき） 日本が多い。4sqが40%占めてる。 店舗情報や天気情報などもあるらしい。 人口と関係した相関が散布図でわかった。 そこで、ツイート内容との関係を分析 あとで資料みたいなー @i2key(#attacca の関係者)　スライドはこちら\n「iOSのTwitterFrameworkを使ってみたら・・・・」 ・Twitter4Jのほうが楽だったよー デモがいいね！ ・アーキテクチャ play!をバックエンド。Amazonとか。 iOS Twitter framework ・Reverse Authの使い方とか。 申請してから、20日間かかった。 @Mocel(チャーハン諸島 開発者)　スライドはこちら\n「(仮)Twitter クライアントの開発とかについて」 ・趣味プログラマー ・「ラーメン大陸」のクローン：「チャーハン諸島」を開発 Excel溶けこむGUI Javaで実装 コマンドライン風のTL画面もある（自分では使ってないけど） 「電力会社の電力使用量モニター」もクライアント初搭載！ ラーメン大陸のバージョンチェックも可能ｗ ・開発したことで 自分のニーズにジャストフィット 優しい気持ちになれる（苦労がわかる） Twitter APIのテストとかもすぐ試せる ・GUIアプリ開発のノウハウも手に入るからオススメ ・API利用規約は読んどこうね ・自動アップデート機能がいるよ。→バージョンごとのサポートがなくなるよ。 ・通信エラー前提で作りましょう ・鍵付きの非公式RTはやめなさい。 ・Twitterクライアントの作成はおもしろいよ！ 反応がプレッシャーになることもあるけど。 おもしろ機能をつけるのがいいよーと 話が上手で聞きやすかった。 ","date":1343875800,"dir":"post/2012/","id":"8a29f62d1bebfe7b8008d7f264b56b4e","lang":"ja","lastmod":1343875800,"permalink":"https://blog.johtani.info/blog/2012/08/02/twitter-%E5%8B%89%E5%BC%B7%E4%BC%9A--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-08-02T11:50:00+09:00","summary":"またまた飲みに行って参加してきました。 今回は、Rails、iOSでのTwitter連携の話から、ツイート分析、クライアントアプリの開発の苦労","tags":["勉強会"],"title":"Twitter 勉強会 #twtr_hack に参加しました。(Jugemより移植)"},{"contents":"ということで、ステッカー欲しさ？に勉強中の話を恥ずかしげもなく偉そうにしゃべってきました。 #pyfesは以前から、気になっていたんですが、タイミングがあわず初の参加になりました。 TwitterのプロフィールにSenseiDBに興味あると書いていたら、@voluntusさんに声をかけていただけて、 さらになぜかelasticsearchの話をすることにして話をしてきました。 まだまだ、いろんな意味（プレゼン的にも内容的にも）で至らない所だらけだったので反省しまくりですが、 これでまた経験値が稼げたかなと。次回に活かしたいと思いますです。 やっぱり、しっかり勉強して、シナリオを練ってから発表しないとダメですね。。。\n発表のスライドは一番最後にリンクを用意しておきましたので、興味があれば見てもらえればと思います。\nということで、いつものメモを残しておきます。\n日時：日本オラクル青山センター 場所：2012/07/28 10:00 - 20:00 概要：こちらにページあり\n前半（10時から15時）はハンズオンなどをやられてました。参加せずにスライドを微調整して、他の勉強会のスライドをいじったりしてました。 以下は、15時から行われたスライドのメモになります。\n◯PyConJP の宣伝　@shomah4a（LT） 9/15-17 PythonカンファレンスJapan App Engine、Django、Sphinxなどのカンファレンスも併設 遠方参加者支援制度があるらしい。 ◯elasticsearch 入門　@johtani わかりにくい話でしたかねぇ。。。 ◯たのしいうぇっぶくろーら　@tokoroten（LT） index.htmlをクロールしまくってる社畜2.0の人らしい。 ◯Sphinxを使って翻訳してたら本が出てた話　@ymotongpoo（LT） OSSでもドキュメント翻訳でお手伝いできるよ。 そしたら、いつのまにか書籍も出せたよ。 スライド\n◯iOS関連のお話　@Seasons バイナリ解析をしてゴニョゴニョする話。 解析するのに何を使ったとか思考の遷移を説明してくれるのでわかりやすい。 スライドが大きなマインドマップを切り出した形。 ◯HBaseのお話　@shiumachi HBase 分散DB 列ファミリ思考 HBaseなんで？ RDB→シャーディング→だるい。。。 シャーディング→スケールできねー nandeHBase？ 書き込みスケールできるよ。 KVS HBaseのデータ構造 キーがいろいろな情報を含んでる キーがソートされてる HBaseのテーブル構造 リージョンがシャーディングの情報もと？ リージョン見つけなど スライド\n◯PythonではじめるGit　@mkouhei GitPython LXCホスト？ GitもPythonも初心者だわー ◯勉強会を成長させる参加者になろう　@sawonya イラストレーター（スタートアップRubyのイラスト書いた人。サインもらいましたｗ）。 参加者が増えるとなにがいいの？など。 勉強会参加に向けた勉強会の講師とかやられてるらしい。 スライド\n◯IT 系勉強会ネタ(仮)　@tmmkr アジャイルサムライを読んだ情報を共有したくなって読書会を開催してみた！ ビアバッシュのケータリングとかは楽天デリバリーとか、カクヤスがいいよ。 かなり、いいスライドなので、あとで見返す。 今、読書会やったりしてるし、Solr勉強会の役にも立てそうだし。 スライド\n◯Do not invent your RNG...　@kenji_rikitake Androidの乱数のコードがすごいらしい（ひどい） Pythonの乱数ではos.urandomを使うのが安全です。 オレオレ乱数は作っちゃ駄目！ ◯分散ファイルシステム（LeoFS）　@yosukehara LeoFSの開発者の方。 Erlangで98%書いてある。 Masterノードは存在しない。SPOFになるから。 分散システムとして元にした概念とか論文ってあるんだろうか？ ◯継続的デリバリー　@troter CIとデリバリーの話。 いいこと書いてあるんだけど、実際のツールの話しがないのが辛いこともある ということで、Python周りのツールをこうして見たよというお話。 Rubyの方がものがいろいろ揃ってるらしい ◯クライアントサイドのみで作ったダッシュボード　@takufukushima RESTアクセス用のUIのフロントエンドの話？ JSのお話の？node.jsとかの話。 MVCにしたり、CSSフレームワーク使ったり。 backbone.jsつかってるらしい。 実際の画面がみたいなぁ。 現状の話なので、 ◯Meinheld　@mopemope Python3対応とかLoggerとかやってから秋くらいに出るみたい。 このあたりは未知の領域です。。。 ◯3分間で開発環境構築 @tk0miya Vagrant＋Chefみたい。 VeeWeeってのでIOSイメージからVMイメージを作ってくれる。 （githubから持ってこないといろいろ古いらしい） これ、重要だと思う。 実践するようにしよう。 手順書がわりにChefのレシピを書こうよと。 環境マニア募集中！ 継続的デリバリー座談会やってます ◯筋トレ講座　@hiroki_niinuma ジムに通い続けるのはキツイ。 成功率5% 以下の条件に ・10時間以下の仕事時間 ・ジムが近い ・ジムという環境が好き ベンチマークｗ先入観を捨てましょうとｗ ジムで筋トレとかよりも歩くのが全然いいよと。 togetterがあったのでリンク。 http://togetter.com/li/346242 http://togetter.com/li/346270\nスライドはこちら。\n** [Elasticsearch入門 pyfes 201207](http://www.slideshare.net/JunOhtani/elasticsearch-pyfes-201207) ** from **[Jun Ohtani](http://www.slideshare.net/JunOhtani)** それにしても発表するといういい機会を与えてもらえて良かったです！。 継続的にelasticsearchも調べていきたいので、興味ある人は声をかけてくださいー\n","date":1343466900,"dir":"post/2012/","id":"7fa2f0877831b4c924438396760f1841","lang":"ja","lastmod":1343466900,"permalink":"https://blog.johtani.info/blog/2012/07/28/python-developers-festa-2012-07%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%97%E3%82%83%E3%81%B9%E3%81%A3%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pyfes/","publishdate":"2012-07-28T18:15:00+09:00","summary":"ということで、ステッカー欲しさ？に勉強中の話を恥ずかしげもなく偉そうにしゃべってきました。 #pyfesは以前から、気になっていたんですが、タ","tags":["勉強会"],"title":"Python Developers Festa 2012.07に参加してしゃべってきました #pyfes(Jugemより移植)"},{"contents":"今日はSolr 4.0 ALPHAの興味深い機能があったので紹介です。 数日前に「Solr 4.0: Partial documents update」という記事を見つけました。\nSolrには、ドキュメント（RDBで言うレコード）のデータを更新したい場合には、特定のフィールドだけを更新するという機能がありませんでした。 ですので、特定の項目（例えば、priceなど）を更新したい場合、ドキュメントの全データをSolrに再度上書き登録するという処理をしなければなりませんでした。 RDBを触っていた方が、Solrを始めた場合に必ず使いづらいと思われる点だと思います。\nで、4.0でその機能がありますという、「Solr 4.0: Partial documents update」の記事を見つけました。 ただ、SolrのWikiや4.0 ALPHAの紹介のページには「partial update」という記述が見当たりません。 （あれ、これかな？Update semantics） あと、まだ完成していないので、載っていないのかもしれないです。（このチケットSOLR-139が部分更新に関するもののはず。チケット番号をみても古くから望まれている機能だということがわかります。）\nということで、調べてみました。\n###機能概要\nSolrの機能として、特定のフィールドのみを更新するという機能です。 あくまでも、Solrレベルでの機能となり、Luceneの機能を利用したものではありません。 つぎのような流れになっています。\nSolrに対して特定フィールドを更新したいという形のドキュメントを投げる Solrはドキュメントを受け取ると、内部のインデックスに保存してあるデータを取り出す 取り出したドキュメントオブジェクトに対して、更新対象フィールドの値だけデータを更新する ドキュメントオブジェクトをインデックスに保存する このような流れです。 まぁ、言われてみれば当たり前な処理です。 ただし、この機能を使う場合はいくつかの前提条件があります。\n###前提条件\n前提条件はつぎのとおりです。\nすべてのフィールドをstored=\u0026ldquo;true\u0026quot;にする 「version」という特殊なフィールドを用意する 1点目は、データの保存方法についてです。 先ほど流れに書きましたが、Solrが内部に保存してあるデータを取り出して、更新対象以外のデータを保存しなおしてくれます。 このため、stored=\u0026ldquo;true\u0026quot;にしておかないと、元のデータがSolr内部で取得できません。\n2点目の「version」というフィールドは4.0から導入されたフィールドです。 SolrCloudに必要な機能としてドキュメントのバージョン管理を行うために導入されたフィールドだと思います。（あまり詳しく調べていない。。。） SolrCloud内でレプリカの更新などに使ってるのかなぁと（そのうち調べます。） 以上の2点が前提条件です。すべてのデータをstored=\u0026ldquo;true\u0026quot;としなければならない点は、インデックスのサイズや性能に関わってくるので考えて利用するほうがいいかと思います。\n###利用方法\nSolrのサンプルデータ（exampledocs/mem.xml）を例として利用します。 部分更新を行うにはつぎのような形のデータを投げると部分更新が可能です。 （JSONでの更新のサンプルについては、こちらの記事を参考にしてください。） ####XMLのサンプル（partial_update.xmlというファイルで保存する）\n\u0026lt;add\u0026amp;gt; \u0026lt;doc\u0026amp;gt; \u0026lt;field name=\u0026#34;id\u0026#34;\u0026amp;gt;VS1GB400C3\u0026lt;/field\u0026amp;gt; \u0026lt;field name=\u0026#34;_version_\u0026#34;\u0026amp;gt;バージョン番号\u0026lt;/field\u0026amp;gt; \u0026lt;field name=\u0026#34;cat\u0026#34; update=\u0026#34;add\u0026#34;\u0026amp;gt;cats_and_dogs\u0026lt;/field\u0026amp;gt; \u0026lt;field name=\u0026#34;popularity\u0026#34; update=\u0026#34;inc\u0026#34;\u0026amp;gt;10\u0026lt;/field\u0026amp;gt; \u0026lt;!-- set empty for SOLR-3502 bug --\u0026amp;gt; \u0026lt;field name=\u0026#34;price_c\u0026#34; update=\u0026#34;set\u0026#34;\u0026amp;gt;0.0,USD\u0026lt;/field\u0026amp;gt; \u0026lt;/doc\u0026amp;gt; \u0026lt;/add\u0026amp;gt; 上記サンプルのうち、バージョン番号の部分は、現在Solrに登録してある値を指定します。（Solrの管理画面で検索すれば表示されます。） 上記ファイルを「SOLR_HOME/example/exampledocs」に保存し、同フォルダにてつぎのコマンドを実行すると、部分更新されるのがわかります。 Solrに更新であるというフィールドがわかるように、fieldタグにupdateという属性を指定してあります。\njava -Durl=http://localhost:8983/solr/update?versions=on -Dout=yes -jar post.jar partial_update.xml ちなみに、上記post.jarのオプションで、「-Durl」「-Dout」を追加してあります。 「-Durl」はverions=onというパラメータを追加したいためです。 「-Dout」はPOSTした結果をターミナルに表示するために追加しています。 これらのオプションを指定すると、データ更新後のバージョンが取得できるようになります。\n####更新に利用できるコマンド？ 部分更新にはつぎの3つのコマンド？（正式名は不明）が用意されています。fieldタグのupdate属性に指定します。\nコマンド？ 説明 add 値を追加します。multiValuedのフィールドでない場合はエラーが出ます。 set 値を新規に登録しなおします。現在入っているデータは無くなります inc 指定された数値を加算（数値形式のみ） 以上が、部分更新の機能になります。 ちなみに、登録されているバージョンと更新データに入っているバージョンが異なる場合はエラーが発生する仕組みになっているようです。 それとは別に、この機能を調べていて、copyFieldのバグにぶつかってしまいました。。。 multiValuedでない、copyFieldを利用しているしている場合には注意が必要です。\n###copyFieldのバグ（SOLR-3502）\n4.0-ALPHA（3.6.0でも再現しました。）のexampleのデータで部分更新の機能を確認できると言いました。 ただし、「price_c」というフィールドのせいで、2回部分更新を行うと2回目にエラーが発生します。 根本的な問題は、部分更新ではなくcopyFieldのバグのようです。（部分更新の処理にも問題は有るような気がしますが。。。）\nバグの内容はつぎのとおりです。\nmultiValued=\u0026ldquo;false\u0026quot;のフィールドをdestに指定 srcに指定されたフィールドに値を設定（exampleのpriceフィールドに「1」を指定） destに指定されたフィールドに値を設定（exampleのprice_cフィールドに「2,USD」を指定） 上記のように設定した場合、「price_c」フィールドに、指定された値＋「price」の値がcopyにより追加されます。 通常は「price_c」フィールドはmultiValued=\u0026ldquo;false\u0026quot;なのでエラーが出るはずなのですが、エラーが発生せず2つの値が登録されてしまいます。\nこのバグのため、exampleのデータを利用して部分更新を行うとつぎのような状態が発生します。 更新を行う対象のデータはprice、price_cフィールド以外のフィールドとします。\n1回目の登録後：priceフィールド「\u0026ldquo;185.0\u0026rdquo;」、price_cフィールド「\u0026ldquo;185.0,USD\u0026rdquo;」 2回目の登録後：priceフィールド「\u0026ldquo;185.0\u0026rdquo;」、price_cフィールド「[\u0026ldquo;185.0,USD\u0026rdquo;,\u0026ldquo;185.0,USD\u0026rdquo;]」 3回目の登録：エラーが発生 部分更新の処理で、すでに登録済みのデータをSolrが自動で取り出すため、2回目の登録処理にて「price_c」の登録済みの値がSolrから取り出され、さらにcopyField設定により、「price」の値が追加されます。 本当は2回目の登録でエラーが発生すべきなのですが、バグのためエラーが発生せずに登録できてしまいます。 部分更新の処理としては、copyフィールドのdestに指定されているフィールドの値を取り出さないほうがいいような気もしますが、きちんと考えてないのでなんとも言えないです。（制約事項とする形のほうがいいかもしれません）\n","date":1342177320,"dir":"post/2012/","id":"68a8f34c240a42ab521d2f885f7aa33c","lang":"ja","lastmod":1342177320,"permalink":"https://blog.johtani.info/blog/2012/07/13/partial-update%E3%81%A8copyfield%E3%81%AE%E3%83%90%E3%82%B0solr-4-0-alpha/","publishdate":"2012-07-13T20:02:00+09:00","summary":"今日はSolr 4.0 ALPHAの興味深い機能があったので紹介です。 数日前に「Solr 4.0: Partial documents update」という記事を見つけました。 Solrには、","tags":["solr"],"title":"Partial UpdateとcopyFieldのバグ【Solr 4.0 ALPHA】(Jugemより移植)"},{"contents":" Modern Information Retrieval: The Concepts and Technology behind Search (2nd Edition) (ACM Press Books) いやぁ、蒸し暑くてなかなか寝れない日がはじまりましたね。（あんまり関係ないですね。。。）\nModern Information Retrieval 2nd Editionを輪読会という形で読み始めました。 Solrに関わって数年ですが、昔から検索をやっていたわけではありません。 なので、そろそろ基礎的、理論的なところも勉強して行かないとなと思い、この本を買いました。 ただ、約1000ページある英語の本でして。。。 一人で読むと間違いなく挫折するし、理解不能になりそうだなと。。。\nということで、Twitterで呟いたら賛同してくれる方が現れ、輪読会を開催することにしました。 イベントの開催とか初めてなので、手さぐりしながらです。（それにしても、ほんと、Twitterは素晴らしい。賛同してもらえる人が見つかったのもTwitterのおかげだし。）\nさすがに細かく読んでいくと終わらなそうなので、１周目（できれば、２周目もやりたいなぁと思ってる。１週目が１年でも終わりそうにない感じだけど）は公開されているスライドを元に進めようと思ってます。 それにしても検索周りはいろんな技術が必要なのだなぁと分厚い書籍を見て、途方に暮れつつ、楽しみでもあるなと思いながら、輪読会後の飲みを楽しんでましたｗ\nということで、各分野の専門家もいそうなので、特別ゲストとして読んできて話に混ざってもらうのも面白いかもと夢想しつつブログを書いています。 だれかいないかなーｗ\n参考URL： 書籍のHPで公開されているスライドのページです。 http://grupoweb.upf.es/WRG/mir2ed/contents.php\n","date":1342111298,"dir":"post/2012/","id":"9ac7bb94e60dc30a023ce433de027364","lang":"ja","lastmod":1342111298,"permalink":"https://blog.johtani.info/blog/2012/07/13/mir%E8%BC%AA%E8%AA%AD%E4%BC%9A%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-07-13T01:41:38+09:00","summary":"Modern Information Retrieval: The Concepts and Technology behind Search (2nd Edition) (ACM Press Books) いやぁ、蒸し暑くてなかなか寝れない日がはじまりましたね。（あんまり関係ないですね。。。） Modern Information Retrieval 2nd Editionを","tags":["勉強会"],"title":"MIR輪読会始めました(Jugemより移植)"},{"contents":"Lucene/Solrの4.0.0-ALPHAが7/3にリリースされました。\nこれに伴い、lucene-goenの4xブランチのjarファイルも4.0-ALPHAのものに置き換え、現在のtrunkの修正もマージしました。 こちらにあります。チェックアウトしてビルドしてから利用してください。\n※さすがに、jarをダウンロードできるようにすべきかもなぁ。 あと、Maven登録も。。。\n","date":1341457909,"dir":"post/2012/","id":"dcc2e24df32287e89ee3b0f64d617f57","lang":"ja","lastmod":1341457909,"permalink":"https://blog.johtani.info/blog/2012/07/05/lucene-gosen%E3%81%AElucene-solr4-0-alpha%E5%AF%BE%E5%BF%9C/","publishdate":"2012-07-05T12:11:49+09:00","summary":"Lucene/Solrの4.0.0-ALPHAが7/3にリリースされました。 これに伴い、lucene-goenの4xブランチのjarファイル","tags":["lucene-gosen"],"title":"lucene-gosenのLucene/Solr4.0-ALPHA対応(Jugemより移植)"},{"contents":"またまた参加しました。いまだ皆勤賞です。 感想などはあとで。とりあえず、メモとったので第一弾です。\nということで、感想です。 まずは、参加人数。 今回は今までで一番、ATND登録した人が多かったんじゃないかなぁと。 埋まるのも早かったですし。やっとSolrというキーワードが多くの方に触れられるようになってきたんですかねぇ。\nmixiの事例はやはり、SSDを使った11億文書のインデックスが圧巻です。 実際にマイニングに利用していて、ネガポジ分析なども行われているようで楽しそう。 TLにもありましたが、「ヤバイ」はネガ？ポジ？など、そのへんの分析方法をもう少し詳しく聞いてみたい感じもしました。 あとは、Luceneソースコードリーディングの開催が楽しみです！（候補日知らせないと。。。）\nLucene Revolution 2012の参加レポートは、自己紹介がおもしろかったですｗ ずっと検索をやらてているのもあり、色々と理論ではなく、実践的なノウハウを持っていそうで、つぎはそのあたりの話を聞いてみるのも面白そうです（発表してくれないかなーｗ） 残念ながら、私はまだスライドを見ていないので、事例を中心にピックアップして見てみようかなぁと（時間がトレない。。。）\n最後は阿部さんの4.0の紹介です。タイムリーに、前日に4.0-ALPHAがリリースされたので、 資料がすごく参考になりそうです。 SolrCloudについても詳しく書かれてたし。（ちゃんと動くのかなぁ？）\n最後は懇親会です。最近知り合った方から、発表者、昔からの勉強会の参加者といろいろな方と今回も話ができて楽しかったです。 TL上で知り合った方にもお会いできたし。 次回もしゃべってもらえそうな人を捕まえつつあるので、また企画してもらうようにつついてみようかな。\n※そういえば、毎度のことながら4.0ベースで、書籍は出さないのかって言われましたｗ\n※ちなみに、4.0-ALPHAが出たので、lucene-gosenも4xブランチの更新作業をしています。 終わったらまたブログに書くと思います。\n第8回Solr勉強会 場所：VOYAGE GROUP 会議室 日時：7/4(水)　19:00 ～ 1. ＠haruyamaさん mixi での Solr の利用 ・mixiの全文検索 2011年以前：Hyper Etraier、Tokyo Dystopia、Senna 2011年以降：Solrを利用して新規案件の検索システムの構築、入れ替えを行なっている。 ・Anuenueの論理構成など。 ・物理構成 1マスター、2スレーブ インデックスが小さい、QPSが100以下 インデックスサイズが大きいものは今後構築予定 ・今後やりたいこと ・ログ分析 ・パーソナライズ ・外部ストレージ参照のカスタム関数 ・外部ストレージをファンクションカスタム関数クエリ FunctionQueryを活用したい。 ・上記のデモ（検討中のもの？） 現在はjar内部のファイルを読んでるよと。 速度的な面がどうなるかがきになるところ。 ・テキストマイニング mixiボイス haruyamaさん入社前：ダンプして解析してた haruyamaさん入社後：Solrに載せちゃえば 600GのSSD　約11億文書 約450GB 利用してるもの：Solr 4.0（2012/01） lucene-gosen 1.2.1 自作フィルタ haruyama/solr-filter - GitHub ・利用統計の説明。 女性が多い。 「AKB」だと20代前半が多い。男性はおっさんも頑張ってる。 ・mergeindex機能を利用して、過去データとマージしてる。 1日分だけ集計したいこともあるかもしれないから。 updateじゃなくて、mergeindexなのは、ソッチのほうが早かったから。 ・拡張してる分析 ・ポジネガ分析 形容詞＞絵文字＞顔文字でスコアが効く 機械学習して辞書を調整してる ・Luceneソースコードリーディングまたやりますよ！ 2. 楽天株式会社 大須賀 稔さん Lucene Revolution 2012 in Boston参加レポート(仮) ・まずは自己紹介。 infoseekに転職→楽天→Ask.com→楽天（そして英語） ・Lucene Revolutionってなに？ ・トレーニング Scaling Search with Big Data \u0026amp; Solr Hadoopの紹介 SolrとHadoopのMapReduceを利用したインデキシングのハンズオン Solrのスケーリング（Sharding、Replication）、マルチテナント ※http://www.lucidimagination.com/services/training/big-data-training-scaling-solr 日本ではやってない、残念。 ・カンファレンス スライドとかはlucidimaginationのサイトで見れるよと。 http://www.lucidimagination.com/devzone/events/conferences/lucene-revolution-2012 ・Lucidworks Big Dataの紹介 Hadoopとかいろいろ組み合わせて使えるよと ・Microsoftの人がAzureでSolrの紹介 IEとかWindows8の話ばっかり。 ・Kuromojiの紹介 やはり、マイノリティ。 内容は日本語勉強会ｗ 中国語とかは対応するの？日本語しか知らないです。。。 ・ErickさんのSolrCloudの話 4.0は2012年にリリースする予定 スコアリングをプラガブルに。 管理系画面がリッチだよと。 ・一番重要だなぁと思ったのは。。。 「英語」！（会社的な感想ではありません。。。） Q：これはみとけ的なスライドは？ A：Hadoop上でインデキシングして、ビットトレントとかで連携してるという例が面白かった。 Q：FASTとかと比べてSolrってどーなの？ A：ESPは洗練されてる。クローラーとか、ベイシスのトークナイザーを内包してるとか。 Solrは言語処理系が弱かったとかあるけど、そろってきてるのでは。 4.0は互角になるんじゃないかなぁ。 ESPがWindowsオンリーになるので、LinuxユーザがSolrに行きつつある。 3. 株式会社 ロンウイット　阿部さん Solr 4.0の紹介 ・Solr 4.0の主な機能の紹介 3.xは3.6が最後4.0-ALPHAが7/3に出た ・プラガブルなスコアリング BM25、Language Models、Divergence from Randomness、Information-based Models 関口さんがスライド作ってる ・FST対応 Finite State Automata/Transducer オートマトン理論を活用したもの。 TokenStreamはFSAで実装 SynonymFilterがFSTになると、オフセットが変わってくるらしいと。 ・Codecプラグイン Luceneレベルのお話。 ドキュメントをファイルに保存するときの形式をプラガブルに変更可能。 SimpleTextなどもあるらしい。テストに利用できそう。 APIレベルで、マイグレーションの必要があるかも。 ・NRT Near Real Time Search softCommitのお話 Realtime-get：IDを入れたらGETできるよと。 KVSとしても活用できるぞ～と。 ・PivotFacet Facetが階層的（？）な感じで取れる ・JOIN、pseudo-join ローカルパラメータでできるよーと。 ・SolrCloud インデックスの分散配置をやってくれる（3.6まではやってくれない） shardがダウンしたらフェイルオーバーしてくれそう Master/Slave環境 リアルタイムインデクシングとリアルタイム検索とか ・ZooKeeperIntegration実装 リーダー選出、コンフィグの管理などなど ・ManifoldCFの近況 5月にトップレベルに昇格！ http://manifoldcf.apache.org/ja_JP/index.html 0.6は7月に出そう。日本語にもなってる。すげー Alfresco Connector、ElasticSearch Connectorなども Solr Plugin for Enterprise Searchとか ","date":1341402000,"dir":"post/2012/","id":"8acc78be63e27e938ee53ec2c0b90c61","lang":"ja","lastmod":1341402000,"permalink":"https://blog.johtani.info/blog/2012/07/04/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--solrjp/","publishdate":"2012-07-04T20:40:00+09:00","summary":"またまた参加しました。いまだ皆勤賞です。 感想などはあとで。とりあえず、メモとったので第一弾です。 ということで、感想です。 まずは、参加人数。 今","tags":["勉強会"],"title":"Solr勉強会第8回に参加しました。 #SolrJP(Jugemより移植)"},{"contents":"Hadoopからはちょっと離れているのに、面白そうなネタなので参加しました。 Data Science Summit、HBaseCon、Hadoop Summitのイベント参加レポートです。\n最初の草薙さんの発表が実は一番興味を惹かれていたので、参加しました。 データの解析に関するサミットというのはなかなか聞いたことが無いのでどんな内容なのかなぁと。 ちょうどVisualizeなどに興味を持っていたり、データ解析、今後重要ですよねという話が出ていたりしていたので。 実際にデータ解析が今後重要で、どんなことに使えるのかなど、製品に偏らない内容のようで色々とためになりました。 この内容をずっと聞くのは私には無理ですw英語も数学もイマイチなので、ついていけない自信がありますｗ。 「データ分析の結果をビジネスに結び付けられる人とかが今後重要になります」という話が一番気になったキーワードでした。\nHBaseConもかなり濃い内容だったようです。 私は残念ながら、HBaseの概要の概要くらいしか知らないので、内容にはついていけてないですが。。。 Facebookがかなり活用しているようですが、残念ながらスライドが上がっていないようです。 Solrに関連する話もあったようです。HBaseとSolrを組み合わせたLilyプロジェクトに関連する話のようでした。 スライドは登録しないと見れないみたいです。\n最後はHadoop Summitの参加レポートです。 まずは、ユーザ寄りの内容を@muddydixonさんから。個人的に、Twitterの話が多いのかなぁと。 ここでも、Visualizeの話が出ていたとか。 Lucidの話もあったようです。LucidWorks BigDataの話かな？\n最後は@shiumachiさんのHadoopのプロダクト寄りのお話。 YARN（Map/Reduce2.0？）やHBaseの今後の展望など。YARNはキーワードだけ知っていたので、わかりやすい解説で、やっと理解できました。 全体を通して、HBaseが今後もっといろんな局面で使われそうだなぁと。日本語の本も7/24に出るし。（まだページが無いみたいなので、英語のほうを。）\nいつものごとく、途中でビールが入ったので後半はメモが適当ですが、楽しかったです。皆さんお疲れ様でした。\n帰り着いたら、さっそくスライドが上がってました。すごい！ スライドはこちら（2012/06/26 0時現在）\nData Science Summit / EMC Worldレポート HBaseCon 2012 参加レポート』の発表スライドをアップしました。（NTTデータ 猿田 @raspberry1123 ／岩崎） @muddydixonさんのHadoopSummit2012参加レポート @shiumachiさんのHadoopSummit2012参加レポート @muddydixonさんのブログ いろんなキーワード、特に、データサイエンス寄りの話が面白かったです。 次回はJenkins関連のようで、7/30開催みたいです。\n以下はいつものメモです。\n日　時： 2012年6月25日（月） 19:00～21:00 （受付開始 18:40） 場　所： 豊洲センタービルアネックス（NTTデータ、豊洲駅直通） ◯ Data Science Summit / EMC World レポート （EMC Japan 草薙） ・Data Science Summitのレポート 揃ってるようで揃ってないスロットの写真ｗ EMC World2012と併設 今回2回目。 ・OpeningKeynote: What We Can Predict About Prediction by Nate Silver 研究者は不確実性やリスクを包含した、現実的な予測モデルを開発すべき いろいろ ・Roundtable: Economic, Political, \u0026amp; Societal Roles of Social Data ユーザの「query-like intent」を自然言語解析と機械学習で捉える 属性だけじゃなく、活動を コンテンツからコンテキストへ、コンバージョンからカンバセーション ・Big Data Transformation - HealthMap ウィルスのアウトブレイクの検知（160日→20日）に。 ウィルス＝コンピュータじゃない方 ・Big Data Transformation - Intuit int.com？ データがあるから、こういうことが知りたいなどの新しいプロセスが 「https://www.mint.com/」 ・Big Data Transformation - InfoMotion Sports Technologies バスケのボールにセンサーつけて、試合や選手の解析に利用して、 チームが強くなったりしてるらしい。 ・Big Data Transformation - Decide.com アメリカ？の価格比較サイト ソーシャルデータを元に、買い時、売り時を予測して教えてくれる。 もうすぐ新しいモデル出るかもよ？などの噂を利用してる。 ・Analytics Maturity: Master or Novice? 2010年のアメリカの教育事情のレポート データサイエンス系の統計とかがもっと必要なんじゃないか。 ・Keynote: Navigating the Road from Business Intelligence to Data science Piyanka Jain BIの限界とか、データサイエンスの恩恵を受け入れるのに必要なもの？など システムじゃなくて、人やスキルに投資しましょう。 データ分析の結果をビジネスに結び付けられる人とか。 Panel: From Raw Data とValue Data プライバシー問題 データ品質の問題 異常値を除外するなと。最も興味深いデータになることもある。 \u0026#34;Data exhaust\u0026#34;の問題 個人が日々インターネット上で行う様々なインタラクションに関するデータの集合 相関と因果関係の区別が大変難しい。 Panel: Tapping Into the Pulse of the Data Science movement ストーリを持ってデータを語れるのが重要。 Keynote: Data Visualizeation at the Point of Influence by Adam Bly Closing Keynote: The Promise and Peril in the Human / Technology Relationship by Jonathan Harris TEDで有名な人 まとめ アメリカはこの分野での投資は回り始めている. http://www.greenplum.com/datasciencesummit/ ◯ HBaseCon レポート （NTTデータ 猿田／岩崎） ・GeneralSession HBaseの開発に参加してね。 ・レプリケーション、セキュリティ、セカンダリインデックス、スナップショット、バックアップなど特に貢献して欲しいと。 ・HBaseによりカバーできるアプリケーション領域 メッセージング、位置ベースアプリケーション、リアルタイムレコメンデーション、広告最適化 ・開発者への要望 メッセージをちゃんとして 解析用メトリクス 管理ツール ・M/Rジョブとの連携の改善 ・自動チューニングなど ・Applications ・GAPの事例 色々試してHBaseにした。 クラスタ構成、16Slave、3Master、NN Failover via NFS ※ZKはスレーブに置くと、アウト。 ・Tumblr 最初は失敗した。 OpenTSDBを経験して、Motherboy V1に。 テストフェーズまでが目的 →幾つかの知見が得られたよーと。 Motherboy V2を構築中。 ・Facebook ひと月250TBペースで増加中。。。 なんで、HBaseにしたの？ 低レイテンシ、水平スケール、一貫性重視の設計、M/Rとの親和性とか Schema V1＝Snapshot Schema Schema V2＝Split Snapshot Schema Schema V3＝Hybrid Schema HBaseのデータにさらにインデックス作ったりとか。 Schema Vertion Current＝Finer grained schema and Indexer 読み書きの単位を分析して、スキーマを分割して細かくして行っていた。 ・Operations ・HBaseで困ったよ at Facebook ・リージョンサーバに特定データ入れると連鎖的に死亡 ・サーバが死に切らないとか。 ・HBaseは落ちるときは落ちるので、しぶとく生き残れるアプリを作ってねと。 ※Facebook関連のスライドなどがあがってませんと。 ・HBaseバックアップについて Clouderaの人とFacebookの人 ・選択肢 DistCP /hbaseディレクトリまるごとコピー。一貫性が保証されない exportツール MRジョブ。1度に1つのテーブルのみ copytableツール データを別クラスタに保存 exportツールに似てる。 レプリケーション 。。。 アプリケーションから複数クラスタへの書き込み 。。。 ・ユースケース ・HBASE-5509を利用したバックアップ ・開発中バックアップ HBASE-6055スナップショット、HBASE-4618など ・Development ・HBase Schema Design　Salesforce.comの人 非正規化でやりなさいと。Joinはおすすめしないと 最後にデザインパターンが載ってると。 0.行キーの設計がすべて 1.Design for the questions, not the answers. 2.データサイズは2種類しかない。大きすぎるか、そうじゃないか。 3.コンパクトに詰め込め 4.行単位の原子性を活用する。 5.属性は行キー内に移動することができる。（Lars Georgeがfoldingと読んでいる手法） 6.エンティティをネストさせると、データを事前に集計できる。 ・HBase Performance Tuning And Organizations　Facebookの中の人 テーブルの事前スプリット オフピーク時間を設定する。（0.94で入った） コンパクション設定が効いてくるよ ・SolrのバックエンドにHBase？？？ ◯ Hadoop Summit レポート (@muddydixonさん) ・オープニングビデオは必見 ・ショーケース ・Datameerを注目した。Visualizationの専任チームがいる。 UIじゃなくて、解析部隊だけで60名 お値打価格。$2900/年 ・Azure Big Data JavaScriptで ・ショーケースLucid Solr、HBaseとかいろいろ組み合わせて。 ・Session Hadoop... 2015までにApache Hadoopに世界のデータの半分が乗るらしいと。 ・Session Realtime analytics with Storm and Hadoop フォロワのフォロワをunique処理したり。 ・Session Scalding Twitter\u0026#39;s new DSL for Hadoop ※Zipkinにも出てきたな、名前。 ・Hadoop Plugin for MongoDB ・Hadoop and Vertica The Data Analytics Platform at Twitter Twitter社でのHadoop周りのデータフローとか。 Verticaは速度がいるものの処理に利用 80-100TB/dayとか。。。 ・Keynotes ・Big data analyzing system is censor of company. ・It is difficult in blind and deaf. ・Session Large Scale Search, Discovery and Analytics with Hadoop, Mahout and Solr ※@muddydixonさんのブログにセッションに対応するスライドのリンクを公開中。http://d.hatena.ne.jp/muddydixon/20120617/1339919125 ◯Hadoop Summit レポート (@shiumachiさん) ・Hadoop1.x MapReduce 非常に安定 ・課題。。。 ・YARN（Yet Another Resource Negociator） ターゲット：6000～10000ノード 100,000以上のタスクの同時実行 10,000ジョブの同時実行 性能は倍以上 Q：これは同じプログラムを動かして？ A：。。。倍以上です！（わかんないっす。） 今後の予定 幾つかのJIRAの紹介 MAPREDUCE-4327とかHBASE-4329とか まとめ YARNは「汎用」分散処理基盤に向けて一歩踏み出したもの！ 更なる進化に注目と ・HBaseの可用性とリペア ダウンタイムを短くしよう。 障害停止7割くらい。 設定ミスが44% 不安定な機能は使うな、推奨構成を推奨！ HBase 0.92＋Hadoop 2.0 HDFS HAによる高可用性とか 将来：HBase 0.96＋Hadoop 2.x 計画停止時間削減：オンラインスキーマ変更（HBASE-1730） ローリングアップデート：バージョン間互換性が必須 HBase本読みなさい。 金があれば、サポート買ってください。 日本語HBaseトレーニング開催予定（来月） ・HBase NameNode HighAvailability ```　","date":1340642460,"dir":"post/2012/","id":"9f29c6d9719fc6bc09a2981057642b69","lang":"ja","lastmod":1340642460,"permalink":"https://blog.johtani.info/blog/2012/06/26/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC10%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/","publishdate":"2012-06-26T01:41:00+09:00","summary":"Hadoopからはちょっと離れているのに、面白そうなネタなので参加しました。 Data Science Summit、HBaseCon、Hadoop Summitのイ","title":"Hadoopソースコードリーディング第10回に参加しました。#hadoopreading(Jugemより移植)"},{"contents":"Issue 32で上がってきたlucee-gosenのUniDic対応の最初のパッチを書いたので、ブログに残しておきます。\n###UniDicとは___ UniDicとは、日本語テキストを単語に分割し，形態論情報を付与するための電子化辞書です。 UniDicの詳細や特長についてはHPを御覧ください。\n残念ながら、UniDicは利用者登録をして、利用規約に従うと利用が可能となります。 ですので、lucene-gosenでは、Ipadicやnaist-chasenの辞書とは異なり自動で辞書をダウンロードする機能はありません。\n###利用手順___ 以下が、Unidicの辞書を利用したjarファイルの作成方法となります。\n1. lucene-gosenをダウンロードし、パッチを当てる lucene-gosenのリポジトリからソースをエクスポートし、パッチをダウンロードし、パッチを適用します。 コマンドは以下のとおりです。\nsvn co . lucene-gosen-trunk-readonly cd lucene-gosen-trunk-readonly patch -p0 \u0026amp;gt; ...patch （パッチに関しては今後正式版をリリースされたら手順からは必要なくなります。）\n2. Unidic辞書生成のためのディレクトリを作成「$GOSEN_HOME/dictionary/unidic」\nmkdir dictionary/unidic 3. 対象となるUnidicの辞書のソースファイルをダウンロード 利用者登録をし、利用規約に同意の上、以下のファイルをダウンロードします。 「/」に添ってダウンロードページから遷移してダウンロードしてください。\n1.3.12個別ファイル/unidic-chasen/unidic-chasen1312src.tar.gz 4. ダウンロードしたtar.gzファイルを「dictionary/unidic/」にコピー\ncp .. lucene-gosen-trunk-readonly/dictionary/unidic/ 5. Antを実行してjarファイルの作成\nant -Ddictype=unidic 成功すれば、lucene-gosen-trunk-readonly/dist/lucene-gosen-2.1-dev-unidic.jarファイルが生成されます。 あとは、通常通り、SolrやLuceneで利用することが可能です。\n以上がjarファイルの作成手順となります。\n###制約事項（2012/06/18現在）___ 現在（2012/06/18）時点で公開しているパッチは、以下の制約が存在します。\nCOMPOUNDエントリー未対応 品詞情報（発音）の内容の制限 COMPOUNDエントリー未対応 Unidicの辞書のエントリーの中に1件だけ、COMPOUNDと呼ばれるエントリーが1件だけ存在します。 別々の単語を組み合わせて1単語として扱うことができるようになっているようです。 lucene-gosenでは、残念ながら、このような辞書の形式には対応していません。 1件しか存在しないデータでもあることを鑑みて、今回の辞書構築処理では、スキップするようにしました。\n品詞情報（発音）の内容の制限 lucene-gosenの実装上、単語の読みのバリエーション数と発音のバリエーション数には以下の制限が存在します。\n「読み」バリエーション数 ＜ 「発音」バリエーション数 「読み」に対応する形で、「発音」がlucene-gosenでは品詞情報としてデータ登録されています。 UniDicのデータには上記制約を満たさないデータが5件ほど存在します。 現在、これら5件のデータについて、「読み」に対応した「発音」データには空文字が表示されるようになっています。\nまだ、簡単に動作確認をしただけです。UniDicを利用していて問題など有りましたら連絡、Issueへのアップをしていただけると助かります。\n","date":1340028180,"dir":"post/2012/","id":"d13aa56e27fe71ef40ff153c093ecdf8","lang":"ja","lastmod":1340028180,"permalink":"https://blog.johtani.info/blog/2012/06/18/lucene-gosen%E3%81%AEunidic%E5%AF%BE%E5%BF%9C/","publishdate":"2012-06-18T23:03:00+09:00","summary":"Issue 32で上がってきたlucee-gosenのUniDic対応の最初のパッチを書いたので、ブログに残しておきます。 ###UniDicとは___","tags":["lucene-gosen"],"title":"lucene-gosenのUniDic対応(Jugemより移植)"},{"contents":"「鉄は熱いうちに打て」ということで、残りも勢いでメモ。 まだ、見直しとかしてない状態なのでおかしいところとかありますが。。。 図とか入れるのはまた今度。\nTransport（転送）\nZipkinとHadoopに異なるサービスからのトレースを送信するのにScribeを利用します。 ScribeはFacebookにより開発されました。 システムの各サーバで実行できるデーモンとして作成されています。 ログメッセージをListenし、カテゴリごとのcorrectレシーバーに配送します。 Zipkin collector daemon\nトレースデータがZipkinコレクターデーモンに配送されたらvalidかどうかをチェックしてから保管し、インデックスを作成します。 Storage\nストレージにはCassandraを選びました。 スケーラブルで、柔軟なスキーマをもっており、Twitter内部で大変使われています。 このコンポーネントをプラガブルにしようと試みましたが、困難なため、ここでは公開しません。 Zipkin query daemon\n保存、インデックスされたデータを探す方法が必要です。 クエリーデーモンはユーザに対して簡単なThriftAPIを公開しており、トレースを探すことが可能です。Thrift fileを見て下さい。\nUI\n多くのユーザはUI経由でデータにアクセスします。 VisualizeにD3を利用したRailsアプリケーションです。 UIの認証は実装していないことに注意してください。\nモジュール Zipkin内部のモジュール関連図\n##インストール___ Cassandra\nZipkinはCassandraをストレージにしています。Cassandraクラスタが必要になります。 1. Cassandraサイトを参考にしてクラスタを構築してください。 2. Zipkin Cassandraスキーマを利用します。つぎのコマンドでスキーマが作成できます。 bin/cassandra-cli -host localhost -port 9160 -f zipkin-server/src/schema/cassandra-schema.txt Zookeeper\nZipkinは協調のためにZooKeeperを利用します。 これは、保存すべきサーバをサンプルレートで決定し、サーバを登録します。？ 1. ZooKeeperのサイトを参考にインストールしてください。 Scribe\nScribeはトレースデータを配送するのに利用するロギングフレームワークです。 ネットワーク保存先としてZipkinコレクターデーモンを指定する必要があります。 Scribeの設定は次のようにします。 \u0026lt;store\u0026amp;gt; category=zipkin type=network remote_host=zk://zookeeper-hostname:2181/scribe/zipkin remote_port=9410 use_conn_pool=yes default_max_msg_before_reconnect=50000 allowable_delta_before_reconnect=12500 must_succeed=no \u0026lt;/store\u0026amp;gt; 注意：上記設定は、カテゴリーにより送信ホストを見つけるためにZooKeeperを利用するサポートのScribeのTwitterバージョンを使用する方法です。 コレクターのためのDNSエントリーを利用したりもできます。 Zipkinサーバ ZipkinサーバはScala 2.9.1、SBT 0.11.2そしてJDK6で開発しました。\n1. git clone https://github.com/twitter/zipkin.git 2. cd zipkin 3. cp zipkin-scribe/config/collector-dev.scala zipkin-scribe/config/collector-prod.scala 4. cp zipkin-server/config/query-dev.scala zipkin-server/config/query-prod.scala 5. Modify the configs above as needed. Pay particular attention to ZooKeeper and Cassandra server entries. 6. bin/sbt update package-dist (This downloads SBT 0.11.2 if it doesn\u0026#39;t already exist) 7. scp dist/zipkin*.zip [server] 8. ssh [server] 9. unzip zipkin*.zip 10. mkdir -p /var/log/zipkin 11. zipkin-scribe/scripts/collector.sh -f zipkin-scribe/config/collector-prod.scala 12. zipkin-server/scripts/query.sh -f zipkin-server/config/query-prod.scala SBTでコレクターとクエリサービスを起動します。 Scribeコレクターサービスの起動方法は次の通り。 bin/sbt \u0026#39;project zipkin-scribe\u0026#39; \u0026#39;run -f zipkin-scribe/config/collector-dev.scala\u0026#39; クエリサービスは次の通り bin/sbt \u0026#39;project zipkin-server\u0026#39; \u0026#39;run -f zipkin-server/config/query-dev.scala\u0026#39; Zipkin UI\nUIはRails3アプリです。 1. 設定をZooKeeperサーバでアップデートします。これはクエリデーモンを見つけるのに利用します。 2. Rails3アプリケーションサーバにデプロイします。テストの場合は次のようにすることもできます。 bundle install \u0026amp;amp;\u0026amp;amp; bundle exec rails server. zipkin-tracer gem\nzipkin-tracer gemをトレースしたいRailsアプリケーションにRack Handlerで追加します。 config.ruにつぎの記載をします。 use ZipkinTracer::RackHandler run \u0026lt;YOUR_APPLICATION\u0026gt; もし、アプリケーションのstatic assetsがRailsで提供されれば、リクエストがトレースされます。 ##　Running a Hadoop job\nScribeからHadoopにログを保存する設定をすることも可能です。 これをすると、Zipkin自身でオンザフライで簡単に作れないデータから様々なレポートが作成可能です。 ScalaでHadoopのジョブをかけるScaldingというライブラリを利用します。\n``` 1. Hadoopジョブを実行するためのfatなjarを作成します。 2. scald.rbをjarをコピーしたいホスト名とjobを実行するホスト名に書き換えます。 3. 必要なら、scald.rbのjarファイルのバージョンを更新します。 4. scald.rbスクリプトを利用してジョブを実行できます。\n./scald.rb \u0026ndash;hdfs com.twitter.zipkin.hadoop.[classname] \u0026ndash;date yyyy-mm-ddThh:mm yyyy-mm-ddThh:mm \u0026ndash;output [dir]\n##計測ライブラリの利用方法\u0026lt;hr\u0026gt; 計測のためのライブラリとプロトコルがちょっとだけあります。 しかし、もっと計測するための役に立つものを望んでいます。 開始する前にトレースデータがどんな構造なのかを知る必要があります。\n・Annotation - 値、タイムスタンプ、ホストを含みます。 ・Span - 特定のRPCに相当するAnnotationの集合 ・Trace - あるルートSpanにぶら下がるSpanの集合\nZipkinに送信するトレースデータです。\nこれらの詳細な記述は[こちら](https://github.com/twitter/zipkin/blob/master/zipkin-thrift/src/main/thrift/zipkinCore.thrift)を見て下さい。 その他にトレースデータの重要なものは、トレースされたサービス間でやり取りされる情報である、軽量なヘッダーです。 トレースヘッダは次のものから構成されます。\n・Trace Id - トレース全体のID ・Span Id - 個々のリクエストのID ・Optional Parent Span Id - このリクエストが他のリクエストの一部として生成されたら付与される ・Sampled boolean - トレースすべきかどうかを表すフラグ\nデータタイプについて、理解したので、どのように計測が行われるかを順をおってみてみましょう 例はFinagleのHTTPがどのようにトレースされるかを示しています。 他のライブラリやプロトコルはもちろん、異なりますが、基本的な部分は一緒です。\n\u0026lt;b\u0026gt;　サーバサイド\u0026lt;/b\u0026gt; 1. 到達したリクエストのトレースヘッダー存在するかどうかを調べます。存在すれば、なら、このリクエストに対して関連するIDとします。トレースヘッダーがなければ、サンプリング対象かどうかを決めて、新しいTrace Id、Span Idを生成します。参考には[HttpSererTracingFilter](https://github.com/twitter/finagle/blob/master/finagle-http/src/main/scala/com/twitter/finagle/http/Codec.scala)を見て下さい。 2. もし、現在のリクエストがサンプリングされる場合、サービス名、ホスト名、スパン名（例えば、http get/put）、その他のAnnotationのような情報を集めます。 リクエスト受信時には「server received」というAnnotationを生成し、処理が終了して結果を返すときに「server send」というAnnotationを生成します。 参考には[HttpServerTracingFilter](https://github.com/twitter/finagle/blob/master/finagle-http/src/main/scala/com/twitter/finagle/http/Codec.scala)を見てください。 3. 生成されたトレースデータはServerBuilderにより設定されたトレーサーに渡されます。 デバッグのためのConsoleTracerが例としてありますが、ZipkinTracerになります。 トレースデータを[ZipkinTracer](https://github.com/twitter/finagle/tree/master/finagle-zipkin)が受け取った時、Span Idにより集約されます。 4. ZipkinTracerが\u0026#34;end of span\u0026#34;イベント（\u0026#34;server received\u0026#34;アノテーションやタイムアウトのような）を受け取ると、Thrift構造としてデータを集約してScribeに送ります。もし、そのようなイベントが発生しない場合、ZipkinTracerはいつかそのデータを送信します？？？おかしい？。データ送信のための他の方法も追加します。 ThriftやScribeのようなものですが、JSONやHttpかもしれません？ \u0026lt;b\u0026gt;　クライアントサイド\u0026lt;/b\u0026gt; 1. リクエストを送る前にそれがトレースの一部かどうかをチェックします。 サーバで利用されているとします。　サーバは、リクエストを処理してすでに付与されているトレースIDを割り当てます。 トレースIDを再利用しますが、この新しいリクエストには新しいスパンIDを生成します。 また、親のスパンIDが存在すれば、前のスパンIDに設定します。 [ここ(TracingFilter)](https://github.com/twitter/finagle/blob/master/finagle-core/src/main/scala/com/twitter/finagle/tracing/TracingFilter.scala)や[ここ(Trace)](https://github.com/twitter/finagle/blob/master/finagle-core/src/main/scala/com/twitter/finagle/tracing/Trace.scala)が参考になります。 2. サーバサイドと同様に、送信されるHttpリクエストにトレースヘッダーを追加するための[HttpClientTracingFilter](https://github.com/twitter/finagle/blob/master/finagle-http/src/main/scala/com/twitter/finagle/http/Codec.scala)があります。 3. リクエスト送信前の「client send」やサーバからの返信を受信した「client receive」のようなアノテーションを生成します。 4. サーバサイドと同様に、データがZipkinにデータを送るZipkinTracerに到達します。 ","date":1339772520,"dir":"post/2012/","id":"9ccda414c322ebcdf875eacbba2e4b7e","lang":"ja","lastmod":1339772520,"permalink":"https://blog.johtani.info/blog/2012/06/16/zipkin%E3%81%AEreadme%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%81%9D%E3%81%AE%EF%BC%92%E6%AE%8B%E3%82%8A/","publishdate":"2012-06-16T00:02:00+09:00","summary":"「鉄は熱いうちに打て」ということで、残りも勢いでメモ。 まだ、見直しとかしてない状態なのでおかしいところとかありますが。。。 図とか入れるのはま","tags":["Zipkin"],"title":"ZipkinのReadme読んでる（その２、残り）(Jugemより移植)"},{"contents":"ZipkinのGithubにあるReadmeを読んでます。 せっかくというか、頭が悪いので読みながら内容をメモ。 まずは、アーキテクチャとトレースデータ送信のためのクライアント側あたりです。 （誤訳とかおかしいだろというツッコミ大歓迎です。） あとで、リンク貼ったり絵を入れたりするかもしれませんが、とりあえず。\n◯アーキテクチャ（図はこちら）\n・対象とするサービスからScribeでデータを収集し、ZipkinのCollectorに投げる ・CollectorはCassandraにデータを格納 ・WebUIからはQueryでCassandraに問い合わせを行なってデータ取得 ・Scripe、CollectorはZookeeperと連携している（妄想） ◯計測用ライブラリ（図はこちら。図のSと書かれた青い箱）\n・各ホストの計測用ライブラリがトレースデータを集めてZipkinに送信する。 ・ホストは他のサービスへリクエストを飛ばすときに、リクエストにトレース用のIDを付与してます こうすることで、データをあとで、束ねることが可能となります。 ◯計測ライブラリの利用方法 ・Finagle\nJVMのための非同期ネットワークスタックである。 それは、JVMベース言語（JavaやScalaなど）で非同期RPCのクライアント・サーバを構築するのに利用できる。 FinagleはTwitterの内部ですごく利用されていて、トレースサポートを実現するのに当然のポイントです。 現時点で（Finagleは）ThriftやHTTP、Memcache、Redisのクライアント・サーバサポートも持っています。 ScalaでFinagleサーバをセットアップするのはつぎのようなコードになります。 トレースを追加するには、finagle-zipkinを追加して、ServerBuilderのtraceFactory関数を呼ぶだけです。\nServerBuilder() .codec(ThriftServerFramedCodec()) .bindTo(serverAddr) .name(\u0026#34;servicename\u0026#34;) .tracerFactory(ZipkinTracer()) .build(new SomeService.FinagledService(queryService, new TBinaryProtocol.Factory())) クライアント側も同様です。 上記のようにサンプリングしたリクエストにZipkinトレーサーを指定することで 自動的にトレースできるようになります。 サービスやホストでのリクエストの開始と終了を記録できます。 さらに付加的な情報を記録したい場合は、つぎのようなコードを追加します。 Trace.record(\u0026#34;starting that extremely expensive computation\u0026#34;) 上記コードは、上記コードが実行された時間に文字列を付加できます。 キーバリュー情報を付加したい場合は次のようになります。 Trace.recordBinary(\u0026#34;http.response.code\u0026#34;, \u0026#34;500\u0026#34;) Ruby Thrift\nリクエストのトレースに利用できるgemもあります。 リクエストに対してトレースIDを生成し、リクエストに付与し、トレーサーにプッシュするのにRackHandlerのgemを利用できます。 トレーサをトレースするサンプルはzipkin-webを参照。\nRubyからトレースクライアントをコールするのに、Twitter Ruby Thrift clientを使います。 つぎのようなコードを書きます。\nclient = ThriftClient.new(SomeService::Client, \u0026#39;127.0.0.1:1234\u0026#39;) client_id = FinagleThrift::ClientId.new(:name =\u0026gt; \u0026#34;service_example.sample_environment\u0026#34;) FinagleThrift.enable_tracing!(client, client_id), \u0026#34;service_name\u0026#34;) Querulous\nQuerulousはScala用のSQLデータベースのインタフェースライブラリです。 SQLクエリの実行のタイミング情報をトレースに追加できます。 Cassie\nCassieはFinagleベースのCassandraクライアントライブラリです。 CassieのトレーサーはFinagleの例とほぼ一緒ですが、 CassieではKeyspaceBuilderに設定します。 cluster.keyspace(keyspace).tracerFactory(ZipkinTracer()) とりあえず、ここまで。___ 2012/06/22 リンクを貼って体裁を修正\n","date":1339721820,"dir":"post/2012/","id":"69f755dd5b9e90a99c3086543790541c","lang":"ja","lastmod":1339721820,"permalink":"https://blog.johtani.info/blog/2012/06/15/zipkin%E3%81%AEreadme%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E5%91%A8%E3%82%8A%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-06-15T09:57:00+09:00","summary":"ZipkinのGithubにあるReadmeを読んでます。 せっかくというか、頭が悪いので読みながら内容をメモ。 まずは、アーキテクチャとトレー","tags":["Zipkin"],"title":"ZipkinのReadmeを読んでる（クライアント周りについて）(Jugemより移植)"},{"contents":"久々にSolrの話です。 といっても、結構前からの話でして。。。\nschema.xmlのfieldTypeの設定に「autoGeneratePhraseQueries」という属性があります。 Solr3.1で導入されました。動作に関しては関口さんのブログで説明されています。 Solr 1.4までは、Analyzerがトークンを複数返してくる場合（例：lucene-gosenで「Solr入門」という文字列を入れた場合など）にフレーズクエリとして処理していました。 Lucene 3.1.0から、この処理がデフォルトfalse（つまり、フレーズクエリにならない）という挙動になりました。（詳しくは関口さんのブログで。） ただ、Solr 3.1.0では、下位互換性を考慮して、autoGeneratePhraseQueriesの設定値はデフォルトが「true」でした。\nこのデフォルト値がSolr 3.3以降で提供されているschemaのバージョン（1.4以上）からデフォルト値が「false」に変更されています。 schemaのバージョンを1.3以前のものから1.4以上に移行する場合は注意が必要です。\nとまぁ、偉そうに書きましたが、私もちゃんと追えてませんでした。 Solr勉強会第６回で、関口さんの発表できちんと説明されていて、参加してたのに聞けてなかったですし。（メモ取ってるのに、書いてない。）\nということで、Solr入門のサンプルschemaも少し修正しました。 こちらとこちらの記事に追記してありますので、参考にしてください。\n","date":1339603740,"dir":"post/2012/","id":"277f7f2177e2a265a62680ea0158f9b9","lang":"ja","lastmod":1339603740,"permalink":"https://blog.johtani.info/blog/2012/06/14/autogeneratephrasequeries%E3%81%AE%E3%83%87%E3%83%95%E3%82%A9%E3%83%AB%E3%83%88%E5%80%A4%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-06-14T01:09:00+09:00","summary":"久々にSolrの話です。 といっても、結構前からの話でして。。。 schema.xmlのfieldTypeの設定に「autoGeneratePh","tags":["solr"],"title":"autoGeneratePhraseQueriesのデフォルト値について(Jugemより移植)"},{"contents":"すでに読まれた方もいるかも知れませんが、気になったのでメモを書いてみようかと。\n先週の木曜日にTwitterのエンジニアブログでZipkinというOSSを公開したという記事がでました。 非常に興味深いシステムだったので、ちょっとずつ読み解いていきたいなという宣言（というか、ハッパをかけてもらうため）も兼ねて、まずはブログの内容をメモ程度に残しておきます。\nZipkinは分散トレースシステム（distributed tracing system）です。Twitter APIの１リクエストを構成する様々なサービスのタイミングデータ（計時データ）を集めるために作りました。 Firebugのような性能プロファイラのよなもので、しかもバックエンドのサービスもプロファイル可能です。 ZipkinはAPLv2ライセンスでOSSとしてGithubで公開しています。\nZipkinはWebのユーザインタフェースを持っています。（元記事参照） 各サービス（縦軸）でどのくらい時間がかかっているか（横軸）がわかり、クリックすることでより詳細な情報が得られます。 Zipkinはパフォーマンス改善の余地のある部分（遅いMySQLのSELECTなど）を見つけるのに役立ちます。\nZipkinはどのように動くの？ Twitterに届いたリクエストからサンプリングしたリクエストに対してトレース可能なIDを付与して、すべてのサービスに渡していきます。 全リクエストの一部をサンプリングすることで、トレースのオーバヘッドを減らし、常に本番環境で利用できるようにしています。 Zipkinコレクタ（collector）が、Scribe経由でタイミングデータを受け取り、Cassandraに保存してインデックスを作成します。 Zipkinクエリデーモンがインデックスを利用して、WebUIにトレースデータを見つけます。\nZipkinはHack Weekで開始されました。 最初はThriftに対するGoogle Dapperの論文の基本的な部分の実装から始まり、現在ではHttp、Thrift、Memcache、SQL、Redisリクエストをサポートしています。 これらはFinagleライブラリで経由で動作します。Rubyのgemも用意してあります。\nということで、ほぼ直訳ですが、何かの役に立てればと。 ちょっとずつですが、Githubのページやソースを読みながら記事を書いていこうと思っています。\n","date":1339515600,"dir":"post/2012/","id":"ee48516e57684c5a4c22adccac34be92","lang":"ja","lastmod":1339515600,"permalink":"https://blog.johtani.info/blog/2012/06/13/twitter%E3%81%8C%E5%85%AC%E9%96%8B%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%B3%E3%82%B0%E8%BF%BD%E8%B7%A1%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0zipkin/","publishdate":"2012-06-13T00:40:00+09:00","summary":"すでに読まれた方もいるかも知れませんが、気になったのでメモを書いてみようかと。 先週の木曜日にTwitterのエンジニアブログでZipkinと","tags":["OSS"],"title":"Twitterが公開した分散トレーシング（追跡？）システム、Zipkin(Jugemより移植)"},{"contents":"lucene-gosenの最新版（2.0.1）をリリースしました。\nプロジェクトページよりダウンロードが可能です。\n今回の修正では、@haruyama さんからいただいていたパッチの取り込み（リソース周りの改善など）が主な対応となっています。 また、コンパイルに利用するjarファイルがLucene/Solr3.6.0に変更になっています。（Issueはこちら） 3.6.0から追加されたテストケースにて、発生する問題への対処も施したものとなっています。\n","date":1339059234,"dir":"post/2012/","id":"216db319052b5742fc68862cb2f39905","lang":"ja","lastmod":1339059234,"permalink":"https://blog.johtani.info/blog/2012/06/07/lucene-gosen-2-0-2%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E5%91%A8%E3%82%8A%E3%81%AE%E6%94%B9%E5%96%84%E3%81%AA%E3%81%A9/","publishdate":"2012-06-07T17:53:54+09:00","summary":"lucene-gosenの最新版（2.0.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、@haruy","tags":["lucene-gosen"],"title":"lucene-gosen 2.0.2リリース（リソース周りの改善など）(Jugemより移植)"},{"contents":"昨晩に引き続き、情けない内容のブログになってしまいますが。。。\n昨晩、書いた記事の調査をしていた時に気づいた、問題になるケースがあったので調査をしていました。 Issue32に登録した内容になります。 拙い英語を振り絞って書いた英語なので、伝わらないかもしれないのでブログに残しておきます。 昨晩の問題点となったクラス（StreamTagger2.java）の内部処理についてです。 lucene-gosenのLucene向けのTokenizerの内部処理では入力文字列の処理を行うのに、「char buffer[]」を用いて 入力文字列をReaderから読み込むときにバッファリングしています。 このバッファリングにて、特定のケースにて、想定していない場所を単語の切れ目と認識してしまう問題が実装上存在しました。 Issue32に記載した内容は次のようになります。\n上記バッファは4096文字というサイズで固定になっています。 StreamTagger2クラスでは、この4096文字をオーバーするような文字列の場合に、つぎの処理により、4096文字以下の場所に文章の区切りを探そうとします。\n4096文字以上の文字列が入力される バッファに入れられるだけの文字（4096文字）をバッファにコピーする。 バッファの後ろから、つぎの5種類の文字を探索し、見つかった場合（場所をkとし、ｋ＞０の場合）は、その場所を文章の切れ目と判定して、0からk+1文字目までの文字をStringTaggerを利用して形態素解析する。 あとは、繰り返し 上記条件に合致しない場合は、4096文字を文章とみなして形態素解析を行います。 ここで、5種類の文字は以下のとおり。\n0x000D:CARRIAGE RETURN(CR) 0x000A:LINE FEED(LF) 0x0085:NEXT LINE (NEL) 0x2028:LINE SEPARATOR 0x2029:PARAGRAPH SEPARATOR 見ての通り、制御文字ばかりです。 この5文字以外は切れ目と判断してくれません。 ということで、4097文字の文字列が存在し、上記5種類の文字が一度も出てこない場合、バッファのサイズで文字列が途切れてしまい、想定しない区切り位置で区切られた文章に対して形態素解析が実行されてしまいます. HTMLから文字列を抜き出して解析したり、長い文書を解析する場合に、改行文字を削除して処理するといったことも考えられます。 上記5種類の文字列のみで文章の区切り位置を判断してしまうのは問題ではないかと。 まずは、4096文字内に「。」句点が存在した場合に、その部分を区切り位置として認識するようなパッチを記載して、Issue32に添付しました。\n「。」句点を採用した理由はつぎのとおりです。 StreamTagger2では、上記バッファリングした文字列を更に、BreakIterator.getSentenceIterator(Locale.JAPANESE)にて取得したBreakIteratorにて文節単位に区切ってから、各文節ごとに形態素解析を実施しています。 ということは、BraekIteratorにて分節の区切りとして判断される文字については、上記の文字種に追加しても問題無いという判断からです。 ただし、この修正でも、純粋に4096文字以上、句点が出てこない場合には区切り位置がおかしなことになってしまいますが。。。 もう少し、BreakIteratorの挙動を調べて、他にも利用可能な区切り文字が存在しないかを調査していく予定です。。。\n1年以上コミッターをやっているのに、こんなことも理解していないのかよいうツッコミを受けてしまいそうでなんとも情けない話です。。。 まずは、現状報告でした。\n","date":1338913260,"dir":"post/2012/","id":"cbf9587a8187985725963b8bfc67004d","lang":"ja","lastmod":1338913260,"permalink":"https://blog.johtani.info/blog/2012/06/06/issue32%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A64096%E3%81%AE%E5%A3%81/","publishdate":"2012-06-06T01:21:00+09:00","summary":"昨晩に引き続き、情けない内容のブログになってしまいますが。。。 昨晩、書いた記事の調査をしていた時に気づいた、問題になるケースがあったので調査","tags":["lucene-gosen"],"title":"Issue32について（4096の壁）(Jugemより移植)"},{"contents":"久々にlucene-gosenを触っています。 trunkのlibにある、jarファイルが3.5ベースだったので、3.6ベースにしてテストをしたところ、 いくつかある、ランダムテストで結果の不整合が検出されたので、調査していました。 先程、trunkに対応版をコミットしました。もう少しテストケースを追加してからリリースします。 おそらく、通常の使い方では問題無いと思います。\nLuceneでは、ランダムな文字列を利用したテストが実装されています。 lucene-gosenでもこのテストを利用してランダムなテストをしています。 実際にはtest/以下のorg.apache.luceneパッケージにテストケースがあります。 今回、jarファイルを差し替えた時に、このランダムなテスト実施にて、assertが失敗するケースが発生しました。\n原因究明までに、いくつかフェーズがあったので、忘れないように書いておきます。\n1.ランダムテストのテストケースにてエラーがassertが失敗するケースが発生 ※ただし、成功する場合もあり。 2.該当のテストを再現しつつデバッグ＋該当のテストがどんなものかを解読（勉強不足。。。） ※テストは、失敗した場合につぎのようなメッセージが表示され、同じテストが再現可能です。 以下、エラーの出力例。「NOTE: reproduce with: 」のあとにあるantコマンドを実行すれば、同じテストが再現可能です。\n[junit] ------------- Standard Error ----------------- [junit] TEST FAIL: useCharFilter=false text=\u0026#39;wgxznwk\u0026#39; [junit] [junit] ===\u0026gt; [junit] Uncaught exception by thread: Thread[Thread-3,5,main] [junit] org.junit.ComparisonFailure: term 0 expected:\u0026lt;w[gxznwk]\u0026gt; but was:\u0026lt;w[]\u0026gt; [junit] at org.junit.Assert.assertEquals(Assert.java:125) [junit] at org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:146) [junit] at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:565) [junit] at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:396) [junit] at org.apache.lucene.analysis.BaseTokenStreamTestCase.access$000(BaseTokenStreamTestCase.java:51) [junit] at org.apache.lucene.analysis.BaseTokenStreamTestCase$AnalysisThread.run(BaseTokenStreamTestCase.java:337) [junit] \u0026lt;=== [junit] [junit] NOTE: reproduce with: ant test -Dtestcase=TestGosenAnalyzer -Dtestmethod=testReliability -Dtests.seed=4ad9618caecb9fb2:d5476c03b8172df:-9c569f70013ffbb -Dargs=\u0026#34;-Dfile.encoding=SJIS\u0026#34; [junit] ------------- ---------------- --------------- [junit] Testcase: testReliability(org.apache.lucene.analysis.gosen.TestGosenAnalyzer):\tCaused an ERROR 3.デバッグの結果、Luceneのtest-frameworkにある「MockReaderWrapper」というクラスの影響を確認 LuceneのJIRAのLUCENE-3894にて追加されたクラスであるとわかる。 このクラス、Readerのreadメソッド内部で、ランダムな値を元に長さを途中で返すという実装のReaderになっている。 （全部で18文字の文字列なのだが、ランダムな値を元に、12文字として結果を一旦返すという仕組みが実装されている） 4.lucene-gosenの問題箇所を特定。 Readerが途切れた部分を分節として扱ってしまう実装になっていた。 該当の部分に修正をいれてコミット。 という具合です。 一応、テストを数回走らせてランダムテストが問題なく終了するのを確認はしてあります。 今回の問題に対する、個別のテストケースを追加してから近日中リリースする予定です。 対応が遅くなって申し訳ないです。。。\n","date":1338827340,"dir":"post/2012/","id":"0dcb6d0f17794bbca56b6cdb9e20b932","lang":"ja","lastmod":1338827340,"permalink":"https://blog.johtani.info/blog/2012/06/05/trunk%E3%81%AE%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E5%B7%AE%E3%81%97%E6%9B%BF%E3%81%88lucene-solr3-6-0%E3%81%A8%E3%83%A9%E3%83%B3%E3%83%80%E3%83%A0%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E5%A4%B1%E6%95%97%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-06-05T01:29:00+09:00","summary":"久々にlucene-gosenを触っています。 trunkのlibにある、jarファイルが3.5ベースだったので、3.6ベースにしてテストをし","tags":["lucene-gosen"],"title":"trunkのライブラリ差し替え（Lucene/Solr3.6.0）とランダムテストの失敗について(Jugemより移植)"},{"contents":"録画してたEテレのスーパープレゼンテーションを見ててふと書きたくなったので、書いてます。 あとから読んだら恥ずかしくなりそうだけど。。。 「\u0026ldquo;知力の余剰\u0026quot;が世界を変える」というClay Shirkyさんの話を見て思ったことです。 社会的に貢献できる仕組みが最近増えているという話の内容でした。そこで、OSSについても同じことが言えるよなぁと思った次第でして。\n昔からいろんなかたが言ってると思うし、今さら何をとおもわれるかもしれないですが、なんとなく書きたくなってしまったので。\n私はシステム開発を生業にしています。特にOSSにはお世話になっています。 実際に、OSSを利用している方はかなりいると思います。 幸いにも、私はOSSのコミッターもやっています。 OSSに色々と関わってきて常々思っていることがありまして。\nOSSは基本は有志の方々が開発やメンテナンスを行なっています。（最近では会社で行なっているところもありますが。） そんなOSSに貢献する方法はいくつかあるのかなぁと。\nバグを発見したら報告したり、こんな機能を作ってみたけどどうですか？とパッチを送ってみたりするのは素晴らしい貢献だと思います。 ただ、なかなかアクションを起こすのって勇気がいるかなぁと。 実際、私もパッチ書いたりバグ報告するのは気後れすることがありしました。 ただ、貢献する方法ってこれだけじゃないよなぁと、コミッターをやり始めて思いました。\nもちろん、バグ報告してもらえるともっとありがたいですし、新機能とかリクエストを送ってもらえるともっと嬉しいです。 MLに質問するのもありです。ただ、ちょっとハードルが高いと思うこともあります。\nそんな時は、ただ使っているよと、ツイートしたりブログを書いてくれるだけでもありがたいし、ヤル気が出るものです。 使い勝手が悪いなぁというツイートでも、なんでこんなに使いにくいんだというブログでもいいんです。 気になるなぁという形でもいいと思っています。 githubでフォローするだけでもいいかと。 反応があれば、使ったり触ってもらえていることがわかります。 なので、使っているよとかアピールしてもらえると嬉しいよなぁと。\nなんか、締りのない感じになっちゃいましたが、反応があるとうれしいので、お気楽に反応しましょうよというお話です。\n","date":1338394320,"dir":"post/2012/","id":"ffdbd6a7d28c9a63976e9eec38cab0f5","lang":"ja","lastmod":1338394320,"permalink":"https://blog.johtani.info/blog/2012/05/31/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%B8%E3%81%AE%E8%B2%A2%E7%8C%AE%E3%81%AE%E3%82%B9%E3%82%B9%E3%83%A1/","publishdate":"2012-05-31T01:12:00+09:00","summary":"録画してたEテレのスーパープレゼンテーションを見ててふと書きたくなったので、書いてます。 あとから読んだら恥ずかしくなりそうだけど。。。 「\u0026l","tags":["misc"],"title":"オープンソースへの貢献のススメ(Jugemより移植)"},{"contents":"JJUG CCC 2012 Springに参加してきました。 昨年のFallに続き、2回目です。 概要や、タイムテーブルはこちらを御覧ください。 今回は、午後一から参加しました。 色々と迷いましたが、つぎのを聞いて来ました。\nHotSpot vs JRockit ～ HotRockit到来の前に予習しよう！ Play! Framework - モダンで高速なWeb開発 Grails/Groovyの開発活用術 Scala 最新状況報告 From Swing to JavaFX SwingからJavaFXへのマイグレーションガイド JRockitは使ったことがなく（たぶん）、新鮮でした。いろいろなコマンドが用意されているなぁと。 あと、jvisualvmの使い方も知らないこともあったのでいい話が聞けました。 プレゼンに慣れているようで、プレゼン中に、コマンドラインの拡大＋コマンドのオプションに赤い下線を入れるなど、どうやってやっているのか、プレゼンの内容よりも気になってしまったのが本音です\nPlayは今回の目玉の一つでした。まだ、手元でPlayを触り始めたばかりだったので、概観がつかめたのが良かったです。 あとでスライドを見なおさないと。 頭がどうしてもServlet、JSPのため、未だにPlayに切り替えができてないので、もっと触ってみないとなぁと。 ちなみに、紆余曲折してまして、Play 1.2.4→Play 2.0（Javaアプリ）→Play 2.0（Scalaアプリ）と心変わりしまくりで、まだ完全に作ってないのに、ふらふらしてます。。。\nGrailsはGrailsを現場にどのように投入していくのがいいかという、技術よりは、政治的な話でしたが面白かったです。 実際に、あまり有名でないプロダクトを現場に導入するのに、Javaだからと無理やり説得してみたりｗ、開発コストがこれくらい下がりますという話をしてみたりと、いろいろやられているようでした。 あと、PlayのあとにGrailsということもあり、すこしPlayを意識した話もされていました。\nScalaはScalaDaysの話＋Scalaの最近の動向ということで、ある程度Scalaを知っている人がターゲットのようでした。 少し触っただけなので、何となく分かる部分もありましたが、最後の方はついていけてないです、すみません。。。 一番感じたのは、発表者の水島さんのScalaに対する愛情でしょうか。\n最後は桜庭さんのJavaFXのお話です。 一応、昔、JFreeChart＋Swingでちょっとしたものを作ったことがあるので面白かったです。 プレゼン自体もJavaFXで作成されていたり、オープニングがStarWars風だったりと凝ったプレゼンでした。 JavaFXとしては、JavaOneでも聞いたのですが、グラフやHTMLがリッチに書けるようになったことがびっくりです。\n実際のSwingアプリからJavaFXへの移行に関して、注意する点などがわかりやすく聞けました。 FXMLは確かに便利ですよねぇ。レイアウトをJavaで組むのがすごくめんどくさかったもんなぁ。\nさて、簡単ですが、感想でした。 今回一番残念だったのは、長丁場の割に電源の確保が難しかったことでしょうか。 ツイートしたり、メモ取ったりしたかったのですが、電源が乏しいので、Wi-fiオフにしてメモ取るのが限度でした。。。\n場所：オリンピック記念青少年総合センター 日時：2012/05/28 10:00 - 19:00 ◎13:10 - 14:00 C-1 HotSpot vs JRockit ～ HotRockit到来の前に予習しよう！ 谷本 心 @cero_t ◯HotSpot from Sun ◯JRockit from BEA 今は、どちらもOracle ◯違いは？ 1.歴史 2.プラットフォーム JRockitはMacではNG。Solarisは一部。 2.1Oracleさん曰く Solaris/Mac → HotSpot Windows/Linuxのサーバ → JRockit Windows/Linuxのクライアント → HotSpot 2.2谷本さんは？ WebLogic → JRockit 1.4、5の時の開発環境はJRockit 当時はJRockitの解析ツールがカッコ良かった 3.解析ツール 3.1コマンドラインツール プロセス HotSpot ： jps JRockit ： jrcmd スレッドダンプ HotSpot ：jstack JRockit ： jjrcmd \u0026lt;pid\u0026gt; print_threads ヒープ解析 HotSpot：jmap -histo \u0026lt;pid\u0026gt; JRocket：jrcmd \u0026lt;pid\u0026gt; heap_diagnostics HotSpot： JRockit：jrcmd \u0026lt;pid\u0026gt; 他にもJRockitは色いろある。 print_utf8poolとか（内部の文字列が出てくる） 3.2GUIツール HotSpot：jvisualvm　NetBeansベース JRockit：Mission Control　Eclipseベース メモリリークの解消をツールを使ってみてみましょうデモ。 ・hprofファイルを吐き出して、jvisualvmで読みこむのが楽な方法 ・jrmcはヒープダンプファイルを読み込む機能がない。 memleakというツールがある。アプリを起動してから、プロセスを右クリックして選択可能。 タイプグラフや割当てトレースみたいなものが使えるよ。 フライトレコーダーというのもあるよ。 4.HotRockitの紹介 まだいつ出るのかなぁという状態だけど、HotSpotにJRockitのツールも使えるようになるVMが出る模様。（2013？） ※デモ中に画面拡大した時に、赤線でラインを引いているのがすごく気になった。（便利なツールなのかな？そこだけ？） ◎14:15 - 15:05 C-2 Play! Framework - モダンで高速なWeb開発 池田尚史 @ikeike443 ◯自己紹介 Play!Frameworkコミッター 日本Playframeworkユーザ会 ◯アンケート メイン言語は？Java多数 触ったことある？半分くらい？ Play1？Play2？半々くらい プロダクションで使ってる人？3人 ◯Playframeworkって？ JEEではないよ。 Webだよ。 ServletとかXML使ってないよ。 ◯JEEは難しいよね。RailsとかDjangoから流れてくると。 ◯Webフレームワーク なので、Webアプリが作れればいいよね。 開発すべきものに注力して、抽象化とかを頑張らないようにと。 ◯ライブコーディング！ Play2.0のScalaアプリみたい。 プロジェクト作成～編集して起動まで。 エラーを起こして、エラーがどのように表示されるか。 エラーのリンクをクリックして、エディタを起動するということも可能みたい。 TODOとかで、まだ終わってないのも記述可能。 パラメータとControllerの関数の引数が勝手にひもづけられますよと。 ◯歴史 Servletとかもあった。 1.2からNetty、Websocket、Scalaサポート 2.0.1：Scalaで書き直し。Netty+Akkaで非同期 ◯１と２のちがいは？ ・Play1 Javaで書かれたJavaのフレームワーク。Scalaはプラグインサポート ・Play2 Scalaで書かれたScala/Javaのフレームワーク ◯Playの特徴 ステートレスとかノンブロッキングとかリアクティブとか ・高生産性 XMLがないし、unzipするとすぐ使えるよ。 ホットスワップできるよ。 CoffeeScript、LESSサポートも。assetsに入れとくとコンパイルしてくれて静的コンテンツにしてくれる。（Railsにも似たようなのあったっけか？） ・ステートレス HttpSessionがない→必要ならMemcachedとかで管理してね。 「デプロイ→ニーズ・状況に応じて即時スケールアウトという時代じゃないか？」という主張 Playはステートレス養成ギブスであり、時代の要請にマッチ ・広範囲な型安全 コンパイルしてエラー検知 ・ノンブロッキングI/O 非同期処理が手軽に書けるように考えられている。 →リアルタイムWebの時代 NettyやAkkaにより実現されてるのがいい Akkaを使ったアプリを書くと、長い処理のActorを別サーバにするなども設定で変更が可能。 ◯テスタビリティ BDDフレームワーク（Specs2？） Viewもテストできるぞと。 ◯事例 Klout：ソーシャルスコアリング イギリスのガーディアン：コンテンツAPIの実装がPlay2 MinecraftのWebサイト ◎15:20 - 16:10 C-3 Grails/Groovyの開発活用術 ～Java EE資産を活かして開発を加速する～(仮) 上原潤二 山本剛 ◯充電中のためお休み ◎16:25 - 17:15 C-4 Scala 最新状況報告 ～或いはScala Days 2012リポート～ 水島宏太 ◯自己紹介 言語を作るのが夢みたい。 ◯Scala最新状況報告 ScalaDaysの雰囲気を伝えるよと。（どっちかというと、旅行記かも） ◯Scala？ ・オブジェクト指向関数型言語 ハイブリッドじゃなくて、統合したもの ・強力な静的型付け NullPointerExceptionなども起きにくい ・超強力なコレクションフレームワーク ・Javaと同等の実行速度 ・コードが簡潔（1/4くらい） ◯Scala採用企業 Twitter、Amazon.com（どこに使ってるかは不明）、Foursquare、LinkedIn、VMWare、Klout、Tumblrなど ◯Scalaのバージョンは？ 2.10が開発版。2.9.2がステーブル版。 ◯開発体制 Typesafe＋世界のContributor Typesafeメンバの議決でいろいろ決定 githubでオープンに開発 ◯ScalaDays2012の目玉 豪華ゲスト（私は、わからなかった） Scala2.10の新機能紹介 今後のScala、多数の応用例 ◯ScalaDays2012を見ての方向性 ・All-in-oneパッケージの提供 Typesafe Stackの提供 重要なツール sbt（Simple Build Tool） gitter8（プロジェクトテンプレート生成ツール。githubを元に色々取ってくる？） Akka Play 2.0 Framework ・学習コストの削減 言語機能のモジュール化 高度な開発者が使う昨日はデフォルトOff ・バイナリ互換性問題への対処 ・Minor Release間での互換性を維持 MIMAでジドウテキに非互換性を検出 ・Major Release間では互換性は保証しない。 No more java.util.Date ソース互換性は「概ね」保証される deprecatedは次期メジャーバージョン時に削除される。 ・Scala IDEへの注力 インクリメンタルにコンパイルしてくれるから、遅いのも気にならなくなるかも。 デバッガとか、できるよと。 ・さらなるパフォーマンス改善 Value classes AnyValを継承したクラスが作成可能 該クラスのオブジェクトがインライン化 Pimp my libraryによるヒープ使用料が0に！ ◯2.10最新機能紹介 \u0026#34;1+2=#{1+2}\u0026#34;ができない s\u0026#34;1+2=${1+2}\u0026#34;ができるように String = 1 + 2 = 3 f\u0026#34;1=${1}%03d\u0026#34;もできるようにSring = 1 = 001 自分でStringコンテキストにメソッド追加できるらしい（聞き取った日本語が合ってるか？） とか。（かなり不安。。。まだまだわかってない。。。） ◎17:30 - 18:30 BOF-B-1 From Swing to JavaFX SwingからJavaFXへのマイグレーションガイド 櫻庭 祐一 ◯JavaFX 次世代のJava GUI Library Swing+Java2D+α JavaSE8から標準（JavaFX3.0） ◯サンプル クラス名がいろいろ変わってる。 ◯はまりそうなところ コンテナへの追加がちょっと違う イベントリスナは1種類のみになった。（Genericsを使うようになったよと。） ◯Bind 値が変わるとModelが勝手に検知して変わるみたい。 双方向もあり。これだとEventを書かなくても良くなりつつ有るよと。 ◯シナリオベースでマイグレーション考えましょう 1.JavaFX in Swing JavaFXにSwingを埋め込むことはできないぞと。 SwingでできないことをJavaFXでやりますよと。 おー、グラフが動く。JavaDocのHTMLも綺麗に出てる。 使い方：JFXPanelを使う シーングラフを記述可能 データのやり取りが大変。Threadが違うから。 パフォーマンスが落ちます。Java2Dで画像を書くので遅いですよと。 新規のものはJavaFXで書きましょうと。 2.Swing to JavaFX w/o FXML SwingをJavaFXに置き換える。 使い方が違うものはTableViewなど、◯Viewとついてるもの。 ちょっと考えるのはLayout Swing：コンテナ＋レイアウトマネージャー JavaFX：コンテナがレイアウトを含む BorderPaneクラスとか。 問題はTableとか Swing：TableModel JavaFX：BeanをColumnにバインド 3.Swing to JavaFX w/ FXML ・FXML GUIの構造をXMLで表す。 シーングラフを表現。 スキーマレス クラス：要素 プロパティ：属性 or 要素 アノテーションバリバリです。これで、FXMLとJavaのバインディングができるよと。 ツール Java ：NetBeans e(fx)clipseってのがあるかも。 FXML：Scene Builder ","date":1338259500,"dir":"post/2012/","id":"de734259dfb9addebe2b226d96b4f744","lang":"ja","lastmod":1338259500,"permalink":"https://blog.johtani.info/blog/2012/05/29/jjug-ccc-2012-spring%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-05-29T11:45:00+09:00","summary":"JJUG CCC 2012 Springに参加してきました。 昨年のFallに続き、2回目です。 概要や、タイムテーブルはこちらを御覧ください。 今回は、午後一から参加","tags":["勉強会"],"title":"JJUG CCC 2012 Springに参加してきました。(Jugemより移植)"},{"contents":"PlayFramework2.0を触ってみてます。 ちょっとコーディングしたくなったのと、最近のアプリの作成の調査も兼ねて。 まぁ、せっかくなので、Solr検索のアプリでも作ってみようかと言うことで触ってます。 ただ、Solr検索アプリでしかなく、今のところDBを使わないので、実はPlay Frameworkじゃなくてもいいのではないかという疑問も。。。\nまだ、触り始めたばかりなので、なんともですが。感想を。 たぶん、Ruby on Railsに似ているのかなと。 RoRは仕事で少し関わったので、なんとなく知っていますが、アプリの作成手順や、ディレクトリ構成などが似ている気がします。\nコントローラーの生成のタイミングとか、内部でオブジェクトをSingletonで保持する方法とかのイメージがまだ良くつかめていない状態で、まずは、Solr検索部分（Palyにあんまり関係ないところ）を実装しているところです。\n現状で一番の疑問点は、Eclipseプロジェクト化した時の参照ライブラリのパスに関するところでしょうか。 Play Frameworkは「play new ほげほげ」コマンドを実行するとアプリのディレクトリ構成が作成されます。 このあとに、eclipsfyというplayのコマンドを実行すると、Ecilpseのプロジェクトファイルが作成されます。 この時、PlayFrameworkが利用するjarファイルたちが参照ライブラリとしてクラスパスに設定されます。\nこのパスには、PlayFrameworkのインストールディレクトリが含まれた絶対パスが記述されるのですが、 複数人で開発するときにはどうしているのかなぁと。 あと、BitbucketやGitHubにアップするときもどうするのかなぁと。 以前、この疑問ツイートして、頂いた回答としては、環境変数として定義して、各自で設定してもらうというものでした。 私も同じ事を考えていたので、腑に落ちたのですが、他にもっといい方法があったりするんでしょうか？ クラスパスやEclipseプロジェクトのファイルをアップしないというのもあると思いますが、それもちょっとなぁと。 なにか、オススメとかあれば、教えていただけると嬉しいです。\n最近、ブログ更新してなかったのもあったので、まずは、導入編でした。\n","date":1337151314,"dir":"post/2012/","id":"78f002cc3d512ea302c900d1da4dfeec","lang":"ja","lastmod":1337151314,"permalink":"https://blog.johtani.info/blog/2012/05/16/playframework-2-0-java%E3%81%AE%E6%96%B9-%E3%82%92%E8%A7%A6%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%A6%E3%82%8B/","publishdate":"2012-05-16T15:55:14+09:00","summary":"PlayFramework2.0を触ってみてます。 ちょっとコーディングしたくなったのと、最近のアプリの作成の調査も兼ねて。 まぁ、せっかくなの","tags":["備忘録"],"title":"PlayFramework 2.0(Javaの方)を触ってみてる(Jugemより移植)"},{"contents":"lucene-gosenの最新版（2.0.1）をリリースしました。\nプロジェクトページよりダウンロードが可能です。\n今回の修正では、Java7でUnicodeのバージョン変更に伴う対応（詳細はこちらを参照）を行なっています。\nリソース周りの対応はまた後日。。。すみません。2012/05/16 遅くなりましたが、昨晩、JavaDocをアップしました。\n","date":1336494900,"dir":"post/2012/","id":"c4b418764dca70aebfc965899a3fa7e5","lang":"ja","lastmod":1336494900,"permalink":"https://blog.johtani.info/blog/2012/05/09/lucene-gosen-2-0-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9java7%E5%AF%BE%E5%BF%9C/","publishdate":"2012-05-09T01:35:00+09:00","summary":"lucene-gosenの最新版（2.0.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、Java7で","tags":["lucene-gosen"],"title":"lucene-gosen 2.0.1リリース（Java7対応）(Jugemより移植)"},{"contents":" IDの秘密 (丸善ライブラリー―情報研シリーズ) 非常に面白く読めました。 バーコードの話に始まり、最後はシステムで付与するIDに関する考慮点まで幅広くIDについて語られています。\n適度に配置されたコラムがまた面白く、ここまで書いてもいいのかな？と思いながらも楽しく読ませて頂きました。 2次元バーコードが汚れに強いのも知らなかったし、チロルチョコの話は知らなかったし、指コレクションとか面白すぎです。 また、JRのSuicaの導入に7年もかけている点などは、やはりすごい技術なのだなぁというため息混じりの感想です。 それほど長い期間のテストや設計は想像がつかないです。\n最後の2章（７，８章）については、エンジニアの以外のシステムに関わる方やエンジニアになられたばかりの方たちにぜひ読んで欲しいと思いました。 もちろん、エンジニアの方にも読んでほしい内容です。\nいくつか疑問点や気になる点もあったので。\n「静脈や指紋が人によって異なるって確率はどうやって決めたんだろう？」 Twitterの説明文のあとにFBの画面の図番号が書いてある。 日本語がデコードされたけど、QRコードの文字コードって、この中に含まれてるのかな？それとも規格で決まってるのかな？ 最後に、書影がNIIに合ったので撮影しました。写真へのリンクです。\n","date":1335794635,"dir":"post/2012/","id":"95c0a5b8a66950b5f22dd82a8dfe0ce5","lang":"ja","lastmod":1335794635,"permalink":"https://blog.johtani.info/blog/2012/04/30/id%E3%81%AE%E7%A7%98%E5%AF%86%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-04-30T23:03:55+09:00","summary":"IDの秘密 (丸善ライブラリー―情報研シリーズ) 非常に面白く読めました。 バーコードの話に始まり、最後はシステムで付与するIDに関する考慮点まで","tags":["読書"],"title":"「IDの秘密」を読みました。(Jugemより移植)"},{"contents":"WebSolrの話があるらしいというのを嗅ぎつけて、初めてHeroku JP Meetupに参加しました。 herokuもWebSolrも知りつつ、手を出していなかったので、いい機会でした。 （SignUpだけ、勉強会直前に済ませましたｗ）\nHerokuはAWS上に構築されたアプリケーションプラットフォームで、簡単にアプリをデプロイして動作させることができるようです。 Ruby on Railsを使うのが多いみたいですが、他の言語も利用できると。 で、herokuの面白いところは、アドオンとして、開発が簡単にできるようなしくみが用意されていることみたいです。 今回発表のあった、IronMQ、WebSolr、PaperTrailもアドオンとして用意されており、簡単に利用することが可能です。 IronMQはメッセージキューとして利用できます。\nWebsolrはSolrを簡単に利用できる形で提供しているものになります。 今、利用できるのは3.5.0のようで、最新版（3.6.0）になるのはまだ未定のようです。 今回の発表はWebSolrの話しもありましたが、基本は全文検索の仕組みとKuromojiの説明でした。 ただ、残念ながら、Kuromojiは3.6.0からの提供となるので、現時点では利用できないようです。 あとで、聞いた話だと、schema.xmlを自分で変更できるようです。 ただ、jarファイルを置いたりはできないようなので、lucene-gosenを利用するとかはできないみたいですが。。。 ほかにも、bonsai.ioとして、ElasticSearchの提供も行うようです。 まだ、利用はできないようですが。\n最後がPapertrailです。 こちらは、ログを保存して、検索、グラフ化（視覚化）してくれるアドオンです。 まだ、ベータのようですが、ログを保存してくれるようです。無料版もあるようです。 アドオンとしての機能もそうですが、利用しているグラフ化のツールなど、面白そうなものが利用されていました。\nLTはRuby使いの方が多かったです。\nRuby使いではないのですが、いろいろなアドオンが用意されており、サービスを簡単に提供することができそうだという印象をうけ、ちょっと使ってみたいなぁと思いました。 普段参加していない勉強会だったので、普段では知りえない興味ある話が聞けて面白かったです。\n余談ですがPapertrailの人が利用していた、slideshareのようなサービスのSpeaker Deckもよさそうなので登録してみました。 次に何か発表があった時には資料はこっちにアップしてみようかなぁと\n以下は、いつものように自分用のメモです。\n日時2012/04/20 19:00 to 21:00 会場：パソナグループ本部　呉服橋 ◎オープニング – Ayumu AIZAWA (Heroku Evangelist） ◎新入社員からの挨拶 – Koichi SASADA (Ruby Developer） 前職：大学教員 仕事：CRuby開発 Heroku使った事無いですｗRailsもよく知らないですｗ RUby2.0のリリースがゴール。2013/Feb 性能アップのことやってます。 ◎IronMQ – Chad Arimura (Iron.IO)\n「メッセージキューは涼しいです。」 （Google翻訳による日本語訳付きのスライド） Aggregation、Distribution。。。 IronMQ Elastic、RESTful heroku addon ironmq:rust 簡単にheroku上にキューが用意できるアドオンです。 Q：メッセージがキューに到達したのを確認する方法か？ A：ステータスコードが帰ってくる。 Q：データのサイズのリミットは？ A：postのリミットはある。S3とかに巨大データをおいて、ポインタを渡すとかしてほしい。 Q：キューへの到達の成功の保証は？ A：アプリケーション側で判断してください？ ◎Search \u0026amp; Indexing on Heroku – Nick Zadrozny (Websolr) スライドはこちら。\n※ツイートしてて、メモとってなかったので、ツイートをコピペ。 次はWebsolrのお話 Bonsai.io？ Bonsai by onemorecloud - http://bit.ly/JjCuaE SQLのLIKE検索はO(n)でおそいねぇと。 クエリのパースについての話。 今度は転置インデックスのお話。 Termへの分割ってどーすんの？というお話。Tokenizeのお話。 その１：N-GramというTokenizeの方法。N文字ずつ先頭からTermを切り出す。開始位置は1文字ずつずらしていくと。 N-Gramはノイズがのるし、多くのTermがでてきちゃうよと。 その２：そこで、次は形態素解析ですね。 先週、Lucene/Solr 3.6.0がリリースされて、Kuromojiという日本語向けの形態素解析器がでましたよ。 Kuromojiはこちら。（Lucene版とは少し違うけど。）http://atilika.org/ Kuromojiのサーチモードのお話。 通常は、「関西国際空港」という単語になってしまうのを、Kuromojiでは「関西」「国際」　「空港」という切り方の単語も出してくれると。 ちなみに、lucene-gosenでは、サーチモードはないんですねぇ。。。 「の」はどこに消えたんだ？？そこの説明は？ ElasticSearchやSolrのコアの部分でLuceneを使ってるよ。 ElasticSearch　http://bit.ly/qjjvWp Kuromojiはユーザ辞書をサポートしてるよ。 Q：まだ、3.5.0では？ A：もうすぐやります ◎log analysis for your Heroku app – Eric Lindvall (Papertrail)\nheroku上にログを貯めて、検索したりグラフ化したりできるようになりそうなもの。 [スライドはこちら](http://speakerdeck.com/u/lindvall/p/log-analysis-for-your-heroku-app) ログを貯めて、検索や可視化できるようにするサービスみたいです。 まだ、アイデアレベルのものも発表資料には含まれていました。 内部で利用しているツールなど、資料の最後に出てきますが、色々と面白そうなものがありました。 ◎Lightning Talks ◯Receibo ( @shu_0115 ) デザイナーｘエンジニアハッカソンでの成果らしい。 Webベースの家計簿アプリ。 買ったものの名称と料金を入れるだけ。 ◯Heroku + Pusherで作る！リアルタイムアプリケーション ( @satococoa ) WebSocketみたいなことが、Pusherでできるらしい。 http://www.slideshare.net/satococoa/heroku-pusher　◯Herokuアドオンを作ってみてわかったこと ( @takkam ) ◯heroku client のちょっと進んだ使い方 ( @hsbt ) ◯love heroku? – we love herokuのご紹介 ( @ppworks ） ","date":1334935380,"dir":"post/2012/","id":"c92c12a28fa219ad1aab60865046ff05","lang":"ja","lastmod":1334935380,"permalink":"https://blog.johtani.info/blog/2012/04/21/heroku-jp-meetup-4%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/","publishdate":"2012-04-21T00:23:00+09:00","summary":"WebSolrの話があるらしいというのを嗅ぎつけて、初めてHeroku JP Meetupに参加しました。 herokuもWebSolrも知りつつ、","tags":["勉強会"],"title":"Heroku JP Meetup ＃4に参加しました。#herokujp(Jugemより移植)"},{"contents":"先日、Solr入門のサンプルschema.xmlの3.6.0対応版の作成をしていて、気になったことがあったので、 メモとして残しておきます。\nSynonymFilterFactoryの属性「tokenizerFactory」に関連する話です。 （「Apache Solr入門」の36-37ページに記載があります。）\nSynonymFilterFactoryでは、類義語設定ファイルを読み込む際に利用するTokenizerFactoryを「tokenizerFactory」という属性で指定できます。（以下は書籍の記述を抜粋）\n\u0026lt;filter class=\u0026#34;sold.SynonymFilterFactory\u0026#34; synonyms=\u0026#34;synonyms.txt\u0026#34; ... tokenizerFactory=\u0026#34;solrbook.analysis.SenTokenizerFactory\u0026#34;/\u0026gt; このように、TokenizerFactoryが指定できます。\nただ、こちらの記事で書いたように、 Solr 3.6.0のexampleのschema.xmlではCJKのフィールドは次のように設定されています。\n\u0026lt;!-- CJK bigram (see text_ja for a Japanese configuration using morphological analysis) --\u0026gt; \u0026lt;fieldType name=\u0026#34;text_cjk\u0026#34; class=\u0026#34;solr.TextField\u0026#34; positionIncrementGap=\u0026#34;100\u0026#34;\u0026gt; \u0026lt;analyzer\u0026gt; \u0026lt;tokenizer class=\u0026#34;solr.StandardTokenizerFactory\u0026#34;/\u0026gt; \u0026lt;!-- normalize width before bigram, as e.g. half-width dakuten combine --\u0026gt; \u0026lt;filter class=\u0026#34;solr.CJKWidthFilterFactory\u0026#34;/\u0026gt; \u0026lt;!-- for any non-CJK --\u0026gt; \u0026lt;filter class=\u0026#34;solr.LowerCaseFilterFactory\u0026#34;/\u0026gt; \u0026lt;filter class=\u0026#34;solr.CJKBigramFilterFactory\u0026#34;/\u0026gt; \u0026lt;/analyzer\u0026gt; \u0026lt;/fieldType\u0026gt; 3.6.0以前は、solr.CJKTokenizerFactoryを利用していましたが、3.6.0からはCJKTokenizerFactoryがdeprecatedになってしまい、代わりにStandardTokenizerFactory＋CJKBigramFilterFactoryの組み合わせになっています。 exampleのCJKのフィールドタイプ設定を利用して、かつ、そのフィールドにSynonymFilterを利用する場合に、 StandardTokenizerFactoryを指定してしまうと、類義語が展開できなくなってしまうので注意が必要です。\nCJKのフィールドでSynonymFilterを利用する場合は、類義語の設定ファイル内の記述を自力でCJKTokenizerが分割する形で記述する（まぁ、やらないでしょうが）か、deprecatedですが、CJKTokenizerFactoryを利用するのが現時点での対応でしょうか。\nなお、これに絡んで、このようなチケットもできています。\nSyntaxHighlighterを導入してみました。 ちょっとはみやすくなってますかね？ まだ、SyntaxHighlighterの設定を調べながら使っているので、コロコロ変わるかもしれないですが、気にしないでください。 ","date":1334592971,"dir":"post/2012/","id":"12d1e0cf7396dd33a9bbbca8da4cbc68","lang":"ja","lastmod":1334592971,"permalink":"https://blog.johtani.info/blog/2012/04/17/solr-3-6-0%E3%81%AEcjk%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%81%A8synonymfilterfactory%E3%81%AE%E6%B0%97%E3%81%AB%E3%81%AA%E3%82%8B%E7%82%B9/","publishdate":"2012-04-17T01:16:11+09:00","summary":"先日、Solr入門のサンプルschema.xmlの3.6.0対応版の作成をしていて、気になったことがあったので、 メモとして残しておきます。 S","tags":["solr"],"title":"Solr 3.6.0のCJKの設定とSynonymFilterFactoryの気になる点(Jugemより移植)"},{"contents":"先日の続きです。「Apache Solr入門」の2章から4章の説明について、Solr3.6.0で動作させる時の変更点を以下に書いていきます。 なお、前回も説明しましたが、3.6.0からKuromojiという形態素解析器がSolrに同梱されるようになりました。 これから説明する2章の変更点の手順ですが、Kuromojiとlucene-gosenそれぞれの利用方法について説明します。 添付のschema.xmlについては、基本的にKuromojiを利用する形に変更してあります。 それに加えて、lucene-gosen用のフィールドを別途追加で定義しました。 これらのフィールド名については、次の表の用になります。 適宜、書籍のフィールド名と置き換えながら読み進めたり、試したりしてください。\nKuromojiフィールド lucene-gosenフィールド title title_gosen author auther_gosen summary summary_gosen intended_reader intended_reader_gosen from_author from_author_gosen toc toc_gosen 2章 2.1.3 schema.xmlのバージョン（27ページ） Solr3.xではschema.xmlのファイルの最新バージョンは**1.5**になっています。\n2.2.3 代表的なトークナイザ（35ページ） solrbook.analysis.SenTokenizerFactoryは必要ありません。 Solr 3.6.0からはKuromojiと呼ばれる形態素解析器が用意されています。 solr.JapaneseTokenizerFactoryがそれに該当します。 これとは別に、lucene-gosenを利用する場合、Solr向けのトークナイザが用意されています。 solr.GosenTokenizerFactoryがそれに該当します。\n2.2.4 代表的なトークンフィルタ（37ページ） 以下の2つについてはKuromojiが同等のトークンフィルタを提供しています。 また、lucene-gosenを利用する場合は、lucene-gosenに同等のトークンフィルタが存在します。\nsolrbook.analysis.KatakanaStemFilterFactory solrbook.analysis.POSFilterFactory 次のものがSolr 3.6.0に用意されているので、こちらを利用します。\nsolr.JapaneseKatakanaStemFilterFactory solr.JapanesePartOfSpeechStopFilterFactory それぞれ、次のものがlucene-gosenにあるので、こちらを利用します。\nsolr.GosenKatakanaStemFilterFactory solr.GosenPartOfSpeechStopFilterFactory 2章向けのschema.xmlはこちらです。その他のtxtファイルについては、特に変更はありません。\n3,4章は特に変更はありません。Solrの起動の仕方にだけ注意してください。（-Dsen.homeは必要ありません）\n以上が4章までの修正点になります。\n昨日に引き続き、眠い目をこすりながら修正したので、おかしいかも。 動かない、意味がわからないなどあれば、コメントorツイートいただければと思います。\n2012/06/14提供しているschema.xmlに関して修正を加えました。こちらの記事で説明しているautoGeneratePhraseQueriesの値をtext_gosen、text_cjkのフィールドに対してtrueを設定する記述を追記しました。\n","date":1334339880,"dir":"post/2012/","id":"d77cdb466c5063b99c5aea58e6da4d32","lang":"ja","lastmod":1334339880,"permalink":"https://blog.johtani.info/blog/2012/04/14/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C2%E7%AB%A04%E7%AB%A0/","publishdate":"2012-04-14T02:58:00+09:00","summary":"先日の続きです。「Apache Solr入門」の2章から4章の説明について、Solr3.6.0で動作させる時の変更点を以下に書いていきます。 な","tags":["solr"],"title":"「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（2章～4章）(Jugemより移植)"},{"contents":"以前より、アナウンスしていた、Kuromojiという日本語形態素解析が含まれるLucene/Solr 3.6.0がリリースされました。\n以下、各リリース内容について簡単に説明されているページへのリンクです。\nSolrリリースのお知らせ\nLuceneリリースのお知らせ\nSolr 3.6.0の変更の目玉は各言語のAnalyzer/Tokenizerの設定がexampleのschema.xmlに含まれるようになったことです。 Kuromojiという日本語用の形態素解析器もexampleを起動すればすぐに利用できる形になっています。 Kuromojiを利用する場合は、exampleのschema.xmlが参考になるでしょう。\nあと、大きな変更は、Ivyに対応した点です。ソースをダウンロードするとわかりますが、依存するjarファイルが含まれない形に変更されています。 SVNからチェックアウトした場合も同様です。ビルドにはネットワークに接続している環境が必要になりました。\nまた、このリリースに合わせて、以前書いた「Apache Solr入門」のサンプルについての記事も変更が必要かと思い、 前回の記事をベースに以下に変更した記事を書いたので、参考にしてください。 今回は、Kuromojiという日本語形態素解析がデフォルトで含まれるようになったので、 Kuromojiの利用方法とあわせて、lucene-gosenの利用方法も記載します。 サンプルのschema.xmlについては、Kuromoji、lucene-gosenが同時に利用できる形のものを用意しました。\nサンプルのschema.xmlを最新版（Solr 3.6 + lucene-gosen-2.0.0-ipadic）のものを用意しました。 なお、あくまでも、3.xでlucene-gosenを利用する場合の「Apache Solr入門」のサンプルプログラムの変更点（とりあえず、4章まで）の違いについて記述します。 申し訳ございませんが、1.4と3.xの違いについての説明はここでは行いません。\n以下では、各章でschema.xmlに関連する記載のある部分を抜粋して、変更点と変更したschema.xmlのリンクを用意しました。参考にしてもらえればと思います。\n1章 1.6.1 N-gram（17ページ） 1.6.1の手順に変更はありません。 サンプルプログラムが入っているZip「solrbook.zip」のintroduction/ngram/schema.xmlファイルの代わりに こちらのschema.xmlを利用してください。 ※なお、Solr 3.6.0から、SOLR_HOME/example/solr/conf/schema.xmlにデフォルトでN-gramで利用しているCJKTokenizerの設定が入るようになっています。 （実際にはCJKTokenizerではなく、CJKBigramFilterとCJKWidthFilterに変更されています。）\n1.6.2 形態素解析（18ページ～20ページ中盤まで） CJKと同様、exampleにKuromojiを利用した設定がすでに記述されています。text_jaというフィールドタイプになります。書籍の21ページ1行目に記載のある、 「Field」のテキストボックスに入力する文字列を「text_ja」とすると、Kuromojiを利用した形態素解析結果が表示されます。exampleですでに幾つかのフィルタも設定されているため、書籍の出力結果とは異なる表示となるはずです。\nlucene-gosenを利用する場合は手順が大きく変わります。 Senを利用する場合、Senの辞書のビルド、Senのjarファイルの配置、Senを利用するためのTokenizerクラスを含んだサンプルjarの配置という作業があります。 lucene-gosenではコンパイル済みの辞書がjarファイルに含まれています。 また、Solr向けのTokenizerもlucene-gosenのjarファイルに含まれています。 lucene-gosenを利用して形態素解析を体験するための手順は次の流れになります。 なお、schema.xmlについては上記N-gramでダウンロードしたschema.xmlに形態素解析の設定もあわせて記載してあります。\njarファイル（lucene-gosen-2.0.0-ipadic.jar）をダウンロードして、$SOLR/example/solr/lib（libディレクトリがない場合は作成）にコピーします。 コピーが終わりましたら、次のように$SOLR/exampleディレクトリでSolrを起動します。 （-Dsen.homeは必要なし）\n$ java -jar start.jar あとは、書籍の記述にしたがって管理画面のAnalysis画面で動作を確認します。 ほぼ、図1-6と同じ結果になっていると思います。 （lucene-gosenで出力される情報には本書のサンプルよりも多くの情報が含まれています。また、サンプルでは、形態素解析の後の単語に基本形を採用しているため、「な」が「だ」として出力されています。基本形を出力する場合は後述するこちらで紹介したTokenFilterを利用すれば可能です。）\n2章については後日説明することにします（眠くなってきた。。。）\n動作しないなどあれば、コメントください。\n2012/06/14追記提供しているschema.xmlに関して修正を加えました。こちらの記事で説明しているautoGeneratePhraseQueriesの値をtext_gosen、text_cjkのフィールドに対してtrueを設定する記述を追記しました。\n","date":1334339100,"dir":"post/2012/","id":"904b07170a0ce481b7491e7fecce4f79","lang":"ja","lastmod":1334339100,"permalink":"https://blog.johtani.info/blog/2012/04/14/lucene-solr-3-6-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9---apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0/","publishdate":"2012-04-14T02:45:00+09:00","summary":"以前より、アナウンスしていた、Kuromojiという日本語形態素解析が含まれるLucene/Solr 3.6.0がリリースされました。 以下、各","tags":["solr"],"title":"Lucene/Solr 3.6.0リリース / 「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（1章）(Jugemより移植)"},{"contents":"Twitterでこのブログ流れてきて、気になったので、流し読みして簡単にメモ。 Amazonのサービスでスケールする検索サービスみたい。\n主に、機能面です。価格とかはみてないです。\nデータと検索トラフィックに対して自動でスケール（※automaticってのがどういう感じかは調べてないです） CloudSearch APIsでアクセス可能。AWS管理コンソールからオペレーションできる。コマンドツールもある データ登録にHTTPSも使えますよ。データ形式はJSON、XML、SDF（Search Document Format）と呼ばれるものに準拠したもの near real-timeで検索可能になる。RAMにインデックスを保持して更新処理が早くなる（Lucene/Solrと一緒か？） ステミングとかストップワードの設定変えたらre-index ファセット、フィールド指定検索が可能。（ファセットはファセットクエリみたいなのもできるのかな？） データ量が増えたら、サーチインスタンスを追加するか、インスタンスタイプを大きくしてスケールする？ トラフィックが増えたら新しいインスタンスにデータをレプリケートしてインスタンスを追加する 簡単に実現できるよ。ファセット検索、全文検索、And/OR検索式、ランキングのカスタマイズ、フィールド指定ソート、フィールド指定検索、テキスト処理オプション（ストップワード、類義語、ステミングのような） ここから詳細のドキュメントが見れるみたいなので、また、見てみます。\nあと、WikipediaをCloudSearchで動かしてるデモとそれに関する記事もあるみたいです。これも暇を見つけて眺めてみます。\n","date":1334241069,"dir":"post/2012/","id":"bed3b7fcc1294e23639057435ac8756a","lang":"ja","lastmod":1334241069,"permalink":"https://blog.johtani.info/blog/2012/04/12/%E3%83%A1%E3%83%A2amazon-cloudsearch%E3%81%8C%E5%87%BA%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F%E3%82%88/","publishdate":"2012-04-12T23:31:09+09:00","summary":"Twitterでこのブログ流れてきて、気になったので、流し読みして簡単にメモ。 Amazonのサービスでスケールする検索サービスみたい。 主に、","tags":["備忘録"],"title":"【メモ】Amazon CloudSearchが出てきましたよ(Jugemより移植)"},{"contents":"JavaOne Tokyo 2012に参加してきました。 4/4-4/5の2日間開催されていたのですが、子供が体調を崩してしまい、4/5のみの参加となりました。 4/4はTwitterのTLを眺めて、羨ましがってました。\n7年ぶりに日本で開催されたJavaOneみたいです。 そういえば、7年前くらいに参加した記憶があるなぁと。\n会場入りして最初の感想は年齢層が高いなぁと。 最近、勉強会によく顔を出すようになったのですが、勉強会とは年齢層が少し異なりました。 まぁ、私も年齢層を上げている一人ではあるのですが。。。 Javaも熟成してきてるなぁというのが最初の感想でした。 あと、思ったよりもスーツ率は低かったと思いました。（5割はいましたが） 一番違和感を感じたのは、会場の所々の色が「赤い」ことです。。。\n以下は私が参加したセッションのカンタンな感想です。\nJava EE6 Modeling　JS2-01　#jt12_s201\nJavaEEから離れてはや数年。私が関わっていた頃はEJB2.0が出たくらいのタイミングだったので、 色々と変わってきているなぁというのが第一印象です。 CDI、Singleton EJBなど、知らない単語もちらほらと。 earではなく、warファイル1つで済む、jQueryをリソースjarとしてパッケージングしてwarファイルに入れられるなどは簡易になっていいなぁと。 web.xmlがアノテーションで記述できて要らなくなるという話は一長一短だと思いました。 一覧性があるからいいと思うこともあるので。 中国の方？の英語だったので少し特徴的でした。すこしは頑張ってみたものの、やはり同時通訳を聞いてしまって反省しています。。。\nマルチコアCPU時代のJavaプログラミング　JS2-14　#jt12_s214\nF社の方が実際に経験されてきた性能関連のプログラミングについての話でした。 現時点のJavaでマルチコアCPUで気をつけるべきプログラミングの観点をわかりやすく説明されたいいセッションでした。 詳細は下のメモを見ていただけるといいですが、色々とプログラミングで気をつけるべき点を説明されていました。 いいおさらいになりましたし、忘れていることや知らないこともあって勉強になりました。 TLでも見かけましたが、モダンJavaプログラミングみたいな、今のJavaでのプログラミングの気をつけるべき点を書いた書籍があるといいかもなぁと思いました。 あと、もうひとつ私が好印象だと思ったのは、F社の製品の紹介などがなかったからかもしれませんｗ\nサービス維持・発展を踏まえた楽天オークションのJava EEによる開発と運用　JS2-23　#jt12_s223\n楽天オークションの開発をサれている方の立ち上げから現在に至るまでの開発メンバーの管理の仕方や 実際に利用している開発手法、気をつけている点のお話です。 スライドに書いてあること以外のことを発表者の方が話をされており、もう少し、喋る内容に関連した図などを入れてもらえるとわかりやすかったかもしれません。 あとは、WebLogicの管理画面が使いやすくていいという話のあとに、GlassFishに移行していますという話があったりと、少し「？」が浮かぶ部分がありました。。。\nJSR 353: Java API for JSON Processing　JS2-33　#jt12_s233\n最近、Twitterで遊んでもらっている（勝手に絡んでいるだけという話も。。。）@yusukeyさんの発表です。 結構な数の立ち見が出るほどの盛況ぶりで、発表者の@yusukeyさんもびっくりしていました。 JSRがどういった形で実際の仕様として公開されていくのかという話がわかりやすく紹介されていて勉強になりました。 所々で笑いが入るなど、さすがの安定感でした。立ち見が出るはずです。 ようやく、JavaもJSONに関する処理を仕様として取り入れようとしているのはいい傾向かと。 ※残念ながら資料は公開されないようです。\nUI Controls and Charts: Drag-and-Drop, Filtering, Sorting, Table Hookup with Charts　JS2-42　#jt12_s242\n最近、Chartに興味を持っていたので、登録したセッションです。 内容としてはJavaFXのコンポーネントをリストアップして紹介していくというお話でした。 グラフ（Chart）周りも数種類が用意されるようです。 JavaFXをあまり知らないのですが、Swingをすこしやっていたのでなんとかついていくことが出来ました。 発表者の方が、実際にJavaFX内部の実装を行われている方だったようで、QAでいくつかこんなコンポーネントはないのか？という質問に、「私のPCでは動いているのですが、ドキュメントなどの整備が追いついていないので公開できていないです」という回答が出て、なかなか大変なのだなぁとｗ Chartに関しては、グラフの重ね合わせなどがまだできないということで、JFreeChartを触ったことがある身としてはすこし物足りなさそうだなぁというのが印象です。\nLearn how the JVM is fundamental to our architecture.　BoF2-03 #jt12_b203\n今回JavaOneに参加した一番の理由がこのセッションです。 Twitterのアーキテクチャに関するセッションでした。 思った以上に濃い内容で、ツイートしたデータがどんな流れで登録されるのか、登録されたデータを各ユーザのTimelineにどのようにアクセスして表示しているのかが説明されました。 今回は主にFinagleについての話でしたが、非同期処理をどのように活用しているかというお話でした。 負荷分散を行なっているポイントやキャッシュについての考え方などです。 メモを取るのに夢中になってしまい、英語をヒアリングするという目的を見失ってしまいましたが。。。 期待以上の話が聞けて満足しています。\nパネルディスカッション\n最後はJavaに関連するコミュニティを運営されている方々のコミュニティ運営に関するディスカッションです。 コミュニティの運営の苦労している点や、心がけている点など、運営も大変そうだなぁと。 どうしても長くやっているとメンバーが固定化してしまうという話なども出ていました。 これは難しいですよね。会社も同じことが言えますし。 一番印象に残ったのは桜庭さんの「動くものが作れるのが楽しい」という一言でした。 エンジニアをやってるのは確かにそこが面白いからだなぁと。最近忘れかけているので、もっと色々と作っていきたいですね。\n以上がカンタンな感想です。 少し残念なのですが、事前に参加登録していたセッションについては、マイページと呼ばれるところから資料がダウンロードできるものもあるみたいですが、参加登録してないものについてはダウンロードが出来ない様でした。（4/6現在） 参加できなかったセッションの資料こそ見たいと思うのが普通だと思うのですが、どうでしょう？そのうちどこかに公開されるのかなぁ。\n以下は、いつもの通り個人のメモです。\n場所：六本木ヒルズ　アカデミーヒルズ49F 日時：2012/04/05 ○Java EE6 Modeling　JS2-01　#jt12_s201 スーツ禁止。Eva好き？ ・特徴 Web Profile Pruing POJO、Annotation、Less XML Java EE6の半分のAPIは変更なし。新規が11% ・JavaEE6 Web Profile CDI、Interceptors、JSR 250 Singleton EJB JPAはEntityBeanの代わりかな？ ・パッケージングがearではなく、war一つで済むように。 war（ウォーファイル） web.xmlはアノテーションで行えるようになり、要らなくなる。 ◯マルチコアCPU時代のJavaプログラミング　JS2-14　#jt12_s214 HotSpotVM依存のお話ですよ。 ・GCとか ・java.util.concurrent.ForkJoinPool デフォルト並列数は論理CPU数 ・メモリアロケーション TLABが非効率に。先にある程度大きめにスレッドに割り当てを行うため、 スレッド数が上がるとTLABが非効率になる-\u0026gt;Eden全体では未使用領域があるんだけどGC発生とか ・JNIでの問題 GetStringCriticalとReleaseStringCritical間はGCが抑止されるため。 ・無意識のロック HashTableやStringBufferなど。 String#getBytes()も。 InetAddress#getAllByName()が内部でキャッシュを持ってる＝ロック File#renameTo()も内部でキャッシュ（ExpiringCache）持ってる。 Javaでは時間がかかる処理にはキャッシュを利用するという仕組みなので。スレッド数を増加させる場合は注意が必要 ・フェアネスロック lock = new Object(); for (int i=0;i\u0026lt;100;i++0{ synchronized(lock){ System.out.println(\u0026#34;i=\u0026#34;+i+\u0026#34;tid=\u0026#34;+Thread.currentThread().getId()); } } 上記を実行してもかたよることがあるよ。＝フェアじゃない モニターによるスレッド割り当ての説明。 RentrantLockでフェアネスになるよ。 ・性能分析 println()で区間分析。複数スレッドで実行したら実行時間にずれが。 println内部でもsynchronizedを利用している。＝ロックのせいで処理時間が遅くなるスレッドが出てきたりする。 JVMTIで性能分析する場合RawMonitorEnter,RawMonitorExitでロックとりあいなるのでもマルチスレッッドだと正しい値がでない。GetThreadLocalStrage使え。 ・まとめ： ハードウェア更改時にプログラムの変更が必要になることもあるよ。 わずかのロックが命取りに（ロックをあんまり使わない、無意識なロックを見極めなさい） ロックポリシーの選択（レスポンス重視なのか、スループット重視なのか） QA Q：事例が合ったという話でしたが、コードの修正しかないんですか？ A：はい。やっぱり治すのがいいです。あとは、チューニングですが。。。 Q：ReentrantLockが昔はスレッドダンプにでなかったのですが、今は？ A：今は出ます。 Q：各世代とJavaのバージョンのマッピングは？ A：第3世代が1.5くらいから。第2世代が1.3とか1.4？ ◯サービス維持・発展を踏まえた楽天オークションのJava EEによる開発と運用　JS2-23　#jt12_s223 ・短期で人材が参加できるようにしているというお話 ・楽天オークションの成り立ち（郵政とdocomoと楽天） ・商品、コミュニティ系（出品とか検索とか）と流通系（入出金、配送など）の2軸 ・メンバー30人くらい ミドルエンジニア エンジニア プロデューサー ・楽天市場をベースとして機能追加 ・巨大でリリースが大変に。 ・この5年で機能分解して機能ごとのリリースをめざして改善している ・JavaEEを使う理由 WebLogic上にバッチが動いているなどの仕組みをしている？ 管理機能が充実している（WebLogic） ・GlassFishへ移行中 あれ？Weblogicの管理機能がいいんじゃなかったっけ？ EJB実装はWebLogicに依存してるのでWebLogicもバージョンアップしてる。 ※メモはここまで。電池の持ちを気にして ◯ JSR 353: Java API for JSON Processing　JS2-33　#jt12_s233 ・JSONとは JavaScript Object Notation 「軽量な」データ交換フォーマット ・JSON仕様のグラフ ・XMLもあるのになんで？ シンプルで可読性が高い 属性がなく、複雑なスキーマ仕様がない。 ・コンパクト ・Twitter、GoogleMaps、YahooWebServicesなど ・JCP、JSRのお話 JSRの役割とか。 リファレンス実装の話。 ・JSR-353 http://jcp.org/en/jsr/detail?id=353 StAXやDOMに対応するよ。 ・ゴールではないもの JSONをJavaのドメインオブジェクトにバインドするとかもどすとか。 ・メンバー @yusukeyも一人 ・参加になったきっかけ 2011/10にTwitterがJCPに参加 2012/12/6にJSON JSR提出 年越しに採択 @yusukey「これTwitterで重要じゃない？」 @cra　「やりましょう」 ・JSRのコミュニケーション 世界各地の人なので、基本メールベース（今は自己紹介したくらい。。） ・既存のJSONライブラリ json.org、jackson、google-gson ・なんで、いろいろあるのにJSR？ 標準化、クラスパスにデフォ、シンプル、ライセンスで悩まないとか。 ・ロードマップ エキスパートグループ作成→アーリードラフト→パブリックレビュー→ファイナルリリース いま、アーリードラフト ・最新仕様 javax.json.* javax.json.spi.* javax.json.stream.* javax.json.tree.* メソッドチェインできるみたい。 JsonObject.create(reader);みたい JsonObject obj = …; JsonWriter writer = obj.accept(writer.) ・改善案 JSON***にしたいな。 spiはらないんじゃないかな？（いま、一個しか無い） treeもいらないんじゃないかな？（そんなに増えないし） parseじゃないかな？ メソッド追加（asStringで文字列化とか、create(String)とか） QA Q：JSONのスキーマ決めないの？バリデータとか A：JSONスキーマはあんまりもてはやされてない。一応あるのはある。 さすがの安定感。適宜笑いが入ってて楽しかったです。 ◯UI Controls and Charts: Drag-and-Drop, Filtering, Sorting, Table Hookup with Charts　JS2-42　#jt12_s242 ◯JavaFX 2.0のControls ◯Label、Button、ToggleButton、RadioButton、Hyperlink、CheckBox ◯Slider、ScrollBar、ScrollPane、ProgressIndicator、ProgressBar ◯TextField、PasswordField、TextArea ◯新しい機能 TitledPaneとAccordion TabPaneとSplitPane ◯Charts XYChartとPieChart XYChartにはLineChart、AreaChart、BarChart、ScatterChart、BubbleChartがある。 ◯Menu MenuItemの下に色々ある。 CheckMenuItem、RadioMenuItem、CustomMenuItem（SeparatorMenuItemとか) ◯ChoiceBox、ContextMenu、ToolTip ◯ListView ◯2.1の新機能 ComboBox、http://fxexperience.com/2012/03/new-in-javafx-2-1-combobox/ StackedBarChart、 StackedAreaChart MenuBarのMac OSへの対応（窓の中じゃなく、画面上部にちゃんと出る。） LCD Text QA： Q：テキストエリアの日本語入力とかは？ A：JavaFX3.0で対応 Q：FXML（Scene Builder）を使ってコードが生成されるのか？ A：ドラッグ・アンド・ドロップでやる場合はScene Builderでもできるでしょう。私はNetBeansとかでやりますけどね。 Q：Dialogはいつ対応されるんでしょうか？ A：私は使ってるんですけど、JavaFXに入れてもらえませんｗコードは出来てますｗ Q：Chartがありますが、pngやsvgでの出力は可能？ A：できません。そのうちできるかも。 Q：Chartの結合はできる？Axisの時間を便利に使うツールはありますか？ A：できないです。ありません。 Q：FX2.0でカスタムコントロール作るの大変？ A：私のマシンでは動いてるんですがｗ Q：ChartにCSSを適用することは可能？ A：可能です。データはJavaから出力されたものだけですけどね。 Q：JavaFX2.0の起動速度が上がったけど、どういう仕組？ A：私は上の方のエンジニアなのでよくわからないですが、GPUをうまく使ってるみたいです。 ◯Learn how the JVM is fundamental to our architecture.　BoF2-03 #jt12_b203 Java、Scala、Linuxのカーネルまで担当してます。 ・Twitterのアーキテクチャ ・スパイクが急にあがる場合にも対応できるスケールの話。 なでしこ、#バルス、大震災など ・Twitterはプラットフォーム ・最上位層：HTTP Proxy（Routing） ・中層：Twitter App（Models/Biz Objects、Composition） UserService、TweetService、TimelineServiceに分解（Models/Biz Objects） API（Composition） ・最下層：TimelineStorage、TweetStorage、SocialGraph、UserStorage（Storage/Retrieval） ・NEEDS サーバ負荷をハンドルできる必要がある。 言語のフレキシビリティ（JavaとかScalaとか） 成熟したコンカレンシーモデル ・Java が提供してるもの 開発者のエコシステムが素晴らしい。例：Nettyを使っている。Non-blocking I/O world class JITとコンカレンシーモデル メモリ管理 利点：メモリ管理を意識しなくていい 課題：GC。OpenJDKのコミュニティで参加してる。 複数の言語が実行可能な環境 ・OpenJDKについて ・Finagleのお話。 Netty上に作られた非同期なRPCサーバクライアントのライブラリ http://twitter.gthub.com/finagle/ ・TimelineServiceのお話 340M/day 10K/sec（イベント時） ・ツイートが入ってくる仕組み HTTP Proxy → tweet API → queue → tweet daemon → fanout （social graph）→ delivery → timeline cache → redis ・fanout 4000フォロワーごとにdeliveryにツイートが渡される。 ・Timelineを見る仕組み HTTP Proxy → timeline API（user service、） →timeline service →timeline cache ・timeline、tweets、users ・timeline serviceとtimeline cacheの関係 Finagleで負荷分散している ・timeline serviceからtimeline cacheへのリクエストを監視して、 高頻度のリクエストについては、timeline serviceのin-process cacheに入れる仕組み ・Service[Request, Response] Scalaの記述 service(request).onSuccess {response =\u0026gt; println(\u0026#34;got response! \u0026#34; + response) } ・Finagleのコンポーネント コネクション管理 プロトコルデコード　ThriftでService以降がつながってる。 分散トレース　オーバーヘッドを抑えて全体を監視（RPCトレース（呼び出しと処理時間のタイムラインチャート）） サービスディスカバリ　observability ◯パネルディスカッション ・JGGUG、JRuby、Scala、Groovyのコミュニティ運営に関係している方々によるディスカッション。 ","date":1333698660,"dir":"post/2012/","id":"56d5711303378bd333ddb611a53ece94","lang":"ja","lastmod":1333698660,"permalink":"https://blog.johtani.info/blog/2012/04/06/java-one-tokyo-2012-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-javaonejp/","publishdate":"2012-04-06T16:51:00+09:00","summary":"JavaOne Tokyo 2012に参加してきました。 4/4-4/5の2日間開催されていたのですが、子供が体調を崩してしまい、4/5のみの参加となりました。 4/4","tags":["勉強会"],"title":"Java One Tokyo 2012 に参加しました。#JavaOneJp(Jugemより移植)"},{"contents":"先日、2.0.0リリースの記事にも記載しましたが、Java7でテストケースが失敗する問題がありました。\n@haruyamaさんと@hideaki_tさんの協力により問題を解消し、trunkと4xブランチにコミットしました。\nissueにも記載しましたが、Java6からJava7にバージョンアップするタイミングで変更されたUnicodeのバージョンが原因でした。 Java6ではUnicodeのバージョンが4.0です。Java7ではUnicodeのバージョンが6.0に変更されています。 今回の問題は「・」（0x30FB）の文字列のCharacter.getType()がCONNECTOR_PUNCTUATIONからOTHER_PUNCTUATIONに変更されたのが原因です。（この変更自体はUnicode 4.1で変更されたみたい） カタカナ文字種の判別をlucene-gosenのnet.java.sen.tokenizers.ja.JapaneseTokenizerのgetCharClass(char c)メソッドで行なっています。 修正前は、ここで、charの範囲が0x30A0～0x30FFにある文字でかつ、Character.getType()がCONNECTOR_PUNCTUATIONでないものがカタカナとして判別されていました。 issueの添付ファイルにJava6とJava7で上記範囲の文字のCharacter.getType()のリストを生成して、該当する文字を探した所、「・」（0x30FB）のみであることがわかりました。 ということで、このコードの意図としては、「・」はカタカナではないと判別したかったのだと。 上記の確認を行えたので、ソースコードを修正してコミットしました。 2.0.1としてリリースするかは、Issue29のボリュームを見て考えますので、もう少しお待ちください。\n参考にしたサイト： JavaSE 7でメソッド名に使えなくなった文字 UNICODE CHARACTER DATABASEのHistory\n","date":1333552800,"dir":"post/2012/","id":"c7937b6b4bde2a96191dc31db913e1ab","lang":"ja","lastmod":1333552800,"permalink":"https://blog.johtani.info/blog/2012/04/05/lucene-gosen%E3%81%AEjava7%E3%81%A7%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E5%A4%B1%E6%95%97%E5%95%8F%E9%A1%8C%E3%81%AE%E5%AF%BE%E5%BF%9C/","publishdate":"2012-04-05T00:20:00+09:00","summary":"先日、2.0.0リリースの記事にも記載しましたが、Java7でテストケースが失敗する問題がありました。 @haruyamaさんと@hideak","tags":["lucene-gosen"],"title":"lucene-gosenのJava7でのテスト失敗問題の対応(Jugemより移植)"},{"contents":"先日、宣言したとおり、lucene-gosenのパッケージ名＋クラス名の変更を行ったlucene-gosen 2.0.0をリリースしました。 Lucene/Solr 3.6.0のリリースを待つつもりだったのですが、なかなか出ないので先にリリースを行いました。 現時点では、branches/4xについては、パッケージ名、クラス名の修正が追いついていません。 明日までに4xブランチについても修正を反映する予定です。\n参考までに、1.2.1から2.0.0への変更点について以下にまとめました。 また、変更に伴い、Solrのschema.xmlに記述するクラス名も変更になります。 schema.xmlのサンプルについてはこちらをご覧下さい。\n変更点 まずは、パッケージ名の変更点です。 左が旧パッケージ名、右が新パッケージ名となります。\n旧パッケージ名 新パッケージ名 org.apache.lucene.analysis.ja org.apache.lucene.analysis.gosen org.apache.lucene.analysis.ja.tokenAttributes org.apache.lucene.analysis.gosen.tokenAttributes また、パッケージ名とは別に、以下のクラス名も変更になっています。 まずは、org.apache.lucene.analysis.gosenのクラス名の変更点です。\n旧クラス名 新クラス名 JapaneseAnalyzer.java GosenAnalyzer.java JapaneseBasicFormFilter.java GosenBasicFormFilter.java JapaneseKatakanaStemFilter.java GosenKatakanaStemFilter.java JapanesePartOfSpeechKeepFilter.java GosenPartOfSpeechKeepFilter.java JapanesePartOfSpeechStopFilter.java GosenPartOfSpeechStopFilter.java JapanesePunctuationFilter.java GosenPunctuationFilter.java なし GosenReadingsFormFilter.java JapaneseTokenizer.java GosenTokenizer.java JapaneseWidthFilter.java GosenWidthFilter.java 次は**org.apache.solr.analysis**です。 旧クラス名 新クラス名 JapaneseBasicFormFilterFactory.java GosenBasicFormFilterFactory.java JapaneseKatakanaStemFilterFactory.java GosenKatakanaStemFilterFactory.java JapanesePartOfSpeechKeepFilterFactory.java GosenPartOfSpeechKeepFilterFactory.java JapanesePartOfSpeechStopFilterFactory.java GosenPartOfSpeechStopFilterFactory.java JapanesePunctuationFilterFactory.java GosenPunctuationFilterFactory.java なし GosenReadingsFormFilterFactory.java JapaneseTokenizerFactory.java GosenTokenizerFactory.java JapaneseWidthFilterFactory.java GosenWidthFilterFactory.java また、上記クラスに関連するテストクラスの名前も変更になっています。\n以上がクラス名、パッケージ名の対応に関する修正ついてでした。\nまた、現在、Java7にてテストケースが失敗する問題が見つかっています。 こちらの問題の対応版についても近日中にリリースを行う予定です。\n問題点、質問などありましたら、コメントしていただくと回答いたします。\n2012-04-03追記 忘れてました、すみません。今回のリリースで、以下の機能が追加されています。\nAntのパラメータにproxy.user、proxy.passwordの追加 GosenReadingsFormFilterの追加 TokenAttributeの修正（PronunciationsAttributeImpl、ReadingsAttributeImpl） Antは認証が必要なプロキシ環境で辞書のビルドを実施するときにユーザ名、パスワードを指定できるようにしました。\nGosenReadingsFormFilterは単語を読みに変換するTokenFilterになります。 よみは、辞書に登録してある読みになります。オプションとして、romanizedが指定可能です。指定をすると、よみをローマ字に変換します。\nTokenAttributeの修正は、バグフィックスになります。Issueはこちらです。\n","date":1333362120,"dir":"post/2012/","id":"06731164684f90f33ce4017eca9d8ec1","lang":"ja","lastmod":1333362120,"permalink":"https://blog.johtani.info/blog/2012/04/02/%E9%87%8D%E8%A6%81lucene-gosen-2-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2012-04-02T19:22:00+09:00","summary":"先日、宣言したとおり、lucene-gosenのパッケージ名＋クラス名の変更を行ったlucene-gosen 2.0.0をリリースしました。 Lucene/Solr","tags":["lucene-gosen"],"title":"【重要】lucene-gosen 2.0.0リリース(Jugemより移植)"},{"contents":"lucene-gosenを利用して頂いてる皆様に連絡があります。\n連絡事項 次期lucene-gosenのリリース（2.0を予定）にて、org.apache系のパッケージ名および、クラス名の変更を行います。 Lucene/Solrの次期リリース版である3.6.0以降では、lucene-gosen 2.0（予定）を利用するようにしてください。\n経緯 Twitterでは少しずつツイートしていますが、Lucene/Solr 3.6から日本語の形態素解析器がLucene/Solrにて用意されることになりました。 ベースとなっているのは、Atilika社が開発したKuromojiという形態素解析器です。 Lucene/SolrにコントリビュートされたタイミングではKuromojiAnalyzerなど、Kuromojiという名称が残った形で取り込みが行われました。 その後、LUCENE-3909にて、Kuromojiではなく、一般的な名称（Japanese*）に変更する提案が行われました。 この提案で、luene-gosenが利用しているクラス名、パッケージ名と大半のクラスが衝突してしまうこととなりましす。 今後も、lucene-gosenを利用していただけるように、lucene-gosenのIssueを発行し、 現在、lucene-gosenのtrunkにてパッケージ名の変更及びクラス名の変更作業を行なっています。 正式にリリースするタイミングになりましたら、再度連絡いたします。\nブランチなどについて 現時点ではパッケージ名、クラス名の変更はリポジトリの以下のものについてのみ作業を行う予定です。\ntrunk branches/4x 現時点でのリリース版（1.2系）のソースについてはbranches/rel-1.2にて、これまで同様のクラス名、パッケージ名のまま変更を行いません。 1.2系についてはこちらをご覧下さい。\nまた、当ブログにて、提供しているSolr入門のサンプルに利用可能なschema.xmlなどの記事についてもLucene/Solr3.6がリリースされた際には再度修正して掲載いたします。 Kuromojiの利用方法もあわせて記載したいです。\n参考： lucene-gosenとKuromojiの機能などの比較についてはこちらを参考にしてください。\n","date":1332783540,"dir":"post/2012/","id":"f8327953a0f0b80011b939111807999a","lang":"ja","lastmod":1332783540,"permalink":"https://blog.johtani.info/blog/2012/03/27/%E9%87%8D%E8%A6%81lucene-gosen%E3%81%AE%E6%AC%A1%E6%9C%9F%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2012-03-27T02:39:00+09:00","summary":"lucene-gosenを利用して頂いてる皆様に連絡があります。 連絡事項 次期lucene-gosenのリリース（2.0を予定）にて、org.","tags":["lucene-gosen"],"title":"【重要】lucene-gosenの次期リリースについて(Jugemより移植)"},{"contents":"子供の寝かしつけしてたら、寝かしつけされてしまって、２時に目が覚めてしまいました。 TSUTAYAでCD借りてきてウォークマンに入れようと思っていたのに。。。 ということで、今作業してます。\nMBAを買う前から使っている、もう９年目のWindows自作デスクトップで基本的にはCDの取り込みをしています。 ファイルサーバ（BuffaloのTeraStation）がLionから接続できないというのと、 X-アプリで曲管理していたのでという理由です。 あと、ウォークマンなのでMac用のソフトがなかったりというのも理由です。\nで、眠い目をこすりながらWindowsマシンを起動すると、ネットワークにつながらないじゃないですか。。。 再起動してもダメでした。\nとなってしまったので、せっかく、譲ってもらったMac miniも活用しないといけないなと思い、iTunesでアルバムを取り込んでみています。 ここ数年はWAV形式でデータを取り込んでいたので、WAVでの取り込みを設定して、iTunesで取り込みました。\nとまぁ、ここまでやってから、件のWindows機を再度、再起動したらネットワークに繋がってしまいました。。。 なので、残りのCDはWindows機で取り込みしてます。 けど、そろそろこのPCも危なそうなので、データをサルベージして、Mac miniで作業できるようにしないとなぁ。 Macでウォークマンを運用している人はどうやってるんだろう？ ちなみに私が利用しているウォークマンはNW-A847です。 エンコードはWAV形式で取り込んで、X-アプリでウォークマンに入れています。 iTunes使ってる人は、アップルのロスレスエンコードをつかってるのかなぁ？ ということで、調査・検討したい項目はこんなところですか。\n調査：TeraStationにMacからつなぐ方法（Lionで利用できそうなソフトなにかないかな？） 調査：iTunesでウォークマンに曲転送（やってみればすぐわかるだろう。。。） 調査：iTunesの曲をCDに焼く方法（車で曲聞くのにCDだから） 検討：ファイルサーバのリプレース対象となる機種（ファイルサーバは導入してまだ５年だから余裕がないと買い換えない） 検討：iPodに鞍替え（Sony好きだし、ウォークマン好きだし、買ったばっかりだからまず無い選択肢） 検討：Mac miniにVirtualBox入れて、WindowsからX-アプリ使うとか。（ファイルサーバが見えるようになるかな？） 検討：Mac miniをWindowsとして運用（もったいなさすぎる気がする） とまぁ、まだ悩んでるだけで、取り留めもない事を書いて、しかも結論が出ないままですが、ご容赦ください。 ご意見、提案を大募集してます！！\n","date":1332618420,"dir":"post/2012/","id":"8b76101d185700a8efed148d8722d926","lang":"ja","lastmod":1332618420,"permalink":"https://blog.johtani.info/blog/2012/03/25/%E4%B9%85%E3%80%85%E3%81%ABmac-mini%E3%81%AE%E3%81%93%E3%81%A8%E3%81%A7%E3%82%82/","publishdate":"2012-03-25T04:47:00+09:00","summary":"子供の寝かしつけしてたら、寝かしつけされてしまって、２時に目が覚めてしまいました。 TSUTAYAでCD借りてきてウォークマンに入れようと思っ","tags":["備忘録"],"title":"久々にMac Miniのことでも(Jugemより移植)"},{"contents":"はい。またまた、Twitter API勉強会に参加してきました。（今回から開催回数の記載がなくなった？） 今回は直前でタイムテーブルが変わってしまう波乱がありましたが、個人的には楽しめる内容でした。 Twitterの国際化や形態素解析などの話が聞けたのがすごく面白かったです。 アーキテクチャや利用されている形態素解析器の話など、また、現状の問題点なども話が聞けました。 日々、進化しているんだなぁと。 残念ながら、発表者の方が懇親会にいらっしゃらなかったので、詳しく聞けませんでしたが、挨拶だけは出来ました。 実際のテスト環境や導入方法、A/Bテストとかやってるのかなど、ブログをかきながら色々と気になることが出てきてしまいますｗ 頭の回転がよくないので、話を聞いてる間は質問があんまり思い浮かばなかったなぁ。。。\nその他にも（使ったことなくてすみません。。。）「昼会」のサービスの話、他の言語でのTwitterの活用の話も聞けました。\n途中で帰ってしまいましたが、懇親会でも数人の方とお話できて、楽しかったです。 （今回の懇親会会場はちょっと人数の割に手狭だったかもなぁ）\n次回は4月末を予定しているようでした。今度こそ、利用規約の話になるんですかね？ 忙しさを見つつ、また参加しようかと思います。\nということで、いつものメモです。\n開催日時：2012/03/21 19:00 ～ 21:00場所：ハロー会議室shibuya Zusaarのページ\n◎Twitterの日本語検索、ハッシュタグについて　@keita_f\n◯アーキテクチャ ・Twitterバックエンドの国際化 Before 各言語ごとに独自実装。 After 共通テキスト処理ライブラリ：Penguin ・アーキテクチャ：検索 Firehose → ingester → Earlybird ⇔ Blender ← ユーザの検索 Firehose：ツイートの受信 ingester：ツイート解析 Earlybird：Luceneベースのインデクサ Blender： ・アーキテクチャ：トレンド TrendsはGeo（ユーザ位置情報）を利用してるっぽい。 Term Statisticsは過去ツイートからHadoopで頻出フレーズを解析する。 今頻出しているフレーズ＋過去頻出しているフレーズ ◯日本語関連 ・ツイートの言語判定 言語判定にはIndigenous Tweets（Kevin Scannell）をベースに実装。 ５０言語サポート、Javaで実装 ・文字種チェック ・エンコーディングチェック ・Ngram（the→英語、das→ドイツ語） 問題点： ２つ以上の言語が混じってる場合 絵文字が入ってる場合 Unicodeアルファベット ・形態素解析 日本語：Gomoku 中国語：LuceneのSmartCN その他：N-Gram 問題点： 形態素が小さすぎる →そのままだと細かすぎるので品詞情報を元に大きめに区切るようにしている iPhone4Sなどが数字で区切られる →ASCIIの数字とアルファベットは連結しなおす ・フレーズ抽出 他の言語もあったけど、キー入力間に合わず 日本語の場合： トークンに分割 トークンでNgramを生成 品詞情報を使ってフィルター 最初、最後が助詞はNG、接頭詞で終わるのはNG ・やりたい事はまだまだたくさん ・形態素解析の品質向上 辞書への単語追加 韓国語、タイ語のトークなイザー ・同義語、類義語、翻訳、音訳、略語などのサポート ・フレーズ・トピックのクラスタリング ・Sentiment Analysis ・日本語のできるエンジニア募集中ｗ QA Q：顔文字を手動で抜き出すと言われたんですが、どのくらいあるんでしょうか？　A：正規表現なので、なんとも言えませんが、パターンを Q：Gomokuの選択の理由は？ A：Javaだから。jarに辞書が入るから。スピードが出るから。 ◎ランチタイム共有サービス「昼会(http://www.hirukai.jp/)」のご紹介　@setomits\n◯前提 ・ネットワーキングは重要 ・出会いも重要 ・飲み会だとコスパが悪い ◯ランチだと ・金額が限られる ・必ず食べる ということで、昼会だ！ ◯画面でサービスの説明 パブリックな昼会、プライベートな昼会がある。 ◯なんでTwitter？ LinkedInのOAuthを使ったログイン検討してた。 ビジネス目的＋ 敷居が高いのでTwitterに変更 ◯Twitterのapiで利用しているものなど ◯ユーザの声 ・DMを使ってる＝自分からのDMが気持ち悪い APIの使用制限やフォローしてもらう必要があるのが辛い。 - スパムかと思った - 乗っ取られたかと思った。 - エンジニアからは、「まぁ、こうするよね」 ・OAuthについて - ユーザ登録しなくていいのは嬉しい - イベント参加のためにOAuthでの書き込み権限まで与えたくない ◯８ヶ月経って ・新しい出会いがあった ・昼会を開催する敷居が高い ＝なかなか使ってもらえない ◯今後の計画 募集中！ QA Q：AppEngineで月額どのくらい？ A：料金改定前：数千円/１ヶ月、料金改定後：２万円くらい/１ヶ月 処理数を減らして、現時点では数千円/１ヶ月に最適化した Q：夜会はないんですか？ A：設計していたら、出会い系サイト？になりそうなので、昼にした。 ドメイン的になぁ。まだ悩み中 Q：GAE特化したもの？AWSに移行できる作り？ A：できない作りです。（pythonで書いてます。） GAEが楽なので、移行可能な作りにするのがつらい。 ◎LT ◯Twitter 4 contact　@inda_re ・広告！アジャイルサムライの道場\n・問い合わせフォームをTwitterにしちゃう 今あるHTMLにフォームを入れる方法（MySQLとPHP） githubにサンプルあるよ。 ◯PerlのTwitterモジュールについて　@xtetsuji\n・前回出席したら、ムチャぶりが！ ・いまどきのPerl 進化してるよ、古い情報が検索で出てきてしまうのがネック ・perlbrewってのがある http://perlbrew.pl/ ・AnyEvent::Twitter::Streamをよく使ってます。 ・gistにサンプルあげてあるよ！ ◯KotlinでもTwitter4J　@ngsw_taro ・Kotlinの説明 ・以下のサイトでインストールしなくても動かせるよ！ http://kotlin-demo.jetbrains.com/ ・NULL安全 Nullを許容する型、許容しない型がある。 ・一応、Twitter4Jのサンプルも作ったけど、ブログ見てね http://d.hatena.ne.jp/ngsw_taro/\n◯締め Twitter API勉強会ではスピーカーを常に募集中です。登録はこちら！\n","date":1332343680,"dir":"post/2012/","id":"16b3c9445539e9274282a612dea354c2","lang":"ja","lastmod":1332343680,"permalink":"https://blog.johtani.info/blog/2012/03/22/%E7%AC%AC5%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%B8%8B%E8%B0%B7--twtr_hack/","publishdate":"2012-03-22T00:28:00+09:00","summary":"はい。またまた、Twitter API勉強会に参加してきました。（今回から開催回数の記載がなくなった？） 今回は直前でタイムテーブルが変わってし","tags":["勉強会"],"title":"第5回 Twitter API勉強会 @渋谷 #twtr_hack(Jugemより移植)"},{"contents":"TLで面白いと見かけて、Amazonで買ってしまいました。 SEやってるのに、つい最近Amazonを使い始めた軟弱者です。 それにしてもAmazon危険です。スマートフォンにAmazonの Androidアプリを入れたのですが、これがまた、レコメンドに面白そうな本が出てきて危険です。\n話がそれてしまいましたが、面白い本でした。 久々に、小説でも技術書でもない本を短期間で読みました。 「箱」と呼ばれる概念の中と外について、とある会社に転職した管理職の人が学んでいくという物語風の作りです。 いくつか、自分の経験にカブるシーンがあったので、サクサク読めました。 今までの自分になかった考えである「箱」という視点が得られたのがよかったです。\nただ、いくつか気になる点もあるので、また少し時間を開けてからサラっと流し読みしたいと思います。\nあと、すこしだけ、キリスト教チックな考え方でもあるかなぁと思う部分もありました。（キリスト教をちゃんと勉強してるわけではないので認識が間違ってるかもしれないです）\n人によっては共感出来なかったり、読みにくかったりすると思いますが、私は面白いと思った本でした。 なんとなく、人間関係に違和感を感じていることがある場合は目を通してみるといいかもしれません。\nTwitterで読み終えたというツイートをしたら、「自分を変える気づきの瞑想法」を読むとまた面白いですという＠ツイート（これがmentionの日本語の正式名称らしい？）を@ledsunいただきました。 箱に入る原理が別の視点で書かれているようです。 読んでみたいです。（本会過ぎてる気がするので、図書館で探そうかなぁ。。。）\n自分を変える気づきの瞑想法【増補改訂版】 自分を変える気づきの瞑想法【増補改訂版】 ","date":1332253920,"dir":"post/2012/","id":"ee623aaa99b429863f89da313fffed97","lang":"ja","lastmod":1332253920,"permalink":"https://blog.johtani.info/blog/2012/03/20/%E8%87%AA%E5%88%86%E3%81%AE%E5%B0%8F%E3%81%95%E3%81%AA%E7%AE%B1%E3%81%8B%E3%82%89%E8%84%B1%E5%87%BA%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-03-20T23:32:00+09:00","summary":"TLで面白いと見かけて、Amazonで買ってしまいました。 SEやってるのに、つい最近Amazonを使い始めた軟弱者です。 それにしてもAmaz","tags":["読書"],"title":"「自分の小さな「箱」から脱出する方法」を読みました。(Jugemより移植)"},{"contents":"えーと、ブログ更新してないなぁとふと思ったので。 １年前くらいからずーっと、つぶやいてましたが、やっとScalaを始めました。 長かった。。。 とある、サンプルデータを作成するので、ついでにScalaを勉強してしまえという感じで始めました。\nScalaで学ぶ関数脳入門を買ってもう１年以上経ってました。。。 とりあえず、CSVデータからInsert文を作ってます。 書籍を見ながら、四苦八苦してるところです。 今日は、csvファイルを読み込んで適当に出力した所で終了でした。 現状を忘れないようにというのと、いくつか気になった点があったので、備忘録のため上げておきます。\nscala IDE for Eclipseを利用（もっさりしてる） classとは別にobjectというものがある点に慣れない セミコロンいらないのに、ついつい打ってしまう usingを利用しようとしたが、Eclipseに怒られた（なんで？） メソッドの戻り値を省略出来る場合とできない場合がよくわかってない Javaが混ざる（ファイル出力にBufferedWriterを使う）のがまた戸惑う ということで、四苦八苦してますｗ ７つの言語、７つの世界も参考にしつつ、コップ本をパラパラしながら、ググって書くといった感じです。 Javaだととっくにできていると思うのですが、まだ、読み込んで出力できただけです。\n新しいものに触れるのは頭を使って面白いのですが、思い通りに行かず（とくにIDEがもっさりしてたり、上手く使えなかったり）イライラもしていますｗ まぁ、ちょっとずつ勉強していきます。\n（ほかにもいろいろやらないとなぁ。。。）\nScalaスケーラブルプログラミング第2版 Scalaスケーラブルプログラミング第2版 ","date":1331652421,"dir":"post/2012/","id":"116c9be6d760b4befa6d51ce9e96604c","lang":"ja","lastmod":1331652421,"permalink":"https://blog.johtani.info/blog/2012/03/14/scala%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-03-14T00:27:01+09:00","summary":"えーと、ブログ更新してないなぁとふと思ったので。 １年前くらいからずーっと、つぶやいてましたが、やっとScalaを始めました。 長かった。。。 と","tags":["Scala"],"title":"Scala始めました(Jugemより移植)"},{"contents":"森ビルに行ったことなかったので、参加してみました。 あと、最近まともにコーディングしてないので、そのへんを矯正するためにもと思って。 （まぁ、遊びに行きたかっただけなんですけどね）\nすこし遅刻して参加です。 会場は、Twitter Japanさんの@yakitoriでした。ここだけ、撮影可でした。 で、肝心のハッカソンの中身です（ハッカソン自体、初参加！）。 Twitter APIもTwitter4Jも触ったことがありません。 なので、ソファーに座ってMac Book AirでTwitter4Jのサンプルを眺めながら、とりあえず、Solrに流しこむってのを作ってみました。 今回、Solrに用意したのはlucene-gosenによる形態素解析を行うフィールドとあとは、Solrのexampleについてるダイナミックフィールドたちです。 Twitter4Jからどんなデータが取れるかわからないので、ダイナミックフィールドで型だけ指定してSolrを起動しておきます。 次に、Twitter4Jにあるsample()にてパブリックなツイートの1%を取得（適当なのがこれくらいしか思い浮かばなかったから）。 あとは、SolrJのStreamingUpdateSolrServerを利用して、流し込みです。 あんまり時間がなかった（準備とかウォーミングアップで時間かかった）ので、結局、Screan名とツイート本文を SolrInputDocumentに無理やり詰め込んで登録しただけでした。 ほかにも色々と情報が取れるはずなので、そのへんも格納してファセットとかで遊びたかったなぁ。 とまぁ、こんな感じでタイムアップです。（コードは大したことないので文章だけでｗ） 画面も用意出来なかったので、発表はSolrのダサい管理画面で検索でした。 次回は、もう少し中身を勉強して画面もbootstrapで作ってとかやってみたいですね。 あと、自己紹介スライドに書きましたが、Scalaから使ってみるのもやってみたいです。（その前に、Scalaに入門しないといけないんですけど。。。）\nということで、個人的にいろいろと反省点があるハッカソンでした。 反省点：\n立ち上がりに時間がかかった（普段からコーディングしてないから） Twitter4Jについて事前に勉強してない（ごめんなさい） 環境面が整備しきれてない Twitter API ポケットリファレンス（右の本）を忘れた。。。 スターウォーズのピザの箱の写真取り忘れた＞＜ 普段、コーディングをしていない仇が出てしまいました。 もっと、すぐにコーディングをできる環境、体質を日頃から鍛えておかないといけないなぁと。 （SolrやTwitter4JのJavaDocをオロオロしながら探すとか情けないです。。。）\n場所や雰囲気は全然問題ありませんでした。 ピザを@yusukeyさんからごちそうになったり、飲み物、お菓子が用意されていたりと至れり尽くせりでした。 iPadで音楽も流してくれてたし。 他のハッカソンに参加したことないので比較はできないですが、集中できてよかったです。 あと、ソファーでコーディングもなかなかいいなぁと実感出来ました。（初めて！） 人数的にもこのくらいのほうが話がしやすくていいかなぁと。発表も時間かからないですし。 ただ、帰り道に誰かが言っていましたが、「マラソンというよりは短距離走だったね」というのは否めないかなぁと。 時間は限られちゃうので、準備をしっかりしないとなぁと。 私としては、土日のハッカソンだと参加しづらいので、平日開催がうれしいのですが。 いやぁ、楽しかったです。みなさんの面白いネタも見れたし。（自分のやったのは普通すぎて少し恥ずかしかったです。。。） あと、GoogleDocsの使い方（自己紹介スライドとかアンケートの集計とか）も学べたのが収穫でした。 @yusukeyありがとうございます！ 次回もありそうなので、懲りずに参加しようかな。\nさて、他の方たちのブログやtogetterは@yusukeyさんのページからたどってくださいｗ。 第0回Twitterハッカソンを開催しました #twtr_hack\n今日購入したCD聴きながらブログ書いてます。 タワレコで視聴して購入したCDです。 なかなか大人な雰囲気でオススメです。 Heaven ","date":1331230200,"dir":"post/2012/","id":"4d6c95b0b3ea2ddb30fdd3edf3b82391","lang":"ja","lastmod":1331230200,"permalink":"https://blog.johtani.info/blog/2012/03/09/%E7%AC%AC0%E5%9B%9E-twitter-hack--twtr_hack-%E3%81%AB%E9%81%8A%E3%81%B3%E3%81%AB%E8%A1%8C%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-03-09T03:10:00+09:00","summary":"森ビルに行ったことなかったので、参加してみました。 あと、最近まともにコーディングしてないので、そのへんを矯正するためにもと思って。 （まぁ、遊","tags":["勉強会"],"title":"第0回 Twitter Hack #twtr_hack に遊びに行きました。(Jugemより移植)"},{"contents":" Clean Coder プロフェッショナルプログラマへの道 Clean Coderを読みました。 理由はTwitterで「Clean Code」がいい本だと流れてきたためです。 「Clean Code」はまだ読んでいないのですが、クリーンなコード（メンテナンスしやすく、修正などもやりやすいコード？）を書くために必要な話が書いてあるのだと思います。（まだ妄想）\nそして、何も考えずに、「Clean Code”r”」という本が新しく出ていたので、新しい方に手を出しました。 まぁ、軽い勘違いですｗ（コードの構造の話などは出てこなかったです。） それほど分厚くなく、軽く読めそうだということで読み進めると軽い衝撃を受けました。 Clean Coderはプロのプログラマとして、どのような意識を持つべきか、立ち居振る舞いをするべきかなどが書かれています。 「～したい」はまず守らない約束だという話、ユニットテストを書くことはプロとして当たり前の行為だ、目的意識を明確に持つことなどなど、耳の痛いことが色々と書かれています。 これは、著者の方（パンチカードのころからコーディングをされている！）の実体験を元に、失敗した経験から導きだされているようです。 ところどころ、古くてよくわからない話やちょっとだけしっくりこない表現（ビジネス、QAといった単語）もありましたが、概ねわかりやすい話でした。\n基本的にはアジャイルなスタイルの開発を行うプログラマ（設計書に基づいてコーディングするだけの人ではない）について書かれています。 この本を読んでいて、昨年、仕事をご一緒させていただいたRubyistの方たちの開発スタイルを思い出しました。 私よりもこの本に書かれているプロに近いなぁと。 ペアプロやったり、実装方法について相談していたりと。\n勘違いでしたが、良い本に出会えて本当によかったです。 私もこの本に書かれているようなチームでのプログラミングをやりたい、またなにかコーディングをしたいという気にさせてくれました。（「～したい」じゃダメって書いてあったのに。。。） 自分を戒めるためにも、定期的に読み返したい本です。 プログラマでいたい方、ある程度プログラミングができるようになってきた方にはぜひ読んでいただきたい本です。 （この流れで、アジャイルサムライやClean Codeを読んだら理解が深まりそうだなぁ）\n参考URL： 35歳定年説をブチ破れ！「Clean Coder プロフェッショナルプログラマへの道 Robert C. Martin」 - ledsunの日記 ","date":1330704840,"dir":"post/2012/","id":"10eb415a232ad4be7d05c57eb850036c","lang":"ja","lastmod":1330704840,"permalink":"https://blog.johtani.info/blog/2012/03/03/clean-coder%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A0/","publishdate":"2012-03-03T01:14:00+09:00","summary":"Clean Coder プロフェッショナルプログラマへの道 Clean Coderを読みました。 理由はTwitterで「Clean Code」がいい本だと流れてきたためです。","tags":["読書"],"title":"Clean Coderを読んだ(Jugemより移植)"},{"contents":" 親子で楽しめる 絵本で英語をはじめる本 Twitterでこの本について書かれたブログ記事が流れてきて、購入しました。\n最近、英語を身につけておいたほうがいいなと思うことが多々あり、子供にも英語を勉強してもらいたいなと思っていたところでした。 あとは、私自身が英語が苦手というのもあり、子供をダシにして勉強したいというのもありまして。。。 サラっと読んでみましたが、参考になりました。 特に「多読」というキーワードが面白かったです。こちらが元のようですが。 多読とは、文章を分析しないで大意を把握する読書法だそうです。\n辞書を引かずに楽しめるものを読む わかるところをつなげて読む 自分が面白いと思う本を選んで読む という原則があるようで、確かにいいなと思いました。 絵本だと絵が書かれているので、辞書を引かなくても想像できそうですし、楽しめそうだなぁと。 また、多読は先日読んだ、速読の本に書かれていた本の読み方にも通じるものがあるなと。（まだ、実践できてないんですけどね）\nどうしても英語を勉強させたい！、勉強しないと！と思ってしまいがちですが、この本にも書いてあるように楽に楽しんでやったほうがやっぱいいなぁと。 楽しくないと続かないですからねぇ（実際、何度も挫折してるし、押し付けられるとヤル気がなくなるので。。。）\nということで、実践してみようと思います。（平日は子供が寝てしまってから帰宅なので、まずは土日から）子供のためというよりは、自分の英語の勉強のために。 まずは、簡単な絵本を購入して。 この本の後半半分は、著者の方の感想や説明がついた、オススメの絵本50冊が書かれています。 英語の絵本を入手するのは、結構大変（実際に売ってる店もなかなかないし、手にとって見る機会も少ない）だと思うのですごく参考になりそうです。 いくつかピックアップして、あわよくば本屋で手にとってみようかと。なければ、Amazonで購入しようかなぁと思ってる所です。\n","date":1330186800,"dir":"post/2012/","id":"627a0c45dd07150343c81d856855590e","lang":"ja","lastmod":1330186800,"permalink":"https://blog.johtani.info/blog/2012/02/26/%E8%A6%AA%E5%AD%90%E3%81%A7%E6%A5%BD%E3%81%97%E3%82%81%E3%82%8B-%E7%B5%B5%E6%9C%AC%E3%81%A7%E8%8B%B1%E8%AA%9E%E3%82%92%E3%81%AF%E3%81%98%E3%82%81%E3%82%8B%E6%9C%AC/","publishdate":"2012-02-26T01:20:00+09:00","summary":"親子で楽しめる 絵本で英語をはじめる本 Twitterでこの本について書かれたブログ記事が流れてきて、購入しました。 最近、英語を身につけておいた","tags":["読書"],"title":"親子で楽しめる 絵本で英語をはじめる本(Jugemより移植)"},{"contents":"今週も勉強会に参加しました。 @yusukey さんが開催してるTwitter API勉強会です。 前回とは会場が異なりましたが、広くて大画面で良い会場でした。駅も近いし。（デジタルハリウッドさいこー！） 今回はLT枠のbootstrapの話が聞きたくて参加しました。（ムチャぶり駆動勉強会の現場をTLで目撃してたのでｗ） あと、バーチャファイター（昔、VF目当てでセガサターンを買ったなぁ、懐かしい）の話も聞きたかったので。 （ごめんなさい、Twitter APIはまだ触る機会がなさそうです。。。） 今回も途中で参加者同士を数グループ（座席が近い人）に分けて自己紹介タイムがあり素敵でした。 ちょっと残念だったのはネームプレートが今回はなかったことでしょうか。 自己紹介でツイッターID教える＋聞くのがちょっと辛かったです。（やっぱり個人名刺作ったほうがいいかなぁ） 私はPCを開いていたのでTwitterのページを見せることで対応出来ましたが。 （次やるときはお手伝いするのでこえかけてください。）\n内容はメモをとってあり、下に書いてますので見ていただければ。\nTwitter APIの説明はいろいろ新鮮でした。今回はWebページに貼るリンクやボタンの話でした。 カスタマイズも出来るようになってるってのは知りませんでした。Webサイトやってる人は簡単にカスタマイズできるのは便利ですよね。\nバーチャファイターのTwitter連携の話は結構詳細な話が出てきてびっくりでした。（テーブル名とかまで出てきましたｗ） ゲーム筐体の前のユーザの動きまで考えてシステム作るとかすごいなぁとか。違う業界の話って面白いです。\nBootstrap入門はbootstrapの紹介だけじゃなく、Tips（bootstrap弊害とかw）やその他の便利なサイトの紹介までありました。 スライドもあとから読んでもわかるのがすごく嬉しいです。時間を見て試してみます。 TwitterSphereは懇親会でもデモが見れました。Groovyは名前を知ってるだけだったのですが、Swingとかまで動くんですね。（JVMだから当たり前なんだけどなんか新鮮。） 最後はAndroidのAPI Demoのお話。こちらも普段Android携帯使ってるのに知らないことが多くて。。。 Macでもデモが動くんですね。やっぱり動くものを作ってLTするのって素晴らしいですねぇ（なんか作るかー）\nとまぁ、最近はキーワードだけ知ってて、いろいろ触れてもいないものが多いなぁと思ってたところに、 今日の勉強会で色々見れて面白かったです。 Twitterがいろんな人に興味を持たれているのがわかります。 （けど、Twitterってどうやって儲かってるんだろう？？？） 懇親会は、入り口からは想像できない貸パーティースペースで素敵でした。 開始の乾杯の音頭を取ることもできましたし（もちろん、ムチャぶり）。 学生が多かったのですが、声をかける暇なく懇親会が終わってしまったのが少し心残りですかねぇ。 毛色が違うメンバーが居て面白いので、次回も空きがあれば参加しようと思います。 スタッフとかお手伝いもしますので。\nということで、いつものメモです。\n開催日時：2012/02/23 19:00 ～ 21:00 場所：デジタルハリウッド東京本校 1Fセミナールーム Zusaarのページはこちら。他にも学生枠とかありました。\n◯ Webサイト向けAPI @yusukey\n・Webサイト向けAPI フォローボタン、ツイートボタン、Web Intents、@Anywhere サーバサイドの実装扶養、htmlのみで構成可能 ・Twitterボタン Twitterのサイトで色々カスタマイズ可能なボタンが作れます。 ツイートのカウント表示とか。 ・Web Intents @ツイート、リツイート、お気に入りが簡単にできるものが作成可能。 ツイートの埋め込み用リンクがTwitterのWeb版のツイート詳細から生成可能。 「このツイートをサイトに埋め込む」リンクをクリックするとダイアログが出てきます。 ・@Anywhere あんまりフォローされてないけど、JavaScriptでサーバサイドなしにTwitterと連携可能。 ユーザIDを辞書的に検知してTwitterの情報をホバーで出してくれる。 ・ウィジェット（検索、プロフィール、お気に入り、リストなど） これもTwitterサイトでカスタマイズ可能。 ・ツイートボタンには公式ロゴを利用しましょう ・注意点 charsetを必ず指定しましょう。 IE/Firefoxで問題が発生します。 ◯ グルーブに分かれて簡単に自己紹介\n◯ デジタルハリウッドよりご挨拶\n◯ 「Virtua Fighter5 Final ShowdownのTwitter連動機能について」@twtrfk\n部内にAmitterというSNSを構築して自由に使ってもらって、Twitterを疑似体験してもらった。 VF5FSでの開発中はTwitter4JにAmitterのラッパーを追加してテストしてたらしい。（おもしろいなー） 当時は、筐体にツイート機能を入れることも考えていたらしい。 ツイート自体はバッチで処理してます。 ゲーム筐体にお客さんが座ってる時間もシステムの性能として考慮しないといけない。 苦労した点： テストアカウントを100個地道に作成（連番、内容がバレるアカウント名はNGだから） Twitter4Jがうまく動かなかった。。。 今後の展開： まだ未定 QA Q：FB連携とかは？ A：今は考えてないです。 ◯ LT ・ @making「Twitter Bootstrap入門」 スライドはこちら\n・Bootstrapとは？ Twtter者が提供するWebアプリケーションのフロントエンド 一般的にCSSフレームワークと呼ばれるもの 簡単にかっこいいデザインにするための枠組み ダウンロードしてきてHTMLで読み込むだけ。 ・Bootstrapのコンポーネント紹介 いろいろおしゃれなコンポーネントあるよ。（スライド見ましょう） ・Tips examplesがあるので、それをベースに作るのが簡単です！ Initializrも対応してて、こっちで作るのもいいよ！ bootstrap簡単すぎて、みんな同じデザインのサイトに（弊害） 差別化のサービスが出てきてます。 ・ @kimukou_26 「TwitterSphere of Twitter4J」\nGriffon？ codehausで作られてるGroovy製のMVCイメージのGUIフレームワーク codehausはJetty作ってるとこですね 地球儀にツイートを乗っけることができるアプリ。 Groovyの記述がちょっと新鮮。 ・ @bina1204 「ApiDemos of Twitter4J for Android」\nAPI DemosというAndroidのデモがあり、ここにTwitter4Jを仕込んでみた？ Android系は持ってるのに知らない。。。 ","date":1330015800,"dir":"post/2012/","id":"966fe8d32b86121f8a465a21b95f7e5c","lang":"ja","lastmod":1330015800,"permalink":"https://blog.johtani.info/blog/2012/02/24/%E7%AC%AC4%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E3%83%8F%E3%83%AA%E3%82%A6%E3%83%83%E3%83%89--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-02-24T01:50:00+09:00","summary":"今週も勉強会に参加しました。 @yusukey さんが開催してるTwitter API勉強会です。 前回とは会場が異なりましたが、広くて大画面で良い会場でした。駅","tags":["勉強会"],"title":"第4回 Twitter API勉強会 @デジタルハリウッド #twtr_hack に参加しました。(Jugemより移植)"},{"contents":"久々にlucene-gosenの話です。 しかも、あんまり嬉しくない話しです。\nすでにissueをアップしていますが、lucene-gosenとSynonymFilterを併用する場合に、特定の条件下でNullPointerExceptionが発生してしまいます。\n条件は以下の組み合わせになります。\nSolr 3.5.0以前 lucene-gosen1.2.0 - 1.2.1の辞書なしjar SynonymFilterFactoryにてtokenizerFactoryを指定 根本的にはSolr側の問題のようです。SOLR-2909としてissueが上がっています。\nSynonymFilterFactoryでは、類義語の設定ファイルの単語を読み込むときにtokenizerFactoryを指定できます。 このとき、SynonymFilterFactory内部でtokenizerFactoryに指定されたFactoryのクラスが読み込まれ、 インスタンス化されて、Tokenizerが作成されます。 この、Tokenizerのインスタンス化の処理シーケンスに問題があります。 schema.xmlの\u0026lt;tokenizer\u0026gt;タグで指定されたTokenizerFactoryでは、ResourceLoaderAwareインタフェースのinform(ResourceLoader loader)メソッドが実行されます。 このinform()メソッドがSynonymFilterFactoryのToeknizerのインスタンス化の場合に実行されません。 lucene-gosenのJapaneseTokenizerFactoryではこのinform()メソッドでdictionaryDirのパスの読み込みを行なっています。（このへん）\n上記の条件では、NullPointerExceptionが発生すると書きました。 辞書を内包したjarファイルを利用している場合、NullPointerExceptionが発生しなくても次のような問題点があります。こちらの問題は見た目は動いているように見えてしまうので注意が必要です。 すべて、SynonymFilterを利用する時点でも問題点になります。\ncompositePOS設定が類義語辞書読み込み時に無効 dictionaryDir設定が類義語辞書読み込み時に無効（＝jarに内包されている辞書で動作する） 一見動いているように見えるかもしれませんが、望んでいてる動作になっていない可能性があるので注意が必要です。\n解決策（まだ途中） 先程書きましたが、基本的にはSolr側の修正をするのが妥当です。 SolrのJIRAにパッチもアップされました。 こちらのパッチをSolrに適用し、SynonymFilterFactoryを次のように指定することで問題を回避することが可能になります。\n\u0026lt;tokenizer class=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; compositePOS=\u0026#34;compositePOS.txt\u0026#34; dictionaryDir=\u0026#34;dictionary/naist-chasen\u0026#34;/\u0026amp;gt; ... \u0026lt;filter class=\u0026#34;solr.SynonymFilterFactory\u0026#34; synonyms=\u0026#34;synonyms.txt\u0026#34; ignoreCase=\u0026#34;true\u0026#34; expand=\u0026#34;true\u0026#34; tokenizerFactory=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; **compositePOS=\u0026#34;compositePOS.txt\u0026#34; dictionaryDir=\u0026#34;dictionary/naist-chasen\u0026#34;**/\u0026amp;gt; ... SynonymFilterFactoryの設定にcompositePOS、dictionaryDirを追加します。 ここの設定は\u0026lt;tokenizer\u0026gt;タグで指定された設定と同じ物を指定します。以上で問題なく動作することになります。\nただし、この方法はSolrにパッチを当てなければいけません。 Solrにパッチを当てるのもなかなかな作業だと思います。 ということで、どうにかlucene-gosen側だけでも対応出来る形にしたいなぁと考えているところです。 残念ながら、まだ考えているだけですので、もう少し提供できるのは先になってしまいますが。。。 現時点では、次の方法を考え中です。\ninformメソッドを呼ぶフラグを追加して、どうにかしてinformメソッドを呼び出す SynonymFilterの修正版をlucene-gosenに内包して提供する できれば、a.にて対応できればと思っています。 最悪、b.の方法かと。 悩んでいる間にSolrの次のバージョンが出てしまわないように出来るだけ早く対応しようと思っています。 他にも問題点や気になる点があれば、日本語、英語を問わないので、気兼ねなくissueに上げてもらうか、Twitterで私宛にメンションしてもらえればと。 （あ、issue23へのパッチでもいいですよ！）\n追記： まだ、SOLR-2909のパッチを適用してからの確認はできていません。（ソース見て大丈夫だと思ってるレベル） あと、現時点での対応方法としては、「lucene-gosenとは別のjarにSynonymFilterFactoryなどを入れて提供」が妥当かなぁと考えているところです。（無理やりinformメソッド呼び出すのは骨が折れそう＋パッチが思いの外早く出て、導入されたのでlucene-gosen本体に特殊処理を入れるのはあまりメリットを感じない。）\n","date":1329756060,"dir":"post/2012/","id":"4e7b945feca199bd486653fea1d0e39c","lang":"ja","lastmod":1329756060,"permalink":"https://blog.johtani.info/blog/2012/02/21/lucene-gosen%E3%81%A8synonymfilter%E3%82%92%E5%88%A9%E7%94%A8%E3%81%99%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AE%E6%B3%A8%E6%84%8F%E7%82%B9%E5%95%8F%E9%A1%8C%E7%82%B9%E7%B7%A8/","publishdate":"2012-02-21T01:41:00+09:00","summary":"久々にlucene-gosenの話です。 しかも、あんまり嬉しくない話しです。 すでにissueをアップしていますが、lucene-gosenと","tags":["lucene-gosen"],"title":"lucene-gosenとSynonymFilterを利用するときの注意点（問題点編）(Jugemより移植)"},{"contents":"また、勉強会ログです、すみません。。。 直接業務とは関係ないのですが、今回はリクルートの中野さんが話しをされるというので顔を出してきました。 もちろん、内容も気になりましたというのもありますが。 実際には中野さんは2分くらいしか喋らなかったんですけどね。。。\n今回は、最初のセッションはちゃんとしたソースコードリーディングでした。 Hadoopの入力としてデータをHDFSじゃなくて、MongoDBから取得するときに利用するMultipleInputの実装をしてみたというお話でした。 MongoDBやHadoopを知らないと（私はあんまり知らない。。。）少しきつかったかもしれないです。 幸い、HadoopのMultipleInputについては以前、すこしだけ見たことがあったので、かろうじてついていけました。 最初の部分を聞きのがしてしまったので合っているか自信がないのですが、10genから出ているmongo-hadoopの使い勝手、効率の悪そうなところに手を入れた話しがベースになっているんでしょうか？（ツッコミあるとうれしいです） 気になったのは、MongoDBのデータをHadoopから直接取りに行くというユースケースがどういう場合に出てくるのかという点です。 ネットワークやMongoDBの負荷がHadoop処理へのボトルネックになるんじゃないかしらという懸念がありそうだなと。 発表を聞いていて感じたのは、やっぱりソース書いて動かさないとダメだよねぇ、自分も手を動かそうというところです。 リクルートさんの発表は波乱万丈（？）でした。 最後まで話しを聴いたあとに思った感想は「こんなに話して大丈夫なのかな？」「いろんな人を敵に回してない？」というものです。 実際に昨年の夏くらいからEMCの草薙さんも検証メンバーに入って、リクルート社内での活用シーンをベースにMapRの検証をいろんな項目でやられたようです。（ある程度の詳細は以下のメモ参照） で、最終的な結論はまだ出ていないのですが、最後に出てきた検討中の比較対象が某C社のCDH。 どちらかというとCDHの方に傾いてる感じに取れる終わり方で心配になりました。。。 会場が会場だからというのもあったのかなぁ？ mesosというキーワードが出てきたのが気になりました。単語だけは以前Twitterで流れてきたのを目にしてたのですが、どんなものかという概要がわかったのは収穫でした。 リクルートさんの資料はどこまで公開されるかわからないですが、もう一度見たい気がします。（mesosの部分だけでも公開して欲しい）\nということで、以下はいつもの自分用メモです。\n日時： 2012年2月8日（水） 19:00～21:30 （受付開始 18:40） 場所： 豊洲センタービルアネックス（NTTデータ、豊洲駅直通）\n◎日本OSS貢献者賞・奨励賞のご案内　@hamaken 日本OSS貢献者賞・奨励賞\n◎『オレオレMultipleInputを作る方法（仮）』@muddydixon さん http://www.slideshare.net/muddydixon/multipleinput\nhadoopからMongoDBを利用する方法を紹介 CDH3u2かu3で試しました。 10genからも出てるけど使いにくい？から作った？ MongoMultipleInputs.addInputPath で色々簡単に使えるようにしたかった。 絞り込みしてデータをMapperにとり込みたかったため。 ＝絞り込みできないと必要なデータ以外も取得できてしまいJSONのパース処理がオーバヘッドになるから。 com.mongodb.hadoop.input.DelegatingInputFormat mongodbの環境にあわせて多くのsplitを生成する。 mongosへのアクセスはメタ情報の取り出しだけ。 あとは、個々のサーバにアクセスしてるのでデータ取り出しが高速？ ◎『MapRってどうよ？ - 実際に使ってみた感触を紹介します』 - リクルート 中野さん、高林さん、大坪さん\nMapRの説明資料がなかったので、EMCの草薙さんが出てきて説明を開始。 Greenplum MRはMapRテクノロジが開発した実装のOEM版。 EMCは特に手を加えず。 ※MapRについては前回のMapR勉強会の記事を御覧くださいな。 Q：JavaのAPI互換と言われている部分はHadoopのどのバージョン？ A：CDH3u2に近いパッチが当たってるらしい。 Q：DFSIO性能の比較対象のHadoopはどのバージョン？ A：手元に資料は残念ながらないです。 ここからリクルートさん。 検証内容：性能検証 中古車サイトで利用されている3つのHiveに置き換えてみた。 結果（パーティション圧縮） MapRのほうが約1.3倍高速に（そこまで速くならなかった？） 結果（非パーティション圧縮） MapRのほうが約1.7倍高速に（そこまで速くならなかった？） ビルドイン圧縮はGzip圧縮と比較して高速 ※チューニング次第では結果変わるかもね。 機能検証：マルチテナント検証 目的： 複数ユーザに対して1つのクラスタを提供する セキュリティの担保（） 余剰リソースの有効活用 複数ユーザのJobの並列実行？ 結果１（ユーザ権限まわり） MapRのユーザはLinuxユーザに準拠。 同じmaprユーザでもUIDがずれてるとエラーが起きる。 MapR内のPermissionは内部のクラスタ、ボリュームの権限定義が可能 ※Volumeは管理者に付加的な情報を与えるような存在 Job実行はHadoopと一緒のアクセス権。 結果２（FairScheduler） MapRではデフォルトとなっている。 複数テナントからの同時ジョブ実行の動作を確認。 poolをベースにタスクを割り当ててく。 min/max値にあわせてslotが利用される模様 結果３（Load処理（Hive）、Job実行（HiveのSelect）） じゃらんPVデータ１ヶ月分をロード。 NFS→MFS 結果４（フェイルオーバー） HA機能 ノード切り替え時間、タスクの復旧までの時間とか。 結果５（DirectNFSでの転送） NFSGatewayをクライアント側にした場合との違いなど。 クライアント側に載せた場合、通信量が減るから速度が出てる。 Mesos概要 Apache IncubatorのOSS。C++により実装 効率的なリソース分離、リソース共有機能を提供するクラスタマネージャ。 Mesosでの検証 マルチテナント（ユーザ権限）硬い。 リソース制限ができない。などなど。 MapRとMesosの比較 資料期待！ リクルートとしてのMapRの評価 保守/サポート/教育が充実してるのが重要。速度だけじゃない。 けど、まだ検討中です。 Q：クラスタに対するパーミッションの権限情報はどこで管理されてるの？ どこが落ちたときにそのパーミッションの情報がとれなくなる？ A：CLDBで管理されてます。 Q：CLDB内部でのデータはバイナリ？DBを別途持ってる？ A：HDFS上にボリュームが作られてそこに吐き出されてる。 Q：Jobのスケジュールの情報とかはどこに？ A：Job管理データはJobTracker用のボリュームに保存されてる。 それを別の人が引き継ぐ。 Q：ボリュームが壊れたら？ A：さすがに壊れたら引き継げない。 けど、壊れにくくしてあるのが売り？ Q：MapRのチューニングのポイントはどんなものがあるの？ A：チューニングに関しては256Mのchunkサイズを64Mに減らした場合の化粧しかしてない。Apache Hadoopの方は若干チューニングした。 Q：DFSのシリアライズは？ボンディングとかでもできるんじゃないの？ A：そこはやってないのでやってみます。 Q：MapRでの8台構成で全部のせてみた場合、CLDBのリソースはどのくらいもっていってるの？ A：結構使ってる。CLDBを3台以上にしたらサポート対象外。 Q：CLDBを3台に制限してる理由は？ A：わからない。 Q：本番MapR、検証CDHというのはあり？ A：M3を開発環境で利用して欲しいですね。（ステマ？）開発目的だとM5を無償提供してほしいなー（EMCへのお願い？） Q：Pigの検証は？ A：リクルートではHiveを利用してたので検証してない。 次回は3月ころかなぁ？だそうです。 ","date":1328716980,"dir":"post/2012/","id":"fa16213d24273d386d22332cd01ce774","lang":"ja","lastmod":1328716980,"permalink":"https://blog.johtani.info/blog/2012/02/09/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/","publishdate":"2012-02-09T01:03:00+09:00","summary":"また、勉強会ログです、すみません。。。 直接業務とは関係ないのですが、今回はリクルートの中野さんが話しをされるというので顔を出してきました。 も","tags":["勉強会"],"title":"Hadoopソースコードリーディング第8回に参加しました。#hadoopreading(Jugemより移植)"},{"contents":"Fluentd meetup in Japanに参加しました。いつも面白そうな話を聞いてばっかりなので、役に立つためにスタッフとしても参加してみました。 まずは、会場が綺麗でびっくりしました。しかも電源タップまで用意されていてかなり充実してました。Ustはまだ見ていないのですが、Ustも録画までされていて素晴らしい運営メンバーでした。\n開発者の古橋さんほか、Treasure Data Inc.の方たち（太田さんはいなかった）が集まり、 Fluentdの仕組みから、プラグイン開発の方法、実際にプラグイン開発してしかも本番で利用してる実例まで 「パーフェクトFluentd」という本ががそのまま書けてしまうのではというくらい密度の濃い話が聞けました。 私個人は、いつものごとく興味を持ってるんだけど、仕事、私用では触っていないという腰抜けなので話についていくのが大変でしたが。。。 各セッションごとに、しっかりとしたQA時間が取られていて、質問者も質が高く、中の人や発表者の方も誠実に回答されている感じがすごく良かったです。 （残念ながらLTの時は懇親会の準備を手伝っていたので聞けてないです） 基本はログの中継サーバとして利用するという話でした。 個人的には性能系のデータやログ（遅いクエリのログに関するプラグインの話などもあった）をストレージに保存して、時間を軸にログとグラフを表示するとかいう仕組みに使うと面白いかもなぁと感じました。 今回はFluentdがメインなので、ログを集める部分の話が主だったところでしたが、懇親会直前の@doryokujinさんのスライドでも上がっていた集計後のビジュアライゼーションに関する部分のはなしも聞いてみたいなぁと思ってるところです。\nあとは、いくつか知りたかったことが。 Treasure Data Serviceというサービスをやってるみたいで、SQLライクな問い合わせやビジュアライゼーションされた画面があるみたいな話があがっていたんですが、画面が見てみたかったです。 また、@just_do_neetさんの構想図のその後を聞いてみたいですねぇ。\nそれにしても実例も構成から性能値まで上がっていたので、実際に利用する場合に参考になる資料だらけで普及にはずみがつきそうです。 Ust録画が上がっているようなので復習したいと思います。 （あ、内容とは関係ないけど、Ust録画にハッシュタグつきのツイートを時間軸で重ねて表示するサービスとか機能ってないのかな？）\nということで、以下はいつものメモ書きです。\n2012/02/04 12:30 ～ 19:00\nフューチャーアーキテクト セミナールーム\n参考URL：http://fluentd.org\n◎13:00～14:00 「What\u0026rsquo;s Fluentd? - The missing log collector」 http://www.slideshare.net/treasure-data/fluentd-meetup-in-japan-11410514 Treasure Data, Inc.　古橋 貞之 (@frsyuki)\nまずは、Fluentdの概要。syslogdみたいなもの Fileのtailで流すことが基本。 Clientライブラリから流すことも可能。 他との比較 ScribeとFluentd 構造化されたデータを扱う gemとかapt-get，yumでインストールあg可能 Rubyで書かれてるからカスタマイズもプラグインの追加も簡単。 FluentdとFlume FlumeはZKやマスタノードが必要＝セットアップが面倒 JVMだから面倒、設定も簡単。 Fluentdのアーキテクチャ Bufferプラグイン：スレッドセーフ、バッファ処理など Outputプラグイン：出力だけ out_forwardプラグイン：Cassandraと同じアルゴリズムでHeartBeatしてる out_copyプラグイン：同じ出力を別の出力先にコピー bof_fileプラグイン：バッファ先をファイルにする。Fluentdがこけても大丈夫 out_exec_filterプラグイン：外部プログラムからの入出力を使える in_tailプラグイン：ログのパーサーが内蔵されてるみたい。 開発者用API Unitテストフレームワーク（MRUnitに似てる） TailInput（パーサカスタマイズも簡単） ドキュメントとか http://fluentd.org にあります。 会社紹介！ Treasure Data Service Fluentdでは出力先がいろいろできるけど、自分で解析しないといけない ！ここで、Treasure Data Service（クラウド）に保存すると。。。 データのVisualizationとかがリアルタイムで出来る。 QA： Q：ログ転送にUDP使ってますか？ A：TCPです。UDPはハートビートに利用してます。 Q：文字コードはどういう扱い？ A：バイナリ形式であつかってます。 文字列で扱う場合はプラグインで対応しましょう。 Q：性能大丈夫？ A：Twitterで議論があがって、いろいろ対応しました。 Q：TreasureDataServiceはクラウド対応だけなの？ A：データはクラウド上で管理してるので上げても大丈夫なものだけが現在は対応。暗号化などは行なっている。 Q：TreasureDataServiceはどこで動いてる？ A：AWS上（S3にデータ保存） Q：解析プラットフォームを提供している？SQLだけ？ A：HiveのSQLで解析可能。Visualizationのツールもある。 Q：コンサルタントもあるの？ログ出力系とか。 A：あとから解析できるように。 Q：in_tailでログローテート（iノードが変わって）も大丈夫？　A：大丈夫。動かなかったら連絡ください。 Q：ファイルバッファリングされるデータの順序は保証される？ A：キュー形式なので、保証される。けど、S3とかだと出力先が遅いので、 パラレルモードで対応が可能。だけど、パラレルだと順序は保証されない。 Q：実際のシステムが投げるときにFluentd側で認証とかできる？ A：認証はないです。推奨は同一アプリサーバでFluentdを起動。 Q：Fluentd間のデータ通信のセキュリティ対応は？ A：今はない。プラグインとか作ればOK。 Q：中間層のFluentdを置くのは推奨？なしで直接ストレージ保存も可能？ A：柔軟な対応（送信先、バッファリングとか）が可能にできるように中間層を置くほうがいい。直接出すことも可能。 Q：TDAgentでのセットアップが推奨？gemは？ A：gemはOSS版でtrunkに近い。TDAgentはテストとかしっかりやってる。 バージョンの対応表はリリースノート見ないとわからない。 Q：Flumeのほうが優れているのは？ A：設定ファイルが一元管理ができる。大規模はFlumeのほうがいいかも ただし、includeでHTTPサーバ経由で設定ファイルを取得可能な機能あり。 Q：バッファサイズは指定可能？ A：可能。 Q：ストレージがずっと停止している場合にログがあふれるのを防ぎたい場合の対処法は？ A：セカンダリという機能がある。（ただし、対応できてないプラグインもある） Q：フェイルオーバーでローカルファイル出力とかはできる？ A：out_forwardは対応してる？ Q：Fluentdからのbuf_fileに出力してる部分で遅延、書き込み不可が発生したら？ A：入力と出力がスレッドで分かれてる。 入力スレッドでのエラーはinput_plugin側にException上がる ◎14:15～15:00 「Dive into Fluent Plugin」 http://www.slideshare.net/repeatedly/fluentd-meetup-dive-into-fluent-plugin Preferred Infrastructure, Inc.　Masahiro Nakagawa (@repeatedly)\n好きなプラグインとか言いましょう（発表者さん） MongoDBのプラグインをベースにプラグイン開発の説明 http://bit.ly/fluentd-with-mongo プラグイン名はfluent-plugin-xxxで統一されてます。 fluent-plugin-mongoがダウンロード数が1位に！ （scribeのプラグインがデイリーでテストが走ってダウンロード数が増えるという卑怯なカウント稼ぎしてたらしいｗ） fluentd.confの説明 fluentdの起動は以下のとおり。開発中は-vつけるといいよ fluentd -c fluentd.conf プラグインをどう作る？ Fluentdの構成図による説明 Cool.io、MessagePack、Rubyなど。 それぞれの説明を簡単に。 Cool.ioがファイル監視とかをやってくれるみたい。 プラグイン開発に関する詳細な説明 テスト、gem構成などを書いてくれてる。 QA： Q：複数行のログを扱うのはどこを作ればいい？tailプラグインの正規表現だとうまく行かなかった。 A：tailをoverrideしてparserLineを実装する。複数行のparserは難しいけどね Q：ログのアグリゲーションをやってみたいのだが、どう？CPU利用率とかを1分間バッファしてからアグリゲーションして平均出すとか。 A；fluent-plugin-aggregateってのがあって、forward-pluginを書き換えて作ってる。 TimeSlicedOutputでやると時間の期間指定とかが可能。 管理画面つくろうと思ってるので手伝ってください！@repeatedly Q：fluentd自体が処理した統計データの出力とかある？ A：古橋さんが頑張ります！協力して！=\u0026gt;@tagomoris先生が書いてる！ ◎15:15～16:00 「fluent を使った大規模ウェブサービスのロギング」 http://www.slideshare.net/hotchpotch/20120204fluent-logging COOKPAD, Inc.　舘野 祐一 (id:secondlife, @hotchpotch)\nCOOKPADでの基盤全般を見てる部署の人　PVログ＋MySQL 1日分はオンメモリにのるから高速。けど、1週間前とかになると遅くなる blackholeエンジン（MySQLの一部？）だと速い（ときどきおそくなる） データ保存でも問題 直近データしか保存できない。大きすぎて。 今後スケールしないときつくなる（1日分もメモリに載らなくなる可能性も出てくる） 他のログはMySQLへJSONでシリアライズして出力とかもしてた。 アプリでDBにログ出力はinsertのコストが厳しい。PVとかなら、1リクエスト＝1insertだけど、1リクエストで多数ログ出力とかが厳しい。 そこにFluentd登場！！！ 出力先が色々使える。（MySQL以外もOK） パフォーマンス バッファリング＋転送をやってくれるし、非同期で処理可能なのでレスポンスタイムへの影響が最小限にできてる。 安定性 プラグインはちょっと注意が必要。 バッファリングしてくれてるので、一時的に停止もできるのがうれしい。 6時間止めてもOKだったよ（テヘッｗ） 今後 PV系のログをMySQLから移行検討中 具体例！！ td-agentをrpmで入れてるし、Rubyまで入ってくれる。 構成管理はpuppetを利用してる。 td-agentの設定の注意点 「retry_limit 9」に変更してる。標準だと17なんだけど、2の16乗＝大体1日かかる。9だと大体10分くらい 中央転送用サーバ gitで設定ファイル管理してる。 よく変更するため。　gemfileで各種fluentd/pluginを利用してる。 自分たちで手を入れたソースを利用できるようにもしたいため。 テスト時にテストが書けるのが嬉しい（Rubyで出来てるアプリからもいじりやすいし、アプリのテストでも簡単に使える） ロガーへの実装追加もできる。 Tips バッファからすぐ処理させたい場合とかの説明 こんなのあったら嬉しいな。 設定ファイルの柔軟な設定記述方式 DSLにならないかなぁ（けど、やり過ぎも厳しいし。。。） ログの重要性 統計を考えられるエンジニアが重要。 どのデータにどんな価値があってそれを仕事（お金）に結び付けられるか？ QA： Q：障害対応のノウハウとか？ A：nagios、muninでサーバとか監視してる。 アラートチェックもしてる。 Fluentdの安定性は2ヶ月実際に導入してみて特に問題は出てない。 Q：MongoDBの構成は？ A：master/slave構成。PVログはS3に保存してEMRで処理。 Q：パフォーマンスの測定は？ A：40Mbit/sが処理できてたのは見てる。あとは、後ろの発表ですごいのがある！ Q：設定ミスの防止とかをどうやった？ A：今回はpuppetの設定後のリロードをチェックするような仕組みを入れた。 本来なら、データが流れてるかどうかのチェックを入れるプラグインを書いて欲しいｗ Q：データマイニングエンジニアの定義は？ A：データの価値を見いだせるエンジニア。あとは、きちんと統計学を学んできてるエンジニア。両方募集中！！ Q：DynamoDBは検討は？ A：西海岸でしか動かないのでデータ転送の時間がかかってしまった＋RESTで１件ずつ登録なので今回は見送った。スキーマレスなのでうまく使えそう。 A２（古橋さん）：バルクインポートがないので使いにくい。 Q：ログ出力の形式をFluentdにあわせて変更したとかありますか？ A：もともとアプリで出力してたから特に変更なかった。 ◎16:15～17:00　「fluentをサービスで使ってみた」 http://www.slideshare.net/naverjapan/20120204fluent-public NHN Japan株式会社　Tetsuya Ohira (@just_do_neet)\n自己紹介が面白かったｗ 実例の話。 事例１： 社内向けのログ解析に利用　Fluentd＋Hadoop データノードにFluentdで出力して、データノードからHDFSに書き込んでる。 事例２： NAVERまとめのまとめ作成者へのデータ解析 Fluentd＋Hadopo＋Azkaban Azkaban（個人的にはオススメできないｗ） flutendの負荷は全然上がってない。 監視 tcp portの監視 転送されたデータサイズのチェック。HDFS側のデータ量でチェックしてる。 なぜか半死半生の状態になった（よくわからない。） プラグインを自分で直せるので対応が楽。（Ruby力は必要だけど。） demo 準リアルタイム解析基盤の構成案（おもろそう） fluentd、MongoDB、Hadoop、Jubatus、node.js 地図にアクセス解析結果をのっけて見せる。（maptail.js？） 提案or相談： 動的に設定ファイルの内容を変更できるようにしたい log rotateのタイミングでshell実行でfluentd再起動 必要な情報だけrelayしたい フィルタープラグインみたいなものが書きたい。 fluentd自体のメトリクスを出して欲しい jubatusプラグインはー？ QA：　Q：log rotateへの対応はどーしてる？ A：今はログローテートのタイミングでfluentd再起動してる Q：Apps側のFluentdがコケたときにaccess_logをcopyしてるらしいけど、重複しないの？ A：失敗した対象のログをストレージから一旦廃棄して、再送してる。 Q：Rubyがそこまで得意じゃないのにFluentdを選んだ理由は？ A：他のモノが使いにくかった＋既存システムに手を入れなくて済む＋タイムリーだったという理由。 Q：構成案のデータの流れは？ A：MongoDB、Hadoopへは同一ログを流して、リアルタイムが重要な場合はMongoDB、大量データ回すのはHadoop？ ◎17:15～18:00 「Distributed message stream processing on fluentd」 http://www.slideshare.net/tagomoris/distributed-stream-processing-on-fluentd-fluentd NHN Japan株式会社 ウェブサービス本部　Tagomori Satoshi (@tagomoris)\nsed | grep | wc がメイン。 Hiveで集計してます。 なんでFluentd？（not Storm、Kafka or Flume?） Rubyが好き（ライブドアはJavaが入ってない環境もあるし） プラグインやTimeSlicedOutputがあるのも採用理由 ログ収集の構成図 ブログに別の勉強会の資料があるので見てください。 まだ１０日間しか動いてないので実績は少ない？ 127サーバからのログを流してる。 7万行/sec、ピーク120Mbpsが流れてる。 89 fluentd インスタンスが12ノード（4コアHT）で動いてる。 1行のログを1行のタブ区切りで出力する（Hiveでインポートしやすいから） Apacheのログに幾つか追加したデータなどが出力されてて、それをタブ区切りにするため設定一発では変換できない。 TimeSlicedOutputが重要 時刻単位でログ出力できないとキツイ（ログの流量が半端ないから） ログローテートでは時刻単位できちんと出力されてない。 ログから解析までの流れ図 以前は生ログをHadoopに書き出してたので25分くらいのタイムラグが出てしまっていた。（ノード数が少ないという理由もあるけど、お金的に増やしたくない）＋Hadoopで他のジョブが実行されてるとさらに遅くなる。。。 fluentd でログを流しながらコンバートもかけられ、Hadoopでのデータコンバートの処理遅延が少なくなってハッピーに！ ストリーミング処理の重要な点 バッチでもストリーミング処理でも同じことが可能。（out_exec_filterとHadoop Streaming） SPOFがないこと トポロジ、Fluentdの構成　ログエージェント（scribeline：お手製） pythonで書かれたscribelineというものを利用してる。 フェイルオーバーの処理（primary、secondary構成）が可能 fluentdは入れてない。（ログを拾い上げて流すだけには重い） workerノード serializerノードが必要なのは出力先の競合を減らす必要があるため。 出力先が大量のアクセスに向いてない場合があるから。 あと、ログの流れを元に監視したい項目にもここで対応可能。 watcherノード deliver、serializerからのデータを見ながら監視、統計処理を行える。 設定は自動生成してる。800行くらいになっちゃうから。 workerへの分散具合をよしなにしたいから。 remove_prefix 、add_prefixでデータの流れ先の交通整理してるのか。 GrowthForecastでグラフを出力してる。 https://github.com/kazeburo/GrowthForecast QA Q：大規模環境での移行はどうやったの？ A：もともと流すような仕組みはあって、流し先を変えたので それほど大変ではなかった。ただ、アプリ側で動いてた部分に手を入れたときは配備が大変だった。 Q：workerが1サーバ8の理由は？ A：4コアHT＝8というので8としている。 Q：deliverのカーネルパラメータをいじってたりしない？ A：ライブドア標準の設定がされてる。CentOSのデフォルトでもそれほどきびしくないかな？ Q：deliverノードでラウンドロビン＋out_forwardになってる理由は？out_forwardだけじゃだめ？ A：バッファのタイミングでの切り替えだと溢れてしまうので、最大でも1秒でラウンドロビンしてworkerを切り替える必要がある。 ※懇親会設営の手伝いのためあんまり聞けず。 ◎18:15～19:00(Plugin紹介LT)(各10分)　@shun0102: 「fluent-plugin-dstatを使ったリアルタイムクラスタモニタリング」 http://www.slideshare.net/shun0102/fluent-plugindstat\n@ixixi: 「fluent-plugin-couch」 http://www.slideshare.net/ixixi/fluent-plugins-for-couchdbamazon-sqssns\n@chobi_e: 「Fluentd \u0026amp; PHP」 http://www.slideshare.net/shuheitanuma/fluentd-and-php\n@railute:「Fluent Output Plugin for Cassandra」 https://skydrive.live.com/view.aspx?cid=D105615A0F594518\u0026amp;resid=D105615A0F594518%21333\n","date":1328367780,"dir":"post/2012/","id":"a2679a7d860a0bfb2645809ed92ce138","lang":"ja","lastmod":1328367780,"permalink":"https://blog.johtani.info/blog/2012/02/05/fluentd-meetup-japan%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-02-05T00:03:00+09:00","summary":"Fluentd meetup in Japanに参加しました。いつも面白そうな話を聞いてばっかりなので、役に立つためにスタッフとしても参加してみました。 まずは、会場が綺麗","tags":["勉強会"],"title":"Fluentd Meetup Japanに参加しました。(Jugemより移植)"},{"contents":"昨年末に今年の抱負について書いたのですが、 他にも興味あるものが増えたので備忘録＆公約？を兼ねてブログに書いておきます。 （興味あるものがあれば、シェアしたりできると楽しいので、ツイート、コメント待ってます。）\nZooKeeper SolrCloud SenseiDB Lucene 検索システムのアジャイル開発？ まずは、ZooKeeper。このなんとも言えないアイコンでお馴染みのヤツです。 こんな顔してますが（顔関係ない。。。）、いろんな所に出没します。 Katta、Lilly、SolrCloudにも出てくるんです。SenseiDBにも出てくるんです。分散処理にことごとく絡んできます。 で、これは、知っとかないとまずそうだと。\nSolrCloud。まぁ、妥当です。一応、Solrな人なんで。 昨年、NewSolrDesignを訳してみてもいます。訳しただけでほったらかし。。。 elasticsearchとかSenseiDBとかSolrに似たLuceneを利用している検索サーバがチラホラ話題になってます。 できれば、このあたりの分散の仕組みを比較しながら調べたいなと思ってみたり。 すべてをカバーするのはキツイので、SolrCloudかSenseiDBあたりを調べていきたいなぁと。\nで、SenseiDBです。先日、Publickeyで記事が出て飛びつきました。 Zookeeper使ってるし、分散だし、全文インデックスにLucene使ってるし。 なんだか興味あること、全部入りな感じです。\nLuceneも興味津津です。 Solrがコアとして使ってますし、昨年、Solrと同時にリリースされるようになりました。 Luceneも奥が深く、時々、Solr調べててLuceneのソースも見るのですが、本格的に全体像を把握したりは残念ながらできていません。 そのくせ、Zookeeper同様、いろんな所に出没するんです、これが。 ということで、足元を固めるためにもLuceneに入門しないとなぁと。\nで、最後に検索システムのアジャイル開発です。 lucene-gosenのコミッターをやらせてもらってたり、Solrに絡んだ仕事もしてますが、長期にわたってフィードバックをもらいながら検索システムを育てていくというのが最近興味が出てきてることです。 検索システムは作ったらおしまいとは行かないのが厄介なところです。 データは増加しますし、検索されるキーワードも変わってきます。 また、検索される方法も変わってきたりもします。 ユーザが検索したいものも変化があります。 思ったように検索にヒットしない場合とユーザが離れて行ってしまいますし、検索しにくい場合も同様です。 今日、クックパッドの方の話しを聞いて思い出した次第です。（前に、Solr勉強会でも同じ話しをされて、同じ思いに至ったのですが、いかんせん忘れやすくてｗ） また、ログ解析の話などをTwitterで見てることもあり、検索という側面でのログ解析ってのも重要だよなぁと。 いくつか思いつくこともあるのですが、実践出来る場も限られてます。 色々と話しをする場を設けるのも面白いかもなぁと妄想してる次第です。\n取り留めもなく、現時点で気になってることを書きだして見ました。 また、数ヶ月したら気が変わってるかもしれないですが、とりあえず書き残してみます。 興味がある方がいらっしゃったら声をかけてもらえるとうれしいですね。\n","date":1327596641,"dir":"post/2012/","id":"58e83fb33c120db338132d23b9112805","lang":"ja","lastmod":1327596641,"permalink":"https://blog.johtani.info/blog/2012/01/27/%E4%BB%8A%E8%88%88%E5%91%B3%E3%81%8C%E3%81%82%E3%82%8B%E3%81%93%E3%81%A8/","publishdate":"2012-01-27T01:50:41+09:00","summary":"昨年末に今年の抱負について書いたのですが、 他にも興味あるものが増えたので備忘録＆公約？を兼ねてブログに書いておきます。 （興味あるものがあれば","tags":["備忘録"],"title":"今興味があること(Jugemより移植)"},{"contents":"ということで、いつものように勉強会に参加したメモです。\nhttp://atnd.org/events/23608 日時 :2012/01/26 19:00 to 22:00 会場 :アカデミーヒルズ(六本木ヒルズ内) 49階（タワーホールA） （港区六本木6-10-1） ハッシュタグ :#mnlgy\n■タイムテーブル 司会：CROOZLabs株式会社 研究所 所長 代表取締役社長　小俣 泰明 モーションノロジーの説明があったけど、他のことしてました。すんません。 1. 発表者: 有限会社未来検索ブラジル　森 大二郎 概要：groongaの索引構築の実装 全文検索とは。歴史から 1971：full-text。。。というキーワードが。 現代の全文検索の課題はあんまり変わってない 全文検索の手法 いくつかあるけど、転置索引の説明だけ。groongaも転置索引 groongaはインデックスの動的構築が得意 静的構築も考慮してます。 2. 発表者：CROOZ株式会社　長谷川 博紀 概要：MeCabからの脱出？(仮 CROOZ MALLの解説 MySQLとMeCabでやってます。 Tritonnつかってるのか？ groongaとの性能比較検証やってみました。 MeCabが問題じゃなくて、辞書ありの形態素解析が問題。 辞書にない単語もうまく検索したい 辞書に単語登録したら形態素やり直し ソート用のデータが。。。（ここはわからなかった） QA Q：MeCabの代わりとなっているものは？ A：MeCabを改善してみる？ 3. 発表者 : グリー株式会社　一井 崇 概要：全文検索のちょっとちがった使い方（仮） グリーでの数値指標管理 事前集計してKVSに登録してみてみる 1億パターンのキーが存在する。。。 キーがわからなくなる問題とか事前集計できてる？とか迷子になる。 キーも全文検索に入れてみては？ 「富士山の標高は何メートル？」とかでデータが取れる。 構造化されたキーをkey stringとして全文検索する。 構造化Keyに対応したKVSがあればいいんだけど。 データストアとしての全文検索もいいのでは。 4. 発表者：株式会社クリアコード　須藤 功平 概要：rroongaによる検索サービスの実装 groongaとRubyの組み合わせでrroonga。Rubyによるインタフェース？ groongaとのつながり部分をRubyで書いたライブラリ 多段ドリルダウン機能 絞り込みによる検索結果の比較とかに利用可能 メタデータ抽出にドリルダウンが便利 例：番組説明から出演者を抽出 サジェスト機能もある コンテンツベース すぐできる。候補の精度がいい 統計情報ベース 元データがある程度必要 候補が増えるけど、精度の問題あり 5. 発表者: 株式会社ぐるなび　塩畑 公一 概要: groongaの位置情報検索関連について。 2010年4月からgroongaを利用し始めた レストラン検索、地図検索など 円形、矩形の緯度経度検索が可能。 距離算出もやってる。ソートとか用かな。 球面近似もやってる。 geoの検索速度についてパフォーマンステストしました。 Q：近似手法をいくつもサポートされてるけど必要？ A：距離計算を正確にしないと不利になるお店が出てきちゃうから 6. 発表者: クックパッド株式会社 兼山 元太 概要: Solrを使ったレシピ検索のプロトタイピング クックパッドとは？ 女性多いよ AWS上でRubyで組んであるよ プロトタイピングって？ ユーザの問題を発見してから、プロトタイピング 本番デプロイ（一部ユーザに公開） 問題を抱えているユーザーに向けてそれぞれ数十のバージョンが動いている インタビューとかしてフィードバック受ける。 本番の検索エンジンのフィールドをいっぱい追加 Solrの紹介（MySQL（Tritonn）から移植しました） ダイナミックフィールドやレプリケーションの話。 JSON型でHTTP経由で検索できるのが便利。 Solr本の紹介して頂きました！あざっす！ 気になってるSolrの新機能 not to cache SurroundQuery BloomFilter Q：全部AWS？ A：全部AWSに移行しました。 とまぁ、参加してきました。 初六本木ヒルズで、おしゃれな場所、雰囲気にやられてしまって、あんまりちゃんと聞けてないところがありますが。。。 メモを取りましたので。参考までに。 groongaについては勉強不足のため、いまいちついていけませんでした。 ちょっと英語の記事を読んでいたのもありまして。（内職良くない。。。） MeCabに関する発表に興味があり、勝手にMeCabの代わりorMeCabよりいいものを使ってます！みたいな発表かと想像していました。（ちょっと違ったみたい、妄想は良くないですね。。。）\nグリーの方の発表は興味深かったです。ログ解析とかにも確かに全文検索の技術使えるし。 検討が進んだ次の話も聞いてみたいです groongaの位置情報の話やrroongaでのgroongaの色々な機能のはなしも出てきてgroongaの理解もちょっと進んだのはありがたかったです。\n最後のクックパッドさんの話は、今回もわかりやすくて面白かったです。 検索を成長させていくという姿勢と、実際にどんな形でそれを実施されているかが楽しそうに話されててとても羨ましかったです。 次はSolrで困ってる点とか、検索のログとか利用され方をどのように解析してるのかといった話も聞きたいですね。\nどうしてもSolrに思い入れがあるので、感想が偏ってるかもしれません、すみません。 気になる点やいや、こうなんだよ！ってツッコミがあれば、ぜひコメントやTweetしてもらえるとありがたいです。\n","date":1327593155,"dir":"post/2012/","id":"c6dc6e6567d673436ac41ebc8e79a9ec","lang":"ja","lastmod":1327593155,"permalink":"https://blog.johtani.info/blog/2012/01/27/%E3%83%A2%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%8E%E3%83%AD%E3%82%B8%E3%83%BC2012-1%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-01-27T00:52:35+09:00","summary":"ということで、いつものように勉強会に参加したメモです。 http://atnd.org/events/23608 日時 :2012/01/26 19:00 to 22:00 会場 :アカデミーヒルズ(六本木ヒルズ内) 49階（タワーホールA） （港区六","tags":["勉強会"],"title":"モーショノロジー2012#1に参加しました。(Jugemより移植)"},{"contents":"日時：2012/01/19 18:30-20:30 場所：ベルサール三田Room2シアター\nInside MapR デモ＋内部のお話。 ・自己紹介 Susheel Kaushik 元YahooのHadoop系の人。製品担当責任者。 草薙さん 3台のベアボーンでMapRが動いてるデモが開始。 クラスタ管理画面の説明。 なぜか、NFSのサービスが1台落ちてますがｗ MapReduceなんかの実行結果なども出てくるのか。 ボリューム管理も画面から操作 レプリケーション、スナップショットも管理画面で操作、動作確認できますよ。 ミラー先はリードオンリーでボリュームの同期が可能。 スナップショットによりMapRのクラスタ内部にバックアップが保持可能。 NFSのHA構成可能。VIPの機能などもあるよ。 事前定義された各種Alertの発行も可能。 JobTrackerもMapRで拡張された表示がある。 例：MapTaskPrefetchCapacity：次のジョブのMapperを起動する準備可能な仕組み MapR内で独自に出力してる測定値をGangliaで見ることができるよ。 MapRはHadoopの置き換えとなる製品。 HDFS部分を重点的に性能アップさせるために主に置き換えた製品。 MapReduce部分にも手を入れてる。例：Direct Shuffle（HTTPじゃなくて、RPCでShuffleの通信を行ってるとか）ボリューム活用してるらしい。 分散NameNode、JavaGCの影響の排除、ビルトイン圧縮によるI/O削減など。 Mapperの出力をHDFSに置くと、メタデータ更新が多くなり、NameNodeがパンクする。（Apache Hadoop） Q：中間データもレプリケーションすると性能劣化しないんですか？ A：中間データボリュームは特定ノードしか保持されない（＝レプリカ数は１） ストレージプール（SP） ソフトウェアでストライピング。RAIDしなくてよい。 コンテナ（データ、ネームがある。） データブロックをグループ化したもの ※ストレージプールの数と同数のボリュームを作成すべき。 CLDBがコンテナを管理してる。 Q：トランザクション失敗するのは？ A：どこかにかければトランザクションは成功。 コンテナが復旧してきたら、データがコピーされる。復旧されない場合は別途コンテナを割り当てることもある？ Q：ノードが追加される場合の挙動は？ A：。。。聞き逃した。 トポロジ ノードを階層的にグループ化してデータ配置をコントロール。 Q：トポロジ設定などの権限設定は？ A：Permission画面があるよ。 Q：ボリューム単位のファイルシステムアクセスに関する設定は？ A：？？？聞き逃した？ ボリューム いろいろな設定が可能。 スナップショット Copy-on-Write方式による差分格納 ミラー ソースからミラーにコピー。手動orスケジュールによる起動が必要。 ミラー側はRead-only ※誤解を招きやすいので注意 読み出しが多い場合にミラーを利用することで対応が可能。 ビルトイン圧縮 LZZFの一種を高速化してる ネットワークIOにも効いてくる JobTracker HA 最大３ノードで構成可能。アクティブスタンバイ NFS HA すべてのノードで稼働可能。 NFS機能 NFSv3相当 クライアント側にNFSサービスをインストールするという構成も可能に。 Q：NFSマウントして作成したファイルもブロックサイズ分のファイルサイズになるの？ A：8Kバイト単位で内部的にはファイルを作成してる。8KB単位で圧縮して管理してるので、小さいサイズでもいい。（アロケーションサイズが8KB） Q：8KBにしてしまったために大きなブロックサイズの利点がなくなるのでは？ A：オーバーヘッド内容な構成になってる。シーケンシャルに8KBに並んでるから？ Q：NFSによるとMapReduceによるアクセスの排他制御とかは？ A：独自で頑張らないといけない。Job起動時に効果的にスナップショット取ったりはしてない。 リバランスもバックグラウンドで実行可能 Apache Hadoopが備えるJava APIは100%語幹 Q：なんで、HDFSをがりっと書き換えたの？ A：運用性も、ノード管理も。。。全部です。 なくなっても良いデータなら、別にHadoopでもいいですよね。 けど、基幹システムとかだと、信頼性が必要だし、運用の効率も必要だしいろいろ必要。 Q：実績が必要なんですが、どのような試験を行われているのかという情報が公開される？EMCでやられてるテストのプロセスを適用しているなどの裏付けは公開されないの？ A：内部で6ヶ月利用してデータロスはない。 品質については強化していく。 Q：MapRとしてHadoopコミュニティへの還元していく内容ってどんなもの？ A：Apacheコミュニティに対して1000台のクラスタを提供してスケーラビリティテストとかやってくださいとしている。 Q：このクラスタを実際にはどう使ってもらうの？ A：品質アップするためにテスト環境として使ってもらう？ Q：ApacheのAPIの互換性を死守するのが必ずしもいいとは思えない場合にどうするの？MapR独自APIとかは出さないの？ A：ApacheのAPIに準拠するのは非常に重要。他のHadoop上のアプリが動作しなくなるから。 Q：MapRを容量の大きなファイルシステムとしてだけ利用するなんて想定はありますか？MapReduceを利用しないパターンです。 A：いや、それはｗ Q：MapRはエンタープライズがターゲットだけど、Amazonはパブリッククラウドが対象。マルチテナントなパブリックサービスでMapRを利用するとかは？ A：。。。 Q：ジョブ管理にも手を入れてるの？ A：あんまり手を入れてません。 Q：EMCのストレージ製品でMapRのMapReduceない版みたいの出てない？ A：中身はMapRじゃないですよ。 想定とは異なり、日本の草薙さんが主に説明されたのですごくわかりやすかったです。 しかもかなり内部まで理解されている方だったので突っ込んだ質問にもきちんと回答されてるので更に理解が進みました。 今回利用された資料は現時点では公開の予定はないという話でした。 ただ、かなりまとまってる資料なので、後悔して欲しいものです。 普通にviとかしてるだけなのに、すごいと思うデモってなんか新鮮でした。 MapR自体を触る機会はまだまだないと思うのですが、MapRとしてHadoopに対する思想が垣間見えたのが面白かったです。 すごいメンツが質問を投げまくるのでいろいろな側面で話が聞けました。 ただ、やっぱり英語のヒアリングがダメダメだというのが露呈しました。。。今年は少し頑張らないと、先が思いやられますね。。。 あと、疑問と言うか、感想ですが、MapR自体が結構多機能で、その機能をどう扱うか、どのようなノード構成やボリューム構成を取るかといった設計が結構大事でしかも大変なんじゃないかなぁという印象を受けました。 特にマルチテナントで利用する場合などは、想定されないミラーの利用などでデータ容量が足りなくなったりといった側面も出てくるのかなぁと。\n説明会のあと、Hadoopにあんまり絡んでないのに図々しくも飲み会にまで参加してきました。 これまた濃いメンバーだったので話についていくのも大変でしたが、面白い話が聞けました。やっぱり懇親会重要ですよねぇ。\n事前にこのブログを読んでいたので話しを聞くのが楽でした。 MapR勉強するために必須のページです。（どうやら今日説明した人がかいてるきがしますが。。。）\n追記： トゥギャってくれた人に感謝。 ","date":1326988680,"dir":"post/2012/","id":"7198e10ebcf1bb88dc479b5c5b9f2c15","lang":"ja","lastmod":1326988680,"permalink":"https://blog.johtani.info/blog/2012/01/20/mapr%E4%B8%AD%E8%BA%AB%E8%AA%AC%E6%98%8E%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-01-20T00:58:00+09:00","summary":"日時：2012/01/19 18:30-20:30 場所：ベルサール三田Room2シアター Inside MapR デモ＋内部のお話。 ・自己紹介 Susheel Kaushik 元YahooのHadoop系の人。製品","tags":["勉強会"],"title":"MapR中身説明会に参加しました。(Jugemより移植)"},{"contents":"お久しぶりです。インフルエンザで一家全滅という最悪の状況に陥っていた我が家でした。 流行してるみたいなのでみなさんも気をつけてください。\nさて、そんな中、OSSAJのミニセミナーでSolrについて簡単に話しをしてきました。 人生初Ustだったのですが、ぶっ倒れている中作成した資料だったためなんとも情けない発表だった気がします。（言い訳カッコ悪いですね。。。） 関係者の皆様、申し訳ございませんでした。\n内容としては、Solrの機能を簡単に紹介する程度の資料となっています。デモなどもないのでスライドだけ見てもなんだこれという感じかもしれませんが。\nということで、恥ずかしながら、録画もされているようなので、後で見て反省しようと思います。。。\n[オープンソースソフトウェア検索サーバ Solr入門](http://www.slideshare.net/JunOhtani/solr-11146713)** View more [presentations](http://www.slideshare.net/) from [Jun Ohtani](http://www.slideshare.net/JunOhtani) ","date":1326941184,"dir":"post/2012/","id":"a4462529ab493676987d946019a14945","lang":"ja","lastmod":1326941184,"permalink":"https://blog.johtani.info/blog/2012/01/19/ossaj%E3%81%AE%E3%83%9F%E3%83%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%A7%E8%A9%B1%E3%81%97%E3%82%92%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2012-01-19T11:46:24+09:00","summary":"お久しぶりです。インフルエンザで一家全滅という最悪の状況に陥っていた我が家でした。 流行してるみたいなのでみなさんも気をつけてください。 さて、","tags":["勉強会"],"title":"OSSAJのミニセミナーで話しをしてきました(Jugemより移植)"},{"contents":"先日のSolr勉強会でLucene/Solr4.x系のlucene-gosenについて質問を受けていたのを忘れないように（年越しちゃいました、すみません。）先週金曜日（1/6）にissueに登録しました。 まずは忘れないようにと思って、登録だけして3連休に突入したのですが、Robertさんが1/7に対応してくれました。 Lucene/Solr 4.x系では3.x系とはパッケージやメソッドが変更されるなど少し異なる部分があります。 lucene-gosenでは、プロジェクトのページにもあるとおり、4.x系にも対応しています。 ただ、この4x系に対応したブランチが、2011年5月から放置されていました。\nということで、Lucene/Solr 4.0系でlucene-gosenを利用されている方、これから利用される方は、この4x系に対応したブランチを利用してください。 なお、このブランチにはLucene/Solrのtrunk (r1228509)のSNAPSHOT版のjarファイルが利用されています。\n今後はlucene-gosen側でバグ修正や機能追加を行った場合にも4xブランチを更新していく予定です。 ※ただし、Lucene/Solr 4.0が正式リリースされていないため、頻繁にSNAPSHOTのjarファイルを入れ替えることはこなわないと思います。\n","date":1326033660,"dir":"post/2012/","id":"f7df7b85af230b2623d3a827b0cbddd2","lang":"ja","lastmod":1326033660,"permalink":"https://blog.johtani.info/blog/2012/01/08/lucene-gosen%E3%81%AElucene-solr4-0%E5%AF%BE%E5%BF%9C%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%9B%B4%E6%96%B0/","publishdate":"2012-01-08T23:41:00+09:00","summary":"先日のSolr勉強会でLucene/Solr4.x系のlucene-gosenについて質問を受けていたのを忘れないように（年越しちゃいました","tags":["lucene-gosen"],"title":"lucene-gosenのLucene/Solr4.0対応ブランチ更新(Jugemより移植)"},{"contents":"あけましておめでとうございます。（もう5日ですが。。。） 今年もlucene-gosenを中心に色々と記事を書いていきますので、ツッコミ、コメント待ってます。\nたまには会社のブログを書かないとイカンということで、会社のブログにNearRealTime検索についての記事をアップしました。 読んでやってください。\nということで、今年もいろんな勉強会に出没しますので、よろしくお願い致します。\n","date":1325735817,"dir":"post/2012/","id":"cc573488dec311655890a205aad4fb65","lang":"ja","lastmod":1325735817,"permalink":"https://blog.johtani.info/blog/2012/01/05/%E3%81%82%E3%81%91%E3%81%BE%E3%81%97%E3%81%A6%E3%81%8A%E3%82%81%E3%81%A7%E3%81%A8%E3%81%86%E3%81%94%E3%81%96%E3%81%84%E3%81%BE%E3%81%99%E4%BC%9A%E7%A4%BE%E3%81%AE%E3%83%96%E3%83%AD%E3%82%B0%E6%9B%B4%E6%96%B0/","publishdate":"2012-01-05T12:56:57+09:00","summary":"あけましておめでとうございます。（もう5日ですが。。。） 今年もlucene-gosenを中心に色々と記事を書いていきますので、ツッコミ、コメ","tags":["misc"],"title":"あけましておめでとうございます＋会社のブログ更新(Jugemより移植)"},{"contents":"他の方たちよりひと足はやいですが、今年の仕事が終わりました。 せっかくブログを始めたので、振り返りと来年の抱負など書いてみようかなと。\n今年の振り返り まずは、今年1年を振り返ってみます。 今年の出来事はこんな感じでした。\n3月に仕事が一区切り lucene-gosenに参加 ブログを始める 色々な勉強会に参加 Twitterでつぶやきまくり Mac Book Airの購入 PSVita買いました 3月に一昨年から参加していた仕事が一区切りつきました。 もう少し色々とやり残した感がある中で区切りがついたのが少し心残りでした。 あと、3月は震災もあり、色々と大変でした。ただ、自分の中では震災の記憶が少し薄れつつあるのが気がかりです。 良くも悪くも忘れて行ってしまうのだなと。今でも頑張っている方々もいるので、少しでも心に留めておきたいものです。\n個人的に一番大きな今年の変化は「lucene-gosenへの参加」です。 関口さんとここ数年ずっと仕事をご一緒させていただいていることもあり、コミッターとして参加させてもらうことが出来ました。 英語が苦手な中、Robertさんへ自己紹介のメールを書いたり、Issueを英語で書いたりと苦労もしていますが、OSSに参加できることがとても楽しいです。 また、使っていただいている方たちからのフィードバックもいただけているのがすごく励みになります。 やはり、OSSは使ってもらってさらに良いものになっていくのかなぁという感想です。 ただ、自分の腰が重いため、なかなか対応が遅かったりといったところもあるなと反省するところも。\n勉強会にも色々と参加しました。Solr勉強会を始めとして、かねてより興味があるHadoopのカンファレンスやソースコードリーディング。MongoDBの勉強会やDSIRNLPといった少し研究よりの勉強会にも参加しました。 Solr勉強会に参加してきた経験もあり、他の勉強会にも気負わずに参加できたので本当にSolr勉強会には感謝しています。 おかげで、社外のいろいろな方と話ができ、様々な刺激をうけることが出来ました。\n勉強会以外にもTwitterで色々な方に絡みまくったのもまた社外の方とのつながりが出来るいい機会でした。 Twitter依存症じゃないかというくらい、つぶやいたり、人に絡んだりしてます。。。（迷惑だったら言ってください。） お陰で@doryokujinさんや@wyukawaさんが主催してくれたログ解析の飲み会に誘ってもらえたり、@nobu_kさんや@ IjokarumawakさんにSolr勉強会で講演してもらえたりしました。 あと、Twitterを通じて勉強会やHadoop関連の情報、lucene-gosenへのフィードバックなどももらえていてかなり助かってます。 @yusukeyさんや@repeatedlyさんに遊んでもらってるのも楽しいですｗ\n最後の大きな変化はApple製品の購入でした。 これまでもブログで書いてきましたが、私は今年の中頃までアンチApple派でした。 それがここ半年足らずでAir、Mini、iPadと3つのApple製品に囲まれています。 Emacsのショートカットが使えるのが最大の要因ですが、何ごとも毛嫌いせずためしてみるのがいいなと思いましたね。 今では、Windowsで開発したくないくらいになってきています。\n2012年の抱負 さて、来年の抱負です。 今年いくつかチャレンジしようとして挫折してるものがあります。\nMongoDB触ってみる Scala触ってみる なんかWebサービス作ってみる（Amazonとかで） elasticsearch、IndexTankを調べてみる NewSolrCloudDesignを読み込んで自分なりにまとめる Junsaiに参加する 「7つの言語7つの世界」の続き 最初の3つはセットですかね。コップ本買ったり、NoSQLの本を買ったりしてるのですが、手付かずです。。。 電子書籍の検索サービスでもつくってみようと思いつつ、腰が重い状態です。 来年は余裕を見ながらちょっとずつやりたいですね。\nelasticsearchやIndexTankは仕事がらみです。 Solr入門を書いたこともあり、検索関連には興味があります。Solrだけでも2ヶ月おきに新バージョンがリリースされたり、4.0系でいろんな機能が実装されているのですが、それ以外にもOSSの検索サーバがいくつかあります。 気になってはいるものの英語が障壁でなかなか手を出して来ませんでした。 来年はSolr以外についてももう少し知識をつけていきたいです。 個人的ですが、分散処理にも少々興味を持っています。 慣れ親しんでいるSolrでもSolrCloudという壮大な計画が上がっていて、少しずつ実装もされています。 ブログでWikiページを翻訳してもみたのですが、翻訳に注力しすぎて理解ができていないです。 このあたりをもう少し理解しつつどのような実装がされているかも調べたいところです。\nJunsaiはSolr入門の著者である武田さんが最新のMeCab（今はMeCabが新しくなってしまったので、少し前のMeCabになってしまいました）をJavaに移植したプロジェクトです。 今年頭のSolr勉強会でお披露目があり、私も一応参画しているのですが、手が出せていない状態です。 lucene-gosenで少しは経験を積んできたので、その部分を生かしつつ、こちらももっと活性化させたいところです。 最後は夏ごろにやっていた「7つの言語7つの世界」の再開です。序盤で止まってしまっています。。。 新しい技術に触れる題材としてちょうどよいので、余裕をつくって続きを再開します。 なんか、抱負と言うよりも積み残しですね。。。 他にもTwitterで情報を仕入れるとやりたいことも変わってくるかもしれませんが、それも含めてブログに少しずつでも書きためていこうと思います。\n先ほども書きましたが、今年はTwitterを通じて色々な方たちと知り合いになれた一年でした。 ここには書ききれていませんが、フォローしてもらっている方々や勝手に絡んでも相手をしてくれている方々に感謝しています。 今後も絡みますのでよろしくお願いしますｗ あと、様々な勉強会に今後も顔を出していくので、かまってやってください。 いやぁ、色々書いたけど恥ずかしいですね。。。 まぁ、何事も経験なので、恥ずかしいと思いつつ今後も色々書いていきます。\n","date":1325006100,"dir":"post/2011/","id":"7164823f504286e3a762ee612ff0a988","lang":"ja","lastmod":1325006100,"permalink":"https://blog.johtani.info/blog/2011/12/28/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A0/","publishdate":"2011-12-28T02:15:00+09:00","summary":"他の方たちよりひと足はやいですが、今年の仕事が終わりました。 せっかくブログを始めたので、振り返りと来年の抱負など書いてみようかなと。 今年の振","tags":["misc"],"title":"今年の振り返りと来年の抱負？(Jugemより移植)"},{"contents":"@yusukeyさんにサインをもらう目的で勉強会に参加してきました。前回もらいそびれたのでｗ 残念ながら、まだTwitter APIを触ってないし、利用したサービスも思いついてないんですが。。。 けど、勉強になりました。 といことで、いつものごとく、自分メモです。\n◎APIの基本と最新動向について @yusukey 資料：http://www.slideshare.net/yusukey/21twitter-api-api\n・検索APIについて http://search.twitter.com/search.json?q=*** %3Aは「:」 詳しくはリファレンスを買ってね。 ・ページ処理のベストプラクティス Pageじゃなくて、MaxIdを利用して取得すると１５００件以上のデータも取れるよ。 ・最近のTwitterAPIアップデートについて - ポケリファでの変更点 ストリーミングのエンドポイントがSSLのみに。（twitter4jは2.2.5以上） - ユーザ名が検索APIのスキーマに追加（１２月以降） - in_reply_toの追加（１２月以降） =\u0026gt;検索結果から会話を追える。 ・include_entitiesが追加 t.coの展開したリンクも取得可能。 けど、t.coリンクの飛び先はt.coリンクにしてね。パトロールとかしてるから。 ・本当にあった怖いt.co - URLのつもりじゃないのにリンクになる。 →仕様です - 日本語を含むURLがおかしくなる。 →少しずつ治ってきてる。 - リンク先のURLがわからない（クライアント依存） そのたいろいろ？ ◎Zusaarについて何か @knj77 資料：\n・特徴 - SNSアカウントでログイン トラブル抑制など - 事前決済可能。最小催行人数が決められて、払い戻しも可能。 ・利用例 旅行とか合宿に使う例がないんだけど、できるんじゃないかな？ ・イベントを依頼する機能 欲しいイベントを提案可能 http://www.zusaar.com/idea/ ・アーキテクチャ GAE/Java、Twitter4j、Yahoo APIのテキスト解析 ・SNS連携 TwitterのDMが送れない。他のSNSのアカウントが主催者とか。 なので、自分からDMが届く。 ・PayPal連携 小さいアプリほど相性がいい 固定費ゼロ、マイクロペイメント（１００円とか可能） 銀行口座の登録不要、返金可能。部分返金も可能。 ・トラブル - SNS側のエラーが適当 ステータスコードは信用できないｗ - PayPalの実装を３回変更 - GAE料金体系の変更 9$/month。追加料金はほとんど使ってない。Googleのアナウンスが下手。 - ブルーオーシャンのはずが... Q：Zusaarで返金できるポイントは？ A：主催者が主導（手動？）で返金可能。 Q：無料イベントで約束手形的に課金するのはできる？ A：やろうと思えば出来ます。ただ、システム的には１００円は手数料としてもらっている。 Q：新しいATNDに対抗意識はありますか？ A：ZusaarはCtoCをターゲットにしてる。ATNDはBtoCなので、補完できる関係だと思ってる。 Q：APIでTwitterIDとかで検索したいんですが。 A：対応予定あります。 Q：できればATNDのAPIと共通化してほしい。 A：追加してるだけのつもりです。 ◎グループに分かれて自己紹介 6人中、懇親会参加者が5人もいたｗ\n◎LT - OAuth Echoについて@tkawa 資料：http://www.slideshare.net/tkawa1/oauth-echo-20111221-10657954\ntwitpicで使ってる。 認証をServiceProviderに委譲する仕組み。 クライアントがOAuth登録してあれば、。。。 ・問題点 非公式仕様 OAuth1.0に基づいてて2.0では変わってそう。 ・Railsで実装してみたよ。 - GroovyとQuartzとTwitter4Jの甘い生活G @mike_neck 資料：\nベトナムから緊急来日らしい。 しかもむちゃぶりされたらしい。 - 認証なしで使えるAPIまとめ？@ts_3156 えごったーの作者で学生！\n- TDD (Twitter4J Driven Development) @sue445 資料：\nAZusaarの作者！ テストドリブンなはなし。 Twitter4Jを利用するときのTDDの簡単に実装できる仕組みの話。 ここにソースがあるのかな？ http:/github.com/sue445/twtrhack/ - 放射線を自動計測してTwitterにつぶやくimaocandeの紹介 @imaoca 松山の方。 とまぁ、APIの話だけでなく、実際にAPIを利用している方のサービスの話など色々と面白い話が聞けました。 厚かましくも懇親会にも参加して、そこでも今までのイベントとは違うクラスタの方たちの話が聞けたのが楽しかったです。 やはり、APIを利用して色々とやってみようと思っている方が多かったのでいつもと違う話が聞けたんですかね。 私自身はサービスを思いついたりしないタイプなので、いい刺激になりました。（まだ、特になにか作る気にはなってないですがｗ） ということで、次回も余力があれば参加したいなー。 ","date":1324485660,"dir":"post/2011/","id":"da67e2f049b5b6babcf7906b85653399","lang":"ja","lastmod":1324485660,"permalink":"https://blog.johtani.info/blog/2011/12/22/%E7%AC%AC2-1%E5%9B%9E-twitter-api-%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%9D%B1%E4%BA%AC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-22T01:41:00+09:00","summary":"@yusukeyさんにサインをもらう目的で勉強会に参加してきました。前回もらいそびれたのでｗ 残念ながら、まだTwitter APIを触ってない","tags":["勉強会"],"title":"第2.1回 Twitter API 勉強会 @東京に参加しました。(Jugemより移植)"},{"contents":"lucene-gosenの最新版（1.2.1）をリリースしました。\nプロジェクトページよりダウンロードが可能です。\n今回の修正では、特定文字列でメモリの使用量が爆発してしまうバグへの対処となっています。 1.2.1以前のバージョンを利用している場合は最新版を利用するようにしてください。\n","date":1324437339,"dir":"post/2011/","id":"584b2b145f362098fc5fc1e634d57de5","lang":"ja","lastmod":1324437339,"permalink":"https://blog.johtani.info/blog/2011/12/21/1-2-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-21T12:15:39+09:00","summary":"lucene-gosenの最新版（1.2.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、特定文字列で","tags":["lucene-gosen"],"title":"1.2.1リリースしました(Jugemより移植)"},{"contents":"いつものようにSolr勉強会に参加してきました。 皆勤賞を継続中です。（暇人というはなしも。。。） 今回は話しを聞きたいですねぇといったら、いやいや、話もしてくださいと言われてしまったので、 発表もしてきました。 発表資料はブログの最後に掲載してあります。\n日時：2011/12/19(月) 19:00～21:00 場所：Voyage Group 8階\n1.Fessについて N2SM菅谷さん 資料：http://www.slideshare.net/shinsuke/solr-fess\nマルチコアで構成されてる。 S2Robotでクロールしてますよ。 ※ごめんなさい、あまり聞けなかった。。。あとで資料を読んで質問します！ 2.lucene-gosenについて @johtani 発表しました。 3.ApacheConに参加しました @Ijokarumawak 資料：http://www.slideshare.net/KojiKawamura/apache-con-2011report\n日本-\u0026gt;カナダ-\u0026gt;ベルリン-\u0026gt;カナダ-\u0026gt;日本 50万円。。。 キーノート１： セキュアな開発について。 キーノート２： Hortonworksのコミュニティ運営大変だよねぇ、頑張るよという話。 キーノート３： 本題：Lucene 4.0の話：Simonさん ヨーロッパの方？ PostingsFormatの話。 Document内部の情報を使うためにどうする？ StoredField：あんまり効率よくないね。 FieldCache（on RAM）：インデックス作る動作の逆を行う。これも効率よくないね。 IndexDocValue：インデックス作成時に作られるので読み込み性能が１００倍！（DocValue） Document Writer Per Thread！ Automaton Query あいまい検索の処理に利用。 Solr Flair Solr同梱 Prism LucidImaginationが出してるJRubyのラッパー GitHubで公開されてるらしい。 Blacklight RoR 図書館むけのパッケージじゃなかったっけ？ VUFind PHP これも図書館向け？ TwigKit JSPのタグリブ おぉ。これ直接読んでるのかな？ Ajax Solr Ajax用 QA Q：TwigKit、Ajax Solrは直接Solrを呼んでるんですかね？ A：たぶん、そうですね。JSPのはSolrJかもしれないですが。 4.サフィックスアレイの話 @nobu_k 資料：http://www.slideshare.net/nobu_k/suffix-arraysolr\nSuffix Arrayの話 全文検索インデックスの話。 Suffix Array＝検索漏れがない。 Suffix＝接尾辞 RedBullがどの文書に入っているか！ SuffixArrayのメリット 検索漏れがない＝n-gramと同様 仕組み上n-gramよりも早くなるケースが多い。 長いクエリに対して速い THIS IS IT：全部ストップワード SuffixArrayのデメリット インデックス構築系 アルゴリズムが難しい。 メモリ上での構築はちょっとだけ楽（けど、簡単ではない） SAISなど。けど、これだとメモリがいっぱいないとキツイ HDDでの構築 ランダムアクセスを排除したアルゴリズムが必要（dc3,dc7） インデックス更新、差分更新できない。 頑張って１台100GB/day Sedueでは？ SA＆インメモリn-gramのハイブリッド 更新分はn-gramに 検索時にはn-gram＋SAの内容をマージして出力 検索 二分探索はHDDとは相性が悪い。 メモリ上で検索できればOKだけど、サイズが大きいからきびしい。 圧縮接尾辞配列なら可能だけど、低速。。。 SSDだとはやいよ！ SSD対応のクラウドはまだないけど。。。 Sedueでは最初の２０段でキャッシュしてる。 VSストップワード ストップワード込でインデックス作るみたい。 1.SAを二分探索 2.該当区間から出現位置をロード 3.出現位置をソート O(n)だけど、CPUのキャッシュミスが激しく影響 4.ソートした出現位置からヒット文書を求める。 同じくキャッシュミスがやばい ・実際にはmallocした領域のページフォルトが一番やばい SAが超活躍する場面 遺伝子の検索 n-gramとか死ぬ。形態素解析も無理。区切りがわからんｗ 5.P2P検索 ORBIS @ceeflyer 資料：http://www.slideshare.net/ceeflyer/p2p-search-engine-orbis\nORBISとは？ラテン語で「目」 ORBISとは？ リアルタイム検索エンジン 自律分散検索エンジン もともとはAmebaなうの検索のため ノード構成 比較的小規模（～１０００台）\u0026lt;=しょ、小規模ですか。すごいな。 Master-Slaveの差がなし MessagePack利用 フルメッシュネットワークを構築 インデックス フィールド： Content（形態素解析対象） Appendix（形態素解析しない） Flag（属性） ハッシュレプリケーションで登録。近いハッシュ値に登録（レプリカ数を指定できるのかな？） 単語に対して転置インデックスを一定数で固定 投稿日時が新しいものだけ検索するため。 検索： マージして結果を返す。 壊れてたら取れたものだけ返す。 QA： Q：ハッシュ値が大きくて１台しか選ばれないとかあるのでは？ A：ハッシュ値は循環しているという形で３台とか選ぶ。 Q：最大何台で稼働させてる？ A：現在はまだ５台程度 Q：障害時にレプリケーションの維持はするのか？ A：現時点はしてない。 Q；Cassandra、Lucendraとかあるけど、それをしなかった理由は？ A：単純にConfigurationができるから、１から作った。 今回はSolr以外の話も聞けたのがとても面白かったです。 やはり、Solr以外の検索エンジンについても知見があると、色々と比較の話しとかしやすいので。 それにしても、一からP2Pの検索エンジンを作っているのにはびっくりしました。 他にもSuffixArray（Sedue）の話も気になっていたのが少し氷解したし、海外旅行のノウハウがApacheConの話で聞けたしｗ やはり、発表をすると話しをしてもらえるのもあって、いい機会だなと再認識しました。 今回も紹介ネタだったので、ちゃんと事例とか測定したものも発表できるようにならねばと。。。\nということで、私の発表資料はこちらになります。疑問点とか質問事項とか、指摘事項など、コメントorTwitterで連絡いただけるとすごく嬉しいです。\n[Lucene gosenの紹介 solr勉強会第7回](http://www.slideshare.net/JunOhtani/lucene-gosen-solr7)** View more [presentations](http://www.slideshare.net/) from [Jun Ohtani](http://www.slideshare.net/JunOhtani) ","date":1324311660,"dir":"post/2011/","id":"c6696a730f7498efb66f5ba3a8b35d08","lang":"ja","lastmod":1324311660,"permalink":"https://blog.johtani.info/blog/2011/12/20/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC%EF%BC%97%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F%E7%99%BA%E8%A1%A8%E3%82%82%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-20T01:21:00+09:00","summary":"いつものようにSolr勉強会に参加してきました。 皆勤賞を継続中です。（暇人というはなしも。。。） 今回は話しを聞きたいですねぇといったら、いや","tags":["勉強会"],"title":"Solr勉強会第７回に参加しました。（発表もしました）(Jugemより移植)"},{"contents":"ということで、懲りずに#DSIRNLPに参加してきました。 基礎的な部分をおろそかにしたくないけど、TokyoNLPとかWebMiningではついていけないので。。。 今回もしがみつくのが精一杯かもしれないと思いつつ、聞いて来ました。\n0. DSIRNLPについて　@overlast 講演者が可能なら実装に関して言及する。 「こうやって作って結果を出す」系の発表をしましょう。 開催に際して協力してくださったみなさんへの感謝の辞。 1.自然言語処理はじめました　@phyllo 資料：http://www.slideshare.net/phyllo/ngram-10539181 ブログ：http://d.hatena.ne.jp/jetbead/20111210/1323499634 某Web企業の新入社員！（すごい） で、入って自然言語処理をはじめたらしい。 N-Gramの説明 Perl？ 1.ナイーブな方法 Perlでハッシュ使って数えてみたよ。これでOK？ いやいや、Nが大きくなったりデータが大きくなるとキツイでしょ 2.SuffixArrayを使う ということで、Suffix Arrayを使ってみた。 SuffixArrayのデータを作ってから、上からN文字数えれば数えられる！ （数式出てきたけど目も取れなかったｗ） これでいいじゃん？いやいや、更に大規模だとどーすんの。1TBのメモリ 3.近似カウント法 いくつかある中からLossy Countingを説明します。 ストリームデータから数えてみよう。 C++の実装？ 4.分散処理を使う方法 近似じゃダメ！正確な頻度が欲しい！ ＝＞Hadoopつかえ！ 色々やってみた感想が良かった。 SuffixArrayのメモリ使用量という話がありましたが、ディスクを使う方法もあります。 by ? 新人から自然言語やり始めたというが、自分が新人の頃にはこんなに出来なかった気がするなぁ。 発表とかもってのほかだったし。 2.AI で AI 創ってみた（LT）　@uchumik 資料： Luaプログラミングが出てきたので、 多クラスロジスティック回帰とListNetを書いて見ました。（ただし、本は読んでないよ。） 学習器のお話。 ラグナロクオンラインのAIがLuaでかけることを思い出した。 動画の途中で終了ｗ GitHubにあげなさい。ブログ書きなさい。動画もあげなさい。 by @overlast 資料の割に時間がｗ　2.5.CMコーナー 技評の方からWEB+DBのCM！（ただし、商品なし） 読者層の95%が男性ｗ 総集編買ってね！WEB+DB plusシリーズも買ってね！ 書いてor買ってね。 技評さんつぎはオライリーさんに負けないように賞品持ってきてねｗ 3.Mahout にパッチを送ってみた　@issay 資料：http://www.slideshare.net/issaymk2/mahout-10539755 人がやめていく会社で検索やHadoopやってます。 ※今日は皆既月食です。 機械学習関連 SGDはMapReduceでの分散に対応していないので、パッチを送ってみた。 MapReduce、Shuffleなどの説明 これをベースにナイーブベイズの説明をあわせて実装を見てみる。 ・単語ｗのカテゴリｃにおける確率 ・文書ｄのカテゴリｃにおける確率 -文書ｄに出てくる単語ｗの確率の積と定義 単語の相関を見ない。 ゼロ頻度問題の解説 文書頻度の逆数（IDF） カテゴリ毎の文書数のばらつきに対応するために、Complement Naive Bayes BayesFeatureDriver 次はランダムフォレスト 決定木とは？ ランダムフォレストとは？ ここでは素性。 Mahoutでの実装は？ 決定木の数だけ処理分散が可能。 Reducerは使ってない。＝Mapperで計算が終わっちゃうから？ 次はロジスティクス回帰 尤度関数、損失関数、確率的勾配降下法（SGD） 先程まではオンライン。バッチ学習もある。 Mahoutでの実装はオンラインで、MapReduceに向いてない！ Adaptive Logistic Regrettion（アダプティブロジスティクス回帰）というのも実装されてる。 送ったパッチの概要 Iterative Parameter Mixisngというのがあるので、それをSGDに適用するパッチ 今後 MapReduce以外も増えるかも。 Q:パッチがはいったバージョンはいつでる？A:3日前に送ったのでまだです Q:ナイーブベイズのMapReduceが一段ムダでは？（文書数のカウントは同時に出来るよね）A:そうですね、ぜひパッチを送ってみてください。 Q:Mahout、Hadoopの未来は明るいんでしょうか？A:HDFSのデータをMapReduce以外のフレームワークで使えるといい。 Q:Hadoopのパッチ送るの大変ですか？どのくらいかかりました？A:4,5ヶ月かかりました。 すみません、途中から頭がパンクしてしまいました。。。 ただ、MahoutがHadoopに乗っかってるからといって、MapReduce活用できてるわけじゃないという話がわかりました。 4.GraphDBのデータ構造　@kimuras 資料：http://www.slideshare.net/skimura/graphdatabase-data-structure LTみたいな資料にになっちゃいました。すみません。 mixiではMySQLだけど、いろんなDB触ってます。 なので、GraphDBに興味持ちました。 Luceneを教科書的に読んでます。 Neo4jモダンな作りでよかった。　http://www.slideshare.net/skimura/ss-8787632 ノードデータの構造 NodeManagerというのがいて、Cache系を管理してる。 プロパティのインデックス、トランザクションManagerもいて、PersistenceManager ここからNodeにアクセス（探索、）。 キャッシュとかいいね。 Soft LRU Cacheってのもあるよ。 その他色々ｗ Q:トランザクション周りでLRUのキャッシュはどうなるんでしょうか@kumagi A:きちんとロックしてました。 Q:分散はネットワーク、HDDどちらがキツイ？A:HDDがかなりきつい Q:プロパティもキャッシュに乗ってたほうがいい？A:プロパティも必要なら載せたほうがいい。メモリのしてはできたはず。 Luceneがほめられてました。Neo４Jの 5.冬のLock-free祭り　@kumagi 資料：https://docs.google.com/viewer?a=v\u0026amp;pid=explorer\u0026amp;chrome=true\u0026amp;srcid=0B72X9w6tG5q0NzMyODgwNDYtNjY4Yy00ZDgwLTliZDMtMjQwYmViMWE5NGU5\u0026amp;hl=en_US ※資料がうまく見れないのは、アニメーションガチガチって話だからかな？ http://twitter.com/#!/kumagi/status/145363169718697984 辻Lock-free活動してます。 Lock-freeとツイートすると補足されるらしい。 CPUの系譜のおさらい ポラックの系譜 最新のIntelManyCoreとか東大とかに配られてるらしい。 なんで、マルチコアのCPUがTSUKUMOとかで売ってないの？ 僕らが使いこなせてないから。＝マルチスレッドの対応がうまくできてないから。 CAS＝Compare And Swap まずは、Lock-free stack ABA問題？ Lock-free Queue QueueのEnqueueの場合は2回のCASが必要になる。 不変条件を守る。ロックだと守りやすい。 2回のCAS処理の間が危険領域 Lock-free List 色々なロックの説明。 Lock-free hash map これも気が狂ってるアルゴリズム？ ConcurrentHashMapなども話が出てきたが、説明しない＝Lock-freeじゃないからｗ Lock-free SkipList SkipList： 順序関係のあるデータをO(log n)で検索・挿入・削除ができるデータ構造（2分木ともろかぶり） DougLea先生がjava.util.concurrentに入っています。 Lock-free Btree 論文ないんですよ。簡単すぎて。 SoftwareTransactionalMemory The Art of Multiprocessor Programmingを読みましょう！ 論文のお話。 http://labs.gree.jp/Top/OpenSource/Flare.html を利用しているらしい。 The Art of Multiprocessor Programming関連サイト http://www.cs.brown.edu/courses/cs176/lectures.shtml すごくわかりやすかった。資料をもっと見たいなぁ。 Q:STMはメモリ使用量が2倍になる？A: Q:STM（Clojure）使ってみたけど残念な性能しか出なかったけど、なんで？A:Clojureのものはロックベース。でうーむ。。。 6.機械学習と最適化の基礎（仮）　@tkng PFIの徳永さん 日本語入力を支える技術（技評）2012年2月発売予定 最適化の話、機械学習の話、学習率の話。 大域的最適、局所的最適の説明。（言いにくそう、大域的最適ｗ） 凸最適化問題＝最適解が1つしかない？ 大域的最適解＝局所的最適解 機械学習なはなし。 スパムメールの例で説明 淡々と語られてましたが、わかりやすい説明でした。もっと昔にこんな形で数学の説明聞きたかった。。。 7.機械学習・言語処理技術を用いた誤り検出・訂正（LT）　@mamoruk 資料： スペル誤り訂正とかに機械学習とか使われてます。 8.神の言語による自然言語処理（LT）　@AntiBayes 資料：http://www.slideshare.net/AntiBayesian/ss-10539347# Lispさいこー Clojureさいこー lucene-gosenもいいよーｗ 9.言語判定へのいざない（LT）　@shuyo 資料： Solrで採用されたlanguage-detection libraryの紹介。 アゼルバイジャン語とか大変みたい。 12.作ろう！簡潔ビットベクトル　@echizen_tm 資料：http://www.scribd.com/doc/73565169/Lets-Impl-Sbv 入門編： 簡潔データ構造 データサイズをほぼ情報量的下限にまで小さくしたデータ構造 データは小さいし、速度速いというのがこれ。 実用化されてる。 mozc（LOUDSが使われてます） Sedue（圧縮接尾辞配列（デフォルトではなくなった by @tkng）） 種類： ビット列：ここの説明がこのあと 木構造：トライ木をLOUDSが結構で実装するケースが多い。データサイズが小さくなる 文字列：ウェーブレット木が有名。全文検索、転置インデックスにウェーブレット木を使う研究が多い。 中級編 簡潔ビットベクトル： rank(i)関数：i番目より前の立っているビットの数。 疎なデータ列の効率的な実装に使える。検索結果が少ない場合のFacetとかに使える？ select(i)関数：？ 可変長データ列の効率的な実装 上級編 ダメでした。。。ごめんなさい。。。 体力的に厳しかったです。。。けど面白いし、わかりやすい。どういった所でこれらを使うべきかを取捨選択するのがすこし難しそうです。Luceneとかの内部ソース見ると実はこのあたりで実装されてる部分があったりするのかも。 11.類似文字列検索の仕組み　@overlast 資料： 使い所のはなし 例：辞書メンテナンスコストを軽減したい 架空の事例から類似検索を適用できるというストーリー 既存データが活用されるうれしさの例？ Apporoのデータ構造とかの話かな？ 11.5.審査委員長から賞品持って帰る人の発表 @kumagi @tkng @echizen_tm の方たちでしたー 12.懇親会 いやぁ、前回も感じましたが、基礎ができてないなぁと実感できた勉強会です。 そして幅も広い。やはり、数学的な要素が時々出てくるのでその部分をもっと身につけないといけないなぁと。。。 ついていけなかったところも多々ありましたが、頭の中にキーワードが入ってればなんとかなるかなぁと。 Neo4jやLuceneのソースコードリーディングをやるのが仕事に役立ちそうなので、少しずつでもやろう。 これから懇親会なので、とりあえず、このへんで。 あとで、見返しながら、リンク貼り直したりすると思います。\n","date":1323529475,"dir":"post/2011/","id":"16fa0e4aefe18e1446bf6baefd3ba400","lang":"ja","lastmod":1323529475,"permalink":"https://blog.johtani.info/blog/2011/12/11/%E7%AC%AC2%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-12-11T00:04:35+09:00","summary":"ということで、懲りずに#DSIRNLPに参加してきました。 基礎的な部分をおろそかにしたくないけど、TokyoNLPとかWebMiningでは","title":"第2回 データ構造と情報検索と言語処理勉強会に参加しました(Jugemより移植)"},{"contents":"ひさびさに、MBAのお話です。 セットアップといっても、物理的な方ですね。 以前、ケース（カバー）について記載しました。 この記事にも書いてあったのですが、付属の滑り止めが簡易なシールで、カバンの中から出し入れすると剥がれるは、作業をしてるとずれるわで、悩んでいました。 今日、たまたま、東急ハンズに行くことがあったので、店員さんに相談してすべり止め対策のグッズを購入しました。 相談した所、カバーは傷がつきにくくなるような素材ですから、シールもつきにくいとのこと。（言われてみればそりゃそうか。） 対策としては紙ヤスリで傷つけたところに薄手のシールゴムをつければはがれにくくなりますよとのこと。 ということで、やってみました。まぁ、ゴムにホコリはつくかもしれませんが、今のところ滑らず快適！ いやぁ、ハンズの店員さんすごいですわ。 MBAについてはこんなとこです。最近また、出先に行っていてMBA使えないので、ブログを書くかメールにしか使ってないです。。。\nで、もう一つはMac Mini（2009 late：Core2Duo 2.26GHz、メモリ4G、HDD250G）です。 前職の同期から安く譲ってもらいました。音声が出力されないという問題点があるとFacebookでつぶやいているのをみて、興味を持ったらゲット出来ましたｗ で、セットアップをしたのです。 大変でした。まずつまずいたのが、キーボードとマウスでした。 これまで使っていたデスクトップのキーボードがあるのですが、これがPS/2ということで使えません。（軽いジャブ） MBAのキー配列にも慣れてきていたので、ビックカメラで悩みながらもApple純正のワイヤレスキーボードとまじっくトラックパッドを購入。 で、まずは、付属のLeopardで初期化。 このときは、ワイヤレスキーボードは認識したのですが、マジックトラックパッドはこの時代に無かったらしく、反応せず（さらに軽いジャブ） さすがに前のPCのマウスはUSBだったので、これを利用してセットアップ再開 次にSnow Leopard（これもつけてくれた）にアップグレードして最後にLionです。 Snow Leopardでソフトウェアアップデートしたところでようやくトラックパッドが認識できたと。 で、やっと使い始めたのですが、MBA（2011）に慣れていたので、思いの外もっさりした動きをしているMacMiniに 戸惑ってます。（トドメのストレート。現在ここ） ということで、どうやれば快適に使えるかアイデア募集中です。 とりあえず、Lionの設定のウィンドウ復元機能やアニメーションをオフにするなど対策してます。 HDDのSSD化とかメモリ増設とか考えないとダメかなぁ。 あと、ついでにBootcampも興味があるので、せっかくだから実験する予定です。 Windowsが前のデスクトップより快適に使えるようになるなら、Windowsマシンとするのもありかなぁと。。。\nセットアップ系はこのへんで。 あとは、最近興味が有ること2点です。（技術系ではありません） 1つ目は最近発売されたゼルダ。夜な夜なやってます。 もともとゲーム好きでゼルダも欠かさずやってきてますが、ゼルダらしさを残しつつ新しい要素やアクションも取り入れとなかなか楽しいです。 ただ、Wii全般に言えることですが難しい！まぁ、楽しんでますけどね 2つ目は前からつぶやいてるのですが、電子書籍を読むためのタブレットがすごく気になってます。 最初は財布に優しく、MBAを普段持ち歩いてるのもあるから、LenovoのA1（7インチ）で決まりだと思っていたのですが、技術書を読むのは少しキツイかもという印象。 どうしてもオライリー本などの大きめのサイズになるため、7インチの画面でPDFを表示したところ、字が小さくなってしまい拡大しないと見づらいのです。 ただ、拡大してしまうと今度はパッと見るという一覧性が下がってしまいます。。。 少々重くなってもいいので10インチにしたほうがいいのかな、けど、電車で立って読むの辛いかもなどなど考えているところで最終的な決断ができない次第です。。。 最初は毛嫌いしていたiPad2もいいかもと思う始末で困ってるとこです。 安い中華パッド（2万ちょっと）に手を出すか、7インチで我慢するか、Galaxy Tab 10.1のWifi版を輸入業者から購入するかと悩んでるところ。 ただ、長く使うのを考えると、OSのバージョンアップなどを保証してくれるiPad2が実はいいじゃないかなぁなど。 皆さんからしてみればくだらないなぁと思われるかもしれないけどずーっと悩んでつぶやいたりしております。 はぁ、こまった。（そもそもそんなにスペックいらないんじゃないかというのもあるからなぁ。メインはPDF読むことだから。） ゼルダの伝説 スカイウォードソード (期間限定生産 スペシャルCD同梱) ","date":1322668828,"dir":"post/2011/","id":"6e970d0818d58ff2d50c5bf037b1a565","lang":"ja","lastmod":1322668828,"permalink":"https://blog.johtani.info/blog/2011/12/01/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%95%E3%81%A8mac-mini2009late%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E3%81%A8%E3%81%9D%E3%81%AE%E4%BB%96%E3%81%8F%E3%81%A0%E3%82%89%E3%81%AA%E3%81%84%E8%A9%B1/","publishdate":"2011-12-01T01:00:28+09:00","summary":"ひさびさに、MBAのお話です。 セットアップといっても、物理的な方ですね。 以前、ケース（カバー）について記載しました。 この記事にも書いてあった","tags":["備忘録"],"title":"MBAセットアップ備忘録その５とMac Mini（2009late）セットアップとその他くだらない話(Jugemより移植)"},{"contents":" どんな本でも大量に読める「速読」の本 Twitterで知り合った方がこの本について書かれていたブログ記事を読んで興味を持ち、読みました。 書籍（特に技術書）が山になっていたこともあり、速読に興味を持っていたところちょうど記事を目にしたのは きっと何かのタイミングなんだろうなと。\n悪い癖で、電車で読もうと本を常に持ち歩くのですが、ついついスマートフォンやゲームで遊んでしまい、今回も読むのに時間がかかってしまいました。 ３章の途中までを今月頭に読んでいたのですが、そこから少しほったらかしで、読み終わったのが昨日でした。\n本の内容ですが、先ほどのブログにも書かれていますが、速読は技術ではない。 ### 速読　＝　速読技術　X　ストック（知識、経験、情報） であると。あとは、わからなくてもいいから、ざっと目を通す感じで繰り返し読みなさいと。 さらに、１回でわからんくてもいいから、とにかく繰り返し読むことが重要だということでした。\n確かに「速読＝１回で速く読む」、「読書＝１回で理解する」という意識がどこかにあったなぁと気付かされました。 プログラム組んだり、あることを覚えるときは繰り返しを意識してたのに、読書は１回読んで「はい、おしまい。」という気になってました。（マンガは繰り返し読むんですけどねぇ）\n他の速読の本は胡散臭いし、絶対無理だよなぁと思ってたのですが、この本に書かれている話は筋が通っているように感じました。 ただ、考えずにサラサラ読みなさいという部分の実践はなかなか難しいかな。どうしても頭の中で音読してしまうので。 私は間を開けてしまったせいで、時間がかかってしまいましたが普通なら１日あれば読める内容なので速読に関してちょっとと思ってる方は読んでみると面白いかと思います。\nちょっとだけショックだったのは、この本の論理だと電子書籍は速読に向いていないというところです。 せっかく溜まった書籍をPDF化して、タブレット購入して（まだ買ってない。。。）読もうと思っていたところなのに。。。\n","date":1322542620,"dir":"post/2011/","id":"0ebe78077c8b48410cf52a0bccdff866","lang":"ja","lastmod":1322542620,"permalink":"https://blog.johtani.info/blog/2011/11/29/%E3%81%A9%E3%82%93%E3%81%AA%E6%9C%AC%E3%81%A7%E3%82%82%E5%A4%A7%E9%87%8F%E3%81%AB%E8%AA%AD%E3%82%81%E3%82%8B%E9%80%9F%E8%AA%AD%E3%81%AE%E6%9C%AC%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-29T13:57:00+09:00","summary":"どんな本でも大量に読める「速読」の本 Twitterで知り合った方がこの本について書かれていたブログ記事を読んで興味を持ち、読みました。 書籍（","tags":["読書"],"title":"「どんな本でも大量に読める「速読」の本」を読みました(Jugemより移植)"},{"contents":"Hadoopソースコードリーディング第7回に参加しました。 いつものごとく、自分用のメモをとっていたので。 第6回（2010/12）には参加してたのですが、あれからそういえば、話が無いなぁと思っていたところに 再開するという話がTwitterに流れてきたので、即申し込みしました。 思い返せば、Hadoopに興味をもって少し触っているところで参加したのだったなぁと感慨深い思いを思い出しました。\n今回は場所を変えて豊洲のNTTデータさんで開催されました。\n日時：2011/11/28（月）19:00～22:00 場所：豊洲センタービルアネックス NTTデータ\n◎アジェンダ＋導入（NTTデータ 濱野さん） ちょっと間が空きましたが隔月で行う予定。 2012/01/12くらいに次回を予定。ネタ募集中。 ◎Hadoop World NYC 2011 参加レポート - NTTデータ 下垣 徹さん （Hadoop徹底入門著者の一人です！） ・イベント概要：2011/11/08～09にNYで開催 スポンサー企業の数がどんどん大きくなってる。 ・会場の様子 最初のキーノートは立ち見が出るほど。 個別に5並列でセッションが開催されてましたと。 ・キーノート紹介 1.Hadoop World（Michael Olson） アンケートからの概観 HadoopはNext Generation DataCenterだそうで。 2.JP Morgan（Larry Feinsmith） コスト削減＋収入増加のためにHadoopつかうぞと。 BigData分析の戦略 ユースケース１：ETL（Extract/Transfer/Load）ツールとして ユースケース２：共通データ基盤 検索頻度が低いデータの低コストストレージなどなど。 ユースケース３：データマイニング 異常値検出とか。 3.eBay（E. Williams） Cassini：オークション情報の検索エンジン 柔軟な検索＋協力なランキング機能 Hadoopで転置インデックス作成＝Luceneは使ってるってことかな？ HBaseも利用。データはHBaseに登録してる。 4.Informatica（James Markarian） データとプロセス Hadoopが賑わうからRDBMSも活気づく Hadoopはプラットフォームになるよと 5.Cloudera（Doug Cutting） Hadoopの背景と今後について BigDataを分散処理するためのカーネルになりつつあるよと。 Apacheプロジェクトの良さ 類似するプロジェクトも共存させてるよと。 Hadoopの今とこれから（0.20（今）、0.23（将来）） 0.23はHDFSの性能面改善、スケーラビリティの強化、HA MapReduce2.0 CDH4のはなし。 Hadoopコミュニティはまだまだ若い ・HadoopWorldの傾向 HBaseの利用増加 利用理由？ 小さいレコードにも強い。 ランダムアクセス 大手ベンダ参加 Oracleすげー。Hadoopの周りを固めていくぞと。 Hadoopの周りを各社がどう固めていくかというはなし。 事例が多い WibiData：HBaseの利用事例。Fonedoctor Walt Disney：Big Dataに対する機会損失があるから、導入するよと。 テーマパークの交通流解析にも使うぞ！ イケメンによる来年（2012年）のHadoop Worldの動向！？ 参加者3000人！ ラスベガスで開催？ スポンサー拡大で食事が美味しく！？ 全方位戦略vs.特化型 BIツールベンダの巻き込み 利用事例のアピール合戦 HBaseの利用事例が続々！（Salesforce.comあたりがセッション持つんじゃね？） Hadoop対抗アプリケーション、業界特化型キラーアプリケーションがますます増える？ Mahout事例の増加 データマイニング＋Web勉強会 - NTTデータ 政谷さんのHadoopNYでの発表のダイジェスト まずは印象。深く使っている人は去年より減っている。バズワードになってるからかな？ 今後もHadoopコミュニティは健全なコミュニティになりそう。（いろんな所が出てきたけど、大丈夫そうだなぁ） ・発表スライドのダイジェスト版 日本でのHadoopの盛り上がりの話。 Hadoopと他との住み分けの話。 Sqoopのお話。PostgreSQLに向けたインテグレーションの話。これはPostしてコミット待ち。 Low-Latency Serving Systemへの受け渡し（前処理はHadoopでGPGPU使ってデータをクラスタリングして処理速度をあげる） FujitsuのETERNUSにHDFS APIが用意されたという話。 MapRの話に似ているよと。小さめのクラスタの場合に有効？セッションの後に少し話題になった。 扇子を配りましたよと。 ※ビールが配られ始めた！（ビールじゃないという声もチラホラｗ） ◎『Hadoop Troubleshooting 101』 セッションレポート - Cloudera 嶋内さん （@shiumachi） Hadoopを壊す7つの方法 Hadoop設定したりしたことある人？＝結構いた。さすがソースコードリーディング Clouderaでは木曜日に重要なミーティング（ボードゲームするかFPSするか）というのがあるらしい。 チケット分析 設定ミス？ HadoopやOSの設定ファイルの変更を必要とするあらゆるチケットの事 35%が該当 問題の原因別のグラフ 1番は設定ミス 2番はバグ（これはベータ版リリースからチケット管理してるから） メモリの管理ミス Task Out Of Memory Error io.sort.mb \u0026lt; mapred.child.java.optsとなるように設定すること io.sort.mb = mapバッファのサイズ mapperとreducerを減らす。 mapper＝ノード上のコア数 これは机にはっとけ！ Total RAM = (Mappers + Reducers) * Child Task Heap + DN heap + 3GB + RS heap + ？ JobTracker Out Of Memory Error JTのメモリ使用量の合計　＞　割り当てRAM 原因は？ タスクが小さすぎ jobヒストリが多すぎ 解決は？ maximumを減らしなさい？ Unable to Create New Native Thread どういう意味？ プロセスが起動中にもかかわらずDNが障害ノードとして表示されている。 原因は？ nprocのデフォルト値が低すぎる 対応は？ /etc/seurity/limits.confの値を考えろ Too Many Fetch-Failures 元スライドの発表者はこれが大好きらしい どういう意味？ Reducerのfetch操作がmapperの出力の取得に失敗 ブラックリスト入りのTTで発生するらしい 原因は？ DNSの問題 対応は？ mapred.reduce.slowstart.completed.maps = 0.80 reducerの開始を遅らせることで対応 tasktracker.http.threads = 80 Jetty 6.1.26は使うな！CDH3u2に上げましょう。 Not Able to Place Enough Replicas 。。。きっとどっかにスライドあるからメモはこのへんでいいか。。。 ◎Hadoop World NYC 2011 参加レポート - Acroquest Technology 阪本 雄一郎さん （@frutescens） 落合 雄介さん （@taro_x） ・RとHadoopの融合（Revolution AnalyticsのDavid Champagneさん） R言語の紹介 Rとの接続点（rmr、rhdfs、？） R言語の利点がHadoopで使えるから、記述が少なくて済むよと。 統計処理がわからなくてもRが使えると分析ができるよ。（そう言われても、その分析で正しいのかとかは結局統計とかをある程度理解してないと厳しいんじゃないか？） ・Hadoopを使った衛星画像解析 スケールとかしたいからHadoopにしたけど、ジョブ起動遅いし、科学計算ライブラリが不十分 ・Hadoopをクラウド上に展開（vmware） Hadoopだけじゃなく、NoSQLとかもスケールしてから使いたいよねぇ。 ということで、vmwareの色々なものを使ってHadoopと他をうまく構築しますよ事例紹介。 マルチテナントのHadoopの話とかもありますよねと。 ◎最後はHadoopには関係ないのが多かったけどおみやげ争奪戦。 なぜか、MongoDBのシールをもらいました。 ということで、HadoopWorld2011の総括＋各スライドの紹介でした。 これまでのHadoopWorldの傾向などから、参加者などのトレンドがどうなっているかなどの話が聞けたのが面白かったです。 ClouderaのスライドはHadoopのトラブルシューティングとして必見になりそうな感じでした。 内容が濃くて、それほど触っていない私にはわからないところもチラホラ。（日本語資料の公開されるかなぁ？） 案の定、ビール（発泡酒）を飲んだので、途中から一部が飲み会状態になってたし、ピザ食べてたので、私のメモも途中から適当になってしまいました。 あとは、とある件についていろんなかたからの知見を入手できたのが良かったですね。 他にもLilyプロジェクト（Solrが利用されているOSSの話）の話もあったようなのですが（HPの方が教えてくれました）、今回の参加レポートでは含まれてなかったです。（話聞きたかったなぁ。余力があれば、スライド読むかなぁ。誰か発表してくれないかなぁ） 今日もまた、Twitterで絡んでいた方たち数人と面識が得られました。 今後は定期開催の流れになるようなので、これからもHadoopにしがみついていくためにも参加するようにがんばりますよと。\n会場提供のNTTデータのみなさん、発表者の皆さんお疲れ様でした。次回も期待してます！！\n2011/12/01追記 Togetterのまとめ\n","date":1322499060,"dir":"post/2011/","id":"924727b6f380cf3cdfe5650163e92054","lang":"ja","lastmod":1322499060,"permalink":"https://blog.johtani.info/blog/2011/11/29/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC7%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-29T01:51:00+09:00","summary":"Hadoopソースコードリーディング第7回に参加しました。 いつものごとく、自分用のメモをとっていたので。 第6回（2010/12）には参加して","tags":["勉強会"],"title":"Hadoopソースコードリーディング第7回に参加しました。(Jugemより移植)"},{"contents":"先週末から勤労感謝の日まで風邪で寝こんでました。。。 みなさん、朝晩、冷え込みが激しいので風邪には気をつけてください。\n季節の言葉も入れたので本題です。 つい最近、「Apache Solr入門」のサンプルをlucene-gosenでどうやって動かすんですかー？という質問を受けました。 確かに、「Apache Solr入門」を書いたのはSolrのバージョンが1.4が出る直前でしたし、lucene-gosenは存在せず、 当時はSenを元にした日本語の形態素解析のサンプルとなっていました。 そのSenも入手しづらくなってきており、私もlucene-gosenのプロジェクトに携わるようになってきてある程度時間が 経ちました。 せっかくなので、サンプルのschema.xmlだけでも最新版（Solr 3.4 + lucene-gosen-1.2.0-ipadic）のものを用意しました。 なお、あくまでも、3.xでlucene-gosenを利用する場合の「Apache Solr入門」のサンプルプログラムの変更点（とりあえず、4章まで）の違いについて記述します。 申し訳ございませんが、1.4と3.xの違いについての説明はここでは行いません。\n以下では、各章でschema.xmlに関連する記載のある部分を抜粋して、変更点と変更したschema.xmlのリンクを用意しました。参考にしてもらえればと思います。\n1章 1.6.1 N-gram（17ページ） 1.6.1の手順に変更はありません。 サンプルプログラムが入っているZip「solrbook.zip」のintroduction/ngram/schema.xmlファイルの代わりに こちらのschema.xmlを利用してください。\n1.6.2 形態素解析（18ページ～20ページ中盤まで） 手順が大きく変わります。 Senを利用する場合、Senの辞書のビルド、Senのjarファイルの配置、Senを利用するためのTokenizerクラスを含んだサンプルjarの配置という作業があります。 lucene-gosenではコンパイル済みの辞書がjarファイルに含まれています。 また、Solr向けのTokenizerもlucene-gosenのjarファイルに含まれています。 lucene-gosenを利用して形態素解析を体験するための手順は次の流れになります。 なお、schema.xmlについては上記N-gramでダウンロードしたschema.xmlに形態素解析の設定もあわせて記載してあります。\njarファイル（lucene-gosen-1.2.0-ipadic.jar）をダウンロードして、$SOLR/example/solr/lib（libディレクトリがない場合は作成）にコピーします。 コピーが終わりましたら、次のように$SOLR/exampleディレクトリでSolrを起動します。 （-Dsen.homeは必要なし）\n$ java -jar start.jar あとは、書籍の記述にしたがって管理画面のAnalysis画面で動作を確認します。 ほぼ、図1-6と同じ結果になっていると思います。 （lucene-gosenで出力される情報には本書のサンプルよりも多くの情報が含まれています。また、サンプルでは、形態素解析の後の単語に基本形を採用しているため、「な」が「だ」として出力されています。基本形を出力する場合は後述するこちらで紹介したTokenFilterを利用すれば可能です。）\n2章 2.1.3 schema.xmlのバージョン（27ページ） Solr3.xではschema.xmlのファイルの最新バージョンは1.4になっています。\n2.2.3 代表的なトークナイザ（35ページ） solrbook.analysis.SenTokenizerFactoryは必要ありません。 先ほども説明しましたが、lucene-gosenにはSolr向けのトークナイザが用意されています。 solr.JapaneseTokenizerFactoryがそれに該当します。\n2.2.4 代表的なトークンフィルタ（37ページ） 以下の2つについてはlucene-gosenに同等のトークンフィルタが存在します。\nsolrbook.analysis.KatakanaStemFilterFactory solrbook.analysis.POSFilterFactory それぞれ、次のものがlucene-gosenにあるので、こちらを利用します。\nsolr.JapaneseKatakanaStemFilterFactory solr.JapanesePartOfSpeechStopFilterFactory 2章向けのschema.xmlはこちらです。その他のtxtファイルについては、特に変更はありません。\n3,4章は特に変更はありません。Solrの起動の仕方にだけ注意してください。（-Dsen.homeは必要ありません）\n以上が4章までの修正点になります。 動作しないなどあれば、コメントください。 サンプルアプリについてはまた後日余裕があれば。。。\n","date":1322244000,"dir":"post/2011/","id":"26d48d68b28f927bfebad454658f9425","lang":"ja","lastmod":1322244000,"permalink":"https://blog.johtani.info/blog/2011/11/26/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AElucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0%E3%81%8B%E3%82%894%E7%AB%A0/","publishdate":"2011-11-26T03:00:00+09:00","summary":"先週末から勤労感謝の日まで風邪で寝こんでました。。。 みなさん、朝晩、冷え込みが激しいので風邪には気をつけてください。 季節の言葉も入れたので本","tags":["lucene-gosen"],"title":"「Apache Solr入門」のサンプルのlucene-gosen対応（1章から4章）(Jugemより移植)"},{"contents":"今回は、触ろうと思って触れていないMongoDBの勉強会に行って来ました。 2週連続の渋谷で、さすがに今回は出口をすんなりでれました。 今回は初のGMOさんのビルへの潜入です。 ということで、いつものごとく自分のメモを残しておきます。\n日時 :2011/11/15 14:30 to 20:00 定員 :140 人 会場 :GMO Yours （セルリアンタワー（11階）） ハッシュタグ :#mongotokyo\n1.fluentd plugins for MongoDB @doryokujin スライドはこちら。\nFluentとMongoDBのコラボレーション ・Fluentとは？ 解析対象のログについて。データ量が膨大 これまでのログの扱い方。日次でS3に送信して、ログ解析サーバにて前日分を解析する。 これではリアルタイム性がないのが問題！しかも1日分なので、データ量が半端ない。 そこでFluentにてストリーミングアプローチ。 リレーサーバ（Fluentd）にログを流すと、適宜、解析サーバに流れていく仕組みが可能。 これにより、ネットワークに負荷をあまりかけずにログを定期的（時次とか）で流せる。 ※splunkに近い考えかな。 ここで、Fluentのスライドで説明が入りました。http://www.scribd.com/doc/70897187/Fluent-event-collector-update ・Out Mongo For Local Back-Up MongoDBへの出力。 信頼性をあげるためにローカルにmongoDBを置いておき、スプールしておく。 リレーサーバにも配置してみるという仕組み。 バッファリングにMongoDBを使うので Aggregation Mongoってのを作ったらしい。そのせいで、スライドの作成が遅れたらしいw ・Aggregation Mongo Map/Reduceの集約のようなプラグイン。 fluentdのアプリを通して、特定のキーをベースに集計してから、outputする仕組み。 更に、キーに対してshufleが行われて、次のfluentdにデータが集まる。　fluentdを使ってM/Rっぽいことが可能なのかな。 QA 最終的な流れ込み先のMongoDBはCappedCollectionじゃなくしたほうがいい。検索とかしたくなるから。 2.about Server Density and MongoDB @davidmytton スライドはこちら\nQueuingシステムで利用。 MongoDBとRabbitMQとの比較？ MongoDB関連のノウハウかな。 データ量に関する話。メモリに載せたほうがいいのかとか、ログ出力の設定とか、ジャーナルとか。 HDDの見積もりに関連しそう。 健康状態の監視方法。 コネクションプールの話とか。 rs＝ReplicaSet？ mongostatってコマンドがあるのか。 ServerDensityのツールとダッシュボードなどについて。 ※英語のスライド見ながら話聞くとメモがとれない。　まとめ： Keep it in Ram インデックスはメモリに載せましょう。 Watch your Strage ストレージのサイズは監視しましょう。（ログ、データ、ジャーナルなどなど） db.serverStatus()　コマンドあるよ。これで見れるデータが重要なのかな？ rs.stats()　コマンドあるよ。これで見れるデータが重要なのかな？ QA：残念ながら聞き取れなかったっすｗ Q：MongoDBのクエリログの統計の質問。DBごと？＝コレクションごと？のクエリ統計のとり方は？ A：MongoDBにはないので、ログレベルを下げて統計取ったりする方法しかないかなぁ。 3.MongoDB: Case Study for AMN @koyhoge スライドはこちら\nサービス（アジャイルメディア・ネットワーク）で利用している実例について 広告配信に関連して利用してる。 最初にPostgreSQLにて実装。5分おきにCronで再起動するはめに。。。 PostgreSQLの次にSimpleDBへ（インサートが遅い。分散インサート） SimpleDB＋SQSに変更。1日130$で断念。 SaaSなKVSはやめてMongoDBに移行してみる。 負荷も軽いし、インサートも速い！ EC2でMongoDB。しかもレプリカを東京A、B、シンガポールAにしてみよう。 shardingは残念ながらうまく行かず。 ストレージはEBSの1TB 4.「MongoDBとHadoopの蜜月関係」 @muddydixon スライドはこちら\nお父さんエンジニアなので、土曜日の勉強会は無理です！＝同じく辛いです！ HadoopとMongoDBのつなぎについて。 MongoDBからデータを読み込んで、Hadoopで計算してMongoDBに戻すものがmongo-hadoop データロストがニュースになってて心配してる。データロストはめったにない（by @doryokujin） Hadoopを計算だけに利用できるのでクラスタが落ちても気にせず立ち上げができそう。 MongoDBからデータを取得する時点でフィルタリングが可能なので、Hadoopでの演算が楽。 AdHocなクエリをMongoDBに投げれるのがうれしいのかな？ HBaseとかHiveに入れてやったりはダメなんかな？ QA Q：なんで、みんなMongoDBにログ入れるの？@kzk_mover A：様々な形式を入れやすいから。 Q：捨てるのどーするの？ A：コンパクションが大変（ただし、2.0以降は良くなる予定） Q：MongoDBのMap/Reduceは？ A：時間がかかった上に死ぬというひどい目にあったので。。。 5.Fusion-io @hasegaw\n340の仮想マシンが4台で動きます！ すごそう。。。一回は触ってみたいかも。 Fusion-ioすげーーーって感じ。（Ustストップ） 6.MongoDB on Cloud Foundry @yssk22\nVMWare社のPaaSオファリングの名称 感想など： mongoDBに興味はあるのに、腰が引けてるおじさんになって結局触らずに会場入りしてしまいました。 会場に入っていきなり、Treasure Dataの太田さんがマグカップを売っているという場面に遭遇するというインパクトがあるスタート。（思わず1個購入） 最初はMongoDB JPの主催者でもある@doryokujinさんの話から。今熱いfluentdとmongoDBの組み合わせに関する話で、面白かったです。 途中でfluentdを作っている古橋さんのスライドを用いてfluentdの解説まで入りました。 TL上では、その古橋さんが時々フォローを入れているという贅沢な流れ。 なんとなく仕組みはスライドなどを見ていたのですが、更に理解が深まりました。 次が、イギリスから来日されていた@davidmyttonさん（なんと24歳という若さ！）のお話。 残念ながら英語のヒアリングは微妙な私なので、あまり理解できなかったのですが、どうやら、MongoDBの運用でのTipsのお話だったようです。スライドを後で見なおしたほうがいいかな。 次は、実際のMongoDBを利用した事例の紹介。PostgreSQLから試行錯誤してMongoDB＋AWSの組み合わせのお話。 やはり実例があると面白いですね。試行錯誤された部分があるので、非常にわかりやすかったです。 次が、HadoopとMongoDBの組み合わせのお話。HadoopのMap/Reduceの部分だけを利用して、データ保存先はMongoDBにしましょうという割りきった話でした。 いくつか疑問点がメモにもありますが、残念ながら質問する勇気なしという腰抜けっぷり（もうちょっと積極的にならないと。。。） で、このあとFusion-ioとCloud Foundryの話になるのですが、体力切れ＋lucene-gosenのjavadocが古いことに気づいてしまい、作業をしながら聞いていたのであまり頭に残っていません。（ほんとに申し訳ない。。。） とまぁ、最近、Twitter上でいろんな人に絡みまくってまして、@doryokujinにも絡みまくってたというのもあり、今回参加することにしたという次第でした。 懇親会にも多くの人が残っており、良いコミュニティができてるなぁというのが正直な感想です。 各セッションでも@doryokujinさんが適宜QAなどのフォローをされていて感心しっぱなしでした。 あとは、Twitter上で会話をしていた方たちとも顔合わせができたので、大収穫でした。\n次は、少しでもいいので、触ってから参加することにしようかと思います。 来年1月にはMongo Tokyo 2012というイベントも開かれるようで、ますます注目を浴びていきそうですね。主催者もミドルウェアもｗ\nあ、そうそう、そんなMongoDBの勉強会でしたが、CouchDBの話もちらほら出てまして、CouchConf TOKYOというチラシも@Ijokarumawakさんから頂きました。こちらも1月開催のようです。\n追記： 戦利品の画像です。マグカップ（500円）以外は貰い物です。 なんと、このUSBにはMongoDBのコマンドやクエリのチートシート（PDF）が入ってました。びっくり！\n","date":1321376880,"dir":"post/2011/","id":"bda9a5da86ec9790262e14f953bbadcb","lang":"ja","lastmod":1321376880,"permalink":"https://blog.johtani.info/blog/2011/11/16/mongodb%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC7%E5%9B%9E%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-16T02:08:00+09:00","summary":"今回は、触ろうと思って触れていないMongoDBの勉強会に行って来ました。 2週連続の渋谷で、さすがに今回は出口をすんなりでれました。 今回は初","tags":["勉強会"],"title":"MongoDB勉強会（第7回）に行って来ました。(Jugemより移植)"},{"contents":"Solr本の武田さんから教えていただいたSplunkの イベントに行って来ました。 Splunkとは様々な機器のログなどを一箇所に集めてリアルタイムに検索、分析できるようにするための製品です。（ざっくりした説明ですが。。。） ちなみに、データ量が小さければフリー版も用意されています。 以前、話しを聞いていて気になっていた所イベントが開催されるということだったので参加してきました。 以下に、その時取ったメモを記載しておきます。いつものごとく、自分用のメモなので、役に立つかはわかりませんが。\nSplunk Live! in toyosu\n日時：2011/11/02　10:00-12:00 場所：豊洲\n1.挨拶＋アジェンダ紹介 2.ビッグデータ取り込み、ロードマップ（Splunk Inc.）CEO Godfrey Sullivan 英語でした。。。 データの種類と量が大きくなってきてるのに、ツールが追いつかないし、回答するのもはやくしろと言われる。 非構造化データの例としてApacheのログが出ていた。 TimeSeriesのフラットファイルがsplunkのデータのインデックス。（No RDB＝スキーマいらないよと。）　※ここが重要な点かもしれない。 リアルタイムに解析できるのが売り。Jubatusとの違いとか聞くと面白いかも。 Machine Data Engine＝Splunk データの関連付けの方法がどんなものか？ 事前のスキーマが不要＝流しこむ前には定義が必要？だよね？ ？No need to filter/forward？？ デベロッパーフレームワークってなんだ？？ Splunkbaseと呼ばれる場所にSplunk Appsと呼ばれるアプリケーションがある。色々な場所、OS、アプリで利用できるものらしい。 ？自動監視も学習する仕組みがある？？ それとも定義するのか？ あくまでもMachine Dataと言っている。これは、ユーザのリレーションの解析などはないということか？ Leading Social Gaming Company＝Zynga Introscopeのログバージョンに似てるかもなぁ。 Cloudベースのアプリの解析にも利用（saleforce） 色々な利用シーンのお話。 3.適用事例（独立行政法人理化学研究所） 和光と神戸で利用。10G程度のデータを扱ってる？ ログから情報基盤を監視するのに利用している。 syslogベースでsplunkにログを送信している。 事例１：VPNに接続できない（接続数上限がある？） CISCOのログから解析 どの研究室で発生しているかも検索。 事例２：DHCPの接続ミス？（IPアドレスロスト） ここまでは問題が発生してからログを漁るという使い方。 事例３：LINK FLAPのアラート 短時間にUPDOWNを繰り返す場合にスイッチがおかしくなってるんでは？ 事例４：メール大量送信（ウィルス感染） 不特定多数のサーバに短時間でメールを配信している ※使い方としては情報基盤環境すべて（ネットワークとかサーバなど）のログを集めておいて監視＋解析に利用して障害対応などに利用している？データセンターとかに入れるのか？ あくまでも、ログを保存して、検索できる仕組みが１箇所にまとめられているという感じ。 そのログの解析について（どういった問題に対して、どういったクエリを投げるか？どういったトラップを仕込むか？）は利用する側の腕にかかっている印象。 ※実際に触ってみたいなぁ。500M/dayか。ご近所に入れてみるか？syslogで転送設定＋入れるサーバが必要。 4.最新アプリなどの紹介（Splunk Inc.） GUIがきれいだなー（最近のgoogleっぽいが。。。） リアルタイムにデータが入っているのが見えるのか。おもろいな。 どこのフィールドにヒットしたかがファセットで表示できるらしい。おもろい。 flashでできたビューがすごくおもろかったぞ。（ドキュメントどこだ？） 5.最新の取り組み（NTTデータ先端） やっぱり武田さんだった。 複数の監視システムのメッセージを統合して検索、アラートを出せるようにする。 消費電力を算出するためにログを集めて集計する。 6.QA ロードマップ ・２年以内にビジネスサイドでの利用に向けての動きを見せていく予定。 ・アプリケーションフレームワークにして、他のパートナーのアプリを載せていきたい。 ということで、感想ですが、事例紹介などを聴いた感じだと今のところはインフラ系のログを一元化して検索、監視、アラートをあげるということに活用するためのツールの用に感じました。 当初の使い方がそういったところにあるためだとは思いますが。 開発者としての視点で話しを聞いていて、活用できそうだというのは次のシーンでしょうか。\n開発時の開発環境のログ集約 性能試験などでのログ、性能データ集約 開発時点もしくは性能試験時ですが、色々なサーバ（DBやアプリサーバ）の時間を横串にして表示検索などができると思うので、問題があった時の各種サーバの状態を一元的に見れるため、どのサーバにどういった負荷がかかっていたか、 どこに問題があったかなどをグラフ化して見ることが簡単にできるのではないかなぁという感想です。 あとは、ログが一元化されているので、問題があったときにまずログを検索すればいいのが楽ですかね。\n基本的にはログが集まってるからあとは、どう使うかはご自由にという印象でした。 どのようなログを集めておき、どういったトラップでアラートさせるか、どのような検索をすれば望んでいるログが出てくるか、どのような集計をしたいかなどについては、やはり導入してからノウハウを貯めていくか、導入時にコンサルしてもらうなどが必要かと。 また、このツールを入れることでどのようなフィードバックをどのように活用できるかをイメージしていなければ、 宝の持ち腐れになりそうです。 あとは、使い方次第ですが、サーバログ以外にアプリログ（ユーザの行動履歴とか）などを入れることで、インフラ以外での使い道もありそうです。 とりあえず、保存しておいて、あとから特定の傾向を見出すのに検索できるのはちょっと面白いかも。\nあ、そうそう、ストラップとUSBメモリ（4G）のノベルティをお土産にもらいました。無料セミナーなのに。\n","date":1320822000,"dir":"post/2011/","id":"cc1a3b2f107510ac664e491d5f2412aa","lang":"ja","lastmod":1320822000,"permalink":"https://blog.johtani.info/blog/2011/11/09/splunk-live%E3%81%AE%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-09T16:00:00+09:00","summary":"Solr本の武田さんから教えていただいたSplunkの イベントに行って来ました。 Splunkとは様々な機器のログなどを一箇所に集めてリアルタ","tags":["misc"],"title":"Splunk Live!のイベントに行って来ました。(Jugemより移植)"},{"contents":"最近忘れやすいので、記録しておこうかと。 読んだスライドの簡単な内容と感想です。 ちなみに、スライドの一覧はこちらです。 ※スライドへのリンクはすべてPDFへのリンクになっていますので、注意が必要です。\nSolr 4 Highlights（PDF）\nSolrの次期バージョン4.0で採用される機能の紹介でした。 紹介されているのは次の機能。各機能について、JIRAの番号も記載があるので便利ですね。\nDirectSolrSpellChecker NRT (Near RealTime search) Realtime Get SolrCloud - search side SolrCloud - indexing side (WIP) これまでと異なるSpellChecker、Commit前のデータが検索できるNRT（なんでNRSじゃないんだろう？）、Commit前の登録済みデータを取得することが出来るRealtime Getなどの簡単な紹介です。 あと、個人的に興味のあるSolrCloud周りが絵付きで紹介されてます。ZooKeeperもちょっと出てきます。 まだ、ちゃんとまとめてないですが、NewSolrCloudDesignの翻訳したものも参考までに。（その１、その２）\nArchive-It: Scaling Beyond a Billion Archival Web-pages\nInternetArchiveの事例紹介。1996年からWebページのアーカイブを行なっているサイトですね。 その一部でSolrが利用されています。 「1,375,473,187 unique documents」との記述もあり、データ量が巨大です。 データ量が多いのに、ここでFieldCollapsing/Groupingも利用しているようで、インデックス作成、検索両方に対してカスタマイズしたものをgithubで公開している模様です。\n[**Scaling search at Trovit with Solr and Hadoop**](http://www.lucidimagination.com/sites/default/files/file/Eurocon2011/MarcSturlese_scalingsearchTrovit_eurocon2011.pdf) 次は、Trovitという会社のSolr＋Hadoopの事例紹介です。 最初はLuceneをベースに検索サーバ作ってたけど、Solrが出てきたので、Solrを使うようになったようで。 データ保存先として最初はMySQLを利用してDataImportHandlerでSolrにデータ登録してたけど、 データ量が増加するが、MySQLのShardingが面倒なので、Hadoop（Hive）でデータをパイプライン処理してSolrのインデックスを作成しましょうという流れになったようです。 私が以前、Solr勉強会で紹介したSOLR-1301のパッチをベースにMap/Reduceの処理を2段階にして性能をアップさせたという話が記載されてました。 ただ、これで早くなるのかはよくわからないんですが。。。 一応、資料では、いきなり大きなSolrのインデックスを作らずに、最初のM/Rで小さなインデックスを作成し（TaskTrackerの数＞＞Solrのshardサーバ数だから小さくしたほうが速い？）、 2段目のM/Rでインデックスをマージしてshardサーバ数のインデックスに集約する？という形みたいです。 （英語力のなさが。。。） あとは、テキスト処理を幾つかHadoopでやってますよという紹介でした。 SOLR-1301の利用者が他にもいて、違うアプローチをとっていたのが印象的。 毎回全データインデックス生成するときは、SOLR-1301を利用してshard数が増えてもすぐに対応が可能になるので、 かなり便利ですよ。\nSolr @ Etsy\nEtsyは個人の作家（編み物とかシールとか）の方が出店するためのショッピングモールのようなサイトです。 実は、最近、MacBookAirのステッカーを購入したのがここでした。 で、検索にSolrを使っています。 面白いのが、検索サーバとWebアプリ（PHPで書かれている）の間のデータのやり取りにThriftを利用していること。 Solrの前にThriftを話すサーバを別途用意しているようです。ネットワークのデータ量を減らすことが目的らしいです。 そのあとは、少しThriftのサーバでのLoadBalancingの話が続きます。 次にレプリケーションの性能問題のはなし。定期的にレプリケーションに異様に時間がかかるのが問題になったようで、 Multicast-Rsyncを試してみたけどダメでしたというはなし。 Bit Torrent + Solrという組み合わせで回避したらしいのですが、いまいち仕組みがわからなかったです。。。 こちらもgithubに公開されている模様。 あとは、QParser、Stemmerをカスタマイズしたものの話です。\nArchitecting the Future of Big Data and Search\nLuceneのカンファレンスにHortonworksが出てきてびっくりしました。 まぁ、Luceneの生みの親＝Hadoopの生みの親ですから、問題ないのかもしれないですが。 大半が予想通り、Hadoopに関する話でした。 知らないApacheのプロジェクト「Ambari」というのが出てきました。これは、HadoopConferenceJapan2011 Fallでの発表にもチラッと出てきたようです。 「Ambari is a monitoring, administration and lifecycle management project for Apache Hadoop clusters.」ということで、Hadoopクラスタの統合管理のツールになるんでしょうか？ 最後の2枚くらいにLuceneが出てきます。絡めてみたって感じですかね。\nConfiguring mahout Clustering Jobs\n今度はMahoutが出てきました。はやりのものが満載です。 まぁ、MahoutもLuceneのインデックスを利用するという話もありますので。 スライドはクラスタリングとはどういうものか、Mahoutの説明とテキストクラスタリング処理のお話、最後はstuckoverflowでのMahoutとSolrの活用の仕方について。\nということで、英語力がない中、かなり流し読みな感じですが、あとで思い出すために書きだして見ました。 何かの役に立てれば幸いです。\n他に、こんなスライドが面白かったとか、このスライドについても書いてほしいなどあれば、コメントください。\n","date":1320724920,"dir":"post/2011/","id":"d9c6ab5c6630a4a84e242c5765103d2d","lang":"ja","lastmod":1320724920,"permalink":"https://blog.johtani.info/blog/2011/11/08/lucene-eurocon-2011-barcelona-%E3%81%AE%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%89%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-08T13:02:00+09:00","summary":"最近忘れやすいので、記録しておこうかと。 読んだスライドの簡単な内容と感想です。 ちなみに、スライドの一覧はこちらです。 ※スライドへのリンクはす","tags":["solr"],"title":"Lucene Eurocon 2011 Barcelona のスライド読みました(Jugemより移植)"},{"contents":"Bookscanというサービスがあります。 書籍を電子化（PDF）して原本を破棄してくれるサービスです。\n電子書籍にはずっと興味を持っていました。 技術書を購入するのですが、技術書は３００ページ超の大きな書籍が大半です。 また、日本語の技術書については、なかなか電子書籍が見つからないもしくは、電子化されるのが遅いとうのが現状です。 海外では、Manningなど、電子書籍も同時に発売（もしくは、製本前から電子書籍が売られている）サイトがありますが、やはり英語の書籍はハードルが高いなぁと。\nそんな中、Bookscanの噂を耳にしました。 ということで、どんどん、積ん読になっていく技術書だったので、思い切って、電子化してみることにしました。 ※残念ながらまだタブレット（電子書籍端末）は持っていないのですが。。。もうすぐ発売されるlenovoの7inchタブレットを待ちかねているところです。\nBookscanでは、１冊１００円で書籍をPDFにしてくれます。（ページ数により変わってくる） この場合、あくまでも書籍をスキャンするだけで、検索などはできません。 OCR処理については別途１冊１００円（これもページ数による）のオプションが必要になります。 詳しいサービス内容はこちらを御覧ください。 基本的には書籍をBookscanに発送してから約３ヶ月ほど電子化するのに時間がかかります。 これでは、すぐに見たい場合に手元にないという状態になってしまいます。 この電子化までの時間を短くできる、「プレミアム会員」というオプションが存在します。 月額固定の費用（９９８０円）を支払うことで、５０冊（※ページ数により１冊の単位が異なります）まで無料で、「スキャン＋OCR＋書籍名をファイル名」のPDFファイルを書籍到着後１週間以内で作成してもらうことができます。 また、プレミアム会員は月単位での契約が可能なようで、１ヶ月（＝５０冊）だけ早く電子化してもらうといった利用方法もできるようです。\nで、実際にプレミアム会員となって４９冊の書籍を送付して電子化してもらいました。 先週金曜日に発送、Bookscanに書籍が到着したのが翌土曜日、電子化が完了したのが火曜日の夜という感じでした。 すごくはやい！かなり感動してます。自炊自体をしたことがないので、出来上がりが自炊と比べてという比較はできないのですが、ざっと見ている感じでは全然問題なく読めそうです。\nただ、１冊の２ページだけ、ページの端が文章の途中で切れているPDFがありました。 この書籍に関しては、サポートサービスにお願いして、再スキャンをしてもらいました。 昨日夜に頼んで今日の午後には問題なく電子化されているというサービスの質でとても満足しています。 なお、原本の破棄が電子化後から１０日後に行われるため、問題ないかの確認はそれまでに行う必要があるようです。 大量の本を送る場合は小分けに送ったほうが確認するのが楽になると思います。（送料は小分けにした分、かかってしまいますが。）\n書籍の山になっていた机がすっきりして、とても満足しています。 せっかく電子化したので、早くタブレットが欲しいなと思う今日この頃。。。 基本的には今後は電子書籍を購入するようにしていく予定なので、プレミアム会員を継続することはないと思いますが、 家に溜まっている漫画を電子化するのもありかなぁと思っているところです 漫画の場合はOCRに掛ける必要もないですし。\n個人的にはBookscanさんには悪いのですが、もっと電子書籍が増えると助かります。 技術書はページ数が多く、重たいうえ、実際に利用するときは検索したくなることが多々ありますので。 あとは、電子書籍を検索できるサイトがあるといいなと思ってもいるところです。 現在は、各出版社が個別に電子書籍のHPを持っている状況で、会社によっては検索すらできないです。 電子書籍があるかないかだけでも簡単に検索できると、いいなと思っています。（小説などはまた別なのかもしれないですが。） みんなはどう思ってるんですかねぇ？検索したくないですか？\n","date":1320225060,"dir":"post/2011/","id":"7a9609a971a8f31685e88da563eea5ce","lang":"ja","lastmod":1320225060,"permalink":"https://blog.johtani.info/blog/2011/11/02/bookscan%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-11-02T18:11:00+09:00","summary":"Bookscanというサービスがあります。 書籍を電子化（PDF）して原本を破棄してくれるサービスです。 電子書籍にはずっと興味を持っていました","tags":["misc"],"title":"Bookscanを使ってみました(Jugemより移植)"},{"contents":"lucene-gosenの最新版（1.2.0）をリリースしました。\nプロジェクトページよりダウンロードが可能です。\n新規追加機能についてはこちらのエントリを御覧ください。\nバグなどありましたら、容赦なく報告をいただけると助かります。\n","date":1320043560,"dir":"post/2011/","id":"14cf6e75aec1ead888e7101d3d94d28a","lang":"ja","lastmod":1320043560,"permalink":"https://blog.johtani.info/blog/2011/10/31/1-2-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2011-10-31T15:46:00+09:00","summary":"lucene-gosenの最新版（1.2.0）をリリースしました。 プロジェクトページよりダウンロードが可能です。 新規追加機能についてはこちら","tags":["lucene-gosen"],"title":"1.2.0リリース(Jugemより移植)"},{"contents":"すぐやりますと言いつつ、はや1ヶ月。。。 腰が重い、ダメエンジニアですね。。。\nすみませんでした。。。 ようやくtrunkにコミットしました。 すぐにリリース版を用意すると思います。\n1ヶ月もあいてしまったので、追加した機能に関するまとめと、 用途別の利用方法を記載しておきます。 （lucene-gosenのWikiにもそろそろ書かないとなぁ。日本語でもいいから。）\n追加した機能\nこれまでのlucene-gosenはjarに辞書を含む形でライブラリを提供していました。 ただ、この場合、カスタム辞書を利用している環境ではカスタム辞書を修正し、ビルドしなおすたびに、 jarファイルを作成しなければなりません。 また、jarファイルをSolrなどに配布する必要も出てきます。 この手間を考慮して、辞書を外部ディレクトリで指定することができるようにしたものが 今回の修正になります。 また、修正の過程で同一VM内で異なる辞書を使えるようにする機能も副産物として生まれました。 今回追加した機能は次のようなものになります。 辞書を含まないjarのビルドおよび提供 ディレクトリ指定による辞書の指定 同一VM内での複数辞書の利用 辞書リビルド用のAntターゲットの追加 Lucene/Solr jarファイルの最新化（3.4.0対応） ディレクトリ指定による辞書の指定ですが、以下のような形になります。 まずは、LuceneのTokenizerでの指定方法です。 「辞書のディレクトリ」という引数が追加になっています。 ここに、辞書ディレクトリ（*.senファイルが存在するディレクトリ）を相対/絶対パスで指定します。\n... Tokenizer tokenizer = new JapaneseTokenizer(reader, null, \u0026#34;辞書のディレクトリ\u0026#34;); ... つぎは、Solrでの設定の方法です。 schema.xmlにて次のような設定を行います。\n... \u0026lt;fieldType name=\u0026#34;text_ja\u0026#34; ...\u0026gt; \u0026lt;analyzer\u0026gt; ... \u0026lt;tokenizer class=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; compositePOS=\u0026#34;compositePOS.txt\u0026#34; dictionaryDir=\u0026#34;辞書のディレクトリ\u0026#34;/\u0026amp;gt; ... \u0026lt;/analyzer\u0026gt; \u0026lt;/fieldType\u0026gt; ... schema.xmlの設定については、example/schema.xml.snippetにも説明がありますので、こちらもあわせて参考に。 なお、Solrの設定については、先ほどのLuceneでの辞書のディレクトリの指定方法（絶対/相対パス）に加えて、 $SOLR_HOME/conf からの相対パスでの指定も可能になっています。\nAntのターゲットについて\n辞書なしjarファイルを作成するターゲットなどを追加しています。 実際に追加したターゲットは以下のとおりです。 ターゲット名 説明 nodic-jar 辞書なしのjarファイルを生成するためのターゲット。辞書のダウンロード、コンパイルは行いません。 rebuild-dic lucene-gosenのビルド済み辞書（.senファイル）を削除してから辞書のコンパイル（ビルド）を行います。-Ddictypeにより辞書のタイプ（ipadic|naist-chasen）の指定が必要です。また、-Dcustom.dicsによりカスタム辞書の指定もあわせて可能です。 build-dic-ipadic テスト用に追加。-Ddictype=ipadicを指定してbuild-dicを実行。 build-dic-naist-chasen ついでに追加。-Ddictype=naist-chasenを指定してbuild-dicを実行。 最後の２つはあまり関係ありません。内部的に有ると便利だったため、作りました。 重要なのは最初の２つです。 ひとつめの「nodic-jar」は辞書を含まないjarファイルをビルドします。 このjarファイル＋辞書の入ったディレクトリを利用することで、辞書の外部化が可能となります。\nそして、「rebuild-dic」です。こちらは、以前記事に書きましたが、カスタム辞書のコンパイルが思いの外面倒だったので、ターゲットを追加しました。 次のように指定することで、辞書のリビルドが可能です。\n$ ant -Ddictype=naist-chasen -Dcustom.dcs=\u0026#34;custom1.csv custom2.csv\u0026#34; rebuild-dic 提供されるjarファイルについて\n提供されるjarファイルは次のようになる予定です。 1番目のjarファイルが今回追加になる、辞書なしのjarファイルになります。\nlucene-gosen-1.x.x.jar lucene-gosen-1.x.x-ipadic.jar lucene-gosen-1.x.x-naist-chasen.jar 用途別の利用方法 利用用途別に利用するjarファイルやantのターゲットを利用シーンを交えて想定を書いてみます。 Solrでの利用シーンを想定します。\nお手軽に使う。辞書ありjarファイルで一発インストール。 これまでどおりの使い方になります。 辞書込みのjarファイルを利用すれば、すぐに利用可能になります。\nカスタム辞書を使い倒す。定期的に辞書をメンテナンス。 定期的にシステム固有の単語が増える（例：製品名、新語など）場合です。\n利用するjar：lucene-gosen-1.x.x.jar 辞書のコンパイル＋配置：ant -Ddictype=naist-chasen -Dcustom.dics=\u0026ldquo;custom1.csv\u0026rdquo; rebuild-dir Solrの該当コアのRELOAD Solrのマルチコア環境を利用します。なお、sharedLib設定にlucene-gosen-1.x.x.jarを配置すると、辞書の再読み込みができないので注意してください。 設定は、上記のようにTokenizerFactoryの設定でdictionaryDirにて辞書のディレクトリを設定しておきます。 カスタム辞書に単語を追加後、antにて、辞書のリビルドを行います。 リビルドした辞書ファイルを必要に応じて対象の辞書ディレクトリにコピーします。（ビルド後のディレクトリをそのまま利用している場合はコピーの必要はないです。） 最後に、Solrの該当コアのリロードを行います。（リロードの仕方はこちらを参考に。） コアのリロードにより、辞書の再読み込みが行われるので、リロード後から新しい辞書が適用されます。\n異なる辞書を使い倒す。TokenizerごとにdictionaryDir設定するぞ 1つのSolrで異なる辞書を使ったフィールドを使いたい場合です。 ipadicとnaist-chasenといった異なる場合はあまり想定できないですが、カスタム辞書の部分が異なるという形が想定できるでしょうか。（例：製品名のフィールド、企業名のフィールド。。。など）\n利用するjar：lucene-gosen-1.x.x.jar 設定：schema.xmlに異なるdictionaryDirを設定したTokenizerFactoryを設定 上記、カスタム辞書の定期更新も一緒に行うことも可能です。コアをリロードすれば、リロードしたコアで利用している 辞書がすべてリロードされます。\n最後に 遅くなってしまいましたが、ようやく、trunkにコミットしました。 できるだけ速く、リリースしますので、もう少々お待ちを。\nSolrのconfディレクトリからの指定については、＠shinobu_aokiさんにパッチを提供してもらいました。 また、trunkにコミットしていないパッチを適用して記事を書いてくれた方もいらっしゃいました。こちらもあわせて参考に。私より説明が上手です。 Java製形態素解析ライブラリ「lucene-gosen」を試してみる\n","date":1319559120,"dir":"post/2011/","id":"14a6d294550c9760aec57ba29682a750","lang":"ja","lastmod":1319559120,"permalink":"https://blog.johtani.info/blog/2011/10/26/%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%A4%96%E9%83%A8%E5%8C%96%E3%81%A8lucene-solr3-4%E5%AF%BE%E5%BF%9C/","publishdate":"2011-10-26T01:12:00+09:00","summary":"すぐやりますと言いつつ、はや1ヶ月。。。 腰が重い、ダメエンジニアですね。。。 すみませんでした。。。 ようやくtrunkにコミットしました。 すぐ","tags":["lucene-gosen"],"title":"辞書の外部化とLucene/Solr3.4対応(Jugemより移植)"},{"contents":"JJUG CCC 2011 Fallに参加してきました。 個人的にはかなり久々のJavaのカンファレンスです。（※あくまで「Javaの」という話で。SolrやHadoopとは別という意味です。）\n概要やタイムテーブルはこちら。 予定があったので、残念ながら最後の２つのセッション（Scala、Twitter）しか参加できませんでした。 Hadoopの話も聞きたかったのですが、しょうがないかと。 いつものごとく、メモを個人的に取ったので。\n★楽々Scalaプログラミング 浅海 ◎OOPからOFPへの道しるべ ・関数型の使い所、プログラミングのコツ ・つながりの部分 ◎最近の活動 モデリングからモデル駆動によるソース生成などに利用。 Scala、2008年から使い始めている ◎Scalaと他の機能との比較図 ◎Scalaの用途 ・高い生産性 体感で3倍。コード量が少なくなる。 IDEのサポートを考えるとまだ、Java+Eclipseのほうが高い！ ・DSL ドメインモデルの記述 フレームワークAPI ・並行プログラミング Many Core 消費電力的に複数のコアで動かす＝関数型のほうが並行性が上がる（スレッドさわるJavaだけだときつい） Parallel Everything Object指向＋関数型が扱いやすい。 ◎関数型言語とは ・公開関数をあつかえる 関数を値として扱える、引数と返却地に関数を渡せる。（やさしめ） ＜＝＞ 数学（ラムダ計算、圏論など）的にプログラムを記述できる（きびしめ） ある程度使えるはず。厳しめの部分も ◎関数型言語の長所と短所 長所 ・高階関数を使った技が使える List（？？？） 短所 ・メモリ、関数実行オーバーヘッド、スタックの大きさが読めない（再帰的） ◎関数型言語の系譜 純粋関数型言語 pure Lisp 伝統的関数型言語 OCaml 新世代関数型言語 Haskell Scala 型クラス 代数データ型、モナド Parametric polymorphism ◎関数型でしたいこと DSL（Domain Specific Lanuguage） 昨年の資料を参考に！ ◎準備 scalaの文法 ◎並列コレクション スレッドを利用しないで並列に動作実行させるか？ ※List().par.map(sitelen).sum これで並行実行させられる。 ◎Future （これってJavaでもあるよね？＝あるよ） 処理を非同期で先行実行し、あとから結果を取得可能 Scalaではアクターライブラリでサポート（cala.actors） 関数合成するとFutureの実行結果を取り出す所でブロックされる！！ ◎Promise Futureより強力 関数合成すると、合成関数全体が非同期実行される！ scalazを利用してた ◎5つのコツ コツ１：　y=f(x) 引数がひとつの関数が基本 関数合成のビルディングブロックになるよ 引数が複数ある関数は他の関数（map関数とか）で合成しにくい 対処方法：カリー化（関数の戻りを関数とする） addc(a: Int)(b: Int) : Int = a + b とすることで、 コツ２：分割統治 コツ３：演算は転換 flatMapとかfoldLeftとか ※永続データ構造 前に作ったデータ コツ４：オブジェクトの世界と関数の世界を分ける 更新指示書の形でObjectに渡す？ 関数型データ構造 コツ５：新しいデザインパターン 関数型プログラミングの用語 ・Functor（関手） ・Subgroup（半群） ・Monoid（モノイド） ・Monad（モナド） OOPのデザインパターン的に考えれば、数学的なところまで理解しなくてもよさそう？ ★Twitterとオープンソース　@yusukey http://dev.twitter.com http://bit.ly/tdt-ja id：twj_dev ◎OSSとの関わり 支援してます。 Apache、Eclipse、Open Invention、JCP、OpenJDK パフォーマンス系のためにもOpenJDKに参画してる ◎Twitter API オープンなAPIで無償提供 １３言語でAPIライブラリがあるよ ◎Twitter4Jのこれまで ほぼ全てをカバー APIはだいぶ落ち着いてきていて、追加変更は少なくなってる。 ◎立ち位置 Twitterはコミュニティを活発にするためにもライブラリを出さないらしい。 ◎Twitter4Jのこれから キャッシング ストリーミングAPI利用を簡単に モックテスト レートリミットの影響を受けると辛いから。。。 ツイート/ユーザの永続化機能 jClouds対応？ ライブラリからフレームワークへ 半公式ライブラリへ github/twitter/twitter4jへ JSR Social API Twitter4Jが参照実装に？？？ スケーラビリティの話。 Hadoopはユーザのデータ解析とかに使ってる。 メッセージはキューイングしている。デモ。 memcachedプロトコルなんだけど、値を取ると値が消えるよ。（memcachedとは動きが違うよねー。プロトコル的にはクライアントがいっぱいあっていいよねー） RubyのGCがきつかったのでJavaベースに変更 Kestrel（Scalaで記述。） Kestrelのフォーカス外 メッセージの順序保証（してないよ） トランザクション memcachedプロトコルの拡張１ ブロックフェッチ コンシューマから取りに行くというのが特徴 memcachedプロトコルの拡張２ リライアブルフェッチ ということで感想。\nScalaは前から気になっていて、本までかってるのになかなか手を付けられていない始末でした。 そんな時にこのJJUGの話があったので、ちょうどいいと聞きに。 関数型やScalaのぼんやりしたイメージのみを持って聴いていたのですが、思った以上にキーワードが多くてついていくのがやっとというイメージ。 で、いつものごとく、Twitterでつぶやいていた所、色々な反応が。（わからずにつぶやいたのもあり、波紋を呼んだ模様） お陰で、Scala関連の方たちをフォローできたので結果オーライでした。 話の内容自体はサラっとながす感じだったので、再度資料を見る＋Scalaをもっと勉強しないと理解出来ないなぁという印象でした。 ちなみに、資料はこちら。\n次は、最近Twitterの中の人になった山本さん（@yusukey）の話しを聞きました。 Twitter4Jの話と、TwitterのOSSへの関わりの話。あとは、実際にTwitterが作成しているOSSのひとつKestrelについて。 TwitterはRubyベースで色々と作ってきていたのだが、Java（JVM上で動く言語（Scalaなど））に徐々にシフトしているというのが一番の印象です。あとは、Lucene、Hadoopなど私の興味のあるOSSも利用しているなど。 Kestrelについてはデモを交えながら、実際の動きを説明されていたのでとてもわかり易かったです。 プレゼン中もTweetを表示しながらという、さすがTwitterの中の人という印象でした。 Twitterでは少し前から知り合いだったのですが、実際にお会いできた（イケメンでしたよ！）のも収穫でした。 次はStormの話も聞きたいかなぁ\nで、２セッション（山本さんの話のあとにLT大会にも参加）だけですが、全体の感想を。 「クロスコミュニティカンファレンス」というだけあり、Java以外の話題（CouchDBとか名前がありました）もちらほらあったようです。 ただ、最近の他の勉強会やカンファレンスに比べると人が少ない印象でした。 私が参加したセッションは比較的大きな部屋だったせいもあり、40～50人くらい入っていたと思うのですが、ガラガラな印象でした。良い意味で、Javaも安定してきているため、参加者が少なかったのかなぁと あとは、年齢層がHadoopなどに比べると高めかなぁという印象（かく言う私も年齢層を上げている一人ですが。。。）。Javaも長いですからねぇ。 午前中から参加していると違った印象だったかもしれないですが。。。 あと、初めて行った会場で、しかも大きめの施設でした。午後の途中から行ったせいもあるかもしれないですが、 案内が出ていなくて若干迷子に。。。 ただ、セッションの部屋自体は各席に机があり、電源も比較的多めにあったので、PC持ち込みでメモを取るには最適でした。\n","date":1318922443,"dir":"post/2011/","id":"5d827a1e8ea70edb11d946b54f076cae","lang":"ja","lastmod":1318922443,"permalink":"https://blog.johtani.info/blog/2011/10/18/jjug-ccc-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-10-18T16:20:43+09:00","summary":"JJUG CCC 2011 Fallに参加してきました。 個人的にはかなり久々のJavaのカンファレンスです。（※あくまで「Javaの」という話で。SolrやHad","tags":["備忘録"],"title":"JJUG CCC 2011 Fallに参加してきました。(Jugemより移植)"},{"contents":"昨日、文章から特定の単語（リストあり）を探したいという話を聞き、lucene-gosenでもできるねぇという話になりました。 まぁ、考えてみればごくごく当たり前なのですが。。。（その筋の方たちにしてみれば常識なのかもしれないですが。。。） 一応やってみたので、こんなこともできるなという一例ですということで、記録を残しておきます。\n今回の例文として野田首相の所信表明演説の一部を活用させてもらいます。 単語のリストは次のようにします。\n内閣総理大臣 正心誠意 東日本 日本 今回も結果をわかりやすくするためにSolrのanalysis画面を利用します。 作業手順は以下のとおり。\ndictionary.csvの編集 辞書のコンパイル fieldTypeの定義（Solrのschema.xmlの設定） 文章からキーワード抽出（Solrのanalysis画面） ### **1.dictionary.csvの編集** 今回はnaist-chasenディレクトリで作業します。 なお、今回利用するlucene-gosenは[ここ](http://johtani.jugem.jp/?eid=21)で紹介した辞書分離バージョンです。（はやくtrunkにコミットせねば。。。） dictionary.csvを先ほど上げた単語だけのエントリに変更します。 キーワードだけを抽出したいので、他の単語は必要ないからです。 ``` \u0026ldquo;内閣総理大臣\u0026rdquo;,1,名詞,一般,,,,,\u0026ldquo;内閣総理大臣\u0026rdquo;,\u0026ldquo;ナイカクソウリダイジン\u0026rdquo;,\u0026ldquo;ナイカクソウリダイジン\u0026rdquo; \u0026ldquo;正心誠意\u0026rdquo;,1,名詞,一般,,,,,\u0026ldquo;正心誠意\u0026rdquo;,\u0026ldquo;セイシンセイイ\u0026rdquo;,\u0026ldquo;セイシンセイイ\u0026rdquo; \u0026ldquo;東日本\u0026rdquo;,1,名詞,一般,,,,,\u0026ldquo;東日本\u0026rdquo;,\u0026ldquo;ヒガシニホン\u0026rdquo;,\u0026ldquo;ヒガシニホン\u0026rdquo; \u0026ldquo;日本\u0026rdquo;,1,名詞,一般,,,,,\u0026ldquo;日本\u0026rdquo;,\u0026ldquo;ニホン\u0026rdquo;,\u0026ldquo;ニホン\u0026rdquo;\n\u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; ### **2.辞書のコンパイル** 先ほど作成した辞書をコンパイルし、lucene-gosen用バイナリ辞書を作成します。 $ cd $LUCENE_GOSEN_HOME¥dictionary $ ant -Ddictype=naist-chasen clean-sen compile\n\u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; ### **3.fieldTypeの定義（Solrのschema.xmlの設定）** Solrのschema.xmlにlucene-gosenを利用するフィールドタイプを定義します。 追加するのは次の通り \u0026lt;fieldType name=\u0026quot;text_ja\u0026quot; class=\u0026quot;solr.TextField\u0026quot; positionIncrementGap=\u0026quot;100\u0026quot; autoGeneratePhraseQueries=\u0026quot;false\u0026quot;\u0026amp;gt; \u0026lt;analyzer\u0026amp;gt; \u0026lt;tokenizer class=\u0026quot;solr.JapaneseTokenizerFactory\u0026quot; compositePOS=\u0026quot;compositePOS.txt\u0026quot; dictionaryDir=\u0026quot;keyword-dic\u0026quot;/\u0026amp;gt; \u0026lt;filter class=\u0026quot;solr.JapanesePartOfSpeechKeepFilterFactory\u0026quot; tags=\u0026quot;keeptags_ja.txt\u0026quot; enablePositionIncrements=\u0026quot;true\u0026quot;/\u0026amp;gt; \u0026lt;/analyzer\u0026amp;gt; \u0026lt;/fieldType\u0026amp;gt; また、ここで定義しているcompositePOS.txt、keeptags_ja.txtは次のようになります。 compositePOS.txt 未知語\nkeeptags_ja.txt 名詞-一般\n未知語がバラバラに出現しないようにして見やすくするためと、必要な単語（今回は「名詞-一般」しか利用しないため。）だけを抽出したいための設定です。 \u0026lt;/div\u0026gt; \u0026lt;div\u0026gt; **### 4.文章からキーワード抽出（Solrのanalysis画面）** あとは、analysis画面で解析して見るだけになります。 ということで、辞書に登録された単語だけが抽出されてますね。 この例ではインデックスに登録となりますが。 ただし、「東日本」「日本」のような一部を含む単語の場合、「東日本」が見つかった場合は「日本」は抽出されません。 あくまでも、ベストな解が見つかるのみという形です。 すべての単語を出したい場合はもう少しやり方を考えたほうがいいかもしれません。 （まぁ、このやり方でキーワードを抽出するかも考えたほうがいいかもしれませんが。。。） \u0026lt;/div\u0026gt; 最近、頭が硬くなってきてるなぁと実感してしまいました。まぁ、こんな使い方もあるかなぁと。 もっと頭を柔らかくして問題を解けるけるようになりたいなぁと。 ","date":1318389420,"dir":"post/2011/","id":"b9d4f73fa7ca8ef66891554b66b2cded","lang":"ja","lastmod":1318389420,"permalink":"https://blog.johtani.info/blog/2011/10/12/lucene-gosen%E3%81%A7%E6%96%87%E7%AB%A0%E3%81%8B%E3%82%89%E3%82%AD%E3%83%BC%E3%83%AF%E3%83%BC%E3%83%89%E6%8A%BD%E5%87%BA%E3%82%A4%E3%83%AC%E3%82%AE%E3%83%A5%E3%83%A9%E3%83%BC/","publishdate":"2011-10-12T12:17:00+09:00","summary":"昨日、文章から特定の単語（リストあり）を探したいという話を聞き、lucene-gosenでもできるねぇという話になりました。 まぁ、考えてみれ","tags":["lucene-gosen"],"title":"lucene-gosenで文章からキーワード抽出（イレギュラー？）(Jugemより移植)"},{"contents":"ちょっと間があいてしまったが、ようやくIoの1日目を終了。 なれない感じの言語なので苦労しました。 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大募集です。コメント欄にどしどしコメントください。そこは違うだろ？こっちのほうがいいのでは？という感じで。\n感想： プロトタイプ言語であり、すべての言語はクローンだそうです。\n○手始めに スロット、オブジェクトのクローンについて。 メッセージとその送信について。 あくまでもオブジェクトだけの世界。クローンであり、クラスのインスタンスではない。（まだつかめない。。。） ### ○オブジェクト、プロトタイプ、継承 slotNamesで取れないけど、継承してる。クローンで元をコピーしてるだけか？ 頭文字が大文字かどうかがtypeかどうかの違い。大文字＝type（クラスもどき＝） オブジェクト＝スロットの入れ物 オブジェクトのクローン＝オブジェクトのチェーン？（Object ＝＞ Vehicle ＝＞ Car ＝＞ ferrari） 疑問点： 存在しないスロット名をgetSlot()で呼び出したら？＝＞nilが返る 存在しないスロットをメッセージとして送信したら？＝＞Exceptionが出る ○メソッド method()で定義 メソッドもオブジェクト＝スロットに入れることができる（まだつかめない。。。） メソッドをスロットから呼び出すと実行される。 ○リストとマップ リスト、マップは簡単。幾つか（スタックやキュー）のメソッドも用意されてる。 ○true、false、nil、singleton cloneメソッドを最定義することでsingletonの動作にする。（言われてみれば当たり前か） Object cloneをオーバーライドすることもできるが、プロセス停止などしないとダメ。（恐るべし。。。） ○インタビュー SIMD（Single Instruction Multiple Data）http://ja.wikipedia.org/wiki/SIMD やりながら感想： シンタックスが全然違うのでかなり戸惑い。 ただ、考え方はシンプル。slotとか。 まだ、予約語がわかってない（cloneとかprintとかslotNamesとか）ので。 ★セルフスタディ （探してみよう） ○Ioのいくつかの問題点の例 見つけられず。。。英語がダメダメ。。。　○質問に答えてくれるIoコミュニティ\nML：http://tech.groups.yahoo.com/group/iolanguage/ twitter：http://twitter.com/#!/iolanguage **○Ioのイディオムに関するスタイルガイド** Io Note（英語） [http://iota.flowsnake.org/](http://iota.flowsnake.org/) Ioプログラミングガイド [http://iolanguage.com/scm/io/docs/IoGuide.html](http://iolanguage.com/scm/io/docs/IoGuide.html) [http://xole.net/docs/IoGuide_ja.html](http://xole.net/docs/IoGuide_ja.html)（日本語） Ioスタイルガイド [http://en.wikibooks.org/wiki/Io_Programming/Io_Style_Guide](http://en.wikibooks.org/wiki/Io_Programming/Io_Style_Guide) [http://d.hatena.ne.jp/katzchang/20080819/p1](http://d.hatena.ne.jp/katzchang/20080819/p1)（日本語訳してくれてるブログ） （確認してみよう） ○1 + 1を評価してから、1 + \u0026ldquo;one\u0026quot;を評価する。Ioは強く型付けされた言語か？\n``` Io\u0026gt; 1 + 1 ==\u0026gt; 2 Io\u0026gt; 1 + \u0026ldquo;one\u0026rdquo;\nException: argument 0 to method \u0026lsquo;+\u0026rsquo; must be a Number, not a \u0026lsquo;Sequence\u0026rsquo; message \u0026lsquo;+\u0026rsquo; in \u0026lsquo;Command Line\u0026rsquo; on line 1\nということで、型付けは強いです。 \u0026lt;/div\u0026gt; **○0は真か偽か？空文字列はどうか？nilは真か偽か？** \u0026lt;div\u0026gt; Io\u0026gt; 0 ==\u0026gt; 0 Io\u0026gt; true and 0 ==\u0026gt; true Io\u0026gt; true and \u0026quot;\u0026rdquo; ==\u0026gt; true Io\u0026gt; \u0026quot;\u0026quot; ==\u0026gt; Io\u0026gt; true and nil ==\u0026gt; false Io\u0026gt;\n0、空文字列はtrue、nilはfalseでした。 \u0026lt;/div\u0026gt; **○プロトタイプに存在するスロットを確認するにはどうすればよいか？** \u0026lt;div\u0026gt; Io\u0026gt; Highlander := Object clone ==\u0026gt; Highlander_0x1a233a0: type = \u0026ldquo;Highlander\u0026rdquo;\nIo\u0026gt; hoge := Highlander clone ==\u0026gt; Highlander_0x1a83630:\nIo\u0026gt; hoge proto slotNames ==\u0026gt; list(type) Io\u0026gt; Highlander name := \u0026ldquo;arnold\u0026rdquo; ==\u0026gt; arnold Io\u0026gt; hoge slotNames ==\u0026gt; list() Io\u0026gt; hoge proto slotNames ==\u0026gt; list(type, name) Io\u0026gt; Highlander slotNames ==\u0026gt; list(type, name) Io\u0026gt; hoge name ==\u0026gt; arnold Io\u0026gt; hoge getSlot(\u0026ldquo;name\u0026rdquo;) ==\u0026gt; arnold\nこんな感じ。slotNamesでスロット名を確認し、スロット内部についてはgetSlotで確認できます。 \u0026lt;/div\u0026gt; **○等号（=）、コロン等号（:=）および、コロンコロン等号（::=）の違いはなにか？どのようなときに使うか？** \u0026lt;div\u0026gt; \u0026lt;table class=\u0026#34;list_view\u0026#34;\u0026gt; \u0026lt;thead\u0026gt; \u0026lt;tr\u0026gt; \u0026lt;th\u0026gt;演算子\u0026lt;/th\u0026gt; \u0026lt;th\u0026gt;説明\u0026lt;/th\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;/thead\u0026gt; \u0026lt;tbody\u0026gt; \u0026lt;tr class=\u0026#34;spec\u0026#34;\u0026gt; \u0026lt;td\u0026gt;:::=\u0026lt;/td\u0026gt; \u0026lt;td\u0026gt;スロットへの代入＋setterの追加\u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr class=\u0026#34;specalt\u0026#34;\u0026gt; \u0026lt;td class=\u0026#34;alt\u0026#34;\u0026gt;:=\u0026lt;/td\u0026gt; \u0026lt;td class=\u0026#34;alt\u0026#34;\u0026gt;スロットへの代入\u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;tr class=\u0026#34;spec\u0026#34;\u0026gt; \u0026lt;td\u0026gt;=\u0026lt;/td\u0026gt; \u0026lt;td\u0026gt;スロットへの代入（ただし、スロットが存在しない場合は例外が発生）\u0026lt;/td\u0026gt; \u0026lt;/tr\u0026gt; \u0026lt;/tbody\u0026gt; \u0026lt;/table\u0026gt; とまぁ、記載したが、実際に動かして確認しました。 Io\u0026gt; Highlander := Object clone ==\u0026gt; Highlander_0x223b800: type = \u0026ldquo;Highlander\u0026rdquo;\nIo\u0026gt; hoge := Highlander clone ==\u0026gt; Highlander_0x21acd60:\nIo\u0026gt; hoge slotNames ==\u0026gt; list() Io\u0026gt; hoge name ::= \u0026ldquo;arnold\u0026rdquo; ==\u0026gt; arnold Io\u0026gt; hoge slotNames ==\u0026gt; list(setName, name) Io\u0026gt; hoge sword := \u0026ldquo;long sword\u0026rdquo; ==\u0026gt; long sword Io\u0026gt; hoge slotNames ==\u0026gt; list(setName, name, sword) Io\u0026gt; hoge clothes = \u0026ldquo;armor\u0026rdquo;\nException: Slot clothes not found. Must define slot using := operator before updating. message \u0026lsquo;updateSlot\u0026rsquo; in \u0026lsquo;Command Line\u0026rsquo; on line 1\n\u0026lt;/div\u0026gt; ### （試してみよう） **○ファイルからIoプログラムを実行せよ** \u0026lt;div\u0026gt; ファイル「great.io」を作成し、以下を入力。 Highlander := Object clone Highlander giveWarCry := \u0026ldquo;Woooooooo!!\u0026rdquo; println Highlander giveWarCry()\nで、以下のコマンドを実行する。 $ io great.io Woooooooo!!\n\u0026lt;/div\u0026gt; **○スロットの名前を指定して格納されているコードを実行せよ** \u0026lt;div\u0026gt; Io\u0026gt; Masason := Object clone ==\u0026gt; Masason_0x20ae7d0: type = \u0026ldquo;Masason\u0026rdquo;\nIo\u0026gt; Masason recieveNiceTweet := method(\u0026ldquo;やりましょう\u0026rdquo; println) ==\u0026gt; method( \u0026ldquo;やりましょう\u0026rdquo; println ) Io\u0026gt; Masason getSlot(\u0026ldquo;recieveNiceTweet\u0026rdquo;) ==\u0026gt; method( \u0026ldquo;やりましょう\u0026rdquo; println ) Io\u0026gt; Masason getSlot(\u0026ldquo;recieveNiceTweet\u0026rdquo;) call やりましょう ==\u0026gt; やりましょう\ncallとgetSlotが鍵ですね。 \u0026lt;/div\u0026gt; 1日目の途中で間があいてしまったのでシンタックスを忘れてしまう始末。。。 ただ、そんなに込み入った記述もないので、最初に勉強することは少ないかもしれないです。 まだメソッドをあとから追加とか、cloneしたあとにまたプロトタイプを変更して反映可能など、考え方になれないもところがありますが、良い頭の体操になってます。 間を置かずに3日目まで行かないと！！ ","date":1317990120,"dir":"post/2011/","id":"dc962e34780f0374b7eb3d583f6d7eb6","lang":"ja","lastmod":1317990120,"permalink":"https://blog.johtani.info/blog/2011/10/07/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-1%E6%97%A5%E7%9B%AE/","publishdate":"2011-10-07T21:22:00+09:00","summary":"ちょっと間があいてしまったが、ようやくIoの1日目を終了。 なれない感じの言語なので苦労しました。 今回もセルフスタディの私の回答が最後の方に記","title":"「7つの言語　7つの世界」 Io 1日目(Jugemより移植)"},{"contents":"久々に、MBAの備忘録です。 あれから色々入れました。 なので、入れたソフトの一覧を追加。\nAIR：TweetDeckをインストールするのに必要だったため TweetDeck（AIR版）：TwitterとFacebookを同じ画面で見ることができるため。 TextWrangler：テキストエディタ（まだあんまり使ってない） Skitch：Evernoteに買収されて無料に。先日のSolr管理画面の説明書きにもちょっと使用 ClamXav：フリーのセキュリティソフト。 SourceTree：Twitterで知ったMac用のgit、mercurialのクライアントソフト。AtlassianがSourceTreeを買収したのを機に一時的に無料公開されていたので。 Firefox：基本はSafariを使ってます。WindowsではChromeを使ってます。ただ、Webページを表示されていない部分もまるごとキャプチャするのにChromeのプラグインだとダメだったので入れました。今のところキャプチャ用のブラウザです。 Full Screen enable for Eclipse on Lion：Eclipseをフルスクリーン対応するためのプラグイン MercurialEclipse：bitbucketにアカウントをもっているので。 mercurial：pipを使ってインストール。MercurialEclipseでコマンドが必要だから。「sudo pip install Mercurial」 pip：mercurialをインストールするためにインストール。「sudo easy_install pip」でインストール iStat pro（ウィジェット）：CPUなどの情報を表示するウィジェット。ウィジェットがアップルのサイト（AppStoreではない）から検索できるというのを人から聞いた。ウィジェットってあんまり使われないのか？ Mac Blu-ray Player：現時点で有料ソフトはこれだけ。こちら。もともとNASのデータのバックアップ用にBlu-rayのドライブ買ったんですが、せっかくだからMacにも使ってみようと思い、MacでBlu-rayを見るために購入しました。所用で長距離移動もあったので、新幹線で映画見てました。 このくらいです。 ほんとはリンクを貼ればいいのですが、そこまでの元気がないので、ご勘弁を。\nSkitchがおすすめです。簡単に画像編集＋説明書きが入れられて、矢印などがよくある画像編集の野暮ったさがないので、画面キャプチャに説明書くのに今後活躍する予定です。\nあと、ソフトではなく、サービスなのですが、Cacooというサービスが便利です。 ここ最近、ちょっとした作図にはこのサービスを使うようにしています。オンラインで利用できるので、いろんな場所で編集できます。 また、図の作成もさることながら、図を共有することが可能です。 先日は、lucene-gosenが思ったように動かないという相談を受けて、このCacooでanalysis画面や設定をを貼ってもらったりしながら使いました。結構便利ですね。 ただ、付属のチャットを使ったのですが、このチャットの内容がテキスト形式でコピー出来なかったのが残念でした。今後の改修に期待ということで。\nあと、セットアップとは少し違いますが、ジャケット買ってつけました。 ステッカーを直接貼るのがちょっと気になったので、ジャケットつけてステッカーを貼ってます。 ただ、ステッカーは思ったよりチープな感じが。。。ジャケットの中に貼らないとダメだったかも。まぁ、それが嫌でジャケット買ったんですが。。。 エアージャケットセット for Macbook Air 13inch(クリア)PMC-81 ","date":1317968700,"dir":"post/2011/","id":"de1ab82817c0fb24e591b9a89a82f736","lang":"ja","lastmod":1317968700,"permalink":"https://blog.johtani.info/blog/2011/10/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%94/","publishdate":"2011-10-07T15:25:00+09:00","summary":"久々に、MBAの備忘録です。 あれから色々入れました。 なので、入れたソフトの一覧を追加。 AIR：TweetDeckをインストールするのに必要だ","tags":["備忘録"],"title":"MBAセットアップ備忘録その４(Jugemより移植)"},{"contents":"Lucene/SolrのMLでSolrの管理画面を新しくするというチケットが流れていたのでちょっと触って見ました。 ほんとにちょっと触っただけですが、いくつかキャプチャ撮ってみたので、アップしときます。 ※以下ではサムネイル画像に元画像（100Kくらいの画像）へのリンクが設定されています。携帯などでは見づらいかもしれませんが、ご容赦を。\nURLは旧管理画面とことなり、http://localhost:8983/solr/になります。\nまずはトップ画面 ダッシュボードと呼ばれるトップ画面。メモリの利用率や起動してからの時間、Luceneなどのバージョンが表示されます。 次は検索画面すっきりしてます。facetが指定できるようになったのは大きいかな。ただし、facet.fieldを複数指定などができないが。結果についてはとくに指定がなければXMLで帰ってきます。ただ、パラメータの追加ができなくなってる気がするなぁ ちなみに、Solrを止めて検索したらこんな感じの画面になりました。クエリの実行ならこのようにエラーがわかったのですが、停止後に左のメニューにあるSchemaなどをクリックしても白い画面が出るだけで、エラーかどうかがわかりにくいです。 Analysis画面。入力画面がシンプルになりました。フィールド名はリストで表示されるので選択するだけです。あとは、これまでどおり。サンプルはlucene-gosenの解析結果です。ハイライトもきちんと表示されます。ただし、長い文章の場合は結果部分だけがスクロールできる形になり、ちょっとわかりにくかったです。 Analysisの入力画面を表示したあとにSolrを停止して解析してみたらこんなエラー画面が出ました。ちなみに、その後、画面を切り替えずにSolrを起動して解析したら、赤い帯のエラーは出たままでした。一度別画面にすれば、元に戻りますが。 Pluginsの画面（旧管理画面のstatisticsに相当）。 キャッシュの状態が確認できます。今まであった画面と情報的には一緒かと。一段カテゴリ（CACHEとかCOREとか）の選択ができるようになり、見やすくなりました。 同じくPluginsの画面。 こちらはupdateHandlerについての情報です。commit数やoptimizeの回数、updateして、commitする前の状態のドキュメント数などが表示されます。前より表示される項目が多くなってるかな？ 最後はスキーマブラウザこの画面が一番良くなっています。旧管理画面では、フィールド名がすべて大文字で表示され、しかもソートがされていない状態だったため、ダイナミックフィールドを利用しているとフィールドを探すのが一苦労でした。 今回は、プルダウンでフィールドやフィールドタイプのリストが表示され、辞書順で並んでいます。Filterなどもわかりやすい表示になっているかと。 おまけ Solritasと呼ばれるVelocityを使った、3.x系で入ってきた新しいサンプル画面です。URLはhttp://localhost:8983/solr/browseです。ファセットなどを使った簡単なサンプル画面なので、検索結果画面でこんなことができるというデモにも使えるかと。ただ、これも旧管理画面よりはましですが、デザインが。。。 とまぁ、簡単ですが、4.x系の管理画面をいくつか触ってみて、キャプチャをとって見ました。 デザインは前よりもすっきりしています。ただ、クエリについてはパラメータの追加ができなくなっているので、もう少し改良されるといいかなぁ（自分でやれよと言われそうですが。。。）\n","date":1317811380,"dir":"post/2011/","id":"09677934e13a5d728f00c6ed7c8870a9","lang":"ja","lastmod":1317811380,"permalink":"https://blog.johtani.info/blog/2011/10/05/solr%E3%81%AE%E6%96%B0%E3%81%97%E3%81%84%E7%AE%A1%E7%90%86%E7%94%BB%E9%9D%A2solr4-x-trunk%E7%B3%BB/","publishdate":"2011-10-05T19:43:00+09:00","summary":"Lucene/SolrのMLでSolrの管理画面を新しくするというチケットが流れていたのでちょっと触って見ました。 ほんとにちょっと触っただけ","tags":["solr"],"title":"Solrの新しい管理画面（Solr4.x trunk系）(Jugemより移植)"},{"contents":"遅くなりましたが、続きです。 さらに英語力のなさを痛感して凹んでいるところですが、何かの役に立てばと恥を晒すところです。。。\n一応、訳してみたのですが、訳すのに必死になってしまい、つながりがわかっていない点もちらほら。 このあと一旦見直しつつ、再度理解する「理解編」をアップしようかと思います。 できれば、シーケンス図とかも交えつつ。（そうしないと理解ができない可能性が。。。） 前回同様、原文は最後に付加しておきます。\nBoot Strapping Cluster Startup（クラスタの起動） ノードはZookeeperのホストとポートを指定することから始めます。 クラスタの最初のノードはクラスタのschema/configとクラスタの設定を指定するとこから開始します。 最初のノードはZookeeperに設定をアップロードしてクラスタをブートします。 クラスタは「ブートストラップ」状態です。 この状態ではノード-\u0026gt;パーティションマッピングは計算されず、クラスタはクラスタ管理コマンド以外のどんなread/writeリクエストも受け付けません。\nクラスタの最初のノード集合が起動した後、クラスタ管理コマンド（TBD記述？？？）が管理者によって発行されます。このコマンドは整数「partitions」パラメータを受け取り、次のステップを実行します。\nCluster Lockを取得 「partitions」をパーティション数として割り当て 各パーティションのためのノードを取得 ZooKeeperのノード-\u0026gt;パーティションマッピングを更新 Cluster Lockをリリース 全ノードに対して最新版のノード-\u0026gt;パーティションマッピングをZooKeeper経由で更新させる Node Startup ノードが起動すると、自分がすでに存在するシャードの一部かどうかZooKeeperでチェックします。 もし、ZooKeeperがノードのレコードを持っていない、またはどのシャードの一部でもないと判断したら、 ノードは後述の「New Node」のステップを実行します。すでに存在するノードの場合は後述の「Node Restart」のステップを実行します。\nNew Node\n新しいノードはクラスタの一部ではなく、クラスタのキャパシティを増強するためのものです。\n「auto_add_new_nodes」クラスタプロパティが「false」の場合、新しいノードはZooKeeperに「idle」として登録され、他のノードが参加してくれと言うまで待機します。 そうでない場合（auto_add_new_nods=true）は次のステップを実行します。\nCluster Lockを取得します。 適切なnode-\u0026gt;partitionエントリを選び出します。 利用可能なパーティションのリストをスキャンして「replication_factor」のノード数以下のパーティションのエントリを探します。複数ある場合はノード数が最小のエントリを選びます。それも一緒ならランダムに選びます。 全パーティションが「replication_factor」以上のノードを持っている場合、ノードはパーティションが最も多いものをスキャンします。複数ある場合はパーティション内のドキュメント数が最大のエントリを選びます。ドキュメント数が同一なら任意のエントリを選びます。 もし、選んだノード-\u0026gt;パーティションエントリを現在のノードに移動させることでがクラスタのパーティション：ノード比率の最大値を小さくするなら、現在のエントリを返します。。それ以外の場合選ばれたエントリがないので、アルゴリズムは終了です。。 ZooKeeper内のノード-\u0026gt;パーティションマッピングを更新します ZooKeeper内のノードステータスを「リカバリ」状態にします Cluster Lockをリリースします 「リカバリ」はパーティションのリーダーから開始します。 リカバリが終了したら、再度、Cluster Lockを取得します。 元のエントリはZooKeeperのノード-\u0026gt;パーティションマッピングから削除されます。 Cluster Lockをリリースします 元のノードはZooKeeperからノード-\u0026gt;パーティションマッピングを更新させられます ステップ1に戻ります。 Node Restart ノードの再起動とは次のいずれかを意味しています。\nJVMがクラッシュし、手動または自動でのリスタート ノードが一時的にネットワークから切り離された。もしくは、ZooKeeperに接続できなかった（死んでいると思われた）。または、ある一定期間、リーダーからの更新を受信できなかった。 このシナリオが表す書き込み処理のライフサイクルの間にネットワークから分断された ハード故障もしくはメンテナンスウインドウによりクラスタからノードが分断され、ノードをクラスタにrejoinさせるために起動した。 ノードが各パーティションに対してメンバーであるパーティションのリストを読み、パーティションのリーダーがリカバリプロセスを実行する。その時、ノードは「auto_add_new_nods」プロパティをチェックして、「New Node」処理のステップを実行する。 これはクラスタが。。。（元の文章が切れてて意味が不明）\nクライアントは標準的なSolrの更新形式を利用して書き込みできます。 書き込み処理はクラスタの任意のノードに送信されます。 ノードはハッシュ関数を利用して、どのパーティションに所属するか決めるためにrange-パーティションマッピングを使います。 ZooKeeperはシャードのリーダーを識別して、書き込み処理をそこに送ります。 SolrJはリーダーに対して書き込みを直接送信するための拡張がされています。\nリーダーはPartitionバージョンの操作を割り当て、そのトランザクションログの操作を書き込み、シャードに属する他のノードにドキュメントバージョンハッシュを転送します。 ノードはインデックスにドキュメントハッシュを書き込み、トランザクションログに操作を記録します。 リーダーは、min_writesの最小数のノード以上のノードが「OK」とレスポンスを返したら「OK」とレスポンスを返します。 クラスタプロパティのmin_writesは書き込みリクエスト時に指定することで、異なる値を指定できます。\nクラウドモードはコミット/ロールバック操作を明示的には行いません。 コミットは特定の間隔で（commit_within）リーダーによりオートコミットにより管理されます。 また、シャードの全メンバーのコミットはトリガーにより管理されます。 ノードが利用可能な最新バージョンはコミットの時点で記録されます。\nTransaction Log トランザクションログは2つのコミットの間にインデックスに対して実行された操作全てを記録したもの コミットはそれ以前に実行された操作の耐久性を保証するために、新しいトランザクションログを開始します。 同期は調整が可能です。例えば、flush vs fsynです。fsyncがデフォルトで、JVMクラッシュに対して保証できるが、電源異常の場合には保証できないが、速度的には早いです。 Recovery 次のトリガーにより復旧が可能です。\nBootstrap パーティション分割 クラスタの再構築 ノードは自身に「recovering」というステータスを設定して復旧を開始します。 このフェーズの間、ノードは読み込みリクエストを受けることができませんが、トランザくkションログに書きこまれるすべての新しい書き込みリクエストを受け取ります。 ノードは自身が持つインデックスのバージョンを調べて、パーティションの最新バージョンのリーダーに問い合わせます。 リーダーはシャード内の残りのノードと同期する前に実行されるべき操作の集合を返します（？？？）。\n最初にインデックスをコピーし、最新のノードにあるトランザクションログをリプレイします。 もし、インデックスのコピーが必要ならば、インデックスファイルをローカルにまずコピーし、その後トランザクションログをリプレイします。 トランザクションログのリプレイは通常の書き込みリクエストの流れと同じです。 この時、ノードは新しい書き込みを受け付けるかもしれません。その書き込みはインデックスに再生されるべきです。 ある時点でノードは最新のコミットポイントに追いつき、自身のステータスを「ready」にします。 この時点で、このノードは読み込みリクエストを処理できます。\nHandling Node Failures 一時的にネットワークが分断され、幾つかのノードとZooKeeperの間の通信が遮断されるかもしれません。 クラスタはデータの再構築（リバランシング）の前にしばらく待ちが発生します。\nLeader failure\nノードが故障し、もしそれがシャードのリーダだった場合、他のメンバーがリーダー選出のプロセスを開始します。 新しいリーダーが選出されるまで、このパーティションへの書き込みは受け付けられません。 この時、これはリーダー以外の故障ステップを処理します。（？？？）\nLeader failure\nシャードの一部に新しいノードが割り当てられる前にリーダーはmin_reaction_timeの間待ちます。 リーダーはCluster Lockを取得し、シャードの新規メンバーとしてノードを割り当てるためのノード-シャード割り当てアルゴリズムを使用します。 ZooKeeperのノード-\u0026gt;パーティションマッピングが更新され、Cluster Lockがリリースされます。 新しいノードはZooKeeperからノード-\u0026gt;パーティションマッピングを強制的にリロードされます。\nSplitting partitions 明示的なクラスタ管理コマンドもしくはSolrによる自動的な分割戦略（ストラテジ）はパーティションを分割することができます。 明示的な分割コマンド（split command）は対象となるパーティションを分割するために実行されます。\nパーティションXが100から199のハッシュの範囲を持つものとし、X（100から149）、Y（150～199）に分割するとします。 Xのリーダーは、XとYの新しい値の範囲をZooKeeperに分割アクションを記録します。 ノードはこの分割アクションもしくは新しいパーティションの存在については通知を受けません。（？？？）\nXのリーダはCluster Lockを取得し、パーティションY（アルゴリズムはto be determined）を割り当てるノードを決定し、新しいパーティションを知らせ、パーティション-\u0026gt;ノードマッピングを更新します。Xのリーダはノードのレスポンスを街、新しいパーティションがコマンドを受付可能な状態になったら次の処理を実行します。 Xのリーダーは分割が完了するまですべてのコミットを停止します。 Xのリーダーは最新のコミットポイント（バージョンVとする）のIndexReaderをオープンし、同じバージョンのIndexReaderもオープンするように命じます XのリーダーはYのリーダーに対してバージョンV以降のトランザクションログのうちハッシュ値の範囲が150から199のものを流します。 Yのリーダーはトランザクションログの#2（#3の間違い？）で送られたリクエストだけを記録します？？？ Xのリーダーはステップ#2で開いたIndexReaderに対してインデックスの分割を開始します。 #5で作成されたインデックスはYのリーダーに送られ、登録されます。 Yのリーダーは「recovery」プロセスを開始するように（シャードの）他のノード命令し、インデックスのトランザクションログを再生し始めます。 パーティションYのすべてのノードがバージョンVに到達したならば YのリーダーはXのリーダーに#2で作成されたReaderの上に、ハッシュの範囲が100から149だけに属しているドキュメントを抽出するようにするFilteredIndexReaderを準備するように頼みます。 Xのリーダーは#8aのリクエストが完了したのを検知したら、YのリーダーがCluster Lockを取得し、クラスタ全体の検索/登録リクエストの受信を開始するためにレンジ-\u0026gt;パーティションマッピングを変更します。 YのリーダーはXのリーダーに検索リクエストのために#8aで作成されたFilteredIndexReaderの利用開始を頼みます YのリーダーはXのリーダーに、ZooKeeperからレンジ-\u0026gt;パーティションマッピングを矯正リフレッシュするように頼みます。この時点で#3で開始されたトランザクションログの流しこみが停止されるのが保証されます。 Xのリーダーは自身のパーティションに存在するべきでないハッシュ値をもつドキュメントを削除し、最新のコミットポイントのsearcherを再度開きます。 この時点で分割は完全に終了し、Xのリーダーはcommit_withinパラメータによるコミットをレジュームします（？？？） Notes:\n分割操作が完了するまで、commit_withinパラメータによるパーティションの分割は実行されない #8b開始から#8c終了までの間の分散検索は一貫しない検索結果を帰す場合がある（例えば：検索結果が異なる） Cluster Re-balancing クラスタは明示的なクラスタ管理コマンドにより再構築（リバランシング）できる。\nTBD （to be determined）\nCluster Re-balancing TBD （to be determined）\nConfiguration solr_cluster.properties これはクラスタ内の全ノードにわたって適用される一般的なSolr設定ファイルとは別のプロパティファイルの集合である。\nreplication_factor：クラスタによって管理されるドキュメントのレプリカの数 min_writes：書き込み操作が成功になる前の最小の書き込み？？？？。これは書き込みごとに上書き設定可能 commit_within：検索に現れるまでの書き込み操作の最大回数 hash_function：ドキュメントのハッシュ値を計算するための関数の実装 max_hash_value：ハッシュ関数が出力することができる最大値。理論的には、この値はクラスタが保持できるパーティションの最大数でもある min_reaction_time：起動、停止の後に再配分/分割にかかる時間（？？） min_replica_for_reaction：レプリカノード数がこの値以下になったら、min_reaction_timeにならなくても分割が実行される。 auto_add_new_nodes：booleanフラグ。もしtrueなら新しいノードは自動的にパーティションからレプリカを読み込む。そうでない場合は新しいノードはクラスタに「idle」状態で登録される Cluster Admin Commands すべてのクラスタ管理コマンドはすべてのノードでパス（/cluster_admin）を与えることで実行できます。 全ノードは同じコマンドを受け付けることができ、振る舞いも同じものになるでしょう。 以下のコマンドはユーザが利用できるパブリックなコマンドです。\ninit_cluster：（パラメータ：パーティション）このコマンドはノードの集合の初期化後に実施されます。このコマンドが実行されるまで、クラスタは読み込み/書き込みコマンドを受け付けません。 split_partition：（パラメータ：パーティション（任意））パーティションを2つに分割します。もしパーティションパラメータが指定されない場合は、ドキュメント数が最大の add_idle_nodes：このコマンドはauto_add_new_nodes=falseの場合に利用できます。このコマンドはクラスタに対して「idle」状態のすべてのノードを追加するトリガーとなります。 move_partition：（パラメータ：パーティション、from、to）fromのノードからtoの別のノードに引数で指定されたパーティションを移動します。 command_status：（パラメータ：completion_id（任意））上記コマンドはすべて非同期で実行され、completion_idを返します。このコマンドは特定の実行中のコマンドもしくは全ての実行中のコマンドの状態を表示するために利用できます。 status：（パラメータ：パーティション（任意））パーティションのリストを表示し各パーティションの次の情報を表示します。 リーダーノード ノードのリスト ドキュメント数 平均読み込み回数（reads/sec） 平均書き込み回数（writes/sec） 平均読み込み時間（time/read） 平均書き込み時間（time/write） Migrating from Solr to SolrCloud クラウドに移行するときに幾つかの特徴は不要かもしれないし、サポートされないかもしれません。 既存の（クラウドでない）バージョンでのすべての特徴をSolrCloudでサポートし続けなければなりません。\nレプリケーション：これは必要ありません。 CoreAdminコマンド：明示的なコアの操作は許可されません。内部にコアがあるかもしれないが、暗黙的に管理されるでしょう 複数スキーマのサポート？：単純化のため、ver1.0ではサポートしないかもしれない solr.xml：SolrCloudでほんとに必要？ Alternative to a Cluster Lock リーダーを選出する常設の調停ノード（masterはインデックスレプリケーションで利用している用語なので、「調停」とする）を持つほうが単純かもしれません。 「truth」状態をZookeeperの状態としてみなすような次のパターンでは、将来の柔軟性（クラスタを制御するためのZookeeperの状態を直接変更するような外部管理ツールのような）を考慮に入れることができます。 （毎回ロックを取得するよりも）調停ノードを持つことにより、よりスケーラブルになるかもしれません。 特定条件下でのみCluster Lockを利用するハイブリッドも意味があるでしょう。\nSingle Node Simplest Use Case 単一ノードでスタートして、ドキュメントをインデックス登録できないといけません。 また、あとで、クラスタに2番目のノードを追加できないと行けません。\n1つのノードから開始し、最初にZookeeperに設定ファイルをアップロードし、shard1にノードを作成＋登録します。 他の情報がない状態で設定が作成され、1つのシャードのシステムとなります。 いくつかのドキュメントをインデックスします 他のノードが起動し、「まだ割り当てられていない場合、レプリカの最小の数をもつshardに割り当てられ、「recovery」プロセスを開始します」というパラメータを受け取ります。 * 出来れば、同一ホスト上に同じシャードはコピーしない * この時点の後で、ノードが停止したら、再起動し、同じ役割が再開されるべきです。（Zookeeperでそれ自身であると判別されれば） 原文はこちらからです。\nBoot Strapping Cluster Startup A node is started pointing to a Zookeeper host and port. The first node in the cluster may be started with cluster configuration properties and the schema/config files for the cluster. The first node would upload the configuration into zookeeper and bootstrap the cluster. The cluster is deemed to be in the “bootstrap” state. In this state, the node -\u0026gt; partition mapping is not computed and the cluster does not accept any read/write requests except for clusteradmin commands.\nAfter the initial set of nodes in the cluster have started up, a clusteradmin command (TBD description) is issued by the administrator. This command accepts an integer “partitions” parameter and it performs the following steps:\nAcquire the Cluster Lock Allocate the “partitions” number of partitions Acquires nodes for each partition Updates the node -\u0026gt; partition mapping in ZooKeeper Release the Cluster Lock Informs all nodes to force update their own node -\u0026gt; partition mapping from ZooKeeper The Cluster Lock is acquired A suitable source (node, partition) tuple is chosen: The list of available partitions are scanned to find partitions which has less then “replication_factor” number of nodes. In case of tie, the partition with the least number of nodes is selected. In case of another tie, a random partition is chosen. If all partitions have enough replicas, the nodes are scanned to find one which has most number of partitions. In case of tie, of all the partitions in such nodes, the one which has the most number of documents is chosen. In case of tie, a random partition on a random node is chosen. If moving the chosen (node, partition) tuple to the current node will decrease the maximum number of partition:node ratio of the cluster, the chosen tuple is returned.Otherwise, no (node, partition) is chosen and the algorithm terminates The node -\u0026gt; partition mapping is updated in ZooKeeper The node status in ZooKeeper is updated to “recovery” state The Cluster Lock is released A “recovery” is initiated against the leader of the chosen partition After the recovery is complete, the Cluster Lock is acquired again The source (node, partition) is removed from the node -\u0026gt; partition map in ZooKeeper The Cluster Lock is released The source node is instructed to force refresh the node -\u0026gt; partition map from ZooKeeper Goto step #1 Node Restart A node restart can mean one of the following things:\nThe JVM crashed and was manually or automatically restarted The node was in a temporary network partition and either could not reach ZooKeeper (and was supposed to be dead) or could not receive updates from the leader for a period of time. A node restart ine node failure. Lifecycle of a Write Operation this scenario signifies the removal of the network partition. A hardware failure or maintenance window caused the removal of the node from the cluster and the node has been started again to rejoin the cluster. The node reads the list of partitions for which it is a member and for each partition, starts a recovery process from each partition’s leader respectively. Then, the node follows the steps in the New Node section without checking for the auto_add_new_nodes property. This ensures that the cluster recovers from the imbalance created by th\nWrites are performed by clients using the standard Solr update formats. A write operation can be sent to any node in the cluster. The node uses the hash_function , and the Range-Partition mapping to identify the partition where the doc belongs to. A zookeeper lookup is performed to identify the leader of the shard and the operation is forwarded there. A SolrJ enhancement may enable it to send the write directly to the leader\nThe leader assigns the operation a Partition Version and writes the operation to its transaction log and forwards the document + version + hash to other nodes belonging to the shard. The nodes write the document + hash to the index and record the operation in the transaction log. The leader responds with an ‘OK’ if at least min_writes number of nodes respond with ‘OK’. The min_writes in the cluster properties can be overridden by specifying it in the write request.\nThe cloud mode would not offer any explicit commit/rollback operations. The commits are managed by auto-commits at intervals (commit_within) by the leader and triggers a commit on all members on the shard. The latest version available to a node is recorded with the commit point.\nTransaction Log A transaction log records all operations performed on an Index between two commits Each commit starts a new transaction log because a commit guarantees durability of operations performed before it The sync can be tunable e.g. flush vs fsync by default can protect against JVM crashes but not against power failure and can be much faster Recovery A recovery can be triggered during:\nBootstrap Partition splits Cluster re-balancing The node starts by setting its status as ‘recovering’. During this phase, the node will not receive any read requests but it will receive all new write requests which shall be written to a separate transaction log. The node looks up the version of index it has and queries the ‘leader’ for the latest version of the partition. The leader responds with the set of operations to be performed before the node can be in sync with the rest of the nodes in the shard.\nThis may involve copying the index first and replaying the transaction log depending on where the node is w.r.t the state of the art. If an index copy is required, the index files are replicated first to the local index and then the transaction logs are replayed. The replay of transaction log is nothing but a stream of regular write requests. During this time, the node may have accumulated new writes, which should then be played back on the index. The moment the node catches up with the latest commit point, it marks itself as “ready”. At this point, read requests can be handled by the node.\nHandling Node Failures There may be temporary network partitions between some nodes or between a node and ZooKeeper. The cluster should wait for some time before re-balancing data.\nLeader failure\nIf node fails and if it is a leader of any of the shards, the other members will initiate a leader election process. Writes to this partition are not accepted until the new leader is elected. Then it follows the steps in non-leader failure\nNon-Leader failure\nThe leader would wait for the min_reaction_time before identifying a new node to be a part of the shard. The leader acquires the Cluster Lock and uses the node-shard assignment algorithm to identify a node as the new member of the shard. The node -\u0026gt; partition mapping is updated in ZooKeeper and the cluster lock is released. The new node is then instructed to force reload the node -\u0026gt; partition mapping from ZooKeeper.\nSplitting partitions A partition can be split either by an explicit cluster admin command or automatically by splitting strategies provided by Solr. An explicit split command may give specify target partition(s) for split.\nAssume the partition ‘X’ with hash range 100 - 199 is identified to be split into X (100 - 149) and a new partition Y (150 - 199). The leader of X records the split action in ZooKeeper with the new desired range values of X as well as Y. No nodes are notified of this split action or the existence of the new partition.\nThe leader of X, acquires the Cluster Lock and identifies nodes which can be assigned to partition Y (algorithm TBD) and informs them of the new partition and updates the partition -\u0026gt; node mapping. The leader of X waits for the nodes to respond and once it determines that the new partition is ready to accept commands, it proceeds as follows: The leader of X suspends all commits until the split is complete. The leader of X opens an IndexReader on the latest commit point (say version V) and instructs its peers to do the same. The leader of X starts streaming the transaction log after version V for the hash range 150 - 199 to the leader of Y. The leader of Y records the requests sent in #2 in its transaction log only i.e. it is not played on the index. The leader of X initiates an index split on the IndexReader opened in step #2. The index created in #5 is sent to the leader of Y and is installed. The leader of Y instructs its peers to start recovery process. At the same time, it starts playing its transaction log on the index. Once all peers of partition Y have reached at least version V: The leader of Y asks the leader of X to prepare a FilteredIndexReader on top of the reader created in step #2 which will have documents belonging to hash range 100 - 149 only. Once the leader of X acknowledges the completion of request in #8a, the leader of Y acquires the Cluster Lock and modifies the range -\u0026gt; partition mapping to start receiving regular search/write requests from the whole cluster. The leader of Y asks leader of X to start using the FilteredIndexReader created in #8a for search requests. The leader of Y asks leader of X to force refresh the range -\u0026gt; partition mapping from ZooKeeper. At this point, it is guaranteed that the transaction log streaming which started in #3 will be stopped. The leader of X will delete all documents with hash values not belonging to its partitions, commits and re-opens the searcher on the latest commit point. At this point, the split is considered complete and leader of X resumes commits according to the commit_within parameters. Notes:\nThe partition being split does not honor commit_within parameter until the split operation completes Any distributed search operation performed starting at the time of #8b and till the end of #8c can return inconsistent results i.e. the number of search results may be wrong. Cluster Re-balancing The cluster can be rebalanced by an explicit cluster admin command.\nTBD\nMonitoring TBD\nConfiguration solr_cluster.properties This are the set of properties which are outside of the regular Solr configuration and is applicable across all nodes in the cluster:\nreplication_factor : The number of replicas of a doc maintained by the cluster min_writes : Minimum no:of successful writes before the write operation is signaled as successful . This may me overridden on a per write basis commit_within : This is the max time within which write operation is visible in a search hash_function : The implementation which computes the hash of a given doc max_hash_value : The maximum value that a hash_function can output. Theoretically, this is also the maximum number of partitions the cluster can ever have min_reaction_time : The time before any reallocation/splitting is done after a node comes up or goes down (in secs) min_replica_for_reaction : If the number of replica nodes go below this threshold the splitting is triggered even if the min_reaction_time is not met auto_add_new_nodes : A Boolean flag. If true, new nodes are automatically used as read replicas to existing partitions, otherwise, new nodes sit idle until the cluster needs them. Cluster Admin Commands All cluster admin commands run on all nodes at a given path (say /cluster_admin). All nodes are capable of accepting the same commands and the behavior would be same. These are the public commands which a user can use to manage a cluster:\ninit_cluster : (params : partition) This command is issued after the initial set of nodes are started. Till this command is issued, the cluster would not accept any read/write commands split_partition : (params : partitionoptional). The partition is split into two halves. If the partition parameter is not supplied, the partition with the largest number of documents is identified as the candidate. add_idle_nodes : This can be used if auto_add_new_nodes=false. This command triggers the addition of all ‘idle’ nodes to the cluster. move_partition : (params : partition, from, to). Move the given partition from a given node from to another node command_status :(params : completion_idoptional) . All the above commands are asynchronous and returns with a completion_id . This command can be used to know the status of a particular running command or all the current running commands status : (params : partitionoptional) Shows the list of partitions and for each partition, the following info is provided leader node nodes list doc count average reads/sec average writes/sec average time/read average time/write Migrating from Solr to SolrCloud A few features may be redundant or not supported when we move to cloud such as. We should continue to support the non cloud version which supports all the existing features\nReplication. This feature is not required anymore CoreAdmin commands. Explicit manipulation of cores will not be allowed. Though cores may exist internally and they meay be managed implicitly Multiple schema support ? Should we just remove it from ver 1.0 for simplicity? solr.xml . Is there a need at all for this in the cloud mode? Alternative to a Cluster Lock It may be simpler to have a coordinator node (we avoid the term master since that is associated with traditional index replication) that is established via leader election. Following a pattern of treating the zookeeper state as the \u0026ldquo;truth\u0026rdquo; and having nodes react to changes in that state allow for more future flexibility (such as allowing an external management tool directly change the zookeeper state to control the cluster). Having a coordinator (as opposed to grabbing a lock every time) can be more scalable too. A hybrid model where a cluster lock is used only in certain circumstances can also make sense.\nSingle Node Simplest Use Case We should be able to easily start up a single node and start indexing documents. At a later point in time, we should be able to start up a second node and have it join the cluster.\nstart up a single node, upload it\u0026rsquo;s configuration (the first time) to zookeeper, and create+assign the node to shard1. in the absence of other information when the config is created, a single shard system is assumed index some documents start up another node and pass it a parameter that says \u0026ldquo;if you are not already assigned, assign yourself to any shard that has the lowest number of replicas and start recovery process\u0026rdquo; avoid replicating a shard on the same host if possible after this point, one should be able to kill the node and start it up again and have it resume the same role (since it should see itself in zookeeper)\n","date":1317720720,"dir":"post/2011/","id":"7052598d2355984237d126afea2f6e88","lang":"ja","lastmod":1317720720,"permalink":"https://blog.johtani.info/blog/2011/10/04/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE2/","publishdate":"2011-10-04T18:32:00+09:00","summary":"遅くなりましたが、続きです。 さらに英語力のなさを痛感して凹んでいるところですが、何かの役に立てばと恥を晒すところです。。。 一応、訳してみたの","tags":["solr"],"title":"New SolrCloud Designの翻訳（その2）(Jugemより移植)"},{"contents":"ちょっと興味があるので、訳してみました。（Wikiのページはこちら） 更新されているようなので、もとの文章も残しておきます。（ページ下部の続きはこちら部分以降） 全部訳そうと思ったのですが、終わらなかったので、まずは前半部分です。まだ、訳しただけで理解できてない。。。 （英語力のなさをさらけ出してしまうのですが、これも修行です。。。おかしいところはツッコミを。）\nWhat is SolrCloud? Solrクラウドはクラウドでの検索サービスとしてのSolrを管理、運用するための既存のSolrを拡張するものです。\n用語集 Cluster：クラスタは1単位として管理されるSolrノードの集合です。クラスタ全体で単一のschema、solrconfigをもたないといけません。 Node：ひとつのJVMインスタンスで起動しているSolrのこと Partition：パーティションはドキュメント集合全体のサブセット（部分集合）のことです。パーティションは部分集合のドキュメントが単一のインデックスに含まれるような形で作られます。 Shard：パーティションはn（＝replication factor）個のノードに保存される必要があります。このn個のノードすべてでひとつのshardです。1つのノードはいくつかのshardの一部にで有る場合があります。 Leader：各Shardは1つのリーダとなるノードを持っています。パーティションに登録されたドキュメントリーダーからコピーされます Replication Factor：クラスタによって保持されるレプリカの最小限の数 Transaction Log：各ノードによって保持される書き込み処理の追記ログ Partition version：これは各shardのリーダーが持っているカウンターで、書き込み処理ごとに増加し、レプリカに送られます。 Cluster Lock：これはrange（※後述されているハッシュ値の範囲のことか？）-\u0026gt;パーティションもしくはパーティション-\u0026gt;ノードのマッピングを変更するために取得しなければいけないグローバルなロックのことです。 ※用語だけだと関係がわかりづらかったので、図を書いてみました。\nドキュメントの集合とパーティションについての考え方\nクラスタ、ノード、シャードの考え方。\n処理原則 任意の処理はクラスタにある任意のノードに実行可能です。 リカバリできないSPOFはありません。 クラスタは伸縮自在（elastic）でなければならない 書き込みが失われないこと（耐久性）を保証する 書き込み順序が保証されなければならない 2つのクライアントが2つの「A」というドキュメントを同時に送信してきた場合、すべてのレプリカで一貫してどちらか一方が保存されなければならない。 クラスタの設定は中央管理されなければならない。また、クラスタのどのノードからもクラスタ設定が更新できます。 読み込み（検索）の自動的なフェイルオーバー 書き込み（インデクシング）の自動的なフェイルオーバー ノードの故障が発生しても自動的にrepcation factorの数は守られます。（故障したら動的にレプリカを再配置？） Zookeeper ZooKeeperクラスタは次のために使用されます。\nクラスタ設定の集中管理 分散同期に必要な操作のコーディネータ クラスタ構成を保存するためのシステム Partitioning クラスタは固定されたmax_hash_value＝「N」が設定されます。 max_hash_valueは1000のような大きな値が設定されます。\nhash = hash_function(doc.getKey()) % N ハッシュ値の範囲がパーティションに割り当てられ、ZooKeeperに保存されます。 次の例のような形で、パーティションに対して範囲が設定されます。\nrange : partition ------ ---------- 0 - 99 : 1 100-199: 2 200-299: 3 ハッシュはドキュメントにインデックスフィールドとして追加され、変更されない値です。 これは、インデックスを分割するときにも利用します。\nハッシュ関数はプラガブルです。これはドキュメントを受け取り、一貫した正整数ハッシュ値を返します。デフォルトのハッシュ関数として、必須でかつ変更されないフィールド（デフォルトはユニークキーフィールド）からハッシュ値を計算する関数が提供されます。\nUsing full hash range max_hash_valueは必ずしも必要ではありません。各shardはいずれにしろハッシュ値の範囲持っているので、完全な32 bitsハッシュを使うこともできます。 設定可能なmax_hash_valueを利用しないで、クライアントからの値をもとにハッシュ値を作ることができます。 例えば、電子メールの検索アプリでは次のようにハッシュ関数を作ることができます。\n(hash(user_id)\u0026lt;\u0026lt;24) | (hash(message_id)\u0026gt;\u0026gt;\u0026gt;8) ユーザIDから8bitのハッシュコードの先頭8ビットを利用することで、任意のユーザのメールがクラスタの同じ256番目（のノード？）にあるのを保証します。検索時はこの情報をもとにクラスタのその部分への問い合わせだけで情報が得られます。\nおそらく、私たちは最大値から最小値をカバーする範囲を表現するのにハッシュ空間を輪（固定のハッシュではなく）とみなしたいです。（？？？円状のハッシュ空間とすることで、クラスタ内のノード数の増減に耐えられるようにするよということかな？）\nshard naming シャードからハッシュ値の範囲へのマッピングを別々に管理するよりも、ハッシュコードによりパーティションを構成するときに実際にはハッシュの範囲をシャード名にします。 （シャード「1-1000」は1から1000の間のハッシュコードを持つドキュメントが含まれるという形）\n現時点では（コレクション1つに対してシングルコアの1Solrサーバと仮定して）solrコア名はコレクション名をつけるようになっています。 同一コレクションのためのマルチコアに対してのいい命名規則をつけるという課題が残っています。 （※コレクションに対する説明がここまでないかな？）\nShard Assignment ノード-\u0026gt;パーティションのマッピングはZooKeeperにあるCluster Lockを取得したノードによってのみ変更が可能です。 ノードの追加時に、まず、Cluster Lockを取得し、次にそれがどのパーティションを取得できるかを識別します。\nNode to a shard assignment 新しいノードを探しているノードはまずCluster Lockを取得しないといけません。 第一に、リーダーはシャードを決めます。 シャードが持つ、すべての利用可能なノード数で最小の値を持つノードが選び出されます。 もし、同値ならランダムにノードを選びます。\n原文はこちらからです。\nNew SolrCloud Design (Work in progress)\nWhat is SolrCloud? SolrCloud is an enhancement to the existing Solr to manage and operate Solr as a search service in a cloud.\nGlossary Cluster : Cluster is a set of Solr nodes managed as a single unit. The entire cluster must have a single schema and solrconfig Node : A JVM instance running Solr Partition : A partition is a subset of the entire document collection. A partition is created in such a way that all its documents can be contained in a single index. Shard : A Partition needs to be stored in multiple nodes as specified by the replication factor. All these nodes collectively form a shard. A node may be a part of multiple shards Leader : Each Shard has one node identified as its leader. All the writes for documents belonging to a partition should be routed through the leader. Replication Factor : Minimum number of copies of a document maintained by the cluster Transaction Log : An append-only log of write operations maintained by each node Partition version : This is a counter maintained with the leader of each shard and incremented on each write operation and sent to the peers Cluster Lock : This is a global lock which must be acquired in order to change the range -\u0026gt; partition or the partition -\u0026gt; node mappings. Guiding Principles Any operation can be invoked on any node in the cluster. No non-recoverable single point of failures Cluster should be elastic Writes must never be lost i.e. durability is guaranteed Order of writes should be preserved If two clients send document \u0026ldquo;A\u0026rdquo; to two different replicas at the same time, one should consistently \u0026ldquo;win\u0026rdquo; on all replicas. Cluster configuration should be managed centrally and can be updated through any node in the cluster. No per node configuration other than local values such as the port, index/logs storage locations should be required Automatic failover of reads Automatic failover of writes Automatically honour the replication factor in the event of a node failure Zookeeper A ZooKeeper cluster is used as:\nThe central configuration store for the cluster A co-ordinator for operations requiring distributed synchronization The system-of-record for cluster topology Partitioning The cluster is configured with a fixed max_hash_value (which is set to a fairly large value, say 1000) ‘N’. Each document’s hash is calculated as:\nhash = hash_function(doc.getKey()) % N Ranges of hash values are assigned to partitions and stored in Zookeeper. For example we may have a range to partition mapping as follows\nrange : partition ------ ---------- 0 - 99 : 1 100-199: 2 200-299: 3 The hash is added as an indexed field in the doc and it is immutable. This may also be used during an index split\nThe hash function is pluggable. It can accept a document and return a consistent \u0026amp; positive integer hash value. The system provides a default hash function which uses the content of a configured, required \u0026amp; immutable field (default is unique_key field) to calculate hash values.\nUsing full hash range Alternatively, there need not be any max_hash_value - the full 32 bits of the hash can be used since each shard will have a range of hash values anyway. Avoiding a configurable max_hash_value makes things easier on clients wanting related hash values next to each other. For example, in an email search application, one could construct a hashcode as follows:\n(hash(user_id)\u0026lt;\u0026lt;24) | (hash(message_id)\u0026gt;\u0026gt;\u0026gt;8) By deriving the top 8 bits of the hashcode from the user_id, it guarantees that any users emails are in the same 256th portion of the cluster. At search time, this information can be used to only query that portion of the cluster.\nWe probably also want to view the hash space as a ring (as is done with consistent hashing) in order to express ranges that wrap (cross from the maximum value to the minimum value).\nshard naming When partitioning is by hash code, rather than maintaining a separate mapping from shard to hash range, the shard name could actually be the hash range (i.e. shard \u0026ldquo;1-1000\u0026rdquo; would contain docs with a hashcode between 1 and 1000).\nThe current convention for solr-core naming is that it match the collection name (assuming a single core in a solr server for the collection). We still need a good naming scheme for when there are multiple cores for the same collection.\nShard Assignment The node -\u0026gt; partition mapping can only be changed by a node which has acquired the Cluster Lock in ZooKeeper. So when a node comes up, it first attempts to acquire the cluster lock, waits for it to be acquired and then identifies the partition to which it can subscribe to.\nNode to a shard assignment The node which is trying to find a new node should acquire the cluster lock first. First of all the leader is identified for the shard. Out of the all the available nodes, the node with the least number of shards is selected. If there is a tie, the node which is a leader to the least number of shard is chosen. If there is a tie, a random node is chosen.\n","date":1317210300,"dir":"post/2011/","id":"927612b57ba01ca878b2d7edce52a563","lang":"ja","lastmod":1317210300,"permalink":"https://blog.johtani.info/blog/2011/09/28/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE%EF%BC%91/","publishdate":"2011-09-28T20:45:00+09:00","summary":"ちょっと興味があるので、訳してみました。（Wikiのページはこちら） 更新されているようなので、もとの文章も残しておきます。（ページ下部の続き","tags":["solr"],"title":"New SolrCloud Designの翻訳（その１）(Jugemより移植)"},{"contents":"Hadoop Conference Japan 2011 Fallに行ってきました。 まずは、ユーザ会の方々、運営の方々、発表された方々お疲れ様でした。こんな機会を用意していただき、ありがとうございます。 Hadoopは昨年触っていたのですが、最近は縁がなくなってしまいました。 ただ、触っていたときに面白かったので参加してきました。 ということで、今回も自分用にメモを取ったので。（今回は英語のヒアリングがあって、メモがひどい事になってます。。。） いつものことながら、おかしいところとかあれば、ツッコミなどフィードバックをもらえると嬉しいです。\n場所：ベルサール汐留 日時：2011/09/26 10:00～18:00＋懇親会：18:30～21:00\nオープニングトーク：濱野、太田 参加者：1100名超！（実際は800名弱？） Hadoopの経験：利用経験なしな方が580名 カンファレンスの認知：Twitterよりも知人、その他が多かった。 会場提供：リクルート様 リクルート米谷様より一言。 Question VOTE！！サイトを用意。 http://mit.recruit.co.jpにて情報提供。 ※残念ながら地下だったため、E-mobileにつながらず、あと、電源確保が難しかったのでMBAをスタンドアロンにしてメモをとっていたので、 QAサイトにはアクセスしませんでした。もう少し活用したかったんですが、携帯でTwitterを追っかけるので精一杯。。。\n◎The role of the Distribution in the Apache Hadoop Ecosystem：Todd Lipcon（Cloudera）\n1.Introduction Todd Lipcon：Clouderaエンジニア Hadoop とHBaseのコミッター 2. Hadoop Overview HDFS＋MapReduceの説明 Hadoopの生まれてきた経緯　様々な形式のデータが大量に存在し、データのハンドリングが難しくなってきたため。 Flexible, Scalable Solutionが必要に。 Hadoop の2つのユースケース 1.Advanced Analytics SNS（Web）、Content Optimization（Media）、Network Analytics（Telco）、 2.Data Processing Clickstream SessionizationEngagement 3.Cloudera Overview ClouderaCustomers ・Large National Bank ・Web-Based Media click-through dataや広告のログ ・Wireless Telecom 大量のデータ 目標：大量データからビジネスを引き出すこと。 Cloudera Japan：トレーニング。NTTDと協業して開発支援も 4.CDH Overview 100% pure Apache Hadoop SCM Epress(Service \u0026amp;amp; Configuration Manager) Free なぜ、CDHを利用するの？ Linuxを利用する場合にLinux.orgからはダウンロードしないように、Hadoopも同じように提供したい。 RedHat系を目指しているみたい。 様々なパッケージの依存関係が混乱を招く。 CDHならテストが終わってるものが提供されてる。 ※SolrはLWEがLucidWorksEnterpriseがこれを目指してるのか。 5.Cloudera Enterprise Activity Monitor：Jobのパフォーマンスをリアルタイムに監視 SCM：設定のvalidateや管理。 Resource Manager：。。。 6.まとめ CDH：簡単にHadopが使えるよ。 SCM Express：簡単にHadoopの設定ができてフリーだよ Cloudera：Hadoopに関していろいろサポートしているよ。（Enterprise用ソフトやトレーニングなど） ◎About Hortonworks：Owen O\u0026rsquo;Malley（Hortonworks）\n1.About Hortonworks 2011/2月に設立 22人のYahooからのアーキテクトとコミッタにより設立 2.Credentials Yahooのクラスタの経験者がいますよ。 OSSに長けた人達によるチームです。 3.What is Apache Hadoop Hadoopの説明（別の側面が幾つかあり。） Commodity Hardwareで動く 簡単にプログラムできる 典型的なアプリケーションのタグクラウド（あとでちゃんと見る） HadoopのほとんどのソースコードはYahooで作られてるよ。 Clouderaとか目じゃないよ 4.Hadoop @ Yahoo! 各種サーバや規模など Science Hadoop Cluster \u0026lt;-\u0026amp;gt; Production Hadoop Cluster \u0026lt;-\u0026amp;gt; Serving Systems という構成で、いろいろやってます。 5.Hadoop Market ビジネス：ビッグデータを扱って色々やろうね 金融系：IT系のコストをOSSとHadoopで削減 技術系： 6.Hortonworks Strategy Hadoopを利用、管理しやすくするためのいろんなことをコミュニティに還元しますよ。 性能などについても同様。 トレーニングやテクニカルサポートやりますよ。 QA： Q：42Kのノードの管理ツールはなに？ A：手で管理してます。 Q：社名の由来は？ A：童話でHortonという名前の象の話がある。 Q：CDHはおすすめ？それともほかのものがいい？ A：※聞き取れず。。。 Q：500万Query/月はアドホックQueryもあるの？ A：幾つかのクラスタに分けて使ってる。アドホックは不明 ◎How Hadoop needs to evolve and integrate into the enterprise：Ted Dunning（MapR）\n・Quick History ・英語わからない身には辛い。。。 Zookeeperの人らしい。 Narrow Foundations HDFSとNASの間には大きな壁があり、大きなデータを移動するのはコストが掛かる。 Broad Foundation HDFSの代わりにNAS、RDBMSの下に位置するMapRを用意 ど、どんな仕組み？-\u0026amp;gt;テクニカルセッションで。 QA： Q：MapRはOSSにしないのか？ A：MapRで開発したものはApacheに還元はしますが、OSSにはしないよ。フリー版は提供するかも ここで昼食。午前中からいた人にはランチボックスが提供されました。 午後からはコミュニティトラックとテクニカルトラックの2トラックがありましたが、LTが聞きたかった（それよりも英語が辛かった？）のでコミュニティトラックのど真ん中、最前列に入り浸りました。 ★コミュニティトラック ◎Elastic MapReduce Amazonが提供するHadoop：大谷晋平（Amazon）\n・Amazonとは Eコマース 流通 AWS の3つのサービス ・AWS Low-level、High-level、Cross Service、Tools to access services、アプリケーション 色々あるなー ・Bigデータが大変な理由 ケタ違いのデータ量、異なる形式データ、即時性 現状システムはスケールしない ビジネスとして成立する？ 成立するならすぐスケールだめならすぐ縮小 ・Hadoopとは？ これまでのお話。 スケーラブル、低価格なハード 誰でも入手可能で、実績多数。 ・Amazon EMR AWS上でスケーラブルなインフラ上に構築が可能 オンプレミスからMapReduceアプリを移行可能なため、分析、解析に集中可能 S3からデータIN/OUTするので、データ欠損がない。 Hadoopそのままではチューニングやクラスタサイズ見積もりも難しい ＝＞クラスタサイズを動的に拡張伸縮可能。パフォーマンス最適化もできるよ。 0.18、0.20が利用可能。 EMRはHDFSとジョブ（タスク）トラッカーを別構成にしている。 EC2上にMaster、Core、タスクノードを展開 S3にデータを格納 SimpleDB（KVS）を利用 ・EMR注目機能 ジョブフローの高速化 ジョブの再起動無しにコスト/パフォーマンス比を変更可能。 タスクノードを動的に増やせる 柔軟なデータウェアハウスクラスタ タスクノードをバッチ実行時にのみ増やせる。 ※増減できるのはタスクノード Coreノードは増加のみ EMR＋Spotインスタンスの活用 コスト削減効果が非常に高い AWSの余剰リソースをリーズナブルに提供（Amazon的にもウハハだ） ・その他の機能 東海岸だけだけど、スパコンレベルのインスタンスも利用可能 AWS上での最適化設計など ※ちょっと時間足りなくなってきたｗ ・EMRの事例 1.Razorfish ROAS（広告費用対効果）を500%改善（すげー） 2.So-net ・EMR都市伝説 物理vs仮想 そりゃ、物理が速いよ EMRの柔軟性・拡張性がセールスポイント ビッグデータは成功/失敗が読めないのもあるので、 インフラに投資する部分を少なくできるよ。 オンプレミスが安い？ いやいや、HWの購入から設定など時間かかる。 ・Beyond Hadoop HadoopのIn/Out含めてスケーラブル、フレキシビリティが重要 運用管理の仕組みも重要 まだまだやってくよ。 QA Q：EMRは複数サービスから構築してるけど、一部がダウンするとどーなる？（例：SimpleDBが落ちてるとか） A：ジョブはReRunしてもらうか、SimpleDBの状態をみてリカバリをしてもらう。 Q：上記にともない、SLAの計算は？ A：SLAはEMRについては定義できてない。S3などはリージョン跨いで Q：S3のセキュリティが心配だが、どう考えてるか？ A：いままで脆弱性を晒してデータをロストしてない。 ユーザコントロールなどもできる。基本的には問題ない Q：EMRでS3を使う＝Hadoopのローカリティの利点が失われるのでは？ A：オーバヘッドはあるが、実際のデータはS3で守られているので、HDFSが飛んでも大丈夫。 Q：S3からのコピーオーバヘッドはどーなるか？ A：Single5で少しずつor分割して全部送るも可能 Q：EMRはマルチテナントだけど他のユーザのネットワークの影響を受けないの？ A：マルチテナントだと起こる可能性がある。 M1（？）だと内部ネットワークは専有可能らしい。 ◎LT\n・Hadoop and Subsystems in livedoor @tagomoris ピーク時に15Gbps。 10ノード（36コア） CDH3b2を利用 データマイニングではなく、ログからレポーティングをするのに利用している。 hadoop streaming + Hiveで実施 580G/dayが96サーバから来る ScribeにてHadoop Streaming（Perl）でper hourでHiveにload scribelineをWebサーバに入れててログ配送してくれる。 **　・Lightweight　@stanaka（はてなCTO：田中慎司さん）**\nEMR以前 自前20台クラスタ ジョブがあふれてきた ナマMapReduceを利用 PerlでMapper/Reducerを記述（Hadoop Streaming） EMR導入 リソース増やせて便利！ 必要な台数に伸縮可能 問題点： S3にアップしないとダメ ＝＞ログデータをS3に展開するlog2s3.plを作成。毎時実行。 起動、ジョブキック、結果改修どーする？ ＝＞Net::Amazon::EMR::Wrapperを作成した。 クラスタ起動、ジョブキック、クラスタ停止などできる 作ってみて思ったこと よかったところ： Perlでかける。Cronで実行可能。HiveQL便利。 悪かったところ。 途中で失敗してクラスタ起動しっぱなしとかがある。S3にデータを展開が大変。複雑な計算がきつい。 慣れてないエンジニアにも触れるようにしたい ＝＞Perlで書けるようにした？。 **　・HBaseでグラフ構造を扱う（開発中）：アメーバ鈴木**\n自己紹介@brfrnl69 アメーバのソーシャルグラフ 基本はMySQL マスタ分散が難しい、シャーディング管理が面倒 ＝＞HBaseでやってみるか。 目的　グラフデータに対して高速に更新追加したい。 隣接ノードが取れればいい（これを高速化したい） オンライン処理したい 運用コストの削減したい。 Not目的 マルチホップはどうでもいい。 アーキテクチャ JavaでGatewayつくってみる。 ・Large-Scale Graph Processing：井上さん（@doryokujin）さん Map/Reduceではグラフ計算だめ？ Vertex基本だとShuffleに問題ががが。 BSPの紹介 Bulk Synchronous Processing Google Pregel SSSP：MapReduce Model すごい計算時間が掛かりそう。MRの組み合わせが何回回ることやら。 枝が少ないとこっちのほうがいいのか？ SSSP：PregelModel シンプルなアルゴリズム Pregel使えるのあるの？ Hama GoldenOrb Giraph YERN？YARN？ ◎リクルート式Hadoopの使い方：石川（リクルート）\n@ground_beetle ・導入の課題点 バッチ処理時間対策のため。 ＝＞実は入れたかっただけｗ ・導入の障壁 現行システムへの影響＋開発工数 ＝＞これへの対処がこのあとの話 ・課題の克服と活用シーン Azkaban知らなかった。ジョブスケジューリングツール Hadoop単体ではなく、エコシステム（関連ツール）が魅力 ・活用シーン：Hive SQLゆーがざ多く、HiveQLがSQLライクのため導入が簡単に！ 既存機能のリプレイス系案件に活躍（低工数＋簡単に高速化） とりあえず、Hive実装 ＝＞性能アップのためにMapReduceで書きなおし Hotpepperなどのアトリビューション分析に利用 ・活用シーン：Sqoop＋Hive RDBとHadoop連携のツール：Sqoop 現行システムの横にHadoopを配置でき、RDBMSの利点も利用しつつHiveも利用できるようになる。 （※気を付けないといけないけどねぇ。） ゼクシィで活用しようとしてるところ。 ・活用シーン：Mahout マイニング用ツール カーセンサーのレコメンド（同時に閲覧される車種） アソシエーション分析＋クラスタリング ・活用シーン：BIツールの導入 何度か導入しようとして失敗してます。。。 BIツールの前処理（クレンジングなど）にHadoopを活用 ・インフラリソースは？ 全部で118台。 最小のクラスタ構成はサーバ6台で構成してる ・Hadoopで複数処理を回す方法 ここまで紹介したものを入れてますよ。Hive、Sqoop、Solr。。。 ・Azkaban TomcatにWar配置で利用可能。 LinedInのチームにより作成 ※若干マシントラブルで中断 ・今後のHadoop導入 ログ基盤 分析エンジン・レコメンドエンジンとして バッチ処理短縮＝トライアンドエラーが簡単にできるようになる。＝色々な気づきが出てくる。 アジャイル的な解析が可能に。 ・開発サイクルの短縮ができるエコシステムでビジネスが回りだす。 ・今後の展開 MapRが気になってる。 マルチテナント対応ができてうはうはできそう。 EMCと共同して検証中 QA： Q：性能監視ツールの選別の理由は？ A：Zabbix、Cactiです。今から利用しようと思っている段階。 Q：CDH、GreenPlum、Apacheをそれぞれ利用してるけど、使い分けのシーンは？比較は？ A：CDH3u0です。GreenPlumは使ってないです。理由は言うとクビが飛ぶ可能性ががが。 Q：高度なデータ分析ができる技術者はどこからヘッドハントしてるの？ A：MITに別途分析チームが存在し、高度な分析をしてくれる。 Q：NameNodeの冗長化はどーやってんの？ A：象本と一緒DRBD＋HeartBeat Q：EMRの導入を検討してる？ A：今後、サーバ数が多くなると導入の検討をしていくと思う。 現時点は、運用ノウハウも入手するために社内で使ってる。 EMRになるかRCloud（リクルート社内クラウド）になるかは不明。 Q：HBaseを利用してる？ A：してないです。スペック的にサーバが買ってもらえないと厳しいです。 ◎The history and the future of Hadoop use case at Rakuten：Tarje Marthinussen（楽天）\n・Introduction（self、rakuten） NextGeneration Search Group Norwayから来ましたよ。 ・RakutenのBigDataとは ・Hadoop at rakuten　Recommendation（2009） ProductRanking、GenreRanking、Log解析、（2010） Enhance Search。。。（2011） ・PigやHiveのようなものが簡単に利用できるようになってきた ・新しい検索プラットフォームを構築中 index 10k docs/sec search 400qps ・What\u0026#39;s Next Generation Search 20%はインデックスとQuery評価の 50%がデータの前処理（データとQuery） 30%がアナライズ ・Collecting Data？ ログの取得はバッチ処理だった。これをStreamingに（Flume） ・Flume Zookeeperを利用してFlumeを管理してる？？？ ・気になる部分があったので、改善のコーディングしてるよ。 ・セキュリティ マスタで管理できるように ・Pools Agentが送信先がコケてると他のPoolにスイッチ可能に。 ・MasterlessACKs QA Q：パッチ作成は何人でやってるの？ A：50人が働いていてOSSコミッターが何人いるかはわからんです。 Q：ログはテキストだけど、パース処理はどこで？（古橋さん） A：Flumeは各ノードでうまい構成になっていて Decorator 性能問題は？ HiveはJSONデータをうまく活用できてるよ。 Q：Masterlessとそうじゃないバージョンの性能比は？ A：ノード数が増えると Q：HBaseじゃなくてCassandraなの？ A：（※英語きつい。。。聞き取れず） ◎マーケティング向け大規模ログ解析事例紹介：原謙治（NTTコミュニケーション）\n・自己紹介 ・BizCITYというクラウドサービスを展開中 まずは、宣伝。 Bizストレージ、Bizマーケティングとして大規模データ、分散処理を実施してる。 ・Hadoop in Bizマーケティング CGMデータを解析して口コミ情報抽出 アクセスログから行動情報抽出 ・Hadoop in BuzzFinder CGM DBからHDFSにインポートして解析開始。DBはPostgreSQL 処理フローは資料参照。 リッチインデクシング技術（NTT研究所が開発した日本語解析技術） ※検索インデックスってどんなものなんだろう？ ポジネガ分析気になる。 ・Fast Map-Reduce for PaaS Services アクセス解析やマーケティング解析を行う上でShuffleコストが大きくなるため大量マシンが必要 ＝＞マシン数を減らすことが目的？ Map Multi-Reduce、PJoinはNTT研究所が開発した技術！？（子象本にないっけ？？） ＝＞Multi-Reduce。同一ノード上のMap出力をReduceすることで、shuffleフェーズに渡るデータを削減している。 ＝＞PJoin　QA Q：Map multi-reduce、PJoinはどう実現してるのか？公開するのか？ A：Hadoopの0.19に改造をしてる。 公開できるかどうかはわかりません。NTT研究所が研究しているものを試しに実装してみてるから。 なのでパッチにはなりませんかね（研究所に聞いてみないとわからないっす） Q：性能が向上したパターンはあったが、悪化する場合などはあるのか？ A：不明 Q：Map-side Joinとの違いは？ A：。。。 ※この辺で少し集中力が途切れてしまいました、すみません。（次に集中したかったので。。。） ◎ミクシィにおけるHadoopの利用：伊藤敬彦（mixi）\nLSH-Based Recommendation engine powered by hadoop ・実はmixiの話はすくないよ。 ・利用している環境。5or6台/クラスタ ・Hadoopの活用 ログデータをHDFSに保存 DBコンテンツをHDFSに入れることで、DBに負荷をかけずに解析する。 ・マイニングも検証中 検索クエリログをベースにデータマイニング では、本題。 ・LSHを利用した推薦 ・推薦とは？ mixiにはいろいろ推薦（レコメンド）を付加できるサービスがある。 ・推薦するには？ 類似インスタンス集合を抽出する。 インスタンスは文書だったりユーザだったり ・類似インスタンスとは？ 同じ特徴を持つ集合 例：同一商品購入したユーザとか同一単語を持つ文書とか ・抽出するには？ 全ユーザごとに全ユーザとの類似性をチェックすると時間がかかりすぎる！ ＝＞LSHを利用しよう！ ・LSHについて 特徴： ・速い！ ・精度はそれほどではない 事例： ・Google Newsのレコメンド（USロケール） ・LSHの処理ステップ 2つだけ。 1.インスタンスベクトルを計算（似ているデータは同じ値が返りやすい関数） 2.同一値が帰ってきたデータが類似インスタンス ・インスタンスベクトル例（あとでスライド見ようね） ・Likelikeがいち実装。Hadoopでうごくよ ・実験について トップページに表示されていない記事を知ってもらうために推薦してみるぞ！ ・実験１ 性能を測ってみた ・実験２ 精度を調べてみた。 精度はほんとにひどいな。。。 ＝＞同一カテゴリの遷移を元に計算したらそれなりになってきた。 ・今後 データソースを増やしたい。 他のアルゴリズムも実装したい ・CM 以下も作ってますよ。 Oluolu Anuenue QA Q：Mahoutは使わないんですか？ A：Likelikeを作った頃にMahoutになかったので作った。 性能比較したいと思ってる。 Q：ログサーバのデータ転送はどーやってる？ A：伊藤さんのところにはどういう仕組みかは上がって来てない。 Q：ベクトルの次元数はどのくらいまで耐えられる？ A：高次元のデータに対して耐えられるように作られてる。 次元数が低くて良い制度が欲しければ他のアルゴリズムがいいかも。 Q：ユーザのベクトルを作るテクニックは？ A：画像などであれば大変だけど、ユーザであれば、単語とかキーワードとかで Q：ニュース以外のデータは？ A：まだまだ実験中。まだやってない。 Q：推薦される記事数のばらつきはどういった理由が考えられる？ A：後ほど考察してQAサイトに入れます。 Q：LSHをMapReduceに載せたということだけど、関数の計算をさせてる？ A：Iterationはしてない。 Map側でLSH関数計算してる。Reduceにて類似インスタンスを導出してる。 Q：今後の予定の空間木とは？R-Treeだと高次元できついのでは？ A：低次元にて利用できるように用意したい。 Q：HamaとかGiraphで高速化させてみるのはどう？ A：イテレーションがいらないからあまり利用用途がないかなぁ。 ◎懇親会\nAWSを採用しない企業がいくつかあったのでそのあたりを質問してみた。 AWSは通常運用に利用すると結構なコストがかかる場合があるので、ノウハウがある企業や データ量が多い場合は、オンプレミスの場合を選択しているらしい。 やはりスポットで利用する方がお得感があるみたいだった。 Twitter上だけの知り合いだった方々と面識が持てたのが一番の収穫でした。 感想＋調べること\n感想\n会場規模とかQAサイトとかオープニングムービーとかすごかったです。しかも無料。さすがリクルートさん。 ランチボックスとか出てきたし。装飾もとても無料のカンファレンスと思えない出来でした。 午前中はHadoopをもとにした各社の戦略とCMという感じが色濃かったです。少しずつ各社の立ち位置が違いそれはそれで面白かったです。 AWSの説明を聞いてやはりAWSを扱える技術は必要だと再認識。 お金かけないで触ってみれるレベルでまずは触ってみるかなぁ。 洗脳されてるのかもしれないけど、自社or自前でHadoop運用するのは厳しそうです。（懇親会ですこし認識が変わった） カフェコーナーでは、リクルートのMITの冊子が配られていたり、映像や案内に使われていたHadoopマスコットのシールが配られていたりと小技も聞いてました。 あと、オライリーの販売コーナーも用意されていて、思わず子象本を買ってしまう罠にはまったりもしましたが。。。 mixiの伊藤さんの話は最後で疲れていたのですが、ストーリーが上手くできていて、実験や事例もあったのでわかりやすかったです。 Hadoopはエコシステムと呼ばれるHadoopを活用するツール群（Hiveの話が多かった？）、Hadoopの今後、Hadoopを活用したログ解析の話など、 話題が豊富でそれぞれの話が面白くて困ってしいまうくらいです。 いくつかのセッションで出てきたのですが、アクセスログなどをHDFS上に集めるための仕組みがまだ乱立（定番がまだない）している感じを受けました。 Flume、Scribe、MapR。。。などなど あとは、テクニカルセッションのビデオがアップされたらまた目を通さないと。。。 残念ながらHadoopから少し縁遠くなっていますが、これからもネタや参考になりそうな話には事欠かなそうなのでかじりついていこうと思います。 ※一番やらないといけないのは英語の勉強かもしれないです。。。 調べること 一応Solrの人なので、Solrに関連しそうな話に興味がいってしまいます。\nNTT研究所のリッチインデクシング技術 やっぱりAWS触ってみる。EMRまでとは言わないが。（herokuもちょっと興味あるが。） Mesos、GreenPlum、Scribe、Storm、Flume、Giraphこれらの概要 関連サイト 公式QAサイト。後日録画していたセッションがアップされるそうです Hadoop Conferene Japan Fall 2011 - 急がば回れ、選ぶなら近道 Hadoopカンファレンスが開催、本格普及を見据えた支援サービスや先進事例が充実 - ニュース：ITpro Hadoop Conference Japan 2011 fallで使用された資料 #hcj11f | インフラエンジニアのつぶやき（スライドをまとめてくれてます。）\n","date":1317113460,"dir":"post/2011/","id":"97402287d8c6c03f0b63848e17e9d944","lang":"ja","lastmod":1317113460,"permalink":"https://blog.johtani.info/blog/2011/09/27/hadoop-conference-japan-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-09-27T17:51:00+09:00","summary":"Hadoop Conference Japan 2011 Fallに行ってきました。 まずは、ユーザ会の方々、運営の方々、発表された方々お疲れ様でした。こんな機会を用意していただき、ありがとう","tags":["hadoop"],"title":"Hadoop Conference Japan 2011 Fallに参加してきました。(Jugemより移植)"},{"contents":"台風15号すごかったですね。幸いにも（？）夏休みだったので、通勤などでひどい目に合わずにすみました。 風雨はすごくてちょっと怖かったですが。。。\nさて、夏休みに進める予定が、子供の寝かしつけで一緒に寝てしまう日が続いてしまい、 間が開いてしまいました。\n0日目というタイトルになっているのは、まだ、1日目に入ってないからです。。。 Ioという未知の言語をMBAにそのままインストールするのも抵抗があり、VirtualBox上にLinuxをインストールしてから 進めようとして思いの外手こずってしまったためです。 ということで、0日目として、VirtualBox上にScientific Linux 6.1をインストールしてIoのインストールまでではまった箇所を記録として残しておきます。\n罠その１ 罠と言うよりは、私の無知に関する部類なのですが。。。 Scientific Linux 6.1のインストールは特に手こずることなくインストールでき、 起動も出来ました。 次にscpコマンドでダウンロードしてきたIoのソースをLinuxに渡そうとしてはまりました。 問題となったのはネットワーク接続が「NAT」のみだったため。 NATのため、Linux（ゲストOS）から外部への接続は可能だったのですが、Mac（ホストOS）からLinux（ゲストOS）への接続ができませんでした。 で、変更したのは以下の2点。\nVirtualBoxの環境設定-\u0026gt;ネットワーク-\u0026gt;ホストオンリーネットワークの追加 仮想マシン（Linux）の設定-\u0026gt;ネットワーク-\u0026gt;アダプタ2を有効にしてホストオンリーアダプタを割り当て 1番目のホストオンリーネットワークの追加をしておかないと、2番目のアダプタ2でホストオンリーアダプタを選択したときにエラーが出て、設定ができませんでした。割り当てるべきアダプタを先に用意しとかないとダメですよね、そりゃあ。\n罠その２ これも罠というほどではないのですが。。。 Ioのビルドにはcmakeが必要なのですが、Scientific Linux 6.1に入っているcmakeはバージョンが古い（2.6.4）ため、必要なバージョン（2.8以上）をインストールしないとダメでした。 インストール自体はcmakeのサイトにある手順通りのため割愛します。\n罠その３ これもちゃんとドキュメント読めよというレベルですが。。。 Ioのインストールは以下のコマンドを実行するという話です。 私がcmakeについて知らなかったと言われればそれまで。。。\n$ cd io $ mkdir build \u0026amp;amp;\u0026amp;amp; cd build $ ccmake .. $ make $ sudo make install 3つ目の「ccmake」の部分がIoのGetting Startedの下の方にありました。上の方に記載がある「cmake」ではエラーがでてうまく行かなかったので。 IoのGetting Startedにもありますが、ccmakeの場合はCUI上にGUIのようなものが起動するので、「c」（configure）と実行後、「g」（generate）を実行して最後に「e」（exit）でccmakeを離れます。 するとmakeが実行できるようになりました。\nあとは、/etc/ld.so.conf.d/io.confファイルを作成し、「/usr/local/lib」と記述。ldconfigを実行することで、Ioが実行可能になります。 ということで、1日目に入れず終了。。。\n明日は出来るかなぁ。\n","date":1316716440,"dir":"post/2011/","id":"62f31128a21b0e240bdb7b3d5b121c04","lang":"ja","lastmod":1316716440,"permalink":"https://blog.johtani.info/blog/2011/09/23/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-0%E6%97%A5%E7%9B%AE/","publishdate":"2011-09-23T03:34:00+09:00","summary":"台風15号すごかったですね。幸いにも（？）夏休みだったので、通勤などでひどい目に合わずにすみました。 風雨はすごくてちょっと怖かったですが。。","tags":["読書"],"title":"「7つの言語　7つの世界」 Io 0日目(Jugemより移植)"},{"contents":"Solr/Lucene 3.4がリリースされました。（速報）\n以下、各サイトへのリンクです。\nSolrリリースのお知らせ\nLuceneリリースのお知らせ\nちなみに、先日のSolr勉強会で関口さんが話されていたインデックスが壊れるバグですが、 先日のアメリカのハリケーン（Irene）で実際に電源が落ちて見つかったみたいです。\nということで、3.4がリリースされたので、3.1~3.3は利用しないほうがいいようです。\n追記： lucidimagination.jpのサイトに日本語のリリースノートが公開されていたので、リンクを記載しておきます。\n","date":1316046660,"dir":"post/2011/","id":"54da1b916f49ef40c822fab61d37cf66","lang":"ja","lastmod":1316046660,"permalink":"https://blog.johtani.info/blog/2011/09/15/lucene-solr-3-4%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/","publishdate":"2011-09-15T09:31:00+09:00","summary":"Solr/Lucene 3.4がリリースされました。（速報） 以下、各サイトへのリンクです。 Solrリリースのお知らせ Luceneリリースのお知らせ ちなみに、先日の","tags":["solr"],"title":"Lucene/Solr 3.4リリース（速報）(Jugemより移植)"},{"contents":"ということで、Rubyの最終日の感想。 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大募集です。コメント欄にどしどしコメントください。そこは違うだろ？こっちのほうがいいのでは？という感じで。\n感想： ◎メタプログラミングが特徴 例：ActiveRecordのhas_many、has_oneがいい例\n◎オープンクラス クラス定義をいつでも変更可能。 あらゆるクラスやオブジェクトをいつでも再定義できる 書きやすいコードのために再定義が可能＝何でもできるが気を付ける必要あり。 DSLの定義に便利。 確かに便利。ただ、範囲を限定しないと予期せぬ場所で問題が発生しそう。 ※解析するための手段はいいのがあるのかな？=\u0026gt;method_missingみたい\n◎method_missing 対象メソッドが見つからない場合に最後に実行されるメソッド 通常はNoMethodErrorが発行される。\n◎モジュールによるメタプログラミング defやattr_accessorなどその一例。 DSLではモジュール内にメソッドを定義してメソッド＋定数を利用 ActsAs\u0026hellip;ってそういう意味合いだったのか。 親クラスバージョン、親クラス＋マクロ、モジュールそれぞれの実装の仕方の紹介。 ※マクロもinclude同様、実行順で、メソッドの上書きが発生するのか？ ActiveRecordではメタプログラミングを利用してDBのカラム名からアクセサを追加。 シンタックスの美しさ＝読みやすさ\n感想＆疑問点： メタプログラミングはフレームワークを作成するのが便利そう。 ただし、エラーや問題が起きた時の対処をきちんと準備しておかないとひどい目に合いそう。 クラスやモジュールはわかりやすい単位で1ファイルにまとめるもの？ ファイル名の規則とかあったりする？ ディレクトリ構成でパッケージ構成が可能？ 複数のモジュール（gemとか）を組み合わせて使っている場合にincludeの順序がどのようになるかが気になる。 予期せぬ順序でincludeされて利用しようと思ったメソッドがオーバーライドされてるとかありそう。 追っかけるのがまた大変そうだ。 異なるパフォーマンス（開発者の開発速度）の観点が一番おもしろかった。ただ、なれるまでは大変そう。すんなりinjectとかコードブロックをうまく利用するイメージがわかない。 まぁ、思考については反復練習かな。これは他の言語でも一緒かな\nようやく、Rubyの世界が終わりました。楽しかった。次は未知の言語である「Io」です。\n（試してみよう：） ○eachメソッドがCsvRowオブジェクトを返すようにCSVアプリケーションを変更せよ。そのCsvRowのmethod_mmissingを使って、与えられた見出しの列の値を返すようにせよ。 モジュールにて実装してみた。 ``` module ActsAsCsv\ndef self.included(base) base.extend ClassMethods end module ClassMethods def acts_as_csv include InstanceMethods end end\nmodule InstanceMethods\ndef read @csv_rows = [] file = File.new(self.class.to_s.downcase + '.txt') headers = file.gets.chomp.split(', ') file.each do |row| @csv_rows \u0026lt;\u0026lt; CsvRow.new(headers,row.chomp.split(', ')) end end def each(\u0026amp;block) csv_rows.each(\u0026amp;block) end attr_accessor :csv_rows def initialize read end end\nclass CsvRow def initialize(headers, csv_contents) @headers = headers @csv_contents = csv_contents end\nattr_accessor :headers, :csv_contents def method_missing name, *args csv_contents.fetch(headers.find_index(name.to_s)) end end end\nここまでが実装したモジュール＋クラス。 以下は実行例。id,name,sizeというheaderをもつCSVを使ってみた。 require \u0026lsquo;acts_as_csv_module_mod.rb\u0026rsquo; =\u0026gt; true class RubyCsv include ActsAsCsv acts_as_csv end =\u0026gt; RubyCsv csv = RubyCsv.new =\u0026gt; #\u0026lt;RubyCsv:0x103c4c530 @csv_rows=[#\u0026lt;ActsAsCsv::CsvRow:0x103c4c030 @csv_contents=[\u0026ldquo;1\u0026rdquo;, \u0026ldquo;RubyCsv.class\u0026rdquo;, \u0026ldquo;20\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;, #\u0026lt;ActsAsCsv::CsvRow:0x103c4be78 @csv_contents=[\u0026ldquo;2\u0026rdquo;, \u0026ldquo;JRubyCsv.class\u0026rdquo;, \u0026ldquo;50\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;]\u0026gt; csv.each {|row| puts row.name} RubyCsv.class JRubyCsv.class =\u0026gt; [#\u0026lt;ActsAsCsv::CsvRow:0x103c4c030 @csv_contents=[\u0026ldquo;1\u0026rdquo;, \u0026ldquo;RubyCsv.class\u0026rdquo;, \u0026ldquo;20\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;, #\u0026lt;ActsAsCsv::CsvRow:0x103c4be78 @csv_contents=[\u0026ldquo;2\u0026rdquo;, \u0026ldquo;JRubyCsv.class\u0026rdquo;, \u0026ldquo;50\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;] csv.each {|row| puts row.id} (irb):8: warning: Object#id will be deprecated; use Object#object_id 2179096600 (irb):8: warning: Object#id will be deprecated; use Object#object_id 2179096380 =\u0026gt; [#\u0026lt;ActsAsCsv::CsvRow:0x103c4c030 @csv_contents=[\u0026ldquo;1\u0026rdquo;, \u0026ldquo;RubyCsv.class\u0026rdquo;, \u0026ldquo;20\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;, #\u0026lt;ActsAsCsv::CsvRow:0x103c4be78 @csv_contents=[\u0026ldquo;2\u0026rdquo;, \u0026ldquo;JRubyCsv.class\u0026rdquo;, \u0026ldquo;50\u0026rdquo;], @headers=[\u0026ldquo;id\u0026rdquo;, \u0026ldquo;name\u0026rdquo;, \u0026ldquo;size\u0026rdquo;]\u0026gt;]\n\u0026lt;span style=\u0026#34;color:#FF0000\u0026#34;\u0026gt;※idというcsvフィールド名にしたら、object_idとかぶっているようでwarningが出てしまった。\u0026lt;/span\u0026gt; CsvRowクラスの定義がモジュールの中に入っているが、この実装でも動くみたい。ただ、パッケージみたいな感じ7日までは調査してない。。。 ","date":1315992060,"dir":"post/2011/","id":"41b811063b9425de1934e77d89118022","lang":"ja","lastmod":1315992060,"permalink":"https://blog.johtani.info/blog/2011/09/14/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-3%E6%97%A5%E7%9B%AE%E6%9C%80%E7%B5%82%E6%97%A5/","publishdate":"2011-09-14T18:21:00+09:00","summary":"ということで、Rubyの最終日の感想。 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大","tags":["読書"],"title":"「7つの言語　7つの世界」 Ruby 3日目（最終日）(Jugemより移植)"},{"contents":"「第6回Solr勉強会」に参加しました。 なんだかんだと第6回で、今のところ皆勤賞です。\nということで、主に自分用ですが、メモなどとったので。\n概要\n日時 :2011/09/12 19:00 to 21:00 定員 :110 人 会場 :株式会社 ECナビ 1.「Lucene/Solr 3.2-3.4」 by ロンウイット 関口 宏司さん ※Solr2.9.4、3.1でデグレードし、Solr3.4で修正されたバグがあります。 インデックス中にPCがシャットダウンされた場合にインデックスが壊れてしまうものあり。 Solr3.1-3.3は使用しないようにとのこと。 ○index ・IndexWriter.addDocuments(docs) 複数ドキュメントの更新が可能になった。 ※検索で話をする親子関係のNestedQuery向けの登録にも利用する。 この登録では途中でフラッシュされないため、セグメントが分割されない特徴あり。 複数だけでなく、 ・TieredMergePolicy ※Lucene3.2/Solr3.3からデフォルトになった。 新しいインデックスのマージポリシー。（amebaの開発者ブログに説明があった。） インデックスの登録順が守られていたが、このマージ処理では保証がされなくなったので注意が必要。 ・update.chain update.processorがdeprecatedに。 update.chainというパラメータに変更 ○index(cont\u0026#39;d) ・TwoPhaseCommit ・UniqFieldsUpdateProcessor 重複した値を削除するための機能。 UIMAでの提案から取り込まれた ○search ・group=on 検索グルーピング機能を使えるパラメータ ・{!term} クエリパーサを通さないでTermQueryをかける機能。 ・structured explanation debug=onの算出根拠を XMLタグで構造化されたExplanationが取得可能に ・ReloadCacheRequestHandler 関口さん担当。ExternalFileField インデックス外（外部ファイル）を元にFunctionQueryの情報を利用可能にできるのだが、 このファイルのリロードが可能になる。 ・Carrot2　3.5.0 アップグレード。 デモあり。Carrot2のworkbenchとか　○search(cont\u0026#39;d) ・hl.phraseLimit parameter FastVectorHighlighterの高速化用パラメータ。 ・{!cache=false} キャッシュを利用しないためのローカルパラメータ。fqのローカルパラメータに利用可能。 検索セッション内でキャッシュへの処理（参照・登録）をしなくなる ・BlockJoinQuery NestedDocumentQueryの名前が変更された。 （Luceneで登録されたところまで。） ○schema ・KStemFilter PoterStemmerとは別のstemmer ・ReversePathHierarchyTokenizer パスの構造化インデックスの逆バージョン ・ommitPositions=\u0026#34;true\u0026#34; 指定が可能になった。 ・version 1.4 スキーマのバージョンが新しくなった。 ○admin/tools ・action=MERGEINDEXES\u0026amp;srcCore=coreName コア名指定可能。 ・action=UNLOAD\u0026amp;deleteIndex=true UNLOAD時にインデックス削除 ・action=CREATE\u0026amp;property.name ※ぎゃーーー。打ち込み失敗。 ○ぎゃーーーー失敗。 ○技術者大募集中！！ Q\u0026amp;A Q：クラスタリングの日本語は大丈夫？入門には制限があると記載があったが。 A：analyzerが記載が簡単になってるかは不明 前処理をして別フィールドにメタデータ的にある程度単語で区切ったようなものを作成したほうがいい。 Q：グルーピングで、グルーピング後のファセット件数が取得可能か？ A：3.4ではグループ数で表示可能。 パラメータ指定で可能。 2.「Solr＠cookpad」 by ＠PENGUINANA_ さん ○COOKPADとは？ ・レシピ投稿サイト ・105万のユーザのレシピ ・30代女性の1/2が利用 ○レシピ検索 ・PC：1307万UU、1億回強/月 ・モバイルで利用が多く、スーパの店頭などで利用？ ・Androidもあるよ。 ○人気順検索（Solrですよ） ○自己紹介 ・＠PNGUINANA_ ・情報可視化＋検索が好き！！ yats、など ○Solrはどのように利用 ・レシピ検索 ・もしかして ○Tritonnから移行 同じ検索結果になるようにして徐々に移行 ○なぜ？ パフォーマンスが良い。 フィールド追加が簡単 レプリケーション-\u0026gt;ファイルベース プロトタイピングが楽 ○Solr4 nightly（on Oracle JVM） ・マルチコア利用 ・Ruby on Railsから ○簡単な構成＋説明 ・バッチからSolrへの更新をしている。 ※Analyzerを利用せず、バッチ側で分かち書き、正規化、同義語展開を行っている。 Rubyで全部かけるほうが社内に展開しやすい。 ・バッチ終了後、可能ならoptimize ※検索速度がmax20%高速になる。 ・マスタ-\u0026gt;スレーブレプリケーションはschema.xmlもレプリケート 新規フィールド追加などはレプリケーションだけで実行できて楽。 ・アプリはMySQLとSolrのSlaveにアクセス。 Solrにはidのみ。本文はMySQLから取得 インデックスサイズを小さくできる＝レプリケーション時間が短くなる オンメモリにできるため検索速度も向上 ○監視（munin） ・監視項目（コア別）： クエリ：QTime/QPS キャッシュ：hit/eviction キャッシュから漏れている数をみてキャッシュサイズを定期的に変更して無駄をなくす インデックス：サイズ/docの数 運用してから重要。開始当初は気にしてるが、そのうち気にならなくなるため。 レプリケーション：所要時間 スレーブ間でのズレを検知するため。 ※コアごとに監視することで、問題点を把握しやすくしている。 ○監視（nagios） ・監視項目（コア別）： サーバの基本的なヘルスチェック Solrが動いてるサーバのはなし。 レプリ：インデックスバージョンのチェック ズレが長いとメールが飛ぶ ○便利だった機能 ・DynamicField フィールドをあとから簡単に追加可能。 例：人気順のアルゴリズムの違うフィールド。検索用フィールド ・FacetQuery 絞り込み検索をクエリで記載可能。 現時点では社内向け検索機能で利用。 ※ファセットで簡単な解析もやってる。 例：鍋の季節ごとの登録件数。 ・HTTP経由で色々可能 検索の並列化 通常検索画面：3クエリを同時実行 あるプロトタイプ画面だと8クエリで実行したりしてる。 ・分散検索（Distributed Search） 簡単にsharding可能 思いクエリは４shardで投げる オーバヘッドが大きいので思いクエリにだけ利用しているらしい。 ○開発の流れ ・まずはステージングを更新 ・問題なければマスターも更新 例外： フィールド追加するだけだったら直接マスタへ 例：ファセット追加など。 ○パフォーマンスとか大丈夫？ 本番で複数のバージョンを持っており、 バグっていても自動フォールバックするらしい。 価値があったらパフォーマンス向上＋テスト追加 例：スニペット変更 ○気になっている機能 ・not to cache(SOLR-2429) ・SurroundQuery(Solr-2703) ・JOIN(SOLR-2272) SQLのJOINなイメージ ・BloomFilter(SOLR-1375) 単語が存在するかどうかのチェック ○Solr入門おすすめ ○おすすめ ・http://blog.sematext.com 月一で新機能が出てくる ・SolrのJIRA ・@otisg ○今後やりたいこと ・わかち書きの精度向上 ・検索セッションの分析 nDCG、クエリ分類、検索意図 ・デバイス対応 ・パーソナライズ Q\u0026amp;A Q：同義語は誰が集めている？ A：外部辞書を利用。０件キーワードから解析して取得 単語登録も一緒。 Q：プチトマトとトマトの違いはどうやってる？ A：上位、下位の概念で同義語を利用している。 本にあるよ。 Q：もしかしてはSolrの機能？ A：Solrではない。訂正候補の単語をSolrに検索してからチェックして表示する。 Q：人気順はどういった計算をしてるんですか？計算してから登録？By 大谷 A：１フィールドに外から入れている。 Q：RubyからSolrの利用方法は？独自？ライブラリ？By 大谷 A：Rsolrを利用しており、コネクション管理にだけ利用している。 あとは、ラッパーを独自で作成。 Q：4.0を利用している理由は？なかなかチャレンジャー。By関口 A：グループクエリを利用したかったため。 実際には重くて使えていない。 今は必要ないかもと思っている。年始のバージョンを利用。いつでも入れ替え可能。 マスタスレーブ構成のsolrのバージョンアップはサービスアウトしてから入れ替える。 3. 「Solrを用いた検索システムの構築」　by データセクション株式会社 高井さん いろいろな試行錯誤について ○データセクションについて 言語処理を元にデータの解析（Twitterとかブログとか）している会社。 ・昔は自社で検索サーバを構築していた ・Luceneを利用して検索サーバを構築するように変更。 ○構成（過去？） ・Lucene＋RMI 3.0から縮小で、4.0で廃止に ○SolrにするかLuceneにするか？ ・いろいろ機能があるからSolr使ってみるかｗ ○Solr導入は1.4.1から スペック マスタ： メモリ：16G Disk：2Tｘ12 スレーブ： 256GのSSDを利用 JavaVMが32bit ○ひと月分を1shardにして登録 ○検証＋手探り？ メモリが足りない。 Solrのキャッシュを全Offに。 BOBO SolrPluginってのを利用 compressオプションも利用。 各スレーブにキューを用意して1つだけしか処理しない。（なんでだ？？） ○結果 キャッシュはフィルタキャッシュのみ利用 ユーザが同じクエリを投げるのはほぼないので。 フィルタキャッシュのエントリのメモリ量の計算式（あとで資料が出てくるかなぁ。） ○問題点 ・レプリケーションでインデックスサイズの2倍の容量が必要になる。 ・レプリケーションの日時フォーマットのバグ（SOLR-1995）を踏んでしまった。 ・レプリケーション後にインデックスが消えない場合がある ○検討（1.4.1-\u0026gt;3.2） うれしい要素 レプリケーションバグがfix 省メモリや範囲検索の高速化など　かなしい要素 compressが使えなく（しかも回答してからriindexしてくれる） ○検討 余計なインデックス消す nearinfinityが出しているlucene-compressionを利用 https://github.com/nearinfinity/lucene-compression ○残った問題 facet.rangeが使えないなど。 ○じゃあ集約サーバつくっちゃえ（すごいな。） facet書き換えコンポーネントなど。 ○シャードのインデックスサイズが下がった 130GiB-\u0026gt;90GiB これはlucene-compressionの効果 ○ここまでの変更はプラグインにて対応（この一覧いいかも） ○感想 コンポーネント化されてて、簡単に追加機能が実装可能 用途次第であまりスペック高くなくても使える。 Q\u0026amp;A Q：Twitterのデータのクロール方法は？ A：HTMLをスクレイピングしている。publicなTLのみ。 Q：いきなりSolrに入れる？Solrの前処理は？ A：SolrJを利用して前処理済みのデータを登録している。 4. 「Anuenueの紹介と最近の進捗」 by @takahi_i さん（mixi） ○自己紹介 ・NAIST出身 ・ファストサーチ ・今はmixi ○mixiとは？ ○社内の緊急タスク ・内製検索エンジンをメンテナンスしやすいOSSにしたい！ -\u0026gt;Solrを選択 Anuenueも実装 ○Anuenueの作成理由は？ インデックス運用が面倒（検索（distributed search）はあるがインデックスは自前） クラスタ用のコマンドが提供されていない。 ○Anuenueが提供する機能 ・検索クラスタの簡単設定 ・クラスタ用コマンド ・もしかして機能 ○機能：Anuenueのクラスタ設定 Merger：クライアントからのクエリをMasterに分散 Master：インデックス作成側 Slave：検索用スレーブ。マスタからコピー ○クラスタの管理コマンド クラスタのコマンドを用意。 起動、コミット、登録など ○SolrCloud向けのAnuenueを検討中 branch-cloudにあります。 今後の予定 インスタンス追加削除を動的に実行できるようにしたい ○Hadoop Conferenceの宣伝ｗ Oluolu：Hadoop上で動くクエリログマイニングツール Likelike：LSHをHadoopで実装（Hadoop Conference 2011 Fallで発表） 5. LT 5.1　「solrとRの連携について」　by @yutakashino さん（BakFoo） Python本、Zope本を書いてます。 ○NHKの実証実験で利用？ ○TwitterストリームをSolrにストア facet.date ○Rでキーワード頻度グラフ Node.js、Redis、R、Solrを使ってる。しかもPython ○デモ キーワード＋日付でグラフが出てくる。 Rでプロット。 GoogleのチャートAPIを利用すると面白いことができる。 5.2　「 Apache ManifoldCF」　by 阿部さん(ロンウィット) ○Apache Incubator ○Manifold Connector Framework Solr ＜－ MCF ＜－ web＋non-web repositories すぐに利用可能。 ○概要 出力はSolr。 接続先はWeb、DB、CMS、などなどいろいろRepositoryConnectorというのがあります。 ○Crawler Agent クロールに関するJobの管理 接続先、スケジュールなど ○Windowsサーバのクロールもできる 社内のナレッジ共有などに使える。権限周りも簡単に対応可能。 JCIFS.jarによりWindowsの権限情報を取得 ○クロール設定画面もある デモ ○導入が簡単なのがおすすめ。 ○ManifoldCFの資料関連 http://www.manning.com/wright 懇親会についてはあとで記載します！！ ということで追記です。 懇親会でも色々と面白い話を聞けました。 @PENGUINANA_さんにはCOOKPADのCI関連の話を聞けました。 1日に数度リリースするという話もあるようでした。\nあとは、Rについても@yutakashinoさんから概要が聞けたのが良かったです。\nちょっとだけ追記。まだ成形する予定ですが、とりあえず。\n追記：スライドが公開され始めたので。\n関口さんのスライドはこちら 阿部さんのスライドはこちら ＠PENGUINANA_さんのスライドはこちら。 @takahi_iさんのスライドはこちらからPDFダウンロード可能。\nその他に関連するブログも見つけましたので。 「Solr@Cookpad」- Solr勉強会で発表してきました Ars longa, vita brevis: 第６回 Solr 勉強会に行ってきた\n勉強会で出てきた各製品などのリンク： 色々とURLが出てきていたので、リンクをまとめておきます。\nlucene-compression Anuenue Apache Solr のラッパー Likelike LSH (Localtiy Sensitive Hashing)の実装 OluOlu 検索ログマイニングツール @takahi_iさんのLuceneRevolution2011のスライド Kuromoji 形態素解析器 lucene-gosen 形態素解析器（Senの後継） Apache ManifoldCF ","date":1315810980,"dir":"post/2011/","id":"37b622eaad1f79e759a722aacebf48ec","lang":"ja","lastmod":1315810980,"permalink":"https://blog.johtani.info/blog/2011/09/12/%E7%AC%AC6%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-09-12T16:03:00+09:00","summary":"「第6回Solr勉強会」に参加しました。 なんだかんだと第6回で、今のところ皆勤賞です。 ということで、主に自分用ですが、メモなどとったので。 概","tags":["勉強会"],"title":"第6回Solr勉強会に参加しました。(Jugemより移植)"},{"contents":"ということで、Ruby2日目の感想（2日目だけで2日間かかったのは内緒。。。） 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大募集です。コメント欄にどしどしコメントください。そこは違うだろ？こっちのほうがいいのでは？という感じで。\n感想： ◎関数の定義：ありゃ、利用するのはダメなんだ、これじゃ。\u0026ndash;\u0026gt;単なるタイプミスでした。お恥ずかしい。。。 \u0026gt;\u0026gt; def tell_the_truth \u0026gt;\u0026gt; true \u0026gt;\u0026gt; end =\u0026gt; nil \u0026gt;\u0026gt; tell_the_trueth() NoMethodError: undefined method `tell_the_trueth\u0026#39; for main:Object from (irb):4 ◎配列：そしてシンタックスシュガー puts animalsで内容が出力されるのはうれしい。JavaだとHashCodeが出てくるから。出力メソッド書かないといけなくなる。 animals[-1]で最後の要素とかかなり便利。 animals[0..1]はRangeクラスを利用する形。Rangeはやはり便利。substringなどもできそう。 カラ配列の定義は必要。a = [] 1.9と1.8でinclude?の書き方が異なるので注意！ 配列（Array）クラスは中はObjectが入る。 多次元配列もOK。popやpushでキューとしても利用可能。\n◎ハッシュ： Mapのようなもの。任意のキーが利用可能。:付きの文字列はシンボルと呼ばれる定数値を簡単に定義する方法。 object_idという属性？関数によりObjectのハッシュコードが取れるらしい。 ブレース＝「{}」のカッコのこと。do～endでも代用可能\n◎コードブロックとyeild コードブロック＝名前なし関数。習慣では複数行の場合、do/endで、１行は{}みたい。Javaと混同しそう。 コードブロックは引数も指定可能。 「yield」予約語？を利用してコードブロック自体をメソッド内部などで呼び出し可能。 ということで、コードブロックは引数にも指定できると。コードブロック＝関数もObjectとして扱われてる感じか？ 実行遅延、分岐、共通関数とか？Javaだとabstractメソッドを利用して処理するようなイメージか？ちょっと違うなぁ。 なれると、yieldはコードを読みやすくできそう。また、シンタックスハイライトしてくれるツールがあれば、更に便利。\n◎ファイルの実行 ruby ファイル名 vi、Emacs、TextMateなどがあるよ。\n◎クラスの定義 ※数字で始まる変数は利用できない！Javaと一緒 Tree.rbとログを参考にすること。 \u0026amp;使うとブロックに名前が付けられる。yieldじゃなくてもいい？ クラス名はキャメルケース。 変数とメソッド名は「_」アンダーバーつなぎ インスタンス変数の頭は@ クラス変数は@@ 定数は大文字 ※メソッド名、変数名には違和感が。なんでこんな規則？？ 判定用関数とメソッドには「?」（if test?）をつける！！Javaでいう「is」か。\n◎Mixin（多重継承？モジュールと呼ばれるものを利用） 多重継承のような類似の振る舞いを伝搬する仕組み。 Javaではインタフェースでやること。 Rubyではモジュールといい、関数と定数の集まり。 クラスに機能を盛り込む場合はincludeする ※複数includeして、includeしたものの中に同じメソッドとかあったらどーなる？ \u0026ndash;\u0026gt;Overrideされた＝includeがあとにあるもので上書きされる Abstractにできないものをモジュール化できるの楽。 javaだとstaticメソッドだらけのUtilクラスを別途起こすイメージだけど、内部で呼ばれるメソッド（コードブロック）が同じインタフェースじゃないと行けないから、インタフェースの記述もしないと行けない。 ただし、同一名のメソッドを持ってるとややこしそう。 ※モジュールからモジュールは呼べる？\n◎モジュール、Enumerable、セット EnumerableとComparable（JavaのCollectionまわりかな。） 宇宙船演算子（\u0026lt;=\u0026gt;）Javaのequalsに似てる any?とかCollectionUtils？？に似たのあったな。 ※今利用しているクラスが何をincludeしてるかってのは分かる仕組みあるのかな？ ※そういえば、メソッドごとに戻り値があるが、全部newされてインスタンス化されてGCの対象になってるのか？irbだけ？ injectはすんなり使うイメージが出にくそう。また、ソースをぱっと見て理解出来ない。なれだろうけど。 ※injectしながらinjectとかあるんだろうな。\n（探してみよう：） ○コードブロックを使った場合と使わない場合の両方について、ファイルにアクセスするコードを書く。コードブロックの利点は？ ※コードブロックあり。 ``` File.open(\u0026ldquo;tree.rb\u0026rdquo;, \u0026lsquo;r\u0026rsquo;) {|f| f.each {|line| puts \u0026ldquo;#{f.lineno} : #{line}\u0026rdquo;}}\n※コードブロックなし f = File.open(\u0026ldquo;tree.rb\u0026rdquo;, \u0026lsquo;r\u0026rsquo;) while line = f.gets puts \u0026ldquo;#{f.lineno} : #{line}\u0026rdquo; end\nコードブロックの利点： 見通しの良さ。行数が少なくてすむ。繰り返し処理が簡単に記述できる。 ※うーん、まだきちんと理解できてないか？ \u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○ハッシュを配列に変換するにはどうすればよいか？また、逆に配列をハッシュに変換する方法は？\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt; ※間違えた。。。 h = [:key1 =\u0026gt; \u0026ldquo;hoge\u0026rdquo;, :key2 =\u0026gt; \u0026ldquo;boke\u0026rdquo;, :key3 =\u0026gt; \u0026ldquo;fuga\u0026rdquo;] h.each {|key, value| puts \u0026ldquo;#{key} is #{value}\u0026rdquo;} =\u0026gt;key1hogekey2bokekey3fuga is\nハッシュ-\u0026amp;gt;配列変換 h.to_a\n配列-\u0026amp;gt;ハッシュ変換 a = [\u0026ldquo;value1\u0026rdquo;, \u0026ldquo;valu2\u0026rdquo;, \u0026ldquo;value3\u0026rdquo;] h = {} a.each {|i| h.store(a.index(i),i) }\n※また間違い？なんでそうなる？ a.inject(h2) {|hoge, i| hoge[a.index(i).to_s] = i}\nこっちならいいみたい。まだinjectがわかってない。 a.inject(h2) {|hoge, i| hoge[a.index(i).to_s] = i;puts \u0026ldquo;#{i}\u0026rdquo;; hoge}\n\u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○ハッシュの各要素について繰り返すにはどうすればよいか？\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt; h.each {|key, value| puts \u0026ldquo;#{key} is #{value}\u0026rdquo;}\n\u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○Rubyの配列はスタックとしても使える。スタック以外に配列で実現可能なよくあるデータ構造体を挙げよ。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;キュー。 他にある？Treeとか？Treeはハッシュじゃないか？Set？順番が関係ないけど。\u0026lt;/dd\u0026gt; \u0026lt;/dl\u0026gt; ### **（試してみよう：）** \u0026lt;dl\u0026gt; \u0026lt;dt\u0026gt;○最初に、eachだけを用いて、１６個の数値と４個の数値の配列の中身を同時に出力せよ。次に、同じ事をEnumerableのeach_sliceを用いて実行せよ。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt; \u0026lt;span style=\u0026#34;color:#FF0000\u0026#34;\u0026gt;\u0026lt;em\u0026gt;※これ日本語がわからないんだが、4個ずつ出せってことか？？\u0026lt;/em\u0026gt;\u0026lt;/span\u0026gt;ということで、「16個の数字の配列の中身を4個ずつ同時に出力せよ。」と解釈して実装してみた ※each利用版 a = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16] s = [] a.each do |b| unless s.length \u0026lt; 4 puts s.inspect s.clear end s \u0026laquo; b end\n※each_slice a = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16] a.each_slice(4) {|b| puts b.inspect}\nまた、えらい違いだな。 \u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○Treeクラスは面白いクラスだったが、きれいなインタフェースを用いて新しいツリーを指定することは出来なかった。そこで、initializerにハッシュと配列が入れ子になった構造体を指定できるようにせよ。具体的には、次のようなツリーを指定できるようにしたい。{\u0026#39;grandpa\u0026#39; =\u0026amp;gt; { \u0026#39;dad\u0026#39; =\u0026amp;gt; {\u0026#39;child 1\u0026#39; =\u0026amp;gt; [], \u0026#39;child 2\u0026#39; =\u0026amp;gt; [] }, \u0026#39;uncle\u0026#39; =\u0026amp;gt; {\u0026#39;child 3\u0026#39; =\u0026amp;gt; [], \u0026#39;child 4\u0026#39; =\u0026lt; [] } } }\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;\u0026lt;span style=\u0026#34;color:#FF0000\u0026#34;\u0026gt;※root（ここではgrandpaレベル）が複数あると破綻しないのか？\u0026lt;/span\u0026gt; class Tree attr_accessor :children, :node_name\ndef initialize(name, children=[]) @children = children @node_name = name end\ndef initialize(hash) hash.each do |key, value| @node_name = key @children = value.inject([]) do |array, (child_key, child_val)| puts \u0026ldquo;inject! #{key}\u0026rdquo; [Tree.new({child_key =\u0026gt; child_val})] + array end end end\ndef visit_all(\u0026amp;block) visit \u0026amp;block children.each {|c| c.visit_all \u0026amp;block} end\ndef visit(\u0026amp;block) block.call self end end\n残念ながらちょっとカンニングしてしまいました。。。 \u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt; ○ファイル内で、あるフレーズを含む全ての行を出力する簡単なgrepをかけ。簡単な正規表現でマッチングを行い、ファイルから行を読み出す必要がある（この処理はRubyでは驚くほど簡単にかける）。必要なら行番号も出力してみると良い。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;※メソッドだけでいいな。\u0026lt;span style=\u0026#34;color:#0000FF\u0026#34;\u0026gt;ファイルクローズはこの記述の場合はコーディングブロックのendのタイミングでクローズされるのか？\u0026lt;/span\u0026gt; class RegGrep def grep(filename, regexp) File.open(filename, \u0026lsquo;r\u0026rsquo;) do |f| f.each do |line| puts \u0026ldquo;#{f.lineno} : #{line}\u0026rdquo; if line.match(regexp) end end end end\n\u0026lt;/dd\u0026gt; \u0026lt;/dl\u0026gt; ということで、2日目終了。 恥ずかしいコードだらけだけど、ぜひツッコミ入れてもらえると助かります。 数年前までは、恥ずかしいからとか見せられるレベルじゃないからと、ほとんどアウトプットしなかったのですが、 最近はそれではものすごく損をしていると思っています。 ホントは発表するとか議論するとかする場もあればいいのですが。 アウトプットすることで、フィードバックが貰えて、いろんなかたの考えが参考になり、糧となり成長していけるのかと。 （これじゃ成長できないレベルだよという話でなければいいのだが。。。） 一度、Rubyのプロフェッショナル各位に見てもらいたいなぁｗ ","date":1315588260,"dir":"post/2011/","id":"73262345214f9b7794f2cc4a612b15e8","lang":"ja","lastmod":1315588260,"permalink":"https://blog.johtani.info/blog/2011/09/10/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-2%E6%97%A5%E7%9B%AE/","publishdate":"2011-09-10T02:11:00+09:00","summary":"ということで、Ruby2日目の感想（2日目だけで2日間かかったのは内緒。。。） 今回もセルフスタディの私の回答が最後の方に記載されてます。見た","tags":["読書"],"title":"「7つの言語　7つの世界」 Ruby 2日目(Jugemより移植)"},{"contents":"実に3年ぶりくらいにゆっくりできる日々が訪れたので、積読状態の本を消化しようと「7つの言語　7つの世界」を読み始めました。\nせっかくブログも始めたので、備忘録も兼ねて感想などを書いていこうかと。\nこの本ですが、以下の7つの言語についてエッセンスがまとめられています。\nRuby Io Prolog Scala Erlang Clojure Haskell まずはRubyからです。 ここ2年ほどRuby（Rails）に関連する仕事をしていたのですが、Ruby周りはプロフェッショナルな方たちがいたので、きちんと勉強していないことがこの本を読み始めてわかりました。\nということで、前置きはそれなりな記述ですが、感想は適当になりますので、あしからず。\n感想： irbが便利。簡単に動作確認ができるのが便利。Javaだとコンパイルが必要。 変数を定義する必要がない気軽さはある。 必ず戻り値が帰ってくる「puts \u0026lsquo;hello, world\u0026rsquo;」でも。=\u0026gt;nil putsは楽かな。まぁ、Eclipse使ってると一緒か。 「4」もオブジェクトとなっている。ここもJavaと異なる。 (x \u0026lt;= 4).classという記述でTrueClassというクラスだとわかる。 unlessが結構便利。ただし、記述方法が多数あるので、可読性は落ちる？場合によってはわかりやすいか？ あと、括弧()がないのも慣れない。（まぁ、これは慣れの問題。ただし、カッコありでもOK） {}のかわりがif～endなのはわかりやすいかも。 if not はわかりやすくていい。!はだいたい間違えるから。。。 whileも１行形式で書けるのか。「x = x + 1 while x \u0026lt; 10」慣れないと厳しい。個人的には混在すると読めないなぁ。 nilとfalse以外がすべてtrueに評価されるのは厳しいのでは？型のチェックがないので、booleanが入ってると想定してない場合に挙動を読めないかも。実行時に動作が変だなーと思うことが出てきそう。 and、orの記述が使えるのは読みやすい。ただし、混在するとやっかい。 判定結果が明らかになった時点で実行が中止されるのは普通。\u0026amp;、|の挙動はJava同様。\nやりながら疑問点：\nNetBeansとかIDEでフォーマッタやcheckstyleみたいなのはあるのか？ コーディング規約はあるのか？（2日目に「習慣」があるらしいとの記載があった。） 必ず戻り値が戻ってくるのは、必ずGC対象になりうるオブジェクトが生成されるってことか？ ここまでが感想と疑問点。で、この本の面白いところは最後に調査、コーディングを行う練習問題的なものがある部分です。 一応、私なりの答えを書いておこうかと。（一覧などで見えないようにはしますが、ネタバレがあるので注意してください。）\nということで、セルフスタディの回答。\n（探してみよう） ○Ruby API http://ruby-doc.org/core/ ○Programming Ruby: The Pragmatic Programmer's Guideのオンライン版 http://www.ruby-doc.org/docs/ProgrammingRuby/参考資料：http://www.swlab.it.okayama-u.ac.jp/man/ruby/uguide/uguide00.html ○文字列の一部を置換するメソッド \"hello\".gsub(/[aeiou]/, '*') ○Rubyの正規表現に関する情報 日本語：http://www.namaraii.com/rubytips/?%A5%D1%A5%BF%A1%BC%A5%F3%A5%DE%A5%C3%A5%C1 英語の試せるサイト（irbが動けば必要ないかもね）：http://rubular.com/ ○Rubyの範囲に関する情報 日本語：http://doc.okkez.net/static/192/class/Range.html 英語：RDocのRangeクラスに相当するのかな。 （試してみよう） ○文字列\"Hello, world\"を出力する。 ``` ○文字列\"Hello, Ruby\"の中の\"Ruby\"という単語のインデックスを検索する。 ``` s = \u0026lsquo;Hello, Ruby\u0026rsquo; s.index(\u0026lsquo;Ruby\u0026rsquo;) //indexofで間違えた\n\u0026lt;dt\u0026gt;○自分の名前を10回出力する。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;``` ※まずは、正統派。 i = 0 while i \u0026lt; 10 puts \u0026#34;johtani\u0026#34; i = i + 1 end ※Rangeを利用 (1..10).each {|n| puts \u0026#34;johtani #{n}\u0026#34;} ※forもあるよね for i in 1..10 puts \u0026#34;johtani\u0026#34; end ※timesってのもある。（0始まり） 10.times {|n| puts \u0026#34;johtani #{n}\u0026#34;} ※uptoなんてのもあるのか。 1.upto(10) {|n| puts \u0026#34;johtani #{n}\u0026#34;} ※downtoも 10.downto(1) {puts \u0026#34;johtani\u0026#34;} ※stepもある。 10.step(1, -1) {puts \u0026#34;johtani\u0026#34;}//step(上限,ステップ) ```\u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○文字列\u0026#34;This is sentence number 1\u0026#34;の1を10までカウントアップしながら10回出力する。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;``` 1.upto(10) {|n| puts \u0026#34;This is sentence number #{n}\u0026#34;} ※あとは上記と一緒 ```\u0026lt;/dd\u0026gt; \u0026lt;dt\u0026gt;○ファイルに格納されているRubyプログラムを実行する。\u0026lt;/dt\u0026gt; \u0026lt;dd\u0026gt;``` vi hoge.rb ※#上記処理をどれか記述 $ ruby hoge.rb ○ボーナス問題：少し物足りない人は、乱数を選択するプログラムを書いてみてほしい。プレーヤーに数字を選択してもらい、その数字が生成された乱数よりも大きいか小さいかを返す。 ``` -- coding: utf-8 -- range = (1..100) while true puts \u0026ldquo;#{range.min}から#{range.max}の数字を入力してください\u0026rdquo; n = gets n = n.to_i if range.include?(n) break; else puts \u0026ldquo;範囲外の入力値です。もう一度入力してください\u0026rdquo; end end i = rand(range.max) if i \u0026lt; n puts \u0026ldquo;入力「#{n}」は乱数「#{i}」より大きいです\u0026rdquo; elsif i == n puts \u0026ldquo;入力「#{n}」は乱数「#{i}」と等しいです\u0026rdquo; else puts \u0026ldquo;入力「#{n}」は乱数「#{i}」より小さいです\u0026rdquo; end\n\u0026lt;/dl\u0026gt; とまぁ、こんな感じ。こんな方法もあるよ、ここおかしくない？などあれば、コメント欄まで。 リアクション大募集です。 はやく、シンタックスライター導入せねば。 ","date":1315545120,"dir":"post/2011/","id":"9baedcd033169611a42c3cfd58b3ae03","lang":"ja","lastmod":1315545120,"permalink":"https://blog.johtani.info/blog/2011/09/09/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-1%E6%97%A5%E7%9B%AE/","publishdate":"2011-09-09T14:12:00+09:00","summary":"実に3年ぶりくらいにゆっくりできる日々が訪れたので、積読状態の本を消化しようと「7つの言語 7つの世界」を読み始めました。 せっかくブログも始め","tags":["読書"],"title":"「7つの言語　7つの世界」 Ruby 1日目(Jugemより移植)"},{"contents":"現在の出先でMBAを使えないので、なかなか進んでいないMBAのセットアップです。。。\nとりあえず、Eclipse、homebrewをインストールしたので、lucene-gosenの開発やビルドには支障がない程度になってきました。（肝心のSolrがまだ動く状況になかった。。。）\nあとは、Windowsで使用頻度の高いソフトを列挙して、対応するMacのアプリを探そうかと。 まずは、Windowsでよく利用するソフトのリストアップ\nEclipse Cygwin TeraTerm WinSCP meadow サクラエディタ WinMerge PDF-XChange Viewer Evernote FreeMind VMWare こんなところかな。 a.～e.についてはMacOS特に問題なし。Eclipseは入れたし、その他は標準で入ってるものでまかなえると。 f.についてもEmacsで当面対応する予定。ただ、OmmWriter やCotEditorがおすすめらしいと聞いてます。 g.についてはFileMergeなるものがあるらしいので、試してみようかと。 h.は現状Adobe Readerです。ほかにいいのあるのかしら。PDF-XChange Viewerはちなみに、Solr入門を書くときに編集の方から教えてもらったPDFのビューワです。コメントとかハイライトできるのが便利でした。 i.はMacOS版をインストールして、すでに活用中。 j.については一時期活用していたのですが、最近利用していないです。なので、保留 k.についてはVirtualBoxをインストールしてみました。フリーだったので。WindowsではVMWareだったのですが。。。\nほんとにこれくらいで大丈夫かどうかはもう少し使ってみてからかなぁと。 その他におすすめ、これがあるとかなり便利などあれば、教えてもらえると助かります。 まだ、MacOSに触り始めたところなので、細かな部分のカスタマイズなどができていないので、その辺りもオイオイ考えていこうかと。\n※余談ですが、現在「７つの言語　７つの世界」を読み始めました。いろいろな言語の特徴について学べる本のようでかなり楽しく感じています。どうしてもJavaで仕事優先だとコーディングする速度優先でJavaばかり使ってしまうので。 いい頭の体操にもなりそうなのでオススメです。（といってもまだ、最初の言語Rubyなのですが。。。）\n","date":1315329480,"dir":"post/2011/","id":"f23ca2aa066b1ee0fa4df1f2f865be4c","lang":"ja","lastmod":1315329480,"permalink":"https://blog.johtani.info/blog/2011/09/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%93/","publishdate":"2011-09-07T02:18:00+09:00","summary":"現在の出先でMBAを使えないので、なかなか進んでいないMBAのセットアップです。。。 とりあえず、Eclipse、homebrewをインストー","tags":["備忘録"],"title":"MBAセットアップ備忘録その３(Jugemより移植)"},{"contents":"すぐにテストケース追加しますといいつつ、はや一週間。\nようやく仕事が落ち着いたので、テストケースを追記しました。まだパッチの段階です。 一応、異なる辞書の読み込みのテストケースなどを追加し、テストケース追加時点で いくつか気になったところもあったので、ついでに修正を加えました。 一応、辞書の分離＋複数辞書対応については現時点ではこんなところかと。\nあと、もう１項目対応してからtrunkに取り込む予定です。 対応する項目とは以下の項目です。\nカスタム辞書ビルドの簡易化 以前の記事にも書いていますが、カスタム辞書のビルドが思いのほか手間がかかります。 辞書の外部化は対応したのですが、せっかく辞書が外部化できたのですから、コマンド（ant？）で一発で カスタム辞書を含んだビルドをしたくなるのが人情です。 辞書なしのjarファイルもあることなので、すぐに対応可能かと。 ということで、今週中には対応する予定です（宣言しないとまた先延ばしになりそう）\n忘れてそうだったらTwitterやコメントでツッコミを入れてもらえると助かります。\n","date":1315328188,"dir":"post/2011/","id":"3c2523e65ff953fd73579aaaf5d7ce36","lang":"ja","lastmod":1315328188,"permalink":"https://blog.johtani.info/blog/2011/09/07/%E8%BE%9E%E6%9B%B8%E5%88%86%E9%9B%A2%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E3%82%B1%E3%83%BC%E3%82%B9%E8%BF%BD%E5%8A%A0%E3%81%A8%E6%AE%8B%E3%82%BF%E3%82%B9%E3%82%AF/","publishdate":"2011-09-07T01:56:28+09:00","summary":"すぐにテストケース追加しますといいつつ、はや一週間。 ようやく仕事が落ち着いたので、テストケースを追記しました。まだパッチの段階です。 一応、異","tags":["lucene-gosen"],"title":"辞書分離のテストケース追加と残タスク(Jugemより移植)"},{"contents":"先日、辞書のjarファイルからの分離についてパッチと記事を書きました。\nIssueにあげていたパッチをRobertさんが見ていたらしく、次のようなコメントをもらいました。\nMaybe if we change SenFactory.getInstance to use a ConcurrentHashMap then you can easily use multiple dictionaries at the same time? 「SenFactory.getInstanceメソッドでConcurrentHashMap使ったら複数辞書対応できるんじゃない？」（訳） たしかに。。。なんで思いつかなかったのだろう。。。\nということで、実装してみました。 パッチはこちら。\n使い方ですが、先日の記事と代わりはありません。 ただし、あった制限事項が次のようになります。\nマルチコアの設定でsharedLibにlucene-gosenのjarを含まない 同一コア内で異なるdictinaryDirの指定はできない ソースの変更点ですが、ものすごく単純です。 dictionaryDirに指定された文字列をキー、その辞書ディレクトリを利用したSenFactoryのインスタンスを値に持つmapをSenFactory内に保持します。あとは、SenFactoryのgetInstance(String dictionaryDir)メソッドで取得する際にmapに対応するインスタンスがあれば、そのインスタンスをなければ、dictionaryDirから辞書を読み込んでインスタンス生成してmapにキャッシュしつつ返すという実装に変えただけです。 ということで、次のようなIPADICとNAIST-JDIC for ChaSenを同時に使う設定も可能となります。\n\u0026lt;fieldType name=\u0026#34;text_ja_ipadic\u0026#34; class=\u0026#34;solr.TextField\u0026#34; positionIncrementGap=\u0026#34;100\u0026#34;\u0026amp;gt; \u0026lt;analyzer\u0026amp;gt; \u0026lt;tokenizer class=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; dictionaryDir=\u0026#34;/tmp/lucene-gosen/dictionary/ipadic\u0026#34;/\u0026amp;gt; \u0026lt;/analyzer\u0026amp;gt; \u0026lt;/fieldType\u0026amp;gt; \u0026lt;fieldType name=\u0026#34;text_ja_naist_chasen\u0026#34; class=\u0026#34;solr.TextField\u0026#34; positionIncrementGap=\u0026#34;100\u0026#34;\u0026amp;gt; \u0026lt;analyzer\u0026amp;gt; \u0026lt;tokenizer class=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; dictionaryDir=\u0026#34;/tmp/lucene-gosen/dictionary/naist-chasen\u0026#34;/\u0026amp;gt; \u0026lt;/analyzer\u0026amp;gt; \u0026lt;/fieldType\u0026amp;gt; あと、注意事項です。 普通に考えるとわかることですが、辞書を複数読み込めるようになったことで、読み込んだ複数の辞書をメモリに保持することになります。ですので、今までよりも多くのメモリを利用するので、Heapのサイズには注意が必要です。 例のごとく（ほんとよくない。。。）テストコードを書いていない状態のパッチをまずはアップしました。 テスト書かないと。。。次回はテストコードかきましたと言う報告をしたいな\nあと、Robertさんのコメントの前に@shinobu_aokiさんからJapaneseTokenizerFactoryの設定では辞書のディレクトリを$SOLR_HOME/confからの相対パスで記述できるというパッチもいただいています。 この部分については先日と使い方が異なります。 （すみません、まだきちんとソースを見れてないです。。。）\n","date":1314668040,"dir":"post/2011/","id":"88a8e608108be939da9aab5a9a8af7d1","lang":"ja","lastmod":1314668040,"permalink":"https://blog.johtani.info/blog/2011/08/30/%E8%A4%87%E6%95%B0%E8%BE%9E%E6%9B%B8%E3%81%AE%E8%AA%AD%E3%81%BF%E8%BE%BC%E3%81%BF%E6%A9%9F%E8%83%BD%E8%BF%BD%E5%8A%A0%E4%BB%AE/","publishdate":"2011-08-30T10:34:00+09:00","summary":"先日、辞書のjarファイルからの分離についてパッチと記事を書きました。 IssueにあげていたパッチをRobertさんが見ていたらしく、次のよ","tags":["lucene-gosen"],"title":"複数辞書の読み込み機能追加（仮）(Jugemより移植)"},{"contents":"ひさびさに、lucene-gosenの話題です。\nlucene-gosenはjarファイルに辞書も同梱されており、jarファイルをクラスパスに取り込むだけで、 簡単に形態素解析器が利用できるといお手軽さがあり、便利です。\nですが、以前カスタム辞書の登録について記事を書いたように、カスタム辞書の登録は思いのほか手間がかかります。 lucene-gosenのソースをダウンロードし、lucene-gosenを一度コンパイルし、カスタム辞書のcsvファイルを作成し、カスタム辞書を取り込んだ辞書のバイナリを生成し、最後にjarファイルにするという作業です。（書くだけでいやになってきました。。。）さらに作成したjarファイルをSolrや各プログラムに再度配布するという具合です。\nそこで、辞書ファイルの外部化ができないかという話があがっていました。 すこし時間ができたので、山積みになっているissueを横目に軽く実装をしてpatchをissueにアップしました。\n機能としてはごく簡単で、JapaneseTokenizerのコンストラクタに辞書のディレクトリ（*.senファイルのあるディレクトリ）を指定可能にしただけです。 また、JapaneseTokenizerFactoryでもdictionaryDir属性で指定可能になっています。 まずは、コンパイルの方法から。 trunkをSVNでcheckoutし、issueにあるpatchをダウンロードして適用します。（svnのチェックアウトについてはこちらを参考にしてください。）\n$ cd lucene-gosen-trunk $ patch -p0 --dry-run \u0026lt; lucene-gosen-separate-dictionary.patch $ patch -p0 \u0026lt; lucene-gosen-separate-dictionary.patch 次に、antを実行し辞書なし版のjarファイルをビルドします。\n$ ant nodic-jar これで、dictディレクトリに「lucene-gosen-1.2-dev.jar」というjarファイルが出来上がります。 （※ただし、これだけでは動作しないので、別途辞書のコンパイルは必要です。）\n次に、指定の仕方です。JapaneseTokenizerのコンストラクタは第3引数に辞書のディレクトリ（フルパスor実行ディレクトリからの相対パス）を渡すだけです。\nTokenizer tokenizer = new JapaneseTokenizer(reader, compositeTokenFilter, dictionaryDir); 最後に、Solrのtokenizerタグでの指定方法です。\n\u0026lt;fieldType name=\u0026#34;text_ja\u0026#34; class=\u0026#34;solr.TextField\u0026#34; positionIncrementGap=\u0026#34;100\u0026#34;\u0026amp;gt; \u0026lt;analyzer\u0026amp;gt; \u0026lt;tokenizer class=\u0026#34;solr.JapaneseTokenizerFactory\u0026#34; dictionaryDir=\u0026#34;/hoge/dictionarydir\u0026#34;/\u0026amp;gt; \u0026lt;/analyzer\u0026amp;gt; \u0026lt;/fieldType\u0026amp;gt; 以上が、簡単な設定の仕方です。なお、辞書を内包したjarファイルでもdictionaryDirは利用可能です。優先度としては、dictionaryDirが指定されている場合はdictionaryDirを探索しファイルがなければRuntimeExceptionです。指定がnullもしくは空文字の場合はjarファイルの辞書の読み込みを行います。\n次に利用シーン、制限事項についてです。 利用シーンとしてはカスタム辞書を定期的にメンテナンス（追加更新）しながらSolrを運用するというのが想定されます。定期的に辞書の再読み込みをしたい場合です。 利用方法は次のようになります。\nSolrのマルチコア構成を利用する 各コアごとにlib/lucene-gosen-1.2-dev.jarを用意 辞書の更新が終わったらコアのRELOADを実施 コアをリロードすることで、lucene-gosenが辞書を再読み込みようになります。（現状でも再読み込みするが、jarファイルを再配置しないといけない。）あとは、定期的に辞書ファイルを更新、再構築しコアをリロードすれば、 リロード後に新しい辞書が利用できるという具合です。 （もちろん、辞書更新後に入った単語は辞書更新以前に作成したインデックスにはでてこないですが。。。） また、コアごとにdictinaryDirを別々に指定することも可能です。\n制限事項は次のようになります。\nマルチコアの設定でsharedLibにlucene-gosenのjarを含まない 同一コア内で異なるdictinaryDirの指定はできない 以上が、辞書の外部ファイル化のパッチについてでした。 少しテストケースを追加したら、trunkにコミットする予定です。興味があれば、パッチを利用してみてください。\nSyntaxHighlighterの導入をしないとソースコードが見にくいですね。。。導入を検討しないと。。。どこかにWebサーバ用意しないとダメかも\n","date":1314062760,"dir":"post/2011/","id":"2f1ec795216d5bafa33a810af3421942","lang":"ja","lastmod":1314062760,"permalink":"https://blog.johtani.info/blog/2011/08/23/%E8%BE%9E%E6%9B%B8%E3%81%AEjar%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%8B%E3%82%89%E3%81%AE%E5%88%86%E9%9B%A2/","publishdate":"2011-08-23T10:26:00+09:00","summary":"ひさびさに、lucene-gosenの話題です。 lucene-gosenはjarファイルに辞書も同梱されており、jarファイルをクラスパスに","tags":["lucene-gosen"],"title":"辞書のjarファイルからの分離(Jugemより移植)"},{"contents":"すみません、また、MBA関連の記事になってしまいました。 ということで、備忘録その２です。\n前回からいくつかインストールや環境の設定をしたので、リストアップ。\nVirtualBoxとWindowsのインストール homebrewのインストール KeyRemap4MacBookのインストール Growlのインストール Time Machine用HDDの購入と設定 VirtualBoxのインストールとWindowsXPのセットアップ。会社関連でどうしてもWindowsが必要なので、 とりあえず、VirtualBoxとWIndowsを入れました。これまでのWindows環境ではVMWareを利用してたのですが、 Macだと有償ということで、無償版が存在するVirtualBoxを選択。 MBAにはDVDのドライブがなく、また、ケチって購入しなかったので、ちょっと手間取りました。 自宅のデスクトップでXPのイメージをisoにして、MBAにコピーしてからインストールと。。。 ただ、MBAのSSDの効果なのか、XPの起動がすごく速くてびっくりです。\nhomebrewのインストールは、まだインストールしただけの状態。。。 MacPortsってのがあるというのは知っていたのですが、最近はこちらがいいとのこと。 ちなみに、MacPortsにはSolrがあるらしいです。デフォルトのため、lucene-gosenとか入れる必要がありますが。\nKeyRemap4MacBookのインストール。入れた方がいいですよと言われてたのだが、きちんと調査してなく、 キーの入れ替えができる程度だと思ってました。昨日、EmacsModeなるものが存在するというのをKeyRemap4MacBookのドキュメントを読んでいて発見し即インストール。 とりあえず、Ctrl-x,Ctrl-cでEvernoteが終了できて喜んでるところです。\nGrowlのインストール。KeyRemap4MacBookのCtrl-xを通知してくれます。ほかにも使い方があるかは調査が必要。\nあとは、昨日、ビックカメラでWDの2TBのHDDを購入してTimeMachineの設定をしてバックアップをとりました。 まだバックアップをとっただけで、差分を見たりはしていないです。帰ってからやってみようかと。\n最後に、ケースを買いました。封筒とかいろいろ考えたのですが、やはり機能重視ということで、以下のケースです。 できれば、ファスナーが２つついていて、両方からあけられるとよかったのですが。リュックとショルダーバッグを使い分けるので、横でも縦でも取り出しが楽なものがよかったので、このケースを買いました。 一応、がんばれば縦でも出せるので。あとは、PCだけもって移動することもあるため、取っ手があるのが便利かと。\nとまぁ、お盆なので、このエントリーで許してください。次回は技術的なことを書きますので。。。 CaseLogic 機能的なモバイルコンピュータケース(13~14.1インチPC対応)、MacBookやMacBook Proにも対応 ダークグレー UNS-114J-DG ","date":1313369460,"dir":"post/2011/","id":"ce0aea06d44878b4a373efe090a66a62","lang":"ja","lastmod":1313369460,"permalink":"https://blog.johtani.info/blog/2011/08/15/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%92/","publishdate":"2011-08-15T09:51:00+09:00","summary":"すみません、また、MBA関連の記事になってしまいました。 ということで、備忘録その２です。 前回からいくつかインストールや環境の設定をしたので、","tags":["備忘録"],"title":"MBAセットアップ備忘録その２(Jugemより移植)"},{"contents":"Mac Book Airのセットアップ関連の備忘録\n（今回は備忘録なので、文体も変かも）\nインストールしたもの（順不同）だいたい、このサイトを参考にした。\nEvernote Dropbox XCode Twitter YoruFukurou GNU Emacs For Mac OS X Java Office for mac 現状はこんなところ。\nまだ、キーボードの配列とショートカット、ウィンドウの切り替えなどがすぐにできないので、かなりおぼつかない状態。\nCtrl+aなどの操作は快適なのだが、ウインドウを閉じたりする場合のcommandキーの扱いがまだなれない。キー配置を切り替えたりした方がいいのか悩み中。 Windowsでは長年XKeymacsを使ってきたため、通常のOfficeなどもCtrl+x　Ctrl+sなどで閉じていたので、command＋qなどがすんなり出てこない。。。\nあとは、VirtualBoxにWindowsを入れて、Eclipseを入れればなんとか、WindowsPCからMBAへの切り替えができそう。\n残っている課題は以下の通り。\nTime Machine環境の整備USB接続のHDDの導入（ミラーリング対応にするか悩み中）※ちなみにうちで使ってるNASは古い＋NFSマウントできない機種だった。。。　対応可能だったらScientific Linux＋Netatalk環境などを用意するのも考えたんだが。 homebrewのインストール 日本語入力（GoogleIME？SKK？） ウォークマン、Xperia arcの運用方法まぁ、今まで使ってたPCで対応かな キーの配置Emacsのショートカットに変更できたりするか調査したい データの移行Windowsに入ってるデータのうち移行するものしないものの選別Macでは利用できないデータやファイルもあると思う。 解凍ツールの選別？いるのかな？ ブラウザのインストールchrome、Firefoxはいれるかな。 メーラーのインストールWindwosではBecky!を使ってたのだが、どうするか。デフォルトメーラで様子見？ ウイルス対策ソフトの導入Macってどんなソフトがあるかがわからない。。。 あと、１週間触っての感想\nまずは、良かった点。\nいろんなUIがよくできてるセットアップなどきれいな画面で説明が進むのが新鮮だった。あと、フォントのきれいさも新鮮。これは、今までのPCが古いからかもしれないが。 トラックパッドがいいまだなれてないけど、スイスイ動くのでストレスなく作業できる。スワイプとかも画面の移動が楽でいい。 静かで速いSSDのため、静かだし起動がすごく速い。会社で支給されてるPCもSSD（３年くらい前のもの）だけど、こんなに起動などがはやくない。 あとは、気になった点。\nAppStoreでページ間のスワイプができない。かなり使いづらい。Safariと同じイメージでいるので。 手首がいたい手前のエッジ部分が手首に当たってちょっといたい。 アプリインストール時にファンがうるさい動画などはまだ見てないが、Office、XCodeのインストール時にファンの排気音がうるさくなり、結構な熱を発していた ファーストインプレッションはこんな感じ。\nただ、前回も書いたようにうらやましかったのもあり、かなり満足している。 もっと触る時間が欲しいのだが、なかなかとれないのが歯がゆい。。。\n持ち歩くようになったらとりあえず、「７つの言語　７つの世界」を読み進め＋写経をやる予定。\n","date":1312904760,"dir":"post/2011/","id":"c0e423f9ac41cc5b265c95a3e97e3fcb","lang":"ja","lastmod":1312904760,"permalink":"https://blog.johtani.info/blog/2011/08/10/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2/","publishdate":"2011-08-10T00:46:00+09:00","summary":"Mac Book Airのセットアップ関連の備忘録 （今回は備忘録なので、文体も変かも） インストールしたもの（順不同）だいたい、このサイトを参考にした。 Evernote Dropbox","tags":["備忘録"],"title":"MBAセットアップ備忘録(Jugemより移植)"},{"contents":"個人用のPCを８年ぶりに新調しました。\n前回購入した家のデスクトップPCがもう８年ものになりつつあるということで、\nさすがに今年はPCを買おうと思い、年初からいろいろと調べていました。\n当初は次もデスクトップPCを購入する予定でした。ただ、次のような状況ということもあり\nデスクトップは見送ることにし、代わりにノートPCにすることに。\n通勤時間が１時間を超えること\n基本、客先に出向いての仕事\n家でPCに触る時間が少ない（家族サービスのため。）\nで、ここ数週間悩んでいたのですが、Mac Book Air 13インチを購入しました。（そのMBAから初投稿です。）\n実は、Apple製品はこれが初の購入となります。\n対抗馬としてあがっていたのはSonyのVAIO Type Zでした。\n元々ソニスト（ソニー大好き）であり、携帯（Xperia arc）、ウォークマン（Sony）、PSP go、ハンディカムなど、\nソニー製品に囲まれており、デザインもType Zのほうが好みなのですが、MBAを購入しました。\nこの理由なのですが、私が大学時代にさかのぼります。\n情報系の大学の出身で、はじめてきちんと触ったマシンがSunOS4.1（最後の数年はSolaris2.6）でした。\nその後、大学６年間は基本的にEmacsでメールをみて、Emacsで文章を書いていました。\nそのため、社会人になってからもEmacsのキーバインドから抜け出せない日々を送っていました。\n社会人ではやはりWindowsでしたが、XKeymacsというフリーソフトのおかげ（せい？）でEmacsの\nショートカットからは抜け出せないまま。（家のPCはXPで、XKeymacsがインストールされてます。）\n今までの流れだと、何も考えずにWindows7+XKeymacsの流れだったのですが。。。\n職場でWindows7のPCを使う機会があり、XKeymacsを入れてみたのですが、これまでとことなり、\nうまく機能しないことこの上なし（例：chromeのアドレスバーでCtrl+Kとかできないなど）。\nさらに、64bit版の場合、XKeymacsを32bit、64bitの２つインストールしないといけないことに。（32bit用アプリのために32bitを入れないといけない）\nで、数ヶ月使っているのですが、ちょっとずつストレスがたまっている始末。。。\n今までは、「Mac？今更恥ずかしくてかえない」「Mac？おしゃれすぎて無理」「Apple？MSにかわって独占してるの気に食わん」と公言していたのですが。。。\nやはりUnixベースであり、Ctrl+aやCtrl+kが意識せずに利用できるということでコーディングなどを行う場合のストレスよりも保守的な思考を変える方が今後のためにも良さそうだということで、心機一転MBAを購入しました。\nということで、ついにApple教へ入信です。\nまだ、１時間も触ってないですが、すでに洗脳されつつあります。。。\n新しいものに触れるのって楽しいですよね。当分は何をインストールするかなど楽しい悩みでいっぱいになれそうです。（次回はちゃんとした技術的な記事書きたいと、書けるかな、書くぞ、たぶん。。。）\nとまぁ、いろいろと理由を書いてみましたが、要は（オシャレさに）憧れてて、あまのじゃくになって思ってもないこと言ってたんです！\n理由が欲しかったんです！！\nMacかっこえーわーw\nMac miniとかiMacとかもほしーわー\n","date":1312389240,"dir":"post/2011/","id":"7ed1d2efa3e0f0ed6b77eb4eff3d86b3","lang":"ja","lastmod":1312389240,"permalink":"https://blog.johtani.info/blog/2011/08/04/apple%E6%95%99%E3%81%AB%E5%85%A5%E4%BF%A1%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-08-04T01:34:00+09:00","summary":"個人用のPCを８年ぶりに新調しました。 前回購入した家のデスクトップPCがもう８年ものになりつつあるということで、 さすがに今年はPCを買おうと","tags":["備忘録"],"title":"Apple教に入信しました(Jugemより移植)"},{"contents":"かなり遅くなりましたが、第1回 データ構造と情報検索と言語処理勉強会 #DSIRNLPに参加しました。\n帰ってから２日半ほど寝込んでしまい、更新が遅れました。。。\n初の土曜日開催の勉強会でしたが、家族を説得してなんとか参加しました。\nおかげで色々と面白そうなキーワードが拾えてよかったです。（拾っただけで理解するのはかなり時間がかかりそうですが。。。）\nということで、前回同様、個人的にメモを取ったので。誤記などあるかもしれませんが、その時はコメントいただければと。\n0.DSIRNLPについて\n※ボランティアで受付してたので聞けず。\n1.TRIEにトライ！～今日からはじめるTRIE入門～\n@echizen_tm さん\n資料：http://www.scribd.com/doc/58688141/Try-for-Trie\n1.TRIEの説明\n実装についてはあとでスライドをみればいいか。（※ボランティアで受付してたので前半聞けず）\n・パトリシア木\n・Double Array\n・LOUDS\n・XBW\n2.作ってみた\nその1　ベーシック\nQ.ノードのラベルどーする？\n・固定長（ラベル＝1文字）\n定数時間でアクセス可能\n・可変長（ラベル＝任意文字列）\nPatricia木に拡張可能\nA.拡張性を考えて可変長に！\n3.LOUDSとは？\n概要\nJacobsonが提案　Level-Order Unary Degree Sequenceの略（いつからLOUDSになったのか不明）\n構築済みTRIEからLOUDSを構築\n作業領域がO(NlogN)からO(N)に\n・ノードに幅優先で順番（Level-Order）をつける\n・子ノードの数を付ける。Unary符号で実装\n作ってみた\n・UnaryよりVerticalCodeのほうがよさそう\nhttp://d.hatena.ne.jp/echizen_tm/20100531/1275323074\n・dag_vectorを使ってもいいかもよ？\n4.QA\nQ.可変長を配列にすればいいんじゃね？\nA.単純にやると効率悪そう？\n※LOUDSをlucene-gosenに適用するとなんか嬉しいことあるかな？\n現状はDouble-Arrayだけど。\n2. ランキング学習ことはじめ（Solr系に利用できそうな予感。。。ごごご。。。むずかしい。。。）\n@sleepy_yoshi さん NTTのSuharaさん「話がうまい」\n数原　良彦\n自己紹介\n情報検索、ランキング学習をやってる。\n三浦半島在住\nねらい\nランキング学習の認知度を高める、ざっくり伝える。　ごめんなさい　「実装」についてをわすれてた。\n・ランキング学習とは？\nLearning to rank\npreference learningとは違う\n教師あり機械学習で検索ランキングに適用\n・歴史\n従来は単一ランキング\nクエリ・文書関連度（TF-IDF、BM25）\n文書の重要度（PageRank、HITS、SALSAなど）\n近代的なランキングの実装方法\n上記データを利用して関数を適用する。\n・何を正解とするのか？\n適合性評価の作成方法\n評価点数を多段階で点数化\nランキング評価方法\nランキングを正解データと比較\nNDCG（Normalized Discounted Cumulative Gain）　※分類問題におけるモデルの生成\nTraining Data＋学習アルゴリズム＝＞モデル\nランキング学習の訓練データ\n素性や評価はクエリごとに変わってくるTraining data（ここが違う）\nここまでのまとめ\n正解データは適合度至上主義！\nランキング学習手法\n３つのアプローチ\n教師あり機械学習（識別学習）≒\nどのような目的関数/損失関数を\nどのように最適化するのか\nアプローチ\n1.Pointwise手法\n単一のデータに対して損失関数を設定\n2.Pairwise手法\n同一クエリのペアに対して損失関数を設定\n3.Listwise手法\n同一クエリのリストに対して損失関数を設定\nPointwise：あまりつかえない。\n例：二値分類（適合＋１不適合－１）で学習\n補足：Perceptron\n例：PRank\nしきい値と重み両方修正する。\nPairwise：Pointwiseよりいいらしい\n文書ペアで損失を設定\nMQ2007、MQ2008データセットの結果\nPairwise手法とListwise手法を比較しても\nそんなに悪くないらしい\nIR-SVMってので偏りなどを排除できて、精度向上になるよ\nNLP2011でPARankっての発表したよ（手前味噌）\nQA\nQ.じゃんけんみたいに循環しない？（nokuno）\nA.半順序のデータだと起きるが、検索の場合は全順序なので大丈夫だよ\nListwise：Pairwiseよりいいらしい\nListNetってのあり。\nAdaRank\n検索評価指標を直接最適化するブースティング手法\n性能はいまいち？実装は簡単\nその他の話題\nClick-through logs\nQuery-dependent ranking\nFeature selection\nTransfer learning/Domain adaptation\nDiversity/Novelty\n公開Dataset\nLETOR3.0/4.0 Dataset\nMSLR-WEB Datasetなど\n実装\nRankingSVM\nStoch\u0026hellip;.\nLearning to Rank教科書\n英語の資料が今年複数出たみたい\nまとめ\n近代的な検索エンジンは多数のランキング素性を利用\n評価データを用いてランキング素性の最適な重み付けを求める方法\n。。。\n機械学習手法は論文≒実装\nなので、ソースコード見るほうが重要（論文にないノウハウがあるよ）\n3.snappy調べてみた\n@machy　町永圭吾（赤いポータルサイト）\nTopCoderなどで活躍中？\n・snappyは圧縮/伸張ライブラリ\nzlibよりサイズが大きいけど一桁はやいですぞ。\n・インストールなど\ngoogle－gflagsってのがないと動作しないよ。\n・比較してみた（zlib）\n一桁は言い過ぎだけど、はやかった。\n・比較してみた（lzo）\nHadoopで利用されているlzo\nはやかった。\n・仕組みは？\nzlib　辞書式符号化＋ハフマン符号化＝出力\nsnappy　辞書式符号化＋リテラル＝出力\n・辞書式符号化は？\n前に出てきたデータで同じ文字列の部分について端折る\n・ハフマン符号化\nよく出てくる記号を短い符号で置き換えることで圧縮する。\n・snappyの符号化\n基本バイト単位での処理にすることで、高速化してるみたい。\n・snappyの辞書参照元の探し方\nハッシュテーブル利用してマッチする位置を検索\n4byte窓でハッシュ値を計算してハッシュテーブルを更新\n・圧縮しにくいデータ（同じ単語が出てこないパターン）について\n圧縮をあきらめ始める（32回同じのが見つからないと窓の移動幅が1つずつ大きくなる）\n16KB（フラグメント内）での比較回数が1008回に抑えられる。\n・特徴\nハッシュがしょうと移したらあるはずのマッチが見つからないこともある。\nメモリ消費量を抑えるためのハッシュのサイズ？\n最悪ケースのサイズを予め確保してから処理するため、メモリの再確保が起きないのではやいぞ。\n4.類似文字列検索してますか？\n@overlast さん　Yな会社\n1.曖昧な情報を処理する能力\n曖昧な情報を解決しようとする能力が高い。\n例：お笑い芸人の芸がサンプルｗ\n画像検索は曖昧クエリに答える例。。。\nスターバックス、スタバ、SUTABA\nスータバでも画像が出てきた。-\u0026gt;女子高生とかが「スータバ」で画像をアップしてたりするから。\n文字列を使った検索は現代のインフラになってるよね。\n例：iタウンページ\nタイトルとかに「スターバックスコーヒー」って書いてないとだめ。？\n「スタバ」800件くらい　-\u0026gt;　正規化で「ー」消してるんじゃないの？\n「スータバックスコーヒー」0件　ちがうな。シノニム辞書登録してるな。\n曖昧なクエリ（キーワード）から検索できないかなぁ？\n曖昧情報の処理は文字列処理にこそ必要\nなんでヒットしたかがわかるのが正解　なんでヒットしたかわからないけど、ちゃんと出てきたから正解！\n2.ゼロ件ヒット問題（ゼロマッチ）\nピクシブ百科事典\n「ピングドラム」だと17件\n「ピンクドラム」だと0件　しかも真っ白！！\n使いにくいよね。けど、一般的な検索システムの問題だよね。\nGoogleだと出てくる「ピンクドラム」の結果の最初にはピングドラムが出てくる。\n-\u0026gt;リンクがはられているから出てきた？みんなの間違いで助けられてる\n食べログ\n「俺のハンバーグ」\n「俺はハンバーグ」で検索したら。。。「俺はハンバーグで連れは。。。」がヒット-\u0026gt;しらねーよｗ\nまとめ\nゼロ件ヒットは機会損失！！\n3.曖昧な文字列で正しい文字列を探す方法\n正しい文字列って？\n1.表記誤りがない\n2.心の底で求めている\n※異表記同義、同表記異義、異言語表記（日本語の情報を英語で検索）などもある\n正しさはユーザによって変わる。\n正しい文字列をさがす手法\nクエリ表記の正誤という軸\n誤の場合表記をヒントに似た文字列を検索してみる。\n探したい対象が正確か曖昧か\n表記意外がヒントで同じ対象に到達できる？\nどんな情報を手がかりにする？\n編集距離（レーベンシュタイン）\n検索ログ\n4.Apporoの紹介\nチョコ？いや、ロケット？いや、Approximate \u0026hellip;\nhttp://code.google.com/p/apporo/\n中小規模だと使えそう\nSimString\n今後\nよみかな、ローマ字表記に基づく類似文字列検索＋高速化の予定\n技術概要\nSuffix Array\nN-gram Searchベースの近似文字列照合\nBit Parallel Matchingによる編集距離計算\n5.検索と言語と文化（仮）\n@mizuno_takaaki さん\n放送禁止のためメモなし。\n7.自然言語処理におけるargmax操作\n@hitoshi_ni さん\n※順番変更\n・近似解法\nその１　全探索\nいや、無理でしょ、計算が。\nその２　貪欲法\n最適解が出るかは不明。\nその３　ビームサーチ\n上位kこの仮説を保持しながら幅優先探索\n・動的計画法\nすでに最大値がわかっていて、ゴールから眺めてみる。\n逆からたどるとルートがわかるんじゃないか。\nマルコフ性につけ込むことで、わかるんじゃないか。\n計算量：品詞数の2乗\n（品詞数の2乗）＊形態素数\nDPの実装\nViterbiかなぁ？\n・整数計画法（線形-\u0026gt;整数）\n自然言語処理としては整数計画法でだいたいOK。\nアルゴリズム\n・手元の解空間中から許容解を得る\n・分枝してそこから最大値を求める\n最大値＞許容解ならそちらを探索。\nプログラム実装する？\nすごく大変じゃないけど簡単でもないね。\n問題の弱点がわかってるなら実装してもいいよね。\n整数計画法の場合lp_solveなどのフリーのソフトで解くのがいいよ。エクセルでも解けるよ\nILP（整数計画法？）\n問題の切り分けに使える。\nまとめ\nILPで解けたら、いろいろ自分で考えると面白いよ。\nその他のバズワード\n参考資料\n組み合わせ最適化＝1万円超\nアリ本\n6.ソーシャルグラフ分析(導入編)\n@kimuras さん　mixiの木村さん\n・グラフ探索部分はまた今度。\n・テキストマイニングや検索エンジンまわりやってる。\n・ノードが数1千万、エッジが数億のオーダー\n・分散技術の発展によるアルゴリズムの多様化\nこれまで\nRDBからDumpしたデータをKVSに入れて頑張ってた。\nDump部分でデータ構造を毎回構築\n問題点\n変更による再実装、メンテナンスコスト、\nこれから\ngraphDBに取組中。マイニングに最適な感じ\ngraphDBの実装\nOrientDB、Neo4jとか\nNeo4jって\nACIDトランザクション可能\nEmbeddedGraphDatabaseだとAGPLｖ３だから気をつけてね。\nluceneで全文検索インデックスつくってるみたい。\nGremlinってのがquery言語を汎化してるらし。\nとあるSNSのデータを使ってみたよ。\nメモリ64G、CPUは1コアしか使えなかったよ。\nノード：15million、枝：600million\nまとめ\nということで、色々と面白い話が聞けました。特にTRIEの話はかなり興味を持ちました。\n検索周りで嫌というほど出てくるので。まだまだきちんと理解できてないので復習しないと。。。\nlucene-gosenにも関係あるので、しっかり資料をみて復習する予定です。\n基本的に検索系の話に関連があることが多くて面白く聞くことができました。\n「類似文字列検索してますか？」や「ランキング学習ことはじめ」などは身近な話（だけど、なかなかきちんと学習できてない話）でした。\nまた、「自然言語処理におけるargmax操作」では大学でやっていた線形計画法などのわかりやすい説明で10年経ってようやく理解ができた次第です。。。（もっとちゃんと勉強しとけば。。。）\n懇親会にも参加し、研究に近い分野の方が多い中でいろいろな話が聞けたのはよかったと思います。\n次回もいろいろなキーワードを拾いたいのでぜひ参加したいです。\n","date":1311737580,"dir":"post/2011/","id":"3811b40721f7ca651887aac4eb17f9f0","lang":"ja","lastmod":1311737580,"permalink":"https://blog.johtani.info/blog/2011/07/27/%E7%AC%AC1%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-07-27T12:33:00+09:00","summary":"かなり遅くなりましたが、第1回 データ構造と情報検索と言語処理勉強会 #DSIRNLPに参加しました。 帰ってから２日半ほど寝込んでしまい、更新が","tags":["勉強会"],"title":"第1回 データ構造と情報検索と言語処理勉強会に参加しました。(Jugemより移植)"},{"contents":"以前から春山さんのブログ（リンク）や勉強会で耳にはしていたのですがソースは読んでいませんでした。 先日、Luceneにcontributeされた（リンク）ので軽くソースを読んでみました。\n公式サイトはこちら\nまずはMeCabのページにある比較表（リンク）を基準に特徴を調べてみました。せっかくなので、lucene-gosenも隣に。\n\u0026nbsp; Kuromoji lucene-gosen 解析モデル なし（学習機能なし） なし（学習機能なし） コスト推定 なし（学習機能なし） なし（学習機能なし） 学習モデル なし（学習機能なし） なし（学習機能なし） 辞書引きアルゴリズム Double Array Trie Double Array Trie 解探索アルゴリズム Viterbi Viterbi 連接表の実装 2次元 Table 3次元 Table 品詞の階層 無制限多階層品詞？ipadic、unidic形式に対応 無制限多階層品詞 未知語処理 字種 (動作定義を変更可能)（おそらく。） 字種（変更不可能） 制約つき解析 たぶん、不可？ たぶん、不可？ N-best解 不可能 不可能 こうやって比較してみるとlucene-gosen（Sen）とあまりかわりはありませんが、lucene-gosenが少し古いのがわかりますね。。。\nKuromojiで利用出来る辞書は現時点ではMeCab IPADIC、UNIDICの2種類のようです。\nソースを読んでの感想ですが、やはりMeCabが偉大だということがよくわかりました。 Senよりも新しいMeCabの処理に似ている点が多いです。解探索アルゴリズムや連接コスト表が特に。 MeCab向けの辞書を利用しているためというのもあるかと思います。\nKuromojiが特徴的なのは「searchモード」と呼ばれるモードが用意されていることです。 公式サイトにある例ですと、「関西国際空港」が「関西」「国際」「空港」というTokenで出力されます。 ソースを見たところViterbiアルゴリズムで辞書を探索しているときに特定の条件でコストをカサ増しすることで、結果を変えるという処理を行っているようです。\n全て漢字の単語：3文字以上の場合に「(単語の長さ-3)*10000」をコストに加算 その他の単語：7文字以上の場合に「(単語の長さ-7)*10000」をコストに加算 このようにコストを変化させることで「空港」でも「関西国際空港」という文字を含む文章が検索できる仕組みになっています。 また、「拡張searchモード」と呼ばれるモードも存在し、こちらは、未知語をuni-gramで区切って出力を行うようです。\nソース上で確認しただけで、未確認ですが、GraphvizFormatterというクラスがあるので、Graphvizで読み込める形式で形態素解析の結果が出力されるかもしれません。（すみません、確認してなくて。）\n未知語の処理やsearchモードなど面白い機能があるので、試してみるのもいいかもしれません。lucene-gosenを考えていく上でも参考になりそうです。\n最後に余談ですが、FAQのページ（リンク）が面白いです。。。\n","date":1311132540,"dir":"post/2011/","id":"5a765f9668608a39333fa90cf462657e","lang":"ja","lastmod":1311132540,"permalink":"https://blog.johtani.info/blog/2011/07/20/kuromoji%E3%82%92%E8%AA%BF%E3%81%B9%E3%81%A6%E3%81%BF%E3%81%9F/","publishdate":"2011-07-20T12:29:00+09:00","summary":"以前から春山さんのブログ（リンク）や勉強会で耳にはしていたのですがソースは読んでいませんでした。 先日、Luceneにcontributeされ","tags":["形態素解析"],"title":"Kuromojiを調べてみた(Jugemより移植)"},{"contents":"忘れてしまうので、備忘録を残しておきます。 一応、ソースには少しずつコメントをいれてはいるのですが。 私は残念ながら、自然言語処理は初心者に毛が生えた程度（現在、鋭意勉強中）で、対応方法に問題があるかもしれません。気づいた方はコメントをいただけると助かります。\n辞書ファイルについて NAIST-JDic for MeCabの辞書ファイルは以下の構成になっています。\nファイル名 メモ char.def 文字種の設定 feature.def 辞書学習用の設定？ left-id.def左文脈IDのマスタ（左文脈ID、品詞情報） matrix.def 連接コスト表（前件文脈ID,後件文脈ID,連接コスト） pos-id.def 品詞IDのマスタ（品詞情報、ID） rewrite.def rewrite情報（左右文脈に出現した場合のそれぞれの品詞情報のrewriteルール。辞書学習で主に利用） right-id.def 右文脈IDのマスタ（右文脈ID、品詞情報） unk.def 未知語の品詞情報（文字種ごとに未知語のコスト、左右文脈ID、品詞情報が記載されている） naist-jdic.csv 単語辞書（単語、左右文脈ID、単語コスト、品詞情報、読みなど記載） 現時点では、MeCabDicPreprocessorでは以下のファイルを利用しています。\nleft-id.def matrix.def right-id.def naist-jdic.csv 上記以外のファイルは現時点では利用しない実装になっています。 ただし、rewrite.def、unk.def、char.defについては利用したほうがよりMeCabに近い結果が得られるような気がしています。（特に文字種ごとのコストを利用することは有効と思われます。）\nPreprocessorでの処理について lucene-gosenはSenの後継であり、MeCabの昔のバージョンを移植したものがベースとなっています。 lucene-gosenとMeCabの現時点での実装の大きな違いとして、連接コスト表の違いがあります。 ここからは憶測になってしまいますので、注意してください。（論文を探せばどこかにこの実装の変化の過程が記載してあるかもしれないですが、まだ探していません、すみません。） 過去のMeCabではChaSen向けの辞書を利用していました。 ChaSenでは連接コスト表が3つの項（前の前、前、後）から構成されていました。（n項まで定義可能らしい） ですので、lucene-gosenのViterbiアルゴリズムの引数も3つのノードが引数となっています。 lucene-gosen向けの連接コスト辞書も同様の作りになっています。 一方、現在のMeCabは先ほど書いたとおり、matrix.defでは2項の連接コスト表（前、後）となっています。この違いを保管するために、Preprocessorでは、matrix.defを3項にするために一番左（前の前）については任意の品詞を採用できるように「,,,,,,*」のみを設定しています。\n現時点では、Preprocessorの出力である中間ファイルを共通の形式に出力することで、DictinaryBuilder以降の処理に変更を加えることなくNAIST-JDic for MeCabへの対応を行う形を取りました。まずは使えるようにするのが先かと思いまして。 ただ、MeCabの辞書の構成から考えると中間ファイルに落とし込む処理に無駄があると感じています。 matrix.defでせっかく、IDによる連接コスト表を構成しているのに、IDを品詞情報の文字列に戻したconnection.csvを生成していますので。\nということで、備忘録でした。 あとは、テストをどうするか（正解をどう考えるか）なども考える必要があります。現時点での悩みの種です。。。アイデア募集中です。\n","date":1310432760,"dir":"post/2011/","id":"c70b78fd0b5dffcd38322355e9c2471e","lang":"ja","lastmod":1310432760,"permalink":"https://blog.johtani.info/blog/2011/07/12/naist-jdic-for-mecab%E3%81%AEpreprocessor%E3%81%AE%E5%AE%9F%E8%A3%85%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E5%82%99%E5%BF%98%E9%8C%B2/","publishdate":"2011-07-12T10:06:00+09:00","summary":"忘れてしまうので、備忘録を残しておきます。 一応、ソースには少しずつコメントをいれてはいるのですが。 私は残念ながら、自然言語処理は初心者に毛が","tags":["lucene-gosen"],"title":"NAIST-JDic for MeCabのPreprocessorの実装に関する備忘録(Jugemより移植)"},{"contents":"lucene-gosen 1.1.1をリリースしました。\n先日お知らせしたバグ修正を取り込んだjarを用意いしました。\nダウンロードはこちらから\n","date":1309777240,"dir":"post/2011/","id":"229975f1e84b5088e819cd5f2dc43080","lang":"ja","lastmod":1309777240,"permalink":"https://blog.johtani.info/blog/2011/07/04/lucene-gosen-1-1-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2011-07-04T20:00:40+09:00","summary":"lucene-gosen 1.1.1をリリースしました。 先日お知らせしたバグ修正を取り込んだjarを用意いしました。 ダウンロードはこちらから","tags":["lucene-gosen"],"title":"lucene-gosen 1.1.1リリース(Jugemより移植)"},{"contents":"Solr/Lucene 3.3がリリースされました。（速報）\n以下、各サイトへのリンクです。\nSolrリリースのお知らせ\nLuceneリリースのお知らせ\nリリースのタイミングがどんどん早くなってる。。。\n","date":1309501779,"dir":"post/2011/","id":"10eb1e7dc64d8ca3dad92641dadb5de7","lang":"ja","lastmod":1309501779,"permalink":"https://blog.johtani.info/blog/2011/07/01/lucene-solr-3-3%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/","publishdate":"2011-07-01T15:29:39+09:00","summary":"Solr/Lucene 3.3がリリースされました。（速報） 以下、各サイトへのリンクです。 Solrリリースのお知らせ Luceneリリースのお知らせ リリースのタイミ","tags":["solr"],"title":"Lucene/Solr 3.3リリース（速報）(Jugemより移植)"},{"contents":"「Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）」に参加しました。300名入るイベントルームでしたが、後ろの方まで人が埋まっていました。\nということで、主に自分用ですが、メモを取ったので。\n※二次会行きたかった。。。\n1.「鉄道システムへの誘い」\n@ayasehiro（本名無理w）\nHadoopの話はありません。\n○鉄道系基幹システムの開発\n実態：\n耐用年数：１０年以上\n開発期間：数年～５年程度\n開発規模：～10Mステップ、10k人月～\nほとんどテスト、しかも異常系が主体。\n夜間に実際に鉄道を走らせて試験したり。\n開発サイクルが長い\n人材育成が難しい、ノウハウがたまらない。\n開発自体はほとんど時間がなく、設計・製造・試験など新規技術の採用が難しい。\n開発４年前の調査・検証自体が２年程度。\nHadoopも調査中。\n○鉄道システム３大システム\nマルス（予約オンラインシステム）（1960～）\nコムトラック（運行管理システム）（1972～）\nヤックス（ヤード自動化システム）（1968～1984）\n○鉄道輸送システムとは\n用語：\n運行を計画する=\u0026gt;輸送計画\n列車を運行する=\u0026gt;運行管理\n需要想定＋営業施策＋その他（お召し列車など）＝列車ダイヤ作成\n基本計画（長期）＋短期計画（数日～四半期程度）＝列車ダイヤ（重ねあわせてできあがり）\nダイヤの計画（発車時刻など）と車両運用（車両自体の走る組み合わせ（仮の車両））の作成\n＋乗務員運用（乗務員の運用計画）\n運行管理：\nなにも起きなければすることなし。（車両故障、天候、人身事故などによる整合性を取る作業）\n＝事前に計画した輸送計画をすべて見直し\n遅延の検知は？\n昔：人による伝令\n今：システムによる検知（レールに電流流して検知）\n運転整理（実際に遅れた）：\n部分運休、折り返し駅の変更などにより対応\n元の計画になるべく近づく形で修正していく。\n新幹線、山手線、京浜東北線などは速度信号という信号が表示される。\n線路上に信号はないらしい。\n○鉄道システムを取り巻く情勢\n少子高齢化・人口減少のため凋落産業となっている。\n社会インフラの責務＝動くのが当たり前\n2007年問題（ベテランの引退）＝スジ屋さんは最近いないらしい。\n高度な判断支援をするシステムが必要\n連続稼動＝分散技術を適用できない？\n関係各所との情報共有\n計画立案のための情報支援＝最適化技術を適用できない？\n○分散処理技術の適用\n個人的な感想\n可用性（連続稼動）のための仕組み\nバッチ処理\n○分散技術の適用\n・連続稼動\nactive-active構成がメイン\n主系の出力だけを行う。問題が出れば副系の出力。\n3系統の出力を比較器にて出力もある\nmagiシステム\n問題点：\nハードが高い（H社）\nソフトウェアの作り込みが複雑＝テストが前パターンできない\n解決案：\n汎用的なハードが使いたい。\n作り込みも減らしたい\n・バッチ処理：\nAsakusa使えないかなーw\n○最適化技術の採用\nコンピュータ技術の発展\n2007年問題\n職人に言わせれば最適化はいらない、俺の言うことを聞けｗ\n・車両運用のモデリング\n車両数大=\u0026gt;組み合わせ大\n制約条件が多い\n車両運用の場合、走行累積キロの条件もある\n-\u0026gt;有向グラフにモデル化される。（ただし、グラフ化するまでが大変）\n・乗務員運用のモデリング\n車両と違い、乗務員は1回で2人とか運べる（運転士＋移動する人とか）\n・車両割当のモデリング\nやはり、グラフ化が可能\n・乗務員交番のモデリング。。。など\n結構一般的なモデルに落とし込める。ただし、落し込みが大変。\n机上研究だったものが、コンピュータの発展により実証研究になりつつある。\n○まとめ\n鉄道システムはまだまだ未到の領域が残っている。\n開発サイクルが長いため、保守的な開発になる（35年前の設計思想からあまり変わってなかったりする）\nしかし業務要件やシステム利用者の意識は変化している\n興味を持たれた方は、ぜひ、我社に！（社名は2次会でｗ）\n○Q\u0026amp;A\nQ：鉄道システムのカルチャーってイケイケ？保守的？（@okachimachiorgさん）\nA：最新技術も知らないとだめじゃないかという人が出てきている。\nコア部分（安全第一なところ）＋周辺領域（ある程度融通が効きそうな部分）と考えることができるんじゃないかって人も出てきている。\nJR九○＝先進的\nJR四○、北○道＝お金ない\nJR○海＝超保守（企業的に超保守）\nJR東、西＝うーむ？\n東京メト○（運行計画）、阪○＝先進的\n京○急行＝基本人間で進路制御w\n基本的には新しいものには興味をもつ人たちでは。\nQ：Su○caとかで分散処理は利用出来るんでは？\nA：匿名なので外側から見ていると分散処理はいろいろ使えるんでは？\nログデータからいろいろできるんじゃないの？活かすべきでないの？\n使いどころはいっぱいある。\nQ：鉄道システムでどうしようもなくなったことはあるか？\nA：保守体制が一番気になる。\nOSSとかならまだ調べられる。ミドルウェアなどの保守契約が必要。\n保守体制が確立されてればある程度の保守費用は飲み込む。\nどうしようもないことはないが、今すごく困ってることは\nExcelで帳票を出したいとかいわれること。（ちょっと前に作ったシステムでExcel2003。バージョンあげると速度が遅くなったりするｗ）\nilog社のものを使ってたが、IBMに買収されて保守費用があがってこまってるｗ\n保守が10年と長いため、サポートなどの折衝が必要。\nQ：最適化の適用範囲は？\nA：走行順序（どこで追い抜くか）の算出に活用。ほぼ完成でユーザ教育中。\n1列車の波及がかなり影響が出る。ダイヤだけ見ると列車だけだが、乗務員も関係しており、大変。\nある時点から終電までを最適化の対象としたりして割り切っている。\nまた、不足分について算出が出来れば、そこで打ち切ったりもする。\n2.「九州電力におけるHadoopの取り組みについて」\n株式会社キューデンインフォコム e－ビジネス部　@hisashi_yano\n概要：2年間関係したOSSをメインにしたシステムの話。\n○九州電力の概要\n現在風当たりが強い業界。\n東電の1/10くらい\n部門ごとに大手ベンダーが関わってる。\n○Hadoop採用の経緯\n部門ごとに個別最適なシステムを導入していてベンダーロックインされてる。\n・ホストのリプレース\n・両現用センター構成への対応\n・スマートグリッドへの対応\n問題点\n・コスト削減\n・技術革新への中の人の対応（内部でも問題を理解できるように）\n・商用パッケージのカスタマイズの限界\n・脱ベンダーロックイン（実は楽なんだけど。。。）\n○過去2年間の研究内容\n・H21年度の結果\nテーマ：クラウドの要素技術の研究\nKVM、Eucalyptus、wakame、hadoop　性能比較：VMWareとKVM-\u0026gt;ベンチマーク比較\n結論：性能的にあまり問題なし。\nMapReduceの耐障害性など\nダミーデータにより台数増加による影響を検証\n結論：台数大-\u0026gt;性能向上\nストリーミングは性能劣化する\nスループットはリニアに向上\n信頼性は？\n実行中にノードを抜いたりして検証。\n結論：問題なし。\nクラウド環境におけるシステム管理手法\n複数ハードで1アプリという構成になる。\n監視対象が膨大になる。\n障害発生時の切り離しや監視対象も膨大。\nデータセンター自体を監視する仕組みが必要では？というところで終了。\n・H22年度の結果\n分散に特化した研究\n前年度の課題\nサーバの仮想化・管理に関する課題\n分散処理に関する課題\n分散処理環境の運用監視に関する課題\n目的：\nHadoopを本番への適用（実際にはダミーデータ＋本番の仕組み）\n柔軟なサーバ統合基盤（サーバを起動-\u0026gt;バッチを起動-\u0026gt;回す仕組み）＝MonkeyMagic\nlibvirtを使ってる\n50台の仮想サーバの起動が10数分で完了。\n運用監視基盤（monkey magic）\n仮想、実サーバ混在の監視\n監視状況（サーバの状況）から判断して制御する仕組みを構築\nDSLにてルール（判断＋制御）を指定\n・ジョブの監視\n・ジョブの実行管理\n・構成管理の省力化\nvolanteと連携が可能＝AmazonWebServiceとも連携可能\n・サーバリソース＋アプリケーションの一括監視が可能\n分散バッチ処理の概要\nRDBからKV形式にして抽出し、MRで回してRDBに戻すという研究\n対象：\n配電部門（電柱の設備情報の目視検査）のデータの月間バッチ処理\n現状：\n19時間程度かかってる。\nテスト環境：\n実サーバ2台（仮想10台）\nMySQL、Javaで実装\n処理内容\n電柱104万本\n巨大バッチを分割して実装\n結果\nMySQL1台では15日以上かかる処理（現行システムで19時間）\n処理が32分で終了！他でも効果でるよね。\nバッチ短縮の理由は？\n1.データアクセスが分散された\n2.処理の並列化（多重化出来る部分がうまくできた）\n分散処理を書くのに2名死亡。。。\n適用基準の策定、開発ガイドライン、フレームワーク整備などが必要。\n・H23年度は？\nAsakusaの適用など。\n・さらに今後は？\nスマートグリッドへの適用\n-\u0026gt;メーターの交換が必要だが、10年くらいかかる\n-\u0026gt;スパンが長い（10年）ので商用製品だときつい？\nデータ量も半端ない。\nテネシー州とClouderaでOpenPDCってのやってるらしい。\n電力と気温の関係は密接な関係あり。\nエアコンが割合を占めてるから。\n過去実績と予想気温データから分析するのにHadoop使える！\n・2年間やってきて思うこと\n将来目指すべき理想像を掲げるのが重要\n新技術導入は段階を踏むことが必要\nコミュニケーション大切！\n○Q\u0026amp;A\nQ：仮想化環境のオーバヘッドは？（I/O）\nA：台数を増やしたときにどうなるか？というのを検証したかった。\nアプリ配布も考えていたので、物理サーバに縛られたくなかった。\nQ：仮想化に関して気をつけたM/RのPGで気をつけたことありますか？\nA：まったくないです。\nQ：日本でスマートグリッドははやるの？\nA：電力会社的にはやりたくない。費用対効果があまりない。\nQ：今後のスケジュールは？\nA：文書管理システムの組織名変更などの処理時間が540時間とかでてくるらしい。\nこれをHadoopで対応してみようかと思ってる。\nQ：Asakusaをどう評価していくのか？\nA：開発効率性があがるか？は検証する予定。1/3くらい楽になるんじゃないかなぁ？byのぐちさん\nバッチの種類などにもよると思うが、標準化も指標にする予定。\n結果はまたこの場で報告する予定。\nQ：Asakusa＋MonkeyMagicの連携はどんなこと考えてる？\nA：MonkeyMagicを運用基盤として行く予定。合意が取れればだけど。\n※MonkeyMagicもOSSにするよー\nまとめ\nHadoopから少しずつ離れつつありますが、やはり興味があるので、非常に楽しく話を聞けました。\nまた、今回はインフラ分野のシステムということで、システムに要求されるレベルや\n運用周りにも気を配っている話が聞けたのが収穫でした。保守期間が長いため、テストが長い＝\n運用もしっかりと考慮を入れた設計、実装が必要になるというのは最もだと思います。\nただ、少しずつ修正が入るアジャイルなども同様かと。\nMonkeyMagicが出来上がってきた背景の話を聞いて、さらに興味が湧いてきたところです。\n今後もかかわりが少ないかもしれないですが、ウォッチしていきたいと思いました。\nただ、興味あるモノが多すぎるので、優先度をつけつつこなして行かないと。。。\n少しずつでも身につけていきたいと思う今日このごろです。\n※追記：Twitterでコメントを頂いたので、忘れないように追記。\nコメントを貰えるだけでもうれしい。やはり、アウトプットしたらフィードバック貰いたいし。\nありがとうございます！\nTwitter / @cocoatomo: あの質問をまとめるとこうなるのかぁ…… 最適化そのも \u0026hellip;\nTwitter / @cocoatomo: @johtani すみません, コメントはコメント欄 \u0026hellip;\nTwitter / @cocoatomo: @johtani そこらへんの理論って最後には計算量 \u0026hellip;\nTwitter / @cocoatomo: @johtani あの話し振りだとどうもまだ本格的に \u0026hellip;\nあと、まとめも出来ていたので、ついでに。\nTogetter - 「2011/06/29_Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回） #hadoopmodeling」\n関連するブログも見つけたので。\n第5回Hadoop座談会の感想 - ひしだまの変更履歴\nHadoopモデリング座談会（第5回）へ行ってきました - 虎塚\n","date":1309356600,"dir":"post/2011/","id":"49ba23148db9effdc3979aa0fe5876ea","lang":"ja","lastmod":1309356600,"permalink":"https://blog.johtani.info/blog/2011/06/29/hadoop%E3%82%92%E4%B8%AD%E5%BF%83%E3%81%A8%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E7%92%B0%E5%A2%83%E3%81%A7%E3%81%AE%E9%96%8B%E7%99%BA%E6%96%B9%E6%B3%95%E8%AB%96%E3%83%A2%E3%83%87%E3%83%AA%E3%83%B3%E3%82%B0%E8%A8%AD%E8%A8%88%E6%89%8B%E6%B3%95%E7%AD%89%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E5%BA%A7%E8%AB%87%E4%BC%9A-%E7%AC%AC5%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/","publishdate":"2011-06-29T23:10:00+09:00","summary":"「Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）」に参加しました。300名入るイベントルー","tags":["hadoop"],"title":"Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）に参加しました。(Jugemより移植)"},{"contents":"以前、こちらで話題に上がっていた「未知語」に関するcompositePOSのエラーの件を調査しました。（Twitterでも流れてました。） 次のような条件の場合にエラーが発生するようです。\ncompositePOSの設定に構成品詞として「未知語」が指定されたエントリが存在する。 未知語が連続して出現する文字列をanalyzeする。（例：ニンテンドーDSi） ということで、trunkに修正版をコミットしました。 Issueはこちら。\n※お茶をにごす感じの日記になってしまいました。次回はマシな記事を書く予定です。。。\n6/29追記：恥ずかしいバグをいれこんでしましました。。。 ということで、trunkに再度修正版をコミットしました。\n","date":1309232160,"dir":"post/2011/","id":"f6dff70097776e24c2a7c9c0f2514f79","lang":"ja","lastmod":1309232160,"permalink":"https://blog.johtani.info/blog/2011/06/28/compositeposcompositetokenfilter%E3%81%AE%E3%83%90%E3%82%B0%E4%BF%AE%E6%AD%A3/","publishdate":"2011-06-28T12:36:00+09:00","summary":"以前、こちらで話題に上がっていた「未知語」に関するcompositePOSのエラーの件を調査しました。（Twitterでも流れてました。） 次","tags":["lucene-gosen"],"title":"compositePOS（CompositeTokenFilter）のバグ修正(Jugemより移植)"},{"contents":"lucene-gosenのtrunkbranches/impl-mecab-dicにNAIST-JDic for MeCabの辞書を利用出来るPreprocessorをコミットしました。\nビルド方法は次のとおりです。\n$ cd lucene-gosen-trunk $ ant -Ddictype=naist-mecab 現在のstable版で利用できる辞書は「ipadic」「naist-chasen」の2種類でした。\n[以前の記事](http://johtani.jugem.jp/?eid=4)に書きましたが、naist-chasenの辞書でも2008年の更新となっています。\n今回コミットしたPreprocessorでは[NAIST-JDicのサイト](http://sourceforge.jp/projects/naist-jdic/)で公開されているMeCab向けの辞書である「mecab-naist-jdic-0.6.3-20100801」を利用出来るようになります。\nただし、lucene-gosenは昔のMeCabから派生したSenをもとにしていますので、最新のMeCabが持っている機能は\n利用できません。\nMeCab向けの辞書のうち一部のもの（matrix.def、naist-jdic.csvなど）を利用してlucene-gosen向けの辞書の中間ファイルを生成する仕組みになっています。\nまだ、仮実装版ということで、とりあえず動作するバージョンとなっています。\nまだテストが不十分ですが。。。\n利用してみて問題などあれば、lucene-gosenの[issue](http://code.google.com/p/lucene-gosen/issues/list)に登録していただくか、コメントを頂ければと思います。\n※更新が週1回に落ちてきてるので、もう少し頑張らねば。\n※2011/07/04追記 trunkにコミットしていましたが、branchに一旦移動しました。 仮実装として一旦コミットしたので、trunkとは別でテストする必要があるかと思った次第です。 ということで、試してみたい方は、[branches/impl-mecab-dic](http://code.google.com/p/lucene-gosen/source/browse/#svn%2Fbranches%2Fimpl-mecab-dic)にありますので、触ってみてください。 ","date":1308609480,"dir":"post/2011/","id":"991285e3967c3295b4ff2dcd835f7c61","lang":"ja","lastmod":1308609480,"permalink":"https://blog.johtani.info/blog/2011/06/21/naist-jdic-for-mecab%E5%AF%BE%E5%BF%9C%E7%89%88%E4%BB%AE%E5%AE%9F%E8%A3%85/","publishdate":"2011-06-21T07:38:00+09:00","summary":"lucene-gosenのtrunkbranches/impl-mecab-dicにNAIST-JDic for MeCabの辞書を利用出来るPre","tags":["lucene-gosen"],"title":"NAIST-JDic for MeCab対応版（仮実装）(Jugemより移植)"},{"contents":"前回、naist-chasenではアルファベットが別々の単語としてanalyzeされてしまうという話をしました。\nただ、これだと、英単語が含まれた文章を形態素解析すると、英単語がアルファベット単位に区切られてしまい、 単語の意味をなさなくなってしまいます。\nlucene-gosenでは、この問題に対応するための方法が提供されています。 CompositeTokenFilter（compositePOS）という機能です。\n文字通り「トークン」を「合成」するための機能になります。\n利用するためには以下の作業が必要です。（※Solrでのの利用方法を説明します。）\ncompositePOS設定ファイル（composite_pos_ja_naist-chasen.txt）の用意 schema.xmlのtokenizerにcompositePOS設定を追加 まずは、compositePOS設定ファイルの記述方法について説明します。 compositePOS設定ファイルには１行につき１つのcompositeの設定を記述していきます。 記述方法は次のようになります。品詞名を半角スペース区切りで記述します。\n連結品詞名 構成品詞名1 構成品詞名2 ... 構成品詞名n それぞれは次のような意味を持ちます。\n連結品詞名：合成したあとのトークンの品詞として出力する品詞名 構成品詞名：合成したい品詞名（スペース区切りで複数指定可能） TokenizerのcompositePOS機能は、構成品詞に定義されたトークンが連続して出力された場合に、 結合（合成）して１つのトークン（連結品詞名）として出力します。 また、以下のように構成品詞名が１種類で連続品詞名としても利用する場合は次のように省略した記述も可能です。\n以下にcompositePOSファイルの設定例を上げます。 ※なお、現時点では#によるコメント機能はありません。ので、記述した内容がそのまま利用されます。\n名詞-数 未知語 記号-アルファベット １行目は連続した数字を1つのトークン（名詞-数）として出力する設定です。（連続品詞名＝構成品詞名として省略して記述した例になります。） 2行目は連続したアルファベットを１つのトークン（未知語）として出力する設定です。\n次にSolrのschema.xmlにlucene-gosenのtokenizerを利用するフィールドタイプの設定を記述します。 $SOLR_HOME/conf/schema.xmlに以下を追加します。\u0026lt;types\u0026gt;～\u0026lt;/types\u0026gt;タグの間に記載します。\n... \u0026lt;types\u0026amp;gt; ... \u0026lt;fieldType name=\u0026amp;quot;text_ja\u0026amp;quot; class=\u0026amp;quot;solr.TextField\u0026amp;quot; positionIncrementGap=\u0026amp;quot;100\u0026amp;quot;\u0026amp;gt; \u0026lt;analyzer\u0026amp;gt; \u0026lt;tokenizer class=\u0026amp;quot;solr.JapaneseTokenizerFactory\u0026amp;quot; compositePOS=\u0026amp;quot;composite_pos_ja_naist-chasen.txt\u0026amp;quot;/\u0026amp;gt; \u0026lt;/analyzer\u0026amp;gt; \u0026lt;/fieldType\u0026amp;gt; \u0026lt;/types\u0026amp;gt; ... 重要なのはtokenizerタグのcompositePOS属性になります。ここに1.で記載したファイルを指定します。指定したファイルはschema.xmlと同じディレクトリに配置します。 以上が利用するための設定です。\n前回同様、「このComputerは、10回に1回の割合で起動中に青い画面が表示されます。」という文章をanalyze画面で解析した結果を示します。\nとまぁ、記事を書きましたが、すでにこちらで出ている話ですね。。。\nみなさん手が早くて困ってますｗ\nちなみに、上記の設定の場合、「100,000」や「3.14」といった文字列は「100」「,」「000」という形で出力されてしまいます。これらも数字とみなしたい場合は「名詞-数 名詞-数 記号-句点 記号-読点」という設定で１つのトークンとして出力されます。ただし、「。」も「記号-句点」なので注意が必要です。\n※なお、今回はlucene-gosen-1.1.0、Solr3.2を利用した例になっています。 ","date":1307977200,"dir":"post/2011/","id":"50f43b1726cf61066ef8656477b226be","lang":"ja","lastmod":1307977200,"permalink":"https://blog.johtani.info/blog/2011/06/14/compositepos%E3%81%AE%E5%88%A9%E7%94%A8%E4%BE%8Bnaist-chasen%E3%81%A7%E3%81%AE%E8%8B%B1%E5%8D%98%E8%AA%9E%E3%81%AE%E5%87%BA%E5%8A%9B%E6%96%B9%E6%B3%95%E4%BE%8B/","publishdate":"2011-06-14T00:00:00+09:00","summary":"前回、naist-chasenではアルファベットが別々の単語としてanalyzeされてしまうという話をしました。 ただ、これだと、英単語が含ま","tags":["lucene-gosen"],"title":"compositePOSの利用例（naist-chasenでの英単語の出力方法例）(Jugemより移植)"},{"contents":"lucene-gosenの1.1.0がリリースされました。\n大きな目玉はJapaneseTokenizerが出力する形態素に関するデータを遅延ロードすることで、パフォーマンスの改善を行ったことです。\n詳しくは関口さんのブログで実測されてます。さすが、早い。。。 あと、先日リリースされたLucene/Solr 3.2への対応も行われています。\nlucene-gosen-1.1.0のダウンロードはこちらから。\nうーん、中身がない記事だ。。。\n","date":1307934480,"dir":"post/2011/","id":"eeef60efe889349870426d10edc694be","lang":"ja","lastmod":1307934480,"permalink":"https://blog.johtani.info/blog/2011/06/13/lucene-gosen-1-1-0-%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/","publishdate":"2011-06-13T12:08:00+09:00","summary":"lucene-gosenの1.1.0がリリースされました。 大きな目玉はJapaneseTokenizerが出力する形態素に関するデータを遅延","tags":["lucene-gosen"],"title":"lucene-gosen 1.1.0 リリース(Jugemより移植)"},{"contents":"lucene-gosenをSolr/Luceneで利用する場合、TokenFilterを利用してTokenizerが出力したToken対してさまざまな処理（Tokenに対する正規化や展開など）を追加することが可能です。\n今回は現在（ver. 1.0.1）用意されているTokenFilterについて説明します。 以下はTokenFilterの一覧です。 「フィルタ名」にはSolrのschema.xmlで記述するクラス名を書いてあります。\nフィルタ名(Factory名) 概要 solr.JapaneseWidthFilterFactory 全角のASCII文字を半角に、半角カタカナを全角にするフィルタ。例：「Ｃｏｍｐｕｔｅｒ」-\u0026gt;「Computer」 solr.JapanesePunctuationFilterFactory 区切り文字、記号などを除外するフィルタ。[※1](#token_filter_kome_1) solr.JapanesePartOfSpeechStopFilterFactory 設定ファイルに記載した品詞に該当するTokenを除外するフィルタ。ファイルは「tags=\"ファイル名\"」とfilterに記載。なお、ここで記述する品詞とはanalysis画面に表示される「partOfSpeech」の完全一致となります。 solr.JapanesePartOfSpeechKeepFilterFactory 設定ファイルに記載した品詞に該当するToken\"以外\"を除去フィルタ。ファイルは「tags=\"ファイル名\"」とfilterに記載。なお、ここで記述する品詞とはanalysis画面に表示される「partOfSpeech」の完全一致となります。 solr.JapaneseBasicFormFilterFactory Tokenを基本形に変換するフィルタ。例：「悲しき」-\u0026gt;「悲しい」 solr.JapaneseKatakanaStemFilterFactory カタカナの長音（ー）の正規化フィルタ。4文字以上のカタカナのみの文字列の最後の長音（ー）を除去した文字列に変換します。例：「コンピューター」-\u0026gt;「コンピュータ」、「コピー」-\u0026gt;「コピー」 上記のTokenFilterをJapanizeTokenizerを利用するフィールドタイプに設定することで 各フィルタによる機能が有効になります。 schema.xmlの記載に関する詳細についてはこちらを参考にしてください。\n※1　Characterクラスの以下の定数に相当する文字が。SPACE_SEPARATOR、LINE_SEPARATOR、PARAGRAPH_SEPARATOR、CONTROL、FORMAT、DASH_PUNCTUATION、START_PUNCTUATION、END_PUNCTUATION、CONNECTOR_PUNCTUATION、OTHER_PUNCTUATION、MATH_SYMBOL、CURRENCY_SYMBOL、MODIFIER_SYMBOL、OTHER_SYMBOL、INITIAL_QUOTE_PUNCTUATION、FINAL_QUOTE_PUNCTUATION\n","date":1307344980,"dir":"post/2011/","id":"4b046ac6a4796fb1338f0481dbd4003d","lang":"ja","lastmod":1307344980,"permalink":"https://blog.johtani.info/blog/2011/06/06/lucene-gosen%E3%81%AEtokenfilter%E3%81%9F%E3%81%A1/","publishdate":"2011-06-06T16:23:00+09:00","summary":"lucene-gosenをSolr/Luceneで利用する場合、TokenFilterを利用してTokenizerが出力したToken対して","tags":["lucene-gosen"],"title":"lucene-gosenのTokenFilterたち(Jugemより移植)"},{"contents":"辞書の特性について 現在lucene-gosenでは以下の2つの辞書が利用可能です。 簡単に違いについて説明します。\nIPAdicの辞書について\nバージョン：2.6.0（※IPAdicとして公開されている最新は2.7.0） 最終更新日：2003/06/19 登録単語数：約24万語 NAIST-Jdicができたためか、更新されていない NAIST-Jdic-for-ChaSenの辞書について\nバージョン：0.4.3（※NAISTとして公開されている最新はMeCab用の辞書0.6.3） 最終更新日：2008/07/07 登録単語数：約28万語 IPAdicの後継として整備。品詞の定義など大まかな仕様は共通。 IPAdicと異なり、アルファベットや数字が1文字ずつ単語として登録されている。 IPAdicとNAIST-Jdicで大きな違いはアルファベットと数字の扱いについてです。 次のような文章をそれぞれの辞書で解析した結果は次のようになります。(SolrのField Analysisの画面です。思いの外大きいのでサムネイルのみですが。) 「このComputerは、10回に1回の割合で起動中に青い画面が表示されます。」 ○IPAdicの場合 ○NAIST-Jdicの場合 「Computer」と「10」という単語の区切り方が異なることがわかります。 この違いは、辞書のエントリが異なるために発生します。 NAIST-Jdicでは、数字（例：「1」）やアルファベット（例：「a」）が個々のエントリで登録されているため、分割された単語として認識されます。\n※この問題への対応方法はまた後日。\nカスタム辞書について 実際のデータを形態素解析したい場合、辞書に存在しない単語を登録して、1単語として認識させたい場合があります。（固有名詞など） このような場合にカスタム辞書を利用することで、新しい単語を辞書に登録することが可能になります。 カスタム辞書を利用する手順としては次のようになります。\nカスタム辞書ファイルの作成 作成した辞書ファイルを利用したjarファイルの生成 まずは辞書ファイルの作成についてです。 以下では、naist-chasen(NAIST-Jdic)の辞書を例として説明します。（ディレクトリの違いだけで、IPAdicでも同じ方法でOKです。）\nlucene-gosenでは辞書のコンパイルに2つのフェーズが存在します。\ngosen用辞書を生成する前処理（中間csvファイルの生成） gosen用バイナリ辞書の生成 カスタム辞書は1の出力の形式(=中間csvファイル=dictionary.csv)にあわせたCSVファイルとして作成します。 CSVの各カラムは次のような意味を持っています。\n単語 単語の生起コスト 品詞 品詞細分類1 品詞細分類2 品詞細分類3 活用型 活用形 基本形 読み 発音 3カラム目以降は「素性（そせい？）」と呼ばれる項目です。ipadic、naist-jdicでは「品詞」「品詞細分類1」「品詞細分類2」「品詞細分類3」「活用型」「活用形」「基本形」「読み」「発音」となります。 ※「見出し語」「形態素生起コスト」「素性」と呼ばれる項目を表形式にする。 厳密な品詞の体系に関してはIPAdicやNAIST-Jdicのサイトをご覧ください（説明できるレベルにはまだまだなっていないので。。。） 今回は、固有名詞（人名、地名など）を追加するという例でカスタム辞書について説明します。 固有名詞として「達川」という人名を追加してみましょう。 まずは、次のようなエントリをもつ「custom-dic.csv」ファイルを作成します。ファイルはUTF-8で保存してください。 コストはすでにあるエントリで似たようなエントリのコストを真似します。（今回は固有名詞,人名で似ているものを採用）。ちなみに、コストは小さいほど単語として出てきやすくなります。 ※カスタム辞書にはSenで利用していたものが利用できます。 **\"達川\",2245,名詞,固有名詞,人名,名,*,*,\"達川\",\"タツカワ\",\"タツカワ\"** 上記ファイルを、先日紹介した$LUCENE-GOSEN/dictionary/ディレクトリにコピーします。 では、カスタム辞書を含んだlucene-gosenのjarを作成しましょう。 カスタム辞書のビルドは$LUCENE-GOSEN/dictionary/で行います。 また、カスタム辞書の指定はCSVファイル名をantの引数で指定します。次がコマンドの例になります。\n$ cd lucene-gosen-trunk $ cd dictionary $ ant -Ddictype=naist-chasen clean-sen $ ant -Ddictype=naist-chasen -Dcustom.dics=\u0026#34;../custom-dic.csv\u0026#34; compile $ cd .. $ ant -Ddictype=naist-chasen 上記コマンドの例で\u0026quot;clean-sen\u0026quot;というタスクを実行しています。これは、すでに出来上がっているgosen用のバイナリ辞書を削除するタスクになります。すでにgosen用の辞書が作成されている場合には辞書の再生成が行われないためです。 また、複数のファイルを利用したい場合は-Dcustom.dics=\u0026ldquo;custom-dic.csv custom-dic2.csv\u0026quot;という形でスペース区切りでファイル名を記述すればOKです。\nカスタム辞書を適用する前と適用後の違いは次のとおりです。 適用前 適用後 簡単ですが、以上がカスタマイズ辞書を利用する方法でした。 ちなみに、この記事を書く前にすでにカスタム辞書の件を書いているブログがありました。。。こちらも参考にしてください。 今回の例でいくつかSolrのanalysis画面を利用して説明してきました。Solrでのlucene-gosenの利用方法についてはまた後日記載したいと思います。 ※参考までに。Solrでの利用方法はこちらにも記載してあります。\nまた、IPAdicなどの辞書について記載のある書籍を見つけましたので、参考になれば。\nアプリケーションソフトの基礎 (講座ITと日本語研究) ","date":1307002560,"dir":"post/2011/","id":"b2621497b3313c97855ed951f0d9b291","lang":"ja","lastmod":1307002560,"permalink":"https://blog.johtani.info/blog/2011/06/02/%E8%BE%9E%E6%9B%B8%E3%81%A8%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E8%BE%9E%E6%9B%B8%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/","publishdate":"2011-06-02T17:16:00+09:00","summary":"辞書の特性について 現在lucene-gosenでは以下の2つの辞書が利用可能です。 簡単に違いについて説明します。 IPAdicの辞書について バ","tags":["lucene-gosen"],"title":"辞書とカスタム辞書について(Jugemより移植)"},{"contents":"今回はソースのダウンロードとビルドについてです。\n最新版のソースを利用したり、JavaDocを見たい場合はソースをダウンロードしてからビルドすることになります。 ソースのダウンロードからビルドまでの手順について説明します。\nまずはソースのダウンロードです。\n$ mkdir ~/work $ cd work $ svn co http://lucene-gosen.googlecode.com/svn/trunk/ lucene-gosen-trunk $ cd lucene-gosen-trunk ダウンロードしたソースは次のようなディレクトリ構成です。\n.classpathEclipse用ファイル .projectEclipse用ファイル .settingsEclipse用ファイル AUTHORS作者のリスト（Sen、GoSen） CHANGES.txtlucene-gosenにおける更新履歴 COPYING.LGPLライセンス README.txtReadme build.xmlAntのビルドファイル dictionary辞書コンパイル用ディレクトリ docsAPIドキュメント用ディレクトリ libライブラリ prettifyGoogle Code Prettify用ディレクトリ（APIドキュメントでの色づけ用） srcソースコード また、辞書やソースのコンパイルにはAntを利用します。 通常利用するAntのタスクには次のようなものがあります。\ncleanプロジェクトのクリーンアップ build-dic辞書のコンパイル（辞書のダウンロードも行う） jarjarファイル生成 dist配布パッケージの生成（2つのjarファイル生成） javadocJavaDocの生成 jarファイルの生成までの大まかな流れは「javaソースのコンパイル」～「辞書のダウンロード」～「辞書のプレコンパイル」～「辞書のコンパイル」～「jarファイルの生成」となります。 Antのタスク以外にjarファイルを生成する場合に利用するオプションは以下の通りです。\n-Dproxy.hostプロキシのホスト -Dproxy.portプロキシのポート -Ddictype辞書の指定（指定可能なものは次の通り。naist-chasen、ipadic） 以下はNaist-Jdicのjarファイルを生成するコマンドの実行例になります。プロキシサーバを利用する環境の場合は-Dproxy.hostと-Dproxy.portも指定してください。（※認証が必要なプロキシの場合はAntのビルドファイルを修正する必要が出てきます。）\n$ ant -Ddictype=naist-chasen jarファイルはdistディレクトリに生成されます。 これで、jarファイルが利用できるようになります。\n次回は、ipadicとNaist-chasenの辞書の違いとカスタム辞書を利用する方法について書こうと思います。\n","date":1306398840,"dir":"post/2011/","id":"ff1441a42144a7de9a3eaf9f5e7cfea9","lang":"ja","lastmod":1306398840,"permalink":"https://blog.johtani.info/blog/2011/05/26/%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%8B%E3%82%89%E3%81%AE%E3%83%93%E3%83%AB%E3%83%89%E3%81%A8%E6%A7%8B%E6%88%90/","publishdate":"2011-05-26T17:34:00+09:00","summary":"今回はソースのダウンロードとビルドについてです。 最新版のソースを利用したり、JavaDocを見たい場合はソースをダウンロードしてからビルドす","tags":["lucene-gosen"],"title":"ソースからのビルドと構成(Jugemより移植)"},{"contents":"概要： Lucene/SolrのコミッターであるRobert Muirさんが始めたプロジェクト 歴史： MeCabのJava移植版としてスタートしたSenがベースになります。 その後、辞書の構築部分をPerlからJavaに置き換えたGoSenが登場しました。 が、どちらもメンテナンスされなくなってきたので、Robertさんが引き継いでメンテナンスとLucene/Solr対応をはじめました。そして、現在にいたります。 ライセンス： LGPLライセンス（ベースになったMeCabのライセンスにならって） 特徴： 以下のような特徴があります。 ・Lucene/Solrですぐに利用可能（3.1、4.0に対応済み） ・jarファイル1つで利用可能（辞書をjarファイルに内包） ・LuceneのAttributeをベースにしたTokenの解析 ・その他（パフォーマンス改善、テスト改善など） プロジェクトのサイト： http://code.google.com/p/lucene-gosen/ ダウンロード： http://code.google.com/p/lucene-gosen/downloads/list 現時点では2つの辞書を内包したjarファイルが用意されています。 Naist-jdic 0.4.3（for ChaSen） 参考サイト：http://sourceforge.jp/projects/naist-jdic/ IpaDic 2.6.0　参考サイト：http://sourceforge.jp/projects/ipadic/ ","date":1306130400,"dir":"post/2011/","id":"5988b62a0c0785a303b77c74608e8b55","lang":"ja","lastmod":1306130400,"permalink":"https://blog.johtani.info/blog/2011/05/23/lucene-gosen%E3%81%A8%E3%81%AF/","publishdate":"2011-05-23T15:00:00+09:00","summary":"概要： Lucene/SolrのコミッターであるRobert Muirさんが始めたプロジェクト 歴史： MeCabのJava移植版としてスタートした","tags":["lucene-gosen"],"title":"lucene-gosenとは(Jugemより移植)"},{"contents":"今さらですが、ブログをはじめてみようかと。今さらですが…\nはじめてみようと思った一番の理由は、自分で調べたことをメモがわりに残すためです。 あとは、自分を追い込むためもありますが。(こっちが一番の理由かも)最近勉強してないなぁと感じているので。 ということで、まずは、lucene-gosenやsolrについて書いていく予定です。\n","date":1305859440,"dir":"post/2011/","id":"94b85ba716dbb7c20b230e69248b8208","lang":"ja","lastmod":1305859440,"permalink":"https://blog.johtani.info/blog/2011/05/20/%E3%83%96%E3%83%AD%E3%82%B0%E3%81%AF%E3%81%98%E3%82%81%E3%81%BE%E3%81%99/","publishdate":"2011-05-20T11:44:00+09:00","summary":"今さらですが、ブログをはじめてみようかと。今さらですが… はじめてみようと思った一番の理由は、自分で調べたことをメモがわりに残すためです。 あと","tags":["misc"],"title":"ブログはじめます(Jugemより移植)"}]
\ No newline at end of file
diff --git a/orama/index.html b/orama/index.html
index 6e9b32e31d..41ddd38597 100644
--- a/orama/index.html
+++ b/orama/index.html
@@ -498,6 +498,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -887,7 +889,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/orama/placeholder/index.html b/orama/placeholder/index.html
index 015761e4e8..ef99aeae92 100644
--- a/orama/placeholder/index.html
+++ b/orama/placeholder/index.html
@@ -362,6 +362,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -751,7 +753,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/orama_index.json b/orama_index.json
index bfc58efe26..9b70f2d686 100644
--- a/orama_index.json
+++ b/orama_index.json
@@ -1,77 +1,77 @@
-5v WinternalDocumentIDStore1wninternalIdToId<xp `d869fb48cb9acba03dc639481524ee80 `476e17b6f854414033d5cec1470774ee `516a7aa07f8faa6b7aa38beb5010cf8c `7f78b02c531f09602ba4e140132d26a2 `8f58cbe5f2ce85c22569af765de3f8d3 `f9e847ee886bdb9ab5583eeb6eabbd51 `7884b62c561b999b9358d52779a18218 `ed431877ce11fe403fee77f7d26ce637 `086b4fd5f77021a0a2aa6b0e90061486 `a12474027c91fad5a861aa9919817d72 `698cf3cbd796161d82c9ac438ebab5d2 `9335522f4c8dbc7256a42a091e6e00bc `df30d810068e4656498e5972c6de7e3d `67c2ae6761e89be0fa66db9623b40d30 `9693a1e77dee5785b1dc61ccffd2e906 `73279888a8fe482c836fb19ca23318dc `6639ec6f88c4976f8ca20fa840f169e3 `167a7c9d579ce6f2cebf64a6f6329ecb `3384ea6bb47d70f8ca94b4510813f36a `779e444b4bc720a9eed97f19c41e8773 `f56c19442484b3e4f47875b58b3f72b2 `5eebdf85fd1726db301194bfeeee4377 `7cc21814165879f72529e91682ece5c6 `0645bdb1cdf88ec74288d503eb71839c `104b8ee17a8bf1f7043d236659680493 `218e2c36d5945ece02fdc55d6cbcbc38 `f0fdc140e18514362a4e52376a6fecba `26e44dfd16a2963d4c18e99806c26fd7 `35200cbf0b5b45d7f5f0b343cb18868b `10a7f69bd03d2632722300194f01e93d `59b7b60e6bbf4858d72643d22ad90451 `43caef5d41c4e74826e4a8d82088739d `f4baa43cc7ca712d83b99a794c4e2dbd `f41d4fde94cbd7bbd28808dc080a2019 `ce426b7f3190c8a4a47d45ac799e91a4 `eced95e5f301a8340e83d81d3c0d5c0d `fcb0105fa6b5777a133f247784b9d930 `931b2ebd9bfaeb5dcf1973e724a1f8d0 `aa61b4543e8a7c67fccabee27a6e99cd `d95522c691013bfe66dd46ded85a98ed `4ad8239a37f641bcd17abeb96106314e `64a421c2367372c3199c66a6420faf89 `a5b2ee641e10d3e4db8f888217ab9ecc `c6fc88bd57a0e57ddf22e2eb1bef892c `a46c601d03a3a26bc418d0096fe83a42 `b16bddd1a6d3e5f4136446bebe7ffbc7 `188c1ee5132a6752dfce5a0235354070 `de37d9fae011687eb1eb5a127fcb89e3 `c377351433a941a927aab543931f6026 `15932a656f7acfac897d27766eadc9e2 `b2c4cf0fb96d02d37f03668caaecbc57 `d08a3fdc040bbbdd81c9927ce296318c `827de2d7a9d231f6bcb44caf35896c1f `3c5d4d351e0fb9e33e0e8b6d1d43c0f2 `eb2a5824e03996c1966bee38866ce349 `f5effd616a3f8db6193b482caec37912 `11a61827e80739a6065960eb188d5758 `9da845cd31310b8952efd1be1881e651 `208a8c072ea521c813b86ca7730eb880 `e5cb2e5d501d3db2db5d8f14984a66d4 `bbd2824ff0d5b801bb6f5da3a2a1a888 `8a1ea5d5cf843bc5955a94cfcc321e92 `82a115ab8d617e4e96813587fe3a6049 `e74d071363645a588f858b35231128c4 `163beeae9620c1a6a46a38aa7ebd9663 `36dd94159e3e60076c0c6098086e255f `21982f43bc435f22efef22b309a48c66 `306cecb32320ead508346ad8fed3394d `1e220a934e16fd941bd804ca03865b60 `09155bf417a93847b538ad607f78cca2 `c098c6f0901979bd914ed7a345200f90 `2c3270f8797ace2fb37402ea6a09d126 `44db1f1fefc97cd28d55d443f2bd2b63 `4d71d2a23c85fb7af20e8d1e8b3e0de8 `be2c49ea5816e7daa6d3b3ff45353291 `15357b6978e83daa2d97692c861dc177 `f488aa62d39194824861a134567cadb8 `9a687babb0f44db51dc389b75bdaa19d `dc9580308938069159c5afc55b2f3b96 `4fbdc9c57a37781dc5dd86f470c61d04 `6fbf7c3d0f4f89e415e89cec28811a94 `8d9c3760395e8e0eb40e335b22750b68 `3f431bf71ee866f626daf42bc915fa3f `7fded0345c258eea966c0b5ee1b7c7aa `a7f0e85fcad4f5bc5ae5c18c10de4f9e `48b5ab9805919736382ffea5a9554c02 `c9d257aba54475c20b3737ce7c779e55 `6f47cb314fd780c122adb8cc1f44f785 `d710a073be2da219a388a150eb7b6b6a `71cf83ae0f45e9ede3a3f979b9c74933 `daa3fe935b0be9f31b6b362ad9e0d2d6 `ef8a399c9679ce4e9710c7c6ecf8bcc7 `c3053579ae25e2fb9b967076a06373af `7b080dc43fce482af14de61c6ab819a5 `90f9355781403b92e844de8568863ae8 `7fcfaa8dd34dbd508f19e8ca0fcfda0f `c61a5bda3f1667498626ae52ad0362e0 `d9018f459d3c94a91e92b459e152f7e7 `99c9c80a6532e4ea3b535c5a92d07a25 `018b365b00dd3a6ad17c813d21590549 `a65bd31d4c3dab0a41712823a5d6002b `3c299a4d77be8b4f886ce9fcd23a2561 `35aa9e09db936aee7ec407c431816573 `1a1a8cc0040b356d06eacd22e0526476 `80c8fca02ebfecc7a931dad1ec38466e `f3ef819656f68b87a91c53afbd441fec `1abc586d67f0b6c05fd5e60f25492340 `1bbf2ef67f096960e13d8578fa544536 `c2d39f2f7fe6cb69fc8efb6c5495c932 `78da47d61c91c82809a3c97a791d26d2 `11b3a28b536f34d3606427f835bd3ddf `d8041ae308961666b15aa1e57b0f9f35 `d96f80f23543850a2ee9fff8cd2cc53f `538e38fbc3f78cd61e1841d8141ddcc1 `b27bdabd8e1a6b7dc06886867331ceb3 `6c226ee1519fbf910197cc1d5c5a5756 `ee62cb0b9a97f990df1ed0266a7027e2 `ba45ddd3042dad59a12e5937644f7246 `3fd9052870778e14ab4a5acbc8c24af4 `d3fa23c9066f943f10e8883de9340dea `10ae016e19fff6ae9cfaeb8534fa47f9 `04d818cbaac08b2915db15e0bffdcb5b `8cc6b19cd410e638f4beaf1642f4f52a `d791eaca9375ca1b36a987af22ee71dd `e6684944c37dbdd4c08d978af9e47bed `bbe1deec11d459bdb348051b970abdaf `a673b3829e62477e01abc75465416b86 `7b6cb59a177abe9767fd22da5a03b1e6 `4afcb20d4d95bcd1bde3aa6b7f552660 `7c21b70f9e9c782c1f5153268e0cc1c1 `f3a9b931b7f552a4f9dfa61ce4f39f0e `fa0486610d8a02cea245c13c85b6de27 `c20d71627e66a044b21780f56f2f9504 `4f88f3eebe44285ded812939553ef94c `29b4c2b5adcd80ced1612128b3ca95a9 `16f1046144ad9ee7bb96214ba7ae7516 `002d980d74d19b43ff4e2446665e2fe5 `550becdd08d00fb1e7fd00c2adc3d3d6 `a62186ea292d6db03a087bd5dfcc3f1e `167e2a6833d49ce198cb3b88f521991e `993e58f132740b464ecf06ee289dc7b2 `c56a76ef8f604a8d87be2a32b1f81fac `3fc7462a83fa55885067fee629287e8a `4b0a768585da8f9f8f8db1ca409e7ebd `c54909ecf4fb3e9afeea36200fe95dce `d819cea5197e9b8673d6c0b16659a5ea `1b56132638912a1ca54fcf7cd38b8e23 `2ea86ae5093670df1d4502ea82efa1ac `5912529cfd6ce14c5ede5c6c83dae7e8 `15700442e957951307bbcec5fff8643d `018e32a8010960eb17e368a6fdd5a51b `e159a35d1b9a46e03072a3d54780edcb `cc64c2fcdecdb505b3797e1aaaa59adc `4cc08ca51ecf0f963035f039de6194c5 `4b227d61f33182579cd3edd0ac6c7c44 `0de0edbf2a506143c1739b12e94c0ef9 `744554499cb7880086fbd9b1f080e7e1 `5a9e950f4ac186925e5de978c5f72062 `73b8194ad8fce0cabb01cd21d5e18500 `100c0a69bea7f02a0f4540ecaa37d0e3 `809925e891b0456231c374b09cbe4a90 `dd6c32a722dc815273cd9ed8cd6c671b `ee4ff9e4e8a1948795e26af2f3f8a30f `f887e1aabf801e351bfb39698f208af1 `9cc2a0b6c8be1405cddcdeb4487c59fe `18b7998a871950ebc36c415a53630477 `ddab6357ff522c0c956ebd7669e83454 `55188a318c5998989255253e15ccc1f6 `75d9268739fe7787ac02d389ac605feb `23a22d1411afb787810d68210e6fad4f `615db1a24f36d19a8eaf18d4dceed6b2 `8d7caf84b3a51cca27291c1f7cfc2d40 `7249710187cc2d983709e044dbc78d9d `563864a949924c505985a168191dcb84 `24357fe145c869ec82fdfc8134a1a6d1 `19ecbaa5e12f7a9ebcff703c79534a52 `ced9df0d8c8ed14de91c509b31b4c4ae `cb13b64d0127c13bb466c4d4677a7b8a `f2cbe07bf2ff16d5a5860b4d6edbc5e8 `eee039f49a5b570599cf459c55c649f3 `ddd3e6f6e298d3884abc4d888a043664 `5b97ead91c0dd0bad57b4f43a89149a2 `997acc135d01b54f7de77a432fb9133f `1fed22e99b0e11a50eb7b92cb1644e8a `5badf61ecb9cfadd7d6af58712fa5f6f `fe6ba10cc6c9509b4b22e9d59e029775 `b36abffbe5d6a0de73a9968604a1a3f9 `cb9649eca3dfbd356527ffc88f1dcb94 `7dea465ad52758b10cbceb08c81d1760 `bce2fa6458f39a75e2713f3d687271a1 `e5390751969ab21df280b7591854b89f `05330c3703d0e2c96cfe657ab33f130c `4a3c42c9c5ac29db268010bbebf4f579 `1bc36080b2493aab78c26e4f2152542c `2de582c67fca31500621ecd6d3917a07 `0a8183ced0e9e3e895b41286e54e8e4d `4d8f5e581eee602c7fd21da8eb68df9a `937a597a8b399fd32caba88a3c1c7bc4 `2a8412aa50d07330f1298f0243fa79d3 `d266a2023c67b7a20c3bd01055b223bc `bc2709406a9bb19e8d83a78f81e36244 `998eda745d07fd8608f251138384a0b9 `853cac0f2d1f90b7c986e7d1dcdbbfde `4616fbea6a6dbc1074bc3f1016bbc73b `f15702ae9e55bad42182cf18724d1863 `77d965afaebd7193badc746d52b4173f `bdea71d64cdfcc405e65e750fe8d9b86 `7cc605e721fdd1d2ccc16f5b6490e830 `fb1da4a6ed74705ad98bb60ad4badaf2 `0c1821d1069578551d0e3c7d9275f16b `e3e146469ed4318eaa2ffbca3510c054 `21a8e6324e9330d4f8ebade604c62b6e `40abea0a87a64bd832a1fad69458b293 `916bda59bc7621d5c1790c040572a3c0 `5bb6f8322cdbda7a21e4aecbe04462b7 `a578acf825a595ce95fe8f804b7208f0 `706c033b4483b6d062b66d6e4ea0236a `72df0bf7853e05560d94208817b83468 `91fe03f994e8e85cede4e3bd62f4d6b7 `ed4f5a398056eef1cf6caa90786b340a `2824bef72110575c78aeb979170212b8 `e396cbf9274b590a1d94ee43d823a0bd `50562b09417cd8c4a2348a0a5aabe754 `76a1fb7f21fda9eddb95426b65124517 `299abcee56b05b312ed5700f686f79b8 `670744b945088de05866864f7d57bee7 `c1241374502f200cf9fc49c8d6fb5822 `d51032bef3e7117a94336fea18a3fad7 `65453a1ae403679bd2e47398a04205ca `abc5ca9856a61831fd4ed06b402875d2 `386dc9d1b647a9f3965f1fbe29c7dfb9 `9ad72c2a5157f21741bd4581a562dfc7 `f55d33371dcff207fd7d201128df2ea3 `229b7fc784707b1d2c702fbeba080e86 `c98cbc333fb7d95c6c9fc4924b0526e1 `c6107ff57e96a1373c019d252c00ad84 `f6debed350f20a2b3aa4d970e3227411 `c4e7199a586a308352b7a881add7e356 `15f501351d482ffd73985a50f5c89d1f `6425af51edead39c0e439073986043fb `10c715f70de25ccb493bbbb532b78ced `c18b12fff24dc87e7f1039bd17c0c6aa `cb5b6f7ab4d36e90d2619cb907ebb956 `a0a00c23556fcc5dbfb7b7f43fbbb61d `d9560caeb797b302191f667b4264da40 `a2012a3c9cdb1d6fd69afdbadc1e76b6 `13684d16fdd07d5f0584e29265a270e7 `66f43ab4b823d67f52735bbbe6ba65b0 `a106d7c1b1b277538367f9c8140e3a75 `9dca844d353efed03fbaddfc0fab7c76 `b5c628b0c1dbf857a475c4be5de4690d `0302e8a57a5e8604342a925b2dc60737 `76e127a44931bfefab991be3dd7a08b7 `e1870dde155be1a375f155dd1f7ead13 `d2e805472f79f0b558f75b90b5e7b4ee `79e647a3f8b36a1221897f5837c84aff `5931f8e3acdac724742c4ee0960d8d40 `3931327ed463d1568868c5ab8e839148 `33e01e2271be22b5ed330045fe6aff50 `cd9ba1f582642d9cbe500f018afab341 `b875f24d3d444fdda82b6bbfb75a4c92 `59d1b7206e7664e76672d3de4dc9a8ed `1b9c5ae60ec46be64a1877f0c6920edc `50557b455cba1a3ce9b4555fc3fd5433 `146e8ca40c0d37f36eecea822028dd9e `a98d42be181c01b8077e060b1b5080ec `ecf3ac80454654d990d9c07d33d35d1c `26c47355cbe966a94826cbe2fbf2b355 `33919e866426ce8e7b2ce06f19bbf889 `78292d953eafbdf9e57cc4bbbe6e8964 `c4d3a917f623f58646ce93015d79e8e0 `d12c1c2a68be4c7fda5a7737d5493b4d `f45069216cd934b80ce882c9a2f2a08a `1fe14e2e02b6e65e6e6e2ae3d8ddcc9f `e30258aeb8475d4c27f7935945671856 `cd90bce912f5743226af94c1efaaa4a7 `494557db52824555864d1106278cd1f0 `16f10764f0ccce42d5be8cfeac36b446 `dbcc4002c15afefef853a08a0804ba3a `11d4726484be418849e1f4200ade9535 `db97311c24809f103575d8a7fee19680 `286a9a4ee373398d7d2c93862c5f6661 `99f5219da22485d0872a2529599c8440 `36ff37ced0d3211db95a5ac0daac0c35 `1ca04e5339ed1826c12fe61fd984e949 `73d2fce4efa52675b35a11ee97bc2db0 `26d0c0d8c465087cf160a3bdc479f2b4 `f5f28f42ad234b4389af4cbea54ff60d `5412fb82160d0f6093e4b6670f505c13 `b051fd352847c06e748b345e8ed0738b `bf4f86812812dab8d39db9aaefe94a78 `322264a17ef7182eb1475bd2eaebc2eb `20110c8f8da8304b6d9d3c2845a38128 `992a00c30242b6217243f3c387ea18b7 `4c08b67e0c1fdeef50b1fdcc32cdcee2 `4a30eeb083acec8460150068ba0c6743 `898d25a2ab9c0ba1fa9bad462405e475 `e01e01d18582c7f69e1b0db7e1b111a0 `7e23419e4fc69b5b533815681c9bb1a9 `98c640616f997a323af625e34ba34850 `922cc71fd28b1dac8f407f1d517f5595 `43501cdf0de25278a208cbb9aad80012 `89abaa7f21cf788ce4744e3e61173291 `7604edf307a5e96120606c8dda06458f `775894425f5a7436f56fc5a3b4a2cfaa `8a29f62d1bebfe7b8008d7f264b56b4e `7fa2f0877831b4c924438396760f1841 `68a8f34c240a42ab521d2f885f7aa33c `9ac7bb94e60dc30a023ce433de027364 `dcc2e24df32287e89ee3b0f64d617f57 `8acc78be63e27e938ee53ec2c0b90c61 `9f29c6d9719fc6bc09a2981057642b69 `d13aa56e27fe71ef40ff153c093ecdf8 `9ccda414c322ebcdf875eacbba2e4b7e `69f755dd5b9e90a99c3086543790541c `277f7f2177e2a265a62680ea0158f9b9 `ee48516e57684c5a4c22adccac34be92 `216db319052b5742fc68862cb2f39905 `cbf9587a8187985725963b8bfc67004d `0dcb6d0f17794bbca56b6cdb9e20b932 `ffdbd6a7d28c9a63976e9eec38cab0f5 `de734259dfb9addebe2b226d96b4f744 `78f002cc3d512ea302c900d1da4dfeec `c4b418764dca70aebfc965899a3fa7e5 `95c0a5b8a66950b5f22dd82a8dfe0ce5 `c92c12a28fa219ad1aab60865046ff05 `12d1e0cf7396dd33a9bbbca8da4cbc68 `d77cdb466c5063b99c5aea58e6da4d32 `904b07170a0ce481b7491e7fecce4f79 `bed3b7fcc1294e23639057435ac8756a `56d5711303378bd333ddb611a53ece94 `c7937b6b4bde2a96191dc31db913e1ab `06731164684f90f33ce4017eca9d8ec1 `f8327953a0f0b80011b939111807999a `8b76101d185700a8efed148d8722d926 `16b3c9445539e9274282a612dea354c2 `ee623aaa99b429863f89da313fffed97 `116c9be6d760b4befa6d51ce9e96604c `4d6c95b0b3ea2ddb30fdd3edf3b82391 `10eb415a232ad4be7d05c57eb850036c `627a0c45dd07150343c81d856855590e `966fe8d32b86121f8a465a21b95f7e5c `4e7b945feca199bd486653fea1d0e39c `fa16213d24273d386d22332cd01ce774 `a2679a7d860a0bfb2645809ed92ce138 `58e83fb33c120db338132d23b9112805 `c6dc6e6567d673436ac41ebc8e79a9ec `7198e10ebcf1bb88dc479b5c5b9f2c15 `a4462529ab493676987d946019a14945 `f7df7b85af230b2623d3a827b0cbddd2 `cc573488dec311655890a205aad4fb65 `7164823f504286e3a762ee612ff0a988 `da67e2f049b5b6babcf7906b85653399 `584b2b145f362098fc5fc1e634d57de5 `c6696a730f7498efb66f5ba3a8b35d08 `16fa0e4aefe18e1446bf6baefd3ba400 `6e970d0818d58ff2d50c5bf037b1a565 `0ebe78077c8b48410cf52a0bccdff866 `924727b6f380cf3cdfe5650163e92054 `26d48d68b28f927bfebad454658f9425 `bda9a5da86ec9790262e14f953bbadcb `cc1a3b2f107510ac664e491d5f2412aa `d9c6ab5c6630a4a84e242c5765103d2d `7a9609a971a8f31685e88da563eea5ce `14cf6e75aec1ead888e7101d3d94d28a `14a6d294550c9760aec57ba29682a750 `5d827a1e8ea70edb11d946b54f076cae `b9d4f73fa7ca8ef66891554b66b2cded `dc962e34780f0374b7eb3d583f6d7eb6 `de1ab82817c0fb24e591b9a89a82f736 `09677934e13a5d728f00c6ed7c8870a9 `7052598d2355984237d126afea2f6e88 `927612b57ba01ca878b2d7edce52a563 `97402287d8c6c03f0b63848e17e9d944 `62f31128a21b0e240bdb7b3d5b121c04 `54da1b916f49ef40c822fab61d37cf66 `41b811063b9425de1934e77d89118022 `37b622eaad1f79e759a722aacebf48ec `73262345214f9b7794f2cc4a612b15e8 `9baedcd033169611a42c3cfd58b3ae03 `f23ca2aa066b1ee0fa4df1f2f865be4c `3c2523e65ff953fd73579aaaf5d7ce36 `88a8e608108be939da9aab5a9a8af7d1 `2f1ec795216d5bafa33a810af3421942 `ce0aea06d44878b4a373efe090a66a62 `c0e423f9ac41cc5b265c95a3e97e3fcb `7ed1d2efa3e0f0ed6b77eb4eff3d86b3 `3811b40721f7ca651887aac4eb17f9f0 `5a765f9668608a39333fa90cf462657e `c70b78fd0b5dffcd38322355e9c2471e `229975f1e84b5088e819cd5f2dc43080 `10eb1e7dc64d8ca3dad92641dadb5de7 `49ba23148db9effdc3979aa0fe5876ea `f6dff70097776e24c2a7c9c0f2514f79 `991285e3967c3295b4ff2dcd835f7c61 `50f43b1726cf61066ef8656477b226be `eeef60efe889349870426d10edc694be `4b046ac6a4796fb1338f0481dbd4003d `b2621497b3313c97855ed951f0d9b291 `ff1441a42144a7de9a3eaf9f5e7cfea9 `5988b62a0c0785a303b77c74608e8b55 `94b85ba716dbb7c20b230e69248b8208>veindex8vgindexes5vbid3xdtypeeRadixvdnode{dNode6vac<va0{dNode6vac<va0{dNode6vac6va2{dNode6vac1vad{dNode6vac0wad1ypIxawd002dxakadxasadvaetwad1ypCxawc002xaka2xasa2vaetva4{dNode6vac0wad1yphxawd0040xaka4xasb40vaetva9{dNode6vac0wad1ypmxawd0096xaka9xasb96vaetvad{dNode6vac0wad1ypdxawd00ddxakadxasbddvaetvaa{dNode6vac0wad1yplxawd00adxakaaxasbadvaetvac{dNode6vac0wad1ypfxawc00cxakacxasacvaetwad0xawb00xaka0xasa0vaesva1{dNode6vac<va0{dNode6vac1va5{dNode6vac0wad1ypHxawf01055bxaka5xasb5bvaetwad1ypexawd0105xaka0xasb05vaetva1{dNode6vac0wad1yppxawh011687ebxaka1xasf1687ebvaetva2{dNode6vac0wad1yprxawd0127xaka2xasb27vaetva5{dNode6vac0wad1yp|xawe0158fxaka5xasc58fvaetva6{dNode6vac0wad1ypyxawc016xaka6xasa6vaetva8{dNode6vac2vab{dNode6vac0wad1ypdxawd018bxakabxasabvaetvae{dNode6vac0wad1ypWxawd018exakaexasaevaetwad0xawc018xaka8xasa8vaesva9{dNode6vac0wad1yplxawc019xaka9xasa9vaetvaa{dNode6vac0wad1ypxawe01abcxakaaxascabcvaetvac{dNode6vac2vad{dNode6vac0wad1yp_xawd01cdxakadxasadvaetvae{dNode6vac0wad1ypXxawd01cexakaexasaevaetwad0xawc01cxakacxasacvaesvab{dNode6vac0wad2ypwJxawc01bxakabxasabvaetvae{dNode6vac0wad1ypCxawc01exakaexasaevaetvad{dNode6vac0wad1ypjxawc01dxakadxasadvaet>wad0xawb01xaka1xasa1vaesva2{dNode6vac:va3{dNode6vac1va6{dNode6vac0wad1ypYxawe0236axaka6xasb6avaetwad1ypuxawc023xaka3xasa3vaetva4{dNode6vac0wad1ypGxawd0243xaka4xasb43vaetva6{dNode6vac0wad1ypuxawd0266xaka6xasb66vaetva7{dNode6vac0wad1ypuxawf027364xaka7xasd7364vaetva9{dNode6vac0wad1ypzxawf029775xaka9xasd9775vaetvac{dNode6vac0wad1ypTxawc02cxakacxasacvaetvad{dNode6vac0wad2ypsixawc02dxakadxasadvaetvae{dNode6vac0wad1ypixaw Y02ebfecc7a931dad1ec38466exakaexas Webfecc7a931dad1ec38466evaetvaa{dNode6vac0wad1yp`xawc02axakaaxasaavaetvab{dNode6vac0wad1ypRxawc02bxakabxasabvaetwad0xawb02xaka2xasa2vaesva3{dNode6vac;va0{dNode6vac2va2{dNode6vac0wad1yp|xawe0302exaka2xasb2evaetva7{dNode6vac0wad1ypXxawf03072axaka7xasc72avaetwad0xawc030xaka0xasa0vaesva3{dNode6vac1va1{dNode6vac0wad1yp|xaw Y033169611a42c3cfd58b3ae03xaka1xas V169611a42c3cfd58b3ae03vaetwad1ypYxawc033xaka3xasa3vaetva4{dNode6vac0wad1ypTxawd0345xaka4xasb45vaetva6{dNode6vac0wad1ypsxawn03668caaecbc57xaka6xasl668caaecbc57vaetva7{dNode6vac1va4{dNode6vac0wad1ypqxawe0374bxaka4xasb4bvaetwad1ypexawc037xaka7xasa7vaetva8{dNode6vac0wad1ypExawh03865b60xaka8xasf865b60vaetva9{dNode6vac1va9{dNode6vac0wad1ypwxawf03996cxaka9xasc96cvaetwad2ypZtxawc039xaka9xasa9vaetvad{dNode6vac1vac{dNode6vac0wad1ypQxawd03dcxakacxasacvaetwad1yp^xawc03dxakadxasadvaetvaa{dNode6vac0wad2ypmKxawc03axakaaxasaavaetvab{dNode6vac0wad1yp@xawc03bxakabxasabvaetvaf{dNode6vac1vab{dNode6vac0wad1ypzxaw Q03fbaddfc0fab7c76xakabxasnbaddfc0fab7c76vaetwad1yp[xawc03fxakafxasafvaetwad0xawb03xaka3xasa3vaesva4{dNode6vac:va0{dNode6vac1va5{dNode6vac0wad1ypVxawj040572a3c0xaka5xasg572a3c0vaetwad1yptxawc040xaka0xasa0vaetva2{dNode6vac0wad1ypexawg04205caxaka2xase205cavaetva3{dNode6vac0wad1ypuxawf043664xaka3xasd3664vaetva4{dNode6vac0wad1ypExawc044xaka4xasa4vaetva5{dNode6vac0wad1ypaxaw U0456231c374b09cbe4a90xaka5xas S56231c374b09cbe4a90vaetva6{dNode6vac0wad1ypNxawc046xaka6xasa6vaetva8{dNode6vac2va1{dNode6vac0wad1ypNxawg0481dbdxaka1xasd1dbdvaetva6{dNode6vac0wad1ypDxaw ^0486610d8a02cea245c13c85b6de27xaka6xas [6610d8a02cea245c13c85b6de27vaetwad0xawc048xaka8xasa8vaesva9{dNode6vac0wad1ypaxawc049xaka9xasa9vaetvad{dNode6vac0wad1ypzxawc04dxakadxasadvaetvae{dNode6vac0wad1yp]xawc04exakaexasaevaetwad2ypPwxawb04xaka4xasa4vaetva5{dNode6vac6va2{dNode6vac2va4{dNode6vac0wad1yphxawg0526476xaka4xasc476vaetvae{dNode6vac0wad1ypkxawe0526exakaexasaevaetwad0xawd0526xaka2xasb26vaesva3{dNode6vac0wad1yp@xawf05330cxaka3xasd330cvaetva5{dNode6vac0wad1ypZxawf05560dxaka5xasd560dvaetva8{dNode6vac2va4{dNode6vac0wad1ypwxawd0584xaka4xasa4vaetva6{dNode6vac0wad1ypbxaw Q05866864f7d57bee7xaka6xasn66864f7d57bee7vaetwad0xawc058xaka8xasa8vaesvaf{dNode6vac0wad1ypkxawd05fdxakafxasbfdvaetvac{dNode6vac0wad1ypTxawc05cxakacxasacvaetwad0xawb05xaka5xasa5vaesva6{dNode6vac9va0{dNode6vac0wad1ypJxawc060xaka0xasa0vaetva2{dNode6vac0wad1ypYxawc062xaka2xasa2vaetva4{dNode6vac0wad1ypXxaw `0645bdb1cdf88ec74288d503eb71839cxaka4xas ^45bdb1cdf88ec74288d503eb71839cvaetva6{dNode6vac0wad1yp}xawc066xaka6xasa6vaetva7{dNode6vac0wad1ypMxaw `06731164684f90f33ce4017eca9d8ec1xaka7xas ^731164684f90f33ce4017eca9d8ec1vaetvae{dNode6vac2vaa{dNode6vac0wad1yphxawf06eacdxakaaxascacdvaetvae{dNode6vac0wad1ypMxawd06eexakaexasaevaetwad0xawc06exakaexasaevaesvab{dNode6vac0wad1ypfxawc06bxakabxasabvaetvaf{dNode6vac0wad1ypMxawc06fxakafxasafvaetvad{dNode6vac0wad1ypAxawc06dxakadxasadvaetwad0xawb06xaka6xasa6vaesva7{dNode6vac9va1{dNode6vac3va3{dNode6vac0wad1yp@xaw \071363645a588f858b35231128c4xaka3xas Y363645a588f858b35231128c4vaetva5{dNode6vac0wad1ypUxaw V07150343c81d856855590exaka5xas S50343c81d856855590evaetva7{dNode6vac0wad1ypIxawi07170a0cexaka7xasf70a0cevaetwad0xawc071xaka1xasa1vaesva2{dNode6vac0wad1yp{xawc072xaka2xasa2vaetva3{dNode6vac1va3{dNode6vac0wad1ypGxawf07330fxaka3xasc30fvaetwad1ypYxawc073xaka3xasa3vaetva6{dNode6vac0wad1ypoxawc076xaka6xasa6vaetva8{dNode6vac0wad1ypQxawd0785xaka8xasb85vaetvaf{dNode6vac1vad{dNode6vac0wad1ypJxawd07fdxakadxasadvaetwad1ypSxawc07fxakafxasafvaetvaa{dNode6vac0wad1ypcxawc07axakaaxasaavaetvab{dNode6vac0wad1ypsxawd07bfxakabxasbbfvaetvad{dNode6vac0wad1ypwxawc07dxakadxasadvaetwad0xawb07xaka7xasa7vaesva8{dNode6vac7va0{dNode6vac0wad2ypb^xawc080xaka0xasa0vaetva1{dNode6vac0wad1ypexawd0818xaka1xasb18vaetva3{dNode6vac0wad1yphxawc083xaka3xasa3vaetva6{dNode6vac0wad1ypYxawd086bxaka6xasb6bvaetva7{dNode6vac2va2{dNode6vac0wad1yp[xawd0872xaka2xasa2vaetva7{dNode6vac0wad1ypsxaw [0877831b4c924438396760f1841xaka7xas X7831b4c924438396760f1841vaetwad1ypKxawc087xaka7xasa7vaetvab{dNode6vac0wad2ypzgxawc08bxakabxasabvaetvac{dNode6vac0wad1ypZxawd08caxakacxasbcavaetwad0xawb08xaka8xasa8vaesva9{dNode6vac7va0{dNode6vac1va1{dNode6vac0wad1ypGxawi0901979bdxaka1xasf1979bdvaetwad1ypAxawc090xaka0xasa0vaetva1{dNode6vac0wad1ypFxawg09155bfxaka1xase155bfvaetva3{dNode6vac0wad1ypyxawc093xaka3xasa3vaetva4{dNode6vac0wad1yp_xawg09417cdxaka4xase417cdvaetva6{dNode6vac3va0{dNode6vac0wad1ypTxawg09602baxaka0xasd02bavaetva7{dNode6vac0wad1ypsxaw `09677934e13a5d728f00c6ed7c8870a9xaka7xas ]77934e13a5d728f00c6ed7c8870a9vaetva9{dNode6vac0wad1yplxaw V096960e13d8578fa544536xaka9xas S960e13d8578fa544536vaetwad0xawc096xaka6xasa6vaesvad{dNode6vac0wad1ypgxawd09dbxakadxasbdbvaetvaa{dNode6vac0wad1ypxxawc09axakaaxasaavaetwad0xawb09xaka9xasa9vaesvad{dNode6vac2vae{dNode6vac0wad1yp\xawc0dexakaexasaevaetvac{dNode6vac0wad1yp@xawd0dcbxakacxasbcbvaetwad0xawb0dxakadxasadvaesvaa{dNode6vac1vae{dNode6vac0wad1ypAxawd0aeaxakaexasbeavaetwad1ypDxawb0axakaaxasaavaetvac{dNode6vac0wad1ypRxawb0cxakacxasacvaetvae{dNode6vac0wad1ypfxawd0ebexakaexascebevaet>wad<ypYY^ddflsvvv}BJNQTUZ[[``ekuzCPRZ\\_``egqvvx@DKUXZ^_r{GIO\\\^__agijjvw@EEGSUY^dfw}CCFIQ>xawa0xaka0xasa0vaetva1{dNode6vac<va0{dNode6vac9va0{dNode6vac0wad1yp`xawd100cxaka0xasb0cvaetva3{dNode6vac2va5{dNode6vac0wad1ypYxaw R103575d8a7fee19680xaka5xaso575d8a7fee19680vaetva9{dNode6vac0wad1yprxawd1039xaka9xasa9vaetwad0xawc103xaka3xasa3vaesva4{dNode6vac2va6{dNode6vac0wad1ypHxaw ]1046144ad9ee7bb96214ba7ae7516xaka6xas Z6144ad9ee7bb96214ba7ae7516vaetvab{dNode6vac0wad1ypYxawd104bxakabxasabvaetwad0xawc104xaka4xasa4vaesva6{dNode6vac0wad1ypRxaw Y1069578551d0e3c7d9275f16bxaka6xas W69578551d0e3c7d9275f16bvaetva7{dNode6vac2va5{dNode6vac0wad1ypjxawh107510acxaka5xase510acvaetva6{dNode6vac0wad1ypVxaw ]10764f0ccce42d5be8cfeac36b446xaka6xas Z64f0ccce42d5be8cfeac36b446vaetwad0xawc107xaka7xasa7vaesvaa{dNode6vac1vae{dNode6vac0wad1ypyxawd10aexakaexasaevaetwad1yp^xawc10axakaaxasaavaetvad{dNode6vac1vae{dNode6vac0wad1ypUxawd10dexakaexasaevaetwad1ypkxawc10dxakadxasadvaetvae{dNode6vac1vab{dNode6vac1vac{dNode6vac0wad1yp\xawf10ebcfxakacxasbcfvaetwad2ypTHxawd10ebxakabxasabvaetwad1ypxxawc10exakaexasaevaetvac{dNode6vac2vac{dNode6vac0wad1ypzxawd10ccxakacxasacvaetvab{dNode6vac0wad1yp}xaw Q10cbceb08c81d1760xakabxasnbceb08c81d1760vaetwad1ypqxawc10cxakacxasacvaetwad0xawb10xaka0xasa0vaesva1{dNode6vac8va1{dNode6vac0wad1ypjxawd111axaka1xasb1avaetva5{dNode6vac0wad1ypxawc115xaka5xasa5vaetva6{dNode6vac0wad1ypRxawd116cxaka6xasb6cvaetvaf{dNode6vac0wad1ypXxawd11fexakafxasbfevaetvaa{dNode6vac0wad2ypyxxawc11axakaaxasaavaetvab{dNode6vac0wad1ypoxawc11bxakabxasabvaetvad{dNode6vac0wad3yp~Xoxawc11dxakadxasadvaetvae{dNode6vac0wad1yp^xawd11eexakaexasbeevaetwad0xawb11xaka1xasa1vaesva2{dNode6vac9va0{dNode6vac0wad1ypZxawc120xaka0xasa0vaetva1{dNode6vac0wad1ypwxawc121xaka1xasa1vaetva2{dNode6vac1va1{dNode6vac0wad1yp@xaw R1221897f5837c84affxaka1xaso1897f5837c84affvaetwad1ypXxawc122xaka2xasa2vaetva7{dNode6vac0wad2ypp}xawc127xaka7xasa7vaetva9{dNode6vac2va4{dNode6vac0wad1ypJxawd1294xaka4xasa4vaetva8{dNode6vac0wad1ypGxawd1298xaka8xasa8vaetwad0xawc129xaka9xasa9vaesvae{dNode6vac0wad1yp\xawc12exakaexasaevaetvaf{dNode6vac2vaf{dNode6vac0wad1yprxawe12fffxakafxasbffvaetvae{dNode6vac0wad1yp]xawd12fexakaexasaevaetwad1yppxawc12fxakafxasafvaetvaa{dNode6vac0wad1ypFxawc12axakaaxasaavaetvad{dNode6vac0wad1ypGxawc12dxakadxasadvaetwad0xawb12xaka2xasa2vaesva3{dNode6vac7va0{dNode6vac0wad1yp@xawc130xaka0xasa0vaetva2{dNode6vac0wad1ypMxawg132740bxaka2xase2740bvaetva3{dNode6vac1va8{dNode6vac0wad1ypNxawd1338xaka8xasa8vaetwad1ypexawc133xaka3xasa3vaetva5{dNode6vac0wad1ypwxawc135xaka5xasa5vaetva6{dNode6vac0wad1ypwxawf13684dxaka6xasd684dvaetva7{dNode6vac0wad1yplxawd1373xaka7xasb73vaetvab{dNode6vac1vab{dNode6vac0wad1yprxawd13bbxakabxasabvaetwad1yprxawc13bxakabxasabvaetwad1ypaxawb13xaka3xasa3vaetva4{dNode6vac:va0{dNode6vac2va1{dNode6vac0wad1ypTxawk140132d26a2xaka1xash132d26a2vaetva5{dNode6vac0wad1ypexaw T1405cddcdeb4487c59fexaka5xas Q5cddcdeb4487c59fevaetwad1yp[xawc140xaka0xasa0vaetva1{dNode6vac0wad1ypjxawg1411afbxaka1xase11afbvaetva4{dNode6vac2va1{dNode6vac0wad1ypPxawd1441xaka1xasa1vaetva6{dNode6vac0wad1ypdxawd1446xaka6xasa6vaetwad0xawc144xaka4xasa4vaesva5{dNode6vac0wad2ypobxawc145xaka5xasa5vaetva6{dNode6vac2va4{dNode6vac0wad1ypSxawh146469edxaka4xase469edvaetvae{dNode6vac0wad1ypIxawd146exakaexasaevaetwad0xawc146xaka6xasa6vaesva9{dNode6vac0wad1yp|xawf14984axaka9xasd984avaetvad{dNode6vac0wad2yp^qxawd14dexakadxasbdevaetvae{dNode6vac0wad1ypRxawc14exakaexasaevaetvac{dNode6vac0wad1ypmxawd14cfxakacxasbcfvaetvaa{dNode6vac0wad1ypnxawc14axakaaxasaavaetwad0xawb14xaka4xasa4vaesva5{dNode6vac:va0{dNode6vac0wad1ypYxawc150xaka0xasa0vaetva1{dNode6vac0wad1yptxawg1519fbfxaka1xase19fbfvaetva2{dNode6vac0wad1ypbxawc152xaka2xasa2vaetva3{dNode6vac1va5{dNode6vac0wad1ypLxawf15357bxaka5xasc57bvaetwad1ypyxawc153xaka3xasa3vaetva6{dNode6vac0wad1ypBxaw S1568868c5ab8e839148xaka6xas Q68868c5ab8e839148vaetva7{dNode6vac0wad1ypVxaw `15700442e957951307bbcec5fff8643dxaka7xas ^700442e957951307bbcec5fff8643dvaetva9{dNode6vac0wad1yprxawf15932axaka9xasd932avaetvae{dNode6vac0wad1ypzxawc15exakaexasaevaetvaf{dNode6vac0wad1ypoxawc15fxakafxasafvaetvaa{dNode6vac0wad1ypWxaw W15afefef853a08a0804ba3axakaaxas Uafefef853a08a0804ba3avaetwad1yp\xawb15xaka5xasa5vaetva6{dNode6vac<va0{dNode6vac0wad1yp_xawc160xaka0xasa0vaetva1{dNode6vac0wad1ypGxawo1612128b3ca95a9xaka1xasm12128b3ca95a9vaetva2{dNode6vac0wad1ypXxawf16213dxaka2xasd213dvaetva3{dNode6vac0wad1ypAxaw `163beeae9620c1a6a46a38aa7ebd9663xaka3xas ^3beeae9620c1a6a46a38aa7ebd9663vaetva4{dNode6vac2va2{dNode6vac0wad1yp{xawe1642fxaka2xasb2fvaetva4{dNode6vac0wad1ypxxawg1644e8axaka4xasd4e8avaetwad0xawc164xaka4xasa4vaesva6{dNode6vac2va5{dNode6vac0wad1ypRxawi16659a5eaxaka5xasf59a5eavaetva7{dNode6vac0wad1ypaxaw V1667498626ae52ad0362e0xaka7xas S7498626ae52ad0362e0vaetwad0xawc166xaka6xasa6vaesva7{dNode6vac2vaa{dNode6vac0wad1ypRxawd167axakaaxasaavaetvae{dNode6vac0wad1ypLxawd167exakaexasaevaetwad0xawc167xaka7xasa7vaesva8{dNode6vac0wad1ypnxawk168191dcb84xaka8xasi8191dcb84vaetva9{dNode6vac0wad1ypQxawd169exaka9xasb9evaetvaa{dNode6vac0wad1yp\xawc16axakaaxasaavaetvaf{dNode6vac2vad{dNode6vac1vad{dNode6vac0wad1ypwxawe16fddxakadxasadvaetwad1ypExawd16fdxakadxasadvaetvaa{dNode6vac0wad1ypdxawd16faxakaaxasaavaetwad3ypHPVxawc16fxakafxasafvaetvad{dNode6vac0wad1ypsxawc16dxakadxasadvaetvab{dNode6vac0wad1ypPxawc16bxakabxasabvaet>wad0xawb16xaka6xasa6vaesva7{dNode6vac7va2{dNode6vac0wad2ypVLxawd1726xaka2xasb26vaetva3{dNode6vac0wad1yp\xawd1739xaka3xasb39vaetva7{dNode6vac1va9{dNode6vac0wad1yp@xaw X17794bbca56b6cdb9e20b932xaka9xas U94bbca56b6cdb9e20b932vaetwad2ypL@xawc177xaka7xasa7vaetva9{dNode6vac0wad1ypVxawd1790xaka9xasb90vaetvab{dNode6vac0wad1ypRxawc17bxakabxasabvaetvaa{dNode6vac1vab{dNode6vac0wad1ypixawf17abebxakabxascbebvaetwad1ypYxawc17axakaaxasaavaetvac{dNode6vac0wad2ypdrxawc17cxakacxasacvaetwad0xawb17xaka7xasa7vaesva8{dNode6vac;va1{dNode6vac0wad1ypJxawc181xaka1xasa1vaetva2{dNode6vac2va1{dNode6vac1va8{dNode6vac0wad1ypWxawe18218xaka8xasa8vaetwad1ypRxawd1821xaka1xasa1vaetva6{dNode6vac0wad1yp]xawd1826xaka6xasa6vaetwad0xawc182xaka2xasa2vaesva4{dNode6vac0wad1yprxawd1841xaka4xasb41vaetva5{dNode6vac4va0{dNode6vac0wad1yp_xawe18500xaka0xasb00vaetva1{dNode6vac0wad1yp[xaw W18514362a4e52376a6fecbaxaka1xas T14362a4e52376a6fecbavaetva7{dNode6vac0wad1ypOxaw X185700a8efed148d8722d926xaka7xas U700a8efed148d8722d926vaetva8{dNode6vac0wad1ypjxawf18582cxaka8xasc82cvaetwad0xawc185xaka5xasa5vaesva6{dNode6vac2va3{dNode6vac0wad1ypMxawd1863xaka3xasa3vaetva9{dNode6vac0wad1yp^xaw U186925e5de978c5f72062xaka9xas R925e5de978c5f72062vaetwad0xawc186xaka6xasa6vaesva7{dNode6vac2va2{dNode6vac0wad1ypMxawf18724dxaka2xasc24dvaetva7{dNode6vac0wad1ypGxawe1877fxaka7xasb7fvaetwad0xawc187xaka7xasa7vaesva8{dNode6vac1vac{dNode6vac0wad1ypoxawd188cxakacxasacvaetwad1ypyxawc188xaka8xasa8vaetvae{dNode6vac0wad2yp\dxawc18exakaexasaevaetvac{dNode6vac0wad1ypUxawc18cxakacxasacvaetvab{dNode6vac0wad1ypfxawc18bxakabxasabvaetvad{dNode6vac0wad1ypkxawc18dxakadxasadvaetwad0xawb18xaka8xasa8vaesva9{dNode6vac<va3{dNode6vac0wad1ypyxawd1934xaka3xasb34vaetva4{dNode6vac2va4{dNode6vac0wad1ypUxaw \19442484b3e4f47875b58b3f72b2xaka4xas Y42484b3e4f47875b58b3f72b2vaetva8{dNode6vac0wad1ypcxaw U1948795e26af2f3f8a30fxaka8xas R8795e26af2f3f8a30fvaetwad0xawc194xaka4xasa4vaesva6{dNode6vac0wad1ypwxawg1966beexaka6xase66beevaetva7{dNode6vac0wad1ypfxawd1973xaka7xasb73vaetva8{dNode6vac0wad1ypLxawc198xaka8xasa8vaetva9{dNode6vac0wad1ypWxawc199xaka9xasa9vaetvac{dNode6vac1vad{dNode6vac0wad1yp{xawd19cdxakadxasadvaetwad1ypTxawc19cxakacxasacvaetvad{dNode6vac0wad1ypNxawc19dxakadxasadvaetvae{dNode6vac1vac{dNode6vac0wad1yppxawg19ecbaaxakacxasdcbaavaetwad1yp`xawc19exakaexasaevaetvaf{dNode6vac0wad1ypyxawe19fffxakafxascfffvaetvab{dNode6vac1vab{dNode6vac0wad1ypMxawe19bbfxakabxasbbfvaetwad1ypIxawc19bxakabxasabvaetvaa{dNode6vac0wad1ypkxawc19axakaaxasaavaet>wad0xawb19xaka9xasa9vaesvae{dNode6vac0wad1ypExawb1exakaexasaevaetvaa{dNode6vac1vab{dNode6vac0wad1ypkxawd1abcxakabxasbbcvaetwad2yphjxawb1axakaaxasaavaetvab{dNode6vac2vab{dNode6vac0wad1yplxawd1bbfxakabxasbbfvaetvac{dNode6vac0wad1ypBxawc1bcxakacxasacvaetwad2ypSGxawb1bxakabxasabvaetvaf{dNode6vac1vad{dNode6vac0wad1ypxxawd1fedxakadxasadvaetwad1ypRxawc1fexakafxasbfevaetvac{dNode6vac0wad1yp]xawc1caxakacxasbcavaet>wad<yp__Yflnopv}IIJTXhtu~@ABKNPTTXYddklooFKKPQU^`ggkovyy{DFHJPggijjmmrCFGL\bemorxz}}CH>xawa1xaka1xasa1vaetva2{dNode6vac<va0{dNode6vac9va1{dNode6vac2va1{dNode6vac0wad1ypexawf20110cxaka1xasc10cvaetva9{dNode6vac0wad1ypbxawd2019xaka9xasa9vaetwad0xawc201xaka1xasa1vaesva2{dNode6vac0wad1ypHxawd2023xaka2xasb23vaetva8{dNode6vac1vaa{dNode6vac0wad1yp{xawd208axakaaxasaavaetwad1ypdxawc208xaka8xasa8vaetvaf{dNode6vac0wad1ypQxawd20faxakafxasbfavaetvae{dNode6vac0wad1ypJxawc20exakaexasaevaetvab{dNode6vac0wad2ypWRxawc20bxakabxasabvaetvad{dNode6vac0wad1ypAxawc20dxakadxasadvaetvac{dNode6vac0wad1ypHxawc20cxakacxasacvaetvaa{dNode6vac0wad1ypmxawc20axakaaxasaavaetwad0xawb20xaka0xasa0vaesva1{dNode6vac:va5{dNode6vac0wad1ypdxawh21590549xaka5xasf590549vaetva6{dNode6vac0wad1yp~xawe216dbxaka6xasc6dbvaetva7{dNode6vac3va4{dNode6vac0wad1yphxawg21741bdxaka4xasd41bdvaetva7{dNode6vac0wad1yp|xawe2177exaka7xasb7evaetva8{dNode6vac0wad1ypExawf21780fxaka8xasc80fvaetwad0xawc217xaka7xasa7vaesva8{dNode6vac2va1{dNode6vac0wad1ypWxaw ]21814165879f72529e91682ece5c6xaka1xas Z14165879f72529e91682ece5c6vaetvae{dNode6vac0wad1ypZxawd218exakaexasaevaetwad0xawc218xaka8xasa8vaesva9{dNode6vac1va8{dNode6vac0wad1ypCxawf21982fxaka8xasc82fvaetwad2ypYFxawc219xaka9xasa9vaetvab{dNode6vac0wad3ypBVwxawc21bxakabxasabvaetvad{dNode6vac1vaa{dNode6vac0wad1ypExawd21daxakaaxasaavaetwad1yp_xawc21dxakadxasadvaetvaa{dNode6vac0wad1ypTxawc21axakaaxasaavaetvaf{dNode6vac0wad1yp`xawe21fdaxakafxascfdavaetvac{dNode6vac0wad1ypoxawd21cfxakacxasbcfvaetwad0xawb21xaka1xasa1vaesva2{dNode6vac;va0{dNode6vac0wad1ypExawc220xaka0xasa0vaetva3{dNode6vac2va3{dNode6vac0wad1ypXxawg22332cdxaka3xasd32cdvaetvab{dNode6vac0wad1ypHxawe223bcxakabxasbbcvaetwad0xawc223xaka3xasa3vaesva4{dNode6vac0wad1yp[xawf22485dxaka4xasd485dvaetva5{dNode6vac0wad1ypUxawg22569afxaka5xase569afvaetva6{dNode6vac0wad1yptxawc226xaka6xasa6vaetva7{dNode6vac1va1{dNode6vac0wad1ypCxawd2271xaka1xasa1vaetwad1yp[xawc227xaka7xasa7vaetva9{dNode6vac2va9{dNode6vac0wad1ypGxaw `229975f1e84b5088e819cd5f2dc43080xaka9xas ]975f1e84b5088e819cd5f2dc43080vaetvab{dNode6vac0wad1ypjxawd229bxakabxasabvaetwad0xawc229xaka9xasa9vaesvaa{dNode6vac1vac{dNode6vac0wad1yp}xawn22adccac34be92xakacxasjccac34be92vaetwad1yp_xawd22adxakaaxasbadvaetvae{dNode6vac1vaf{dNode6vac0wad1ypCxawf22efefxakafxascfefvaetwad4yplhxzxawc22exakaexasaevaetvab{dNode6vac0wad2ypCCxawc22bxakabxasabvaetvad{dNode6vac2vaa{dNode6vac0wad1yp@xawd22daxakaaxasaavaetvad{dNode6vac0wad1ypExawd22ddxakadxasadvaetwad1ypjxawc22dxakadxasadvaetwad0xawb22xaka2xasa2vaesva3{dNode6vac8va0{dNode6vac0wad2yp^Rxawc230xaka0xasa0vaetva1{dNode6vac1va4{dNode6vac0wad1ypIxawg23148dbxaka4xasd48dbvaetwad1ypuxawc231xaka1xasa1vaetva2{dNode6vac0wad1ypTxawc232xaka2xasa2vaetva4{dNode6vac2va1{dNode6vac0wad1ypkxaw ^23419e4fc69b5b533815681c9bb1a9xaka1xas [19e4fc69b5b533815681c9bb1a9vaetva8{dNode6vac0wad1yp_xawe2348axaka8xasb8avaetwad1yp`xawc234xaka4xasa4vaetva5{dNode6vac2va4{dNode6vac0wad1ypqxaw Y23543850a2ee9fff8cd2cc53fxaka4xas V43850a2ee9fff8cd2cc53fvaetva5{dNode6vac0wad1yptxaw Z23556fcc5dbfb7b7f43fbbb61dxaka5xas W56fcc5dbfb7b7f43fbbb61dvaetwad0xawc235xaka5xasa5vaesva6{dNode6vac3va3{dNode6vac0wad1ypJxaw R23639057435ac8756axaka3xaso39057435ac8756avaetva6{dNode6vac0wad1ypYxawl236659680493xaka6xasi659680493vaetva7{dNode6vac0wad1ypjxaw Y2367372c3199c66a6420faf89xaka7xas V7372c3199c66a6420faf89vaetwad0xawc236xaka6xasa6vaesvac{dNode6vac0wad2ypJxxawc23cxakacxasacvaetvaa{dNode6vac0wad2ypfjxawc23axakaaxasaavaetwad0xawb23xaka3xasa3vaesva4{dNode6vac:va0{dNode6vac0wad2yptwxawc240xaka0xasa0vaetva1{dNode6vac0wad1ypjxawf2412aaxaka1xasd12aavaetva2{dNode6vac1va7{dNode6vac0wad1ypXxawf24273dxaka7xasc73dvaetwad1ypkxawc242xaka2xasa2vaetva3{dNode6vac0wad1ypoxawg24357fexaka3xase357fevaetva4{dNode6vac0wad1ypIxawl2446665e2fe5xaka4xasj46665e2fe5vaetva7{dNode6vac0wad1ypexawl247784b9d930xaka7xasj7784b9d930vaetva8{dNode6vac0wad1ypYxawf24809fxaka8xasd809fvaetva9{dNode6vac0wad1ypBxaw W2493aab78c26e4f2152542cxaka9xas U93aab78c26e4f2152542cvaetvaf{dNode6vac0wad1ypkxawc24fxakafxasafvaetvad{dNode6vac2vac{dNode6vac0wad1yprxawd24dcxakacxasacvaetvaf{dNode6vac0wad1ypvxawd24dfxakafxasafvaetwad1ypExawc24dxakadxasadvaetwad0xawb24xaka4xasa4vaesva5{dNode6vac8va1{dNode6vac0wad1ypJxawm251138384a0b9xaka1xask1138384a0b9vaetva2{dNode6vac2va3{dNode6vac0wad1yp~xawd2523xaka3xasa3vaetva9{dNode6vac0wad1yp[xawl2529599c8440xaka9xasi9599c8440vaetwad1yplxawc252xaka2xasa2vaetva4{dNode6vac0wad1ypkxawh25492340xaka4xasf492340vaetva6{dNode6vac0wad1ypfxawd2561xaka6xasb61vaetva7{dNode6vac0wad1ypWxawc257xaka7xasa7vaetva8{dNode6vac0wad1ypTxawc258xaka8xasa8vaetvac{dNode6vac0wad1ypqxawe25ccbxakacxascccbvaetvaa{dNode6vac0wad1ypixawc25axakaaxasaavaetwad1ypcxawb25xaka5xasa5vaetva6{dNode6vac;va1{dNode6vac0wad1ypsxawd2619xaka1xasb19vaetva2{dNode6vac0wad1yp^xawe2623dxaka2xasc23dvaetva3{dNode6vac0wad1yp^xaw T2632722300194f01e93dxaka3xas R32722300194f01e93dvaetva4{dNode6vac1va5{dNode6vac0wad1ypYxaw P2645809ed92ce138xaka5xasm5809ed92ce138vaetwad1yprxawc264xaka4xasa4vaetva5{dNode6vac0wad2yp|Bxawc265xaka5xasa5vaetva8{dNode6vac0wad1ypAxaw P268010bbebf4f579xaka8xasn8010bbebf4f579vaetvac{dNode6vac1vae{dNode6vac0wad1ypXxawd26cexakaexasaevaetwad1ypLxawc26cxakacxasacvaetvae{dNode6vac0wad1yp\xawc26exakaexasaevaetvaf{dNode6vac0wad1yp\xawd26fdxakafxasbfdvaetvab{dNode6vac0wad1ypmxawd26bcxakabxasbbcvaetvad{dNode6vac0wad3ypn_hxawc26dxakadxasadvaetwad0xawb26xaka6xasa6vaesva7{dNode6vac6va0{dNode6vac2va9{dNode6vac0wad1ypIxaw ^2709406a9bb19e8d83a78f81e36244xaka9xas [9406a9bb19e8d83a78f81e36244vaetvae{dNode6vac0wad1ypwxawd270exakaexasaevaetwad0xawc270xaka0xasa0vaesva1{dNode6vac0wad1yp~xawe2713fxaka1xasc13fvaetva2{dNode6vac0wad1yplxawf27291cxaka2xasd291cvaetva7{dNode6vac3va5{dNode6vac0wad1ypyxaw U277538367f9c8140e3a75xaka5xas R538367f9c8140e3a75vaetva6{dNode6vac0wad1yprxawl27766eadc9e2xaka6xasi66eadc9e2vaetvaf{dNode6vac0wad1yp|xawd277fxakafxasafvaetwad0xawc277xaka7xasa7vaesvae{dNode6vac0wad1ypwxawc27exakaexasaevaetvaf{dNode6vac0wad1ypyxawd27fexakafxasbfevaetwad0xawb27xaka7xasa7vaesva8{dNode6vac:va2{dNode6vac1vab{dNode6vac0wad1yp]xawg2824befxakabxascbefvaetwad1yp}xawd2824xaka2xasb24vaetva4{dNode6vac0wad1ypexawd2845xaka4xasb45vaetva6{dNode6vac0wad1ypZxawd286axaka6xasb6avaetva8{dNode6vac2va0{dNode6vac0wad1ypbxawg28808dcxaka0xasd08dcvaetva1{dNode6vac0wad1ypQxawh28811a94xaka1xase11a94vaetwad0xawc288xaka8xasa8vaesva9{dNode6vac0wad1ypMxawc289xaka9xasa9vaetvad{dNode6vac0wad1ypIxawc28dxakadxasadvaetvab{dNode6vac0wad2ypomxawc28bxakabxasabvaetvac{dNode6vac0wad1ypAxawc28cxakacxasacvaetvaf{dNode6vac1vaa{dNode6vac0wad1ypFxawd28faxakaaxasaavaetwad1yphxawc28fxakafxasafvaetvaa{dNode6vac0wad1ypmxawc28axakaaxasaavaetwad0xawb28xaka8xasa8vaesva9{dNode6vac;va1{dNode6vac0wad1ypzxawd2915xaka1xasb15vaetva2{dNode6vac1va6{dNode6vac0wad1ypwxawf29265axaka6xasc65avaetwad1ypKxawc292xaka2xasa2vaetva3{dNode6vac0wad1ypUxawc293xaka3xasa3vaetva4{dNode6vac0wad1ypnxawg294550cxaka4xase4550cvaetva6{dNode6vac2va1{dNode6vac0wad1yptxawg296318cxaka1xasc18cvaetvad{dNode6vac0wad1yp\xawe2963dxakadxasadvaetwad0xawd2963xaka6xasb63vaesva8{dNode6vac1va1{dNode6vac0wad1ypxxawm2981057642b69xaka1xasj1057642b69vaetwad1ypuxawc298xaka8xasa8vaetva9{dNode6vac1vaa{dNode6vac0wad1ypaxaw `299abcee56b05b312ed5700f686f79b8xakaaxas ]abcee56b05b312ed5700f686f79b8vaetwad1ypfxawc299xaka9xasa9vaetvab{dNode6vac0wad1ypGxawc29bxakabxasabvaetvad{dNode6vac0wad1ypAxawd29dbxakadxasbdbvaetvac{dNode6vac0wad2ypgxxawc29cxakacxasacvaetvaf{dNode6vac0wad1yprxawc29fxakafxasafvaetwad0xawb29xaka9xasa9vaesvac{dNode6vac0wad1ypHxawb2cxakacxasacvaetvae{dNode6vac0wad1ypTxawc2eaxakaexasbeavaetvad{dNode6vac0wad1ypCxawc2dexakadxasbdevaetvaa{dNode6vac0wad1ypGxawb2axakaaxasaavaetvaf{dNode6vac0wad1yp@xawc2f1xakafxasbf1vaet>wad<ypUY^_RZafluvw||}FIIJKLY[lmnuEGLMNY\eklsv~@KPQehmMPRR^^_istvwz|~LS\^abej}}CK>xawa2xaka2xasa2vaetva3{dNode6vac<va0{dNode6vac<va1{dNode6vac1va1{dNode6vac0wad1ypVxaw P301194bfeeee4377xaka1xasm194bfeeee4377vaetwad1ypdxawc301xaka1xasa1vaetva2{dNode6vac1va4{dNode6vac0wad1ypfxawf30242bxaka4xasc42bvaetwad1ypCxawc302xaka2xasa2vaetva3{dNode6vac0wad1ypQxawc303xaka3xasa3vaetva4{dNode6vac0wad1ypvxaw Y3042dad59a12e5937644f7246xaka4xas W42dad59a12e5937644f7246vaetva6{dNode6vac0wad1ypDxawg306cecbxaka6xase6cecbvaetva7{dNode6vac0wad1yppxawc307xaka7xasa7vaetva8{dNode6vac3va3{dNode6vac0wad1ypnxaw T308352b7a881add7e356xaka3xas Q352b7a881add7e356vaetva6{dNode6vac0wad1yp{xawn3086543790541cxaka6xask6543790541cvaetva9{dNode6vac0wad1yppxaw Y308961666b15aa1e57b0f9f35xaka9xas V961666b15aa1e57b0f9f35vaetwad0xawc308xaka8xasa8vaesva9{dNode6vac0wad1ypCxawc309xaka9xasa9vaetvad{dNode6vac0wad1yp]xawc30dxakadxasadvaetvae{dNode6vac0wad1yphxawe30eebxakaexasceebvaetvaa{dNode6vac0wad1ypuxawc30axakaaxasaavaetvaf{dNode6vac0wad1ypSxawe30fddxakafxascfddvaet>wad1yp^xawb30xaka0xasa0vaetva1{dNode6vac9va1{dNode6vac0wad1ypwxawf31128axaka1xasd128avaetva3{dNode6vac0wad1ypzxawf31310bxaka3xasd310bvaetva4{dNode6vac0wad1ypXxawc314xaka4xasa4vaetva5{dNode6vac0wad1ypCxaw T31500621ecd6d3917a07xaka5xas R500621ecd6d3917a07vaetva6{dNode6vac0wad1yplxawf31685exaka6xasd685evaetva8{dNode6vac0wad1yphxawc318xaka8xasa8vaetva9{dNode6vac2va5{dNode6vac0wad1yp~xawg319052bxaka5xasc52bvaetvac{dNode6vac0wad1ypcxawe3190cxakacxasacvaetwad0xawd3190xaka9xasb90vaesvab{dNode6vac0wad2yp[qxawc31bxakabxasabvaetvad{dNode6vac1vab{dNode6vac0wad1ypLxawd31dbxakabxasabvaetwad1ypexawc31dxakadxasadvaetwad0xawb31xaka1xasa1vaesva2{dNode6vac8va1{dNode6vac1va1{dNode6vac0wad1yp\xawd3211xaka1xasa1vaetwad1yp~xawc321xaka1xasa1vaetva2{dNode6vac3va2{dNode6vac0wad1ypdxaw `322264a17ef7182eb1475bd2eaebc2ebxaka2xas ]264a17ef7182eb1475bd2eaebc2ebvaetva7{dNode6vac0wad1ypmxawg3227411xaka7xasd7411vaetva8{dNode6vac0wad1ypvxawf32287exaka8xasc87evaetwad1ypzxawc322xaka2xasa2vaetva3{dNode6vac1va2{dNode6vac0wad1ypDxaw Y32320ead508346ad8fed3394dxaka2xas V20ead508346ad8fed3394dvaetwad1yplxawc323xaka3xasa3vaetva7{dNode6vac0wad1ypHxawd3270xaka7xasb70vaetva9{dNode6vac0wad1ypKxawe3295bxaka9xasc95bvaetvab{dNode6vac0wad2ypNVxawc32bxakabxasabvaetvaa{dNode6vac0wad2ypWbxawc32axakaaxasaavaetvac{dNode6vac2vaa{dNode6vac0wad1ypFxawf32cabaxakaaxascabavaetvad{dNode6vac0wad1ypgxawh32cdcee2xakadxasedcee2vaetwad0xawc32cxakacxasacvaeswad1ypHxawb32xaka2xasa2vaetva3{dNode6vac9va0{dNode6vac0wad1ypCxawh330045fexaka0xasf0045fevaetva1{dNode6vac0wad1yp[xaw W33182579cd3edd0ac6c7c44xaka1xas U182579cd3edd0ac6c7c44vaetva3{dNode6vac1va7{dNode6vac0wad1ypixaw \33371dcff207fd7d201128df2ea3xaka7xas Y71dcff207fd7d201128df2ea3vaetwad1ypkxawc333xaka3xasa3vaetva8{dNode6vac2va1{dNode6vac0wad1ypZxaw Q338132d23b9112805xaka1xasn132d23b9112805vaetva4{dNode6vac0wad1ypSxawd3384xaka4xasa4vaetwad0xawc338xaka8xasa8vaesva9{dNode6vac0wad1ypMxawf33919exaka9xasd919evaetvae{dNode6vac0wad2ypvCxawc33exakaexasaevaetvaf{dNode6vac0wad1yp@xawc33fxakafxasafvaetvac{dNode6vac0wad2yptZxawc33cxakacxasacvaetvaa{dNode6vac0wad1ypGxawc33axakaaxasaavaetwad0xawb33xaka3xasa3vaesva4{dNode6vac7va5{dNode6vac0wad1ypGxawi345200f90xaka5xasg5200f90vaetva7{dNode6vac0wad1ypqxawf34780fxaka7xasd780fvaetva8{dNode6vac2va0{dNode6vac0wad1yp~xawg348051bxaka0xasd051bvaetva5{dNode6vac0wad1yplxawe34850xaka5xasb50vaetwad0xawc348xaka8xasa8vaesva9{dNode6vac0wad1ypwxawc349xaka9xasa9vaetvad{dNode6vac1vab{dNode6vac0wad1yp`xawe34dbdxakabxasbbdvaetwad1ypoxawc34dxakadxasadvaetvab{dNode6vac0wad1yplxawd34baxakabxasbbavaetvac{dNode6vac0wad1yptxawc34cxakacxasacvaetwad0xawb34xaka4xasa4vaesva5{dNode6vac8va0{dNode6vac0wad1ypmxawc350xaka0xasa0vaetva1{dNode6vac0wad2ypvdxawc351xaka1xasa1vaetva2{dNode6vac2va0{dNode6vac0wad1yp]xaw `35200cbf0b5b45d7f5f0b343cb18868bxaka0xas ]00cbf0b5b45d7f5f0b343cb18868bvaetva8{dNode6vac0wad1ypbxaw Z352847c06e748b345e8ed0738bxaka8xas W847c06e748b345e8ed0738bvaetwad0xawc352xaka2xasa2vaesva3{dNode6vac0wad1ypzxawc353xaka3xasa3vaetva6{dNode6vac0wad1yphxawc356xaka6xasa6vaetva8{dNode6vac0wad1ypuxawh35896c1fxaka8xasf896c1fvaetvaa{dNode6vac1vaa{dNode6vac0wad1ypgxawd35aaxakaaxasaavaetwad1yp^xawc35axakaaxasaavaetvad{dNode6vac0wad1ypXxawc35dxakadxasadvaetwad1yp\xawb35xaka5xasa5vaetva6{dNode6vac7va0{dNode6vac2va6{dNode6vac0wad1ypoxaw Q3606427f835bd3ddfxaka6xasn6427f835bd3ddfvaetva8{dNode6vac0wad1ypBxawf36080bxaka8xasc80bvaetwad0xawc360xaka0xasa0vaesva2{dNode6vac1va0{dNode6vac0wad1ypbxawh362098fcxaka0xase098fcvaetwad1yp[xawc362xaka2xasa2vaetva5{dNode6vac0wad1ypdxawc365xaka5xasa5vaetvad{dNode6vac1vad{dNode6vac0wad1ypBxawd36ddxakadxasadvaetwad2ypZkxawc36dxakadxasadvaetvae{dNode6vac1vae{dNode6vac0wad1ypIxawg36eeceaxakaexasdeceavaetwad1ypsxawc36exakaexasaevaetvaa{dNode6vac0wad1yp@xawc36axakaaxasaavaetvaf{dNode6vac0wad1yp\xawd36ffxakafxasbffvaetwad0xawb36xaka6xasa6vaesva7{dNode6vac9va0{dNode6vac0wad1yp@xawe3703dxaka0xasc03dvaetva3{dNode6vac2va3{dNode6vac0wad1ypZxaw W373398d7d2c93862c5f6661xaka3xas T398d7d2c93862c5f6661vaetva7{dNode6vac0wad1ypWxawd3737xaka7xasa7vaetwad1ypAxawc373xaka3xasa3vaetva6{dNode6vac0wad1ypRxaw \3760395e8e0eb40e335b22750b68xaka6xas Z60395e8e0eb40e335b22750b68vaetva7{dNode6vac0wad1ypPxawg37781dcxaka7xase781dcvaetva9{dNode6vac2va1{dNode6vac0wad1ypxxawe37912xaka1xasb12vaetva7{dNode6vac0wad1ypYxawe3797exaka7xasb7evaetwad0xawc379xaka9xasa9vaesvaf{dNode6vac0wad3ypisIxawc37fxakafxasafvaetvad{dNode6vac0wad1yppxawc37dxakadxasadvaetvac{dNode6vac2vae{dNode6vac0wad1yp\xawe37cedxakaexasbedvaetvaf{dNode6vac0wad1ypxxawd37cfxakafxasafvaetwad0xawc37cxakacxasacvaesvab{dNode6vac0wad1ypzxawc37bxakabxasabvaetwad0xawb37xaka7xasa7vaesva8{dNode6vac8va1{dNode6vac2va1{dNode6vac0wad1ypDxawd3811xaka1xasa1vaetva2{dNode6vac0wad1ypexawe38128xaka2xasb28vaetwad0xawc381xaka1xasa1vaesva2{dNode6vac0wad1ypxawd3829xaka2xasb29vaetva3{dNode6vac0wad1ypFxaw P38322355e9c2471exaka3xasn322355e9c2471evaetva6{dNode6vac1vad{dNode6vac0wad1ypgxawe386dcxakadxasbdcvaetwad1ypXxawc386xaka6xasa6vaetva8{dNode6vac2va4{dNode6vac0wad1ypuxawg3884abcxaka4xasd4abcvaetva6{dNode6vac0wad1ypwxawg38866cexaka6xasd66cevaetwad1ypYxawc388xaka8xasa8vaetva9{dNode6vac0wad2ypNixawc389xaka9xasa9vaetvab{dNode6vac0wad1ypSxawe38bebxakabxascbebvaetvaf{dNode6vac0wad1yprxawe38fbcxakafxascfbcvaetwad0xawb38xaka8xasa8vaesva9{dNode6vac8va1{dNode6vac0wad1ypMxaw W39194824861a134567cadb8xaka1xas U194824861a134567cadb8vaetva3{dNode6vac0wad1ypBxawi3931327edxaka3xasg31327edvaetva6{dNode6vac3va5{dNode6vac0wad1ypgxawe3965fxaka5xasb5fvaetva7{dNode6vac0wad1ypKxawd3967xaka7xasa7vaetva9{dNode6vac0wad1ypdxawf39698fxaka9xasc98fvaetwad0xawc396xaka6xasa6vaesva7{dNode6vac0wad1ypIxawd3979xaka7xasb79vaetva8{dNode6vac0wad1yp\xaw Z398056eef1cf6caa90786b340axaka8xas X8056eef1cf6caa90786b340avaetva9{dNode6vac1va0{dNode6vac0wad1yp~xawe39905xaka0xasb05vaetwad2yp\Fxawc399xaka9xasa9vaetvaf{dNode6vac0wad1ypCxawc39fxakafxasafvaetvaa{dNode6vac0wad1yp~xawc39axakaaxasaavaetwad0xawb39xaka9xasa9vaesvac{dNode6vac0wad3ypvf~xawb3cxakacxasacvaetvaf{dNode6vac2vad{dNode6vac0wad1ypwxawc3fdxakadxasadvaetvac{dNode6vac0wad1ypOxawc3fcxakacxasacvaetwad1ypSxawb3fxakafxasafvaet>wad<ypUU[Qdkmnptx|}BJKKQSZZ[abcdenorAFKLXltu~ADFGH[mv@AEHHKOR_eovCJPSSS^djmqwBBCCCHP>xawa3xaka3xasa3vaetva4{dNode6vac<va0{dNode6vac:va0{dNode6vac2va2{dNode6vac0wad1ypWxawd4002xaka2xasa2vaetva3{dNode6vac0wad1ypNxawe4003dxaka3xasb3dvaetwad1ypdxawc400xaka0xasa0vaetva2{dNode6vac0wad1ypfxawh402875d2xaka2xasf2875d2vaetva3{dNode6vac1va6{dNode6vac0wad1ypexawh403679bdxaka6xase679bdvaetwad1ypXxawc403xaka3xasa3vaetva5{dNode6vac0wad1ypOxawc405xaka5xasa5vaetva7{dNode6vac1va2{dNode6vac0wad1ypDxawi40721f7caxaka2xasf21f7cavaetwad2ypgmxawc407xaka7xasa7vaetva9{dNode6vac0wad1ypPxawc409xaka9xasa9vaetvad{dNode6vac0wad1yp^xawc40dxakadxasadvaetvaa{dNode6vac0wad1ypUxawf40abeaxakaaxasdabeavaetvac{dNode6vac0wad2ypIxxawc40cxakacxasacvaetvaf{dNode6vac0wad1ypyxawd40ffxakafxasbffvaetwad1yplxawb40xaka0xasa0vaetva1{dNode6vac:va0{dNode6vac0wad1yp{xawc410xaka0xasa0vaetva2{dNode6vac0wad1ypDxawf41286exaka2xasd286evaetva3{dNode6vac0wad1ypnxaw Q4136446bebe7ffbc7xaka3xaso36446bebe7ffbc7vaetva4{dNode6vac0wad1ypzxawc414xaka4xasa4vaetva5{dNode6vac0wad2ypQTxawc415xaka5xasa5vaetva7{dNode6vac1va1{dNode6vac0wad1ypexaw P41712823a5d6002bxaka1xasm12823a5d6002bvaetwad1ypFxawc417xaka7xasa7vaetva8{dNode6vac2va7{dNode6vac0wad1ypDxaw ]418764dca70aebfc965899a3fa7e5xaka7xas Z764dca70aebfc965899a3fa7e5vaetva8{dNode6vac0wad1ypXxaw T418849e1f4200ade9535xaka8xas Q849e1f4200ade9535vaetwad1ypmxawc418xaka8xasa8vaetvae{dNode6vac1vab{dNode6vac0wad1yp[xawe41ebcxakabxasbbcvaetwad1ypTxawc41exakaexasaevaetvac{dNode6vac1vac{dNode6vac0wad1ypBxawd41ccxakacxasacvaetwad1yp`xawc41cxakacxasacvaetvab{dNode6vac0wad1ypyxawc41bxakabxasabvaetwad0xawb41xaka1xasa1vaesva2{dNode6vac7va1{dNode6vac2va4{dNode6vac0wad1ypPxawi42144a7dexaka4xasf44a7devaetva8{dNode6vac0wad1ypMxawg42182cfxaka8xasd82cfvaetwad1ypjxawc421xaka1xasa1vaetva3{dNode6vac0wad1ypBxawc423xaka3xasa3vaetva6{dNode6vac0wad1ypcxawc426xaka6xasa6vaetva9{dNode6vac0wad1ypQxaw U429863f89da313fffed97xaka9xas S9863f89da313fffed97vaetvab{dNode6vac2vac{dNode6vac0wad1ypSxawd42bcxakacxasacvaetvae{dNode6vac0wad1ypJxawd42bexakaexasaevaetwad0xawc42bxakabxasabvaesvac{dNode6vac0wad1ypAxawc42cxakacxasacvaetvaa{dNode6vac2vad{dNode6vac0wad1yp`xawd42adxakadxasadvaetvab{dNode6vac0wad1yptxawd42abxakabxasabvaetwad0xawc42axakaaxasaavaeswad1ypmxawb42xaka2xasa2vaetva3{dNode6vac:va1{dNode6vac1va8{dNode6vac3va1{dNode6vac0wad1ypgxawi431816573xaka1xase16573vaetva7{dNode6vac0wad1ypXxawh431877cexaka7xasd77cevaetvae{dNode6vac0wad1ypSxaw U4318eaa2ffbca3510c054xakaexas Qeaa2ffbca3510c054vaetwad0xawd4318xaka8xasa8vaeswad1ypSxawc431xaka1xasa1vaetva2{dNode6vac0wad1ypwxawc432xaka2xasa2vaetva3{dNode6vac0wad1ypuxawc433xaka3xasa3vaetva5{dNode6vac1va0{dNode6vac0wad1ypnxaw `43501cdf0de25278a208cbb9aad80012xaka0xas ]01cdf0de25278a208cbb9aad80012vaetwad1ypCxawc435xaka5xasa5vaetva8{dNode6vac0wad1yp`xawd4389xaka8xasb89vaetvac{dNode6vac2vaa{dNode6vac0wad1yp`xawf43caefxakaaxascaefvaetvac{dNode6vac0wad1ypaxawd43ccxakacxasacvaetwad1ypvxawc43cxakacxasacvaetvab{dNode6vac1vac{dNode6vac0wad1ypCxawd43bcxakacxasacvaetwad1ypLxawc43bxakabxasabvaetvaf{dNode6vac2vac{dNode6vac0wad1yp^xawe43fcexakacxasbcevaetvaf{dNode6vac0wad1ypIxawd43ffxakafxasafvaetwad0xawc43fxakafxasafvaesvaa{dNode6vac1vab{dNode6vac0wad1ypxxawd43abxakabxasabvaetwad1ypvxawc43axakaaxasaavaetvad{dNode6vac0wad1yp^xawc43dxakadxasadvaetwad0xawb43xaka3xasa3vaesva4{dNode6vac8va2{dNode6vac0wad1ypFxaw V44285ded812939553ef94cxaka2xas T285ded812939553ef94cvaetva3{dNode6vac0wad1ypIxawc443xaka3xasa3vaetva4{dNode6vac0wad2ypTExawc444xaka4xasa4vaetva8{dNode6vac2va3{dNode6vac0wad1ypYxawe4483bxaka3xasb3bvaetva7{dNode6vac0wad1ypAxawf44878bxaka7xasc78bvaetwad0xawc448xaka8xasa8vaesva9{dNode6vac0wad1yp}xaw Y44931bfefab991be3dd7a08b7xaka9xas W931bfefab991be3dd7a08b7vaetvad{dNode6vac2vaf{dNode6vac0wad1yp\xawe44dfdxakafxasbfdvaetvab{dNode6vac0wad2ypINxawd44dbxakabxasabvaetwad0xawc44dxakadxasadvaesvac{dNode6vac0wad1ypuxawe44cafxakacxasccafvaetvaf{dNode6vac0wad1ypXxawc44fxakafxasafvaetwad0xawb44xaka4xasa4vaesva5{dNode6vac:va0{dNode6vac0wad1ypTxawd4502xaka0xasb02vaetva1{dNode6vac0wad1ypSxawk4510813f36axaka1xasi10813f36avaetva3{dNode6vac0wad1ypKxawh45353291xaka3xasf353291vaetva4{dNode6vac3va0{dNode6vac0wad1yp`xawn4540ecaa37d0e3xaka0xask0ecaa37d0e3vaetva3{dNode6vac0wad1ypgxawe4543exaka3xasb3evaetva6{dNode6vac0wad1yphxawg454658fxaka6xasd658fvaetwad0xawc454xaka4xasa4vaesva5{dNode6vac1va5{dNode6vac0wad1ypHxawd4555xaka5xasa5vaetwad1ypHxawc455xaka5xasa5vaetva8{dNode6vac0wad1yphxawd4581xaka8xasb81vaetva9{dNode6vac0wad4ypbb~txawc459xaka9xasa9vaetvaa{dNode6vac0wad1ypcxawd45acxakaaxasbacvaetvae{dNode6vac0wad1ypZxawc45exakaexasaevaetvad{dNode6vac1vad{dNode6vac0wad1ypvxawe45dddxakadxasadvaetwad1ypUxawd45ddxakadxasbddvaetwad0xawb45xaka5xasa5vaesva6{dNode6vac:va1{dNode6vac0wad1ypLxaw `4616fbea6a6dbc1074bc3f1016bbc73bxaka1xas ^16fbea6a6dbc1074bc3f1016bbc73bvaetva2{dNode6vac0wad1ypixawg462405exaka2xase2405evaetva3{dNode6vac0wad1ypBxawc463xaka3xasa3vaetva4{dNode6vac0wad1ypMxawc464xaka4xasa4vaetva5{dNode6vac2va0{dNode6vac0wad1yp_xawh465087cfxaka0xase087cfvaetva6{dNode6vac0wad1yp]xaw T4656498e5972c6de7e3dxaka6xas Q6498e5972c6de7e3dvaetwad2yp}Vxawc465xaka5xasa5vaetva6{dNode6vac0wad2yprHxawc466xaka6xasa6vaetva7{dNode6vac0wad1yprxawe4677axaka7xasc77avaetva9{dNode6vac0wad1yp{xawe4690dxaka9xasc90dvaetvae{dNode6vac0wad1ypXxawc46exakaexasaevaetvab{dNode6vac0wad1ypGxawd46bexakabxasbbevaetwad0xawb46xaka6xasa6vaesva7{dNode6vac:va0{dNode6vac0wad1ypPxawc470xaka0xasa0vaetva2{dNode6vac0wad1ypXxawi4726484bexaka2xasg26484bevaetva3{dNode6vac2va5{dNode6vac0wad1ypLxaw ]47355cbe966a94826cbe2fbf2b355xaka5xas Z55cbe966a94826cbe2fbf2b355vaetva9{dNode6vac0wad1ypexawf47398axaka9xasc98avaetwad0xawc473xaka3xasa3vaesva4{dNode6vac0wad1ypoxawe4744exaka4xasc44evaetva5{dNode6vac0wad2yp{ixawc475xaka5xasa5vaetva6{dNode6vac0wad1ypRxawd476exaka6xasb6evaetva9{dNode6vac1va6{dNode6vac0wad1ypNxawd4796xaka6xasa6vaetwad2yp_\xawc479xaka9xasa9vaetvad{dNode6vac0wad3ypScnxawc47dxakadxasadvaetvac{dNode6vac0wad1ypXxawd47cbxakacxasbcbvaetvaf{dNode6vac0wad1ypyxawc47fxakafxasafvaetwad0xawb47xaka7xasa7vaesva8{dNode6vac9va1{dNode6vac0wad1ypIxawc481xaka1xasa1vaetva2{dNode6vac0wad3ypx^oxawc482xaka2xasa2vaetva4{dNode6vac0wad1ypfxawg48410cfxaka4xase410cfvaetva5{dNode6vac2va1{dNode6vac0wad1yp}xawf48516exaka1xasc16evaetva8{dNode6vac0wad1yp_xawd4858xaka8xasa8vaetwad0xawc485xaka5xasa5vaesva6{dNode6vac0wad1ypWxaw P486653fea1d0e39cxaka6xasn6653fea1d0e39cvaetvac{dNode6vac1vab{dNode6vac0wad1ypQxawd48cbxakabxasabvaetwad1ypCxawc48cxakacxasacvaetvab{dNode6vac0wad1ypVxawc48bxakabxasabvaetvad{dNode6vac0wad1yphxawc48dxakadxasadvaetvae{dNode6vac0wad1ypzxawd48ecxakaexasbecvaetwad0xawb48xaka8xasa8vaesva9{dNode6vac9va1{dNode6vac0wad1ypjxawc491xaka1xasa1vaetva2{dNode6vac0wad1ypkxawd4924xaka2xasb24vaetva3{dNode6vac0wad1ypqxawc493xaka3xasa3vaetva4{dNode6vac0wad1ypUxawh494557dbxaka4xasf4557dbvaetva7{dNode6vac0wad1ypQxawe4976fxaka7xasc76fvaetvae{dNode6vac2vaa{dNode6vac0wad1ypKxawd49eaxakaaxasaavaetvaf{dNode6vac0wad1ypxxawd49efxakafxasafvaetwad0xawc49exakaexasaevaesvac{dNode6vac0wad1ypLxawd49cexakacxasbcevaetvaa{dNode6vac0wad1yptxawc49axakaaxasaavaetvab{dNode6vac0wad1ypIxawd49baxakabxasbbavaetwad0xawb49xaka9xasa9vaesvaa{dNode6vac2vad{dNode6vac0wad1ypixawc4adxakadxasadvaetvaf{dNode6vac0wad1ypAxawe4afcbxakafxascfcbvaetwad2ypAhxawb4axakaaxasaavaetvad{dNode6vac0wad3ypJESxawb4dxakadxasadvaetvaf{dNode6vac1vab{dNode6vac0wad1ypPxawe4fbdcxakabxascbdcvaetwad2ypF\xawb4fxakafxasafvaetvab{dNode6vac0wad3ypP[Nxawb4bxakabxasabvaetvac{dNode6vac1vac{dNode6vac0wad1ypZxawc4ccxakacxasacvaetwad1ypgxawb4cxakacxasacvaetvae{dNode6vac0wad1ypWxawb4exakaexasaevaet>wad<ypTYT\``abcckv|QUU\ceff{{ACCGI^cckqqrsuvzDFQQTY[[_fmsx{ENPZ^_`acrz}CGHILRTdkp}}ACK>xawa4xaka4xasa4vaetva5{dNode6vac<va0{dNode6vac:va1{dNode6vac2va0{dNode6vac0wad1ypSxawd5010xaka0xasa0vaetva3{dNode6vac0wad1ypoxawg501351dxaka3xasd351dvaetwad1yp|xawc501xaka1xasa1vaetva5{dNode6vac3va5{dNode6vac0wad1ypHxawf50557bxaka5xasc57bvaetva6{dNode6vac0wad1yp_xawf50562bxaka6xasc62bvaetva9{dNode6vac0wad1ypnxawg505985axaka9xasd985avaetwad2ypYaxawc505xaka5xasa5vaetva6{dNode6vac2va1{dNode6vac0wad1yp\xawg506143cxaka1xasd143cvaetva3{dNode6vac0wad1ypHxawd5063xaka3xasa3vaetwad0xawc506xaka6xasa6vaesva8{dNode6vac1va0{dNode6vac0wad1ypJxawf5080ecxaka0xasc0ecvaetwad1yp`xawc508xaka8xasa8vaetva9{dNode6vac1va3{dNode6vac0wad1ypTxawi5093670dfxaka3xasf3670dfvaetwad1ypqxawc509xaka9xasa9vaetvae{dNode6vac0wad1ypxxawd50ebxakaexasbebvaetvad{dNode6vac0wad1ypGxawc50dxakadxasadvaetvaf{dNode6vac0wad2ypoLxawc50fxakafxasafvaetvab{dNode6vac0wad1ypgxawc50bxakabxasabvaetvac{dNode6vac0wad1ypexawc50cxakacxasacvaetwad1ypCxawb50xaka0xasa0vaetva1{dNode6vac9va2{dNode6vac0wad1ypCxawc512xaka2xasa2vaetva3{dNode6vac0wad1ypoxawd5132xaka3xasb32vaetva5{dNode6vac2va3{dNode6vac0wad1ypBxawn5153268e0cc1c1xaka3xask3268e0cc1c1vaetva7{dNode6vac0wad1yphxawd5157xaka7xasa7vaetwad0xawc515xaka5xasa5vaesva6{dNode6vac0wad1ypSxawd516axaka6xasb6avaetva7{dNode6vac0wad1ypmxawc517xaka7xasa7vaetva9{dNode6vac0wad1ypRxawe5197exaka9xasc97evaetvad{dNode6vac0wad1ypNxawd51dcxakadxasbdcvaetvae{dNode6vac2vac{dNode6vac0wad1ypZxawe51ecfxakacxasbcfvaetvad{dNode6vac0wad1yppxaw Z51edead39c0e439073986043fbxakadxas Wdead39c0e439073986043fbvaetwad0xawc51exakaexasaevaesvac{dNode6vac2vac{dNode6vac0wad1yplxawe51ccaxakacxasbcavaetvae{dNode6vac0wad1ypRxawd51cexakaexasaevaetwad0xawc51cxakacxasacvaeswad0xawb51xaka1xasa1vaesva2{dNode6vac6va1{dNode6vac1va9{dNode6vac1va9{dNode6vac0wad1ypLxawg521991exaka9xasc91evaetwad1yp[xawd5219xaka9xasa9vaetwad2yp{txawc521xaka1xasa1vaetva2{dNode6vac0wad1ypgxawc522xaka2xasa2vaetva6{dNode6vac0wad1yp^xawf52675bxaka6xasd675bvaetva7{dNode6vac3va3{dNode6vac0wad1ypxxaw P52735bbbe6ba65b0xaka3xasm35bbbe6ba65b0vaetva5{dNode6vac0wad1yp}xawf52758bxaka5xasc58bvaetva7{dNode6vac0wad1ypWxawf52779axaka7xasc79avaetwad0xawc527xaka7xasa7vaesva8{dNode6vac0wad1ypUxaw X52824555864d1106278cd1f0xaka8xas V824555864d1106278cd1f0vaetvaa{dNode6vac0wad2yp{fxawc52axakaaxasaavaetwad0xawb52xaka2xasa2vaesva3{dNode6vac7va1{dNode6vac0wad1ypTxawc531xaka1xasa1vaetva2{dNode6vac0wad1ypqxawc532xaka2xasa2vaetva3{dNode6vac0wad1yp]xawd5339xaka3xasb39vaetva5{dNode6vac0wad1ypcxawc535xaka5xasa5vaetva6{dNode6vac0wad1ypoxawc536xaka6xasa6vaetva8{dNode6vac1vae{dNode6vac0wad1yprxawd538exakaexasaevaetwad1ypFxawc538xaka8xasa8vaetvae{dNode6vac0wad1ypwxawd53ecxakaexasbecvaetwad0xawb53xaka3xasa3vaesva4{dNode6vac8va1{dNode6vac0wad1ypaxawd5412xaka1xasb12vaetva3{dNode6vac0wad1ypHxawd5433xaka3xasb33vaetva4{dNode6vac0wad1ypWxawf54475cxaka4xasd475cvaetva7{dNode6vac0wad1ypXxawi54780edcbxaka7xasg780edcbvaetva9{dNode6vac2va3{dNode6vac0wad1ypPxawg5493b4dxaka3xasd3b4dvaetva5{dNode6vac0wad1ypmxawd5495xaka5xasa5vaetwad0xawc549xaka9xasa9vaesvaf{dNode6vac1vaf{dNode6vac0wad1yp`xawd54ffxakafxasafvaetwad2ypwoxawc54fxakafxasafvaetvae{dNode6vac0wad1ypDxawc54exakaexasaevaetvad{dNode6vac0wad1ypxxawd54daxakadxasbdavaetwad0xawb54xaka4xasa4vaesva5{dNode6vac8va0{dNode6vac0wad1ypJxaw `550becdd08d00fb1e7fd00c2adc3d3d6xaka0xas ^0becdd08d00fb1e7fd00c2adc3d3d6vaetva1{dNode6vac0wad1yphxawf55188axaka1xasd188avaetva2{dNode6vac1va6{dNode6vac0wad1ypAxawf552660xaka6xasc660vaetwad1ypCxawc552xaka2xasa2vaetva8{dNode6vac2va3{dNode6vac0wad1ypVxawo5583eeb6eabbd51xaka3xasl3eeb6eabbd51vaetva8{dNode6vac0wad1ypOxaw T55885067fee629287e8axaka8xas Q85067fee629287e8avaetwad0xawc558xaka8xasa8vaesva9{dNode6vac0wad1ypmxawd5595xaka9xasb95vaetvad{dNode6vac0wad1ypIxawc55dxakadxasadvaetvac{dNode6vac0wad1yptxawc55cxakacxasacvaetvab{dNode6vac0wad1ypMxawe55badxakabxascbadvaetwad2ypWQxawb55xaka5xasa5vaetva6{dNode6vac8va1{dNode6vac1va3{dNode6vac0wad1ypSxaw ^56132638912a1ca54fcf7cd38b8e23xaka3xas [32638912a1ca54fcf7cd38b8e23vaetwad1ypWxawc561xaka1xasa1vaetva2{dNode6vac0wad1yphxawc562xaka2xasa2vaetva3{dNode6vac1va8{dNode6vac0wad1ypnxawg563864axaka8xasd864avaetwad1yplxawc563xaka3xasa3vaetva5{dNode6vac0wad1ypexawc565xaka5xasa5vaetvaf{dNode6vac0wad1ypExawc56fxakafxasafvaetvab{dNode6vac0wad1yprxawc56bxakabxasabvaetvae{dNode6vac0wad1ypyxawc56exakaexasaevaetvad{dNode6vac0wad1ypKxawc56dxakadxasadvaetwad0xawb56xaka6xasa6vaesva7{dNode6vac<va0{dNode6vac0wad1yptxawh570599cfxaka0xasf0599cfvaetva1{dNode6vac0wad1ypKxaw ]5711303378bd333ddb611a53ece94xaka1xas [11303378bd333ddb611a53ece94vaetva3{dNode6vac0wad1yp_xaw ^573488dec311655890a205aad4fb65xaka3xas \3488dec311655890a205aad4fb65vaetva4{dNode6vac2va2{dNode6vac0wad1yp~xawd5742xaka2xasa2vaetva3{dNode6vac0wad1ypTxaw U5743226af94c1efaaa4a7xaka3xas R3226af94c1efaaa4a7vaetwad0xawc574xaka4xasa4vaesva5{dNode6vac2va6{dNode6vac0wad1yptxawd5756xaka6xasa6vaetva8{dNode6vac0wad1ypyxawd5758xaka8xasa8vaetwad0xawc575xaka5xasa5vaesva6{dNode6vac2va5{dNode6vac0wad1ypkxawj5765103d2dxaka5xasg5103d2dvaetva8{dNode6vac0wad1yp}xawf57684cxaka8xasc84cvaetwad0xawc576xaka6xasa6vaesva7{dNode6vac0wad1ypexawd5777xaka7xasb77vaetva8{dNode6vac0wad1yp_xawe5785bxaka8xasc85bvaetva9{dNode6vac0wad1ypRxawc579xaka9xasa9vaetvaa{dNode6vac0wad3yplP|xawc57axakaaxasaavaetvad{dNode6vac2vad{dNode6vac0wad1yplxawe57ddfxakadxasbdfvaetvae{dNode6vac0wad1ypbxawd57dexakaexasaevaetwad0xawc57dxakadxasadvaesvab{dNode6vac0wad1ypvxawc57bxakabxasabvaetvae{dNode6vac1vab{dNode6vac0wad1ypTxawd57ebxakabxasabvaetwad1yplxawc57exakaexasaevaetvac{dNode6vac0wad1ypNxawd57ccxakacxasbccvaet>wad1ypvxawb57xaka7xasa7vaetva8{dNode6vac9va1{dNode6vac1va6{dNode6vac0wad1ypKxawe5816exaka6xasb6evaetwad1ypExawc581xaka1xasa1vaetva2{dNode6vac2va4{dNode6vac0wad1ypwxawd5824xaka4xasa4vaetva6{dNode6vac0wad1ypDxaw Y582642d9cbe500f018afab341xaka6xas V642d9cbe500f018afab341vaetwad1ypCxawc582xaka2xasa2vaetva3{dNode6vac0wad1ypqxawc583xaka3xasa3vaetva4{dNode6vac0wad1ypbxawd584bxaka4xasb4bvaetva6{dNode6vac2va0{dNode6vac0wad1ypsxawe5860bxaka0xasb0bvaetva4{dNode6vac0wad1ypOxawg58646cexaka4xasd46cevaetwad2ypknxawc586xaka6xasa6vaetva7{dNode6vac2va1{dNode6vac0wad1ypyxawg58712faxaka1xasd12favaetva6{dNode6vac0wad1ypIxawf5876eaxaka6xasc6eavaetwad0xawc587xaka7xasa7vaesvac{dNode6vac0wad1ypUxawe58cbexakacxasccbevaetvaf{dNode6vac1vaf{dNode6vac0wad1ypexawd58ffxakafxasafvaetwad1ypMxawc58fxakafxasafvaetvae{dNode6vac0wad2ypHZxawc58exakaexasaevaetwad0xawb58xaka8xasa8vaesva9{dNode6vac<va0{dNode6vac0wad1yp^xawc590xaka0xasa0vaetva1{dNode6vac0wad1ypUxaw `5912529cfd6ce14c5ede5c6c83dae7e8xaka1xas ^12529cfd6ce14c5ede5c6c83dae7e8vaetva3{dNode6vac0wad1ypAxawe5931fxaka3xasc31fvaetva4{dNode6vac0wad1ypZxaw W5945ece02fdc55d6cbcbc38xaka4xas U45ece02fdc55d6cbcbc38vaetva5{dNode6vac1va5{dNode6vac0wad1yp~xawd5955xaka5xasa5vaetwad1ypXxawc595xaka5xasa5vaetva7{dNode6vac0wad1ypFxawc597xaka7xasa7vaetva8{dNode6vac0wad1ypQxawd5988xaka8xasb88vaetva9{dNode6vac0wad1yphxaw V5998989255253e15ccc1f6xaka9xas T98989255253e15ccc1f6vaetvab{dNode6vac1vac{dNode6vac0wad1ypVxawd59bcxakacxasacvaetwad1yp_xawc59bxakabxasabvaetvaa{dNode6vac1vad{dNode6vac0wad1ypYxawe59adcxakadxasbdcvaetwad1yp@xawc59axakaaxasaavaetvae{dNode6vac0wad1ypzxawc59exakaexasaevaetvad{dNode6vac0wad1ypFxawc59dxakadxasadvaet>wad0xawb59xaka9xasa9vaesvae{dNode6vac0wad1ypVxawf5eebdfxakaexaseeebdfvaetvaa{dNode6vac0wad2yp^Exawb5axakaaxasaavaetvab{dNode6vac2vaa{dNode6vac0wad1ypyxawe5badfxakaaxascadfvaetvab{dNode6vac0wad1ypWxawc5bbxakabxasabvaetwad2ypvsxawb5bxakabxasabvaetvad{dNode6vac0wad1ypoxawb5dxakadxasadvaet>wad<ypUY`ddfnpv||}}~~PTUUUV^acktt@GKZ_psstyAEPV\_fow{|CGP\p{}EEEHV\\abbeijklwBFP>xawa5xaka5xasa5vaetva6{dNode6vac<va0{dNode6vac<va0{dNode6vac0wad1ypBxawf60076cxaka0xasd076cvaetva1{dNode6vac0wad1ypmxawc601xaka1xasa1vaetva2{dNode6vac0wad1ypExawc602xaka2xasa2vaetva4{dNode6vac0wad2ypNTxawc604xaka4xasa4vaetva5{dNode6vac0wad2ypiPxawc605xaka5xasa5vaetva6{dNode6vac0wad1ypyxawi6065960ebxaka6xasg65960ebvaetva7{dNode6vac0wad1ypFxawc607xaka7xasa7vaetva8{dNode6vac2va1{dNode6vac0wad1ypxawh608108bexaka1xase108bevaetva6{dNode6vac0wad1ypFxawl60865046ff05xaka6xasi65046ff05vaetwad0xawc608xaka8xasa8vaesva9{dNode6vac2va3{dNode6vac0wad1ypaxawe6093exaka3xasb3evaetva8{dNode6vac0wad1ypBxawl6098086e255fxaka8xasi8086e255fvaetwad0xawc609xaka9xasa9vaesvae{dNode6vac2vac{dNode6vac0wad1ypGxawd60ecxakacxasacvaetvaf{dNode6vac0wad1ypMxawe60efexakafxasbfevaetwad1yp_xawc60exakaexasaevaetvaf{dNode6vac0wad1ypkxawc60fxakafxasafvaetvaa{dNode6vac0wad1ypQxawd60adxakaaxasbadvaetvad{dNode6vac1vac{dNode6vac0wad1ypuxawd60dcxakacxasacvaetwad1yp`xawc60dxakadxasadvaet>wad0xawb60xaka0xasa0vaesva1{dNode6vac<va0{dNode6vac0wad1ypLxawg61066efxaka0xase066efvaetva1{dNode6vac0wad1ypoxawh61173291xaka1xasf173291vaetva5{dNode6vac0wad1ypkxawe615dbxaka5xasc5dbvaetva6{dNode6vac0wad1ypxxawc616xaka6xasa6vaetva7{dNode6vac0wad2ypvxawc617xaka7xasa7vaetva8{dNode6vac2va2{dNode6vac0wad1ypyxawf61827exaka2xasc27evaetva3{dNode6vac0wad1ypfxawg61831fdxaka3xasd31fdvaetwad0xawc618xaka8xasa8vaesva9{dNode6vac2va3{dNode6vac0wad1ypxxawd6193xaka3xasa3vaetva4{dNode6vac0wad1ypZxawe6194cxaka4xasb4cvaetwad0xawc619xaka9xasa9vaesvac{dNode6vac2vac{dNode6vac0wad1yp_xawg61ccffdxakacxasdcffdvaetvae{dNode6vac0wad1ypCxawd61cexakaexasaevaetwad2yp^nxawc61cxakacxasacvaetvab{dNode6vac0wad1ypgxawc61bxakabxasabvaetvad{dNode6vac0wad2ypPxxawc61dxakadxasadvaetvae{dNode6vac1vac{dNode6vac0wad1ypyxawe61ecbxakacxasbcbvaetwad1yprxawc61exakaexasaevaetvaf{dNode6vac1vad{dNode6vac0wad1yp]xawd61fdxakadxasadvaetwad1yp[xawc61fxakafxasafvaet>wad2ypwKxawb61xaka1xasa1vaetva2{dNode6vac<va1{dNode6vac0wad1ypfxaw S6217243f3c387ea18b7xaka1xas Q17243f3c387ea18b7vaetva2{dNode6vac0wad1ypzxawc622xaka2xasa2vaetva3{dNode6vac0wad2ypOQxawc623xaka3xasa3vaetva4{dNode6vac0wad1ypxawf62477exaka4xasd477evaetva5{dNode6vac0wad1yplxawc625xaka5xasa5vaetva6{dNode6vac1va8{dNode6vac0wad1yp|xawg62680eaxaka8xasd80eavaetwad1ypSxawc626xaka6xasa6vaetva7{dNode6vac0wad1ypUxawd627axaka7xasb7avaetva8{dNode6vac0wad1yp{xawc628xaka8xasa8vaetvac{dNode6vac1vab{dNode6vac0wad1ypuxawd62cbxakabxasabvaetwad1ypWxawc62cxakacxasacvaetvad{dNode6vac0wad2ypMrxawc62dxakadxasadvaetvab{dNode6vac0wad1ypTxawc62bxakabxasabvaetvaf{dNode6vac0wad2yp[wxawc62fxakafxasafvaetvaa{dNode6vac0wad1ypQxawc62axakaaxasaavaet>wad1ypAxawb62xaka2xasa2vaetva3{dNode6vac7va2{dNode6vac2va4{dNode6vac0wad1ypTxawd6324xaka4xasa4vaetva9{dNode6vac0wad1ypRxawg6329ecbxaka9xasd9ecbvaetwad0xawc632xaka2xasa2vaesva4{dNode6vac0wad1ypbxawc634xaka4xasa4vaetva5{dNode6vac0wad1ypgxawd6357xaka5xasb57vaetva7{dNode6vac0wad1ypXxawc637xaka7xasa7vaetva8{dNode6vac0wad1yp{xawc638xaka8xasa8vaetva9{dNode6vac2va4{dNode6vac0wad1ypQxawm639481524ee80xaka4xasj481524ee80vaetva7{dNode6vac0wad1ypAxaw R63976e9eec38cab0f5xaka7xaso76e9eec38cab0f5vaetwad0xawc639xaka9xasa9vaesvae{dNode6vac0wad1ypwxawc63exakaexasaevaetwad1ypIxawb63xaka3xasa3vaetva4{dNode6vac:va0{dNode6vac0wad1yplxawg640616fxaka0xase0616fvaetva1{dNode6vac0wad2ypikxawc641xaka1xasa1vaetva2{dNode6vac0wad1yppxawd6425xaka2xasb25vaetva5{dNode6vac0wad1yp~xawd6458xaka5xasb58vaetva7{dNode6vac0wad2ypg@xawc647xaka7xasa7vaetva9{dNode6vac2va0{dNode6vac0wad1ypPxawd6490xaka0xasa0vaetvaf{dNode6vac0wad1yptxawd649fxakafxasafvaetwad0xawc649xaka9xasa9vaesvaa{dNode6vac0wad3ypRjGxawc64axakaaxasaavaetvac{dNode6vac1vad{dNode6vac0wad1ypOxawg64cdfccxakadxasddfccvaetwad1ypYxawc64cxakacxasacvaetvad{dNode6vac0wad3yprvHxawc64dxakadxasadvaetvab{dNode6vac0wad1ypUxawd64bdxakabxasbbdvaetwad0xawb64xaka4xasa4vaesva5{dNode6vac7va1{dNode6vac2va2{dNode6vac0wad1yp`xawh65124517xaka2xase24517vaetva8{dNode6vac0wad1ypDxaw R651887aac4eb17f9f0xaka8xaso887aac4eb17f9f0vaetwad0xawc651xaka1xasa1vaesva3{dNode6vac0wad1ypcxawe6532exaka3xasc32evaetva4{dNode6vac0wad1ypexawi65453a1aexaka4xasg453a1aevaetva6{dNode6vac1va7{dNode6vac0wad1yp[xawd6567xaka7xasa7vaetwad1yprxawc656xaka6xasa6vaetva7{dNode6vac0wad1yp@xawc657xaka7xasa7vaetvae{dNode6vac0wad2ypORxawc65exakaexasaevaetvaf{dNode6vac0wad1yp~xawd65ffxakafxasbffvaetwad0xawb65xaka5xasa5vaesva6{dNode6vac8va3{dNode6vac2va0{dNode6vac0wad1ypkxawe6630axaka0xasb0avaetva9{dNode6vac0wad1ypQxawd6639xaka9xasa9vaetwad0xawc663xaka3xasa3vaesva4{dNode6vac0wad1ypjxawc664xaka4xasa4vaetva7{dNode6vac0wad1ypaxawd6670xaka7xasb70vaetva8{dNode6vac0wad1yppxaw Q66891554b66b2cdedxaka8xaso891554b66b2cdedvaetva9{dNode6vac0wad1ypExawf66950bxaka9xasd950bvaetvad{dNode6vac1vab{dNode6vac0wad1yp^xawd66dbxakabxasabvaetwad2yp|Yxawc66dxakadxasadvaetvaa{dNode6vac0wad2ypEAxawc66axakaaxasaavaetvaf{dNode6vac0wad1ypxxawc66fxakafxasafvaetwad2ypCxxawb66xaka6xasa6vaetva7{dNode6vac9va0{dNode6vac0wad1ypbxawg670744bxaka0xase0744bvaetva1{dNode6vac0wad1ypbxawc671xaka1xasa1vaetva3{dNode6vac0wad1yp[xawh673436acxaka3xasf3436acvaetva5{dNode6vac0wad1ypoxaw T6752dfce5a0235354070xaka5xas R52dfce5a0235354070vaetva6{dNode6vac0wad1yp^xawd6761xaka6xasb61vaetvac{dNode6vac0wad1yp^xawc67cxakacxasacvaetvaf{dNode6vac1vac{dNode6vac2vac{dNode6vac0wad1ypgxaw R67fccabee27a6e99cdxakacxasncabee27a6e99cdvaetvaa{dNode6vac0wad1ypCxawe67fcaxakaaxasaavaetwad0xawd67fcxakacxasacvaeswad3ypklxxawc67fxakafxasafvaetvab{dNode6vac0wad1ypHxawc67bxakabxasabvaetvae{dNode6vac0wad2ypgaxawc67exakaexasaevaetwad0xawb67xaka7xasa7vaesva8{dNode6vac7va2{dNode6vac0wad1ypjxawl68210e6fad4fxaka2xasj210e6fad4fvaetva3{dNode6vac0wad1ypLxawd6833xaka3xasb33vaetva7{dNode6vac1va2{dNode6vac0wad1yp~xawh687271a1xaka2xase271a1vaetwad1ypNxawc687xaka7xasa7vaetva8{dNode6vac0wad1yp~xawg68862cbxaka8xase862cbvaetvad{dNode6vac0wad1ypExawd68dfxakadxasbdfvaetvab{dNode6vac1vae{dNode6vac0wad1ypPxawd68bexakaexasaevaetwad1yphxawc68bxakabxasabvaetvaa{dNode6vac0wad1yptxawc68axakaaxasaavaetwad1ypGxawb68xaka8xasa8vaetva9{dNode6vac9va1{dNode6vac0wad1yphxaw Y691013bfe66dd46ded85a98edxaka1xas W1013bfe66dd46ded85a98edvaetva2{dNode6vac2va0{dNode6vac0wad1ypGxawg6920edcxaka0xasd0edcvaetva4{dNode6vac0wad1ypRxawf69248bxaka4xasc48bvaetwad0xawc692xaka2xasa2vaesva4{dNode6vac0wad1ypUxawf69458bxaka4xasd458bvaetva7{dNode6vac0wad1ypLxawd6978xaka7xasb78vaetva8{dNode6vac0wad1yp[xawe698cfxaka8xasc8cfvaetvab{dNode6vac2vad{dNode6vac0wad1yp^xawd69bdxakadxasadvaetvae{dNode6vac0wad1yp`xawe69beaxakaexasbeavaetwad0xawc69bxakabxasabvaesvaf{dNode6vac1vac{dNode6vac0wad1ypmxawd69fcxakacxasacvaetwad1yp{xawc69fxakafxasafvaetvaa{dNode6vac0wad1ypvxawo69afdbadc1e76b6xakaaxasmafdbadc1e76b6vaetvae{dNode6vac0wad1ypjxawc69exakaexasaevaetwad0xawb69xaka9xasa9vaesvaf{dNode6vac1vab{dNode6vac0wad1ypQxawd6fbfxakabxasbbfvaetwad1ypXxawb6fxakafxasafvaetvac{dNode6vac0wad1yptxawb6cxakacxasacvaetvae{dNode6vac0wad1ypexawb6exakaexasaevaet>wad<ypRSYQRRS_enuv}GKYY[[\^dkmmy{@AKRbbekosuuyyzzQTWYY[krsvCENRRRexx@AHLRRS[admnqqCN>xawa6xaka6xasa6vaetva7{dNode6vac<va0{dNode6vac9va0{dNode6vac0wad1ypJxaw [70097776e24c2a7c9c0f2514f79xaka0xas Y097776e24c2a7c9c0f2514f79vaetva2{dNode6vac0wad1ypuxawe7027exaka2xasc27evaetva3{dNode6vac0wad1yppxawc703xaka3xasa3vaetva4{dNode6vac0wad1ypYxawd7043xaka4xasb43vaetva5{dNode6vac0wad1yptxaw `7052598d2355984237d126afea2f6e88xaka5xas ^52598d2355984237d126afea2f6e88vaetva6{dNode6vac0wad1ypYxawd706cxaka6xasb6cvaetvaf{dNode6vac0wad2ypSBxawc70fxakafxasafvaetvad{dNode6vac0wad1ypqxawd70dexakadxasbdevaetvae{dNode6vac0wad1ypoxawe70edbxakaexascedbvaetwad0xawb70xaka0xasa0vaesva1{dNode6vac9va0{dNode6vac0wad1ypmxawe7101dxaka0xasc01dvaetva2{dNode6vac0wad1ypaxawc712xaka2xasa2vaetva5{dNode6vac0wad1ypqxawc715xaka5xasa5vaetva6{dNode6vac2va2{dNode6vac0wad1ypExawf71627exaka2xasc27evaetva4{dNode6vac0wad1yp`xaw `7164823f504286e3a762ee612ff0a988xaka4xas ]4823f504286e3a762ee612ff0a988vaetwad1ypRxawc716xaka6xasa6vaetva9{dNode6vac3va3{dNode6vac0wad1ypNxaw T7193badc746d52b4173fxaka3xas Q3badc746d52b4173fvaetva8{dNode6vac0wad1yp\xawd7198xaka8xasa8vaetva9{dNode6vac0wad1ypnxawd7199xaka9xasa9vaetwad0xawc719xaka9xasa9vaesvad{dNode6vac0wad2ypJOxawc71dxakadxasadvaetvae{dNode6vac2vae{dNode6vac0wad1ypSxawd71eexakaexasaevaetvaf{dNode6vac0wad1ypyxawd71efxakafxasafvaetwad0xawc71exakaexasaevaesvac{dNode6vac0wad1ypZxawd71cfxakacxasbcfvaetvaf{dNode6vac0wad1ypmxawd71fdxakafxasbfdvaetwad0xawb71xaka1xasa1vaesva2{dNode6vac7va0{dNode6vac2va6{dNode6vac0wad1ypFxawd7206xaka6xasa6vaetva8{dNode6vac0wad1ypXxawe7208fxaka8xasb8fvaetwad1ypTxawc720xaka0xasa0vaetva1{dNode6vac1va1{dNode6vac0wad1yp]xaw Y72110575c78aeb979170212b8xaka1xas V10575c78aeb979170212b8vaetwad1ypPxawc721xaka1xasa1vaetva2{dNode6vac0wad2ypbzxawc722xaka2xasa2vaetva4{dNode6vac2va7{dNode6vac0wad1ypAxaw S724742c4ee0960d8d40xaka7xas P742c4ee0960d8d40vaetva9{dNode6vac0wad1ypmxaw `7249710187cc2d983709e044dbc78d9dxaka9xas ]9710187cc2d983709e044dbc78d9dvaetwad1ypfxawc724xaka4xasa4vaetva6{dNode6vac0wad1yp_xawf72643dxaka6xasd643dvaetvad{dNode6vac0wad1ypZxawd72dfxakadxasbdfvaetvac{dNode6vac0wad1yphxawc72cxakacxasacvaetwad0xawb72xaka2xasa2vaesva3{dNode6vac8va0{dNode6vac0wad1ypcxawc730xaka0xasa0vaetva2{dNode6vac2va6{dNode6vac0wad1yp{xaw `73262345214f9b7794f2cc4a612b15e8xaka6xas ]62345214f9b7794f2cc4a612b15e8vaetva7{dNode6vac0wad1ypPxaw `73279888a8fe482c836fb19ca23318dcxaka7xas ]79888a8fe482c836fb19ca23318dcvaetwad0xawc732xaka2xasa2vaesva4{dNode6vac0wad1ypBxaw ^734259dfb9addebe2b226d96b4f744xaka4xas \4259dfb9addebe2b226d96b4f744vaetva5{dNode6vac0wad1yp~xaw P73579aaaf5d7ce36xaka5xasn579aaaf5d7ce36vaetva9{dNode6vac2va6{dNode6vac0wad1ypGxawd7396xaka6xasa6vaetva8{dNode6vac0wad1ypoxawf73985axaka8xasc85avaetwad0xawc739xaka9xasa9vaesvab{dNode6vac0wad1yp_xawc73bxakabxasabvaetvad{dNode6vac0wad1yp^xawc73dxakadxasadvaetvaf{dNode6vac0wad1yppxawd73faxakafxasbfavaetwad0xawb73xaka3xasa3vaesva4{dNode6vac7va4{dNode6vac0wad1yp]xaw `744554499cb7880086fbd9b1f080e7e1xaka4xas ^4554499cb7880086fbd9b1f080e7e1vaetva5{dNode6vac0wad1ypJxawc745xaka5xasa5vaetva6{dNode6vac2va0{dNode6vac0wad1ypQxawf74608exaka0xasc08evaetva2{dNode6vac0wad1ypOxawd7462xaka2xasa2vaetwad0xawc746xaka6xasa6vaesva7{dNode6vac0wad1ypQxawg74705adxaka7xase705advaetva8{dNode6vac0wad1yp`xawf74826exaka8xasd826evaetva9{dNode6vac3va1{dNode6vac0wad1ypIxawe7491exaka1xasb1evaetva3{dNode6vac0wad1ypZxawe74933xaka3xasb33vaetva8{dNode6vac0wad1ypcxaw V7498efb66f5ba3a8b35d08xaka8xas S8efb66f5ba3a8b35d08vaetwad0xawc749xaka9xasa9vaesvad{dNode6vac0wad1ypIxawc74dxakadxasadvaetwad0xawb74xaka4xasa4vaesva5{dNode6vac8va0{dNode6vac0wad1ypOxawc750xaka0xasa0vaetva4{dNode6vac1va6{dNode6vac0wad1ypxawk75465416b86xaka6xash65416b86vaetwad1yp_xawc754xaka4xasa4vaetva5{dNode6vac0wad1yp{xawc755xaka5xasa5vaetva9{dNode6vac0wad1ypzxawc759xaka9xasa9vaetvab{dNode6vac0wad1ypNxawf75bdaaxakabxasdbdaavaetvad{dNode6vac0wad1ypixawc75dxakadxasadvaetvae{dNode6vac0wad1yp~xawc75exakaexasaevaetvaa{dNode6vac1vae{dNode6vac0wad1ypmxawe75aecxakaexasbecvaetwad1ypExawc75axakaaxasaavaetwad0xawb75xaka5xasa5vaesva6{dNode6vac8va0{dNode6vac1va4{dNode6vac0wad1yppxawg7604edfxaka4xasd4edfvaetwad1ypRxawc760xaka0xasa0vaetva1{dNode6vac0wad1ypOxawf76101dxaka1xasd101dvaetva2{dNode6vac0wad1ypVxawe7621dxaka2xasc21dvaetva5{dNode6vac0wad2ypUExawc765xaka5xasa5vaetva6{dNode6vac3va4{dNode6vac0wad1ypFxawd7664xaka4xasa4vaetva7{dNode6vac0wad1ypFxaw Q76672d3de4dc9a8edxaka7xasn72d3de4dc9a8edvaetva9{dNode6vac0wad1ypgxawd7669xaka9xasa9vaetwad0xawc766xaka6xasa6vaesva8{dNode6vac0wad1ypPxawh768585daxaka8xasf8585davaetvae{dNode6vac1vaf{dNode6vac0wad1ypNxawd76efxakafxasafvaetwad1yp}xawc76exakaexasaevaetvaa{dNode6vac0wad1yp`xawc76axakaaxasaavaetwad0xawb76xaka6xasa6vaesva7{dNode6vac<va0{dNode6vac0wad1ypYxawf77021axaka0xasd021avaetva3{dNode6vac2va0{dNode6vac0wad1yp{xawd7730xaka0xasa0vaetva7{dNode6vac0wad1ypPxawd7737xaka7xasa7vaetwad0xawc773xaka3xasa3vaesva4{dNode6vac0wad1ypXxawc774xaka4xasa4vaetva5{dNode6vac0wad1ypqxaw `775894425f5a7436f56fc5a3b4a2cfaaxaka5xas ^5894425f5a7436f56fc5a3b4a2cfaavaetva8{dNode6vac0wad1ypixawd7787xaka8xasb87vaetva9{dNode6vac1vae{dNode6vac0wad1ypTxawd779exakaexasaevaetwad1ypWxawc779xaka9xasa9vaetvaf{dNode6vac0wad1ypXxawc77fxakafxasafvaetvad{dNode6vac1vae{dNode6vac0wad1yp_xawe77deexakaexasbeevaetwad2ypNyxawc77dxakadxasadvaetvab{dNode6vac0wad1ypfxawd77bexakabxasbbevaetvaa{dNode6vac0wad1ypwxawc77axakaaxasaavaetvae{dNode6vac0wad1ypCxawd77ebxakaexasbebvaetvac{dNode6vac0wad1ypQxawc77cxakacxasacvaet>wad0xawb77xaka7xasa7vaesva8{dNode6vac:va0{dNode6vac1va7{dNode6vac0wad1ypfxawf78077cxaka7xasc77cvaetwad1ypXxawc780xaka0xasa0vaetva2{dNode6vac1va9{dNode6vac0wad1ypNxawf78292dxaka9xasc92dvaetwad1ypBxawc782xaka2xasa2vaetva4{dNode6vac0wad1ypjxaw Y784707b1d2c702fbeba080e86xaka4xas W4707b1d2c702fbeba080e86vaetva5{dNode6vac1va3{dNode6vac0wad1ypZxawd7853xaka3xasa3vaetwad1ypXxawc785xaka5xasa5vaetva7{dNode6vac0wad1ypjxawg787810dxaka7xase7810dvaetva8{dNode6vac1va4{dNode6vac0wad1ypWxawd7884xaka4xasa4vaetwad1ypoxawc788xaka8xasa8vaetvab{dNode6vac1vae{dNode6vac0wad1ypwxawd78bexakaexasaevaetwad1ypTxawc78bxakabxasabvaetvac{dNode6vac3vac{dNode6vac0wad1ypFxawe78ccaxakacxasbcavaetvad{dNode6vac0wad1yprxawd78cdxakadxasadvaetvae{dNode6vac0wad1ypqxawe78cedxakaexasbedvaetwad0xawc78cxakacxasacvaesvad{dNode6vac0wad1ypnxawd78daxakadxasbdavaetvaf{dNode6vac1vad{dNode6vac0wad1ypFxawd78fdxakadxasadvaetwad1ypCxawc78fxakafxasafvaetwad0xawb78xaka8xasa8vaesva9{dNode6vac9va0{dNode6vac0wad1ypaxawd7906xaka0xasb06vaetva1{dNode6vac0wad1ypnxawc791xaka1xasa1vaetva4{dNode6vac0wad1ypaxawc794xaka4xasa4vaetva5{dNode6vac2va2{dNode6vac0wad1yp@xaw [795216d5bafa33a810af3421942xaka2xas X216d5bafa33a810af3421942vaetva3{dNode6vac0wad1yppxawh79534a52xaka3xase34a52vaetwad0xawc795xaka5xasa5vaesva6{dNode6vac0wad1yp[xaw W796161d82c9ac438ebab5d2xaka6xas U6161d82c9ac438ebab5d2vaetva9{dNode6vac1va8{dNode6vac0wad1ypfxawd7998xaka8xasa8vaetwad1ypcxawc799xaka9xasa9vaetvad{dNode6vac0wad1ypGxawc79dxakadxasadvaetvae{dNode6vac0wad3yp@Ozxawc79exakaexasaevaetvaa{dNode6vac0wad1yp[xawc79axakaaxasaavaetwad1ypIxawb79xaka9xasa9vaetvaf{dNode6vac3vad{dNode6vac0wad1ypTxawe7fdedxakadxascdedvaetvac{dNode6vac0wad1yp`xawf7fcfaaxakacxasdcfaavaetvaa{dNode6vac0wad1ypsxawc7faxakaaxasaavaetwad1ypTxawb7fxakafxasafvaetvac{dNode6vac1vac{dNode6vac0wad2ypWPxawc7ccxakacxasacvaetwad1ypBxawb7cxakacxasacvaetvab{dNode6vac1va6{dNode6vac0wad1yp@xawc7b6xaka6xasa6vaetwad1yp^xawb7bxakabxasabvaetvad{dNode6vac0wad1yp}xawd7deaxakadxascdeavaetvae{dNode6vac1vad{dNode6vac0wad1ypCxawc7edxakadxasadvaetwad1ypkxawb7exakaexasaevaetvaa{dNode6vac0wad1yplxawb7axakaaxasaavaet>wad<ypSSXR\^_abcgruGJKQTTWY\\bbgmACMP`lprwxyEFHKK[`ghjkrswyMPjjorrtuz|AIJTVWY^pqqwHKPR>xawa7xaka7xasa7vaetva8{dNode6vac<va0{dNode6vac9va0{dNode6vac0wad1yprxawe8008dxaka0xasc08dvaetva1{dNode6vac1va0{dNode6vac0wad1ypWxaw Y8010960eb17e368a6fdd5a51bxaka0xas V0960eb17e368a6fdd5a51bvaetwad2yp}dxawc801xaka1xasa1vaetva4{dNode6vac1va5{dNode6vac0wad1ypKxaw Z80454654d990d9c07d33d35d1cxaka5xas W54654d990d9c07d33d35d1cvaetwad2ypEXxawc804xaka4xasa4vaetva5{dNode6vac0wad1ypxaw ]805472f79f0b558f75b90b5e7b4eexaka5xas [5472f79f0b558f75b90b5e7b4eevaetva7{dNode6vac2va3{dNode6vac0wad1ypyxawf80739axaka3xasc39avaetva7{dNode6vac0wad1ypJxawd8077xaka7xasa7vaetwad0xawc807xaka7xasa7vaesva9{dNode6vac0wad1ypaxawg809925exaka9xase9925evaetvaa{dNode6vac0wad1ypcxawc80axakaaxasaavaetvac{dNode6vac1vae{dNode6vac0wad1ypGxawe80cedxakaexasbedvaetwad1ypixawc80cxakacxasacvaetvaf{dNode6vac0wad1ypqxawc80fxakafxasafvaetwad0xawb80xaka0xasa0vaesva1{dNode6vac:va0{dNode6vac0wad1yp]xawg810068exaka0xase0068evaetva1{dNode6vac0wad1ypyxawg811063bxaka1xase1063bvaetva3{dNode6vac1va4{dNode6vac0wad1ypoxawe8134axaka4xasb4avaetwad2yp{dxawc813xaka3xasa3vaetva4{dNode6vac0wad1yprxawi8141ddcc1xaka4xasg41ddcc1vaetva5{dNode6vac0wad1ypbxawh815273cdxaka5xasf5273cdvaetva8{dNode6vac2va3{dNode6vac0wad1ypDxawg8183cedxaka3xasd3cedvaetva7{dNode6vac0wad1ypxaw X8187985725963b8bfc67004dxaka7xas U7985725963b8bfc67004dvaetwad1ypzxawc818xaka8xasa8vaetva9{dNode6vac3va4{dNode6vac0wad1yp_xawd8194xaka4xasa4vaetva6{dNode6vac0wad1ypjxaw \819656f68b87a91c53afbd441fecxaka6xas Y656f68b87a91c53afbd441fecvaetvaa{dNode6vac0wad1yp^xawd819axakaaxasaavaetwad0xawc819xaka9xasa9vaesvad{dNode6vac0wad1ypdxawc81dxakadxasadvaetvac{dNode6vac0wad1yptxawc81cxakacxasacvaetvaf{dNode6vac0wad1ypNxawe81facxakafxascfacvaetwad0xawb81xaka1xasa1vaesva2{dNode6vac;va0{dNode6vac1va8{dNode6vac0wad1yp`xawi82088739dxaka8xase8739dvaetwad1ypRxawd8208xaka0xasb08vaetva1{dNode6vac0wad1ypaxawf82160dxaka1xasd160dvaetva2{dNode6vac1va0{dNode6vac0wad1ypIxawj822028dd9exaka0xasg028dd9evaetwad1ypxxawc822xaka2xasa2vaetva3{dNode6vac1va9{dNode6vac1va1{dNode6vac0wad1ypSxawe82391xaka1xasa1vaetwad1ypixawd8239xaka9xasa9vaetwad2yp^xxawc823xaka3xasa3vaetva5{dNode6vac0wad1ypXxawc825xaka5xasa5vaetva7{dNode6vac1vad{dNode6vac0wad1ypuxawe827dexakadxasbdevaetwad2yp^oxawc827xaka7xasa7vaetva8{dNode6vac2va0{dNode6vac0wad1ypnxawf82809axaka0xasc09avaetva1{dNode6vac0wad1yprxaw [82817c0fb24e591b9a89a82f736xaka1xas X17c0fb24e591b9a89a82f736vaetwad0xawc828xaka8xasa8vaesvaa{dNode6vac0wad2ypExawc82axakaaxasaavaetvae{dNode6vac0wad1ypTxawe82efaxakaexascefavaetvaf{dNode6vac0wad1ypoxawf82fdfcxakafxasdfdfcvaetvab{dNode6vac0wad1ypExawc82bxakabxasabvaetwad0xawb82xaka2xasa2vaesva3{dNode6vac8va0{dNode6vac1va4{dNode6vac0wad1ypexawe8304bxaka4xasb4bvaetwad1ypPxawc830xaka0xasa0vaetva2{dNode6vac1va2{dNode6vac0wad1ypWxaw [8322cdbda7a21e4aecbe04462b7xaka2xas X2cdbda7a21e4aecbe04462b7vaetwad1ypUxawc832xaka2xasa2vaetva4{dNode6vac2va0{dNode6vac0wad1ypdxawd8340xaka0xasa0vaetva5{dNode6vac0wad1ypgxawe83454xaka5xasb54vaetwad0xawc834xaka4xasa4vaesva5{dNode6vac0wad1ypKxawc835xaka5xasa5vaetvab{dNode6vac0wad1ypaxawc83bxakabxasabvaetvad{dNode6vac1vaa{dNode6vac0wad1ypLxawe83daaxakaaxasbaavaetwad1ypdxawc83dxakadxasadvaetvaa{dNode6vac1vae{dNode6vac0wad1ypZxawd83aexakaexasaevaetwad1ypmxawc83axakaaxasaavaetvaf{dNode6vac2vaa{dNode6vac0wad1ypOxawd83faxakaaxasaavaetvab{dNode6vac0wad1ypZxawd83fbxakabxasabvaetwad0xawc83fxakafxasafvaeswad0xawb83xaka3xasa3vaesva4{dNode6vac9va0{dNode6vac0wad1ypQxawc840xaka0xasa0vaetva1{dNode6vac0wad1ypGxawd8412xaka1xasb12vaetva3{dNode6vac0wad1yp~xawc843xaka3xasa3vaetva4{dNode6vac0wad1ypzxawc844xaka4xasa4vaetva5{dNode6vac0wad1ypzxawc845xaka5xasa5vaetva6{dNode6vac0wad1yphxaw R8460150068ba0c6743xaka6xas P60150068ba0c6743vaetva7{dNode6vac0wad1ypVxawc847xaka7xasa7vaetvab{dNode6vac0wad1yplxawc84bxakabxasabvaetvae{dNode6vac0wad1ypkxawc84exakaexasaevaetwad1yplxawb84xaka4xasa4vaetva5{dNode6vac9va0{dNode6vac0wad1ypTxawg850036cxaka0xase0036cvaetva3{dNode6vac2va4{dNode6vac0wad1ypyxawd8534xaka4xasa4vaetvac{dNode6vac0wad1ypKxawf853cacxakacxasccacvaetwad0xawc853xaka3xasa3vaesva4{dNode6vac0wad1ypRxaw W854414033d5cec1470774eexaka4xas U4414033d5cec1470774eevaetva6{dNode6vac0wad1ypaxawh85653399xaka6xasf653399vaetva7{dNode6vac0wad1yp{xawc857xaka7xasa7vaetvac{dNode6vac1vae{dNode6vac0wad1yp[xawf85cedexakaexascedevaetwad1ypUxawc85cxakacxasacvaetvaf{dNode6vac3vad{dNode6vac0wad1ypVxawd85fdxakadxasadvaetvab{dNode6vac0wad1ypJxawd85fbxakabxasabvaetvac{dNode6vac0wad1ypUxawf85fcadxakacxasccadvaetwad0xawc85fxakafxasafvaesvaa{dNode6vac0wad1yp^xawd85afxakaaxasbafvaetvab{dNode6vac0wad1ypRxawd85baxakabxasbbavaetwad0xawb85xaka5xasa5vaesva6{dNode6vac<va0{dNode6vac2va4{dNode6vac0wad1yp|xaw T8604342a925b2dc60737xaka4xas Q4342a925b2dc60737vaetva8{dNode6vac0wad1ypJxawd8608xaka8xasa8vaetwad1ypYxawc860xaka0xasa0vaetva1{dNode6vac1va2{dNode6vac0wad1ypVxawf86121fxaka2xasc21fvaetwad1ypLxawc861xaka1xasa1vaetva5{dNode6vac1va6{dNode6vac0wad1ypLxawm8656477b226bexaka6xasj6477b226bevaetwad1yp}xawc865xaka5xasa5vaetva6{dNode6vac1va4{dNode6vac0wad1ypMxawh866426cexaka4xase426cevaetwad2ypSfxawc866xaka6xasa6vaetva7{dNode6vac0wad1ypRxawe8673dxaka7xasc73dvaetva8{dNode6vac0wad1ypcxaw \86812812dab8d39db9aaefe94a78xaka8xas Z812812dab8d39db9aaefe94a78vaetva9{dNode6vac0wad1ypoxawc869xaka9xasa9vaetvac{dNode6vac0wad1yp{xawd86caxakacxasbcavaetvaf{dNode6vac0wad1ypPxawc86fxakafxasafvaetvaa{dNode6vac0wad1ypTxawd86aexakaaxasbaevaetvae{dNode6vac0wad1ypixawd86ecxakaexasbecvaetvab{dNode6vac0wad1ypCxawc86bxakabxasabvaet>wad1ypOxawb86xaka6xasa6vaetva7{dNode6vac7va1{dNode6vac0wad1ypfxaw X871950ebc36c415a53630477xaka1xas V1950ebc36c415a53630477vaetva5{dNode6vac0wad1ypzxawc875xaka5xasa5vaetva7{dNode6vac0wad1ypTxawd8773xaka7xasb73vaetva9{dNode6vac0wad1ypHxaw Y8797ace2fb37402ea6a09d126xaka9xas W97ace2fb37402ea6a09d126vaetvab{dNode6vac0wad1ypNxawd87bexakabxasbbevaetvaa{dNode6vac0wad1ypUxawc87axakaaxasaavaetvae{dNode6vac0wad1yprxawc87exakaexasaevaetwad0xawb87xaka7xasa7vaesva8{dNode6vac:va0{dNode6vac0wad1yp{xawc880xaka0xasa0vaetva5{dNode6vac0wad1yptxawc885xaka5xasa5vaetva6{dNode6vac0wad2ypVfxawc886xaka6xasa6vaetva8{dNode6vac2va2{dNode6vac0wad1ypkxawh888217abxaka2xase217abvaetva3{dNode6vac0wad1ypxxawd8883xaka3xasa3vaetwad3yp}umxawc888xaka8xasa8vaetva9{dNode6vac1va3{dNode6vac0wad1ypMxaw W889349870426d10edc694bexaka3xas T349870426d10edc694bevaetwad1ypMxawc889xaka9xasa9vaetvac{dNode6vac0wad1ypQxawc88cxakacxasacvaetvab{dNode6vac0wad1yplxawd88bdxakabxasbbdvaetvaf{dNode6vac0wad2ypFLxawc88fxakafxasafvaetvaa{dNode6vac0wad2ypFxawc88axakaaxasaavaetvad{dNode6vac2vac{dNode6vac0wad1yp\xawd88dcxakacxasacvaetvaa{dNode6vac0wad1yplxawd88daxakaaxasaavaetwad0xawc88dxakadxasadvaeswad0xawb88xaka8xasa8vaesva9{dNode6vac;va1{dNode6vac2va1{dNode6vac0wad1ypyxawh89118022xaka1xase18022vaetva4{dNode6vac0wad1ypvxawf89149axaka4xasc49avaetwad1ypaxawc891xaka1xasa1vaetva2{dNode6vac0wad1yplxawc892xaka2xasa2vaetva5{dNode6vac1va2{dNode6vac0wad1ypzxaw R8952efd1be1881e651xaka2xaso2efd1be1881e651vaetwad1ypDxawc895xaka5xasa5vaetva6{dNode6vac0wad1ypNxawd8964xaka6xasb64vaetva7{dNode6vac0wad1yprxawc897xaka7xasa7vaetva8{dNode6vac0wad1ypixawd898dxaka8xasb8dvaetvab{dNode6vac0wad1yp^xawd89bexakabxasbbevaetvae{dNode6vac1vae{dNode6vac0wad1ypvxawd89eexakaexasaevaetwad2yppQxawc89exakaexasaevaetvac{dNode6vac0wad1ypQxawe89cecxakacxasccecvaetvad{dNode6vac0wad1ypoxawc89dxakadxasadvaetvaa{dNode6vac0wad1ypoxawf89abaaxakaaxasdabaavaetwad0xawb89xaka9xasa9vaesvaf{dNode6vac0wad1ypUxawb8fxakafxasafvaetvaa{dNode6vac2va1{dNode6vac0wad1yp~xawc8a1xaka1xasa1vaetvac{dNode6vac0wad1ypwxawd8accxakacxasbccvaetwad1yprxawb8axakaaxasaavaetvad{dNode6vac1va7{dNode6vac0wad1yplxawf8d7cafxaka7xasd7cafvaetwad1ypRxawb8dxakadxasadvaetvac{dNode6vac0wad1yp{xawc8ccxakacxasbccvaetvab{dNode6vac0wad1ypOxawb8bxakabxasabvaet>wad<ypSSUQSYY`cfgkvx{|JJJX\\``fhimNNPPP_bcekqqrsDEEFOTTX[_|@AIMOR_eemtyEEGVV[flopHQ>xawa8xaka8xasa8vaetva9{dNode6vac<va0{dNode6vac:va0{dNode6vac1va6{dNode6vac0wad1ypYxawh90061486xaka6xase61486vaetwad1ypCxawc900xaka0xasa0vaetva4{dNode6vac2va5{dNode6vac0wad1yp_xawe90451xaka5xasb51vaetvab{dNode6vac0wad1ypIxawd904bxakabxasabvaetwad0xawc904xaka4xasa4vaesva5{dNode6vac0wad1ypwxaw ]9052870778e14ab4a5acbc8c24af4xaka5xas [52870778e14ab4a5acbc8c24af4vaetva6{dNode6vac1va6{dNode6vac0wad1ypxxawd9066xaka6xasa6vaetwad1yp_xawc906xaka6xasa6vaetva7{dNode6vac0wad1ypsxawc907xaka7xasa7vaetvaf{dNode6vac0wad1yp_xawc90fxakafxasafvaetvab{dNode6vac1vac{dNode6vac0wad1ypTxawe90bcexakacxasbcevaetwad1ypKxawc90bxakabxasabvaetvad{dNode6vac0wad1ypsxawc90dxakadxasadvaetvac{dNode6vac0wad1ypwxawc90cxakacxasacvaetvaa{dNode6vac0wad1yp{xawc90axakaaxasaavaetwad0xawb90xaka0xasa0vaesva1{dNode6vac;va0{dNode6vac0wad1yptxawh910197ccxaka0xasf0197ccvaetva2{dNode6vac0wad1ypTxawc912xaka2xasa2vaetva3{dNode6vac1va3{dNode6vac0wad1ypwxawe9133fxaka3xasb3fvaetwad1ypLxawc913xaka3xasa3vaetva4{dNode6vac0wad1ypGxawc914xaka4xasa4vaetva5{dNode6vac0wad1ypSxawc915xaka5xasa5vaetva6{dNode6vac1vab{dNode6vac0wad1ypVxawf916bdaxakabxascbdavaetwad1ypxxawc916xaka6xasa6vaetva7{dNode6vac0wad1ypOxawc917xaka7xasa7vaetvaa{dNode6vac0wad1ypcxawc91axakaaxasaavaetvae{dNode6vac0wad1ypbxawc91exakaexasaevaetvac{dNode6vac0wad3ypnqvxawc91cxakacxasacvaetvaf{dNode6vac0wad1yp[xawd91fexakafxasbfevaetwad0xawb91xaka1xasa1vaesva2{dNode6vac7va2{dNode6vac0wad1ypmxawe922ccxaka2xasc2ccvaetva4{dNode6vac0wad1ypgxaw `924727b6f380cf3cdfe5650163e92054xaka4xas ^4727b6f380cf3cdfe5650163e92054vaetva6{dNode6vac2va4{dNode6vac0wad1ypHxawm92641dadb5de7xaka4xasj41dadb5de7vaetva8{dNode6vac0wad1ypixawi9268739fexaka8xasf8739fevaetwad0xawc926xaka6xasa6vaesva7{dNode6vac2va4{dNode6vac0wad1yp^xawd9274xaka4xasa4vaetva6{dNode6vac0wad1ypuxaw `927612b57ba01ca878b2d7edce52a563xaka6xas ]612b57ba01ca878b2d7edce52a563vaetwad1yphxawc927xaka7xasa7vaetvab{dNode6vac0wad1ypbxawc92bxakabxasabvaetvad{dNode6vac0wad1ypcxawc92dxakadxasadvaetvac{dNode6vac0wad1ypxxawd92cbxakacxasbcbvaetwad2yp~Exawb92xaka2xasa2vaetva3{dNode6vac:va0{dNode6vac0wad1ypOxawf93015dxaka0xasd015dvaetva1{dNode6vac1vab{dNode6vac0wad1ypfxawd931bxakabxasabvaetwad1ypCxawc931xaka1xasa1vaetva2{dNode6vac0wad1ypmxawc932xaka2xasa2vaetva3{dNode6vac2va0{dNode6vac0wad1ypTxawe9330dxaka0xasb0dvaetva5{dNode6vac0wad1yp\xaw `9335522f4c8dbc7256a42a091e6e00bcxaka5xas ]5522f4c8dbc7256a42a091e6e00bcvaetwad0xawc933xaka3xasa3vaesva4{dNode6vac1va0{dNode6vac0wad1ypxxawg9340deaxaka0xasd0deavaetwad1ypExawc934xaka4xasa4vaetva5{dNode6vac2va5{dNode6vac0wad1yp_xaw ]9355781403b92e844de8568863ae8xaka5xas Z5781403b92e844de8568863ae8vaetva8{dNode6vac0wad1ypWxawd9358xaka8xasa8vaetwad1yp[xawc935xaka5xasa5vaetva6{dNode6vac0wad1ypgxawc936xaka6xasa6vaetva7{dNode6vac0wad1ypFxawd937axaka7xasb7avaetva8{dNode6vac1va4{dNode6vac0wad1ypFxawf93847bxaka4xasc47bvaetwad1ypwxawc938xaka8xasa8vaetva9{dNode6vac0wad1ypxawc939xaka9xasa9vaetwad0xawb93xaka3xasa3vaesva4{dNode6vac<va1{dNode6vac1va5{dNode6vac0wad1ypBxawf94159exaka5xasc59evaetwad1ypExawc941xaka1xasa1vaetva2{dNode6vac2va0{dNode6vac0wad1ypZxawn94208817b83468xaka0xask08817b83468vaetva5{dNode6vac0wad2yphyxawd9425xaka5xasa5vaetwad0xawc942xaka2xasa2vaesva3{dNode6vac0wad1ypxxawc943xaka3xasa3vaetva4{dNode6vac0wad1ypPxaw [9445539e9274282a612dea354c2xaka4xas Y45539e9274282a612dea354c2vaetva5{dNode6vac1va0{dNode6vac0wad1ypbxawh945088dexaka0xase088devaetwad1ypWxawc945xaka5xasa5vaetva6{dNode6vac0wad1ypoxawc946xaka6xasa6vaetva9{dNode6vac1va9{dNode6vac0wad1ypnxawg949924cxaka9xasd924cvaetwad1yp]xawc949xaka9xasa9vaetvab{dNode6vac0wad2ypSRxawc94bxakabxasabvaetvac{dNode6vac2vab{dNode6vac0wad1ypbxawe94cbdxakabxasbbdvaetvaf{dNode6vac0wad1yp~xawf94cfccxakafxascfccvaetwad1yp\xawc94cxakacxasacvaetvaa{dNode6vac0wad1ypbxawc94axakaaxasaavaetvae{dNode6vac1vae{dNode6vac0wad1yp^xawd94eexakaexasaevaetwad1ypuxawc94exakaexasaevaetvad{dNode6vac0wad1ypmxawc94dxakadxasadvaet>wad0xawb94xaka4xasa4vaesva5{dNode6vac:va0{dNode6vac2va4{dNode6vac0wad1ypExawd9504xaka4xasa4vaetva9{dNode6vac0wad1ypzxawe9509bxaka9xasb9bvaetwad1yp^xawc950xaka0xasa0vaetva3{dNode6vac0wad2ypN~xawc953xaka3xasa3vaetva4{dNode6vac0wad1yp`xawf95426bxaka4xasd426bvaetva6{dNode6vac0wad2ypgsxawc956xaka6xasa6vaetva8{dNode6vac2va0{dNode6vac0wad1ypOxaw ^9580308938069159c5afc55b2f3b96xaka0xas [0308938069159c5afc55b2f3b96vaetva7{dNode6vac0wad1ypxawd9587xaka7xasa7vaetwad0xawc958xaka8xasa8vaesvae{dNode6vac0wad1ypdxawc95exakaexasaevaetvab{dNode6vac1vac{dNode6vac0wad1ypAxawe95bcdxakacxasbcdvaetwad1ypSxawc95bxakabxasabvaetvaf{dNode6vac1vae{dNode6vac0wad1ypXxawd95fexakaexasaevaetwad1ypVxawc95fxakafxasafvaetvac{dNode6vac0wad2ypkExawc95cxakacxasacvaetvaa{dNode6vac0wad2yp\Bxawc95axakaaxasaavaetwad0xawb95xaka5xasa5vaesva6{dNode6vac<va0{dNode6vac0wad1yplxawd9609xaka0xasb09vaetva1{dNode6vac3va0{dNode6vac0wad1ypixawi96106314exaka0xasf06314evaetva2{dNode6vac0wad1yppxaw S96120606c8dda06458fxaka2xas P20606c8dda06458fvaetva9{dNode6vac0wad1ypLxawg96191dcxaka9xasd91dcvaetwad0xawc961xaka1xasa1vaesva2{dNode6vac1va3{dNode6vac0wad1yp^xawd9623xaka3xasa3vaetwad1ypqxawc962xaka2xasa2vaetva3{dNode6vac0wad1ypZxawg963035fxaka3xase3035fvaetva4{dNode6vac0wad1yp|xaw ^9649eca3dfbd356527ffc88f1dcb94xaka4xas \49eca3dfbd356527ffc88f1dcb94vaetva5{dNode6vac0wad1ypNxawc965xaka5xasa5vaetva6{dNode6vac3va0{dNode6vac0wad1ypRxawf96604cxaka0xasc04cvaetva8{dNode6vac0wad1ypExaw Z9668608a39333fa90cf462657exaka8xas W8608a39333fa90cf462657evaetvaf{dNode6vac0wad1ypVxawe966fexakafxasbfevaetwad1ypTxawc966xaka6xasa6vaetva7{dNode6vac0wad1yp\xawd9679xaka7xasb79vaetva8{dNode6vac0wad1ypxaw P96813587fe3a6049xaka8xasn813587fe3a6049vaetva9{dNode6vac0wad1yp_xawe9693axaka9xasc93avaetvad{dNode6vac0wad1ypsxawc96dxakadxasadvaetvac{dNode6vac0wad1yp@xawe96cfexakacxasccfevaetvaa{dNode6vac0wad1yplxawc96axakaaxasaavaet>wad0xawb96xaka6xasa6vaesva7{dNode6vac;va0{dNode6vac0wad3yp~mexawc970xaka0xasa0vaetva1{dNode6vac2va0{dNode6vac0wad1yp\xawe9710cxaka0xasb0cvaetva9{dNode6vac0wad1ypxxawd9719xaka9xasa9vaetwad1yplxawc971xaka1xasa1vaetva3{dNode6vac0wad1ypYxawf97311cxaka3xasd311cvaetva4{dNode6vac0wad1ypvxaw `97402287d8c6c03f0b63848e17e9d944xaka4xas ^402287d8c6c03f0b63848e17e9d944vaetva6{dNode6vac3va0{dNode6vac0wad1ypnxaw T9760aec57ba29682a750xaka0xas Q0aec57ba29682a750vaetva7{dNode6vac0wad1yp@xawd9767xaka7xasa7vaetva9{dNode6vac0wad1ypLxawf97692cxaka9xasc92cvaetwad0xawc976xaka6xasa6vaesva9{dNode6vac1va0{dNode6vac0wad1ypixaw T9790262e14f953bbadcbxaka0xas Q0262e14f953bbadcbvaetwad1ypZxawc979xaka9xasa9vaetvaf{dNode6vac0wad2ypTuxawc97fxakafxasafvaetvac{dNode6vac0wad1ypIxawd97cdxakacxasbcdvaetvaa{dNode6vac0wad1ypnxawc97axakaaxasaavaetvae{dNode6vac1vaa{dNode6vac0wad1ypvxawe97eadxakaaxasbadvaetwad1ypBxawc97exakaexasaevaetvab{dNode6vac0wad1yp^xawd97bcxakabxasbbcvaetwad0xawb97xaka7xasa7vaesva8{dNode6vac6va0{dNode6vac1va5{dNode6vac0wad1ypVxaw Z9805919736382ffea5a9554c02xaka5xas W5919736382ffea5a9554c02vaetwad1ypIxawc980xaka0xasa0vaetva4{dNode6vac0wad1yp]xawc984xaka4xasa4vaetva5{dNode6vac0wad1ypfxawd9856xaka5xasb56vaetva6{dNode6vac0wad1ypKxawc986xaka6xasa6vaetvab{dNode6vac0wad1ypQxawd98bbxakabxasbbbvaetvac{dNode6vac0wad1yplxawc98cxakacxasacvaetwad0xawb98xaka8xasa8vaesva9{dNode6vac<va0{dNode6vac0wad1ypuxawc990xaka0xasa0vaetva1{dNode6vac0wad1ypKxawg991285exaka1xase1285evaetva2{dNode6vac2va7{dNode6vac0wad1yptxawd9927xaka7xasa7vaetvaa{dNode6vac0wad1ypfxawd992axakaaxasaavaetwad0xawc992xaka2xasa2vaesva3{dNode6vac0wad1ypMxawd993exaka3xasb3evaetva4{dNode6vac0wad1yp[xawc994xaka4xasa4vaetva7{dNode6vac1vaa{dNode6vac0wad1ypwxawf997accxakaaxascaccvaetwad1yplxawc997xaka7xasa7vaetva8{dNode6vac2va0{dNode6vac0wad1yp\xawf99806cxaka0xasc06cvaetvae{dNode6vac0wad1ypJxawf998edaxakaexascedavaetwad0xawc998xaka8xasa8vaesva9{dNode6vac0wad1ypWxawc999xaka9xasa9vaetvaa{dNode6vac0wad1ypaxawc99axakaaxasaavaetvac{dNode6vac0wad3ypc{Hxawc99cxakacxasacvaetvab{dNode6vac0wad2ypxQxawc99bxakabxasabvaetvaf{dNode6vac0wad1yp[xawc99fxakafxasafvaet>wad0xawb99xaka9xasa9vaesvad{dNode6vac2vaa{dNode6vac0wad1ypzxawc9daxakaaxasaavaetvac{dNode6vac0wad1ypzxawd9dcaxakacxasbcavaetwad0xawb9dxakadxasadvaesvaa{dNode6vac2vad{dNode6vac0wad1yphxawc9adxakadxasadvaetvac{dNode6vac0wad1ypuxawc9acxakacxasacvaetwad1ypNxawb9axakaaxasaavaetvac{dNode6vac1vad{dNode6vac0wad1ypzxawe9ccdaxakadxasbdavaetwad1ypexawc9ccxakacxasbccvaetvaf{dNode6vac0wad1ypxxawb9fxakafxasafvaetvab{dNode6vac0wad1yp|xawg9baedcdxakabxasfbaedcdvaet>wad<ypQVRTfkpuvPRUZZ[[cfguyyBBCCPRX\^bcpqyzADEMO`gggkvDGHNRZeii{||AGRR[\iBIPPP>xawa9xaka9xasa9vaetvad{dNode6vac<va0{dNode6vac0wad1yptxawdd08axaka0xasc08avaetva1{dNode6vac2va2{dNode6vac0wad1ypPxawdd12cxaka2xasb2cvaetva3{dNode6vac0wad1ypyxawed13aaxaka3xasc3aavaetwad0xawbd1xaka1xasa1vaesva2{dNode6vac1va6{dNode6vac0wad1ypHxawdd266xaka6xasb66vaetwad1ypxawbd2xaka2xasa2vaetva3{dNode6vac1va9{dNode6vac0wad1ypmxawdd39fxaka9xasb9fvaetwad1ypxxawbd3xaka3xasa3vaetva5{dNode6vac0wad1ypdxaw `d51032bef3e7117a94336fea18a3fad7xaka5xas _51032bef3e7117a94336fea18a3fad7vaetva7{dNode6vac3va1{dNode6vac0wad1ypYxawdd710xaka1xasb10vaetva7{dNode6vac0wad1ypHxawfd77cdbxaka7xasd7cdbvaetva9{dNode6vac0wad1yp|xaw `d791eaca9375ca1b36a987af22ee71ddxaka9xas ^91eaca9375ca1b36a987af22ee71ddvaetwad0xawbd7xaka7xasa7vaesva8{dNode6vac3va0{dNode6vac0wad1yppxawgd8041aexaka0xase041aevaetva1{dNode6vac0wad1ypRxawgd819ceaxaka1xase19ceavaetva6{dNode6vac0wad1ypQxawdd869xaka6xasb69vaetwad0xawbd8xaka8xasa8vaesva9{dNode6vac3va0{dNode6vac0wad1ypbxawfd9018fxaka0xasd018fvaetva5{dNode6vac2va5{dNode6vac0wad1yphxawgd95522cxaka5xasd522cvaetva6{dNode6vac0wad1ypuxaw `d9560caeb797b302191f667b4264da40xaka6xas ]60caeb797b302191f667b4264da40vaetwad0xawcd95xaka5xasa5vaesva6{dNode6vac0wad1ypqxawdd96fxaka6xasb6fvaetwad1ypkxawbd9xaka9xasa9vaetvae{dNode6vac1vae{dNode6vac0wad1yp~xawddeecxakaexasbecvaetwad;ypUpJxZw{uBryxawbdexakaexasaevaetvaf{dNode6vac5vaa{dNode6vac0wad1ypCxawcdfaxakaaxasaavaetvac{dNode6vac1vac{dNode6vac0wad1ypKxawddfccxakacxasacvaetwad1yphxawcdfcxakacxasacvaetvab{dNode6vac0wad1ypgxawcdfbxakabxasabvaetvae{dNode6vac1vae{dNode6vac0wad1ypCxawedfeecxakaexasbecvaetwad1ypExawcdfexakaexasaevaetvaf{dNode6vac0wad1ypFxawedffcdxakafxascfcdvaetwad5yp]uq^}xawbdfxakafxasafvaetvac{dNode6vac4vaf{dNode6vac0wad1ypfxawcdcfxakafxasafvaetvae{dNode6vac0wad1ypkxawedceedxakaexasceedvaetvad{dNode6vac1vab{dNode6vac0wad1ypKxawhdcdbbfdexakabxasebbfdevaetwad1ypKxawcdcdxakadxasadvaetvac{dNode6vac0wad1ypvxawcdccxakacxasacvaetwad9yp_LO^Mb[qHxawbdcxakacxasacvaetvab{dNode6vac4vad{dNode6vac0wad1ypaxawcdbdxakadxasadvaetvaf{dNode6vac0wad1yp{xawcdbfxakafxasafvaetvac{dNode6vac0wad1ypWxawddbccxakacxasbccvaetvab{dNode6vac0wad1ypRxawcdbbxakabxasabvaetwad<ypVkx||zKPY\^jZ>xawbdbxakabxasabvaetvaa{dNode6vac5vaa{dNode6vac1vac{dNode6vac0wad1yp\xawddaacxakacxasacvaetwad2ypK[xawcdaaxakaaxasaavaetvaf{dNode6vac0wad1ypSxawcdafxakafxasafvaetvab{dNode6vac0wad1ypexawcdabxakabxasabvaetvac{dNode6vac0wad1ypmxawcdacxakacxasacvaetvad{dNode6vac0wad1ypHxawcdadxakadxasadvaetwad;yp}YQ[eCGHaixawbdaxakaaxasaavaetvad{dNode6vac4vaa{dNode6vac0wad1ypgxawdddabxakaaxasbabvaetvad{dNode6vac0wad1ypuxawcdddxakadxasadvaetvac{dNode6vac0wad1ypRxawdddccxakacxasbccvaetvab{dNode6vac0wad1ypSxawcddbxakabxasabvaetwad6ypP`bv{Gxawbddxakadxasadvaet>wad<ypUWXRY_``addfmmnruuvvvvy|||}~JKLQW[[bdfhknrtAIKLNTX[loqrsuuwyz~DJKKOPRY[^gklmsvxyzBEIOPR\_eemtx@ACCHRRTVXY[beeejmnpqqwCC>xawadxakadxasadvaetvaf{dNode6vac<va0{dNode6vac0wad1yp[xawef0fdcxaka0xasd0fdcvaetva1{dNode6vac0wad1ypMxawhf15702aexaka1xasg15702aevaetva2{dNode6vac3va3{dNode6vac0wad1yp}xawef23caxaka3xasc3cavaetva8{dNode6vac0wad1yp`xawdf28fxaka8xasb8fvaetvac{dNode6vac0wad1ypsxawef2cbexakacxasccbevaetwad0xawbf2xaka2xasa2vaesva3{dNode6vac0wad2ypjCxawbf3xaka3xasa3vaetva4{dNode6vac4va1{dNode6vac0wad1ypbxawdf41dxaka1xasb1dvaetva5{dNode6vac0wad1ypQxaw `f45069216cd934b80ce882c9a2f2a08axaka5xas ^5069216cd934b80ce882c9a2f2a08avaetva8{dNode6vac0wad1ypMxawdf488xaka8xasb88vaetvab{dNode6vac0wad1ypaxawef4baaxakabxascbaavaetwad0xawbf4xaka4xasa4vaesva5{dNode6vac3va5{dNode6vac0wad1ypixawdf55dxaka5xasb5dvaetva6{dNode6vac0wad1ypUxawdf56cxaka6xasb6cvaetvae{dNode6vac0wad1ypxxawff5effdxakaexasdeffdvaetwad1yp`xawbf5xaka5xasa5vaetva6{dNode6vac2vae{dNode6vac0wad1ypmxawgf6debedxakaexasdebedvaetvaf{dNode6vac0wad1ypJxawef6dffxakafxasbffvaetwad0xawcf6dxaka6xasb6dvaesva7{dNode6vac0wad1yp^xawbf7xaka7xasa7vaetva8{dNode6vac2va3{dNode6vac0wad1ypNxaw `f8327953a0f0b80011b939111807999axaka3xas ^327953a0f0b80011b939111807999avaetva8{dNode6vac0wad1ypdxawdf887xaka8xasb87vaetwad0xawbf8xaka8xasa8vaesva9{dNode6vac0wad1ypVxawbf9xaka9xasa9vaetvab{dNode6vac1vae{dNode6vac0wad1ypgxawcfbexakaexasaevaetwad9ypQsvwQ`kaNxawbfbxakabxasabvaetvaa{dNode6vac4vaa{dNode6vac0wad1ypSxawcfaaxakaaxasaavaetvae{dNode6vac0wad1yppxawcfaexakaexasaevaetvad{dNode6vac0wad1ypUxawcfadxakadxasadvaetvab{dNode6vac0wad1ypxxawcfabxakabxasabvaetwad;yp^eSxyD~GiX}xawbfaxakaaxasaavaetvae{dNode6vac4vae{dNode6vac0wad1ypXxawcfeexakaexasaevaetvaf{dNode6vac0wad1ypIxawdfefcxakafxasbfcvaetvab{dNode6vac0wad1ypixawcfebxakabxasabvaetvac{dNode6vac2vac{dNode6vac0wad1ypIxawefeccexakacxasbcevaetvaa{dNode6vac0wad1ypWxawdfecaxakaaxasaavaetwad0xawcfecxakacxasacvaeswad6ypm[mzOIxawbfexakaexasaevaetvad{dNode6vac4vae{dNode6vac1vae{dNode6vac0wad1ypgxawefdeefxakaexasbefvaetwad1ypbxawcfdexakaexasaevaetvac{dNode6vac1vac{dNode6vac0wad1ypgxawdfdccxakacxasacvaetwad1yptxawcfdcxakacxasacvaetvad{dNode6vac1vaa{dNode6vac0wad1ypExawdfddaxakaaxasaavaetwad1ypPxawcfddxakadxasadvaetvaa{dNode6vac0wad1ypPxawcfdaxakaaxasaavaetwad9ypYX@EFvHb~xawbfdxakadxasadvaetvac{dNode6vac6vab{dNode6vac0wad3ypepBxawcfcbxakabxasabvaetvaf{dNode6vac0wad1yp`xawefcfdaxakafxascfdavaetvad{dNode6vac1vae{dNode6vac0wad1ypYxawgfcdecdbxakaexasdecdbvaetwad1ypfxawcfcdxakadxasadvaetvaa{dNode6vac0wad1ypixawcfcaxakaaxasaavaetvae{dNode6vac0wad2yp_^xawcfcexakaexasaevaetvac{dNode6vac0wad1ypJxawcfccxakacxasacvaetwad7ypljkHx~bxawbfcxakacxasacvaetvaf{dNode6vac1vad{dNode6vac1vab{dNode6vac0wad1ypAxaweffdbdxakabxasbbdvaetwad1ypoxawcffdxakadxasadvaetwad7yp}KcgsKPxawbffxakafxasafvaet>wad<ypRTUUYQQRRY^cdefknruvx|}CFGHIINQQSSUUUXZZ[``abfmorxx{{ABCCCEKNNPPPZ^``ltuvyy~EGJKKTWX`ghmoqrsw@DEOORT_aacejmmmorstttvv|~@EI\abcjjlpqxz}}BCEKNP>xawafxakafxasafvaetvaa{dNode6vac<va0{dNode6vac1va0{dNode6vac0wad1yptxawda00cxaka0xasb0cvaetwad1yptxawba0xaka0xasa0vaetva1{dNode6vac2va0{dNode6vac0wad1ypyxawda106xaka0xasb06vaetva2{dNode6vac0wad1ypZxaw `a12474027c91fad5a861aa9919817d72xaka2xas ^2474027c91fad5a861aa9919817d72vaetwad0xawba1xaka1xasa1vaesva2{dNode6vac2va0{dNode6vac0wad1ypvxawfa2012axaka0xasd012avaetva6{dNode6vac0wad1ypYxawfa2679axaka6xasd679avaetwad0xawba2xaka2xasa2vaesva4{dNode6vac2va4{dNode6vac0wad1yp]xaw `a4462529ab493676987d946019a14945xaka4xas ^462529ab493676987d946019a14945vaetva6{dNode6vac0wad1ypmxawda46cxaka6xasb6cvaetwad0xawba4xaka4xasa4vaesva5{dNode6vac1va7{dNode6vac0wad1ypXxawga578acfxaka7xase78acfvaetwad1ypkxawba5xaka5xasa5vaetva6{dNode6vac3va2{dNode6vac0wad1ypKxawha62186eaxaka2xasf2186eavaetva5{dNode6vac0wad1ypexawea65bdxaka5xasc5bdvaetva7{dNode6vac0wad1ypxawda673xaka7xasb73vaetwad0xawba6xaka6xasa6vaesva7{dNode6vac0wad1ypUxawba7xaka7xasa7vaetva9{dNode6vac0wad1ypJxawda98dxaka9xasc98dvaetvac{dNode6vac4vab{dNode6vac0wad1ypQxawdacbaxakabxasbbavaetvaf{dNode6vac0wad1yprxaweacfacxakafxascfacvaetvad{dNode6vac0wad1ypAxaweacdacxakadxascdacvaetvae{dNode6vac0wad1yphxawdacecxakaexasbecvaetwad9ypT^iiAK\BNxawbacxakacxasacvaetvaa{dNode6vac3vaa{dNode6vac1vaa{dNode6vac0wad1ypYxawdaaaaxakaaxasaavaetwad1ypQxawcaaaxakaaxasaavaetvab{dNode6vac2vaf{dNode6vac0wad1ypdxawdaabfxakafxasafvaetvae{dNode6vac0wad1yp_xawdaabexakaexasaevaetwad2ypFxawcaabxakabxasabvaetvac{dNode6vac0wad1ypzxawfaacebfxakacxasdcebfvaetwad<ypSSYgMTAGmrt}I>xawbaaxakaaxasaavaetvab{dNode6vac4vaa{dNode6vac0wad1ypWxawcabaxakaaxasaavaetvad{dNode6vac0wad1yp~xaweabdafxakadxascdafvaetvae{dNode6vac0wad1yp@xawcabexakaexasaevaetvac{dNode6vac0wad1ypfxawcabcxakacxasacvaetwad:ypVV^@siLkrxawbabxakabxasabvaetvae{dNode6vac3vae{dNode6vac0wad1ypgxawcaeexakaexasaevaetvaa{dNode6vac0wad1ypHxawcaeaxakaaxasaavaetvaf{dNode6vac0wad1ypdxawdaefexakafxasbfevaetwad6yp^UyqGRxawbaexakaexasaevaetvad{dNode6vac2vab{dNode6vac0wad1ypXxawcadbxakabxasabvaetvac{dNode6vac0wad1ypGxawdadcdxakacxasbcdvaetwad7ypF[d_}FTxawbadxakadxasadvaetvaf{dNode6vac2vaa{dNode6vac0wad1ypNxawfafaebdxakaaxasdaebdvaetvaf{dNode6vac0wad1ypCxawcaffxakafxasafvaetwad8ypJ^dyp`lxawbafxakafxasafvaet>wad<ypYT`bccdefgimnopuwx}}}~CEFGJYYYYZ\cdefhotuu@CCLNNOPXX\`cefkloprsuEFHHQUUX\^^__fghhnn{|}@HOPPZ[_elpt||}AAEELTVVY^eikllozAANPPQ>xawaaxakaaxasaavaetvab{dNode6vac<va0{dNode6vac0wad1ypbxawdb051xaka0xasc051vaetva1{dNode6vac0wad1ypnxawgb16bdddxaka1xasf16bdddvaetva2{dNode6vac2va6{dNode6vac0wad1ypOxaw `b2621497b3313c97855ed951f0d9b291xaka6xas ^621497b3313c97855ed951f0d9b291vaetva7{dNode6vac0wad1ypsxaw `b27bdabd8e1a6b7dc06886867331ceb3xaka7xas ^7bdabd8e1a6b7dc06886867331ceb3vaetwad2ypksxawbb2xaka2xasa2vaetva3{dNode6vac0wad1yp{xaw `b36abffbe5d6a0de73a9968604a1a3f9xaka3xas _36abffbe5d6a0de73a9968604a1a3f9vaetva5{dNode6vac0wad1yp{xawbb5xaka5xasa5vaetva8{dNode6vac0wad1ypExawdb875xaka8xasc875vaetva9{dNode6vac0wad1yppxawbb9xaka9xasa9vaetvad{dNode6vac4vab{dNode6vac0wad3ypV~wxawcbdbxakabxasabvaetvaa{dNode6vac0wad2ypaixawcbdaxakaaxasaavaetvae{dNode6vac1vaa{dNode6vac0wad1ypOxawdbdeaxakaaxasaavaetwad2ypALxawcbdexakaexasaevaetvac{dNode6vac0wad1yp_xawcbdcxakacxasacvaetwad8ypEIKH[^rWxawbbdxakadxasadvaetvab{dNode6vac4vaf{dNode6vac1vab{dNode6vac0wad1ypExawdbbfbxakabxasabvaetwad1yp_xawcbbfxakafxasafvaetvad{dNode6vac0wad2ypb}xawcbbdxakadxasadvaetvab{dNode6vac4vad{dNode6vac0wad1yptxawebbbddxakadxasbddvaetvab{dNode6vac0wad1ypqxawdbbbbxakabxasabvaetvae{dNode6vac0wad1ypNxawdbbbexakaexasaevaetvac{dNode6vac0wad1ypGxawebbbcaxakacxasbcavaetwad0xawcbbbxakabxasabvaesvae{dNode6vac0wad1yp~xawcbbexakaexasaevaetwad4ypS}u\xawbbbxakabxasabvaetvac{dNode6vac4vad{dNode6vac0wad1ypixawcbcdxakadxasadvaetvab{dNode6vac0wad1ypuxawcbcbxakabxasabvaetvac{dNode6vac1vad{dNode6vac0wad1ypfxawfbccdffxakadxascdffvaetwad1yp\xawcbccxakacxasacvaetvae{dNode6vac0wad1yp~xawcbcexakaexasaevaetwad6ypT~UFIxxawbbcxakacxasacvaetvaf{dNode6vac4vaa{dNode6vac0wad1ypfxawebfaebxakaaxascaebvaetvaf{dNode6vac0wad1ypzxawhbffdcb5bxakafxasffdcb5bvaetvab{dNode6vac0wad2ypdYxawcbfbxakabxasabvaetvae{dNode6vac0wad1yphxawfbfebadxakaexasdebadvaetwad6ypYSZcdexawbbfxakafxasafvaetvae{dNode6vac4vaf{dNode6vac1vaa{dNode6vac0wad1ypRxawdbefaxakaaxasaavaetwad1yplxawcbefxakafxasafvaetvaa{dNode6vac0wad1yp{xawdbeafxakaaxasbafvaetvab{dNode6vac0wad1yprxawebebfexakabxascbfevaetvad{dNode6vac0wad1ypJxawcbedxakadxasadvaetwad9ypKY[e{CRT}xawbbexakaexasaevaetvaa{dNode6vac3vab{dNode6vac2vab{dNode6vac0wad1ypNxawdbabbxakabxasabvaetvac{dNode6vac0wad1ypaxawebabcfxakacxasbcfvaetwad0xawcbabxakabxasabvaesvad{dNode6vac1vaa{dNode6vac0wad1ypQxawebadafxakaaxasbafvaetwad2ypvixawcbadxakadxasadvaetvae{dNode6vac0wad1ypdxawebaefdxakaexascefdvaetwad5ypvzDidxawbbaxakaaxasaavaet>wad<ypSWWWY^T_cevx{}IJKNTTYYZ[[cdfhku{ACCEGLMRRXY\abekqrtxzDFOPXYY[^gkmqxyy{@FHJJM_`ajjrrvwz{|DEHIJLRSSW\\^^^aaabefjowwx}BCDFQQQ>xawabxakabxasabvaetvac{dNode6vac<va0{dNode6vac1va9{dNode6vac0wad1ypGxawdc098xaka9xasb98vaetwad1ypBxawbc0xaka0xasa0vaetva1{dNode6vac2va2{dNode6vac0wad1ypcxaw `c1241374502f200cf9fc49c8d6fb5822xaka2xas ^241374502f200cf9fc49c8d6fb5822vaetva8{dNode6vac0wad1yprxawdc18bxaka8xasb8bvaetwad0xawbc1xaka1xasa1vaesva2{dNode6vac1va0{dNode6vac0wad1ypExawdc20dxaka0xasb0dvaetwad1ypmxawbc2xaka2xasa2vaetva3{dNode6vac2va0{dNode6vac0wad1yp]xaw `c3053579ae25e2fb9b967076a06373afxaka0xas ^053579ae25e2fb9b967076a06373afvaetva7{dNode6vac0wad1ypqxaw `c377351433a941a927aab543931f6026xaka7xas ^77351433a941a927aab543931f6026vaetwad0xawbc3xaka3xasa3vaesva4{dNode6vac0wad4ypsnODxawbc4xaka4xasa4vaetva5{dNode6vac2va4{dNode6vac0wad1ypQxaw `c54909ecf4fb3e9afeea36200fe95dcexaka4xas ^4909ecf4fb3e9afeea36200fe95dcevaetva6{dNode6vac0wad1ypNxawdc56axaka6xasb6avaetwad0xawbc5xaka5xasa5vaesva6{dNode6vac2va1{dNode6vac2va0{dNode6vac0wad1yplxawgc6107ffxaka0xasd07ffvaetvaa{dNode6vac0wad1ypaxawdc61axakaaxasaavaetwad0xawcc61xaka1xasa1vaesva6{dNode6vac0wad1ypcxawfc6696axaka6xasd696avaetwad3ypl[kxawbc6xaka6xasa6vaetva7{dNode6vac2va0{dNode6vac0wad1ypFxawdc70bxaka0xasb0bvaetva9{dNode6vac0wad1ypLxawfc7937bxaka9xasd937bvaetwad0xawbc7xaka7xasa7vaesva9{dNode6vac2va2{dNode6vac0wad1ypFxawdc92cxaka2xasb2cvaetva8{dNode6vac0wad1ypkxawfc98cbcxaka8xasd8cbcvaetwad1ypWxawbc9xaka9xasa9vaetvaf{dNode6vac3vaa{dNode6vac2vae{dNode6vac0wad1ypyxawecfaebxakaexasbebvaetvad{dNode6vac0wad1ypyxawecfaddxakadxasbddvaetwad0xawccfaxakaaxasaavaesvac{dNode6vac0wad1yplxawccfcxakacxasacvaetvae{dNode6vac0wad1ypPxawdcfeaxakaexasbeavaetwad5ypSs~GLxawbcfxakafxasafvaetvae{dNode6vac2vab{dNode6vac0wad1ypRxawdcebfxakabxasbbfvaetvad{dNode6vac0wad1ypqxawccedxakadxasadvaetwad<ypURctW\fXHMouElA>xawbcexakaexasaevaetvab{dNode6vac5vad{dNode6vac1vad{dNode6vac0wad1yp^xawecbdddxakadxasbddvaetwad1yp[xawccbdxakadxasadvaetvaa{dNode6vac1vaa{dNode6vac0wad1ypzxawecbaacxakaaxasbacvaetwad1ypHxawccbaxakaaxasaavaetvae{dNode6vac0wad1yp`xawdcbeaxakaexasbeavaetvaf{dNode6vac0wad1ypxawccbfxakafxasafvaetvac{dNode6vac0wad1ypGxawccbcxakacxasacvaetwad8yp|m@Lr|ssxawbcbxakabxasabvaetvaa{dNode6vac2vae{dNode6vac1vac{dNode6vac0wad1ypxxawdcaecxakacxasacvaetwad1ypoxawccaexakaexasaevaetvab{dNode6vac0wad1yp_xawdcabbxakabxasbbbvaetwad:ypQSaE`PfIpHxawbcaxakaaxasaavaetvad{dNode6vac1vab{dNode6vac0wad1ypvxawccdbxakabxasabvaetwad4ypzbDTxawbcdxakadxasadvaetvac{dNode6vac1vac{dNode6vac0wad1ypPxawccccxakacxasacvaetwad6ypXhYC_jxawbccxakacxasacvaet>wad<ypSRZ\addgjl{{BGKPPQRTTTUWXZ\\bccegkmmntBBGRbbegghopqqrrtz@@AACEFFHKTVV_kllorvy{{{EGGJPPW\]__aegiwyz}CHPSUV\\kkw}BKKQR>xawacxakacxasacvaetvae{dNode6vac<va0{dNode6vac0wad1ypjxawde01exaka0xasc01evaetva1{dNode6vac2va5{dNode6vac0wad1ypXxawde159xaka5xasb59vaetva8{dNode6vac0wad1yp~xaw `e1870dde155be1a375f155dd1f7ead13xaka8xas ^870dde155be1a375f155dd1f7ead13vaetwad0xawbe1xaka1xasa1vaesva3{dNode6vac2va0{dNode6vac0wad1ypSxaw `e30258aeb8475d4c27f7935945671856xaka0xas ^0258aeb8475d4c27f7935945671856vaetva9{dNode6vac0wad1yp^xawge396cbfxaka9xase96cbfvaetwad1ypSxawbe3xaka3xasa3vaetva5{dNode6vac1va3{dNode6vac0wad1ypxaw `e5390751969ab21df280b7591854b89fxaka3xas ^390751969ab21df280b7591854b89fvaetwad1yp|xawbe5xaka5xasa5vaetva6{dNode6vac0wad1yp}xaw `e6684944c37dbdd4c08d978af9e47bedxaka6xas _6684944c37dbdd4c08d978af9e47bedvaetva7{dNode6vac0wad1yp@xawde74dxaka7xasc74dvaetvae{dNode6vac4vad{dNode6vac0wad1ypTxawceedxakadxasadvaetvaa{dNode6vac0wad2ypTlxawceeaxakaaxasaavaetvab{dNode6vac0wad1ypFxawdeebexakabxasbbevaetvae{dNode6vac1vaf{dNode6vac0wad1ypMxawdeeefxakafxasafvaetwad2yptExawceeexakaexasaevaetwad<ypVYkoTtucZw}Q}>xawbeexakaexasaevaetvad{dNode6vac4vae{dNode6vac0wad1ypZxawcedexakaexasaevaetvab{dNode6vac2vaf{dNode6vac0wad1yp\xawdedbfxakafxasafvaetvac{dNode6vac0wad1ypsxawdedbcxakacxasacvaetwad0xawcedbxakabxasabvaesvad{dNode6vac0wad1yp`xawdeddbxakadxasbdbvaetvaf{dNode6vac0wad1ypSxawcedfxakafxasafvaetwad;ypXGubqQ\fC]Cxawbedxakadxasadvaetvac{dNode6vac4vae{dNode6vac0wad1ypdxawdecedxakaexasbedvaetvac{dNode6vac0wad1ypkxawceccxakacxasacvaetvaf{dNode6vac0wad3yp\MKxawcecfxakafxasafvaetvad{dNode6vac0wad1ypyxawdecdfxakadxasbdfvaetwad5ypQgo[@xawbecxakacxasacvaetvaa{dNode6vac4vaf{dNode6vac1vab{dNode6vac0wad1ypNxawfeafbdfxakabxascbdfvaetwad2ypkPxawceafxakafxasafvaetvac{dNode6vac0wad1ypzxawfeacbbaxakacxasdcbbavaetvad{dNode6vac0wad1ypmxawceadxakadxasadvaetvaa{dNode6vac0wad1ypzxawdeaadxakaaxasbadvaetwad9ypS{~cTYCSoxawbeaxakaaxasaavaetvab{dNode6vac4vad{dNode6vac0wad3ypfPgxawcebdxakadxasadvaetvac{dNode6vac2vaf{dNode6vac0wad1yppxaweebcffxakafxasbffvaetvad{dNode6vac0wad1ypzxaweebcdfxakadxasbdfvaetwad0xawcebcxakacxasacvaesvaa{dNode6vac0wad1ypTxaweebadexakaaxascadevaetvab{dNode6vac0wad1ypsxawcebbxakabxasabvaetwad8yplpw{YEqqxawbebxakabxasabvaetvaf{dNode6vac4vab{dNode6vac0wad1ypmxawcefbxakabxasabvaetvae{dNode6vac1vad{dNode6vac0wad1ypzxawdefedxakadxasadvaetwad1ypAxawcefexakaexasaevaetvaa{dNode6vac0wad2yp^Cxawcefaxakaaxasaavaetvaf{dNode6vac1vad{dNode6vac0wad1ypIxaweeffdcxakadxasbdcvaetwad1ypCxawceffxakafxasafvaetwad5yp\jl\pxawbefxakafxasafvaet>wad<ypTVY^__[`acdfkklnvvvw|~BEJJLQUUW[\bbgky{@BCIKP^_ccddgpsuux@DDDDEKMOPPSTTTYZ[[[emnw|AFFJMNNORRRR]jloprvzz{GJLRV[[\bdjmmoqwy~BBCHPR>xawaexakaexasaevaet>wad0xaw`xak`xas`vaesvgisArraysvetitle3xdtypeeRadixvdnode{dNode6vac<va0{dNode6vac<va0{dNode6vac0wad1yp~xawb00xaka0xasa0vaetva2{dNode6vac0wad3ype~fxawb02xaka2xasa2vaetva3{dNode6vac0wad2ypN}xawb03xaka3xasa3vaetva4{dNode6vac0wad1yp}xawb04xaka4xasa4vaetva5{dNode6vac0wad1yp|xawb05xaka5xasa5vaetva6{dNode6vac0wad2ypN|xawb06xaka6xasa6vaetva7{dNode6vac1va2{dNode6vac0wad1ypGxawd0724xaka2xasb24vaetwad1ypsxawb07xaka7xasa7vaetva8{dNode6vac0wad1ypHxawb08xaka8xasa8vaetva9{dNode6vac0wad2yptHxawb09xaka9xasa9vaetva系{dNode6vac0wad1yp|xawb0系xaka系xasa系vaetva対{dNode6vac0wad2ypm^xawc0対応xaka対xasb対応vaetva日{dNode6vac0wad1ypwxawc0日目xaka日xasb日目vaet>wad<ypquJUUVVWWXYY[[\]]addhp}BHKpprXXZ[mmtv~@CDGIMMmM>xawa0xaka0xasa0vaetva1{dNode6vac9va0{dNode6vac3va0{dNode6vac0wad;ypvwFGHNO|}~xawd100本xaka0xasb0本vaetva章{dNode6vac0wad1ypAxawc10章xaka章xasa章vaetva回{dNode6vac0wad1ypxxawc10回xaka回xasa回vaetwad1ypGxawb10xaka0xasa0vaetva1{dNode6vac0wad1ypGxawb11xaka1xasa1vaetva2{dNode6vac0wad2ypFrxawb12xaka2xasa2vaetva3{dNode6vac2va章{dNode6vac0wad1yp@xawc13章xaka章xasa章vaetvaw{dNode6vac0wad1ypcxawc13wxakawxasawvaetwad0xawb13xaka3xasa3vaesva5{dNode6vac0wad1yp{xawc15章xaka5xasb5章vaetva9{dNode6vac0wad1ypFxawb19xaka9xasa9vaetva回{dNode6vac0wad2ypAaxawb1回xaka回xasa回vaetva日{dNode6vac0wad3ypSq|xawc1日目xaka日xasb日目vaetva章{dNode6vac0wad2ypIhxawb1章xaka章xasa章vaetwad<ypzJeoU]```aaadhllnnpuuyy}~~BBDDDHHKKQQRRRnppRaD[bbmGGGMM>xawa1xaka1xasa1vaetva2{dNode6vac5va0{dNode6vac4va0{dNode6vac0wad1ypexawh2009latexaka0xasf09latevaetva1{dNode6vac9va1{dNode6vac0wad3ypkovxawd2011xaka1xasa1vaetva2{dNode6vac0wad7ypgoosBK[xawd2012xaka2xasa2vaetva3{dNode6vac0wad:ypqryyPRcddexawd2013xaka3xasa3vaetva4{dNode6vac1va年{dNode6vac0wad1ypCxawe2014年xaka年xasa年vaetwad1yp{xawd2014xaka4xasa4vaetva5{dNode6vac1va年{dNode6vac0wad1ypRxawe2015年xaka年xasa年vaetwad4ypQSzzxawd2015xaka5xasa5vaetva6{dNode6vac1va年{dNode6vac0wad1ypIxawe2016年xaka年xasa年vaetwad1ypHxawd2016xaka6xasa6vaetva7{dNode6vac1va年{dNode6vac0wad1ypDxawe2017年xaka年xasa年vaetwad1ypBxawd2017xaka7xasa7vaetva8{dNode6vac1va年{dNode6vac0wad2ypvCxawe2018年xaka年xasa年vaetwad1yptxawd2018xaka8xasa8vaetva9{dNode6vac1va年{dNode6vac0wad2yp[nxawe2019年xaka年xasa年vaetwad1ypgxawd2019xaka9xasa9vaetwad0xawc201xaka1xasa1vaesva2{dNode6vac4va0{dNode6vac0wad:ypktvwCFGHNSxawd2020xaka0xasa0vaetva1{dNode6vac1va年{dNode6vac0wad1ypZxawe2021年xaka年xasa年vaetwad2ypYexawd2021xaka1xasa1vaetva2{dNode6vac0wad1yp]xawd2022xaka2xasa2vaetva3{dNode6vac0wad1ypQxawd2023xaka3xasa3vaetwad0xawc202xaka2xasa2vaesva追{dNode6vac0wad1yprxawd20追記xaka追xasb追記vaetwad0xawb20xaka0xasa0vaesva回{dNode6vac0wad1yp@xawb2回xaka回xasa回vaetvan{dNode6vac0wad1ypVxawc2ndxakanxasbndvaetva章{dNode6vac0wad1ypHxawb2章xaka章xasa章vaetva日{dNode6vac0wad1yp{xawc2日目xaka日xasb日目vaetwad<ypXPSgyIdpUVWXY[[\]`dl|~R^IP\q~~CDMbmt>xawa2xaka2xasa2vaetva3{dNode6vac5va2{dNode6vac0wad1ypxawb32xaka2xasa2vaetva章{dNode6vac0wad2ypXZxawb3章xaka章xasa章vaetva回{dNode6vac0wad1ypzxawb3回xaka回xasa回vaetva版{dNode6vac0wad1ypGxawb3版xaka版xasa版vaetva日{dNode6vac0wad1ypyxawc3日目xaka日xasb日目vaetwad<ypscuyy}~DHQzLXXZ[j@GInxHH>xawa3xaka3xasa3vaetva4{dNode6vac4va0{dNode6vac0wad1ypxawd4096xaka0xasc096vaetva8{dNode6vac0wad1ypJxawd4897xaka8xasc897vaetva章{dNode6vac0wad3ypTHhxawb4章xaka章xasa章vaetva対{dNode6vac0wad1ypnxawc4対応xaka対xasb対応vaetwad<ypbXltuuy~DHKnXXZ[mmtvF^sx>xawa4xaka4xasa4vaetva5{dNode6vac2va章{dNode6vac0wad1ypRxawb5章xaka章xasa章vaetva回{dNode6vac0wad1ypIxawb5回xaka回xasa回vaetwad:yp\JgllnpBHjxawa5xaka5xasa5vaetva6{dNode6vac1va章{dNode6vac0wad1ypPxawb6章xaka章xasa章vaetwad8yp`ahDn@GIxawa6xaka6xasa6vaetva7{dNode6vac3va対{dNode6vac0wad1ypDxawc7対応xaka対xasb対応vaetva回{dNode6vac0wad2ypgixawb7回xaka回xasa回vaetvaつ{dNode6vac0wad:ypqqwwyy{{||xawb7つxakaつxasaつvaetwad7ypDDu`a~Lxawa7xaka7xasa7vaetva8{dNode6vac2va章{dNode6vac0wad1ypMxawb8章xaka章xasa章vaetva回{dNode6vac0wad2ypwXxawb8回xaka回xasa回vaetwad3ypyr^xawa8xaka8xasa8vaetva9{dNode6vac2va0{dNode6vac0wad1yprxawb90xaka0xasa0vaetva章{dNode6vac0wad1ypExawb9章xaka章xasa章vaetwad1ypuxawa9xaka9xasa9vaetva今{dNode6vac2va年{dNode6vac0wad<ypQ\]UY\^_kgtBHQ{qg`>xawb今年xaka年xasa年vaetva興{dNode6vac0wad1ypZxawc今興味xaka興xasb興味vaetwad0xawa今xaka今xasa今vaesvaの{dNode6vac0wad<ypQQSVWXXZ]]^_PQQSTVWYY[\`bdegikkorstuxz}}~BBCCCFGHIJKKLLNQSUUUWXYZ\bcdgghhjkmmnqrsttvwzz{|}~@@AABBCDEGHHIJKOQQRSUU\cfjr{{||AACFIJJKNPPVZ]^`bcgiikmnoqqssu{~CDDHKLSTXZ[[\\\]`aaaffgghmnntvyz{|~@@AACEGGGHHIILLLNOQW]^_``fhhjknqqstuwwyy{{||~@@FFIIJLLLNP>xawaのxakaのxasaのvaetva振{dNode6vac0wad<ypQ]YkgtBHQ{qg`>xawb振りxaka振xasb振りvaetva返{dNode6vac0wad<ypQ]YkgtBHQ{qg`>xawb返りxaka返xasb返りvaetvaと{dNode6vac6vaい{dNode6vac1vaか{dNode6vac0wad2ypHHxawdというかxakaかxasaかvaetwad7ypRX]MZLexawcというxakaいxasbいうvaetvaし{dNode6vac0wad2ypWsxawcとしてxakaしxasbしてvaetvaこ{dNode6vac0wad1ypZxawcところxakaこxasbころvaetvaり{dNode6vac0wad1ypTxawbとりxakaりxasaりvaetvaき{dNode6vac0wad1ypWxawbときxakaきxasaきvaetvaう{dNode6vac0wad1yp_xawgとうございますxakaうxasfうございますvaetwad<ypQUUVYZ[[]_PY\cddgkszIQYYcegntuvz@ABDHOQb{EM^mqtCNagt@GHIW`ddeen~DDIOPQ>xawaとxakaとxasaとvaetva来{dNode6vac2va年{dNode6vac0wad<ypQ]YkgtBHQ{qg`>xawb来年xaka年xasa年vaetvaま{dNode6vac0wad4ypPRijxawc来ましxakaまxasbましvaetwad0xawa来xaka来xasa来vaesva抱{dNode6vac0wad<ypQ]YkgtBHQ{qg`>xawb抱負xaka抱xasb抱負vaetva（{dNode6vac0wad<ypQYZ[]PSTYkogtz{|}~@ABHQVXYZ[]^`acdehjlnprtuy{}~ADHQ]`bcdqr@JQTXYdfghpz{}~@DHIWcehipstuxyHJKL>xawa（xaka（xasa（vaetva）{dNode6vac0wad<ypQYZ[]PSTYkogtz{|}~@ABHQVXYZ[]^`acdehjlnprtuy{}~ADHQ]`bcdqr@JQTXYdfghpz{}~@DHIWcehipstuxyHIJKL>xawa）xaka）xasa）vaetvaO{dNode6vac7var{dNode6vac0wad1ypRxaweOramaxakarxasdramavaetvaD{dNode6vac0wad1ypdxawfOData式xakaDxaseData式vaetvac{dNode6vac1va始{dNode6vac0wad1ypWxawnOctopress始めましたxaka始xase始めましたvaetwad3ypfkVxawiOctopressxakacxashctopressvaetvap{dNode6vac0wad1ypaxawiOperationxakapxashperationvaetvab{dNode6vac0wad1ypixawfObjectxakabxasebjectvaetvan{dNode6vac0wad1ypKxawcOnexakanxasbnevaetvaS{dNode6vac0wad1yp]xaweOSSAJxakaSxasdSSAJvaetwad0xawaOxakaOxasaOvaesva検{dNode6vac2va索{dNode6vac5va画{dNode6vac0wad1ypUxawd検索画面xaka画xasb画面vaetva技{dNode6vac1va勉{dNode6vac0wad1ypsxawg検索技術勉強会xaka勉xasc勉強会vaetwad1ypcxawd検索技術xaka技xasb技術vaetva対{dNode6vac0wad1ypsxawd検索対象xaka対xasb対象vaetva機{dNode6vac0wad1ypbxawd検索機能xaka機xasb機能vaetva座{dNode6vac0wad1ypGxawf検索座談会っxaka座xasd座談会っvaetwad<ypRRTddsyyzz]^edD>xawb検索xaka索xasa索vaetva討{dNode6vac0wad1ypNxawb検討xaka討xasa討vaetwad0xawa検xaka検xasa検vaesvaエ{dNode6vac2vaン{dNode6vac2vaン{dNode6vac0wad1ypRxawdエンジンxakaンxasaンvaetvaニ{dNode6vac1vaサ{dNode6vac0wad1ypdxawiエンジニアサポートxakaサxasdサポートvaetwad3yp\aaxaweエンジニアxakaニxasbニアvaetwad0xawcエンジxakaンxasbンジvaesvaコ{dNode6vac0wad1ypAxawfエコシステムxakaコxaseコシステムvaetwad0xawaエxakaエxasaエvaesvaで{dNode6vac2vaき{dNode6vac0wad1ypcxawdできましxakaきxascきましvaetvaる{dNode6vac0wad4ypZOz{xawbでるxakaるxasaるvaetwad<ypRS\U[fxCL]uyEKbvxzJJPkBDDKXX[`eeLOUU]_fpIL>xawaでxakaでxasaでvaetvaブ{dNode6vac2vaロ{dNode6vac2va記{dNode6vac0wad1ypWxawgブログ記述環境xaka記xasd記述環境vaetva移{dNode6vac0wad5yp\bcdexawgブログ移行日記xaka移xasd移行日記vaetwad4ypR\_Rxawcブログxakaロxasbログvaetvaラ{dNode6vac0wad1yp^xawdブランチxakaラxascランチvaetwad0xawaブxakaブxasaブvaesvaを{dNode6vac0wad<ypRSTRX[]`abcfghmnpqrxyCIJLQVWXZ\]pruwxFGKKMNOPT_bijkmovwxzFGLMOSZ_hjkklptvwx|}@ABCFJVXZ]_efjknp{CEQTUW]flEI>xawaをxakaをxasaをvaetva作{dNode6vac4vaっ{dNode6vac0wad4ypRSW]xawb作っxakaっxasaっvaetva成{dNode6vac0wad6ypbnqz@Axawb作成xaka成xasa成vaetva業{dNode6vac0wad3ypetSxawb作業xaka業xasa業vaetvaり{dNode6vac0wad1yp\xawb作りxakaりxasaりvaetwad0xawa作xaka作xasa作vaesvaて{dNode6vac1vaる{dNode6vac0wad1ypCxawbてるxakaるxasaるvaetwad<ypRZ^_`aahh|IJW[]rrssu|}~EGGKWYgkBCJPRYZ[finossBC_ijlovE>xawaてxakaてxasaてvaetvaみ{dNode6vac2vaる{dNode6vac0wad3ypfIJxawbみるxakaるxasaるvaetvaま{dNode6vac0wad4ypsEBlxawcみましxakaまxasbましvaetwad<ypR`abhWr|}~GKkCZ[CE>xawaみxakaみxasaみvaetvaた{dNode6vac6vaめ{dNode6vac0wad3ypQ\axawbためxakaめxasaめvaetvaく{dNode6vac0wad1yp[xawbたくxakaくxasaくvaetvaい{dNode6vac0wad1yp^xawbたいxakaいxasaいvaetvaち{dNode6vac0wad2ypSNxawbたちxakaちxasaちvaetvaら{dNode6vac0wad1ypTxawdたらしいxakaらxascらしいvaetvaよ{dNode6vac0wad1ypJxawbたよxakaよxasaよvaetwad<ypRST[\RUZ^_`abccghjmnqr|DVWX[^`acoprswxy|}~EEFGKKMNPT_befgijmowzFGJLMOSTUWXY[_adehjklprvxyz}ABCDDFGIJMPRUXZ[[\^_abcdfijjklnoqrsuwx}BEFKQRSVXY[\]abccdfgijklovzCDEII>xawaたxakaたxasaたvaetvaG{dNode6vac4vao{dNode6vac0wad1ypSxawbGoxakaoxasaovaetvar{dNode6vac2vaa{dNode6vac2vaa{dNode6vac0wad1ypYxawgGraalVMxakaaxasdalVMvaetvan{dNode6vac0wad1ypnxaweGrantxakanxasbntvaetwad0xawcGraxakaaxasaavaesvao{dNode6vac0wad1ypxxawfGroovyxakaoxasdoovyvaetwad0xawbGrxakarxasarvaesvaA{dNode6vac0wad1ypVxawbGAxakaAxasaAvaetvaO{dNode6vac0wad1ypexawdGOTOxakaOxascOTOvaetwad0xawaGxakaGxasaGvaesvaS{dNode6vac<va3{dNode6vac0wad1yp]xawbS3xaka3xasa3vaetval{dNode6vac0wad2ypScxaweSlackxakalxasdlackvaetvae{dNode6vac4vaa{dNode6vac2vak{dNode6vac0wad1ypUxawiSearchkitxakakxasckitvaetvaっ{dNode6vac0wad1ypTxawhSearchってxakaっxasbってvaetwad<ypWX[]``fxBCIJW]sQS>xawfSearchxakaaxasdarchvaetvar{dNode6vac2val{dNode6vac0wad1yp_xawjServerlessxakalxasdlessvaetva日{dNode6vac0wad1ypdxawjServer日本語版xaka日xasd日本語版vaetwad1yphxawfServerxakarxasdrvervaetvam{dNode6vac2vaa{dNode6vac0wad2ypX`xawhSemanticxakaaxaseanticvaetvai{dNode6vac0wad1ypgxawgSeminarxakaixasdinarvaetwad0xawcSemxakamxasamvaesvan{dNode6vac0wad2ypUUxaweSensexakanxascnsevaetwad0xawbSexakaexasaevaesvat{dNode6vac2vaa{dNode6vac2vat{dNode6vac0wad1yp_xawiStatelessxakatxasftelessvaetvac{dNode6vac0wad6ypDnuvDIxaweStackxakacxasbckvaetwad0xawcStaxakaaxasaavaesvau{dNode6vac2vay{dNode6vac0wad1yp]xaweStudyxakayxasayvaetvai{dNode6vac0wad2ypUWxawfStudioxakaixasbiovaetwad0xawdStudxakauxasbudvaeswad0xawbStxakatxasatvaesvac{dNode6vac3vah{dNode6vac0wad1yp[xawfSchemaxakahxasdhemavaetvai{dNode6vac0wad1ypoxawgSciencexakaixaseiencevaetvaa{dNode6vac0wad1ypRxaweScalaxakaaxascalavaetwad0xawbScxakacxasacvaesvap{dNode6vac3vae{dNode6vac0wad1yp]xawhSpecificxakaexasfecificvaetvar{dNode6vac0wad1ypBxawfSpringxakarxasdringvaetval{dNode6vac0wad1ypjxawfSplunkxakalxasdlunkvaetwad0xawbSpxakapxasapvaesvao{dNode6vac3vaf{dNode6vac0wad1yphxaweSoflexakafxascflevaetvan{dNode6vac0wad2ypJtxawhSonatypexakanxasfnatypevaetval{dNode6vac2vaJ{dNode6vac0wad5yp}F_kwxawfSolrJPxakaJxasbJPvaetvaC{dNode6vac0wad2yptuxawiSolrCloudxakaCxaseCloudvaetwad<yplsuv}FKXZ_kmtvw@GHII^chnssxzH>xawdSolrxakalxasblrvaetwad0xawbSoxakaoxasaovaesvaT{dNode6vac0wad1yppxawdSTEPxakaTxascTEPvaetvaw{dNode6vac0wad1ypExawhSwiftypexakawxasgwiftypevaetvah{dNode6vac0wad2ypVrxawfShieldxakahxasehieldvaetvaO{dNode6vac0wad1ypJxawdSOLRxakaOxascOLRvaetvau{dNode6vac0wad2ypPRxawfSummitxakauxaseummitvaetvay{dNode6vac1vaF{dNode6vac0wad1ypGxaw TSynonymFilterFactoryxakaFxasgFactoryvaetwad1ypWxawmSynonymFilterxakayxaslynonymFiltervaet>wad0xawaSxakaSxasaSvaesvaボ{dNode6vac2vaッ{dNode6vac0wad1ypSxawcボットxakaッxasbットvaetvaー{dNode6vac0wad1yp_xawfボードゲームxakaーxaseードゲームvaetwad0xawaボxakaボxasaボvaesva話{dNode6vac1vaし{dNode6vac1vaま{dNode6vac0wad1ypyxawd話しましxakaまxasbましvaetwad1yp]xawb話しxakaしxasaしvaetwad5ypSrzMexawa話xaka話xasa話vaetva機{dNode6vac2va械{dNode6vac0wad1ypTxawd機械学習xaka械xasc械学習vaetva能{dNode6vac0wad2ypzxawb機能xaka能xasa能vaetwad0xawa機xaka機xasa機vaesvaに{dNode6vac4vaよ{dNode6vac0wad1ypTxawcによるxakaよxasbよるvaetvaつ{dNode6vac0wad<ypzKmqRs{|@NIO>xawdについてxakaつxascついてvaetvaお{dNode6vac0wad1yp\xawdにおけるxakaおxascおけるvaetvaぜ{dNode6vac0wad1ypkxawcにぜひxakaぜxasbぜひvaetwad<yp\U^_bcrsyz|Q[coefgqNWXYaekntyzBGHIMMPR[[\^acdijlopqrswxBFGKOSSVXY[\acdfgijovzCDFI>xawaにxakaにxasaにvaetvaラ{dNode6vac3vaン{dNode6vac2vaキ{dNode6vac0wad1ypTxaweランキングxakaキxascキングvaetvaダ{dNode6vac0wad1yp@xawgランダムテストxakaダxaseダムテストvaetwad0xawbランxakaンxasaンvaesvaテ{dNode6vac0wad1ypQxawdラティスxakaテxascティスvaetvaイ{dNode6vac0wad1yp@xaweライブラリxakaイxasdイブラリvaetwad0xawaラxakaラxasaラvaesva改{dNode6vac3va善{dNode6vac0wad2ypT~xawb改善xaka善xasa善vaetva訂{dNode6vac0wad2ypuvxawc改訂版xaka訂xasb訂版vaetva良{dNode6vac0wad1yp{xawb改良xaka良xasa良vaetwad0xawa改xaka改xasa改vaesvaガ{dNode6vac0wad1ypTxawcガイドxakaガxascガイドvaetva読{dNode6vac3vaみ{dNode6vac1vaま{dNode6vac0wad5ypTfEQfxawd読みましxakaまxasbましvaetwad6ypPgVXkxawb読みxakaみxasaみvaetvaん{dNode6vac0wad7ypX]ZOz{Txawb読んxakaんxasaんvaetvaめ{dNode6vac0wad1ypfxawc読めるxakaめxasbめるvaetwad0xawa読xaka読xasa読vaesvas{dNode6vac3vae{dNode6vac2vaa{dNode6vac0wad1ypUxawfsearchxakaaxasdarchvaetvar{dNode6vac0wad1ypVxawfserverxakarxasdrvervaetwad0xawbsexakaexasaevaesvat{dNode6vac0wad1yp^xawfstreamxakatxasetreamvaetvao{dNode6vac0wad1ypNxawdsolrxakaoxascolrvaetwad0xawasxakasxasasvaesva-{dNode6vac0wad<ypUY[WX]ahi{}~@AEIIJMPRT\bcdeSUU[\]\]`bcnpttww{{||~JOUUX``mvvy~DHILMNW^hpFGKLMNQ>xawa-xaka-xasa-vaetvaU{dNode6vac3vaI{dNode6vac0wad4ypUz@AxawbUIxakaIxasaIvaetvan{dNode6vac0wad2ypmyxawfUniDicxakanxaseniDicvaetvap{dNode6vac0wad1yptxawfUpdatexakapxasepdatevaetwad0xawaUxakaUxasaUvaesvaV{dNode6vac6va2{dNode6vac0wad1yplxawbV2xaka2xasa2vaetvaS{dNode6vac0wad3ypVYZxawbVSxakaSxasaSvaetvae{dNode6vac0wad1yp]xawhVerticalxakaexasgerticalvaetvai{dNode6vac0wad2ypUWxawfVisualxakaixaseisualvaetvaa{dNode6vac0wad1ypkxawgVagrantxakaaxasfagrantvaetvao{dNode6vac0wad2yp\axawcVolxakaoxasbolvaetwad0xawaVxakaVxasaVvaesva {dNode6vac0wad<ypVVWYYZZ\__UWWWWXXXXXXXX[[[[]]]]]]]]]_```aaffghhiiillmmnnnqxx{{{{|}}~~@@@@AAAABBCCCDDEEEEIIIIIJJJMMMMPPPPRRRRTTTTUUUVVWWWWW\\]]bbccddeemnoooopppsssuuvz@ADFIJKKKKKMNPSSSSSSUUUVVWXYZZ[\\\]^^^```aaabdfgggggghklllnooopqstuzz|}~BBDHIKMOOQQRVVVYY\\aaaadeehijmnoprxyyyyyzzzzADGGGGIIIMOOOOOOOOPPPPQRRRRST[[[[[\\\\\^^^^^^^aaaabccccddefiiijlmnopqqqqqqrrrsssstttw~BBBCDFFFGHIIIIJKKKKMOPPPPSSSSTUVVVVVYYaaaadehjkkkkoooqqsttuuvvvvwwxyy{{||DFFGHKKMM>xawa xaka xasa vaetvaC{dNode6vac;vao{dNode6vac5vad{dNode6vac1var{dNode6vac0wad1ypTxaweCoderxakarxasarvaetwad5ypVYZUWxawdCodexakadxasbdevaetvan{dNode6vac2vat{dNode6vac0wad4ypVWYZxawiContainerxakatxasftainervaetvaf{dNode6vac0wad2ypcvxawjConferencexakafxasgferencevaetwad0xawcConxakanxasanvaesvag{dNode6vac2vat{dNode6vac0wad8ypW[`fxB]xawiCognitivexakatxasdtivevaetvar{dNode6vac0wad1ypCxawiCognirivexakarxasdrivevaetwad0xaweCognixakagxascgnivaesvar{dNode6vac2van{dNode6vac0wad3ypimnxaweCornexakanxasbnevaetvae{dNode6vac0wad2ypsNxawdCorexakaexasaevaetwad0xawcCorxakarxasarvaesvam{dNode6vac2vaa{dNode6vac0wad2yp\axawgCompassxakaaxascassvaetvao{dNode6vac0wad1ypJxaw TCompositeTokenFilterxakaoxas PositeTokenFiltervaetwad0xawdCompxakamxasbmpvaeswad0xawbCoxakaoxasaovaesvaS{dNode6vac0wad1yp[xawcCSVxakaSxasbSVvaetvaa{dNode6vac2vas{dNode6vac2vae{dNode6vac0wad1yp]xawdCasexakaexasaevaetvau{dNode6vac0wad1ypaxawfCasualxakauxascualvaetwad0xawcCasxakasxasasvaesval{dNode6vac0wad1ypSxawhCalendarxakalxasflendarvaetwad0xawbCaxakaaxasaavaesvah{dNode6vac2vao{dNode6vac0wad1ypmxawiChocolatexakaoxasgocolatevaetvaa{dNode6vac0wad3ypZ[[xawgChangesxakaaxaseangesvaetwad0xawbChxakahxasahvaesvaL{dNode6vac0wad2ypQYxawcCLIxakaLxasbLIvaetval{dNode6vac3vai{dNode6vac0wad1ypWxawfClientxakaixasdientvaetvao{dNode6vac2vaS{dNode6vac0wad2ypYJxawkCloudSearchxakaSxasfSearchvaetvae{dNode6vac0wad4ypyQSTxawhClouderaxakaexasceravaetwad0xaweCloudxakaoxascoudvaesvae{dNode6vac0wad1ypTxaweCleanxakaexasceanvaetwad0xawbClxakalxasalvaesvaf{dNode6vac0wad1yp{xawcCfPxakafxasbfPvaetvaR{dNode6vac0wad4ypzdeexaweCROSSxakaRxasdROSSvaetvau{dNode6vac0wad2ypRoxawgCuratorxakauxasfuratorvaetvaC{dNode6vac0wad2ypBoxawcCCCxakaCxasbCCvaetvaJ{dNode6vac0wad1ypGxawcCJKxakaJxasbJKvaetwad0xawaCxakaCxasaCvaesvaD{dNode6vac6vae{dNode6vac3vav{dNode6vac1vae{dNode6vac0wad1ypsxawjDevelopersxakaexasgelopersvaetwad4ypVWYZxawcDevxakavxasavvaetval{dNode6vac0wad1yp^xawfDeletexakalxasdletevaetvas{dNode6vac0wad2yptuxawfDesignxakasxasdsignvaetwad0xawbDexakaexasaevaesvaI{dNode6vac0wad8yp\ahijmnqxawcDIYxakaIxasbIYvaetvao{dNode6vac4vam{dNode6vac0wad1yp]xawfDomainxakamxasdmainvaetvaz{dNode6vac0wad1ypqxaweDozenxakazxasczenvaetvau{dNode6vac0wad1yprxawoDoubleArrayTriexakauxasmubleArrayTrievaetvac{dNode6vac0wad1ypkxawfDockerxakacxasdckervaetwad0xawbDoxakaoxasaovaesvaa{dNode6vac2vat{dNode6vac0wad1ypoxawdDataxakatxasbtavaetvay{dNode6vac0wad2ypPRxawcDayxakayxasayvaetwad0xawbDaxakaaxasaavaesvaB{dNode6vac0wad1yphxawbDBxakaBxasaBvaetvaS{dNode6vac0wad1ypjxawgDSIRNLPxakaSxasfSIRNLPvaetwad0xawaDxakaDxasaDvaesva({dNode6vac0wad<ypVdestvwyzCFGHNSW\abbccdefsUW\xBoPRVXYZ[\]^_`abcdefghijklmnopqrsuvwxyz{|}~@ABCCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~@ABCDEFGHIIJKLMNOPQR>xawa(xaka(xasa(vaetvaコ{dNode6vac3vaン{dNode6vac3vaテ{dNode6vac0wad1ypVxawdコンテナxakaテxasbテナvaetvaト{dNode6vac0wad1yp\xawjコントローラーラックxakaトxashトローラーラックvaetvaピ{dNode6vac0wad1ypgxawjコンピュータシステムxakaピxashピュータシステムvaetwad0xawbコンxakaンxasaンvaesvaマ{dNode6vac0wad3ypQYPxawdコマンドxakaマxascマンドvaetvaー{dNode6vac2vaヒ{dNode6vac0wad1yp@xawhコーヒーブレイクxakaヒxasfヒーブレイクvaetvaド{dNode6vac0wad1ypfxawkコード・シンプリシティxakaドxasiド・シンプリシティvaetwad0xawbコーxakaーxasaーvaeswad0xawaコxakaコxasaコvaesva名{dNode6vac1va古{dNode6vac0wad2ypovxawc名古屋xaka古xasb古屋vaetwad1ypVxawa名xaka名xasa名vaetva指{dNode6vac0wad3ypVLKxawb指定xaka指xasb指定vaetva){dNode6vac0wad<ypVdestvwyzCFGHNSW\abbccdefsUW\xBoPRVXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~@ABCCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~@ABCDEFGHIJKLMNOPQR>xawa)xaka)xasa)vaetvaW{dNode6vac5vaS{dNode6vac0wad1ypXxawcWSLxakaSxasbSLvaetvai{dNode6vac2van{dNode6vac2vad{dNode6vac0wad2ypopxawgWindowsxakadxasddowsvaetvat{dNode6vac0wad1ypcxawfWinterxakatxasctervaetwad0xawcWinxakanxasanvaesvak{dNode6vac0wad2yp@BxawiWikipediaxakakxasgkipediavaetwad0xawbWixakaixasaivaesvao{dNode6vac2vak{dNode6vac0wad2ypIJxawiWorkplacexakakxasfkplacevaetval{dNode6vac0wad1ypyxaweWorldxakalxasbldvaetwad0xawcWorxakaoxasborvaesvaa{dNode6vac2vat{dNode6vac0wad1ypVxawgWatcherxakatxasetchervaetvaz{dNode6vac0wad1yp^xawdWazaxakazxasbzavaetwad0xawbWaxakaaxasaavaesvae{dNode6vac0wad1yp\xawcWebxakaexasbebvaetwad0xawaWxakaWxasaWvaesvaデ{dNode6vac5vaィ{dNode6vac0wad1ypXxawkディストリビューションxakaィxasjィストリビューションvaetvaー{dNode6vac1vaソ{dNode6vac0wad1ypsxawfデータソースxakaソxascソースvaetwad8ypsF^BK]dDxawcデータxakaーxasbータvaetvaモ{dNode6vac0wad1ypOxawbデモxakaモxasaモvaetvaフ{dNode6vac0wad1yp|xaweデフォルトxakaフxasdフォルトvaetvaジ{dNode6vac0wad1ypVxawiデジタルハリウッドxakaジxashジタルハリウッドvaetwad0xawaデxakaデxasaデvaesva環{dNode6vac1va移{dNode6vac0wad1ypXxawd環境移行xaka移xasb移行vaetwad8yp^betSkPIxawb環境xaka環xasb環境vaetvad{dNode6vac2vao{dNode6vac0wad1ypYxawfdockerxakaoxaseockervaetvai{dNode6vac0wad1ypkxawgdiscussxakaixasfiscussvaetwad0xawadxakadxasadvaesvac{dNode6vac4vao{dNode6vac2vam{dNode6vac2vap{dNode6vac2vao{dNode6vac2vae{dNode6vac0wad1ypYxawgcomposexakaexasaevaetvai{dNode6vac0wad2ypJLxawlcompositePOSxakaixasfitePOSvaetwad0xawfcomposxakaoxasbosvaesvaa{dNode6vac0wad1yp[xawmcompatibilityxakaaxasiatibilityvaetwad0xawdcompxakapxasapvaesvam{dNode6vac0wad1yp[xawfcommitxakamxascmitvaetwad0xawccomxakamxasamvaesvap{dNode6vac0wad1yptxawicopyFieldxakapxasgpyFieldvaetwad1ypkxawbcoxakaoxasaovaetvar{dNode6vac0wad2ypzdxawecrossxakarxasdrossvaetvaw{dNode6vac0wad1ypyxawccwtxakawxasbwtvaetvah{dNode6vac0wad1ypLxawfchasenxakahxasehasenvaetwad0xawacxakacxasacvaesva.{dNode6vac0wad<ypYDuJUUVVWWXXYY[[\]]````aaaadddhhkkllllnnppuuuuyyyy|}}~~~~BBDDDDHHHHKKKMQQRRnnpprrNXXXXZZ[[\jmmmstv~~@@CDDGGIIMM^abbmmnsxGGHMM>xawa.xaka.xasa.vaetvay{dNode6vac0wad1ypYxawcymlxakayxascymlvaetva対{dNode6vac1va版{dNode6vac0wad1ypKxawc対応版xaka版xasa版vaetwad9ypYimvyHILhxawb対応xaka対xasb対応vaetva導{dNode6vac0wad3ypZbixawb導入xaka導xasb導入vaetvaま{dNode6vac4vaだ{dNode6vac0wad2ypZfxawbまだxakaだxasaだvaetvaで{dNode6vac0wad7ypFGHN|}~xawbまでxakaでxasaでvaetvaし{dNode6vac0wad<ypoxFMNPT_bfgimowGLOSTUX_adehjlrvxyz}AFGI\^_acjklqruwxFKVXY[\acdgkzCDI>xawbましxakaしxasaしvaetvaす{dNode6vac0wad4ypvY\exawbますxakaすxasaすvaetwad0xawaまxakaまxasaまvaesva途{dNode6vac0wad2ypZfxawb途中xaka途xasb途中vaetvap{dNode6vac7var{dNode6vac0wad1yp[xawcprexakarxasbrevaetvai{dNode6vac0wad1ypYxawgpicoclixakaixasficoclivaetval{dNode6vac0wad2ypPUxawfpluginxakalxaseluginvaetvao{dNode6vac0wad1yp[xawfpolicyxakaoxaseolicyvaetvaa{dNode6vac0wad1ypfxawjpaperwhitexakaaxasiaperwhitevaetvaf{dNode6vac0wad1ypoxawgpfiopenxakafxasffiopenvaetvay{dNode6vac0wad1ypsxawepyfesxakayxasdyfesvaetwad0xawapxakapxasapvaesvav{dNode6vac3va2{dNode6vac0wad3yphinxawbv2xaka2xasa2vaetvae{dNode6vac0wad1yp[xawdvenvxakaexascenvvaetvaa{dNode6vac0wad1ypIxawhvalidatexakaaxasgalidatevaetwad0xawavxakavxasavvaesvaP{dNode6vac8vay{dNode6vac2vaC{dNode6vac0wad1yp[xawgPyCharmxakaCxaseCharmvaetvat{dNode6vac0wad1ypsxawfPythonxakatxasdthonvaetwad0xawbPyxakayxasayvaesvar{dNode6vac2vao{dNode6vac0wad1ypXxawgProductxakaoxaseoductvaetvae{dNode6vac2vat{dNode6vac0wad1yp]xawkPretrainingxakatxashtrainingvaetvap{dNode6vac0wad1ypFxawlPreprocessorxakapxasiprocessorvaetwad0xawcPrexakaexasaevaeswad0xawbPrxakarxasarvaesvaC{dNode6vac0wad1ypjxawbPCxakaCxasaCvaetval{dNode6vac2vau{dNode6vac0wad1ypKxawfPluginxakauxasduginvaetvaa{dNode6vac0wad1ypCxawmPlayFrameworkxakaaxaskayFrameworkvaetwad0xawbPlxakalxasalvaesvaD{dNode6vac0wad1ypuxawcPDFxakaDxasbDFvaetvao{dNode6vac0wad1yphxawjPostgreSQLxakaoxasiostgreSQLvaetvaF{dNode6vac0wad1ypoxawcPFIxakaFxasbFIvaetvaa{dNode6vac0wad1yptxawgPartialxakaaxasfartialvaetwad0xawaPxakaPxasaPvaesva困{dNode6vac0wad2yp[Jxawb困っxaka困xasb困っvaetvaな{dNode6vac6vaる{dNode6vac0wad3yp[HGxawbなるxakaるxasaるvaetvaど{dNode6vac0wad2yp{~xawbなどxakaどxasaどvaetvaし{dNode6vac0wad1ypxxawbなしxakaしxasaしvaetvaん{dNode6vac0wad1ypHxawbなんxakaんxasaんvaetvaっ{dNode6vac0wad1yp[xawbなっxakaっxasaっvaetvaい{dNode6vac0wad1ypexawbないxakaいxasaいvaetwad8yp[~^\iQfxawaなxakaなxasaなvaetva？{dNode6vac1va」{dNode6vac0wad1ypaxawb？」xaka」xasa」vaetwad<yp[qq{CJwEJT}`p>xawa？xaka？xasa？vaetvaも{dNode6vac2vaの{dNode6vac0wad2ypZ[xawbものxakaのxasaのvaetvaう{dNode6vac0wad1ypMxaweもうちょっxakaうxasdうちょっvaetwad<yp\U^_jduLfOcf>xawaもxakaもxasaもvaetvaオ{dNode6vac2vaン{dNode6vac0wad5yp\U^_|xaweオンラインxakaンxasdンラインvaetvaー{dNode6vac2vaト{dNode6vac0wad2ypQfxawiオートコンプリートxakaトxasgトコンプリートvaetvaプ{dNode6vac2vaセ{dNode6vac0wad1ypoxawhオープンセミナーxakaセxasdセミナーvaetvaソ{dNode6vac0wad1ypAxawgオープンソースxakaソxascソースvaetwad0xawdオープンxakaプxasbプンvaeswad0xawbオーxakaーxasaーvaeswad0xawaオxakaオxasaオvaesvaB{dNode6vac7vae{dNode6vac2var{dNode6vac0wad5yp\U_|fxawfBerlinxakarxasdrlinvaetvat{dNode6vac0wad2ypBKxawdBetaxakatxasbtavaetwad0xawbBexakaexasaevaesvau{dNode6vac2vaz{dNode6vac0wad4yp\U_|xawiBuzzwordsxakazxasgzzwordsvaetvai{dNode6vac0wad1ypCxaweBuildxakaixascildvaetwad0xawbBuxakauxasauvaesvaG{dNode6vac0wad1yp^xawcBGMxakaGxasbGMvaetvai{dNode6vac0wad1yp]xawjBiomedicalxakaixasiiomedicalvaetvaL{dNode6vac0wad3ypahixawcBLExakaLxasbLEvaetvao{dNode6vac2vao{dNode6vac1vas{dNode6vac0wad1yplxawhBookscanxakasxasdscanvaetwad1ypVxawdBookxakaoxasbokvaetvan{dNode6vac0wad1ypoxawgBonfirexakanxasenfirevaetwad0xawbBoxakaoxasaovaesvaa{dNode6vac2vas{dNode6vac0wad1ypMxaweBashoxakasxascshovaetvar{dNode6vac0wad1ypkxawiBarcelonaxakarxasgrcelonavaetwad0xawbBaxakaaxasaavaeswad0xawaBxakaBxasaBvaesva参{dNode6vac1va中{dNode6vac0wad1ypqxawc参加中xaka中xasa中vaetwad<yp\UosfgkWXaeyzGI\^acdijloqrswxBFKVXY[\acdgovzDI>xawb参加xaka参xasb参加vaetvaし{dNode6vac3vaて{dNode6vac0wad6ypbfzM]xawbしてxakaてxasaてvaetvaま{dNode6vac2vaし{dNode6vac0wad6ypjpXdbcxawcしましxakaしxasaしvaetvaす{dNode6vac0wad1yplxawcしますxakaすxasaすvaetwad0xawbしまxakaまxasaまvaesvaゃ{dNode6vac0wad1ypsxawdしゃべっxakaゃxascゃべっvaetwad<yp\RU^_cnqr|^oswxEFKMNPT_befgimovwFGLSTUWX_aehjklvxyz}ADDFGI\^_aceijkloqrswx}@BFKVXY[\acdgovzCDII>xawaしxakaしxasaしvaetva仕{dNode6vac0wad1yp^xawc仕事中xaka仕xasc仕事中vaetvaE{dNode6vac5val{dNode6vac2vas{dNode6vac2va勉{dNode6vac0wad<ypxMNPT_bimovwGLS_>xaw PElasticsearch勉強会xaka勉xasc勉強会vaetvaク{dNode6vac0wad1ypkxaw QElasticsearchクラスタxakaクxasdクラスタvaetwad<yp_VUpJRSW[\]`adhjlnpsuy|~CDHNQVgmr>xawmElasticsearchxakasxasfsearchvaetvaS{dNode6vac1va勉{dNode6vac0wad1ypAxaw PElasticSearch勉強会xaka勉xasc勉強会vaetwad3ypdhBxawmElasticSearchxakaSxasfSearchvaetwad<ypDIJnnuvvCDDI>xawgElasticxakalxasflasticvaetvax{dNode6vac2var{dNode6vac0wad1ypXxawgExtremexakarxasdremevaetvae{dNode6vac0wad1yppxawhExtendedxakaexaseendedvaetwad0xawcExtxakaxxasbxtvaesvan{dNode6vac1vai{dNode6vac0wad1ypsxawkEngineeringxakaixascingvaetwad1ypgxawhEngineerxakanxasgngineervaetvam{dNode6vac0wad1ypjxaweEmacsxakamxasdmacsvaetvau{dNode6vac0wad1ypkxawgEuroconxakauxasfuroconvaetwad0xawaExakaExasaEvaesvaア{dNode6vac6vaー{dNode6vac0wad2yp_Sxawgアーキテクチャxakaーxasfーキテクチャvaetvaッ{dNode6vac0wad2ypRpxawfアップデートxakaッxaseップデートvaetvaプ{dNode6vac0wad1ypqxawcアプリxakaプxasbプリvaetvaイ{dNode6vac0wad1ypwxawdアイテムxakaイxascイテムvaetvaク{dNode6vac0wad1ypFxawfアクセスログxakaクxaseクセスログvaetvaジ{dNode6vac0wad1yp[xawmアジャイルデータサイエンスxakaジxaslジャイルデータサイエンスvaetwad0xawaアxakaアxasaアvaesva/{dNode6vac0wad<yp_etOrrXmv@II^nxH>xawa/xaka/xasa/vaetvaロ{dNode6vac4vaー{dNode6vac0wad1ypPxawcローマxakaーxasbーマvaetvaギ{dNode6vac0wad1ypBxawdロギングxakaギxascギングvaetvaグ{dNode6vac1va検{dNode6vac0wad1ypOxawdログ検索xaka検xasb検索vaetwad1ypOxawbログxakaグxasaグvaetvaジ{dNode6vac0wad1ypNxawdロジックxakaジxascジックvaetwad0xawaロxakaロxasaロvaesva字{dNode6vac0wad1ypPxawc字入力xaka字xasc字入力vaetvaゆ{dNode6vac0wad1ypPxawbゆれxakaゆxasbゆれvaetvaJ{dNode6vac9vaa{dNode6vac2vap{dNode6vac1vae{dNode6vac0wad1ypPxaw \JapaneseCompletionAnalyzerそのxakaexas WeseCompletionAnalyzerそのvaetwad5ypMcqYvxaweJapanxakapxascpanvaetvav{dNode6vac1vaO{dNode6vac0wad1ypKxawiJavaOneJpxakaOxaseOneJpvaetwad5ypVCDKLxawdJavaxakavxasbvavaetwad0xawbJaxakaaxasaavaesvaS{dNode6vac0wad2yp[QxawdJSONxakaSxascSONvaetvau{dNode6vac2vag{dNode6vac0wad<yp\VXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~@ABCDEFGHIJKLMNOPQR>xaweJugemxakagxascgemvaetvas{dNode6vac0wad1ypfxawlJustTechTalkxakasxasjstTechTalkvaetwad0xawbJuxakauxasauvaesvaJ{dNode6vac0wad5ypyBoxawdJJUGxakaJxascJUGvaetvaV{dNode6vac0wad1ypaxawcJVMxakaVxasbVMvaetvaI{dNode6vac0wad2yp]hxawdJIRAxakaIxascIRAvaetvae{dNode6vac0wad1ypixawiJetBrainsxakaexashetBrainsvaetvaP{dNode6vac0wad1ypFxawbJPxakaPxasaPvaetvaD{dNode6vac0wad2ypFKxawdJDicxakaDxascDicvaetwad0xawaJxakaJxasaJvaesva日{dNode6vac3va用{dNode6vac0wad1ypQxawd日本語用xaka用xasa用vaetva向{dNode6vac0wad1ypxawe日本語向けxaka向xasb向けvaetva訳{dNode6vac0wad<ypUVWXYZ[\]^`acdehjlnprtuxy}~ABDHQo>xawd日本語訳xaka訳xasa訳vaetwad3ypd@Bxawc日本語xaka日xasc日本語vaetvaA{dNode6vac:van{dNode6vac1var{dNode6vac0wad3ypQ}xawhAnalyzerxakarxasarvaetwad6ypUWz@ApxawgAnalyzexakanxasfnalyzevaetvaz{dNode6vac0wad:ypW[`fxBCW]xaweAzurexakazxasdzurevaetvaP{dNode6vac0wad6ypU^IPVaxawcAPIxakaPxasbPIvaetval{dNode6vac0wad1ypbxawgAlgoliaxakalxasflgoliavaetvap{dNode6vac2vaa{dNode6vac0wad5ypmFHIhxawfApachexakaaxasdachevaetvap{dNode6vac0wad1ypCxaweApplexakapxascplevaetwad0xawbApxakapxasapvaesvad{dNode6vac0wad1ypSxawfAdventxakadxasedventvaetvam{dNode6vac0wad2ypYJxawfAmazonxakamxasemazonvaetvag{dNode6vac0wad1yp\xawlAggregationsxakagxaskggregationsvaetvaW{dNode6vac0wad3ypPRlxawcAWSxakaWxasbWSvaetvaL{dNode6vac0wad2yptvxaweALPHAxakaLxasdLPHAvaetwad0xawaAxakaAxasaAvaesvaH{dNode6vac6vau{dNode6vac0wad4ypRcefxawdHugoxakauxascugovaetvaT{dNode6vac0wad1ypqxawdHTMLxakaTxascTMLvaetvaa{dNode6vac3vat{dNode6vac0wad1ypgxawfHatenaxakatxasdtenavaetvad{dNode6vac0wad7ypGcxXgvIxawfHadoopxakadxasddoopvaetvac{dNode6vac0wad1ypSxawdHackxakacxasbckvaetwad0xawbHaxakaaxasaavaesvai{dNode6vac0wad1ypGxawdHivexakaixascivevaetvae{dNode6vac0wad2yp^FxawfHerokuxakaexaseerokuvaetvaS{dNode6vac0wad1yphxawfHSQLDBxakaSxaseSQLDBvaetwad0xawaHxakaHxasaHvaesvaQ{dNode6vac2vaq{dNode6vac0wad2ypSTxawfQuerqyxakaqxasbqyvaetvay{dNode6vac0wad1yp^xaweQueryxakayxasayvaetwad0xawdQuerxakaQxasdQuervaesva調{dNode6vac2va査{dNode6vac0wad2ypSTxawb調査xaka査xasa査vaetvaべ{dNode6vac0wad3ypCJExawb調べxakaべxasaべvaetwad0xawa調xaka調xasa調vaesvaそ{dNode6vac0wad<ypSTosyzIJ\bcdezeertu}A>xawbそのxakaそxasbそのvaetva：{dNode6vac0wad1ypSxawa：xaka：xasa：vaetva１{dNode6vac0wad3ypTouxawa１xaka１xasa１vaetva新{dNode6vac3vaし{dNode6vac0wad3ypVNsxawc新しいxakaしxasbしいvaetva機{dNode6vac0wad3ypW`uxawc新機能xaka機xasb機能vaetva規{dNode6vac0wad1ypwxawd新規導入xaka規xasc規導入vaetwad0xawa新xaka新xasa新vaesvaク{dNode6vac2vaラ{dNode6vac2vaイ{dNode6vac1vaプ{dNode6vac0wad1ypUxawkクライアントプラグインxakaプxaseプラグインvaetwad2ypV{xawfクライアントxakaイxasdイアントvaetvaス{dNode6vac0wad1ypxxaweクラスターxakaスxascスターvaetwad0xawbクラxakaラxasaラvaesvaレ{dNode6vac0wad1ypuxawdクレートxakaレxascレートvaetwad0xawaクxakaクxasaクvaesvaイ{dNode6vac4vaン{dNode6vac4vaデ{dNode6vac3vaッ{dNode6vac2vaエ{dNode6vac0wad1ypWxawkインデックスエイリアスxakaエxaseエイリアスvaetvaテ{dNode6vac0wad1ypExawlインデックステンプレートxakaテxasfテンプレートvaetwad4ypL]joxawfインデックスxakaッxascックスvaetvaキ{dNode6vac0wad1ypNxawgインデキシングxakaキxasdキシングvaetvaク{dNode6vac0wad1yp@xawgインデクシングxakaクxasdクシングvaetwad0xawcインデxakaデxasaデvaesvaス{dNode6vac0wad1ypIxawfインストールxakaスxasdストールvaetvaポ{dNode6vac0wad1ypFxaweインポートxakaポxascポートvaetvaフ{dNode6vac2va養{dNode6vac0wad1ypOxawmインフラエンジニア養成読本xaka養xasd養成読本vaetva技{dNode6vac0wad1ypXxawmインフラエンジニア技術勉強xaka技xasd技術勉強vaetwad0xawiインフラエンジニアxakaフxasgフラエンジニアvaeswad0xawbインxakaンxasaンvaesvaメ{dNode6vac0wad1ypkxawdイメージxakaメxascメージvaetvaベ{dNode6vac0wad1ypjxawdイベントxakaベxascベントvaetvaレ{dNode6vac0wad1yppxawfイレギュラーxakaレxaseレギュラーvaetwad0xawaイxakaイxasaイvaesvaM{dNode6vac7vau{dNode6vac0wad1ypXxaweMultixakauxasdultivaetvaa{dNode6vac5vat{dNode6vac0wad1ypXxawhMatchingxakatxasftchingvaetvar{dNode6vac3vap{dNode6vac0wad1ypbxawdMarpxakapxasapvaetvak{dNode6vac0wad1ypdxawhMarkdownxakakxasekdownvaetvav{dNode6vac0wad3ypV}mxawfMarvelxakavxascvelvaetwad0xawcMarxakarxasarvaesvap{dNode6vac2vap{dNode6vac0wad1ypcxawgMappingxakapxasdpingvaetvaR{dNode6vac0wad1yp\xawdMapRxakaRxasaRvaetwad0xawcMapxakapxasapvaesvav{dNode6vac0wad1yptxaweMavenxakavxascvenvaetvac{dNode6vac0wad2ypOexawcMacxakacxasacvaetwad0xawbMaxakaaxasaavaesvaI{dNode6vac2vaC{dNode6vac0wad1yp^xaweMICESxakaCxascCESvaetvaR{dNode6vac0wad1ypuxawcMIRxakaRxasaRvaetwad0xawbMIxakaIxasaIvaesvai{dNode6vac2van{dNode6vac0wad3ypaOexawdMinixakanxasbnivaetvac{dNode6vac0wad1ypCxawiMicrosoftxakacxasgcrosoftvaetwad0xawbMixakaixasaivaesvae{dNode6vac2vae{dNode6vac0wad5ypzI^FYxawfMeetupxakaexasdetupvaetvaC{dNode6vac0wad2ypFKxaweMeCabxakaCxascCabvaetwad0xawbMexakaexasaevaesvao{dNode6vac3var{dNode6vac0wad2ypCExawjMorphlinesxakarxashrphlinesvaetvau{dNode6vac0wad1yppxawhMountainxakauxasfuntainvaetvan{dNode6vac0wad1ypixawgMongoDBxakanxasengoDBvaetwad0xawbMoxakaoxasaovaesvaB{dNode6vac0wad6ypper}ABxawcMBAxakaBxasbBAvaetwad0xawaMxakaMxasaMvaesval{dNode6vac3vaa{dNode6vac0wad1ypXxawelabelxakaaxasdabelvaetvau{dNode6vac1vau{dNode6vac0wad2yp}~xawjluceneutilxakauxasdutilvaetwad<ypnXmvy~DHILMNW^hpGMNQ>xawflucenexakauxaseucenevaetvao{dNode6vac2vaa{dNode6vac0wad1ypCxawhloadSolrxakaaxasfadSolrvaetvag{dNode6vac0wad1ypOxawfloggenxakagxasdggenvaetwad0xawbloxakaoxasaovaeswad0xawalxakalxasalvaesvaL{dNode6vac5vae{dNode6vac0wad1ypXxawhLearningxakaexasgearningvaetvai{dNode6vac5vat{dNode6vac0wad1yp]xawjLiteraturexakatxashteraturevaetvag{dNode6vac0wad2ypinxaweLightxakagxascghtvaetvan{dNode6vac0wad1yprxawgLinderaxakanxasenderavaetvao{dNode6vac0wad1yppxawdLionxakaoxasbonvaetvav{dNode6vac0wad1ypjxawdLivexakavxasbvevaetwad0xawbLixakaixasaivaesvau{dNode6vac2van{dNode6vac0wad1ypaxawgLunakeyxakanxasenakeyvaetvac{dNode6vac2vae{dNode6vac0wad<ypmKX[mv@I^knxH>xawfLucenexakaexascenevaetvai{dNode6vac0wad1ypnxaweLucidxakaixasbidvaetwad0xawcLucxakacxasacvaeswad0xawbLuxakauxasauvaesvaP{dNode6vac0wad3ypahixawdLPMExakaPxascPMEvaetvao{dNode6vac0wad6ypYjABEFxawhLogstashxakaoxasgogstashvaetwad0xawaLxakaLxasaLvaesvaf{dNode6vac2vao{dNode6vac0wad5ypX]KFKxawcforxakaoxasborvaetval{dNode6vac1vad{dNode6vac0wad2ypOqxawgfluentdxakadxasadvaetwad1ypUxawffluentxakalxaseluentvaetwad0xawafxakafxasafvaesvai{dNode6vac1vaq{dNode6vac0wad1yp~xawjinquisitorxakaqxashquisitorvaetwad4ypXo[qxawbinxakaixasbinvaetva論{dNode6vac0wad2ypX]xawb論文xaka論xasb論文vaetvaだ{dNode6vac2vaけ{dNode6vac0wad1ypCxawbだけxakaけxasaけvaetvaら{dNode6vac0wad1ypexawbだらxakaらxasaらvaetwad3ypX]Txawaだxakaだxasaだvaetvaか{dNode6vac2vaっ{dNode6vac0wad1ypZxawbかっxakaっxasaっvaetvaら{dNode6vac1vaお{dNode6vac0wad1ypfxawcからおxakaおxasaおvaetwad<ypFGHNf|}~hQhp@P>xawbからxakaらxasaらvaetwad1ypUxawaかxakaかxasaかvaetva良{dNode6vac0wad1ypZxawc良かっxaka良xasc良かっvaetvaI{dNode6vac5van{dNode6vac2vad{dNode6vac0wad2yp[lxaweIndexxakadxascdexvaetvag{dNode6vac2vas{dNode6vac0wad1ypKxawfIngestxakasxasbstvaetvar{dNode6vac0wad1ypnxawiIngersollxakarxasersollvaetwad0xawdIngexakagxasbgevaeswad0xawbInxakanxasanvaesvaO{dNode6vac1va化{dNode6vac0wad2ypahxawdIO化しxaka化xasb化しvaetwad1ypixawbIOxakaOxasaOvaetvas{dNode6vac0wad2yp|xaweIssuexakasxasdssuevaetvaD{dNode6vac0wad1ypExawbIDxakaDxasaDvaetvao{dNode6vac0wad2ypqwxawbIoxakaoxasaovaetwad0xawaIxakaIxasaIvaesva見{dNode6vac2vaた{dNode6vac0wad1ypCxawb見たxakaたxasaたvaetvaま{dNode6vac0wad1ypJxawc見ましxakaまxasbましvaetwad1yp[xawa見xaka見xasa見vaetvaキ{dNode6vac2vaボ{dNode6vac0wad7yp\ahimnqxaweキーボードxakaボxascボードvaetvaワ{dNode6vac0wad1yppxaweキーワードxakaワxascワードvaetwad0xawbキーxakaキxasbキーvaesva:{dNode6vac0wad2yp]oxawa:xaka:xasa:vaetvao{dNode6vac2van{dNode6vac0wad1yp]xawbonxakanxasanvaetvar{dNode6vac0wad1ypGxawgoreillyxakarxasfreillyvaetwad0xawaoxakaoxasaovaesva出{dNode6vac4va張{dNode6vac0wad3yp^_|xawb出張xaka張xasa張vaetva力{dNode6vac1va方{dNode6vac0wad1ypLxawe出力方法例xaka方xasc方法例vaetwad2ypQQxawb出力xaka力xasa力vaetvaす{dNode6vac0wad1ypKxawb出すxakaすxasaすvaetvaて{dNode6vac0wad1ypJxawb出てxakaてxasaてvaetwad1ypTxawa出xaka出xasa出vaetva、{dNode6vac0wad<yp`ahO{{VVTaez}>xawa、xaka、xasa、vaetva試{dNode6vac0wad2yp`Vxawb試しxaka試xasb試しvaetva組{dNode6vac0wad3ypahmxawb組みxaka組xasb組みvaetva立{dNode6vac0wad3ypahmxawb立てxaka立xasb立てvaetva+{dNode6vac0wad7ypahiOOO^xawa+xaka+xasa+vaetva#{dNode6vac0wad<ypaghimnqoKMNPT_bfggimooqwzGLMSWY_ajxyzz}AFGIIPR\^^_acdhijkloqqrswxFKPSVX[>xawa#xaka#xasa#vaetvaス{dNode6vac6vaラ{dNode6vac0wad2ypbkxawdスライドxakaラxascライドvaetvaポ{dNode6vac0wad1yp{xaweスポンサーxakaポxasdポンサーvaetvaク{dNode6vac0wad1ypxxaweスクリプトxakaクxasdクリプトvaetvaキ{dNode6vac2vaー{dNode6vac0wad1ypJxawiスキーマレスモードxakaーxasgーマレスモードvaetvaル{dNode6vac0wad2yp\axawfスキルアップxakaルxasdルアップvaetwad0xawbスキxakaキxasaキvaesvaマ{dNode6vac0wad1ypaxawcスマホxakaマxasbマホvaetvaス{dNode6vac0wad1ypAxawcススメxakaスxasbスメvaetwad0xawaスxakaスxasaスvaesva関{dNode6vac0wad7ypcsyzNnFxawc関するxaka関xasc関するvaetva情{dNode6vac0wad4ypc{dDxawb情報xaka情xasb情報vaetva交{dNode6vac0wad2ypcDxawb交換xaka交xasb交換vaetva目{dNode6vac0wad1ypcxawb目的xaka目xasb目的vaetvaが{dNode6vac0wad<ypcDhEL[drDTX[e}JZ>xawaがxakaがxasaがvaetva！{dNode6vac0wad:ypcYjxyAG\ajxawa！xaka！xasa！vaetvaN{dNode6vac6vaG{dNode6vac0wad1ypdxaweNGramxakaGxasdGramvaetvaa{dNode6vac0wad1ypgxawdNandxakaaxascandvaetvaE{dNode6vac2vaX{dNode6vac0wad1yppxawdNEXTxakaXxasbXTvaetvao{dNode6vac0wad1ypKxawgNEologdxakaoxaseologdvaetwad0xawbNExakaExasaEvaesvai{dNode6vac0wad1ypexaweNightxakaixasdightvaetvae{dNode6vac2vas{dNode6vac0wad1ypixawfNestedxakasxasdstedvaetvaw{dNode6vac0wad2yptuxawcNewxakawxasawvaetwad0xawbNexakaexasaevaesvaA{dNode6vac0wad2ypFKxaweNAISTxakaAxasdAISTvaetwad0xawaNxakaNxasaNvaesvaフ{dNode6vac4vaレ{dNode6vac0wad1ypdxawdフレーズxakaレxascレーズvaetvaリ{dNode6vac0wad1ypaxawfフリーランスxakaリxaseリーランスvaetvaァ{dNode6vac3vaイ{dNode6vac0wad2ypd@xawdファイルxakaイxasbイルvaetvaー{dNode6vac0wad1ypVxawmファーストインプレッションxakaーxaskーストインプレッションvaetvaセ{dNode6vac0wad1yp\xaweファセットxakaセxascセットvaetwad0xawbファxakaァxasaァvaesvaィ{dNode6vac0wad1ypixaweフィールドxakaィxasdィールドvaetwad0xawaフxakaフxasaフvaesva自{dNode6vac4va宅{dNode6vac0wad3ypetSxawb自宅xaka宅xasa宅vaetva作{dNode6vac0wad1ypqxawb自作xaka作xasa作vaetva然{dNode6vac0wad1ypOxawf自然言語処理xaka然xase然言語処理vaetva分{dNode6vac0wad1ypQxawb自分xaka分xasa分vaetwad0xawa自xaka自xasa自vaesvaや{dNode6vac2vaり{dNode6vac0wad1yp^xawdやりましxakaりxascりましvaetvaっ{dNode6vac0wad5ypr|}~Gxawbやっxakaっxasaっvaetwad3ypfffxawaやxakaやxasaやvaetvaサ{dNode6vac3vaジ{dNode6vac0wad1ypfxaweサジェストxakaジxasdジェストvaetvaー{dNode6vac2vaバ{dNode6vac0wad1ypOxawcサーバxakaバxasaバvaetvaビ{dNode6vac0wad1yp\xawdサービスxakaビxasbビスvaetwad0xawbサーxakaーxasaーvaesvaン{dNode6vac0wad3ypHIhxawdサンプルxakaンxascンプルvaetwad0xawaサxakaサxasaサvaesva「{dNode6vac0wad<ypg^OY\afEHIQQffhqwy{|>xawa「xaka「xasa「vaetva理{dNode6vac0wad1ypgxawb理論xaka理xasb理論vaetva実{dNode6vac3va装{dNode6vac0wad2ypgFxawb実装xaka装xasa装vaetva践{dNode6vac1va入{dNode6vac0wad1ypjxawd実践入門xaka入xasb入門vaetwad3ypXZ`xawb実践xaka践xasa践vaetva行{dNode6vac0wad2ypxPxawb実行xaka行xasa行vaetwad0xawa実xaka実xasa実vaesva」{dNode6vac0wad<ypg^OY\fjEHIQQffhqwy{|>xawa」xaka」xasa」vaetva始{dNode6vac1vaま{dNode6vac0wad1ypRxawd始めましxakaまxasbましvaetwad3ypgVsxawb始めxaka始xasb始めvaetvaT{dNode6vac6vae{dNode6vac4vat{dNode6vac0wad1ypgxawfTetrisxakatxasdtrisvaetvam{dNode6vac0wad1yplxawhTemplatexakamxasfmplatevaetvar{dNode6vac0wad1ypxxawiTerraformxakarxasgrraformvaetvac{dNode6vac0wad3yps\axawdTechxakacxasbchvaetwad0xawbTexakaexasaevaesvaa{dNode6vac1vas{dNode6vac0wad1ypaxaweTalksxakasxasasvaetwad1ypsxawdTalkxakaaxascalkvaetvai{dNode6vac0wad1ypSxawhTimelionxakaixasgimelionvaetvao{dNode6vac2vay{dNode6vac0wad6ypgyIPRKxaweTokyoxakayxasbyovaetvae{dNode6vac0wad1ypNxawkTokenFilterxakaexashenFiltervaetwad0xawcTokxakaoxasbokvaesvar{dNode6vac0wad1yp^xawlTreasureDataxakarxaskreasureDatavaetvaw{dNode6vac0wad6ypr}PSVaxawgTwitterxakawxasfwittervaetwad0xawaTxakaTxasaTvaesvaへ{dNode6vac0wad9ypo}fj^s]hAxawaへxakaへxasaへvaetva移{dNode6vac2va行{dNode6vac1va中{dNode6vac0wad1ypfxawc移行中xaka中xasa中vaetwad4ypo\jhxawb移行xaka行xasa行vaetva植{dNode6vac0wad<ypVXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~@ABCDEFGHIJKLMNOPQR>xawb移植xaka植xasa植vaetwad0xawa移xaka移xasa移vaesvaお{dNode6vac3va試{dNode6vac0wad1yppxawcお試しxaka試xasb試しvaetvaよ{dNode6vac0wad9yp`aluy~DHRxawcおよびxakaよxasbよびvaetvaめ{dNode6vac0wad1yp_xawbおめxakaめxasaめvaetwad1ypdxawaおxakaおxasaおvaetva中{dNode6vac2va身{dNode6vac0wad1yp\xawe中身説明会xaka身xasd身説明会vaetva心{dNode6vac0wad1ypIxawb中心xaka心xasa心vaetwad2yppVxawa中xaka中xasa中vaetvaF{dNode6vac5vaS{dNode6vac0wad1yprxawcFSTxakaSxasbSTvaetvao{dNode6vac0wad1ypexaweFoundxakaoxasdoundvaetval{dNode6vac0wad2ypqYxawgFluentdxakalxasfluentdvaetvae{dNode6vac0wad1ypsxaweFestaxakaexasdestavaetvaa{dNode6vac0wad2ypovxawdFallxakaaxascallvaetwad0xawaFxakaFxasaFvaesva変{dNode6vac2va更{dNode6vac0wad3ypr\Axawb変更xaka更xasa更vaetva換{dNode6vac0wad1ypdxawb変換xaka換xasa換vaetwad0xawa変xaka変xasa変vaesvaシ{dNode6vac0wad7ypsyyzz^}xawdシステムxakaシxasdシステムvaetva妄{dNode6vac1va版{dNode6vac0wad1ypQxawc妄想版xaka版xasa版vaetwad3ypsyzxawb妄想xaka妄xasb妄想vaetvam{dNode6vac2vae{dNode6vac2vat{dNode6vac0wad1ypuxawgmeteredxakatxaseteredvaetvae{dNode6vac0wad1ypqxawfmeetupxakaexasdetupvaetwad0xawbmexakaexasaevaesvaa{dNode6vac0wad1yphxawemacOSxakaaxasdacOSvaetwad0xawamxakamxasamvaesva紹{dNode6vac0wad<ypu_uwSU|]`bcm~>xawb紹介xaka紹xasb紹介vaetva第{dNode6vac;va0{dNode6vac0wad1ypSxawc第0回xaka0xasb0回vaetva1{dNode6vac9va0{dNode6vac0wad2ypi_xawd第10回xaka0xasb0回vaetva1{dNode6vac0wad2yp_Fxawd第11回xaka1xasb1回vaetva2{dNode6vac0wad1yp}xawd第12回xaka2xasb2回vaetva3{dNode6vac0wad2ypTlxawd第13回xaka3xasb3回vaetva4{dNode6vac0wad1ypPxawd第14回xaka4xasb4回vaetva5{dNode6vac0wad1ypNxawd第15回xaka5xasb5回vaetva6{dNode6vac0wad1ypMxawd第16回xaka6xasb6回vaetva章{dNode6vac0wad5ypHN|}~xawc第1章xaka章xasa章vaetva回{dNode6vac0wad2ypADxawc第1回xaka回xasa回vaetwad0xawb第1xaka1xasa1vaesva2{dNode6vac3va5{dNode6vac0wad1ypxxawd第25回xaka5xasb5回vaetva章{dNode6vac0wad2ypFGxawc第2章xaka章xasa章vaetva回{dNode6vac0wad2ypxdxawc第2回xaka回xasa回vaetwad1ypaxawb第2xaka2xasa2vaetva3{dNode6vac2va章{dNode6vac0wad1ypwxawe第3章終了xaka章xasc章終了vaetva回{dNode6vac0wad1ypjxawc第3回xaka回xasa回vaetwad0xawb第3xaka3xasa3vaesva4{dNode6vac2va章{dNode6vac0wad1ypvxawe第4章終了xaka章xasc章終了vaetva回{dNode6vac0wad2yp_Vxawc第4回xaka回xasa回vaetwad0xawb第4xaka4xasa4vaesva5{dNode6vac0wad2ypSPxawc第5回xaka5xasb5回vaetva6{dNode6vac0wad2ypLzxawc第6回xaka6xasb6回vaetva7{dNode6vac0wad1ypGxawc第7回xaka7xasb7回vaetva8{dNode6vac0wad1ypwxawc第8回xaka8xasb8回vaetva9{dNode6vac0wad2ypmkxawc第9回xaka9xasb9回vaetva一{dNode6vac2va印{dNode6vac0wad1ypmxawd第一印象xaka印xasb印象vaetva回{dNode6vac0wad1ypixawc第一回xaka回xasa回vaetwad0xawb第一xaka一xasa一vaeswad<yp{@AEMPRTz@AGxXgiI>xawa第xaka第xasa第vaetva言{dNode6vac1va処{dNode6vac1va勉{dNode6vac0wad2ypdDxawg言語処理勉強会xaka勉xasc勉強会vaetwad;ypvwFGHNO|}~xawd言語処理xaka処xasb処理vaetwad5ypqwy{|xawb言語xaka言xasb言語vaetvaノ{dNode6vac0wad;ypvwFGHNO|}~xawcノックxakaノxascノックvaetva起{dNode6vac0wad3ypxIkxawb起動xaka起xasb起動vaetva構{dNode6vac2va成{dNode6vac0wad2ypyPxawb構成xaka成xasa成vaetva造{dNode6vac0wad2ypdDxawb構造xaka造xasa造vaetwad0xawa構xaka構xasa構vaesvaす{dNode6vac3vaる{dNode6vac0wad3ypyQWxawbするxakaるxasaるvaetvaば{dNode6vac0wad1ypcxaweすばらしいxakaばxasdばらしいvaetvaず{dNode6vac0wad1ypkxawfすずけんさんxakaずxaseずけんさんvaetwad2ypXexawaすxakaすxasaすvaetvaパ{dNode6vac3vaー{dNode6vac0wad1ypyxawcパーツxakaーxasbーツvaetvaッ{dNode6vac0wad1ypmxawcパッチxakaッxasbッチvaetvaフ{dNode6vac0wad1ypNxawgパフォーマンスxakaフxasfフォーマンスvaetwad0xawaパxakaパxasaパvaesva特{dNode6vac0wad1ypzxawb特徴xaka特xasb特徴vaetvaR{dNode6vac4vau{dNode6vac2vas{dNode6vac0wad<yp{@AEMPRTVXZ`>xawdRustxakasxasbstvaetvab{dNode6vac0wad3ypy{|xawdRubyxakabxasbbyvaetwad0xawbRuxakauxasauvaesvae{dNode6vac3val{dNode6vac0wad1ypZxawgReleasexakalxaseleasevaetvap{dNode6vac0wad1yp^xawfReportxakapxasdportvaetvaa{dNode6vac0wad2ypz{xawfReadmexakaaxasdadmevaetwad0xawbRexakaexasaevaesvaC{dNode6vac0wad1yppxawbRCxakaCxasaCvaetvai{dNode6vac0wad2ypzIxawdRiakxakaixasciakvaetwad0xawaRxakaRxasaRvaesvat{dNode6vac4vah{dNode6vac0wad9yp{@AEMPRTVxawcthexakahxasbhevaetvae{dNode6vac0wad2yp\axawftecompxakaexaseecompvaetvaw{dNode6vac0wad4yprPSVxawdtwtrxakawxascwtrvaetvar{dNode6vac0wad2yp@sxawetrunkxakarxasdrunkvaetwad0xawatxakatxasatvaesvab{dNode6vac4vao{dNode6vac0wad8yp{@AEMPRTxawdbookxakaoxascookvaetvae{dNode6vac0wad4ypU[]dxawdbetaxakaexascetavaetvay{dNode6vac0wad1yp^xawbbyxakayxasayvaetvaa{dNode6vac0wad1yp[xawibackwardsxakaaxashackwardsvaetwad0xawabxakabxasabvaesva性{dNode6vac0wad1yp}xawb性能xaka性xasb性能vaetvaテ{dNode6vac2vaス{dNode6vac1vaケ{dNode6vac0wad1yp~xawfテストケースxakaケxascケースvaetwad2yp}Lxawcテストxakaスxasbストvaetvaー{dNode6vac0wad2ypcexawcテーマxakaーxasbーマvaetwad0xawaテxakaテxasaテvaesvak{dNode6vac3vau{dNode6vac0wad2yp}`xawhkuromojixakauxasguromojivaetvao{dNode6vac0wad4yp]`bcxawdkopfxakaoxascopfvaetvai{dNode6vac0wad1ypOxawfkibanaxakaixaseibanavaetwad0xawakxakakxasakvaesva追{dNode6vac2va加{dNode6vac0wad4yp}Q~xawb追加xaka加xasa加vaetva跡{dNode6vac0wad1yp}xawb追跡xaka跡xasa跡vaetwad0xawa追xaka追xasa追vaesvaマ{dNode6vac0wad1yp~xaweマニアックxakaマxaseマニアックvaetvaツ{dNode6vac0wad2yp~Wxawcツールxakaツxascツールvaetvaセ{dNode6vac3vaッ{dNode6vac2vaト{dNode6vac0wad7yp~eer}ABxawfセットアップxakaトxasdトアップvaetvaシ{dNode6vac0wad2ypCexaweセッションxakaシxascションvaetwad0xawbセッxakaッxasaッvaesvaキ{dNode6vac0wad1yprxawfセキュリティxakaキxaseキュリティvaetvaミ{dNode6vac0wad2ypGlxawdセミナーxakaミxascミナーvaetwad0xawaセxakaセxasaセvaesva違{dNode6vac0wad1ypxawb違いxaka違xasb違いvaetvaリ{dNode6vac4vaク{dNode6vac0wad1ypBxaweリクエストxakaクxasdクエストvaetvaリ{dNode6vac0wad<ypDVWXY[]`adhlnpruy}~BDHKQnprtXm~DIMNbmxGHM>xawdリリースxakaリxascリースvaetvaフ{dNode6vac0wad1ypcxawhリファクタリングxakaフxasgファクタリングvaetvaソ{dNode6vac0wad1yp~xawdリソースxakaソxascソースvaetwad0xawaリxakaリxasaリvaesvaメ{dNode6vac2vaモ{dNode6vac0wad5ypCkDQJxawbメモxakaモxasaモvaetvaイ{dNode6vac0wad1yppxawcメインxakaイxasbインvaetwad0xawaメxakaメxasaメvaesvaさ{dNode6vac2vaら{dNode6vac0wad1ypexawbさらxakaらxasaらvaetvaん{dNode6vac0wad1ypnxawbさんxakaんxasaんvaetwad3ypDdrxawaさxakaさxasaさvaetvaれ{dNode6vac0wad3ypDdrxawaれxakaれxasaれvaetva触{dNode6vac0wad4ypIJECxawb触っxaka触xasb触っvaetva辞{dNode6vac1va分{dNode6vac0wad1yp~xawd辞書分離xaka分xasb分離vaetwad7ypKL`n@OOxawb辞書xaka辞xasb辞書vaetva更{dNode6vac0wad3ypK^_xawb更新xaka更xasb更新vaetva注{dNode6vac0wad4ypKnrWxawc注意点xaka注xasc注意点vaetvaK{dNode6vac2vau{dNode6vac0wad9ypLQYmK@HIExawhKuromojixakauxasguromojivaetvai{dNode6vac2vab{dNode6vac0wad6ypz@AXtLxawfKibanaxakabxasdbanavaetvan{dNode6vac0wad1ypfxawfKindlexakanxasdndlevaetwad0xawbKixakaixasaivaeswad0xawaKxakaKxasaKvaesvaカ{dNode6vac2vaス{dNode6vac0wad2ypLOxawdカスタムxakaスxascスタムvaetvaン{dNode6vac0wad1yp{xawgカンファレンスxakaンxasfンファレンスvaetwad0xawaカxakaカxasaカvaesva設{dNode6vac2va定{dNode6vac0wad3ypLcGxawb設定xaka定xasa定vaetva計{dNode6vac0wad1ypIxawe設計手法等xaka計xasd計手法等vaetwad0xawa設xaka設xasa設vaesva再{dNode6vac1vaび{dNode6vac0wad1ypOxawb再びxakaびxasaびvaetwad1ypjxawa再xaka再xasa再vaetvaプ{dNode6vac2vaラ{dNode6vac0wad<ypWz@A^rAgst|~B>xaweプラグインxakaラxasdラグインvaetvaロ{dNode6vac2vaキ{dNode6vac0wad1ypPxawdプロキシxakaキxasbキシvaetvaグ{dNode6vac0wad1ypGxawgプログラミングxakaグxaseグラミングvaetwad0xawbプロxakaロxasaロvaeswad0xawaプxakaプxasaプvaesva入{dNode6vac4va門{dNode6vac0wad:ypXZ`MuvEHIhxawb入門xaka門xasa門vaetvaっ{dNode6vac0wad1ypuxawb入っxakaっxasaっvaetvaれ{dNode6vac0wad2ypgBxawb入れxakaれxasaれvaetva信{dNode6vac0wad1ypCxawb入信xaka信xasa信vaetwad0xawa入xaka入xasa入vaesva終{dNode6vac0wad1ypXxawc終わっxaka終xasc終わっvaetva買{dNode6vac2vaっ{dNode6vac0wad1yp[xawb買っxakaっxasaっvaetvaい{dNode6vac0wad1ypbxawd買いましxakaいxascいましvaetwad0xawa買xaka買xasa買vaesvaよ{dNode6vac4vaか{dNode6vac0wad1yp[xawcよかっxakaかxasbかっvaetvaく{dNode6vac1vaわ{dNode6vac0wad1ypYxaweよくわかるxakaわxascわかるvaetwad1ypLxawbよくxakaくxasaくvaetvaり{dNode6vac1vaも{dNode6vac0wad1yp\xawcよりもxakaもxasaもvaetwad<ypVXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~@ABCDEFGHIJKLMNOPQR>xawbよりxakaりxasaりvaetvaう{dNode6vac0wad1ypfxawbようxakaうxasaうvaetwad0xawaよxakaよxasaよvaesva探{dNode6vac3va訪{dNode6vac0wad1yp^xawb探訪xaka訪xasa訪vaetvaし{dNode6vac0wad1yp{xawb探しxakaしxasaしvaetva索{dNode6vac0wad1ypNxawb探索xaka索xasa索vaetwad0xawa探xaka探xasa探vaesva={dNode6vac0wad2yp^Oxawa=xaka=xasa=vaetva>{dNode6vac0wad1yp^xawa>xaka>xasa>vaetvaは{dNode6vac0wad:yp`aC^faUQRxawaはxakaはxasaはvaetvaじ{dNode6vac2vaま{dNode6vac2vaし{dNode6vac0wad3yp`axawdじめましxakaしxasaしvaetvaす{dNode6vac0wad1ypRxawdじめますxakaすxasaすvaetwad0xawcじめまxakaまxasaまvaesvaる{dNode6vac0wad1ypUxawcじめるxakaるxasaるvaetwad0xawbじめxakaじxasbじめvaesva仮{dNode6vac1va実{dNode6vac0wad1ypKxawc仮実装xaka実xasb実装vaetwad2ypaxawa仮xaka仮xasa仮vaetva微{dNode6vac0wad1ypcxawc微調整xaka微xasc微調整vaetva合{dNode6vac0wad1ypcxawb合わxaka合xasb合わvaetvaせ{dNode6vac0wad1ypcxawaせxakaせxasaせvaetva標{dNode6vac0wad1yphxawb標準xaka標xasb標準vaetvaタ{dNode6vac0wad1yphxaweターミナルxakaタxaseターミナルvaetvaウ{dNode6vac0wad1yphxawiウィンドウグループxakaウxasiウィンドウグループvaetva便{dNode6vac1va機{dNode6vac0wad1ypJxawf便利機能紹介xaka機xasd機能紹介vaetwad1yphxawb便利xaka便xasb便利vaetvah{dNode6vac4vao{dNode6vac0wad1ypixawihomeshickxakaoxashomeshickvaetvaa{dNode6vac4vav{dNode6vac0wad1ypZxawdhavexakavxasbvevaetvat{dNode6vac0wad1ypgxawjhatenatechxakatxashtenatechvaetvac{dNode6vac0wad4yprPSVxawdhackxakacxasbckvaetvad{dNode6vac0wad2ypxXxawmhadoopreadingxakadxaskdoopreadingvaetwad0xawbhaxakaaxasaavaesvae{dNode6vac0wad2yp^Fxawhherokujpxakaexasgerokujpvaetvac{dNode6vac0wad1ypcxawchcjxakacxasbcjvaetwad0xawahxakahxasahvaesvaz{dNode6vac2vas{dNode6vac0wad1ypjxawczshxakasxasbshvaetvao{dNode6vac0wad1ypUxawlzoomdata作りましxakaoxaskoomdata作りましvaetwad0xawazxakazxasazvaesva化{dNode6vac0wad1ypkxawa化xaka化xasa化vaetva退{dNode6vac0wad2yplUxawb退職xaka退xasb退職vaetvaビ{dNode6vac2vaル{dNode6vac0wad2ypmPxawcビルドxakaルxasbルドvaetvaッ{dNode6vac0wad1yplxawfビッグデータxakaッxaseッグデータvaetwad0xawaビxakaビxasaビvaesva&{dNode6vac0wad1ypoxawa&xaka&xasa&vaetva頂{dNode6vac2vaき{dNode6vac0wad1yppxawd頂きましxakaきxascきましvaetvaい{dNode6vac0wad1ypjxawg頂いちゃいましxakaいxasfいちゃいましvaetwad0xawa頂xaka頂xasa頂vaesva勉{dNode6vac2va運{dNode6vac0wad1yprxawi勉強会運営座談会っxaka運xasf運営座談会っvaetva第{dNode6vac0wad2ypwcxawd勉強会第xaka第xasa第vaetwad<ypql}F\_akrPVaiz>xawc勉強会xaka勉xasc勉強会vaetva受{dNode6vac0wad1ypqxawb受付xaka受xasb受付vaetva運{dNode6vac0wad1ypsxawb運営xaka運xasb運営vaetva。{dNode6vac0wad<ypsxFMNPT_bfgimowGLSWX_z}FIJPRXYZ[\^_acfjkloqrwxBEFKQSVXY[\acgijovzDI>xawa。xaka。xasa。vaetvaく{dNode6vac0wad1ypuxawbくるxakaくxasbくるvaetvaち{dNode6vac0wad2ypuCxawcちょっxakaちxascちょっvaetva長{dNode6vac0wad1ypwxawe長期出張用xaka長xase長期出張用vaetvaい{dNode6vac5vaく{dNode6vac0wad1ypwxawdいくつかxakaくxascくつかvaetvaつ{dNode6vac0wad1ypgxawcいつもxakaつxasbつもvaetvaる{dNode6vac0wad1ypgxawbいるxakaるxasaるvaetvaま{dNode6vac0wad1ypexawdいまさらxakaまxascまさらvaetvaろ{dNode6vac0wad1yppxawdいろいろxakaろxascろいろvaetwad2ypOdxawaいxakaいxasaいvaetva開{dNode6vac2va催{dNode6vac1va期{dNode6vac0wad1yp{xawd開催期間xaka期xasb期間vaetwad<ypxMNPT_bimosvwGLS_jlxA>xawb開催xaka催xasa催vaetva発{dNode6vac2va中{dNode6vac0wad1yp|xawc開発中xaka中xasa中vaetva方{dNode6vac0wad1ypIxawe開発方法論xaka方xasc方法論vaetwad0xawb開発xaka発xasa発vaeswad0xawa開xaka開xasa開vaesvaナ{dNode6vac0wad2ypyxawgナイトセミナーxakaナxasgナイトセミナーvaetva方{dNode6vac2va法{dNode6vac0wad6ypz@As`Qxawb方法xaka法xasa法vaetva教{dNode6vac0wad1yp\xawb方教xaka教xasa教vaetwad2yp{Cxawa方xaka方xasa方vaetva応{dNode6vac0wad1yp{xawb応募xaka応xasb応募vaetvaジ{dNode6vac2vaョ{dNode6vac0wad1ypExawdジョインxakaョxascョインvaetvaャ{dNode6vac0wad1ypfxawhジャストシステムxakaャxasgャストシステムvaetwad0xawaジxakaジxasaジvaesva分{dNode6vac3va析{dNode6vac0wad1ypFxawh分析基盤構築入門xaka析xasg析基盤構築入門vaetva散{dNode6vac0wad2yp}Ixawb分散xaka散xasa散vaetva離{dNode6vac0wad1yp@xawb分離xaka離xasa離vaetwad0xawa分xaka分xasa分vaesva一{dNode6vac0wad1ypFxawb一部xaka一xasb一部vaetva執{dNode6vac0wad2ypFvxawb執筆xaka執xasb執筆vaetva品{dNode6vac0wad1ypKxawb品詞xaka品xasb品詞vaetva単{dNode6vac0wad1ypKxawb単語xaka単xasb単語vaetva抜{dNode6vac0wad1ypKxawb抜きxaka抜xasb抜きvaetva書{dNode6vac0wad1ypKxawb書いxaka書xasb書いvaetvae{dNode6vac5val{dNode6vac2vas{dNode6vac2vaj{dNode6vac0wad<ypKMNPT_bimowGLS_jxA>xawoelasticsearchjpxakajxasbjpvaetva勉{dNode6vac0wad2ypjxxaw Pelasticsearch勉強会xaka勉xasc勉強会vaetwad<ypoKM]`bcetw{|~O`>xawmelasticsearchxakasxasfsearchvaetvao{dNode6vac0wad1ypqxawielasticonxakaoxasbonvaetwad1ypkxawgelasticxakalxasflasticvaetvaf{dNode6vac0wad1ypMxawcefkxakafxasbfkvaetvad{dNode6vac0wad1ypVxawgeditionxakadxasfditionvaetvas{dNode6vac0wad1yp^xawbesxakasxasasvaetvax{dNode6vac0wad4yptw{|xawhextendedxakaxxasgxtendedvaetwad0xawaexakaexasaevaesva物{dNode6vac0wad1ypLxawa物xaka物xasa物vaetva壊{dNode6vac0wad1ypLxawc壊れるxaka壊xasc壊れるvaetva年{dNode6vac0wad1ypLxawa年xaka年xasa年vaetva基{dNode6vac0wad1ypOxawb基本xaka基xasb基本vaetva技{dNode6vac0wad1ypOxawb技術xaka技xasb技術vaetva歴{dNode6vac0wad1ypUxawb歴史xaka歴xasb歴史vaetva,{dNode6vac0wad1ypZxawa,xaka,xasa,vaetvaw{dNode6vac2vae{dNode6vac0wad1ypZxawbwexakaexasaevaetvai{dNode6vac0wad1ypxawiwikipediaxakaixashikipediavaetwad0xawawxakawxasawvaesvau{dNode6vac0wad1yp\xawiunpluggedxakauxasiunpluggedvaetvaネ{dNode6vac0wad1yp\xawfネットワークxakaネxasfネットワークvaetva大{dNode6vac2va阪{dNode6vac0wad1ypbxawb大阪xaka阪xasa阪vaetva量{dNode6vac0wad1ypfxawb大量xaka量xasa量vaetwad0xawa大xaka大xasa大vaesva京{dNode6vac0wad1ypbxawb京都xaka京xasb京都vaetva間{dNode6vac0wad1ypdxawb間近xaka間xasb間近vaetva進{dNode6vac0wad1ypexawb進化xaka進xasb進化vaetva形{dNode6vac0wad1ypfxawe形態素解析xaka形xase形態素解析vaetvaあ{dNode6vac5vaれ{dNode6vac0wad1ypfxawbあれxakaれxasaれvaetvaり{dNode6vac0wad1ypLxaweありましてxakaりxasdりましてvaetvaえ{dNode6vac0wad1ypTxawcあえずxakaえxasbえずvaetvaる{dNode6vac0wad2yp[Zxawbあるxakaるxasaるvaetvaけ{dNode6vac0wad1yp_xawdあけましxakaけxascけましvaetwad0xawaあxakaあxasaあvaesvaこ{dNode6vac4vaれ{dNode6vac0wad1ypfxawbこれxakaれxasaれvaetvaと{dNode6vac0wad3ypZOZxawbことxakaとxasaとvaetvaの{dNode6vac0wad1ypaxawbこのxakaのxasaのvaetvaる{dNode6vac0wad1ypaxawbこるxakaるxasaるvaetwad0xawaこxakaこxasaこvaesva@{dNode6vac0wad5ypfgPVaxawa@xaka@xasa@vaetva使{dNode6vac2vaっ{dNode6vac0wad2ypjlxawb使っxakaっxasaっvaetvaい{dNode6vac0wad1ypfxawb使いxakaいxasaいvaetwad0xawa使xaka使xasa使vaesva向{dNode6vac0wad1yprxawb向けxaka向xasb向けvaetvaト{dNode6vac2vaニ{dNode6vac0wad1ypsxawfトレーニングxakaニxascニングvaetvaシ{dNode6vac0wad1yp}xawfトレーシングxakaシxascシングvaetwad0xawcトレーxakaトxascトレーvaesvaダ{dNode6vac0wad1ypxxawkダイナミックスクリプトxakaダxaskダイナミックスクリプトvaetva　{dNode6vac0wad6ypyqwy{|xawa　xaka　xasa　vaetvaき{dNode6vac1vaま{dNode6vac0wad<ypzMWYinosBJ]ov>xawcきましxakaまxasbましvaetwad1ypaxawaきxakaきxasaきvaetva簡{dNode6vac0wad1ypxawb簡単xaka簡xasb簡単vaetva利{dNode6vac1va例{dNode6vac0wad1ypLxawc利用例xaka例xasa例vaetwad5ypFIX`Wxawb利用xaka利xasb利用vaetvaバ{dNode6vac3vaー{dNode6vac0wad2ypJ@xaweバージョンxakaーxasdージョンvaetvaッ{dNode6vac0wad1yp]xawfバックアップxakaッxaseックアップvaetvaグ{dNode6vac0wad2yptJxawbバグxakaグxasaグvaetwad0xawaバxakaバxasaバvaesva番{dNode6vac0wad1ypJxawb番号xaka番xasb番号vaetvag{dNode6vac2vai{dNode6vac0wad1ypMxawegihyoxakaixasdihyovaetvao{dNode6vac0wad<ypnXmvy~DHILMNW^hpGMNQ>xawegosenxakaoxasdosenvaetwad0xawagxakagxasagvaesva_{dNode6vac0wad5ypMrPSVxawa_xaka_xasa_vaetva収{dNode6vac0wad1ypOxawb収集xaka収xasb収集vaetva~{dNode6vac0wad1ypOxawa~xaka~xasa~vaetva可{dNode6vac2va視{dNode6vac1va編{dNode6vac0wad1ypOxawd可視化編xaka編xasa編vaetwad2ypWWxawc可視化xaka視xasb視化vaetva能{dNode6vac0wad1ypXxawb可能xaka能xasa能vaetwad0xawa可xaka可xasa可vaesva手{dNode6vac0wad2ypOdxawb手伝xaka手xasb手伝vaetva転{dNode6vac0wad1ypTxawb転職xaka転xasb転職vaetva現{dNode6vac0wad1ypWxawe現状確認会xaka現xase現状確認会vaetva最{dNode6vac2va新{dNode6vac0wad1ypXxawb最新xaka新xasa新vaetva終{dNode6vac0wad1ypyxawc最終日xaka終xasb終日vaetwad0xawa最xaka最xasa最vaesva行{dNode6vac2vaっ{dNode6vac0wad5ypYPRijxawb行っxakaっxasaっvaetvaき{dNode6vac0wad2ypMSxawd行きましxakaきxascきましvaetwad0xawa行xaka行xasa行vaesva外{dNode6vac1va部{dNode6vac0wad1ypnxawc外部化xaka部xasb部化vaetwad1ypZxawa外xaka外xasa外vaetva世{dNode6vac0wad6ypZqwy{|xawb世界xaka世xasb世界vaetva知{dNode6vac0wad1ypZxawb知るxaka知xasb知るvaetva届{dNode6vac0wad1yp[xawd届きましxaka届xasd届きましvaetva柔{dNode6vac0wad1yp\xawb柔軟xaka柔xasb柔軟vaetva集{dNode6vac0wad1yp\xawb集計xaka集xasb集計vaetvaa{dNode6vac5val{dNode6vac0wad1yp]xawgaliasesxakalxasfliasesvaetvan{dNode6vac2vas{dNode6vac0wad2yp``xawhanalysisxakasxascsisvaetvaz{dNode6vac0wad4yptw{|xawganalyzexakazxasbzevaetwad0xaweanalyxakanxasdnalyvaesvap{dNode6vac0wad1ypOxawfapachexakapxasepachevaetvaw{dNode6vac0wad2ypPRxawiawssummitxakawxashwssummitvaetvau{dNode6vac2vag{dNode6vac0wad1yphxawdaugjxakagxasbgjvaetvat{dNode6vac0wad1yp|xaw YautoGeneratePhraseQueriesxakatxas WtoGeneratePhraseQueriesvaetwad0xawbauxakauxasauvaeswad0xawaaxakaaxasaavaesva画{dNode6vac0wad4yp]`bKxawb画面xaka画xasb画面vaetva複{dNode6vac1va辞{dNode6vac0wad1ypxawd複数辞書xaka辞xasb辞書vaetwad1yp^xawb複数xaka複xasb複数vaetva登{dNode6vac0wad2yp^Kxawb登録xaka登xasb登録vaetvaj{dNode6vac3vav{dNode6vac0wad1ypaxawijvmcasualxakavxashvmcasualvaetvab{dNode6vac0wad1ypixawejbugjxakabxasdbugjvaetvaa{dNode6vac2vaw{dNode6vac0wad1yplxawfjawsugxakawxasdwsugvaetvar{dNode6vac0wad1yp@xawcjarxakarxasarvaetwad0xawbjaxakaaxasaavaeswad0xawajxakajxasajvaesvar{dNode6vac2vae{dNode6vac0wad1ypbxawdrestxakaexascestvaetvai{dNode6vac2vaa{dNode6vac0wad2ypzIxawfriakjpxakaaxasdakjpvaetvav{dNode6vac0wad1ypxaweriverxakavxascvervaetwad0xawbrixakaixasaivaeswad0xawarxakarxasarvaesva概{dNode6vac0wad1ypcxawb概要xaka概xasb概要vaetva電{dNode6vac0wad1ypdxawc電子版xaka電xasc電子版vaetva発{dNode6vac2va売{dNode6vac0wad2ypduxawb発売xaka売xasa売vaetva表{dNode6vac0wad1ypcxawb発表xaka表xasa表vaetwad0xawa発xaka発xasa発vaesvaご{dNode6vac0wad1ypfxaweございますxakaごxaseございますvaetva翻{dNode6vac0wad3yphtuxawb翻訳xaka翻xasb翻訳vaetva奇{dNode6vac0wad1ypixawb奇妙xaka奇xasb奇妙vaetva動{dNode6vac0wad1ypixawb動作xaka動xasb動作vaetva元{dNode6vac0wad1ypkxawa元xaka元xasa元vaetva時{dNode6vac2va系{dNode6vac0wad1ypoxawc時系列xaka系xasb系列vaetva代{dNode6vac0wad1ypaxawd時代到来xaka代xasc代到来vaetwad0xawa時xaka時xasa時vaesva管{dNode6vac1va画{dNode6vac0wad1ypsxawd管理画面xaka画xasb画面vaetwad2ypoKxawb管理xaka管xasb管理vaetva＆{dNode6vac1va「{dNode6vac0wad1ypjxawb＆「xaka「xasa「vaetwad2yprmxawa＆xaka＆xasa＆vaetva配{dNode6vac0wad1ypsxawb配置xaka配xasb配置vaetva版{dNode6vac0wad1ypuxawa版xaka版xasa版vaetva公{dNode6vac0wad2ypw}xawb公開xaka公xasb公開vaetva主{dNode6vac0wad4yp}F_kxawb主催xaka主xasb主催vaetva疑{dNode6vac0wad1ypxawc疑問点xaka疑xasc疑問点vaetvaX{dNode6vac0wad2ypDbxawfXperiaxakaXxasfXperiavaetvaZ{dNode6vac1vai{dNode6vac0wad3ypz{}xawfZipkinxakaixaseipkinvaetwad2ypDbxawaZxakaZxasaZvaetva故{dNode6vac0wad1ypDxawb故障xaka故xasb故障vaetva『{dNode6vac0wad4ypGG\axawa『xaka『xasa『vaetva』{dNode6vac0wad4ypGG\axawa』xaka』xasa』vaetva刊{dNode6vac0wad1ypGxawd刊行記念xaka刊xasd刊行記念vaetvaY{dNode6vac0wad1ypHxawhYokozunaxakaYxashYokozunavaetva気{dNode6vac0wad3ypH[Gxawa気xaka気xasa気vaetva点{dNode6vac0wad2ypHGxawa点xaka点xasa点vaetva遊{dNode6vac0wad2ypMSxawb遊びxaka遊xasb遊びvaetvax{dNode6vac1vam{dNode6vac0wad1ypNxawcxmlxakamxasbmlvaetwad1ypsxawaxxakaxxasaxvaetvaモ{dNode6vac3vaジ{dNode6vac0wad1ypSxaweモジュールxakaジxasdジュールvaetvaデ{dNode6vac2vaレ{dNode6vac0wad1ypdxaweモデレータxakaレxascレータvaetvaリ{dNode6vac0wad1ypIxaweモデリングxakaリxascリングvaetwad0xawbモデxakaデxasaデvaesvaー{dNode6vac0wad1yp[xawhモーショノロジーxakaーxasgーショノロジーvaetwad0xawaモxakaモxasaモvaesva雑{dNode6vac0wad1ypTxawb雑感xaka雑xasb雑感vaetva＋{dNode6vac0wad4ypUdd_xawa＋xaka＋xasa＋vaetva悩{dNode6vac0wad1ypUxawb悩みxaka悩xasb悩みvaetva事{dNode6vac0wad1ypUxawb事とxaka事xasb事とvaetva以{dNode6vac0wad1ypXxawb以上xaka以xasb以上vaetvaポ{dNode6vac2va回{dNode6vac0wad1ypYxawgポモドーロ回しxaka回xasb回しvaetvaテ{dNode6vac0wad1ypYxaw Qポモドーロテクニック入門読みましたxakaテxaslテクニック入門読みましたvaetwad0xaweポモドーロxakaポxaseポモドーロvaesva訳{dNode6vac0wad2ypZ[xawb訳しxaka訳xasb訳しvaetva―{dNode6vac0wad2yp\axawa―xaka―xasa―vaetva人{dNode6vac0wad1yp\xawb人気xaka人xasb人気vaetvaえ{dNode6vac0wad1yp\xawaえxakaえxasaえvaetva!{dNode6vac1va!{dNode6vac0wad1yp^xawb!!xaka!xasa!vaetwad1ypjxawa!xaka!xasa!vaetvaユ{dNode6vac1vaー{dNode6vac0wad1ypixawhユーザーグループxakaーxaseーグループvaetwad1yp`xawcユーザxakaユxascユーザvaetva＠{dNode6vac0wad1ypaxawa＠xaka＠xasa＠vaetva竹{dNode6vac0wad1ypaxawb竹橋xaka竹xasb竹橋vaetva先{dNode6vac0wad1ypaxawb先生xaka先xasb先生vaetva担{dNode6vac0wad1ypexawb担当xaka担xasb担当vaetva勝{dNode6vac0wad1ypfxawb勝手xaka勝xasb勝手vaetva確{dNode6vac1va中{dNode6vac0wad1yppxawc確認中xaka中xasa中vaetwad1ypfxawb確認xaka確xasb確認vaetva兼{dNode6vac0wad1ypfxawb兼ねxaka兼xasb兼ねvaetva活{dNode6vac0wad1yplxawd活用事例xaka活xasd活用事例vaetva講{dNode6vac0wad1ypnxawb講演xaka講xasb講演vaetva聞{dNode6vac0wad1ypnxawb聞いxaka聞xasb聞いvaetva【{dNode6vac0wad4yptJMNxawa【xaka【xasa【vaetva】{dNode6vac1va({dNode6vac0wad1yptxawb】(xaka(xasa(vaetwad3ypJMNxawa】xaka】xasa】vaetva輪{dNode6vac0wad1ypuxawe輪読会始めxaka輪xase輪読会始めvaetvaソ{dNode6vac1vaコ{dNode6vac0wad3ypxXgxawlソースコードリーディングxakaコxasiコードリーディングvaetwad1ypPxawcソースxakaソxascソースvaetva２{dNode6vac0wad2ypzAxawa２xaka２xasa２vaetva残{dNode6vac2vaり{dNode6vac0wad1ypzxawb残りxakaりxasaりvaetvaタ{dNode6vac0wad1yp~xawd残タスクxakaタxascタスクvaetwad0xawa残xaka残xasa残vaesva周{dNode6vac0wad2yp{~xawb周りxaka周xasb周りvaetva値{dNode6vac0wad1yp|xawa値xaka値xasa値vaetva壁{dNode6vac0wad1ypxawa壁xaka壁xasa壁vaetva差{dNode6vac0wad1yp@xawa差xaka差xasa差vaetva替{dNode6vac0wad1yp@xawb替えxaka替xasb替えvaetva失{dNode6vac0wad2yp@Lxawb失敗xaka失xasb失敗vaetva貢{dNode6vac0wad1ypAxawb貢献xaka貢xasb貢献vaetva秘{dNode6vac0wad1ypExawb秘密xaka秘xasb秘密vaetva＃{dNode6vac0wad1ypFxawa＃xaka＃xasa＃vaetva～{dNode6vac0wad1ypHxawa～xaka～xasa～vaetva問{dNode6vac1va点{dNode6vac0wad1ypWxawd問題点編xaka点xasb点編vaetwad1ypLxawb問題xaka問xasb問題vaetva重{dNode6vac0wad2ypMNxawb重要xaka重xasb重要vaetva次{dNode6vac0wad1ypNxawb次期xaka次xasb次期vaetva久{dNode6vac0wad1ypOxawb久々xaka久xasb久々vaetva渋{dNode6vac0wad1ypPxawb渋谷xaka渋xasb渋谷vaetva小{dNode6vac0wad1ypQxawb小さxaka小xasb小さvaetva箱{dNode6vac0wad1ypQxawa箱xaka箱xasa箱vaetva脱{dNode6vac0wad1ypQxawb脱出xaka脱xasb脱出vaetva親{dNode6vac0wad1ypUxawb親子xaka親xasb親子vaetva楽{dNode6vac0wad1ypUxawd楽しめるxaka楽xasd楽しめるvaetva絵{dNode6vac0wad1ypUxawb絵本xaka絵xasb絵本vaetva英{dNode6vac2va語{dNode6vac0wad1ypUxawb英語xaka語xasa語vaetva単{dNode6vac0wad1ypLxawc英単語xaka単xasb単語vaetwad0xawa英xaka英xasa英vaesva本{dNode6vac0wad3ypUffxawa本xaka本xasa本vaetvaミ{dNode6vac0wad1yp]xawfミニセミナーxakaミxasfミニセミナーvaetva会{dNode6vac0wad1yp_xawb会社xaka会xasb会社vaetva東{dNode6vac0wad1ypaxawb東京xaka東xasb東京vaetva７{dNode6vac0wad1ypcxawb７回xaka７xasb７回vaetva備{dNode6vac0wad6yper}ABFxawc備忘録xaka備xasc備忘録vaetva５{dNode6vac0wad1ypexawa５xaka５xasa５vaetva他{dNode6vac0wad1ypexawb他くxaka他xasb他くvaetvaど{dNode6vac0wad1ypfxawbどんxakaどxasbどんvaetva速{dNode6vac2va読{dNode6vac0wad1ypfxawb速読xaka読xasa読vaetva報{dNode6vac0wad2ypxHxawb速報xaka報xasa報vaetwad0xawa速xaka速xasa速vaesva文{dNode6vac0wad1yppxawb文章xaka文xasb文章vaetva抽{dNode6vac0wad1yppxawb抽出xaka抽xasb抽出vaetva４{dNode6vac0wad1yprxawa４xaka４xasa４vaetva系{dNode6vac0wad1ypsxawa系xaka系xasa系vaetva３{dNode6vac0wad1yp}xawa３xaka３xasa３vaetva込{dNode6vac0wad1ypxawb込みxaka込xasb込みvaetva教{dNode6vac0wad1ypCxawa教xaka教xasa教vaetva・{dNode6vac0wad2ypIIxawa・xaka・xasa・vaetva座{dNode6vac0wad1ypIxawc座談会xaka座xasc座談会vaetva修{dNode6vac0wad1ypJxawb修正xaka修xasb修正vaetvan{dNode6vac0wad1ypLxawenaistxakanxasenaistvaet>wad0xaw`xak`xas`vaesvgisArraysvgsummary3xdtypeeRadixvdnode{dNode6vac<va0{dNode6vac:va0{dNode6vac3vaく{dNode6vac0wad1yprxawe00くらいxakaくxascくらいvaetva現{dNode6vac0wad1ypZxawd00現在xaka現xasb現在vaetva時{dNode6vac0wad1yp[xawd00時点xaka時xasb時点vaetwad4ypo~[[xawb00xaka0xasa0vaetva1{dNode6vac0wad2yp[\xawb01xaka1xasa1vaetva2{dNode6vac0wad2yp~fxawb02xaka2xasa2vaetva3{dNode6vac0wad4ypeN}}xawb03xaka3xasa3vaetva4{dNode6vac0wad3yp}Z[xawb04xaka4xasa4vaetva5{dNode6vac0wad3yp||uxawb05xaka5xasa5vaetva6{dNode6vac0wad2ypr|xawb06xaka6xasa6vaetva8{dNode6vac0wad2ypSHxawb08xaka8xasa8vaetva9{dNode6vac0wad1ypexawb09xaka9xasa9vaetva対{dNode6vac0wad1ypGxawb0対xaka対xasa対vaetwad<ypRR~DIJUUVVWWWWXXXYYYY[[\]]^^addddhpr}}ABBHJKRRrrzXX[mmmmttvv~CDHILLMMNmM>xawa0xaka0xasa0vaetva1{dNode6vac<va0{dNode6vac3va0{dNode6vac0wad:ypvwFGHNO|}~xawd100本xaka0xasb0本vaetva月{dNode6vac2vaく{dNode6vac0wad1ypjxawe10月くらxakaくxasbくらvaetva末{dNode6vac0wad1ypJxawd10月末xaka末xasa末vaetwad0xawc10月xaka月xasa月vaesva回{dNode6vac0wad1yp_xawc10回xaka回xasa回vaetwad<yproVY`ahlnpy~DHKg>xawb10xaka0xasa0vaetva1{dNode6vac1va回{dNode6vac0wad1ypFxawc11回xaka回xasa回vaetwad2yprZxawb11xaka1xasa1vaetva2{dNode6vac2va月{dNode6vac0wad1ypaxawc12月xaka月xasa月vaetva回{dNode6vac0wad1yp}xawc12回xaka回xasa回vaetwad6ypS^}ugxawb12xaka2xasa2vaetva4{dNode6vac3va0{dNode6vac0wad1ypxxawj140人くらいくらいxaka0xash0人くらいくらいvaetva8{dNode6vac0wad1ypoxawf148121xaka8xasd8121vaetva回{dNode6vac0wad1ypPxawc14回xaka回xasa回vaetwad1ypsxawb14xaka4xasa4vaetva5{dNode6vac2va日{dNode6vac0wad1ypRxawd15日目xaka日xasb日目vaetva号{dNode6vac0wad1ypwxawc15号xaka号xasa号vaetwad1yp^xawb15xaka5xasa5vaetva6{dNode6vac0wad4ypVka[xawb16xaka6xasa6vaetva7{dNode6vac1va日{dNode6vac0wad1yp_xawc17日xaka日xasa日vaetwad3yp[}xawb17xaka7xasa7vaetva8{dNode6vac1va日{dNode6vac0wad1yplxawd18日目xaka日xasb日目vaetwad3ypde\xawb18xaka8xasa8vaetva9{dNode6vac0wad3ypo[\xawb19xaka9xasa9vaetva年{dNode6vac0wad2ypcAxawb1年xaka年xasa年vaetva日{dNode6vac1va目{dNode6vac0wad6ypmnvDJqxawc1日目xaka目xasa目vaetwad1ypZxawb1日xaka日xasa日vaetva回{dNode6vac1va目{dNode6vac0wad1ypsxawc1回目xaka目xasa目vaetwad3ypsADxawb1回xaka回xasa回vaetva度{dNode6vac0wad1ypwxawb1度xaka度xasa度vaetva章{dNode6vac0wad1yp~xawb1章xaka章xasa章vaetva弾{dNode6vac0wad1ypAxawb1弾xaka弾xasa弾vaetva対{dNode6vac0wad1ypnxawb1対xaka対xasa対vaetva週{dNode6vac0wad1ypMxawc1週間xaka週xasb週間vaet>wad<ypWDG\bcdnovDIIUW[]]^```aaaddhlnnprruuuxyy}}~~AABBBBDDDHHJJKKKQQQQRRRnNde~DbbmnGGGMM>xawa1xaka1xasa1vaetva2{dNode6vac<va0{dNode6vac3va1{dNode6vac:va0{dNode6vac0wad1ypgxawd2010xaka0xasa0vaetva1{dNode6vac0wad2ypovxawd2011xaka1xasa1vaetva2{dNode6vac1va年{dNode6vac0wad1ypqxawe2012年xaka年xasa年vaetwad6yphoBK[\xawd2012xaka2xasa2vaetva3{dNode6vac1va年{dNode6vac0wad1yp{xawe2013年xaka年xasa年vaetwad8ypyPRZ[cdexawd2013xaka3xasa3vaetva4{dNode6vac1va年{dNode6vac0wad2ypQMxawe2014年xaka年xasa年vaetwad1yp|xawd2014xaka4xasa4vaetva5{dNode6vac1va年{dNode6vac0wad1ypHxawe2015年xaka年xasa年vaetwad1ypRxawd2015xaka5xasa5vaetva6{dNode6vac1va年{dNode6vac0wad1ypBxawe2016年xaka年xasa年vaetwad1ypIxawd2016xaka6xasa6vaetva7{dNode6vac1va年{dNode6vac0wad1yptxawe2017年xaka年xasa年vaetwad2ypCDxawd2017xaka7xasa7vaetva8{dNode6vac1va年{dNode6vac0wad2ypgCxawe2018年xaka年xasa年vaetwad2ypuvxawd2018xaka8xasa8vaetva9{dNode6vac1va年{dNode6vac0wad2ypk[xawe2019年xaka年xasa年vaetwad3ypmnoxawd2019xaka9xasa9vaetwad1yp^xawc201xaka1xasa1vaetva2{dNode6vac4va0{dNode6vac1va年{dNode6vac0wad3ypYO[xawe2020年xaka年xasa年vaetwad6ypeelmrIxawd2020xaka0xasa0vaetva1{dNode6vac1va年{dNode6vac0wad2yp]Zxawe2021年xaka年xasa年vaetwad1yp\xawd2021xaka1xasa1vaetva2{dNode6vac0wad2ypQ_xawd2022xaka2xasa2vaetva3{dNode6vac0wad1ypRxawd2023xaka3xasa3vaetwad0xawc202xaka2xasa2vaesva日{dNode6vac0wad1yphxawd20日目xaka日xasb日目vaetwad2ypu\xawb20xaka0xasa0vaetva1{dNode6vac0wad1ypoxawb21xaka1xasa1vaetva2{dNode6vac0wad1yp[xawb22xaka2xasa2vaetva3{dNode6vac1va6{dNode6vac0wad1yp[xawe23608xaka6xasc608vaetwad1yppxawb23xaka3xasa3vaetva4{dNode6vac1va日{dNode6vac0wad1ypCxawd24日目xaka日xasb日目vaetwad1yp[xawb24xaka4xasa4vaetva5{dNode6vac1va日{dNode6vac0wad2ypu|xawd25日目xaka日xasb日目vaetwad3ypoyZxawb25xaka5xasa5vaetva6{dNode6vac0wad3yps][xawb26xaka6xasa6vaetva7{dNode6vac0wad2yplrxawb27xaka7xasa7vaetva8{dNode6vac0wad2ypVYxawb28xaka8xasa8vaetva9{dNode6vac0wad1yp`xawb29xaka9xasa9vaetva回{dNode6vac1va目{dNode6vac0wad5ypR\xXBxawc2回目xaka目xasa目vaetwad1yp@xawb2回xaka回xasa回vaetva月{dNode6vac0wad4ypWJ[Ixawb2月xaka月xasa月vaetva号{dNode6vac0wad1ypmxawb2号xaka号xasa号vaetva種{dNode6vac0wad1ypxawc2種類xaka種xasb種類vaetva章{dNode6vac0wad3ypFGHxawb2章xaka章xasa章vaetva年{dNode6vac0wad1ypNxawb2年xaka年xasa年vaetva弾{dNode6vac0wad1ypbxawb2弾xaka弾xasa弾vaetvan{dNode6vac0wad3ypVuuxawc2ndxakanxasbndvaetva日{dNode6vac2va間{dNode6vac1va開{dNode6vac0wad1ypKxawe2日間開催xaka開xasb開催vaetwad1yp{xawc2日間xaka間xasa間vaetva目{dNode6vac0wad1yp{xawc2日目xaka目xasa目vaetwad0xawb2日xaka日xasa日vaesva週{dNode6vac0wad1ypixawb2週xaka週xasa週vaetvaつ{dNode6vac0wad1ypOxawb2つxakaつxasaつvaet>wad<ypXD\bcdesIIIIIIUVWWXXXXYY[[[\]]^`ddluDHRzCI~DLMN\bm>xawa2xaka2xasa2vaetva3{dNode6vac7va0{dNode6vac1va0{dNode6vac0wad1ypIxawc300xaka0xasa0vaetwad3ypo\\xawb30xaka0xasa0vaetva2{dNode6vac0wad1ypyxawb32xaka2xasa2vaetva章{dNode6vac0wad5ypwXXXZxawb3章xaka章xasa章vaetva番{dNode6vac0wad2ypKLxawc3番煎xaka番xasb番煎vaetvaつ{dNode6vac0wad1ypkxawb3つxakaつxasaつvaetva日{dNode6vac0wad1ypsxawc3日間xaka日xasb日間vaetva年{dNode6vac1va越{dNode6vac0wad1ypmxawc3年越xaka越xasa越vaetwad2ypv|xawb3年xaka年xasa年vaetwad<yp\bcdepsuxxyyy}}~~~DHQQzLNXXZ[[v@@GHIxHH>xawa3xaka3xasa3vaetva4{dNode6vac7va7{dNode6vac0wad1ypWxawc477xaka7xasb77vaetva8{dNode6vac0wad1ypJxawd4897xaka8xasc897vaetva9{dNode6vac1va階{dNode6vac0wad1yp[xawc49階xaka階xasa階vaetwad1yp[xawb49xaka9xasa9vaetva日{dNode6vac0wad1ypmxawc4日目xaka日xasb日目vaetva章{dNode6vac0wad<ypvv{@AEMPRTTH>xawb4章xaka章xasa章vaetva月{dNode6vac2va1{dNode6vac0wad1ypsxawe4月13日xaka1xasc13日vaetva4{dNode6vac0wad1ypvxawd4月4日xaka4xasb4日vaetwad0xawb4月xaka月xasa月vaesvax{dNode6vac0wad1ypvxawb4xxakaxxasaxvaetwad<yp\bcdemwXX``aaehhlllnnnppttuuuxyy~~DDFHHJKKnnJJNXXZ[mmttvKKKKKK^x>xawa4xaka4xasa4vaetva5{dNode6vac5va5{dNode6vac0wad1yp[xawc55Xxaka5xasb5Xvaetva章{dNode6vac0wad7yp{@AEMPRxawb5章xaka章xasa章vaetva年{dNode6vac0wad2ypflxawb5年xaka年xasa年vaetva日{dNode6vac0wad1yp_xawb5日xaka日xasa日vaetva回{dNode6vac0wad1ypIxawb5回xaka回xasa回vaetwad<ypI\delIJ[]glnpABBH@KK>xawa5xaka5xasa5vaetva6{dNode6vac3va月{dNode6vac2va1{dNode6vac0wad1yp_xawe6月14日xaka1xasc14日vaetva7{dNode6vac0wad1yp|xawd6月7日xaka7xasb7日vaetwad0xawb6月xaka月xasa月vaesva章{dNode6vac0wad6yp{@AEMPxawb6章xaka章xasa章vaetva回{dNode6vac0wad3ypgzzxawb6回xaka回xasa回vaetwad<yp~`ahhDnn@GHI>xawa6xaka6xasa6vaetva7{dNode6vac7va0{dNode6vac0wad1yp}xawc70人xaka0xasb0人vaetva9{dNode6vac0wad1ypWxawb79xaka9xasa9vaetva時{dNode6vac0wad1ypIxawc7時点xaka時xasb時点vaetva章{dNode6vac0wad1ypMxawb7章xaka章xasa章vaetva月{dNode6vac0wad1yp`xawb7月xaka月xasa月vaetva回{dNode6vac0wad2ypFgxawb7回xaka回xasa回vaetvaつ{dNode6vac0wad2yp||xawb7つxakaつxasaつvaetwad<ypVlDDpyI``aavDL>xawa7xaka7xasa7vaetva8{dNode6vac2va4{dNode6vac0wad1ypRxawb84xaka4xasa4vaetva章{dNode6vac0wad5yp{@AEMxawb8章xaka章xasa章vaetwad8ypl~]xy~rrxawa8xaka8xasa8vaetva9{dNode6vac6va0{dNode6vac1va人{dNode6vac0wad1ypFxawf90人くらいxaka人xasd人くらいvaetwad2yprrxawb90xaka0xasa0vaetva2{dNode6vac0wad1ypRxawb92xaka2xasa2vaetva5{dNode6vac0wad1yp[xawe9500Gxaka5xasd500Gvaetva日{dNode6vac0wad1yp_xawc9日目xaka日xasb日目vaetva流{dNode6vac0wad1yp{xawb9流xaka流xasa流vaetva月{dNode6vac0wad1ypMxawd9月9日xaka月xasc月9日vaetwad4yp[hnuxawa9xaka9xasa9vaetva今{dNode6vac8va年{dNode6vac3va買{dNode6vac0wad2ypZZxawd今年買っxaka買xasb買っvaetva起{dNode6vac0wad3ypnvDxawc今年起xaka起xasa起vaetva初{dNode6vac0wad1ypixawc今年初xaka初xasa初vaetwad<ypQRS\\]^UUY\\^^__kqzgtuABBHHILQRRSzz{CpZ_``C>xawb今年xaka年xasa年vaetva回{dNode6vac0wad<ypYPSv}BIKOxIS_j|}@FL]_qr~BDPPXbciiiqy{BP>xawb今回xaka回xasa回vaetva日{dNode6vac0wad9yppuY]`b~]txawb今日xaka日xasa日vaetva週{dNode6vac0wad3ypCeVxawb今週xaka週xasa週vaetva月{dNode6vac0wad2ypSXxawb今月xaka月xasa月vaetva開{dNode6vac0wad1yp|xawc今開発xaka開xasb開発vaetva朝{dNode6vac0wad1ypDxawd今朝起きxaka朝xasc朝起きvaetvaさ{dNode6vac0wad2ypRRxawc今さらxakaさxasbさらvaetwad4ypwqwzxawa今xaka今xasa今vaetvaも{dNode6vac8vaう{dNode6vac1vaす{dNode6vac0wad1ypbxawdもうすぐxakaすxasbすぐvaetwad:ypPci[lvBO_Cxawbもうxakaうxasaうvaetvaの{dNode6vac0wad<ypZ[[SUVWXYZ[\]^`acdhjklnprtuxy}~ABCDHKQJJLZZcgBC>xawbものxakaのxasaのvaetvaら{dNode6vac3vaっ{dNode6vac0wad2yptCxawcもらっxakaっxasaっvaetvaう{dNode6vac0wad1ypaxawcもらうxakaうxasaうvaetvaい{dNode6vac0wad1ypaxawcもらいxakaいxasaいvaetwad0xawbもらxakaらxasaらvaesvaと{dNode6vac1vaも{dNode6vac0wad1ypWxawdもともとxakaもxasbもとvaetwad1ypuxawbもとxakaとxasaとvaetvaっ{dNode6vac0wad1yptxawbもっxakaっxasaっvaetvaち{dNode6vac2vaろ{dNode6vac0wad1ypBxawcもちろxakaろxasaろvaetvaつ{dNode6vac0wad1ypqxawdもちつつxakaつxasbつつvaetwad0xawbもちxakaちxasaちvaesvaか{dNode6vac0wad1ypGxawfもかかわらずxakaかxaseかかわらずvaetvaせ{dNode6vac0wad1ypOxawcもせずxakaせxasbせずvaetwad<ypQUX\\]SUYZ\^^_acccjkopty{}@AEMNOPRSTVfgkstuFFSUtzCTU[\^_cddhipuvvwyDDFIII\_`cfgjjqsz|}CFFLQSSVXYZ]_ceefhpquwy{|@BBJ>xawaもxakaもxasaもvaetva振{dNode6vac1vaり{dNode6vac0wad<ypQQ]]]YYjkkggnttvBDHIQQ{qqg`>xawb振りxakaりxasaりvaetwad1yp`xawa振xaka振xasa振vaetva返{dNode6vac3vaり{dNode6vac0wad<ypQQ]]YYjkkggttBHQQ{qqg`>xawb返りxakaりxasaりvaetvaせ{dNode6vac0wad1yplxawb返せxakaせxasaせvaetvaっ{dNode6vac0wad4ypnvDIxawb返っxakaっxasaっvaetwad1yp]xawa返xaka返xasa返vaetvaブ{dNode6vac3vaロ{dNode6vac3va移{dNode6vac0wad<ypW\\\\\bbbbbcccccdddddeeee>xawgブログ移行日記xaka移xasd移行日記vaetva書{dNode6vac0wad4ypkHgKxaweブログ書いxaka書xasb書いvaetva流{dNode6vac0wad1ypJxawdブログ流xaka流xasa流vaetwad<ypQW]RYeejnu}JKQSUahoty{AGJLUVWXYZ[\]^`acdhjklnprtuxy}~@ABDHIKOZors|BKVVW]abyRUZ`f|ER>xawcブログxakaロxasbログvaetvaー{dNode6vac0wad2yp{Rxawcブースxakaーxasbースvaetvaラ{dNode6vac0wad1ypvxawdブランチxakaラxascランチvaetwad0xawaブxakaブxasaブvaesvaを{dNode6vac0wad<ypQTTUVVWXXXYZ[[\]]^PPRRRRSTTXYZZ[]]abbffggijjklnooprssuuvxxyzzz{@ABDEGJKLLMOOPQRSTUUUVVVVWWWXYZ[]]^^___``aaafghhiijjknnpsttvvwxxy{}~@@@ABBDDEFGGHIKLMNOPQQRTUUVWXYZZ[\\]^_`abcddeeghijjjkklmnoprrtuvwxyy}}~~@@ABBDDEFGHHIJKKLOOQQSTVVWZ[\^_`bddijkkklnosssvxx|}@@ADEFHJKKNOPQRSUUVVVWWXY[]]``bcdeffgklqqstuy{{}~@@ABCDFGHKMMNNQRSTUUWXXYZ]^^__`aabccdffghijlllmppqrrsttvy||}}~@ABCCFFGGGIJKLMNNPPPRR>xawaをxakaをxasaをvaetvaリ{dNode6vac:vaビ{dNode6vac0wad1ypQxawdリビングxakaビxascビングvaetvaア{dNode6vac2vaタ{dNode6vac0wad1yp]xawdリアタイxakaタxasbタイvaetvaル{dNode6vac0wad1ypjxawdリアルタxakaルxasbルタvaetwad0xawbリアxakaアxasaアvaesvaラ{dNode6vac0wad1ypTxawdリライトxakaラxascライトvaetvaリ{dNode6vac1vaス{dNode6vac0wad<ypVlDIJJWXYYdrx}ABJRmnnrrtXX[mmmv~DILMNbmxxxGHHHHM>xawdリリースxakaスxasaスvaetwad1ypQxawcリリーxakaリxasbリーvaetvaス{dNode6vac1vaア{dNode6vac0wad1ypZxawfリストアップxakaアxascアップvaetwad2ypUpxawcリストxakaスxasbストvaetvaン{dNode6vac0wad6yp]ukxEHxawcリンクxakaンxasbンクvaetvaポ{dNode6vac0wad1yprxaweリポジトリxakaポxasdポジトリvaetvaク{dNode6vac2vaエ{dNode6vac0wad1ypBxaweリクエストxakaエxascエストvaetvaル{dNode6vac1vaテ{dNode6vac0wad9ypMNT_imwGLxawlリクルートテクノロジーズxakaテxasgテクノロジーズvaetwad1ypXxaweリクルートxakaルxascルートvaetwad0xawbリクxakaクxasaクvaesvaフ{dNode6vac0wad2ypHNxawhリファクタリングxakaフxasgファクタリングvaetvaツ{dNode6vac0wad1yphxaweリツイートxakaツxasdツイートvaetwad0xawaリxakaリxasaリvaesvaで{dNode6vac6vaす{dNode6vac1vaし{dNode6vac0wad1ypvxawdですしねxakaしxasbしねvaetwad<yp_W{@AEMPPRT\`bcos|CPSWXBFQZacmT[tA>xawbですxakaすxasaすvaetvaき{dNode6vac2vaま{dNode6vac0wad1yp[xawdできますxakaまxasbますvaetvaる{dNode6vac0wad2ypp|xawcできるxakaるxasaるvaetwad5ypccxDNxawbできxakaきxasaきvaetvaい{dNode6vac3vaつ{dNode6vac0wad2ypoJxawcでいつxakaつxasaつvaetvaく{dNode6vac0wad1ypJxaweでいくつかxakaくxascくつかvaetvaま{dNode6vac0wad1ypExaweでいませんxakaまxascませんvaetwad3ypJZ}xawbでいxakaいxasaいvaetvaる{dNode6vac0wad2ypXkxawbでるxakaるxasaるvaetvaみ{dNode6vac0wad2ypY]xawbでみxakaみxasaみvaetvaち{dNode6vac0wad1ypsxawdでちょっxakaちxascちょっvaetwad<ypQQQRRSSSTTUVVWYZZ[\\\\]^^^_QRSTUUUVVVWWXXXYZ[\\]^^_`bccdeeefglllmmnnnoppppqsttttuuuvvvwwwxyyy{|}}~~@AEFFFGHIJKLMNPRRSTTVXZZZ]^^__``ahiiikkkklllllmnooppqqqruwyyyzz{{{||||}}}}~@@@AAEFGJKLOOOPRSSSX\^bbgooqssvvvvzzz{|||@ABCCCEEFIIIJMOOPPPQTTTUUUUVWXYZZ[[[\\\]^_`aaabccdeefffhiiijjllmooppqqtttuvvwwwxyyzzz{{{||}}}~~@AABCDEEFGHIJKKKKLLNPQRSTTTUUUVVVWXYZ[[\]^___`aabdeefgghhjjjkllmnnnopppqqrssttuwwwwwwxyyzzz{{||}}}~~@ABDDDEGHHJJJKLOPQQQRSSTUUUVVVWWWXXXYZZ[]]]^___``aabbbccddeefffghhhhiikkklmnnoopqrrstttuuvwwwwxyzzzzz{{|}}}~~@AABCDEEEFFHIJJLNOOPQRRRR>xawaでxakaでxasaでvaetva書{dNode6vac9vaい{dNode6vac0wad<ypQQUW]]YeknsuFSSgt{BBCHHKKQQ{{[dkqqs|KLOQghy}AHZZ_`e>xawb書いxakaいxasaいvaetvaき{dNode6vac1vaま{dNode6vac0wad<ypZjoyIKUad{f>xawd書きましxakaまxasbましvaetwad7yp[aFUZcAxawb書きxakaきxasaきvaetvaく{dNode6vac0wad7ypZyU^sV]xawb書くxakaくxasaくvaetva式{dNode6vac0wad1ypdxawb書式xaka式xasa式vaetvaけ{dNode6vac1vaる{dNode6vac0wad1ypdxawc書けるxakaるxasaるvaetwad1ypVxawb書けxakaけxasaけvaetva展{dNode6vac0wad1yppxawb書展xaka展xasa展vaetva籍{dNode6vac0wad7yppFuuuflxawb書籍xaka籍xasa籍vaetvaこ{dNode6vac0wad5ypI\\Mgxawc書こうxakaこxasbこうvaetvaか{dNode6vac0wad4ypOgUfxawb書かxakaかxasaかvaetwad2ypYhxawa書xaka書xasa書vaetvaて{dNode6vac1vaる{dNode6vac0wad<yptygrrr{VCGKKM\^NQV]>xawbてるxakaるxasaるvaetwad<ypQQUUVWWWXXXZ\\]_PRSSTTUUVVYYZZ\]]^_aabccceffghiijkkkkppppqsstuuuuxzz||~~BBCDDDFFGHHSSSUUVVWWW[[[]]]^^_``affghhhijjkkkmmmnnoppqrstuvvwwwz{}~@AABCDDFGGGHIJJKKKKLLMNOPQTZ_bdefggimtw{{@@GIJLOOPRSSTTVWWWZZZ[\]aaacdffhkkkmppqsstuvwxyyz||@ABCCCDDEGHHJKKMNNOOOPQQRRSTTUUVWWWWZZZ[[]]]]^^^^abbbcdhijjkllmooooppqqrrssuxyyz|}@AAABCCCFGGGHIJKKKNOOOOOPQRSSSTUVWXYYZZ]^__`aacdefggiiijjjkllopssttuuuvvy{@ADEFFFJJLNPR>xawaてxakaてxasaてvaetvaい{dNode6vac<vaま{dNode6vac4vaす{dNode6vac1vaか{dNode6vac0wad1ypbxawdいますかxakaかxasaかvaetwad<ypQUVWXipDWwDN@W>xawcいますxakaすxasaすvaetvaし{dNode6vac0wad9ypWafmdhmlxawcいましxakaしxasaしvaetvaさ{dNode6vac0wad1ypexawdいまさらxakaさxasbさらvaetvaだ{dNode6vac0wad1ypwxawcいまだxakaだxasaだvaetwad0xawbいまxakaまxasaまvaesvaる{dNode6vac0wad<ypQZSUgips|~BW]fkJPPk|U[]]xtuF>xawbいるxakaるxasaるvaetvaく{dNode6vac1vaつ{dNode6vac0wad4ypVo[Cxawdいくつかxakaつxasbつかvaetwad2yp]pxawbいくxakaくxasaくvaetvaろ{dNode6vac2vaん{dNode6vac0wad3ypPBixawcいろんxakaんxasaんvaetvaい{dNode6vac0wad1ypexawdいろいろxakaいxasbいろvaetwad0xawbいろxakaろxasaろvaesvaち{dNode6vac0wad1ypTxawdいちばんxakaちxascちばんvaetvaき{dNode6vac2vaな{dNode6vac0wad1ypXxawdいきなりxakaなxasbなりvaetvaま{dNode6vac0wad2ypH_xawdいきますxakaまxasbますvaetwad0xawbいきxakaきxasaきvaesvaつ{dNode6vac1vaも{dNode6vac1vaの{dNode6vac0wad5ypeWzl[xawdいつものxakaのxasaのvaetwad2ypgYxawcいつもxakaもxasaもvaetwad2ypcgxawbいつxakaつxasaつvaetvaい{dNode6vac1vaか{dNode6vac0wad1ypixaweいいかげんxakaかxascかげんvaetwad2yp~oxawbいいxakaいxasaいvaetvaけ{dNode6vac0wad2ypaoxawcいけるxakaけxasbけるvaetvaう{dNode6vac0wad1yplxawbいうxakaうxasaうvaetvaら{dNode6vac0wad1yp}xawfいらっしゃっxakaらxaseらっしゃっvaetvaっ{dNode6vac0wad1ypbxawbいっxakaっxasaっvaetvaや{dNode6vac1vaぁ{dNode6vac0wad1ypuxawcいやぁxakaぁxasaぁvaetwad1ypcxawbいやxakaやxasaやvaetvaれ{dNode6vac0wad1ypFxawbいれxakaれxasaれvaet>wad<ypTVYccequzVW]`kpAMNT_deimwGLOUVZ[fjwxSTWWZZ[bpqstGIKQ]^fgijsvEGJ>xawaいxakaいxasaいvaetva（{dNode6vac0wad<ypQQUW[]]QWY^`ddkgistwyBHLSVY[]`ahlnpuRV\]`beoxFGLMQXZ[_cddhhhhlu~DNPSZ[[^_bcefglmopuuwx{BBEHJ>xawa（xaka（xasa（vaetvaド{dNode6vac5vaミ{dNode6vac0wad1ypQxaweドミノ倒しxakaミxasdミノ倒しvaetvaキ{dNode6vac2vaュ{dNode6vac0wad1ypTxawfドキュメントxakaュxasdュメントvaetvaド{dNode6vac0wad1ypgxawdドキドキxakaドxasbドキvaetwad0xawbドキxakaキxasaキvaesvaッ{dNode6vac0wad1ypixawhドットファイル系xakaッxasgットファイル系vaetvaリ{dNode6vac0wad1ypXxawdドリコムxakaリxascリコムvaetvaタ{dNode6vac0wad1ypcxawdドタバタxakaタxascタバタvaetwad0xawaドxakaドxasaドvaesvaす{dNode6vac<vaご{dNode6vac2vaい{dNode6vac0wad2ypQxxawcすごいxakaいxasaいvaetvaく{dNode6vac0wad1ypwxawdすごくてxakaくxasbくてvaetwad0xawbすごxakaごxasaごvaesvaる{dNode6vac0wad<ypR[psx]_wwqTZb@BBeEJLSrsMN>xawbするxakaるxasaるvaetvaか{dNode6vac0wad1ypwxawcすかねxakaかxasbかねvaetvaい{dNode6vac1vaか{dNode6vac0wad1ypNxawcすいかxakaかxasaかvaetwad1ypkxawbすいxakaいxasaいvaetvaも{dNode6vac0wad1ypSxaweすもけさんxakaもxasdもけさんvaetvaね{dNode6vac1vaぇ{dNode6vac0wad1ypcxawcすねぇxakaぇxasaぇvaetwad7ypnvguenwxawbすねxakaねxasaねvaetvaで{dNode6vac0wad1ypuxawbすでxakaでxasaでvaetvaら{dNode6vac0wad1ypwxawbすらxakaらxasaらvaetvaず{dNode6vac0wad1ypkxawfすずけんさんxakaずxaseずけんさんvaetvaよ{dNode6vac0wad1yptxawcすよねxakaよxasbよねvaetvaみ{dNode6vac2vaせ{dNode6vac0wad3ypXnAxaweすみませんxakaせxasbせんvaetvaし{dNode6vac0wad1ypwxawdすみましxakaしxasaしvaetwad0xawcすみまxakaみxasbみまvaesvaん{dNode6vac0wad1ypixawbすんxakaんxasaんvaetvaぐ{dNode6vac1vaや{dNode6vac0wad1ypnxawfすぐやりますxakaやxasdやりますvaetwad2ypn~xawbすぐxakaぐxasaぐvaet>wad<ypRRST^_WXYZ\ceemnpqtvwy}~FFJRTZ^iklllmuy{|}@FJORSXoqvv||CEIOQUUV[\]`abcceijpuwx{{{||}}~@DFKPTUW[]__`abehkpqstwww|}~BDHKQVWWWXXZ]_`bcekkklmorttwwxzz}~@EFHOPPRRR>xawaすxakaすxasaすvaetvaな{dNode6vac<vaど{dNode6vac0wad<ypUUQohrwPw`jwz>xawbなどxakaどxasaどvaetvaん{dNode6vac2vaか{dNode6vac0wad5ypqHLC`xawcなんかxakaかxasaかvaetvaち{dNode6vac0wad1ypAxawfなんちゃってxakaちxasdちゃってvaetwad8yp]XuRZcEzxawbなんxakaんxasaんvaetvaく{dNode6vac0wad;yp^cfkTWZE^sPxawbなくxakaくxasaくvaetvaつ{dNode6vac0wad1ypSxawdなつくりxakaつxascつくりvaetvaっ{dNode6vac2vaて{dNode6vac0wad1yphxawcなってxakaてxasaてvaetvaち{dNode6vac0wad1ypjxawgなっちゃいましxakaちxaseちゃいましvaetwad<ypS\cpqzV[afkmqKO{RSYZZuCCHKMNW^ks}ACGJPA>xawbなっxakaっxasaっvaetvaも{dNode6vac1vaか{dNode6vac0wad3ypT^Txawdなものかxakaかxasaかvaetwad3ypcxawcなものxakaもxasbものvaetvaる{dNode6vac0wad:ypY\zmHJJkxawbなるxakaるxasaるvaetvaぁ{dNode6vac0wad;ypaNBGLQjV\iRxawbなぁxakaぁxasaぁvaetvaさ{dNode6vac2vaん{dNode6vac0wad3ypb]hxawcなさんxakaんxasaんvaetvaい{dNode6vac0wad1ypGxawcなさいxakaいxasaいvaetwad1yptxawbなさxakaさxasaさvaetvaい{dNode6vac4vaか{dNode6vac0wad2ypLVxawcないかxakaかxasaかvaetvaら{dNode6vac0wad1ypaxaweないらしいxakaらxascらしいvaetvaん{dNode6vac0wad1ypDxawcないんxakaんxasaんvaetvaけ{dNode6vac0wad1ypdxawdないけどxakaけxasbけどvaetwad<ypcgqs}Fa{g@I_ajDHQZZ[^ggquuzRSWX^aiqy}}>xawbないxakaいxasaいvaetvaか{dNode6vac1vaっ{dNode6vac0wad9ypelHwIs|aSxawcなかっxakaっxasaっvaetwad4ypuu}}xawbなかxakaかxasaかvaetvaり{dNode6vac2vaま{dNode6vac2vaす{dNode6vac0wad<yplmnuvxCDIJRUVWXYZ[\]^`acdhjklnprtuxy}~ABDHKb>xawdなりますxakaすxasaすvaetvaし{dNode6vac0wad7ypxSCKptDxawdなりましxakaしxasaしvaetwad0xawcなりまxakaまxasaまvaesvaつ{dNode6vac0wad1ypCxawdなりつつxakaつxasbつつvaetwad4ypjAioxawbなりxakaりxasaりvaetvaみ{dNode6vac0wad2ypFkxawbなみxakaみxasaみvaetvaお{dNode6vac0wad1ypIxawbなおxakaおxasaおvaetvaと{dNode6vac0wad6ypS[i\B`xawbなとxakaとxasaとvaetvaー{dNode6vac0wad1yprxawbなーxakaーxasaーvaetvaけ{dNode6vac0wad1ypuxawbなけxakaけxasaけvaetva量{dNode6vac0wad1ypFxawbな量xaka量xasa量vaetvaが{dNode6vac0wad5ypHg{s{xawbながxakaがxasaがvaetvaげ{dNode6vac0wad1yp|xawcなげるxakaげxasbげるvaetvaの{dNode6vac0wad3yp[xrxawbなのxakaのxasaのvaetvaれ{dNode6vac1vaる{dNode6vac0wad1ypgxawcなれるxakaるxasaるvaetwad1ypqxawbなれxakaれxasaれvaetvaら{dNode6vac0wad1ypDxawbならxakaらxasaらvaetvaし{dNode6vac0wad1ypcxawbなしxakaしxasaしvaet>wad<ypQ]]PUYZ__affhhu{}}}@AEMPRSSTTWXZ^aqr{|BKLQUZg@IZZ[\]^`bbcfflmnsvxyCGHKLLMSY\_egijjjlxzCHYY]adefjkquvBFM>xawaなxakaなxasaなvaetva）{dNode6vac0wad<ypQUW[]]WY^`dkgistwBHLSVY[]`ahlnpuR\]`bexGLXZ[_cddhhhlu~DNP[_bceglmpuwx{BBEHIJ>xawa）xaka）xasa）vaetva。{dNode6vac0wad<ypQQQQRRSSTTUWWXYYZ[\\]]^^^__PRSTUUVWWXYYZ[\\]]^^__`ccdefghjjkkllmmnopqrstuvvvvwwwwwwwxyyz{{|}}~@@AACEEFFFGGGGGHHHHHIKLMMNNNOOPPPQRRRSTTTUWXZZZ[\]^^__````abbccggggghhhhijkllmnnoossttuvvvvwxxy{|||}}~@AABBBCCDDFFGGHHIIJJKKLMNOOOOOPPQQQRRSSSSSSTUVWXXYYZZ[\]^_`abcddefggghijklmnoopqqrrstuvvwxyzzz{{{{{||}~@@@ABBCCCDEFGHIIIIIJKLOPQRSSTTUUUVVVVVWWXZ[[\\\\]]]]^^^__````aabbbbccdeeffghijjlmnppqqrssstuuvvvwwxyyzz{{||||}~@AABBCDDDDDEFFHIIIJJKMMMMNOPQQRRSTUVYZ[\\\\]]]__`aaabbbbbccccccfggghhiijjkklmmoqrsttuuuuvwwwwwwxyzzzz{{||||}~~@AAAABBBCCDDEFGHHIJJKKLMNOPPQQRRRRRSSTTUVVVWWXXXXYYZ[\\]]]____``abbcccccdeeefgghhhhiijkkkllmmnnnnnnnnnnooopqqrrrsttttuuvvwwwwxxyyyzzz{{{{|}}}~~~@AABCDEFFGGHHIJJLMOOPRR>xawa。xaka。xasa。vaetva {dNode6vac0wad<ypQQRRRRRRSTTUUVWWXXYYYYZ[\\\]]^^____PSUUVWWWWXXXXXXXXXXXYYZ[[[\\\\\]]]]]]]]]]]]]^^^___`````aaabbbccdddefffghhhhjjkkllllllllmmmmmnnopqrrrstuuvvvvvwwwxxxyyz{{{{{{{{{{{{{{{{{{{{{{{||||}}}}~~@@@@@@@@@@@@@@@@@@@@@@@AAAAAAAAAAAAAAAAAAAAAAABBBBCCCCDDEEEEEEEEEEEEEEEEEEEEEEEFFFGGGHHHHHHHHHIJJKLLMMMMMMMMMMMMMMMMMMMMNNNNNNOPPPPPPPPPPPPPPPQQRRRRRRRRRRSTTTTTUUUUUUVVVVWWWWXXXXXYZZZ[[[[[[[\\\\]]]]]]^^__`abbbbccccdddddeeeeeefggggghhijjkkklmmmmmmmnnnnnnoooooooooooooooooooooooopqsssssttttuuuuuuuuvvvvvvvwxxyyy{{||||}}}}~@@ABBBBCCCCCCCCCDDDDDDEFGGGHHHIIIIIIIIIIIIIIJJJJJJJKKKLLLMNOOPPQQQQQRRRRRRSSTUUUUUUUUUUVVVVVVVVWWWWWWWXXXXXXXXXXXXXYYYYYYZZZZZ[[[[[\\\\\\\\]]]]]^^^^^^^^^^_```````aaaaaaabbbbbbccccccddddddeeeeeefffgggggggghhhhhijjjjjjjkkkkkklllllmnnnnnoooopppppqqqrrrrrrrrrrrsstttttuuuuuuuvvwxxxxxxxyyyyyyyz{{{||||}}}}}}~~~~~~~@@@AAAAAAAAAABBBBBBCCDDDDDDDEFFGHHHHHHIIIIJJKKKKKLMMMNNNNNNOOPQQQQRSSTTUUUUVVVVVVWWWWXXYYZ[[[\\\\\\\\\\]]^^__``aaaaabbccddeeeeffhhijlllnnopqqqrrstttuuuvvvwxxyyyyyzzzz{{||}~@AAABCCDDEEFGGHIIIIIJJKLMMMNNNOPPPPQQRRRRRSSSTTTUVWXXYYYZZZ[[\\\\]^__``aabbbbbccccccdeffggghhhhhiiijjkklmmmnoppqrsttttttttuuuuuuuuuuuuuuuuuuuvwwwwxxxxyyzz{{||}~~@AABBBBBBCCDDEEEFFFGGHHIIJJKKKKLMMNNOPPQQRRRSSTTTTTTUUUVVVVWWXXYYYYZZ[[[[[[[[[[\\\\\\\\\]]_``aabbccdeeeffgghhiijjkkkllmmnnnnoooopqqrrrsttuvvvvvwxxxxxyyzzz{||}~~@AABBBBBBCCDDDEFFGGGHHHHHJKKLMOOOOPQQQQRR>xawa xaka xasa vaetvaF{dNode6vac5vaM{dNode6vac0wad1ypQxawcFMVxakaMxasbMVvaetvaS{dNode6vac0wad1yp~xawcFSTxakaSxasbSTvaetvao{dNode6vac0wad2ypeexaweFoundxakaoxasdoundvaetval{dNode6vac0wad3ypXqYxawgFluentdxakalxasfluentdvaetvaa{dNode6vac0wad3ypBovxawdFallxakaaxascallvaetwad1ypRxawaFxakaFxasaFvaetvaの{dNode6vac4vaか{dNode6vac0wad4ypP_faxawbのかxakaかxasaかvaetvaめ{dNode6vac0wad1ypxawdのめもみxakaめxascめもみvaetvaく{dNode6vac0wad1ypVxawdのくらいxakaくxascくらいvaetvaみ{dNode6vac0wad1ypKxawbのみxakaみxasaみvaetwad<ypQQRRRRSSSSTTTUUVWXYZZ[[\^^____PPQQQQRRSSTTTVVVWWXXX[[[[[[\\\]_`abceeeeefffgggghhiiijklllmmmnnnnoooppqqqrtttttuuuvvwxyyzzz{{{|}}}}~~~@@@AAABBCCDDEEEFFGGHHHIJJKKKKLMMMNNOOOPPPQQQRRRSSTTTUVWXXYYYZZZZ^___```aabcdefffghhkkllmmmmnnppqqssttuuuvvwwwwxxxxyyyyyz{{{||}~~~@@@BCCCDDEFFFGHHIIJJJKKMMNNOOOOOPPQQQRRRRTTUVWWWXXXXYZ[[\\]]^^__``aabbcccccdddefffghhiijjkkkllmmnnooppqqqrstuvvvvwwxxyzz||}~@@AAABBCDEEEEEFFGGHIIKLLNOOOPQRRRRTUVVWXXXZ[\\]]^^^^^_```aabbbbcccceefffiiijjjkklmnnoopqrrsttuuuvwxyyzzz{|}}}~~@@@ABBCCDEFFGGHHIIJJKKLLLMNNNNOOPQRRRSSTUUUVVVWWXXXZ[\\\\]]^^_```abbdeefghhhklllmnnoppqqrrrrsttvvvwxxyyyyzz{{||||}}}~~@@AABCCCCCDDEEFFGGGGHHHHJJKKKLMMNOPQRSSTWXXXYZZZ\\\]]^^^_`````abbefgghhhhiijjjkkkkmooopqqqqqqrrrssstttuuuuuvvwxxxxyyyyyzz{{{{{||||}}}~~@AAABBBCCEEFFHHHHIIJJKKLMOOOOPPQQR>xawaのxakaのxasaのvaetvaキ{dNode6vac2vaボ{dNode6vac0wad6ypQmnnqqxaweキーボードxakaボxascボードvaetvaワ{dNode6vac0wad1ypaxaweキーワードxakaワxascワードvaetwad1yphxawbキーxakaキxasbキーvaetvaタ{dNode6vac4vaイ{dNode6vac4vaポ{dNode6vac0wad1ypQxawcタイポxakaポxasaポvaetvaム{dNode6vac2vaラ{dNode6vac0wad1ypqxawfタイムラインxakaラxascラインvaetvaテ{dNode6vac0wad2ypBPxawgタイムテーブルxakaテxasdテーブルvaetwad0xawcタイムxakaムxasaムvaesvaミ{dNode6vac1vaン{dNode6vac0wad1ypUxawdタイミンxakaンxasaンvaetwad1ypHxawcタイミxakaミxasaミvaetvaプ{dNode6vac0wad1ypcxawcタイプxakaプxasaプvaetwad0xawbタイxakaイxasaイvaesvaー{dNode6vac0wad3yphhjxaweターミナルxakaーxasdーミナルvaetvaム{dNode6vac0wad1ypOxawdタムタムxakaムxascムタムvaetvaワ{dNode6vac0wad1yp[xawfタワーホールxakaワxaseワーホールvaetwad1ypsxawaタxakaタxasaタvaetvaが{dNode6vac5vaら{dNode6vac0wad1ypYxawbがらxakaらxasaらvaetvaつ{dNode6vac0wad1ypgxawcがついxakaつxasbついvaetvaち{dNode6vac0wad1ypAxawdがちだっxakaちxascちだっvaetvaい{dNode6vac3vaて{dNode6vac0wad1ypxxawcがいてxakaてxasaてvaetvaら{dNode6vac0wad1ypFxawiがいらっしゃいましxakaらxasgらっしゃいましvaetvaい{dNode6vac0wad1ypTxawcがいいxakaいxasaいvaetwad0xawbがいxakaいxasaいvaesvaっ{dNode6vac0wad1ypyxawbがっxakaっxasaっvaetwad<ypQVWY\]__QSTVVWXZZ[\^`aaddeefghhhiijkloopppqqqrrstuwww~BCDDIJKLNSTVVYYZ[]`affijjkllmmnpqvwzzz|~~@BCDEEEGHJJLLQSSUYes@CIJMOPRRRSTUVVVY\]^acdefhhiikmnrsuvwyyyz{}}}CDEFFKKLMMNNNOPSTTUWWXZ]__abbefgiikmmnnoopqqstuvz{}~@DFGIIKKLLLNOPPRUVVVWXXYZZZ]_``abfhlmnqqqsttuvwxyz{|~CDDEFFFHLLMMNOQRRR>xawaがxakaがxasaがvaetvaつ{dNode6vac4vaら{dNode6vac0wad1ypQxawcつらいxakaらxasbらいvaetvaい{dNode6vac0wad3ypamQxawbついxakaいxasaいvaetvaぶ{dNode6vac0wad1ypRxaweつぶやいてxakaぶxasdぶやいてvaetvaけ{dNode6vac0wad3yp]hyxawcつけてxakaけxasbけてvaetwad0xawaつxakaつxasaつvaesvaこ{dNode6vac9vaの{dNode6vac1vaく{dNode6vac0wad1ypUxaweこのくらいxakaくxascくらいvaetwad<ypRW\Z~UhpRUVWXYYZ[\]^`acdhjklnprtuvxy|}~ABCDHKdgHnJUefB>xawbこのxakaのxasaのvaetvaち{dNode6vac1vaか{dNode6vac0wad1ypcxawdこちらかxakaかxasaかvaetwad<ypXvw{@AEFGHMNNPRTZ\bcde|}ABUJKUBkmuGJ>xawcこちらxakaちxasbちらvaetvaと{dNode6vac0wad<ypZ[gmpsy^fnov~ADLSsCTTTWYfilmqstzCFGITVejnswzGS[dyz{ACR>xawbことxakaとxasaとvaetvaれ{dNode6vac1vaら{dNode6vac0wad1ypxawcこれらxakaらxasaらvaetwad<ypZRxJTXZhijkm~X^fSScvL>xawbこれxakaれxasaれvaetvaっ{dNode6vac0wad4yplnvDxawbこっxakaっxasaっvaetvaろ{dNode6vac0wad:ypXkB]`bozttxawbころxakaろxasaろvaetvaう{dNode6vac0wad2yp[hxawbこうxakaうxasaうvaetvaん{dNode6vac0wad7yp^Sq\^svxawbこんxakaんxasaんvaetvaこ{dNode6vac0wad1yp{xawbここxakaこxasaこvaetwad3yppM]xawaこxakaこxasaこvaetva記{dNode6vac4va事{dNode6vac0wad<ypRRYZ__Rlm{@AEMPRTYbcdemmnuvCDIJRUVWXYZ[\]^`acdhjklnprtuxy|}~ABCDEHKR^dkow@LMUftLU_efA>xawb記事xaka事xasa事vaetva載{dNode6vac0wad6ypKLPey{xawb記載xaka載xasa載vaetva録{dNode6vac0wad2yp[kxawb記録xaka録xasa録vaetva念{dNode6vac0wad2ypL_xawb記念xaka念xasa念vaetwad1ypqxawa記xaka記xasa記vaetvaは{dNode6vac5vaり{dNode6vac0wad1yphxawbはりxakaりxasaりvaetvaち{dNode6vac0wad1ypxxawdはちょっxakaちxascちょっvaetvaい{dNode6vac0wad1ypPxawbはいxakaいxasaいvaetvaや{dNode6vac0wad2ypn~xawbはやxakaやxasaやvaetvaじ{dNode6vac1vaて{dNode6vac0wad1ypRxawdはじめてxakaてxasaてvaetwad1ypRxawcはじめxakaじxasbじめvaetwad<ypRRSSSWWXY]^^^^_PPSTU[]^^^__`bbbddegimsvvvwwxy{|}~@ABEFFFGGHIIKMMNNPQRSTXZZ\bcdegilmrstuux{|}~~@@ABBBFHHHJLQQRSUVWXYYZZ[\]^^`accdghjklnpqqrttuxyzz{{|}~@@@AABCDEFHIIKNSTUUVVY]`abcfgjpqqrvxy{|}}~@BGJKLLLLMQSSTY\]^abijppqrsttuwwyzz{~BBDEPTUVXXY`bccdghiiijkklmouvwy{@BCEEFFFFGLMOPPR>xawaはxakaはxasaはvaetva、{dNode6vac0wad<ypRRSTUVWWWXXYZZ[\^_PPQRUVVWXZZ[[\^abbcceefhhijklmmnoppqqqstuuuwxxxxy{|}~@ABCDDEFGHIIJKKLMOPRSTTUVVWYZ[]^^^_``aaffffhhhiiijjkklllmmmnnnoqqrrsstuvvwxyz{{||}~~@@@AACDDEFFFGGGGIIJKKLLLMMNNOOPPSSSTTUVW[]^__`abceeeffghiijjklmmnopqqqsstttttuvwwyzz{|}~@@@@ACCDEFFGGHKKLLMOOPSSTTTUUVWWXYYZZ[[\^^__aaabccddffghhiijkklllmmmoopqqrrstuvvvwwxxyzz{{||}}~@@ABCDDEEGHHIIJKLLMMNNOOPPQRSTTTUVVVWWWXXYZZZZ[[[]]]^_``abccdeffggghjkklllmmnnoopqqqrrrrssstuvwwwxxxyzz{{|}~@@ABBBCCDEFFGGGHIIIJJJKKLLMMNOOPQQRRRSSSSUUVWWXXXYYZ[]__``abcddeeefghhiikknnpppqrrtttuuvvvvwxxyzzz{|}}}~~~@@AAAABBCDDEFFFHJLLLNPRR>xawa、xaka、xasa、vaetva情{dNode6vac2va報{dNode6vac2va検{dNode6vac0wad3ypR_mxawd情報検索xaka検xasb検索vaetva研{dNode6vac0wad1ypExawc情報研xaka研xasa研vaetwad2ypRDxawb情報xaka報xasa報vaetvaけ{dNode6vac0wad1ypxawb情けxakaけxasaけvaetwad0xawa情xaka情xasa情vaesva・{dNode6vac0wad8ypR_mg\IIxawa・xaka・xasa・vaetva検{dNode6vac2va索{dNode6vac4va技{dNode6vac1va勉{dNode6vac0wad2ypcrxawg検索技術勉強会xaka勉xasc勉強会vaetwad2ypR_xawd検索技術xaka技xasb技術vaetva条{dNode6vac0wad1ypdxawd検索条件xaka条xasb条件vaetva周{dNode6vac0wad2ypz]xawd検索周りxaka周xasb周りvaetvaシ{dNode6vac0wad1yp^xawd検索シスxakaシxasbシスvaetwad<ypRTUU[`sssyzWW^mGBdeJD>xawb検索xaka索xasa索vaetva討{dNode6vac0wad1ypNxawb検討xaka討xasa討vaetwad0xawa検xaka検xasa検vaesvaA{dNode6vac<vad{dNode6vac0wad<ypRR_\lmmnuuvCDIJRR|Ch>xawfAdventxakadxasedventvaetvan{dNode6vac2vaa{dNode6vac2vaz{dNode6vac1var{dNode6vac0wad4ypPQ`xawhAnalyzerxakarxasarvaetwad2ypU@xawgAnalyzexakazxasbzevaetvas{dNode6vac0wad2yp]`xawhAnalysisxakasxascsisvaetwad0xaweAnalyxakaaxascalyvaesvan{dNode6vac0wad1ypUxawjAnnouncingxakanxashnouncingvaetwad0xawbAnxakanxasanvaesvaz{dNode6vac0wad<ypW[[]`dfxBBCUW]]>xaweAzurexakazxasdzurevaetval{dNode6vac0wad1ypWxaweAliasxakalxasdliasvaetvau{dNode6vac0wad1ypfxawlAutocompletexakauxaskutocompletevaetvaW{dNode6vac0wad5ypLYPRTxawcAWSxakaWxasbWSvaetvam{dNode6vac1vao{dNode6vac0wad5yp[YJQQxawfAmazonxakaoxasbonvaetwad1ypQxawdAmazxakamxascmazvaetvac{dNode6vac0wad1yppxawiAcroquestxakacxashcroquestvaetvaP{dNode6vac2vaM{dNode6vac0wad1ypyxawcAPMxakaMxasaMvaetvaI{dNode6vac0wad6yp^I^PVaxawcAPIxakaIxasaIvaetwad0xawbAPxakaPxasaPvaesvag{dNode6vac2vae{dNode6vac0wad1ypyxaweAgentxakaexascentvaetvag{dNode6vac0wad1yp\xawkAggregationxakagxasigregationvaetwad0xawbAgxakagxasagvaesvap{dNode6vac0wad2ypEHxawfApachexakapxasepachevaetvaa{dNode6vac0wad1ypoxaweAaronxakaaxasdaronvaetvat{dNode6vac0wad1yphxawiAtlassianxakatxashtlassianvaetvai{dNode6vac0wad2yppBxawcAirxakaixasbirvaetvaL{dNode6vac0wad2yptvxaweALPHAxakaLxasdLPHAvaetvaC{dNode6vac0wad1ypuxawcACMxakaCxasbCMvaetvaI{dNode6vac0wad1yprxawcAIRxakaIxasbIRvaet>wad2ypS[xawaAxakaAxasaAvaetvaC{dNode6vac9vaa{dNode6vac3val{dNode6vac2vae{dNode6vac0wad<ypRR_\lmmnuuvCDIJRRCh>xawhCalendarxakaexaseendarvaetvan{dNode6vac0wad1yp|xawgCalndarxakanxasdndarvaetwad0xawcCalxakalxasalvaesvas{dNode6vac2vae{dNode6vac0wad1yp]xawdCasexakaexasaevaetvau{dNode6vac0wad1ypaxawfCasualxakauxascualvaetwad0xawcCasxakasxasasvaesvat{dNode6vac0wad1ypjxawhCatalinaxakatxasftalinavaetwad0xawbCaxakaaxasaavaesvao{dNode6vac4van{dNode6vac4vat{dNode6vac0wad2ypVYxawiContainerxakatxasftainervaetvav{dNode6vac0wad1ypkxawlConversationxakavxasiversationvaetvaf{dNode6vac0wad2ypcvxawjConferencexakafxasgferencevaetvac{dNode6vac0wad1ypuxawhConceptsxakacxaseceptsvaetwad0xawcConxakanxasanvaesvad{dNode6vac1var{dNode6vac0wad2ypTTxaweCoderxakarxasarvaetwad3ypYUTxawdCodexakadxasbdevaetvag{dNode6vac0wad<ypW[]`dfxBBCW]]>xawiCognitivexakagxasggnitivevaetvar{dNode6vac2van{dNode6vac1va使{dNode6vac0wad1yphxawgCorne使っxaka使xasb使っvaetwad2ypinxaweCornexakanxasbnevaetvae{dNode6vac0wad1ypsxawdCorexakaexasaevaetwad0xawcCorxakarxasarvaeswad1ypkxawbCoxakaoxasaovaetvaL{dNode6vac0wad3ypQQYxawcCLIxakaLxasbLIvaetval{dNode6vac3vai{dNode6vac0wad1ypUxawfClientxakaixasdientvaetvao{dNode6vac0wad6ypyCQSSTxawhClouderaxakaoxasfouderavaetvae{dNode6vac0wad3ypTTTxaweCleanxakaexasceanvaetwad1ypYxawbClxakalxasalvaetvah{dNode6vac3var{dNode6vac0wad2ypCIxawiChristmasxakarxasgristmasvaetvae{dNode6vac0wad1ypXxawdChefxakaexasbefvaetvaa{dNode6vac0wad2ypXXxawgChangesxakaaxaseangesvaetwad0xawbChxakahxasahvaesvaR{dNode6vac0wad5ypzddeexaweCROSSxakaRxasdROSSvaetvaC{dNode6vac0wad3ypFBoxawcCCCxakaCxasbCCvaetvau{dNode6vac0wad2ypRRxawgCuratorxakauxasfuratorvaetvaD{dNode6vac0wad1ypOxawbCDxakaDxasaDvaetwad1ypYxawaCxakaCxasaCvaetva昨{dNode6vac5va年{dNode6vac3va少{dNode6vac0wad1ypAxawc昨年少xaka少xasa少vaetva書{dNode6vac0wad2ypqgxawd昨年書いxaka書xasb書いvaetva末{dNode6vac0wad1ypZxawc昨年末xaka末xasa末vaetwad<ypRSZ\^_{qAWgB>xawb昨年xaka年xasa年vaetva日{dNode6vac0wad5ypS^MPpxawb昨日xaka日xasa日vaetva今{dNode6vac0wad1yptxawb昨今xaka今xasa今vaetva晩{dNode6vac0wad3ypmxawb昨晩xaka晩xasa晩vaetva夜{dNode6vac0wad1yprxawb昨夜xaka夜xasa夜vaetwad0xawa昨xaka昨xasa昨vaesvaに{dNode6vac:vaよ{dNode6vac2vaる{dNode6vac0wad2ypTqxawcによるxakaるxasaるvaetvaっ{dNode6vac0wad1ypexawdによってxakaっxasbってvaetwad1ypxxawbによxakaよxasaよvaetvaつ{dNode6vac1vaい{dNode6vac1vaて{dNode6vac0wad<ypVZsyIIKKQCEOUprsE[]HUZ^efmIOOOP>xawdについてxakaてxasaてvaetwad2ypzoxawcについxakaいxasaいvaetwad1yp|xawbにつxakaつxasaつvaetvaく{dNode6vac1vaい{dNode6vac0wad8yp{@AEMPRTxawdにくいかxakaいxasbいかvaetwad1ypyxawbにくxakaくxasaくvaetva対{dNode6vac0wad1ypBxawcに対しxaka対xasb対しvaetvaち{dNode6vac1vaょ{dNode6vac0wad1ypsxawdにちょっxakaょxasbょっvaetwad2ypSqxawbにちxakaちxasaちvaetvaし{dNode6vac0wad1ypTxawcにしてxakaしxasbしてvaetvaお{dNode6vac1vaじ{dNode6vac1vaま{dNode6vac0wad1ypixawhにおじゃましましxakaまxasbましvaetwad1ypIxawfにおじゃましxakaじxasdじゃましvaetwad1yppxawbにおxakaおxasaおvaetvaき{dNode6vac0wad1ypxawcにきりxakaきxasbきりvaetvaい{dNode6vac0wad1ypGxawcにいるxakaいxasbいるvaetvaて{dNode6vac0wad1ypNxawbにてxakaてxasaてvaetwad<ypRUVVVWWX[\]^_PQRRRSUWXYY[[\\^_`abdfghjjklmnnopqrtuuvxyyz||~BCFFHHJLOSVVWY[[[]_afggijmnnoqqsttuuvvwwwxyy{~@BBBBCDDDFHHIIJJKLLOOQQRUVWXYZZZ[\]^`acdeefgghjklnpqqrrsttttuvxyy{{|}}~~@@ABDDFHHIKKMNOQSWYZ[[_aeeffggjjqqtuyzz|BCDEGHHHIJJKLLMMMNPPQRRRRSTUVWZ\]^^_``abbccdeeffghhiijjkkklmnoopqrsssttvvxyz{||}}}@@@BBEEEFGHJJJKLNOOPQQSSSVWWYYYZZZ[[]^_aaccdddeefgghiijjklnoopqrrttvwwwxyzz{||~@@@ABCCCDEEFFIJJKMOR>xawaにxakaにxasaにvaetva続{dNode6vac2vaき{dNode6vac1vaっ{dNode6vac0wad1ypSxawe続きっぽいxakaっxascっぽいvaetwad<ypR_\v}HN|}E^@PcBHtu>xawb続きxakaきxasaきvaetvaい{dNode6vac0wad1ypmxawb続いxakaいxasaいvaetwad0xawa続xaka続xasa続vaesva参{dNode6vac4va戦{dNode6vac0wad1ypRxawb参戦xaka戦xasa戦vaetva加{dNode6vac3va登{dNode6vac0wad1ypxxawe参加登録者xaka登xasc登録者vaetva者{dNode6vac0wad3ypx}Fxawc参加者xaka者xasa者vaetva人{dNode6vac0wad1ypwxawd参加人数xaka人xasb人数vaetwad<yp\^os{fqzWaeyyyzGII\`aacijkloorwxBBFKKPSVYY[acdggozDI>xawb参加xaka加xasa加vaetva照{dNode6vac0wad1yp]xawb参照xaka照xasa照vaetva考{dNode6vac0wad1ypBxawb参考xaka考xasa考vaetwad1yp_xawa参xaka参xasa参vaetva夏{dNode6vac1va休{dNode6vac0wad1ypwxawb夏休xaka休xasa休vaetwad1ypRxawa夏xaka夏xasa夏vaetvaP{dNode6vac9vay{dNode6vac3vaS{dNode6vac0wad2ypS^xawePySpaxakaSxascSpavaetvat{dNode6vac0wad3ypU[[xawfPythonxakatxasdthonvaetvaC{dNode6vac0wad1ypZxawgPyCharmxakaCxaseCharmvaetwad0xawbPyxakayxasayvaesvaC{dNode6vac0wad9yp^ijpikCCCxawbPCxakaCxasaCvaetvar{dNode6vac2vao{dNode6vac3vad{dNode6vac0wad1ypXxawgProductxakadxasdductvaetvac{dNode6vac0wad1ypKxawiProcessorxakacxasfcessorvaetvax{dNode6vac0wad1ypPxaweProxyxakaxxasbxyvaetwad2ypjkxawcProxakaoxasaovaetvae{dNode6vac2vat{dNode6vac0wad1yp]xawkPretrainingxakatxashtrainingvaetvas{dNode6vac0wad1ypuxawePressxakasxasbssvaetwad1ypKxawcPrexakaexasaevaetwad0xawbPrxakarxasarvaesvau{dNode6vac0wad1yp`xawfPublicxakauxaseublicvaetvao{dNode6vac0wad1ypbxawjPowerpointxakaoxasiowerpointvaetvaD{dNode6vac0wad2ypulxawcPDFxakaDxasbDFvaetvaa{dNode6vac2vag{dNode6vac0wad1ypWxawePagesxakagxascgesvaetvar{dNode6vac0wad1yptxawgPartialxakarxasertialvaetwad0xawbPaxakaaxasaavaesvaF{dNode6vac0wad1ypoxawcPFIxakaFxasbFIvaetval{dNode6vac0wad1ypCxawnPlayFramework2xakalxasmlayFramework2vaetwad1yp`xawaPxakaPxasaPvaetvaア{dNode6vac<vaド{dNode6vac0wad3ypS^\xawjアドベントカレンダーxakaドxasiドベントカレンダーvaetvaン{dNode6vac2vaラ{dNode6vac0wad1ypSxawgアンラーニングxakaラxaseラーニングvaetvaデ{dNode6vac0wad1ypRxawfアンデルセンxakaデxasdデルセンvaetwad0xawbアンxakaンxasaンvaesvaッ{dNode6vac1vaデ{dNode6vac0wad4ypRtppxawfアップデートxakaデxascデートvaetwad1ypWxawcアップxakaッxasbップvaetvaー{dNode6vac2vaテ{dNode6vac0wad1ypYxawfアーティストxakaテxasdティストvaetvaキ{dNode6vac0wad1yp{xawgアーキテクチャxakaキxaseキテクチャvaetwad0xawbアーxakaーxasaーvaesvaフ{dNode6vac0wad2ypjSxawfアフィリンクxakaフxaseフィリンクvaetvaプ{dNode6vac1vaケ{dNode6vac0wad1ypBxawhアプリケーションxakaケxaseケーションvaetwad2ypqCxawcアプリxakaプxasbプリvaetvaナ{dNode6vac2vaウ{dNode6vac0wad2ypeIxaweアナウンスxakaウxascウンスvaetvaラ{dNode6vac0wad1yp@xaweアナライザxakaラxascライザvaetwad0xawbアナxakaナxasaナvaesvaメ{dNode6vac0wad1ypqxawdアメリカxakaメxascメリカvaetvaク{dNode6vac0wad2ypEFxawfアクセスログxakaクxaseクセスログvaetvaジ{dNode6vac1vaデ{dNode6vac0wad1yp[xawmアジャイルデータサイエンスxakaデxashデータサイエンスvaetwad1ypYxaweアジャイルxakaジxasdジャイルvaetvaカ{dNode6vac2vaウ{dNode6vac0wad1yp^xawgアカウント作っxakaウxaseウント作っvaetvaデ{dNode6vac0wad1yp[xawhアカデミーヒルズxakaデxasfデミーヒルズvaetwad0xawbアカxakaカxasaカvaesvaル{dNode6vac0wad1ypLxawgアルファベットxakaルxasfルファベットvaet>wad0xawaアxakaアxasaアvaesva/{dNode6vac0wad<ypS^eerrIIoooooosxxyVY[]`ahlnprsu}MRgnuNXZZ[[demmvvIKKKKM[[[[[\\^gsxHKNQ>xawa/xaka/xasa/vaetvaエ{dNode6vac2vaン{dNode6vac2vaト{dNode6vac1vaー{dNode6vac0wad3ypS^mxaweエントリーxakaーxasaーvaetwad3ypR|hxawdエントリxakaトxasbトリvaetvaジ{dNode6vac2vaン{dNode6vac0wad4ypU[Wmxawdエンジンxakaンxasaンvaetvaニ{dNode6vac2vaサ{dNode6vac0wad1ypdxawiエンジニアサポートxakaサxasdサポートvaetvaブ{dNode6vac0wad1yp}xawhエンジニアブログxakaブxascブログvaetwad1yp\xaweエンジニアxakaニxasbニアvaetwad0xawcエンジxakaジxasaジvaeswad0xawbエンxakaンxasaンvaesvaラ{dNode6vac0wad1ypJxawcエラーxakaラxasbラーvaetwad0xawaエxakaエxasaエvaesva渋{dNode6vac2va川{dNode6vac0wad1ypSxawb渋川xaka川xasa川vaetva谷{dNode6vac0wad1ypixawb渋谷xaka谷xasa谷vaetwad0xawa渋xaka渋xasa渋vaesvaさ{dNode6vac7vaん{dNode6vac1vaよ{dNode6vac0wad1ypTxawdさんよりxakaよxasbよりvaetwad<ypS^hrxfmw@GLXioGIOPRnqLVXajEQ>xawbさんxakaんxasaんvaetvaい{dNode6vac0wad7yp]QZB]hyxawbさいxakaいxasaいvaetvaせ{dNode6vac0wad1ypWxawbさせxakaせxasaせvaetvaて{dNode6vac0wad3yp~~]xawbさてxakaてxasaてvaetvaっ{dNode6vac0wad1ypmxawdさっそくxakaっxascっそくvaetvaら{dNode6vac0wad3ypEStxawbさらxakaらxasaらvaetvaす{dNode6vac0wad2ypiCxawcさすがxakaすxasbすがvaetwad<ypVW`lrt||DfpzAFJJJYiosJRRVaehmnrruySXZ[dehkmnsvHIKXuvxy{@EHLM>xawaさxakaさxasaさvaetva失{dNode6vac0wad2ypSLxawb失敗xaka失xasb失敗vaetvaし{dNode6vac7vaま{dNode6vac5vaし{dNode6vac1vaょ{dNode6vac0wad1yp}xaweしましょうxakaょxasbょうvaetwad<ypYjl@er}Bnv~DMbmnGGL>xawcしましxakaしxasaしvaetvaい{dNode6vac1vaま{dNode6vac2vaし{dNode6vac0wad<yp_\kpz{S[]uDkOQA>xaweしまいましxakaしxasaしvaetvaす{dNode6vac0wad1ypxaweしまいますxakaすxasaすvaetwad1ypzxawdしまいまxakaまxasaまvaetwad2ypKDxawcしまいxakaいxasaいvaetvaっ{dNode6vac0wad5yp[R^Oqxawcしまっxakaっxasaっvaetvaす{dNode6vac0wad1ypaxawcしますxakaすxasaすvaetvaう{dNode6vac0wad2ypFLxawcしまうxakaうxasaうvaetwad1ypXxawbしまxakaまxasaまvaetvaて{dNode6vac0wad;yp\yax_cw@Qlxawbしてxakaてxasaてvaetvaゃ{dNode6vac2vaり{dNode6vac0wad1yplxawdしゃべりxakaりxasaりvaetvaっ{dNode6vac0wad1ypsxawdしゃべっxakaっxasaっvaetwad0xawcしゃべxakaゃxasbゃべvaesvaい{dNode6vac0wad2ypeOxawbしいxakaいxasaいvaetvaか{dNode6vac0wad3yp{DWxawcしかもxakaかxasbかもvaetvaつ{dNode6vac0wad1ypOxawdしつけしxakaつxascつけしvaetvaち{dNode6vac0wad1yp^xawfしちゃいましxakaちxaseちゃいましvaetwad<ypSSVVWWXXY\^PRUUUYYZ]^^^__aiknoosswxx|~BBDIKOOV]]^^_fhiijklmorsswyz{}~AFGGMMNNPSTTUVWXYZ[\]^__`abcddefgghiijjjkklmmnoprtuwwxyyzz{}~~@@ABDDEFGGHHJKKLLOQSTTUVWW_adeejkloqtvxxyyyz{|}@@ADEFGGIILUUW\]^_aabciijjklmoooppprswxz|@ABCFGIKLMNPPRSSUVVVWYY[]]acddeggklnoqtvvz|~~ABBCCDEEIIJNNOPPQ>xawaしxakaしxasaしvaetvaた{dNode6vac<vaめ{dNode6vac0wad:ypPQuxq\STYRxawbためxakaめxasaめvaetvaだ{dNode6vac0wad4yp[KFLxawbただxakaだxasaだvaetvaん{dNode6vac0wad5yplhi\sxawbたんxakaんxasaんvaetvaり{dNode6vac2vaし{dNode6vac1vaま{dNode6vac0wad1ypSxaweたりしますxakaまxasbますvaetwad2ypxTxawcたりしxakaしxasaしvaetvaす{dNode6vac0wad1ypBxawcたりすxakaすxasaすvaetwad8ypox{jj{oPxawbたりxakaりxasaりvaetvaい{dNode6vac2vaし{dNode6vac0wad1yp^xawcたいしxakaしxasaしvaetvaん{dNode6vac0wad1ypUxawcたいんxakaんxasaんvaetwad<ypLiqTccBEFjkJ]cpB>xawbたいxakaいxasaいvaetvaら{dNode6vac4vaか{dNode6vac0wad1ypkxawdたらかしxakaかxasbかしvaetvaー{dNode6vac0wad1ypqxawcたらーxakaーxasaーvaetvaし{dNode6vac2vaい{dNode6vac0wad1ypYxawdたらしいxakaいxasaいvaetvaく{dNode6vac0wad1ypxawdたらしくxakaくxasaくvaetwad0xawcたらしxakaしxasaしvaesvaま{dNode6vac0wad1yp|xawdたらまたxakaまxasbまたvaetwad7ypGDH`gOcxawbたらxakaらxasaらvaetvaる{dNode6vac0wad1ypRxawbたるxakaるxasaるvaetvaぶ{dNode6vac0wad3ypTglxawcたぶんxakaぶxasbぶんvaetvaび{dNode6vac0wad1ypixawbたびxakaびxasaびvaetvaち{dNode6vac2vaま{dNode6vac0wad1ypAxawdたちましxakaまxasbましvaetvaよ{dNode6vac0wad1yp`xaweたちよりひxakaよxascよりひvaetwad2yppVxawbたちxakaちxasaちvaetvaく{dNode6vac0wad6ypKZACdyxawbたくxakaくxasaくvaetvaか{dNode6vac0wad2ypL}xawbたかxakaかxasaかvaetvaま{dNode6vac2vaに{dNode6vac0wad1yp@xawcたまにxakaにxasaにvaetvaた{dNode6vac0wad2ypjGxawdたまたまxakaたxasbたまvaetwad0xawbたまxakaまxasaまvaesvaみ{dNode6vac0wad1ypExawbたみxakaみxasaみvaetvaけ{dNode6vac0wad1ypaxawcたけどxakaけxasbけどvaetvaね{dNode6vac0wad1ypuxawbたねxakaねxasaねvaet>wad<ypSSTTTTVVVWYYZ[\\\]^_PQQRSTTUUUVVWYYZZ\^^^__`aeefghjjjjkkkllnnooooprstuvwwwxyyz{||@ABCCEGGHHIJKKMNOPRSTUUUVVWWXXYZZ[[^_``aaafgghjjkkklmnoppqqssttvvwxyzz~@AABBDDEFHHJKKMMMNNNOOPQQSTTTUVWXYYZ[\]^___`abcdefggghiiijklmmmnoooprrtuwwwxyyzzzz{{}}~~ABBCCDDEFGGGHIJKKLLLOOQRRRSSSTTTUUVVWZZ[[[\^___aadddeehiijjlmnoqqqqrrssuuvvwwxxyyyyzz{{|}}~@AADEEFFGGIIIJJKLLMMNNOPPQRRRTTTUUVWXYZ\\\__aaabbbcdffggghhiijjkklmmmnooppqrsttvwwxyy}}~@AABCDEFGGIIJKKKLLMMMOPPQQRRRRSSSTTUUUVVVXYYZZ[]]^^``aabcdeefffgghhiijjjlmnnopqqrrsssttuvvvvwwwwxzz{{||~~AABBCCDDEEGGGHIIJJJLMNQQRR>xawaたxakaたxasaたvaetva話{dNode6vac3vaも{dNode6vac1vaし{dNode6vac0wad1ypzxawd話もしてxakaしxasbしてvaetwad1ypYxawb話もxakaもxasaもvaetvaし{dNode6vac1vaま{dNode6vac0wad1ypExawd話しましxakaまxasbましvaetwad4yp\WXcxawb話しxakaしxasaしvaetva題{dNode6vac0wad2yp@Jxawb話題xaka題xasa題vaetwad<ypSS^VW^aqqfZz|IWkoqrs||EFWY\eoppL>xawa話xaka話xasa話vaetva私{dNode6vac2va自{dNode6vac0wad1ypSxawc私自身xaka自xasb自身vaetva以{dNode6vac0wad1ypFxawc私以外xaka以xasb以外vaetwad:ypSbqVyEqy{Fxawa私xaka私xasa私vaetva「{dNode6vac1va【{dNode6vac0wad1ypxawb「【xaka【xasa【vaetwad<ypTVYW`gosvwy^q~OvEMOXY[dirYacdefiltz|AHTfoz|IJ>xawa「xaka「xasa「vaetva機{dNode6vac4va械{dNode6vac0wad2ypTxawd機械学習xaka械xasc械学習vaetva能{dNode6vac0wad5ypW`fytxawb機能xaka能xasa能vaetva器{dNode6vac0wad1ypjxawb機器xaka器xasa器vaetva会{dNode6vac0wad1ypvxawb機会xaka会xasa会vaetwad0xawa機xaka機xasa機vaesvaラ{dNode6vac2vaン{dNode6vac0wad1ypTxaweランキングxakaンxasdンキングvaetvaイ{dNode6vac1vaー{dNode6vac0wad1ypExawfライブラリーxakaーxasaーvaetwad1ypnxaweライブラリxakaイxasdイブラリvaetwad0xawaラxakaラxasaラvaesva改{dNode6vac5va善{dNode6vac0wad1ypTxawb改善xaka善xasa善vaetva訂{dNode6vac2va新{dNode6vac0wad1yplxawd改訂新版xaka新xasb新版vaetva版{dNode6vac0wad1ypvxawc改訂版xaka版xasa版vaetwad0xawb改訂xaka訂xasa訂vaesvaめ{dNode6vac0wad1ypvxawc改めてxakaめxasbめてvaetva良{dNode6vac0wad2yp{{xawb改良xaka良xasa良vaetva変{dNode6vac0wad1yphxawb改変xaka変xasa変vaetwad0xawa改xaka改xasa改vaesvaガ{dNode6vac0wad1ypTxawcガイドxakaガxascガイドvaetva」{dNode6vac1vaっ{dNode6vac0wad1ypaxawc」ってxakaっxasbってvaetwad<ypTVYW`gosvwyq~OvEO[dicdefiltzHTfoz|IJ>xawa」xaka」xasa」vaetva読{dNode6vac5vaみ{dNode6vac2vaま{dNode6vac0wad4ypTYffxawd読みましxakaまxasbましvaetvaし{dNode6vac0wad1ypJxawd読みしてxakaしxasbしてvaetwad<ypTg{{@@AAEEMMPPRRTTVX`{T|>xawb読みxakaみxasaみvaetvaん{dNode6vac0wad<ypXX]]VXZZoQT{AfkE>xawb読んxakaんxasaんvaetva書{dNode6vac0wad1ypZxawb読書xaka書xasa書vaetvaま{dNode6vac0wad1yp}xawc読まれxakaまxasbまれvaetvaめ{dNode6vac2vaま{dNode6vac0wad1ypExawd読めましxakaまxasbましvaetvaる{dNode6vac0wad1ypfxawc読めるxakaるxasaるvaetwad0xawb読めxakaめxasaめvaeswad1ypVxawa読xaka読xasa読vaetva著{dNode6vac0wad1ypTxawb著者xaka著xasb著者vaetva鈴{dNode6vac0wad1ypTxawb鈴木xaka鈴xasb鈴木vaetva献{dNode6vac0wad1ypTxawb献本xaka献xasb献本vaetvaだ{dNode6vac9vaい{dNode6vac2vaぶ{dNode6vac0wad2yp_]xawcだいぶxakaぶxasaぶvaetvaて{dNode6vac0wad1yp[xawcだいてxakaてxasaてvaetwad<ypTMNT_imowGLjB>xawbだいxakaいxasaいvaetvaっ{dNode6vac0wad<ypVUo[hsHQaBHbm@w>xawbだっxakaっxasaっvaetvaけ{dNode6vac3vaど{dNode6vac0wad3ypr^Axawcだけどxakaどxasaどvaetvaる{dNode6vac0wad1ypOxawcだけるxakaるxasaるvaetvaれ{dNode6vac0wad1ypZxawcだけれxakaれxasaれvaetwad6ypSVYEs{xawbだけxakaけxasaけvaetvaき{dNode6vac1vaま{dNode6vac0wad1ypWxawdだきましxakaまxasbましvaetwad1ypvxawbだきxakaきxasaきvaetvaく{dNode6vac0wad1ypZxawbだくxakaくxasaくvaetvaろ{dNode6vac0wad2yprHxawcだろうxakaろxasbろうvaetvaか{dNode6vac1vaん{dNode6vac0wad1ypzxawcだかんxakaんxasaんvaetwad1ypcxawbだかxakaかxasaかvaetvaり{dNode6vac0wad1ypTxawbだりxakaりxasaりvaetvaら{dNode6vac0wad1ypAxawbだらxakaらxasaらvaetwad<ypXXX]]]rQSTV`LZ]LOciB]hkryzGL>xawaだxakaだxasaだvaetva終{dNode6vac3vaわ{dNode6vac2vaっ{dNode6vac0wad2ypTHxawc終わっxakaっxasaっvaetvaり{dNode6vac2vaで{dNode6vac0wad1ypXxawe終わりまでxakaでxasaでvaetvaし{dNode6vac0wad1yp`xawe終わりましxakaしxasaしvaetwad0xawd終わりまxakaりxasbりまvaeswad0xawb終わxakaわxasaわvaesva了{dNode6vac0wad2ypXqxawb終了xaka了xasa了vaetvaえ{dNode6vac0wad1ypXxawb終えxakaえxasaえvaetwad0xawa終xaka終xasa終vaesvaレ{dNode6vac2vaビ{dNode6vac0wad1ypTxawdレビューxakaビxascビューvaetvaイ{dNode6vac0wad1ypRxawiレイアウトファイルxakaイxashイアウトファイルvaetwad0xawaレxakaレxasaレvaesvaと{dNode6vac<vaし{dNode6vac1vaて{dNode6vac0wad<ypYP[fzs{AbBGYLQ>xawcとしてxakaてxasaてvaetwad2ypnwxawbとしxakaしxasaしvaetvaい{dNode6vac3vaう{dNode6vac1vaか{dNode6vac0wad3ypHk{xawdというかxakaかxasaかvaetwad<ypYT]`adghmrsyzCJLUYY^`aloqs~@ALOSs||CJTWYdefimqtzCILTVWYejjnstwzFIX[]cdloppsyz{ACL>xawcというxakaうxasaうvaetvaい{dNode6vac1vaつ{dNode6vac0wad2ypZ~xaweといいつつxakaつxasbつつvaetwad2ypZLxawcといいxakaいxasaいvaetvaっ{dNode6vac1vaて{dNode6vac0wad4ypFF|exawdといってxakaてxasaてvaetwad1ypcxawcといっxakaっxasaっvaetwad1ypsxawbといxakaいxasaいvaetvaか{dNode6vac1vaし{dNode6vac0wad1ypzxawcとかしxakaしxasaしvaetwad9yp]iiGGQSzdxawbとかxakaかxasaかvaetvaり{dNode6vac0wad6ypTw\lw}xawbとりxakaりxasaりvaetvaき{dNode6vac1vaっ{dNode6vac0wad1ypgxawcときっxakaっxasaっvaetwad6yp[aL_`xawbときxakaきxasaきvaetvaど{dNode6vac0wad1yphxawcとどうxakaどxasbどうvaetvaっ{dNode6vac2vaく{dNode6vac0wad1ypHxawcとっくxakaくxasaくvaetvaて{dNode6vac0wad1ypZxawcとってxakaてxasaてvaetwad3ypwgzxawbとっxakaっxasaっvaetvaう{dNode6vac2vaご{dNode6vac2vaす{dNode6vac0wad4ypAPp_xawgとうございますxakaすxasaすvaetvaし{dNode6vac0wad1yp_xawgとうございましxakaしxasaしvaetwad0xawfとうございまxakaごxasdございまvaesvaれ{dNode6vac0wad1ypOxawcとうれxakaれxasaれvaetwad1ypvxawbとうxakaうxasaうvaetvaず{dNode6vac0wad1ypAxawcとずつxakaずxasbずつvaetvaま{dNode6vac0wad1yppxawcとまぁxakaまxasbまぁvaetvaく{dNode6vac0wad2ypJgxawbとくxakaくxasaくvaetvaて{dNode6vac0wad1yp`xawbとてxakaてxasaてvaetvaお{dNode6vac0wad1ypMxawcとおりxakaおxasbおりvaetvaふ{dNode6vac0wad1ypRxawbとふxakaふxasaふvaetvaこ{dNode6vac0wad1ypzxawcところxakaこxasbころvaet>wad<ypTXZZZ[QQSVXXZ\^egiklopxy|IJQQRSTVVXZ[_`aafhklnoqrrtvxyz||}ABCCDGGLORScefgtx{CIPUWZZ[\]]_`abbcdgjjjlmmopqsxz{{{EEEJKLMNQV\gggikwxyzz{}}ACCKLOQRRRRRSSTVWX_``ijkklnqssstttuwz|CDDILPRR>xawaとxakaとxasaとvaetvaあ{dNode6vac<vaと{dNode6vac1vaお{dNode6vac0wad1ypTxaweあとおまけxakaおxascおまけvaetwad7ypZSSCASRxawbあとxakaとxasaとvaetvaる{dNode6vac0wad<ypVYTfhnvk|GGUj^efzWinq{@FZZuCQ>xawbあるxakaるxasaるvaetvaり{dNode6vac2vaま{dNode6vac3vaす{dNode6vac0wad8ypWdrLYzNlxawdありますxakaすxasaすvaetvaし{dNode6vac0wad2ypCLxawdありましxakaしxasaしvaetvaせ{dNode6vac0wad1ypoxaweありませんxakaせxasbせんvaetwad0xawcありまxakaまxasaまvaesvaこ{dNode6vac0wad1ypixaweありここにxakaこxascここにvaetwad;ypctfFINP_jpvxawbありxakaりxasaりvaetvaえ{dNode6vac1vaず{dNode6vac0wad5ypTw\w}xawcあえずxakaずxasaずvaetwad1yplxawbあえxakaえxasaえvaetvaっ{dNode6vac0wad9ypt`q|ntGexawbあっxakaっxasaっvaetvaけ{dNode6vac0wad4ypAPp_xawdあけましxakaけxascけましvaetvaれ{dNode6vac0wad3ypfZrxawbあれxakaれxasaれvaetvaん{dNode6vac1vaこ{dNode6vac0wad1ypzxawgあんまりこないxakaこxascこないvaetwad3ypauWxawdあんまりxakaんxascんまりvaetvaい{dNode6vac1vaて{dNode6vac0wad1ypqxawcあいてxakaてxasaてvaetwad2yp]yxawbあいxakaいxasaいvaetvaつ{dNode6vac0wad1yp_xawdあつまりxakaつxascつまりvaetvaま{dNode6vac0wad1ypaxawcあまりxakaまxasbまりvaetvaく{dNode6vac0wad1ypoxawdあくまでxakaくxascくまでvaetvaげ{dNode6vac0wad1ypxawbあげxakaげxasaげvaet>wad1ypwxawaあxakaあxasaあvaetva紹{dNode6vac0wad<ypTPVu_yy@JJI]`bm~Ut>xawb紹介xaka紹xasb紹介vaetva趣{dNode6vac0wad4ypUU[[xawb趣味xaka趣xasb趣味vaetva？{dNode6vac1vaっ{dNode6vac0wad1ypOxawc？ってxakaっxasbってvaetwad<ypU]SXbbbbhELYY[ttCCFLU_sPZw>xawa？xaka？xasa？vaetva関{dNode6vac5vaす{dNode6vac0wad9ypU[_]N|EJMxawc関するxakaすxasbするvaetva連{dNode6vac0wad4yp~ABxawb関連xaka連xasa連vaetvaし{dNode6vac0wad2ypFZxawb関しxakaしxasaしvaetva西{dNode6vac0wad1ypbxawb関西xaka西xasa西vaetva係{dNode6vac0wad2ypuXxawb関係xaka係xasa係vaetwad1ypOxawa関xaka関xasa関vaetvaプ{dNode6vac3vaロ{dNode6vac4vaジ{dNode6vac1vaペ{dNode6vac0wad4yp~Dbmxawiプロジェクトページxakaペxascページvaetwad6ypU[[UkQxawfプロジェクトxakaジxasdジェクトvaetvaグ{dNode6vac2vaム{dNode6vac0wad4ypU[[Xxaweプログラムxakaムxasaムvaetvaミ{dNode6vac0wad1yp^xawgプログラミングxakaミxascミングvaetwad0xawdプログラxakaグxasbグラvaesvaダ{dNode6vac1vaシ{dNode6vac0wad1ypYxawiプロダクトシリーズxakaシxasdシリーズvaetwad2ypGmxaweプロダクトxakaダxascダクトvaetvaフ{dNode6vac0wad1ypTxawnプロフェッショナルプログラマxakaフxaslフェッショナルプログラマvaetwad0xawbプロxakaロxasaロvaesvaラ{dNode6vac2vaグ{dNode6vac0wad<ypSTUUz@@KAJPstw|~>xaweプラグインxakaグxascグインvaetvaッ{dNode6vac0wad1ypfxawfプラットフォxakaッxasdットフォvaetwad0xawbプラxakaラxasaラvaesvaレ{dNode6vac2vaス{dNode6vac0wad1ypExawgプレスリリースxakaスxaseスリリースvaetvaイ{dNode6vac0wad1ypHxawfプレイバックxakaイxasdイバックvaetwad1yplxawbプレxakaレxasaレvaetwad0xawaプxakaプxasaプvaesvaベ{dNode6vac3vaク{dNode6vac0wad1ypUxawdベクトルxakaクxascクトルvaetvaル{dNode6vac2vaリ{dNode6vac0wad3yp|cexawdベルリンxakaリxasbリンvaetvaサ{dNode6vac0wad1yp\xaweベルサールxakaサxascサールvaetwad0xawbベルxakaルxasaルvaesvaー{dNode6vac0wad<yp[]`ahlnpy~DHKYY@@>xawcベースxakaーxasbースvaetwad0xawaベxakaベxasaベvaesva確{dNode6vac1va用{dNode6vac0wad1ypGxawc確認用xaka用xasa用vaetwad3ypU[Wxawb確認xaka確xasb確認vaetva含{dNode6vac2vaめ{dNode6vac0wad1ypUxawb含めxakaめxasaめvaetvaま{dNode6vac1vaれ{dNode6vac0wad1ypIxawd含まれるxakaれxasbれるvaetwad1ypLxawb含まxakaまxasaまvaetwad0xawa含xaka含xasa含vaesvaJ{dNode6vac:vau{dNode6vac2vap{dNode6vac0wad1ypUxawgJupyterxakapxasepytervaetvas{dNode6vac0wad1ypfxawlJustTechTalkxakasxasjstTechTalkvaetwad0xawbJuxakauxasauvaesvaa{dNode6vac3vav{dNode6vac2vaO{dNode6vac0wad1ypKxawgJavaOnexakaOxascOnevaetvaD{dNode6vac0wad1ypPxawgJavaDocxakaDxascDocvaetwad7ypVyDLooQxawdJavaxakavxasbvavaetvap{dNode6vac1vae{dNode6vac0wad1ypMxaw QJapaneseTokenizerxakaexasleseTokenizervaetwad5ypoMcYvxaweJapanxakapxascpanvaetvan{dNode6vac0wad1ypfxawfJanomexakanxasdnomevaetwad0xawbJaxakaaxasaavaesvaJ{dNode6vac0wad6ypWyFBoxawdJJUGxakaJxascJUGvaetvaM{dNode6vac0wad1ypfxawdJMATxakaMxascMATvaetvao{dNode6vac0wad1ypkxawdJoinxakaoxascoinvaetvaV{dNode6vac0wad1ypaxawcJVMxakaVxasbVMvaetvaI{dNode6vac0wad1yp]xawdJIRAxakaIxascIRAvaetvae{dNode6vac0wad1ypixawiJetBrainsxakaexashetBrainsvaetvaP{dNode6vac0wad1ypFxawbJPxakaPxasaPvaetvaD{dNode6vac0wad1ypKxawdJDicxakaDxascDicvaetwad1yp^xawaJxakaJxasaJvaetvaN{dNode6vac3vae{dNode6vac0wad1yp\xawjNetworkingxakaexasietworkingvaetvai{dNode6vac0wad1ypexaweNightxakaixasdightvaetvaA{dNode6vac0wad1ypKxaweNAISTxakaAxasdAISTvaetwad1ypUxawaNxakaNxasaNvaetva環{dNode6vac0wad7ypVeSPOAIxawb環境xaka環xasb環境vaetvaD{dNode6vac7vae{dNode6vac3vav{dNode6vac0wad3ypVYYxawcDevxakavxasavvaetvas{dNode6vac0wad1ypXxawgDesktopxakasxasesktopvaetval{dNode6vac0wad1yp^xawfDeletexakalxasdletevaetwad0xawbDexakaexasaevaesvao{dNode6vac2vac{dNode6vac0wad1ypXxawfDockerxakacxasdckervaetvam{dNode6vac0wad1yp]xawfDomainxakamxasdmainvaetwad0xawbDoxakaoxasaovaesvaI{dNode6vac0wad4yp^\jnxawcDIYxakaIxasbIYvaetvaa{dNode6vac2vat{dNode6vac0wad3ypooxxawdDataxakatxasbtavaetvav{dNode6vac0wad1ypjxaweDavidxakavxascvidvaetwad0xawbDaxakaaxasaavaesvai{dNode6vac0wad1ypkxawgDiscussxakaixasfiscussvaetvaS{dNode6vac0wad2ypdDxawgDSIRNLPxakaSxasfSIRNLPvaetvar{dNode6vac0wad1ypBxawgDropboxxakarxasfropboxvaetwad0xawaDxakaDxasaDvaesva動{dNode6vac4vaく{dNode6vac0wad1ypVxawb動くxakaくxasaくvaetva向{dNode6vac0wad1ypOxawb動向xaka向xasa向vaetva機{dNode6vac0wad1ypWxawb動機xaka機xasa機vaetva作{dNode6vac0wad1ypHxawb動作xaka作xasa作vaetwad0xawa動xaka動xasa動vaesvaよ{dNode6vac4vaう{dNode6vac2vaか{dNode6vac1vaっ{dNode6vac0wad1ypWxawdようかっxakaっxasaっvaetwad3yp_CDxawcようかxakaかxasaかvaetvaや{dNode6vac0wad3ypnq~xawdようやくxakaやxasbやくvaetwad<ypVUU[n~S`nAv[bffzKSm}O[^`cu|RR>xawbようxakaうxasaうvaetvaく{dNode6vac1vaわ{dNode6vac0wad1ypYxaweよくわかるxakaわxascわかるvaetwad4ypLLUgxawbよくxakaくxasaくvaetvaか{dNode6vac0wad1yptxawcよかっxakaかxasbかっvaetvaり{dNode6vac0wad7ypel~DIbmxawbよりxakaりxasaりvaetwad2ypcxawaよxakaよxasaよvaetva変{dNode6vac5vaえ{dNode6vac0wad1ypVxawb変えxakaえxasaえvaetvaわ{dNode6vac1vaて{dNode6vac0wad1ypPxawd変わってxakaてxasaてvaetwad2ypeVxawc変わっxakaわxasbわっvaetva遷{dNode6vac0wad2ypIRxawb変遷xaka遷xasa遷vaetva更{dNode6vac1va点{dNode6vac0wad1ypHxawc変更点xaka点xasa点vaetwad5ypjjR{Mxawb変更xaka更xasa更vaetvaか{dNode6vac0wad1ypBxawb変かxakaかxasaかvaetwad0xawa変xaka変xasa変vaesva最{dNode6vac9va初{dNode6vac0wad4ypVXyyxawb最初xaka初xasa初vaetva近{dNode6vac3va使{dNode6vac0wad1ypkxawd最近使っxaka使xasb使っvaetva触{dNode6vac0wad1ypUxawd最近触っxaka触xasb触っvaetva忘{dNode6vac0wad1ypkxawc最近忘xaka忘xasa忘vaetwad9yp[O@ZVCQSUxawb最近xaka近xasa近vaetva終{dNode6vac2va出{dNode6vac0wad1yplxawe最終出社日xaka出xasc出社日vaetva日{dNode6vac0wad4ypIR|yxawc最終日xaka日xasa日vaetwad0xawb最終xaka終xasa終vaesva後{dNode6vac0wad6ypuREqy{xawb最後xaka後xasa後vaetva大{dNode6vac0wad1ypExawc最大手xaka大xasb大手vaetvaも{dNode6vac0wad1ypcxawb最もxakaもxasaもvaetva新{dNode6vac1va版{dNode6vac0wad5yp~DbmPxawc最新版xaka版xasa版vaetwad1ypXxawb最新xaka新xasa新vaetva中{dNode6vac0wad1yp[xawb最中xaka中xasa中vaetva悪{dNode6vac0wad1yp]xawb最悪xaka悪xasa悪vaetwad0xawa最xaka最xasa最vaesva導{dNode6vac0wad2ypVYxawb導入xaka導xasb導入vaetva時{dNode6vac2va間{dNode6vac2va大{dNode6vac0wad1yp]xawe時間大丈夫xaka大xasc大丈夫vaetva管{dNode6vac0wad1ypYxawe時間管理術xaka管xasc管理術vaetwad4yp`fk{xawb時間xaka間xasa間vaetva差{dNode6vac0wad1ypUxawb時差xaka差xasa差vaetwad4ypVgHxawa時xaka時xasa時vaetva疑{dNode6vac0wad1ypVxawc疑問点xaka疑xasc疑問点vaetvaコ{dNode6vac9vaン{dNode6vac4vaテ{dNode6vac2vaナ{dNode6vac0wad1ypVxawdコンテナxakaナxasaナvaetvaン{dNode6vac0wad1ypfxaweコンテンツxakaンxasbンツvaetwad0xawcコンテxakaテxasaテvaesvaパ{dNode6vac0wad1ypaxaweコンパクトxakaパxascパクトvaetvaピ{dNode6vac0wad1ypgxawjコンピュータシステムxakaピxashピュータシステムvaetvaビ{dNode6vac0wad2ypmmxawcコンビxakaビxasaビvaetwad0xawbコンxakaンxasaンvaesvaロ{dNode6vac2vaィ{dNode6vac0wad1ypcxawgコロナウィルスxakaィxascィルスvaetvaイ{dNode6vac0wad1yptxawgコロナウイルスxakaイxascイルスvaetwad0xawdコロナウxakaロxascロナウvaesvaマ{dNode6vac1vaン{dNode6vac0wad4ypQPRwxawdコマンドxakaンxasbンドvaetwad1ypGxawbコマxakaマxasaマvaetvaー{dNode6vac3vaド{dNode6vac1va・{dNode6vac0wad1ypfxawkコード・シンプリシティxaka・xash・シンプリシティvaetwad1ypNxawcコードxakaドxasaドvaetvaヒ{dNode6vac0wad1yp@xawdコーヒーxakaヒxasbヒーvaetvaデ{dNode6vac0wad2ypCSxawfコーディングxakaデxasdディングvaetwad0xawbコーxakaーxasaーvaesvaピ{dNode6vac0wad2ypijxawcコピーxakaピxasbピーvaetvaミ{dNode6vac2vaッ{dNode6vac2vaタ{dNode6vac0wad3ypWnQxaweコミッターxakaタxasbターvaetvaト{dNode6vac0wad1ypnxawdコミットxakaトxasaトvaetwad0xawcコミッxakaッxasaッvaesvaュ{dNode6vac0wad1ypkxawiコミュニティサポーxakaュxasgュニティサポーvaetwad0xawbコミxakaミxasaミvaesvaト{dNode6vac0wad1ypNxawbコトxakaトxasaトvaetvaリ{dNode6vac0wad1ypOxawbコリxakaリxasaリvaetvaメ{dNode6vac1vaン{dNode6vac0wad1ypFxawdコメントxakaンxasbントvaetwad1yp_xawbコメxakaメxasaメvaetwad0xawaコxakaコxasaコvaesva名{dNode6vac1va古{dNode6vac0wad2ypovxawc名古屋xaka古xasb古屋vaetwad4ypVMMIxawa名xaka名xasa名vaetva解{dNode6vac0wad1ypVxawb解消xaka解xasb解消vaetvaメ{dNode6vac3vaモ{dNode6vac0wad<ypVR]gu{@AEMPRTZoWzNQ\`lwz{}GJ[gzR>xawbメモxakaモxasaモvaetvaイ{dNode6vac0wad1ypixawfメインマシンxakaイxaseインマシンvaetvaニ{dNode6vac0wad2yp`bxawdメニューxakaニxascニューvaetwad0xawaメxakaメxasaメvaesva生{dNode6vac2va成{dNode6vac0wad2ypWfxawb生成xaka成xasa成vaetva活{dNode6vac0wad1ypwxawb生活xaka活xasa活vaetwad0xawa生xaka生xasa生vaesvaH{dNode6vac5vau{dNode6vac0wad2ypWRxawdHugoxakauxascugovaetvaa{dNode6vac2vat{dNode6vac0wad1ypgxawfHatenaxakatxasdtenavaetvad{dNode6vac1vao{dNode6vac0wad9ypGccxx\gvIxawfHadoopxakaoxascoopvaetwad1ypoxawcHadxakadxasadvaetwad0xawbHaxakaaxasaavaesvai{dNode6vac1vav{dNode6vac0wad1ypGxawdHivexakavxasbvevaetwad1yp\xawbHixakaixasaivaetvae{dNode6vac0wad2yp^FxawfHerokuxakaexaseerokuvaetvaB{dNode6vac0wad1ypxxawhHBaseConxakaBxasgBaseConvaetwad0xawaHxakaHxasaHvaesva利{dNode6vac0wad<ypWXXBK]EF@]NKNNOP>xawb利用xaka利xasb利用vaetvaそ{dNode6vac;vaの{dNode6vac3va後{dNode6vac0wad1ypaxaweその後どうxaka後xasc後どうvaetvaま{dNode6vac0wad1ypWxawdそのままxakaまxasbままvaetvaへ{dNode6vac0wad1ypSxawdそのへんxakaへxasbへんvaetwad<ypWnDDV\\\\\bbbbbcccccddddddeeeeeG]`CNA>xawbそのxakaのxasaのvaetvaこ{dNode6vac2vaに{dNode6vac0wad1yphxawcそこにxakaにxasaにvaetvaで{dNode6vac0wad3ypCWJxawcそこでxakaでxasaでvaetwad0xawbそこxakaこxasaこvaesvaり{dNode6vac0wad1yplxawbそりxakaりxasaりvaetvaろ{dNode6vac0wad1ypmxawdそろってxakaろxascろってvaetvaも{dNode6vac0wad1ypuxaweそもそものxakaもxasdもそものvaetvaう{dNode6vac0wad7ypSanKxAYxawbそうxakaうxasaうvaetvaれ{dNode6vac2vaぞ{dNode6vac0wad1yp|xawdそれぞれxakaぞxasbぞれvaetvaほ{dNode6vac0wad1yp_xawdそれほどxakaほxasbほどvaetwad2ypyQxawbそれxakaれxasaれvaetvaし{dNode6vac0wad2yptzxawcそしてxakaしxasbしてvaetvaち{dNode6vac0wad1ypOxawcそちらxakaちxasbちらvaetvaび{dNode6vac0wad1ypaxawcそびれxakaびxasbびれvaetvaか{dNode6vac0wad1ypdxawbそかxakaかxasaかvaetwad1ypexawaそxakaそxasaそvaetva当{dNode6vac2va時{dNode6vac0wad1ypWxawb当時xaka時xasa時vaetva選{dNode6vac0wad1ypgxawb当選xaka選xasa選vaetwad0xawa当xaka当xasa当vaesvab{dNode6vac7var{dNode6vac0wad1ypWxawdbrewxakarxascrewvaetvao{dNode6vac0wad<yp{{{{@@@@AAAAEEEEMMMPPRVV>xawdbookxakaoxascookvaetvaa{dNode6vac0wad1ypjxawdbashxakaaxascashvaetvai{dNode6vac0wad1ypxxawcbitxakaixasbitvaetvae{dNode6vac2vat{dNode6vac0wad8ypU[]^ddBKxawdbetaxakatxasbtavaetvah{dNode6vac0wad1ypuxawfbehindxakahxasdhindvaetwad0xawbbexakaexasaevaesvay{dNode6vac0wad1yp^xawbbyxakayxasayvaetvau{dNode6vac0wad1ypxawdbulkxakauxasculkvaetwad0xawabxakabxasabvaesvaイ{dNode6vac3vaン{dNode6vac6vaス{dNode6vac1vaー{dNode6vac1vaル{dNode6vac1vaガ{dNode6vac0wad1ypQxawiインストールガイドxakaガxascガイドvaetwad9ypWoItwwrABxawfインストールxakaルxasaルvaetwad2ypA}xaweインストーxakaーxasaーvaetwad1ypPxawdインストxakaスxasbストvaetvaデ{dNode6vac2vaッ{dNode6vac1vaク{dNode6vac0wad3ypWj@xawfインデックスxakaクxasbクスvaetwad1yp@xawdインデッxakaッxasaッvaetvaキ{dNode6vac0wad1ypNxawgインデキシングxakaキxasdキシングvaetwad1yp[xawcインデxakaデxasaデvaetvaチ{dNode6vac0wad1ypkxawcインチxakaチxasaチvaetvaポ{dNode6vac0wad1ypExaweインポートxakaポxascポートvaetvaフ{dNode6vac2vaラ{dNode6vac2va養{dNode6vac0wad1ypMxawmインフラエンジニア養成読本xaka養xasd養成読本vaetva技{dNode6vac0wad1ypXxawmインフラエンジニア技術勉強xaka技xasd技術勉強vaetwad0xawiインフラエンジニアxakaラxasfラエンジニアvaesvaル{dNode6vac0wad1yp]xawgインフルエンザxakaルxasdルエンザvaetwad0xawcインフxakaフxasaフvaesvaタ{dNode6vac0wad1ypnxawgインタフェースxakaタxaseタフェースvaetwad0xawbインxakaンxasaンvaesvaベ{dNode6vac1vaル{dNode6vac0wad1ypIxawfイベントルーxakaルxasbルーvaetwad8ypCC`acenjxawdイベントxakaベxascベントvaetvaケ{dNode6vac0wad2yphixawdイケメンxakaケxascケメンvaetwad2ypixxawaイxakaイxasaイvaetvaま{dNode6vac:vaた{dNode6vac1vaま{dNode6vac0wad4ypzrwPxawdまたまたxakaまxasbまたvaetwad8ypWXq^OUXAxawbまたxakaたxasaたvaetvaし{dNode6vac0wad<ypY\PUVW^_`hkrwx|GKO^sFJMNPTY_imowzFGJLRSTU_adelmqruvxy{}AFGIIRT\bkmvwxFILRRTUVYeghiqrxz~CDHIJJM>xawbましxakaしxasaしvaetvaす{dNode6vac0wad<yp]VYckqzIZ[]ghntvBFGHKOQdes{@@VfhOSb{ACy{~O>xawbますxakaすxasaすvaetvaず{dNode6vac0wad<yp]gtBHQ{Vcqqw{Yv>xawbまずxakaずxasaずvaetvaつ{dNode6vac0wad1yp^xawdまつわるxakaつxascつわるvaetvaで{dNode6vac0wad<ypRX_JXZ\hijk^sZE>xawbまでxakaでxasaでvaetvaだ{dNode6vac1vaま{dNode6vac0wad1yp^xawdまだまだxakaまxasbまだvaetwad<ypWlnvDQZ[kpza~>xawbまだxakaだxasaだvaetvaと{dNode6vac1vaて{dNode6vac0wad2ypXSxawdまとめてxakaてxasaてvaetwad1ypnxawcまとめxakaとxasbとめvaetvaぁ{dNode6vac0wad6ypytFCSpxawbまぁxakaぁxasaぁvaetvaせ{dNode6vac0wad2ypp}xawcませんxakaせxasbせんvaetwad5ypYkJzSxawaまxakaまxasaまvaetvaW{dNode6vac5vaS{dNode6vac1va2{dNode6vac0wad1ypXxawdWSL2xaka2xasa2vaetwad1ypXxawcWSLxakaSxasbSLvaetvai{dNode6vac3van{dNode6vac2vad{dNode6vac0wad2ypZoxawgWindowsxakadxasddowsvaetvat{dNode6vac0wad1ypcxawfWinterxakatxasctervaetwad0xawcWinxakanxasanvaesvat{dNode6vac0wad1ypjxawdWithxakatxasbthvaetvak{dNode6vac1vap{dNode6vac0wad1yp@xawiWikipediaxakapxasepediavaetwad1ypuxawdWikixakakxasbkivaetwad0xawbWixakaixasaivaesvao{dNode6vac3var{dNode6vac2vak{dNode6vac0wad3ypDIJxawiWorkplacexakakxasfkplacevaetval{dNode6vac0wad1ypyxaweWorldxakalxasbldvaetwad0xawcWorxakarxasarvaesvau{dNode6vac0wad1yp\xaweWouldxakauxasculdvaetvao{dNode6vac0wad1ypexaweWoogaxakaoxascogavaetwad0xawbWoxakaoxasaovaesvaa{dNode6vac2vat{dNode6vac0wad2ypVVxawgWatcherxakatxasetchervaetvan{dNode6vac0wad1ypixawhWantedlyxakanxasfntedlyvaetwad0xawbWaxakaaxasaavaesvae{dNode6vac2vaS{dNode6vac0wad2ypFFxawgWebSolrxakaSxasdSolrvaetvaM{dNode6vac0wad1ypdxawiWebMiningxakaMxasfMiningvaetwad0xawcWebxakaexasbebvaeswad0xawaWxakaWxasaWvaesvaU{dNode6vac5vab{dNode6vac0wad1ypXxawfUbuntuxakabxasebuntuvaetvaS{dNode6vac0wad1ypixawcUSBxakaSxasbSBvaetvan{dNode6vac2vax{dNode6vac0wad1ypGxawdUnixxakaxxasaxvaetvaD{dNode6vac0wad2ypyyxawfUniDicxakaDxascDicvaetwad0xawcUnixakanxasbnivaesvaI{dNode6vac0wad1yp@xawbUIxakaIxasaIvaetvaR{dNode6vac0wad1yptxawcURLxakaRxasbRLvaetwad0xawaUxakaUxasaUvaesva入{dNode6vac7vaれ{dNode6vac1vaる{dNode6vac0wad2ypgzxawc入れるxakaるxasaるvaetwad4ypXOhrxawb入れxakaれxasaれvaetva門{dNode6vac1va出{dNode6vac0wad1yplxawf入門出版記念xaka出xasd出版記念vaetwad<ypXXZ``vvYY^GH>xawb入門xaka門xasa門vaetvaっ{dNode6vac0wad2yp]Sxawb入っxakaっxasaっvaetva力{dNode6vac0wad1yp}xawe入力文字列xaka力xasd力文字列vaetvaり{dNode6vac1va浸{dNode6vac0wad1yp@xawd入り浸っxaka浸xasb浸っvaetwad2ypijxawb入りxakaりxasaりvaetva手{dNode6vac0wad1ypfxawb入手xaka手xasa手vaetvaる{dNode6vac0wad1ypIxawb入るxakaるxasaるvaetwad2yptxawa入xaka入xasa入vaetva開{dNode6vac5va発{dNode6vac3va中{dNode6vac0wad2yp{Lxawc開発中xaka中xasa中vaetva者{dNode6vac0wad1yp[xawc開発者xaka者xasa者vaetva方{dNode6vac0wad1ypIxawe開発方法論xaka方xasc方法論vaetwad7ypXrYkJwrxawb開発xaka発xasa発vaetva催{dNode6vac0wad<yp\U^_c||xMNPT_bimosvwGLS_elxadekPV>xawb開催xaka催xasa催vaetva始{dNode6vac0wad1ypsxawb開始xaka始xasa始vaetva場{dNode6vac0wad5ypimwGLxawd開場提供xaka場xasc場提供vaetvaい{dNode6vac0wad1yp]xawb開いxakaいxasaいvaetwad0xawa開xaka開xasa開vaesvaか{dNode6vac9vaら{dNode6vac4vaか{dNode6vac0wad1ypLxawcからかxakaかxasaかvaetvaお{dNode6vac0wad1ypfxawcからおxakaおxasaおvaetvaっ{dNode6vac0wad1ypGxawcからっxakaっxasaっvaetvaい{dNode6vac0wad1ypAxawfからいくつかxakaいxasdいくつかvaetwad<yp]RTY]_aghkqzzFO^egkmtwxz~BHQqs{BOR\]__`bmoqqstuyDPSWbfgorsx|ABHPRhjprDEGP>xawbからxakaらxasaらvaetvaけ{dNode6vac2vaて{dNode6vac0wad1ypfxawcかけてxakaてxasaてvaetvaず{dNode6vac0wad1ypfxawcかけずxakaずxasaずvaetwad2ypYtxawbかけxakaけxasaけvaetvaか{dNode6vac0wad1ypfxawcかかるxakaかxasbかるvaetvaな{dNode6vac2vaく{dNode6vac0wad1ypqxawcかなくxakaくxasaくvaetvaり{dNode6vac0wad1ypDxawcかなりxakaりxasaりvaetwad0xawbかなxakaなxasaなvaesvaど{dNode6vac0wad1yp~xawdかどうかxakaどxascどうかvaetvaっ{dNode6vac0wad4ypS\a{xawbかっxakaっxasaっvaetvaや{dNode6vac0wad1ypaxawcかやっxakaやxasbやっvaetvaち{dNode6vac0wad1ypjxawdかちゃんxakaちxascちゃんvaetvaも{dNode6vac0wad1ypqxawbかもxakaもxasaもvaetwad<ypX]SghS[_`zAGGLUV[\aCKLYoz}}`ko{R>xawaかxakaかxasaかvaetvaバ{dNode6vac4vaッ{dNode6vac2vaエ{dNode6vac0wad1ypXxawjバックエンドエンジンxakaエxasgエンドエンジンvaetvaア{dNode6vac0wad1yp]xawfバックアップxakaアxascアップvaetwad0xawcバックxakaッxasbックvaesvaグ{dNode6vac1vaフ{dNode6vac0wad1ypQxawgバグフィックスxakaフxaseフィックスvaetwad1ypGxawbバグxakaグxasaグvaetvaー{dNode6vac2vaジ{dNode6vac0wad1ypVxaweバージョンxakaジxascジョンvaetvaコ{dNode6vac0wad1ypExaweバーコードxakaコxascコードvaetwad0xawbバーxakaーxasaーvaesvaイ{dNode6vac0wad1ypnxawdバイナリxakaイxascイナリvaetwad2ypZOxawaバxakaバxasaバvaetva前{dNode6vac5va回{dNode6vac2va読{dNode6vac0wad1ypXxawd前回読んxaka読xasb読んvaetva購{dNode6vac0wad1ypCxawd前回購入xaka購xasb購入vaetwad<ypYZPenovw{@AEFGHIMNPRT\xEER}LLVaAL>xawb前回xaka回xasa回vaetva々{dNode6vac1va紹{dNode6vac0wad1yp@xawe前々回紹介xaka紹xasb紹介vaetwad2ypexawc前々回xaka々xasb々回vaetvaま{dNode6vac0wad1ypwxawc前までxakaまxasbまでvaetvaな{dNode6vac0wad1ypvxawc前なんxakaなxasbなんvaetvaく{dNode6vac0wad1ypRxawd前くらいxakaくxascくらいvaetwad7ypNVlV\Mbxawa前xaka前xasa前vaetvaV{dNode6vac6vaS{dNode6vac0wad1ypYxawbVSxakaSxasaSvaetvae{dNode6vac0wad1yp]xawhVerticalxakaexasgerticalvaetvai{dNode6vac0wad1ypUxawfVisualxakaixaseisualvaetvaa{dNode6vac0wad1ypkxawgVagrantxakaaxasfagrantvaetvaM{dNode6vac0wad1ypkxawbVMxakaMxasaMvaetvao{dNode6vac0wad3ypNZ[xawdVotexakaoxascotevaetwad0xawaVxakaVxasaVvaesva＋{dNode6vac0wad7ypYOWaaM\xawa＋xaka＋xasa＋vaetva残{dNode6vac5va課{dNode6vac0wad1ypYxawc残課題xaka課xasb課題vaetvaし{dNode6vac0wad<ypR]fu[nvDLNlyGuF>xawb残しxakaしxasaしvaetvaり{dNode6vac0wad2ypFzxawb残りxakaりxasaりvaetva念{dNode6vac0wad2ypaFxawb残念xaka念xasa念vaetvaす{dNode6vac0wad1ypRxawb残すxakaすxasaすvaetwad0xawa残xaka残xasa残vaesvaマ{dNode6vac5vaル{dNode6vac2vaン{dNode6vac0wad1ypYxawhマルチコンテナ化xakaンxasdンテナ化vaetvaア{dNode6vac0wad1ypNxaweマルチコアxakaアxasaアvaetwad0xawdマルチコxakaルxascルチコvaesvaー{dNode6vac0wad1yprxawcマージxakaーxasbージvaetvaニ{dNode6vac0wad1yp}xaweマニアックxakaニxasdニアックvaetvaシ{dNode6vac0wad1yp\xawcマシンxakaシxasbシンvaetvaッ{dNode6vac0wad1ypjxaweマッピングxakaッxasdッピングvaetwad0xawaマxakaマxasaマvaesvap{dNode6vac7var{dNode6vac2vae{dNode6vac0wad1ypZxawcprexakaexasaevaetvao{dNode6vac0wad1ypjxawgprofilexakaoxaseofilevaetwad0xawbprxakarxasarvaesvay{dNode6vac2vas{dNode6vac0wad3yp\mmxawepyspaxakasxascspavaetvaf{dNode6vac0wad2ypAsxawepyfesxakafxascfesvaetwad0xawbpyxakayxasayvaesvau{dNode6vac2vab{dNode6vac0wad1ypHxawcpubxakabxasabvaetvap{dNode6vac0wad1ypkxawipuppet使ってxakapxasgppet使ってvaetwad0xawbpuxakauxasauvaesvai{dNode6vac0wad1ypQxawgpicoclixakaixasficoclivaetval{dNode6vac2vau{dNode6vac0wad4yp^APwxawfpluginxakauxasduginvaetvae{dNode6vac0wad1yp\xawfpleasexakaexasdeasevaetwad0xawbplxakalxasalvaesvae{dNode6vac0wad1ypNxawkperformancexakaexasjerformancevaetvaa{dNode6vac0wad1ypfxawjpaperwhitexakaaxasiaperwhitevaetwad0xawapxakapxasapvaesva-{dNode6vac1va&{dNode6vac0wad1ypHxawb-&xaka&xasa&vaetwad<ypZX]{{{{}@@@@AAAAEEEEMMMPPQRY[oo||UU[\]^HJJ]`bcn{{~JXvvy~@DKMMNNWW\^_bmp@@GKKKKLMNO>xawa-xaka-xasa-vaetvac{dNode6vac4vao{dNode6vac3vam{dNode6vac3vam{dNode6vac0wad1ypZxawfcommitxakamxascmitvaetvai{dNode6vac0wad1ypdxawfcomingxakaixascingvaetvap{dNode6vac0wad1ypJxawlcompositePOSxakapxasipositePOSvaetwad2ypoqxawccomxakamxasamvaetvan{dNode6vac3van{dNode6vac0wad1ypoxawhconnpassxakanxasenpassvaetvas{dNode6vac0wad1ypNxawnconsiderationsxakasxasksiderationsvaetvat{dNode6vac0wad1ypExawjcontributexakatxasgtributevaetwad0xawcconxakanxasanvaesvac{dNode6vac0wad1ypRxawicocoatomoxakacxasgcoatomovaetwad0xawbcoxakaoxasaovaesvai{dNode6vac0wad1ypHxawfcipherxakaixaseiphervaetvah{dNode6vac2van{dNode6vac0wad2yp\Axawgchangesxakanxasdngesvaetvas{dNode6vac0wad1ypLxawfchasenxakasxascsenvaetwad0xawcchaxakahxasbhavaesvau{dNode6vac0wad1ypoxawgcuratorxakauxasfuratorvaetwad0xawacxakacxasacvaesva組{dNode6vac2vaみ{dNode6vac0wad2ypZjxawb組みxakaみxasaみvaetvaん{dNode6vac0wad1ypkxawb組んxakaんxasaんvaetwad0xawa組xaka組xasa組vaesva合{dNode6vac4vaわ{dNode6vac1vaせ{dNode6vac1vaて{dNode6vac0wad1ypZxawd合わせてxakaてxasaてvaetwad1ypZxawc合わせxakaせxasaせvaetwad1ypwxawb合わxakaわxasaわvaetvaい{dNode6vac0wad2ypVZxawb合いxakaいxasaいvaetva間{dNode6vac0wad1yp{xawb合間xaka間xasa間vaetvaっ{dNode6vac0wad1ypfxawb合っxakaっxasaっvaetwad0xawa合xaka合xasa合vaesva困{dNode6vac0wad2ypZ_xawb困っxaka困xasb困っvaetva知{dNode6vac5vaり{dNode6vac2va合{dNode6vac0wad3ypZXaxawd知り合いxaka合xasb合いvaetvaつ{dNode6vac0wad1ypFxawd知りつつxakaつxasbつつvaetwad3ypVZfxawb知りxakaりxasaりvaetvaら{dNode6vac1vaせ{dNode6vac0wad4ypxxHHxawc知らせxakaせxasaせvaetwad1ypqxawb知らxakaらxasaらvaetvaれ{dNode6vac0wad2ypz}xawb知れxakaれxasaれvaetvaる{dNode6vac0wad1ypzxawb知るxakaるxasaるvaetva人{dNode6vac0wad1yp_xawb知人xaka人xasa人vaetwad0xawa知xaka知xasa知vaesvaチ{dNode6vac3vaャ{dNode6vac0wad1ypZxawdチャットxakaャxascャットvaetvaー{dNode6vac0wad1ypexawcチームxakaーxasbームvaetvaケ{dNode6vac0wad6ypJJKKKsxawdチケットxakaケxascケットvaetwad0xawaチxakaチxasaチvaesva始{dNode6vac2vaめ{dNode6vac1vaま{dNode6vac0wad3yp[V|xawd始めましxakaまxasbましvaetwad<ypg{@AEMPRT`kQR`|Q>xawb始めxakaめxasaめvaetvaま{dNode6vac3vaる{dNode6vac0wad1yp^xawc始まるxakaるxasaるvaetvaり{dNode6vac1vaま{dNode6vac0wad1ypCxawe始まりましxakaまxasbましvaetwad1ypExawc始まりxakaりxasaりvaetvaっ{dNode6vac0wad1ypNxawc始まっxakaっxasaっvaetwad0xawb始まxakaまxasaまvaeswad0xawa始xaka始xasa始vaesvaき{dNode6vac4vaち{dNode6vac0wad1yp[xawcきちんxakaちxasbちんvaetvaま{dNode6vac0wad<yp\obfggzWyzPVijloorsBKPXacdov>xawcきましxakaまxasbましvaetvaて{dNode6vac0wad5ypp]JOUxawbきてxakaてxasaてvaetvaっ{dNode6vac0wad1ypYxawdきっかけxakaっxascっかけvaetwad8yppzk|TKyTxawaきxakaきxasaきvaetva季{dNode6vac0wad4yp\\Chxawb季節xaka季xasb季節vaetvaや{dNode6vac6vaっ{dNode6vac1vaぱ{dNode6vac0wad1ypaxawgやっぱりいいよxakaぱxaseぱりいいよvaetwad:yp\kzrrr[dQRxawbやっxakaっxasaっvaetvaり{dNode6vac1vaま{dNode6vac0wad1ypvxawdやりましxakaまxasbましvaetwad2ypzTxawbやりxakaりxasaりvaetvaる{dNode6vac0wad2ypxuxawbやるxakaるxasaるvaetvaら{dNode6vac0wad1ypRxawbやらxakaらxasaらvaetvaけ{dNode6vac0wad1ypxawbやけxakaけxasaけvaetvaい{dNode6vac0wad1yp`xawbやいxakaいxasaいvaetwad<ypRdfh_rffFZpqBkoAE>xawaやxakaやxasaやvaetvaB{dNode6vac6vae{dNode6vac2var{dNode6vac0wad8yp\U^_||ffxawfBerlinxakarxasdrlinvaetvat{dNode6vac0wad3ypABJxawdBetaxakatxasbtavaetwad0xawbBexakaexasaevaesvau{dNode6vac3vaz{dNode6vac0wad6yp\U^_||xawiBuzzwordsxakazxasgzzwordsvaetvai{dNode6vac0wad1ypCxaweBuildxakaixascildvaetval{dNode6vac0wad1yp^xawdBulkxakalxasblkvaetwad0xawbBuxakauxasauvaesvai{dNode6vac3vao{dNode6vac0wad1yp]xawjBiomedicalxakaoxashomedicalvaetvag{dNode6vac0wad1yp|xawcBigxakagxasagvaetvar{dNode6vac0wad1ypsxawdBirdxakarxasbrdvaetwad0xawbBixakaixasaivaesvao{dNode6vac2vao{dNode6vac1vas{dNode6vac1vac{dNode6vac0wad1yplxawhBookscanxakacxasccanvaetwad1ypuxaweBooksxakasxasasvaetwad9yp{@AEMPRTBxawdBookxakaoxasbokvaetvan{dNode6vac0wad1ypoxawgBonfirexakanxasenfirevaetwad0xawbBoxakaoxasaovaesvaR{dNode6vac0wad1yp[xawfBRAVIAxakaRxaseRAVIAvaetvaa{dNode6vac0wad2ypIMxaweBashoxakaaxasdashovaetwad0xawaBxakaBxasaBvaesvaオ{dNode6vac6vaン{dNode6vac0wad5yp\\U_|xaweオンラインxakaンxasdンラインvaetvaー{dNode6vac2vaト{dNode6vac0wad3yp_PQxawiオートコンプリートxakaトxasgトコンプリートvaetvaプ{dNode6vac0wad1ypoxawhオープンセミナーxakaプxasfプンセミナーvaetwad0xawbオーxakaーxasaーvaesvaッ{dNode6vac0wad1ypYxawbオッxakaッxasaッvaetvaフ{dNode6vac2vaラ{dNode6vac0wad1ypcxaweオフラインxakaラxascラインvaetvaィ{dNode6vac0wad2yp@@xawdオフィスxakaィxasbィスvaetwad0xawbオフxakaフxasaフvaesvaラ{dNode6vac1va・{dNode6vac0wad1ypgxawjオライリー・ジャパンxaka・xase・ジャパンvaetwad1ypgxaweオライリーxakaラxasdライリーvaetvaシ{dNode6vac0wad1ypgxawdオシャレxakaシxascシャレvaetwad0xawaオxakaオxasaオvaesva出{dNode6vac;va張{dNode6vac1va中{dNode6vac0wad1ypqxawc出張中xaka中xasa中vaetwad6yp\U_|wBxawb出張xaka張xasa張vaetva力{dNode6vac0wad3ypFMNxawb出力xaka力xasa力vaetvaま{dNode6vac2vaし{dNode6vac0wad1ypExawc出ましxakaしxasaしvaetvaす{dNode6vac0wad1ypdxawd出ますよxakaすxasbすよvaetwad0xawb出まxakaまxasaまvaesva版{dNode6vac0wad2ypMlxawd出版記念xaka版xasc版記念vaetvaて{dNode6vac0wad3ypTsCxawb出てxakaてxasaてvaetvaし{dNode6vac1vaま{dNode6vac0wad1ypsxawd出しましxakaまxasbましvaetwad1ypXxawb出しxakaしxasaしvaetva来{dNode6vac0wad2ypwKxawc出来るxaka来xasb来るvaetva会{dNode6vac0wad1ypRxawc出会っxaka会xasb会っvaetva演{dNode6vac0wad1ypaxawb出演xaka演xasa演vaetva口{dNode6vac0wad1ypixawb出口xaka口xasa口vaetva先{dNode6vac0wad1yp}xawb出先xaka先xasa先vaetwad3ypVg~xawa出xaka出xasa出vaetvaハ{dNode6vac2vaイ{dNode6vac0wad2yp\Uxawfハイブリッドxakaイxaseイブリッドvaetvaッ{dNode6vac0wad1ypoxawfハッシュタグxakaッxaseッシュタグvaetwad0xawaハxakaハxasaハvaesvaく{dNode6vac2vaら{dNode6vac0wad2ypfOxawcくらいxakaらxasbらいvaetvaれ{dNode6vac0wad1yplxawcくれるxakaれxasbれるvaetwad9yp\]zQBE]hyxawaくxakaくxasaくvaetvaれ{dNode6vac1vaる{dNode6vac0wad6ypSztenXxawbれるxakaるxasaるvaetwad<yp\VW`lr||DfpuFJJJYsJRRVaehmnrruyOSXZ[dhkmvIJKOUfikruvxy{@EHLM>xawaれxakaれxasaれvaetvaw{dNode6vac4vah{dNode6vac0wad1yp}xawjwhitespacexakahxasihitespacevaetvae{dNode6vac0wad1ypZxawbwexakaexasaevaetvai{dNode6vac2vat{dNode6vac0wad1ypxxawgwithoutxakatxasethoutvaetvak{dNode6vac0wad1ypxawiwikipediaxakakxasgkipediavaetwad0xawbwixakaixasaivaesvaa{dNode6vac0wad1yp\xawcwayxakaaxasbayvaetwad2yp]txawawxakawxasawvaetva紅{dNode6vac1va見{dNode6vac0wad1ypQxawc紅白見xaka見xasa見vaetwad3yp]YBxawb紅白xaka紅xasb紅白vaetva見{dNode6vac:vaる{dNode6vac0wad1yp[xawb見るxakaるxasaるvaetvaつ{dNode6vac2vaて{dNode6vac0wad1yp^xawd見つけてxakaてxasaてvaetvaま{dNode6vac0wad1yptxawe見つけましxakaまxasbましvaetwad5ypfu\~Jxawc見つけxakaつxasbつけvaetvaや{dNode6vac0wad1ypNxawb見やxakaやxasaやvaetvaな{dNode6vac0wad1ypBxawb見なxakaなxasaなvaetvaて{dNode6vac0wad5ypOVk`Axawb見てxakaてxasaてvaetva本{dNode6vac0wad1yp[xawb見本xaka本xasa本vaetva直{dNode6vac0wad1ypzxawb見直xaka直xasa直vaetvaか{dNode6vac0wad1ypQxawd見かけてxakaかxascかけてvaetvaま{dNode6vac0wad1ypsxawc見ましxakaまxasbましvaetvaた{dNode6vac0wad1ypPxawc見たいxakaたxasbたいvaetwad7yp]YHVy{xawa見xaka見xasa見vaetvaら{dNode6vac3vaみ{dNode6vac0wad1yp\xawbらみxakaみxasaみvaetvaか{dNode6vac0wad1ypIxawcらかけxakaかxasbかけvaetvaし{dNode6vac0wad2ypWFxawcらしいxakaしxasbしいvaetwad<yp]ZuBHQUegg{@UsMSg{aF>xawaらxakaらxasaらvaetva抱{dNode6vac0wad<yp]YkggttBBHHQQ{qqgZ`>xawb抱負xaka抱xasb抱負vaetvat{dNode6vac5vaa{dNode6vac0wad1yp^xawftaichixakaaxaseaichivaetvah{dNode6vac0wad<yp{{{{{@@@@@AAAAAEEEEEMMMMPPPRRTVVk\>xawcthexakahxasbhevaetvae{dNode6vac4vax{dNode6vac0wad1ypHxawdtextxakaxxasbxtvaetvam{dNode6vac0wad1ypzxawhtemplatexakamxasfmplatevaetvaa{dNode6vac0wad1ypexawdteamxakaaxasbamvaetval{dNode6vac0wad1yp\xawdtellxakalxasbllvaetwad0xawbtexakaexasaevaesvao{dNode6vac0wad2yp\[xawbtoxakaoxasaovaetvar{dNode6vac1vab{dNode6vac0wad1ypKxawmtrunkbranchesxakabxashbranchesvaetwad2yp@nxawetrunkxakarxasdrunkvaetwad0xawatxakatxasatvaesva仕{dNode6vac3va事{dNode6vac1va中{dNode6vac0wad1yp^xawc仕事中xaka中xasa中vaetwad8ypze@@cc`~xawb仕事xaka事xasa事vaetva組{dNode6vac0wad2ypdzxawb仕組xaka組xasa組vaetva様{dNode6vac0wad1yp^xawb仕様xaka様xasa様vaetwad0xawa仕xaka仕xasa仕vaesva本{dNode6vac7va記{dNode6vac0wad1yp_xawc本記事xaka記xasb記事vaetva日{dNode6vac0wad<ypllsVY[]`ahlnpuy~DHK>xawb本日xaka日xasa日vaetva当{dNode6vac0wad2yp_xawb本当xaka当xasa当vaetva書{dNode6vac0wad1ypOxawb本書xaka書xasa書vaetva出{dNode6vac0wad1yplxawe本出版記念xaka出xasd出版記念vaetva家{dNode6vac0wad1yprxawb本家xaka家xasa家vaetvaだ{dNode6vac0wad1ypTxawb本だxakaだxasaだvaetwad<ypZ`O[sYUUfffhj|>xawa本xaka本xasa本vaetva間{dNode6vac0wad7yp_wwpz|qxawa間xaka間xasa間vaetva空{dNode6vac2vaい{dNode6vac0wad3yp_wzxawb空いxakaいxasaいvaetvaき{dNode6vac0wad1ypwxawd空きましxakaきxascきましvaetwad0xawa空xaka空xasa空vaesva日{dNode6vac6va本{dNode6vac1va語{dNode6vac3va用{dNode6vac0wad2ypPQxawd日本語用xaka用xasa用vaetva対{dNode6vac0wad1yp`xawe日本語対応xaka対xasb対応vaetva形{dNode6vac1va析{dNode6vac1va器{dNode6vac0wad1ypYxawi日本語形態素解析器xaka器xasa器vaetwad1ypIxawh日本語形態素解析xaka析xasa析vaetwad1ypYxawg日本語形態素解xaka形xasd形態素解vaetwad7yp_LQoo@xawc日本語xaka語xasa語vaetwad1ypjxawb日本xaka本xasa本vaetva目{dNode6vac0wad1ypmxawb日目xaka目xasa目vaetva時{dNode6vac0wad3ypo[\xawb日時xaka時xasa時vaetva経{dNode6vac0wad1ypxxawb日経xaka経xasa経vaetvaま{dNode6vac0wad1yphxawc日までxakaまxasbまでvaetva々{dNode6vac0wad1yp|xawb日々xaka々xasa々vaetwad1ypuxawa日xaka日xasa日vaetvaど{dNode6vac5vaう{dNode6vac3vaや{dNode6vac2vaっ{dNode6vac1vaて{dNode6vac0wad1ypFxaweどうやってxakaてxasaてvaetwad1ypPxawdどうやっxakaっxasaっvaetvaら{dNode6vac0wad1ypYxawdどうやらxakaらxasaらvaetwad0xawcどうやxakaやxasaやvaesvaい{dNode6vac0wad1ypzxawdどういうxakaいxasbいうvaetvaし{dNode6vac0wad1ypWxawcどうしxakaしxasaしvaetwad2yprCxawbどうxakaうxasaうvaetvaん{dNode6vac0wad8ypST_f^[fxawbどんxakaんxasaんvaetvaち{dNode6vac0wad1ypNxawdどちらかxakaちxascちらかvaetvaー{dNode6vac0wad3ypsTwxawbどーxakaーxasaーvaetvaも{dNode6vac0wad2yptxawbどもxakaもxasaもvaetwad1ypVxawaどxakaどxasaどvaetva使{dNode6vac5vaう{dNode6vac0wad3ypPh`xawb使うxakaうxasaうvaetvaっ{dNode6vac0wad<ypVabijWhjSU^b>xawb使っxakaっxasaっvaetvaい{dNode6vac0wad4ypLQQxawb使いxakaいxasaいvaetva用{dNode6vac0wad1ypfxawb使用xaka用xasa用vaetvaえ{dNode6vac0wad1yp}xawb使えxakaえxasaえvaetwad0xawa使xaka使xasa使vaesva簡{dNode6vac0wad<ypP_nv@DIR]`bmJkO>xawb簡単xaka簡xasb簡単vaetva少{dNode6vac1vaし{dNode6vac1vaず{dNode6vac0wad1ypFxawd少しずつxakaずxasbずつvaetwad:ypPZtwwzSCuBxawb少しxakaしxasaしvaetwad2ypX{xawa少xaka少xasa少vaetvaパ{dNode6vac8vaタ{dNode6vac0wad1ypPxawdパターンxakaタxascターンvaetvaブ{dNode6vac0wad1ypWxawjパブリックプレビューxakaブxasiブリックプレビューvaetvaー{dNode6vac0wad3ypjssxawcパーツxakaーxasbーツvaetvaフ{dNode6vac0wad2yp~Nxawgパフォーマンスxakaフxasfフォーマンスvaetvaラ{dNode6vac0wad1ypBxaweパラメータxakaラxasdラメータvaetvaス{dNode6vac0wad1ypwxaweパスポートxakaスxasdスポートvaetvaシ{dNode6vac0wad1ypPxawcパシリxakaシxasbシリvaetvaッ{dNode6vac2vaチ{dNode6vac0wad4ypy~xawcパッチxakaチxasaチvaetvaケ{dNode6vac0wad1ypMxaweパッケージxakaケxascケージvaetwad0xawbパッxakaッxasaッvaeswad1ypMxawaパxakaパxasaパvaetva試{dNode6vac1vaし{dNode6vac0wad3yppAkxawb試しxakaしxasaしvaetwad1ypPxawa試xaka試xasa試vaetva風{dNode6vac2va邪{dNode6vac0wad2yphhxawb風邪xaka邪xasa邪vaetva雨{dNode6vac0wad1ypwxawb風雨xaka雨xasa雨vaetwad1ypQxawa風xaka風xasa風vaetvaう{dNode6vac2vaわ{dNode6vac0wad1ypQxawcうわさxakaわxasbわさvaetvaま{dNode6vac0wad1ypsxawcうまくxakaまxasbまくvaetwad1ypzxawaうxakaうxasaうvaetvaT{dNode6vac9vao{dNode6vac2vae{dNode6vac3vaF{dNode6vac0wad2ypQNxawkTokenFilterxakaFxasfFiltervaetvai{dNode6vac0wad1ypNxawiTokenizerxakaixasdizervaetva対{dNode6vac0wad1ypNxawhToken対してxaka対xasc対してvaetwad0xaweTokenxakaexasbenvaesvay{dNode6vac1vaN{dNode6vac0wad1ypdxawhTokyoNLPxakaNxascNLPvaetwad7ypgyzIPRKxaweTokyoxakayxasbyovaetwad0xawcTokxakaoxasbokvaesvaw{dNode6vac2vai{dNode6vac0wad<ypqqvPZYr}JPTUVafJ>xawgTwitterxakaixaseittervaetvae{dNode6vac0wad1yprxawiTweetDeckxakaexasgeetDeckvaetwad0xawbTwxakawxasawvaesvae{dNode6vac2var{dNode6vac0wad1ypxxawiTerraformxakarxasgrraformvaetvac{dNode6vac1van{dNode6vac0wad2yppuxawjTechnologyxakanxasfnologyvaetwad1ypsxawdTechxakacxasbchvaetwad0xawbTexakaexasaevaesvaO{dNode6vac1vaE{dNode6vac0wad2ypgtxaweTOEICxakaExascEICvaetwad1ypgxawbTOxakaOxasaOvaetvaa{dNode6vac1vas{dNode6vac0wad1ypaxaweTalksxakasxasasvaetwad1ypsxawdTalkxakaaxascalkvaetvah{dNode6vac2vae{dNode6vac0wad4ypU^cuxawcThexakaexasaevaetvaa{dNode6vac0wad1ypjxawfThanksxakaaxasdanksvaetwad0xawbThxakahxasahvaesvaD{dNode6vac0wad2ypR^xawbTDxakaDxasaDvaetvaL{dNode6vac0wad3ypTVQxawbTLxakaLxasaLvaetvaS{dNode6vac0wad1ypOxawgTSUTAYAxakaSxasfSUTAYAvaetwad0xawaTxakaTxasaTvaesvaL{dNode6vac6vau{dNode6vac2vac{dNode6vac0wad<ypQ~~[]`ahlnpy~DHKYnNXXmmvIM^sxxEHHNQ>xawfLucenexakacxasdcenevaetvan{dNode6vac0wad1ypaxawgLunakeyxakanxasenakeyvaetwad0xawbLuxakauxasauvaesvaU{dNode6vac0wad1ypQxawdLUCExakaUxascUCEvaetvae{dNode6vac0wad1ypXxawhLearningxakaexasgearningvaetvai{dNode6vac4vat{dNode6vac0wad1yp]xawjLiteraturexakatxashteraturevaetvag{dNode6vac0wad1ypnxaweLightxakagxascghtvaetvan{dNode6vac0wad2yprYxawgLinderaxakanxasenderavaetvao{dNode6vac0wad1yppxawdLionxakaoxasbonvaetwad0xawbLixakaixasaivaesvaT{dNode6vac0wad1yplxawbLTxakaTxasaTvaetvao{dNode6vac0wad7ypYYjABEExawhLogstashxakaoxasgogstashvaetwad0xawaLxakaLxasaLvaesva取{dNode6vac2vaり{dNode6vac1va込{dNode6vac1vaる{dNode6vac0wad1ypJxawf取り込まれるxakaるxasaるvaetwad1ypQxawe取り込まれxaka込xasc込まれvaetwad2ypzGxawb取りxakaりxasaりvaetvaる{dNode6vac0wad2ypgFxawb取るxakaるxasaるvaetwad0xawa取xaka取xasa取vaesva聞{dNode6vac3vaき{dNode6vac1vaま{dNode6vac0wad1ypQxawd聞きましxakaまxasbましvaetwad3ypqcpxawb聞きxakaきxasaきvaetvaい{dNode6vac0wad3ypzRYxawb聞いxakaいxasaいvaetvaけ{dNode6vac0wad1ypIxawc聞けるxakaけxasbけるvaetwad0xawa聞xaka聞xasa聞vaesva.{dNode6vac0wad<ypRRVl~~DDHNijooqx|}}IIIIIIIJUUVVWWWWXXXXXYYYY[[[[\]]]]^^``````aaaaaaddddddhhhhkkllllnnnnpppprttuuuuuuxxxxyyyyyy}}}}~~~~~~AABBBBBDDDDDDHHHHHHJJJKKKKKQQQQRRRRnnnnrrrrzJNNXXXXZ[[mmmmttvv|~~@@CDDGGGHHIILLMMNN[^bbmmxGGHMM>xawa.xaka.xasa.vaetva際{dNode6vac0wad1ypRxawa際xaka際xasa際vaetva修{dNode6vac0wad6ypR~~DbGxawb修正xaka修xasb修正vaetva個{dNode6vac2va的{dNode6vac0wad3ypR]oxawc個人的xaka的xasa的vaetva用{dNode6vac0wad1ypCxawc個人用xaka用xasa用vaetwad2ypJzxawb個人xaka個xasb個人vaetvaお{dNode6vac<vaき{dNode6vac1vaま{dNode6vac0wad<ypRX]fjuNyGZuF>xawdおきますxakaまxasbますvaetwad1ypBxawbおきxakaきxasaきvaetvaこ{dNode6vac2vaか{dNode6vac0wad1ypZxawdおこうかxakaかxasaかvaetvaう{dNode6vac0wad1ypaxaweおこううかxakaうxasbうかvaetwad2ypLkxawcおこうxakaこxasbこうvaetva試{dNode6vac0wad2ypoUxawcお試しxaka試xasb試しvaetvaか{dNode6vac2vaげ{dNode6vac0wad1yptxawcおかげxakaげxasaげvaetvaし{dNode6vac0wad1ypzxawdおかしいxakaしxasbしいvaetwad0xawbおかxakaかxasaかvaesvaも{dNode6vac0wad1ypSxawdおもしろxakaもxascもしろvaetvaり{dNode6vac0wad3yp]{@xawbおりxakaりxasaりvaetvaめ{dNode6vac0wad4ypAPp_xawbおめxakaめxasaめvaetvaよ{dNode6vac0wad1ypVxawcおよびxakaよxasbよびvaetvaた{dNode6vac0wad1ypzxawdおたしてxakaたxascたしてvaetva決{dNode6vac0wad1yppxawdお決まりxaka決xasc決まりvaetvaい{dNode6vac1vaて{dNode6vac0wad1yppxawcおいてxakaてxasaてvaetwad1ypUxawbおいxakaいxasaいvaetva久{dNode6vac0wad2yp|]xaweお久しぶりxaka久xasd久しぶりvaetvaし{dNode6vac0wad1ypjxawdおしゃれxakaしxascしゃれvaetvaっ{dNode6vac0wad1ypjxawcおっきxakaっxasbっきvaetvaろ{dNode6vac0wad1ypdxawbおろxakaろxasaろvaetva知{dNode6vac0wad1ypGxaweお知らせしxaka知xasd知らせしvaet>wad<yptCW]]^gx{~ozA|Bl\evxxHH>xawaおxakaおxasaおvaetvaQ{dNode6vac2vaq{dNode6vac0wad2ypSTxawfQuerqyxakaqxasbqyvaetvay{dNode6vac0wad1yp^xaweQueryxakayxasayvaetwad0xawdQuerxakaQxasdQuervaesvaE{dNode6vac8val{dNode6vac2vaa{dNode6vac1vas{dNode6vac1vat{dNode6vac1vai{dNode6vac1vac{dNode6vac2vas{dNode6vac1vae{dNode6vac1vac{dNode6vac1vah{dNode6vac3va1{dNode6vac0wad1ypxxawnElasticsearch1xaka1xasa1vaetva勉{dNode6vac0wad<ypprGMNPT_bbovFSh>xaw PElasticsearch勉強会xaka勉xasc勉強会vaetvaユ{dNode6vac0wad1ypNxaw PElasticsearchユーザxakaユxascユーザvaetwad<ypSVllKLLnuvDIIJRWWXX[\\]^`acddhjlnpsu|}JNPQQSVX^ijkmopr|O>xawmElasticsearchxakahxasahvaetwad1yprxawlElasticsearcxakacxasacvaetwad1ypIxawkElasticsearxakaexascearvaetwad1ypCxawhElasticsxakasxasasvaetvaS{dNode6vac1var{dNode6vac2va勉{dNode6vac0wad1ypAxaw PElasticSearch勉強会xaka勉xasc勉強会vaetvaネ{dNode6vac0wad1ypBxawoElasticSearchネタxakaネxasbネタvaetwad4ypdh~AxawmElasticSearchxakarxascrchvaetwad1yp~xawjElasticSeaxakaSxascSeavaetwad<yplDDJlnuvyCCDEIJZek>xawgElasticxakacxasacvaetwad3ypq|TxawfElastixakaixasaivaetwad2ypSKxaweElastxakatxasatvaetwad9ypl[]hny~DFxawdElasxakasxasasvaetwad2yplpxawcElaxakaaxasaavaetvas{dNode6vac0wad6ypimwGL_xawoElsticsearch勉強会xakasxasmsticsearch勉強会vaetwad0xawbElxakalxasalvaesvax{dNode6vac0wad1ypXxawgExtremexakaxxasfxtremevaetvan{dNode6vac3vat{dNode6vac0wad1ypJxawjEnterprisexakatxashterprisevaetvau{dNode6vac0wad1ypPxawdEnumxakauxasbumvaetvag{dNode6vac1vai{dNode6vac0wad1ypsxawkEngineeringxakaixascingvaetwad1ypgxawhEngineerxakagxasfgineervaetwad0xawbEnxakanxasanvaesvaa{dNode6vac0wad1ypsxaweEarlyxakaaxasdarlyvaetvad{dNode6vac0wad2ypuuxawgEditionxakadxasfditionvaetvaテ{dNode6vac0wad1ypAxawcEテレxakaテxasbテレvaetvac{dNode6vac0wad1yp}xawgEclipsexakacxasfclipsevaetvav{dNode6vac0wad1ypBxawhEvernotexakavxasgvernotevaetwad2yp`axawaExakaExasaEvaetvaち{dNode6vac3vaょ{dNode6vac2vaっ{dNode6vac0wad<ypSVvAC{]qEEN\Cquw>xawcちょっxakaっxasaっvaetvaく{dNode6vac0wad1ypMxawfちょくちょくxakaくxasdくちょくvaetwad0xawbちょxakaょxasaょvaesvaゃ{dNode6vac2vaい{dNode6vac0wad1ypvxaweちゃいましxakaいxascいましvaetvaっ{dNode6vac0wad1ypGxawcちゃっxakaっxasaっvaetwad0xawbちゃxakaゃxasaゃvaesvaな{dNode6vac0wad1ypxxawcちなみxakaなxasbなみvaetwad4ypFnxkxawaちxakaちxasaちvaetva調{dNode6vac2vaべ{dNode6vac2vaる{dNode6vac0wad3ypCHHxawc調べるxakaるxasaるvaetvaま{dNode6vac0wad1ypExawd調べましxakaまxasbましvaetwad7ypSTfJNTRxawb調べxakaべxasaべvaetva査{dNode6vac0wad4ypCJxawb調査xaka査xasa査vaetwad0xawa調xaka調xasa調vaesvaみ{dNode6vac8vaま{dNode6vac2vaし{dNode6vac0wad<ypSTs~KOOSTV_wJOQUahSYu>xawcみましxakaしxasaしvaetvaす{dNode6vac0wad2ypIHxawcみますxakaすxasaすvaetwad0xawbみまxakaまxasaまvaesvaん{dNode6vac0wad2ypr|xawbみんxakaんxasaんvaetvaよ{dNode6vac0wad1ypvxawbみよxakaよxasaよvaetvaる{dNode6vac0wad1ypKxawbみるxakaるxasaるvaetvaな{dNode6vac0wad1ypOxawdみなさんxakaなxascなさんvaetvaて{dNode6vac0wad1ypmxawbみてxakaてxasaてvaetvaれ{dNode6vac0wad2ypvpxawbみれxakaれxasaれvaetvaみ{dNode6vac0wad1ypKxawbみみxakaみxasaみvaetwad<ypTVbdyzDSUnq{CDK[cZj}CJ]`htwRR>xawaみxakaみxasaみvaetvaS{dNode6vac<vao{dNode6vac2val{dNode6vac1vaJ{dNode6vac0wad1yplxawfSolrJPxakaJxasbJPvaetwad<ypSYlllnpsvvv}CEFJKNSXXZ_kmmtttv|GHHIM^^cjossxxzHHNQ>xawdSolrxakalxasblrvaetvaf{dNode6vac0wad2ypahxaweSoflexakafxascflevaetwad1yphxawbSoxakaoxasaovaetvae{dNode6vac4vaa{dNode6vac0wad<ypWX[]``dfxBBCDIJJUW]]sCQSSTu>xawfSearchxakaaxasdarchvaetvam{dNode6vac2vaa{dNode6vac0wad3ypXX`xawhSemanticxakaaxaseanticvaetvai{dNode6vac0wad1ypgxawgSeminarxakaixasdinarvaetwad0xawcSemxakamxasamvaesvar{dNode6vac2vai{dNode6vac0wad1ypLxaweServixakaixasaivaetvae{dNode6vac1va日{dNode6vac0wad1yphxawjServer日本語版xaka日xasd日本語版vaetwad1ypdxawfServerxakaexasbervaetwad0xawdServxakarxasbrvvaesvan{dNode6vac0wad3ypUUUxaweSensexakanxascnsevaetwad0xawbSexakaexasaevaesvap{dNode6vac3vae{dNode6vac0wad1yp]xawhSpecificxakaexasfecificvaetvar{dNode6vac0wad1ypBxawfSpringxakarxasdringvaetval{dNode6vac0wad2ypjjxawfSplunkxakalxasdlunkvaetwad1ypxxawbSpxakapxasapvaetvat{dNode6vac3vau{dNode6vac2vay{dNode6vac0wad1yp]xaweStudyxakayxasayvaetvai{dNode6vac0wad1ypUxawfStudioxakaixasbiovaetwad0xawdStudxakauxasbudvaesvaa{dNode6vac0wad3ypDyCxaweStackxakaaxascackvaetvao{dNode6vac0wad1ypUxaweStoryxakaoxascoryvaetwad0xawbStxakatxasatvaesval{dNode6vac0wad1ypbxawfSlidesxakalxaselidesvaetvau{dNode6vac3vag{dNode6vac0wad1ypfxawgSuggestxakagxaseggestvaetvam{dNode6vac0wad5ypPRTxxxawfSummitxakamxasdmmitvaetvas{dNode6vac0wad1yp\xawgSusheelxakasxasesheelvaetwad0xawbSuxakauxasauvaesvaD{dNode6vac0wad1ypBxawcSDKxakaDxasbDKvaetvaO{dNode6vac2vaN{dNode6vac0wad1yp[xawdSONYxakaNxasbNYvaetvaL{dNode6vac0wad1ypJxawdSOLRxakaLxasbLRvaetwad0xawbSOxakaOxasaOvaesvaa{dNode6vac0wad1ypgxawfSasukexakaaxaseasukevaetvac{dNode6vac2vai{dNode6vac0wad3ypooxxawgSciencexakaixaseiencevaetvaa{dNode6vac0wad1ypRxaweScalaxakaaxascalavaetwad0xawbScxakacxasacvaesvaw{dNode6vac1vap{dNode6vac0wad2ypEExawhSwiftypexakapxasbpevaetwad1ypExawfSwiftyxakawxasewiftyvaetvah{dNode6vac0wad3ypVVrxawfShieldxakahxasehieldvaetvaE{dNode6vac0wad1ypQxawbSExakaExasaEvaet>wad2yp]GxawaSxakaSxasaSvaetvaク{dNode6vac5vaエ{dNode6vac1vaプ{dNode6vac0wad1ypIxaweクエリプロxakaプxasbプロvaetwad1ypTxawcクエリxakaエxasbエリvaetvaラ{dNode6vac2vaイ{dNode6vac1vaア{dNode6vac0wad1yprxawiクライアントアプリxakaアxascアプリvaetwad1ypVxawfクライアントxakaイxasdイアントvaetvaス{dNode6vac2vaタ{dNode6vac1vaー{dNode6vac0wad1ypxxaweクラスターxakaーxasaーvaetwad1ypkxawdクラスタxakaタxasaタvaetvaパ{dNode6vac0wad1yp@xaweクラスパスxakaパxasbパスvaetwad1ypMxawcクラスxakaスxasaスvaetwad0xawbクラxakaラxasaラvaesvaロ{dNode6vac0wad1yprxawdクローンxakaロxascローンvaetvaレ{dNode6vac0wad1ypuxawdクレートxakaレxascレートvaetvaイ{dNode6vac0wad1ypZxawgクイックツアーxakaイxasfイックツアーvaetwad0xawaクxakaクxasaクvaesva用{dNode6vac1va意{dNode6vac0wad3ypvGxawb用意xaka意xasa意vaetwad1ypTxawa用xaka用xasa用vaetva概{dNode6vac2va要{dNode6vac0wad6ypTvIoBQxawb概要xaka要xasa要vaetva念{dNode6vac1va的{dNode6vac0wad1yptxawc概念的xaka的xasa的vaetwad1ypTxawb概念xaka念xasa念vaetwad1ypzxawa概xaka概xasa概vaetva追{dNode6vac4vaい{dNode6vac0wad1ypTxawd追いかけxakaいxascいかけvaetvaっ{dNode6vac0wad2yp@Zxawb追っxakaっxasaっvaetva加{dNode6vac0wad2ypr~xawb追加xaka加xasa加vaetva記{dNode6vac0wad1yp~xawb追記xaka記xasa記vaetwad0xawa追xaka追xasa追vaesva感{dNode6vac4vaじ{dNode6vac0wad9ypTyylm]_lqxawb感じxakaじxasaじvaetva想{dNode6vac1va文{dNode6vac0wad1yp[xawc感想文xaka文xasa文vaetwad8yp_Omwwky{xawb感想xaka想xasa想vaetva満{dNode6vac0wad1ypexawc感満載xaka満xasb満載vaetva謝{dNode6vac0wad1yphxawb感謝xaka謝xasa謝vaetwad0xawa感xaka感xasa感vaesva現{dNode6vac3va地{dNode6vac0wad1ypUxawb現地xaka地xasa地vaetva在{dNode6vac0wad4ypt[}Oxawb現在xaka在xasa在vaetva状{dNode6vac1va確{dNode6vac0wad1ypWxawe現状確認会xaka確xasc確認会vaetwad1ypWxawb現状xaka状xasa状vaetwad0xawa現xaka現xasa現vaesva再{dNode6vac2va開{dNode6vac0wad2ypUwxawb再開xaka開xasa開vaetva生{dNode6vac0wad1ypYxawb再生xaka生xasa生vaetwad0xawa再xaka再xasa再vaesva人{dNode6vac4vaも{dNode6vac1vaる{dNode6vac0wad1ypUxawd人もいるxakaるxasaるvaetwad1yp_xawc人もいxakaもxasbもいvaetva生{dNode6vac1va初{dNode6vac0wad1ypfxawc人生初xaka初xasa初vaetwad1ypfxawb人生xaka生xasa生vaetva数{dNode6vac0wad1ypyxawb人数xaka数xasa数vaetva形{dNode6vac0wad1ypjxawb人形xaka形xasa形vaetwad5yppjV\yxawa人xaka人xasa人vaetva正{dNode6vac2va式{dNode6vac0wad1ypVxawb正式xaka式xasa式vaetva規{dNode6vac0wad1ypwxawd正規表現xaka規xasc規表現vaetwad0xawa正xaka正xasa正vaesva新{dNode6vac6vaし{dNode6vac2vaい{dNode6vac0wad4ypVWjxawc新しいxakaいxasaいvaetvaく{dNode6vac0wad2ypjsxawc新しくxakaくxasaくvaetwad0xawb新しxakaしxasaしvaesva機{dNode6vac0wad1yp`xawc新機能xaka機xasb機能vaetva型{dNode6vac0wad1ypcxawb新型xaka型xasa型vaetva規{dNode6vac2va書{dNode6vac0wad1ypFxawd新規書きxaka書xasb書きvaetva追{dNode6vac0wad1ypmxawf新規追加機能xaka追xasd追加機能vaetwad0xawb新規xaka規xasa規vaesva天{dNode6vac0wad1ypUxawc新天地xaka天xasb天地vaetva調{dNode6vac0wad1ypCxawb新調xaka調xasa調vaetwad1yplxawa新xaka新xasa新vaetva公{dNode6vac2va開{dNode6vac0wad3ypWOZxawb公開xaka開xasa開vaetva約{dNode6vac0wad1ypZxawb公約xaka約xasa約vaetwad1ypfxawa公xaka公xasa公vaetvaI{dNode6vac5van{dNode6vac4vad{dNode6vac0wad1ypWxaweIndexxakadxascdexvaetvag{dNode6vac2vas{dNode6vac0wad1ypKxawfIngestxakasxasbstvaetvar{dNode6vac0wad1ypnxawiIngersollxakarxasersollvaetwad0xawdIngexakagxasbgevaesvaf{dNode6vac0wad2ypuuxawkInformationxakafxasiformationvaetvas{dNode6vac0wad1yp\xawfInsidexakasxasdsidevaetwad0xawbInxakanxasanvaesvas{dNode6vac1vas{dNode6vac0wad2ypyxaweIssuexakasxascsuevaetwad1yp^xawbIsxakasxasasvaetvaD{dNode6vac0wad2ypEExawbIDxakaDxasaDvaetvao{dNode6vac0wad1ypqxawbIoxakaoxasaovaetvaP{dNode6vac0wad1ypOxawfIPAdicxakaPxasePAdicvaetwad2yplRxawaIxakaIxasaIvaetva別{dNode6vac5va名{dNode6vac0wad1ypWxawb別名xaka名xasa名vaetva開{dNode6vac0wad1yp^xawc別開催xaka開xasb開催vaetva日{dNode6vac0wad1yp^xawc別日程xaka日xasb日程vaetva関{dNode6vac0wad1yp|xawb別関xaka関xasa関vaetva々{dNode6vac0wad1ypLxawb別々xaka々xasa々vaetwad2ypHLxawa別xaka別xasa別vaetva段{dNode6vac0wad2ypW~xawb段階xaka段xasb段階vaetva年{dNode6vac3va末{dNode6vac0wad3ypX_fxawb年末xaka末xasa末vaetva始{dNode6vac0wad1ypfxawb年始xaka始xasa始vaetva越{dNode6vac0wad1yp^xawb年越xaka越xasa越vaetwad0xawa年xaka年xasa年vaesva次{dNode6vac2va回{dNode6vac0wad1yp_xawb次回xaka回xasa回vaetva期{dNode6vac0wad2ypqNxawb次期xaka期xasa期vaetwad<ypX[UVWXYZ[\]^`acdhjklnprtuxy}~ABDHKbSJ>xawa次xaka次xasa次vaetva論{dNode6vac1va自{dNode6vac0wad1yp]xawd論文自体xaka自xasb自体vaetwad2ypX]xawb論文xaka論xasb論文vaetva軽{dNode6vac1vaど{dNode6vac0wad1ypTxawd軽くどんxakaどxasbどんvaetwad3ypX]hxawb軽くxaka軽xasb軽くvaetvaM{dNode6vac<vau{dNode6vac2val{dNode6vac0wad1ypXxaweMultixakalxascltivaetvai{dNode6vac0wad1ypQxawdMuirxakaixasbirvaetwad0xawbMuxakauxasauvaesvaa{dNode6vac6vat{dNode6vac0wad1ypXxawhMatchingxakatxasftchingvaetvac{dNode6vac2vab{dNode6vac0wad2ypjkxawgMacbookxakabxasdbookvaetvak{dNode6vac0wad1ypWxawhMackerelxakakxasekerelvaetwad5ypbihpBxawcMacxakacxasacvaetvar{dNode6vac2vav{dNode6vac1vae{dNode6vac0wad3ypV}mxawfMarvelxakaexasbelvaetwad1ypVxawdMarvxakavxasavvaetvak{dNode6vac0wad2ypVVxawhMarkdownxakakxasekdownvaetwad0xawcMarxakarxasarvaesvap{dNode6vac2vap{dNode6vac0wad1ypcxawgMappingxakapxasdpingvaetvaR{dNode6vac0wad1yp\xawdMapRxakaRxasaRvaetwad0xawcMapxakapxasapvaesvav{dNode6vac0wad2ypttxaweMavenxakavxascvenvaetvah{dNode6vac0wad1ypnxawfMahoutxakahxasdhoutvaetwad0xawbMaxakaaxasaavaesvaI{dNode6vac0wad2yp^^xaweMICESxakaIxasdICESvaetvai{dNode6vac3van{dNode6vac0wad1ypaxawdMinixakanxasbnivaetvar{dNode6vac0wad1ypCxawiMircosoftxakarxasgrcosoftvaetval{dNode6vac0wad1ypoxawkMildensteinxakalxasildensteinvaetwad0xawbMixakaixasaivaesvaS{dNode6vac0wad1ypCxawbMSxakaSxasaSvaetvay{dNode6vac0wad1ypCxawfMyBuilxakayxaseyBuilvaetvae{dNode6vac3vae{dNode6vac0wad4ypqzIFxawfMeetupxakaexasdetupvaetvar{dNode6vac0wad2ypCIxaweMerryxakarxascrryvaetvaC{dNode6vac0wad2ypKQxaweMeCabxakaCxascCabvaetwad0xawbMexakaexasaevaesvaA{dNode6vac0wad1yp{xawhMANABIYAxakaAxasgANABIYAvaetvaL{dNode6vac0wad7yp~KN[`msxawbMLxakaLxasaLvaetvao{dNode6vac4var{dNode6vac0wad1ypExawjMorphlinesxakarxashrphlinesvaetvan{dNode6vac1vaD{dNode6vac0wad1ypixawgMongoDBxakaDxasbDBvaetwad1ypgxaweMongoxakanxascngovaetvau{dNode6vac0wad1yppxawhMountainxakauxasfuntainvaetvad{dNode6vac0wad2ypuuxawfModernxakadxasddernvaetwad0xawbMoxakaoxasaovaesvaT{dNode6vac0wad1yphxawbMTxakaTxasaTvaetvaB{dNode6vac0wad5yper}}AxawcMBAxakaBxasbBAvaet>wad0xawaMxakaMxasaMvaesval{dNode6vac5vaa{dNode6vac2vab{dNode6vac0wad1ypXxawelabelxakabxascbelvaetvan{dNode6vac0wad1ypxawhlanguagexakanxasfnguagevaetwad0xawblaxakaaxasaavaesvau{dNode6vac2van{dNode6vac1vau{dNode6vac0wad2yp}}xawjluceneutilxakauxasdutilvaetwad<ypnXv~@DMMNNWW^_bmp@@GKMNO>xawflucenexakanxasbnevaetvae{dNode6vac0wad1ypyxaweluceexakaexasaevaetwad0xawdlucexakauxascucevaesvay{dNode6vac0wad1ypxxawblyxakayxasayvaetvai{dNode6vac2vat{dNode6vac0wad1yptxawiliterallyxakatxasgterallyvaetvab{dNode6vac0wad1yp@xawclibxakabxasabvaetwad0xawblixakaixasaivaesvao{dNode6vac0wad2ypABxawhlogstashxakaoxasgogstashvaetwad1ypAxawalxakalxasalvaetvaf{dNode6vac4vao{dNode6vac0wad5ypX]rNKxawcforxakaoxasborvaetvai{dNode6vac2val{dNode6vac0wad1ypdxawffilterxakalxasdltervaetvae{dNode6vac0wad1yp|xawifieldTypexakaexasgeldTypevaetwad0xawbfixakaixasaivaesvan{dNode6vac0wad1ypHxawbfnxakanxasanvaetval{dNode6vac1vad{dNode6vac0wad1ypUxawgfluentdxakadxasadvaetwad1ypUxawffluentxakalxaseluentvaetwad0xawafxakafxasafvaesvai{dNode6vac4van{dNode6vac2vad{dNode6vac0wad1ypNxawhindexingxakadxasfdexingvaetvaq{dNode6vac0wad1yp~xawjinquisitorxakaqxashquisitorvaetwad6ypX\bboYxawbinxakanxasanvaetvaO{dNode6vac0wad1yprxawciOSxakaOxasbOSvaetvas{dNode6vac0wad1ypWxaweissuexakasxasdssuevaetvam{dNode6vac0wad1ypKxawdimplxakamxascmplvaetwad0xawaixakaixasaivaesva理{dNode6vac2va由{dNode6vac0wad8ypX]wzGjTRxawb理由xaka由xasa由vaetva論{dNode6vac0wad1ypgxawb理論xaka論xasa論vaetwad0xawa理xaka理xasa理vaesva一{dNode6vac<va緒{dNode6vac0wad3ypXeRxawb一緒xaka緒xasa緒vaetva覧{dNode6vac0wad3yp[krxawb一覧xaka覧xasa覧vaetva台{dNode6vac0wad1ypixawb一台xaka台xasa台vaetva応{dNode6vac1va現{dNode6vac0wad1ypaxawd一応現在xaka現xasb現在vaetwad4yp}t~Fxawb一応xaka応xasa応vaetva旦{dNode6vac0wad1ypmxawd一旦休憩xaka旦xasc旦休憩vaetva年{dNode6vac0wad2ypHQxawb一年xaka年xasa年vaetva番{dNode6vac1va忙{dNode6vac0wad1ypSxawc一番忙xaka忙xasa忙vaetwad1ypRxawb一番xaka番xasa番vaetvaつ{dNode6vac0wad1ypcxawb一つxakaつxasaつvaetva人{dNode6vac0wad1ypfxawb一人xaka人xasa人vaetva家{dNode6vac0wad1yp]xawd一家全滅xaka家xasc家全滅vaetva箇{dNode6vac0wad1ypjxawc一箇所xaka箇xasb箇所vaetva週{dNode6vac0wad1yp~xawc一週間xaka週xasb週間vaet>wad1ypBxawa一xaka一xasa一vaetva録{dNode6vac0wad2ypYAxawb録画xaka録xasb録画vaetva気{dNode6vac1vaづ{dNode6vac0wad4ypG|gxawc気づいxakaづxasbづいvaetwad<ypYhqHOHJs}GJ]hy>xawa気xaka気xasa気vaetva良{dNode6vac2vaか{dNode6vac0wad2ypZ[xawc良かっxakaかxasbかっvaetvaい{dNode6vac1vaか{dNode6vac0wad1ypVxawc良いかxakaかxasaかvaetwad5ypZUiVxawb良いxakaいxasaいvaetwad0xawa良xaka良xasa良vaesva思{dNode6vac3vaい{dNode6vac2vaま{dNode6vac0wad7ypZ_nCDPkxawd思いますxakaまxasbますvaetvaつ{dNode6vac0wad1ypgxawd思いついxakaつxasbついvaetwad7yplrIsVfgxawb思いxakaいxasaいvaetvaっ{dNode6vac0wad;yppSahD\ORSiRxawb思っxakaっxasaっvaetvaう{dNode6vac0wad1yp_xawb思うxakaうxasaうvaetwad1ypTxawa思xaka思xasa思vaetvaネ{dNode6vac0wad2ypZxxawbネタxakaネxasbネタvaetvaス{dNode6vac<vaキ{dNode6vac2vaー{dNode6vac0wad2yp[Cxawdスキーマxakaーxasbーマvaetvaル{dNode6vac0wad1yp\xawfスキルアップxakaルxasdルアップvaetwad0xawbスキxakaキxasaキvaesvaラ{dNode6vac0wad5ypbbkkkxawdスライドxakaラxascライドvaetvaイ{dNode6vac0wad1ypixawdスイッチxakaイxascイッチvaetvaピ{dNode6vac2vaー{dNode6vac0wad;ypxMNPT_imwGLxaweスピーカーxakaーxascーカーvaetvaリ{dNode6vac0wad1ypZxawgスピリチュアルxakaリxaseリチュアルvaetwad0xawbスピxakaピxasaピvaesvaポ{dNode6vac0wad1yp{xaweスポンサーxakaポxasdポンサーvaetvaタ{dNode6vac2vaッ{dNode6vac0wad;ypMNPT_imwGLYxawdスタッフxakaッxasbッフvaetvaー{dNode6vac0wad1ypQxawdスタートxakaーxasbートvaetwad0xawbスタxakaタxasaタvaesvaケ{dNode6vac1vaア{dNode6vac0wad1ypkxawgスケールアップxakaアxascアップvaetwad1ypJxawdスケールxakaケxascケールvaetvaペ{dNode6vac0wad1ypjxawhスペシャルゲストxakaペxasgペシャルゲストvaetvaテ{dNode6vac2vaキ{dNode6vac0wad1ypxxawcステキxakaキxasaキvaetvaッ{dNode6vac0wad1ypsxaweステッカーxakaッxascッカーvaetwad0xawbステxakaテxasaテvaesvaリ{dNode6vac0wad2ypDDxawdスリープxakaリxascリープvaetvaマ{dNode6vac0wad1ypaxawcスマホxakaマxasbマホvaetvaー{dNode6vac0wad1ypAxawmスーパープレゼンテーションxakaーxaslーパープレゼンテーションvaet>wad1ypcxawaスxakaスxasaスvaetvaポ{dNode6vac3vaー{dNode6vac0wad1yp[xawdポータルxakaーxascータルvaetvaス{dNode6vac0wad1ypOxawcポストxakaスxasbストvaetvaモ{dNode6vac1vaテ{dNode6vac0wad2ypYYxawjポモドーロテクニックxakaテxaseテクニックvaetwad1ypYxaweポモドーロxakaモxasdモドーロvaetwad0xawaポxakaポxasaポvaesvaフ{dNode6vac3vaィ{dNode6vac0wad1yp[xaweフィールドxakaィxasdィールドvaetvaリ{dNode6vac0wad1ypzxawfフリーランスxakaリxaseリーランスvaetvaァ{dNode6vac1vaイ{dNode6vac0wad7ypFEv@@@xawdファイルxakaイxasbイルvaetwad1ypNxawbファxakaァxasaァvaetwad0xawaフxakaフxasaフvaesva実{dNode6vac4va際{dNode6vac0wad4yp[`Blxawb実際xaka際xasa際vaetva装{dNode6vac0wad2ypg~xawb実装xaka装xasa装vaetva践{dNode6vac0wad7ypXXXZ``Xxawb実践xaka践xasa践vaetva例{dNode6vac0wad1ypXxawb実例xaka例xasa例vaetwad1yp|xawa実xaka実xasa実vaetva投{dNode6vac0wad4yp\\m`xawb投稿xaka投xasb投稿vaetva引{dNode6vac2vaき{dNode6vac0wad6yp\rYPcxawb引きxakaきxasaきvaetvaっ{dNode6vac0wad1ypixawb引っxakaっxasaっvaetwad0xawa引xaka引xasa引vaesva:{dNode6vac1va/{dNode6vac0wad3ypox[xawb:/xaka/xasa/vaetwad<yp]rHooooookrZ[tu[[[[\\>xawa:xaka:xasa:vaetvao{dNode6vac5van{dNode6vac0wad1yp]xawbonxakanxasanvaetvar{dNode6vac2vad{dNode6vac0wad1ypdxawforderbxakadxasdderbvaetvag{dNode6vac0wad2ypN[xawcorgxakagxasagvaetwad1ypFxawborxakarxasarvaetvas{dNode6vac0wad1yprxaweosukaxakasxasdsukavaetvaf{dNode6vac0wad1ypUxawbofxakafxasafvaetvau{dNode6vac0wad1ypexawcourxakauxasburvaetwad0xawaoxakaoxasaovaesva共{dNode6vac3va同{dNode6vac0wad1yp^xawb共同xaka同xasa同vaetva通{dNode6vac0wad1ypGxawb共通xaka通xasa通vaetva著{dNode6vac0wad1ypOxawc共著者xaka著xasb著者vaetwad0xawa共xaka共xasa共vaesvaカ{dNode6vac6vaン{dNode6vac0wad3yp_{oxawgカンファレンスxakaンxasfンファレンスvaetvaタ{dNode6vac0wad1ypkxawcカタンxakaタxasbタンvaetvaス{dNode6vac0wad2ypKLxawdカスタムxakaスxascスタムvaetvaジ{dNode6vac0wad1ypWxawjカジュアルウォーターxakaジxasiジュアルウォーターvaetvaフ{dNode6vac0wad1ypjxawcカフェxakaフxasbフェvaetvaバ{dNode6vac0wad1ypexawcカバーxakaバxasbバーvaetwad0xawaカxakaカxasaカvaesvaセ{dNode6vac5vaマ{dNode6vac0wad1yp`xawgセマンティックxakaマxasfマンティックvaetvaパ{dNode6vac0wad2ypnqxawhセパレートタイプxakaパxasgパレートタイプvaetvaッ{dNode6vac2vaト{dNode6vac0wad6yp}hke}Bxawfセットアップxakaトxasdトアップvaetvaシ{dNode6vac1vaン{dNode6vac1vaオ{dNode6vac0wad1ypdxawiセッションオーナーxakaオxasdオーナーvaetwad6ypC{oFdexaweセッションxakaンxasaンvaetwad1ypyxawdセッショxakaシxasbショvaetwad0xawbセッxakaッxasaッvaesvaミ{dNode6vac0wad1yplxawdセミナーxakaミxascミナーvaetvaル{dNode6vac0wad3ypqy{xawgセルフスタディxakaルxasfルフスタディvaetwad0xawaセxakaセxasaセvaesva発{dNode6vac3va表{dNode6vac1va者{dNode6vac0wad1yp_xawc発表者xaka者xasa者vaetwad2yp`vxawb発表xaka表xasa表vaetva売{dNode6vac0wad4ypaVhuxawb発売xaka売xasa売vaetva生{dNode6vac0wad1ypwxawb発生xaka生xasa生vaetwad1ypdxawa発xaka発xasa発vaetvav{dNode6vac2va2{dNode6vac0wad2ypanxawbv2xaka2xasa2vaetvaa{dNode6vac0wad1ypIxawhvalidatexakaaxasgalidatevaetwad1yphxawavxakavxasavvaetva長{dNode6vac4vaら{dNode6vac0wad1ypaxawc長らくxakaらxasbらくvaetvaさ{dNode6vac0wad1ypoxawb長さxakaさxasaさvaetvaい{dNode6vac0wad2ypHtxawb長いxakaいxasaいvaetvaか{dNode6vac0wad1ypRxawc長かっxakaかxasbかっvaetwad0xawa長xaka長xasa長vaesvaK{dNode6vac7vao{dNode6vac0wad2ypahxaweKochixakaoxasdochivaetvae{dNode6vac2vab{dNode6vac0wad3ypahhxawhKeyboardxakabxaseboardvaetvan{dNode6vac0wad1ypbxawgKeynotexakanxasdnotevaetwad0xawcKeyxakaexasbeyvaesvaV{dNode6vac0wad1ypixawcKVMxakaVxasbVMvaetvau{dNode6vac0wad8ypr~QQY@`IxawhKuromojixakauxasguromojivaetvaJ{dNode6vac0wad1yp[xawbKJxakaJxasaJvaetvai{dNode6vac2vab{dNode6vac0wad9yp@XXXtFLLOxawfKibanaxakabxasdbanavaetvan{dNode6vac0wad1ypfxawfKindlexakanxasdndlevaetwad0xawbKixakaixasaivaesvaa{dNode6vac2vag{dNode6vac0wad1ypfxawfKagomexakagxasdgomevaetvau{dNode6vac0wad1yp\xawgKaushikxakauxaseushikvaetwad0xawbKaxakaaxasaavaeswad1ypAxawaKxakaKxasaKvaetva作{dNode6vac4va成{dNode6vac0wad6ypbnz@CGxawb作成xaka成xasa成vaetva業{dNode6vac0wad2ypptxawb作業xaka業xasa業vaetvaっ{dNode6vac0wad6ypUU`AKOxawb作っxakaっxasaっvaetva者{dNode6vac0wad1ypqxawb作者xaka者xasa者vaetwad1ypbxawa作xaka作xasa作vaetva何{dNode6vac4va種{dNode6vac0wad1yp_xawc何種類xaka種xasb種類vaetva番{dNode6vac0wad1ypOxawc何番煎xaka番xasb番煎vaetva度{dNode6vac0wad1ypYxawb何度xaka度xasa度vaetvaか{dNode6vac0wad1yptxawb何かxakaかxasaかvaetwad2ypbLxawa何xaka何xasa何vaetvaG{dNode6vac5vao{dNode6vac0wad1ypbxawfGooglexakaoxaseooglevaetvar{dNode6vac2vaa{dNode6vac3vaa{dNode6vac0wad1ypQxawgGraalVMxakaaxasdalVMvaetvap{dNode6vac0wad1ypWxawhGraphitexakapxasephitevaetvan{dNode6vac0wad1ypnxaweGrantxakanxasbntvaetwad0xawcGraxakaaxasaavaesvae{dNode6vac0wad1ypcxaweGreatxakaexasceatvaetwad0xawbGrxakarxasarvaesvai{dNode6vac2vaH{dNode6vac0wad1ypixawfGitHubxakaHxascHubvaetvah{dNode6vac0wad2ypW{xawfGithubxakahxaschubvaetwad0xawcGitxakaixasbitvaesvaA{dNode6vac0wad2ypVWxawbGAxakaAxasaAvaetvaO{dNode6vac0wad1ypexawdGOTOxakaOxascOTOvaetwad1ypQxawaGxakaGxasaGvaetva影{dNode6vac0wad2ypctxawb影響xaka影xasb影響vaetva集{dNode6vac2vaま{dNode6vac0wad1ypcxawc集まっxakaまxasbまっvaetvaめ{dNode6vac0wad1ypjxawb集めxakaめxasaめvaetwad0xawa集xaka集xasa集vaesva勉{dNode6vac2va会{dNode6vac3vaメ{dNode6vac0wad1ypgxawe勉強会メモxakaメxasbメモvaetva開{dNode6vac0wad1ypBxawe勉強会開催xaka開xasb開催vaetvaロ{dNode6vac0wad1ypXxawe勉強会ログxakaロxasbログvaetwad<ypclrssbbovZeelvv}CEF_hkPVV[^acizE>xawc勉強会xaka会xasa会vaetva中{dNode6vac0wad1ypsxawc勉強中xaka中xasa中vaetwad3yp^j\xawb勉強xaka勉xasb勉強vaetva以{dNode6vac5va上{dNode6vac2va開{dNode6vac0wad1ypcxawd以上開催xaka開xasb開催vaetva前{dNode6vac0wad1ypMxawc以上前xaka前xasa前vaetwad2ypD[xawb以上xaka上xasa上vaetva降{dNode6vac0wad2yp~Wxawb以降xaka降xasa降vaetva前{dNode6vac0wad7ypFwsIeEJxawb以前xaka前xasa前vaetva外{dNode6vac0wad5ypbov`hxawb以外xaka外xasa外vaetva下{dNode6vac0wad6yp{HIxHOxawb以下xaka下xasa下vaetwad0xawa以xaka以xasa以vaesvaO{dNode6vac5vaD{dNode6vac0wad2ypddxaweODataxakaDxasdDatavaetvac{dNode6vac0wad2ypfWxawiOctopressxakacxashctopressvaetvaS{dNode6vac1vaS{dNode6vac0wad1ypkxawcOSSxakaSxasaSvaetwad1ypjxawbOSxakaSxasaSvaetvaN{dNode6vac0wad1ypqxawbONxakaNxasaNvaetvap{dNode6vac0wad1ypaxawiOperationxakapxashperationvaetwad0xawaOxakaOxasaOvaesva式{dNode6vac0wad1ypdxawa式xaka式xasa式vaetva条{dNode6vac0wad2ypddxawb条件xaka条xasb条件vaetva${dNode6vac0wad2ypddxawa$xaka$xasa$vaetvaソ{dNode6vac3vaー{dNode6vac2vaト{dNode6vac0wad1ypdxawcソートxakaトxasaトvaetvaス{dNode6vac2va眺{dNode6vac0wad1ypQxaweソース眺めxaka眺xasb眺めvaetvaコ{dNode6vac0wad1ypgxawlソースコードリーディングxakaコxasiコードリーディングvaetwad5ypEFPPPxawcソースxakaスxasaスvaetwad1yp{xawbソーxakaーxasaーvaetvaフ{dNode6vac0wad2yporxawcソフトxakaフxasbフトvaetvaニ{dNode6vac0wad1yp[xawcソニーxakaニxasbニーvaetwad0xawaソxakaソxasaソvaesva自{dNode6vac8va宅{dNode6vac1va環{dNode6vac0wad1yptxawd自宅環境xaka環xasb環境vaetwad3ypeptxawb自宅xaka宅xasa宅vaetva作{dNode6vac0wad3ypjpqxawb自作xaka作xasa作vaetva分{dNode6vac1va用{dNode6vac0wad;yp{@AEMPRTlgzxawc自分用xaka用xasa用vaetwad6ypuSiH\Rxawb自分xaka分xasa分vaetva体{dNode6vac0wad1yp~xawb自体xaka体xasa体vaetva然{dNode6vac1va特{dNode6vac0wad1ypxawh自然言語処理特集xaka特xasb特集vaetwad3ypOOFxawf自然言語処理xaka然xase然言語処理vaetva転{dNode6vac0wad1ypVxawd自転車本xaka転xasc転車本vaetva己{dNode6vac1va紹{dNode6vac0wad1yp\xawd自己紹介xaka紹xasb紹介vaetwad1ypHxawb自己xaka己xasa己vaetva信{dNode6vac0wad1ypoxawb自信xaka信xasa信vaetwad0xawa自xaka自xasa自vaesva更{dNode6vac1va版{dNode6vac0wad4ypetFFxawc更新版xaka版xasa版vaetwad6ypKfcRuDxawb更新xaka更xasb更新vaetva({dNode6vac1va){dNode6vac0wad1yp}xawb()xaka)xasa)vaetwad<ypeejlmprCCDHSUW\\\\\`bbbbbcccccdddddeeeenuvDIQ{AMnqeuuE[I>xawa(xaka(xasa(vaetva){dNode6vac0wad<ypeejlmprCDHSU\\\\`bbbbccccdddddeeeenuvDIQ{AMnqeuuE[>xawa)xaka)xasa)vaetva挙{dNode6vac0wad1ypfxawb挙動xaka挙xasb挙動vaetvaロ{dNode6vac2vaグ{dNode6vac0wad3ypfMjxawbログxakaグxasaグvaetvaー{dNode6vac0wad1yp\xawdローカルxakaーxascーカルvaetwad1ypOxawaロxakaロxasaロvaetva原{dNode6vac3va著{dNode6vac0wad1ypgxawb原著xaka著xasa著vaetva文{dNode6vac0wad<ypUVWXYZZ[\]^`acdhjklnprtuxy}~ABDHKNQ>xawb原文xaka文xasa文vaetva本{dNode6vac0wad1yplxawb原本xaka本xasa本vaetwad0xawa原xaka原xasa原vaesvaじ{dNode6vac2vaめ{dNode6vac2vaま{dNode6vac1vaて{dNode6vac0wad1ypmxaweじめましてxakaてxasaてvaetwad3ypGXZxawdじめましxakaまxasbましvaetvaる{dNode6vac0wad2yp^Uxawcじめるxakaるxasaるvaetwad0xawbじめxakaめxasaめvaesvaま{dNode6vac0wad1ypuxaweじまりましxakaまxasdまりましvaetwad5ypgKWLOxawaじxakaじxasaじvaetvaゃ{dNode6vac0wad2ypgWxawaゃxakaゃxasaゃvaetva数{dNode6vac4va字{dNode6vac0wad1yphxawb数字xaka字xasa字vaetva回{dNode6vac0wad1ypxxawb数回xaka回xasa回vaetva年{dNode6vac0wad1yp{xawb数年xaka年xasa年vaetva日{dNode6vac0wad1yptxawc数日前xaka日xasb日前vaetwad0xawa数xaka数xasa数vaesva下{dNode6vac2va記{dNode6vac0wad1ypixawb下記xaka記xasa記vaetva部{dNode6vac0wad1ypuxawb下部xaka部xasa部vaetwad0xawa下xaka下xasa下vaesvaサ{dNode6vac6vaン{dNode6vac3vaワ{dNode6vac0wad1ypixawgサンワサプライxakaワxaseワサプライvaetvaフ{dNode6vac0wad1ypqxawhサンフランシスコxakaフxasfフランシスコvaetvaプ{dNode6vac0wad2yp\Gxawdサンプルxakaプxasbプルvaetwad0xawbサンxakaンxasaンvaesvaイ{dNode6vac2vaト{dNode6vac0wad7ypoEEuxBHxawcサイトxakaトxasaトvaetvaン{dNode6vac0wad1ypaxawcサインxakaンxasaンvaetwad0xawbサイxakaイxasaイvaesvaボ{dNode6vac0wad1ypAxawbサボxakaボxasaボvaetvaー{dNode6vac2vaビ{dNode6vac0wad5ypEJJllxawdサービスxakaビxasbビスvaetvaバ{dNode6vac0wad1ypMxawcサーバxakaバxasaバvaetwad0xawbサーxakaーxasaーvaesvaポ{dNode6vac0wad1ypXxawdサポートxakaポxascポートvaetvaム{dNode6vac0wad2yp@Txawfサムライズムxakaムxaseムライズムvaetwad1ypjxawaサxakaサxasaサvaetva接{dNode6vac0wad2ypiixawb接続xaka接xasb接続vaetvaノ{dNode6vac2vaー{dNode6vac0wad1ypixawcノートxakaーxasbートvaetvaッ{dNode6vac0wad:ypvwFGHNO|}~xawcノックxakaッxasbックvaetwad0xawaノxakaノxasaノvaesvaデ{dNode6vac4vaス{dNode6vac0wad2ypjCxawfデスクトップxakaスxaseスクトップvaetvaィ{dNode6vac0wad1ypzxawfディレクトリxakaィxaseィレクトリvaetvaー{dNode6vac1vaア{dNode6vac0wad1yp^xawfデータアップxakaアxascアップvaetwad6ypz@BUDMxawcデータxakaーxasbータvaetvaモ{dNode6vac0wad2ypF\xawbデモxakaモxasaモvaetwad0xawaデxakaデxasaデvaesva立{dNode6vac4vaて{dNode6vac0wad2ypjtxawb立てxakaてxasaてvaetvaち{dNode6vac0wad1ypjxawb立ちxakaちxasaちvaetvaっ{dNode6vac0wad1ypjxawb立っxakaっxasaっvaetvaつ{dNode6vac0wad1ypYxawb立つxakaつxasaつvaetwad0xawa立xaka立xasa立vaesva貼{dNode6vac1vaっ{dNode6vac0wad1ypjxawb貼っxakaっxasaっvaetwad1ypSxawa貼xaka貼xasa貼vaetva航{dNode6vac0wad1ypkxawb航海xaka航xasb航海vaetva者{dNode6vac0wad1ypkxawb者版xaka者xasb者版vaetva購{dNode6vac0wad6ypk_ubpUxawb購入xaka購xasb購入vaetva家{dNode6vac1va族{dNode6vac0wad4ypk___xawb家族xaka族xasa族vaetwad2yp]Cxawa家xaka家xasa家vaetva負{dNode6vac2vaけ{dNode6vac0wad1ypkxawb負けxakaけxasaけvaetva荷{dNode6vac0wad1ypxxawb負荷xaka荷xasa荷vaetwad0xawa負xaka負xasa負vaesvas{dNode6vac8vat{dNode6vac2vaa{dNode6vac0wad7yplnuvDIJxawestackxakaaxascackvaetvar{dNode6vac0wad1ypHxawcstrxakarxasarvaetwad0xawbstxakatxasatvaesvap{dNode6vac0wad1yp}xawesplitxakapxasdplitvaetvao{dNode6vac0wad1ypdxawdsoonxakaoxascoonvaetvam{dNode6vac0wad1ypoxawgsmogamixakamxasfmogamivaetvae{dNode6vac3vac{dNode6vac0wad1yprxawhsecurityxakacxasfcurityvaetvar{dNode6vac0wad1ypVxawfserverxakarxasdrvervaetvaa{dNode6vac0wad1yp`xawfsearchxakaaxasdarchvaetwad0xawbsexakaexasaevaesvah{dNode6vac0wad1yprxawfshieldxakahxasehieldvaetvac{dNode6vac2var{dNode6vac2vas{dNode6vac0wad1ypxxawgscriptsxakasxasasvaetvai{dNode6vac0wad1ypxxawiscriptingxakaixascingvaetwad0xawfscriptxakarxasdriptvaesvah{dNode6vac0wad2yp|Gxawfschemaxakahxasdhemavaetwad0xawbscxakacxasacvaesvai{dNode6vac0wad1ypxawdsizexakaixascizevaetwad0xawasxakasxasasvaesva足{dNode6vac1vaり{dNode6vac0wad1yplxawb足りxakaりxasaりvaetwad1yp`xawa足xaka足xasa足vaetva大{dNode6vac<va谷{dNode6vac0wad1ypmxawb大谷xaka谷xasa谷vaetva体{dNode6vac0wad1ypsxawb大体xaka体xasa体vaetva事{dNode6vac0wad1ypTxawb大事xaka事xasa事vaetva好{dNode6vac0wad1yp|xawb大好xaka好xasa好vaetvaき{dNode6vac0wad3ypZcMxawb大きxakaきxasaきvaetva阪{dNode6vac0wad1ypbxawb大阪xaka阪xasa阪vaetvaさ{dNode6vac0wad1ypzxawc大さんxakaさxasbさんvaetva晦{dNode6vac0wad3yp{qgxawc大晦日xaka晦xasb晦日vaetva講{dNode6vac0wad1ypMxawb大講xaka講xasa講vaetva満{dNode6vac0wad1ypjxawc大満足xaka満xasb満足vaetva入{dNode6vac0wad1ypFxawc大入りxaka入xasb入りvaetva画{dNode6vac0wad1ypVxawc大画面xaka画xasb画面vaetva量{dNode6vac0wad1ypfxawb大量xaka量xasa量vaet>wad1ypyxawa大xaka大xasa大vaetvaビ{dNode6vac3vaル{dNode6vac1vaロ{dNode6vac0wad1ypnxaweビルドログxakaロxasbログvaetwad2ypPPxawcビルドxakaルxasbルドvaetvaー{dNode6vac0wad1ypUxawcビールxakaーxasbールvaetvaッ{dNode6vac0wad1yplxawfビッグデータxakaッxaseッグデータvaetwad0xawaビxakaビxasaビvaesvaヒ{dNode6vac4vaゲ{dNode6vac0wad2ypopxawbヒゲxakaゲxasaゲvaetvaッ{dNode6vac0wad1ypsxawcヒットxakaッxasbットvaetvaカ{dNode6vac0wad1ypjxawdヒカリエxakaカxascカリエvaetvaル{dNode6vac0wad1yp[xawcヒルズxakaルxasbルズvaetwad0xawaヒxakaヒxasaヒvaesva不{dNode6vac4va評{dNode6vac0wad2ypopxawb不評xaka評xasa評vaetva安{dNode6vac0wad1ypaxawb不安xaka安xasa安vaetva定{dNode6vac1va開{dNode6vac0wad2yp}Fxawe不定期開催xaka開xasb開催vaetwad1ypkxawc不定期xaka定xasb定期vaetva純{dNode6vac0wad1ypjxawb不純xaka純xasa純vaetwad0xawa不xaka不xasa不vaesva通{dNode6vac3vaり{dNode6vac0wad1ypoxawb通りxakaりxasaりvaetva訳{dNode6vac0wad1ypjxawb通訳xaka訳xasa訳vaetva勤{dNode6vac0wad1ypwxawb通勤xaka勤xasa勤vaetwad0xawa通xaka通xasa通vaesva切{dNode6vac1vaま{dNode6vac0wad1ypoxawd切りましxakaまxasbましvaetwad1ypqxawb切りxaka切xasb切りvaetva中{dNode6vac3va身{dNode6vac0wad1ypYxawb中身xaka身xasa身vaetva野{dNode6vac0wad1ypXxawb中野xaka野xasa野vaetva心{dNode6vac0wad2yp_Ixawb中心xaka心xasa心vaetwad4ypoydwxawa中xaka中xasa中vaetva伸{dNode6vac2vaび{dNode6vac0wad1yppxawb伸びxakaびxasaびvaetvaば{dNode6vac0wad1yppxawe伸ばしてるxakaばxasdばしてるvaetwad0xawa伸xaka伸xasa伸vaesva買{dNode6vac3vaっ{dNode6vac0wad6ypp[`OOQxawb買っxakaっxasaっvaetva収{dNode6vac0wad1ypExawb買収xaka収xasa収vaetvaお{dNode6vac0wad1ypCxawc買おうxakaおxasbおうvaetwad0xawa買xaka買xasa買vaesvaご{dNode6vac5vaろ{dNode6vac0wad2ypp]xawbごろxakaろxasaろvaetvaめ{dNode6vac0wad1ypGxawcごめんxakaめxasbめんvaetvaく{dNode6vac0wad2yp@xawbごくxakaくxasaくvaetvaざ{dNode6vac0wad1ypfxaweございますxakaざxasdざいますvaetvaか{dNode6vac0wad1ypwxawcごかっxakaかxasbかっvaetwad3ypZJgxawaごxakaごxasaごvaetva多{dNode6vac0wad1yppxawb多くxaka多xasb多くvaetva春{dNode6vac2vaく{dNode6vac0wad1ypqxawd春くらいxakaくxascくらいvaetva山{dNode6vac0wad1ypExawb春山xaka山xasa山vaetwad0xawa春xaka春xasa春vaesva@{dNode6vac0wad<yprSfgo\PRR~LLVa>xawa@xaka@xasa@vaetvam{dNode6vac3vai{dNode6vac2vao{dNode6vac0wad1yprxawfminoruxakaoxascoruvaetvai{dNode6vac0wad1yppxawdminixakaixasaivaetwad0xawcminxakaixasbinvaesvaa{dNode6vac3vat{dNode6vac0wad1ypPxawdmatcxakatxasbtcvaetvac{dNode6vac0wad1yphxawemacOSxakacxasccOSvaetvar{dNode6vac0wad1yp}xawfmarvelxakarxasdrvelvaetwad0xawbmaxakaaxasaavaesvae{dNode6vac2vae{dNode6vac0wad2ypoYxawfmeetupxakaexasdetupvaetvac{dNode6vac0wad1ypKxawemecabxakacxasccabvaetwad1yp\xawbmexakaexasaevaetwad0xawamxakamxasamvaesva_{dNode6vac0wad8yprj}Pyyyxawa_xaka_xasa_vaetva継{dNode6vac2vaい{dNode6vac0wad2yprYxawb継いxakaいxasaいvaetva続{dNode6vac1va中{dNode6vac0wad1ypcxawc継続中xaka中xasa中vaetwad2yptQxawb継続xaka続xasa続vaetwad0xawa継xaka継xasa継vaesvaR{dNode6vac7vau{dNode6vac2vas{dNode6vac1va製{dNode6vac0wad2ypYYxaweRust製xaka製xasa製vaetwad<ypruuvw{{{{{@@@@@AAAAAEEEEEFGHMMMMNPPPRRTVVXXYZ``|}>xawdRustxakasxasbstvaetvab{dNode6vac1va2{dNode6vac0wad1yp{xawgRuby2日目xaka2xasc2日目vaetwad1ypyxawdRubyxakabxasbbyvaetwad0xawbRuxakauxasauvaesvaE{dNode6vac2vaA{dNode6vac0wad1yp}xawdREADxakaAxasbADvaetvaS{dNode6vac0wad1ypbxawdRESTxakaSxasbSTvaetwad0xawbRExakaExasaEvaesvai{dNode6vac2vao{dNode6vac0wad1ypHxawcRioxakaoxasaovaetvaa{dNode6vac0wad4ypzzIMxawdRiakxakaaxasbakvaetwad0xawbRixakaixasaivaesvae{dNode6vac6val{dNode6vac2vae{dNode6vac0wad5ypVlnpQxawhReleasedxakaexaseeasedvaetvaa{dNode6vac0wad1ypZxawfRelasexakaaxascasevaetwad0xawcRelxakalxasalvaesvaf{dNode6vac0wad1ypcxawkRefactoringxakafxasifactoringvaetvai{dNode6vac0wad1ypjxawgReindexxakaixaseindexvaetvap{dNode6vac0wad1yptxawjRepositoryxakapxashpositoryvaetvat{dNode6vac0wad2ypuuxawiRetrievalxakatxasgtrievalvaetvaa{dNode6vac0wad1yp{xawfReadmexakaaxasdadmevaetwad0xawbRexakaexasaevaesvaC{dNode6vac0wad2ypN[xawbRCxakaCxasaCvaetvaa{dNode6vac0wad2yp^rxaweRailsxakaaxasdailsvaetvao{dNode6vac2vao{dNode6vac0wad1yp\xawdRoomxakaoxasbomvaetvab{dNode6vac0wad2ypQxawfRobertxakabxasdbertvaetwad0xawbRoxakaoxasaovaeswad0xawaRxakaRxasaRvaesva先{dNode6vac2va日{dNode6vac0wad<ypsyKUMdIfGHLM^xEG>xawb先日xaka日xasa日vaetva週{dNode6vac1va末{dNode6vac0wad1yphxawc先週末xaka末xasa末vaetwad1yp}xawb先週xaka週xasa週vaetwad2ypVlxawa先xaka先xasa先vaetvaシ{dNode6vac3vaス{dNode6vac0wad6ypssyz^Exawdシステムxakaスxascステムvaetvaリ{dNode6vac0wad1ypExawdシリーズxakaリxascリーズvaetvaア{dNode6vac0wad1yp\xawdシアターxakaアxascアターvaetwad0xawaシxakaシxasaシvaesva構{dNode6vac2va成{dNode6vac0wad5ypssIzSxawb構成xaka成xasa成vaetva造{dNode6vac1va体{dNode6vac0wad1ypRxawc構造体xaka体xasa体vaetwad1ypDxawb構造xaka造xasa造vaetwad0xawa構xaka構xasa構vaesva客{dNode6vac0wad5yptCW]{xawc客さんxaka客xasc客さんvaetva相{dNode6vac0wad1yptxawb相変xaka相xasb相変vaetvaわ{dNode6vac3vaら{dNode6vac0wad1yptxawcわらずxakaらxasbらずvaetvaけ{dNode6vac0wad1ypHxawdわけじゃxakaけxascけじゃvaetvaり{dNode6vac0wad1ypRxawbわりxakaりxasaりvaetwad0xawaわxakaわxasaわvaesvaせ{dNode6vac2vaっ{dNode6vac0wad4yp{C`|xawdせっかくxakaっxascっかくvaetvaる{dNode6vac0wad1ypHxawbせるxakaるxasaるvaetwad2yptAxawaせxakaせxasaせvaetva便{dNode6vac0wad3ypu[Kxawb便利xaka便xasb便利vaetva問{dNode6vac0wad7ypu~~|}Lxawb問題xaka問xasb問題vaetva処{dNode6vac0wad:ypuvwFFGHN|}xawb処理xaka処xasb処理vaetva言{dNode6vac4va語{dNode6vac2va処{dNode6vac1va勉{dNode6vac0wad1ypDxawg言語処理勉強会xaka勉xasc勉強会vaetwad2ypO~xawd言語処理xaka処xasb処理vaetva仕{dNode6vac0wad1yp`xawc言語仕xaka仕xasa仕vaetwad:ypvwFGHN|}q|xawb言語xaka語xasa語vaetvaっ{dNode6vac0wad1ypTxawb言っxakaっxasaっvaetvaい{dNode6vac1vaつ{dNode6vac0wad1ypnxawd言いつつxakaつxasbつつvaetwad2ypsMxawb言いxakaいxasaいvaetva葉{dNode6vac0wad1yphxawb言葉xaka葉xasa葉vaetwad0xawa言xaka言xasa言vaesva第{dNode6vac:va1{dNode6vac6va0{dNode6vac0wad1ypixawd第10回xaka0xasb0回vaetva1{dNode6vac0wad1yp_xawd第11回xaka1xasb1回vaetva3{dNode6vac0wad2ypTlxawd第13回xaka3xasb3回vaetva5{dNode6vac0wad1ypNxawd第15回xaka5xasb5回vaetva6{dNode6vac0wad1ypMxawd第16回xaka6xasb6回vaetva回{dNode6vac0wad1yp@xawc第1回xaka回xasa回vaetwad0xawb第1xaka1xasa1vaesva2{dNode6vac1va目{dNode6vac0wad1yp\xawd第2回目xaka目xasa目vaetwad2ypzxxawc第2回xaka2xasb2回vaetva3{dNode6vac0wad1yphxawc第3回xaka3xasb3回vaetva4{dNode6vac0wad1yp_xawc第4回xaka4xasb4回vaetva5{dNode6vac0wad1ypSxawc第5回xaka5xasb5回vaetva6{dNode6vac0wad1ypLxawc第6回xaka6xasb6回vaetva7{dNode6vac0wad1ypGxawc第7回xaka7xasb7回vaetva8{dNode6vac0wad1ypwxawc第8回xaka8xasb8回vaetva9{dNode6vac0wad2ypmkxawc第9回xaka9xasb9回vaetva一{dNode6vac2va回{dNode6vac0wad1ypixawc第一回xaka回xasa回vaetva弾{dNode6vac0wad1ypwxawc第一弾xaka弾xasa弾vaetwad0xawb第一xaka一xasa一vaeswad<ypvvw{{{{@@@@AAAAEEEEFGMMMMPPPRRTTss~@APb{F}AF_ggzzDI>xawa第xaka第xasa第vaetva早{dNode6vac2vaめ{dNode6vac0wad1ypvxawb早めxakaめxasaめvaetvaい{dNode6vac0wad3ypQSCxawb早いxakaいxasaいvaetwad0xawa早xaka早xasa早vaesva形{dNode6vac2va態{dNode6vac1va解{dNode6vac1va器{dNode6vac0wad2ypfxawf形態素解析器xaka器xasa器vaetwad2ypvfxawe形態素解析xaka解xasb解析vaetwad1ypMxawc形態素xaka態xasb態素vaetvaに{dNode6vac0wad1ypwxawb形にxakaにxasaにvaetwad1yp]xawa形xaka形xasa形vaetva吾{dNode6vac0wad1ypvxawb吾輩xaka吾xasb吾輩vaetva猫{dNode6vac0wad1ypvxawa猫xaka猫xasa猫vaetva計{dNode6vac0wad1ypxxawb計測xaka計xasb計測vaetva起{dNode6vac3va動{dNode6vac0wad2ypxkxawb起動xaka動xasa動vaetva因{dNode6vac0wad1ypexawb起因xaka因xasa因vaetvaこ{dNode6vac0wad1ypFxawc起こしxakaこxasbこしvaetwad1yp\xawa起xaka起xasa起vaetva停{dNode6vac0wad1ypxxawb停止xaka停xasb停止vaetva楽{dNode6vac1vaし{dNode6vac4vaみ{dNode6vac0wad1yp_xawe楽しみましxakaみxascみましvaetvaく{dNode6vac0wad1yptxawc楽しくxakaくxasaくvaetvaか{dNode6vac0wad1ypPxawc楽しかxakaかxasaかvaetvaめ{dNode6vac0wad1ypUxawd楽しめるxakaめxasbめるvaetwad1ypaxawb楽しxakaしxasaしvaetwad1ypxxawa楽xaka楽xasa楽vaetva特{dNode6vac3va徴{dNode6vac0wad1ypyxawb特徴xaka徴xasa徴vaetva定{dNode6vac1va文{dNode6vac0wad1ypbxawe特定文字列xaka文xasc文字列vaetwad1yppxawb特定xaka定xasa定vaetva性{dNode6vac0wad1ypOxawb特性xaka性xasa性vaetwad0xawa特xaka特xasa特vaesvaふ{dNode6vac1vaん{dNode6vac0wad1ypyxawdふんわりxakaんxascんわりvaetwad1ypAxawaふxakaふxasaふvaetva頭{dNode6vac1va痛{dNode6vac0wad1ypUxawb頭痛xaka痛xasa痛vaetwad4ypyz{xawa頭xaka頭xasa頭vaetvaぼ{dNode6vac0wad1ypyxawdぼんやりxakaぼxasdぼんやりvaetva考{dNode6vac2vaえ{dNode6vac0wad3ypyvpxawb考えxakaえxasaえvaetva慮{dNode6vac0wad1ypExawc考慮点xaka慮xasb慮点vaetwad1ypUxawa考xaka考xasa考vaetva文{dNode6vac3va章{dNode6vac0wad4ypyVpuxawb文章xaka章xasa章vaetva字{dNode6vac1va通{dNode6vac0wad1yptxawd文字通りxaka通xasb通りvaetwad1yp|xawb文字xaka字xasa字vaetva体{dNode6vac0wad1ypBxawb文体xaka体xasa体vaetwad0xawa文xaka文xasa文vaesva他{dNode6vac1va愛{dNode6vac0wad1yp@xawb他愛xaka愛xasa愛vaetwad7ypybcdeZ`xawa他xaka他xasa他vaetva手{dNode6vac3va伝{dNode6vac2vaっ{dNode6vac0wad1ypWxawc手伝っxakaっxasaっvaetvaい{dNode6vac0wad1yp]xawc手伝いxakaいxasaいvaetwad3ypz]oxawb手伝xaka伝xasa伝vaetva元{dNode6vac0wad2ypkpxawb手元xaka元xasa元vaetva軽{dNode6vac0wad1ypBxawb手軽xaka軽xasa軽vaetwad0xawa手xaka手xasa手vaesvaば{dNode6vac1vaっ{dNode6vac0wad1ypYxawdばっかりxakaっxascっかりvaetwad8ypzluQZvZtxawaばxakaばxasaばvaetvaほ{dNode6vac7vaど{dNode6vac0wad4ypz}}Dxawbほどxakaどxasaどvaetvaう{dNode6vac0wad2ypNVxawbほうxakaうxasaうvaetvaか{dNode6vac0wad1ypfxawbほかxakaかxasaかvaetvaっ{dNode6vac0wad1ypkxawbほっxakaっxasaっvaetvaし{dNode6vac0wad1ypUxawcほしいxakaしxasbしいvaetvaぼ{dNode6vac0wad1yp_xawbほぼxakaぼxasaぼvaetvaん{dNode6vac0wad1ypsxawbほんxakaんxasaんvaetwad0xawaほxakaほxasaほvaesva面{dNode6vac0wad7ypz\axEQYxawb面白xaka面xasb面白vaetva週{dNode6vac0wad1yp|xawa週xaka週xasa週vaetva?{dNode6vac0wad6yp|}NRVaxawa?xaka?xasa?vaetvaツ{dNode6vac3vaー{dNode6vac0wad3yp}WWxawcツールxakaーxasbールvaetvaイ{dNode6vac1vaト{dNode6vac0wad;ypO^^erO\^horxawdツイートxakaトxasaトvaetwad1yp_xawcツイーxakaイxasbイーvaetvaッ{dNode6vac0wad2yp_yxawdツッコミxakaッxascッコミvaetwad0xawaツxakaツxasaツvaesva誰{dNode6vac0wad1yp}xawb誰得xaka誰xasb誰得vaetva興{dNode6vac1va深{dNode6vac0wad1yptxawc興味深xaka深xasa深vaetwad9yp}nqqZZfluxawb興味xaka興xasb興味vaetva場{dNode6vac2va合{dNode6vac0wad4yp}NPxawb場合xaka合xasa合vaetva所{dNode6vac0wad2ypo\xawb場所xaka所xasa所vaetwad0xawa場xaka場xasa場vaesva飛{dNode6vac0wad1yp}xawb飛ばxaka飛xasb飛ばvaetva直{dNode6vac4vaる{dNode6vac0wad1yp~xawb直るxakaるxasaるvaetvaし{dNode6vac0wad1ypFxawb直しxakaしxasaしvaetva前{dNode6vac0wad1ypPxawb直前xaka前xasa前vaetva接{dNode6vac0wad1ypXxawd直接業務xaka接xasc接業務vaetwad0xawa直xaka直xasa直vaesva扱{dNode6vac0wad2ypLxawb扱うxaka扱xasb扱うvaetva違{dNode6vac0wad2ypOxawb違いxaka違xasb違いvaetva送{dNode6vac2va信{dNode6vac0wad1ypBxawb送信xaka信xasa信vaetvaっ{dNode6vac0wad1ypwxawb送っxakaっxasaっvaetwad0xawa送xaka送xasa送vaesva方{dNode6vac5vaや{dNode6vac0wad1ypCxawb方やxakaやxasaやvaetva法{dNode6vac0wad4ypKK@sxawb方法xaka法xasa法vaetva々{dNode6vac0wad5ypFOvvvxawb方々xaka々xasa々vaetvaも{dNode6vac1vaい{dNode6vac0wad1yp}xawd方もいるxakaいxasbいるvaetwad1ypPxawb方もxakaもxasaもvaetvaな{dNode6vac0wad1ypkxawc方などxakaなxasbなどvaetwad9ypQO}`efqy{xawa方xaka方xasa方vaetva教{dNode6vac0wad2ypCjxawb教えxaka教xasb教えvaetva触{dNode6vac5vaっ{dNode6vac0wad;ypDmBGMq@Cassxawb触っxakaっxasaっvaetva発{dNode6vac0wad1ypxawb触発xaka発xasa発vaetvaれ{dNode6vac0wad2yphixawb触れxakaれxasaれvaetvaる{dNode6vac0wad1ypcxawb触るxakaるxasaるvaetvaろ{dNode6vac0wad1ypixawc触ろうxakaろxasbろうvaetwad0xawa触xaka触xasa触vaesva標{dNode6vac1va入{dNode6vac0wad1ypFxawd標準入力xaka入xasb入力vaetwad1yphxawb標準xaka標xasb標準vaetva受{dNode6vac2vaけ{dNode6vac1vaま{dNode6vac0wad1ypgxawd受けましxakaまxasbましvaetwad4ypFss^xawb受けxakaけxasaけvaetva付{dNode6vac0wad1ypqxawc受付用xaka付xasb付用vaetwad0xawa受xaka受xasa受vaesvaヶ{dNode6vac1va月{dNode6vac2vaサ{dNode6vac0wad1ypGxawdヶ月サボxakaサxasbサボvaetvaも{dNode6vac0wad1yplxawcヶ月もxakaもxasaもvaetwad4ypnvDnxawbヶ月xaka月xasa月vaetwad1ypexawaヶxakaヶxasaヶvaetvaっ{dNode6vac0wad3ypG^Rxawaっxakaっxasaっvaetva暗{dNode6vac0wad1ypHxawc暗号文xaka暗xasc暗号文vaetva&{dNode6vac0wad5ypHoogAxawa&xaka&xasa&vaetvaa{dNode6vac6vam{dNode6vac0wad3ypHooxawcampxakamxasbmpvaetval{dNode6vac0wad1ypuxawcalpxakalxasblpvaetvan{dNode6vac2vad{dNode6vac0wad:ypV`auy~DHuxawcandxakadxasadvaetvaa{dNode6vac2vaz{dNode6vac0wad3ypJ{Lxawganalyzexakazxasbzevaetvas{dNode6vac0wad1yp`xawhanalysisxakasxascsisvaetwad0xaweanalyxakaaxascalyvaeswad0xawbanxakanxasanvaesvat{dNode6vac1van{dNode6vac0wad1yp[xawdatndxakanxasbndvaetwad1ypexawbatxakatxasatvaetvar{dNode6vac0wad1ypbxawcarcxakarxasbrcvaetvau{dNode6vac0wad1yp|xawnautoGeneratePhxakauxasmutoGeneratePhvaetwad1yp^xawaaxakaaxasaavaetva;{dNode6vac0wad5ypHHoogxawa;xaka;xasa;vaetvag{dNode6vac4vat{dNode6vac0wad1ypHxawbgtxakatxasatvaetvar{dNode6vac2vaa{dNode6vac0wad2yp||xawdgramxakaaxasbamvaetvao{dNode6vac0wad1ypxxawfgroovyxakaoxasdoovyvaetwad0xawbgrxakarxasarvaesvao{dNode6vac2vae{dNode6vac2vas{dNode6vac0wad1yprxawdgoesxakasxasasvaetvan{dNode6vac0wad1ypvxawdgoenxakanxasanvaetwad0xawcgoexakaexasaevaesvas{dNode6vac0wad<ypnXy~@DMMNNWW^_bmp@@GKMNO>xawegosenxakasxascsenvaetwad0xawbgoxakaoxasaovaesvaa{dNode6vac0wad1yprxawbgaxakaaxasaavaetwad0xawagxakagxasagvaesva要{dNode6vac2va素{dNode6vac0wad1ypIxawb要素xaka素xasa素vaetva望{dNode6vac0wad1ypLxawb要望xaka望xasa望vaetwad0xawa要xaka要xasa要vaesva説{dNode6vac1va明{dNode6vac0wad3ypIHOxawb説明xaka明xasa明vaetwad1ypExawa説xaka説xasa説vaetva社{dNode6vac0wad1ypJxawa社xaka社xasa社vaetva呼{dNode6vac2vaん{dNode6vac0wad1ypJxawb呼んxakaんxasaんvaetvaべ{dNode6vac0wad1ypjxawb呼べxakaべxasaべvaetwad0xawa呼xaka呼xasa呼vaesva製{dNode6vac1va名{dNode6vac0wad1ypJxawc製品名xaka名xasa名vaetwad3ypJi\xawb製品xaka製xasb製品vaetva辞{dNode6vac0wad:ypKKKL@KOOOxawb辞書xaka辞xasb辞書vaetva設{dNode6vac2va定{dNode6vac0wad6ypKjEN|Axawb設定xaka定xasa定vaetva計{dNode6vac0wad1ypIxawe設計手法等xaka計xasd計手法等vaetwad0xawa設xaka設xasa設vaesva載{dNode6vac0wad1ypNxawb載せxaka載xasb載せvaetva円{dNode6vac0wad2ypN}xawc円周率xaka円xasc円周率vaetva版{dNode6vac0wad2ypOQxawa版xaka版xasa版vaetva研{dNode6vac0wad1ypOxawb研究xaka研xasb研究vaetva反{dNode6vac0wad1ypOxawb反映xaka反xasb反映vaetva深{dNode6vac0wad1ypOxawb深層xaka深xasb深層vaetvaニ{dNode6vac0wad1ypOxawkニューラルネットワークxakaニxaskニューラルネットワークvaetva過{dNode6vac2va去{dNode6vac0wad1ypQxawb過去xaka去xasa去vaetva熱{dNode6vac0wad1yp}xawb過熱xaka熱xasa熱vaetwad0xawa過xaka過xasa過vaesva御{dNode6vac0wad2ypQBxawb御覧xaka御xasb御覧vaetva勝{dNode6vac0wad1ypRxawd勝手知っxaka勝xasd勝手知っvaetva在{dNode6vac0wad1ypSxawf在宅勤務環境xaka在xasf在宅勤務環境vaetva基{dNode6vac3va本{dNode6vac0wad2ypWOxawb基本xaka本xasa本vaetva調{dNode6vac0wad1ypyxawb基調xaka調xasa調vaetva礎{dNode6vac0wad1ypdxawb基礎xaka礎xasa礎vaetwad0xawa基xaka基xasa基vaesva的{dNode6vac0wad5ypWXKdexawa的xaka的xasa的vaetvaナ{dNode6vac1vaト{dNode6vac2vaセ{dNode6vac0wad1ypyxawgナイトセミナーxakaセxasdセミナーvaetva・{dNode6vac0wad1ypxawhナイト・セミナーxaka・xase・セミナーvaetwad0xawcナイトxakaトxasaトvaeswad1ypWxawbナイxakaナxasbナイvaetva初{dNode6vac6va心{dNode6vac0wad2ypYFxawc初心者xaka心xasb心者vaetvaだ{dNode6vac0wad1ypexawb初だxakaだxasaだvaetvaめ{dNode6vac0wad2ypfFxawb初めxakaめxasaめvaetva記{dNode6vac0wad1ypLxawc初記事xaka記xasb記事vaetva目{dNode6vac0wad1yplxawc初目黒xaka目xasb目黒vaetvaA{dNode6vac0wad1yplxawg初AmazonxakaAxasfAmazonvaetwad8ypoqqvXemixawa初xaka初xasa初vaetva|{dNode6vac0wad1yp[xawa|xaka|xasa|vaetva={dNode6vac0wad2yp]Xxawa=xaka=xasa=vaetvaボ{dNode6vac3vaー{dNode6vac0wad2yp__xawfボードゲームxakaーxaseードゲームvaetvaケ{dNode6vac0wad1ypUxawbボケxakaケxasaケvaetvaタ{dNode6vac0wad1ypDxawcボタンxakaタxasbタンvaetwad0xawaボxakaボxasaボvaesva交{dNode6vac0wad1yp_xawb交えxaka交xasb交えvaetva去{dNode6vac0wad6yp`gtBHQxawb去年xaka去xasb去年vaetva積{dNode6vac2vaん{dNode6vac0wad1yp`xawb積んxakaんxasaんvaetva読{dNode6vac0wad1yp|xawd積読状態xaka読xasc読状態vaetwad0xawa積xaka積xasa積vaesva[{dNode6vac0wad1yp`xawa[xaka[xasa[vaetva退{dNode6vac2va職{dNode6vac1va日{dNode6vac0wad1yplxawc退職日xaka日xasa日vaetwad2ypaUxawb退職xaka職xasa職vaetva化{dNode6vac0wad1ypxawb退化xaka化xasa化vaetwad0xawa退xaka退xasa退vaesva状{dNode6vac2va況{dNode6vac0wad2ypa]xawb状況xaka況xasa況vaetva態{dNode6vac0wad1ypzxawb状態xaka態xasa態vaetwad0xawa状xaka状xasa状vaesva留{dNode6vac0wad1ypaxawb留めxaka留xasb留めvaetva結{dNode6vac2va論{dNode6vac0wad1ypaxawb結論xaka論xasa論vaetva構{dNode6vac1va前{dNode6vac0wad1yp|xawc結構前xaka前xasa前vaetwad4ypFPy|xawb結構xaka構xasa構vaetwad0xawa結xaka結xasa結vaesva元{dNode6vac1vaに{dNode6vac0wad1ypVxawb元にxakaにxasaにvaetwad8ypgtBHQJK\xawa元xaka元xasa元vaetva普{dNode6vac0wad3yphqcxawb普段xaka普xasb普段vaetvae{dNode6vac6vam{dNode6vac0wad1ypixaweemacsxakamxasdmacsvaetvav{dNode6vac1vas{dNode6vac0wad1yp[xawfeventsxakasxasasvaetwad1ypoxaweeventxakavxasdventvaetval{dNode6vac1vas{dNode6vac1vae{dNode6vac1vah{dNode6vac0wad<ypuy~DHJKN\]`bcegg{~>xawmelasticsearchxakahxasahvaetwad1ypgxawlelasticsearcxakaexasdearcvaetwad1ypMxawhelasticsxakasxasasvaetwad2ypq`xawgelasticxakalxasflasticvaetvax{dNode6vac2vac{dNode6vac0wad1ypAxawhexcitingxakacxasfcitingvaetvat{dNode6vac0wad2ypJ{xawhextendedxakatxasftendedvaetwad0xawbexxakaxxasaxvaesvac{dNode6vac0wad1ypAxawiecosystemxakacxashcosystemvaetvad{dNode6vac0wad1ypVxawgeditionxakadxasfditionvaetwad0xawaexakaexasaevaesva越{dNode6vac0wad1ypixawb越すxaka越xasb越すvaetva管{dNode6vac0wad2ypisxawb管理xaka管xasb管理vaetva上{dNode6vac2vaげ{dNode6vac0wad2ypjHxawb上げxakaげxasaげvaetvaが{dNode6vac0wad1ypJxawc上がっxakaがxasbがっvaetwad3ypPYyxawa上xaka上xasa上vaetva有{dNode6vac0wad1yplxawd有休消化xaka有xasd有休消化vaetva質{dNode6vac1va問{dNode6vac0wad4ypssC^xawb質問xaka問xasa問vaetwad1ypmxawa質xaka質xasa質vaetva高{dNode6vac0wad1ypmxawb高いxaka高xasb高いvaetva頂{dNode6vac2vaく{dNode6vac0wad1ypmxawb頂くxakaくxasaくvaetvaい{dNode6vac0wad2yppNxawb頂いxakaいxasaいvaetwad0xawa頂xaka頂xasa頂vaesva毎{dNode6vac2va年{dNode6vac0wad1ypnxawb毎年xaka年xasa年vaetva月{dNode6vac0wad1ypxxawd毎月開催xaka月xasc月開催vaetwad0xawa毎xaka毎xasa毎vaesva恒{dNode6vac0wad1ypnxawb恒例xaka恒xasb恒例vaetva#{dNode6vac1va#{dNode6vac0wad1ypmxawb##xaka#xasa#vaetwad<ypoo{fgglzIisyyydD>xawa#xaka#xasa#vaetva枠{dNode6vac0wad2yponxawa枠xaka枠xasa枠vaetvaY{dNode6vac2vaa{dNode6vac0wad2ypo\xaweYahooxakaaxasdahoovaetvao{dNode6vac0wad3ypzHIxawhYokozunaxakaoxasgokozunavaetwad0xawaYxakaYxasaYvaesva!{dNode6vac0wad5ypoCIdjxawa!xaka!xasa!vaetvah{dNode6vac5vat{dNode6vac1vas{dNode6vac0wad1ypoxawehttpsxakasxasasvaetwad2ypx[xawdhttpxakatxascttpvaetvaa{dNode6vac3vap{dNode6vac0wad1ypxawehappyxakapxascppyvaetvav{dNode6vac0wad1ypZxawdhavexakavxasbvevaetvar{dNode6vac1vaa{dNode6vac0wad1ypLxawhharuyamaxakaaxascamavaetwad1yp~xaweharuyxakarxascruyvaetwad0xawbhaxakaaxasaavaesvae{dNode6vac1va気{dNode6vac0wad1yp^xawgheroku気xaka気xasa気vaetwad1ypFxawfherokuxakaexaseerokuvaetvai{dNode6vac0wad1ypLxawfhideakxakaixaseideakvaetvao{dNode6vac0wad1yp}xawhhomebrewxakaoxasgomebrewvaetwad0xawahxakahxasahvaesvay{dNode6vac4vaj{dNode6vac1vab{dNode6vac0wad1ypoxawiyjbonfirexakabxasgbonfirevaetwad1ypoxawbyjxakajxasajvaetvae{dNode6vac0wad1ypxawdyearxakaexascearvaetvao{dNode6vac0wad2ypr\xawcyouxakaoxasbouvaetvau{dNode6vac0wad2ypVaxawgyusukeyxakauxasfusukeyvaetwad0xawayxakayxasayvaesva技{dNode6vac2va書{dNode6vac0wad1ypOxawd技術書読xaka書xasb書読vaetva評{dNode6vac1va様{dNode6vac0wad1yplxawf技術評論社様xaka様xasa様vaetwad1ypuxawe技術評論社xaka評xasc評論社vaetwad4yppKObxawb技術xaka技xasb技術vaetva販{dNode6vac0wad1yppxawb販売xaka販xasb販売vaetva替{dNode6vac0wad1ypqxawb替えxaka替xasb替えvaetvaん{dNode6vac1vaじ{dNode6vac0wad1ypKxawcんじゃxakaじxasbじゃvaetwad8yprr{O^KiDxawaんxakaんxasaんvaetva独{dNode6vac0wad1yprxawb独学xaka独xasb独学vaetvaj{dNode6vac3vao{dNode6vac2vah{dNode6vac0wad3ypsPSxawgjohtanixakahxasehtanivaetvai{dNode6vac0wad1ypexawfjoinedxakaixasdinedvaetwad0xawbjoxakaoxasaovaesvab{dNode6vac0wad1ypixawejbugjxakabxasdbugjvaetvaa{dNode6vac0wad6ypv@@@Gxawcjarxakaaxasbarvaetwad0xawajxakajxasajvaesva運{dNode6vac2va営{dNode6vac0wad2ypsvxawb運営xaka営xasa営vaetva用{dNode6vac0wad1ypaxawb運用xaka用xasa用vaetwad0xawa運xaka運xasa運vaesva英{dNode6vac2va語{dNode6vac1va力{dNode6vac0wad1yptxawc英語力xaka力xasa力vaetwad5yptQjUUxawb英語xaka語xasa語vaetva単{dNode6vac0wad1ypLxawc英単語xaka単xasb単語vaetwad0xawa英xaka英xasa英vaesva＆{dNode6vac0wad2yptZxawa＆xaka＆xasa＆vaetva！{dNode6vac0wad<ypuuMMOixxFG__k>xawa！xaka！xasa！vaetva来{dNode6vac3va年{dNode6vac0wad3ypu|`xawb来年xaka年xasa年vaetvaる{dNode6vac0wad1ypvxawb来るxakaるxasaるvaetvaま{dNode6vac1vaし{dNode6vac0wad6ypMRcqijxawc来ましxakaしxasaしvaetwad1ypdxawb来まxakaまxasaまvaetwad2ypfTxawa来xaka来xasa来vaetva忘{dNode6vac0wad3ypu^Fxawb忘れxaka忘xasb忘れvaetvaず{dNode6vac2vaー{dNode6vac0wad1ypRxawbずーxakaーxasaーvaetvaっ{dNode6vac0wad1yplxawbずっxakaっxasaっvaetwad4ypuglwxawaずxakaずxasaずvaetva遅{dNode6vac4vaれ{dNode6vac0wad1ypvxawb遅れxakaれxasaれvaetvaく{dNode6vac0wad4ypSutDxawb遅くxakaくxasaくvaetva刻{dNode6vac0wad2yp__xawd遅刻厳禁xaka刻xasc刻厳禁vaetva延{dNode6vac0wad1ypMxawb遅延xaka延xasa延vaetwad0xawa遅xaka遅xasa遅vaesva転{dNode6vac0wad4ypwwTTxawb転職xaka転xasb転職vaetva持{dNode6vac2vaっ{dNode6vac0wad2ypwlxawb持っxakaっxasaっvaetvaち{dNode6vac0wad1ypfxawb持ちxakaちxasaちvaetwad0xawa持xaka持xasa持vaesva会{dNode6vac2va社{dNode6vac0wad2ypwexawb会社xaka社xasa社vaetva場{dNode6vac1va提{dNode6vac0wad4ypMNT_xawd会場提供xaka提xasb提供vaetwad6ypxxVVY[xawb会場xaka場xasa場vaetwad1ypvxawa会xaka会xasa会vaetva半{dNode6vac0wad1ypwxawb半年xaka半xasb半年vaetva割{dNode6vac0wad1ypwxawb割合xaka割xasb割合vaetva海{dNode6vac1va自{dNode6vac0wad1ypexawd海外自体xaka自xasb自体vaetwad5ypwQeffxawb海外xaka海xasb海外vaetvaへ{dNode6vac1vaん{dNode6vac0wad2ypgHxawbへんxakaんxasaんvaetwad6ypwuTkxHxawaへxakaへxasaへvaetva借{dNode6vac0wad2ypxOxawb借りxaka借xasb借りvaetva募{dNode6vac0wad1ypxxawb募集xaka募xasb募集vaetva補{dNode6vac0wad1ypyxawb補足xaka補xasb補足vaetva久{dNode6vac2va々{dNode6vac0wad<ypyFGOOBah|@Wor>xawb久々xaka々xasa々vaetvaし{dNode6vac0wad4ypKIc`xawb久しxakaしxasaしvaetwad0xawa久xaka久xasa久vaesva流{dNode6vac3vaれ{dNode6vac0wad7ypzKmTUsJxawb流れxakaれxasaれvaetvaし{dNode6vac0wad2ypZJxawb流しxakaしxasaしvaetva行{dNode6vac1vaり{dNode6vac0wad1yplxawc流行りxakaりxasaりvaetwad1yp]xawb流行xaka行xasa行vaetwad1ypUxawa流xaka流xasa流vaetva色{dNode6vac1va入{dNode6vac0wad1yprxawc色々入xaka入xasa入vaetwad4yp{Up_xawb色々xaka色xasb色々vaetvan{dNode6vac3vae{dNode6vac0wad2ypxawcnewxakaexasbewvaetvao{dNode6vac0wad1yp^xawcnowxakaoxasbowvaetvaa{dNode6vac0wad1ypLxawenaistxakaaxasdaistvaetwad2yp||xawanxakanxasanvaetva単{dNode6vac0wad3yp|pLxawb単語xaka単xasb単語vaetva分{dNode6vac4va割{dNode6vac0wad1yp}xawb分割xaka割xasa割vaetva析{dNode6vac0wad1yprxawb分析xaka析xasa析vaetva離{dNode6vac0wad1ypxawb分離xaka離xasa離vaetva散{dNode6vac0wad1ypIxawb分散xaka散xasa散vaetwad0xawa分xaka分xasa分vaesva鉄{dNode6vac0wad2yp~zxawa鉄xaka鉄xasa鉄vaetva熱{dNode6vac0wad2yp~zxawd熱いうちxaka熱xasd熱いうちvaetva打{dNode6vac0wad2yp~zxawb打てxaka打xasb打てvaetva効{dNode6vac0wad1yp~xawb効率xaka効xasb効率vaetvak{dNode6vac4vaa{dNode6vac0wad1ypxawikatsyoshixakaaxashatsyoshivaetvan{dNode6vac0wad1yprxawdknowxakanxascnowvaetvai{dNode6vac0wad1yptxawfkibanaxakaixaseibanavaetvao{dNode6vac2vap{dNode6vac0wad4yp]^`bxawdkopfxakapxasbpfvaetvab{dNode6vac0wad1ypPxawikobayashixakabxasgbayashivaetwad1ypcxawbkoxakaoxasaovaetwad0xawakxakakxasakvaesva順{dNode6vac1va不{dNode6vac0wad1ypBxawc順不同xaka不xasb不同vaetwad1yp@xawa順xaka順xasa順vaetvaり{dNode6vac0wad1ypAxawaりxakaりxasaりvaetva復{dNode6vac2va活{dNode6vac0wad1ypAxawb復活xaka活xasa活vaetva帰{dNode6vac0wad1ypDxawb復帰xaka帰xasa帰vaetwad0xawa復xaka復xasa復vaesva行{dNode6vac2vaっ{dNode6vac0wad<ypBggMPRjqrMSijv>xawb行っxakaっxasaっvaetvaき{dNode6vac0wad1ypRxawb行きxakaきxasaきvaetwad0xawa行xaka行xasa行vaesva内{dNode6vac4va検{dNode6vac0wad2ypEExawc内検索xaka検xasb検索vaetva容{dNode6vac0wad5ypro{kxawb内容xaka容xasa容vaetva緒{dNode6vac0wad2ypG{xawb内緒xaka緒xasa緒vaetva部{dNode6vac0wad1yp\xawb内部xaka部xasa部vaetwad1yp[xawa内xaka内xasa内vaetva：{dNode6vac0wad<ypEUVWXYZ[\]^`acdhjklnprtuxy}~ABDHKNQ\\rQQ>xawa：xaka：xasa：vaetva執{dNode6vac1va者{dNode6vac0wad1ypMxawc執筆者xaka者xasa者vaetwad3ypFOvxawb執筆xaka執xasb執筆vaetva主{dNode6vac1va催{dNode6vac1va者{dNode6vac0wad1ypkxawc主催者xaka者xasa者vaetwad5ypG}AFixawb主催xaka催xasa催vaetwad2ypJzxawa主xaka主xasa主vaetva超{dNode6vac0wad1ypGxawb超えxaka超xasb超えvaetva課{dNode6vac0wad1ypGxawb課題xaka課xasb課題vaetva悩{dNode6vac0wad2ypGcxawb悩みxaka悩xasb悩みvaetva{dNode6vac0wad1ypHxawaxakaxasavaetvaぶ{dNode6vac1vaく{dNode6vac0wad1yp|xaweぶりくらいxakaくxascくらいvaetwad6ypKIc}`Cxawbぶりxakaぶxasbぶりvaetva物{dNode6vac1va理{dNode6vac1va的{dNode6vac0wad1yp[xawc物理的xaka的xasa的vaetwad1ypexawb物理xaka理xasa理vaetwad2ypLUxawa物xaka物xasa物vaetva壊{dNode6vac1vaる{dNode6vac0wad1ypLxawc壊れるxakaるxasaるvaetwad2ypLLxawb壊れxaka壊xasb壊れvaetva厄{dNode6vac0wad1ypLxawb厄年xaka厄xasb厄年vaetva腕{dNode6vac0wad1ypLxawc腕時計xaka腕xasc腕時計vaetva電{dNode6vac3va波{dNode6vac0wad1ypLxawd電波腕時xaka波xasc波腕時vaetva子{dNode6vac3va版{dNode6vac0wad2ypddxawc電子版xaka版xasa版vaetva化{dNode6vac0wad1yplxawc電子化xaka化xasa化vaetva書{dNode6vac0wad1yplxawd電子書籍xaka書xasb書籍vaetwad2ypuuxawb電子xaka子xasa子vaetva源{dNode6vac0wad1ypDxawb電源xaka源xasa源vaetwad0xawa電xaka電xasa電vaesva皆{dNode6vac3vaさ{dNode6vac0wad<ypMMNNPTT__iimmwwGGLLF>xawc皆さんxakaさxasbさんvaetva勤{dNode6vac0wad4ypkwczxawc皆勤賞xaka勤xasb勤賞vaetva様{dNode6vac0wad1ypNxawb皆様xaka様xasa様vaetwad1ypPxawa皆xaka皆xasa皆vaetva監{dNode6vac0wad1ypOxawb監修xaka監xasb監修vaetva師{dNode6vac0wad2ypSCxawb師走xaka師xasb師走vaetva※{dNode6vac0wad<ypUVWXYZZ[\]^`acdhjklnprtuxy}~ABDHKiko>xawa※xaka※xasa※vaetva翻{dNode6vac0wad<ypUVWXYZ[\]^`acdhjklnprtuxy}~ABDHIKQVd>xawb翻訳xaka翻xasb翻訳vaetva誕{dNode6vac0wad1ypUxawb誕生xaka誕xasb誕生vaetva同{dNode6vac2va様{dNode6vac0wad1ypUxawb同様xaka様xasa様vaetva梱{dNode6vac0wad1yp@xawb同梱xaka梱xasa梱vaetwad0xawa同xaka同xasa同vaesva飲{dNode6vac2vaみ{dNode6vac0wad2ypUrxawb飲みxakaみxasaみvaetvaん{dNode6vac0wad2yp{@xawb飲んxakaんxasaんvaetwad0xawa飲xaka飲xasa飲vaesva,{dNode6vac0wad8ypVVWZrXX\xawa,xaka,xasa,vaetvar{dNode6vac4vae{dNode6vac2val{dNode6vac1vae{dNode6vac0wad<ypWXY[]`ahuy}~BDHK>xawhreleasedxakaexasbedvaetwad1yprxawfreleasxakalxasdleasvaetvas{dNode6vac0wad1ypbxawdrestxakasxasbstvaetwad0xawbrexakaexasaevaesvau{dNode6vac0wad1ypxxawgrunningxakauxasfunningvaetvai{dNode6vac0wad1ypxaweriverxakaixasdivervaetvay{dNode6vac1vau{dNode6vac0wad1ypPxawcryuxakauxasauvaetwad1ypRxawbryxakayxasayvaetwad0xawarxakarxasarvaesva+{dNode6vac0wad2ypXkxawa+xaka+xasa+vaetva�{dNode6vac0wad1ypXxawb💚xaka�xasb💚vaetva画{dNode6vac2va像{dNode6vac0wad2ypZixawb画像xaka像xasa像vaetva面{dNode6vac0wad5yp]`bbsxawb画面xaka面xasa面vaetwad0xawa画xaka画xasa画vaesva覧{dNode6vac0wad1ypZxawb覧くxaka覧xasb覧くvaetvau{dNode6vac2van{dNode6vac0wad1yp\xawiunpluggedxakanxashnpluggedvaetvap{dNode6vac0wad1yptxawfupdatexakapxasepdatevaetwad0xawauxakauxasauvaesva東{dNode6vac0wad5ypbosvxawb東京xaka東xasb東京vaetva京{dNode6vac0wad1ypbxawa京xaka京xasa京vaetvaユ{dNode6vac1vaー{dNode6vac3vaカ{dNode6vac0wad1ypqxawjユーザカンファレンスxakaカxasgカンファレンスvaetvaガ{dNode6vac0wad1ypQxawfユーザガイドxakaガxascガイドvaetvaー{dNode6vac0wad1ypixawhユーザーグループxakaーxaseーグループvaetwad3ypc`vxawcユーザxakaーxasbーザvaetwad1ypqxawaユxakaユxasaユvaetva準{dNode6vac0wad1ypdxawb準備xaka準xasb準備vaetva月{dNode6vac0wad1ypexawb月前xaka月xasb月前vaetva素{dNode6vac0wad1ypexawb素晴xaka素xasb素晴vaetva彼{dNode6vac0wad1ypexawb彼らxaka彼xasb彼らvaetvaジ{dNode6vac0wad2ypffxawhジャストシステムxakaジxashジャストシステムvaetvaひ{dNode6vac2vaさ{dNode6vac0wad4ypgZe@xawdひさびさxakaさxascさびさvaetvaど{dNode6vac0wad1ypwxawcひどいxakaどxasbどいvaetwad0xawaひxakaひxasaひvaesva近{dNode6vac2va寄{dNode6vac0wad1ypgxawb近寄xaka寄xasa寄vaetvaく{dNode6vac0wad1ypGxawb近くxakaくxasaくvaetwad0xawa近xaka近xasa近vaesva街{dNode6vac0wad1ypgxawa街xaka街xasa街vaetva企{dNode6vac0wad1ypoxawb企画xaka企xasb企画vaetva弊{dNode6vac0wad1ypqxawc弊社初xaka弊xasc弊社初vaetva{{dNode6vac0wad1ypqxawa{xaka{xasa{vaetva}{dNode6vac0wad1ypqxawa}xaka}xasa}vaetvaト{dNode6vac1vaニ{dNode6vac0wad1ypsxawfトレーニングxakaニxascニングvaetwad1yp{xawcトレーxakaトxascトレーvaetva申{dNode6vac0wad1ypsxawb申しxaka申xasb申しvaetva込{dNode6vac3vaみ{dNode6vac1vaす{dNode6vac0wad1ypsxawc込みすxakaすxasaすvaetwad1yphxawb込みxakaみxasaみvaetvaむ{dNode6vac0wad1ypUxawb込むxakaむxasaむvaetvaん{dNode6vac0wad1ypGxawb込んxakaんxasaんvaetwad0xawa込xaka込xasa込vaesva抽{dNode6vac0wad1yptxawc抽象的xaka抽xasc抽象的vaetva精{dNode6vac0wad1yptxawc精神的xaka精xasc精神的vaetva土{dNode6vac0wad1ypvxawc土曜日xaka土xasc土曜日vaetva午{dNode6vac2va後{dNode6vac0wad2ypvBxawb午後xaka後xasa後vaetva前{dNode6vac0wad1ypyxawc午前中xaka前xasb前中vaetwad0xawa午xaka午xasa午vaesva予{dNode6vac0wad5ypvaBJNxawb予定xaka予xasb予定vaetvad{dNode6vac3vay{dNode6vac0wad1ypxxawgdynamicxakayxasfynamicvaetvao{dNode6vac0wad1yptxawidocumentsxakaoxashocumentsvaetvai{dNode6vac0wad1ypKxawcdicxakaixasbicvaetwad0xawadxakadxasadvaesva横{dNode6vac0wad2ypzzxawb横浜xaka横xasb横浜vaetva橋{dNode6vac0wad1ypzxawa橋xaka橋xasa橋vaetva乗{dNode6vac0wad2ypzfxawb乗りxaka乗xasb乗りvaetva換{dNode6vac0wad2ypzfxawb換えxaka換xasb換えvaetva意{dNode6vac0wad1yp|xawb意味xaka意xasb意味vaetva】{dNode6vac0wad1ypxawa】xaka】xasa】vaetva水{dNode6vac0wad1ypxawa水xaka水xasa水vaetvaペ{dNode6vac2vaジ{dNode6vac0wad4ypBuuuxawcページxakaジxasaジvaetvaス{dNode6vac0wad1yp]xawcペースxakaスxasaスvaetwad0xawbペーxakaペxasbペーvaesvaダ{dNode6vac2vaウ{dNode6vac0wad8ypB~DbmGPPxawfダウンロードxakaウxaseウンロードvaetvaメ{dNode6vac0wad1ypnxawgダメエンジニアxakaメxasfメエンジニアvaetwad0xawaダxakaダxasaダvaesva背{dNode6vac0wad1ypIxawb背景xaka背xasb背景vaetva火{dNode6vac0wad1ypMxawa火xaka火xasa火vaetva『{dNode6vac0wad1ypMxawa『xaka『xasa『vaetva収{dNode6vac0wad1ypMxawb収集xaka収xasb収集vaetva〜{dNode6vac0wad1ypMxawa〜xaka〜xasa〜vaetva可{dNode6vac2va視{dNode6vac1va編{dNode6vac0wad1ypMxawd可視化編xaka編xasa編vaetwad2ypWWxawc可視化xaka視xasb視化vaetva能{dNode6vac0wad6ypu~DbmOxawb可能xaka能xasa能vaetwad0xawa可xaka可xasa可vaesva』{dNode6vac0wad1ypMxawa』xaka』xasa』vaetva語{dNode6vac0wad1ypMxawb語るxaka語xasb語るvaetva演{dNode6vac0wad1ypMxawb演会xaka演xasb演会vaetva様{dNode6vac1va々{dNode6vac0wad1ypjxawb様々xaka々xasa々vaetwad2ypNvxawa様xaka様xasa様vaetva懲{dNode6vac0wad2ypOdxawc懲りずxaka懲xasc懲りずvaetva詳{dNode6vac2vaし{dNode6vac0wad1ypOxawc詳しいxakaしxasbしいvaetva細{dNode6vac0wad1ypZxawb詳細xaka細xasa細vaetwad0xawa詳xaka詳xasa詳vaesva働{dNode6vac0wad1ypPxawb働いxaka働xasb働いvaetva古{dNode6vac2vaく{dNode6vac0wad1ypRxawb古くxakaくxasaくvaetva橋{dNode6vac0wad1ypqxawb古橋xaka橋xasa橋vaetwad0xawa古xaka古xasa古vaesva無{dNode6vac4va理{dNode6vac0wad1ypTxawb無理xaka理xasa理vaetvaか{dNode6vac0wad1yp}xawc無かっxakaかxasbかっvaetvaい{dNode6vac0wad1ypGxawb無いxakaいxasaいvaetva事{dNode6vac0wad1yp_xawb無事xaka事xasa事vaetwad0xawa無xaka無xasa無vaesva余{dNode6vac0wad1ypUxawc余裕出xaka余xasc余裕出vaetva明{dNode6vac0wad1ypUxawa明xaka明xasa明vaetva目{dNode6vac4va次{dNode6vac0wad1ypVxawb目次xaka次xasa次vaetva黒{dNode6vac0wad1ypXxawb目黒xaka黒xasa黒vaetva的{dNode6vac0wad1ypaxawb目的xaka的xasa的vaetva玉{dNode6vac0wad1ypMxawb目玉xaka玉xasa玉vaetwad2ypOwxawa目xaka目xasa目vaetva～{dNode6vac0wad2ypXXxawa～xaka～xasa～vaetva｜{dNode6vac0wad1ypYxawa｜xaka｜xasa｜vaetva酔{dNode6vac0wad1ypZxawb酔っxaka酔xasb酔っvaetva払{dNode6vac0wad1ypZxawb払っxaka払xasb払っvaetva想{dNode6vac0wad1yp[xawb想像xaka想xasb想像vaetva薄{dNode6vac0wad1yp[xawc薄かっxaka薄xasc薄かっvaetva３{dNode6vac0wad1yp]xawa３xaka３xasa３vaetva必{dNode6vac0wad2yp^rxawb必要xaka必xasb必要vaetva２{dNode6vac3va年{dNode6vac0wad1ypbxawb２年xaka年xasa年vaetva時{dNode6vac0wad1ypOxawb２時xaka時xasa時vaetva日{dNode6vac0wad1ypDxawc２日半xaka日xasb日半vaetwad2yp`Axawa２xaka２xasa２vaetva選{dNode6vac0wad2yp`bxawb選択xaka選xasb選択vaetva懇{dNode6vac0wad2ypaIxawc懇親会xaka懇xasc懇親会vaetva旅{dNode6vac0wad1ypcxawc旅行記xaka旅xasc旅行記vaetva幸{dNode6vac2vaせ{dNode6vac0wad1ypgxawb幸せxakaせxasaせvaetvaい{dNode6vac0wad1ypwxawb幸いxakaいxasaいvaetwad0xawa幸xaka幸xasa幸vaesva突{dNode6vac0wad1ypixawb突撃xaka突xasb突撃vaetva隣{dNode6vac0wad1ypixawa隣xaka隣xasa隣vaetva写{dNode6vac0wad1ypixawb写真xaka写xasb写真vaetva撮{dNode6vac0wad1ypixawb撮っxaka撮xasb撮っvaetvaｗ{dNode6vac0wad2ypjaxawaｗxakaｗxasaｗvaetva配{dNode6vac2va布{dNode6vac0wad1ypnxawc配布待xaka布xasb布待vaetva置{dNode6vac0wad1ypsxawb配置xaka置xasa置vaetwad0xawa配xaka配xasa配vaesva応{dNode6vac0wad2ypnGxawb応版xaka応xasb応版vaetva頑{dNode6vac0wad1yppxawc頑張っxaka頑xasc頑張っvaetva所{dNode6vac0wad1yppxawb所存xaka所xasb所存vaetva挨{dNode6vac0wad1yppxawb挨拶xaka挨xasb挨拶vaetva進{dNode6vac2va歩{dNode6vac0wad1ypqxawb進歩xaka歩xasa歩vaetvaん{dNode6vac0wad1yp}xawb進んxakaんxasaんvaetwad0xawa進xaka進xasa進vaesva辛{dNode6vac0wad1yptxawb辛いxaka辛xasb辛いvaetvaね{dNode6vac1vaぇ{dNode6vac0wad1yppxawbねぇxakaぇxasaぇvaetwad1yptxawaねxakaねxasaねvaetva宣{dNode6vac2va伝{dNode6vac0wad1ypvxawb宣伝xaka伝xasa伝vaetva言{dNode6vac0wad1ypMxawb宣言xaka言xasa言vaetwad0xawa宣xaka宣xasa宣vaesva１{dNode6vac2va０{dNode6vac0wad1ypxxawd１００人xaka０xasc００人vaetva年{dNode6vac0wad1ypRxawb１年xaka年xasa年vaetwad0xawa１xaka１xasa１vaesvaょ{dNode6vac0wad1ypxxawbょっxakaょxasbょっvaetvaび{dNode6vac0wad1ypxxawdびっくりxakaびxasdびっくりvaetva提{dNode6vac0wad1ypxxawb提供xaka提xasb提供vaetva雨{dNode6vac0wad1ypyxawa雨xaka雨xasa雨vaetva講{dNode6vac0wad3ypyRnxawb講演xaka講xasb講演vaetva登{dNode6vac0wad2yp@xawb登録xaka登xasb登録vaetva件{dNode6vac1va数{dNode6vac0wad1ypxawb件数xaka数xasa数vaetwad1ypJxawa件xaka件xasa件vaetva資{dNode6vac0wad1ypAxawb資料xaka資xasb資料vaetva喋{dNode6vac0wad1ypAxawb喋っxaka喋xasb喋っvaetva宿{dNode6vac0wad1ypCxawb宿題xaka宿xasb宿題vaetva周{dNode6vac0wad1ypCxawc周りっxaka周xasc周りっvaetvaX{dNode6vac0wad3ypDbbxawfXperiaxakaXxasfXperiavaetvaZ{dNode6vac2vao{dNode6vac0wad1ypUxawhZoomdataxakaoxasgoomdatavaetvai{dNode6vac0wad2yp{}xawfZipkinxakaixaseipkinvaetwad2ypDbxawaZxakaZxasaZvaetva故{dNode6vac0wad1ypDxawb故障xaka故xasb故障vaetva押{dNode6vac0wad1ypDxawb押しxaka押xasb押しvaetva誤{dNode6vac0wad2ypEExawb誤解xaka誤xasb誤解vaetva認{dNode6vac0wad1ypExawb認識xaka認xasb認識vaetva離{dNode6vac0wad3ypGbxxawb離れxaka離xasb離れvaetva玉{dNode6vac0wad1ypGxawb玉川xaka玉xasb玉川vaetva点{dNode6vac0wad1ypHxawa点xaka点xasa点vaetva観{dNode6vac0wad1ypHxawb観点xaka観xasb観点vaetva完{dNode6vac0wad1ypHxawb完全xaka完xasb完全vaetva満{dNode6vac2va足{dNode6vac0wad1ypHxawb満足xaka足xasa足vaetva員{dNode6vac0wad1yp_xawb満員xaka員xasa員vaetwad0xawa満xaka満xasa満vaesva経{dNode6vac0wad1ypKxawb経由xaka経xasb経由vaetva眺{dNode6vac0wad1ypKxawb眺めxaka眺xasb眺めvaetvaぐ{dNode6vac0wad1ypLxawcぐらいxakaぐxascぐらいvaetva遊{dNode6vac1vaび{dNode6vac0wad1ypMxawb遊びxakaびxasaびvaetwad1ypSxawa遊xaka遊xasa遊vaetva仰{dNode6vac0wad1ypPxawe仰せつかるxaka仰xase仰せつかるvaetva忙{dNode6vac0wad1ypPxawd忙しかっxaka忙xasd忙しかっvaetvaざ{dNode6vac0wad1ypQxawbざっxakaざxasbざっvaetvaテ{dNode6vac2vaキ{dNode6vac0wad1ypQxawdテキトーxakaキxascキトーvaetvaス{dNode6vac1vaケ{dNode6vac0wad3ypL~~xawfテストケースxakaケxascケースvaetwad1yp@xawcテストxakaスxasbストvaetwad0xawaテxakaテxasaテvaesva掛{dNode6vac0wad1ypRxawb掛けxaka掛xasb掛けvaetvaモ{dNode6vac2vaジ{dNode6vac0wad2ypSSxaweモジュールxakaジxasdジュールvaetvaデ{dNode6vac2vaレ{dNode6vac0wad1ypdxaweモデレータxakaレxascレータvaetvaリ{dNode6vac0wad1ypIxaweモデリングxakaリxascリングvaetwad0xawbモデxakaデxasaデvaeswad0xawaモxakaモxasaモvaesva賑{dNode6vac0wad1ypTxawc賑わっxaka賑xasc賑わっvaetva憧{dNode6vac0wad1ypUxawb憧れxaka憧xasb憧れvaetva慣{dNode6vac0wad1ypVxawb慣れxaka慣xasb慣れvaetva訳{dNode6vac0wad3ypZtuxawb訳しxaka訳xasb訳しvaetva欠{dNode6vac0wad1yp\xawb欠けxaka欠xasb欠けvaetva視{dNode6vac0wad1yp\xawb視点xaka視xasb視点vaetva寒{dNode6vac0wad1yp\xawc寒かっxaka寒xasc寒かっvaetva落{dNode6vac0wad2yp]~xawb落ちxaka落xasb落ちvaetva危{dNode6vac0wad1yp]xawc危機感xaka危xasc危機感vaetva軟{dNode6vac0wad3yp^qQxawc軟弱者xaka軟xasc軟弱者vaetvaべ{dNode6vac0wad1yp_xawbべきxakaべxasbべきvaetva盛{dNode6vac0wad1yp_xawb盛況xaka盛xasb盛況vaetva容{dNode6vac0wad1ypbxawc容量不xaka容xasc容量不vaetva金{dNode6vac1va曜{dNode6vac0wad2ypcexawc金曜日xaka曜xasb曜日vaetwad1ypdxawa金xaka金xasa金vaetva担{dNode6vac0wad1ypexawb担当xaka担xasb担当vaetva急{dNode6vac0wad1yphxawd急遽参戦xaka急xasd急遽参戦vaetva某{dNode6vac0wad1yphxawa某xaka某xasa某vaetva口{dNode6vac0wad2ypijxawa口xaka口xasa口vaetva綺{dNode6vac0wad2ypjYxawb綺麗xaka綺xasb綺麗vaetvaウ{dNode6vac2vaチ{dNode6vac0wad1ypnxawiウチダスペクトラムxakaチxashチダスペクトラムvaetvaォ{dNode6vac0wad1ypOxawfウォークマンxakaォxaseォークマンvaetwad0xawaウxakaウxasaウvaesva対{dNode6vac2va象{dNode6vac0wad1ypoxawb対象xaka象xasa象vaetva応{dNode6vac0wad1ypyxawb対応xaka応xasa応vaetwad0xawa対xaka対xasa対vaesva微{dNode6vac0wad1ypoxawb微妙xaka微xasb微妙vaetva外{dNode6vac0wad1ypoxawb外れxaka外xasb外れvaetva友{dNode6vac0wad1yppxawb友人xaka友xasb友人vaetva値{dNode6vac0wad1yppxawb値打xaka値xasb値打vaetva価{dNode6vac0wad1yppxawb価格xaka価xasb価格vaetva魅{dNode6vac0wad1ypqxawb魅力xaka魅xasb魅力vaetva連{dNode6vac3va携{dNode6vac0wad1yprxawb連携xaka携xasa携vaetva絡{dNode6vac1va事{dNode6vac0wad1ypNxawd連絡事項xaka事xasb事項vaetwad1ypNxawb連絡xaka絡xasa絡vaetva続{dNode6vac0wad1ypixawb連続xaka続xasa続vaetwad0xawa連xaka連xasa連vaesva苦{dNode6vac0wad2yprqxawb苦労xaka苦xasb苦労vaetva欲{dNode6vac0wad1ypsxawa欲xaka欲xasa欲vaetva恥{dNode6vac1vaず{dNode6vac2vaげ{dNode6vac0wad1ypsxawe恥ずかしげxakaげxasaげvaetvaく{dNode6vac0wad1ypAxawe恥ずかしくxakaくxasaくvaetwad0xawd恥ずかしxakaずxascずかしvaeswad1yptxawa恥xaka恥xasa恥vaetva偉{dNode6vac0wad1ypsxawc偉そうxaka偉xasc偉そうvaetva蒸{dNode6vac0wad1ypuxawb蒸しxaka蒸xasb蒸しvaetva暑{dNode6vac0wad1ypuxawb暑くxaka暑xasb暑くvaetva寝{dNode6vac4vaれ{dNode6vac0wad1ypuxawb寝れxakaれxasaれvaetvaか{dNode6vac1vaし{dNode6vac0wad1ypOxawf寝かしつけさxakaしxasdしつけさvaetwad1ypOxawb寝かxakaかxasaかvaetvaこ{dNode6vac0wad1yphxawc寝こんxakaこxasbこんvaetva込{dNode6vac0wad1ypDxawb寝込xaka込xasa込vaetwad0xawa寝xaka寝xasa寝vaesva伴{dNode6vac0wad1ypvxawb伴いxaka伴xasb伴いvaetva勢{dNode6vac0wad1ypzxawb勢いxaka勢xasb勢いvaetva図{dNode6vac0wad1ypzxawa図xaka図xasa図vaetva悪{dNode6vac0wad1yp{xawb悪いxaka悪xasb悪いvaetvax{dNode6vac1vam{dNode6vac0wad2yp|Gxawcxmlxakamxasbmlvaetwad1yp^xawaxxakaxxasaxvaetva木{dNode6vac0wad1yp}xawc木曜日xaka木xasc木曜日vaetvaケ{dNode6vac0wad2ypexawcケースxakaケxascケースvaetva兼{dNode6vac0wad2ypCZxawb兼ねxaka兼xasb兼ねvaetva秘{dNode6vac0wad1ypExawb秘密xaka秘xasb秘密vaetva丸{dNode6vac0wad1ypExawb丸善xaka丸xasb丸善vaetva―{dNode6vac0wad1ypExawa―xaka―xasa―vaetva非{dNode6vac0wad1ypExawb非常xaka非xasb非常vaetva付{dNode6vac0wad1ypExawb付与xaka付xasb付与vaetva嗅{dNode6vac0wad1ypFxawe嗅ぎつけてxaka嗅xase嗅ぎつけてvaetva各{dNode6vac0wad3ypIxHxawa各xaka各xasa各vaetva子{dNode6vac0wad2ypKOxawb子供xaka子xasb子供vaetva体{dNode6vac0wad1ypKxawb体調xaka体xasb体調vaetva崩{dNode6vac0wad1ypKxawb崩しxaka崩xasb崩しvaetva覚{dNode6vac0wad1ypOxawb覚めxaka覚xasb覚めvaetva回{dNode6vac2va数{dNode6vac0wad1ypPxawb回数xaka数xasa数vaetva答{dNode6vac0wad3ypqy{xawb回答xaka答xasa答vaetwad0xawa回xaka回xasa回vaesvaえ{dNode6vac0wad1ypRxawbえーxakaえxasbえーvaetva森{dNode6vac0wad1ypSxawc森ビルxaka森xasc森ビルvaetva矯{dNode6vac0wad1ypSxawb矯正xaka矯xasb矯正vaetva道{dNode6vac0wad1ypTxawa道xaka道xasa道vaetva親{dNode6vac0wad1ypUxawb親子xaka親xasb親子vaetva絵{dNode6vac0wad1ypUxawb絵本xaka絵xasb絵本vaetva身{dNode6vac0wad1ypUxawe身につけてxaka身xase身につけてvaetva異{dNode6vac1vaな{dNode6vac0wad1ypVxawe異なりましxakaなxasdなりましvaetwad1yp~xawa異xaka異xasa異vaetva広{dNode6vac0wad1ypVxawb広くxaka広xasb広くvaetva駅{dNode6vac0wad1ypVxawa駅xaka駅xasa駅vaetva嬉{dNode6vac0wad1ypWxawc嬉しくxaka嬉xasc嬉しくvaetva顔{dNode6vac0wad1ypXxawa顔xaka顔xasa顔vaetva役{dNode6vac0wad2ypYtxawa役xaka役xasa役vaetva増{dNode6vac0wad1ypZxawb増えxaka増xasb増えvaetva備{dNode6vac0wad6ypZrABBFxawc備忘録xaka備xasc備忘録vaetva六{dNode6vac1va本{dNode6vac0wad1yp[xawc六本木xaka本xasb本木vaetwad1yp[xawa六xaka六xasa六vaetva港{dNode6vac0wad1yp[xawb港区xaka港xasb港区vaetva三{dNode6vac0wad1yp\xawb三田xaka三xasb三田vaetva系{dNode6vac0wad2yp\^xawa系xaka系xasa系vaetva陥{dNode6vac0wad1yp]xawb陥っxaka陥xasb陥っvaetva我{dNode6vac0wad1yp]xawa我xaka我xasa我vaetva暇{dNode6vac0wad1ypcxawb暇人xaka暇xasb暇人vaetva部{dNode6vac0wad1ypdxawb部分xaka部xasb部分vaetva速{dNode6vac2va読{dNode6vac0wad1ypfxawb速読xaka読xasa読vaetva報{dNode6vac0wad2ypxHxawb速報xaka報xasa報vaetwad0xawa速xaka速xasa速vaesva勤{dNode6vac0wad1yphxawb勤労xaka勤xasb勤労vaetva朝{dNode6vac0wad1yphxawb朝晩xaka朝xasb朝晩vaetva冷{dNode6vac0wad1yphxawb冷えxaka冷xasb冷えvaetva激{dNode6vac0wad1yphxawc激しいxaka激xasc激しいvaetva武{dNode6vac0wad1ypjxawb武田xaka武xasb武田vaetva破{dNode6vac0wad1yplxawb破棄xaka破xasb破棄vaetva腰{dNode6vac0wad1ypnxawa腰xaka腰xasa腰vaetva重{dNode6vac0wad1ypnxawb重いxaka重xasb重いvaetva探{dNode6vac0wad1yppxawb探しxaka探xasb探しvaetva痛{dNode6vac0wad1yptxawb痛感xaka痛xasb痛感vaetva凹{dNode6vac0wad1yptxawb凹んxaka凹xasb凹んvaetva晒{dNode6vac0wad1yptxawb晒すxaka晒xasb晒すvaetva疲{dNode6vac0wad1ypvxawb疲れxaka疲xasb疲れvaetva台{dNode6vac0wad1ypwxawb台風xaka台xasb台風vaetva怖{dNode6vac0wad1ypwxawc怖かっxaka怖xasc怖かっvaetvaゆ{dNode6vac0wad1yp|xawdゆっくりxakaゆxasdゆっくりvaetva訪{dNode6vac0wad1yp|xawb訪れxaka訪xasb訪れvaetva消{dNode6vac0wad1yp|xawb消化xaka消xasb消化vaetva世{dNode6vac0wad1yp|xawb世界xaka世xasb世界vaetva着{dNode6vac0wad1yp~xawb着いxaka着xasb着いvaetva８{dNode6vac0wad2ypCCxawb８年xaka８xasb８年vaetva帰{dNode6vac0wad1ypDxawb帰っxaka帰xasb帰っvaetva耳{dNode6vac0wad1ypExawa耳xaka耳xasa耳vaetva毛{dNode6vac0wad1ypFxawa毛xaka毛xasa毛vaetva座{dNode6vac0wad1ypIxawc座談会xaka座xasc座談会vaetva未{dNode6vac0wad1ypJxawc未知語xaka未xasc未知語vaetva歴{dNode6vac0wad1ypQxawb歴史xaka歴xasb歴史vaetva移{dNode6vac0wad1ypQxawc移植版xaka移xasc移植版vaetva…{dNode6vac0wad1ypRxawa…xaka…xasa…vaet>wad0xaw`xak`xas`vaesvgisArraysvdtags3xdtypeeRadixvdnode{dNode6vac<va1{dNode6vac0wad;ypvwFGHNO|}~xawc100xaka1xasc100vaetva2{dNode6vac0wad2ypg^xawa2xaka2xasa2vaetva4{dNode6vac0wad1yptxawa4xaka4xasa4vaetva振{dNode6vac0wad;ypQ]YkgtBHQ{qxawb振りxaka振xasb振りvaetva返{dNode6vac0wad;ypQ]YkgtBHQ{qxawb返りxaka返xasb返りvaetvao{dNode6vac3var{dNode6vac0wad1ypRxaweoramaxakarxasdramavaetvap{dNode6vac0wad1yp_xawjopensearchxakapxasipensearchvaetvac{dNode6vac0wad3ypfkWxawioctopressxakacxashctopressvaetwad0xawaoxakaoxasaovaesvas{dNode6vac4vae{dNode6vac2vaa{dNode6vac1vak{dNode6vac0wad1ypUxawisearchkitxakakxasckitvaetwad<ypRUWX[]`dfxBCIJW]>xawfsearchxakaaxasdarchvaetvan{dNode6vac0wad1ypUxawesensexakanxascnsevaetwad0xawbsexakaexasaevaesvat{dNode6vac3vaa{dNode6vac0wad1ypDxawestackxakaaxascackvaetvau{dNode6vac0wad2ypUWxawfstudioxakauxasdudiovaetvar{dNode6vac0wad1yp^xawfstreamxakarxasdreamvaetwad0xawbstxakatxasatvaesvah{dNode6vac0wad2ypVrxawfshieldxakahxasehieldvaetvao{dNode6vac2van{dNode6vac0wad1ypJxawhsonatypexakanxasfnatypevaetval{dNode6vac0wad<ypZ[t|GHIkstuxH>xawdsolrxakalxasblrvaetwad0xawbsoxakaoxasaovaeswad0xawasxakasxasasvaesvam{dNode6vac3vai{dNode6vac0wad<ypS^Z[\aehijmnopqtQSYhijwL@fVWA_`jlR>xawdmiscxakaixasciscvaetvau{dNode6vac0wad2ypS^xawemusicxakauxasdusicvaetvaa{dNode6vac0wad4ypV}kmxawfmarvelxakaaxasearvelvaetwad0xawamxakamxasamvaesvab{dNode6vac3vao{dNode6vac2vat{dNode6vac0wad1ypSxawcbotxakatxasatvaetvao{dNode6vac0wad9yp{@AEMPRTVxawdbookxakaoxasbokvaetwad0xawbboxakaoxasaovaesvae{dNode6vac2val{dNode6vac0wad1yp\xawebelinxakalxasclinvaetvar{dNode6vac0wad4ypU^_|xawfberlinxakarxasdrlinvaetwad0xawbbexakaexasaevaesvau{dNode6vac0wad5yp\U^_|xawibuzzwordsxakauxashuzzwordsvaetwad0xawabxakabxasabvaesva読{dNode6vac0wad<ypT{@AEMPRTVXZ`YfEQTUfwy{|>xawb読書xaka読xasb読書vaetvae{dNode6vac2val{dNode6vac2vas{dNode6vac0wad<ypT_PQSTVdlIJKLUnuvxCDFIJKMNPRTUVWZ[\]^_`abcdehijlmnoprstuvwxyz|}~CDEFGHILOPQRSVX\]^_`bcdeghijkmoprtwx{|~@ABLO`>xawmelasticsearchxakasxasfsearchvaetvao{dNode6vac0wad1ypqxawielasticonxakaoxasbonvaetwad4ypDXYqxawgelasticxakalxasflasticvaetvas{dNode6vac0wad1yp^xawbesxakasxasasvaetwad0xawaexakaexasaevaesva-{dNode6vac0wad<ypU{{@@AAEEMMPPRRTTVVnXmvy~@DLMNW^bhmnp~@FGJKLMNOPQ>xawa-xaka-xasa-vaetvau{dNode6vac0wad1ypUxawbuixakauxasbuivaetva画{dNode6vac0wad1ypUxawb画面xaka画xasb画面vaetvad{dNode6vac0wad4ypVWYZxawcdevxakadxascdevvaetva {dNode6vac0wad<ypVWYZ\UW[^_`dfx|BCDIJUUWWW]CDEFQST>xawa xaka xasa vaetvac{dNode6vac2vao{dNode6vac3van{dNode6vac2vat{dNode6vac0wad4ypVWYZxawicontainerxakatxasftainervaetvaf{dNode6vac0wad5yp\U^_|xawjconferencexakafxasgferencevaetwad0xawcconxakanxasanvaesvad{dNode6vac0wad2ypUWxawdcodexakadxasbdevaetvaf{dNode6vac0wad1yp@xawfcoffeexakafxasdffeevaetwad0xawbcoxakaoxasaovaesvau{dNode6vac0wad2ypRoxawgcuratorxakauxasfuratorvaetwad0xawacxakacxasacvaesvah{dNode6vac2vau{dNode6vac0wad4ypWR\fxawdhugoxakauxascugovaetvaa{dNode6vac0wad2ypvIxawfhadoopxakaaxaseadoopvaetwad0xawahxakahxasahvaesvaw{dNode6vac4vas{dNode6vac0wad1ypXxawcwslxakasxasbslvaetvai{dNode6vac2van{dNode6vac0wad3ypXopxawgwindowsxakanxasendowsvaetvak{dNode6vac0wad3yp@Bxawiwikipediaxakakxasgkipediavaetwad0xawbwixakaixasaivaesvao{dNode6vac0wad2ypIJxawiworkplacexakaoxashorkplacevaetvaa{dNode6vac0wad1ypVxawgwatcherxakaaxasfatchervaetwad0xawawxakawxasawvaesvap{dNode6vac4vay{dNode6vac0wad3ypYZ[xawfpythonxakayxaseythonvaetvaa{dNode6vac0wad2ypX]xawepaperxakaaxasdapervaetval{dNode6vac0wad<ypz@AKJP]`bcgw{|~>xawfpluginxakalxaseluginvaetvau{dNode6vac0wad1ypkxawfpuppetxakauxaseuppetvaetwad0xawapxakapxasapvaesval{dNode6vac2vau{dNode6vac0wad<ypPQ}~nXmvy~@DLMNW^bhmnp~@FGJKLMNOPQ>xawflucenexakauxaseucenevaetvao{dNode6vac0wad7ypYZjABEFxawhlogstashxakaoxasgogstashvaetwad0xawalxakalxasalvaesvaj{dNode6vac2vaa{dNode6vac0wad1ypVxawdjavaxakaaxascavavaetvaj{dNode6vac0wad1ypxawdjjugxakajxascjugvaetwad0xawajxakajxasajvaesvaa{dNode6vac0wad;ypW[`dfxBCW]xaweazurexakaaxaseazurevaetvaD{dNode6vac0wad7yp\ahimnqxawcDIYxakaDxascDIYvaetvaキ{dNode6vac0wad7yp\ahimnqxaweキーボードxakaキxaseキーボードvaetvaM{dNode6vac3vaI{dNode6vac0wad1yp^xaweMICESxakaIxasdICESvaetvaa{dNode6vac0wad2yp}FxawjManifoldCFxakaaxasianifoldCFvaetvao{dNode6vac0wad2ypCExawjMorphlinesxakaoxasiorphlinesvaetwad0xawaMxakaMxasaMvaesva勉{dNode6vac0wad<ypbcoqrsxyGMNPT_bfgimovwzGLMSWXY_aejlxAPR\^_acdeijklnoqrsuwBFKPSVXY[\]acgizD>xawc勉強会xaka勉xasc勉強会vaetva輪{dNode6vac0wad1ypgxawb輪読xaka輪xasb輪読vaetvaN{dNode6vac2vaa{dNode6vac0wad1ypgxawdNandxakaaxascandvaetvao{dNode6vac0wad1ypyxawgNorikraxakaoxasforikravaetwad0xawaNxakaNxasaNvaesvaT{dNode6vac0wad1ypgxawfTetrisxakaTxasfTetrisvaetvaR{dNode6vac2vau{dNode6vac0wad<ypruvwFGHNO|}~>xawdRustxakauxascustvaetvai{dNode6vac0wad5ypz}HIMxawdRiakxakaixasciakvaetwad0xawaRxakaRxasaRvaesvaL{dNode6vac2vai{dNode6vac0wad1yprxawgLinderaxakaixasfinderavaetvau{dNode6vac0wad2ypmnxawfLucenexakauxaseucenevaetwad0xawaLxakaLxasaLvaesva検{dNode6vac0wad5ypsyz^sxawb検索xaka検xasb検索vaetvan{dNode6vac3val{dNode6vac0wad;ypvwFGHNO|}~xawcnlpxakalxasblpvaetvae{dNode6vac0wad1ypBxawcnetxakaexasbetvaetvao{dNode6vac0wad1ypexawbnoxakaoxasaovaetwad0xawanxakanxasanvaesvar{dNode6vac2vau{dNode6vac0wad<yp{{@@AAEEMMPPRRTTVVXZ`>xawdrustxakauxascustvaetvae{dNode6vac0wad1ypQxawgreleasexakaexasfeleasevaetwad0xawarxakarxasarvaesvat{dNode6vac3vah{dNode6vac0wad9yp{@AEMPRTVxawcthexakahxasbhevaetvai{dNode6vac0wad1ypSxawhtimelionxakaixasgimelionvaetvar{dNode6vac0wad1ypfxawftravelxakarxaseravelvaetwad0xawatxakatxasatvaesvak{dNode6vac2vau{dNode6vac0wad3ypr@xawhkuromojixakauxasguromojivaetvai{dNode6vac0wad;ypFSXZtEFOxLOxawfkibanaxakaixaseibanavaetwad0xawakxakakxasakvaesva.{dNode6vac0wad2ypBexawa.xaka.xasa.vaetvav{dNode6vac2vai{dNode6vac0wad2ypUWxawfvisualxakaixaseisualvaetvaa{dNode6vac0wad1ypkxawgvagrantxakaaxasfagrantvaetwad0xawavxakavxasavvaesva買{dNode6vac0wad1yp[xawb買いxaka買xasb買いvaetva物{dNode6vac0wad1yp[xawa物xaka物xasa物vaetvaブ{dNode6vac0wad6yp\bcdefxawcブログxakaブxascブログvaetvaシ{dNode6vac0wad1yp^xawdシステムxakaシxasdシステムvaetva探{dNode6vac0wad1yp^xawb探訪xaka探xasb探訪vaetvaゲ{dNode6vac0wad1yp_xawcゲームxakaゲxascゲームvaetva転{dNode6vac0wad4ypalTUxawb転職xaka転xasb転職vaetva書{dNode6vac0wad1yppxawb書籍xaka書xasb書籍vaetvaK{dNode6vac0wad3ypz@AxawfKibanaxakaKxasfKibanavaetvaカ{dNode6vac0wad1yp{xawgカンファレンスxakaカxasgカンファレンスvaetvaス{dNode6vac2vaポ{dNode6vac0wad1yp{xaweスポンサーxakaポxasdポンサーvaetvaピ{dNode6vac0wad1ypZxawgスピリチュアルxakaピxasfピリチュアルvaetwad0xawaスxakaスxasaスvaesva本{dNode6vac0wad5ypFOMOVxawa本xaka本xasa本vaetvaf{dNode6vac2vao{dNode6vac0wad1ypexawefoundxakaoxasdoundvaetval{dNode6vac0wad3ypxOUxawgfluentdxakalxasfluentdvaetwad0xawafxakafxasafvaesvaE{dNode6vac0wad3ypJKNxawmElasticsearchxakaExasmElasticsearchvaetvaC{dNode6vac2vaS{dNode6vac0wad1ypYxawkCloudSearchxakaSxasfSearchvaetvae{dNode6vac0wad:ypyCEFGQSSTTxawhClouderaxakaexasceravaetwad0xaweCloudxakaCxaseCloudvaesvaA{dNode6vac0wad3ypYPRxawcAWSxakaAxascAWSvaetva感{dNode6vac0wad1yp[xawc感想文xaka感xasc感想文vaetvaオ{dNode6vac0wad2yp[GxaweオライリーxakaオxaseオライリーvaetvaJ{dNode6vac3vaV{dNode6vac0wad1ypaxawcJVMxakaVxasbVMvaetvaa{dNode6vac0wad1ypaxawdJavaxakaaxascavavaetvaI{dNode6vac0wad1yphxawdJIRAxakaIxascIRAvaetwad0xawaJxakaJxasaJvaesvaS{dNode6vac3vao{dNode6vac0wad<yplnsuv}CEFHIJKMNQST>xawdSolrxakaoxascolrvaetvae{dNode6vac0wad6ypCEFQSTxawfSearchxakaexaseearchvaetvac{dNode6vac0wad1ypRxaweScalaxakacxasdcalavaetwad0xawaSxakaSxasaSvaesvag{dNode6vac0wad<ypnXmvy~@DLMNW^bhmnp~@FGJKLMNOPQ>xawegosenxakagxasegosenvaetvaH{dNode6vac2vaa{dNode6vac0wad5ypyGQSTxawfHadoopxakaaxaseadoopvaetvai{dNode6vac0wad1ypGxawdHivexakaixascivevaetwad0xawaHxakaHxasaHvaesvaY{dNode6vac0wad5ypz}HIMxawhYokozunaxakaYxashYokozunavaetvaX{dNode6vac0wad1ypDxawfXperiaxakaXxasfXperiavaetvaZ{dNode6vac2vao{dNode6vac0wad1ypUxawhZoomdataxakaoxasgoomdatavaetvai{dNode6vac0wad2ypz{xawfZipkinxakaixaseipkinvaetwad1ypDxawaZxakaZxasaZvaetvaB{dNode6vac0wad1ypMxaweBashoxakaBxaseBashovaetva備{dNode6vac0wad<yp]bgpCJOZeor}ABC>xawc備忘録xaka備xasc備忘録vaetvaO{dNode6vac0wad1yp}xawcOSSxakaOxascOSSvaetva形{dNode6vac0wad1ypExawe形態素解析xaka形xase形態素解析vaet>wad0xaw`xak`xas`vaesvgisArraytvddate3xdtypecAVLvdnode5yakPwav0valpvar5yak%$4Awav1ypQval5yak%1!pwav1ypRval5yak%7pwav1ypSval5yak%=Hwav1ypTval5yak$9'|wav1ypUval5yak$0iwav1ypVval5yak$/$Hwav1ypWval5yak$/!(`wav1ypXval5yak$..zwav1ypYval5yak$+?#kwav1ypZval5yak$*6dwav1yp[val5yak$$uwav1yp\val5yak#,
<\wav1yp]val5yak#&Vwav1yp^val5yak#$ 6]wav1yp_val5yak"<13Zwav1ypPval5yak"< rwav1ypQval5yak";
/bwav1ypRval5yak"5:#jwav1ypSval5yak"567{wav1ypTval5yak"*>_wav1ypUval5yak")19Vwav1ypVval5yak"!	 Ywav1ypWval5yak!7*nwav1ypXval5yak!30owav1ypYval5yak!3	xwav1ypZval5yak!0)
gwav1yp[val5yak!+7pwav1yp\val5yak!"5&\wav1yp]val5yak ;/gwav1yp^val5yak 9?'Ewav1yp_val5yak 7Wwav1yp`val5yak "-Twav1ypaval5yak -0gwav1ypbval5yak ~wav1ypcval5yak 3%uwav1ypdval5yak 
7fwav1ypeval5yak pwav1ypfval5yak :|wav1ypgval5yak ,&Jwav1yphval5yak>;,Wwav1ypival5yak;~wav1ypjval5yak;twav1ypkval5yak67{wav1yplval5yak2
-Xwav1ypmval5yak(,gwav1ypnval5yak#+Nwav1ypoval5yak!:8Rwav1yppval5yak 11fwav1ypqval5yak(bwav1yprval5yakfwav1ypsval5yak.&uwav1yptval5yak#>\wav1ypuval5yak cwav1ypvval5yak%
Awav1ypwval5yak9;Wwav1ypxval5yak93Rwav1ypyval5yak)9Vwav1ypzval5yak
.*Jwav1yp{val5yak)lwav1yp|val5yak=Vwav1yp}val5yak<1uwav1yp~val5yak74/Pwav1ypval5yak6Iwav1yp@val5yak37<owav1ypAval5yak3
Wwav1ypBval5yak14
-qwav1ypCval5yak/.mwav1ypDval5yak/
-~wav1ypEval5yak.!qwav1ypFval5yak-:`wav1ypGval5yak-4Iwav1ypHval5yak,7
Rwav1ypIval5yak*<?@wav1ypJval5yak)##owav1ypKval5yak'99Pwav1ypLval5yak&
-jwav1ypMval5yak#.Owav1ypNval5yak#)ywav1ypOval5yak#wav1ypPval5yak"*pwav1ypQval5yak!Nwav1ypRval5yak?gwav1ypSval5yak[wav1ypTval5yak+5}wav1ypUval5yak
Bwav1ypVval5yak,?Wwav1ypWval5yak?Mwav1ypXval5yak?Cwav1ypYval5yak".mwav1ypZval5yak8<nwav1yp[val5yak4"`wav1yp\val5yak
-awav1yp]val5yakkwav1yp^val5yak
%fwav1yp_val5yak
dwav1yp`val5yak

Cwav1ypaval5yak;,dwav1ypbval5yak
-*Ywav1ypcval5yak
-Zwav1ypdval5yak	;fwav1ypeval5yak.Ywav1ypfval5yak,Gwav1ypgval5yak
wav1yphval5yak>Jwav1ypival5yak>
-wwav1ypjval5yak=-Mwav1ypkval5yak:)rwav1yplval5yak9'!pwav1ypmval5yak8(pwav1ypnval5yak,-Bwav1ypoval5yak'-]wav1yppval5yak (dwav1ypqval5yak0/nwav1yprval5yak=Hwav1ypsval5yak
-ewav1yptval5yakqwav1ypuval5yak!vwav1ypvval5yak16owav1ypwval5yak1/nwav1ypxval5yakzwav1ypyval5yak6#iwav1ypzval5yak-$Dwav1yp{val5yak,?ewav1yp|val5yak")(Pwav1yp}val5yak!Uwav1yp~val5yak!
owav1ypval5yakqwav1yp@val5yak~wav1ypAval5yak
!swav1ypBval5yak;Hwav1ypCval5yak
3pwav1ypDval5yak
.Ywav1ypEval5yak00>fwav1ypFval5yak	]wav1ypGval5yak;Fwav1ypHval5yak(9Vwav1ypIval5yak>Vwav1ypJval5yak$Pwav1ypKval5yak2Rwav1ypLval5yak 
[wav1ypMval5yak:"Dwav1ypNval5yak9+7Twav1ypOval5yak#2
Pwav1ypPval5yak!
~wav1ypQval5yakBwav1ypRval5yak{wav1ypSval5yak%bwav1ypTval5yak3
jwav1ypUval5yak1){wav1ypVval5yak#Kwav1ypWval5yak"swav1ypXval5yak"]wav1ypYval5yak1Cwav1ypZval5yak></mwav1yp[val5yak7<<Jwav1yp\val5yak7&hwav1yp]val5yak5dwav1yp^val5yak.0*awav1yp_val5yak."iwav1yp`val5yak+3%Awav1ypaval5yak)0.iwav1ypbval5yak'%Cwav1ypcval5yak&7|wav1ypdval5yak&6>Pwav1ypeval5yak&:Mwav1ypfval5yak ;}wav1ypgval5yak;6Fwav1yphval5yaklwav1ypival5yak
/Zwav1ypjval5yak,Owav1ypkval5yak2pwav1yplval5yak	4bwav1ypmval5yak
-2,wwav1ypnval5yak3Wwav1ypoval5yak6 hwav1yppval5yak??Wwav1ypqval5yak<7Dwav1yprval5yak<uwav1ypsval5yak9,pwav1yptval5yak9,^wav1ypuval5yak9>}wav1ypvval5yak8owav1ypwval5yak7uwav1ypxval5yak7Iwav1ypyval5yak2Pwav1ypzval5yak(>fwav1yp{val5yak&;Lwav1yp|val5yak$(,Xwav1yp}val5yak$&vwav1yp~val5yak$?bwav1ypval5yak#:Lwav1yp@val5yak#
-hwav1ypAval5yak"*Vwav1ypBval5yak=lwav1ypCval5yak(?Twav1ypDval5yak;zwav1ypEval5yak/ owav1ypFval5yak?8[wav1ypGval5yak%iwav1ypHval5yak!Gwav1ypIval5yak!@wav1ypJval5yakhwav1ypKval5yak1hwav1ypLval5yak;*lwav1ypMval5yak+Twav1ypNval5yak78	hwav1ypOval5yak63
-@wav1ypPval5yak51
Xwav1ypQval5yak55Dwav1ypRval5yak2&'pwav1ypSval5yak,!4hwav1ypTval5yak,Twav1ypUval5yak'*<Dwav1ypVval5yak#07Dwav1ypWval5yak2
Xwav1ypXval5yak>xwav1ypYval5yak$/Pwav1ypZval5yak:|wav1yp[val5yak 
lwav1yp\val5yak
-|wav1yp]val5yak=Twav1yp^val5yakpwav1yp_val5yak|wav1yp`val5yak'3@wav1ypaval5yak 1@wav1ypbval5yak
Xwav1ypcval5yak%Twav1ypdval5yak
-twav1ypeval5yak	4twav1ypfval5yak)6twav1ypgval5yak
dwav1yphval5yak0 pwav1ypival5yak=;Hwav1ypjval5yak<9|wav1ypkval5yak:7Xwav1yplval5yak:!Hwav1ypmval5yak92hwav1ypnval5yak8:Pwav1ypoval5yak7(<pwav1yppval5yak0pwav1ypqval5yak,?Pwav1yprval5yak,,|wav1ypsval5yak+<Dwav1yptval5yak)@wav1ypuval5yak%
Dwav1ypvval5yak!?dwav1ypwval5yak Pwav1ypxval5yak."dwav1ypyval5yak$.\wav1ypzval5yak94`wav1yp{val5yak$
-Hwav1yp|val5yak!	Twav1yp}val5yak;Dwav1yp~val5yak
-)xwav1ypval5yak	&Dwav1yp@val5yak8hwav1ypAval5yak-hwav1ypBval5yak>7Hwav1ypCval5yak>&xwav1ypDval5yak>pwav1ypEval5yak='#dwav1ypFval5yak<*dwav1ypGval5yak7<Twav1ypHval5yak7?lwav1ypIval5yak55Pwav1ypJval5yak2>&@wav1ypKval5yak0
twav1ypLval5yak0
Dwav1ypMval5yak-/twav1ypNval5yak-Xwav1ypOval5yak,	`wav1ypPval5yak,Hwav1ypQval5yak+0Xwav1ypRval5yak+-pwav1ypSval5yak+-Lwav1ypTval5yak+
;Twav1ypUval5yak+Fwav1ypVval5yak* .|wav1ypWval5yak!;5Twav1ypXval5yak <3Kwav1ypYval5yak	hwav1ypZval5yak8pwav1yp[val5yak'fwav1yp\val5yak`wav1yp]val5yak#{wav1yp^val5yak@wav1yp_val5yak"Dwav1yp`val5yak/@wav1ypaval5yak'
lwav1ypbval5yak?hwav1ypcval5yak>)+lwav1ypdval5yak=Lwav1ypeval5yak;,@wav1ypfval5yak8lwav1ypgval5yak4/hwav1yphval5yak12hwav1ypival5yak-$Pwav1ypjval5yak,3'`wav1ypkval5yak'(dwav1yplval5yak="Lwav1ypmval5yak,|wav1ypnval5yak
>lwav1ypoval5yakHwav1yppval5yak
%pwav1ypqval5yak+Xwav1yprval5yak:6Twav1ypsval5yakhwav1yptval5yak?/9Bwav1ypuval5yak=uwav1ypvval5yak=.Pwav1ypwval5yak:	\wav1ypxval5yak73Twav1ypyval5yak649hwav1ypzval5yak6(!\wav1yp{val5yak6,\wav1yp|val5yak56Pwav1yp}val5yak40bwav1yp~val5yak3#lwav1ypval5yak3	Lwav1yp@val5yak1$Pwav1ypAval5yak1 lwav1ypBval5yak,4=Rwav1ypCval5yak*,twav1ypDval5yak')/Kwav1ypEval5yak$=Twav1ypFval5yak#Kwav1ypGval5yak"$hwav1ypHval5yak"\wav1ypIval5yak!.mwav1ypJval5yak*
dwav1ypKval5yak`wav1ypLval5yak7Hwav1ypMval5yak
-&twav1ypNval5yak"twav1ypOval5yak@wav1ypPval5yak	`wav1ypQval5yak6Ewav1ypRval5yakxwav1ypSval5yakHwav1ypTval5yak(pwav1ypUval5yak&8xwav1ypVval5yak'\wav1ypWval5yak)2twav1ypXval5yak"dwav1ypYval5yakawav1ypZval5yakCwav1yp[val5yak6Hwav1yp\val5yak8@wav1yp]val5yak+|wav1yp^val5yak
>Iwav1yp_val5yak>4Twav1yp`val5yak< 0\wav1ypaval5yak<=[wav1ypbval5yak;6lwav1ypcval5yak87Cwav1ypdval5yak5%\wav1ypeval5yak5\wav1ypfval5yak4;/twav1ypgval5yak3=`wav1yphval5yak0)1pwav1ypival5yak."pwav1ypjval5yak.
-&xwav1ypkval5yak,$dwav1yplval5yak+$hwav1ypmval5yak)-?Pwav1ypnval5yak'#Kwav1ypoval5yak%lwav1yppval5yak#.;hwav1ypqval5yak#),|wav1yprval5yak#twav1ypsval5yak"-
-Pwav1yptval5yak 0"|wav1ypuval5yak 9twav1ypvval5yak7>Xwav1ypwval5yakDwav1ypxval5yak|wav1ypyval5yak:dwav1ypzval5yak$"dwav1yp{val5yak`wav1yp|val5yak%Hwav1yp}val5yak%|wav1yp~val5yak8Hwav1ypval5yak0hwav1yp@val5yak5twav1ypAval5yakxwav1ypBval5yak!xwav1ypCval5yak8lwav1ypDval5yak	$-|wav1ypEval5yak97xwav1ypFval5yak5Xwav1ypGval5yak%Swav1ypHval5yak3xwav1ypIval5yak0`wav1ypJval5yak
?</Hwav1ypKval5yak
="pwav1ypLval5yak
=<Pwav1ypMval5yak
;
Twav1ypNval5yak
94@wav1ypOval5yak
7!
xwav1ypPval5yak
6`wav1ypQval5yak
5pwav1ypRvalpvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPyahPvgisArraysvmvectorIndexes0w TsearchableProperties5xpbidetitlegsummarydtagsddatev ]searchablePropertiesWithTypes5xbidfstringxetitlefstringxgsummaryfstringxdtagshstring[]xddatefnumbervkfrequencies4vbid<va17ya9 S0.14285714285714285ydd869 S0.14285714285714285ybfb S0.14285714285714285yd48cb S0.14285714285714285ydacba S0.14285714285714285yd03dc S0.14285714285714285ym639481524ee80 S0.14285714285714285va25ya6c0.2yd476ec0.2yc17bc0.2yafc0.2y W854414033d5cec1470774eec0.2va3<ya6 S0.06666666666666667ya7 S0.13333333333333333ya8 S0.13333333333333333yd5010 S0.06666666666666667yd516a S0.06666666666666667ybaa S0.13333333333333333yc07f S0.06666666666666667ycfaa S0.06666666666666667yab S0.06666666666666667ye38beb S0.06666666666666667ybcf S0.06666666666666667yac S0.06666666666666667>va49ya4 R0.1111111111111111yc531 R0.1111111111111111yb7f R0.1111111111111111yc78b R0.1111111111111111yc02c R0.1111111111111111yaf R0.1111111111111111yg09602ba R0.1111111111111111yae R0.1111111111111111yk140132d26a2 R0.1111111111111111va5<ya2 S0.06666666666666667ya3 S0.13333333333333333ya5 S0.06666666666666667ya8 S0.06666666666666667yc765 S0.06666666666666667yb8f S0.06666666666666667ye58cbe S0.06666666666666667yaf S0.13333333333333333ybce S0.06666666666666667yc85c S0.06666666666666667yg22569af S0.06666666666666667ybde S0.06666666666666667yad S0.06666666666666667>va69ya9 R0.1111111111111111yc847 R0.1111111111111111yc886 R0.1111111111111111ybf9 R0.1111111111111111yae R0.1111111111111111ybee R0.1111111111111111ycbdb R0.1111111111111111ybab R0.1111111111111111yo5583eeb6eabbd51 R0.1111111111111111va79yc561 S0.09090909090909091yc999 S0.09090909090909091yd7884 S0.09090909090909091yd9358 S0.09090909090909091ye18218 S0.09090909090909091yab R0.2727272727272727yc62c S0.09090909090909091yad S0.09090909090909091yf52779a S0.09090909090909091va8:ya7c0.1yc403c0.1yc637c0.1ybedc0.1yh431877cec0.1yd11fec0.1ycfeec0.1yc77fc0.1yadc0.1yd26cec0.1va9<ya0 S0.13333333333333333ya2 S0.06666666666666667ya4 S0.06666666666666667ya5 S0.06666666666666667ya6 S0.06666666666666667yh90061486 S0.06666666666666667yd086b S0.06666666666666667ybfd S0.06666666666666667yaf S0.06666666666666667yf77021a S0.06666666666666667yaa S0.06666666666666667ybaa S0.06666666666666667yab S0.06666666666666667yae S0.06666666666666667>vb101y `a12474027c91fad5a861aa9919817d72Qvb114ya3d0.25ye698cfd0.25yccbdd0.25y W796161d82c9ac438ebab5d2d0.25vb121y `9335522f4c8dbc7256a42a091e6e00bcQvb134ybdfd0.25yc30dd0.25yg810068ed0.25y T4656498e5972c6de7e3dd0.25vb14<ya0 S0.07692307692307693ya2 S0.07692307692307693yb30 S0.07692307692307693yd6761 S0.07692307692307693yd9623 S0.07692307692307693yc67c S0.07692307692307693ybae S0.07692307692307693yae S0.07692307692307693yd89be S0.07692307692307693ybfa S0.07692307692307693yd66db S0.07692307692307693yab S0.07692307692307693yc40d S0.07692307692307693>vb159ya1 S0.18181818181818182ya2 S0.09090909090909091yc906 S0.09090909090909091ye9693a S0.09090909090909091yae S0.18181818181818182ye77dee S0.09090909090909091ye5785b S0.09090909090909091ybdc S0.09090909090909091yg61ccffd S0.09090909090909091vb161y `73279888a8fe482c836fb19ca23318dcQvb17<ya3 S0.07692307692307693ya6 S0.07692307692307693ya8 S0.07692307692307693yc840 S0.07692307692307693yd6639 S0.07692307692307693ybec S0.07692307692307693yaf S0.15384615384615385yc88c S0.07692307692307693ye4976f S0.07692307692307693ybca S0.07692307692307693yd20fa S0.07692307692307693yd169e S0.07692307692307693>vb18<ya2 S0.06666666666666667ya6 S0.13333333333333333ya7 S0.06666666666666667ya9 S0.06666666666666667yc579 S0.06666666666666667yd167a S0.06666666666666667yac S0.06666666666666667yad S0.06666666666666667ybce S0.06666666666666667yaf S0.13333333333333333ydcebf S0.06666666666666667yc64a S0.06666666666666667yg6329ecb S0.06666666666666667>vb19:ya6c0.1ya8c0.1yd3384c0.1ybeac0.1ybbbc0.1yc47dc0.1yc70fc0.1ybcac0.1yc94bc0.1yk4510813f36ac0.1vb20<ya4 S0.07692307692307693ya9 S0.07692307692307693yc444 S0.07692307692307693yc720 S0.07692307692307693yd8773 S0.07692307692307693yd779e S0.07692307692307693yab S0.07692307692307693ybbc S0.07692307692307693yaa S0.07692307692307693yceed S0.07692307692307693yc97f S0.07692307692307693yc19c S0.07692307692307693yc41e S0.07692307692307693>vb212ydf56cc0.5y \19442484b3e4f47875b58b3f72b2c0.5vb225yd1726c0.2yf5eebdfc0.2yd85fdc0.2ybdbc0.2y P301194bfeeee4377c0.2vb232yc7ccc0.5y ]21814165879f72529e91682ece5c6c0.5vb241y `0645bdb1cdf88ec74288d503eb71839cQvb25:ya1 S0.09090909090909091ya8 S0.18181818181818182yd7043 S0.09090909090909091yd104b S0.09090909090909091ybee S0.09090909090909091yc17a S0.09090909090909091ybbf S0.09090909090909091yaf S0.09090909090909091yad S0.09090909090909091yl236659680493 S0.09090909090909091vb265ya2c0.2yd218ec0.2yacc0.2yc36dc0.2y W5945ece02fdc55d6cbcbc38c0.2vb274yc140d0.25yef0fdcd0.25yaed0.25y W18514362a4e52376a6fecbad0.25vb28:ya4c0.1ya7c0.1yc26ec0.1ye44dfdc0.1yc16ac0.1ye2963dc0.1yacc0.1yc18ec0.1yf99806cc0.1yd26fdc0.1vb291y `35200cbf0b5b45d7f5f0b343cb18868bQvb306ya7 S0.16666666666666666yc10a S0.16666666666666666yaf S0.16666666666666666yd69bd S0.16666666666666666yc03d S0.16666666666666666y T2632722300194f01e93d S0.16666666666666666vb31;ya6 S0.09090909090909091ya7 S0.09090909090909091yd4858 S0.09090909090909091ye90451 S0.09090909090909091yc59b S0.09090909090909091yab S0.09090909090909091yc60e S0.09090909090909091ycbbf S0.09090909090909091yad S0.09090909090909091yf72643d S0.09090909090909091yd22ad S0.09090909090909091vb32:ya4 S0.16666666666666666ya5 S0.08333333333333333ya8 S0.08333333333333333yf43caef S0.08333333333333333yad S0.16666666666666666yc41c S0.08333333333333333yae S0.08333333333333333yf74826e S0.08333333333333333yaa S0.08333333333333333yi82088739d S0.08333333333333333vb33<ya2 S0.07142857142857142ya4 S0.07142857142857142ya7 S0.07142857142857142yc712 S0.07142857142857142yc794 S0.07142857142857142yef4baa S0.07142857142857142yd43cc S0.07142857142857142ybca S0.07142857142857142yad S0.07142857142857142yc83b S0.07142857142857142yc99a S0.07142857142857142yac S0.07142857142857142yae S0.07142857142857142ycdbd S0.07142857142857142>vb34:ya4c0.1ya7c0.1yd2019c0.1ydf41dc0.1ycfdec0.1ye94cbdc0.1ycbbdc0.1yg28808dcc0.1yc080c0.1yaac0.1vb35<ya4e0.125ya7f0.0625ya8f0.0625yc426f0.0625yc799f0.0625ybcef0.0625yabf0.0625yaff0.0625ye3190cf0.0625yaae0.125yc47df0.0625yd45acf0.0625yaef0.0625yc91af0.0625>vb36<ya0 R0.1111111111111111ya3 S0.05555555555555555ya5 R0.1111111111111111yc301 S0.05555555555555555yd8340 S0.05555555555555555ydeced S0.05555555555555555yc95e S0.05555555555555555yaf S0.05555555555555555yaa S0.05555555555555555yae S0.05555555555555555yc83d S0.05555555555555555yc81d S0.05555555555555555yac R0.1111111111111111yad R0.1111111111111111>vb37:ya6c0.1yc133c0.1yd5777c0.1ycfcbc0.1yd0105c0.1ybfac0.1yabc0.1yaac0.1yafc0.1yl247784b9d930c0.1vb38<ya0f0.0625ya1f0.0625ya2f0.0625ya5f0.0625ya8f0.0625ya9f0.0625yc724f0.0625yd1973f0.0625yd931bf0.0625ycebdf0.0625yebfaebf0.0625ycdcff0.0625yaef0.0625yaaf0.0625yaff0.0625yadf0.0625>vb398ya7e0.125ya8e0.125ybaae0.125yc61be0.125ye4543ee0.125yaae0.125yace0.125y R67fccabee27a6e99cde0.125vb402ygd95522cc0.5y Y691013bfe66dd46ded85a98edc0.5vb418yc641e0.125yd8239e0.125yc4ade0.125yaae0.125yc37fe0.125ycbcde0.125yf17abebe0.125yi96106314ee0.125vb424yc421d0.25yc64ad0.25yacd0.25y Y2367372c3199c66a6420faf89d0.25vb43<ya3 S0.06666666666666667ya4 S0.06666666666666667ya8 S0.06666666666666667ya9 S0.06666666666666667yc641 S0.06666666666666667yba5 S0.06666666666666667ybb2 S0.06666666666666667ybee S0.06666666666666667yae S0.13333333333333333yc10d S0.06666666666666667ybdb S0.06666666666666667yaf S0.06666666666666667yh888217ab S0.06666666666666667ycecc S0.06666666666666667>vb44<ya0 S0.07142857142857142ya1 S0.07142857142857142ya2 S0.07142857142857142yc892 S0.07142857142857142ybc6 S0.07142857142857142ybfc S0.07142857142857142yd88bd S0.07142857142857142yc57a S0.07142857142857142yae S0.07142857142857142ye57ddf S0.07142857142857142yc22e S0.07142857142857142ybeb S0.07142857142857142ycbef S0.07142857142857142yac S0.07142857142857142>vb45<ya3 S0.07692307692307693yb42 S0.07692307692307693yc418 S0.07692307692307693yc601 S0.07692307692307693yda46c S0.07692307692307693yad S0.15384615384615385yc03a S0.07692307692307693yaa S0.07692307692307693yd26bc S0.07692307692307693yd0096 S0.07692307692307693ybfe S0.07692307692307693yc83a S0.07692307692307693>vb46:ya1c0.1ya3c0.1ya5c0.1ya6c0.1ygb16bdddc0.1yaac0.1yadc0.1yaec0.1yafc0.1y Q4136446bebe7ffbc7c0.1vb476ya1 S0.16666666666666666yd5132 S0.16666666666666666yd188c S0.16666666666666666ybee S0.16666666666666666yaa S0.16666666666666666y T6752dfce5a0235354070 S0.16666666666666666vb48<ya1 S0.07692307692307693ya3 S0.07692307692307693ya5 S0.07692307692307693ya9 S0.07692307692307693yc127 S0.07692307692307693ybde S0.07692307692307693yc37d S0.07692307692307693ycfae S0.07692307692307693yh011687eb S0.07692307692307693ybeb S0.07692307692307693yaa S0.07692307692307693ycfcb S0.07692307692307693yc89e S0.07692307692307693>vb491y `c377351433a941a927aab543931f6026Qvb508ya7e0.125yc656e0.125yc897e0.125yf15932ae0.125yafe0.125yeacface0.125yade0.125yl27766eadc9e2e0.125vb519ya0 R0.1111111111111111ybb2 R0.1111111111111111ybc4 R0.1111111111111111ybcf R0.1111111111111111ybfb R0.1111111111111111yc96d R0.1111111111111111yc02d R0.1111111111111111yc37f R0.1111111111111111yn03668caaecbc57 R0.1111111111111111vb529ya3 R0.1111111111111111yd9927 R0.1111111111111111ydd08a R0.1111111111111111ycfdc R0.1111111111111111yc040 R0.1111111111111111yebbbdd R0.1111111111111111yc81c R0.1111111111111111ybce R0.1111111111111111yg296318c R0.1111111111111111vb53<ya2 S0.07692307692307693ya6 S0.07692307692307693ya7 S0.07692307692307693ya9 S0.07692307692307693yc231 S0.07692307692307693ye827de S0.07692307692307693yad S0.15384615384615385yaa S0.07692307692307693yaf S0.07692307692307693ycbcb S0.07692307692307693ye44caf S0.07692307692307693yh35896c1f S0.07692307692307693>vb54<ya0e0.125ya1 T0.041666666666666664ya2 T0.041666666666666664ya4 T0.041666666666666664ya5 T0.041666666666666664ya6 T0.041666666666666664ya8 T0.041666666666666664ya9 T0.041666666666666664yc351 T0.041666666666666664yb3c T0.041666666666666664yad S0.16666666666666666yaee0.125ybfb T0.041666666666666664yc33e T0.041666666666666664yab T0.041666666666666664yc43c T0.041666666666666664yaf T0.041666666666666664>vb559ya2 R0.1111111111111111yc349 R0.1111111111111111yd5824 R0.1111111111111111ybeb R0.1111111111111111yaa R0.1111111111111111yae R0.1111111111111111yf03996c R0.1111111111111111yg1966bee R0.1111111111111111yg38866ce R0.1111111111111111vb56<ya3 S0.08333333333333333ya8 S0.08333333333333333yc482 S0.08333333333333333yc616 S0.08333333333333333yd6193 S0.08333333333333333ye37912 S0.08333333333333333yff5effd S0.08333333333333333yaa S0.08333333333333333yaf S0.08333333333333333ybdb S0.08333333333333333yab S0.08333333333333333ydcaec S0.08333333333333333>vb577yc188 S0.14285714285714285yd5758 S0.14285714285714285yc11a S0.14285714285714285yf61827e S0.14285714285714285yf80739a S0.14285714285714285yi6065960eb S0.14285714285714285yad S0.14285714285714285vb585yc845c0.2yc9dac0.2ybcdc0.2yf31310bc0.2y R8952efd1be1881e651c0.2vb59<ya8 S0.07692307692307693yc521 S0.07692307692307693yc813 S0.07692307692307693yc880 S0.07692307692307693yd7730 S0.07692307692307693yd208a S0.07692307692307693yac S0.15384615384615385yc072 S0.07692307692307693ybea S0.07692307692307693yab S0.07692307692307693yd86ca S0.07692307692307693ybeb S0.07692307692307693>vb60<ya2 S0.10526315789473684ya3 S0.05263157894736842ya4 S0.05263157894736842ya5 S0.10526315789473684ya8 S0.05263157894736842yc501 S0.05263157894736842ybe5 S0.05263157894736842ybcb S0.05263157894736842yae S0.05263157894736842yad S0.15789473684210525ybdb S0.10526315789473684yaf S0.05263157894736842yf14984a S0.05263157894736842yc66d S0.05263157894736842>vb61<ya0d0.05ya1d0.05ya2d0.05ya3d0.05ya5c0.1ya6d0.05yc801d0.05yc888d0.05yd2824d0.05ycbbdd0.05ybffd0.05yadd0.05yabd0.05ybbbd0.05yafd0.05ybdad0.05yaad0.15>vb62<ya5 S0.14285714285714285yb92 S0.07142857142857142yc321 S0.07142857142857142yc843 S0.07142857142857142yd5955 S0.07142857142857142yc8a1 S0.07142857142857142ybea S0.07142857142857142yad S0.07142857142857142ybcf S0.07142857142857142ybbc S0.07142857142857142yaa S0.07142857142857142yf94cfcc S0.07142857142857142yae S0.07142857142857142>vb639ya4c0.1ya8c0.1yc115c0.1yc617c0.1yc82ac0.1ybabc0.1yadc0.1yaec0.2y P96813587fe3a6049c0.1vb642yde74dc0.5y \071363645a588f858b35231128c4c0.5vb651y `163beeae9620c1a6a46a38aa7ebd9663Qvb668ya0e0.125ya3e0.125yd36dde0.125yf94159ee0.125yaee0.125yf60076ce0.125yace0.125yl6098086e255fe0.125vb67:yb66c0.1yc309c0.1yc435c0.1yf21982fc0.1yd43bcc0.1yafc0.1yf22efefc0.1yc22bc0.1yaac0.1yc48cc0.1vb682yg306cecbc0.5y Y32320ead508346ad8fed3394dc0.5vb69;yc220 S0.09090909090909091yc804 S0.09090909090909091yc934 S0.09090909090909091yc941 S0.09090909090909091yb1e S0.09090909090909091yaa S0.09090909090909091yae S0.09090909090909091yd16fd S0.09090909090909091ybbd S0.09090909090909091ybca S0.09090909090909091yh03865b60 S0.09090909090909091vb70:ya2c0.1yc417c0.1yc538c0.1yc607c0.1yg09155bfc0.1yaac0.1yf93847bc0.1ybadc0.1yafc0.1ye78ccac0.1vb71:ya6c0.1ya7c0.1yc914c0.1ydc098c0.1yacc0.1yafc0.1yi0901979bdc0.1ybedc0.1yaac0.1yi345200f90c0.1vb724yd3270d0.25yb2cd0.25yafd0.25y Y8797ace2fb37402ea6a09d126d0.25vb73<ya1 S0.13333333333333333ya2 S0.13333333333333333yb63 S0.06666666666666667yc443 S0.06666666666666667yd44db S0.06666666666666667yaf S0.13333333333333333ydfefc S0.06666666666666667yd97cd S0.06666666666666667yc28d S0.06666666666666667yc55d S0.06666666666666667ybbd S0.06666666666666667yab S0.06666666666666667>vb74<ya0d0.05ya1d0.05ya2d0.05ya3d0.05ya7d0.05ya8d0.15yb4dd0.05yc71dd0.05yaad0.05yc23cd0.05yd85fbd0.05ybafd0.05yc20ed0.05yadd0.05yaec0.1yabd0.05ybded0.05>vb75<ya2 S0.07142857142857142ya3 S0.14285714285714285ya6 S0.07142857142857142ya7 S0.07142857142857142yh45353291 S0.07142857142857142ybbe S0.07142857142857142yac S0.07142857142857142yd49ea S0.07142857142857142ye5816e S0.07142857142857142ycdaa S0.07142857142857142yad S0.07142857142857142yab S0.07142857142857142ybff S0.07142857142857142>vb76:ya2c0.1yc177c0.1yc861c0.1yd6978c0.1yf15357bc0.1yaec0.1ye83daac0.1yadc0.1yf97692cc0.1ybdcc0.1vb774ydf488d0.25ybaad0.25yc62dd0.25y W39194824861a134567cadb8d0.25vb78;ya0 S0.09090909090909091yc389 S0.09090909090909091yc687 S0.09090909090909091yb9a S0.09090909090909091ydbabb S0.09090909090909091yaf S0.09090909090909091yd44db S0.09090909090909091yd51dc S0.09090909090909091yab S0.09090909090909091yf75bdaa S0.09090909090909091yc19d S0.09090909090909091vb792ybdcc0.5y ^9580308938069159c5afc55b2f3b96c0.5vb80;ya5 S0.08333333333333333ya9 S0.08333333333333333yc470 S0.08333333333333333ye4fbdc S0.08333333333333333yac S0.16666666666666666yc57a S0.08333333333333333yg37781dc S0.08333333333333333ybdd S0.08333333333333333yc86f S0.08333333333333333yc61d S0.08333333333333333yb04 S0.08333333333333333vb81<ya0 S0.07142857142857142ya3 S0.07142857142857142ya4 S0.07142857142857142ya7 S0.07142857142857142yc415 S0.07142857142857142yd6fbf S0.07142857142857142yac S0.07142857142857142yad S0.07142857142857142yaf S0.14285714285714285yc89e S0.07142857142857142yae S0.07142857142857142ye89cec S0.07142857142857142yh28811a94 S0.07142857142857142>vb824ya9d0.25yb8dd0.25yacd0.25y \3760395e8e0eb40e335b22750b68d0.25vb83<ya3 S0.07692307692307693yc431 S0.07692307692307693yc626 S0.07692307692307693yc866 S0.07692307692307693yc915 S0.07692307692307693yb3f S0.07692307692307693ybbf S0.07692307692307693yd71ee S0.07692307692307693yaf S0.15384615384615385ycdaf S0.07692307692307693yd42bc S0.07692307692307693ybfa S0.07692307692307693>vb84<ya0 T0.058823529411764705ya1 T0.058823529411764705ya5 T0.058823529411764705ya7 S0.11764705882352941yc258 T0.058823529411764705yc966 T0.058823529411764705ye7fded T0.058823529411764705yd0345 T0.058823529411764705yac S0.17647058823529413yceea T0.058823529411764705yab S0.11764705882352941ybee T0.058823529411764705ybaa T0.058823529411764705>vb85<ya0 S0.05263157894736842ya4 S0.10526315789473684ya5 S0.15789473684210525ya9 S0.05263157894736842yba7 S0.05263157894736842yaf S0.15789473684210525yae S0.10526315789473684yf85fcad S0.05263157894736842ybbc S0.05263157894736842ybae S0.05263157894736842yac S0.05263157894736842yc18c S0.05263157894736842yd10de S0.05263157894736842>vb864ya5d0.25yc48bd0.25ybabd0.25y Z9805919736382ffea5a9554c02d0.25vb87<ya7 S0.07692307692307693yb55 S0.07692307692307693yc257 S0.07692307692307693yc779 S0.07692307692307693yd3737 S0.07692307692307693ybc9 S0.07692307692307693yad S0.07692307692307693ycaba S0.07692307692307693yf54475c S0.07692307692307693yc20b S0.07692307692307693ybce S0.07692307692307693yac S0.07692307692307693yae S0.07692307692307693>vb88<ya1 S0.07142857142857142ya8 S0.07142857142857142yc122 S0.07142857142857142yc314 S0.07142857142857142yc780 S0.07142857142857142yc785 S0.07142857142857142yb6f S0.07142857142857142yd47cb S0.07142857142857142ybfd S0.07142857142857142yac S0.07142857142857142ycadb S0.07142857142857142ybcc S0.07142857142857142yaf S0.07142857142857142yc44f S0.07142857142857142>vb89<ya2 S0.05555555555555555ya6 R0.1111111111111111ya7 S0.05555555555555555yc150 S0.05555555555555555yc219 S0.05555555555555555yc388 S0.05555555555555555ydd710 S0.05555555555555555yaa R0.2222222222222222yc073 S0.05555555555555555ybbe S0.05555555555555555ybda S0.05555555555555555ybeb S0.05555555555555555yab R0.1111111111111111>vb90<ya0f0.0625ya3e0.125ya9e0.125yc979f0.0625ye74933f0.0625yd71cff0.0625yd83aef0.0625yafe0.125yc45ef0.0625ycedef0.0625yaaf0.0625yabf0.0625yacf0.0625>vb91<ya0 S0.09523809523809523ya2 T0.047619047619047616ya3 T0.047619047619047616ya6 S0.09523809523809523ya9 S0.09523809523809523yc362 T0.047619047619047616yc935 T0.047619047619047616ycdaa T0.047619047619047616ybfe T0.047619047619047616yab S0.09523809523809523ybbe T0.047619047619047616yaf T0.047619047619047616yc31b T0.047619047619047616ybad T0.047619047619047616yae T0.047619047619047616yad S0.09523809523809523>vb92<ya4 T0.058823529411764705ya6 T0.058823529411764705ya7 S0.11764705882352941ya8 S0.11764705882352941yc399 T0.058823529411764705yd9679 T0.058823529411764705ybef T0.058823529411764705yaa T0.058823529411764705yac S0.11764705882352941ybce T0.058823529411764705yae T0.058823529411764705ye9710c T0.058823529411764705ycecf T0.058823529411764705ycbcc T0.058823529411764705>vb931y `c3053579ae25e2fb9b967076a06373afQvb94<ya5 S0.08333333333333333ya6 S0.08333333333333333yc482 S0.08333333333333333yb7b S0.08333333333333333yc080 S0.08333333333333333ybdc S0.08333333333333333ye43fce S0.08333333333333333ybaf S0.08333333333333333yd14de S0.08333333333333333yc61c S0.08333333333333333ybab S0.08333333333333333yd819a S0.08333333333333333>vb952yc90fc0.5y ]9355781403b92e844de8568863ae8c0.5vb96:ya0 S0.15384615384615385ya8 S0.15384615384615385yc508 S0.07692307692307693yf7fcfaa S0.07692307692307693ybdd S0.07692307692307693ye34dbd S0.07692307692307693yaf S0.15384615384615385yc19e S0.07692307692307693ybca S0.07692307692307693yefcfda S0.07692307692307693vb976ya3 S0.16666666666666666ya5 S0.16666666666666666ydc61a S0.16666666666666666ycbda S0.16666666666666666yaf S0.16666666666666666y V1667498626ae52ad0362e0 S0.16666666666666666vb98<ya3 S0.06666666666666667ya7 S0.13333333333333333yc152 S0.06666666666666667yc459 S0.13333333333333333yfd9018f S0.06666666666666667yad S0.06666666666666667yac S0.06666666666666667yc94a S0.06666666666666667yc91e S0.06666666666666667yc92b S0.06666666666666667yae S0.13333333333333333yaf S0.06666666666666667>vb99<ya3f0.0625ya4f0.0625ya5f0.0625ya9f0.0625yb25f0.0625yc535f0.0625yc99cf0.0625yace0.125yc80af0.0625ye6532ef0.0625ybeaf0.0625yabf0.0625yaaf0.0625yc92df0.0625yc07af0.0625>vc100<ya3 S0.08333333333333333ya6 S0.08333333333333333yc365 S0.08333333333333333yc813 S0.08333333333333333yh21590549 S0.08333333333333333yd018b S0.08333333333333333yab S0.08333333333333333yd00dd S0.08333333333333333yaa S0.08333333333333333ybad S0.08333333333333333yc17c S0.08333333333333333yad S0.08333333333333333>vc1019ya0 R0.1111111111111111ya3 R0.1111111111111111ya4 R0.1111111111111111yea65bd R0.1111111111111111yc31d R0.1111111111111111yac R0.1111111111111111ycdab R0.1111111111111111yaa R0.1111111111111111y P41712823a5d6002b R0.1111111111111111vc102<ya4e0.125ya8f0.0625ya9f0.0625yc299f0.0625yc886f0.0625yd2561f0.0625yb3cf0.0625yaaf0.0625yadf0.0625yd77bef0.0625yabf0.0625yaff0.0625ybcef0.0625ycfcdf0.0625yc23af0.0625>vc103;ya7 S0.09090909090909091ya9 S0.09090909090909091yc407 S0.09090909090909091yc936 S0.09090909090909091yi431816573 S0.09090909090909091yd35aa S0.09090909090909091yae S0.09090909090909091yd09db S0.09090909090909091ycaee S0.09090909090909091ybec S0.09090909090909091yac S0.09090909090909091vc104<ya1 S0.08333333333333333ya8 S0.08333333333333333yc356 S0.08333333333333333yb1a S0.08333333333333333yaa S0.08333333333333333ybcc S0.08333333333333333yd0040 S0.08333333333333333yab S0.08333333333333333yad S0.08333333333333333yf06eacd S0.08333333333333333yc22e S0.08333333333333333yg0526476 S0.08333333333333333>vc1054ya8d0.25yc80cd0.25ycfcad0.25y Y02ebfecc7a931dad1ec38466ed0.25vc1063ybf3 R0.3333333333333333ybef R0.3333333333333333y \819656f68b87a91c53afbd441fec R0.3333333333333333vc107<ya0 S0.07692307692307693ya5 S0.07692307692307693ya6 S0.07692307692307693yc586 S0.07692307692307693yh25492340 S0.07692307692307693yd1abc S0.07692307692307693yad S0.07692307692307693yc67f S0.07692307692307693yab S0.07692307692307693yac S0.07692307692307693yd05fd S0.07692307692307693yae S0.07692307692307693yc60f S0.07692307692307693>vc1085ya2c0.2yd1bbfc0.2ybefc0.2yc67fc0.2y V096960e13d8578fa544536c0.2vc109<ya2f0.0625ya6e0.125ya7f0.0625ya8f0.0625yc932f0.0625yd5495f0.0625ybc2f0.0625ydd39ff0.0625yaff0.0625ybfef0.0625ybcbf0.0625yd69fcf0.0625ycefbf0.0625yace0.125>vc110<ya2 S0.08333333333333333ya3 S0.08333333333333333yc791 S0.08333333333333333yd78da S0.08333333333333333yc47d S0.08333333333333333yc61c S0.08333333333333333yc91c S0.08333333333333333yf82809a S0.08333333333333333yac S0.08333333333333333yc97a S0.08333333333333333yad S0.08333333333333333yc26d S0.08333333333333333>vc1118ya3e0.125yc536e0.125yc11be0.125yaae0.125yc28be0.125yafe0.125yc34de0.125y Q3606427f835bd3ddfe0.125vc1122ygd8041aec0.5y Y308961666b15aa1e57b0f9f35c0.5vc1133ydd96f R0.3333333333333333yc80f R0.3333333333333333y Y23543850a2ee9fff8cd2cc53f R0.3333333333333333vc1149ya3 R0.1111111111111111yd1841 R0.1111111111111111yd538e R0.1111111111111111ye38fbc R0.1111111111111111yaf R0.1111111111111111yd78cd R0.1111111111111111yc61e R0.1111111111111111yad R0.1111111111111111yi8141ddcc1 R0.1111111111111111vc1151y `b27bdabd8e1a6b7dc06886867331ceb3Qvc116;ya1 S0.08333333333333333ya5 S0.16666666666666666yc226 S0.08333333333333333yd5756 S0.08333333333333333yb6c S0.08333333333333333ybee S0.08333333333333333yg1519fbf S0.08333333333333333yh910197cc S0.08333333333333333yad S0.08333333333333333yac S0.08333333333333333yaa S0.08333333333333333vc117<ya0 S0.06666666666666667ya1 S0.06666666666666667ya2 S0.06666666666666667ya9 S0.06666666666666667yc990 S0.06666666666666667ybee S0.06666666666666667yd62cb S0.06666666666666667yab S0.06666666666666667yaa S0.13333333333333333yc97f S0.06666666666666667ybdf S0.06666666666666667ybed S0.06666666666666667yd0266 S0.06666666666666667ye7027e S0.06666666666666667>vc1183ybba R0.3333333333333333ye45ddd R0.3333333333333333y Y3042dad59a12e5937644f7246 R0.3333333333333333vc1192yc3fdc0.5y ]9052870778e14ab4a5acbc8c24af4c0.5vc120:yc943 S0.09090909090909091yd8883 S0.09090909090909091yd9066 S0.09090909090909091ybd3 S0.09090909090909091ybfa S0.09090909090909091yc23c S0.09090909090909091yaf S0.18181818181818182yc10e S0.09090909090909091ybde S0.09090909090909091yg9340dea S0.09090909090909091vc121;ya6 S0.08333333333333333ya9 S0.16666666666666666yd8534 S0.08333333333333333yd10ae S0.08333333333333333yc016 S0.08333333333333333yae S0.08333333333333333ye19fff S0.08333333333333333ybae S0.08333333333333333yecfaeb S0.08333333333333333ybfa S0.08333333333333333yc47f S0.08333333333333333vc1229ya0 R0.1111111111111111yc818 R0.1111111111111111yd2915 R0.1111111111111111yc04d R0.1111111111111111yecbaac R0.1111111111111111yc08b R0.1111111111111111ybdb R0.1111111111111111yc15e R0.1111111111111111yhbffdcb5b R0.1111111111111111vc123<ya4 S0.14285714285714285ya6 S0.07142857142857142yc410 S0.07142857142857142yc638 S0.07142857142857142yc8cc S0.07142857142857142yab S0.07142857142857142yd19cd S0.07142857142857142yae S0.07142857142857142yaf S0.14285714285714285ydbeaf S0.07142857142857142ye1642f S0.07142857142857142yc52a S0.07142857142857142>vc1241y `d791eaca9375ca1b36a987af22ee71ddQvc1251y `e6684944c37dbdd4c08d978af9e47bedQvc1269ya1 R0.1111111111111111yc459 R0.1111111111111111yc970 R0.1111111111111111ycbbe R0.1111111111111111yddeec R0.1111111111111111yc11d R0.1111111111111111ycbdb R0.1111111111111111yg348051b R0.1111111111111111yeabdaf R0.1111111111111111vc1277yd3829 S0.14285714285714285yda673 S0.14285714285714285yab S0.14285714285714285yae S0.14285714285714285yf62477e S0.14285714285714285ye01abc S0.14285714285714285yk75465416b86 S0.14285714285714285vc128<ya1 S0.07142857142857142ya5 S0.07142857142857142ya6 S0.07142857142857142yc177 S0.07142857142857142yd9767 S0.07142857142857142yc7b6 S0.07142857142857142ybcb S0.07142857142857142yc59a S0.07142857142857142ycabe S0.07142857142857142ybfd S0.07142857142857142yd22da S0.07142857142857142yaa S0.07142857142857142yc03b S0.07142857142857142yae S0.07142857142857142>vc129<ya1 S0.07142857142857142ya3 S0.07142857142857142ya4 S0.07142857142857142ya6 S0.07142857142857142ya7 S0.07142857142857142yf552660 S0.07142857142857142ye4afcb S0.07142857142857142yc20d S0.07142857142857142yad S0.07142857142857142ye95bcd S0.07142857142857142ycbde S0.07142857142857142ybaa S0.07142857142857142yab S0.07142857142857142yaf S0.07142857142857142>vc130:ya1 S0.08333333333333333ya9 S0.16666666666666666yc782 S0.08333333333333333yb7c S0.08333333333333333yc21b S0.08333333333333333yc70f S0.08333333333333333yae S0.08333333333333333yac S0.16666666666666666yaf S0.08333333333333333yn5153268e0cc1c1 S0.08333333333333333vc131<ya0d0.05ya4c0.1ya7d0.05ya9c0.1yc552d0.05yc931d0.05ybf3d0.05yaac0.1yabc0.1yafd0.15ycdfad0.05yd61ced0.05yc39fd0.05yaed0.05>vc1322ybfac0.5y ^0486610d8a02cea245c13c85b6de27c0.5vc133:ya2c0.1yd9504c0.1ydc20dc0.1yf71627ec0.1yc66ac0.1yc044c0.1yabc0.1yf21780fc0.1yc56fc0.1yafc0.1vc1345ya3c0.2yb4fc0.2yc88fc0.2ydeebec0.2y V44285ded812939553ef94cc0.2vc1359ya2 R0.1111111111111111ya4 R0.1111111111111111ya5 R0.1111111111111111yc29b R0.1111111111111111yac R0.1111111111111111yab R0.1111111111111111ydadcd R0.1111111111111111ye80ced R0.1111111111111111yo1612128b3ca95a9 R0.1111111111111111vc1362yc16fc0.5y ]1046144ad9ee7bb96214ba7ae7516c0.5vc1379ya4 R0.1111111111111111yc980 R0.1111111111111111yd002d R0.1111111111111111yad R0.1111111111111111yc74d R0.1111111111111111yc19b R0.1111111111111111yd43ff R0.1111111111111111yae R0.1111111111111111yl2446665e2fe5 R0.1111111111111111vc1381y `550becdd08d00fb1e7fd00c2adc3d3d6Qvc139<ya1 S0.07142857142857142ya3 S0.07142857142857142ya5 S0.07142857142857142ya6 S0.07142857142857142yc292 S0.07142857142857142yha62186ea S0.07142857142857142yad S0.07142857142857142ybdb S0.07142857142857142yc03a S0.07142857142857142yc087 S0.07142857142857142ybbd S0.07142857142857142yddfcc S0.07142857142857142yaf S0.07142857142857142yae S0.07142857142857142>vc140<ya2 S0.08333333333333333ya3 S0.08333333333333333yc198 S0.08333333333333333yd6833 S0.08333333333333333yd167e S0.08333333333333333yaa S0.08333333333333333yad S0.08333333333333333yd49ce S0.08333333333333333ybcb S0.08333333333333333yab S0.08333333333333333yc88f S0.08333333333333333yg521991e S0.08333333333333333>vc141;ya2 S0.09090909090909091ya7 S0.09090909090909091yc289 S0.09090909090909091yc464 S0.09090909090909091yd993e S0.09090909090909091yc58f S0.09090909090909091yg132740b S0.09090909090909091ycecf S0.09090909090909091yd06ee S0.09090909090909091ybdc S0.09090909090909091yab S0.09090909090909091vc142<ya1 S0.06666666666666667ya2 S0.06666666666666667ya8 S0.13333333333333333yc604 S0.06666666666666667ydc56a S0.06666666666666667yd76ef S0.06666666666666667yaf S0.13333333333333333yaa S0.13333333333333333yad S0.06666666666666667yd87be S0.06666666666666667yc32b S0.06666666666666667ye81fac S0.06666666666666667>vc1435yd7462c0.2yc3fcc0.2yaac0.2yd83fac0.2y T55885067fee629287e8ac0.2vc144<ya0 S0.05555555555555555ya1 S0.05555555555555555ya7 S0.05555555555555555ya8 S0.16666666666666666ya9 S0.05555555555555555yc409 S0.05555555555555555yb4b S0.05555555555555555yaa S0.05555555555555555yh768585da S0.05555555555555555yaf S0.16666666666666666ybdb S0.05555555555555555ybca S0.05555555555555555yae S0.05555555555555555ycebd S0.05555555555555555>vc1451y `c54909ecf4fb3e9afeea36200fe95dceQvc1469ya0c0.1ya6c0.1ya9c0.1ygd819ceac0.1ye5197ec0.1yabc0.2ye8673dc0.1yacc0.1yi16659a5eac0.1vc1472yb1bc0.5y ^56132638912a1ca54fcf7cd38b8e23c0.5vc1489ya1c0.2yd4502c0.1yc2eac0.1yd86aec0.1yi5093670dfc0.1yadc0.1ybeac0.1ye82efac0.1ybacc0.1vc1491y `5912529cfd6ce14c5ede5c6c83dae7e8Qvc1501y `15700442e957951307bbcec5fff8643dQvc1513yd018e R0.3333333333333333yc32a R0.3333333333333333y Y8010960eb17e368a6fdd5a51b R0.3333333333333333vc152;ya1 S0.08333333333333333ya3 S0.08333333333333333ya9 S0.08333333333333333yde159 S0.08333333333333333yaa S0.16666666666666666yc35d S0.08333333333333333yab S0.08333333333333333yc46e S0.08333333333333333yf03072a S0.08333333333333333yad S0.08333333333333333yi54780edcb S0.08333333333333333vc153:ya1c0.1ya2c0.1yc505c0.1ybccc0.1yc64cc0.1ygfcdecdbc0.1yabc0.1ye3797ec0.1ydaaaac0.1ye59adcc0.1vc154:ya0c0.1ya5c0.1yc4ccc0.1yd08cac0.1ye51ecfc0.1yafc0.1yg963035fc0.1yc039c0.1ybdec0.1ye6194cc0.1vc1555yc227c0.2yb4bc0.2yadc0.2yc61fc0.2y W33182579cd3edd0ac6c7c44c0.2vc156<ya0 S0.15384615384615385ya2 S0.07692307692307693ya9 S0.07692307692307693yd1739 S0.07692307692307693yc0de S0.07692307692307693ydedbf S0.07692307692307693yaa S0.07692307692307693yg506143c S0.07692307692307693yab S0.07692307692307693yc12e S0.07692307692307693yc94c S0.07692307692307693ybef S0.07692307692307693>vc1571y `744554499cb7880086fbd9b1f080e7e1Qvc1588ya4e0.125ya9e0.125yc950e0.125yb5ae0.125yaee0.125yafe0.125ybace0.125y U186925e5de978c5f72062e0.125vc159<ya0 S0.08333333333333333ya5 S0.08333333333333333ya8 S0.08333333333333333yd8194 S0.08333333333333333ye18500 S0.08333333333333333yc73b S0.08333333333333333ybad S0.08333333333333333ycfce S0.08333333333333333ydcabb S0.08333333333333333yd01cd S0.08333333333333333yc21d S0.08333333333333333yae S0.08333333333333333>vc1608ya0c0.2ya7c0.1yd100cc0.1yaac0.1ye69beac0.1yafc0.2yc02ac0.1yn4540ecaa37d0e3c0.1vc1614yc891d0.25yg809925ed0.25yabd0.25y U0456231c374b09cbe4a90d0.25vc162<ya6 S0.13333333333333333ya8 S0.06666666666666667ya9 S0.06666666666666667yc671 S0.06666666666666667yc722 S0.06666666666666667ybdd S0.06666666666666667yac S0.13333333333333333yc32a S0.06666666666666667ybdc S0.06666666666666667yh815273cd S0.06666666666666667ybed S0.06666666666666667ybcd S0.06666666666666667yab S0.06666666666666667>vc1638ya4c0.2ya8c0.1ya9c0.1ybeec0.1ybffc0.1yaec0.2yaac0.1y U1948795e26af2f3f8a30fc0.1vc164:ya1 S0.16666666666666666yc208 S0.08333333333333333yc351 S0.08333333333333333yc801 S0.08333333333333333ydf887 S0.08333333333333333yae S0.16666666666666666ydaabf S0.08333333333333333ycbfb S0.08333333333333333yf39698f S0.08333333333333333ybaf S0.08333333333333333vc165:ya0c0.1ya2c0.1ya6c0.1ya8c0.1yc9ccc0.1yaac0.1yabc0.1yacc0.1ybbec0.1y T1405cddcdeb4487c59fec0.1vc1664yd7998d0.25yc18bd0.25yaad0.25y X871950ebc36c415a53630477d0.25vc167;ya0 S0.08333333333333333yc522 S0.08333333333333333yc956 S0.08333333333333333yd6357 S0.08333333333333333yd7669 S0.08333333333333333ye83454 S0.08333333333333333ydddab S0.08333333333333333ybff S0.08333333333333333yac S0.16666666666666666ycebd S0.08333333333333333yae S0.08333333333333333vc1684yc318d0.25yf55188ad0.25yacd0.25y V5998989255253e15ccc1f6d0.25vc1698yc389 R0.1111111111111111yc605 R0.1111111111111111yd7787 R0.1111111111111111yc75d R0.1111111111111111yi9268739fe R0.1111111111111111ybac R0.2222222222222222yc02d R0.1111111111111111ycfeb R0.1111111111111111vc1705yc23ac0.2yc22dc0.2yg1411afbc0.2yg787810dc0.2yl68210e6fad4fc0.2vc171<ya1 S0.07142857142857142ya2 S0.07142857142857142ya4 S0.07142857142857142ya6 S0.07142857142857142ya8 S0.07142857142857142ye615db S0.07142857142857142yaa S0.07142857142857142yc24f S0.07142857142857142yc36d S0.07142857142857142yc19a S0.07142857142857142yceaf S0.07142857142857142yc18d S0.07142857142857142yedceed S0.07142857142857142yab S0.07142857142857142>vc172<ya1 S0.07692307692307693ya2 S0.07692307692307693ya3 S0.07692307692307693ya7 S0.07692307692307693yb40 S0.07692307692307693yf8d7caf S0.07692307692307693yc84b S0.07692307692307693yaa S0.07692307692307693ye51cca S0.07692307692307693yf27291c S0.07692307692307693yaf S0.07692307692307693yccfc S0.07692307692307693yad S0.07692307692307693>vc1731y `7249710187cc2d983709e044dbc78d9dQvc1744yg563864ad0.25yg949924cd0.25yg505985ad0.25yk168191dcb84d0.25vc175;ya1 S0.16666666666666666ya6 S0.08333333333333333yc145 S0.08333333333333333yc869 S0.08333333333333333yg24357fe S0.08333333333333333yac S0.08333333333333333ybec S0.08333333333333333yf82fdfc S0.08333333333333333ye8134a S0.08333333333333333yaa S0.08333333333333333yad S0.08333333333333333vc176;ya5 S0.09090909090909091ya7 S0.09090909090909091ya9 S0.09090909090909091yc703 S0.09090909090909091yg19ecbaa S0.09090909090909091yae S0.09090909090909091yc12f S0.09090909090909091yaa S0.09090909090909091yeebcff S0.09090909090909091yac S0.09090909090909091yh79534a52 S0.09090909090909091vc177<ya0 S0.05555555555555555ya4 R0.1111111111111111ya8 R0.1111111111111111ya9 S0.05555555555555555yc509 S0.05555555555555555ycced S0.05555555555555555ybdf S0.05555555555555555yad S0.05555555555555555yac R0.1111111111111111ybed S0.05555555555555555yd14de S0.05555555555555555yc91c S0.05555555555555555yab S0.05555555555555555yc31b S0.05555555555555555ybae S0.05555555555555555>vc178<ya4 S0.06666666666666667ya7 S0.06666666666666667ya8 S0.06666666666666667yc466 S0.06666666666666667ybcb S0.06666666666666667yc13b S0.06666666666666667yc64d S0.06666666666666667yd0127 S0.06666666666666667yac S0.13333333333333333yd13bb S0.06666666666666667yad S0.06666666666666667ye4677a S0.06666666666666667yab S0.06666666666666667yaa S0.06666666666666667>vc179<ya2 S0.06666666666666667ya4 S0.06666666666666667ya5 S0.13333333333333333ya6 S0.06666666666666667ya8 S0.06666666666666667yef2cbe S0.06666666666666667yd07bf S0.06666666666666667ybff S0.06666666666666667yc16d S0.06666666666666667yaa S0.06666666666666667ye5860b S0.06666666666666667yad S0.06666666666666667ydedbc S0.06666666666666667yae S0.06666666666666667>vc180<ya3 S0.08333333333333333ya5 S0.08333333333333333yc459 S0.08333333333333333yceee S0.08333333333333333yc039 S0.08333333333333333yaf S0.08333333333333333yc49a S0.08333333333333333yab S0.08333333333333333yh570599cf S0.08333333333333333yac S0.08333333333333333yc55c S0.08333333333333333yd649f S0.08333333333333333>vc181<ya3 S0.06666666666666667ya4 S0.06666666666666667ya6 S0.13333333333333333yc298 S0.06666666666666667yc888 S0.06666666666666667ycddd S0.06666666666666667yae S0.13333333333333333yaf S0.06666666666666667yad S0.13333333333333333yg3884abc S0.06666666666666667yaa S0.06666666666666667yf043664 S0.06666666666666667>vc182<ya0 S0.15384615384615385ya2 S0.07692307692307693ya4 S0.07692307692307693yb5b S0.07692307692307693ye97ead S0.07692307692307693yc91c S0.07692307692307693ybdd S0.07692307692307693ycbad S0.07692307692307693yc57b S0.07692307692307693yaf S0.07692307692307693yc43a S0.07692307692307693yf89149a S0.07692307692307693>vc183;ya7 S0.09090909090909091yc135 S0.09090909090909091yc432 S0.09090909090909091yf997acc S0.09090909090909091yad S0.09090909090909091yc01b S0.09090909090909091yc54f S0.09090909090909091ybde S0.09090909090909091yc77a S0.09090909090909091ybfb S0.09090909090909091ye9133f S0.09090909090909091vc184;ya0 S0.09090909090909091ya7 S0.09090909090909091yd1fed S0.09090909090909091yc22e S0.09090909090909091yc99b S0.09090909090909091yae S0.09090909090909091yc11a S0.09090909090909091yd50eb S0.09090909090909091yab S0.09090909090909091yd92cb S0.09090909090909091yg1644e8a S0.09090909090909091vc185;ya5 S0.07692307692307693ya6 S0.15384615384615385ya7 S0.07692307692307693ya9 S0.07692307692307693ye5badf S0.07692307692307693ye61ecb S0.07692307692307693yecfadd S0.07692307692307693yad S0.07692307692307693ybaf S0.07692307692307693yg58712fa S0.07692307692307693yaf S0.15384615384615385vc186<ya4 S0.07142857142857142ya6 S0.14285714285714285ya9 S0.07142857142857142ybfe S0.07142857142857142ybba S0.07142857142857142yd10cc S0.07142857142857142yac S0.07142857142857142ye9509b S0.07142857142857142yab S0.07142857142857142yc22e S0.07142857142857142yad S0.07142857142857142yc59e S0.07142857142857142yf029775 S0.07142857142857142>vc1871y `b36abffbe5d6a0de73a9968604a1a3f9Qvc1882ybcbc0.5y ^9649eca3dfbd356527ffc88f1dcb94c0.5vc1895yc465c0.2yd7deac0.2ybadc0.2yf52758bc0.2y Q10cbceb08c81d1760c0.2vc190;ya2 S0.09090909090909091ya3 S0.09090909090909091yd6458 S0.09090909090909091ycbce S0.09090909090909091ybfa S0.09090909090909091yaf S0.09090909090909091yc39a S0.09090909090909091yc75e S0.09090909090909091ye2713f S0.09090909090909091yad S0.09090909090909091yh687271a1 S0.09090909090909091vc1911y `e5390751969ab21df280b7591854b89fQvc192;ya0 S0.08333333333333333ya2 S0.08333333333333333yc130 S0.08333333333333333yc657 S0.08333333333333333yf05330c S0.08333333333333333ye3703d S0.08333333333333333yae S0.08333333333333333yac S0.16666666666666666ye96cfe S0.08333333333333333ybab S0.08333333333333333yc33f S0.08333333333333333vc1939ya3c0.1ya5c0.1ya9c0.1yb4ac0.1yacc0.2yc42cc0.1ybacc0.1yd29dbc0.1y P268010bbebf4f579c0.1vc1943yc1bc R0.3333333333333333yf36080b R0.3333333333333333y W2493aab78c26e4f2152542c R0.3333333333333333vc1955yc582c0.2yc2dec0.2yacc0.2ye67fcac0.2y T31500621ecd6d3917a07c0.2vc196<ya0f0.0625ya3f0.0625ya4f0.0625ya8f0.0625ya9f0.0625yc895f0.0625yb0af0.0625yg8183cedf0.0625yaed0.25yabf0.0625yf41286ef0.0625yc54ef0.0625yadf0.0625>vc197<ya5 T0.058823529411764705ya7 T0.058823529411764705ya8 S0.11764705882352941ya9 T0.058823529411764705yc581 T0.058823529411764705yc602 T0.058823529411764705yb4d T0.058823529411764705yaf T0.058823529411764705yae T0.058823529411764705yceee T0.058823529411764705yac T0.058823529411764705ybfd T0.058823529411764705yd21da T0.058823529411764705ybeb T0.058823529411764705yd68df T0.058823529411764705yaa T0.058823529411764705>vc198<ya1f0.0625ya3f0.0625ya4f0.0625ya7f0.0625ya8f0.0625yc399f0.0625yc597f0.0625yd937af0.0625yaaf0.0625yabf0.0625ybfdf0.0625yf32cabaf0.0625yc88af0.0625yace0.125ybbcf0.0625>vc199;ya3 S0.09090909090909091yd1298 S0.09090909090909091yd8412 S0.09090909090909091yb2a S0.09090909090909091ybaa S0.09090909090909091yc50d S0.09090909090909091yf07330f S0.09090909090909091yaf S0.09090909090909091yd0243 S0.09090909090909091ybfa S0.09090909090909091yc79d S0.09090909090909091vc200;ya3 S0.08333333333333333ya7 S0.08333333333333333yd2023 S0.08333333333333333ydd266 S0.08333333333333333yaa S0.16666666666666666yac S0.08333333333333333yc67b S0.08333333333333333yc20c S0.08333333333333333ybbd S0.08333333333333333yf01055b S0.08333333333333333ye223bc S0.08333333333333333vc2012ybbcc0.5y ^2709406a9bb19e8d83a78f81e36244c0.5vc2027yc745 S0.14285714285714285yd8608 S0.14285714285714285yf998eda S0.14285714285714285yad S0.14285714285714285yd07fd S0.14285714285714285yaf S0.14285714285714285ym251138384a0b9 S0.14285714285714285vc203<ya0f0.0625ya1e0.125ya2f0.0625ya7e0.125yc986f0.0625yf853cacf0.0625yafe0.125yade0.125yc90bf0.0625yacf0.0625yaef0.0625yhdcdbbfdef0.0625>vc2041y `4616fbea6a6dbc1074bc3f1016bbc73bQvc2057ya9 S0.14285714285714285yd1863 S0.14285714285714285yhf15702ae S0.14285714285714285yae S0.14285714285714285ye55bad S0.14285714285714285yg42182cf S0.14285714285714285yf18724d S0.14285714285714285vc2064yc965d0.25yc77dd0.25yfafaebdd0.25y T7193badc746d52b4173fd0.25vc207<ya8 S0.07692307692307693ya9 S0.07692307692307693yb86 S0.07692307692307693yc405 S0.07692307692307693yc750 S0.07692307692307693ydbdea S0.07692307692307693yc71d S0.07692307692307693yg64cdfcc S0.07692307692307693yae S0.07692307692307693yc65e S0.07692307692307693ybfe S0.07692307692307693yad S0.07692307692307693yab S0.07692307692307693>vc208<ya1 S0.06666666666666667ya2 S0.06666666666666667ya5 S0.06666666666666667yc605 S0.06666666666666667yc721 S0.06666666666666667yc830 S0.06666666666666667yd6490 S0.06666666666666667yc7cc S0.06666666666666667yae S0.13333333333333333ycfdd S0.06666666666666667yad S0.06666666666666667ycccc S0.06666666666666667yc16f S0.06666666666666667yab S0.06666666666666667>vc209<ya1 S0.07692307692307693ya2 S0.07692307692307693ya4 S0.15384615384615385ya6 S0.07692307692307693ybfb S0.07692307692307693ybda S0.07692307692307693yaa S0.07692307692307693ybed S0.07692307692307693yg74705ad S0.07692307692307693yd98bb S0.07692307692307693yd60ad S0.07692307692307693yebadaf S0.07692307692307693>vc2104yd1821d0.25yb0cd0.25yadd0.25y Y1069578551d0e3c7d9275f16bd0.25vc2114ybe3d0.25yaed0.25yh146469edd0.25y U4318eaa2ffbca3510c054d0.25vc212<ya4 S0.06666666666666667ya6 S0.06666666666666667ya8 S0.13333333333333333yc604 S0.06666666666666667yd6324 S0.06666666666666667yc21a S0.06666666666666667yaec0.2ye9330d S0.06666666666666667yaf S0.06666666666666667yeebade S0.06666666666666667yac S0.06666666666666667yc62b S0.06666666666666667>vc213:ya0 S0.09090909090909091ya1 S0.09090909090909091yc293 S0.09090909090909091yc832 S0.09090909090909091yf40abea S0.09090909090909091yaa S0.18181818181818182yc87a S0.09090909090909091yd64bd S0.09090909090909091ycfad S0.09090909090909091yf69458b S0.09090909090909091vc2147ya5e0.125yd1790e0.125yf916bdae0.125yd59bce0.125ye7621de0.125yacd0.25yj040572a3c0e0.125vc2154ya6d0.25yc5bbd0.25yafd0.25y [8322cdbda7a21e4aecbe04462b7d0.25vc216<ya0 S0.08333333333333333ya8 S0.08333333333333333yc595 S0.08333333333333333yc804 S0.08333333333333333yc825 S0.08333333333333333yga578acf S0.08333333333333333yaa S0.08333333333333333ybce S0.08333333333333333yd95fe S0.08333333333333333yaf S0.08333333333333333yab S0.08333333333333333ye7208f S0.08333333333333333>vc217<ya4 S0.07142857142857142ya6 S0.14285714285714285yd706c S0.07142857142857142yc033 S0.07142857142857142yab S0.14285714285714285ye4483b S0.07142857142857142yad S0.07142857142857142yc062 S0.07142857142857142yc66d S0.07142857142857142yae S0.07142857142857142ybea S0.07142857142857142ye0236a S0.07142857142857142>vc2187ya0 S0.14285714285714285yd7853 S0.14285714285714285yd72df S0.14285714285714285ybbf S0.14285714285714285yae S0.14285714285714285yf05560d S0.14285714285714285yn94208817b83468 S0.14285714285714285vc219<ya3 T0.058823529411764705ya4 S0.11764705882352941ya6 T0.058823529411764705ya7 T0.058823529411764705ya8 T0.058823529411764705yc994 T0.058823529411764705yd91fe T0.058823529411764705yc03f T0.058823529411764705yae S0.17647058823529413yf85cede T0.058823529411764705ybbd T0.058823529411764705yc62f T0.058823529411764705yad T0.058823529411764705yab T0.058823529411764705>vc2205ya5c0.2ybedc0.2yb4fc0.2yaac0.2y Z398056eef1cf6caa90786b340ac0.2vc2212yg2824befc0.5y Y72110575c78aeb979170212b8c0.5vc222<ya0 S0.07692307692307693ya1 S0.07692307692307693yc590 S0.07692307692307693yc823 S0.07692307692307693yd9274 S0.07692307692307693yge396cbf S0.07692307692307693yab S0.07692307692307693yaa S0.15384615384615385yad S0.07692307692307693yd94ee S0.07692307692307693yc43d S0.07692307692307693ybbd S0.07692307692307693>vc223;ya0 S0.08333333333333333ya4 S0.08333333333333333ya5 S0.08333333333333333ya8 S0.08333333333333333yc754 S0.08333333333333333yf50562b S0.08333333333333333yg09417cd S0.08333333333333333yac S0.08333333333333333yaa S0.16666666666666666ye2348a S0.08333333333333333ydaabe S0.08333333333333333vc224:ya1c0.1ya7c0.1ya9c0.1yh65124517c0.1yc76ac0.1ybfbc0.1yafc0.1ye21fdac0.1ydeddbc0.1yf95426bc0.1vc2251y `299abcee56b05b312ed5700f686f79b8Qvc2263yg670744b R0.3333333333333333yh945088de R0.3333333333333333y Q05866864f7d57bee7 R0.3333333333333333vc2271y `c1241374502f200cf9fc49c8d6fb5822Qvc2281y `d51032bef3e7117a94336fea18a3fad7Qvc2296ya2 S0.16666666666666666yi65453a1ae S0.16666666666666666yh403679bd S0.16666666666666666yae S0.16666666666666666yf47398a S0.16666666666666666yg04205ca S0.16666666666666666vc230:ya4c0.1ya5c0.1yd9856c0.1ycabcc0.1ybcac0.1yaac0.1yg61831fdc0.1ybedc0.1yc06bc0.1yh402875d2c0.1vc231<ya1e0.125ya7f0.0625ya9f0.1875yc647f0.0625ye386dcf0.0625yadf0.0625yabf0.0625yaaf0.0625yaff0.0625ye3965ff0.0625ycfbef0.0625yc29cf0.0625ycdfbf0.0625>vc232;ya2 S0.08333333333333333ya7 S0.08333333333333333yc562 S0.08333333333333333yd4581 S0.08333333333333333yd5157 S0.08333333333333333yc9ad S0.08333333333333333yc72c S0.08333333333333333yaa S0.16666666666666666yaf S0.08333333333333333yg21741bd S0.08333333333333333ycdfc S0.08333333333333333vc2332ydf55dc0.5y \33371dcff207fd7d201128df2ea3c0.5vc2344ya7d0.25yd229bd0.25ybfcd0.25y Y784707b1d2c702fbeba080e86d0.25vc235<ya1 S0.07142857142857142ya6 S0.07142857142857142ya7 S0.07142857142857142ya9 S0.07142857142857142yc333 S0.07142857142857142yd4924 S0.07142857142857142yfc98cbc S0.07142857142857142ybfb S0.07142857142857142yad S0.07142857142857142yc95c S0.07142857142857142yac S0.07142857142857142ybfc S0.07142857142857142yab S0.07142857142857142ye0526e S0.07142857142857142>vc236:yb84 S0.09090909090909091yc252 S0.09090909090909091yd1373 S0.09090909090909091ygc6107ff S0.09090909090909091yc57e S0.09090909090909091yc96a S0.09090909090909091yac S0.18181818181818182yc019 S0.09090909090909091yad S0.09090909090909091yd00ad S0.09090909090909091vc237<ya2 S0.07692307692307693ya3 S0.07692307692307693ya4 S0.07692307692307693yc350 S0.07692307692307693yc970 S0.07692307692307693yg3227411 S0.07692307692307693ygf6debed S0.07692307692307693yaf S0.07692307692307693yc20a S0.07692307692307693yab S0.07692307692307693ybaa S0.07692307692307693yad S0.07692307692307693yae S0.07692307692307693>vc2386yc586 S0.14285714285714285yd7199 S0.14285714285714285ybc4 S0.14285714285714285yae S0.14285714285714285yaa R0.2857142857142857y T308352b7a881add7e356 S0.14285714285714285vc239;ya1 S0.09090909090909091ya5 S0.09090909090909091yc482 S0.09090909090909091yc15f S0.09090909090909091yg501351d S0.09090909090909091ycffd S0.09090909090909091yf73985a S0.09090909090909091yc50f S0.09090909090909091yac S0.09090909090909091yc89d S0.09090909090909091yaf S0.09090909090909091vc2403yd6425 R0.3333333333333333ybaf R0.3333333333333333y Z51edead39c0e439073986043fb R0.3333333333333333vc241:yc493c0.1yc532c0.1yc715c0.1yc10cc0.1yafc0.1yd70dec0.1ye25ccbc0.1ydbbbbc0.1yabc0.1ye78cedc0.1vc242<ya0 S0.07692307692307693ya6 S0.07692307692307693ya7 S0.07692307692307693yd1039 S0.07692307692307693ydc18b S0.07692307692307693ye12fff S0.07692307692307693yd24dc S0.07692307692307693yc87e S0.07692307692307693yaf S0.07692307692307693ybbd S0.07692307692307693yc17c S0.07692307692307693yac S0.07692307692307693ybaa S0.07692307692307693>vc243<ya4 S0.06666666666666667ya6 S0.06666666666666667ya7 S0.06666666666666667yc907 S0.06666666666666667yc956 S0.06666666666666667yd2619 S0.06666666666666667ybcb S0.13333333333333333yb5b S0.06666666666666667yaf S0.06666666666666667ybab S0.06666666666666667yad S0.06666666666666667yc36e S0.06666666666666667yc90d S0.06666666666666667ycebb S0.06666666666666667>vc2443yba0 R0.3333333333333333yda00c R0.3333333333333333y Z23556fcc5dbfb7b7f43fbbb61d R0.3333333333333333vc2451y `d9560caeb797b302191f667b4264da40Qvc246:ya1c0.1ya3c0.1ya6c0.1ya9c0.1yfa2012ac0.1yacc0.1yccdbc0.1yadc0.1ybfdc0.1yo69afdbadc1e76b6c0.1vc247:ya5c0.1ya7c0.1yf13684dc0.1ye16fddc0.1yc07dc0.1yafc0.1yd0584c0.1yaec0.1yf29265ac0.1yd270ec0.1vc2488ya4e0.125yc823e0.125yc66fe0.125yd43abe0.125yabe0.125yade0.125yc67fe0.125y P52735bbbe6ba65b0e0.125vc2497ya1 R0.2222222222222222ya7 R0.1111111111111111yda106 R0.1111111111111111yad R0.1111111111111111yac R0.1111111111111111yab R0.2222222222222222y U277538367f9c8140e3a75 R0.1111111111111111vc2506yc353 S0.16666666666666666yc844 S0.16666666666666666yd9dca S0.16666666666666666yad S0.16666666666666666ydefed S0.16666666666666666y Q03fbaddfc0fab7c76 S0.16666666666666666vc251<ya0 T0.058823529411764705ya1 T0.058823529411764705ya4 T0.058823529411764705ya5 T0.058823529411764705yc475 T0.058823529411764705yc628 T0.058823529411764705yc857 T0.058823529411764705ybb5 T0.058823529411764705yac S0.17647058823529413yab T0.058823529411764705ycdbf T0.058823529411764705yaa T0.058823529411764705ybbe T0.058823529411764705ybde T0.058823529411764705ye4690d T0.058823529411764705>vc2527ya5 S0.14285714285714285ya8 S0.14285714285714285ye0302e S0.14285714285714285yaa S0.14285714285714285yc57a S0.14285714285714285yae S0.14285714285714285y T8604342a925b2dc60737 S0.14285714285714285vc2534yc127d0.25yc76ed0.25yaad0.25y Y44931bfefab991be3dd7a08b7d0.25vc2541y `e1870dde155be1a375f155dd1f7ead13Qvc2553ybd2 R0.3333333333333333yae R0.3333333333333333y ]805472f79f0b558f75b90b5e7b4ee R0.3333333333333333vc2569ya3 R0.1111111111111111ya8 R0.1111111111111111yc647 R0.1111111111111111yc79e R0.1111111111111111yaa R0.1111111111111111yaf R0.1111111111111111yab R0.1111111111111111yc36a R0.1111111111111111y R1221897f5837c84aff R0.1111111111111111vc2576ya3 S0.16666666666666666ya8 S0.16666666666666666ye5931f S0.16666666666666666yae S0.16666666666666666yeacdac S0.16666666666666666y S724742c4ee0960d8d40 S0.16666666666666666vc2584yc463d0.25yi3931327edd0.25yadd0.25y S1568868c5ab8e839148d0.25vc259;ya5 S0.09090909090909091ya6 S0.09090909090909091yb50 S0.09090909090909091yd2271 S0.09090909090909091yc33e S0.09090909090909091yc01e S0.09090909090909091ybbe S0.09090909090909091yc22b S0.09090909090909091ybed S0.09090909090909091yh330045fe S0.09090909090909091ycaff S0.09090909090909091vc2606ya1 S0.16666666666666666ya9 S0.16666666666666666ybcd S0.16666666666666666ybba S0.16666666666666666yaf S0.16666666666666666y Y582642d9cbe500f018afab341 S0.16666666666666666vc261<ya3 S0.07142857142857142ya4 S0.07142857142857142ya6 S0.07142857142857142yb92 S0.07142857142857142yc444 S0.07142857142857142ydb875 S0.07142857142857142yaf S0.07142857142857142yc24d S0.07142857142857142yad S0.07142857142857142ydfdda S0.07142857142857142yc82b S0.07142857142857142ydbbfb S0.07142857142857142yc75a S0.07142857142857142yac S0.07142857142857142>vc2627ya1e0.125yd7206e0.125yd7664e0.125yc59de0.125yabe0.125yaed0.25y Q76672d3de4dc9a8ede0.125vc263;ya0 S0.08333333333333333ya5 S0.08333333333333333ya9 S0.08333333333333333yb1b S0.08333333333333333yac S0.16666666666666666ybae S0.08333333333333333yd60ec S0.08333333333333333yd46be S0.08333333333333333yc64a S0.08333333333333333ye1877f S0.08333333333333333yg6920edc S0.08333333333333333vc264<ya1 S0.07142857142857142ya3 S0.14285714285714285ya9 S0.07142857142857142yc455 S0.07142857142857142yd4555 S0.07142857142857142yd5433 S0.07142857142857142yf50557b S0.07142857142857142yccba S0.07142857142857142yaa S0.07142857142857142ybce S0.07142857142857142yab S0.07142857142857142ybfc S0.07142857142857142ybfd S0.07142857142857142>vc2659ya0 R0.1111111111111111ya8 R0.1111111111111111yd146e R0.1111111111111111ybca R0.1111111111111111yc40c R0.1111111111111111yad R0.1111111111111111yc37f R0.1111111111111111yg36eecea R0.1111111111111111yj822028dd9e R0.1111111111111111vc266;ya1 S0.08333333333333333yc181 S0.08333333333333333yd8077 S0.08333333333333333yda98d S0.08333333333333333yd42be S0.08333333333333333yac S0.08333333333333333yc01b S0.08333333333333333yae S0.08333333333333333yc060 S0.08333333333333333yab S0.16666666666666666yf5080ec S0.08333333333333333vc2674ya3d0.25ycecfd0.25ybacd0.25y Z80454654d990d9c07d33d35d1cd0.25vc2682yc26cc0.5y ]47355cbe966a94826cbe2fbf2b355c0.5vc269;ya2 S0.09090909090909091ya7 S0.09090909090909091ya8 S0.09090909090909091yc889 S0.09090909090909091yf33919e S0.09090909090909091yh866426ce S0.09090909090909091yae S0.09090909090909091yab S0.09090909090909091ybce S0.09090909090909091yc06f S0.09090909090909091ye19bbf S0.09090909090909091vc270:ya4 S0.09090909090909091ya6 S0.09090909090909091ya9 S0.09090909090909091yc953 S0.09090909090909091yd8964 S0.09090909090909091yf78292d S0.09090909090909091yfeafbdf S0.09090909090909091yae S0.18181818181818182yd57cc S0.09090909090909091ydbbbe S0.09090909090909091vc271<ya0 S0.07142857142857142ya3 S0.07142857142857142ya8 S0.07142857142857142yc623 S0.07142857142857142yc917 S0.07142857142857142ybc4 S0.07142857142857142yad S0.07142857142857142yaa S0.07142857142857142yaf S0.14285714285714285yg58646ce S0.07142857142857142yf93015d S0.07142857142857142yc79e S0.07142857142857142yae S0.07142857142857142>vc272<ya1 S0.06666666666666667ya2 S0.06666666666666667ya4 S0.06666666666666667ya5 S0.06666666666666667ya7 S0.06666666666666667yd7737 S0.06666666666666667ydd12c S0.06666666666666667yac S0.13333333333333333yaa S0.13333333333333333yd68be S0.06666666666666667ycfda S0.06666666666666667yad S0.06666666666666667yg5493b4d S0.06666666666666667>vc2731y `f45069216cd934b80ce882c9a2f2a08aQvc274<ya2c0.1ya3d0.05ya6d0.15ya8d0.05ya9d0.05yc1fed0.05yc14ed0.05yaec0.2yc02bd0.05yc65ed0.05ybaed0.05yadd0.05ydddccd0.05yafd0.05>vc2751y `e30258aeb8475d4c27f7935945671856Qvc2765yc912c0.2ybcdc0.2ye90bcec0.2yafc0.2y U5743226af94c1efaaa4a7c0.2vc2772yh494557dbc0.5y X52824555864d1106278cd1f0c0.5vc2782yc16fc0.5y ]10764f0ccce42d5be8cfeac36b446c0.5vc2794yd4002d0.25yddbccd0.25yacd0.25y W15afefef853a08a0804ba3ad0.25vc2803yc11d R0.3333333333333333yi4726484be R0.3333333333333333y T418849e1f4200ade9535 R0.3333333333333333vc2814ybdbd0.25yf97311cd0.25yf24809fd0.25y R103575d8a7fee19680d0.25vc2826ya4 S0.16666666666666666ya9 S0.16666666666666666yd286a S0.16666666666666666yaa S0.16666666666666666ybee S0.16666666666666666y W373398d7d2c93862c5f6661 S0.16666666666666666vc2837yd5219 S0.14285714285714285yc99f S0.14285714285714285ybda S0.14285714285714285yf22485d S0.14285714285714285yd0872 S0.14285714285714285yaa S0.14285714285714285yl2529599c8440 S0.14285714285714285vc284<ya0 S0.21428571428571427ya5 S0.07142857142857142yb35 S0.07142857142857142yd3211 S0.07142857142857142yd36ff S0.07142857142857142ye37ced S0.07142857142857142yad S0.07142857142857142ybdb S0.07142857142857142yc95a S0.07142857142857142ybac S0.07142857142857142yddaac S0.07142857142857142yac S0.07142857142857142>vc285;yc949 S0.09090909090909091yc984 S0.09090909090909091yd1826 S0.09090909090909091yd5339 S0.09090909090909091yc1ca S0.09090909090909091yc04e S0.09090909090909091ybed S0.09090909090909091yac S0.09090909090909091yd12fe S0.09090909090909091yd61fd S0.09090909090909091yae S0.09090909090909091vc286;ya0 S0.08333333333333333ya2 S0.16666666666666666ya4 S0.08333333333333333yc73d S0.08333333333333333ycfce S0.08333333333333333ycefa S0.08333333333333333yf52675b S0.08333333333333333yc35a S0.08333333333333333yd11ee S0.08333333333333333yd97bc S0.08333333333333333ybdb S0.08333333333333333vc287<ya0 S0.11764705882352941ya2 T0.058823529411764705ya3 T0.058823529411764705ya4 T0.058823529411764705ya8 T0.058823529411764705yc160 T0.058823529411764705yc479 T0.058823529411764705yc26d T0.058823529411764705yac S0.11764705882352941yad T0.058823529411764705yh465087cf T0.058823529411764705yaa T0.058823529411764705ycbdc T0.058823529411764705yaf T0.058823529411764705yab T0.058823529411764705>vc288;ya4 S0.09090909090909091yc234 S0.09090909090909091yd4389 S0.09090909090909091ybf5 S0.09090909090909091ydf28f S0.09090909090909091yd42ad S0.09090909090909091yab S0.09090909090909091ybaf S0.09090909090909091ydcbea S0.09090909090909091yd54ff S0.09090909090909091yc60d S0.09090909090909091vc289<ya0 S0.07692307692307693ya4 S0.07692307692307693yb13 S0.07692307692307693yc505 S0.07692307692307693yd5412 S0.07692307692307693yd6670 S0.07692307692307693ybfb S0.07692307692307693yf82160d S0.07692307692307693yaf S0.15384615384615385ye6093e S0.07692307692307693yab S0.07692307692307693yac S0.07692307692307693>vc2903ydb051 R0.3333333333333333ybfd R0.3333333333333333y Z352847c06e748b345e8ed0738b R0.3333333333333333vc2914ya4d0.25ybbfd0.25yafd0.25y \86812812dab8d39db9aaefe94a78d0.25vc2921y `322264a17ef7182eb1475bd2eaebc2ebQvc293<ya3 S0.06666666666666667ya6 S0.06666666666666667ya8 S0.13333333333333333ya9 S0.06666666666666667yd2845 S0.06666666666666667ye38128 S0.06666666666666667yf20110c S0.06666666666666667yaf S0.06666666666666667ybda S0.06666666666666667ye8304b S0.06666666666666667yad S0.13333333333333333yac S0.06666666666666667yaa S0.06666666666666667>vc2944yd992ad0.25yc00cd0.25yf30242bd0.25y S6217243f3c387ea18b7d0.25vc295:ya0 S0.09090909090909091ya1 S0.18181818181818182yb4c S0.09090909090909091yc08b S0.09090909090909091yc67e S0.09090909090909091yac S0.09090909090909091yefdeef S0.09090909090909091yc50b S0.09090909090909091ydfdcc S0.09090909090909091yh32cdcee2 S0.09090909090909091vc2965yb4ac0.2ye30eebc0.2yc083c0.2ydacecc0.2y R8460150068ba0c6743c0.2vc297<ya0 S0.07142857142857142ya1 S0.07142857142857142ya2 S0.07142857142857142ya9 S0.14285714285714285yc475 S0.07142857142857142yd898d S0.07142857142857142yc25a S0.07142857142857142ybab S0.07142857142857142yac S0.07142857142857142ybba S0.07142857142857142ybfa S0.07142857142857142ycbad S0.07142857142857142yg462405e S0.07142857142857142>vc298<ya0e0.125ya1e0.125ya7e0.125yde01ef0.0625yc01df0.0625yf18582cf0.0625yaff0.0625yc69ef0.0625yabe0.125ybdbf0.0625yaef0.0625yd111af0.0625>vc2992yb7ec0.5y ^23419e4fc69b5b533815681c9bb1a9c0.5vc300:yc323c0.1yc625c0.1yc997c0.1ye34850c0.1yc98cc0.1yg640616fc0.1yaac0.1ybafc0.1yaec0.1yd34bac0.1vc301;ya1 S0.14285714285714285ya8 S0.07142857142857142yc407 S0.07142857142857142yc517 S0.07142857142857142yd5595 S0.07142857142857142ye922cc S0.07142857142857142yd71fd S0.07142857142857142yc28b S0.07142857142857142ycdac S0.07142857142857142yaf S0.21428571428571427yad S0.07142857142857142vc3021y `43501cdf0de25278a208cbb9aad80012Qvc303:ya3c0.1ya7c0.1yc788c0.1yh61173291c0.1yf89abaac0.1yafc0.1yd21cfc0.1ybcec0.1ye4744ec0.1yaec0.1vc3046ya5 S0.16666666666666666yc307 S0.16666666666666666yg7604edf S0.16666666666666666yaa S0.16666666666666666yae S0.16666666666666666y S96120606c8dda06458f S0.16666666666666666vc3051y `775894425f5a7436f56fc5a3b4a2cfaaQvc306<ya1 S0.06666666666666667ya4 S0.06666666666666667ya7 S0.13333333333333333yc264 S0.06666666666666667yb8a S0.06666666666666667yc29f S0.06666666666666667yc62d S0.06666666666666667yebebfe S0.06666666666666667yab S0.13333333333333333ye8008d S0.06666666666666667yaf S0.06666666666666667yc56b S0.06666666666666667yae S0.06666666666666667>vc3074ya2d0.25yc7fad0.25yafd0.25y [0877831b4c924438396760f1841d0.25vc308<ya2f0.0625ya7f0.0625ya8f0.0625yc240f0.0625yc521f0.0625yc885f0.0625yc68af0.0625yaff0.1875yc34cf0.0625yaaf0.0625yd42abf0.0625yadf0.0625ybaaf0.0625yc33cf0.0625>vc309;ya7 S0.09090909090909091yc433 S0.09090909090909091yc9ac S0.09090909090909091ybbb S0.09090909090909091yc94e S0.09090909090909091yd60dc S0.09090909090909091yc30a S0.09090909090909091yc023 S0.09090909090909091ybce S0.09090909090909091ybde S0.09090909090909091yf027364 S0.09090909090909091vc310<ya0 S0.07142857142857142ya2 S0.07142857142857142ya3 S0.07142857142857142yb57 S0.07142857142857142yc617 S0.07142857142857142ycdcc S0.07142857142857142yae S0.07142857142857142yd24df S0.07142857142857142yf32287e S0.07142857142857142yd89ee S0.07142857142857142yab S0.07142857142857142yaf S0.14285714285714285yc64d S0.07142857142857142>vc311<ya0 S0.07692307692307693ya2 S0.07692307692307693yb61 S0.07692307692307693yc938 S0.07692307692307693yd8acc S0.07692307692307693yd78be S0.07692307692307693yc63e S0.07692307692307693yc27e S0.07692307692307693ybee S0.07692307692307693yd53ec S0.07692307692307693yac S0.07692307692307693yab S0.07692307692307693yc90c S0.07692307692307693>vc3129ya6c0.2yd9719c0.1yb9fc0.1yc29cc0.1yadc0.1ybfcc0.1ybbcc0.1yc09ac0.1ym2981057642b69c0.1vc313:ya8c0.1yc153c0.1yed13aac0.1yc56ec0.1yd27fec0.1yd71efc0.1yd40ffc0.1yacc0.1yc093c0.1ydecdfc0.1vc314<ya2 S0.07692307692307693ya4 S0.07692307692307693ya7 S0.07692307692307693yc322 S0.07692307692307693yc414 S0.07692307692307693yc875 S0.07692307692307693ye9ccda S0.07692307692307693yac S0.07692307692307693yeebcdf S0.07692307692307693yfeacbba S0.07692307692307693yae S0.15384615384615385yab S0.07692307692307693>vc315:ya5c0.1ya9c0.1yc755c0.1yc69fc0.1ybddc0.1yabc0.1yaec0.1yc90ac0.1yc99cc0.1yn3086543790541cc0.1vc316;ya2 S0.07692307692307693ya7 S0.07692307692307693ya9 S0.15384615384615385yc265 S0.07692307692307693yd277f S0.07692307692307693yaf S0.07692307692307693ye2177e S0.07692307692307693yaa S0.15384615384615385yg62680ea S0.07692307692307693ye0158f S0.07692307692307693yab S0.07692307692307693vc3178ya4e0.125ya5e0.125ybeee0.125yf48516ee0.125yf57684ce0.125yaae0.125yace0.125yn22adccac34be92e0.125vc3188ya2e0.125yd5742e0.125ye39905e0.125ye216dbe0.125yg319052be0.125ybfce0.125yg68862cbe0.125yafe0.125vc3194yd9587d0.25yccbfd0.25yaad0.25y X8187985725963b8bfc67004dd0.25vc3206ya0 S0.16666666666666666ya6 S0.16666666666666666yd0dcb S0.16666666666666666yad S0.16666666666666666yaf S0.16666666666666666y X17794bbca56b6cdb9e20b932 S0.16666666666666666vc3218ya6 R0.1111111111111111ya7 R0.1111111111111111ya9 R0.1111111111111111yeffdbd R0.1111111111111111yaa R0.2222222222222222yad R0.1111111111111111yc28c R0.1111111111111111y R63976e9eec38cab0f5 R0.1111111111111111vc3222ybdec0.5y ^734259dfb9addebe2b226d96b4f744c0.5vc323<ya1 S0.06666666666666667ya3 S0.06666666666666667ya4 S0.06666666666666667yc302 S0.06666666666666667yc512 S0.06666666666666667yc900 S0.06666666666666667yc78f S0.06666666666666667yc002 S0.06666666666666667ybcc S0.06666666666666667yad S0.13333333333333333ybea S0.06666666666666667yac S0.06666666666666667ybda S0.06666666666666667yedfeec S0.06666666666666667>vc3243ybc4 R0.3333333333333333yab R0.3333333333333333y ]418764dca70aebfc965899a3fa7e5 R0.3333333333333333vc325<ya0 S0.11764705882352941ya5 S0.17647058823529413ya8 S0.11764705882352941yc95c T0.058823529411764705yaa S0.11764705882352941yab T0.058823529411764705yf66950b T0.058823529411764705yaf T0.058823529411764705yd22dd T0.058823529411764705yc82a T0.058823529411764705ycdfe T0.058823529411764705ybce T0.058823529411764705>vc3268ya1e0.125yc219e0.125ydc92ce0.125yc12ae0.125yd28fae0.125ybade0.125ycaabe0.125yl60865046ff05e0.125vc327<ya0 S0.06666666666666667ya1 S0.06666666666666667ya4 S0.06666666666666667ya8 S0.06666666666666667ya9 S0.06666666666666667yb68 S0.06666666666666667yd7396 S0.06666666666666667yc12d S0.06666666666666667yae S0.06666666666666667ybcf S0.06666666666666667ybdd S0.06666666666666667yc33a S0.06666666666666667yebbbca S0.06666666666666667ybda S0.06666666666666667yccbc S0.06666666666666667>vc328<ya4 S0.07142857142857142ya5 S0.07142857142857142ya6 S0.07142857142857142yb32 S0.07142857142857142yc466 S0.07142857142857142yd5063 S0.07142857142857142yfd77cdb S0.07142857142857142yac S0.07142857142857142yab S0.07142857142857142yc99c S0.07142857142857142ycaea S0.07142857142857142yc58e S0.07142857142857142ybda S0.07142857142857142yad S0.07142857142857142>vc329:ya4c0.1ya7c0.1yb79c0.1yc481c0.1yd904bc0.1yi07170a0cec0.1yabc0.1ye7491ec0.1yefeccec0.1yafc0.1vc3308ya3e0.125ya7e0.125yd1294e0.125ycbede0.125yabe0.125ycfcce0.125yaee0.125y R23639057435ac8756ae0.125vc3312yc56dc0.5y ]5711303378bd333ddb611a53ece94c0.5vc332<ya1 S0.07692307692307693ya2 S0.07692307692307693ya4 S0.07692307692307693ya6 S0.07692307692307693yc913 S0.07692307692307693yfc7937b S0.07692307692307693yab S0.07692307692307693ycbde S0.07692307692307693yaa S0.07692307692307693yg96191dc S0.07692307692307693yd31db S0.07692307692307693yae S0.07692307692307693ybab S0.07692307692307693>vc3331y `06731164684f90f33ce4017eca9d8ec1Qvc3341y `f8327953a0f0b80011b939111807999aQvc3353yb8b R0.3333333333333333yf76101d R0.3333333333333333y X185700a8efed148d8722d926 R0.3333333333333333vc3364ya3d0.25yc16bd0.25yacd0.25y [9445539e9274282a612dea354c2d0.25vc3375yc623c0.2ybeec0.2ycaaac0.2yc99bc0.2y U429863f89da313fffed97c0.2vc338<ya4 S0.06666666666666667ya6 S0.13333333333333333ya9 S0.13333333333333333yc760 S0.06666666666666667yd116c S0.06666666666666667ybbe S0.06666666666666667yad S0.13333333333333333yab S0.06666666666666667ydbefa S0.06666666666666667yd51ce S0.06666666666666667yae S0.06666666666666667yf96604c S0.06666666666666667>vc339<ya0f0.0625ya2f0.0625ya3f0.1875ya6f0.0625ye82391f0.0625yb4df0.0625yacf0.0625yc95bf0.0625yabe0.125ybeaf0.0625ycddbf0.0625ye30fddf0.0625ycedff0.0625>vc340<ya4 S0.08333333333333333ya7 S0.08333333333333333yc232 S0.08333333333333333yc415 S0.08333333333333333yd10eb S0.08333333333333333yaa S0.08333333333333333ybad S0.08333333333333333ybbe S0.08333333333333333yad S0.08333333333333333yc05c S0.08333333333333333yd57eb S0.08333333333333333yg850036c S0.08333333333333333>vc3415ya0c0.2yd627ac0.2yacc0.2yd45ddc0.2y V07150343c81d856855590ec0.2vc342<ya5 S0.06666666666666667ya7 S0.06666666666666667ya8 S0.13333333333333333yc465 S0.06666666666666667ye966fe S0.06666666666666667yad S0.06666666666666667yc32b S0.06666666666666667yf86121f S0.06666666666666667yaa S0.13333333333333333yc21b S0.06666666666666667yc95f S0.06666666666666667yae S0.06666666666666667yac S0.06666666666666667>vc3438ya7e0.125yc199e0.125yc945e0.125yb4ee0.125yabe0.125ydfecae0.125ybbde0.125y P486653fea1d0e39ce0.125vc3448yc386e0.125yc774e0.125ybfae0.125yf16213de0.125yf24273de0.125yade0.125yg22332cde0.125yd01cee0.125vc3458ya0e0.125ya7e0.125yc860e0.125yfa2679ae0.125yade0.125yaae0.125ycbfbe0.125y P2645809ed92ce138e0.125vc3466yc120 S0.16666666666666666yc58e S0.16666666666666666yd83fb S0.16666666666666666yc33c S0.16666666666666666ybdb S0.16666666666666666y Q338132d23b9112805 S0.16666666666666666vc347<ya6 S0.07692307692307693ya8 S0.07692307692307693ya9 S0.07692307692307693yd6567 S0.07692307692307693ybc6 S0.07692307692307693ybdc S0.07692307692307693yae S0.15384615384615385yad S0.07692307692307693yh673436ac S0.07692307692307693ye41ebc S0.07692307692307693yc79a S0.07692307692307693ybec S0.07692307692307693>vc348<ya1 T0.058823529411764705ya2 T0.058823529411764705ya5 S0.11764705882352941ya9 T0.058823529411764705yb15 T0.058823529411764705yc479 T0.058823529411764705yd7198 T0.058823529411764705yae T0.058823529411764705yf10ebcf T0.058823529411764705ybbb T0.058823529411764705yd88dc T0.058823529411764705yab S0.11764705882352941yac S0.11764705882352941yaf T0.058823529411764705>vc3491y `a4462529ab493676987d946019a14945Qvc350<ya0 S0.06666666666666667ya2 S0.06666666666666667ya3 S0.06666666666666667ya7 S0.06666666666666667yc230 S0.06666666666666667yc827 S0.06666666666666667ybf7 S0.06666666666666667ybdf S0.06666666666666667yabc0.2yd85af S0.06666666666666667ye2623d S0.06666666666666667yaa S0.06666666666666667yecbddd S0.06666666666666667>vc3512ybccc0.5y ^573488dec311655890a205aad4fb65c0.5vc3521y `7164823f504286e3a762ee612ff0a988Qvc353;ya2 S0.07692307692307693ya5 S0.07692307692307693ya6 S0.07692307692307693yd7906 S0.07692307692307693yh85653399 S0.07692307692307693ybda S0.07692307692307693yc67e S0.07692307692307693yaf S0.07692307692307693yc049 S0.07692307692307693yab S0.23076923076923078yebabcf S0.07692307692307693vc354<ya1 S0.07142857142857142ya2 S0.07142857142857142ya5 S0.14285714285714285yc145 S0.07142857142857142yc634 S0.07142857142857142yd584b S0.07142857142857142yab S0.07142857142857142yaf S0.07142857142857142yh362098fc S0.07142857142857142ybfc S0.07142857142857142yae S0.07142857142857142yad S0.07142857142857142yd57de S0.07142857142857142>vc3554yc730d0.25yfc6696ad0.25yafd0.25y V7498efb66f5ba3a8b35d08d0.25vc356<ya0 S0.07692307692307693ya3 S0.07692307692307693ya4 S0.07692307692307693ya6 S0.07692307692307693yc400 S0.07692307692307693yd1446 S0.07692307692307693yd16fa S0.07692307692307693yae S0.07692307692307693ydaefe S0.07692307692307693yc18e S0.07692307692307693ybbf S0.07692307692307693yebaefd S0.07692307692307693ybba S0.07692307692307693>vc357<ya1f0.0625ya2f0.0625ya5f0.0625yc565f0.0625yc970f0.0625yb6ef0.0625yadf0.1875yd0818f0.0625yd58fff0.0625yc50cf0.0625ybbff0.0625yc037f0.0625yabf0.0625yaaf0.0625>vc3589ya0 R0.1111111111111111ya8 R0.1111111111111111yc866 R0.1111111111111111yd0ebe R0.1111111111111111yf78077c R0.1111111111111111yab R0.1111111111111111yg48410cf R0.1111111111111111yc52a R0.1111111111111111yfbccdff R0.1111111111111111vc3591y `924727b6f380cf3cdfe5650163e92054Qvc3608yc927e0.125yd9425e0.125yc26de0.125yc48de0.125yc68be0.125yc28fe0.125yfbfebade0.125yg454658fe0.125vc3617ya5 S0.14285714285714285ya9 S0.14285714285714285ycbda S0.14285714285714285yaa S0.14285714285714285ybda S0.14285714285714285yd86ec S0.14285714285714285y T9790262e14f953bbadcb S0.14285714285714285vc362<ya2 S0.07142857142857142ya3 S0.07142857142857142ya5 S0.07142857142857142yc491 S0.07142857142857142yc664 S0.07142857142857142ybcc S0.07142857142857142yb1a S0.07142857142857142yab S0.07142857142857142yaf S0.14285714285714285yh107510ac S0.07142857142857142yae S0.07142857142857142yad S0.07142857142857142yf2412aa S0.07142857142857142>vc363;ya4 S0.08333333333333333ya5 S0.08333333333333333yc242 S0.08333333333333333ybd9 S0.08333333333333333ybc6 S0.08333333333333333ybab S0.08333333333333333yac S0.16666666666666666ye6630a S0.08333333333333333yaa S0.08333333333333333yc84e S0.08333333333333333yj5765103d2d S0.08333333333333333vc364<ya5 S0.07692307692307693ya8 S0.07692307692307693yc563 S0.07692307692307693yc971 S0.07692307692307693yd9609 S0.07692307692307693yb7a S0.07692307692307693yaa S0.15384615384615385yaf S0.07692307692307693yf31685e S0.07692307692307693yd88da S0.07692307692307693yceea S0.07692307692307693ybce S0.07692307692307693>vc365<ya1 S0.07692307692307693ya3 S0.07692307692307693ya6 S0.07692307692307693yc888 S0.07692307692307693yd14cf S0.07692307692307693yae S0.15384615384615385ye75aec S0.07692307692307693ycead S0.07692307692307693ye7101d S0.07692307692307693yad S0.07692307692307693yc94d S0.07692307692307693yc28a S0.07692307692307693>vc3665ya6c0.2yc14ac0.2yadc0.2yg294550cc0.2y T9760aec57ba29682a750c0.2vc367<ya1 S0.07142857142857142ya8 S0.07142857142857142yc827 S0.07142857142857142yc946 S0.07142857142857142yb5d S0.07142857142857142yaa S0.07142857142857142yae S0.07142857142857142ybea S0.07142857142857142ye70edb S0.07142857142857142yc11d S0.07142857142857142yab S0.07142857142857142yc54f S0.07142857142857142yc076 S0.07142857142857142yccae S0.07142857142857142>vc368:ya4c0.1ya7c0.1ya8c0.1ybb9c0.1yadc0.1yafc0.1yd73fac0.1ybcac0.1ybefc0.1y Q66891554b66b2cdedc0.1vc369<ya3f0.0625ya6e0.125ya7e0.125yc583f0.0625yc962f0.0625ybdcf0.0625yaef0.0625yf34780ff0.0625ye0374bf0.0625ybebe0.125yade0.125yaff0.0625>vc3704ya1d0.25ybded0.25ybabd0.25y [82817c0fb24e591b9a89a82f736d0.25vc3711y `09677934e13a5d728f00c6ed7c8870a9Qvc3721y `7052598d2355984237d126afea2f6e88Qvc3731y `927612b57ba01ca878b2d7edce52a563Qvc3741y `97402287d8c6c03f0b63848e17e9d944Qvc375<ya0f0.0625ya3f0.0625ya5f0.0625ya7f0.0625yc121f0.0625yc240f0.0625yc62ff0.0625yf31128af0.0625yc21bf0.0625yaef0.0625ycbdbf0.0625yabe0.125yadf0.0625yacf0.0625yb04f0.0625>vc376<ya1 S0.08333333333333333yb66 S0.08333333333333333yc822 S0.08333333333333333yc916 S0.08333333333333333yd54da S0.08333333333333333yab S0.08333333333333333yaf S0.08333333333333333yd49ef S0.08333333333333333yc40c S0.08333333333333333ycfab S0.08333333333333333yc61d S0.08333333333333333yd37cf S0.08333333333333333>vc3778yd1934e0.125yd9425e0.125yh89118022e0.125yc41be0.125yg811063be0.125ybdee0.125yaee0.125yc77de0.125vc378;ya1 S0.09090909090909091yc622 S0.09090909090909091yc722 S0.09090909090909091yc759 S0.09090909090909091yc37b S0.09090909090909091ydeaad S0.09090909090909091yaf S0.09090909090909091yc79e S0.09090909090909091yaa S0.09090909090909091yfaacebf S0.09090909090909091yd48ec S0.09090909090909091vc3791y `73262345214f9b7794f2cc4a612b15e8Qvc3802yg9baedcdc0.5y Y033169611a42c3cfd58b3ae03c0.5vc381<ya0 S0.05263157894736842ya1 S0.10526315789473684ya2 S0.10526315789473684ya4 S0.10526315789473684yc865 S0.05263157894736842yef23ca S0.05263157894736842ybaa S0.05263157894736842yc066 S0.05263157894736842yab S0.05263157894736842ybee S0.05263157894736842ybfa S0.05263157894736842ybdf S0.05263157894736842yaf S0.10526315789473684ybbe S0.05263157894736842yac S0.05263157894736842>vc3827yc953 S0.14285714285714285yd2523 S0.14285714285714285yb3c S0.14285714285714285yae S0.14285714285714285yd65ff S0.14285714285714285ybfd S0.14285714285714285y P73579aaaf5d7ce36 S0.14285714285714285vc383<ya1 T0.058823529411764705ya5 T0.058823529411764705ya7 T0.058823529411764705ya8 S0.11764705882352941ya9 S0.11764705882352941yc939 T0.058823529411764705yc88a T0.058823529411764705yae T0.058823529411764705yh608108be T0.058823529411764705ybda T0.058823529411764705ycaab T0.058823529411764705yaa S0.11764705882352941ybaf T0.058823529411764705yad T0.058823529411764705>vc3843yc2f1 R0.3333333333333333ybec R0.3333333333333333y [795216d5bafa33a810af3421942 R0.3333333333333333vc385;ya4 S0.08333333333333333yb62 S0.08333333333333333yc373 S0.08333333333333333ybce S0.08333333333333333yd0aea S0.08333333333333333yc06d S0.08333333333333333yf44878b S0.08333333333333333yaa S0.16666666666666666ycefe S0.08333333333333333yc090 S0.08333333333333333yc66a S0.08333333333333333vc386<ya3 S0.11764705882352941ya5 T0.058823529411764705ya9 T0.058823529411764705yc265 T0.058823529411764705yc423 T0.058823529411764705ybc0 T0.058823529411764705yae S0.11764705882352941yaf T0.058823529411764705ybac T0.058823529411764705yd41cc T0.058823529411764705yab T0.058823529411764705yac T0.058823529411764705yc95a T0.058823529411764705yc97e T0.058823529411764705ycfcb T0.058823529411764705>vc387<ya0c0.1ya1d0.05ya2d0.05ya3d0.15ya4d0.05ya6d0.05yc7edd0.05yadc0.1ycefad0.05yaed0.05yafd0.05ybedd0.05yabd0.05yd77ebd0.05yceffd0.05yc86bd0.05>vc3884yd3811d0.25yabd0.25yi40721f7cad0.25y R651887aac4eb17f9f0d0.25vc3894yc765d0.25yb5ad0.25yafd0.25y Z9668608a39333fa90cf462657ed0.25vc3907ya0 S0.14285714285714285ya5 S0.14285714285714285ydc70b S0.14285714285714285yd78fd S0.14285714285714285yab S0.14285714285714285yedffcd S0.14285714285714285y P38322355e9c2471e S0.14285714285714285vc3911y `229975f1e84b5088e819cd5f2dc43080Qvc392;ya1 S0.09090909090909091ya3 S0.09090909090909091ya7 S0.09090909090909091ya8 S0.09090909090909091yd10eb S0.09090909090909091yae S0.09090909090909091ybdc S0.09090909090909091yc64d S0.09090909090909091ybca S0.09090909090909091ycdad S0.09090909090909091ym92641dadb5de7 S0.09090909090909091vc3939ya0 R0.1111111111111111ya9 R0.1111111111111111yd3979 R0.1111111111111111yd49ba R0.1111111111111111yg23148db R0.1111111111111111yeeffdc R0.1111111111111111ybaa R0.1111111111111111ybfe R0.1111111111111111yf5876ea R0.1111111111111111vc3942yef6dffc0.5y [70097776e24c2a7c9c0f2514f79c0.5vc395<ya2 S0.07692307692307693ya4 S0.07692307692307693ya7 S0.07692307692307693yb61 S0.07692307692307693yc835 S0.07692307692307693yd3967 S0.07692307692307693yg991285e S0.07692307692307693yac S0.15384615384615385ye3295b S0.07692307692307693ybff S0.07692307692307693ycdcd S0.07692307692307693yaf S0.07692307692307693>vc3966yd1726 S0.16666666666666666yc50f S0.16666666666666666yc43b S0.16666666666666666ybcf S0.16666666666666666yg61066ef S0.16666666666666666ym8656477b226be S0.16666666666666666vc3973ydeeef R0.3333333333333333ye60efe R0.3333333333333333y W889349870426d10edc694be R0.3333333333333333vc398;ya6 S0.09090909090909091yd1338 S0.09090909090909091yd4796 S0.09090909090909091yb4b S0.09090909090909091yc046 S0.09090909090909091ybac S0.09090909090909091yaa S0.09090909090909091ybfb S0.09090909090909091yaf S0.09090909090909091yg0481dbd S0.09090909090909091ye4003d S0.09090909090909091vc3991y `b2621497b3313c97855ed951f0d9b291Qvc400<ya3 S0.06666666666666667ya5 S0.06666666666666667ya7 S0.06666666666666667ya9c0.2yd1441 S0.06666666666666667ybff S0.06666666666666667yaa S0.13333333333333333yi42144a7de S0.06666666666666667yceaf S0.06666666666666667yaf S0.06666666666666667yae S0.06666666666666667ydcfea S0.06666666666666667>vc401<ya0 S0.07142857142857142ya8 S0.07142857142857142yb55 S0.07142857142857142yc303 S0.07142857142857142yd5988 S0.07142857142857142yab S0.21428571428571427yc62a S0.07142857142857142yac S0.07142857142857142yd0785 S0.07142857142857142yaa S0.07142857142857142yc77c S0.07142857142857142yf74608e S0.07142857142857142>vc402;ya7 S0.09090909090909091yc230 S0.09090909090909091yc716 S0.09090909090909091yd8208 S0.09090909090909091yc94b S0.09090909090909091yd85ba S0.09090909090909091ycdbb S0.09090909090909091yac S0.09090909090909091yc20b S0.09090909090909091yae S0.09090909090909091yf69248b S0.09090909090909091>vetitle<va1:yd2023 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091va2;yeOrama S0.08333333333333333ycという S0.08333333333333333yb検索 S0.16666666666666666ydエンジン S0.08333333333333333yaで S0.08333333333333333ycブログ S0.08333333333333333yaを S0.08333333333333333yb作っ S0.08333333333333333yaて S0.08333333333333333yaみ S0.08333333333333333yaた S0.08333333333333333va39ybGo R0.1111111111111111yaで R0.1111111111111111yeSlack R0.1111111111111111yaの R0.1111111111111111ycボット R0.1111111111111111yaを R0.1111111111111111yb作っ R0.1111111111111111yaた R0.1111111111111111ya話 R0.1111111111111111va49yd機械学習 R0.1111111111111111ycによる R0.1111111111111111yb検索 R0.1111111111111111yeランキング R0.1111111111111111yb改善 R0.1111111111111111ycガイド R0.1111111111111111yaを R0.1111111111111111yd読みまし R0.1111111111111111yaた R0.1111111111111111va56yfsearch S0.14285714285714285ya- S0.14285714285714285ybUI S0.14285714285714285yaと R0.2857142857142857yiSearchkit S0.14285714285714285yd検索画面 S0.14285714285714285va6<ybVS S0.07692307692307693ya  S0.15384615384615385ydCode S0.07692307692307693yaと S0.07692307692307693ycDev S0.07692307692307693yiContainer S0.07692307692307693ya( S0.07692307692307693ydコンテナ S0.07692307692307693ya名 S0.07692307692307693yaの S0.07692307692307693yb指定 S0.07692307692307693ya) S0.07692307692307693>va76ygブログ記述環境 S0.16666666666666666ycとして S0.16666666666666666yaの S0.16666666666666666ycDev S0.16666666666666666ya  S0.16666666666666666yiContainer S0.16666666666666666va85ya2 S0.16666666666666666ycWSL S0.16666666666666666yaの R0.3333333333333333ykディストリビューション S0.16666666666666666yd環境移行 S0.16666666666666666va9<ybVS S0.06666666666666667ya  S0.13333333333333333ydCode S0.06666666666666667yaと S0.06666666666666667ycDev S0.06666666666666667yiContainer S0.06666666666666667ya（ S0.06666666666666667yfdocker S0.06666666666666667ya- S0.06666666666666667ygcompose S0.06666666666666667ya. S0.06666666666666667ycyml S0.06666666666666667yb対応 S0.06666666666666667ya） S0.06666666666666667>vb10<ybVS S0.07692307692307693ya  S0.15384615384615385ydCode S0.07692307692307693yaと S0.07692307692307693ycDev S0.07692307692307693yiContainer S0.07692307692307693yaの S0.07692307692307693yb導入 S0.07692307692307693ya（ S0.07692307692307693ybまだ S0.07692307692307693yb途中 S0.07692307692307693ya） S0.07692307692307693>vb11<ycpre S0.07692307692307693ya- S0.07692307692307693yfcommit S0.07692307692307693yaと S0.15384615384615385ydvenv S0.07692307692307693ygPyCharm S0.07692307692307693ya（ S0.07692307692307693yb困っ S0.07692307692307693yaた S0.07692307692307693yaな S0.07692307692307693ya？ S0.07692307692307693ya） S0.07692307692307693>vb12;yb今年 S0.09090909090909091yaも S0.09090909090909091yeオンライン S0.09090909090909091yaで S0.09090909090909091yfBerlin S0.09090909090909091ya  S0.09090909090909091yiBuzzwords S0.09090909090909091yaに S0.09090909090909091yb参加 S0.09090909090909091yaし S0.09090909090909091yaた S0.09090909090909091vb13:yd2022 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091vb144yc仕事中d0.25yaのd0.25ycBGMd0.25yb環境d0.25vb158ymElasticsearch R0.1111111111111111yaの R0.1111111111111111ygアーキテクチャ R0.1111111111111111yaと R0.1111111111111111yiStateless R0.1111111111111111ya  R0.2222222222222222ya/ R0.1111111111111111yjServerless R0.1111111111111111vb16:ya2c0.1ycローマc0.1yc字入力c0.1yaのc0.1ybゆれc0.1yaとc0.1yb読みc0.1ya（c0.1y \JapaneseCompletionAnalyzerそのc0.1ya）c0.1vb175yd日本語用 S0.16666666666666666yiオートコンプリート S0.16666666666666666yaの R0.3333333333333333ybため S0.16666666666666666yhAnalyzer S0.16666666666666666vb185ydHugoc0.2yaをc0.2yfアップデートc0.2yaしc0.2yaたc0.2vb199ya2 R0.1111111111111111yfQuerqy R0.1111111111111111yaの R0.1111111111111111yb調査 R0.1111111111111111ya（ R0.1111111111111111ybその R0.1111111111111111ya： R0.1111111111111111ygアーキテクチャ R0.1111111111111111ya） R0.1111111111111111vb207yfQuerqy S0.14285714285714285yaの S0.14285714285714285yb調査 S0.14285714285714285ya（ S0.14285714285714285ybその S0.14285714285714285ya１ S0.14285714285714285ya） S0.14285714285714285vb21;yb今年 S0.09090909090909091yaも S0.09090909090909091yeオンライン S0.09090909090909091yaで S0.09090909090909091yfBerlin S0.09090909090909091ya  S0.09090909090909091yiBuzzwords S0.09090909090909091yaに S0.09090909090909091yb参加 S0.09090909090909091yaし S0.09090909090909091yaた S0.09090909090909091vb225ymElasticsearchc0.2yaのc0.2yc新しいc0.2ydJavac0.2yfクライアントc0.2vb238ykインデックスエイリアス S0.09090909090909091ya  S0.36363636363636365ya- S0.09090909090909091yeAzure S0.09090909090909091yiCognitive S0.09090909090909091yfSearch S0.09090909090909091yaの S0.09090909090909091yc新機能 S0.09090909090909091vb24<ygExtreme T0.041666666666666664ya  R0.3333333333333333yeMulti T0.041666666666666664ya- T0.041666666666666664yelabel T0.041666666666666664yhLearning T0.041666666666666664ycfor T0.041666666666666664yhSemantic T0.041666666666666664yhMatching T0.041666666666666664ybin T0.041666666666666664ygProduct T0.041666666666666664yfSearch T0.041666666666666664ycという T0.041666666666666664yb論文 T0.041666666666666664yaを T0.041666666666666664yb読ん T0.041666666666666664yaだ T0.041666666666666664>vb25:yd2021 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091vb266ye2021年 S0.16666666666666666ybかっ S0.16666666666666666yaて S0.16666666666666666yc良かっ S0.16666666666666666yaた S0.16666666666666666ybもの S0.16666666666666666vb27<yeAzure T0.058823529411764705ya  S0.23529411764705882yiCognitive T0.058823529411764705yfSearch T0.058823529411764705yaの T0.058823529411764705yeIndex T0.058823529411764705yfSchema T0.058823529411764705ydJSON T0.058823529411764705yaを T0.058823529411764705ycCSV T0.058823529411764705yaで T0.058823529411764705ya見 T0.058823529411764705ybたく T0.058823529411764705ybなる T0.058823529411764705>vb286yb今年 S0.16666666666666666yaの S0.16666666666666666ycDIY S0.16666666666666666yeキーボード S0.16666666666666666yaと S0.16666666666666666yjコントローラーラック S0.16666666666666666vb29<yfDomain T0.037037037037037035ya- T0.037037037037037035yhSpecific T0.037037037037037035ya  R0.3333333333333333ykPretraining T0.037037037037037035ycfor T0.037037037037037035yhVertical T0.037037037037037035yfSearch T0.037037037037037035ya: T0.037037037037037035ydCase T0.037037037037037035yeStudy T0.037037037037037035ybon T0.037037037037037035yjBiomedical T0.037037037037037035yjLiterature T0.037037037037037035ycという T0.037037037037037035yb論文 T0.037037037037037035yaを T0.037037037037037035yb読ん T0.037037037037037035yaだ T0.037037037037037035>vb309yb今年 R0.1111111111111111yaも R0.1111111111111111yeMICES R0.1111111111111111yaに R0.1111111111111111yeオンライン R0.1111111111111111yb出張 R0.1111111111111111yaし R0.1111111111111111yaて R0.1111111111111111yaた R0.1111111111111111vb31;yb今年 S0.09090909090909091yaも S0.09090909090909091yfBerlin S0.09090909090909091ya  S0.09090909090909091yiBuzzwords S0.09090909090909091yaに S0.09090909090909091yeオンライン S0.09090909090909091yb出張 S0.09090909090909091yaし S0.09090909090909091yaて S0.09090909090909091yaた S0.09090909090909091vb32<yeAzuref0.0625ya f0.1875yiCognitivef0.0625yfSearche0.125yaのf0.0625yc新機能f0.0625ya、f0.0625yhSemanticf0.0625yaをf0.0625yb試しf0.0625yaてf0.0625yaみf0.0625yaたf0.0625>vb33<ygLunakeyd0.05ya c0.1ydMinid0.05yaをd0.05yb組みd0.05yb立てd0.05yaてc0.1ya、d0.05ycBLEd0.05ya+d0.05ydLPMEd0.05ya-d0.05ydIO化しd0.05yaみd0.05yaたd0.05ya#d0.05ycDIYd0.05yeキーボードd0.05>vb34:ydスライドc0.1yb作成c0.1yaのc0.1yb環境c0.1yaをc0.1ydMarpc0.1yaにc0.1ybしてc0.1yaみc0.1yaたc0.1vb35<yd検索技術 S0.06666666666666667yaに S0.06666666666666667yc関する S0.06666666666666667yb情報 S0.06666666666666667yb交換 S0.06666666666666667yaを S0.06666666666666667yb目的 S0.06666666666666667yaと S0.06666666666666667yaし S0.06666666666666667yaた S0.13333333333333333yeSlack S0.06666666666666667yaが S0.06666666666666667ydできまし S0.06666666666666667ya！ S0.06666666666666667>vb369yfOData式 S0.09090909090909091yaと S0.18181818181818182yc日本語 S0.09090909090909091yaの S0.09090909090909091yb検索 S0.18181818181818182ya( S0.09090909090909091yeNGram S0.09090909090909091ya) S0.09090909090909091ydフレーズ S0.09090909090909091vb379yd2021 R0.1111111111111111yb自宅 R0.1111111111111111yaの R0.1111111111111111yb作業 R0.1111111111111111yb環境 R0.1111111111111111ya( R0.1111111111111111ya/ R0.1111111111111111yb02 R0.1111111111111111ya) R0.1111111111111111vb38;yeAzure S0.08333333333333333ya  S0.16666666666666666yiCognitive S0.08333333333333333yfSearch S0.08333333333333333yaで S0.08333333333333333yiオートコンプリート S0.08333333333333333yaや S0.08333333333333333yeサジェスト S0.08333333333333333yaを S0.08333333333333333ybして S0.08333333333333333ybみる S0.08333333333333333vb39<ya2f0.0625ya「f0.0625yjコンピュータシステムf0.0625yaのf0.0625yb理論f0.0625yaとf0.0625yb実装f0.0625ya」f0.0625yaをf0.0625yb読みf0.0625yb始めf0.0625yaたf0.0625ya f0.0625ya#f0.0625ydNandf0.0625yfTetrisf0.0625>vb40<yeSofled0.05ya c0.1ybv2d0.05yaをd0.05yb組みd0.05yb立てd0.05yaてc0.1ya、d0.05ycBLEd0.05ya+d0.05ydLPMEd0.05ya-d0.05ydIO化しd0.05yaみd0.05yaたd0.05ya#d0.05ycDIYd0.05yeキーボードd0.05>vb41<yeCornef0.0625ya f0.1875yeLightf0.0625ybv2f0.0625yaのf0.0625ycBLEf0.0625ya+f0.0625ydLPMEf0.0625ya-f0.0625ybIOf0.0625yb対応f0.0625ya#f0.0625ycDIYf0.0625yeキーボードf0.0625>vb425ybPCc0.2yaもc0.2ycDIYc0.2ycしましc0.2yaたc0.2vb43:yd2020 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091vb444yeIndexc0.2ya c0.4yhTemplatec0.2ybV2c0.2vb45:yeCorne S0.09090909090909091ya  S0.18181818181818182yiChocolate S0.09090909090909091yaを S0.09090909090909091yb組み S0.09090909090909091yb立て S0.09090909090909091yaた S0.09090909090909091ya# S0.09090909090909091ycDIY S0.09090909090909091yeキーボード S0.09090909090909091vb46;yeCorne S0.07692307692307693ya  S0.23076923076923078yeLight S0.07692307692307693ybv2 S0.07692307692307693yaを S0.07692307692307693yb作成 S0.07692307692307693yaし S0.07692307692307693yaた S0.07692307692307693ya# S0.07692307692307693ycDIY S0.07692307692307693yeキーボード S0.07692307692307693vb478ygWindowse0.125yaへe0.125yaのe0.125yb移行e0.125ya（e0.125ybそのe0.125ya１e0.125ya）e0.125vb484ygWindowsd0.25yaをd0.25ycお試しd0.25ya中d0.25vb49:ya0c0.1yeDozenc0.1yaをc0.1yb作成c0.1yaしc0.1yaたc0.1ya c0.1ya#c0.1ycDIYc0.1yeキーボードc0.1vb50:ygLinderac0.1yaのc0.1ycFSTc0.1yaをc0.1yoDoubleArrayTriec0.1yaにc0.1yb変更c0.1yaしc0.1yaたc0.1ya話c0.1vb51<ya3 S0.07142857142857142yd検索対象 S0.07142857142857142yaの S0.07142857142857142ycデータ S0.07142857142857142yaと S0.07142857142857142yfデータソース S0.07142857142857142ya( S0.07142857142857142yb検索 S0.07142857142857142ydシステム S0.07142857142857142yaに S0.07142857142857142yc関する S0.07142857142857142yb妄想 S0.07142857142857142ybその S0.07142857142857142ya) S0.07142857142857142>vb529yd2020 R0.1111111111111111yb自宅 R0.1111111111111111yaの R0.1111111111111111yb作業 R0.1111111111111111yb環境 R0.1111111111111111ya( R0.1111111111111111ya/ R0.1111111111111111yb09 R0.1111111111111111ya) R0.1111111111111111vb534ygmeteredd0.25ydクレートd0.25yaのd0.25yb紹介d0.25vb547yd2020 S0.14285714285714285ye第4章終了 S0.14285714285714285ya( S0.14285714285714285yd言語処理 S0.14285714285714285yd100本 S0.14285714285714285ycノック S0.14285714285714285ya) S0.14285714285714285vb557yd2020 S0.14285714285714285ye第3章終了 S0.14285714285714285ya( S0.14285714285714285yd言語処理 S0.14285714285714285yd100本 S0.14285714285714285ycノック S0.14285714285714285ya) S0.14285714285714285vb56:yiTerraform S0.09090909090909091yaで S0.09090909090909091yeAzure S0.09090909090909091ya  S0.18181818181818182yiCognitive S0.09090909090909091yfSearch S0.09090909090909091yaの S0.09090909090909091yeクラスター S0.09090909090909091yaを S0.09090909090909091yb起動 S0.09090909090909091vb57<ya2 S0.06666666666666667yb検索 S0.13333333333333333ydシステム S0.13333333333333333yaを S0.06666666666666667yb構成 S0.06666666666666667ybする S0.06666666666666667ycパーツ S0.06666666666666667ya( S0.06666666666666667yaに S0.06666666666666667yc関する S0.06666666666666667yb妄想 S0.06666666666666667ybその S0.06666666666666667ya) S0.06666666666666667>vb58<ya1f0.0625ydシステムe0.125yaのf0.0625yb特徴f0.0625yaとf0.0625yb検索e0.125yb機能f0.0625ydについてf0.0625ya(f0.0625yaにf0.0625yc関するf0.0625yb妄想f0.0625ybそのf0.0625ya)f0.0625>vb597ydRustc0.1ya c0.4ycthec0.1ydbookc0.1ya-c0.1ya第c0.1yc15章c0.1vb609yfBerlin R0.1111111111111111ya  R0.1111111111111111yiBuzzwords R0.1111111111111111yaに R0.1111111111111111yeオンライン R0.1111111111111111yb出張 R0.1111111111111111yaし R0.1111111111111111yaて R0.1111111111111111yaた R0.1111111111111111vb61:yjluceneutil S0.08333333333333333ya  S0.16666666666666666ya- S0.08333333333333333yhAnalyzer S0.08333333333333333yb性能 S0.08333333333333333ycテスト S0.08333333333333333yaへ S0.08333333333333333yaの S0.16666666666666666yhkuromoji S0.08333333333333333yb追加 S0.08333333333333333vb628yjluceneutil R0.1111111111111111ya  R0.2222222222222222ya- R0.1111111111111111yeマニアック R0.1111111111111111yaな R0.1111111111111111ycツール R0.1111111111111111yaの R0.1111111111111111yfセットアップ R0.1111111111111111vb639yeAzure S0.09090909090909091ya  S0.18181818181818182yiCognitive S0.09090909090909091yfSearch S0.09090909090909091yaで S0.09090909090909091yaの S0.18181818181818182ye日本語向け S0.09090909090909091yhAnalyzer S0.09090909090909091yb違い S0.09090909090909091vb647ydRustc0.1ya c0.4ycthec0.1ydbookc0.1ya-c0.1ya第c0.1yc13章c0.1vb657ydRustc0.1ya c0.4ycthec0.1ydbookc0.1ya-c0.1ya第c0.1yc10章c0.1vb667yeAzure R0.1111111111111111ya  R0.2222222222222222yiCognitive R0.1111111111111111yfSearch R0.1111111111111111yaの R0.2222222222222222yeリクエスト R0.1111111111111111ydロギング R0.1111111111111111vb67<yd2020 S0.05263157894736842yiMicrosoft S0.05263157894736842ya  S0.15789473684210525yeBuild S0.05263157894736842ya( S0.05263157894736842ya) S0.05263157894736842yaの S0.15789473684210525yeAzure S0.05263157894736842yiCognirive S0.05263157894736842yfSearch S0.05263157894736842yeセッション S0.05263157894736842yaを S0.05263157894736842yb見た S0.05263157894736842yaで S0.05263157894736842ybメモ S0.05263157894736842>vb68:ya7 S0.16666666666666666ygElastic S0.08333333333333333ya  S0.16666666666666666yeStack S0.08333333333333333ya. S0.08333333333333333yaが S0.08333333333333333ydリリース S0.08333333333333333yaさ S0.08333333333333333yaれ S0.08333333333333333yaた S0.08333333333333333vb697ydRustc0.1ya c0.4ycthec0.1ydbookc0.1ya-c0.1ya第c0.1yb9章c0.1vb70<yb12 S0.08333333333333333yb19 S0.08333333333333333yd2020 S0.08333333333333333yc第2章 S0.08333333333333333yaの S0.08333333333333333ybから S0.08333333333333333ybまで S0.08333333333333333ya( S0.08333333333333333yd言語処理 S0.08333333333333333yd100本 S0.08333333333333333ycノック S0.08333333333333333ya) S0.08333333333333333>vb71<yb10 S0.08333333333333333yb11 S0.08333333333333333yd2020 S0.08333333333333333yc第2章 S0.08333333333333333yaの S0.08333333333333333ybから S0.08333333333333333ybまで S0.08333333333333333ya( S0.08333333333333333yd言語処理 S0.08333333333333333yd100本 S0.08333333333333333ycノック S0.08333333333333333ya) S0.08333333333333333>vb72<yd2020 S0.08333333333333333yc第1章 S0.08333333333333333yaの S0.08333333333333333yb08 S0.08333333333333333ybから S0.08333333333333333yb09 S0.08333333333333333ybまで S0.08333333333333333ya( S0.08333333333333333yd言語処理 S0.08333333333333333yd100本 S0.08333333333333333ycノック S0.08333333333333333ya) S0.08333333333333333>vb73<ya2d0.05ygElasticd0.05yaのd0.05yiWorkplaced0.05ya d0.25yfSearchd0.05yaをd0.05yb触っd0.05yaてd0.05ybみるd0.05ya-c0.1ybそのd0.05yfインストールd0.05yaとd0.05yb起動d0.05>vb74<ya1 S0.07142857142857142ygElastic S0.07142857142857142yaの S0.07142857142857142yiWorkplace S0.07142857142857142ya  S0.21428571428571427yfSearch S0.07142857142857142yaを S0.07142857142857142yb触っ S0.07142857142857142yaて S0.07142857142857142ybみる S0.07142857142857142ya- S0.07142857142857142ybその S0.07142857142857142>vb755yb辞書 S0.16666666666666666yaの R0.3333333333333333yb更新 S0.16666666666666666ydについて S0.16666666666666666yc注意点 S0.16666666666666666vb769yhKuromojic0.1yaのc0.2ydカスタムc0.1yb辞書c0.1yaをc0.1yfインデックスc0.1yb設定c0.1yaでc0.1yb指定c0.1vb777ydRustc0.1ya c0.4ycthec0.1ydbookc0.1ya-c0.1ya第c0.1yb8章c0.1vb78<yd2020 S0.08333333333333333yc第1章 S0.08333333333333333yaの S0.08333333333333333yb03 S0.08333333333333333ybから S0.08333333333333333yb06 S0.08333333333333333ybまで S0.08333333333333333ya( S0.08333333333333333yd言語処理 S0.08333333333333333yd100本 S0.08333333333333333ycノック S0.08333333333333333ya) S0.08333333333333333>vb795yd言語処理c0.2yd100本c0.2ycノックc0.2ya、c0.2yb再びc0.2vb807ydRustc0.1ya c0.4ycthec0.1ydbookc0.1ya-c0.1ya第c0.1yb6章c0.1vb81;yhKuromoji S0.08333333333333333yaの S0.08333333333333333ycCLI S0.08333333333333333ydコマンド S0.08333333333333333yaに S0.08333333333333333ydJSON S0.08333333333333333yb出力 S0.16666666666666666yaと S0.08333333333333333ydラティス S0.08333333333333333yaを S0.08333333333333333yb追加 S0.08333333333333333vb827ydRustc0.1ya c0.4ycthec0.1ydbookc0.1ya-c0.1ya第c0.1yb5章c0.1vb837yd2020 S0.14285714285714285yb自宅 S0.14285714285714285yaの S0.14285714285714285yb作業 S0.14285714285714285yb環境 S0.14285714285714285ya( S0.14285714285714285ya) S0.14285714285714285vb847ydRustc0.1ya c0.4ycthec0.1ydbookc0.1ya-c0.1ya第c0.1yb4章c0.1vb859ymElasticsearch S0.07692307692307693yaの S0.23076923076923078ygAnalyze S0.07692307692307693ya  S0.23076923076923078ycAPI S0.07692307692307693yfVisual S0.07692307692307693yfStudio S0.07692307692307693ydCode S0.07692307692307693ykクライアントプラグイン S0.07692307692307693vb868ydRust R0.1111111111111111ya  R0.2222222222222222ycthe R0.1111111111111111ydBook R0.1111111111111111yaを R0.1111111111111111yb読み R0.1111111111111111yb始め R0.1111111111111111yaた R0.1111111111111111vb87<yfVisual T0.047619047619047616ya  S0.23809523809523808yfStudio T0.047619047619047616ydCode T0.047619047619047616yaの T0.047619047619047616yeプラグイン T0.047619047619047616yaを T0.047619047619047616yb作っ T0.047619047619047616yaて T0.047619047619047616yaみ T0.047619047619047616yaた T0.047619047619047616ya( T0.047619047619047616yeAzure T0.047619047619047616yfSearch T0.047619047619047616ygAnalyze T0.047619047619047616yfClient T0.047619047619047616ya) T0.047619047619047616>vb889yb実践 R0.1111111111111111ydRust R0.1111111111111111yb入門 R0.1111111111111111yaの R0.1111111111111111yb3章 R0.1111111111111111yaを R0.1111111111111111yb読み R0.1111111111111111yc終わっ R0.1111111111111111yaた R0.1111111111111111vb897yhKuromojie0.125yaのe0.125ycCLIe0.125ydコマンドe0.125yaとd0.25ygpicoclie0.125ygGraalVMe0.125vb909yb実践 R0.1111111111111111ydRust R0.1111111111111111yb入門 R0.1111111111111111yaの R0.1111111111111111yb3章 R0.1111111111111111yaを R0.1111111111111111yb読ん R0.1111111111111111ybでる R0.1111111111111111ycところ R0.1111111111111111vb917ye2019年 S0.14285714285714285yaに S0.14285714285714285yb買っ S0.14285714285714285yaて S0.14285714285714285ycよかっ S0.14285714285714285yaた S0.14285714285714285ybもの S0.14285714285714285vb92<ya5 S0.07692307692307693ygブログ移行日記 S0.07692307692307693ya( S0.07692307692307693ybその S0.07692307692307693ya) S0.07692307692307693ya  S0.15384615384615385ya- S0.07692307692307693yeJugem S0.07692307692307693yaの S0.07692307692307693ycブログ S0.07692307692307693yaを S0.07692307692307693yb移行 S0.07692307692307693>vb93:yeAzure S0.09090909090909091ya  S0.18181818181818182yiCognitive S0.09090909090909091yfSearch S0.09090909090909091yaで S0.09090909090909091yfインデックス S0.09090909090909091yaを S0.09090909090909091yb作っ S0.09090909090909091yaて S0.09090909090909091yb検索 S0.09090909090909091vb94<ya「 S0.08333333333333333yb検索 S0.08333333333333333ydシステム S0.08333333333333333yb探訪 S0.08333333333333333ya」 S0.08333333333333333yaし S0.08333333333333333ybたい S0.08333333333333333yaな S0.08333333333333333ya= S0.08333333333333333ya> S0.08333333333333333ydやりまし S0.08333333333333333yaた S0.08333333333333333>vb952yfボードゲームc0.5yb紹介c0.5vb966yb実践 S0.16666666666666666ydRust S0.16666666666666666yb入門 S0.16666666666666666yaは S0.16666666666666666ydじめまし S0.16666666666666666yaた S0.16666666666666666vb977yfフリーランス S0.14285714285714285yaは S0.14285714285714285ydじめまし S0.14285714285714285yaた S0.14285714285714285ya( S0.14285714285714285ya仮 S0.14285714285714285ya) S0.14285714285714285vb98;ya4 S0.07142857142857142ygブログ移行日記 S0.07142857142857142ya( S0.14285714285714285ybその S0.07142857142857142ya) S0.14285714285714285ya  S0.14285714285714285ya- S0.07142857142857142yd検索機能 S0.07142857142857142ygAlgolia S0.07142857142857142yaの S0.07142857142857142yb導入 S0.07142857142857142vb99<ya3d0.05ygブログ移行日記d0.05ya(c0.1ybそのd0.05ya)c0.1ya c0.1ya-d0.05ydHugod0.05yaのd0.05yb設定d0.05yaとd0.05yc微調整d0.05ycテーマd0.05yaにd0.05yb合わd0.05yaせd0.05yaたd0.05>vc100;ya2 S0.08333333333333333ygブログ移行日記 S0.08333333333333333ya( S0.08333333333333333ybその S0.08333333333333333ya) S0.08333333333333333ya  S0.16666666666666666ya- S0.08333333333333333yhMarkdown S0.08333333333333333ydファイル S0.08333333333333333yaの S0.08333333333333333yb変換 S0.08333333333333333vc101:ya1 S0.09090909090909091ygブログ移行日記 S0.09090909090909091ya( S0.09090909090909091ybその S0.09090909090909091ya) S0.09090909090909091ya  S0.18181818181818182ya- S0.09090909090909091ydHugo S0.09090909090909091yaと S0.09090909090909091ycテーマ S0.09090909090909091vc1029yiOctopress R0.1111111111111111ybから R0.1111111111111111ydHugo R0.1111111111111111yaへ R0.1111111111111111yc移行中 R0.1111111111111111ya( R0.1111111111111111ybまだ R0.1111111111111111yb途中 R0.1111111111111111ya) R0.1111111111111111vc103:yd2019 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091vc1047yemacOSe0.125yb標準e0.125yaのd0.25yeターミナルe0.125yiウィンドウグループe0.125yaがe0.125yb便利e0.125vc1052yihomeshickc0.5yb導入c0.5vc1064yczshd0.25yaへd0.25yaのd0.25yb移行d0.25vc1076yiOctopress S0.16666666666666666yb環境 S0.16666666666666666yaの S0.16666666666666666yfDocker S0.16666666666666666ydイメージ S0.16666666666666666ya化 S0.16666666666666666vc1082yb退職c0.5ycしますc0.5vc109:yfApache S0.09090909090909091ya  S0.09090909090909091yfLucene S0.09090909090909091yaの S0.18181818181818182yhKuromoji S0.09090909090909091yfUniDic S0.09090909090909091ycビルド S0.09090909090909091yb対応 S0.09090909090909091ycパッチ S0.09090909090909091ydについて S0.09090909090909091vc1106ye2019年 S0.14285714285714285yaの S0.14285714285714285ygElastic R0.2857142857142857ya  S0.14285714285714285yeStack S0.14285714285714285yaと S0.14285714285714285vc111<ya1 S0.06666666666666667ygBonfire S0.06666666666666667ya  S0.26666666666666666ydData S0.06666666666666667ya& S0.06666666666666667ygScience S0.06666666666666667ya# S0.06666666666666667yaに S0.06666666666666667yb参加 S0.06666666666666667yaし S0.06666666666666667ybまし S0.06666666666666667yaた S0.06666666666666667>vc1128ya2c0.1ymElasticsearchc0.1ya c0.3ydNEXTc0.1ydSTEPc0.1yaをc0.1yd頂きましc0.1yaたc0.1vc1138yc勉強会 R0.1111111111111111yaの R0.1111111111111111yb受付 R0.1111111111111111yb自作 R0.1111111111111111ya？ R0.2222222222222222ycアプリ R0.1111111111111111ydHTML R0.1111111111111111ydについて R0.1111111111111111vc1147yi勉強会運営座談会っe0.125yaてd0.25yaのe0.125yaをe0.125ybやっe0.125yaみe0.125yaたe0.125vc115<yfSearch T0.047619047619047616ya  S0.14285714285714285ykEngineering T0.047619047619047616ydTech T0.047619047619047616ydTalk T0.047619047619047616ya( T0.047619047619047616yg検索技術勉強会 T0.047619047619047616ya) T0.047619047619047616yaの T0.047619047619047616yb運営 T0.047619047619047616ycとして T0.047619047619047616yb参加 T0.047619047619047616yaし T0.047619047619047616yaて S0.09523809523809523yb始め T0.047619047619047616ycみまし T0.047619047619047616yaた T0.047619047619047616ya。 T0.047619047619047616>vc116:yd2018 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091vc117<ya0f0.0625ya7f0.0625ygElasticf0.0625ya e0.125yeStackf0.0625ya.f0.0625yaでf0.0625yb入っf0.0625yaてf0.0625ybくるf0.0625yc新機能f0.0625yaをf0.0625ycちょっf0.0625yaとf0.0625yb紹介f0.0625>vc1186ye2018年 S0.14285714285714285yaの S0.14285714285714285ygElastic R0.2857142857142857ya  S0.14285714285714285yeStack S0.14285714285714285yaと S0.14285714285714285vc1199yd新規導入 R0.1111111111111111yaし R0.1111111111111111yaた R0.1111111111111111ye長期出張用 R0.1111111111111111yaの R0.1111111111111111ydアイテム R0.1111111111111111yaを R0.1111111111111111ydいくつか R0.1111111111111111yb紹介 R0.1111111111111111vc1208yd第25回e0.125y PElasticsearch勉強会e0.125yaをe0.125yb開催e0.125yaしe0.125ybましe0.125yaたe0.125ya。e0.125vc1215ydJJUGc0.2ygナイトセミナーc0.2yaでc0.2yd話しましc0.2yaたc0.2vc122<ygAnalyze S0.07142857142857142ya  S0.07142857142857142ybUI S0.07142857142857142yaと S0.07142857142857142yfKibana S0.07142857142857142yaの S0.14285714285714285yeプラグイン S0.07142857142857142yb作成 S0.07142857142857142yb方法 S0.07142857142857142ya（ S0.07142857142857142ya第 S0.07142857142857142yb3回 S0.07142857142857142ya） S0.07142857142857142>vc123<ygカンファレンス S0.06666666666666667yb情報 S0.06666666666666667yaの S0.06666666666666667yb探し S0.06666666666666667ya方 S0.06666666666666667ya（ S0.06666666666666667ycCfP S0.06666666666666667ya、 S0.13333333333333333yeスポンサー S0.06666666666666667yb応募 S0.06666666666666667yd開催期間 S0.06666666666666667ybなど S0.06666666666666667ya） S0.06666666666666667ya？ S0.06666666666666667>vc124<yc第1章 S0.06666666666666667yaの S0.06666666666666667yb05 S0.06666666666666667ybから S0.06666666666666667yb06 S0.06666666666666667ybまで S0.06666666666666667ybやっ S0.06666666666666667yaて S0.06666666666666667yaみ S0.06666666666666667yaた S0.06666666666666667ya（ S0.06666666666666667yd言語処理 S0.06666666666666667yd100本 S0.06666666666666667ycノック S0.06666666666666667ya） S0.06666666666666667>vc125<yc第1章 S0.06666666666666667yaの S0.06666666666666667yb03 S0.06666666666666667ybから S0.06666666666666667yb04 S0.06666666666666667ybまで S0.06666666666666667ybやっ S0.06666666666666667yaて S0.06666666666666667yaみ S0.06666666666666667yaた S0.06666666666666667ya（ S0.06666666666666667yd言語処理 S0.06666666666666667yd100本 S0.06666666666666667ycノック S0.06666666666666667ya） S0.06666666666666667>vc126<yc第1章 S0.06666666666666667yaの S0.06666666666666667yb00 S0.06666666666666667ybから S0.06666666666666667yb02 S0.06666666666666667ybまで S0.06666666666666667ybやっ S0.06666666666666667yaて S0.06666666666666667yaみ S0.06666666666666667yaた S0.06666666666666667ya（ S0.06666666666666667yd言語処理 S0.06666666666666667yd100本 S0.06666666666666667ycノック S0.06666666666666667ya） S0.06666666666666667>vc1279yd言語処理 R0.1111111111111111yd100本 R0.1111111111111111ycノック R0.1111111111111111yaは R0.1111111111111111ydじめまし R0.1111111111111111yaた R0.1111111111111111ya( R0.1111111111111111ydRust R0.1111111111111111ya) R0.1111111111111111vc128<ygAnalyze S0.07142857142857142ya  S0.07142857142857142ybUI S0.07142857142857142yaと S0.07142857142857142yfKibana S0.07142857142857142yaの S0.14285714285714285yeプラグイン S0.07142857142857142yb作成 S0.07142857142857142yb方法 S0.07142857142857142ya（ S0.07142857142857142ya第 S0.07142857142857142yb2回 S0.07142857142857142ya） S0.07142857142857142>vc129<ygAnalyze S0.07142857142857142ya  S0.07142857142857142ybUI S0.07142857142857142yaと S0.07142857142857142yfKibana S0.07142857142857142yaの S0.14285714285714285yeプラグイン S0.07142857142857142yb作成 S0.07142857142857142yb方法 S0.07142857142857142ya（ S0.07142857142857142ya第 S0.07142857142857142yb1回 S0.07142857142857142ya） S0.07142857142857142>vc130:yd2017 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091vc1315ye2018年c0.2yaのc0.2ygElasticc0.2yaはc0.2ya？c0.2vc1326ye2017年 S0.14285714285714285yaの S0.14285714285714285ygElastic R0.2857142857142857ya  S0.14285714285714285yeStack S0.14285714285714285yaと S0.14285714285714285vc133:yhSwiftype S0.09090909090909091yaが S0.09090909090909091ydジョイン S0.09090909090909091yaし S0.09090909090909091yaた S0.18181818181818182yaの S0.09090909090909091yaで S0.09090909090909091yb触っ S0.09090909090909091yaて S0.09090909090909091ycみまし S0.09090909090909091vc134:ycデータc0.1yh分析基盤構築入門c0.1ya c0.1yaをc0.1yb一部c0.1yb執筆c0.1yaしc0.1ybましc0.1yaたc0.1ya。c0.1vc1357yf検索座談会っe0.125yaてd0.25yaのe0.125yaをe0.125ybやっe0.125yaみe0.125yaたe0.125vc136:yd2016 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091vc1375ye2016年c0.2yaのc0.2ygElasticc0.2ya c0.2yeStackc0.2vc1388ya0e0.125ya5e0.125ymElasticsearche0.125ya e0.125ya.e0.125yaのe0.125yf便利機能紹介e0.125ya？e0.125vc139<yfLucene S0.03571428571428571ya  S0.17857142857142858yhKuromoji S0.03571428571428571ycfor S0.03571428571428571ygNEologd S0.03571428571428571yaで S0.03571428571428571yb指定 S0.03571428571428571yaし S0.03571428571428571yaた S0.07142857142857142yb品詞 S0.03571428571428571yaの S0.03571428571428571yb単語 S0.03571428571428571yaを S0.07142857142857142yb抜き S0.03571428571428571yb出す S0.03571428571428571yfIngest S0.03571428571428571yfPlugin S0.03571428571428571yb書い S0.03571428571428571yaて S0.03571428571428571yaみ S0.03571428571428571ya# S0.03571428571428571yoelasticsearchjp S0.03571428571428571>vc1405ybよくc0.2ya物c0.2yaがc0.2yc壊れるc0.2ya年c0.2vc141;yd第16回 S0.09090909090909091y PElasticsearch勉強会 S0.09090909090909091yaを S0.09090909090909091yb開催 S0.09090909090909091yaし S0.09090909090909091ybまし S0.09090909090909091yaた S0.09090909090909091ya。 S0.09090909090909091ya  S0.09090909090909091ya# S0.09090909090909091yoelasticsearchjp S0.09090909090909091vc142;yd第15回 S0.09090909090909091y PElasticsearch勉強会 S0.09090909090909091yaを S0.09090909090909091yb開催 S0.09090909090909091yaし S0.09090909090909091ybまし S0.09090909090909091yaた S0.09090909090909091ya。 S0.09090909090909091ya  S0.09090909090909091ya# S0.09090909090909091yoelasticsearchjp S0.09090909090909091vc143:ya「c0.1yf自然言語処理c0.1yaのc0.1yb基本c0.1yaとc0.1yb技術c0.1ya」c0.1yaをc0.1yb読んc0.1ybでるc0.1vc144;yd第14回 S0.09090909090909091y PElasticsearch勉強会 S0.09090909090909091yaを S0.09090909090909091yb開催 S0.09090909090909091yaし S0.09090909090909091ybまし S0.09090909090909091yaた S0.09090909090909091ya。 S0.09090909090909091ya  S0.09090909090909091ya# S0.09090909090909091yoelasticsearchjp S0.09090909090909091vc145:yd2015 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091vc1463ye2015年 R0.3333333333333333yaの R0.3333333333333333ymElasticsearch R0.3333333333333333vc147:yd2015 S0.06666666666666667yhTimelion S0.06666666666666667yaの S0.06666666666666667yb紹介 S0.06666666666666667ya c0.4ya- S0.06666666666666667ymElasticsearch S0.06666666666666667yfAdvent S0.06666666666666667yhCalendar S0.06666666666666667yc1日目 S0.06666666666666667vc148:yd第13回c0.1y PElasticsearch勉強会c0.1yaをc0.1yb開催c0.1yaしc0.1ybましc0.1yaたc0.1ya。c0.1ya#c0.1yoelasticsearchjpc0.1vc149<ya0 S0.09523809523809523ya1 T0.047619047619047616ya2 T0.047619047619047616yeSense S0.09523809523809523yaの S0.09523809523809523yb歴史 T0.047619047619047616ya  S0.14285714285714285ya- S0.09523809523809523ya. S0.09523809523809523ydbeta T0.047619047619047616yb紹介 T0.047619047619047616ya( T0.047619047619047616yd日本語訳 T0.047619047619047616ya) T0.047619047619047616>vc150<ya0 S0.11764705882352941ya2 T0.058823529411764705yfShield T0.058823529411764705ya、 S0.11764705882352941ygWatcher T0.058823529411764705yfMarvel T0.058823529411764705ya  S0.11764705882352941ya. S0.11764705882352941ybGA T0.058823529411764705ydリリース T0.058823529411764705ya（ T0.058823529411764705yd日本語訳 T0.058823529411764705ya） T0.058823529411764705>vc1519ya0 S0.18181818181818182ya2 S0.09090909090909091ymElasticsearch S0.09090909090909091ya  S0.09090909090909091ya. S0.18181818181818182ydリリース S0.09090909090909091ya( S0.09090909090909091yd日本語訳 S0.09090909090909091ya) S0.09090909090909091vc152:ya0 S0.09090909090909091ya2 S0.09090909090909091ya4 S0.09090909090909091yfKibana S0.09090909090909091ya  S0.09090909090909091ya. S0.18181818181818182ydリリース S0.09090909090909091ya（ S0.09090909090909091yd日本語訳 S0.09090909090909091ya） S0.09090909090909091vc1539ya0 S0.18181818181818182ya2 S0.09090909090909091yhLogstash S0.09090909090909091ya  S0.09090909090909091ya. S0.18181818181818182ydリリース S0.09090909090909091ya（ S0.09090909090909091yd日本語訳 S0.09090909090909091ya） S0.09090909090909091vc1548ygRelease R0.1111111111111111ya, R0.1111111111111111ya  R0.2222222222222222ybwe R0.1111111111111111ydhave R0.1111111111111111ya（ R0.1111111111111111yd日本語訳 R0.1111111111111111ya） R0.1111111111111111vc155;ya0 S0.14285714285714285ya2 S0.14285714285714285ymElasticsearch S0.07142857142857142ya  S0.07142857142857142ya. S0.14285714285714285ya- S0.07142857142857142ydbeta S0.07142857142857142ydリリース S0.07142857142857142ya（ S0.07142857142857142yd日本語訳 S0.07142857142857142ya） S0.07142857142857142vc156<ya0f0.0625ya2f0.0625ymElasticsearchf0.0625ya f0.1875yiunpluggedf0.0625ya-f0.0625ya.f0.0625ydにおけるf0.0625yfネットワークf0.0625yaのf0.0625yb変更f0.0625ya(f0.0625yd日本語訳f0.0625ya)f0.0625>vc157<ya0 S0.14285714285714285ya1 S0.07142857142857142ya2 S0.07142857142857142ymElasticsearch S0.07142857142857142ya  S0.07142857142857142ya. S0.14285714285714285ya- S0.07142857142857142ydbeta S0.07142857142857142ydリリース S0.07142857142857142ya（ S0.07142857142857142yd日本語訳 S0.07142857142857142ya） S0.07142857142857142>vc158;yfDelete S0.07692307692307693ya  S0.23076923076923078ybby S0.07692307692307693yeQuery S0.07692307692307693ycAPI S0.07692307692307693yaは S0.07692307692307693yeプラグイン S0.07692307692307693yaへ S0.07692307692307693ya（ S0.07692307692307693yd日本語訳 S0.07692307692307693ya） S0.07692307692307693vc159:yd第11回c0.1y PElasticsearch勉強会c0.1yaをc0.1yb開催c0.1yaしc0.1ybましc0.1yaたc0.1ya。c0.1ya#c0.1yoelasticsearchjpc0.1vc160<ya1 S0.15789473684210525ya2 S0.05263157894736842ya6 S0.05263157894736842ya7 S0.05263157894736842ymElasticsearch S0.05263157894736842ya  S0.15789473684210525ya. S0.21052631578947367ycおよび S0.05263157894736842ydリリース S0.05263157894736842ya（ S0.05263157894736842yd日本語訳 S0.05263157894736842ya） S0.05263157894736842>vc161<ya0 S0.05263157894736842ya1 S0.15789473684210525ya6 S0.05263157894736842ya7 S0.05263157894736842ymElasticsearch S0.05263157894736842ya  S0.15789473684210525ya. S0.21052631578947367ycおよび S0.05263157894736842ydリリース S0.05263157894736842ya（ S0.05263157894736842yd日本語訳 S0.05263157894736842ya） S0.05263157894736842>vc162<yb大阪 S0.07142857142857142yaと S0.07142857142857142yb京都 S0.07142857142857142yaで S0.07142857142857142y PElasticsearch勉強会 S0.07142857142857142yaを S0.07142857142857142yb開催 S0.07142857142857142yaし S0.07142857142857142ybまし S0.07142857142857142yaた S0.07142857142857142ya。 S0.07142857142857142ya  S0.07142857142857142ya# S0.07142857142857142yoelasticsearchjp S0.07142857142857142>vc1637ygMapping S0.14285714285714285yaの S0.14285714285714285yeすばらしい S0.14285714285714285yhリファクタリング S0.14285714285714285ya（ S0.14285714285714285yd日本語訳 S0.14285714285714285ya） S0.14285714285714285vc164<ya0 S0.13333333333333333ya1 S0.06666666666666667ya2 S0.06666666666666667ymElasticsearch S0.06666666666666667ya  S0.06666666666666667ya.c0.2ydbeta S0.06666666666666667ydリリース S0.06666666666666667yb間近 S0.06666666666666667ya（ S0.06666666666666667yd日本語訳 S0.06666666666666667ya） S0.06666666666666667>vc1659ybさら R0.1111111111111111yaに R0.1111111111111111yb進化 R0.1111111111111111yaし R0.1111111111111111yaた R0.1111111111111111yeFound R0.1111111111111111ya（ R0.1111111111111111yd日本語訳 R0.1111111111111111ya） R0.1111111111111111vc166<ylJustTechTalk S0.05555555555555555ya# S0.05555555555555555yb02 S0.05555555555555555ya  S0.05555555555555555ye形態素解析 S0.05555555555555555yaの S0.05555555555555555ybあれ S0.05555555555555555yaや R0.1111111111111111ybこれ S0.05555555555555555ya@ S0.05555555555555555yhジャストシステム S0.05555555555555555yaに S0.05555555555555555yb参加 S0.05555555555555555yaし S0.05555555555555555ybまし S0.05555555555555555yaた S0.05555555555555555ya。 S0.05555555555555555>vc167<ya5 T0.047619047619047616yfHatena T0.047619047619047616ya  R0.2857142857142857yhEngineer T0.047619047619047616ygSeminar T0.047619047619047616ya# S0.09523809523809523ya@ T0.047619047619047616yeTokyo T0.047619047619047616yaに T0.047619047619047616yb参加 T0.047619047619047616yaし T0.047619047619047616ybまし T0.047619047619047616yaた T0.047619047619047616ya。 T0.047619047619047616yjhatenatech T0.047619047619047616>vc168:ya0 S0.09090909090909091ya1 S0.09090909090909091ya6 S0.09090909090909091ymElasticsearch S0.09090909090909091ya  S0.09090909090909091ya. S0.18181818181818182ydリリース S0.09090909090909091ya（ S0.09090909090909091yd日本語訳 S0.09090909090909091ya） S0.09090909090909091vc169:yd第10回c0.1y PElasticsearch勉強会c0.1yaをc0.1yb開催c0.1yaしc0.1ybましc0.1yaたc0.1ya。c0.1ya#c0.1yoelasticsearchjpc0.1vc170;yhLogstash S0.09090909090909091yaを S0.09090909090909091yb使っ S0.09090909090909091yaた S0.09090909090909091ymElasticsearch S0.09090909090909091yaの S0.09090909090909091ya再 S0.09090909090909091yfインデックス S0.09090909090909091ya（ S0.09090909090909091yd日本語訳 S0.09090909090909091ya） S0.09090909090909091vc1718ygdiscuss R0.1111111111111111ya. R0.2222222222222222ygelastic R0.1111111111111111ybco R0.1111111111111111ya  R0.1111111111111111ycにぜひ R0.1111111111111111yb参加 R0.1111111111111111yaを R0.1111111111111111vc172<ya1 S0.10526315789473684ya2 S0.05263157894736842ya4 S0.05263157894736842ya5 S0.10526315789473684ymElasticsearch S0.05263157894736842ya  S0.15789473684210525ya. S0.21052631578947367ycおよび S0.05263157894736842ydリリース S0.05263157894736842ya（ S0.05263157894736842yd日本語訳 S0.05263157894736842ya） S0.05263157894736842>vc173:yc第9回c0.1y PElasticsearch勉強会c0.1yaをc0.1yb開催c0.1yaしc0.1ybましc0.1yaたc0.1ya。c0.1ya#c0.1yoelasticsearchjpc0.1vc1749ya1 S0.18181818181818182ya5 S0.09090909090909091ymElasticsearch S0.09090909090909091ya  S0.09090909090909091ya. S0.18181818181818182ydリリース S0.09090909090909091ya（ S0.09090909090909091yd日本語訳 S0.09090909090909091ya） S0.09090909090909091vc175<y PElasticsearch勉強会f0.0625ya f0.1875ybinf0.0625yc名古屋f0.0625yaをf0.0625yb開催f0.0625yaしf0.0625ybましf0.0625yaたf0.0625ya。f0.0625ya#e0.125ymelasticsearchf0.0625yoelasticsearchjpf0.0625>vc176:ya0 S0.09090909090909091ya1 S0.09090909090909091ya5 S0.09090909090909091ymElasticsearch S0.09090909090909091ya  S0.09090909090909091ya. S0.18181818181818182ydリリース S0.09090909090909091ya（ S0.09090909090909091yd日本語訳 S0.09090909090909091ya） S0.09090909090909091vc1775ya#c0.2yielasticonc0.2ya c0.2yaにc0.2yc参加中c0.2vc1789yfセキュリティ R0.1111111111111111yb向け R0.1111111111111111yeプラグイン R0.1111111111111111yfShield R0.1111111111111111yaの R0.1111111111111111ydリリース R0.1111111111111111ya（ R0.1111111111111111yd日本語訳 R0.1111111111111111ya） R0.1111111111111111vc1795ymElasticsearchc0.2ya c0.2ydCorec0.2yfトレーニングc0.2yb開催c0.2vc1806ya4 S0.16666666666666666yfKibana S0.16666666666666666ya  S0.16666666666666666ya（ S0.16666666666666666yd日本語訳 S0.16666666666666666ya） S0.16666666666666666vc181<ya1 S0.11764705882352941ya3 T0.058823529411764705ya4 S0.11764705882352941ya9 T0.058823529411764705ymElasticsearch T0.058823529411764705ya  T0.058823529411764705ya. S0.23529411764705882ycおよび T0.058823529411764705ydリリース T0.058823529411764705ya（ T0.058823529411764705yd日本語訳 T0.058823529411764705ya） T0.058823529411764705>vc1827yc名古屋 S0.14285714285714285yaで S0.14285714285714285y PElasticsearch勉強会 S0.14285714285714285yaを S0.14285714285714285yb開催 S0.14285714285714285yaし S0.14285714285714285ybます S0.14285714285714285vc183:yc第8回c0.1y PElasticsearch勉強会c0.1yaをc0.1yb開催c0.1yaしc0.1ybましc0.1yaたc0.1ya。c0.1ya#c0.1yoelasticsearchjpc0.1vc184:yfGroovyc0.1yeスクリプトc0.1yaをc0.1ykダイナミックスクリプトc0.1ybなしc0.1yaでc0.1yb実行c0.1ya(c0.1yd日本語訳c0.1ya)c0.1vc185<ya1 S0.11764705882352941ya3 S0.11764705882352941ya4 T0.058823529411764705ya8 T0.058823529411764705ymElasticsearch T0.058823529411764705ya　 T0.058823529411764705ya. S0.23529411764705882ycおよび T0.058823529411764705ydリリース T0.058823529411764705ya（ T0.058823529411764705yd日本語訳 T0.058823529411764705ya） T0.058823529411764705>vc186;yd2015 S0.15384615384615385yeCROSS S0.07692307692307693ya  S0.15384615384615385yaで S0.07692307692307693ya話 S0.07692307692307693yaを S0.07692307692307693ybして S0.07692307692307693ycきまし S0.07692307692307693yaた S0.07692307692307693ya# S0.07692307692307693yecross S0.07692307692307693vc187:yd2014 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091vc1888ya2 R0.1111111111111111ymElasticsearch R0.1111111111111111ya  R0.1111111111111111ya. R0.1111111111111111yb0系 R0.1111111111111111yaの R0.2222222222222222yeIssue R0.1111111111111111yb紹介 R0.1111111111111111vc189:ya0 S0.09090909090909091ya1 S0.09090909090909091ya3 S0.09090909090909091yfMarvel S0.09090909090909091ya  S0.09090909090909091ya. S0.18181818181818182ydリリース S0.09090909090909091ya（ S0.09090909090909091yd日本語訳 S0.09090909090909091ya） S0.09090909090909091vc190<ya1 S0.11764705882352941ya2 T0.058823529411764705ya3 T0.058823529411764705ya4 T0.058823529411764705ya7 T0.058823529411764705ymElasticsearch T0.058823529411764705ya  T0.058823529411764705ya. S0.23529411764705882ycおよび T0.058823529411764705ydリリース T0.058823529411764705ya（ T0.058823529411764705yd日本語訳 T0.058823529411764705ya） T0.058823529411764705>vc191<ydJJUGe0.125ya f0.0625ygナイトセミナーf0.0625yaでf0.0625yfLucenef0.0625yaのf0.0625yb簡単f0.0625yaなf0.0625yb紹介f0.0625yaをf0.0625ybしてf0.0625ycきましf0.0625yaたf0.0625ya。f0.0625ya#f0.0625>vc1921yhコーヒーブレイクQvc1938yhLogstash R0.1111111111111111yeプラグイン R0.1111111111111111yaの R0.2222222222222222yfエコシステム R0.1111111111111111yb変更 R0.1111111111111111ya（ R0.1111111111111111yd日本語訳 R0.1111111111111111ya） R0.1111111111111111vc194;ya0 S0.07142857142857142ya1 S0.14285714285714285ya5 S0.07142857142857142yhLogstash S0.07142857142857142ya  S0.14285714285714285ya. S0.14285714285714285ydBeta S0.07142857142857142ydリリース S0.07142857142857142ya( S0.07142857142857142yd日本語訳 S0.07142857142857142ya) S0.07142857142857142vc1953ye2014年 R0.3333333333333333yaの R0.3333333333333333ymElasticsearch R0.3333333333333333vc196<ya1 S0.17647058823529413ya3 T0.058823529411764705ya4 T0.058823529411764705ya6 T0.058823529411764705ymElasticsearch T0.058823529411764705ya  T0.058823529411764705ya. S0.23529411764705882ycおよび T0.058823529411764705ydリリース T0.058823529411764705ya（ T0.058823529411764705yd日本語訳 T0.058823529411764705ya） T0.058823529411764705>vc1973ylインデックステンプレート R0.3333333333333333yaと R0.3333333333333333yhLogstash R0.3333333333333333vc1989yhLogstash R0.1111111111111111yaを R0.1111111111111111yb利用 R0.1111111111111111yaし R0.1111111111111111yaた R0.1111111111111111yfApache R0.1111111111111111yfアクセスログ R0.1111111111111111yaの R0.1111111111111111yeインポート R0.1111111111111111vc199:yc第7回c0.1y PElasticsearch勉強会c0.1yaをc0.1yb開催c0.1yaしc0.1ybましc0.1yaたc0.1ya。c0.1ya#c0.1yoelasticsearchjpc0.1vc200<ya0 T0.058823529411764705ya1 S0.11764705882352941ya3 T0.058823529411764705ya4 T0.058823529411764705ya5 T0.058823529411764705ymElasticsearch T0.058823529411764705ya  T0.058823529411764705ya. S0.23529411764705882ycおよび T0.058823529411764705ydリリース T0.058823529411764705ya（ T0.058823529411764705yd日本語訳 T0.058823529411764705ya） T0.058823529411764705>vc2015yhvalidatec0.2ya c0.2ycAPIc0.2yaのc0.2yb利用c0.2vc2027yhSonatype R0.1111111111111111yaの R0.2222222222222222yeバージョン R0.1111111111111111yb番号 R0.1111111111111111yaで R0.2222222222222222yb困っ R0.1111111111111111yaた R0.1111111111111111vc2039ya0 S0.08333333333333333ya1 S0.16666666666666666ya4 S0.08333333333333333ymelasticsearch S0.08333333333333333ya  S0.08333333333333333ya.d0.25ydBeta S0.08333333333333333yaの S0.08333333333333333ydリリース S0.08333333333333333vc204:yc第6回c0.1y PElasticsearch勉強会c0.1yaをc0.1yb開催c0.1yaしc0.1ybましc0.1yaたc0.1ya。c0.1ya#c0.1yoelasticsearchjpc0.1vc205<ymelasticsearchf0.0625ya.f0.0625yeもうちょっf0.0625yaとf0.0625yb入門f0.0625ycというf0.0625ya話f0.0625yaをf0.0625ybしてf0.0625ycきましf0.0625yaたf0.0625ya f0.0625ya#f0.0625yegihyof0.0625ya_f0.0625ycefkf0.0625>vc2067ymElasticsearch S0.14285714285714285yaの S0.14285714285714285ygインデキシング S0.14285714285714285yaに S0.14285714285714285yc関する S0.14285714285714285ygパフォーマンス S0.14285714285714285yb検討 S0.14285714285714285vc207<ycサーバ S0.07142857142857142ya/ S0.07142857142857142ymインフラエンジニア養成読本 S0.07142857142857142ya  S0.14285714285714285ybログ S0.07142857142857142yb収集 S0.07142857142857142ya~ S0.07142857142857142yd可視化編 S0.07142857142857142yaを S0.07142857142857142yb手伝 S0.07142857142857142yaい S0.07142857142857142ybまし S0.07142857142857142yaた S0.07142857142857142>vc2087ydプロキシe0.125yb環境e0.125yaでe0.125yaのd0.25yfplugine0.125ydコマンドe0.125yb実行e0.125vc2099ya1 S0.16666666666666666ya3 S0.08333333333333333ymElasticsearch S0.08333333333333333ya  S0.16666666666666666ya. S0.16666666666666666ydリリース S0.08333333333333333ya（ S0.08333333333333333yd日本語訳 S0.08333333333333333ya） S0.08333333333333333vc2107ya1c0.3ya2c0.1ygCuratorc0.1ya c0.1ya.c0.2ycおよびc0.1ydについてc0.1vc211:yc第5回c0.1y PElasticsearch勉強会c0.1yaをc0.1yb開催c0.1yaしc0.1ybましc0.1yaたc0.1ya。c0.1ya#c0.1yoelasticsearchjpc0.1vc2124yb転職d0.25yaしd0.25ybましd0.25yaたd0.25vc2134yb退職d0.25yaしd0.25ybましd0.25yaたd0.25vc2147ymElasticsearch R0.1111111111111111ya  R0.3333333333333333yfserver R0.1111111111111111yc2nd R0.1111111111111111ygedition R0.1111111111111111yaの R0.1111111111111111ymファーストインプレッション R0.1111111111111111vc215;yc可視化 S0.16666666666666666ycツール S0.08333333333333333ye現状確認会 S0.08333333333333333yaに S0.08333333333333333yb参加 S0.08333333333333333yaし S0.08333333333333333yaて S0.08333333333333333ycきまし S0.08333333333333333yaた S0.08333333333333333ya。 S0.08333333333333333ya# S0.08333333333333333vc2168yb最新e0.125ymインフラエンジニア技術勉強e0.125yaにe0.125yb参加e0.125yaしe0.125ybましe0.125yaたe0.125ya。e0.125vc217<ya「 S0.07142857142857142yeよくわかる S0.07142857142857142yfAmazon S0.07142857142857142ya  S0.14285714285714285ya# S0.07142857142857142ykCloudSearch S0.07142857142857142ya」 S0.07142857142857142yaに S0.07142857142857142yb行っ S0.07142857142857142yaて S0.07142857142857142ycきまし S0.07142857142857142yaた S0.07142857142857142ya！ S0.07142857142857142>vc2187ya外 S0.14285714285714285yaの S0.14285714285714285yb世界 S0.14285714285714285yaを S0.14285714285714285yb知る S0.14285714285714285ycという S0.14285714285714285ybこと S0.14285714285714285vc2194ymアジャイルデータサイエンスd0.25yaがd0.25yd届きましd0.25yaたd0.25vc2208ylAggregations R0.1111111111111111ya  R0.2222222222222222ya- R0.1111111111111111yeファセット R0.1111111111111111ycよりも R0.1111111111111111yb柔軟 R0.1111111111111111yaな R0.1111111111111111yb集計 R0.1111111111111111vc2219ymelasticsearch R0.1111111111111111ya- R0.1111111111111111ydkopf R0.1111111111111111yaの R0.1111111111111111yb紹介 R0.1111111111111111ya（ R0.1111111111111111ygaliases R0.1111111111111111yb画面 R0.1111111111111111ya） R0.1111111111111111vc2228ya2e0.125yfstreame0.125ybese0.125yaとe0.125yb複数e0.125ycデータe0.125yaのe0.125yb登録e0.125vc223:yc第4回c0.1y PElasticsearch勉強会c0.1yaをc0.1yb開催c0.1yaしc0.1ybましc0.1yaたc0.1ya。c0.1ya#c0.1yoelasticsearchjpc0.1vc2249ymelasticsearch R0.1111111111111111ya- R0.1111111111111111ydkopf R0.1111111111111111yaの R0.1111111111111111yb紹介 R0.1111111111111111ya（ R0.1111111111111111yhanalysis R0.1111111111111111yb画面 R0.1111111111111111ya） R0.1111111111111111vc225<ycJVM S0.06666666666666667ya  S0.26666666666666666yiOperation S0.06666666666666667yfCasual S0.06666666666666667yeTalks S0.06666666666666667yaに S0.06666666666666667yb参加 S0.06666666666666667yaし S0.06666666666666667ybまし S0.06666666666666667yaた S0.06666666666666667ya# S0.06666666666666667yijvmcasual S0.06666666666666667>vc2269ymelasticsearch R0.1111111111111111ya- R0.1111111111111111ydkopf R0.1111111111111111yaの R0.1111111111111111yb紹介 R0.1111111111111111ya（ R0.1111111111111111ydrest R0.1111111111111111yb画面 R0.1111111111111111ya） R0.1111111111111111vc2278ymelasticsearche0.125ya-e0.125ydkopfe0.125yaのe0.125yb紹介e0.125ya（e0.125yb概要e0.125ya）e0.125vc228<ymElasticSearch S0.07692307692307693ya  S0.07692307692307693yjServer日本語版 S0.07692307692307693ya（ S0.07692307692307693yc電子版 S0.07692307692307693yaも S0.07692307692307693ya） S0.07692307692307693yaが S0.07692307692307693yb発売 S0.07692307692307693yaさ S0.07692307692307693yaれ S0.07692307692307693ybまし S0.07692307692307693yaた S0.07692307692307693>vc2299ydGOTOc0.1ya c0.2yeNightc0.1ymelasticsearchc0.1yaにc0.1yb参加c0.1yaしc0.1ybましc0.1yaたc0.1vc2305yfBerlinc0.2ycからおc0.2yaはc0.2ybようc0.2yeございますc0.2vc2317ycいつも S0.14285714285714285yb入れ S0.14285714285714285yaて S0.14285714285714285ybいる S0.14285714285714285ymElasticsearch S0.14285714285714285yaの S0.14285714285714285yeプラグイン S0.14285714285714285vc2328ymElasticSearche0.125ya e0.125yfServere0.125yaをe0.125yb翻訳e0.125yaしe0.125ybましe0.125yaたe0.125vc2338yfNested R0.1111111111111111ya  R0.1111111111111111yfObject R0.1111111111111111yaの R0.2222222222222222yeフィールド R0.1111111111111111yb奇妙 R0.1111111111111111yaな R0.1111111111111111yb動作 R0.1111111111111111vc234;yc第3回 S0.09090909090909091y Pelasticsearch勉強会 S0.09090909090909091yaを S0.09090909090909091yb開催 S0.09090909090909091yaし S0.09090909090909091ybまし S0.09090909090909091yaた S0.09090909090909091ya！ S0.09090909090909091ya  S0.09090909090909091ya# S0.09090909090909091yoelasticsearchjp S0.09090909090909091vc235<yfすずけんさん S0.06666666666666667yaの S0.06666666666666667ybメモ S0.06666666666666667yaを S0.13333333333333333ya元 S0.06666666666666667yaに S0.06666666666666667ygVagrant S0.06666666666666667yaで S0.06666666666666667y QElasticsearchクラスタ S0.06666666666666667yb起動 S0.06666666666666667yaし S0.06666666666666667yaて S0.06666666666666667yaみ S0.06666666666666667yaた S0.06666666666666667>vc2368yd第13回e0.125ydSolre0.125yc勉強会e0.125yaをe0.125yb開催e0.125yaしe0.125ybましe0.125yaたe0.125vc2377ymElasticsearch S0.14285714285714285ya  S0.14285714285714285yfMarvel S0.14285714285714285yaの S0.14285714285714285yb紹介 S0.14285714285714285yaと S0.14285714285714285yd第一印象 S0.14285714285714285vc238<ya1 S0.07142857142857142ya4 S0.07142857142857142ya6 S0.07142857142857142yflucene S0.07142857142857142ya- S0.07142857142857142yegosen S0.07142857142857142ya  S0.07142857142857142ya. S0.14285714285714285yaの S0.07142857142857142ydリリース S0.07142857142857142yaに S0.07142857142857142yc関する S0.07142857142857142yc注意点 S0.07142857142857142>vc239:ygCuratorc0.1ya:c0.1ya c0.1yc時系列c0.1yfインデックスc0.1yaのc0.1yb管理c0.1ya(c0.1yd日本語訳c0.1ya)c0.1vc240<ya0 S0.13333333333333333ya1 S0.13333333333333333yhExtended S0.06666666666666667ya- S0.06666666666666667ygAnalyze S0.06666666666666667ya  S0.06666666666666667ya. S0.13333333333333333ybRC S0.06666666666666667yaを S0.06666666666666667ydリリース S0.06666666666666667ycしまし S0.06666666666666667yaた S0.06666666666666667>vc241:yd2013 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091vc242<ya0 T0.045454545454545456ya8 T0.045454545454545456yb12 T0.045454545454545456yb90 T0.045454545454545456yd2013 T0.045454545454545456ymElasticsearch T0.045454545454545456ya  T0.045454545454545456ya. S0.09090909090909091yaが T0.045454545454545456ydリリース T0.045454545454545456yaさ T0.045454545454545456yaれ T0.045454545454545456ybまし T0.045454545454545456yaた T0.045454545454545456ya＆ T0.045454545454545456yc注意点 T0.045454545454545456ya（ T0.045454545454545456ya/ S0.09090909090909091yd20追記 T0.045454545454545456ya） T0.045454545454545456>vc2437ydSolre0.125yaへe0.125yaのd0.25yeプラグインe0.125yb配置e0.125yb方法e0.125ydについてe0.125vc244;ymelasticsearch S0.08333333333333333ya- S0.16666666666666666yhextended S0.08333333333333333yganalyze S0.08333333333333333yeプラグイン S0.08333333333333333yaを S0.08333333333333333yeMaven S0.08333333333333333yaと S0.08333333333333333yhSonatype S0.08333333333333333yaに S0.08333333333333333ydリリース S0.08333333333333333vc2458yc改訂版e0.125ydSolre0.125yb入門e0.125yaのe0.125ycPDFe0.125ya版e0.125yaもe0.125yb発売e0.125vc2468yc改訂版e0.125ydSolre0.125yb入門e0.125yaをe0.125yb執筆e0.125yaしe0.125ybましe0.125yaたe0.125vc2477ymelasticsearche0.125ya-d0.25yhextendede0.125yganalyzee0.125yaをe0.125yb公開e0.125ya？e0.125vc248;yc第2回 S0.09090909090909091y Pelasticsearch勉強会 S0.09090909090909091yaを S0.09090909090909091yb開催 S0.09090909090909091yaし S0.09090909090909091ybまし S0.09090909090909091yaた S0.09090909090909091ya！ S0.09090909090909091ya  S0.09090909090909091ya# S0.09090909090909091yoelasticsearchjp S0.09090909090909091vc249<yd2013 R0.1111111111111111yhCloudera S0.05555555555555555ya  R0.2777777777777778yeWorld S0.05555555555555555yeTokyo S0.05555555555555555yaに S0.05555555555555555yb参加 S0.05555555555555555yaし S0.05555555555555555ybまし S0.05555555555555555yaた S0.05555555555555555ya！ S0.05555555555555555ya# S0.05555555555555555yccwt S0.05555555555555555>vc250<ya3f0.0625ydRiakf0.0625ya d0.25yfMeetupf0.0625ya#e0.125yfriakjpf0.0625yaにf0.0625yb参加f0.0625yaしf0.0625ybましf0.0625yaたf0.0625ya。f0.0625>vc2516ymelasticsearch S0.14285714285714285ya- R0.2857142857142857yhextended S0.14285714285714285yganalyze S0.14285714285714285yaの S0.14285714285714285yb改良 S0.14285714285714285vc2527ymelasticsearche0.125ya-d0.25yhextendede0.125yganalyzee0.125yeプラグインe0.125yaをe0.125yc開発中e0.125vc253;yd第12回 S0.09090909090909091ydSolr S0.09090909090909091yc勉強会 S0.09090909090909091yaを S0.09090909090909091yb主催 S0.09090909090909091yaし S0.09090909090909091ybまし S0.09090909090909091yaた S0.09090909090909091ya。 S0.09090909090909091ya# S0.09090909090909091yfSolrJP S0.09090909090909091vc2546ymelasticsearch S0.16666666666666666ya- S0.16666666666666666yjinquisitor S0.16666666666666666yeプラグイン S0.16666666666666666yaの S0.16666666666666666yb紹介 S0.16666666666666666vc2556ymelasticsearch S0.14285714285714285ya- R0.2857142857142857yeriver S0.14285714285714285yiwikipedia S0.14285714285714285yaの S0.14285714285714285yc疑問点 S0.14285714285714285vc2568yc日本語e0.125yiWikipediae0.125yaをe0.125ygインデクシングe0.125ya（e0.125yhKuromojie0.125yeバージョンe0.125ya）e0.125vc257;yc第1回 S0.09090909090909091y PElasticSearch勉強会 S0.09090909090909091yaを S0.09090909090909091yb開催 S0.09090909090909091yaし S0.09090909090909091ybまし S0.09090909090909091yaた S0.09090909090909091ya！ S0.09090909090909091ya  S0.09090909090909091ya# S0.09090909090909091yoelasticsearchjp S0.09090909090909091vc258<ymElasticSearch S0.08333333333333333yaに S0.08333333333333333yeプラグイン S0.08333333333333333yaで S0.08333333333333333yc日本語 S0.08333333333333333yiWikipedia S0.08333333333333333ycデータ S0.08333333333333333yaを S0.08333333333333333yb入れ S0.08333333333333333yaて S0.08333333333333333ycみまし S0.08333333333333333yaた S0.08333333333333333>vc259;yjMorphlines S0.09090909090909091yaの S0.09090909090909091yhloadSolr S0.09090909090909091yaを S0.09090909090909091ycちょっ S0.09090909090909091yaと S0.09090909090909091ybだけ S0.09090909090909091yb調べ S0.09090909090909091yaて S0.09090909090909091yaみ S0.09090909090909091yaた S0.09090909090909091vc260;yfXperia S0.06666666666666667ya  S0.06666666666666667yaZ S0.06666666666666667yaが S0.06666666666666667yb故障 S0.06666666666666667yaし S0.13333333333333333yaた S0.13333333333333333yaの S0.13333333333333333yaで S0.13333333333333333yb交換 S0.06666666666666667ybメモ S0.06666666666666667vc2613yjMorphlines R0.3333333333333333yb入門 R0.3333333333333333ya？ R0.3333333333333333vc262;yd第11回 S0.09090909090909091ydSolr S0.09090909090909091yc勉強会 S0.09090909090909091yaを S0.09090909090909091yb主催 S0.09090909090909091yaし S0.09090909090909091ybまし S0.09090909090909091yaた S0.09090909090909091ya。 S0.09090909090909091ya# S0.09090909090909091yfSolrJP S0.09090909090909091vc263<ya『 S0.08333333333333333ygプログラミング T0.041666666666666664ya  S0.16666666666666666ydHive T0.041666666666666664ya』 S0.08333333333333333yfHadoop T0.041666666666666664ya第 T0.041666666666666664yb3版 T0.041666666666666664yd刊行記念 T0.041666666666666664ydセミナー T0.041666666666666664yaに T0.041666666666666664yb参加 T0.041666666666666664yaし T0.041666666666666664ybまし T0.041666666666666664yaた T0.041666666666666664ya！ T0.041666666666666664ya# T0.041666666666666664ygoreilly T0.041666666666666664yd0724 T0.041666666666666664>vc2648yhYokozuna R0.1111111111111111yaの R0.1111111111111111ya気 R0.1111111111111111yaに R0.1111111111111111ybなる R0.1111111111111111ya点 R0.1111111111111111ydというか R0.2222222222222222ybなん R0.1111111111111111vc265<ya2f0.0625ydRiakf0.0625ya f0.1875yfMeetupf0.0625yeTokyof0.0625ya#e0.125yaにf0.0625yb参加f0.0625yaしf0.0625ybましf0.0625yaたf0.0625ya。f0.0625yfriakjpf0.0625>vc266<yd4897 S0.07692307692307693yiスキーマレスモード S0.07692307692307693ya？ S0.07692307692307693ya（ S0.07692307692307693ydSOLR S0.07692307692307693ya- S0.07692307692307693ya） S0.07692307692307693yaを S0.07692307692307693yb調べ S0.07692307692307693yaて S0.07692307692307693yc見まし S0.07692307692307693yaた S0.07692307692307693ya。 S0.07692307692307693>vc2677ydSolr S0.14285714285714285yaの S0.14285714285714285yb管理 S0.14285714285714285yb画面 S0.14285714285714285yaで S0.14285714285714285ycデータ S0.14285714285714285yb登録 S0.14285714285714285vc2686ya3 S0.16666666666666666yfKibana S0.16666666666666666ycという S0.16666666666666666yaの S0.16666666666666666yaも S0.16666666666666666yeありまして S0.16666666666666666vc2697yeBashoe0.125ya e0.125yeJapane0.125yaにd0.25yb遊びe0.125yd行きましe0.125yaたe0.125vc2708yc新しいe0.125ydsolre0.125ya.e0.125ycxmle0.125yaとe0.125ydCoree0.125yb探索e0.125ydロジックe0.125vc271;yfapached0.05ya-d0.05yfloggend0.05ya c0.4ya+d0.15ygfluentdd0.05ymelasticsearchd0.05yfkibanad0.05ya=d0.05ydログ検索d0.05ybデモd0.05vc272<ya2d0.05yd2013d0.05ycAWSd0.05ya c0.2yfSummitd0.05yeTokyod0.05yaにd0.05yb行っd0.05yaてd0.05yc来ましd0.05yaたd0.05ya。d0.05ya(d0.05ycDayd0.05ya)d0.05ya#d0.05yiawssummitd0.05>vc2737yhCloudera S0.14285714285714285ya  S0.14285714285714285yfSearch S0.14285714285714285ybメモ S0.14285714285714285ya（ S0.14285714285714285yc妄想版 S0.14285714285714285ya） S0.14285714285714285vc274<ya1d0.05yd2013d0.05ycAWSd0.05ya c0.2yfSummitd0.05yeTokyod0.05yaにd0.05yb行っd0.05yaてd0.05yc来ましd0.05yaたd0.05ya。d0.05ya(d0.05ycDayd0.05ya)d0.05ya#d0.05yiawssummitd0.05>vc2756yhCloudera S0.16666666666666666ya  S0.16666666666666666yfSearch S0.16666666666666666yaの S0.16666666666666666yeモジュール S0.16666666666666666ybたち S0.16666666666666666vc276<yhCloudera S0.07142857142857142ya  S0.07142857142857142yhSearchって S0.07142857142857142yaの S0.07142857142857142yaが S0.07142857142857142ya出 S0.07142857142857142ydたらしい S0.07142857142857142ya（ S0.07142857142857142ybとり S0.07142857142857142ycあえず S0.07142857142857142ya、 S0.07142857142857142yb雑感 S0.07142857142857142ya？ S0.07142857142857142ya） S0.07142857142857142>vc2779yffluentc0.1ya-c0.2yfpluginc0.1ylzoomdata作りましc0.1yaたc0.1ya＋c0.1yb悩みc0.1yb事とc0.1yaかc0.1vc2789yiOctopress R0.1111111111111111yaを R0.1111111111111111yb試し R0.1111111111111111ya中 R0.1111111111111111ya( R0.1111111111111111yeJugem R0.1111111111111111ybより R0.1111111111111111yb移植 R0.1111111111111111ya) R0.1111111111111111vc2791ynOctopress始めましたQvc280<ya0 S0.05555555555555555ya3 S0.05555555555555555ya4 S0.05555555555555555yflucene T0.027777777777777776ya- T0.027777777777777776yegosen T0.027777777777777776ya. R0.1111111111111111yaを T0.027777777777777776ydリリース T0.027777777777777776ycしまし T0.027777777777777776yaた T0.027777777777777776ya。 T0.027777777777777776ya（ T0.027777777777777776yfLucene T0.027777777777777776ya/ T0.027777777777777776ydSolr T0.027777777777777776yb以上 T0.027777777777777776yaで S0.05555555555555555yaの T0.027777777777777776yb利用 T0.027777777777777776yaが T0.027777777777777776yb可能 T0.027777777777777776yaす T0.027777777777777776ya） T0.027777777777777776ya( T0.027777777777777776yeJugem T0.027777777777777776ybより T0.027777777777777776yb移植 T0.027777777777777776ya) T0.027777777777777776>vc281<ygポモドーロ回し S0.08333333333333333yaて S0.08333333333333333ybます S0.08333333333333333ya。 S0.08333333333333333ya（ S0.08333333333333333y Qポモドーロテクニック入門読みました S0.08333333333333333ya） S0.08333333333333333ya( S0.08333333333333333yeJugem S0.08333333333333333ybより S0.08333333333333333yb移植 S0.08333333333333333ya) S0.08333333333333333>vc282<ya0 S0.05263157894736842ya3 S0.05263157894736842ya4 S0.05263157894736842ydSolr S0.05263157894736842ya. S0.10526315789473684yaの S0.05263157894736842ygChanges S0.05263157894736842yaを S0.05263157894736842yb訳し S0.05263157894736842yaて S0.05263157894736842yaみ S0.05263157894736842yaた S0.05263157894736842ya。 S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc283<ya0 S0.02702702702702703ya3 S0.02702702702702703ya4 S0.02702702702702703yfLucene S0.02702702702702703ya  S0.13513513513513514ya. S0.05405405405405406yaの S0.05405405405405406ygChanges S0.05405405405405406yaに S0.05405405405405406ybある S0.02702702702702703ybin S0.02702702702702703yibackwards S0.02702702702702703ymcompatibility S0.02702702702702703yfpolicy S0.02702702702702703yaが S0.02702702702702703ya気 S0.02702702702702703ybなっ S0.02702702702702703yaた S0.05405405405405406yaで S0.02702702702702703yb訳し S0.02702702702702703yaて S0.02702702702702703yaみ S0.02702702702702703ya。 S0.02702702702702703ya( S0.02702702702702703yeJugem S0.02702702702702703ybより S0.02702702702702703yb移植 S0.02702702702702703ya) S0.02702702702702703>vc284<ya2 T0.023255813953488372yeエンジニア T0.023255813953488372yaの S0.06976744186046512ybため T0.023255813953488372yfスキルアップ T0.023255813953488372yc勉強会 T0.023255813953488372ya『 T0.023255813953488372ydTech T0.023255813953488372ya  S0.11627906976744186ygCompass T0.023255813953488372ya』 T0.023255813953488372ya# T0.023255813953488372yftecomp T0.023255813953488372ya― T0.023255813953488372ycVol T0.023255813953488372ya. T0.023255813953488372ya「 T0.023255813953488372yb人気 T0.023255813953488372ycWeb T0.023255813953488372ydサービス T0.023255813953488372yb作り T0.023255813953488372yb方教 T0.023255813953488372yaえ T0.023255813953488372ybます T0.023255813953488372ya！ T0.023255813953488372ya」 T0.023255813953488372yaに T0.023255813953488372yb参加 T0.023255813953488372yaし T0.023255813953488372ybまし T0.023255813953488372yaた T0.023255813953488372ya。 T0.023255813953488372ya( T0.023255813953488372yeJugem T0.023255813953488372ybより T0.023255813953488372yb移植 T0.023255813953488372ya) T0.023255813953488372>vc285<ydJIRA S0.08333333333333333yaの S0.08333333333333333ycデータ S0.08333333333333333yaを S0.08333333333333333ybS3 S0.08333333333333333yaへ S0.08333333333333333yfバックアップ S0.08333333333333333ya( S0.08333333333333333yeJugem S0.08333333333333333ybより S0.08333333333333333yb移植 S0.08333333333333333ya) S0.08333333333333333>vc286<ya8 T0.034482758620689655yfHeroku T0.034482758620689655ya  R0.2413793103448276yfMeetup T0.034482758620689655ya# S0.06896551724137931ylTreasureData T0.034482758620689655ya+ T0.034482758620689655ydWaza T0.034482758620689655yfReport T0.034482758620689655yb!! T0.034482758620689655yaに T0.034482758620689655yb参加 T0.034482758620689655yaし T0.034482758620689655ybまし T0.034482758620689655yaた T0.034482758620689655ya。 T0.034482758620689655yhherokujp T0.034482758620689655ya( T0.034482758620689655yeJugem T0.034482758620689655ybより T0.034482758620689655yb移植 T0.034482758620689655ya) T0.034482758620689655>vc287<yd第10回f0.0625ydSolrf0.0625yc勉強会f0.0625yaをf0.0625yb主催f0.0625yaしf0.0625ybましf0.0625yaたf0.0625ya。f0.0625ya#f0.0625yfSolrJPf0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc288<ymelasticsearchf0.0625ya-e0.125yhanalysisf0.0625yhkuromojif0.0625yaでf0.0625ycユーザf0.0625yb辞書f0.0625yaのf0.0625yb利用f0.0625yb方法f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc289<ya1 T0.021739130434782608yeエンジニア T0.043478260869565216yaの S0.06521739130434782ybため T0.021739130434782608yfスキルアップ T0.021739130434782608yc勉強会 T0.021739130434782608ya『 T0.021739130434782608ydTech T0.021739130434782608ya  S0.08695652173913043ygCompass T0.021739130434782608ya』 T0.021739130434782608ya＠ T0.021739130434782608yb竹橋 T0.021739130434782608ya― T0.021739130434782608ycVol T0.021739130434782608ya「 T0.021739130434782608ycスマホ T0.021739130434782608yd時代到来 T0.021739130434782608ya、 T0.021739130434782608ybこの T0.021739130434782608yb先生 T0.021739130434782608yaき T0.021739130434782608ybこる T0.021739130434782608yaと T0.021739130434782608yaは T0.021739130434782608ya！ T0.021739130434782608yb？」 T0.021739130434782608yaに T0.021739130434782608yb参加 T0.021739130434782608yaし T0.021739130434782608ybまし T0.021739130434782608yaた T0.021739130434782608ya。 T0.021739130434782608ya# T0.021739130434782608yftecomp T0.021739130434782608ya( T0.021739130434782608yeJugem T0.021739130434782608ybより T0.021739130434782608yb移植 T0.021739130434782608ya) T0.021739130434782608>vc290:yfXperiac0.1ya c0.1yaZc0.1yd買いましc0.1yaたc0.1ya(c0.1yeJugemc0.1ybよりc0.1yb移植c0.1ya)c0.1vc291<yd2013 T0.043478260869565216yfHadoop T0.043478260869565216ya  S0.17391304347826086yjConference T0.043478260869565216yeJapan T0.043478260869565216yfWinter T0.043478260869565216yaに T0.043478260869565216yb参加 T0.043478260869565216yaし T0.043478260869565216ybまし T0.043478260869565216yaた T0.043478260869565216ya。 T0.043478260869565216ya# T0.043478260869565216ychcj T0.043478260869565216yc13w T0.043478260869565216ya( T0.043478260869565216yeJugem T0.043478260869565216ybより T0.043478260869565216yb移植 T0.043478260869565216ya) T0.043478260869565216>vc292<yd2013d0.08yiエンジニアサポートd0.04yeCROSSd0.04ya d0.08yaにd0.04yb参加d0.04ya（d0.04ya＋d0.08yaおd0.04yb手伝d0.04yaいd0.04yeモデレータd0.04ya）d0.04ycしましd0.04yaたd0.04ya#d0.04yecrossd0.04ya(d0.04yeJugemd0.04ybよりd0.04yb移植d0.04ya)d0.04>vc293<yd2013 T0.045454545454545456ydいまさら T0.045454545454545456yaで S0.09090909090909091yaす T0.045454545454545456yaが T0.045454545454545456ya、 T0.045454545454545456yeCROSS S0.09090909090909091ya  T0.045454545454545456yb検索 T0.045454545454545456ycという T0.045454545454545456yeセッション T0.045454545454545456yaを T0.045454545454545456yb担当 T0.045454545454545456yaし T0.045454545454545456ybます T0.045454545454545456ya( T0.045454545454545456yeJugem T0.045454545454545456ybより T0.045454545454545456yb移植 T0.045454545454545456ya) T0.045454545454545456>vc294<ya「d0.04ykコード・シンプリシティd0.04ya」d0.04yaをd0.04yd読みましd0.04yaたd0.04ya。d0.04ya（d0.04yfKindled0.04ya d0.04yjpaperwhited0.04yaのd0.08yb使いd0.04yb勝手d0.04yb確認d0.04yaもd0.04yb兼ねd0.04yaてd0.04ya）d0.04ya(d0.04yeJugemd0.04ybよりd0.04yb移植d0.04ya)d0.04>vc295<yd2012f0.0625yb今年f0.0625yaのe0.125yb振りf0.0625yb返りf0.0625yaとf0.0625yb来年f0.0625yb抱負f0.0625ya（f0.0625ya）f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc296<ydJIRA T0.058823529411764705yaの T0.058823529411764705ybDB T0.058823529411764705yb移行 T0.058823529411764705ya（ T0.058823529411764705yfHSQLDB T0.058823529411764705ybから T0.058823529411764705yjPostgreSQL T0.058823529411764705yaへ T0.058823529411764705ya） T0.058823529411764705ya# T0.058823529411764705ydaugj T0.058823529411764705ya( T0.058823529411764705yeJugem T0.058823529411764705ybより T0.058823529411764705yb移植 T0.058823529411764705ya) T0.058823529411764705>vc297<yc第一回 S0.05263157894736842ya  S0.15789473684210525yiJetBrains S0.05263157894736842yhユーザーグループ S0.05263157894736842ya# S0.05263157894736842yejbugj S0.05263157894736842yaに S0.05263157894736842yb参加 S0.05263157894736842yaし S0.05263157894736842yaて S0.05263157894736842ycきまし S0.05263157894736842yaた S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc298<ya3d0.04ya5d0.04ya#d0.04ygDSIRNLPd0.04ya d0.04ya.d0.04yaにd0.04yb参加d0.04yaしd0.04ybましd0.04yaたd0.08ya。d0.04yb＆「d0.04yeEmacsd0.04yd実践入門d0.04ya」d0.04yaをd0.04yg頂いちゃいましd0.04ya！d0.04ya(d0.04yeJugemd0.04ybよりd0.04yb移植d0.04ya)d0.04>vc299<yc第9回f0.0625ydSolrf0.0625yc勉強会f0.0625yaをf0.0625yb主催f0.0625yaしf0.0625ybましf0.0625yaたf0.0625ya。f0.0625ya#f0.0625yfSolrJPf0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc300<ycAWS S0.05555555555555555ya  S0.05555555555555555yfビッグデータ S0.05555555555555555yd活用事例 S0.05555555555555555ydセミナー S0.05555555555555555yaに S0.05555555555555555yb参加 S0.05555555555555555yaし S0.05555555555555555ybまし S0.05555555555555555yaた S0.05555555555555555ya。 S0.05555555555555555ya# S0.05555555555555555yfjawsug S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc301<ya0 S0.08695652173913043ya4 S0.08695652173913043yfLucene T0.043478260869565216ya/ T0.043478260869565216ydSolr T0.043478260869565216ya  T0.043478260869565216ya. S0.13043478260869565ydリリース T0.043478260869565216ya＆ T0.043478260869565216yflucene T0.043478260869565216ya- T0.043478260869565216yegosen T0.043478260869565216yaの T0.043478260869565216yc0対応 T0.043478260869565216ya( T0.043478260869565216yeJugem T0.043478260869565216ybより T0.043478260869565216yb移植 T0.043478260869565216ya) T0.043478260869565216>vc302<yeLucid S0.05555555555555555yaの R0.1111111111111111yeGrant S0.05555555555555555ya  S0.05555555555555555yiIngersoll S0.05555555555555555ybさん S0.05555555555555555yb講演 S0.05555555555555555yaを S0.05555555555555555yb聞い S0.05555555555555555yaて S0.05555555555555555ycきまし S0.05555555555555555yaた S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc303<yd2012 S0.10526315789473684ycPFI S0.05263157894736842yhオープンセミナー S0.05263157894736842yaに S0.05263157894736842yb参加 S0.05263157894736842yaし S0.05263157894736842yaて S0.05263157894736842ycきまし S0.05263157894736842yaた S0.05263157894736842ya。 S0.05263157894736842ya  S0.05263157894736842ya# S0.05263157894736842ygpfiopen S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc304<ycメイン T0.058823529411764705ycMBA T0.058823529411764705yaを T0.058823529411764705yhMountain T0.058823529411764705ya  T0.058823529411764705ydLion T0.058823529411764705yaに T0.058823529411764705yfアップデート T0.058823529411764705ya（ T0.058823529411764705ydいろいろ T0.058823529411764705yc確認中 T0.058823529411764705ya） T0.058823529411764705ya( T0.058823529411764705yeJugem T0.058823529411764705ybより T0.058823529411764705yb移植 T0.058823529411764705ya) T0.058823529411764705>vc305<ya2d0.04ygFluentdd0.04ya d0.24yfmeetupd0.04ybind0.04yeJapand0.04ya#d0.08ygfluentdd0.04yaにd0.04yb参加d0.04yaしd0.04ybましd0.04yaたd0.04ya。d0.04ya(d0.04yeJugemd0.04ybよりd0.04yb移植d0.04ya)d0.04>vc306<ygTwitterd0.05ya d0.15yc勉強会d0.05ya#d0.05ydtwtrd0.05ya_d0.05ydhackd0.05yaにd0.05yb参加d0.05yaしd0.05ybましd0.05yaたd0.05ya。d0.05ya(d0.05yeJugemd0.05ybよりd0.05yb移植d0.05ya)d0.05>vc307<yd2012d0.04yfPythond0.04ya d0.16yjDevelopersd0.04yeFestad0.04ya.d0.04yb07d0.04yaにd0.04yb参加d0.04yaしd0.04yaてd0.08ydしゃべっd0.04ycきましd0.04yaたd0.04ya#d0.04yepyfesd0.04ya(d0.04yeJugemd0.04ybよりd0.04yb移植d0.04ya)d0.04>vc308<ya0d0.05ya4d0.05ygPartiald0.05ya d0.15yfUpdated0.05yaとd0.05yicopyFieldd0.05yaのd0.05ybバグd0.05ya【d0.05ydSolrd0.05ya.d0.05yeALPHAd0.05yb】(d0.05yeJugemd0.05ybよりd0.05yb移植d0.05ya)d0.05>vc3099ycMIR R0.1111111111111111ye輪読会始め R0.1111111111111111ybまし R0.1111111111111111yaた R0.1111111111111111ya( R0.1111111111111111yeJugem R0.1111111111111111ybより R0.1111111111111111yb移植 R0.1111111111111111ya) R0.1111111111111111vc310<ya0 S0.05555555555555555ya4 S0.05555555555555555yflucene S0.05555555555555555ya- R0.1111111111111111yegosen S0.05555555555555555yaの S0.05555555555555555yfLucene S0.05555555555555555ya/ S0.05555555555555555ydSolr S0.05555555555555555ya. S0.05555555555555555yeALPHA S0.05555555555555555yb対応 S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc311<ydSolr T0.058823529411764705yd勉強会第 T0.058823529411764705yb8回 T0.058823529411764705yaに T0.058823529411764705yb参加 T0.058823529411764705yaし T0.058823529411764705ybまし T0.058823529411764705yaた T0.058823529411764705ya。 T0.058823529411764705ya  T0.058823529411764705ya# T0.058823529411764705yfSolrJP T0.058823529411764705ya( T0.058823529411764705yeJugem T0.058823529411764705ybより T0.058823529411764705yb移植 T0.058823529411764705ya) T0.058823529411764705>vc312<yfHadoop T0.058823529411764705ylソースコードリーディング T0.058823529411764705ya第 T0.058823529411764705yc10回 T0.058823529411764705yaに T0.058823529411764705yb参加 T0.058823529411764705yaし T0.058823529411764705ybまし T0.058823529411764705yaた T0.058823529411764705ya。 T0.058823529411764705ya# T0.058823529411764705ymhadoopreading T0.058823529411764705ya( T0.058823529411764705yeJugem T0.058823529411764705ybより T0.058823529411764705yb移植 T0.058823529411764705ya) T0.058823529411764705>vc313;yflucene S0.09090909090909091ya- S0.09090909090909091yegosen S0.09090909090909091yaの S0.09090909090909091yfUniDic S0.09090909090909091yb対応 S0.09090909090909091ya( S0.09090909090909091yeJugem S0.09090909090909091ybより S0.09090909090909091yb移植 S0.09090909090909091ya) S0.09090909090909091vc314<yfZipkinf0.0625yaのf0.0625yfReadmef0.0625yb読んf0.0625ybでるf0.0625ya（f0.0625ybそのf0.0625ya２f0.0625ya、f0.0625yb残りf0.0625ya）f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc315<yfZipkinf0.0625yaのf0.0625yfReadmef0.0625yaをf0.0625yb読んf0.0625ybでるf0.0625ya（f0.0625yfクライアントf0.0625yb周りf0.0625ydについてf0.0625ya）f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc316:y YautoGeneratePhraseQueriesc0.1yaのc0.1yeデフォルトc0.1ya値c0.1ydについてc0.1ya(c0.1yeJugemc0.1ybよりc0.1yb移植c0.1ya)c0.1vc317<ygTwitter S0.05263157894736842yaが S0.05263157894736842yb公開 S0.05263157894736842yaし S0.05263157894736842yaた S0.05263157894736842yb分散 S0.05263157894736842yfトレーシング S0.05263157894736842ya（ S0.05263157894736842yb追跡 S0.05263157894736842ya？ S0.05263157894736842ya） S0.05263157894736842ydシステム S0.05263157894736842ya、 S0.05263157894736842yfZipkin S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc318<ya0 T0.045454545454545456ya2 S0.09090909090909091yflucene T0.045454545454545456ya- T0.045454545454545456yegosen T0.045454545454545456ya  T0.045454545454545456ya. S0.09090909090909091ydリリース T0.045454545454545456ya（ T0.045454545454545456ydリソース T0.045454545454545456yb周り T0.045454545454545456yaの T0.045454545454545456yb改善 T0.045454545454545456ybなど T0.045454545454545456ya） T0.045454545454545456ya( T0.045454545454545456yeJugem T0.045454545454545456ybより T0.045454545454545456yb移植 T0.045454545454545456ya) T0.045454545454545456>vc319<yb32 S0.07692307692307693yd4096 S0.07692307692307693yeIssue S0.07692307692307693ydについて S0.07692307692307693ya（ S0.07692307692307693yaの S0.07692307692307693ya壁 S0.07692307692307693ya） S0.07692307692307693ya( S0.07692307692307693yeJugem S0.07692307692307693ybより S0.07692307692307693yb移植 S0.07692307692307693ya) S0.07692307692307693>vc320<ya0 T0.038461538461538464ya3 T0.038461538461538464ya6 T0.038461538461538464yetrunk T0.038461538461538464yaの S0.07692307692307693yeライブラリ T0.038461538461538464ya差 T0.038461538461538464yaし T0.038461538461538464yb替え T0.038461538461538464ya（ T0.038461538461538464yfLucene T0.038461538461538464ya/ T0.038461538461538464ydSolr T0.038461538461538464ya. S0.07692307692307693ya） T0.038461538461538464yaと T0.038461538461538464ygランダムテスト T0.038461538461538464yb失敗 T0.038461538461538464ydについて T0.038461538461538464ya( T0.038461538461538464yeJugem T0.038461538461538464ybより T0.038461538461538464yb移植 T0.038461538461538464ya) T0.038461538461538464>vc321:ygオープンソース S0.09090909090909091yaへ S0.09090909090909091yaの S0.18181818181818182yb貢献 S0.09090909090909091ycススメ S0.09090909090909091ya( S0.09090909090909091yeJugem S0.09090909090909091ybより S0.09090909090909091yb移植 S0.09090909090909091ya) S0.09090909090909091vc322<yd2012 S0.05263157894736842ydJJUG S0.05263157894736842ya  S0.15789473684210525ycCCC S0.05263157894736842yfSpring S0.05263157894736842yaに S0.05263157894736842yb参加 S0.05263157894736842yaし S0.05263157894736842yaて S0.05263157894736842ycきまし S0.05263157894736842yaた S0.05263157894736842ya。 S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc323<ya0d0.05ya2d0.05ymPlayFrameworkd0.05ya d0.05ya.d0.05ya(c0.1ydJavad0.05yaのd0.05ya方d0.05ya)c0.1yaをd0.05yb触っd0.05yaてd0.05yaみd0.05ybてるd0.05yeJugemd0.05ybよりd0.05yb移植d0.05>vc324<ya0 S0.05263157894736842ya1 S0.05263157894736842ya2 S0.05263157894736842yflucene S0.05263157894736842ya- S0.05263157894736842yegosen S0.05263157894736842ya  S0.05263157894736842ya. S0.10526315789473684ydリリース S0.05263157894736842ya（ S0.05263157894736842ydJava S0.05263157894736842yc7対応 S0.05263157894736842ya） S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc325<ya「 S0.07142857142857142ybID S0.07142857142857142yaの S0.07142857142857142yb秘密 S0.07142857142857142ya」 S0.07142857142857142yaを S0.07142857142857142yd読みまし S0.07142857142857142yaた S0.07142857142857142ya。 S0.07142857142857142ya( S0.07142857142857142yeJugem S0.07142857142857142ybより S0.07142857142857142yb移植 S0.07142857142857142ya) S0.07142857142857142>vc326<ya4 T0.047619047619047616yfHeroku T0.047619047619047616ya  S0.14285714285714285ybJP T0.047619047619047616yfMeetup T0.047619047619047616ya＃ T0.047619047619047616yaに T0.047619047619047616yb参加 T0.047619047619047616yaし T0.047619047619047616ybまし T0.047619047619047616yaた T0.047619047619047616ya。 T0.047619047619047616ya# T0.047619047619047616yhherokujp T0.047619047619047616ya( T0.047619047619047616yeJugem T0.047619047619047616ybより T0.047619047619047616yb移植 T0.047619047619047616ya) T0.047619047619047616>vc327<ya0 T0.043478260869565216ya3 T0.043478260869565216ya6 T0.043478260869565216ydSolr T0.043478260869565216ya  T0.043478260869565216ya. S0.08695652173913043yaの S0.13043478260869565ycCJK T0.043478260869565216yb設定 T0.043478260869565216yaと T0.043478260869565216y TSynonymFilterFactory T0.043478260869565216ya気 T0.043478260869565216yaに T0.043478260869565216ybなる T0.043478260869565216ya点 T0.043478260869565216ya( T0.043478260869565216yeJugem T0.043478260869565216ybより T0.043478260869565216yb移植 T0.043478260869565216ya) T0.043478260869565216>vc328<ya「d0.04yfApached0.04ya d0.04ydSolrd0.04yb入門d0.04ya」d0.04yaのd0.08ydサンプルd0.04yhKuromojid0.04yaとd0.04yflucened0.04ya-d0.04yegosend0.04yb対応d0.04ya（d0.04yb2章d0.04ya～d0.04yb4章d0.04ya）d0.04ya(d0.04yeJugemd0.04ybよりd0.04yb移植d0.04ya)d0.04>vc329<ya0 T0.027777777777777776ya3 T0.027777777777777776ya6 T0.027777777777777776yfLucene T0.027777777777777776ya/ S0.05555555555555555ydSolr S0.05555555555555555ya  R0.1111111111111111ya. S0.05555555555555555ydリリース T0.027777777777777776ya「 T0.027777777777777776yfApache T0.027777777777777776yb入門 T0.027777777777777776ya」 T0.027777777777777776yaの S0.05555555555555555ydサンプル T0.027777777777777776yhKuromoji T0.027777777777777776yaと T0.027777777777777776yflucene T0.027777777777777776ya- T0.027777777777777776yegosen T0.027777777777777776yb対応 T0.027777777777777776ya（ T0.027777777777777776yb1章 T0.027777777777777776ya） T0.027777777777777776ya( T0.027777777777777776yeJugem T0.027777777777777776ybより T0.027777777777777776yb移植 T0.027777777777777776ya) T0.027777777777777776>vc330<ya【 S0.06666666666666667ybメモ S0.06666666666666667ya】 S0.06666666666666667yfAmazon S0.06666666666666667ya  S0.06666666666666667ykCloudSearch S0.06666666666666667yaが S0.06666666666666667yb出て S0.06666666666666667ycきまし S0.06666666666666667ybたよ S0.06666666666666667ya( S0.06666666666666667yeJugem S0.06666666666666667ybより S0.06666666666666667yb移植 S0.06666666666666667ya) S0.06666666666666667>vc331<yd2012 T0.047619047619047616ydJava T0.047619047619047616ya  S0.19047619047619047ycOne T0.047619047619047616yeTokyo T0.047619047619047616yaに T0.047619047619047616yb参加 T0.047619047619047616yaし T0.047619047619047616ybまし T0.047619047619047616yaた T0.047619047619047616ya。 T0.047619047619047616ya# T0.047619047619047616yiJavaOneJp T0.047619047619047616ya( T0.047619047619047616yeJugem T0.047619047619047616ybより T0.047619047619047616yb移植 T0.047619047619047616ya) T0.047619047619047616>vc332<ya7 S0.05555555555555555yflucene S0.05555555555555555ya- S0.05555555555555555yegosen S0.05555555555555555yaの S0.16666666666666666ydJava S0.05555555555555555yaで S0.05555555555555555ycテスト S0.05555555555555555yb失敗 S0.05555555555555555yb問題 S0.05555555555555555yb対応 S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc333<ya0 R0.1111111111111111ya2 S0.05555555555555555ya【 S0.05555555555555555yb重要 S0.05555555555555555ya】 S0.05555555555555555yflucene S0.05555555555555555ya- S0.05555555555555555yegosen S0.05555555555555555ya  S0.05555555555555555ya. R0.1111111111111111ydリリース S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc334<ya【 S0.06666666666666667yb重要 S0.06666666666666667ya】 S0.06666666666666667yflucene S0.06666666666666667ya- S0.06666666666666667yegosen S0.06666666666666667yaの S0.06666666666666667yb次期 S0.06666666666666667ydリリース S0.06666666666666667ydについて S0.06666666666666667ya( S0.06666666666666667yeJugem S0.06666666666666667ybより S0.06666666666666667yb移植 S0.06666666666666667ya) S0.06666666666666667>vc335<yb久々 S0.07142857142857142yaに S0.07142857142857142ycMac S0.07142857142857142ya  S0.07142857142857142ydMini S0.07142857142857142yaの S0.07142857142857142ybこと S0.07142857142857142yaで S0.07142857142857142yaも S0.07142857142857142ya( S0.07142857142857142yeJugem S0.07142857142857142ybより S0.07142857142857142yb移植 S0.07142857142857142ya) S0.07142857142857142>vc336<yc第5回 S0.05263157894736842ya  S0.21052631578947367ygTwitter S0.05263157894736842ycAPI S0.05263157894736842yc勉強会 S0.05263157894736842ya@ S0.05263157894736842yb渋谷 S0.05263157894736842ya# S0.05263157894736842ydtwtr S0.05263157894736842ya_ S0.05263157894736842ydhack S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc337<ya「 S0.09090909090909091yb自分 T0.045454545454545456yaの T0.045454545454545456yb小さ T0.045454545454545456yaな T0.045454545454545456ya箱 T0.045454545454545456ya」 S0.09090909090909091ybから T0.045454545454545456yb脱出 T0.045454545454545456ybする T0.045454545454545456yb方法 T0.045454545454545456yaを T0.045454545454545456yd読みまし T0.045454545454545456yaた T0.045454545454545456ya。 T0.045454545454545456ya( T0.045454545454545456yeJugem T0.045454545454545456ybより T0.045454545454545456yb移植 T0.045454545454545456ya) T0.045454545454545456>vc3388yeScalae0.125yd始めましe0.125yaたe0.125ya(e0.125yeJugeme0.125ybよりe0.125yb移植e0.125ya)e0.125vc339<yc第0回 T0.045454545454545456ya  S0.18181818181818182ygTwitter T0.045454545454545456ydHack T0.045454545454545456ya# T0.045454545454545456ydtwtr T0.045454545454545456ya_ T0.045454545454545456ydhack T0.045454545454545456yaに S0.09090909090909091yb遊び T0.045454545454545456yd行きまし T0.045454545454545456yaた T0.045454545454545456ya。 T0.045454545454545456ya( T0.045454545454545456yeJugem T0.045454545454545456ybより T0.045454545454545456yb移植 T0.045454545454545456ya) T0.045454545454545456>vc340;yeClean S0.09090909090909091ya  S0.09090909090909091yeCoder S0.09090909090909091yaを S0.09090909090909091yb読ん S0.09090909090909091yaだ S0.09090909090909091ya( S0.09090909090909091yeJugem S0.09090909090909091ybより S0.09090909090909091yb移植 S0.09090909090909091ya) S0.09090909090909091vc341<yb親子f0.0625yaでe0.125yd楽しめるf0.0625ya f0.0625yb絵本f0.0625yb英語f0.0625yaをf0.0625yaはf0.0625ycじめるf0.0625ya本f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc342<yc第4回 T0.038461538461538464ya  S0.19230769230769232ygTwitter T0.038461538461538464ycAPI T0.038461538461538464yc勉強会 T0.038461538461538464ya@ T0.038461538461538464yiデジタルハリウッド T0.038461538461538464ya# T0.038461538461538464ydtwtr T0.038461538461538464ya_ T0.038461538461538464ydhack T0.038461538461538464yaに T0.038461538461538464yb参加 T0.038461538461538464yaし T0.038461538461538464ybまし T0.038461538461538464yaた T0.038461538461538464ya。 T0.038461538461538464ya( T0.038461538461538464yeJugem T0.038461538461538464ybより T0.038461538461538464yb移植 T0.038461538461538464ya) T0.038461538461538464>vc343<yflucene S0.05263157894736842ya- S0.05263157894736842yegosen S0.05263157894736842yaと S0.05263157894736842ymSynonymFilter S0.05263157894736842yaを S0.05263157894736842yb利用 S0.05263157894736842ybする S0.05263157894736842ybとき S0.05263157894736842yaの S0.05263157894736842yc注意点 S0.05263157894736842ya（ S0.05263157894736842yd問題点編 S0.05263157894736842ya） S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc344<yfHadoop T0.058823529411764705ylソースコードリーディング T0.058823529411764705ya第 T0.058823529411764705yb8回 T0.058823529411764705yaに T0.058823529411764705yb参加 T0.058823529411764705yaし T0.058823529411764705ybまし T0.058823529411764705yaた T0.058823529411764705ya。 T0.058823529411764705ya# T0.058823529411764705ymhadoopreading T0.058823529411764705ya( T0.058823529411764705yeJugem T0.058823529411764705ybより T0.058823529411764705yb移植 T0.058823529411764705ya) T0.058823529411764705>vc345<ygFluentdf0.0625ya e0.125yfMeetupf0.0625yeJapanf0.0625yaにf0.0625yb参加f0.0625yaしf0.0625ybましf0.0625yaたf0.0625ya。f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc3469yc今興味 R0.1111111111111111yaが R0.1111111111111111ybある R0.1111111111111111ybこと R0.1111111111111111ya( R0.1111111111111111yeJugem R0.1111111111111111ybより R0.1111111111111111yb移植 R0.1111111111111111ya) R0.1111111111111111vc347<ya1 S0.06666666666666667yd2012 S0.06666666666666667yhモーショノロジー S0.06666666666666667ya# S0.06666666666666667yaに S0.06666666666666667yb参加 S0.06666666666666667yaし S0.06666666666666667ybまし S0.06666666666666667yaた S0.06666666666666667ya。 S0.06666666666666667ya( S0.06666666666666667yeJugem S0.06666666666666667ybより S0.06666666666666667yb移植 S0.06666666666666667ya) S0.06666666666666667>vc348<ydMapR S0.07692307692307693ye中身説明会 S0.07692307692307693yaに S0.07692307692307693yb参加 S0.07692307692307693yaし S0.07692307692307693ybまし S0.07692307692307693yaた S0.07692307692307693ya。 S0.07692307692307693ya( S0.07692307692307693yeJugem S0.07692307692307693ybより S0.07692307692307693yb移植 S0.07692307692307693ya) S0.07692307692307693>vc349<yeOSSAJ S0.07142857142857142yaの S0.07142857142857142yfミニセミナー S0.07142857142857142yaで S0.07142857142857142yb話し S0.07142857142857142yaを S0.07142857142857142ybして S0.07142857142857142ycきまし S0.07142857142857142yaた S0.07142857142857142ya( S0.07142857142857142yeJugem S0.07142857142857142ybより S0.07142857142857142yb移植 S0.07142857142857142ya) S0.07142857142857142>vc350<ya4 T0.058823529411764705yflucene T0.058823529411764705ya- T0.058823529411764705yegosen T0.058823529411764705yaの T0.058823529411764705yfLucene T0.058823529411764705ya/ T0.058823529411764705ydSolr T0.058823529411764705ya. T0.058823529411764705yc0対応 T0.058823529411764705ydブランチ T0.058823529411764705yb更新 T0.058823529411764705ya( T0.058823529411764705yeJugem T0.058823529411764705ybより T0.058823529411764705yb移植 T0.058823529411764705ya) T0.058823529411764705>vc351<ydあけまし S0.06666666666666667yaて S0.06666666666666667ybおめ S0.06666666666666667yaで S0.06666666666666667ygとうございます S0.06666666666666667ya＋ S0.06666666666666667yb会社 S0.06666666666666667yaの S0.06666666666666667ycブログ S0.06666666666666667yb更新 S0.06666666666666667ya( S0.06666666666666667yeJugem S0.06666666666666667ybより S0.06666666666666667yb移植 S0.06666666666666667ya) S0.06666666666666667>vc352<yb今年 S0.07142857142857142yaの S0.14285714285714285yb振り S0.07142857142857142yb返り S0.07142857142857142yaと S0.07142857142857142yb来年 S0.07142857142857142yb抱負 S0.07142857142857142ya？ S0.07142857142857142ya( S0.07142857142857142yeJugem S0.07142857142857142ybより S0.07142857142857142yb移植 S0.07142857142857142ya) S0.07142857142857142>vc353<yb第2 T0.043478260869565216ya. T0.043478260869565216yb1回 T0.043478260869565216ya  S0.17391304347826086ygTwitter T0.043478260869565216ycAPI T0.043478260869565216yc勉強会 T0.043478260869565216ya@ T0.043478260869565216yb東京 T0.043478260869565216yaに T0.043478260869565216yb参加 T0.043478260869565216yaし T0.043478260869565216ybまし T0.043478260869565216yaた T0.043478260869565216ya。 T0.043478260869565216ya( T0.043478260869565216yeJugem T0.043478260869565216ybより T0.043478260869565216yb移植 T0.043478260869565216ya) T0.043478260869565216>vc354;ya1 S0.15384615384615385ya2 S0.07692307692307693ya. S0.15384615384615385ydリリース S0.07692307692307693ycしまし S0.07692307692307693yaた S0.07692307692307693ya( S0.07692307692307693yeJugem S0.07692307692307693ybより S0.07692307692307693yb移植 S0.07692307692307693ya) S0.07692307692307693vc355<ydSolrd0.05yd勉強会第d0.05yb７回d0.05yaにd0.05yb参加d0.05yaしd0.05ybましd0.05yaたc0.1ya。d0.05ya（d0.05yb発表d0.05yaもd0.05ycしましd0.05ya）d0.05ya(d0.05yeJugemd0.05ybよりd0.05yb移植d0.05ya)d0.05>vc356<yc第2回 S0.05263157894736842ya  S0.05263157894736842ycデータ S0.05263157894736842yb構造 S0.05263157894736842yaと S0.10526315789473684yb情報 S0.05263157894736842yb検索 S0.05263157894736842yg言語処理勉強会 S0.05263157894736842yaに S0.05263157894736842yb参加 S0.05263157894736842yaし S0.05263157894736842ybまし S0.05263157894736842yaた S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc357<ycMBA T0.041666666666666664yfセットアップ S0.08333333333333333yc備忘録 T0.041666666666666664ybその S0.08333333333333333ya５ T0.041666666666666664yaと S0.08333333333333333ycMac T0.041666666666666664ya  T0.041666666666666664ydMini T0.041666666666666664ya（ T0.041666666666666664yh2009late T0.041666666666666664ya） T0.041666666666666664yb他く T0.041666666666666664ybだら T0.041666666666666664ybない T0.041666666666666664ya話 T0.041666666666666664ya( T0.041666666666666664yeJugem T0.041666666666666664ybより T0.041666666666666664yb移植 T0.041666666666666664ya) T0.041666666666666664>vc358<ya「 S0.08695652173913043ybどん T0.043478260869565216yaな T0.043478260869565216ya本 S0.08695652173913043yaで T0.043478260869565216yaも T0.043478260869565216yb大量 T0.043478260869565216yaに T0.043478260869565216yc読める T0.043478260869565216yb速読 T0.043478260869565216ya」 S0.08695652173913043yaの T0.043478260869565216yaを T0.043478260869565216yd読みまし T0.043478260869565216yaた T0.043478260869565216ya( T0.043478260869565216yeJugem T0.043478260869565216ybより T0.043478260869565216yb移植 T0.043478260869565216ya) T0.043478260869565216>vc359<yfHadoop S0.06666666666666667ylソースコードリーディング S0.06666666666666667ya第 S0.06666666666666667yb7回 S0.06666666666666667yaに S0.06666666666666667yb参加 S0.06666666666666667yaし S0.06666666666666667ybまし S0.06666666666666667yaた S0.06666666666666667ya。 S0.06666666666666667ya( S0.06666666666666667yeJugem S0.06666666666666667ybより S0.06666666666666667yb移植 S0.06666666666666667ya) S0.06666666666666667>vc360<ya「 T0.043478260869565216yfApache T0.043478260869565216ya  T0.043478260869565216ydSolr T0.043478260869565216yb入門 T0.043478260869565216ya」 T0.043478260869565216yaの S0.08695652173913043ydサンプル T0.043478260869565216yflucene T0.043478260869565216ya- T0.043478260869565216yegosen T0.043478260869565216yb対応 T0.043478260869565216ya（ T0.043478260869565216yb1章 T0.043478260869565216ybから T0.043478260869565216yb4章 T0.043478260869565216ya） T0.043478260869565216ya( T0.043478260869565216yeJugem T0.043478260869565216ybより T0.043478260869565216yb移植 T0.043478260869565216ya) T0.043478260869565216>vc361<ygMongoDB T0.058823529411764705yc勉強会 T0.058823529411764705ya（ T0.058823529411764705ya第 T0.058823529411764705yb7回 T0.058823529411764705ya） T0.058823529411764705yaに T0.058823529411764705yb行っ T0.058823529411764705yaて T0.058823529411764705yc来まし T0.058823529411764705yaた T0.058823529411764705ya。 T0.058823529411764705ya( T0.058823529411764705yeJugem T0.058823529411764705ybより T0.058823529411764705yb移植 T0.058823529411764705ya) T0.058823529411764705>vc362<yfSplunk T0.058823529411764705ya  T0.058823529411764705ydLive T0.058823529411764705ya! T0.058823529411764705yaの T0.058823529411764705ydイベント T0.058823529411764705yaに T0.058823529411764705yb行っ T0.058823529411764705yaて T0.058823529411764705yc来まし T0.058823529411764705yaた T0.058823529411764705ya。 T0.058823529411764705ya( T0.058823529411764705yeJugem T0.058823529411764705ybより T0.058823529411764705yb移植 T0.058823529411764705ya) T0.058823529411764705>vc363<yd2011 S0.05555555555555555yfLucene S0.05555555555555555ya  R0.2222222222222222ygEurocon S0.05555555555555555yiBarcelona S0.05555555555555555yaの S0.05555555555555555ydスライド S0.05555555555555555yb読み S0.05555555555555555ybまし S0.05555555555555555yaた S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc364;yhBookscan S0.09090909090909091yaを S0.09090909090909091yb使っ S0.09090909090909091yaて S0.09090909090909091ycみまし S0.09090909090909091yaた S0.09090909090909091ya( S0.09090909090909091yeJugem S0.09090909090909091ybより S0.09090909090909091yb移植 S0.09090909090909091ya) S0.09090909090909091vc365:ya0 S0.09090909090909091ya1 S0.09090909090909091ya2 S0.09090909090909091ya. S0.18181818181818182ydリリース S0.09090909090909091ya( S0.09090909090909091yeJugem S0.09090909090909091ybより S0.09090909090909091yb移植 S0.09090909090909091ya) S0.09090909090909091vc366<ya3 S0.06666666666666667yb辞書 S0.06666666666666667yaの S0.06666666666666667yc外部化 S0.06666666666666667yaと S0.06666666666666667yfLucene S0.06666666666666667ya/ S0.06666666666666667ydSolr S0.06666666666666667ya. S0.06666666666666667yc4対応 S0.06666666666666667ya( S0.06666666666666667yeJugem S0.06666666666666667ybより S0.06666666666666667yb移植 S0.06666666666666667ya) S0.06666666666666667>vc367<yd2011 S0.05263157894736842ydJJUG S0.05263157894736842ya  S0.15789473684210525ycCCC S0.05263157894736842ydFall S0.05263157894736842yaに S0.05263157894736842yb参加 S0.05263157894736842yaし S0.05263157894736842yaて S0.05263157894736842ycきまし S0.05263157894736842yaた S0.05263157894736842ya。 S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc368<yflucene T0.058823529411764705ya- T0.058823529411764705yegosen T0.058823529411764705yaで T0.058823529411764705yb文章 T0.058823529411764705ybから T0.058823529411764705yeキーワード T0.058823529411764705yb抽出 T0.058823529411764705ya（ T0.058823529411764705yfイレギュラー T0.058823529411764705ya？ T0.058823529411764705ya） T0.058823529411764705ya( T0.058823529411764705yeJugem T0.058823529411764705ybより T0.058823529411764705yb移植 T0.058823529411764705ya) T0.058823529411764705>vc369<ya「 S0.05555555555555555yb7つ R0.1111111111111111yaの R0.1111111111111111yb言語 S0.05555555555555555ya　 S0.05555555555555555yb世界 S0.05555555555555555ya」 S0.05555555555555555ya  R0.1111111111111111ybIo S0.05555555555555555yc1日目 S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc370:ycMBAc0.1yfセットアップc0.1yc備忘録c0.1ybそのc0.1ya４c0.1ya(c0.1yeJugemc0.1ybよりc0.1yb移植c0.1ya)c0.1vc371<ya4 S0.05555555555555555ydSolr R0.1111111111111111yaの S0.05555555555555555yc新しい S0.05555555555555555yd管理画面 S0.05555555555555555ya（ S0.05555555555555555ya. S0.05555555555555555yax S0.05555555555555555ya  S0.05555555555555555yetrunk S0.05555555555555555ya系 S0.05555555555555555ya） S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc372<ya2f0.0625ycNewf0.0625ya e0.125yiSolrCloudf0.0625yfDesignf0.0625yaのf0.0625yb翻訳f0.0625ya（f0.0625ybそのf0.0625ya）f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc373<ycNewf0.0625ya e0.125yiSolrCloudf0.0625yfDesignf0.0625yaのf0.0625yb翻訳f0.0625ya（f0.0625ybそのf0.0625ya１f0.0625ya）f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc374<yd2011 T0.047619047619047616yfHadoop T0.047619047619047616ya  S0.19047619047619047yjConference T0.047619047619047616yeJapan T0.047619047619047616ydFall T0.047619047619047616yaに T0.047619047619047616yb参加 T0.047619047619047616yaし T0.047619047619047616yaて T0.047619047619047616ycきまし T0.047619047619047616yaた T0.047619047619047616ya。 T0.047619047619047616ya( T0.047619047619047616yeJugem T0.047619047619047616ybより T0.047619047619047616yb移植 T0.047619047619047616ya) T0.047619047619047616>vc375<ya「 S0.05555555555555555yb7つ R0.1111111111111111yaの R0.1111111111111111yb言語 S0.05555555555555555ya　 S0.05555555555555555yb世界 S0.05555555555555555ya」 S0.05555555555555555ya  R0.1111111111111111ybIo S0.05555555555555555yc0日目 S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc376<ya3f0.0625ya4f0.0625yfLucenef0.0625ya/f0.0625ydSolrf0.0625ya f0.0625ya.f0.0625ydリリースf0.0625ya（f0.0625yb速報f0.0625ya）f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc377<ya「 T0.047619047619047616yb7つ S0.09523809523809523yaの S0.09523809523809523yb言語 T0.047619047619047616ya　 T0.047619047619047616yb世界 T0.047619047619047616ya」 T0.047619047619047616ya  S0.09523809523809523ydRuby T0.047619047619047616yc3日目 T0.047619047619047616ya（ T0.047619047619047616yc最終日 T0.047619047619047616ya） T0.047619047619047616ya( T0.047619047619047616yeJugem T0.047619047619047616ybより T0.047619047619047616yb移植 T0.047619047619047616ya) T0.047619047619047616>vc378<yc第6回 S0.07142857142857142ydSolr S0.07142857142857142yc勉強会 S0.07142857142857142yaに S0.07142857142857142yb参加 S0.07142857142857142yaし S0.07142857142857142ybまし S0.07142857142857142yaた S0.07142857142857142ya。 S0.07142857142857142ya( S0.07142857142857142yeJugem S0.07142857142857142ybより S0.07142857142857142yb移植 S0.07142857142857142ya) S0.07142857142857142>vc379<ya「 S0.05555555555555555yb7つ R0.1111111111111111yaの R0.1111111111111111yb言語 S0.05555555555555555ya　 S0.05555555555555555yb世界 S0.05555555555555555ya」 S0.05555555555555555ya  R0.1111111111111111ydRuby S0.05555555555555555yc2日目 S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc380<ya「 S0.05555555555555555yb7つ R0.1111111111111111yaの R0.1111111111111111yb言語 S0.05555555555555555ya　 S0.05555555555555555yb世界 S0.05555555555555555ya」 S0.05555555555555555ya  R0.1111111111111111ydRuby S0.05555555555555555yc1日目 S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc381:ycMBAc0.1yfセットアップc0.1yc備忘録c0.1ybそのc0.1ya３c0.1ya(c0.1yeJugemc0.1ybよりc0.1yb移植c0.1ya)c0.1vc382;yd辞書分離 S0.09090909090909091yaの S0.09090909090909091yfテストケース S0.09090909090909091yb追加 S0.09090909090909091yaと S0.09090909090909091yd残タスク S0.09090909090909091ya( S0.09090909090909091yeJugem S0.09090909090909091ybより S0.09090909090909091yb移植 S0.09090909090909091ya) S0.09090909090909091vc383<yd複数辞書 S0.07142857142857142yaの S0.07142857142857142yb読み S0.07142857142857142yb込み S0.07142857142857142yb機能 S0.07142857142857142yb追加 S0.07142857142857142ya（ S0.07142857142857142ya仮 S0.07142857142857142ya） S0.07142857142857142ya( S0.07142857142857142yeJugem S0.07142857142857142ybより S0.07142857142857142yb移植 S0.07142857142857142ya) S0.07142857142857142>vc384;yb辞書 S0.08333333333333333yaの S0.16666666666666666ycjar S0.08333333333333333ydファイル S0.08333333333333333ybから S0.08333333333333333yb分離 S0.08333333333333333ya( S0.08333333333333333yeJugem S0.08333333333333333ybより S0.08333333333333333yb移植 S0.08333333333333333ya) S0.08333333333333333vc385:ycMBAc0.1yfセットアップc0.1yc備忘録c0.1ybそのc0.1ya２c0.1ya(c0.1yeJugemc0.1ybよりc0.1yb移植c0.1ya)c0.1vc3868ycMBAe0.125yfセットアップe0.125yc備忘録e0.125ya(e0.125yeJugeme0.125ybよりe0.125yb移植e0.125ya)e0.125vc387<yeApple S0.08333333333333333ya教 S0.08333333333333333yaに S0.08333333333333333yb入信 S0.08333333333333333yaし S0.08333333333333333ybまし S0.08333333333333333yaた S0.08333333333333333ya( S0.08333333333333333yeJugem S0.08333333333333333ybより S0.08333333333333333yb移植 S0.08333333333333333ya) S0.08333333333333333>vc388<yc第1回d0.05ya d0.05ycデータd0.05yb構造d0.05yaとc0.1yb情報d0.05yb検索d0.05yg言語処理勉強会d0.05yaにd0.05yb参加d0.05yaしd0.05ybましd0.05yaたd0.05ya。d0.05ya(d0.05yeJugemd0.05ybよりd0.05yb移植d0.05ya)d0.05>vc389;yhKuromoji S0.09090909090909091yaを S0.09090909090909091yb調べ S0.09090909090909091yaて S0.09090909090909091yaみ S0.09090909090909091yaた S0.09090909090909091ya( S0.09090909090909091yeJugem S0.09090909090909091ybより S0.09090909090909091yb移植 S0.09090909090909091ya) S0.09090909090909091vc390<yeNAIST S0.05263157894736842ya- S0.05263157894736842ydJDic S0.05263157894736842ya  S0.10526315789473684ycfor S0.05263157894736842yeMeCab S0.05263157894736842yaの S0.10526315789473684ylPreprocessor S0.05263157894736842yb実装 S0.05263157894736842yaに S0.05263157894736842yc関する S0.05263157894736842yc備忘録 S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc391<ya1c0.2yflucene S0.06666666666666667ya- S0.06666666666666667yegosen S0.06666666666666667ya  S0.06666666666666667ya. S0.13333333333333333ydリリース S0.06666666666666667ya( S0.06666666666666667yeJugem S0.06666666666666667ybより S0.06666666666666667yb移植 S0.06666666666666667ya) S0.06666666666666667>vc392<ya3e0.125yfLucenef0.0625ya/f0.0625ydSolrf0.0625ya f0.0625ya.f0.0625ydリリースf0.0625ya（f0.0625yb速報f0.0625ya）f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc393<yfHadoop T0.030303030303030304yaを T0.030303030303030304yb中心 T0.030303030303030304yaと T0.030303030303030304yaし S0.06060606060606061yaた S0.06060606060606061yb分散 T0.030303030303030304yb環境 T0.030303030303030304yaで T0.030303030303030304yaの S0.06060606060606061ye開発方法論 T0.030303030303030304ya・ S0.06060606060606061yeモデリング T0.030303030303030304ye設計手法等 T0.030303030303030304ydについて T0.030303030303030304yc座談会 T0.030303030303030304ya( S0.06060606060606061ya第 T0.030303030303030304yb5回 T0.030303030303030304ya） T0.030303030303030304yaに T0.030303030303030304yb参加 T0.030303030303030304ybまし T0.030303030303030304ya。 T0.030303030303030304yeJugem T0.030303030303030304ybより T0.030303030303030304yb移植 T0.030303030303030304ya) T0.030303030303030304>vc394<ylcompositePOS S0.08333333333333333ya（ S0.08333333333333333y TCompositeTokenFilter S0.08333333333333333ya） S0.08333333333333333yaの S0.08333333333333333ybバグ S0.08333333333333333yb修正 S0.08333333333333333ya( S0.08333333333333333yeJugem S0.08333333333333333ybより S0.08333333333333333yb移植 S0.08333333333333333ya) S0.08333333333333333>vc395<yeNAISTf0.0625ya-f0.0625ydJDicf0.0625ya e0.125ycforf0.0625yeMeCabf0.0625yc対応版f0.0625ya（f0.0625yc仮実装f0.0625ya）f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc396<ylcompositePOS S0.05555555555555555yaの S0.16666666666666666yc利用例 S0.05555555555555555ya（ S0.05555555555555555yenaist S0.05555555555555555ya- S0.05555555555555555yfchasen S0.05555555555555555yaで S0.05555555555555555yc英単語 S0.05555555555555555ye出力方法例 S0.05555555555555555ya） S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc397<ya0f0.0625ya1e0.125yflucenef0.0625ya-f0.0625yegosenf0.0625ya e0.125ya.e0.125ydリリースf0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc398;yflucene S0.09090909090909091ya- S0.09090909090909091yegosen S0.09090909090909091yaの S0.09090909090909091ykTokenFilter S0.09090909090909091ybたち S0.09090909090909091ya( S0.09090909090909091yeJugem S0.09090909090909091ybより S0.09090909090909091yb移植 S0.09090909090909091ya) S0.09090909090909091vc3999yb辞書c0.2yaとc0.1ydカスタムc0.1ydについてc0.1ya(c0.1yeJugemc0.1ybよりc0.1yb移植c0.1ya)c0.1vc400;ycソース S0.09090909090909091ybから S0.09090909090909091yaの S0.09090909090909091ycビルド S0.09090909090909091yaと S0.09090909090909091yb構成 S0.09090909090909091ya( S0.09090909090909091yeJugem S0.09090909090909091ybより S0.09090909090909091yb移植 S0.09090909090909091ya) S0.09090909090909091vc401:yflucenec0.1ya-c0.1yegosenc0.1yaとc0.1yaはc0.1ya(c0.1yeJugemc0.1ybよりc0.1yb移植c0.1ya)c0.1vc4028ycブログe0.125yaはe0.125ydじめますe0.125ya(e0.125yeJugeme0.125ybよりe0.125yb移植e0.125ya)e0.125>vgsummary<va1<yd2022 S0.02631578947368421yb今年 S0.02631578947368421yaも S0.02631578947368421yb振り S0.05263157894736842yb返り S0.05263157894736842ycブログ S0.02631578947368421yaを S0.02631578947368421ydリビング S0.02631578947368421yaで S0.07894736842105263yb書い S0.05263157894736842yaて S0.05263157894736842ycいます S0.02631578947368421ya（ S0.05263157894736842yeドミノ倒し S0.02631578947368421ycすごい S0.02631578947368421yaな S0.02631578947368421ya） S0.02631578947368421ya。 S0.10526315789473684ya  S0.05263157894736842ycFMV S0.02631578947368421yaの S0.05263157894736842yeキーボード S0.02631578947368421ybいる S0.02631578947368421ycタイポ S0.02631578947368421yaが S0.02631578947368421ycつらい S0.02631578947368421>va2<yd2023 T0.024390243902439025ybこの T0.024390243902439025yb記事 S0.04878048780487805yaは S0.04878048780487805ya、 S0.04878048780487805yd情報検索 T0.024390243902439025ya・ T0.024390243902439025yd検索技術 T0.024390243902439025ya  S0.14634146341463414yfAdvent S0.04878048780487805yhCalendar S0.04878048780487805yaの R0.0975609756097561yd15日目 T0.024390243902439025yaで S0.04878048780487805yaす S0.04878048780487805ya。 S0.04878048780487805yb昨年 T0.024390243902439025yaに T0.024390243902439025yb続き T0.024390243902439025yc2回目 T0.024390243902439025yb情報 T0.024390243902439025yb検索 T0.024390243902439025yb参戦 T0.024390243902439025yb今年 T0.024390243902439025ya夏 T0.024390243902439025>va3<yb12 T0.027777777777777776yePySpa T0.027777777777777776yjアドベントカレンダー T0.027777777777777776yaの R0.1111111111111111ya/ T0.027777777777777776yb08 T0.027777777777777776yeエントリー T0.027777777777777776yaで S0.08333333333333333yaす T0.027777777777777776ya。 S0.05555555555555555yb昨日 T0.027777777777777776yaは S0.08333333333333333yb渋川 T0.027777777777777776ybさん T0.027777777777777776ygアンラーニング T0.027777777777777776yb失敗 T0.027777777777777776yaし S0.05555555555555555yaた S0.05555555555555555ya話 S0.05555555555555555ya  T0.027777777777777776ya私 T0.027777777777777776ya、 T0.027777777777777776yb今年 T0.027777777777777776yb昨年 T0.027777777777777776ye続きっぽい T0.027777777777777776>va4<ya「 S0.02631578947368421yd機械学習 S0.02631578947368421ycによる S0.02631578947368421yb検索 S0.02631578947368421yeランキング S0.02631578947368421yb改善 S0.02631578947368421ycガイド S0.02631578947368421ya」 S0.02631578947368421yaを S0.05263157894736842yd読みまし S0.02631578947368421yaた S0.10526315789473684ya。 S0.05263157894736842ya  S0.05263157894736842yb著者 S0.02631578947368421yaの S0.07894736842105263yb鈴木 S0.02631578947368421ydさんより S0.02631578947368421yb献本 S0.02631578947368421yaい S0.02631578947368421ybだい S0.02631578947368421yb読み S0.02631578947368421yc終わっ S0.02631578947368421yaで S0.05263157894736842ydレビュー S0.02631578947368421yaと S0.02631578947368421ya、 S0.02631578947368421yeあとおまけ S0.02631578947368421yaす S0.02631578947368421yb紹介 S0.02631578947368421>va5<yb趣味 S0.06060606060606061ya？ T0.030303030303030304ya（ T0.030303030303030304yb検索 S0.06060606060606061ydエンジン T0.030303030303030304yaに T0.030303030303030304yc関する T0.030303030303030304yfプロジェクト T0.030303030303030304ya） T0.030303030303030304yaで T0.030303030303030304yfPython T0.030303030303030304yaの S0.06060606060606061yeプログラム T0.030303030303030304yaを T0.030303030303030304yb書い T0.030303030303030304yaて S0.06060606060606061ycいます T0.030303030303030304ya。 T0.030303030303030304ya  S0.06060606060606061ydベクトル T0.030303030303030304ybなど S0.06060606060606061yb確認 T0.030303030303030304yaも T0.030303030303030304yb含め T0.030303030303030304ya、 T0.030303030303030304ygJupyter T0.030303030303030304yaN T0.030303030303030304>va6<ydいくつか S0.02631578947368421ybある S0.02631578947368421yb環境 S0.02631578947368421yaを S0.05263157894736842ycDev S0.02631578947368421ya  S0.02631578947368421yiContainer S0.02631578947368421yaで S0.05263157894736842yb動く S0.02631578947368421ybよう S0.02631578947368421yaに S0.07894736842105263yb変え S0.02631578947368421yaて S0.02631578947368421ycいます S0.02631578947368421yaが S0.02631578947368421ya、 S0.02631578947368421yb最初 S0.02631578947368421yb導入 S0.02631578947368421yaし S0.05263157894736842yaた S0.07894736842105263ya時 S0.02631578947368421yc疑問点 S0.02631578947368421ybだっ S0.02631578947368421ya「 S0.02631578947368421ydコンテナ S0.02631578947368421ya名 S0.02631578947368421ya」 S0.02631578947368421ydについて S0.02631578947368421yb解消 S0.02631578947368421yaの S0.02631578947368421ybメモ S0.02631578947368421>va7<ya1 S0.02564102564102564ybこの S0.02564102564102564ycブログ S0.02564102564102564yaの S0.02564102564102564yb生成 S0.02564102564102564yaに S0.05128205128205128yaは S0.05128205128205128ya、 S0.07692307692307693ydHugo S0.02564102564102564yaを S0.02564102564102564yb利用 S0.02564102564102564yaし S0.05128205128205128yaて S0.07692307692307693ycいます S0.02564102564102564ya。 S0.05128205128205128ya  S0.05128205128205128ygブログ移行日記 S0.02564102564102564ya（ S0.02564102564102564ybその S0.02564102564102564ya） S0.02564102564102564yb書い S0.02564102564102564ydあります S0.02564102564102564yaが S0.02564102564102564yb当時 S0.02564102564102564ydbrew S0.02564102564102564yaで S0.02564102564102564yfインストール S0.02564102564102564ycいまし S0.02564102564102564yaた S0.02564102564102564ybまた S0.02564102564102564>va8<ya2 T0.030303030303030304ydWSL2 T0.030303030303030304yaに T0.030303030303030304yfUbuntu T0.030303030303030304yaを S0.09090909090909091yb入れ T0.030303030303030304yaて S0.09090909090909091ya、 S0.06060606060606061yb開発 T0.030303030303030304yaと T0.030303030303030304yaか T0.030303030303030304yaは T0.030303030303030304ycこちら T0.030303030303030304yb利用 S0.06060606060606061yaし S0.06060606060606061ycいます T0.030303030303030304ya。 T0.030303030303030304ya  S0.06060606060606061ybまた T0.030303030303030304yfDocker T0.030303030303030304ygDesktop T0.030303030303030304yaも T0.030303030303030304ycWSL T0.030303030303030304yaの T0.030303030303030304yjバックエンドエンジン T0.030303030303030304>va9<yb前回 T0.027777777777777776yaの T0.027777777777777776yb記事 T0.027777777777777776yaで T0.027777777777777776ya、 T0.027777777777777776ybVS T0.027777777777777776ya  R0.1111111111111111ydCode T0.027777777777777776ya＋ T0.027777777777777776ycDev S0.05555555555555555yiContainer T0.027777777777777776yaを T0.027777777777777776yb導入 T0.027777777777777776yaし T0.027777777777777776ybまし T0.027777777777777776yaた S0.05555555555555555ya。 S0.05555555555555555yc残課題 T0.027777777777777776ycとして T0.027777777777777776ya「 T0.027777777777777776yhマルチコンテナ化 T0.027777777777777776ya」 T0.027777777777777776yaが T0.027777777777777776ybある T0.027777777777777776ycという T0.027777777777777776yb話も T0.027777777777777776ycしまし T0.027777777777777776yb今回 T0.027777777777777776yaは T0.027777777777777776yaC T0.027777777777777776>vb10<yb前回 S0.03225806451612903yaの S0.06451612903225806yb記事 S0.03225806451612903yaで S0.06451612903225806ya、 S0.06451612903225806ycpre S0.03225806451612903ya- S0.03225806451612903yfcommit S0.03225806451612903yaと R0.0967741935483871ygPyCharm S0.03225806451612903ygWindows S0.03225806451612903yb組み S0.03225806451612903yc合わせ S0.03225806451612903yb困っ S0.03225806451612903yaて S0.03225806451612903ybいる S0.03225806451612903ybこと S0.03225806451612903yaを S0.03225806451612903yd書きまし S0.03225806451612903yaた S0.03225806451612903ya。 S0.03225806451612903ya  S0.03225806451612903ybこれ S0.03225806451612903ydについて S0.03225806451612903yd知り合い S0.03225806451612903ydチャット S0.03225806451612903>vb11<yb最近 S0.03571428571428571ya、 S0.03571428571428571yb趣味 S0.07142857142857142ya（ S0.03571428571428571yb検索 S0.03571428571428571ydエンジン S0.03571428571428571yaに S0.03571428571428571yc関する S0.03571428571428571yfプロジェクト S0.07142857142857142ya） S0.03571428571428571yaで S0.03571428571428571yfPython S0.07142857142857142yaの S0.07142857142857142yeプログラム S0.07142857142857142yaを S0.07142857142857142yb書き S0.03571428571428571yd始めまし S0.03571428571428571yaた S0.03571428571428571ya。 S0.03571428571428571ya  S0.03571428571428571ycきちん S0.03571428571428571yaと S0.03571428571428571>vb12<yb今年d0.05yaもd0.05ybこのe0.025yb季節e0.025yaがe0.025ybやっe0.025yaてd0.05ycきましe0.025yaたe0.075ya。d0.05ya e0.075yfBerline0.025yiBuzzwordse0.025yaにe0.025yeオンラインd0.05yaでc0.1yb出張e0.025yaしe0.025ybましe0.025yfハイブリッドe0.025yb開催e0.025yaをe0.025ybしてe0.025yaくe0.025yaれe0.025yaのe0.025ya、e0.025yb参加e0.025>vb13<yb今年 T0.022727272727272728yaも T0.022727272727272728ybなん T0.022727272727272728ybとか T0.022727272727272728yb振り S0.06818181818181818yb返り T0.045454545454545456ycブログ T0.022727272727272728yaを T0.045454545454545456yb書い T0.045454545454545456yaて T0.022727272727272728ybます T0.022727272727272728ya（ T0.045454545454545456ye時間大丈夫 T0.022727272727272728yaか T0.022727272727272728yaな T0.045454545454545456ya？ T0.022727272727272728yaw T0.022727272727272728ya） T0.045454545454545456ya。 T0.045454545454545456yb紅白 T0.022727272727272728ydリアタイ T0.022727272727272728yaで T0.022727272727272728ya見 T0.022727272727272728yaが T0.022727272727272728yaら T0.022727272727272728ya  T0.045454545454545456ye2021年 T0.022727272727272728yaに T0.022727272727272728yaた T0.022727272727272728yb抱負 T0.022727272727272728ybから T0.022727272727272728ybまず T0.022727272727272728yaは T0.022727272727272728ya返 T0.022727272727272728>vb14<yb12 T0.027777777777777776yb15 T0.027777777777777776yePySpa T0.027777777777777776yjアドベントカレンダー T0.027777777777777776yaの S0.05555555555555555ya/ T0.027777777777777776yeエントリー T0.027777777777777776yaで S0.08333333333333333yaす T0.027777777777777776ya。 S0.08333333333333333yb昨日 T0.027777777777777776yaは R0.1111111111111111yftaichi T0.027777777777777776ybさん T0.027777777777777776yaし T0.027777777777777776yaた T0.027777777777777776ya  S0.05555555555555555yb今年 T0.027777777777777776ycDIY T0.027777777777777776ybなく T0.027777777777777776ya、 T0.027777777777777776ybPC T0.027777777777777776yaに T0.027777777777777776ydまつわる T0.027777777777777776ya話 T0.027777777777777776yaを T0.027777777777777776yc仕事中 T0.027777777777777776>vb15<yd2022 S0.02631578947368421yc本記事 S0.02631578947368421yaは S0.02631578947368421yd情報検索 S0.02631578947368421ya・ S0.02631578947368421yd検索技術 S0.02631578947368421ya  S0.10526315789473684yfAdvent S0.02631578947368421yhCalendar S0.02631578947368421yaの S0.10526315789473684yc9日目 S0.02631578947368421yb記事 S0.05263157894736842yaで S0.02631578947368421yaす S0.02631578947368421ya。 S0.05263157894736842ycだいぶ S0.02631578947368421ya間 S0.02631578947368421yaが S0.05263157894736842yb空い S0.02631578947368421yaて S0.02631578947368421yeしまいまし S0.02631578947368421yaた S0.02631578947368421ya、 S0.02631578947368421yc日本語 S0.02631578947368421yiオートコンプリート S0.02631578947368421yaに S0.02631578947368421yc関する S0.02631578947368421yb続き S0.02631578947368421ybです S0.02631578947368421>vb16<yb前回 T0.030303030303030304yaは S0.06060606060606061yd日本語用 T0.030303030303030304yiオートコンプリート T0.030303030303030304yaの S0.06060606060606061ybため T0.030303030303030304yhAnalyzer T0.030303030303030304ycとして T0.030303030303030304ya、 S0.06060606060606061ydどうやっ T0.030303030303030304yaて T0.030303030303030304yb使う T0.030303030303030304ybのか T0.030303030303030304yaを S0.06060606060606061yb簡単 T0.030303030303030304yaに T0.030303030303030304yb紹介 T0.030303030303030304yaし T0.030303030303030304ybまし T0.030303030303030304yaた T0.030303030303030304ya。 T0.030303030303030304ya  T0.030303030303030304yb今回 T0.030303030303030304ybもう T0.030303030303030304yb少し T0.030303030303030304ycいろん T0.030303030303030304yaな T0.030303030303030304ydパターン T0.030303030303030304ya試 T0.030303030303030304>vb17<ya風 T0.041666666666666664yaの S0.16666666666666666ycうわさ T0.041666666666666664yaで T0.041666666666666664ya、 T0.041666666666666664yd日本語用 T0.041666666666666664yiオートコンプリート T0.041666666666666664ybため T0.041666666666666664ykTokenFilter T0.041666666666666664yaと S0.08333333333333333yhAnalyzer T0.041666666666666664yaが T0.041666666666666664yfLucene T0.041666666666666664yaに T0.041666666666666664ye取り込まれ T0.041666666666666664yaた S0.08333333333333333yd聞きまし T0.041666666666666664ya（ T0.041666666666666664ydLUCE T0.041666666666666664>vb18<ya0 S0.05405405405405406yb84 S0.02702702702702703yb92 S0.02702702702702703ydHugo S0.02702702702702703yaを S0.10810810810810811ya. S0.05405405405405406ybから S0.02702702702702703yaに S0.08108108108108109yfアップデート S0.02702702702702703ybする S0.02702702702702703ya際 S0.02702702702702703ya、 S0.02702702702702703ybこれ S0.02702702702702703ybまで S0.02702702702702703yaの S0.05405405405405406ycブログ S0.02702702702702703yb記事 S0.02702702702702703yaや S0.02702702702702703yiレイアウトファイル S0.02702702702702703yb修正 S0.02702702702702703yaし S0.02702702702702703yaた S0.02702702702702703yaで S0.02702702702702703yc個人的 S0.02702702702702703ybメモ S0.02702702702702703yb残し S0.02702702702702703yaて S0.02702702702702703ydおきます S0.02702702702702703ya。 S0.02702702702702703>vb19<yb今回 S0.03333333333333333yaは S0.03333333333333333yfQuerqy S0.03333333333333333yaの S0.06666666666666667ymElasticsearch S0.03333333333333333yeプラグイン S0.03333333333333333yaが S0.03333333333333333ybどん S0.03333333333333333ydなつくり S0.03333333333333333yaに S0.03333333333333333ybなっ S0.03333333333333333yaて S0.06666666666666667ybいる S0.03333333333333333yaか S0.03333333333333333ya？ S0.03333333333333333yaを S0.03333333333333333ycちょっ S0.03333333333333333yaと S0.03333333333333333ybだけ S0.03333333333333333yb調べ S0.03333333333333333ycみまし S0.03333333333333333yaた S0.03333333333333333ya。 S0.03333333333333333ya  S0.03333333333333333ydSolr S0.03333333333333333yaで S0.03333333333333333yaも S0.03333333333333333yeElast S0.03333333333333333>vb20<yfQuerqyg0.03125ycというg0.03125ycクエリg0.03125yaのg0.09375ydリライトg0.03125ya用g0.03125yeプラグインg0.03125yaがg0.03125ybあるg0.03125yaでg0.03125ybどんg0.03125ydなものかg0.03125yaをf0.0625yb調べg0.03125yaてf0.0625ycみましg0.03125yaたf0.0625ya。g0.03125ybとりg0.03125ycあえずg0.03125yaはg0.03125yb概要g0.03125yfドキュメントg0.03125ybからg0.03125yd追いかけg0.03125yaみg0.03125yb感じg0.03125>vb21<yb今年 S0.05555555555555555yaも T0.027777777777777776yfBerlin T0.027777777777777776ya  S0.05555555555555555yiBuzzwords T0.027777777777777776yaに T0.027777777777777776yeオンライン T0.027777777777777776yb出張 T0.027777777777777776yaし S0.08333333333333333yaて S0.05555555555555555ybまし T0.027777777777777776yaた S0.08333333333333333ya。 S0.05555555555555555yaは T0.027777777777777776yfハイブリッド T0.027777777777777776yaな T0.027777777777777776yb開催 T0.027777777777777776ybだっ T0.027777777777777776ybよう S0.05555555555555555yaで S0.08333333333333333ya、 T0.027777777777777776yb現地 T0.027777777777777776yb再開 T0.027777777777777776ybいる T0.027777777777777776yd人もいる T0.027777777777777776>vb22<ya7 S0.02702702702702703yb16 S0.02702702702702703ya. S0.02702702702702703yaで S0.08108108108108109yb正式 S0.02702702702702703ydリリース S0.02702702702702703yaさ S0.02702702702702703yaれ S0.02702702702702703ybまし S0.02702702702702703yaた S0.05405405405405406yaが S0.05405405405405406ya、 S0.05405405405405406ymElasticsearch S0.02702702702702703yaの S0.08108108108108109yc新しい S0.02702702702702703ydJava S0.02702702702702703yfクライアント S0.02702702702702703ya出 S0.02702702702702703yaて S0.05405405405405406yaい S0.02702702702702703ybます S0.02702702702702703ya。 S0.02702702702702703ya  S0.02702702702702703yb使っ S0.02702702702702703yaみ S0.02702702702702703ycちょっ S0.02702702702702703yaと S0.02702702702702703ybだけ S0.02702702702702703yb紹介 S0.02702702702702703>vb23<yeAzure S0.02702702702702703ya  S0.10810810810810811yiCognitive S0.02702702702702703yfSearch S0.02702702702702703yaで S0.05405405405405406yb2月 S0.02702702702702703yaに S0.02702702702702703yc新しい S0.02702702702702703yb機能 S0.02702702702702703yaが S0.02702702702702703yb公開 S0.02702702702702703yaさ S0.02702702702702703yaれ S0.02702702702702703ybまし S0.02702702702702703yaた S0.02702702702702703ya。 S0.05405405405405406ya「 S0.02702702702702703yeIndex S0.02702702702702703yeAlias S0.02702702702702703ya」 S0.02702702702702703ya（ S0.02702702702702703yfインデックス S0.02702702702702703yaの S0.05405405405405406yb別名 S0.02702702702702703ya） S0.02702702702702703ybです S0.02702702702702703ybまだ S0.02702702702702703ya、 S0.02702702702702703yjパブリックプレビュー S0.02702702702702703yb段階 S0.02702702702702703yaす S0.02702702702702703>vb24<yb年末 S0.01818181818181818ybまで S0.01818181818181818yaに S0.01818181818181818yd知り合い S0.01818181818181818yaと S0.03636363636363636ya次 S0.01818181818181818yaの S0.05454545454545454yb論文 S0.01818181818181818yaを S0.01818181818181818yb読ん S0.03636363636363636yaだ S0.05454545454545454yaで S0.05454545454545454yb軽く S0.01818181818181818ydまとめて S0.01818181818181818ydおきます S0.01818181818181818ya。 S0.01818181818181818ya c0.2ygExtreme S0.01818181818181818yeMulti S0.01818181818181818ya- S0.01818181818181818yelabel S0.01818181818181818yhLearning S0.01818181818181818ycfor S0.01818181818181818yhSemantic S0.03636363636363636yhMatching S0.01818181818181818ybin S0.01818181818181818ygProduct S0.01818181818181818yfSearch S0.01818181818181818ybなん S0.01818181818181818ya？ S0.01818181818181818yd前回読ん S0.01818181818181818yb理由 S0.01818181818181818yb一緒 S0.01818181818181818yaす S0.01818181818181818yaが S0.01818181818181818ya、 S0.01818181818181818>vb25<yb今年 T0.022727272727272728yaも T0.022727272727272728yb振り T0.045454545454545456yb返り T0.045454545454545456ycブログ T0.022727272727272728yaで T0.022727272727272728yaす T0.022727272727272728ya。 T0.045454545454545456yb録画 T0.022727272727272728yaし T0.045454545454545456yaた T0.045454545454545456yb紅白 T0.022727272727272728yaを T0.022727272727272728ybオッ T0.022727272727272728ybかけ T0.022727272727272728yb再生 T0.022727272727272728yaて T0.045454545454545456ya気 T0.022727272727272728yaに T0.045454545454545456ybなる T0.022727272727272728yfアーティスト T0.022727272727272728ybだけ T0.022727272727272728ya見 T0.022727272727272728yaな T0.022727272727272728ybがら T0.022727272727272728ya書 T0.022727272727272728yaい T0.022727272727272728ybます T0.022727272727272728ya  T0.045454545454545456ya（ T0.022727272727272728ye2020年 T0.022727272727272728yb書い T0.022727272727272728yb抱負 T0.022727272727272728ybから T0.022727272727272728ya） T0.022727272727272728yaま T0.022727272727272728>vb26<ye2021年 S0.02857142857142857yaも S0.02857142857142857ybあと S0.02857142857142857yb少し S0.02857142857142857yaで S0.02857142857142857yaす S0.02857142857142857yaが S0.05714285714285714ya、 S0.05714285714285714yd今年買っ S0.05714285714285714yaて S0.05714285714285714yc良かっ S0.02857142857142857yaた S0.05714285714285714ybもの S0.02857142857142857yaを S0.05714285714285714yfリストアップ S0.02857142857142857yaし S0.02857142857142857ydおこうか S0.02857142857142857yaと S0.02857142857142857yd思います S0.02857142857142857ya。 S0.02857142857142857ya  S0.02857142857142857ycといい S0.02857142857142857yaな S0.02857142857142857yaら S0.02857142857142857yb昨年 S0.02857142857142857ybこの S0.02857142857142857ybネタ S0.02857142857142857yb書く S0.02857142857142857yeといいつつ S0.02857142857142857>vb27<yeAzure S0.05263157894736842ya  S0.07894736842105263yiCognitive S0.02631578947368421yfSearch S0.02631578947368421yaの S0.15789473684210525ydスキーマ S0.02631578947368421yb確認 S0.02631578947368421yaを S0.02631578947368421ybする S0.02631578947368421ybとき S0.02631578947368421yaに S0.05263157894736842ya、 S0.05263157894736842ydポータル S0.02631578947368421yaで S0.02631578947368421yaは S0.02631578947368421ya次 S0.02631578947368421ybよう S0.02631578947368421yeフィールド S0.02631578947368421yb一覧 S0.02631578947368421ycとして S0.02631578947368421yb見る S0.02631578947368421ybこと S0.02631578947368421yaが S0.02631578947368421ydできます S0.02631578947368421ya。 S0.02631578947368421ybただ S0.02631578947368421yb実際 S0.02631578947368421ycインデ S0.02631578947368421>vb28<yd2021e0.025yb今年d0.05yaもe0.025yjアドベントカレンダーe0.025yaのe0.075yb季節e0.025yaにd0.05ybなっe0.025yaてe0.025yeしまいましe0.025yaたe0.025ya。d0.05ya e0.125yaでd0.05yc2回目e0.025yaとe0.025ybなるe0.025ya、e0.025yepyspae0.025yfAdvente0.025yhCalendare0.025yb投稿d0.05yaすe0.025yb昨年e0.025yb引きe0.025yb続きe0.025ycDIYe0.025yaがe0.025ybらみe0.025>vb29<yfDomain T0.017543859649122806ya- T0.017543859649122806yhSpecific T0.017543859649122806ya  S0.22807017543859648ykPretraining T0.017543859649122806ycfor T0.017543859649122806yhVertical T0.017543859649122806yfSearch T0.017543859649122806ya: T0.017543859649122806ydCase T0.017543859649122806yeStudy T0.017543859649122806ybon T0.017543859649122806yjBiomedical T0.017543859649122806yjLiterature T0.017543859649122806ycという T0.017543859649122806yb論文 T0.017543859649122806yaを S0.03508771929824561yb読ん S0.03508771929824561yaだ S0.05263157894736842yaの T0.017543859649122806yaで T0.017543859649122806yb軽く T0.017543859649122806ybメモ T0.017543859649122806yb残し T0.017543859649122806yaて S0.03508771929824561ydおきます T0.017543859649122806ya。 S0.03508771929824561yd論文自体 T0.017543859649122806yaは T0.017543859649122806ycリンク T0.017543859649122806ybから T0.017543859649122806yb参照 T0.017543859649122806yaし T0.017543859649122806yaく T0.017543859649122806ybさい T0.017543859649122806yb理由 T0.017543859649122806yeAzure T0.017543859649122806yiCognitive T0.017543859649122806yaS T0.017543859649122806>vb30<yc201 S0.02564102564102564yb今年 S0.05128205128205128yaも S0.05128205128205128yeMICES S0.05128205128205128yaに S0.02564102564102564yb参加 S0.02564102564102564yaし S0.07692307692307693yaて S0.02564102564102564ybまし S0.02564102564102564yaた S0.07692307692307693ya。 S0.05128205128205128ya  S0.07692307692307693yb昨年 S0.02564102564102564yaは S0.07692307692307693yfBerlin S0.02564102564102564yiBuzzwords S0.02564102564102564yaと S0.02564102564102564yb共同 S0.02564102564102564yb開催 S0.02564102564102564yaで S0.05128205128205128yaが S0.02564102564102564ya、 S0.02564102564102564yc別開催 S0.02564102564102564ya（ S0.02564102564102564yc別日程 S0.02564102564102564ya） S0.02564102564102564>vb31<yb今年 T0.058823529411764705yaも T0.029411764705882353yfBerlin T0.029411764705882353ya  S0.08823529411764706yiBuzzwords T0.029411764705882353yaに T0.029411764705882353yeオンライン T0.029411764705882353yb出張 T0.029411764705882353yaし T0.058823529411764705yaて T0.029411764705882353ybまし T0.029411764705882353yaた T0.058823529411764705ya。 T0.058823529411764705yaの T0.029411764705882353yb開催 T0.029411764705882353yaは T0.058823529411764705ye6月14日 T0.029411764705882353ybから T0.029411764705882353yc17日 T0.029411764705882353ybまで T0.029411764705882353yaで T0.029411764705882353ybどん T0.029411764705882353yaな T0.058823529411764705ygカンファレンス T0.029411764705882353ybのか T0.029411764705882353yb昨年 T0.029411764705882353>vb32<yeAzure T0.029411764705882353ya  S0.14705882352941177yiCognitive T0.029411764705882353yfSearch T0.058823529411764705yaで T0.029411764705882353yc新機能 T0.029411764705882353ya「 T0.029411764705882353yhSemantic T0.029411764705882353ya（ T0.029411764705882353ygセマンティック T0.029411764705882353yb検索 T0.029411764705882353ya） T0.029411764705882353ya」 T0.029411764705882353ycという T0.029411764705882353yb機能 T0.029411764705882353yaの T0.029411764705882353ye日本語対応 T0.029411764705882353yaが T0.029411764705882353yb発表 T0.029411764705882353yaさ T0.029411764705882353yaれ T0.029411764705882353ybまし T0.029411764705882353yaた T0.029411764705882353ya。 T0.029411764705882353yb実際 T0.029411764705882353yaに T0.029411764705882353yaは T0.029411764705882353yfPublic T0.029411764705882353yaP T0.029411764705882353>vb33<yeSofle S0.03225806451612903ya  R0.0967741935483871ybv2 S0.03225806451612903yaを S0.03225806451612903yc長らく S0.03225806451612903yb使っ S0.03225806451612903yaて S0.06451612903225806ycいまし S0.03225806451612903yaた S0.03225806451612903yaが S0.06451612903225806ya、 S0.03225806451612903yeコンパクト S0.03225806451612903yaな S0.03225806451612903yaの S0.03225806451612903yaも S0.03225806451612903ygやっぱりいいよ S0.03225806451612903ybなぁ S0.03225806451612903ycという S0.03225806451612903ybとき S0.03225806451612903yaに S0.03225806451612903yeKochi S0.03225806451612903yhKeyboard S0.03225806451612903ybから S0.03225806451612903ygLunakey S0.03225806451612903ydMini S0.03225806451612903yb発売 S0.03225806451612903yaし S0.03225806451612903>vb34<yaみ T0.030303030303030304ycなさん T0.030303030303030304yaは S0.09090909090909091ya、 S0.06060606060606061ydスライド S0.06060606060606061yaの T0.030303030303030304yb作成 T0.030303030303030304yaに T0.030303030303030304ya何 T0.030303030303030304yaを S0.06060606060606061yb使っ T0.030303030303030304yaて T0.030303030303030304ydいますか T0.030303030303030304ya？ S0.12121212121212122ya  S0.09090909090909091ygKeynote T0.030303030303030304yjPowerpoint T0.030303030303030304yfGoogle T0.030303030303030304yfSlides T0.030303030303030304ya私 T0.030303030303030304ycMac T0.030303030303030304yaで T0.030303030303030304ya作 T0.030303030303030304>vb35<yb新型 S0.02702702702702703ygコロナウィルス S0.02702702702702703yaの S0.02702702702702703yb影響 S0.02702702702702703yaも S0.08108108108108109ybあり S0.02702702702702703ya、 S0.05405405405405406yeオフライン S0.02702702702702703yaで S0.05405405405405406yc集まっ S0.02702702702702703yaて S0.08108108108108109yc勉強会 S0.02702702702702703yb開催 S0.02702702702702703ybでき S0.05405405405405406ybなく S0.02702702702702703ybなっ S0.02702702702702703yaい S0.05405405405405406ybます S0.02702702702702703ya。 S0.05405405405405406ya  S0.05405405405405406yg検索技術勉強会 S0.02702702702702703ybもう S0.02702702702702703yb1年 S0.02702702702702703yd以上開催 S0.02702702702702703ybない S0.02702702702702703yaす S0.02702702702702703yaス S0.02702702702702703>vb36<yeAzure T0.029411764705882353ya  S0.08823529411764706yiCognitive T0.029411764705882353yfSearch T0.029411764705882353yaに T0.029411764705882353yaは T0.058823529411764705yeOData T0.058823529411764705ya式 T0.029411764705882353ycという T0.029411764705882353yb書式 T0.029411764705882353yaで T0.029411764705882353yb条件 T0.058823529411764705yaが T0.058823529411764705yc書ける T0.029411764705882353yb仕組 T0.029411764705882353yaみ T0.029411764705882353ydあります T0.029411764705882353ya。 T0.029411764705882353yd検索条件 T0.029411764705882353ya（ T0.058823529411764705ya$ T0.058823529411764705yffilter T0.029411764705882353ya） T0.029411764705882353yaや T0.029411764705882353ycソート T0.029411764705882353yforderb T0.029411764705882353>vb37<yd2020 T0.045454545454545456yb自宅 T0.022727272727272728yaの S0.11363636363636363yb環境 T0.022727272727272728yaが T0.045454545454545456ydいろいろ T0.022727272727272728yaと T0.022727272727272728yc変わっ T0.022727272727272728yaた T0.045454545454545456yaで S0.06818181818181818yaす T0.045454545454545456ya、 T0.045454545454545456yb書い T0.022727272727272728yaて T0.022727272727272728yaい T0.022727272727272728ycなかっ T0.022727272727272728yc更新版 T0.022727272727272728ya。 T0.022727272727272728ya  T0.022727272727272728yb前回 T0.022727272727272728ycブログ T0.045454545454545456ya( T0.045454545454545456ya/ T0.045454545454545456yb09 T0.022727272727272728ya) T0.045454545454545456yc前々回 T0.022727272727272728yb03 T0.022727272727272728yaは T0.022727272727272728yaそ T0.022727272727272728>vb38<yeAzure T0.027777777777777776ya  S0.08333333333333333yiCognitive T0.027777777777777776yfSearch T0.027777777777777776yaに T0.027777777777777776ygSuggest T0.027777777777777776yaや T0.027777777777777776ylAutocomplete T0.027777777777777776yaの S0.08333333333333333yb機能 T0.027777777777777776yaが T0.027777777777777776ybある T0.027777777777777776yaを S0.05555555555555555yc見つけ T0.027777777777777776yaた T0.027777777777777776yaで T0.027777777777777776ya、 T0.027777777777777776ybどん T0.027777777777777776yaな S0.05555555555555555yb挙動 T0.027777777777777776ybのか T0.027777777777777776yb調べ T0.027777777777777776yaて S0.05555555555555555ybログ T0.027777777777777776ycとして T0.027777777777777776yb残し T0.027777777777777776ydおきます T0.027777777777777776ya。 T0.027777777777777776ya公 T0.027777777777777776>vb39<yjオライリー・ジャパン T0.027777777777777776ybから T0.027777777777777776ya出 T0.027777777777777776yaて T0.027777777777777776ybいる T0.027777777777777776ya「 T0.027777777777777776yjコンピュータシステム T0.027777777777777776yaの R0.1111111111111111yb理論 T0.027777777777777776yaと T0.027777777777777776yb実装 T0.027777777777777776ya」 T0.027777777777777776yaを S0.05555555555555555yb読み T0.027777777777777776yb始め T0.027777777777777776yaた T0.027777777777777776yaで T0.027777777777777776ybメモ T0.027777777777777776yb取る T0.027777777777777776ybこと T0.027777777777777776yaに T0.027777777777777776ya。 T0.027777777777777776ya  T0.027777777777777776yb原著 T0.027777777777777776yaは T0.027777777777777776yeオライリー T0.027777777777777776yaじ T0.027777777777777776yaゃ T0.027777777777777776ybない T0.027777777777777776yaか T0.027777777777777776ycという T0.027777777777777776yaが T0.027777777777777776>vb40<ygCorne使っ S0.02631578947368421yaて S0.02631578947368421ybまし S0.02631578947368421yaた S0.02631578947368421yaが S0.07894736842105263ya、 S0.05263157894736842yb数字 S0.02631578947368421ybキー S0.02631578947368421ybある S0.02631578947368421ycとどう S0.02631578947368421yaな S0.05263157894736842yaの S0.05263157894736842yaか S0.02631578947368421ya？ S0.02631578947368421ycという S0.02631578947368421yaや S0.02631578947368421ybはり S0.02631578947368421ya気 S0.02631578947368421yaに S0.02631578947368421ycなって S0.02631578947368421ya。 S0.02631578947368421ya  S0.10526315789473684ycそこに S0.02631578947368421yeKochi S0.02631578947368421yhKeyboard S0.05263157894736842ybさん S0.02631578947368421ybから S0.02631578947368421yeSofle S0.02631578947368421yav S0.02631578947368421>vb41<yfメインマシン S0.03333333333333333yaと S0.03333333333333333ycMac S0.03333333333333333yaは S0.03333333333333333yb下記 S0.03333333333333333yaのc0.1ygサンワサプライ S0.03333333333333333ycUSB S0.03333333333333333yb接続 S0.06666666666666667ycKVM S0.03333333333333333ydスイッチ S0.03333333333333333yaを S0.03333333333333333yb使っ S0.03333333333333333yaて S0.06666666666666667ycいます S0.03333333333333333yaが S0.06666666666666667ya、 S0.03333333333333333ybもう S0.03333333333333333yb一台 S0.03333333333333333ycノート S0.03333333333333333ybPC S0.03333333333333333yeありここに S0.03333333333333333yaし S0.03333333333333333ybいる S0.03333333333333333yeCorne S0.03333333333333333>vb42<yb振り T0.027777777777777776yb返り T0.027777777777777776ycブログ T0.027777777777777776yaに S0.05555555555555555yaも T0.027777777777777776yd書きまし T0.027777777777777776yaた R0.1111111111111111yaが T0.027777777777777776ya、 T0.027777777777777776yfデスクトップ T0.027777777777777776ybPC T0.027777777777777776yaを S0.05555555555555555yb自作 T0.027777777777777776ya( T0.027777777777777776ycDIY T0.027777777777777776ya) T0.027777777777777776ycしまし T0.027777777777777776ya。 S0.05555555555555555ya  S0.05555555555555555yb組み T0.027777777777777776yb立て T0.027777777777777776yb使っ T0.027777777777777776ycパーツ T0.027777777777777776yaの T0.027777777777777776yfアフィリンク T0.027777777777777776yb貼っ T0.027777777777777776yaて T0.027777777777777776ydおきます T0.027777777777777776ye10月くら T0.027777777777777776>vb43<yb今年 T0.023809523809523808yaも T0.023809523809523808yb振り T0.047619047619047616yb返り T0.047619047619047616yeブログ書い T0.023809523809523808yaて S0.09523809523809523ybます T0.023809523809523808ya。 T0.047619047619047616ycカタン T0.023809523809523808yaの T0.023809523809523808yb航海 T0.023809523809523808yb者版 T0.023809523809523808yaを T0.023809523809523808yb購入 T0.023809523809523808yaし T0.023809523809523808yb家族 T0.023809523809523808yaと T0.023809523809523808ybやっ T0.023809523809523808ybまし T0.023809523809523808yaた S0.07142857142857142yaが T0.023809523809523808ya、 T0.023809523809523808yb負け T0.023809523809523808yeしまいまし T0.023809523809523808ya  T0.047619047619047616ya（ T0.023809523809523808ye2019年 T0.023809523809523808yaに T0.023809523809523808yb書い T0.023809523809523808yb抱負 T0.023809523809523808ybから T0.023809523809523808ya） T0.023809523809523808yaま T0.023809523809523808>vb44<ya7 T0.019230769230769232ya8 T0.019230769230769232yd2020 T0.019230769230769232ygElastic T0.019230769230769232ya  S0.15384615384615385yestack T0.019230769230769232ya( T0.019230769230769232ymElasticsearch T0.038461538461538464ya) T0.019230769230769232yfAdvent T0.019230769230769232yhCalendar T0.019230769230769232yaの T0.057692307692307696yd18日目 T0.019230769230769232yb記事 T0.019230769230769232yaに T0.019230769230769232ydなります T0.019230769230769232ya。 T0.038461538461538464yb本日 T0.019230769230769232yc勉強会 T0.019230769230769232yaで T0.057692307692307696ybLT T0.019230769230769232yaを T0.019230769230769232ycしまし T0.019230769230769232yaた T0.038461538461538464yaが T0.019230769230769232ya、 T0.019230769230769232ydしゃべり T0.019230769230769232yb足り T0.019230769230769232ycなかっ T0.019230769230769232ybたん T0.019230769230769232ya. T0.019230769230769232ybこっ T0.019230769230769232ybそり T0.019230769230769232yaと T0.019230769230769232ydリリース T0.019230769230769232yaさ T0.019230769230769232yaれ T0.019230769230769232yaI T0.019230769230769232>vb45<yd2020 S0.02702702702702703yaは S0.02702702702702703yeじめまして S0.02702702702702703ya、 S0.05405405405405406yepyspa S0.05405405405405406ya。 S0.05405405405405406ya  S0.13513513513513514ycという S0.02702702702702703ybこと S0.02702702702702703yaで S0.05405405405405406yfAdvent S0.02702702702702703yhCalendar S0.02702702702702703yaの S0.08108108108108109yc4日目 S0.02702702702702703ya( S0.02702702702702703yb大谷 S0.02702702702702703ycコンビ S0.05405405405405406yb2号 S0.02702702702702703ya) S0.02702702702702703yb投稿 S0.02702702702702703yaに S0.02702702702702703ydなります S0.02702702702702703ydそろって S0.02702702702702703yeキーボード S0.02702702702702703yb記事 S0.02702702702702703yaす S0.02702702702702703>vb46<yb前回 S0.02857142857142857yaの S0.11428571428571428ycブログ S0.02857142857142857ycまとめ S0.02857142857142857yaに S0.05714285714285714yb書い S0.02857142857142857yaた S0.05714285714285714ybよう S0.02857142857142857ya、 S0.02857142857142857yhセパレートタイプ S0.02857142857142857yeキーボード S0.05714285714285714yaで S0.08571428571428572ybある S0.02857142857142857yeCorne S0.02857142857142857ya  S0.05714285714285714yeLight S0.02857142857142857ybv2 S0.02857142857142857yaを S0.02857142857142857yb作成 S0.02857142857142857yaし S0.02857142857142857ybその S0.02857142857142857yeビルドログ S0.02857142857142857yaす S0.02857142857142857ya。 S0.02857142857142857ycDIY S0.02857142857142857ybとし S0.02857142857142857>vb47<ybヒゲ S0.02631578947368421yaが S0.05263157894736842yb不評 S0.02631578947368421ybだっ S0.02631578947368421yaた S0.10526315789473684yaの S0.07894736842105263ycでいつ S0.02631578947368421yaも S0.02631578947368421yb通り S0.02631578947368421yb長さ S0.02631578947368421yaに S0.02631578947368421yd切りまし S0.02631578947368421ya。 S0.02631578947368421ya  S0.02631578947368421yb前回 S0.02631578947368421ya「 S0.02631578947368421ygWindows S0.02631578947368421yaを S0.05263157894736842ycお試し S0.02631578947368421ya中 S0.02631578947368421ya」 S0.02631578947368421yaと S0.02631578947368421yd書きまし S0.02631578947368421ya、 S0.02631578947368421ydいくつか S0.02631578947368421ycソフト S0.02631578947368421yfインストール S0.02631578947368421yaし S0.05263157894736842ybたり S0.02631578947368421yaで S0.02631578947368421>vb48<ybヒゲ S0.02127659574468085yaが S0.06382978723404255yb伸び S0.02127659574468085yaて R0.0851063829787234ybきて S0.02127659574468085ya( S0.02127659574468085yb試し S0.02127659574468085yaに S0.02127659574468085ye伸ばしてる S0.02127659574468085ya) S0.02127659574468085yb不評 S0.02127659574468085yaを S0.02127659574468085yb買っ S0.02127659574468085ybいる S0.02127659574468085yb今日 S0.02127659574468085yaこ S0.02127659574468085yaの R0.0425531914893617ybごろ S0.02127659574468085yaで R0.0851063829787234yaす S0.02127659574468085ya。 S0.02127659574468085ya  S0.02127659574468085yb自宅 S0.02127659574468085yb作業 S0.02127659574468085ybする S0.02127659574468085ybこと S0.02127659574468085yb多く S0.02127659574468085ybなっ S0.02127659574468085yaき S0.02127659574468085yaた S0.02127659574468085ya、 R0.0425531914893617yb自作 S0.02127659574468085ybPC S0.02127659574468085yaも S0.02127659574468085yaと S0.02127659574468085yb思っ S0.02127659574468085ycいます S0.02127659574468085>vb49<yb今年g0.03125yaのg0.09375yd春くらいg0.03125ybからg0.03125ya、g0.09375yhセパレートタイプg0.03125yeキーボードf0.0625yaがg0.09375ya気g0.03125yaにg0.03125ybなっg0.03125yaてg0.03125yaいg0.03125ybますg0.03125ya。g0.03125ya g0.03125ybまたg0.03125ycなんかg0.03125yb知らg0.03125ybないg0.03125yaでg0.03125yaすg0.03125ygTwitterg0.03125yfタイムラインg0.03125yb自作g0.03125>vb50<yb10e0.025yb11e0.025yd2020e0.025ya/d0.05yb06e0.025ya e0.075ya:e0.025ye00くらいe0.025yaにe0.025ycマージe0.025yaさe0.025yaれe0.025ybましe0.025yaたe0.025ya。e0.025ya@e0.025yfminorue0.025ya_e0.025yeosukae0.025ybさんe0.025yaがd0.05yb開発e0.025yaをe0.025yb引きe0.025yb継いe0.025yaだe0.025ygLinderae0.025ycというe0.025yhKuromojie0.025yaのe0.025ydRuste0.025ydクローンe0.025ydありますe0.025ya(e0.025yeリポジトリe0.025ya)e0.025>vb51<yb先日 S0.02702702702702703yaは S0.02702702702702703ya「 S0.02702702702702703yb検索 S0.08108108108108109ydシステム S0.05405405405405406yaを S0.05405405405405406yb構成 S0.05405405405405406ybする S0.02702702702702703ycパーツ S0.05405405405405406ya」 S0.02702702702702703ycという S0.02702702702702703ybこと S0.02702702702702703yaで S0.02702702702702703yaし S0.05405405405405406yaて S0.05405405405405406ybいる S0.02702702702702703ydについて S0.02702702702702703yb書い S0.02702702702702703ycみまし S0.02702702702702703yaた S0.02702702702702703ya。 S0.02702702702702703ya  S0.02702702702702703yb大体 S0.02702702702702703ya、 S0.02702702702702703yaが S0.02702702702702703ycうまく S0.02702702702702703ycヒット S0.02702702702702703ybない S0.02702702702702703ybとい S0.02702702702702703>vb52<yd自宅環境 S0.02631578947368421yaに S0.02631578947368421yb少し S0.02631578947368421yfアップデート S0.02631578947368421yaが S0.02631578947368421ybあっ S0.02631578947368421yaた S0.02631578947368421yaの S0.13157894736842105yaで S0.10526315789473684yc更新版 S0.02631578947368421yaす S0.02631578947368421ya。 S0.02631578947368421ya  S0.02631578947368421yaお S0.02631578947368421yc客さん S0.02631578947368421ycおかげ S0.02631578947368421yb相変 S0.02631578947368421ycわらず S0.02631578947368421yb自宅 S0.02631578947368421yb作業 S0.02631578947368421yaさ S0.02631578947368421yaせ S0.02631578947368421yaて S0.02631578947368421ycもらっ S0.02631578947368421ybてる S0.02631578947368421yaも S0.02631578947368421ybあり S0.02631578947368421ya、 S0.02631578947368421yb昨今 S0.02631578947368421ygコロナウイルス S0.02631578947368421yb影響 S0.02631578947368421>vb53<ydRust T0.047619047619047616yaで S0.07142857142857142yb便利 T0.023809523809523808yaな T0.023809523809523808ydクレート T0.023809523809523808yaを T0.047619047619047616yc見つけ T0.023809523809523808yaた T0.023809523809523808yaの S0.07142857142857142ya、 S0.07142857142857142yb紹介 T0.023809523809523808yaが T0.023809523809523808yaて S0.09523809523809523yaら T0.023809523809523808yb自分 T0.023809523809523808ybメモ T0.023809523809523808ybため T0.023809523809523808yaに T0.047619047619047616ycブログ T0.023809523809523808yb残し T0.023809523809523808ydおきます T0.023809523809523808ya。 T0.023809523809523808ya  T0.047619047619047616yeそもそもの T0.023809523809523808yb問題 T0.023809523809523808yb処理 T0.023809523809523808yb書い T0.023809523809523808yaい T0.023809523809523808ybなん T0.023809523809523808>vb54<ydRust T0.022727272727272728yaで S0.06818181818181818yb言語 T0.022727272727272728yb処理 T0.022727272727272728yd100本 T0.022727272727272728ycノック T0.022727272727272728yaの T0.045454545454545456ya第 T0.045454545454545456yb4章 T0.045454545454545456yaす T0.022727272727272728ya。 S0.09090909090909091ya  S0.11363636363636363yb前回 T0.022727272727272728yaは S0.06818181818181818ycこちら T0.022727272727272728yb今回 T0.022727272727272728yb早め T0.022727272727272728yaに T0.022727272727272728yb続き T0.022727272727272728yaを T0.022727272727272728ydやりまし T0.022727272727272728yaた T0.022727272727272728ya「 T0.022727272727272728ye形態素解析 T0.022727272727272728ya」 T0.022727272727272728ydですしね T0.022727272727272728yb概要 T0.022727272727272728yb吾輩 T0.022727272727272728ya猫 T0.022727272727272728ybある T0.022727272727272728>vb55<ydRust T0.021739130434782608yaで S0.06521739130434782yb言語 T0.021739130434782608yb処理 T0.021739130434782608yd100本 T0.021739130434782608ycノック T0.021739130434782608yaの T0.021739130434782608ya第 T0.021739130434782608yb3章 T0.021739130434782608yaす T0.021739130434782608ya。 S0.15217391304347827ya  S0.06521739130434782yb前回 T0.021739130434782608yaは T0.043478260869565216ycこちら T0.021739130434782608yb少し T0.021739130434782608ya間 T0.043478260869565216yaが S0.06521739130434782yd空きまし T0.021739130434782608yaた S0.06521739130434782ya、 T0.021739130434782608yb再開 T0.021739130434782608yaし T0.021739130434782608ybまし T0.021739130434782608yb空い T0.021739130434782608yb理由 T0.021739130434782608ya「 T0.021739130434782608yd正規表現 T0.021739130434782608ya」 T0.021739130434782608ycすかね T0.021739130434782608>vb56<yb負荷 S0.02631578947368421yaを S0.05263157894736842yb計測 S0.02631578947368421ybする S0.02631578947368421ybため S0.02631578947368421yaに S0.02631578947368421ya、 S0.10526315789473684yb数回 S0.02631578947368421yeAzure S0.02631578947368421ya  S0.07894736842105263yiCognitive S0.02631578947368421yfSearch S0.02631578947368421yaの S0.02631578947368421yeクラスター S0.02631578947368421yb起動 S0.02631578947368421yaし S0.05263157894736842ybたり S0.02631578947368421yb停止 S0.02631578947368421ycたりし S0.02631578947368421yaて S0.02631578947368421ybまし S0.02631578947368421yaた S0.02631578947368421ya。 S0.02631578947368421ybこれ S0.02631578947368421yaは S0.02631578947368421yiTerraform S0.02631578947368421yaで S0.02631578947368421ybやる S0.02631578947368421yaと S0.02631578947368421ya楽 S0.02631578947368421ybでき S0.02631578947368421>vb57<yb先日 T0.023255813953488372yaは T0.023255813953488372ya「 T0.023255813953488372ydシステム T0.023255813953488372yaの T0.046511627906976744yb特徴 T0.023255813953488372yaと T0.023255813953488372yb検索 T0.023255813953488372yb機能 T0.023255813953488372ydについて T0.023255813953488372ya」 T0.023255813953488372ycという T0.023255813953488372yb感じ T0.046511627906976744yaで S0.06976744186046512ydふんわり T0.023255813953488372yd書きまし T0.023255813953488372yaた T0.046511627906976744ya。 T0.046511627906976744ya  T0.046511627906976744ybまぁ T0.023255813953488372ya、 T0.023255813953488372ya頭 T0.023255813953488372ya中 T0.023255813953488372ydぼんやり T0.023255813953488372yb考え T0.023255813953488372ybてる T0.023255813953488372ybこと T0.023255813953488372yaを T0.023255813953488372yb文章 T0.023255813953488372yaに T0.046511627906976744ybして T0.023255813953488372yaみ T0.023255813953488372yaす T0.023255813953488372ya他 T0.023255813953488372yaも T0.023255813953488372>vb58<yb今年e0.025yaのe0.075ya頭e0.025ybからd0.05ydシステムe0.025yd検索周りe0.025yaをe0.075yb手伝e0.025yaうe0.025yb仕事e0.025yfフリーランスe0.025ycとしてe0.025ybやっe0.025yaてd0.05yaいe0.025ybますe0.025ya。e0.025ya e0.025yb検索e0.025yb仕組e0.025yaみe0.025yb知れe0.025yaばe0.025yb知るe0.025ybほどe0.025yb面白e0.025yaくe0.025ybなっe0.025yaきe0.025yaたe0.025ycというe0.025yb理由e0.025yaにe0.025ybなるe0.025>vb59<yb前回 T0.013888888888888888yaの T0.041666666666666664yb記事 T0.013888888888888888yaは T0.013888888888888888ycこちら T0.013888888888888888ya。 T0.027777777777777776yc自分用 T0.013888888888888888ybメモ T0.013888888888888888yaな T0.013888888888888888yaで T0.013888888888888888ya、 T0.013888888888888888yb読み T0.027777777777777776ydにくいか T0.013888888888888888yaも T0.013888888888888888ybです T0.013888888888888888ya  R0.3194444444444444ydRust S0.06944444444444445ycthe S0.06944444444444445ydBook T0.013888888888888888yaを T0.013888888888888888yb始め T0.013888888888888888yaた T0.013888888888888888ydbook S0.05555555555555555ya- S0.05555555555555555ya第 S0.05555555555555555yb4章 T0.013888888888888888yb5章 T0.013888888888888888yb6章 T0.013888888888888888yb8章 T0.013888888888888888>vb60<yd6月7日 T0.027777777777777776yaの T0.027777777777777776ya週 T0.027777777777777776yaに S0.05555555555555555yb開催 S0.05555555555555555yaさ S0.05555555555555555yaれ S0.05555555555555555yaた S0.05555555555555555yfBerlin S0.05555555555555555ya  R0.1111111111111111yiBuzzwords S0.05555555555555555yeオンライン T0.027777777777777776yb出張 T0.027777777777777776yaし T0.027777777777777776yaて S0.05555555555555555ybまし T0.027777777777777776ya。 T0.027777777777777776yaと T0.027777777777777776yaは T0.027777777777777776ya? T0.027777777777777776ydベルリン T0.027777777777777776yaで T0.027777777777777776ybいる T0.027777777777777776ya、 T0.027777777777777776ycBig T0.027777777777777776>vb61<yjluceneutil S0.05405405405405406ya  S0.10810810810810811ya- S0.02702702702702703yeマニアック S0.02702702702702703yaな S0.08108108108108109ycツール S0.02702702702702703yaの S0.10810810810810811yfセットアップ S0.02702702702702703yb続き S0.02702702702702703yaで S0.05405405405405406yaす S0.02702702702702703ya。 S0.05405405405405406yb今回 S0.02702702702702703yaも S0.02702702702702703yb誰得 S0.02702702702702703ya? S0.02702702702702703ycブログ S0.02702702702702703yb興味 S0.02702702702702703ybない S0.02702702702702703yb場合 S0.02702702702702703yaは S0.02702702702702703yb飛ば S0.02702702702702703yeしましょう S0.02702702702702703yb一応 S0.02702702702702703ya、 S0.02702702702702703ydREAD S0.02702702702702703>vb62<ya0 S0.02702702702702703ya6 S0.02702702702702703ya8 S0.02702702702702703yfLucene S0.05405405405405406yaの S0.08108108108108109ycFST S0.02702702702702703yb修正 S0.02702702702702703yaに S0.02702702702702703yb関連 S0.02702702702702703yaし S0.02702702702702703yaて S0.05405405405405406ya、 S0.02702702702702703yhKuromoji S0.02702702702702703ygパフォーマンス S0.02702702702702703yb問題 S0.05405405405405406yaが S0.02702702702702703ya出 S0.02702702702702703ybいる S0.02702702702702703ybよう S0.02702702702702703yaで S0.05405405405405406yaす S0.02702702702702703ya。 S0.02702702702702703ya  S0.05405405405405406ybこの S0.02702702702702703yb自体 S0.02702702702702703yaは S0.02702702702702703ya. S0.05405405405405406yb以降 S0.02702702702702703yb直る S0.02702702702702703>vb63<yeAzure S0.02702702702702703ya  S0.05405405405405406yiCognitive S0.02702702702702703yfSearch S0.02702702702702703yaで S0.02702702702702703yc日本語 S0.02702702702702703yaを S0.05405405405405406yb扱う S0.02702702702702703ybとき S0.02702702702702703yaに S0.02702702702702703ya、 S0.05405405405405406yf形態素解析器 S0.02702702702702703yb使い S0.02702702702702703ybたい S0.02702702702702703yb場合 S0.02702702702702703yc2種類 S0.02702702702702703yaの S0.05405405405405406yhAnalyzer S0.02702702702702703yaが S0.05405405405405406yb用意 S0.02702702702702703yaさ S0.02702702702702703yaれ S0.02702702702702703yaて S0.02702702702702703yaい S0.02702702702702703ybます S0.02702702702702703ya。 S0.02702702702702703yb今回 S0.02702702702702703yaは S0.02702702702702703ycこれら S0.02702702702702703yb違い S0.02702702702702703ybどん S0.02702702702702703ycなもの S0.02702702702702703>vb64<yb前回 T0.013888888888888888yaの T0.041666666666666664yb記事 T0.013888888888888888yaは T0.013888888888888888ycこちら T0.013888888888888888ya。 T0.027777777777777776yc自分用 T0.013888888888888888ybメモ T0.013888888888888888yaな T0.013888888888888888yaで T0.013888888888888888ya、 T0.013888888888888888yb読み T0.027777777777777776ydにくいか T0.013888888888888888yaも T0.013888888888888888ybです T0.013888888888888888ya  R0.3194444444444444ydRust S0.06944444444444445ycthe S0.06944444444444445ydBook T0.013888888888888888yaを T0.013888888888888888yb始め T0.013888888888888888yaた T0.013888888888888888ydbook S0.05555555555555555ya- S0.05555555555555555ya第 S0.05555555555555555yb4章 T0.013888888888888888yb5章 T0.013888888888888888yb6章 T0.013888888888888888yb8章 T0.013888888888888888>vb65<yb前回 T0.013888888888888888yaの T0.041666666666666664yb記事 T0.013888888888888888yaは T0.013888888888888888ycこちら T0.013888888888888888ya。 T0.027777777777777776yc自分用 T0.013888888888888888ybメモ T0.013888888888888888yaな T0.013888888888888888yaで T0.013888888888888888ya、 T0.013888888888888888yb読み T0.027777777777777776ydにくいか T0.013888888888888888yaも T0.013888888888888888ybです T0.013888888888888888ya  R0.3194444444444444ydRust S0.06944444444444445ycthe S0.06944444444444445ydBook T0.013888888888888888yaを T0.013888888888888888yb始め T0.013888888888888888yaた T0.013888888888888888ydbook S0.05555555555555555ya- S0.05555555555555555ya第 S0.05555555555555555yb4章 T0.013888888888888888yb5章 T0.013888888888888888yb6章 T0.013888888888888888yb8章 T0.013888888888888888>vb66<yb今回g0.03125yaはg0.03125yeAzuref0.0625ya e0.125yiCognitivef0.0625yfSearchf0.0625yaのf0.0625ycSDKg0.03125yaをg0.03125yb利用g0.03125yaしf0.0625yaたg0.03125yhアプリケーションg0.03125yaがg0.03125ya、g0.03125yb実際g0.03125yaにg0.03125ycに対しg0.03125yaてf0.0625yb送信g0.03125ybいるg0.03125yeリクエストg0.03125yeパラメータg0.03125>vb67<yiMircosoft T0.029411764705882353ya  S0.11764705882352941yeBuild T0.029411764705882353ycという T0.029411764705882353ydイベント T0.029411764705882353yaが T0.029411764705882353yb今週 T0.029411764705882353ydありまし T0.029411764705882353yaた T0.058823529411764705ya( T0.058823529411764705ybMS T0.029411764705882353yaの T0.058823529411764705yb方や T0.029411764705882353yaお T0.029411764705882353yc客さん T0.029411764705882353yaに T0.029411764705882353yb教え T0.029411764705882353yaて T0.029411764705882353ycもらっ T0.029411764705882353ya) T0.029411764705882353ya。 T0.029411764705882353ycそこで T0.029411764705882353ya、 T0.029411764705882353yeAzure T0.029411764705882353yiCognitive T0.029411764705882353yfSearch T0.029411764705882353yeセッション T0.029411764705882353yfMyBuil T0.029411764705882353>vb68<ya0 S0.02857142857142857ya1 S0.02857142857142857ya2 S0.02857142857142857ya7 S0.05714285714285714ygElastic S0.05714285714285714yaの S0.05714285714285714yiWorkplace S0.02857142857142857ya  S0.05714285714285714yfSearch S0.02857142857142857yaを S0.02857142857142857yb触っ S0.02857142857142857yaて S0.08571428571428572yaみ S0.02857142857142857ycいます S0.02857142857142857ya( S0.02857142857142857ybその S0.05714285714285714ya、 S0.05714285714285714ya) S0.02857142857142857yaが S0.05714285714285714yeStack S0.02857142857142857ya. S0.05714285714285714ydリリース S0.02857142857142857yaさ S0.02857142857142857yaれ S0.02857142857142857yaし S0.02857142857142857>vb69<yb前回 T0.013888888888888888yaの T0.041666666666666664yb記事 T0.013888888888888888yaは T0.013888888888888888ycこちら T0.013888888888888888ya。 T0.027777777777777776yc自分用 T0.013888888888888888ybメモ T0.013888888888888888yaな T0.013888888888888888yaで T0.013888888888888888ya、 T0.013888888888888888yb読み T0.027777777777777776ydにくいか T0.013888888888888888yaも T0.013888888888888888ybです T0.013888888888888888ya  R0.3194444444444444ydRust S0.06944444444444445ycthe S0.06944444444444445ydBook T0.013888888888888888yaを T0.013888888888888888yb始め T0.013888888888888888yaた T0.013888888888888888ydbook S0.05555555555555555ya- S0.05555555555555555ya第 S0.05555555555555555yb4章 T0.013888888888888888yb5章 T0.013888888888888888yb6章 T0.013888888888888888yb8章 T0.013888888888888888>vb70<ydRust T0.023255813953488372yaで S0.06976744186046512yb言語 T0.023255813953488372yb処理 T0.046511627906976744yd100本 T0.023255813953488372ycノック T0.023255813953488372yaの T0.046511627906976744ya第 T0.023255813953488372yb2章 T0.023255813953488372yb残り T0.023255813953488372yaす T0.046511627906976744ya。 S0.06976744186046512ya  S0.06976744186046512yb前回 T0.023255813953488372yaは S0.06976744186046512ycこちら T0.023255813953488372yaち T0.023255813953488372ybなみ T0.023255813953488372yaに T0.046511627906976744ya、 T0.023255813953488372yd標準入力 T0.023255813953488372ybから T0.023255813953488372yb受け T0.023255813953488372yb取る T0.023255813953488372yb書い T0.023255813953488372yaて T0.046511627906976744ybない T0.023255813953488372yb出力 T0.023255813953488372yb関し T0.023255813953488372ydファイル T0.023255813953488372>vb71<ya1 S0.02564102564102564yc気づい S0.02564102564102564ybたら S0.02564102564102564ydヶ月サボ S0.02564102564102564yaっ S0.02564102564102564yaて S0.02564102564102564ybまし S0.02564102564102564yaた S0.05128205128205128ya、 S0.02564102564102564ycごめん S0.02564102564102564ycなさい S0.02564102564102564ya。 R0.1282051282051282ya  S0.07692307692307693ydRust S0.02564102564102564yaで S0.02564102564102564yb言語 S0.02564102564102564yb処理 S0.02564102564102564yd100本 S0.02564102564102564ycノック S0.02564102564102564yaの S0.05128205128205128ya第 S0.02564102564102564yb2章 S0.02564102564102564yaを S0.02564102564102564yaは S0.05128205128205128ydじめまし S0.02564102564102564yb前回 S0.02564102564102564ycこちら S0.02564102564102564yc確認用 S0.02564102564102564ydUnix S0.02564102564102564ybコマ S0.02564102564102564>vb72<ydRust T0.017857142857142856yaで T0.017857142857142856yb言語 T0.017857142857142856yb処理 T0.017857142857142856yd100本 T0.017857142857142856ycノック T0.017857142857142856yaの S0.05357142857142857yhリファクタリング T0.017857142857142856yb続き T0.017857142857142856ya。 S0.08928571428571429ya  S0.16071428571428573yb前回 T0.017857142857142856yaは T0.017857142857142856ycこちら T0.017857142857142856ycとっく T0.017857142857142856yaに S0.03571428571428571yc終わっ T0.017857142857142856yaて S0.03571428571428571yaた S0.03571428571428571ya、 T0.017857142857142856yeブログ書い T0.017857142857142856ycなかっ T0.017857142857142856yb08 T0.017857142857142856ya. T0.017857142857142856yc暗号文 T0.017857142857142856ycpub T0.017857142857142856ybfn T0.017857142857142856yfcipher T0.017857142857142856ya( T0.017857142857142856ydtext T0.017857142857142856ya: T0.017857142857142856ya& T0.017857142857142856ycamp T0.017857142857142856ya; S0.03571428571428571ycstr T0.017857142857142856ya) T0.017857142857142856yb-& T0.017857142857142856ybgt T0.017857142857142856>vb73<ya5 S0.03225806451612903yd2020 S0.03225806451612903yb前回 S0.03225806451612903yaは S0.06451612903225806yiWorkplace S0.03225806451612903ya  S0.03225806451612903yfSearch S0.03225806451612903yaの S0.03225806451612903yb概要 S0.03225806451612903ydについて S0.06451612903225806yd書きまし S0.03225806451612903yaた S0.03225806451612903yaが S0.03225806451612903ya、 S0.06451612903225806yb今回 S0.03225806451612903yfインストール S0.03225806451612903yaと S0.03225806451612903yb構成 S0.03225806451612903yb要素 S0.03225806451612903yb説明 S0.03225806451612903yaし S0.03225806451612903ybます S0.03225806451612903ya。 S0.03225806451612903ybなお S0.03225806451612903ya/ S0.06451612903225806yc7時点 S0.03225806451612903yaで S0.03225806451612903>vb74<yb2月 T0.037037037037037035yaの S0.07407407407407407ygElastic T0.037037037037037035ya社 T0.037037037037037035ycブログ T0.037037037037037035yaで T0.037037037037037035yaす T0.037037037037037035yaが T0.037037037037037035ya、 T0.037037037037037035yjEnterprise T0.037037037037037035ya  S0.07407407407407407yfSearch S0.07407407407407407yaと T0.037037037037037035ybこれ T0.037037037037037035ybまで T0.037037037037037035yb呼ん T0.037037037037037035ybでい T0.037037037037037035yaた T0.037037037037037035yb製品 T0.037037037037037035yaを T0.037037037037037035yiWorkplace T0.037037037037037035ycという T0.037037037037037035yc製品名 T0.037037037037037035yaに T0.037037037037037035>vb75<yb先日 T0.030303030303030304ya、 S0.06060606060606061ymElasticsearch T0.030303030303030304yaで T0.030303030303030304yaの S0.12121212121212122ydカスタム T0.030303030303030304yb辞書 S0.09090909090909091yb利用 T0.030303030303030304yb方法 S0.06060606060606061ydについて S0.06060606060606061ycブログ T0.030303030303030304yaを T0.030303030303030304yd書きまし T0.030303030303030304yaた S0.06060606060606061ya。 T0.030303030303030304ya  T0.030303030303030304yb設定 T0.030303030303030304yb記載 T0.030303030303030304yaし T0.030303030303030304ybまし T0.030303030303030304yaが T0.030303030303030304yb今回 T0.030303030303030304yaは T0.030303030303030304yb更新 T0.030303030303030304>vb76<ymElasticsearchd0.08yaでd0.04yc日本語d0.04yaをd0.08yb扱うd0.04ybときd0.04yaにd0.04ya、d0.04ydカスタムd0.04yb辞書d0.04yb使いd0.04ybたいd0.04ycというd0.04yb要望d0.04yaがd0.04ybよくd0.04ydありますd0.04ya。d0.04ya d0.08ycAWSd0.04yaのd0.04yeServid0.04>vb77<yb前回 T0.014705882352941176yaの S0.04411764705882353yb記事 T0.014705882352941176yaは T0.029411764705882353ycこちら T0.014705882352941176ya。 T0.029411764705882353yc自分用 T0.014705882352941176ybメモ T0.014705882352941176yaな T0.014705882352941176yaで T0.014705882352941176ya、 T0.014705882352941176yb読み T0.029411764705882353ydにくいか T0.014705882352941176yaも T0.014705882352941176ybです T0.014705882352941176ya  S0.29411764705882354ydRust T0.058823529411764705ycthe T0.058823529411764705ydBook T0.014705882352941176yaを T0.014705882352941176yb始め T0.014705882352941176yaた T0.014705882352941176ydbook S0.04411764705882353ya- S0.04411764705882353ya第 T0.058823529411764705yb4章 T0.014705882352941176yb5章 T0.014705882352941176yb6章 T0.014705882352941176yb8章 T0.014705882352941176yb7章 T0.014705882352941176yaパ T0.014705882352941176>vb78<ydRuste0.025yaでe0.025yb言語e0.025yb処理e0.025yd100本e0.025ycノックe0.025yaのd0.05yhリファクタリングe0.025yb続きe0.025ya。e0.075ya d0.15yb前回e0.025yaはd0.05ycこちらd0.05ycコードe0.025yaもe0.025yb載せe0.025yaたe0.025ybほうe0.025yaがe0.025yb見やe0.025ycすいかe0.025ybなぁe0.025ya?e0.025yb03e0.025ya.e0.025yc円周率e0.025yb2年e0.025ya前e0.025ydどちらかe0.025>vb79<yb今回g0.03125yaもg0.03125ydツイートg0.03125ybからg0.03125ya。f0.0625ya g0.03125yd言語処理g0.03125yd100本g0.03125ycノックg0.03125yaのg0.09375ye2020年g0.03125ya版g0.03125yaをf0.0625yb公開g0.03125yaしf0.0625ybましg0.03125yaたg0.03125yb最近g0.03125yf自然言語処理g0.03125yb研究g0.03125yb動向g0.03125yb反映g0.03125ya、g0.03125yb深層g0.03125ykニューラルネットワークg0.03125yaにg0.03125ya関g0.03125>vb80<yb前回 T0.017241379310344827yaの S0.05172413793103448yb記事 T0.017241379310344827yaは T0.017241379310344827ycこちら T0.017241379310344827ya。 S0.05172413793103448yc自分用 T0.017241379310344827ybメモ T0.017241379310344827yaな T0.017241379310344827yaで T0.017241379310344827ya、 T0.017241379310344827yb読み T0.034482758620689655ydにくいか T0.017241379310344827yaも T0.017241379310344827ybです T0.034482758620689655ya  S0.25862068965517243ydRust S0.05172413793103448ycthe S0.05172413793103448ydBook T0.017241379310344827yaを T0.017241379310344827yb始め T0.017241379310344827yaた T0.017241379310344827ydbook T0.034482758620689655ya- T0.034482758620689655ya第 S0.05172413793103448yb4章 T0.017241379310344827yb5章 T0.017241379310344827yb6章 T0.017241379310344827ydEnum T0.017241379310344827ydmatc T0.017241379310344827>vb81<yhKuromoji S0.06896551724137931ya- T0.034482758620689655ycCLI S0.06896551724137931yaの S0.10344827586206896yb使い T0.034482758620689655ya方 T0.034482758620689655ybなど T0.034482758620689655ydについて T0.034482758620689655yaは T0.034482758620689655yb過去 T0.034482758620689655ycブログ T0.034482758620689655yaを T0.034482758620689655yb御覧 T0.034482758620689655yaく T0.034482758620689655yaだ T0.034482758620689655ybさい T0.034482758620689655ya。 T0.034482758620689655ya  S0.06896551724137931ydコマンド T0.034482758620689655yaと S0.06896551724137931ygpicocli T0.034482758620689655ygGraalVM T0.034482758620689655yaG T0.034482758620689655>vb82<yb前回 T0.018867924528301886yaの S0.05660377358490566yb記事 T0.018867924528301886yaは T0.018867924528301886ycこちら T0.018867924528301886ya。 S0.05660377358490566yc自分用 T0.018867924528301886ybメモ T0.018867924528301886yaな T0.018867924528301886yaで S0.03773584905660377ya、 T0.018867924528301886yb読み S0.03773584905660377ydにくいか T0.018867924528301886yaも T0.018867924528301886ybです T0.018867924528301886ya  S0.18867924528301888ydRust S0.03773584905660377ycthe S0.03773584905660377ydBook T0.018867924528301886yaを T0.018867924528301886yb始め T0.018867924528301886yaた T0.018867924528301886ydbook T0.018867924528301886ya- T0.018867924528301886ya第 S0.03773584905660377yb4章 T0.018867924528301886yb5章 T0.018867924528301886yc構造体 T0.018867924528301886yaす T0.018867924528301886yd勝手知っ T0.018867924528301886ybたる T0.018867924528301886ybなん T0.018867924528301886yaと T0.018867924528301886ybやら T0.018867924528301886ya? T0.018867924528301886>vb83<yeすもけさんe0.025yaがe0.025yf在宅勤務環境e0.025yaをe0.025ycブログe0.025yaにe0.025yb書いd0.05yaてe0.075ydおもしろe0.025ybそうe0.025yaだe0.025yaなd0.05ya(e0.025ybあとe0.025ya、e0.025yfアフィリンクe0.025ya貼e0.025ybれるe0.025ya)e0.025yaとe0.025yb思っe0.025yaたe0.025yaのd0.05yaでe0.025yb自分e0.025yb環境e0.025yaもe0.025yaみe0.025ybようe0.025yaかe0.025ybなとe0.025ya。e0.025ya e0.025yc私自身e0.025yaはe0.025>vb84<yb前回 T0.020833333333333332yaのf0.0625yb記事 T0.020833333333333332yaは T0.020833333333333332ycこちら T0.020833333333333332ya。f0.0625yc自分用 T0.020833333333333332ybメモ T0.020833333333333332yaな T0.041666666666666664yaで T0.041666666666666664ya、 T0.041666666666666664yb読み T0.041666666666666664ydにくいか T0.020833333333333332yaも T0.020833333333333332ybです T0.020833333333333332ya  S0.10416666666666667ydRust T0.020833333333333332ycthe T0.020833333333333332ydBook T0.020833333333333332yaを T0.020833333333333332yb始め T0.020833333333333332yaた T0.020833333333333332ya第 T0.041666666666666664yb4章 T0.041666666666666664yaす T0.020833333333333332ycたぶん T0.020833333333333332ybこれ T0.020833333333333332yaが T0.020833333333333332ydいちばん T0.020833333333333332yb大事 T0.020833333333333332yb概念 T0.020833333333333332yaだ T0.020833333333333332yaと T0.020833333333333332ya思 T0.020833333333333332>vb85<yb先日 S0.02702702702702703ya、 S0.02702702702702703yfVisual S0.02702702702702703ya  S0.16216216216216217yfStudio S0.02702702702702703ydCode S0.02702702702702703yaの S0.02702702702702703yeプラグイン S0.05405405405405406yaを S0.08108108108108109yb作っ S0.05405405405405406yaて S0.05405405405405406yaみ S0.02702702702702703yaた S0.08108108108108109ya( S0.02702702702702703yeAzure S0.02702702702702703yfSearch S0.02702702702702703ygAnalyze S0.02702702702702703yfClient S0.02702702702702703ya) S0.02702702702702703ycという S0.02702702702702703ycブログ S0.02702702702702703yd書きまし S0.02702702702702703ya。 S0.02702702702702703ybこの S0.02702702702702703ydタイミン S0.02702702702702703>vb86<yd自転車本 S0.02127659574468085yaを R0.0851063829787234yb読み S0.02127659574468085yd始めまし S0.02127659574468085yaた R0.0425531914893617yaが R0.0425531914893617ya、 R0.0425531914893617ybその S0.02127659574468085ya前 S0.02127659574468085yaに R0.0425531914893617ydRust R0.0425531914893617ya  R0.0851063829787234ycthe R0.0425531914893617ydbook R0.0425531914893617yb読ん S0.02127659574468085yaだ S0.02127659574468085ybほう S0.02127659574468085yc良いか S0.02127659574468085yaも S0.02127659574468085ya? S0.02127659574468085yaと R0.0425531914893617yb知り S0.02127659574468085yb合い S0.02127659574468085ya話 S0.02127659574468085yaし S0.02127659574468085yaて R0.0425531914893617yaい S0.02127659574468085ybなっ S0.02127659574468085yaの S0.02127659574468085yaで S0.02127659574468085ya先 S0.02127659574468085ya読 S0.02127659574468085>vb87<yb動機 T0.024390243902439025ya  R0.0975609756097561yeAzure T0.024390243902439025yiCognitive T0.024390243902439025yfSearch T0.024390243902439025yaを S0.07317073170731707yb検索 S0.04878048780487805ydエンジン T0.024390243902439025yaに T0.024390243902439025yb使っ T0.024390243902439025yaて S0.07317073170731707ybいる T0.024390243902439025yaお T0.024390243902439025yc客さん T0.024390243902439025yc手伝っ T0.024390243902439025ycいます T0.024390243902439025ya。 T0.024390243902439025ycそこで T0.024390243902439025ya、 T0.024390243902439025yaの T0.024390243902439025yb基本 T0.024390243902439025ya的 T0.024390243902439025yaな T0.024390243902439025ya話 T0.024390243902439025ybさせ T0.024390243902439025yaい T0.024390243902439025yaた S0.04878048780487805ydだきまし T0.024390243902439025ya( T0.024390243902439025ydもともと T0.024390243902439025ydJJUG T0.024390243902439025ybナイ T0.024390243902439025>vb88<ybこれ S0.02564102564102564ybまで S0.02564102564102564ya  R0.1282051282051282yb実践 S0.07692307692307693ydRust S0.05128205128205128yb入門 S0.05128205128205128yaは S0.02564102564102564ydじめまし S0.02564102564102564yaた S0.05128205128205128yaの S0.05128205128205128yb3章 S0.07692307692307693yaを S0.02564102564102564yb読ん S0.02564102564102564ybでる S0.02564102564102564yaと S0.02564102564102564ybころ S0.02564102564102564yb終了 S0.02564102564102564ye終わりまで S0.02564102564102564yb読み S0.02564102564102564yb終え S0.02564102564102564ya。 S0.02564102564102564ydいきなり S0.02564102564102564ya的 S0.02564102564102564yaな S0.02564102564102564yeプログラム S0.02564102564102564yaで S0.02564102564102564ya少 S0.02564102564102564>vb89<yhKuromoji S0.03571428571428571ya- S0.03571428571428571ycCLI S0.03571428571428571ya  S0.03571428571428571ydRust S0.03571428571428571yc初心者 S0.03571428571428571yaが S0.07142857142857142yeRust製 S0.07142857142857142yaの S0.10714285714285714yi日本語形態素解析器 S0.03571428571428571yb開発 S0.03571428571428571yaを S0.03571428571428571yb引き S0.03571428571428571yb継い S0.03571428571428571ybでみ S0.03571428571428571yaた S0.03571428571428571ycという S0.07142857142857142yb記事 S0.03571428571428571yaに S0.03571428571428571ydあります S0.03571428571428571ya、 S0.03571428571428571ygLindera S0.03571428571428571yg日本語形態素解 S0.03571428571428571>vb90<ybこれ T0.023255813953488372ybまで T0.023255813953488372yaの S0.09302325581395349yaは T0.046511627906976744ycこちら T0.023255813953488372ya。 S0.06976744186046512yb読書 T0.023255813953488372ybメモ T0.023255813953488372yaな T0.023255813953488372yaで S0.06976744186046512ya、 T0.023255813953488372ya本 T0.023255813953488372yaと T0.023255813953488372yd合わせて T0.023255813953488372yb読ん T0.046511627906976744ybでい T0.023255813953488372yaた T0.046511627906976744ybだく T0.023255813953488372yaが T0.023255813953488372yb良い T0.023255813953488372yaす T0.023255813953488372ya  S0.06976744186046512yb実践 T0.023255813953488372ydRust T0.023255813953488372yb入門 T0.023255813953488372ydじめまし T0.023255813953488372yb3章 T0.023255813953488372ygクイックツアー T0.023255813953488372yaを T0.023255813953488372ybます T0.023255813953488372yaバ T0.023255813953488372>vb91<yb49 S0.02040816326530612ybもう S0.02040816326530612ye2020年 S0.02040816326530612yb2月 S0.02040816326530612yaに T0.061224489795918366ybなっ S0.02040816326530612yaて T0.061224489795918366ycしまっ S0.02040816326530612ybます S0.02040816326530612yaが S0.02040816326530612ya、 S0.02040816326530612ye2019年 S0.02040816326530612yb買っ S0.02040816326530612yb便利 S0.02040816326530612ybだっ S0.02040816326530612yaた S0.04081632653061224ybもの S0.04081632653061224yc良かっ S0.02040816326530612yaを S0.02040816326530612ydいくつか S0.02040816326530612yb記録 S0.02040816326530612yb残し S0.02040816326530612yaと S0.02040816326530612ybこう S0.02040816326530612yaか S0.02040816326530612ybなと S0.02040816326530612ya。 S0.02040816326530612ya  S0.14285714285714285yfBRAVIA S0.02040816326530612ybKJ S0.02040816326530612ya- S0.02040816326530612yc55X S0.02040816326530612ye9500G S0.02040816326530612yfAmazon S0.02040816326530612ya| S0.02040816326530612ycソニー S0.02040816326530612ydSONY S0.02040816326530612>vb92<ya1 T0.029411764705882353ya2 T0.029411764705882353ya3 T0.029411764705882353ya4 T0.029411764705882353ya5 T0.029411764705882353ygブログ移行日記 S0.14705882352941177ya( S0.14705882352941177ybその S0.14705882352941177ya) S0.11764705882352941ybです T0.029411764705882353ya。 T0.029411764705882353yb前回 T0.029411764705882353ybまで T0.029411764705882353yaは T0.029411764705882353ycこちら T0.029411764705882353ya  S0.11764705882352941>vb93<yaお S0.04878048780487805yc手伝い T0.024390243902439025yaし S0.04878048780487805yaて S0.07317073170731707ybいる T0.024390243902439025yc客さん T0.024390243902439025yaが T0.024390243902439025yeAzure S0.04878048780487805ya  S0.14634146341463414yiCognitive S0.04878048780487805yfSearch S0.04878048780487805yaを S0.04878048780487805yb利用 T0.024390243902439025ybます T0.024390243902439025ya。 T0.024390243902439025yd検索周り T0.024390243902439025ya= T0.024390243902439025yaに T0.024390243902439025yc関する T0.024390243902439025yb手伝 T0.024390243902439025yaい T0.024390243902439025ybする T0.024390243902439025ya形 T0.024390243902439025yaで T0.024390243902439025yb入っ T0.024390243902439025ybおり T0.024390243902439025ya、 T0.024390243902439025ybいく T0.024390243902439025>vb94<ybまたe0.025ya、e0.075ydツイートd0.05ybからe0.025yc始まるe0.025yaおe0.025ya話e0.025yaでd0.05yaすe0.025ya。d0.05ya d0.05ydまだまだe0.025yb検索e0.025ydシステムe0.025yaっe0.025yaてd0.05ybどんe0.025ydなものかe0.025yaをd0.05yb勉強e0.025yaしd0.05ycたいしe0.025ycというe0.025ybことe0.025ybこんe0.025yaなe0.025yaのe0.025ybましe0.025yaたe0.025ya「e0.025yd検索シスe0.025>vb95<yb年末 S0.02564102564102564ya、 S0.02564102564102564yc何種類 S0.02564102564102564yaか S0.02564102564102564yaの S0.07692307692307693yfボードゲーム S0.05128205128205128yaを S0.07692307692307693yb家族 S0.07692307692307693yaで S0.05128205128205128ye楽しみまし S0.02564102564102564yaた S0.02564102564102564ya。 S0.05128205128205128ya  S0.05128205128205128yb感想 S0.02564102564102564yb交え S0.02564102564102564yaて S0.02564102564102564yb簡単 S0.02564102564102564yaに S0.02564102564102564yb紹介 S0.02564102564102564yaし S0.02564102564102564ycようか S0.02564102564102564yaと S0.02564102564102564yd思います S0.02564102564102564yaや S0.02564102564102564yb知人 S0.02564102564102564yb購入 S0.02564102564102564ybする S0.02564102564102564ybとき S0.02564102564102564ya参 S0.02564102564102564>vb96<yb実践 T0.043478260869565216ydRust T0.043478260869565216yb入門 T0.043478260869565216ycという T0.021739130434782608ya本 T0.021739130434782608yaを T0.043478260869565216yb買っ T0.021739130434782608yaて T0.043478260869565216yaい T0.021739130434782608yaた T0.043478260869565216ya( T0.021739130434782608yb去年 T0.021739130434782608yaの S0.06521739130434782yb7月 T0.021739130434782608yaだ T0.021739130434782608ya。 S0.08695652173913043ya) T0.021739130434782608ybです T0.021739130434782608yaが T0.021739130434782608ya、 T0.043478260869565216yb積ん T0.021739130434782608yaで T0.043478260869565216ybあっ T0.021739130434782608yb時間 T0.021739130434782608yb作っ T0.021739130434782608yb読み T0.021739130434782608yb始め T0.021739130434782608ybよう T0.021739130434782608yaか T0.021739130434782608yaと T0.021739130434782608ya  T0.021739130434782608ya[ T0.021739130434782608yc言語仕 T0.021739130434782608>vb97<yc12月 S0.02564102564102564yaに S0.02564102564102564yb退職 S0.02564102564102564ycします S0.02564102564102564ycブログ S0.02564102564102564yaを S0.07692307692307693yd書きまし S0.02564102564102564yaた S0.07692307692307693yaが S0.02564102564102564ya、 S0.05128205128205128yeその後どう S0.02564102564102564ybなっ S0.02564102564102564ybのか S0.02564102564102564ya? S0.02564102564102564ycという S0.02564102564102564ya話 S0.02564102564102564ybして S0.02564102564102564ybない S0.02564102564102564yaな S0.02564102564102564yaと S0.05128205128205128yb思っ S0.02564102564102564yaの S0.05128205128205128yaで S0.02564102564102564yd一応現在 S0.02564102564102564yb状況 S0.02564102564102564yb書き S0.02564102564102564yb留め S0.02564102564102564yaて S0.02564102564102564yeおこううか S0.02564102564102564ya。 S0.02564102564102564ya  S0.02564102564102564yb結論 S0.02564102564102564>vb98<ya1 S0.02857142857142857ya2 S0.02857142857142857ya3 S0.02857142857142857ya4 S0.02857142857142857ygブログ移行日記 S0.14285714285714285ya( S0.14285714285714285ybその S0.14285714285714285ya) S0.11428571428571428ybです S0.02857142857142857ya。 S0.05714285714285714ya他 S0.02857142857142857yaの S0.02857142857142857yb記事 S0.02857142857142857yaは S0.02857142857142857ycこちら S0.02857142857142857ya  S0.11428571428571428>vb99<ya1 S0.02857142857142857ya2 S0.02857142857142857ya3 S0.02857142857142857ya4 S0.02857142857142857ygブログ移行日記 S0.14285714285714285ya( S0.14285714285714285ybその S0.14285714285714285ya) S0.11428571428571428ybです S0.02857142857142857ya。 S0.05714285714285714ya他 S0.02857142857142857yaの S0.02857142857142857yb記事 S0.02857142857142857yaは S0.02857142857142857ycこちら S0.02857142857142857ya  S0.11428571428571428>vc100<ya1 T0.027777777777777776ya2 T0.027777777777777776ya3 T0.027777777777777776ya4 T0.027777777777777776ya5 T0.027777777777777776ybその S0.16666666666666666ya他 T0.027777777777777776yaの T0.027777777777777776yb記事 T0.027777777777777776yaは T0.027777777777777776ycこちら T0.027777777777777776ya  R0.1388888888888889ygブログ移行日記 R0.1388888888888889ya( R0.1388888888888889ya) R0.1388888888888889>vc101<ya2 T0.027777777777777776ya3 T0.027777777777777776ya4 T0.027777777777777776ya5 T0.027777777777777776ybその R0.1388888888888889ya他 T0.027777777777777776yaの T0.027777777777777776yb記事 T0.027777777777777776yaは T0.027777777777777776ycこちら T0.027777777777777776ya  S0.16666666666666666ygブログ移行日記 R0.1111111111111111ya( R0.1111111111111111ya) R0.1111111111111111yb起因 T0.027777777777777776ydいつもの T0.027777777777777776ydツイート T0.027777777777777776ybから T0.027777777777777776>vc102<yb5年 S0.02702702702702703ycくらい S0.02702702702702703ya、 S0.10810810810810811yiOctopress S0.02702702702702703yaを S0.02702702702702703yb使用 S0.02702702702702703yaし S0.02702702702702703yaて S0.05405405405405406ycいまし S0.02702702702702703yaた S0.02702702702702703yaが S0.05405405405405406yb更新 S0.02702702702702703yaさ S0.02702702702702703yaれ S0.02702702702702703ybなく S0.02702702702702703ybなっ S0.02702702702702703ybいる S0.02702702702702703yaの S0.08108108108108109yaと S0.02702702702702703yeコンテンツ S0.02702702702702703yb生成 S0.02702702702702703yaに S0.02702702702702703yb時間 S0.02702702702702703ycかかる S0.02702702702702703ybこと S0.02702702702702703yaも S0.02702702702702703ybあり S0.02702702702702703ya  S0.02702702702702703ybほか S0.02702702702702703yfプラットフォ S0.02702702702702703>vc103<yb今年 T0.023255813953488372yaも T0.023255813953488372yb振り T0.046511627906976744yb返り T0.046511627906976744yeブログ書い T0.023255813953488372yaて T0.023255813953488372ybます T0.023255813953488372ya。 S0.11627906976744186yfSasuke T0.023255813953488372ycがつい T0.023255813953488372ybてる T0.023255813953488372ya  S0.11627906976744186ya（ T0.023255813953488372ye2018年 T0.023255813953488372yaに T0.046511627906976744yb書い T0.023255813953488372yaた T0.046511627906976744yb抱負 T0.046511627906976744ybから T0.023255813953488372ya） T0.023255813953488372ybまず T0.023255813953488372yaは T0.023255813953488372yb去年 T0.023255813953488372yaの T0.023255813953488372yaを T0.023255813953488372ya元 T0.023255813953488372yeTOEIC T0.023255813953488372yd受けまし T0.023255813953488372yaお T0.023255813953488372ybTO T0.023255813953488372>vc104<ybこの S0.02564102564102564ycブログ S0.02564102564102564ya書 S0.02564102564102564ybこう S0.02564102564102564yaと S0.02564102564102564yb思っ S0.02564102564102564yaて S0.07692307692307693ya、 S0.07692307692307693ybこれ S0.02564102564102564ybまで S0.02564102564102564ycMac S0.02564102564102564yaの S0.05128205128205128yfセットアップ S0.02564102564102564yaし S0.02564102564102564ybたん S0.02564102564102564ybだっ S0.02564102564102564yaた S0.02564102564102564ya。 S0.10256410256410256ya  S0.05128205128205128yb普段 S0.02564102564102564yemacOS S0.02564102564102564yb標準 S0.02564102564102564yeターミナル S0.05128205128205128yaを S0.05128205128205128yb使っ S0.02564102564102564ybます S0.02564102564102564yaで S0.02564102564102564yb使う S0.02564102564102564>vc105<yhドットファイル系 S0.02702702702702703ya（ S0.02702702702702703ya. S0.02702702702702703yeemacs S0.02702702702702703ybとか S0.05405405405405406ya） S0.02702702702702703yaを S0.05405405405405406ybこれ S0.02702702702702703ybまで S0.02702702702702703yaは S0.02702702702702703ya、 S0.08108108108108109ybPC S0.02702702702702703yb引っ S0.02702702702702703yb越す S0.02702702702702703ybたび S0.02702702702702703yaに S0.02702702702702703ycコピー S0.02702702702702703yaし S0.05405405405405406yaて S0.02702702702702703ybたん S0.02702702702702703yaで S0.08108108108108109yaす S0.02702702702702703yaが S0.02702702702702703yeいいかげん S0.02702702702702703yfGitHub S0.02702702702702703yb管理 S0.02702702702702703ybたい S0.02702702702702703ybなと S0.02702702702702703ya。 S0.02702702702702703ya  S0.02702702702702703>vc106<ygMacbook T0.030303030303030304ya  S0.06060606060606061ycPro T0.030303030303030304yaが S0.06060606060606061yc新しく T0.030303030303030304ybなり T0.030303030303030304ya、 S0.06060606060606061ybOS T0.030303030303030304yhCatalina T0.030303030303030304yaに T0.030303030303030304ygなっちゃいまし T0.030303030303030304yaた S0.06060606060606061ya。 T0.030303030303030304ybこれ T0.030303030303030304ybまで T0.030303030303030304yb使っ T0.030303030303030304yaて S0.06060606060606061ya. T0.030303030303030304ydbash T0.030303030303030304ya_ T0.030303030303030304ygprofile T0.030303030303030304yaを S0.06060606060606061ycコピー T0.030303030303030304yaし T0.030303030303030304yeターミナル T0.030303030303030304yb立ち T0.030303030303030304yb上げ T0.030303030303030304>vc107<yb16 T0.022222222222222223yd最近使っ T0.022222222222222223yaて S0.06666666666666667yaい T0.022222222222222223yaた S0.06666666666666667ybPC T0.022222222222222223yaが T0.022222222222222223yb手元 T0.022222222222222223ybから T0.022222222222222223ybなく T0.022222222222222223ybなっ T0.022222222222222223yaの T0.044444444444444446yaで S0.08888888888888889ya、 T0.044444444444444446ycインチ T0.022222222222222223ya  S0.06666666666666667ygMacbook T0.022222222222222223ycPro T0.022222222222222223yaを T0.022222222222222223yfセットアップ T0.022222222222222223yaし T0.022222222222222223ybいる T0.022222222222222223yaと T0.022222222222222223ybころ T0.022222222222222223yaす T0.022222222222222223ya。 T0.022222222222222223yb時間 T0.022222222222222223yaも T0.022222222222222223ybある T0.022222222222222223ybこれ T0.022222222222222223ybまで T0.022222222222222223ybほっ T0.022222222222222223ydたらかし T0.022222222222222223yaき T0.022222222222222223>vc108<ya5 T0.024390243902439025yb本日 T0.024390243902439025ya、 S0.07317073170731707ygElastic T0.024390243902439025yaで S0.12195121951219512yaの S0.04878048780487805ye最終出社日 T0.024390243902439025yaし T0.024390243902439025yaた T0.024390243902439025ya。 S0.04878048780487805yb実際 T0.024390243902439025yc退職日 T0.024390243902439025yaは T0.024390243902439025ybまだ T0.024390243902439025ya先 T0.024390243902439025yaす S0.07317073170731707yaが S0.04878048780487805yd有休消化 T0.024390243902439025ycという T0.024390243902439025yb感じ T0.024390243902439025ya  T0.024390243902439025yb思い T0.024390243902439025yb返せ T0.024390243902439025yaば T0.024390243902439025ybもう T0.024390243902439025yb5年 T0.024390243902439025yaと T0.024390243902439025ycヶ月も T0.024390243902439025ya前 T0.024390243902439025ydElas T0.024390243902439025>vc109<ya4 S0.02040816326530612yd2019 S0.02040816326530612ybこれ S0.02040816326530612yaは S0.02040816326530612ya、 T0.061224489795918366yd情報検索 S0.02040816326530612ya・ S0.02040816326530612yb検索 S0.02040816326530612ydエンジン S0.02040816326530612ya  S0.14285714285714285yfAdvent S0.02040816326530612yhCalendar S0.02040816326530612yaの S0.08163265306122448yb日目 S0.02040816326530612yb記事 S0.04081632653061224yaで S0.02040816326530612yaす S0.02040816326530612ya。 S0.02040816326530612yc1日目 S0.02040816326530612ybから S0.02040816326530612ya質 S0.02040816326530612yb高い S0.02040816326530612yeエントリー S0.02040816326530612yaが S0.04081632653061224yb続い S0.02040816326530612yaて T0.061224489795918366ycいまし S0.02040816326530612yaた S0.02040816326530612yd一旦休憩 S0.02040816326530612yaし S0.02040816326530612yb頂く S0.02040816326530612yb感じ S0.02040816326530612yaに S0.02040816326530612ybなっ S0.02040816326530612>vc110<ya1 R0.0196078431372549yd2019 R0.0196078431372549ygElastic R0.0196078431372549ya  S0.11764705882352941yestack R0.0196078431372549ya( R0.0196078431372549ymElasticsearch R0.0196078431372549ya) R0.0196078431372549yfAdvent R0.0196078431372549yhCalendar R0.0196078431372549yaの R0.0392156862745098yc1日目 R0.0196078431372549yb記事 R0.0196078431372549yaに R0.0392156862745098ydなります R0.0196078431372549ya。 R0.0392156862745098ybまだ R0.0196078431372549ya、 T0.058823529411764705ybヶ月 R0.0196078431372549yaを R0.0392156862745098yb残し R0.0196078431372549yaて R0.0392156862745098ybます R0.0196078431372549yaが R0.0196078431372549yb簡単 R0.0196078431372549yc今年起 R0.0196078431372549ybこっ R0.0196078431372549yaた R0.0196078431372549ybこと R0.0196078431372549yb振り R0.0196078431372549yb返っ R0.0196078431372549yaみ R0.0196078431372549ybよう R0.0196078431372549yaと R0.0196078431372549yd思います R0.0196078431372549yb毎年 R0.0196078431372549yb恒例 R0.0196078431372549yaで R0.0196078431372549ybすね R0.0196078431372549>vc111<ya1 T0.010416666666666666yb10 T0.010416666666666666yb19 T0.010416666666666666yb21 T0.010416666666666666yb25 T0.010416666666666666yb30 T0.010416666666666666yd2019 T0.010416666666666666yf148121 T0.010416666666666666ygBonfire T0.010416666666666666ya d0.25ydData T0.020833333333333332ya& T0.020833333333333332ycamp T0.020833333333333332ya; T0.020833333333333332ygScience T0.020833333333333332ya# T0.020833333333333332yaに T0.010416666666666666ycブログ T0.010416666666666666ya枠 T0.010416666666666666yaで T0.020833333333333332yb参加 T0.010416666666666666yaし T0.010416666666666666yaて T0.010416666666666666ycきまし T0.010416666666666666yaた T0.010416666666666666ya。 T0.020833333333333332ycという T0.010416666666666666ybこと T0.010416666666666666ya、 T0.010416666666666666ybメモ T0.010416666666666666ybです T0.010416666666666666yb日時 T0.010416666666666666ya:f0.0625ya/f0.0625yb00 T0.010416666666666666ya- T0.020833333333333332yb場所 T0.010416666666666666yeYahoo T0.010416666666666666ya! T0.010416666666666666yeJapan T0.010416666666666666ycサイト T0.010416666666666666yehttps T0.010416666666666666yb:/ T0.010416666666666666ybyj T0.010416666666666666yfmeetup T0.010416666666666666ya. T0.020833333333333332yhconnpass T0.010416666666666666yccom T0.010416666666666666yeevent T0.010416666666666666yfハッシュタグ T0.010416666666666666yiyjbonfire T0.010416666666666666yb概要 T0.010416666666666666yaと T0.010416666666666666>vc112<ya7 S0.03571428571428571ybこの S0.03571428571428571ya間 S0.03571428571428571yaの S0.07142857142857142y PElasticsearch勉強会 S0.03571428571428571yaで S0.07142857142857142yiAcroquest S0.03571428571428571ya  S0.03571428571428571yjTechnology S0.03571428571428571ya人 S0.03571428571428571ybたち S0.03571428571428571yaが S0.03571428571428571yb技術 S0.03571428571428571yb書展 S0.03571428571428571yb販売 S0.03571428571428571yaさ S0.03571428571428571yaれ S0.03571428571428571yaて S0.07142857142857142yaい S0.03571428571428571yaた S0.07142857142857142yb書籍 S0.03571428571428571yaを S0.03571428571428571yb頂い S0.03571428571428571yeしまいまし S0.03571428571428571>vc113<ygTwitter S0.02702702702702703yaで S0.08108108108108109ya「 S0.02702702702702703yfMeetup S0.02702702702702703ya. S0.02702702702702703yccom S0.02702702702702703yaに S0.05405405405405406yb切り S0.02702702702702703yb替え S0.02702702702702703ycたらー S0.02702702702702703ya」 S0.02702702702702703yaみ S0.02702702702702703ybたい S0.02702702702702703yaな S0.02702702702702703ya話 S0.05405405405405406yaが S0.02702702702702703ybあっ S0.02702702702702703yaた S0.05405405405405406yaの S0.05405405405405406ya、 S0.05405405405405406ya  S0.02702702702702703yc受付用 S0.02702702702702703ycアプリ S0.02702702702702703yaと S0.02702702702702703ycかなく S0.02702702702702703yaて S0.02702702702702703ycという S0.02702702702702703ybなっ S0.02702702702702703yb普段 S0.02702702702702703yfElasti S0.02702702702702703>vc114<y PElasticsearch勉強会 T0.034482758620689655yaや T0.034482758620689655yg検索技術勉強会 T0.034482758620689655ybやっ S0.10344827586206896ybてる S0.10344827586206896yaん S0.06896551724137931ycだけど T0.034482758620689655ya、 S0.06896551724137931yb独学 T0.034482758620689655yaで T0.034482758620689655yc勉強会 T0.034482758620689655ybなー T0.034482758620689655yaと S0.06896551724137931yb思い T0.034482758620689655ybみん T0.034482758620689655yaな T0.034482758620689655yaは T0.034482758620689655ybどう T0.034482758620689655ycだろう T0.034482758620689655ydツイート T0.034482758620689655yaし T0.034482758620689655yaて T0.034482758620689655>vc115<ya2 T0.021739130434782608yb26 T0.021739130434782608ybどー T0.021739130434782608yaも T0.021739130434782608ya、 T0.043478260869565216ygjohtani T0.021739130434782608ybです T0.021739130434782608ya。 T0.043478260869565216ya  S0.10869565217391304yfSearch T0.021739130434782608ykEngineering T0.021739130434782608ydTech T0.021739130434782608ydTalk T0.021739130434782608ycという T0.021739130434782608yc勉強会 T0.043478260869565216yaに T0.021739130434782608yb運営 T0.021739130434782608ycとして T0.021739130434782608yb参加 T0.021739130434782608yaし T0.043478260869565216yaて T0.021739130434782608ya第 T0.043478260869565216yb1回 T0.021739130434782608yaの T0.043478260869565216yaを T0.021739130434782608yb開始 T0.021739130434782608ybまし T0.021739130434782608yaた T0.043478260869565216yb本日 T0.021739130434782608ya（ T0.021739130434782608ya/ T0.021739130434782608ya） T0.021739130434782608yaは T0.021739130434782608yc1回目 T0.021739130434782608ybだっ T0.021739130434782608>vc116<yb今年 T0.022222222222222223yaも T0.022222222222222223yb振り T0.044444444444444446yb返り T0.044444444444444446ycブログ T0.022222222222222223yaを T0.044444444444444446ybかけ T0.022222222222222223yaて T0.022222222222222223ybます T0.022222222222222223ya。 T0.044444444444444446ycよかっ T0.022222222222222223yaた T0.044444444444444446yaw T0.022222222222222223ya  S0.08888888888888889ya（ T0.022222222222222223ye2017年 T0.022222222222222223yaに T0.044444444444444446yb書い T0.022222222222222223yb抱負 T0.044444444444444446ybから T0.022222222222222223ya） T0.022222222222222223ybまず T0.022222222222222223yaは T0.022222222222222223yb去年 T0.022222222222222223yaの T0.044444444444444446ya元 T0.022222222222222223ybもっ T0.022222222222222223yaと T0.022222222222222223yb英語 T0.022222222222222223yb継続 T0.022222222222222223ya＆ T0.022222222222222223yeTOEIC T0.022222222222222223ybまぁ T0.022222222222222223ya、 T0.022222222222222223>vc117<yd2018 T0.020833333333333332ygElastic T0.020833333333333332ya  S0.16666666666666666yestack T0.020833333333333332ya( T0.020833333333333332ymElasticsearch T0.020833333333333332ya) T0.020833333333333332yfAdvent T0.041666666666666664yhCalendar T0.041666666666666664yaのf0.0625yd25日目 T0.020833333333333332yb記事 T0.020833333333333332yaに T0.041666666666666664ydなります T0.020833333333333332ya。 T0.020833333333333332yb今年 T0.020833333333333332yb最後 T0.020833333333333332yaで T0.020833333333333332yaす T0.020833333333333332ya！ T0.041666666666666664yb来年 T0.020833333333333332yaも T0.020833333333333332yb忘れ T0.020833333333333332yaて T0.020833333333333332ybなけ T0.020833333333333332yaれ T0.020833333333333332yaば T0.020833333333333332ybやる T0.020833333333333332yaは T0.041666666666666664yaず T0.020833333333333332yb今日 T0.020833333333333332ya、 T0.020833333333333332ybすで T0.020833333333333332ycalp T0.020833333333333332>vc118<ya1 R0.0196078431372549yd2018 R0.0196078431372549ygElastic R0.0196078431372549ya  S0.13725490196078433yestack R0.0196078431372549ya( R0.0196078431372549ymElasticsearch R0.0196078431372549ya) R0.0196078431372549yfAdvent R0.0196078431372549yhCalendar R0.0196078431372549yaの R0.0392156862745098yc1日目 R0.0196078431372549yb記事 R0.0196078431372549yaに R0.0392156862745098ydなります R0.0196078431372549ya。 R0.0784313725490196ycちょっ R0.0196078431372549yaと R0.0196078431372549yb遅れ R0.0196078431372549yeちゃいまし R0.0196078431372549yaた R0.0392156862745098ybまだ R0.0196078431372549ya、 R0.0392156862745098ybヶ月 R0.0196078431372549yaを R0.0392156862745098yb残し R0.0196078431372549yaて R0.0392156862745098ybます R0.0196078431372549yaが R0.0196078431372549yb簡単 R0.0196078431372549yc今年起 R0.0196078431372549ybこっ R0.0196078431372549ybこと R0.0196078431372549yb振り R0.0196078431372549yb返っ R0.0196078431372549ybみよ R0.0196078431372549>vc119<ya4 T0.022727272727272728ya（ T0.022727272727272728yb転職 T0.045454545454545456ybする T0.045454545454545456yb少し T0.022727272727272728yc前まで T0.022727272727272728yeパスポート T0.022727272727272728ybすら T0.022727272727272728yb持っ T0.022727272727272728yaて S0.06818181818181818ycなかっ T0.022727272727272728yaた T0.022727272727272728yaの S0.09090909090909091yaに S0.06818181818181818ya） T0.022727272727272728ya今 T0.022727272727272728yb会社 T0.022727272727272728yaし T0.022727272727272728ybから T0.022727272727272728ya、 T0.022727272727272728yb半年 T0.022727272727272728yb1度 T0.022727272727272728yb割合 T0.022727272727272728yaで T0.022727272727272728yb海外 T0.022727272727272728yaへ T0.022727272727272728yb出張 T0.022727272727272728yaが T0.022727272727272728yb発生 T0.022727272727272728yb生活 T0.022727272727272728yaを T0.022727272727272728yb送っ T0.022727272727272728ycいます T0.022727272727272728ya。 T0.022727272727272728ya  T0.022727272727272728>vc120<yd毎月開催 S0.02564102564102564yaの S0.10256410256410256yc2回目 S0.02564102564102564yaに S0.02564102564102564ydなります S0.02564102564102564ya。 S0.05128205128205128ya  S0.05128205128205128yb今回 S0.02564102564102564yaは S0.02564102564102564yb日経 S0.02564102564102564ybさん S0.02564102564102564yb会場 S0.02564102564102564yaを S0.05128205128205128yaお S0.02564102564102564yb借り S0.02564102564102564ybして S0.02564102564102564yb開催 S0.02564102564102564yaと S0.02564102564102564ydなりまし S0.02564102564102564yaた S0.02564102564102564yb前回 S0.02564102564102564ybから S0.02564102564102564ya、 S0.02564102564102564yeスピーカー S0.02564102564102564yb募集 S0.02564102564102564ydhttp S0.02564102564102564yb:/ S0.02564102564102564ya/ S0.05128205128205128ycbit S0.02564102564102564ya. S0.02564102564102564ybly S0.02564102564102564ybSp S0.02564102564102564>vc121<ya7 S0.02702702702702703yb25 S0.02702702702702703ya/ S0.02702702702702703yaに S0.05405405405405406ydJJUG S0.02702702702702703ygナイトセミナー S0.02702702702702703yaで S0.08108108108108109ygElastic S0.02702702702702703ya  S0.08108108108108109yeStack S0.02702702702702703yaの S0.13513513513513514yb紹介 S0.05405405405405406yaと S0.02702702702702703ycAPM S0.02702702702702703ydJava S0.02702702702702703yeAgent S0.02702702702702703yaを S0.02702702702702703yaし S0.02702702702702703yaた S0.02702702702702703ya、 S0.02702702702702703yb補足 S0.02702702702702703ycブログ S0.02702702702702703yaす S0.02702702702702703ya。 S0.02702702702702703ya（ S0.02702702702702703yb久々 S0.02702702702702703yb書く S0.02702702702702703>vc122<yc第2回g0.03125ybからg0.03125yb少しg0.03125ya間g0.03125yaがg0.09375yb空いg0.03125yaてg0.03125yeしまいましg0.03125yaたf0.0625ya、g0.03125yhtemplateg0.03125yaでf0.0625yb作成g0.03125yaしg0.03125yeプラグインg0.03125yaのg0.03125yfディレクトリg0.03125yb構成g0.03125yaとg0.03125ydどういうg0.03125yb流れg0.03125ycデータg0.03125ybやりg0.03125yb取りg0.03125yaさg0.03125ybれるg0.03125yaかg0.03125ycについg0.03125>vc123<ya# T0.024390243902439025yhMANABIYA T0.024390243902439025ya  S0.04878048780487805yaの S0.07317073170731707ycブース T0.024390243902439025yaで S0.07317073170731707yeセッション T0.024390243902439025yb時間 T0.024390243902439025yb合間 T0.024390243902439025yaは T0.024390243902439025yaお T0.024390243902439025yc客さん T0.024390243902439025ya少 T0.024390243902439025ybない T0.024390243902439025ya、 S0.04878048780487805ycブログ T0.024390243902439025yaを T0.024390243902439025yb書い T0.024390243902439025yaて T0.024390243902439025yaみ T0.024390243902439025ybたり T0.024390243902439025ya。 T0.024390243902439025ybここ T0.024390243902439025yb数年 T0.024390243902439025yeスポンサー T0.024390243902439025ycとして T0.024390243902439025yb色々 T0.024390243902439025yaな T0.024390243902439025ygカンファレンス T0.024390243902439025yaに T0.024390243902439025yb参加 T0.024390243902439025yaし T0.024390243902439025ybてる T0.024390243902439025yaん T0.024390243902439025yaす T0.024390243902439025>vc124<ydRust T0.020833333333333332yaで S0.08333333333333333yb言語 T0.020833333333333332yb処理 T0.020833333333333332yd100本 T0.020833333333333332ycノック T0.020833333333333332yaの T0.041666666666666664yb続き T0.020833333333333332ya、 T0.041666666666666664yb05 T0.041666666666666664yaと T0.041666666666666664yb06 T0.020833333333333332yaす T0.020833333333333332ya。f0.0625ya  S0.08333333333333333ya. T0.020833333333333332yan T0.041666666666666664ya- T0.041666666666666664ydgram T0.041666666666666664yb問題 T0.020833333333333332yaは T0.020833333333333332ycこちら T0.020833333333333332ybみん T0.020833333333333332yaな T0.020833333333333332yb大好 T0.020833333333333332yaき T0.020833333333333332ybです T0.020833333333333332yb単語 T0.020833333333333332yb文字 T0.020833333333333332yaが T0.020833333333333332ybある T0.020833333333333332ydそれぞれ T0.020833333333333332yb別関 T0.020833333333333332>vc125<ydRust S0.02631578947368421yaで S0.10526315789473684yb言語 S0.02631578947368421yb処理 S0.02631578947368421yd100本 S0.02631578947368421ycノック S0.02631578947368421yaの S0.02631578947368421yb続き S0.02631578947368421ya、 S0.02631578947368421yb03 S0.05263157894736842yaと S0.02631578947368421yb04 S0.02631578947368421yaす S0.02631578947368421ya。 S0.05263157894736842ya  S0.10526315789473684ya. S0.05263157894736842yc円周率 S0.02631578947368421yb問題 S0.02631578947368421yaは S0.02631578947368421ycこちら S0.02631578947368421ye入力文字列 S0.02631578947368421yaを S0.02631578947368421yesplit S0.02631578947368421ya_ S0.02631578947368421yjwhitespace S0.02631578947368421yb() S0.02631578947368421yb分割 S0.02631578947368421yaし S0.02631578947368421yaて S0.02631578947368421>vc126<ya「 T0.024390243902439025ya鉄 T0.024390243902439025yaは S0.04878048780487805yd熱いうち T0.024390243902439025yaに T0.024390243902439025yb打て T0.024390243902439025ya」 T0.024390243902439025ycという T0.024390243902439025ybこと T0.024390243902439025yaで T0.024390243902439025ya、 S0.04878048780487805yd言語処理 T0.024390243902439025yd100本 T0.024390243902439025ycノック T0.024390243902439025yaの S0.07317073170731707ya第 T0.024390243902439025yb1章 T0.024390243902439025yb00 T0.024390243902439025ybから T0.024390243902439025yb02 T0.024390243902439025yaを T0.024390243902439025yb実装 T0.024390243902439025yaし T0.024390243902439025yaて T0.024390243902439025ycみまし T0.024390243902439025yaた T0.024390243902439025ya。 T0.024390243902439025ya  T0.024390243902439025ybさて S0.04878048780487805ybこれ T0.024390243902439025yaが S0.04878048780487805yb効率 T0.024390243902439025ybいい T0.024390243902439025ydかどうか T0.024390243902439025yaお T0.024390243902439025>vc127<ybども T0.020833333333333332ya。 S0.08333333333333333yc新しい T0.020833333333333332ybもの T0.020833333333333332yb始め T0.020833333333333332ybない T0.020833333333333332yaと T0.020833333333333332ya頭 T0.020833333333333332yaが T0.020833333333333332yb退化 T0.020833333333333332ybする T0.020833333333333332ycという T0.020833333333333332ybこと T0.020833333333333332yaで T0.020833333333333332ya、 T0.041666666666666664ycこちら T0.020833333333333332ya（ T0.020833333333333332ya  S0.16666666666666666yehappy T0.020833333333333332ycnew T0.041666666666666664ydyear T0.020833333333333332ycand T0.020833333333333332yhlanguage T0.020833333333333332ya- T0.020833333333333332yikatsyoshi T0.020833333333333332ydのめもみ T0.020833333333333332ybたい T0.020833333333333332ycなもの T0.020833333333333332ya） T0.020833333333333332yaの T0.020833333333333332ycブログ T0.020833333333333332yaに T0.020833333333333332yb触発 T0.020833333333333332yaさ T0.020833333333333332yaれ T0.020833333333333332yaて T0.020833333333333332>vc128<yc第1回 S0.02564102564102564yaで S0.07692307692307693yaは S0.05128205128205128ya、 S0.07692307692307693ygAnalyze S0.02564102564102564ya  S0.05128205128205128ybUI S0.02564102564102564ycという S0.02564102564102564yeプラグイン S0.05128205128205128yaの S0.07692307692307693yb紹介 S0.02564102564102564yaを S0.07692307692307693ycしまし S0.02564102564102564yaた S0.02564102564102564ybごく S0.02564102564102564yb簡単 S0.02564102564102564yaに S0.02564102564102564yaす S0.02564102564102564yaが S0.02564102564102564ya。 S0.02564102564102564ya第 S0.02564102564102564yb2回 S0.02564102564102564yfKibana S0.02564102564102564yb作成 S0.02564102564102564yb方法 S0.02564102564102564ya順 S0.02564102564102564yb追っ S0.02564102564102564yaて S0.02564102564102564>vc129<ydあけまし S0.02564102564102564yaて S0.05128205128205128ybおめ S0.02564102564102564yaで S0.05128205128205128ygとうございます S0.02564102564102564ya。 S0.05128205128205128yb今年 S0.02564102564102564yaは S0.02564102564102564ybサボ S0.02564102564102564yaり S0.02564102564102564ydがちだっ S0.02564102564102564yaた S0.05128205128205128ycブログ S0.02564102564102564yaを S0.02564102564102564ycちょっ S0.02564102564102564ycとずつ S0.02564102564102564yb復活 S0.02564102564102564yaさ S0.02564102564102564yaせ S0.02564102564102564ybよう S0.02564102564102564yaか S0.02564102564102564yaと S0.02564102564102564ya  S0.02564102564102564ycという S0.02564102564102564ybこと S0.02564102564102564ya、 S0.05128205128205128ya第 S0.02564102564102564yb1弾 S0.02564102564102564ycとして S0.02564102564102564yc昨年少 S0.02564102564102564yaし S0.02564102564102564yb作っ S0.02564102564102564yaい S0.02564102564102564yaK S0.02564102564102564>vc130<yb今年 T0.041666666666666664yaはf0.0625yb紅白 T0.020833333333333332yaを T0.041666666666666664yb見な T0.020833333333333332yaが T0.020833333333333332yaら T0.020833333333333332yb書い T0.041666666666666664yaて T0.020833333333333332ybます T0.020833333333333332ya。f0.0625ya  S0.08333333333333333ycいろん T0.020833333333333332yaな T0.020833333333333332yaと T0.020833333333333332ybころ T0.020833333333333332yaに S0.08333333333333333yb出張 T0.020833333333333332yb行っ T0.020833333333333332yaた T0.041666666666666664ybなぁ T0.020833333333333332yb振り T0.020833333333333332yb返り T0.020833333333333332ya（ T0.020833333333333332ye2016年 T0.020833333333333332yb抱負 T0.041666666666666664ybから T0.020833333333333332ya） T0.020833333333333332ybまず T0.020833333333333332yb去年 T0.020833333333333332yaの T0.020833333333333332ya元 T0.020833333333333332ycもちろ T0.020833333333333332>vc131<yd2017 T0.023809523809523808yeMerry T0.023809523809523808ya  S0.21428571428571427yiChristmas T0.023809523809523808ya! T0.023809523809523808ygElastic T0.047619047619047616yeStack T0.023809523809523808yfAdvent T0.023809523809523808yhCalendar T0.023809523809523808yaの S0.07142857142857142yd24日目 T0.023809523809523808yb記事 T0.023809523809523808yaに T0.023809523809523808ydなります T0.023809523809523808ya。 T0.047619047619047616ycちょっ T0.023809523809523808yaと T0.047619047619047616ybです T0.023809523809523808yaが T0.023809523809523808ya、 T0.023809523809523808ye2018年 T0.023809523809523808ydについて T0.023809523809523808yb書い T0.023809523809523808yaて T0.023809523809523808yaみ T0.023809523809523808ycようか T0.023809523809523808yd思います T0.023809523809523808ydイベント T0.023809523809523808ydいくつか T0.023809523809523808>vc132<ya1d0.02yd2017d0.02ygElasticd0.02ya d0.12yestackd0.02ya(d0.02ymElasticsearchd0.02ya)d0.02yfAdventd0.02yhCalendard0.02yaのd0.04yc1日目d0.02yb記事d0.02yaにd0.06ydなりますd0.02ya。d0.04ybまだd0.02ya、d0.04ybヶ月d0.02yaをd0.04yb残しd0.02yaてd0.04ycいますd0.02yaがd0.02yb簡単d0.02yc今年起d0.02ybこっd0.02yaたd0.04ybことd0.02yb振りd0.02yb返っd0.02yaみd0.02ycようかd0.02yaとd0.02yd思いますd0.02yb思っd0.02yb以上d0.02>vc133<yhSwiftype S0.08333333333333333yaで T0.041666666666666664ycサイト S0.08333333333333333yc内検索 S0.08333333333333333ya？ T0.041666666666666664ya  T0.041666666666666664ygプレスリリース T0.041666666666666664ya： T0.041666666666666664ygElastic T0.041666666666666664yaがe0.125ydサービス T0.041666666666666664yc最大手 T0.041666666666666664yaの T0.041666666666666664yaを T0.041666666666666664yb買収 T0.041666666666666664yc出まし T0.041666666666666664yaた T0.041666666666666664ya、 T0.041666666666666664yfSwifty T0.041666666666666664>vc134<yb久々 T0.024390243902439025yaに T0.024390243902439025yb執筆 T0.024390243902439025yaし T0.024390243902439025ybまし T0.024390243902439025yaた T0.024390243902439025ya。 S0.04878048780487805ydといって S0.04878048780487805yaも S0.04878048780487805ya、 S0.07317073170731707yb以前 T0.024390243902439025yaの S0.07317073170731707yb書籍 T0.024390243902439025yc更新版 S0.04878048780487805yaで T0.024390243902439025yaす T0.024390243902439025ya  T0.024390243902439025ybまぁ T0.024390243902439025yc私以外 T0.024390243902439025yb方々 T0.024390243902439025yaは T0.024390243902439025yb結構 T0.024390243902439025ybな量 T0.024390243902439025yaを T0.024390243902439025yb書き T0.024390243902439025yb直し T0.024390243902439025ybor T0.024390243902439025yd新規書き T0.024390243902439025yc起こし T0.024390243902439025yaさ T0.024390243902439025yaれ T0.024390243902439025yaて T0.024390243902439025ybます T0.024390243902439025>vc135<yb久々 S0.02564102564102564yaの S0.02564102564102564ycブログ S0.02564102564102564ya。 S0.05128205128205128ya  S0.07692307692307693y PElasticsearch勉強会 S0.02564102564102564yaを S0.05128205128205128yb主催 S0.02564102564102564yaし S0.05128205128205128yaて S0.07692307692307693ybます S0.02564102564102564yaが S0.02564102564102564ya、 S0.10256410256410256yeプロダクト S0.02564102564102564yb超え S0.02564102564102564yb検索 S0.02564102564102564yaで S0.02564102564102564yb共通 S0.02564102564102564ybある S0.05128205128205128yb課題 S0.02564102564102564yaと S0.05128205128205128yaか S0.05128205128205128yb悩み S0.02564102564102564ybとか S0.02564102564102564ybなぁ S0.02564102564102564ybその S0.02564102564102564>vc136<yb今年 T0.045454545454545456yaは S0.06818181818181818ycRio T0.022727272727272728yaの T0.045454545454545456yfプレイバック T0.022727272727272728ya T0.022727272727272728ya見 T0.022727272727272728ybなが T0.022727272727272728yaら T0.022727272727272728yb書い T0.045454545454545456yaて T0.022727272727272728ybます T0.022727272727272728ya。 T0.045454545454545456ya  S0.06818181818181818ycなんか T0.022727272727272728yb長い T0.022727272727272728yb一年 T0.022727272727272728ybだっ T0.022727272727272728yaた T0.045454545454545456ya気 T0.022727272727272728yaが T0.022727272727272728yb振り T0.022727272727272728yb返り T0.022727272727272728ya（ T0.022727272727272728ye2015年 T0.022727272727272728yaに T0.045454545454545456yb抱負 T0.045454545454545456ybから T0.022727272727272728ya） T0.022727272727272728ybまず T0.022727272727272728yb去年 T0.022727272727272728yaを T0.022727272727272728ya元 T0.022727272727272728>vc137<ya0 T0.015151515151515152ya1 T0.030303030303030304ya2 S0.09090909090909091ya5 T0.015151515151515152ya7 T0.015151515151515152yd2016 T0.015151515151515152yeMerry T0.015151515151515152ya  S0.21212121212121213yiChristmas T0.015151515151515152ya! T0.015151515151515152ygElastic T0.015151515151515152yestack T0.015151515151515152yfAdvent T0.015151515151515152yhCalendar T0.015151515151515152yc最終日 T0.015151515151515152yaの T0.030303030303030304yb記事 T0.015151515151515152yaに T0.030303030303030304ydなります T0.015151515151515152ya。 T0.030303030303030304yb簡単 T0.015151515151515152yb今年 T0.015151515151515152yb変遷 T0.015151515151515152yaを T0.015151515151515152yb振り T0.015151515151515152yb返っ T0.015151515151515152yaて T0.015151515151515152ycみます T0.015151515151515152ymElasticsearch T0.030303030303030304ya. S0.10606060606060606ya( T0.015151515151515152yb2月 T0.015151515151515152ya) T0.015151515151515152ya、 T0.030303030303030304ydリリース T0.015151515151515152yeクエリプロ T0.015151515151515152>vc138<ya0d0.02ya5d0.02ygElasticd0.02ya d0.14yestackd0.02yfAdventd0.02yhCalendard0.02yc1日目d0.02yaのd0.06yb記事d0.02yaにd0.04ydなりますd0.02ya。d0.04ymElasticsearchd0.02ya.d0.02yaがd0.04yd10月末d0.02ydリリースd0.04yaさd0.06yaれd0.06ybましd0.02yaたd0.02ycブログd0.02yeでいくつかd0.02yb紹介d0.04yaてd0.04ybいるd0.02yaでd0.02yaすd0.02ya、d0.02ycそこでd0.02yaはd0.02>vc139<yb久しe0.025ybぶりe0.025yaにe0.025ya、d0.05yb技術e0.025ya的e0.025yaなe0.025yeブログ書いe0.025yaてc0.1ybますe0.025ya。d0.05ya e0.075yfIngeste0.025yiProcessore0.025yaのd0.05yeプラグインe0.025yaをe0.025yb作っe0.025yaみe0.025ybたくe0.025ybなっe0.025yaたd0.05yaでe0.025yb書いd0.05ycみましe0.025ybただe0.025ybみるe0.025ycんじゃe0.025yc3番煎e0.025yaじe0.025>vc140<ycなんか T0.022727272727272728ya、 S0.06818181818181818yb今年 T0.022727272727272728yaは T0.022727272727272728ybよく T0.022727272727272728ya物 T0.022727272727272728yaが T0.045454545454545456yc壊れる T0.022727272727272728yb厄年 T0.022727272727272728yaだ T0.022727272727272728ycからか T0.022727272727272728ybなぁ T0.022727272727272728ya？ T0.022727272727272728ya  S0.06818181818181818ycという T0.022727272727272728ybこと T0.022727272727272728yaで T0.022727272727272728yb記念 T0.022727272727272728yaに T0.045454545454545456ya何 T0.022727272727272728yb壊れ T0.045454545454545456ybたか T0.022727272727272728yaを T0.022727272727272728ycブログ T0.022727272727272728yb残し T0.022727272727272728yaて T0.045454545454545456ycおこう T0.022727272727272728yaか T0.022727272727272728yaと T0.022727272727272728ya。 T0.022727272727272728yc腕時計 T0.022727272727272728ya（ T0.022727272727272728ycないか T0.022727272727272728yaな T0.022727272727272728ya） T0.022727272727272728yd電波腕時 T0.022727272727272728>vc141<yd第16回d0.04y PElasticsearch勉強会d0.04yaをd0.04yb開催d0.04yaしd0.08ybましd0.04yaたd0.12ya。d0.04ya d0.04ydスタッフd0.04yaのd0.08yc皆さんd0.08ya、d0.08yeスピーカーd0.04yd会場提供d0.04yaてd0.04yaいd0.04ybだいd0.04ylリクルートテクノロジーズd0.04>vc142<yd第15回d0.04y PElasticsearch勉強会d0.04yaをd0.04yb開催d0.04yaしd0.08ybましd0.04yaたd0.12ya。d0.04ya d0.04ydスタッフd0.04yaのd0.08yc皆さんd0.08ya、d0.08yeスピーカーd0.04yd会場提供d0.04yaてd0.04yaいd0.04ybだいd0.04ylリクルートテクノロジーズd0.04>vc143<yb久々 T0.043478260869565216yaの S0.10869565217391304ycポスト T0.021739130434782608ya。 S0.10869565217391304ya  T0.043478260869565216yaに T0.043478260869565216ya、 T0.043478260869565216yd技術書読 T0.021739130434782608yaん T0.021739130434782608yaで S0.06521739130434782ybます T0.021739130434782608ya「 T0.021739130434782608yf自然言語処理 T0.021739130434782608yb基本 T0.021739130434782608yaと T0.021739130434782608yb技術 T0.021739130434782608ya」 T0.021739130434782608ycという T0.021739130434782608ya本 T0.021739130434782608yaす T0.021739130434782608yb監修 T0.021739130434782608ya方 T0.021739130434782608ydツイート T0.021739130434782608yaを T0.021739130434782608yb見て T0.021739130434782608ya気 T0.021739130434782608ybなっ T0.021739130434782608yaた T0.043478260869565216yb買っ T0.021739130434782608yaて T0.021739130434782608ycみまし T0.021739130434782608>vc144<ydあけまし T0.037037037037037035yaて T0.037037037037037035ybおめ T0.037037037037037035yaで T0.037037037037037035ygとうございます T0.037037037037037035ya、 S0.07407407407407407ygjohtani T0.037037037037037035ybです T0.037037037037037035ya。 S0.07407407407407407ya  S0.07407407407407407ya第 T0.037037037037037035yc14回 T0.037037037037037035y PElasticsearch勉強会 T0.037037037037037035yaを T0.037037037037037035yb開催 T0.037037037037037035yaし T0.037037037037037035ybまし T0.037037037037037035yaた T0.037037037037037035ydスタッフ T0.037037037037037035yaの S0.07407407407407407yc皆さん T0.037037037037037035yeスピーカー T0.037037037037037035ya皆 T0.037037037037037035>vc145<yb今年 S0.02040816326530612yaは S0.04081632653061224yc紅白見 S0.02040816326530612yaな S0.02040816326530612yaが S0.02040816326530612yaら S0.02040816326530612yb書い S0.04081632653061224yaて S0.02040816326530612ybます S0.02040816326530612ya。 T0.061224489795918366ya  S0.10204081632653061yb早い S0.02040816326530612yb一年 S0.02040816326530612ybだっ S0.02040816326530612yaた S0.04081632653061224ybなぁ S0.02040816326530612yb振り S0.04081632653061224yb返り S0.04081632653061224ya( S0.02040816326530612ye2014年 S0.02040816326530612yaに S0.04081632653061224yb抱負 S0.04081632653061224ybから S0.02040816326530612ya) S0.02040816326530612ybまず S0.02040816326530612yb去年 S0.02040816326530612yaの T0.061224489795918366yaを S0.04081632653061224ya元 S0.02040816326530612yaば S0.02040816326530612yb英語 S0.02040816326530612yb継続 S0.02040816326530612yb海外 S0.02040816326530612>vc146<yd2015 T0.029411764705882353yb今年 T0.058823529411764705yb最後 T0.029411764705882353yaの S0.11764705882352941yfAdvent T0.058823529411764705ya  S0.17647058823529413yhCalendar T0.058823529411764705yaと T0.029411764705882353ydなります T0.029411764705882353ya。 T0.058823529411764705ybこの T0.029411764705882353yb記事 T0.029411764705882353yaは T0.029411764705882353ymElasticsearch T0.029411764705882353yc最終日 T0.029411764705882353ydエントリ T0.029411764705882353yaで T0.029411764705882353yaす T0.029411764705882353yb簡単 T0.029411764705882353yaに T0.029411764705882353yb変遷 T0.029411764705882353yaを T0.029411764705882353>vc147<ybこん T0.023255813953488372ybにち T0.023255813953488372yaは T0.023255813953488372ya、 S0.06976744186046512ya@ T0.023255813953488372ygjohtani T0.023255813953488372ybです T0.023255813953488372ya。 S0.13953488372093023ya  T0.046511627906976744yb早い T0.023255813953488372ybもの T0.023255813953488372yaで S0.06976744186046512yb師走 T0.023255813953488372yaす T0.023255813953488372yb今年 T0.023255813953488372yaも T0.023255813953488372ybあと T0.023255813953488372yb少し T0.023255813953488372yaと T0.023255813953488372ydなりまし T0.023255813953488372yaた T0.023255813953488372ya（ T0.023255813953488372yb今月 T0.023255813953488372yaが T0.046511627906976744yc一番忙 T0.023255813953488372yaし T0.023255813953488372ybかっ T0.023255813953488372yeたりします T0.023255813953488372ya） T0.023255813953488372ycという T0.023255813953488372ybこと T0.023255813953488372yaA T0.023255813953488372>vc148<yd第13回d0.04y PElasticsearch勉強会d0.04yaをd0.04yb開催d0.04yaしd0.08ybましd0.04yaたd0.12ya。d0.04ya d0.04ydスタッフd0.04yaのd0.08yc皆さんd0.08ya、d0.08yeスピーカーd0.04yd会場提供d0.04yaてd0.04yaいd0.04ybだいd0.04ylリクルートテクノロジーズd0.04>vc149<ya0 T0.034482758620689655ya1 T0.017241379310344827ya2 T0.017241379310344827ya※ T0.017241379310344827ybこの T0.017241379310344827yb記事 T0.017241379310344827yaは T0.017241379310344827ya次 T0.017241379310344827yaの T0.017241379310344827ycブログ T0.017241379310344827yaを T0.034482758620689655yb翻訳 T0.017241379310344827yaし T0.017241379310344827yaた T0.017241379310344827ybもの T0.017241379310344827yaに T0.017241379310344827ydなります T0.017241379310344827ya。 T0.017241379310344827ya  R0.1724137931034483yb原文 T0.017241379310344827ya： T0.017241379310344827ycThe T0.017241379310344827yeStory T0.017241379310344827ybof T0.017241379310344827yeSense S0.05172413793103448ya- T0.034482758620689655yjAnnouncing T0.017241379310344827ya. T0.034482758620689655ydbeta T0.017241379310344827yb誕生 T0.017241379310344827ybよく T0.017241379310344827ybある T0.017241379310344827yb良い T0.017241379310344827yfプロジェクト T0.017241379310344827yb同様 T0.017241379310344827ya、 T0.017241379310344827yaも T0.017241379310344827ycビール T0.017241379310344827yb飲み T0.017241379310344827yaな T0.017241379310344827yaが T0.017241379310344827yaら T0.017241379310344827ya考 T0.017241379310344827>vc150<ya0 S0.04081632653061224ya2 S0.02040816326530612yb10 S0.02040816326530612yb28 S0.02040816326530612ya※ S0.02040816326530612ybこの S0.02040816326530612yb記事 S0.02040816326530612yaは S0.02040816326530612ya次 S0.02040816326530612yaの S0.02040816326530612ycブログ S0.02040816326530612yaを S0.02040816326530612yb翻訳 S0.02040816326530612yaし S0.02040816326530612yaた S0.02040816326530612ybもの S0.02040816326530612yaに S0.02040816326530612ydなります S0.02040816326530612ya。 S0.02040816326530612ya  S0.16326530612244897yb原文 S0.02040816326530612ya： S0.02040816326530612yfShield S0.04081632653061224ya, S0.04081632653061224ygWatcher S0.04081632653061224ycand S0.02040816326530612yfMarvel S0.02040816326530612ya. S0.04081632653061224ybGA S0.02040816326530612yhReleased S0.02040816326530612yb本日 S0.02040816326530612ya（ S0.02040816326530612ya/ S0.02040816326530612ya） S0.02040816326530612ya、 S0.02040816326530612ycおよび S0.02040816326530612ydMarv S0.02040816326530612>vc151<ya0 S0.08333333333333333ya1 T0.020833333333333332ya2 T0.041666666666666664yb79 T0.020833333333333332yc477 T0.020833333333333332ya※ T0.020833333333333332ybこの T0.020833333333333332yb記事 T0.020833333333333332yaは T0.020833333333333332ya次 T0.020833333333333332yaのf0.0625ycブログ T0.020833333333333332yaを T0.020833333333333332yb翻訳 T0.020833333333333332yaし T0.020833333333333332yaた T0.020833333333333332ybもの T0.020833333333333332yaに T0.020833333333333332ydなります T0.020833333333333332ya。 T0.020833333333333332ya  S0.14583333333333334yb原文 T0.020833333333333332ya： T0.020833333333333332ymElasticsearch T0.041666666666666664ya. S0.08333333333333333ybGA T0.020833333333333332yhreleased T0.020833333333333332ydリリース T0.020833333333333332yb以降 T0.020833333333333332ya、 T0.020833333333333332yeコミッター T0.020833333333333332ya, T0.020833333333333332>vc152<ya0 T0.047619047619047616ya2 S0.06349206349206349ya4 T0.031746031746031744ya※ T0.015873015873015872ybこの T0.015873015873015872yb記事 T0.015873015873015872yaは T0.015873015873015872ya次 T0.015873015873015872yaの S0.06349206349206349ycブログ T0.015873015873015872yaを T0.015873015873015872yb翻訳 T0.015873015873015872yaし T0.015873015873015872yaた T0.015873015873015872ybもの T0.015873015873015872yaに T0.015873015873015872ydなります T0.015873015873015872ya。 T0.031746031746031744ya  S0.20634920634920634yb原文 T0.015873015873015872ya： T0.015873015873015872yfKibana T0.047619047619047616ya. S0.07936507936507936yhreleased T0.015873015873015872ymElasticsearch T0.031746031746031744ya+ T0.015873015873015872ya= T0.015873015873015872yb💚 T0.015873015873015872ydサポート T0.015873015873015872yb最初 T0.015873015873015872ydリリース T0.015873015873015872yaで T0.015873015873015872yaす T0.015873015873015872ybこれ T0.015873015873015872>vc153<ya0 S0.07692307692307693ya2 T0.038461538461538464yb10 T0.019230769230769232yb28 T0.019230769230769232ya※ T0.019230769230769232ybこの T0.038461538461538464yb記事 T0.019230769230769232yaは T0.038461538461538464ya次 T0.019230769230769232yaの T0.019230769230769232ycブログ T0.019230769230769232yaを T0.019230769230769232yb翻訳 T0.019230769230769232yaし T0.019230769230769232yaた T0.038461538461538464ybもの T0.019230769230769232yaに T0.019230769230769232ydなります T0.019230769230769232ya。 T0.038461538461538464ya  S0.11538461538461539yb原文 T0.019230769230769232ya： T0.019230769230769232yhLogstash T0.038461538461538464ya. S0.07692307692307693yhreleased T0.019230769230769232yaが T0.019230769230769232yb本日 T0.019230769230769232ya（ T0.019230769230769232ya/ T0.019230769230769232ya） T0.019230769230769232ydリリース T0.038461538461538464yaさ T0.019230769230769232yaれ T0.019230769230769232ybまし T0.019230769230769232>vc154<ya※ T0.044444444444444446ybこの T0.022222222222222223yb記事 T0.022222222222222223yaは T0.044444444444444446ya次 T0.022222222222222223yaの T0.022222222222222223ycブログ T0.022222222222222223yaを T0.044444444444444446yb翻訳 T0.022222222222222223yaし T0.022222222222222223yaた T0.022222222222222223ybもの T0.022222222222222223yaに S0.06666666666666667ydなります T0.022222222222222223ya。 T0.044444444444444446ya  R0.1111111111111111yb原文 T0.044444444444444446ya： T0.022222222222222223yfRelase T0.022222222222222223ya, T0.022222222222222223ybwe T0.022222222222222223ydhave T0.022222222222222223yb画像 T0.022222222222222223yb関し T0.022222222222222223yaて T0.022222222222222223yaご T0.022222222222222223yb覧く T0.022222222222222223yaだ T0.022222222222222223ybさい T0.022222222222222223ygElastic T0.022222222222222223ycとって T0.022222222222222223yb大き T0.022222222222222223yaな T0.022222222222222223yb1日 T0.022222222222222223>vc155<ya0 T0.041666666666666664ya1 T0.020833333333333332ya2f0.0625ya5 T0.020833333333333332ya9 T0.020833333333333332yb17 T0.020833333333333332ya※ T0.020833333333333332ybこの T0.020833333333333332yb記事 T0.020833333333333332yaは T0.020833333333333332ya次 T0.020833333333333332yaの T0.041666666666666664ycブログ T0.020833333333333332yaを T0.020833333333333332yb翻訳 T0.020833333333333332yaし T0.020833333333333332yaた T0.020833333333333332ybもの T0.020833333333333332yaに T0.020833333333333332ydなります T0.020833333333333332ya。 T0.020833333333333332ya  S0.10416666666666667yb原文 T0.020833333333333332ya： T0.020833333333333332ymElasticsearch T0.020833333333333332ya. S0.08333333333333333ya- T0.020833333333333332ydbeta T0.020833333333333332yhreleased T0.020833333333333332yb本日 T0.020833333333333332ya（ T0.020833333333333332ya/ T0.020833333333333332ya） T0.020833333333333332ya、 T0.020833333333333332yfLucene T0.020833333333333332ycベース T0.020833333333333332ydElas T0.020833333333333332>vc156<ya0 T0.024390243902439025ya2 T0.024390243902439025ya※ T0.024390243902439025ybこの T0.024390243902439025yb記事 T0.024390243902439025yaは T0.024390243902439025ya次 T0.024390243902439025yaの S0.04878048780487805ycブログ T0.024390243902439025yaを S0.04878048780487805yb翻訳 T0.024390243902439025yaし T0.024390243902439025yaた T0.024390243902439025ybもの T0.024390243902439025yaに T0.024390243902439025ydなります T0.024390243902439025ya。 T0.024390243902439025ya  R0.1951219512195122yb原文 T0.024390243902439025ya： T0.024390243902439025ymElasticsearch S0.04878048780487805yiunplugged T0.024390243902439025ya- T0.024390243902439025yjNetworking T0.024390243902439025ygchanges T0.024390243902439025ybin T0.024390243902439025ya. T0.024390243902439025ydローカル T0.024390243902439025ycマシン T0.024390243902439025yaで T0.024390243902439025ya起 T0.024390243902439025>vc157<ya0 T0.041666666666666664ya1 T0.041666666666666664ya2 T0.041666666666666664ya5 T0.020833333333333332ya8 T0.020833333333333332yb26 T0.020833333333333332ya※ T0.020833333333333332ybこの T0.020833333333333332yb記事 T0.020833333333333332yaは T0.020833333333333332ya次 T0.020833333333333332yaの T0.041666666666666664ycブログ T0.020833333333333332yaを T0.020833333333333332yb翻訳 T0.020833333333333332yaし T0.020833333333333332yaた T0.020833333333333332ybもの T0.020833333333333332yaに T0.020833333333333332ydなります T0.020833333333333332ya。 T0.020833333333333332ya  S0.10416666666666667yb原文 T0.020833333333333332ya： T0.020833333333333332ymElasticsearch T0.020833333333333332ya. S0.08333333333333333ya- T0.020833333333333332ydbeta T0.020833333333333332yhreleased T0.020833333333333332yb本日 T0.020833333333333332ya（ T0.020833333333333332ya/ T0.020833333333333332ya） T0.020833333333333332ya、 T0.020833333333333332yfLucene T0.020833333333333332ycベース T0.020833333333333332ydElas T0.020833333333333332>vc158<ya0 R0.0392156862745098ya1 R0.0196078431372549ya2 R0.0196078431372549ya※ R0.0196078431372549ybこの R0.0196078431372549yb記事 R0.0196078431372549yaは R0.0392156862745098ya次 R0.0196078431372549yaの R0.0392156862745098ycブログ R0.0196078431372549yaを R0.0196078431372549yb翻訳 R0.0196078431372549yaし R0.0196078431372549yaた R0.0196078431372549ybもの R0.0196078431372549yaに R0.0196078431372549ydなります R0.0196078431372549ya。 R0.0196078431372549ya  S0.19607843137254902yb原文 R0.0196078431372549ya： R0.0196078431372549ycThe R0.0196078431372549yfDelete R0.0196078431372549ybby R0.0196078431372549yeQuery R0.0196078431372549ycAPI R0.0196078431372549ybIs R0.0196078431372549ycnow R0.0196078431372549yaa R0.0196078431372549yfplugin R0.0196078431372549ymElasticsearch R0.0196078431372549ya. R0.0392156862745098ya- R0.0196078431372549ydbeta R0.0196078431372549yaで R0.0196078431372549ya、 R0.0196078431372549ybこれ R0.0196078431372549ybまで R0.0196078431372549>vc159<yd第11回d0.04y PElasticsearch勉強会d0.04yaをd0.04yb開催d0.04yaしd0.08ybましd0.04yaたd0.12ya。d0.04ya d0.04ydスタッフd0.04yaのd0.08yc皆さんd0.08ya、d0.08yeスピーカーd0.04yd会場提供d0.04yaてd0.04yaいd0.04ybだいd0.04ylリクルートテクノロジーズd0.04>vc160<ya1 S0.05660377358490566ya2 T0.018867924528301886ya4 S0.03773584905660377ya6 T0.018867924528301886ya7 S0.03773584905660377yb10 T0.018867924528301886yb29 T0.018867924528301886ya※ T0.018867924528301886ybこの T0.018867924528301886yb記事 T0.018867924528301886yaは T0.018867924528301886ya次 T0.018867924528301886yaの S0.03773584905660377ycブログ T0.018867924528301886yaを T0.018867924528301886yb翻訳 T0.018867924528301886yaし T0.018867924528301886yaた T0.018867924528301886ybもの T0.018867924528301886yaに T0.018867924528301886ydなります T0.018867924528301886ya。 T0.018867924528301886ya  R0.1320754716981132yb原文 T0.018867924528301886ya： T0.018867924528301886ymElasticsearch T0.018867924528301886ya. S0.11320754716981132ycand T0.018867924528301886yhreleased T0.018867924528301886yb本日 T0.018867924528301886ya（ T0.018867924528301886ya/ T0.018867924528301886ya） T0.018867924528301886ya、 T0.018867924528301886yfLucene T0.018867924528301886ycベース T0.018867924528301886yaE T0.018867924528301886>vc161<ya0 T0.018867924528301886ya1 S0.05660377358490566ya4 S0.03773584905660377ya6 T0.018867924528301886ya7 S0.03773584905660377yb10 T0.018867924528301886yb16 T0.018867924528301886ya※ T0.018867924528301886ybこの T0.018867924528301886yb記事 T0.018867924528301886yaは T0.018867924528301886ya次 T0.018867924528301886yaの S0.03773584905660377ycブログ T0.018867924528301886yaを T0.018867924528301886yb翻訳 T0.018867924528301886yaし T0.018867924528301886yaた T0.018867924528301886ybもの T0.018867924528301886yaに T0.018867924528301886ydなります T0.018867924528301886ya。 T0.018867924528301886ya  R0.1320754716981132yb原文 T0.018867924528301886ya： T0.018867924528301886ymElasticsearch T0.018867924528301886ya. S0.11320754716981132ycand T0.018867924528301886yhreleased T0.018867924528301886yb本日 T0.018867924528301886ya（ T0.018867924528301886ya/ T0.018867924528301886ya） T0.018867924528301886ya、 T0.018867924528301886yfLucene T0.018867924528301886ycベース T0.018867924528301886yaE T0.018867924528301886>vc162<yb東京g0.03125yb以外g0.03125yaでf0.0625yaのf0.0625yc勉強会f0.0625ya第g0.03125yb2弾g0.03125ycとしてg0.03125ya、g0.03125yb関西g0.03125yaをg0.03125yb開催g0.03125yaしg0.03125yaてg0.03125ycきましg0.03125yaたg0.03125ya。g0.03125ya f0.1875y PElasticsearch勉強会f0.0625ybinf0.0625yb大阪g0.03125ya京g0.03125>vc163<ya※ T0.023809523809523808ybこの T0.023809523809523808yb記事 T0.023809523809523808yaは T0.047619047619047616ya次 T0.023809523809523808yaの S0.11904761904761904ycブログ T0.023809523809523808yaを T0.023809523809523808yb翻訳 T0.023809523809523808yaし T0.023809523809523808yaた T0.023809523809523808ybもの T0.023809523809523808yaに T0.023809523809523808ydなります T0.023809523809523808ya。 T0.023809523809523808ya  S0.14285714285714285yb原文 T0.023809523809523808ya： T0.023809523809523808ycThe T0.023809523809523808yeGreat T0.023809523809523808ygMapping T0.023809523809523808ykRefactoring T0.023809523809523808ymElasticsearch T0.023809523809523808ycユーザ T0.023809523809523808yb悩み T0.023809523809523808yb最も T0.023809523809523808yb大き T0.023809523809523808ycなもの T0.023809523809523808yb一つ T0.023809523809523808ya、 T0.023809523809523808ycタイプ T0.023809523809523808yaと T0.023809523809523808>vc164<ya0 S0.07407407407407407ya1 T0.037037037037037035ya2 T0.037037037037037035ya※ T0.018518518518518517ybこの T0.018518518518518517yb記事 T0.018518518518518517yaは T0.018518518518518517ya次 T0.018518518518518517yaの S0.05555555555555555ycブログ T0.018518518518518517yaを T0.037037037037037035yb翻訳 T0.018518518518518517yaし T0.037037037037037035yaた T0.018518518518518517ybもの T0.018518518518518517yaに T0.018518518518518517ydなります T0.018518518518518517ya。 T0.037037037037037035ya  R0.1111111111111111yb原文 T0.018518518518518517ya： T0.018518518518518517ymElasticsearch T0.037037037037037035ya. R0.1111111111111111ydbeta T0.037037037037037035yfcoming T0.018518518518518517ydsoon T0.018518518518518517ya! T0.018518518518518517ydリリース T0.018518518518518517yb準備 T0.018518518518518517yaて T0.018518518518518517yaい T0.018518518518518517ybます T0.018518518518518517>vc165<ya4 T0.023255813953488372yaヶ T0.023255813953488372yb月前 T0.023255813953488372yaに T0.046511627906976744ya、 S0.06976744186046512yeFound T0.046511627906976744ya  S0.13953488372093023yfjoined T0.023255813953488372ycour T0.023255813953488372ydteam T0.023255813953488372ybat T0.023255813953488372ygElastic T0.023255813953488372yaを T0.046511627906976744yeアナウンス T0.023255813953488372ycしまし T0.023255813953488372yaた T0.023255813953488372ya。 T0.023255813953488372yaの T0.023255813953488372yb素晴 T0.023255813953488372yaら T0.023255813953488372ybしい T0.023255813953488372ycチーム T0.023255813953488372yaと T0.023255813953488372yb一緒 T0.023255813953488372yb仕事 T0.023255813953488372yaし T0.023255813953488372yaて T0.023255813953488372yaい T0.023255813953488372ybます T0.023255813953488372yaが T0.023255813953488372yb彼ら T0.023255813953488372ydによって T0.023255813953488372ybより T0.023255813953488372>vc166<ylJustTechTalk T0.030303030303030304ya# T0.030303030303030304yb02 T0.030303030303030304ya  S0.09090909090909091ye形態素解析 T0.030303030303030304yaの S0.09090909090909091ybあれ T0.030303030303030304yaや S0.06060606060606061ybこれ T0.030303030303030304ya@ T0.030303030303030304yhジャストシステム S0.06060606060606061yaに T0.030303030303030304yb参加 T0.030303030303030304yaし T0.030303030303030304yaて T0.030303030303030304ycきまし T0.030303030303030304yaた T0.030303030303030304ya。 T0.030303030303030304ybさん T0.030303030303030304yf形態素解析器 T0.030303030303030304ydJMAT T0.030303030303030304ya話 T0.030303030303030304yaと T0.030303030303030304yfKagome T0.030303030303030304ya、 S0.06060606060606061yfJanome T0.030303030303030304>vc167<ya5d0.02ydひさびさd0.02yaにd0.04ya、d0.02ye勉強会メモd0.02ya。d0.06ya d0.16yfHatenad0.02yhEngineerd0.02ygSeminard0.02ya#d0.02ya@d0.02yeTokyod0.02yb当選d0.02yaしd0.04yaたd0.06yaのd0.02yaでd0.02yb行っd0.04yaてd0.04ycきましd0.04ycいつもd0.02yaはd0.02yb近寄d0.02yaらd0.04ybないd0.02ydオシャレd0.02yaなd0.02ya街d0.02yaをd0.02ydドキドキd0.02ybながd0.02yaとd0.02>vc168<ya0 T0.022222222222222223ya1 T0.022222222222222223ya4 T0.044444444444444446ya6 T0.044444444444444446ya9 T0.022222222222222223yb10 T0.022222222222222223ya※ T0.022222222222222223ybこの T0.022222222222222223yb記事 T0.022222222222222223yaは T0.022222222222222223ya次 T0.022222222222222223yaの T0.044444444444444446ycブログ T0.022222222222222223yaを T0.022222222222222223yb翻訳 T0.022222222222222223yaし T0.022222222222222223yaた T0.022222222222222223ybもの T0.022222222222222223yaに T0.022222222222222223ydなります T0.022222222222222223ya。 T0.022222222222222223ya  R0.1111111111111111yb原文 T0.022222222222222223ya： T0.022222222222222223ymElasticsearch T0.022222222222222223ya. S0.08888888888888889yhreleased T0.022222222222222223yb本日 T0.022222222222222223ya（ T0.022222222222222223ya/ T0.022222222222222223ya） T0.022222222222222223ya、 T0.022222222222222223yfLucene T0.022222222222222223ycベース T0.022222222222222223ydElas T0.022222222222222223>vc169<yd第10回 T0.038461538461538464yoElsticsearch勉強会 T0.038461538461538464yaを T0.038461538461538464yb開催 T0.038461538461538464yaし S0.07692307692307693ybまし T0.038461538461538464yaた S0.11538461538461539ya。 T0.038461538461538464ya  T0.038461538461538464ydスタッフ T0.038461538461538464yaの S0.07692307692307693yc皆さん S0.07692307692307693ya、 S0.07692307692307693yeスピーカー T0.038461538461538464yd開場提供 T0.038461538461538464yaて T0.038461538461538464yaい T0.038461538461538464ybだい T0.038461538461538464ylリクルートテクノロジーズ T0.038461538461538464yaさ T0.038461538461538464>vc170<ya※ S0.02127659574468085ybこの S0.02127659574468085yb記事 S0.02127659574468085yaは S0.02127659574468085ya次 S0.02127659574468085yaの R0.0425531914893617ycブログ S0.02127659574468085yaを S0.06382978723404255yb翻訳 S0.02127659574468085yaし S0.06382978723404255yaた S0.02127659574468085ybもの S0.02127659574468085yaに S0.02127659574468085ydなります S0.02127659574468085ya。 S0.02127659574468085ya  S0.14893617021276595yb原文 S0.02127659574468085ya： S0.02127659574468085ygReindex S0.02127659574468085ymElasticsearch S0.02127659574468085ydWith S0.02127659574468085yhLogstash S0.02127659574468085yfThanks S0.02127659574468085yeDavid S0.02127659574468085ya! S0.02127659574468085yeマッピング S0.02127659574468085yb変更 R0.0425531914893617ybたり R0.0425531914893617ya、 R0.0425531914893617yfインデックス S0.02127659574468085yb設定 S0.02127659574468085ybある S0.02127659574468085yaサ S0.02127659574468085>vc171<ya※ T0.022727272727272728ybこの T0.022727272727272728yb記事 T0.022727272727272728yaは T0.022727272727272728ya次 T0.022727272727272728yaの S0.06818181818181818ycブログ T0.022727272727272728yaを T0.045454545454545456yb翻訳 T0.022727272727272728yaし T0.045454545454545456yaた T0.022727272727272728ybもの T0.022727272727272728yaに T0.022727272727272728ydなります T0.022727272727272728ya。 T0.022727272727272728ya  S0.13636363636363635yb原文 T0.022727272727272728ya： T0.022727272727272728ydJoin T0.022727272727272728ycthe T0.022727272727272728ylConversation T0.022727272727272728ya: T0.022727272727272728ygDiscuss T0.022727272727272728ya. T0.045454545454545456ygElastic T0.022727272727272728ybCo T0.022727272727272728yb3つ T0.022727272727272728ycOSS T0.022727272727272728yfプロジェクト T0.022727272727272728yb開発 T0.022727272727272728ygスケールアップ T0.022727272727272728yb始め T0.022727272727272728ya、 T0.022727272727272728yiコミュニティサポー T0.022727272727272728>vc172<ya1 T0.022222222222222223ya2 T0.022222222222222223ya4 S0.06666666666666667ya5 T0.022222222222222223yb10 T0.022222222222222223yb27 T0.022222222222222223ya※ T0.022222222222222223ybこの T0.022222222222222223yb記事 T0.022222222222222223yaは T0.022222222222222223ya次 T0.022222222222222223yaの T0.044444444444444446ycブログ T0.022222222222222223yaを T0.022222222222222223yb翻訳 T0.022222222222222223yaし T0.022222222222222223yaた T0.022222222222222223ybもの T0.022222222222222223yaに T0.022222222222222223ydなります T0.022222222222222223ya。 T0.022222222222222223ya  R0.1111111111111111yb原文 T0.022222222222222223ya： T0.022222222222222223ymElasticsearch T0.022222222222222223ya. S0.08888888888888889yhReleased T0.022222222222222223yb本日 T0.022222222222222223ya（ T0.022222222222222223ya/ T0.022222222222222223ya） T0.022222222222222223ya、 T0.022222222222222223yfLucene T0.022222222222222223ycベース T0.022222222222222223ycEla T0.022222222222222223>vc173<yc第9回 T0.038461538461538464yoElsticsearch勉強会 T0.038461538461538464yaを T0.038461538461538464yb開催 T0.038461538461538464yaし S0.07692307692307693ybまし T0.038461538461538464yaた S0.11538461538461539ya。 T0.038461538461538464ya  T0.038461538461538464ydスタッフ T0.038461538461538464yaの S0.07692307692307693yc皆さん S0.07692307692307693ya、 S0.07692307692307693yeスピーカー T0.038461538461538464yd開場提供 T0.038461538461538464yaて T0.038461538461538464yaい T0.038461538461538464ybだい T0.038461538461538464ylリクルートテクノロジーズ T0.038461538461538464ybさん T0.038461538461538464>vc174<ya1 T0.044444444444444446ya4 S0.06666666666666667ya5 T0.022222222222222223ya9 T0.022222222222222223yb10 T0.022222222222222223ya※ T0.022222222222222223ybこの T0.022222222222222223yb記事 T0.022222222222222223yaは T0.022222222222222223ya次 T0.022222222222222223yaの T0.044444444444444446ycブログ T0.022222222222222223yaを T0.022222222222222223yb翻訳 T0.022222222222222223yaし T0.022222222222222223yaた T0.022222222222222223ybもの T0.022222222222222223yaに T0.022222222222222223ydなります T0.022222222222222223ya。 T0.022222222222222223ya  R0.1111111111111111yb原文 T0.022222222222222223ya： T0.022222222222222223ymElasticsearch T0.022222222222222223ya. S0.08888888888888889yhReleased T0.022222222222222223yb本日 T0.022222222222222223ya（ T0.022222222222222223ya/ T0.022222222222222223ya） T0.022222222222222223ya、 T0.022222222222222223yfLucene T0.022222222222222223ycベース T0.022222222222222223ydElas T0.022222222222222223>vc175<y PElasticsearch勉強会 T0.027777777777777776ya  R0.1111111111111111ybin T0.027777777777777776yc名古屋 T0.027777777777777776yaを T0.027777777777777776yb開催 T0.027777777777777776yaし T0.027777777777777776ybまし T0.027777777777777776yaた S0.08333333333333333ya。 S0.05555555555555555ya初 T0.027777777777777776yaの S0.05555555555555555yb東京 T0.027777777777777776yb以外 T0.027777777777777776yaで S0.05555555555555555yc勉強会 T0.027777777777777776yaす T0.027777777777777776yb企画 T0.027777777777777776ya、 T0.027777777777777776yeセッション T0.027777777777777776ybなど T0.027777777777777776yaお T0.027777777777777776yb手伝 T0.027777777777777776ybいい T0.027777777777777776ybだい T0.027777777777777776ya@ T0.027777777777777776ygsmogami T0.027777777777777776yaさ T0.027777777777777776>vc176<ya0 T0.022222222222222223ya1 T0.022222222222222223ya3 T0.022222222222222223ya4 T0.044444444444444446ya5 T0.022222222222222223yb10 T0.022222222222222223yb23 T0.022222222222222223ya※ T0.022222222222222223ybこの T0.022222222222222223yb記事 T0.022222222222222223yaは T0.022222222222222223ya次 T0.022222222222222223yaの T0.044444444444444446ycブログ T0.022222222222222223yaを T0.022222222222222223yb翻訳 T0.022222222222222223yaし T0.022222222222222223yaた T0.022222222222222223ybもの T0.022222222222222223yaに T0.022222222222222223ydなります T0.022222222222222223ya。 T0.022222222222222223ya  R0.1111111111111111yb原文 T0.022222222222222223ya： T0.022222222222222223ymElasticsearch T0.022222222222222223ya. S0.08888888888888889yhReleased T0.022222222222222223yb本日 T0.022222222222222223ya（ T0.022222222222222223ya/ T0.022222222222222223ya） T0.022222222222222223ya、 T0.022222222222222223yfLucene T0.022222222222222223ycベース T0.022222222222222223ycEla T0.022222222222222223>vc177<yhサンフランシスコ S0.02702702702702703ybから S0.02702702702702703ybこん S0.02702702702702703ybにち S0.02702702702702703yaは S0.05405405405405406ya。 S0.05405405405405406ya  S0.08108108108108109ya今 S0.02702702702702703ya、 S0.08108108108108109ya私 S0.02702702702702703yc弊社初 S0.02702702702702703yaの S0.08108108108108109yjユーザカンファレンス S0.02702702702702703ygelastic S0.02702702702702703ya{ S0.02702702702702703ybON S0.02702702702702703ya} S0.02702702702702703yaに S0.05405405405405406yb参加 S0.02702702702702703ybする S0.02702702702702703ybため S0.02702702702702703ya初 S0.05405405405405406ydアメリカ S0.02702702702702703yc出張中 S0.02702702702702703yaで S0.02702702702702703yaす S0.02702702702702703yaユ S0.02702702702702703>vc178<ya0 R0.0196078431372549ya1 R0.0392156862745098yb27 R0.0196078431372549ya※ R0.0196078431372549ybこの R0.0196078431372549yb記事 R0.0196078431372549yaは R0.0196078431372549ya次 R0.0196078431372549yaの R0.0196078431372549ycブログ R0.0196078431372549yaを R0.0392156862745098yb翻訳 R0.0196078431372549yaし R0.0196078431372549yaた R0.0392156862745098ybもの R0.0196078431372549yaに R0.0392156862745098ydなります R0.0196078431372549ya。 R0.0392156862745098ya  S0.21568627450980393yb原文 R0.0196078431372549ya： R0.0196078431372549ycyou R0.0196078431372549ydknow R0.0196078431372549ya, R0.0196078431372549ycfor R0.0196078431372549yhsecurity R0.0196078431372549ya: R0.0196078431372549yfshield R0.0196078431372549ydgoes R0.0196078431372549ybga R0.0196078431372549ya/ R0.0196078431372549yfShield R0.0196078431372549ya. R0.0196078431372549ydリリース R0.0196078431372549ycしまし R0.0196078431372549ylElasticsearc R0.0196078431372549>vc179<ya3 S0.03225806451612903yb14 S0.03225806451612903ye4月13日 S0.03225806451612903ybから S0.03225806451612903yc3日間 S0.03225806451612903ya、 S0.06451612903225806ymElasticsearch S0.03225806451612903yaの S0.03225806451612903ydCore S0.03225806451612903yfトレーニング S0.03225806451612903yaが S0.03225806451612903yb東京 S0.03225806451612903yaで S0.06451612903225806yb開催 S0.03225806451612903yaさ S0.03225806451612903yaれ S0.03225806451612903ybます S0.03225806451612903ya。 S0.03225806451612903ya  S0.06451612903225806yeEarly S0.03225806451612903ydBird S0.03225806451612903ycという S0.03225806451612903ybこと S0.03225806451612903ya/ S0.03225806451612903ybまで S0.03225806451612903yaに S0.03225806451612903yb申し S0.03225806451612903yc込みす S0.03225806451612903>vc180<ya4 T0.041666666666666664ya※ T0.020833333333333332ybこの T0.020833333333333332yb記事 T0.020833333333333332yaは T0.041666666666666664ya次 T0.020833333333333332yaの T0.020833333333333332ycブログ T0.020833333333333332yaを T0.020833333333333332yb翻訳 T0.020833333333333332yaし T0.020833333333333332yaた T0.020833333333333332ybもの T0.020833333333333332yaに S0.08333333333333333ydなります T0.020833333333333332ya。 T0.020833333333333332ya  S0.10416666666666667yb原文 T0.020833333333333332ya： T0.020833333333333332yfkibana T0.020833333333333332ya. T0.041666666666666664yiliterally T0.020833333333333332yfKibana T0.020833333333333332yb現在 T0.020833333333333332ya、 S0.10416666666666667yd文字通り T0.020833333333333332yc抽象的 T0.020833333333333332yc概念的 T0.020833333333333332yc精神的 T0.020833333333333332ycそして T0.020833333333333332yaと T0.020833333333333332yaて T0.020833333333333332yaも T0.020833333333333332yc楽しく T0.020833333333333332>vc181<ya1 T0.061224489795918366ya2 S0.02040816326530612ya3 S0.02040816326530612ya4 T0.061224489795918366ya9 S0.02040816326530612yb20 S0.02040816326530612ya※ S0.02040816326530612ybこの S0.02040816326530612yb記事 S0.02040816326530612yaは S0.02040816326530612ya次 S0.02040816326530612yaの S0.02040816326530612ycブログ S0.02040816326530612yaを S0.02040816326530612yb翻訳 S0.02040816326530612yaし S0.02040816326530612yaた S0.02040816326530612ybもの S0.02040816326530612yaに S0.02040816326530612ydなります S0.02040816326530612ya。 S0.02040816326530612ya  S0.14285714285714285yb原文 S0.02040816326530612ya： S0.02040816326530612ymelasticsearch S0.02040816326530612ya. S0.12244897959183673ycand S0.02040816326530612yhreleased S0.02040816326530612yb本日 S0.02040816326530612ya（ S0.02040816326530612ya/ S0.02040816326530612ya） S0.02040816326530612ya、 S0.02040816326530612ymElasticsearch S0.02040816326530612>vc182<yb来る T0.029411764705882353ya、 T0.029411764705882353yd4月4日 T0.029411764705882353yaの S0.11764705882352941yc土曜日 T0.029411764705882353yb午後 T0.029411764705882353yaに T0.029411764705882353yc名古屋 T0.029411764705882353yaで S0.11764705882352941y PElasticsearch勉強会 T0.029411764705882353yaを T0.029411764705882353yb開催 T0.029411764705882353yb予定 T0.029411764705882353yaす T0.058823529411764705ya。 T0.058823529411764705ya  T0.058823529411764705ya「 T0.029411764705882353ya初 T0.029411764705882353ya」 T0.029411764705882353yb東京 T0.029411764705882353yb以外 T0.029411764705882353yc勉強会 T0.029411764705882353ygTwitter T0.029411764705882353ybこの T0.029411764705882353ybよう T0.029411764705882353>vc183<yc第8回 T0.038461538461538464yoElsticsearch勉強会 T0.038461538461538464yaを T0.038461538461538464yb開催 T0.038461538461538464yaし S0.07692307692307693ybまし T0.038461538461538464yaた S0.11538461538461539ya。 T0.038461538461538464ya  T0.038461538461538464ydスタッフ T0.038461538461538464yaの S0.07692307692307693yc皆さん S0.07692307692307693ya、 S0.07692307692307693yeスピーカー T0.038461538461538464yd開場提供 T0.038461538461538464yaて T0.038461538461538464yaい T0.038461538461538464ybだい T0.038461538461538464ylリクルートテクノロジーズ T0.038461538461538464ybさん T0.038461538461538464>vc184<ya1 T0.022727272727272728ya3 T0.045454545454545456ya4 T0.022727272727272728ya8 T0.022727272727272728ya※ T0.022727272727272728ybこの T0.022727272727272728yb記事 T0.022727272727272728yaは T0.022727272727272728ya次 T0.022727272727272728yaの T0.045454545454545456ycブログ T0.022727272727272728yaを T0.022727272727272728yb翻訳 T0.022727272727272728yaし T0.022727272727272728yaた T0.022727272727272728ybもの T0.022727272727272728yaに T0.022727272727272728ydなります T0.022727272727272728ya。 T0.022727272727272728ya  R0.1590909090909091yb原文 T0.022727272727272728ya： T0.022727272727272728ygrunning T0.022727272727272728yfgroovy T0.022727272727272728ygscripts T0.022727272727272728ygwithout T0.022727272727272728ygdynamic T0.022727272727272728yiscripting T0.022727272727272728ynElasticsearch1 T0.022727272727272728ya. S0.09090909090909091yaと T0.022727272727272728ydリリース T0.022727272727272728ybによ T0.022727272727272728>vc185<ya1 R0.0392156862745098ya3 T0.058823529411764705ya4 R0.0392156862745098ya8 R0.0196078431372549yb10 R0.0196078431372549ya※ R0.0196078431372549ybこの R0.0196078431372549yb記事 R0.0196078431372549yaは R0.0196078431372549ya次 R0.0196078431372549yaの R0.0196078431372549ycブログ R0.0196078431372549yaを R0.0392156862745098yb翻訳 R0.0196078431372549yaし R0.0392156862745098yaた R0.0392156862745098ybもの R0.0196078431372549yaに R0.0392156862745098ydなります R0.0196078431372549ya。 R0.0196078431372549ya  S0.13725490196078433yb原文 R0.0196078431372549ya： R0.0196078431372549ymelasticsearch R0.0196078431372549ya. S0.11764705882352941ycand R0.0196078431372549yhreleased R0.0196078431372549yb本日 R0.0196078431372549ya、 R0.0196078431372549yfLucene R0.0196078431372549ycベース R0.0196078431372549ydElas R0.0196078431372549>vc186<yb今年 S0.05263157894736842yaも S0.02631578947368421yeCROSS S0.02631578947368421yb参加 S0.02631578947368421yaし S0.05263157894736842ybまし S0.02631578947368421yaた S0.10526315789473684ya。 S0.07894736842105263ycそして S0.02631578947368421ya、 S0.05263157894736842yd話もして S0.02631578947368421ycきまし S0.02631578947368421ya  S0.02631578947368421yaは S0.05263157894736842yb横浜 S0.05263157894736842yaの S0.05263157894736842yc大さん S0.02631578947368421ya橋 S0.02631578947368421yaで S0.07894736842105263ygあんまりこない S0.02631578947368421yb乗り S0.02631578947368421yb換え S0.02631578947368421yaお S0.02631578947368421ydおたして S0.02631578947368421ydしまいま S0.02631578947368421>vc187<yb今年 T0.022727272727272728yaは T0.045454545454545456yc大晦日 T0.022727272727272728yaに T0.045454545454545456ybなっ T0.022727272727272728yaて T0.045454545454545456yeしまいまし T0.022727272727272728yaた T0.045454545454545456ya。 S0.11363636363636363ycしかも T0.022727272727272728ya、 T0.022727272727272728ycちょっ T0.022727272727272728yaと T0.022727272727272728yb飲ん T0.022727272727272728yaで T0.022727272727272728ybたり T0.022727272727272728ya  S0.06818181818181818ya第 T0.022727272727272728yb9流 T0.022727272727272728yaし T0.022727272727272728ybなが T0.022727272727272728yaら T0.022727272727272728yb書い T0.045454545454545456ybます T0.022727272727272728yb振り T0.022727272727272728yb返り T0.022727272727272728ya( T0.022727272727272728ye2013年 T0.022727272727272728yb抱負 T0.022727272727272728ybから T0.022727272727272728ya) T0.022727272727272728ybまず T0.022727272727272728yb昨年 T0.022727272727272728>vc188<yd2014 T0.029411764705882353ybこの T0.029411764705882353yb記事 T0.029411764705882353yaは T0.029411764705882353ymElasticsearch T0.029411764705882353ya  S0.11764705882352941yfAdvent T0.029411764705882353ygCalndar T0.029411764705882353yaの T0.058823529411764705yd25日目 T0.029411764705882353ydエントリ T0.029411764705882353yaで S0.08823529411764706yaす T0.058823529411764705ya。 T0.058823529411764705ybあっ T0.029411764705882353ycという T0.058823529411764705ya間 T0.029411764705882353yaに T0.029411764705882353yc最終日 T0.029411764705882353yb来年 T0.029411764705882353ybにつ T0.029411764705882353ycなげる T0.029411764705882353yb意味 T0.029411764705882353ya、 T0.029411764705882353yfElasti T0.029411764705882353>vc189<ya0 T0.043478260869565216ya1 T0.043478260869565216ya3 T0.043478260869565216yb12 T0.021739130434782608yb17 T0.021739130434782608ya※ T0.021739130434782608ybこの T0.021739130434782608yb記事 T0.021739130434782608yaは T0.021739130434782608ya次 T0.021739130434782608yaの T0.021739130434782608ycブログ T0.021739130434782608yaを T0.043478260869565216yb翻訳 T0.021739130434782608yaし T0.021739130434782608yaた T0.043478260869565216ybもの T0.021739130434782608yaに T0.043478260869565216ydなります T0.021739130434782608ya。 T0.021739130434782608ya  S0.13043478260869565yb原文 T0.021739130434782608ya： T0.021739130434782608yfmarvel T0.021739130434782608ya. S0.08695652173913043yhreleased T0.021739130434782608ya/ T0.021739130434782608ya、 T0.021739130434782608ymElasticsearch T0.021739130434782608yfMarvel T0.021739130434782608ydリリース T0.021739130434782608ycしまし T0.021739130434782608>vc190<ya1 R0.0392156862745098ya3 T0.058823529411764705ya4 R0.0392156862745098ya8 R0.0196078431372549yb10 R0.0196078431372549ya※ R0.0196078431372549ybこの R0.0196078431372549yb記事 R0.0196078431372549yaは R0.0196078431372549ya次 R0.0196078431372549yaの R0.0196078431372549ycブログ R0.0196078431372549yaを R0.0392156862745098yb翻訳 R0.0196078431372549yaし R0.0392156862745098yaた R0.0392156862745098ybもの R0.0196078431372549yaに R0.0392156862745098ydなります R0.0196078431372549ya。 R0.0196078431372549ya  S0.13725490196078433yb原文 R0.0196078431372549ya： R0.0196078431372549ymelasticsearch R0.0196078431372549ya. S0.11764705882352941ycand R0.0196078431372549yhreleased R0.0196078431372549yb本日 R0.0196078431372549ya、 R0.0196078431372549yfLucene R0.0196078431372549ycベース R0.0196078431372549ydElas R0.0196078431372549>vc191<yb12 T0.027777777777777776yb17 T0.027777777777777776yb「【 T0.027777777777777776yb東京 T0.027777777777777776ya】 T0.027777777777777776ydJJUG T0.027777777777777776ya  S0.05555555555555555yhナイト・セミナー T0.027777777777777776ya「 T0.027777777777777776yd機械学習 T0.027777777777777776ya・ T0.027777777777777776yh自然言語処理特集 T0.027777777777777776ya！ T0.027777777777777776ya」 S0.05555555555555555ya/ T0.027777777777777776ya（ T0.027777777777777776ya水 T0.027777777777777776ya） T0.027777777777777776yb開催 T0.027777777777777776yaで T0.027777777777777776yfLucene T0.027777777777777776yaの T0.027777777777777776ya話 T0.027777777777777776yaを T0.027777777777777776ybして T0.027777777777777776ycきまし T0.027777777777777776yaた T0.027777777777777776ya。 T0.027777777777777776yb本当 T0.027777777777777776yaに T0.027777777777777776ybごく T0.027777777777777776yb簡単 T0.027777777777777776yaな T0.027777777777777776ya入 T0.027777777777777776>vc192<ycたまに T0.023255813953488372yaは S0.06976744186046512ya、 S0.09302325581395349yb他愛 T0.023255813953488372yaの T0.046511627906976744ybない T0.023255813953488372ycブログ T0.023255813953488372yaを T0.046511627906976744ya。 S0.06976744186046512ya  S0.06976744186046512yb仕事 T0.046511627906976744yaし T0.046511627906976744yaな T0.023255813953488372yaが T0.023255813953488372yaら T0.023255813953488372ydコーヒー T0.023255813953488372yb飲ん T0.023255813953488372yaで T0.023255813953488372ybます T0.046511627906976744yb最近 T0.023255813953488372yfサムライズム T0.023255813953488372ybさん T0.023255813953488372ydオフィス T0.046511627906976744yaに T0.046511627906976744yd入り浸っ T0.023255813953488372yaて T0.046511627906976744>vc193<ya0 T0.018867924528301886ya1 S0.03773584905660377ya5 T0.018867924528301886ya※ T0.018867924528301886ybこの T0.018867924528301886yb記事 T0.018867924528301886yaは S0.03773584905660377ya次 T0.018867924528301886yaの S0.05660377358490566ycブログ T0.018867924528301886yaを T0.018867924528301886yb翻訳 T0.018867924528301886yaし T0.018867924528301886yaた T0.018867924528301886ybもの T0.018867924528301886yaに T0.018867924528301886ydなります T0.018867924528301886ya。 T0.018867924528301886ya  S0.18867924528301888yb原文 T0.018867924528301886ya： T0.018867924528301886yhexciting T0.018867924528301886yhlogstash T0.018867924528301886yfplugin T0.018867924528301886yiecosystem T0.018867924528301886ygchanges T0.018867924528301886yhLogstash T0.018867924528301886ya. S0.03773584905660377ydBeta T0.018867924528301886ya( T0.018867924528301886yaお T0.018867924528301886yb試し T0.018867924528301886ycこちら T0.018867924528301886ya) T0.018867924528301886ydリリース T0.018867924528301886yaで T0.018867924528301886ya、 T0.018867924528301886yeプラグイン T0.018867924528301886yeインストー T0.018867924528301886>vc194<ya0 T0.038461538461538464ya1 S0.07692307692307693ya5 T0.038461538461538464ya※ T0.019230769230769232ybこの T0.019230769230769232yb記事 T0.019230769230769232yaは T0.019230769230769232ya次 T0.019230769230769232yaの T0.038461538461538464ycブログ T0.019230769230769232yaを T0.038461538461538464yb翻訳 T0.019230769230769232yaし T0.019230769230769232yaた T0.038461538461538464ybもの T0.019230769230769232yaに T0.019230769230769232ydなります T0.019230769230769232ya。 T0.038461538461538464ya  S0.11538461538461539yb原文 T0.019230769230769232ya： T0.019230769230769232yhlogstash T0.019230769230769232ya. S0.09615384615384616ydbeta T0.019230769230769232yhreleased T0.019230769230769232yhLogstash T0.019230769230769232ydBeta T0.019230769230769232ydリリース T0.019230769230769232ycしまし T0.019230769230769232ycこちら T0.019230769230769232ycページ T0.019230769230769232ybから T0.019230769230769232yfダウンロード T0.019230769230769232yaで T0.019230769230769232>vc195<yb早い T0.029411764705882353ybもの T0.029411764705882353yaで S0.08823529411764706ya、 T0.058823529411764705yb師走 T0.029411764705882353yaす T0.029411764705882353ya。 S0.08823529411764706yb今年 T0.029411764705882353yaも T0.029411764705882353ybあと T0.029411764705882353yb少し T0.029411764705882353yaと T0.029411764705882353ydなりまし T0.029411764705882353yaた T0.058823529411764705ycという T0.029411764705882353ybこと T0.029411764705882353yfAdvent T0.029411764705882353ya  T0.058823529411764705yhCalendar T0.029411764705882353yaの T0.029411764705882353yb季節 T0.029411764705882353yaが T0.029411764705882353ye始まりまし T0.029411764705882353ybこの T0.029411764705882353yb記事 T0.029411764705882353yaは T0.029411764705882353yhElastics T0.029411764705882353>vc196<ya1 T0.058823529411764705ya2 R0.0196078431372549ya3 R0.0196078431372549ya4 R0.0392156862745098ya6 R0.0196078431372549yb10 R0.0196078431372549ya※ R0.0196078431372549ybこの R0.0196078431372549yb記事 R0.0196078431372549yaは R0.0196078431372549ya次 R0.0196078431372549yaの R0.0196078431372549ycブログ R0.0196078431372549yaを R0.0392156862745098yb翻訳 R0.0196078431372549yaし R0.0392156862745098yaた R0.0392156862745098ybもの R0.0196078431372549yaに R0.0392156862745098ydなります R0.0196078431372549ya。 R0.0196078431372549ya  S0.13725490196078433yb原文 R0.0196078431372549ya： R0.0196078431372549ymelasticsearch R0.0196078431372549ya. S0.11764705882352941ycand R0.0196078431372549yhreleased R0.0196078431372549yb本日 R0.0196078431372549ya、 R0.0196078431372549yfLucene R0.0196078431372549ycベース R0.0196078431372549ydElas R0.0196078431372549>vc197<yb前回 S0.06451612903225806yaの S0.16129032258064516ya「 S0.03225806451612903yhLogstash S0.06451612903225806yaを S0.03225806451612903yb利用 S0.03225806451612903yaし S0.03225806451612903yaた S0.03225806451612903yfApache S0.03225806451612903yfアクセスログ S0.03225806451612903yeインポート S0.03225806451612903ya」 S0.03225806451612903yb続き S0.03225806451612903yaで S0.06451612903225806yaす S0.03225806451612903ya。 S0.03225806451612903ya  S0.03225806451612903yb記事 S0.03225806451612903yaは S0.03225806451612903ya、 S0.03225806451612903yb設定 S0.03225806451612903ydファイル S0.03225806451612903ydについて S0.03225806451612903ya説 S0.03225806451612903>vc198<ya4 T0.034482758620689655ydJJUG T0.034482758620689655ya  S0.06896551724137931ycCCC T0.034482758620689655yaや T0.034482758620689655ya第 T0.034482758620689655yb7回 T0.034482758620689655y PElasticsearch勉強会 T0.034482758620689655yaの S0.06896551724137931yfKibana T0.034482758620689655ybデモ T0.034482758620689655yaに T0.034482758620689655yfアクセスログ T0.034482758620689655yaを T0.034482758620689655yb利用 T0.034482758620689655yaし T0.034482758620689655ybまし T0.034482758620689655yaた T0.034482758620689655ya。 T0.034482758620689655ybただ T0.034482758620689655ya、 S0.06896551724137931yeセッション T0.034482758620689655yaで T0.034482758620689655yaは T0.034482758620689655yeどうやって T0.034482758620689655ydElas T0.034482758620689655>vc199<yc第7回 T0.038461538461538464yoElsticsearch勉強会 T0.038461538461538464yaを T0.038461538461538464yb開催 T0.038461538461538464yaし S0.07692307692307693ybまし T0.038461538461538464yaた S0.11538461538461539ya。 T0.038461538461538464ya  T0.038461538461538464ydスタッフ T0.038461538461538464yaの S0.07692307692307693yc皆さん S0.07692307692307693ya、 S0.07692307692307693yeスピーカー T0.038461538461538464yd開場提供 T0.038461538461538464yaて T0.038461538461538464yaい T0.038461538461538464ybだい T0.038461538461538464ylリクルートテクノロジーズ T0.038461538461538464ybさん T0.038461538461538464>vc200<ya0 S0.02040816326530612ya1 S0.04081632653061224ya2 S0.02040816326530612ya3 S0.02040816326530612ya4 S0.04081632653061224ya5 S0.02040816326530612yb10 S0.02040816326530612ya※ S0.02040816326530612ybこの S0.02040816326530612yb記事 S0.02040816326530612yaは S0.02040816326530612ya次 S0.02040816326530612yaの S0.02040816326530612ycブログ S0.02040816326530612yaを S0.04081632653061224yb翻訳 S0.02040816326530612yaし S0.04081632653061224yaた S0.02040816326530612ybもの S0.02040816326530612yaに S0.04081632653061224ydなります S0.02040816326530612ya。 S0.02040816326530612ya  S0.12244897959183673yb原文 S0.02040816326530612ya： S0.02040816326530612ymelasticsearch S0.02040816326530612ya- S0.02040816326530612ya. S0.12244897959183673ycand S0.02040816326530612yhreleased S0.02040816326530612yb本日 S0.02040816326530612ya、 S0.02040816326530612yfLucene S0.02040816326530612ycベース S0.02040816326530612>vc201<yb久し S0.02564102564102564ybぶり S0.02564102564102564yaに S0.02564102564102564yb翻訳 S0.02564102564102564yaで S0.07692307692307693yaは S0.05128205128205128ybない S0.02564102564102564ycブログ S0.02564102564102564yaを S0.02564102564102564ya。 R0.1282051282051282yc書こう S0.02564102564102564yaと S0.02564102564102564yb思い S0.02564102564102564yaな S0.02564102564102564yaが S0.02564102564102564ycらかけ S0.02564102564102564yaて S0.02564102564102564ycなかっ S0.02564102564102564yaた S0.02564102564102564yaの S0.05128205128205128ya  S0.10256410256410256yb今回 S0.02564102564102564yhvalidate S0.02564102564102564ycAPI S0.02564102564102564yb紹介 S0.02564102564102564yaす S0.02564102564102564yb背景 S0.02564102564102564ykElasticsear S0.02564102564102564>vc202<ya0g0.03125ya1f0.0625ya4g0.03125ymElasticsearchg0.03125ya f0.0625ya.g0.09375ydBetag0.03125yaがg0.03125ydリリースg0.03125yaさg0.03125yaれg0.03125ybましg0.03125yaたg0.03125ya。g0.03125yb個人g0.03125yaでg0.03125ymelasticsearchg0.03125ya-f0.0625yhextendedg0.03125yganalyzeg0.03125ycというg0.03125yeプラグインg0.03125yaをg0.03125yb開発g0.03125yaしg0.03125yaてg0.03125yaまg0.03125>vc203<ya0 S0.02127659574468085ya1 S0.06382978723404255ya4 R0.0425531914893617yb10 S0.02127659574468085ya※ S0.02127659574468085ybこの S0.02127659574468085yb記事 S0.02127659574468085yaは S0.02127659574468085ya次 S0.02127659574468085yaの S0.02127659574468085ycブログ S0.02127659574468085yaを R0.0425531914893617yb翻訳 S0.02127659574468085yaし R0.0425531914893617yaた R0.0425531914893617ybもの S0.02127659574468085yaに R0.0425531914893617ydなります S0.02127659574468085ya。 S0.02127659574468085ya  S0.10638297872340426yb原文 S0.02127659574468085ya： S0.02127659574468085ymelasticsearch S0.02127659574468085ya. S0.10638297872340426ydbeta S0.02127659574468085yhreleased S0.02127659574468085yb本日 S0.02127659574468085ya、 R0.0425531914893617yfLucene S0.02127659574468085ycベース S0.02127659574468085yeElast S0.02127659574468085>vc204<yc第6回 T0.038461538461538464yoElsticsearch勉強会 T0.038461538461538464yaを T0.038461538461538464yb開催 T0.038461538461538464yaし S0.07692307692307693ybまし T0.038461538461538464yaた S0.11538461538461539ya。 T0.038461538461538464ya  T0.038461538461538464ydスタッフ T0.038461538461538464yaの S0.07692307692307693yc皆さん S0.07692307692307693ya、 S0.07692307692307693yeスピーカー T0.038461538461538464yd開場提供 T0.038461538461538464yaて T0.038461538461538464yaい T0.038461538461538464ybだい T0.038461538461538464ylリクルートテクノロジーズ T0.038461538461538464ybさん T0.038461538461538464>vc205<yb先日 S0.03225806451612903ye2014年 S0.03225806451612903yd9月9日 S0.03225806451612903ya( S0.03225806451612903ya火 S0.03225806451612903ya) S0.03225806451612903yaに S0.03225806451612903ya『 S0.03225806451612903ycサーバ S0.03225806451612903ya/ S0.03225806451612903ymインフラエンジニア養成読本 S0.03225806451612903ya  R0.0967741935483871ybログ S0.03225806451612903yb収集 S0.03225806451612903ya〜 S0.03225806451612903yd可視化編 S0.03225806451612903ya』 S0.03225806451612903yd出版記念 S0.03225806451612903ya！ S0.06451612903225806yc執筆者 S0.03225806451612903yaが S0.03225806451612903yb語る S0.03225806451612903yb大講 S0.03225806451612903yb演会 S0.03225806451612903yaで S0.03225806451612903ya、 S0.03225806451612903ya「 S0.03225806451612903yhelastics S0.03225806451612903>vc206<ymElasticsearch T0.043478260869565216yaの T0.043478260869565216ygインデキシング T0.043478260869565216yaに T0.043478260869565216yc関する T0.043478260869565216ygパフォーマンス T0.043478260869565216yb検討 T0.043478260869565216ya  R0.2608695652173913yb原文 T0.043478260869565216ya： T0.043478260869565216ykperformance T0.043478260869565216ynconsiderations T0.043478260869565216ycfor T0.043478260869565216ymelasticsearch T0.043478260869565216yhindexing T0.043478260869565216y PElasticsearchユーザ T0.043478260869565216yaは T0.043478260869565216ya様 T0.043478260869565216>vc207<yc懲りず T0.023809523809523808yaに T0.023809523809523808ybまた T0.023809523809523808ya、 T0.047619047619047616yb執筆 T0.023809523809523808yaし T0.023809523809523808yaて T0.047619047619047616ycみまし T0.023809523809523808yaた T0.047619047619047616ya。 T0.023809523809523808ydみなさん T0.023809523809523808ya「 T0.023809523809523808yb買っ T0.023809523809523808ya」 T0.023809523809523808ybから T0.023809523809523808yb感想 T0.023809523809523808yaを T0.047619047619047616yaい T0.023809523809523808ycだける T0.023809523809523808ycとうれ T0.023809523809523808ybしい T0.023809523809523808yaで T0.047619047619047616yaす T0.023809523809523808ya！ T0.023809523809523808ya  T0.047619047619047616yb本書 T0.023809523809523808ydについて T0.023809523809523808yc共著者 T0.023809523809523808yaの S0.07142857142857142yb方々 T0.023809523809523808ycブログ T0.023809523809523808yaが T0.023809523809523808yc詳しい T0.023809523809523808ycそちら T0.023809523809523808>vc208<yeProxyd0.04yb環境d0.04yaでd0.12yb働いd0.04yaてd0.04ybいるd0.08yb方もd0.04yb結構d0.04yaとd0.04yd思いますd0.04ya。d0.04ya d0.04ygTwitterd0.04ya上d0.04ya、d0.04ymElasticsearchd0.04yaのd0.04yfplugind0.04ydコマンドd0.04yeプラグインd0.04yaがd0.04ydインストd0.04>vc209<ya1 S0.11764705882352941ya3 T0.058823529411764705yb原文 T0.029411764705882353ya： T0.029411764705882353ymElasticsearch T0.058823529411764705ya  S0.11764705882352941ya. S0.11764705882352941yhReleased T0.029411764705882353yaを T0.058823529411764705yc日本語 T0.029411764705882353yaに T0.029411764705882353yb翻訳 T0.029411764705882353yaし T0.029411764705882353yaた T0.029411764705882353ybもの T0.029411764705882353yaで T0.029411764705882353yaす T0.029411764705882353ya。 T0.029411764705882353ygバグフィックス T0.029411764705882353ya版 T0.029411764705882353yaの T0.029411764705882353ycリリー T0.029411764705882353>vc210<ya0 T0.045454545454545456ya1 S0.06818181818181818ya2 T0.022727272727272728ygCurator T0.045454545454545456yaの S0.09090909090909091ya. S0.09090909090909091yaが S0.06818181818181818ydリリース T0.022727272727272728yaさ T0.045454545454545456yaれ T0.045454545454545456ybまし T0.022727272727272728yaた S0.06818181818181818ya。 T0.022727272727272728ya  T0.022727272727272728yb前回 T0.022727272727272728yb記事 T0.022727272727272728yb古く T0.022727272727272728ybなっ T0.022727272727272728yaて T0.022727272727272728ycしまっ T0.022727272727272728ya（ T0.022727272727272728ybから T0.022727272727272728ydコマンド T0.022727272727272728yaI T0.022727272727272728ya/ T0.022727272727272728yaF T0.022727272727272728yb変更 T0.022727272727272728ya） T0.022727272727272728>vc211<yc第5回 S0.03571428571428571y PElasticsearch勉強会 S0.03571428571428571yaを S0.03571428571428571yb開催 S0.03571428571428571yaし S0.03571428571428571ybまし S0.03571428571428571yaた S0.10714285714285714ya。 S0.07142857142857142ya  S0.07142857142857142yb遅く S0.03571428571428571ybなっ S0.03571428571428571yaて S0.07142857142857142yeしまいまし S0.03571428571428571yaが S0.03571428571428571ya、 S0.07142857142857142ydまとめて S0.03571428571428571ycみまし S0.03571428571428571yb今回 S0.03571428571428571yaは S0.03571428571428571ymElasticsearch S0.03571428571428571yaに S0.03571428571428571yb入っ S0.03571428571428571>vc212<ycという T0.023809523809523808ybこと S0.07142857142857142yaで S0.07142857142857142ya、 S0.07142857142857142yb転職 T0.047619047619047616yaし T0.047619047619047616ybまし T0.023809523809523808yaた S0.07142857142857142ya。 T0.047619047619047616ya  T0.047619047619047616ybどー T0.023809523809523808yaて T0.047619047619047616yaも T0.023809523809523808ybやり T0.023809523809523808ybたい T0.023809523809523808yaが T0.023809523809523808yb出て T0.023809523809523808yaき T0.023809523809523808yaの T0.023809523809523808yb無理 T0.023809523809523808yaを T0.023809523809523808yb言っ T0.023809523809523808ybする T0.023809523809523808ycにして T0.023809523809523808ycみまし T0.023809523809523808yfサムライズム T0.023809523809523808yaは T0.023809523809523808ybなく T0.023809523809523808yfElasti T0.023809523809523808>vc213<yb退職 T0.021739130434782608yaし T0.021739130434782608ybまし T0.021739130434782608yaた T0.043478260869565216ya。 S0.06521739130434782ya  S0.08695652173913043yb色々 T0.021739130434782608yaと T0.021739130434782608yb書き T0.021739130434782608ycたいん T0.021739130434782608yaで S0.08695652173913043yaす T0.043478260869565216yaが T0.021739130434782608ya、 T0.043478260869565216yb時差 T0.021739130434782608ybボケ T0.021739130434782608yb頭痛 T0.021739130434782608yaい T0.021739130434782608yaの T0.021739130434782608yeこのくらい T0.021739130434782608yc余裕出 T0.021739130434782608yaら T0.021739130434782608yb書く T0.021739130434782608yaか T0.021739130434782608yaも T0.021739130434782608ycほしい T0.021739130434782608ya物 T0.021739130434782608ycリスト T0.021739130434782608yaは T0.043478260869565216ycこちら T0.021739130434782608yc新天地 T0.021739130434782608ydについて T0.021739130434782608ybまた T0.021739130434782608ya明 T0.021739130434782608>vc214<ymElasticsearch R0.0196078431372549ya  S0.11764705882352941yfserver R0.0196078431372549yc2nd R0.0196078431372549ygedition R0.0196078431372549yaが T0.058823529411764705yb発売 R0.0196078431372549yaさ R0.0196078431372549yaれ R0.0196078431372549yaて R0.0196078431372549yaい R0.0196078431372549ybます R0.0196078431372549ya。 S0.09803921568627451ya私 R0.0196078431372549yb翻訳 R0.0196078431372549yaし R0.0196078431372549yaた R0.0392156862745098yaの R0.0392156862745098yaは R0.0392156862745098ya前 R0.0196078431372549yeバージョン R0.0196078431372549yaで R0.0196078431372549yaす R0.0196078431372549ybまず R0.0196078431372549ya、 R0.0196078431372549yb目次 R0.0196078431372549yaを R0.0392156862745098yb元に R0.0196078431372549yaど R0.0196078431372549ydのくらい R0.0196078431372549yc変わっ R0.0196078431372549ybてる R0.0196078431372549yaか R0.0196078431372549yb見て R0.0196078431372549ycみまし R0.0196078431372549ya（ R0.0196078431372549>vc215<yc可視化 S0.05128205128205128ycツール S0.05128205128205128ye現状確認会 S0.02564102564102564yaに S0.02564102564102564yb参加 S0.02564102564102564yaし S0.05128205128205128yaて S0.07692307692307693ya、 S0.05128205128205128yjカジュアルウォーター S0.02564102564102564yaじ S0.02564102564102564yaゃ S0.02564102564102564ybなく S0.02564102564102564yaの S0.02564102564102564yb現状 S0.02564102564102564yaを S0.02564102564102564yb確認 S0.02564102564102564ycきまし S0.02564102564102564yaた S0.02564102564102564ya。 S0.05128205128205128ya  S0.10256410256410256ycという S0.02564102564102564ybこと S0.02564102564102564yaで S0.02564102564102564ydいつもの S0.02564102564102564ybメモ S0.02564102564102564ybです S0.02564102564102564yhMackerel S0.02564102564102564yaと S0.02564102564102564yhGraphite S0.02564102564102564>vc216<yb今月 T0.037037037037037035yc2回目 T0.037037037037037035yaの R0.1111111111111111yb目黒 T0.037037037037037035yaで T0.037037037037037035ya、 T0.037037037037037035ya初 T0.037037037037037035ydドリコム T0.037037037037037035ybさん T0.037037037037037035ybです T0.037037037037037035ya。 T0.037037037037037035ya  S0.07407407407407407ya「 T0.037037037037037035yb最新 T0.037037037037037035ymインフラエンジニア技術勉強 T0.037037037037037035ya～ S0.07407407407407407ygFluentd T0.037037037037037035ya, S0.07407407407407407ymElasticsearch T0.037037037037037035ydChef T0.037037037037037035yb実践 T0.037037037037037035yb実例 T0.037037037037037035>vc217<ydどうやら S0.03571428571428571ya、 S0.07142857142857142yb中身 S0.03571428571428571yaが S0.03571428571428571ydSolr S0.03571428571428571ycベース S0.07142857142857142ya？ S0.07142857142857142yfLucene S0.03571428571428571yaに S0.03571428571428571ybなっ S0.03571428571428571ydたらしい S0.03571428571428571ycという S0.03571428571428571ybこと S0.03571428571428571yaで S0.03571428571428571ya  S0.07142857142857142yb今日 S0.03571428571428571yaは S0.03571428571428571ya「 S0.03571428571428571ycAWS S0.03571428571428571yiプロダクトシリーズ S0.03571428571428571ya｜ S0.03571428571428571yeよくわかる S0.03571428571428571yfAmazon S0.03571428571428571ybCl S0.03571428571428571>vc218<yb酔っe0.025yb払っe0.025yaてe0.075ybなんe0.025yaとd0.05ybなくe0.025yb書きe0.025ybたくe0.025ybなっd0.05yaたd0.05ygスピリチュアルe0.025yaなd0.05ycブログe0.025yaのe0.025yaでd0.05ya、d0.05yb流しe0.025yaいe0.025ycだけれe0.025yaばe0.025ya。e0.025ya e0.025yb最近e0.025yc勉強会e0.025yaやe0.025ygTwittere0.025yb知りe0.025yb合いe0.025yaにe0.025ya話e0.025yaをe0.025ybするe0.025>vc219<ya「 T0.023809523809523808ymアジャイルデータサイエンス T0.023809523809523808ya」 T0.023809523809523808yaの T0.023809523809523808yb見本 T0.023809523809523808yaを T0.023809523809523808yaい T0.023809523809523808yaた S0.07142857142857142ycだいて T0.023809523809523808yeしまいまし T0.023809523809523808ya。 T0.047619047619047616ya  S0.07142857142857142ybなの T0.023809523809523808yaで S0.07142857142857142ya、 T0.047619047619047616yc感想文 T0.023809523809523808yaも T0.023809523809523808yb書い T0.023809523809523808yaて T0.023809523809523808yaみ T0.023809523809523808ybよう T0.023809523809523808yaか T0.023809523809523808yaと T0.023809523809523808ybどん T0.023809523809523808yaな T0.023809523809523808ya本 T0.023809523809523808ya？ T0.023809523809523808yb想像 T0.023809523809523808yb以上 T0.023809523809523808yaに T0.047619047619047616yc薄かっ T0.023809523809523808yaす T0.023809523809523808yc物理的 T0.023809523809523808>vc220<ybこん S0.01818181818181818yaな S0.01818181818181818ydツイート S0.01818181818181818yaを S0.01818181818181818yc見つけ S0.01818181818181818yaた S0.01818181818181818yaの S0.03636363636363636yaで S0.05454545454545454ya、 S0.01818181818181818ykAggregation S0.01818181818181818ydサンプル S0.01818181818181818yaも S0.01818181818181818yc書こう S0.03636363636363636yaか S0.01818181818181818ybなと S0.01818181818181818ya。 S0.07272727272727272ya（ S0.01818181818181818ya前 S0.01818181818181818ybから S0.01818181818181818yaと S0.01818181818181818yb思っ S0.01818181818181818yaて S0.01818181818181818ybたん S0.01818181818181818yaす S0.01818181818181818yaが S0.01818181818181818ya） S0.01818181818181818ya  S0.18181818181818182ya@ S0.01818181818181818ymelasticsearch S0.01818181818181818ybHi S0.01818181818181818ya, S0.01818181818181818yeWould S0.01818181818181818ycyou S0.01818181818181818yfplease S0.01818181818181818ydtell S0.01818181818181818ybme S0.01818181818181818ycthe S0.01818181818181818ycway S0.01818181818181818ybto S0.01818181818181818>vc221<yb今日 S0.02857142857142857yaは S0.02857142857142857ymelasticsearch S0.02857142857142857ya- S0.02857142857142857ydkopf S0.02857142857142857yaの S0.05714285714285714yhAnalysis S0.02857142857142857yb画面 S0.02857142857142857yb紹介 S0.02857142857142857yaで S0.02857142857142857yaす S0.02857142857142857ya。 S0.11428571428571428ya  S0.05714285714285714ya（ S0.02857142857142857yb簡単 S0.02857142857142857yaな S0.02857142857142857yaと S0.05714285714285714ybころ S0.02857142857142857ybから S0.02857142857142857ybその S0.02857142857142857ya３ S0.02857142857142857ya） S0.02857142857142857ycちょっ S0.02857142857142857ybあい S0.02857142857142857yaだ S0.02857142857142857yaが S0.02857142857142857yb開い S0.02857142857142857yaて S0.02857142857142857yeしまいまし S0.02857142857142857>vc222<ydkopf S0.02857142857142857yaの S0.14285714285714285yb記事 S0.02857142857142857yb続き S0.02857142857142857yaも S0.02857142857142857yb書く S0.02857142857142857yb必要 S0.02857142857142857yaが S0.02857142857142857ybある S0.02857142857142857yaん S0.02857142857142857ycだけど S0.02857142857142857ya、 S0.05714285714285714ybこん S0.02857142857142857yaな S0.02857142857142857ydツイート S0.02857142857142857yaを S0.02857142857142857yd見つけて S0.02857142857142857ycしまっ S0.02857142857142857yaた S0.02857142857142857yaで S0.02857142857142857ya。 S0.08571428571428572ya  S0.05714285714285714ymElasticsearch S0.02857142857142857ydBulk S0.02857142857142857ycAPI S0.02857142857142857yb仕様 S0.02857142857142857yaJ S0.02857142857142857>vc223<yc第4回 T0.030303030303030304yoElsticsearch勉強会 T0.030303030303030304yaを T0.030303030303030304yb開催 T0.030303030303030304yaし T0.030303030303030304ybまし T0.030303030303030304yaた S0.09090909090909091ya。 S0.06060606060606061ya  S0.06060606060606061yb今回 T0.030303030303030304ybから S0.06060606060606061ya、 S0.06060606060606061yd遅刻厳禁 S0.06060606060606061yaに T0.030303030303030304ybして T0.030303030303030304ycみまし T0.030303030303030304ydそれほど T0.030303030303030304yb困っ T0.030303030303030304yc人もい T0.030303030303030304ybない T0.030303030303030304yaと T0.030303030303030304yb思う T0.030303030303030304yaの T0.030303030303030304yaで T0.030303030303030304yb次回 T0.030303030303030304yaも T0.030303030303030304>vc224<yb今日g0.03125yaはg0.03125ymelasticsearchg0.03125ya-g0.03125ydkopfg0.03125yaのg0.09375yhAnalysisg0.03125yb画面g0.03125yb紹介g0.03125yaでg0.03125yaすg0.03125ya。e0.125ya f0.0625ya（g0.03125yb簡単g0.03125yaなg0.03125yaとg0.03125ybころg0.03125ybからg0.03125ybそのg0.03125ya２g0.03125ya）g0.03125ydメニューg0.03125yhanalysisg0.03125yaをg0.03125yb選択g0.03125>vc225<ycJVM T0.020833333333333332ya  S0.10416666666666667yiOperation T0.020833333333333332yfCasual T0.020833333333333332yeTalks T0.020833333333333332yaに T0.020833333333333332yb参加 T0.020833333333333332yaし T0.020833333333333332ybまし T0.020833333333333332yaた T0.041666666666666664ya。 T0.041666666666666664ydあんまり T0.020833333333333332ya、f0.0625yb運用 T0.020833333333333332yaと T0.020833333333333332ycかやっ T0.020833333333333332yaてf0.0625ybない T0.020833333333333332yaの T0.041666666666666664yaでf0.0625ybつい T0.020833333333333332ycいける T0.020833333333333332yaか T0.020833333333333332yb不安 T0.020833333333333332yaす T0.020833333333333332yaが T0.020833333333333332yb楽し T0.020833333333333332ybそう T0.020833333333333332ybだっ T0.020833333333333332yc懇親会 T0.020833333333333332yaは T0.020833333333333332yb予定 T0.020833333333333332yaさ T0.020833333333333332yaれ T0.020833333333333332yeないらしい T0.020833333333333332>vc226<yb今日 S0.02631578947368421yaは S0.02631578947368421ymelasticsearch S0.02631578947368421ya- S0.02631578947368421ydkopf S0.02631578947368421yaの S0.10526315789473684ydREST S0.02631578947368421yb画面 S0.05263157894736842yb紹介 S0.02631578947368421yaで S0.02631578947368421yaす S0.02631578947368421ya。 S0.10526315789473684ya  S0.05263157894736842ya（ S0.02631578947368421yb簡単 S0.02631578947368421yaな S0.05263157894736842yaと S0.05263157894736842ybころ S0.02631578947368421ybから S0.02631578947368421ya） S0.02631578947368421ydメニュー S0.02631578947368421ydrest S0.02631578947368421yaを S0.02631578947368421yb選択 S0.02631578947368421ybする S0.02631578947368421ya、 S0.02631578947368421ya次 S0.02631578947368421ybよう S0.02631578947368421>vc227<ybなん S0.02631578947368421ybだか S0.02631578947368421ya、 S0.05263157894736842ydドタバタ S0.02631578947368421ybして S0.02631578947368421yaて S0.02631578947368421yb久し S0.02631578947368421ybぶり S0.02631578947368421yaの S0.10526315789473684yb更新 S0.02631578947368421yaで S0.05263157894736842yaす S0.05263157894736842ya。 S0.05263157894736842ya  S0.05263157894736842ydベルリン S0.02631578947368421yc旅行記 S0.02631578947368421yaみ S0.02631578947368421ybたい S0.05263157894736842yaな S0.02631578947368421yaも S0.02631578947368421yb書き S0.02631578947368421yaが S0.02631578947368421ybまず S0.02631578947368421yaは S0.02631578947368421ydこちらか S0.02631578947368421yaと S0.02631578947368421ymelasticsearch S0.02631578947368421ya- S0.02631578947368421ybko S0.02631578947368421>vc228<yb先日 S0.02857142857142857ya、 S0.05714285714285714ya「 S0.02857142857142857ymElasticSearch S0.02857142857142857ya  S0.05714285714285714yfServer S0.02857142857142857yaを S0.05714285714285714yb翻訳 S0.02857142857142857yaし S0.02857142857142857ybまし S0.02857142857142857yaた S0.08571428571428572ya」 S0.02857142857142857ycという S0.02857142857142857yb記事 S0.02857142857142857yd書きまし S0.02857142857142857ya。 S0.02857142857142857ybこの S0.02857142857142857ya中 S0.02857142857142857yaで S0.02857142857142857yc電子版 S0.05714285714285714yaも S0.05714285714285714yd出ますよ S0.02857142857142857yaと S0.02857142857142857yb書い S0.02857142857142857yaて S0.02857142857142857ycいまし S0.02857142857142857yaが S0.02857142857142857ya発 S0.02857142857142857>vc229<ydGOTO S0.02564102564102564ya  S0.10256410256410256yeNight S0.02564102564102564ymelasticsearch S0.02564102564102564yaに S0.05128205128205128yb参加 S0.02564102564102564yaし S0.05128205128205128ybまし S0.02564102564102564yaた S0.05128205128205128ya。 S0.05128205128205128ya初 S0.02564102564102564yaの S0.05128205128205128yb海外 S0.02564102564102564yc勉強会 S0.05128205128205128yaで S0.05128205128205128yaす S0.02564102564102564ya（ S0.02564102564102564yd海外自体 S0.02564102564102564yaが S0.02564102564102564yb初だ S0.02564102564102564ya） S0.02564102564102564ydベルリン S0.02564102564102564ybある S0.02564102564102564yeWooga S0.02564102564102564ycという S0.02564102564102564yb会社 S0.02564102564102564yb開催 S0.02564102564102564yaさ S0.02564102564102564yaれ S0.02564102564102564>vc230<yfBerlind0.05ycからおe0.025yaはe0.025ybようd0.05yeございますe0.025ya。d0.05ya d0.05ycというe0.025ybことe0.025yaでe0.075ya、d0.05yb人生e0.025yb初めe0.025yaてd0.05yaのe0.075yb海外d0.05yaにd0.05ya来e0.025yaいe0.025ybますe0.025yc人生初e0.025yaなd0.05yb一人e0.025yb乗りe0.025yb換えe0.025yaがe0.025ybあるe0.025>vc231<yb10 T0.043478260869565216ymelasticsearch S0.08695652173913043yaに S0.08695652173913043ya、 T0.043478260869565216ybこの T0.043478260869565216ybへん T0.043478260869565216yc入れる T0.043478260869565216ycときっ T0.043478260869565216yaと T0.043478260869565216yb幸せ T0.043478260869565216ycなれる T0.043478260869565216yaは T0.043478260869565216yaず T0.043478260869565216ya・ T0.043478260869565216ycたぶん T0.043478260869565216ya。 T0.043478260869565216ya& T0.043478260869565216ya# T0.043478260869565216ya; T0.043478260869565216ya/ T0.043478260869565216ylelasticsearc T0.043478260869565216>vc232<yc第3回 T0.041666666666666664y PElasticsearch勉強会 T0.041666666666666664yaで T0.041666666666666664ya、 S0.08333333333333333yb軽く T0.041666666666666664yb触れ T0.041666666666666664yaて T0.041666666666666664ycいまし T0.041666666666666664yaた T0.041666666666666664yaが S0.08333333333333333ymElasticSearch T0.041666666666666664ya  S0.08333333333333333yjServer日本語版 T0.041666666666666664yb発売 T0.041666666666666664yaさ T0.041666666666666664yaれ T0.041666666666666664ybます T0.041666666666666664ya。 T0.041666666666666664ydツイート T0.041666666666666664ybなど T0.041666666666666664yaも T0.041666666666666664>vc233<yc今年初 T0.029411764705882353yaの S0.08823529411764706ya「 T0.029411764705882353yb突撃 T0.029411764705882353ya！ T0.029411764705882353ya隣 T0.029411764705882353ymElasticsearch T0.029411764705882353ya」 T0.029411764705882353ycという T0.029411764705882353ybこと T0.029411764705882353yaで S0.08823529411764706ya、 T0.058823529411764705yhWantedly T0.029411764705882353ybさん T0.029411764705882353yhにおじゃましまし T0.029411764705882353yaた T0.058823529411764705ya。 T0.029411764705882353ya  T0.029411764705882353ya※ T0.029411764705882353yb写真 T0.029411764705882353yaを T0.029411764705882353yb自分 T0.029411764705882353yaも T0.029411764705882353yb撮っ T0.029411764705882353yaす T0.029411764705882353yaが T0.058823529411764705yb画像 T0.029411764705882353>vc234<yb今回 T0.027777777777777776yaは T0.027777777777777776ydたまたま T0.027777777777777776yb日本 T0.027777777777777776yaに S0.05555555555555555yaい T0.027777777777777776yaた S0.05555555555555555ymElasticsearch T0.027777777777777776yaの S0.08333333333333333ya人 T0.027777777777777776yaを T0.027777777777777776yhスペシャルゲスト T0.027777777777777776yb呼べ T0.027777777777777776yaで S0.05555555555555555ya、 T0.027777777777777776yc大満足 T0.027777777777777776yaす T0.027777777777777776yaｗ T0.027777777777777776ya  T0.027777777777777776yb英語 T0.027777777777777776yb通訳 T0.027777777777777776yaと S0.08333333333333333ydかちゃん T0.027777777777777776yb勉強 T0.027777777777777776yaし T0.027777777777777776ybない T0.027777777777777776ybなぁ T0.027777777777777776ya。 S0.05555555555555555>vc235<yfすずけんさん T0.037037037037037035yaが T0.037037037037037035ygVagrant T0.037037037037037035ya+ T0.037037037037037035yipuppet使って T0.037037037037037035ya、 S0.07407407407407407ybVM T0.037037037037037035yb起動 T0.037037037037037035yaし T0.037037037037037035yaて R0.1111111111111111ymElasticsearch T0.037037037037037035yaの S0.07407407407407407ydクラスタ T0.037037037037037035yaを R0.1111111111111111yb組ん T0.037037037037037035ybでる T0.037037037037037035yb記事 T0.037037037037037035yb書い T0.037037037037037035ybいる T0.037037037037037035yb見て T0.037037037037037035yb試し T0.037037037037037035>vc236<yd改訂新版 T0.029411764705882353ydSolr S0.08823529411764706yf入門出版記念 T0.029411764705882353yaと T0.029411764705882353ybいう T0.029411764705882353ybこと T0.029411764705882353yaで T0.058823529411764705ya、 S0.08823529411764706yd第13回 T0.029411764705882353yc勉強会 T0.029411764705882353ya  S0.08823529411764706ya# T0.029411764705882353yfSolrJP T0.029411764705882353ya新 T0.029411764705882353ye本出版記念 T0.029411764705882353yaを T0.029411764705882353yb開催 T0.029411764705882353yaし T0.029411764705882353ybまし T0.029411764705882353yaた T0.029411764705882353ya。 T0.029411764705882353yd出版記念 T0.029411764705882353yaな T0.029411764705882353yaの T0.029411764705882353yf技術評論社様 T0.029411764705882353ybより T0.029411764705882353ybプレ T0.029411764705882353>vc237<yb昨晩 S0.03225806451612903ya、 R0.0967741935483871ymElasticsearch S0.03225806451612903ybから S0.03225806451612903ya初 S0.03225806451612903yaの S0.03225806451612903yeプロダクト S0.03225806451612903yaと S0.06451612903225806ybなる S0.03225806451612903yfMarvel S0.03225806451612903yaが S0.03225806451612903ydリリース S0.03225806451612903yaさ S0.03225806451612903yaれ S0.03225806451612903ybまし S0.03225806451612903yaた S0.03225806451612903ya。 S0.03225806451612903ycという S0.03225806451612903ybこと S0.03225806451612903yaで S0.03225806451612903ydさっそく S0.03225806451612903yb触っ S0.03225806451612903yaて S0.03225806451612903ybみて S0.03225806451612903yb簡単 S0.03225806451612903yaな S0.03225806451612903yb紹介 S0.03225806451612903yb感想 S0.03225806451612903>vc238<ya1 S0.02564102564102564ya4 S0.05128205128205128ya6 S0.05128205128205128yfLucene S0.02564102564102564ya/ S0.02564102564102564ydSolr S0.02564102564102564ya  S0.05128205128205128ya. S0.10256410256410256yaが S0.02564102564102564ydリリース S0.05128205128205128yaさ S0.02564102564102564yaれ S0.02564102564102564ybそう S0.02564102564102564ya( S0.02564102564102564ydバイナリ S0.02564102564102564yc配布待 S0.02564102564102564yaち S0.02564102564102564ya) S0.02564102564102564yflucene S0.02564102564102564ya- S0.02564102564102564yegosen S0.02564102564102564yaの S0.05128205128205128yb1対 S0.02564102564102564yb応版 S0.02564102564102564yaを S0.02564102564102564ycしまし S0.02564102564102564yaた S0.02564102564102564ya。 S0.02564102564102564yeライブラリ S0.02564102564102564ygインタフェース S0.02564102564102564yaな S0.02564102564102564>vc239<ymElasticsearchd0.04yaのd0.08ygcuratord0.04ycブログd0.04yb記事d0.04yaをd0.04yb読んd0.04yaでd0.08ya、d0.08yc日本語d0.08ydツイートd0.04yaしd0.04yaたd0.04yaとd0.04ybころd0.04yeAarond0.04ya d0.04ykMildensteind0.04ybさんd0.04ybからd0.04ya（d0.04>vc240<ydあけまし T0.034482758620689655yaて S0.06896551724137931ybおめ T0.034482758620689655yaで S0.06896551724137931ygとうございます T0.034482758620689655ya。 S0.06896551724137931yb今年 T0.034482758620689655yaも T0.034482758620689655ydSolr T0.034482758620689655yaや T0.034482758620689655ymElasticsearch T0.034482758620689655ydについて T0.034482758620689655yb色々 T0.034482758620689655yaと T0.034482758620689655yc頑張っ T0.034482758620689655ybいく T0.034482758620689655yb所存 T0.034482758620689655yaす T0.034482758620689655ya  T0.034482758620689655ycとまぁ T0.034482758620689655ya、 T0.034482758620689655ydお決まり T0.034482758620689655yaの T0.034482758620689655yb挨拶 T0.034482758620689655yaは T0.034482758620689655ycおいて T0.034482758620689655>vc241<yb昨年 T0.022727272727272728yaは T0.045454545454545456ya、 T0.045454545454545456yc大晦日 T0.022727272727272728yaに T0.045454545454545456yb書い T0.045454545454545456yaて T0.022727272727272728ybまし T0.022727272727272728yaた S0.09090909090909091ya。 T0.045454545454545456ya  S0.06818181818181818ycちょっ T0.022727272727272728yaと T0.022727272727272728yb進歩 T0.022727272727272728yaし T0.022727272727272728ybかも T0.022727272727272728yb振り T0.045454545454545456yb返り T0.045454545454545456ya( T0.022727272727272728ye2012年 T0.022727272727272728yb抱負 T0.045454545454545456ybから T0.045454545454545456ya) T0.022727272727272728ycという T0.022727272727272728ybこと T0.022727272727272728yaで T0.045454545454545456ybまず T0.022727272727272728yd昨年書い T0.022727272727272728yaの T0.022727272727272728>vc242<ya0 S0.05405405405405406ya8 S0.05405405405405406yb90 S0.05405405405405406yb昨夜 S0.02702702702702703ya、 S0.05405405405405406ymElasticsearch S0.02702702702702703yaの S0.05405405405405406ya. S0.10810810810810811yaが S0.02702702702702703ydリリース S0.05405405405405406yaさ S0.05405405405405406yaれ S0.05405405405405406ybまし S0.02702702702702703yaた S0.05405405405405406ya。 S0.02702702702702703ya  S0.05405405405405406yb内容 S0.02702702702702703ybなど S0.02702702702702703ydについて S0.02702702702702703yaは S0.02702702702702703yb本家 S0.02702702702702703ycブログ S0.02702702702702703ya「 S0.02702702702702703yfreleas S0.02702702702702703>vc243<ydSolr S0.02564102564102564ya本 S0.02564102564102564yaが S0.02564102564102564yb出て S0.02564102564102564ybから S0.02564102564102564ya、 S0.02564102564102564yb質問 S0.05128205128205128yaを S0.07692307692307693yb受け S0.05128205128205128yaて S0.05128205128205128ycブログ S0.02564102564102564yb書く S0.02564102564102564yaと S0.02564102564102564yb言い S0.02564102564102564ybなが S0.02564102564102564yaら S0.02564102564102564yb書い S0.02564102564102564ycなかっ S0.02564102564102564yaた S0.05128205128205128ybこと S0.02564102564102564yb思い S0.02564102564102564yd出しまし S0.02564102564102564ya。 S0.07692307692307693ya  S0.02564102564102564yeプラグイン S0.02564102564102564yaの S0.02564102564102564yb配置 S0.02564102564102564yb方法 S0.02564102564102564ydについて S0.02564102564102564ybこん S0.02564102564102564yaな S0.02564102564102564>vc244<ybどもg0.03125ya。g0.03125ya g0.09375yeプラグインg0.03125yaのf0.0625yfインストールg0.03125yaにg0.03125yb長いg0.03125ycURLg0.03125ya入g0.03125ybれるg0.03125yb辛いg0.03125yaでg0.09375ycすよねg0.03125ya？f0.0625yaねg0.03125ycというg0.03125ybことg0.03125ya、g0.03125yeMavenf0.0625ydリリースg0.03125yaしg0.03125yaてg0.03125yjRepositoryg0.03125ybからg0.03125>vc245<yb12 T0.023809523809523808yb少し T0.023809523809523808yb遅く T0.023809523809523808ybなっ T0.023809523809523808yaて T0.023809523809523808yeしまいまし T0.023809523809523808yaた T0.047619047619047616yaが T0.023809523809523808ya、 T0.023809523809523808ya/ T0.023809523809523808yb05 T0.023809523809523808yaに T0.023809523809523808yb電子 T0.047619047619047616yb書籍 S0.07142857142857142yaも T0.023809523809523808yb発売 T0.023809523809523808yaさ T0.023809523809523808yaれ T0.023809523809523808ybまし T0.023809523809523808ya。 T0.047619047619047616ya  S0.07142857142857142ye技術評論社 T0.023809523809523808yaの S0.07142857142857142ycサイト T0.023809523809523808ybから T0.023809523809523808yb購入 T0.023809523809523808yb可能 T0.023809523809523808yaで T0.023809523809523808yaす T0.023809523809523808ycページ T0.023809523809523808yaへ T0.023809523809523808ycリンク T0.023809523809523808ycPDF T0.023809523809523808>vc246<yc勉強会 T0.047619047619047616yaで T0.047619047619047616yb宣伝 T0.023809523809523808yaも T0.047619047619047616ycしまし T0.023809523809523808yaた T0.047619047619047616yaが T0.023809523809523808ya、 S0.07142857142857142yc改めて T0.023809523809523808ya。 S0.07142857142857142ya  S0.07142857142857142ydSolr S0.07142857142857142yb入門 T0.047619047619047616yaの T0.023809523809523808yc改訂版 T0.023809523809523808yaを T0.023809523809523808yb執筆 T0.023809523809523808yaし T0.023809523809523808ybまし T0.023809523809523808yb考え T0.023809523809523808yaて T0.023809523809523808ybみれ T0.023809523809523808yaば T0.023809523809523808ybもう T0.023809523809523808yb3年 T0.023809523809523808yc前なん T0.023809523809523808ybすね T0.023809523809523808yaは T0.023809523809523808yaな T0.023809523809523808>vc247<ybどー T0.029411764705882353yaも T0.029411764705882353ya。 T0.058823529411764705yb以前 T0.029411764705882353yaの T0.029411764705882353yb記事 T0.029411764705882353yaで S0.08823529411764706yb開発 T0.029411764705882353ya中 T0.029411764705882353ybとし T0.029411764705882353yaて T0.029411764705882353yaい T0.029411764705882353yaた T0.058823529411764705yeプラグイン T0.029411764705882353yaす T0.029411764705882353yaが T0.029411764705882353ya、 T0.058823529411764705ybとり T0.029411764705882353ycあえず T0.029411764705882353yfplugin T0.029411764705882353ydコマンド T0.029411764705882353yfインストール T0.058823529411764705yc出来る T0.029411764705882353yb形に T0.029411764705882353ybして T0.029411764705882353ycみまし T0.029411764705882353ya  T0.029411764705882353ybなど T0.029411764705882353>vc248<yc第2回 S0.02631578947368421yaを S0.05263157894736842yb開催 S0.02631578947368421yaし S0.05263157894736842ybまし S0.02631578947368421yaた S0.05263157894736842ya！ S0.05263157894736842ya  S0.05263157894736842ycすごい S0.02631578947368421ya、 S0.05263157894736842yj140人くらいくらい S0.02631578947368421yaの S0.02631578947368421ye参加登録者 S0.02631578947368421ya（ S0.02631578947368421yc参加者 S0.02631578947368421yaは S0.02631578947368421yd１００人 S0.02631578947368421yaち S0.02631578947368421ybょっ S0.02631578947368421yaと S0.02631578947368421ya） S0.02631578947368421ycがいて S0.02631578947368421ydびっくり S0.02631578947368421yaで S0.02631578947368421yaす S0.02631578947368421ya。 S0.02631578947368421ycステキ S0.02631578947368421yaな S0.02631578947368421yb会場 S0.02631578947368421yb提供 S0.02631578947368421yaて S0.02631578947368421yaい S0.02631578947368421>vc249<yd2013 T0.019230769230769232yhCloudera T0.019230769230769232ya  S0.09615384615384616yeWorld T0.019230769230769232yeTokyo T0.019230769230769232yaに T0.019230769230769232yb参加 T0.057692307692307696yaし T0.057692307692307696yaて T0.038461538461538464ycきまし T0.019230769230769232yaた S0.07692307692307693ya。 T0.038461538461538464yc午前中 T0.019230769230769232yaは T0.019230769230769232ybあい T0.019230769230769232ybにく T0.019230769230769232yaの T0.038461538461538464ya雨 T0.019230769230769232yaで T0.038461538461538464yaが T0.057692307692307696ya、 T0.019230769230769232ybそれ T0.019230769230769232yaも T0.019230769230769232yb結構 T0.019230769230769232yaな T0.019230769230769232yb人数 T0.019230769230769232yb最初 T0.019230769230769232yb基調 T0.019230769230769232yb講演 T0.019230769230769232ybから T0.019230769230769232yaさ T0.019230769230769232yaれ T0.019230769230769232ybまし T0.019230769230769232ya私 T0.019230769230769232ydセッショ T0.019230769230769232>vc250<ya0 T0.022727272727272728ya2 T0.022727272727272728ya3 T0.022727272727272728ydまたまた T0.022727272727272728ya、 T0.045454545454545456ydRiak T0.045454545454545456ya  S0.09090909090909091yfMeetup T0.022727272727272728yeTokyo T0.022727272727272728ya# T0.022727272727272728yaに T0.045454545454545456yb参加 T0.022727272727272728yaし T0.022727272727272728yaて T0.022727272727272728ycきまし T0.022727272727272728yaた T0.045454545454545456ya。 T0.045454545454545456ya. T0.022727272727272728yaの S0.06818181818181818yhYokozuna T0.022727272727272728ya話 T0.022727272727272728yaが T0.022727272727272728ybある T0.022727272727272728yaと T0.022727272727272728yb聞い T0.022727272727272728yaで S0.06818181818181818ycという T0.022727272727272728ybこと T0.022727272727272728ydいつもの T0.022727272727272728ybよう T0.022727272727272728yb個人 T0.022727272727272728ybメモ T0.022727272727272728>vc251<yc開発中 S0.02857142857142857yaで S0.08571428571428572yaす S0.08571428571428572yaと S0.08571428571428572yd書きまし S0.02857142857142857yaた S0.05714285714285714ya、 S0.05714285714285714ymelasticsearch S0.02857142857142857ya- S0.05714285714285714yhextended S0.02857142857142857yganalyze S0.02857142857142857yaが S0.02857142857142857yb改良 S0.05714285714285714yaし S0.02857142857142857ybまし S0.02857142857142857ya。 S0.05714285714285714ya  S0.05714285714285714yb変更 S0.02857142857142857yaは S0.02857142857142857yb以下 S0.02857142857142857yaの S0.02857142857142857ybおり S0.02857142857142857ybソー S0.02857142857142857>vc252<yeお久しぶり S0.02857142857142857yaで S0.05714285714285714yaす S0.05714285714285714ya。 S0.11428571428571428ya  S0.05714285714285714yc気づい S0.02857142857142857ydたらまた S0.02857142857142857ya、 S0.05714285714285714yb結構 S0.02857142857142857ycブログ S0.02857142857142857yaを S0.02857142857142857yb書い S0.02857142857142857yaて S0.05714285714285714ycなかっ S0.02857142857142857yaた S0.02857142857142857yb今回 S0.02857142857142857yaは S0.02857142857142857yc今開発 S0.02857142857142857yaし S0.02857142857142857ybいる S0.02857142857142857ymElasticsearch S0.02857142857142857yaの S0.02857142857142857yeプラグイン S0.02857142857142857yaに S0.02857142857142857yc関する S0.02857142857142857yaお S0.02857142857142857ya話 S0.02857142857142857>vc253<ye不定期開催e0.025yaでe0.075yaすd0.05yaがe0.075ya第e0.025yc12回e0.025ydSolre0.025yc勉強会e0.025yaをe0.025yb主催e0.025yaしe0.025ybましe0.025yaたd0.05ya。e0.025ya e0.025yb今回e0.025yaはd0.05ya、d0.05yb前回e0.025ybほどd0.05yaのe0.075yb過熱e0.025ybぶりe0.025yc無かっe0.025yc70人e0.025yc参加者e0.025ya方e0.025yfいらっしゃっe0.025ybたかe0.025>vc254<yb今日d0.05yaはd0.05ya、d0.05ymElasticSearchd0.05yaのc0.1ybMLd0.05yaでc0.1yc見つけd0.05yaたd0.05ymelasticsearchd0.05ya-d0.05yjinquisitord0.05yeプラグインd0.05yb紹介d0.05yaすd0.05ya。d0.05ya d0.05yjElasticSead0.05>vc255<yeriver S0.02857142857142857ya- S0.02857142857142857yiwikipedia S0.02857142857142857yaの S0.08571428571428572yc前々回 S0.02857142857142857yb記事 S0.02857142857142857yaで S0.02857142857142857yd書きまし S0.02857142857142857yaた S0.02857142857142857yaが S0.11428571428571428ya、 S0.02857142857142857ydbulk S0.02857142857142857ya_ S0.02857142857142857ydsize S0.02857142857142857yaに S0.05714285714285714yb関連 S0.02857142857142857yaし S0.02857142857142857yaて S0.05714285714285714yb登録 S0.02857142857142857yb件数 S0.02857142857142857ybやけ S0.02857142857142857ycにきり S0.02857142857142857yb良い S0.02857142857142857ya気 S0.02857142857142857ybなる S0.02857142857142857yaと S0.02857142857142857yb書い S0.02857142857142857ycいまし S0.02857142857142857>vc256<ye前々回紹介 S0.03333333333333333yaし S0.06666666666666667yaた S0.03333333333333333ya、 S0.06666666666666667yc日本語 S0.03333333333333333yiWikipedia S0.03333333333333333yaのc0.1ycデータ S0.03333333333333333yaを S0.06666666666666667yfインデックス S0.03333333333333333yb登録 S0.03333333333333333ybする S0.03333333333333333yb記事 S0.03333333333333333yb続き S0.03333333333333333yaで S0.03333333333333333yaす S0.03333333333333333ya。 S0.03333333333333333ya  S0.03333333333333333yb今回 S0.03333333333333333yaは S0.03333333333333333yhKuromoji S0.03333333333333333yeアナライザ S0.03333333333333333yb利用 S0.03333333333333333yaて S0.03333333333333333ydインデッ S0.03333333333333333>vc257<y PElasticSearch勉強会 T0.037037037037037035ya  R0.1111111111111111ya第 T0.037037037037037035yb1回 T0.037037037037037035yaを T0.037037037037037035yb主催 T0.037037037037037035yaし T0.037037037037037035ybまし T0.037037037037037035yaた S0.07407407407407407ya。 S0.07407407407407407yb昨年 T0.037037037037037035yaの T0.037037037037037035yepyfes T0.037037037037037035yaで S0.07407407407407407yfなんちゃって T0.037037037037037035yb資料 T0.037037037037037035yb喋っ T0.037037037037037035yaて T0.037037037037037035ya、 T0.037037037037037035yb1年 T0.037037037037037035ydたちまし T0.037037037037037035ymElasticSearch T0.037037037037037035>vc258<yb久々 S0.03225806451612903yaの S0.06451612903225806ycブログ S0.03225806451612903yaは S0.03225806451612903yoElasticSearchネタ S0.03225806451612903ybです S0.03225806451612903ya。 S0.06451612903225806ye勉強会開催 S0.03225806451612903ybする S0.06451612903225806yb予定 S0.03225806451612903ybだっ S0.03225806451612903ycたりす S0.03225806451612903yaで S0.03225806451612903ya、 S0.03225806451612903ybもう S0.03225806451612903yb少し S0.03225806451612903yb触っ S0.03225806451612903yaて S0.03225806451612903ybおき S0.03225806451612903ybたい S0.03225806451612903ybなと S0.03225806451612903ya  S0.03225806451612903yaお S0.03225806451612903yb手軽 S0.03225806451612903yaに S0.03225806451612903yb検索 S0.03225806451612903ycデータ S0.03225806451612903ycとして S0.03225806451612903>vc259<ya2 S0.02857142857142857yb宿題 S0.02857142857142857ybその S0.02857142857142857ya？ S0.05714285714285714yaか S0.02857142857142857yaな S0.02857142857142857ya。 S0.02857142857142857ydSolr S0.02857142857142857yc勉強会 S0.02857142857142857yaで S0.02857142857142857yhCloudera S0.02857142857142857ya  S0.05714285714285714yfSearch S0.02857142857142857yaの S0.05714285714285714ydスキーマ S0.02857142857142857yc周りっ S0.02857142857142857yaて S0.08571428571428572ybどう S0.02857142857142857ybなっ S0.05714285714285714ybてる S0.02857142857142857ycという S0.02857142857142857yb質問 S0.02857142857142857yaが S0.02857142857142857yb出て S0.02857142857142857ya、 S0.02857142857142857ycなんか S0.02857142857142857yc調べる S0.02857142857142857ybこと S0.02857142857142857yaに S0.02857142857142857>vc260<yd今朝起き S0.02564102564102564ybたら S0.02564102564102564ya、 S0.05128205128205128yfXperia S0.02564102564102564ya  S0.05128205128205128yaZ S0.02564102564102564yaが S0.02564102564102564yb故障 S0.02564102564102564yaし S0.02564102564102564yaて S0.05128205128205128yeしまいまし S0.02564102564102564yaた S0.02564102564102564ya。 R0.1282051282051282yb電源 S0.02564102564102564ycボタン S0.02564102564102564yaを S0.02564102564102564yb押し S0.02564102564102564yaも S0.05128205128205128ydスリープ S0.05128205128205128yaに S0.02564102564102564ybなら S0.02564102564102564ycないん S0.02564102564102564yaで S0.02564102564102564yaす S0.02564102564102564ycしかも S0.02564102564102564ybから S0.02564102564102564yaの S0.02564102564102564yb復帰 S0.02564102564102564ybでき S0.02564102564102564ybない S0.02564102564102564>vc261<yjMorphlines T0.027777777777777776ydについて T0.027777777777777776ycちょっ S0.05555555555555555yaと S0.08333333333333333ybだけ T0.027777777777777776ya、 S0.05555555555555555ybさら T0.027777777777777776yaに T0.027777777777777776yd調べまし T0.027777777777777776yaた S0.05555555555555555ya。 T0.027777777777777776ya  S0.05555555555555555yb誤解 S0.05555555555555555ydSolr T0.027777777777777776yc勉強会 T0.027777777777777776yaで S0.05555555555555555ybなん T0.027777777777777776ybなく T0.027777777777777776ya私 T0.027777777777777776yaの T0.027777777777777776yb認識 T0.027777777777777776yaを T0.027777777777777776yd話しまし T0.027777777777777776yaが T0.027777777777777776yaし T0.027777777777777776yaて T0.027777777777777776ybたみ T0.027777777777777776ybたい T0.027777777777777776>vc262<ye不定期開催 T0.029411764705882353yaで T0.029411764705882353yaす T0.029411764705882353yaが T0.058823529411764705ya第 T0.029411764705882353yc11回 T0.029411764705882353ydSolr T0.029411764705882353yc勉強会 T0.029411764705882353yaを T0.029411764705882353yb主催 T0.029411764705882353yaし T0.029411764705882353ybまし T0.029411764705882353yaた T0.058823529411764705ya。 T0.058823529411764705ya  T0.029411764705882353yb今回 T0.029411764705882353yaも T0.029411764705882353yc大入り T0.029411764705882353yf90人くらい T0.029411764705882353ya？ T0.029411764705882353yaの T0.058823529411764705yc参加者 T0.029411764705882353yc皆さん T0.029411764705882353yiがいらっしゃいまし T0.029411764705882353ybあり T0.029411764705882353ybたい T0.029411764705882353ybこと T0.029411764705882353ybです T0.029411764705882353ya！ T0.029411764705882353ya（ T0.029411764705882353>vc263<yfHadoop S0.02702702702702703ybとか S0.02702702702702703yb離れ S0.02702702702702703ycちゃっ S0.02702702702702703ybてる S0.02702702702702703yaし S0.05405405405405406ya、 S0.02702702702702703ydHive S0.02702702702702703yb触っ S0.02702702702702703yaた S0.05405405405405406ybこと S0.02702702702702703yb無い S0.02702702702702703yaに S0.02702702702702703yfもかかわらず S0.02702702702702703yb参加 S0.02702702702702703ybまし S0.02702702702702703ya！ S0.02702702702702703ya  S0.05405405405405406ya（ S0.02702702702702703ydたまたま S0.02702702702702703yb近く S0.02702702702702703ycにいる S0.02702702702702703ycからっ S0.02702702702702703yaて S0.02702702702702703yb理由 S0.02702702702702703yaな S0.02702702702702703yaの S0.05405405405405406yaは S0.02702702702702703yb内緒 S0.02702702702702703yaで S0.02702702702702703ya） S0.02702702702702703yb玉川 S0.02702702702702703ybさん S0.02702702702702703>vc264<yhYokozuna S0.02702702702702703yaの S0.05405405405405406ya気 S0.02702702702702703yaに S0.08108108108108109ybなる S0.02702702702702703ya点 S0.02702702702702703ydというか S0.02702702702702703ya、 S0.05405405405405406yb自分 S0.02702702702702703ybだっ S0.02702702702702703ybたら S0.02702702702702703ybこの S0.02702702702702703ybへん S0.02702702702702703yc調べる S0.05405405405405406ycだろう S0.02702702702702703ybなっ S0.02702702702702703yaて S0.05405405405405406yb観点 S0.02702702702702703yaを S0.02702702702702703yb上げ S0.02702702702702703ycみます S0.02702702702702703ya。 S0.02702702702702703ya  S0.02702702702702703ya別 S0.02702702702702703ydわけじゃ S0.02702702702702703ybない S0.02702702702702703yaで S0.02702702702702703yb完全 S0.02702702702702703yb自己 S0.02702702702702703yb満足 S0.02702702702702703yaな S0.02702702702702703>vc265<ya2 T0.023809523809523808yb先日 T0.023809523809523808ya、 T0.047619047619047616yeBasho T0.023809523809523808ybさん T0.023809523809523808yfにおじゃまし T0.023809523809523808yaた S0.07142857142857142yaの T0.047619047619047616yaも S0.07142857142857142ybあり T0.023809523809523808ydRiak T0.023809523809523808ya  S0.11904761904761904yfMeetup T0.023809523809523808yeTokyo T0.023809523809523808ya# T0.023809523809523808yaに T0.023809523809523808yb参加 T0.047619047619047616yaし T0.047619047619047616ybまし T0.047619047619047616ya。 S0.07142857142857142yhYokozuna T0.023809523809523808ya話 T0.023809523809523808yc聞ける T0.023809523809523808ycという T0.023809523809523808ybこと T0.023809523809523808yaで T0.023809523809523808yc懇親会 T0.023809523809523808>vc266<ya4d0.05yd4897e0.025ydSolre0.025ya d0.05ya.e0.025yaにd0.05yf取り込まれるe0.025yb予定e0.025yaのd0.05ydチケットd0.05yaでe0.025ya、e0.025ya気e0.025ybなるd0.05ybものd0.05yaをe0.025yc見つけe0.025yaたd0.05ycでいつe0.025yaごe0.025ybとくe0.025yb調べe0.025yaてe0.025ycみましe0.025ya。d0.05ya元e0.025yaとe0.025yaはe0.025ycこちらe0.025ydSOLRe0.025ya-e0.025>vc267<ydSolr T0.023255813953488372yaの T0.046511627906976744ydチケット S0.06976744186046512yaを T0.046511627906976744ybML T0.023255813953488372yb経由 T0.023255813953488372yaで S0.09302325581395349yb眺め T0.023255813953488372ybてる T0.046511627906976744yaん T0.023255813953488372yaす T0.023255813953488372yaが T0.046511627906976744ya、 T0.023255813953488372yb便利 T0.023255813953488372ybそう T0.023255813953488372yaな T0.023255813953488372yb流れ T0.023255813953488372yaて T0.046511627906976744yaき T0.023255813953488372yaた T0.023255813953488372ycブログ T0.023255813953488372yb書い T0.023255813953488372ybみみ T0.023255813953488372ybよう T0.023255813953488372yaか T0.023255813953488372yaと T0.023255813953488372ya。 T0.023255813953488372ya  T0.023255813953488372ya元 T0.023255813953488372yaに T0.023255813953488372ybなっ T0.023255813953488372yaは T0.023255813953488372ycこちら T0.023255813953488372>vc268<ya3 T0.023255813953488372yb前回 T0.046511627906976744yaは S0.09302325581395349yc3番煎 T0.023255813953488372yaじ T0.023255813953488372ycぐらい T0.023255813953488372yaで T0.046511627906976744yaし T0.023255813953488372yaた T0.046511627906976744yaが T0.023255813953488372ya、 T0.046511627906976744yb今回 T0.023255813953488372yc初記事 T0.023255813953488372yaか T0.023255813953488372yaな T0.046511627906976744ya？ T0.023255813953488372ya（ T0.023255813953488372yaだ T0.023255813953488372ycといい T0.023255813953488372ya） T0.023255813953488372ya  T0.023255813953488372yfKibana T0.046511627906976744yaに T0.046511627906976744yaの S0.06976744186046512yb記事 T0.023255813953488372yb書い T0.023255813953488372ybもの T0.023255813953488372yaと T0.023255813953488372ya別 T0.023255813953488372yc開発中 T0.023255813953488372ycという T0.023255813953488372>vc269<yfちょくちょく T0.024390243902439025yc書こう T0.024390243902439025yaと T0.024390243902439025yb言い T0.024390243902439025yaな T0.024390243902439025yaが S0.04878048780487805yaら T0.024390243902439025ya、 S0.04878048780487805ya前 T0.024390243902439025yaの T0.024390243902439025yb記事 T0.024390243902439025yc1週間 T0.024390243902439025yc以上前 T0.024390243902439025yaに S0.07317073170731707ybなっ T0.024390243902439025ybてる T0.024390243902439025ya。 R0.0975609756097561ya  S0.07317073170731707yb昨日 T0.024390243902439025yaは T0.024390243902439025yeBasho T0.024390243902439025yeJapan T0.024390243902439025yb遊び T0.024390243902439025yb行っ T0.024390243902439025yaて T0.024390243902439025yc来まし T0.024390243902439025yaた S0.04878048780487805ya（ T0.024390243902439025ydRiak T0.024390243902439025yb触っ T0.024390243902439025yaこ T0.024390243902439025>vc270<ya1 S0.02127659574468085ya3 S0.02127659574468085ya4 S0.02127659574468085yfLucene S0.02127659574468085ya/ S0.02127659574468085ydSolr S0.02127659574468085ya  S0.06382978723404255ya. R0.0425531914893617yaの R0.0851063829787234ybRC S0.02127659574468085ydVote S0.02127659574468085yaが S0.06382978723404255yc始まっ S0.02127659574468085yaて R0.0425531914893617ycいます S0.02127659574468085ya、 R0.0425531914893617ybその S0.02127659574468085ybML S0.02127659574468085ybでき S0.02127659574468085yaに S0.02127659574468085ybなっ S0.02127659574468085yaた R0.0425531914893617ybコト S0.02127659574468085ybあり S0.02127659574468085ycちょっ S0.02127659574468085yaと S0.02127659574468085yb調べ S0.02127659574468085yaで S0.02127659574468085ybメモ S0.02127659574468085yaを S0.02127659574468085yb残し S0.02127659574468085ydおきます S0.02127659574468085ya。 S0.02127659574468085yeマルチコア S0.02127659574468085yb設定 S0.02127659574468085ybファ S0.02127659574468085>vc271<ybもう T0.030303030303030304yc何番煎 T0.030303030303030304yaじ T0.030303030303030304yaだ T0.030303030303030304yc？って T0.030303030303030304ycくらい T0.030303030303030304yb書か T0.030303030303030304yaれ T0.030303030303030304yaて S0.09090909090909091ybます T0.030303030303030304yaが T0.030303030303030304ya、 S0.06060606060606061ybコリ T0.030303030303030304ycもせず T0.030303030303030304yb書い T0.030303030303030304ycみまし T0.030303030303030304yaた T0.030303030303030304ya。 T0.030303030303030304ya  T0.030303030303030304ymElasticsearch T0.030303030303030304ya＋ T0.030303030303030304yfKibana T0.030303030303030304yaの S0.06060606060606061yb環境 T0.030303030303030304yaを T0.030303030303030304yb作っ T0.030303030303030304ydタムタム T0.030303030303030304ybさん T0.030303030303030304yaロ T0.030303030303030304>vc272<yd2013 S0.02631578947368421yb昨日 S0.02631578947368421yaに S0.05263157894736842yb引き S0.02631578947368421yb続き S0.02631578947368421ya、 S0.05263157894736842ycAWS S0.02631578947368421ya  S0.10526315789473684yfSummit S0.02631578947368421yeTokyo S0.02631578947368421yb行っ S0.02631578947368421yaて S0.02631578947368421ycきまし S0.02631578947368421yaた S0.05263157894736842ya。 S0.02631578947368421ya@ S0.02631578947368421ycryu S0.02631578947368421ya_ S0.02631578947368421yikobayashi S0.02631578947368421ybさん S0.02631578947368421ybから S0.02631578947368421ycパシリ S0.02631578947368421yaを S0.02631578947368421ye仰せつかる S0.02631578947368421ybなど S0.02631578947368421ybあり S0.02631578947368421yd忙しかっ S0.02631578947368421yaの S0.02631578947368421yaで S0.02631578947368421yaす S0.02631578947368421yaが S0.02631578947368421yc楽しか S0.02631578947368421>vc273<ybざっ S0.03333333333333333yaと S0.03333333333333333yiインストールガイド S0.03333333333333333ybとか S0.03333333333333333yhCloudera S0.03333333333333333ya  S0.06666666666666667yfSearch S0.03333333333333333yaの S0.03333333333333333yeソース眺め S0.03333333333333333yaて S0.06666666666666667ya、 S0.03333333333333333ydテキトー S0.03333333333333333yaに S0.03333333333333333ybメモ S0.03333333333333333yaを S0.03333333333333333yb書い S0.03333333333333333ycみまし S0.03333333333333333yaた S0.03333333333333333ya。 S0.06666666666666667ya（ S0.03333333333333333yfユーザガイド S0.03333333333333333yaは S0.03333333333333333ybまだ S0.03333333333333333yb読ん S0.03333333333333333yaで S0.03333333333333333ybない S0.03333333333333333ybです S0.03333333333333333>vc274<yd2013 T0.023255813953488372ycAWS T0.023255813953488372ya  S0.11627906976744186yfSummit T0.023255813953488372yeTokyo T0.023255813953488372yaに S0.09302325581395349yb行っ T0.023255813953488372yaて T0.046511627906976744yc来まし T0.023255813953488372yaた S0.06976744186046512ya。 T0.046511627906976744ya@ T0.046511627906976744yicocoatomo T0.023255813953488372ybさん T0.023255813953488372yb行き T0.023255813953488372yb掛け T0.023255813953488372yc出会っ T0.023255813953488372yaの S0.06976744186046512yaで T0.023255813953488372ya、 T0.023255813953488372yfアンデルセン T0.023255813953488372yb講演 T0.023255813953488372yaを T0.023255813953488372yb一緒 T0.023255813953488372yb聞い T0.023255813953488372ybまし T0.023255813953488372ybTD T0.023255813953488372ycブース T0.023255813953488372ybry T0.023255813953488372>vc275<yhCloudera S0.05555555555555555ya  S0.08333333333333333yfSearch S0.05555555555555555yaは S0.05555555555555555ya次 T0.027777777777777776yaの S0.05555555555555555ybよう T0.027777777777777776yaな T0.027777777777777776yeモジュール S0.05555555555555555ybから T0.027777777777777776yb構成 T0.027777777777777776yaさ T0.027777777777777776yaれ T0.027777777777777776yaて T0.027777777777777776yaい T0.027777777777777776ybます T0.027777777777777776ya。 T0.027777777777777776ybこれ S0.05555555555555555yaで T0.027777777777777776ya、 T0.027777777777777776ybさら T0.027777777777777776yaに T0.027777777777777776yaら T0.027777777777777776yaが T0.027777777777777776ydSolr T0.027777777777777776ybとか T0.027777777777777776yaを T0.027777777777777776yb使っ T0.027777777777777776>vc276<ycAWS S0.02631578947368421ya  S0.07894736842105263yfSummit S0.02631578947368421yaに S0.02631578947368421ya来 S0.02631578947368421yaて S0.05263157894736842yaい S0.02631578947368421yaた S0.07894736842105263yaの S0.02631578947368421yaで S0.07894736842105263yaす S0.02631578947368421yaが S0.05263157894736842ya、 S0.07894736842105263ybTL S0.02631578947368421yaは S0.02631578947368421yhCloudera S0.02631578947368421yfSearch S0.02631578947368421yc賑わっ S0.02631578947368421ybまし S0.02631578947368421ya。 S0.02631578947368421ycという S0.02631578947368421ybこと S0.02631578947368421yd軽くどん S0.02631578947368421ydなものか S0.02631578947368421yb読ん S0.02631578947368421ybだり S0.02631578947368421yb調べ S0.02631578947368421ycたりし S0.02631578947368421>vc277<yb憧れ T0.027777777777777776ya？ T0.027777777777777776yaの S0.08333333333333333yffluent T0.027777777777777776yaを S0.05555555555555555yb使っ T0.027777777777777776yaて S0.05555555555555555ycみまし T0.027777777777777776yaた S0.05555555555555555ya。 T0.027777777777777776ya  T0.027777777777777776ycこちら T0.027777777777777776yb記事 T0.027777777777777776yaで S0.08333333333333333yb紹介 T0.027777777777777776yaし S0.05555555555555555yhZoomdata T0.027777777777777776yd最近触っ T0.027777777777777776ybいる T0.027777777777777776yaす T0.027777777777777776yaが T0.027777777777777776ya、 T0.027777777777777776ycお試し T0.027777777777777776yaに T0.027777777777777776ygfluentd T0.027777777777777776ycデータ T0.027777777777777776ya流 T0.027777777777777776yb込む T0.027777777777777776>vc278<yb最近 S0.02702702702702703ya、 S0.08108108108108109yhMarkdown S0.05405405405405406yaで S0.08108108108108109yb文章 S0.02702702702702703yaを S0.08108108108108109yb書く S0.02702702702702703yaの S0.08108108108108109yaに S0.02702702702702703yb慣れ S0.02702702702702703yaて S0.02702702702702703ycきまし S0.02702702702702703yaた S0.02702702702702703ya。 S0.02702702702702703ya  S0.02702702702702703ycという S0.02702702702702703ybこと S0.02702702702702703ycブログ S0.05405405405405406yb書け S0.02702702702702703ycないか S0.02702702702702703ybなぁ S0.02702702702702703yaと S0.02702702702702703yb思い S0.02702702702702703ybTL S0.02702702702702703ya人 S0.02702702702702703ybたち S0.02702702702702703ya見 S0.02702702702702703>vc279<yb昨年 T0.027777777777777776ybから T0.027777777777777776ya、 S0.08333333333333333ycブログ T0.027777777777777776yaを S0.05555555555555555ycどうし T0.027777777777777776ydようかっ T0.027777777777777776yaて R0.1111111111111111ya話 T0.027777777777777776yaし T0.027777777777777776yaい S0.05555555555555555ydそのまま T0.027777777777777776yaに T0.027777777777777776ybなっ T0.027777777777777776yaた T0.027777777777777776yaの S0.05555555555555555yaで T0.027777777777777776yaす T0.027777777777777776yaが S0.05555555555555555yiOctopress T0.027777777777777776ya＋ T0.027777777777777776yfGithub T0.027777777777777776ya  T0.027777777777777776yePages T0.027777777777777776ycという T0.027777777777777776ybある T0.027777777777777776ycらしい T0.027777777777777776>vc280<ya0 S0.05263157894736842ya3 S0.05263157894736842ya4 S0.05263157894736842yfLucene S0.05263157894736842ya/ S0.02631578947368421ydSolr S0.05263157894736842ya  S0.05263157894736842ya. S0.10526315789473684yaが S0.02631578947368421ydリリース S0.05263157894736842yaさ S0.02631578947368421yaれ S0.02631578947368421yaた S0.02631578947368421ya（ S0.02631578947368421yaの S0.07894736842105263ygChanges S0.05263157894736842ya、 S0.05263157894736842ya） S0.02631578947368421yaで S0.02631578947368421yflucene S0.02631578947368421ya- S0.02631578947368421yegosen S0.02631578947368421yaを S0.02631578947368421ybしま S0.02631578947368421>vc281<yeアジャイル T0.038461538461538464yaな T0.038461538461538464ye時間管理術 T0.038461538461538464ya  S0.11538461538461539yjポモドーロテクニック S0.07692307692307693yb入門 S0.07692307692307693ycという T0.038461538461538464ya本 T0.038461538461538464yaを T0.038461538461538464yd読みまし T0.038461538461538464yaた T0.038461538461538464ya。 T0.038461538461538464ydきっかけ T0.038461538461538464yaは T0.038461538461538464ya、 T0.038461538461538464ygTwitter T0.038461538461538464ya上 T0.038461538461538464yaで T0.038461538461538464yb何度 T0.038461538461538464yaか T0.038461538461538464ya「 T0.038461538461538464yeポモドーロ T0.038461538461538464>vc282<ya3 T0.021739130434782608ya4 T0.021739130434782608yb11 T0.021739130434782608yb25 T0.021739130434782608yd2013 T0.021739130434782608ybまだ T0.021739130434782608ya、 S0.08695652173913043ydVote T0.021739130434782608yb公開 T0.021739130434782608yaさ T0.021739130434782608yaれ T0.021739130434782608yaて S0.06521739130434782yaい T0.043478260869565216ybない T0.043478260869565216ydSolr T0.021739130434782608ya  S0.06521739130434782ya. T0.021739130434782608ya（ T0.021739130434782608ya/ T0.043478260869565216yb04 T0.021739130434782608ya: T0.021739130434782608yd00現在 T0.021739130434782608ya） T0.021739130434782608ybです T0.021739130434782608yaが T0.021739130434782608ydひさびさ T0.021739130434782608yaに T0.021739130434782608yb訳し T0.021739130434782608yaみ T0.021739130434782608yaた T0.021739130434782608ya。 T0.021739130434782608yb詳細 T0.021739130434782608ybまで T0.021739130434782608yb追っ T0.021739130434782608yaの T0.021739130434782608yaで T0.021739130434782608>vc283<ya0 T0.022727272727272728ya3 T0.045454545454545456ya4 T0.022727272727272728yb16 T0.022727272727272728yb24 T0.022727272727272728yd2013 T0.022727272727272728yb現在 T0.022727272727272728ya、 S0.06818181818181818ybRC T0.022727272727272728yaの T0.022727272727272728ydVote T0.022727272727272728yaを T0.022727272727272728ybやっ T0.022727272727272728yaて T0.045454545454545456ybいる T0.022727272727272728yb最中 T0.022727272727272728ya（ T0.022727272727272728ya/ T0.045454545454545456yb04 T0.022727272727272728ya  T0.045454545454545456ya: T0.022727272727272728yd00時点 T0.022727272727272728ya） T0.022727272727272728yaで T0.045454545454545456ybまだ T0.022727272727272728ydリリース T0.022727272727272728yaさ T0.022727272727272728yaれ T0.022727272727272728yaい T0.022727272727272728ybない T0.022727272727272728ya. T0.045454545454545456ydについて T0.022727272727272728yaす T0.022727272727272728ya。 T0.022727272727272728yc開発者 T0.022727272727272728ybML T0.022727272727272728>vc284<yd第2回目 T0.023809523809523808yaも T0.023809523809523808yb参加 T0.023809523809523808yaし T0.023809523809523808ybまし T0.023809523809523808yaた S0.07142857142857142ya。 S0.09523809523809523ya  S0.09523809523809523ybとり T0.023809523809523808ycあえず T0.023809523809523808ybメモ T0.023809523809523808yb自分 T0.023809523809523808yaに T0.023809523809523808yaは T0.023809523809523808yb欠け T0.023809523809523808ybてる T0.023809523809523808yb視点 T0.023809523809523808yaの S0.09523809523809523yb話し T0.023809523809523808yaな T0.023809523809523808yaで T0.023809523809523808yb面白 T0.023809523809523808ybかっ T0.023809523809523808ycちょっ T0.023809523809523808yaと T0.023809523809523808yc寒かっ T0.023809523809523808ybなぁ T0.023809523809523808yeエンジニア T0.023809523809523808ybため T0.023809523809523808yfスキルアップ T0.023809523809523808yb勉強 T0.023809523809523808>vc285<ycだいぶe0.025ya、e0.075ycブログe0.025yaをd0.05yb書くe0.025ycペースe0.025yaがe0.025yb落ちe0.025yaてc0.1ybきてe0.025yc危機感e0.025yb感じe0.025ybいるd0.05yb今日e0.025yaこe0.025yaのd0.05ybごろe0.025yaでe0.025yaすe0.025ya。e0.075ya e0.025yb今回e0.025yaはe0.025yc個人的e0.025yaにe0.025yb利用e0.025yaしe0.025ydJIRAe0.025yfバックアップe0.025ydについてe0.025>vc286<yfHeroku S0.03571428571428571yaで S0.03571428571428571yaは S0.03571428571428571ycじめる S0.03571428571428571yeRails S0.03571428571428571ygプログラミング S0.03571428571428571yb入門 S0.03571428571428571ya  S0.03571428571428571ygheroku気 S0.03571428571428571yaに S0.07142857142857142ybなっ S0.03571428571428571ybてる S0.03571428571428571yaの S0.07142857142857142yb使っ S0.03571428571428571yaて S0.14285714285714285ybなく S0.03571428571428571ya、 S0.03571428571428571ybTD S0.03571428571428571ygアカウント作っ S0.03571428571428571yfデータアップ S0.03571428571428571yaし S0.03571428571428571ybない S0.03571428571428571yc軟弱者 S0.03571428571428571>vc287<yb記念 T0.023809523809523808yaす T0.047619047619047616ybべき T0.023809523809523808ya！ T0.047619047619047616ya？ T0.023809523809523808ya第 T0.023809523809523808yc10回 T0.023809523809523808yaの T0.023809523809523808ydSolr T0.023809523809523808yc勉強会 T0.023809523809523808yaで S0.07142857142857142ya。 T0.047619047619047616ya  T0.047619047619047616yc発表者 T0.023809523809523808yaが T0.047619047619047616yb無事 T0.023809523809523808ydあつまり T0.023809523809523808ya（ T0.023809523809523808yb本当 T0.023809523809523808yaに T0.023809523809523808ybあり T0.023809523809523808ygとうございまし T0.023809523809523808yaた T0.047619047619047616ya） T0.023809523809523808ya、 T0.023809523809523808yb今回 T0.023809523809523808yaも T0.023809523809523808yb盛況 T0.023809523809523808yaな T0.023809523809523808yb感じ T0.023809523809523808ybほぼ T0.023809523809523808yb満員 T0.023809523809523808yaし T0.023809523809523808ycツイー T0.023809523809523808>vc288<ycなんか T0.029411764705882353ya、 T0.058823529411764705ybとて T0.029411764705882353yaも T0.029411764705882353yb久し T0.029411764705882353ybぶり T0.029411764705882353yaに T0.058823529411764705ydイベント T0.029411764705882353yb参加 T0.029411764705882353ybメモ T0.029411764705882353yb以外 T0.029411764705882353yaの S0.08823529411764706yb投稿 T0.029411764705882353yaで T0.029411764705882353yaす T0.029411764705882353ya。 T0.029411764705882353ya  T0.058823529411764705ygelastic T0.029411764705882353yfsearch T0.029411764705882353ybML T0.029411764705882353yaを T0.058823529411764705yb見て T0.029411764705882353ybたら T0.029411764705882353yhKuromoji T0.029411764705882353yhAnalyzer T0.029411764705882353yb使う T0.029411764705882353ybとき T0.029411764705882353ycユーザ T0.029411764705882353>vc289<yb久々e0.025yaにe0.025ycブログe0.025ya＋d0.05ydイベントe0.025yb参加d0.05yaでd0.05yaすe0.025ya。e0.075ya d0.05yd知り合いe0.025yaがe0.025yb開催e0.025yb出演e0.025yaしd0.05yaたe0.075yaのe0.025yaてe0.025ycみましe0.025ya「e0.025ycスマホe0.025yc」ってe0.025yeキーワードe0.025yaはe0.025ycあまりe0.025ycなかっe0.025ycたけどe0.025ya、e0.025yb面白e0.025ybかっe0.025ybですe0.025>vc290<yb技術 T0.020833333333333332ycブログ T0.020833333333333332ybから T0.020833333333333332yb離れ T0.020833333333333332yaてf0.0625ybいっ T0.020833333333333332ybます T0.020833333333333332yaが T0.041666666666666664ya。 S0.10416666666666667ya  S0.10416666666666667yfXperia T0.041666666666666664yaZ T0.020833333333333332yaを T0.020833333333333332yb購入 T0.020833333333333332yaし T0.020833333333333332ybまし T0.020833333333333332yaたf0.0625ya前 T0.020833333333333332yaに T0.041666666666666664yb使っ T0.020833333333333332yaい T0.020833333333333332yaの T0.041666666666666664yaは T0.020833333333333332ycarc T0.020833333333333332ydなります T0.020833333333333332ydもうすぐ T0.020833333333333332yb２年 T0.020833333333333332ybだっ T0.020833333333333332yaで T0.020833333333333332yaす T0.020833333333333332ya、 T0.020833333333333332yc容量不 T0.020833333333333332>vc291<yd2013 T0.022222222222222223yc金曜日 T0.022222222222222223yaに T0.044444444444444446yb引き T0.022222222222222223yb続き T0.022222222222222223ya、 T0.044444444444444446ydイベント T0.022222222222222223yb参加 T0.022222222222222223yaし T0.022222222222222223yaて T0.022222222222222223yc来まし T0.022222222222222223yaた T0.022222222222222223ya。 S0.13333333333333333ya（ T0.022222222222222223yb仕事 T0.044444444444444446ybこれ T0.022222222222222223yaも T0.022222222222222223yaだ T0.022222222222222223yaよ T0.022222222222222223ya） T0.022222222222222223ya  S0.13333333333333333ya「 T0.022222222222222223yfHadoop T0.044444444444444446yjConference T0.022222222222222223yeJapan T0.022222222222222223yfWinter T0.022222222222222223ya」 T0.022222222222222223ybです T0.022222222222222223yb普段 T0.022222222222222223yaを T0.022222222222222223yb触る T0.022222222222222223>vc292<ya1 S0.03225806451612903yb18 S0.03225806451612903yd2013 S0.03225806451612903ya/ S0.03225806451612903ya（ S0.06451612903225806ya金 S0.03225806451612903ya） S0.06451612903225806yaに S0.03225806451612903yb開催 S0.03225806451612903yaさ S0.03225806451612903yaれ S0.03225806451612903yaた S0.03225806451612903ya、 S0.03225806451612903yiエンジニアサポート S0.03225806451612903yeCROSS S0.06451612903225806ya  S0.03225806451612903yaで S0.03225806451612903ya「 S0.03225806451612903yb検索 S0.03225806451612903ya」 S0.03225806451612903yeセッション S0.03225806451612903yaの S0.03225806451612903yiセッションオーナー S0.03225806451612903yeモデレータ S0.03225806451612903yaを S0.03225806451612903ybやっ S0.03225806451612903yaて S0.03225806451612903yb来ま S0.03225806451612903>vc293<ya1 T0.027777777777777776yb18 T0.027777777777777776yd2013 T0.027777777777777776ydいまさら T0.027777777777777776yc感満載 T0.027777777777777776yaで S0.05555555555555555yaす T0.027777777777777776yaが T0.027777777777777776ya、 T0.027777777777777776yb今週 T0.027777777777777776yaの S0.05555555555555555yc金曜日 T0.027777777777777776ya( T0.027777777777777776ya/ T0.027777777777777776ya) T0.027777777777777776yaに S0.05555555555555555yb開催 T0.027777777777777776yaさ T0.027777777777777776ybれる T0.027777777777777776yeCROSS S0.05555555555555555ya  T0.027777777777777776ycという T0.027777777777777776ydイベント T0.027777777777777776ya「 T0.027777777777777776yb検索 T0.027777777777777776ya」 T0.027777777777777776yeセッション T0.027777777777777776yaを T0.027777777777777776yb担当 T0.027777777777777776ybする T0.027777777777777776ybこと T0.027777777777777776yaな T0.027777777777777776>vc294<yb年末 S0.03225806451612903ybから S0.03225806451612903yb年始 S0.03225806451612903yaに S0.06451612903225806ycかけて S0.03225806451612903ya、 S0.06451612903225806ya「 S0.03225806451612903ykコード・シンプリシティ S0.03225806451612903ya」 S0.03225806451612903yaを S0.06451612903225806yd読みまし S0.03225806451612903yaた S0.06451612903225806ya。 S0.03225806451612903ya  S0.06451612903225806yb先日 S0.03225806451612903yaの S0.03225806451612903yb記事 S0.03225806451612903yaも S0.03225806451612903yd書きまし S0.03225806451612903yaが S0.03225806451612903yfKindle S0.03225806451612903yjpaperwhite S0.03225806451612903yb思い S0.03225806451612903ycかけず S0.03225806451612903yb入手 S0.03225806451612903yaで S0.03225806451612903>vc295<yc書こう T0.022727272727272728yaと S0.06818181818181818yb思い T0.022727272727272728yaな T0.022727272727272728yaが T0.022727272727272728yaら T0.022727272727272728ya、 S0.06818181818181818yc気づい T0.022727272727272728ybたら T0.022727272727272728yc大晦日 T0.022727272727272728ya。 S0.06818181818181818ya  S0.06818181818181818ybよく T0.022727272727272728ybない T0.045454545454545456yaで T0.045454545454545456ybすね T0.022727272727272728yd思いつい T0.022727272727272728yaた S0.06818181818181818ya時 T0.022727272727272728yaに T0.022727272727272728yb書か T0.022727272727272728yb昨年 T0.022727272727272728yaも T0.022727272727272728yb書い T0.022727272727272728yaの T0.022727272727272728yd昨年書い T0.022727272727272728yb抱負 T0.022727272727272728ybから T0.022727272727272728yb振り T0.022727272727272728yb返り T0.022727272727272728yaを T0.022727272727272728yeMongo T0.022727272727272728>vc296<yd2012 T0.021739130434782608yiAtlassian T0.021739130434782608ya  S0.10869565217391304yfAdvent T0.021739130434782608yhCalendar T0.021739130434782608yaの S0.06521739130434782yd20日目 T0.021739130434782608ya。 T0.043478260869565216ya（ S0.08695652173913043yd急遽参戦 T0.021739130434782608ya） S0.06521739130434782ya某 T0.021739130434782608ydイケメン T0.021739130434782608yaに T0.043478260869565216ybMT T0.021739130434782608yb改変 T0.021739130434782608yeリツイート T0.021739130434782608yaさ T0.021739130434782608yaれ T0.021739130434782608yaた T0.043478260869565216yaで T0.043478260869565216yb書い T0.021739130434782608yaて T0.021739130434782608ycみまし T0.021739130434782608yb久々 T0.021739130434782608ya、 T0.021739130434782608yc勉強会 T0.021739130434782608yb以外 T0.021739130434782608ydエントリ T0.021739130434782608yaす T0.021739130434782608ybSo T0.021739130434782608>vc297<ydイケメン S0.02631578947368421yaが S0.05263157894736842yb主催 S0.02631578947368421yaし S0.05263157894736842yaた S0.05263157894736842ya「 S0.02631578947368421yc第一回 S0.02631578947368421ya  S0.07894736842105263yiJetBrains S0.02631578947368421yhユーザーグループ S0.02631578947368421ya# S0.02631578947368421yejbugj S0.02631578947368421ya」 S0.02631578947368421yaに S0.05263157894736842yb参加 S0.02631578947368421yaて S0.02631578947368421ycきまし S0.02631578947368421ya。 S0.05263157894736842ycいろん S0.02631578947368421yaな S0.02631578947368421yb製品 S0.02631578947368421ybある S0.02631578947368421yaん S0.02631578947368421yaだ S0.02631578947368421ybなぁ S0.02631578947368421yaと S0.02631578947368421yb入り S0.02631578947368421ya口 S0.02631578947368421yaは S0.02631578947368421yb良い S0.02631578947368421yaイ S0.02631578947368421>vc298<ydヒカリエ T0.023255813953488372yaに T0.046511627906976744yb行っ T0.023255813953488372yaて T0.046511627906976744yaみ T0.023255813953488372ybたい T0.023255813953488372ycという T0.046511627906976744yb不純 T0.023255813953488372yaな S0.06976744186046512yb理由 T0.023255813953488372yaで S0.06976744186046512yb参加 T0.023255813953488372yaし T0.046511627906976744ycきまし T0.023255813953488372yaた T0.046511627906976744ya。 T0.046511627906976744ya  T0.046511627906976744yc新しい T0.023255813953488372ybこと T0.023255813953488372yaも T0.046511627906976744ybあり T0.023255813953488372ya、 T0.023255813953488372ydおしゃれ T0.023255813953488372yb綺麗 T0.023255813953488372ycカフェ T0.023255813953488372yb入り T0.023255813953488372ya口 T0.023255813953488372yaは T0.023255813953488372ycおっき T0.023255813953488372yb人形 T0.023255813953488372yb立っ T0.023255813953488372>vc299<yc第9回e0.025ydSolre0.025yc勉強会e0.025yaにe0.075yb参加e0.025yaしe0.025ybましe0.025yaたd0.05ya。d0.05ya d0.05yc皆勤賞e0.025yaでe0.025yaすe0.025ya！e0.025ydというかe0.025ya、d0.05yc主催者e0.025ybなっe0.025yaてe0.025yeしまいましe0.025ybまだe0.025yc不定期e0.025yaのe0.025yb開催e0.025ybなるe0.025yaとe0.025yd思いますe0.025yaがe0.025ya話e0.025yaをe0.025yaさe0.025yaれe0.025ybたいe0.025yc方などe0.025>vc300<yc初目黒 S0.02631578947368421ya（ S0.02631578947368421ycたぶん S0.02631578947368421ya） S0.02631578947368421yaで S0.05263157894736842ya、 S0.07894736842105263yg初Amazon S0.02631578947368421yaな S0.02631578947368421yb感じ S0.02631578947368421yc流行り S0.02631578947368421yaの S0.07894736842105263ya「 S0.02631578947368421yfビッグデータ S0.02631578947368421ya」 S0.02631578947368421ydセミナー S0.02631578947368421yaに S0.02631578947368421yb参加 S0.02631578947368421yaし S0.02631578947368421yaて S0.05263157894736842ycきまし S0.02631578947368421yaた S0.02631578947368421ya。 S0.02631578947368421ya  S0.02631578947368421ybとり S0.02631578947368421ybあえ S0.02631578947368421yaず S0.02631578947368421ydいつもの S0.02631578947368421yc自分用 S0.02631578947368421ybメモ S0.02631578947368421yaを S0.02631578947368421yb残し S0.02631578947368421yaお S0.02631578947368421>vc301<ya0 S0.08333333333333333ya4 T0.041666666666666664yb## T0.020833333333333332yfLucene T0.041666666666666664ya/ T0.041666666666666664ydSolr T0.041666666666666664ya f0.0625ya. S0.08333333333333333ydリリースf0.0625ybつい T0.020833333333333332yaに T0.020833333333333332ya、 T0.041666666666666664yaが T0.041666666666666664yaさ T0.020833333333333332yaれ T0.020833333333333332ybまし T0.020833333333333332yaたf0.0625ya。 T0.041666666666666664ybML T0.020833333333333332yaで T0.020833333333333332yb流れ T0.020833333333333332yaて T0.020833333333333332ycいまし T0.020833333333333332yc3年越 T0.020833333333333332yaし T0.020833333333333332yaの T0.020833333333333332ybだっ T0.020833333333333332ybよう T0.020833333333333332ybです T0.020833333333333332>vc302<ybこの T0.034482758620689655ydイベント T0.034482758620689655yaに T0.034482758620689655yiウチダスペクトラム T0.034482758620689655yaの S0.06896551724137931ya枠 T0.034482758620689655yaで S0.10344827586206896yfMahout T0.034482758620689655yeコミッター T0.034482758620689655ybある T0.034482758620689655ya、 S0.06896551724137931yeGrant T0.034482758620689655ya  T0.034482758620689655yiIngersoll T0.034482758620689655ybさん T0.034482758620689655yaが S0.06896551724137931yb講演 T0.034482758620689655yaさ T0.034482758620689655ybれる T0.034482758620689655ycという T0.034482758620689655ybこと T0.034482758620689655yb興味 T0.034482758620689655ybあっ T0.034482758620689655yaた T0.034482758620689655>vc303<yd2012 S0.02631578947368421ycPFI S0.02631578947368421yhオープンセミナー S0.02631578947368421yaに S0.05263157894736842yb参加 S0.05263157894736842yaし S0.07894736842105263yaて S0.10526315789473684ycきまし S0.05263157894736842yaた S0.05263157894736842ya。 S0.02631578947368421ya  S0.02631578947368421yb対象 S0.02631578947368421ybから S0.02631578947368421yb微妙 S0.02631578947368421yb外れ S0.02631578947368421ybたり S0.02631578947368421ya、 S0.05263157894736842ya話 S0.02631578947368421yaの S0.02631578947368421yb内容 S0.02631578947368421ycについ S0.02631578947368421ycいける S0.02631578947368421yaか S0.02631578947368421yb自信 S0.02631578947368421yaが S0.05263157894736842yeありません S0.02631578947368421yaで S0.02631578947368421>vc304<yb友人 T0.027777777777777776ybにお T0.027777777777777776yb値打 T0.027777777777777776yb価格 T0.027777777777777776yaで S0.08333333333333333yb購入 T0.027777777777777776yaし S0.08333333333333333yaた S0.05555555555555555ycMac T0.027777777777777776ya  S0.05555555555555555ydmini T0.027777777777777776yaは S0.05555555555555555yhMountain T0.027777777777777776ydLion T0.027777777777777776yaに T0.027777777777777776yfアップデート S0.05555555555555555yaて S0.05555555555555555yaの S0.05555555555555555yaす T0.027777777777777776yaが T0.027777777777777776ya、 T0.027777777777777776yb手元 T0.027777777777777776ycAir T0.027777777777777776ybまだ T0.027777777777777776yaい T0.027777777777777776ycません T0.027777777777777776>vc305<yb興味 T0.047619047619047616yaを T0.047619047619047616ydもちつつ T0.023809523809523808ya、 S0.07142857142857142yb触っ T0.023809523809523808yaて T0.047619047619047616yaい T0.023809523809523808ybない T0.023809523809523808yc軟弱者 T0.023809523809523808yaで T0.047619047619047616yaす T0.023809523809523808yaが T0.047619047619047616ybある T0.023809523809523808yaの T0.047619047619047616yb今回 T0.023809523809523808yaも T0.023809523809523808ya話 T0.023809523809523808yb聞き T0.023809523809523808yaに T0.023809523809523808yb行っ T0.023809523809523808yc来まし T0.023809523809523808yaた T0.023809523809523808ya。 T0.023809523809523808ya  T0.023809523809523808ybまず T0.023809523809523808yaは T0.023809523809523808yb作者 T0.023809523809523808yb古橋 T0.023809523809523808ybさん T0.023809523809523808ycによる T0.023809523809523808ygFluentd T0.023809523809523808yb魅力 T0.023809523809523808yaや T0.023809523809523808yb次期 T0.023809523809523808>vc306<ydまたまた T0.029411764705882353yb飲み T0.029411764705882353yaに T0.029411764705882353yb行っ T0.029411764705882353yaて T0.058823529411764705yb参加 T0.029411764705882353yaし T0.029411764705882353ycきまし T0.029411764705882353yaた T0.029411764705882353ya。 T0.029411764705882353ya  T0.029411764705882353yb今回 T0.029411764705882353yaは T0.029411764705882353ya、 S0.11764705882352941yeRails T0.029411764705882353yciOS T0.029411764705882353yaで T0.029411764705882353yaの S0.11764705882352941ygTwitter T0.029411764705882353yb連携 T0.029411764705882353ya話 T0.029411764705882353ybから T0.029411764705882353ydツイート T0.029411764705882353yb分析 T0.029411764705882353yiクライアントアプリ T0.029411764705882353yb開発 T0.029411764705882353yb苦労 T0.029411764705882353>vc307<ycという T0.023809523809523808ybこと T0.023809523809523808yaで T0.047619047619047616ya、 S0.07142857142857142yeステッカー T0.023809523809523808ya欲 T0.023809523809523808yaし T0.023809523809523808yaさ T0.023809523809523808ya？ T0.023809523809523808yaに S0.07142857142857142yc勉強中 T0.023809523809523808yaの T0.023809523809523808ya話 T0.023809523809523808yaを T0.023809523809523808ye恥ずかしげ T0.023809523809523808yaも T0.023809523809523808ybなく T0.023809523809523808yc偉そう T0.023809523809523808ydしゃべっ T0.023809523809523808yaて T0.047619047619047616ycきまし T0.023809523809523808yaた T0.023809523809523808ya。 T0.023809523809523808ya  T0.023809523809523808ya# T0.023809523809523808yepyfes T0.023809523809523808yaは T0.023809523809523808yb以前 T0.023809523809523808ybから T0.023809523809523808ya気 T0.023809523809523808ybなっ T0.023809523809523808yaい T0.023809523809523808ybたん T0.023809523809523808yaす T0.023809523809523808yaが T0.023809523809523808yaタ T0.023809523809523808>vc308<ya0d0.04ya4d0.04yb今日d0.02yaはd0.04ydSolrd0.06ya d0.16ya.d0.04yeALPHAd0.02yaのd0.04yc興味深d0.02yaいd0.02yb機能d0.02yaがd0.02ybあっd0.02yaたd0.04yaでd0.04yb紹介d0.02yaすd0.02ya。d0.04yc数日前d0.02yaにd0.04ya「d0.02ya:d0.02ygPartiald0.02yidocumentsd0.02yfupdated0.02ya」d0.02ycというd0.02yb記事d0.02yaをd0.02ye見つけましd0.02ya、d0.02>vc309<yfModern T0.028985507246376812ya  R0.2753623188405797ykInformation T0.028985507246376812yiRetrieval T0.028985507246376812ya: T0.014492753623188406ycThe T0.014492753623188406yhConcepts T0.014492753623188406ycand T0.014492753623188406yjTechnology T0.014492753623188406yfbehind T0.014492753623188406yfSearch T0.014492753623188406ya( T0.028985507246376812yc2nd T0.028985507246376812ygEdition T0.028985507246376812ya) T0.028985507246376812ycACM T0.014492753623188406yePress T0.014492753623188406yeBooks T0.014492753623188406ycいやぁ T0.014492753623188406ya、 T0.014492753623188406yb蒸し T0.014492753623188406yb暑く T0.014492753623188406yaて T0.014492753623188406ybなか T0.028985507246376812yb寝れ T0.014492753623188406ybない T0.028985507246376812ya日 T0.014492753623188406yaが T0.014492753623188406yaは T0.014492753623188406yeじまりまし T0.014492753623188406ybたね T0.014492753623188406ya。 T0.057971014492753624ya（ T0.014492753623188406ydあんまり T0.014492753623188406yb関係 T0.014492753623188406yaで T0.014492753623188406ybすね T0.014492753623188406ya） T0.014492753623188406yaを T0.014492753623188406>vc310<ya0 S0.05555555555555555ya3 T0.027777777777777776ya4 T0.027777777777777776ya7 T0.027777777777777776yfLucene T0.027777777777777776ya/ S0.05555555555555555ydSolr T0.027777777777777776yaの S0.08333333333333333ya. S0.05555555555555555ya- S0.05555555555555555yeALPHA T0.027777777777777776yaが T0.027777777777777776yaに S0.05555555555555555ydリリース T0.027777777777777776yaさ T0.027777777777777776yaれ T0.027777777777777776ybまし T0.027777777777777776yaた T0.027777777777777776ya。 T0.027777777777777776ya  T0.027777777777777776ybこれ T0.027777777777777776yb伴い T0.027777777777777776ya、 T0.027777777777777776yflucene T0.027777777777777776ydgoen T0.027777777777777776yb4x T0.027777777777777776ydブランチ T0.027777777777777776ycjar T0.027777777777777776ydファイル T0.027777777777777776>vc311<ydまたまた T0.020833333333333332yb参加 T0.020833333333333332yaし T0.020833333333333332ybまし T0.020833333333333332yaた T0.041666666666666664ya。e0.125ycいまだ T0.020833333333333332yc皆勤賞 T0.020833333333333332yaでe0.125yaすf0.0625ya  S0.08333333333333333yb感想 T0.041666666666666664ybなど T0.020833333333333332yaは T0.041666666666666664yaあ T0.020833333333333332yaと T0.020833333333333332ybとり T0.020833333333333332ycあえず T0.020833333333333332ya、f0.0625ybメモ T0.020833333333333332ybとっ T0.020833333333333332yaの T0.020833333333333332yc第一弾 T0.020833333333333332ycという T0.020833333333333332ybこと T0.020833333333333332ybまず T0.020833333333333332yd参加人数 T0.020833333333333332ya今 T0.020833333333333332>vc312<yfHadoop S0.05714285714285714ybから S0.02857142857142857ydはちょっ S0.02857142857142857yaと S0.02857142857142857yb離れ S0.02857142857142857yaて S0.02857142857142857ybいる S0.02857142857142857yaの S0.05714285714285714yaに S0.02857142857142857ya、 S0.08571428571428572yb面白 S0.02857142857142857ybそう S0.02857142857142857yaな S0.02857142857142857ybネタ S0.02857142857142857ybなの S0.02857142857142857yaで S0.02857142857142857yb参加 S0.02857142857142857yaし S0.02857142857142857ybまし S0.02857142857142857yaた S0.02857142857142857ya。 S0.02857142857142857ya  S0.11428571428571428ydData S0.02857142857142857ygScience S0.02857142857142857yfSummit S0.05714285714285714yhHBaseCon S0.02857142857142857yaイ S0.02857142857142857>vc313<yb32 T0.024390243902439025yeIssue T0.024390243902439025ya  S0.04878048780487805yaで S0.04878048780487805ya上 T0.024390243902439025ybがっ T0.024390243902439025yaて S0.04878048780487805yaき T0.024390243902439025yaた S0.04878048780487805yelucee T0.024390243902439025ya- T0.024390243902439025yegosen T0.024390243902439025yaの R0.0975609756097561yfUniDic S0.04878048780487805yb対応 T0.024390243902439025yb最初 T0.024390243902439025ycパッチ T0.024390243902439025yaを T0.024390243902439025yb書い T0.024390243902439025ya、 T0.024390243902439025ycブログ T0.024390243902439025yaに T0.024390243902439025yb残し T0.024390243902439025ydおきます T0.024390243902439025ya。 T0.024390243902439025ya# S0.07317073170731707yaと T0.024390243902439025yaは T0.024390243902439025ya_ S0.07317073170731707>vc314<ya「 T0.021739130434782608ya鉄 T0.021739130434782608yaは T0.043478260869565216yd熱いうち T0.021739130434782608yaに T0.021739130434782608yb打て T0.021739130434782608ya」 T0.021739130434782608ycという T0.021739130434782608ybこと T0.021739130434782608yaで S0.06521739130434782ya、 T0.043478260869565216yb残り T0.021739130434782608yaも T0.021739130434782608yb勢い T0.021739130434782608ybメモ T0.021739130434782608ya。 S0.08695652173913043ya  T0.043478260869565216ybまだ T0.021739130434782608yb見直 T0.021739130434782608yaし T0.021739130434782608ycとかし T0.021739130434782608yaて T0.021739130434782608ybない T0.021739130434782608yb状態 T0.021739130434782608yaな T0.021739130434782608yaの T0.043478260869565216ydおかしい T0.021739130434782608yaと T0.043478260869565216ybころ T0.021739130434782608yaか T0.021739130434782608ydあります T0.021739130434782608yaが T0.021739130434782608ya図 T0.021739130434782608ybとか T0.021739130434782608yc入れる T0.021739130434782608yaま T0.021739130434782608>vc315<yfZipkin T0.029411764705882353yaの T0.058823529411764705yfGithub T0.029411764705882353yaに T0.029411764705882353ybある T0.029411764705882353yfReadme T0.029411764705882353yaを T0.058823529411764705yb読ん T0.029411764705882353yaで T0.058823529411764705ybます T0.029411764705882353ya。 T0.058823529411764705ya  T0.058823529411764705ydせっかく T0.029411764705882353ydというか T0.029411764705882353ya、 T0.058823529411764705ya頭 T0.029411764705882353yaが T0.029411764705882353yb悪い T0.029411764705882353yb読み T0.029411764705882353ybなが T0.029411764705882353yaら T0.029411764705882353yb内容 T0.029411764705882353ybメモ T0.029411764705882353ybまず T0.029411764705882353yaは T0.029411764705882353ygアーキテクチャ T0.029411764705882353yaと T0.029411764705882353ycトレー T0.029411764705882353>vc316<yb久々 T0.030303030303030304yaに S0.06060606060606061ydSolr T0.030303030303030304yaの S0.12121212121212122ya話 S0.06060606060606061yaで S0.06060606060606061yaす T0.030303030303030304ya。 S0.12121212121212122ya  S0.06060606060606061ydといって T0.030303030303030304yaも T0.030303030303030304ya、 T0.030303030303030304yc結構前 T0.030303030303030304ybから T0.030303030303030304yaし T0.030303030303030304yaて T0.030303030303030304yfschema T0.030303030303030304ya. T0.030303030303030304ycxml T0.030303030303030304yifieldType T0.030303030303030304yb設定 T0.030303030303030304ya「 T0.030303030303030304ynautoGeneratePh T0.030303030303030304>vc317<yaす S0.02631578947368421yaで S0.07894736842105263yaに S0.07894736842105263yc読まれ S0.02631578947368421yaた S0.05263157894736842yd方もいる S0.02631578947368421yaか S0.05263157894736842yaも S0.02631578947368421yb知れ S0.02631578947368421ycません S0.02631578947368421yaが S0.02631578947368421ya、 S0.02631578947368421ya気 S0.02631578947368421ybなっ S0.02631578947368421yaの S0.07894736842105263ybメモ S0.02631578947368421yaを S0.02631578947368421yb書い S0.02631578947368421yaて S0.02631578947368421yaみ S0.02631578947368421ybよう S0.02631578947368421yaと S0.05263157894736842ya。 S0.02631578947368421ya  S0.02631578947368421yb先週 S0.02631578947368421yc木曜日 S0.02631578947368421ygTwitter S0.02631578947368421yhエンジニアブログ S0.02631578947368421yfZipkin S0.02631578947368421>vc318<ya0 S0.02857142857142857ya1 S0.02857142857142857ya2 S0.02857142857142857yflucene S0.02857142857142857ya- S0.02857142857142857yegosen S0.02857142857142857yaの S0.05714285714285714yc最新版 S0.02857142857142857ya（ S0.02857142857142857ya. S0.05714285714285714ya） S0.02857142857142857yaを S0.02857142857142857ydリリース S0.02857142857142857ycしまし S0.02857142857142857yaた S0.02857142857142857ya。 S0.05714285714285714ya  S0.05714285714285714yiプロジェクトページ S0.02857142857142857ybより S0.02857142857142857yfダウンロード S0.02857142857142857yaが S0.02857142857142857yb可能 S0.02857142857142857yaで S0.05714285714285714yaす S0.02857142857142857yb今回 S0.02857142857142857yb修正 S0.02857142857142857yaは S0.02857142857142857ya、 S0.02857142857142857ya@ S0.02857142857142857yeharuy S0.02857142857142857>vc319<yb昨晩 T0.043478260869565216yaに S0.08695652173913043yb引き T0.021739130434782608yb続き T0.021739130434782608ya、 S0.06521739130434782yb情け T0.021739130434782608ybない T0.021739130434782608yb内容 T0.021739130434782608yaの S0.06521739130434782ycブログ T0.021739130434782608ybなっ T0.021739130434782608yaて T0.043478260869565216yeしまいます T0.021739130434782608yaが T0.043478260869565216ya。 S0.06521739130434782ya  T0.021739130434782608yb書い T0.021739130434782608yaた S0.08695652173913043yb記事 T0.021739130434782608yb調査 T0.043478260869565216yaを T0.021739130434782608yaし T0.021739130434782608yaい T0.021739130434782608ya時 T0.021739130434782608yc気づい T0.021739130434782608yb問題 T0.021739130434782608ybなる T0.021739130434782608ycケース T0.021739130434782608ybあっ T0.021739130434782608yaで T0.021739130434782608>vc320<ya3 S0.05263157894736842ya5 S0.02631578947368421ya6 S0.02631578947368421yb久々 S0.02631578947368421yaに S0.07894736842105263yflucene S0.02631578947368421ya- S0.02631578947368421yegosen S0.02631578947368421yaを S0.05263157894736842yb触っ S0.02631578947368421yaて S0.02631578947368421ycいます S0.02631578947368421ya。 S0.02631578947368421ya  S0.02631578947368421yetrunk S0.02631578947368421yaの S0.05263157894736842yclib S0.02631578947368421ybある S0.02631578947368421ya、 S0.05263157894736842ycjar S0.02631578947368421ydファイル S0.02631578947368421yaが S0.02631578947368421ya. S0.05263157894736842ycベース S0.05263157894736842ybだっ S0.02631578947368421yaた S0.02631578947368421yaで S0.02631578947368421ybして S0.02631578947368421ycテスト S0.02631578947368421yaし S0.02631578947368421>vc321<yb録画 S0.02564102564102564yaし S0.02564102564102564yaて S0.07692307692307693yaた S0.05128205128205128ycEテレ S0.02564102564102564yaの S0.05128205128205128ymスーパープレゼンテーション S0.02564102564102564yaを S0.02564102564102564yb見て S0.02564102564102564yaふ S0.02564102564102564yaと S0.02564102564102564yb書き S0.02564102564102564ybたく S0.02564102564102564ybなっ S0.02564102564102564yaで S0.02564102564102564ya、 S0.02564102564102564yb書い S0.02564102564102564ybます S0.02564102564102564ya。 S0.10256410256410256ya  S0.05128205128205128ybあと S0.02564102564102564ybから S0.02564102564102564yb読ん S0.02564102564102564ybだら S0.02564102564102564ye恥ずかしく S0.02564102564102564ybなり S0.02564102564102564ybそう S0.02564102564102564ycだけど S0.02564102564102564ya「 S0.02564102564102564ya& S0.02564102564102564yal S0.02564102564102564>vc322<yd2012 T0.021739130434782608ydJJUG T0.021739130434782608ya  S0.13043478260869565ycCCC T0.021739130434782608yfSpring T0.021739130434782608yaに T0.043478260869565216yb参加 T0.043478260869565216yaし T0.021739130434782608yaて T0.021739130434782608ycきまし T0.021739130434782608yaた T0.021739130434782608ya。 S0.06521739130434782yb昨年 T0.021739130434782608yaの T0.021739130434782608ydFall T0.021739130434782608yb続き T0.021739130434782608ya、 S0.06521739130434782yc2回目 T0.021739130434782608yaで T0.021739130434782608yaす T0.021739130434782608yb概要 T0.021739130434782608yaや T0.021739130434782608ygタイムテーブル T0.021739130434782608yaは T0.043478260869565216ycこちら T0.021739130434782608yaを T0.021739130434782608yb御覧 T0.021739130434782608yaく T0.021739130434782608yaだ T0.021739130434782608ybさい T0.021739130434782608yb今回 T0.021739130434782608yb午後 T0.021739130434782608ya一 T0.021739130434782608ybから T0.021739130434782608>vc323<ya0 S0.02631578947368421ynPlayFramework2 S0.02631578947368421ya. S0.02631578947368421yaを S0.02631578947368421yb触っ S0.02631578947368421yaて S0.07894736842105263yaみ S0.02631578947368421ybます S0.02631578947368421ya。 S0.05263157894736842ya  S0.05263157894736842ycちょっ S0.02631578947368421yaと S0.05263157894736842yfコーディング S0.02631578947368421yaし S0.02631578947368421ybたく S0.02631578947368421ybなっ S0.02631578947368421yaた S0.02631578947368421yaの S0.13157894736842105ya、 S0.05263157894736842yb最近 S0.02631578947368421ycアプリ S0.02631578947368421yb作成 S0.02631578947368421yb調査 S0.02631578947368421yaも S0.02631578947368421yb兼ね S0.02631578947368421ybまぁ S0.02631578947368421ydせっかく S0.02631578947368421yaな S0.02631578947368421>vc324<ya0 T0.027777777777777776ya1 T0.027777777777777776ya2 T0.027777777777777776ya7 T0.027777777777777776yflucene T0.027777777777777776ya- T0.027777777777777776yegosen T0.027777777777777776yaの S0.05555555555555555yc最新版 T0.027777777777777776ya（ T0.027777777777777776ya. S0.05555555555555555ya） T0.027777777777777776yaを T0.027777777777777776ydリリース T0.027777777777777776ycしまし T0.027777777777777776yaた T0.027777777777777776ya。 S0.05555555555555555ya  S0.05555555555555555yiプロジェクトページ T0.027777777777777776ybより T0.027777777777777776yfダウンロード T0.027777777777777776yaが T0.027777777777777776yb可能 T0.027777777777777776yaで S0.08333333333333333yaす T0.027777777777777776yb今回 T0.027777777777777776yb修正 T0.027777777777777776yaは T0.027777777777777776ya、 T0.027777777777777776ydJava T0.027777777777777776>vc325<ybID S0.05405405405405406yaの S0.05405405405405406yb秘密 S0.02702702702702703ya  S0.08108108108108109ya( S0.02702702702702703yb丸善 S0.02702702702702703yfライブラリー S0.02702702702702703ya― S0.02702702702702703yc情報研 S0.02702702702702703ydシリーズ S0.02702702702702703ya) S0.02702702702702703yb非常 S0.02702702702702703yaに S0.08108108108108109yb面白 S0.02702702702702703yaく S0.02702702702702703yd読めまし S0.02702702702702703yaた S0.02702702702702703ya。 S0.02702702702702703yeバーコード S0.02702702702702703ya話 S0.02702702702702703yc始まり S0.02702702702702703ya、 S0.02702702702702703yb最後 S0.02702702702702703yaは S0.02702702702702703ydシステム S0.02702702702702703yaで S0.02702702702702703yb付与 S0.02702702702702703ybする S0.02702702702702703yc関する S0.02702702702702703yc考慮点 S0.02702702702702703ybまで S0.02702702702702703>vc326<ygWebSolr S0.06451612903225806yaの S0.06451612903225806ya話 S0.03225806451612903yaが S0.03225806451612903ybある S0.03225806451612903ycらしい S0.03225806451612903ycという S0.03225806451612903yaを S0.03225806451612903ye嗅ぎつけて S0.03225806451612903ya、 S0.06451612903225806yb初め S0.03225806451612903yaて S0.03225806451612903yfHeroku S0.03225806451612903ya  R0.0967741935483871ybJP S0.03225806451612903yfMeetup S0.03225806451612903yaに S0.03225806451612903yb参加 S0.03225806451612903yaし S0.03225806451612903ybまし S0.03225806451612903yaた S0.03225806451612903ya。 S0.03225806451612903yfheroku S0.03225806451612903yaも S0.06451612903225806yd知りつつ S0.03225806451612903>vc327<ya3 T0.022727272727272728ya6 T0.022727272727272728yb先日 T0.022727272727272728ya、 S0.06818181818181818ydSolr T0.022727272727272728yb入門 T0.022727272727272728yaの S0.09090909090909091ydサンプル T0.022727272727272728yfschema T0.022727272727272728ya. S0.06818181818181818ycxml T0.022727272727272728yb0対 T0.022727272727272728yb応版 T0.022727272727272728yb作成 T0.022727272727272728yaを T0.022727272727272728yaし T0.022727272727272728yaて S0.06818181818181818yaい T0.022727272727272728ya気 T0.022727272727272728yaに T0.022727272727272728ybなっ T0.022727272727272728yaた T0.045454545454545456ybこと T0.022727272727272728yaが T0.022727272727272728ybあっ T0.022727272727272728yaで T0.022727272727272728ya  T0.045454545454545456ybメモ T0.022727272727272728ycとして T0.022727272727272728yb残し T0.022727272727272728ydおきます T0.022727272727272728ya。 T0.022727272727272728yaS T0.022727272727272728>vc328<ya0 T0.023809523809523808ya3 T0.023809523809523808ya6 T0.023809523809523808yb先日 T0.023809523809523808yaの S0.09523809523809523yb続き T0.023809523809523808yaで T0.047619047619047616yaす T0.023809523809523808ya。 T0.047619047619047616ya「 T0.023809523809523808yfApache T0.023809523809523808ya  T0.047619047619047616ydSolr T0.047619047619047616yb入門 T0.023809523809523808ya」 T0.023809523809523808yb2章 T0.023809523809523808ybから T0.023809523809523808yb4章 T0.023809523809523808yb説明 T0.023809523809523808ydについて T0.023809523809523808ya、 T0.023809523809523808ya. T0.047619047619047616yb動作 T0.023809523809523808yaさ T0.023809523809523808ybせる T0.023809523809523808ya時 T0.023809523809523808yc変更点 T0.023809523809523808yaを T0.023809523809523808yb以下 T0.023809523809523808yaに T0.023809523809523808yb書い T0.023809523809523808yaて T0.023809523809523808ydいきます T0.023809523809523808yaな T0.023809523809523808>vc329<ya0 T0.029411764705882353ya3 T0.029411764705882353ya6 T0.029411764705882353yb以前 T0.029411764705882353ybより T0.029411764705882353ya、 S0.08823529411764706yeアナウンス T0.029411764705882353yaし T0.029411764705882353yaて T0.029411764705882353yaい T0.029411764705882353yaた T0.058823529411764705yhKuromoji T0.029411764705882353ycという T0.029411764705882353yh日本語形態素解析 T0.029411764705882353yaが T0.058823529411764705yd含まれる T0.029411764705882353yfLucene T0.029411764705882353ya/ T0.029411764705882353ydSolr T0.029411764705882353ya  T0.058823529411764705ya. T0.058823529411764705ydリリース T0.029411764705882353yaさ T0.029411764705882353yaれ T0.029411764705882353ybまし T0.029411764705882353ya。 T0.029411764705882353yb以下 T0.029411764705882353ya各 T0.029411764705882353>vc330<ygTwitter S0.02702702702702703yaで S0.08108108108108109ybこの S0.02702702702702703ydブログ流 S0.02702702702702703yaれ S0.02702702702702703yaて S0.02702702702702703ybきて S0.02702702702702703ya、 S0.08108108108108109ya気 S0.02702702702702703yaに S0.08108108108108109ybなっ S0.02702702702702703yaた S0.02702702702702703yaの S0.05405405405405406yb流し S0.02702702702702703yd読みして S0.02702702702702703yb簡単 S0.02702702702702703ybメモ S0.02702702702702703ya。 S0.05405405405405406ya  S0.05405405405405406yfAmazon S0.02702702702702703ydサービス S0.05405405405405406ydスケール S0.02702702702702703ybする S0.02702702702702703yb検索 S0.02702702702702703yaみ S0.02702702702702703ybたい S0.02702702702702703ya主 S0.02702702702702703>vc331<ya4 R0.1111111111111111ya5 T0.037037037037037035yd2012 T0.018518518518518517ygJavaOne T0.018518518518518517ya  S0.07407407407407407yeTokyo T0.018518518518518517yaに T0.018518518518518517yb参加 T0.037037037037037035yaし T0.018518518518518517yaて S0.05555555555555555ycきまし T0.018518518518518517yaた S0.05555555555555555ya。 T0.037037037037037035ya/ S0.07407407407407407ya- T0.018518518518518517yaの S0.05555555555555555ye2日間開催 T0.018518518518518517yaさ T0.018518518518518517yaれ T0.018518518518518517yaい T0.018518518518518517yaで T0.018518518518518517yaす T0.018518518518518517yaが T0.037037037037037035ya、 T0.037037037037037035yb子供 T0.018518518518518517yb体調 T0.018518518518518517yaを T0.018518518518518517yb崩し T0.018518518518518517ycしまい T0.018518518518518517ybのみ T0.018518518518518517yaと T0.018518518518518517ydなりまし T0.018518518518518517>vc332<ya0 S0.05405405405405406ya2 S0.02702702702702703ya7 S0.02702702702702703yb先日 S0.02702702702702703ya、 S0.05405405405405406ya. S0.05405405405405406ydリリース S0.02702702702702703yaの S0.02702702702702703yb記事 S0.02702702702702703yaに S0.02702702702702703yaも S0.02702702702702703yb記載 S0.02702702702702703yaし S0.02702702702702703ybまし S0.02702702702702703yaた S0.05405405405405406yaが S0.08108108108108109ydJava S0.02702702702702703yaで S0.02702702702702703yfテストケース S0.02702702702702703yb失敗 S0.02702702702702703ybする S0.02702702702702703yb問題 S0.02702702702702703ydありまし S0.02702702702702703ya。 S0.02702702702702703ya  S0.02702702702702703ya@ S0.05405405405405406yhharuyama S0.02702702702702703ybさん S0.02702702702702703yaと S0.02702702702702703yfhideak S0.02702702702702703>vc333<ya0 S0.05128205128205128ya2 S0.02564102564102564yb先日 S0.02564102564102564ya、 S0.05128205128205128yb宣言 S0.02564102564102564yaし S0.02564102564102564yaた S0.07692307692307693ycとおり S0.02564102564102564yflucene S0.05128205128205128ya- S0.05128205128205128yegosen S0.05128205128205128yaの S0.05128205128205128yeパッケージ S0.02564102564102564ya名 S0.05128205128205128ya＋ S0.02564102564102564ycクラス S0.02564102564102564yb変更 S0.02564102564102564yaを S0.05128205128205128yb行っ S0.02564102564102564ya  S0.05128205128205128ya. S0.05128205128205128ydリリース S0.02564102564102564ycしまし S0.02564102564102564ya。 S0.02564102564102564yfLucene S0.02564102564102564ya/ S0.02564102564102564ydSolr S0.02564102564102564>vc334<ya0 S0.02857142857142857ya2 S0.02857142857142857yflucene S0.05714285714285714ya- S0.05714285714285714yegosen S0.05714285714285714yaを S0.05714285714285714yb利用 S0.02857142857142857yaし S0.02857142857142857yaて S0.02857142857142857yb頂い S0.02857142857142857ybてる S0.02857142857142857yb皆様 S0.02857142857142857yaに S0.02857142857142857yb連絡 S0.02857142857142857yaが S0.02857142857142857ydあります S0.02857142857142857ya。 S0.02857142857142857ya  S0.05714285714285714yd連絡事項 S0.02857142857142857yb次期 S0.02857142857142857yaの S0.02857142857142857ydリリース S0.02857142857142857ya（ S0.02857142857142857ya. S0.05714285714285714yb予定 S0.02857142857142857ya） S0.02857142857142857ybにて S0.02857142857142857ya、 S0.02857142857142857ycorg S0.02857142857142857>vc335<yb子供 S0.02857142857142857yaの S0.02857142857142857yb寝か S0.02857142857142857ydしつけし S0.02857142857142857yaて S0.14285714285714285ybたら S0.02857142857142857ya、 S0.05714285714285714yf寝かしつけさ S0.02857142857142857yaれ S0.02857142857142857ycしまっ S0.02857142857142857yb２時 S0.02857142857142857yaに S0.05714285714285714ya目 S0.02857142857142857yaが S0.02857142857142857yb覚め S0.02857142857142857yeしまいまし S0.02857142857142857yaた S0.02857142857142857ya。 S0.02857142857142857ya  S0.02857142857142857ygTSUTAYA S0.02857142857142857yaで S0.02857142857142857ybCD S0.02857142857142857yb借り S0.02857142857142857ybきて S0.02857142857142857yfウォークマン S0.02857142857142857yb入れ S0.02857142857142857ybよう S0.02857142857142857yaと S0.02857142857142857yb思っ S0.02857142857142857>vc336<ybはい S0.02702702702702703ya。 S0.05405405405405406ydまたまた S0.02702702702702703ya、 S0.02702702702702703ygTwitter S0.02702702702702703ya  S0.05405405405405406ycAPI S0.02702702702702703yc勉強会 S0.02702702702702703yaに S0.02702702702702703yb参加 S0.02702702702702703yaし S0.05405405405405406yaて S0.02702702702702703ycきまし S0.02702702702702703yaた S0.05405405405405406ya（ S0.02702702702702703yb今回 S0.05405405405405406ybから S0.02702702702702703yb開催 S0.02702702702702703yb回数 S0.02702702702702703yaの S0.02702702702702703yb記載 S0.02702702702702703yaが S0.05405405405405406ybなく S0.02702702702702703ybなっ S0.02702702702702703ya？ S0.02702702702702703ya） S0.02702702702702703yaは S0.02702702702702703yb直前 S0.02702702702702703yaで S0.02702702702702703ygタイムテーブル S0.02702702702702703yd変わって S0.02702702702702703>vc337<ybTL S0.02631578947368421yaで S0.07894736842105263yb面白 S0.02631578947368421yaい S0.02631578947368421yaと S0.02631578947368421yd見かけて S0.02631578947368421ya、 S0.05263157894736842yfAmazon S0.05263157894736842yb買っ S0.02631578947368421yaて S0.02631578947368421yeしまいまし S0.02631578947368421yaた S0.05263157894736842ya。 S0.05263157894736842ya  S0.05263157894736842ybSE S0.02631578947368421ybやっ S0.02631578947368421ybてる S0.02631578947368421yaの S0.02631578947368421yaに S0.05263157894736842ybつい S0.02631578947368421yb最近 S0.02631578947368421yaを S0.02631578947368421yb使い S0.02631578947368421yb始め S0.02631578947368421yc軟弱者 S0.02631578947368421yaす S0.02631578947368421ybそれ S0.02631578947368421ybして S0.02631578947368421yaも S0.02631578947368421ydAmaz S0.02631578947368421>vc338<ybえー T0.022222222222222223yaと R0.1111111111111111ya、 S0.06666666666666667ycブログ T0.022222222222222223yb更新 T0.022222222222222223yaし T0.022222222222222223yaて T0.022222222222222223ybない T0.022222222222222223ybなぁ T0.022222222222222223ybとふ T0.022222222222222223yb思っ T0.022222222222222223yaた S0.08888888888888889yaの T0.022222222222222223yaで T0.022222222222222223ya。 R0.1111111111111111ya  S0.06666666666666667yb１年 T0.022222222222222223yd前くらい T0.022222222222222223ybから T0.022222222222222223ybずー T0.022222222222222223yaっ T0.022222222222222223yeつぶやいて T0.022222222222222223ybまし T0.044444444444444446yaが T0.022222222222222223ybやっ T0.022222222222222223yeScala T0.022222222222222223yaを T0.022222222222222223yb始め T0.022222222222222223yc長かっ T0.022222222222222223>vc339<yc森ビル S0.02127659574468085yaに S0.06382978723404255yb行っ S0.02127659574468085yaた S0.06382978723404255ybこと S0.02127659574468085ycなかっ S0.02127659574468085yaの R0.0425531914893617yaで R0.0425531914893617ya、 R0.0851063829787234yb参加 S0.02127659574468085yaし R0.0425531914893617yaて S0.06382978723404255ycみまし S0.02127659574468085ya。 R0.0425531914893617ya  R0.0425531914893617ybあと S0.02127659574468085yb最近 S0.02127659574468085yaま S0.02127659574468085yaと R0.0425531914893617yaも R0.0425531914893617yfコーディング S0.02127659574468085ybない S0.02127659574468085ydそのへん S0.02127659574468085yaを S0.02127659574468085yb矯正 S0.02127659574468085ybする S0.02127659574468085ybため S0.02127659574468085yb思っ S0.02127659574468085ya（ S0.02127659574468085ybまぁ S0.02127659574468085ya遊 S0.02127659574468085>vc340<yeClean S0.08108108108108109ya  S0.16216216216216217yeCoder S0.05405405405405406ynプロフェッショナルプログラマ S0.02702702702702703yaへ S0.02702702702702703yaの S0.02702702702702703ya道 S0.02702702702702703yaを S0.02702702702702703yb読み S0.02702702702702703ybまし S0.02702702702702703yaた S0.05405405405405406ya。 S0.05405405405405406yb理由 S0.02702702702702703yaは S0.02702702702702703ygTwitter S0.02702702702702703yaで S0.02702702702702703ya「 S0.02702702702702703ydCode S0.02702702702702703ya」 S0.02702702702702703ycがいい S0.02702702702702703yb本だ S0.02702702702702703yaと S0.02702702702702703yb流れ S0.02702702702702703yaて S0.02702702702702703yaき S0.02702702702702703ybため S0.02702702702702703ybです S0.02702702702702703>vc341<yb親子e0.025yaでe0.075yd楽しめるe0.025ya e0.075yb絵本e0.025yb英語d0.05yaをd0.05yaはe0.025ycじめるe0.025ya本d0.05ygTwittere0.025ybこのe0.025ydについてe0.025yb書かe0.025yaれe0.025yaたe0.075ycブログe0.025yb記事e0.025yaがe0.025yb流れe0.025yaてe0.025ybきてe0.025ya、d0.05yb購入e0.025yaしe0.025ybましe0.025ya。e0.025yb最近e0.025ye身につけてe0.025ybおいe0.025>vc342<yb今週 T0.021739130434782608yaも T0.021739130434782608yc勉強会 T0.043478260869565216yaに T0.021739130434782608yb参加 T0.021739130434782608yaし S0.06521739130434782ybまし T0.021739130434782608yaた S0.06521739130434782ya。 S0.06521739130434782ya  S0.08695652173913043ya@ T0.021739130434782608ygyusukey T0.021739130434782608ybさん T0.021739130434782608yaが S0.06521739130434782yb開催 T0.021739130434782608ybてる T0.021739130434782608ygTwitter T0.021739130434782608ycAPI T0.021739130434782608yaで S0.06521739130434782yaす T0.021739130434782608yb前回 T0.021739130434782608yaと T0.021739130434782608yaは T0.021739130434782608yb会場 T0.043478260869565216ye異なりまし T0.021739130434782608ya、 T0.021739130434782608yb広く T0.021739130434782608yaて T0.021739130434782608yc大画面 T0.021739130434782608yb良い T0.021739130434782608ya駅 T0.021739130434782608>vc343<yb久々 T0.027777777777777776yaに S0.05555555555555555yflucene S0.05555555555555555ya- S0.05555555555555555yegosen S0.05555555555555555yaの T0.027777777777777776ya話 T0.027777777777777776yaで S0.08333333333333333yaす S0.08333333333333333ya。 S0.05555555555555555ya  S0.05555555555555555ycしかも T0.027777777777777776ya、 S0.05555555555555555ydあんまり T0.027777777777777776yc嬉しく T0.027777777777777776ybない T0.027777777777777776yb話し T0.027777777777777776yeissue T0.027777777777777776yaを T0.027777777777777776ycアップ T0.027777777777777776yaし T0.027777777777777776yaて T0.027777777777777776ycいます T0.027777777777777776yaが T0.027777777777777776yaと T0.027777777777777776>vc344<ybまた T0.022727272727272728ya、 S0.06818181818181818ye勉強会ログ T0.022727272727272728yaで S0.06818181818181818yaす T0.045454545454545456yeすみません T0.022727272727272728ya。 S0.09090909090909091ya  T0.045454545454545456yd直接業務 T0.022727272727272728yaと T0.022727272727272728yaは T0.045454545454545456yb関係 T0.022727272727272728ybない T0.022727272727272728yaの S0.06818181818181818yaが T0.045454545454545456yb今回 T0.022727272727272728yeリクルート T0.022727272727272728yb中野 T0.022727272727272728ybさん T0.022727272727272728yb話し T0.022727272727272728yaを T0.045454545454545456yaさ T0.022727272727272728ybれる T0.022727272727272728ycという T0.022727272727272728ya顔 T0.022727272727272728yb出し T0.022727272727272728yaて T0.022727272727272728ycきまし T0.022727272727272728yaた T0.022727272727272728yaも T0.022727272727272728>vc345<ygFluentd S0.02127659574468085ya  R0.0851063829787234yfmeetup S0.02127659574468085ybin S0.02127659574468085yeJapan S0.02127659574468085yaに S0.06382978723404255yb参加 R0.0425531914893617yaし R0.0425531914893617ybまし S0.02127659574468085yaた R0.0425531914893617ya。 R0.0425531914893617ycいつも S0.02127659574468085yb面白 S0.02127659574468085ybそう S0.02127659574468085yaな R0.0425531914893617ya話 S0.02127659574468085yaを S0.02127659574468085yb聞い S0.02127659574468085yaて R0.0425531914893617ydばっかり S0.02127659574468085yaの S0.02127659574468085yaで S0.02127659574468085ya、 R0.0425531914893617ya役 S0.02127659574468085yb立つ S0.02127659574468085ybため S0.02127659574468085ydスタッフ S0.02127659574468085ycとして S0.02127659574468085yaも S0.02127659574468085ycみまし S0.02127659574468085ybまず S0.02127659574468085yaは S0.02127659574468085yb会場 S0.02127659574468085yaが S0.02127659574468085yb綺麗 S0.02127659574468085>vc346<yc昨年末 T0.021739130434782608yaに S0.06521739130434782yb今年 T0.021739130434782608yaの S0.06521739130434782yb抱負 T0.021739130434782608ydについて T0.021739130434782608yb書い T0.043478260869565216yaた T0.043478260869565216yaで T0.043478260869565216yaす T0.021739130434782608yaが S0.06521739130434782ya、 T0.021739130434782608ya  T0.043478260869565216ya他 T0.021739130434782608yaも T0.021739130434782608yb興味 T0.043478260869565216ybある T0.043478260869565216ybもの T0.043478260869565216yb増え T0.021739130434782608yc備忘録 T0.021739130434782608ya＆ T0.021739130434782608yb公約 T0.021739130434782608ya？ T0.021739130434782608yaを T0.021739130434782608yb兼ね T0.021739130434782608yaて T0.043478260869565216ycブログ T0.021739130434782608ydおきます T0.021739130434782608ya。 T0.021739130434782608ya（ T0.021739130434782608ybあれ T0.021739130434782608yaば T0.021739130434782608>vc347<yb19 T0.015384615384615385yb22 T0.015384615384615385yb26 T0.015384615384615385yd2012 T0.015384615384615385ye23608 T0.015384615384615385ycという T0.015384615384615385ybこと T0.015384615384615385yaで T0.015384615384615385ya、 T0.015384615384615385ydいつもの T0.015384615384615385ybよう T0.015384615384615385yaに S0.03076923076923077yc勉強会 T0.015384615384615385yb参加 T0.015384615384615385yaし T0.015384615384615385yaた T0.015384615384615385ybメモ T0.015384615384615385ybです T0.015384615384615385ya。 T0.015384615384615385ya  S0.15384615384615385ydhttp T0.015384615384615385yb:/ T0.015384615384615385ya/ S0.07692307692307693ydatnd T0.015384615384615385ya. T0.015384615384615385ycorg T0.015384615384615385yfevents T0.015384615384615385yb日時 T0.015384615384615385ya: S0.06153846153846154yb01 T0.015384615384615385yb00 S0.03076923076923077ybto T0.015384615384615385yb会場 T0.015384615384615385yhアカデミーヒルズ T0.015384615384615385ya( T0.015384615384615385yc六本木 T0.015384615384615385ycヒルズ T0.015384615384615385ya内 T0.015384615384615385ya) T0.015384615384615385yc49階 T0.015384615384615385ya（ S0.03076923076923077yfタワーホール T0.015384615384615385yaA T0.015384615384615385ya） T0.015384615384615385yb港区 T0.015384615384615385ya六 T0.015384615384615385>vc348<ya2 T0.019230769230769232yb18 T0.019230769230769232yb19 T0.019230769230769232yb20 T0.019230769230769232yb30 T0.038461538461538464yd2012 T0.019230769230769232yb日時 T0.019230769230769232ya： T0.038461538461538464ya/ T0.038461538461538464yb01 T0.019230769230769232ya  S0.17307692307692307ya: T0.038461538461538464ya- T0.019230769230769232yb場所 T0.019230769230769232yeベルサール T0.019230769230769232yb三田 T0.019230769230769232ydRoom T0.019230769230769232ydシアター T0.019230769230769232yfInside T0.019230769230769232ydMapR T0.019230769230769232ybデモ T0.019230769230769232ya＋ T0.019230769230769232yb内部 T0.019230769230769232yaの T0.057692307692307696yaお T0.019230769230769232ya話 T0.019230769230769232ya。 T0.038461538461538464ya・ T0.019230769230769232yd自己紹介 T0.019230769230769232ygSusheel T0.019230769230769232ygKaushik T0.019230769230769232ya元 T0.019230769230769232yeYahoo T0.019230769230769232yfHadoop T0.019230769230769232ya系 T0.019230769230769232ya人 T0.019230769230769232yb製品 T0.019230769230769232>vc349<yeお久しぶり T0.022727272727272728yaで S0.06818181818181818yaす T0.022727272727272728ya。 S0.06818181818181818ygインフルエンザ T0.022727272727272728yd一家全滅 T0.022727272727272728ycという T0.022727272727272728yb最悪 T0.022727272727272728yaの T0.045454545454545456yb状況 T0.022727272727272728yaに T0.022727272727272728yb陥っ T0.022727272727272728yaて T0.022727272727272728yaい T0.022727272727272728yaた T0.045454545454545456ya我 T0.022727272727272728yaが T0.022727272727272728ya家 T0.022727272727272728yaし T0.045454545454545456ya  T0.045454545454545456yb流行 T0.022727272727272728ybてる T0.022727272727272728yaみ T0.022727272727272728ybたい T0.022727272727272728yaな T0.022727272727272728ybでみ T0.022727272727272728ycなさん T0.022727272727272728yaも T0.022727272727272728ya気 T0.022727272727272728yaを T0.022727272727272728ycつけて T0.022727272727272728yaく T0.022727272727272728yaだ T0.022727272727272728ybさい T0.022727272727272728ybさて T0.022727272727272728ya、 T0.022727272727272728>vc350<ya4 T0.030303030303030304yb先日 T0.030303030303030304yaの S0.09090909090909091ydSolr S0.06060606060606061yc勉強会 T0.030303030303030304yaで T0.030303030303030304yfLucene T0.030303030303030304ya/ T0.030303030303030304ya. T0.030303030303030304yax T0.030303030303030304ya系 T0.030303030303030304yflucene T0.030303030303030304ya- T0.030303030303030304yegosen T0.030303030303030304ydについて T0.030303030303030304yb質問 T0.030303030303030304yaを S0.06060606060606061yb受け T0.030303030303030304yaて T0.030303030303030304yaい T0.030303030303030304yaた S0.06060606060606061yb忘れ T0.030303030303030304ybない T0.030303030303030304ybよう T0.030303030303030304yaに T0.030303030303030304ya（ T0.030303030303030304yb年越 T0.030303030303030304yfしちゃいまし T0.030303030303030304>vc351<ydあけまし S0.02631578947368421yaて S0.05263157894736842ybおめ S0.02631578947368421yaで S0.07894736842105263ygとうございます S0.02631578947368421ya。 S0.10526315789473684ya（ S0.02631578947368421ybもう S0.02631578947368421yb5日 S0.02631578947368421yaす S0.02631578947368421yaが S0.02631578947368421ya） S0.02631578947368421ya  S0.02631578947368421yb今年 S0.02631578947368421yaも S0.02631578947368421yflucene S0.02631578947368421ya- S0.02631578947368421yegosen S0.02631578947368421yaを S0.05263157894736842yb中心 S0.02631578947368421yaに S0.02631578947368421yb色々 S0.02631578947368421yaと S0.02631578947368421yb記事 S0.02631578947368421yb書い S0.02631578947368421ydいきます S0.02631578947368421yaの S0.02631578947368421ya、 S0.05263157894736842ydツッコミ S0.02631578947368421ybコメ S0.02631578947368421>vc352<ya他 T0.021739130434782608yaの S0.10869565217391304ya方 T0.021739130434782608yeたちよりひ T0.021739130434782608yaと T0.043478260869565216ya足 T0.021739130434782608yaは T0.021739130434782608ybやい T0.021739130434782608yaで T0.043478260869565216yaす T0.021739130434782608yaが T0.043478260869565216ya、 T0.043478260869565216yb今年 T0.043478260869565216yb仕事 T0.021739130434782608ye終わりまし T0.021739130434782608yaた T0.043478260869565216ya。 T0.043478260869565216ya  T0.043478260869565216ydせっかく T0.021739130434782608ycブログ T0.021739130434782608yaを T0.021739130434782608yb始め T0.021739130434782608yb振り T0.021739130434782608yb返り T0.021739130434782608yb来年 T0.021739130434782608yb抱負 T0.021739130434782608ybなど T0.021739130434782608yb書い T0.021739130434782608yaて T0.021739130434782608yaみ T0.021739130434782608ybよう T0.021739130434782608yaか T0.021739130434782608ybなと T0.021739130434782608ya振 T0.021739130434782608>vc353<ya@ S0.02631578947368421ygyusukey S0.02631578947368421ybさん S0.02631578947368421yaに S0.05263157894736842ycサイン S0.02631578947368421yaを S0.05263157894736842ycもらう S0.02631578947368421yb目的 S0.02631578947368421yaで S0.05263157894736842yc勉強会 S0.02631578947368421yb参加 S0.02631578947368421yaし S0.02631578947368421yaて S0.05263157894736842ycきまし S0.02631578947368421yaた S0.05263157894736842ya。 S0.02631578947368421yb前回 S0.02631578947368421ycもらい S0.02631578947368421ycそびれ S0.02631578947368421yaの S0.02631578947368421yaｗ S0.02631578947368421ya  S0.05263157894736842yb残念 S0.02631578947368421yaな S0.02631578947368421yaが S0.02631578947368421yaら S0.02631578947368421ya、 S0.02631578947368421ybまだ S0.02631578947368421ygTwitter S0.02631578947368421ycAPI S0.02631578947368421yb触っ S0.02631578947368421ybない S0.02631578947368421>vc354<ya1 S0.05714285714285714ya2 S0.02857142857142857yflucene S0.02857142857142857ya- S0.02857142857142857yegosen S0.02857142857142857yaの S0.05714285714285714yc最新版 S0.02857142857142857ya（ S0.02857142857142857ya. S0.05714285714285714ya） S0.02857142857142857yaを S0.02857142857142857ydリリース S0.02857142857142857ycしまし S0.02857142857142857yaた S0.02857142857142857ya。 S0.05714285714285714ya  S0.05714285714285714yiプロジェクトページ S0.02857142857142857ybより S0.02857142857142857yfダウンロード S0.02857142857142857yaが S0.02857142857142857yb可能 S0.02857142857142857yaで S0.08571428571428572yaす S0.02857142857142857yb今回 S0.02857142857142857yb修正 S0.02857142857142857yaは S0.02857142857142857ya、 S0.02857142857142857ye特定文字列 S0.02857142857142857>vc355<ybいつ T0.023255813953488372ybもの T0.023255813953488372ybよう T0.023255813953488372yaに T0.046511627906976744ydSolr T0.023255813953488372yc勉強会 T0.023255813953488372yb参加 T0.023255813953488372yaし T0.023255813953488372yaて T0.023255813953488372ycきまし T0.023255813953488372yaた T0.023255813953488372ya。 S0.11627906976744186ya  T0.046511627906976744yc皆勤賞 T0.023255813953488372yaを T0.046511627906976744yc継続中 T0.023255813953488372yaで T0.046511627906976744yaす T0.023255813953488372ya（ T0.023255813953488372yb暇人 T0.023255813953488372ycという T0.023255813953488372yaは T0.046511627906976744ybなし T0.023255813953488372yaも T0.023255813953488372ya） T0.023255813953488372yb今回 T0.023255813953488372yb話し T0.023255813953488372yb聞き T0.023255813953488372ybたい T0.023255813953488372ycすねぇ T0.023255813953488372ycといっ T0.023255813953488372ybたら T0.023255813953488372ya、 T0.023255813953488372ybいや T0.023255813953488372>vc356<ycという T0.030303030303030304ybこと T0.030303030303030304yaで S0.06060606060606061ya、 S0.06060606060606061yc懲りず T0.030303030303030304yaに S0.09090909090909091ya# T0.030303030303030304ygDSIRNLP T0.030303030303030304yb参加 T0.030303030303030304yaし S0.06060606060606061yaて T0.030303030303030304ycきまし T0.030303030303030304yaた T0.030303030303030304ya。 T0.030303030303030304ya  T0.030303030303030304yb基礎 T0.030303030303030304ya的 T0.030303030303030304yaな T0.030303030303030304yb部分 T0.030303030303030304yaを T0.030303030303030304ybおろ T0.030303030303030304ybそか T0.030303030303030304ybたく T0.030303030303030304ydないけど T0.030303030303030304yhTokyoNLP T0.030303030303030304ybとか T0.030303030303030304yiWebMining T0.030303030303030304yaは T0.030303030303030304>vc357<ydひさびさ T0.022727272727272728yaに T0.045454545454545456ya、 S0.06818181818181818ycMBA T0.022727272727272728yaの T0.022727272727272728yaお T0.022727272727272728ya話 T0.022727272727272728yaで T0.045454545454545456yaす T0.022727272727272728ya。 S0.06818181818181818ya  S0.06818181818181818yfセットアップ T0.022727272727272728ydといって T0.022727272727272728yaも T0.045454545454545456yb物理 T0.022727272727272728ya的 T0.022727272727272728yaな T0.022727272727272728ya方 T0.022727272727272728ybすね T0.022727272727272728yb以前 T0.022727272727272728ycケース T0.022727272727272728ya（ T0.022727272727272728ycカバー T0.022727272727272728ya） T0.022727272727272728ydについて T0.022727272727272728yb記載 T0.022727272727272728yaし T0.022727272727272728ybまし T0.022727272727272728yaた T0.045454545454545456ybこの T0.022727272727272728yb記事 T0.022727272727272728yb書い T0.022727272727272728yaて T0.022727272727272728ybあっ T0.022727272727272728>vc358<ybどん T0.022727272727272728yaな T0.022727272727272728ya本 S0.06818181818181818yaで S0.06818181818181818yaも T0.022727272727272728yb大量 T0.022727272727272728yaに T0.022727272727272728yc読める T0.022727272727272728ya「 T0.022727272727272728yb速読 T0.022727272727272728ya」 T0.022727272727272728yaの T0.022727272727272728ya  T0.045454545454545456ygTwitter T0.022727272727272728yb知り T0.022727272727272728yb合っ T0.022727272727272728yaた S0.06818181818181818ya方 T0.022727272727272728yaが T0.022727272727272728ybこの T0.022727272727272728ydについて T0.022727272727272728yb書か T0.022727272727272728yaれ T0.022727272727272728yaて T0.022727272727272728yaい T0.022727272727272728ycブログ T0.022727272727272728yb記事 T0.022727272727272728yaを T0.045454545454545456yb読ん T0.022727272727272728yb興味 T0.022727272727272728yb持ち T0.022727272727272728ya、 T0.022727272727272728yd読みまし T0.022727272727272728ya。 T0.022727272727272728yb書籍 T0.022727272727272728ya（ T0.022727272727272728>vc359<yb12e0.025yd2010e0.025yfHadoope0.025ylソースコードリーディングe0.025ya第d0.05yb7回e0.025yaにd0.05yb参加d0.05yaしd0.05ybましe0.025yaたd0.05ya。d0.05ya d0.05ybいつe0.025ybものe0.025yaごe0.025ybとくe0.025ya、e0.025yc自分用e0.025yaのd0.05ybメモe0.025yaをe0.025ybとっe0.025yaてd0.05yaいe0.025yaでe0.025yb6回e0.025ya（e0.025ya/e0.025ya）e0.025yaはe0.025>vc360<yc先週末 S0.02127659574468085ybから S0.02127659574468085yb勤労 S0.02127659574468085yb感謝 S0.02127659574468085yaの R0.0851063829787234yc日まで S0.02127659574468085yb風邪 R0.0425531914893617yaで R0.0851063829787234yc寝こん S0.02127659574468085ybまし S0.02127659574468085yaた R0.0425531914893617ya。 R0.0851063829787234ya  R0.0425531914893617yaみ S0.02127659574468085ycなさん S0.02127659574468085ya、 R0.0425531914893617yb朝晩 S0.02127659574468085yb冷え S0.02127659574468085yb込み S0.02127659574468085yaが S0.02127659574468085yc激しい S0.02127659574468085yaに S0.02127659574468085yaは S0.02127659574468085ya気 S0.02127659574468085yaを S0.02127659574468085ycつけて S0.02127659574468085yaく S0.02127659574468085yaだ S0.02127659574468085ybさい S0.02127659574468085yb季節 S0.02127659574468085yb言葉 S0.02127659574468085yaも S0.02127659574468085yb入れ S0.02127659574468085ya本 S0.02127659574468085>vc361<yb今回 S0.06818181818181818yaは S0.06818181818181818ya、 T0.045454545454545456yc触ろう T0.022727272727272728yaと T0.022727272727272728yb思っ T0.022727272727272728yaて S0.06818181818181818yb触れ T0.022727272727272728yaい T0.022727272727272728ybない T0.022727272727272728ygMongoDB T0.022727272727272728yaの T0.045454545454545456yc勉強会 T0.022727272727272728yaに T0.045454545454545456yb行っ T0.022727272727272728yc来まし T0.022727272727272728yaた T0.045454545454545456ya。 T0.045454545454545456ya  T0.045454545454545456yb2週 T0.022727272727272728yb連続 T0.022727272727272728yb渋谷 T0.022727272727272728yaで T0.045454545454545456ycさすが T0.022727272727272728yb出口 T0.022727272727272728yaを T0.022727272727272728ybすん T0.022727272727272728ybなり T0.022727272727272728yaれ T0.022727272727272728ybまし T0.022727272727272728ya初 T0.022727272727272728>vc362<ydSolr S0.02631578947368421ya本 S0.02631578947368421yaの S0.07894736842105263yb武田 S0.02631578947368421ybさん S0.02631578947368421ybから S0.02631578947368421yb教え S0.02631578947368421yaて S0.07894736842105263yaい S0.02631578947368421yaた S0.07894736842105263ybだい S0.02631578947368421yfSplunk S0.05263157894736842ya  S0.05263157894736842ydイベント S0.02631578947368421yaに S0.05263157894736842yb行っ S0.02631578947368421yc来まし S0.02631578947368421ya。 S0.02631578947368421yaと S0.02631578947368421yaは S0.02631578947368421yb様々 S0.02631578947368421yaな S0.02631578947368421yb機器 S0.02631578947368421ybログ S0.02631578947368421ybなど S0.02631578947368421yaを S0.02631578947368421yc一箇所 S0.02631578947368421yb集め S0.02631578947368421ydリアルタ S0.02631578947368421>vc363<yc最近忘 T0.020833333333333332yaれ T0.020833333333333332yaや T0.020833333333333332ybすい T0.020833333333333332yaの S0.08333333333333333yaでf0.0625ya、 T0.041666666666666664yb記録 T0.020833333333333332yaし T0.020833333333333332yaて T0.020833333333333332ycおこう T0.020833333333333332yaか T0.020833333333333332yaと T0.041666666666666664ya。f0.0625ya f0.0625yb読ん T0.020833333333333332yaだ T0.020833333333333332ydスライドf0.0625yb簡単 T0.020833333333333332yaな T0.020833333333333332yb内容 T0.020833333333333332yb感想 T0.020833333333333332yaすf0.0625yaち T0.020833333333333332ybなみ T0.020833333333333332yaに T0.020833333333333332yb一覧 T0.020833333333333332yaは T0.041666666666666664ycこちら T0.020833333333333332ya※ T0.020833333333333332yaへ T0.020833333333333332ycリンク T0.020833333333333332>vc364<yhBookscan T0.027777777777777776ycという T0.027777777777777776ydサービス S0.05555555555555555yaが T0.027777777777777776ydあります T0.027777777777777776ya。 S0.05555555555555555ya  S0.05555555555555555yb書籍 T0.027777777777777776yaを S0.08333333333333333yc電子化 T0.027777777777777776ya（ T0.027777777777777776ycPDF T0.027777777777777776ya） T0.027777777777777776ybして T0.027777777777777776yb原本 T0.027777777777777776yb破棄 T0.027777777777777776yaし T0.027777777777777776yaて S0.05555555555555555ycくれる T0.027777777777777776yaで T0.027777777777777776yaす T0.027777777777777776yd電子書籍 T0.027777777777777776yaに T0.027777777777777776yaは T0.027777777777777776ybずっ T0.027777777777777776yaと T0.027777777777777776yb興味 T0.027777777777777776yb持っ T0.027777777777777776ycいまし T0.027777777777777776yaた T0.027777777777777776>vc365<ya0 S0.03225806451612903ya1 S0.03225806451612903ya2 S0.03225806451612903yflucene S0.03225806451612903ya- S0.03225806451612903yegosen S0.03225806451612903yaの S0.03225806451612903yc最新版 S0.03225806451612903ya（ S0.03225806451612903ya. S0.06451612903225806ya） S0.03225806451612903yaを S0.03225806451612903ydリリース S0.03225806451612903ycしまし S0.03225806451612903yaた S0.03225806451612903ya。 S0.06451612903225806ya  S0.06451612903225806yiプロジェクトページ S0.03225806451612903ybより S0.03225806451612903yfダウンロード S0.03225806451612903yaが S0.03225806451612903yb可能 S0.03225806451612903yaで S0.03225806451612903yaす S0.03225806451612903yf新規追加機能 S0.03225806451612903ydについて S0.03225806451612903yaは S0.03225806451612903ycこちら S0.03225806451612903>vc366<ya1 S0.02564102564102564yfすぐやります S0.02564102564102564yaと S0.02564102564102564yd言いつつ S0.02564102564102564ya、 S0.05128205128205128ybはや S0.02564102564102564ybヶ月 S0.02564102564102564ya。 R0.2564102564102564ya  S0.10256410256410256ya腰 S0.02564102564102564yaが S0.02564102564102564yb重い S0.02564102564102564ygダメエンジニア S0.02564102564102564yaで S0.05128205128205128ybすね S0.02564102564102564yeすみません S0.02564102564102564yaし S0.02564102564102564yaた S0.05128205128205128ydようやく S0.02564102564102564yetrunk S0.02564102564102564yaに S0.02564102564102564ydコミット S0.02564102564102564ycしまし S0.02564102564102564ybすぐ S0.02564102564102564>vc367<yd2011 T0.023809523809523808ydJJUG T0.023809523809523808ya  S0.09523809523809523ycCCC T0.023809523809523808ydFall T0.023809523809523808yaに T0.047619047619047616yb参加 T0.023809523809523808yaし T0.023809523809523808yaて T0.023809523809523808ycきまし T0.023809523809523808yaた T0.023809523809523808ya。 S0.07142857142857142yc個人的 T0.023809523809523808yaは T0.023809523809523808yaか T0.023809523809523808ybなり T0.023809523809523808yb久々 T0.023809523809523808yaの S0.07142857142857142ydJava T0.047619047619047616ygカンファレンス T0.023809523809523808yaで T0.047619047619047616yaす T0.023809523809523808ya（ T0.023809523809523808ya※ T0.023809523809523808ydあくまで T0.023809523809523808ya「 T0.023809523809523808ya」 T0.023809523809523808ycという T0.023809523809523808ya話 T0.023809523809523808ydSolr T0.023809523809523808yaや T0.023809523809523808ycHad T0.023809523809523808>vc368<yb昨日 S0.02631578947368421ya、 S0.07894736842105263yb文章 S0.02631578947368421ybから S0.02631578947368421yb特定 S0.02631578947368421yaの S0.02631578947368421yb単語 S0.02631578947368421ya（ S0.02631578947368421ycリスト S0.02631578947368421ybあり S0.02631578947368421ya） S0.02631578947368421yaを S0.05263157894736842yb探し S0.02631578947368421ybたい S0.02631578947368421ycという S0.05263157894736842ya話 S0.05263157894736842yb聞き S0.02631578947368421yflucene S0.02631578947368421ya- S0.02631578947368421yegosen S0.02631578947368421yaで S0.02631578947368421yaも S0.02631578947368421ycできる S0.02631578947368421ybねぇ S0.02631578947368421yaに S0.02631578947368421ydなりまし S0.02631578947368421yaた S0.02631578947368421ya。 S0.02631578947368421ya  S0.02631578947368421ybまぁ S0.02631578947368421yb考え S0.02631578947368421yaて S0.02631578947368421ybみれ S0.02631578947368421>vc369<ycちょっ T0.022727272727272728yaと T0.022727272727272728ya間 T0.022727272727272728yaが S0.06818181818181818ycあいて T0.022727272727272728ycしまっ T0.022727272727272728yaた T0.045454545454545456ya、 T0.022727272727272728ydようやく T0.022727272727272728ybIo T0.022727272727272728yaの S0.13636363636363635yc1日目 T0.022727272727272728yaを T0.022727272727272728yb終了 T0.022727272727272728ya。 T0.045454545454545456ya  T0.045454545454545456ybなれ T0.022727272727272728ybない T0.022727272727272728yb感じ T0.022727272727272728yb言語 T0.022727272727272728yaな T0.022727272727272728yaで T0.022727272727272728yb苦労 T0.022727272727272728yaし T0.022727272727272728ybまし T0.022727272727272728yb今回 T0.022727272727272728yaも T0.022727272727272728ygセルフスタディ T0.022727272727272728ya私 T0.022727272727272728yb回答 T0.022727272727272728yb最後 T0.022727272727272728ya方 T0.022727272727272728yaに T0.022727272727272728ya記 T0.022727272727272728>vc370<yb久々e0.025yaにd0.05ya、d0.05ycMBAe0.025yaのe0.075yc備忘録e0.025yaでd0.05yaすe0.025ya。e0.075ya e0.075ybあれe0.025ybからe0.025yc色々入e0.025yaれe0.025ybましe0.025yaたd0.05ybなのe0.025yb入れe0.025ycソフトe0.025yb一覧e0.025yaをd0.05yb追加e0.025ycAIRe0.025ya：e0.025yiTweetDecke0.025yfインストールe0.025ybするe0.025yb必要e0.025yaだe0.025>vc371<yfLucene T0.027777777777777776ya/ T0.027777777777777776ydSolr S0.05555555555555555yaの S0.08333333333333333ybML T0.027777777777777776yaで T0.027777777777777776yb管理 T0.027777777777777776yb画面 T0.027777777777777776yaを T0.027777777777777776yc新しく T0.027777777777777776ybする T0.027777777777777776ycという T0.027777777777777776ydチケット T0.027777777777777776yaが T0.027777777777777776yb流れ T0.027777777777777776yaて S0.05555555555555555yaい T0.027777777777777776yaた S0.08333333333333333ydでちょっ T0.027777777777777776yaと S0.08333333333333333yb触っ S0.05555555555555555yc見まし T0.027777777777777776ya。 T0.027777777777777776ya  T0.027777777777777776ybほん T0.027777777777777776ydにちょっ T0.027777777777777776ybだけ T0.027777777777777776>vc372<yb遅く T0.019230769230769232ydなりまし T0.019230769230769232yaた T0.038461538461538464yaが T0.038461538461538464ya、 T0.057692307692307696yb続き T0.019230769230769232ybです T0.019230769230769232ya。 S0.07692307692307693ya  T0.038461538461538464ybさら T0.019230769230769232yaに T0.038461538461538464yc英語力 T0.019230769230769232yaの T0.057692307692307696ybなさ T0.019230769230769232yaを T0.038461538461538464yb痛感 T0.019230769230769232yaし T0.019230769230769232yaて T0.038461538461538464yb凹ん T0.019230769230769232yaで T0.057692307692307696ybいる T0.019230769230769232yaと T0.057692307692307696ybころ T0.038461538461538464yaす T0.038461538461538464yb何か T0.019230769230769232ya役 T0.019230769230769232yb立て T0.019230769230769232yaば T0.019230769230769232ya恥 T0.019230769230769232yb晒す T0.019230769230769232yb一応 T0.019230769230769232yb訳し T0.019230769230769232yaみ T0.019230769230769232>vc373<ycちょっ T0.022727272727272728yaと T0.022727272727272728yb興味 T0.022727272727272728yaが T0.022727272727272728ybある T0.022727272727272728yaの S0.11363636363636363yaで T0.045454545454545456ya、 T0.045454545454545456yb訳し T0.022727272727272728yaて S0.06818181818181818ycみまし T0.022727272727272728yaた T0.022727272727272728ya。 T0.045454545454545456ya（ T0.045454545454545456ydWiki T0.022727272727272728ycページ T0.045454545454545456yaは T0.022727272727272728ycこちら T0.022727272727272728ya） T0.022727272727272728ya  T0.022727272727272728yb更新 T0.022727272727272728yaさ T0.022727272727272728yaれ T0.022727272727272728ybいる T0.022727272727272728ybよう T0.022727272727272728yaな T0.022727272727272728ybもと T0.022727272727272728yb文章 T0.022727272727272728yaも T0.022727272727272728yb残し T0.022727272727272728ydおきます T0.022727272727272728yb下部 T0.022727272727272728yb続き T0.022727272727272728>vc374<yd2011 T0.018518518518518517yfHadoop T0.018518518518518517ya  S0.09259259259259259yjConference T0.018518518518518517yeJapan T0.018518518518518517ydFall T0.018518518518518517yaに T0.018518518518518517yb行っ T0.018518518518518517yaて T0.037037037037037035ycきまし T0.018518518518518517yaた S0.07407407407407407ya。 T0.037037037037037035ybまず T0.018518518518518517yaは T0.018518518518518517ya、 S0.07407407407407407ycユーザ T0.018518518518518517ya会 T0.018518518518518517yaの T0.037037037037037035yb方々 S0.05555555555555555yb運営 T0.018518518518518517yb発表 T0.018518518518518517yaさ T0.018518518518518517yaれ T0.018518518518518517yaお T0.018518518518518517yb疲れ T0.018518518518518517ya様 T0.018518518518518517yaで T0.018518518518518517yaし T0.037037037037037035ybこん T0.018518518518518517yaな T0.018518518518518517yb機会 T0.018518518518518517yaを T0.018518518518518517yb用意 T0.018518518518518517yaい T0.018518518518518517ybだき T0.018518518518518517ybあり T0.018518518518518517yaが T0.018518518518518517ybとう T0.018518518518518517>vc375<yb台風 T0.021739130434782608yc15号 T0.021739130434782608yaす T0.043478260869565216ycごかっ T0.021739130434782608yaた S0.08695652173913043yaで S0.08695652173913043ybすね T0.021739130434782608ya。 S0.08695652173913043yb幸い T0.021739130434782608yaに S0.06521739130434782yaも T0.021739130434782608ya（ T0.021739130434782608ya？ T0.021739130434782608ya） T0.021739130434782608yb夏休 T0.021739130434782608yaみ T0.021739130434782608ybだっ T0.021739130434782608yaの T0.021739130434782608ya、 T0.021739130434782608yb通勤 T0.021739130434782608ybなど T0.021739130434782608ycひどい T0.021739130434782608ya目 T0.021739130434782608yb合わ T0.021739130434782608yaず T0.021739130434782608ydすみまし T0.021739130434782608ya  T0.021739130434782608yb風雨 T0.021739130434782608yaは T0.021739130434782608ydすごくて T0.021739130434782608ycちょっ T0.021739130434782608yaと T0.021739130434782608yc怖かっ T0.021739130434782608yaが T0.021739130434782608>vc376<ya3 T0.021739130434782608ya4 T0.021739130434782608ydSolr T0.043478260869565216ya/ T0.021739130434782608yfLucene T0.043478260869565216ya  S0.10869565217391304ya. T0.021739130434782608yaが T0.021739130434782608ydリリース S0.06521739130434782yaさ T0.021739130434782608yaれ T0.021739130434782608ybまし T0.021739130434782608yaた T0.021739130434782608ya。 T0.043478260869565216ya（ T0.021739130434782608yb速報 T0.021739130434782608ya） T0.021739130434782608yb以下 T0.021739130434782608ya、 T0.043478260869565216ya各 T0.021739130434782608ycサイト T0.021739130434782608yaへ T0.021739130434782608yaの S0.08695652173913043ycリンク T0.021739130434782608yaで T0.021739130434782608yaす T0.021739130434782608yaお T0.043478260869565216yc知らせ T0.043478260869565216ycちなみ T0.021739130434782608yaに T0.021739130434782608yb先日 T0.021739130434782608>vc377<ycという T0.022727272727272728ybこと T0.022727272727272728yaで T0.022727272727272728ya、 T0.022727272727272728ydRuby T0.022727272727272728yaの S0.11363636363636363yc最終日 T0.022727272727272728yb感想 T0.022727272727272728ya。 S0.06818181818181818ya  T0.045454545454545456yb今回 T0.022727272727272728yaも T0.022727272727272728ygセルフスタディ T0.022727272727272728ya私 T0.022727272727272728yb回答 T0.022727272727272728yaが T0.022727272727272728yb最後 T0.022727272727272728ya方 T0.022727272727272728yaに T0.022727272727272728yb記載 T0.022727272727272728yaさ T0.022727272727272728yaれ T0.022727272727272728yaて T0.022727272727272728ybます T0.022727272727272728ya見 T0.022727272727272728ybたく T0.022727272727272728ybない T0.022727272727272728ya人 T0.022727272727272728yaは T0.022727272727272728ya気 T0.022727272727272728yaを T0.022727272727272728ycつけて T0.022727272727272728yaく T0.022727272727272728yaだ T0.022727272727272728ybさい T0.022727272727272728ydツッコミ T0.022727272727272728ya大 T0.022727272727272728>vc378<ya「 S0.02040816326530612ya第 S0.04081632653061224yb6回 S0.04081632653061224ydSolr S0.02040816326530612yc勉強会 S0.02040816326530612ya」 S0.02040816326530612yaに S0.04081632653061224yb参加 S0.02040816326530612yaし S0.02040816326530612ybまし S0.02040816326530612yaた S0.04081632653061224ya。 T0.061224489795918366ya  T0.061224489795918366ybなん S0.02040816326530612ycだかん S0.02040816326530612yaだ S0.02040816326530612yaと S0.02040816326530612yaで S0.10204081632653061ya、 T0.061224489795918366ya今 S0.02040816326530612yaの S0.04081632653061224ycところ S0.02040816326530612yc皆勤賞 S0.02040816326530612yaす S0.04081632653061224ycという S0.02040816326530612ybこと S0.02040816326530612ya主 S0.02040816326530612yc自分用 S0.02040816326530612yaが S0.02040816326530612ybメモ S0.02040816326530612ybなど S0.02040816326530612ybとっ S0.02040816326530612ya概 S0.02040816326530612>vc379<ycという T0.023255813953488372ybこと T0.023255813953488372yaで T0.046511627906976744ya、 T0.023255813953488372ygRuby2日目 T0.023255813953488372yaの S0.11627906976744186yb感想 T0.023255813953488372ya（ T0.023255813953488372yc2日目 T0.023255813953488372ybだけ T0.023255813953488372yc2日間 T0.023255813953488372yaか T0.023255813953488372ybかっ T0.023255813953488372yaた T0.046511627906976744yaは T0.023255813953488372yb内緒 T0.023255813953488372ya。 S0.09302325581395349ya） T0.023255813953488372ya  T0.023255813953488372yb今回 T0.023255813953488372yaも T0.023255813953488372ygセルフスタディ T0.023255813953488372ya私 T0.023255813953488372yb回答 T0.023255813953488372yaが T0.023255813953488372yb最後 T0.023255813953488372ya方 T0.023255813953488372yaに T0.023255813953488372yb記載 T0.023255813953488372yaさ T0.023255813953488372yaれ T0.023255813953488372yaて T0.023255813953488372ybます T0.023255813953488372ya見 T0.023255813953488372>vc380<ya実 T0.024390243902439025yaに S0.04878048780487805yb3年 T0.024390243902439025yeぶりくらい T0.024390243902439025ydゆっくり T0.024390243902439025ycできる T0.024390243902439025yb日々 T0.024390243902439025yaが T0.024390243902439025yb訪れ T0.024390243902439025yaた S0.04878048780487805yaの R0.0975609756097561yaで T0.024390243902439025ya、 T0.024390243902439025yd積読状態 T0.024390243902439025ya本 T0.024390243902439025yaを S0.04878048780487805yb消化 T0.024390243902439025yaし T0.024390243902439025ybよう T0.024390243902439025yaと T0.024390243902439025ya「 T0.024390243902439025yb7つ S0.04878048780487805yb言語 T0.024390243902439025ya  S0.04878048780487805yb世界 T0.024390243902439025ya」 T0.024390243902439025yb読み T0.024390243902439025yd始めまし T0.024390243902439025ya。 T0.024390243902439025ydせっかく T0.024390243902439025ycブログ T0.024390243902439025yaも T0.024390243902439025yb始め T0.024390243902439025>vc381<yb現在 T0.030303030303030304yaの S0.09090909090909091yb出先 T0.030303030303030304yaで S0.09090909090909091ycMBA S0.06060606060606061yaを S0.06060606060606061yb使え T0.030303030303030304ybない S0.06060606060606061ya、 S0.09090909090909091ybなか S0.06060606060606061yb進ん T0.030303030303030304ybでい T0.030303030303030304yfセットアップ T0.030303030303030304yaす T0.030303030303030304ya。 S0.09090909090909091ya  T0.030303030303030304ybとり T0.030303030303030304ycあえず T0.030303030303030304ygEclipse T0.030303030303030304yhhomebrew T0.030303030303030304yeインストー T0.030303030303030304>vc382<ybすぐ S0.02564102564102564yaに S0.02564102564102564yfテストケース S0.05128205128205128yb追加 S0.02564102564102564yaし S0.05128205128205128ybます S0.02564102564102564yeといいつつ S0.02564102564102564ya、 S0.07692307692307693ybはや S0.02564102564102564yc一週間 S0.02564102564102564ya。 S0.07692307692307693ya  S0.05128205128205128ydようやく S0.02564102564102564yb仕事 S0.02564102564102564yaが S0.02564102564102564yb落ち S0.02564102564102564yb着い S0.02564102564102564yaた S0.05128205128205128yaの S0.05128205128205128yaで S0.05128205128205128yaを S0.02564102564102564yb追記 S0.02564102564102564ybまし S0.02564102564102564ybまだ S0.02564102564102564ycパッチ S0.02564102564102564yb段階 S0.02564102564102564yaす S0.02564102564102564yb一応 S0.02564102564102564ya異 S0.02564102564102564>vc383<yb先日 S0.02702702702702703ya、 S0.05405405405405406yb辞書 S0.02702702702702703yaの S0.08108108108108109ycjar S0.02702702702702703ydファイル S0.02702702702702703ybから S0.02702702702702703yb分離 S0.02702702702702703ydについて S0.02702702702702703ycパッチ S0.05405405405405406yaと S0.02702702702702703yb記事 S0.02702702702702703yaを S0.05405405405405406yd書きまし S0.02702702702702703yaた S0.05405405405405406ya。 S0.02702702702702703ya  S0.02702702702702703yeIssue S0.02702702702702703yaに S0.02702702702702703ybあげ S0.02702702702702703yaて S0.05405405405405406yaい S0.05405405405405406yfRobert S0.02702702702702703ybさん S0.02702702702702703yaが S0.02702702702702703ya見 S0.02702702702702703ydたらしく S0.02702702702702703ya次 S0.02702702702702703yaよ S0.02702702702702703>vc384<ydひさびさg0.03125yaにg0.09375ya、f0.0625yflucenef0.0625ya-f0.0625yegosenf0.0625yaのg0.03125yb話題g0.03125yaでg0.03125yaすg0.03125ya。g0.03125ya g0.03125yaはg0.03125ycjarf0.0625ydファイルf0.0625yb辞書g0.03125yaもg0.03125yb同梱g0.03125yaさg0.03125yaれg0.03125yaてg0.03125ybおりg0.03125yaをg0.03125yeクラスパスg0.03125>vc385<yeすみません S0.02631578947368421ya、 S0.10526315789473684ybまた S0.02631578947368421ycMBA S0.02631578947368421yb関連 S0.02631578947368421yaの S0.07894736842105263yb記事 S0.02631578947368421yaに S0.02631578947368421ybなっ S0.02631578947368421yaて S0.02631578947368421yeしまいまし S0.02631578947368421yaた S0.05263157894736842ya。 S0.05263157894736842ya  S0.05263157894736842ycという S0.02631578947368421ybこと S0.02631578947368421yaで S0.05263157894736842yc備忘録 S0.02631578947368421ybその S0.02631578947368421ya２ S0.02631578947368421ybです S0.02631578947368421yb前回 S0.02631578947368421yfからいくつか S0.02631578947368421yfインストール S0.02631578947368421yaや S0.02631578947368421yb環境 S0.02631578947368421yb設定 S0.02631578947368421yaを S0.02631578947368421yaし S0.02631578947368421>vc386<ycMac S0.02127659574468085ya  R0.1276595744680851ydBook S0.02127659574468085ycAir S0.02127659574468085yaの S0.06382978723404255yfセットアップ S0.02127659574468085yb関連 S0.02127659574468085yc備忘録 R0.0425531914893617ya（ R0.0425531914893617yb今回 S0.02127659574468085yaは S0.02127659574468085yaな S0.02127659574468085yaで S0.02127659574468085ya、 R0.0425531914893617yb文体 S0.02127659574468085yaも R0.0425531914893617yb変か S0.02127659574468085ya） R0.0425531914893617yfインストール S0.02127659574468085yaし R0.0425531914893617yaた R0.0425531914893617ybもの S0.02127659574468085yc順不同 S0.02127659574468085ybだい S0.02127659574468085ybたい S0.02127659574468085ybこの S0.02127659574468085ycサイト S0.02127659574468085yaを S0.02127659574468085yb参考 S0.02127659574468085yaに S0.02127659574468085ya。 S0.02127659574468085yhEvernote S0.02127659574468085ygDropbox S0.02127659574468085>vc387<yc個人用e0.025yaのd0.05ybPCe0.075yaをd0.05yb８年d0.05ybぶりe0.025yaにe0.075yb新調e0.025yaしd0.05ybましe0.025yaたd0.05ya。e0.025ya d0.05yd前回購入e0.025ya家e0.025yfデスクトップe0.025yaがe0.025ybもうe0.025ybものe0.025ydなりつつe0.025ybあるe0.025ycというe0.025ybことe0.025yaでe0.025ya、e0.025ycさすがe0.025yb今年e0.025yaはe0.025yc買おうe0.025yaとe0.025>vc388<ycかなり S0.02631578947368421yb遅く S0.02631578947368421ydなりまし S0.02631578947368421yaた S0.05263157894736842yaが S0.05263157894736842ya、 S0.05263157894736842ya第 S0.02631578947368421yb1回 S0.02631578947368421ya  S0.07894736842105263ycデータ S0.02631578947368421yb構造 S0.02631578947368421yaと S0.05263157894736842yb情報 S0.02631578947368421yb検索 S0.02631578947368421yg言語処理勉強会 S0.02631578947368421ya# S0.02631578947368421ygDSIRNLP S0.02631578947368421yaに S0.02631578947368421yb参加 S0.02631578947368421yaし S0.02631578947368421ybまし S0.02631578947368421ya。 S0.02631578947368421yb帰っ S0.02631578947368421yaて S0.02631578947368421ybから S0.02631578947368421yc２日半 S0.02631578947368421ybほど S0.02631578947368421yb寝込 S0.02631578947368421yaん S0.02631578947368421yaで S0.02631578947368421ycしまい S0.02631578947368421yb更新 S0.02631578947368421>vc389<yb以前 S0.02564102564102564ybから S0.02564102564102564yb春山 S0.02564102564102564ybさん S0.02564102564102564yaの S0.05128205128205128ycブログ S0.02564102564102564ya（ S0.02564102564102564ycリンク S0.02564102564102564ya） S0.02564102564102564yaや S0.02564102564102564yc勉強会 S0.02564102564102564yaで S0.07692307692307693ya耳 S0.02564102564102564yaに S0.05128205128205128yaは S0.05128205128205128yaし S0.05128205128205128yaて S0.02564102564102564yaい S0.02564102564102564yaた S0.05128205128205128yaす S0.02564102564102564yaが S0.02564102564102564ycソース S0.02564102564102564yb読ん S0.02564102564102564yeでいません S0.02564102564102564ya。 S0.02564102564102564ya  S0.02564102564102564yb先日 S0.02564102564102564ya、 S0.02564102564102564yfLucene S0.02564102564102564yjcontribute S0.02564102564102564yaさ S0.02564102564102564yaれ S0.02564102564102564>vc390<yb忘れ T0.022727272727272728yaて S0.06818181818181818ycしまう T0.022727272727272728yaの T0.045454545454545456yaで T0.045454545454545456ya、 S0.06818181818181818yc備忘録 T0.022727272727272728yaを T0.045454545454545456yb残し T0.022727272727272728ydおきます T0.022727272727272728ya。 T0.045454545454545456ya  T0.045454545454545456yb一応 T0.022727272727272728ycソース T0.022727272727272728yaに T0.045454545454545456yaは S0.09090909090909091yd少しずつ T0.022727272727272728ydコメント T0.022727272727272728ybいれ T0.022727272727272728ybいる T0.022727272727272728yaす T0.022727272727272728yaが S0.06818181818181818ya私 T0.022727272727272728yb残念 T0.022727272727272728yaな T0.022727272727272728yaら T0.022727272727272728yf自然言語処理 T0.022727272727272728yc初心者 T0.022727272727272728ya毛 T0.022727272727272728>vc391<ya1 S0.08333333333333333yflucene T0.027777777777777776ya- T0.027777777777777776yegosen T0.027777777777777776ya  S0.08333333333333333ya. S0.05555555555555555yaを S0.08333333333333333ydリリース T0.027777777777777776ycしまし S0.05555555555555555yaた S0.08333333333333333ya。 S0.05555555555555555yb先日 T0.027777777777777776yeお知らせし T0.027777777777777776ybバグ T0.027777777777777776yb修正 T0.027777777777777776yb取り T0.027777777777777776yb込ん T0.027777777777777776yaだ T0.027777777777777776ycjar T0.027777777777777776yb用意 T0.027777777777777776yaい T0.027777777777777776yfダウンロード T0.027777777777777776yaは T0.027777777777777776ycこちら T0.027777777777777776ybから T0.027777777777777776>vc392<ya3 T0.045454545454545456ydSolr T0.045454545454545456ya/ T0.022727272727272728yfLucene T0.045454545454545456ya  S0.11363636363636363ya. T0.022727272727272728yaが T0.022727272727272728ydリリース S0.09090909090909091yaさ T0.022727272727272728yaれ T0.022727272727272728ybまし T0.022727272727272728yaた T0.022727272727272728ya。 T0.045454545454545456ya（ T0.022727272727272728yb速報 T0.022727272727272728ya） T0.022727272727272728yb以下 T0.022727272727272728ya、 T0.022727272727272728ya各 T0.022727272727272728ycサイト T0.022727272727272728yaへ T0.022727272727272728yaの S0.09090909090909091ycリンク T0.022727272727272728yaで T0.022727272727272728yaす T0.022727272727272728yaお T0.045454545454545456yc知らせ T0.045454545454545456ycタイミ T0.022727272727272728>vc393<yc300 T0.029411764705882353ya「 T0.029411764705882353yfHadoop T0.029411764705882353yaを T0.029411764705882353yb中心 T0.029411764705882353yaと T0.029411764705882353yaし T0.058823529411764705yaた T0.058823529411764705yb分散 T0.029411764705882353yb環境 T0.029411764705882353yaで T0.029411764705882353yaの T0.058823529411764705ye開発方法論 T0.029411764705882353ya・ T0.058823529411764705yeモデリング T0.029411764705882353ye設計手法等 T0.029411764705882353ydについて T0.029411764705882353yc座談会 T0.029411764705882353ya( T0.029411764705882353ya第 T0.029411764705882353yb5回 T0.029411764705882353ya） T0.029411764705882353ya」 T0.029411764705882353yaに T0.029411764705882353yb参加 T0.029411764705882353ybまし T0.029411764705882353ya。 T0.029411764705882353ya名 T0.029411764705882353yb入る T0.029411764705882353yfイベントルー T0.029411764705882353>vc394<yb以前 S0.02631578947368421ya、 S0.02631578947368421ycこちら S0.02631578947368421yaで S0.05263157894736842yb話題 S0.02631578947368421yaに S0.05263157894736842yc上がっ S0.02631578947368421yaて S0.05263157894736842yaい S0.02631578947368421yaた S0.07894736842105263ya「 S0.02631578947368421yc未知語 S0.02631578947368421ya」 S0.02631578947368421yc関する S0.02631578947368421ylcompositePOS S0.02631578947368421yaの S0.05263157894736842ycエラー S0.02631578947368421ya件 S0.02631578947368421yaを S0.02631578947368421yb調査 S0.02631578947368421yaし S0.02631578947368421ybまし S0.05263157894736842ya。 S0.05263157894736842ya（ S0.02631578947368421ygTwitter S0.02631578947368421yaも S0.02631578947368421yb流れ S0.02631578947368421ya） S0.02631578947368421ya  S0.02631578947368421ya次 S0.02631578947368421>vc395<yflucened0.04ya-d0.16yegosend0.04yaのd0.08ymtrunkbranchesd0.04ya/d0.04ydimpld0.04yemecabd0.04ycdicd0.04yaにd0.04yeNAISTd0.04ydJDicd0.04ya d0.08ycford0.04yeMeCabd0.04yb辞書d0.04yaをd0.04yb利用d0.04yc出来るd0.04ycPred0.04>vc396<yb前回 T0.029411764705882353ya、 S0.08823529411764706yenaist T0.029411764705882353ya- T0.029411764705882353yfchasen T0.029411764705882353yaで T0.029411764705882353yaは T0.029411764705882353ygアルファベット T0.029411764705882353yaが T0.058823529411764705yb別々 T0.029411764705882353yaの T0.029411764705882353yb単語 T0.029411764705882353ycとして T0.029411764705882353yganalyze T0.029411764705882353yaさ T0.029411764705882353yaれ T0.029411764705882353yaて T0.029411764705882353ycしまう T0.029411764705882353ycという T0.029411764705882353ya話 T0.029411764705882353yaを T0.029411764705882353ycしまし T0.029411764705882353yaた T0.029411764705882353ya。 T0.029411764705882353ya  T0.029411764705882353ybただ T0.029411764705882353ybこれ T0.029411764705882353yaだ T0.029411764705882353yaと T0.029411764705882353yc英単語 T0.029411764705882353yb含ま T0.029411764705882353>vc397<ya0 S0.03225806451612903ya1 S0.06451612903225806yflucene S0.03225806451612903ya- S0.03225806451612903yegosen S0.03225806451612903yaの S0.03225806451612903ya. S0.06451612903225806yaが S0.06451612903225806ydリリース S0.03225806451612903yaさ S0.03225806451612903yaれ S0.03225806451612903ybまし S0.03225806451612903yaた S0.03225806451612903ya。 S0.03225806451612903ya  S0.03225806451612903yb大き S0.03225806451612903yaな S0.03225806451612903yb目玉 S0.03225806451612903yaは S0.03225806451612903y QJapaneseTokenizer S0.03225806451612903yb出力 S0.03225806451612903ybする S0.03225806451612903yc形態素 S0.03225806451612903yaに S0.03225806451612903yc関する S0.03225806451612903ycデータ S0.03225806451612903yaを S0.03225806451612903yb遅延 S0.03225806451612903>vc398<yflucene T0.043478260869565216ya- T0.043478260869565216yegosen T0.043478260869565216yaを S0.08695652173913043ydSolr T0.043478260869565216ya/ T0.043478260869565216yfLucene T0.043478260869565216yaで T0.043478260869565216yb利用 S0.08695652173913043ybする T0.043478260869565216yb場合 T0.043478260869565216ya、 T0.043478260869565216ykTokenFilter T0.043478260869565216yaし S0.08695652173913043yaて T0.043478260869565216yiTokenizer T0.043478260869565216yaが T0.043478260869565216yb出力 T0.043478260869565216yaた T0.043478260869565216yhToken対して T0.043478260869565216>vc399<yb辞書 S0.07894736842105263yaの S0.10526315789473684yb特性 S0.02631578947368421ydについて S0.07894736842105263ya  S0.10526315789473684yb現在 S0.02631578947368421yflucene S0.02631578947368421ya- S0.02631578947368421yegosen S0.02631578947368421yaで S0.05263157894736842yaは S0.02631578947368421yb以下 S0.02631578947368421yb2つ S0.02631578947368421yaが S0.02631578947368421yb利用 S0.02631578947368421yb可能 S0.02631578947368421yaす S0.02631578947368421ya。 S0.05263157894736842yb簡単 S0.02631578947368421yaに S0.02631578947368421yb違い S0.02631578947368421yb説明 S0.02631578947368421yaし S0.02631578947368421ybます S0.02631578947368421yfIPAdic S0.02631578947368421yaバ S0.02631578947368421>vc400<yb今回 T0.030303030303030304yaは S0.06060606060606061ycソース S0.09090909090909091yaの S0.06060606060606061yfダウンロード S0.06060606060606061yaと T0.030303030303030304ycビルド S0.06060606060606061ydについて T0.030303030303030304yaで T0.030303030303030304yaす S0.06060606060606061ya。 T0.030303030303030304ya  T0.030303030303030304yc最新版 T0.030303030303030304yaを S0.09090909090909091yb利用 T0.030303030303030304yaし S0.06060606060606061ybたり T0.030303030303030304ya、 T0.030303030303030304ygJavaDoc T0.030303030303030304yc見たい T0.030303030303030304yb場合 T0.030303030303030304yaて T0.030303030303030304ybから T0.030303030303030304>vc401<yb概要 S0.03333333333333333ya： S0.06666666666666667ya  S0.13333333333333333yfLucene S0.03333333333333333ya/ S0.03333333333333333ydSolr S0.03333333333333333yaの S0.06666666666666667yeコミッター S0.03333333333333333yaで S0.03333333333333333ybある S0.03333333333333333yfRobert S0.03333333333333333ydMuir S0.03333333333333333ybさん S0.03333333333333333yaが S0.03333333333333333yb始め S0.03333333333333333yaた S0.06666666666666667yfプロジェクト S0.03333333333333333yb歴史 S0.03333333333333333yeMeCab S0.03333333333333333ydJava S0.03333333333333333yc移植版 S0.03333333333333333ycとして S0.03333333333333333ydスタート S0.03333333333333333yaし S0.03333333333333333>vc402<yc今さら T0.041666666666666664yaで S0.08333333333333333yaすf0.0625yaがf0.0625ya、 T0.041666666666666664ycブログ T0.020833333333333332yaを T0.041666666666666664ycはじめ T0.020833333333333332yaて T0.020833333333333332yaみ T0.041666666666666664ybよう T0.041666666666666664yaか T0.020833333333333332yaと T0.041666666666666664ya。 T0.041666666666666664ya… T0.020833333333333332ya  T0.041666666666666664ydはじめて T0.020833333333333332yb思っ T0.020833333333333332yaた T0.041666666666666664yb一番 T0.020833333333333332yaの T0.020833333333333332yb理由 T0.020833333333333332yaは T0.020833333333333332yb自分 T0.020833333333333332yb調べ T0.020833333333333332ybこと T0.020833333333333332ybメモ T0.020833333333333332ybわり T0.020833333333333332yaに T0.020833333333333332yb残す T0.020833333333333332ybため T0.020833333333333332ybあと T0.020833333333333332>>vdtags<va12yb振りc0.5yb返りc0.5va21yfsearchQva31ycbotQva41ymelasticsearchQva51yb画面Qva63ycdev R0.3333333333333333ya  R0.3333333333333333yicontainer R0.3333333333333333va73ycdev R0.3333333333333333ya  R0.3333333333333333yicontainer R0.3333333333333333va81ygwindowsQva93ycdev R0.3333333333333333ya  R0.3333333333333333yicontainer R0.3333333333333333vb103ycdev R0.3333333333333333ya  R0.3333333333333333yicontainer R0.3333333333333333vb111yfpythonQvb123yebelin R0.3333333333333333ya  R0.3333333333333333yibuzzwords R0.3333333333333333vb132yb振りc0.5yb返りc0.5vb141yemusicQvb151yjopensearchQvb161yfluceneQvb171ymelasticsearchQvb181ydhugoQvb191ymelasticsearchQvb201ymelasticsearchQvb213yfberlin R0.3333333333333333ya  R0.3333333333333333yibuzzwords R0.3333333333333333vb221ydjavaQvb233yeazure R0.3333333333333333ya  R0.3333333333333333yfsearch R0.3333333333333333vb241yepaperQvb252yb振りc0.5yb返りc0.5vb261ydmiscQvb271ydmiscQvb281ydmiscQvb291yepaperQvb301yeMICESQvb313yfberlin R0.3333333333333333ya  R0.3333333333333333yibuzzwords R0.3333333333333333vb323yeazure R0.3333333333333333ya  R0.3333333333333333yfsearch R0.3333333333333333vb331ydmiscQvb341yc勉強会Qvb351yc勉強会Qvb361ymelasticsearchQvb371ydmiscQvb383yeazure R0.3333333333333333ya  R0.3333333333333333yfsearch R0.3333333333333333vb393ya2 R0.3333333333333333ydNand R0.3333333333333333yfTetris R0.3333333333333333vb401ydmiscQvb411ydmiscQvb421ydmiscQvb432yb振りc0.5yb返りc0.5vb441ymelasticsearchQvb451ydmiscQvb461ydmiscQvb471ygwindowsQvb481ygwindowsQvb491ydmiscQvb501ygLinderaQvb511yb検索Qvb521ydmiscQvb531ydRustQvb542yc100c0.5ycnlpc0.5vb552yc100c0.5ycnlpc0.5vb563yeazure R0.3333333333333333ya  R0.3333333333333333yfsearch R0.3333333333333333vb571yb検索Qvb581yb検索Qvb594ydrustc0.2ya-c0.4ycthec0.2ydbookc0.2vb603yfberlin R0.3333333333333333ya  R0.3333333333333333yibuzzwords R0.3333333333333333vb611yfluceneQvb621yfluceneQvb631yhkuromojiQvb644ydrustc0.2ya-c0.4ycthec0.2ydbookc0.2vb654ydrustc0.2ya-c0.4ycthec0.2ydbookc0.2vb662ya.c0.5ycnetc0.5vb673yeazure R0.3333333333333333ya  R0.3333333333333333yfsearch R0.3333333333333333vb683ygelastic R0.3333333333333333ya  R0.3333333333333333yestack R0.3333333333333333vb694ydrustc0.2ya-c0.4ycthec0.2ydbookc0.2vb702yc100c0.5ycnlpc0.5vb712yc100c0.5ycnlpc0.5vb722yc100c0.5ycnlpc0.5vb733yiworkplace R0.3333333333333333ya  R0.3333333333333333yfsearch R0.3333333333333333vb743yiworkplace R0.3333333333333333ya  R0.3333333333333333yfsearch R0.3333333333333333vb751ymelasticsearchQvb761ymelasticsearchQvb774ydrustc0.2ya-c0.4ycthec0.2ydbookc0.2vb782yc100c0.5ycnlpc0.5vb792yc100c0.5ycnlpc0.5vb804ydrustc0.2ya-c0.4ycthec0.2ydbookc0.2vb811ydmiscQvb824ydrustc0.2ya-c0.4ycthec0.2ydbookc0.2vb831ydmiscQvb844ydrustc0.2ya-c0.4ycthec0.2ydbookc0.2vb854yfvisualc0.2ya c0.4yfstudioc0.2ydcodec0.2vb864ydrustc0.2ya-c0.4ycthec0.2ydbookc0.2vb874yfvisualc0.2ya c0.4yfstudioc0.2ydcodec0.2vb881yb読書Qvb891ydmiscQvb901yb読書Qvb912yb買いc0.5ya物c0.5vb921ycブログQvb933yeazure R0.3333333333333333ya  R0.3333333333333333yfsearch R0.3333333333333333vb943yb検索 R0.3333333333333333ydシステム R0.3333333333333333yb探訪 R0.3333333333333333vb951ycゲームQvb961yb読書Qvb971yb転職Qvb981ycブログQvb991ycブログQvc1001ycブログQvc1011ycブログQvc1021yioctopressQvc1032yb振りc0.5yb返りc0.5vc1041ydmiscQvc1051ydmiscQvc1061ydmiscQvc1071yioctopressQvc1081yb転職Qvc1091yfLuceneQvc1101ymelasticsearchQvc1111yc勉強会Qvc1121yb書籍Qvc1131yc勉強会Qvc1141yc勉強会Qvc1151yb検索Qvc1162yb振りc0.5yb返りc0.5vc1171ymelasticsearchQvc1181ymelasticsearchQvc1191ydmiscQvc1201yc勉強会Qvc1211yc勉強会Qvc1221yfpluginQvc1231yeスポンサーQvc1242yc100c0.5ycnlpc0.5vc1252yc100c0.5ycnlpc0.5vc1262yc100c0.5ycnlpc0.5vc1272yc100c0.5ycnlpc0.5vc1281yfpluginQvc1291yfpluginQvc1302yb振りc0.5yb返りc0.5vc1311ymelasticsearchQvc1321ymelasticsearchQvc1341ya本Qvc1351yc勉強会Qvc1362yb振りc0.5yb返りc0.5vc1371ymelasticsearchQvc1381ymelasticsearchQvc1391yfpluginQvc1401ydmiscQvc1411yc勉強会Qvc1421yc勉強会Qvc1431ya本Qvc1441yc勉強会Qvc1452yb振りc0.5yb返りc0.5vc1461ymelasticsearchQvc1471yhtimelionQvc1481yc勉強会Qvc1491yesenseQvc1501yfmarvelQvc1511ymelasticsearchQvc1521yfkibanaQvc1531yhlogstashQvc1541yhlogstashQvc1551ymelasticsearchQvc1561ymelasticsearchQvc1571ymelasticsearchQvc1581ymelasticsearchQvc1591yc勉強会Qvc1601ymelasticsearchQvc1611ymelasticsearchQvc1621ymelasticsearchQvc1631ymelasticsearchQvc1641ymelasticsearchQvc1653yefound R0.3333333333333333ya. R0.3333333333333333ybno R0.3333333333333333vc1661yc勉強会Qvc1671yc勉強会Qvc1681ymelasticsearchQvc1691yc勉強会Qvc1701ymelasticsearchQvc1721ymelasticsearchQvc1731yc勉強会Qvc1741ymelasticsearchQvc1751yc勉強会Qvc1761ymelasticsearchQvc1771yielasticonQvc1781yfshieldQvc1791ymelasticsearchQvc1802ya4c0.5yfkibanac0.5vc1811ymelasticsearchQvc1821yc勉強会Qvc1831yc勉強会Qvc1841ymelasticsearchQvc1851ymelasticsearchQvc1861ymelasticsearchQvc1872yb振りc0.5yb返りc0.5vc1881ymelasticsearchQvc1891yfmarvelQvc1901ymelasticsearchQvc1911ydjjugQvc1921yfcoffeeQvc1931yhlogstashQvc1941yhlogstashQvc1951ymelasticsearchQvc1961ymelasticsearchQvc1971ymelasticsearchQvc1981ymelasticsearchQvc1991yc勉強会Qvc2001ymelasticsearchQvc2011ymelasticsearchQvc2021yhsonatypeQvc2031ymElasticsearchQvc2041yc勉強会Qvc2051ya本Qvc2061ymElasticsearchQvc2071ya本Qvc2081yfpluginQvc2091ygreleaseQvc2101ygcuratorQvc2111yc勉強会Qvc2121yb転職Qvc2131yb転職Qvc2141ya本Qvc2151yc勉強会Qvc2161ymelasticsearchQvc2171ycAWSQvc2181ygスピリチュアルQvc2191yeオライリーQvc2201ymelasticsearchQvc2211yfpluginQvc2223ya2 R0.3333333333333333yfstream R0.3333333333333333ybes R0.3333333333333333vc2231yc勉強会Qvc2241yfpluginQvc2251yc勉強会Qvc2261yfpluginQvc2271yfpluginQvc2281ymelasticsearchQvc2291yc勉強会Qvc2301yftravelQvc2311yfpluginQvc2321ymelasticsearchQvc2331ymelasticsearchQvc2341yc勉強会Qvc2351yfmarvelQvc2361yc勉強会Qvc2371yfmarvelQvc2383yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc2391ygcuratorQvc2401ymelasticsearchQvc2412yb振りc0.5yb返りc0.5vc2421yhkuromojiQvc2431ydSolrQvc2441ymelasticsearchQvc2451ydSolrQvc2461ydSolrQvc2471yfpluginQvc2481yc勉強会Qvc2491ygNorikraQvc2501yhYokozunaQvc2511yfpluginQvc2521yfpluginQvc2531yjManifoldCFQvc2541yfpluginQvc2551yiwikipediaQvc2561yiwikipediaQvc2571yc勉強会Qvc2581yiwikipediaQvc2591ydSolrQvc2603yfXperia R0.3333333333333333ya  R0.3333333333333333yaZ R0.3333333333333333vc2611ydSolrQvc2621yjManifoldCFQvc2631yeオライリーQvc2641yhYokozunaQvc2651ydSolrQvc2661ydSolrQvc2671ydSolrQvc2681yfkibanaQvc2691ydSolrQvc2701ydSolrQvc2711ygfluentdQvc2721yc勉強会Qvc2731ydSolrQvc2741ycAWSQvc2753yhCloudera R0.3333333333333333ya  R0.3333333333333333yfSearch R0.3333333333333333vc2763yhCloudera R0.3333333333333333ya  R0.3333333333333333yfSearch R0.3333333333333333vc2771ygfluentdQvc2781ydmiscQvc2791ydmiscQvc2803yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc2811yb読書Qvc2821ydsolrQvc2831ydsolrQvc2841yc勉強会Qvc2851yc備忘録Qvc2861yc勉強会Qvc2871yc勉強会Qvc2881ymelasticsearchQvc2891yc勉強会Qvc2901yc備忘録Qvc2911yc勉強会Qvc2921yc勉強会Qvc2931yc勉強会Qvc2941yb読書Qvc2951yc備忘録Qvc2961ydJIRAQvc2971yc勉強会Qvc2981yc勉強会Qvc2991yc勉強会Qvc3001yc勉強会Qvc3013yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3021yc勉強会Qvc3031yc勉強会Qvc3041yc備忘録Qvc3051yc勉強会Qvc3061yc勉強会Qvc3071yc勉強会Qvc3081ydsolrQvc3091yc勉強会Qvc3103yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3111yc勉強会Qvc3133yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3141yfZipkinQvc3151yfZipkinQvc3161ydsolrQvc3171ycOSSQvc3183yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3193yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3203yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3211ydmiscQvc3221yc勉強会Qvc3231yc備忘録Qvc3243yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3251yb読書Qvc3261yc勉強会Qvc3271ydsolrQvc3281ydsolrQvc3291ydsolrQvc3301yc備忘録Qvc3311yc勉強会Qvc3323yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3333yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3343yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3351yc備忘録Qvc3361yc勉強会Qvc3371yb読書Qvc3381yeScalaQvc3391yc勉強会Qvc3401yb読書Qvc3411yb読書Qvc3421yc勉強会Qvc3433yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3441yc勉強会Qvc3451yc勉強会Qvc3461yc備忘録Qvc3471yc勉強会Qvc3481yc勉強会Qvc3491yc勉強会Qvc3503yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3511ydmiscQvc3521ydmiscQvc3531yc勉強会Qvc3543yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3551yc勉強会Qvc3571yc備忘録Qvc3581yb読書Qvc3591yc勉強会Qvc3603yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3611yc勉強会Qvc3621ydmiscQvc3631ydsolrQvc3641ydmiscQvc3653yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3663yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3671yc備忘録Qvc3683yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3701yc備忘録Qvc3711ydsolrQvc3721ydsolrQvc3731ydsolrQvc3741yfhadoopQvc3751yb読書Qvc3761ydsolrQvc3771yb読書Qvc3781yc勉強会Qvc3791yb読書Qvc3801yb読書Qvc3811yc備忘録Qvc3823yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3833yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3843yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3851yc備忘録Qvc3861yc備忘録Qvc3871yc備忘録Qvc3881yc勉強会Qvc3891ye形態素解析Qvc3903yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3913yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3921ydsolrQvc3931yfhadoopQvc3943yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3953yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3963yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3973yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3983yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3993yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc4003yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc4013yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc4021ydmiscQ>v PtokenOccurrences4vbid<ya0Uya1Qya2Jya3Nya4Qya5Kya6Nya7Qya8Pya9Jyb13Qyb15Qyb25Qyb30Qyb32Qyb35Qyb40Qyb42Qyb50Qyb55Ryb57Qyb61Ryb62Qyb63Qyb66Ryb68Qyb79Qyb84Qyb86Qyb92Ryc115Qyc120Qyc121Qyc122Qyc127Ryc130Qyc133Qyc135Qyc140Qyc145Ryc150Qyc152Qyc153Qyc160Qyc177Ryc181Qyc188Qyc198Qyc199Qyc208Qyc219Ryc220Qyc226Qyc227Qyc230Ryc231Qyc232Qyc234Qyc240Ryc242Qyc252Qyc257Qyc258Qyc264Qyc265Ryc289Qyc292Qyc293Qyc298Qyc299Qyc301Qyc302Qyc303Qyc307Qyc309Qyc314Qyc318Qyc321Qyc322Qyc323Qyc333Qyc349Qyc350Qyc351Ryc353Qyc356Qyc362Qyc365Qyc373Qyc386Qyc388Qyc389Ryc399Ryc400Qyc403Qyc405Qyc407Ryc409Qyc410Qyc414Qyc415Ryc417Qyc418Qyc421Qyc423Qyc426Qyc431Qyc432Qyc433Qyc435Qyc443Qyc444Ryc455Qyc459Tyc463Qyc464Qyc465Ryc466Ryc470Qyc475Ryc479Ryc481Qyc482Syc491Qyc493Qyc501Qyc505Ryc508Qyc509Qyc512Qyc517Qyc521Ryc522Qyc531Qyc532Qyc535Qyc536Qyc538Qyc552Qyc561Qyc562Qyc563Qyc565Qyc579Qyc581Qyc582Qyc583Qyc586Ryc590Qyc595Qyc597Qyc601Qyc602Qyc604Ryc605Ryc607Qyc616Qyc617Ryc622Qyc623Ryc625Qyc626Qyc628Qyc634Qyc637Qyc638Qyc641Ryc647Ryc656Qyc657Qyc664Qyc671Qyc687Qyc703Qyc712Qyc715Qyc716Qyc720Qyc721Qyc722Ryc724Qyc730Qyc745Qyc750Qyc754Qyc755Qyc759Qyc760Qyc765Ryc774Qyc779Qyc780Qyc782Qyc785Qyc788Qyc791Qyc794Qyc799Qyc801Ryc804Ryc813Ryc818Qyc822Qyc823Ryc825Qyc827Ryc830Qyc832Qyc835Qyc840Qyc843Qyc844Qyc845Qyc847Qyc857Qyc860Qyc861Qyc865Qyc866Ryc869Qyc875Qyc880Qyc885Qyc886Ryc888Syc889Qyc891Qyc892Qyc895Qyc897Qyc900Qyc906Qyc907Qyc912Qyc913Qyc914Qyc915Qyc916Qyc917Qyc927Qyc931Qyc932Qyc934Qyc935Qyc936Qyc938Qyc939Qyc941Qyc943Qyc945Qyc946Qyc949Qyc950Qyc953Ryc956Ryc962Qyc965Qyc966Qyc970Syc971Qyc979Qyc980Qyc984Qyc986Qyc990Qyc994Qyc997Qyc999Qyd1039Qyd1294Qyd1298Qyd1338Qyd1373Qyd1441Qyd1446Qyd1726Ryd1739Qyd1790Qyd1821Qyd1826Qyd1841Qyd1863Qyd1934Qyd1973Qyd2019Qyd2023Qyd2271Qyd2523Qyd2561Qyd2619Qyd2824Qyd2845Qyd2915Qyd3211Qyd3270Qyd3384Qyd3737Qyd3811Qyd3829Qyd3967Qyd3979Qyd4002Qyd4389Qyd4502Qyd4555Qyd4581Qyd4796Qyd4858Qyd4924Qyd5010Qyd5063Qyd5132Qyd5157Qyd5219Qyd5339Qyd5412Qyd5433Qyd5495Qyd5595Qyd5742Qyd5756Qyd5758Qyd5777Qyd5824Qyd5955Qyd5988Qyd6193Qyd6324Qyd6357Qyd6425Qyd6458Qyd6490Qyd6567Qyd6639Qyd6670Qyd6761Qyd6833Qyd6978Qyd7043Qyd7198Qyd7199Qyd7206Qyd7396Qyd7462Qyd7664Qyd7669Qyd7730Qyd7737Qyd7787Qyd7853Qyd7884Qyd7906Qyd7998Qyd8077Qyd8194Qyd8208Qyd8239Qyd8340Qyd8412Qyd8534Qyd8608Qyd8773Qyd8883Qyd8964Qyd9066Qyd9274Qyd9358Qyd9425Ryd9504Qyd9587Qyd9609Qyd9623Qyd9679Qyd9719Qyd9767Qyd9856Qyd9927Qye18218Qye18500Qye34850Qye37912Qye38128Qye39905Qye74933Qye82391Qye83454Qye90451Qyf552660Qyg3227411Qyh21590549Qyh25492340Qyh45353291Qyh61173291Qyh65124517Qyh85653399Qyh89118022Qyh90061486Qyi431816573Qydd869QybfbYyd48cbQydacbaQyd03dcQym639481524ee80Qyd476eQyc17bQyafMy W854414033d5cec1470774eeQyd516aQybaa]yc07fQycfaaQyab{ye38bebQybcfUyactyb7fQyc78bQyc02cQyg09602baQyaeEyk140132d26a2Qyb8fQye58cbeQybce_yc85cQyg22569afQybde[yadyybf9Qybee]ycbdbSybabZyo5583eeb6eabbd51Qyc62cQyf52779aQybed[yh431877ceQyd11feQycfeeQyc77fQyd26ceQyd086bQybfdYyf77021aQyaay `a12474027c91fad5a861aa9919817d72Qye698cfQyccbdQy W796161d82c9ac438ebab5d2Qy `9335522f4c8dbc7256a42a091e6e00bcQybdfUyc30dQyg810068eQy T4656498e5972c6de7e3dQyc67cQybaeVyd89beQybfa[yd66dbQyc40dQye9693aQye77deeQye5785bQybdcYyg61ccffdQy `73279888a8fe482c836fb19ca23318dcQybecUyc88cQye4976fQybcaZyd20faQyd169eQyd167aQydcebfQyc64aSyg6329ecbQybeaYybbbTyc47dSyc70fRyc94bRyk4510813f36aQyd779eQybbcVyceedQyc97fRyc19cQyc41eQydf56cQy \19442484b3e4f47875b58b3f72b2Qyf5eebdfQyd85fdQybdb]y P301194bfeeee4377Qyc7ccRy ]21814165879f72529e91682ece5c6Qy `0645bdb1cdf88ec74288d503eb71839cQyd104bQyc17aQybbfVyl236659680493Qyd218eQyc36dRy W5945ece02fdc55d6cbcbc38Qyef0fdcQy W18514362a4e52376a6fecbaQyc26eQye44dfdQyc16aQye2963dQyc18eRyf99806cQyd26fdQy `35200cbf0b5b45d7f5f0b343cb18868bQyc10aQyd69bdQyc03dQy T2632722300194f01e93dQyc59bQyc60eQycbbfQyf72643dQyd22adQyf43caefQyc41cQyf74826eQyi82088739dQyef4baaQyd43ccQyc83bQyc99aQycdbdQydf41dQycfdeQye94cbdQycbbdRyg28808dcQyc080Rye3190cQyd45acQyc91aQydecedQyc95eQyc83dQyc81dQycfcbSyd0105Qyl247784b9d930Qyd931bQycebdSyebfaebQycdcfQyc61bQye4543eQy R67fccabee27a6e99cdQygd95522cQy Y691013bfe66dd46ded85a98edQyc4adQyc37fSycbcdQyf17abebQyi96106314eQy Y2367372c3199c66a6420faf89Qyba5Qybb2Ryc10dQyh888217abQyceccQybc6SybfcWyd88bdQyc57aSye57ddfQyc22eTybebXycbefQyda46cQyc03aRyd26bcQyd0096QybfeVyc83aQygb16bdddQy Q4136446bebe7ffbc7Qyd188cQy T6752dfce5a0235354070Qyc37dQycfaeQyh011687ebQyc89eRy `c377351433a941a927aab543931f6026Qyf15932aQyeacfacQyl27766eadc9e2Qybc4Tyc96dQyc02dRyn03668caaecbc57Qydd08aQycfdcQyc040QyebbbddQyc81cQyg296318cQye827deQycbcbQye44cafQyh35896c1fQyb3cSyc33eRyc43cQyf03996cQyg1966beeQyg38866ceQyff5effdQydcaecQyc11aRyf61827eQyf80739aQyi6065960ebQyc9daQybcdTyf31310bQy R8952efd1be1881e651Qyd208aQyc072Qyd86caQybe5QybcbXyf14984aQyc66dRybffWybda[yc8a1Qyf94cfccQyc82aRy P96813587fe3a6049Qyde74dQy \071363645a588f858b35231128c4Qy `163beeae9620c1a6a46a38aa7ebd9663Qyd36ddQyf94159eQyf60076cQyl6098086e255fQyf21982fQyd43bcQyf22efefQyc22bRyc48cQyg306cecbQy Y32320ead508346ad8fed3394dQyb1eQyd16fdQybbdXyh03865b60Qyg09155bfQyf93847bQybadWye78ccaQydc098Qyi0901979bdQyi345200f90Qyb2cQy Y8797ace2fb37402ea6a09d126Qyd44dbRydfefcQyd97cdQyc28dQyc55dQyb4dSyc71dRyc23cRyd85fbQybafXyc20eQybbeYyd49eaQye5816eQycdaaRyf15357bQye83daaQyf97692cQydf488Qyc62dRy W39194824861a134567cadb8Qyb9aQydbabbQyd51dcQyf75bdaaQyc19dQy ^9580308938069159c5afc55b2f3b96Qye4fbdcQyg37781dcQybddVyc86fQyc61dRyb04Ryd6fbfQye89cecQyh28811a94Qyb8dQy \3760395e8e0eb40e335b22750b68Qyb3fQyd71eeQycdafQyd42bcQye7fdedQyd0345QyceeaRyba7Qyf85fcadQyc18cQyd10deQyc48bQy Z9805919736382ffea5a9554c02Qybc9QycabaQyf54475cQyc20bRyb6fQyd47cbQycadbQybccVyc44fQydd710Qyc073Qyd71cfQyd83aeQyc45eQycedeQyc31bRybefUye9710cQycecfSycbccQy `c3053579ae25e2fb9b967076a06373afQyb7bQye43fceQyd14deRyc61cRyd819aQyc90fQy ]9355781403b92e844de8568863ae8Qyf7fcfaaQye34dbdQyc19eQyefcfdaQydc61aQycbdaRy V1667498626ae52ad0362e0Qyfd9018fQyc94aQyc91eQyc92bQyc99cSyc80aQye6532eQyc92dQyc07aQyd018bQyd00ddQyc17cRyea65bdQyc31dQycdabQy P41712823a5d6002bQyd77beQycfcdQyc23aRyd35aaQyd09dbQycaeeQyb1aRyd0040Qyf06eacdQyg0526476Qyc80cQycfcaQy Y02ebfecc7a931dad1ec38466eQybf3Ry \819656f68b87a91c53afbd441fecQyd1abcQyc67fSyd05fdQyc60fQyd1bbfQy V096960e13d8578fa544536Qybc2Qydd39fQyd69fcQycefbQyd78daQyc91cSyf82809aQyc97aQyc26dSyc11bQyc28bRyc34dQy Q3606427f835bd3ddfQygd8041aeQy Y308961666b15aa1e57b0f9f35Qydd96fQyc80fQy Y23543850a2ee9fff8cd2cc53fQyd538eQye38fbcQyd78cdQyc61eQyi8141ddcc1Qy `b27bdabd8e1a6b7dc06886867331ceb3Qyb6cQyg1519fbfQyh910197ccQyd62cbQyd0266Qye7027eQybbaUye45dddQy Y3042dad59a12e5937644f7246Qyc3fdQy ]9052870778e14ab4a5acbc8c24af4Qybd3Qyc10eQyg9340deaQyd10aeQyc016Qye19fffQyecfaebQyc47fQyc04dQyecbaacQyc08bRyc15eQyhbffdcb5bQyc8ccQyd19cdQydbeafQye1642fQyc52aRy `d791eaca9375ca1b36a987af22ee71ddQy `e6684944c37dbdd4c08d978af9e47bedQycbbeQyddeecQyc11dSyg348051bQyeabdafQyda673Qyf62477eQye01abcQyk75465416b86Qyc7b6Qyc59aQycabeQyd22daQyc03bQye4afcbQyc20dQye95bcdQycbdeRyb7cQyc21bSyn5153268e0cc1c1QycdfaQyd61ceQyc39fQy ^0486610d8a02cea245c13c85b6de27Qydc20dQyf71627eQyc66aRyc044Qyf21780fQyc56fQyb4fRyc88fRydeebeQy V44285ded812939553ef94cQyc29bQydadcdQye80cedQyo1612128b3ca95a9Qyc16fSy ]1046144ad9ee7bb96214ba7ae7516Qyd002dQyc74dQyc19bQyd43ffQyl2446665e2fe5Qy `550becdd08d00fb1e7fd00c2adc3d3d6Qyha62186eaQyc087QyddfccQyd167eQyd49ceQyg521991eQyd993eQyc58fQyg132740bQyd06eeQydc56aQyd76efQyd87beQyc32bRye81facQyc3fcQyd83faQy T55885067fee629287e8aQyb4bSyh768585daQy `c54909ecf4fb3e9afeea36200fe95dceQygd819ceaQye5197eQye8673dQyi16659a5eaQyb1bRy ^56132638912a1ca54fcf7cd38b8e23Qyc2eaQyd86aeQyi5093670dfQye82efaQybacYy `5912529cfd6ce14c5ede5c6c83dae7e8Qy `15700442e957951307bbcec5fff8643dQyd018eQyc32aRy Y8010960eb17e368a6fdd5a51bQyde159Qyc35dQyc46eQyf03072aQyi54780edcbQyc64cQygfcdecdbQye3797eQydaaaaQye59adcQyc4ccQyd08caQye51ecfQyg963035fQyc039Rye6194cQyc61fQy W33182579cd3edd0ac6c7c44Qyc0deQydedbfQyg506143cQyc12eQyc94cQy `744554499cb7880086fbd9b1f080e7e1Qyb5aRy U186925e5de978c5f72062Qyc73bQycfceRydcabbQyd01cdQyc21dQyd100cQye69beaQyc02aQyn4540ecaa37d0e3Qyg809925eQy U0456231c374b09cbe4a90Qyh815273cdQy U1948795e26af2f3f8a30fQydf887QydaabfQycbfbRyf39698fQyc9ccQy T1405cddcdeb4487c59feQyc18bQy X871950ebc36c415a53630477QydddabQyf55188aQy V5998989255253e15ccc1f6Qyc75dQyi9268739feQycfebQyc22dQyg1411afbQyg787810dQyl68210e6fad4fQye615dbQyc24fQyc19aQyceafRyc18dQyedceedQyf8d7cafQyc84bQye51ccaQyf27291cQyccfcQy `7249710187cc2d983709e044dbc78d9dQyg563864aQyg949924cQyg505985aQyk168191dcb84Qyg24357feQyf82fdfcQye8134aQyg19ecbaaQyc12fQyeebcffQyh79534a52QyccedQyc13bQyc64dSyd0127Qyd13bbQye4677aQyef2cbeQyd07bfQyc16dQye5860bQydedbcQyceeeRyc49aQyh570599cfQyc55cQyd649fQycdddQyg3884abcQyf043664Qyb5bRye97eadQycbadRyc57bQyc43aQyf89149aQyf997accQyc01bRyc54fRyc77aQye9133fQyd1fedQyc99bRyd50ebQyd92cbQyg1644e8aQye5badfQye61ecbQyecfaddQyg58712faQyd10ccQye9509bQyc59eQyf029775Qy `b36abffbe5d6a0de73a9968604a1a3f9Qy ^9649eca3dfbd356527ffc88f1dcb94Qyd7deaQyf52758bQy Q10cbceb08c81d1760QycbceQyc39aQyc75eQye2713fQyh687271a1Qy `e5390751969ab21df280b7591854b89fQyf05330cQye3703dQye96cfeQyc33fQyb4aRyc42cQyd29dbQy P268010bbebf4f579Qyc1bcQyf36080bQy W2493aab78c26e4f2152542cQyc2deQye67fcaQy T31500621ecd6d3917a07Qyb0aQyg8183cedQyf41286eQyc54eQyd21daQyd68dfQyd937aQyf32cabaQyc88aRyb2aQyc50dQyf07330fQyd0243Qyc79dQydd266Qyc67bQyc20cQyf01055bQye223bcQy ^2709406a9bb19e8d83a78f81e36244Qyf998edaQyd07fdQym251138384a0b9Qyf853cacQyc90bQyhdcdbbfdeQy `4616fbea6a6dbc1074bc3f1016bbc73bQyhf15702aeQye55badQyg42182cfQyf18724dQyc77dRyfafaebdQy T7193badc746d52b4173fQydbdeaQyg64cdfccQyc65eRycfddQyccccQyg74705adQyd98bbQyd60adQyebadafQyb0cQy Y1069578551d0e3c7d9275f16bQybe3Qyh146469edQy U4318eaa2ffbca3510c054Qyc21aQye9330dQyeebadeQyc62bQyf40abeaQyc87aQyd64bdQycfadQyf69458bQyf916bdaQyd59bcQye7621dQyj040572a3c0Qyc5bbQy [8322cdbda7a21e4aecbe04462b7Qyga578acfQyd95feQye7208fQyd706cQyc033Qye4483bQyc062Qye0236aQyd72dfQyf05560dQyn94208817b83468Qyd91feQyc03fQyf85cedeQyc62fRy Z398056eef1cf6caa90786b340aQyg2824befQy Y72110575c78aeb979170212b8Qyge396cbfQyd94eeQyc43dQyf50562bQyg09417cdQye2348aQydaabeQyc76aQye21fdaQydeddbQyf95426bQy `299abcee56b05b312ed5700f686f79b8Qyg670744bQyh945088deQy Q05866864f7d57bee7Qy `c1241374502f200cf9fc49c8d6fb5822Qy `d51032bef3e7117a94336fea18a3fad7Qyi65453a1aeQyh403679bdQyf47398aQyg04205caQycabcQyg61831fdQyc06bQyh402875d2Qye386dcQye3965fQycfbeQyc29cRycdfbQyc9adQyc72cQyg21741bdQycdfcQydf55dQy \33371dcff207fd7d201128df2ea3Qyd229bQy Y784707b1d2c702fbeba080e86Qyfc98cbcQyc95cRye0526eQygc6107ffQyc57eQyc96aQyc019Qyd00adQygf6debedQyc20aQy T308352b7a881add7e356Qyc15fQyg501351dQycffdQyf73985aQyc50fRyc89dQy Z51edead39c0e439073986043fbQyc10cQyd70deQye25ccbQydbbbbQye78cedQydc18bQye12fffQyd24dcQyc87eQyc36eQyc90dQycebbQyba0Qyda00cQy Z23556fcc5dbfb7b7f43fbbb61dQy `d9560caeb797b302191f667b4264da40Qyfa2012aQyccdbQyo69afdbadc1e76b6Qyf13684dQye16fddQyc07dQyd0584Qyf29265aQyd270eQyc66fQyd43abQy P52735bbbe6ba65b0Qyda106Qy U277538367f9c8140e3a75Qyd9dcaQydefedQy Q03fbaddfc0fab7c76Qybb5QycdbfQye4690dQye0302eQy T8604342a925b2dc60737Qyc76eQy Y44931bfefab991be3dd7a08b7Qy `e1870dde155be1a375f155dd1f7ead13Qybd2Qy ]805472f79f0b558f75b90b5e7b4eeQyc79eSyc36aQy R1221897f5837c84affQye5931fQyeacdacQy S724742c4ee0960d8d40Qyi3931327edQy S1568868c5ab8e839148Qyc01eQyh330045feQycaffQy Y582642d9cbe500f018afab341Qydb875Qyc24dQydfddaQyc82bQydbbfbQyc75aQyc59dQy Q76672d3de4dc9a8edQyd60ecQyd46beQye1877fQyg6920edcQyf50557bQyccbaQyd146eQyc40cRyg36eeceaQyj822028dd9eQyda98dQyd42beQyc060Qyf5080ecQy Z80454654d990d9c07d33d35d1cQyc26cQy ]47355cbe966a94826cbe2fbf2b355Qyf33919eQyh866426ceQyc06fQye19bbfQyf78292dQyfeafbdfQyd57ccQydbbbeQyg58646ceQyf93015dQydd12cQyd68beQycfdaQyg5493b4dQy `f45069216cd934b80ce882c9a2f2a08aQyc1feQyc14eQyc02bQydddccQy `e30258aeb8475d4c27f7935945671856Qye90bceQy U5743226af94c1efaaa4a7Qyh494557dbQy X52824555864d1106278cd1f0Qy ]10764f0ccce42d5be8cfeac36b446QyddbccQy W15afefef853a08a0804ba3aQyi4726484beQy T418849e1f4200ade9535Qyf97311cQyf24809fQy R103575d8a7fee19680Qyd286aQy W373398d7d2c93862c5f6661Qyc99fQyf22485dQyd0872Qyl2529599c8440Qyd36ffQye37cedQyc95aRyddaacQyc1caQyc04eQyd12feQyd61fdQyc73dQycefaRyf52675bQyc35aQyd11eeQyd97bcQyh465087cfQycbdcQybf5Qydf28fQyd42adQydcbeaQyd54ffQyc60dQyf82160dQye6093eQydb051Qy Z352847c06e748b345e8ed0738bQy \86812812dab8d39db9aaefe94a78Qy `322264a17ef7182eb1475bd2eaebc2ebQyf20110cQye8304bQyd992aQyc00cQyf30242bQy S6217243f3c387ea18b7Qyb4cQyc67eRyefdeefQyc50bQydfdccQyh32cdcee2Qye30eebQyc083QydacecQy R8460150068ba0c6743Qyd898dQyc25aQyg462405eQyde01eQyc01dQyf18582cQyc69eQyd111aQyb7eQy ^23419e4fc69b5b533815681c9bb1a9Qyc98cQyg640616fQyd34baQye922ccQyd71fdQycdacQy `43501cdf0de25278a208cbb9aad80012Qyf89abaaQyd21cfQye4744eQyg7604edfQy S96120606c8dda06458fQy `775894425f5a7436f56fc5a3b4a2cfaaQyb8aQyc29fQyebebfeQye8008dQyc56bQyc7faQy [0877831b4c924438396760f1841Qyc68aQyc34cQyd42abQyc33cRyc9acQyc94eQyd60dcQyc30aQyc023Qyf027364QycdccQyd24dfQyf32287eQyd89eeQyd8accQyd78beQyc63eQyc27eQyd53ecQyc90cQyb9fQyc09aQym2981057642b69Qyed13aaQyc56eQyd27feQyd71efQyd40ffQyc093QydecdfQye9ccdaQyeebcdfQyfeacbbaQyc69fQyc90aQyn3086543790541cQyd277fQye2177eQyg62680eaQye0158fQyf48516eQyf57684cQyn22adccac34be92Qye216dbQyg319052bQyg68862cbQyccbfQy X8187985725963b8bfc67004dQyd0dcbQy X17794bbca56b6cdb9e20b932QyeffdbdQyc28cQy R63976e9eec38cab0f5Qy ^734259dfb9addebe2b226d96b4f744Qyc78fQyc002QyedfeecQy ]418764dca70aebfc965899a3fa7e5Qyf66950bQyd22ddQycdfeQydc92cQyc12aQyd28faQycaabRyl60865046ff05Qyc12dQyc33aQyebbbcaQyccbcQyfd77cdbQycaeaQyc58eRyd904bQyi07170a0ceQye7491eQyefecceQycbedQycfccQy R23639057435ac8756aQyc56dQy ]5711303378bd333ddb611a53ece94Qyfc7937bQyg96191dcQyd31dbQy `06731164684f90f33ce4017eca9d8ec1Qy `f8327953a0f0b80011b939111807999aQyb8bQyf76101dQy X185700a8efed148d8722d926Qyc16bQy [9445539e9274282a612dea354c2QycaaaQy U429863f89da313fffed97Qyd116cQydbefaQyd51ceQyf96604cQyc95bQycddbQye30fddQycedfQyd10ebRyc05cQyd57ebQyg850036cQyd627aQyd45ddQy V07150343c81d856855590eQye966feQyf86121fQyc95fQyb4eQydfecaQy P486653fea1d0e39cQyf16213dQyf24273dQyg22332cdQyd01ceQyfa2679aQy P2645809ed92ce138Qyd83fbQy Q338132d23b9112805Qyh673436acQye41ebcQyc79aQyf10ebcfQyd88dcQy `a4462529ab493676987d946019a14945Qybf7Qyd85afQye2623dQyecbdddQy ^573488dec311655890a205aad4fb65Qy `7164823f504286e3a762ee612ff0a988Qyc049QyebabcfQyd584bQyh362098fcQyd57deQyfc6696aQy V7498efb66f5ba3a8b35d08Qyd16faQydaefeQyebaefdQyb6eQyd0818Qyd58ffQyc50cQyc037Qyd0ebeQyf78077cQyg48410cfQyfbccdffQy `924727b6f380cf3cdfe5650163e92054Qyc48dQyc68bQyc28fQyfbfebadQyg454658fQyd86ecQy T9790262e14f953bbadcbQyh107510acQyf2412aaQybd9Qye6630aQyc84eQyj5765103d2dQyb7aQyf31685eQyd88daQyd14cfQye75aecQyceadQye7101dQyc94dQyc28aQyc14aQyg294550cQy T9760aec57ba29682a750Qyb5dQye70edbQyc076QyccaeQybb9Qyd73faQy Q66891554b66b2cdedQyf34780fQye0374bQy [82817c0fb24e591b9a89a82f736Qy `09677934e13a5d728f00c6ed7c8870a9Qy `7052598d2355984237d126afea2f6e88Qy `927612b57ba01ca878b2d7edce52a563Qy `97402287d8c6c03f0b63848e17e9d944Qyf31128aQyd54daQyd49efQycfabQyd37cfQyc41bQyg811063bQyc37bQydeaadQyfaacebfQyd48ecQy `73262345214f9b7794f2cc4a612b15e8Qyg9baedcdQy Y033169611a42c3cfd58b3ae03Qyef23caQyc066Qyd65ffQy P73579aaaf5d7ce36Qyh608108beQyc2f1Qy [795216d5bafa33a810af3421942Qyd0aeaQyc06dQyf44878bQycefeQyc090Qybc0Qyd41ccQyc97eQyc7edQyd77ebQyceffQyc86bQyi40721f7caQy R651887aac4eb17f9f0Qy Z9668608a39333fa90cf462657eQydc70bQyd78fdQyedffcdQy P38322355e9c2471eQy `229975f1e84b5088e819cd5f2dc43080QycdadQym92641dadb5de7Qyd49baQyg23148dbQyeeffdcQyf5876eaQyef6dffQy [70097776e24c2a7c9c0f2514f79Qyg991285eQye3295bQycdcdQyc43bQyg61066efQym8656477b226beQydeeefQye60efeQy W889349870426d10edc694beQyc046Qyg0481dbdQye4003dQy `b2621497b3313c97855ed951f0d9b291Qyi42144a7deQydcfeaQyc62aQyd0785Qyc77cQyf74608eQyd85baQycdbbQyf69248bQ>vetitle<ya0oya1wya2dya3Xya4Xya5Zya6Xya7Wya8Sya9Qyb10Qyb11Qyb12Ryb19Qyb32Qyb90Qyd2011Syd2012Wyd2013Zyd2014Qyd2015Tyd2016Qyd2017Qyd2018Qyd2019Qyd2020Zyd2021Ryd2022Qyd2023Qyd4096Qyd4897Qyb今年Ryaの|yb振り]yb返り]yaとFyb来年]yb抱負]ya（^ya）_yeOramaQycというWyb検索_ydエンジンQyaでlycブログTyaをkyb作っTyaてvyaみRyaたdybGoQyeSlackRycボットQya話Uyd機械学習QycによるQyeランキングQyb改善RycガイドQyd読みましUyfsearchQya-PybUITyiSearchkitQyd検索画面QybVSSya uydCodeUycDevTyiContainerTya(`ydコンテナQya名Qyb指定Sya)`ygブログ記述環境QycとしてRycWSLQykディストリビューションQyd環境移行QyfdockerQygcomposeQya.}ycymlQyb対応Yyb導入SybまだRyb途中RycpreQyfcommitQydvenvQygPyCharmQyb困っRyaなXya？]yaも\yeオンラインUyfBerlinUyiBuzzwordsTyaにQyb参加nyaし_yc仕事中QycBGMQyb環境XymElasticsearchaygアーキテクチャRyiStatelessQya/PyjServerlessQycローマQyc字入力QybゆれQyb読みVy \JapaneseCompletionAnalyzerそのQyd日本語用QyiオートコンプリートRybためSyhAnalyzerSydHugoTyfアップデートRyfQuerqyRyb調査RybそのUya：Qya１Syc新しいSydJavaUyfクライアントRykインデックスエイリアスQyeAzureZyiCognitiveXyfSearchRyc新機能SygExtremeQyeMultiQyelabelQyhLearningQycforUyhSemanticRyhMatchingQybinTygProductQyb論文Ryb読んWyaだSye2021年QybかっQyc良かっQybものRyeIndexRyfSchemaQydJSONRycCSVQya見QybたくQybなるSycDIYXyeキーボードWyjコントローラーラックQyfDomainQyhSpecificQykPretrainingQyhVerticalQya:RydCaseQyeStudyQybonQyjBiomedicalQyjLiteratureQyeMICESQyb出張Sya、]yb試しRygLunakeyQydMiniSyb組みSyb立てSycBLESya+WydLPMESydIO化しRya#IydスライドRyb作成VydMarpQybしてVyd検索技術Qyc関するWyb情報Tyb交換Ryb目的QyaがPydできましQya！ZyfOData式Qyc日本語SyeNGramQydフレーズQyb自宅Syb作業Syb02SyaやSyeサジェストQybみるSya「TyjコンピュータシステムQyb理論Qyb実装Rya」Tyb始めSydNandQyfTetrisQyeSofleQybv2SyeCorneSyeLightRybIOQybPCQycしましVyhTemplateQybV2QyiChocolateQygWindowsRyaへYyb移行Tycお試しQya中RyeDozenQygLinderaQycFSTQyoDoubleArrayTrieQyb変更Syd検索対象QycデータXyfデータソースQydシステムWyb妄想Syb09RygmeteredQydクレートQyb紹介^ye第4章終了Qyd言語処理[yd100本[ycノック[ye第3章終了QyiTerraformQyeクラスターQyb起動Syb構成RybするSycパーツQyb特徴Qyb機能Rydについて]ydRust]yctheYydbookXya第Qyc15章QyjluceneutilRyb性能QycテストRyhkuromojiRyb追加TyeマニアックQycツールRyfセットアップWye日本語向けQyb違いQyc13章Qyc10章QyeリクエストQydロギングQyiMicrosoftQyeBuildQyiCogniriveQyeセッションRyb見たQybメモUygElastic\yeStackVydリリースiyaさSyaれSyb9章Qyc第2章Rybから^ybまでWyc第1章Uyb08QyiWorkplaceRyb触っTyfインストールQyb辞書Wyb更新Syc注意点TyhKuromojiYydカスタムRyfインデックスTyb設定Syb8章Qyb03Ryb06Ryb再びQyb6章QycCLIRydコマンドSyb出力RydラティスQyb5章Qyb4章SygAnalyzeVycAPIVyfVisualRyfStudioRykクライアントプラグインQydBookQyeプラグイン]yfClientQyb実践Syb入門Zyb3章Ryc終わっQygpicocliQygGraalVMQybでるTycところQye2019年Ryb買っQycよかっQygブログ移行日記UyeJugem}yb探訪QybたいQya=Rya>QydやりましQyfボードゲームQyaはZydじめましSyfフリーランスQya仮Ryd検索機能QygAlgoliaQyc微調整QycテーマRyb合わQyaせQyhMarkdownQydファイルRyb変換QyiOctopressSyc移行中QyemacOSQyb標準QyeターミナルQyiウィンドウグループQyb便利QyihomeshickQyczshQyfDockerQydイメージQya化Qyb退職RycしますQyfApacheUyfLucene^yfUniDicRycビルドRycパッチQygBonfireQydDataQya&QygScienceQybましDydNEXTQydSTEPQyd頂きましQyc勉強会^yb受付Qyb自作QycアプリQydHTMLQyi勉強会運営座談会っQybやっUykEngineeringQydTechSydTalkQyg検索技術勉強会Qyb運営QycみましTya。Dyb入っQybくるQycちょっRye2018年Ryd新規導入Qye長期出張用QydアイテムQydいくつかQyd第25回Qy PElasticsearch勉強会Pyb開催UydJJUGUygナイトセミナーRyd話しましQyfKibanaVyb方法Vyb3回QygカンファレンスQyb探しQya方RycCfPQyeスポンサーQyb応募Qyd開催期間QybなどRyb05Qyb04Qyb00Qyb2回Qyb1回Rye2017年QyhSwiftypeQydジョインQyh分析基盤構築入門Qyb一部Qyb執筆Ryf検索座談会っQye2016年Qyf便利機能紹介QygNEologdQyb品詞Qyb単語Qyb抜きQyb出すQyfIngestQyfPluginQyb書いQyoelasticsearchjpRybよくQya物Qyc壊れるQya年Qyd第16回Qyd第15回Qyf自然言語処理Qyb基本Qyb技術Qyd第14回Qye2015年QyhTimelionQyfAdventQyhCalendarQyc1日目Syd第13回RyeSenseRyb歴史QydbetaTyd日本語訳ayfShieldRygWatcherQyfMarvelSybGAQyhLogstashVygReleaseQya,QybweQydhaveQyiunpluggedQydにおけるQyfネットワークQyfDeleteQybbyQyeQueryQyd第11回RycおよびYyb大阪Qyb京都QygMappingQyeすばらしいQyhリファクタリングQyb間近QybさらQyb進化QyeFoundQylJustTechTalkQye形態素解析QybあれQybこれQya@UyhジャストシステムQyfHatenaQyhEngineerQygSeminarQyeTokyoVyjhatenatechQyd第10回Ryb使っRya再QygdiscussQygelasticQybcoQycにぜひQyc第9回Ryc名古屋RymelasticsearchPyielasticonQyc参加中QyfセキュリティQyb向けQydCoreRyfトレーニングQybますTyc第8回QyfGroovyQyeスクリプトQykダイナミックスクリプトQybなしQyb実行Rya　VyeCROSSTycきまし^yecrossRyb0系QyeIssueRyb簡単QyhコーヒーブレイクQyfエコシステムQydBetaRye2014年QylインデックステンプレートQyb利用UyfアクセスログQyeインポートQyc第7回QyhvalidateQyhSonatypeRyeバージョンRyb番号Qyc第6回RyeもうちょっQyegihyoQya_UycefkQygインデキシングQygパフォーマンスQyb検討QycサーバQymインフラエンジニア養成読本QybログQyb収集Qya~Qyd可視化編Qyb手伝RyaいRydプロキシQyfpluginRygCuratorRyc第5回Ryb転職QyfserverQyc2ndQygeditionQymファーストインプレッションQyc可視化Rye現状確認会Qyb最新Qymインフラエンジニア技術勉強QyeよくわかるQyfAmazonRykCloudSearchRyb行っUya外Qyb世界Vyb知るQybことSymアジャイルデータサイエンスQyd届きましQylAggregationsQyeファセットQycよりもQyb柔軟Qyb集計QydkopfTygaliasesQyb画面TyfstreamQybesQyb複数Qyb登録Ryc第4回RyhanalysisRycJVMQyiOperationQyfCasualQyeTalksQyijvmcasualQydrestQyb概要QymElasticSearchSyjServer日本語版Qyc電子版Qyb発売RydGOTOQyeNightQycからおQybようQyeございますQycいつもQyb入れRybいるQyfServerQyb翻訳SyfNestedQyfObjectQyeフィールドQyb奇妙Qyb動作Qyc第3回Qy Pelasticsearch勉強会RyfすずけんさんQya元QygVagrantQy QElasticsearchクラスタQydSolr]yd第一印象QyfluceneTyegosenTyc時系列Qyb管理RyhExtendedQybRCQya＆Ryd20追記Qyb配置QyhextendedTyganalyzeTyeMavenQyc改訂版RycPDFQya版Qyb公開Ryc第2回RyhClouderaTyeWorldQyccwtQydRiakRyfMeetupUyfriakjpRyb改良Qyc開発中Qyd第12回Qyb主催TyfSolrJPUyjinquisitorQyeriverQyiwikipediaQyc疑問点QyiWikipediaRygインデクシングQyc第1回Ry PElasticSearch勉強会QyjMorphlinesRyhloadSolrQybだけQyb調べSyfXperiaRyaZRyb故障Qya『TygプログラミングQydHiveQya』TyfHadoopWyb3版Qyd刊行記念QydセミナーRygoreillyQyd0724QyhYokozunaQya気Sya点RydというかRybなんQyiスキーマレスモードQydSOLRQyc見ましQyeありましてQyeBashoQyeJapanUyb遊びRyd行きましRydsolrQycxmlQyb探索QydロジックQyfapacheQyfloggenQygfluentdRyfkibanaQydログ検索QybデモQycAWSSyfSummitRyc来ましTycDayRyiawssummitRyc妄想版QyeモジュールQybたちRyhSearchってQya出QydたらしいQybとりQycあえずQyb雑感QyffluentQylzoomdata作りましQya＋Tyb悩みQyb事とQyaかQybより|yb移植|ynOctopress始めましたQyb以上Qyb可能QyaすRygポモドーロ回しQy Qポモドーロテクニック入門読みましたQygChangesSyb訳しRybあるRyibackwardsQymcompatibilityQyfpolicyQybなっQyeエンジニアSyfスキルアップRygCompassRyftecompRya―RycVolRyb人気QycWebQydサービスQyb作りQyb方教QyaえQydJIRARybS3QyfバックアップQyfHerokuRylTreasureDataQydWazaQyfReportQyb!!QyhherokujpRycユーザQya＠Qyb竹橋QycスマホQyd時代到来QybこのQyb先生QyaきQybこるQyb？」Qyd買いましQyjConferenceRyfWinterQychcjQyc13wQyiエンジニアサポートQyaおQyeモデレータQydいまさらQyb担当Qykコード・シンプリシティQyfKindleQyjpaperwhiteQyb使いQyb勝手Qyb確認Qyb兼ねQybDBQyfHSQLDBQyjPostgreSQLQydaugjQyc第一回QyiJetBrainsQyhユーザーグループQyejbugjQygDSIRNLPQyb＆「QyeEmacsQyd実践入門Qyg頂いちゃいましQyfビッグデータQyd活用事例QyfjawsugQyc0対応RyeLucidQyeGrantQyiIngersollQybさんQyb講演Qyb聞いQycPFIQyhオープンセミナーQygpfiopenQycメインQycMBAVyhMountainQydLionQydいろいろQyc確認中QygFluentdRyfmeetupQygTwitterVydtwtrTydhackTyfPythonQyjDevelopersQyeFestaQyb07QydしゃべっQyepyfesQygPartialQyfUpdateQyicopyFieldQybバグRya【TyeALPHARyb】(QycMIRQye輪読会始めQyd勉強会第Ryb8回RylソースコードリーディングSyc10回QymhadoopreadingRyfZipkinSyfReadmeRya２Ryb残りQyb周りRy YautoGeneratePhraseQueriesQyeデフォルトQya値Qyb分散RyfトレーシングQyb追跡QydリソースQya壁QyetrunkRyeライブラリQya差Qyb替えQygランダムテストQyb失敗RygオープンソースQyb貢献QycススメQycCCCRyfSpringQymPlayFrameworkQybてるQyc7対応QybIDQyb秘密QybJPQya＃QycCJKQy TSynonymFilterFactoryQydサンプルSyb2章Qya～Qyb1章Rya】Syb出てQybたよQycOneQyiJavaOneJpQyb問題Qyb重要Ryb次期Qyb久々QycMacRyb渋谷Qyb自分Qyb小さQya箱Qyb脱出QyeScalaQyd始めましQyc第0回QydHackQyeCleanQyeCoderQyb親子Qyd楽しめるQyb絵本Qyb英語QycじめるQya本SyiデジタルハリウッドQymSynonymFilterQybときQyd問題点編Qyc今興味QyhモーショノロジーQydMapRQye中身説明会QyeOSSAJQyfミニセミナーQyb話しQydブランチQydあけましQybおめQygとうございますQyb会社Qyb第2Qyb東京Qyb７回Qyb発表Qyb構造Ryg言語処理勉強会Ryc備忘録Vya５Qyh2009lateQyb他くQybだらQybないQybどんQyb大量Qyc読めるQyb速読Qyb7回RygMongoDBQyfSplunkQydLiveQya!QydイベントQygEuroconQyiBarcelonaQyhBookscanQyc外部化Qyc4対応QydFallRyb文章QyeキーワードQyb抽出QyfイレギュラーQyb7つZyb言語UybIoRya４Qyd管理画面QyaxQya系QycNewRyiSolrCloudRyfDesignRyc0日目Qyb速報RydRubySyc3日目Qyc最終日Qyc2日目Qya３Qyd辞書分離QyfテストケースQyd残タスクQyd複数辞書Qyb込みQycjarQyb分離QyeAppleQya教Qyb入信QyeNAISTRydJDicRyeMeCabRylPreprocessorQyb中心Qye開発方法論Qya・RyeモデリングQye設計手法等Qyc座談会Qyb5回QylcompositePOSRy TCompositeTokenFilterQyb修正Qyc対応版Qyc仮実装Qyc利用例QyenaistQyfchasenQyc英単語Qye出力方法例QykTokenFilterQycソースQydじめますQ>vgsummary<ya0Hya1Rya2rya3gya4@ya5Tya6\ya7^ya8Xya9Tyb10Pyb11Ryb12Vyb14Qyb15Qyb16Tyb17Syb18Syb19Syb20Ryb21Qyb22Qyb23Qyb24Qyb25Syb26Syb27Ryb28Ryb29Qyb30Syb32Qyb49Qyb79Qyb84Qyb90Ryb92Qyc201Qyc300Qyc477Qyd2010Qyd2011Ryd2012Vyd2013Xyd2014Qyd2015Qyd2016Qyd2017Ryd2018Ryd2019Syd2020Vyd2021Qyd2022Ryd2023Qyd4897Qye23608Qyf148121Qyb今年kyaもsyb振り[yb返りVycブログUyaをIydリビングQyaでeyb書いuyaてXycいます^ya（^yeドミノ倒しQycすごいRyaなhya）Nya。yya SycFMVQyaの\yeキーボードVybいる\ycタイポQyaがeycつらいQybこのvyb記事XyaはVya、Jyd情報検索Sya・Xyd検索技術RyfAdventTyhCalendarSyd15日目Qyaす^yb昨年\yaにXyb続きSyc2回目Uyb情報Ryb検索Uyb参戦Qya夏QyePySpaRyjアドベントカレンダーSya/Gyb08RyeエントリーSyb昨日Uyb渋川Qybさん]ygアンラーニングQyb失敗Ryaし[yaたnya話aya私Zye続きっぽいQya「nyd機械学習RycによるRyeランキングQyb改善QycガイドQya」fyd読みましTyb著者Qyb鈴木QydさんよりQyb献本QyaいCybだい]yb読みXyc終わっRydレビューQyaとwyeあとおまけQyb紹介Ryb趣味Tya？ZydエンジンTyc関するYyfプロジェクトVyfPythonSyeプログラムTydベクトルQybなど]yb確認Syb含めQygJupyterQyaNQydいくつかTybある]yb環境WycDevSyiContainerRyb動くQybよう]yb変えQyb最初Tyb導入Rya時Tyc疑問点Qybだっ_ydコンテナQya名Tydについて`yb解消Qybメモ`yb生成RydHugoRyb利用Pygブログ移行日記YybそのeydありますXyb当時QydbrewQyfインストールYycいましYybまたXydWSL2QyfUbuntuQyb入れTyb開発Wyaか`ycこちらeyfDockerQygDesktopQycWSLQyjバックエンドエンジンQyb前回aybVSQydCodeSya＋Wybまし^yc残課題Qycとして^yhマルチコンテナ化QycというRyb話もQycしましSyb今回hyaCQycpreQya-TyfcommitQygPyCharmQygWindowsRyb組みRyc合わせQyb困っRybことwyd書きまし]ybこれUyd知り合いSydチャットQyb最近Yyb書きWyd始めましSycきちんQyb季節TybやっZycきまし]yfBerlinXyiBuzzwordsVyeオンラインUyb出張VyfハイブリッドRyb開催bybして[yaくYyaれ~yb参加tybなんXybとかYybますkye時間大丈夫QyawRyb紅白SydリアタイQya見WyaらTye2021年Ryb抱負SybからJybまず_ya返QyftaichiQycDIYTybなく[ybPCYydまつわるQyc仕事中Qyc本記事Qyc9日目QycだいぶRya間Wyb空いSyeしまいまし_yc日本語WyiオートコンプリートSybですbyd日本語用RybためZyhAnalyzerTydどうやっQyb使うSybのかTyb簡単PybもうZyb少しZycいろんSydパターンQya試Qya風QycうわさQykTokenFilterRyfLucenedye取り込まれQyd聞きましQydLUCEQya.WyfアップデートTybするZya際Qybまで_yaやQyiレイアウトファイルQyb修正Vyc個人的Syb残し_ydおきます\yfQuerqyRymElasticsearchxyeプラグインPybどんXydなつくりQybなっhycちょっPybだけVyb調べWycみましUydSolrryeElastRycクエリQydリライトQya用QydなものかSybとりVycあえずUyb概要VyfドキュメントQyd追いかけQyaみ]yb感じYyb現地Qyb再開Ryd人もいるQyb正式Qydリリースpyaさ~yc新しいTydJavaWyfクライアントQya出Syb使っ\yeAzurePyiCognitive^yfSearch\yb2月Tyb機能Uyb公開SyeIndexQyeAliasQyfインデックスSyb別名Qybまだ]yjパブリックプレビューQyb段階Ryb年末Sya次fyb論文Ryb読んPyaだ\yb軽くSydまとめてRygExtremeQyeMultiQyelabelQyhLearningQycforUyhSemanticSyhMatchingQybinVygProductQyd前回読んQyb理由Xyb一緒Syb録画RybオッQybかけRyb再生Qya気_ybなるZyfアーティストQybがらQya書Rye2020年SyaまUybあとWyd今年買っRyc良かっRybものpyfリストアップQydおこうかQyd思いますWycといいRybネタRyb書くWyeといいつつRydスキーマRybときVydポータルQyeフィールドQyb一覧Syb見るQydできますQybただTyb実際TycインデQyepyspaSyb投稿Tyb引きVybらみQyfDomainQyhSpecificQykPretrainingQyhVerticalQya:UydCaseQyeStudyQybonQyjBiomedicalQyjLiteratureQyd論文自体QycリンクVyb参照QybさいWyaSRyeMICESRyb共同Qyc別開催Qyc別日程Qye6月14日Qyc17日QygカンファレンスSyc新機能QygセマンティックQye日本語対応Qyb発表RyfPublicQyaPQyeSofleRybv2Ryc長らくQyeコンパクトQygやっぱりいいよQybなぁ[yeKochiRyhKeyboardSygLunakeyQydMiniQyb発売TycなさんSydスライドUyb作成Vya何RydいますかQygKeynoteQyjPowerpointQyfGoogleQyfSlidesQycMacUya作Qyb新型QygコロナウィルスQyb影響Rybあり[yeオフラインQyc集まっQyc勉強会`ybできUyg検索技術勉強会Ryb1年Ryd以上開催QybないhyaスQyeODataRya式Qyb書式Qyb条件Ryc書けるQyb仕組Ryd検索条件Qya$RyffilterQycソートQyforderbQyb自宅SydいろいろQyc変わっRycなかっYyc更新版Tya(xyb09Qya)ryc前々回Ryb03TyaそQygSuggestQylAutocompleteQyc見つけUyb挙動QybログSya公Qyjオライリー・ジャパンQyjコンピュータシステムQyb理論Qyb実装Ryb始めQyb取るRyb原著QyeオライリーQyaじUyaゃRygCorne使っQyb数字QybキーQycとどうQybはりQycなってQycそこにQyavQyfメインマシンQyb下記QygサンワサプライQycUSBQyb接続RycKVMQydスイッチQyb一台QycノートQyeありここにQyeCorneRyfデスクトップRyb自作Syb立てRycパーツSyfアフィリンクRyb貼っQye10月くらQyeブログ書いTycカタンQyb航海Qyb者版Qyb購入Vyb家族Tyb負けQye2019年RygElasticRyestackWyd18日目Qydなりますlyb本日SybLTQydしゃべりQyb足りQybたんUybこっTybそりQyaIRyeじめましてQyc4日目Qyb大谷QycコンビRyb2号QydそろってQycまとめQyhセパレートタイプRyeLightQyeビルドログQybとしRybヒゲRyb不評RycでいつRyb通りQyb長さQyd切りましQycお試しRya中TycソフトRybたりXyb伸びQybきてUyb試しSye伸ばしてるQyb買っVyb今日YyaこSybごろRyb作業Ryb多くQyaきXyb思っ[yd春くらいQycなんかUyb知らQygTwitterPyfタイムラインQyb06Rye00くらいQycマージQya@^yfminoruQya_XyeosukaQyb継いRygLinderaRyhKuromojiXydRustqydクローンQyeリポジトリQyb先日QydシステムVyb構成Uyb大体QycうまくQycヒットQybといQyd自宅環境QybあっYyaおWyc客さんUycおかげQyb相変QycわらずQyaせRycもらっRybてるSyb昨今QygコロナウイルスQyb便利SydクレートQyb自分VyeそもそものQyb問題Wyb処理Zyb言語Zyd100本ZycノックZya第syb4章\yb早めQydやりましQye形態素解析RydですしねQyb吾輩Qya猫Qyb3章Uyd空きましQyd正規表現QycすかねQyb負荷Qyb計測Qyb数回QyeクラスターQyb起動Ryb停止QycたりしRyiTerraformQybやるRya楽Qyb特徴QydふんわりQybまぁVya頭TydぼんやりQyb考えSyb文章Tya他Wyd検索周りRyb手伝SyaうQyb仕事XyfフリーランスQyb知れRyaばXyb知るQybほどTyb面白Wyc自分用[ydにくいかXycthebydBookYydbookXyb5章Wyb6章Vyb8章Uyd6月7日Qya週Qya?VydベルリンSycBigQyjluceneutilRyeマニアックQycツールSyfセットアップVyb誰得Qyb興味Yyb場合Tyb飛ばQyeしましょうQyb一応TydREADQycFSTQyb関連TygパフォーマンスRyb自体Qyb以降Ryb直るQyb扱うRyf形態素解析器Ryb使いTybたいRyc2種類Qyb用意SycこれらQyb違いRycなものSycSDKQyhアプリケーションQycに対しQyb送信QyeリクエストQyeパラメータQyiMircosoftQyeBuildQydイベントXyb今週SydありましRybMSQyb方やQyb教えRycそこでSyeセッションVyfMyBuilQyiWorkplaceSyb触っ[yeStackSyb2章Syb残りRyaちTybなみRyd標準入力Qyb受けTyb出力Syb関しRydファイルWyc気づいTybたらWydヶ月サボQyaっSycごめんQycなさいQydじめましSyc確認用QydUnixQybコマQyhリファクタリングRycとっくQyc暗号文QycpubQybfnQyfcipherQydtextQya&UycampSya;UycstrQyb-&QybgtQyb要素Qyb説明SybなおQyc7時点Qya社QyjEnterpriseQyb呼んQybでいSyb製品Syc製品名QydカスタムRyb辞書Zyb方法Tyb設定Vyb記載Vyb更新Vyb要望QybよくTycAWSUyeServiQyb7章QyaパQycコードQyb載せQybほうRyb見やQycすいかQyc円周率Ryb2年Qya前WydどちらかQydツイート[yd言語処理Rya版Ryf自然言語処理Syb研究Qyb動向Qyb反映Qyb深層QykニューラルネットワークQya関QydEnumQydmatcQycCLISya方Yyb過去Qyb御覧RydコマンドTygpicocliQygGraalVMQyaGQyc構造体Qyd勝手知っQybたるQybやらQyeすもけさんQyf在宅勤務環境QydおもしろQybそうWya貼QybれるVybなとVyc私自身QycたぶんSydいちばんQyb大事Qyb概念Qya思QyfVisualQyfStudioQyb作っVygAnalyzeRyfClientQydタイミンQyd自転車本Qyc良いかQyb知りSyb合いRya先Rya読Qyb動機Qyc手伝っQyb基本Rya的UybさせQydだきましQydもともとQydJJUGVybナイQyb実践Wyb入門\ybでるRybころZyb終了Rye終わりまでQyb終えQydいきなりQya少Ryc初心者RyeRust製Ryi日本語形態素解析器QybでみRyg日本語形態素解Qyb読書Qya本^yd合わせてQybだくQyb良いUygクイックツアーQyaバRycしまっUyb記録RybこうRyfBRAVIAQybKJQyc55XQye9500GQyfAmazonUya|QycソニーQydSONYQyc手伝いQya=Rya形Qyb入っRybおりSybいくRyc始まるQydまだまだQyb勉強SycたいしQybこんWyd検索シスQyc何種類QyfボードゲームRye楽しみましQyb感想Xyb交えQycようかSyb知人Qya参Qyb去年Vyb7月Qyb積んQyb時間Tya[Qyc言語仕Qyc12月Qyb退職RycしますQyeその後どうQyd一応現在Qyb状況Ryb留めQyeおこううかQyb結論Qyb起因QydいつものUyb5年RycくらいRyiOctopressRyb使用QyeコンテンツQycかかるQybほかQyfプラットフォQyfSasukeQycがついQye2018年Rya元XyeTOEICRyd受けましQybTOQyb普段SyemacOSQyb標準QyeターミナルSyhドットファイル系QyeemacsQyb引っQyb越すQybたびQycコピーRyeいいかげんQyfGitHubQyb管理RygMacbookRycProRyc新しくRybなりTybOSQyhCatalinaQygなっちゃいましQydbashQygprofileQyb立ちQyb上げRyd最近使っQyb手元RycインチQybほっQydたらかしQye最終出社日Qyc退職日Qyd有休消化Qyb思いWyb返せQycヶ月もQydElasYyb日目Qyc1日目Vya質Qyb高いQyb続いQyd一旦休憩Qyb頂くQybヶ月Tyc今年起Syb返っTyb毎年Qyb恒例QybすねWygBonfireQydDataSygScienceSya#Pya枠Ryb日時Syb00Tyb場所RyeYahooRya!UyeJapanUycサイトWyehttpsQyb:/SybyjQyfmeetupRyhconnpassQyccomRyeeventQyfハッシュタグQyiyjbonfireQy PElasticsearch勉強会_yiAcroquestQyjTechnologyRya人UybたちRyb技術Tyb書展Qyb販売Qyb書籍Wyb頂いRyfMeetupTyb切りQyb替えQycたらーQyc受付用QycアプリRycかなくQyfElastiSyaんXycだけどSyb独学QybなーQybみんRybどうRycだろうRybどーSygjohtaniSykEngineeringQydTechQydTalkQyb運営Ryb1回Syb開始Qyc1回目QycよかっQye2017年QybもっQyb英語Uyb継続Rya＆Ryd25日目Ryb最後Vya！^yb来年Syb忘れSybなけQyaずTybすでQycalpQyb遅れQyeちゃいましQybみよQyb転職Tyc前までQyeパスポートQybすらQyb持っRya今Tyb会社Ryb半年Qyb1度Qyb割合Qyb海外UyaへVyb発生Qyb生活Qyb送っQyd毎月開催Qyb日経Qyb会場Vyb借りRydなりましWyeスピーカー[yb募集QydhttpRycbitQyblyQybSpQygナイトセミナーQycAPMQyeAgentQyb補足Qyb久々]yc第2回RyhtemplateQyfディレクトリQydどういうQyb流れWycデータVybやりRyb取りRycについRyhMANABIYAQycブースRyb合間QybここQyb数年QyeスポンサーQyb色々Tyb05SyanRydgramRyb大好Qyb単語Syb文字QydそれぞれQyb別関Qyb04Sye入力文字列QyesplitQyjwhitespaceQyb()Qyb分割Qya鉄Ryd熱いうちRyb打てRyb1章Qyb02RybさてSyb効率QybいいRydかどうかQybどもRyb退化QyehappyQycnewRydyearQycandZyhlanguageQyikatsyoshiQydのめもみQyb触発Qyc第1回QybUIQybごくRyb2回QyfKibanaYya順Qyb追っRydあけましTybおめTygとうございますTybサボQyaりQydがちだっQycとずつQyb復活Qyb1弾Qyc昨年少QyaKQyb見なQyb行っ^ye2016年QycもちろQyeMerryRyiChristmasRyd24日目Qyb以上RyhSwiftypeRyc内検索RygプレスリリースQya：hydサービスUyc最大手Qyb買収Qyc出ましQyfSwiftyQyb執筆SydといってTyb以前Wyc私以外Qyb方々Uyb結構Tybな量Qyb直しQyborQyd新規書きQyc起こしQyb主催UyeプロダクトRyb超えQyb共通Qyb課題Qyb悩みRycRioQyfプレイバックQyaQybながUyb長いRyb一年Rye2015年Qyc最終日Tyb変遷RycみますRyeクエリプロQyd10月末QyeでいくつかQyb久しTybぶりVyfIngestQyiProcessorQybたくVybみるQycんじゃQyc3番煎Rya物Ryc壊れるQyb厄年QycからかQyb記念Ryb壊れRybたかRycおこうRyc腕時計QycないかRyd電波腕時Qyd第16回Qydスタッフ[yc皆さんTyd会場提供TylリクルートテクノロジーズYyd第15回QycポストQyd技術書読Qyb監修Qyb見てUyc14回Qya皆Qyc紅白見Qyb早いSye2014年RydエントリSybにちRyb師走Ryb今月Ryc一番忙QybかっTyeたりしますQyaARyd第13回Rya※dyb翻訳dyb原文cycTheTyeStoryQybofQyeSenseSyjAnnouncingQydbetaXyb誕生Qyb同様QycビールQyb飲みRya考QyfShieldSya,XygWatcherRyfMarvelSybGARyhReleasedUycおよびQydMarvQyhreleasedPyeコミッターSya+Ryb💚QydサポートQyhLogstashWyfRelaseQybweQydhaveQyb画像RyaごSyb覧くQycとってQyb大きSyb1日QycベースQyiunpluggedQyjNetworkingQygchangesRydローカルQycマシンQya起QyfDeleteQybbyQyeQueryQycAPIVybIsQycnowQyaaQyfpluginTyd第11回QyaERyb東京Uyb以外Uyb2弾Qyb関西Qyb大阪Qya京QyeGreatQygMappingQykRefactoringQycユーザSyb最もQyb一つQycタイプQyfcomingQydsoonQyb準備QyaヶQyb月前QyeFoundRyfjoinedQycourQydteamQybatQyeアナウンスRyb素晴QybしいRycチームQyb彼らQydによってQybよりWylJustTechTalkQybあれSyhジャストシステムRydJMATQyfKagomeQyfJanomeQydひさびさTye勉強会メモQyfHatenaQyhEngineerQygSeminarQyeTokyoWyb当選QycいつもRyb近寄QydオシャレQya街QydドキドキQyd第10回QyoElsticsearch勉強会Vyd開場提供UygReindexQydWithQyfThanksQyeDavidQyeマッピングQyb変更UyaサQydJoinQylConversationQygDiscussQybCoQyb3つQycOSSQygスケールアップQyiコミュニティサポーQycElaRyc第9回Ryc名古屋Rya初Xyb企画QygsmogamiQyhサンフランシスコQyc弊社初QyjユーザカンファレンスQygelasticRya{QybONQya}QydアメリカQyc出張中QyaユQycyouRydknowQyhsecurityQyfshieldQydgoesQybgaQylElasticsearcQye4月13日Qyc3日間QydCoreQyfトレーニングQyeEarlyQydBirdQyb申しQyc込みすQyfkibanaQyiliterallyQyb現在Tyd文字通りQyc抽象的Qyc概念的Qyc精神的QycそしてRyc楽しくQymelasticsearchRyb来るQyd4月4日Qyc土曜日Qyb午後Ryb予定Uyc第8回QygrunningQyfgroovyQygscriptsQygwithoutQygdynamicQyiscriptingQynElasticsearch1QybによQyeCROSSUyd話もしてQyb横浜Ryc大さんQya橋QygあんまりこないQyb乗りRyb換えRydおたしてQydしまいまQyc大晦日SycしかもSyb飲んRyb9流Qye2013年QygCalndarQybにつQycなげるQyb意味QyfmarvelQyb「【Qya】Qyhナイト・セミナーQyh自然言語処理特集Qya水Qyb本当Rya入RycたまにQyb他愛QydコーヒーQyfサムライズムRydオフィスRyd入り浸っQyhexcitingQyhlogstashRyiecosystemQydBetaSyeインストーRycページTyfダウンロードXye始まりましQyhElasticsQyfApacheRyfアクセスログRyeインポートQya説QycCCCSyb7回RybデモRyeどうやってQyc第7回Qyc書こうUycらかけQyhvalidateQyb背景QykElasticsearQyb個人RyhextendedRyganalyzeSyc第6回Qyd9月9日Qya火Qya『QycサーバQymインフラエンジニア養成読本Qyb収集Qya〜Qyd可視化編Qya』Qyd出版記念Ryc執筆者Qyb語るQyb大講Qyb演会QyhelasticsQygインデキシングQyb検討QykperformanceQynconsiderationsQyhindexingQy PElasticsearchユーザQya様Ryc懲りずRydみなさんQycだけるQycとうれQyb本書Qyc共著者Qyc詳しいQycそちらQyeProxyQyb働いQyb方もQya上SydインストQygバグフィックスQycリリーQygCuratorRyb古くQyaFQyc第5回Qyb遅くTyb出てSyb無理Qyb言っQycにしてQycたいんQyb時差QybボケQyb頭痛QyeこのくらいQyc余裕出QycほしいQycリストRyc新天地Qya明QyfserverQyc2ndSygeditionQyeバージョンQyb目次Qyb元にQyaどQydのくらいQyc可視化Rye現状確認会QyjカジュアルウォーターQyb現状QyhMackerelQyhGraphiteQyb目黒QydドリコムQyb最新Qymインフラエンジニア技術勉強Qya～RygFluentdSydChefQyb実例QydどうやらQyb中身QydたらしいQyiプロダクトシリーズQya｜QyeよくわかるQybClQyb酔っQyb払っQygスピリチュアルQyb流しRycだけれQymアジャイルデータサイエンスQyb見本QycだいてQybなのSyc感想文Qyb想像Qyc薄かっQyc物理的QykAggregationQydサンプルRybHiQyeWouldQyfpleaseQydtellQybmeQycwayQybtoRydkopfTyhAnalysisRyb画面Uya３QybあいRyb開いQyb必要Ryd見つけてQydBulkQyb仕様QyaJQyc第4回Qyd遅刻厳禁RydそれほどQyc人もいQyb思うQyb次回Qya２RydメニューRyhanalysisQyb選択RycJVMQyiOperationQyfCasualQyeTalksQydあんまりSyb運用QycかやっQybついSycいけるRyb不安Qyb楽しQyc懇親会RyeないらしいQydRESTQydrestQybだかQydドタバタQyc旅行記QydこちらかQybkoQymElasticSearchTyfServerQyc電子版Ryd出ますよQya発QydGOTOQyeNightQyd海外自体Qyb初だQyeWoogaQycからおQyeございますQyb人生Qyb初めRya来Ryc人生初Qyb一人QybへんRyc入れるRycときっQyb幸せQycなれるQylelasticsearcQyc第3回Qyb触れRyjServer日本語版Qyc今年初Qyb突撃Qya隣QyhWantedlyQyhにおじゃましましQyb写真Qyb撮っQydたまたまRyb日本QyhスペシャルゲストQyb呼べQyc大満足QyaｗRyb通訳QydかちゃんQyfすずけんさんQygVagrantQyipuppet使ってQybVMQydクラスタQyb組んQyd改訂新版Qyf入門出版記念QybいうQyfSolrJPQya新Qye本出版記念Qyf技術評論社様QybプレQyb昨晩SydさっそくQybみてQydバイナリQyc配布待QyfluceneXyegosenXyb1対Qyb応版RyeライブラリQygインタフェースQygcuratorQyeAaronQykMildensteinQyc頑張っQyb所存QycとまぁQydお決まりQyb挨拶QycおいてQyb進歩QybかもQye2012年Qyd昨年書いRyb昨夜Qyb内容Uyb本家QyfreleasQyb質問Tyb言いRyd出しましQyb配置QycURLQyb辛いQycすよねQyaねQyeMavenRyjRepositoryQyb電子Rye技術評論社Qyb可能VycPDFRyb宣伝Qyc改めてQyc改訂版QybみれRyb3年Ryc前なんQyc出来るRyb形にQyj140人くらいくらいQye参加登録者Qyc参加者Syd１００人QybょっQycがいてQydびっくりQycステキQyb提供QyhClouderaVyeWorldQyc午前中QybにくQya雨QybそれRyb人数Qyb基調Qyb講演SydセッショQydまたまたTydRiakTyhYokozunaSyb聞いSyc開発中Ryb改良Ryb以下VybソーQyeお久しぶりRydたらまたQyc今開発Qye不定期開催Ryc12回Qyb過熱Qyc無かっQyc70人QyfいらっしゃっQybMLWyjinquisitorQyjElasticSeaQyeriverQyiwikipediaQydbulkQydsizeQyb登録Ryb件数QybやけQycにきりQye前々回紹介QyiWikipediaQyeアナライザQydインデッQy PElasticSearch勉強会QyepyfesRyfなんちゃってQyb資料Qyb喋っQydたちましQyoElasticSearchネタQye勉強会開催QycたりすQybおきQyb手軽Qyb宿題Qyc周りっQyc調べるSyd今朝起きQyfXperiaSyaZRyb故障Qyb電源QycボタンQyb押しQydスリープRybならQycないんQyb復帰QyjMorphlinesQybさらSyd調べましQyb誤解Ryb認識Qyd話しましQybたみQyc11回Qyc大入りQyf90人くらいQyiがいらっしゃいましQyfHadoopYyb離れSycちゃっQydHiveQyb無いQyfもかかわらずQyb近くQycにいるQycからっQyb内緒Ryb玉川Qya点QydというかSyb観点Qya別RydわけじゃQyb完全Qyb自己Qyb満足QyeBashoRyfにおじゃましQyc聞けるQyf取り込まれるQydチケットVybとくRydSOLRQyb経由Qyb眺めQybみみQycぐらいQyc初記事QyfちょくちょくQyc1週間Qyc以上前Qyb遊びQyc来ましVybRCRydVoteSyc始まっQybコトQyeマルチコアQybファQyc何番煎Qyc？ってQyb書かTybコリQycもせずQydタムタムQyaロQyfSummitUycryuQyikobayashiQycパシリQye仰せつかるQyd忙しかっQyc楽しかQybざっQyiインストールガイドQyeソース眺めQydテキトーQyfユーザガイドQyicocoatomoQyb行きQyb掛けQyc出会っQyfアンデルセンQybTDRybryQyeモジュールRybTLSyc賑わっQyd軽くどんQybだりQyb憧れQyffluentQyhZoomdataQyd最近触っQygfluentdQya流Qyb込むQyhMarkdownRyb慣れQyb書けQycどうしQydようかっQydそのままQyfGithubRyePagesQycらしいRygChangesRybしまQyeアジャイルQye時間管理術QyjポモドーロテクニックRydきっかけQyb何度QyeポモドーロQyd00現在Qyb訳しSyb詳細Qyb最中Qyd00時点Qyc開発者Qyd第2回目Qyb欠けQyb視点Qyb話しTyc寒かっQyeエンジニアQyfスキルアップQycペースQyb落ちRyc危機感QydJIRAQyfバックアップQyfHerokuRycじめるRyeRailsRygプログラミングQygheroku気Qygアカウント作っQyfデータアップQyc軟弱者SybべきQyc10回Qyc発表者Qyb無事QydあつまりQygとうございましQyb盛況QybほぼQyb満員QycツイーQybとてQyfsearchQyb出演QycスマホQyc」ってQyeキーワードQycあまりQycたけどQybいっQycarcQydもうすぐQyb２年Qyc容量不Qyc金曜日RyaよRyjConferenceRyfWinterQyb触るQya金QyiエンジニアサポートQyiセッションオーナーQyeモデレータQyb来まQydいまさらQyc感満載Qyb担当Qyb年始QycかけてQykコード・シンプリシティQyfKindleQyjpaperwhiteQycかけずQyb入手Qyd思いついQyeMongoQyiAtlassianQyd20日目Qyd急遽参戦Qya某QydイケメンRybMTQyb改変QyeリツイートQybSoQyc第一回QyiJetBrainsQyhユーザーグループQyejbugjQyb入りRya口RyaイRydヒカリエQyb不純QydおしゃれQyb綺麗RycカフェQycおっきQyb人形Qyb立っQyc皆勤賞Tyc主催者Qyc不定期Qyc方などQyc初目黒Qyg初AmazonQyc流行りQyfビッグデータQydセミナーQybあえQyb##Qyc3年越QyiウチダスペクトラムQyfMahoutQyeGrantQyiIngersollQycPFIQyhオープンセミナーQyb対象Qyb微妙Qyb外れQyb自信QyeありませんQyb友人QybにおQyb値打Qyb価格QydminiQyhMountainQydLionQycAirRycませんRydもちつつQyb聞きSyb作者Qyb古橋Qyb魅力Qyb次期RyciOSQyb連携Qyb分析QyiクライアントアプリQyb苦労RyeステッカーQya欲Qyc勉強中Qye恥ずかしげQyc偉そうQydしゃべっQyaタQyeALPHARyc興味深Qyc数日前QygPartialQyidocumentsQyfupdateQye見つけましQyfModernRykInformationRyiRetrievalRyhConceptsQyfbehindQygEditionRycACMQyePressQyeBooksQycいやぁQyb蒸しQyb暑くQybなかTyb寝れQya日QyeじまりましQybたねQyb関係Ryb伴いQydgoenQyb4xQydブランチQycjarVycいまだQyaあQybとっSyc第一弾Qyd参加人数QydはちょっQyhHBaseConQyeIssueRybがっQyeluceeQyfUniDicRyb対応QycパッチTyb勢いQyb見直QycとかしQyb状態QydおかしいQya図QyfZipkinRyfReadmeQydせっかくTyb悪いQygアーキテクチャQycトレーQyc結構前QyfschemaRycxmlRyifieldTypeQynautoGeneratePhQyc読まれQyd方もいるQyb先週Qyc木曜日QyhエンジニアブログQyc最新版UyiプロジェクトページTyeharuyQyb情けQyeしまいますQyb調査TycケースRyetrunkRyclibQycテストQycEテレQymスーパープレゼンテーションQyaふQybだらQye恥ずかしくQyalQyfSpringQydFallSygタイムテーブルRya一QynPlayFramework2QyfコーディングRyb兼ねRybIDRyb秘密Qyb丸善QyfライブラリーQya―Qyc情報研QydシリーズQyb非常Qyd読めましQyeバーコードQyc始まりQyb付与Qyc考慮点QygWebSolrRye嗅ぎつけてQybJPQyfherokuQyd知りつつQyb0対Qyb動作QybせるQyc変更点QydいきますRyh日本語形態素解析Qyd含まれるQya各Sydブログ流Qyd読みしてQydスケールQya主RygJavaOneQye2日間開催Qyb子供Ryb体調Qyb崩しQycしまいRybのみQyfテストケースSyhharuyamaQyfhideakQyb宣言QycとおりQyeパッケージQycクラスQyb皆様Qyb連絡Qyd連絡事項QybにてQycorgRyb寝かQydしつけしQyf寝かしつけさQyb２時Qya目Ryb覚めQygTSUTAYAQybCDQyfウォークマンQybはいQyb回数Qyb直前Qyd変わってQyd見かけてQybSEQydAmazQybえーQybとふQyb１年Qyd前くらいQybずーQyeつぶやいてQyeScalaQyc長かっQyc森ビルQydそのへんQyb矯正Qya遊QyeCleanSyeCoderRynプロフェッショナルプログラマQya道QycがいいQyb本だQyb親子Qyd楽しめるQyb絵本Qye身につけてQybおいQygyusukeyRye異なりましQyb広くQyc大画面Qya駅Qyc嬉しくQyeissueQycアップQye勉強会ログQyeすみませんSyd直接業務QyeリクルートQyb中野Qya顔Qyb出しQydばっかりQya役Ryb立つQyc昨年末Qyb増えQyc備忘録Vyb公約QydatndQyfeventsQyb01RyhアカデミーヒルズQyc六本木QycヒルズQya内Qyc49階QyfタワーホールQyb港区Qya六QyeベルサールQyb三田QydRoomQydシアターQyfInsideQydMapRQyb内部Qyd自己紹介QygSusheelQygKaushikQya系RygインフルエンザQyd一家全滅Qyb最悪Qyb陥っQya我Qya家Ryb流行QycつけてSyaxQyb年越QyfしちゃいましQyb5日Qyb中心RydツッコミRybコメQyeたちよりひQya足QybやいQye終わりましQya振QycサインQycもらうQyb目的QycもらいQycそびれQyb残念Rye特定文字列QybいつRyc継続中Qyb暇人QybなしQycすねぇQycといっQybいやQygDSIRNLPRyb基礎Qyb部分QybおろQybそかQydないけどQyhTokyoNLPQyiWebMiningQycMBAUyb物理QycカバーQyb大量Qyc読めるQyb速読Qyb合っQyb持ちQylソースコードリーディングQyb6回Syc先週末Qyb勤労Qyb感謝Qyc日までQyb風邪Ryc寝こんQyb朝晩Qyb冷えQyb込みQyc激しいQyb言葉Qyc触ろうQygMongoDBQyb2週Qyb連続Qyb渋谷QycさすがRyb出口QybすんQyb武田QyfSplunkRyb様々Qyb機器Qyc一箇所Qyb集めQydリアルタQyc最近忘QybすいQyhBookscanQyc電子化Qyb原本Qyb破棄QycくれるQyd電子書籍QybずっQyf新規追加機能QyfすぐやりますQyd言いつつQybはやRya腰Qyb重いQygダメエンジニアQydようやくSydコミットQybすぐRydあくまでQycHadQyb特定Qyb探しQycできるRybねぇQycあいてQybIoQybなれQygセルフスタディSyb回答Sya記Qyc色々入Qyb追加RycAIRQyiTweetDeckQydでちょっQyc見ましQybほんQydにちょっQyc英語力QybなさQyb痛感Qyb凹んQyb何かQya恥Qyb晒すQydWikiQybもとQyb下部Qya会Qyb疲れQyb機会QybだきQybとうQyb台風Qyc15号QycごかっQyb幸いQyb夏休Qyb通勤QycひどいQyb合わQydすみましQyb風雨QydすごくてQyc怖かっQyb速報Ryc知らせTycちなみQydRubyQya大QycだかんQycところQya概QygRuby2日目Qyc2日目Qyc2日間Qya実QyeぶりくらいQydゆっくりQyb日々Qyb訪れQyd積読状態Qyb消化Qyb7つRyb世界Qyb出先Qyb使えQyb進んQygEclipseQyhhomebrewQyc一週間Qyb着いQyb追記Qya異Qyb分離QybあげQyfRobertRydたらしくQyb話題Ryb同梱QyeクラスパスQyfからいくつかQyb文体Qyb変かQyc順不同Qyb参考QyhEvernoteQygDropboxQyc個人用Qyb８年Ryb新調Qyd前回購入QydなりつつQyc買おうQycかなりQyb構造Qyg言語処理勉強会Qyb帰っQyc２日半Qyb寝込Qyb春山Qya耳QycソースUyeでいませんQyjcontributeQycしまうRyd少しずつQydコメントQybいれQya毛Qyeお知らせしQybバグQyb込んQycタイミQyb分散Qye開発方法論QyeモデリングQye設計手法等Qyc座談会Qyb5回Qyb入るQyfイベントルーQyc上がっQyc未知語QylcompositePOSQycエラーQya件QymtrunkbranchesQydimplQyemecabQycdicQyeNAISTQydJDicQyeMeCabRycPreQyenaistQyfchasenQygアルファベットQyb別々Qyc英単語Qyb含まQyb目玉Qy QJapaneseTokenizerQyc形態素Qyb遅延QyiTokenizerQyhToken対してQyb特性Qyb2つQyfIPAdicQycビルドRygJavaDocQyc見たいQydMuirQyb歴史Qyc移植版QydスタートQyc今さらRycはじめQya…QydはじめてQyb一番QybわりQyb残すQ>vdtags<ya2Rya4Qyc100[yb振り[yb返り[yeoramaQyfsearchQydmiscbyemusicRycbotQyb読書XymelasticsearchoyisearchkitQya-sybuiQyb画面QycdevTya byicontainerTydhugoTycwslQygwindowsSyfpythonSyjconferenceUyebelinQyibuzzwordsUyjopensearchQyflucenedyfberlinTydjavaQyeazure[yepaperRycDIYWyeキーボードWyeMICESQyc勉強会Jyb輪読QydNandQyfTetrisQydRust]ygLinderaQyb検索Uycnlp[ydrustUyctheYydbookYyhkuromojiSya.RycnetQygelasticTyestackQyiworkplaceRyfvisualRyfstudioRydcodeRyb買いQya物QycブログVydシステムQyb探訪QycゲームQyb転職TyioctopressSyfLuceneRyb書籍QyfKibanaSyfplugin_ygカンファレンスQyeスポンサーQyfkibana[ya本UyhtimelionQyesenseQyfshieldRygwatcherQyfmarvelTyhlogstashWyefoundQybnoQyielasticonQydjjugQyfcoffeeQymElasticsearchSyhsonatypeQygreleaseQygcuratorRykCloudSearchQycAWSSygスピリチュアルQyc感想文QyeオライリーRyfstreamQybesQycJVMQydJavaQyftravelQygvagrantQyfpuppetQydSolrRyegosen`ygfluentdSyhClouderaZyfHadoopUygNorikraQydRiakUyhYokozunaUyjManifoldCFRyiwikipediaSyfSearchVyjMorphlinesRyfXperiaQyaZQydHiveQyeBashoQyhZoomdataQydsolr]yc備忘録_ydJIRAQyfZipkinRycOSSQyeScalaQyfhadoopRye形態素解析Q>vnavgFieldLength4ybid Q9.029850746268652yetitle Q12.96268656716417ygsummary Q39.88805970149251ydtags R1.3145292852726016vlfieldLengths4vbid<ya1Wya2Uya3_ya4Yya5_ya6Yya7[ya8Zya9_yb10Qyb11Tyb12Qyb13Tyb14]yb15[yb16Qyb17]yb18_yb19Zyb20]yb21Ryb22Uyb23Ryb24Qyb25[yb26Uyb27Tyb28Zyb29Qyb30Vyb31[yb32\yb33^yb34Zyb35Pyb36Ryb37Zyb38Pyb39Xyb40Ryb41Xyb42Tyb43_yb44^yb45]yb46Zyb47Vyb48]yb49Qyb50Xyb51Yyb52Yyb53]yb54Xyb55Yyb56\yb57Wyb58Uyb59]yb60Syb61Tyb62^yb63Zyb64Ryb65Qyb66Xyb67Zyb68Ryb69[yb70Zyb71Zyb72Tyb73_yb74Tyb75^yb76Zyb77Tyb78[yb79Ryb80\yb81^yb82Tyb83]yb84Qyb85Syb86Tyb87]yb88^yb89Ryb90Pyb91Uyb92Qyb93Qyb94\yb95Ryb96]yb97Vyb98_yb99Pyc100\yc101Yyc102Pyc103[yc104\yc105Tyc106Syc107]yc108Uyc109Pyc110\yc111Xyc112Ryc113Syc114Yyc115Qyc116\yc117_yc118Syc119Ryc120[yc121\yc122Yyc123^yc124Qyc125Qyc126Yyc127Wyc128^yc129^yc130\yc131Tyc132Ryc133Zyc134Uyc135Yyc136Ryc137Yyc138Qyc139^yc140\yc141[yc142_yc143Uyc144Ryc145Qyc146Zyc147Ryc148Zyc149Qyc150Qyc151Syc152\yc153Zyc154Zyc155Uyc156]yc157Qyc158Xyc159\yc160Zyc161Tyc162_yc163Zyc164\yc165Zyc166Tyc167\yc168Tyc169Yyc170Uyc171^yc172]yc173Qyc174Tyc175\yc176[yc177Ryc178_yc179_yc180\yc181_yc182]yc183[yc184[yc185]yc186^yc187Qyc188Ryc189Uyc190[yc191Qyc192\yc193Zyc194Syc195Uyc196Pyc197Qyc198Pyc199[yc200\yc201Ryc202Wyc203Pyc204Qyc205Wyc206Tyc207]yc208_yc209]yc210Tyc211Tyc212_yc213[yc214Xyc215Tyc216\yc217^yc218Wyc219Qyc220Uyc221Ryc222]yc223\yc224Zyc225Qyc226Syc227Qyc228Qyc229Vyc230Zyc231Pyc232\yc233Ryc234Tyc235^yc236[yc237]yc238Wyc239[yc240Syc241Zyc242]yc243_yc244Syc245Qyc246Zyc247Zyc248Xyc249Yyc250Vyc251Qyc252Wyc253Tyc254Qyc255Syc256Yyc257Vyc258Tyc259[yc260Vyc261^yc262Xyc263\yc264^yc265Yyc266\yc267Tyc268Ryc269[yc270[yc271^yc272_yc273Qyc274Tyc275Qyc276Uyc277Ryc278Ryc279Tyc280Syc281Tyc282Vyc283Wyc284^yc285[yc286\yc287Qyc288[yc289]yc290Syc291Tyc292Qyc293_yc294Tyc295[yc296Uyc297^yc298Pyc299Ryc300Zyc301^yc302Qyc303Zyc304Vyc305Qyc306_yc307Tyc308Pyc309[yc310^yc311]yc312Zyc313Zyc314]yc315Zyc316]yc317Xyc318Xyc319Tyc320Vyc321Yyc322Ryc323_yc324Syc325Qyc326Xyc327_yc328^yc329Zyc330Xyc331Ryc332]yc333Qyc334Qyc335Syc336Tyc337Uyc338_yc339Pyc340\yc341Uyc342_yc343Xyc344Xyc345Xyc346Vyc347]yc348Qyc349Qyc350_yc351Ryc352Qyc353]yc354^yc355Tyc356]yc357Pyc358Yyc359Qyc360Xyc361Wyc362^yc363\yc364]yc365]yc366Uyc367^yc368Zyc369Pyc370Tyc371Qyc372Qyc373Qyc374Qyc375Pyc376\yc377Xyc378[yc379Qyc380Ryc381Syc382Wyc383Qyc384Syc385\yc386Qyc387Tyc388Tyc389Tyc390Wyc391Qyc392[yc393Yyc394Ryc395]yc396Vyc397Syc398[yc399Qyc400_yc401^yc402[>vetitle<ya1[ya2\ya3Yya4Yya5Wya6]ya7Vya8Vya9_yb10]yb11]yb12[yb13[yb14Tyb15Yyb16Zyb17Vyb18Uyb19Yyb20Wyb21[yb22Uyb23[yb24Xyb25[yb26Vyb27Qyb28Vyb29[yb30Yyb31[yb32Pyb33Tyb34Zyb35_yb36[yb37Yyb38\yb39Pyb40Tyb41Pyb42Uyb43[yb44Uyb45[yb46]yb47Xyb48Tyb49Zyb50Zyb51^yb52Yyb53Tyb54Wyb55Wyb56[yb57_yb58Pyb59Zyb60Yyb61\yb62Yyb63[yb64Zyb65Zyb66Yyb67Syb68\yb69Zyb70\yb71\yb72\yb73Tyb74^yb75Vyb76Zyb77Zyb78\yb79Uyb80Zyb81\yb82Zyb83Wyb84Zyb85]yb86Yyb87Uyb88Yyb89Xyb90Yyb91Wyb92]yb93[yb94\yb95Ryb96Vyb97Wyb98^yb99Tyc100\yc101[yc102Yyc103[yc104Xyc105Ryc106Tyc107Vyc108Ryc109[yc110Wyc111_yc112Zyc113Yyc114Xyc115Uyc116[yc117Pyc118Wyc119Yyc120Xyc121Uyc122^yc123_yc124_yc125_yc126_yc127Yyc128^yc129^yc130[yc131Uyc132Wyc133[yc134Zyc135Xyc136[yc137Uyc138Xyc139\yc140Uyc141[yc142[yc143Zyc144[yc145[yc146Syc147_yc148Zyc149Uyc150Qyc151[yc152[yc153[yc154Yyc155^yc156Pyc157^yc158]yc159Zyc160Syc161Syc162^yc163Wyc164_yc165Yyc166Ryc167Uyc168[yc169Zyc170[yc171Yyc172Syc173Zyc174[yc175Pyc176[yc177Uyc178Yyc179Uyc180Vyc181Qyc182Wyc183Zyc184Zyc185Qyc186]yc187[yc188Yyc189[yc190Qyc191Pyc192Qyc193Yyc194^yc195Syc196Qyc197Syc198Yyc199Zyc200Qyc201Uyc202Yyc203\yc204Zyc205Pyc206Wyc207^yc208Xyc209\yc210Zyc211Zyc212Tyc213Tyc214Yyc215\yc216Xyc217^yc218Wyc219Tyc220Yyc221Yyc222Xyc223Zyc224Yyc225_yc226Yyc227Xyc228]yc229Zyc230Uyc231Wyc232Xyc233Yyc234[yc235_yc236Xyc237Wyc238^yc239Zyc240_yc241[yc242Vyc243Xyc244\yc245Xyc246Xyc247Xyc248[yc249Ryc250Pyc251Wyc252Xyc253[yc254Vyc255Wyc256Xyc257[yc258\yc259[yc260_yc261Syc262[yc263Xyc264Yyc265Pyc266]yc267Wyc268Vyc269Xyc270Xyc271Tyc272Tyc273Wyc274Tyc275Vyc276^yc277Zyc278Yyc279Qyc280dyc281\yc282Syc283eyc284kyc285\yc286]yc287Pyc288Pyc289nyc290Zyc291Wyc292Yyc293Vyc294Yyc295Pyc296Qyc297Syc298Yyc299Pyc300Ryc301Wyc302Ryc303Syc304Qyc305Yyc306Tyc307Yyc308Tyc309Yyc310Ryc311Qyc312Qyc313[yc314Pyc315Pyc316Zyc317Syc318Vyc319]yc320Zyc321[yc322Syc323Tyc324Syc325^yc326Uyc327Wyc328Yyc329dyc330_yc331Uyc332Ryc333Ryc334_yc335^yc336Syc337Vyc338Xyc339Vyc340[yc341Pyc342Zyc343Syc344Qyc345Pyc346Yyc347_yc348]yc349^yc350Qyc351_yc352^yc353Wyc354]yc355Tyc356Syc357Xyc358Wyc359_yc360Wyc361Qyc362Qyc363Ryc364[yc365[yc366_yc367Syc368Qyc369Ryc370Zyc371Ryc372Pyc373Pyc374Uyc375Ryc376Pyc377Uyc378^yc379Ryc380Ryc381Zyc382[yc383^yc384\yc385Zyc386Xyc387\yc388Tyc389[yc390Syc391_yc392Pyc393ayc394\yc395Pyc396Ryc397Pyc398[yc399Zyc400[yc401Zyc402X>vgsummary<ya1fya2iya3dya4fya5aya6fya7gya8aya9dyb10_yb11\yb12hyb13lyb14dyb15fyb16ayb17Xyb18eyb19^yb20`yb21dyb22eyb23eyb24wyb25lyb26cyb27fyb28hyb29yyb30gyb31byb32byb33_yb34ayb35eyb36byb37lyb38dyb39dyb40fyb41^yb42dyb43jyb44tyb45eyb46cyb47fyb48oyb49`yb50hyb51eyb52fyb53jyb54lyb55nyb56fyb57kyb58hyb59Hyb60dyb61eyb62eyb63eyb64Hyb65Hyb66`yb67byb68cyb69Hyb70kyb71gyb72xyb73_yb74[yb75ayb76Yyb77Dyb78hyb79`yb80zyb81]yb82uyb83hyb84pyb85eyb86oyb87iyb88gyb89\yb90kyb91qyb92byb93iyb94hyb95gyb96nyb97gyb98cyb99cyc100dyc101dyc102eyc103kyc104gyc105eyc106ayc107myc108iyc109qyc110syc111`yc112\yc113eyc114]yc115nyc116myc117pyc118syc119lyc120gyc121eyc122`yc123iyc124pyc125fyc126iyc127pyc128gyc129gyc130pyc131jyc132ryc133Xyc134iyc135gyc136lyc137Byc138ryc139hyc140lyc141Yyc142Yyc143nyc144[yc145qyc146byc147kyc148Yyc149zyc150qyc151pyc152yc153tyc154myc155pyc156iyc157pyc158syc159Yyc160uyc161uyc162`yc163jyc164vyc165kyc166ayc167ryc168myc169Zyc170oyc171lyc172myc173Zyc174myc175dyc176myc177eyc178syc179_yc180pyc181qyc182byc183Zyc184lyc185syc186fyc187lyc188byc189nyc190syc191dyc192kyc193uyc194tyc195byc196syc197_yc198]yc199Zyc200qyc201gyc202`yc203oyc204Zyc205_yc206Wyc207jyc208Yyc209byc210lyc211\yc212jyc213nyc214syc215gyc216[yc217\yc218hyc219jyc220wyc221cyc222cyc223ayc224`yc225pyc226fyc227fyc228cyc229gyc230hyc231Wyc232Xyc233byc234dyc235[yc236byc237_yc238gyc239Yyc240]yc241lyc242eyc243gyc244`yc245jyc246jyc247byc248fyc249tyc250lyc251cyc252cyc253hyc254Tyc255cyc256^yc257[yc258_yc259cyc260gyc261dyc262byc263eyc264eyc265jyc266hyc267kyc268kyc269iyc270oyc271ayc272fyc273^yc274kyc275dyc276fyc277dyc278eyc279dyc280fyc281Zyc282nyc283lyc284jyc285hyc286\yc287jyc288byc289hyc290pyc291myc292_yc293dyc294_yc295lyc296nyc297fyc298kyc299hyc300fyc301pyc302]yc303fyc304dyc305jyc306byc307jyc308ryc309Eyc310dyc311pyc312cyc313iyc314nyc315byc316ayc317fyc318cyc319nyc320fyc321gyc322nyc323fyc324dyc325eyc326_yc327lyc328jyc329byc330eyc331vyc332eyc333gyc334cyc335cyc336eyc337fyc338myc339oyc340eyc341hyc342nyc343dyc344lyc345oyc346nyc347Ayc348tyc349lyc350ayc351fyc352nyc353fyc354cyc355kyc356ayc357lyc358lyc359hyc360oyc361lyc362fyc363pyc364dyc365_yc366gyc367jyc368fyc369lyc370hyc371dyc372tyc373lyc374vyc375nyc376nyc377lyc378qyc379kyc380iyc381ayc382gyc383eyc384`yc385fyc386oyc387hyc388fyc389gyc390lyc391dyc392lyc393byc394fyc395Yyc396byc397_yc398Wyc399fyc400ayc401^yc402p>vdtags<ya1Rya2Qya3Qya4Qya5Qya6Sya7Sya8Qya9Syb10Syb11Qyb12Syb13Ryb14Qyb15Qyb16Qyb17Qyb18Qyb19Qyb20Qyb21Syb22Qyb23Syb24Qyb25Ryb26Qyb27Qyb28Qyb29Qyb30Qyb31Syb32Syb33Qyb34Qyb35Qyb36Qyb37Qyb38Syb39Syb40Qyb41Qyb42Qyb43Ryb44Qyb45Qyb46Qyb47Qyb48Qyb49Qyb50Qyb51Qyb52Qyb53Qyb54Ryb55Ryb56Syb57Qyb58Qyb59Uyb60Syb61Qyb62Qyb63Qyb64Uyb65Uyb66Ryb67Syb68Syb69Uyb70Ryb71Ryb72Ryb73Syb74Syb75Qyb76Qyb77Uyb78Ryb79Ryb80Uyb81Qyb82Uyb83Qyb84Uyb85Uyb86Uyb87Uyb88Qyb89Qyb90Qyb91Ryb92Qyb93Syb94Syb95Qyb96Qyb97Qyb98Qyb99Qyc100Qyc101Qyc102Qyc103Ryc104Qyc105Qyc106Qyc107Qyc108Qyc109Qyc110Qyc111Qyc112Qyc113Qyc114Qyc115Qyc116Ryc117Qyc118Qyc119Qyc120Qyc121Qyc122Qyc123Qyc124Ryc125Ryc126Ryc127Ryc128Qyc129Qyc130Ryc131Qyc132Qyc134Qyc135Qyc136Ryc137Qyc138Qyc139Qyc140Qyc141Qyc142Qyc143Qyc144Qyc145Ryc146Qyc147Qyc148Qyc149Qyc150Qyc151Qyc152Qyc153Qyc154Qyc155Qyc156Qyc157Qyc158Qyc159Qyc160Qyc161Qyc162Qyc163Qyc164Qyc165Syc166Qyc167Qyc168Qyc169Qyc170Qyc172Qyc173Qyc174Qyc175Qyc176Qyc177Qyc178Qyc179Qyc180Ryc181Qyc182Qyc183Qyc184Qyc185Qyc186Qyc187Ryc188Qyc189Qyc190Qyc191Qyc192Qyc193Qyc194Qyc195Qyc196Qyc197Qyc198Qyc199Qyc200Qyc201Qyc202Qyc203Qyc204Qyc205Qyc206Qyc207Qyc208Qyc209Qyc210Qyc211Qyc212Qyc213Qyc214Qyc215Qyc216Qyc217Qyc218Qyc219Qyc220Qyc221Qyc222Syc223Qyc224Qyc225Qyc226Qyc227Qyc228Qyc229Qyc230Qyc231Qyc232Qyc233Qyc234Qyc235Qyc236Qyc237Qyc238Syc239Qyc240Qyc241Ryc242Qyc243Qyc244Qyc245Qyc246Qyc247Qyc248Qyc249Qyc250Qyc251Qyc252Qyc253Qyc254Qyc255Qyc256Qyc257Qyc258Qyc259Qyc260Syc261Qyc262Qyc263Qyc264Qyc265Qyc266Qyc267Qyc268Qyc269Qyc270Qyc271Qyc272Qyc273Qyc274Qyc275Syc276Syc277Qyc278Qyc279Qyc280Syc281Qyc282Qyc283Qyc284Qyc285Qyc286Qyc287Qyc288Qyc289Qyc290Qyc291Qyc292Qyc293Qyc294Qyc295Qyc296Qyc297Qyc298Qyc299Qyc300Qyc301Syc302Qyc303Qyc304Qyc305Qyc306Qyc307Qyc308Qyc309Qyc310Syc311Qyc313Syc314Qyc315Qyc316Qyc317Qyc318Syc319Syc320Syc321Qyc322Qyc323Qyc324Syc325Qyc326Qyc327Qyc328Qyc329Qyc330Qyc331Qyc332Syc333Syc334Syc335Qyc336Qyc337Qyc338Qyc339Qyc340Qyc341Qyc342Qyc343Syc344Qyc345Qyc346Qyc347Qyc348Qyc349Qyc350Syc351Qyc352Qyc353Qyc354Syc355Qyc357Qyc358Qyc359Qyc360Syc361Qyc362Qyc363Qyc364Qyc365Syc366Syc367Qyc368Syc370Qyc371Qyc372Qyc373Qyc374Qyc375Qyc376Qyc377Qyc378Qyc379Qyc380Qyc381Qyc382Syc383Syc384Syc385Qyc386Qyc387Qyc388Qyc389Qyc390Syc391Syc392Qyc393Qyc394Syc395Syc396Syc397Syc398Syc399Syc400Syc401Syc402Q>vddocs2vddocs<va1:yddate%$4Axcdirjpost/2023/xbid `d869fb48cb9acba03dc639481524ee80xdlangbjayglastmod%$4Axipermalink vhttps://blog.johtani.info/blog/2023/12/31/review-2023/xkpublishdate T2023-12-31T07:49:21Zxgsummary!H今年も振り返りブログをリビングで書いています（ドミノ倒しすごいな）。 FMVのキーボードで書いているのでタイポがつらい。。。 振り返り（2022wdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2023）va2:yddate%1!pxcdirjpost/2023/xbid `476e17b6f854414033d5cec1470774eexdlangbjayglastmod%1!pxipermalink!Bhttps://blog.johtani.info/blog/2023/12/15/introduce-orama-to-blog/xkpublishdate Y2023-12-15T00:00:00+09:00xgsummary!Xこの記事は、情報検索・検索技術 Advent Calendar 2023の15日目の記事です。 昨年に続き2回目の情報検索のAdvent Calendar参戦です。 今年は、夏wdtags2xpeoramafsearchxetitle ZOramaという検索エンジンでブログ検索を作ってみたva3:yddate%7pxcdirjpost/2023/xbid `516a7aa07f8faa6b7aa38beb5010cf8cxdlangbjayglastmod%7pxipermalink xhttps://blog.johtani.info/blog/2023/12/08/smarthome-bot/xkpublishdate Y2023-12-08T00:00:00+09:00xgsummary!GPySpaアドベントカレンダーの12/08のエントリーです。昨日は渋川さんのアンラーニングで失敗した話でした。 私は、今年は昨年の続きっぽい話wdtags3xpdmiscemusiccbotxetitle QGoでSlackのボットを作った話va4:yddate%=Hxcdirjpost/2023/xbid `7f78b02c531f09602ba4e140132d26a2xdlangbjayglastmod%=Hxipermalink!Chttps://blog.johtani.info/blog/2023/09/25/read-search-raking-guide/xkpublishdate T2023-09-25T03:32:24Zxgsummary!H「機械学習による検索ランキング改善ガイド」を読みました。 著者の鈴木さんより献本いただいたのを読み終わったのでレビューと、あとおまけです。 紹介wdtags2xpb読書melasticsearchxetitle Y機械学習による検索ランキング改善ガイドを読みましたva5:yddate$9'|xcdirjpost/2023/xbid `8f58cbe5f2ce85c22569af765de3f8d3xdlangbjayglastmod$9'|xipermalink!Bhttps://blog.johtani.info/blog/2023/08/23/search-ui-and-searchkit/xkpublishdate T2023-08-23T05:32:44Zxgsummary!H趣味？（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書いています。 ベクトル検索などの確認なども含めて、Jupyter Nwdtags3xpisearchkitisearch-uib画面xetitle Xsearch-UIとSearchkitと検索画面va6:yddate$0ixcdirjpost/2023/xbid `f9e847ee886bdb9ab5583eeb6eabbd51xdlangbjayglastmod$0ixipermalink!Ihttps://blog.johtani.info/blog/2023/07/27/container-name-in-devcontainer/xkpublishdate T2023-07-27T01:22:49Zxgsummary!Gいくつかある環境をDev Containerで動くように変えていますが、最初に導入した時に疑問点だった「コンテナ名」について解消したのでメモをwdtags1xpmdev containerxetitle _VS CodeとDev Container(コンテナ名の指定)va7:yddate$/$Hxcdirjpost/2023/xbid `7884b62c561b999b9358d52779a18218xdlangbjayglastmod$/$Hxipermalink!Nhttps://blog.johtani.info/blog/2023/07/24/introduce-dev-container-to-hugo-env/xkpublishdate T2023-07-24T09:10:32Zxgsummary!Hこのブログの生成には、Hugoを利用しています。 ブログ移行日記（その1）に書いてありますが、当時はbrewでインストールしていました。 また、wdtags2xpdhugomdev containerxetitle Xブログ記述環境としてのDev Containerva8:yddate$/!(`xcdirjpost/2023/xbid `ed431877ce11fe403fee77f7d26ce637xdlangbjayglastmod$/!(`xipermalink!Lhttps://blog.johtani.info/blog/2023/07/24/move-distribution-to-another-disk/xkpublishdate T2023-07-24T06:28:48Zxgsummary!HWSL2にUbuntuを入れて、開発とかはこちらを利用しています。 また、Docker DesktopもWSL2のバックエンドエンジンを利用してwdtags2xpcwslgwindowsxetitle UWSL2のディストリビューションの環境移行va9:yddate$..zxcdirjpost/2023/xbid `086b4fd5f77021a0a2aa6b0e90061486xdlangbjayglastmod$..zxipermalink!Nhttps://blog.johtani.info/blog/2023/07/21/multi-containers-with-dev-container/xkpublishdate Y2023-07-21T10:13:30+09:00xgsummary!J前回の記事で、VS Code＋Dev Containerを導入しました。 残課題として「マルチコンテナ化」があるという話もしました。今回はDev Cwdtags2xpfpythonmdev containerxetitle kVS CodeとDev Container（docker-compose.yml対応）vb10:yddate$+?#kxcdirjpost/2023/xbid `a12474027c91fad5a861aa9919817d72xdlangbjayglastmod$+?#kxipermalink!Nhttps://blog.johtani.info/blog/2023/07/13/introduce-vs-code-and-dev-container/xkpublishdate Y2023-07-13T22:15:23+09:00xgsummary!G前回の記事で、pre-commitとPyCharmとWindowsの組み合わせで困っていることを書きました。 これについて、知り合いとチャットwdtags2xpfpythonmdev containerxetitle ^VS CodeとDev Containerの導入（まだ途中）vb11:yddate$*6dxcdirjpost/2023/xbid `698cf3cbd796161d82c9ac438ebab5d2xdlangbjayglastmod$*6dxipermalink!@https://blog.johtani.info/blog/2023/07/10/pre-commit-and-python/xkpublishdate Y2023-07-10T10:55:48+09:00xgsummary!G最近、趣味（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書き始めました。 きちんとPythonのプログラムをプロジェクトwdtags1xpfpythonxetitle ^pre-commitとvenvとPyCharm（困ったな？）vb12:yddate$$uxcdirjpost/2023/xbid `9335522f4c8dbc7256a42a091e6e00bcxdlangbjayglastmod$$uxipermalink!Ghttps://blog.johtani.info/blog/2023/06/21/attend-berlin-buzzwords-2023/xkpublishdate Y2023-06-21T01:30:45+09:00xgsummary!N今年もこの季節がやってきました。 Berlin Buzzwordsにオンラインで出張してました。 今年もハイブリッド開催をしてくれたので、オンラインで参加でwdtags2xpjconferenceobelin buzzwordsxetitle ^今年もオンラインでBerlin Buzzwordsに参加したvb13:yddate#,
<\xcdirjpost/2022/xbid `df30d810068e4656498e5972c6de7e3dxdlangbjayglastmod#,
<\xipermalink vhttps://blog.johtani.info/blog/2022/12/31/review-2022/xkpublishdate Y2022-12-31T20:38:04+09:00xgsummary!H今年もなんとか振り返りブログを書いてます（時間大丈夫かな？w）。紅白をリアタイで見ながら。 振り返り（2021年に書いた抱負から） まずは振り返wdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2022）vb14:yddate#&Vxcdirjpost/2022/xbid `67c2ae6761e89be0fa66db9623b40d30xdlangbjayglastmod#&Vxipermalink!Chttps://blog.johtani.info/blog/2022/12/15/music-server-on-mac-mini/xkpublishdate Y2022-12-15T00:05:58+09:00xgsummary!HPySpaアドベントカレンダーの12/15のエントリーです。昨日はtaichiさんでした。 今年はDIYではなく、PCにまつわる話を。 仕事中はwdtags2xpdmiscemusicxetitlei仕事中のBGM環境vb15:yddate#$ 6]xcdirjpost/2022/xbid `9693a1e77dee5785b1dc61ccffd2e906xdlangbjayglastmod#$ 6]xipermalink!Ahttps://blog.johtani.info/blog/2022/12/09/open-search-serverless/xkpublishdate Y2022-12-09T01:15:25+09:00xgsummary!V本記事は情報検索・検索技術 Advent Calendar 2022の9日目の記事です。 だいぶ間が空いてしまいましたが、日本語のオートコンプリートに関する記事の続きです。wdtags2xpmelasticsearchjopensearchxetitle lElasticsearchのアーキテクチャとStateless / Serverlessvb16:yddate"<13Zxcdirjpost/2022/xbid `73279888a8fe482c836fb19ca23318dcxdlangbjayglastmod"<13Zxipermalink https://blog.johtani.info/blog/2022/08/10/jp-auto-completion-2/xkpublishdate Y2022-08-10T11:50:02+09:00xgsummary!G前回は日本語用オートコンプリートのためのAnalyzerとして、どうやって使うのかを簡単に紹介しました。 今回はもう少し、いろんなパターンを試wdtags2xpmelasticsearchflucenexetitle kローマ字入力のゆれと読み（JapaneseCompletionAnalyzerその2）vb17:yddate"< rxcdirjpost/2022/xbid `6639ec6f88c4976f8ca20fa840f169e3xdlangbjayglastmod"< rxipermalink!Chttps://blog.johtani.info/blog/2022/08/09/japanese-auto-completion/xkpublishdate Y2022-08-09T16:00:02+09:00xgsummary!F風のうわさで、日本語用のオートコンプリートのためのTokenFilterとAnalyzerがLuceneに取り込まれたと聞きました（LUCEwdtags2xpflucenemelasticsearchxetitle Y日本語用オートコンプリートのためのAnalyzervb18:yddate";
/bxcdirjpost/2022/xbid `167a7c9d579ce6f2cebf64a6f6329ecbxdlangbjayglastmod";
/bxipermalink!Dhttps://blog.johtani.info/blog/2022/08/05/upgrade-hugo-accidentally/xkpublishdate Y2022-08-05T17:59:14+09:00xgsummary!FHugoを0.84から0.92にアップデートをする際に、これまでのブログ記事やレイアウトファイルを修正したので個人的にメモを残しておきます。wdtags1xpdhugoxetitlemHugoをアップデートしたvb19:yddate"5:#jxcdirjpost/2022/xbid `3384ea6bb47d70f8ca94b4510813f36axdlangbjayglastmod"5:#jxipermalink ~https://blog.johtani.info/blog/2022/07/20/querqy-architecture/xkpublishdate Y2022-07-20T16:04:10+09:00xgsummary!G今回はQuerqyのElasticsearchのプラグインがどんなつくりになっているか？をちょっとだけ調べてみました。 SolrでもElastwdtags1xpmelasticsearchxetitle VQuerqyの調査（その2：アーキテクチャ）vb20:yddate"567{xcdirjpost/2022/xbid `779e444b4bc720a9eed97f19c41e8773xdlangbjayglastmod"567{xipermalink whttps://blog.johtani.info/blog/2022/07/20/intro-querqy/xkpublishdate Y2022-07-20T11:52:43+09:00xgsummary!FQuerqyというクエリのリライト用のプラグインがあるのでどんなものかを調べてみました。とりあえずは概要をドキュメントから追いかけてみた感じwdtags1xpmelasticsearchxetitlenQuerqyの調査（その１）vb21:yddate"*>_xcdirjpost/2022/xbid `f56c19442484b3e4f47875b58b3f72b2xdlangbjayglastmod"*>_xipermalink!Hhttps://blog.johtani.info/blog/2022/06/15/ttend-berlin-buzzwords-online/xkpublishdate Y2022-06-15T18:00:15+09:00xgsummary!H今年もBerlin Buzzwordsにオンライン出張してました。 今年はハイブリッドな開催だったようで、現地で再開している人もいるようでした。wdtags2xpjconference Pberlin buzzwordsxetitle ^今年もオンラインでBerlin Buzzwordsに参加したvb22:yddate")19Vxcdirjpost/2022/xbid `5eebdf85fd1726db301194bfeeee4377xdlangbjayglastmod")19Vxipermalink!Hhttps://blog.johtani.info/blog/2022/06/13/new-elasticsearch-java-client/xkpublishdate Y2022-06-13T20:24:06+09:00xgsummary!G7.16で正式リリースされましたが、Elasticsearchの新しいJavaのクライアントが出ています。 使ってみたので、ちょっとだけ紹介でwdtags2xpmelasticsearchdjavaxetitle [Elasticsearchの新しいJavaクライアントvb23:yddate"!	 Yxcdirjpost/2022/xbid `7cc21814165879f72529e91682ece5c6xdlangbjayglastmod"!	 Yxipermalink!Phttps://blog.johtani.info/blog/2022/05/18/index-alias-in-azure-cognitive-search/xkpublishdate Y2022-05-18T15:54:17+09:00xgsummary!VAzure Cognitive Searchで2月に新しい機能が公開されました。 「Index Alias」（インデックスの別名）です。まだ、パブリックプレビューの段階ですwdtags1xplazure searchxetitle hインデックスエイリアス - Azure Cognitive Searchの新機能vb24:yddate!7*nxcdirjpost/2022/xbid `0645bdb1cdf88ec74288d503eb71839cxdlangbjayglastmod!7*nxipermalink!Rhttps://blog.johtani.info/blog/2022/01/12/reading-xmc-for-semantic-search-in-prod/xkpublishdate Y2022-01-12T18:41:02+09:00xgsummary"D年末までに知り合いと次の論文を読んだので軽くまとめておきます。 Extreme Multi-label Learning for Semantic Matching in Product Search なんで読んだの？ 前回読んだ理由と一緒ですが、Semanticwdtags2xpfsearchepaperxetitle!MExtreme Multi-label Learning for Semantic Matching in Product Searchという論文を読んだvb25:yddate!30oxcdirjpost/2021/xbid `104b8ee17a8bf1f7043d236659680493xdlangbjayglastmod!30oxipermalink |https://blog.johtani.info/blog/2021/12/31/looking-back-2021/xkpublishdate Y2021-12-31T22:29:19+09:00xgsummary!H今年も振り返りブログです。録画した紅白をオッかけ再生して気になるアーティストだけ見ながら書ています。 振り返り（2020年に書いた抱負から） まwdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2021）vb26:yddate!3	xxcdirjpost/2021/xbid `218e2c36d5945ece02fdc55d6cbcbc38xdlangbjayglastmod!3	xxipermalink xhttps://blog.johtani.info/blog/2021/12/29/best-buy-2021/xkpublishdate Y2021-12-29T22:28:24+09:00xgsummary!G2021年もあと少しですが、今年買って良かったものをリストアップしておこうかと思います。 今年買ったといいながら、昨年このネタを書くといいつつwdtags1xpdmiscxetitlen2021年かって良かったものvb27:yddate!0)
gxcdirjpost/2021/xbid `f0fdc140e18514362a4e52376a6fecbaxdlangbjayglastmod!0)
gxipermalink!Ghttps://blog.johtani.info/blog/2021/12/22/azure-search-schema-json2csv/xkpublishdate Y2021-12-22T11:54:31+09:00xgsummary!UAzure Cognitive Searchのスキーマの確認をするときに、Azureのポータルでは次のようにフィールドの一覧として見ることができます。 ただ、実際のインデwdtags2xplazure searchdmiscxetitle rAzure Cognitive SearchのIndex Schema JSONをCSVで見たくなるvb28:yddate!+7pxcdirjpost/2021/xbid `26e44dfd16a2963d4c18e99806c26fd7xdlangbjayglastmod!+7pxipermalink zhttps://blog.johtani.info/blog/2021/12/08/controller-rack/xkpublishdate Y2021-12-08T00:00:00+09:00xgsummary!W今年もアドベントカレンダーの季節になってしまいました。 今年で2回目となる、pyspa Advent Calendar 2021の投稿です。 昨年に引き続きDIYがらみの投稿wdtags2xphDIYキーボードdmiscxetitle V今年のDIYキーボードとコントローラーラックvb29:yddate!"5&\xcdirjpost/2021/xbid `35200cbf0b5b45d7f5f0b343cb18868bxdlangbjayglastmod!"5&\xipermalink!Mhttps://blog.johtani.info/blog/2021/11/10/reading-ms-biomedical-search-paper/xkpublishdate Y2021-11-10T14:33:16+09:00xgsummary"WDomain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだので軽くメモを残しておきます。論文自体はリンクから参照してください。 読んだ理由 Azure Cognitive Swdtags2xpfsearchepaperxetitle!]Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだvb30:yddate ;/gxcdirjpost/2021/xbid `10a7f69bd03d2632722300194f01e93dxdlangbjayglastmod ;/gxipermalink |https://blog.johtani.info/blog/2021/07/13/attend-mices-2021/xkpublishdate Y2021-07-13T16:08:23+09:00xgsummary!I今年もMICESにも参加してました。 昨年はBerlin Buzzwordsと共同開催でしたが、今年は別開催（別日程）でした。 MICESは201wdtags3xpjconference Pberlin buzzwordseMICESxetitle S今年もMICESにオンライン出張してたvb31:yddate 9?'Excdirjpost/2021/xbid `59b7b60e6bbf4858d72643d22ad90451xdlangbjayglastmod 9?'Exipermalink!Bhttps://blog.johtani.info/blog/2021/07/09/berlin-buzzwords-2021-1/xkpublishdate Y2021-07-09T16:24:53+09:00xgsummary!I今年もBerlin Buzzwordsにオンライン出張してました。 今年の開催は6月14日から17日まででした。 どんなカンファレンスなのかは昨年wdtags2xpjconference Pberlin buzzwordsxetitle ^今年もBerlin Buzzwordsにオンライン出張してたvb32:yddate 7Wxcdirjpost/2021/xbid `43caef5d41c4e74826e4a8d82088739dxdlangbjayglastmod 7Wxipermalink!Thttps://blog.johtani.info/blog/2021/07/01/semantic-search-in-azure-cognitive-search/xkpublishdate Y2021-07-01T18:09:43+09:00xgsummary!WAzure Cognitive Searchで新機能「Semantic Search（セマンティック検索）」という機能の日本語対応が発表されました。 実際にはPublic Pwdtags1xplazure searchxetitle pAzure Cognitive Searchの新機能、Semantic Searchを試してみたvb33:yddate "-Txcdirjpost/2021/xbid `f4baa43cc7ca712d83b99a794c4e2dbdxdlangbjayglastmod "-Txipermalink!Ahttps://blog.johtani.info/blog/2021/04/30/build-lunakey-mini-ble/xkpublishdate Y2021-04-30T00:26:12+09:00xgsummary!MSofle v2を長らく使っていましたが、コンパクトなのもやっぱりいいよなぁというときにKochi KeyboardからLunakey Miniが発売してwdtags2xphDIYキーボードdmiscxetitle mLunakey Miniを組み立てて、BLE+LPME-IO化してみた #DIYキーボードvb34:yddate -0gxcdirjpost/2021/xbid `f41d4fde94cbd7bbd28808dc080a2019xdlangbjayglastmod -0gxipermalink uhttps://blog.johtani.info/blog/2021/04/05/intro-marp/xkpublishdate Y2021-04-05T18:45:11+09:00xgsummary!Iみなさんは、スライドの作成には何を使っていますか？ Keynote？Powerpoint？Google Slides？ 私は、Macでスライドを作wdtags1xpc勉強会xetitle Sスライド作成の環境をMarpにしてみたvb35:yddate ~xcdirjpost/2021/xbid `ce426b7f3190c8a4a47d45ac799e91a4xdlangbjayglastmod ~xipermalink https://blog.johtani.info/blog/2021/03/31/search-tech-jp-slack/xkpublishdate Y2021-03-31T23:28:14+09:00xgsummary!H新型コロナウィルスの影響もあり、オフラインで集まって勉強会も開催できなくなっています。 検索技術勉強会も、もう1年以上開催できていないです。 スwdtags1xpc勉強会xetitle ^検索技術に関する情報交換を目的としたSlackができました！vb36:yddate 3%uxcdirjpost/2021/xbid `eced95e5f301a8340e83d81d3c0d5c0dxdlangbjayglastmod 3%uxipermalink!Chttps://blog.johtani.info/blog/2021/03/03/phrase-query-in-japanese/xkpublishdate Y2021-03-03T16:23:33+09:00xgsummary!UAzure Cognitive SearchにはOData式という書式で条件が書ける仕組みがあります。 ODataは検索条件（$filter）やソート条件（$orderbwdtags2xplazure searchmelasticsearchxetitle [OData式と日本語の検索(NGram)とフレーズ検索vb37:yddate 
7fxcdirjpost/2021/xbid `fcb0105fa6b5777a133f247784b9d930xdlangbjayglastmod 
7fxipermalink!Bhttps://blog.johtani.info/blog/2021/02/25/update-working-facility/xkpublishdate Y2021-02-25T18:43:02+09:00xgsummary!G自宅の環境がいろいろと変わったのですが、書いていなかったので更新版です。 前回のブログ(2020/09)、前々回のブログ(2020/03)はそwdtags1xpdmiscxetitle P自宅の作業環境(2021/02)vb38:yddate pxcdirjpost/2021/xbid `931b2ebd9bfaeb5dcf1973e724a1f8d0xdlangbjayglastmod pxipermalink!Shttps://blog.johtani.info/blog/2021/02/05/autocomplete-and-suggest-on-azure-search/xkpublishdate Y2021-02-05T17:52:00+09:00xgsummary!UAzure Cognitive SearchにSuggestやAutocompleteの機能があるのを見つけたので、どんな挙動なのかを調べてログとして残しておきます。 公wdtags1xplazure searchxetitle kAzure Cognitive Searchでオートコンプリートやサジェストをしてみるvb39:yddate :|xcdirjpost/2021/xbid `aa61b4543e8a7c67fccabee27a6e99cdxdlangbjayglastmod :|xipermalink!Phttps://blog.johtani.info/blog/2021/02/04/reading-elements-of-computing-systems/xkpublishdate Y2021-02-04T16:40:44+09:00xgsummary!Gオライリー・ジャパンから出ている「コンピュータシステムの理論と実装」を読み始めたのでメモを取ることに。 原著はオライリーじゃないのかというのがwdtags2xpb輪読kNand2Tetrisxetitle e「コンピュータシステムの理論と実装」を読み始めた #Nand2Tetrisvb40:yddate ,&Jxcdirjpost/2021/xbid `d95522c691013bfe66dd46ded85a98edxdlangbjayglastmod ,&Jxipermalink }https://blog.johtani.info/blog/2021/02/01/apply-ble-to-sofle/xkpublishdate Y2021-02-01T00:15:22+09:00xgsummary!QCorne使ってましたが、数字キーがあるとどうなのかな？というのがやはり気になって。 そこに、Kochi KeyboardさんからSofle Keyboard vwdtags2xphDIYキーボードdmiscxetitle iSofle v2を組み立てて、BLE+LPME-IO化してみた #DIYキーボードvb41:yddate>;,Wxcdirjpost/2021/xbid `4ad8239a37f641bcd17abeb96106314exdlangbjayglastmod>;,Wxipermalink!Fhttps://blog.johtani.info/blog/2021/01/11/apply-ble-and-lpme-to-corne/xkpublishdate Y2021-01-11T11:42:31+09:00xgsummary!FメインマシンとMacは下記のサンワサプライのUSB接続のKVMスイッチを使っていますが、もう一台ノートPCがありここに接続しているCornewdtags2xphDIYキーボードdmiscxetitle fCorne Light v2のBLE+LPME-IO対応 #DIYキーボードvb42:yddate;~xcdirjpost/2020/xbid `64a421c2367372c3199c66a6420faf89xdlangbjayglastmod;~xipermalink qhttps://blog.johtani.info/blog/2020/12/31/diy-pc/xkpublishdate Y2020-12-31T22:48:46+09:00xgsummary!H振り返りブログにも書きましたが、デスクトップPCを自作(DIY)しました。 組み立てたに使ったパーツのアフィリンクを貼っておきます。 10月くらwdtags1xpdmiscxetitlejPCもDIYしましたvb43:yddate;txcdirjpost/2020/xbid `a5b2ee641e10d3e4db8f888217ab9eccxdlangbjayglastmod;txipermalink |https://blog.johtani.info/blog/2020/12/31/looking-back-2020/xkpublishdate Y2020-12-31T18:13:24+09:00xgsummary!H今年も振り返りブログ書いてます。カタンの航海者版を購入して家族とやってましたが、負けてしまいました。 振り返り（2019年に書いた抱負から） まwdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2020）vb44:yddate67{xcdirjpost/2020/xbid `c6fc88bd57a0e57ddf22e2eb1bef892cxdlangbjayglastmod67{xipermalink |https://blog.johtani.info/blog/2020/12/17/index_template_v2/xkpublishdate Y2020-12-17T23:55:55+09:00xgsummary!~Elastic stack (Elasticsearch) Advent Calendar 2020の18日目の記事になります。 本日の勉強会でLTをしましたが、しゃべり足りなかったんで。 Elasticsearch 7.8でこっそりとリリースされたIwdtags1xpmelasticsearchxetitle QIndex Template V2vb45:yddate2
+5v WinternalDocumentIDStore1wninternalIdToId<xp `c4dba56f2db4851cd31b561d92dc5e35 `d869fb48cb9acba03dc639481524ee80 `476e17b6f854414033d5cec1470774ee `516a7aa07f8faa6b7aa38beb5010cf8c `7f78b02c531f09602ba4e140132d26a2 `8f58cbe5f2ce85c22569af765de3f8d3 `f9e847ee886bdb9ab5583eeb6eabbd51 `7884b62c561b999b9358d52779a18218 `ed431877ce11fe403fee77f7d26ce637 `086b4fd5f77021a0a2aa6b0e90061486 `a12474027c91fad5a861aa9919817d72 `698cf3cbd796161d82c9ac438ebab5d2 `9335522f4c8dbc7256a42a091e6e00bc `df30d810068e4656498e5972c6de7e3d `67c2ae6761e89be0fa66db9623b40d30 `9693a1e77dee5785b1dc61ccffd2e906 `73279888a8fe482c836fb19ca23318dc `6639ec6f88c4976f8ca20fa840f169e3 `167a7c9d579ce6f2cebf64a6f6329ecb `3384ea6bb47d70f8ca94b4510813f36a `779e444b4bc720a9eed97f19c41e8773 `f56c19442484b3e4f47875b58b3f72b2 `5eebdf85fd1726db301194bfeeee4377 `7cc21814165879f72529e91682ece5c6 `0645bdb1cdf88ec74288d503eb71839c `104b8ee17a8bf1f7043d236659680493 `218e2c36d5945ece02fdc55d6cbcbc38 `f0fdc140e18514362a4e52376a6fecba `26e44dfd16a2963d4c18e99806c26fd7 `35200cbf0b5b45d7f5f0b343cb18868b `10a7f69bd03d2632722300194f01e93d `59b7b60e6bbf4858d72643d22ad90451 `43caef5d41c4e74826e4a8d82088739d `f4baa43cc7ca712d83b99a794c4e2dbd `f41d4fde94cbd7bbd28808dc080a2019 `ce426b7f3190c8a4a47d45ac799e91a4 `eced95e5f301a8340e83d81d3c0d5c0d `fcb0105fa6b5777a133f247784b9d930 `931b2ebd9bfaeb5dcf1973e724a1f8d0 `aa61b4543e8a7c67fccabee27a6e99cd `d95522c691013bfe66dd46ded85a98ed `4ad8239a37f641bcd17abeb96106314e `64a421c2367372c3199c66a6420faf89 `a5b2ee641e10d3e4db8f888217ab9ecc `c6fc88bd57a0e57ddf22e2eb1bef892c `a46c601d03a3a26bc418d0096fe83a42 `b16bddd1a6d3e5f4136446bebe7ffbc7 `188c1ee5132a6752dfce5a0235354070 `de37d9fae011687eb1eb5a127fcb89e3 `c377351433a941a927aab543931f6026 `15932a656f7acfac897d27766eadc9e2 `b2c4cf0fb96d02d37f03668caaecbc57 `d08a3fdc040bbbdd81c9927ce296318c `827de2d7a9d231f6bcb44caf35896c1f `3c5d4d351e0fb9e33e0e8b6d1d43c0f2 `eb2a5824e03996c1966bee38866ce349 `f5effd616a3f8db6193b482caec37912 `11a61827e80739a6065960eb188d5758 `9da845cd31310b8952efd1be1881e651 `208a8c072ea521c813b86ca7730eb880 `e5cb2e5d501d3db2db5d8f14984a66d4 `bbd2824ff0d5b801bb6f5da3a2a1a888 `8a1ea5d5cf843bc5955a94cfcc321e92 `82a115ab8d617e4e96813587fe3a6049 `e74d071363645a588f858b35231128c4 `163beeae9620c1a6a46a38aa7ebd9663 `36dd94159e3e60076c0c6098086e255f `21982f43bc435f22efef22b309a48c66 `306cecb32320ead508346ad8fed3394d `1e220a934e16fd941bd804ca03865b60 `09155bf417a93847b538ad607f78cca2 `c098c6f0901979bd914ed7a345200f90 `2c3270f8797ace2fb37402ea6a09d126 `44db1f1fefc97cd28d55d443f2bd2b63 `4d71d2a23c85fb7af20e8d1e8b3e0de8 `be2c49ea5816e7daa6d3b3ff45353291 `15357b6978e83daa2d97692c861dc177 `f488aa62d39194824861a134567cadb8 `9a687babb0f44db51dc389b75bdaa19d `dc9580308938069159c5afc55b2f3b96 `4fbdc9c57a37781dc5dd86f470c61d04 `6fbf7c3d0f4f89e415e89cec28811a94 `8d9c3760395e8e0eb40e335b22750b68 `3f431bf71ee866f626daf42bc915fa3f `7fded0345c258eea966c0b5ee1b7c7aa `a7f0e85fcad4f5bc5ae5c18c10de4f9e `48b5ab9805919736382ffea5a9554c02 `c9d257aba54475c20b3737ce7c779e55 `6f47cb314fd780c122adb8cc1f44f785 `d710a073be2da219a388a150eb7b6b6a `71cf83ae0f45e9ede3a3f979b9c74933 `daa3fe935b0be9f31b6b362ad9e0d2d6 `ef8a399c9679ce4e9710c7c6ecf8bcc7 `c3053579ae25e2fb9b967076a06373af `7b080dc43fce482af14de61c6ab819a5 `90f9355781403b92e844de8568863ae8 `7fcfaa8dd34dbd508f19e8ca0fcfda0f `c61a5bda3f1667498626ae52ad0362e0 `d9018f459d3c94a91e92b459e152f7e7 `99c9c80a6532e4ea3b535c5a92d07a25 `018b365b00dd3a6ad17c813d21590549 `a65bd31d4c3dab0a41712823a5d6002b `3c299a4d77be8b4f886ce9fcd23a2561 `35aa9e09db936aee7ec407c431816573 `1a1a8cc0040b356d06eacd22e0526476 `80c8fca02ebfecc7a931dad1ec38466e `f3ef819656f68b87a91c53afbd441fec `1abc586d67f0b6c05fd5e60f25492340 `1bbf2ef67f096960e13d8578fa544536 `c2d39f2f7fe6cb69fc8efb6c5495c932 `78da47d61c91c82809a3c97a791d26d2 `11b3a28b536f34d3606427f835bd3ddf `d8041ae308961666b15aa1e57b0f9f35 `d96f80f23543850a2ee9fff8cd2cc53f `538e38fbc3f78cd61e1841d8141ddcc1 `b27bdabd8e1a6b7dc06886867331ceb3 `6c226ee1519fbf910197cc1d5c5a5756 `ee62cb0b9a97f990df1ed0266a7027e2 `ba45ddd3042dad59a12e5937644f7246 `3fd9052870778e14ab4a5acbc8c24af4 `d3fa23c9066f943f10e8883de9340dea `10ae016e19fff6ae9cfaeb8534fa47f9 `04d818cbaac08b2915db15e0bffdcb5b `8cc6b19cd410e638f4beaf1642f4f52a `d791eaca9375ca1b36a987af22ee71dd `e6684944c37dbdd4c08d978af9e47bed `bbe1deec11d459bdb348051b970abdaf `a673b3829e62477e01abc75465416b86 `7b6cb59a177abe9767fd22da5a03b1e6 `4afcb20d4d95bcd1bde3aa6b7f552660 `7c21b70f9e9c782c1f5153268e0cc1c1 `f3a9b931b7f552a4f9dfa61ce4f39f0e `fa0486610d8a02cea245c13c85b6de27 `c20d71627e66a044b21780f56f2f9504 `4f88f3eebe44285ded812939553ef94c `29b4c2b5adcd80ced1612128b3ca95a9 `16f1046144ad9ee7bb96214ba7ae7516 `002d980d74d19b43ff4e2446665e2fe5 `550becdd08d00fb1e7fd00c2adc3d3d6 `a62186ea292d6db03a087bd5dfcc3f1e `167e2a6833d49ce198cb3b88f521991e `993e58f132740b464ecf06ee289dc7b2 `c56a76ef8f604a8d87be2a32b1f81fac `3fc7462a83fa55885067fee629287e8a `4b0a768585da8f9f8f8db1ca409e7ebd `c54909ecf4fb3e9afeea36200fe95dce `d819cea5197e9b8673d6c0b16659a5ea `1b56132638912a1ca54fcf7cd38b8e23 `2ea86ae5093670df1d4502ea82efa1ac `5912529cfd6ce14c5ede5c6c83dae7e8 `15700442e957951307bbcec5fff8643d `018e32a8010960eb17e368a6fdd5a51b `e159a35d1b9a46e03072a3d54780edcb `cc64c2fcdecdb505b3797e1aaaa59adc `4cc08ca51ecf0f963035f039de6194c5 `4b227d61f33182579cd3edd0ac6c7c44 `0de0edbf2a506143c1739b12e94c0ef9 `744554499cb7880086fbd9b1f080e7e1 `5a9e950f4ac186925e5de978c5f72062 `73b8194ad8fce0cabb01cd21d5e18500 `100c0a69bea7f02a0f4540ecaa37d0e3 `809925e891b0456231c374b09cbe4a90 `dd6c32a722dc815273cd9ed8cd6c671b `ee4ff9e4e8a1948795e26af2f3f8a30f `f887e1aabf801e351bfb39698f208af1 `9cc2a0b6c8be1405cddcdeb4487c59fe `18b7998a871950ebc36c415a53630477 `ddab6357ff522c0c956ebd7669e83454 `55188a318c5998989255253e15ccc1f6 `75d9268739fe7787ac02d389ac605feb `23a22d1411afb787810d68210e6fad4f `615db1a24f36d19a8eaf18d4dceed6b2 `8d7caf84b3a51cca27291c1f7cfc2d40 `7249710187cc2d983709e044dbc78d9d `563864a949924c505985a168191dcb84 `24357fe145c869ec82fdfc8134a1a6d1 `19ecbaa5e12f7a9ebcff703c79534a52 `ced9df0d8c8ed14de91c509b31b4c4ae `cb13b64d0127c13bb466c4d4677a7b8a `f2cbe07bf2ff16d5a5860b4d6edbc5e8 `eee039f49a5b570599cf459c55c649f3 `ddd3e6f6e298d3884abc4d888a043664 `5b97ead91c0dd0bad57b4f43a89149a2 `997acc135d01b54f7de77a432fb9133f `1fed22e99b0e11a50eb7b92cb1644e8a `5badf61ecb9cfadd7d6af58712fa5f6f `fe6ba10cc6c9509b4b22e9d59e029775 `b36abffbe5d6a0de73a9968604a1a3f9 `cb9649eca3dfbd356527ffc88f1dcb94 `7dea465ad52758b10cbceb08c81d1760 `bce2fa6458f39a75e2713f3d687271a1 `e5390751969ab21df280b7591854b89f `05330c3703d0e2c96cfe657ab33f130c `4a3c42c9c5ac29db268010bbebf4f579 `1bc36080b2493aab78c26e4f2152542c `2de582c67fca31500621ecd6d3917a07 `0a8183ced0e9e3e895b41286e54e8e4d `4d8f5e581eee602c7fd21da8eb68df9a `937a597a8b399fd32caba88a3c1c7bc4 `2a8412aa50d07330f1298f0243fa79d3 `d266a2023c67b7a20c3bd01055b223bc `bc2709406a9bb19e8d83a78f81e36244 `998eda745d07fd8608f251138384a0b9 `853cac0f2d1f90b7c986e7d1dcdbbfde `4616fbea6a6dbc1074bc3f1016bbc73b `f15702ae9e55bad42182cf18724d1863 `77d965afaebd7193badc746d52b4173f `bdea71d64cdfcc405e65e750fe8d9b86 `7cc605e721fdd1d2ccc16f5b6490e830 `fb1da4a6ed74705ad98bb60ad4badaf2 `0c1821d1069578551d0e3c7d9275f16b `e3e146469ed4318eaa2ffbca3510c054 `21a8e6324e9330d4f8ebade604c62b6e `40abea0a87a64bd832a1fad69458b293 `916bda59bc7621d5c1790c040572a3c0 `5bb6f8322cdbda7a21e4aecbe04462b7 `a578acf825a595ce95fe8f804b7208f0 `706c033b4483b6d062b66d6e4ea0236a `72df0bf7853e05560d94208817b83468 `91fe03f994e8e85cede4e3bd62f4d6b7 `ed4f5a398056eef1cf6caa90786b340a `2824bef72110575c78aeb979170212b8 `e396cbf9274b590a1d94ee43d823a0bd `50562b09417cd8c4a2348a0a5aabe754 `76a1fb7f21fda9eddb95426b65124517 `299abcee56b05b312ed5700f686f79b8 `670744b945088de05866864f7d57bee7 `c1241374502f200cf9fc49c8d6fb5822 `d51032bef3e7117a94336fea18a3fad7 `65453a1ae403679bd2e47398a04205ca `abc5ca9856a61831fd4ed06b402875d2 `386dc9d1b647a9f3965f1fbe29c7dfb9 `9ad72c2a5157f21741bd4581a562dfc7 `f55d33371dcff207fd7d201128df2ea3 `229b7fc784707b1d2c702fbeba080e86 `c98cbc333fb7d95c6c9fc4924b0526e1 `c6107ff57e96a1373c019d252c00ad84 `f6debed350f20a2b3aa4d970e3227411 `c4e7199a586a308352b7a881add7e356 `15f501351d482ffd73985a50f5c89d1f `6425af51edead39c0e439073986043fb `10c715f70de25ccb493bbbb532b78ced `c18b12fff24dc87e7f1039bd17c0c6aa `cb5b6f7ab4d36e90d2619cb907ebb956 `a0a00c23556fcc5dbfb7b7f43fbbb61d `d9560caeb797b302191f667b4264da40 `a2012a3c9cdb1d6fd69afdbadc1e76b6 `13684d16fdd07d5f0584e29265a270e7 `66f43ab4b823d67f52735bbbe6ba65b0 `a106d7c1b1b277538367f9c8140e3a75 `9dca844d353efed03fbaddfc0fab7c76 `b5c628b0c1dbf857a475c4be5de4690d `0302e8a57a5e8604342a925b2dc60737 `76e127a44931bfefab991be3dd7a08b7 `e1870dde155be1a375f155dd1f7ead13 `d2e805472f79f0b558f75b90b5e7b4ee `79e647a3f8b36a1221897f5837c84aff `5931f8e3acdac724742c4ee0960d8d40 `3931327ed463d1568868c5ab8e839148 `33e01e2271be22b5ed330045fe6aff50 `cd9ba1f582642d9cbe500f018afab341 `b875f24d3d444fdda82b6bbfb75a4c92 `59d1b7206e7664e76672d3de4dc9a8ed `1b9c5ae60ec46be64a1877f0c6920edc `50557b455cba1a3ce9b4555fc3fd5433 `146e8ca40c0d37f36eecea822028dd9e `a98d42be181c01b8077e060b1b5080ec `ecf3ac80454654d990d9c07d33d35d1c `26c47355cbe966a94826cbe2fbf2b355 `33919e866426ce8e7b2ce06f19bbf889 `78292d953eafbdf9e57cc4bbbe6e8964 `c4d3a917f623f58646ce93015d79e8e0 `d12c1c2a68be4c7fda5a7737d5493b4d `f45069216cd934b80ce882c9a2f2a08a `1fe14e2e02b6e65e6e6e2ae3d8ddcc9f `e30258aeb8475d4c27f7935945671856 `cd90bce912f5743226af94c1efaaa4a7 `494557db52824555864d1106278cd1f0 `16f10764f0ccce42d5be8cfeac36b446 `dbcc4002c15afefef853a08a0804ba3a `11d4726484be418849e1f4200ade9535 `db97311c24809f103575d8a7fee19680 `286a9a4ee373398d7d2c93862c5f6661 `99f5219da22485d0872a2529599c8440 `36ff37ced0d3211db95a5ac0daac0c35 `1ca04e5339ed1826c12fe61fd984e949 `73d2fce4efa52675b35a11ee97bc2db0 `26d0c0d8c465087cf160a3bdc479f2b4 `f5f28f42ad234b4389af4cbea54ff60d `5412fb82160d0f6093e4b6670f505c13 `b051fd352847c06e748b345e8ed0738b `bf4f86812812dab8d39db9aaefe94a78 `322264a17ef7182eb1475bd2eaebc2eb `20110c8f8da8304b6d9d3c2845a38128 `992a00c30242b6217243f3c387ea18b7 `4c08b67e0c1fdeef50b1fdcc32cdcee2 `4a30eeb083acec8460150068ba0c6743 `898d25a2ab9c0ba1fa9bad462405e475 `e01e01d18582c7f69e1b0db7e1b111a0 `7e23419e4fc69b5b533815681c9bb1a9 `98c640616f997a323af625e34ba34850 `922cc71fd28b1dac8f407f1d517f5595 `43501cdf0de25278a208cbb9aad80012 `89abaa7f21cf788ce4744e3e61173291 `7604edf307a5e96120606c8dda06458f `775894425f5a7436f56fc5a3b4a2cfaa `8a29f62d1bebfe7b8008d7f264b56b4e `7fa2f0877831b4c924438396760f1841 `68a8f34c240a42ab521d2f885f7aa33c `9ac7bb94e60dc30a023ce433de027364 `dcc2e24df32287e89ee3b0f64d617f57 `8acc78be63e27e938ee53ec2c0b90c61 `9f29c6d9719fc6bc09a2981057642b69 `d13aa56e27fe71ef40ff153c093ecdf8 `9ccda414c322ebcdf875eacbba2e4b7e `69f755dd5b9e90a99c3086543790541c `277f7f2177e2a265a62680ea0158f9b9 `ee48516e57684c5a4c22adccac34be92 `216db319052b5742fc68862cb2f39905 `cbf9587a8187985725963b8bfc67004d `0dcb6d0f17794bbca56b6cdb9e20b932 `ffdbd6a7d28c9a63976e9eec38cab0f5 `de734259dfb9addebe2b226d96b4f744 `78f002cc3d512ea302c900d1da4dfeec `c4b418764dca70aebfc965899a3fa7e5 `95c0a5b8a66950b5f22dd82a8dfe0ce5 `c92c12a28fa219ad1aab60865046ff05 `12d1e0cf7396dd33a9bbbca8da4cbc68 `d77cdb466c5063b99c5aea58e6da4d32 `904b07170a0ce481b7491e7fecce4f79 `bed3b7fcc1294e23639057435ac8756a `56d5711303378bd333ddb611a53ece94 `c7937b6b4bde2a96191dc31db913e1ab `06731164684f90f33ce4017eca9d8ec1 `f8327953a0f0b80011b939111807999a `8b76101d185700a8efed148d8722d926 `16b3c9445539e9274282a612dea354c2 `ee623aaa99b429863f89da313fffed97 `116c9be6d760b4befa6d51ce9e96604c `4d6c95b0b3ea2ddb30fdd3edf3b82391 `10eb415a232ad4be7d05c57eb850036c `627a0c45dd07150343c81d856855590e `966fe8d32b86121f8a465a21b95f7e5c `4e7b945feca199bd486653fea1d0e39c `fa16213d24273d386d22332cd01ce774 `a2679a7d860a0bfb2645809ed92ce138 `58e83fb33c120db338132d23b9112805 `c6dc6e6567d673436ac41ebc8e79a9ec `7198e10ebcf1bb88dc479b5c5b9f2c15 `a4462529ab493676987d946019a14945 `f7df7b85af230b2623d3a827b0cbddd2 `cc573488dec311655890a205aad4fb65 `7164823f504286e3a762ee612ff0a988 `da67e2f049b5b6babcf7906b85653399 `584b2b145f362098fc5fc1e634d57de5 `c6696a730f7498efb66f5ba3a8b35d08 `16fa0e4aefe18e1446bf6baefd3ba400 `6e970d0818d58ff2d50c5bf037b1a565 `0ebe78077c8b48410cf52a0bccdff866 `924727b6f380cf3cdfe5650163e92054 `26d48d68b28f927bfebad454658f9425 `bda9a5da86ec9790262e14f953bbadcb `cc1a3b2f107510ac664e491d5f2412aa `d9c6ab5c6630a4a84e242c5765103d2d `7a9609a971a8f31685e88da563eea5ce `14cf6e75aec1ead888e7101d3d94d28a `14a6d294550c9760aec57ba29682a750 `5d827a1e8ea70edb11d946b54f076cae `b9d4f73fa7ca8ef66891554b66b2cded `dc962e34780f0374b7eb3d583f6d7eb6 `de1ab82817c0fb24e591b9a89a82f736 `09677934e13a5d728f00c6ed7c8870a9 `7052598d2355984237d126afea2f6e88 `927612b57ba01ca878b2d7edce52a563 `97402287d8c6c03f0b63848e17e9d944 `62f31128a21b0e240bdb7b3d5b121c04 `54da1b916f49ef40c822fab61d37cf66 `41b811063b9425de1934e77d89118022 `37b622eaad1f79e759a722aacebf48ec `73262345214f9b7794f2cc4a612b15e8 `9baedcd033169611a42c3cfd58b3ae03 `f23ca2aa066b1ee0fa4df1f2f865be4c `3c2523e65ff953fd73579aaaf5d7ce36 `88a8e608108be939da9aab5a9a8af7d1 `2f1ec795216d5bafa33a810af3421942 `ce0aea06d44878b4a373efe090a66a62 `c0e423f9ac41cc5b265c95a3e97e3fcb `7ed1d2efa3e0f0ed6b77eb4eff3d86b3 `3811b40721f7ca651887aac4eb17f9f0 `5a765f9668608a39333fa90cf462657e `c70b78fd0b5dffcd38322355e9c2471e `229975f1e84b5088e819cd5f2dc43080 `10eb1e7dc64d8ca3dad92641dadb5de7 `49ba23148db9effdc3979aa0fe5876ea `f6dff70097776e24c2a7c9c0f2514f79 `991285e3967c3295b4ff2dcd835f7c61 `50f43b1726cf61066ef8656477b226be `eeef60efe889349870426d10edc694be `4b046ac6a4796fb1338f0481dbd4003d `b2621497b3313c97855ed951f0d9b291 `ff1441a42144a7de9a3eaf9f5e7cfea9 `5988b62a0c0785a303b77c74608e8b55 `94b85ba716dbb7c20b230e69248b8208>veindex8vgindexes5vbid3xdtypeeRadixvdnode{dNode6vac<va0{dNode6vac<va0{dNode6vac6va2{dNode6vac1vad{dNode6vac0wad1ypJxawd002dxakadxasadvaetwad1ypDxawc002xaka2xasa2vaetva4{dNode6vac0wad1ypixawd0040xaka4xasb40vaetva9{dNode6vac0wad1ypnxawd0096xaka9xasb96vaetvad{dNode6vac0wad1ypexawd00ddxakadxasbddvaetvaa{dNode6vac0wad1ypmxawd00adxakaaxasbadvaetvac{dNode6vac0wad1ypgxawc00cxakacxasacvaetwad0xawb00xaka0xasa0vaesva1{dNode6vac<va0{dNode6vac1va5{dNode6vac0wad1ypIxawf01055bxaka5xasb5bvaetwad1ypfxawd0105xaka0xasb05vaetva1{dNode6vac0wad1ypqxawh011687ebxaka1xasf1687ebvaetva2{dNode6vac0wad1ypsxawd0127xaka2xasb27vaetva5{dNode6vac0wad1yp}xawe0158fxaka5xasc58fvaetva6{dNode6vac0wad1ypzxawc016xaka6xasa6vaetva8{dNode6vac2vab{dNode6vac0wad1ypexawd018bxakabxasabvaetvae{dNode6vac0wad1ypXxawd018exakaexasaevaetwad0xawc018xaka8xasa8vaesva9{dNode6vac0wad1ypmxawc019xaka9xasa9vaetvaa{dNode6vac0wad1yp@xawe01abcxakaaxascabcvaetvac{dNode6vac2vad{dNode6vac0wad1yp`xawd01cdxakadxasadvaetvae{dNode6vac0wad1ypYxawd01cexakaexasaevaetwad0xawc01cxakacxasacvaesvab{dNode6vac0wad2ypxKxawc01bxakabxasabvaetvae{dNode6vac0wad1ypDxawc01exakaexasaevaetvad{dNode6vac0wad1ypkxawc01dxakadxasadvaet>wad0xawb01xaka1xasa1vaesva2{dNode6vac:va3{dNode6vac1va6{dNode6vac0wad1ypZxawe0236axaka6xasb6avaetwad1ypvxawc023xaka3xasa3vaetva4{dNode6vac0wad1ypHxawd0243xaka4xasb43vaetva6{dNode6vac0wad1ypvxawd0266xaka6xasb66vaetva7{dNode6vac0wad1ypvxawf027364xaka7xasd7364vaetva9{dNode6vac0wad1yp{xawf029775xaka9xasd9775vaetvac{dNode6vac0wad1ypUxawc02cxakacxasacvaetvad{dNode6vac0wad2yptjxawc02dxakadxasadvaetvae{dNode6vac0wad1ypjxaw Y02ebfecc7a931dad1ec38466exakaexas Webfecc7a931dad1ec38466evaetvaa{dNode6vac0wad1ypaxawc02axakaaxasaavaetvab{dNode6vac0wad1ypSxawc02bxakabxasabvaetwad0xawb02xaka2xasa2vaesva3{dNode6vac;va0{dNode6vac2va2{dNode6vac0wad1yp}xawe0302exaka2xasb2evaetva7{dNode6vac0wad1ypYxawf03072axaka7xasc72avaetwad0xawc030xaka0xasa0vaesva3{dNode6vac1va1{dNode6vac0wad1yp}xaw Y033169611a42c3cfd58b3ae03xaka1xas V169611a42c3cfd58b3ae03vaetwad1ypZxawc033xaka3xasa3vaetva4{dNode6vac0wad1ypUxawd0345xaka4xasb45vaetva6{dNode6vac0wad1yptxawn03668caaecbc57xaka6xasl668caaecbc57vaetva7{dNode6vac1va4{dNode6vac0wad1yprxawe0374bxaka4xasb4bvaetwad1ypfxawc037xaka7xasa7vaetva8{dNode6vac0wad1ypFxawh03865b60xaka8xasf865b60vaetva9{dNode6vac1va9{dNode6vac0wad1ypxxawf03996cxaka9xasc96cvaetwad2yp[uxawc039xaka9xasa9vaetvad{dNode6vac1vac{dNode6vac0wad1ypRxawd03dcxakacxasacvaetwad1yp_xawc03dxakadxasadvaetvaa{dNode6vac0wad2ypnLxawc03axakaaxasaavaetvab{dNode6vac0wad1ypAxawc03bxakabxasabvaetvaf{dNode6vac1vab{dNode6vac0wad1yp{xaw Q03fbaddfc0fab7c76xakabxasnbaddfc0fab7c76vaetwad1yp\xawc03fxakafxasafvaetwad0xawb03xaka3xasa3vaesva4{dNode6vac:va0{dNode6vac1va5{dNode6vac0wad1ypWxawj040572a3c0xaka5xasg572a3c0vaetwad1ypuxawc040xaka0xasa0vaetva2{dNode6vac0wad1ypfxawg04205caxaka2xase205cavaetva3{dNode6vac0wad1ypvxawf043664xaka3xasd3664vaetva4{dNode6vac0wad1ypFxawc044xaka4xasa4vaetva5{dNode6vac0wad1ypbxaw U0456231c374b09cbe4a90xaka5xas S56231c374b09cbe4a90vaetva6{dNode6vac0wad1ypOxawc046xaka6xasa6vaetva8{dNode6vac2va1{dNode6vac0wad1ypOxawg0481dbdxaka1xasd1dbdvaetva6{dNode6vac0wad1ypExaw ^0486610d8a02cea245c13c85b6de27xaka6xas [6610d8a02cea245c13c85b6de27vaetwad0xawc048xaka8xasa8vaesva9{dNode6vac0wad1ypbxawc049xaka9xasa9vaetvad{dNode6vac0wad1yp{xawc04dxakadxasadvaetvae{dNode6vac0wad1yp^xawc04exakaexasaevaetwad2ypQxxawb04xaka4xasa4vaetva5{dNode6vac6va2{dNode6vac2va4{dNode6vac0wad1ypixawg0526476xaka4xasc476vaetvae{dNode6vac0wad1yplxawe0526exakaexasaevaetwad0xawd0526xaka2xasb26vaesva3{dNode6vac0wad1ypAxawf05330cxaka3xasd330cvaetva5{dNode6vac0wad1yp[xawf05560dxaka5xasd560dvaetva8{dNode6vac2va4{dNode6vac0wad1ypxxawd0584xaka4xasa4vaetva6{dNode6vac0wad1ypcxaw Q05866864f7d57bee7xaka6xasn66864f7d57bee7vaetwad0xawc058xaka8xasa8vaesvaf{dNode6vac0wad1yplxawd05fdxakafxasbfdvaetvac{dNode6vac0wad1ypUxawc05cxakacxasacvaetwad0xawb05xaka5xasa5vaesva6{dNode6vac9va0{dNode6vac0wad1ypKxawc060xaka0xasa0vaetva2{dNode6vac0wad1ypZxawc062xaka2xasa2vaetva4{dNode6vac0wad1ypYxaw `0645bdb1cdf88ec74288d503eb71839cxaka4xas ^45bdb1cdf88ec74288d503eb71839cvaetva6{dNode6vac0wad1yp~xawc066xaka6xasa6vaetva7{dNode6vac0wad1ypNxaw `06731164684f90f33ce4017eca9d8ec1xaka7xas ^731164684f90f33ce4017eca9d8ec1vaetvae{dNode6vac2vaa{dNode6vac0wad1ypixawf06eacdxakaaxascacdvaetvae{dNode6vac0wad1ypNxawd06eexakaexasaevaetwad0xawc06exakaexasaevaesvab{dNode6vac0wad1ypgxawc06bxakabxasabvaetvaf{dNode6vac0wad1ypNxawc06fxakafxasafvaetvad{dNode6vac0wad1ypBxawc06dxakadxasadvaetwad0xawb06xaka6xasa6vaesva7{dNode6vac9va1{dNode6vac3va3{dNode6vac0wad1ypAxaw \071363645a588f858b35231128c4xaka3xas Y363645a588f858b35231128c4vaetva5{dNode6vac0wad1ypVxaw V07150343c81d856855590exaka5xas S50343c81d856855590evaetva7{dNode6vac0wad1ypJxawi07170a0cexaka7xasf70a0cevaetwad0xawc071xaka1xasa1vaesva2{dNode6vac0wad1yp|xawc072xaka2xasa2vaetva3{dNode6vac1va3{dNode6vac0wad1ypHxawf07330fxaka3xasc30fvaetwad1ypZxawc073xaka3xasa3vaetva6{dNode6vac0wad1yppxawc076xaka6xasa6vaetva8{dNode6vac0wad1ypRxawd0785xaka8xasb85vaetvaf{dNode6vac1vad{dNode6vac0wad1ypKxawd07fdxakadxasadvaetwad1ypTxawc07fxakafxasafvaetvaa{dNode6vac0wad1ypdxawc07axakaaxasaavaetvab{dNode6vac0wad1yptxawd07bfxakabxasbbfvaetvad{dNode6vac0wad1ypxxawc07dxakadxasadvaetwad0xawb07xaka7xasa7vaesva8{dNode6vac7va0{dNode6vac0wad2ypc_xawc080xaka0xasa0vaetva1{dNode6vac0wad1ypfxawd0818xaka1xasb18vaetva3{dNode6vac0wad1ypixawc083xaka3xasa3vaetva6{dNode6vac0wad1ypZxawd086bxaka6xasb6bvaetva7{dNode6vac2va2{dNode6vac0wad1yp\xawd0872xaka2xasa2vaetva7{dNode6vac0wad1yptxaw [0877831b4c924438396760f1841xaka7xas X7831b4c924438396760f1841vaetwad1ypLxawc087xaka7xasa7vaetvab{dNode6vac0wad2yp{hxawc08bxakabxasabvaetvac{dNode6vac0wad1yp[xawd08caxakacxasbcavaetwad0xawb08xaka8xasa8vaesva9{dNode6vac7va0{dNode6vac1va1{dNode6vac0wad1ypHxawi0901979bdxaka1xasf1979bdvaetwad1ypBxawc090xaka0xasa0vaetva1{dNode6vac0wad1ypGxawg09155bfxaka1xase155bfvaetva3{dNode6vac0wad1ypzxawc093xaka3xasa3vaetva4{dNode6vac0wad1yp`xawg09417cdxaka4xase417cdvaetva6{dNode6vac3va0{dNode6vac0wad1ypUxawg09602baxaka0xasd02bavaetva7{dNode6vac0wad1yptxaw `09677934e13a5d728f00c6ed7c8870a9xaka7xas ]77934e13a5d728f00c6ed7c8870a9vaetva9{dNode6vac0wad1ypmxaw V096960e13d8578fa544536xaka9xas S960e13d8578fa544536vaetwad0xawc096xaka6xasa6vaesvad{dNode6vac0wad1yphxawd09dbxakadxasbdbvaetvaa{dNode6vac0wad1ypyxawc09axakaaxasaavaetwad0xawb09xaka9xasa9vaesvad{dNode6vac2vae{dNode6vac0wad1yp]xawc0dexakaexasaevaetvac{dNode6vac0wad1ypAxawd0dcbxakacxasbcbvaetwad0xawb0dxakadxasadvaesvaa{dNode6vac1vae{dNode6vac0wad1ypBxawd0aeaxakaexasbeavaetwad1ypExawb0axakaaxasaavaetvac{dNode6vac0wad1ypSxawb0cxakacxasacvaetvae{dNode6vac0wad1ypgxawd0ebexakaexascebevaet>wad<ypZZ_eegmtwww~CKORUV[\\aaflv{DQS[]]`aafhrwwyAELVY[_`s|HJP]]]_``bhjkkwxAFFHTVZ_egx~DDGJR>xawa0xaka0xasa0vaetva1{dNode6vac<va0{dNode6vac9va0{dNode6vac0wad1ypaxawd100cxaka0xasb0cvaetva3{dNode6vac2va5{dNode6vac0wad1ypZxaw R103575d8a7fee19680xaka5xaso575d8a7fee19680vaetva9{dNode6vac0wad1ypsxawd1039xaka9xasa9vaetwad0xawc103xaka3xasa3vaesva4{dNode6vac2va6{dNode6vac0wad1ypIxaw ]1046144ad9ee7bb96214ba7ae7516xaka6xas Z6144ad9ee7bb96214ba7ae7516vaetvab{dNode6vac0wad1ypZxawd104bxakabxasabvaetwad0xawc104xaka4xasa4vaesva6{dNode6vac0wad1ypSxaw Y1069578551d0e3c7d9275f16bxaka6xas W69578551d0e3c7d9275f16bvaetva7{dNode6vac2va5{dNode6vac0wad1ypkxawh107510acxaka5xase510acvaetva6{dNode6vac0wad1ypWxaw ]10764f0ccce42d5be8cfeac36b446xaka6xas Z64f0ccce42d5be8cfeac36b446vaetwad0xawc107xaka7xasa7vaesvaa{dNode6vac1vae{dNode6vac0wad1ypzxawd10aexakaexasaevaetwad1yp_xawc10axakaaxasaavaetvad{dNode6vac1vae{dNode6vac0wad1ypVxawd10dexakaexasaevaetwad1yplxawc10dxakadxasadvaetvae{dNode6vac1vab{dNode6vac1vac{dNode6vac0wad1yp]xawf10ebcfxakacxasbcfvaetwad2ypUIxawd10ebxakabxasabvaetwad1ypyxawc10exakaexasaevaetvac{dNode6vac2vac{dNode6vac0wad1yp{xawd10ccxakacxasacvaetvab{dNode6vac0wad1yp~xaw Q10cbceb08c81d1760xakabxasnbceb08c81d1760vaetwad1yprxawc10cxakacxasacvaetwad0xawb10xaka0xasa0vaesva1{dNode6vac8va1{dNode6vac0wad1ypkxawd111axaka1xasb1avaetva5{dNode6vac0wad1yp@xawc115xaka5xasa5vaetva6{dNode6vac0wad1ypSxawd116cxaka6xasb6cvaetvaf{dNode6vac0wad1ypYxawd11fexakafxasbfevaetvaa{dNode6vac0wad2ypzyxawc11axakaaxasaavaetvab{dNode6vac0wad1yppxawc11bxakabxasabvaetvad{dNode6vac0wad3ypYpxawc11dxakadxasadvaetvae{dNode6vac0wad1yp_xawd11eexakaexasbeevaetwad0xawb11xaka1xasa1vaesva2{dNode6vac9va0{dNode6vac0wad1yp[xawc120xaka0xasa0vaetva1{dNode6vac0wad1ypxxawc121xaka1xasa1vaetva2{dNode6vac1va1{dNode6vac0wad1ypAxaw R1221897f5837c84affxaka1xaso1897f5837c84affvaetwad1ypYxawc122xaka2xasa2vaetva7{dNode6vac0wad2ypq~xawc127xaka7xasa7vaetva9{dNode6vac2va4{dNode6vac0wad1ypKxawd1294xaka4xasa4vaetva8{dNode6vac0wad1ypHxawd1298xaka8xasa8vaetwad0xawc129xaka9xasa9vaesvae{dNode6vac0wad1yp]xawc12exakaexasaevaetvaf{dNode6vac2vaf{dNode6vac0wad1ypsxawe12fffxakafxasbffvaetvae{dNode6vac0wad1yp^xawd12fexakaexasaevaetwad1ypqxawc12fxakafxasafvaetvaa{dNode6vac0wad1ypGxawc12axakaaxasaavaetvad{dNode6vac0wad1ypHxawc12dxakadxasadvaetwad0xawb12xaka2xasa2vaesva3{dNode6vac7va0{dNode6vac0wad1ypAxawc130xaka0xasa0vaetva2{dNode6vac0wad1ypNxawg132740bxaka2xase2740bvaetva3{dNode6vac1va8{dNode6vac0wad1ypOxawd1338xaka8xasa8vaetwad1ypfxawc133xaka3xasa3vaetva5{dNode6vac0wad1ypxxawc135xaka5xasa5vaetva6{dNode6vac0wad1ypxxawf13684dxaka6xasd684dvaetva7{dNode6vac0wad1ypmxawd1373xaka7xasb73vaetvab{dNode6vac1vab{dNode6vac0wad1ypsxawd13bbxakabxasabvaetwad1ypsxawc13bxakabxasabvaetwad1ypbxawb13xaka3xasa3vaetva4{dNode6vac:va0{dNode6vac2va1{dNode6vac0wad1ypUxawk140132d26a2xaka1xash132d26a2vaetva5{dNode6vac0wad1ypfxaw T1405cddcdeb4487c59fexaka5xas Q5cddcdeb4487c59fevaetwad1yp\xawc140xaka0xasa0vaetva1{dNode6vac0wad1ypkxawg1411afbxaka1xase11afbvaetva4{dNode6vac2va1{dNode6vac0wad1ypQxawd1441xaka1xasa1vaetva6{dNode6vac0wad1ypexawd1446xaka6xasa6vaetwad0xawc144xaka4xasa4vaesva5{dNode6vac0wad2yppcxawc145xaka5xasa5vaetva6{dNode6vac2va4{dNode6vac0wad1ypTxawh146469edxaka4xase469edvaetvae{dNode6vac0wad1ypJxawd146exakaexasaevaetwad0xawc146xaka6xasa6vaesva9{dNode6vac0wad1yp}xawf14984axaka9xasd984avaetvad{dNode6vac0wad2yp_rxawd14dexakadxasbdevaetvae{dNode6vac0wad1ypSxawc14exakaexasaevaetvac{dNode6vac0wad1ypnxawd14cfxakacxasbcfvaetvaa{dNode6vac0wad1ypoxawc14axakaaxasaavaetwad0xawb14xaka4xasa4vaesva5{dNode6vac:va0{dNode6vac0wad1ypZxawc150xaka0xasa0vaetva1{dNode6vac0wad1ypuxawg1519fbfxaka1xase19fbfvaetva2{dNode6vac0wad1ypcxawc152xaka2xasa2vaetva3{dNode6vac1va5{dNode6vac0wad1ypMxawf15357bxaka5xasc57bvaetwad1ypzxawc153xaka3xasa3vaetva6{dNode6vac0wad1ypCxaw S1568868c5ab8e839148xaka6xas Q68868c5ab8e839148vaetva7{dNode6vac0wad1ypWxaw `15700442e957951307bbcec5fff8643dxaka7xas ^700442e957951307bbcec5fff8643dvaetva9{dNode6vac0wad1ypsxawf15932axaka9xasd932avaetvae{dNode6vac0wad1yp{xawc15exakaexasaevaetvaf{dNode6vac0wad1yppxawc15fxakafxasafvaetvaa{dNode6vac0wad1ypXxaw W15afefef853a08a0804ba3axakaaxas Uafefef853a08a0804ba3avaetwad1yp]xawb15xaka5xasa5vaetva6{dNode6vac<va0{dNode6vac0wad1yp`xawc160xaka0xasa0vaetva1{dNode6vac0wad1ypHxawo1612128b3ca95a9xaka1xasm12128b3ca95a9vaetva2{dNode6vac0wad1ypYxawf16213dxaka2xasd213dvaetva3{dNode6vac0wad1ypBxaw `163beeae9620c1a6a46a38aa7ebd9663xaka3xas ^3beeae9620c1a6a46a38aa7ebd9663vaetva4{dNode6vac2va2{dNode6vac0wad1yp|xawe1642fxaka2xasb2fvaetva4{dNode6vac0wad1ypyxawg1644e8axaka4xasd4e8avaetwad0xawc164xaka4xasa4vaesva6{dNode6vac2va5{dNode6vac0wad1ypSxawi16659a5eaxaka5xasf59a5eavaetva7{dNode6vac0wad1ypbxaw V1667498626ae52ad0362e0xaka7xas S7498626ae52ad0362e0vaetwad0xawc166xaka6xasa6vaesva7{dNode6vac2vaa{dNode6vac0wad1ypSxawd167axakaaxasaavaetvae{dNode6vac0wad1ypMxawd167exakaexasaevaetwad0xawc167xaka7xasa7vaesva8{dNode6vac0wad1ypoxawk168191dcb84xaka8xasi8191dcb84vaetva9{dNode6vac0wad1ypRxawd169exaka9xasb9evaetvaa{dNode6vac0wad1yp]xawc16axakaaxasaavaetvaf{dNode6vac2vad{dNode6vac1vad{dNode6vac0wad1ypxxawe16fddxakadxasadvaetwad1ypFxawd16fdxakadxasadvaetvaa{dNode6vac0wad1ypexawd16faxakaaxasaavaetwad3ypIQWxawc16fxakafxasafvaetvad{dNode6vac0wad1yptxawc16dxakadxasadvaetvab{dNode6vac0wad1ypQxawc16bxakabxasabvaet>wad0xawb16xaka6xasa6vaesva7{dNode6vac7va2{dNode6vac0wad2ypWMxawd1726xaka2xasb26vaetva3{dNode6vac0wad1yp]xawd1739xaka3xasb39vaetva7{dNode6vac1va9{dNode6vac0wad1ypAxaw X17794bbca56b6cdb9e20b932xaka9xas U94bbca56b6cdb9e20b932vaetwad2ypMAxawc177xaka7xasa7vaetva9{dNode6vac0wad1ypWxawd1790xaka9xasb90vaetvab{dNode6vac0wad1ypSxawc17bxakabxasabvaetvaa{dNode6vac1vab{dNode6vac0wad1ypjxawf17abebxakabxascbebvaetwad1ypZxawc17axakaaxasaavaetvac{dNode6vac0wad2ypesxawc17cxakacxasacvaetwad0xawb17xaka7xasa7vaesva8{dNode6vac;va1{dNode6vac0wad1ypKxawc181xaka1xasa1vaetva2{dNode6vac2va1{dNode6vac1va8{dNode6vac0wad1ypXxawe18218xaka8xasa8vaetwad1ypSxawd1821xaka1xasa1vaetva6{dNode6vac0wad1yp^xawd1826xaka6xasa6vaetwad0xawc182xaka2xasa2vaesva4{dNode6vac0wad1ypsxawd1841xaka4xasb41vaetva5{dNode6vac4va0{dNode6vac0wad1yp`xawe18500xaka0xasb00vaetva1{dNode6vac0wad1yp\xaw W18514362a4e52376a6fecbaxaka1xas T14362a4e52376a6fecbavaetva7{dNode6vac0wad1ypPxaw X185700a8efed148d8722d926xaka7xas U700a8efed148d8722d926vaetva8{dNode6vac0wad1ypkxawf18582cxaka8xasc82cvaetwad0xawc185xaka5xasa5vaesva6{dNode6vac2va3{dNode6vac0wad1ypNxawd1863xaka3xasa3vaetva9{dNode6vac0wad1yp_xaw U186925e5de978c5f72062xaka9xas R925e5de978c5f72062vaetwad0xawc186xaka6xasa6vaesva7{dNode6vac2va2{dNode6vac0wad1ypNxawf18724dxaka2xasc24dvaetva7{dNode6vac0wad1ypHxawe1877fxaka7xasb7fvaetwad0xawc187xaka7xasa7vaesva8{dNode6vac1vac{dNode6vac0wad1yppxawd188cxakacxasacvaetwad1ypzxawc188xaka8xasa8vaetvae{dNode6vac0wad2yp]exawc18exakaexasaevaetvac{dNode6vac0wad1ypVxawc18cxakacxasacvaetvab{dNode6vac0wad1ypgxawc18bxakabxasabvaetvad{dNode6vac0wad1yplxawc18dxakadxasadvaetwad0xawb18xaka8xasa8vaesva9{dNode6vac<va3{dNode6vac0wad1ypzxawd1934xaka3xasb34vaetva4{dNode6vac2va4{dNode6vac0wad1ypVxaw \19442484b3e4f47875b58b3f72b2xaka4xas Y42484b3e4f47875b58b3f72b2vaetva8{dNode6vac0wad1ypdxaw U1948795e26af2f3f8a30fxaka8xas R8795e26af2f3f8a30fvaetwad0xawc194xaka4xasa4vaesva6{dNode6vac0wad1ypxxawg1966beexaka6xase66beevaetva7{dNode6vac0wad1ypgxawd1973xaka7xasb73vaetva8{dNode6vac0wad1ypMxawc198xaka8xasa8vaetva9{dNode6vac0wad1ypXxawc199xaka9xasa9vaetvac{dNode6vac1vad{dNode6vac0wad1yp|xawd19cdxakadxasadvaetwad1ypUxawc19cxakacxasacvaetvad{dNode6vac0wad1ypOxawc19dxakadxasadvaetvae{dNode6vac1vac{dNode6vac0wad1ypqxawg19ecbaaxakacxasdcbaavaetwad1ypaxawc19exakaexasaevaetvaf{dNode6vac0wad1ypzxawe19fffxakafxascfffvaetvab{dNode6vac1vab{dNode6vac0wad1ypNxawe19bbfxakabxasbbfvaetwad1ypJxawc19bxakabxasabvaetvaa{dNode6vac0wad1yplxawc19axakaaxasaavaet>wad0xawb19xaka9xasa9vaesvae{dNode6vac0wad1ypFxawb1exakaexasaevaetvaa{dNode6vac1vab{dNode6vac0wad1yplxawd1abcxakabxasbbcvaetwad2ypikxawb1axakaaxasaavaetvab{dNode6vac2vab{dNode6vac0wad1ypmxawd1bbfxakabxasbbfvaetvac{dNode6vac0wad1ypCxawc1bcxakacxasacvaetwad2ypTHxawb1bxakabxasabvaetvaf{dNode6vac1vad{dNode6vac0wad1ypyxawd1fedxakadxasadvaetwad1ypSxawc1fexakafxasbfevaetvac{dNode6vac0wad1yp^xawc1caxakacxasbcavaet>wad<ypPPZgmopqw~JJKUYiuvABCLOQUUYZeelmppGLLQRV_ahhlpwzz|EGIKQhhjkknnsDGHM]cfnpsy{~~@DI>xawa1xaka1xasa1vaetva2{dNode6vac<va0{dNode6vac9va1{dNode6vac2va1{dNode6vac0wad1ypfxawf20110cxaka1xasc10cvaetva9{dNode6vac0wad1ypcxawd2019xaka9xasa9vaetwad0xawc201xaka1xasa1vaesva2{dNode6vac0wad1ypIxawd2023xaka2xasb23vaetva8{dNode6vac1vaa{dNode6vac0wad1yp|xawd208axakaaxasaavaetwad1ypexawc208xaka8xasa8vaetvaf{dNode6vac0wad1ypRxawd20faxakafxasbfavaetvae{dNode6vac0wad1ypKxawc20exakaexasaevaetvab{dNode6vac0wad2ypXSxawc20bxakabxasabvaetvad{dNode6vac0wad1ypBxawc20dxakadxasadvaetvac{dNode6vac0wad1ypIxawc20cxakacxasacvaetvaa{dNode6vac0wad1ypnxawc20axakaaxasaavaetwad0xawb20xaka0xasa0vaesva1{dNode6vac:va5{dNode6vac0wad1ypexawh21590549xaka5xasf590549vaetva6{dNode6vac0wad1ypxawe216dbxaka6xasc6dbvaetva7{dNode6vac3va4{dNode6vac0wad1ypixawg21741bdxaka4xasd41bdvaetva7{dNode6vac0wad1yp}xawe2177exaka7xasb7evaetva8{dNode6vac0wad1ypFxawf21780fxaka8xasc80fvaetwad0xawc217xaka7xasa7vaesva8{dNode6vac2va1{dNode6vac0wad1ypXxaw ]21814165879f72529e91682ece5c6xaka1xas Z14165879f72529e91682ece5c6vaetvae{dNode6vac0wad1yp[xawd218exakaexasaevaetwad0xawc218xaka8xasa8vaesva9{dNode6vac1va8{dNode6vac0wad1ypDxawf21982fxaka8xasc82fvaetwad2ypZGxawc219xaka9xasa9vaetvab{dNode6vac0wad3ypCWxxawc21bxakabxasabvaetvad{dNode6vac1vaa{dNode6vac0wad1ypFxawd21daxakaaxasaavaetwad1yp`xawc21dxakadxasadvaetvaa{dNode6vac0wad1ypUxawc21axakaaxasaavaetvaf{dNode6vac0wad1ypaxawe21fdaxakafxascfdavaetvac{dNode6vac0wad1yppxawd21cfxakacxasbcfvaetwad0xawb21xaka1xasa1vaesva2{dNode6vac;va0{dNode6vac0wad1ypFxawc220xaka0xasa0vaetva3{dNode6vac2va3{dNode6vac0wad1ypYxawg22332cdxaka3xasd32cdvaetvab{dNode6vac0wad1ypIxawe223bcxakabxasbbcvaetwad0xawc223xaka3xasa3vaesva4{dNode6vac0wad1yp\xawf22485dxaka4xasd485dvaetva5{dNode6vac0wad1ypVxawg22569afxaka5xase569afvaetva6{dNode6vac0wad1ypuxawc226xaka6xasa6vaetva7{dNode6vac1va1{dNode6vac0wad1ypDxawd2271xaka1xasa1vaetwad1yp\xawc227xaka7xasa7vaetva9{dNode6vac2va9{dNode6vac0wad1ypHxaw `229975f1e84b5088e819cd5f2dc43080xaka9xas ]975f1e84b5088e819cd5f2dc43080vaetvab{dNode6vac0wad1ypkxawd229bxakabxasabvaetwad0xawc229xaka9xasa9vaesvaa{dNode6vac1vac{dNode6vac0wad1yp~xawn22adccac34be92xakacxasjccac34be92vaetwad1yp`xawd22adxakaaxasbadvaetvae{dNode6vac1vaf{dNode6vac0wad1ypDxawf22efefxakafxascfefvaetwad4ypmiy{xawc22exakaexasaevaetvab{dNode6vac0wad2ypDDxawc22bxakabxasabvaetvad{dNode6vac2vaa{dNode6vac0wad1ypAxawd22daxakaaxasaavaetvad{dNode6vac0wad1ypFxawd22ddxakadxasadvaetwad1ypkxawc22dxakadxasadvaetwad0xawb22xaka2xasa2vaesva3{dNode6vac8va0{dNode6vac0wad2yp_Sxawc230xaka0xasa0vaetva1{dNode6vac1va4{dNode6vac0wad1ypJxawg23148dbxaka4xasd48dbvaetwad1ypvxawc231xaka1xasa1vaetva2{dNode6vac0wad1ypUxawc232xaka2xasa2vaetva4{dNode6vac2va1{dNode6vac0wad1yplxaw ^23419e4fc69b5b533815681c9bb1a9xaka1xas [19e4fc69b5b533815681c9bb1a9vaetva8{dNode6vac0wad1yp`xawe2348axaka8xasb8avaetwad1ypaxawc234xaka4xasa4vaetva5{dNode6vac2va4{dNode6vac0wad1yprxaw Y23543850a2ee9fff8cd2cc53fxaka4xas V43850a2ee9fff8cd2cc53fvaetva5{dNode6vac0wad1ypuxaw Z23556fcc5dbfb7b7f43fbbb61dxaka5xas W56fcc5dbfb7b7f43fbbb61dvaetwad0xawc235xaka5xasa5vaesva6{dNode6vac3va3{dNode6vac0wad1ypKxaw R23639057435ac8756axaka3xaso39057435ac8756avaetva6{dNode6vac0wad1ypZxawl236659680493xaka6xasi659680493vaetva7{dNode6vac0wad1ypkxaw Y2367372c3199c66a6420faf89xaka7xas V7372c3199c66a6420faf89vaetwad0xawc236xaka6xasa6vaesvac{dNode6vac0wad2ypKyxawc23cxakacxasacvaetvaa{dNode6vac0wad2ypgkxawc23axakaaxasaavaetwad0xawb23xaka3xasa3vaesva4{dNode6vac:va0{dNode6vac0wad2ypuxxawc240xaka0xasa0vaetva1{dNode6vac0wad1ypkxawf2412aaxaka1xasd12aavaetva2{dNode6vac1va7{dNode6vac0wad1ypYxawf24273dxaka7xasc73dvaetwad1yplxawc242xaka2xasa2vaetva3{dNode6vac0wad1yppxawg24357fexaka3xase357fevaetva4{dNode6vac0wad1ypJxawl2446665e2fe5xaka4xasj46665e2fe5vaetva7{dNode6vac0wad1ypfxawl247784b9d930xaka7xasj7784b9d930vaetva8{dNode6vac0wad1ypZxawf24809fxaka8xasd809fvaetva9{dNode6vac0wad1ypCxaw W2493aab78c26e4f2152542cxaka9xas U93aab78c26e4f2152542cvaetvaf{dNode6vac0wad1yplxawc24fxakafxasafvaetvad{dNode6vac2vac{dNode6vac0wad1ypsxawd24dcxakacxasacvaetvaf{dNode6vac0wad1ypwxawd24dfxakafxasafvaetwad1ypFxawc24dxakadxasadvaetwad0xawb24xaka4xasa4vaesva5{dNode6vac8va1{dNode6vac0wad1ypKxawm251138384a0b9xaka1xask1138384a0b9vaetva2{dNode6vac2va3{dNode6vac0wad1ypxawd2523xaka3xasa3vaetva9{dNode6vac0wad1yp\xawl2529599c8440xaka9xasi9599c8440vaetwad1ypmxawc252xaka2xasa2vaetva4{dNode6vac0wad1yplxawh25492340xaka4xasf492340vaetva6{dNode6vac0wad1ypgxawd2561xaka6xasb61vaetva7{dNode6vac0wad1ypXxawc257xaka7xasa7vaetva8{dNode6vac0wad1ypUxawc258xaka8xasa8vaetvac{dNode6vac0wad1yprxawe25ccbxakacxascccbvaetvaa{dNode6vac0wad1ypjxawc25axakaaxasaavaetwad1ypdxawb25xaka5xasa5vaetva6{dNode6vac;va1{dNode6vac0wad1yptxawd2619xaka1xasb19vaetva2{dNode6vac0wad1yp_xawe2623dxaka2xasc23dvaetva3{dNode6vac0wad1yp_xaw T2632722300194f01e93dxaka3xas R32722300194f01e93dvaetva4{dNode6vac1va5{dNode6vac0wad1ypZxaw P2645809ed92ce138xaka5xasm5809ed92ce138vaetwad1ypsxawc264xaka4xasa4vaetva5{dNode6vac0wad2yp}Cxawc265xaka5xasa5vaetva8{dNode6vac0wad1ypBxaw P268010bbebf4f579xaka8xasn8010bbebf4f579vaetvac{dNode6vac1vae{dNode6vac0wad1ypYxawd26cexakaexasaevaetwad1ypMxawc26cxakacxasacvaetvae{dNode6vac0wad1yp]xawc26exakaexasaevaetvaf{dNode6vac0wad1yp]xawd26fdxakafxasbfdvaetvab{dNode6vac0wad1ypnxawd26bcxakabxasbbcvaetvad{dNode6vac0wad3ypo`ixawc26dxakadxasadvaetwad0xawb26xaka6xasa6vaesva7{dNode6vac6va0{dNode6vac2va9{dNode6vac0wad1ypJxaw ^2709406a9bb19e8d83a78f81e36244xaka9xas [9406a9bb19e8d83a78f81e36244vaetvae{dNode6vac0wad1ypxxawd270exakaexasaevaetwad0xawc270xaka0xasa0vaesva1{dNode6vac0wad1ypxawe2713fxaka1xasc13fvaetva2{dNode6vac0wad1ypmxawf27291cxaka2xasd291cvaetva7{dNode6vac3va5{dNode6vac0wad1ypzxaw U277538367f9c8140e3a75xaka5xas R538367f9c8140e3a75vaetva6{dNode6vac0wad1ypsxawl27766eadc9e2xaka6xasi66eadc9e2vaetvaf{dNode6vac0wad1yp}xawd277fxakafxasafvaetwad0xawc277xaka7xasa7vaesvae{dNode6vac0wad1ypxxawc27exakaexasaevaetvaf{dNode6vac0wad1ypzxawd27fexakafxasbfevaetwad0xawb27xaka7xasa7vaesva8{dNode6vac:va2{dNode6vac1vab{dNode6vac0wad1yp^xawg2824befxakabxascbefvaetwad1yp~xawd2824xaka2xasb24vaetva4{dNode6vac0wad1ypfxawd2845xaka4xasb45vaetva6{dNode6vac0wad1yp[xawd286axaka6xasb6avaetva8{dNode6vac2va0{dNode6vac0wad1ypcxawg28808dcxaka0xasd08dcvaetva1{dNode6vac0wad1ypRxawh28811a94xaka1xase11a94vaetwad0xawc288xaka8xasa8vaesva9{dNode6vac0wad1ypNxawc289xaka9xasa9vaetvad{dNode6vac0wad1ypJxawc28dxakadxasadvaetvab{dNode6vac0wad2yppnxawc28bxakabxasabvaetvac{dNode6vac0wad1ypBxawc28cxakacxasacvaetvaf{dNode6vac1vaa{dNode6vac0wad1ypGxawd28faxakaaxasaavaetwad1ypixawc28fxakafxasafvaetvaa{dNode6vac0wad1ypnxawc28axakaaxasaavaetwad0xawb28xaka8xasa8vaesva9{dNode6vac;va1{dNode6vac0wad1yp{xawd2915xaka1xasb15vaetva2{dNode6vac1va6{dNode6vac0wad1ypxxawf29265axaka6xasc65avaetwad1ypLxawc292xaka2xasa2vaetva3{dNode6vac0wad1ypVxawc293xaka3xasa3vaetva4{dNode6vac0wad1ypoxawg294550cxaka4xase4550cvaetva6{dNode6vac2va1{dNode6vac0wad1ypuxawg296318cxaka1xasc18cvaetvad{dNode6vac0wad1yp]xawe2963dxakadxasadvaetwad0xawd2963xaka6xasb63vaesva8{dNode6vac1va1{dNode6vac0wad1ypyxawm2981057642b69xaka1xasj1057642b69vaetwad1ypvxawc298xaka8xasa8vaetva9{dNode6vac1vaa{dNode6vac0wad1ypbxaw `299abcee56b05b312ed5700f686f79b8xakaaxas ]abcee56b05b312ed5700f686f79b8vaetwad1ypgxawc299xaka9xasa9vaetvab{dNode6vac0wad1ypHxawc29bxakabxasabvaetvad{dNode6vac0wad1ypBxawd29dbxakadxasbdbvaetvac{dNode6vac0wad2yphyxawc29cxakacxasacvaetvaf{dNode6vac0wad1ypsxawc29fxakafxasafvaetwad0xawb29xaka9xasa9vaesvac{dNode6vac0wad1ypIxawb2cxakacxasacvaetvae{dNode6vac0wad1ypUxawc2eaxakaexasbeavaetvad{dNode6vac0wad1ypDxawc2dexakadxasbdevaetvaa{dNode6vac0wad1ypHxawb2axakaaxasaavaetvaf{dNode6vac0wad1ypAxawc2f1xakafxasbf1vaet>wad<ypQVZ_PS[bgmvwx}}~GJJKLMZ\mnovFHMNOZ]flmtwALQRfinNQSS__`jtuwx{}MT]_bcfk~~DL>xawa2xaka2xasa2vaetva3{dNode6vac<va0{dNode6vac<va1{dNode6vac1va1{dNode6vac0wad1ypWxaw P301194bfeeee4377xaka1xasm194bfeeee4377vaetwad1ypexawc301xaka1xasa1vaetva2{dNode6vac1va4{dNode6vac0wad1ypgxawf30242bxaka4xasc42bvaetwad1ypDxawc302xaka2xasa2vaetva3{dNode6vac0wad1ypRxawc303xaka3xasa3vaetva4{dNode6vac0wad1ypwxaw Y3042dad59a12e5937644f7246xaka4xas W42dad59a12e5937644f7246vaetva6{dNode6vac0wad1ypExawg306cecbxaka6xase6cecbvaetva7{dNode6vac0wad1ypqxawc307xaka7xasa7vaetva8{dNode6vac3va3{dNode6vac0wad1ypoxaw T308352b7a881add7e356xaka3xas Q352b7a881add7e356vaetva6{dNode6vac0wad1yp|xawn3086543790541cxaka6xask6543790541cvaetva9{dNode6vac0wad1ypqxaw Y308961666b15aa1e57b0f9f35xaka9xas V961666b15aa1e57b0f9f35vaetwad0xawc308xaka8xasa8vaesva9{dNode6vac0wad1ypDxawc309xaka9xasa9vaetvad{dNode6vac0wad1yp^xawc30dxakadxasadvaetvae{dNode6vac0wad1ypixawe30eebxakaexasceebvaetvaa{dNode6vac0wad1ypvxawc30axakaaxasaavaetvaf{dNode6vac0wad1ypTxawe30fddxakafxascfddvaet>wad1yp_xawb30xaka0xasa0vaetva1{dNode6vac9va1{dNode6vac0wad1ypxxawf31128axaka1xasd128avaetva3{dNode6vac0wad1yp{xawf31310bxaka3xasd310bvaetva4{dNode6vac0wad1ypYxawc314xaka4xasa4vaetva5{dNode6vac0wad1ypDxaw T31500621ecd6d3917a07xaka5xas R500621ecd6d3917a07vaetva6{dNode6vac0wad1ypmxawf31685exaka6xasd685evaetva8{dNode6vac0wad1ypixawc318xaka8xasa8vaetva9{dNode6vac2va5{dNode6vac0wad1ypxawg319052bxaka5xasc52bvaetvac{dNode6vac0wad1ypdxawe3190cxakacxasacvaetwad0xawd3190xaka9xasb90vaesvab{dNode6vac0wad3ypQ\rxawc31bxakabxasabvaetvad{dNode6vac1vab{dNode6vac0wad1ypMxawd31dbxakabxasabvaetwad1ypfxawc31dxakadxasadvaetwad0xawb31xaka1xasa1vaesva2{dNode6vac8va1{dNode6vac1va1{dNode6vac0wad1yp]xawd3211xaka1xasa1vaetwad1ypxawc321xaka1xasa1vaetva2{dNode6vac3va2{dNode6vac0wad1ypexaw `322264a17ef7182eb1475bd2eaebc2ebxaka2xas ]264a17ef7182eb1475bd2eaebc2ebvaetva7{dNode6vac0wad1ypnxawg3227411xaka7xasd7411vaetva8{dNode6vac0wad1ypwxawf32287exaka8xasc87evaetwad1yp{xawc322xaka2xasa2vaetva3{dNode6vac1va2{dNode6vac0wad1ypExaw Y32320ead508346ad8fed3394dxaka2xas V20ead508346ad8fed3394dvaetwad1ypmxawc323xaka3xasa3vaetva7{dNode6vac0wad1ypIxawd3270xaka7xasb70vaetva9{dNode6vac0wad1ypLxawe3295bxaka9xasc95bvaetvab{dNode6vac0wad2ypOWxawc32bxakabxasabvaetvaa{dNode6vac0wad2ypXcxawc32axakaaxasaavaetvac{dNode6vac2vaa{dNode6vac0wad1ypGxawf32cabaxakaaxascabavaetvad{dNode6vac0wad1yphxawh32cdcee2xakadxasedcee2vaetwad0xawc32cxakacxasacvaeswad1ypIxawb32xaka2xasa2vaetva3{dNode6vac9va0{dNode6vac0wad1ypDxawh330045fexaka0xasf0045fevaetva1{dNode6vac0wad1yp\xaw W33182579cd3edd0ac6c7c44xaka1xas U182579cd3edd0ac6c7c44vaetva3{dNode6vac1va7{dNode6vac0wad1ypjxaw \33371dcff207fd7d201128df2ea3xaka7xas Y71dcff207fd7d201128df2ea3vaetwad1yplxawc333xaka3xasa3vaetva8{dNode6vac2va1{dNode6vac0wad1yp[xaw Q338132d23b9112805xaka1xasn132d23b9112805vaetva4{dNode6vac0wad1ypTxawd3384xaka4xasa4vaetwad0xawc338xaka8xasa8vaesva9{dNode6vac0wad1ypNxawf33919exaka9xasd919evaetvae{dNode6vac0wad2ypwDxawc33exakaexasaevaetvaf{dNode6vac0wad1ypAxawc33fxakafxasafvaetvac{dNode6vac0wad2ypu[xawc33cxakacxasacvaetvaa{dNode6vac0wad1ypHxawc33axakaaxasaavaetwad0xawb33xaka3xasa3vaesva4{dNode6vac7va5{dNode6vac0wad1ypHxawi345200f90xaka5xasg5200f90vaetva7{dNode6vac0wad1yprxawf34780fxaka7xasd780fvaetva8{dNode6vac2va0{dNode6vac0wad1ypxawg348051bxaka0xasd051bvaetva5{dNode6vac0wad1ypmxawe34850xaka5xasb50vaetwad0xawc348xaka8xasa8vaesva9{dNode6vac0wad1ypxxawc349xaka9xasa9vaetvad{dNode6vac1vab{dNode6vac0wad1ypaxawe34dbdxakabxasbbdvaetwad1yppxawc34dxakadxasadvaetvab{dNode6vac0wad1ypmxawd34baxakabxasbbavaetvac{dNode6vac0wad1ypuxawc34cxakacxasacvaetwad0xawb34xaka4xasa4vaesva5{dNode6vac8va0{dNode6vac0wad1ypnxawc350xaka0xasa0vaetva1{dNode6vac0wad2ypwexawc351xaka1xasa1vaetva2{dNode6vac2va0{dNode6vac0wad1yp^xaw `35200cbf0b5b45d7f5f0b343cb18868bxaka0xas ]00cbf0b5b45d7f5f0b343cb18868bvaetva8{dNode6vac0wad1ypcxaw Z352847c06e748b345e8ed0738bxaka8xas W847c06e748b345e8ed0738bvaetwad0xawc352xaka2xasa2vaesva3{dNode6vac0wad1yp{xawc353xaka3xasa3vaetva6{dNode6vac0wad1ypixawc356xaka6xasa6vaetva8{dNode6vac0wad1ypvxawh35896c1fxaka8xasf896c1fvaetvaa{dNode6vac1vaa{dNode6vac0wad1yphxawd35aaxakaaxasaavaetwad1yp_xawc35axakaaxasaavaetvad{dNode6vac0wad1ypYxawc35dxakadxasadvaetwad2ypQ]xawb35xaka5xasa5vaetva6{dNode6vac7va0{dNode6vac2va6{dNode6vac0wad1yppxaw Q3606427f835bd3ddfxaka6xasn6427f835bd3ddfvaetva8{dNode6vac0wad1ypCxawf36080bxaka8xasc80bvaetwad0xawc360xaka0xasa0vaesva2{dNode6vac1va0{dNode6vac0wad1ypcxawh362098fcxaka0xase098fcvaetwad1yp\xawc362xaka2xasa2vaetva5{dNode6vac0wad1ypexawc365xaka5xasa5vaetvad{dNode6vac1vad{dNode6vac0wad1ypCxawd36ddxakadxasadvaetwad2yp[lxawc36dxakadxasadvaetvae{dNode6vac1vae{dNode6vac0wad1ypJxawg36eeceaxakaexasdeceavaetwad1yptxawc36exakaexasaevaetvaa{dNode6vac0wad1ypAxawc36axakaaxasaavaetvaf{dNode6vac0wad1yp]xawd36ffxakafxasbffvaetwad0xawb36xaka6xasa6vaesva7{dNode6vac9va0{dNode6vac0wad1ypAxawe3703dxaka0xasc03dvaetva3{dNode6vac2va3{dNode6vac0wad1yp[xaw W373398d7d2c93862c5f6661xaka3xas T398d7d2c93862c5f6661vaetva7{dNode6vac0wad1ypXxawd3737xaka7xasa7vaetwad1ypBxawc373xaka3xasa3vaetva6{dNode6vac0wad1ypSxaw \3760395e8e0eb40e335b22750b68xaka6xas Z60395e8e0eb40e335b22750b68vaetva7{dNode6vac0wad1ypQxawg37781dcxaka7xase781dcvaetva9{dNode6vac2va1{dNode6vac0wad1ypyxawe37912xaka1xasb12vaetva7{dNode6vac0wad1ypZxawe3797exaka7xasb7evaetwad0xawc379xaka9xasa9vaesvaf{dNode6vac0wad3ypjtJxawc37fxakafxasafvaetvad{dNode6vac0wad1ypqxawc37dxakadxasadvaetvac{dNode6vac2vae{dNode6vac0wad1yp]xawe37cedxakaexasbedvaetvaf{dNode6vac0wad1ypyxawd37cfxakafxasafvaetwad0xawc37cxakacxasacvaesvab{dNode6vac0wad1yp{xawc37bxakabxasabvaetwad0xawb37xaka7xasa7vaesva8{dNode6vac8va1{dNode6vac2va1{dNode6vac0wad1ypExawd3811xaka1xasa1vaetva2{dNode6vac0wad1ypfxawe38128xaka2xasb28vaetwad0xawc381xaka1xasa1vaesva2{dNode6vac0wad1yp@xawd3829xaka2xasb29vaetva3{dNode6vac0wad1ypGxaw P38322355e9c2471exaka3xasn322355e9c2471evaetva6{dNode6vac1vad{dNode6vac0wad1yphxawe386dcxakadxasbdcvaetwad1ypYxawc386xaka6xasa6vaetva8{dNode6vac2va4{dNode6vac0wad1ypvxawg3884abcxaka4xasd4abcvaetva6{dNode6vac0wad1ypxxawg38866cexaka6xasd66cevaetwad1ypZxawc388xaka8xasa8vaetva9{dNode6vac0wad2ypOjxawc389xaka9xasa9vaetvab{dNode6vac0wad1ypTxawe38bebxakabxascbebvaetvaf{dNode6vac0wad1ypsxawe38fbcxakafxascfbcvaetwad0xawb38xaka8xasa8vaesva9{dNode6vac8va1{dNode6vac0wad1ypNxaw W39194824861a134567cadb8xaka1xas U194824861a134567cadb8vaetva3{dNode6vac0wad1ypCxawi3931327edxaka3xasg31327edvaetva6{dNode6vac3va5{dNode6vac0wad1yphxawe3965fxaka5xasb5fvaetva7{dNode6vac0wad1ypLxawd3967xaka7xasa7vaetva9{dNode6vac0wad1ypexawf39698fxaka9xasc98fvaetwad0xawc396xaka6xasa6vaesva7{dNode6vac0wad1ypJxawd3979xaka7xasb79vaetva8{dNode6vac0wad1yp]xaw Z398056eef1cf6caa90786b340axaka8xas X8056eef1cf6caa90786b340avaetva9{dNode6vac1va0{dNode6vac0wad1ypxawe39905xaka0xasb05vaetwad2yp]Gxawc399xaka9xasa9vaetvaf{dNode6vac0wad1ypDxawc39fxakafxasafvaetvaa{dNode6vac0wad1ypxawc39axakaaxasaavaetwad0xawb39xaka9xasa9vaesvac{dNode6vac0wad3ypwgxawb3cxakacxasacvaetvaf{dNode6vac2vad{dNode6vac0wad1ypxxawc3fdxakadxasadvaetvac{dNode6vac0wad1ypPxawc3fcxakacxasacvaetwad1ypTxawb3fxakafxasafvaet>wad<ypVV\Relnoquy}~CKLLRT[[\bcdefopsBGLMYmuvBEGHI\nwABFIILPS`fpwDKQTTT_eknrxCCDDDIQ>xawa3xaka3xasa3vaetva4{dNode6vac<va0{dNode6vac:va0{dNode6vac2va2{dNode6vac0wad1ypXxawd4002xaka2xasa2vaetva3{dNode6vac0wad1ypOxawe4003dxaka3xasb3dvaetwad1ypexawc400xaka0xasa0vaetva2{dNode6vac0wad1ypgxawh402875d2xaka2xasf2875d2vaetva3{dNode6vac1va6{dNode6vac0wad1ypfxawh403679bdxaka6xase679bdvaetwad1ypYxawc403xaka3xasa3vaetva5{dNode6vac0wad1ypPxawc405xaka5xasa5vaetva7{dNode6vac1va2{dNode6vac0wad1ypExawi40721f7caxaka2xasf21f7cavaetwad2yphnxawc407xaka7xasa7vaetva9{dNode6vac0wad1ypQxawc409xaka9xasa9vaetvad{dNode6vac0wad1yp_xawc40dxakadxasadvaetvaa{dNode6vac0wad1ypVxawf40abeaxakaaxasdabeavaetvac{dNode6vac0wad2ypJyxawc40cxakacxasacvaetvaf{dNode6vac0wad1ypzxawd40ffxakafxasbffvaetwad1ypmxawb40xaka0xasa0vaetva1{dNode6vac:va0{dNode6vac0wad1yp|xawc410xaka0xasa0vaetva2{dNode6vac0wad1ypExawf41286exaka2xasd286evaetva3{dNode6vac0wad1ypoxaw Q4136446bebe7ffbc7xaka3xaso36446bebe7ffbc7vaetva4{dNode6vac0wad1yp{xawc414xaka4xasa4vaetva5{dNode6vac0wad2ypRUxawc415xaka5xasa5vaetva7{dNode6vac1va1{dNode6vac0wad1ypfxaw P41712823a5d6002bxaka1xasm12823a5d6002bvaetwad1ypGxawc417xaka7xasa7vaetva8{dNode6vac2va7{dNode6vac0wad1ypExaw ]418764dca70aebfc965899a3fa7e5xaka7xas Z764dca70aebfc965899a3fa7e5vaetva8{dNode6vac0wad1ypYxaw T418849e1f4200ade9535xaka8xas Q849e1f4200ade9535vaetwad1ypnxawc418xaka8xasa8vaetvae{dNode6vac1vab{dNode6vac0wad1yp\xawe41ebcxakabxasbbcvaetwad1ypUxawc41exakaexasaevaetvac{dNode6vac1vac{dNode6vac0wad1ypCxawd41ccxakacxasacvaetwad1ypaxawc41cxakacxasacvaetvab{dNode6vac0wad1ypzxawc41bxakabxasabvaetwad0xawb41xaka1xasa1vaesva2{dNode6vac7va1{dNode6vac2va4{dNode6vac0wad1ypQxawi42144a7dexaka4xasf44a7devaetva8{dNode6vac0wad1ypNxawg42182cfxaka8xasd82cfvaetwad1ypkxawc421xaka1xasa1vaetva3{dNode6vac0wad1ypCxawc423xaka3xasa3vaetva6{dNode6vac0wad1ypdxawc426xaka6xasa6vaetva9{dNode6vac0wad1ypRxaw U429863f89da313fffed97xaka9xas S9863f89da313fffed97vaetvab{dNode6vac2vac{dNode6vac0wad1ypTxawd42bcxakacxasacvaetvae{dNode6vac0wad1ypKxawd42bexakaexasaevaetwad0xawc42bxakabxasabvaesvac{dNode6vac0wad1ypBxawc42cxakacxasacvaetvaa{dNode6vac2vad{dNode6vac0wad1ypaxawd42adxakadxasadvaetvab{dNode6vac0wad1ypuxawd42abxakabxasabvaetwad0xawc42axakaaxasaavaeswad1ypnxawb42xaka2xasa2vaetva3{dNode6vac:va1{dNode6vac1va8{dNode6vac3va1{dNode6vac0wad1yphxawi431816573xaka1xase16573vaetva7{dNode6vac0wad1ypYxawh431877cexaka7xasd77cevaetvae{dNode6vac0wad1ypTxaw U4318eaa2ffbca3510c054xakaexas Qeaa2ffbca3510c054vaetwad0xawd4318xaka8xasa8vaeswad1ypTxawc431xaka1xasa1vaetva2{dNode6vac0wad1ypxxawc432xaka2xasa2vaetva3{dNode6vac0wad1ypvxawc433xaka3xasa3vaetva5{dNode6vac1va0{dNode6vac0wad1ypoxaw `43501cdf0de25278a208cbb9aad80012xaka0xas ]01cdf0de25278a208cbb9aad80012vaetwad1ypDxawc435xaka5xasa5vaetva8{dNode6vac0wad1ypaxawd4389xaka8xasb89vaetvac{dNode6vac2vaa{dNode6vac0wad1ypaxawf43caefxakaaxascaefvaetvac{dNode6vac0wad1ypbxawd43ccxakacxasacvaetwad1ypwxawc43cxakacxasacvaetvab{dNode6vac1vac{dNode6vac0wad1ypDxawd43bcxakacxasacvaetwad1ypMxawc43bxakabxasabvaetvaf{dNode6vac2vac{dNode6vac0wad1yp_xawe43fcexakacxasbcevaetvaf{dNode6vac0wad1ypJxawd43ffxakafxasafvaetwad0xawc43fxakafxasafvaesvaa{dNode6vac1vab{dNode6vac0wad1ypyxawd43abxakabxasabvaetwad1ypwxawc43axakaaxasaavaetvad{dNode6vac0wad1yp_xawc43dxakadxasadvaetwad0xawb43xaka3xasa3vaesva4{dNode6vac8va2{dNode6vac0wad1ypGxaw V44285ded812939553ef94cxaka2xas T285ded812939553ef94cvaetva3{dNode6vac0wad1ypJxawc443xaka3xasa3vaetva4{dNode6vac0wad2ypUFxawc444xaka4xasa4vaetva8{dNode6vac2va3{dNode6vac0wad1ypZxawe4483bxaka3xasb3bvaetva7{dNode6vac0wad1ypBxawf44878bxaka7xasc78bvaetwad0xawc448xaka8xasa8vaesva9{dNode6vac0wad1yp~xaw Y44931bfefab991be3dd7a08b7xaka9xas W931bfefab991be3dd7a08b7vaetvad{dNode6vac2vaf{dNode6vac0wad1yp]xawe44dfdxakafxasbfdvaetvab{dNode6vac0wad2ypJOxawd44dbxakabxasabvaetwad0xawc44dxakadxasadvaesvac{dNode6vac0wad1ypvxawe44cafxakacxasccafvaetvaf{dNode6vac0wad1ypYxawc44fxakafxasafvaetwad0xawb44xaka4xasa4vaesva5{dNode6vac:va0{dNode6vac0wad1ypUxawd4502xaka0xasb02vaetva1{dNode6vac0wad1ypTxawk4510813f36axaka1xasi10813f36avaetva3{dNode6vac0wad1ypLxawh45353291xaka3xasf353291vaetva4{dNode6vac3va0{dNode6vac0wad1ypaxawn4540ecaa37d0e3xaka0xask0ecaa37d0e3vaetva3{dNode6vac0wad1yphxawe4543exaka3xasb3evaetva6{dNode6vac0wad1ypixawg454658fxaka6xasd658fvaetwad0xawc454xaka4xasa4vaesva5{dNode6vac1va5{dNode6vac0wad1ypIxawd4555xaka5xasa5vaetwad1ypIxawc455xaka5xasa5vaetva8{dNode6vac0wad1ypixawd4581xaka8xasb81vaetva9{dNode6vac0wad4ypccuxawc459xaka9xasa9vaetvaa{dNode6vac0wad1ypdxawd45acxakaaxasbacvaetvae{dNode6vac0wad1yp[xawc45exakaexasaevaetvad{dNode6vac1vad{dNode6vac0wad1ypwxawe45dddxakadxasadvaetwad1ypVxawd45ddxakadxasbddvaetwad0xawb45xaka5xasa5vaesva6{dNode6vac:va1{dNode6vac0wad1ypMxaw `4616fbea6a6dbc1074bc3f1016bbc73bxaka1xas ^16fbea6a6dbc1074bc3f1016bbc73bvaetva2{dNode6vac0wad1ypjxawg462405exaka2xase2405evaetva3{dNode6vac0wad1ypCxawc463xaka3xasa3vaetva4{dNode6vac0wad1ypNxawc464xaka4xasa4vaetva5{dNode6vac2va0{dNode6vac0wad1yp`xawh465087cfxaka0xase087cfvaetva6{dNode6vac0wad1yp^xaw T4656498e5972c6de7e3dxaka6xas Q6498e5972c6de7e3dvaetwad2yp~Wxawc465xaka5xasa5vaetva6{dNode6vac0wad2ypsIxawc466xaka6xasa6vaetva7{dNode6vac0wad1ypsxawe4677axaka7xasc77avaetva9{dNode6vac0wad1yp|xawe4690dxaka9xasc90dvaetvae{dNode6vac0wad1ypYxawc46exakaexasaevaetvab{dNode6vac0wad1ypHxawd46bexakabxasbbevaetwad0xawb46xaka6xasa6vaesva7{dNode6vac:va0{dNode6vac0wad1ypQxawc470xaka0xasa0vaetva2{dNode6vac0wad1ypYxawi4726484bexaka2xasg26484bevaetva3{dNode6vac2va5{dNode6vac0wad1ypMxaw ]47355cbe966a94826cbe2fbf2b355xaka5xas Z55cbe966a94826cbe2fbf2b355vaetva9{dNode6vac0wad1ypfxawf47398axaka9xasc98avaetwad0xawc473xaka3xasa3vaesva4{dNode6vac0wad1yppxawe4744exaka4xasc44evaetva5{dNode6vac0wad2yp|jxawc475xaka5xasa5vaetva6{dNode6vac0wad1ypSxawd476exaka6xasb6evaetva9{dNode6vac1va6{dNode6vac0wad1ypOxawd4796xaka6xasa6vaetwad2yp`]xawc479xaka9xasa9vaetvad{dNode6vac0wad3ypTdoxawc47dxakadxasadvaetvac{dNode6vac0wad1ypYxawd47cbxakacxasbcbvaetvaf{dNode6vac0wad1ypzxawc47fxakafxasafvaetwad0xawb47xaka7xasa7vaesva8{dNode6vac9va1{dNode6vac0wad1ypJxawc481xaka1xasa1vaetva2{dNode6vac0wad3ypy_pxawc482xaka2xasa2vaetva4{dNode6vac0wad1ypgxawg48410cfxaka4xase410cfvaetva5{dNode6vac2va1{dNode6vac1va6{dNode6vac0wad1yp~xawf48516exaka6xasb6evaetwad1ypQxawd4851xaka1xasa1vaetva8{dNode6vac0wad1yp`xawd4858xaka8xasa8vaetwad0xawc485xaka5xasa5vaesva6{dNode6vac0wad1ypXxaw P486653fea1d0e39cxaka6xasn6653fea1d0e39cvaetvac{dNode6vac1vab{dNode6vac0wad1ypRxawd48cbxakabxasabvaetwad1ypDxawc48cxakacxasacvaetvab{dNode6vac0wad1ypWxawc48bxakabxasabvaetvad{dNode6vac0wad1ypixawc48dxakadxasadvaetvae{dNode6vac0wad1yp{xawd48ecxakaexasbecvaetwad0xawb48xaka8xasa8vaesva9{dNode6vac9va1{dNode6vac0wad1ypkxawc491xaka1xasa1vaetva2{dNode6vac0wad1yplxawd4924xaka2xasb24vaetva3{dNode6vac0wad1yprxawc493xaka3xasa3vaetva4{dNode6vac0wad1ypVxawh494557dbxaka4xasf4557dbvaetva7{dNode6vac0wad1ypRxawe4976fxaka7xasc76fvaetvae{dNode6vac2vaa{dNode6vac0wad1ypLxawd49eaxakaaxasaavaetvaf{dNode6vac0wad1ypyxawd49efxakafxasafvaetwad0xawc49exakaexasaevaesvac{dNode6vac0wad1ypMxawd49cexakacxasbcevaetvaa{dNode6vac0wad1ypuxawc49axakaaxasaavaetvab{dNode6vac0wad1ypJxawd49baxakabxasbbavaetwad0xawb49xaka9xasa9vaesvaa{dNode6vac2vad{dNode6vac0wad1ypjxawc4adxakadxasadvaetvaf{dNode6vac0wad1ypBxawe4afcbxakafxascfcbvaetwad2ypBixawb4axakaaxasaavaetvad{dNode6vac0wad3ypKFTxawb4dxakadxasadvaetvaf{dNode6vac1vab{dNode6vac0wad1ypQxawe4fbdcxakabxascbdcvaetwad2ypG]xawb4fxakafxasafvaetvab{dNode6vac0wad3ypQ\Oxawb4bxakabxasabvaetvac{dNode6vac1vac{dNode6vac0wad1yp[xawc4ccxakacxasacvaetwad1yphxawb4cxakacxasacvaetvae{dNode6vac0wad1ypXxawb4exakaexasaevaet>wad<ypUZU]aabcddlw}@RVV]dfgg||BDDHJ_ddlrrstvw{EGRRUZ\\`gnty|FOQ[_`abds{~DHIJMSUelq~~BDL>xawa4xaka4xasa4vaetva5{dNode6vac<va0{dNode6vac:va1{dNode6vac2va0{dNode6vac0wad1ypTxawd5010xaka0xasa0vaetva3{dNode6vac0wad1yppxawg501351dxaka3xasd351dvaetwad1yp}xawc501xaka1xasa1vaetva5{dNode6vac3va5{dNode6vac0wad1ypIxawf50557bxaka5xasc57bvaetva6{dNode6vac0wad1yp`xawf50562bxaka6xasc62bvaetva9{dNode6vac0wad1ypoxawg505985axaka9xasd985avaetwad2ypZbxawc505xaka5xasa5vaetva6{dNode6vac2va1{dNode6vac0wad1yp]xawg506143cxaka1xasd143cvaetva3{dNode6vac0wad1ypIxawd5063xaka3xasa3vaetwad0xawc506xaka6xasa6vaesva8{dNode6vac1va0{dNode6vac0wad1ypKxawf5080ecxaka0xasc0ecvaetwad1ypaxawc508xaka8xasa8vaetva9{dNode6vac1va3{dNode6vac0wad1ypUxawi5093670dfxaka3xasf3670dfvaetwad1yprxawc509xaka9xasa9vaetvae{dNode6vac0wad1ypyxawd50ebxakaexasbebvaetvad{dNode6vac0wad1ypHxawc50dxakadxasadvaetvaf{dNode6vac0wad2yppMxawc50fxakafxasafvaetvab{dNode6vac0wad1yphxawc50bxakabxasabvaetvac{dNode6vac0wad1ypfxawc50cxakacxasacvaetwad1ypDxawb50xaka0xasa0vaetva1{dNode6vac9va2{dNode6vac0wad1ypDxawc512xaka2xasa2vaetva3{dNode6vac0wad1yppxawd5132xaka3xasb32vaetva5{dNode6vac2va3{dNode6vac0wad1ypCxawn5153268e0cc1c1xaka3xask3268e0cc1c1vaetva7{dNode6vac0wad1ypixawd5157xaka7xasa7vaetwad0xawc515xaka5xasa5vaesva6{dNode6vac0wad1ypTxawd516axaka6xasb6avaetva7{dNode6vac0wad1ypnxawc517xaka7xasa7vaetva9{dNode6vac0wad1ypSxawe5197exaka9xasc97evaetvad{dNode6vac0wad1ypOxawd51dcxakadxasbdcvaetvae{dNode6vac2vac{dNode6vac0wad1yp[xawe51ecfxakacxasbcfvaetvad{dNode6vac0wad1ypqxaw Z51edead39c0e439073986043fbxakadxas Wdead39c0e439073986043fbvaetwad0xawc51exakaexasaevaesvac{dNode6vac2vac{dNode6vac0wad1ypmxawe51ccaxakacxasbcavaetvae{dNode6vac0wad1ypSxawd51cexakaexasaevaetwad0xawc51cxakacxasacvaeswad0xawb51xaka1xasa1vaesva2{dNode6vac6va1{dNode6vac1va9{dNode6vac1va9{dNode6vac0wad1ypMxawg521991exaka9xasc91evaetwad1yp\xawd5219xaka9xasa9vaetwad2yp|uxawc521xaka1xasa1vaetva2{dNode6vac0wad1yphxawc522xaka2xasa2vaetva6{dNode6vac0wad1yp_xawf52675bxaka6xasd675bvaetva7{dNode6vac3va3{dNode6vac0wad1ypyxaw P52735bbbe6ba65b0xaka3xasm35bbbe6ba65b0vaetva5{dNode6vac0wad1yp~xawf52758bxaka5xasc58bvaetva7{dNode6vac0wad1ypXxawf52779axaka7xasc79avaetwad0xawc527xaka7xasa7vaesva8{dNode6vac0wad1ypVxaw X52824555864d1106278cd1f0xaka8xas V824555864d1106278cd1f0vaetvaa{dNode6vac0wad2yp|gxawc52axakaaxasaavaetwad0xawb52xaka2xasa2vaesva3{dNode6vac7va1{dNode6vac0wad1ypUxawc531xaka1xasa1vaetva2{dNode6vac0wad1yprxawc532xaka2xasa2vaetva3{dNode6vac0wad1yp^xawd5339xaka3xasb39vaetva5{dNode6vac0wad1ypdxawc535xaka5xasa5vaetva6{dNode6vac0wad1yppxawc536xaka6xasa6vaetva8{dNode6vac1vae{dNode6vac0wad1ypsxawd538exakaexasaevaetwad1ypGxawc538xaka8xasa8vaetvae{dNode6vac0wad1ypxxawd53ecxakaexasbecvaetwad0xawb53xaka3xasa3vaesva4{dNode6vac8va1{dNode6vac0wad1ypbxawd5412xaka1xasb12vaetva3{dNode6vac0wad1ypIxawd5433xaka3xasb33vaetva4{dNode6vac0wad1ypXxawf54475cxaka4xasd475cvaetva7{dNode6vac0wad1ypYxawi54780edcbxaka7xasg780edcbvaetva9{dNode6vac2va3{dNode6vac0wad1ypQxawg5493b4dxaka3xasd3b4dvaetva5{dNode6vac0wad1ypnxawd5495xaka5xasa5vaetwad0xawc549xaka9xasa9vaesvaf{dNode6vac1vaf{dNode6vac0wad1ypaxawd54ffxakafxasafvaetwad2ypxpxawc54fxakafxasafvaetvae{dNode6vac0wad1ypExawc54exakaexasaevaetvad{dNode6vac0wad1ypyxawd54daxakadxasbdavaetwad0xawb54xaka4xasa4vaesva5{dNode6vac8va0{dNode6vac0wad1ypKxaw `550becdd08d00fb1e7fd00c2adc3d3d6xaka0xas ^0becdd08d00fb1e7fd00c2adc3d3d6vaetva1{dNode6vac0wad1ypixawf55188axaka1xasd188avaetva2{dNode6vac1va6{dNode6vac0wad1ypBxawf552660xaka6xasc660vaetwad1ypDxawc552xaka2xasa2vaetva8{dNode6vac2va3{dNode6vac0wad1ypWxawo5583eeb6eabbd51xaka3xasl3eeb6eabbd51vaetva8{dNode6vac0wad1ypPxaw T55885067fee629287e8axaka8xas Q85067fee629287e8avaetwad0xawc558xaka8xasa8vaesva9{dNode6vac0wad1ypnxawd5595xaka9xasb95vaetvad{dNode6vac0wad1ypJxawc55dxakadxasadvaetvac{dNode6vac0wad1ypuxawc55cxakacxasacvaetvab{dNode6vac0wad1ypNxawe55badxakabxascbadvaetwad2ypXRxawb55xaka5xasa5vaetva6{dNode6vac8va1{dNode6vac1va3{dNode6vac0wad1ypTxaw ^56132638912a1ca54fcf7cd38b8e23xaka3xas [32638912a1ca54fcf7cd38b8e23vaetwad2ypQXxawc561xaka1xasa1vaetva2{dNode6vac0wad1ypixawc562xaka2xasa2vaetva3{dNode6vac1va8{dNode6vac0wad1ypoxawg563864axaka8xasd864avaetwad1ypmxawc563xaka3xasa3vaetva5{dNode6vac0wad1ypfxawc565xaka5xasa5vaetvaf{dNode6vac0wad2ypQFxawc56fxakafxasafvaetvab{dNode6vac0wad1ypsxawc56bxakabxasabvaetvae{dNode6vac0wad1ypzxawc56exakaexasaevaetvad{dNode6vac0wad1ypLxawc56dxakadxasadvaetwad0xawb56xaka6xasa6vaesva7{dNode6vac<va0{dNode6vac0wad1ypuxawh570599cfxaka0xasf0599cfvaetva1{dNode6vac0wad1ypLxaw ]5711303378bd333ddb611a53ece94xaka1xas [11303378bd333ddb611a53ece94vaetva3{dNode6vac0wad1yp`xaw ^573488dec311655890a205aad4fb65xaka3xas \3488dec311655890a205aad4fb65vaetva4{dNode6vac2va2{dNode6vac0wad1ypxawd5742xaka2xasa2vaetva3{dNode6vac0wad1ypUxaw U5743226af94c1efaaa4a7xaka3xas R3226af94c1efaaa4a7vaetwad0xawc574xaka4xasa4vaesva5{dNode6vac2va6{dNode6vac0wad1ypuxawd5756xaka6xasa6vaetva8{dNode6vac0wad1ypzxawd5758xaka8xasa8vaetwad0xawc575xaka5xasa5vaesva6{dNode6vac2va5{dNode6vac0wad1yplxawj5765103d2dxaka5xasg5103d2dvaetva8{dNode6vac0wad1yp~xawf57684cxaka8xasc84cvaetwad0xawc576xaka6xasa6vaesva7{dNode6vac0wad1ypfxawd5777xaka7xasb77vaetva8{dNode6vac0wad1ypPxawe5785bxaka8xasc85bvaetva9{dNode6vac0wad1ypSxawc579xaka9xasa9vaetvaa{dNode6vac0wad3ypmQ}xawc57axakaaxasaavaetvad{dNode6vac2vad{dNode6vac0wad1ypmxawe57ddfxakadxasbdfvaetvae{dNode6vac0wad1ypcxawd57dexakaexasaevaetwad0xawc57dxakadxasadvaesvab{dNode6vac0wad1ypwxawc57bxakabxasabvaetvae{dNode6vac1vab{dNode6vac0wad1ypUxawd57ebxakabxasabvaetwad1ypmxawc57exakaexasaevaetvac{dNode6vac0wad1ypOxawd57ccxakacxasbccvaet>wad1ypwxawb57xaka7xasa7vaetva8{dNode6vac9va1{dNode6vac1va6{dNode6vac0wad1ypLxawe5816exaka6xasb6evaetwad1ypFxawc581xaka1xasa1vaetva2{dNode6vac2va4{dNode6vac0wad1ypxxawd5824xaka4xasa4vaetva6{dNode6vac0wad1ypExaw Y582642d9cbe500f018afab341xaka6xas V642d9cbe500f018afab341vaetwad1ypDxawc582xaka2xasa2vaetva3{dNode6vac0wad1yprxawc583xaka3xasa3vaetva4{dNode6vac0wad1ypcxawd584bxaka4xasb4bvaetva6{dNode6vac2va0{dNode6vac0wad1yptxawe5860bxaka0xasb0bvaetva4{dNode6vac0wad1ypPxawg58646cexaka4xasd46cevaetwad2yploxawc586xaka6xasa6vaetva7{dNode6vac2va1{dNode6vac0wad1ypzxawg58712faxaka1xasd12favaetva6{dNode6vac0wad1ypJxawf5876eaxaka6xasc6eavaetwad0xawc587xaka7xasa7vaesvac{dNode6vac0wad1ypVxawe58cbexakacxasccbevaetvaf{dNode6vac1vaf{dNode6vac0wad1ypfxawd58ffxakafxasafvaetwad1ypNxawc58fxakafxasafvaetvae{dNode6vac0wad2ypI[xawc58exakaexasaevaetwad0xawb58xaka8xasa8vaesva9{dNode6vac<va0{dNode6vac0wad1yp_xawc590xaka0xasa0vaetva1{dNode6vac0wad1ypVxaw `5912529cfd6ce14c5ede5c6c83dae7e8xaka1xas ^12529cfd6ce14c5ede5c6c83dae7e8vaetva3{dNode6vac0wad1ypBxawe5931fxaka3xasc31fvaetva4{dNode6vac0wad1yp[xaw W5945ece02fdc55d6cbcbc38xaka4xas U45ece02fdc55d6cbcbc38vaetva5{dNode6vac1va5{dNode6vac0wad1ypxawd5955xaka5xasa5vaetwad1ypYxawc595xaka5xasa5vaetva7{dNode6vac0wad1ypGxawc597xaka7xasa7vaetva8{dNode6vac0wad1ypRxawd5988xaka8xasb88vaetva9{dNode6vac0wad1ypixaw V5998989255253e15ccc1f6xaka9xas T98989255253e15ccc1f6vaetvab{dNode6vac1vac{dNode6vac0wad1ypWxawd59bcxakacxasacvaetwad1yp`xawc59bxakabxasabvaetvaa{dNode6vac1vad{dNode6vac0wad1ypZxawe59adcxakadxasbdcvaetwad1ypAxawc59axakaaxasaavaetvae{dNode6vac0wad1yp{xawc59exakaexasaevaetvad{dNode6vac0wad1ypGxawc59dxakadxasadvaet>wad0xawb59xaka9xasa9vaesvae{dNode6vac0wad1ypWxawf5eebdfxakaexaseeebdfvaetvaa{dNode6vac0wad2yp_Fxawb5axakaaxasaavaetvab{dNode6vac2vaa{dNode6vac0wad1ypzxawe5badfxakaaxascadfvaetvab{dNode6vac0wad1ypXxawc5bbxakabxasabvaetwad2ypwtxawb5bxakabxasabvaetvad{dNode6vac0wad1yppxawb5dxakadxasadvaet>wad<ypQVZaeegoqw}}~~QUVVVW_bdluuAHL[`qttuzBFQW]`gpx|}DHQ]q|~FFFIW]]bccfjklmx@CGQ>xawa5xaka5xasa5vaetva6{dNode6vac<va0{dNode6vac<va0{dNode6vac0wad1ypCxawf60076cxaka0xasd076cvaetva1{dNode6vac0wad1ypnxawc601xaka1xasa1vaetva2{dNode6vac0wad1ypFxawc602xaka2xasa2vaetva4{dNode6vac0wad2ypOUxawc604xaka4xasa4vaetva5{dNode6vac0wad2ypjQxawc605xaka5xasa5vaetva6{dNode6vac0wad1ypzxawi6065960ebxaka6xasg65960ebvaetva7{dNode6vac0wad1ypGxawc607xaka7xasa7vaetva8{dNode6vac2va1{dNode6vac0wad1yp@xawh608108bexaka1xase108bevaetva6{dNode6vac0wad1ypGxawl60865046ff05xaka6xasi65046ff05vaetwad0xawc608xaka8xasa8vaesva9{dNode6vac2va3{dNode6vac0wad1ypbxawe6093exaka3xasb3evaetva8{dNode6vac0wad1ypCxawl6098086e255fxaka8xasi8086e255fvaetwad0xawc609xaka9xasa9vaesvae{dNode6vac2vac{dNode6vac0wad1ypHxawd60ecxakacxasacvaetvaf{dNode6vac0wad1ypNxawe60efexakafxasbfevaetwad1yp`xawc60exakaexasaevaetvaf{dNode6vac0wad1yplxawc60fxakafxasafvaetvaa{dNode6vac0wad1ypRxawd60adxakaaxasbadvaetvad{dNode6vac1vac{dNode6vac0wad1ypvxawd60dcxakacxasacvaetwad1ypaxawc60dxakadxasadvaet>wad0xawb60xaka0xasa0vaesva1{dNode6vac<va0{dNode6vac0wad1ypMxawg61066efxaka0xase066efvaetva1{dNode6vac0wad1yppxawh61173291xaka1xasf173291vaetva5{dNode6vac0wad1yplxawe615dbxaka5xasc5dbvaetva6{dNode6vac0wad1ypyxawc616xaka6xasa6vaetva7{dNode6vac0wad2yp@wxawc617xaka7xasa7vaetva8{dNode6vac2va2{dNode6vac0wad1ypzxawf61827exaka2xasc27evaetva3{dNode6vac0wad1ypgxawg61831fdxaka3xasd31fdvaetwad0xawc618xaka8xasa8vaesva9{dNode6vac2va3{dNode6vac0wad1ypyxawd6193xaka3xasa3vaetva4{dNode6vac0wad1yp[xawe6194cxaka4xasb4cvaetwad0xawc619xaka9xasa9vaesvac{dNode6vac2vac{dNode6vac0wad1ypPxawg61ccffdxakacxasdcffdvaetvae{dNode6vac0wad1ypDxawd61cexakaexasaevaetwad2yp_oxawc61cxakacxasacvaetvab{dNode6vac0wad1yphxawc61bxakabxasabvaetvad{dNode6vac0wad2ypQyxawc61dxakadxasadvaetvae{dNode6vac1vac{dNode6vac0wad1ypzxawe61ecbxakacxasbcbvaetwad1ypsxawc61exakaexasaevaetvaf{dNode6vac1vad{dNode6vac0wad1yp^xawd61fdxakadxasadvaetwad1yp\xawc61fxakafxasafvaet>wad2ypxLxawb61xaka1xasa1vaetva2{dNode6vac<va1{dNode6vac0wad1ypgxaw S6217243f3c387ea18b7xaka1xas Q17243f3c387ea18b7vaetva2{dNode6vac0wad1yp{xawc622xaka2xasa2vaetva3{dNode6vac0wad2ypPRxawc623xaka3xasa3vaetva4{dNode6vac0wad1yp@xawf62477exaka4xasd477evaetva5{dNode6vac0wad1ypmxawc625xaka5xasa5vaetva6{dNode6vac1va8{dNode6vac0wad1yp}xawg62680eaxaka8xasd80eavaetwad1ypTxawc626xaka6xasa6vaetva7{dNode6vac0wad1ypVxawd627axaka7xasb7avaetva8{dNode6vac0wad1yp|xawc628xaka8xasa8vaetvac{dNode6vac1vab{dNode6vac0wad1ypvxawd62cbxakabxasabvaetwad1ypXxawc62cxakacxasacvaetvad{dNode6vac0wad2ypNsxawc62dxakadxasadvaetvab{dNode6vac0wad1ypUxawc62bxakabxasabvaetvaf{dNode6vac0wad2yp\xxawc62fxakafxasafvaetvaa{dNode6vac0wad1ypRxawc62axakaaxasaavaet>wad1ypBxawb62xaka2xasa2vaetva3{dNode6vac7va2{dNode6vac2va4{dNode6vac0wad1ypUxawd6324xaka4xasa4vaetva9{dNode6vac0wad1ypSxawg6329ecbxaka9xasd9ecbvaetwad0xawc632xaka2xasa2vaesva4{dNode6vac0wad1ypcxawc634xaka4xasa4vaetva5{dNode6vac0wad1yphxawd6357xaka5xasb57vaetva7{dNode6vac0wad1ypYxawc637xaka7xasa7vaetva8{dNode6vac0wad1yp|xawc638xaka8xasa8vaetva9{dNode6vac2va4{dNode6vac0wad1ypRxawm639481524ee80xaka4xasj481524ee80vaetva7{dNode6vac0wad1ypBxaw R63976e9eec38cab0f5xaka7xaso76e9eec38cab0f5vaetwad0xawc639xaka9xasa9vaesvae{dNode6vac0wad1ypxxawc63exakaexasaevaetwad1ypJxawb63xaka3xasa3vaetva4{dNode6vac:va0{dNode6vac0wad1ypmxawg640616fxaka0xase0616fvaetva1{dNode6vac0wad2ypjlxawc641xaka1xasa1vaetva2{dNode6vac0wad1ypqxawd6425xaka2xasb25vaetva5{dNode6vac0wad1ypxawd6458xaka5xasb58vaetva7{dNode6vac0wad2yphAxawc647xaka7xasa7vaetva9{dNode6vac2va0{dNode6vac0wad1ypQxawd6490xaka0xasa0vaetvaf{dNode6vac0wad1ypuxawd649fxakafxasafvaetwad0xawc649xaka9xasa9vaesvaa{dNode6vac0wad3ypSkHxawc64axakaaxasaavaetvac{dNode6vac1vad{dNode6vac0wad1ypPxawg64cdfccxakadxasddfccvaetwad1ypZxawc64cxakacxasacvaetvad{dNode6vac0wad3ypswIxawc64dxakadxasadvaetvab{dNode6vac0wad1ypVxawd64bdxakabxasbbdvaetwad0xawb64xaka4xasa4vaesva5{dNode6vac7va1{dNode6vac2va2{dNode6vac0wad1ypaxawh65124517xaka2xase24517vaetva8{dNode6vac0wad1ypExaw R651887aac4eb17f9f0xaka8xaso887aac4eb17f9f0vaetwad0xawc651xaka1xasa1vaesva3{dNode6vac0wad1ypdxawe6532exaka3xasc32evaetva4{dNode6vac0wad1ypfxawi65453a1aexaka4xasg453a1aevaetva6{dNode6vac1va7{dNode6vac0wad1yp\xawd6567xaka7xasa7vaetwad1ypsxawc656xaka6xasa6vaetva7{dNode6vac0wad1ypAxawc657xaka7xasa7vaetvae{dNode6vac0wad2ypPSxawc65exakaexasaevaetvaf{dNode6vac0wad1ypxawd65ffxakafxasbffvaetwad0xawb65xaka5xasa5vaesva6{dNode6vac8va3{dNode6vac2va0{dNode6vac0wad1yplxawe6630axaka0xasb0avaetva9{dNode6vac0wad1ypRxawd6639xaka9xasa9vaetwad0xawc663xaka3xasa3vaesva4{dNode6vac0wad1ypkxawc664xaka4xasa4vaetva7{dNode6vac0wad1ypbxawd6670xaka7xasb70vaetva8{dNode6vac0wad1ypqxaw Q66891554b66b2cdedxaka8xaso891554b66b2cdedvaetva9{dNode6vac0wad1ypFxawf66950bxaka9xasd950bvaetvad{dNode6vac1vab{dNode6vac0wad1yp_xawd66dbxakabxasabvaetwad2yp}Zxawc66dxakadxasadvaetvaa{dNode6vac0wad2ypFBxawc66axakaaxasaavaetvaf{dNode6vac0wad1ypyxawc66fxakafxasafvaetwad2ypDyxawb66xaka6xasa6vaetva7{dNode6vac9va0{dNode6vac0wad1ypcxawg670744bxaka0xase0744bvaetva1{dNode6vac0wad1ypcxawc671xaka1xasa1vaetva3{dNode6vac0wad1yp\xawh673436acxaka3xasf3436acvaetva5{dNode6vac0wad1yppxaw T6752dfce5a0235354070xaka5xas R52dfce5a0235354070vaetva6{dNode6vac0wad1yp_xawd6761xaka6xasb61vaetvac{dNode6vac0wad1yp_xawc67cxakacxasacvaetvaf{dNode6vac1vac{dNode6vac2vac{dNode6vac0wad1yphxaw R67fccabee27a6e99cdxakacxasncabee27a6e99cdvaetvaa{dNode6vac0wad1ypDxawe67fcaxakaaxasaavaetwad0xawd67fcxakacxasacvaeswad3yplmyxawc67fxakafxasafvaetvab{dNode6vac0wad1ypIxawc67bxakabxasabvaetvae{dNode6vac0wad2yphbxawc67exakaexasaevaetwad0xawb67xaka7xasa7vaesva8{dNode6vac7va2{dNode6vac0wad1ypkxawl68210e6fad4fxaka2xasj210e6fad4fvaetva3{dNode6vac0wad1ypMxawd6833xaka3xasb33vaetva7{dNode6vac1va2{dNode6vac0wad1ypxawh687271a1xaka2xase271a1vaetwad1ypOxawc687xaka7xasa7vaetva8{dNode6vac0wad1ypxawg68862cbxaka8xase862cbvaetvad{dNode6vac0wad1ypFxawd68dfxakadxasbdfvaetvab{dNode6vac1vae{dNode6vac0wad1ypQxawd68bexakaexasaevaetwad1ypixawc68bxakabxasabvaetvaa{dNode6vac0wad1ypuxawc68axakaaxasaavaetwad1ypHxawb68xaka8xasa8vaetva9{dNode6vac9va1{dNode6vac0wad1ypixaw Y691013bfe66dd46ded85a98edxaka1xas W1013bfe66dd46ded85a98edvaetva2{dNode6vac2va0{dNode6vac0wad1ypHxawg6920edcxaka0xasd0edcvaetva4{dNode6vac0wad1ypSxawf69248bxaka4xasc48bvaetwad0xawc692xaka2xasa2vaesva4{dNode6vac0wad1ypVxawf69458bxaka4xasd458bvaetva7{dNode6vac0wad1ypMxawd6978xaka7xasb78vaetva8{dNode6vac0wad1yp\xawe698cfxaka8xasc8cfvaetvab{dNode6vac2vad{dNode6vac0wad1yp_xawd69bdxakadxasadvaetvae{dNode6vac0wad1ypaxawe69beaxakaexasbeavaetwad0xawc69bxakabxasabvaesvaf{dNode6vac1vac{dNode6vac0wad1ypnxawd69fcxakacxasacvaetwad1yp|xawc69fxakafxasafvaetvaa{dNode6vac0wad1ypwxawo69afdbadc1e76b6xakaaxasmafdbadc1e76b6vaetvae{dNode6vac0wad1ypkxawc69exakaexasaevaetwad0xawb69xaka9xasa9vaesvaf{dNode6vac1vab{dNode6vac0wad1ypRxawd6fbfxakabxasbbfvaetwad1ypYxawb6fxakafxasafvaetvac{dNode6vac0wad1ypuxawb6cxakacxasacvaetvae{dNode6vac0wad1ypfxawb6exakaexasaevaet>wad<ypSTZRSST`fovw~HLZZ\\]_elnnz|ABLSccflptvvzz{{RUXZZ\lstwDFOSSSfyyABIMSST\benorrDO>xawa6xaka6xasa6vaetva7{dNode6vac<va0{dNode6vac9va0{dNode6vac0wad1ypKxaw [70097776e24c2a7c9c0f2514f79xaka0xas Y097776e24c2a7c9c0f2514f79vaetva2{dNode6vac0wad1ypvxawe7027exaka2xasc27evaetva3{dNode6vac0wad1ypqxawc703xaka3xasa3vaetva4{dNode6vac0wad1ypZxawd7043xaka4xasb43vaetva5{dNode6vac0wad1ypuxaw `7052598d2355984237d126afea2f6e88xaka5xas ^52598d2355984237d126afea2f6e88vaetva6{dNode6vac0wad1ypZxawd706cxaka6xasb6cvaetvaf{dNode6vac0wad2ypTCxawc70fxakafxasafvaetvad{dNode6vac0wad1yprxawd70dexakadxasbdevaetvae{dNode6vac0wad1yppxawe70edbxakaexascedbvaetwad0xawb70xaka0xasa0vaesva1{dNode6vac9va0{dNode6vac0wad1ypnxawe7101dxaka0xasc01dvaetva2{dNode6vac0wad1ypbxawc712xaka2xasa2vaetva5{dNode6vac0wad1yprxawc715xaka5xasa5vaetva6{dNode6vac2va2{dNode6vac0wad1ypFxawf71627exaka2xasc27evaetva4{dNode6vac0wad1ypaxaw `7164823f504286e3a762ee612ff0a988xaka4xas ]4823f504286e3a762ee612ff0a988vaetwad1ypSxawc716xaka6xasa6vaetva9{dNode6vac3va3{dNode6vac0wad1ypOxaw T7193badc746d52b4173fxaka3xas Q3badc746d52b4173fvaetva8{dNode6vac0wad1yp]xawd7198xaka8xasa8vaetva9{dNode6vac0wad1ypoxawd7199xaka9xasa9vaetwad0xawc719xaka9xasa9vaesvad{dNode6vac0wad2ypKPxawc71dxakadxasadvaetvae{dNode6vac2vae{dNode6vac0wad1ypTxawd71eexakaexasaevaetvaf{dNode6vac0wad1ypzxawd71efxakafxasafvaetwad0xawc71exakaexasaevaesvac{dNode6vac0wad1yp[xawd71cfxakacxasbcfvaetvaf{dNode6vac0wad1ypnxawd71fdxakafxasbfdvaetwad0xawb71xaka1xasa1vaesva2{dNode6vac7va0{dNode6vac2va6{dNode6vac0wad1ypGxawd7206xaka6xasa6vaetva8{dNode6vac0wad1ypYxawe7208fxaka8xasb8fvaetwad1ypUxawc720xaka0xasa0vaetva1{dNode6vac1va1{dNode6vac0wad1yp^xaw Y72110575c78aeb979170212b8xaka1xas V10575c78aeb979170212b8vaetwad1ypQxawc721xaka1xasa1vaetva2{dNode6vac0wad2ypc{xawc722xaka2xasa2vaetva4{dNode6vac2va7{dNode6vac0wad1ypBxaw S724742c4ee0960d8d40xaka7xas P742c4ee0960d8d40vaetva9{dNode6vac0wad1ypnxaw `7249710187cc2d983709e044dbc78d9dxaka9xas ]9710187cc2d983709e044dbc78d9dvaetwad1ypgxawc724xaka4xasa4vaetva6{dNode6vac0wad1yp`xawf72643dxaka6xasd643dvaetvad{dNode6vac0wad1yp[xawd72dfxakadxasbdfvaetvac{dNode6vac0wad1ypixawc72cxakacxasacvaetwad0xawb72xaka2xasa2vaesva3{dNode6vac8va0{dNode6vac0wad1ypdxawc730xaka0xasa0vaetva2{dNode6vac2va6{dNode6vac0wad1yp|xaw `73262345214f9b7794f2cc4a612b15e8xaka6xas ]62345214f9b7794f2cc4a612b15e8vaetva7{dNode6vac0wad1ypQxaw `73279888a8fe482c836fb19ca23318dcxaka7xas ]79888a8fe482c836fb19ca23318dcvaetwad0xawc732xaka2xasa2vaesva4{dNode6vac0wad1ypCxaw ^734259dfb9addebe2b226d96b4f744xaka4xas \4259dfb9addebe2b226d96b4f744vaetva5{dNode6vac0wad1ypxaw P73579aaaf5d7ce36xaka5xasn579aaaf5d7ce36vaetva9{dNode6vac2va6{dNode6vac0wad1ypHxawd7396xaka6xasa6vaetva8{dNode6vac0wad1yppxawf73985axaka8xasc85avaetwad0xawc739xaka9xasa9vaesvab{dNode6vac0wad1yp`xawc73bxakabxasabvaetvad{dNode6vac0wad1yp_xawc73dxakadxasadvaetvaf{dNode6vac0wad1ypqxawd73faxakafxasbfavaetwad0xawb73xaka3xasa3vaesva4{dNode6vac7va4{dNode6vac0wad1yp^xaw `744554499cb7880086fbd9b1f080e7e1xaka4xas ^4554499cb7880086fbd9b1f080e7e1vaetva5{dNode6vac0wad1ypKxawc745xaka5xasa5vaetva6{dNode6vac2va0{dNode6vac0wad1ypRxawf74608exaka0xasc08evaetva2{dNode6vac0wad1ypPxawd7462xaka2xasa2vaetwad0xawc746xaka6xasa6vaesva7{dNode6vac0wad1ypRxawg74705adxaka7xase705advaetva8{dNode6vac0wad1ypaxawf74826exaka8xasd826evaetva9{dNode6vac3va1{dNode6vac0wad1ypJxawe7491exaka1xasb1evaetva3{dNode6vac0wad1yp[xawe74933xaka3xasb33vaetva8{dNode6vac0wad1ypdxaw V7498efb66f5ba3a8b35d08xaka8xas S8efb66f5ba3a8b35d08vaetwad0xawc749xaka9xasa9vaesvad{dNode6vac0wad1ypJxawc74dxakadxasadvaetwad0xawb74xaka4xasa4vaesva5{dNode6vac8va0{dNode6vac0wad1ypPxawc750xaka0xasa0vaetva4{dNode6vac1va6{dNode6vac0wad1yp@xawk75465416b86xaka6xash65416b86vaetwad1yp`xawc754xaka4xasa4vaetva5{dNode6vac0wad1yp|xawc755xaka5xasa5vaetva9{dNode6vac0wad1yp{xawc759xaka9xasa9vaetvab{dNode6vac0wad1ypOxawf75bdaaxakabxasdbdaavaetvad{dNode6vac0wad1ypjxawc75dxakadxasadvaetvae{dNode6vac0wad1ypxawc75exakaexasaevaetvaa{dNode6vac1vae{dNode6vac0wad1ypnxawe75aecxakaexasbecvaetwad1ypFxawc75axakaaxasaavaetwad0xawb75xaka5xasa5vaesva6{dNode6vac8va0{dNode6vac1va4{dNode6vac0wad1ypqxawg7604edfxaka4xasd4edfvaetwad1ypSxawc760xaka0xasa0vaetva1{dNode6vac0wad1ypPxawf76101dxaka1xasd101dvaetva2{dNode6vac0wad1ypWxawe7621dxaka2xasc21dvaetva5{dNode6vac0wad2ypVFxawc765xaka5xasa5vaetva6{dNode6vac3va4{dNode6vac0wad1ypGxawd7664xaka4xasa4vaetva7{dNode6vac0wad1ypGxaw Q76672d3de4dc9a8edxaka7xasn72d3de4dc9a8edvaetva9{dNode6vac0wad1yphxawd7669xaka9xasa9vaetwad0xawc766xaka6xasa6vaesva8{dNode6vac0wad1ypQxawh768585daxaka8xasf8585davaetvae{dNode6vac1vaf{dNode6vac0wad1ypOxawd76efxakafxasafvaetwad1yp~xawc76exakaexasaevaetvaa{dNode6vac0wad1ypaxawc76axakaaxasaavaetwad0xawb76xaka6xasa6vaesva7{dNode6vac<va0{dNode6vac0wad1ypZxawf77021axaka0xasd021avaetva3{dNode6vac2va0{dNode6vac0wad1yp|xawd7730xaka0xasa0vaetva7{dNode6vac0wad1ypQxawd7737xaka7xasa7vaetwad0xawc773xaka3xasa3vaesva4{dNode6vac0wad1ypYxawc774xaka4xasa4vaetva5{dNode6vac0wad1yprxaw `775894425f5a7436f56fc5a3b4a2cfaaxaka5xas ^5894425f5a7436f56fc5a3b4a2cfaavaetva8{dNode6vac0wad1ypjxawd7787xaka8xasb87vaetva9{dNode6vac1vae{dNode6vac0wad1ypUxawd779exakaexasaevaetwad1ypXxawc779xaka9xasa9vaetvaf{dNode6vac0wad1ypYxawc77fxakafxasafvaetvad{dNode6vac1vae{dNode6vac0wad1ypPxawe77deexakaexasbeevaetwad2ypOzxawc77dxakadxasadvaetvab{dNode6vac0wad1ypgxawd77bexakabxasbbevaetvaa{dNode6vac0wad1ypxxawc77axakaaxasaavaetvae{dNode6vac0wad1ypDxawd77ebxakaexasbebvaetvac{dNode6vac0wad1ypRxawc77cxakacxasacvaet>wad0xawb77xaka7xasa7vaesva8{dNode6vac:va0{dNode6vac1va7{dNode6vac0wad1ypgxawf78077cxaka7xasc77cvaetwad1ypYxawc780xaka0xasa0vaetva2{dNode6vac1va9{dNode6vac0wad1ypOxawf78292dxaka9xasc92dvaetwad1ypCxawc782xaka2xasa2vaetva4{dNode6vac0wad1ypkxaw Y784707b1d2c702fbeba080e86xaka4xas W4707b1d2c702fbeba080e86vaetva5{dNode6vac1va3{dNode6vac0wad1yp[xawd7853xaka3xasa3vaetwad1ypYxawc785xaka5xasa5vaetva7{dNode6vac0wad1ypkxawg787810dxaka7xase7810dvaetva8{dNode6vac1va4{dNode6vac0wad1ypXxawd7884xaka4xasa4vaetwad1yppxawc788xaka8xasa8vaetvab{dNode6vac1vae{dNode6vac0wad1ypxxawd78bexakaexasaevaetwad1ypUxawc78bxakabxasabvaetvac{dNode6vac3vac{dNode6vac0wad1ypGxawe78ccaxakacxasbcavaetvad{dNode6vac0wad1ypsxawd78cdxakadxasadvaetvae{dNode6vac0wad1yprxawe78cedxakaexasbedvaetwad0xawc78cxakacxasacvaesvad{dNode6vac0wad1ypoxawd78daxakadxasbdavaetvaf{dNode6vac1vad{dNode6vac0wad1ypGxawd78fdxakadxasadvaetwad1ypDxawc78fxakafxasafvaetwad0xawb78xaka8xasa8vaesva9{dNode6vac9va0{dNode6vac0wad1ypbxawd7906xaka0xasb06vaetva1{dNode6vac0wad1ypoxawc791xaka1xasa1vaetva4{dNode6vac0wad1ypbxawc794xaka4xasa4vaetva5{dNode6vac2va2{dNode6vac0wad1ypAxaw [795216d5bafa33a810af3421942xaka2xas X216d5bafa33a810af3421942vaetva3{dNode6vac0wad1ypqxawh79534a52xaka3xase34a52vaetwad0xawc795xaka5xasa5vaesva6{dNode6vac0wad1yp\xaw W796161d82c9ac438ebab5d2xaka6xas U6161d82c9ac438ebab5d2vaetva9{dNode6vac1va8{dNode6vac0wad1ypgxawd7998xaka8xasa8vaetwad1ypdxawc799xaka9xasa9vaetvad{dNode6vac0wad1ypHxawc79dxakadxasadvaetvae{dNode6vac0wad3ypAP{xawc79exakaexasaevaetvaa{dNode6vac0wad1yp\xawc79axakaaxasaavaetwad1ypJxawb79xaka9xasa9vaetvaf{dNode6vac3vad{dNode6vac0wad1ypUxawe7fdedxakadxascdedvaetvac{dNode6vac0wad1ypaxawf7fcfaaxakacxasdcfaavaetvaa{dNode6vac0wad1yptxawc7faxakaaxasaavaetwad1ypUxawb7fxakafxasafvaetvac{dNode6vac1vac{dNode6vac0wad2ypXQxawc7ccxakacxasacvaetwad1ypCxawb7cxakacxasacvaetvab{dNode6vac1va6{dNode6vac0wad1ypAxawc7b6xaka6xasa6vaetwad1yp_xawb7bxakabxasabvaetvad{dNode6vac0wad1yp~xawd7deaxakadxascdeavaetvae{dNode6vac1vad{dNode6vac0wad1ypDxawc7edxakadxasadvaetwad1yplxawb7exakaexasaevaetvaa{dNode6vac0wad1ypmxawb7axakaaxasaavaet>wad<ypTTYS]_`bcdhsvHKLRUUXZ]]cchnBDNQamqsxyzFGILL\ahiklstxzNQkkpssuv{}BJKUWXZ_qrrx@ILQS>xawa7xaka7xasa7vaetva8{dNode6vac<va0{dNode6vac9va0{dNode6vac0wad1ypsxawe8008dxaka0xasc08dvaetva1{dNode6vac1va0{dNode6vac0wad1ypXxaw Y8010960eb17e368a6fdd5a51bxaka0xas V0960eb17e368a6fdd5a51bvaetwad2yp~exawc801xaka1xasa1vaetva4{dNode6vac1va5{dNode6vac0wad1ypLxaw Z80454654d990d9c07d33d35d1cxaka5xas W54654d990d9c07d33d35d1cvaetwad2ypFYxawc804xaka4xasa4vaetva5{dNode6vac0wad1yp@xaw ]805472f79f0b558f75b90b5e7b4eexaka5xas [5472f79f0b558f75b90b5e7b4eevaetva7{dNode6vac2va3{dNode6vac0wad1ypzxawf80739axaka3xasc39avaetva7{dNode6vac0wad1ypKxawd8077xaka7xasa7vaetwad0xawc807xaka7xasa7vaesva9{dNode6vac0wad1ypbxawg809925exaka9xase9925evaetvaa{dNode6vac0wad1ypdxawc80axakaaxasaavaetvac{dNode6vac1vae{dNode6vac0wad1ypHxawe80cedxakaexasbedvaetwad1ypjxawc80cxakacxasacvaetvaf{dNode6vac0wad1yprxawc80fxakafxasafvaetwad0xawb80xaka0xasa0vaesva1{dNode6vac:va0{dNode6vac0wad1yp^xawg810068exaka0xase0068evaetva1{dNode6vac0wad1ypzxawg811063bxaka1xase1063bvaetva3{dNode6vac1va4{dNode6vac0wad1yppxawe8134axaka4xasb4avaetwad2yp|exawc813xaka3xasa3vaetva4{dNode6vac0wad1ypsxawi8141ddcc1xaka4xasg41ddcc1vaetva5{dNode6vac0wad1ypcxawh815273cdxaka5xasf5273cdvaetva8{dNode6vac2va3{dNode6vac0wad1ypExawg8183cedxaka3xasd3cedvaetva7{dNode6vac0wad1yp@xaw X8187985725963b8bfc67004dxaka7xas U7985725963b8bfc67004dvaetwad1yp{xawc818xaka8xasa8vaetva9{dNode6vac3va4{dNode6vac0wad1yp`xawd8194xaka4xasa4vaetva6{dNode6vac0wad1ypkxaw \819656f68b87a91c53afbd441fecxaka6xas Y656f68b87a91c53afbd441fecvaetvaa{dNode6vac0wad1yp_xawd819axakaaxasaavaetwad0xawc819xaka9xasa9vaesvad{dNode6vac0wad1ypexawc81dxakadxasadvaetvac{dNode6vac0wad1ypuxawc81cxakacxasacvaetvaf{dNode6vac0wad1ypOxawe81facxakafxascfacvaetwad0xawb81xaka1xasa1vaesva2{dNode6vac;va0{dNode6vac1va8{dNode6vac0wad1ypaxawi82088739dxaka8xase8739dvaetwad1ypSxawd8208xaka0xasb08vaetva1{dNode6vac0wad1ypbxawf82160dxaka1xasd160dvaetva2{dNode6vac1va0{dNode6vac0wad1ypJxawj822028dd9exaka0xasg028dd9evaetwad1ypyxawc822xaka2xasa2vaetva3{dNode6vac1va9{dNode6vac1va1{dNode6vac0wad1ypTxawe82391xaka1xasa1vaetwad1ypjxawd8239xaka9xasa9vaetwad2yp_yxawc823xaka3xasa3vaetva5{dNode6vac0wad1ypYxawc825xaka5xasa5vaetva7{dNode6vac1vad{dNode6vac0wad1ypvxawe827dexakadxasbdevaetwad2yp_pxawc827xaka7xasa7vaetva8{dNode6vac2va0{dNode6vac0wad1ypoxawf82809axaka0xasc09avaetva1{dNode6vac0wad1ypsxaw [82817c0fb24e591b9a89a82f736xaka1xas X17c0fb24e591b9a89a82f736vaetwad0xawc828xaka8xasa8vaesvaa{dNode6vac0wad2yp@Fxawc82axakaaxasaavaetvae{dNode6vac0wad1ypUxawe82efaxakaexascefavaetvaf{dNode6vac0wad1yppxawf82fdfcxakafxasdfdfcvaetvab{dNode6vac0wad1ypFxawc82bxakabxasabvaetwad0xawb82xaka2xasa2vaesva3{dNode6vac8va0{dNode6vac1va4{dNode6vac0wad1ypfxawe8304bxaka4xasb4bvaetwad1ypQxawc830xaka0xasa0vaetva2{dNode6vac1va2{dNode6vac0wad1ypXxaw [8322cdbda7a21e4aecbe04462b7xaka2xas X2cdbda7a21e4aecbe04462b7vaetwad1ypVxawc832xaka2xasa2vaetva4{dNode6vac2va0{dNode6vac0wad1ypexawd8340xaka0xasa0vaetva5{dNode6vac0wad1yphxawe83454xaka5xasb54vaetwad0xawc834xaka4xasa4vaesva5{dNode6vac0wad1ypLxawc835xaka5xasa5vaetvab{dNode6vac0wad1ypbxawc83bxakabxasabvaetvad{dNode6vac1vaa{dNode6vac0wad1ypMxawe83daaxakaaxasbaavaetwad1ypexawc83dxakadxasadvaetvaa{dNode6vac1vae{dNode6vac0wad1yp[xawd83aexakaexasaevaetwad1ypnxawc83axakaaxasaavaetvaf{dNode6vac2vaa{dNode6vac0wad1ypPxawd83faxakaaxasaavaetvab{dNode6vac0wad1yp[xawd83fbxakabxasabvaetwad0xawc83fxakafxasafvaeswad0xawb83xaka3xasa3vaesva4{dNode6vac9va0{dNode6vac0wad1ypRxawc840xaka0xasa0vaetva1{dNode6vac0wad1ypHxawd8412xaka1xasb12vaetva3{dNode6vac0wad1ypxawc843xaka3xasa3vaetva4{dNode6vac0wad1yp{xawc844xaka4xasa4vaetva5{dNode6vac0wad1yp{xawc845xaka5xasa5vaetva6{dNode6vac0wad1ypixaw R8460150068ba0c6743xaka6xas P60150068ba0c6743vaetva7{dNode6vac0wad1ypWxawc847xaka7xasa7vaetvab{dNode6vac0wad1ypmxawc84bxakabxasabvaetvae{dNode6vac0wad1yplxawc84exakaexasaevaetwad1ypmxawb84xaka4xasa4vaetva5{dNode6vac9va0{dNode6vac0wad1ypUxawg850036cxaka0xase0036cvaetva3{dNode6vac2va4{dNode6vac0wad1ypzxawd8534xaka4xasa4vaetvac{dNode6vac0wad1ypLxawf853cacxakacxasccacvaetwad0xawc853xaka3xasa3vaesva4{dNode6vac0wad1ypSxaw W854414033d5cec1470774eexaka4xas U4414033d5cec1470774eevaetva6{dNode6vac0wad1ypbxawh85653399xaka6xasf653399vaetva7{dNode6vac0wad1yp|xawc857xaka7xasa7vaetvac{dNode6vac1vae{dNode6vac0wad1yp\xawf85cedexakaexascedevaetwad1ypVxawc85cxakacxasacvaetvaf{dNode6vac3vad{dNode6vac0wad1ypWxawd85fdxakadxasadvaetvab{dNode6vac0wad1ypKxawd85fbxakabxasabvaetvac{dNode6vac0wad1ypVxawf85fcadxakacxasccadvaetwad0xawc85fxakafxasafvaesvaa{dNode6vac0wad1yp_xawd85afxakaaxasbafvaetvab{dNode6vac0wad1ypSxawd85baxakabxasbbavaetwad0xawb85xaka5xasa5vaesva6{dNode6vac<va0{dNode6vac2va4{dNode6vac0wad1yp}xaw T8604342a925b2dc60737xaka4xas Q4342a925b2dc60737vaetva8{dNode6vac0wad1ypKxawd8608xaka8xasa8vaetwad1ypZxawc860xaka0xasa0vaetva1{dNode6vac1va2{dNode6vac0wad1ypWxawf86121fxaka2xasc21fvaetwad1ypMxawc861xaka1xasa1vaetva5{dNode6vac1va6{dNode6vac0wad1ypMxawm8656477b226bexaka6xasj6477b226bevaetwad1yp~xawc865xaka5xasa5vaetva6{dNode6vac1va4{dNode6vac0wad1ypNxawh866426cexaka4xase426cevaetwad2ypTgxawc866xaka6xasa6vaetva7{dNode6vac0wad1ypSxawe8673dxaka7xasc73dvaetva8{dNode6vac0wad1ypdxaw \86812812dab8d39db9aaefe94a78xaka8xas Z812812dab8d39db9aaefe94a78vaetva9{dNode6vac0wad1yppxawc869xaka9xasa9vaetvac{dNode6vac0wad1yp|xawd86caxakacxasbcavaetvaf{dNode6vac0wad1ypQxawc86fxakafxasafvaetvaa{dNode6vac0wad1ypUxawd86aexakaaxasbaevaetvae{dNode6vac0wad1ypjxawd86ecxakaexasbecvaetvab{dNode6vac0wad1ypDxawc86bxakabxasabvaet>wad1ypPxawb86xaka6xasa6vaetva7{dNode6vac7va1{dNode6vac0wad1ypgxaw X871950ebc36c415a53630477xaka1xas V1950ebc36c415a53630477vaetva5{dNode6vac0wad1yp{xawc875xaka5xasa5vaetva7{dNode6vac0wad1ypUxawd8773xaka7xasb73vaetva9{dNode6vac0wad1ypIxaw Y8797ace2fb37402ea6a09d126xaka9xas W97ace2fb37402ea6a09d126vaetvab{dNode6vac0wad1ypOxawd87bexakabxasbbevaetvaa{dNode6vac0wad1ypVxawc87axakaaxasaavaetvae{dNode6vac0wad1ypsxawc87exakaexasaevaetwad0xawb87xaka7xasa7vaesva8{dNode6vac:va0{dNode6vac0wad1yp|xawc880xaka0xasa0vaetva5{dNode6vac0wad1ypuxawc885xaka5xasa5vaetva6{dNode6vac0wad2ypWgxawc886xaka6xasa6vaetva8{dNode6vac2va2{dNode6vac0wad1yplxawh888217abxaka2xase217abvaetva3{dNode6vac0wad1ypyxawd8883xaka3xasa3vaetwad3yp~vnxawc888xaka8xasa8vaetva9{dNode6vac1va3{dNode6vac0wad1ypNxaw W889349870426d10edc694bexaka3xas T349870426d10edc694bevaetwad1ypNxawc889xaka9xasa9vaetvac{dNode6vac0wad1ypRxawc88cxakacxasacvaetvab{dNode6vac0wad1ypmxawd88bdxakabxasbbdvaetvaf{dNode6vac0wad2ypGMxawc88fxakafxasafvaetvaa{dNode6vac0wad2ypG@xawc88axakaaxasaavaetvad{dNode6vac2vac{dNode6vac0wad1yp]xawd88dcxakacxasacvaetvaa{dNode6vac0wad1ypmxawd88daxakaaxasaavaetwad0xawc88dxakadxasadvaeswad0xawb88xaka8xasa8vaesva9{dNode6vac;va1{dNode6vac2va1{dNode6vac0wad1ypzxawh89118022xaka1xase18022vaetva4{dNode6vac0wad1ypwxawf89149axaka4xasc49avaetwad1ypbxawc891xaka1xasa1vaetva2{dNode6vac0wad1ypmxawc892xaka2xasa2vaetva5{dNode6vac1va2{dNode6vac0wad1yp{xaw R8952efd1be1881e651xaka2xaso2efd1be1881e651vaetwad1ypExawc895xaka5xasa5vaetva6{dNode6vac0wad1ypOxawd8964xaka6xasb64vaetva7{dNode6vac0wad1ypsxawc897xaka7xasa7vaetva8{dNode6vac0wad1ypjxawd898dxaka8xasb8dvaetvab{dNode6vac0wad1yp_xawd89bexakabxasbbevaetvae{dNode6vac1vae{dNode6vac0wad1ypwxawd89eexakaexasaevaetwad2ypqRxawc89exakaexasaevaetvac{dNode6vac0wad1ypRxawe89cecxakacxasccecvaetvad{dNode6vac0wad1yppxawc89dxakadxasadvaetvaa{dNode6vac0wad1yppxawf89abaaxakaaxasdabaavaetwad0xawb89xaka9xasa9vaesvaf{dNode6vac0wad1ypVxawb8fxakafxasafvaetvaa{dNode6vac2va1{dNode6vac0wad1ypxawc8a1xaka1xasa1vaetvac{dNode6vac0wad1ypxxawd8accxakacxasbccvaetwad1ypsxawb8axakaaxasaavaetvad{dNode6vac1va7{dNode6vac0wad1ypmxawf8d7cafxaka7xasd7cafvaetwad1ypSxawb8dxakadxasadvaetvac{dNode6vac0wad1yp|xawc8ccxakacxasbccvaetvab{dNode6vac0wad1ypPxawb8bxakabxasabvaet>wad<ypTTVRTZZadghlwy|}@KKKY]]aagijnOOQQQ`cdflrrstEFFGPUUY\`}ABJNPS`ffnuzFFHWW\gmpq@@IR>xawa8xaka8xasa8vaetva9{dNode6vac<va0{dNode6vac:va0{dNode6vac1va6{dNode6vac0wad1ypZxawh90061486xaka6xase61486vaetwad1ypDxawc900xaka0xasa0vaetva4{dNode6vac2va5{dNode6vac0wad1yp`xawe90451xaka5xasb51vaetvab{dNode6vac0wad1ypJxawd904bxakabxasabvaetwad0xawc904xaka4xasa4vaesva5{dNode6vac0wad1ypxxaw ]9052870778e14ab4a5acbc8c24af4xaka5xas [52870778e14ab4a5acbc8c24af4vaetva6{dNode6vac1va6{dNode6vac0wad1ypyxawd9066xaka6xasa6vaetwad1ypPxawc906xaka6xasa6vaetva7{dNode6vac0wad1yptxawc907xaka7xasa7vaetvaf{dNode6vac0wad1yp`xawc90fxakafxasafvaetvab{dNode6vac1vac{dNode6vac0wad1ypUxawe90bcexakacxasbcevaetwad1ypLxawc90bxakabxasabvaetvad{dNode6vac0wad1yptxawc90dxakadxasadvaetvac{dNode6vac0wad1ypxxawc90cxakacxasacvaetvaa{dNode6vac0wad1yp|xawc90axakaaxasaavaetwad0xawb90xaka0xasa0vaesva1{dNode6vac;va0{dNode6vac0wad1ypuxawh910197ccxaka0xasf0197ccvaetva2{dNode6vac0wad1ypUxawc912xaka2xasa2vaetva3{dNode6vac1va3{dNode6vac0wad1ypxxawe9133fxaka3xasb3fvaetwad1ypMxawc913xaka3xasa3vaetva4{dNode6vac0wad1ypHxawc914xaka4xasa4vaetva5{dNode6vac0wad1ypTxawc915xaka5xasa5vaetva6{dNode6vac1vab{dNode6vac0wad1ypWxawf916bdaxakabxascbdavaetwad1ypyxawc916xaka6xasa6vaetva7{dNode6vac0wad1ypPxawc917xaka7xasa7vaetvaa{dNode6vac0wad1ypdxawc91axakaaxasaavaetvae{dNode6vac0wad1ypcxawc91exakaexasaevaetvac{dNode6vac0wad3yporwxawc91cxakacxasacvaetvaf{dNode6vac0wad1yp\xawd91fexakafxasbfevaetwad0xawb91xaka1xasa1vaesva2{dNode6vac7va2{dNode6vac0wad1ypnxawe922ccxaka2xasc2ccvaetva4{dNode6vac0wad1yphxaw `924727b6f380cf3cdfe5650163e92054xaka4xas ^4727b6f380cf3cdfe5650163e92054vaetva6{dNode6vac2va4{dNode6vac0wad1ypIxawm92641dadb5de7xaka4xasj41dadb5de7vaetva8{dNode6vac0wad1ypjxawi9268739fexaka8xasf8739fevaetwad0xawc926xaka6xasa6vaesva7{dNode6vac2va4{dNode6vac0wad1yp_xawd9274xaka4xasa4vaetva6{dNode6vac0wad1ypvxaw `927612b57ba01ca878b2d7edce52a563xaka6xas ]612b57ba01ca878b2d7edce52a563vaetwad1ypixawc927xaka7xasa7vaetvad{dNode6vac1vac{dNode6vac0wad1ypQxawd92dcxakacxasacvaetwad1ypdxawc92dxakadxasadvaetvab{dNode6vac0wad1ypcxawc92bxakabxasabvaetvac{dNode6vac0wad1ypyxawd92cbxakacxasbcbvaetwad2ypFxawb92xaka2xasa2vaetva3{dNode6vac:va0{dNode6vac0wad1ypPxawf93015dxaka0xasd015dvaetva1{dNode6vac1vab{dNode6vac0wad1ypgxawd931bxakabxasabvaetwad1ypDxawc931xaka1xasa1vaetva2{dNode6vac0wad1ypnxawc932xaka2xasa2vaetva3{dNode6vac2va0{dNode6vac0wad1ypUxawe9330dxaka0xasb0dvaetva5{dNode6vac0wad1yp]xaw `9335522f4c8dbc7256a42a091e6e00bcxaka5xas ]5522f4c8dbc7256a42a091e6e00bcvaetwad0xawc933xaka3xasa3vaesva4{dNode6vac1va0{dNode6vac0wad1ypyxawg9340deaxaka0xasd0deavaetwad1ypFxawc934xaka4xasa4vaetva5{dNode6vac2va5{dNode6vac0wad1yp`xaw ]9355781403b92e844de8568863ae8xaka5xas Z5781403b92e844de8568863ae8vaetva8{dNode6vac0wad1ypXxawd9358xaka8xasa8vaetwad1yp\xawc935xaka5xasa5vaetva6{dNode6vac0wad1yphxawc936xaka6xasa6vaetva7{dNode6vac0wad1ypGxawd937axaka7xasb7avaetva8{dNode6vac1va4{dNode6vac0wad1ypGxawf93847bxaka4xasc47bvaetwad1ypxxawc938xaka8xasa8vaetva9{dNode6vac0wad1yp@xawc939xaka9xasa9vaetwad0xawb93xaka3xasa3vaesva4{dNode6vac<va1{dNode6vac1va5{dNode6vac0wad1ypCxawf94159exaka5xasc59evaetwad1ypFxawc941xaka1xasa1vaetva2{dNode6vac2va0{dNode6vac0wad1yp[xawn94208817b83468xaka0xask08817b83468vaetva5{dNode6vac0wad2ypizxawd9425xaka5xasa5vaetwad0xawc942xaka2xasa2vaesva3{dNode6vac0wad1ypyxawc943xaka3xasa3vaetva4{dNode6vac0wad1ypQxaw [9445539e9274282a612dea354c2xaka4xas Y45539e9274282a612dea354c2vaetva5{dNode6vac1va0{dNode6vac0wad1ypcxawh945088dexaka0xase088devaetwad1ypXxawc945xaka5xasa5vaetva6{dNode6vac0wad1yppxawc946xaka6xasa6vaetva9{dNode6vac1va9{dNode6vac0wad1ypoxawg949924cxaka9xasd924cvaetwad1yp^xawc949xaka9xasa9vaetvab{dNode6vac0wad2ypTSxawc94bxakabxasabvaetvac{dNode6vac2vab{dNode6vac0wad1ypcxawe94cbdxakabxasbbdvaetvaf{dNode6vac0wad1ypxawf94cfccxakafxascfccvaetwad1yp]xawc94cxakacxasacvaetvaa{dNode6vac0wad1ypcxawc94axakaaxasaavaetvae{dNode6vac1vae{dNode6vac0wad1yp_xawd94eexakaexasaevaetwad1ypvxawc94exakaexasaevaetvad{dNode6vac0wad1ypnxawc94dxakadxasadvaet>wad0xawb94xaka4xasa4vaesva5{dNode6vac:va0{dNode6vac2va4{dNode6vac0wad1ypFxawd9504xaka4xasa4vaetva9{dNode6vac0wad1yp{xawe9509bxaka9xasb9bvaetwad1yp_xawc950xaka0xasa0vaetva3{dNode6vac0wad2ypOxawc953xaka3xasa3vaetva4{dNode6vac0wad1ypaxawf95426bxaka4xasd426bvaetva6{dNode6vac0wad2yphtxawc956xaka6xasa6vaetva8{dNode6vac2va0{dNode6vac0wad1ypPxaw ^9580308938069159c5afc55b2f3b96xaka0xas [0308938069159c5afc55b2f3b96vaetva7{dNode6vac0wad1yp@xawd9587xaka7xasa7vaetwad0xawc958xaka8xasa8vaesvae{dNode6vac0wad1ypexawc95exakaexasaevaetvab{dNode6vac1vac{dNode6vac0wad1ypBxawe95bcdxakacxasbcdvaetwad1ypTxawc95bxakabxasabvaetvaf{dNode6vac1vae{dNode6vac0wad1ypYxawd95fexakaexasaevaetwad1ypWxawc95fxakafxasafvaetvac{dNode6vac0wad2yplFxawc95cxakacxasacvaetvaa{dNode6vac0wad2yp]Cxawc95axakaaxasaavaetwad0xawb95xaka5xasa5vaesva6{dNode6vac<va0{dNode6vac0wad1ypmxawd9609xaka0xasb09vaetva1{dNode6vac3va0{dNode6vac0wad1ypjxawi96106314exaka0xasf06314evaetva2{dNode6vac0wad1ypqxaw S96120606c8dda06458fxaka2xas P20606c8dda06458fvaetva9{dNode6vac0wad1ypMxawg96191dcxaka9xasd91dcvaetwad0xawc961xaka1xasa1vaesva2{dNode6vac1va3{dNode6vac0wad1yp_xawd9623xaka3xasa3vaetwad1yprxawc962xaka2xasa2vaetva3{dNode6vac0wad1yp[xawg963035fxaka3xase3035fvaetva4{dNode6vac0wad1yp}xaw ^9649eca3dfbd356527ffc88f1dcb94xaka4xas \49eca3dfbd356527ffc88f1dcb94vaetva5{dNode6vac0wad1ypOxawc965xaka5xasa5vaetva6{dNode6vac3va0{dNode6vac0wad1ypSxawf96604cxaka0xasc04cvaetva8{dNode6vac0wad1ypFxaw Z9668608a39333fa90cf462657exaka8xas W8608a39333fa90cf462657evaetvaf{dNode6vac0wad1ypWxawe966fexakafxasbfevaetwad1ypUxawc966xaka6xasa6vaetva7{dNode6vac0wad1yp]xawd9679xaka7xasb79vaetva8{dNode6vac0wad1yp@xaw P96813587fe3a6049xaka8xasn813587fe3a6049vaetva9{dNode6vac0wad1ypPxawe9693axaka9xasc93avaetvad{dNode6vac0wad1yptxawc96dxakadxasadvaetvac{dNode6vac0wad1ypAxawe96cfexakacxasccfevaetvaa{dNode6vac0wad1ypmxawc96axakaaxasaavaet>wad0xawb96xaka6xasa6vaesva7{dNode6vac;va0{dNode6vac0wad3ypnfxawc970xaka0xasa0vaetva1{dNode6vac2va0{dNode6vac0wad1yp]xawe9710cxaka0xasb0cvaetva9{dNode6vac0wad1ypyxawd9719xaka9xasa9vaetwad1ypmxawc971xaka1xasa1vaetva3{dNode6vac0wad1ypZxawf97311cxaka3xasd311cvaetva4{dNode6vac0wad1ypwxaw `97402287d8c6c03f0b63848e17e9d944xaka4xas ^402287d8c6c03f0b63848e17e9d944vaetva6{dNode6vac3va0{dNode6vac0wad1ypoxaw T9760aec57ba29682a750xaka0xas Q0aec57ba29682a750vaetva7{dNode6vac0wad1ypAxawd9767xaka7xasa7vaetva9{dNode6vac0wad1ypMxawf97692cxaka9xasc92cvaetwad0xawc976xaka6xasa6vaesva9{dNode6vac1va0{dNode6vac0wad1ypjxaw T9790262e14f953bbadcbxaka0xas Q0262e14f953bbadcbvaetwad1yp[xawc979xaka9xasa9vaetvaf{dNode6vac0wad2ypUvxawc97fxakafxasafvaetvac{dNode6vac0wad1ypJxawd97cdxakacxasbcdvaetvaa{dNode6vac0wad1ypoxawc97axakaaxasaavaetvae{dNode6vac1vaa{dNode6vac0wad1ypwxawe97eadxakaaxasbadvaetwad1ypCxawc97exakaexasaevaetvab{dNode6vac0wad1yp_xawd97bcxakabxasbbcvaetwad0xawb97xaka7xasa7vaesva8{dNode6vac6va0{dNode6vac1va5{dNode6vac0wad1ypWxaw Z9805919736382ffea5a9554c02xaka5xas W5919736382ffea5a9554c02vaetwad1ypJxawc980xaka0xasa0vaetva4{dNode6vac0wad1yp^xawc984xaka4xasa4vaetva5{dNode6vac0wad1ypgxawd9856xaka5xasb56vaetva6{dNode6vac0wad1ypLxawc986xaka6xasa6vaetvab{dNode6vac0wad1ypRxawd98bbxakabxasbbbvaetvac{dNode6vac0wad1ypmxawc98cxakacxasacvaetwad0xawb98xaka8xasa8vaesva9{dNode6vac<va0{dNode6vac0wad1ypvxawc990xaka0xasa0vaetva1{dNode6vac0wad1ypLxawg991285exaka1xase1285evaetva2{dNode6vac2va7{dNode6vac0wad1ypuxawd9927xaka7xasa7vaetvaa{dNode6vac0wad1ypgxawd992axakaaxasaavaetwad0xawc992xaka2xasa2vaesva3{dNode6vac0wad1ypNxawd993exaka3xasb3evaetva4{dNode6vac0wad1yp\xawc994xaka4xasa4vaetva7{dNode6vac1vaa{dNode6vac0wad1ypxxawf997accxakaaxascaccvaetwad1ypmxawc997xaka7xasa7vaetva8{dNode6vac2va0{dNode6vac0wad1yp]xawf99806cxaka0xasc06cvaetvae{dNode6vac0wad1ypKxawf998edaxakaexascedavaetwad0xawc998xaka8xasa8vaesva9{dNode6vac0wad1ypXxawc999xaka9xasa9vaetvaa{dNode6vac0wad1ypbxawc99axakaaxasaavaetvac{dNode6vac0wad3ypd|Ixawc99cxakacxasacvaetvab{dNode6vac0wad2ypyRxawc99bxakabxasabvaetvaf{dNode6vac0wad1yp\xawc99fxakafxasafvaet>wad0xawb99xaka9xasa9vaesvad{dNode6vac2vaa{dNode6vac0wad1yp{xawc9daxakaaxasaavaetvac{dNode6vac0wad1yp{xawd9dcaxakacxasbcavaetwad0xawb9dxakadxasadvaesvaa{dNode6vac2vad{dNode6vac0wad1ypixawc9adxakadxasadvaetvac{dNode6vac0wad1ypvxawc9acxakacxasacvaetwad1ypOxawb9axakaaxasaavaetvac{dNode6vac1vad{dNode6vac0wad1yp{xawe9ccdaxakadxasbdavaetwad1ypfxawc9ccxakacxasbccvaetvaf{dNode6vac0wad1ypyxawb9fxakafxasafvaetvab{dNode6vac0wad1yp}xawg9baedcdxakabxasfbaedcdvaet>wad<ypRWSUglqvwQSV[[\\dghvzzCCDDQSY]_cdqrz{BEFNPahhhlwEHIOS[fjj|}}BHSS\]j@@CJQQQ>xawa9xaka9xasa9vaetvac{dNode6vac<va0{dNode6vac1va9{dNode6vac0wad1ypHxawdc098xaka9xasb98vaetwad1ypCxawbc0xaka0xasa0vaetva1{dNode6vac2va2{dNode6vac0wad1ypdxaw `c1241374502f200cf9fc49c8d6fb5822xaka2xas ^241374502f200cf9fc49c8d6fb5822vaetva8{dNode6vac0wad1ypsxawdc18bxaka8xasb8bvaetwad0xawbc1xaka1xasa1vaesva2{dNode6vac1va0{dNode6vac0wad1ypFxawdc20dxaka0xasb0dvaetwad1ypnxawbc2xaka2xasa2vaetva3{dNode6vac2va0{dNode6vac0wad1yp^xaw `c3053579ae25e2fb9b967076a06373afxaka0xas ^053579ae25e2fb9b967076a06373afvaetva7{dNode6vac0wad1yprxaw `c377351433a941a927aab543931f6026xaka7xas ^77351433a941a927aab543931f6026vaetwad0xawbc3xaka3xasa3vaesva4{dNode6vac1vad{dNode6vac0wad1ypQxawec4dbaxakadxascdbavaetwad4yptoPExawbc4xaka4xasa4vaetva5{dNode6vac2va4{dNode6vac0wad1ypRxaw `c54909ecf4fb3e9afeea36200fe95dcexaka4xas ^4909ecf4fb3e9afeea36200fe95dcevaetva6{dNode6vac0wad1ypOxawdc56axaka6xasb6avaetwad0xawbc5xaka5xasa5vaesva6{dNode6vac2va1{dNode6vac2va0{dNode6vac0wad1ypmxawgc6107ffxaka0xasd07ffvaetvaa{dNode6vac0wad1ypbxawdc61axakaaxasaavaetwad0xawcc61xaka1xasa1vaesva6{dNode6vac0wad1ypdxawfc6696axaka6xasd696avaetwad3ypm\lxawbc6xaka6xasa6vaetva7{dNode6vac2va0{dNode6vac0wad1ypGxawdc70bxaka0xasb0bvaetva9{dNode6vac0wad1ypMxawfc7937bxaka9xasd937bvaetwad0xawbc7xaka7xasa7vaesva9{dNode6vac2va2{dNode6vac0wad1ypGxawdc92cxaka2xasb2cvaetva8{dNode6vac0wad1yplxawfc98cbcxaka8xasd8cbcvaetwad1ypXxawbc9xaka9xasa9vaetvad{dNode6vac1vab{dNode6vac0wad1ypwxawccdbxakabxasabvaetwad5ypQ{cEUxawbcdxakadxasadvaetvaf{dNode6vac3vaa{dNode6vac2vae{dNode6vac0wad1ypzxawecfaebxakaexasbebvaetvad{dNode6vac0wad1ypzxawecfaddxakadxasbddvaetwad0xawccfaxakaaxasaavaesvac{dNode6vac0wad1ypmxawccfcxakacxasacvaetvae{dNode6vac0wad1ypQxawdcfeaxakaexasbeavaetwad5ypTtHMxawbcfxakafxasafvaetvae{dNode6vac2vab{dNode6vac0wad1ypSxawdcebfxakabxasbbfvaetvad{dNode6vac0wad1yprxawccedxakadxasadvaetwad<ypVSduX]gYINpvFmB>xawbcexakaexasaevaetvab{dNode6vac5vad{dNode6vac1vad{dNode6vac0wad1yp_xawecbdddxakadxasbddvaetwad1yp\xawccbdxakadxasadvaetvaa{dNode6vac1vaa{dNode6vac0wad1yp{xawecbaacxakaaxasbacvaetwad1ypIxawccbaxakaaxasaavaetvae{dNode6vac0wad1ypaxawdcbeaxakaexasbeavaetvaf{dNode6vac0wad1yp@xawccbfxakafxasafvaetvac{dNode6vac0wad1ypHxawccbcxakacxasacvaetwad8yp}nAMs}ttxawbcbxakabxasabvaetvaa{dNode6vac2vae{dNode6vac1vac{dNode6vac0wad1ypyxawdcaecxakacxasacvaetwad1yppxawccaexakaexasaevaetvab{dNode6vac0wad1yp`xawdcabbxakabxasbbbvaetwad:ypRTbFaQgJqIxawbcaxakaaxasaavaetvac{dNode6vac1vac{dNode6vac0wad1ypQxawccccxakacxasacvaetwad6ypYiZD`kxawbccxakacxasacvaet>wad<ypTS[]beehkm||CHLQQRSUUUVXY[]]cddfhlnnouCCHSccfhhipqrrssu{AABBDFGGILUWW`lmmpswz|||FHHKQQX]^``bfhjxz{~DIQTVW]]llx~CLLRS>xawacxakacxasacvaetvad{dNode6vac<va0{dNode6vac0wad1ypuxawdd08axaka0xasc08avaetva1{dNode6vac2va2{dNode6vac0wad1ypQxawdd12cxaka2xasb2cvaetva3{dNode6vac0wad1ypzxawed13aaxaka3xasc3aavaetwad0xawbd1xaka1xasa1vaesva2{dNode6vac1va6{dNode6vac0wad1ypIxawdd266xaka6xasb66vaetwad1yp@xawbd2xaka2xasa2vaetva3{dNode6vac1va9{dNode6vac0wad1ypnxawdd39fxaka9xasb9fvaetwad1ypyxawbd3xaka3xasa3vaetva5{dNode6vac0wad1ypexaw `d51032bef3e7117a94336fea18a3fad7xaka5xas _51032bef3e7117a94336fea18a3fad7vaetva7{dNode6vac3va1{dNode6vac0wad1ypZxawdd710xaka1xasb10vaetva7{dNode6vac0wad1ypIxawfd77cdbxaka7xasd7cdbvaetva9{dNode6vac0wad1yp}xaw `d791eaca9375ca1b36a987af22ee71ddxaka9xas ^91eaca9375ca1b36a987af22ee71ddvaetwad0xawbd7xaka7xasa7vaesva8{dNode6vac3va0{dNode6vac0wad1ypqxawgd8041aexaka0xase041aevaetva1{dNode6vac0wad1ypSxawgd819ceaxaka1xase19ceavaetva6{dNode6vac0wad1ypRxawdd869xaka6xasb69vaetwad0xawbd8xaka8xasa8vaesva9{dNode6vac3va0{dNode6vac0wad1ypcxawfd9018fxaka0xasd018fvaetva5{dNode6vac2va5{dNode6vac0wad1ypixawgd95522cxaka5xasd522cvaetva6{dNode6vac0wad1ypvxaw `d9560caeb797b302191f667b4264da40xaka6xas ]60caeb797b302191f667b4264da40vaetwad0xawcd95xaka5xasa5vaesva6{dNode6vac0wad1yprxawdd96fxaka6xasb6fvaetwad1yplxawbd9xaka9xasa9vaetvab{dNode6vac4vad{dNode6vac0wad1ypbxawcdbdxakadxasadvaetvaf{dNode6vac0wad1yp|xawcdbfxakafxasafvaetvac{dNode6vac0wad1ypXxawddbccxakacxasbccvaetvab{dNode6vac0wad1ypSxawcdbbxakabxasabvaetwad<ypQWly}}{LQZ]_k[>xawbdbxakabxasabvaetvae{dNode6vac1vae{dNode6vac0wad1ypxawddeecxakaexasbecvaetwad;ypVqKy[x|vCszxawbdexakaexasaevaetvaf{dNode6vac5vaa{dNode6vac0wad1ypDxawcdfaxakaaxasaavaetvac{dNode6vac1vac{dNode6vac0wad1ypLxawddfccxakacxasacvaetwad1ypixawcdfcxakacxasacvaetvab{dNode6vac0wad1yphxawcdfbxakabxasabvaetvae{dNode6vac1vae{dNode6vac0wad1ypDxawedfeecxakaexasbecvaetwad1ypFxawcdfexakaexasaevaetvaf{dNode6vac0wad1ypGxawedffcdxakafxascfcdvaetwad5yp^vr_~xawbdfxakafxasafvaetvac{dNode6vac4vaf{dNode6vac0wad1ypgxawcdcfxakafxasafvaetvae{dNode6vac0wad1yplxawedceedxakaexasceedvaetvad{dNode6vac1vab{dNode6vac0wad1ypLxawhdcdbbfdexakabxasebbfdevaetwad1ypLxawcdcdxakadxasadvaetvac{dNode6vac0wad1ypwxawcdccxakacxasacvaetwad9ypPMP_Nc\rIxawbdcxakacxasacvaetvaa{dNode6vac5vaa{dNode6vac1vac{dNode6vac0wad1yp]xawddaacxakacxasacvaetwad2ypL\xawcdaaxakaaxasaavaetvaf{dNode6vac0wad1ypTxawcdafxakafxasafvaetvab{dNode6vac0wad1ypfxawcdabxakabxasabvaetvac{dNode6vac0wad1ypnxawcdacxakacxasacvaetvad{dNode6vac0wad1ypIxawcdadxakadxasadvaetwad;yp~ZR\fDHIbj@xawbdaxakaaxasaavaetvad{dNode6vac4vaa{dNode6vac0wad1yphxawdddabxakaaxasbabvaetvad{dNode6vac0wad1ypvxawcdddxakadxasadvaetvac{dNode6vac0wad1ypSxawdddccxakacxasbccvaetvab{dNode6vac0wad1ypTxawcddbxakabxasabvaetwad6ypQacw|Hxawbddxakadxasadvaet>wad<ypQVXYSZ`aabeegnnosvvwwwwz}}}~@KLMRX\\cegilosuBJLMOUY\mprstvvxz{EKLLPQSZ\_hlmntwyz{CFJPQS]`ffnuyABDDISSUWYZ\cfffknoqrrx@DD>xawadxakadxasadvaetvae{dNode6vac<va0{dNode6vac0wad1ypkxawde01exaka0xasc01evaetva1{dNode6vac2va5{dNode6vac0wad1ypYxawde159xaka5xasb59vaetva8{dNode6vac0wad1ypxaw `e1870dde155be1a375f155dd1f7ead13xaka8xas ^870dde155be1a375f155dd1f7ead13vaetwad0xawbe1xaka1xasa1vaesva3{dNode6vac2va0{dNode6vac0wad1ypTxaw `e30258aeb8475d4c27f7935945671856xaka0xas ^0258aeb8475d4c27f7935945671856vaetva9{dNode6vac0wad1yp_xawge396cbfxaka9xase96cbfvaetwad1ypTxawbe3xaka3xasa3vaetva5{dNode6vac1va3{dNode6vac0wad1yp@xaw `e5390751969ab21df280b7591854b89fxaka3xas ^390751969ab21df280b7591854b89fvaetwad1yp}xawbe5xaka5xasa5vaetva6{dNode6vac0wad1yp~xaw `e6684944c37dbdd4c08d978af9e47bedxaka6xas _6684944c37dbdd4c08d978af9e47bedvaetva7{dNode6vac0wad1ypAxawde74dxaka7xasc74dvaetvae{dNode6vac4vad{dNode6vac0wad1ypUxawceedxakadxasadvaetvaa{dNode6vac0wad2ypUmxawceeaxakaaxasaavaetvab{dNode6vac0wad1ypGxawdeebexakabxasbbevaetvae{dNode6vac1vaf{dNode6vac0wad1ypNxawdeeefxakafxasafvaetwad2ypuFxawceeexakaexasaevaetwad<ypWZlpUuvd[x~R~>xawbeexakaexasaevaetvad{dNode6vac4vae{dNode6vac0wad1yp[xawcedexakaexasaevaetvab{dNode6vac2vaf{dNode6vac0wad1yp]xawdedbfxakafxasafvaetvac{dNode6vac0wad1yptxawdedbcxakacxasacvaetwad0xawcedbxakabxasabvaesvad{dNode6vac0wad1ypaxawdeddbxakadxasbdbvaetvaf{dNode6vac0wad1ypTxawcedfxakafxasafvaetwad;ypYHvcrR]gD^Dxawbedxakadxasadvaetvac{dNode6vac4vae{dNode6vac0wad1ypexawdecedxakaexasbedvaetvac{dNode6vac0wad1yplxawceccxakacxasacvaetvaf{dNode6vac0wad3yp]NLxawcecfxakafxasafvaetvad{dNode6vac0wad1ypzxawdecdfxakadxasbdfvaetwad5ypRhp\Axawbecxakacxasacvaetvaa{dNode6vac4vaf{dNode6vac1vab{dNode6vac0wad1ypOxawfeafbdfxakabxascbdfvaetwad2yplQxawceafxakafxasafvaetvac{dNode6vac0wad1yp{xawfeacbbaxakacxasdcbbavaetvad{dNode6vac0wad1ypnxawceadxakadxasadvaetvaa{dNode6vac0wad1yp{xawdeaadxakaaxasbadvaetwad9ypT|dUZDTpxawbeaxakaaxasaavaetvab{dNode6vac4vad{dNode6vac0wad3ypgQhxawcebdxakadxasadvaetvac{dNode6vac2vaf{dNode6vac0wad1ypqxaweebcffxakafxasbffvaetvad{dNode6vac0wad1yp{xaweebcdfxakadxasbdfvaetwad0xawcebcxakacxasacvaesvaa{dNode6vac0wad1ypUxaweebadexakaaxascadevaetvab{dNode6vac0wad1yptxawcebbxakabxasabvaetwad8ypmqx|ZFrrxawbebxakabxasabvaetvaf{dNode6vac4vab{dNode6vac0wad1ypnxawcefbxakabxasabvaetvae{dNode6vac1vad{dNode6vac0wad1yp{xawdefedxakadxasadvaetwad1ypBxawcefexakaexasaevaetvaa{dNode6vac0wad2yp_Dxawcefaxakaaxasaavaetvaf{dNode6vac1vad{dNode6vac0wad1ypJxaweeffdcxakadxasbdcvaetwad1ypDxawceffxakafxasafvaetwad5yp]km]qxawbefxakafxasafvaet>wad<ypQUWZ_PP\abdegllmowwwx}@@CFKKMRVVX\]cchlz|@ACDJLQ_`ddeehqtvvyAEEEEFLNPQQTUUUZ[\\\fnox}@BGGKNOOPSSSS^kmpqsw{{|HKMSW\\]ceknnprxz@CCDIQS>xawaexakaexasaevaetvaf{dNode6vac<va0{dNode6vac0wad1yp\xawef0fdcxaka0xasd0fdcvaetva1{dNode6vac0wad1ypNxawhf15702aexaka1xasg15702aevaetva2{dNode6vac3va3{dNode6vac0wad1yp~xawef23caxaka3xasc3cavaetva8{dNode6vac0wad1ypaxawdf28fxaka8xasb8fvaetvac{dNode6vac0wad1yptxawef2cbexakacxasccbevaetwad0xawbf2xaka2xasa2vaesva3{dNode6vac0wad2ypkDxawbf3xaka3xasa3vaetva4{dNode6vac4va1{dNode6vac0wad1ypcxawdf41dxaka1xasb1dvaetva5{dNode6vac0wad1ypRxaw `f45069216cd934b80ce882c9a2f2a08axaka5xas ^5069216cd934b80ce882c9a2f2a08avaetva8{dNode6vac0wad1ypNxawdf488xaka8xasb88vaetvab{dNode6vac0wad1ypbxawef4baaxakabxascbaavaetwad0xawbf4xaka4xasa4vaesva5{dNode6vac3va5{dNode6vac0wad1ypjxawdf55dxaka5xasb5dvaetva6{dNode6vac0wad1ypVxawdf56cxaka6xasb6cvaetvae{dNode6vac0wad1ypyxawff5effdxakaexasdeffdvaetwad1ypaxawbf5xaka5xasa5vaetva6{dNode6vac2vae{dNode6vac0wad1ypnxawgf6debedxakaexasdebedvaetvaf{dNode6vac0wad1ypKxawef6dffxakafxasbffvaetwad0xawcf6dxaka6xasb6dvaesva7{dNode6vac0wad1yp_xawbf7xaka7xasa7vaetva8{dNode6vac2va3{dNode6vac0wad1ypOxaw `f8327953a0f0b80011b939111807999axaka3xas ^327953a0f0b80011b939111807999avaetva8{dNode6vac0wad1ypexawdf887xaka8xasb87vaetwad0xawbf8xaka8xasa8vaesva9{dNode6vac0wad1ypWxawbf9xaka9xasa9vaetvab{dNode6vac1vae{dNode6vac0wad1yphxawcfbexakaexasaevaetwad9ypRtwxRalbOxawbfbxakabxasabvaetvaa{dNode6vac4vaa{dNode6vac0wad1ypTxawcfaaxakaaxasaavaetvae{dNode6vac0wad1ypqxawcfaexakaexasaevaetvad{dNode6vac0wad1ypVxawcfadxakadxasadvaetvab{dNode6vac0wad1ypyxawcfabxakabxasabvaetwad;yp_fTyzEHjY~xawbfaxakaaxasaavaetvae{dNode6vac4vae{dNode6vac0wad1ypYxawcfeexakaexasaevaetvaf{dNode6vac0wad1ypJxawdfefcxakafxasbfcvaetvab{dNode6vac0wad1ypjxawcfebxakabxasabvaetvac{dNode6vac2vac{dNode6vac0wad1ypJxawefeccexakacxasbcevaetvaa{dNode6vac0wad1ypXxawdfecaxakaaxasaavaetwad0xawcfecxakacxasacvaeswad6ypn\n{PJxawbfexakaexasaevaetvad{dNode6vac4vae{dNode6vac1vae{dNode6vac0wad1yphxawefdeefxakaexasbefvaetwad1ypcxawcfdexakaexasaevaetvac{dNode6vac1vac{dNode6vac0wad1yphxawdfdccxakacxasacvaetwad1ypuxawcfdcxakacxasacvaetvad{dNode6vac1vaa{dNode6vac0wad1ypFxawdfddaxakaaxasaavaetwad1ypQxawcfddxakadxasadvaetvaa{dNode6vac0wad1ypQxawcfdaxakaaxasaavaetwad9ypZYAFGwIcxawbfdxakadxasadvaetvac{dNode6vac6vab{dNode6vac0wad3ypfqCxawcfcbxakabxasabvaetvaf{dNode6vac0wad1ypaxawefcfdaxakafxascfdavaetvad{dNode6vac1vae{dNode6vac0wad1ypZxawgfcdecdbxakaexasdecdbvaetwad1ypgxawcfcdxakadxasadvaetvaa{dNode6vac0wad1ypjxawcfcaxakaaxasaavaetvae{dNode6vac0wad2yp`_xawcfcexakaexasaevaetvac{dNode6vac0wad1ypKxawcfccxakacxasacvaetwad7ypmklIycxawbfcxakacxasacvaetvaf{dNode6vac1vad{dNode6vac1vab{dNode6vac0wad1ypBxaweffdbdxakabxasbbdvaetwad1yppxawcffdxakadxasadvaetwad7yp~LdhtLQxawbffxakafxasafvaet>wad<ypSUVVZRRSSZ_defglosvwy}~DGHIJJORRTTVVVY[[\aabcgnpsyy||BCDDDFLOOQQQ[_aamuvwzzFHKLLUXYahinprstxAEFPPSU`bbdfknnnpstuuuww}AFJ]bcdkkmqry{~~CDFLOQ>xawafxakafxasafvaetvaa{dNode6vac<va0{dNode6vac1va0{dNode6vac0wad1ypuxawda00cxaka0xasb0cvaetwad1ypuxawba0xaka0xasa0vaetva1{dNode6vac2va0{dNode6vac0wad1ypzxawda106xaka0xasb06vaetva2{dNode6vac0wad1yp[xaw `a12474027c91fad5a861aa9919817d72xaka2xas ^2474027c91fad5a861aa9919817d72vaetwad0xawba1xaka1xasa1vaesva2{dNode6vac2va0{dNode6vac0wad1ypwxawfa2012axaka0xasd012avaetva6{dNode6vac0wad1ypZxawfa2679axaka6xasd679avaetwad0xawba2xaka2xasa2vaesva4{dNode6vac2va4{dNode6vac0wad1yp^xaw `a4462529ab493676987d946019a14945xaka4xas ^462529ab493676987d946019a14945vaetva6{dNode6vac0wad1ypnxawda46cxaka6xasb6cvaetwad0xawba4xaka4xasa4vaesva5{dNode6vac1va7{dNode6vac0wad1ypYxawga578acfxaka7xase78acfvaetwad1yplxawba5xaka5xasa5vaetva6{dNode6vac3va2{dNode6vac0wad1ypLxawha62186eaxaka2xasf2186eavaetva5{dNode6vac0wad1ypfxawea65bdxaka5xasc5bdvaetva7{dNode6vac0wad1yp@xawda673xaka7xasb73vaetwad0xawba6xaka6xasa6vaesva7{dNode6vac0wad1ypVxawba7xaka7xasa7vaetva9{dNode6vac0wad1ypKxawda98dxaka9xasc98dvaetvac{dNode6vac4vab{dNode6vac0wad1ypRxawdacbaxakabxasbbavaetvaf{dNode6vac0wad1ypsxaweacfacxakafxascfacvaetvad{dNode6vac0wad1ypBxaweacdacxakadxascdacvaetvae{dNode6vac0wad1ypixawdacecxakaexasbecvaetwad9ypU_jjBL]COxawbacxakacxasacvaetvaa{dNode6vac3vaa{dNode6vac1vaa{dNode6vac0wad1ypZxawdaaaaxakaaxasaavaetwad1ypRxawcaaaxakaaxasaavaetvab{dNode6vac2vaf{dNode6vac0wad1ypexawdaabfxakafxasafvaetvae{dNode6vac0wad1yp`xawdaabexakaexasaevaetwad2ypG@xawcaabxakabxasabvaetvac{dNode6vac0wad1yp{xawfaacebfxakacxasdcebfvaetwad<ypTTZhNUBHnsu~J>xawbaaxakaaxasaavaetvab{dNode6vac4vaa{dNode6vac0wad1ypXxawcabaxakaaxasaavaetvad{dNode6vac0wad1ypxaweabdafxakadxascdafvaetvae{dNode6vac0wad1ypAxawcabexakaexasaevaetvac{dNode6vac0wad1ypgxawcabcxakacxasacvaetwad:ypW@W_AtjMlsxawbabxakabxasabvaetvae{dNode6vac3vae{dNode6vac0wad1yphxawcaeexakaexasaevaetvaa{dNode6vac0wad1ypIxawcaeaxakaaxasaavaetvaf{dNode6vac0wad1ypexawdaefexakafxasbfevaetwad6yp_VzrHSxawbaexakaexasaevaetvad{dNode6vac2vab{dNode6vac0wad1ypYxawcadbxakabxasabvaetvac{dNode6vac0wad1ypHxawdadcdxakacxasbcdvaetwad7ypG\e`~GUxawbadxakadxasadvaetvaf{dNode6vac2vaa{dNode6vac0wad1ypOxawfafaebdxakaaxasdaebdvaetvaf{dNode6vac0wad1ypDxawcaffxakafxasafvaetwad8ypK_ezqam@xawbafxakafxasafvaet>wad<ypZUacddefghjnopqvxy~~~DFGHKZZZZ[]defgipuvvADDMOOPQYY]adfglmpqstvFGIIRVVY]__``ghiioo|}~AIPQQ[\`fmqu}}~@BBFFMUWWZ_fjlmmp{@@BBOQQR>xawaaxakaaxasaavaetvab{dNode6vac<va0{dNode6vac0wad1ypcxawdb051xaka0xasc051vaetva1{dNode6vac0wad1ypoxawgb16bdddxaka1xasf16bdddvaetva2{dNode6vac2va6{dNode6vac0wad1ypPxaw `b2621497b3313c97855ed951f0d9b291xaka6xas ^621497b3313c97855ed951f0d9b291vaetva7{dNode6vac0wad1yptxaw `b27bdabd8e1a6b7dc06886867331ceb3xaka7xas ^7bdabd8e1a6b7dc06886867331ceb3vaetwad2ypltxawbb2xaka2xasa2vaetva3{dNode6vac0wad1yp|xaw `b36abffbe5d6a0de73a9968604a1a3f9xaka3xas _36abffbe5d6a0de73a9968604a1a3f9vaetva5{dNode6vac0wad1yp|xawbb5xaka5xasa5vaetva8{dNode6vac0wad1ypFxawdb875xaka8xasc875vaetva9{dNode6vac0wad1ypqxawbb9xaka9xasa9vaetvad{dNode6vac4vab{dNode6vac0wad3ypWxxawcbdbxakabxasabvaetvaa{dNode6vac0wad2ypbjxawcbdaxakaaxasaavaetvae{dNode6vac1vaa{dNode6vac0wad1ypPxawdbdeaxakaaxasaavaetwad2ypBMxawcbdexakaexasaevaetvac{dNode6vac0wad1yp`xawcbdcxakacxasacvaetwad8ypFJLI\_sXxawbbdxakadxasadvaetvab{dNode6vac4vaf{dNode6vac1vab{dNode6vac0wad1ypFxawdbbfbxakabxasabvaetwad1yp`xawcbbfxakafxasafvaetvad{dNode6vac0wad2ypc~xawcbbdxakadxasadvaetvab{dNode6vac4vad{dNode6vac0wad1ypuxawebbbddxakadxasbddvaetvab{dNode6vac0wad1yprxawdbbbbxakabxasabvaetvae{dNode6vac0wad1ypOxawdbbbexakaexasaevaetvac{dNode6vac0wad1ypHxawebbbcaxakacxasbcavaetwad0xawcbbbxakabxasabvaesvae{dNode6vac0wad1ypxawcbbexakaexasaevaetwad4ypT~v]xawbbbxakabxasabvaetvac{dNode6vac4vad{dNode6vac0wad1ypjxawcbcdxakadxasadvaetvab{dNode6vac0wad1ypvxawcbcbxakabxasabvaetvac{dNode6vac1vad{dNode6vac0wad1ypgxawfbccdffxakadxascdffvaetwad1yp]xawcbccxakacxasacvaetvae{dNode6vac0wad1ypxawcbcexakaexasaevaetwad6ypUVGJyxawbbcxakacxasacvaetvaf{dNode6vac4vaa{dNode6vac0wad1ypgxawebfaebxakaaxascaebvaetvaf{dNode6vac0wad1yp{xawhbffdcb5bxakafxasffdcb5bvaetvab{dNode6vac0wad2ypeZxawcbfbxakabxasabvaetvae{dNode6vac0wad1ypixawfbfebadxakaexasdebadvaetwad6ypZT[defxawbbfxakafxasafvaetvae{dNode6vac4vaf{dNode6vac1vaa{dNode6vac0wad1ypSxawdbefaxakaaxasaavaetwad1ypmxawcbefxakafxasafvaetvaa{dNode6vac0wad1yp|xawdbeafxakaaxasbafvaetvab{dNode6vac0wad1ypsxawebebfexakabxascbfevaetvad{dNode6vac0wad1ypKxawcbedxakadxasadvaetwad9ypLZ\f|DSU~xawbbexakaexasaevaetvaa{dNode6vac3vab{dNode6vac2vab{dNode6vac0wad1ypOxawdbabbxakabxasabvaetvac{dNode6vac0wad1ypbxawebabcfxakacxasbcfvaetwad0xawcbabxakabxasabvaesvad{dNode6vac1vaa{dNode6vac0wad1ypRxawebadafxakaaxasbafvaetwad2ypwjxawcbadxakadxasadvaetvae{dNode6vac0wad1ypexawebaefdxakaexascefdvaetwad5ypw{Ejexawbbaxakaaxasaavaet>wad<ypTXXXZ_U`dfwy|~JKLOUUZZ[\\degilv|@BDDFHMNSSYZ]bcflrsuy{EGPQYZZ\_hlnryzz|AGIKKN`abkksswx{|}EFIJKMSTTX]]___bbbcfgkpxxy~CDEGRRR>xawabxakabxasabvaet>wad0xaw`xak`xas`vaesvgisArraysvetitle3xdtypeeRadixvdnode{dNode6vac<va0{dNode6vac<va0{dNode6vac0wad1ypxawb00xaka0xasa0vaetva2{dNode6vac0wad3ypfgxawb02xaka2xasa2vaetva3{dNode6vac0wad2ypO~xawb03xaka3xasa3vaetva4{dNode6vac0wad1yp~xawb04xaka4xasa4vaetva5{dNode6vac0wad1yp}xawb05xaka5xasa5vaetva6{dNode6vac0wad2ypO}xawb06xaka6xasa6vaetva7{dNode6vac1va2{dNode6vac0wad1ypHxawd0724xaka2xasb24vaetwad1yptxawb07xaka7xasa7vaetva8{dNode6vac0wad1ypIxawb08xaka8xasa8vaetva9{dNode6vac0wad2ypuIxawb09xaka9xasa9vaetva系{dNode6vac0wad1yp}xawb0系xaka系xasa系vaetva対{dNode6vac0wad2ypn_xawc0対応xaka対xasb対応vaetva日{dNode6vac0wad1ypxxawc0日目xaka日xasb日目vaet>wad<yprvKVVWWXXYZZ\\]^^beeiq~CILqqsYY[\nnuwADEHJNNnN>xawa0xaka0xasa0vaetva1{dNode6vac9va0{dNode6vac3va0{dNode6vac0wad;ypwxGHIOP}~@xawd100本xaka0xasb0本vaetva章{dNode6vac0wad1ypBxawc10章xaka章xasa章vaetva回{dNode6vac0wad1ypyxawc10回xaka回xasa回vaetwad1ypHxawb10xaka0xasa0vaetva1{dNode6vac0wad1ypHxawb11xaka1xasa1vaetva2{dNode6vac0wad2ypGsxawb12xaka2xasa2vaetva3{dNode6vac2va章{dNode6vac0wad1ypAxawc13章xaka章xasa章vaetvaw{dNode6vac0wad1ypdxawc13wxakawxasawvaetwad0xawb13xaka3xasa3vaesva5{dNode6vac0wad1yp|xawc15章xaka5xasb5章vaetva9{dNode6vac0wad1ypGxawb19xaka9xasa9vaetva回{dNode6vac0wad2ypBbxawb1回xaka回xasa回vaetva日{dNode6vac0wad3ypTr}xawc1日目xaka日xasb日目vaetva章{dNode6vac0wad2ypJixawb1章xaka章xasa章vaetwad<yp{KfpV^aaabbbeimmooqvvzz~CCEEEIILLRRSSSoqqSbE\ccnHHHNN>xawa1xaka1xasa1vaetva2{dNode6vac5va0{dNode6vac4va0{dNode6vac0wad1ypfxawh2009latexaka0xasf09latevaetva1{dNode6vac9va1{dNode6vac0wad3yplpwxawd2011xaka1xasa1vaetva2{dNode6vac0wad7yphpptCL\xawd2012xaka2xasa2vaetva3{dNode6vac0wad:yprszzQSdeefxawd2013xaka3xasa3vaetva4{dNode6vac1va年{dNode6vac0wad1ypDxawe2014年xaka年xasa年vaetwad1yp|xawd2014xaka4xasa4vaetva5{dNode6vac1va年{dNode6vac0wad1ypSxawe2015年xaka年xasa年vaetwad4ypRT{{xawd2015xaka5xasa5vaetva6{dNode6vac1va年{dNode6vac0wad1ypJxawe2016年xaka年xasa年vaetwad1ypIxawd2016xaka6xasa6vaetva7{dNode6vac1va年{dNode6vac0wad1ypExawe2017年xaka年xasa年vaetwad1ypCxawd2017xaka7xasa7vaetva8{dNode6vac1va年{dNode6vac0wad2ypwDxawe2018年xaka年xasa年vaetwad1ypuxawd2018xaka8xasa8vaetva9{dNode6vac1va年{dNode6vac0wad2yp\oxawe2019年xaka年xasa年vaetwad1yphxawd2019xaka9xasa9vaetwad0xawc201xaka1xasa1vaesva2{dNode6vac4va0{dNode6vac0wad:ypluwxDGHIOTxawd2020xaka0xasa0vaetva1{dNode6vac1va年{dNode6vac0wad1yp[xawe2021年xaka年xasa年vaetwad2ypZfxawd2021xaka1xasa1vaetva2{dNode6vac0wad1yp^xawd2022xaka2xasa2vaetva3{dNode6vac0wad1ypRxawd2023xaka3xasa3vaetwad0xawc202xaka2xasa2vaesva追{dNode6vac0wad1ypsxawd20追記xaka追xasb追記vaetwad0xawb20xaka0xasa0vaesva回{dNode6vac0wad1ypAxawb2回xaka回xasa回vaetvan{dNode6vac0wad1ypWxawc2ndxakanxasbndvaetva章{dNode6vac0wad1ypIxawb2章xaka章xasa章vaetva日{dNode6vac0wad1yp|xawc2日目xaka日xasb日目vaetwad<ypYQThzJeqVWXYZ\\]^aem}S_JQ]rDENcnu>xawa2xaka2xasa2vaetva3{dNode6vac5va2{dNode6vac0wad1yp@xawb32xaka2xasa2vaetva章{dNode6vac0wad2ypY[xawb3章xaka章xasa章vaetva回{dNode6vac0wad1yp{xawb3回xaka回xasa回vaetva版{dNode6vac0wad1ypHxawb3版xaka版xasa版vaetva日{dNode6vac0wad1ypzxawc3日目xaka日xasb日目vaetwad<yptdvzz~EIR{MYY[\kAHJoyII>xawa3xaka3xasa3vaetva4{dNode6vac4va0{dNode6vac0wad1yp@xawd4096xaka0xasc096vaetva8{dNode6vac0wad1ypKxawd4897xaka8xasc897vaetva章{dNode6vac0wad3ypUIixawb4章xaka章xasa章vaetva対{dNode6vac0wad1ypoxawc4対応xaka対xasb対応vaetwad<ypcYmuvvzEILoYY[\nnuwG_ty>xawa4xaka4xasa4vaetva5{dNode6vac2va章{dNode6vac0wad1ypSxawb5章xaka章xasa章vaetva回{dNode6vac0wad1ypJxawb5回xaka回xasa回vaetwad:yp]KhmmoqCIkxawa5xaka5xasa5vaetva6{dNode6vac1va章{dNode6vac0wad1ypQxawb6章xaka章xasa章vaetwad8ypabiEoAHJxawa6xaka6xasa6vaetva7{dNode6vac3va対{dNode6vac0wad1ypExawc7対応xaka対xasb対応vaetva回{dNode6vac0wad2yphjxawb7回xaka回xasa回vaetvaつ{dNode6vac0wad:yprrxxzz||}}xawb7つxakaつxasaつvaetwad7ypEEvabMxawa7xaka7xasa7vaetva8{dNode6vac2va章{dNode6vac0wad1ypNxawb8章xaka章xasa章vaetva回{dNode6vac0wad2ypxYxawb8回xaka回xasa回vaetwad3ypzs_xawa8xaka8xasa8vaetva9{dNode6vac2va0{dNode6vac0wad1ypsxawb90xaka0xasa0vaetva章{dNode6vac0wad1ypFxawb9章xaka章xasa章vaetwad1ypvxawa9xaka9xasa9vaetvak{dNode6vac4vaa{dNode6vac0wad1ypQxawfkagomexakaaxaseagomevaetvau{dNode6vac0wad2yp~axawhkuromojixakauxasguromojivaetvao{dNode6vac0wad4yp^acdxawdkopfxakaoxascopfvaetvai{dNode6vac0wad1ypPxawfkibanaxakaixaseibanavaetwad0xawakxakakxasakvaesva-{dNode6vac0wad<ypQVZ\XY^bij|~ABFJJKNQSU]cdefTVV\]^]^acdoquuxx||}}@@KPVVYaanwwzEIJMNOX_iqGHLMNOR>xawa-xaka-xasa-vaetvab{dNode6vac4vao{dNode6vac2vat{dNode6vac0wad1ypQxawcbotxakatxasatvaetvao{dNode6vac0wad8yp|ABFNQSUxawdbookxakaoxasbokvaetwad0xawbboxakaoxasaovaesvae{dNode6vac0wad4ypV\^exawdbetaxakaexascetavaetvay{dNode6vac0wad1yp_xawbbyxakayxasayvaetvaa{dNode6vac0wad1yp\xawibackwardsxakaaxashackwardsvaetwad0xawabxakabxasabvaesvaの{dNode6vac0wad<ypQRRTWXYY[^^_PQRRTUWXZZ\]acefhjllpstuvy{~~@@CCDDDGHIJKLLMMORTVVVXYZ[]cdehhiiklnnorstuuwx{{|}~AABBCCDEFHIIJKLPRRSTVV]dgks||}}@BBDGJKKLOQQW[^_acdhjjlnoprrttv|@DEEILMTUY[\\]]]^abbbgghhinoouwz{|}@AABBDFHHHIIJJMMMOPRX^_`aagiiklorrtuvxxzz||}}@AAGGJJKMMMOQ>xawaのxakaのxasaのvaetvaユ{dNode6vac1vaー{dNode6vac2vaサ{dNode6vac0wad1ypQxawiユーザーサービス化xakaサxaseサービス化vaetvaグ{dNode6vac0wad1ypjxawhユーザーグループxakaグxasdグループvaetwad0xawdユーザーxakaーxasaーvaeswad1ypaxawcユーザxakaユxascユーザvaetva今{dNode6vac2va年{dNode6vac0wad<ypR]^VZ]_`lhuCIR|rha>xawb今年xaka年xasa年vaetva興{dNode6vac0wad1yp[xawc今興味xaka興xasb興味vaetwad0xawa今xaka今xasa今vaesva振{dNode6vac0wad<ypR^ZlhuCIR|rha>xawb振りxaka振xasb振りvaetva返{dNode6vac0wad<ypR^ZlhuCIR|rha>xawb返りxaka返xasb返りvaetvaと{dNode6vac6vaい{dNode6vac1vaか{dNode6vac0wad2ypIIxawdというかxakaかxasaかvaetwad7ypSY^N[Mfxawcというxakaいxasbいうvaetvaし{dNode6vac0wad2ypXtxawcとしてxakaしxasbしてvaetvaこ{dNode6vac0wad1yp[xawcところxakaこxasbころvaetvaり{dNode6vac0wad1ypUxawbとりxakaりxasaりvaetvaき{dNode6vac0wad1ypXxawbときxakaきxasaきvaetvaう{dNode6vac0wad1yp`xawgとうございますxakaうxasfうございますvaetwad<ypRVVWZ[\\^PQZ]deehlt{JRZZdfhouvw{ABCEIPRc|FN_nruDObhuAHIJXaeeffoEEJPQR>xawaとxakaとxasaとvaetva来{dNode6vac2va年{dNode6vac0wad<ypR^ZlhuCIR|rha>xawb来年xaka年xasa年vaetvaま{dNode6vac0wad4ypQSjkxawc来ましxakaまxasbましvaetwad0xawa来xaka来xasa来vaesva抱{dNode6vac0wad<ypR^ZlhuCIR|rha>xawb抱負xaka抱xasb抱負vaetva（{dNode6vac0wad<ypRZ[\^QTUZlphu{|}~ABCIRWYZ[\^_abdefikmoqsuvz|~BEIR^acdersAKRUYZeghiq{|~@AEIJXdfijqtuvyz@IKLM>xawa（xaka（xasa（vaetva）{dNode6vac0wad<ypRZ[\^QTUZlphu{|}~ABCIRWYZ[\^_abdefikmoqsuvz|~BEIR^acdersAKRUYZeghiq{|~@AEIJXdfijqtuvyz@IJKLM>xawa）xaka）xasa）vaetvaO{dNode6vac7var{dNode6vac0wad1ypSxaweOramaxakarxasdramavaetvaD{dNode6vac0wad1ypexawfOData式xakaDxaseData式vaetvac{dNode6vac1va始{dNode6vac0wad1ypXxawnOctopress始めましたxaka始xase始めましたvaetwad3ypglWxawiOctopressxakacxashctopressvaetvap{dNode6vac0wad1ypbxawiOperationxakapxashperationvaetvab{dNode6vac0wad1ypjxawfObjectxakabxasebjectvaetvan{dNode6vac0wad1ypLxawcOnexakanxasbnevaetvaS{dNode6vac0wad1yp^xaweOSSAJxakaSxasdSSAJvaetwad0xawaOxakaOxasaOvaesva検{dNode6vac2va索{dNode6vac5va画{dNode6vac0wad1ypVxawd検索画面xaka画xasb画面vaetva技{dNode6vac1va勉{dNode6vac0wad1yptxawg検索技術勉強会xaka勉xasc勉強会vaetwad1ypdxawd検索技術xaka技xasb技術vaetva対{dNode6vac0wad1yptxawd検索対象xaka対xasb対象vaetva機{dNode6vac0wad1ypcxawd検索機能xaka機xasb機能vaetva座{dNode6vac0wad1ypHxawf検索座談会っxaka座xasd座談会っvaetwad<ypSSUeetzz{{^_feE>xawb検索xaka索xasa索vaetva討{dNode6vac0wad1ypOxawb検討xaka討xasa討vaetwad0xawa検xaka検xasa検vaesvaエ{dNode6vac2vaン{dNode6vac2vaン{dNode6vac0wad1ypSxawdエンジンxakaンxasaンvaetvaニ{dNode6vac1vaサ{dNode6vac0wad1ypexawiエンジニアサポートxakaサxasdサポートvaetwad3yp]bbxaweエンジニアxakaニxasbニアvaetwad0xawcエンジxakaンxasbンジvaesvaコ{dNode6vac0wad1ypBxawfエコシステムxakaコxaseコシステムvaetwad0xawaエxakaエxasaエvaesvaで{dNode6vac2vaき{dNode6vac0wad1ypdxawdできましxakaきxascきましvaetvaる{dNode6vac0wad4yp[P{|xawbでるxakaるxasaるvaetwad<ypST]V\gy@DM^vzFLcwy{@KKQlCEELYY\affMPVV^`gqJM>xawaでxakaでxasaでvaetvaブ{dNode6vac2vaロ{dNode6vac2va記{dNode6vac0wad1ypXxawgブログ記述環境xaka記xasd記述環境vaetva移{dNode6vac0wad5yp]cdefxawgブログ移行日記xaka移xasd移行日記vaetwad4ypS]`Sxawcブログxakaロxasbログvaetvaラ{dNode6vac0wad1yp_xawdブランチxakaラxascランチvaetwad0xawaブxakaブxasaブvaesvaを{dNode6vac0wad<ypSTUSY\^abcdghinoqrsyzDJKMRWXY[]^qsvxyGHLLNOPQU`cjklnpwxy{@GHMNPT[`ikllmquwxy}~ABCDGKWY[^`fgkloq|DFRUVX^gmFJ>xawaをxakaをxasaをvaetva作{dNode6vac4vaっ{dNode6vac0wad4ypSTX^xawb作っxakaっxasaっvaetva成{dNode6vac0wad6ypcor{ABxawb作成xaka成xasa成vaetva業{dNode6vac0wad3ypfuTxawb作業xaka業xasa業vaetvaり{dNode6vac0wad1yp]xawb作りxakaりxasaりvaetwad0xawa作xaka作xasa作vaesvaて{dNode6vac1vaる{dNode6vac0wad1ypDxawbてるxakaるxasaるvaetwad<ypS[_`abbii}JKX\^ssttv}~FHHLXZhlCDKQSZ[\gjopttCD`jkmpwF>xawaてxakaてxasaてvaetvaみ{dNode6vac2vaる{dNode6vac0wad3ypgJKxawbみるxakaるxasaるvaetvaま{dNode6vac0wad4yptFCmxawcみましxakaまxasbましvaetwad<ypSabciXs}~HLlD[\DF>xawaみxakaみxasaみvaetvaた{dNode6vac6vaめ{dNode6vac0wad3ypR]bxawbためxakaめxasaめvaetvaく{dNode6vac0wad1yp\xawbたくxakaくxasaくvaetvaい{dNode6vac0wad1yp_xawbたいxakaいxasaいvaetvaち{dNode6vac0wad2ypTOxawbたちxakaちxasaちvaetvaら{dNode6vac0wad1ypUxawdたらしいxakaらxascらしいvaetvaよ{dNode6vac0wad1ypKxawbたよxakaよxasaよvaetwad<ypSTU\]SV[_`abcddhiknors}EWXY\_abdpqstxyz}~@FFGHLLNOQU`cfghjknpx{@GHKMNPTUVXYZ\`befiklmqswyz{~BCDEEGHJKNQSVY[\\]_`bcdegjkklmoprstvxy~CFGLRSTWYZ\]^bcddeghjklmpw{DEFJJ>xawaたxakaたxasaたvaetvaG{dNode6vac4vao{dNode6vac0wad1ypTxawbGoxakaoxasaovaetvar{dNode6vac2vaa{dNode6vac2vaa{dNode6vac0wad1ypZxawgGraalVMxakaaxasdalVMvaetvan{dNode6vac0wad1ypoxaweGrantxakanxasbntvaetwad0xawcGraxakaaxasaavaesvao{dNode6vac0wad1ypyxawfGroovyxakaoxasdoovyvaetwad0xawbGrxakarxasarvaesvaA{dNode6vac0wad1ypWxawbGAxakaAxasaAvaetvaO{dNode6vac0wad1ypfxawdGOTOxakaOxascOTOvaetwad0xawaGxakaGxasaGvaesvaS{dNode6vac<va3{dNode6vac0wad1yp^xawbS3xaka3xasa3vaetval{dNode6vac0wad2ypTdxaweSlackxakalxasdlackvaetvae{dNode6vac4vaa{dNode6vac2vak{dNode6vac0wad1ypVxawiSearchkitxakakxasckitvaetvaっ{dNode6vac0wad1ypUxawhSearchってxakaっxasbってvaetwad<ypXY\^aagy@CDJKX^tRT>xawfSearchxakaaxasdarchvaetvar{dNode6vac2val{dNode6vac0wad1ypPxawjServerlessxakalxasdlessvaetva日{dNode6vac0wad1ypexawjServer日本語版xaka日xasd日本語版vaetwad1ypixawfServerxakarxasdrvervaetvam{dNode6vac2vaa{dNode6vac0wad2ypYaxawhSemanticxakaaxaseanticvaetvai{dNode6vac0wad1yphxawgSeminarxakaixasdinarvaetwad0xawcSemxakamxasamvaesvan{dNode6vac0wad2ypVVxaweSensexakanxascnsevaetwad0xawbSexakaexasaevaesvat{dNode6vac2vaa{dNode6vac2vat{dNode6vac0wad1ypPxawiStatelessxakatxasftelessvaetvac{dNode6vac0wad6ypEovwEJxaweStackxakacxasbckvaetwad0xawcStaxakaaxasaavaesvau{dNode6vac2vay{dNode6vac0wad1yp^xaweStudyxakayxasayvaetvai{dNode6vac0wad2ypVXxawfStudioxakaixasbiovaetwad0xawdStudxakauxasbudvaeswad0xawbStxakatxasatvaesvac{dNode6vac3vah{dNode6vac0wad1yp\xawfSchemaxakahxasdhemavaetvai{dNode6vac0wad1yppxawgSciencexakaixaseiencevaetvaa{dNode6vac0wad1ypSxaweScalaxakaaxascalavaetwad0xawbScxakacxasacvaesvap{dNode6vac3vae{dNode6vac0wad1yp^xawhSpecificxakaexasfecificvaetvar{dNode6vac0wad1ypCxawfSpringxakarxasdringvaetval{dNode6vac0wad1ypkxawfSplunkxakalxasdlunkvaetwad0xawbSpxakapxasapvaesvao{dNode6vac3vaf{dNode6vac0wad1ypixaweSoflexakafxascflevaetvan{dNode6vac0wad2ypKuxawhSonatypexakanxasfnatypevaetval{dNode6vac2vaJ{dNode6vac0wad5yp~G`lxxawfSolrJPxakaJxasbJPvaetvaC{dNode6vac0wad2ypuvxawiSolrCloudxakaCxaseCloudvaetwad<ypmtvw~GLY[`lnuwxAHIJJ_diotty{I>xawdSolrxakalxasblrvaetwad0xawbSoxakaoxasaovaesvaT{dNode6vac0wad1ypqxawdSTEPxakaTxascTEPvaetvaw{dNode6vac0wad1ypFxawhSwiftypexakawxasgwiftypevaetvah{dNode6vac0wad2ypWsxawfShieldxakahxasehieldvaetvaO{dNode6vac0wad1ypKxawdSOLRxakaOxascOLRvaetvau{dNode6vac0wad2ypQSxawfSummitxakauxaseummitvaetvay{dNode6vac1vaF{dNode6vac0wad1ypHxaw TSynonymFilterFactoryxakaFxasgFactoryvaetwad1ypXxawmSynonymFilterxakayxaslynonymFiltervaet>wad0xawaSxakaSxasaSvaesvaボ{dNode6vac2vaッ{dNode6vac0wad1ypTxawcボットxakaッxasbットvaetvaー{dNode6vac0wad1yp`xawfボードゲームxakaーxaseードゲームvaetwad0xawaボxakaボxasaボvaesva話{dNode6vac1vaし{dNode6vac1vaま{dNode6vac0wad1ypzxawd話しましxakaまxasbましvaetwad1yp^xawb話しxakaしxasaしvaetwad5ypTs{Nfxawa話xaka話xasa話vaetva機{dNode6vac2va械{dNode6vac0wad1ypUxawd機械学習xaka械xasc械学習vaetva能{dNode6vac0wad2yp{@xawb機能xaka能xasa能vaetwad0xawa機xaka機xasa機vaesvaに{dNode6vac4vaよ{dNode6vac0wad1ypUxawcによるxakaよxasbよるvaetvaつ{dNode6vac0wad<yp{LnrSt|}@AOJP>xawdについてxakaつxascついてvaetvaお{dNode6vac0wad1yp]xawdにおけるxakaおxascおけるvaetvaぜ{dNode6vac0wad1yplxawcにぜひxakaぜxasbぜひvaetwad<yp]V_`cdstz{}R\dpfghrOXYZbflouz{CHIJNNQS\\]_bdejkmpqrstxyCGHLPTTWYZ\]bdeghjkpw{DEGJ>xawaにxakaにxasaにvaetvaラ{dNode6vac3vaン{dNode6vac2vaキ{dNode6vac0wad1ypUxaweランキングxakaキxascキングvaetvaダ{dNode6vac0wad1ypAxawgランダムテストxakaダxaseダムテストvaetwad0xawbランxakaンxasaンvaesvaテ{dNode6vac0wad1ypRxawdラティスxakaテxascティスvaetvaイ{dNode6vac0wad1ypAxaweライブラリxakaイxasdイブラリvaetwad0xawaラxakaラxasaラvaesva改{dNode6vac3va善{dNode6vac0wad2ypUxawb改善xaka善xasa善vaetva訂{dNode6vac0wad2ypvwxawc改訂版xaka訂xasb訂版vaetva良{dNode6vac0wad1yp|xawb改良xaka良xasa良vaetwad0xawa改xaka改xasa改vaesvaガ{dNode6vac0wad1ypUxawcガイドxakaガxascガイドvaetva読{dNode6vac3vaみ{dNode6vac1vaま{dNode6vac0wad5ypUgFRgxawd読みましxakaまxasbましvaetwad6ypQhWYl@xawb読みxakaみxasaみvaetvaん{dNode6vac0wad7ypY^[P{|Uxawb読んxakaんxasaんvaetvaめ{dNode6vac0wad1ypgxawc読めるxakaめxasbめるvaetwad0xawa読xaka読xasa読vaesvas{dNode6vac3vae{dNode6vac2vaa{dNode6vac0wad1ypVxawfsearchxakaaxasdarchvaetvar{dNode6vac0wad1ypWxawfserverxakarxasdrvervaetwad0xawbsexakaexasaevaesvat{dNode6vac0wad1yp_xawfstreamxakatxasetreamvaetvao{dNode6vac0wad1ypOxawdsolrxakaoxascolrvaetwad0xawasxakasxasasvaesvaU{dNode6vac3vaI{dNode6vac0wad4ypV{ABxawbUIxakaIxasaIvaetvan{dNode6vac0wad2ypnzxawfUniDicxakanxaseniDicvaetvap{dNode6vac0wad1ypuxawfUpdatexakapxasepdatevaetwad0xawaUxakaUxasaUvaesvaV{dNode6vac6va2{dNode6vac0wad1ypmxawbV2xaka2xasa2vaetvaS{dNode6vac0wad3ypWZ[xawbVSxakaSxasaSvaetvae{dNode6vac0wad1yp^xawhVerticalxakaexasgerticalvaetvai{dNode6vac0wad2ypVXxawfVisualxakaixaseisualvaetvaa{dNode6vac0wad1yplxawgVagrantxakaaxasfagrantvaetvao{dNode6vac0wad2yp]bxawcVolxakaoxasbolvaetwad0xawaVxakaVxasaVvaesva {dNode6vac0wad<ypWWXZZ[[]PPVXXXXYYYYYYYY\\\\^^^^^^^^^`aaabbgghiijjjmmnnoooryy||||}~~@@AAAABBBBCCDDDEEFFFFJJJJJKKKNNNNQQQQSSSSUUUUVVVWWXXXXX]]^^ccddeeffnoppppqqqtttvvw{ABEGJKLLLLLNOQTTTTTTVVVWWXYZ[[\]]]^___aaabbbceghhhhhhilmmmopppqrtuv{{}~@CCEIJLNPPRRSWWWZZ]]bbbbeffijknopqsyzzzzz{{{{BEHHHHJJJNPPPPPPPPQQQQRSSSSTU\\\\\]]]]]_______bbbbcddddeefgjjjkmnopqrrrrrrsssttttuuuxCCCDEGGGHIJJJJKLLLLNPQQQQTTTTUVWWWWWZZbbbbefikllllppprrtuuvvwwwwxxyzz||}}EGGHILLNN>xawa xaka xasa vaetvaC{dNode6vac;vao{dNode6vac5vad{dNode6vac1var{dNode6vac0wad1ypUxaweCoderxakarxasarvaetwad5ypWZ[VXxawdCodexakadxasbdevaetvan{dNode6vac2vat{dNode6vac0wad4ypWXZ[xawiContainerxakatxasftainervaetvaf{dNode6vac0wad2ypdwxawjConferencexakafxasgferencevaetwad0xawcConxakanxasanvaesvag{dNode6vac2vat{dNode6vac0wad8ypX\agy@C^xawiCognitivexakatxasdtivevaetvar{dNode6vac0wad1ypDxawiCognirivexakarxasdrivevaetwad0xaweCognixakagxascgnivaesvar{dNode6vac2van{dNode6vac0wad3ypjnoxaweCornexakanxasbnevaetvae{dNode6vac0wad2yptOxawdCorexakaexasaevaetwad0xawcCorxakarxasarvaesvam{dNode6vac2vaa{dNode6vac0wad2yp]bxawgCompassxakaaxascassvaetvao{dNode6vac0wad1ypKxaw TCompositeTokenFilterxakaoxas PositeTokenFiltervaetwad0xawdCompxakamxasbmpvaeswad0xawbCoxakaoxasaovaesvaS{dNode6vac0wad1yp\xawcCSVxakaSxasbSVvaetvaa{dNode6vac2vas{dNode6vac2vae{dNode6vac0wad1yp^xawdCasexakaexasaevaetvau{dNode6vac0wad1ypbxawfCasualxakauxascualvaetwad0xawcCasxakasxasasvaesval{dNode6vac0wad1ypTxawhCalendarxakalxasflendarvaetwad0xawbCaxakaaxasaavaesvah{dNode6vac2vao{dNode6vac0wad1ypnxawiChocolatexakaoxasgocolatevaetvaa{dNode6vac0wad3yp[\\xawgChangesxakaaxaseangesvaetwad0xawbChxakahxasahvaesvaL{dNode6vac0wad2ypRZxawcCLIxakaLxasbLIvaetval{dNode6vac3vai{dNode6vac0wad1ypXxawfClientxakaixasdientvaetvao{dNode6vac2vaS{dNode6vac0wad2ypZKxawkCloudSearchxakaSxasfSearchvaetvae{dNode6vac0wad4ypzRTUxawhClouderaxakaexasceravaetwad0xaweCloudxakaoxascoudvaesvae{dNode6vac0wad1ypUxaweCleanxakaexasceanvaetwad0xawbClxakalxasalvaesvaf{dNode6vac0wad1yp|xawcCfPxakafxasbfPvaetvaR{dNode6vac0wad4yp{effxaweCROSSxakaRxasdROSSvaetvau{dNode6vac0wad2ypSpxawgCuratorxakauxasfuratorvaetvaC{dNode6vac0wad2ypCpxawcCCCxakaCxasbCCvaetvaJ{dNode6vac0wad1ypHxawcCJKxakaJxasbJKvaetwad0xawaCxakaCxasaCvaesvaD{dNode6vac6vae{dNode6vac3vav{dNode6vac1vae{dNode6vac0wad1yptxawjDevelopersxakaexasgelopersvaetwad4ypWXZ[xawcDevxakavxasavvaetval{dNode6vac0wad1yp_xawfDeletexakalxasdletevaetvas{dNode6vac0wad2ypuvxawfDesignxakasxasdsignvaetwad0xawbDexakaexasaevaesvaI{dNode6vac0wad8yp]bijknorxawcDIYxakaIxasbIYvaetvao{dNode6vac4vam{dNode6vac0wad1yp^xawfDomainxakamxasdmainvaetvaz{dNode6vac0wad1yprxaweDozenxakazxasczenvaetvau{dNode6vac0wad1ypsxawoDoubleArrayTriexakauxasmubleArrayTrievaetvac{dNode6vac0wad1yplxawfDockerxakacxasdckervaetwad0xawbDoxakaoxasaovaesvaa{dNode6vac2vat{dNode6vac0wad1yppxawdDataxakatxasbtavaetvay{dNode6vac0wad2ypQSxawcDayxakayxasayvaetwad0xawbDaxakaaxasaavaesvaB{dNode6vac0wad1ypixawbDBxakaBxasaBvaetvaS{dNode6vac0wad1ypkxawgDSIRNLPxakaSxasfSIRNLPvaetwad0xawaDxakaDxasaDvaesva({dNode6vac0wad<ypWeftuwxz{DGHIOTX]bccddefgt@VX]yCpQSWYZ[\]^_`abcdefghijklmnopqrstvwxyz{|}~@ABCDDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~@ABCDEFGHIJJKLMNOPQRS>xawa(xaka(xasa(vaetvaコ{dNode6vac3vaン{dNode6vac3vaテ{dNode6vac0wad1ypWxawdコンテナxakaテxasbテナvaetvaト{dNode6vac0wad1yp]xawjコントローラーラックxakaトxashトローラーラックvaetvaピ{dNode6vac0wad1yphxawjコンピュータシステムxakaピxashピュータシステムvaetwad0xawbコンxakaンxasaンvaesvaマ{dNode6vac0wad3ypRZQxawdコマンドxakaマxascマンドvaetvaー{dNode6vac2vaヒ{dNode6vac0wad1ypAxawhコーヒーブレイクxakaヒxasfヒーブレイクvaetvaド{dNode6vac0wad1ypgxawkコード・シンプリシティxakaドxasiド・シンプリシティvaetwad0xawbコーxakaーxasaーvaeswad0xawaコxakaコxasaコvaesva名{dNode6vac1va古{dNode6vac0wad2yppwxawc名古屋xaka古xasb古屋vaetwad1ypWxawa名xaka名xasa名vaetva指{dNode6vac0wad3ypWMLxawb指定xaka指xasb指定vaetva){dNode6vac0wad<ypWeftuwxz{DGHIOTX]bccddefgt@VX]yCpQSWYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~@ABCDDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~@ABCDEFGHIJKLMNOPQRS>xawa)xaka)xasa)vaetvaW{dNode6vac5vaS{dNode6vac0wad1ypYxawcWSLxakaSxasbSLvaetvai{dNode6vac2van{dNode6vac2vad{dNode6vac0wad2yppqxawgWindowsxakadxasddowsvaetvat{dNode6vac0wad1ypdxawfWinterxakatxasctervaetwad0xawcWinxakanxasanvaesvak{dNode6vac0wad2ypACxawiWikipediaxakakxasgkipediavaetwad0xawbWixakaixasaivaesvao{dNode6vac2vak{dNode6vac0wad2ypJKxawiWorkplacexakakxasfkplacevaetval{dNode6vac0wad1ypzxaweWorldxakalxasbldvaetwad0xawcWorxakaoxasborvaesvaa{dNode6vac2vat{dNode6vac0wad1ypWxawgWatcherxakatxasetchervaetvaz{dNode6vac0wad1yp_xawdWazaxakazxasbzavaetwad0xawbWaxakaaxasaavaesvae{dNode6vac0wad1yp]xawcWebxakaexasbebvaetwad0xawaWxakaWxasaWvaesvaデ{dNode6vac5vaィ{dNode6vac0wad1ypYxawkディストリビューションxakaィxasjィストリビューションvaetvaー{dNode6vac1vaソ{dNode6vac0wad1yptxawfデータソースxakaソxascソースvaetwad8yptG_CL^eExawcデータxakaーxasbータvaetvaモ{dNode6vac0wad1ypPxawbデモxakaモxasaモvaetvaフ{dNode6vac0wad1yp}xaweデフォルトxakaフxasdフォルトvaetvaジ{dNode6vac0wad1ypWxawiデジタルハリウッドxakaジxashジタルハリウッドvaetwad0xawaデxakaデxasaデvaesva環{dNode6vac1va移{dNode6vac0wad1ypYxawd環境移行xaka移xasb移行vaetwad8yp_cfuTlQJxawb環境xaka環xasb環境vaetvad{dNode6vac2vao{dNode6vac0wad1ypZxawfdockerxakaoxaseockervaetvai{dNode6vac0wad1yplxawgdiscussxakaixasfiscussvaetwad0xawadxakadxasadvaesvac{dNode6vac4vao{dNode6vac2vam{dNode6vac2vap{dNode6vac2vao{dNode6vac2vae{dNode6vac0wad1ypZxawgcomposexakaexasaevaetvai{dNode6vac0wad2ypKMxawlcompositePOSxakaixasfitePOSvaetwad0xawfcomposxakaoxasbosvaesvaa{dNode6vac0wad1yp\xawmcompatibilityxakaaxasiatibilityvaetwad0xawdcompxakapxasapvaesvam{dNode6vac0wad1yp\xawfcommitxakamxascmitvaetwad0xawccomxakamxasamvaesvap{dNode6vac0wad1ypuxawicopyFieldxakapxasgpyFieldvaetwad1yplxawbcoxakaoxasaovaetvar{dNode6vac0wad2yp{exawecrossxakarxasdrossvaetvaw{dNode6vac0wad1ypzxawccwtxakawxasbwtvaetvah{dNode6vac0wad1ypMxawfchasenxakahxasehasenvaetwad0xawacxakacxasacvaesva.{dNode6vac0wad<ypZEvKVVWWXXYYZZ\\]^^aaaabbbbeeeiillmmmmooqqvvvvzzzz}~~CCEEEEIIIILLLNRRSSooqqssOYYYY[[\\]knnntuwAADEEHHJJNN_bccnnotyHHINN>xawa.xaka.xasa.vaetvay{dNode6vac0wad1ypZxawcymlxakayxascymlvaetva対{dNode6vac1va版{dNode6vac0wad1ypLxawc対応版xaka版xasa版vaetwad9ypZjnwzIJMixawb対応xaka対xasb対応vaetva導{dNode6vac0wad3yp[cjxawb導入xaka導xasb導入vaetvaま{dNode6vac4vaだ{dNode6vac0wad2yp[gxawbまだxakaだxasaだvaetvaで{dNode6vac0wad7ypGHIO}~xawbまでxakaでxasaでvaetvaし{dNode6vac0wad<yppyGNOQU`cghjnpxHMPTUVY`befikmswyz{~BGHJ]_`bdklmrsvxyGLWYZ\]bdehl{DEJ>xawbましxakaしxasaしvaetvaす{dNode6vac0wad4ypwZ]fxawbますxakaすxasaすvaetwad0xawaまxakaまxasaまvaesva途{dNode6vac0wad2yp[gxawb途中xaka途xasb途中vaetvap{dNode6vac7var{dNode6vac0wad1yp\xawcprexakarxasbrevaetvai{dNode6vac0wad1ypZxawgpicoclixakaixasficoclivaetval{dNode6vac0wad2ypQVxawfpluginxakalxaseluginvaetvao{dNode6vac0wad1yp\xawfpolicyxakaoxaseolicyvaetvaa{dNode6vac0wad1ypgxawjpaperwhitexakaaxasiaperwhitevaetvaf{dNode6vac0wad1yppxawgpfiopenxakafxasffiopenvaetvay{dNode6vac0wad1yptxawepyfesxakayxasdyfesvaetwad0xawapxakapxasapvaesvav{dNode6vac3va2{dNode6vac0wad3ypijoxawbv2xaka2xasa2vaetvae{dNode6vac0wad1yp\xawdvenvxakaexascenvvaetvaa{dNode6vac0wad1ypJxawhvalidatexakaaxasgalidatevaetwad0xawavxakavxasavvaesvaP{dNode6vac8vay{dNode6vac2vaC{dNode6vac0wad1yp\xawgPyCharmxakaCxaseCharmvaetvat{dNode6vac0wad1yptxawfPythonxakatxasdthonvaetwad0xawbPyxakayxasayvaesvar{dNode6vac2vao{dNode6vac0wad1ypYxawgProductxakaoxaseoductvaetvae{dNode6vac2vat{dNode6vac0wad1yp^xawkPretrainingxakatxashtrainingvaetvap{dNode6vac0wad1ypGxawlPreprocessorxakapxasiprocessorvaetwad0xawcPrexakaexasaevaeswad0xawbPrxakarxasarvaesvaC{dNode6vac0wad1ypkxawbPCxakaCxasaCvaetval{dNode6vac2vau{dNode6vac0wad1ypLxawfPluginxakauxasduginvaetvaa{dNode6vac0wad1ypDxawmPlayFrameworkxakaaxaskayFrameworkvaetwad0xawbPlxakalxasalvaesvaD{dNode6vac0wad1ypvxawcPDFxakaDxasbDFvaetvao{dNode6vac0wad1ypixawjPostgreSQLxakaoxasiostgreSQLvaetvaF{dNode6vac0wad1yppxawcPFIxakaFxasbFIvaetvaa{dNode6vac0wad1ypuxawgPartialxakaaxasfartialvaetwad0xawaPxakaPxasaPvaesva困{dNode6vac0wad2yp\Kxawb困っxaka困xasb困っvaetvaな{dNode6vac6vaる{dNode6vac0wad3yp\IHxawbなるxakaるxasaるvaetvaど{dNode6vac0wad2yp|xawbなどxakaどxasaどvaetvaし{dNode6vac0wad1ypyxawbなしxakaしxasaしvaetvaん{dNode6vac0wad1ypIxawbなんxakaんxasaんvaetvaっ{dNode6vac0wad1yp\xawbなっxakaっxasaっvaetvaい{dNode6vac0wad1ypfxawbないxakaいxasaいvaetwad8yp\_@]jRgxawaなxakaなxasaなvaetva？{dNode6vac1va」{dNode6vac0wad1ypbxawb？」xaka」xasa」vaetwad<yp\rr|DKxFKU~aq>xawa？xaka？xasa？vaetvaも{dNode6vac2vaの{dNode6vac0wad2yp[\xawbものxakaのxasaのvaetvaう{dNode6vac0wad1ypNxaweもうちょっxakaうxasdうちょっvaetwad<yp]V_`kevMgPdg>xawaもxakaもxasaもvaetvaオ{dNode6vac2vaン{dNode6vac0wad5yp]V_`}xaweオンラインxakaンxasdンラインvaetvaー{dNode6vac2vaト{dNode6vac0wad2ypRgxawiオートコンプリートxakaトxasgトコンプリートvaetvaプ{dNode6vac2vaセ{dNode6vac0wad1yppxawhオープンセミナーxakaセxasdセミナーvaetvaソ{dNode6vac0wad1ypBxawgオープンソースxakaソxascソースvaetwad0xawdオープンxakaプxasbプンvaeswad0xawbオーxakaーxasaーvaeswad0xawaオxakaオxasaオvaesvaB{dNode6vac7vae{dNode6vac2var{dNode6vac0wad5yp]V`}gxawfBerlinxakarxasdrlinvaetvat{dNode6vac0wad2ypCLxawdBetaxakatxasbtavaetwad0xawbBexakaexasaevaesvau{dNode6vac2vaz{dNode6vac0wad4yp]V`}xawiBuzzwordsxakazxasgzzwordsvaetvai{dNode6vac0wad1ypDxaweBuildxakaixascildvaetwad0xawbBuxakauxasauvaesvaG{dNode6vac0wad1yp_xawcBGMxakaGxasbGMvaetvai{dNode6vac0wad1yp^xawjBiomedicalxakaixasiiomedicalvaetvaL{dNode6vac0wad3ypbijxawcBLExakaLxasbLEvaetvao{dNode6vac2vao{dNode6vac1vas{dNode6vac0wad1ypmxawhBookscanxakasxasdscanvaetwad1ypWxawdBookxakaoxasbokvaetvan{dNode6vac0wad1yppxawgBonfirexakanxasenfirevaetwad0xawbBoxakaoxasaovaesvaa{dNode6vac2vas{dNode6vac0wad1ypNxaweBashoxakasxascshovaetvar{dNode6vac0wad1yplxawiBarcelonaxakarxasgrcelonavaetwad0xawbBaxakaaxasaavaeswad0xawaBxakaBxasaBvaesva参{dNode6vac1va中{dNode6vac0wad1yprxawc参加中xaka中xasa中vaetwad<yp]VptghlXYbfz{HJ]_bdejkmprstxyCGLWYZ\]bdehpw{EJ>xawb参加xaka参xasb参加vaetvaし{dNode6vac3vaて{dNode6vac0wad6ypcg{@N^xawbしてxakaてxasaてvaetvaま{dNode6vac2vaし{dNode6vac0wad6ypkqYecdxawcしましxakaしxasaしvaetvaす{dNode6vac0wad1ypmxawcしますxakaすxasaすvaetwad0xawbしまxakaまxasaまvaesvaゃ{dNode6vac0wad1yptxawdしゃべっxakaゃxascゃべっvaetwad<yp]SV_`dors}_ptxyFGLNOQU`cfghjnpwxGHMTUVXY`bfiklmwyz{~BEEGHJ]_`bdfjklmprstxy~ACGLWYZ\]bdehpw{DEJJ>xawaしxakaしxasaしvaetva仕{dNode6vac0wad1yp_xawc仕事中xaka仕xasc仕事中vaetvaE{dNode6vac5val{dNode6vac2vas{dNode6vac2va勉{dNode6vac0wad<ypyNOQU`cjnpwxHMT`>xaw PElasticsearch勉強会xaka勉xasc勉強会vaetvaク{dNode6vac0wad1yplxaw QElasticsearchクラスタxakaクxasdクラスタvaetwad<ypPWVqKSTX\]^abeikmoqtvz}DEIORWhns>xawmElasticsearchxakasxasfsearchvaetvaS{dNode6vac1va勉{dNode6vac0wad1ypBxaw PElasticSearch勉強会xaka勉xasc勉強会vaetwad3ypeiCxawmElasticSearchxakaSxasfSearchvaetwad<ypEJKoovwwDEEJ>xawgElasticxakalxasflasticvaetvax{dNode6vac2var{dNode6vac0wad1ypYxawgExtremexakarxasdremevaetvae{dNode6vac0wad1ypqxawhExtendedxakaexaseendedvaetwad0xawcExtxakaxxasbxtvaesvan{dNode6vac1vai{dNode6vac0wad1yptxawkEngineeringxakaixascingvaetwad1yphxawhEngineerxakanxasgngineervaetvam{dNode6vac0wad1ypkxaweEmacsxakamxasdmacsvaetvau{dNode6vac0wad1yplxawgEuroconxakauxasfuroconvaetwad0xawaExakaExasaEvaesvaア{dNode6vac6vaー{dNode6vac0wad2ypPTxawgアーキテクチャxakaーxasfーキテクチャvaetvaッ{dNode6vac0wad2ypSqxawfアップデートxakaッxaseップデートvaetvaプ{dNode6vac0wad1yprxawcアプリxakaプxasbプリvaetvaイ{dNode6vac0wad1ypxxawdアイテムxakaイxascイテムvaetvaク{dNode6vac0wad1ypGxawfアクセスログxakaクxaseクセスログvaetvaジ{dNode6vac0wad1yp\xawmアジャイルデータサイエンスxakaジxaslジャイルデータサイエンスvaetwad0xawaアxakaアxasaアvaesva/{dNode6vac0wad<ypPfuPssYnwAJJ_oyI>xawa/xaka/xasa/vaetvaロ{dNode6vac4vaー{dNode6vac0wad1ypQxawcローマxakaーxasbーマvaetvaギ{dNode6vac0wad1ypCxawdロギングxakaギxascギングvaetvaグ{dNode6vac1va検{dNode6vac0wad1ypPxawdログ検索xaka検xasb検索vaetwad1ypPxawbログxakaグxasaグvaetvaジ{dNode6vac0wad1ypOxawdロジックxakaジxascジックvaetwad0xawaロxakaロxasaロvaesva字{dNode6vac0wad1ypQxawc字入力xaka字xasc字入力vaetvaゆ{dNode6vac0wad1ypQxawbゆれxakaゆxasbゆれvaetvaJ{dNode6vac9vaa{dNode6vac2vap{dNode6vac1vae{dNode6vac0wad1ypQxaw \JapaneseCompletionAnalyzerそのxakaexas WeseCompletionAnalyzerそのvaetwad5ypNdrZwxaweJapanxakapxascpanvaetvav{dNode6vac1vaO{dNode6vac0wad1ypLxawiJavaOneJpxakaOxaseOneJpvaetwad5ypWDELMxawdJavaxakavxasbvavaetwad0xawbJaxakaaxasaavaesvaS{dNode6vac0wad2yp\RxawdJSONxakaSxascSONvaetvau{dNode6vac2vag{dNode6vac0wad<yp]WYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~@ABCDEFGHIJKLMNOPQRS>xaweJugemxakagxascgemvaetvas{dNode6vac0wad1ypgxawlJustTechTalkxakasxasjstTechTalkvaetwad0xawbJuxakauxasauvaesvaJ{dNode6vac0wad5ypz@@CpxawdJJUGxakaJxascJUGvaetvaV{dNode6vac0wad1ypbxawcJVMxakaVxasbVMvaetvaI{dNode6vac0wad2yp^ixawdJIRAxakaIxascIRAvaetvae{dNode6vac0wad1ypjxawiJetBrainsxakaexashetBrainsvaetvaP{dNode6vac0wad1ypGxawbJPxakaPxasaPvaetvaD{dNode6vac0wad2ypGLxawdJDicxakaDxascDicvaetwad0xawaJxakaJxasaJvaesva日{dNode6vac3va用{dNode6vac0wad1ypRxawd日本語用xaka用xasa用vaetva向{dNode6vac0wad1yp@xawe日本語向けxaka向xasb向けvaetva訳{dNode6vac0wad<ypVWXYZ[\]^_abdefikmoqsuvyz~BCEIRp>xawd日本語訳xaka訳xasa訳vaetwad3ypeACxawc日本語xaka日xasc日本語vaetvaA{dNode6vac:van{dNode6vac1var{dNode6vac0wad3ypR~@xawhAnalyzerxakarxasarvaetwad6ypVX{ABqxawgAnalyzexakanxasfnalyzevaetvaz{dNode6vac0wad:ypX\agy@CDX^xaweAzurexakazxasdzurevaetvaP{dNode6vac0wad6ypV_JQWbxawcAPIxakaPxasbPIvaetval{dNode6vac0wad1ypcxawgAlgoliaxakalxasflgoliavaetvap{dNode6vac2vaa{dNode6vac0wad5ypnGIJixawfApachexakaaxasdachevaetvap{dNode6vac0wad1ypDxaweApplexakapxascplevaetwad0xawbApxakapxasapvaesvad{dNode6vac0wad1ypTxawfAdventxakadxasedventvaetvam{dNode6vac0wad2ypZKxawfAmazonxakamxasemazonvaetvag{dNode6vac0wad1yp]xawlAggregationsxakagxaskggregationsvaetvaW{dNode6vac0wad3ypQSmxawcAWSxakaWxasbWSvaetvaL{dNode6vac0wad2ypuwxaweALPHAxakaLxasdLPHAvaetwad0xawaAxakaAxasaAvaesvaH{dNode6vac6vau{dNode6vac0wad4ypSdfgxawdHugoxakauxascugovaetvaT{dNode6vac0wad1yprxawdHTMLxakaTxascTMLvaetvaa{dNode6vac3vat{dNode6vac0wad1yphxawfHatenaxakatxasdtenavaetvad{dNode6vac0wad7ypHdyYhwJxawfHadoopxakadxasddoopvaetvac{dNode6vac0wad1ypTxawdHackxakacxasbckvaetwad0xawbHaxakaaxasaavaesvai{dNode6vac0wad1ypHxawdHivexakaixascivevaetvae{dNode6vac0wad2yp_GxawfHerokuxakaexaseerokuvaetvaS{dNode6vac0wad1ypixawfHSQLDBxakaSxaseSQLDBvaetwad0xawaHxakaHxasaHvaesvaQ{dNode6vac2vaq{dNode6vac0wad2ypTUxawfQuerqyxakaqxasbqyvaetvay{dNode6vac0wad1yp_xaweQueryxakayxasayvaetwad0xawdQuerxakaQxasdQuervaesva調{dNode6vac2va査{dNode6vac0wad2ypTUxawb調査xaka査xasa査vaetvaべ{dNode6vac0wad3ypDKFxawb調べxakaべxasaべvaetwad0xawa調xaka調xasa調vaesvaそ{dNode6vac0wad<ypTUptz{JK]cdef{ffsuv~B>xawbそのxakaそxasbそのvaetva：{dNode6vac0wad1ypTxawa：xaka：xasa：vaetva１{dNode6vac0wad3ypUpvxawa１xaka１xasa１vaetva新{dNode6vac3vaし{dNode6vac0wad3ypWOtxawc新しいxakaしxasbしいvaetva機{dNode6vac0wad3ypXavxawc新機能xaka機xasb機能vaetva規{dNode6vac0wad1ypxxawd新規導入xaka規xasc規導入vaetwad0xawa新xaka新xasa新vaesvaク{dNode6vac2vaラ{dNode6vac2vaイ{dNode6vac1vaプ{dNode6vac0wad1ypVxawkクライアントプラグインxakaプxaseプラグインvaetwad2ypW|xawfクライアントxakaイxasdイアントvaetvaス{dNode6vac0wad1ypyxaweクラスターxakaスxascスターvaetwad0xawbクラxakaラxasaラvaesvaレ{dNode6vac0wad1ypvxawdクレートxakaレxascレートvaetwad0xawaクxakaクxasaクvaesvaイ{dNode6vac4vaン{dNode6vac4vaデ{dNode6vac3vaッ{dNode6vac2vaエ{dNode6vac0wad1ypXxawkインデックスエイリアスxakaエxaseエイリアスvaetvaテ{dNode6vac0wad1ypFxawlインデックステンプレートxakaテxasfテンプレートvaetwad4ypM^kpxawfインデックスxakaッxascックスvaetvaキ{dNode6vac0wad1ypOxawgインデキシングxakaキxasdキシングvaetvaク{dNode6vac0wad1ypAxawgインデクシングxakaクxasdクシングvaetwad0xawcインデxakaデxasaデvaesvaス{dNode6vac0wad1ypJxawfインストールxakaスxasdストールvaetvaポ{dNode6vac0wad1ypGxaweインポートxakaポxascポートvaetvaフ{dNode6vac2va養{dNode6vac0wad1ypPxawmインフラエンジニア養成読本xaka養xasd養成読本vaetva技{dNode6vac0wad1ypYxawmインフラエンジニア技術勉強xaka技xasd技術勉強vaetwad0xawiインフラエンジニアxakaフxasgフラエンジニアvaeswad0xawbインxakaンxasaンvaesvaメ{dNode6vac0wad1yplxawdイメージxakaメxascメージvaetvaベ{dNode6vac0wad1ypkxawdイベントxakaベxascベントvaetvaレ{dNode6vac0wad1ypqxawfイレギュラーxakaレxaseレギュラーvaetwad0xawaイxakaイxasaイvaesvaM{dNode6vac7vau{dNode6vac0wad1ypYxaweMultixakauxasdultivaetvaa{dNode6vac5vat{dNode6vac0wad1ypYxawhMatchingxakatxasftchingvaetvar{dNode6vac3vap{dNode6vac0wad1ypcxawdMarpxakapxasapvaetvak{dNode6vac0wad1ypexawhMarkdownxakakxasekdownvaetvav{dNode6vac0wad3ypW~nxawfMarvelxakavxascvelvaetwad0xawcMarxakarxasarvaesvap{dNode6vac2vap{dNode6vac0wad1ypdxawgMappingxakapxasdpingvaetvaR{dNode6vac0wad1yp]xawdMapRxakaRxasaRvaetwad0xawcMapxakapxasapvaesvav{dNode6vac0wad1ypuxaweMavenxakavxascvenvaetvac{dNode6vac0wad2ypPfxawcMacxakacxasacvaetwad0xawbMaxakaaxasaavaesvaI{dNode6vac2vaC{dNode6vac0wad1yp_xaweMICESxakaCxascCESvaetvaR{dNode6vac0wad1ypvxawcMIRxakaRxasaRvaetwad0xawbMIxakaIxasaIvaesvai{dNode6vac2van{dNode6vac0wad3ypbPfxawdMinixakanxasbnivaetvac{dNode6vac0wad1ypDxawiMicrosoftxakacxasgcrosoftvaetwad0xawbMixakaixasaivaesvae{dNode6vac2vae{dNode6vac0wad5yp{J_GZxawfMeetupxakaexasdetupvaetvaC{dNode6vac0wad2ypGLxaweMeCabxakaCxascCabvaetwad0xawbMexakaexasaevaesvao{dNode6vac3var{dNode6vac0wad2ypDFxawjMorphlinesxakarxashrphlinesvaetvau{dNode6vac0wad1ypqxawhMountainxakauxasfuntainvaetvan{dNode6vac0wad1ypjxawgMongoDBxakanxasengoDBvaetwad0xawbMoxakaoxasaovaesvaB{dNode6vac0wad6ypqfs~BCxawcMBAxakaBxasbBAvaetwad0xawaMxakaMxasaMvaesval{dNode6vac3vaa{dNode6vac0wad1ypYxawelabelxakaaxasdabelvaetvau{dNode6vac1vau{dNode6vac0wad2yp~xawjluceneutilxakauxasdutilvaetwad<ypoYnwzEIJMNOX_iqHNOR>xawflucenexakauxaseucenevaetvao{dNode6vac2vaa{dNode6vac0wad1ypDxawhloadSolrxakaaxasfadSolrvaetvag{dNode6vac0wad1ypPxawfloggenxakagxasdggenvaetwad0xawbloxakaoxasaovaeswad0xawalxakalxasalvaesvaL{dNode6vac5vae{dNode6vac0wad1ypYxawhLearningxakaexasgearningvaetvai{dNode6vac5vat{dNode6vac0wad1yp^xawjLiteraturexakatxashteraturevaetvag{dNode6vac0wad2ypjoxaweLightxakagxascghtvaetvan{dNode6vac0wad1ypsxawgLinderaxakanxasenderavaetvao{dNode6vac0wad1ypqxawdLionxakaoxasbonvaetvav{dNode6vac0wad1ypkxawdLivexakavxasbvevaetwad0xawbLixakaixasaivaesvau{dNode6vac2van{dNode6vac0wad1ypbxawgLunakeyxakanxasenakeyvaetvac{dNode6vac2vae{dNode6vac0wad<ypnL@Y\nwAJ_loyI>xawfLucenexakaexascenevaetvai{dNode6vac0wad1ypoxaweLucidxakaixasbidvaetwad0xawcLucxakacxasacvaeswad0xawbLuxakauxasauvaesvaP{dNode6vac0wad3ypbijxawdLPMExakaPxascPMEvaetvao{dNode6vac0wad6ypZkBCFGxawhLogstashxakaoxasgogstashvaetwad0xawaLxakaLxasaLvaesvaf{dNode6vac2vao{dNode6vac0wad5ypY^LGLxawcforxakaoxasborvaetval{dNode6vac1vad{dNode6vac0wad2ypPrxawgfluentdxakadxasadvaetwad1ypVxawffluentxakalxaseluentvaetwad0xawafxakafxasafvaesvai{dNode6vac1vaq{dNode6vac0wad1ypxawjinquisitorxakaqxashquisitorvaetwad4ypYp\rxawbinxakaixasbinvaetva論{dNode6vac0wad2ypY^xawb論文xaka論xasb論文vaetvaだ{dNode6vac2vaけ{dNode6vac0wad1ypDxawbだけxakaけxasaけvaetvaら{dNode6vac0wad1ypfxawbだらxakaらxasaらvaetwad3ypY^Uxawaだxakaだxasaだvaetvaか{dNode6vac2vaっ{dNode6vac0wad1yp[xawbかっxakaっxasaっvaetvaら{dNode6vac1vaお{dNode6vac0wad1ypgxawcからおxakaおxasaおvaetwad<ypGHIOg}~iRiqAQ>xawbからxakaらxasaらvaetwad1ypVxawaかxakaかxasaかvaetva良{dNode6vac0wad1yp[xawc良かっxaka良xasc良かっvaetvaI{dNode6vac5van{dNode6vac2vad{dNode6vac0wad2yp\mxaweIndexxakadxascdexvaetvag{dNode6vac2vas{dNode6vac0wad1ypLxawfIngestxakasxasbstvaetvar{dNode6vac0wad1ypoxawiIngersollxakarxasersollvaetwad0xawdIngexakagxasbgevaeswad0xawbInxakanxasanvaesvaO{dNode6vac1va化{dNode6vac0wad2ypbixawdIO化しxaka化xasb化しvaetwad1ypjxawbIOxakaOxasaOvaetvas{dNode6vac0wad2yp}@xaweIssuexakasxasdssuevaetvaD{dNode6vac0wad1ypFxawbIDxakaDxasaDvaetvao{dNode6vac0wad2yprxxawbIoxakaoxasaovaetwad0xawaIxakaIxasaIvaesva見{dNode6vac2vaた{dNode6vac0wad1ypDxawb見たxakaたxasaたvaetvaま{dNode6vac0wad1ypKxawc見ましxakaまxasbましvaetwad1yp\xawa見xaka見xasa見vaetvaキ{dNode6vac2vaボ{dNode6vac0wad7yp]bijnorxaweキーボードxakaボxascボードvaetvaワ{dNode6vac0wad1ypqxaweキーワードxakaワxascワードvaetwad0xawbキーxakaキxasbキーvaesva:{dNode6vac0wad2yp^pxawa:xaka:xasa:vaetvao{dNode6vac2van{dNode6vac0wad1yp^xawbonxakanxasanvaetvar{dNode6vac0wad1ypHxawgoreillyxakarxasfreillyvaetwad0xawaoxakaoxasaovaesva出{dNode6vac4va張{dNode6vac0wad3yp_`}xawb出張xaka張xasa張vaetva力{dNode6vac1va方{dNode6vac0wad1ypMxawe出力方法例xaka方xasc方法例vaetwad2ypRRxawb出力xaka力xasa力vaetvaす{dNode6vac0wad1ypLxawb出すxakaすxasaすvaetvaて{dNode6vac0wad1ypKxawb出てxakaてxasaてvaetwad1ypUxawa出xaka出xasa出vaetva、{dNode6vac0wad<ypabiP||WWUbf{~>xawa、xaka、xasa、vaetva試{dNode6vac0wad2ypaWxawb試しxaka試xasb試しvaetva組{dNode6vac0wad3ypbinxawb組みxaka組xasb組みvaetva立{dNode6vac0wad3ypbinxawb立てxaka立xasb立てvaetva+{dNode6vac0wad7ypbijPPP_xawa+xaka+xasa+vaetva#{dNode6vac0wad<ypbhijnorpLNOQU`cghhjnpprx{@HMNTXZ`bkyz{{~BGHJJQS]__`bdeijklmprrstxyGLQTWY\>xawa#xaka#xasa#vaetvaス{dNode6vac6vaラ{dNode6vac0wad2ypclxawdスライドxakaラxascライドvaetvaポ{dNode6vac0wad1yp|xaweスポンサーxakaポxasdポンサーvaetvaク{dNode6vac0wad1ypyxaweスクリプトxakaクxasdクリプトvaetvaキ{dNode6vac2vaー{dNode6vac0wad1ypKxawiスキーマレスモードxakaーxasgーマレスモードvaetvaル{dNode6vac0wad2yp]bxawfスキルアップxakaルxasdルアップvaetwad0xawbスキxakaキxasaキvaesvaマ{dNode6vac0wad1ypbxawcスマホxakaマxasbマホvaetvaス{dNode6vac0wad1ypBxawcススメxakaスxasbスメvaetwad0xawaスxakaスxasaスvaesva関{dNode6vac0wad7ypdtz{OoGxawc関するxaka関xasc関するvaetva情{dNode6vac0wad4ypd|eExawb情報xaka情xasb情報vaetva交{dNode6vac0wad2ypdExawb交換xaka交xasb交換vaetva目{dNode6vac0wad1ypdxawb目的xaka目xasb目的vaetvaが{dNode6vac0wad<ypdEiFM\esEUY\f~K[>xawaがxakaがxasaがvaetva！{dNode6vac0wad:ypdZkyzBH]bkxawa！xaka！xasa！vaetvaN{dNode6vac6vaG{dNode6vac0wad1ypexaweNGramxakaGxasdGramvaetvaa{dNode6vac0wad1yphxawdNandxakaaxascandvaetvaE{dNode6vac2vaX{dNode6vac0wad1ypqxawdNEXTxakaXxasbXTvaetvao{dNode6vac0wad1ypLxawgNEologdxakaoxaseologdvaetwad0xawbNExakaExasaEvaesvai{dNode6vac0wad1ypfxaweNightxakaixasdightvaetvae{dNode6vac2vas{dNode6vac0wad1ypjxawfNestedxakasxasdstedvaetvaw{dNode6vac0wad2ypuvxawcNewxakawxasawvaetwad0xawbNexakaexasaevaesvaA{dNode6vac0wad2ypGLxaweNAISTxakaAxasdAISTvaetwad0xawaNxakaNxasaNvaesvaフ{dNode6vac4vaレ{dNode6vac0wad1ypexawdフレーズxakaレxascレーズvaetvaリ{dNode6vac0wad1ypbxawfフリーランスxakaリxaseリーランスvaetvaァ{dNode6vac3vaイ{dNode6vac0wad2ypeAxawdファイルxakaイxasbイルvaetvaー{dNode6vac0wad1ypWxawmファーストインプレッションxakaーxaskーストインプレッションvaetvaセ{dNode6vac0wad1yp]xaweファセットxakaセxascセットvaetwad0xawbファxakaァxasaァvaesvaィ{dNode6vac0wad1ypjxaweフィールドxakaィxasdィールドvaetwad0xawaフxakaフxasaフvaesva自{dNode6vac4va宅{dNode6vac0wad3ypfuTxawb自宅xaka宅xasa宅vaetva作{dNode6vac0wad1yprxawb自作xaka作xasa作vaetva然{dNode6vac0wad1ypPxawf自然言語処理xaka然xase然言語処理vaetva分{dNode6vac0wad1ypRxawb自分xaka分xasa分vaetwad0xawa自xaka自xasa自vaesvaや{dNode6vac2vaり{dNode6vac0wad1yp_xawdやりましxakaりxascりましvaetvaっ{dNode6vac0wad5yps}~Hxawbやっxakaっxasaっvaetwad3ypgggxawaやxakaやxasaやvaetvaサ{dNode6vac3vaジ{dNode6vac0wad1ypgxaweサジェストxakaジxasdジェストvaetvaー{dNode6vac2vaバ{dNode6vac0wad1ypPxawcサーバxakaバxasaバvaetvaビ{dNode6vac0wad1yp]xawdサービスxakaビxasbビスvaetwad0xawbサーxakaーxasaーvaesvaン{dNode6vac0wad3ypIJixawdサンプルxakaンxascンプルvaetwad0xawaサxakaサxasaサvaesva「{dNode6vac0wad<yph_PZ]bgFIJRRggirxz|}>xawa「xaka「xasa「vaetva理{dNode6vac0wad1yphxawb理論xaka理xasb理論vaetva実{dNode6vac3va装{dNode6vac0wad2yphGxawb実装xaka装xasa装vaetva践{dNode6vac1va入{dNode6vac0wad1ypkxawd実践入門xaka入xasb入門vaetwad3ypY[axawb実践xaka践xasa践vaetva行{dNode6vac0wad2ypyQxawb実行xaka行xasa行vaetwad0xawa実xaka実xasa実vaesva」{dNode6vac0wad<yph_PZ]gkFIJRRggirxz|}>xawa」xaka」xasa」vaetva始{dNode6vac1vaま{dNode6vac0wad1ypSxawd始めましxakaまxasbましvaetwad3yphWtxawb始めxaka始xasb始めvaetvaT{dNode6vac6vae{dNode6vac4vat{dNode6vac0wad1yphxawfTetrisxakatxasdtrisvaetvam{dNode6vac0wad1ypmxawhTemplatexakamxasfmplatevaetvar{dNode6vac0wad1ypyxawiTerraformxakarxasgrraformvaetvac{dNode6vac0wad3ypt]bxawdTechxakacxasbchvaetwad0xawbTexakaexasaevaesvaa{dNode6vac1vas{dNode6vac0wad1ypbxaweTalksxakasxasasvaetwad1yptxawdTalkxakaaxascalkvaetvai{dNode6vac0wad1ypTxawhTimelionxakaixasgimelionvaetvao{dNode6vac2vay{dNode6vac0wad6yphzJQSLxaweTokyoxakayxasbyovaetvae{dNode6vac0wad1ypOxawkTokenFilterxakaexashenFiltervaetwad0xawcTokxakaoxasbokvaesvar{dNode6vac0wad1yp_xawlTreasureDataxakarxaskreasureDatavaetvaw{dNode6vac0wad6yps~QTWbxawgTwitterxakawxasfwittervaetwad0xawaTxakaTxasaTvaesvaへ{dNode6vac0wad9ypp~gk_t^iBxawaへxakaへxasaへvaetva移{dNode6vac2va行{dNode6vac1va中{dNode6vac0wad1ypgxawc移行中xaka中xasa中vaetwad4ypp]kixawb移行xaka行xasa行vaetva植{dNode6vac0wad<ypWYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~@ABCDEFGHIJKLMNOPQRS>xawb移植xaka植xasa植vaetwad0xawa移xaka移xasa移vaesvaお{dNode6vac3va試{dNode6vac0wad1ypqxawcお試しxaka試xasb試しvaetvaよ{dNode6vac0wad9ypabmvzEISxawcおよびxakaよxasbよびvaetvaめ{dNode6vac0wad1yp`xawbおめxakaめxasaめvaetwad1ypexawaおxakaおxasaおvaetva中{dNode6vac2va身{dNode6vac0wad1yp]xawe中身説明会xaka身xasd身説明会vaetva心{dNode6vac0wad1ypJxawb中心xaka心xasa心vaetwad2ypqWxawa中xaka中xasa中vaetvaF{dNode6vac5vaS{dNode6vac0wad1ypsxawcFSTxakaSxasbSTvaetvao{dNode6vac0wad1ypfxaweFoundxakaoxasdoundvaetval{dNode6vac0wad2yprZxawgFluentdxakalxasfluentdvaetvae{dNode6vac0wad1yptxaweFestaxakaexasdestavaetvaa{dNode6vac0wad2yppwxawdFallxakaaxascallvaetwad0xawaFxakaFxasaFvaesva変{dNode6vac2va更{dNode6vac0wad3yps]Bxawb変更xaka更xasa更vaetva換{dNode6vac0wad1ypexawb変換xaka換xasa換vaetwad0xawa変xaka変xasa変vaesvaシ{dNode6vac0wad7yptzz{{_~xawdシステムxakaシxasdシステムvaetva妄{dNode6vac1va版{dNode6vac0wad1ypRxawc妄想版xaka版xasa版vaetwad3yptz{xawb妄想xaka妄xasb妄想vaetvam{dNode6vac2vae{dNode6vac2vat{dNode6vac0wad1ypvxawgmeteredxakatxaseteredvaetvae{dNode6vac0wad1yprxawfmeetupxakaexasdetupvaetwad0xawbmexakaexasaevaesvaa{dNode6vac0wad1ypixawemacOSxakaaxasdacOSvaetwad0xawamxakamxasamvaesva紹{dNode6vac0wad<ypv`vxTV}@^acdn>xawb紹介xaka紹xasb紹介vaetva第{dNode6vac;va0{dNode6vac0wad1ypTxawc第0回xaka0xasb0回vaetva1{dNode6vac9va0{dNode6vac0wad2ypj`xawd第10回xaka0xasb0回vaetva1{dNode6vac0wad2yp`Gxawd第11回xaka1xasb1回vaetva2{dNode6vac0wad1yp~xawd第12回xaka2xasb2回vaetva3{dNode6vac0wad2ypUmxawd第13回xaka3xasb3回vaetva4{dNode6vac0wad1ypQxawd第14回xaka4xasb4回vaetva5{dNode6vac0wad1ypOxawd第15回xaka5xasb5回vaetva6{dNode6vac0wad1ypNxawd第16回xaka6xasb6回vaetva章{dNode6vac0wad5ypIO}~xawc第1章xaka章xasa章vaetva回{dNode6vac0wad2ypBExawc第1回xaka回xasa回vaetwad0xawb第1xaka1xasa1vaesva2{dNode6vac3va5{dNode6vac0wad1ypyxawd第25回xaka5xasb5回vaetva章{dNode6vac0wad2ypGHxawc第2章xaka章xasa章vaetva回{dNode6vac0wad2ypyexawc第2回xaka回xasa回vaetwad1ypbxawb第2xaka2xasa2vaetva3{dNode6vac2va章{dNode6vac0wad1ypxxawe第3章終了xaka章xasc章終了vaetva回{dNode6vac0wad1ypkxawc第3回xaka回xasa回vaetwad0xawb第3xaka3xasa3vaesva4{dNode6vac2va章{dNode6vac0wad1ypwxawe第4章終了xaka章xasc章終了vaetva回{dNode6vac0wad2yp`Wxawc第4回xaka回xasa回vaetwad0xawb第4xaka4xasa4vaesva5{dNode6vac0wad2ypTQxawc第5回xaka5xasb5回vaetva6{dNode6vac0wad2ypM{xawc第6回xaka6xasb6回vaetva7{dNode6vac0wad1ypHxawc第7回xaka7xasb7回vaetva8{dNode6vac0wad1ypxxawc第8回xaka8xasb8回vaetva9{dNode6vac0wad2ypnlxawc第9回xaka9xasb9回vaetva一{dNode6vac2va印{dNode6vac0wad1ypnxawd第一印象xaka印xasb印象vaetva回{dNode6vac0wad1ypjxawc第一回xaka回xasa回vaetwad0xawb第一xaka一xasa一vaeswad<yp|ABFNQSU{ABHyYhjJ>xawa第xaka第xasa第vaetva言{dNode6vac1va処{dNode6vac1va勉{dNode6vac0wad2ypeExawg言語処理勉強会xaka勉xasc勉強会vaetwad;ypwxGHIOP}~@xawd言語処理xaka処xasb処理vaetwad5yprxz|}xawb言語xaka言xasb言語vaetvaノ{dNode6vac0wad;ypwxGHIOP}~@xawcノックxakaノxascノックvaetva起{dNode6vac0wad3ypyJlxawb起動xaka起xasb起動vaetva構{dNode6vac2va成{dNode6vac0wad2ypzQxawb構成xaka成xasa成vaetva造{dNode6vac0wad2ypeExawb構造xaka造xasa造vaetwad0xawa構xaka構xasa構vaesvaす{dNode6vac3vaる{dNode6vac0wad3ypzRXxawbするxakaるxasaるvaetvaば{dNode6vac0wad1ypdxaweすばらしいxakaばxasdばらしいvaetvaず{dNode6vac0wad1yplxawfすずけんさんxakaずxaseずけんさんvaetwad2ypYfxawaすxakaすxasaすvaetvaパ{dNode6vac3vaー{dNode6vac0wad1ypzxawcパーツxakaーxasbーツvaetvaッ{dNode6vac0wad1ypnxawcパッチxakaッxasbッチvaetvaフ{dNode6vac0wad1ypOxawgパフォーマンスxakaフxasfフォーマンスvaetwad0xawaパxakaパxasaパvaesva特{dNode6vac0wad1yp{xawb特徴xaka特xasb特徴vaetvaR{dNode6vac4vau{dNode6vac2vas{dNode6vac0wad<yp|ABFNQSUWY[a@>xawdRustxakasxasbstvaetvab{dNode6vac0wad3ypz|}xawdRubyxakabxasbbyvaetwad0xawbRuxakauxasauvaesvae{dNode6vac3val{dNode6vac0wad1yp[xawgReleasexakalxaseleasevaetvap{dNode6vac0wad1yp_xawfReportxakapxasdportvaetvaa{dNode6vac0wad2yp{|xawfReadmexakaaxasdadmevaetwad0xawbRexakaexasaevaesvaC{dNode6vac0wad1ypqxawbRCxakaCxasaCvaetvai{dNode6vac0wad2yp{JxawdRiakxakaixasciakvaetwad0xawaRxakaRxasaRvaesvat{dNode6vac4vah{dNode6vac0wad9yp|ABFNQSUWxawcthexakahxasbhevaetvae{dNode6vac0wad2yp]bxawftecompxakaexaseecompvaetvaw{dNode6vac0wad4ypsQTWxawdtwtrxakawxascwtrvaetvar{dNode6vac0wad2ypAtxawetrunkxakarxasdrunkvaetwad0xawatxakatxasatvaesva性{dNode6vac0wad1yp~xawb性能xaka性xasb性能vaetvaテ{dNode6vac2vaス{dNode6vac1vaケ{dNode6vac0wad1ypxawfテストケースxakaケxascケースvaetwad2yp~Mxawcテストxakaスxasbストvaetvaー{dNode6vac0wad2ypdfxawcテーマxakaーxasbーマvaetwad0xawaテxakaテxasaテvaesva追{dNode6vac2va加{dNode6vac0wad4yp~R@xawb追加xaka加xasa加vaetva跡{dNode6vac0wad1yp~xawb追跡xaka跡xasa跡vaetwad0xawa追xaka追xasa追vaesvaマ{dNode6vac0wad1ypxaweマニアックxakaマxaseマニアックvaetvaツ{dNode6vac0wad2ypXxawcツールxakaツxascツールvaetvaセ{dNode6vac3vaッ{dNode6vac2vaト{dNode6vac0wad7ypffs~BCxawfセットアップxakaトxasdトアップvaetvaシ{dNode6vac0wad2ypDfxaweセッションxakaシxascションvaetwad0xawbセッxakaッxasaッvaesvaキ{dNode6vac0wad1ypsxawfセキュリティxakaキxaseキュリティvaetvaミ{dNode6vac0wad2ypHmxawdセミナーxakaミxascミナーvaetwad0xawaセxakaセxasaセvaesva違{dNode6vac0wad1yp@xawb違いxaka違xasb違いvaetvaリ{dNode6vac4vaク{dNode6vac0wad1ypCxaweリクエストxakaクxasdクエストvaetvaリ{dNode6vac0wad<ypEWXYZ\^abeimoqsvz~CEILRoqsuYnEJNOcnyHIN>xawdリリースxakaリxascリースvaetvaフ{dNode6vac0wad1ypdxawhリファクタリングxakaフxasgファクタリングvaetvaソ{dNode6vac0wad1ypxawdリソースxakaソxascソースvaetwad0xawaリxakaリxasaリvaesvaメ{dNode6vac2vaモ{dNode6vac0wad5ypDlERKxawbメモxakaモxasaモvaetvaイ{dNode6vac0wad1ypqxawcメインxakaイxasbインvaetwad0xawaメxakaメxasaメvaesvaさ{dNode6vac2vaら{dNode6vac0wad1ypfxawbさらxakaらxasaらvaetvaん{dNode6vac0wad1ypoxawbさんxakaんxasaんvaetwad3ypEesxawaさxakaさxasaさvaetvaれ{dNode6vac0wad3ypEesxawaれxakaれxasaれvaetva触{dNode6vac0wad4ypJKFDxawb触っxaka触xasb触っvaetva辞{dNode6vac1va分{dNode6vac0wad1ypxawd辞書分離xaka分xasb分離vaetwad7ypLMaoAPPxawb辞書xaka辞xasb辞書vaetva更{dNode6vac0wad3ypL_`xawb更新xaka更xasb更新vaetva注{dNode6vac0wad4ypLosXxawc注意点xaka注xasc注意点vaetvaK{dNode6vac2vau{dNode6vac0wad9ypMRZnLAIJFxawhKuromojixakauxasguromojivaetvai{dNode6vac2vab{dNode6vac0wad6yp{ABYuMxawfKibanaxakabxasdbanavaetvan{dNode6vac0wad1ypgxawfKindlexakanxasdndlevaetwad0xawbKixakaixasaivaeswad0xawaKxakaKxasaKvaesvaカ{dNode6vac2vaス{dNode6vac0wad2ypMPxawdカスタムxakaスxascスタムvaetvaン{dNode6vac0wad1yp|xawgカンファレンスxakaンxasfンファレンスvaetwad0xawaカxakaカxasaカvaesva設{dNode6vac2va定{dNode6vac0wad3ypMdHxawb設定xaka定xasa定vaetva計{dNode6vac0wad1ypJxawe設計手法等xaka計xasd計手法等vaetwad0xawa設xaka設xasa設vaesva再{dNode6vac1vaび{dNode6vac0wad1ypPxawb再びxakaびxasaびvaetwad1ypkxawa再xaka再xasa再vaetvaプ{dNode6vac2vaラ{dNode6vac0wad<ypX{AB_sBhtu}C>xaweプラグインxakaラxasdラグインvaetvaロ{dNode6vac2vaキ{dNode6vac0wad1ypQxawdプロキシxakaキxasbキシvaetvaグ{dNode6vac0wad1ypHxawgプログラミングxakaグxaseグラミングvaetwad0xawbプロxakaロxasaロvaeswad0xawaプxakaプxasaプvaesva入{dNode6vac4va門{dNode6vac0wad:ypY[aNvwFIJixawb入門xaka門xasa門vaetvaっ{dNode6vac0wad1ypvxawb入っxakaっxasaっvaetvaれ{dNode6vac0wad2yphCxawb入れxakaれxasaれvaetva信{dNode6vac0wad1ypDxawb入信xaka信xasa信vaetwad0xawa入xaka入xasa入vaesva終{dNode6vac0wad1ypYxawc終わっxaka終xasc終わっvaetva買{dNode6vac2vaっ{dNode6vac0wad1yp\xawb買っxakaっxasaっvaetvaい{dNode6vac0wad1ypcxawd買いましxakaいxascいましvaetwad0xawa買xaka買xasa買vaesvaよ{dNode6vac4vaか{dNode6vac0wad1yp\xawcよかっxakaかxasbかっvaetvaく{dNode6vac1vaわ{dNode6vac0wad1ypZxaweよくわかるxakaわxascわかるvaetwad1ypMxawbよくxakaくxasaくvaetvaり{dNode6vac1vaも{dNode6vac0wad1yp]xawcよりもxakaもxasaもvaetwad<ypWYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~@ABCDEFGHIJKLMNOPQRS>xawbよりxakaりxasaりvaetvaう{dNode6vac0wad1ypgxawbようxakaうxasaうvaetwad0xawaよxakaよxasaよvaesva探{dNode6vac3va訪{dNode6vac0wad1yp_xawb探訪xaka訪xasa訪vaetvaし{dNode6vac0wad1yp|xawb探しxakaしxasaしvaetva索{dNode6vac0wad1ypOxawb探索xaka索xasa索vaetwad0xawa探xaka探xasa探vaesva={dNode6vac0wad2yp_Pxawa=xaka=xasa=vaetva>{dNode6vac0wad1yp_xawa>xaka>xasa>vaetvaは{dNode6vac0wad:ypab@D_gbVRSxawaはxakaはxasaはvaetvaじ{dNode6vac2vaま{dNode6vac2vaし{dNode6vac0wad3ypab@xawdじめましxakaしxasaしvaetvaす{dNode6vac0wad1ypSxawdじめますxakaすxasaすvaetwad0xawcじめまxakaまxasaまvaesvaる{dNode6vac0wad1ypVxawcじめるxakaるxasaるvaetwad0xawbじめxakaじxasbじめvaesva仮{dNode6vac1va実{dNode6vac0wad1ypLxawc仮実装xaka実xasb実装vaetwad2ypb@xawa仮xaka仮xasa仮vaetva微{dNode6vac0wad1ypdxawc微調整xaka微xasc微調整vaetva合{dNode6vac0wad1ypdxawb合わxaka合xasb合わvaetvaせ{dNode6vac0wad1ypdxawaせxakaせxasaせvaetva標{dNode6vac0wad1ypixawb標準xaka標xasb標準vaetvaタ{dNode6vac0wad1ypixaweターミナルxakaタxaseターミナルvaetvaウ{dNode6vac0wad1ypixawiウィンドウグループxakaウxasiウィンドウグループvaetva便{dNode6vac1va機{dNode6vac0wad1ypKxawf便利機能紹介xaka機xasd機能紹介vaetwad1ypixawb便利xaka便xasb便利vaetvah{dNode6vac4vao{dNode6vac0wad1ypjxawihomeshickxakaoxashomeshickvaetvaa{dNode6vac4vav{dNode6vac0wad1yp[xawdhavexakavxasbvevaetvat{dNode6vac0wad1yphxawjhatenatechxakatxashtenatechvaetvac{dNode6vac0wad4ypsQTWxawdhackxakacxasbckvaetvad{dNode6vac0wad2ypyYxawmhadoopreadingxakadxaskdoopreadingvaetwad0xawbhaxakaaxasaavaesvae{dNode6vac0wad2yp_Gxawhherokujpxakaexasgerokujpvaetvac{dNode6vac0wad1ypdxawchcjxakacxasbcjvaetwad0xawahxakahxasahvaesvaz{dNode6vac2vas{dNode6vac0wad1ypkxawczshxakasxasbshvaetvao{dNode6vac0wad1ypVxawlzoomdata作りましxakaoxaskoomdata作りましvaetwad0xawazxakazxasazvaesva化{dNode6vac0wad1yplxawa化xaka化xasa化vaetva退{dNode6vac0wad2ypmVxawb退職xaka退xasb退職vaetvaビ{dNode6vac2vaル{dNode6vac0wad2ypnQxawcビルドxakaルxasbルドvaetvaッ{dNode6vac0wad1ypmxawfビッグデータxakaッxaseッグデータvaetwad0xawaビxakaビxasaビvaesva&{dNode6vac0wad1yppxawa&xaka&xasa&vaetva頂{dNode6vac2vaき{dNode6vac0wad1ypqxawd頂きましxakaきxascきましvaetvaい{dNode6vac0wad1ypkxawg頂いちゃいましxakaいxasfいちゃいましvaetwad0xawa頂xaka頂xasa頂vaesva勉{dNode6vac2va運{dNode6vac0wad1ypsxawi勉強会運営座談会っxaka運xasf運営座談会っvaetva第{dNode6vac0wad2ypxdxawd勉強会第xaka第xasa第vaetwad<yprm~G]`blsQWbj{>xawc勉強会xaka勉xasc勉強会vaetva受{dNode6vac0wad1yprxawb受付xaka受xasb受付vaetva運{dNode6vac0wad1yptxawb運営xaka運xasb運営vaetva。{dNode6vac0wad<yptyGNOQU`cghjnpx@HMTXY`{~GJKQSYZ[\]_`bdgklmprsxyCFGLRTWYZ\]bdhjkpw{EJ>xawa。xaka。xasa。vaetvaく{dNode6vac0wad1ypvxawbくるxakaくxasbくるvaetvaち{dNode6vac0wad2ypvDxawcちょっxakaちxascちょっvaetva長{dNode6vac0wad1ypxxawe長期出張用xaka長xase長期出張用vaetvaい{dNode6vac5vaく{dNode6vac0wad1ypxxawdいくつかxakaくxascくつかvaetvaつ{dNode6vac0wad1yphxawcいつもxakaつxasbつもvaetvaる{dNode6vac0wad1yphxawbいるxakaるxasaるvaetvaま{dNode6vac0wad1ypfxawdいまさらxakaまxascまさらvaetvaろ{dNode6vac0wad1ypqxawdいろいろxakaろxascろいろvaetwad2ypPexawaいxakaいxasaいvaetva開{dNode6vac2va催{dNode6vac1va期{dNode6vac0wad1yp|xawd開催期間xaka期xasb期間vaetwad<ypyNOQU`cjnptwxHMT`kmyB>xawb開催xaka催xasa催vaetva発{dNode6vac2va中{dNode6vac0wad1yp}xawc開発中xaka中xasa中vaetva方{dNode6vac0wad1ypJxawe開発方法論xaka方xasc方法論vaetwad0xawb開発xaka発xasa発vaeswad0xawa開xaka開xasa開vaesvaナ{dNode6vac0wad2ypz@xawgナイトセミナーxakaナxasgナイトセミナーvaetva方{dNode6vac2va法{dNode6vac0wad6yp{ABtaRxawb方法xaka法xasa法vaetva教{dNode6vac0wad1yp]xawb方教xaka教xasa教vaetwad2yp|Dxawa方xaka方xasa方vaetva応{dNode6vac0wad1yp|xawb応募xaka応xasb応募vaetvaジ{dNode6vac2vaョ{dNode6vac0wad1ypFxawdジョインxakaョxascョインvaetvaャ{dNode6vac0wad1ypgxawhジャストシステムxakaャxasgャストシステムvaetwad0xawaジxakaジxasaジvaesva分{dNode6vac3va析{dNode6vac0wad1ypGxawh分析基盤構築入門xaka析xasg析基盤構築入門vaetva散{dNode6vac0wad2yp~Jxawb分散xaka散xasa散vaetva離{dNode6vac0wad1ypAxawb分離xaka離xasa離vaetwad0xawa分xaka分xasa分vaesva一{dNode6vac0wad1ypGxawb一部xaka一xasb一部vaetva執{dNode6vac0wad2ypGwxawb執筆xaka執xasb執筆vaetva品{dNode6vac0wad1ypLxawb品詞xaka品xasb品詞vaetva単{dNode6vac0wad1ypLxawb単語xaka単xasb単語vaetva抜{dNode6vac0wad1ypLxawb抜きxaka抜xasb抜きvaetva書{dNode6vac0wad1ypLxawb書いxaka書xasb書いvaetvae{dNode6vac5val{dNode6vac2vas{dNode6vac2vaj{dNode6vac0wad<ypLNOQU`cjnpxHMT`kyB>xawoelasticsearchjpxakajxasbjpvaetva勉{dNode6vac0wad2ypkyxaw Pelasticsearch勉強会xaka勉xasc勉強会vaetwad<yppLN^acdfux|}@Pa>xawmelasticsearchxakasxasfsearchvaetvao{dNode6vac0wad1yprxawielasticonxakaoxasbonvaetwad1yplxawgelasticxakalxasflasticvaetvaf{dNode6vac0wad1ypNxawcefkxakafxasbfkvaetvad{dNode6vac0wad1ypWxawgeditionxakadxasfditionvaetvas{dNode6vac0wad1yp_xawbesxakasxasasvaetvax{dNode6vac0wad4ypux|}xawhextendedxakaxxasgxtendedvaetwad0xawaexakaexasaevaesva物{dNode6vac0wad1ypMxawa物xaka物xasa物vaetva壊{dNode6vac0wad1ypMxawc壊れるxaka壊xasc壊れるvaetva年{dNode6vac0wad1ypMxawa年xaka年xasa年vaetva基{dNode6vac0wad1ypPxawb基本xaka基xasb基本vaetva技{dNode6vac0wad1ypPxawb技術xaka技xasb技術vaetva歴{dNode6vac0wad1ypVxawb歴史xaka歴xasb歴史vaetva,{dNode6vac0wad1yp[xawa,xaka,xasa,vaetvaw{dNode6vac2vae{dNode6vac0wad1yp[xawbwexakaexasaevaetvai{dNode6vac0wad1yp@xawiwikipediaxakaixashikipediavaetwad0xawawxakawxasawvaesvau{dNode6vac0wad1yp]xawiunpluggedxakauxasiunpluggedvaetvaネ{dNode6vac0wad1yp]xawfネットワークxakaネxasfネットワークvaetva大{dNode6vac2va阪{dNode6vac0wad1ypcxawb大阪xaka阪xasa阪vaetva量{dNode6vac0wad1ypgxawb大量xaka量xasa量vaetwad0xawa大xaka大xasa大vaesva京{dNode6vac0wad1ypcxawb京都xaka京xasb京都vaetva間{dNode6vac0wad1ypexawb間近xaka間xasb間近vaetva進{dNode6vac0wad1ypfxawb進化xaka進xasb進化vaetva形{dNode6vac0wad1ypgxawe形態素解析xaka形xase形態素解析vaetvaあ{dNode6vac5vaれ{dNode6vac0wad1ypgxawbあれxakaれxasaれvaetvaり{dNode6vac0wad1ypMxaweありましてxakaりxasdりましてvaetvaえ{dNode6vac0wad1ypUxawcあえずxakaえxasbえずvaetvaる{dNode6vac0wad2yp\[xawbあるxakaるxasaるvaetvaけ{dNode6vac0wad1yp`xawdあけましxakaけxascけましvaetwad0xawaあxakaあxasaあvaesvaこ{dNode6vac4vaれ{dNode6vac0wad1ypgxawbこれxakaれxasaれvaetvaと{dNode6vac0wad3yp[P[xawbことxakaとxasaとvaetvaの{dNode6vac0wad1ypbxawbこのxakaのxasaのvaetvaる{dNode6vac0wad1ypbxawbこるxakaるxasaるvaetwad0xawaこxakaこxasaこvaesva@{dNode6vac0wad5ypghQWbxawa@xaka@xasa@vaetva使{dNode6vac2vaっ{dNode6vac0wad2ypkmxawb使っxakaっxasaっvaetvaい{dNode6vac0wad1ypgxawb使いxakaいxasaいvaetwad0xawa使xaka使xasa使vaesva向{dNode6vac0wad1ypsxawb向けxaka向xasb向けvaetvaト{dNode6vac2vaニ{dNode6vac0wad1yptxawfトレーニングxakaニxascニングvaetvaシ{dNode6vac0wad1yp~xawfトレーシングxakaシxascシングvaetwad0xawcトレーxakaトxascトレーvaesvaダ{dNode6vac0wad1ypyxawkダイナミックスクリプトxakaダxaskダイナミックスクリプトvaetva　{dNode6vac0wad6ypzrxz|}xawa　xaka　xasa　vaetvaき{dNode6vac1vaま{dNode6vac0wad<yp{@NXZjoptCK^pw>xawcきましxakaまxasbましvaetwad1ypbxawaきxakaきxasaきvaetva簡{dNode6vac0wad1yp@xawb簡単xaka簡xasb簡単vaetva利{dNode6vac1va例{dNode6vac0wad1ypMxawc利用例xaka例xasa例vaetwad5ypGJYaXxawb利用xaka利xasb利用vaetvaバ{dNode6vac3vaー{dNode6vac0wad2ypKAxaweバージョンxakaーxasdージョンvaetvaッ{dNode6vac0wad1yp^xawfバックアップxakaッxaseックアップvaetvaグ{dNode6vac0wad2ypuKxawbバグxakaグxasaグvaetwad0xawaバxakaバxasaバvaesva番{dNode6vac0wad1ypKxawb番号xaka番xasb番号vaetvag{dNode6vac2vai{dNode6vac0wad1ypNxawegihyoxakaixasdihyovaetvao{dNode6vac0wad<ypoYnwzEIJMNOX_iqHNOR>xawegosenxakaoxasdosenvaetwad0xawagxakagxasagvaesva_{dNode6vac0wad5ypNsQTWxawa_xaka_xasa_vaetva収{dNode6vac0wad1ypPxawb収集xaka収xasb収集vaetva~{dNode6vac0wad1ypPxawa~xaka~xasa~vaetva可{dNode6vac2va視{dNode6vac1va編{dNode6vac0wad1ypPxawd可視化編xaka編xasa編vaetwad2ypXXxawc可視化xaka視xasb視化vaetva能{dNode6vac0wad1ypYxawb可能xaka能xasa能vaetwad0xawa可xaka可xasa可vaesva手{dNode6vac0wad2ypPexawb手伝xaka手xasb手伝vaetva転{dNode6vac0wad1ypUxawb転職xaka転xasb転職vaetva現{dNode6vac0wad1ypXxawe現状確認会xaka現xase現状確認会vaetva最{dNode6vac2va新{dNode6vac0wad1ypYxawb最新xaka新xasa新vaetva終{dNode6vac0wad1ypzxawc最終日xaka終xasb終日vaetwad0xawa最xaka最xasa最vaesva行{dNode6vac2vaっ{dNode6vac0wad5ypZQSjkxawb行っxakaっxasaっvaetvaき{dNode6vac0wad2ypNTxawd行きましxakaきxascきましvaetwad0xawa行xaka行xasa行vaesva外{dNode6vac1va部{dNode6vac0wad1ypoxawc外部化xaka部xasb部化vaetwad1yp[xawa外xaka外xasa外vaetva世{dNode6vac0wad6yp[rxz|}xawb世界xaka世xasb世界vaetva知{dNode6vac0wad1yp[xawb知るxaka知xasb知るvaetva届{dNode6vac0wad1yp\xawd届きましxaka届xasd届きましvaetva柔{dNode6vac0wad1yp]xawb柔軟xaka柔xasb柔軟vaetva集{dNode6vac0wad1yp]xawb集計xaka集xasb集計vaetvaa{dNode6vac5val{dNode6vac0wad1yp^xawgaliasesxakalxasfliasesvaetvan{dNode6vac2vas{dNode6vac0wad2ypaaxawhanalysisxakasxascsisvaetvaz{dNode6vac0wad4ypux|}xawganalyzexakazxasbzevaetwad0xaweanalyxakanxasdnalyvaesvap{dNode6vac0wad1ypPxawfapachexakapxasepachevaetvaw{dNode6vac0wad2ypQSxawiawssummitxakawxashwssummitvaetvau{dNode6vac2vag{dNode6vac0wad1ypixawdaugjxakagxasbgjvaetvat{dNode6vac0wad1yp}xaw YautoGeneratePhraseQueriesxakatxas WtoGeneratePhraseQueriesvaetwad0xawbauxakauxasauvaeswad0xawaaxakaaxasaavaesva画{dNode6vac0wad4yp^acLxawb画面xaka画xasb画面vaetva複{dNode6vac1va辞{dNode6vac0wad1yp@xawd複数辞書xaka辞xasb辞書vaetwad1yp_xawb複数xaka複xasb複数vaetva登{dNode6vac0wad2yp_Lxawb登録xaka登xasb登録vaetvaj{dNode6vac3vav{dNode6vac0wad1ypbxawijvmcasualxakavxashvmcasualvaetvab{dNode6vac0wad1ypjxawejbugjxakabxasdbugjvaetvaa{dNode6vac2vaw{dNode6vac0wad1ypmxawfjawsugxakawxasdwsugvaetvar{dNode6vac0wad1ypAxawcjarxakarxasarvaetwad0xawbjaxakaaxasaavaeswad0xawajxakajxasajvaesvar{dNode6vac2vae{dNode6vac0wad1ypcxawdrestxakaexascestvaetvai{dNode6vac2vaa{dNode6vac0wad2yp{Jxawfriakjpxakaaxasdakjpvaetvav{dNode6vac0wad1yp@xaweriverxakavxascvervaetwad0xawbrixakaixasaivaeswad0xawarxakarxasarvaesva概{dNode6vac0wad1ypdxawb概要xaka概xasb概要vaetva電{dNode6vac0wad1ypexawc電子版xaka電xasc電子版vaetva発{dNode6vac2va売{dNode6vac0wad2ypevxawb発売xaka売xasa売vaetva表{dNode6vac0wad1ypdxawb発表xaka表xasa表vaetwad0xawa発xaka発xasa発vaesvaご{dNode6vac0wad1ypgxaweございますxakaごxaseございますvaetva翻{dNode6vac0wad3ypiuvxawb翻訳xaka翻xasb翻訳vaetva奇{dNode6vac0wad1ypjxawb奇妙xaka奇xasb奇妙vaetva動{dNode6vac0wad1ypjxawb動作xaka動xasb動作vaetva元{dNode6vac0wad1yplxawa元xaka元xasa元vaetva時{dNode6vac2va系{dNode6vac0wad1yppxawc時系列xaka系xasb系列vaetva代{dNode6vac0wad1ypbxawd時代到来xaka代xasc代到来vaetwad0xawa時xaka時xasa時vaesva管{dNode6vac1va画{dNode6vac0wad1yptxawd管理画面xaka画xasb画面vaetwad2yppLxawb管理xaka管xasb管理vaetva＆{dNode6vac1va「{dNode6vac0wad1ypkxawb＆「xaka「xasa「vaetwad2ypsnxawa＆xaka＆xasa＆vaetva配{dNode6vac0wad1yptxawb配置xaka配xasb配置vaetva版{dNode6vac0wad1ypvxawa版xaka版xasa版vaetva公{dNode6vac0wad2ypx~xawb公開xaka公xasb公開vaetva主{dNode6vac0wad4yp~G`lxawb主催xaka主xasb主催vaetva疑{dNode6vac0wad1yp@xawc疑問点xaka疑xasc疑問点vaetvaX{dNode6vac0wad2ypEcxawfXperiaxakaXxasfXperiavaetvaZ{dNode6vac1vai{dNode6vac0wad3yp{|~xawfZipkinxakaixaseipkinvaetwad2ypEcxawaZxakaZxasaZvaetva故{dNode6vac0wad1ypExawb故障xaka故xasb故障vaetva『{dNode6vac0wad4ypHH]bxawa『xaka『xasa『vaetva』{dNode6vac0wad4ypHH]bxawa』xaka』xasa』vaetva刊{dNode6vac0wad1ypHxawd刊行記念xaka刊xasd刊行記念vaetvaY{dNode6vac0wad1ypIxawhYokozunaxakaYxashYokozunavaetva気{dNode6vac0wad3ypI\Hxawa気xaka気xasa気vaetva点{dNode6vac0wad2ypIHxawa点xaka点xasa点vaetva遊{dNode6vac0wad2ypNTxawb遊びxaka遊xasb遊びvaetvax{dNode6vac1vam{dNode6vac0wad1ypOxawcxmlxakamxasbmlvaetwad1yptxawaxxakaxxasaxvaetvaモ{dNode6vac3vaジ{dNode6vac0wad1ypTxaweモジュールxakaジxasdジュールvaetvaデ{dNode6vac2vaレ{dNode6vac0wad1ypexaweモデレータxakaレxascレータvaetvaリ{dNode6vac0wad1ypJxaweモデリングxakaリxascリングvaetwad0xawbモデxakaデxasaデvaesvaー{dNode6vac0wad1yp\xawhモーショノロジーxakaーxasgーショノロジーvaetwad0xawaモxakaモxasaモvaesva雑{dNode6vac0wad1ypUxawb雑感xaka雑xasb雑感vaetva＋{dNode6vac0wad4ypVee`xawa＋xaka＋xasa＋vaetva悩{dNode6vac0wad1ypVxawb悩みxaka悩xasb悩みvaetva事{dNode6vac0wad1ypVxawb事とxaka事xasb事とvaetva以{dNode6vac0wad1ypYxawb以上xaka以xasb以上vaetvaポ{dNode6vac2va回{dNode6vac0wad1ypZxawgポモドーロ回しxaka回xasb回しvaetvaテ{dNode6vac0wad1ypZxaw Qポモドーロテクニック入門読みましたxakaテxaslテクニック入門読みましたvaetwad0xaweポモドーロxakaポxaseポモドーロvaesva訳{dNode6vac0wad2yp[\xawb訳しxaka訳xasb訳しvaetva―{dNode6vac0wad2yp]bxawa―xaka―xasa―vaetva人{dNode6vac0wad1yp]xawb人気xaka人xasb人気vaetvaえ{dNode6vac0wad1yp]xawaえxakaえxasaえvaetva!{dNode6vac1va!{dNode6vac0wad1yp_xawb!!xaka!xasa!vaetwad1ypkxawa!xaka!xasa!vaetva＠{dNode6vac0wad1ypbxawa＠xaka＠xasa＠vaetva竹{dNode6vac0wad1ypbxawb竹橋xaka竹xasb竹橋vaetva先{dNode6vac0wad1ypbxawb先生xaka先xasb先生vaetva担{dNode6vac0wad1ypfxawb担当xaka担xasb担当vaetva勝{dNode6vac0wad1ypgxawb勝手xaka勝xasb勝手vaetva確{dNode6vac1va中{dNode6vac0wad1ypqxawc確認中xaka中xasa中vaetwad1ypgxawb確認xaka確xasb確認vaetva兼{dNode6vac0wad1ypgxawb兼ねxaka兼xasb兼ねvaetva活{dNode6vac0wad1ypmxawd活用事例xaka活xasd活用事例vaetva講{dNode6vac0wad1ypoxawb講演xaka講xasb講演vaetva聞{dNode6vac0wad1ypoxawb聞いxaka聞xasb聞いvaetva【{dNode6vac0wad4ypuKNOxawa【xaka【xasa【vaetva】{dNode6vac1va({dNode6vac0wad1ypuxawb】(xaka(xasa(vaetwad3ypKNOxawa】xaka】xasa】vaetva輪{dNode6vac0wad1ypvxawe輪読会始めxaka輪xase輪読会始めvaetvaソ{dNode6vac1vaコ{dNode6vac0wad3ypyYhxawlソースコードリーディングxakaコxasiコードリーディングvaetwad1ypQxawcソースxakaソxascソースvaetva２{dNode6vac0wad2yp{Bxawa２xaka２xasa２vaetva残{dNode6vac2vaり{dNode6vac0wad1yp{xawb残りxakaりxasaりvaetvaタ{dNode6vac0wad1ypxawd残タスクxakaタxascタスクvaetwad0xawa残xaka残xasa残vaesva周{dNode6vac0wad2yp|xawb周りxaka周xasb周りvaetva値{dNode6vac0wad1yp}xawa値xaka値xasa値vaetva壁{dNode6vac0wad1yp@xawa壁xaka壁xasa壁vaetva差{dNode6vac0wad1ypAxawa差xaka差xasa差vaetva替{dNode6vac0wad1ypAxawb替えxaka替xasb替えvaetva失{dNode6vac0wad2ypAMxawb失敗xaka失xasb失敗vaetva貢{dNode6vac0wad1ypBxawb貢献xaka貢xasb貢献vaetva秘{dNode6vac0wad1ypFxawb秘密xaka秘xasb秘密vaetva＃{dNode6vac0wad1ypGxawa＃xaka＃xasa＃vaetva～{dNode6vac0wad1ypIxawa～xaka～xasa～vaetva問{dNode6vac1va点{dNode6vac0wad1ypXxawd問題点編xaka点xasb点編vaetwad1ypMxawb問題xaka問xasb問題vaetva重{dNode6vac0wad2ypNOxawb重要xaka重xasb重要vaetva次{dNode6vac0wad1ypOxawb次期xaka次xasb次期vaetva久{dNode6vac0wad1ypPxawb久々xaka久xasb久々vaetva渋{dNode6vac0wad1ypQxawb渋谷xaka渋xasb渋谷vaetva小{dNode6vac0wad1ypRxawb小さxaka小xasb小さvaetva箱{dNode6vac0wad1ypRxawa箱xaka箱xasa箱vaetva脱{dNode6vac0wad1ypRxawb脱出xaka脱xasb脱出vaetva親{dNode6vac0wad1ypVxawb親子xaka親xasb親子vaetva楽{dNode6vac0wad1ypVxawd楽しめるxaka楽xasd楽しめるvaetva絵{dNode6vac0wad1ypVxawb絵本xaka絵xasb絵本vaetva英{dNode6vac2va語{dNode6vac0wad1ypVxawb英語xaka語xasa語vaetva単{dNode6vac0wad1ypMxawc英単語xaka単xasb単語vaetwad0xawa英xaka英xasa英vaesva本{dNode6vac0wad3ypVggxawa本xaka本xasa本vaetvaミ{dNode6vac0wad1yp^xawfミニセミナーxakaミxasfミニセミナーvaetva会{dNode6vac0wad1yp`xawb会社xaka会xasb会社vaetva東{dNode6vac0wad1ypbxawb東京xaka東xasb東京vaetva７{dNode6vac0wad1ypdxawb７回xaka７xasb７回vaetva備{dNode6vac0wad6ypfs~BCGxawc備忘録xaka備xasc備忘録vaetva５{dNode6vac0wad1ypfxawa５xaka５xasa５vaetva他{dNode6vac0wad1ypfxawb他くxaka他xasb他くvaetvaど{dNode6vac0wad1ypgxawbどんxakaどxasbどんvaetva速{dNode6vac2va読{dNode6vac0wad1ypgxawb速読xaka読xasa読vaetva報{dNode6vac0wad2ypyIxawb速報xaka報xasa報vaetwad0xawa速xaka速xasa速vaesva文{dNode6vac0wad1ypqxawb文章xaka文xasb文章vaetva抽{dNode6vac0wad1ypqxawb抽出xaka抽xasb抽出vaetva４{dNode6vac0wad1ypsxawa４xaka４xasa４vaetva系{dNode6vac0wad1yptxawa系xaka系xasa系vaetva３{dNode6vac0wad1yp~xawa３xaka３xasa３vaetva込{dNode6vac0wad1yp@xawb込みxaka込xasb込みvaetva教{dNode6vac0wad1ypDxawa教xaka教xasa教vaetva・{dNode6vac0wad2ypJJxawa・xaka・xasa・vaetva座{dNode6vac0wad1ypJxawc座談会xaka座xasc座談会vaetva修{dNode6vac0wad1ypKxawb修正xaka修xasb修正vaetvan{dNode6vac0wad1ypMxawenaistxakanxasenaistvaet>wad0xaw`xak`xas`vaesvgisArraysvgsummary3xdtypeeRadixvdnode{dNode6vac<va0{dNode6vac:va0{dNode6vac3vaく{dNode6vac0wad1ypsxawe00くらいxakaくxascくらいvaetva現{dNode6vac0wad1yp[xawd00現在xaka現xasb現在vaetva時{dNode6vac0wad1yp\xawd00時点xaka時xasb時点vaetwad4ypp\\xawb00xaka0xasa0vaetva1{dNode6vac0wad2yp\]xawb01xaka1xasa1vaetva2{dNode6vac0wad2ypgxawb02xaka2xasa2vaetva3{dNode6vac0wad4ypfO~~xawb03xaka3xasa3vaetva4{dNode6vac0wad3yp~[\xawb04xaka4xasa4vaetva5{dNode6vac0wad3yp}}vxawb05xaka5xasa5vaetva6{dNode6vac0wad2yps}xawb06xaka6xasa6vaetva8{dNode6vac0wad2ypTIxawb08xaka8xasa8vaetva9{dNode6vac0wad1ypfxawb09xaka9xasa9vaetva対{dNode6vac0wad1ypHxawb0対xaka対xasa対vaetwad<ypSSEJKVVWWXXXXYYYZZZZ\\]^^__beeeeiqs~~BCCIKLSSss{YY\nnnnuuwwDEIJMMNNOnN>xawa0xaka0xasa0vaetva1{dNode6vac<va0{dNode6vac3va0{dNode6vac0wad:ypwxGHIOP}~xawd100本xaka0xasb0本vaetva月{dNode6vac2vaく{dNode6vac0wad1ypkxawe10月くらxakaくxasbくらvaetva末{dNode6vac0wad1ypKxawd10月末xaka末xasa末vaetwad0xawc10月xaka月xasa月vaesva回{dNode6vac0wad1yp`xawc10回xaka回xasa回vaetwad<ypspWZabimoqzEILh>xawb10xaka0xasa0vaetva1{dNode6vac1va回{dNode6vac0wad1ypGxawc11回xaka回xasa回vaetwad2yps[xawb11xaka1xasa1vaetva2{dNode6vac2va月{dNode6vac0wad1ypbxawc12月xaka月xasa月vaetva回{dNode6vac0wad1yp~xawc12回xaka回xasa回vaetwad6ypT_~@vhxawb12xaka2xasa2vaetva4{dNode6vac3va0{dNode6vac0wad1ypyxawj140人くらいくらいxaka0xash0人くらいくらいvaetva8{dNode6vac0wad1yppxawf148121xaka8xasd8121vaetva回{dNode6vac0wad1ypQxawc14回xaka回xasa回vaetwad1yptxawb14xaka4xasa4vaetva5{dNode6vac2va日{dNode6vac0wad1ypSxawd15日目xaka日xasb日目vaetva号{dNode6vac0wad1ypxxawc15号xaka号xasa号vaetwad1yp_xawb15xaka5xasa5vaetva6{dNode6vac0wad4ypWlb\xawb16xaka6xasa6vaetva7{dNode6vac1va日{dNode6vac0wad1yp`xawc17日xaka日xasa日vaetwad3yp\~@xawb17xaka7xasa7vaetva8{dNode6vac1va日{dNode6vac0wad1ypmxawd18日目xaka日xasb日目vaetwad3ypef]xawb18xaka8xasa8vaetva9{dNode6vac0wad3ypp\]xawb19xaka9xasa9vaetva年{dNode6vac0wad2ypdBxawb1年xaka年xasa年vaetva日{dNode6vac1va目{dNode6vac0wad6ypnowEKrxawc1日目xaka目xasa目vaetwad1yp[xawb1日xaka日xasa日vaetva回{dNode6vac1va目{dNode6vac0wad1yptxawc1回目xaka目xasa目vaetwad3yptBExawb1回xaka回xasa回vaetva度{dNode6vac0wad1ypxxawb1度xaka度xasa度vaetva章{dNode6vac0wad1ypxawb1章xaka章xasa章vaetva弾{dNode6vac0wad1ypBxawb1弾xaka弾xasa弾vaetva対{dNode6vac0wad1ypoxawb1対xaka対xasa対vaetva週{dNode6vac0wad1ypNxawc1週間xaka週xasb週間vaet>wad<ypXEH]cdeopwEJJVX\^^_aaabbbeeimooqssvvvyzz~~BBCCCCEEEIIKKLLLRRRRSSSoOefEccnoHHHNN>xawa1xaka1xasa1vaetva2{dNode6vac<va0{dNode6vac3va1{dNode6vac:va0{dNode6vac0wad1yphxawd2010xaka0xasa0vaetva1{dNode6vac0wad2yppwxawd2011xaka1xasa1vaetva2{dNode6vac1va年{dNode6vac0wad1yprxawe2012年xaka年xasa年vaetwad6ypipCL\]xawd2012xaka2xasa2vaetva3{dNode6vac1va年{dNode6vac0wad1yp|xawe2013年xaka年xasa年vaetwad8ypzQS[\defxawd2013xaka3xasa3vaetva4{dNode6vac1va年{dNode6vac0wad2ypRNxawe2014年xaka年xasa年vaetwad1yp}xawd2014xaka4xasa4vaetva5{dNode6vac1va年{dNode6vac0wad1ypIxawe2015年xaka年xasa年vaetwad1ypSxawd2015xaka5xasa5vaetva6{dNode6vac1va年{dNode6vac0wad1ypCxawe2016年xaka年xasa年vaetwad1ypJxawd2016xaka6xasa6vaetva7{dNode6vac1va年{dNode6vac0wad1ypuxawe2017年xaka年xasa年vaetwad2ypDExawd2017xaka7xasa7vaetva8{dNode6vac1va年{dNode6vac0wad2yphDxawe2018年xaka年xasa年vaetwad2ypvwxawd2018xaka8xasa8vaetva9{dNode6vac1va年{dNode6vac0wad2ypl\xawe2019年xaka年xasa年vaetwad3ypnopxawd2019xaka9xasa9vaetwad1yp_xawc201xaka1xasa1vaetva2{dNode6vac4va0{dNode6vac1va年{dNode6vac0wad3ypZP\xawe2020年xaka年xasa年vaetwad6ypffmnsJxawd2020xaka0xasa0vaetva1{dNode6vac1va年{dNode6vac0wad2yp^[xawe2021年xaka年xasa年vaetwad1yp]xawd2021xaka1xasa1vaetva2{dNode6vac0wad2ypRPxawd2022xaka2xasa2vaetva3{dNode6vac0wad1ypSxawd2023xaka3xasa3vaetwad0xawc202xaka2xasa2vaesva日{dNode6vac0wad1ypixawd20日目xaka日xasb日目vaetwad2ypv]xawb20xaka0xasa0vaetva1{dNode6vac0wad1yppxawb21xaka1xasa1vaetva2{dNode6vac0wad1yp\xawb22xaka2xasa2vaetva3{dNode6vac1va6{dNode6vac0wad1yp\xawe23608xaka6xasc608vaetwad1ypqxawb23xaka3xasa3vaetva4{dNode6vac1va日{dNode6vac0wad1ypDxawd24日目xaka日xasb日目vaetwad1yp\xawb24xaka4xasa4vaetva5{dNode6vac1va日{dNode6vac0wad2ypv}xawd25日目xaka日xasb日目vaetwad3yppz[xawb25xaka5xasa5vaetva6{dNode6vac0wad3ypt^\xawb26xaka6xasa6vaetva7{dNode6vac0wad2ypmsxawb27xaka7xasa7vaetva8{dNode6vac0wad2ypWZxawb28xaka8xasa8vaetva9{dNode6vac0wad1ypaxawb29xaka9xasa9vaetva回{dNode6vac1va目{dNode6vac0wad5ypS]yYCxawc2回目xaka目xasa目vaetwad1ypAxawb2回xaka回xasa回vaetva月{dNode6vac0wad4ypXK\Jxawb2月xaka月xasa月vaetva号{dNode6vac0wad1ypnxawb2号xaka号xasa号vaetva種{dNode6vac0wad1yp@xawc2種類xaka種xasb種類vaetva章{dNode6vac0wad3ypGHIxawb2章xaka章xasa章vaetva年{dNode6vac0wad1ypOxawb2年xaka年xasa年vaetva弾{dNode6vac0wad1ypcxawb2弾xaka弾xasa弾vaetvan{dNode6vac0wad3ypWvvxawc2ndxakanxasbndvaetva日{dNode6vac2va間{dNode6vac1va開{dNode6vac0wad1ypLxawe2日間開催xaka開xasb開催vaetwad1yp|xawc2日間xaka間xasa間vaetva目{dNode6vac0wad1yp|xawc2日目xaka目xasa目vaetwad0xawb2日xaka日xasa日vaesva週{dNode6vac0wad1ypjxawb2週xaka週xasa週vaetvaつ{dNode6vac0wad1ypPxawb2つxakaつxasaつvaet>wad<ypYE]cdeftJJJJJJVWXXYYYYZZ\\\]^^_aeemvEIS{DJEMNO]cn>xawa2xaka2xasa2vaetva3{dNode6vac7va0{dNode6vac1va0{dNode6vac0wad1ypJxawc300xaka0xasa0vaetwad3ypp]]xawb30xaka0xasa0vaetva2{dNode6vac0wad1ypzxawb32xaka2xasa2vaetva章{dNode6vac0wad5ypxYYY[xawb3章xaka章xasa章vaetva番{dNode6vac0wad2ypLMxawc3番煎xaka番xasb番煎vaetvaつ{dNode6vac0wad1yplxawb3つxakaつxasaつvaetva日{dNode6vac0wad1yptxawc3日間xaka日xasb日間vaetva年{dNode6vac1va越{dNode6vac0wad1ypnxawc3年越xaka越xasa越vaetwad2ypw}xawb3年xaka年xasa年vaetwad<yp]cdefqtvyyzzz~~EIRR{MOYY[\\wAAHIJyII>xawa3xaka3xasa3vaetva4{dNode6vac7va7{dNode6vac0wad1ypXxawc477xaka7xasb77vaetva8{dNode6vac0wad1ypKxawd4897xaka8xasc897vaetva9{dNode6vac1va階{dNode6vac0wad1yp\xawc49階xaka階xasa階vaetwad1yp\xawb49xaka9xasa9vaetva日{dNode6vac0wad1ypnxawc4日目xaka日xasb日目vaetva章{dNode6vac0wad<ypww|ABFNQSUUI>xawb4章xaka章xasa章vaetva月{dNode6vac2va1{dNode6vac0wad1yptxawe4月13日xaka1xasc13日vaetva4{dNode6vac0wad1ypwxawd4月4日xaka4xasb4日vaetwad0xawb4月xaka月xasa月vaesvax{dNode6vac0wad1ypwxawb4xxakaxxasaxvaetwad<yp]cdefnxYYaabbfiimmmoooqquuvvvyzzEEGIIKLLooKKOYY[\nnuuwLLLLLL_y>xawa4xaka4xasa4vaetva5{dNode6vac5va5{dNode6vac0wad1yp\xawc55Xxaka5xasb5Xvaetva章{dNode6vac0wad7yp|ABFNQSxawb5章xaka章xasa章vaetva年{dNode6vac0wad2ypgmxawb5年xaka年xasa年vaetva日{dNode6vac0wad1yp`xawb5日xaka日xasa日vaetva回{dNode6vac0wad1ypJxawb5回xaka回xasa回vaetwad<ypJ]efmJK\^hmoqBCCIALL>xawa5xaka5xasa5vaetva6{dNode6vac3va月{dNode6vac2va1{dNode6vac0wad1yp`xawe6月14日xaka1xasc14日vaetva7{dNode6vac0wad1yp}xawd6月7日xaka7xasb7日vaetwad0xawb6月xaka月xasa月vaesva章{dNode6vac0wad6yp|ABFNQxawb6章xaka章xasa章vaetva回{dNode6vac0wad3yph{{xawb6回xaka回xasa回vaetwad<ypabiiEooAHIJ>xawa6xaka6xasa6vaetva7{dNode6vac7va0{dNode6vac0wad1yp~xawc70人xaka0xasb0人vaetva9{dNode6vac0wad1ypXxawb79xaka9xasa9vaetva時{dNode6vac0wad1ypJxawc7時点xaka時xasb時点vaetva章{dNode6vac0wad1ypNxawb7章xaka章xasa章vaetva月{dNode6vac0wad1ypaxawb7月xaka月xasa月vaetva回{dNode6vac0wad2ypGhxawb7回xaka回xasa回vaetvaつ{dNode6vac0wad2yp}}xawb7つxakaつxasaつvaetwad<ypWmEEqzJaabbwEM>xawa7xaka7xasa7vaetva8{dNode6vac2va4{dNode6vac0wad1ypSxawb84xaka4xasa4vaetva章{dNode6vac0wad5yp|ABFNxawb8章xaka章xasa章vaetwad8ypm^yzssxawa8xaka8xasa8vaetva9{dNode6vac6va0{dNode6vac1va人{dNode6vac0wad1ypGxawf90人くらいxaka人xasd人くらいvaetwad2ypssxawb90xaka0xasa0vaetva2{dNode6vac0wad1ypSxawb92xaka2xasa2vaetva5{dNode6vac0wad1yp\xawe9500Gxaka5xasd500Gvaetva日{dNode6vac0wad1ypPxawc9日目xaka日xasb日目vaetva流{dNode6vac0wad1yp|xawb9流xaka流xasa流vaetva月{dNode6vac0wad1ypNxawd9月9日xaka月xasc月9日vaetwad4yp\iovxawa9xaka9xasa9vaetva日{dNode6vac7va常{dNode6vac1va的{dNode6vac0wad1ypQxawc日常的xaka的xasa的vaetwad1ypQxawb日常xaka常xasa常vaetva本{dNode6vac1va語{dNode6vac3va用{dNode6vac0wad2ypQRxawd日本語用xaka用xasa用vaetva対{dNode6vac0wad1ypaxawe日本語対応xaka対xasb対応vaetva形{dNode6vac1va析{dNode6vac1va器{dNode6vac0wad1ypZxawi日本語形態素解析器xaka器xasa器vaetwad1ypJxawh日本語形態素解析xaka析xasa析vaetwad1ypZxawg日本語形態素解xaka形xasd形態素解vaetwad7ypP@MRppAxawc日本語xaka語xasa語vaetwad1ypkxawb日本xaka本xasa本vaetva目{dNode6vac0wad1ypnxawb日目xaka目xasa目vaetva時{dNode6vac0wad3ypp\]xawb日時xaka時xasa時vaetva経{dNode6vac0wad1ypyxawb日経xaka経xasa経vaetvaま{dNode6vac0wad1ypixawc日までxakaまxasbまでvaetva々{dNode6vac0wad1yp}xawb日々xaka々xasa々vaetwad1ypvxawa日xaka日xasa日vaetvaで{dNode6vac6vaす{dNode6vac1vaし{dNode6vac0wad1ypwxawdですしねxakaしxasbしねvaetwad<ypPX|ABFNQQSU]acdpt}DQTXYCGR[bdnU\uB>xawbですxakaすxasaすvaetvaき{dNode6vac2vaま{dNode6vac0wad1yp\xawdできますxakaまxasbますvaetvaる{dNode6vac0wad2ypq}xawcできるxakaるxasaるvaetwad5ypddyEOxawbできxakaきxasaきvaetvaい{dNode6vac3vaつ{dNode6vac0wad2yppKxawcでいつxakaつxasaつvaetvaく{dNode6vac0wad1ypKxaweでいくつかxakaくxascくつかvaetvaま{dNode6vac0wad1ypFxaweでいませんxakaまxascませんvaetwad3ypK[~xawbでいxakaいxasaいvaetvaる{dNode6vac0wad2ypYlxawbでるxakaるxasaるvaetvaみ{dNode6vac0wad2ypZ^xawbでみxakaみxasaみvaetvaち{dNode6vac0wad1yptxawdでちょっxakaちxascちょっvaetwad<ypQRRRSSTTTUUVWWXZ[[\]]]]^___PRSTUVVVWWWXXYYYZ[\]]^__`acddefffghmmmnnooopqqqqrtuuuuvvvwwwxxxyzzz|}~~@ABFGGGHIJKLMNOQSSTUUWY[[[^__``aabijjjllllmmmmmnoppqqrrrsvxzzz{{|||}}}}~~~~@AAABBFGHKLMPPPQSTTTY]_cchpprttwwww{{{|}}}@ABCDDDFFGJJJKNPPQQQRUUUVVVVWXYZ[[\\\]]]^_`abbbcddeffgggijjjkkmmnppqqrruuuvwwxxxyzz{{{|||}}~~~@ABBCDEFFGHIJKLLLLMMOQRSTUUUVVVWWWXYZ[\\]^_```abbceffghhiikkklmmnooopqqqrrsttuuvxxxxxxyzz{{{||}}~~~@ABCEEEFHIIKKKLMPQRRRSTTUVVVWWWXXXYYYZ[[\^^^_```aabbcccddeeffggghiiiijjlllmnooppqrsstuuuvvwxxxxyz{{{{{||}~~~ABBCDEFFFGGIJKKMOPPQRSSSS>xawaでxakaでxasaでvaetvaよ{dNode6vac4vaく{dNode6vac1vaわ{dNode6vac0wad1ypZxaweよくわかるxakaわxascわかるvaetwad5ypQMMVhxawbよくxakaくxasaくvaetvaう{dNode6vac2vaか{dNode6vac1vaっ{dNode6vac0wad1ypXxawdようかっxakaっxasaっvaetwad3yp`DExawcようかxakaかxasaかvaetvaや{dNode6vac0wad3yporxawdようやくxakaやxasbやくvaetwad<ypWVV\oTaoBw\cgg{LTn~P\_adv}SS>xawbようxakaうxasaうvaetvaか{dNode6vac0wad1ypuxawcよかっxakaかxasbかっvaetvaり{dNode6vac0wad7ypfmEJcnxawbよりxakaりxasaりvaetwad2ypd@xawaよxakaよxasaよvaetva、{dNode6vac0wad<ypQQQSSTUVWXXXYYZ[[\]_PQQRSVWWXY[[\\]_bccddffgiijklmnnopqqrrrtuvvvxyyyyz|}~@@ABCDEEFGHIJJKLLMNPQSTUUVWWXZ[\^___`aabbggggiiijjjkkllmmmnnnoooprrssttuvwwxyz{||}}~@@AAABBDEEFGGGHHHHJJKLLMMMNNOOPPQQTTTUUVWX\^_``abcdfffgghijjkklmnnopqrrrttuuuuuvwxxz{{|}~AAAABDDEFGGHHILLMMNPPQTTUUUVVWXXYZZ[[\\]__``bbbcddeegghiijjkllmmmnnnppqrrsstuvwwwxxyyz{{||}}~~@AABCDEEFFHIIJJKLMMNNOOPPQQRSTUUUVWWWXXXYYZ[[[[\\\^^^_`aabcddefgghhhikllmmmnnooppqrrrsssstttuvwxxxyyyz{{||}~@@@AABCCCDDEFGGHHHIJJJKKKLLMMNNOPPQRRSSSTTTTVVWXXYYYZZ[\^``aabcdeefffghiijjllooqqqrssuuuvvwwwwxyyz{{{|}~~~@@AABBBBCCDEEFGGGIKMMMOQSS>xawa、xaka、xasa、vaetva形{dNode6vac2va態{dNode6vac1va解{dNode6vac1va器{dNode6vac0wad2yp@gxawf形態素解析器xaka器xasa器vaetwad3ypQwgxawe形態素解析xaka解xasb解析vaetwad1ypNxawc形態素xaka態xasb態素vaetvaに{dNode6vac0wad1ypxxawb形にxakaにxasaにvaetwad1yp^xawa形xaka形xasa形vaetvaし{dNode6vac7vaま{dNode6vac5vaし{dNode6vac1vaょ{dNode6vac0wad1yp~xaweしましょうxakaょxasbょうvaetwad<ypZkmAfs~CowENcnoHHM>xawcしましxakaしxasaしvaetvaい{dNode6vac1vaま{dNode6vac2vaし{dNode6vac0wad<ypP]lq{|T\^vElPRB>xaweしまいましxakaしxasaしvaetvaす{dNode6vac0wad1yp@xaweしまいますxakaすxasaすvaetwad1yp{xawdしまいまxakaまxasaまvaetwad2ypLExawcしまいxakaいxasaいvaetvaっ{dNode6vac0wad5yp\S_Prxawcしまっxakaっxasaっvaetvaす{dNode6vac0wad1ypbxawcしますxakaすxasaすvaetvaう{dNode6vac0wad2ypGMxawcしまうxakaうxasaうvaetwad1ypYxawbしまxakaまxasaまvaetvaて{dNode6vac0wad;yp]zby@`dxARmxawbしてxakaてxasaてvaetvaゃ{dNode6vac2vaり{dNode6vac0wad1ypmxawdしゃべりxakaりxasaりvaetvaっ{dNode6vac0wad1yptxawdしゃべっxakaっxasaっvaetwad0xawcしゃべxakaゃxasbゃべvaesvaい{dNode6vac0wad2ypfPxawbしいxakaいxasaいvaetvaか{dNode6vac0wad3yp|EXxawcしかもxakaかxasbかもvaetvaつ{dNode6vac0wad1ypPxawdしつけしxakaつxascつけしvaetvaち{dNode6vac0wad1yp_xawfしちゃいましxakaちxaseちゃいましvaetwad<ypQTTWWXXYYZ]_QSVVVZZ[^___``bjloppttxyy}CCEJLPPW^^__`gijjklmnpsttxz{|~BGHHNNOOQTUUVWXYZ[\]^_``abcdeefghhijjkkkllmnnopqsuvxxyzz{{|~AABCEEFGHHIIKLLMMPRTUUVWXX`beffklmpruwyyzzz{|}~@AABEFGHHJJMVVX]^_`bbcdjjkklmnpppqqqstxy{}@ABCDGHJLMNOQQSTTVWWWXZZ\^^bdeefhhlmopruww{}BCCDDEFFJJKOOPQQR>xawaしxakaしxasaしvaetvaた{dNode6vac<vaく{dNode6vac0wad7ypQL[BDezxawbたくxakaくxasaくvaetvaめ{dNode6vac0wad:ypQRvyr]TUZSxawbためxakaめxasaめvaetvaだ{dNode6vac0wad4yp\LGMxawbただxakaだxasaだvaetvaん{dNode6vac0wad5ypmij]txawbたんxakaんxasaんvaetvaり{dNode6vac2vaし{dNode6vac1vaま{dNode6vac0wad1ypTxaweたりしますxakaまxasbますvaetwad2ypyUxawcたりしxakaしxasaしvaetvaす{dNode6vac0wad1ypCxawcたりすxakaすxasaすvaetwad8yppy|kk|pQxawbたりxakaりxasaりvaetvaい{dNode6vac2vaし{dNode6vac0wad1yp_xawcたいしxakaしxasaしvaetvaん{dNode6vac0wad1ypVxawcたいんxakaんxasaんvaetwad<yp@Mjr@UddCFGklK^dqC>xawbたいxakaいxasaいvaetvaら{dNode6vac4vaか{dNode6vac0wad1yplxawdたらかしxakaかxasbかしvaetvaー{dNode6vac0wad1yprxawcたらーxakaーxasaーvaetvaし{dNode6vac2vaい{dNode6vac0wad1ypZxawdたらしいxakaいxasaいvaetvaく{dNode6vac0wad1yp@xawdたらしくxakaくxasaくvaetwad0xawcたらしxakaしxasaしvaesvaま{dNode6vac0wad1yp}xawdたらまたxakaまxasbまたvaetwad7ypHEIahPdxawbたらxakaらxasaらvaetvaる{dNode6vac0wad1ypSxawbたるxakaるxasaるvaetvaぶ{dNode6vac0wad3ypUhmxawcたぶんxakaぶxasbぶんvaetvaび{dNode6vac0wad1ypjxawbたびxakaびxasaびvaetvaち{dNode6vac2vaま{dNode6vac0wad1ypBxawdたちましxakaまxasbましvaetvaよ{dNode6vac0wad1ypaxaweたちよりひxakaよxascよりひvaetwad2ypqWxawbたちxakaちxasaちvaetvaか{dNode6vac0wad2ypM~xawbたかxakaかxasaかvaetvaま{dNode6vac2vaに{dNode6vac0wad1ypAxawcたまにxakaにxasaにvaetvaた{dNode6vac0wad2ypkHxawdたまたまxakaたxasbたまvaetwad0xawbたまxakaまxasaまvaesvaみ{dNode6vac0wad1ypFxawbたみxakaみxasaみvaetvaけ{dNode6vac0wad1ypbxawcたけどxakaけxasbけどvaetvaね{dNode6vac0wad1ypvxawbたねxakaねxasaねvaet>wad<ypTTUUUUWWWXZZ[\]]]^_PQRRSTUUVVVWWXZZ[[]___``abffghikkkklllmmooppppqstuvwxxxyzz{|}}ABCDDFHHIIJKLLNOPQSTUVVVWWXXYYZ[[\\_`aabbbghhikklllmnopqqrrttuuwwxyz{{ABBCCEEFGIIKLLNNNOOOPPQRRTUUUVWXYZZ[\]^_```abcdefghhhijjjklmnnnopppqssuvxxxyzz{{{{||~~@BCCDDEEFGHHHIJKLLMMMPPRSSSTTTUUUVVWWX[[\\\]_```bbeeeffijjkkmnoprrrrssttvvwwxxyyzzzz{{||}~~@ABBEFFGGHHJJJKKLMMNNOOPQQRSSSUUUVVWXYZ[]]]``bbbcccdegghhhiijjkkllmnnnoppqqrstuuwxxyzz~~@@@@ABBCDEFGHHJJKLLLMMNNNPQQRRSSSSTTTUUVVVWWWYZZ[[\^^__aabbcdeffggghhiijjkkkmnoopqrrsstttuuvwwwwxxxxy{{||}}@@BBCCDDEEFFHHHIJJKKKMNORRSS>xawaたxakaたxasaたvaetvaな{dNode6vac<vaる{dNode6vac0wad;ypQZ]{n@IKKl@xawbなるxakaるxasaるvaetvaど{dNode6vac0wad<ypVVRpisxQxakx{>xawbなどxakaどxasaどvaetvaん{dNode6vac2vaか{dNode6vac0wad5yprIMDaxawcなんかxakaかxasaかvaetvaち{dNode6vac0wad1ypBxawfなんちゃってxakaちxasdちゃってvaetwad8yp^YvS[dF{xawbなんxakaんxasaんvaetvaく{dNode6vac0wad;yp_dglUX[F_tQxawbなくxakaくxasaくvaetvaつ{dNode6vac0wad1ypTxawdなつくりxakaつxascつくりvaetvaっ{dNode6vac2vaて{dNode6vac0wad1ypixawcなってxakaてxasaてvaetvaち{dNode6vac0wad1ypkxawgなっちゃいましxakaちxaseちゃいましvaetwad<ypT]dqr{W\bglnrLP|STZ[[vDDILNOX_lt~@BDHKQB>xawbなっxakaっxasaっvaetvaも{dNode6vac1vaか{dNode6vac0wad3ypU_Uxawdなものかxakaかxasaかvaetwad3yp@@dxawcなものxakaもxasbものvaetvaぁ{dNode6vac0wad;ypbOCHMRkW]jSxawbなぁxakaぁxasaぁvaetvaさ{dNode6vac2vaん{dNode6vac0wad3ypc^ixawcなさんxakaんxasaんvaetvaい{dNode6vac0wad1ypHxawcなさいxakaいxasaいvaetwad1ypuxawbなさxakaさxasaさvaetvaい{dNode6vac4vaか{dNode6vac0wad2ypMWxawcないかxakaかxasaかvaetvaら{dNode6vac0wad1ypbxaweないらしいxakaらxascらしいvaetvaん{dNode6vac0wad1ypExawcないんxakaんxasaんvaetvaけ{dNode6vac0wad1ypexawdないけどxakaけxasbけどvaetwad<ypdhrt~Gb|@hAJ`bkEIR[[\_hhrvv{@STXY_bjrz~~>xawbないxakaいxasaいvaetvaか{dNode6vac1vaっ{dNode6vac0wad9ypfmIxJt}bTxawcなかっxakaっxasaっvaetwad4ypvv~~xawbなかxakaかxasaかvaetvaり{dNode6vac2vaま{dNode6vac2vaす{dNode6vac0wad<ypmnovwyDEJKSVWXYZ[\]^_abdeiklmoqsuvyz~BCEILc>xawdなりますxakaすxasaすvaetvaし{dNode6vac0wad7ypyTDLquExawdなりましxakaしxasaしvaetwad0xawcなりまxakaまxasaまvaesvaつ{dNode6vac0wad1ypDxawdなりつつxakaつxasbつつvaetwad4ypkBjpxawbなりxakaりxasaりvaetvaみ{dNode6vac0wad2ypGlxawbなみxakaみxasaみvaetvaお{dNode6vac0wad1ypJxawbなおxakaおxasaおvaetvaと{dNode6vac0wad6ypT\j]Caxawbなとxakaとxasaとvaetvaー{dNode6vac0wad1ypsxawbなーxakaーxasaーvaetvaけ{dNode6vac0wad1ypvxawbなけxakaけxasaけvaetva量{dNode6vac0wad1ypGxawbな量xaka量xasa量vaetvaが{dNode6vac0wad5ypIh|t|xawbながxakaがxasaがvaetvaげ{dNode6vac0wad1yp}xawcなげるxakaげxasbげるvaetvaの{dNode6vac0wad3yp\ysxawbなのxakaのxasaのvaetvaれ{dNode6vac1vaる{dNode6vac0wad1yphxawcなれるxakaるxasaるvaetwad1yprxawbなれxakaれxasaれvaetvaら{dNode6vac0wad1ypExawbならxakaらxasaらvaetvaし{dNode6vac0wad1ypdxawbなしxakaしxasaしvaet>wad<ypR^^QVZ[``bggiiv|~~~ABFNQSTTUUXY[_brs|}CLMRV[h@AJ[[\]^_accdggmnotwyzDHILMMNTZ]`fhjkkkmy{DIZZ^befgklrvwCGN>xawaなxakaなxasaなvaetvaこ{dNode6vac9vaと{dNode6vac0wad<ypQQ[\hnqtz_gopw@BEMTtDUUUXZgjmnrtu{DGHJUWfkotx{HT\ez{|BDS>xawbことxakaとxasaとvaetvaの{dNode6vac1vaく{dNode6vac0wad1ypVxaweこのくらいxakaくxascくらいvaetwad<ypSX][ViqSVWXYZZ[\]^_abdeiklmoqsuvwyz}~BCDEILehIoKVfgC>xawbこのxakaのxasaのvaetvaち{dNode6vac1vaか{dNode6vac0wad1ypdxawdこちらかxakaかxasaかvaetwad<ypYwx|ABFGHINOOQSU[]cdef}~@BCVKLVClnvHK>xawcこちらxakaちxasbちらvaetvaれ{dNode6vac1vaら{dNode6vac0wad1yp@xawcこれらxakaらxasaらvaetwad<yp[SyKUY[ijklnY_gTTdwM>xawbこれxakaれxasaれvaetvaっ{dNode6vac0wad4ypmowExawbこっxakaっxasaっvaetvaろ{dNode6vac0wad:ypYlC^acp{uuxawbころxakaろxasaろvaetvaう{dNode6vac0wad2yp\ixawbこうxakaうxasaうvaetvaん{dNode6vac0wad7yp_Tr]_twxawbこんxakaんxasaんvaetvaこ{dNode6vac0wad1yp|xawbここxakaこxasaこvaetwad3ypqN^xawaこxakaこxasaこvaetvaが{dNode6vac5vaら{dNode6vac0wad1ypZxawbがらxakaらxasaらvaetvaつ{dNode6vac0wad1yphxawcがついxakaつxasbついvaetvaち{dNode6vac0wad1ypBxawdがちだっxakaちxascちだっvaetvaい{dNode6vac3vaて{dNode6vac0wad1ypyxawcがいてxakaてxasaてvaetvaら{dNode6vac0wad1ypGxawiがいらっしゃいましxakaらxasgらっしゃいましvaetvaい{dNode6vac0wad1ypUxawcがいいxakaいxasaいvaetwad0xawbがいxakaいxasaいvaesvaっ{dNode6vac0wad1ypzxawbがっxakaっxasaっvaetwad<ypQRWXZ]^PPRTUWWXY[[\]_abbeeffghiiijjklmppqqqrrrsstuvxxx@@CDEEJKLMOTUWWZZ[\^abggjkklmmnnoqrwx{{{}@ACDEFFFHIKKMMRTTVZftADJKNPQSSSTUVWWWZ]^_bdefgiijjlnostvwxzzz{|~~~@@@@DEFGGLLMNNOOOPQTUUVXXY[^``bccfghjjlnnooppqrrtuvw{|~@@AEGHJJLLMMMOPQQSVWWWXYYZ[[[^`aabcgimnorrrtuuvwxyz{|}@DEEFGGGIMMNNOPRSSS>xawaがxakaがxasaがvaetvaあ{dNode6vac<vaり{dNode6vac2vaま{dNode6vac3vaす{dNode6vac1vaよ{dNode6vac0wad1ypQxawfありますよねxakaよxasbよねvaetwad8ypXesMZ{Omxawdありますxakaすxasaすvaetvaし{dNode6vac0wad2ypDMxawdありましxakaしxasaしvaetvaせ{dNode6vac0wad1yppxaweありませんxakaせxasbせんvaetwad0xawcありまxakaまxasaまvaesvaこ{dNode6vac0wad1ypjxaweありここにxakaこxascここにvaetwad;ypdugGJOQ`kqwxawbありxakaりxasaりvaetvaと{dNode6vac1vaお{dNode6vac0wad1ypUxaweあとおまけxakaおxascおまけvaetwad7yp[TTDBTSxawbあとxakaとxasaとvaetvaる{dNode6vac0wad<ypWZUgiowl}HHVk_fg{Xjor|AG[[vDR>xawbあるxakaるxasaるvaetvaえ{dNode6vac1vaず{dNode6vac0wad5ypUx]x~xawcあえずxakaずxasaずvaetwad1ypmxawbあえxakaえxasaえvaetvaっ{dNode6vac0wad9ypuar}ou@Hfxawbあっxakaっxasaっvaetvaけ{dNode6vac0wad4ypBQq`xawdあけましxakaけxascけましvaetvaれ{dNode6vac0wad3ypg[sxawbあれxakaれxasaれvaetvaん{dNode6vac1vaこ{dNode6vac0wad1yp{xawgあんまりこないxakaこxascこないvaetwad3ypbvXxawdあんまりxakaんxascんまりvaetvaい{dNode6vac1vaて{dNode6vac0wad1yprxawcあいてxakaてxasaてvaetwad2yp^zxawbあいxakaいxasaいvaetvaつ{dNode6vac0wad1yp`xawdあつまりxakaつxascつまりvaetvaま{dNode6vac0wad1ypbxawcあまりxakaまxasbまりvaetvaく{dNode6vac0wad1yppxawdあくまでxakaくxascくまでvaetvaげ{dNode6vac0wad1yp@xawbあげxakaげxasaげvaet>wad1ypxxawaあxakaあxasaあvaetva？{dNode6vac1vaっ{dNode6vac0wad1ypPxawc？ってxakaっxasbってvaetwad<ypQQV^TYcccciFMZZ\uuDDGMV`tQ[x>xawa？xaka？xasa？vaetva {dNode6vac0wad<ypQQRRSSSSSSTUUVVWXXYYZZZZ[\]]]^^__PPPPQTVVWXXXXYYYYYYYYYYYZZ[\\\]]]]]^^^^^^^^^^^^^___```aaaaabbbcccddeeefggghiiiikkllmmmmmmmmnnnnnoopqrssstuvvwwwwwxxxyyyzz{|||||||||||||||||||||||}}}}~~~~@@AAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBCCCCDDDDEEFFFFFFFFFFFFFFFFFFFFFFFGGGHHHIIIIIIIIIJKKLMMNNNNNNNNNNNNNNNNNNNNOOOOOOPQQQQQQQQQQQQQQQRRSSSSSSSSSSTUUUUUVVVVVVWWWWXXXXYYYYYZ[[[\\\\\\\]]]]^^^^^^__``abccccddddeeeeeffffffghhhhhiijkklllmnnnnnnnooooooppppppppppppppppppppppppqrtttttuuuuvvvvvvvvwwwwwwwxyyzzz||}}}}~~~~@@@@@@@@AABCCCCDDDDDDDDDEEEEEEFGHHHIIIJJJJJJJJJJJJJJKKKKKKKLLLMMMNOPPQQRRRRRSSSSSSTTUVVVVVVVVVVWWWWWWWWXXXXXXXYYYYYYYYYYYYYZZZZZZ[[[[[\\\\\]]]]]]]]^^^^^__________`aaaaaaabbbbbbbccccccddddddeeeeeeffffffggghhhhhhhhiiiiijkkkkkkkllllllmmmmmnoooooppppqqqqqrrrsssssssssssttuuuuuvvvvvvvwwxyyyyyyyzzzzzzz{|||}}}}~~~~~~@@AAABBBBBBBBBBCCCCCCDDEEEEEEEFGGHIIIIIIJJJJKKLLLLLMNNNOOOOOOPPQRRRRSTTUUVVVVWWWWWWXXXXYYZZ[\\\]]]]]]]]]]^^__``aabbbbbccddeeffffggiijkmmmoopqrrrsstuuuvvvwwwxyyzzzzz{{{{||}}~ABBBCDDEEFFGHHIJJJJJKKLMNNNOOOPQQQQRRSSSSSTTTUUUVWXYYZZZ[[[\\]]]]^_``aabbcccccddddddefgghhhiiiiijjjkkllmnnnopqqrstuuuuuuuuvvvvvvvvvvvvvvvvvvvwxxxxyyyyzz{{||}}~@ABBCCCCCCDDEEFFFGGGHHIIJJKKLLLLMNNOOPQQRRSSSTTUUUUUUVVVWWWWXXYYZZZZ[[\\\\\\\\\\]]]]]]]]]^^`aabbccddefffgghhiijjkklllmmnnooooppppqrrssstuuvwwwwwxyyyyyzz{{{|}}~@ABBCCCCCCDDEEEFGGHHHIIIIIKLLMNPPPPQRRRRSS>xawa xaka xasa vaetvaそ{dNode6vac;vaし{dNode6vac0wad3ypQu{xawcそしてxakaしxasbしてvaetvaの{dNode6vac3va後{dNode6vac0wad1ypbxaweその後どうxaka後xasc後どうvaetvaま{dNode6vac0wad1ypXxawdそのままxakaまxasbままvaetvaへ{dNode6vac0wad1ypTxawdそのへんxakaへxasbへんvaetwad<ypXoEEW]]]]]cccccdddddeeeeeefffffH^aDOB>xawbそのxakaのxasaのvaetvaこ{dNode6vac2vaに{dNode6vac0wad1ypixawcそこにxakaにxasaにvaetvaで{dNode6vac0wad3ypDXKxawcそこでxakaでxasaでvaetwad0xawbそこxakaこxasaこvaesvaり{dNode6vac0wad1ypmxawbそりxakaりxasaりvaetvaろ{dNode6vac0wad1ypnxawdそろってxakaろxascろってvaetvaも{dNode6vac0wad1ypvxaweそもそものxakaもxasdもそものvaetvaう{dNode6vac0wad7ypTboLyBZxawbそうxakaうxasaうvaetvaれ{dNode6vac2vaぞ{dNode6vac0wad1yp}xawdそれぞれxakaぞxasbぞれvaetvaほ{dNode6vac0wad1yp`xawdそれほどxakaほxasbほどvaetwad2ypzRxawbそれxakaれxasaれvaetvaち{dNode6vac0wad1ypPxawcそちらxakaちxasbちらvaetvaび{dNode6vac0wad1ypbxawcそびれxakaびxasbびれvaetvaか{dNode6vac0wad1ypexawbそかxakaかxasaかvaetwad1ypfxawaそxakaそxasaそvaetvaS{dNode6vac<val{dNode6vac2vaa{dNode6vac0wad2ypQQxaweSlackxakaaxascackvaetvai{dNode6vac0wad1ypcxawfSlidesxakaixasdidesvaetwad0xawbSlxakalxasalvaesvao{dNode6vac2val{dNode6vac1vaJ{dNode6vac0wad1ypmxawfSolrJPxakaJxasbJPvaetwad<ypTZmmmoqtwww~DFGKLOTYY[`lnnuuuw}HIIJN__dkpttyy{IIOR>xawdSolrxakalxasblrvaetvaf{dNode6vac0wad2ypbixaweSoflexakafxascflevaetwad1ypixawbSoxakaoxasaovaetvae{dNode6vac4vaa{dNode6vac0wad<ypXY\^aaegy@CCDEJKKVX^^tDRTTUv>xawfSearchxakaaxasdarchvaetvam{dNode6vac2vaa{dNode6vac0wad3ypYYaxawhSemanticxakaaxaseanticvaetvai{dNode6vac0wad1yphxawgSeminarxakaixasdinarvaetwad0xawcSemxakamxasamvaesvar{dNode6vac2vai{dNode6vac0wad1ypMxaweServixakaixasaivaetvae{dNode6vac1va日{dNode6vac0wad1ypixawjServer日本語版xaka日xasd日本語版vaetwad1ypexawfServerxakaexasbervaetwad0xawdServxakarxasbrvvaesvan{dNode6vac0wad3ypVVVxaweSensexakanxascnsevaetwad0xawbSexakaexasaevaesvap{dNode6vac3vae{dNode6vac0wad1yp^xawhSpecificxakaexasfecificvaetvar{dNode6vac0wad1ypCxawfSpringxakarxasdringvaetval{dNode6vac0wad2ypkkxawfSplunkxakalxasdlunkvaetwad1ypyxawbSpxakapxasapvaetvat{dNode6vac3vau{dNode6vac2vay{dNode6vac0wad1yp^xaweStudyxakayxasayvaetvai{dNode6vac0wad1ypVxawfStudioxakaixasbiovaetwad0xawdStudxakauxasbudvaesvaa{dNode6vac0wad3ypEzDxaweStackxakaaxascackvaetvao{dNode6vac0wad1ypVxaweStoryxakaoxascoryvaetwad0xawbStxakatxasatvaesvau{dNode6vac3vag{dNode6vac0wad1ypgxawgSuggestxakagxaseggestvaetvam{dNode6vac0wad5ypQSUyyxawfSummitxakamxasdmmitvaetvas{dNode6vac0wad1yp]xawgSusheelxakasxasesheelvaetwad0xawbSuxakauxasauvaesvaD{dNode6vac0wad1ypCxawcSDKxakaDxasbDKvaetvaO{dNode6vac2vaN{dNode6vac0wad1yp\xawdSONYxakaNxasbNYvaetvaL{dNode6vac0wad1ypKxawdSOLRxakaLxasbLRvaetwad0xawbSOxakaOxasaOvaesvaa{dNode6vac0wad1yphxawfSasukexakaaxaseasukevaetvac{dNode6vac2vai{dNode6vac0wad3ypppyxawgSciencexakaixaseiencevaetvaa{dNode6vac0wad1ypSxaweScalaxakaaxascalavaetwad0xawbScxakacxasacvaesvaw{dNode6vac1vap{dNode6vac0wad2ypFFxawhSwiftypexakapxasbpevaetwad1ypFxawfSwiftyxakawxasewiftyvaetvah{dNode6vac0wad3ypWWsxawfShieldxakahxasehieldvaetvaE{dNode6vac0wad1ypRxawbSExakaExasaEvaet>wad2yp^HxawaSxakaSxasaSvaetvaも{dNode6vac8vaう{dNode6vac1vaす{dNode6vac0wad1ypcxawdもうすぐxakaすxasbすぐvaetwad:ypQdj\mwCP`Dxawbもうxakaうxasaうvaetvaの{dNode6vac0wad<yp[\\@TVWXYZ[\]^_abdeiklmoqsuvyz~BCDEILRKKM[[dhCD>xawbものxakaのxasaのvaetvaら{dNode6vac3vaっ{dNode6vac0wad2ypuDxawcもらっxakaっxasaっvaetvaう{dNode6vac0wad1ypbxawcもらうxakaうxasaうvaetvaい{dNode6vac0wad1ypbxawcもらいxakaいxasaいvaetwad0xawbもらxakaらxasaらvaesvaと{dNode6vac1vaも{dNode6vac0wad1ypXxawdもともとxakaもxasbもとvaetwad1ypvxawbもとxakaとxasaとvaetvaっ{dNode6vac0wad1ypuxawbもっxakaっxasaっvaetvaち{dNode6vac2vaろ{dNode6vac0wad1ypCxawcもちろxakaろxasaろvaetvaつ{dNode6vac0wad1yprxawdもちつつxakaつxasbつつvaetwad0xawbもちxakaちxasaちvaesvaか{dNode6vac0wad1ypHxawfもかかわらずxakaかxaseかかわらずvaetvaせ{dNode6vac0wad1ypPxawcもせずxakaせxasbせずvaetwad<ypQRVY]]^TVZ[]__`bdddklpquz|~ABFNOPQSTUWghltuvGGTVu{DUV\]_`deeijqvwwxzEEGJJJ]`adghkkrt{}~DGGMRTTWYZ[^`dffgiqrvxz|}ACCK>xawaもxakaもxasaもvaetvaに{dNode6vac:vaよ{dNode6vac2vaる{dNode6vac0wad2ypUrxawcによるxakaるxasaるvaetvaっ{dNode6vac0wad1ypfxawdによってxakaっxasbってvaetwad1ypyxawbによxakaよxasaよvaetvaつ{dNode6vac1vaい{dNode6vac1vaて{dNode6vac0wad<ypW[tzJJLLRDFPVqstF\^IV[_fgn@JPPPQ>xawdについてxakaてxasaてvaetwad2yp{pxawcについxakaいxasaいvaetwad1yp}xawbにつxakaつxasaつvaetvaく{dNode6vac1vaい{dNode6vac0wad8yp|ABFNQSUxawdにくいかxakaいxasbいかvaetwad1ypzxawbにくxakaくxasaくvaetva対{dNode6vac0wad1ypCxawcに対しxaka対xasb対しvaetvaち{dNode6vac1vaょ{dNode6vac0wad1yptxawdにちょっxakaょxasbょっvaetwad2ypTrxawbにちxakaちxasaちvaetvaし{dNode6vac0wad1ypUxawcにしてxakaしxasbしてvaetvaお{dNode6vac1vaじ{dNode6vac1vaま{dNode6vac0wad1ypjxawhにおじゃましましxakaまxasbましvaetwad1ypJxawfにおじゃましxakaじxasdじゃましvaetwad1ypqxawbにおxakaおxasaおvaetvaき{dNode6vac0wad1yp@xawcにきりxakaきxasbきりvaetvaい{dNode6vac0wad1ypHxawcにいるxakaいxasbいるvaetvaて{dNode6vac0wad1ypOxawbにてxakaてxasaてvaetwad<ypQSVWWWXXY\]^_PQRSSSTVXYZZ\\]]_`abceghikklmnoopqrsuvvwyzz{}}@CDGGIIKMPTWWXZ\\\^`bghhjknooprrtuuvvwwxxxyzz|@ACCCCDEEEGIIJJKKLMMPPRRSVWXYZ[[[\]^_abdeffghhiklmoqrrsstuuuuvwyzz||}~~@AABCEEGIIJLLNOPRTXZ[\\`bffgghhkkrruvz{{}@@CDEFHIIIJKKLMMNNNOQQRSSSSTUVWX[]^__`aabccddeffgghiijjkklllmnoppqrstttuuwwyz{|}}~~~@@@@AAACCFFFGHIKKKLMOPPQRRTTTWXXZZZ[[[\\^_`bbddeeeffghhijjkklmoppqrssuuwxxxyz{{|}}@AAABCDDDEFFGGJKKLNPS>xawaにxakaにxasaにvaetva立{dNode6vac4vaち{dNode6vac0wad2ypQkxawb立ちxakaちxasaちvaetvaて{dNode6vac0wad2ypkuxawb立てxakaてxasaてvaetvaっ{dNode6vac0wad1ypkxawb立っxakaっxasaっvaetvaつ{dNode6vac0wad1ypZxawb立つxakaつxasaつvaetwad0xawa立xaka立xasa立vaesva上{dNode6vac2vaが{dNode6vac1vaて{dNode6vac0wad1ypQxawd上がってxakaてxasaてvaetwad1ypKxawc上がっxakaがxasbがっvaetvaげ{dNode6vac0wad2ypkIxawb上げxakaげxasaげvaetwad3ypQZzxawa上xaka上xasa上vaetvaま{dNode6vac:vaす{dNode6vac1vaよ{dNode6vac0wad1ypQxawdますよねxakaよxasbよねvaetwad<yp^WZdlr{@J[\^hiouwCGHILPReft|AAWgiPTc|BDz|P>xawbますxakaすxasaすvaetvaた{dNode6vac1vaま{dNode6vac0wad4yp{sxQxawdまたまたxakaまxasbまたvaetwad8ypXYr_PVYBxawbまたxakaたxasaたvaetvaし{dNode6vac0wad<ypZ]QVWX_`ailsxy}HLP_tGKNOQUZ`jnpx{GHKMSTUV`befmnrsvwyz|~BGHJJSU]clnwxyGJMSSUVWZfhijrsy{DEIJKKN>xawbましxakaしxasaしvaetvaず{dNode6vac0wad<yp^huCIR|Wdrrx|Zw>xawbまずxakaずxasaずvaetvaつ{dNode6vac0wad1yp_xawdまつわるxakaつxascつわるvaetvaで{dNode6vac0wad<ypSY`KY[]ijkl_t[F>xawbまでxakaでxasaでvaetvaだ{dNode6vac1vaま{dNode6vac0wad1yp_xawdまだまだxakaまxasbまだvaetwad<ypXmowER[\lq{b>xawbまだxakaだxasaだvaetvaと{dNode6vac1vaて{dNode6vac0wad2ypYTxawdまとめてxakaてxasaてvaetwad1ypoxawcまとめxakaとxasbとめvaetvaぁ{dNode6vac0wad6ypzuGDTqxawbまぁxakaぁxasaぁvaetvaせ{dNode6vac0wad2ypq~xawcませんxakaせxasbせんvaetwad5ypZlK{Txawaまxakaまxasaまvaetvaと{dNode6vac<vaい{dNode6vac3vaう{dNode6vac1vaか{dNode6vac0wad3ypIl|xawdというかxakaかxasaかvaetwad<ypQZU^abehinstz{DKMVZZ_abmprt@ABMPTt}}DKUXZefgjnru{DJMUWXZfkkotux{GJY\^dempqqtz{|BDM>xawcというxakaうxasaうvaetvaい{dNode6vac1vaつ{dNode6vac0wad2yp[xaweといいつつxakaつxasbつつvaetwad2yp[Mxawcといいxakaいxasaいvaetvaっ{dNode6vac1vaて{dNode6vac0wad4ypGG}fxawdといってxakaてxasaてvaetwad1ypdxawcといっxakaっxasaっvaetwad1yptxawbといxakaいxasaいvaetvaし{dNode6vac1vaて{dNode6vac0wad<ypQZQ\g{t|BcCHZMR>xawcとしてxakaてxasaてvaetwad2ypoxxawbとしxakaしxasaしvaetvaか{dNode6vac1vaし{dNode6vac0wad1yp{xawcとかしxakaしxasaしvaetwad9yp^jjHHRT{exawbとかxakaかxasaかvaetvaり{dNode6vac0wad6ypUx]mx~xawbとりxakaりxasaりvaetvaき{dNode6vac1vaっ{dNode6vac0wad1yphxawcときっxakaっxasaっvaetwad6yp\b@M`axawbときxakaきxasaきvaetvaど{dNode6vac0wad1ypixawcとどうxakaどxasbどうvaetvaっ{dNode6vac2vaく{dNode6vac0wad1ypIxawcとっくxakaくxasaくvaetvaて{dNode6vac0wad1yp[xawcとってxakaてxasaてvaetwad3ypxh{xawbとっxakaっxasaっvaetvaう{dNode6vac2vaご{dNode6vac2vaす{dNode6vac0wad4ypBQq`xawgとうございますxakaすxasaすvaetvaし{dNode6vac0wad1yp`xawgとうございましxakaしxasaしvaetwad0xawfとうございまxakaごxasdございまvaesvaれ{dNode6vac0wad1ypPxawcとうれxakaれxasaれvaetwad1ypwxawbとうxakaうxasaうvaetvaず{dNode6vac0wad1ypBxawcとずつxakaずxasbずつvaetvaま{dNode6vac0wad1ypqxawcとまぁxakaまxasbまぁvaetvaく{dNode6vac0wad2ypKhxawbとくxakaくxasaくvaetvaて{dNode6vac0wad1ypaxawbとてxakaてxasaてvaetvaお{dNode6vac0wad1ypNxawcとおりxakaおxasbおりvaetvaふ{dNode6vac0wad1ypSxawbとふxakaふxasaふvaetvaこ{dNode6vac0wad1yp{xawcところxakaこxasbころvaet>wad<ypUY[[[\RRTWYY[]_fhjlmpqyz}JKRRSTUWWY[\`abbgilmoprssuwyz{}}~@BCDDEHHMPSTdfghuy|DJQVX[[\]^^`abccdehkkkmnnpqrty{|||@FFFKLMNORW]hhhjlxyz{{|~~BDDLMPRSSSSSTTUWXY`aajkllmortttuuuvx{}@DEEJMQSS>xawaとxakaとxasaとvaetvaは{dNode6vac5vaり{dNode6vac0wad1ypixawbはりxakaりxasaりvaetvaち{dNode6vac0wad1ypyxawdはちょっxakaちxascちょっvaetvaい{dNode6vac0wad1ypQxawbはいxakaいxasaいvaetvaや{dNode6vac0wad2ypoxawbはやxakaやxasaやvaetvaじ{dNode6vac1vaて{dNode6vac0wad1ypSxawdはじめてxakaてxasaてvaetwad1ypSxawcはじめxakaじxasbじめvaetwad<ypQSSTTTXXYZ^____PQQTUV\^___``accceefhjntwwwxxyz|}~@ABCFGGGHHIJJLNNOOQRSTUY[[]cdefhjmnstuvvy|}~AABCCCGIIIKMRRSTVWXYZZ[[\]^__abddehiklmoqrrsuuvyz{{||}~AAABBCDEFGIJJLOTUVVWWZ^abcdghkqrrswyz|}~~ACHKLMMMMNRTTUZ]^_bcjkqqrstuuvxxz{{|CCEFQUVWYYZacddehijjjkllmnpvwxz|ACDFFGGGGHMNPQQS>xawaはxakaはxasaはvaetvaの{dNode6vac4vaか{dNode6vac0wad4ypQ`gbxawbのかxakaかxasaかvaetvaめ{dNode6vac0wad1yp@xawdのめもみxakaめxascめもみvaetvaく{dNode6vac0wad1ypWxawdのくらいxakaくxascくらいvaetvaみ{dNode6vac0wad1ypLxawbのみxakaみxasaみvaetwad<ypQRRSSSSTTTTUUUVVWXYZ[[\\]__PPPPQQRRRRSSTTUUUWWWXXYYY\\\\\\]]]^`abcdfffffggghhhhiijjjklmmmnnnoooopppqqrrrsuuuuuvvvwwxyzz{{{|||}~~~~@@AAABBBCCDDEEFFFGGHHIIIJKKLLLLMNNNOOPPPQQQRRRSSSTTUUUVWXYYZZZ[[[[_```aaabbcdefggghiillmmnnnnooqqrrttuuvvvwwxxxxyyyyzzzzz{|||}}~@AAACDDDEEFGGGHIIJJKKKLLNNOOPPPPPQQRRRSSSSUUVWXXXYYYYZ[\\]]^^__``aabbccdddddeeefggghiijjkklllmmnnooppqqrrrstuvwwwwxxyyz{{}}~@AABBBCCDEFFFFFGGHHIJJLMMOPPPQRSSSSUVWWXYYY[\]]^^_____`aaabbccccddddffgggjjjkkkllmnooppqrsstuuvvvwxyzz{{{|}~~~@@@AAABCCDDEFGGHHIIJJKKLLMMMNOOOOPPQRSSSTTUVVVWWWXXYYY[\]]]]^^__`aaabcceffghiiilmmmnoopqqrrsssstuuwwwxyyzzzz{{||}}}}~~~@@@AABBCDDDDDEEFFGGHHHHIIIIKKLLLMNNOPQRSTTUXYYYZ[[[]]]^^___`aaaaabccfghhiiiijjkkkllllnpppqrrrrrrssstttuuuvvvvvwwxyyyyzzzzz{{|||||}}}}~~~@@@ABBBCCCDDFFGGIIIIJJKKLLMNPPPPQQRRS>xawaのxakaのxasaのvaetvaボ{dNode6vac4vaッ{dNode6vac0wad1ypQxawcボットxakaッxasbットvaetvaー{dNode6vac0wad2yp``xawfボードゲームxakaーxaseードゲームvaetvaケ{dNode6vac0wad1ypVxawbボケxakaケxasaケvaetvaタ{dNode6vac0wad1ypExawcボタンxakaタxasbタンvaetwad0xawaボxakaボxasaボvaesva今{dNode6vac8va年{dNode6vac3va買{dNode6vac0wad2yp[[xawd今年買っxaka買xasb買っvaetva起{dNode6vac0wad3ypowExawc今年起xaka起xasa起vaetva初{dNode6vac0wad1ypjxawc今年初xaka初xasa初vaetwad<ypRST]]^_VVZ]]__``lr{huvBCCIIJMRSST{{|Dq[`aaD>xawb今年xaka年xasa年vaetva回{dNode6vac0wad<ypZQTw~@CJLPyJT`k}~AGM^`rsCEQQYcdjjjrz|CQ>xawb今回xaka回xasa回vaetva日{dNode6vac0wad9ypqvZ^ac^uxawb今日xaka日xasa日vaetva週{dNode6vac0wad3ypDfWxawb今週xaka週xasa週vaetva月{dNode6vac0wad2ypTYxawb今月xaka月xasa月vaetva開{dNode6vac0wad1yp}xawc今開発xaka開xasb開発vaetva朝{dNode6vac0wad1ypExawd今朝起きxaka朝xasc朝起きvaetvaさ{dNode6vac0wad2ypSSxawc今さらxakaさxasbさらvaetwad4ypxrx{xawa今xaka今xasa今vaetva振{dNode6vac1vaり{dNode6vac0wad<ypRR^^^ZZkllhhouuwCEIJRR|rrha>xawb振りxakaりxasaりvaetwad1ypaxawa振xaka振xasa振vaetva返{dNode6vac3vaり{dNode6vac0wad<ypRR^^ZZkllhhuuCIRR|rrha>xawb返りxakaりxasaりvaetvaせ{dNode6vac0wad1ypmxawb返せxakaせxasaせvaetvaっ{dNode6vac0wad4ypowEJxawb返っxakaっxasaっvaetwad1yp^xawa返xaka返xasa返vaetvaブ{dNode6vac3vaロ{dNode6vac3va移{dNode6vac0wad<ypX]]]]]cccccdddddeeeeeffff>xawgブログ移行日記xaka移xasd移行日記vaetva書{dNode6vac0wad4yplIhLxaweブログ書いxaka書xasb書いvaetva流{dNode6vac0wad1ypKxawdブログ流xaka流xasa流vaetwad<ypRX^SZffkov~KLRTVbipuz|@BHKMVWXYZ[\]^_abdeiklmoqsuvyz~ABCEIJLP[pst}CLWWX^bcz@SV[ag}FS>xawcブログxakaロxasbログvaetvaー{dNode6vac0wad2yp|Sxawcブースxakaーxasbースvaetvaラ{dNode6vac0wad1ypwxawdブランチxakaラxascランチvaetwad0xawaブxakaブxasaブvaesvaを{dNode6vac0wad<ypRUUVWWXYYYZ[\\]^^_QQSSSSTUUYZ[[\^^bccgghhjkklmoppqsttvvwyyz{{{|@@ABCEFHKLMMNPPQRSTUVVVWWWWXXXYZ[\^^__```aabbbghiijjkklooqtuuwwxyyz|~AAABCCEEFGHHIJLMNOPQRRSUVVWXYZ[[\]]^_`abcdeeffhijkkkllmnopqssuvwxyzz~~@AABCCEEFGHIIJKLLMPPRRTUWWX[\]_`aceejklllmoptttwyy}~AABEFGIKLLOPQRSTVVWWWXXYZ\^^aacdefgghlmrrtuvz||~@AABCDEGHILNNOORSTUVVXYYZ[^__``abbcddegghijkmmmnqqrsstuuwz}}~~@@ABCDDGGHHHJKLMNOOQQQSS>xawaをxakaをxasaをvaetvaリ{dNode6vac:vaビ{dNode6vac0wad1ypRxawdリビングxakaビxascビングvaetvaア{dNode6vac2vaタ{dNode6vac0wad1yp^xawdリアタイxakaタxasbタイvaetvaル{dNode6vac0wad1ypkxawdリアルタxakaルxasbルタvaetwad0xawbリアxakaアxasaアvaesvaラ{dNode6vac0wad1ypUxawdリライトxakaラxascライトvaetvaリ{dNode6vac1vaス{dNode6vac0wad<ypWmEJKKXYZZesy~BCKSnoossuYY\nnnwEJMNOcnyyyHIIIIN>xawdリリースxakaスxasaスvaetwad1ypRxawcリリーxakaリxasbリーvaetvaス{dNode6vac1vaア{dNode6vac0wad1yp[xawfリストアップxakaアxascアップvaetwad2ypVqxawcリストxakaスxasbストvaetvaン{dNode6vac0wad6yp^vlyFIxawcリンクxakaンxasbンクvaetvaポ{dNode6vac0wad1ypsxaweリポジトリxakaポxasdポジトリvaetvaク{dNode6vac2vaエ{dNode6vac0wad1ypCxaweリクエストxakaエxascエストvaetvaル{dNode6vac1vaテ{dNode6vac0wad9ypNOU`jnxHMxawlリクルートテクノロジーズxakaテxasgテクノロジーズvaetwad1ypYxaweリクルートxakaルxascルートvaetwad0xawbリクxakaクxasaクvaesvaフ{dNode6vac0wad2ypIOxawhリファクタリングxakaフxasgファクタリングvaetvaツ{dNode6vac0wad1ypixaweリツイートxakaツxasdツイートvaetwad0xawaリxakaリxasaリvaesva書{dNode6vac9vaい{dNode6vac0wad<ypRRVX^^ZflotvGTThu|CCDIILLRR||\elrrt}@LMPRhiz~@BI[[`af>xawb書いxakaいxasaいvaetvaき{dNode6vac1vaま{dNode6vac0wad<yp[kpzJLVbe|@g@>xawd書きましxakaまxasbましvaetwad7yp\bGV[dBxawb書きxakaきxasaきvaetvaく{dNode6vac0wad7yp[zV_tW^xawb書くxakaくxasaくvaetva式{dNode6vac0wad1ypexawb書式xaka式xasa式vaetvaけ{dNode6vac1vaる{dNode6vac0wad1ypexawc書けるxakaるxasaるvaetwad1ypWxawb書けxakaけxasaけvaetva展{dNode6vac0wad1ypqxawb書展xaka展xasa展vaetva籍{dNode6vac0wad7ypqGvvvgmxawb書籍xaka籍xasa籍vaetvaこ{dNode6vac0wad5ypJ]]Nhxawc書こうxakaこxasbこうvaetvaか{dNode6vac0wad4ypPhVgxawb書かxakaかxasaかvaetwad2ypZixawa書xaka書xasa書vaetvaて{dNode6vac1vaる{dNode6vac0wad<ypuzhsss|WDHLLN]_ORW^>xawbてるxakaるxasaるvaetwad<ypRRVVWXXXYYY[]]^PQSTTUUVVWWZZ[[]^^_`bbcdddfgghijjkllllqqqqrttuvvvvy{{}}@CCDEEEGGHIITTTVVWWXXX\\\^^^__`aabgghiiijkklllnnnoopqqrstuvwwxxx{|~@ABBCDEEGHHHIJKKLLLLMMNOPQRU[`cefghhjnux||AAHJKMPPQSTTUUWXXX[[[\]^bbbdeggilllnqqrttuvwxyzz{}}@@ABCDDDEEFHIIKLLNOOPPPQRRSSTUUVVWXXXX[[[\\^^^^____bcccdeijkklmmnppppqqrrssttvyzz{}~@@ABBBCDDDGHHHIJKLLLOPPPPPQRSTTTUVWXYZZ[[^_``abbdefghhjjjkkklmmpqttuuvvvwwz|@@ABEFGGGKKMOQS>xawaてxakaてxasaてvaetvaい{dNode6vac<vaま{dNode6vac4vaす{dNode6vac1vaか{dNode6vac0wad1ypcxawdいますかxakaかxasaかvaetwad<ypRVWXYjqEXxEOAX>xawcいますxakaすxasaすvaetvaし{dNode6vac0wad9ypXbgnei@nmxawcいましxakaしxasaしvaetvaさ{dNode6vac0wad1ypfxawdいまさらxakaさxasbさらvaetvaだ{dNode6vac0wad1ypxxawcいまだxakaだxasaだvaetwad0xawbいまxakaまxasaまvaesvaる{dNode6vac0wad<ypR[TVhjqt}CX^glKQQl}V\^^yuvG>xawbいるxakaるxasaるvaetvaく{dNode6vac1vaつ{dNode6vac0wad4ypWp\Dxawdいくつかxakaつxasbつかvaetwad2yp^qxawbいくxakaくxasaくvaetvaろ{dNode6vac2vaん{dNode6vac0wad3ypQCjxawcいろんxakaんxasaんvaetvaい{dNode6vac0wad1ypfxawdいろいろxakaいxasbいろvaetwad0xawbいろxakaろxasaろvaesvaち{dNode6vac0wad1ypUxawdいちばんxakaちxascちばんvaetvaき{dNode6vac2vaな{dNode6vac0wad1ypYxawdいきなりxakaなxasbなりvaetvaま{dNode6vac0wad2ypI`xawdいきますxakaまxasbますvaetwad0xawbいきxakaきxasaきvaesvaつ{dNode6vac1vaも{dNode6vac1vaの{dNode6vac0wad5ypfX{m\xawdいつものxakaのxasaのvaetwad2yphZxawcいつもxakaもxasaもvaetwad2ypdhxawbいつxakaつxasaつvaetvaい{dNode6vac1vaか{dNode6vac0wad1ypjxaweいいかげんxakaかxascかげんvaetwad2yppxawbいいxakaいxasaいvaetvaけ{dNode6vac0wad2ypbpxawcいけるxakaけxasbけるvaetvaう{dNode6vac0wad1ypmxawbいうxakaうxasaうvaetvaら{dNode6vac0wad1yp~xawfいらっしゃっxakaらxaseらっしゃっvaetvaっ{dNode6vac0wad1ypcxawbいっxakaっxasaっvaetvaや{dNode6vac1vaぁ{dNode6vac0wad1ypvxawcいやぁxakaぁxasaぁvaetwad1ypdxawbいやxakaやxasaやvaetvaれ{dNode6vac0wad1ypGxawbいれxakaれxasaれvaet>wad<ypUWZddfrv{@WX^alqBNOU`efjnxHMPVW[\gkxyTUXX[[\cqrtu@HJLR^_ghjktw@@FHK>xawaいxakaいxasaいvaetva（{dNode6vac0wad<ypRRVX\^^RXZ_aeelhjtuxz@CIMTWZ\^abimoqv@SW]^acfpyGHMNRY[\`deeiiiimvEOQT[\\_`cdfghmnpqvvxy|CCFIK>xawa（xaka（xasa（vaetvaド{dNode6vac5vaミ{dNode6vac0wad1ypRxaweドミノ倒しxakaミxasdミノ倒しvaetvaキ{dNode6vac2vaュ{dNode6vac0wad1ypUxawfドキュメントxakaュxasdュメントvaetvaド{dNode6vac0wad1yphxawdドキドキxakaドxasbドキvaetwad0xawbドキxakaキxasaキvaesvaッ{dNode6vac0wad1ypjxawhドットファイル系xakaッxasgットファイル系vaetvaリ{dNode6vac0wad1ypYxawdドリコムxakaリxascリコムvaetvaタ{dNode6vac0wad1ypdxawdドタバタxakaタxascタバタvaetwad0xawaドxakaドxasaドvaesvaす{dNode6vac<vaご{dNode6vac2vaい{dNode6vac0wad2ypRyxawcすごいxakaいxasaいvaetvaく{dNode6vac0wad1ypxxawdすごくてxakaくxasbくてvaetwad0xawbすごxakaごxasaごvaesvaる{dNode6vac0wad<ypS\qty^`xx@rU[cACCfFKMTstNO>xawbするxakaるxasaるvaetvaか{dNode6vac0wad1ypxxawcすかねxakaかxasbかねvaetvaい{dNode6vac1vaか{dNode6vac0wad1ypOxawcすいかxakaかxasaかvaetwad1yplxawbすいxakaいxasaいvaetvaも{dNode6vac0wad1ypTxaweすもけさんxakaもxasdもけさんvaetvaね{dNode6vac1vaぇ{dNode6vac0wad1ypdxawcすねぇxakaぇxasaぇvaetwad7ypowhvfoxxawbすねxakaねxasaねvaetvaで{dNode6vac0wad1ypvxawbすでxakaでxasaでvaetvaら{dNode6vac0wad1ypxxawbすらxakaらxasaらvaetvaず{dNode6vac0wad1yplxawfすずけんさんxakaずxaseずけんさんvaetvaよ{dNode6vac0wad1ypuxawcすよねxakaよxasbよねvaetvaみ{dNode6vac2vaせ{dNode6vac0wad3ypYoBxaweすみませんxakaせxasbせんvaetvaし{dNode6vac0wad1ypxxawdすみましxakaしxasaしvaetwad0xawcすみまxakaみxasbみまvaesvaん{dNode6vac0wad1ypjxawbすんxakaんxasaんvaetvaぐ{dNode6vac1vaや{dNode6vac0wad1ypoxawfすぐやりますxakaやxasdやりますvaetwad2ypoxawbすぐxakaぐxasaぐvaet>wad<ypSSTU_PXYZ[]dffnoqruwxz~GGKSU[_jlmmmnvz|}~AGKPSTYprww}}DFJPRVVW\]^abcddfjkqvxy|||}}~~AEGLQUVX\^``abcfilqrtuxxx}~CEILRWXXXYY[^`acdflllmnpsuuxxy{{~AFGIPQQSSS>xawaすxakaすxasaすvaetva）{dNode6vac0wad<ypRVX\^^XZ_aelhjtux@CIMTWZ\^abimoqv@S]^acfyHMY[\`deeiiimvEOQ\`cdfhmnqvxy|CCFIJK>xawa）xaka）xasa）vaetva。{dNode6vac0wad<ypRRRRSSTTUUVXXYZZ[\]]^^___PPQSTUVVWXXYZZ[\]]^^__``addefghikkllmmnnopqrstuvwwwwxxxxxxxyzz{||}~~@AABBDFFGGGHHHHHIIIIIJLMNNOOOPPQQQRSSSTUUUVXY[[[\]^__``aaaabccddhhhhhiiiijklmmnooppttuuvwwwwxyyz|}}}~~@@@@ABBCCCDDEEGGHHIIJJKKLLMNOPPPPPQQRRRSSTTTTTTUVWXYYZZ[[\]^_`abcdeefghhhijklmnoppqrrsstuvwwxyz{{{|||||}}~@AAABCCDDDEFGHIJJJJJKLMPQRSTTUUVVVWWWWWXXY[\\]]]]^^^^___``aaaabbccccddeffgghijkkmnoqqrrstttuvvwwwxxyzz{{||}}}}~ABBCCDEEEEEFGGIJJJKKLNNNNOPQRRSSTUVWZ[\]]]]^^^``abbbcccccddddddghhhiijjkkllmnnprstuuvvvvwxxxxxxyz{{{{||}}}}~@@@ABBBBCCCDDEEFGHIIJKKLLMNOPQQRRSSSSSTTUUVWWWXXYYYYZZ[\]]^^^````aabccdddddefffghhiiiijjklllmmnnoooooooooopppqrrssstuuuuvvwwxxxxyyzzz{{{||||}~~~@ABBCDEFGGHHIIJKKMNPPQSS>xawa。xaka。xasa。vaetvaF{dNode6vac5vaM{dNode6vac0wad1ypRxawcFMVxakaMxasbMVvaetvaS{dNode6vac0wad1ypxawcFSTxakaSxasbSTvaetvao{dNode6vac0wad2ypffxaweFoundxakaoxasdoundvaetval{dNode6vac0wad3ypYrZxawgFluentdxakalxasfluentdvaetvaa{dNode6vac0wad3ypCpwxawdFallxakaaxascallvaetwad1ypSxawaFxakaFxasaFvaetvaキ{dNode6vac2vaボ{dNode6vac0wad6ypRnoorrxaweキーボードxakaボxascボードvaetvaワ{dNode6vac0wad1ypbxaweキーワードxakaワxascワードvaetwad1ypixawbキーxakaキxasbキーvaetvaタ{dNode6vac4vaイ{dNode6vac4vaポ{dNode6vac0wad1ypRxawcタイポxakaポxasaポvaetvaム{dNode6vac2vaラ{dNode6vac0wad1yprxawfタイムラインxakaラxascラインvaetvaテ{dNode6vac0wad2ypCQxawgタイムテーブルxakaテxasdテーブルvaetwad0xawcタイムxakaムxasaムvaesvaミ{dNode6vac1vaン{dNode6vac0wad1ypVxawdタイミンxakaンxasaンvaetwad1ypIxawcタイミxakaミxasaミvaetvaプ{dNode6vac0wad1ypdxawcタイプxakaプxasaプvaetwad0xawbタイxakaイxasaイvaesvaー{dNode6vac0wad3ypiikxaweターミナルxakaーxasdーミナルvaetvaム{dNode6vac0wad1ypPxawdタムタムxakaムxascムタムvaetvaワ{dNode6vac0wad1yp\xawfタワーホールxakaワxaseワーホールvaetwad1yptxawaタxakaタxasaタvaetvaつ{dNode6vac4vaら{dNode6vac0wad1ypRxawcつらいxakaらxasbらいvaetvaい{dNode6vac0wad3ypbnRxawbついxakaいxasaいvaetvaぶ{dNode6vac0wad1ypSxaweつぶやいてxakaぶxasdぶやいてvaetvaけ{dNode6vac0wad3yp^izxawcつけてxakaけxasbけてvaetwad0xawaつxakaつxasaつvaesva記{dNode6vac4va事{dNode6vac0wad<ypSSZ[PPSmn|ABFNQSUZcdefnnovwDEJKSVWXYZ[\]^_abdeiklmoqsuvyz}~BCDEFILS_elpx@AMNVgu@MV`fg@B>xawb記事xaka事xasa事vaetva載{dNode6vac0wad6ypLMQfz|xawb記載xaka載xasa載vaetva録{dNode6vac0wad2yp\lxawb記録xaka録xasa録vaetva念{dNode6vac0wad2ypM`xawb記念xaka念xasa念vaetwad1yprxawa記xaka記xasa記vaetva情{dNode6vac2va報{dNode6vac2va検{dNode6vac0wad3ypSPnxawd情報検索xaka検xasb検索vaetva研{dNode6vac0wad1ypFxawc情報研xaka研xasa研vaetwad2ypSExawb情報xaka報xasa報vaetvaけ{dNode6vac0wad1yp@xawb情けxakaけxasaけvaetwad0xawa情xaka情xasa情vaesva・{dNode6vac0wad8ypSPn@h]JJxawa・xaka・xasa・vaetva検{dNode6vac2va索{dNode6vac4va技{dNode6vac1va勉{dNode6vac0wad2ypdsxawg検索技術勉強会xaka勉xasc勉強会vaetwad2ypSPxawd検索技術xaka技xasb技術vaetva条{dNode6vac0wad1ypexawd検索条件xaka条xasb条件vaetva周{dNode6vac0wad2yp{^xawd検索周りxaka周xasb周りvaetvaシ{dNode6vac0wad1yp_xawd検索シスxakaシxasbシスvaetwad<ypSUVV\atttz{XX_nHCefKE>xawb検索xaka索xasa索vaetva討{dNode6vac0wad1ypOxawb検討xaka討xasa討vaetwad0xawa検xaka検xasa検vaesvaA{dNode6vac<vad{dNode6vac0wad<ypSSP]mnnovvwDEJKSS}Di>xawfAdventxakadxasedventvaetvan{dNode6vac2vaa{dNode6vac2vaz{dNode6vac1var{dNode6vac0wad4ypQR@axawhAnalyzerxakarxasarvaetwad2ypVAxawgAnalyzexakazxasbzevaetvas{dNode6vac0wad2yp^axawhAnalysisxakasxascsisvaetwad0xaweAnalyxakaaxascalyvaesvan{dNode6vac0wad1ypVxawjAnnouncingxakanxashnouncingvaetwad0xawbAnxakanxasanvaesvaz{dNode6vac0wad<ypX\\^aegy@CCDVX^^>xaweAzurexakazxasdzurevaetval{dNode6vac0wad1ypXxaweAliasxakalxasdliasvaetvau{dNode6vac0wad1ypgxawlAutocompletexakauxaskutocompletevaetvaW{dNode6vac0wad5ypMZQSUxawcAWSxakaWxasbWSvaetvam{dNode6vac1vao{dNode6vac0wad5yp\ZKRRxawfAmazonxakaoxasbonvaetwad1ypRxawdAmazxakamxascmazvaetvac{dNode6vac0wad1ypqxawiAcroquestxakacxashcroquestvaetvaP{dNode6vac2vaM{dNode6vac0wad1ypzxawcAPMxakaMxasaMvaetvaI{dNode6vac0wad6yp_J_QWbxawcAPIxakaIxasaIvaetwad0xawbAPxakaPxasaPvaesvag{dNode6vac2vae{dNode6vac0wad1ypzxaweAgentxakaexascentvaetvag{dNode6vac0wad1yp]xawkAggregationxakagxasigregationvaetwad0xawbAgxakagxasagvaesvap{dNode6vac0wad2ypFIxawfApachexakapxasepachevaetvaa{dNode6vac0wad1yppxaweAaronxakaaxasdaronvaetvat{dNode6vac0wad1ypixawiAtlassianxakatxashtlassianvaetvai{dNode6vac0wad2ypqCxawcAirxakaixasbirvaetvaL{dNode6vac0wad2ypuwxaweALPHAxakaLxasdLPHAvaetvaC{dNode6vac0wad1ypvxawcACMxakaCxasbCMvaetvaI{dNode6vac0wad1ypsxawcAIRxakaIxasbIRvaet>wad2ypT\xawaAxakaAxasaAvaetvaC{dNode6vac9vaa{dNode6vac3val{dNode6vac2vae{dNode6vac0wad<ypSSP]mnnovvwDEJKSSDi>xawhCalendarxakaexaseendarvaetvan{dNode6vac0wad1yp}xawgCalndarxakanxasdndarvaetwad0xawcCalxakalxasalvaesvas{dNode6vac2vae{dNode6vac0wad1yp^xawdCasexakaexasaevaetvau{dNode6vac0wad1ypbxawfCasualxakauxascualvaetwad0xawcCasxakasxasasvaesvat{dNode6vac0wad1ypkxawhCatalinaxakatxasftalinavaetwad0xawbCaxakaaxasaavaesvao{dNode6vac4van{dNode6vac4vat{dNode6vac0wad2ypWZxawiContainerxakatxasftainervaetvav{dNode6vac0wad1yplxawlConversationxakavxasiversationvaetvaf{dNode6vac0wad2ypdwxawjConferencexakafxasgferencevaetvac{dNode6vac0wad1ypvxawhConceptsxakacxaseceptsvaetwad0xawcConxakanxasanvaesvad{dNode6vac1var{dNode6vac0wad2ypUUxaweCoderxakarxasarvaetwad3ypZVUxawdCodexakadxasbdevaetvag{dNode6vac0wad<ypX\^aegy@CCDX^^>xawiCognitivexakagxasggnitivevaetvar{dNode6vac2van{dNode6vac1va使{dNode6vac0wad1ypixawgCorne使っxaka使xasb使っvaetwad2ypjoxaweCornexakanxasbnevaetvae{dNode6vac0wad1yptxawdCorexakaexasaevaetwad0xawcCorxakarxasarvaeswad1yplxawbCoxakaoxasaovaetvaL{dNode6vac0wad3ypRRZxawcCLIxakaLxasbLIvaetval{dNode6vac3vai{dNode6vac0wad1ypVxawfClientxakaixasdientvaetvao{dNode6vac0wad6ypzDRTTUxawhClouderaxakaoxasfouderavaetvae{dNode6vac0wad3ypUUUxaweCleanxakaexasceanvaetwad1ypZxawbClxakalxasalvaetvah{dNode6vac3var{dNode6vac0wad2ypDJxawiChristmasxakarxasgristmasvaetvae{dNode6vac0wad1ypYxawdChefxakaexasbefvaetvaa{dNode6vac0wad2ypYYxawgChangesxakaaxaseangesvaetwad0xawbChxakahxasahvaesvaR{dNode6vac0wad5yp{eeffxaweCROSSxakaRxasdROSSvaetvaC{dNode6vac0wad3ypGCpxawcCCCxakaCxasbCCvaetvau{dNode6vac0wad2ypSSxawgCuratorxakauxasfuratorvaetvaD{dNode6vac0wad1ypPxawbCDxakaDxasaDvaetwad1ypZxawaCxakaCxasaCvaetva昨{dNode6vac5va年{dNode6vac3va少{dNode6vac0wad1ypBxawc昨年少xaka少xasa少vaetva書{dNode6vac0wad2yprhxawd昨年書いxaka書xasb書いvaetva末{dNode6vac0wad1yp[xawc昨年末xaka末xasa末vaetwad<ypST[]_`|rBXhC>xawb昨年xaka年xasa年vaetva日{dNode6vac0wad5ypT_NQqxawb昨日xaka日xasa日vaetva今{dNode6vac0wad1ypuxawb昨今xaka今xasa今vaetva晩{dNode6vac0wad3ypn@@xawb昨晩xaka晩xasa晩vaetva夜{dNode6vac0wad1ypsxawb昨夜xaka夜xasa夜vaetwad0xawa昨xaka昨xasa昨vaesva続{dNode6vac2vaき{dNode6vac1vaっ{dNode6vac0wad1ypTxawe続きっぽいxakaっxascっぽいvaetwad<ypSP]w~IO}~F_AQd@CIuv>xawb続きxakaきxasaきvaetvaい{dNode6vac0wad1ypnxawb続いxakaいxasaいvaetwad0xawa続xaka続xasa続vaesva参{dNode6vac4va戦{dNode6vac0wad1ypSxawb参戦xaka戦xasa戦vaetva加{dNode6vac3va登{dNode6vac0wad1ypyxawe参加登録者xaka登xasc登録者vaetva者{dNode6vac0wad3ypy~Gxawc参加者xaka者xasa者vaetva人{dNode6vac0wad1ypxxawd参加人数xaka人xasb人数vaetwad<yp]_pt|gr{Xbfzzz{HJJ]abbdjklmppsxyCCGLLQTWZZ\bdehhp{EJ>xawb参加xaka加xasa加vaetva照{dNode6vac0wad1yp^xawb参照xaka照xasa照vaetva考{dNode6vac0wad1ypCxawb参考xaka考xasa考vaetwad1yp`xawa参xaka参xasa参vaetva夏{dNode6vac1va休{dNode6vac0wad1ypxxawb夏休xaka休xasa休vaetwad1ypSxawa夏xaka夏xasa夏vaetvaP{dNode6vac9vay{dNode6vac3vaS{dNode6vac0wad2ypT_xawePySpaxakaSxascSpavaetvat{dNode6vac0wad3ypV\\xawfPythonxakatxasdthonvaetvaC{dNode6vac0wad1yp[xawgPyCharmxakaCxaseCharmvaetwad0xawbPyxakayxasayvaesvaC{dNode6vac0wad9yp_jkqjlDDDxawbPCxakaCxasaCvaetvar{dNode6vac2vao{dNode6vac3vad{dNode6vac0wad1ypYxawgProductxakadxasdductvaetvac{dNode6vac0wad1ypLxawiProcessorxakacxasfcessorvaetvax{dNode6vac0wad1ypQxaweProxyxakaxxasbxyvaetwad2ypklxawcProxakaoxasaovaetvae{dNode6vac2vat{dNode6vac0wad1yp^xawkPretrainingxakatxashtrainingvaetvas{dNode6vac0wad1ypvxawePressxakasxasbssvaetwad1ypLxawcPrexakaexasaevaetwad0xawbPrxakarxasarvaesvau{dNode6vac0wad1ypaxawfPublicxakauxaseublicvaetvao{dNode6vac0wad1ypcxawjPowerpointxakaoxasiowerpointvaetvaD{dNode6vac0wad2ypvmxawcPDFxakaDxasbDFvaetvaa{dNode6vac2vag{dNode6vac0wad1ypXxawePagesxakagxascgesvaetvar{dNode6vac0wad1ypuxawgPartialxakarxasertialvaetwad0xawbPaxakaaxasaavaesvaF{dNode6vac0wad1yppxawcPFIxakaFxasbFIvaetval{dNode6vac0wad1ypDxawnPlayFramework2xakalxasmlayFramework2vaetwad1ypaxawaPxakaPxasaPvaetvaア{dNode6vac<vaド{dNode6vac0wad3ypT_]xawjアドベントカレンダーxakaドxasiドベントカレンダーvaetvaン{dNode6vac2vaラ{dNode6vac0wad1ypTxawgアンラーニングxakaラxaseラーニングvaetvaデ{dNode6vac0wad1ypSxawfアンデルセンxakaデxasdデルセンvaetwad0xawbアンxakaンxasaンvaesvaッ{dNode6vac1vaデ{dNode6vac0wad4ypSuqqxawfアップデートxakaデxascデートvaetwad1ypXxawcアップxakaッxasbップvaetvaー{dNode6vac2vaテ{dNode6vac0wad1ypZxawfアーティストxakaテxasdティストvaetvaキ{dNode6vac0wad1yp|xawgアーキテクチャxakaキxaseキテクチャvaetwad0xawbアーxakaーxasaーvaesvaフ{dNode6vac0wad2ypkTxawfアフィリンクxakaフxaseフィリンクvaetvaプ{dNode6vac1vaケ{dNode6vac0wad1ypCxawhアプリケーションxakaケxaseケーションvaetwad2yprDxawcアプリxakaプxasbプリvaetvaナ{dNode6vac2vaウ{dNode6vac0wad2ypfJxaweアナウンスxakaウxascウンスvaetvaラ{dNode6vac0wad1ypAxaweアナライザxakaラxascライザvaetwad0xawbアナxakaナxasaナvaesvaメ{dNode6vac0wad1yprxawdアメリカxakaメxascメリカvaetvaク{dNode6vac0wad2ypFGxawfアクセスログxakaクxaseクセスログvaetvaジ{dNode6vac1vaデ{dNode6vac0wad1yp\xawmアジャイルデータサイエンスxakaデxashデータサイエンスvaetwad1ypZxaweアジャイルxakaジxasdジャイルvaetvaカ{dNode6vac2vaウ{dNode6vac0wad1yp_xawgアカウント作っxakaウxaseウント作っvaetvaデ{dNode6vac0wad1yp\xawhアカデミーヒルズxakaデxasfデミーヒルズvaetwad0xawbアカxakaカxasaカvaesvaル{dNode6vac0wad1ypMxawgアルファベットxakaルxasfルファベットvaet>wad0xawaアxakaアxasaアvaesva/{dNode6vac0wad<ypT_ffssJJpppppptyyzWZ\^abimoqstv~@NShovOY[[\\efnnwwJLLLLN\\\\\]]_htyILOR>xawa/xaka/xasa/vaetvaエ{dNode6vac2vaン{dNode6vac2vaト{dNode6vac1vaー{dNode6vac0wad3ypT_nxaweエントリーxakaーxasaーvaetwad3ypS}ixawdエントリxakaトxasbトリvaetvaジ{dNode6vac2vaン{dNode6vac0wad4ypV\Xnxawdエンジンxakaンxasaンvaetvaニ{dNode6vac2vaサ{dNode6vac0wad1ypexawiエンジニアサポートxakaサxasdサポートvaetvaブ{dNode6vac0wad1yp~xawhエンジニアブログxakaブxascブログvaetwad1yp]xaweエンジニアxakaニxasbニアvaetwad0xawcエンジxakaジxasaジvaeswad0xawbエンxakaンxasaンvaesvaラ{dNode6vac0wad1ypKxawcエラーxakaラxasbラーvaetwad0xawaエxakaエxasaエvaesva渋{dNode6vac2va川{dNode6vac0wad1ypTxawb渋川xaka川xasa川vaetva谷{dNode6vac0wad1ypjxawb渋谷xaka谷xasa谷vaetwad0xawa渋xaka渋xasa渋vaesvaさ{dNode6vac7vaん{dNode6vac1vaよ{dNode6vac0wad1ypUxawdさんよりxakaよxasbよりvaetwad<ypT_isygnxAHMYjpHJPQSorMWYbk@FR>xawbさんxakaんxasaんvaetvaい{dNode6vac0wad7yp^R[C^izxawbさいxakaいxasaいvaetvaせ{dNode6vac0wad1ypXxawbさせxakaせxasaせvaetvaて{dNode6vac0wad3yp^xawbさてxakaてxasaてvaetvaっ{dNode6vac0wad1ypnxawdさっそくxakaっxascっそくvaetvaら{dNode6vac0wad3ypFTuxawbさらxakaらxasaらvaetvaす{dNode6vac0wad2ypjDxawcさすがxakaすxasbすがvaetwad<ypWXamsu}}@Egq{@BGKKKZjptKSSWbfinossvzTY[\efilnotwIJLYvwyz|AFIMN>xawaさxakaさxasaさvaetva失{dNode6vac0wad2ypTMxawb失敗xaka失xasb失敗vaetva話{dNode6vac3vaも{dNode6vac1vaし{dNode6vac0wad1yp{xawd話もしてxakaしxasbしてvaetwad1ypZxawb話もxakaもxasaもvaetvaし{dNode6vac1vaま{dNode6vac0wad1ypFxawd話しましxakaまxasbましvaetwad4yp]XYdxawb話しxakaしxasaしvaetva題{dNode6vac0wad2ypAKxawb話題xaka題xasa題vaetwad<ypTT_WX_brrg@[{}JXlprst}}FGXZ]fpqqM>xawa話xaka話xasa話vaetva私{dNode6vac2va自{dNode6vac0wad1ypTxawc私自身xaka自xasb自身vaetva以{dNode6vac0wad1ypGxawc私以外xaka以xasb以外vaetwad:ypTcrWzFrz|Gxawa私xaka私xasa私vaetva「{dNode6vac1va【{dNode6vac0wad1yp@xawb「【xaka【xasa【vaetwad<ypUWZXahptwxz_rPw@FNPYZ\ejsZbdefgjmu{}BIUgp{}JK>xawa「xaka「xasa「vaetva機{dNode6vac4va械{dNode6vac0wad2ypU@xawd機械学習xaka械xasc械学習vaetva能{dNode6vac0wad5ypXagzuxawb機能xaka能xasa能vaetva器{dNode6vac0wad1ypkxawb機器xaka器xasa器vaetva会{dNode6vac0wad1ypwxawb機会xaka会xasa会vaetwad0xawa機xaka機xasa機vaesvaラ{dNode6vac2vaン{dNode6vac0wad1ypUxaweランキングxakaンxasdンキングvaetvaイ{dNode6vac1vaー{dNode6vac0wad1ypFxawfライブラリーxakaーxasaーvaetwad1ypoxaweライブラリxakaイxasdイブラリvaetwad0xawaラxakaラxasaラvaesva改{dNode6vac5va善{dNode6vac0wad1ypUxawb改善xaka善xasa善vaetva訂{dNode6vac2va新{dNode6vac0wad1ypmxawd改訂新版xaka新xasb新版vaetva版{dNode6vac0wad1ypwxawc改訂版xaka版xasa版vaetwad0xawb改訂xaka訂xasa訂vaesvaめ{dNode6vac0wad1ypwxawc改めてxakaめxasbめてvaetva良{dNode6vac0wad2yp||xawb改良xaka良xasa良vaetva変{dNode6vac0wad1ypixawb改変xaka変xasa変vaetwad0xawa改xaka改xasa改vaesvaガ{dNode6vac0wad1ypUxawcガイドxakaガxascガイドvaetva」{dNode6vac1vaっ{dNode6vac0wad1ypbxawc」ってxakaっxasbってvaetwad<ypUWZXahptwxzrPw@@FP\ejdefgjmu{IUgp{}JK>xawa」xaka」xasa」vaetva読{dNode6vac5vaみ{dNode6vac2vaま{dNode6vac0wad4ypUZggxawd読みましxakaまxasbましvaetvaし{dNode6vac0wad1ypKxawd読みしてxakaしxasbしてvaetwad<ypUh||AABBFFNNQQSSUUWYa|U}>xawb読みxakaみxasaみvaetvaん{dNode6vac0wad<ypYY^^WY[[pRU|BglF>xawb読んxakaんxasaんvaetva書{dNode6vac0wad1yp[xawb読書xaka書xasa書vaetvaま{dNode6vac0wad1yp~xawc読まれxakaまxasbまれvaetvaめ{dNode6vac2vaま{dNode6vac0wad1ypFxawd読めましxakaまxasbましvaetvaる{dNode6vac0wad1ypgxawc読めるxakaるxasaるvaetwad0xawb読めxakaめxasaめvaeswad1ypWxawa読xaka読xasa読vaetva著{dNode6vac0wad1ypUxawb著者xaka著xasb著者vaetva鈴{dNode6vac0wad1ypUxawb鈴木xaka鈴xasb鈴木vaetva献{dNode6vac0wad1ypUxawb献本xaka献xasb献本vaetvaだ{dNode6vac9vaい{dNode6vac2vaぶ{dNode6vac0wad2ypP^xawcだいぶxakaぶxasaぶvaetvaて{dNode6vac0wad1yp\xawcだいてxakaてxasaてvaetwad<ypUNOU`jnpxHMkC>xawbだいxakaいxasaいvaetvaっ{dNode6vac0wad<ypWVp\itIRbCIcnAx>xawbだっxakaっxasaっvaetvaけ{dNode6vac3vaど{dNode6vac0wad3yps_Bxawcだけどxakaどxasaどvaetvaる{dNode6vac0wad1ypPxawcだけるxakaるxasaるvaetvaれ{dNode6vac0wad1yp[xawcだけれxakaれxasaれvaetwad6ypTWZFt|xawbだけxakaけxasaけvaetvaき{dNode6vac1vaま{dNode6vac0wad1ypXxawdだきましxakaまxasbましvaetwad1ypwxawbだきxakaきxasaきvaetvaく{dNode6vac0wad1yp[xawbだくxakaくxasaくvaetvaろ{dNode6vac0wad2ypsIxawcだろうxakaろxasbろうvaetvaか{dNode6vac1vaん{dNode6vac0wad1yp{xawcだかんxakaんxasaんvaetwad1ypdxawbだかxakaかxasaかvaetvaり{dNode6vac0wad1ypUxawbだりxakaりxasaりvaetvaら{dNode6vac0wad1ypBxawbだらxakaらxasaらvaetwad<ypYYY^^^sRTUWaM[^MPdjC^ilsz{HM>xawaだxakaだxasaだvaetva終{dNode6vac3vaわ{dNode6vac2vaっ{dNode6vac0wad2ypUIxawc終わっxakaっxasaっvaetvaり{dNode6vac2vaで{dNode6vac0wad1ypYxawe終わりまでxakaでxasaでvaetvaし{dNode6vac0wad1ypaxawe終わりましxakaしxasaしvaetwad0xawd終わりまxakaりxasbりまvaeswad0xawb終わxakaわxasaわvaesva了{dNode6vac0wad2ypYrxawb終了xaka了xasa了vaetvaえ{dNode6vac0wad1ypYxawb終えxakaえxasaえvaetwad0xawa終xaka終xasa終vaesvaレ{dNode6vac2vaビ{dNode6vac0wad1ypUxawdレビューxakaビxascビューvaetvaイ{dNode6vac0wad1ypSxawiレイアウトファイルxakaイxashイアウトファイルvaetwad0xawaレxakaレxasaレvaesva紹{dNode6vac0wad<ypUQWv`zzAKKJ^acnVu>xawb紹介xaka紹xasb紹介vaetva趣{dNode6vac0wad4ypVV\\xawb趣味xaka趣xasb趣味vaetva関{dNode6vac5vaす{dNode6vac0wad9ypV\P^O}FKNxawc関するxakaすxasbするvaetva連{dNode6vac0wad4yp@BCxawb関連xaka連xasa連vaetvaし{dNode6vac0wad2ypG[xawb関しxakaしxasaしvaetva西{dNode6vac0wad1ypcxawb関西xaka西xasa西vaetva係{dNode6vac0wad2ypvYxawb関係xaka係xasa係vaetwad1ypPxawa関xaka関xasa関vaetvaプ{dNode6vac3vaロ{dNode6vac4vaジ{dNode6vac1vaペ{dNode6vac0wad4ypEcnxawiプロジェクトページxakaペxascページvaetwad6ypV\\VlRxawfプロジェクトxakaジxasdジェクトvaetvaグ{dNode6vac2vaム{dNode6vac0wad4ypV\\Yxaweプログラムxakaムxasaムvaetvaミ{dNode6vac0wad1yp_xawgプログラミングxakaミxascミングvaetwad0xawdプログラxakaグxasbグラvaesvaダ{dNode6vac1vaシ{dNode6vac0wad1ypZxawiプロダクトシリーズxakaシxasdシリーズvaetwad2ypHnxaweプロダクトxakaダxascダクトvaetvaフ{dNode6vac0wad1ypUxawnプロフェッショナルプログラマxakaフxaslフェッショナルプログラマvaetwad0xawbプロxakaロxasaロvaesvaラ{dNode6vac2vaグ{dNode6vac0wad<ypTUVV{AALBKQtux}>xaweプラグインxakaグxascグインvaetvaッ{dNode6vac0wad1ypgxawfプラットフォxakaッxasdットフォvaetwad0xawbプラxakaラxasaラvaesvaレ{dNode6vac2vaス{dNode6vac0wad1ypFxawgプレスリリースxakaスxaseスリリースvaetvaイ{dNode6vac0wad1ypIxawfプレイバックxakaイxasdイバックvaetwad1ypmxawbプレxakaレxasaレvaetwad0xawaプxakaプxasaプvaesvaベ{dNode6vac3vaク{dNode6vac0wad1ypVxawdベクトルxakaクxascクトルvaetvaル{dNode6vac2vaリ{dNode6vac0wad3yp}dfxawdベルリンxakaリxasbリンvaetvaサ{dNode6vac0wad1yp]xaweベルサールxakaサxascサールvaetwad0xawbベルxakaルxasaルvaesvaー{dNode6vac0wad<yp\^abimoqzEILZZAA>xawcベースxakaーxasbースvaetwad0xawaベxakaベxasaベvaesva確{dNode6vac1va用{dNode6vac0wad1ypHxawc確認用xaka用xasa用vaetwad3ypV\Xxawb確認xaka確xasb確認vaetva含{dNode6vac2vaめ{dNode6vac0wad1ypVxawb含めxakaめxasaめvaetvaま{dNode6vac1vaれ{dNode6vac0wad1ypJxawd含まれるxakaれxasbれるvaetwad1ypMxawb含まxakaまxasaまvaetwad0xawa含xaka含xasa含vaesvaJ{dNode6vac:vau{dNode6vac2vap{dNode6vac0wad1ypVxawgJupyterxakapxasepytervaetvas{dNode6vac0wad1ypgxawlJustTechTalkxakasxasjstTechTalkvaetwad0xawbJuxakauxasauvaesvaa{dNode6vac3vav{dNode6vac2vaO{dNode6vac0wad1ypLxawgJavaOnexakaOxascOnevaetvaD{dNode6vac0wad1ypQxawgJavaDocxakaDxascDocvaetwad7ypWzEMppRxawdJavaxakavxasbvavaetvap{dNode6vac1vae{dNode6vac0wad1ypNxaw QJapaneseTokenizerxakaexasleseTokenizervaetwad5yppNdZwxaweJapanxakapxascpanvaetvan{dNode6vac0wad1ypgxawfJanomexakanxasdnomevaetwad0xawbJaxakaaxasaavaesvaJ{dNode6vac0wad6ypXz@GCpxawdJJUGxakaJxascJUGvaetvaM{dNode6vac0wad1ypgxawdJMATxakaMxascMATvaetvao{dNode6vac0wad1yplxawdJoinxakaoxascoinvaetvaV{dNode6vac0wad1ypbxawcJVMxakaVxasbVMvaetvaI{dNode6vac0wad1yp^xawdJIRAxakaIxascIRAvaetvae{dNode6vac0wad1ypjxawiJetBrainsxakaexashetBrainsvaetvaP{dNode6vac0wad1ypGxawbJPxakaPxasaPvaetvaD{dNode6vac0wad1ypLxawdJDicxakaDxascDicvaetwad1yp_xawaJxakaJxasaJvaetvaN{dNode6vac3vae{dNode6vac0wad1yp]xawjNetworkingxakaexasietworkingvaetvai{dNode6vac0wad1ypfxaweNightxakaixasdightvaetvaA{dNode6vac0wad1ypLxaweNAISTxakaAxasdAISTvaetwad1ypVxawaNxakaNxasaNvaetva環{dNode6vac0wad7ypWfTQPBJxawb環境xaka環xasb環境vaetvaD{dNode6vac7vae{dNode6vac3vav{dNode6vac0wad3ypWZZxawcDevxakavxasavvaetvas{dNode6vac0wad1ypYxawgDesktopxakasxasesktopvaetval{dNode6vac0wad1yp_xawfDeletexakalxasdletevaetwad0xawbDexakaexasaevaesvao{dNode6vac2vac{dNode6vac0wad1ypYxawfDockerxakacxasdckervaetvam{dNode6vac0wad1yp^xawfDomainxakamxasdmainvaetwad0xawbDoxakaoxasaovaesvaI{dNode6vac0wad4yp_]koxawcDIYxakaIxasbIYvaetvaa{dNode6vac2vat{dNode6vac0wad3ypppyxawdDataxakatxasbtavaetvav{dNode6vac0wad1ypkxaweDavidxakavxascvidvaetwad0xawbDaxakaaxasaavaesvai{dNode6vac0wad1yplxawgDiscussxakaixasfiscussvaetvaS{dNode6vac0wad2ypeExawgDSIRNLPxakaSxasfSIRNLPvaetvar{dNode6vac0wad1ypCxawgDropboxxakarxasfropboxvaetwad0xawaDxakaDxasaDvaesva動{dNode6vac4vaく{dNode6vac0wad1ypWxawb動くxakaくxasaくvaetva向{dNode6vac0wad1ypPxawb動向xaka向xasa向vaetva機{dNode6vac0wad1ypXxawb動機xaka機xasa機vaetva作{dNode6vac0wad1ypIxawb動作xaka作xasa作vaetwad0xawa動xaka動xasa動vaesva変{dNode6vac5vaえ{dNode6vac0wad1ypWxawb変えxakaえxasaえvaetvaわ{dNode6vac1vaて{dNode6vac0wad1ypQxawd変わってxakaてxasaてvaetwad2ypfWxawc変わっxakaわxasbわっvaetva遷{dNode6vac0wad2ypJSxawb変遷xaka遷xasa遷vaetva更{dNode6vac1va点{dNode6vac0wad1ypIxawc変更点xaka点xasa点vaetwad5ypkkS|Nxawb変更xaka更xasa更vaetvaか{dNode6vac0wad1ypCxawb変かxakaかxasaかvaetwad0xawa変xaka変xasa変vaesva最{dNode6vac9va初{dNode6vac0wad4ypWYzzxawb最初xaka初xasa初vaetva近{dNode6vac3va使{dNode6vac0wad1yplxawd最近使っxaka使xasb使っvaetva触{dNode6vac0wad1ypVxawd最近触っxaka触xasb触っvaetva忘{dNode6vac0wad1yplxawc最近忘xaka忘xasa忘vaetwad9yp\PA[WDRTVxawb最近xaka近xasa近vaetva終{dNode6vac2va出{dNode6vac0wad1ypmxawe最終出社日xaka出xasc出社日vaetva日{dNode6vac0wad4ypJS}zxawc最終日xaka日xasa日vaetwad0xawb最終xaka終xasa終vaesva後{dNode6vac0wad6ypvSFrz|xawb最後xaka後xasa後vaetva大{dNode6vac0wad1ypFxawc最大手xaka大xasb大手vaetvaも{dNode6vac0wad1ypdxawb最もxakaもxasaもvaetva新{dNode6vac1va版{dNode6vac0wad5ypEcnQxawc最新版xaka版xasa版vaetwad1ypYxawb最新xaka新xasa新vaetva中{dNode6vac0wad1yp\xawb最中xaka中xasa中vaetva悪{dNode6vac0wad1yp^xawb最悪xaka悪xasa悪vaetwad0xawa最xaka最xasa最vaesva導{dNode6vac0wad2ypWZxawb導入xaka導xasb導入vaetva時{dNode6vac2va間{dNode6vac2va大{dNode6vac0wad1yp^xawe時間大丈夫xaka大xasc大丈夫vaetva管{dNode6vac0wad1ypZxawe時間管理術xaka管xasc管理術vaetwad4ypagl|xawb時間xaka間xasa間vaetva差{dNode6vac0wad1ypVxawb時差xaka差xasa差vaetwad4ypWh@Ixawa時xaka時xasa時vaetva疑{dNode6vac0wad1ypWxawc疑問点xaka疑xasc疑問点vaetvaコ{dNode6vac9vaン{dNode6vac4vaテ{dNode6vac2vaナ{dNode6vac0wad1ypWxawdコンテナxakaナxasaナvaetvaン{dNode6vac0wad1ypgxaweコンテンツxakaンxasbンツvaetwad0xawcコンテxakaテxasaテvaesvaパ{dNode6vac0wad1ypbxaweコンパクトxakaパxascパクトvaetvaピ{dNode6vac0wad1yphxawjコンピュータシステムxakaピxashピュータシステムvaetvaビ{dNode6vac0wad2ypnnxawcコンビxakaビxasaビvaetwad0xawbコンxakaンxasaンvaesvaロ{dNode6vac2vaィ{dNode6vac0wad1ypdxawgコロナウィルスxakaィxascィルスvaetvaイ{dNode6vac0wad1ypuxawgコロナウイルスxakaイxascイルスvaetwad0xawdコロナウxakaロxascロナウvaesvaマ{dNode6vac1vaン{dNode6vac0wad4ypRQSxxawdコマンドxakaンxasbンドvaetwad1ypHxawbコマxakaマxasaマvaetvaー{dNode6vac3vaド{dNode6vac1va・{dNode6vac0wad1ypgxawkコード・シンプリシティxaka・xash・シンプリシティvaetwad1ypOxawcコードxakaドxasaドvaetvaヒ{dNode6vac0wad1ypAxawdコーヒーxakaヒxasbヒーvaetvaデ{dNode6vac0wad2ypDTxawfコーディングxakaデxasdディングvaetwad0xawbコーxakaーxasaーvaesvaピ{dNode6vac0wad2ypjkxawcコピーxakaピxasbピーvaetvaミ{dNode6vac2vaッ{dNode6vac2vaタ{dNode6vac0wad3ypXoRxaweコミッターxakaタxasbターvaetvaト{dNode6vac0wad1ypoxawdコミットxakaトxasaトvaetwad0xawcコミッxakaッxasaッvaesvaュ{dNode6vac0wad1yplxawiコミュニティサポーxakaュxasgュニティサポーvaetwad0xawbコミxakaミxasaミvaesvaト{dNode6vac0wad1ypOxawbコトxakaトxasaトvaetvaリ{dNode6vac0wad1ypPxawbコリxakaリxasaリvaetvaメ{dNode6vac1vaン{dNode6vac0wad1ypGxawdコメントxakaンxasbントvaetwad1yp`xawbコメxakaメxasaメvaetwad0xawaコxakaコxasaコvaesva名{dNode6vac1va古{dNode6vac0wad2yppwxawc名古屋xaka古xasb古屋vaetwad4ypWNNJxawa名xaka名xasa名vaetva解{dNode6vac0wad1ypWxawb解消xaka解xasb解消vaetvaメ{dNode6vac3vaモ{dNode6vac0wad<ypWS^hv|ABFNQSU[pX{OR]amx{|~HK\h{S>xawbメモxakaモxasaモvaetvaイ{dNode6vac0wad1ypjxawfメインマシンxakaイxaseインマシンvaetvaニ{dNode6vac0wad2ypacxawdメニューxakaニxascニューvaetwad0xawaメxakaメxasaメvaesva生{dNode6vac2va成{dNode6vac0wad2ypXgxawb生成xaka成xasa成vaetva活{dNode6vac0wad1ypxxawb生活xaka活xasa活vaetwad0xawa生xaka生xasa生vaesvaH{dNode6vac5vau{dNode6vac0wad2ypXSxawdHugoxakauxascugovaetvaa{dNode6vac2vat{dNode6vac0wad1yphxawfHatenaxakatxasdtenavaetvad{dNode6vac1vao{dNode6vac0wad9ypHddyy]hwJxawfHadoopxakaoxascoopvaetwad1yppxawcHadxakadxasadvaetwad0xawbHaxakaaxasaavaesvai{dNode6vac1vav{dNode6vac0wad1ypHxawdHivexakavxasbvevaetwad1yp]xawbHixakaixasaivaetvae{dNode6vac0wad2yp_GxawfHerokuxakaexaseerokuvaetvaB{dNode6vac0wad1ypyxawhHBaseConxakaBxasgBaseConvaetwad0xawaHxakaHxasaHvaesva利{dNode6vac0wad<ypXYYCL^FGA^OLOOPQ>xawb利用xaka利xasb利用vaetva当{dNode6vac2va時{dNode6vac0wad1ypXxawb当時xaka時xasa時vaetva選{dNode6vac0wad1yphxawb当選xaka選xasa選vaetwad0xawa当xaka当xasa当vaesvab{dNode6vac7var{dNode6vac0wad1ypXxawdbrewxakarxascrewvaetvao{dNode6vac0wad<yp||||AAAABBBBFFFFNNNQQSWW>xawdbookxakaoxascookvaetvaa{dNode6vac0wad1ypkxawdbashxakaaxascashvaetvai{dNode6vac0wad1ypyxawcbitxakaixasbitvaetvae{dNode6vac2vat{dNode6vac0wad8ypV\^_eeCLxawdbetaxakatxasbtavaetvah{dNode6vac0wad1ypvxawfbehindxakahxasdhindvaetwad0xawbbexakaexasaevaesvay{dNode6vac0wad1yp_xawbbyxakayxasayvaetvau{dNode6vac0wad1yp@xawdbulkxakauxasculkvaetwad0xawabxakabxasabvaesvaイ{dNode6vac3vaン{dNode6vac6vaス{dNode6vac1vaー{dNode6vac1vaル{dNode6vac1vaガ{dNode6vac0wad1ypRxawiインストールガイドxakaガxascガイドvaetwad9ypXpJuxxsBCxawfインストールxakaルxasaルvaetwad2ypB~xaweインストーxakaーxasaーvaetwad1ypQxawdインストxakaスxasbストvaetvaデ{dNode6vac2vaッ{dNode6vac1vaク{dNode6vac0wad3ypXkAxawfインデックスxakaクxasbクスvaetwad1ypAxawdインデッxakaッxasaッvaetvaキ{dNode6vac0wad1ypOxawgインデキシングxakaキxasdキシングvaetwad1yp\xawcインデxakaデxasaデvaetvaチ{dNode6vac0wad1yplxawcインチxakaチxasaチvaetvaポ{dNode6vac0wad1ypFxaweインポートxakaポxascポートvaetvaフ{dNode6vac2vaラ{dNode6vac2va養{dNode6vac0wad1ypNxawmインフラエンジニア養成読本xaka養xasd養成読本vaetva技{dNode6vac0wad1ypYxawmインフラエンジニア技術勉強xaka技xasd技術勉強vaetwad0xawiインフラエンジニアxakaラxasfラエンジニアvaesvaル{dNode6vac0wad1yp^xawgインフルエンザxakaルxasdルエンザvaetwad0xawcインフxakaフxasaフvaesvaタ{dNode6vac0wad1ypoxawgインタフェースxakaタxaseタフェースvaetwad0xawbインxakaンxasaンvaesvaベ{dNode6vac1vaル{dNode6vac0wad1ypJxawfイベントルーxakaルxasbルーvaetwad8ypDDabdfokxawdイベントxakaベxascベントvaetvaケ{dNode6vac0wad2ypijxawdイケメンxakaケxascケメンvaetwad2ypjyxawaイxakaイxasaイvaetvaW{dNode6vac5vaS{dNode6vac1va2{dNode6vac0wad1ypYxawdWSL2xaka2xasa2vaetwad1ypYxawcWSLxakaSxasbSLvaetvai{dNode6vac3van{dNode6vac2vad{dNode6vac0wad2yp[pxawgWindowsxakadxasddowsvaetvat{dNode6vac0wad1ypdxawfWinterxakatxasctervaetwad0xawcWinxakanxasanvaesvat{dNode6vac0wad1ypkxawdWithxakatxasbthvaetvak{dNode6vac1vap{dNode6vac0wad1ypAxawiWikipediaxakapxasepediavaetwad1ypvxawdWikixakakxasbkivaetwad0xawbWixakaixasaivaesvao{dNode6vac3var{dNode6vac2vak{dNode6vac0wad3ypEJKxawiWorkplacexakakxasfkplacevaetval{dNode6vac0wad1ypzxaweWorldxakalxasbldvaetwad0xawcWorxakarxasarvaesvau{dNode6vac0wad1yp]xaweWouldxakauxasculdvaetvao{dNode6vac0wad1ypfxaweWoogaxakaoxascogavaetwad0xawbWoxakaoxasaovaesvaa{dNode6vac2vat{dNode6vac0wad2ypWWxawgWatcherxakatxasetchervaetvan{dNode6vac0wad1ypjxawhWantedlyxakanxasfntedlyvaetwad0xawbWaxakaaxasaavaesvae{dNode6vac2vaS{dNode6vac0wad2ypGGxawgWebSolrxakaSxasdSolrvaetvaM{dNode6vac0wad1ypexawiWebMiningxakaMxasfMiningvaetwad0xawcWebxakaexasbebvaeswad0xawaWxakaWxasaWvaesvaU{dNode6vac5vab{dNode6vac0wad1ypYxawfUbuntuxakabxasebuntuvaetvaS{dNode6vac0wad1ypjxawcUSBxakaSxasbSBvaetvan{dNode6vac2vax{dNode6vac0wad1ypHxawdUnixxakaxxasaxvaetvaD{dNode6vac0wad2ypzzxawfUniDicxakaDxascDicvaetwad0xawcUnixakanxasbnivaesvaI{dNode6vac0wad1ypAxawbUIxakaIxasaIvaetvaR{dNode6vac0wad1ypuxawcURLxakaRxasbRLvaetwad0xawaUxakaUxasaUvaesva入{dNode6vac7vaれ{dNode6vac1vaる{dNode6vac0wad2yph{xawc入れるxakaるxasaるvaetwad4ypYPisxawb入れxakaれxasaれvaetva門{dNode6vac1va出{dNode6vac0wad1ypmxawf入門出版記念xaka出xasd出版記念vaetwad<ypYY[aawwZZ_HI>xawb入門xaka門xasa門vaetvaっ{dNode6vac0wad2yp^Txawb入っxakaっxasaっvaetva力{dNode6vac0wad1yp~xawe入力文字列xaka力xasd力文字列vaetvaり{dNode6vac1va浸{dNode6vac0wad1ypAxawd入り浸っxaka浸xasb浸っvaetwad2ypjkxawb入りxakaりxasaりvaetva手{dNode6vac0wad1ypgxawb入手xaka手xasa手vaetvaる{dNode6vac0wad1ypJxawb入るxakaるxasaるvaetwad2yp@uxawa入xaka入xasa入vaetva開{dNode6vac5va発{dNode6vac3va中{dNode6vac0wad2yp|Mxawc開発中xaka中xasa中vaetva者{dNode6vac0wad1yp\xawc開発者xaka者xasa者vaetva方{dNode6vac0wad1ypJxawe開発方法論xaka方xasc方法論vaetwad7ypYsZlKxsxawb開発xaka発xasa発vaetva催{dNode6vac0wad<yp]V_`d}}yNOQU`cjnptwx@HMT`fmybeflQW>xawb開催xaka催xasa催vaetva始{dNode6vac0wad1yptxawb開始xaka始xasa始vaetva場{dNode6vac0wad5ypjnxHMxawd開場提供xaka場xasc場提供vaetvaい{dNode6vac0wad1yp^xawb開いxakaいxasaいvaetwad0xawa開xaka開xasa開vaesvaか{dNode6vac9vaら{dNode6vac4vaか{dNode6vac0wad1ypMxawcからかxakaかxasaかvaetvaお{dNode6vac0wad1ypgxawcからおxakaおxasaおvaetvaっ{dNode6vac0wad1ypHxawcからっxakaっxasaっvaetvaい{dNode6vac0wad1ypBxawfからいくつかxakaいxasdいくつかvaetwad<yp^SUZ^`bhilr{{GP_fhlnuxy{CIRrt|CPS]^``acnprrtuvzEQTXcghpsty}BCIQSikqs@EFHQ>xawbからxakaらxasaらvaetvaけ{dNode6vac2vaて{dNode6vac0wad1ypgxawcかけてxakaてxasaてvaetvaず{dNode6vac0wad1ypgxawcかけずxakaずxasaずvaetwad2ypZuxawbかけxakaけxasaけvaetvaか{dNode6vac0wad1ypgxawcかかるxakaかxasbかるvaetvaな{dNode6vac2vaく{dNode6vac0wad1yprxawcかなくxakaくxasaくvaetvaり{dNode6vac0wad1ypExawcかなりxakaりxasaりvaetwad0xawbかなxakaなxasaなvaesvaど{dNode6vac0wad1ypxawdかどうかxakaどxascどうかvaetvaっ{dNode6vac0wad4ypT]b|xawbかっxakaっxasaっvaetvaや{dNode6vac0wad1ypbxawcかやっxakaやxasbやっvaetvaち{dNode6vac0wad1ypkxawdかちゃんxakaちxascちゃんvaetvaも{dNode6vac0wad1yprxawbかもxakaもxasaもvaetwad<ypY^ThiT\`a{BHHMVW\]bDLMZp{~~alp|S>xawaかxakaかxasaかvaetvaバ{dNode6vac4vaッ{dNode6vac2vaエ{dNode6vac0wad1ypYxawjバックエンドエンジンxakaエxasgエンドエンジンvaetvaア{dNode6vac0wad1yp^xawfバックアップxakaアxascアップvaetwad0xawcバックxakaッxasbックvaesvaグ{dNode6vac1vaフ{dNode6vac0wad1ypRxawgバグフィックスxakaフxaseフィックスvaetwad1ypHxawbバグxakaグxasaグvaetvaー{dNode6vac2vaジ{dNode6vac0wad1ypWxaweバージョンxakaジxascジョンvaetvaコ{dNode6vac0wad1ypFxaweバーコードxakaコxascコードvaetwad0xawbバーxakaーxasaーvaesvaイ{dNode6vac0wad1ypoxawdバイナリxakaイxascイナリvaetwad2yp[Pxawaバxakaバxasaバvaetva前{dNode6vac5va回{dNode6vac2va読{dNode6vac0wad1ypYxawd前回読んxaka読xasb読んvaetva購{dNode6vac0wad1ypDxawd前回購入xaka購xasb購入vaetwad<ypZ[Qfopwx|ABFGHIJNOQSU]yFFS~MMWbBM>xawb前回xaka回xasa回vaetva々{dNode6vac1va紹{dNode6vac0wad1ypAxawe前々回紹介xaka紹xasb紹介vaetwad2ypf@xawc前々回xaka々xasb々回vaetvaま{dNode6vac0wad1ypxxawc前までxakaまxasbまでvaetvaな{dNode6vac0wad1ypwxawc前なんxakaなxasbなんvaetvaく{dNode6vac0wad1ypSxawd前くらいxakaくxascくらいvaetwad7ypOWmW]Ncxawa前xaka前xasa前vaetvaV{dNode6vac6vaS{dNode6vac0wad1ypZxawbVSxakaSxasaSvaetvae{dNode6vac0wad1yp^xawhVerticalxakaexasgerticalvaetvai{dNode6vac0wad1ypVxawfVisualxakaixaseisualvaetvaa{dNode6vac0wad1yplxawgVagrantxakaaxasfagrantvaetvaM{dNode6vac0wad1yplxawbVMxakaMxasaMvaetvao{dNode6vac0wad3ypO[\xawdVotexakaoxascotevaetwad0xawaVxakaVxasaVvaesva＋{dNode6vac0wad7ypZPXbbN]xawa＋xaka＋xasa＋vaetva残{dNode6vac5va課{dNode6vac0wad1ypZxawc残課題xaka課xasb課題vaetvaし{dNode6vac0wad<ypS^gv\owEMOmzHvG>xawb残しxakaしxasaしvaetvaり{dNode6vac0wad2ypG{xawb残りxakaりxasaりvaetva念{dNode6vac0wad2ypbGxawb残念xaka念xasa念vaetvaす{dNode6vac0wad1ypSxawb残すxakaすxasaすvaetwad0xawa残xaka残xasa残vaesvaマ{dNode6vac5vaル{dNode6vac2vaン{dNode6vac0wad1ypZxawhマルチコンテナ化xakaンxasdンテナ化vaetvaア{dNode6vac0wad1ypOxaweマルチコアxakaアxasaアvaetwad0xawdマルチコxakaルxascルチコvaesvaー{dNode6vac0wad1ypsxawcマージxakaーxasbージvaetvaニ{dNode6vac0wad1yp~xaweマニアックxakaニxasdニアックvaetvaシ{dNode6vac0wad1yp]xawcマシンxakaシxasbシンvaetvaッ{dNode6vac0wad1ypkxaweマッピングxakaッxasdッピングvaetwad0xawaマxakaマxasaマvaesvap{dNode6vac7var{dNode6vac2vae{dNode6vac0wad1yp[xawcprexakaexasaevaetvao{dNode6vac0wad1ypkxawgprofilexakaoxaseofilevaetwad0xawbprxakarxasarvaesvay{dNode6vac2vas{dNode6vac0wad3yp]nnxawepyspaxakasxascspavaetvaf{dNode6vac0wad2ypBtxawepyfesxakafxascfesvaetwad0xawbpyxakayxasayvaesvau{dNode6vac2vab{dNode6vac0wad1ypIxawcpubxakabxasabvaetvap{dNode6vac0wad1yplxawipuppet使ってxakapxasgppet使ってvaetwad0xawbpuxakauxasauvaesvai{dNode6vac0wad1ypRxawgpicoclixakaixasficoclivaetval{dNode6vac2vau{dNode6vac0wad4yp_BQxxawfpluginxakauxasduginvaetvae{dNode6vac0wad1yp]xawfpleasexakaexasdeasevaetwad0xawbplxakalxasalvaesvae{dNode6vac0wad1ypOxawkperformancexakaexasjerformancevaetvaa{dNode6vac0wad1ypgxawjpaperwhitexakaaxasiaperwhitevaetwad0xawapxakapxasapvaesva-{dNode6vac1va&{dNode6vac0wad1ypIxawb-&xaka&xasa&vaetwad<yp[Y^||||~AAAABBBBFFFFNNNQQRSZ\pp}}@VV\]^_IKK^acdo||@KYwwzAELNNOOXX]_`cnqAAHLLLLMNOP>xawa-xaka-xasa-vaetvac{dNode6vac4vao{dNode6vac3vam{dNode6vac3vam{dNode6vac0wad1yp[xawfcommitxakamxascmitvaetvai{dNode6vac0wad1ypexawfcomingxakaixascingvaetvap{dNode6vac0wad1ypKxawlcompositePOSxakapxasipositePOSvaetwad2ypprxawccomxakamxasamvaetvan{dNode6vac3van{dNode6vac0wad1yppxawhconnpassxakanxasenpassvaetvas{dNode6vac0wad1ypOxawnconsiderationsxakasxasksiderationsvaetvat{dNode6vac0wad1ypFxawjcontributexakatxasgtributevaetwad0xawcconxakanxasanvaesvac{dNode6vac0wad1ypSxawicocoatomoxakacxasgcoatomovaetwad0xawbcoxakaoxasaovaesvai{dNode6vac0wad1ypIxawfcipherxakaixaseiphervaetvah{dNode6vac2van{dNode6vac0wad2yp]Bxawgchangesxakanxasdngesvaetvas{dNode6vac0wad1ypMxawfchasenxakasxascsenvaetwad0xawcchaxakahxasbhavaesvau{dNode6vac0wad1yppxawgcuratorxakauxasfuratorvaetwad0xawacxakacxasacvaesva組{dNode6vac2vaみ{dNode6vac0wad2yp[kxawb組みxakaみxasaみvaetvaん{dNode6vac0wad1yplxawb組んxakaんxasaんvaetwad0xawa組xaka組xasa組vaesva合{dNode6vac4vaわ{dNode6vac1vaせ{dNode6vac1vaて{dNode6vac0wad1yp[xawd合わせてxakaてxasaてvaetwad1yp[xawc合わせxakaせxasaせvaetwad1ypxxawb合わxakaわxasaわvaetvaい{dNode6vac0wad2ypW[xawb合いxakaいxasaいvaetva間{dNode6vac0wad1yp|xawb合間xaka間xasa間vaetvaっ{dNode6vac0wad1ypgxawb合っxakaっxasaっvaetwad0xawa合xaka合xasa合vaesva困{dNode6vac0wad2yp[`xawb困っxaka困xasb困っvaetva知{dNode6vac5vaり{dNode6vac2va合{dNode6vac0wad3yp[Ybxawd知り合いxaka合xasb合いvaetvaつ{dNode6vac0wad1ypGxawd知りつつxakaつxasbつつvaetwad3ypW[gxawb知りxakaりxasaりvaetvaら{dNode6vac1vaせ{dNode6vac0wad4ypyyIIxawc知らせxakaせxasaせvaetwad1yprxawb知らxakaらxasaらvaetvaれ{dNode6vac0wad2yp{~xawb知れxakaれxasaれvaetvaる{dNode6vac0wad1yp{xawb知るxakaるxasaるvaetva人{dNode6vac0wad1yp`xawb知人xaka人xasa人vaetwad0xawa知xaka知xasa知vaesvaチ{dNode6vac3vaャ{dNode6vac0wad1yp[xawdチャットxakaャxascャットvaetvaー{dNode6vac0wad1ypfxawcチームxakaーxasbームvaetvaケ{dNode6vac0wad6ypKKLLLtxawdチケットxakaケxascケットvaetwad0xawaチxakaチxasaチvaesva始{dNode6vac2vaめ{dNode6vac1vaま{dNode6vac0wad3yp\W}xawd始めましxakaまxasbましvaetwad<yph|ABFNQSUa@lRSa}R>xawb始めxakaめxasaめvaetvaま{dNode6vac3vaる{dNode6vac0wad1yp_xawc始まるxakaるxasaるvaetvaり{dNode6vac1vaま{dNode6vac0wad1ypDxawe始まりましxakaまxasbましvaetwad1ypFxawc始まりxakaりxasaりvaetvaっ{dNode6vac0wad1ypOxawc始まっxakaっxasaっvaetwad0xawb始まxakaまxasaまvaeswad0xawa始xaka始xasa始vaesvaき{dNode6vac4vaち{dNode6vac0wad1yp\xawcきちんxakaちxasbちんvaetvaま{dNode6vac0wad<yp]pcghh{@Xz{QWjkmppstCLQYbdepw>xawcきましxakaまxasbましvaetvaて{dNode6vac0wad5ypq^KPVxawbきてxakaてxasaてvaetvaっ{dNode6vac0wad1ypZxawdきっかけxakaっxascっかけvaetwad8ypq{l}ULzUxawaきxakaきxasaきvaetva季{dNode6vac0wad4yp]]Dixawb季節xaka季xasb季節vaetvaや{dNode6vac6vaっ{dNode6vac1vaぱ{dNode6vac0wad1ypbxawgやっぱりいいよxakaぱxaseぱりいいよvaetwad:yp]l{sss\eRSxawbやっxakaっxasaっvaetvaり{dNode6vac1vaま{dNode6vac0wad1ypwxawdやりましxakaまxasbましvaetwad2yp{Uxawbやりxakaりxasaりvaetvaる{dNode6vac0wad2ypyvxawbやるxakaるxasaるvaetvaら{dNode6vac0wad1ypSxawbやらxakaらxasaらvaetvaけ{dNode6vac0wad1yp@xawbやけxakaけxasaけvaetvaい{dNode6vac0wad1ypaxawbやいxakaいxasaいvaetwad<ypSegi`sggG[qrClpBF>xawaやxakaやxasaやvaetvaB{dNode6vac6vae{dNode6vac2var{dNode6vac0wad8yp]V_`}}ggxawfBerlinxakarxasdrlinvaetvat{dNode6vac0wad3ypBCKxawdBetaxakatxasbtavaetwad0xawbBexakaexasaevaesvau{dNode6vac3vaz{dNode6vac0wad6yp]V_`}}xawiBuzzwordsxakazxasgzzwordsvaetvai{dNode6vac0wad1ypDxaweBuildxakaixascildvaetval{dNode6vac0wad1yp_xawdBulkxakalxasblkvaetwad0xawbBuxakauxasauvaesvai{dNode6vac3vao{dNode6vac0wad1yp^xawjBiomedicalxakaoxashomedicalvaetvag{dNode6vac0wad1yp}xawcBigxakagxasagvaetvar{dNode6vac0wad1yptxawdBirdxakarxasbrdvaetwad0xawbBixakaixasaivaesvao{dNode6vac2vao{dNode6vac1vas{dNode6vac1vac{dNode6vac0wad1ypmxawhBookscanxakacxasccanvaetwad1ypvxaweBooksxakasxasasvaetwad9yp|ABFNQSUCxawdBookxakaoxasbokvaetvan{dNode6vac0wad1yppxawgBonfirexakanxasenfirevaetwad0xawbBoxakaoxasaovaesvaR{dNode6vac0wad1yp\xawfBRAVIAxakaRxaseRAVIAvaetvaa{dNode6vac0wad2ypJNxaweBashoxakaaxasdashovaetwad0xawaBxakaBxasaBvaesvaオ{dNode6vac6vaン{dNode6vac0wad5yp]]V`}xaweオンラインxakaンxasdンラインvaetvaー{dNode6vac2vaト{dNode6vac0wad3ypPQRxawiオートコンプリートxakaトxasgトコンプリートvaetvaプ{dNode6vac0wad1yppxawhオープンセミナーxakaプxasfプンセミナーvaetwad0xawbオーxakaーxasaーvaesvaッ{dNode6vac0wad1ypZxawbオッxakaッxasaッvaetvaフ{dNode6vac2vaラ{dNode6vac0wad1ypdxaweオフラインxakaラxascラインvaetvaィ{dNode6vac0wad2ypAAxawdオフィスxakaィxasbィスvaetwad0xawbオフxakaフxasaフvaesvaラ{dNode6vac1va・{dNode6vac0wad1yphxawjオライリー・ジャパンxaka・xase・ジャパンvaetwad1yphxaweオライリーxakaラxasdライリーvaetvaシ{dNode6vac0wad1yphxawdオシャレxakaシxascシャレvaetwad0xawaオxakaオxasaオvaesva出{dNode6vac;va張{dNode6vac1va中{dNode6vac0wad1yprxawc出張中xaka中xasa中vaetwad6yp]V`}xCxawb出張xaka張xasa張vaetva力{dNode6vac0wad3ypGNOxawb出力xaka力xasa力vaetvaま{dNode6vac2vaし{dNode6vac0wad1ypFxawc出ましxakaしxasaしvaetvaす{dNode6vac0wad1ypexawd出ますよxakaすxasbすよvaetwad0xawb出まxakaまxasaまvaesva版{dNode6vac0wad2ypNmxawd出版記念xaka版xasc版記念vaetvaて{dNode6vac0wad3ypUtDxawb出てxakaてxasaてvaetvaし{dNode6vac1vaま{dNode6vac0wad1yptxawd出しましxakaまxasbましvaetwad1ypYxawb出しxakaしxasaしvaetva来{dNode6vac0wad2ypxLxawc出来るxaka来xasb来るvaetva会{dNode6vac0wad1ypSxawc出会っxaka会xasb会っvaetva演{dNode6vac0wad1ypbxawb出演xaka演xasa演vaetva口{dNode6vac0wad1ypjxawb出口xaka口xasa口vaetva先{dNode6vac0wad1yp~xawb出先xaka先xasa先vaetwad3ypWhxawa出xaka出xasa出vaetvaハ{dNode6vac2vaイ{dNode6vac0wad2yp]Vxawfハイブリッドxakaイxaseイブリッドvaetvaッ{dNode6vac0wad1yppxawfハッシュタグxakaッxaseッシュタグvaetwad0xawaハxakaハxasaハvaesvaく{dNode6vac2vaら{dNode6vac0wad2ypgPxawcくらいxakaらxasbらいvaetvaれ{dNode6vac0wad1ypmxawcくれるxakaれxasbれるvaetwad9yp]^{RCF^izxawaくxakaくxasaくvaetvaれ{dNode6vac1vaる{dNode6vac0wad6ypT{ufoYxawbれるxakaるxasaるvaetwad<yp]WXams}}@Egqv@GKKKZtKSSWbfinossvzPTY[\eilnwJKLPVgjlsvwyz|AFIMN>xawaれxakaれxasaれvaetvaw{dNode6vac4vah{dNode6vac0wad1yp~xawjwhitespacexakahxasihitespacevaetvae{dNode6vac0wad1yp[xawbwexakaexasaevaetvai{dNode6vac2vat{dNode6vac0wad1ypyxawgwithoutxakatxasethoutvaetvak{dNode6vac0wad1yp@xawiwikipediaxakakxasgkipediavaetwad0xawbwixakaixasaivaesvaa{dNode6vac0wad1yp]xawcwayxakaaxasbayvaetwad2yp^uxawawxakawxasawvaetva紅{dNode6vac1va見{dNode6vac0wad1ypRxawc紅白見xaka見xasa見vaetwad3yp^ZCxawb紅白xaka紅xasb紅白vaetva見{dNode6vac:vaる{dNode6vac0wad1yp\xawb見るxakaるxasaるvaetvaつ{dNode6vac2vaて{dNode6vac0wad1yp_xawd見つけてxakaてxasaてvaetvaま{dNode6vac0wad1ypuxawe見つけましxakaまxasbましvaetwad5ypgv]Kxawc見つけxakaつxasbつけvaetvaや{dNode6vac0wad1ypOxawb見やxakaやxasaやvaetvaな{dNode6vac0wad1ypCxawb見なxakaなxasaなvaetvaて{dNode6vac0wad5ypPWlaBxawb見てxakaてxasaてvaetva本{dNode6vac0wad1yp\xawb見本xaka本xasa本vaetva直{dNode6vac0wad1yp{xawb見直xaka直xasa直vaetvaか{dNode6vac0wad1ypRxawd見かけてxakaかxascかけてvaetvaま{dNode6vac0wad1yptxawc見ましxakaまxasbましvaetvaた{dNode6vac0wad1ypQxawc見たいxakaたxasbたいvaetwad7yp^ZIWz|@xawa見xaka見xasa見vaetvaら{dNode6vac3vaみ{dNode6vac0wad1yp]xawbらみxakaみxasaみvaetvaか{dNode6vac0wad1ypJxawcらかけxakaかxasbかけvaetvaし{dNode6vac0wad2ypXGxawcらしいxakaしxasbしいvaetwad<yp^[vCIRVfhh|AVtNTh|bG>xawaらxakaらxasaらvaetva抱{dNode6vac0wad<yp^ZlhhuuCCIIRR|rrh[a>xawb抱負xaka抱xasb抱負vaetvat{dNode6vac5vaa{dNode6vac0wad1yp_xawftaichixakaaxaseaichivaetvah{dNode6vac0wad<yp|||||AAAAABBBBBFFFFFNNNNQQQSSUWWl]>xawcthexakahxasbhevaetvae{dNode6vac4vax{dNode6vac0wad1ypIxawdtextxakaxxasbxtvaetvam{dNode6vac0wad1yp{xawhtemplatexakamxasfmplatevaetvaa{dNode6vac0wad1ypfxawdteamxakaaxasbamvaetval{dNode6vac0wad1yp]xawdtellxakalxasbllvaetwad0xawbtexakaexasaevaesvao{dNode6vac0wad2yp]\xawbtoxakaoxasaovaetvar{dNode6vac1vab{dNode6vac0wad1ypLxawmtrunkbranchesxakabxashbranchesvaetwad2ypAoxawetrunkxakarxasdrunkvaetwad0xawatxakatxasatvaesva仕{dNode6vac3va事{dNode6vac1va中{dNode6vac0wad1yp_xawc仕事中xaka中xasa中vaetwad8yp{fAAddaxawb仕事xaka事xasa事vaetva組{dNode6vac0wad2ype{xawb仕組xaka組xasa組vaetva様{dNode6vac0wad1yp_xawb仕様xaka様xasa様vaetwad0xawa仕xaka仕xasa仕vaesva本{dNode6vac7va記{dNode6vac0wad1ypPxawc本記事xaka記xasb記事vaetva日{dNode6vac0wad<ypmmtWZ\^abimoqvzEIL>xawb本日xaka日xasa日vaetva当{dNode6vac0wad2yp@`xawb本当xaka当xasa当vaetva書{dNode6vac0wad1ypPxawb本書xaka書xasa書vaetva出{dNode6vac0wad1ypmxawe本出版記念xaka出xasd出版記念vaetva家{dNode6vac0wad1ypsxawb本家xaka家xasa家vaetvaだ{dNode6vac0wad1ypUxawb本だxakaだxasaだvaetwad<yp[aP\tZVVgggik}>xawa本xaka本xasa本vaetva間{dNode6vac0wad7ypPxxq{}rxawa間xaka間xasa間vaetva空{dNode6vac2vaい{dNode6vac0wad3ypPx{xawb空いxakaいxasaいvaetvaき{dNode6vac0wad1ypxxawd空きましxakaきxascきましvaetwad0xawa空xaka空xasa空vaesvaど{dNode6vac5vaう{dNode6vac3vaや{dNode6vac2vaっ{dNode6vac1vaて{dNode6vac0wad1ypGxaweどうやってxakaてxasaてvaetwad1ypQxawdどうやっxakaっxasaっvaetvaら{dNode6vac0wad1ypZxawdどうやらxakaらxasaらvaetwad0xawcどうやxakaやxasaやvaesvaい{dNode6vac0wad1yp{xawdどういうxakaいxasbいうvaetvaし{dNode6vac0wad1ypXxawcどうしxakaしxasaしvaetwad2ypsDxawbどうxakaうxasaうvaetvaん{dNode6vac0wad8ypTU`g@_\gxawbどんxakaんxasaんvaetvaち{dNode6vac0wad1ypOxawdどちらかxakaちxascちらかvaetvaー{dNode6vac0wad3yptUxxawbどーxakaーxasaーvaetvaも{dNode6vac0wad2yp@uxawbどもxakaもxasaもvaetwad1ypWxawaどxakaどxasaどvaetva使{dNode6vac5vaう{dNode6vac0wad3ypQiaxawb使うxakaうxasaうvaetvaっ{dNode6vac0wad<ypWbcjkXikTV_c>xawb使っxakaっxasaっvaetvaい{dNode6vac0wad4yp@MRRxawb使いxakaいxasaいvaetva用{dNode6vac0wad1ypgxawb使用xaka用xasa用vaetvaえ{dNode6vac0wad1yp~xawb使えxakaえxasaえvaetwad0xawa使xaka使xasa使vaesva簡{dNode6vac0wad<ypQ`owAEJS@^acnKlP>xawb簡単xaka簡xasb簡単vaetva少{dNode6vac1vaし{dNode6vac1vaず{dNode6vac0wad1ypGxawd少しずつxakaずxasbずつvaetwad:ypQ[uxx{TDvCxawb少しxakaしxasaしvaetwad2ypY|xawa少xaka少xasa少vaetvaパ{dNode6vac8vaタ{dNode6vac0wad1ypQxawdパターンxakaタxascターンvaetvaブ{dNode6vac0wad1ypXxawjパブリックプレビューxakaブxasiブリックプレビューvaetvaー{dNode6vac0wad3ypkttxawcパーツxakaーxasbーツvaetvaフ{dNode6vac0wad2ypOxawgパフォーマンスxakaフxasfフォーマンスvaetvaラ{dNode6vac0wad1ypCxaweパラメータxakaラxasdラメータvaetvaス{dNode6vac0wad1ypxxaweパスポートxakaスxasdスポートvaetvaシ{dNode6vac0wad1ypQxawcパシリxakaシxasbシリvaetvaッ{dNode6vac2vaチ{dNode6vac0wad4ypz@@xawcパッチxakaチxasaチvaetvaケ{dNode6vac0wad1ypNxaweパッケージxakaケxascケージvaetwad0xawbパッxakaッxasaッvaeswad1ypNxawaパxakaパxasaパvaetva試{dNode6vac1vaし{dNode6vac0wad3ypqBlxawb試しxakaしxasaしvaetwad1ypQxawa試xaka試xasa試vaetva風{dNode6vac2va邪{dNode6vac0wad2ypiixawb風邪xaka邪xasa邪vaetva雨{dNode6vac0wad1ypxxawb風雨xaka雨xasa雨vaetwad1ypRxawa風xaka風xasa風vaetvaう{dNode6vac2vaわ{dNode6vac0wad1ypRxawcうわさxakaわxasbわさvaetvaま{dNode6vac0wad1yptxawcうまくxakaまxasbまくvaetwad1yp{xawaうxakaうxasaうvaetvaT{dNode6vac9vao{dNode6vac2vae{dNode6vac3vaF{dNode6vac0wad2ypROxawkTokenFilterxakaFxasfFiltervaetvai{dNode6vac0wad1ypOxawiTokenizerxakaixasdizervaetva対{dNode6vac0wad1ypOxawhToken対してxaka対xasc対してvaetwad0xaweTokenxakaexasbenvaesvay{dNode6vac1vaN{dNode6vac0wad1ypexawhTokyoNLPxakaNxascNLPvaetwad7yphz{JQSLxaweTokyoxakayxasbyovaetwad0xawcTokxakaoxasbokvaesvaw{dNode6vac2vai{dNode6vac0wad<yprrwQ[Zs~KQUVWbgK>xawgTwitterxakaixaseittervaetvae{dNode6vac0wad1ypsxawiTweetDeckxakaexasgeetDeckvaetwad0xawbTwxakawxasawvaesvae{dNode6vac2var{dNode6vac0wad1ypyxawiTerraformxakarxasgrraformvaetvac{dNode6vac1van{dNode6vac0wad2ypqvxawjTechnologyxakanxasfnologyvaetwad1yptxawdTechxakacxasbchvaetwad0xawbTexakaexasaevaesvaO{dNode6vac1vaE{dNode6vac0wad2yphuxaweTOEICxakaExascEICvaetwad1yphxawbTOxakaOxasaOvaetvaa{dNode6vac1vas{dNode6vac0wad1ypbxaweTalksxakasxasasvaetwad1yptxawdTalkxakaaxascalkvaetvah{dNode6vac2vae{dNode6vac0wad4ypV_dvxawcThexakaexasaevaetvaa{dNode6vac0wad1ypkxawfThanksxakaaxasdanksvaetwad0xawbThxakahxasahvaesvaD{dNode6vac0wad2ypS_xawbTDxakaDxasaDvaetvaL{dNode6vac0wad3ypUWRxawbTLxakaLxasaLvaetvaS{dNode6vac0wad1ypPxawgTSUTAYAxakaSxasfSUTAYAvaetwad0xawaTxakaTxasaTvaesvaL{dNode6vac6vau{dNode6vac2vac{dNode6vac0wad<ypR\^abimoqz@EILZoOYYnnwJN_tyyFIIOR>xawfLucenexakacxasdcenevaetvan{dNode6vac0wad1ypbxawgLunakeyxakanxasenakeyvaetwad0xawbLuxakauxasauvaesvaU{dNode6vac0wad1ypRxawdLUCExakaUxascUCEvaetvae{dNode6vac0wad1ypYxawhLearningxakaexasgearningvaetvai{dNode6vac4vat{dNode6vac0wad1yp^xawjLiteraturexakatxashteraturevaetvag{dNode6vac0wad1ypoxaweLightxakagxascghtvaetvan{dNode6vac0wad2ypsZxawgLinderaxakanxasenderavaetvao{dNode6vac0wad1ypqxawdLionxakaoxasbonvaetwad0xawbLixakaixasaivaesvaT{dNode6vac0wad1ypmxawbLTxakaTxasaTvaetvao{dNode6vac0wad7ypZZkBCFFxawhLogstashxakaoxasgogstashvaetwad0xawaLxakaLxasaLvaesva取{dNode6vac2vaり{dNode6vac1va込{dNode6vac1vaる{dNode6vac0wad1ypKxawf取り込まれるxakaるxasaるvaetwad1ypRxawe取り込まれxaka込xasc込まれvaetwad2yp{Hxawb取りxakaりxasaりvaetvaる{dNode6vac0wad2yphGxawb取るxakaるxasaるvaetwad0xawa取xaka取xasa取vaesva聞{dNode6vac3vaき{dNode6vac1vaま{dNode6vac0wad1ypRxawd聞きましxakaまxasbましvaetwad3yprdqxawb聞きxakaきxasaきvaetvaい{dNode6vac0wad3yp{SZxawb聞いxakaいxasaいvaetvaけ{dNode6vac0wad1ypJxawc聞けるxakaけxasbけるvaetwad0xawa聞xaka聞xasa聞vaesva.{dNode6vac0wad<ypSSWmEEIOjkppry}~~JJJJJJJKVVWWXXXXYYYYYZZZZ\\\\]^^^^__aaaaaabbbbbbeeeeeeiiiillmmmmooooqqqqsuuvvvvvvyyyyzzzzzz~~~~BBCCCCCEEEEEEIIIIIIKKKLLLLLRRRRSSSSoooossss{KOOYYYY[\\nnnnuuww}AADEEHHHIIJJMMNNOO\_ccnnyHHINN>xawa.xaka.xasa.vaetva際{dNode6vac0wad1ypSxawa際xaka際xasa際vaetva修{dNode6vac0wad6ypSEcHxawb修正xaka修xasb修正vaetva個{dNode6vac2va的{dNode6vac0wad3ypS^pxawc個人的xaka的xasa的vaetva用{dNode6vac0wad1ypDxawc個人用xaka用xasa用vaetwad2ypK{xawb個人xaka個xasb個人vaetvaお{dNode6vac<vaき{dNode6vac1vaま{dNode6vac0wad<ypSY^gkvOzH[vG>xawdおきますxakaまxasbますvaetwad1ypCxawbおきxakaきxasaきvaetvaこ{dNode6vac2vaか{dNode6vac0wad1yp[xawdおこうかxakaかxasaかvaetvaう{dNode6vac0wad1ypbxaweおこううかxakaうxasbうかvaetwad2ypMlxawcおこうxakaこxasbこうvaetva試{dNode6vac0wad2yppVxawcお試しxaka試xasb試しvaetvaか{dNode6vac2vaげ{dNode6vac0wad1ypuxawcおかげxakaげxasaげvaetvaし{dNode6vac0wad1yp{xawdおかしいxakaしxasbしいvaetwad0xawbおかxakaかxasaかvaesvaも{dNode6vac0wad1ypTxawdおもしろxakaもxascもしろvaetvaり{dNode6vac0wad3yp^|Axawbおりxakaりxasaりvaetvaめ{dNode6vac0wad4ypBQq`xawbおめxakaめxasaめvaetvaよ{dNode6vac0wad1ypWxawcおよびxakaよxasbよびvaetvaた{dNode6vac0wad1yp{xawdおたしてxakaたxascたしてvaetva決{dNode6vac0wad1ypqxawdお決まりxaka決xasc決まりvaetvaい{dNode6vac1vaて{dNode6vac0wad1ypqxawcおいてxakaてxasaてvaetwad1ypVxawbおいxakaいxasaいvaetva久{dNode6vac0wad2yp}^xaweお久しぶりxaka久xasd久しぶりvaetvaし{dNode6vac0wad1ypkxawdおしゃれxakaしxascしゃれvaetvaっ{dNode6vac0wad1ypkxawcおっきxakaっxasbっきvaetvaろ{dNode6vac0wad1ypexawbおろxakaろxasaろvaetva知{dNode6vac0wad1ypHxaweお知らせしxaka知xasd知らせしvaet>wad<ypuDX^^_hy|p{B}Cm]fwyyII>xawaおxakaおxasaおvaetvaQ{dNode6vac2vaq{dNode6vac0wad2ypTUxawfQuerqyxakaqxasbqyvaetvay{dNode6vac0wad1yp_xaweQueryxakayxasayvaetwad0xawdQuerxakaQxasdQuervaesvaE{dNode6vac8val{dNode6vac2vaa{dNode6vac1vas{dNode6vac1vat{dNode6vac1vai{dNode6vac1vac{dNode6vac2vas{dNode6vac1vae{dNode6vac1vac{dNode6vac1vah{dNode6vac3va1{dNode6vac0wad1ypyxawnElasticsearch1xaka1xasa1vaetva勉{dNode6vac0wad<ypqsHNOQU`ccpwGTi>xaw PElasticsearch勉強会xaka勉xasc勉強会vaetvaユ{dNode6vac0wad1ypOxaw PElasticsearchユーザxakaユxascユーザvaetwad<ypTWmmLMMovwEJJKSXXYY\]]^_abdeeikmoqtv}~KOQRRTWY_jklnpqs}P>xawmElasticsearchxakahxasahvaetwad1ypsxawlElasticsearcxakacxasacvaetwad1ypJxawkElasticsearxakaexascearvaetwad1ypDxawhElasticsxakasxasasvaetvaS{dNode6vac1var{dNode6vac2va勉{dNode6vac0wad1ypBxaw PElasticSearch勉強会xaka勉xasc勉強会vaetvaネ{dNode6vac0wad1ypCxawoElasticSearchネタxakaネxasbネタvaetwad4ypeiBxawmElasticSearchxakarxascrchvaetwad1ypxawjElasticSeaxakaSxascSeavaetwad<ypmEEKmovwzDDEFJK[fl>xawgElasticxakacxasacvaetwad3ypr}UxawfElastixakaixasaivaetwad2ypTLxaweElastxakatxasatvaetwad9ypm\^iozEGxawdElasxakasxasasvaetwad2ypmqxawcElaxakaaxasaavaetvas{dNode6vac0wad6ypjnxHM`xawoElsticsearch勉強会xakasxasmsticsearch勉強会vaetwad0xawbElxakalxasalvaesvax{dNode6vac0wad1ypYxawgExtremexakaxxasfxtremevaetvan{dNode6vac3vat{dNode6vac0wad1ypKxawjEnterprisexakatxashterprisevaetvau{dNode6vac0wad1ypQxawdEnumxakauxasbumvaetvag{dNode6vac1vai{dNode6vac0wad1yptxawkEngineeringxakaixascingvaetwad1yphxawhEngineerxakagxasfgineervaetwad0xawbEnxakanxasanvaesvaa{dNode6vac0wad1yptxaweEarlyxakaaxasdarlyvaetvad{dNode6vac0wad2ypvvxawgEditionxakadxasfditionvaetvaテ{dNode6vac0wad1ypBxawcEテレxakaテxasbテレvaetvac{dNode6vac0wad1yp~xawgEclipsexakacxasfclipsevaetvav{dNode6vac0wad1ypCxawhEvernotexakavxasgvernotevaetwad2ypabxawaExakaExasaEvaetvaち{dNode6vac3vaょ{dNode6vac2vaっ{dNode6vac0wad<ypTWwBD|^rFFO]Drvx>xawcちょっxakaっxasaっvaetvaく{dNode6vac0wad1ypNxawfちょくちょくxakaくxasdくちょくvaetwad0xawbちょxakaょxasaょvaesvaゃ{dNode6vac2vaい{dNode6vac0wad1ypwxaweちゃいましxakaいxascいましvaetvaっ{dNode6vac0wad1ypHxawcちゃっxakaっxasaっvaetwad0xawbちゃxakaゃxasaゃvaesvaな{dNode6vac0wad1ypyxawcちなみxakaなxasbなみvaetwad4ypGoylxawaちxakaちxasaちvaetva調{dNode6vac2vaべ{dNode6vac2vaる{dNode6vac0wad3ypDIIxawc調べるxakaるxasaるvaetvaま{dNode6vac0wad1ypFxawd調べましxakaまxasbましvaetwad7ypTUgKOUSxawb調べxakaべxasaべvaetva査{dNode6vac0wad4yp@@DKxawb調査xaka査xasa査vaetwad0xawa調xaka調xasa調vaesvaみ{dNode6vac8vaま{dNode6vac2vaし{dNode6vac0wad<ypTUtLPPTUW`xKPRVbiTZv>xawcみましxakaしxasaしvaetvaす{dNode6vac0wad2ypJIxawcみますxakaすxasaすvaetwad0xawbみまxakaまxasaまvaesvaん{dNode6vac0wad2yps}xawbみんxakaんxasaんvaetvaよ{dNode6vac0wad1ypwxawbみよxakaよxasaよvaetvaる{dNode6vac0wad1ypLxawbみるxakaるxasaるvaetvaな{dNode6vac0wad1ypPxawdみなさんxakaなxascなさんvaetvaて{dNode6vac0wad1ypnxawbみてxakaてxasaてvaetvaれ{dNode6vac0wad2ypwqxawbみれxakaれxasaれvaetvaみ{dNode6vac0wad1ypLxawbみみxakaみxasaみvaetwad<ypUWcez{ETVor|DEL\d[k~DK^aiuxSS>xawaみxakaみxasaみvaetvaク{dNode6vac5vaエ{dNode6vac1vaプ{dNode6vac0wad1ypJxaweクエリプロxakaプxasbプロvaetwad1ypUxawcクエリxakaエxasbエリvaetvaラ{dNode6vac2vaイ{dNode6vac1vaア{dNode6vac0wad1ypsxawiクライアントアプリxakaアxascアプリvaetwad1ypWxawfクライアントxakaイxasdイアントvaetvaス{dNode6vac2vaタ{dNode6vac1vaー{dNode6vac0wad1ypyxaweクラスターxakaーxasaーvaetwad1yplxawdクラスタxakaタxasaタvaetvaパ{dNode6vac0wad1ypAxaweクラスパスxakaパxasbパスvaetwad1ypNxawcクラスxakaスxasaスvaetwad0xawbクラxakaラxasaラvaesvaロ{dNode6vac0wad1ypsxawdクローンxakaロxascローンvaetvaレ{dNode6vac0wad1ypvxawdクレートxakaレxascレートvaetvaイ{dNode6vac0wad1yp[xawgクイックツアーxakaイxasfイックツアーvaetwad0xawaクxakaクxasaクvaesva用{dNode6vac1va意{dNode6vac0wad3yp@wHxawb用意xaka意xasa意vaetwad1ypUxawa用xaka用xasa用vaetva概{dNode6vac2va要{dNode6vac0wad6ypUwJpCRxawb概要xaka要xasa要vaetva念{dNode6vac1va的{dNode6vac0wad1ypuxawc概念的xaka的xasa的vaetwad1ypUxawb概念xaka念xasa念vaetwad1yp{xawa概xaka概xasa概vaetva追{dNode6vac4vaい{dNode6vac0wad1ypUxawd追いかけxakaいxascいかけvaetvaっ{dNode6vac0wad2ypA[xawb追っxakaっxasaっvaetva加{dNode6vac0wad2ypsxawb追加xaka加xasa加vaetva記{dNode6vac0wad1ypxawb追記xaka記xasa記vaetwad0xawa追xaka追xasa追vaesva感{dNode6vac4vaじ{dNode6vac0wad9ypUzzmn^`mrxawb感じxakaじxasaじvaetva想{dNode6vac1va文{dNode6vac0wad1yp\xawc感想文xaka文xasa文vaetwad8yp`Pnxxlz|xawb感想xaka想xasa想vaetva満{dNode6vac0wad1ypfxawc感満載xaka満xasb満載vaetva謝{dNode6vac0wad1ypixawb感謝xaka謝xasa謝vaetwad0xawa感xaka感xasa感vaesva現{dNode6vac3va地{dNode6vac0wad1ypVxawb現地xaka地xasa地vaetva在{dNode6vac0wad4ypu\~Pxawb現在xaka在xasa在vaetva状{dNode6vac1va確{dNode6vac0wad1ypXxawe現状確認会xaka確xasc確認会vaetwad1ypXxawb現状xaka状xasa状vaetwad0xawa現xaka現xasa現vaesva再{dNode6vac2va開{dNode6vac0wad2ypVxxawb再開xaka開xasa開vaetva生{dNode6vac0wad1ypZxawb再生xaka生xasa生vaetwad0xawa再xaka再xasa再vaesva人{dNode6vac4vaも{dNode6vac1vaる{dNode6vac0wad1ypVxawd人もいるxakaるxasaるvaetwad1yp`xawc人もいxakaもxasbもいvaetva生{dNode6vac1va初{dNode6vac0wad1ypgxawc人生初xaka初xasa初vaetwad1ypgxawb人生xaka生xasa生vaetva数{dNode6vac0wad1ypzxawb人数xaka数xasa数vaetva形{dNode6vac0wad1ypkxawb人形xaka形xasa形vaetwad5ypqkW]zxawa人xaka人xasa人vaetva正{dNode6vac2va式{dNode6vac0wad1ypWxawb正式xaka式xasa式vaetva規{dNode6vac0wad1ypxxawd正規表現xaka規xasc規表現vaetwad0xawa正xaka正xasa正vaesva新{dNode6vac6vaし{dNode6vac2vaい{dNode6vac0wad4ypWX@kxawc新しいxakaいxasaいvaetvaく{dNode6vac0wad2ypktxawc新しくxakaくxasaくvaetwad0xawb新しxakaしxasaしvaesva機{dNode6vac0wad1ypaxawc新機能xaka機xasb機能vaetva型{dNode6vac0wad1ypdxawb新型xaka型xasa型vaetva規{dNode6vac2va書{dNode6vac0wad1ypGxawd新規書きxaka書xasb書きvaetva追{dNode6vac0wad1ypnxawf新規追加機能xaka追xasd追加機能vaetwad0xawb新規xaka規xasa規vaesva天{dNode6vac0wad1ypVxawc新天地xaka天xasb天地vaetva調{dNode6vac0wad1ypDxawb新調xaka調xasa調vaetwad1ypmxawa新xaka新xasa新vaetva公{dNode6vac2va開{dNode6vac0wad3ypXP[xawb公開xaka開xasa開vaetva約{dNode6vac0wad1yp[xawb公約xaka約xasa約vaetwad1ypgxawa公xaka公xasa公vaetvaI{dNode6vac5van{dNode6vac4vad{dNode6vac0wad1ypXxaweIndexxakadxascdexvaetvag{dNode6vac2vas{dNode6vac0wad1ypLxawfIngestxakasxasbstvaetvar{dNode6vac0wad1ypoxawiIngersollxakarxasersollvaetwad0xawdIngexakagxasbgevaesvaf{dNode6vac0wad2ypvvxawkInformationxakafxasiformationvaetvas{dNode6vac0wad1yp]xawfInsidexakasxasdsidevaetwad0xawbInxakanxasanvaesvas{dNode6vac1vas{dNode6vac0wad2ypz@xaweIssuexakasxascsuevaetwad1yp_xawbIsxakasxasasvaetvaD{dNode6vac0wad2ypFFxawbIDxakaDxasaDvaetvao{dNode6vac0wad1yprxawbIoxakaoxasaovaetvaP{dNode6vac0wad1ypPxawfIPAdicxakaPxasePAdicvaetwad2ypmSxawaIxakaIxasaIvaetva別{dNode6vac5va名{dNode6vac0wad1ypXxawb別名xaka名xasa名vaetva開{dNode6vac0wad1yp_xawc別開催xaka開xasb開催vaetva日{dNode6vac0wad1yp_xawc別日程xaka日xasb日程vaetva関{dNode6vac0wad1yp}xawb別関xaka関xasa関vaetva々{dNode6vac0wad1ypMxawb別々xaka々xasa々vaetwad2ypIMxawa別xaka別xasa別vaetva段{dNode6vac0wad2ypXxawb段階xaka段xasb段階vaetva年{dNode6vac3va末{dNode6vac0wad3ypY`gxawb年末xaka末xasa末vaetva始{dNode6vac0wad1ypgxawb年始xaka始xasa始vaetva越{dNode6vac0wad1yp_xawb年越xaka越xasa越vaetwad0xawa年xaka年xasa年vaesva次{dNode6vac2va回{dNode6vac0wad1yp`xawb次回xaka回xasa回vaetva期{dNode6vac0wad2yprOxawb次期xaka期xasa期vaetwad<ypY\VWXYZ[\]^_abdeiklmoqsuvyz~BCEILcT@K>xawa次xaka次xasa次vaetva論{dNode6vac1va自{dNode6vac0wad1yp^xawd論文自体xaka自xasb自体vaetwad2ypY^xawb論文xaka論xasb論文vaetva軽{dNode6vac1vaど{dNode6vac0wad1ypUxawd軽くどんxakaどxasbどんvaetwad3ypY^ixawb軽くxaka軽xasb軽くvaetvaM{dNode6vac<vau{dNode6vac2val{dNode6vac0wad1ypYxaweMultixakalxascltivaetvai{dNode6vac0wad1ypRxawdMuirxakaixasbirvaetwad0xawbMuxakauxasauvaesvaa{dNode6vac6vat{dNode6vac0wad1ypYxawhMatchingxakatxasftchingvaetvac{dNode6vac2vab{dNode6vac0wad2ypklxawgMacbookxakabxasdbookvaetvak{dNode6vac0wad1ypXxawhMackerelxakakxasekerelvaetwad5ypcjiqCxawcMacxakacxasacvaetvar{dNode6vac2vav{dNode6vac1vae{dNode6vac0wad3ypW~nxawfMarvelxakaexasbelvaetwad1ypWxawdMarvxakavxasavvaetvak{dNode6vac0wad2ypWWxawhMarkdownxakakxasekdownvaetwad0xawcMarxakarxasarvaesvap{dNode6vac2vap{dNode6vac0wad1ypdxawgMappingxakapxasdpingvaetvaR{dNode6vac0wad1yp]xawdMapRxakaRxasaRvaetwad0xawcMapxakapxasapvaesvav{dNode6vac0wad2ypuuxaweMavenxakavxascvenvaetvah{dNode6vac0wad1ypoxawfMahoutxakahxasdhoutvaetwad0xawbMaxakaaxasaavaesvaI{dNode6vac0wad2yp__xaweMICESxakaIxasdICESvaetvai{dNode6vac3van{dNode6vac0wad1ypbxawdMinixakanxasbnivaetvar{dNode6vac0wad1ypDxawiMircosoftxakarxasgrcosoftvaetval{dNode6vac0wad1yppxawkMildensteinxakalxasildensteinvaetwad0xawbMixakaixasaivaesvaS{dNode6vac0wad1ypDxawbMSxakaSxasaSvaetvay{dNode6vac0wad1ypDxawfMyBuilxakayxaseyBuilvaetvae{dNode6vac3vae{dNode6vac0wad4ypr{JGxawfMeetupxakaexasdetupvaetvar{dNode6vac0wad2ypDJxaweMerryxakarxascrryvaetvaC{dNode6vac0wad2ypLRxaweMeCabxakaCxascCabvaetwad0xawbMexakaexasaevaesvaA{dNode6vac0wad1yp|xawhMANABIYAxakaAxasgANABIYAvaetvaL{dNode6vac0wad7ypLO\antxawbMLxakaLxasaLvaetvao{dNode6vac4var{dNode6vac0wad1ypFxawjMorphlinesxakarxashrphlinesvaetvan{dNode6vac1vaD{dNode6vac0wad1ypjxawgMongoDBxakaDxasbDBvaetwad1yphxaweMongoxakanxascngovaetvau{dNode6vac0wad1ypqxawhMountainxakauxasfuntainvaetvad{dNode6vac0wad2ypvvxawfModernxakadxasddernvaetwad0xawbMoxakaoxasaovaesvaT{dNode6vac0wad1ypixawbMTxakaTxasaTvaetvaB{dNode6vac0wad5ypfs~~BxawcMBAxakaBxasbBAvaet>wad0xawaMxakaMxasaMvaesval{dNode6vac5vaa{dNode6vac2vab{dNode6vac0wad1ypYxawelabelxakabxascbelvaetvan{dNode6vac0wad1yp@xawhlanguagexakanxasfnguagevaetwad0xawblaxakaaxasaavaesvau{dNode6vac2van{dNode6vac1vau{dNode6vac0wad2yp~~xawjluceneutilxakauxasdutilvaetwad<ypoYwAENNOOXX_`cnqAAHLNOP>xawflucenexakanxasbnevaetvae{dNode6vac0wad1ypzxaweluceexakaexasaevaetwad0xawdlucexakauxascucevaesvay{dNode6vac0wad1ypyxawblyxakayxasayvaetvai{dNode6vac2vat{dNode6vac0wad1ypuxawiliterallyxakatxasgterallyvaetvab{dNode6vac0wad1ypAxawclibxakabxasabvaetwad0xawblixakaixasaivaesvao{dNode6vac0wad2ypBCxawhlogstashxakaoxasgogstashvaetwad1ypBxawalxakalxasalvaetvaf{dNode6vac4vao{dNode6vac0wad5ypY^sOLxawcforxakaoxasborvaetvai{dNode6vac2val{dNode6vac0wad1ypexawffilterxakalxasdltervaetvae{dNode6vac0wad1yp}xawifieldTypexakaexasgeldTypevaetwad0xawbfixakaixasaivaesvan{dNode6vac0wad1ypIxawbfnxakanxasanvaetval{dNode6vac1vad{dNode6vac0wad1ypVxawgfluentdxakadxasadvaetwad1ypVxawffluentxakalxaseluentvaetwad0xawafxakafxasafvaesvai{dNode6vac4van{dNode6vac2vad{dNode6vac0wad1ypOxawhindexingxakadxasfdexingvaetvaq{dNode6vac0wad1ypxawjinquisitorxakaqxashquisitorvaetwad6ypY]ccpZxawbinxakanxasanvaetvaO{dNode6vac0wad1ypsxawciOSxakaOxasbOSvaetvas{dNode6vac0wad1ypXxaweissuexakasxasdssuevaetvam{dNode6vac0wad1ypLxawdimplxakamxascmplvaetwad0xawaixakaixasaivaesva理{dNode6vac2va由{dNode6vac0wad8ypY^x{HkUSxawb理由xaka由xasa由vaetva論{dNode6vac0wad1yphxawb理論xaka論xasa論vaetwad0xawa理xaka理xasa理vaesva一{dNode6vac<va緒{dNode6vac0wad3ypYfSxawb一緒xaka緒xasa緒vaetva覧{dNode6vac0wad3yp\lsxawb一覧xaka覧xasa覧vaetva台{dNode6vac0wad1ypjxawb一台xaka台xasa台vaetva応{dNode6vac1va現{dNode6vac0wad1ypbxawd一応現在xaka現xasb現在vaetwad4yp~uGxawb一応xaka応xasa応vaetva旦{dNode6vac0wad1ypnxawd一旦休憩xaka旦xasc旦休憩vaetva年{dNode6vac0wad2ypIRxawb一年xaka年xasa年vaetva番{dNode6vac1va忙{dNode6vac0wad1ypTxawc一番忙xaka忙xasa忙vaetwad1ypSxawb一番xaka番xasa番vaetvaつ{dNode6vac0wad1ypdxawb一つxakaつxasaつvaetva人{dNode6vac0wad1ypgxawb一人xaka人xasa人vaetva家{dNode6vac0wad1yp^xawd一家全滅xaka家xasc家全滅vaetva箇{dNode6vac0wad1ypkxawc一箇所xaka箇xasb箇所vaetva週{dNode6vac0wad1ypxawc一週間xaka週xasb週間vaet>wad1ypCxawa一xaka一xasa一vaetva録{dNode6vac0wad2ypZBxawb録画xaka録xasb録画vaetva気{dNode6vac1vaづ{dNode6vac0wad4ypH}h@xawc気づいxakaづxasbづいvaetwad<ypZirIP@IKt~HK^iz>xawa気xaka気xasa気vaetva良{dNode6vac2vaか{dNode6vac0wad2yp[\xawc良かっxakaかxasbかっvaetvaい{dNode6vac1vaか{dNode6vac0wad1ypWxawc良いかxakaかxasaかvaetwad5yp[V@jWxawb良いxakaいxasaいvaetwad0xawa良xaka良xasa良vaesva思{dNode6vac3vaい{dNode6vac2vaま{dNode6vac0wad7yp[`oDEQlxawd思いますxakaまxasbますvaetvaつ{dNode6vac0wad1yphxawd思いついxakaつxasbついvaetwad7ypmsJtWghxawb思いxakaいxasaいvaetvaっ{dNode6vac0wad;ypqTbiE]PSTjSxawb思っxakaっxasaっvaetvaう{dNode6vac0wad1yp`xawb思うxakaうxasaうvaetwad1ypUxawa思xaka思xasa思vaetvaネ{dNode6vac0wad2yp[yxawbネタxakaネxasbネタvaetvaス{dNode6vac<vaキ{dNode6vac2vaー{dNode6vac0wad2yp\Dxawdスキーマxakaーxasbーマvaetvaル{dNode6vac0wad1yp]xawfスキルアップxakaルxasdルアップvaetwad0xawbスキxakaキxasaキvaesvaラ{dNode6vac0wad5ypcclllxawdスライドxakaラxascライドvaetvaイ{dNode6vac0wad1ypjxawdスイッチxakaイxascイッチvaetvaピ{dNode6vac2vaー{dNode6vac0wad;ypyNOQU`jnxHMxaweスピーカーxakaーxascーカーvaetvaリ{dNode6vac0wad1yp[xawgスピリチュアルxakaリxaseリチュアルvaetwad0xawbスピxakaピxasaピvaesvaポ{dNode6vac0wad1yp|xaweスポンサーxakaポxasdポンサーvaetvaタ{dNode6vac2vaッ{dNode6vac0wad;ypNOQU`jnxHMZxawdスタッフxakaッxasbッフvaetvaー{dNode6vac0wad1ypRxawdスタートxakaーxasbートvaetwad0xawbスタxakaタxasaタvaesvaケ{dNode6vac1vaア{dNode6vac0wad1yplxawgスケールアップxakaアxascアップvaetwad1ypKxawdスケールxakaケxascケールvaetvaペ{dNode6vac0wad1ypkxawhスペシャルゲストxakaペxasgペシャルゲストvaetvaテ{dNode6vac2vaキ{dNode6vac0wad1ypyxawcステキxakaキxasaキvaetvaッ{dNode6vac0wad1yptxaweステッカーxakaッxascッカーvaetwad0xawbステxakaテxasaテvaesvaリ{dNode6vac0wad2ypEExawdスリープxakaリxascリープvaetvaマ{dNode6vac0wad1ypbxawcスマホxakaマxasbマホvaetvaー{dNode6vac0wad1ypBxawmスーパープレゼンテーションxakaーxaslーパープレゼンテーションvaet>wad1ypdxawaスxakaスxasaスvaetvaポ{dNode6vac3vaー{dNode6vac0wad1yp\xawdポータルxakaーxascータルvaetvaス{dNode6vac0wad1ypPxawcポストxakaスxasbストvaetvaモ{dNode6vac1vaテ{dNode6vac0wad2ypZZxawjポモドーロテクニックxakaテxaseテクニックvaetwad1ypZxaweポモドーロxakaモxasdモドーロvaetwad0xawaポxakaポxasaポvaesvaフ{dNode6vac3vaィ{dNode6vac0wad1yp\xaweフィールドxakaィxasdィールドvaetvaリ{dNode6vac0wad1yp{xawfフリーランスxakaリxaseリーランスvaetvaァ{dNode6vac1vaイ{dNode6vac0wad7ypGFwA@AAxawdファイルxakaイxasbイルvaetwad1ypOxawbファxakaァxasaァvaetwad0xawaフxakaフxasaフvaesva実{dNode6vac4va際{dNode6vac0wad4yp\aCmxawb実際xaka際xasa際vaetva装{dNode6vac0wad2yphxawb実装xaka装xasa装vaetva践{dNode6vac0wad7ypYYY[aaYxawb実践xaka践xasa践vaetva例{dNode6vac0wad1ypYxawb実例xaka例xasa例vaetwad1yp}xawa実xaka実xasa実vaetva投{dNode6vac0wad4yp]]naxawb投稿xaka投xasb投稿vaetva引{dNode6vac2vaき{dNode6vac0wad6yp]sZQd@xawb引きxakaきxasaきvaetvaっ{dNode6vac0wad1ypjxawb引っxakaっxasaっvaetwad0xawa引xaka引xasa引vaesva:{dNode6vac1va/{dNode6vac0wad3yppy\xawb:/xaka/xasa/vaetwad<yp^sIppppppls[\uv\\\\]]>xawa:xaka:xasa:vaetvao{dNode6vac5van{dNode6vac0wad1yp^xawbonxakanxasanvaetvar{dNode6vac2vad{dNode6vac0wad1ypexawforderbxakadxasdderbvaetvag{dNode6vac0wad2ypO\xawcorgxakagxasagvaetwad1ypGxawborxakarxasarvaetvas{dNode6vac0wad1ypsxaweosukaxakasxasdsukavaetvaf{dNode6vac0wad1ypVxawbofxakafxasafvaetvau{dNode6vac0wad1ypfxawcourxakauxasburvaetwad0xawaoxakaoxasaovaesva共{dNode6vac3va同{dNode6vac0wad1yp_xawb共同xaka同xasa同vaetva通{dNode6vac0wad1ypHxawb共通xaka通xasa通vaetva著{dNode6vac0wad1ypPxawc共著者xaka著xasb著者vaetwad0xawa共xaka共xasa共vaesvaカ{dNode6vac6vaン{dNode6vac0wad3yp`|pxawgカンファレンスxakaンxasfンファレンスvaetvaタ{dNode6vac0wad1yplxawcカタンxakaタxasbタンvaetvaス{dNode6vac0wad2ypLMxawdカスタムxakaスxascスタムvaetvaジ{dNode6vac0wad1ypXxawjカジュアルウォーターxakaジxasiジュアルウォーターvaetvaフ{dNode6vac0wad1ypkxawcカフェxakaフxasbフェvaetvaバ{dNode6vac0wad1ypfxawcカバーxakaバxasbバーvaetwad0xawaカxakaカxasaカvaesvaセ{dNode6vac5vaマ{dNode6vac0wad1ypaxawgセマンティックxakaマxasfマンティックvaetvaパ{dNode6vac0wad2yporxawhセパレートタイプxakaパxasgパレートタイプvaetvaッ{dNode6vac2vaト{dNode6vac0wad6yp~ilf~Cxawfセットアップxakaトxasdトアップvaetvaシ{dNode6vac1vaン{dNode6vac1vaオ{dNode6vac0wad1ypexawiセッションオーナーxakaオxasdオーナーvaetwad6ypD|pGefxaweセッションxakaンxasaンvaetwad1ypzxawdセッショxakaシxasbショvaetwad0xawbセッxakaッxasaッvaesvaミ{dNode6vac0wad1ypmxawdセミナーxakaミxascミナーvaetvaル{dNode6vac0wad3yprz|xawgセルフスタディxakaルxasfルフスタディvaetwad0xawaセxakaセxasaセvaesva発{dNode6vac3va表{dNode6vac1va者{dNode6vac0wad1yp`xawc発表者xaka者xasa者vaetwad2ypawxawb発表xaka表xasa表vaetva売{dNode6vac0wad4ypbWivxawb発売xaka売xasa売vaetva生{dNode6vac0wad1ypxxawb発生xaka生xasa生vaetwad1ypexawa発xaka発xasa発vaetvav{dNode6vac2va2{dNode6vac0wad2ypboxawbv2xaka2xasa2vaetvaa{dNode6vac0wad1ypJxawhvalidatexakaaxasgalidatevaetwad1ypixawavxakavxasavvaetva長{dNode6vac4vaら{dNode6vac0wad1ypbxawc長らくxakaらxasbらくvaetvaさ{dNode6vac0wad1yppxawb長さxakaさxasaさvaetvaい{dNode6vac0wad2ypIuxawb長いxakaいxasaいvaetvaか{dNode6vac0wad1ypSxawc長かっxakaかxasbかっvaetwad0xawa長xaka長xasa長vaesvaK{dNode6vac7vao{dNode6vac0wad2ypbixaweKochixakaoxasdochivaetvae{dNode6vac2vab{dNode6vac0wad3ypbiixawhKeyboardxakabxaseboardvaetvan{dNode6vac0wad1ypcxawgKeynotexakanxasdnotevaetwad0xawcKeyxakaexasbeyvaesvaV{dNode6vac0wad1ypjxawcKVMxakaVxasbVMvaetvau{dNode6vac0wad8ypsRRZAaJxawhKuromojixakauxasguromojivaetvaJ{dNode6vac0wad1yp\xawbKJxakaJxasaJvaetvai{dNode6vac2vab{dNode6vac0wad9ypAYYYuGMMPxawfKibanaxakabxasdbanavaetvan{dNode6vac0wad1ypgxawfKindlexakanxasdndlevaetwad0xawbKixakaixasaivaesvaa{dNode6vac2vag{dNode6vac0wad1ypgxawfKagomexakagxasdgomevaetvau{dNode6vac0wad1yp]xawgKaushikxakauxaseushikvaetwad0xawbKaxakaaxasaavaeswad1ypBxawaKxakaKxasaKvaetva作{dNode6vac4va成{dNode6vac0wad6ypco{ADHxawb作成xaka成xasa成vaetva業{dNode6vac0wad2ypquxawb作業xaka業xasa業vaetvaっ{dNode6vac0wad6ypVVaBLPxawb作っxakaっxasaっvaetva者{dNode6vac0wad1yprxawb作者xaka者xasa者vaetwad1ypcxawa作xaka作xasa作vaetva何{dNode6vac4va種{dNode6vac0wad1yp`xawc何種類xaka種xasb種類vaetva番{dNode6vac0wad1ypPxawc何番煎xaka番xasb番煎vaetva度{dNode6vac0wad1ypZxawb何度xaka度xasa度vaetvaか{dNode6vac0wad1ypuxawb何かxakaかxasaかvaetwad2ypcMxawa何xaka何xasa何vaetvaG{dNode6vac5vao{dNode6vac0wad1ypcxawfGooglexakaoxaseooglevaetvar{dNode6vac2vaa{dNode6vac3vaa{dNode6vac0wad1ypRxawgGraalVMxakaaxasdalVMvaetvap{dNode6vac0wad1ypXxawhGraphitexakapxasephitevaetvan{dNode6vac0wad1ypoxaweGrantxakanxasbntvaetwad0xawcGraxakaaxasaavaesvae{dNode6vac0wad1ypdxaweGreatxakaexasceatvaetwad0xawbGrxakarxasarvaesvai{dNode6vac2vaH{dNode6vac0wad1ypjxawfGitHubxakaHxascHubvaetvah{dNode6vac0wad2ypX|xawfGithubxakahxaschubvaetwad0xawcGitxakaixasbitvaesvaA{dNode6vac0wad2ypWXxawbGAxakaAxasaAvaetvaO{dNode6vac0wad1ypfxawdGOTOxakaOxascOTOvaetwad1ypRxawaGxakaGxasaGvaetva影{dNode6vac0wad2ypduxawb影響xaka影xasb影響vaetva集{dNode6vac2vaま{dNode6vac0wad1ypdxawc集まっxakaまxasbまっvaetvaめ{dNode6vac0wad1ypkxawb集めxakaめxasaめvaetwad0xawa集xaka集xasa集vaesva勉{dNode6vac2va会{dNode6vac3vaメ{dNode6vac0wad1yphxawe勉強会メモxakaメxasbメモvaetva開{dNode6vac0wad1ypCxawe勉強会開催xaka開xasb開催vaetvaロ{dNode6vac0wad1ypYxawe勉強会ログxakaロxasbログvaetwad<ypdmsttccpw[ffmww~DFG`ilQWW\_bdj{F>xawc勉強会xaka会xasa会vaetva中{dNode6vac0wad1yptxawc勉強中xaka中xasa中vaetwad3yp_k]xawb勉強xaka勉xasb勉強vaetva以{dNode6vac5va上{dNode6vac2va開{dNode6vac0wad1ypdxawd以上開催xaka開xasb開催vaetva前{dNode6vac0wad1ypNxawc以上前xaka前xasa前vaetwad2ypE\xawb以上xaka上xasa上vaetva降{dNode6vac0wad2ypXxawb以降xaka降xasa降vaetva前{dNode6vac0wad7ypGxtJfFKxawb以前xaka前xasa前vaetva外{dNode6vac0wad5ypcpwaixawb以外xaka外xasa外vaetva下{dNode6vac0wad6yp|IJyIPxawb以下xaka下xasa下vaetwad0xawa以xaka以xasa以vaesvaO{dNode6vac5vaD{dNode6vac0wad2ypeexaweODataxakaDxasdDatavaetvac{dNode6vac0wad2ypgXxawiOctopressxakacxashctopressvaetvaS{dNode6vac1vaS{dNode6vac0wad1yplxawcOSSxakaSxasaSvaetwad1ypkxawbOSxakaSxasaSvaetvaN{dNode6vac0wad1yprxawbONxakaNxasaNvaetvap{dNode6vac0wad1ypbxawiOperationxakapxashperationvaetwad0xawaOxakaOxasaOvaesva式{dNode6vac0wad1ypexawa式xaka式xasa式vaetva条{dNode6vac0wad2ypeexawb条件xaka条xasb条件vaetva${dNode6vac0wad2ypeexawa$xaka$xasa$vaetvaソ{dNode6vac3vaー{dNode6vac2vaト{dNode6vac0wad1ypexawcソートxakaトxasaトvaetvaス{dNode6vac2va眺{dNode6vac0wad1ypRxaweソース眺めxaka眺xasb眺めvaetvaコ{dNode6vac0wad1yphxawlソースコードリーディングxakaコxasiコードリーディングvaetwad5ypFGQQQxawcソースxakaスxasaスvaetwad1yp|xawbソーxakaーxasaーvaetvaフ{dNode6vac0wad2yppsxawcソフトxakaフxasbフトvaetvaニ{dNode6vac0wad1yp\xawcソニーxakaニxasbニーvaetwad0xawaソxakaソxasaソvaesva自{dNode6vac8va宅{dNode6vac1va環{dNode6vac0wad1ypuxawd自宅環境xaka環xasb環境vaetwad3ypfquxawb自宅xaka宅xasa宅vaetva作{dNode6vac0wad3ypkqrxawb自作xaka作xasa作vaetva分{dNode6vac1va用{dNode6vac0wad;yp|ABFNQSUmh{xawc自分用xaka用xasa用vaetwad6ypvTjI]Sxawb自分xaka分xasa分vaetva体{dNode6vac0wad1ypxawb自体xaka体xasa体vaetva然{dNode6vac1va特{dNode6vac0wad1yp@xawh自然言語処理特集xaka特xasb特集vaetwad3ypPPGxawf自然言語処理xaka然xase然言語処理vaetva転{dNode6vac0wad1ypWxawd自転車本xaka転xasc転車本vaetva己{dNode6vac1va紹{dNode6vac0wad1yp]xawd自己紹介xaka紹xasb紹介vaetwad1ypIxawb自己xaka己xasa己vaetva信{dNode6vac0wad1yppxawb自信xaka信xasa信vaetwad0xawa自xaka自xasa自vaesva更{dNode6vac1va版{dNode6vac0wad4ypfuGGxawc更新版xaka版xasa版vaetwad6ypLgdSvExawb更新xaka更xasb更新vaetva({dNode6vac1va){dNode6vac0wad1yp~xawb()xaka)xasa)vaetwad<ypffkmnqsDDEITVX]]]]]acccccdddddeeeeeffffovwEJR|BNorfvvF\J>xawa(xaka(xasa(vaetva){dNode6vac0wad<ypffkmnqsDEITV]]]]accccddddeeeeeffffovwEJR|BNorfvvF\>xawa)xaka)xasa)vaetva挙{dNode6vac0wad1ypgxawb挙動xaka挙xasb挙動vaetvaロ{dNode6vac2vaグ{dNode6vac0wad3ypgNkxawbログxakaグxasaグvaetvaー{dNode6vac0wad1yp]xawdローカルxakaーxascーカルvaetwad1ypPxawaロxakaロxasaロvaetva原{dNode6vac3va著{dNode6vac0wad1yphxawb原著xaka著xasa著vaetva文{dNode6vac0wad<ypVWXYZ[[\]^_abdeiklmoqsuvyz~BCEILOR>xawb原文xaka文xasa文vaetva本{dNode6vac0wad1ypmxawb原本xaka本xasa本vaetwad0xawa原xaka原xasa原vaesvaじ{dNode6vac2vaめ{dNode6vac2vaま{dNode6vac1vaて{dNode6vac0wad1ypnxaweじめましてxakaてxasaてvaetwad3ypHY[xawdじめましxakaまxasbましvaetvaる{dNode6vac0wad2yp_Vxawcじめるxakaるxasaるvaetwad0xawbじめxakaめxasaめvaesvaま{dNode6vac0wad1ypvxaweじまりましxakaまxasdまりましvaetwad5yphLXMPxawaじxakaじxasaじvaetvaゃ{dNode6vac0wad2yphXxawaゃxakaゃxasaゃvaetva数{dNode6vac4va字{dNode6vac0wad1ypixawb数字xaka字xasa字vaetva回{dNode6vac0wad1ypyxawb数回xaka回xasa回vaetva年{dNode6vac0wad1yp|xawb数年xaka年xasa年vaetva日{dNode6vac0wad1ypuxawc数日前xaka日xasb日前vaetwad0xawa数xaka数xasa数vaesva下{dNode6vac2va記{dNode6vac0wad1ypjxawb下記xaka記xasa記vaetva部{dNode6vac0wad1ypvxawb下部xaka部xasa部vaetwad0xawa下xaka下xasa下vaesvaサ{dNode6vac6vaン{dNode6vac3vaワ{dNode6vac0wad1ypjxawgサンワサプライxakaワxaseワサプライvaetvaフ{dNode6vac0wad1yprxawhサンフランシスコxakaフxasfフランシスコvaetvaプ{dNode6vac0wad2yp]Hxawdサンプルxakaプxasbプルvaetwad0xawbサンxakaンxasaンvaesvaイ{dNode6vac2vaト{dNode6vac0wad7yppFFvyCIxawcサイトxakaトxasaトvaetvaン{dNode6vac0wad1ypbxawcサインxakaンxasaンvaetwad0xawbサイxakaイxasaイvaesvaボ{dNode6vac0wad1ypBxawbサボxakaボxasaボvaetvaー{dNode6vac2vaビ{dNode6vac0wad5ypFKKmmxawdサービスxakaビxasbビスvaetvaバ{dNode6vac0wad1ypNxawcサーバxakaバxasaバvaetwad0xawbサーxakaーxasaーvaesvaポ{dNode6vac0wad1ypYxawdサポートxakaポxascポートvaetvaム{dNode6vac0wad2ypAUxawfサムライズムxakaムxaseムライズムvaetwad1ypkxawaサxakaサxasaサvaetva接{dNode6vac0wad2ypjjxawb接続xaka接xasb接続vaetvaノ{dNode6vac2vaー{dNode6vac0wad1ypjxawcノートxakaーxasbートvaetvaッ{dNode6vac0wad:ypwxGHIOP}~xawcノックxakaッxasbックvaetwad0xawaノxakaノxasaノvaesvaデ{dNode6vac4vaス{dNode6vac0wad2ypkDxawfデスクトップxakaスxaseスクトップvaetvaィ{dNode6vac0wad1yp{xawfディレクトリxakaィxaseィレクトリvaetvaー{dNode6vac1vaア{dNode6vac0wad1yp_xawfデータアップxakaアxascアップvaetwad6yp{ACVENxawcデータxakaーxasbータvaetvaモ{dNode6vac0wad2ypG]xawbデモxakaモxasaモvaetwad0xawaデxakaデxasaデvaesva貼{dNode6vac1vaっ{dNode6vac0wad1ypkxawb貼っxakaっxasaっvaetwad1ypTxawa貼xaka貼xasa貼vaetva航{dNode6vac0wad1yplxawb航海xaka航xasb航海vaetva者{dNode6vac0wad1yplxawb者版xaka者xasb者版vaetva購{dNode6vac0wad6ypl`vcqVxawb購入xaka購xasb購入vaetva家{dNode6vac1va族{dNode6vac0wad4ypl```xawb家族xaka族xasa族vaetwad2yp^Dxawa家xaka家xasa家vaetva負{dNode6vac2vaけ{dNode6vac0wad1yplxawb負けxakaけxasaけvaetva荷{dNode6vac0wad1ypyxawb負荷xaka荷xasa荷vaetwad0xawa負xaka負xasa負vaesvas{dNode6vac8vat{dNode6vac2vaa{dNode6vac0wad7ypmovwEJKxawestackxakaaxascackvaetvar{dNode6vac0wad1ypIxawcstrxakarxasarvaetwad0xawbstxakatxasatvaesvap{dNode6vac0wad1yp~xawesplitxakapxasdplitvaetvao{dNode6vac0wad1ypexawdsoonxakaoxascoonvaetvam{dNode6vac0wad1yppxawgsmogamixakamxasfmogamivaetvae{dNode6vac3vac{dNode6vac0wad1ypsxawhsecurityxakacxasfcurityvaetvar{dNode6vac0wad1ypWxawfserverxakarxasdrvervaetvaa{dNode6vac0wad1ypaxawfsearchxakaaxasdarchvaetwad0xawbsexakaexasaevaesvah{dNode6vac0wad1ypsxawfshieldxakahxasehieldvaetvac{dNode6vac2var{dNode6vac2vas{dNode6vac0wad1ypyxawgscriptsxakasxasasvaetvai{dNode6vac0wad1ypyxawiscriptingxakaixascingvaetwad0xawfscriptxakarxasdriptvaesvah{dNode6vac0wad2yp}Hxawfschemaxakahxasdhemavaetwad0xawbscxakacxasacvaesvai{dNode6vac0wad1yp@xawdsizexakaixascizevaetwad0xawasxakasxasasvaesva足{dNode6vac1vaり{dNode6vac0wad1ypmxawb足りxakaりxasaりvaetwad1ypaxawa足xaka足xasa足vaetva大{dNode6vac<va谷{dNode6vac0wad1ypnxawb大谷xaka谷xasa谷vaetva体{dNode6vac0wad1yptxawb大体xaka体xasa体vaetva事{dNode6vac0wad1ypUxawb大事xaka事xasa事vaetva好{dNode6vac0wad1yp}xawb大好xaka好xasa好vaetvaき{dNode6vac0wad3yp[dNxawb大きxakaきxasaきvaetva阪{dNode6vac0wad1ypcxawb大阪xaka阪xasa阪vaetvaさ{dNode6vac0wad1yp{xawc大さんxakaさxasbさんvaetva晦{dNode6vac0wad3yp|rhxawc大晦日xaka晦xasb晦日vaetva講{dNode6vac0wad1ypNxawb大講xaka講xasa講vaetva満{dNode6vac0wad1ypkxawc大満足xaka満xasb満足vaetva入{dNode6vac0wad1ypGxawc大入りxaka入xasb入りvaetva画{dNode6vac0wad1ypWxawc大画面xaka画xasb画面vaetva量{dNode6vac0wad1ypgxawb大量xaka量xasa量vaet>wad1ypzxawa大xaka大xasa大vaetvaビ{dNode6vac3vaル{dNode6vac1vaロ{dNode6vac0wad1ypoxaweビルドログxakaロxasbログvaetwad2ypQQxawcビルドxakaルxasbルドvaetvaー{dNode6vac0wad1ypVxawcビールxakaーxasbールvaetvaッ{dNode6vac0wad1ypmxawfビッグデータxakaッxaseッグデータvaetwad0xawaビxakaビxasaビvaesvaヒ{dNode6vac4vaゲ{dNode6vac0wad2yppqxawbヒゲxakaゲxasaゲvaetvaッ{dNode6vac0wad1yptxawcヒットxakaッxasbットvaetvaカ{dNode6vac0wad1ypkxawdヒカリエxakaカxascカリエvaetvaル{dNode6vac0wad1yp\xawcヒルズxakaルxasbルズvaetwad0xawaヒxakaヒxasaヒvaesva不{dNode6vac4va評{dNode6vac0wad2yppqxawb不評xaka評xasa評vaetva安{dNode6vac0wad1ypbxawb不安xaka安xasa安vaetva定{dNode6vac1va開{dNode6vac0wad2yp~Gxawe不定期開催xaka開xasb開催vaetwad1yplxawc不定期xaka定xasb定期vaetva純{dNode6vac0wad1ypkxawb不純xaka純xasa純vaetwad0xawa不xaka不xasa不vaesva通{dNode6vac3vaり{dNode6vac0wad1yppxawb通りxakaりxasaりvaetva訳{dNode6vac0wad1ypkxawb通訳xaka訳xasa訳vaetva勤{dNode6vac0wad1ypxxawb通勤xaka勤xasa勤vaetwad0xawa通xaka通xasa通vaesva切{dNode6vac1vaま{dNode6vac0wad1yppxawd切りましxakaまxasbましvaetwad1yprxawb切りxaka切xasb切りvaetva中{dNode6vac3va身{dNode6vac0wad1ypZxawb中身xaka身xasa身vaetva野{dNode6vac0wad1ypYxawb中野xaka野xasa野vaetva心{dNode6vac0wad2yp`Jxawb中心xaka心xasa心vaetwad4yppzexxawa中xaka中xasa中vaetva伸{dNode6vac2vaび{dNode6vac0wad1ypqxawb伸びxakaびxasaびvaetvaば{dNode6vac0wad1ypqxawe伸ばしてるxakaばxasdばしてるvaetwad0xawa伸xaka伸xasa伸vaesva買{dNode6vac3vaっ{dNode6vac0wad6ypq\aPPRxawb買っxakaっxasaっvaetva収{dNode6vac0wad1ypFxawb買収xaka収xasa収vaetvaお{dNode6vac0wad1ypDxawc買おうxakaおxasbおうvaetwad0xawa買xaka買xasa買vaesvaご{dNode6vac5vaろ{dNode6vac0wad2ypq^xawbごろxakaろxasaろvaetvaめ{dNode6vac0wad1ypHxawcごめんxakaめxasbめんvaetvaく{dNode6vac0wad2ypA@xawbごくxakaくxasaくvaetvaざ{dNode6vac0wad1ypgxaweございますxakaざxasdざいますvaetvaか{dNode6vac0wad1ypxxawcごかっxakaかxasbかっvaetwad3yp[Khxawaごxakaごxasaごvaetva多{dNode6vac0wad1ypqxawb多くxaka多xasb多くvaetva春{dNode6vac2vaく{dNode6vac0wad1yprxawd春くらいxakaくxascくらいvaetva山{dNode6vac0wad1ypFxawb春山xaka山xasa山vaetwad0xawa春xaka春xasa春vaesva@{dNode6vac0wad<ypsTghp]QSSMMWb>xawa@xaka@xasa@vaetvam{dNode6vac3vai{dNode6vac2vao{dNode6vac0wad1ypsxawfminoruxakaoxascoruvaetvai{dNode6vac0wad1ypqxawdminixakaixasaivaetwad0xawcminxakaixasbinvaesvaa{dNode6vac3vat{dNode6vac0wad1ypQxawdmatcxakatxasbtcvaetvac{dNode6vac0wad1ypixawemacOSxakacxasccOSvaetvar{dNode6vac0wad1yp~xawfmarvelxakarxasdrvelvaetwad0xawbmaxakaaxasaavaesvae{dNode6vac2vae{dNode6vac0wad2yppZxawfmeetupxakaexasdetupvaetvac{dNode6vac0wad1ypLxawemecabxakacxasccabvaetwad1yp]xawbmexakaexasaevaetwad0xawamxakamxasamvaesva_{dNode6vac0wad8ypsk~@Qzzzxawa_xaka_xasa_vaetva継{dNode6vac2vaい{dNode6vac0wad2ypsZxawb継いxakaいxasaいvaetva続{dNode6vac1va中{dNode6vac0wad1ypdxawc継続中xaka中xasa中vaetwad2ypuRxawb継続xaka続xasa続vaetwad0xawa継xaka継xasa継vaesvaR{dNode6vac7vau{dNode6vac2vas{dNode6vac1va製{dNode6vac0wad2ypZZxaweRust製xaka製xasa製vaetwad<ypsvvwx|||||AAAAABBBBBFFFFFGHINNNNOQQQSSUWWYYZ[aa}~>xawdRustxakasxasbstvaetvab{dNode6vac1va2{dNode6vac0wad1yp|xawgRuby2日目xaka2xasc2日目vaetwad1ypzxawdRubyxakabxasbbyvaetwad0xawbRuxakauxasauvaesvaE{dNode6vac2vaA{dNode6vac0wad1yp~xawdREADxakaAxasbADvaetvaS{dNode6vac0wad1ypcxawdRESTxakaSxasbSTvaetwad0xawbRExakaExasaEvaesvai{dNode6vac2vao{dNode6vac0wad1ypIxawcRioxakaoxasaovaetvaa{dNode6vac0wad4yp{{JNxawdRiakxakaaxasbakvaetwad0xawbRixakaixasaivaesvae{dNode6vac6val{dNode6vac2vae{dNode6vac0wad5ypWmoqRxawhReleasedxakaexaseeasedvaetvaa{dNode6vac0wad1yp[xawfRelasexakaaxascasevaetwad0xawcRelxakalxasalvaesvaf{dNode6vac0wad1ypdxawkRefactoringxakafxasifactoringvaetvai{dNode6vac0wad1ypkxawgReindexxakaixaseindexvaetvap{dNode6vac0wad1ypuxawjRepositoryxakapxashpositoryvaetvat{dNode6vac0wad2ypvvxawiRetrievalxakatxasgtrievalvaetvaa{dNode6vac0wad1yp|xawfReadmexakaaxasdadmevaetwad0xawbRexakaexasaevaesvaC{dNode6vac0wad2ypO\xawbRCxakaCxasaCvaetvaa{dNode6vac0wad2yp_sxaweRailsxakaaxasdailsvaetvao{dNode6vac2vao{dNode6vac0wad1yp]xawdRoomxakaoxasbomvaetvab{dNode6vac0wad2yp@RxawfRobertxakabxasdbertvaetwad0xawbRoxakaoxasaovaeswad0xawaRxakaRxasaRvaesva先{dNode6vac2va日{dNode6vac0wad<yptzLVNeJgHIMN_y@FH>xawb先日xaka日xasa日vaetva週{dNode6vac1va末{dNode6vac0wad1ypixawc先週末xaka末xasa末vaetwad1yp~xawb先週xaka週xasa週vaetwad2ypWmxawa先xaka先xasa先vaetvaシ{dNode6vac3vaス{dNode6vac0wad6ypttz{_Fxawdシステムxakaスxascステムvaetvaリ{dNode6vac0wad1ypFxawdシリーズxakaリxascリーズvaetvaア{dNode6vac0wad1yp]xawdシアターxakaアxascアターvaetwad0xawaシxakaシxasaシvaesva構{dNode6vac2va成{dNode6vac0wad5ypttJ{Txawb構成xaka成xasa成vaetva造{dNode6vac1va体{dNode6vac0wad1ypSxawc構造体xaka体xasa体vaetwad1ypExawb構造xaka造xasa造vaetwad0xawa構xaka構xasa構vaesva客{dNode6vac0wad5ypuDX^|xawc客さんxaka客xasc客さんvaetva相{dNode6vac0wad1ypuxawb相変xaka相xasb相変vaetvaわ{dNode6vac3vaら{dNode6vac0wad1ypuxawcわらずxakaらxasbらずvaetvaけ{dNode6vac0wad1ypIxawdわけじゃxakaけxascけじゃvaetvaり{dNode6vac0wad1ypSxawbわりxakaりxasaりvaetwad0xawaわxakaわxasaわvaesvaせ{dNode6vac2vaっ{dNode6vac0wad4yp|Da}xawdせっかくxakaっxascっかくvaetvaる{dNode6vac0wad1ypIxawbせるxakaるxasaるvaetwad2ypuBxawaせxakaせxasaせvaetva便{dNode6vac0wad3ypv\Lxawb便利xaka便xasb便利vaetva問{dNode6vac0wad7ypv}~@Mxawb問題xaka問xasb問題vaetva処{dNode6vac0wad:ypvwxGGHIO}~xawb処理xaka処xasb処理vaetva言{dNode6vac4va語{dNode6vac2va処{dNode6vac1va勉{dNode6vac0wad1ypExawg言語処理勉強会xaka勉xasc勉強会vaetwad2ypPxawd言語処理xaka処xasb処理vaetva仕{dNode6vac0wad1ypaxawc言語仕xaka仕xasa仕vaetwad:ypwxGHIO}~r}xawb言語xaka語xasa語vaetvaっ{dNode6vac0wad1ypUxawb言っxakaっxasaっvaetvaい{dNode6vac1vaつ{dNode6vac0wad1ypoxawd言いつつxakaつxasbつつvaetwad2yptNxawb言いxakaいxasaいvaetva葉{dNode6vac0wad1ypixawb言葉xaka葉xasa葉vaetwad0xawa言xaka言xasa言vaesva第{dNode6vac:va1{dNode6vac6va0{dNode6vac0wad1ypjxawd第10回xaka0xasb0回vaetva1{dNode6vac0wad1yp`xawd第11回xaka1xasb1回vaetva3{dNode6vac0wad2ypUmxawd第13回xaka3xasb3回vaetva5{dNode6vac0wad1ypOxawd第15回xaka5xasb5回vaetva6{dNode6vac0wad1ypNxawd第16回xaka6xasb6回vaetva回{dNode6vac0wad1ypAxawc第1回xaka回xasa回vaetwad0xawb第1xaka1xasa1vaesva2{dNode6vac1va目{dNode6vac0wad1yp]xawd第2回目xaka目xasa目vaetwad2yp{yxawc第2回xaka2xasb2回vaetva3{dNode6vac0wad1ypixawc第3回xaka3xasb3回vaetva4{dNode6vac0wad1yp`xawc第4回xaka4xasb4回vaetva5{dNode6vac0wad1ypTxawc第5回xaka5xasb5回vaetva6{dNode6vac0wad1ypMxawc第6回xaka6xasb6回vaetva7{dNode6vac0wad1ypHxawc第7回xaka7xasb7回vaetva8{dNode6vac0wad1ypxxawc第8回xaka8xasb8回vaetva9{dNode6vac0wad2ypnlxawc第9回xaka9xasb9回vaetva一{dNode6vac2va回{dNode6vac0wad1ypjxawc第一回xaka回xasa回vaetva弾{dNode6vac0wad1ypxxawc第一弾xaka弾xasa弾vaetwad0xawb第一xaka一xasa一vaeswad<ypwwx||||AAAABBBBFFFFGHNNNNQQQSSUUttABQc|G~BG`hh{{EJ>xawa第xaka第xasa第vaetva早{dNode6vac2vaめ{dNode6vac0wad1ypwxawb早めxakaめxasaめvaetvaい{dNode6vac0wad3ypRTDxawb早いxakaいxasaいvaetwad0xawa早xaka早xasa早vaesva吾{dNode6vac0wad1ypwxawb吾輩xaka吾xasb吾輩vaetva猫{dNode6vac0wad1ypwxawa猫xaka猫xasa猫vaetva計{dNode6vac0wad1ypyxawb計測xaka計xasb計測vaetva起{dNode6vac3va動{dNode6vac0wad2ypylxawb起動xaka動xasa動vaetva因{dNode6vac0wad1ypfxawb起因xaka因xasa因vaetvaこ{dNode6vac0wad1ypGxawc起こしxakaこxasbこしvaetwad1yp]xawa起xaka起xasa起vaetva停{dNode6vac0wad1ypyxawb停止xaka停xasb停止vaetva楽{dNode6vac1vaし{dNode6vac4vaみ{dNode6vac0wad1yp`xawe楽しみましxakaみxascみましvaetvaく{dNode6vac0wad1ypuxawc楽しくxakaくxasaくvaetvaか{dNode6vac0wad1ypQxawc楽しかxakaかxasaかvaetvaめ{dNode6vac0wad1ypVxawd楽しめるxakaめxasbめるvaetwad1ypbxawb楽しxakaしxasaしvaetwad1ypyxawa楽xaka楽xasa楽vaetva特{dNode6vac3va徴{dNode6vac0wad1ypzxawb特徴xaka徴xasa徴vaetva定{dNode6vac1va文{dNode6vac0wad1ypcxawe特定文字列xaka文xasc文字列vaetwad1ypqxawb特定xaka定xasa定vaetva性{dNode6vac0wad1ypPxawb特性xaka性xasa性vaetwad0xawa特xaka特xasa特vaesvaふ{dNode6vac1vaん{dNode6vac0wad1ypzxawdふんわりxakaんxascんわりvaetwad1ypBxawaふxakaふxasaふvaetva頭{dNode6vac1va痛{dNode6vac0wad1ypVxawb頭痛xaka痛xasa痛vaetwad4ypz{@|xawa頭xaka頭xasa頭vaetvaぼ{dNode6vac0wad1ypzxawdぼんやりxakaぼxasdぼんやりvaetva考{dNode6vac2vaえ{dNode6vac0wad3ypzwqxawb考えxakaえxasaえvaetva慮{dNode6vac0wad1ypFxawc考慮点xaka慮xasb慮点vaetwad1ypVxawa考xaka考xasa考vaetva文{dNode6vac3va章{dNode6vac0wad4ypzWqvxawb文章xaka章xasa章vaetva字{dNode6vac1va通{dNode6vac0wad1ypuxawd文字通りxaka通xasb通りvaetwad1yp}xawb文字xaka字xasa字vaetva体{dNode6vac0wad1ypCxawb文体xaka体xasa体vaetwad0xawa文xaka文xasa文vaesva他{dNode6vac1va愛{dNode6vac0wad1ypAxawb他愛xaka愛xasa愛vaetwad7ypzcdef[axawa他xaka他xasa他vaetva手{dNode6vac3va伝{dNode6vac2vaっ{dNode6vac0wad1ypXxawc手伝っxakaっxasaっvaetvaい{dNode6vac0wad1yp^xawc手伝いxakaいxasaいvaetwad3yp{^pxawb手伝xaka伝xasa伝vaetva元{dNode6vac0wad2yplqxawb手元xaka元xasa元vaetva軽{dNode6vac0wad1ypCxawb手軽xaka軽xasa軽vaetwad0xawa手xaka手xasa手vaesvaば{dNode6vac1vaっ{dNode6vac0wad1ypZxawdばっかりxakaっxascっかりvaetwad8yp{mvR[w[uxawaばxakaばxasaばvaetvaほ{dNode6vac7vaど{dNode6vac0wad4yp{~~Exawbほどxakaどxasaどvaetvaう{dNode6vac0wad2ypOWxawbほうxakaうxasaうvaetvaか{dNode6vac0wad1ypgxawbほかxakaかxasaかvaetvaっ{dNode6vac0wad1yplxawbほっxakaっxasaっvaetvaし{dNode6vac0wad1ypVxawcほしいxakaしxasbしいvaetvaぼ{dNode6vac0wad1yp`xawbほぼxakaぼxasaぼvaetvaん{dNode6vac0wad1yptxawbほんxakaんxasaんvaetwad0xawaほxakaほxasaほvaesva面{dNode6vac0wad7yp{]byFRZxawb面白xaka面xasb面白vaetva週{dNode6vac0wad1yp}xawa週xaka週xasa週vaetva?{dNode6vac0wad6yp}~OSWbxawa?xaka?xasa?vaetvaツ{dNode6vac3vaー{dNode6vac0wad3yp~XXxawcツールxakaーxasbールvaetvaイ{dNode6vac1vaト{dNode6vac0wad;ypP__fsP]_ipsxawdツイートxakaトxasaトvaetwad1yp`xawcツイーxakaイxasbイーvaetvaッ{dNode6vac0wad2yp`zxawdツッコミxakaッxascッコミvaetwad0xawaツxakaツxasaツvaesva誰{dNode6vac0wad1yp~xawb誰得xaka誰xasb誰得vaetva興{dNode6vac1va深{dNode6vac0wad1ypuxawc興味深xaka深xasa深vaetwad9yp~orr[[gmvxawb興味xaka興xasb興味vaetva場{dNode6vac2va合{dNode6vac0wad4yp~@OQxawb場合xaka合xasa合vaetva所{dNode6vac0wad2ypp]xawb場所xaka所xasa所vaetwad0xawa場xaka場xasa場vaesva飛{dNode6vac0wad1yp~xawb飛ばxaka飛xasb飛ばvaetva直{dNode6vac4vaる{dNode6vac0wad1ypxawb直るxakaるxasaるvaetvaし{dNode6vac0wad1ypGxawb直しxakaしxasaしvaetva前{dNode6vac0wad1ypQxawb直前xaka前xasa前vaetva接{dNode6vac0wad1ypYxawd直接業務xaka接xasc接業務vaetwad0xawa直xaka直xasa直vaesva扱{dNode6vac0wad2yp@Mxawb扱うxaka扱xasb扱うvaetva違{dNode6vac0wad2yp@Pxawb違いxaka違xasb違いvaetva送{dNode6vac2va信{dNode6vac0wad1ypCxawb送信xaka信xasa信vaetvaっ{dNode6vac0wad1ypxxawb送っxakaっxasaっvaetwad0xawa送xaka送xasa送vaesva方{dNode6vac5vaや{dNode6vac0wad1ypDxawb方やxakaやxasaやvaetva法{dNode6vac0wad4ypLLAtxawb方法xaka法xasa法vaetva々{dNode6vac0wad5ypGPwwwxawb方々xaka々xasa々vaetvaも{dNode6vac1vaい{dNode6vac0wad1yp~xawd方もいるxakaいxasbいるvaetwad1ypQxawb方もxakaもxasaもvaetvaな{dNode6vac0wad1yplxawc方などxakaなxasbなどvaetwad9ypRP~afgrz|xawa方xaka方xasa方vaetva教{dNode6vac0wad2ypDkxawb教えxaka教xasb教えvaetva触{dNode6vac5vaっ{dNode6vac0wad;ypEnCHNrADbttxawb触っxakaっxasaっvaetva発{dNode6vac0wad1yp@xawb触発xaka発xasa発vaetvaれ{dNode6vac0wad2ypijxawb触れxakaれxasaれvaetvaる{dNode6vac0wad1ypdxawb触るxakaるxasaるvaetvaろ{dNode6vac0wad1ypjxawc触ろうxakaろxasbろうvaetwad0xawa触xaka触xasa触vaesva標{dNode6vac1va入{dNode6vac0wad1ypGxawd標準入力xaka入xasb入力vaetwad1ypixawb標準xaka標xasb標準vaetva受{dNode6vac2vaけ{dNode6vac1vaま{dNode6vac0wad1yphxawd受けましxakaまxasbましvaetwad4ypGtt_xawb受けxakaけxasaけvaetva付{dNode6vac0wad1yprxawc受付用xaka付xasb付用vaetwad0xawa受xaka受xasa受vaesvaヶ{dNode6vac1va月{dNode6vac2vaサ{dNode6vac0wad1ypHxawdヶ月サボxakaサxasbサボvaetvaも{dNode6vac0wad1ypmxawcヶ月もxakaもxasaもvaetwad4ypowEoxawbヶ月xaka月xasa月vaetwad1ypfxawaヶxakaヶxasaヶvaetvaっ{dNode6vac0wad3ypH_Sxawaっxakaっxasaっvaetva暗{dNode6vac0wad1ypIxawc暗号文xaka暗xasc暗号文vaetva&{dNode6vac0wad5ypIpphBxawa&xaka&xasa&vaetvaa{dNode6vac6vam{dNode6vac0wad3ypIppxawcampxakamxasbmpvaetval{dNode6vac0wad1ypvxawcalpxakalxasblpvaetvan{dNode6vac2vad{dNode6vac0wad:yp@WabvzEIvxawcandxakadxasadvaetvaa{dNode6vac2vaz{dNode6vac0wad3ypK|Mxawganalyzexakazxasbzevaetvas{dNode6vac0wad1ypaxawhanalysisxakasxascsisvaetwad0xaweanalyxakaaxascalyvaeswad0xawbanxakanxasanvaesvat{dNode6vac1van{dNode6vac0wad1yp\xawdatndxakanxasbndvaetwad1ypfxawbatxakatxasatvaetvar{dNode6vac0wad1ypcxawcarcxakarxasbrcvaetvau{dNode6vac0wad1yp}xawnautoGeneratePhxakauxasmutoGeneratePhvaetwad1yp_xawaaxakaaxasaavaetva;{dNode6vac0wad5ypIIpphxawa;xaka;xasa;vaetvag{dNode6vac4vat{dNode6vac0wad1ypIxawbgtxakatxasatvaetvar{dNode6vac2vaa{dNode6vac0wad2yp}}xawdgramxakaaxasbamvaetvao{dNode6vac0wad1ypyxawfgroovyxakaoxasdoovyvaetwad0xawbgrxakarxasarvaesvao{dNode6vac2vae{dNode6vac2vas{dNode6vac0wad1ypsxawdgoesxakasxasasvaetvan{dNode6vac0wad1ypwxawdgoenxakanxasanvaetwad0xawcgoexakaexasaevaesvas{dNode6vac0wad<ypoYzAENNOOXX_`cnqAAHLNOP>xawegosenxakasxascsenvaetwad0xawbgoxakaoxasaovaesvaa{dNode6vac0wad1ypsxawbgaxakaaxasaavaetwad0xawagxakagxasagvaesva要{dNode6vac2va素{dNode6vac0wad1ypJxawb要素xaka素xasa素vaetva望{dNode6vac0wad1ypMxawb要望xaka望xasa望vaetwad0xawa要xaka要xasa要vaesva説{dNode6vac1va明{dNode6vac0wad3ypJIPxawb説明xaka明xasa明vaetwad1ypFxawa説xaka説xasa説vaetva社{dNode6vac0wad1ypKxawa社xaka社xasa社vaetva呼{dNode6vac2vaん{dNode6vac0wad1ypKxawb呼んxakaんxasaんvaetvaべ{dNode6vac0wad1ypkxawb呼べxakaべxasaべvaetwad0xawa呼xaka呼xasa呼vaesva製{dNode6vac1va名{dNode6vac0wad1ypKxawc製品名xaka名xasa名vaetwad3ypKj]xawb製品xaka製xasb製品vaetva辞{dNode6vac0wad:ypLLLM@ALPPPxawb辞書xaka辞xasb辞書vaetva設{dNode6vac2va定{dNode6vac0wad6ypLkFO}Bxawb設定xaka定xasa定vaetva計{dNode6vac0wad1ypJxawe設計手法等xaka計xasd計手法等vaetwad0xawa設xaka設xasa設vaesva載{dNode6vac0wad1ypOxawb載せxaka載xasb載せvaetva円{dNode6vac0wad2ypO~xawc円周率xaka円xasc円周率vaetva版{dNode6vac0wad2ypPRxawa版xaka版xasa版vaetva研{dNode6vac0wad1ypPxawb研究xaka研xasb研究vaetva反{dNode6vac0wad1ypPxawb反映xaka反xasb反映vaetva深{dNode6vac0wad1ypPxawb深層xaka深xasb深層vaetvaニ{dNode6vac0wad1ypPxawkニューラルネットワークxakaニxaskニューラルネットワークvaetva過{dNode6vac2va去{dNode6vac0wad1ypRxawb過去xaka去xasa去vaetva熱{dNode6vac0wad1yp~xawb過熱xaka熱xasa熱vaetwad0xawa過xaka過xasa過vaesva御{dNode6vac0wad2ypRCxawb御覧xaka御xasb御覧vaetva勝{dNode6vac0wad1ypSxawd勝手知っxaka勝xasd勝手知っvaetva在{dNode6vac0wad1ypTxawf在宅勤務環境xaka在xasf在宅勤務環境vaetva基{dNode6vac3va本{dNode6vac0wad2ypXPxawb基本xaka本xasa本vaetva調{dNode6vac0wad1ypzxawb基調xaka調xasa調vaetva礎{dNode6vac0wad1ypexawb基礎xaka礎xasa礎vaetwad0xawa基xaka基xasa基vaesva的{dNode6vac0wad5ypXYLefxawa的xaka的xasa的vaetvaナ{dNode6vac1vaト{dNode6vac2vaセ{dNode6vac0wad1ypzxawgナイトセミナーxakaセxasdセミナーvaetva・{dNode6vac0wad1yp@xawhナイト・セミナーxaka・xase・セミナーvaetwad0xawcナイトxakaトxasaトvaeswad1ypXxawbナイxakaナxasbナイvaetva初{dNode6vac6va心{dNode6vac0wad2ypZGxawc初心者xaka心xasb心者vaetvaだ{dNode6vac0wad1ypfxawb初だxakaだxasaだvaetvaめ{dNode6vac0wad2ypgGxawb初めxakaめxasaめvaetva記{dNode6vac0wad1ypMxawc初記事xaka記xasb記事vaetva目{dNode6vac0wad1ypmxawc初目黒xaka目xasb目黒vaetvaA{dNode6vac0wad1ypmxawg初AmazonxakaAxasfAmazonvaetwad8ypprrwYfnjxawa初xaka初xasa初vaetva|{dNode6vac0wad1yp\xawa|xaka|xasa|vaetva={dNode6vac0wad2yp^Yxawa=xaka=xasa=vaetva交{dNode6vac0wad1yp`xawb交えxaka交xasb交えvaetva去{dNode6vac0wad6ypahuCIRxawb去年xaka去xasb去年vaetva積{dNode6vac2vaん{dNode6vac0wad1ypaxawb積んxakaんxasaんvaetva読{dNode6vac0wad1yp}xawd積読状態xaka読xasc読状態vaetwad0xawa積xaka積xasa積vaesva[{dNode6vac0wad1ypaxawa[xaka[xasa[vaetva退{dNode6vac2va職{dNode6vac1va日{dNode6vac0wad1ypmxawc退職日xaka日xasa日vaetwad2ypbVxawb退職xaka職xasa職vaetva化{dNode6vac0wad1yp@xawb退化xaka化xasa化vaetwad0xawa退xaka退xasa退vaesva状{dNode6vac2va況{dNode6vac0wad2ypb^xawb状況xaka況xasa況vaetva態{dNode6vac0wad1yp{xawb状態xaka態xasa態vaetwad0xawa状xaka状xasa状vaesva留{dNode6vac0wad1ypbxawb留めxaka留xasb留めvaetva結{dNode6vac2va論{dNode6vac0wad1ypbxawb結論xaka論xasa論vaetva構{dNode6vac1va前{dNode6vac0wad1yp}xawc結構前xaka前xasa前vaetwad4ypGQz}xawb結構xaka構xasa構vaetwad0xawa結xaka結xasa結vaesva元{dNode6vac1vaに{dNode6vac0wad1ypWxawb元にxakaにxasaにvaetwad8yphuCIRKL]xawa元xaka元xasa元vaetva普{dNode6vac0wad3ypirdxawb普段xaka普xasb普段vaetvae{dNode6vac6vam{dNode6vac0wad1ypjxaweemacsxakamxasdmacsvaetvav{dNode6vac1vas{dNode6vac0wad1yp\xawfeventsxakasxasasvaetwad1yppxaweeventxakavxasdventvaetval{dNode6vac1vas{dNode6vac1vae{dNode6vac1vah{dNode6vac0wad<ypvzEIKLO]^acdfhh|>xawmelasticsearchxakahxasahvaetwad1yphxawlelasticsearcxakaexasdearcvaetwad1ypNxawhelasticsxakasxasasvaetwad2ypraxawgelasticxakalxasflasticvaetvax{dNode6vac2vac{dNode6vac0wad1ypBxawhexcitingxakacxasfcitingvaetvat{dNode6vac0wad2ypK|xawhextendedxakatxasftendedvaetwad0xawbexxakaxxasaxvaesvac{dNode6vac0wad1ypBxawiecosystemxakacxashcosystemvaetvad{dNode6vac0wad1ypWxawgeditionxakadxasfditionvaetwad0xawaexakaexasaevaesva越{dNode6vac0wad1ypjxawb越すxaka越xasb越すvaetva管{dNode6vac0wad2ypjtxawb管理xaka管xasb管理vaetva有{dNode6vac0wad1ypmxawd有休消化xaka有xasd有休消化vaetva質{dNode6vac1va問{dNode6vac0wad4ypttD_xawb質問xaka問xasa問vaetwad1ypnxawa質xaka質xasa質vaetva高{dNode6vac0wad1ypnxawb高いxaka高xasb高いvaetva頂{dNode6vac2vaく{dNode6vac0wad1ypnxawb頂くxakaくxasaくvaetvaい{dNode6vac0wad2ypqOxawb頂いxakaいxasaいvaetwad0xawa頂xaka頂xasa頂vaesva毎{dNode6vac2va年{dNode6vac0wad1ypoxawb毎年xaka年xasa年vaetva月{dNode6vac0wad1ypyxawd毎月開催xaka月xasc月開催vaetwad0xawa毎xaka毎xasa毎vaesva恒{dNode6vac0wad1ypoxawb恒例xaka恒xasb恒例vaetva#{dNode6vac1va#{dNode6vac0wad1ypnxawb##xaka#xasa#vaetwad<yppp|ghhm{JjtzzzeE>xawa#xaka#xasa#vaetva枠{dNode6vac0wad2yppoxawa枠xaka枠xasa枠vaetvaY{dNode6vac2vaa{dNode6vac0wad2ypp]xaweYahooxakaaxasdahoovaetvao{dNode6vac0wad3yp{IJxawhYokozunaxakaoxasgokozunavaetwad0xawaYxakaYxasaYvaesva!{dNode6vac0wad5yppDJekxawa!xaka!xasa!vaetvah{dNode6vac5vat{dNode6vac1vas{dNode6vac0wad1yppxawehttpsxakasxasasvaetwad2ypy\xawdhttpxakatxascttpvaetvaa{dNode6vac3vap{dNode6vac0wad1yp@xawehappyxakapxascppyvaetvav{dNode6vac0wad1yp[xawdhavexakavxasbvevaetvar{dNode6vac1vaa{dNode6vac0wad1ypMxawhharuyamaxakaaxascamavaetwad1ypxaweharuyxakarxascruyvaetwad0xawbhaxakaaxasaavaesvae{dNode6vac1va気{dNode6vac0wad1yp_xawgheroku気xaka気xasa気vaetwad1ypGxawfherokuxakaexaseerokuvaetvai{dNode6vac0wad1ypMxawfhideakxakaixaseideakvaetvao{dNode6vac0wad1yp~xawhhomebrewxakaoxasgomebrewvaetwad0xawahxakahxasahvaesvay{dNode6vac4vaj{dNode6vac1vab{dNode6vac0wad1yppxawiyjbonfirexakabxasgbonfirevaetwad1yppxawbyjxakajxasajvaetvae{dNode6vac0wad1yp@xawdyearxakaexascearvaetvao{dNode6vac0wad2yps]xawcyouxakaoxasbouvaetvau{dNode6vac0wad2ypWbxawgyusukeyxakauxasfusukeyvaetwad0xawayxakayxasayvaesva技{dNode6vac2va書{dNode6vac0wad1ypPxawd技術書読xaka書xasb書読vaetva評{dNode6vac1va様{dNode6vac0wad1ypmxawf技術評論社様xaka様xasa様vaetwad1ypvxawe技術評論社xaka評xasc評論社vaetwad4ypqLPcxawb技術xaka技xasb技術vaetva販{dNode6vac0wad1ypqxawb販売xaka販xasb販売vaetva替{dNode6vac0wad1yprxawb替えxaka替xasb替えvaetvaん{dNode6vac1vaじ{dNode6vac0wad1ypLxawcんじゃxakaじxasbじゃvaetwad8ypss|P_LjExawaんxakaんxasaんvaetva独{dNode6vac0wad1ypsxawb独学xaka独xasb独学vaetvaj{dNode6vac3vao{dNode6vac2vah{dNode6vac0wad3yptQTxawgjohtanixakahxasehtanivaetvai{dNode6vac0wad1ypfxawfjoinedxakaixasdinedvaetwad0xawbjoxakaoxasaovaesvab{dNode6vac0wad1ypjxawejbugjxakabxasdbugjvaetvaa{dNode6vac0wad6ypwA@AAHxawcjarxakaaxasbarvaetwad0xawajxakajxasajvaesva運{dNode6vac2va営{dNode6vac0wad2yptwxawb運営xaka営xasa営vaetva用{dNode6vac0wad1ypbxawb運用xaka用xasa用vaetwad0xawa運xaka運xasa運vaesva英{dNode6vac2va語{dNode6vac1va力{dNode6vac0wad1ypuxawc英語力xaka力xasa力vaetwad5ypuRkVVxawb英語xaka語xasa語vaetva単{dNode6vac0wad1ypMxawc英単語xaka単xasb単語vaetwad0xawa英xaka英xasa英vaesva＆{dNode6vac0wad2ypu[xawa＆xaka＆xasa＆vaetva！{dNode6vac0wad<ypvv@NNPjyyGH``l>xawa！xaka！xasa！vaetva来{dNode6vac3va年{dNode6vac0wad3ypv}axawb来年xaka年xasa年vaetvaる{dNode6vac0wad1ypwxawb来るxakaるxasaるvaetvaま{dNode6vac1vaし{dNode6vac0wad6ypNSdrjkxawc来ましxakaしxasaしvaetwad1ypexawb来まxakaまxasaまvaetwad2ypgUxawa来xaka来xasa来vaetva忘{dNode6vac0wad3ypv_Gxawb忘れxaka忘xasb忘れvaetvaず{dNode6vac2vaー{dNode6vac0wad1ypSxawbずーxakaーxasaーvaetvaっ{dNode6vac0wad1ypmxawbずっxakaっxasaっvaetwad4ypvhmxxawaずxakaずxasaずvaetva遅{dNode6vac4vaれ{dNode6vac0wad1ypwxawb遅れxakaれxasaれvaetvaく{dNode6vac0wad4ypTvuExawb遅くxakaくxasaくvaetva刻{dNode6vac0wad2yp``xawd遅刻厳禁xaka刻xasc刻厳禁vaetva延{dNode6vac0wad1ypNxawb遅延xaka延xasa延vaetwad0xawa遅xaka遅xasa遅vaesva転{dNode6vac0wad4ypxxUUxawb転職xaka転xasb転職vaetva持{dNode6vac2vaっ{dNode6vac0wad2ypxmxawb持っxakaっxasaっvaetvaち{dNode6vac0wad1ypgxawb持ちxakaちxasaちvaetwad0xawa持xaka持xasa持vaesva会{dNode6vac2va社{dNode6vac0wad2ypxfxawb会社xaka社xasa社vaetva場{dNode6vac1va提{dNode6vac0wad4ypNOU`xawd会場提供xaka提xasb提供vaetwad6ypyyWWZ\xawb会場xaka場xasa場vaetwad1ypwxawa会xaka会xasa会vaetva半{dNode6vac0wad1ypxxawb半年xaka半xasb半年vaetva割{dNode6vac0wad1ypxxawb割合xaka割xasb割合vaetva海{dNode6vac1va自{dNode6vac0wad1ypfxawd海外自体xaka自xasb自体vaetwad5ypxRfggxawb海外xaka海xasb海外vaetvaへ{dNode6vac1vaん{dNode6vac0wad2yphIxawbへんxakaんxasaんvaetwad6ypxvUlyIxawaへxakaへxasaへvaetva借{dNode6vac0wad2ypyPxawb借りxaka借xasb借りvaetva募{dNode6vac0wad1ypyxawb募集xaka募xasb募集vaetva補{dNode6vac0wad1ypzxawb補足xaka補xasb補足vaetva久{dNode6vac2va々{dNode6vac0wad<ypzGHPPCbi}AXps>xawb久々xaka々xasa々vaetvaし{dNode6vac0wad4ypLJdaxawb久しxakaしxasaしvaetwad0xawa久xaka久xasa久vaesva流{dNode6vac3vaれ{dNode6vac0wad7yp{LnUVtKxawb流れxakaれxasaれvaetvaし{dNode6vac0wad2yp[Kxawb流しxakaしxasaしvaetva行{dNode6vac1vaり{dNode6vac0wad1ypmxawc流行りxakaりxasaりvaetwad1yp^xawb流行xaka行xasa行vaetwad1ypVxawa流xaka流xasa流vaetva色{dNode6vac1va入{dNode6vac0wad1ypsxawc色々入xaka入xasa入vaetwad4yp|Vq`xawb色々xaka色xasb色々vaetvan{dNode6vac3vae{dNode6vac0wad2yp@@xawcnewxakaexasbewvaetvao{dNode6vac0wad1yp_xawcnowxakaoxasbowvaetvaa{dNode6vac0wad1ypMxawenaistxakaaxasdaistvaetwad2yp}}xawanxakanxasanvaetva単{dNode6vac0wad3yp}qMxawb単語xaka単xasb単語vaetva分{dNode6vac4va割{dNode6vac0wad1yp~xawb分割xaka割xasa割vaetva析{dNode6vac0wad1ypsxawb分析xaka析xasa析vaetva離{dNode6vac0wad1yp@xawb分離xaka離xasa離vaetva散{dNode6vac0wad1ypJxawb分散xaka散xasa散vaetwad0xawa分xaka分xasa分vaesva鉄{dNode6vac0wad2yp{xawa鉄xaka鉄xasa鉄vaetva熱{dNode6vac0wad2yp{xawd熱いうちxaka熱xasd熱いうちvaetva打{dNode6vac0wad2yp{xawb打てxaka打xasb打てvaetva効{dNode6vac0wad1ypxawb効率xaka効xasb効率vaetvak{dNode6vac4vaa{dNode6vac0wad1yp@xawikatsyoshixakaaxashatsyoshivaetvan{dNode6vac0wad1ypsxawdknowxakanxascnowvaetvai{dNode6vac0wad1ypuxawfkibanaxakaixaseibanavaetvao{dNode6vac2vap{dNode6vac0wad4yp^_acxawdkopfxakapxasbpfvaetvab{dNode6vac0wad1ypQxawikobayashixakabxasgbayashivaetwad1ypdxawbkoxakaoxasaovaetwad0xawakxakakxasakvaesva順{dNode6vac1va不{dNode6vac0wad1ypCxawc順不同xaka不xasb不同vaetwad1ypAxawa順xaka順xasa順vaetvaり{dNode6vac0wad1ypBxawaりxakaりxasaりvaetva復{dNode6vac2va活{dNode6vac0wad1ypBxawb復活xaka活xasa活vaetva帰{dNode6vac0wad1ypExawb復帰xaka帰xasa帰vaetwad0xawa復xaka復xasa復vaesva行{dNode6vac2vaっ{dNode6vac0wad<ypChhNQSkrsNTjkw>xawb行っxakaっxasaっvaetvaき{dNode6vac0wad1ypSxawb行きxakaきxasaきvaetwad0xawa行xaka行xasa行vaesva内{dNode6vac4va検{dNode6vac0wad2ypFFxawc内検索xaka検xasb検索vaetva容{dNode6vac0wad5ypsp|@lxawb内容xaka容xasa容vaetva緒{dNode6vac0wad2ypH|xawb内緒xaka緒xasa緒vaetva部{dNode6vac0wad1yp]xawb内部xaka部xasa部vaetwad1yp\xawa内xaka内xasa内vaetva：{dNode6vac0wad<ypFVWXYZ[\]^_abdeiklmoqsuvyz~BCEILOR]]sRR>xawa：xaka：xasa：vaetva執{dNode6vac1va者{dNode6vac0wad1ypNxawc執筆者xaka者xasa者vaetwad3ypGPwxawb執筆xaka執xasb執筆vaetva主{dNode6vac1va催{dNode6vac1va者{dNode6vac0wad1yplxawc主催者xaka者xasa者vaetwad5ypH~BGjxawb主催xaka催xasa催vaetwad2ypK{xawa主xaka主xasa主vaetva超{dNode6vac0wad1ypHxawb超えxaka超xasb超えvaetva課{dNode6vac0wad1ypHxawb課題xaka課xasb課題vaetva悩{dNode6vac0wad2ypHdxawb悩みxaka悩xasb悩みvaetva{dNode6vac0wad1ypIxawaxakaxasavaetvaぶ{dNode6vac1vaく{dNode6vac0wad1yp}xaweぶりくらいxakaくxascくらいvaetwad6ypLJd~aDxawbぶりxakaぶxasbぶりvaetva物{dNode6vac1va理{dNode6vac1va的{dNode6vac0wad1yp\xawc物理的xaka的xasa的vaetwad1ypfxawb物理xaka理xasa理vaetwad2ypMVxawa物xaka物xasa物vaetva壊{dNode6vac1vaる{dNode6vac0wad1ypMxawc壊れるxakaるxasaるvaetwad2ypMMxawb壊れxaka壊xasb壊れvaetva厄{dNode6vac0wad1ypMxawb厄年xaka厄xasb厄年vaetva腕{dNode6vac0wad1ypMxawc腕時計xaka腕xasc腕時計vaetva電{dNode6vac3va波{dNode6vac0wad1ypMxawd電波腕時xaka波xasc波腕時vaetva子{dNode6vac3va版{dNode6vac0wad2ypeexawc電子版xaka版xasa版vaetva化{dNode6vac0wad1ypmxawc電子化xaka化xasa化vaetva書{dNode6vac0wad1ypmxawd電子書籍xaka書xasb書籍vaetwad2ypvvxawb電子xaka子xasa子vaetva源{dNode6vac0wad1ypExawb電源xaka源xasa源vaetwad0xawa電xaka電xasa電vaesva皆{dNode6vac3vaさ{dNode6vac0wad<ypNNOOQUU``jjnnxxHHMMG>xawc皆さんxakaさxasbさんvaetva勤{dNode6vac0wad4yplxd{xawc皆勤賞xaka勤xasb勤賞vaetva様{dNode6vac0wad1ypOxawb皆様xaka様xasa様vaetwad1ypQxawa皆xaka皆xasa皆vaetva監{dNode6vac0wad1ypPxawb監修xaka監xasb監修vaetva師{dNode6vac0wad2ypTDxawb師走xaka師xasb師走vaetva※{dNode6vac0wad<ypVWXYZ[[\]^_abdeiklmoqsuvyz~BCEILjlp>xawa※xaka※xasa※vaetva翻{dNode6vac0wad<ypVWXYZ[\]^_abdeiklmoqsuvyz~BCEIJLRWe>xawb翻訳xaka翻xasb翻訳vaetva誕{dNode6vac0wad1ypVxawb誕生xaka誕xasb誕生vaetva同{dNode6vac2va様{dNode6vac0wad1ypVxawb同様xaka様xasa様vaetva梱{dNode6vac0wad1ypAxawb同梱xaka梱xasa梱vaetwad0xawa同xaka同xasa同vaesva飲{dNode6vac2vaみ{dNode6vac0wad2ypVsxawb飲みxakaみxasaみvaetvaん{dNode6vac0wad2yp|Axawb飲んxakaんxasaんvaetwad0xawa飲xaka飲xasa飲vaesva,{dNode6vac0wad8ypWWX[sYY]xawa,xaka,xasa,vaetvar{dNode6vac4vae{dNode6vac2val{dNode6vac1vae{dNode6vac0wad<ypXYZ\^abivz~CEIL>xawhreleasedxakaexasbedvaetwad1ypsxawfreleasxakalxasdleasvaetvas{dNode6vac0wad1ypcxawdrestxakasxasbstvaetwad0xawbrexakaexasaevaesvau{dNode6vac0wad1ypyxawgrunningxakauxasfunningvaetvai{dNode6vac0wad1yp@xaweriverxakaixasdivervaetvay{dNode6vac1vau{dNode6vac0wad1ypQxawcryuxakauxasauvaetwad1ypSxawbryxakayxasayvaetwad0xawarxakarxasarvaesva+{dNode6vac0wad2ypYlxawa+xaka+xasa+vaetva�{dNode6vac0wad1ypYxawb💚xaka�xasb💚vaetva画{dNode6vac2va像{dNode6vac0wad2yp[jxawb画像xaka像xasa像vaetva面{dNode6vac0wad5yp^acctxawb画面xaka面xasa面vaetwad0xawa画xaka画xasa画vaesva覧{dNode6vac0wad1yp[xawb覧くxaka覧xasb覧くvaetvau{dNode6vac2van{dNode6vac0wad1yp]xawiunpluggedxakanxashnpluggedvaetvap{dNode6vac0wad1ypuxawfupdatexakapxasepdatevaetwad0xawauxakauxasauvaesva東{dNode6vac0wad5ypcptw@xawb東京xaka東xasb東京vaetva京{dNode6vac0wad1ypcxawa京xaka京xasa京vaetvaユ{dNode6vac1vaー{dNode6vac3vaカ{dNode6vac0wad1yprxawjユーザカンファレンスxakaカxasgカンファレンスvaetvaガ{dNode6vac0wad1ypRxawfユーザガイドxakaガxascガイドvaetvaー{dNode6vac0wad1ypjxawhユーザーグループxakaーxaseーグループvaetwad3ypdawxawcユーザxakaーxasbーザvaetwad1yprxawaユxakaユxasaユvaetva準{dNode6vac0wad1ypexawb準備xaka準xasb準備vaetva月{dNode6vac0wad1ypfxawb月前xaka月xasb月前vaetva素{dNode6vac0wad1ypfxawb素晴xaka素xasb素晴vaetva彼{dNode6vac0wad1ypfxawb彼らxaka彼xasb彼らvaetvaジ{dNode6vac0wad2ypggxawhジャストシステムxakaジxashジャストシステムvaetvaひ{dNode6vac2vaさ{dNode6vac0wad4yph[fAxawdひさびさxakaさxascさびさvaetvaど{dNode6vac0wad1ypxxawcひどいxakaどxasbどいvaetwad0xawaひxakaひxasaひvaesva近{dNode6vac2va寄{dNode6vac0wad1yphxawb近寄xaka寄xasa寄vaetvaく{dNode6vac0wad1ypHxawb近くxakaくxasaくvaetwad0xawa近xaka近xasa近vaesva街{dNode6vac0wad1yphxawa街xaka街xasa街vaetva企{dNode6vac0wad1yppxawb企画xaka企xasb企画vaetva弊{dNode6vac0wad1yprxawc弊社初xaka弊xasc弊社初vaetva{{dNode6vac0wad1yprxawa{xaka{xasa{vaetva}{dNode6vac0wad1yprxawa}xaka}xasa}vaetvaト{dNode6vac1vaニ{dNode6vac0wad1yptxawfトレーニングxakaニxascニングvaetwad1yp|xawcトレーxakaトxascトレーvaetva申{dNode6vac0wad1yptxawb申しxaka申xasb申しvaetva込{dNode6vac3vaみ{dNode6vac1vaす{dNode6vac0wad1yptxawc込みすxakaすxasaすvaetwad1ypixawb込みxakaみxasaみvaetvaむ{dNode6vac0wad1ypVxawb込むxakaむxasaむvaetvaん{dNode6vac0wad1ypHxawb込んxakaんxasaんvaetwad0xawa込xaka込xasa込vaesva抽{dNode6vac0wad1ypuxawc抽象的xaka抽xasc抽象的vaetva精{dNode6vac0wad1ypuxawc精神的xaka精xasc精神的vaetva土{dNode6vac0wad1ypwxawc土曜日xaka土xasc土曜日vaetva午{dNode6vac2va後{dNode6vac0wad2ypwCxawb午後xaka後xasa後vaetva前{dNode6vac0wad1ypzxawc午前中xaka前xasb前中vaetwad0xawa午xaka午xasa午vaesva予{dNode6vac0wad5ypwbCKOxawb予定xaka予xasb予定vaetvad{dNode6vac3vay{dNode6vac0wad1ypyxawgdynamicxakayxasfynamicvaetvao{dNode6vac0wad1ypuxawidocumentsxakaoxashocumentsvaetvai{dNode6vac0wad1ypLxawcdicxakaixasbicvaetwad0xawadxakadxasadvaesva横{dNode6vac0wad2yp{{xawb横浜xaka横xasb横浜vaetva橋{dNode6vac0wad1yp{xawa橋xaka橋xasa橋vaetva乗{dNode6vac0wad2yp{gxawb乗りxaka乗xasb乗りvaetva換{dNode6vac0wad2yp{gxawb換えxaka換xasb換えvaetva意{dNode6vac0wad1yp}xawb意味xaka意xasb意味vaetva】{dNode6vac0wad1yp@xawa】xaka】xasa】vaetva水{dNode6vac0wad1yp@xawa水xaka水xasa水vaetvaペ{dNode6vac2vaジ{dNode6vac0wad4ypCvvvxawcページxakaジxasaジvaetvaス{dNode6vac0wad1yp^xawcペースxakaスxasaスvaetwad0xawbペーxakaペxasbペーvaesvaダ{dNode6vac2vaウ{dNode6vac0wad8ypCEcnHQQxawfダウンロードxakaウxaseウンロードvaetvaメ{dNode6vac0wad1ypoxawgダメエンジニアxakaメxasfメエンジニアvaetwad0xawaダxakaダxasaダvaesva背{dNode6vac0wad1ypJxawb背景xaka背xasb背景vaetva火{dNode6vac0wad1ypNxawa火xaka火xasa火vaetva『{dNode6vac0wad1ypNxawa『xaka『xasa『vaetva収{dNode6vac0wad1ypNxawb収集xaka収xasb収集vaetva〜{dNode6vac0wad1ypNxawa〜xaka〜xasa〜vaetva可{dNode6vac2va視{dNode6vac1va編{dNode6vac0wad1ypNxawd可視化編xaka編xasa編vaetwad2ypXXxawc可視化xaka視xasb視化vaetva能{dNode6vac0wad6ypvEcnPxawb可能xaka能xasa能vaetwad0xawa可xaka可xasa可vaesva』{dNode6vac0wad1ypNxawa』xaka』xasa』vaetva語{dNode6vac0wad1ypNxawb語るxaka語xasb語るvaetva演{dNode6vac0wad1ypNxawb演会xaka演xasb演会vaetva様{dNode6vac1va々{dNode6vac0wad1ypkxawb様々xaka々xasa々vaetwad2ypOwxawa様xaka様xasa様vaetva懲{dNode6vac0wad2ypPexawc懲りずxaka懲xasc懲りずvaetva詳{dNode6vac2vaし{dNode6vac0wad1ypPxawc詳しいxakaしxasbしいvaetva細{dNode6vac0wad1yp[xawb詳細xaka細xasa細vaetwad0xawa詳xaka詳xasa詳vaesva働{dNode6vac0wad1ypQxawb働いxaka働xasb働いvaetva古{dNode6vac2vaく{dNode6vac0wad1ypSxawb古くxakaくxasaくvaetva橋{dNode6vac0wad1yprxawb古橋xaka橋xasa橋vaetwad0xawa古xaka古xasa古vaesva無{dNode6vac4va理{dNode6vac0wad1ypUxawb無理xaka理xasa理vaetvaか{dNode6vac0wad1yp~xawc無かっxakaかxasbかっvaetvaい{dNode6vac0wad1ypHxawb無いxakaいxasaいvaetva事{dNode6vac0wad1yp`xawb無事xaka事xasa事vaetwad0xawa無xaka無xasa無vaesva余{dNode6vac0wad1ypVxawc余裕出xaka余xasc余裕出vaetva明{dNode6vac0wad1ypVxawa明xaka明xasa明vaetva目{dNode6vac4va次{dNode6vac0wad1ypWxawb目次xaka次xasa次vaetva黒{dNode6vac0wad1ypYxawb目黒xaka黒xasa黒vaetva的{dNode6vac0wad1ypbxawb目的xaka的xasa的vaetva玉{dNode6vac0wad1ypNxawb目玉xaka玉xasa玉vaetwad2ypPxxawa目xaka目xasa目vaetva～{dNode6vac0wad2ypYYxawa～xaka～xasa～vaetva｜{dNode6vac0wad1ypZxawa｜xaka｜xasa｜vaetva酔{dNode6vac0wad1yp[xawb酔っxaka酔xasb酔っvaetva払{dNode6vac0wad1yp[xawb払っxaka払xasb払っvaetva想{dNode6vac0wad1yp\xawb想像xaka想xasb想像vaetva薄{dNode6vac0wad1yp\xawc薄かっxaka薄xasc薄かっvaetva３{dNode6vac0wad1yp^xawa３xaka３xasa３vaetva必{dNode6vac0wad2yp_sxawb必要xaka必xasb必要vaetva２{dNode6vac3va年{dNode6vac0wad1ypcxawb２年xaka年xasa年vaetva時{dNode6vac0wad1ypPxawb２時xaka時xasa時vaetva日{dNode6vac0wad1ypExawc２日半xaka日xasb日半vaetwad2ypaBxawa２xaka２xasa２vaetva選{dNode6vac0wad2ypacxawb選択xaka選xasb選択vaetva懇{dNode6vac0wad2ypbJxawc懇親会xaka懇xasc懇親会vaetva旅{dNode6vac0wad1ypdxawc旅行記xaka旅xasc旅行記vaetva幸{dNode6vac2vaせ{dNode6vac0wad1yphxawb幸せxakaせxasaせvaetvaい{dNode6vac0wad1ypxxawb幸いxakaいxasaいvaetwad0xawa幸xaka幸xasa幸vaesva突{dNode6vac0wad1ypjxawb突撃xaka突xasb突撃vaetva隣{dNode6vac0wad1ypjxawa隣xaka隣xasa隣vaetva写{dNode6vac0wad1ypjxawb写真xaka写xasb写真vaetva撮{dNode6vac0wad1ypjxawb撮っxaka撮xasb撮っvaetvaｗ{dNode6vac0wad2ypkbxawaｗxakaｗxasaｗvaetva配{dNode6vac2va布{dNode6vac0wad1ypoxawc配布待xaka布xasb布待vaetva置{dNode6vac0wad1yptxawb配置xaka置xasa置vaetwad0xawa配xaka配xasa配vaesva応{dNode6vac0wad2ypoHxawb応版xaka応xasb応版vaetva頑{dNode6vac0wad1ypqxawc頑張っxaka頑xasc頑張っvaetva所{dNode6vac0wad1ypqxawb所存xaka所xasb所存vaetva挨{dNode6vac0wad1ypqxawb挨拶xaka挨xasb挨拶vaetva進{dNode6vac2va歩{dNode6vac0wad1yprxawb進歩xaka歩xasa歩vaetvaん{dNode6vac0wad1yp~xawb進んxakaんxasaんvaetwad0xawa進xaka進xasa進vaesva辛{dNode6vac0wad1ypuxawb辛いxaka辛xasb辛いvaetvaね{dNode6vac1vaぇ{dNode6vac0wad1ypqxawbねぇxakaぇxasaぇvaetwad1ypuxawaねxakaねxasaねvaetva宣{dNode6vac2va伝{dNode6vac0wad1ypwxawb宣伝xaka伝xasa伝vaetva言{dNode6vac0wad1ypNxawb宣言xaka言xasa言vaetwad0xawa宣xaka宣xasa宣vaesva１{dNode6vac2va０{dNode6vac0wad1ypyxawd１００人xaka０xasc００人vaetva年{dNode6vac0wad1ypSxawb１年xaka年xasa年vaetwad0xawa１xaka１xasa１vaesvaょ{dNode6vac0wad1ypyxawbょっxakaょxasbょっvaetvaび{dNode6vac0wad1ypyxawdびっくりxakaびxasdびっくりvaetva提{dNode6vac0wad1ypyxawb提供xaka提xasb提供vaetva雨{dNode6vac0wad1ypzxawa雨xaka雨xasa雨vaetva講{dNode6vac0wad3ypzSoxawb講演xaka講xasb講演vaetva登{dNode6vac0wad2yp@Axawb登録xaka登xasb登録vaetva件{dNode6vac1va数{dNode6vac0wad1yp@xawb件数xaka数xasa数vaetwad1ypKxawa件xaka件xasa件vaetva資{dNode6vac0wad1ypBxawb資料xaka資xasb資料vaetva喋{dNode6vac0wad1ypBxawb喋っxaka喋xasb喋っvaetva宿{dNode6vac0wad1ypDxawb宿題xaka宿xasb宿題vaetva周{dNode6vac0wad1ypDxawc周りっxaka周xasc周りっvaetvaX{dNode6vac0wad3ypEccxawfXperiaxakaXxasfXperiavaetvaZ{dNode6vac2vao{dNode6vac0wad1ypVxawhZoomdataxakaoxasgoomdatavaetvai{dNode6vac0wad2yp|~xawfZipkinxakaixaseipkinvaetwad2ypEcxawaZxakaZxasaZvaetva故{dNode6vac0wad1ypExawb故障xaka故xasb故障vaetva押{dNode6vac0wad1ypExawb押しxaka押xasb押しvaetva誤{dNode6vac0wad2ypFFxawb誤解xaka誤xasb誤解vaetva認{dNode6vac0wad1ypFxawb認識xaka認xasb認識vaetva離{dNode6vac0wad3ypHcyxawb離れxaka離xasb離れvaetva玉{dNode6vac0wad1ypHxawb玉川xaka玉xasb玉川vaetva点{dNode6vac0wad1ypIxawa点xaka点xasa点vaetva観{dNode6vac0wad1ypIxawb観点xaka観xasb観点vaetva完{dNode6vac0wad1ypIxawb完全xaka完xasb完全vaetva満{dNode6vac2va足{dNode6vac0wad1ypIxawb満足xaka足xasa足vaetva員{dNode6vac0wad1yp`xawb満員xaka員xasa員vaetwad0xawa満xaka満xasa満vaesva経{dNode6vac0wad1ypLxawb経由xaka経xasb経由vaetva眺{dNode6vac0wad1ypLxawb眺めxaka眺xasb眺めvaetvaぐ{dNode6vac0wad1ypMxawcぐらいxakaぐxascぐらいvaetva遊{dNode6vac1vaび{dNode6vac0wad1ypNxawb遊びxakaびxasaびvaetwad1ypTxawa遊xaka遊xasa遊vaetva仰{dNode6vac0wad1ypQxawe仰せつかるxaka仰xase仰せつかるvaetva忙{dNode6vac0wad1ypQxawd忙しかっxaka忙xasd忙しかっvaetvaざ{dNode6vac0wad1ypRxawbざっxakaざxasbざっvaetvaテ{dNode6vac2vaキ{dNode6vac0wad1ypRxawdテキトーxakaキxascキトーvaetvaス{dNode6vac1vaケ{dNode6vac0wad3ypMxawfテストケースxakaケxascケースvaetwad1ypAxawcテストxakaスxasbストvaetwad0xawaテxakaテxasaテvaesva掛{dNode6vac0wad1ypSxawb掛けxaka掛xasb掛けvaetvaモ{dNode6vac2vaジ{dNode6vac0wad2ypTTxaweモジュールxakaジxasdジュールvaetvaデ{dNode6vac2vaレ{dNode6vac0wad1ypexaweモデレータxakaレxascレータvaetvaリ{dNode6vac0wad1ypJxaweモデリングxakaリxascリングvaetwad0xawbモデxakaデxasaデvaeswad0xawaモxakaモxasaモvaesva賑{dNode6vac0wad1ypUxawc賑わっxaka賑xasc賑わっvaetva憧{dNode6vac0wad1ypVxawb憧れxaka憧xasb憧れvaetva慣{dNode6vac0wad1ypWxawb慣れxaka慣xasb慣れvaetva訳{dNode6vac0wad3yp[uvxawb訳しxaka訳xasb訳しvaetva欠{dNode6vac0wad1yp]xawb欠けxaka欠xasb欠けvaetva視{dNode6vac0wad1yp]xawb視点xaka視xasb視点vaetva寒{dNode6vac0wad1yp]xawc寒かっxaka寒xasc寒かっvaetva落{dNode6vac0wad2yp^xawb落ちxaka落xasb落ちvaetva危{dNode6vac0wad1yp^xawc危機感xaka危xasc危機感vaetva軟{dNode6vac0wad3yp_rRxawc軟弱者xaka軟xasc軟弱者vaetvaべ{dNode6vac0wad1yp`xawbべきxakaべxasbべきvaetva盛{dNode6vac0wad1yp`xawb盛況xaka盛xasb盛況vaetva容{dNode6vac0wad1ypcxawc容量不xaka容xasc容量不vaetva金{dNode6vac1va曜{dNode6vac0wad2ypdfxawc金曜日xaka曜xasb曜日vaetwad1ypexawa金xaka金xasa金vaetva担{dNode6vac0wad1ypfxawb担当xaka担xasb担当vaetva急{dNode6vac0wad1ypixawd急遽参戦xaka急xasd急遽参戦vaetva某{dNode6vac0wad1ypixawa某xaka某xasa某vaetva口{dNode6vac0wad2ypjkxawa口xaka口xasa口vaetva綺{dNode6vac0wad2ypkZxawb綺麗xaka綺xasb綺麗vaetvaウ{dNode6vac2vaチ{dNode6vac0wad1ypoxawiウチダスペクトラムxakaチxashチダスペクトラムvaetvaォ{dNode6vac0wad1ypPxawfウォークマンxakaォxaseォークマンvaetwad0xawaウxakaウxasaウvaesva対{dNode6vac2va象{dNode6vac0wad1yppxawb対象xaka象xasa象vaetva応{dNode6vac0wad1ypzxawb対応xaka応xasa応vaetwad0xawa対xaka対xasa対vaesva微{dNode6vac0wad1yppxawb微妙xaka微xasb微妙vaetva外{dNode6vac0wad1yppxawb外れxaka外xasb外れvaetva友{dNode6vac0wad1ypqxawb友人xaka友xasb友人vaetva値{dNode6vac0wad1ypqxawb値打xaka値xasb値打vaetva価{dNode6vac0wad1ypqxawb価格xaka価xasb価格vaetva魅{dNode6vac0wad1yprxawb魅力xaka魅xasb魅力vaetva連{dNode6vac3va携{dNode6vac0wad1ypsxawb連携xaka携xasa携vaetva絡{dNode6vac1va事{dNode6vac0wad1ypOxawd連絡事項xaka事xasb事項vaetwad1ypOxawb連絡xaka絡xasa絡vaetva続{dNode6vac0wad1ypjxawb連続xaka続xasa続vaetwad0xawa連xaka連xasa連vaesva苦{dNode6vac0wad2ypsrxawb苦労xaka苦xasb苦労vaetva欲{dNode6vac0wad1yptxawa欲xaka欲xasa欲vaetva恥{dNode6vac1vaず{dNode6vac2vaげ{dNode6vac0wad1yptxawe恥ずかしげxakaげxasaげvaetvaく{dNode6vac0wad1ypBxawe恥ずかしくxakaくxasaくvaetwad0xawd恥ずかしxakaずxascずかしvaeswad1ypuxawa恥xaka恥xasa恥vaetva偉{dNode6vac0wad1yptxawc偉そうxaka偉xasc偉そうvaetva蒸{dNode6vac0wad1ypvxawb蒸しxaka蒸xasb蒸しvaetva暑{dNode6vac0wad1ypvxawb暑くxaka暑xasb暑くvaetva寝{dNode6vac4vaれ{dNode6vac0wad1ypvxawb寝れxakaれxasaれvaetvaか{dNode6vac1vaし{dNode6vac0wad1ypPxawf寝かしつけさxakaしxasdしつけさvaetwad1ypPxawb寝かxakaかxasaかvaetvaこ{dNode6vac0wad1ypixawc寝こんxakaこxasbこんvaetva込{dNode6vac0wad1ypExawb寝込xaka込xasa込vaetwad0xawa寝xaka寝xasa寝vaesva伴{dNode6vac0wad1ypwxawb伴いxaka伴xasb伴いvaetva勢{dNode6vac0wad1yp{xawb勢いxaka勢xasb勢いvaetva図{dNode6vac0wad1yp{xawa図xaka図xasa図vaetva悪{dNode6vac0wad1yp|xawb悪いxaka悪xasb悪いvaetvax{dNode6vac1vam{dNode6vac0wad2yp}Hxawcxmlxakamxasbmlvaetwad1yp_xawaxxakaxxasaxvaetva木{dNode6vac0wad1yp~xawc木曜日xaka木xasc木曜日vaetvaケ{dNode6vac0wad2yp@fxawcケースxakaケxascケースvaetva兼{dNode6vac0wad2ypD[xawb兼ねxaka兼xasb兼ねvaetva秘{dNode6vac0wad1ypFxawb秘密xaka秘xasb秘密vaetva丸{dNode6vac0wad1ypFxawb丸善xaka丸xasb丸善vaetva―{dNode6vac0wad1ypFxawa―xaka―xasa―vaetva非{dNode6vac0wad1ypFxawb非常xaka非xasb非常vaetva付{dNode6vac0wad1ypFxawb付与xaka付xasb付与vaetva嗅{dNode6vac0wad1ypGxawe嗅ぎつけてxaka嗅xase嗅ぎつけてvaetva各{dNode6vac0wad3ypJyIxawa各xaka各xasa各vaetva子{dNode6vac0wad2ypLPxawb子供xaka子xasb子供vaetva体{dNode6vac0wad1ypLxawb体調xaka体xasb体調vaetva崩{dNode6vac0wad1ypLxawb崩しxaka崩xasb崩しvaetva覚{dNode6vac0wad1ypPxawb覚めxaka覚xasb覚めvaetva回{dNode6vac2va数{dNode6vac0wad1ypQxawb回数xaka数xasa数vaetva答{dNode6vac0wad3yprz|xawb回答xaka答xasa答vaetwad0xawa回xaka回xasa回vaesvaえ{dNode6vac0wad1ypSxawbえーxakaえxasbえーvaetva森{dNode6vac0wad1ypTxawc森ビルxaka森xasc森ビルvaetva矯{dNode6vac0wad1ypTxawb矯正xaka矯xasb矯正vaetva道{dNode6vac0wad1ypUxawa道xaka道xasa道vaetva親{dNode6vac0wad1ypVxawb親子xaka親xasb親子vaetva絵{dNode6vac0wad1ypVxawb絵本xaka絵xasb絵本vaetva身{dNode6vac0wad1ypVxawe身につけてxaka身xase身につけてvaetva異{dNode6vac1vaな{dNode6vac0wad1ypWxawe異なりましxakaなxasdなりましvaetwad1ypxawa異xaka異xasa異vaetva広{dNode6vac0wad1ypWxawb広くxaka広xasb広くvaetva駅{dNode6vac0wad1ypWxawa駅xaka駅xasa駅vaetva嬉{dNode6vac0wad1ypXxawc嬉しくxaka嬉xasc嬉しくvaetva顔{dNode6vac0wad1ypYxawa顔xaka顔xasa顔vaetva役{dNode6vac0wad2ypZuxawa役xaka役xasa役vaetva増{dNode6vac0wad1yp[xawb増えxaka増xasb増えvaetva備{dNode6vac0wad6yp[sBCCGxawc備忘録xaka備xasc備忘録vaetva六{dNode6vac1va本{dNode6vac0wad1yp\xawc六本木xaka本xasb本木vaetwad1yp\xawa六xaka六xasa六vaetva港{dNode6vac0wad1yp\xawb港区xaka港xasb港区vaetva三{dNode6vac0wad1yp]xawb三田xaka三xasb三田vaetva系{dNode6vac0wad2yp]_xawa系xaka系xasa系vaetva陥{dNode6vac0wad1yp^xawb陥っxaka陥xasb陥っvaetva我{dNode6vac0wad1yp^xawa我xaka我xasa我vaetva暇{dNode6vac0wad1ypdxawb暇人xaka暇xasb暇人vaetva部{dNode6vac0wad1ypexawb部分xaka部xasb部分vaetva速{dNode6vac2va読{dNode6vac0wad1ypgxawb速読xaka読xasa読vaetva報{dNode6vac0wad2ypyIxawb速報xaka報xasa報vaetwad0xawa速xaka速xasa速vaesva勤{dNode6vac0wad1ypixawb勤労xaka勤xasb勤労vaetva朝{dNode6vac0wad1ypixawb朝晩xaka朝xasb朝晩vaetva冷{dNode6vac0wad1ypixawb冷えxaka冷xasb冷えvaetva激{dNode6vac0wad1ypixawc激しいxaka激xasc激しいvaetva武{dNode6vac0wad1ypkxawb武田xaka武xasb武田vaetva破{dNode6vac0wad1ypmxawb破棄xaka破xasb破棄vaetva腰{dNode6vac0wad1ypoxawa腰xaka腰xasa腰vaetva重{dNode6vac0wad1ypoxawb重いxaka重xasb重いvaetva探{dNode6vac0wad1ypqxawb探しxaka探xasb探しvaetva痛{dNode6vac0wad1ypuxawb痛感xaka痛xasb痛感vaetva凹{dNode6vac0wad1ypuxawb凹んxaka凹xasb凹んvaetva晒{dNode6vac0wad1ypuxawb晒すxaka晒xasb晒すvaetva疲{dNode6vac0wad1ypwxawb疲れxaka疲xasb疲れvaetva台{dNode6vac0wad1ypxxawb台風xaka台xasb台風vaetva怖{dNode6vac0wad1ypxxawc怖かっxaka怖xasc怖かっvaetvaゆ{dNode6vac0wad1yp}xawdゆっくりxakaゆxasdゆっくりvaetva訪{dNode6vac0wad1yp}xawb訪れxaka訪xasb訪れvaetva消{dNode6vac0wad1yp}xawb消化xaka消xasb消化vaetva世{dNode6vac0wad1yp}xawb世界xaka世xasb世界vaetva着{dNode6vac0wad1ypxawb着いxaka着xasb着いvaetva８{dNode6vac0wad2ypDDxawb８年xaka８xasb８年vaetva帰{dNode6vac0wad1ypExawb帰っxaka帰xasb帰っvaetva耳{dNode6vac0wad1ypFxawa耳xaka耳xasa耳vaetva毛{dNode6vac0wad1ypGxawa毛xaka毛xasa毛vaetva座{dNode6vac0wad1ypJxawc座談会xaka座xasc座談会vaetva未{dNode6vac0wad1ypKxawc未知語xaka未xasc未知語vaetva歴{dNode6vac0wad1ypRxawb歴史xaka歴xasb歴史vaetva移{dNode6vac0wad1ypRxawc移植版xaka移xasc移植版vaetva…{dNode6vac0wad1ypSxawa…xaka…xasa…vaet>wad0xaw`xak`xas`vaesvgisArraysvdtags3xdtypeeRadixvdnode{dNode6vac<va1{dNode6vac0wad;ypwxGHIOP}~@xawc100xaka1xasc100vaetva2{dNode6vac0wad2yph_xawa2xaka2xasa2vaetva4{dNode6vac0wad1ypuxawa4xaka4xasa4vaetvag{dNode6vac1vas{dNode6vac0wad<ypoYnwz@AEMNOX_cinoq@AGHKLMNOPQR>xawegosenxakasxascsenvaetwad1ypQxawbgoxakagxasbgovaetva振{dNode6vac0wad;ypR^ZlhuCIR|rxawb振りxaka振xasb振りvaetva返{dNode6vac0wad;ypR^ZlhuCIR|rxawb返りxaka返xasb返りvaetvao{dNode6vac3var{dNode6vac0wad1ypSxaweoramaxakarxasdramavaetvap{dNode6vac0wad1ypPxawjopensearchxakapxasipensearchvaetvac{dNode6vac0wad3ypglXxawioctopressxakacxashctopressvaetwad0xawaoxakaoxasaovaesvas{dNode6vac4vae{dNode6vac2vaa{dNode6vac1vak{dNode6vac0wad1ypVxawisearchkitxakakxasckitvaetwad<ypSVXY\^aegy@CDJKX^>xawfsearchxakaaxasdarchvaetvan{dNode6vac0wad1ypVxawesensexakanxascnsevaetwad0xawbsexakaexasaevaesvat{dNode6vac3vaa{dNode6vac0wad1ypExawestackxakaaxascackvaetvau{dNode6vac0wad2ypVXxawfstudioxakauxasdudiovaetvar{dNode6vac0wad1yp_xawfstreamxakarxasdreamvaetwad0xawbstxakatxasatvaesvah{dNode6vac0wad2ypWsxawfshieldxakahxasehieldvaetvao{dNode6vac2van{dNode6vac0wad1ypKxawhsonatypexakanxasfnatypevaetval{dNode6vac0wad<yp[\u}HIJltuvyI>xawdsolrxakalxasblrvaetwad0xawbsoxakaoxasaovaeswad0xawasxakasxasasvaesvam{dNode6vac3vai{dNode6vac0wad<ypT_[\]bfijknopqruRTZijkxMAgWXB`akmS>xawdmiscxakaixasciscvaetvau{dNode6vac0wad2ypT_xawemusicxakauxasdusicvaetvaa{dNode6vac0wad4ypW~lnxawfmarvelxakaaxasearvelvaetwad0xawamxakamxasamvaesvab{dNode6vac3vao{dNode6vac2vat{dNode6vac0wad1ypTxawcbotxakatxasatvaetvao{dNode6vac0wad9yp|ABFNQSUWxawdbookxakaoxasbokvaetwad0xawbboxakaoxasaovaesvae{dNode6vac2val{dNode6vac0wad1yp]xawebelinxakalxasclinvaetvar{dNode6vac0wad4ypV_`}xawfberlinxakarxasdrlinvaetwad0xawbbexakaexasaevaesvau{dNode6vac0wad5yp]V_`}xawibuzzwordsxakauxashuzzwordsvaetwad0xawabxakabxasabvaesva読{dNode6vac0wad<ypU|ABFNQSUWY[aZgFRUVgxz|}>xawb読書xaka読xasb読書vaetvae{dNode6vac2val{dNode6vac2vas{dNode6vac0wad<ypUPQRTUWemJKLMVovwyDEGJKLNOQSUVWX[\]^_`abcdefijkmnopqstuvwxyz{}~@DEFGHIJMPQRSTWY]^_`acdefhijklnpqsuxy|}@ABCMPa>xawmelasticsearchxakasxasfsearchvaetvao{dNode6vac0wad1yprxawielasticonxakaoxasbonvaetwad4ypEYZrxawgelasticxakalxasflasticvaetvas{dNode6vac0wad1yp_xawbesxakasxasasvaetwad0xawaexakaexasaevaesva-{dNode6vac0wad<ypV||AABBFFNNQQSSUUWWoYnwz@AEMNOX_cinoq@AGHKLMNOPQR>xawa-xaka-xasa-vaetvau{dNode6vac0wad1ypVxawbuixakauxasbuivaetva画{dNode6vac0wad1ypVxawb画面xaka画xasb画面vaetvad{dNode6vac0wad4ypWXZ[xawcdevxakadxascdevvaetva {dNode6vac0wad<ypWXZ[]VX\_`aegy}@CDEJKVVXXX^DEFGRTU>xawa xaka xasa vaetvac{dNode6vac2vao{dNode6vac3van{dNode6vac2vat{dNode6vac0wad4ypWXZ[xawicontainerxakatxasftainervaetvaf{dNode6vac0wad5yp]V_`}xawjconferencexakafxasgferencevaetwad0xawcconxakanxasanvaesvad{dNode6vac0wad2ypVXxawdcodexakadxasbdevaetvaf{dNode6vac0wad1ypAxawfcoffeexakafxasdffeevaetwad0xawbcoxakaoxasaovaesvau{dNode6vac0wad2ypSpxawgcuratorxakauxasfuratorvaetwad0xawacxakacxasacvaesvah{dNode6vac2vau{dNode6vac0wad4ypXS]gxawdhugoxakauxascugovaetvaa{dNode6vac0wad2ypwJxawfhadoopxakaaxaseadoopvaetwad0xawahxakahxasahvaesvaw{dNode6vac4vas{dNode6vac0wad1ypYxawcwslxakasxasbslvaetvai{dNode6vac2van{dNode6vac0wad3ypYpqxawgwindowsxakanxasendowsvaetvak{dNode6vac0wad3yp@ACxawiwikipediaxakakxasgkipediavaetwad0xawbwixakaixasaivaesvao{dNode6vac0wad2ypJKxawiworkplacexakaoxashorkplacevaetvaa{dNode6vac0wad1ypWxawgwatcherxakaaxasfatchervaetwad0xawawxakawxasawvaesvap{dNode6vac4vay{dNode6vac0wad3ypZ[\xawfpythonxakayxaseythonvaetvaa{dNode6vac0wad2ypY^xawepaperxakaaxasdapervaetval{dNode6vac0wad<yp{ABLKQ^acdhx|}>xawfpluginxakalxaseluginvaetvau{dNode6vac0wad1yplxawfpuppetxakauxaseuppetvaetwad0xawapxakapxasapvaesval{dNode6vac2vau{dNode6vac0wad<ypQR~oYnwz@AEMNOX_cinoq@AGHKLMNOPQR>xawflucenexakauxaseucenevaetvao{dNode6vac0wad7ypZ[kBCFGxawhlogstashxakaoxasgogstashvaetwad0xawalxakalxasalvaesvaj{dNode6vac2vaa{dNode6vac0wad1ypWxawdjavaxakaaxascavavaetvaj{dNode6vac0wad1yp@xawdjjugxakajxascjugvaetwad0xawajxakajxasajvaesvaa{dNode6vac0wad;ypX\aegy@CDX^xaweazurexakaaxaseazurevaetvaD{dNode6vac0wad7yp]bijnorxawcDIYxakaDxascDIYvaetvaキ{dNode6vac0wad7yp]bijnorxaweキーボードxakaキxaseキーボードvaetvaM{dNode6vac3vaI{dNode6vac0wad1yp_xaweMICESxakaIxasdICESvaetvaa{dNode6vac0wad2yp~GxawjManifoldCFxakaaxasianifoldCFvaetvao{dNode6vac0wad2ypDFxawjMorphlinesxakaoxasiorphlinesvaetwad0xawaMxakaMxasaMvaesva勉{dNode6vac0wad<ypcdprstyzHNOQU`cghjnpwx{HMNTXYZ`bfkmyBQS]_`bdefjklmoprstvxCGLQTWYZ\]^bdhj{E>xawc勉強会xaka勉xasc勉強会vaetva輪{dNode6vac0wad1yphxawb輪読xaka輪xasb輪読vaetvaN{dNode6vac2vaa{dNode6vac0wad1yphxawdNandxakaaxascandvaetvao{dNode6vac0wad1ypzxawgNorikraxakaoxasforikravaetwad0xawaNxakaNxasaNvaesvaT{dNode6vac0wad1yphxawfTetrisxakaTxasfTetrisvaetvaR{dNode6vac2vau{dNode6vac0wad<ypsvwxGHIOP}~@>xawdRustxakauxascustvaetvai{dNode6vac0wad5yp{~IJNxawdRiakxakaixasciakvaetwad0xawaRxakaRxasaRvaesvaL{dNode6vac2vai{dNode6vac0wad1ypsxawgLinderaxakaixasfinderavaetvau{dNode6vac0wad2ypnoxawfLucenexakauxaseucenevaetwad0xawaLxakaLxasaLvaesva検{dNode6vac0wad5yptz{_txawb検索xaka検xasb検索vaetvan{dNode6vac3val{dNode6vac0wad;ypwxGHIOP}~@xawcnlpxakalxasblpvaetvae{dNode6vac0wad1ypCxawcnetxakaexasbetvaetvao{dNode6vac0wad1ypfxawbnoxakaoxasaovaetwad0xawanxakanxasanvaesvar{dNode6vac2vau{dNode6vac0wad<yp||AABBFFNNQQSSUUWWY[a>xawdrustxakauxascustvaetvae{dNode6vac0wad1ypRxawgreleasexakaexasfeleasevaetwad0xawarxakarxasarvaesvat{dNode6vac3vah{dNode6vac0wad9yp|ABFNQSUWxawcthexakahxasbhevaetvai{dNode6vac0wad1ypTxawhtimelionxakaixasgimelionvaetvar{dNode6vac0wad1ypgxawftravelxakarxaseravelvaetwad0xawatxakatxasatvaesvak{dNode6vac2vau{dNode6vac0wad3yp@sAxawhkuromojixakauxasguromojivaetvai{dNode6vac0wad;ypGTY[uFGPyMPxawfkibanaxakaixaseibanavaetwad0xawakxakakxasakvaesva.{dNode6vac0wad2ypCfxawa.xaka.xasa.vaetvav{dNode6vac2vai{dNode6vac0wad2ypVXxawfvisualxakaixaseisualvaetvaa{dNode6vac0wad1yplxawgvagrantxakaaxasfagrantvaetwad0xawavxakavxasavvaesva買{dNode6vac0wad1yp\xawb買いxaka買xasb買いvaetva物{dNode6vac0wad1yp\xawa物xaka物xasa物vaetvaブ{dNode6vac0wad6yp]cdefgxawcブログxakaブxascブログvaetvaシ{dNode6vac0wad1yp_xawdシステムxakaシxasdシステムvaetva探{dNode6vac0wad1yp_xawb探訪xaka探xasb探訪vaetvaゲ{dNode6vac0wad1yp`xawcゲームxakaゲxascゲームvaetva転{dNode6vac0wad4ypbmUVxawb転職xaka転xasb転職vaetva書{dNode6vac0wad1ypqxawb書籍xaka書xasb書籍vaetvaK{dNode6vac0wad3yp{ABxawfKibanaxakaKxasfKibanavaetvaカ{dNode6vac0wad1yp|xawgカンファレンスxakaカxasgカンファレンスvaetvaス{dNode6vac2vaポ{dNode6vac0wad1yp|xaweスポンサーxakaポxasdポンサーvaetvaピ{dNode6vac0wad1yp[xawgスピリチュアルxakaピxasfピリチュアルvaetwad0xawaスxakaスxasaスvaesva本{dNode6vac0wad5ypGPNPWxawa本xaka本xasa本vaetvaf{dNode6vac2vao{dNode6vac0wad1ypfxawefoundxakaoxasdoundvaetval{dNode6vac0wad3ypyPVxawgfluentdxakalxasfluentdvaetwad0xawafxakafxasafvaesvaE{dNode6vac0wad3ypKLOxawmElasticsearchxakaExasmElasticsearchvaetvaC{dNode6vac2vaS{dNode6vac0wad1ypZxawkCloudSearchxakaSxasfSearchvaetvae{dNode6vac0wad:ypzDFGHRTTUUxawhClouderaxakaexasceravaetwad0xaweCloudxakaCxaseCloudvaesvaA{dNode6vac0wad3ypZQSxawcAWSxakaAxascAWSvaetva感{dNode6vac0wad1yp\xawc感想文xaka感xasc感想文vaetvaオ{dNode6vac0wad2yp\HxaweオライリーxakaオxaseオライリーvaetvaJ{dNode6vac3vaV{dNode6vac0wad1ypbxawcJVMxakaVxasbVMvaetvaa{dNode6vac0wad1ypbxawdJavaxakaaxascavavaetvaI{dNode6vac0wad1ypixawdJIRAxakaIxascIRAvaetwad0xawaJxakaJxasaJvaesvaS{dNode6vac3vao{dNode6vac0wad<ypmotvw~DFGIJKLNORTU>xawdSolrxakaoxascolrvaetvae{dNode6vac0wad6ypDFGRTUxawfSearchxakaexaseearchvaetvac{dNode6vac0wad1ypSxaweScalaxakacxasdcalavaetwad0xawaSxakaSxasaSvaesvaH{dNode6vac2vaa{dNode6vac0wad5ypzHRTUxawfHadoopxakaaxaseadoopvaetvai{dNode6vac0wad1ypHxawdHivexakaixascivevaetwad0xawaHxakaHxasaHvaesvaY{dNode6vac0wad5yp{~IJNxawhYokozunaxakaYxashYokozunavaetvaX{dNode6vac0wad1ypExawfXperiaxakaXxasfXperiavaetvaZ{dNode6vac2vao{dNode6vac0wad1ypVxawhZoomdataxakaoxasgoomdatavaetvai{dNode6vac0wad2yp{|xawfZipkinxakaixaseipkinvaetwad1ypExawaZxakaZxasaZvaetvaB{dNode6vac0wad1ypNxaweBashoxakaBxaseBashovaetva備{dNode6vac0wad<yp^chqDKP[fps~BCD>xawc備忘録xaka備xasc備忘録vaetvaO{dNode6vac0wad1yp~xawcOSSxakaOxascOSSvaetva形{dNode6vac0wad1ypFxawe形態素解析xaka形xase形態素解析vaet>wad0xaw`xak`xas`vaesvgisArraytvddate3xdtypecAVLvdnode5yakPwav0valpvar5yak%,")Mwav1ypQval5yak%$4Awav1ypRval5yak%1!pwav1ypSval5yak%7pwav1ypTval5yak%=Hwav1ypUval5yak$9'|wav1ypVval5yak$0iwav1ypWval5yak$/$Hwav1ypXval5yak$/!(`wav1ypYval5yak$..zwav1ypZval5yak$+?#kwav1yp[val5yak$*6dwav1yp\val5yak$$uwav1yp]val5yak#,
<\wav1yp^val5yak#&Vwav1yp_val5yak#$ 6]wav1ypPval5yak"<13Zwav1ypQval5yak"< rwav1ypRval5yak";
/bwav1ypSval5yak"5:#jwav1ypTval5yak"567{wav1ypUval5yak"*>_wav1ypVval5yak")19Vwav1ypWval5yak"!	 Ywav1ypXval5yak!7*nwav1ypYval5yak!30owav1ypZval5yak!3	xwav1yp[val5yak!0)
gwav1yp\val5yak!+7pwav1yp]val5yak!"5&\wav1yp^val5yak ;/gwav1yp_val5yak 9?'Ewav1yp`val5yak 7Wwav1ypaval5yak "-Twav1ypbval5yak -0gwav1ypcval5yak ~wav1ypdval5yak 3%uwav1ypeval5yak 
7fwav1ypfval5yak pwav1ypgval5yak :|wav1yphval5yak ,&Jwav1ypival5yak>;,Wwav1ypjval5yak;~wav1ypkval5yak;twav1yplval5yak67{wav1ypmval5yak2
+Xwav1ypnval5yak(,gwav1ypoval5yak#+Nwav1yppval5yak!:8Rwav1ypqval5yak 11fwav1yprval5yak(bwav1ypsval5yakfwav1yptval5yak.&uwav1ypuval5yak#>\wav1ypvval5yak cwav1ypwval5yak%
Awav1ypxval5yak9;Wwav1ypyval5yak93Rwav1ypzval5yak)9Vwav1yp{val5yak
.*Jwav1yp|val5yak)lwav1yp}val5yak=Vwav1yp~val5yak<1uwav1ypval5yak74/Pwav1yp@val5yak6Iwav1ypAval5yak37<owav1ypBval5yak3
Wwav1ypCval5yak14
+qwav1ypDval5yak/.mwav1ypEval5yak/
+~wav1ypFval5yak.!qwav1ypGval5yak-:`wav1ypHval5yak-4Iwav1ypIval5yak,7
Rwav1ypJval5yak*<?@wav1ypKval5yak)##owav1ypLval5yak'99Pwav1ypMval5yak&
+jwav1ypNval5yak#.Owav1ypOval5yak#)ywav1ypPval5yak#wav1ypQval5yak"*pwav1ypRval5yak!Nwav1ypSval5yak?gwav1ypTval5yak[wav1ypUval5yak+5}wav1ypVval5yak
Bwav1ypWval5yak,?Wwav1ypXval5yak?Mwav1ypYval5yak?Cwav1ypZval5yak".mwav1yp[val5yak8<nwav1yp\val5yak4"`wav1yp]val5yak
+awav1yp^val5yakkwav1yp_val5yak
%fwav1yp`val5yak
dwav1ypaval5yak

Cwav1ypbval5yak;,dwav1ypcval5yak
+*Ywav1ypdval5yak
+Zwav1ypeval5yak	;fwav1ypfval5yak.Ywav1ypgval5yak,Gwav1yphval5yak
wav1ypival5yak>Jwav1ypjval5yak>
+wwav1ypkval5yak=-Mwav1yplval5yak:)rwav1ypmval5yak9'!pwav1ypnval5yak8(pwav1ypoval5yak,-Bwav1yppval5yak'-]wav1ypqval5yak (dwav1yprval5yak0/nwav1ypsval5yak=Hwav1yptval5yak
+ewav1ypuval5yakqwav1ypvval5yak!vwav1ypwval5yak16owav1ypxval5yak1/nwav1ypyval5yakzwav1ypzval5yak6#iwav1yp{val5yak-$Dwav1yp|val5yak,?ewav1yp}val5yak")(Pwav1yp~val5yak!Uwav1ypval5yak!
owav1yp@val5yakqwav1ypAval5yak~wav1ypBval5yak
!swav1ypCval5yak;Hwav1ypDval5yak
3pwav1ypEval5yak
.Ywav1ypFval5yak00>fwav1ypGval5yak	]wav1ypHval5yak;Fwav1ypIval5yak(9Vwav1ypJval5yak>Vwav1ypKval5yak$Pwav1ypLval5yak2Rwav1ypMval5yak 
[wav1ypNval5yak:"Dwav1ypOval5yak9+7Twav1ypPval5yak#2
Pwav1ypQval5yak!
~wav1ypRval5yakBwav1ypSval5yak{wav1ypTval5yak%bwav1ypUval5yak3
jwav1ypVval5yak1){wav1ypWval5yak#Kwav1ypXval5yak"swav1ypYval5yak"]wav1ypZval5yak1Cwav1yp[val5yak></mwav1yp\val5yak7<<Jwav1yp]val5yak7&hwav1yp^val5yak5dwav1yp_val5yak.0*awav1yp`val5yak."iwav1ypaval5yak+3%Awav1ypbval5yak)0.iwav1ypcval5yak'%Cwav1ypdval5yak&7|wav1ypeval5yak&6>Pwav1ypfval5yak&:Mwav1ypgval5yak ;}wav1yphval5yak;6Fwav1ypival5yaklwav1ypjval5yak
/Zwav1ypkval5yak,Owav1yplval5yak2pwav1ypmval5yak	4bwav1ypnval5yak
+2,wwav1ypoval5yak3Wwav1yppval5yak6 hwav1ypqval5yak??Wwav1yprval5yak<7Dwav1ypsval5yak<uwav1yptval5yak9,pwav1ypuval5yak9,^wav1ypvval5yak9>}wav1ypwval5yak8owav1ypxval5yak7uwav1ypyval5yak7Iwav1ypzval5yak2Pwav1yp{val5yak(>fwav1yp|val5yak&;Lwav1yp}val5yak$(,Xwav1yp~val5yak$&vwav1ypval5yak$?bwav1yp@val5yak#:Lwav1ypAval5yak#
+hwav1ypBval5yak"*Vwav1ypCval5yak=lwav1ypDval5yak(?Twav1ypEval5yak;zwav1ypFval5yak/ owav1ypGval5yak?8[wav1ypHval5yak%iwav1ypIval5yak!Gwav1ypJval5yak!@wav1ypKval5yakhwav1ypLval5yak1hwav1ypMval5yak;*lwav1ypNval5yak+Twav1ypOval5yak78	hwav1ypPval5yak63
+@wav1ypQval5yak51
Xwav1ypRval5yak55Dwav1ypSval5yak2&'pwav1ypTval5yak,!4hwav1ypUval5yak,Twav1ypVval5yak'*<Dwav1ypWval5yak#07Dwav1ypXval5yak2
Xwav1ypYval5yak>xwav1ypZval5yak$/Pwav1yp[val5yak:|wav1yp\val5yak 
lwav1yp]val5yak
+|wav1yp^val5yak=Twav1yp_val5yakpwav1yp`val5yak|wav1ypaval5yak'3@wav1ypbval5yak 1@wav1ypcval5yak
Xwav1ypdval5yak%Twav1ypeval5yak
+twav1ypfval5yak	4twav1ypgval5yak)6twav1yphval5yak
dwav1ypival5yak0 pwav1ypjval5yak=;Hwav1ypkval5yak<9|wav1yplval5yak:7Xwav1ypmval5yak:!Hwav1ypnval5yak92hwav1ypoval5yak8:Pwav1yppval5yak7(<pwav1ypqval5yak0pwav1yprval5yak,?Pwav1ypsval5yak,,|wav1yptval5yak+<Dwav1ypuval5yak)@wav1ypvval5yak%
Dwav1ypwval5yak!?dwav1ypxval5yak Pwav1ypyval5yak."dwav1ypzval5yak$.\wav1yp{val5yak94`wav1yp|val5yak$
+Hwav1yp}val5yak!	Twav1yp~val5yak;Dwav1ypval5yak
+)xwav1yp@val5yak	&Dwav1ypAval5yak8hwav1ypBval5yak-hwav1ypCval5yak>7Hwav1ypDval5yak>&xwav1ypEval5yak>pwav1ypFval5yak='#dwav1ypGval5yak<*dwav1ypHval5yak7<Twav1ypIval5yak7?lwav1ypJval5yak55Pwav1ypKval5yak2>&@wav1ypLval5yak0
twav1ypMval5yak0
Dwav1ypNval5yak-/twav1ypOval5yak-Xwav1ypPval5yak,	`wav1ypQval5yak,Hwav1ypRval5yak+0Xwav1ypSval5yak+-pwav1ypTval5yak+-Lwav1ypUval5yak+
;Twav1ypVval5yak+Fwav1ypWval5yak* .|wav1ypXval5yak!;5Twav1ypYval5yak <3Kwav1ypZval5yak	hwav1yp[val5yak8pwav1yp\val5yak'fwav1yp]val5yak`wav1yp^val5yak#{wav1yp_val5yak@wav1yp`val5yak"Dwav1ypaval5yak/@wav1ypbval5yak'
lwav1ypcval5yak?hwav1ypdval5yak>)+lwav1ypeval5yak=Lwav1ypfval5yak;,@wav1ypgval5yak8lwav1yphval5yak4/hwav1ypival5yak12hwav1ypjval5yak-$Pwav1ypkval5yak,3'`wav1yplval5yak'(dwav1ypmval5yak="Lwav1ypnval5yak,|wav1ypoval5yak
>lwav1yppval5yakHwav1ypqval5yak
%pwav1yprval5yak+Xwav1ypsval5yak:6Twav1yptval5yakhwav1ypuval5yak?/9Bwav1ypvval5yak=uwav1ypwval5yak=.Pwav1ypxval5yak:	\wav1ypyval5yak73Twav1ypzval5yak649hwav1yp{val5yak6(!\wav1yp|val5yak6,\wav1yp}val5yak56Pwav1yp~val5yak40bwav1ypval5yak3#lwav1yp@val5yak3	Lwav1ypAval5yak1$Pwav1ypBval5yak1 lwav1ypCval5yak,4=Rwav1ypDval5yak*,twav1ypEval5yak')/Kwav1ypFval5yak$=Twav1ypGval5yak#Kwav1ypHval5yak"$hwav1ypIval5yak"\wav1ypJval5yak!.mwav1ypKval5yak*
dwav1ypLval5yak`wav1ypMval5yak7Hwav1ypNval5yak
+&twav1ypOval5yak"twav1ypPval5yak@wav1ypQval5yak	`wav1ypRval5yak6Ewav1ypSval5yakxwav1ypTval5yakHwav1ypUval5yak(pwav1ypVval5yak&8xwav1ypWval5yak'\wav1ypXval5yak)2twav1ypYval5yak"dwav1ypZval5yakawav1yp[val5yakCwav1yp\val5yak6Hwav1yp]val5yak8@wav1yp^val5yak+|wav1yp_val5yak
>Iwav1yp`val5yak>4Twav1ypaval5yak< 0\wav1ypbval5yak<=[wav1ypcval5yak;6lwav1ypdval5yak87Cwav1ypeval5yak5%\wav1ypfval5yak5\wav1ypgval5yak4;/twav1yphval5yak3=`wav1ypival5yak0)1pwav1ypjval5yak."pwav1ypkval5yak.
+&xwav1yplval5yak,$dwav1ypmval5yak+$hwav1ypnval5yak)-?Pwav1ypoval5yak'#Kwav1yppval5yak%lwav1ypqval5yak#.;hwav1yprval5yak#),|wav1ypsval5yak#twav1yptval5yak"-
+Pwav1ypuval5yak 0"|wav1ypvval5yak 9twav1ypwval5yak7>Xwav1ypxval5yakDwav1ypyval5yak|wav1ypzval5yak:dwav1yp{val5yak$"dwav1yp|val5yak`wav1yp}val5yak%Hwav1yp~val5yak%|wav1ypval5yak8Hwav1yp@val5yak0hwav1ypAval5yak5twav1ypBval5yakxwav1ypCval5yak!xwav1ypDval5yak8lwav1ypEval5yak	$-|wav1ypFval5yak97xwav1ypGval5yak5Xwav1ypHval5yak%Swav1ypIval5yak3xwav1ypJval5yak0`wav1ypKval5yak
?</Hwav1ypLval5yak
="pwav1ypMval5yak
=<Pwav1ypNval5yak
;
Twav1ypOval5yak
94@wav1ypPval5yak
7!
xwav1ypQval5yak
6`wav1ypRval5yak
5pwav1ypSvalpvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPvarpyahPyahPvgisArraysvmvectorIndexes0w TsearchableProperties5xpbidetitlegsummarydtagsddatev ]searchablePropertiesWithTypes5xbidfstringxetitlefstringxgsummaryfstringxdtagshstring[]xddatefnumbervkfrequencies4vbid<va1<ya2 S0.07692307692307693ya5 S0.07692307692307693yb35 S0.07692307692307693yc561 S0.07692307692307693yd4851 S0.07692307692307693yec4dba S0.07692307692307693yc56f S0.07692307692307693ybdb S0.07692307692307693ybcd S0.07692307692307693yc31b S0.07692307692307693yad S0.07692307692307693yd92dc S0.07692307692307693yae S0.07692307692307693>va27ya9 S0.14285714285714285ydd869 S0.14285714285714285ybfb S0.14285714285714285yd48cb S0.14285714285714285ydacba S0.14285714285714285yd03dc S0.14285714285714285ym639481524ee80 S0.14285714285714285va35ya6c0.2yd476ec0.2yc17bc0.2yafc0.2y W854414033d5cec1470774eec0.2va4<ya6 S0.06666666666666667ya7 S0.13333333333333333ya8 S0.13333333333333333yd5010 S0.06666666666666667yd516a S0.06666666666666667ybaa S0.13333333333333333yc07f S0.06666666666666667ycfaa S0.06666666666666667yab S0.06666666666666667ye38beb S0.06666666666666667ybcf S0.06666666666666667yac S0.06666666666666667>va59ya4 R0.1111111111111111yc531 R0.1111111111111111yb7f R0.1111111111111111yc78b R0.1111111111111111yc02c R0.1111111111111111yaf R0.1111111111111111yg09602ba R0.1111111111111111yae R0.1111111111111111yk140132d26a2 R0.1111111111111111va6<ya2 S0.06666666666666667ya3 S0.13333333333333333ya5 S0.06666666666666667ya8 S0.06666666666666667yc765 S0.06666666666666667yb8f S0.06666666666666667ye58cbe S0.06666666666666667yaf S0.13333333333333333ybce S0.06666666666666667yc85c S0.06666666666666667yg22569af S0.06666666666666667ybde S0.06666666666666667yad S0.06666666666666667>va79ya9 R0.1111111111111111yc847 R0.1111111111111111yc886 R0.1111111111111111ybf9 R0.1111111111111111yae R0.1111111111111111ybee R0.1111111111111111ycbdb R0.1111111111111111ybab R0.1111111111111111yo5583eeb6eabbd51 R0.1111111111111111va89yc561 S0.09090909090909091yc999 S0.09090909090909091yd7884 S0.09090909090909091yd9358 S0.09090909090909091ye18218 S0.09090909090909091yab R0.2727272727272727yc62c S0.09090909090909091yad S0.09090909090909091yf52779a S0.09090909090909091va9:ya7c0.1yc403c0.1yc637c0.1ybedc0.1yh431877cec0.1yd11fec0.1ycfeec0.1yc77fc0.1yadc0.1yd26cec0.1vb10<ya0 S0.13333333333333333ya2 S0.06666666666666667ya4 S0.06666666666666667ya5 S0.06666666666666667ya6 S0.06666666666666667yh90061486 S0.06666666666666667yd086b S0.06666666666666667ybfd S0.06666666666666667yaf S0.06666666666666667yf77021a S0.06666666666666667yaa S0.06666666666666667ybaa S0.06666666666666667yab S0.06666666666666667yae S0.06666666666666667>vb111y `a12474027c91fad5a861aa9919817d72Qvb124ya3d0.25ye698cfd0.25yccbdd0.25y W796161d82c9ac438ebab5d2d0.25vb131y `9335522f4c8dbc7256a42a091e6e00bcQvb144ybdfd0.25yc30dd0.25yg810068ed0.25y T4656498e5972c6de7e3dd0.25vb15<ya0 S0.07692307692307693ya2 S0.07692307692307693yb30 S0.07692307692307693yd6761 S0.07692307692307693yd9623 S0.07692307692307693yc67c S0.07692307692307693ybae S0.07692307692307693yae S0.07692307692307693yd89be S0.07692307692307693ybfa S0.07692307692307693yd66db S0.07692307692307693yab S0.07692307692307693yc40d S0.07692307692307693>vb169ya1 S0.18181818181818182ya2 S0.09090909090909091yc906 S0.09090909090909091ye9693a S0.09090909090909091yae S0.18181818181818182ye77dee S0.09090909090909091ye5785b S0.09090909090909091ybdc S0.09090909090909091yg61ccffd S0.09090909090909091vb171y `73279888a8fe482c836fb19ca23318dcQvb18<ya3 S0.07692307692307693ya6 S0.07692307692307693ya8 S0.07692307692307693yc840 S0.07692307692307693yd6639 S0.07692307692307693ybec S0.07692307692307693yaf S0.15384615384615385yc88c S0.07692307692307693ye4976f S0.07692307692307693ybca S0.07692307692307693yd20fa S0.07692307692307693yd169e S0.07692307692307693>vb19<ya2 S0.06666666666666667ya6 S0.13333333333333333ya7 S0.06666666666666667ya9 S0.06666666666666667yc579 S0.06666666666666667yd167a S0.06666666666666667yac S0.06666666666666667yad S0.06666666666666667ybce S0.06666666666666667yaf S0.13333333333333333ydcebf S0.06666666666666667yc64a S0.06666666666666667yg6329ecb S0.06666666666666667>vb20:ya6c0.1ya8c0.1yd3384c0.1ybeac0.1ybbbc0.1yc47dc0.1yc70fc0.1ybcac0.1yc94bc0.1yk4510813f36ac0.1vb21<ya4 S0.07692307692307693ya9 S0.07692307692307693yc444 S0.07692307692307693yc720 S0.07692307692307693yd8773 S0.07692307692307693yd779e S0.07692307692307693yab S0.07692307692307693ybbc S0.07692307692307693yaa S0.07692307692307693yceed S0.07692307692307693yc97f S0.07692307692307693yc19c S0.07692307692307693yc41e S0.07692307692307693>vb222ydf56cc0.5y \19442484b3e4f47875b58b3f72b2c0.5vb235yd1726c0.2yf5eebdfc0.2yd85fdc0.2ybdbc0.2y P301194bfeeee4377c0.2vb242yc7ccc0.5y ]21814165879f72529e91682ece5c6c0.5vb251y `0645bdb1cdf88ec74288d503eb71839cQvb26:ya1 S0.09090909090909091ya8 S0.18181818181818182yd7043 S0.09090909090909091yd104b S0.09090909090909091ybee S0.09090909090909091yc17a S0.09090909090909091ybbf S0.09090909090909091yaf S0.09090909090909091yad S0.09090909090909091yl236659680493 S0.09090909090909091vb275ya2c0.2yd218ec0.2yacc0.2yc36dc0.2y W5945ece02fdc55d6cbcbc38c0.2vb284yc140d0.25yef0fdcd0.25yaed0.25y W18514362a4e52376a6fecbad0.25vb29:ya4c0.1ya7c0.1yc26ec0.1ye44dfdc0.1yc16ac0.1ye2963dc0.1yacc0.1yc18ec0.1yf99806cc0.1yd26fdc0.1vb301y `35200cbf0b5b45d7f5f0b343cb18868bQvb316ya7 S0.16666666666666666yc10a S0.16666666666666666yaf S0.16666666666666666yd69bd S0.16666666666666666yc03d S0.16666666666666666y T2632722300194f01e93d S0.16666666666666666vb32;ya6 S0.09090909090909091ya7 S0.09090909090909091yd4858 S0.09090909090909091ye90451 S0.09090909090909091yc59b S0.09090909090909091yab S0.09090909090909091yc60e S0.09090909090909091ycbbf S0.09090909090909091yad S0.09090909090909091yf72643d S0.09090909090909091yd22ad S0.09090909090909091vb33:ya4 S0.16666666666666666ya5 S0.08333333333333333ya8 S0.08333333333333333yf43caef S0.08333333333333333yad S0.16666666666666666yc41c S0.08333333333333333yae S0.08333333333333333yf74826e S0.08333333333333333yaa S0.08333333333333333yi82088739d S0.08333333333333333vb34<ya2 S0.07142857142857142ya4 S0.07142857142857142ya7 S0.07142857142857142yc712 S0.07142857142857142yc794 S0.07142857142857142yef4baa S0.07142857142857142yd43cc S0.07142857142857142ybca S0.07142857142857142yad S0.07142857142857142yc83b S0.07142857142857142yc99a S0.07142857142857142yac S0.07142857142857142yae S0.07142857142857142ycdbd S0.07142857142857142>vb35:ya4c0.1ya7c0.1yd2019c0.1ydf41dc0.1ycfdec0.1ye94cbdc0.1ycbbdc0.1yg28808dcc0.1yc080c0.1yaac0.1vb36<ya4e0.125ya7f0.0625ya8f0.0625yc426f0.0625yc799f0.0625ybcef0.0625yabf0.0625yaff0.0625ye3190cf0.0625yaae0.125yc47df0.0625yd45acf0.0625yaef0.0625yc91af0.0625>vb37<ya0 R0.1111111111111111ya3 S0.05555555555555555ya5 R0.1111111111111111yc301 S0.05555555555555555yd8340 S0.05555555555555555ydeced S0.05555555555555555yc95e S0.05555555555555555yaf S0.05555555555555555yaa S0.05555555555555555yae S0.05555555555555555yc83d S0.05555555555555555yc81d S0.05555555555555555yac R0.1111111111111111yad R0.1111111111111111>vb38:ya6c0.1yc133c0.1yd5777c0.1ycfcbc0.1yd0105c0.1ybfac0.1yabc0.1yaac0.1yafc0.1yl247784b9d930c0.1vb39<ya0f0.0625ya1f0.0625ya2f0.0625ya5f0.0625ya8f0.0625ya9f0.0625yc724f0.0625yd1973f0.0625yd931bf0.0625ycebdf0.0625yebfaebf0.0625ycdcff0.0625yaef0.0625yaaf0.0625yaff0.0625yadf0.0625>vb408ya7e0.125ya8e0.125ybaae0.125yc61be0.125ye4543ee0.125yaae0.125yace0.125y R67fccabee27a6e99cde0.125vb412ygd95522cc0.5y Y691013bfe66dd46ded85a98edc0.5vb428yc641e0.125yd8239e0.125yc4ade0.125yaae0.125yc37fe0.125ycbcde0.125yf17abebe0.125yi96106314ee0.125vb434yc421d0.25yc64ad0.25yacd0.25y Y2367372c3199c66a6420faf89d0.25vb44<ya3 S0.06666666666666667ya4 S0.06666666666666667ya8 S0.06666666666666667ya9 S0.06666666666666667yc641 S0.06666666666666667yba5 S0.06666666666666667ybb2 S0.06666666666666667ybee S0.06666666666666667yae S0.13333333333333333yc10d S0.06666666666666667ybdb S0.06666666666666667yaf S0.06666666666666667yh888217ab S0.06666666666666667ycecc S0.06666666666666667>vb45<ya0 S0.07142857142857142ya1 S0.07142857142857142ya2 S0.07142857142857142yc892 S0.07142857142857142ybc6 S0.07142857142857142ybfc S0.07142857142857142yd88bd S0.07142857142857142yc57a S0.07142857142857142yae S0.07142857142857142ye57ddf S0.07142857142857142yc22e S0.07142857142857142ybeb S0.07142857142857142ycbef S0.07142857142857142yac S0.07142857142857142>vb46<ya3 S0.07692307692307693yb42 S0.07692307692307693yc418 S0.07692307692307693yc601 S0.07692307692307693yda46c S0.07692307692307693yad S0.15384615384615385yc03a S0.07692307692307693yaa S0.07692307692307693yd26bc S0.07692307692307693yd0096 S0.07692307692307693ybfe S0.07692307692307693yc83a S0.07692307692307693>vb47:ya1c0.1ya3c0.1ya5c0.1ya6c0.1ygb16bdddc0.1yaac0.1yadc0.1yaec0.1yafc0.1y Q4136446bebe7ffbc7c0.1vb486ya1 S0.16666666666666666yd5132 S0.16666666666666666yd188c S0.16666666666666666ybee S0.16666666666666666yaa S0.16666666666666666y T6752dfce5a0235354070 S0.16666666666666666vb49<ya1 S0.07692307692307693ya3 S0.07692307692307693ya5 S0.07692307692307693ya9 S0.07692307692307693yc127 S0.07692307692307693ybde S0.07692307692307693yc37d S0.07692307692307693ycfae S0.07692307692307693yh011687eb S0.07692307692307693ybeb S0.07692307692307693yaa S0.07692307692307693ycfcb S0.07692307692307693yc89e S0.07692307692307693>vb501y `c377351433a941a927aab543931f6026Qvb518ya7e0.125yc656e0.125yc897e0.125yf15932ae0.125yafe0.125yeacface0.125yade0.125yl27766eadc9e2e0.125vb529ya0 R0.1111111111111111ybb2 R0.1111111111111111ybc4 R0.1111111111111111ybcf R0.1111111111111111ybfb R0.1111111111111111yc96d R0.1111111111111111yc02d R0.1111111111111111yc37f R0.1111111111111111yn03668caaecbc57 R0.1111111111111111vb539ya3 R0.1111111111111111yd9927 R0.1111111111111111ydd08a R0.1111111111111111ycfdc R0.1111111111111111yc040 R0.1111111111111111yebbbdd R0.1111111111111111yc81c R0.1111111111111111ybce R0.1111111111111111yg296318c R0.1111111111111111vb54<ya2 S0.07692307692307693ya6 S0.07692307692307693ya7 S0.07692307692307693ya9 S0.07692307692307693yc231 S0.07692307692307693ye827de S0.07692307692307693yad S0.15384615384615385yaa S0.07692307692307693yaf S0.07692307692307693ycbcb S0.07692307692307693ye44caf S0.07692307692307693yh35896c1f S0.07692307692307693>vb55<ya0e0.125ya1 T0.041666666666666664ya2 T0.041666666666666664ya4 T0.041666666666666664ya5 T0.041666666666666664ya6 T0.041666666666666664ya8 T0.041666666666666664ya9 T0.041666666666666664yc351 T0.041666666666666664yb3c T0.041666666666666664yad S0.16666666666666666yaee0.125ybfb T0.041666666666666664yc33e T0.041666666666666664yab T0.041666666666666664yc43c T0.041666666666666664yaf T0.041666666666666664>vb569ya2 R0.1111111111111111yc349 R0.1111111111111111yd5824 R0.1111111111111111ybeb R0.1111111111111111yaa R0.1111111111111111yae R0.1111111111111111yf03996c R0.1111111111111111yg1966bee R0.1111111111111111yg38866ce R0.1111111111111111vb57<ya3 S0.08333333333333333ya8 S0.08333333333333333yc482 S0.08333333333333333yc616 S0.08333333333333333yd6193 S0.08333333333333333ye37912 S0.08333333333333333yff5effd S0.08333333333333333yaa S0.08333333333333333yaf S0.08333333333333333ybdb S0.08333333333333333yab S0.08333333333333333ydcaec S0.08333333333333333>vb587yc188 S0.14285714285714285yd5758 S0.14285714285714285yc11a S0.14285714285714285yf61827e S0.14285714285714285yf80739a S0.14285714285714285yi6065960eb S0.14285714285714285yad S0.14285714285714285vb595yc845c0.2yc9dac0.2ybcdc0.2yf31310bc0.2y R8952efd1be1881e651c0.2vb60<ya8 S0.07692307692307693yc521 S0.07692307692307693yc813 S0.07692307692307693yc880 S0.07692307692307693yd7730 S0.07692307692307693yd208a S0.07692307692307693yac S0.15384615384615385yc072 S0.07692307692307693ybea S0.07692307692307693yab S0.07692307692307693yd86ca S0.07692307692307693ybeb S0.07692307692307693>vb61<ya2 S0.10526315789473684ya3 S0.05263157894736842ya4 S0.05263157894736842ya5 S0.10526315789473684ya8 S0.05263157894736842yc501 S0.05263157894736842ybe5 S0.05263157894736842ybcb S0.05263157894736842yae S0.05263157894736842yad S0.15789473684210525ybdb S0.10526315789473684yaf S0.05263157894736842yf14984a S0.05263157894736842yc66d S0.05263157894736842>vb62<ya0d0.05ya1d0.05ya2d0.05ya3d0.05ya5c0.1ya6d0.05yc801d0.05yc888d0.05yd2824d0.05ycbbdd0.05ybffd0.05yadd0.05yabd0.05ybbbd0.05yafd0.05ybdad0.05yaad0.15>vb63<ya5 S0.14285714285714285yb92 S0.07142857142857142yc321 S0.07142857142857142yc843 S0.07142857142857142yd5955 S0.07142857142857142yc8a1 S0.07142857142857142ybea S0.07142857142857142yad S0.07142857142857142ybcf S0.07142857142857142ybbc S0.07142857142857142yaa S0.07142857142857142yf94cfcc S0.07142857142857142yae S0.07142857142857142>vb649ya4c0.1ya8c0.1yc115c0.1yc617c0.1yc82ac0.1ybabc0.1yadc0.1yaec0.2y P96813587fe3a6049c0.1vb652yde74dc0.5y \071363645a588f858b35231128c4c0.5vb661y `163beeae9620c1a6a46a38aa7ebd9663Qvb678ya0e0.125ya3e0.125yd36dde0.125yf94159ee0.125yaee0.125yf60076ce0.125yace0.125yl6098086e255fe0.125vb68:yb66c0.1yc309c0.1yc435c0.1yf21982fc0.1yd43bcc0.1yafc0.1yf22efefc0.1yc22bc0.1yaac0.1yc48cc0.1vb692yg306cecbc0.5y Y32320ead508346ad8fed3394dc0.5vb70;yc220 S0.09090909090909091yc804 S0.09090909090909091yc934 S0.09090909090909091yc941 S0.09090909090909091yb1e S0.09090909090909091yaa S0.09090909090909091yae S0.09090909090909091yd16fd S0.09090909090909091ybbd S0.09090909090909091ybca S0.09090909090909091yh03865b60 S0.09090909090909091vb71:ya2c0.1yc417c0.1yc538c0.1yc607c0.1yg09155bfc0.1yaac0.1yf93847bc0.1ybadc0.1yafc0.1ye78ccac0.1vb72:ya6c0.1ya7c0.1yc914c0.1ydc098c0.1yacc0.1yafc0.1yi0901979bdc0.1ybedc0.1yaac0.1yi345200f90c0.1vb734yd3270d0.25yb2cd0.25yafd0.25y Y8797ace2fb37402ea6a09d126d0.25vb74<ya1 S0.13333333333333333ya2 S0.13333333333333333yb63 S0.06666666666666667yc443 S0.06666666666666667yd44db S0.06666666666666667yaf S0.13333333333333333ydfefc S0.06666666666666667yd97cd S0.06666666666666667yc28d S0.06666666666666667yc55d S0.06666666666666667ybbd S0.06666666666666667yab S0.06666666666666667>vb75<ya0d0.05ya1d0.05ya2d0.05ya3d0.05ya7d0.05ya8d0.15yb4dd0.05yc71dd0.05yaad0.05yc23cd0.05yd85fbd0.05ybafd0.05yc20ed0.05yadd0.05yaec0.1yabd0.05ybded0.05>vb76<ya2 S0.07142857142857142ya3 S0.14285714285714285ya6 S0.07142857142857142ya7 S0.07142857142857142yh45353291 S0.07142857142857142ybbe S0.07142857142857142yac S0.07142857142857142yd49ea S0.07142857142857142ye5816e S0.07142857142857142ycdaa S0.07142857142857142yad S0.07142857142857142yab S0.07142857142857142ybff S0.07142857142857142>vb77:ya2c0.1yc177c0.1yc861c0.1yd6978c0.1yf15357bc0.1yaec0.1ye83daac0.1yadc0.1yf97692cc0.1ybdcc0.1vb784ydf488d0.25ybaad0.25yc62dd0.25y W39194824861a134567cadb8d0.25vb79;ya0 S0.09090909090909091yc389 S0.09090909090909091yc687 S0.09090909090909091yb9a S0.09090909090909091ydbabb S0.09090909090909091yaf S0.09090909090909091yd44db S0.09090909090909091yd51dc S0.09090909090909091yab S0.09090909090909091yf75bdaa S0.09090909090909091yc19d S0.09090909090909091vb802ybdcc0.5y ^9580308938069159c5afc55b2f3b96c0.5vb81;ya5 S0.08333333333333333ya9 S0.08333333333333333yc470 S0.08333333333333333ye4fbdc S0.08333333333333333yac S0.16666666666666666yc57a S0.08333333333333333yg37781dc S0.08333333333333333ybdd S0.08333333333333333yc86f S0.08333333333333333yc61d S0.08333333333333333yb04 S0.08333333333333333vb82<ya0 S0.07142857142857142ya3 S0.07142857142857142ya4 S0.07142857142857142ya7 S0.07142857142857142yc415 S0.07142857142857142yd6fbf S0.07142857142857142yac S0.07142857142857142yad S0.07142857142857142yaf S0.14285714285714285yc89e S0.07142857142857142yae S0.07142857142857142ye89cec S0.07142857142857142yh28811a94 S0.07142857142857142>vb834ya9d0.25yb8dd0.25yacd0.25y \3760395e8e0eb40e335b22750b68d0.25vb84<ya3 S0.07692307692307693yc431 S0.07692307692307693yc626 S0.07692307692307693yc866 S0.07692307692307693yc915 S0.07692307692307693yb3f S0.07692307692307693ybbf S0.07692307692307693yd71ee S0.07692307692307693yaf S0.15384615384615385ycdaf S0.07692307692307693yd42bc S0.07692307692307693ybfa S0.07692307692307693>vb85<ya0 T0.058823529411764705ya1 T0.058823529411764705ya5 T0.058823529411764705ya7 S0.11764705882352941yc258 T0.058823529411764705yc966 T0.058823529411764705ye7fded T0.058823529411764705yd0345 T0.058823529411764705yac S0.17647058823529413yceea T0.058823529411764705yab S0.11764705882352941ybee T0.058823529411764705ybaa T0.058823529411764705>vb86<ya0 S0.05263157894736842ya4 S0.10526315789473684ya5 S0.15789473684210525ya9 S0.05263157894736842yba7 S0.05263157894736842yaf S0.15789473684210525yae S0.10526315789473684yf85fcad S0.05263157894736842ybbc S0.05263157894736842ybae S0.05263157894736842yac S0.05263157894736842yc18c S0.05263157894736842yd10de S0.05263157894736842>vb874ya5d0.25yc48bd0.25ybabd0.25y Z9805919736382ffea5a9554c02d0.25vb88<ya7 S0.07692307692307693yb55 S0.07692307692307693yc257 S0.07692307692307693yc779 S0.07692307692307693yd3737 S0.07692307692307693ybc9 S0.07692307692307693yad S0.07692307692307693ycaba S0.07692307692307693yf54475c S0.07692307692307693yc20b S0.07692307692307693ybce S0.07692307692307693yac S0.07692307692307693yae S0.07692307692307693>vb89<ya1 S0.07142857142857142ya8 S0.07142857142857142yc122 S0.07142857142857142yc314 S0.07142857142857142yc780 S0.07142857142857142yc785 S0.07142857142857142yb6f S0.07142857142857142yd47cb S0.07142857142857142ybfd S0.07142857142857142yac S0.07142857142857142ycadb S0.07142857142857142ybcc S0.07142857142857142yaf S0.07142857142857142yc44f S0.07142857142857142>vb90<ya2 S0.05555555555555555ya6 R0.1111111111111111ya7 S0.05555555555555555yc150 S0.05555555555555555yc219 S0.05555555555555555yc388 S0.05555555555555555ydd710 S0.05555555555555555yaa R0.2222222222222222yc073 S0.05555555555555555ybbe S0.05555555555555555ybda S0.05555555555555555ybeb S0.05555555555555555yab R0.1111111111111111>vb91<ya0f0.0625ya3e0.125ya9e0.125yc979f0.0625ye74933f0.0625yd71cff0.0625yd83aef0.0625yafe0.125yc45ef0.0625ycedef0.0625yaaf0.0625yabf0.0625yacf0.0625>vb92<ya0 S0.09523809523809523ya2 T0.047619047619047616ya3 T0.047619047619047616ya6 S0.09523809523809523ya9 S0.09523809523809523yc362 T0.047619047619047616yc935 T0.047619047619047616ycdaa T0.047619047619047616ybfe T0.047619047619047616yab S0.09523809523809523ybbe T0.047619047619047616yaf T0.047619047619047616yc31b T0.047619047619047616ybad T0.047619047619047616yae T0.047619047619047616yad S0.09523809523809523>vb93<ya4 T0.058823529411764705ya6 T0.058823529411764705ya7 S0.11764705882352941ya8 S0.11764705882352941yc399 T0.058823529411764705yd9679 T0.058823529411764705ybef T0.058823529411764705yaa T0.058823529411764705yac S0.11764705882352941ybce T0.058823529411764705yae T0.058823529411764705ye9710c T0.058823529411764705ycecf T0.058823529411764705ycbcc T0.058823529411764705>vb941y `c3053579ae25e2fb9b967076a06373afQvb95<ya5 S0.08333333333333333ya6 S0.08333333333333333yc482 S0.08333333333333333yb7b S0.08333333333333333yc080 S0.08333333333333333ybdc S0.08333333333333333ye43fce S0.08333333333333333ybaf S0.08333333333333333yd14de S0.08333333333333333yc61c S0.08333333333333333ybab S0.08333333333333333yd819a S0.08333333333333333>vb962yc90fc0.5y ]9355781403b92e844de8568863ae8c0.5vb97:ya0 S0.15384615384615385ya8 S0.15384615384615385yc508 S0.07692307692307693yf7fcfaa S0.07692307692307693ybdd S0.07692307692307693ye34dbd S0.07692307692307693yaf S0.15384615384615385yc19e S0.07692307692307693ybca S0.07692307692307693yefcfda S0.07692307692307693vb986ya3 S0.16666666666666666ya5 S0.16666666666666666ydc61a S0.16666666666666666ycbda S0.16666666666666666yaf S0.16666666666666666y V1667498626ae52ad0362e0 S0.16666666666666666vb99<ya3 S0.06666666666666667ya7 S0.13333333333333333yc152 S0.06666666666666667yc459 S0.13333333333333333yfd9018f S0.06666666666666667yad S0.06666666666666667yac S0.06666666666666667yc94a S0.06666666666666667yc91e S0.06666666666666667yc92b S0.06666666666666667yae S0.13333333333333333yaf S0.06666666666666667>vc100<ya3f0.0625ya4f0.0625ya5f0.0625ya9f0.0625yb25f0.0625yc535f0.0625yc99cf0.0625yace0.125yc80af0.0625ye6532ef0.0625ybeaf0.0625yabf0.0625yaaf0.0625yc92df0.0625yc07af0.0625>vc101<ya3 S0.08333333333333333ya6 S0.08333333333333333yc365 S0.08333333333333333yc813 S0.08333333333333333yh21590549 S0.08333333333333333yd018b S0.08333333333333333yab S0.08333333333333333yd00dd S0.08333333333333333yaa S0.08333333333333333ybad S0.08333333333333333yc17c S0.08333333333333333yad S0.08333333333333333>vc1029ya0 R0.1111111111111111ya3 R0.1111111111111111ya4 R0.1111111111111111yea65bd R0.1111111111111111yc31d R0.1111111111111111yac R0.1111111111111111ycdab R0.1111111111111111yaa R0.1111111111111111y P41712823a5d6002b R0.1111111111111111vc103<ya4e0.125ya8f0.0625ya9f0.0625yc299f0.0625yc886f0.0625yd2561f0.0625yb3cf0.0625yaaf0.0625yadf0.0625yd77bef0.0625yabf0.0625yaff0.0625ybcef0.0625ycfcdf0.0625yc23af0.0625>vc104;ya7 S0.09090909090909091ya9 S0.09090909090909091yc407 S0.09090909090909091yc936 S0.09090909090909091yi431816573 S0.09090909090909091yd35aa S0.09090909090909091yae S0.09090909090909091yd09db S0.09090909090909091ycaee S0.09090909090909091ybec S0.09090909090909091yac S0.09090909090909091vc105<ya1 S0.08333333333333333ya8 S0.08333333333333333yc356 S0.08333333333333333yb1a S0.08333333333333333yaa S0.08333333333333333ybcc S0.08333333333333333yd0040 S0.08333333333333333yab S0.08333333333333333yad S0.08333333333333333yf06eacd S0.08333333333333333yc22e S0.08333333333333333yg0526476 S0.08333333333333333>vc1064ya8d0.25yc80cd0.25ycfcad0.25y Y02ebfecc7a931dad1ec38466ed0.25vc1073ybf3 R0.3333333333333333ybef R0.3333333333333333y \819656f68b87a91c53afbd441fec R0.3333333333333333vc108<ya0 S0.07692307692307693ya5 S0.07692307692307693ya6 S0.07692307692307693yc586 S0.07692307692307693yh25492340 S0.07692307692307693yd1abc S0.07692307692307693yad S0.07692307692307693yc67f S0.07692307692307693yab S0.07692307692307693yac S0.07692307692307693yd05fd S0.07692307692307693yae S0.07692307692307693yc60f S0.07692307692307693>vc1095ya2c0.2yd1bbfc0.2ybefc0.2yc67fc0.2y V096960e13d8578fa544536c0.2vc110<ya2f0.0625ya6e0.125ya7f0.0625ya8f0.0625yc932f0.0625yd5495f0.0625ybc2f0.0625ydd39ff0.0625yaff0.0625ybfef0.0625ybcbf0.0625yd69fcf0.0625ycefbf0.0625yace0.125>vc111<ya2 S0.08333333333333333ya3 S0.08333333333333333yc791 S0.08333333333333333yd78da S0.08333333333333333yc47d S0.08333333333333333yc61c S0.08333333333333333yc91c S0.08333333333333333yf82809a S0.08333333333333333yac S0.08333333333333333yc97a S0.08333333333333333yad S0.08333333333333333yc26d S0.08333333333333333>vc1128ya3e0.125yc536e0.125yc11be0.125yaae0.125yc28be0.125yafe0.125yc34de0.125y Q3606427f835bd3ddfe0.125vc1132ygd8041aec0.5y Y308961666b15aa1e57b0f9f35c0.5vc1143ydd96f R0.3333333333333333yc80f R0.3333333333333333y Y23543850a2ee9fff8cd2cc53f R0.3333333333333333vc1159ya3 R0.1111111111111111yd1841 R0.1111111111111111yd538e R0.1111111111111111ye38fbc R0.1111111111111111yaf R0.1111111111111111yd78cd R0.1111111111111111yc61e R0.1111111111111111yad R0.1111111111111111yi8141ddcc1 R0.1111111111111111vc1161y `b27bdabd8e1a6b7dc06886867331ceb3Qvc117;ya1 S0.08333333333333333ya5 S0.16666666666666666yc226 S0.08333333333333333yd5756 S0.08333333333333333yb6c S0.08333333333333333ybee S0.08333333333333333yg1519fbf S0.08333333333333333yh910197cc S0.08333333333333333yad S0.08333333333333333yac S0.08333333333333333yaa S0.08333333333333333vc118<ya0 S0.06666666666666667ya1 S0.06666666666666667ya2 S0.06666666666666667ya9 S0.06666666666666667yc990 S0.06666666666666667ybee S0.06666666666666667yd62cb S0.06666666666666667yab S0.06666666666666667yaa S0.13333333333333333yc97f S0.06666666666666667ybdf S0.06666666666666667ybed S0.06666666666666667yd0266 S0.06666666666666667ye7027e S0.06666666666666667>vc1193ybba R0.3333333333333333ye45ddd R0.3333333333333333y Y3042dad59a12e5937644f7246 R0.3333333333333333vc1202yc3fdc0.5y ]9052870778e14ab4a5acbc8c24af4c0.5vc121:yc943 S0.09090909090909091yd8883 S0.09090909090909091yd9066 S0.09090909090909091ybd3 S0.09090909090909091ybfa S0.09090909090909091yc23c S0.09090909090909091yaf S0.18181818181818182yc10e S0.09090909090909091ybde S0.09090909090909091yg9340dea S0.09090909090909091vc122;ya6 S0.08333333333333333ya9 S0.16666666666666666yd8534 S0.08333333333333333yd10ae S0.08333333333333333yc016 S0.08333333333333333yae S0.08333333333333333ye19fff S0.08333333333333333ybae S0.08333333333333333yecfaeb S0.08333333333333333ybfa S0.08333333333333333yc47f S0.08333333333333333vc1239ya0 R0.1111111111111111yc818 R0.1111111111111111yd2915 R0.1111111111111111yc04d R0.1111111111111111yecbaac R0.1111111111111111yc08b R0.1111111111111111ybdb R0.1111111111111111yc15e R0.1111111111111111yhbffdcb5b R0.1111111111111111vc124<ya4 S0.14285714285714285ya6 S0.07142857142857142yc410 S0.07142857142857142yc638 S0.07142857142857142yc8cc S0.07142857142857142yab S0.07142857142857142yd19cd S0.07142857142857142yae S0.07142857142857142yaf S0.14285714285714285ydbeaf S0.07142857142857142ye1642f S0.07142857142857142yc52a S0.07142857142857142>vc1251y `d791eaca9375ca1b36a987af22ee71ddQvc1261y `e6684944c37dbdd4c08d978af9e47bedQvc1279ya1 R0.1111111111111111yc459 R0.1111111111111111yc970 R0.1111111111111111ycbbe R0.1111111111111111yddeec R0.1111111111111111yc11d R0.1111111111111111ycbdb R0.1111111111111111yg348051b R0.1111111111111111yeabdaf R0.1111111111111111vc1287yd3829 S0.14285714285714285yda673 S0.14285714285714285yab S0.14285714285714285yae S0.14285714285714285yf62477e S0.14285714285714285ye01abc S0.14285714285714285yk75465416b86 S0.14285714285714285vc129<ya1 S0.07142857142857142ya5 S0.07142857142857142ya6 S0.07142857142857142yc177 S0.07142857142857142yd9767 S0.07142857142857142yc7b6 S0.07142857142857142ybcb S0.07142857142857142yc59a S0.07142857142857142ycabe S0.07142857142857142ybfd S0.07142857142857142yd22da S0.07142857142857142yaa S0.07142857142857142yc03b S0.07142857142857142yae S0.07142857142857142>vc130<ya1 S0.07142857142857142ya3 S0.07142857142857142ya4 S0.07142857142857142ya6 S0.07142857142857142ya7 S0.07142857142857142yf552660 S0.07142857142857142ye4afcb S0.07142857142857142yc20d S0.07142857142857142yad S0.07142857142857142ye95bcd S0.07142857142857142ycbde S0.07142857142857142ybaa S0.07142857142857142yab S0.07142857142857142yaf S0.07142857142857142>vc131:ya1 S0.08333333333333333ya9 S0.16666666666666666yc782 S0.08333333333333333yb7c S0.08333333333333333yc21b S0.08333333333333333yc70f S0.08333333333333333yae S0.08333333333333333yac S0.16666666666666666yaf S0.08333333333333333yn5153268e0cc1c1 S0.08333333333333333vc132<ya0d0.05ya4c0.1ya7d0.05ya9c0.1yc552d0.05yc931d0.05ybf3d0.05yaac0.1yabc0.1yafd0.15ycdfad0.05yd61ced0.05yc39fd0.05yaed0.05>vc1332ybfac0.5y ^0486610d8a02cea245c13c85b6de27c0.5vc134:ya2c0.1yd9504c0.1ydc20dc0.1yf71627ec0.1yc66ac0.1yc044c0.1yabc0.1yf21780fc0.1yc56fc0.1yafc0.1vc1355ya3c0.2yb4fc0.2yc88fc0.2ydeebec0.2y V44285ded812939553ef94cc0.2vc1369ya2 R0.1111111111111111ya4 R0.1111111111111111ya5 R0.1111111111111111yc29b R0.1111111111111111yac R0.1111111111111111yab R0.1111111111111111ydadcd R0.1111111111111111ye80ced R0.1111111111111111yo1612128b3ca95a9 R0.1111111111111111vc1372yc16fc0.5y ]1046144ad9ee7bb96214ba7ae7516c0.5vc1389ya4 R0.1111111111111111yc980 R0.1111111111111111yd002d R0.1111111111111111yad R0.1111111111111111yc74d R0.1111111111111111yc19b R0.1111111111111111yd43ff R0.1111111111111111yae R0.1111111111111111yl2446665e2fe5 R0.1111111111111111vc1391y `550becdd08d00fb1e7fd00c2adc3d3d6Qvc140<ya1 S0.07142857142857142ya3 S0.07142857142857142ya5 S0.07142857142857142ya6 S0.07142857142857142yc292 S0.07142857142857142yha62186ea S0.07142857142857142yad S0.07142857142857142ybdb S0.07142857142857142yc03a S0.07142857142857142yc087 S0.07142857142857142ybbd S0.07142857142857142yddfcc S0.07142857142857142yaf S0.07142857142857142yae S0.07142857142857142>vc141<ya2 S0.08333333333333333ya3 S0.08333333333333333yc198 S0.08333333333333333yd6833 S0.08333333333333333yd167e S0.08333333333333333yaa S0.08333333333333333yad S0.08333333333333333yd49ce S0.08333333333333333ybcb S0.08333333333333333yab S0.08333333333333333yc88f S0.08333333333333333yg521991e S0.08333333333333333>vc142;ya2 S0.09090909090909091ya7 S0.09090909090909091yc289 S0.09090909090909091yc464 S0.09090909090909091yd993e S0.09090909090909091yc58f S0.09090909090909091yg132740b S0.09090909090909091ycecf S0.09090909090909091yd06ee S0.09090909090909091ybdc S0.09090909090909091yab S0.09090909090909091vc143<ya1 S0.06666666666666667ya2 S0.06666666666666667ya8 S0.13333333333333333yc604 S0.06666666666666667ydc56a S0.06666666666666667yd76ef S0.06666666666666667yaf S0.13333333333333333yaa S0.13333333333333333yad S0.06666666666666667yd87be S0.06666666666666667yc32b S0.06666666666666667ye81fac S0.06666666666666667>vc1445yd7462c0.2yc3fcc0.2yaac0.2yd83fac0.2y T55885067fee629287e8ac0.2vc145<ya0 S0.05555555555555555ya1 S0.05555555555555555ya7 S0.05555555555555555ya8 S0.16666666666666666ya9 S0.05555555555555555yc409 S0.05555555555555555yb4b S0.05555555555555555yaa S0.05555555555555555yh768585da S0.05555555555555555yaf S0.16666666666666666ybdb S0.05555555555555555ybca S0.05555555555555555yae S0.05555555555555555ycebd S0.05555555555555555>vc1461y `c54909ecf4fb3e9afeea36200fe95dceQvc1479ya0c0.1ya6c0.1ya9c0.1ygd819ceac0.1ye5197ec0.1yabc0.2ye8673dc0.1yacc0.1yi16659a5eac0.1vc1482yb1bc0.5y ^56132638912a1ca54fcf7cd38b8e23c0.5vc1499ya1c0.2yd4502c0.1yc2eac0.1yd86aec0.1yi5093670dfc0.1yadc0.1ybeac0.1ye82efac0.1ybacc0.1vc1501y `5912529cfd6ce14c5ede5c6c83dae7e8Qvc1511y `15700442e957951307bbcec5fff8643dQvc1523yd018e R0.3333333333333333yc32a R0.3333333333333333y Y8010960eb17e368a6fdd5a51b R0.3333333333333333vc153;ya1 S0.08333333333333333ya3 S0.08333333333333333ya9 S0.08333333333333333yde159 S0.08333333333333333yaa S0.16666666666666666yc35d S0.08333333333333333yab S0.08333333333333333yc46e S0.08333333333333333yf03072a S0.08333333333333333yad S0.08333333333333333yi54780edcb S0.08333333333333333vc154:ya1c0.1ya2c0.1yc505c0.1ybccc0.1yc64cc0.1ygfcdecdbc0.1yabc0.1ye3797ec0.1ydaaaac0.1ye59adcc0.1vc155:ya0c0.1ya5c0.1yc4ccc0.1yd08cac0.1ye51ecfc0.1yafc0.1yg963035fc0.1yc039c0.1ybdec0.1ye6194cc0.1vc1565yc227c0.2yb4bc0.2yadc0.2yc61fc0.2y W33182579cd3edd0ac6c7c44c0.2vc157<ya0 S0.15384615384615385ya2 S0.07692307692307693ya9 S0.07692307692307693yd1739 S0.07692307692307693yc0de S0.07692307692307693ydedbf S0.07692307692307693yaa S0.07692307692307693yg506143c S0.07692307692307693yab S0.07692307692307693yc12e S0.07692307692307693yc94c S0.07692307692307693ybef S0.07692307692307693>vc1581y `744554499cb7880086fbd9b1f080e7e1Qvc1598ya4e0.125ya9e0.125yc950e0.125yb5ae0.125yaee0.125yafe0.125ybace0.125y U186925e5de978c5f72062e0.125vc160<ya0 S0.08333333333333333ya5 S0.08333333333333333ya8 S0.08333333333333333yd8194 S0.08333333333333333ye18500 S0.08333333333333333yc73b S0.08333333333333333ybad S0.08333333333333333ycfce S0.08333333333333333ydcabb S0.08333333333333333yd01cd S0.08333333333333333yc21d S0.08333333333333333yae S0.08333333333333333>vc1618ya0c0.2ya7c0.1yd100cc0.1yaac0.1ye69beac0.1yafc0.2yc02ac0.1yn4540ecaa37d0e3c0.1vc1624yc891d0.25yg809925ed0.25yabd0.25y U0456231c374b09cbe4a90d0.25vc163<ya6 S0.13333333333333333ya8 S0.06666666666666667ya9 S0.06666666666666667yc671 S0.06666666666666667yc722 S0.06666666666666667ybdd S0.06666666666666667yac S0.13333333333333333yc32a S0.06666666666666667ybdc S0.06666666666666667yh815273cd S0.06666666666666667ybed S0.06666666666666667ybcd S0.06666666666666667yab S0.06666666666666667>vc1648ya4c0.2ya8c0.1ya9c0.1ybeec0.1ybffc0.1yaec0.2yaac0.1y U1948795e26af2f3f8a30fc0.1vc165:ya1 S0.16666666666666666yc208 S0.08333333333333333yc351 S0.08333333333333333yc801 S0.08333333333333333ydf887 S0.08333333333333333yae S0.16666666666666666ydaabf S0.08333333333333333ycbfb S0.08333333333333333yf39698f S0.08333333333333333ybaf S0.08333333333333333vc166:ya0c0.1ya2c0.1ya6c0.1ya8c0.1yc9ccc0.1yaac0.1yabc0.1yacc0.1ybbec0.1y T1405cddcdeb4487c59fec0.1vc1674yd7998d0.25yc18bd0.25yaad0.25y X871950ebc36c415a53630477d0.25vc168;ya0 S0.08333333333333333yc522 S0.08333333333333333yc956 S0.08333333333333333yd6357 S0.08333333333333333yd7669 S0.08333333333333333ye83454 S0.08333333333333333ydddab S0.08333333333333333ybff S0.08333333333333333yac S0.16666666666666666ycebd S0.08333333333333333yae S0.08333333333333333vc1694yc318d0.25yf55188ad0.25yacd0.25y V5998989255253e15ccc1f6d0.25vc1708yc389 R0.1111111111111111yc605 R0.1111111111111111yd7787 R0.1111111111111111yc75d R0.1111111111111111yi9268739fe R0.1111111111111111ybac R0.2222222222222222yc02d R0.1111111111111111ycfeb R0.1111111111111111vc1715yc23ac0.2yc22dc0.2yg1411afbc0.2yg787810dc0.2yl68210e6fad4fc0.2vc172<ya1 S0.07142857142857142ya2 S0.07142857142857142ya4 S0.07142857142857142ya6 S0.07142857142857142ya8 S0.07142857142857142ye615db S0.07142857142857142yaa S0.07142857142857142yc24f S0.07142857142857142yc36d S0.07142857142857142yc19a S0.07142857142857142yceaf S0.07142857142857142yc18d S0.07142857142857142yedceed S0.07142857142857142yab S0.07142857142857142>vc173<ya1 S0.07692307692307693ya2 S0.07692307692307693ya3 S0.07692307692307693ya7 S0.07692307692307693yb40 S0.07692307692307693yf8d7caf S0.07692307692307693yc84b S0.07692307692307693yaa S0.07692307692307693ye51cca S0.07692307692307693yf27291c S0.07692307692307693yaf S0.07692307692307693yccfc S0.07692307692307693yad S0.07692307692307693>vc1741y `7249710187cc2d983709e044dbc78d9dQvc1754yg563864ad0.25yg949924cd0.25yg505985ad0.25yk168191dcb84d0.25vc176;ya1 S0.16666666666666666ya6 S0.08333333333333333yc145 S0.08333333333333333yc869 S0.08333333333333333yg24357fe S0.08333333333333333yac S0.08333333333333333ybec S0.08333333333333333yf82fdfc S0.08333333333333333ye8134a S0.08333333333333333yaa S0.08333333333333333yad S0.08333333333333333vc177;ya5 S0.09090909090909091ya7 S0.09090909090909091ya9 S0.09090909090909091yc703 S0.09090909090909091yg19ecbaa S0.09090909090909091yae S0.09090909090909091yc12f S0.09090909090909091yaa S0.09090909090909091yeebcff S0.09090909090909091yac S0.09090909090909091yh79534a52 S0.09090909090909091vc178<ya0 S0.05555555555555555ya4 R0.1111111111111111ya8 R0.1111111111111111ya9 S0.05555555555555555yc509 S0.05555555555555555ycced S0.05555555555555555ybdf S0.05555555555555555yad S0.05555555555555555yac R0.1111111111111111ybed S0.05555555555555555yd14de S0.05555555555555555yc91c S0.05555555555555555yab S0.05555555555555555yc31b S0.05555555555555555ybae S0.05555555555555555>vc179<ya4 S0.06666666666666667ya7 S0.06666666666666667ya8 S0.06666666666666667yc466 S0.06666666666666667ybcb S0.06666666666666667yc13b S0.06666666666666667yc64d S0.06666666666666667yd0127 S0.06666666666666667yac S0.13333333333333333yd13bb S0.06666666666666667yad S0.06666666666666667ye4677a S0.06666666666666667yab S0.06666666666666667yaa S0.06666666666666667>vc180<ya2 S0.06666666666666667ya4 S0.06666666666666667ya5 S0.13333333333333333ya6 S0.06666666666666667ya8 S0.06666666666666667yef2cbe S0.06666666666666667yd07bf S0.06666666666666667ybff S0.06666666666666667yc16d S0.06666666666666667yaa S0.06666666666666667ye5860b S0.06666666666666667yad S0.06666666666666667ydedbc S0.06666666666666667yae S0.06666666666666667>vc181<ya3 S0.08333333333333333ya5 S0.08333333333333333yc459 S0.08333333333333333yceee S0.08333333333333333yc039 S0.08333333333333333yaf S0.08333333333333333yc49a S0.08333333333333333yab S0.08333333333333333yh570599cf S0.08333333333333333yac S0.08333333333333333yc55c S0.08333333333333333yd649f S0.08333333333333333>vc182<ya3 S0.06666666666666667ya4 S0.06666666666666667ya6 S0.13333333333333333yc298 S0.06666666666666667yc888 S0.06666666666666667ycddd S0.06666666666666667yae S0.13333333333333333yaf S0.06666666666666667yad S0.13333333333333333yg3884abc S0.06666666666666667yaa S0.06666666666666667yf043664 S0.06666666666666667>vc183<ya0 S0.15384615384615385ya2 S0.07692307692307693ya4 S0.07692307692307693yb5b S0.07692307692307693ye97ead S0.07692307692307693yc91c S0.07692307692307693ybdd S0.07692307692307693ycbad S0.07692307692307693yc57b S0.07692307692307693yaf S0.07692307692307693yc43a S0.07692307692307693yf89149a S0.07692307692307693>vc184;ya7 S0.09090909090909091yc135 S0.09090909090909091yc432 S0.09090909090909091yf997acc S0.09090909090909091yad S0.09090909090909091yc01b S0.09090909090909091yc54f S0.09090909090909091ybde S0.09090909090909091yc77a S0.09090909090909091ybfb S0.09090909090909091ye9133f S0.09090909090909091vc185;ya0 S0.09090909090909091ya7 S0.09090909090909091yd1fed S0.09090909090909091yc22e S0.09090909090909091yc99b S0.09090909090909091yae S0.09090909090909091yc11a S0.09090909090909091yd50eb S0.09090909090909091yab S0.09090909090909091yd92cb S0.09090909090909091yg1644e8a S0.09090909090909091vc186;ya5 S0.07692307692307693ya6 S0.15384615384615385ya7 S0.07692307692307693ya9 S0.07692307692307693ye5badf S0.07692307692307693ye61ecb S0.07692307692307693yecfadd S0.07692307692307693yad S0.07692307692307693ybaf S0.07692307692307693yg58712fa S0.07692307692307693yaf S0.15384615384615385vc187<ya4 S0.07142857142857142ya6 S0.14285714285714285ya9 S0.07142857142857142ybfe S0.07142857142857142ybba S0.07142857142857142yd10cc S0.07142857142857142yac S0.07142857142857142ye9509b S0.07142857142857142yab S0.07142857142857142yc22e S0.07142857142857142yad S0.07142857142857142yc59e S0.07142857142857142yf029775 S0.07142857142857142>vc1881y `b36abffbe5d6a0de73a9968604a1a3f9Qvc1892ybcbc0.5y ^9649eca3dfbd356527ffc88f1dcb94c0.5vc1905yc465c0.2yd7deac0.2ybadc0.2yf52758bc0.2y Q10cbceb08c81d1760c0.2vc191;ya2 S0.09090909090909091ya3 S0.09090909090909091yd6458 S0.09090909090909091ycbce S0.09090909090909091ybfa S0.09090909090909091yaf S0.09090909090909091yc39a S0.09090909090909091yc75e S0.09090909090909091ye2713f S0.09090909090909091yad S0.09090909090909091yh687271a1 S0.09090909090909091vc1921y `e5390751969ab21df280b7591854b89fQvc193;ya0 S0.08333333333333333ya2 S0.08333333333333333yc130 S0.08333333333333333yc657 S0.08333333333333333yf05330c S0.08333333333333333ye3703d S0.08333333333333333yae S0.08333333333333333yac S0.16666666666666666ye96cfe S0.08333333333333333ybab S0.08333333333333333yc33f S0.08333333333333333vc1949ya3c0.1ya5c0.1ya9c0.1yb4ac0.1yacc0.2yc42cc0.1ybacc0.1yd29dbc0.1y P268010bbebf4f579c0.1vc1953yc1bc R0.3333333333333333yf36080b R0.3333333333333333y W2493aab78c26e4f2152542c R0.3333333333333333vc1965yc582c0.2yc2dec0.2yacc0.2ye67fcac0.2y T31500621ecd6d3917a07c0.2vc197<ya0f0.0625ya3f0.0625ya4f0.0625ya8f0.0625ya9f0.0625yc895f0.0625yb0af0.0625yg8183cedf0.0625yaed0.25yabf0.0625yf41286ef0.0625yc54ef0.0625yadf0.0625>vc198<ya5 T0.058823529411764705ya7 T0.058823529411764705ya8 S0.11764705882352941ya9 T0.058823529411764705yc581 T0.058823529411764705yc602 T0.058823529411764705yb4d T0.058823529411764705yaf T0.058823529411764705yae T0.058823529411764705yceee T0.058823529411764705yac T0.058823529411764705ybfd T0.058823529411764705yd21da T0.058823529411764705ybeb T0.058823529411764705yd68df T0.058823529411764705yaa T0.058823529411764705>vc199<ya1f0.0625ya3f0.0625ya4f0.0625ya7f0.0625ya8f0.0625yc399f0.0625yc597f0.0625yd937af0.0625yaaf0.0625yabf0.0625ybfdf0.0625yf32cabaf0.0625yc88af0.0625yace0.125ybbcf0.0625>vc200;ya3 S0.09090909090909091yd1298 S0.09090909090909091yd8412 S0.09090909090909091yb2a S0.09090909090909091ybaa S0.09090909090909091yc50d S0.09090909090909091yf07330f S0.09090909090909091yaf S0.09090909090909091yd0243 S0.09090909090909091ybfa S0.09090909090909091yc79d S0.09090909090909091vc201;ya3 S0.08333333333333333ya7 S0.08333333333333333yd2023 S0.08333333333333333ydd266 S0.08333333333333333yaa S0.16666666666666666yac S0.08333333333333333yc67b S0.08333333333333333yc20c S0.08333333333333333ybbd S0.08333333333333333yf01055b S0.08333333333333333ye223bc S0.08333333333333333vc2022ybbcc0.5y ^2709406a9bb19e8d83a78f81e36244c0.5vc2037yc745 S0.14285714285714285yd8608 S0.14285714285714285yf998eda S0.14285714285714285yad S0.14285714285714285yd07fd S0.14285714285714285yaf S0.14285714285714285ym251138384a0b9 S0.14285714285714285vc204<ya0f0.0625ya1e0.125ya2f0.0625ya7e0.125yc986f0.0625yf853cacf0.0625yafe0.125yade0.125yc90bf0.0625yacf0.0625yaef0.0625yhdcdbbfdef0.0625>vc2051y `4616fbea6a6dbc1074bc3f1016bbc73bQvc2067ya9 S0.14285714285714285yd1863 S0.14285714285714285yhf15702ae S0.14285714285714285yae S0.14285714285714285ye55bad S0.14285714285714285yg42182cf S0.14285714285714285yf18724d S0.14285714285714285vc2074yc965d0.25yc77dd0.25yfafaebdd0.25y T7193badc746d52b4173fd0.25vc208<ya8 S0.07692307692307693ya9 S0.07692307692307693yb86 S0.07692307692307693yc405 S0.07692307692307693yc750 S0.07692307692307693ydbdea S0.07692307692307693yc71d S0.07692307692307693yg64cdfcc S0.07692307692307693yae S0.07692307692307693yc65e S0.07692307692307693ybfe S0.07692307692307693yad S0.07692307692307693yab S0.07692307692307693>vc209<ya1 S0.06666666666666667ya2 S0.06666666666666667ya5 S0.06666666666666667yc605 S0.06666666666666667yc721 S0.06666666666666667yc830 S0.06666666666666667yd6490 S0.06666666666666667yc7cc S0.06666666666666667yae S0.13333333333333333ycfdd S0.06666666666666667yad S0.06666666666666667ycccc S0.06666666666666667yc16f S0.06666666666666667yab S0.06666666666666667>vc210<ya1 S0.07692307692307693ya2 S0.07692307692307693ya4 S0.15384615384615385ya6 S0.07692307692307693ybfb S0.07692307692307693ybda S0.07692307692307693yaa S0.07692307692307693ybed S0.07692307692307693yg74705ad S0.07692307692307693yd98bb S0.07692307692307693yd60ad S0.07692307692307693yebadaf S0.07692307692307693>vc2114yd1821d0.25yb0cd0.25yadd0.25y Y1069578551d0e3c7d9275f16bd0.25vc2124ybe3d0.25yaed0.25yh146469edd0.25y U4318eaa2ffbca3510c054d0.25vc213<ya4 S0.06666666666666667ya6 S0.06666666666666667ya8 S0.13333333333333333yc604 S0.06666666666666667yd6324 S0.06666666666666667yc21a S0.06666666666666667yaec0.2ye9330d S0.06666666666666667yaf S0.06666666666666667yeebade S0.06666666666666667yac S0.06666666666666667yc62b S0.06666666666666667>vc214:ya0 S0.09090909090909091ya1 S0.09090909090909091yc293 S0.09090909090909091yc832 S0.09090909090909091yf40abea S0.09090909090909091yaa S0.18181818181818182yc87a S0.09090909090909091yd64bd S0.09090909090909091ycfad S0.09090909090909091yf69458b S0.09090909090909091vc2157ya5e0.125yd1790e0.125yf916bdae0.125yd59bce0.125ye7621de0.125yacd0.25yj040572a3c0e0.125vc2164ya6d0.25yc5bbd0.25yafd0.25y [8322cdbda7a21e4aecbe04462b7d0.25vc217<ya0 S0.08333333333333333ya8 S0.08333333333333333yc595 S0.08333333333333333yc804 S0.08333333333333333yc825 S0.08333333333333333yga578acf S0.08333333333333333yaa S0.08333333333333333ybce S0.08333333333333333yd95fe S0.08333333333333333yaf S0.08333333333333333yab S0.08333333333333333ye7208f S0.08333333333333333>vc218<ya4 S0.07142857142857142ya6 S0.14285714285714285yd706c S0.07142857142857142yc033 S0.07142857142857142yab S0.14285714285714285ye4483b S0.07142857142857142yad S0.07142857142857142yc062 S0.07142857142857142yc66d S0.07142857142857142yae S0.07142857142857142ybea S0.07142857142857142ye0236a S0.07142857142857142>vc2197ya0 S0.14285714285714285yd7853 S0.14285714285714285yd72df S0.14285714285714285ybbf S0.14285714285714285yae S0.14285714285714285yf05560d S0.14285714285714285yn94208817b83468 S0.14285714285714285vc220<ya3 T0.058823529411764705ya4 S0.11764705882352941ya6 T0.058823529411764705ya7 T0.058823529411764705ya8 T0.058823529411764705yc994 T0.058823529411764705yd91fe T0.058823529411764705yc03f T0.058823529411764705yae S0.17647058823529413yf85cede T0.058823529411764705ybbd T0.058823529411764705yc62f T0.058823529411764705yad T0.058823529411764705yab T0.058823529411764705>vc2215ya5c0.2ybedc0.2yb4fc0.2yaac0.2y Z398056eef1cf6caa90786b340ac0.2vc2222yg2824befc0.5y Y72110575c78aeb979170212b8c0.5vc223<ya0 S0.07692307692307693ya1 S0.07692307692307693yc590 S0.07692307692307693yc823 S0.07692307692307693yd9274 S0.07692307692307693yge396cbf S0.07692307692307693yab S0.07692307692307693yaa S0.15384615384615385yad S0.07692307692307693yd94ee S0.07692307692307693yc43d S0.07692307692307693ybbd S0.07692307692307693>vc224;ya0 S0.08333333333333333ya4 S0.08333333333333333ya5 S0.08333333333333333ya8 S0.08333333333333333yc754 S0.08333333333333333yf50562b S0.08333333333333333yg09417cd S0.08333333333333333yac S0.08333333333333333yaa S0.16666666666666666ye2348a S0.08333333333333333ydaabe S0.08333333333333333vc225:ya1c0.1ya7c0.1ya9c0.1yh65124517c0.1yc76ac0.1ybfbc0.1yafc0.1ye21fdac0.1ydeddbc0.1yf95426bc0.1vc2261y `299abcee56b05b312ed5700f686f79b8Qvc2273yg670744b R0.3333333333333333yh945088de R0.3333333333333333y Q05866864f7d57bee7 R0.3333333333333333vc2281y `c1241374502f200cf9fc49c8d6fb5822Qvc2291y `d51032bef3e7117a94336fea18a3fad7Qvc2306ya2 S0.16666666666666666yi65453a1ae S0.16666666666666666yh403679bd S0.16666666666666666yae S0.16666666666666666yf47398a S0.16666666666666666yg04205ca S0.16666666666666666vc231:ya4c0.1ya5c0.1yd9856c0.1ycabcc0.1ybcac0.1yaac0.1yg61831fdc0.1ybedc0.1yc06bc0.1yh402875d2c0.1vc232<ya1e0.125ya7f0.0625ya9f0.1875yc647f0.0625ye386dcf0.0625yadf0.0625yabf0.0625yaaf0.0625yaff0.0625ye3965ff0.0625ycfbef0.0625yc29cf0.0625ycdfbf0.0625>vc233;ya2 S0.08333333333333333ya7 S0.08333333333333333yc562 S0.08333333333333333yd4581 S0.08333333333333333yd5157 S0.08333333333333333yc9ad S0.08333333333333333yc72c S0.08333333333333333yaa S0.16666666666666666yaf S0.08333333333333333yg21741bd S0.08333333333333333ycdfc S0.08333333333333333vc2342ydf55dc0.5y \33371dcff207fd7d201128df2ea3c0.5vc2354ya7d0.25yd229bd0.25ybfcd0.25y Y784707b1d2c702fbeba080e86d0.25vc236<ya1 S0.07142857142857142ya6 S0.07142857142857142ya7 S0.07142857142857142ya9 S0.07142857142857142yc333 S0.07142857142857142yd4924 S0.07142857142857142yfc98cbc S0.07142857142857142ybfb S0.07142857142857142yad S0.07142857142857142yc95c S0.07142857142857142yac S0.07142857142857142ybfc S0.07142857142857142yab S0.07142857142857142ye0526e S0.07142857142857142>vc237:yb84 S0.09090909090909091yc252 S0.09090909090909091yd1373 S0.09090909090909091ygc6107ff S0.09090909090909091yc57e S0.09090909090909091yc96a S0.09090909090909091yac S0.18181818181818182yc019 S0.09090909090909091yad S0.09090909090909091yd00ad S0.09090909090909091vc238<ya2 S0.07692307692307693ya3 S0.07692307692307693ya4 S0.07692307692307693yc350 S0.07692307692307693yc970 S0.07692307692307693yg3227411 S0.07692307692307693ygf6debed S0.07692307692307693yaf S0.07692307692307693yc20a S0.07692307692307693yab S0.07692307692307693ybaa S0.07692307692307693yad S0.07692307692307693yae S0.07692307692307693>vc2396yc586 S0.14285714285714285yd7199 S0.14285714285714285ybc4 S0.14285714285714285yae S0.14285714285714285yaa R0.2857142857142857y T308352b7a881add7e356 S0.14285714285714285vc240;ya1 S0.09090909090909091ya5 S0.09090909090909091yc482 S0.09090909090909091yc15f S0.09090909090909091yg501351d S0.09090909090909091ycffd S0.09090909090909091yf73985a S0.09090909090909091yc50f S0.09090909090909091yac S0.09090909090909091yc89d S0.09090909090909091yaf S0.09090909090909091vc2413yd6425 R0.3333333333333333ybaf R0.3333333333333333y Z51edead39c0e439073986043fb R0.3333333333333333vc242:yc493c0.1yc532c0.1yc715c0.1yc10cc0.1yafc0.1yd70dec0.1ye25ccbc0.1ydbbbbc0.1yabc0.1ye78cedc0.1vc243<ya0 S0.07692307692307693ya6 S0.07692307692307693ya7 S0.07692307692307693yd1039 S0.07692307692307693ydc18b S0.07692307692307693ye12fff S0.07692307692307693yd24dc S0.07692307692307693yc87e S0.07692307692307693yaf S0.07692307692307693ybbd S0.07692307692307693yc17c S0.07692307692307693yac S0.07692307692307693ybaa S0.07692307692307693>vc244<ya4 S0.06666666666666667ya6 S0.06666666666666667ya7 S0.06666666666666667yc907 S0.06666666666666667yc956 S0.06666666666666667yd2619 S0.06666666666666667ybcb S0.13333333333333333yb5b S0.06666666666666667yaf S0.06666666666666667ybab S0.06666666666666667yad S0.06666666666666667yc36e S0.06666666666666667yc90d S0.06666666666666667ycebb S0.06666666666666667>vc2453yba0 R0.3333333333333333yda00c R0.3333333333333333y Z23556fcc5dbfb7b7f43fbbb61d R0.3333333333333333vc2461y `d9560caeb797b302191f667b4264da40Qvc247:ya1c0.1ya3c0.1ya6c0.1ya9c0.1yfa2012ac0.1yacc0.1yccdbc0.1yadc0.1ybfdc0.1yo69afdbadc1e76b6c0.1vc248:ya5c0.1ya7c0.1yf13684dc0.1ye16fddc0.1yc07dc0.1yafc0.1yd0584c0.1yaec0.1yf29265ac0.1yd270ec0.1vc2498ya4e0.125yc823e0.125yc66fe0.125yd43abe0.125yabe0.125yade0.125yc67fe0.125y P52735bbbe6ba65b0e0.125vc2507ya1 R0.2222222222222222ya7 R0.1111111111111111yda106 R0.1111111111111111yad R0.1111111111111111yac R0.1111111111111111yab R0.2222222222222222y U277538367f9c8140e3a75 R0.1111111111111111vc2516yc353 S0.16666666666666666yc844 S0.16666666666666666yd9dca S0.16666666666666666yad S0.16666666666666666ydefed S0.16666666666666666y Q03fbaddfc0fab7c76 S0.16666666666666666vc252<ya0 T0.058823529411764705ya1 T0.058823529411764705ya4 T0.058823529411764705ya5 T0.058823529411764705yc475 T0.058823529411764705yc628 T0.058823529411764705yc857 T0.058823529411764705ybb5 T0.058823529411764705yac S0.17647058823529413yab T0.058823529411764705ycdbf T0.058823529411764705yaa T0.058823529411764705ybbe T0.058823529411764705ybde T0.058823529411764705ye4690d T0.058823529411764705>vc2537ya5 S0.14285714285714285ya8 S0.14285714285714285ye0302e S0.14285714285714285yaa S0.14285714285714285yc57a S0.14285714285714285yae S0.14285714285714285y T8604342a925b2dc60737 S0.14285714285714285vc2544yc127d0.25yc76ed0.25yaad0.25y Y44931bfefab991be3dd7a08b7d0.25vc2551y `e1870dde155be1a375f155dd1f7ead13Qvc2563ybd2 R0.3333333333333333yae R0.3333333333333333y ]805472f79f0b558f75b90b5e7b4ee R0.3333333333333333vc2579ya3 R0.1111111111111111ya8 R0.1111111111111111yc647 R0.1111111111111111yc79e R0.1111111111111111yaa R0.1111111111111111yaf R0.1111111111111111yab R0.1111111111111111yc36a R0.1111111111111111y R1221897f5837c84aff R0.1111111111111111vc2586ya3 S0.16666666666666666ya8 S0.16666666666666666ye5931f S0.16666666666666666yae S0.16666666666666666yeacdac S0.16666666666666666y S724742c4ee0960d8d40 S0.16666666666666666vc2594yc463d0.25yi3931327edd0.25yadd0.25y S1568868c5ab8e839148d0.25vc260;ya5 S0.09090909090909091ya6 S0.09090909090909091yb50 S0.09090909090909091yd2271 S0.09090909090909091yc33e S0.09090909090909091yc01e S0.09090909090909091ybbe S0.09090909090909091yc22b S0.09090909090909091ybed S0.09090909090909091yh330045fe S0.09090909090909091ycaff S0.09090909090909091vc2616ya1 S0.16666666666666666ya9 S0.16666666666666666ybcd S0.16666666666666666ybba S0.16666666666666666yaf S0.16666666666666666y Y582642d9cbe500f018afab341 S0.16666666666666666vc262<ya3 S0.07142857142857142ya4 S0.07142857142857142ya6 S0.07142857142857142yb92 S0.07142857142857142yc444 S0.07142857142857142ydb875 S0.07142857142857142yaf S0.07142857142857142yc24d S0.07142857142857142yad S0.07142857142857142ydfdda S0.07142857142857142yc82b S0.07142857142857142ydbbfb S0.07142857142857142yc75a S0.07142857142857142yac S0.07142857142857142>vc2637ya1e0.125yd7206e0.125yd7664e0.125yc59de0.125yabe0.125yaed0.25y Q76672d3de4dc9a8ede0.125vc264;ya0 S0.08333333333333333ya5 S0.08333333333333333ya9 S0.08333333333333333yb1b S0.08333333333333333yac S0.16666666666666666ybae S0.08333333333333333yd60ec S0.08333333333333333yd46be S0.08333333333333333yc64a S0.08333333333333333ye1877f S0.08333333333333333yg6920edc S0.08333333333333333vc265<ya1 S0.07142857142857142ya3 S0.14285714285714285ya9 S0.07142857142857142yc455 S0.07142857142857142yd4555 S0.07142857142857142yd5433 S0.07142857142857142yf50557b S0.07142857142857142yccba S0.07142857142857142yaa S0.07142857142857142ybce S0.07142857142857142yab S0.07142857142857142ybfc S0.07142857142857142ybfd S0.07142857142857142>vc2669ya0 R0.1111111111111111ya8 R0.1111111111111111yd146e R0.1111111111111111ybca R0.1111111111111111yc40c R0.1111111111111111yad R0.1111111111111111yc37f R0.1111111111111111yg36eecea R0.1111111111111111yj822028dd9e R0.1111111111111111vc267;ya1 S0.08333333333333333yc181 S0.08333333333333333yd8077 S0.08333333333333333yda98d S0.08333333333333333yd42be S0.08333333333333333yac S0.08333333333333333yc01b S0.08333333333333333yae S0.08333333333333333yc060 S0.08333333333333333yab S0.16666666666666666yf5080ec S0.08333333333333333vc2684ya3d0.25ycecfd0.25ybacd0.25y Z80454654d990d9c07d33d35d1cd0.25vc2692yc26cc0.5y ]47355cbe966a94826cbe2fbf2b355c0.5vc270;ya2 S0.09090909090909091ya7 S0.09090909090909091ya8 S0.09090909090909091yc889 S0.09090909090909091yf33919e S0.09090909090909091yh866426ce S0.09090909090909091yae S0.09090909090909091yab S0.09090909090909091ybce S0.09090909090909091yc06f S0.09090909090909091ye19bbf S0.09090909090909091vc271:ya4 S0.09090909090909091ya6 S0.09090909090909091ya9 S0.09090909090909091yc953 S0.09090909090909091yd8964 S0.09090909090909091yf78292d S0.09090909090909091yfeafbdf S0.09090909090909091yae S0.18181818181818182yd57cc S0.09090909090909091ydbbbe S0.09090909090909091vc272<ya0 S0.07142857142857142ya3 S0.07142857142857142ya8 S0.07142857142857142yc623 S0.07142857142857142yc917 S0.07142857142857142ybc4 S0.07142857142857142yad S0.07142857142857142yaa S0.07142857142857142yaf S0.14285714285714285yg58646ce S0.07142857142857142yf93015d S0.07142857142857142yc79e S0.07142857142857142yae S0.07142857142857142>vc273<ya1 S0.06666666666666667ya2 S0.06666666666666667ya4 S0.06666666666666667ya5 S0.06666666666666667ya7 S0.06666666666666667yd7737 S0.06666666666666667ydd12c S0.06666666666666667yac S0.13333333333333333yaa S0.13333333333333333yd68be S0.06666666666666667ycfda S0.06666666666666667yad S0.06666666666666667yg5493b4d S0.06666666666666667>vc2741y `f45069216cd934b80ce882c9a2f2a08aQvc275<ya2c0.1ya3d0.05ya6d0.15ya8d0.05ya9d0.05yc1fed0.05yc14ed0.05yaec0.2yc02bd0.05yc65ed0.05ybaed0.05yadd0.05ydddccd0.05yafd0.05>vc2761y `e30258aeb8475d4c27f7935945671856Qvc2775yc912c0.2ybcdc0.2ye90bcec0.2yafc0.2y U5743226af94c1efaaa4a7c0.2vc2782yh494557dbc0.5y X52824555864d1106278cd1f0c0.5vc2792yc16fc0.5y ]10764f0ccce42d5be8cfeac36b446c0.5vc2804yd4002d0.25yddbccd0.25yacd0.25y W15afefef853a08a0804ba3ad0.25vc2813yc11d R0.3333333333333333yi4726484be R0.3333333333333333y T418849e1f4200ade9535 R0.3333333333333333vc2824ybdbd0.25yf97311cd0.25yf24809fd0.25y R103575d8a7fee19680d0.25vc2836ya4 S0.16666666666666666ya9 S0.16666666666666666yd286a S0.16666666666666666yaa S0.16666666666666666ybee S0.16666666666666666y W373398d7d2c93862c5f6661 S0.16666666666666666vc2847yd5219 S0.14285714285714285yc99f S0.14285714285714285ybda S0.14285714285714285yf22485d S0.14285714285714285yd0872 S0.14285714285714285yaa S0.14285714285714285yl2529599c8440 S0.14285714285714285vc285<ya0 S0.21428571428571427ya5 S0.07142857142857142yb35 S0.07142857142857142yd3211 S0.07142857142857142yd36ff S0.07142857142857142ye37ced S0.07142857142857142yad S0.07142857142857142ybdb S0.07142857142857142yc95a S0.07142857142857142ybac S0.07142857142857142yddaac S0.07142857142857142yac S0.07142857142857142>vc286;yc949 S0.09090909090909091yc984 S0.09090909090909091yd1826 S0.09090909090909091yd5339 S0.09090909090909091yc1ca S0.09090909090909091yc04e S0.09090909090909091ybed S0.09090909090909091yac S0.09090909090909091yd12fe S0.09090909090909091yd61fd S0.09090909090909091yae S0.09090909090909091vc287;ya0 S0.08333333333333333ya2 S0.16666666666666666ya4 S0.08333333333333333yc73d S0.08333333333333333ycfce S0.08333333333333333ycefa S0.08333333333333333yf52675b S0.08333333333333333yc35a S0.08333333333333333yd11ee S0.08333333333333333yd97bc S0.08333333333333333ybdb S0.08333333333333333vc288<ya0 S0.11764705882352941ya2 T0.058823529411764705ya3 T0.058823529411764705ya4 T0.058823529411764705ya8 T0.058823529411764705yc160 T0.058823529411764705yc479 T0.058823529411764705yc26d T0.058823529411764705yac S0.11764705882352941yad T0.058823529411764705yh465087cf T0.058823529411764705yaa T0.058823529411764705ycbdc T0.058823529411764705yaf T0.058823529411764705yab T0.058823529411764705>vc289;ya4 S0.09090909090909091yc234 S0.09090909090909091yd4389 S0.09090909090909091ybf5 S0.09090909090909091ydf28f S0.09090909090909091yd42ad S0.09090909090909091yab S0.09090909090909091ybaf S0.09090909090909091ydcbea S0.09090909090909091yd54ff S0.09090909090909091yc60d S0.09090909090909091vc290<ya0 S0.07692307692307693ya4 S0.07692307692307693yb13 S0.07692307692307693yc505 S0.07692307692307693yd5412 S0.07692307692307693yd6670 S0.07692307692307693ybfb S0.07692307692307693yf82160d S0.07692307692307693yaf S0.15384615384615385ye6093e S0.07692307692307693yab S0.07692307692307693yac S0.07692307692307693>vc2913ydb051 R0.3333333333333333ybfd R0.3333333333333333y Z352847c06e748b345e8ed0738b R0.3333333333333333vc2924ya4d0.25ybbfd0.25yafd0.25y \86812812dab8d39db9aaefe94a78d0.25vc2931y `322264a17ef7182eb1475bd2eaebc2ebQvc294<ya3 S0.06666666666666667ya6 S0.06666666666666667ya8 S0.13333333333333333ya9 S0.06666666666666667yd2845 S0.06666666666666667ye38128 S0.06666666666666667yf20110c S0.06666666666666667yaf S0.06666666666666667ybda S0.06666666666666667ye8304b S0.06666666666666667yad S0.13333333333333333yac S0.06666666666666667yaa S0.06666666666666667>vc2954yd992ad0.25yc00cd0.25yf30242bd0.25y S6217243f3c387ea18b7d0.25vc296:ya0 S0.09090909090909091ya1 S0.18181818181818182yb4c S0.09090909090909091yc08b S0.09090909090909091yc67e S0.09090909090909091yac S0.09090909090909091yefdeef S0.09090909090909091yc50b S0.09090909090909091ydfdcc S0.09090909090909091yh32cdcee2 S0.09090909090909091vc2975yb4ac0.2ye30eebc0.2yc083c0.2ydacecc0.2y R8460150068ba0c6743c0.2vc298<ya0 S0.07142857142857142ya1 S0.07142857142857142ya2 S0.07142857142857142ya9 S0.14285714285714285yc475 S0.07142857142857142yd898d S0.07142857142857142yc25a S0.07142857142857142ybab S0.07142857142857142yac S0.07142857142857142ybba S0.07142857142857142ybfa S0.07142857142857142ycbad S0.07142857142857142yg462405e S0.07142857142857142>vc299<ya0e0.125ya1e0.125ya7e0.125yde01ef0.0625yc01df0.0625yf18582cf0.0625yaff0.0625yc69ef0.0625yabe0.125ybdbf0.0625yaef0.0625yd111af0.0625>vc3002yb7ec0.5y ^23419e4fc69b5b533815681c9bb1a9c0.5vc301:yc323c0.1yc625c0.1yc997c0.1ye34850c0.1yc98cc0.1yg640616fc0.1yaac0.1ybafc0.1yaec0.1yd34bac0.1vc302;ya1 S0.14285714285714285ya8 S0.07142857142857142yc407 S0.07142857142857142yc517 S0.07142857142857142yd5595 S0.07142857142857142ye922cc S0.07142857142857142yd71fd S0.07142857142857142yc28b S0.07142857142857142ycdac S0.07142857142857142yaf S0.21428571428571427yad S0.07142857142857142vc3031y `43501cdf0de25278a208cbb9aad80012Qvc304:ya3c0.1ya7c0.1yc788c0.1yh61173291c0.1yf89abaac0.1yafc0.1yd21cfc0.1ybcec0.1ye4744ec0.1yaec0.1vc3056ya5 S0.16666666666666666yc307 S0.16666666666666666yg7604edf S0.16666666666666666yaa S0.16666666666666666yae S0.16666666666666666y S96120606c8dda06458f S0.16666666666666666vc3061y `775894425f5a7436f56fc5a3b4a2cfaaQvc307<ya1 S0.06666666666666667ya4 S0.06666666666666667ya7 S0.13333333333333333yc264 S0.06666666666666667yb8a S0.06666666666666667yc29f S0.06666666666666667yc62d S0.06666666666666667yebebfe S0.06666666666666667yab S0.13333333333333333ye8008d S0.06666666666666667yaf S0.06666666666666667yc56b S0.06666666666666667yae S0.06666666666666667>vc3084ya2d0.25yc7fad0.25yafd0.25y [0877831b4c924438396760f1841d0.25vc309<ya2f0.0625ya7f0.0625ya8f0.0625yc240f0.0625yc521f0.0625yc885f0.0625yc68af0.0625yaff0.1875yc34cf0.0625yaaf0.0625yd42abf0.0625yadf0.0625ybaaf0.0625yc33cf0.0625>vc310;ya7 S0.09090909090909091yc433 S0.09090909090909091yc9ac S0.09090909090909091ybbb S0.09090909090909091yc94e S0.09090909090909091yd60dc S0.09090909090909091yc30a S0.09090909090909091yc023 S0.09090909090909091ybce S0.09090909090909091ybde S0.09090909090909091yf027364 S0.09090909090909091vc311<ya0 S0.07142857142857142ya2 S0.07142857142857142ya3 S0.07142857142857142yb57 S0.07142857142857142yc617 S0.07142857142857142ycdcc S0.07142857142857142yae S0.07142857142857142yd24df S0.07142857142857142yf32287e S0.07142857142857142yd89ee S0.07142857142857142yab S0.07142857142857142yaf S0.14285714285714285yc64d S0.07142857142857142>vc312<ya0 S0.07692307692307693ya2 S0.07692307692307693yb61 S0.07692307692307693yc938 S0.07692307692307693yd8acc S0.07692307692307693yd78be S0.07692307692307693yc63e S0.07692307692307693yc27e S0.07692307692307693ybee S0.07692307692307693yd53ec S0.07692307692307693yac S0.07692307692307693yab S0.07692307692307693yc90c S0.07692307692307693>vc3139ya6c0.2yd9719c0.1yb9fc0.1yc29cc0.1yadc0.1ybfcc0.1ybbcc0.1yc09ac0.1ym2981057642b69c0.1vc314:ya8c0.1yc153c0.1yed13aac0.1yc56ec0.1yd27fec0.1yd71efc0.1yd40ffc0.1yacc0.1yc093c0.1ydecdfc0.1vc315<ya2 S0.07692307692307693ya4 S0.07692307692307693ya7 S0.07692307692307693yc322 S0.07692307692307693yc414 S0.07692307692307693yc875 S0.07692307692307693ye9ccda S0.07692307692307693yac S0.07692307692307693yeebcdf S0.07692307692307693yfeacbba S0.07692307692307693yae S0.15384615384615385yab S0.07692307692307693>vc316:ya5c0.1ya9c0.1yc755c0.1yc69fc0.1ybddc0.1yabc0.1yaec0.1yc90ac0.1yc99cc0.1yn3086543790541cc0.1vc317;ya2 S0.07692307692307693ya7 S0.07692307692307693ya9 S0.15384615384615385yc265 S0.07692307692307693yd277f S0.07692307692307693yaf S0.07692307692307693ye2177e S0.07692307692307693yaa S0.15384615384615385yg62680ea S0.07692307692307693ye0158f S0.07692307692307693yab S0.07692307692307693vc3188ya4e0.125ya5e0.125ybeee0.125yf48516ee0.125yf57684ce0.125yaae0.125yace0.125yn22adccac34be92e0.125vc3198ya2e0.125yd5742e0.125ye39905e0.125ye216dbe0.125yg319052be0.125ybfce0.125yg68862cbe0.125yafe0.125vc3204yd9587d0.25yccbfd0.25yaad0.25y X8187985725963b8bfc67004dd0.25vc3216ya0 S0.16666666666666666ya6 S0.16666666666666666yd0dcb S0.16666666666666666yad S0.16666666666666666yaf S0.16666666666666666y X17794bbca56b6cdb9e20b932 S0.16666666666666666vc3228ya6 R0.1111111111111111ya7 R0.1111111111111111ya9 R0.1111111111111111yeffdbd R0.1111111111111111yaa R0.2222222222222222yad R0.1111111111111111yc28c R0.1111111111111111y R63976e9eec38cab0f5 R0.1111111111111111vc3232ybdec0.5y ^734259dfb9addebe2b226d96b4f744c0.5vc324<ya1 S0.06666666666666667ya3 S0.06666666666666667ya4 S0.06666666666666667yc302 S0.06666666666666667yc512 S0.06666666666666667yc900 S0.06666666666666667yc78f S0.06666666666666667yc002 S0.06666666666666667ybcc S0.06666666666666667yad S0.13333333333333333ybea S0.06666666666666667yac S0.06666666666666667ybda S0.06666666666666667yedfeec S0.06666666666666667>vc3253ybc4 R0.3333333333333333yab R0.3333333333333333y ]418764dca70aebfc965899a3fa7e5 R0.3333333333333333vc326<ya0 S0.11764705882352941ya5 S0.17647058823529413ya8 S0.11764705882352941yc95c T0.058823529411764705yaa S0.11764705882352941yab T0.058823529411764705yf66950b T0.058823529411764705yaf T0.058823529411764705yd22dd T0.058823529411764705yc82a T0.058823529411764705ycdfe T0.058823529411764705ybce T0.058823529411764705>vc3278ya1e0.125yc219e0.125ydc92ce0.125yc12ae0.125yd28fae0.125ybade0.125ycaabe0.125yl60865046ff05e0.125vc328<ya0 S0.06666666666666667ya1 S0.06666666666666667ya4 S0.06666666666666667ya8 S0.06666666666666667ya9 S0.06666666666666667yb68 S0.06666666666666667yd7396 S0.06666666666666667yc12d S0.06666666666666667yae S0.06666666666666667ybcf S0.06666666666666667ybdd S0.06666666666666667yc33a S0.06666666666666667yebbbca S0.06666666666666667ybda S0.06666666666666667yccbc S0.06666666666666667>vc329<ya4 S0.07142857142857142ya5 S0.07142857142857142ya6 S0.07142857142857142yb32 S0.07142857142857142yc466 S0.07142857142857142yd5063 S0.07142857142857142yfd77cdb S0.07142857142857142yac S0.07142857142857142yab S0.07142857142857142yc99c S0.07142857142857142ycaea S0.07142857142857142yc58e S0.07142857142857142ybda S0.07142857142857142yad S0.07142857142857142>vc330:ya4c0.1ya7c0.1yb79c0.1yc481c0.1yd904bc0.1yi07170a0cec0.1yabc0.1ye7491ec0.1yefeccec0.1yafc0.1vc3318ya3e0.125ya7e0.125yd1294e0.125ycbede0.125yabe0.125ycfcce0.125yaee0.125y R23639057435ac8756ae0.125vc3322yc56dc0.5y ]5711303378bd333ddb611a53ece94c0.5vc333<ya1 S0.07692307692307693ya2 S0.07692307692307693ya4 S0.07692307692307693ya6 S0.07692307692307693yc913 S0.07692307692307693yfc7937b S0.07692307692307693yab S0.07692307692307693ycbde S0.07692307692307693yaa S0.07692307692307693yg96191dc S0.07692307692307693yd31db S0.07692307692307693yae S0.07692307692307693ybab S0.07692307692307693>vc3341y `06731164684f90f33ce4017eca9d8ec1Qvc3351y `f8327953a0f0b80011b939111807999aQvc3363yb8b R0.3333333333333333yf76101d R0.3333333333333333y X185700a8efed148d8722d926 R0.3333333333333333vc3374ya3d0.25yc16bd0.25yacd0.25y [9445539e9274282a612dea354c2d0.25vc3385yc623c0.2ybeec0.2ycaaac0.2yc99bc0.2y U429863f89da313fffed97c0.2vc339<ya4 S0.06666666666666667ya6 S0.13333333333333333ya9 S0.13333333333333333yc760 S0.06666666666666667yd116c S0.06666666666666667ybbe S0.06666666666666667yad S0.13333333333333333yab S0.06666666666666667ydbefa S0.06666666666666667yd51ce S0.06666666666666667yae S0.06666666666666667yf96604c S0.06666666666666667>vc340<ya0f0.0625ya2f0.0625ya3f0.1875ya6f0.0625ye82391f0.0625yb4df0.0625yacf0.0625yc95bf0.0625yabe0.125ybeaf0.0625ycddbf0.0625ye30fddf0.0625ycedff0.0625>vc341<ya4 S0.08333333333333333ya7 S0.08333333333333333yc232 S0.08333333333333333yc415 S0.08333333333333333yd10eb S0.08333333333333333yaa S0.08333333333333333ybad S0.08333333333333333ybbe S0.08333333333333333yad S0.08333333333333333yc05c S0.08333333333333333yd57eb S0.08333333333333333yg850036c S0.08333333333333333>vc3425ya0c0.2yd627ac0.2yacc0.2yd45ddc0.2y V07150343c81d856855590ec0.2vc343<ya5 S0.06666666666666667ya7 S0.06666666666666667ya8 S0.13333333333333333yc465 S0.06666666666666667ye966fe S0.06666666666666667yad S0.06666666666666667yc32b S0.06666666666666667yf86121f S0.06666666666666667yaa S0.13333333333333333yc21b S0.06666666666666667yc95f S0.06666666666666667yae S0.06666666666666667yac S0.06666666666666667>vc3448ya7e0.125yc199e0.125yc945e0.125yb4ee0.125yabe0.125ydfecae0.125ybbde0.125y P486653fea1d0e39ce0.125vc3458yc386e0.125yc774e0.125ybfae0.125yf16213de0.125yf24273de0.125yade0.125yg22332cde0.125yd01cee0.125vc3468ya0e0.125ya7e0.125yc860e0.125yfa2679ae0.125yade0.125yaae0.125ycbfbe0.125y P2645809ed92ce138e0.125vc3476yc120 S0.16666666666666666yc58e S0.16666666666666666yd83fb S0.16666666666666666yc33c S0.16666666666666666ybdb S0.16666666666666666y Q338132d23b9112805 S0.16666666666666666vc348<ya6 S0.07692307692307693ya8 S0.07692307692307693ya9 S0.07692307692307693yd6567 S0.07692307692307693ybc6 S0.07692307692307693ybdc S0.07692307692307693yae S0.15384615384615385yad S0.07692307692307693yh673436ac S0.07692307692307693ye41ebc S0.07692307692307693yc79a S0.07692307692307693ybec S0.07692307692307693>vc349<ya1 T0.058823529411764705ya2 T0.058823529411764705ya5 S0.11764705882352941ya9 T0.058823529411764705yb15 T0.058823529411764705yc479 T0.058823529411764705yd7198 T0.058823529411764705yae T0.058823529411764705yf10ebcf T0.058823529411764705ybbb T0.058823529411764705yd88dc T0.058823529411764705yab S0.11764705882352941yac S0.11764705882352941yaf T0.058823529411764705>vc3501y `a4462529ab493676987d946019a14945Qvc351<ya0 S0.06666666666666667ya2 S0.06666666666666667ya3 S0.06666666666666667ya7 S0.06666666666666667yc230 S0.06666666666666667yc827 S0.06666666666666667ybf7 S0.06666666666666667ybdf S0.06666666666666667yabc0.2yd85af S0.06666666666666667ye2623d S0.06666666666666667yaa S0.06666666666666667yecbddd S0.06666666666666667>vc3522ybccc0.5y ^573488dec311655890a205aad4fb65c0.5vc3531y `7164823f504286e3a762ee612ff0a988Qvc354;ya2 S0.07692307692307693ya5 S0.07692307692307693ya6 S0.07692307692307693yd7906 S0.07692307692307693yh85653399 S0.07692307692307693ybda S0.07692307692307693yc67e S0.07692307692307693yaf S0.07692307692307693yc049 S0.07692307692307693yab S0.23076923076923078yebabcf S0.07692307692307693vc355<ya1 S0.07142857142857142ya2 S0.07142857142857142ya5 S0.14285714285714285yc145 S0.07142857142857142yc634 S0.07142857142857142yd584b S0.07142857142857142yab S0.07142857142857142yaf S0.07142857142857142yh362098fc S0.07142857142857142ybfc S0.07142857142857142yae S0.07142857142857142yad S0.07142857142857142yd57de S0.07142857142857142>vc3564yc730d0.25yfc6696ad0.25yafd0.25y V7498efb66f5ba3a8b35d08d0.25vc357<ya0 S0.07692307692307693ya3 S0.07692307692307693ya4 S0.07692307692307693ya6 S0.07692307692307693yc400 S0.07692307692307693yd1446 S0.07692307692307693yd16fa S0.07692307692307693yae S0.07692307692307693ydaefe S0.07692307692307693yc18e S0.07692307692307693ybbf S0.07692307692307693yebaefd S0.07692307692307693ybba S0.07692307692307693>vc358<ya1f0.0625ya2f0.0625ya5f0.0625yc565f0.0625yc970f0.0625yb6ef0.0625yadf0.1875yd0818f0.0625yd58fff0.0625yc50cf0.0625ybbff0.0625yc037f0.0625yabf0.0625yaaf0.0625>vc3599ya0 R0.1111111111111111ya8 R0.1111111111111111yc866 R0.1111111111111111yd0ebe R0.1111111111111111yf78077c R0.1111111111111111yab R0.1111111111111111yg48410cf R0.1111111111111111yc52a R0.1111111111111111yfbccdff R0.1111111111111111vc3601y `924727b6f380cf3cdfe5650163e92054Qvc3618yc927e0.125yd9425e0.125yc26de0.125yc48de0.125yc68be0.125yc28fe0.125yfbfebade0.125yg454658fe0.125vc3627ya5 S0.14285714285714285ya9 S0.14285714285714285ycbda S0.14285714285714285yaa S0.14285714285714285ybda S0.14285714285714285yd86ec S0.14285714285714285y T9790262e14f953bbadcb S0.14285714285714285vc363<ya2 S0.07142857142857142ya3 S0.07142857142857142ya5 S0.07142857142857142yc491 S0.07142857142857142yc664 S0.07142857142857142ybcc S0.07142857142857142yb1a S0.07142857142857142yab S0.07142857142857142yaf S0.14285714285714285yh107510ac S0.07142857142857142yae S0.07142857142857142yad S0.07142857142857142yf2412aa S0.07142857142857142>vc364;ya4 S0.08333333333333333ya5 S0.08333333333333333yc242 S0.08333333333333333ybd9 S0.08333333333333333ybc6 S0.08333333333333333ybab S0.08333333333333333yac S0.16666666666666666ye6630a S0.08333333333333333yaa S0.08333333333333333yc84e S0.08333333333333333yj5765103d2d S0.08333333333333333vc365<ya5 S0.07692307692307693ya8 S0.07692307692307693yc563 S0.07692307692307693yc971 S0.07692307692307693yd9609 S0.07692307692307693yb7a S0.07692307692307693yaa S0.15384615384615385yaf S0.07692307692307693yf31685e S0.07692307692307693yd88da S0.07692307692307693yceea S0.07692307692307693ybce S0.07692307692307693>vc366<ya1 S0.07692307692307693ya3 S0.07692307692307693ya6 S0.07692307692307693yc888 S0.07692307692307693yd14cf S0.07692307692307693yae S0.15384615384615385ye75aec S0.07692307692307693ycead S0.07692307692307693ye7101d S0.07692307692307693yad S0.07692307692307693yc94d S0.07692307692307693yc28a S0.07692307692307693>vc3675ya6c0.2yc14ac0.2yadc0.2yg294550cc0.2y T9760aec57ba29682a750c0.2vc368<ya1 S0.07142857142857142ya8 S0.07142857142857142yc827 S0.07142857142857142yc946 S0.07142857142857142yb5d S0.07142857142857142yaa S0.07142857142857142yae S0.07142857142857142ybea S0.07142857142857142ye70edb S0.07142857142857142yc11d S0.07142857142857142yab S0.07142857142857142yc54f S0.07142857142857142yc076 S0.07142857142857142yccae S0.07142857142857142>vc369:ya4c0.1ya7c0.1ya8c0.1ybb9c0.1yadc0.1yafc0.1yd73fac0.1ybcac0.1ybefc0.1y Q66891554b66b2cdedc0.1vc370<ya3f0.0625ya6e0.125ya7e0.125yc583f0.0625yc962f0.0625ybdcf0.0625yaef0.0625yf34780ff0.0625ye0374bf0.0625ybebe0.125yade0.125yaff0.0625>vc3714ya1d0.25ybded0.25ybabd0.25y [82817c0fb24e591b9a89a82f736d0.25vc3721y `09677934e13a5d728f00c6ed7c8870a9Qvc3731y `7052598d2355984237d126afea2f6e88Qvc3741y `927612b57ba01ca878b2d7edce52a563Qvc3751y `97402287d8c6c03f0b63848e17e9d944Qvc376<ya0f0.0625ya3f0.0625ya5f0.0625ya7f0.0625yc121f0.0625yc240f0.0625yc62ff0.0625yf31128af0.0625yc21bf0.0625yaef0.0625ycbdbf0.0625yabe0.125yadf0.0625yacf0.0625yb04f0.0625>vc377<ya1 S0.08333333333333333yb66 S0.08333333333333333yc822 S0.08333333333333333yc916 S0.08333333333333333yd54da S0.08333333333333333yab S0.08333333333333333yaf S0.08333333333333333yd49ef S0.08333333333333333yc40c S0.08333333333333333ycfab S0.08333333333333333yc61d S0.08333333333333333yd37cf S0.08333333333333333>vc3788yd1934e0.125yd9425e0.125yh89118022e0.125yc41be0.125yg811063be0.125ybdee0.125yaee0.125yc77de0.125vc379;ya1 S0.09090909090909091yc622 S0.09090909090909091yc722 S0.09090909090909091yc759 S0.09090909090909091yc37b S0.09090909090909091ydeaad S0.09090909090909091yaf S0.09090909090909091yc79e S0.09090909090909091yaa S0.09090909090909091yfaacebf S0.09090909090909091yd48ec S0.09090909090909091vc3801y `73262345214f9b7794f2cc4a612b15e8Qvc3812yg9baedcdc0.5y Y033169611a42c3cfd58b3ae03c0.5vc382<ya0 S0.05263157894736842ya1 S0.10526315789473684ya2 S0.10526315789473684ya4 S0.10526315789473684yc865 S0.05263157894736842yef23ca S0.05263157894736842ybaa S0.05263157894736842yc066 S0.05263157894736842yab S0.05263157894736842ybee S0.05263157894736842ybfa S0.05263157894736842ybdf S0.05263157894736842yaf S0.10526315789473684ybbe S0.05263157894736842yac S0.05263157894736842>vc3837yc953 S0.14285714285714285yd2523 S0.14285714285714285yb3c S0.14285714285714285yae S0.14285714285714285yd65ff S0.14285714285714285ybfd S0.14285714285714285y P73579aaaf5d7ce36 S0.14285714285714285vc384<ya1 T0.058823529411764705ya5 T0.058823529411764705ya7 T0.058823529411764705ya8 S0.11764705882352941ya9 S0.11764705882352941yc939 T0.058823529411764705yc88a T0.058823529411764705yae T0.058823529411764705yh608108be T0.058823529411764705ybda T0.058823529411764705ycaab T0.058823529411764705yaa S0.11764705882352941ybaf T0.058823529411764705yad T0.058823529411764705>vc3853yc2f1 R0.3333333333333333ybec R0.3333333333333333y [795216d5bafa33a810af3421942 R0.3333333333333333vc386;ya4 S0.08333333333333333yb62 S0.08333333333333333yc373 S0.08333333333333333ybce S0.08333333333333333yd0aea S0.08333333333333333yc06d S0.08333333333333333yf44878b S0.08333333333333333yaa S0.16666666666666666ycefe S0.08333333333333333yc090 S0.08333333333333333yc66a S0.08333333333333333vc387<ya3 S0.11764705882352941ya5 T0.058823529411764705ya9 T0.058823529411764705yc265 T0.058823529411764705yc423 T0.058823529411764705ybc0 T0.058823529411764705yae S0.11764705882352941yaf T0.058823529411764705ybac T0.058823529411764705yd41cc T0.058823529411764705yab T0.058823529411764705yac T0.058823529411764705yc95a T0.058823529411764705yc97e T0.058823529411764705ycfcb T0.058823529411764705>vc388<ya0c0.1ya1d0.05ya2d0.05ya3d0.15ya4d0.05ya6d0.05yc7edd0.05yadc0.1ycefad0.05yaed0.05yafd0.05ybedd0.05yabd0.05yd77ebd0.05yceffd0.05yc86bd0.05>vc3894yd3811d0.25yabd0.25yi40721f7cad0.25y R651887aac4eb17f9f0d0.25vc3904yc765d0.25yb5ad0.25yafd0.25y Z9668608a39333fa90cf462657ed0.25vc3917ya0 S0.14285714285714285ya5 S0.14285714285714285ydc70b S0.14285714285714285yd78fd S0.14285714285714285yab S0.14285714285714285yedffcd S0.14285714285714285y P38322355e9c2471e S0.14285714285714285vc3921y `229975f1e84b5088e819cd5f2dc43080Qvc393;ya1 S0.09090909090909091ya3 S0.09090909090909091ya7 S0.09090909090909091ya8 S0.09090909090909091yd10eb S0.09090909090909091yae S0.09090909090909091ybdc S0.09090909090909091yc64d S0.09090909090909091ybca S0.09090909090909091ycdad S0.09090909090909091ym92641dadb5de7 S0.09090909090909091vc3949ya0 R0.1111111111111111ya9 R0.1111111111111111yd3979 R0.1111111111111111yd49ba R0.1111111111111111yg23148db R0.1111111111111111yeeffdc R0.1111111111111111ybaa R0.1111111111111111ybfe R0.1111111111111111yf5876ea R0.1111111111111111vc3952yef6dffc0.5y [70097776e24c2a7c9c0f2514f79c0.5vc396<ya2 S0.07692307692307693ya4 S0.07692307692307693ya7 S0.07692307692307693yb61 S0.07692307692307693yc835 S0.07692307692307693yd3967 S0.07692307692307693yg991285e S0.07692307692307693yac S0.15384615384615385ye3295b S0.07692307692307693ybff S0.07692307692307693ycdcd S0.07692307692307693yaf S0.07692307692307693>vc3976yd1726 S0.16666666666666666yc50f S0.16666666666666666yc43b S0.16666666666666666ybcf S0.16666666666666666yg61066ef S0.16666666666666666ym8656477b226be S0.16666666666666666vc3983ydeeef R0.3333333333333333ye60efe R0.3333333333333333y W889349870426d10edc694be R0.3333333333333333vc399;ya6 S0.09090909090909091yd1338 S0.09090909090909091yd4796 S0.09090909090909091yb4b S0.09090909090909091yc046 S0.09090909090909091ybac S0.09090909090909091yaa S0.09090909090909091ybfb S0.09090909090909091yaf S0.09090909090909091yg0481dbd S0.09090909090909091ye4003d S0.09090909090909091vc4001y `b2621497b3313c97855ed951f0d9b291Qvc401<ya3 S0.06666666666666667ya5 S0.06666666666666667ya7 S0.06666666666666667ya9c0.2yd1441 S0.06666666666666667ybff S0.06666666666666667yaa S0.13333333333333333yi42144a7de S0.06666666666666667yceaf S0.06666666666666667yaf S0.06666666666666667yae S0.06666666666666667ydcfea S0.06666666666666667>vc402<ya0 S0.07142857142857142ya8 S0.07142857142857142yb55 S0.07142857142857142yc303 S0.07142857142857142yd5988 S0.07142857142857142yab S0.21428571428571427yc62a S0.07142857142857142yac S0.07142857142857142yd0785 S0.07142857142857142yaa S0.07142857142857142yc77c S0.07142857142857142yf74608e S0.07142857142857142>vc403;ya7 S0.09090909090909091yc230 S0.09090909090909091yc716 S0.09090909090909091yd8208 S0.09090909090909091yc94b S0.09090909090909091yd85ba S0.09090909090909091ycdbb S0.09090909090909091yac S0.09090909090909091yc20b S0.09090909090909091yae S0.09090909090909091yf69248b S0.09090909090909091>vetitle<va15yfkagomec0.2ya-c0.2ycbotc0.2yaのc0.2yiユーザーサービス化c0.2va2:yd2023 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091va3;yeOrama S0.08333333333333333ycという S0.08333333333333333yb検索 S0.16666666666666666ydエンジン S0.08333333333333333yaで S0.08333333333333333ycブログ S0.08333333333333333yaを S0.08333333333333333yb作っ S0.08333333333333333yaて S0.08333333333333333yaみ S0.08333333333333333yaた S0.08333333333333333va49ybGo R0.1111111111111111yaで R0.1111111111111111yeSlack R0.1111111111111111yaの R0.1111111111111111ycボット R0.1111111111111111yaを R0.1111111111111111yb作っ R0.1111111111111111yaた R0.1111111111111111ya話 R0.1111111111111111va59yd機械学習 R0.1111111111111111ycによる R0.1111111111111111yb検索 R0.1111111111111111yeランキング R0.1111111111111111yb改善 R0.1111111111111111ycガイド R0.1111111111111111yaを R0.1111111111111111yd読みまし R0.1111111111111111yaた R0.1111111111111111va66yfsearch S0.14285714285714285ya- S0.14285714285714285ybUI S0.14285714285714285yaと R0.2857142857142857yiSearchkit S0.14285714285714285yd検索画面 S0.14285714285714285va7<ybVS S0.07692307692307693ya  S0.15384615384615385ydCode S0.07692307692307693yaと S0.07692307692307693ycDev S0.07692307692307693yiContainer S0.07692307692307693ya( S0.07692307692307693ydコンテナ S0.07692307692307693ya名 S0.07692307692307693yaの S0.07692307692307693yb指定 S0.07692307692307693ya) S0.07692307692307693>va86ygブログ記述環境 S0.16666666666666666ycとして S0.16666666666666666yaの S0.16666666666666666ycDev S0.16666666666666666ya  S0.16666666666666666yiContainer S0.16666666666666666va95ya2 S0.16666666666666666ycWSL S0.16666666666666666yaの R0.3333333333333333ykディストリビューション S0.16666666666666666yd環境移行 S0.16666666666666666vb10<ybVS S0.06666666666666667ya  S0.13333333333333333ydCode S0.06666666666666667yaと S0.06666666666666667ycDev S0.06666666666666667yiContainer S0.06666666666666667ya（ S0.06666666666666667yfdocker S0.06666666666666667ya- S0.06666666666666667ygcompose S0.06666666666666667ya. S0.06666666666666667ycyml S0.06666666666666667yb対応 S0.06666666666666667ya） S0.06666666666666667>vb11<ybVS S0.07692307692307693ya  S0.15384615384615385ydCode S0.07692307692307693yaと S0.07692307692307693ycDev S0.07692307692307693yiContainer S0.07692307692307693yaの S0.07692307692307693yb導入 S0.07692307692307693ya（ S0.07692307692307693ybまだ S0.07692307692307693yb途中 S0.07692307692307693ya） S0.07692307692307693>vb12<ycpre S0.07692307692307693ya- S0.07692307692307693yfcommit S0.07692307692307693yaと S0.15384615384615385ydvenv S0.07692307692307693ygPyCharm S0.07692307692307693ya（ S0.07692307692307693yb困っ S0.07692307692307693yaた S0.07692307692307693yaな S0.07692307692307693ya？ S0.07692307692307693ya） S0.07692307692307693>vb13;yb今年 S0.09090909090909091yaも S0.09090909090909091yeオンライン S0.09090909090909091yaで S0.09090909090909091yfBerlin S0.09090909090909091ya  S0.09090909090909091yiBuzzwords S0.09090909090909091yaに S0.09090909090909091yb参加 S0.09090909090909091yaし S0.09090909090909091yaた S0.09090909090909091vb14:yd2022 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091vb154yc仕事中d0.25yaのd0.25ycBGMd0.25yb環境d0.25vb168ymElasticsearch R0.1111111111111111yaの R0.1111111111111111ygアーキテクチャ R0.1111111111111111yaと R0.1111111111111111yiStateless R0.1111111111111111ya  R0.2222222222222222ya/ R0.1111111111111111yjServerless R0.1111111111111111vb17:ya2c0.1ycローマc0.1yc字入力c0.1yaのc0.1ybゆれc0.1yaとc0.1yb読みc0.1ya（c0.1y \JapaneseCompletionAnalyzerそのc0.1ya）c0.1vb185yd日本語用 S0.16666666666666666yiオートコンプリート S0.16666666666666666yaの R0.3333333333333333ybため S0.16666666666666666yhAnalyzer S0.16666666666666666vb195ydHugoc0.2yaをc0.2yfアップデートc0.2yaしc0.2yaたc0.2vb209ya2 R0.1111111111111111yfQuerqy R0.1111111111111111yaの R0.1111111111111111yb調査 R0.1111111111111111ya（ R0.1111111111111111ybその R0.1111111111111111ya： R0.1111111111111111ygアーキテクチャ R0.1111111111111111ya） R0.1111111111111111vb217yfQuerqy S0.14285714285714285yaの S0.14285714285714285yb調査 S0.14285714285714285ya（ S0.14285714285714285ybその S0.14285714285714285ya１ S0.14285714285714285ya） S0.14285714285714285vb22;yb今年 S0.09090909090909091yaも S0.09090909090909091yeオンライン S0.09090909090909091yaで S0.09090909090909091yfBerlin S0.09090909090909091ya  S0.09090909090909091yiBuzzwords S0.09090909090909091yaに S0.09090909090909091yb参加 S0.09090909090909091yaし S0.09090909090909091yaた S0.09090909090909091vb235ymElasticsearchc0.2yaのc0.2yc新しいc0.2ydJavac0.2yfクライアントc0.2vb248ykインデックスエイリアス S0.09090909090909091ya  S0.36363636363636365ya- S0.09090909090909091yeAzure S0.09090909090909091yiCognitive S0.09090909090909091yfSearch S0.09090909090909091yaの S0.09090909090909091yc新機能 S0.09090909090909091vb25<ygExtreme T0.041666666666666664ya  R0.3333333333333333yeMulti T0.041666666666666664ya- T0.041666666666666664yelabel T0.041666666666666664yhLearning T0.041666666666666664ycfor T0.041666666666666664yhSemantic T0.041666666666666664yhMatching T0.041666666666666664ybin T0.041666666666666664ygProduct T0.041666666666666664yfSearch T0.041666666666666664ycという T0.041666666666666664yb論文 T0.041666666666666664yaを T0.041666666666666664yb読ん T0.041666666666666664yaだ T0.041666666666666664>vb26:yd2021 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091vb276ye2021年 S0.16666666666666666ybかっ S0.16666666666666666yaて S0.16666666666666666yc良かっ S0.16666666666666666yaた S0.16666666666666666ybもの S0.16666666666666666vb28<yeAzure T0.058823529411764705ya  S0.23529411764705882yiCognitive T0.058823529411764705yfSearch T0.058823529411764705yaの T0.058823529411764705yeIndex T0.058823529411764705yfSchema T0.058823529411764705ydJSON T0.058823529411764705yaを T0.058823529411764705ycCSV T0.058823529411764705yaで T0.058823529411764705ya見 T0.058823529411764705ybたく T0.058823529411764705ybなる T0.058823529411764705>vb296yb今年 S0.16666666666666666yaの S0.16666666666666666ycDIY S0.16666666666666666yeキーボード S0.16666666666666666yaと S0.16666666666666666yjコントローラーラック S0.16666666666666666vb30<yfDomain T0.037037037037037035ya- T0.037037037037037035yhSpecific T0.037037037037037035ya  R0.3333333333333333ykPretraining T0.037037037037037035ycfor T0.037037037037037035yhVertical T0.037037037037037035yfSearch T0.037037037037037035ya: T0.037037037037037035ydCase T0.037037037037037035yeStudy T0.037037037037037035ybon T0.037037037037037035yjBiomedical T0.037037037037037035yjLiterature T0.037037037037037035ycという T0.037037037037037035yb論文 T0.037037037037037035yaを T0.037037037037037035yb読ん T0.037037037037037035yaだ T0.037037037037037035>vb319yb今年 R0.1111111111111111yaも R0.1111111111111111yeMICES R0.1111111111111111yaに R0.1111111111111111yeオンライン R0.1111111111111111yb出張 R0.1111111111111111yaし R0.1111111111111111yaて R0.1111111111111111yaた R0.1111111111111111vb32;yb今年 S0.09090909090909091yaも S0.09090909090909091yfBerlin S0.09090909090909091ya  S0.09090909090909091yiBuzzwords S0.09090909090909091yaに S0.09090909090909091yeオンライン S0.09090909090909091yb出張 S0.09090909090909091yaし S0.09090909090909091yaて S0.09090909090909091yaた S0.09090909090909091vb33<yeAzuref0.0625ya f0.1875yiCognitivef0.0625yfSearche0.125yaのf0.0625yc新機能f0.0625ya、f0.0625yhSemanticf0.0625yaをf0.0625yb試しf0.0625yaてf0.0625yaみf0.0625yaたf0.0625>vb34<ygLunakeyd0.05ya c0.1ydMinid0.05yaをd0.05yb組みd0.05yb立てd0.05yaてc0.1ya、d0.05ycBLEd0.05ya+d0.05ydLPMEd0.05ya-d0.05ydIO化しd0.05yaみd0.05yaたd0.05ya#d0.05ycDIYd0.05yeキーボードd0.05>vb35:ydスライドc0.1yb作成c0.1yaのc0.1yb環境c0.1yaをc0.1ydMarpc0.1yaにc0.1ybしてc0.1yaみc0.1yaたc0.1vb36<yd検索技術 S0.06666666666666667yaに S0.06666666666666667yc関する S0.06666666666666667yb情報 S0.06666666666666667yb交換 S0.06666666666666667yaを S0.06666666666666667yb目的 S0.06666666666666667yaと S0.06666666666666667yaし S0.06666666666666667yaた S0.13333333333333333yeSlack S0.06666666666666667yaが S0.06666666666666667ydできまし S0.06666666666666667ya！ S0.06666666666666667>vb379yfOData式 S0.09090909090909091yaと S0.18181818181818182yc日本語 S0.09090909090909091yaの S0.09090909090909091yb検索 S0.18181818181818182ya( S0.09090909090909091yeNGram S0.09090909090909091ya) S0.09090909090909091ydフレーズ S0.09090909090909091vb389yd2021 R0.1111111111111111yb自宅 R0.1111111111111111yaの R0.1111111111111111yb作業 R0.1111111111111111yb環境 R0.1111111111111111ya( R0.1111111111111111ya/ R0.1111111111111111yb02 R0.1111111111111111ya) R0.1111111111111111vb39;yeAzure S0.08333333333333333ya  S0.16666666666666666yiCognitive S0.08333333333333333yfSearch S0.08333333333333333yaで S0.08333333333333333yiオートコンプリート S0.08333333333333333yaや S0.08333333333333333yeサジェスト S0.08333333333333333yaを S0.08333333333333333ybして S0.08333333333333333ybみる S0.08333333333333333vb40<ya2f0.0625ya「f0.0625yjコンピュータシステムf0.0625yaのf0.0625yb理論f0.0625yaとf0.0625yb実装f0.0625ya」f0.0625yaをf0.0625yb読みf0.0625yb始めf0.0625yaたf0.0625ya f0.0625ya#f0.0625ydNandf0.0625yfTetrisf0.0625>vb41<yeSofled0.05ya c0.1ybv2d0.05yaをd0.05yb組みd0.05yb立てd0.05yaてc0.1ya、d0.05ycBLEd0.05ya+d0.05ydLPMEd0.05ya-d0.05ydIO化しd0.05yaみd0.05yaたd0.05ya#d0.05ycDIYd0.05yeキーボードd0.05>vb42<yeCornef0.0625ya f0.1875yeLightf0.0625ybv2f0.0625yaのf0.0625ycBLEf0.0625ya+f0.0625ydLPMEf0.0625ya-f0.0625ybIOf0.0625yb対応f0.0625ya#f0.0625ycDIYf0.0625yeキーボードf0.0625>vb435ybPCc0.2yaもc0.2ycDIYc0.2ycしましc0.2yaたc0.2vb44:yd2020 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091vb454yeIndexc0.2ya c0.4yhTemplatec0.2ybV2c0.2vb46:yeCorne S0.09090909090909091ya  S0.18181818181818182yiChocolate S0.09090909090909091yaを S0.09090909090909091yb組み S0.09090909090909091yb立て S0.09090909090909091yaた S0.09090909090909091ya# S0.09090909090909091ycDIY S0.09090909090909091yeキーボード S0.09090909090909091vb47;yeCorne S0.07692307692307693ya  S0.23076923076923078yeLight S0.07692307692307693ybv2 S0.07692307692307693yaを S0.07692307692307693yb作成 S0.07692307692307693yaし S0.07692307692307693yaた S0.07692307692307693ya# S0.07692307692307693ycDIY S0.07692307692307693yeキーボード S0.07692307692307693vb488ygWindowse0.125yaへe0.125yaのe0.125yb移行e0.125ya（e0.125ybそのe0.125ya１e0.125ya）e0.125vb494ygWindowsd0.25yaをd0.25ycお試しd0.25ya中d0.25vb50:ya0c0.1yeDozenc0.1yaをc0.1yb作成c0.1yaしc0.1yaたc0.1ya c0.1ya#c0.1ycDIYc0.1yeキーボードc0.1vb51:ygLinderac0.1yaのc0.1ycFSTc0.1yaをc0.1yoDoubleArrayTriec0.1yaにc0.1yb変更c0.1yaしc0.1yaたc0.1ya話c0.1vb52<ya3 S0.07142857142857142yd検索対象 S0.07142857142857142yaの S0.07142857142857142ycデータ S0.07142857142857142yaと S0.07142857142857142yfデータソース S0.07142857142857142ya( S0.07142857142857142yb検索 S0.07142857142857142ydシステム S0.07142857142857142yaに S0.07142857142857142yc関する S0.07142857142857142yb妄想 S0.07142857142857142ybその S0.07142857142857142ya) S0.07142857142857142>vb539yd2020 R0.1111111111111111yb自宅 R0.1111111111111111yaの R0.1111111111111111yb作業 R0.1111111111111111yb環境 R0.1111111111111111ya( R0.1111111111111111ya/ R0.1111111111111111yb09 R0.1111111111111111ya) R0.1111111111111111vb544ygmeteredd0.25ydクレートd0.25yaのd0.25yb紹介d0.25vb557yd2020 S0.14285714285714285ye第4章終了 S0.14285714285714285ya( S0.14285714285714285yd言語処理 S0.14285714285714285yd100本 S0.14285714285714285ycノック S0.14285714285714285ya) S0.14285714285714285vb567yd2020 S0.14285714285714285ye第3章終了 S0.14285714285714285ya( S0.14285714285714285yd言語処理 S0.14285714285714285yd100本 S0.14285714285714285ycノック S0.14285714285714285ya) S0.14285714285714285vb57:yiTerraform S0.09090909090909091yaで S0.09090909090909091yeAzure S0.09090909090909091ya  S0.18181818181818182yiCognitive S0.09090909090909091yfSearch S0.09090909090909091yaの S0.09090909090909091yeクラスター S0.09090909090909091yaを S0.09090909090909091yb起動 S0.09090909090909091vb58<ya2 S0.06666666666666667yb検索 S0.13333333333333333ydシステム S0.13333333333333333yaを S0.06666666666666667yb構成 S0.06666666666666667ybする S0.06666666666666667ycパーツ S0.06666666666666667ya( S0.06666666666666667yaに S0.06666666666666667yc関する S0.06666666666666667yb妄想 S0.06666666666666667ybその S0.06666666666666667ya) S0.06666666666666667>vb59<ya1f0.0625ydシステムe0.125yaのf0.0625yb特徴f0.0625yaとf0.0625yb検索e0.125yb機能f0.0625ydについてf0.0625ya(f0.0625yaにf0.0625yc関するf0.0625yb妄想f0.0625ybそのf0.0625ya)f0.0625>vb607ydRustc0.1ya c0.4ycthec0.1ydbookc0.1ya-c0.1ya第c0.1yc15章c0.1vb619yfBerlin R0.1111111111111111ya  R0.1111111111111111yiBuzzwords R0.1111111111111111yaに R0.1111111111111111yeオンライン R0.1111111111111111yb出張 R0.1111111111111111yaし R0.1111111111111111yaて R0.1111111111111111yaた R0.1111111111111111vb62:yjluceneutil S0.08333333333333333ya  S0.16666666666666666ya- S0.08333333333333333yhAnalyzer S0.08333333333333333yb性能 S0.08333333333333333ycテスト S0.08333333333333333yaへ S0.08333333333333333yaの S0.16666666666666666yhkuromoji S0.08333333333333333yb追加 S0.08333333333333333vb638yjluceneutil R0.1111111111111111ya  R0.2222222222222222ya- R0.1111111111111111yeマニアック R0.1111111111111111yaな R0.1111111111111111ycツール R0.1111111111111111yaの R0.1111111111111111yfセットアップ R0.1111111111111111vb649yeAzure S0.09090909090909091ya  S0.18181818181818182yiCognitive S0.09090909090909091yfSearch S0.09090909090909091yaで S0.09090909090909091yaの S0.18181818181818182ye日本語向け S0.09090909090909091yhAnalyzer S0.09090909090909091yb違い S0.09090909090909091vb657ydRustc0.1ya c0.4ycthec0.1ydbookc0.1ya-c0.1ya第c0.1yc13章c0.1vb667ydRustc0.1ya c0.4ycthec0.1ydbookc0.1ya-c0.1ya第c0.1yc10章c0.1vb677yeAzure R0.1111111111111111ya  R0.2222222222222222yiCognitive R0.1111111111111111yfSearch R0.1111111111111111yaの R0.2222222222222222yeリクエスト R0.1111111111111111ydロギング R0.1111111111111111vb68<yd2020 S0.05263157894736842yiMicrosoft S0.05263157894736842ya  S0.15789473684210525yeBuild S0.05263157894736842ya( S0.05263157894736842ya) S0.05263157894736842yaの S0.15789473684210525yeAzure S0.05263157894736842yiCognirive S0.05263157894736842yfSearch S0.05263157894736842yeセッション S0.05263157894736842yaを S0.05263157894736842yb見た S0.05263157894736842yaで S0.05263157894736842ybメモ S0.05263157894736842>vb69:ya7 S0.16666666666666666ygElastic S0.08333333333333333ya  S0.16666666666666666yeStack S0.08333333333333333ya. S0.08333333333333333yaが S0.08333333333333333ydリリース S0.08333333333333333yaさ S0.08333333333333333yaれ S0.08333333333333333yaた S0.08333333333333333vb707ydRustc0.1ya c0.4ycthec0.1ydbookc0.1ya-c0.1ya第c0.1yb9章c0.1vb71<yb12 S0.08333333333333333yb19 S0.08333333333333333yd2020 S0.08333333333333333yc第2章 S0.08333333333333333yaの S0.08333333333333333ybから S0.08333333333333333ybまで S0.08333333333333333ya( S0.08333333333333333yd言語処理 S0.08333333333333333yd100本 S0.08333333333333333ycノック S0.08333333333333333ya) S0.08333333333333333>vb72<yb10 S0.08333333333333333yb11 S0.08333333333333333yd2020 S0.08333333333333333yc第2章 S0.08333333333333333yaの S0.08333333333333333ybから S0.08333333333333333ybまで S0.08333333333333333ya( S0.08333333333333333yd言語処理 S0.08333333333333333yd100本 S0.08333333333333333ycノック S0.08333333333333333ya) S0.08333333333333333>vb73<yd2020 S0.08333333333333333yc第1章 S0.08333333333333333yaの S0.08333333333333333yb08 S0.08333333333333333ybから S0.08333333333333333yb09 S0.08333333333333333ybまで S0.08333333333333333ya( S0.08333333333333333yd言語処理 S0.08333333333333333yd100本 S0.08333333333333333ycノック S0.08333333333333333ya) S0.08333333333333333>vb74<ya2d0.05ygElasticd0.05yaのd0.05yiWorkplaced0.05ya d0.25yfSearchd0.05yaをd0.05yb触っd0.05yaてd0.05ybみるd0.05ya-c0.1ybそのd0.05yfインストールd0.05yaとd0.05yb起動d0.05>vb75<ya1 S0.07142857142857142ygElastic S0.07142857142857142yaの S0.07142857142857142yiWorkplace S0.07142857142857142ya  S0.21428571428571427yfSearch S0.07142857142857142yaを S0.07142857142857142yb触っ S0.07142857142857142yaて S0.07142857142857142ybみる S0.07142857142857142ya- S0.07142857142857142ybその S0.07142857142857142>vb765yb辞書 S0.16666666666666666yaの R0.3333333333333333yb更新 S0.16666666666666666ydについて S0.16666666666666666yc注意点 S0.16666666666666666vb779yhKuromojic0.1yaのc0.2ydカスタムc0.1yb辞書c0.1yaをc0.1yfインデックスc0.1yb設定c0.1yaでc0.1yb指定c0.1vb787ydRustc0.1ya c0.4ycthec0.1ydbookc0.1ya-c0.1ya第c0.1yb8章c0.1vb79<yd2020 S0.08333333333333333yc第1章 S0.08333333333333333yaの S0.08333333333333333yb03 S0.08333333333333333ybから S0.08333333333333333yb06 S0.08333333333333333ybまで S0.08333333333333333ya( S0.08333333333333333yd言語処理 S0.08333333333333333yd100本 S0.08333333333333333ycノック S0.08333333333333333ya) S0.08333333333333333>vb805yd言語処理c0.2yd100本c0.2ycノックc0.2ya、c0.2yb再びc0.2vb817ydRustc0.1ya c0.4ycthec0.1ydbookc0.1ya-c0.1ya第c0.1yb6章c0.1vb82;yhKuromoji S0.08333333333333333yaの S0.08333333333333333ycCLI S0.08333333333333333ydコマンド S0.08333333333333333yaに S0.08333333333333333ydJSON S0.08333333333333333yb出力 S0.16666666666666666yaと S0.08333333333333333ydラティス S0.08333333333333333yaを S0.08333333333333333yb追加 S0.08333333333333333vb837ydRustc0.1ya c0.4ycthec0.1ydbookc0.1ya-c0.1ya第c0.1yb5章c0.1vb847yd2020 S0.14285714285714285yb自宅 S0.14285714285714285yaの S0.14285714285714285yb作業 S0.14285714285714285yb環境 S0.14285714285714285ya( S0.14285714285714285ya) S0.14285714285714285vb857ydRustc0.1ya c0.4ycthec0.1ydbookc0.1ya-c0.1ya第c0.1yb4章c0.1vb869ymElasticsearch S0.07692307692307693yaの S0.23076923076923078ygAnalyze S0.07692307692307693ya  S0.23076923076923078ycAPI S0.07692307692307693yfVisual S0.07692307692307693yfStudio S0.07692307692307693ydCode S0.07692307692307693ykクライアントプラグイン S0.07692307692307693vb878ydRust R0.1111111111111111ya  R0.2222222222222222ycthe R0.1111111111111111ydBook R0.1111111111111111yaを R0.1111111111111111yb読み R0.1111111111111111yb始め R0.1111111111111111yaた R0.1111111111111111vb88<yfVisual T0.047619047619047616ya  S0.23809523809523808yfStudio T0.047619047619047616ydCode T0.047619047619047616yaの T0.047619047619047616yeプラグイン T0.047619047619047616yaを T0.047619047619047616yb作っ T0.047619047619047616yaて T0.047619047619047616yaみ T0.047619047619047616yaた T0.047619047619047616ya( T0.047619047619047616yeAzure T0.047619047619047616yfSearch T0.047619047619047616ygAnalyze T0.047619047619047616yfClient T0.047619047619047616ya) T0.047619047619047616>vb899yb実践 R0.1111111111111111ydRust R0.1111111111111111yb入門 R0.1111111111111111yaの R0.1111111111111111yb3章 R0.1111111111111111yaを R0.1111111111111111yb読み R0.1111111111111111yc終わっ R0.1111111111111111yaた R0.1111111111111111vb907yhKuromojie0.125yaのe0.125ycCLIe0.125ydコマンドe0.125yaとd0.25ygpicoclie0.125ygGraalVMe0.125vb919yb実践 R0.1111111111111111ydRust R0.1111111111111111yb入門 R0.1111111111111111yaの R0.1111111111111111yb3章 R0.1111111111111111yaを R0.1111111111111111yb読ん R0.1111111111111111ybでる R0.1111111111111111ycところ R0.1111111111111111vb927ye2019年 S0.14285714285714285yaに S0.14285714285714285yb買っ S0.14285714285714285yaて S0.14285714285714285ycよかっ S0.14285714285714285yaた S0.14285714285714285ybもの S0.14285714285714285vb93<ya5 S0.07692307692307693ygブログ移行日記 S0.07692307692307693ya( S0.07692307692307693ybその S0.07692307692307693ya) S0.07692307692307693ya  S0.15384615384615385ya- S0.07692307692307693yeJugem S0.07692307692307693yaの S0.07692307692307693ycブログ S0.07692307692307693yaを S0.07692307692307693yb移行 S0.07692307692307693>vb94:yeAzure S0.09090909090909091ya  S0.18181818181818182yiCognitive S0.09090909090909091yfSearch S0.09090909090909091yaで S0.09090909090909091yfインデックス S0.09090909090909091yaを S0.09090909090909091yb作っ S0.09090909090909091yaて S0.09090909090909091yb検索 S0.09090909090909091vb95<ya「 S0.08333333333333333yb検索 S0.08333333333333333ydシステム S0.08333333333333333yb探訪 S0.08333333333333333ya」 S0.08333333333333333yaし S0.08333333333333333ybたい S0.08333333333333333yaな S0.08333333333333333ya= S0.08333333333333333ya> S0.08333333333333333ydやりまし S0.08333333333333333yaた S0.08333333333333333>vb962yfボードゲームc0.5yb紹介c0.5vb976yb実践 S0.16666666666666666ydRust S0.16666666666666666yb入門 S0.16666666666666666yaは S0.16666666666666666ydじめまし S0.16666666666666666yaた S0.16666666666666666vb987yfフリーランス S0.14285714285714285yaは S0.14285714285714285ydじめまし S0.14285714285714285yaた S0.14285714285714285ya( S0.14285714285714285ya仮 S0.14285714285714285ya) S0.14285714285714285vb99;ya4 S0.07142857142857142ygブログ移行日記 S0.07142857142857142ya( S0.14285714285714285ybその S0.07142857142857142ya) S0.14285714285714285ya  S0.14285714285714285ya- S0.07142857142857142yd検索機能 S0.07142857142857142ygAlgolia S0.07142857142857142yaの S0.07142857142857142yb導入 S0.07142857142857142vc100<ya3d0.05ygブログ移行日記d0.05ya(c0.1ybそのd0.05ya)c0.1ya c0.1ya-d0.05ydHugod0.05yaのd0.05yb設定d0.05yaとd0.05yc微調整d0.05ycテーマd0.05yaにd0.05yb合わd0.05yaせd0.05yaたd0.05>vc101;ya2 S0.08333333333333333ygブログ移行日記 S0.08333333333333333ya( S0.08333333333333333ybその S0.08333333333333333ya) S0.08333333333333333ya  S0.16666666666666666ya- S0.08333333333333333yhMarkdown S0.08333333333333333ydファイル S0.08333333333333333yaの S0.08333333333333333yb変換 S0.08333333333333333vc102:ya1 S0.09090909090909091ygブログ移行日記 S0.09090909090909091ya( S0.09090909090909091ybその S0.09090909090909091ya) S0.09090909090909091ya  S0.18181818181818182ya- S0.09090909090909091ydHugo S0.09090909090909091yaと S0.09090909090909091ycテーマ S0.09090909090909091vc1039yiOctopress R0.1111111111111111ybから R0.1111111111111111ydHugo R0.1111111111111111yaへ R0.1111111111111111yc移行中 R0.1111111111111111ya( R0.1111111111111111ybまだ R0.1111111111111111yb途中 R0.1111111111111111ya) R0.1111111111111111vc104:yd2019 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091vc1057yemacOSe0.125yb標準e0.125yaのd0.25yeターミナルe0.125yiウィンドウグループe0.125yaがe0.125yb便利e0.125vc1062yihomeshickc0.5yb導入c0.5vc1074yczshd0.25yaへd0.25yaのd0.25yb移行d0.25vc1086yiOctopress S0.16666666666666666yb環境 S0.16666666666666666yaの S0.16666666666666666yfDocker S0.16666666666666666ydイメージ S0.16666666666666666ya化 S0.16666666666666666vc1092yb退職c0.5ycしますc0.5vc110:yfApache S0.09090909090909091ya  S0.09090909090909091yfLucene S0.09090909090909091yaの S0.18181818181818182yhKuromoji S0.09090909090909091yfUniDic S0.09090909090909091ycビルド S0.09090909090909091yb対応 S0.09090909090909091ycパッチ S0.09090909090909091ydについて S0.09090909090909091vc1116ye2019年 S0.14285714285714285yaの S0.14285714285714285ygElastic R0.2857142857142857ya  S0.14285714285714285yeStack S0.14285714285714285yaと S0.14285714285714285vc112<ya1 S0.06666666666666667ygBonfire S0.06666666666666667ya  S0.26666666666666666ydData S0.06666666666666667ya& S0.06666666666666667ygScience S0.06666666666666667ya# S0.06666666666666667yaに S0.06666666666666667yb参加 S0.06666666666666667yaし S0.06666666666666667ybまし S0.06666666666666667yaた S0.06666666666666667>vc1138ya2c0.1ymElasticsearchc0.1ya c0.3ydNEXTc0.1ydSTEPc0.1yaをc0.1yd頂きましc0.1yaたc0.1vc1148yc勉強会 R0.1111111111111111yaの R0.1111111111111111yb受付 R0.1111111111111111yb自作 R0.1111111111111111ya？ R0.2222222222222222ycアプリ R0.1111111111111111ydHTML R0.1111111111111111ydについて R0.1111111111111111vc1157yi勉強会運営座談会っe0.125yaてd0.25yaのe0.125yaをe0.125ybやっe0.125yaみe0.125yaたe0.125vc116<yfSearch T0.047619047619047616ya  S0.14285714285714285ykEngineering T0.047619047619047616ydTech T0.047619047619047616ydTalk T0.047619047619047616ya( T0.047619047619047616yg検索技術勉強会 T0.047619047619047616ya) T0.047619047619047616yaの T0.047619047619047616yb運営 T0.047619047619047616ycとして T0.047619047619047616yb参加 T0.047619047619047616yaし T0.047619047619047616yaて S0.09523809523809523yb始め T0.047619047619047616ycみまし T0.047619047619047616yaた T0.047619047619047616ya。 T0.047619047619047616>vc117:yd2018 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091vc118<ya0f0.0625ya7f0.0625ygElasticf0.0625ya e0.125yeStackf0.0625ya.f0.0625yaでf0.0625yb入っf0.0625yaてf0.0625ybくるf0.0625yc新機能f0.0625yaをf0.0625ycちょっf0.0625yaとf0.0625yb紹介f0.0625>vc1196ye2018年 S0.14285714285714285yaの S0.14285714285714285ygElastic R0.2857142857142857ya  S0.14285714285714285yeStack S0.14285714285714285yaと S0.14285714285714285vc1209yd新規導入 R0.1111111111111111yaし R0.1111111111111111yaた R0.1111111111111111ye長期出張用 R0.1111111111111111yaの R0.1111111111111111ydアイテム R0.1111111111111111yaを R0.1111111111111111ydいくつか R0.1111111111111111yb紹介 R0.1111111111111111vc1218yd第25回e0.125y PElasticsearch勉強会e0.125yaをe0.125yb開催e0.125yaしe0.125ybましe0.125yaたe0.125ya。e0.125vc1225ydJJUGc0.2ygナイトセミナーc0.2yaでc0.2yd話しましc0.2yaたc0.2vc123<ygAnalyze S0.07142857142857142ya  S0.07142857142857142ybUI S0.07142857142857142yaと S0.07142857142857142yfKibana S0.07142857142857142yaの S0.14285714285714285yeプラグイン S0.07142857142857142yb作成 S0.07142857142857142yb方法 S0.07142857142857142ya（ S0.07142857142857142ya第 S0.07142857142857142yb3回 S0.07142857142857142ya） S0.07142857142857142>vc124<ygカンファレンス S0.06666666666666667yb情報 S0.06666666666666667yaの S0.06666666666666667yb探し S0.06666666666666667ya方 S0.06666666666666667ya（ S0.06666666666666667ycCfP S0.06666666666666667ya、 S0.13333333333333333yeスポンサー S0.06666666666666667yb応募 S0.06666666666666667yd開催期間 S0.06666666666666667ybなど S0.06666666666666667ya） S0.06666666666666667ya？ S0.06666666666666667>vc125<yc第1章 S0.06666666666666667yaの S0.06666666666666667yb05 S0.06666666666666667ybから S0.06666666666666667yb06 S0.06666666666666667ybまで S0.06666666666666667ybやっ S0.06666666666666667yaて S0.06666666666666667yaみ S0.06666666666666667yaた S0.06666666666666667ya（ S0.06666666666666667yd言語処理 S0.06666666666666667yd100本 S0.06666666666666667ycノック S0.06666666666666667ya） S0.06666666666666667>vc126<yc第1章 S0.06666666666666667yaの S0.06666666666666667yb03 S0.06666666666666667ybから S0.06666666666666667yb04 S0.06666666666666667ybまで S0.06666666666666667ybやっ S0.06666666666666667yaて S0.06666666666666667yaみ S0.06666666666666667yaた S0.06666666666666667ya（ S0.06666666666666667yd言語処理 S0.06666666666666667yd100本 S0.06666666666666667ycノック S0.06666666666666667ya） S0.06666666666666667>vc127<yc第1章 S0.06666666666666667yaの S0.06666666666666667yb00 S0.06666666666666667ybから S0.06666666666666667yb02 S0.06666666666666667ybまで S0.06666666666666667ybやっ S0.06666666666666667yaて S0.06666666666666667yaみ S0.06666666666666667yaた S0.06666666666666667ya（ S0.06666666666666667yd言語処理 S0.06666666666666667yd100本 S0.06666666666666667ycノック S0.06666666666666667ya） S0.06666666666666667>vc1289yd言語処理 R0.1111111111111111yd100本 R0.1111111111111111ycノック R0.1111111111111111yaは R0.1111111111111111ydじめまし R0.1111111111111111yaた R0.1111111111111111ya( R0.1111111111111111ydRust R0.1111111111111111ya) R0.1111111111111111vc129<ygAnalyze S0.07142857142857142ya  S0.07142857142857142ybUI S0.07142857142857142yaと S0.07142857142857142yfKibana S0.07142857142857142yaの S0.14285714285714285yeプラグイン S0.07142857142857142yb作成 S0.07142857142857142yb方法 S0.07142857142857142ya（ S0.07142857142857142ya第 S0.07142857142857142yb2回 S0.07142857142857142ya） S0.07142857142857142>vc130<ygAnalyze S0.07142857142857142ya  S0.07142857142857142ybUI S0.07142857142857142yaと S0.07142857142857142yfKibana S0.07142857142857142yaの S0.14285714285714285yeプラグイン S0.07142857142857142yb作成 S0.07142857142857142yb方法 S0.07142857142857142ya（ S0.07142857142857142ya第 S0.07142857142857142yb1回 S0.07142857142857142ya） S0.07142857142857142>vc131:yd2017 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091vc1325ye2018年c0.2yaのc0.2ygElasticc0.2yaはc0.2ya？c0.2vc1336ye2017年 S0.14285714285714285yaの S0.14285714285714285ygElastic R0.2857142857142857ya  S0.14285714285714285yeStack S0.14285714285714285yaと S0.14285714285714285vc134:yhSwiftype S0.09090909090909091yaが S0.09090909090909091ydジョイン S0.09090909090909091yaし S0.09090909090909091yaた S0.18181818181818182yaの S0.09090909090909091yaで S0.09090909090909091yb触っ S0.09090909090909091yaて S0.09090909090909091ycみまし S0.09090909090909091vc135:ycデータc0.1yh分析基盤構築入門c0.1ya c0.1yaをc0.1yb一部c0.1yb執筆c0.1yaしc0.1ybましc0.1yaたc0.1ya。c0.1vc1367yf検索座談会っe0.125yaてd0.25yaのe0.125yaをe0.125ybやっe0.125yaみe0.125yaたe0.125vc137:yd2016 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091vc1385ye2016年c0.2yaのc0.2ygElasticc0.2ya c0.2yeStackc0.2vc1398ya0e0.125ya5e0.125ymElasticsearche0.125ya e0.125ya.e0.125yaのe0.125yf便利機能紹介e0.125ya？e0.125vc140<yfLucene S0.03571428571428571ya  S0.17857142857142858yhKuromoji S0.03571428571428571ycfor S0.03571428571428571ygNEologd S0.03571428571428571yaで S0.03571428571428571yb指定 S0.03571428571428571yaし S0.03571428571428571yaた S0.07142857142857142yb品詞 S0.03571428571428571yaの S0.03571428571428571yb単語 S0.03571428571428571yaを S0.07142857142857142yb抜き S0.03571428571428571yb出す S0.03571428571428571yfIngest S0.03571428571428571yfPlugin S0.03571428571428571yb書い S0.03571428571428571yaて S0.03571428571428571yaみ S0.03571428571428571ya# S0.03571428571428571yoelasticsearchjp S0.03571428571428571>vc1415ybよくc0.2ya物c0.2yaがc0.2yc壊れるc0.2ya年c0.2vc142;yd第16回 S0.09090909090909091y PElasticsearch勉強会 S0.09090909090909091yaを S0.09090909090909091yb開催 S0.09090909090909091yaし S0.09090909090909091ybまし S0.09090909090909091yaた S0.09090909090909091ya。 S0.09090909090909091ya  S0.09090909090909091ya# S0.09090909090909091yoelasticsearchjp S0.09090909090909091vc143;yd第15回 S0.09090909090909091y PElasticsearch勉強会 S0.09090909090909091yaを S0.09090909090909091yb開催 S0.09090909090909091yaし S0.09090909090909091ybまし S0.09090909090909091yaた S0.09090909090909091ya。 S0.09090909090909091ya  S0.09090909090909091ya# S0.09090909090909091yoelasticsearchjp S0.09090909090909091vc144:ya「c0.1yf自然言語処理c0.1yaのc0.1yb基本c0.1yaとc0.1yb技術c0.1ya」c0.1yaをc0.1yb読んc0.1ybでるc0.1vc145;yd第14回 S0.09090909090909091y PElasticsearch勉強会 S0.09090909090909091yaを S0.09090909090909091yb開催 S0.09090909090909091yaし S0.09090909090909091ybまし S0.09090909090909091yaた S0.09090909090909091ya。 S0.09090909090909091ya  S0.09090909090909091ya# S0.09090909090909091yoelasticsearchjp S0.09090909090909091vc146:yd2015 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091vc1473ye2015年 R0.3333333333333333yaの R0.3333333333333333ymElasticsearch R0.3333333333333333vc148:yd2015 S0.06666666666666667yhTimelion S0.06666666666666667yaの S0.06666666666666667yb紹介 S0.06666666666666667ya c0.4ya- S0.06666666666666667ymElasticsearch S0.06666666666666667yfAdvent S0.06666666666666667yhCalendar S0.06666666666666667yc1日目 S0.06666666666666667vc149:yd第13回c0.1y PElasticsearch勉強会c0.1yaをc0.1yb開催c0.1yaしc0.1ybましc0.1yaたc0.1ya。c0.1ya#c0.1yoelasticsearchjpc0.1vc150<ya0 S0.09523809523809523ya1 T0.047619047619047616ya2 T0.047619047619047616yeSense S0.09523809523809523yaの S0.09523809523809523yb歴史 T0.047619047619047616ya  S0.14285714285714285ya- S0.09523809523809523ya. S0.09523809523809523ydbeta T0.047619047619047616yb紹介 T0.047619047619047616ya( T0.047619047619047616yd日本語訳 T0.047619047619047616ya) T0.047619047619047616>vc151<ya0 S0.11764705882352941ya2 T0.058823529411764705yfShield T0.058823529411764705ya、 S0.11764705882352941ygWatcher T0.058823529411764705yfMarvel T0.058823529411764705ya  S0.11764705882352941ya. S0.11764705882352941ybGA T0.058823529411764705ydリリース T0.058823529411764705ya（ T0.058823529411764705yd日本語訳 T0.058823529411764705ya） T0.058823529411764705>vc1529ya0 S0.18181818181818182ya2 S0.09090909090909091ymElasticsearch S0.09090909090909091ya  S0.09090909090909091ya. S0.18181818181818182ydリリース S0.09090909090909091ya( S0.09090909090909091yd日本語訳 S0.09090909090909091ya) S0.09090909090909091vc153:ya0 S0.09090909090909091ya2 S0.09090909090909091ya4 S0.09090909090909091yfKibana S0.09090909090909091ya  S0.09090909090909091ya. S0.18181818181818182ydリリース S0.09090909090909091ya（ S0.09090909090909091yd日本語訳 S0.09090909090909091ya） S0.09090909090909091vc1549ya0 S0.18181818181818182ya2 S0.09090909090909091yhLogstash S0.09090909090909091ya  S0.09090909090909091ya. S0.18181818181818182ydリリース S0.09090909090909091ya（ S0.09090909090909091yd日本語訳 S0.09090909090909091ya） S0.09090909090909091vc1558ygRelease R0.1111111111111111ya, R0.1111111111111111ya  R0.2222222222222222ybwe R0.1111111111111111ydhave R0.1111111111111111ya（ R0.1111111111111111yd日本語訳 R0.1111111111111111ya） R0.1111111111111111vc156;ya0 S0.14285714285714285ya2 S0.14285714285714285ymElasticsearch S0.07142857142857142ya  S0.07142857142857142ya. S0.14285714285714285ya- S0.07142857142857142ydbeta S0.07142857142857142ydリリース S0.07142857142857142ya（ S0.07142857142857142yd日本語訳 S0.07142857142857142ya） S0.07142857142857142vc157<ya0f0.0625ya2f0.0625ymElasticsearchf0.0625ya f0.1875yiunpluggedf0.0625ya-f0.0625ya.f0.0625ydにおけるf0.0625yfネットワークf0.0625yaのf0.0625yb変更f0.0625ya(f0.0625yd日本語訳f0.0625ya)f0.0625>vc158<ya0 S0.14285714285714285ya1 S0.07142857142857142ya2 S0.07142857142857142ymElasticsearch S0.07142857142857142ya  S0.07142857142857142ya. S0.14285714285714285ya- S0.07142857142857142ydbeta S0.07142857142857142ydリリース S0.07142857142857142ya（ S0.07142857142857142yd日本語訳 S0.07142857142857142ya） S0.07142857142857142>vc159;yfDelete S0.07692307692307693ya  S0.23076923076923078ybby S0.07692307692307693yeQuery S0.07692307692307693ycAPI S0.07692307692307693yaは S0.07692307692307693yeプラグイン S0.07692307692307693yaへ S0.07692307692307693ya（ S0.07692307692307693yd日本語訳 S0.07692307692307693ya） S0.07692307692307693vc160:yd第11回c0.1y PElasticsearch勉強会c0.1yaをc0.1yb開催c0.1yaしc0.1ybましc0.1yaたc0.1ya。c0.1ya#c0.1yoelasticsearchjpc0.1vc161<ya1 S0.15789473684210525ya2 S0.05263157894736842ya6 S0.05263157894736842ya7 S0.05263157894736842ymElasticsearch S0.05263157894736842ya  S0.15789473684210525ya. S0.21052631578947367ycおよび S0.05263157894736842ydリリース S0.05263157894736842ya（ S0.05263157894736842yd日本語訳 S0.05263157894736842ya） S0.05263157894736842>vc162<ya0 S0.05263157894736842ya1 S0.15789473684210525ya6 S0.05263157894736842ya7 S0.05263157894736842ymElasticsearch S0.05263157894736842ya  S0.15789473684210525ya. S0.21052631578947367ycおよび S0.05263157894736842ydリリース S0.05263157894736842ya（ S0.05263157894736842yd日本語訳 S0.05263157894736842ya） S0.05263157894736842>vc163<yb大阪 S0.07142857142857142yaと S0.07142857142857142yb京都 S0.07142857142857142yaで S0.07142857142857142y PElasticsearch勉強会 S0.07142857142857142yaを S0.07142857142857142yb開催 S0.07142857142857142yaし S0.07142857142857142ybまし S0.07142857142857142yaた S0.07142857142857142ya。 S0.07142857142857142ya  S0.07142857142857142ya# S0.07142857142857142yoelasticsearchjp S0.07142857142857142>vc1647ygMapping S0.14285714285714285yaの S0.14285714285714285yeすばらしい S0.14285714285714285yhリファクタリング S0.14285714285714285ya（ S0.14285714285714285yd日本語訳 S0.14285714285714285ya） S0.14285714285714285vc165<ya0 S0.13333333333333333ya1 S0.06666666666666667ya2 S0.06666666666666667ymElasticsearch S0.06666666666666667ya  S0.06666666666666667ya.c0.2ydbeta S0.06666666666666667ydリリース S0.06666666666666667yb間近 S0.06666666666666667ya（ S0.06666666666666667yd日本語訳 S0.06666666666666667ya） S0.06666666666666667>vc1669ybさら R0.1111111111111111yaに R0.1111111111111111yb進化 R0.1111111111111111yaし R0.1111111111111111yaた R0.1111111111111111yeFound R0.1111111111111111ya（ R0.1111111111111111yd日本語訳 R0.1111111111111111ya） R0.1111111111111111vc167<ylJustTechTalk S0.05555555555555555ya# S0.05555555555555555yb02 S0.05555555555555555ya  S0.05555555555555555ye形態素解析 S0.05555555555555555yaの S0.05555555555555555ybあれ S0.05555555555555555yaや R0.1111111111111111ybこれ S0.05555555555555555ya@ S0.05555555555555555yhジャストシステム S0.05555555555555555yaに S0.05555555555555555yb参加 S0.05555555555555555yaし S0.05555555555555555ybまし S0.05555555555555555yaた S0.05555555555555555ya。 S0.05555555555555555>vc168<ya5 T0.047619047619047616yfHatena T0.047619047619047616ya  R0.2857142857142857yhEngineer T0.047619047619047616ygSeminar T0.047619047619047616ya# S0.09523809523809523ya@ T0.047619047619047616yeTokyo T0.047619047619047616yaに T0.047619047619047616yb参加 T0.047619047619047616yaし T0.047619047619047616ybまし T0.047619047619047616yaた T0.047619047619047616ya。 T0.047619047619047616yjhatenatech T0.047619047619047616>vc169:ya0 S0.09090909090909091ya1 S0.09090909090909091ya6 S0.09090909090909091ymElasticsearch S0.09090909090909091ya  S0.09090909090909091ya. S0.18181818181818182ydリリース S0.09090909090909091ya（ S0.09090909090909091yd日本語訳 S0.09090909090909091ya） S0.09090909090909091vc170:yd第10回c0.1y PElasticsearch勉強会c0.1yaをc0.1yb開催c0.1yaしc0.1ybましc0.1yaたc0.1ya。c0.1ya#c0.1yoelasticsearchjpc0.1vc171;yhLogstash S0.09090909090909091yaを S0.09090909090909091yb使っ S0.09090909090909091yaた S0.09090909090909091ymElasticsearch S0.09090909090909091yaの S0.09090909090909091ya再 S0.09090909090909091yfインデックス S0.09090909090909091ya（ S0.09090909090909091yd日本語訳 S0.09090909090909091ya） S0.09090909090909091vc1728ygdiscuss R0.1111111111111111ya. R0.2222222222222222ygelastic R0.1111111111111111ybco R0.1111111111111111ya  R0.1111111111111111ycにぜひ R0.1111111111111111yb参加 R0.1111111111111111yaを R0.1111111111111111vc173<ya1 S0.10526315789473684ya2 S0.05263157894736842ya4 S0.05263157894736842ya5 S0.10526315789473684ymElasticsearch S0.05263157894736842ya  S0.15789473684210525ya. S0.21052631578947367ycおよび S0.05263157894736842ydリリース S0.05263157894736842ya（ S0.05263157894736842yd日本語訳 S0.05263157894736842ya） S0.05263157894736842>vc174:yc第9回c0.1y PElasticsearch勉強会c0.1yaをc0.1yb開催c0.1yaしc0.1ybましc0.1yaたc0.1ya。c0.1ya#c0.1yoelasticsearchjpc0.1vc1759ya1 S0.18181818181818182ya5 S0.09090909090909091ymElasticsearch S0.09090909090909091ya  S0.09090909090909091ya. S0.18181818181818182ydリリース S0.09090909090909091ya（ S0.09090909090909091yd日本語訳 S0.09090909090909091ya） S0.09090909090909091vc176<y PElasticsearch勉強会f0.0625ya f0.1875ybinf0.0625yc名古屋f0.0625yaをf0.0625yb開催f0.0625yaしf0.0625ybましf0.0625yaたf0.0625ya。f0.0625ya#e0.125ymelasticsearchf0.0625yoelasticsearchjpf0.0625>vc177:ya0 S0.09090909090909091ya1 S0.09090909090909091ya5 S0.09090909090909091ymElasticsearch S0.09090909090909091ya  S0.09090909090909091ya. S0.18181818181818182ydリリース S0.09090909090909091ya（ S0.09090909090909091yd日本語訳 S0.09090909090909091ya） S0.09090909090909091vc1785ya#c0.2yielasticonc0.2ya c0.2yaにc0.2yc参加中c0.2vc1799yfセキュリティ R0.1111111111111111yb向け R0.1111111111111111yeプラグイン R0.1111111111111111yfShield R0.1111111111111111yaの R0.1111111111111111ydリリース R0.1111111111111111ya（ R0.1111111111111111yd日本語訳 R0.1111111111111111ya） R0.1111111111111111vc1805ymElasticsearchc0.2ya c0.2ydCorec0.2yfトレーニングc0.2yb開催c0.2vc1816ya4 S0.16666666666666666yfKibana S0.16666666666666666ya  S0.16666666666666666ya（ S0.16666666666666666yd日本語訳 S0.16666666666666666ya） S0.16666666666666666vc182<ya1 S0.11764705882352941ya3 T0.058823529411764705ya4 S0.11764705882352941ya9 T0.058823529411764705ymElasticsearch T0.058823529411764705ya  T0.058823529411764705ya. S0.23529411764705882ycおよび T0.058823529411764705ydリリース T0.058823529411764705ya（ T0.058823529411764705yd日本語訳 T0.058823529411764705ya） T0.058823529411764705>vc1837yc名古屋 S0.14285714285714285yaで S0.14285714285714285y PElasticsearch勉強会 S0.14285714285714285yaを S0.14285714285714285yb開催 S0.14285714285714285yaし S0.14285714285714285ybます S0.14285714285714285vc184:yc第8回c0.1y PElasticsearch勉強会c0.1yaをc0.1yb開催c0.1yaしc0.1ybましc0.1yaたc0.1ya。c0.1ya#c0.1yoelasticsearchjpc0.1vc185:yfGroovyc0.1yeスクリプトc0.1yaをc0.1ykダイナミックスクリプトc0.1ybなしc0.1yaでc0.1yb実行c0.1ya(c0.1yd日本語訳c0.1ya)c0.1vc186<ya1 S0.11764705882352941ya3 S0.11764705882352941ya4 T0.058823529411764705ya8 T0.058823529411764705ymElasticsearch T0.058823529411764705ya　 T0.058823529411764705ya. S0.23529411764705882ycおよび T0.058823529411764705ydリリース T0.058823529411764705ya（ T0.058823529411764705yd日本語訳 T0.058823529411764705ya） T0.058823529411764705>vc187;yd2015 S0.15384615384615385yeCROSS S0.07692307692307693ya  S0.15384615384615385yaで S0.07692307692307693ya話 S0.07692307692307693yaを S0.07692307692307693ybして S0.07692307692307693ycきまし S0.07692307692307693yaた S0.07692307692307693ya# S0.07692307692307693yecross S0.07692307692307693vc188:yd2014 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091vc1898ya2 R0.1111111111111111ymElasticsearch R0.1111111111111111ya  R0.1111111111111111ya. R0.1111111111111111yb0系 R0.1111111111111111yaの R0.2222222222222222yeIssue R0.1111111111111111yb紹介 R0.1111111111111111vc190:ya0 S0.09090909090909091ya1 S0.09090909090909091ya3 S0.09090909090909091yfMarvel S0.09090909090909091ya  S0.09090909090909091ya. S0.18181818181818182ydリリース S0.09090909090909091ya（ S0.09090909090909091yd日本語訳 S0.09090909090909091ya） S0.09090909090909091vc191<ya1 S0.11764705882352941ya2 T0.058823529411764705ya3 T0.058823529411764705ya4 T0.058823529411764705ya7 T0.058823529411764705ymElasticsearch T0.058823529411764705ya  T0.058823529411764705ya. S0.23529411764705882ycおよび T0.058823529411764705ydリリース T0.058823529411764705ya（ T0.058823529411764705yd日本語訳 T0.058823529411764705ya） T0.058823529411764705>vc192<ydJJUGe0.125ya f0.0625ygナイトセミナーf0.0625yaでf0.0625yfLucenef0.0625yaのf0.0625yb簡単f0.0625yaなf0.0625yb紹介f0.0625yaをf0.0625ybしてf0.0625ycきましf0.0625yaたf0.0625ya。f0.0625ya#f0.0625>vc1931yhコーヒーブレイクQvc1948yhLogstash R0.1111111111111111yeプラグイン R0.1111111111111111yaの R0.2222222222222222yfエコシステム R0.1111111111111111yb変更 R0.1111111111111111ya（ R0.1111111111111111yd日本語訳 R0.1111111111111111ya） R0.1111111111111111vc195;ya0 S0.07142857142857142ya1 S0.14285714285714285ya5 S0.07142857142857142yhLogstash S0.07142857142857142ya  S0.14285714285714285ya. S0.14285714285714285ydBeta S0.07142857142857142ydリリース S0.07142857142857142ya( S0.07142857142857142yd日本語訳 S0.07142857142857142ya) S0.07142857142857142vc1963ye2014年 R0.3333333333333333yaの R0.3333333333333333ymElasticsearch R0.3333333333333333vc197<ya1 S0.17647058823529413ya3 T0.058823529411764705ya4 T0.058823529411764705ya6 T0.058823529411764705ymElasticsearch T0.058823529411764705ya  T0.058823529411764705ya. S0.23529411764705882ycおよび T0.058823529411764705ydリリース T0.058823529411764705ya（ T0.058823529411764705yd日本語訳 T0.058823529411764705ya） T0.058823529411764705>vc1983ylインデックステンプレート R0.3333333333333333yaと R0.3333333333333333yhLogstash R0.3333333333333333vc1999yhLogstash R0.1111111111111111yaを R0.1111111111111111yb利用 R0.1111111111111111yaし R0.1111111111111111yaた R0.1111111111111111yfApache R0.1111111111111111yfアクセスログ R0.1111111111111111yaの R0.1111111111111111yeインポート R0.1111111111111111vc200:yc第7回c0.1y PElasticsearch勉強会c0.1yaをc0.1yb開催c0.1yaしc0.1ybましc0.1yaたc0.1ya。c0.1ya#c0.1yoelasticsearchjpc0.1vc201<ya0 T0.058823529411764705ya1 S0.11764705882352941ya3 T0.058823529411764705ya4 T0.058823529411764705ya5 T0.058823529411764705ymElasticsearch T0.058823529411764705ya  T0.058823529411764705ya. S0.23529411764705882ycおよび T0.058823529411764705ydリリース T0.058823529411764705ya（ T0.058823529411764705yd日本語訳 T0.058823529411764705ya） T0.058823529411764705>vc2025yhvalidatec0.2ya c0.2ycAPIc0.2yaのc0.2yb利用c0.2vc2037yhSonatype R0.1111111111111111yaの R0.2222222222222222yeバージョン R0.1111111111111111yb番号 R0.1111111111111111yaで R0.2222222222222222yb困っ R0.1111111111111111yaた R0.1111111111111111vc2049ya0 S0.08333333333333333ya1 S0.16666666666666666ya4 S0.08333333333333333ymelasticsearch S0.08333333333333333ya  S0.08333333333333333ya.d0.25ydBeta S0.08333333333333333yaの S0.08333333333333333ydリリース S0.08333333333333333vc205:yc第6回c0.1y PElasticsearch勉強会c0.1yaをc0.1yb開催c0.1yaしc0.1ybましc0.1yaたc0.1ya。c0.1ya#c0.1yoelasticsearchjpc0.1vc206<ymelasticsearchf0.0625ya.f0.0625yeもうちょっf0.0625yaとf0.0625yb入門f0.0625ycというf0.0625ya話f0.0625yaをf0.0625ybしてf0.0625ycきましf0.0625yaたf0.0625ya f0.0625ya#f0.0625yegihyof0.0625ya_f0.0625ycefkf0.0625>vc2077ymElasticsearch S0.14285714285714285yaの S0.14285714285714285ygインデキシング S0.14285714285714285yaに S0.14285714285714285yc関する S0.14285714285714285ygパフォーマンス S0.14285714285714285yb検討 S0.14285714285714285vc208<ycサーバ S0.07142857142857142ya/ S0.07142857142857142ymインフラエンジニア養成読本 S0.07142857142857142ya  S0.14285714285714285ybログ S0.07142857142857142yb収集 S0.07142857142857142ya~ S0.07142857142857142yd可視化編 S0.07142857142857142yaを S0.07142857142857142yb手伝 S0.07142857142857142yaい S0.07142857142857142ybまし S0.07142857142857142yaた S0.07142857142857142>vc2097ydプロキシe0.125yb環境e0.125yaでe0.125yaのd0.25yfplugine0.125ydコマンドe0.125yb実行e0.125vc2109ya1 S0.16666666666666666ya3 S0.08333333333333333ymElasticsearch S0.08333333333333333ya  S0.16666666666666666ya. S0.16666666666666666ydリリース S0.08333333333333333ya（ S0.08333333333333333yd日本語訳 S0.08333333333333333ya） S0.08333333333333333vc2117ya1c0.3ya2c0.1ygCuratorc0.1ya c0.1ya.c0.2ycおよびc0.1ydについてc0.1vc212:yc第5回c0.1y PElasticsearch勉強会c0.1yaをc0.1yb開催c0.1yaしc0.1ybましc0.1yaたc0.1ya。c0.1ya#c0.1yoelasticsearchjpc0.1vc2134yb転職d0.25yaしd0.25ybましd0.25yaたd0.25vc2144yb退職d0.25yaしd0.25ybましd0.25yaたd0.25vc2157ymElasticsearch R0.1111111111111111ya  R0.3333333333333333yfserver R0.1111111111111111yc2nd R0.1111111111111111ygedition R0.1111111111111111yaの R0.1111111111111111ymファーストインプレッション R0.1111111111111111vc216;yc可視化 S0.16666666666666666ycツール S0.08333333333333333ye現状確認会 S0.08333333333333333yaに S0.08333333333333333yb参加 S0.08333333333333333yaし S0.08333333333333333yaて S0.08333333333333333ycきまし S0.08333333333333333yaた S0.08333333333333333ya。 S0.08333333333333333ya# S0.08333333333333333vc2178yb最新e0.125ymインフラエンジニア技術勉強e0.125yaにe0.125yb参加e0.125yaしe0.125ybましe0.125yaたe0.125ya。e0.125vc218<ya「 S0.07142857142857142yeよくわかる S0.07142857142857142yfAmazon S0.07142857142857142ya  S0.14285714285714285ya# S0.07142857142857142ykCloudSearch S0.07142857142857142ya」 S0.07142857142857142yaに S0.07142857142857142yb行っ S0.07142857142857142yaて S0.07142857142857142ycきまし S0.07142857142857142yaた S0.07142857142857142ya！ S0.07142857142857142>vc2197ya外 S0.14285714285714285yaの S0.14285714285714285yb世界 S0.14285714285714285yaを S0.14285714285714285yb知る S0.14285714285714285ycという S0.14285714285714285ybこと S0.14285714285714285vc2204ymアジャイルデータサイエンスd0.25yaがd0.25yd届きましd0.25yaたd0.25vc2218ylAggregations R0.1111111111111111ya  R0.2222222222222222ya- R0.1111111111111111yeファセット R0.1111111111111111ycよりも R0.1111111111111111yb柔軟 R0.1111111111111111yaな R0.1111111111111111yb集計 R0.1111111111111111vc2229ymelasticsearch R0.1111111111111111ya- R0.1111111111111111ydkopf R0.1111111111111111yaの R0.1111111111111111yb紹介 R0.1111111111111111ya（ R0.1111111111111111ygaliases R0.1111111111111111yb画面 R0.1111111111111111ya） R0.1111111111111111vc2238ya2e0.125yfstreame0.125ybese0.125yaとe0.125yb複数e0.125ycデータe0.125yaのe0.125yb登録e0.125vc224:yc第4回c0.1y PElasticsearch勉強会c0.1yaをc0.1yb開催c0.1yaしc0.1ybましc0.1yaたc0.1ya。c0.1ya#c0.1yoelasticsearchjpc0.1vc2259ymelasticsearch R0.1111111111111111ya- R0.1111111111111111ydkopf R0.1111111111111111yaの R0.1111111111111111yb紹介 R0.1111111111111111ya（ R0.1111111111111111yhanalysis R0.1111111111111111yb画面 R0.1111111111111111ya） R0.1111111111111111vc226<ycJVM S0.06666666666666667ya  S0.26666666666666666yiOperation S0.06666666666666667yfCasual S0.06666666666666667yeTalks S0.06666666666666667yaに S0.06666666666666667yb参加 S0.06666666666666667yaし S0.06666666666666667ybまし S0.06666666666666667yaた S0.06666666666666667ya# S0.06666666666666667yijvmcasual S0.06666666666666667>vc2279ymelasticsearch R0.1111111111111111ya- R0.1111111111111111ydkopf R0.1111111111111111yaの R0.1111111111111111yb紹介 R0.1111111111111111ya（ R0.1111111111111111ydrest R0.1111111111111111yb画面 R0.1111111111111111ya） R0.1111111111111111vc2288ymelasticsearche0.125ya-e0.125ydkopfe0.125yaのe0.125yb紹介e0.125ya（e0.125yb概要e0.125ya）e0.125vc229<ymElasticSearch S0.07692307692307693ya  S0.07692307692307693yjServer日本語版 S0.07692307692307693ya（ S0.07692307692307693yc電子版 S0.07692307692307693yaも S0.07692307692307693ya） S0.07692307692307693yaが S0.07692307692307693yb発売 S0.07692307692307693yaさ S0.07692307692307693yaれ S0.07692307692307693ybまし S0.07692307692307693yaた S0.07692307692307693>vc2309ydGOTOc0.1ya c0.2yeNightc0.1ymelasticsearchc0.1yaにc0.1yb参加c0.1yaしc0.1ybましc0.1yaたc0.1vc2315yfBerlinc0.2ycからおc0.2yaはc0.2ybようc0.2yeございますc0.2vc2327ycいつも S0.14285714285714285yb入れ S0.14285714285714285yaて S0.14285714285714285ybいる S0.14285714285714285ymElasticsearch S0.14285714285714285yaの S0.14285714285714285yeプラグイン S0.14285714285714285vc2338ymElasticSearche0.125ya e0.125yfServere0.125yaをe0.125yb翻訳e0.125yaしe0.125ybましe0.125yaたe0.125vc2348yfNested R0.1111111111111111ya  R0.1111111111111111yfObject R0.1111111111111111yaの R0.2222222222222222yeフィールド R0.1111111111111111yb奇妙 R0.1111111111111111yaな R0.1111111111111111yb動作 R0.1111111111111111vc235;yc第3回 S0.09090909090909091y Pelasticsearch勉強会 S0.09090909090909091yaを S0.09090909090909091yb開催 S0.09090909090909091yaし S0.09090909090909091ybまし S0.09090909090909091yaた S0.09090909090909091ya！ S0.09090909090909091ya  S0.09090909090909091ya# S0.09090909090909091yoelasticsearchjp S0.09090909090909091vc236<yfすずけんさん S0.06666666666666667yaの S0.06666666666666667ybメモ S0.06666666666666667yaを S0.13333333333333333ya元 S0.06666666666666667yaに S0.06666666666666667ygVagrant S0.06666666666666667yaで S0.06666666666666667y QElasticsearchクラスタ S0.06666666666666667yb起動 S0.06666666666666667yaし S0.06666666666666667yaて S0.06666666666666667yaみ S0.06666666666666667yaた S0.06666666666666667>vc2378yd第13回e0.125ydSolre0.125yc勉強会e0.125yaをe0.125yb開催e0.125yaしe0.125ybましe0.125yaたe0.125vc2387ymElasticsearch S0.14285714285714285ya  S0.14285714285714285yfMarvel S0.14285714285714285yaの S0.14285714285714285yb紹介 S0.14285714285714285yaと S0.14285714285714285yd第一印象 S0.14285714285714285vc239<ya1 S0.07142857142857142ya4 S0.07142857142857142ya6 S0.07142857142857142yflucene S0.07142857142857142ya- S0.07142857142857142yegosen S0.07142857142857142ya  S0.07142857142857142ya. S0.14285714285714285yaの S0.07142857142857142ydリリース S0.07142857142857142yaに S0.07142857142857142yc関する S0.07142857142857142yc注意点 S0.07142857142857142>vc240:ygCuratorc0.1ya:c0.1ya c0.1yc時系列c0.1yfインデックスc0.1yaのc0.1yb管理c0.1ya(c0.1yd日本語訳c0.1ya)c0.1vc241<ya0 S0.13333333333333333ya1 S0.13333333333333333yhExtended S0.06666666666666667ya- S0.06666666666666667ygAnalyze S0.06666666666666667ya  S0.06666666666666667ya. S0.13333333333333333ybRC S0.06666666666666667yaを S0.06666666666666667ydリリース S0.06666666666666667ycしまし S0.06666666666666667yaた S0.06666666666666667>vc242:yd2013 S0.09090909090909091yb今年 S0.09090909090909091yaの S0.18181818181818182yb振り S0.09090909090909091yb返り S0.09090909090909091yaと S0.09090909090909091yb来年 S0.09090909090909091yb抱負 S0.09090909090909091ya（ S0.09090909090909091ya） S0.09090909090909091vc243<ya0 T0.045454545454545456ya8 T0.045454545454545456yb12 T0.045454545454545456yb90 T0.045454545454545456yd2013 T0.045454545454545456ymElasticsearch T0.045454545454545456ya  T0.045454545454545456ya. S0.09090909090909091yaが T0.045454545454545456ydリリース T0.045454545454545456yaさ T0.045454545454545456yaれ T0.045454545454545456ybまし T0.045454545454545456yaた T0.045454545454545456ya＆ T0.045454545454545456yc注意点 T0.045454545454545456ya（ T0.045454545454545456ya/ S0.09090909090909091yd20追記 T0.045454545454545456ya） T0.045454545454545456>vc2447ydSolre0.125yaへe0.125yaのd0.25yeプラグインe0.125yb配置e0.125yb方法e0.125ydについてe0.125vc245;ymelasticsearch S0.08333333333333333ya- S0.16666666666666666yhextended S0.08333333333333333yganalyze S0.08333333333333333yeプラグイン S0.08333333333333333yaを S0.08333333333333333yeMaven S0.08333333333333333yaと S0.08333333333333333yhSonatype S0.08333333333333333yaに S0.08333333333333333ydリリース S0.08333333333333333vc2468yc改訂版e0.125ydSolre0.125yb入門e0.125yaのe0.125ycPDFe0.125ya版e0.125yaもe0.125yb発売e0.125vc2478yc改訂版e0.125ydSolre0.125yb入門e0.125yaをe0.125yb執筆e0.125yaしe0.125ybましe0.125yaたe0.125vc2487ymelasticsearche0.125ya-d0.25yhextendede0.125yganalyzee0.125yaをe0.125yb公開e0.125ya？e0.125vc249;yc第2回 S0.09090909090909091y Pelasticsearch勉強会 S0.09090909090909091yaを S0.09090909090909091yb開催 S0.09090909090909091yaし S0.09090909090909091ybまし S0.09090909090909091yaた S0.09090909090909091ya！ S0.09090909090909091ya  S0.09090909090909091ya# S0.09090909090909091yoelasticsearchjp S0.09090909090909091vc250<yd2013 R0.1111111111111111yhCloudera S0.05555555555555555ya  R0.2777777777777778yeWorld S0.05555555555555555yeTokyo S0.05555555555555555yaに S0.05555555555555555yb参加 S0.05555555555555555yaし S0.05555555555555555ybまし S0.05555555555555555yaた S0.05555555555555555ya！ S0.05555555555555555ya# S0.05555555555555555yccwt S0.05555555555555555>vc251<ya3f0.0625ydRiakf0.0625ya d0.25yfMeetupf0.0625ya#e0.125yfriakjpf0.0625yaにf0.0625yb参加f0.0625yaしf0.0625ybましf0.0625yaたf0.0625ya。f0.0625>vc2526ymelasticsearch S0.14285714285714285ya- R0.2857142857142857yhextended S0.14285714285714285yganalyze S0.14285714285714285yaの S0.14285714285714285yb改良 S0.14285714285714285vc2537ymelasticsearche0.125ya-d0.25yhextendede0.125yganalyzee0.125yeプラグインe0.125yaをe0.125yc開発中e0.125vc254;yd第12回 S0.09090909090909091ydSolr S0.09090909090909091yc勉強会 S0.09090909090909091yaを S0.09090909090909091yb主催 S0.09090909090909091yaし S0.09090909090909091ybまし S0.09090909090909091yaた S0.09090909090909091ya。 S0.09090909090909091ya# S0.09090909090909091yfSolrJP S0.09090909090909091vc2556ymelasticsearch S0.16666666666666666ya- S0.16666666666666666yjinquisitor S0.16666666666666666yeプラグイン S0.16666666666666666yaの S0.16666666666666666yb紹介 S0.16666666666666666vc2566ymelasticsearch S0.14285714285714285ya- R0.2857142857142857yeriver S0.14285714285714285yiwikipedia S0.14285714285714285yaの S0.14285714285714285yc疑問点 S0.14285714285714285vc2578yc日本語e0.125yiWikipediae0.125yaをe0.125ygインデクシングe0.125ya（e0.125yhKuromojie0.125yeバージョンe0.125ya）e0.125vc258;yc第1回 S0.09090909090909091y PElasticSearch勉強会 S0.09090909090909091yaを S0.09090909090909091yb開催 S0.09090909090909091yaし S0.09090909090909091ybまし S0.09090909090909091yaた S0.09090909090909091ya！ S0.09090909090909091ya  S0.09090909090909091ya# S0.09090909090909091yoelasticsearchjp S0.09090909090909091vc259<ymElasticSearch S0.08333333333333333yaに S0.08333333333333333yeプラグイン S0.08333333333333333yaで S0.08333333333333333yc日本語 S0.08333333333333333yiWikipedia S0.08333333333333333ycデータ S0.08333333333333333yaを S0.08333333333333333yb入れ S0.08333333333333333yaて S0.08333333333333333ycみまし S0.08333333333333333yaた S0.08333333333333333>vc260;yjMorphlines S0.09090909090909091yaの S0.09090909090909091yhloadSolr S0.09090909090909091yaを S0.09090909090909091ycちょっ S0.09090909090909091yaと S0.09090909090909091ybだけ S0.09090909090909091yb調べ S0.09090909090909091yaて S0.09090909090909091yaみ S0.09090909090909091yaた S0.09090909090909091vc261;yfXperia S0.06666666666666667ya  S0.06666666666666667yaZ S0.06666666666666667yaが S0.06666666666666667yb故障 S0.06666666666666667yaし S0.13333333333333333yaた S0.13333333333333333yaの S0.13333333333333333yaで S0.13333333333333333yb交換 S0.06666666666666667ybメモ S0.06666666666666667vc2623yjMorphlines R0.3333333333333333yb入門 R0.3333333333333333ya？ R0.3333333333333333vc263;yd第11回 S0.09090909090909091ydSolr S0.09090909090909091yc勉強会 S0.09090909090909091yaを S0.09090909090909091yb主催 S0.09090909090909091yaし S0.09090909090909091ybまし S0.09090909090909091yaた S0.09090909090909091ya。 S0.09090909090909091ya# S0.09090909090909091yfSolrJP S0.09090909090909091vc264<ya『 S0.08333333333333333ygプログラミング T0.041666666666666664ya  S0.16666666666666666ydHive T0.041666666666666664ya』 S0.08333333333333333yfHadoop T0.041666666666666664ya第 T0.041666666666666664yb3版 T0.041666666666666664yd刊行記念 T0.041666666666666664ydセミナー T0.041666666666666664yaに T0.041666666666666664yb参加 T0.041666666666666664yaし T0.041666666666666664ybまし T0.041666666666666664yaた T0.041666666666666664ya！ T0.041666666666666664ya# T0.041666666666666664ygoreilly T0.041666666666666664yd0724 T0.041666666666666664>vc2658yhYokozuna R0.1111111111111111yaの R0.1111111111111111ya気 R0.1111111111111111yaに R0.1111111111111111ybなる R0.1111111111111111ya点 R0.1111111111111111ydというか R0.2222222222222222ybなん R0.1111111111111111vc266<ya2f0.0625ydRiakf0.0625ya f0.1875yfMeetupf0.0625yeTokyof0.0625ya#e0.125yaにf0.0625yb参加f0.0625yaしf0.0625ybましf0.0625yaたf0.0625ya。f0.0625yfriakjpf0.0625>vc267<yd4897 S0.07692307692307693yiスキーマレスモード S0.07692307692307693ya？ S0.07692307692307693ya（ S0.07692307692307693ydSOLR S0.07692307692307693ya- S0.07692307692307693ya） S0.07692307692307693yaを S0.07692307692307693yb調べ S0.07692307692307693yaて S0.07692307692307693yc見まし S0.07692307692307693yaた S0.07692307692307693ya。 S0.07692307692307693>vc2687ydSolr S0.14285714285714285yaの S0.14285714285714285yb管理 S0.14285714285714285yb画面 S0.14285714285714285yaで S0.14285714285714285ycデータ S0.14285714285714285yb登録 S0.14285714285714285vc2696ya3 S0.16666666666666666yfKibana S0.16666666666666666ycという S0.16666666666666666yaの S0.16666666666666666yaも S0.16666666666666666yeありまして S0.16666666666666666vc2707yeBashoe0.125ya e0.125yeJapane0.125yaにd0.25yb遊びe0.125yd行きましe0.125yaたe0.125vc2718yc新しいe0.125ydsolre0.125ya.e0.125ycxmle0.125yaとe0.125ydCoree0.125yb探索e0.125ydロジックe0.125vc272;yfapached0.05ya-d0.05yfloggend0.05ya c0.4ya+d0.15ygfluentdd0.05ymelasticsearchd0.05yfkibanad0.05ya=d0.05ydログ検索d0.05ybデモd0.05vc273<ya2d0.05yd2013d0.05ycAWSd0.05ya c0.2yfSummitd0.05yeTokyod0.05yaにd0.05yb行っd0.05yaてd0.05yc来ましd0.05yaたd0.05ya。d0.05ya(d0.05ycDayd0.05ya)d0.05ya#d0.05yiawssummitd0.05>vc2747yhCloudera S0.14285714285714285ya  S0.14285714285714285yfSearch S0.14285714285714285ybメモ S0.14285714285714285ya（ S0.14285714285714285yc妄想版 S0.14285714285714285ya） S0.14285714285714285vc275<ya1d0.05yd2013d0.05ycAWSd0.05ya c0.2yfSummitd0.05yeTokyod0.05yaにd0.05yb行っd0.05yaてd0.05yc来ましd0.05yaたd0.05ya。d0.05ya(d0.05ycDayd0.05ya)d0.05ya#d0.05yiawssummitd0.05>vc2766yhCloudera S0.16666666666666666ya  S0.16666666666666666yfSearch S0.16666666666666666yaの S0.16666666666666666yeモジュール S0.16666666666666666ybたち S0.16666666666666666vc277<yhCloudera S0.07142857142857142ya  S0.07142857142857142yhSearchって S0.07142857142857142yaの S0.07142857142857142yaが S0.07142857142857142ya出 S0.07142857142857142ydたらしい S0.07142857142857142ya（ S0.07142857142857142ybとり S0.07142857142857142ycあえず S0.07142857142857142ya、 S0.07142857142857142yb雑感 S0.07142857142857142ya？ S0.07142857142857142ya） S0.07142857142857142>vc2789yffluentc0.1ya-c0.2yfpluginc0.1ylzoomdata作りましc0.1yaたc0.1ya＋c0.1yb悩みc0.1yb事とc0.1yaかc0.1vc2799yiOctopress R0.1111111111111111yaを R0.1111111111111111yb試し R0.1111111111111111ya中 R0.1111111111111111ya( R0.1111111111111111yeJugem R0.1111111111111111ybより R0.1111111111111111yb移植 R0.1111111111111111ya) R0.1111111111111111vc2801ynOctopress始めましたQvc281<ya0 S0.05555555555555555ya3 S0.05555555555555555ya4 S0.05555555555555555yflucene T0.027777777777777776ya- T0.027777777777777776yegosen T0.027777777777777776ya. R0.1111111111111111yaを T0.027777777777777776ydリリース T0.027777777777777776ycしまし T0.027777777777777776yaた T0.027777777777777776ya。 T0.027777777777777776ya（ T0.027777777777777776yfLucene T0.027777777777777776ya/ T0.027777777777777776ydSolr T0.027777777777777776yb以上 T0.027777777777777776yaで S0.05555555555555555yaの T0.027777777777777776yb利用 T0.027777777777777776yaが T0.027777777777777776yb可能 T0.027777777777777776yaす T0.027777777777777776ya） T0.027777777777777776ya( T0.027777777777777776yeJugem T0.027777777777777776ybより T0.027777777777777776yb移植 T0.027777777777777776ya) T0.027777777777777776>vc282<ygポモドーロ回し S0.08333333333333333yaて S0.08333333333333333ybます S0.08333333333333333ya。 S0.08333333333333333ya（ S0.08333333333333333y Qポモドーロテクニック入門読みました S0.08333333333333333ya） S0.08333333333333333ya( S0.08333333333333333yeJugem S0.08333333333333333ybより S0.08333333333333333yb移植 S0.08333333333333333ya) S0.08333333333333333>vc283<ya0 S0.05263157894736842ya3 S0.05263157894736842ya4 S0.05263157894736842ydSolr S0.05263157894736842ya. S0.10526315789473684yaの S0.05263157894736842ygChanges S0.05263157894736842yaを S0.05263157894736842yb訳し S0.05263157894736842yaて S0.05263157894736842yaみ S0.05263157894736842yaた S0.05263157894736842ya。 S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc284<ya0 S0.02702702702702703ya3 S0.02702702702702703ya4 S0.02702702702702703yfLucene S0.02702702702702703ya  S0.13513513513513514ya. S0.05405405405405406yaの S0.05405405405405406ygChanges S0.05405405405405406yaに S0.05405405405405406ybある S0.02702702702702703ybin S0.02702702702702703yibackwards S0.02702702702702703ymcompatibility S0.02702702702702703yfpolicy S0.02702702702702703yaが S0.02702702702702703ya気 S0.02702702702702703ybなっ S0.02702702702702703yaた S0.05405405405405406yaで S0.02702702702702703yb訳し S0.02702702702702703yaて S0.02702702702702703yaみ S0.02702702702702703ya。 S0.02702702702702703ya( S0.02702702702702703yeJugem S0.02702702702702703ybより S0.02702702702702703yb移植 S0.02702702702702703ya) S0.02702702702702703>vc285<ya2 T0.023255813953488372yeエンジニア T0.023255813953488372yaの S0.06976744186046512ybため T0.023255813953488372yfスキルアップ T0.023255813953488372yc勉強会 T0.023255813953488372ya『 T0.023255813953488372ydTech T0.023255813953488372ya  S0.11627906976744186ygCompass T0.023255813953488372ya』 T0.023255813953488372ya# T0.023255813953488372yftecomp T0.023255813953488372ya― T0.023255813953488372ycVol T0.023255813953488372ya. T0.023255813953488372ya「 T0.023255813953488372yb人気 T0.023255813953488372ycWeb T0.023255813953488372ydサービス T0.023255813953488372yb作り T0.023255813953488372yb方教 T0.023255813953488372yaえ T0.023255813953488372ybます T0.023255813953488372ya！ T0.023255813953488372ya」 T0.023255813953488372yaに T0.023255813953488372yb参加 T0.023255813953488372yaし T0.023255813953488372ybまし T0.023255813953488372yaた T0.023255813953488372ya。 T0.023255813953488372ya( T0.023255813953488372yeJugem T0.023255813953488372ybより T0.023255813953488372yb移植 T0.023255813953488372ya) T0.023255813953488372>vc286<ydJIRA S0.08333333333333333yaの S0.08333333333333333ycデータ S0.08333333333333333yaを S0.08333333333333333ybS3 S0.08333333333333333yaへ S0.08333333333333333yfバックアップ S0.08333333333333333ya( S0.08333333333333333yeJugem S0.08333333333333333ybより S0.08333333333333333yb移植 S0.08333333333333333ya) S0.08333333333333333>vc287<ya8 T0.034482758620689655yfHeroku T0.034482758620689655ya  R0.2413793103448276yfMeetup T0.034482758620689655ya# S0.06896551724137931ylTreasureData T0.034482758620689655ya+ T0.034482758620689655ydWaza T0.034482758620689655yfReport T0.034482758620689655yb!! T0.034482758620689655yaに T0.034482758620689655yb参加 T0.034482758620689655yaし T0.034482758620689655ybまし T0.034482758620689655yaた T0.034482758620689655ya。 T0.034482758620689655yhherokujp T0.034482758620689655ya( T0.034482758620689655yeJugem T0.034482758620689655ybより T0.034482758620689655yb移植 T0.034482758620689655ya) T0.034482758620689655>vc288<yd第10回f0.0625ydSolrf0.0625yc勉強会f0.0625yaをf0.0625yb主催f0.0625yaしf0.0625ybましf0.0625yaたf0.0625ya。f0.0625ya#f0.0625yfSolrJPf0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc289<ymelasticsearchf0.0625ya-e0.125yhanalysisf0.0625yhkuromojif0.0625yaでf0.0625ycユーザf0.0625yb辞書f0.0625yaのf0.0625yb利用f0.0625yb方法f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc290<ya1 T0.021739130434782608yeエンジニア T0.043478260869565216yaの S0.06521739130434782ybため T0.021739130434782608yfスキルアップ T0.021739130434782608yc勉強会 T0.021739130434782608ya『 T0.021739130434782608ydTech T0.021739130434782608ya  S0.08695652173913043ygCompass T0.021739130434782608ya』 T0.021739130434782608ya＠ T0.021739130434782608yb竹橋 T0.021739130434782608ya― T0.021739130434782608ycVol T0.021739130434782608ya「 T0.021739130434782608ycスマホ T0.021739130434782608yd時代到来 T0.021739130434782608ya、 T0.021739130434782608ybこの T0.021739130434782608yb先生 T0.021739130434782608yaき T0.021739130434782608ybこる T0.021739130434782608yaと T0.021739130434782608yaは T0.021739130434782608ya！ T0.021739130434782608yb？」 T0.021739130434782608yaに T0.021739130434782608yb参加 T0.021739130434782608yaし T0.021739130434782608ybまし T0.021739130434782608yaた T0.021739130434782608ya。 T0.021739130434782608ya# T0.021739130434782608yftecomp T0.021739130434782608ya( T0.021739130434782608yeJugem T0.021739130434782608ybより T0.021739130434782608yb移植 T0.021739130434782608ya) T0.021739130434782608>vc291:yfXperiac0.1ya c0.1yaZc0.1yd買いましc0.1yaたc0.1ya(c0.1yeJugemc0.1ybよりc0.1yb移植c0.1ya)c0.1vc292<yd2013 T0.043478260869565216yfHadoop T0.043478260869565216ya  S0.17391304347826086yjConference T0.043478260869565216yeJapan T0.043478260869565216yfWinter T0.043478260869565216yaに T0.043478260869565216yb参加 T0.043478260869565216yaし T0.043478260869565216ybまし T0.043478260869565216yaた T0.043478260869565216ya。 T0.043478260869565216ya# T0.043478260869565216ychcj T0.043478260869565216yc13w T0.043478260869565216ya( T0.043478260869565216yeJugem T0.043478260869565216ybより T0.043478260869565216yb移植 T0.043478260869565216ya) T0.043478260869565216>vc293<yd2013d0.08yiエンジニアサポートd0.04yeCROSSd0.04ya d0.08yaにd0.04yb参加d0.04ya（d0.04ya＋d0.08yaおd0.04yb手伝d0.04yaいd0.04yeモデレータd0.04ya）d0.04ycしましd0.04yaたd0.04ya#d0.04yecrossd0.04ya(d0.04yeJugemd0.04ybよりd0.04yb移植d0.04ya)d0.04>vc294<yd2013 T0.045454545454545456ydいまさら T0.045454545454545456yaで S0.09090909090909091yaす T0.045454545454545456yaが T0.045454545454545456ya、 T0.045454545454545456yeCROSS S0.09090909090909091ya  T0.045454545454545456yb検索 T0.045454545454545456ycという T0.045454545454545456yeセッション T0.045454545454545456yaを T0.045454545454545456yb担当 T0.045454545454545456yaし T0.045454545454545456ybます T0.045454545454545456ya( T0.045454545454545456yeJugem T0.045454545454545456ybより T0.045454545454545456yb移植 T0.045454545454545456ya) T0.045454545454545456>vc295<ya「d0.04ykコード・シンプリシティd0.04ya」d0.04yaをd0.04yd読みましd0.04yaたd0.04ya。d0.04ya（d0.04yfKindled0.04ya d0.04yjpaperwhited0.04yaのd0.08yb使いd0.04yb勝手d0.04yb確認d0.04yaもd0.04yb兼ねd0.04yaてd0.04ya）d0.04ya(d0.04yeJugemd0.04ybよりd0.04yb移植d0.04ya)d0.04>vc296<yd2012f0.0625yb今年f0.0625yaのe0.125yb振りf0.0625yb返りf0.0625yaとf0.0625yb来年f0.0625yb抱負f0.0625ya（f0.0625ya）f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc297<ydJIRA T0.058823529411764705yaの T0.058823529411764705ybDB T0.058823529411764705yb移行 T0.058823529411764705ya（ T0.058823529411764705yfHSQLDB T0.058823529411764705ybから T0.058823529411764705yjPostgreSQL T0.058823529411764705yaへ T0.058823529411764705ya） T0.058823529411764705ya# T0.058823529411764705ydaugj T0.058823529411764705ya( T0.058823529411764705yeJugem T0.058823529411764705ybより T0.058823529411764705yb移植 T0.058823529411764705ya) T0.058823529411764705>vc298<yc第一回 S0.05263157894736842ya  S0.15789473684210525yiJetBrains S0.05263157894736842yhユーザーグループ S0.05263157894736842ya# S0.05263157894736842yejbugj S0.05263157894736842yaに S0.05263157894736842yb参加 S0.05263157894736842yaし S0.05263157894736842yaて S0.05263157894736842ycきまし S0.05263157894736842yaた S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc299<ya3d0.04ya5d0.04ya#d0.04ygDSIRNLPd0.04ya d0.04ya.d0.04yaにd0.04yb参加d0.04yaしd0.04ybましd0.04yaたd0.08ya。d0.04yb＆「d0.04yeEmacsd0.04yd実践入門d0.04ya」d0.04yaをd0.04yg頂いちゃいましd0.04ya！d0.04ya(d0.04yeJugemd0.04ybよりd0.04yb移植d0.04ya)d0.04>vc300<yc第9回f0.0625ydSolrf0.0625yc勉強会f0.0625yaをf0.0625yb主催f0.0625yaしf0.0625ybましf0.0625yaたf0.0625ya。f0.0625ya#f0.0625yfSolrJPf0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc301<ycAWS S0.05555555555555555ya  S0.05555555555555555yfビッグデータ S0.05555555555555555yd活用事例 S0.05555555555555555ydセミナー S0.05555555555555555yaに S0.05555555555555555yb参加 S0.05555555555555555yaし S0.05555555555555555ybまし S0.05555555555555555yaた S0.05555555555555555ya。 S0.05555555555555555ya# S0.05555555555555555yfjawsug S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc302<ya0 S0.08695652173913043ya4 S0.08695652173913043yfLucene T0.043478260869565216ya/ T0.043478260869565216ydSolr T0.043478260869565216ya  T0.043478260869565216ya. S0.13043478260869565ydリリース T0.043478260869565216ya＆ T0.043478260869565216yflucene T0.043478260869565216ya- T0.043478260869565216yegosen T0.043478260869565216yaの T0.043478260869565216yc0対応 T0.043478260869565216ya( T0.043478260869565216yeJugem T0.043478260869565216ybより T0.043478260869565216yb移植 T0.043478260869565216ya) T0.043478260869565216>vc303<yeLucid S0.05555555555555555yaの R0.1111111111111111yeGrant S0.05555555555555555ya  S0.05555555555555555yiIngersoll S0.05555555555555555ybさん S0.05555555555555555yb講演 S0.05555555555555555yaを S0.05555555555555555yb聞い S0.05555555555555555yaて S0.05555555555555555ycきまし S0.05555555555555555yaた S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc304<yd2012 S0.10526315789473684ycPFI S0.05263157894736842yhオープンセミナー S0.05263157894736842yaに S0.05263157894736842yb参加 S0.05263157894736842yaし S0.05263157894736842yaて S0.05263157894736842ycきまし S0.05263157894736842yaた S0.05263157894736842ya。 S0.05263157894736842ya  S0.05263157894736842ya# S0.05263157894736842ygpfiopen S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc305<ycメイン T0.058823529411764705ycMBA T0.058823529411764705yaを T0.058823529411764705yhMountain T0.058823529411764705ya  T0.058823529411764705ydLion T0.058823529411764705yaに T0.058823529411764705yfアップデート T0.058823529411764705ya（ T0.058823529411764705ydいろいろ T0.058823529411764705yc確認中 T0.058823529411764705ya） T0.058823529411764705ya( T0.058823529411764705yeJugem T0.058823529411764705ybより T0.058823529411764705yb移植 T0.058823529411764705ya) T0.058823529411764705>vc306<ya2d0.04ygFluentdd0.04ya d0.24yfmeetupd0.04ybind0.04yeJapand0.04ya#d0.08ygfluentdd0.04yaにd0.04yb参加d0.04yaしd0.04ybましd0.04yaたd0.04ya。d0.04ya(d0.04yeJugemd0.04ybよりd0.04yb移植d0.04ya)d0.04>vc307<ygTwitterd0.05ya d0.15yc勉強会d0.05ya#d0.05ydtwtrd0.05ya_d0.05ydhackd0.05yaにd0.05yb参加d0.05yaしd0.05ybましd0.05yaたd0.05ya。d0.05ya(d0.05yeJugemd0.05ybよりd0.05yb移植d0.05ya)d0.05>vc308<yd2012d0.04yfPythond0.04ya d0.16yjDevelopersd0.04yeFestad0.04ya.d0.04yb07d0.04yaにd0.04yb参加d0.04yaしd0.04yaてd0.08ydしゃべっd0.04ycきましd0.04yaたd0.04ya#d0.04yepyfesd0.04ya(d0.04yeJugemd0.04ybよりd0.04yb移植d0.04ya)d0.04>vc309<ya0d0.05ya4d0.05ygPartiald0.05ya d0.15yfUpdated0.05yaとd0.05yicopyFieldd0.05yaのd0.05ybバグd0.05ya【d0.05ydSolrd0.05ya.d0.05yeALPHAd0.05yb】(d0.05yeJugemd0.05ybよりd0.05yb移植d0.05ya)d0.05>vc3109ycMIR R0.1111111111111111ye輪読会始め R0.1111111111111111ybまし R0.1111111111111111yaた R0.1111111111111111ya( R0.1111111111111111yeJugem R0.1111111111111111ybより R0.1111111111111111yb移植 R0.1111111111111111ya) R0.1111111111111111vc311<ya0 S0.05555555555555555ya4 S0.05555555555555555yflucene S0.05555555555555555ya- R0.1111111111111111yegosen S0.05555555555555555yaの S0.05555555555555555yfLucene S0.05555555555555555ya/ S0.05555555555555555ydSolr S0.05555555555555555ya. S0.05555555555555555yeALPHA S0.05555555555555555yb対応 S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc312<ydSolr T0.058823529411764705yd勉強会第 T0.058823529411764705yb8回 T0.058823529411764705yaに T0.058823529411764705yb参加 T0.058823529411764705yaし T0.058823529411764705ybまし T0.058823529411764705yaた T0.058823529411764705ya。 T0.058823529411764705ya  T0.058823529411764705ya# T0.058823529411764705yfSolrJP T0.058823529411764705ya( T0.058823529411764705yeJugem T0.058823529411764705ybより T0.058823529411764705yb移植 T0.058823529411764705ya) T0.058823529411764705>vc313<yfHadoop T0.058823529411764705ylソースコードリーディング T0.058823529411764705ya第 T0.058823529411764705yc10回 T0.058823529411764705yaに T0.058823529411764705yb参加 T0.058823529411764705yaし T0.058823529411764705ybまし T0.058823529411764705yaた T0.058823529411764705ya。 T0.058823529411764705ya# T0.058823529411764705ymhadoopreading T0.058823529411764705ya( T0.058823529411764705yeJugem T0.058823529411764705ybより T0.058823529411764705yb移植 T0.058823529411764705ya) T0.058823529411764705>vc314;yflucene S0.09090909090909091ya- S0.09090909090909091yegosen S0.09090909090909091yaの S0.09090909090909091yfUniDic S0.09090909090909091yb対応 S0.09090909090909091ya( S0.09090909090909091yeJugem S0.09090909090909091ybより S0.09090909090909091yb移植 S0.09090909090909091ya) S0.09090909090909091vc315<yfZipkinf0.0625yaのf0.0625yfReadmef0.0625yb読んf0.0625ybでるf0.0625ya（f0.0625ybそのf0.0625ya２f0.0625ya、f0.0625yb残りf0.0625ya）f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc316<yfZipkinf0.0625yaのf0.0625yfReadmef0.0625yaをf0.0625yb読んf0.0625ybでるf0.0625ya（f0.0625yfクライアントf0.0625yb周りf0.0625ydについてf0.0625ya）f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc317:y YautoGeneratePhraseQueriesc0.1yaのc0.1yeデフォルトc0.1ya値c0.1ydについてc0.1ya(c0.1yeJugemc0.1ybよりc0.1yb移植c0.1ya)c0.1vc318<ygTwitter S0.05263157894736842yaが S0.05263157894736842yb公開 S0.05263157894736842yaし S0.05263157894736842yaた S0.05263157894736842yb分散 S0.05263157894736842yfトレーシング S0.05263157894736842ya（ S0.05263157894736842yb追跡 S0.05263157894736842ya？ S0.05263157894736842ya） S0.05263157894736842ydシステム S0.05263157894736842ya、 S0.05263157894736842yfZipkin S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc319<ya0 T0.045454545454545456ya2 S0.09090909090909091yflucene T0.045454545454545456ya- T0.045454545454545456yegosen T0.045454545454545456ya  T0.045454545454545456ya. S0.09090909090909091ydリリース T0.045454545454545456ya（ T0.045454545454545456ydリソース T0.045454545454545456yb周り T0.045454545454545456yaの T0.045454545454545456yb改善 T0.045454545454545456ybなど T0.045454545454545456ya） T0.045454545454545456ya( T0.045454545454545456yeJugem T0.045454545454545456ybより T0.045454545454545456yb移植 T0.045454545454545456ya) T0.045454545454545456>vc320<yb32 S0.07692307692307693yd4096 S0.07692307692307693yeIssue S0.07692307692307693ydについて S0.07692307692307693ya（ S0.07692307692307693yaの S0.07692307692307693ya壁 S0.07692307692307693ya） S0.07692307692307693ya( S0.07692307692307693yeJugem S0.07692307692307693ybより S0.07692307692307693yb移植 S0.07692307692307693ya) S0.07692307692307693>vc321<ya0 T0.038461538461538464ya3 T0.038461538461538464ya6 T0.038461538461538464yetrunk T0.038461538461538464yaの S0.07692307692307693yeライブラリ T0.038461538461538464ya差 T0.038461538461538464yaし T0.038461538461538464yb替え T0.038461538461538464ya（ T0.038461538461538464yfLucene T0.038461538461538464ya/ T0.038461538461538464ydSolr T0.038461538461538464ya. S0.07692307692307693ya） T0.038461538461538464yaと T0.038461538461538464ygランダムテスト T0.038461538461538464yb失敗 T0.038461538461538464ydについて T0.038461538461538464ya( T0.038461538461538464yeJugem T0.038461538461538464ybより T0.038461538461538464yb移植 T0.038461538461538464ya) T0.038461538461538464>vc322:ygオープンソース S0.09090909090909091yaへ S0.09090909090909091yaの S0.18181818181818182yb貢献 S0.09090909090909091ycススメ S0.09090909090909091ya( S0.09090909090909091yeJugem S0.09090909090909091ybより S0.09090909090909091yb移植 S0.09090909090909091ya) S0.09090909090909091vc323<yd2012 S0.05263157894736842ydJJUG S0.05263157894736842ya  S0.15789473684210525ycCCC S0.05263157894736842yfSpring S0.05263157894736842yaに S0.05263157894736842yb参加 S0.05263157894736842yaし S0.05263157894736842yaて S0.05263157894736842ycきまし S0.05263157894736842yaた S0.05263157894736842ya。 S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc324<ya0d0.05ya2d0.05ymPlayFrameworkd0.05ya d0.05ya.d0.05ya(c0.1ydJavad0.05yaのd0.05ya方d0.05ya)c0.1yaをd0.05yb触っd0.05yaてd0.05yaみd0.05ybてるd0.05yeJugemd0.05ybよりd0.05yb移植d0.05>vc325<ya0 S0.05263157894736842ya1 S0.05263157894736842ya2 S0.05263157894736842yflucene S0.05263157894736842ya- S0.05263157894736842yegosen S0.05263157894736842ya  S0.05263157894736842ya. S0.10526315789473684ydリリース S0.05263157894736842ya（ S0.05263157894736842ydJava S0.05263157894736842yc7対応 S0.05263157894736842ya） S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc326<ya「 S0.07142857142857142ybID S0.07142857142857142yaの S0.07142857142857142yb秘密 S0.07142857142857142ya」 S0.07142857142857142yaを S0.07142857142857142yd読みまし S0.07142857142857142yaた S0.07142857142857142ya。 S0.07142857142857142ya( S0.07142857142857142yeJugem S0.07142857142857142ybより S0.07142857142857142yb移植 S0.07142857142857142ya) S0.07142857142857142>vc327<ya4 T0.047619047619047616yfHeroku T0.047619047619047616ya  S0.14285714285714285ybJP T0.047619047619047616yfMeetup T0.047619047619047616ya＃ T0.047619047619047616yaに T0.047619047619047616yb参加 T0.047619047619047616yaし T0.047619047619047616ybまし T0.047619047619047616yaた T0.047619047619047616ya。 T0.047619047619047616ya# T0.047619047619047616yhherokujp T0.047619047619047616ya( T0.047619047619047616yeJugem T0.047619047619047616ybより T0.047619047619047616yb移植 T0.047619047619047616ya) T0.047619047619047616>vc328<ya0 T0.043478260869565216ya3 T0.043478260869565216ya6 T0.043478260869565216ydSolr T0.043478260869565216ya  T0.043478260869565216ya. S0.08695652173913043yaの S0.13043478260869565ycCJK T0.043478260869565216yb設定 T0.043478260869565216yaと T0.043478260869565216y TSynonymFilterFactory T0.043478260869565216ya気 T0.043478260869565216yaに T0.043478260869565216ybなる T0.043478260869565216ya点 T0.043478260869565216ya( T0.043478260869565216yeJugem T0.043478260869565216ybより T0.043478260869565216yb移植 T0.043478260869565216ya) T0.043478260869565216>vc329<ya「d0.04yfApached0.04ya d0.04ydSolrd0.04yb入門d0.04ya」d0.04yaのd0.08ydサンプルd0.04yhKuromojid0.04yaとd0.04yflucened0.04ya-d0.04yegosend0.04yb対応d0.04ya（d0.04yb2章d0.04ya～d0.04yb4章d0.04ya）d0.04ya(d0.04yeJugemd0.04ybよりd0.04yb移植d0.04ya)d0.04>vc330<ya0 T0.027777777777777776ya3 T0.027777777777777776ya6 T0.027777777777777776yfLucene T0.027777777777777776ya/ S0.05555555555555555ydSolr S0.05555555555555555ya  R0.1111111111111111ya. S0.05555555555555555ydリリース T0.027777777777777776ya「 T0.027777777777777776yfApache T0.027777777777777776yb入門 T0.027777777777777776ya」 T0.027777777777777776yaの S0.05555555555555555ydサンプル T0.027777777777777776yhKuromoji T0.027777777777777776yaと T0.027777777777777776yflucene T0.027777777777777776ya- T0.027777777777777776yegosen T0.027777777777777776yb対応 T0.027777777777777776ya（ T0.027777777777777776yb1章 T0.027777777777777776ya） T0.027777777777777776ya( T0.027777777777777776yeJugem T0.027777777777777776ybより T0.027777777777777776yb移植 T0.027777777777777776ya) T0.027777777777777776>vc331<ya【 S0.06666666666666667ybメモ S0.06666666666666667ya】 S0.06666666666666667yfAmazon S0.06666666666666667ya  S0.06666666666666667ykCloudSearch S0.06666666666666667yaが S0.06666666666666667yb出て S0.06666666666666667ycきまし S0.06666666666666667ybたよ S0.06666666666666667ya( S0.06666666666666667yeJugem S0.06666666666666667ybより S0.06666666666666667yb移植 S0.06666666666666667ya) S0.06666666666666667>vc332<yd2012 T0.047619047619047616ydJava T0.047619047619047616ya  S0.19047619047619047ycOne T0.047619047619047616yeTokyo T0.047619047619047616yaに T0.047619047619047616yb参加 T0.047619047619047616yaし T0.047619047619047616ybまし T0.047619047619047616yaた T0.047619047619047616ya。 T0.047619047619047616ya# T0.047619047619047616yiJavaOneJp T0.047619047619047616ya( T0.047619047619047616yeJugem T0.047619047619047616ybより T0.047619047619047616yb移植 T0.047619047619047616ya) T0.047619047619047616>vc333<ya7 S0.05555555555555555yflucene S0.05555555555555555ya- S0.05555555555555555yegosen S0.05555555555555555yaの S0.16666666666666666ydJava S0.05555555555555555yaで S0.05555555555555555ycテスト S0.05555555555555555yb失敗 S0.05555555555555555yb問題 S0.05555555555555555yb対応 S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc334<ya0 R0.1111111111111111ya2 S0.05555555555555555ya【 S0.05555555555555555yb重要 S0.05555555555555555ya】 S0.05555555555555555yflucene S0.05555555555555555ya- S0.05555555555555555yegosen S0.05555555555555555ya  S0.05555555555555555ya. R0.1111111111111111ydリリース S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc335<ya【 S0.06666666666666667yb重要 S0.06666666666666667ya】 S0.06666666666666667yflucene S0.06666666666666667ya- S0.06666666666666667yegosen S0.06666666666666667yaの S0.06666666666666667yb次期 S0.06666666666666667ydリリース S0.06666666666666667ydについて S0.06666666666666667ya( S0.06666666666666667yeJugem S0.06666666666666667ybより S0.06666666666666667yb移植 S0.06666666666666667ya) S0.06666666666666667>vc336<yb久々 S0.07142857142857142yaに S0.07142857142857142ycMac S0.07142857142857142ya  S0.07142857142857142ydMini S0.07142857142857142yaの S0.07142857142857142ybこと S0.07142857142857142yaで S0.07142857142857142yaも S0.07142857142857142ya( S0.07142857142857142yeJugem S0.07142857142857142ybより S0.07142857142857142yb移植 S0.07142857142857142ya) S0.07142857142857142>vc337<yc第5回 S0.05263157894736842ya  S0.21052631578947367ygTwitter S0.05263157894736842ycAPI S0.05263157894736842yc勉強会 S0.05263157894736842ya@ S0.05263157894736842yb渋谷 S0.05263157894736842ya# S0.05263157894736842ydtwtr S0.05263157894736842ya_ S0.05263157894736842ydhack S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc338<ya「 S0.09090909090909091yb自分 T0.045454545454545456yaの T0.045454545454545456yb小さ T0.045454545454545456yaな T0.045454545454545456ya箱 T0.045454545454545456ya」 S0.09090909090909091ybから T0.045454545454545456yb脱出 T0.045454545454545456ybする T0.045454545454545456yb方法 T0.045454545454545456yaを T0.045454545454545456yd読みまし T0.045454545454545456yaた T0.045454545454545456ya。 T0.045454545454545456ya( T0.045454545454545456yeJugem T0.045454545454545456ybより T0.045454545454545456yb移植 T0.045454545454545456ya) T0.045454545454545456>vc3398yeScalae0.125yd始めましe0.125yaたe0.125ya(e0.125yeJugeme0.125ybよりe0.125yb移植e0.125ya)e0.125vc340<yc第0回 T0.045454545454545456ya  S0.18181818181818182ygTwitter T0.045454545454545456ydHack T0.045454545454545456ya# T0.045454545454545456ydtwtr T0.045454545454545456ya_ T0.045454545454545456ydhack T0.045454545454545456yaに S0.09090909090909091yb遊び T0.045454545454545456yd行きまし T0.045454545454545456yaた T0.045454545454545456ya。 T0.045454545454545456ya( T0.045454545454545456yeJugem T0.045454545454545456ybより T0.045454545454545456yb移植 T0.045454545454545456ya) T0.045454545454545456>vc341;yeClean S0.09090909090909091ya  S0.09090909090909091yeCoder S0.09090909090909091yaを S0.09090909090909091yb読ん S0.09090909090909091yaだ S0.09090909090909091ya( S0.09090909090909091yeJugem S0.09090909090909091ybより S0.09090909090909091yb移植 S0.09090909090909091ya) S0.09090909090909091vc342<yb親子f0.0625yaでe0.125yd楽しめるf0.0625ya f0.0625yb絵本f0.0625yb英語f0.0625yaをf0.0625yaはf0.0625ycじめるf0.0625ya本f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc343<yc第4回 T0.038461538461538464ya  S0.19230769230769232ygTwitter T0.038461538461538464ycAPI T0.038461538461538464yc勉強会 T0.038461538461538464ya@ T0.038461538461538464yiデジタルハリウッド T0.038461538461538464ya# T0.038461538461538464ydtwtr T0.038461538461538464ya_ T0.038461538461538464ydhack T0.038461538461538464yaに T0.038461538461538464yb参加 T0.038461538461538464yaし T0.038461538461538464ybまし T0.038461538461538464yaた T0.038461538461538464ya。 T0.038461538461538464ya( T0.038461538461538464yeJugem T0.038461538461538464ybより T0.038461538461538464yb移植 T0.038461538461538464ya) T0.038461538461538464>vc344<yflucene S0.05263157894736842ya- S0.05263157894736842yegosen S0.05263157894736842yaと S0.05263157894736842ymSynonymFilter S0.05263157894736842yaを S0.05263157894736842yb利用 S0.05263157894736842ybする S0.05263157894736842ybとき S0.05263157894736842yaの S0.05263157894736842yc注意点 S0.05263157894736842ya（ S0.05263157894736842yd問題点編 S0.05263157894736842ya） S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc345<yfHadoop T0.058823529411764705ylソースコードリーディング T0.058823529411764705ya第 T0.058823529411764705yb8回 T0.058823529411764705yaに T0.058823529411764705yb参加 T0.058823529411764705yaし T0.058823529411764705ybまし T0.058823529411764705yaた T0.058823529411764705ya。 T0.058823529411764705ya# T0.058823529411764705ymhadoopreading T0.058823529411764705ya( T0.058823529411764705yeJugem T0.058823529411764705ybより T0.058823529411764705yb移植 T0.058823529411764705ya) T0.058823529411764705>vc346<ygFluentdf0.0625ya e0.125yfMeetupf0.0625yeJapanf0.0625yaにf0.0625yb参加f0.0625yaしf0.0625ybましf0.0625yaたf0.0625ya。f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc3479yc今興味 R0.1111111111111111yaが R0.1111111111111111ybある R0.1111111111111111ybこと R0.1111111111111111ya( R0.1111111111111111yeJugem R0.1111111111111111ybより R0.1111111111111111yb移植 R0.1111111111111111ya) R0.1111111111111111vc348<ya1 S0.06666666666666667yd2012 S0.06666666666666667yhモーショノロジー S0.06666666666666667ya# S0.06666666666666667yaに S0.06666666666666667yb参加 S0.06666666666666667yaし S0.06666666666666667ybまし S0.06666666666666667yaた S0.06666666666666667ya。 S0.06666666666666667ya( S0.06666666666666667yeJugem S0.06666666666666667ybより S0.06666666666666667yb移植 S0.06666666666666667ya) S0.06666666666666667>vc349<ydMapR S0.07692307692307693ye中身説明会 S0.07692307692307693yaに S0.07692307692307693yb参加 S0.07692307692307693yaし S0.07692307692307693ybまし S0.07692307692307693yaた S0.07692307692307693ya。 S0.07692307692307693ya( S0.07692307692307693yeJugem S0.07692307692307693ybより S0.07692307692307693yb移植 S0.07692307692307693ya) S0.07692307692307693>vc350<yeOSSAJ S0.07142857142857142yaの S0.07142857142857142yfミニセミナー S0.07142857142857142yaで S0.07142857142857142yb話し S0.07142857142857142yaを S0.07142857142857142ybして S0.07142857142857142ycきまし S0.07142857142857142yaた S0.07142857142857142ya( S0.07142857142857142yeJugem S0.07142857142857142ybより S0.07142857142857142yb移植 S0.07142857142857142ya) S0.07142857142857142>vc351<ya4 T0.058823529411764705yflucene T0.058823529411764705ya- T0.058823529411764705yegosen T0.058823529411764705yaの T0.058823529411764705yfLucene T0.058823529411764705ya/ T0.058823529411764705ydSolr T0.058823529411764705ya. T0.058823529411764705yc0対応 T0.058823529411764705ydブランチ T0.058823529411764705yb更新 T0.058823529411764705ya( T0.058823529411764705yeJugem T0.058823529411764705ybより T0.058823529411764705yb移植 T0.058823529411764705ya) T0.058823529411764705>vc352<ydあけまし S0.06666666666666667yaて S0.06666666666666667ybおめ S0.06666666666666667yaで S0.06666666666666667ygとうございます S0.06666666666666667ya＋ S0.06666666666666667yb会社 S0.06666666666666667yaの S0.06666666666666667ycブログ S0.06666666666666667yb更新 S0.06666666666666667ya( S0.06666666666666667yeJugem S0.06666666666666667ybより S0.06666666666666667yb移植 S0.06666666666666667ya) S0.06666666666666667>vc353<yb今年 S0.07142857142857142yaの S0.14285714285714285yb振り S0.07142857142857142yb返り S0.07142857142857142yaと S0.07142857142857142yb来年 S0.07142857142857142yb抱負 S0.07142857142857142ya？ S0.07142857142857142ya( S0.07142857142857142yeJugem S0.07142857142857142ybより S0.07142857142857142yb移植 S0.07142857142857142ya) S0.07142857142857142>vc354<yb第2 T0.043478260869565216ya. T0.043478260869565216yb1回 T0.043478260869565216ya  S0.17391304347826086ygTwitter T0.043478260869565216ycAPI T0.043478260869565216yc勉強会 T0.043478260869565216ya@ T0.043478260869565216yb東京 T0.043478260869565216yaに T0.043478260869565216yb参加 T0.043478260869565216yaし T0.043478260869565216ybまし T0.043478260869565216yaた T0.043478260869565216ya。 T0.043478260869565216ya( T0.043478260869565216yeJugem T0.043478260869565216ybより T0.043478260869565216yb移植 T0.043478260869565216ya) T0.043478260869565216>vc355;ya1 S0.15384615384615385ya2 S0.07692307692307693ya. S0.15384615384615385ydリリース S0.07692307692307693ycしまし S0.07692307692307693yaた S0.07692307692307693ya( S0.07692307692307693yeJugem S0.07692307692307693ybより S0.07692307692307693yb移植 S0.07692307692307693ya) S0.07692307692307693vc356<ydSolrd0.05yd勉強会第d0.05yb７回d0.05yaにd0.05yb参加d0.05yaしd0.05ybましd0.05yaたc0.1ya。d0.05ya（d0.05yb発表d0.05yaもd0.05ycしましd0.05ya）d0.05ya(d0.05yeJugemd0.05ybよりd0.05yb移植d0.05ya)d0.05>vc357<yc第2回 S0.05263157894736842ya  S0.05263157894736842ycデータ S0.05263157894736842yb構造 S0.05263157894736842yaと S0.10526315789473684yb情報 S0.05263157894736842yb検索 S0.05263157894736842yg言語処理勉強会 S0.05263157894736842yaに S0.05263157894736842yb参加 S0.05263157894736842yaし S0.05263157894736842ybまし S0.05263157894736842yaた S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc358<ycMBA T0.041666666666666664yfセットアップ S0.08333333333333333yc備忘録 T0.041666666666666664ybその S0.08333333333333333ya５ T0.041666666666666664yaと S0.08333333333333333ycMac T0.041666666666666664ya  T0.041666666666666664ydMini T0.041666666666666664ya（ T0.041666666666666664yh2009late T0.041666666666666664ya） T0.041666666666666664yb他く T0.041666666666666664ybだら T0.041666666666666664ybない T0.041666666666666664ya話 T0.041666666666666664ya( T0.041666666666666664yeJugem T0.041666666666666664ybより T0.041666666666666664yb移植 T0.041666666666666664ya) T0.041666666666666664>vc359<ya「 S0.08695652173913043ybどん T0.043478260869565216yaな T0.043478260869565216ya本 S0.08695652173913043yaで T0.043478260869565216yaも T0.043478260869565216yb大量 T0.043478260869565216yaに T0.043478260869565216yc読める T0.043478260869565216yb速読 T0.043478260869565216ya」 S0.08695652173913043yaの T0.043478260869565216yaを T0.043478260869565216yd読みまし T0.043478260869565216yaた T0.043478260869565216ya( T0.043478260869565216yeJugem T0.043478260869565216ybより T0.043478260869565216yb移植 T0.043478260869565216ya) T0.043478260869565216>vc360<yfHadoop S0.06666666666666667ylソースコードリーディング S0.06666666666666667ya第 S0.06666666666666667yb7回 S0.06666666666666667yaに S0.06666666666666667yb参加 S0.06666666666666667yaし S0.06666666666666667ybまし S0.06666666666666667yaた S0.06666666666666667ya。 S0.06666666666666667ya( S0.06666666666666667yeJugem S0.06666666666666667ybより S0.06666666666666667yb移植 S0.06666666666666667ya) S0.06666666666666667>vc361<ya「 T0.043478260869565216yfApache T0.043478260869565216ya  T0.043478260869565216ydSolr T0.043478260869565216yb入門 T0.043478260869565216ya」 T0.043478260869565216yaの S0.08695652173913043ydサンプル T0.043478260869565216yflucene T0.043478260869565216ya- T0.043478260869565216yegosen T0.043478260869565216yb対応 T0.043478260869565216ya（ T0.043478260869565216yb1章 T0.043478260869565216ybから T0.043478260869565216yb4章 T0.043478260869565216ya） T0.043478260869565216ya( T0.043478260869565216yeJugem T0.043478260869565216ybより T0.043478260869565216yb移植 T0.043478260869565216ya) T0.043478260869565216>vc362<ygMongoDB T0.058823529411764705yc勉強会 T0.058823529411764705ya（ T0.058823529411764705ya第 T0.058823529411764705yb7回 T0.058823529411764705ya） T0.058823529411764705yaに T0.058823529411764705yb行っ T0.058823529411764705yaて T0.058823529411764705yc来まし T0.058823529411764705yaた T0.058823529411764705ya。 T0.058823529411764705ya( T0.058823529411764705yeJugem T0.058823529411764705ybより T0.058823529411764705yb移植 T0.058823529411764705ya) T0.058823529411764705>vc363<yfSplunk T0.058823529411764705ya  T0.058823529411764705ydLive T0.058823529411764705ya! T0.058823529411764705yaの T0.058823529411764705ydイベント T0.058823529411764705yaに T0.058823529411764705yb行っ T0.058823529411764705yaて T0.058823529411764705yc来まし T0.058823529411764705yaた T0.058823529411764705ya。 T0.058823529411764705ya( T0.058823529411764705yeJugem T0.058823529411764705ybより T0.058823529411764705yb移植 T0.058823529411764705ya) T0.058823529411764705>vc364<yd2011 S0.05555555555555555yfLucene S0.05555555555555555ya  R0.2222222222222222ygEurocon S0.05555555555555555yiBarcelona S0.05555555555555555yaの S0.05555555555555555ydスライド S0.05555555555555555yb読み S0.05555555555555555ybまし S0.05555555555555555yaた S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc365;yhBookscan S0.09090909090909091yaを S0.09090909090909091yb使っ S0.09090909090909091yaて S0.09090909090909091ycみまし S0.09090909090909091yaた S0.09090909090909091ya( S0.09090909090909091yeJugem S0.09090909090909091ybより S0.09090909090909091yb移植 S0.09090909090909091ya) S0.09090909090909091vc366:ya0 S0.09090909090909091ya1 S0.09090909090909091ya2 S0.09090909090909091ya. S0.18181818181818182ydリリース S0.09090909090909091ya( S0.09090909090909091yeJugem S0.09090909090909091ybより S0.09090909090909091yb移植 S0.09090909090909091ya) S0.09090909090909091vc367<ya3 S0.06666666666666667yb辞書 S0.06666666666666667yaの S0.06666666666666667yc外部化 S0.06666666666666667yaと S0.06666666666666667yfLucene S0.06666666666666667ya/ S0.06666666666666667ydSolr S0.06666666666666667ya. S0.06666666666666667yc4対応 S0.06666666666666667ya( S0.06666666666666667yeJugem S0.06666666666666667ybより S0.06666666666666667yb移植 S0.06666666666666667ya) S0.06666666666666667>vc368<yd2011 S0.05263157894736842ydJJUG S0.05263157894736842ya  S0.15789473684210525ycCCC S0.05263157894736842ydFall S0.05263157894736842yaに S0.05263157894736842yb参加 S0.05263157894736842yaし S0.05263157894736842yaて S0.05263157894736842ycきまし S0.05263157894736842yaた S0.05263157894736842ya。 S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc369<yflucene T0.058823529411764705ya- T0.058823529411764705yegosen T0.058823529411764705yaで T0.058823529411764705yb文章 T0.058823529411764705ybから T0.058823529411764705yeキーワード T0.058823529411764705yb抽出 T0.058823529411764705ya（ T0.058823529411764705yfイレギュラー T0.058823529411764705ya？ T0.058823529411764705ya） T0.058823529411764705ya( T0.058823529411764705yeJugem T0.058823529411764705ybより T0.058823529411764705yb移植 T0.058823529411764705ya) T0.058823529411764705>vc370<ya「 S0.05555555555555555yb7つ R0.1111111111111111yaの R0.1111111111111111yb言語 S0.05555555555555555ya　 S0.05555555555555555yb世界 S0.05555555555555555ya」 S0.05555555555555555ya  R0.1111111111111111ybIo S0.05555555555555555yc1日目 S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc371:ycMBAc0.1yfセットアップc0.1yc備忘録c0.1ybそのc0.1ya４c0.1ya(c0.1yeJugemc0.1ybよりc0.1yb移植c0.1ya)c0.1vc372<ya4 S0.05555555555555555ydSolr R0.1111111111111111yaの S0.05555555555555555yc新しい S0.05555555555555555yd管理画面 S0.05555555555555555ya（ S0.05555555555555555ya. S0.05555555555555555yax S0.05555555555555555ya  S0.05555555555555555yetrunk S0.05555555555555555ya系 S0.05555555555555555ya） S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc373<ya2f0.0625ycNewf0.0625ya e0.125yiSolrCloudf0.0625yfDesignf0.0625yaのf0.0625yb翻訳f0.0625ya（f0.0625ybそのf0.0625ya）f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc374<ycNewf0.0625ya e0.125yiSolrCloudf0.0625yfDesignf0.0625yaのf0.0625yb翻訳f0.0625ya（f0.0625ybそのf0.0625ya１f0.0625ya）f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc375<yd2011 T0.047619047619047616yfHadoop T0.047619047619047616ya  S0.19047619047619047yjConference T0.047619047619047616yeJapan T0.047619047619047616ydFall T0.047619047619047616yaに T0.047619047619047616yb参加 T0.047619047619047616yaし T0.047619047619047616yaて T0.047619047619047616ycきまし T0.047619047619047616yaた T0.047619047619047616ya。 T0.047619047619047616ya( T0.047619047619047616yeJugem T0.047619047619047616ybより T0.047619047619047616yb移植 T0.047619047619047616ya) T0.047619047619047616>vc376<ya「 S0.05555555555555555yb7つ R0.1111111111111111yaの R0.1111111111111111yb言語 S0.05555555555555555ya　 S0.05555555555555555yb世界 S0.05555555555555555ya」 S0.05555555555555555ya  R0.1111111111111111ybIo S0.05555555555555555yc0日目 S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc377<ya3f0.0625ya4f0.0625yfLucenef0.0625ya/f0.0625ydSolrf0.0625ya f0.0625ya.f0.0625ydリリースf0.0625ya（f0.0625yb速報f0.0625ya）f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc378<ya「 T0.047619047619047616yb7つ S0.09523809523809523yaの S0.09523809523809523yb言語 T0.047619047619047616ya　 T0.047619047619047616yb世界 T0.047619047619047616ya」 T0.047619047619047616ya  S0.09523809523809523ydRuby T0.047619047619047616yc3日目 T0.047619047619047616ya（ T0.047619047619047616yc最終日 T0.047619047619047616ya） T0.047619047619047616ya( T0.047619047619047616yeJugem T0.047619047619047616ybより T0.047619047619047616yb移植 T0.047619047619047616ya) T0.047619047619047616>vc379<yc第6回 S0.07142857142857142ydSolr S0.07142857142857142yc勉強会 S0.07142857142857142yaに S0.07142857142857142yb参加 S0.07142857142857142yaし S0.07142857142857142ybまし S0.07142857142857142yaた S0.07142857142857142ya。 S0.07142857142857142ya( S0.07142857142857142yeJugem S0.07142857142857142ybより S0.07142857142857142yb移植 S0.07142857142857142ya) S0.07142857142857142>vc380<ya「 S0.05555555555555555yb7つ R0.1111111111111111yaの R0.1111111111111111yb言語 S0.05555555555555555ya　 S0.05555555555555555yb世界 S0.05555555555555555ya」 S0.05555555555555555ya  R0.1111111111111111ydRuby S0.05555555555555555yc2日目 S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc381<ya「 S0.05555555555555555yb7つ R0.1111111111111111yaの R0.1111111111111111yb言語 S0.05555555555555555ya　 S0.05555555555555555yb世界 S0.05555555555555555ya」 S0.05555555555555555ya  R0.1111111111111111ydRuby S0.05555555555555555yc1日目 S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc382:ycMBAc0.1yfセットアップc0.1yc備忘録c0.1ybそのc0.1ya３c0.1ya(c0.1yeJugemc0.1ybよりc0.1yb移植c0.1ya)c0.1vc383;yd辞書分離 S0.09090909090909091yaの S0.09090909090909091yfテストケース S0.09090909090909091yb追加 S0.09090909090909091yaと S0.09090909090909091yd残タスク S0.09090909090909091ya( S0.09090909090909091yeJugem S0.09090909090909091ybより S0.09090909090909091yb移植 S0.09090909090909091ya) S0.09090909090909091vc384<yd複数辞書 S0.07142857142857142yaの S0.07142857142857142yb読み S0.07142857142857142yb込み S0.07142857142857142yb機能 S0.07142857142857142yb追加 S0.07142857142857142ya（ S0.07142857142857142ya仮 S0.07142857142857142ya） S0.07142857142857142ya( S0.07142857142857142yeJugem S0.07142857142857142ybより S0.07142857142857142yb移植 S0.07142857142857142ya) S0.07142857142857142>vc385;yb辞書 S0.08333333333333333yaの S0.16666666666666666ycjar S0.08333333333333333ydファイル S0.08333333333333333ybから S0.08333333333333333yb分離 S0.08333333333333333ya( S0.08333333333333333yeJugem S0.08333333333333333ybより S0.08333333333333333yb移植 S0.08333333333333333ya) S0.08333333333333333vc386:ycMBAc0.1yfセットアップc0.1yc備忘録c0.1ybそのc0.1ya２c0.1ya(c0.1yeJugemc0.1ybよりc0.1yb移植c0.1ya)c0.1vc3878ycMBAe0.125yfセットアップe0.125yc備忘録e0.125ya(e0.125yeJugeme0.125ybよりe0.125yb移植e0.125ya)e0.125vc388<yeApple S0.08333333333333333ya教 S0.08333333333333333yaに S0.08333333333333333yb入信 S0.08333333333333333yaし S0.08333333333333333ybまし S0.08333333333333333yaた S0.08333333333333333ya( S0.08333333333333333yeJugem S0.08333333333333333ybより S0.08333333333333333yb移植 S0.08333333333333333ya) S0.08333333333333333>vc389<yc第1回d0.05ya d0.05ycデータd0.05yb構造d0.05yaとc0.1yb情報d0.05yb検索d0.05yg言語処理勉強会d0.05yaにd0.05yb参加d0.05yaしd0.05ybましd0.05yaたd0.05ya。d0.05ya(d0.05yeJugemd0.05ybよりd0.05yb移植d0.05ya)d0.05>vc390;yhKuromoji S0.09090909090909091yaを S0.09090909090909091yb調べ S0.09090909090909091yaて S0.09090909090909091yaみ S0.09090909090909091yaた S0.09090909090909091ya( S0.09090909090909091yeJugem S0.09090909090909091ybより S0.09090909090909091yb移植 S0.09090909090909091ya) S0.09090909090909091vc391<yeNAIST S0.05263157894736842ya- S0.05263157894736842ydJDic S0.05263157894736842ya  S0.10526315789473684ycfor S0.05263157894736842yeMeCab S0.05263157894736842yaの S0.10526315789473684ylPreprocessor S0.05263157894736842yb実装 S0.05263157894736842yaに S0.05263157894736842yc関する S0.05263157894736842yc備忘録 S0.05263157894736842ya( S0.05263157894736842yeJugem S0.05263157894736842ybより S0.05263157894736842yb移植 S0.05263157894736842ya) S0.05263157894736842>vc392<ya1c0.2yflucene S0.06666666666666667ya- S0.06666666666666667yegosen S0.06666666666666667ya  S0.06666666666666667ya. S0.13333333333333333ydリリース S0.06666666666666667ya( S0.06666666666666667yeJugem S0.06666666666666667ybより S0.06666666666666667yb移植 S0.06666666666666667ya) S0.06666666666666667>vc393<ya3e0.125yfLucenef0.0625ya/f0.0625ydSolrf0.0625ya f0.0625ya.f0.0625ydリリースf0.0625ya（f0.0625yb速報f0.0625ya）f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc394<yfHadoop T0.030303030303030304yaを T0.030303030303030304yb中心 T0.030303030303030304yaと T0.030303030303030304yaし S0.06060606060606061yaた S0.06060606060606061yb分散 T0.030303030303030304yb環境 T0.030303030303030304yaで T0.030303030303030304yaの S0.06060606060606061ye開発方法論 T0.030303030303030304ya・ S0.06060606060606061yeモデリング T0.030303030303030304ye設計手法等 T0.030303030303030304ydについて T0.030303030303030304yc座談会 T0.030303030303030304ya( S0.06060606060606061ya第 T0.030303030303030304yb5回 T0.030303030303030304ya） T0.030303030303030304yaに T0.030303030303030304yb参加 T0.030303030303030304ybまし T0.030303030303030304ya。 T0.030303030303030304yeJugem T0.030303030303030304ybより T0.030303030303030304yb移植 T0.030303030303030304ya) T0.030303030303030304>vc395<ylcompositePOS S0.08333333333333333ya（ S0.08333333333333333y TCompositeTokenFilter S0.08333333333333333ya） S0.08333333333333333yaの S0.08333333333333333ybバグ S0.08333333333333333yb修正 S0.08333333333333333ya( S0.08333333333333333yeJugem S0.08333333333333333ybより S0.08333333333333333yb移植 S0.08333333333333333ya) S0.08333333333333333>vc396<yeNAISTf0.0625ya-f0.0625ydJDicf0.0625ya e0.125ycforf0.0625yeMeCabf0.0625yc対応版f0.0625ya（f0.0625yc仮実装f0.0625ya）f0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc397<ylcompositePOS S0.05555555555555555yaの S0.16666666666666666yc利用例 S0.05555555555555555ya（ S0.05555555555555555yenaist S0.05555555555555555ya- S0.05555555555555555yfchasen S0.05555555555555555yaで S0.05555555555555555yc英単語 S0.05555555555555555ye出力方法例 S0.05555555555555555ya） S0.05555555555555555ya( S0.05555555555555555yeJugem S0.05555555555555555ybより S0.05555555555555555yb移植 S0.05555555555555555ya) S0.05555555555555555>vc398<ya0f0.0625ya1e0.125yflucenef0.0625ya-f0.0625yegosenf0.0625ya e0.125ya.e0.125ydリリースf0.0625ya(f0.0625yeJugemf0.0625ybよりf0.0625yb移植f0.0625ya)f0.0625>vc399;yflucene S0.09090909090909091ya- S0.09090909090909091yegosen S0.09090909090909091yaの S0.09090909090909091ykTokenFilter S0.09090909090909091ybたち S0.09090909090909091ya( S0.09090909090909091yeJugem S0.09090909090909091ybより S0.09090909090909091yb移植 S0.09090909090909091ya) S0.09090909090909091vc4009yb辞書c0.2yaとc0.1ydカスタムc0.1ydについてc0.1ya(c0.1yeJugemc0.1ybよりc0.1yb移植c0.1ya)c0.1vc401;ycソース S0.09090909090909091ybから S0.09090909090909091yaの S0.09090909090909091ycビルド S0.09090909090909091yaと S0.09090909090909091yb構成 S0.09090909090909091ya( S0.09090909090909091yeJugem S0.09090909090909091ybより S0.09090909090909091yb移植 S0.09090909090909091ya) S0.09090909090909091vc402:yflucenec0.1ya-c0.1yegosenc0.1yaとc0.1yaはc0.1ya(c0.1yeJugemc0.1ybよりc0.1yb移植c0.1ya)c0.1vc4038ycブログe0.125yaはe0.125ydじめますe0.125ya(e0.125yeJugeme0.125ybよりe0.125yb移植e0.125ya)e0.125>vgsummary<va1<yb日常g0.03125yaでg0.03125ybよくg0.03125ya、g0.09375ye形態素解析g0.03125yaしg0.03125ybたくg0.03125ybなるg0.03125ybことf0.0625yaがg0.03125yfありますよねg0.03125ya？f0.0625ya f0.0625ycそしてg0.03125yeSlackf0.0625yaもg0.03125yc日常的g0.03125yaにg0.03125yb立ちg0.03125yd上がってg0.03125ydますよねg0.03125ycというg0.03125yaはg0.03125yaのg0.03125ycボットg0.03125ycとしてg0.03125>va2<yd2022 S0.02631578947368421yb今年 S0.02631578947368421yaも S0.02631578947368421yb振り S0.05263157894736842yb返り S0.05263157894736842ycブログ S0.02631578947368421yaを S0.02631578947368421ydリビング S0.02631578947368421yaで S0.07894736842105263yb書い S0.05263157894736842yaて S0.05263157894736842ycいます S0.02631578947368421ya（ S0.05263157894736842yeドミノ倒し S0.02631578947368421ycすごい S0.02631578947368421yaな S0.02631578947368421ya） S0.02631578947368421ya。 S0.10526315789473684ya  S0.05263157894736842ycFMV S0.02631578947368421yaの S0.05263157894736842yeキーボード S0.02631578947368421ybいる S0.02631578947368421ycタイポ S0.02631578947368421yaが S0.02631578947368421ycつらい S0.02631578947368421>va3<yd2023 T0.024390243902439025ybこの T0.024390243902439025yb記事 S0.04878048780487805yaは S0.04878048780487805ya、 S0.04878048780487805yd情報検索 T0.024390243902439025ya・ T0.024390243902439025yd検索技術 T0.024390243902439025ya  S0.14634146341463414yfAdvent S0.04878048780487805yhCalendar S0.04878048780487805yaの R0.0975609756097561yd15日目 T0.024390243902439025yaで S0.04878048780487805yaす S0.04878048780487805ya。 S0.04878048780487805yb昨年 T0.024390243902439025yaに T0.024390243902439025yb続き T0.024390243902439025yc2回目 T0.024390243902439025yb情報 T0.024390243902439025yb検索 T0.024390243902439025yb参戦 T0.024390243902439025yb今年 T0.024390243902439025ya夏 T0.024390243902439025>va4<yb12 T0.027777777777777776yePySpa T0.027777777777777776yjアドベントカレンダー T0.027777777777777776yaの R0.1111111111111111ya/ T0.027777777777777776yb08 T0.027777777777777776yeエントリー T0.027777777777777776yaで S0.08333333333333333yaす T0.027777777777777776ya。 S0.05555555555555555yb昨日 T0.027777777777777776yaは S0.08333333333333333yb渋川 T0.027777777777777776ybさん T0.027777777777777776ygアンラーニング T0.027777777777777776yb失敗 T0.027777777777777776yaし S0.05555555555555555yaた S0.05555555555555555ya話 S0.05555555555555555ya  T0.027777777777777776ya私 T0.027777777777777776ya、 T0.027777777777777776yb今年 T0.027777777777777776yb昨年 T0.027777777777777776ye続きっぽい T0.027777777777777776>va5<ya「 S0.02631578947368421yd機械学習 S0.02631578947368421ycによる S0.02631578947368421yb検索 S0.02631578947368421yeランキング S0.02631578947368421yb改善 S0.02631578947368421ycガイド S0.02631578947368421ya」 S0.02631578947368421yaを S0.05263157894736842yd読みまし S0.02631578947368421yaた S0.10526315789473684ya。 S0.05263157894736842ya  S0.05263157894736842yb著者 S0.02631578947368421yaの S0.07894736842105263yb鈴木 S0.02631578947368421ydさんより S0.02631578947368421yb献本 S0.02631578947368421yaい S0.02631578947368421ybだい S0.02631578947368421yb読み S0.02631578947368421yc終わっ S0.02631578947368421yaで S0.05263157894736842ydレビュー S0.02631578947368421yaと S0.02631578947368421ya、 S0.02631578947368421yeあとおまけ S0.02631578947368421yaす S0.02631578947368421yb紹介 S0.02631578947368421>va6<yb趣味 S0.06060606060606061ya？ T0.030303030303030304ya（ T0.030303030303030304yb検索 S0.06060606060606061ydエンジン T0.030303030303030304yaに T0.030303030303030304yc関する T0.030303030303030304yfプロジェクト T0.030303030303030304ya） T0.030303030303030304yaで T0.030303030303030304yfPython T0.030303030303030304yaの S0.06060606060606061yeプログラム T0.030303030303030304yaを T0.030303030303030304yb書い T0.030303030303030304yaて S0.06060606060606061ycいます T0.030303030303030304ya。 T0.030303030303030304ya  S0.06060606060606061ydベクトル T0.030303030303030304ybなど S0.06060606060606061yb確認 T0.030303030303030304yaも T0.030303030303030304yb含め T0.030303030303030304ya、 T0.030303030303030304ygJupyter T0.030303030303030304yaN T0.030303030303030304>va7<ydいくつか S0.02631578947368421ybある S0.02631578947368421yb環境 S0.02631578947368421yaを S0.05263157894736842ycDev S0.02631578947368421ya  S0.02631578947368421yiContainer S0.02631578947368421yaで S0.05263157894736842yb動く S0.02631578947368421ybよう S0.02631578947368421yaに S0.07894736842105263yb変え S0.02631578947368421yaて S0.02631578947368421ycいます S0.02631578947368421yaが S0.02631578947368421ya、 S0.02631578947368421yb最初 S0.02631578947368421yb導入 S0.02631578947368421yaし S0.05263157894736842yaた S0.07894736842105263ya時 S0.02631578947368421yc疑問点 S0.02631578947368421ybだっ S0.02631578947368421ya「 S0.02631578947368421ydコンテナ S0.02631578947368421ya名 S0.02631578947368421ya」 S0.02631578947368421ydについて S0.02631578947368421yb解消 S0.02631578947368421yaの S0.02631578947368421ybメモ S0.02631578947368421>va8<ya1 S0.02564102564102564ybこの S0.02564102564102564ycブログ S0.02564102564102564yaの S0.02564102564102564yb生成 S0.02564102564102564yaに S0.05128205128205128yaは S0.05128205128205128ya、 S0.07692307692307693ydHugo S0.02564102564102564yaを S0.02564102564102564yb利用 S0.02564102564102564yaし S0.05128205128205128yaて S0.07692307692307693ycいます S0.02564102564102564ya。 S0.05128205128205128ya  S0.05128205128205128ygブログ移行日記 S0.02564102564102564ya（ S0.02564102564102564ybその S0.02564102564102564ya） S0.02564102564102564yb書い S0.02564102564102564ydあります S0.02564102564102564yaが S0.02564102564102564yb当時 S0.02564102564102564ydbrew S0.02564102564102564yaで S0.02564102564102564yfインストール S0.02564102564102564ycいまし S0.02564102564102564yaた S0.02564102564102564ybまた S0.02564102564102564>va9<ya2 T0.030303030303030304ydWSL2 T0.030303030303030304yaに T0.030303030303030304yfUbuntu T0.030303030303030304yaを S0.09090909090909091yb入れ T0.030303030303030304yaて S0.09090909090909091ya、 S0.06060606060606061yb開発 T0.030303030303030304yaと T0.030303030303030304yaか T0.030303030303030304yaは T0.030303030303030304ycこちら T0.030303030303030304yb利用 S0.06060606060606061yaし S0.06060606060606061ycいます T0.030303030303030304ya。 T0.030303030303030304ya  S0.06060606060606061ybまた T0.030303030303030304yfDocker T0.030303030303030304ygDesktop T0.030303030303030304yaも T0.030303030303030304ycWSL T0.030303030303030304yaの T0.030303030303030304yjバックエンドエンジン T0.030303030303030304>vb10<yb前回 T0.027777777777777776yaの T0.027777777777777776yb記事 T0.027777777777777776yaで T0.027777777777777776ya、 T0.027777777777777776ybVS T0.027777777777777776ya  R0.1111111111111111ydCode T0.027777777777777776ya＋ T0.027777777777777776ycDev S0.05555555555555555yiContainer T0.027777777777777776yaを T0.027777777777777776yb導入 T0.027777777777777776yaし T0.027777777777777776ybまし T0.027777777777777776yaた S0.05555555555555555ya。 S0.05555555555555555yc残課題 T0.027777777777777776ycとして T0.027777777777777776ya「 T0.027777777777777776yhマルチコンテナ化 T0.027777777777777776ya」 T0.027777777777777776yaが T0.027777777777777776ybある T0.027777777777777776ycという T0.027777777777777776yb話も T0.027777777777777776ycしまし T0.027777777777777776yb今回 T0.027777777777777776yaは T0.027777777777777776yaC T0.027777777777777776>vb11<yb前回 S0.03225806451612903yaの S0.06451612903225806yb記事 S0.03225806451612903yaで S0.06451612903225806ya、 S0.06451612903225806ycpre S0.03225806451612903ya- S0.03225806451612903yfcommit S0.03225806451612903yaと R0.0967741935483871ygPyCharm S0.03225806451612903ygWindows S0.03225806451612903yb組み S0.03225806451612903yc合わせ S0.03225806451612903yb困っ S0.03225806451612903yaて S0.03225806451612903ybいる S0.03225806451612903ybこと S0.03225806451612903yaを S0.03225806451612903yd書きまし S0.03225806451612903yaた S0.03225806451612903ya。 S0.03225806451612903ya  S0.03225806451612903ybこれ S0.03225806451612903ydについて S0.03225806451612903yd知り合い S0.03225806451612903ydチャット S0.03225806451612903>vb12<yb最近 S0.03571428571428571ya、 S0.03571428571428571yb趣味 S0.07142857142857142ya（ S0.03571428571428571yb検索 S0.03571428571428571ydエンジン S0.03571428571428571yaに S0.03571428571428571yc関する S0.03571428571428571yfプロジェクト S0.07142857142857142ya） S0.03571428571428571yaで S0.03571428571428571yfPython S0.07142857142857142yaの S0.07142857142857142yeプログラム S0.07142857142857142yaを S0.07142857142857142yb書き S0.03571428571428571yd始めまし S0.03571428571428571yaた S0.03571428571428571ya。 S0.03571428571428571ya  S0.03571428571428571ycきちん S0.03571428571428571yaと S0.03571428571428571>vb13<yb今年d0.05yaもd0.05ybこのe0.025yb季節e0.025yaがe0.025ybやっe0.025yaてd0.05ycきましe0.025yaたe0.075ya。d0.05ya e0.075yfBerline0.025yiBuzzwordse0.025yaにe0.025yeオンラインd0.05yaでc0.1yb出張e0.025yaしe0.025ybましe0.025yfハイブリッドe0.025yb開催e0.025yaをe0.025ybしてe0.025yaくe0.025yaれe0.025yaのe0.025ya、e0.025yb参加e0.025>vb14<yb今年 T0.022727272727272728yaも T0.022727272727272728ybなん T0.022727272727272728ybとか T0.022727272727272728yb振り S0.06818181818181818yb返り T0.045454545454545456ycブログ T0.022727272727272728yaを T0.045454545454545456yb書い T0.045454545454545456yaて T0.022727272727272728ybます T0.022727272727272728ya（ T0.045454545454545456ye時間大丈夫 T0.022727272727272728yaか T0.022727272727272728yaな T0.045454545454545456ya？ T0.022727272727272728yaw T0.022727272727272728ya） T0.045454545454545456ya。 T0.045454545454545456yb紅白 T0.022727272727272728ydリアタイ T0.022727272727272728yaで T0.022727272727272728ya見 T0.022727272727272728yaが T0.022727272727272728yaら T0.022727272727272728ya  T0.045454545454545456ye2021年 T0.022727272727272728yaに T0.022727272727272728yaた T0.022727272727272728yb抱負 T0.022727272727272728ybから T0.022727272727272728ybまず T0.022727272727272728yaは T0.022727272727272728ya返 T0.022727272727272728>vb15<yb12 T0.027777777777777776yb15 T0.027777777777777776yePySpa T0.027777777777777776yjアドベントカレンダー T0.027777777777777776yaの S0.05555555555555555ya/ T0.027777777777777776yeエントリー T0.027777777777777776yaで S0.08333333333333333yaす T0.027777777777777776ya。 S0.08333333333333333yb昨日 T0.027777777777777776yaは R0.1111111111111111yftaichi T0.027777777777777776ybさん T0.027777777777777776yaし T0.027777777777777776yaた T0.027777777777777776ya  S0.05555555555555555yb今年 T0.027777777777777776ycDIY T0.027777777777777776ybなく T0.027777777777777776ya、 T0.027777777777777776ybPC T0.027777777777777776yaに T0.027777777777777776ydまつわる T0.027777777777777776ya話 T0.027777777777777776yaを T0.027777777777777776yc仕事中 T0.027777777777777776>vb16<yd2022 S0.02631578947368421yc本記事 S0.02631578947368421yaは S0.02631578947368421yd情報検索 S0.02631578947368421ya・ S0.02631578947368421yd検索技術 S0.02631578947368421ya  S0.10526315789473684yfAdvent S0.02631578947368421yhCalendar S0.02631578947368421yaの S0.10526315789473684yc9日目 S0.02631578947368421yb記事 S0.05263157894736842yaで S0.02631578947368421yaす S0.02631578947368421ya。 S0.05263157894736842ycだいぶ S0.02631578947368421ya間 S0.02631578947368421yaが S0.05263157894736842yb空い S0.02631578947368421yaて S0.02631578947368421yeしまいまし S0.02631578947368421yaた S0.02631578947368421ya、 S0.02631578947368421yc日本語 S0.02631578947368421yiオートコンプリート S0.02631578947368421yaに S0.02631578947368421yc関する S0.02631578947368421yb続き S0.02631578947368421ybです S0.02631578947368421>vb17<yb前回 T0.030303030303030304yaは S0.06060606060606061yd日本語用 T0.030303030303030304yiオートコンプリート T0.030303030303030304yaの S0.06060606060606061ybため T0.030303030303030304yhAnalyzer T0.030303030303030304ycとして T0.030303030303030304ya、 S0.06060606060606061ydどうやっ T0.030303030303030304yaて T0.030303030303030304yb使う T0.030303030303030304ybのか T0.030303030303030304yaを S0.06060606060606061yb簡単 T0.030303030303030304yaに T0.030303030303030304yb紹介 T0.030303030303030304yaし T0.030303030303030304ybまし T0.030303030303030304yaた T0.030303030303030304ya。 T0.030303030303030304ya  T0.030303030303030304yb今回 T0.030303030303030304ybもう T0.030303030303030304yb少し T0.030303030303030304ycいろん T0.030303030303030304yaな T0.030303030303030304ydパターン T0.030303030303030304ya試 T0.030303030303030304>vb18<ya風 T0.041666666666666664yaの S0.16666666666666666ycうわさ T0.041666666666666664yaで T0.041666666666666664ya、 T0.041666666666666664yd日本語用 T0.041666666666666664yiオートコンプリート T0.041666666666666664ybため T0.041666666666666664ykTokenFilter T0.041666666666666664yaと S0.08333333333333333yhAnalyzer T0.041666666666666664yaが T0.041666666666666664yfLucene T0.041666666666666664yaに T0.041666666666666664ye取り込まれ T0.041666666666666664yaた S0.08333333333333333yd聞きまし T0.041666666666666664ya（ T0.041666666666666664ydLUCE T0.041666666666666664>vb19<ya0 S0.05405405405405406yb84 S0.02702702702702703yb92 S0.02702702702702703ydHugo S0.02702702702702703yaを S0.10810810810810811ya. S0.05405405405405406ybから S0.02702702702702703yaに S0.08108108108108109yfアップデート S0.02702702702702703ybする S0.02702702702702703ya際 S0.02702702702702703ya、 S0.02702702702702703ybこれ S0.02702702702702703ybまで S0.02702702702702703yaの S0.05405405405405406ycブログ S0.02702702702702703yb記事 S0.02702702702702703yaや S0.02702702702702703yiレイアウトファイル S0.02702702702702703yb修正 S0.02702702702702703yaし S0.02702702702702703yaた S0.02702702702702703yaで S0.02702702702702703yc個人的 S0.02702702702702703ybメモ S0.02702702702702703yb残し S0.02702702702702703yaて S0.02702702702702703ydおきます S0.02702702702702703ya。 S0.02702702702702703>vb20<yb今回 S0.03333333333333333yaは S0.03333333333333333yfQuerqy S0.03333333333333333yaの S0.06666666666666667ymElasticsearch S0.03333333333333333yeプラグイン S0.03333333333333333yaが S0.03333333333333333ybどん S0.03333333333333333ydなつくり S0.03333333333333333yaに S0.03333333333333333ybなっ S0.03333333333333333yaて S0.06666666666666667ybいる S0.03333333333333333yaか S0.03333333333333333ya？ S0.03333333333333333yaを S0.03333333333333333ycちょっ S0.03333333333333333yaと S0.03333333333333333ybだけ S0.03333333333333333yb調べ S0.03333333333333333ycみまし S0.03333333333333333yaた S0.03333333333333333ya。 S0.03333333333333333ya  S0.03333333333333333ydSolr S0.03333333333333333yaで S0.03333333333333333yaも S0.03333333333333333yeElast S0.03333333333333333>vb21<yfQuerqyg0.03125ycというg0.03125ycクエリg0.03125yaのg0.09375ydリライトg0.03125ya用g0.03125yeプラグインg0.03125yaがg0.03125ybあるg0.03125yaでg0.03125ybどんg0.03125ydなものかg0.03125yaをf0.0625yb調べg0.03125yaてf0.0625ycみましg0.03125yaたf0.0625ya。g0.03125ybとりg0.03125ycあえずg0.03125yaはg0.03125yb概要g0.03125yfドキュメントg0.03125ybからg0.03125yd追いかけg0.03125yaみg0.03125yb感じg0.03125>vb22<yb今年 S0.05555555555555555yaも T0.027777777777777776yfBerlin T0.027777777777777776ya  S0.05555555555555555yiBuzzwords T0.027777777777777776yaに T0.027777777777777776yeオンライン T0.027777777777777776yb出張 T0.027777777777777776yaし S0.08333333333333333yaて S0.05555555555555555ybまし T0.027777777777777776yaた S0.08333333333333333ya。 S0.05555555555555555yaは T0.027777777777777776yfハイブリッド T0.027777777777777776yaな T0.027777777777777776yb開催 T0.027777777777777776ybだっ T0.027777777777777776ybよう S0.05555555555555555yaで S0.08333333333333333ya、 T0.027777777777777776yb現地 T0.027777777777777776yb再開 T0.027777777777777776ybいる T0.027777777777777776yd人もいる T0.027777777777777776>vb23<ya7 S0.02702702702702703yb16 S0.02702702702702703ya. S0.02702702702702703yaで S0.08108108108108109yb正式 S0.02702702702702703ydリリース S0.02702702702702703yaさ S0.02702702702702703yaれ S0.02702702702702703ybまし S0.02702702702702703yaた S0.05405405405405406yaが S0.05405405405405406ya、 S0.05405405405405406ymElasticsearch S0.02702702702702703yaの S0.08108108108108109yc新しい S0.02702702702702703ydJava S0.02702702702702703yfクライアント S0.02702702702702703ya出 S0.02702702702702703yaて S0.05405405405405406yaい S0.02702702702702703ybます S0.02702702702702703ya。 S0.02702702702702703ya  S0.02702702702702703yb使っ S0.02702702702702703yaみ S0.02702702702702703ycちょっ S0.02702702702702703yaと S0.02702702702702703ybだけ S0.02702702702702703yb紹介 S0.02702702702702703>vb24<yeAzure S0.02702702702702703ya  S0.10810810810810811yiCognitive S0.02702702702702703yfSearch S0.02702702702702703yaで S0.05405405405405406yb2月 S0.02702702702702703yaに S0.02702702702702703yc新しい S0.02702702702702703yb機能 S0.02702702702702703yaが S0.02702702702702703yb公開 S0.02702702702702703yaさ S0.02702702702702703yaれ S0.02702702702702703ybまし S0.02702702702702703yaた S0.02702702702702703ya。 S0.05405405405405406ya「 S0.02702702702702703yeIndex S0.02702702702702703yeAlias S0.02702702702702703ya」 S0.02702702702702703ya（ S0.02702702702702703yfインデックス S0.02702702702702703yaの S0.05405405405405406yb別名 S0.02702702702702703ya） S0.02702702702702703ybです S0.02702702702702703ybまだ S0.02702702702702703ya、 S0.02702702702702703yjパブリックプレビュー S0.02702702702702703yb段階 S0.02702702702702703yaす S0.02702702702702703>vb25<yb年末 S0.01818181818181818ybまで S0.01818181818181818yaに S0.01818181818181818yd知り合い S0.01818181818181818yaと S0.03636363636363636ya次 S0.01818181818181818yaの S0.05454545454545454yb論文 S0.01818181818181818yaを S0.01818181818181818yb読ん S0.03636363636363636yaだ S0.05454545454545454yaで S0.05454545454545454yb軽く S0.01818181818181818ydまとめて S0.01818181818181818ydおきます S0.01818181818181818ya。 S0.01818181818181818ya c0.2ygExtreme S0.01818181818181818yeMulti S0.01818181818181818ya- S0.01818181818181818yelabel S0.01818181818181818yhLearning S0.01818181818181818ycfor S0.01818181818181818yhSemantic S0.03636363636363636yhMatching S0.01818181818181818ybin S0.01818181818181818ygProduct S0.01818181818181818yfSearch S0.01818181818181818ybなん S0.01818181818181818ya？ S0.01818181818181818yd前回読ん S0.01818181818181818yb理由 S0.01818181818181818yb一緒 S0.01818181818181818yaす S0.01818181818181818yaが S0.01818181818181818ya、 S0.01818181818181818>vb26<yb今年 T0.022727272727272728yaも T0.022727272727272728yb振り T0.045454545454545456yb返り T0.045454545454545456ycブログ T0.022727272727272728yaで T0.022727272727272728yaす T0.022727272727272728ya。 T0.045454545454545456yb録画 T0.022727272727272728yaし T0.045454545454545456yaた T0.045454545454545456yb紅白 T0.022727272727272728yaを T0.022727272727272728ybオッ T0.022727272727272728ybかけ T0.022727272727272728yb再生 T0.022727272727272728yaて T0.045454545454545456ya気 T0.022727272727272728yaに T0.045454545454545456ybなる T0.022727272727272728yfアーティスト T0.022727272727272728ybだけ T0.022727272727272728ya見 T0.022727272727272728yaな T0.022727272727272728ybがら T0.022727272727272728ya書 T0.022727272727272728yaい T0.022727272727272728ybます T0.022727272727272728ya  T0.045454545454545456ya（ T0.022727272727272728ye2020年 T0.022727272727272728yb書い T0.022727272727272728yb抱負 T0.022727272727272728ybから T0.022727272727272728ya） T0.022727272727272728yaま T0.022727272727272728>vb27<ye2021年 S0.02857142857142857yaも S0.02857142857142857ybあと S0.02857142857142857yb少し S0.02857142857142857yaで S0.02857142857142857yaす S0.02857142857142857yaが S0.05714285714285714ya、 S0.05714285714285714yd今年買っ S0.05714285714285714yaて S0.05714285714285714yc良かっ S0.02857142857142857yaた S0.05714285714285714ybもの S0.02857142857142857yaを S0.05714285714285714yfリストアップ S0.02857142857142857yaし S0.02857142857142857ydおこうか S0.02857142857142857yaと S0.02857142857142857yd思います S0.02857142857142857ya。 S0.02857142857142857ya  S0.02857142857142857ycといい S0.02857142857142857yaな S0.02857142857142857yaら S0.02857142857142857yb昨年 S0.02857142857142857ybこの S0.02857142857142857ybネタ S0.02857142857142857yb書く S0.02857142857142857yeといいつつ S0.02857142857142857>vb28<yeAzure S0.05263157894736842ya  S0.07894736842105263yiCognitive S0.02631578947368421yfSearch S0.02631578947368421yaの S0.15789473684210525ydスキーマ S0.02631578947368421yb確認 S0.02631578947368421yaを S0.02631578947368421ybする S0.02631578947368421ybとき S0.02631578947368421yaに S0.05263157894736842ya、 S0.05263157894736842ydポータル S0.02631578947368421yaで S0.02631578947368421yaは S0.02631578947368421ya次 S0.02631578947368421ybよう S0.02631578947368421yeフィールド S0.02631578947368421yb一覧 S0.02631578947368421ycとして S0.02631578947368421yb見る S0.02631578947368421ybこと S0.02631578947368421yaが S0.02631578947368421ydできます S0.02631578947368421ya。 S0.02631578947368421ybただ S0.02631578947368421yb実際 S0.02631578947368421ycインデ S0.02631578947368421>vb29<yd2021e0.025yb今年d0.05yaもe0.025yjアドベントカレンダーe0.025yaのe0.075yb季節e0.025yaにd0.05ybなっe0.025yaてe0.025yeしまいましe0.025yaたe0.025ya。d0.05ya e0.125yaでd0.05yc2回目e0.025yaとe0.025ybなるe0.025ya、e0.025yepyspae0.025yfAdvente0.025yhCalendare0.025yb投稿d0.05yaすe0.025yb昨年e0.025yb引きe0.025yb続きe0.025ycDIYe0.025yaがe0.025ybらみe0.025>vb30<yfDomain T0.017543859649122806ya- T0.017543859649122806yhSpecific T0.017543859649122806ya  S0.22807017543859648ykPretraining T0.017543859649122806ycfor T0.017543859649122806yhVertical T0.017543859649122806yfSearch T0.017543859649122806ya: T0.017543859649122806ydCase T0.017543859649122806yeStudy T0.017543859649122806ybon T0.017543859649122806yjBiomedical T0.017543859649122806yjLiterature T0.017543859649122806ycという T0.017543859649122806yb論文 T0.017543859649122806yaを S0.03508771929824561yb読ん S0.03508771929824561yaだ S0.05263157894736842yaの T0.017543859649122806yaで T0.017543859649122806yb軽く T0.017543859649122806ybメモ T0.017543859649122806yb残し T0.017543859649122806yaて S0.03508771929824561ydおきます T0.017543859649122806ya。 S0.03508771929824561yd論文自体 T0.017543859649122806yaは T0.017543859649122806ycリンク T0.017543859649122806ybから T0.017543859649122806yb参照 T0.017543859649122806yaし T0.017543859649122806yaく T0.017543859649122806ybさい T0.017543859649122806yb理由 T0.017543859649122806yeAzure T0.017543859649122806yiCognitive T0.017543859649122806yaS T0.017543859649122806>vb31<yc201 S0.02564102564102564yb今年 S0.05128205128205128yaも S0.05128205128205128yeMICES S0.05128205128205128yaに S0.02564102564102564yb参加 S0.02564102564102564yaし S0.07692307692307693yaて S0.02564102564102564ybまし S0.02564102564102564yaた S0.07692307692307693ya。 S0.05128205128205128ya  S0.07692307692307693yb昨年 S0.02564102564102564yaは S0.07692307692307693yfBerlin S0.02564102564102564yiBuzzwords S0.02564102564102564yaと S0.02564102564102564yb共同 S0.02564102564102564yb開催 S0.02564102564102564yaで S0.05128205128205128yaが S0.02564102564102564ya、 S0.02564102564102564yc別開催 S0.02564102564102564ya（ S0.02564102564102564yc別日程 S0.02564102564102564ya） S0.02564102564102564>vb32<yb今年 T0.058823529411764705yaも T0.029411764705882353yfBerlin T0.029411764705882353ya  S0.08823529411764706yiBuzzwords T0.029411764705882353yaに T0.029411764705882353yeオンライン T0.029411764705882353yb出張 T0.029411764705882353yaし T0.058823529411764705yaて T0.029411764705882353ybまし T0.029411764705882353yaた T0.058823529411764705ya。 T0.058823529411764705yaの T0.029411764705882353yb開催 T0.029411764705882353yaは T0.058823529411764705ye6月14日 T0.029411764705882353ybから T0.029411764705882353yc17日 T0.029411764705882353ybまで T0.029411764705882353yaで T0.029411764705882353ybどん T0.029411764705882353yaな T0.058823529411764705ygカンファレンス T0.029411764705882353ybのか T0.029411764705882353yb昨年 T0.029411764705882353>vb33<yeAzure T0.029411764705882353ya  S0.14705882352941177yiCognitive T0.029411764705882353yfSearch T0.058823529411764705yaで T0.029411764705882353yc新機能 T0.029411764705882353ya「 T0.029411764705882353yhSemantic T0.029411764705882353ya（ T0.029411764705882353ygセマンティック T0.029411764705882353yb検索 T0.029411764705882353ya） T0.029411764705882353ya」 T0.029411764705882353ycという T0.029411764705882353yb機能 T0.029411764705882353yaの T0.029411764705882353ye日本語対応 T0.029411764705882353yaが T0.029411764705882353yb発表 T0.029411764705882353yaさ T0.029411764705882353yaれ T0.029411764705882353ybまし T0.029411764705882353yaた T0.029411764705882353ya。 T0.029411764705882353yb実際 T0.029411764705882353yaに T0.029411764705882353yaは T0.029411764705882353yfPublic T0.029411764705882353yaP T0.029411764705882353>vb34<yeSofle S0.03225806451612903ya  R0.0967741935483871ybv2 S0.03225806451612903yaを S0.03225806451612903yc長らく S0.03225806451612903yb使っ S0.03225806451612903yaて S0.06451612903225806ycいまし S0.03225806451612903yaた S0.03225806451612903yaが S0.06451612903225806ya、 S0.03225806451612903yeコンパクト S0.03225806451612903yaな S0.03225806451612903yaの S0.03225806451612903yaも S0.03225806451612903ygやっぱりいいよ S0.03225806451612903ybなぁ S0.03225806451612903ycという S0.03225806451612903ybとき S0.03225806451612903yaに S0.03225806451612903yeKochi S0.03225806451612903yhKeyboard S0.03225806451612903ybから S0.03225806451612903ygLunakey S0.03225806451612903ydMini S0.03225806451612903yb発売 S0.03225806451612903yaし S0.03225806451612903>vb35<yaみ T0.030303030303030304ycなさん T0.030303030303030304yaは S0.09090909090909091ya、 S0.06060606060606061ydスライド S0.06060606060606061yaの T0.030303030303030304yb作成 T0.030303030303030304yaに T0.030303030303030304ya何 T0.030303030303030304yaを S0.06060606060606061yb使っ T0.030303030303030304yaて T0.030303030303030304ydいますか T0.030303030303030304ya？ S0.12121212121212122ya  S0.09090909090909091ygKeynote T0.030303030303030304yjPowerpoint T0.030303030303030304yfGoogle T0.030303030303030304yfSlides T0.030303030303030304ya私 T0.030303030303030304ycMac T0.030303030303030304yaで T0.030303030303030304ya作 T0.030303030303030304>vb36<yb新型 S0.02702702702702703ygコロナウィルス S0.02702702702702703yaの S0.02702702702702703yb影響 S0.02702702702702703yaも S0.08108108108108109ybあり S0.02702702702702703ya、 S0.05405405405405406yeオフライン S0.02702702702702703yaで S0.05405405405405406yc集まっ S0.02702702702702703yaて S0.08108108108108109yc勉強会 S0.02702702702702703yb開催 S0.02702702702702703ybでき S0.05405405405405406ybなく S0.02702702702702703ybなっ S0.02702702702702703yaい S0.05405405405405406ybます S0.02702702702702703ya。 S0.05405405405405406ya  S0.05405405405405406yg検索技術勉強会 S0.02702702702702703ybもう S0.02702702702702703yb1年 S0.02702702702702703yd以上開催 S0.02702702702702703ybない S0.02702702702702703yaす S0.02702702702702703yaス S0.02702702702702703>vb37<yeAzure T0.029411764705882353ya  S0.08823529411764706yiCognitive T0.029411764705882353yfSearch T0.029411764705882353yaに T0.029411764705882353yaは T0.058823529411764705yeOData T0.058823529411764705ya式 T0.029411764705882353ycという T0.029411764705882353yb書式 T0.029411764705882353yaで T0.029411764705882353yb条件 T0.058823529411764705yaが T0.058823529411764705yc書ける T0.029411764705882353yb仕組 T0.029411764705882353yaみ T0.029411764705882353ydあります T0.029411764705882353ya。 T0.029411764705882353yd検索条件 T0.029411764705882353ya（ T0.058823529411764705ya$ T0.058823529411764705yffilter T0.029411764705882353ya） T0.029411764705882353yaや T0.029411764705882353ycソート T0.029411764705882353yforderb T0.029411764705882353>vb38<yd2020 T0.045454545454545456yb自宅 T0.022727272727272728yaの S0.11363636363636363yb環境 T0.022727272727272728yaが T0.045454545454545456ydいろいろ T0.022727272727272728yaと T0.022727272727272728yc変わっ T0.022727272727272728yaた T0.045454545454545456yaで S0.06818181818181818yaす T0.045454545454545456ya、 T0.045454545454545456yb書い T0.022727272727272728yaて T0.022727272727272728yaい T0.022727272727272728ycなかっ T0.022727272727272728yc更新版 T0.022727272727272728ya。 T0.022727272727272728ya  T0.022727272727272728yb前回 T0.022727272727272728ycブログ T0.045454545454545456ya( T0.045454545454545456ya/ T0.045454545454545456yb09 T0.022727272727272728ya) T0.045454545454545456yc前々回 T0.022727272727272728yb03 T0.022727272727272728yaは T0.022727272727272728yaそ T0.022727272727272728>vb39<yeAzure T0.027777777777777776ya  S0.08333333333333333yiCognitive T0.027777777777777776yfSearch T0.027777777777777776yaに T0.027777777777777776ygSuggest T0.027777777777777776yaや T0.027777777777777776ylAutocomplete T0.027777777777777776yaの S0.08333333333333333yb機能 T0.027777777777777776yaが T0.027777777777777776ybある T0.027777777777777776yaを S0.05555555555555555yc見つけ T0.027777777777777776yaた T0.027777777777777776yaで T0.027777777777777776ya、 T0.027777777777777776ybどん T0.027777777777777776yaな S0.05555555555555555yb挙動 T0.027777777777777776ybのか T0.027777777777777776yb調べ T0.027777777777777776yaて S0.05555555555555555ybログ T0.027777777777777776ycとして T0.027777777777777776yb残し T0.027777777777777776ydおきます T0.027777777777777776ya。 T0.027777777777777776ya公 T0.027777777777777776>vb40<yjオライリー・ジャパン T0.027777777777777776ybから T0.027777777777777776ya出 T0.027777777777777776yaて T0.027777777777777776ybいる T0.027777777777777776ya「 T0.027777777777777776yjコンピュータシステム T0.027777777777777776yaの R0.1111111111111111yb理論 T0.027777777777777776yaと T0.027777777777777776yb実装 T0.027777777777777776ya」 T0.027777777777777776yaを S0.05555555555555555yb読み T0.027777777777777776yb始め T0.027777777777777776yaた T0.027777777777777776yaで T0.027777777777777776ybメモ T0.027777777777777776yb取る T0.027777777777777776ybこと T0.027777777777777776yaに T0.027777777777777776ya。 T0.027777777777777776ya  T0.027777777777777776yb原著 T0.027777777777777776yaは T0.027777777777777776yeオライリー T0.027777777777777776yaじ T0.027777777777777776yaゃ T0.027777777777777776ybない T0.027777777777777776yaか T0.027777777777777776ycという T0.027777777777777776yaが T0.027777777777777776>vb41<ygCorne使っ S0.02631578947368421yaて S0.02631578947368421ybまし S0.02631578947368421yaた S0.02631578947368421yaが S0.07894736842105263ya、 S0.05263157894736842yb数字 S0.02631578947368421ybキー S0.02631578947368421ybある S0.02631578947368421ycとどう S0.02631578947368421yaな S0.05263157894736842yaの S0.05263157894736842yaか S0.02631578947368421ya？ S0.02631578947368421ycという S0.02631578947368421yaや S0.02631578947368421ybはり S0.02631578947368421ya気 S0.02631578947368421yaに S0.02631578947368421ycなって S0.02631578947368421ya。 S0.02631578947368421ya  S0.10526315789473684ycそこに S0.02631578947368421yeKochi S0.02631578947368421yhKeyboard S0.05263157894736842ybさん S0.02631578947368421ybから S0.02631578947368421yeSofle S0.02631578947368421yav S0.02631578947368421>vb42<yfメインマシン S0.03333333333333333yaと S0.03333333333333333ycMac S0.03333333333333333yaは S0.03333333333333333yb下記 S0.03333333333333333yaのc0.1ygサンワサプライ S0.03333333333333333ycUSB S0.03333333333333333yb接続 S0.06666666666666667ycKVM S0.03333333333333333ydスイッチ S0.03333333333333333yaを S0.03333333333333333yb使っ S0.03333333333333333yaて S0.06666666666666667ycいます S0.03333333333333333yaが S0.06666666666666667ya、 S0.03333333333333333ybもう S0.03333333333333333yb一台 S0.03333333333333333ycノート S0.03333333333333333ybPC S0.03333333333333333yeありここに S0.03333333333333333yaし S0.03333333333333333ybいる S0.03333333333333333yeCorne S0.03333333333333333>vb43<yb振り T0.027777777777777776yb返り T0.027777777777777776ycブログ T0.027777777777777776yaに S0.05555555555555555yaも T0.027777777777777776yd書きまし T0.027777777777777776yaた R0.1111111111111111yaが T0.027777777777777776ya、 T0.027777777777777776yfデスクトップ T0.027777777777777776ybPC T0.027777777777777776yaを S0.05555555555555555yb自作 T0.027777777777777776ya( T0.027777777777777776ycDIY T0.027777777777777776ya) T0.027777777777777776ycしまし T0.027777777777777776ya。 S0.05555555555555555ya  S0.05555555555555555yb組み T0.027777777777777776yb立て T0.027777777777777776yb使っ T0.027777777777777776ycパーツ T0.027777777777777776yaの T0.027777777777777776yfアフィリンク T0.027777777777777776yb貼っ T0.027777777777777776yaて T0.027777777777777776ydおきます T0.027777777777777776ye10月くら T0.027777777777777776>vb44<yb今年 T0.023809523809523808yaも T0.023809523809523808yb振り T0.047619047619047616yb返り T0.047619047619047616yeブログ書い T0.023809523809523808yaて S0.09523809523809523ybます T0.023809523809523808ya。 T0.047619047619047616ycカタン T0.023809523809523808yaの T0.023809523809523808yb航海 T0.023809523809523808yb者版 T0.023809523809523808yaを T0.023809523809523808yb購入 T0.023809523809523808yaし T0.023809523809523808yb家族 T0.023809523809523808yaと T0.023809523809523808ybやっ T0.023809523809523808ybまし T0.023809523809523808yaた S0.07142857142857142yaが T0.023809523809523808ya、 T0.023809523809523808yb負け T0.023809523809523808yeしまいまし T0.023809523809523808ya  T0.047619047619047616ya（ T0.023809523809523808ye2019年 T0.023809523809523808yaに T0.023809523809523808yb書い T0.023809523809523808yb抱負 T0.023809523809523808ybから T0.023809523809523808ya） T0.023809523809523808yaま T0.023809523809523808>vb45<ya7 T0.019230769230769232ya8 T0.019230769230769232yd2020 T0.019230769230769232ygElastic T0.019230769230769232ya  S0.15384615384615385yestack T0.019230769230769232ya( T0.019230769230769232ymElasticsearch T0.038461538461538464ya) T0.019230769230769232yfAdvent T0.019230769230769232yhCalendar T0.019230769230769232yaの T0.057692307692307696yd18日目 T0.019230769230769232yb記事 T0.019230769230769232yaに T0.019230769230769232ydなります T0.019230769230769232ya。 T0.038461538461538464yb本日 T0.019230769230769232yc勉強会 T0.019230769230769232yaで T0.057692307692307696ybLT T0.019230769230769232yaを T0.019230769230769232ycしまし T0.019230769230769232yaた T0.038461538461538464yaが T0.019230769230769232ya、 T0.019230769230769232ydしゃべり T0.019230769230769232yb足り T0.019230769230769232ycなかっ T0.019230769230769232ybたん T0.019230769230769232ya. T0.019230769230769232ybこっ T0.019230769230769232ybそり T0.019230769230769232yaと T0.019230769230769232ydリリース T0.019230769230769232yaさ T0.019230769230769232yaれ T0.019230769230769232yaI T0.019230769230769232>vb46<yd2020 S0.02702702702702703yaは S0.02702702702702703yeじめまして S0.02702702702702703ya、 S0.05405405405405406yepyspa S0.05405405405405406ya。 S0.05405405405405406ya  S0.13513513513513514ycという S0.02702702702702703ybこと S0.02702702702702703yaで S0.05405405405405406yfAdvent S0.02702702702702703yhCalendar S0.02702702702702703yaの S0.08108108108108109yc4日目 S0.02702702702702703ya( S0.02702702702702703yb大谷 S0.02702702702702703ycコンビ S0.05405405405405406yb2号 S0.02702702702702703ya) S0.02702702702702703yb投稿 S0.02702702702702703yaに S0.02702702702702703ydなります S0.02702702702702703ydそろって S0.02702702702702703yeキーボード S0.02702702702702703yb記事 S0.02702702702702703yaす S0.02702702702702703>vb47<yb前回 S0.02857142857142857yaの S0.11428571428571428ycブログ S0.02857142857142857ycまとめ S0.02857142857142857yaに S0.05714285714285714yb書い S0.02857142857142857yaた S0.05714285714285714ybよう S0.02857142857142857ya、 S0.02857142857142857yhセパレートタイプ S0.02857142857142857yeキーボード S0.05714285714285714yaで S0.08571428571428572ybある S0.02857142857142857yeCorne S0.02857142857142857ya  S0.05714285714285714yeLight S0.02857142857142857ybv2 S0.02857142857142857yaを S0.02857142857142857yb作成 S0.02857142857142857yaし S0.02857142857142857ybその S0.02857142857142857yeビルドログ S0.02857142857142857yaす S0.02857142857142857ya。 S0.02857142857142857ycDIY S0.02857142857142857ybとし S0.02857142857142857>vb48<ybヒゲ S0.02631578947368421yaが S0.05263157894736842yb不評 S0.02631578947368421ybだっ S0.02631578947368421yaた S0.10526315789473684yaの S0.07894736842105263ycでいつ S0.02631578947368421yaも S0.02631578947368421yb通り S0.02631578947368421yb長さ S0.02631578947368421yaに S0.02631578947368421yd切りまし S0.02631578947368421ya。 S0.02631578947368421ya  S0.02631578947368421yb前回 S0.02631578947368421ya「 S0.02631578947368421ygWindows S0.02631578947368421yaを S0.05263157894736842ycお試し S0.02631578947368421ya中 S0.02631578947368421ya」 S0.02631578947368421yaと S0.02631578947368421yd書きまし S0.02631578947368421ya、 S0.02631578947368421ydいくつか S0.02631578947368421ycソフト S0.02631578947368421yfインストール S0.02631578947368421yaし S0.05263157894736842ybたり S0.02631578947368421yaで S0.02631578947368421>vb49<ybヒゲ S0.02127659574468085yaが S0.06382978723404255yb伸び S0.02127659574468085yaて R0.0851063829787234ybきて S0.02127659574468085ya( S0.02127659574468085yb試し S0.02127659574468085yaに S0.02127659574468085ye伸ばしてる S0.02127659574468085ya) S0.02127659574468085yb不評 S0.02127659574468085yaを S0.02127659574468085yb買っ S0.02127659574468085ybいる S0.02127659574468085yb今日 S0.02127659574468085yaこ S0.02127659574468085yaの R0.0425531914893617ybごろ S0.02127659574468085yaで R0.0851063829787234yaす S0.02127659574468085ya。 S0.02127659574468085ya  S0.02127659574468085yb自宅 S0.02127659574468085yb作業 S0.02127659574468085ybする S0.02127659574468085ybこと S0.02127659574468085yb多く S0.02127659574468085ybなっ S0.02127659574468085yaき S0.02127659574468085yaた S0.02127659574468085ya、 R0.0425531914893617yb自作 S0.02127659574468085ybPC S0.02127659574468085yaも S0.02127659574468085yaと S0.02127659574468085yb思っ S0.02127659574468085ycいます S0.02127659574468085>vb50<yb今年g0.03125yaのg0.09375yd春くらいg0.03125ybからg0.03125ya、g0.09375yhセパレートタイプg0.03125yeキーボードf0.0625yaがg0.09375ya気g0.03125yaにg0.03125ybなっg0.03125yaてg0.03125yaいg0.03125ybますg0.03125ya。g0.03125ya g0.03125ybまたg0.03125ycなんかg0.03125yb知らg0.03125ybないg0.03125yaでg0.03125yaすg0.03125ygTwitterg0.03125yfタイムラインg0.03125yb自作g0.03125>vb51<yb10e0.025yb11e0.025yd2020e0.025ya/d0.05yb06e0.025ya e0.075ya:e0.025ye00くらいe0.025yaにe0.025ycマージe0.025yaさe0.025yaれe0.025ybましe0.025yaたe0.025ya。e0.025ya@e0.025yfminorue0.025ya_e0.025yeosukae0.025ybさんe0.025yaがd0.05yb開発e0.025yaをe0.025yb引きe0.025yb継いe0.025yaだe0.025ygLinderae0.025ycというe0.025yhKuromojie0.025yaのe0.025ydRuste0.025ydクローンe0.025ydありますe0.025ya(e0.025yeリポジトリe0.025ya)e0.025>vb52<yb先日 S0.02702702702702703yaは S0.02702702702702703ya「 S0.02702702702702703yb検索 S0.08108108108108109ydシステム S0.05405405405405406yaを S0.05405405405405406yb構成 S0.05405405405405406ybする S0.02702702702702703ycパーツ S0.05405405405405406ya」 S0.02702702702702703ycという S0.02702702702702703ybこと S0.02702702702702703yaで S0.02702702702702703yaし S0.05405405405405406yaて S0.05405405405405406ybいる S0.02702702702702703ydについて S0.02702702702702703yb書い S0.02702702702702703ycみまし S0.02702702702702703yaた S0.02702702702702703ya。 S0.02702702702702703ya  S0.02702702702702703yb大体 S0.02702702702702703ya、 S0.02702702702702703yaが S0.02702702702702703ycうまく S0.02702702702702703ycヒット S0.02702702702702703ybない S0.02702702702702703ybとい S0.02702702702702703>vb53<yd自宅環境 S0.02631578947368421yaに S0.02631578947368421yb少し S0.02631578947368421yfアップデート S0.02631578947368421yaが S0.02631578947368421ybあっ S0.02631578947368421yaた S0.02631578947368421yaの S0.13157894736842105yaで S0.10526315789473684yc更新版 S0.02631578947368421yaす S0.02631578947368421ya。 S0.02631578947368421ya  S0.02631578947368421yaお S0.02631578947368421yc客さん S0.02631578947368421ycおかげ S0.02631578947368421yb相変 S0.02631578947368421ycわらず S0.02631578947368421yb自宅 S0.02631578947368421yb作業 S0.02631578947368421yaさ S0.02631578947368421yaせ S0.02631578947368421yaて S0.02631578947368421ycもらっ S0.02631578947368421ybてる S0.02631578947368421yaも S0.02631578947368421ybあり S0.02631578947368421ya、 S0.02631578947368421yb昨今 S0.02631578947368421ygコロナウイルス S0.02631578947368421yb影響 S0.02631578947368421>vb54<ydRust T0.047619047619047616yaで S0.07142857142857142yb便利 T0.023809523809523808yaな T0.023809523809523808ydクレート T0.023809523809523808yaを T0.047619047619047616yc見つけ T0.023809523809523808yaた T0.023809523809523808yaの S0.07142857142857142ya、 S0.07142857142857142yb紹介 T0.023809523809523808yaが T0.023809523809523808yaて S0.09523809523809523yaら T0.023809523809523808yb自分 T0.023809523809523808ybメモ T0.023809523809523808ybため T0.023809523809523808yaに T0.047619047619047616ycブログ T0.023809523809523808yb残し T0.023809523809523808ydおきます T0.023809523809523808ya。 T0.023809523809523808ya  T0.047619047619047616yeそもそもの T0.023809523809523808yb問題 T0.023809523809523808yb処理 T0.023809523809523808yb書い T0.023809523809523808yaい T0.023809523809523808ybなん T0.023809523809523808>vb55<ydRust T0.022727272727272728yaで S0.06818181818181818yb言語 T0.022727272727272728yb処理 T0.022727272727272728yd100本 T0.022727272727272728ycノック T0.022727272727272728yaの T0.045454545454545456ya第 T0.045454545454545456yb4章 T0.045454545454545456yaす T0.022727272727272728ya。 S0.09090909090909091ya  S0.11363636363636363yb前回 T0.022727272727272728yaは S0.06818181818181818ycこちら T0.022727272727272728yb今回 T0.022727272727272728yb早め T0.022727272727272728yaに T0.022727272727272728yb続き T0.022727272727272728yaを T0.022727272727272728ydやりまし T0.022727272727272728yaた T0.022727272727272728ya「 T0.022727272727272728ye形態素解析 T0.022727272727272728ya」 T0.022727272727272728ydですしね T0.022727272727272728yb概要 T0.022727272727272728yb吾輩 T0.022727272727272728ya猫 T0.022727272727272728ybある T0.022727272727272728>vb56<ydRust T0.021739130434782608yaで S0.06521739130434782yb言語 T0.021739130434782608yb処理 T0.021739130434782608yd100本 T0.021739130434782608ycノック T0.021739130434782608yaの T0.021739130434782608ya第 T0.021739130434782608yb3章 T0.021739130434782608yaす T0.021739130434782608ya。 S0.15217391304347827ya  S0.06521739130434782yb前回 T0.021739130434782608yaは T0.043478260869565216ycこちら T0.021739130434782608yb少し T0.021739130434782608ya間 T0.043478260869565216yaが S0.06521739130434782yd空きまし T0.021739130434782608yaた S0.06521739130434782ya、 T0.021739130434782608yb再開 T0.021739130434782608yaし T0.021739130434782608ybまし T0.021739130434782608yb空い T0.021739130434782608yb理由 T0.021739130434782608ya「 T0.021739130434782608yd正規表現 T0.021739130434782608ya」 T0.021739130434782608ycすかね T0.021739130434782608>vb57<yb負荷 S0.02631578947368421yaを S0.05263157894736842yb計測 S0.02631578947368421ybする S0.02631578947368421ybため S0.02631578947368421yaに S0.02631578947368421ya、 S0.10526315789473684yb数回 S0.02631578947368421yeAzure S0.02631578947368421ya  S0.07894736842105263yiCognitive S0.02631578947368421yfSearch S0.02631578947368421yaの S0.02631578947368421yeクラスター S0.02631578947368421yb起動 S0.02631578947368421yaし S0.05263157894736842ybたり S0.02631578947368421yb停止 S0.02631578947368421ycたりし S0.02631578947368421yaて S0.02631578947368421ybまし S0.02631578947368421yaた S0.02631578947368421ya。 S0.02631578947368421ybこれ S0.02631578947368421yaは S0.02631578947368421yiTerraform S0.02631578947368421yaで S0.02631578947368421ybやる S0.02631578947368421yaと S0.02631578947368421ya楽 S0.02631578947368421ybでき S0.02631578947368421>vb58<yb先日 T0.023255813953488372yaは T0.023255813953488372ya「 T0.023255813953488372ydシステム T0.023255813953488372yaの T0.046511627906976744yb特徴 T0.023255813953488372yaと T0.023255813953488372yb検索 T0.023255813953488372yb機能 T0.023255813953488372ydについて T0.023255813953488372ya」 T0.023255813953488372ycという T0.023255813953488372yb感じ T0.046511627906976744yaで S0.06976744186046512ydふんわり T0.023255813953488372yd書きまし T0.023255813953488372yaた T0.046511627906976744ya。 T0.046511627906976744ya  T0.046511627906976744ybまぁ T0.023255813953488372ya、 T0.023255813953488372ya頭 T0.023255813953488372ya中 T0.023255813953488372ydぼんやり T0.023255813953488372yb考え T0.023255813953488372ybてる T0.023255813953488372ybこと T0.023255813953488372yaを T0.023255813953488372yb文章 T0.023255813953488372yaに T0.046511627906976744ybして T0.023255813953488372yaみ T0.023255813953488372yaす T0.023255813953488372ya他 T0.023255813953488372yaも T0.023255813953488372>vb59<yb今年e0.025yaのe0.075ya頭e0.025ybからd0.05ydシステムe0.025yd検索周りe0.025yaをe0.075yb手伝e0.025yaうe0.025yb仕事e0.025yfフリーランスe0.025ycとしてe0.025ybやっe0.025yaてd0.05yaいe0.025ybますe0.025ya。e0.025ya e0.025yb検索e0.025yb仕組e0.025yaみe0.025yb知れe0.025yaばe0.025yb知るe0.025ybほどe0.025yb面白e0.025yaくe0.025ybなっe0.025yaきe0.025yaたe0.025ycというe0.025yb理由e0.025yaにe0.025ybなるe0.025>vb60<yb前回 T0.013888888888888888yaの T0.041666666666666664yb記事 T0.013888888888888888yaは T0.013888888888888888ycこちら T0.013888888888888888ya。 T0.027777777777777776yc自分用 T0.013888888888888888ybメモ T0.013888888888888888yaな T0.013888888888888888yaで T0.013888888888888888ya、 T0.013888888888888888yb読み T0.027777777777777776ydにくいか T0.013888888888888888yaも T0.013888888888888888ybです T0.013888888888888888ya  R0.3194444444444444ydRust S0.06944444444444445ycthe S0.06944444444444445ydBook T0.013888888888888888yaを T0.013888888888888888yb始め T0.013888888888888888yaた T0.013888888888888888ydbook S0.05555555555555555ya- S0.05555555555555555ya第 S0.05555555555555555yb4章 T0.013888888888888888yb5章 T0.013888888888888888yb6章 T0.013888888888888888yb8章 T0.013888888888888888>vb61<yd6月7日 T0.027777777777777776yaの T0.027777777777777776ya週 T0.027777777777777776yaに S0.05555555555555555yb開催 S0.05555555555555555yaさ S0.05555555555555555yaれ S0.05555555555555555yaた S0.05555555555555555yfBerlin S0.05555555555555555ya  R0.1111111111111111yiBuzzwords S0.05555555555555555yeオンライン T0.027777777777777776yb出張 T0.027777777777777776yaし T0.027777777777777776yaて S0.05555555555555555ybまし T0.027777777777777776ya。 T0.027777777777777776yaと T0.027777777777777776yaは T0.027777777777777776ya? T0.027777777777777776ydベルリン T0.027777777777777776yaで T0.027777777777777776ybいる T0.027777777777777776ya、 T0.027777777777777776ycBig T0.027777777777777776>vb62<yjluceneutil S0.05405405405405406ya  S0.10810810810810811ya- S0.02702702702702703yeマニアック S0.02702702702702703yaな S0.08108108108108109ycツール S0.02702702702702703yaの S0.10810810810810811yfセットアップ S0.02702702702702703yb続き S0.02702702702702703yaで S0.05405405405405406yaす S0.02702702702702703ya。 S0.05405405405405406yb今回 S0.02702702702702703yaも S0.02702702702702703yb誰得 S0.02702702702702703ya? S0.02702702702702703ycブログ S0.02702702702702703yb興味 S0.02702702702702703ybない S0.02702702702702703yb場合 S0.02702702702702703yaは S0.02702702702702703yb飛ば S0.02702702702702703yeしましょう S0.02702702702702703yb一応 S0.02702702702702703ya、 S0.02702702702702703ydREAD S0.02702702702702703>vb63<ya0 S0.02702702702702703ya6 S0.02702702702702703ya8 S0.02702702702702703yfLucene S0.05405405405405406yaの S0.08108108108108109ycFST S0.02702702702702703yb修正 S0.02702702702702703yaに S0.02702702702702703yb関連 S0.02702702702702703yaし S0.02702702702702703yaて S0.05405405405405406ya、 S0.02702702702702703yhKuromoji S0.02702702702702703ygパフォーマンス S0.02702702702702703yb問題 S0.05405405405405406yaが S0.02702702702702703ya出 S0.02702702702702703ybいる S0.02702702702702703ybよう S0.02702702702702703yaで S0.05405405405405406yaす S0.02702702702702703ya。 S0.02702702702702703ya  S0.05405405405405406ybこの S0.02702702702702703yb自体 S0.02702702702702703yaは S0.02702702702702703ya. S0.05405405405405406yb以降 S0.02702702702702703yb直る S0.02702702702702703>vb64<yeAzure S0.02702702702702703ya  S0.05405405405405406yiCognitive S0.02702702702702703yfSearch S0.02702702702702703yaで S0.02702702702702703yc日本語 S0.02702702702702703yaを S0.05405405405405406yb扱う S0.02702702702702703ybとき S0.02702702702702703yaに S0.02702702702702703ya、 S0.05405405405405406yf形態素解析器 S0.02702702702702703yb使い S0.02702702702702703ybたい S0.02702702702702703yb場合 S0.02702702702702703yc2種類 S0.02702702702702703yaの S0.05405405405405406yhAnalyzer S0.02702702702702703yaが S0.05405405405405406yb用意 S0.02702702702702703yaさ S0.02702702702702703yaれ S0.02702702702702703yaて S0.02702702702702703yaい S0.02702702702702703ybます S0.02702702702702703ya。 S0.02702702702702703yb今回 S0.02702702702702703yaは S0.02702702702702703ycこれら S0.02702702702702703yb違い S0.02702702702702703ybどん S0.02702702702702703ycなもの S0.02702702702702703>vb65<yb前回 T0.013888888888888888yaの T0.041666666666666664yb記事 T0.013888888888888888yaは T0.013888888888888888ycこちら T0.013888888888888888ya。 T0.027777777777777776yc自分用 T0.013888888888888888ybメモ T0.013888888888888888yaな T0.013888888888888888yaで T0.013888888888888888ya、 T0.013888888888888888yb読み T0.027777777777777776ydにくいか T0.013888888888888888yaも T0.013888888888888888ybです T0.013888888888888888ya  R0.3194444444444444ydRust S0.06944444444444445ycthe S0.06944444444444445ydBook T0.013888888888888888yaを T0.013888888888888888yb始め T0.013888888888888888yaた T0.013888888888888888ydbook S0.05555555555555555ya- S0.05555555555555555ya第 S0.05555555555555555yb4章 T0.013888888888888888yb5章 T0.013888888888888888yb6章 T0.013888888888888888yb8章 T0.013888888888888888>vb66<yb前回 T0.013888888888888888yaの T0.041666666666666664yb記事 T0.013888888888888888yaは T0.013888888888888888ycこちら T0.013888888888888888ya。 T0.027777777777777776yc自分用 T0.013888888888888888ybメモ T0.013888888888888888yaな T0.013888888888888888yaで T0.013888888888888888ya、 T0.013888888888888888yb読み T0.027777777777777776ydにくいか T0.013888888888888888yaも T0.013888888888888888ybです T0.013888888888888888ya  R0.3194444444444444ydRust S0.06944444444444445ycthe S0.06944444444444445ydBook T0.013888888888888888yaを T0.013888888888888888yb始め T0.013888888888888888yaた T0.013888888888888888ydbook S0.05555555555555555ya- S0.05555555555555555ya第 S0.05555555555555555yb4章 T0.013888888888888888yb5章 T0.013888888888888888yb6章 T0.013888888888888888yb8章 T0.013888888888888888>vb67<yb今回g0.03125yaはg0.03125yeAzuref0.0625ya e0.125yiCognitivef0.0625yfSearchf0.0625yaのf0.0625ycSDKg0.03125yaをg0.03125yb利用g0.03125yaしf0.0625yaたg0.03125yhアプリケーションg0.03125yaがg0.03125ya、g0.03125yb実際g0.03125yaにg0.03125ycに対しg0.03125yaてf0.0625yb送信g0.03125ybいるg0.03125yeリクエストg0.03125yeパラメータg0.03125>vb68<yiMircosoft T0.029411764705882353ya  S0.11764705882352941yeBuild T0.029411764705882353ycという T0.029411764705882353ydイベント T0.029411764705882353yaが T0.029411764705882353yb今週 T0.029411764705882353ydありまし T0.029411764705882353yaた T0.058823529411764705ya( T0.058823529411764705ybMS T0.029411764705882353yaの T0.058823529411764705yb方や T0.029411764705882353yaお T0.029411764705882353yc客さん T0.029411764705882353yaに T0.029411764705882353yb教え T0.029411764705882353yaて T0.029411764705882353ycもらっ T0.029411764705882353ya) T0.029411764705882353ya。 T0.029411764705882353ycそこで T0.029411764705882353ya、 T0.029411764705882353yeAzure T0.029411764705882353yiCognitive T0.029411764705882353yfSearch T0.029411764705882353yeセッション T0.029411764705882353yfMyBuil T0.029411764705882353>vb69<ya0 S0.02857142857142857ya1 S0.02857142857142857ya2 S0.02857142857142857ya7 S0.05714285714285714ygElastic S0.05714285714285714yaの S0.05714285714285714yiWorkplace S0.02857142857142857ya  S0.05714285714285714yfSearch S0.02857142857142857yaを S0.02857142857142857yb触っ S0.02857142857142857yaて S0.08571428571428572yaみ S0.02857142857142857ycいます S0.02857142857142857ya( S0.02857142857142857ybその S0.05714285714285714ya、 S0.05714285714285714ya) S0.02857142857142857yaが S0.05714285714285714yeStack S0.02857142857142857ya. S0.05714285714285714ydリリース S0.02857142857142857yaさ S0.02857142857142857yaれ S0.02857142857142857yaし S0.02857142857142857>vb70<yb前回 T0.013888888888888888yaの T0.041666666666666664yb記事 T0.013888888888888888yaは T0.013888888888888888ycこちら T0.013888888888888888ya。 T0.027777777777777776yc自分用 T0.013888888888888888ybメモ T0.013888888888888888yaな T0.013888888888888888yaで T0.013888888888888888ya、 T0.013888888888888888yb読み T0.027777777777777776ydにくいか T0.013888888888888888yaも T0.013888888888888888ybです T0.013888888888888888ya  R0.3194444444444444ydRust S0.06944444444444445ycthe S0.06944444444444445ydBook T0.013888888888888888yaを T0.013888888888888888yb始め T0.013888888888888888yaた T0.013888888888888888ydbook S0.05555555555555555ya- S0.05555555555555555ya第 S0.05555555555555555yb4章 T0.013888888888888888yb5章 T0.013888888888888888yb6章 T0.013888888888888888yb8章 T0.013888888888888888>vb71<ydRust T0.023255813953488372yaで S0.06976744186046512yb言語 T0.023255813953488372yb処理 T0.046511627906976744yd100本 T0.023255813953488372ycノック T0.023255813953488372yaの T0.046511627906976744ya第 T0.023255813953488372yb2章 T0.023255813953488372yb残り T0.023255813953488372yaす T0.046511627906976744ya。 S0.06976744186046512ya  S0.06976744186046512yb前回 T0.023255813953488372yaは S0.06976744186046512ycこちら T0.023255813953488372yaち T0.023255813953488372ybなみ T0.023255813953488372yaに T0.046511627906976744ya、 T0.023255813953488372yd標準入力 T0.023255813953488372ybから T0.023255813953488372yb受け T0.023255813953488372yb取る T0.023255813953488372yb書い T0.023255813953488372yaて T0.046511627906976744ybない T0.023255813953488372yb出力 T0.023255813953488372yb関し T0.023255813953488372ydファイル T0.023255813953488372>vb72<ya1 S0.02564102564102564yc気づい S0.02564102564102564ybたら S0.02564102564102564ydヶ月サボ S0.02564102564102564yaっ S0.02564102564102564yaて S0.02564102564102564ybまし S0.02564102564102564yaた S0.05128205128205128ya、 S0.02564102564102564ycごめん S0.02564102564102564ycなさい S0.02564102564102564ya。 R0.1282051282051282ya  S0.07692307692307693ydRust S0.02564102564102564yaで S0.02564102564102564yb言語 S0.02564102564102564yb処理 S0.02564102564102564yd100本 S0.02564102564102564ycノック S0.02564102564102564yaの S0.05128205128205128ya第 S0.02564102564102564yb2章 S0.02564102564102564yaを S0.02564102564102564yaは S0.05128205128205128ydじめまし S0.02564102564102564yb前回 S0.02564102564102564ycこちら S0.02564102564102564yc確認用 S0.02564102564102564ydUnix S0.02564102564102564ybコマ S0.02564102564102564>vb73<ydRust T0.017857142857142856yaで T0.017857142857142856yb言語 T0.017857142857142856yb処理 T0.017857142857142856yd100本 T0.017857142857142856ycノック T0.017857142857142856yaの S0.05357142857142857yhリファクタリング T0.017857142857142856yb続き T0.017857142857142856ya。 S0.08928571428571429ya  S0.16071428571428573yb前回 T0.017857142857142856yaは T0.017857142857142856ycこちら T0.017857142857142856ycとっく T0.017857142857142856yaに S0.03571428571428571yc終わっ T0.017857142857142856yaて S0.03571428571428571yaた S0.03571428571428571ya、 T0.017857142857142856yeブログ書い T0.017857142857142856ycなかっ T0.017857142857142856yb08 T0.017857142857142856ya. T0.017857142857142856yc暗号文 T0.017857142857142856ycpub T0.017857142857142856ybfn T0.017857142857142856yfcipher T0.017857142857142856ya( T0.017857142857142856ydtext T0.017857142857142856ya: T0.017857142857142856ya& T0.017857142857142856ycamp T0.017857142857142856ya; S0.03571428571428571ycstr T0.017857142857142856ya) T0.017857142857142856yb-& T0.017857142857142856ybgt T0.017857142857142856>vb74<ya5 S0.03225806451612903yd2020 S0.03225806451612903yb前回 S0.03225806451612903yaは S0.06451612903225806yiWorkplace S0.03225806451612903ya  S0.03225806451612903yfSearch S0.03225806451612903yaの S0.03225806451612903yb概要 S0.03225806451612903ydについて S0.06451612903225806yd書きまし S0.03225806451612903yaた S0.03225806451612903yaが S0.03225806451612903ya、 S0.06451612903225806yb今回 S0.03225806451612903yfインストール S0.03225806451612903yaと S0.03225806451612903yb構成 S0.03225806451612903yb要素 S0.03225806451612903yb説明 S0.03225806451612903yaし S0.03225806451612903ybます S0.03225806451612903ya。 S0.03225806451612903ybなお S0.03225806451612903ya/ S0.06451612903225806yc7時点 S0.03225806451612903yaで S0.03225806451612903>vb75<yb2月 T0.037037037037037035yaの S0.07407407407407407ygElastic T0.037037037037037035ya社 T0.037037037037037035ycブログ T0.037037037037037035yaで T0.037037037037037035yaす T0.037037037037037035yaが T0.037037037037037035ya、 T0.037037037037037035yjEnterprise T0.037037037037037035ya  S0.07407407407407407yfSearch S0.07407407407407407yaと T0.037037037037037035ybこれ T0.037037037037037035ybまで T0.037037037037037035yb呼ん T0.037037037037037035ybでい T0.037037037037037035yaた T0.037037037037037035yb製品 T0.037037037037037035yaを T0.037037037037037035yiWorkplace T0.037037037037037035ycという T0.037037037037037035yc製品名 T0.037037037037037035yaに T0.037037037037037035>vb76<yb先日 T0.030303030303030304ya、 S0.06060606060606061ymElasticsearch T0.030303030303030304yaで T0.030303030303030304yaの S0.12121212121212122ydカスタム T0.030303030303030304yb辞書 S0.09090909090909091yb利用 T0.030303030303030304yb方法 S0.06060606060606061ydについて S0.06060606060606061ycブログ T0.030303030303030304yaを T0.030303030303030304yd書きまし T0.030303030303030304yaた S0.06060606060606061ya。 T0.030303030303030304ya  T0.030303030303030304yb設定 T0.030303030303030304yb記載 T0.030303030303030304yaし T0.030303030303030304ybまし T0.030303030303030304yaが T0.030303030303030304yb今回 T0.030303030303030304yaは T0.030303030303030304yb更新 T0.030303030303030304>vb77<ymElasticsearchd0.08yaでd0.04yc日本語d0.04yaをd0.08yb扱うd0.04ybときd0.04yaにd0.04ya、d0.04ydカスタムd0.04yb辞書d0.04yb使いd0.04ybたいd0.04ycというd0.04yb要望d0.04yaがd0.04ybよくd0.04ydありますd0.04ya。d0.04ya d0.08ycAWSd0.04yaのd0.04yeServid0.04>vb78<yb前回 T0.014705882352941176yaの S0.04411764705882353yb記事 T0.014705882352941176yaは T0.029411764705882353ycこちら T0.014705882352941176ya。 T0.029411764705882353yc自分用 T0.014705882352941176ybメモ T0.014705882352941176yaな T0.014705882352941176yaで T0.014705882352941176ya、 T0.014705882352941176yb読み T0.029411764705882353ydにくいか T0.014705882352941176yaも T0.014705882352941176ybです T0.014705882352941176ya  S0.29411764705882354ydRust T0.058823529411764705ycthe T0.058823529411764705ydBook T0.014705882352941176yaを T0.014705882352941176yb始め T0.014705882352941176yaた T0.014705882352941176ydbook S0.04411764705882353ya- S0.04411764705882353ya第 T0.058823529411764705yb4章 T0.014705882352941176yb5章 T0.014705882352941176yb6章 T0.014705882352941176yb8章 T0.014705882352941176yb7章 T0.014705882352941176yaパ T0.014705882352941176>vb79<ydRuste0.025yaでe0.025yb言語e0.025yb処理e0.025yd100本e0.025ycノックe0.025yaのd0.05yhリファクタリングe0.025yb続きe0.025ya。e0.075ya d0.15yb前回e0.025yaはd0.05ycこちらd0.05ycコードe0.025yaもe0.025yb載せe0.025yaたe0.025ybほうe0.025yaがe0.025yb見やe0.025ycすいかe0.025ybなぁe0.025ya?e0.025yb03e0.025ya.e0.025yc円周率e0.025yb2年e0.025ya前e0.025ydどちらかe0.025>vb80<yb今回g0.03125yaもg0.03125ydツイートg0.03125ybからg0.03125ya。f0.0625ya g0.03125yd言語処理g0.03125yd100本g0.03125ycノックg0.03125yaのg0.09375ye2020年g0.03125ya版g0.03125yaをf0.0625yb公開g0.03125yaしf0.0625ybましg0.03125yaたg0.03125yb最近g0.03125yf自然言語処理g0.03125yb研究g0.03125yb動向g0.03125yb反映g0.03125ya、g0.03125yb深層g0.03125ykニューラルネットワークg0.03125yaにg0.03125ya関g0.03125>vb81<yb前回 T0.017241379310344827yaの S0.05172413793103448yb記事 T0.017241379310344827yaは T0.017241379310344827ycこちら T0.017241379310344827ya。 S0.05172413793103448yc自分用 T0.017241379310344827ybメモ T0.017241379310344827yaな T0.017241379310344827yaで T0.017241379310344827ya、 T0.017241379310344827yb読み T0.034482758620689655ydにくいか T0.017241379310344827yaも T0.017241379310344827ybです T0.034482758620689655ya  S0.25862068965517243ydRust S0.05172413793103448ycthe S0.05172413793103448ydBook T0.017241379310344827yaを T0.017241379310344827yb始め T0.017241379310344827yaた T0.017241379310344827ydbook T0.034482758620689655ya- T0.034482758620689655ya第 S0.05172413793103448yb4章 T0.017241379310344827yb5章 T0.017241379310344827yb6章 T0.017241379310344827ydEnum T0.017241379310344827ydmatc T0.017241379310344827>vb82<yhKuromoji S0.06896551724137931ya- T0.034482758620689655ycCLI S0.06896551724137931yaの S0.10344827586206896yb使い T0.034482758620689655ya方 T0.034482758620689655ybなど T0.034482758620689655ydについて T0.034482758620689655yaは T0.034482758620689655yb過去 T0.034482758620689655ycブログ T0.034482758620689655yaを T0.034482758620689655yb御覧 T0.034482758620689655yaく T0.034482758620689655yaだ T0.034482758620689655ybさい T0.034482758620689655ya。 T0.034482758620689655ya  S0.06896551724137931ydコマンド T0.034482758620689655yaと S0.06896551724137931ygpicocli T0.034482758620689655ygGraalVM T0.034482758620689655yaG T0.034482758620689655>vb83<yb前回 T0.018867924528301886yaの S0.05660377358490566yb記事 T0.018867924528301886yaは T0.018867924528301886ycこちら T0.018867924528301886ya。 S0.05660377358490566yc自分用 T0.018867924528301886ybメモ T0.018867924528301886yaな T0.018867924528301886yaで S0.03773584905660377ya、 T0.018867924528301886yb読み S0.03773584905660377ydにくいか T0.018867924528301886yaも T0.018867924528301886ybです T0.018867924528301886ya  S0.18867924528301888ydRust S0.03773584905660377ycthe S0.03773584905660377ydBook T0.018867924528301886yaを T0.018867924528301886yb始め T0.018867924528301886yaた T0.018867924528301886ydbook T0.018867924528301886ya- T0.018867924528301886ya第 S0.03773584905660377yb4章 T0.018867924528301886yb5章 T0.018867924528301886yc構造体 T0.018867924528301886yaす T0.018867924528301886yd勝手知っ T0.018867924528301886ybたる T0.018867924528301886ybなん T0.018867924528301886yaと T0.018867924528301886ybやら T0.018867924528301886ya? T0.018867924528301886>vb84<yeすもけさんe0.025yaがe0.025yf在宅勤務環境e0.025yaをe0.025ycブログe0.025yaにe0.025yb書いd0.05yaてe0.075ydおもしろe0.025ybそうe0.025yaだe0.025yaなd0.05ya(e0.025ybあとe0.025ya、e0.025yfアフィリンクe0.025ya貼e0.025ybれるe0.025ya)e0.025yaとe0.025yb思っe0.025yaたe0.025yaのd0.05yaでe0.025yb自分e0.025yb環境e0.025yaもe0.025yaみe0.025ybようe0.025yaかe0.025ybなとe0.025ya。e0.025ya e0.025yc私自身e0.025yaはe0.025>vb85<yb前回 T0.020833333333333332yaのf0.0625yb記事 T0.020833333333333332yaは T0.020833333333333332ycこちら T0.020833333333333332ya。f0.0625yc自分用 T0.020833333333333332ybメモ T0.020833333333333332yaな T0.041666666666666664yaで T0.041666666666666664ya、 T0.041666666666666664yb読み T0.041666666666666664ydにくいか T0.020833333333333332yaも T0.020833333333333332ybです T0.020833333333333332ya  S0.10416666666666667ydRust T0.020833333333333332ycthe T0.020833333333333332ydBook T0.020833333333333332yaを T0.020833333333333332yb始め T0.020833333333333332yaた T0.020833333333333332ya第 T0.041666666666666664yb4章 T0.041666666666666664yaす T0.020833333333333332ycたぶん T0.020833333333333332ybこれ T0.020833333333333332yaが T0.020833333333333332ydいちばん T0.020833333333333332yb大事 T0.020833333333333332yb概念 T0.020833333333333332yaだ T0.020833333333333332yaと T0.020833333333333332ya思 T0.020833333333333332>vb86<yb先日 S0.02702702702702703ya、 S0.02702702702702703yfVisual S0.02702702702702703ya  S0.16216216216216217yfStudio S0.02702702702702703ydCode S0.02702702702702703yaの S0.02702702702702703yeプラグイン S0.05405405405405406yaを S0.08108108108108109yb作っ S0.05405405405405406yaて S0.05405405405405406yaみ S0.02702702702702703yaた S0.08108108108108109ya( S0.02702702702702703yeAzure S0.02702702702702703yfSearch S0.02702702702702703ygAnalyze S0.02702702702702703yfClient S0.02702702702702703ya) S0.02702702702702703ycという S0.02702702702702703ycブログ S0.02702702702702703yd書きまし S0.02702702702702703ya。 S0.02702702702702703ybこの S0.02702702702702703ydタイミン S0.02702702702702703>vb87<yd自転車本 S0.02127659574468085yaを R0.0851063829787234yb読み S0.02127659574468085yd始めまし S0.02127659574468085yaた R0.0425531914893617yaが R0.0425531914893617ya、 R0.0425531914893617ybその S0.02127659574468085ya前 S0.02127659574468085yaに R0.0425531914893617ydRust R0.0425531914893617ya  R0.0851063829787234ycthe R0.0425531914893617ydbook R0.0425531914893617yb読ん S0.02127659574468085yaだ S0.02127659574468085ybほう S0.02127659574468085yc良いか S0.02127659574468085yaも S0.02127659574468085ya? S0.02127659574468085yaと R0.0425531914893617yb知り S0.02127659574468085yb合い S0.02127659574468085ya話 S0.02127659574468085yaし S0.02127659574468085yaて R0.0425531914893617yaい S0.02127659574468085ybなっ S0.02127659574468085yaの S0.02127659574468085yaで S0.02127659574468085ya先 S0.02127659574468085ya読 S0.02127659574468085>vb88<yb動機 T0.024390243902439025ya  R0.0975609756097561yeAzure T0.024390243902439025yiCognitive T0.024390243902439025yfSearch T0.024390243902439025yaを S0.07317073170731707yb検索 S0.04878048780487805ydエンジン T0.024390243902439025yaに T0.024390243902439025yb使っ T0.024390243902439025yaて S0.07317073170731707ybいる T0.024390243902439025yaお T0.024390243902439025yc客さん T0.024390243902439025yc手伝っ T0.024390243902439025ycいます T0.024390243902439025ya。 T0.024390243902439025ycそこで T0.024390243902439025ya、 T0.024390243902439025yaの T0.024390243902439025yb基本 T0.024390243902439025ya的 T0.024390243902439025yaな T0.024390243902439025ya話 T0.024390243902439025ybさせ T0.024390243902439025yaい T0.024390243902439025yaた S0.04878048780487805ydだきまし T0.024390243902439025ya( T0.024390243902439025ydもともと T0.024390243902439025ydJJUG T0.024390243902439025ybナイ T0.024390243902439025>vb89<ybこれ S0.02564102564102564ybまで S0.02564102564102564ya  R0.1282051282051282yb実践 S0.07692307692307693ydRust S0.05128205128205128yb入門 S0.05128205128205128yaは S0.02564102564102564ydじめまし S0.02564102564102564yaた S0.05128205128205128yaの S0.05128205128205128yb3章 S0.07692307692307693yaを S0.02564102564102564yb読ん S0.02564102564102564ybでる S0.02564102564102564yaと S0.02564102564102564ybころ S0.02564102564102564yb終了 S0.02564102564102564ye終わりまで S0.02564102564102564yb読み S0.02564102564102564yb終え S0.02564102564102564ya。 S0.02564102564102564ydいきなり S0.02564102564102564ya的 S0.02564102564102564yaな S0.02564102564102564yeプログラム S0.02564102564102564yaで S0.02564102564102564ya少 S0.02564102564102564>vb90<yhKuromoji S0.03571428571428571ya- S0.03571428571428571ycCLI S0.03571428571428571ya  S0.03571428571428571ydRust S0.03571428571428571yc初心者 S0.03571428571428571yaが S0.07142857142857142yeRust製 S0.07142857142857142yaの S0.10714285714285714yi日本語形態素解析器 S0.03571428571428571yb開発 S0.03571428571428571yaを S0.03571428571428571yb引き S0.03571428571428571yb継い S0.03571428571428571ybでみ S0.03571428571428571yaた S0.03571428571428571ycという S0.07142857142857142yb記事 S0.03571428571428571yaに S0.03571428571428571ydあります S0.03571428571428571ya、 S0.03571428571428571ygLindera S0.03571428571428571yg日本語形態素解 S0.03571428571428571>vb91<ybこれ T0.023255813953488372ybまで T0.023255813953488372yaの S0.09302325581395349yaは T0.046511627906976744ycこちら T0.023255813953488372ya。 S0.06976744186046512yb読書 T0.023255813953488372ybメモ T0.023255813953488372yaな T0.023255813953488372yaで S0.06976744186046512ya、 T0.023255813953488372ya本 T0.023255813953488372yaと T0.023255813953488372yd合わせて T0.023255813953488372yb読ん T0.046511627906976744ybでい T0.023255813953488372yaた T0.046511627906976744ybだく T0.023255813953488372yaが T0.023255813953488372yb良い T0.023255813953488372yaす T0.023255813953488372ya  S0.06976744186046512yb実践 T0.023255813953488372ydRust T0.023255813953488372yb入門 T0.023255813953488372ydじめまし T0.023255813953488372yb3章 T0.023255813953488372ygクイックツアー T0.023255813953488372yaを T0.023255813953488372ybます T0.023255813953488372yaバ T0.023255813953488372>vb92<yb49 S0.02040816326530612ybもう S0.02040816326530612ye2020年 S0.02040816326530612yb2月 S0.02040816326530612yaに T0.061224489795918366ybなっ S0.02040816326530612yaて T0.061224489795918366ycしまっ S0.02040816326530612ybます S0.02040816326530612yaが S0.02040816326530612ya、 S0.02040816326530612ye2019年 S0.02040816326530612yb買っ S0.02040816326530612yb便利 S0.02040816326530612ybだっ S0.02040816326530612yaた S0.04081632653061224ybもの S0.04081632653061224yc良かっ S0.02040816326530612yaを S0.02040816326530612ydいくつか S0.02040816326530612yb記録 S0.02040816326530612yb残し S0.02040816326530612yaと S0.02040816326530612ybこう S0.02040816326530612yaか S0.02040816326530612ybなと S0.02040816326530612ya。 S0.02040816326530612ya  S0.14285714285714285yfBRAVIA S0.02040816326530612ybKJ S0.02040816326530612ya- S0.02040816326530612yc55X S0.02040816326530612ye9500G S0.02040816326530612yfAmazon S0.02040816326530612ya| S0.02040816326530612ycソニー S0.02040816326530612ydSONY S0.02040816326530612>vb93<ya1 T0.029411764705882353ya2 T0.029411764705882353ya3 T0.029411764705882353ya4 T0.029411764705882353ya5 T0.029411764705882353ygブログ移行日記 S0.14705882352941177ya( S0.14705882352941177ybその S0.14705882352941177ya) S0.11764705882352941ybです T0.029411764705882353ya。 T0.029411764705882353yb前回 T0.029411764705882353ybまで T0.029411764705882353yaは T0.029411764705882353ycこちら T0.029411764705882353ya  S0.11764705882352941>vb94<yaお S0.04878048780487805yc手伝い T0.024390243902439025yaし S0.04878048780487805yaて S0.07317073170731707ybいる T0.024390243902439025yc客さん T0.024390243902439025yaが T0.024390243902439025yeAzure S0.04878048780487805ya  S0.14634146341463414yiCognitive S0.04878048780487805yfSearch S0.04878048780487805yaを S0.04878048780487805yb利用 T0.024390243902439025ybます T0.024390243902439025ya。 T0.024390243902439025yd検索周り T0.024390243902439025ya= T0.024390243902439025yaに T0.024390243902439025yc関する T0.024390243902439025yb手伝 T0.024390243902439025yaい T0.024390243902439025ybする T0.024390243902439025ya形 T0.024390243902439025yaで T0.024390243902439025yb入っ T0.024390243902439025ybおり T0.024390243902439025ya、 T0.024390243902439025ybいく T0.024390243902439025>vb95<ybまたe0.025ya、e0.075ydツイートd0.05ybからe0.025yc始まるe0.025yaおe0.025ya話e0.025yaでd0.05yaすe0.025ya。d0.05ya d0.05ydまだまだe0.025yb検索e0.025ydシステムe0.025yaっe0.025yaてd0.05ybどんe0.025ydなものかe0.025yaをd0.05yb勉強e0.025yaしd0.05ycたいしe0.025ycというe0.025ybことe0.025ybこんe0.025yaなe0.025yaのe0.025ybましe0.025yaたe0.025ya「e0.025yd検索シスe0.025>vb96<yb年末 S0.02564102564102564ya、 S0.02564102564102564yc何種類 S0.02564102564102564yaか S0.02564102564102564yaの S0.07692307692307693yfボードゲーム S0.05128205128205128yaを S0.07692307692307693yb家族 S0.07692307692307693yaで S0.05128205128205128ye楽しみまし S0.02564102564102564yaた S0.02564102564102564ya。 S0.05128205128205128ya  S0.05128205128205128yb感想 S0.02564102564102564yb交え S0.02564102564102564yaて S0.02564102564102564yb簡単 S0.02564102564102564yaに S0.02564102564102564yb紹介 S0.02564102564102564yaし S0.02564102564102564ycようか S0.02564102564102564yaと S0.02564102564102564yd思います S0.02564102564102564yaや S0.02564102564102564yb知人 S0.02564102564102564yb購入 S0.02564102564102564ybする S0.02564102564102564ybとき S0.02564102564102564ya参 S0.02564102564102564>vb97<yb実践 T0.043478260869565216ydRust T0.043478260869565216yb入門 T0.043478260869565216ycという T0.021739130434782608ya本 T0.021739130434782608yaを T0.043478260869565216yb買っ T0.021739130434782608yaて T0.043478260869565216yaい T0.021739130434782608yaた T0.043478260869565216ya( T0.021739130434782608yb去年 T0.021739130434782608yaの S0.06521739130434782yb7月 T0.021739130434782608yaだ T0.021739130434782608ya。 S0.08695652173913043ya) T0.021739130434782608ybです T0.021739130434782608yaが T0.021739130434782608ya、 T0.043478260869565216yb積ん T0.021739130434782608yaで T0.043478260869565216ybあっ T0.021739130434782608yb時間 T0.021739130434782608yb作っ T0.021739130434782608yb読み T0.021739130434782608yb始め T0.021739130434782608ybよう T0.021739130434782608yaか T0.021739130434782608yaと T0.021739130434782608ya  T0.021739130434782608ya[ T0.021739130434782608yc言語仕 T0.021739130434782608>vb98<yc12月 S0.02564102564102564yaに S0.02564102564102564yb退職 S0.02564102564102564ycします S0.02564102564102564ycブログ S0.02564102564102564yaを S0.07692307692307693yd書きまし S0.02564102564102564yaた S0.07692307692307693yaが S0.02564102564102564ya、 S0.05128205128205128yeその後どう S0.02564102564102564ybなっ S0.02564102564102564ybのか S0.02564102564102564ya? S0.02564102564102564ycという S0.02564102564102564ya話 S0.02564102564102564ybして S0.02564102564102564ybない S0.02564102564102564yaな S0.02564102564102564yaと S0.05128205128205128yb思っ S0.02564102564102564yaの S0.05128205128205128yaで S0.02564102564102564yd一応現在 S0.02564102564102564yb状況 S0.02564102564102564yb書き S0.02564102564102564yb留め S0.02564102564102564yaて S0.02564102564102564yeおこううか S0.02564102564102564ya。 S0.02564102564102564ya  S0.02564102564102564yb結論 S0.02564102564102564>vb99<ya1 S0.02857142857142857ya2 S0.02857142857142857ya3 S0.02857142857142857ya4 S0.02857142857142857ygブログ移行日記 S0.14285714285714285ya( S0.14285714285714285ybその S0.14285714285714285ya) S0.11428571428571428ybです S0.02857142857142857ya。 S0.05714285714285714ya他 S0.02857142857142857yaの S0.02857142857142857yb記事 S0.02857142857142857yaは S0.02857142857142857ycこちら S0.02857142857142857ya  S0.11428571428571428>vc100<ya1 S0.02857142857142857ya2 S0.02857142857142857ya3 S0.02857142857142857ya4 S0.02857142857142857ygブログ移行日記 S0.14285714285714285ya( S0.14285714285714285ybその S0.14285714285714285ya) S0.11428571428571428ybです S0.02857142857142857ya。 S0.05714285714285714ya他 S0.02857142857142857yaの S0.02857142857142857yb記事 S0.02857142857142857yaは S0.02857142857142857ycこちら S0.02857142857142857ya  S0.11428571428571428>vc101<ya1 T0.027777777777777776ya2 T0.027777777777777776ya3 T0.027777777777777776ya4 T0.027777777777777776ya5 T0.027777777777777776ybその S0.16666666666666666ya他 T0.027777777777777776yaの T0.027777777777777776yb記事 T0.027777777777777776yaは T0.027777777777777776ycこちら T0.027777777777777776ya  R0.1388888888888889ygブログ移行日記 R0.1388888888888889ya( R0.1388888888888889ya) R0.1388888888888889>vc102<ya2 T0.027777777777777776ya3 T0.027777777777777776ya4 T0.027777777777777776ya5 T0.027777777777777776ybその R0.1388888888888889ya他 T0.027777777777777776yaの T0.027777777777777776yb記事 T0.027777777777777776yaは T0.027777777777777776ycこちら T0.027777777777777776ya  S0.16666666666666666ygブログ移行日記 R0.1111111111111111ya( R0.1111111111111111ya) R0.1111111111111111yb起因 T0.027777777777777776ydいつもの T0.027777777777777776ydツイート T0.027777777777777776ybから T0.027777777777777776>vc103<yb5年 S0.02702702702702703ycくらい S0.02702702702702703ya、 S0.10810810810810811yiOctopress S0.02702702702702703yaを S0.02702702702702703yb使用 S0.02702702702702703yaし S0.02702702702702703yaて S0.05405405405405406ycいまし S0.02702702702702703yaた S0.02702702702702703yaが S0.05405405405405406yb更新 S0.02702702702702703yaさ S0.02702702702702703yaれ S0.02702702702702703ybなく S0.02702702702702703ybなっ S0.02702702702702703ybいる S0.02702702702702703yaの S0.08108108108108109yaと S0.02702702702702703yeコンテンツ S0.02702702702702703yb生成 S0.02702702702702703yaに S0.02702702702702703yb時間 S0.02702702702702703ycかかる S0.02702702702702703ybこと S0.02702702702702703yaも S0.02702702702702703ybあり S0.02702702702702703ya  S0.02702702702702703ybほか S0.02702702702702703yfプラットフォ S0.02702702702702703>vc104<yb今年 T0.023255813953488372yaも T0.023255813953488372yb振り T0.046511627906976744yb返り T0.046511627906976744yeブログ書い T0.023255813953488372yaて T0.023255813953488372ybます T0.023255813953488372ya。 S0.11627906976744186yfSasuke T0.023255813953488372ycがつい T0.023255813953488372ybてる T0.023255813953488372ya  S0.11627906976744186ya（ T0.023255813953488372ye2018年 T0.023255813953488372yaに T0.046511627906976744yb書い T0.023255813953488372yaた T0.046511627906976744yb抱負 T0.046511627906976744ybから T0.023255813953488372ya） T0.023255813953488372ybまず T0.023255813953488372yaは T0.023255813953488372yb去年 T0.023255813953488372yaの T0.023255813953488372yaを T0.023255813953488372ya元 T0.023255813953488372yeTOEIC T0.023255813953488372yd受けまし T0.023255813953488372yaお T0.023255813953488372ybTO T0.023255813953488372>vc105<ybこの S0.02564102564102564ycブログ S0.02564102564102564ya書 S0.02564102564102564ybこう S0.02564102564102564yaと S0.02564102564102564yb思っ S0.02564102564102564yaて S0.07692307692307693ya、 S0.07692307692307693ybこれ S0.02564102564102564ybまで S0.02564102564102564ycMac S0.02564102564102564yaの S0.05128205128205128yfセットアップ S0.02564102564102564yaし S0.02564102564102564ybたん S0.02564102564102564ybだっ S0.02564102564102564yaた S0.02564102564102564ya。 S0.10256410256410256ya  S0.05128205128205128yb普段 S0.02564102564102564yemacOS S0.02564102564102564yb標準 S0.02564102564102564yeターミナル S0.05128205128205128yaを S0.05128205128205128yb使っ S0.02564102564102564ybます S0.02564102564102564yaで S0.02564102564102564yb使う S0.02564102564102564>vc106<yhドットファイル系 S0.02702702702702703ya（ S0.02702702702702703ya. S0.02702702702702703yeemacs S0.02702702702702703ybとか S0.05405405405405406ya） S0.02702702702702703yaを S0.05405405405405406ybこれ S0.02702702702702703ybまで S0.02702702702702703yaは S0.02702702702702703ya、 S0.08108108108108109ybPC S0.02702702702702703yb引っ S0.02702702702702703yb越す S0.02702702702702703ybたび S0.02702702702702703yaに S0.02702702702702703ycコピー S0.02702702702702703yaし S0.05405405405405406yaて S0.02702702702702703ybたん S0.02702702702702703yaで S0.08108108108108109yaす S0.02702702702702703yaが S0.02702702702702703yeいいかげん S0.02702702702702703yfGitHub S0.02702702702702703yb管理 S0.02702702702702703ybたい S0.02702702702702703ybなと S0.02702702702702703ya。 S0.02702702702702703ya  S0.02702702702702703>vc107<ygMacbook T0.030303030303030304ya  S0.06060606060606061ycPro T0.030303030303030304yaが S0.06060606060606061yc新しく T0.030303030303030304ybなり T0.030303030303030304ya、 S0.06060606060606061ybOS T0.030303030303030304yhCatalina T0.030303030303030304yaに T0.030303030303030304ygなっちゃいまし T0.030303030303030304yaた S0.06060606060606061ya。 T0.030303030303030304ybこれ T0.030303030303030304ybまで T0.030303030303030304yb使っ T0.030303030303030304yaて S0.06060606060606061ya. T0.030303030303030304ydbash T0.030303030303030304ya_ T0.030303030303030304ygprofile T0.030303030303030304yaを S0.06060606060606061ycコピー T0.030303030303030304yaし T0.030303030303030304yeターミナル T0.030303030303030304yb立ち T0.030303030303030304yb上げ T0.030303030303030304>vc108<yb16 T0.022222222222222223yd最近使っ T0.022222222222222223yaて S0.06666666666666667yaい T0.022222222222222223yaた S0.06666666666666667ybPC T0.022222222222222223yaが T0.022222222222222223yb手元 T0.022222222222222223ybから T0.022222222222222223ybなく T0.022222222222222223ybなっ T0.022222222222222223yaの T0.044444444444444446yaで S0.08888888888888889ya、 T0.044444444444444446ycインチ T0.022222222222222223ya  S0.06666666666666667ygMacbook T0.022222222222222223ycPro T0.022222222222222223yaを T0.022222222222222223yfセットアップ T0.022222222222222223yaし T0.022222222222222223ybいる T0.022222222222222223yaと T0.022222222222222223ybころ T0.022222222222222223yaす T0.022222222222222223ya。 T0.022222222222222223yb時間 T0.022222222222222223yaも T0.022222222222222223ybある T0.022222222222222223ybこれ T0.022222222222222223ybまで T0.022222222222222223ybほっ T0.022222222222222223ydたらかし T0.022222222222222223yaき T0.022222222222222223>vc109<ya5 T0.024390243902439025yb本日 T0.024390243902439025ya、 S0.07317073170731707ygElastic T0.024390243902439025yaで S0.12195121951219512yaの S0.04878048780487805ye最終出社日 T0.024390243902439025yaし T0.024390243902439025yaた T0.024390243902439025ya。 S0.04878048780487805yb実際 T0.024390243902439025yc退職日 T0.024390243902439025yaは T0.024390243902439025ybまだ T0.024390243902439025ya先 T0.024390243902439025yaす S0.07317073170731707yaが S0.04878048780487805yd有休消化 T0.024390243902439025ycという T0.024390243902439025yb感じ T0.024390243902439025ya  T0.024390243902439025yb思い T0.024390243902439025yb返せ T0.024390243902439025yaば T0.024390243902439025ybもう T0.024390243902439025yb5年 T0.024390243902439025yaと T0.024390243902439025ycヶ月も T0.024390243902439025ya前 T0.024390243902439025ydElas T0.024390243902439025>vc110<ya4 S0.02040816326530612yd2019 S0.02040816326530612ybこれ S0.02040816326530612yaは S0.02040816326530612ya、 T0.061224489795918366yd情報検索 S0.02040816326530612ya・ S0.02040816326530612yb検索 S0.02040816326530612ydエンジン S0.02040816326530612ya  S0.14285714285714285yfAdvent S0.02040816326530612yhCalendar S0.02040816326530612yaの S0.08163265306122448yb日目 S0.02040816326530612yb記事 S0.04081632653061224yaで S0.02040816326530612yaす S0.02040816326530612ya。 S0.02040816326530612yc1日目 S0.02040816326530612ybから S0.02040816326530612ya質 S0.02040816326530612yb高い S0.02040816326530612yeエントリー S0.02040816326530612yaが S0.04081632653061224yb続い S0.02040816326530612yaて T0.061224489795918366ycいまし S0.02040816326530612yaた S0.02040816326530612yd一旦休憩 S0.02040816326530612yaし S0.02040816326530612yb頂く S0.02040816326530612yb感じ S0.02040816326530612yaに S0.02040816326530612ybなっ S0.02040816326530612>vc111<ya1 R0.0196078431372549yd2019 R0.0196078431372549ygElastic R0.0196078431372549ya  S0.11764705882352941yestack R0.0196078431372549ya( R0.0196078431372549ymElasticsearch R0.0196078431372549ya) R0.0196078431372549yfAdvent R0.0196078431372549yhCalendar R0.0196078431372549yaの R0.0392156862745098yc1日目 R0.0196078431372549yb記事 R0.0196078431372549yaに R0.0392156862745098ydなります R0.0196078431372549ya。 R0.0392156862745098ybまだ R0.0196078431372549ya、 T0.058823529411764705ybヶ月 R0.0196078431372549yaを R0.0392156862745098yb残し R0.0196078431372549yaて R0.0392156862745098ybます R0.0196078431372549yaが R0.0196078431372549yb簡単 R0.0196078431372549yc今年起 R0.0196078431372549ybこっ R0.0196078431372549yaた R0.0196078431372549ybこと R0.0196078431372549yb振り R0.0196078431372549yb返っ R0.0196078431372549yaみ R0.0196078431372549ybよう R0.0196078431372549yaと R0.0196078431372549yd思います R0.0196078431372549yb毎年 R0.0196078431372549yb恒例 R0.0196078431372549yaで R0.0196078431372549ybすね R0.0196078431372549>vc112<ya1 T0.010416666666666666yb10 T0.010416666666666666yb19 T0.010416666666666666yb21 T0.010416666666666666yb25 T0.010416666666666666yb30 T0.010416666666666666yd2019 T0.010416666666666666yf148121 T0.010416666666666666ygBonfire T0.010416666666666666ya d0.25ydData T0.020833333333333332ya& T0.020833333333333332ycamp T0.020833333333333332ya; T0.020833333333333332ygScience T0.020833333333333332ya# T0.020833333333333332yaに T0.010416666666666666ycブログ T0.010416666666666666ya枠 T0.010416666666666666yaで T0.020833333333333332yb参加 T0.010416666666666666yaし T0.010416666666666666yaて T0.010416666666666666ycきまし T0.010416666666666666yaた T0.010416666666666666ya。 T0.020833333333333332ycという T0.010416666666666666ybこと T0.010416666666666666ya、 T0.010416666666666666ybメモ T0.010416666666666666ybです T0.010416666666666666yb日時 T0.010416666666666666ya:f0.0625ya/f0.0625yb00 T0.010416666666666666ya- T0.020833333333333332yb場所 T0.010416666666666666yeYahoo T0.010416666666666666ya! T0.010416666666666666yeJapan T0.010416666666666666ycサイト T0.010416666666666666yehttps T0.010416666666666666yb:/ T0.010416666666666666ybyj T0.010416666666666666yfmeetup T0.010416666666666666ya. T0.020833333333333332yhconnpass T0.010416666666666666yccom T0.010416666666666666yeevent T0.010416666666666666yfハッシュタグ T0.010416666666666666yiyjbonfire T0.010416666666666666yb概要 T0.010416666666666666yaと T0.010416666666666666>vc113<ya7 S0.03571428571428571ybこの S0.03571428571428571ya間 S0.03571428571428571yaの S0.07142857142857142y PElasticsearch勉強会 S0.03571428571428571yaで S0.07142857142857142yiAcroquest S0.03571428571428571ya  S0.03571428571428571yjTechnology S0.03571428571428571ya人 S0.03571428571428571ybたち S0.03571428571428571yaが S0.03571428571428571yb技術 S0.03571428571428571yb書展 S0.03571428571428571yb販売 S0.03571428571428571yaさ S0.03571428571428571yaれ S0.03571428571428571yaて S0.07142857142857142yaい S0.03571428571428571yaた S0.07142857142857142yb書籍 S0.03571428571428571yaを S0.03571428571428571yb頂い S0.03571428571428571yeしまいまし S0.03571428571428571>vc114<ygTwitter S0.02702702702702703yaで S0.08108108108108109ya「 S0.02702702702702703yfMeetup S0.02702702702702703ya. S0.02702702702702703yccom S0.02702702702702703yaに S0.05405405405405406yb切り S0.02702702702702703yb替え S0.02702702702702703ycたらー S0.02702702702702703ya」 S0.02702702702702703yaみ S0.02702702702702703ybたい S0.02702702702702703yaな S0.02702702702702703ya話 S0.05405405405405406yaが S0.02702702702702703ybあっ S0.02702702702702703yaた S0.05405405405405406yaの S0.05405405405405406ya、 S0.05405405405405406ya  S0.02702702702702703yc受付用 S0.02702702702702703ycアプリ S0.02702702702702703yaと S0.02702702702702703ycかなく S0.02702702702702703yaて S0.02702702702702703ycという S0.02702702702702703ybなっ S0.02702702702702703yb普段 S0.02702702702702703yfElasti S0.02702702702702703>vc115<y PElasticsearch勉強会 T0.034482758620689655yaや T0.034482758620689655yg検索技術勉強会 T0.034482758620689655ybやっ S0.10344827586206896ybてる S0.10344827586206896yaん S0.06896551724137931ycだけど T0.034482758620689655ya、 S0.06896551724137931yb独学 T0.034482758620689655yaで T0.034482758620689655yc勉強会 T0.034482758620689655ybなー T0.034482758620689655yaと S0.06896551724137931yb思い T0.034482758620689655ybみん T0.034482758620689655yaな T0.034482758620689655yaは T0.034482758620689655ybどう T0.034482758620689655ycだろう T0.034482758620689655ydツイート T0.034482758620689655yaし T0.034482758620689655yaて T0.034482758620689655>vc116<ya2 T0.021739130434782608yb26 T0.021739130434782608ybどー T0.021739130434782608yaも T0.021739130434782608ya、 T0.043478260869565216ygjohtani T0.021739130434782608ybです T0.021739130434782608ya。 T0.043478260869565216ya  S0.10869565217391304yfSearch T0.021739130434782608ykEngineering T0.021739130434782608ydTech T0.021739130434782608ydTalk T0.021739130434782608ycという T0.021739130434782608yc勉強会 T0.043478260869565216yaに T0.021739130434782608yb運営 T0.021739130434782608ycとして T0.021739130434782608yb参加 T0.021739130434782608yaし T0.043478260869565216yaて T0.021739130434782608ya第 T0.043478260869565216yb1回 T0.021739130434782608yaの T0.043478260869565216yaを T0.021739130434782608yb開始 T0.021739130434782608ybまし T0.021739130434782608yaた T0.043478260869565216yb本日 T0.021739130434782608ya（ T0.021739130434782608ya/ T0.021739130434782608ya） T0.021739130434782608yaは T0.021739130434782608yc1回目 T0.021739130434782608ybだっ T0.021739130434782608>vc117<yb今年 T0.022222222222222223yaも T0.022222222222222223yb振り T0.044444444444444446yb返り T0.044444444444444446ycブログ T0.022222222222222223yaを T0.044444444444444446ybかけ T0.022222222222222223yaて T0.022222222222222223ybます T0.022222222222222223ya。 T0.044444444444444446ycよかっ T0.022222222222222223yaた T0.044444444444444446yaw T0.022222222222222223ya  S0.08888888888888889ya（ T0.022222222222222223ye2017年 T0.022222222222222223yaに T0.044444444444444446yb書い T0.022222222222222223yb抱負 T0.044444444444444446ybから T0.022222222222222223ya） T0.022222222222222223ybまず T0.022222222222222223yaは T0.022222222222222223yb去年 T0.022222222222222223yaの T0.044444444444444446ya元 T0.022222222222222223ybもっ T0.022222222222222223yaと T0.022222222222222223yb英語 T0.022222222222222223yb継続 T0.022222222222222223ya＆ T0.022222222222222223yeTOEIC T0.022222222222222223ybまぁ T0.022222222222222223ya、 T0.022222222222222223>vc118<yd2018 T0.020833333333333332ygElastic T0.020833333333333332ya  S0.16666666666666666yestack T0.020833333333333332ya( T0.020833333333333332ymElasticsearch T0.020833333333333332ya) T0.020833333333333332yfAdvent T0.041666666666666664yhCalendar T0.041666666666666664yaのf0.0625yd25日目 T0.020833333333333332yb記事 T0.020833333333333332yaに T0.041666666666666664ydなります T0.020833333333333332ya。 T0.020833333333333332yb今年 T0.020833333333333332yb最後 T0.020833333333333332yaで T0.020833333333333332yaす T0.020833333333333332ya！ T0.041666666666666664yb来年 T0.020833333333333332yaも T0.020833333333333332yb忘れ T0.020833333333333332yaて T0.020833333333333332ybなけ T0.020833333333333332yaれ T0.020833333333333332yaば T0.020833333333333332ybやる T0.020833333333333332yaは T0.041666666666666664yaず T0.020833333333333332yb今日 T0.020833333333333332ya、 T0.020833333333333332ybすで T0.020833333333333332ycalp T0.020833333333333332>vc119<ya1 R0.0196078431372549yd2018 R0.0196078431372549ygElastic R0.0196078431372549ya  S0.13725490196078433yestack R0.0196078431372549ya( R0.0196078431372549ymElasticsearch R0.0196078431372549ya) R0.0196078431372549yfAdvent R0.0196078431372549yhCalendar R0.0196078431372549yaの R0.0392156862745098yc1日目 R0.0196078431372549yb記事 R0.0196078431372549yaに R0.0392156862745098ydなります R0.0196078431372549ya。 R0.0784313725490196ycちょっ R0.0196078431372549yaと R0.0196078431372549yb遅れ R0.0196078431372549yeちゃいまし R0.0196078431372549yaた R0.0392156862745098ybまだ R0.0196078431372549ya、 R0.0392156862745098ybヶ月 R0.0196078431372549yaを R0.0392156862745098yb残し R0.0196078431372549yaて R0.0392156862745098ybます R0.0196078431372549yaが R0.0196078431372549yb簡単 R0.0196078431372549yc今年起 R0.0196078431372549ybこっ R0.0196078431372549ybこと R0.0196078431372549yb振り R0.0196078431372549yb返っ R0.0196078431372549ybみよ R0.0196078431372549>vc120<ya4 T0.022727272727272728ya（ T0.022727272727272728yb転職 T0.045454545454545456ybする T0.045454545454545456yb少し T0.022727272727272728yc前まで T0.022727272727272728yeパスポート T0.022727272727272728ybすら T0.022727272727272728yb持っ T0.022727272727272728yaて S0.06818181818181818ycなかっ T0.022727272727272728yaた T0.022727272727272728yaの S0.09090909090909091yaに S0.06818181818181818ya） T0.022727272727272728ya今 T0.022727272727272728yb会社 T0.022727272727272728yaし T0.022727272727272728ybから T0.022727272727272728ya、 T0.022727272727272728yb半年 T0.022727272727272728yb1度 T0.022727272727272728yb割合 T0.022727272727272728yaで T0.022727272727272728yb海外 T0.022727272727272728yaへ T0.022727272727272728yb出張 T0.022727272727272728yaが T0.022727272727272728yb発生 T0.022727272727272728yb生活 T0.022727272727272728yaを T0.022727272727272728yb送っ T0.022727272727272728ycいます T0.022727272727272728ya。 T0.022727272727272728ya  T0.022727272727272728>vc121<yd毎月開催 S0.02564102564102564yaの S0.10256410256410256yc2回目 S0.02564102564102564yaに S0.02564102564102564ydなります S0.02564102564102564ya。 S0.05128205128205128ya  S0.05128205128205128yb今回 S0.02564102564102564yaは S0.02564102564102564yb日経 S0.02564102564102564ybさん S0.02564102564102564yb会場 S0.02564102564102564yaを S0.05128205128205128yaお S0.02564102564102564yb借り S0.02564102564102564ybして S0.02564102564102564yb開催 S0.02564102564102564yaと S0.02564102564102564ydなりまし S0.02564102564102564yaた S0.02564102564102564yb前回 S0.02564102564102564ybから S0.02564102564102564ya、 S0.02564102564102564yeスピーカー S0.02564102564102564yb募集 S0.02564102564102564ydhttp S0.02564102564102564yb:/ S0.02564102564102564ya/ S0.05128205128205128ycbit S0.02564102564102564ya. S0.02564102564102564ybly S0.02564102564102564ybSp S0.02564102564102564>vc122<ya7 S0.02702702702702703yb25 S0.02702702702702703ya/ S0.02702702702702703yaに S0.05405405405405406ydJJUG S0.02702702702702703ygナイトセミナー S0.02702702702702703yaで S0.08108108108108109ygElastic S0.02702702702702703ya  S0.08108108108108109yeStack S0.02702702702702703yaの S0.13513513513513514yb紹介 S0.05405405405405406yaと S0.02702702702702703ycAPM S0.02702702702702703ydJava S0.02702702702702703yeAgent S0.02702702702702703yaを S0.02702702702702703yaし S0.02702702702702703yaた S0.02702702702702703ya、 S0.02702702702702703yb補足 S0.02702702702702703ycブログ S0.02702702702702703yaす S0.02702702702702703ya。 S0.02702702702702703ya（ S0.02702702702702703yb久々 S0.02702702702702703yb書く S0.02702702702702703>vc123<yc第2回g0.03125ybからg0.03125yb少しg0.03125ya間g0.03125yaがg0.09375yb空いg0.03125yaてg0.03125yeしまいましg0.03125yaたf0.0625ya、g0.03125yhtemplateg0.03125yaでf0.0625yb作成g0.03125yaしg0.03125yeプラグインg0.03125yaのg0.03125yfディレクトリg0.03125yb構成g0.03125yaとg0.03125ydどういうg0.03125yb流れg0.03125ycデータg0.03125ybやりg0.03125yb取りg0.03125yaさg0.03125ybれるg0.03125yaかg0.03125ycについg0.03125>vc124<ya# T0.024390243902439025yhMANABIYA T0.024390243902439025ya  S0.04878048780487805yaの S0.07317073170731707ycブース T0.024390243902439025yaで S0.07317073170731707yeセッション T0.024390243902439025yb時間 T0.024390243902439025yb合間 T0.024390243902439025yaは T0.024390243902439025yaお T0.024390243902439025yc客さん T0.024390243902439025ya少 T0.024390243902439025ybない T0.024390243902439025ya、 S0.04878048780487805ycブログ T0.024390243902439025yaを T0.024390243902439025yb書い T0.024390243902439025yaて T0.024390243902439025yaみ T0.024390243902439025ybたり T0.024390243902439025ya。 T0.024390243902439025ybここ T0.024390243902439025yb数年 T0.024390243902439025yeスポンサー T0.024390243902439025ycとして T0.024390243902439025yb色々 T0.024390243902439025yaな T0.024390243902439025ygカンファレンス T0.024390243902439025yaに T0.024390243902439025yb参加 T0.024390243902439025yaし T0.024390243902439025ybてる T0.024390243902439025yaん T0.024390243902439025yaす T0.024390243902439025>vc125<ydRust T0.020833333333333332yaで S0.08333333333333333yb言語 T0.020833333333333332yb処理 T0.020833333333333332yd100本 T0.020833333333333332ycノック T0.020833333333333332yaの T0.041666666666666664yb続き T0.020833333333333332ya、 T0.041666666666666664yb05 T0.041666666666666664yaと T0.041666666666666664yb06 T0.020833333333333332yaす T0.020833333333333332ya。f0.0625ya  S0.08333333333333333ya. T0.020833333333333332yan T0.041666666666666664ya- T0.041666666666666664ydgram T0.041666666666666664yb問題 T0.020833333333333332yaは T0.020833333333333332ycこちら T0.020833333333333332ybみん T0.020833333333333332yaな T0.020833333333333332yb大好 T0.020833333333333332yaき T0.020833333333333332ybです T0.020833333333333332yb単語 T0.020833333333333332yb文字 T0.020833333333333332yaが T0.020833333333333332ybある T0.020833333333333332ydそれぞれ T0.020833333333333332yb別関 T0.020833333333333332>vc126<ydRust S0.02631578947368421yaで S0.10526315789473684yb言語 S0.02631578947368421yb処理 S0.02631578947368421yd100本 S0.02631578947368421ycノック S0.02631578947368421yaの S0.02631578947368421yb続き S0.02631578947368421ya、 S0.02631578947368421yb03 S0.05263157894736842yaと S0.02631578947368421yb04 S0.02631578947368421yaす S0.02631578947368421ya。 S0.05263157894736842ya  S0.10526315789473684ya. S0.05263157894736842yc円周率 S0.02631578947368421yb問題 S0.02631578947368421yaは S0.02631578947368421ycこちら S0.02631578947368421ye入力文字列 S0.02631578947368421yaを S0.02631578947368421yesplit S0.02631578947368421ya_ S0.02631578947368421yjwhitespace S0.02631578947368421yb() S0.02631578947368421yb分割 S0.02631578947368421yaし S0.02631578947368421yaて S0.02631578947368421>vc127<ya「 T0.024390243902439025ya鉄 T0.024390243902439025yaは S0.04878048780487805yd熱いうち T0.024390243902439025yaに T0.024390243902439025yb打て T0.024390243902439025ya」 T0.024390243902439025ycという T0.024390243902439025ybこと T0.024390243902439025yaで T0.024390243902439025ya、 S0.04878048780487805yd言語処理 T0.024390243902439025yd100本 T0.024390243902439025ycノック T0.024390243902439025yaの S0.07317073170731707ya第 T0.024390243902439025yb1章 T0.024390243902439025yb00 T0.024390243902439025ybから T0.024390243902439025yb02 T0.024390243902439025yaを T0.024390243902439025yb実装 T0.024390243902439025yaし T0.024390243902439025yaて T0.024390243902439025ycみまし T0.024390243902439025yaた T0.024390243902439025ya。 T0.024390243902439025ya  T0.024390243902439025ybさて S0.04878048780487805ybこれ T0.024390243902439025yaが S0.04878048780487805yb効率 T0.024390243902439025ybいい T0.024390243902439025ydかどうか T0.024390243902439025yaお T0.024390243902439025>vc128<ybども T0.020833333333333332ya。 S0.08333333333333333yc新しい T0.020833333333333332ybもの T0.020833333333333332yb始め T0.020833333333333332ybない T0.020833333333333332yaと T0.020833333333333332ya頭 T0.020833333333333332yaが T0.020833333333333332yb退化 T0.020833333333333332ybする T0.020833333333333332ycという T0.020833333333333332ybこと T0.020833333333333332yaで T0.020833333333333332ya、 T0.041666666666666664ycこちら T0.020833333333333332ya（ T0.020833333333333332ya  S0.16666666666666666yehappy T0.020833333333333332ycnew T0.041666666666666664ydyear T0.020833333333333332ycand T0.020833333333333332yhlanguage T0.020833333333333332ya- T0.020833333333333332yikatsyoshi T0.020833333333333332ydのめもみ T0.020833333333333332ybたい T0.020833333333333332ycなもの T0.020833333333333332ya） T0.020833333333333332yaの T0.020833333333333332ycブログ T0.020833333333333332yaに T0.020833333333333332yb触発 T0.020833333333333332yaさ T0.020833333333333332yaれ T0.020833333333333332yaて T0.020833333333333332>vc129<yc第1回 S0.02564102564102564yaで S0.07692307692307693yaは S0.05128205128205128ya、 S0.07692307692307693ygAnalyze S0.02564102564102564ya  S0.05128205128205128ybUI S0.02564102564102564ycという S0.02564102564102564yeプラグイン S0.05128205128205128yaの S0.07692307692307693yb紹介 S0.02564102564102564yaを S0.07692307692307693ycしまし S0.02564102564102564yaた S0.02564102564102564ybごく S0.02564102564102564yb簡単 S0.02564102564102564yaに S0.02564102564102564yaす S0.02564102564102564yaが S0.02564102564102564ya。 S0.02564102564102564ya第 S0.02564102564102564yb2回 S0.02564102564102564yfKibana S0.02564102564102564yb作成 S0.02564102564102564yb方法 S0.02564102564102564ya順 S0.02564102564102564yb追っ S0.02564102564102564yaて S0.02564102564102564>vc130<ydあけまし S0.02564102564102564yaて S0.05128205128205128ybおめ S0.02564102564102564yaで S0.05128205128205128ygとうございます S0.02564102564102564ya。 S0.05128205128205128yb今年 S0.02564102564102564yaは S0.02564102564102564ybサボ S0.02564102564102564yaり S0.02564102564102564ydがちだっ S0.02564102564102564yaた S0.05128205128205128ycブログ S0.02564102564102564yaを S0.02564102564102564ycちょっ S0.02564102564102564ycとずつ S0.02564102564102564yb復活 S0.02564102564102564yaさ S0.02564102564102564yaせ S0.02564102564102564ybよう S0.02564102564102564yaか S0.02564102564102564yaと S0.02564102564102564ya  S0.02564102564102564ycという S0.02564102564102564ybこと S0.02564102564102564ya、 S0.05128205128205128ya第 S0.02564102564102564yb1弾 S0.02564102564102564ycとして S0.02564102564102564yc昨年少 S0.02564102564102564yaし S0.02564102564102564yb作っ S0.02564102564102564yaい S0.02564102564102564yaK S0.02564102564102564>vc131<yb今年 T0.041666666666666664yaはf0.0625yb紅白 T0.020833333333333332yaを T0.041666666666666664yb見な T0.020833333333333332yaが T0.020833333333333332yaら T0.020833333333333332yb書い T0.041666666666666664yaて T0.020833333333333332ybます T0.020833333333333332ya。f0.0625ya  S0.08333333333333333ycいろん T0.020833333333333332yaな T0.020833333333333332yaと T0.020833333333333332ybころ T0.020833333333333332yaに S0.08333333333333333yb出張 T0.020833333333333332yb行っ T0.020833333333333332yaた T0.041666666666666664ybなぁ T0.020833333333333332yb振り T0.020833333333333332yb返り T0.020833333333333332ya（ T0.020833333333333332ye2016年 T0.020833333333333332yb抱負 T0.041666666666666664ybから T0.020833333333333332ya） T0.020833333333333332ybまず T0.020833333333333332yb去年 T0.020833333333333332yaの T0.020833333333333332ya元 T0.020833333333333332ycもちろ T0.020833333333333332>vc132<yd2017 T0.023809523809523808yeMerry T0.023809523809523808ya  S0.21428571428571427yiChristmas T0.023809523809523808ya! T0.023809523809523808ygElastic T0.047619047619047616yeStack T0.023809523809523808yfAdvent T0.023809523809523808yhCalendar T0.023809523809523808yaの S0.07142857142857142yd24日目 T0.023809523809523808yb記事 T0.023809523809523808yaに T0.023809523809523808ydなります T0.023809523809523808ya。 T0.047619047619047616ycちょっ T0.023809523809523808yaと T0.047619047619047616ybです T0.023809523809523808yaが T0.023809523809523808ya、 T0.023809523809523808ye2018年 T0.023809523809523808ydについて T0.023809523809523808yb書い T0.023809523809523808yaて T0.023809523809523808yaみ T0.023809523809523808ycようか T0.023809523809523808yd思います T0.023809523809523808ydイベント T0.023809523809523808ydいくつか T0.023809523809523808>vc133<ya1d0.02yd2017d0.02ygElasticd0.02ya d0.12yestackd0.02ya(d0.02ymElasticsearchd0.02ya)d0.02yfAdventd0.02yhCalendard0.02yaのd0.04yc1日目d0.02yb記事d0.02yaにd0.06ydなりますd0.02ya。d0.04ybまだd0.02ya、d0.04ybヶ月d0.02yaをd0.04yb残しd0.02yaてd0.04ycいますd0.02yaがd0.02yb簡単d0.02yc今年起d0.02ybこっd0.02yaたd0.04ybことd0.02yb振りd0.02yb返っd0.02yaみd0.02ycようかd0.02yaとd0.02yd思いますd0.02yb思っd0.02yb以上d0.02>vc134<yhSwiftype S0.08333333333333333yaで T0.041666666666666664ycサイト S0.08333333333333333yc内検索 S0.08333333333333333ya？ T0.041666666666666664ya  T0.041666666666666664ygプレスリリース T0.041666666666666664ya： T0.041666666666666664ygElastic T0.041666666666666664yaがe0.125ydサービス T0.041666666666666664yc最大手 T0.041666666666666664yaの T0.041666666666666664yaを T0.041666666666666664yb買収 T0.041666666666666664yc出まし T0.041666666666666664yaた T0.041666666666666664ya、 T0.041666666666666664yfSwifty T0.041666666666666664>vc135<yb久々 T0.024390243902439025yaに T0.024390243902439025yb執筆 T0.024390243902439025yaし T0.024390243902439025ybまし T0.024390243902439025yaた T0.024390243902439025ya。 S0.04878048780487805ydといって S0.04878048780487805yaも S0.04878048780487805ya、 S0.07317073170731707yb以前 T0.024390243902439025yaの S0.07317073170731707yb書籍 T0.024390243902439025yc更新版 S0.04878048780487805yaで T0.024390243902439025yaす T0.024390243902439025ya  T0.024390243902439025ybまぁ T0.024390243902439025yc私以外 T0.024390243902439025yb方々 T0.024390243902439025yaは T0.024390243902439025yb結構 T0.024390243902439025ybな量 T0.024390243902439025yaを T0.024390243902439025yb書き T0.024390243902439025yb直し T0.024390243902439025ybor T0.024390243902439025yd新規書き T0.024390243902439025yc起こし T0.024390243902439025yaさ T0.024390243902439025yaれ T0.024390243902439025yaて T0.024390243902439025ybます T0.024390243902439025>vc136<yb久々 S0.02564102564102564yaの S0.02564102564102564ycブログ S0.02564102564102564ya。 S0.05128205128205128ya  S0.07692307692307693y PElasticsearch勉強会 S0.02564102564102564yaを S0.05128205128205128yb主催 S0.02564102564102564yaし S0.05128205128205128yaて S0.07692307692307693ybます S0.02564102564102564yaが S0.02564102564102564ya、 S0.10256410256410256yeプロダクト S0.02564102564102564yb超え S0.02564102564102564yb検索 S0.02564102564102564yaで S0.02564102564102564yb共通 S0.02564102564102564ybある S0.05128205128205128yb課題 S0.02564102564102564yaと S0.05128205128205128yaか S0.05128205128205128yb悩み S0.02564102564102564ybとか S0.02564102564102564ybなぁ S0.02564102564102564ybその S0.02564102564102564>vc137<yb今年 T0.045454545454545456yaは S0.06818181818181818ycRio T0.022727272727272728yaの T0.045454545454545456yfプレイバック T0.022727272727272728ya T0.022727272727272728ya見 T0.022727272727272728ybなが T0.022727272727272728yaら T0.022727272727272728yb書い T0.045454545454545456yaて T0.022727272727272728ybます T0.022727272727272728ya。 T0.045454545454545456ya  S0.06818181818181818ycなんか T0.022727272727272728yb長い T0.022727272727272728yb一年 T0.022727272727272728ybだっ T0.022727272727272728yaた T0.045454545454545456ya気 T0.022727272727272728yaが T0.022727272727272728yb振り T0.022727272727272728yb返り T0.022727272727272728ya（ T0.022727272727272728ye2015年 T0.022727272727272728yaに T0.045454545454545456yb抱負 T0.045454545454545456ybから T0.022727272727272728ya） T0.022727272727272728ybまず T0.022727272727272728yb去年 T0.022727272727272728yaを T0.022727272727272728ya元 T0.022727272727272728>vc138<ya0 T0.015151515151515152ya1 T0.030303030303030304ya2 S0.09090909090909091ya5 T0.015151515151515152ya7 T0.015151515151515152yd2016 T0.015151515151515152yeMerry T0.015151515151515152ya  S0.21212121212121213yiChristmas T0.015151515151515152ya! T0.015151515151515152ygElastic T0.015151515151515152yestack T0.015151515151515152yfAdvent T0.015151515151515152yhCalendar T0.015151515151515152yc最終日 T0.015151515151515152yaの T0.030303030303030304yb記事 T0.015151515151515152yaに T0.030303030303030304ydなります T0.015151515151515152ya。 T0.030303030303030304yb簡単 T0.015151515151515152yb今年 T0.015151515151515152yb変遷 T0.015151515151515152yaを T0.015151515151515152yb振り T0.015151515151515152yb返っ T0.015151515151515152yaて T0.015151515151515152ycみます T0.015151515151515152ymElasticsearch T0.030303030303030304ya. S0.10606060606060606ya( T0.015151515151515152yb2月 T0.015151515151515152ya) T0.015151515151515152ya、 T0.030303030303030304ydリリース T0.015151515151515152yeクエリプロ T0.015151515151515152>vc139<ya0d0.02ya5d0.02ygElasticd0.02ya d0.14yestackd0.02yfAdventd0.02yhCalendard0.02yc1日目d0.02yaのd0.06yb記事d0.02yaにd0.04ydなりますd0.02ya。d0.04ymElasticsearchd0.02ya.d0.02yaがd0.04yd10月末d0.02ydリリースd0.04yaさd0.06yaれd0.06ybましd0.02yaたd0.02ycブログd0.02yeでいくつかd0.02yb紹介d0.04yaてd0.04ybいるd0.02yaでd0.02yaすd0.02ya、d0.02ycそこでd0.02yaはd0.02>vc140<yb久しe0.025ybぶりe0.025yaにe0.025ya、d0.05yb技術e0.025ya的e0.025yaなe0.025yeブログ書いe0.025yaてc0.1ybますe0.025ya。d0.05ya e0.075yfIngeste0.025yiProcessore0.025yaのd0.05yeプラグインe0.025yaをe0.025yb作っe0.025yaみe0.025ybたくe0.025ybなっe0.025yaたd0.05yaでe0.025yb書いd0.05ycみましe0.025ybただe0.025ybみるe0.025ycんじゃe0.025yc3番煎e0.025yaじe0.025>vc141<ycなんか T0.022727272727272728ya、 S0.06818181818181818yb今年 T0.022727272727272728yaは T0.022727272727272728ybよく T0.022727272727272728ya物 T0.022727272727272728yaが T0.045454545454545456yc壊れる T0.022727272727272728yb厄年 T0.022727272727272728yaだ T0.022727272727272728ycからか T0.022727272727272728ybなぁ T0.022727272727272728ya？ T0.022727272727272728ya  S0.06818181818181818ycという T0.022727272727272728ybこと T0.022727272727272728yaで T0.022727272727272728yb記念 T0.022727272727272728yaに T0.045454545454545456ya何 T0.022727272727272728yb壊れ T0.045454545454545456ybたか T0.022727272727272728yaを T0.022727272727272728ycブログ T0.022727272727272728yb残し T0.022727272727272728yaて T0.045454545454545456ycおこう T0.022727272727272728yaか T0.022727272727272728yaと T0.022727272727272728ya。 T0.022727272727272728yc腕時計 T0.022727272727272728ya（ T0.022727272727272728ycないか T0.022727272727272728yaな T0.022727272727272728ya） T0.022727272727272728yd電波腕時 T0.022727272727272728>vc142<yd第16回d0.04y PElasticsearch勉強会d0.04yaをd0.04yb開催d0.04yaしd0.08ybましd0.04yaたd0.12ya。d0.04ya d0.04ydスタッフd0.04yaのd0.08yc皆さんd0.08ya、d0.08yeスピーカーd0.04yd会場提供d0.04yaてd0.04yaいd0.04ybだいd0.04ylリクルートテクノロジーズd0.04>vc143<yd第15回d0.04y PElasticsearch勉強会d0.04yaをd0.04yb開催d0.04yaしd0.08ybましd0.04yaたd0.12ya。d0.04ya d0.04ydスタッフd0.04yaのd0.08yc皆さんd0.08ya、d0.08yeスピーカーd0.04yd会場提供d0.04yaてd0.04yaいd0.04ybだいd0.04ylリクルートテクノロジーズd0.04>vc144<yb久々 T0.043478260869565216yaの S0.10869565217391304ycポスト T0.021739130434782608ya。 S0.10869565217391304ya  T0.043478260869565216yaに T0.043478260869565216ya、 T0.043478260869565216yd技術書読 T0.021739130434782608yaん T0.021739130434782608yaで S0.06521739130434782ybます T0.021739130434782608ya「 T0.021739130434782608yf自然言語処理 T0.021739130434782608yb基本 T0.021739130434782608yaと T0.021739130434782608yb技術 T0.021739130434782608ya」 T0.021739130434782608ycという T0.021739130434782608ya本 T0.021739130434782608yaす T0.021739130434782608yb監修 T0.021739130434782608ya方 T0.021739130434782608ydツイート T0.021739130434782608yaを T0.021739130434782608yb見て T0.021739130434782608ya気 T0.021739130434782608ybなっ T0.021739130434782608yaた T0.043478260869565216yb買っ T0.021739130434782608yaて T0.021739130434782608ycみまし T0.021739130434782608>vc145<ydあけまし T0.037037037037037035yaて T0.037037037037037035ybおめ T0.037037037037037035yaで T0.037037037037037035ygとうございます T0.037037037037037035ya、 S0.07407407407407407ygjohtani T0.037037037037037035ybです T0.037037037037037035ya。 S0.07407407407407407ya  S0.07407407407407407ya第 T0.037037037037037035yc14回 T0.037037037037037035y PElasticsearch勉強会 T0.037037037037037035yaを T0.037037037037037035yb開催 T0.037037037037037035yaし T0.037037037037037035ybまし T0.037037037037037035yaた T0.037037037037037035ydスタッフ T0.037037037037037035yaの S0.07407407407407407yc皆さん T0.037037037037037035yeスピーカー T0.037037037037037035ya皆 T0.037037037037037035>vc146<yb今年 S0.02040816326530612yaは S0.04081632653061224yc紅白見 S0.02040816326530612yaな S0.02040816326530612yaが S0.02040816326530612yaら S0.02040816326530612yb書い S0.04081632653061224yaて S0.02040816326530612ybます S0.02040816326530612ya。 T0.061224489795918366ya  S0.10204081632653061yb早い S0.02040816326530612yb一年 S0.02040816326530612ybだっ S0.02040816326530612yaた S0.04081632653061224ybなぁ S0.02040816326530612yb振り S0.04081632653061224yb返り S0.04081632653061224ya( S0.02040816326530612ye2014年 S0.02040816326530612yaに S0.04081632653061224yb抱負 S0.04081632653061224ybから S0.02040816326530612ya) S0.02040816326530612ybまず S0.02040816326530612yb去年 S0.02040816326530612yaの T0.061224489795918366yaを S0.04081632653061224ya元 S0.02040816326530612yaば S0.02040816326530612yb英語 S0.02040816326530612yb継続 S0.02040816326530612yb海外 S0.02040816326530612>vc147<yd2015 T0.029411764705882353yb今年 T0.058823529411764705yb最後 T0.029411764705882353yaの S0.11764705882352941yfAdvent T0.058823529411764705ya  S0.17647058823529413yhCalendar T0.058823529411764705yaと T0.029411764705882353ydなります T0.029411764705882353ya。 T0.058823529411764705ybこの T0.029411764705882353yb記事 T0.029411764705882353yaは T0.029411764705882353ymElasticsearch T0.029411764705882353yc最終日 T0.029411764705882353ydエントリ T0.029411764705882353yaで T0.029411764705882353yaす T0.029411764705882353yb簡単 T0.029411764705882353yaに T0.029411764705882353yb変遷 T0.029411764705882353yaを T0.029411764705882353>vc148<ybこん T0.023255813953488372ybにち T0.023255813953488372yaは T0.023255813953488372ya、 S0.06976744186046512ya@ T0.023255813953488372ygjohtani T0.023255813953488372ybです T0.023255813953488372ya。 S0.13953488372093023ya  T0.046511627906976744yb早い T0.023255813953488372ybもの T0.023255813953488372yaで S0.06976744186046512yb師走 T0.023255813953488372yaす T0.023255813953488372yb今年 T0.023255813953488372yaも T0.023255813953488372ybあと T0.023255813953488372yb少し T0.023255813953488372yaと T0.023255813953488372ydなりまし T0.023255813953488372yaた T0.023255813953488372ya（ T0.023255813953488372yb今月 T0.023255813953488372yaが T0.046511627906976744yc一番忙 T0.023255813953488372yaし T0.023255813953488372ybかっ T0.023255813953488372yeたりします T0.023255813953488372ya） T0.023255813953488372ycという T0.023255813953488372ybこと T0.023255813953488372yaA T0.023255813953488372>vc149<yd第13回d0.04y PElasticsearch勉強会d0.04yaをd0.04yb開催d0.04yaしd0.08ybましd0.04yaたd0.12ya。d0.04ya d0.04ydスタッフd0.04yaのd0.08yc皆さんd0.08ya、d0.08yeスピーカーd0.04yd会場提供d0.04yaてd0.04yaいd0.04ybだいd0.04ylリクルートテクノロジーズd0.04>vc150<ya0 T0.034482758620689655ya1 T0.017241379310344827ya2 T0.017241379310344827ya※ T0.017241379310344827ybこの T0.017241379310344827yb記事 T0.017241379310344827yaは T0.017241379310344827ya次 T0.017241379310344827yaの T0.017241379310344827ycブログ T0.017241379310344827yaを T0.034482758620689655yb翻訳 T0.017241379310344827yaし T0.017241379310344827yaた T0.017241379310344827ybもの T0.017241379310344827yaに T0.017241379310344827ydなります T0.017241379310344827ya。 T0.017241379310344827ya  R0.1724137931034483yb原文 T0.017241379310344827ya： T0.017241379310344827ycThe T0.017241379310344827yeStory T0.017241379310344827ybof T0.017241379310344827yeSense S0.05172413793103448ya- T0.034482758620689655yjAnnouncing T0.017241379310344827ya. T0.034482758620689655ydbeta T0.017241379310344827yb誕生 T0.017241379310344827ybよく T0.017241379310344827ybある T0.017241379310344827yb良い T0.017241379310344827yfプロジェクト T0.017241379310344827yb同様 T0.017241379310344827ya、 T0.017241379310344827yaも T0.017241379310344827ycビール T0.017241379310344827yb飲み T0.017241379310344827yaな T0.017241379310344827yaが T0.017241379310344827yaら T0.017241379310344827ya考 T0.017241379310344827>vc151<ya0 S0.04081632653061224ya2 S0.02040816326530612yb10 S0.02040816326530612yb28 S0.02040816326530612ya※ S0.02040816326530612ybこの S0.02040816326530612yb記事 S0.02040816326530612yaは S0.02040816326530612ya次 S0.02040816326530612yaの S0.02040816326530612ycブログ S0.02040816326530612yaを S0.02040816326530612yb翻訳 S0.02040816326530612yaし S0.02040816326530612yaた S0.02040816326530612ybもの S0.02040816326530612yaに S0.02040816326530612ydなります S0.02040816326530612ya。 S0.02040816326530612ya  S0.16326530612244897yb原文 S0.02040816326530612ya： S0.02040816326530612yfShield S0.04081632653061224ya, S0.04081632653061224ygWatcher S0.04081632653061224ycand S0.02040816326530612yfMarvel S0.02040816326530612ya. S0.04081632653061224ybGA S0.02040816326530612yhReleased S0.02040816326530612yb本日 S0.02040816326530612ya（ S0.02040816326530612ya/ S0.02040816326530612ya） S0.02040816326530612ya、 S0.02040816326530612ycおよび S0.02040816326530612ydMarv S0.02040816326530612>vc152<ya0 S0.08333333333333333ya1 T0.020833333333333332ya2 T0.041666666666666664yb79 T0.020833333333333332yc477 T0.020833333333333332ya※ T0.020833333333333332ybこの T0.020833333333333332yb記事 T0.020833333333333332yaは T0.020833333333333332ya次 T0.020833333333333332yaのf0.0625ycブログ T0.020833333333333332yaを T0.020833333333333332yb翻訳 T0.020833333333333332yaし T0.020833333333333332yaた T0.020833333333333332ybもの T0.020833333333333332yaに T0.020833333333333332ydなります T0.020833333333333332ya。 T0.020833333333333332ya  S0.14583333333333334yb原文 T0.020833333333333332ya： T0.020833333333333332ymElasticsearch T0.041666666666666664ya. S0.08333333333333333ybGA T0.020833333333333332yhreleased T0.020833333333333332ydリリース T0.020833333333333332yb以降 T0.020833333333333332ya、 T0.020833333333333332yeコミッター T0.020833333333333332ya, T0.020833333333333332>vc153<ya0 T0.047619047619047616ya2 S0.06349206349206349ya4 T0.031746031746031744ya※ T0.015873015873015872ybこの T0.015873015873015872yb記事 T0.015873015873015872yaは T0.015873015873015872ya次 T0.015873015873015872yaの S0.06349206349206349ycブログ T0.015873015873015872yaを T0.015873015873015872yb翻訳 T0.015873015873015872yaし T0.015873015873015872yaた T0.015873015873015872ybもの T0.015873015873015872yaに T0.015873015873015872ydなります T0.015873015873015872ya。 T0.031746031746031744ya  S0.20634920634920634yb原文 T0.015873015873015872ya： T0.015873015873015872yfKibana T0.047619047619047616ya. S0.07936507936507936yhreleased T0.015873015873015872ymElasticsearch T0.031746031746031744ya+ T0.015873015873015872ya= T0.015873015873015872yb💚 T0.015873015873015872ydサポート T0.015873015873015872yb最初 T0.015873015873015872ydリリース T0.015873015873015872yaで T0.015873015873015872yaす T0.015873015873015872ybこれ T0.015873015873015872>vc154<ya0 S0.07692307692307693ya2 T0.038461538461538464yb10 T0.019230769230769232yb28 T0.019230769230769232ya※ T0.019230769230769232ybこの T0.038461538461538464yb記事 T0.019230769230769232yaは T0.038461538461538464ya次 T0.019230769230769232yaの T0.019230769230769232ycブログ T0.019230769230769232yaを T0.019230769230769232yb翻訳 T0.019230769230769232yaし T0.019230769230769232yaた T0.038461538461538464ybもの T0.019230769230769232yaに T0.019230769230769232ydなります T0.019230769230769232ya。 T0.038461538461538464ya  S0.11538461538461539yb原文 T0.019230769230769232ya： T0.019230769230769232yhLogstash T0.038461538461538464ya. S0.07692307692307693yhreleased T0.019230769230769232yaが T0.019230769230769232yb本日 T0.019230769230769232ya（ T0.019230769230769232ya/ T0.019230769230769232ya） T0.019230769230769232ydリリース T0.038461538461538464yaさ T0.019230769230769232yaれ T0.019230769230769232ybまし T0.019230769230769232>vc155<ya※ T0.044444444444444446ybこの T0.022222222222222223yb記事 T0.022222222222222223yaは T0.044444444444444446ya次 T0.022222222222222223yaの T0.022222222222222223ycブログ T0.022222222222222223yaを T0.044444444444444446yb翻訳 T0.022222222222222223yaし T0.022222222222222223yaた T0.022222222222222223ybもの T0.022222222222222223yaに S0.06666666666666667ydなります T0.022222222222222223ya。 T0.044444444444444446ya  R0.1111111111111111yb原文 T0.044444444444444446ya： T0.022222222222222223yfRelase T0.022222222222222223ya, T0.022222222222222223ybwe T0.022222222222222223ydhave T0.022222222222222223yb画像 T0.022222222222222223yb関し T0.022222222222222223yaて T0.022222222222222223yaご T0.022222222222222223yb覧く T0.022222222222222223yaだ T0.022222222222222223ybさい T0.022222222222222223ygElastic T0.022222222222222223ycとって T0.022222222222222223yb大き T0.022222222222222223yaな T0.022222222222222223yb1日 T0.022222222222222223>vc156<ya0 T0.041666666666666664ya1 T0.020833333333333332ya2f0.0625ya5 T0.020833333333333332ya9 T0.020833333333333332yb17 T0.020833333333333332ya※ T0.020833333333333332ybこの T0.020833333333333332yb記事 T0.020833333333333332yaは T0.020833333333333332ya次 T0.020833333333333332yaの T0.041666666666666664ycブログ T0.020833333333333332yaを T0.020833333333333332yb翻訳 T0.020833333333333332yaし T0.020833333333333332yaた T0.020833333333333332ybもの T0.020833333333333332yaに T0.020833333333333332ydなります T0.020833333333333332ya。 T0.020833333333333332ya  S0.10416666666666667yb原文 T0.020833333333333332ya： T0.020833333333333332ymElasticsearch T0.020833333333333332ya. S0.08333333333333333ya- T0.020833333333333332ydbeta T0.020833333333333332yhreleased T0.020833333333333332yb本日 T0.020833333333333332ya（ T0.020833333333333332ya/ T0.020833333333333332ya） T0.020833333333333332ya、 T0.020833333333333332yfLucene T0.020833333333333332ycベース T0.020833333333333332ydElas T0.020833333333333332>vc157<ya0 T0.024390243902439025ya2 T0.024390243902439025ya※ T0.024390243902439025ybこの T0.024390243902439025yb記事 T0.024390243902439025yaは T0.024390243902439025ya次 T0.024390243902439025yaの S0.04878048780487805ycブログ T0.024390243902439025yaを S0.04878048780487805yb翻訳 T0.024390243902439025yaし T0.024390243902439025yaた T0.024390243902439025ybもの T0.024390243902439025yaに T0.024390243902439025ydなります T0.024390243902439025ya。 T0.024390243902439025ya  R0.1951219512195122yb原文 T0.024390243902439025ya： T0.024390243902439025ymElasticsearch S0.04878048780487805yiunplugged T0.024390243902439025ya- T0.024390243902439025yjNetworking T0.024390243902439025ygchanges T0.024390243902439025ybin T0.024390243902439025ya. T0.024390243902439025ydローカル T0.024390243902439025ycマシン T0.024390243902439025yaで T0.024390243902439025ya起 T0.024390243902439025>vc158<ya0 T0.041666666666666664ya1 T0.041666666666666664ya2 T0.041666666666666664ya5 T0.020833333333333332ya8 T0.020833333333333332yb26 T0.020833333333333332ya※ T0.020833333333333332ybこの T0.020833333333333332yb記事 T0.020833333333333332yaは T0.020833333333333332ya次 T0.020833333333333332yaの T0.041666666666666664ycブログ T0.020833333333333332yaを T0.020833333333333332yb翻訳 T0.020833333333333332yaし T0.020833333333333332yaた T0.020833333333333332ybもの T0.020833333333333332yaに T0.020833333333333332ydなります T0.020833333333333332ya。 T0.020833333333333332ya  S0.10416666666666667yb原文 T0.020833333333333332ya： T0.020833333333333332ymElasticsearch T0.020833333333333332ya. S0.08333333333333333ya- T0.020833333333333332ydbeta T0.020833333333333332yhreleased T0.020833333333333332yb本日 T0.020833333333333332ya（ T0.020833333333333332ya/ T0.020833333333333332ya） T0.020833333333333332ya、 T0.020833333333333332yfLucene T0.020833333333333332ycベース T0.020833333333333332ydElas T0.020833333333333332>vc159<ya0 R0.0392156862745098ya1 R0.0196078431372549ya2 R0.0196078431372549ya※ R0.0196078431372549ybこの R0.0196078431372549yb記事 R0.0196078431372549yaは R0.0392156862745098ya次 R0.0196078431372549yaの R0.0392156862745098ycブログ R0.0196078431372549yaを R0.0196078431372549yb翻訳 R0.0196078431372549yaし R0.0196078431372549yaた R0.0196078431372549ybもの R0.0196078431372549yaに R0.0196078431372549ydなります R0.0196078431372549ya。 R0.0196078431372549ya  S0.19607843137254902yb原文 R0.0196078431372549ya： R0.0196078431372549ycThe R0.0196078431372549yfDelete R0.0196078431372549ybby R0.0196078431372549yeQuery R0.0196078431372549ycAPI R0.0196078431372549ybIs R0.0196078431372549ycnow R0.0196078431372549yaa R0.0196078431372549yfplugin R0.0196078431372549ymElasticsearch R0.0196078431372549ya. R0.0392156862745098ya- R0.0196078431372549ydbeta R0.0196078431372549yaで R0.0196078431372549ya、 R0.0196078431372549ybこれ R0.0196078431372549ybまで R0.0196078431372549>vc160<yd第11回d0.04y PElasticsearch勉強会d0.04yaをd0.04yb開催d0.04yaしd0.08ybましd0.04yaたd0.12ya。d0.04ya d0.04ydスタッフd0.04yaのd0.08yc皆さんd0.08ya、d0.08yeスピーカーd0.04yd会場提供d0.04yaてd0.04yaいd0.04ybだいd0.04ylリクルートテクノロジーズd0.04>vc161<ya1 S0.05660377358490566ya2 T0.018867924528301886ya4 S0.03773584905660377ya6 T0.018867924528301886ya7 S0.03773584905660377yb10 T0.018867924528301886yb29 T0.018867924528301886ya※ T0.018867924528301886ybこの T0.018867924528301886yb記事 T0.018867924528301886yaは T0.018867924528301886ya次 T0.018867924528301886yaの S0.03773584905660377ycブログ T0.018867924528301886yaを T0.018867924528301886yb翻訳 T0.018867924528301886yaし T0.018867924528301886yaた T0.018867924528301886ybもの T0.018867924528301886yaに T0.018867924528301886ydなります T0.018867924528301886ya。 T0.018867924528301886ya  R0.1320754716981132yb原文 T0.018867924528301886ya： T0.018867924528301886ymElasticsearch T0.018867924528301886ya. S0.11320754716981132ycand T0.018867924528301886yhreleased T0.018867924528301886yb本日 T0.018867924528301886ya（ T0.018867924528301886ya/ T0.018867924528301886ya） T0.018867924528301886ya、 T0.018867924528301886yfLucene T0.018867924528301886ycベース T0.018867924528301886yaE T0.018867924528301886>vc162<ya0 T0.018867924528301886ya1 S0.05660377358490566ya4 S0.03773584905660377ya6 T0.018867924528301886ya7 S0.03773584905660377yb10 T0.018867924528301886yb16 T0.018867924528301886ya※ T0.018867924528301886ybこの T0.018867924528301886yb記事 T0.018867924528301886yaは T0.018867924528301886ya次 T0.018867924528301886yaの S0.03773584905660377ycブログ T0.018867924528301886yaを T0.018867924528301886yb翻訳 T0.018867924528301886yaし T0.018867924528301886yaた T0.018867924528301886ybもの T0.018867924528301886yaに T0.018867924528301886ydなります T0.018867924528301886ya。 T0.018867924528301886ya  R0.1320754716981132yb原文 T0.018867924528301886ya： T0.018867924528301886ymElasticsearch T0.018867924528301886ya. S0.11320754716981132ycand T0.018867924528301886yhreleased T0.018867924528301886yb本日 T0.018867924528301886ya（ T0.018867924528301886ya/ T0.018867924528301886ya） T0.018867924528301886ya、 T0.018867924528301886yfLucene T0.018867924528301886ycベース T0.018867924528301886yaE T0.018867924528301886>vc163<yb東京g0.03125yb以外g0.03125yaでf0.0625yaのf0.0625yc勉強会f0.0625ya第g0.03125yb2弾g0.03125ycとしてg0.03125ya、g0.03125yb関西g0.03125yaをg0.03125yb開催g0.03125yaしg0.03125yaてg0.03125ycきましg0.03125yaたg0.03125ya。g0.03125ya f0.1875y PElasticsearch勉強会f0.0625ybinf0.0625yb大阪g0.03125ya京g0.03125>vc164<ya※ T0.023809523809523808ybこの T0.023809523809523808yb記事 T0.023809523809523808yaは T0.047619047619047616ya次 T0.023809523809523808yaの S0.11904761904761904ycブログ T0.023809523809523808yaを T0.023809523809523808yb翻訳 T0.023809523809523808yaし T0.023809523809523808yaた T0.023809523809523808ybもの T0.023809523809523808yaに T0.023809523809523808ydなります T0.023809523809523808ya。 T0.023809523809523808ya  S0.14285714285714285yb原文 T0.023809523809523808ya： T0.023809523809523808ycThe T0.023809523809523808yeGreat T0.023809523809523808ygMapping T0.023809523809523808ykRefactoring T0.023809523809523808ymElasticsearch T0.023809523809523808ycユーザ T0.023809523809523808yb悩み T0.023809523809523808yb最も T0.023809523809523808yb大き T0.023809523809523808ycなもの T0.023809523809523808yb一つ T0.023809523809523808ya、 T0.023809523809523808ycタイプ T0.023809523809523808yaと T0.023809523809523808>vc165<ya0 S0.07407407407407407ya1 T0.037037037037037035ya2 T0.037037037037037035ya※ T0.018518518518518517ybこの T0.018518518518518517yb記事 T0.018518518518518517yaは T0.018518518518518517ya次 T0.018518518518518517yaの S0.05555555555555555ycブログ T0.018518518518518517yaを T0.037037037037037035yb翻訳 T0.018518518518518517yaし T0.037037037037037035yaた T0.018518518518518517ybもの T0.018518518518518517yaに T0.018518518518518517ydなります T0.018518518518518517ya。 T0.037037037037037035ya  R0.1111111111111111yb原文 T0.018518518518518517ya： T0.018518518518518517ymElasticsearch T0.037037037037037035ya. R0.1111111111111111ydbeta T0.037037037037037035yfcoming T0.018518518518518517ydsoon T0.018518518518518517ya! T0.018518518518518517ydリリース T0.018518518518518517yb準備 T0.018518518518518517yaて T0.018518518518518517yaい T0.018518518518518517ybます T0.018518518518518517>vc166<ya4 T0.023255813953488372yaヶ T0.023255813953488372yb月前 T0.023255813953488372yaに T0.046511627906976744ya、 S0.06976744186046512yeFound T0.046511627906976744ya  S0.13953488372093023yfjoined T0.023255813953488372ycour T0.023255813953488372ydteam T0.023255813953488372ybat T0.023255813953488372ygElastic T0.023255813953488372yaを T0.046511627906976744yeアナウンス T0.023255813953488372ycしまし T0.023255813953488372yaた T0.023255813953488372ya。 T0.023255813953488372yaの T0.023255813953488372yb素晴 T0.023255813953488372yaら T0.023255813953488372ybしい T0.023255813953488372ycチーム T0.023255813953488372yaと T0.023255813953488372yb一緒 T0.023255813953488372yb仕事 T0.023255813953488372yaし T0.023255813953488372yaて T0.023255813953488372yaい T0.023255813953488372ybます T0.023255813953488372yaが T0.023255813953488372yb彼ら T0.023255813953488372ydによって T0.023255813953488372ybより T0.023255813953488372>vc167<ylJustTechTalk T0.030303030303030304ya# T0.030303030303030304yb02 T0.030303030303030304ya  S0.09090909090909091ye形態素解析 T0.030303030303030304yaの S0.09090909090909091ybあれ T0.030303030303030304yaや S0.06060606060606061ybこれ T0.030303030303030304ya@ T0.030303030303030304yhジャストシステム S0.06060606060606061yaに T0.030303030303030304yb参加 T0.030303030303030304yaし T0.030303030303030304yaて T0.030303030303030304ycきまし T0.030303030303030304yaた T0.030303030303030304ya。 T0.030303030303030304ybさん T0.030303030303030304yf形態素解析器 T0.030303030303030304ydJMAT T0.030303030303030304ya話 T0.030303030303030304yaと T0.030303030303030304yfKagome T0.030303030303030304ya、 S0.06060606060606061yfJanome T0.030303030303030304>vc168<ya5d0.02ydひさびさd0.02yaにd0.04ya、d0.02ye勉強会メモd0.02ya。d0.06ya d0.16yfHatenad0.02yhEngineerd0.02ygSeminard0.02ya#d0.02ya@d0.02yeTokyod0.02yb当選d0.02yaしd0.04yaたd0.06yaのd0.02yaでd0.02yb行っd0.04yaてd0.04ycきましd0.04ycいつもd0.02yaはd0.02yb近寄d0.02yaらd0.04ybないd0.02ydオシャレd0.02yaなd0.02ya街d0.02yaをd0.02ydドキドキd0.02ybながd0.02yaとd0.02>vc169<ya0 T0.022222222222222223ya1 T0.022222222222222223ya4 T0.044444444444444446ya6 T0.044444444444444446ya9 T0.022222222222222223yb10 T0.022222222222222223ya※ T0.022222222222222223ybこの T0.022222222222222223yb記事 T0.022222222222222223yaは T0.022222222222222223ya次 T0.022222222222222223yaの T0.044444444444444446ycブログ T0.022222222222222223yaを T0.022222222222222223yb翻訳 T0.022222222222222223yaし T0.022222222222222223yaた T0.022222222222222223ybもの T0.022222222222222223yaに T0.022222222222222223ydなります T0.022222222222222223ya。 T0.022222222222222223ya  R0.1111111111111111yb原文 T0.022222222222222223ya： T0.022222222222222223ymElasticsearch T0.022222222222222223ya. S0.08888888888888889yhreleased T0.022222222222222223yb本日 T0.022222222222222223ya（ T0.022222222222222223ya/ T0.022222222222222223ya） T0.022222222222222223ya、 T0.022222222222222223yfLucene T0.022222222222222223ycベース T0.022222222222222223ydElas T0.022222222222222223>vc170<yd第10回 T0.038461538461538464yoElsticsearch勉強会 T0.038461538461538464yaを T0.038461538461538464yb開催 T0.038461538461538464yaし S0.07692307692307693ybまし T0.038461538461538464yaた S0.11538461538461539ya。 T0.038461538461538464ya  T0.038461538461538464ydスタッフ T0.038461538461538464yaの S0.07692307692307693yc皆さん S0.07692307692307693ya、 S0.07692307692307693yeスピーカー T0.038461538461538464yd開場提供 T0.038461538461538464yaて T0.038461538461538464yaい T0.038461538461538464ybだい T0.038461538461538464ylリクルートテクノロジーズ T0.038461538461538464yaさ T0.038461538461538464>vc171<ya※ S0.02127659574468085ybこの S0.02127659574468085yb記事 S0.02127659574468085yaは S0.02127659574468085ya次 S0.02127659574468085yaの R0.0425531914893617ycブログ S0.02127659574468085yaを S0.06382978723404255yb翻訳 S0.02127659574468085yaし S0.06382978723404255yaた S0.02127659574468085ybもの S0.02127659574468085yaに S0.02127659574468085ydなります S0.02127659574468085ya。 S0.02127659574468085ya  S0.14893617021276595yb原文 S0.02127659574468085ya： S0.02127659574468085ygReindex S0.02127659574468085ymElasticsearch S0.02127659574468085ydWith S0.02127659574468085yhLogstash S0.02127659574468085yfThanks S0.02127659574468085yeDavid S0.02127659574468085ya! S0.02127659574468085yeマッピング S0.02127659574468085yb変更 R0.0425531914893617ybたり R0.0425531914893617ya、 R0.0425531914893617yfインデックス S0.02127659574468085yb設定 S0.02127659574468085ybある S0.02127659574468085yaサ S0.02127659574468085>vc172<ya※ T0.022727272727272728ybこの T0.022727272727272728yb記事 T0.022727272727272728yaは T0.022727272727272728ya次 T0.022727272727272728yaの S0.06818181818181818ycブログ T0.022727272727272728yaを T0.045454545454545456yb翻訳 T0.022727272727272728yaし T0.045454545454545456yaた T0.022727272727272728ybもの T0.022727272727272728yaに T0.022727272727272728ydなります T0.022727272727272728ya。 T0.022727272727272728ya  S0.13636363636363635yb原文 T0.022727272727272728ya： T0.022727272727272728ydJoin T0.022727272727272728ycthe T0.022727272727272728ylConversation T0.022727272727272728ya: T0.022727272727272728ygDiscuss T0.022727272727272728ya. T0.045454545454545456ygElastic T0.022727272727272728ybCo T0.022727272727272728yb3つ T0.022727272727272728ycOSS T0.022727272727272728yfプロジェクト T0.022727272727272728yb開発 T0.022727272727272728ygスケールアップ T0.022727272727272728yb始め T0.022727272727272728ya、 T0.022727272727272728yiコミュニティサポー T0.022727272727272728>vc173<ya1 T0.022222222222222223ya2 T0.022222222222222223ya4 S0.06666666666666667ya5 T0.022222222222222223yb10 T0.022222222222222223yb27 T0.022222222222222223ya※ T0.022222222222222223ybこの T0.022222222222222223yb記事 T0.022222222222222223yaは T0.022222222222222223ya次 T0.022222222222222223yaの T0.044444444444444446ycブログ T0.022222222222222223yaを T0.022222222222222223yb翻訳 T0.022222222222222223yaし T0.022222222222222223yaた T0.022222222222222223ybもの T0.022222222222222223yaに T0.022222222222222223ydなります T0.022222222222222223ya。 T0.022222222222222223ya  R0.1111111111111111yb原文 T0.022222222222222223ya： T0.022222222222222223ymElasticsearch T0.022222222222222223ya. S0.08888888888888889yhReleased T0.022222222222222223yb本日 T0.022222222222222223ya（ T0.022222222222222223ya/ T0.022222222222222223ya） T0.022222222222222223ya、 T0.022222222222222223yfLucene T0.022222222222222223ycベース T0.022222222222222223ycEla T0.022222222222222223>vc174<yc第9回 T0.038461538461538464yoElsticsearch勉強会 T0.038461538461538464yaを T0.038461538461538464yb開催 T0.038461538461538464yaし S0.07692307692307693ybまし T0.038461538461538464yaた S0.11538461538461539ya。 T0.038461538461538464ya  T0.038461538461538464ydスタッフ T0.038461538461538464yaの S0.07692307692307693yc皆さん S0.07692307692307693ya、 S0.07692307692307693yeスピーカー T0.038461538461538464yd開場提供 T0.038461538461538464yaて T0.038461538461538464yaい T0.038461538461538464ybだい T0.038461538461538464ylリクルートテクノロジーズ T0.038461538461538464ybさん T0.038461538461538464>vc175<ya1 T0.044444444444444446ya4 S0.06666666666666667ya5 T0.022222222222222223ya9 T0.022222222222222223yb10 T0.022222222222222223ya※ T0.022222222222222223ybこの T0.022222222222222223yb記事 T0.022222222222222223yaは T0.022222222222222223ya次 T0.022222222222222223yaの T0.044444444444444446ycブログ T0.022222222222222223yaを T0.022222222222222223yb翻訳 T0.022222222222222223yaし T0.022222222222222223yaた T0.022222222222222223ybもの T0.022222222222222223yaに T0.022222222222222223ydなります T0.022222222222222223ya。 T0.022222222222222223ya  R0.1111111111111111yb原文 T0.022222222222222223ya： T0.022222222222222223ymElasticsearch T0.022222222222222223ya. S0.08888888888888889yhReleased T0.022222222222222223yb本日 T0.022222222222222223ya（ T0.022222222222222223ya/ T0.022222222222222223ya） T0.022222222222222223ya、 T0.022222222222222223yfLucene T0.022222222222222223ycベース T0.022222222222222223ydElas T0.022222222222222223>vc176<y PElasticsearch勉強会 T0.027777777777777776ya  R0.1111111111111111ybin T0.027777777777777776yc名古屋 T0.027777777777777776yaを T0.027777777777777776yb開催 T0.027777777777777776yaし T0.027777777777777776ybまし T0.027777777777777776yaた S0.08333333333333333ya。 S0.05555555555555555ya初 T0.027777777777777776yaの S0.05555555555555555yb東京 T0.027777777777777776yb以外 T0.027777777777777776yaで S0.05555555555555555yc勉強会 T0.027777777777777776yaす T0.027777777777777776yb企画 T0.027777777777777776ya、 T0.027777777777777776yeセッション T0.027777777777777776ybなど T0.027777777777777776yaお T0.027777777777777776yb手伝 T0.027777777777777776ybいい T0.027777777777777776ybだい T0.027777777777777776ya@ T0.027777777777777776ygsmogami T0.027777777777777776yaさ T0.027777777777777776>vc177<ya0 T0.022222222222222223ya1 T0.022222222222222223ya3 T0.022222222222222223ya4 T0.044444444444444446ya5 T0.022222222222222223yb10 T0.022222222222222223yb23 T0.022222222222222223ya※ T0.022222222222222223ybこの T0.022222222222222223yb記事 T0.022222222222222223yaは T0.022222222222222223ya次 T0.022222222222222223yaの T0.044444444444444446ycブログ T0.022222222222222223yaを T0.022222222222222223yb翻訳 T0.022222222222222223yaし T0.022222222222222223yaた T0.022222222222222223ybもの T0.022222222222222223yaに T0.022222222222222223ydなります T0.022222222222222223ya。 T0.022222222222222223ya  R0.1111111111111111yb原文 T0.022222222222222223ya： T0.022222222222222223ymElasticsearch T0.022222222222222223ya. S0.08888888888888889yhReleased T0.022222222222222223yb本日 T0.022222222222222223ya（ T0.022222222222222223ya/ T0.022222222222222223ya） T0.022222222222222223ya、 T0.022222222222222223yfLucene T0.022222222222222223ycベース T0.022222222222222223ycEla T0.022222222222222223>vc178<yhサンフランシスコ S0.02702702702702703ybから S0.02702702702702703ybこん S0.02702702702702703ybにち S0.02702702702702703yaは S0.05405405405405406ya。 S0.05405405405405406ya  S0.08108108108108109ya今 S0.02702702702702703ya、 S0.08108108108108109ya私 S0.02702702702702703yc弊社初 S0.02702702702702703yaの S0.08108108108108109yjユーザカンファレンス S0.02702702702702703ygelastic S0.02702702702702703ya{ S0.02702702702702703ybON S0.02702702702702703ya} S0.02702702702702703yaに S0.05405405405405406yb参加 S0.02702702702702703ybする S0.02702702702702703ybため S0.02702702702702703ya初 S0.05405405405405406ydアメリカ S0.02702702702702703yc出張中 S0.02702702702702703yaで S0.02702702702702703yaす S0.02702702702702703yaユ S0.02702702702702703>vc179<ya0 R0.0196078431372549ya1 R0.0392156862745098yb27 R0.0196078431372549ya※ R0.0196078431372549ybこの R0.0196078431372549yb記事 R0.0196078431372549yaは R0.0196078431372549ya次 R0.0196078431372549yaの R0.0196078431372549ycブログ R0.0196078431372549yaを R0.0392156862745098yb翻訳 R0.0196078431372549yaし R0.0196078431372549yaた R0.0392156862745098ybもの R0.0196078431372549yaに R0.0392156862745098ydなります R0.0196078431372549ya。 R0.0392156862745098ya  S0.21568627450980393yb原文 R0.0196078431372549ya： R0.0196078431372549ycyou R0.0196078431372549ydknow R0.0196078431372549ya, R0.0196078431372549ycfor R0.0196078431372549yhsecurity R0.0196078431372549ya: R0.0196078431372549yfshield R0.0196078431372549ydgoes R0.0196078431372549ybga R0.0196078431372549ya/ R0.0196078431372549yfShield R0.0196078431372549ya. R0.0196078431372549ydリリース R0.0196078431372549ycしまし R0.0196078431372549ylElasticsearc R0.0196078431372549>vc180<ya3 S0.03225806451612903yb14 S0.03225806451612903ye4月13日 S0.03225806451612903ybから S0.03225806451612903yc3日間 S0.03225806451612903ya、 S0.06451612903225806ymElasticsearch S0.03225806451612903yaの S0.03225806451612903ydCore S0.03225806451612903yfトレーニング S0.03225806451612903yaが S0.03225806451612903yb東京 S0.03225806451612903yaで S0.06451612903225806yb開催 S0.03225806451612903yaさ S0.03225806451612903yaれ S0.03225806451612903ybます S0.03225806451612903ya。 S0.03225806451612903ya  S0.06451612903225806yeEarly S0.03225806451612903ydBird S0.03225806451612903ycという S0.03225806451612903ybこと S0.03225806451612903ya/ S0.03225806451612903ybまで S0.03225806451612903yaに S0.03225806451612903yb申し S0.03225806451612903yc込みす S0.03225806451612903>vc181<ya4 T0.041666666666666664ya※ T0.020833333333333332ybこの T0.020833333333333332yb記事 T0.020833333333333332yaは T0.041666666666666664ya次 T0.020833333333333332yaの T0.020833333333333332ycブログ T0.020833333333333332yaを T0.020833333333333332yb翻訳 T0.020833333333333332yaし T0.020833333333333332yaた T0.020833333333333332ybもの T0.020833333333333332yaに S0.08333333333333333ydなります T0.020833333333333332ya。 T0.020833333333333332ya  S0.10416666666666667yb原文 T0.020833333333333332ya： T0.020833333333333332yfkibana T0.020833333333333332ya. T0.041666666666666664yiliterally T0.020833333333333332yfKibana T0.020833333333333332yb現在 T0.020833333333333332ya、 S0.10416666666666667yd文字通り T0.020833333333333332yc抽象的 T0.020833333333333332yc概念的 T0.020833333333333332yc精神的 T0.020833333333333332ycそして T0.020833333333333332yaと T0.020833333333333332yaて T0.020833333333333332yaも T0.020833333333333332yc楽しく T0.020833333333333332>vc182<ya1 T0.061224489795918366ya2 S0.02040816326530612ya3 S0.02040816326530612ya4 T0.061224489795918366ya9 S0.02040816326530612yb20 S0.02040816326530612ya※ S0.02040816326530612ybこの S0.02040816326530612yb記事 S0.02040816326530612yaは S0.02040816326530612ya次 S0.02040816326530612yaの S0.02040816326530612ycブログ S0.02040816326530612yaを S0.02040816326530612yb翻訳 S0.02040816326530612yaし S0.02040816326530612yaた S0.02040816326530612ybもの S0.02040816326530612yaに S0.02040816326530612ydなります S0.02040816326530612ya。 S0.02040816326530612ya  S0.14285714285714285yb原文 S0.02040816326530612ya： S0.02040816326530612ymelasticsearch S0.02040816326530612ya. S0.12244897959183673ycand S0.02040816326530612yhreleased S0.02040816326530612yb本日 S0.02040816326530612ya（ S0.02040816326530612ya/ S0.02040816326530612ya） S0.02040816326530612ya、 S0.02040816326530612ymElasticsearch S0.02040816326530612>vc183<yb来る T0.029411764705882353ya、 T0.029411764705882353yd4月4日 T0.029411764705882353yaの S0.11764705882352941yc土曜日 T0.029411764705882353yb午後 T0.029411764705882353yaに T0.029411764705882353yc名古屋 T0.029411764705882353yaで S0.11764705882352941y PElasticsearch勉強会 T0.029411764705882353yaを T0.029411764705882353yb開催 T0.029411764705882353yb予定 T0.029411764705882353yaす T0.058823529411764705ya。 T0.058823529411764705ya  T0.058823529411764705ya「 T0.029411764705882353ya初 T0.029411764705882353ya」 T0.029411764705882353yb東京 T0.029411764705882353yb以外 T0.029411764705882353yc勉強会 T0.029411764705882353ygTwitter T0.029411764705882353ybこの T0.029411764705882353ybよう T0.029411764705882353>vc184<yc第8回 T0.038461538461538464yoElsticsearch勉強会 T0.038461538461538464yaを T0.038461538461538464yb開催 T0.038461538461538464yaし S0.07692307692307693ybまし T0.038461538461538464yaた S0.11538461538461539ya。 T0.038461538461538464ya  T0.038461538461538464ydスタッフ T0.038461538461538464yaの S0.07692307692307693yc皆さん S0.07692307692307693ya、 S0.07692307692307693yeスピーカー T0.038461538461538464yd開場提供 T0.038461538461538464yaて T0.038461538461538464yaい T0.038461538461538464ybだい T0.038461538461538464ylリクルートテクノロジーズ T0.038461538461538464ybさん T0.038461538461538464>vc185<ya1 T0.022727272727272728ya3 T0.045454545454545456ya4 T0.022727272727272728ya8 T0.022727272727272728ya※ T0.022727272727272728ybこの T0.022727272727272728yb記事 T0.022727272727272728yaは T0.022727272727272728ya次 T0.022727272727272728yaの T0.045454545454545456ycブログ T0.022727272727272728yaを T0.022727272727272728yb翻訳 T0.022727272727272728yaし T0.022727272727272728yaた T0.022727272727272728ybもの T0.022727272727272728yaに T0.022727272727272728ydなります T0.022727272727272728ya。 T0.022727272727272728ya  R0.1590909090909091yb原文 T0.022727272727272728ya： T0.022727272727272728ygrunning T0.022727272727272728yfgroovy T0.022727272727272728ygscripts T0.022727272727272728ygwithout T0.022727272727272728ygdynamic T0.022727272727272728yiscripting T0.022727272727272728ynElasticsearch1 T0.022727272727272728ya. S0.09090909090909091yaと T0.022727272727272728ydリリース T0.022727272727272728ybによ T0.022727272727272728>vc186<ya1 R0.0392156862745098ya3 T0.058823529411764705ya4 R0.0392156862745098ya8 R0.0196078431372549yb10 R0.0196078431372549ya※ R0.0196078431372549ybこの R0.0196078431372549yb記事 R0.0196078431372549yaは R0.0196078431372549ya次 R0.0196078431372549yaの R0.0196078431372549ycブログ R0.0196078431372549yaを R0.0392156862745098yb翻訳 R0.0196078431372549yaし R0.0392156862745098yaた R0.0392156862745098ybもの R0.0196078431372549yaに R0.0392156862745098ydなります R0.0196078431372549ya。 R0.0196078431372549ya  S0.13725490196078433yb原文 R0.0196078431372549ya： R0.0196078431372549ymelasticsearch R0.0196078431372549ya. S0.11764705882352941ycand R0.0196078431372549yhreleased R0.0196078431372549yb本日 R0.0196078431372549ya、 R0.0196078431372549yfLucene R0.0196078431372549ycベース R0.0196078431372549ydElas R0.0196078431372549>vc187<yb今年 S0.05263157894736842yaも S0.02631578947368421yeCROSS S0.02631578947368421yb参加 S0.02631578947368421yaし S0.05263157894736842ybまし S0.02631578947368421yaた S0.10526315789473684ya。 S0.07894736842105263ycそして S0.02631578947368421ya、 S0.05263157894736842yd話もして S0.02631578947368421ycきまし S0.02631578947368421ya  S0.02631578947368421yaは S0.05263157894736842yb横浜 S0.05263157894736842yaの S0.05263157894736842yc大さん S0.02631578947368421ya橋 S0.02631578947368421yaで S0.07894736842105263ygあんまりこない S0.02631578947368421yb乗り S0.02631578947368421yb換え S0.02631578947368421yaお S0.02631578947368421ydおたして S0.02631578947368421ydしまいま S0.02631578947368421>vc188<yb今年 T0.022727272727272728yaは T0.045454545454545456yc大晦日 T0.022727272727272728yaに T0.045454545454545456ybなっ T0.022727272727272728yaて T0.045454545454545456yeしまいまし T0.022727272727272728yaた T0.045454545454545456ya。 S0.11363636363636363ycしかも T0.022727272727272728ya、 T0.022727272727272728ycちょっ T0.022727272727272728yaと T0.022727272727272728yb飲ん T0.022727272727272728yaで T0.022727272727272728ybたり T0.022727272727272728ya  S0.06818181818181818ya第 T0.022727272727272728yb9流 T0.022727272727272728yaし T0.022727272727272728ybなが T0.022727272727272728yaら T0.022727272727272728yb書い T0.045454545454545456ybます T0.022727272727272728yb振り T0.022727272727272728yb返り T0.022727272727272728ya( T0.022727272727272728ye2013年 T0.022727272727272728yb抱負 T0.022727272727272728ybから T0.022727272727272728ya) T0.022727272727272728ybまず T0.022727272727272728yb昨年 T0.022727272727272728>vc189<yd2014 T0.029411764705882353ybこの T0.029411764705882353yb記事 T0.029411764705882353yaは T0.029411764705882353ymElasticsearch T0.029411764705882353ya  S0.11764705882352941yfAdvent T0.029411764705882353ygCalndar T0.029411764705882353yaの T0.058823529411764705yd25日目 T0.029411764705882353ydエントリ T0.029411764705882353yaで S0.08823529411764706yaす T0.058823529411764705ya。 T0.058823529411764705ybあっ T0.029411764705882353ycという T0.058823529411764705ya間 T0.029411764705882353yaに T0.029411764705882353yc最終日 T0.029411764705882353yb来年 T0.029411764705882353ybにつ T0.029411764705882353ycなげる T0.029411764705882353yb意味 T0.029411764705882353ya、 T0.029411764705882353yfElasti T0.029411764705882353>vc190<ya0 T0.043478260869565216ya1 T0.043478260869565216ya3 T0.043478260869565216yb12 T0.021739130434782608yb17 T0.021739130434782608ya※ T0.021739130434782608ybこの T0.021739130434782608yb記事 T0.021739130434782608yaは T0.021739130434782608ya次 T0.021739130434782608yaの T0.021739130434782608ycブログ T0.021739130434782608yaを T0.043478260869565216yb翻訳 T0.021739130434782608yaし T0.021739130434782608yaた T0.043478260869565216ybもの T0.021739130434782608yaに T0.043478260869565216ydなります T0.021739130434782608ya。 T0.021739130434782608ya  S0.13043478260869565yb原文 T0.021739130434782608ya： T0.021739130434782608yfmarvel T0.021739130434782608ya. S0.08695652173913043yhreleased T0.021739130434782608ya/ T0.021739130434782608ya、 T0.021739130434782608ymElasticsearch T0.021739130434782608yfMarvel T0.021739130434782608ydリリース T0.021739130434782608ycしまし T0.021739130434782608>vc191<ya1 R0.0392156862745098ya3 T0.058823529411764705ya4 R0.0392156862745098ya8 R0.0196078431372549yb10 R0.0196078431372549ya※ R0.0196078431372549ybこの R0.0196078431372549yb記事 R0.0196078431372549yaは R0.0196078431372549ya次 R0.0196078431372549yaの R0.0196078431372549ycブログ R0.0196078431372549yaを R0.0392156862745098yb翻訳 R0.0196078431372549yaし R0.0392156862745098yaた R0.0392156862745098ybもの R0.0196078431372549yaに R0.0392156862745098ydなります R0.0196078431372549ya。 R0.0196078431372549ya  S0.13725490196078433yb原文 R0.0196078431372549ya： R0.0196078431372549ymelasticsearch R0.0196078431372549ya. S0.11764705882352941ycand R0.0196078431372549yhreleased R0.0196078431372549yb本日 R0.0196078431372549ya、 R0.0196078431372549yfLucene R0.0196078431372549ycベース R0.0196078431372549ydElas R0.0196078431372549>vc192<yb12 T0.027777777777777776yb17 T0.027777777777777776yb「【 T0.027777777777777776yb東京 T0.027777777777777776ya】 T0.027777777777777776ydJJUG T0.027777777777777776ya  S0.05555555555555555yhナイト・セミナー T0.027777777777777776ya「 T0.027777777777777776yd機械学習 T0.027777777777777776ya・ T0.027777777777777776yh自然言語処理特集 T0.027777777777777776ya！ T0.027777777777777776ya」 S0.05555555555555555ya/ T0.027777777777777776ya（ T0.027777777777777776ya水 T0.027777777777777776ya） T0.027777777777777776yb開催 T0.027777777777777776yaで T0.027777777777777776yfLucene T0.027777777777777776yaの T0.027777777777777776ya話 T0.027777777777777776yaを T0.027777777777777776ybして T0.027777777777777776ycきまし T0.027777777777777776yaた T0.027777777777777776ya。 T0.027777777777777776yb本当 T0.027777777777777776yaに T0.027777777777777776ybごく T0.027777777777777776yb簡単 T0.027777777777777776yaな T0.027777777777777776ya入 T0.027777777777777776>vc193<ycたまに T0.023255813953488372yaは S0.06976744186046512ya、 S0.09302325581395349yb他愛 T0.023255813953488372yaの T0.046511627906976744ybない T0.023255813953488372ycブログ T0.023255813953488372yaを T0.046511627906976744ya。 S0.06976744186046512ya  S0.06976744186046512yb仕事 T0.046511627906976744yaし T0.046511627906976744yaな T0.023255813953488372yaが T0.023255813953488372yaら T0.023255813953488372ydコーヒー T0.023255813953488372yb飲ん T0.023255813953488372yaで T0.023255813953488372ybます T0.046511627906976744yb最近 T0.023255813953488372yfサムライズム T0.023255813953488372ybさん T0.023255813953488372ydオフィス T0.046511627906976744yaに T0.046511627906976744yd入り浸っ T0.023255813953488372yaて T0.046511627906976744>vc194<ya0 T0.018867924528301886ya1 S0.03773584905660377ya5 T0.018867924528301886ya※ T0.018867924528301886ybこの T0.018867924528301886yb記事 T0.018867924528301886yaは S0.03773584905660377ya次 T0.018867924528301886yaの S0.05660377358490566ycブログ T0.018867924528301886yaを T0.018867924528301886yb翻訳 T0.018867924528301886yaし T0.018867924528301886yaた T0.018867924528301886ybもの T0.018867924528301886yaに T0.018867924528301886ydなります T0.018867924528301886ya。 T0.018867924528301886ya  S0.18867924528301888yb原文 T0.018867924528301886ya： T0.018867924528301886yhexciting T0.018867924528301886yhlogstash T0.018867924528301886yfplugin T0.018867924528301886yiecosystem T0.018867924528301886ygchanges T0.018867924528301886yhLogstash T0.018867924528301886ya. S0.03773584905660377ydBeta T0.018867924528301886ya( T0.018867924528301886yaお T0.018867924528301886yb試し T0.018867924528301886ycこちら T0.018867924528301886ya) T0.018867924528301886ydリリース T0.018867924528301886yaで T0.018867924528301886ya、 T0.018867924528301886yeプラグイン T0.018867924528301886yeインストー T0.018867924528301886>vc195<ya0 T0.038461538461538464ya1 S0.07692307692307693ya5 T0.038461538461538464ya※ T0.019230769230769232ybこの T0.019230769230769232yb記事 T0.019230769230769232yaは T0.019230769230769232ya次 T0.019230769230769232yaの T0.038461538461538464ycブログ T0.019230769230769232yaを T0.038461538461538464yb翻訳 T0.019230769230769232yaし T0.019230769230769232yaた T0.038461538461538464ybもの T0.019230769230769232yaに T0.019230769230769232ydなります T0.019230769230769232ya。 T0.038461538461538464ya  S0.11538461538461539yb原文 T0.019230769230769232ya： T0.019230769230769232yhlogstash T0.019230769230769232ya. S0.09615384615384616ydbeta T0.019230769230769232yhreleased T0.019230769230769232yhLogstash T0.019230769230769232ydBeta T0.019230769230769232ydリリース T0.019230769230769232ycしまし T0.019230769230769232ycこちら T0.019230769230769232ycページ T0.019230769230769232ybから T0.019230769230769232yfダウンロード T0.019230769230769232yaで T0.019230769230769232>vc196<yb早い T0.029411764705882353ybもの T0.029411764705882353yaで S0.08823529411764706ya、 T0.058823529411764705yb師走 T0.029411764705882353yaす T0.029411764705882353ya。 S0.08823529411764706yb今年 T0.029411764705882353yaも T0.029411764705882353ybあと T0.029411764705882353yb少し T0.029411764705882353yaと T0.029411764705882353ydなりまし T0.029411764705882353yaた T0.058823529411764705ycという T0.029411764705882353ybこと T0.029411764705882353yfAdvent T0.029411764705882353ya  T0.058823529411764705yhCalendar T0.029411764705882353yaの T0.029411764705882353yb季節 T0.029411764705882353yaが T0.029411764705882353ye始まりまし T0.029411764705882353ybこの T0.029411764705882353yb記事 T0.029411764705882353yaは T0.029411764705882353yhElastics T0.029411764705882353>vc197<ya1 T0.058823529411764705ya2 R0.0196078431372549ya3 R0.0196078431372549ya4 R0.0392156862745098ya6 R0.0196078431372549yb10 R0.0196078431372549ya※ R0.0196078431372549ybこの R0.0196078431372549yb記事 R0.0196078431372549yaは R0.0196078431372549ya次 R0.0196078431372549yaの R0.0196078431372549ycブログ R0.0196078431372549yaを R0.0392156862745098yb翻訳 R0.0196078431372549yaし R0.0392156862745098yaた R0.0392156862745098ybもの R0.0196078431372549yaに R0.0392156862745098ydなります R0.0196078431372549ya。 R0.0196078431372549ya  S0.13725490196078433yb原文 R0.0196078431372549ya： R0.0196078431372549ymelasticsearch R0.0196078431372549ya. S0.11764705882352941ycand R0.0196078431372549yhreleased R0.0196078431372549yb本日 R0.0196078431372549ya、 R0.0196078431372549yfLucene R0.0196078431372549ycベース R0.0196078431372549ydElas R0.0196078431372549>vc198<yb前回 S0.06451612903225806yaの S0.16129032258064516ya「 S0.03225806451612903yhLogstash S0.06451612903225806yaを S0.03225806451612903yb利用 S0.03225806451612903yaし S0.03225806451612903yaた S0.03225806451612903yfApache S0.03225806451612903yfアクセスログ S0.03225806451612903yeインポート S0.03225806451612903ya」 S0.03225806451612903yb続き S0.03225806451612903yaで S0.06451612903225806yaす S0.03225806451612903ya。 S0.03225806451612903ya  S0.03225806451612903yb記事 S0.03225806451612903yaは S0.03225806451612903ya、 S0.03225806451612903yb設定 S0.03225806451612903ydファイル S0.03225806451612903ydについて S0.03225806451612903ya説 S0.03225806451612903>vc199<ya4 T0.034482758620689655ydJJUG T0.034482758620689655ya  S0.06896551724137931ycCCC T0.034482758620689655yaや T0.034482758620689655ya第 T0.034482758620689655yb7回 T0.034482758620689655y PElasticsearch勉強会 T0.034482758620689655yaの S0.06896551724137931yfKibana T0.034482758620689655ybデモ T0.034482758620689655yaに T0.034482758620689655yfアクセスログ T0.034482758620689655yaを T0.034482758620689655yb利用 T0.034482758620689655yaし T0.034482758620689655ybまし T0.034482758620689655yaた T0.034482758620689655ya。 T0.034482758620689655ybただ T0.034482758620689655ya、 S0.06896551724137931yeセッション T0.034482758620689655yaで T0.034482758620689655yaは T0.034482758620689655yeどうやって T0.034482758620689655ydElas T0.034482758620689655>vc200<yc第7回 T0.038461538461538464yoElsticsearch勉強会 T0.038461538461538464yaを T0.038461538461538464yb開催 T0.038461538461538464yaし S0.07692307692307693ybまし T0.038461538461538464yaた S0.11538461538461539ya。 T0.038461538461538464ya  T0.038461538461538464ydスタッフ T0.038461538461538464yaの S0.07692307692307693yc皆さん S0.07692307692307693ya、 S0.07692307692307693yeスピーカー T0.038461538461538464yd開場提供 T0.038461538461538464yaて T0.038461538461538464yaい T0.038461538461538464ybだい T0.038461538461538464ylリクルートテクノロジーズ T0.038461538461538464ybさん T0.038461538461538464>vc201<ya0 S0.02040816326530612ya1 S0.04081632653061224ya2 S0.02040816326530612ya3 S0.02040816326530612ya4 S0.04081632653061224ya5 S0.02040816326530612yb10 S0.02040816326530612ya※ S0.02040816326530612ybこの S0.02040816326530612yb記事 S0.02040816326530612yaは S0.02040816326530612ya次 S0.02040816326530612yaの S0.02040816326530612ycブログ S0.02040816326530612yaを S0.04081632653061224yb翻訳 S0.02040816326530612yaし S0.04081632653061224yaた S0.02040816326530612ybもの S0.02040816326530612yaに S0.04081632653061224ydなります S0.02040816326530612ya。 S0.02040816326530612ya  S0.12244897959183673yb原文 S0.02040816326530612ya： S0.02040816326530612ymelasticsearch S0.02040816326530612ya- S0.02040816326530612ya. S0.12244897959183673ycand S0.02040816326530612yhreleased S0.02040816326530612yb本日 S0.02040816326530612ya、 S0.02040816326530612yfLucene S0.02040816326530612ycベース S0.02040816326530612>vc202<yb久し S0.02564102564102564ybぶり S0.02564102564102564yaに S0.02564102564102564yb翻訳 S0.02564102564102564yaで S0.07692307692307693yaは S0.05128205128205128ybない S0.02564102564102564ycブログ S0.02564102564102564yaを S0.02564102564102564ya。 R0.1282051282051282yc書こう S0.02564102564102564yaと S0.02564102564102564yb思い S0.02564102564102564yaな S0.02564102564102564yaが S0.02564102564102564ycらかけ S0.02564102564102564yaて S0.02564102564102564ycなかっ S0.02564102564102564yaた S0.02564102564102564yaの S0.05128205128205128ya  S0.10256410256410256yb今回 S0.02564102564102564yhvalidate S0.02564102564102564ycAPI S0.02564102564102564yb紹介 S0.02564102564102564yaす S0.02564102564102564yb背景 S0.02564102564102564ykElasticsear S0.02564102564102564>vc203<ya0g0.03125ya1f0.0625ya4g0.03125ymElasticsearchg0.03125ya f0.0625ya.g0.09375ydBetag0.03125yaがg0.03125ydリリースg0.03125yaさg0.03125yaれg0.03125ybましg0.03125yaたg0.03125ya。g0.03125yb個人g0.03125yaでg0.03125ymelasticsearchg0.03125ya-f0.0625yhextendedg0.03125yganalyzeg0.03125ycというg0.03125yeプラグインg0.03125yaをg0.03125yb開発g0.03125yaしg0.03125yaてg0.03125yaまg0.03125>vc204<ya0 S0.02127659574468085ya1 S0.06382978723404255ya4 R0.0425531914893617yb10 S0.02127659574468085ya※ S0.02127659574468085ybこの S0.02127659574468085yb記事 S0.02127659574468085yaは S0.02127659574468085ya次 S0.02127659574468085yaの S0.02127659574468085ycブログ S0.02127659574468085yaを R0.0425531914893617yb翻訳 S0.02127659574468085yaし R0.0425531914893617yaた R0.0425531914893617ybもの S0.02127659574468085yaに R0.0425531914893617ydなります S0.02127659574468085ya。 S0.02127659574468085ya  S0.10638297872340426yb原文 S0.02127659574468085ya： S0.02127659574468085ymelasticsearch S0.02127659574468085ya. S0.10638297872340426ydbeta S0.02127659574468085yhreleased S0.02127659574468085yb本日 S0.02127659574468085ya、 R0.0425531914893617yfLucene S0.02127659574468085ycベース S0.02127659574468085yeElast S0.02127659574468085>vc205<yc第6回 T0.038461538461538464yoElsticsearch勉強会 T0.038461538461538464yaを T0.038461538461538464yb開催 T0.038461538461538464yaし S0.07692307692307693ybまし T0.038461538461538464yaた S0.11538461538461539ya。 T0.038461538461538464ya  T0.038461538461538464ydスタッフ T0.038461538461538464yaの S0.07692307692307693yc皆さん S0.07692307692307693ya、 S0.07692307692307693yeスピーカー T0.038461538461538464yd開場提供 T0.038461538461538464yaて T0.038461538461538464yaい T0.038461538461538464ybだい T0.038461538461538464ylリクルートテクノロジーズ T0.038461538461538464ybさん T0.038461538461538464>vc206<yb先日 S0.03225806451612903ye2014年 S0.03225806451612903yd9月9日 S0.03225806451612903ya( S0.03225806451612903ya火 S0.03225806451612903ya) S0.03225806451612903yaに S0.03225806451612903ya『 S0.03225806451612903ycサーバ S0.03225806451612903ya/ S0.03225806451612903ymインフラエンジニア養成読本 S0.03225806451612903ya  R0.0967741935483871ybログ S0.03225806451612903yb収集 S0.03225806451612903ya〜 S0.03225806451612903yd可視化編 S0.03225806451612903ya』 S0.03225806451612903yd出版記念 S0.03225806451612903ya！ S0.06451612903225806yc執筆者 S0.03225806451612903yaが S0.03225806451612903yb語る S0.03225806451612903yb大講 S0.03225806451612903yb演会 S0.03225806451612903yaで S0.03225806451612903ya、 S0.03225806451612903ya「 S0.03225806451612903yhelastics S0.03225806451612903>vc207<ymElasticsearch T0.043478260869565216yaの T0.043478260869565216ygインデキシング T0.043478260869565216yaに T0.043478260869565216yc関する T0.043478260869565216ygパフォーマンス T0.043478260869565216yb検討 T0.043478260869565216ya  R0.2608695652173913yb原文 T0.043478260869565216ya： T0.043478260869565216ykperformance T0.043478260869565216ynconsiderations T0.043478260869565216ycfor T0.043478260869565216ymelasticsearch T0.043478260869565216yhindexing T0.043478260869565216y PElasticsearchユーザ T0.043478260869565216yaは T0.043478260869565216ya様 T0.043478260869565216>vc208<yc懲りず T0.023809523809523808yaに T0.023809523809523808ybまた T0.023809523809523808ya、 T0.047619047619047616yb執筆 T0.023809523809523808yaし T0.023809523809523808yaて T0.047619047619047616ycみまし T0.023809523809523808yaた T0.047619047619047616ya。 T0.023809523809523808ydみなさん T0.023809523809523808ya「 T0.023809523809523808yb買っ T0.023809523809523808ya」 T0.023809523809523808ybから T0.023809523809523808yb感想 T0.023809523809523808yaを T0.047619047619047616yaい T0.023809523809523808ycだける T0.023809523809523808ycとうれ T0.023809523809523808ybしい T0.023809523809523808yaで T0.047619047619047616yaす T0.023809523809523808ya！ T0.023809523809523808ya  T0.047619047619047616yb本書 T0.023809523809523808ydについて T0.023809523809523808yc共著者 T0.023809523809523808yaの S0.07142857142857142yb方々 T0.023809523809523808ycブログ T0.023809523809523808yaが T0.023809523809523808yc詳しい T0.023809523809523808ycそちら T0.023809523809523808>vc209<yeProxyd0.04yb環境d0.04yaでd0.12yb働いd0.04yaてd0.04ybいるd0.08yb方もd0.04yb結構d0.04yaとd0.04yd思いますd0.04ya。d0.04ya d0.04ygTwitterd0.04ya上d0.04ya、d0.04ymElasticsearchd0.04yaのd0.04yfplugind0.04ydコマンドd0.04yeプラグインd0.04yaがd0.04ydインストd0.04>vc210<ya1 S0.11764705882352941ya3 T0.058823529411764705yb原文 T0.029411764705882353ya： T0.029411764705882353ymElasticsearch T0.058823529411764705ya  S0.11764705882352941ya. S0.11764705882352941yhReleased T0.029411764705882353yaを T0.058823529411764705yc日本語 T0.029411764705882353yaに T0.029411764705882353yb翻訳 T0.029411764705882353yaし T0.029411764705882353yaた T0.029411764705882353ybもの T0.029411764705882353yaで T0.029411764705882353yaす T0.029411764705882353ya。 T0.029411764705882353ygバグフィックス T0.029411764705882353ya版 T0.029411764705882353yaの T0.029411764705882353ycリリー T0.029411764705882353>vc211<ya0 T0.045454545454545456ya1 S0.06818181818181818ya2 T0.022727272727272728ygCurator T0.045454545454545456yaの S0.09090909090909091ya. S0.09090909090909091yaが S0.06818181818181818ydリリース T0.022727272727272728yaさ T0.045454545454545456yaれ T0.045454545454545456ybまし T0.022727272727272728yaた S0.06818181818181818ya。 T0.022727272727272728ya  T0.022727272727272728yb前回 T0.022727272727272728yb記事 T0.022727272727272728yb古く T0.022727272727272728ybなっ T0.022727272727272728yaて T0.022727272727272728ycしまっ T0.022727272727272728ya（ T0.022727272727272728ybから T0.022727272727272728ydコマンド T0.022727272727272728yaI T0.022727272727272728ya/ T0.022727272727272728yaF T0.022727272727272728yb変更 T0.022727272727272728ya） T0.022727272727272728>vc212<yc第5回 S0.03571428571428571y PElasticsearch勉強会 S0.03571428571428571yaを S0.03571428571428571yb開催 S0.03571428571428571yaし S0.03571428571428571ybまし S0.03571428571428571yaた S0.10714285714285714ya。 S0.07142857142857142ya  S0.07142857142857142yb遅く S0.03571428571428571ybなっ S0.03571428571428571yaて S0.07142857142857142yeしまいまし S0.03571428571428571yaが S0.03571428571428571ya、 S0.07142857142857142ydまとめて S0.03571428571428571ycみまし S0.03571428571428571yb今回 S0.03571428571428571yaは S0.03571428571428571ymElasticsearch S0.03571428571428571yaに S0.03571428571428571yb入っ S0.03571428571428571>vc213<ycという T0.023809523809523808ybこと S0.07142857142857142yaで S0.07142857142857142ya、 S0.07142857142857142yb転職 T0.047619047619047616yaし T0.047619047619047616ybまし T0.023809523809523808yaた S0.07142857142857142ya。 T0.047619047619047616ya  T0.047619047619047616ybどー T0.023809523809523808yaて T0.047619047619047616yaも T0.023809523809523808ybやり T0.023809523809523808ybたい T0.023809523809523808yaが T0.023809523809523808yb出て T0.023809523809523808yaき T0.023809523809523808yaの T0.023809523809523808yb無理 T0.023809523809523808yaを T0.023809523809523808yb言っ T0.023809523809523808ybする T0.023809523809523808ycにして T0.023809523809523808ycみまし T0.023809523809523808yfサムライズム T0.023809523809523808yaは T0.023809523809523808ybなく T0.023809523809523808yfElasti T0.023809523809523808>vc214<yb退職 T0.021739130434782608yaし T0.021739130434782608ybまし T0.021739130434782608yaた T0.043478260869565216ya。 S0.06521739130434782ya  S0.08695652173913043yb色々 T0.021739130434782608yaと T0.021739130434782608yb書き T0.021739130434782608ycたいん T0.021739130434782608yaで S0.08695652173913043yaす T0.043478260869565216yaが T0.021739130434782608ya、 T0.043478260869565216yb時差 T0.021739130434782608ybボケ T0.021739130434782608yb頭痛 T0.021739130434782608yaい T0.021739130434782608yaの T0.021739130434782608yeこのくらい T0.021739130434782608yc余裕出 T0.021739130434782608yaら T0.021739130434782608yb書く T0.021739130434782608yaか T0.021739130434782608yaも T0.021739130434782608ycほしい T0.021739130434782608ya物 T0.021739130434782608ycリスト T0.021739130434782608yaは T0.043478260869565216ycこちら T0.021739130434782608yc新天地 T0.021739130434782608ydについて T0.021739130434782608ybまた T0.021739130434782608ya明 T0.021739130434782608>vc215<ymElasticsearch R0.0196078431372549ya  S0.11764705882352941yfserver R0.0196078431372549yc2nd R0.0196078431372549ygedition R0.0196078431372549yaが T0.058823529411764705yb発売 R0.0196078431372549yaさ R0.0196078431372549yaれ R0.0196078431372549yaて R0.0196078431372549yaい R0.0196078431372549ybます R0.0196078431372549ya。 S0.09803921568627451ya私 R0.0196078431372549yb翻訳 R0.0196078431372549yaし R0.0196078431372549yaた R0.0392156862745098yaの R0.0392156862745098yaは R0.0392156862745098ya前 R0.0196078431372549yeバージョン R0.0196078431372549yaで R0.0196078431372549yaす R0.0196078431372549ybまず R0.0196078431372549ya、 R0.0196078431372549yb目次 R0.0196078431372549yaを R0.0392156862745098yb元に R0.0196078431372549yaど R0.0196078431372549ydのくらい R0.0196078431372549yc変わっ R0.0196078431372549ybてる R0.0196078431372549yaか R0.0196078431372549yb見て R0.0196078431372549ycみまし R0.0196078431372549ya（ R0.0196078431372549>vc216<yc可視化 S0.05128205128205128ycツール S0.05128205128205128ye現状確認会 S0.02564102564102564yaに S0.02564102564102564yb参加 S0.02564102564102564yaし S0.05128205128205128yaて S0.07692307692307693ya、 S0.05128205128205128yjカジュアルウォーター S0.02564102564102564yaじ S0.02564102564102564yaゃ S0.02564102564102564ybなく S0.02564102564102564yaの S0.02564102564102564yb現状 S0.02564102564102564yaを S0.02564102564102564yb確認 S0.02564102564102564ycきまし S0.02564102564102564yaた S0.02564102564102564ya。 S0.05128205128205128ya  S0.10256410256410256ycという S0.02564102564102564ybこと S0.02564102564102564yaで S0.02564102564102564ydいつもの S0.02564102564102564ybメモ S0.02564102564102564ybです S0.02564102564102564yhMackerel S0.02564102564102564yaと S0.02564102564102564yhGraphite S0.02564102564102564>vc217<yb今月 T0.037037037037037035yc2回目 T0.037037037037037035yaの R0.1111111111111111yb目黒 T0.037037037037037035yaで T0.037037037037037035ya、 T0.037037037037037035ya初 T0.037037037037037035ydドリコム T0.037037037037037035ybさん T0.037037037037037035ybです T0.037037037037037035ya。 T0.037037037037037035ya  S0.07407407407407407ya「 T0.037037037037037035yb最新 T0.037037037037037035ymインフラエンジニア技術勉強 T0.037037037037037035ya～ S0.07407407407407407ygFluentd T0.037037037037037035ya, S0.07407407407407407ymElasticsearch T0.037037037037037035ydChef T0.037037037037037035yb実践 T0.037037037037037035yb実例 T0.037037037037037035>vc218<ydどうやら S0.03571428571428571ya、 S0.07142857142857142yb中身 S0.03571428571428571yaが S0.03571428571428571ydSolr S0.03571428571428571ycベース S0.07142857142857142ya？ S0.07142857142857142yfLucene S0.03571428571428571yaに S0.03571428571428571ybなっ S0.03571428571428571ydたらしい S0.03571428571428571ycという S0.03571428571428571ybこと S0.03571428571428571yaで S0.03571428571428571ya  S0.07142857142857142yb今日 S0.03571428571428571yaは S0.03571428571428571ya「 S0.03571428571428571ycAWS S0.03571428571428571yiプロダクトシリーズ S0.03571428571428571ya｜ S0.03571428571428571yeよくわかる S0.03571428571428571yfAmazon S0.03571428571428571ybCl S0.03571428571428571>vc219<yb酔っe0.025yb払っe0.025yaてe0.075ybなんe0.025yaとd0.05ybなくe0.025yb書きe0.025ybたくe0.025ybなっd0.05yaたd0.05ygスピリチュアルe0.025yaなd0.05ycブログe0.025yaのe0.025yaでd0.05ya、d0.05yb流しe0.025yaいe0.025ycだけれe0.025yaばe0.025ya。e0.025ya e0.025yb最近e0.025yc勉強会e0.025yaやe0.025ygTwittere0.025yb知りe0.025yb合いe0.025yaにe0.025ya話e0.025yaをe0.025ybするe0.025>vc220<ya「 T0.023809523809523808ymアジャイルデータサイエンス T0.023809523809523808ya」 T0.023809523809523808yaの T0.023809523809523808yb見本 T0.023809523809523808yaを T0.023809523809523808yaい T0.023809523809523808yaた S0.07142857142857142ycだいて T0.023809523809523808yeしまいまし T0.023809523809523808ya。 T0.047619047619047616ya  S0.07142857142857142ybなの T0.023809523809523808yaで S0.07142857142857142ya、 T0.047619047619047616yc感想文 T0.023809523809523808yaも T0.023809523809523808yb書い T0.023809523809523808yaて T0.023809523809523808yaみ T0.023809523809523808ybよう T0.023809523809523808yaか T0.023809523809523808yaと T0.023809523809523808ybどん T0.023809523809523808yaな T0.023809523809523808ya本 T0.023809523809523808ya？ T0.023809523809523808yb想像 T0.023809523809523808yb以上 T0.023809523809523808yaに T0.047619047619047616yc薄かっ T0.023809523809523808yaす T0.023809523809523808yc物理的 T0.023809523809523808>vc221<ybこん S0.01818181818181818yaな S0.01818181818181818ydツイート S0.01818181818181818yaを S0.01818181818181818yc見つけ S0.01818181818181818yaた S0.01818181818181818yaの S0.03636363636363636yaで S0.05454545454545454ya、 S0.01818181818181818ykAggregation S0.01818181818181818ydサンプル S0.01818181818181818yaも S0.01818181818181818yc書こう S0.03636363636363636yaか S0.01818181818181818ybなと S0.01818181818181818ya。 S0.07272727272727272ya（ S0.01818181818181818ya前 S0.01818181818181818ybから S0.01818181818181818yaと S0.01818181818181818yb思っ S0.01818181818181818yaて S0.01818181818181818ybたん S0.01818181818181818yaす S0.01818181818181818yaが S0.01818181818181818ya） S0.01818181818181818ya  S0.18181818181818182ya@ S0.01818181818181818ymelasticsearch S0.01818181818181818ybHi S0.01818181818181818ya, S0.01818181818181818yeWould S0.01818181818181818ycyou S0.01818181818181818yfplease S0.01818181818181818ydtell S0.01818181818181818ybme S0.01818181818181818ycthe S0.01818181818181818ycway S0.01818181818181818ybto S0.01818181818181818>vc222<yb今日 S0.02857142857142857yaは S0.02857142857142857ymelasticsearch S0.02857142857142857ya- S0.02857142857142857ydkopf S0.02857142857142857yaの S0.05714285714285714yhAnalysis S0.02857142857142857yb画面 S0.02857142857142857yb紹介 S0.02857142857142857yaで S0.02857142857142857yaす S0.02857142857142857ya。 S0.11428571428571428ya  S0.05714285714285714ya（ S0.02857142857142857yb簡単 S0.02857142857142857yaな S0.02857142857142857yaと S0.05714285714285714ybころ S0.02857142857142857ybから S0.02857142857142857ybその S0.02857142857142857ya３ S0.02857142857142857ya） S0.02857142857142857ycちょっ S0.02857142857142857ybあい S0.02857142857142857yaだ S0.02857142857142857yaが S0.02857142857142857yb開い S0.02857142857142857yaて S0.02857142857142857yeしまいまし S0.02857142857142857>vc223<ydkopf S0.02857142857142857yaの S0.14285714285714285yb記事 S0.02857142857142857yb続き S0.02857142857142857yaも S0.02857142857142857yb書く S0.02857142857142857yb必要 S0.02857142857142857yaが S0.02857142857142857ybある S0.02857142857142857yaん S0.02857142857142857ycだけど S0.02857142857142857ya、 S0.05714285714285714ybこん S0.02857142857142857yaな S0.02857142857142857ydツイート S0.02857142857142857yaを S0.02857142857142857yd見つけて S0.02857142857142857ycしまっ S0.02857142857142857yaた S0.02857142857142857yaで S0.02857142857142857ya。 S0.08571428571428572ya  S0.05714285714285714ymElasticsearch S0.02857142857142857ydBulk S0.02857142857142857ycAPI S0.02857142857142857yb仕様 S0.02857142857142857yaJ S0.02857142857142857>vc224<yc第4回 T0.030303030303030304yoElsticsearch勉強会 T0.030303030303030304yaを T0.030303030303030304yb開催 T0.030303030303030304yaし T0.030303030303030304ybまし T0.030303030303030304yaた S0.09090909090909091ya。 S0.06060606060606061ya  S0.06060606060606061yb今回 T0.030303030303030304ybから S0.06060606060606061ya、 S0.06060606060606061yd遅刻厳禁 S0.06060606060606061yaに T0.030303030303030304ybして T0.030303030303030304ycみまし T0.030303030303030304ydそれほど T0.030303030303030304yb困っ T0.030303030303030304yc人もい T0.030303030303030304ybない T0.030303030303030304yaと T0.030303030303030304yb思う T0.030303030303030304yaの T0.030303030303030304yaで T0.030303030303030304yb次回 T0.030303030303030304yaも T0.030303030303030304>vc225<yb今日g0.03125yaはg0.03125ymelasticsearchg0.03125ya-g0.03125ydkopfg0.03125yaのg0.09375yhAnalysisg0.03125yb画面g0.03125yb紹介g0.03125yaでg0.03125yaすg0.03125ya。e0.125ya f0.0625ya（g0.03125yb簡単g0.03125yaなg0.03125yaとg0.03125ybころg0.03125ybからg0.03125ybそのg0.03125ya２g0.03125ya）g0.03125ydメニューg0.03125yhanalysisg0.03125yaをg0.03125yb選択g0.03125>vc226<ycJVM T0.020833333333333332ya  S0.10416666666666667yiOperation T0.020833333333333332yfCasual T0.020833333333333332yeTalks T0.020833333333333332yaに T0.020833333333333332yb参加 T0.020833333333333332yaし T0.020833333333333332ybまし T0.020833333333333332yaた T0.041666666666666664ya。 T0.041666666666666664ydあんまり T0.020833333333333332ya、f0.0625yb運用 T0.020833333333333332yaと T0.020833333333333332ycかやっ T0.020833333333333332yaてf0.0625ybない T0.020833333333333332yaの T0.041666666666666664yaでf0.0625ybつい T0.020833333333333332ycいける T0.020833333333333332yaか T0.020833333333333332yb不安 T0.020833333333333332yaす T0.020833333333333332yaが T0.020833333333333332yb楽し T0.020833333333333332ybそう T0.020833333333333332ybだっ T0.020833333333333332yc懇親会 T0.020833333333333332yaは T0.020833333333333332yb予定 T0.020833333333333332yaさ T0.020833333333333332yaれ T0.020833333333333332yeないらしい T0.020833333333333332>vc227<yb今日 S0.02631578947368421yaは S0.02631578947368421ymelasticsearch S0.02631578947368421ya- S0.02631578947368421ydkopf S0.02631578947368421yaの S0.10526315789473684ydREST S0.02631578947368421yb画面 S0.05263157894736842yb紹介 S0.02631578947368421yaで S0.02631578947368421yaす S0.02631578947368421ya。 S0.10526315789473684ya  S0.05263157894736842ya（ S0.02631578947368421yb簡単 S0.02631578947368421yaな S0.05263157894736842yaと S0.05263157894736842ybころ S0.02631578947368421ybから S0.02631578947368421ya） S0.02631578947368421ydメニュー S0.02631578947368421ydrest S0.02631578947368421yaを S0.02631578947368421yb選択 S0.02631578947368421ybする S0.02631578947368421ya、 S0.02631578947368421ya次 S0.02631578947368421ybよう S0.02631578947368421>vc228<ybなん S0.02631578947368421ybだか S0.02631578947368421ya、 S0.05263157894736842ydドタバタ S0.02631578947368421ybして S0.02631578947368421yaて S0.02631578947368421yb久し S0.02631578947368421ybぶり S0.02631578947368421yaの S0.10526315789473684yb更新 S0.02631578947368421yaで S0.05263157894736842yaす S0.05263157894736842ya。 S0.05263157894736842ya  S0.05263157894736842ydベルリン S0.02631578947368421yc旅行記 S0.02631578947368421yaみ S0.02631578947368421ybたい S0.05263157894736842yaな S0.02631578947368421yaも S0.02631578947368421yb書き S0.02631578947368421yaが S0.02631578947368421ybまず S0.02631578947368421yaは S0.02631578947368421ydこちらか S0.02631578947368421yaと S0.02631578947368421ymelasticsearch S0.02631578947368421ya- S0.02631578947368421ybko S0.02631578947368421>vc229<yb先日 S0.02857142857142857ya、 S0.05714285714285714ya「 S0.02857142857142857ymElasticSearch S0.02857142857142857ya  S0.05714285714285714yfServer S0.02857142857142857yaを S0.05714285714285714yb翻訳 S0.02857142857142857yaし S0.02857142857142857ybまし S0.02857142857142857yaた S0.08571428571428572ya」 S0.02857142857142857ycという S0.02857142857142857yb記事 S0.02857142857142857yd書きまし S0.02857142857142857ya。 S0.02857142857142857ybこの S0.02857142857142857ya中 S0.02857142857142857yaで S0.02857142857142857yc電子版 S0.05714285714285714yaも S0.05714285714285714yd出ますよ S0.02857142857142857yaと S0.02857142857142857yb書い S0.02857142857142857yaて S0.02857142857142857ycいまし S0.02857142857142857yaが S0.02857142857142857ya発 S0.02857142857142857>vc230<ydGOTO S0.02564102564102564ya  S0.10256410256410256yeNight S0.02564102564102564ymelasticsearch S0.02564102564102564yaに S0.05128205128205128yb参加 S0.02564102564102564yaし S0.05128205128205128ybまし S0.02564102564102564yaた S0.05128205128205128ya。 S0.05128205128205128ya初 S0.02564102564102564yaの S0.05128205128205128yb海外 S0.02564102564102564yc勉強会 S0.05128205128205128yaで S0.05128205128205128yaす S0.02564102564102564ya（ S0.02564102564102564yd海外自体 S0.02564102564102564yaが S0.02564102564102564yb初だ S0.02564102564102564ya） S0.02564102564102564ydベルリン S0.02564102564102564ybある S0.02564102564102564yeWooga S0.02564102564102564ycという S0.02564102564102564yb会社 S0.02564102564102564yb開催 S0.02564102564102564yaさ S0.02564102564102564yaれ S0.02564102564102564>vc231<yfBerlind0.05ycからおe0.025yaはe0.025ybようd0.05yeございますe0.025ya。d0.05ya d0.05ycというe0.025ybことe0.025yaでe0.075ya、d0.05yb人生e0.025yb初めe0.025yaてd0.05yaのe0.075yb海外d0.05yaにd0.05ya来e0.025yaいe0.025ybますe0.025yc人生初e0.025yaなd0.05yb一人e0.025yb乗りe0.025yb換えe0.025yaがe0.025ybあるe0.025>vc232<yb10 T0.043478260869565216ymelasticsearch S0.08695652173913043yaに S0.08695652173913043ya、 T0.043478260869565216ybこの T0.043478260869565216ybへん T0.043478260869565216yc入れる T0.043478260869565216ycときっ T0.043478260869565216yaと T0.043478260869565216yb幸せ T0.043478260869565216ycなれる T0.043478260869565216yaは T0.043478260869565216yaず T0.043478260869565216ya・ T0.043478260869565216ycたぶん T0.043478260869565216ya。 T0.043478260869565216ya& T0.043478260869565216ya# T0.043478260869565216ya; T0.043478260869565216ya/ T0.043478260869565216ylelasticsearc T0.043478260869565216>vc233<yc第3回 T0.041666666666666664y PElasticsearch勉強会 T0.041666666666666664yaで T0.041666666666666664ya、 S0.08333333333333333yb軽く T0.041666666666666664yb触れ T0.041666666666666664yaて T0.041666666666666664ycいまし T0.041666666666666664yaた T0.041666666666666664yaが S0.08333333333333333ymElasticSearch T0.041666666666666664ya  S0.08333333333333333yjServer日本語版 T0.041666666666666664yb発売 T0.041666666666666664yaさ T0.041666666666666664yaれ T0.041666666666666664ybます T0.041666666666666664ya。 T0.041666666666666664ydツイート T0.041666666666666664ybなど T0.041666666666666664yaも T0.041666666666666664>vc234<yc今年初 T0.029411764705882353yaの S0.08823529411764706ya「 T0.029411764705882353yb突撃 T0.029411764705882353ya！ T0.029411764705882353ya隣 T0.029411764705882353ymElasticsearch T0.029411764705882353ya」 T0.029411764705882353ycという T0.029411764705882353ybこと T0.029411764705882353yaで S0.08823529411764706ya、 T0.058823529411764705yhWantedly T0.029411764705882353ybさん T0.029411764705882353yhにおじゃましまし T0.029411764705882353yaた T0.058823529411764705ya。 T0.029411764705882353ya  T0.029411764705882353ya※ T0.029411764705882353yb写真 T0.029411764705882353yaを T0.029411764705882353yb自分 T0.029411764705882353yaも T0.029411764705882353yb撮っ T0.029411764705882353yaす T0.029411764705882353yaが T0.058823529411764705yb画像 T0.029411764705882353>vc235<yb今回 T0.027777777777777776yaは T0.027777777777777776ydたまたま T0.027777777777777776yb日本 T0.027777777777777776yaに S0.05555555555555555yaい T0.027777777777777776yaた S0.05555555555555555ymElasticsearch T0.027777777777777776yaの S0.08333333333333333ya人 T0.027777777777777776yaを T0.027777777777777776yhスペシャルゲスト T0.027777777777777776yb呼べ T0.027777777777777776yaで S0.05555555555555555ya、 T0.027777777777777776yc大満足 T0.027777777777777776yaす T0.027777777777777776yaｗ T0.027777777777777776ya  T0.027777777777777776yb英語 T0.027777777777777776yb通訳 T0.027777777777777776yaと S0.08333333333333333ydかちゃん T0.027777777777777776yb勉強 T0.027777777777777776yaし T0.027777777777777776ybない T0.027777777777777776ybなぁ T0.027777777777777776ya。 S0.05555555555555555>vc236<yfすずけんさん T0.037037037037037035yaが T0.037037037037037035ygVagrant T0.037037037037037035ya+ T0.037037037037037035yipuppet使って T0.037037037037037035ya、 S0.07407407407407407ybVM T0.037037037037037035yb起動 T0.037037037037037035yaし T0.037037037037037035yaて R0.1111111111111111ymElasticsearch T0.037037037037037035yaの S0.07407407407407407ydクラスタ T0.037037037037037035yaを R0.1111111111111111yb組ん T0.037037037037037035ybでる T0.037037037037037035yb記事 T0.037037037037037035yb書い T0.037037037037037035ybいる T0.037037037037037035yb見て T0.037037037037037035yb試し T0.037037037037037035>vc237<yd改訂新版 T0.029411764705882353ydSolr S0.08823529411764706yf入門出版記念 T0.029411764705882353yaと T0.029411764705882353ybいう T0.029411764705882353ybこと T0.029411764705882353yaで T0.058823529411764705ya、 S0.08823529411764706yd第13回 T0.029411764705882353yc勉強会 T0.029411764705882353ya  S0.08823529411764706ya# T0.029411764705882353yfSolrJP T0.029411764705882353ya新 T0.029411764705882353ye本出版記念 T0.029411764705882353yaを T0.029411764705882353yb開催 T0.029411764705882353yaし T0.029411764705882353ybまし T0.029411764705882353yaた T0.029411764705882353ya。 T0.029411764705882353yd出版記念 T0.029411764705882353yaな T0.029411764705882353yaの T0.029411764705882353yf技術評論社様 T0.029411764705882353ybより T0.029411764705882353ybプレ T0.029411764705882353>vc238<yb昨晩 S0.03225806451612903ya、 R0.0967741935483871ymElasticsearch S0.03225806451612903ybから S0.03225806451612903ya初 S0.03225806451612903yaの S0.03225806451612903yeプロダクト S0.03225806451612903yaと S0.06451612903225806ybなる S0.03225806451612903yfMarvel S0.03225806451612903yaが S0.03225806451612903ydリリース S0.03225806451612903yaさ S0.03225806451612903yaれ S0.03225806451612903ybまし S0.03225806451612903yaた S0.03225806451612903ya。 S0.03225806451612903ycという S0.03225806451612903ybこと S0.03225806451612903yaで S0.03225806451612903ydさっそく S0.03225806451612903yb触っ S0.03225806451612903yaて S0.03225806451612903ybみて S0.03225806451612903yb簡単 S0.03225806451612903yaな S0.03225806451612903yb紹介 S0.03225806451612903yb感想 S0.03225806451612903>vc239<ya1 S0.02564102564102564ya4 S0.05128205128205128ya6 S0.05128205128205128yfLucene S0.02564102564102564ya/ S0.02564102564102564ydSolr S0.02564102564102564ya  S0.05128205128205128ya. S0.10256410256410256yaが S0.02564102564102564ydリリース S0.05128205128205128yaさ S0.02564102564102564yaれ S0.02564102564102564ybそう S0.02564102564102564ya( S0.02564102564102564ydバイナリ S0.02564102564102564yc配布待 S0.02564102564102564yaち S0.02564102564102564ya) S0.02564102564102564yflucene S0.02564102564102564ya- S0.02564102564102564yegosen S0.02564102564102564yaの S0.05128205128205128yb1対 S0.02564102564102564yb応版 S0.02564102564102564yaを S0.02564102564102564ycしまし S0.02564102564102564yaた S0.02564102564102564ya。 S0.02564102564102564yeライブラリ S0.02564102564102564ygインタフェース S0.02564102564102564yaな S0.02564102564102564>vc240<ymElasticsearchd0.04yaのd0.08ygcuratord0.04ycブログd0.04yb記事d0.04yaをd0.04yb読んd0.04yaでd0.08ya、d0.08yc日本語d0.08ydツイートd0.04yaしd0.04yaたd0.04yaとd0.04ybころd0.04yeAarond0.04ya d0.04ykMildensteind0.04ybさんd0.04ybからd0.04ya（d0.04>vc241<ydあけまし T0.034482758620689655yaて S0.06896551724137931ybおめ T0.034482758620689655yaで S0.06896551724137931ygとうございます T0.034482758620689655ya。 S0.06896551724137931yb今年 T0.034482758620689655yaも T0.034482758620689655ydSolr T0.034482758620689655yaや T0.034482758620689655ymElasticsearch T0.034482758620689655ydについて T0.034482758620689655yb色々 T0.034482758620689655yaと T0.034482758620689655yc頑張っ T0.034482758620689655ybいく T0.034482758620689655yb所存 T0.034482758620689655yaす T0.034482758620689655ya  T0.034482758620689655ycとまぁ T0.034482758620689655ya、 T0.034482758620689655ydお決まり T0.034482758620689655yaの T0.034482758620689655yb挨拶 T0.034482758620689655yaは T0.034482758620689655ycおいて T0.034482758620689655>vc242<yb昨年 T0.022727272727272728yaは T0.045454545454545456ya、 T0.045454545454545456yc大晦日 T0.022727272727272728yaに T0.045454545454545456yb書い T0.045454545454545456yaて T0.022727272727272728ybまし T0.022727272727272728yaた S0.09090909090909091ya。 T0.045454545454545456ya  S0.06818181818181818ycちょっ T0.022727272727272728yaと T0.022727272727272728yb進歩 T0.022727272727272728yaし T0.022727272727272728ybかも T0.022727272727272728yb振り T0.045454545454545456yb返り T0.045454545454545456ya( T0.022727272727272728ye2012年 T0.022727272727272728yb抱負 T0.045454545454545456ybから T0.045454545454545456ya) T0.022727272727272728ycという T0.022727272727272728ybこと T0.022727272727272728yaで T0.045454545454545456ybまず T0.022727272727272728yd昨年書い T0.022727272727272728yaの T0.022727272727272728>vc243<ya0 S0.05405405405405406ya8 S0.05405405405405406yb90 S0.05405405405405406yb昨夜 S0.02702702702702703ya、 S0.05405405405405406ymElasticsearch S0.02702702702702703yaの S0.05405405405405406ya. S0.10810810810810811yaが S0.02702702702702703ydリリース S0.05405405405405406yaさ S0.05405405405405406yaれ S0.05405405405405406ybまし S0.02702702702702703yaた S0.05405405405405406ya。 S0.02702702702702703ya  S0.05405405405405406yb内容 S0.02702702702702703ybなど S0.02702702702702703ydについて S0.02702702702702703yaは S0.02702702702702703yb本家 S0.02702702702702703ycブログ S0.02702702702702703ya「 S0.02702702702702703yfreleas S0.02702702702702703>vc244<ydSolr S0.02564102564102564ya本 S0.02564102564102564yaが S0.02564102564102564yb出て S0.02564102564102564ybから S0.02564102564102564ya、 S0.02564102564102564yb質問 S0.05128205128205128yaを S0.07692307692307693yb受け S0.05128205128205128yaて S0.05128205128205128ycブログ S0.02564102564102564yb書く S0.02564102564102564yaと S0.02564102564102564yb言い S0.02564102564102564ybなが S0.02564102564102564yaら S0.02564102564102564yb書い S0.02564102564102564ycなかっ S0.02564102564102564yaた S0.05128205128205128ybこと S0.02564102564102564yb思い S0.02564102564102564yd出しまし S0.02564102564102564ya。 S0.07692307692307693ya  S0.02564102564102564yeプラグイン S0.02564102564102564yaの S0.02564102564102564yb配置 S0.02564102564102564yb方法 S0.02564102564102564ydについて S0.02564102564102564ybこん S0.02564102564102564yaな S0.02564102564102564>vc245<ybどもg0.03125ya。g0.03125ya g0.09375yeプラグインg0.03125yaのf0.0625yfインストールg0.03125yaにg0.03125yb長いg0.03125ycURLg0.03125ya入g0.03125ybれるg0.03125yb辛いg0.03125yaでg0.09375ycすよねg0.03125ya？f0.0625yaねg0.03125ycというg0.03125ybことg0.03125ya、g0.03125yeMavenf0.0625ydリリースg0.03125yaしg0.03125yaてg0.03125yjRepositoryg0.03125ybからg0.03125>vc246<yb12 T0.023809523809523808yb少し T0.023809523809523808yb遅く T0.023809523809523808ybなっ T0.023809523809523808yaて T0.023809523809523808yeしまいまし T0.023809523809523808yaた T0.047619047619047616yaが T0.023809523809523808ya、 T0.023809523809523808ya/ T0.023809523809523808yb05 T0.023809523809523808yaに T0.023809523809523808yb電子 T0.047619047619047616yb書籍 S0.07142857142857142yaも T0.023809523809523808yb発売 T0.023809523809523808yaさ T0.023809523809523808yaれ T0.023809523809523808ybまし T0.023809523809523808ya。 T0.047619047619047616ya  S0.07142857142857142ye技術評論社 T0.023809523809523808yaの S0.07142857142857142ycサイト T0.023809523809523808ybから T0.023809523809523808yb購入 T0.023809523809523808yb可能 T0.023809523809523808yaで T0.023809523809523808yaす T0.023809523809523808ycページ T0.023809523809523808yaへ T0.023809523809523808ycリンク T0.023809523809523808ycPDF T0.023809523809523808>vc247<yc勉強会 T0.047619047619047616yaで T0.047619047619047616yb宣伝 T0.023809523809523808yaも T0.047619047619047616ycしまし T0.023809523809523808yaた T0.047619047619047616yaが T0.023809523809523808ya、 S0.07142857142857142yc改めて T0.023809523809523808ya。 S0.07142857142857142ya  S0.07142857142857142ydSolr S0.07142857142857142yb入門 T0.047619047619047616yaの T0.023809523809523808yc改訂版 T0.023809523809523808yaを T0.023809523809523808yb執筆 T0.023809523809523808yaし T0.023809523809523808ybまし T0.023809523809523808yb考え T0.023809523809523808yaて T0.023809523809523808ybみれ T0.023809523809523808yaば T0.023809523809523808ybもう T0.023809523809523808yb3年 T0.023809523809523808yc前なん T0.023809523809523808ybすね T0.023809523809523808yaは T0.023809523809523808yaな T0.023809523809523808>vc248<ybどー T0.029411764705882353yaも T0.029411764705882353ya。 T0.058823529411764705yb以前 T0.029411764705882353yaの T0.029411764705882353yb記事 T0.029411764705882353yaで S0.08823529411764706yb開発 T0.029411764705882353ya中 T0.029411764705882353ybとし T0.029411764705882353yaて T0.029411764705882353yaい T0.029411764705882353yaた T0.058823529411764705yeプラグイン T0.029411764705882353yaす T0.029411764705882353yaが T0.029411764705882353ya、 T0.058823529411764705ybとり T0.029411764705882353ycあえず T0.029411764705882353yfplugin T0.029411764705882353ydコマンド T0.029411764705882353yfインストール T0.058823529411764705yc出来る T0.029411764705882353yb形に T0.029411764705882353ybして T0.029411764705882353ycみまし T0.029411764705882353ya  T0.029411764705882353ybなど T0.029411764705882353>vc249<yc第2回 S0.02631578947368421yaを S0.05263157894736842yb開催 S0.02631578947368421yaし S0.05263157894736842ybまし S0.02631578947368421yaた S0.05263157894736842ya！ S0.05263157894736842ya  S0.05263157894736842ycすごい S0.02631578947368421ya、 S0.05263157894736842yj140人くらいくらい S0.02631578947368421yaの S0.02631578947368421ye参加登録者 S0.02631578947368421ya（ S0.02631578947368421yc参加者 S0.02631578947368421yaは S0.02631578947368421yd１００人 S0.02631578947368421yaち S0.02631578947368421ybょっ S0.02631578947368421yaと S0.02631578947368421ya） S0.02631578947368421ycがいて S0.02631578947368421ydびっくり S0.02631578947368421yaで S0.02631578947368421yaす S0.02631578947368421ya。 S0.02631578947368421ycステキ S0.02631578947368421yaな S0.02631578947368421yb会場 S0.02631578947368421yb提供 S0.02631578947368421yaて S0.02631578947368421yaい S0.02631578947368421>vc250<yd2013 T0.019230769230769232yhCloudera T0.019230769230769232ya  S0.09615384615384616yeWorld T0.019230769230769232yeTokyo T0.019230769230769232yaに T0.019230769230769232yb参加 T0.057692307692307696yaし T0.057692307692307696yaて T0.038461538461538464ycきまし T0.019230769230769232yaた S0.07692307692307693ya。 T0.038461538461538464yc午前中 T0.019230769230769232yaは T0.019230769230769232ybあい T0.019230769230769232ybにく T0.019230769230769232yaの T0.038461538461538464ya雨 T0.019230769230769232yaで T0.038461538461538464yaが T0.057692307692307696ya、 T0.019230769230769232ybそれ T0.019230769230769232yaも T0.019230769230769232yb結構 T0.019230769230769232yaな T0.019230769230769232yb人数 T0.019230769230769232yb最初 T0.019230769230769232yb基調 T0.019230769230769232yb講演 T0.019230769230769232ybから T0.019230769230769232yaさ T0.019230769230769232yaれ T0.019230769230769232ybまし T0.019230769230769232ya私 T0.019230769230769232ydセッショ T0.019230769230769232>vc251<ya0 T0.022727272727272728ya2 T0.022727272727272728ya3 T0.022727272727272728ydまたまた T0.022727272727272728ya、 T0.045454545454545456ydRiak T0.045454545454545456ya  S0.09090909090909091yfMeetup T0.022727272727272728yeTokyo T0.022727272727272728ya# T0.022727272727272728yaに T0.045454545454545456yb参加 T0.022727272727272728yaし T0.022727272727272728yaて T0.022727272727272728ycきまし T0.022727272727272728yaた T0.045454545454545456ya。 T0.045454545454545456ya. T0.022727272727272728yaの S0.06818181818181818yhYokozuna T0.022727272727272728ya話 T0.022727272727272728yaが T0.022727272727272728ybある T0.022727272727272728yaと T0.022727272727272728yb聞い T0.022727272727272728yaで S0.06818181818181818ycという T0.022727272727272728ybこと T0.022727272727272728ydいつもの T0.022727272727272728ybよう T0.022727272727272728yb個人 T0.022727272727272728ybメモ T0.022727272727272728>vc252<yc開発中 S0.02857142857142857yaで S0.08571428571428572yaす S0.08571428571428572yaと S0.08571428571428572yd書きまし S0.02857142857142857yaた S0.05714285714285714ya、 S0.05714285714285714ymelasticsearch S0.02857142857142857ya- S0.05714285714285714yhextended S0.02857142857142857yganalyze S0.02857142857142857yaが S0.02857142857142857yb改良 S0.05714285714285714yaし S0.02857142857142857ybまし S0.02857142857142857ya。 S0.05714285714285714ya  S0.05714285714285714yb変更 S0.02857142857142857yaは S0.02857142857142857yb以下 S0.02857142857142857yaの S0.02857142857142857ybおり S0.02857142857142857ybソー S0.02857142857142857>vc253<yeお久しぶり S0.02857142857142857yaで S0.05714285714285714yaす S0.05714285714285714ya。 S0.11428571428571428ya  S0.05714285714285714yc気づい S0.02857142857142857ydたらまた S0.02857142857142857ya、 S0.05714285714285714yb結構 S0.02857142857142857ycブログ S0.02857142857142857yaを S0.02857142857142857yb書い S0.02857142857142857yaて S0.05714285714285714ycなかっ S0.02857142857142857yaた S0.02857142857142857yb今回 S0.02857142857142857yaは S0.02857142857142857yc今開発 S0.02857142857142857yaし S0.02857142857142857ybいる S0.02857142857142857ymElasticsearch S0.02857142857142857yaの S0.02857142857142857yeプラグイン S0.02857142857142857yaに S0.02857142857142857yc関する S0.02857142857142857yaお S0.02857142857142857ya話 S0.02857142857142857>vc254<ye不定期開催e0.025yaでe0.075yaすd0.05yaがe0.075ya第e0.025yc12回e0.025ydSolre0.025yc勉強会e0.025yaをe0.025yb主催e0.025yaしe0.025ybましe0.025yaたd0.05ya。e0.025ya e0.025yb今回e0.025yaはd0.05ya、d0.05yb前回e0.025ybほどd0.05yaのe0.075yb過熱e0.025ybぶりe0.025yc無かっe0.025yc70人e0.025yc参加者e0.025ya方e0.025yfいらっしゃっe0.025ybたかe0.025>vc255<yb今日d0.05yaはd0.05ya、d0.05ymElasticSearchd0.05yaのc0.1ybMLd0.05yaでc0.1yc見つけd0.05yaたd0.05ymelasticsearchd0.05ya-d0.05yjinquisitord0.05yeプラグインd0.05yb紹介d0.05yaすd0.05ya。d0.05ya d0.05yjElasticSead0.05>vc256<yeriver S0.02857142857142857ya- S0.02857142857142857yiwikipedia S0.02857142857142857yaの S0.08571428571428572yc前々回 S0.02857142857142857yb記事 S0.02857142857142857yaで S0.02857142857142857yd書きまし S0.02857142857142857yaた S0.02857142857142857yaが S0.11428571428571428ya、 S0.02857142857142857ydbulk S0.02857142857142857ya_ S0.02857142857142857ydsize S0.02857142857142857yaに S0.05714285714285714yb関連 S0.02857142857142857yaし S0.02857142857142857yaて S0.05714285714285714yb登録 S0.02857142857142857yb件数 S0.02857142857142857ybやけ S0.02857142857142857ycにきり S0.02857142857142857yb良い S0.02857142857142857ya気 S0.02857142857142857ybなる S0.02857142857142857yaと S0.02857142857142857yb書い S0.02857142857142857ycいまし S0.02857142857142857>vc257<ye前々回紹介 S0.03333333333333333yaし S0.06666666666666667yaた S0.03333333333333333ya、 S0.06666666666666667yc日本語 S0.03333333333333333yiWikipedia S0.03333333333333333yaのc0.1ycデータ S0.03333333333333333yaを S0.06666666666666667yfインデックス S0.03333333333333333yb登録 S0.03333333333333333ybする S0.03333333333333333yb記事 S0.03333333333333333yb続き S0.03333333333333333yaで S0.03333333333333333yaす S0.03333333333333333ya。 S0.03333333333333333ya  S0.03333333333333333yb今回 S0.03333333333333333yaは S0.03333333333333333yhKuromoji S0.03333333333333333yeアナライザ S0.03333333333333333yb利用 S0.03333333333333333yaて S0.03333333333333333ydインデッ S0.03333333333333333>vc258<y PElasticSearch勉強会 T0.037037037037037035ya  R0.1111111111111111ya第 T0.037037037037037035yb1回 T0.037037037037037035yaを T0.037037037037037035yb主催 T0.037037037037037035yaし T0.037037037037037035ybまし T0.037037037037037035yaた S0.07407407407407407ya。 S0.07407407407407407yb昨年 T0.037037037037037035yaの T0.037037037037037035yepyfes T0.037037037037037035yaで S0.07407407407407407yfなんちゃって T0.037037037037037035yb資料 T0.037037037037037035yb喋っ T0.037037037037037035yaて T0.037037037037037035ya、 T0.037037037037037035yb1年 T0.037037037037037035ydたちまし T0.037037037037037035ymElasticSearch T0.037037037037037035>vc259<yb久々 S0.03225806451612903yaの S0.06451612903225806ycブログ S0.03225806451612903yaは S0.03225806451612903yoElasticSearchネタ S0.03225806451612903ybです S0.03225806451612903ya。 S0.06451612903225806ye勉強会開催 S0.03225806451612903ybする S0.06451612903225806yb予定 S0.03225806451612903ybだっ S0.03225806451612903ycたりす S0.03225806451612903yaで S0.03225806451612903ya、 S0.03225806451612903ybもう S0.03225806451612903yb少し S0.03225806451612903yb触っ S0.03225806451612903yaて S0.03225806451612903ybおき S0.03225806451612903ybたい S0.03225806451612903ybなと S0.03225806451612903ya  S0.03225806451612903yaお S0.03225806451612903yb手軽 S0.03225806451612903yaに S0.03225806451612903yb検索 S0.03225806451612903ycデータ S0.03225806451612903ycとして S0.03225806451612903>vc260<ya2 S0.02857142857142857yb宿題 S0.02857142857142857ybその S0.02857142857142857ya？ S0.05714285714285714yaか S0.02857142857142857yaな S0.02857142857142857ya。 S0.02857142857142857ydSolr S0.02857142857142857yc勉強会 S0.02857142857142857yaで S0.02857142857142857yhCloudera S0.02857142857142857ya  S0.05714285714285714yfSearch S0.02857142857142857yaの S0.05714285714285714ydスキーマ S0.02857142857142857yc周りっ S0.02857142857142857yaて S0.08571428571428572ybどう S0.02857142857142857ybなっ S0.05714285714285714ybてる S0.02857142857142857ycという S0.02857142857142857yb質問 S0.02857142857142857yaが S0.02857142857142857yb出て S0.02857142857142857ya、 S0.02857142857142857ycなんか S0.02857142857142857yc調べる S0.02857142857142857ybこと S0.02857142857142857yaに S0.02857142857142857>vc261<yd今朝起き S0.02564102564102564ybたら S0.02564102564102564ya、 S0.05128205128205128yfXperia S0.02564102564102564ya  S0.05128205128205128yaZ S0.02564102564102564yaが S0.02564102564102564yb故障 S0.02564102564102564yaし S0.02564102564102564yaて S0.05128205128205128yeしまいまし S0.02564102564102564yaた S0.02564102564102564ya。 R0.1282051282051282yb電源 S0.02564102564102564ycボタン S0.02564102564102564yaを S0.02564102564102564yb押し S0.02564102564102564yaも S0.05128205128205128ydスリープ S0.05128205128205128yaに S0.02564102564102564ybなら S0.02564102564102564ycないん S0.02564102564102564yaで S0.02564102564102564yaす S0.02564102564102564ycしかも S0.02564102564102564ybから S0.02564102564102564yaの S0.02564102564102564yb復帰 S0.02564102564102564ybでき S0.02564102564102564ybない S0.02564102564102564>vc262<yjMorphlines T0.027777777777777776ydについて T0.027777777777777776ycちょっ S0.05555555555555555yaと S0.08333333333333333ybだけ T0.027777777777777776ya、 S0.05555555555555555ybさら T0.027777777777777776yaに T0.027777777777777776yd調べまし T0.027777777777777776yaた S0.05555555555555555ya。 T0.027777777777777776ya  S0.05555555555555555yb誤解 S0.05555555555555555ydSolr T0.027777777777777776yc勉強会 T0.027777777777777776yaで S0.05555555555555555ybなん T0.027777777777777776ybなく T0.027777777777777776ya私 T0.027777777777777776yaの T0.027777777777777776yb認識 T0.027777777777777776yaを T0.027777777777777776yd話しまし T0.027777777777777776yaが T0.027777777777777776yaし T0.027777777777777776yaて T0.027777777777777776ybたみ T0.027777777777777776ybたい T0.027777777777777776>vc263<ye不定期開催 T0.029411764705882353yaで T0.029411764705882353yaす T0.029411764705882353yaが T0.058823529411764705ya第 T0.029411764705882353yc11回 T0.029411764705882353ydSolr T0.029411764705882353yc勉強会 T0.029411764705882353yaを T0.029411764705882353yb主催 T0.029411764705882353yaし T0.029411764705882353ybまし T0.029411764705882353yaた T0.058823529411764705ya。 T0.058823529411764705ya  T0.029411764705882353yb今回 T0.029411764705882353yaも T0.029411764705882353yc大入り T0.029411764705882353yf90人くらい T0.029411764705882353ya？ T0.029411764705882353yaの T0.058823529411764705yc参加者 T0.029411764705882353yc皆さん T0.029411764705882353yiがいらっしゃいまし T0.029411764705882353ybあり T0.029411764705882353ybたい T0.029411764705882353ybこと T0.029411764705882353ybです T0.029411764705882353ya！ T0.029411764705882353ya（ T0.029411764705882353>vc264<yfHadoop S0.02702702702702703ybとか S0.02702702702702703yb離れ S0.02702702702702703ycちゃっ S0.02702702702702703ybてる S0.02702702702702703yaし S0.05405405405405406ya、 S0.02702702702702703ydHive S0.02702702702702703yb触っ S0.02702702702702703yaた S0.05405405405405406ybこと S0.02702702702702703yb無い S0.02702702702702703yaに S0.02702702702702703yfもかかわらず S0.02702702702702703yb参加 S0.02702702702702703ybまし S0.02702702702702703ya！ S0.02702702702702703ya  S0.05405405405405406ya（ S0.02702702702702703ydたまたま S0.02702702702702703yb近く S0.02702702702702703ycにいる S0.02702702702702703ycからっ S0.02702702702702703yaて S0.02702702702702703yb理由 S0.02702702702702703yaな S0.02702702702702703yaの S0.05405405405405406yaは S0.02702702702702703yb内緒 S0.02702702702702703yaで S0.02702702702702703ya） S0.02702702702702703yb玉川 S0.02702702702702703ybさん S0.02702702702702703>vc265<yhYokozuna S0.02702702702702703yaの S0.05405405405405406ya気 S0.02702702702702703yaに S0.08108108108108109ybなる S0.02702702702702703ya点 S0.02702702702702703ydというか S0.02702702702702703ya、 S0.05405405405405406yb自分 S0.02702702702702703ybだっ S0.02702702702702703ybたら S0.02702702702702703ybこの S0.02702702702702703ybへん S0.02702702702702703yc調べる S0.05405405405405406ycだろう S0.02702702702702703ybなっ S0.02702702702702703yaて S0.05405405405405406yb観点 S0.02702702702702703yaを S0.02702702702702703yb上げ S0.02702702702702703ycみます S0.02702702702702703ya。 S0.02702702702702703ya  S0.02702702702702703ya別 S0.02702702702702703ydわけじゃ S0.02702702702702703ybない S0.02702702702702703yaで S0.02702702702702703yb完全 S0.02702702702702703yb自己 S0.02702702702702703yb満足 S0.02702702702702703yaな S0.02702702702702703>vc266<ya2 T0.023809523809523808yb先日 T0.023809523809523808ya、 T0.047619047619047616yeBasho T0.023809523809523808ybさん T0.023809523809523808yfにおじゃまし T0.023809523809523808yaた S0.07142857142857142yaの T0.047619047619047616yaも S0.07142857142857142ybあり T0.023809523809523808ydRiak T0.023809523809523808ya  S0.11904761904761904yfMeetup T0.023809523809523808yeTokyo T0.023809523809523808ya# T0.023809523809523808yaに T0.023809523809523808yb参加 T0.047619047619047616yaし T0.047619047619047616ybまし T0.047619047619047616ya。 S0.07142857142857142yhYokozuna T0.023809523809523808ya話 T0.023809523809523808yc聞ける T0.023809523809523808ycという T0.023809523809523808ybこと T0.023809523809523808yaで T0.023809523809523808yc懇親会 T0.023809523809523808>vc267<ya4d0.05yd4897e0.025ydSolre0.025ya d0.05ya.e0.025yaにd0.05yf取り込まれるe0.025yb予定e0.025yaのd0.05ydチケットd0.05yaでe0.025ya、e0.025ya気e0.025ybなるd0.05ybものd0.05yaをe0.025yc見つけe0.025yaたd0.05ycでいつe0.025yaごe0.025ybとくe0.025yb調べe0.025yaてe0.025ycみましe0.025ya。d0.05ya元e0.025yaとe0.025yaはe0.025ycこちらe0.025ydSOLRe0.025ya-e0.025>vc268<ydSolr T0.023255813953488372yaの T0.046511627906976744ydチケット S0.06976744186046512yaを T0.046511627906976744ybML T0.023255813953488372yb経由 T0.023255813953488372yaで S0.09302325581395349yb眺め T0.023255813953488372ybてる T0.046511627906976744yaん T0.023255813953488372yaす T0.023255813953488372yaが T0.046511627906976744ya、 T0.023255813953488372yb便利 T0.023255813953488372ybそう T0.023255813953488372yaな T0.023255813953488372yb流れ T0.023255813953488372yaて T0.046511627906976744yaき T0.023255813953488372yaた T0.023255813953488372ycブログ T0.023255813953488372yb書い T0.023255813953488372ybみみ T0.023255813953488372ybよう T0.023255813953488372yaか T0.023255813953488372yaと T0.023255813953488372ya。 T0.023255813953488372ya  T0.023255813953488372ya元 T0.023255813953488372yaに T0.023255813953488372ybなっ T0.023255813953488372yaは T0.023255813953488372ycこちら T0.023255813953488372>vc269<ya3 T0.023255813953488372yb前回 T0.046511627906976744yaは S0.09302325581395349yc3番煎 T0.023255813953488372yaじ T0.023255813953488372ycぐらい T0.023255813953488372yaで T0.046511627906976744yaし T0.023255813953488372yaた T0.046511627906976744yaが T0.023255813953488372ya、 T0.046511627906976744yb今回 T0.023255813953488372yc初記事 T0.023255813953488372yaか T0.023255813953488372yaな T0.046511627906976744ya？ T0.023255813953488372ya（ T0.023255813953488372yaだ T0.023255813953488372ycといい T0.023255813953488372ya） T0.023255813953488372ya  T0.023255813953488372yfKibana T0.046511627906976744yaに T0.046511627906976744yaの S0.06976744186046512yb記事 T0.023255813953488372yb書い T0.023255813953488372ybもの T0.023255813953488372yaと T0.023255813953488372ya別 T0.023255813953488372yc開発中 T0.023255813953488372ycという T0.023255813953488372>vc270<yfちょくちょく T0.024390243902439025yc書こう T0.024390243902439025yaと T0.024390243902439025yb言い T0.024390243902439025yaな T0.024390243902439025yaが S0.04878048780487805yaら T0.024390243902439025ya、 S0.04878048780487805ya前 T0.024390243902439025yaの T0.024390243902439025yb記事 T0.024390243902439025yc1週間 T0.024390243902439025yc以上前 T0.024390243902439025yaに S0.07317073170731707ybなっ T0.024390243902439025ybてる T0.024390243902439025ya。 R0.0975609756097561ya  S0.07317073170731707yb昨日 T0.024390243902439025yaは T0.024390243902439025yeBasho T0.024390243902439025yeJapan T0.024390243902439025yb遊び T0.024390243902439025yb行っ T0.024390243902439025yaて T0.024390243902439025yc来まし T0.024390243902439025yaた S0.04878048780487805ya（ T0.024390243902439025ydRiak T0.024390243902439025yb触っ T0.024390243902439025yaこ T0.024390243902439025>vc271<ya1 S0.02127659574468085ya3 S0.02127659574468085ya4 S0.02127659574468085yfLucene S0.02127659574468085ya/ S0.02127659574468085ydSolr S0.02127659574468085ya  S0.06382978723404255ya. R0.0425531914893617yaの R0.0851063829787234ybRC S0.02127659574468085ydVote S0.02127659574468085yaが S0.06382978723404255yc始まっ S0.02127659574468085yaて R0.0425531914893617ycいます S0.02127659574468085ya、 R0.0425531914893617ybその S0.02127659574468085ybML S0.02127659574468085ybでき S0.02127659574468085yaに S0.02127659574468085ybなっ S0.02127659574468085yaた R0.0425531914893617ybコト S0.02127659574468085ybあり S0.02127659574468085ycちょっ S0.02127659574468085yaと S0.02127659574468085yb調べ S0.02127659574468085yaで S0.02127659574468085ybメモ S0.02127659574468085yaを S0.02127659574468085yb残し S0.02127659574468085ydおきます S0.02127659574468085ya。 S0.02127659574468085yeマルチコア S0.02127659574468085yb設定 S0.02127659574468085ybファ S0.02127659574468085>vc272<ybもう T0.030303030303030304yc何番煎 T0.030303030303030304yaじ T0.030303030303030304yaだ T0.030303030303030304yc？って T0.030303030303030304ycくらい T0.030303030303030304yb書か T0.030303030303030304yaれ T0.030303030303030304yaて S0.09090909090909091ybます T0.030303030303030304yaが T0.030303030303030304ya、 S0.06060606060606061ybコリ T0.030303030303030304ycもせず T0.030303030303030304yb書い T0.030303030303030304ycみまし T0.030303030303030304yaた T0.030303030303030304ya。 T0.030303030303030304ya  T0.030303030303030304ymElasticsearch T0.030303030303030304ya＋ T0.030303030303030304yfKibana T0.030303030303030304yaの S0.06060606060606061yb環境 T0.030303030303030304yaを T0.030303030303030304yb作っ T0.030303030303030304ydタムタム T0.030303030303030304ybさん T0.030303030303030304yaロ T0.030303030303030304>vc273<yd2013 S0.02631578947368421yb昨日 S0.02631578947368421yaに S0.05263157894736842yb引き S0.02631578947368421yb続き S0.02631578947368421ya、 S0.05263157894736842ycAWS S0.02631578947368421ya  S0.10526315789473684yfSummit S0.02631578947368421yeTokyo S0.02631578947368421yb行っ S0.02631578947368421yaて S0.02631578947368421ycきまし S0.02631578947368421yaた S0.05263157894736842ya。 S0.02631578947368421ya@ S0.02631578947368421ycryu S0.02631578947368421ya_ S0.02631578947368421yikobayashi S0.02631578947368421ybさん S0.02631578947368421ybから S0.02631578947368421ycパシリ S0.02631578947368421yaを S0.02631578947368421ye仰せつかる S0.02631578947368421ybなど S0.02631578947368421ybあり S0.02631578947368421yd忙しかっ S0.02631578947368421yaの S0.02631578947368421yaで S0.02631578947368421yaす S0.02631578947368421yaが S0.02631578947368421yc楽しか S0.02631578947368421>vc274<ybざっ S0.03333333333333333yaと S0.03333333333333333yiインストールガイド S0.03333333333333333ybとか S0.03333333333333333yhCloudera S0.03333333333333333ya  S0.06666666666666667yfSearch S0.03333333333333333yaの S0.03333333333333333yeソース眺め S0.03333333333333333yaて S0.06666666666666667ya、 S0.03333333333333333ydテキトー S0.03333333333333333yaに S0.03333333333333333ybメモ S0.03333333333333333yaを S0.03333333333333333yb書い S0.03333333333333333ycみまし S0.03333333333333333yaた S0.03333333333333333ya。 S0.06666666666666667ya（ S0.03333333333333333yfユーザガイド S0.03333333333333333yaは S0.03333333333333333ybまだ S0.03333333333333333yb読ん S0.03333333333333333yaで S0.03333333333333333ybない S0.03333333333333333ybです S0.03333333333333333>vc275<yd2013 T0.023255813953488372ycAWS T0.023255813953488372ya  S0.11627906976744186yfSummit T0.023255813953488372yeTokyo T0.023255813953488372yaに S0.09302325581395349yb行っ T0.023255813953488372yaて T0.046511627906976744yc来まし T0.023255813953488372yaた S0.06976744186046512ya。 T0.046511627906976744ya@ T0.046511627906976744yicocoatomo T0.023255813953488372ybさん T0.023255813953488372yb行き T0.023255813953488372yb掛け T0.023255813953488372yc出会っ T0.023255813953488372yaの S0.06976744186046512yaで T0.023255813953488372ya、 T0.023255813953488372yfアンデルセン T0.023255813953488372yb講演 T0.023255813953488372yaを T0.023255813953488372yb一緒 T0.023255813953488372yb聞い T0.023255813953488372ybまし T0.023255813953488372ybTD T0.023255813953488372ycブース T0.023255813953488372ybry T0.023255813953488372>vc276<yhCloudera S0.05555555555555555ya  S0.08333333333333333yfSearch S0.05555555555555555yaは S0.05555555555555555ya次 T0.027777777777777776yaの S0.05555555555555555ybよう T0.027777777777777776yaな T0.027777777777777776yeモジュール S0.05555555555555555ybから T0.027777777777777776yb構成 T0.027777777777777776yaさ T0.027777777777777776yaれ T0.027777777777777776yaて T0.027777777777777776yaい T0.027777777777777776ybます T0.027777777777777776ya。 T0.027777777777777776ybこれ S0.05555555555555555yaで T0.027777777777777776ya、 T0.027777777777777776ybさら T0.027777777777777776yaに T0.027777777777777776yaら T0.027777777777777776yaが T0.027777777777777776ydSolr T0.027777777777777776ybとか T0.027777777777777776yaを T0.027777777777777776yb使っ T0.027777777777777776>vc277<ycAWS S0.02631578947368421ya  S0.07894736842105263yfSummit S0.02631578947368421yaに S0.02631578947368421ya来 S0.02631578947368421yaて S0.05263157894736842yaい S0.02631578947368421yaた S0.07894736842105263yaの S0.02631578947368421yaで S0.07894736842105263yaす S0.02631578947368421yaが S0.05263157894736842ya、 S0.07894736842105263ybTL S0.02631578947368421yaは S0.02631578947368421yhCloudera S0.02631578947368421yfSearch S0.02631578947368421yc賑わっ S0.02631578947368421ybまし S0.02631578947368421ya。 S0.02631578947368421ycという S0.02631578947368421ybこと S0.02631578947368421yd軽くどん S0.02631578947368421ydなものか S0.02631578947368421yb読ん S0.02631578947368421ybだり S0.02631578947368421yb調べ S0.02631578947368421ycたりし S0.02631578947368421>vc278<yb憧れ T0.027777777777777776ya？ T0.027777777777777776yaの S0.08333333333333333yffluent T0.027777777777777776yaを S0.05555555555555555yb使っ T0.027777777777777776yaて S0.05555555555555555ycみまし T0.027777777777777776yaた S0.05555555555555555ya。 T0.027777777777777776ya  T0.027777777777777776ycこちら T0.027777777777777776yb記事 T0.027777777777777776yaで S0.08333333333333333yb紹介 T0.027777777777777776yaし S0.05555555555555555yhZoomdata T0.027777777777777776yd最近触っ T0.027777777777777776ybいる T0.027777777777777776yaす T0.027777777777777776yaが T0.027777777777777776ya、 T0.027777777777777776ycお試し T0.027777777777777776yaに T0.027777777777777776ygfluentd T0.027777777777777776ycデータ T0.027777777777777776ya流 T0.027777777777777776yb込む T0.027777777777777776>vc279<yb最近 S0.02702702702702703ya、 S0.08108108108108109yhMarkdown S0.05405405405405406yaで S0.08108108108108109yb文章 S0.02702702702702703yaを S0.08108108108108109yb書く S0.02702702702702703yaの S0.08108108108108109yaに S0.02702702702702703yb慣れ S0.02702702702702703yaて S0.02702702702702703ycきまし S0.02702702702702703yaた S0.02702702702702703ya。 S0.02702702702702703ya  S0.02702702702702703ycという S0.02702702702702703ybこと S0.02702702702702703ycブログ S0.05405405405405406yb書け S0.02702702702702703ycないか S0.02702702702702703ybなぁ S0.02702702702702703yaと S0.02702702702702703yb思い S0.02702702702702703ybTL S0.02702702702702703ya人 S0.02702702702702703ybたち S0.02702702702702703ya見 S0.02702702702702703>vc280<yb昨年 T0.027777777777777776ybから T0.027777777777777776ya、 S0.08333333333333333ycブログ T0.027777777777777776yaを S0.05555555555555555ycどうし T0.027777777777777776ydようかっ T0.027777777777777776yaて R0.1111111111111111ya話 T0.027777777777777776yaし T0.027777777777777776yaい S0.05555555555555555ydそのまま T0.027777777777777776yaに T0.027777777777777776ybなっ T0.027777777777777776yaた T0.027777777777777776yaの S0.05555555555555555yaで T0.027777777777777776yaす T0.027777777777777776yaが S0.05555555555555555yiOctopress T0.027777777777777776ya＋ T0.027777777777777776yfGithub T0.027777777777777776ya  T0.027777777777777776yePages T0.027777777777777776ycという T0.027777777777777776ybある T0.027777777777777776ycらしい T0.027777777777777776>vc281<ya0 S0.05263157894736842ya3 S0.05263157894736842ya4 S0.05263157894736842yfLucene S0.05263157894736842ya/ S0.02631578947368421ydSolr S0.05263157894736842ya  S0.05263157894736842ya. S0.10526315789473684yaが S0.02631578947368421ydリリース S0.05263157894736842yaさ S0.02631578947368421yaれ S0.02631578947368421yaた S0.02631578947368421ya（ S0.02631578947368421yaの S0.07894736842105263ygChanges S0.05263157894736842ya、 S0.05263157894736842ya） S0.02631578947368421yaで S0.02631578947368421yflucene S0.02631578947368421ya- S0.02631578947368421yegosen S0.02631578947368421yaを S0.02631578947368421ybしま S0.02631578947368421>vc282<yeアジャイル T0.038461538461538464yaな T0.038461538461538464ye時間管理術 T0.038461538461538464ya  S0.11538461538461539yjポモドーロテクニック S0.07692307692307693yb入門 S0.07692307692307693ycという T0.038461538461538464ya本 T0.038461538461538464yaを T0.038461538461538464yd読みまし T0.038461538461538464yaた T0.038461538461538464ya。 T0.038461538461538464ydきっかけ T0.038461538461538464yaは T0.038461538461538464ya、 T0.038461538461538464ygTwitter T0.038461538461538464ya上 T0.038461538461538464yaで T0.038461538461538464yb何度 T0.038461538461538464yaか T0.038461538461538464ya「 T0.038461538461538464yeポモドーロ T0.038461538461538464>vc283<ya3 T0.021739130434782608ya4 T0.021739130434782608yb11 T0.021739130434782608yb25 T0.021739130434782608yd2013 T0.021739130434782608ybまだ T0.021739130434782608ya、 S0.08695652173913043ydVote T0.021739130434782608yb公開 T0.021739130434782608yaさ T0.021739130434782608yaれ T0.021739130434782608yaて S0.06521739130434782yaい T0.043478260869565216ybない T0.043478260869565216ydSolr T0.021739130434782608ya  S0.06521739130434782ya. T0.021739130434782608ya（ T0.021739130434782608ya/ T0.043478260869565216yb04 T0.021739130434782608ya: T0.021739130434782608yd00現在 T0.021739130434782608ya） T0.021739130434782608ybです T0.021739130434782608yaが T0.021739130434782608ydひさびさ T0.021739130434782608yaに T0.021739130434782608yb訳し T0.021739130434782608yaみ T0.021739130434782608yaた T0.021739130434782608ya。 T0.021739130434782608yb詳細 T0.021739130434782608ybまで T0.021739130434782608yb追っ T0.021739130434782608yaの T0.021739130434782608yaで T0.021739130434782608>vc284<ya0 T0.022727272727272728ya3 T0.045454545454545456ya4 T0.022727272727272728yb16 T0.022727272727272728yb24 T0.022727272727272728yd2013 T0.022727272727272728yb現在 T0.022727272727272728ya、 S0.06818181818181818ybRC T0.022727272727272728yaの T0.022727272727272728ydVote T0.022727272727272728yaを T0.022727272727272728ybやっ T0.022727272727272728yaて T0.045454545454545456ybいる T0.022727272727272728yb最中 T0.022727272727272728ya（ T0.022727272727272728ya/ T0.045454545454545456yb04 T0.022727272727272728ya  T0.045454545454545456ya: T0.022727272727272728yd00時点 T0.022727272727272728ya） T0.022727272727272728yaで T0.045454545454545456ybまだ T0.022727272727272728ydリリース T0.022727272727272728yaさ T0.022727272727272728yaれ T0.022727272727272728yaい T0.022727272727272728ybない T0.022727272727272728ya. T0.045454545454545456ydについて T0.022727272727272728yaす T0.022727272727272728ya。 T0.022727272727272728yc開発者 T0.022727272727272728ybML T0.022727272727272728>vc285<yd第2回目 T0.023809523809523808yaも T0.023809523809523808yb参加 T0.023809523809523808yaし T0.023809523809523808ybまし T0.023809523809523808yaた S0.07142857142857142ya。 S0.09523809523809523ya  S0.09523809523809523ybとり T0.023809523809523808ycあえず T0.023809523809523808ybメモ T0.023809523809523808yb自分 T0.023809523809523808yaに T0.023809523809523808yaは T0.023809523809523808yb欠け T0.023809523809523808ybてる T0.023809523809523808yb視点 T0.023809523809523808yaの S0.09523809523809523yb話し T0.023809523809523808yaな T0.023809523809523808yaで T0.023809523809523808yb面白 T0.023809523809523808ybかっ T0.023809523809523808ycちょっ T0.023809523809523808yaと T0.023809523809523808yc寒かっ T0.023809523809523808ybなぁ T0.023809523809523808yeエンジニア T0.023809523809523808ybため T0.023809523809523808yfスキルアップ T0.023809523809523808yb勉強 T0.023809523809523808>vc286<ycだいぶe0.025ya、e0.075ycブログe0.025yaをd0.05yb書くe0.025ycペースe0.025yaがe0.025yb落ちe0.025yaてc0.1ybきてe0.025yc危機感e0.025yb感じe0.025ybいるd0.05yb今日e0.025yaこe0.025yaのd0.05ybごろe0.025yaでe0.025yaすe0.025ya。e0.075ya e0.025yb今回e0.025yaはe0.025yc個人的e0.025yaにe0.025yb利用e0.025yaしe0.025ydJIRAe0.025yfバックアップe0.025ydについてe0.025>vc287<yfHeroku S0.03571428571428571yaで S0.03571428571428571yaは S0.03571428571428571ycじめる S0.03571428571428571yeRails S0.03571428571428571ygプログラミング S0.03571428571428571yb入門 S0.03571428571428571ya  S0.03571428571428571ygheroku気 S0.03571428571428571yaに S0.07142857142857142ybなっ S0.03571428571428571ybてる S0.03571428571428571yaの S0.07142857142857142yb使っ S0.03571428571428571yaて S0.14285714285714285ybなく S0.03571428571428571ya、 S0.03571428571428571ybTD S0.03571428571428571ygアカウント作っ S0.03571428571428571yfデータアップ S0.03571428571428571yaし S0.03571428571428571ybない S0.03571428571428571yc軟弱者 S0.03571428571428571>vc288<yb記念 T0.023809523809523808yaす T0.047619047619047616ybべき T0.023809523809523808ya！ T0.047619047619047616ya？ T0.023809523809523808ya第 T0.023809523809523808yc10回 T0.023809523809523808yaの T0.023809523809523808ydSolr T0.023809523809523808yc勉強会 T0.023809523809523808yaで S0.07142857142857142ya。 T0.047619047619047616ya  T0.047619047619047616yc発表者 T0.023809523809523808yaが T0.047619047619047616yb無事 T0.023809523809523808ydあつまり T0.023809523809523808ya（ T0.023809523809523808yb本当 T0.023809523809523808yaに T0.023809523809523808ybあり T0.023809523809523808ygとうございまし T0.023809523809523808yaた T0.047619047619047616ya） T0.023809523809523808ya、 T0.023809523809523808yb今回 T0.023809523809523808yaも T0.023809523809523808yb盛況 T0.023809523809523808yaな T0.023809523809523808yb感じ T0.023809523809523808ybほぼ T0.023809523809523808yb満員 T0.023809523809523808yaし T0.023809523809523808ycツイー T0.023809523809523808>vc289<ycなんか T0.029411764705882353ya、 T0.058823529411764705ybとて T0.029411764705882353yaも T0.029411764705882353yb久し T0.029411764705882353ybぶり T0.029411764705882353yaに T0.058823529411764705ydイベント T0.029411764705882353yb参加 T0.029411764705882353ybメモ T0.029411764705882353yb以外 T0.029411764705882353yaの S0.08823529411764706yb投稿 T0.029411764705882353yaで T0.029411764705882353yaす T0.029411764705882353ya。 T0.029411764705882353ya  T0.058823529411764705ygelastic T0.029411764705882353yfsearch T0.029411764705882353ybML T0.029411764705882353yaを T0.058823529411764705yb見て T0.029411764705882353ybたら T0.029411764705882353yhKuromoji T0.029411764705882353yhAnalyzer T0.029411764705882353yb使う T0.029411764705882353ybとき T0.029411764705882353ycユーザ T0.029411764705882353>vc290<yb久々e0.025yaにe0.025ycブログe0.025ya＋d0.05ydイベントe0.025yb参加d0.05yaでd0.05yaすe0.025ya。e0.075ya d0.05yd知り合いe0.025yaがe0.025yb開催e0.025yb出演e0.025yaしd0.05yaたe0.075yaのe0.025yaてe0.025ycみましe0.025ya「e0.025ycスマホe0.025yc」ってe0.025yeキーワードe0.025yaはe0.025ycあまりe0.025ycなかっe0.025ycたけどe0.025ya、e0.025yb面白e0.025ybかっe0.025ybですe0.025>vc291<yb技術 T0.020833333333333332ycブログ T0.020833333333333332ybから T0.020833333333333332yb離れ T0.020833333333333332yaてf0.0625ybいっ T0.020833333333333332ybます T0.020833333333333332yaが T0.041666666666666664ya。 S0.10416666666666667ya  S0.10416666666666667yfXperia T0.041666666666666664yaZ T0.020833333333333332yaを T0.020833333333333332yb購入 T0.020833333333333332yaし T0.020833333333333332ybまし T0.020833333333333332yaたf0.0625ya前 T0.020833333333333332yaに T0.041666666666666664yb使っ T0.020833333333333332yaい T0.020833333333333332yaの T0.041666666666666664yaは T0.020833333333333332ycarc T0.020833333333333332ydなります T0.020833333333333332ydもうすぐ T0.020833333333333332yb２年 T0.020833333333333332ybだっ T0.020833333333333332yaで T0.020833333333333332yaす T0.020833333333333332ya、 T0.020833333333333332yc容量不 T0.020833333333333332>vc292<yd2013 T0.022222222222222223yc金曜日 T0.022222222222222223yaに T0.044444444444444446yb引き T0.022222222222222223yb続き T0.022222222222222223ya、 T0.044444444444444446ydイベント T0.022222222222222223yb参加 T0.022222222222222223yaし T0.022222222222222223yaて T0.022222222222222223yc来まし T0.022222222222222223yaた T0.022222222222222223ya。 S0.13333333333333333ya（ T0.022222222222222223yb仕事 T0.044444444444444446ybこれ T0.022222222222222223yaも T0.022222222222222223yaだ T0.022222222222222223yaよ T0.022222222222222223ya） T0.022222222222222223ya  S0.13333333333333333ya「 T0.022222222222222223yfHadoop T0.044444444444444446yjConference T0.022222222222222223yeJapan T0.022222222222222223yfWinter T0.022222222222222223ya」 T0.022222222222222223ybです T0.022222222222222223yb普段 T0.022222222222222223yaを T0.022222222222222223yb触る T0.022222222222222223>vc293<ya1 S0.03225806451612903yb18 S0.03225806451612903yd2013 S0.03225806451612903ya/ S0.03225806451612903ya（ S0.06451612903225806ya金 S0.03225806451612903ya） S0.06451612903225806yaに S0.03225806451612903yb開催 S0.03225806451612903yaさ S0.03225806451612903yaれ S0.03225806451612903yaた S0.03225806451612903ya、 S0.03225806451612903yiエンジニアサポート S0.03225806451612903yeCROSS S0.06451612903225806ya  S0.03225806451612903yaで S0.03225806451612903ya「 S0.03225806451612903yb検索 S0.03225806451612903ya」 S0.03225806451612903yeセッション S0.03225806451612903yaの S0.03225806451612903yiセッションオーナー S0.03225806451612903yeモデレータ S0.03225806451612903yaを S0.03225806451612903ybやっ S0.03225806451612903yaて S0.03225806451612903yb来ま S0.03225806451612903>vc294<ya1 T0.027777777777777776yb18 T0.027777777777777776yd2013 T0.027777777777777776ydいまさら T0.027777777777777776yc感満載 T0.027777777777777776yaで S0.05555555555555555yaす T0.027777777777777776yaが T0.027777777777777776ya、 T0.027777777777777776yb今週 T0.027777777777777776yaの S0.05555555555555555yc金曜日 T0.027777777777777776ya( T0.027777777777777776ya/ T0.027777777777777776ya) T0.027777777777777776yaに S0.05555555555555555yb開催 T0.027777777777777776yaさ T0.027777777777777776ybれる T0.027777777777777776yeCROSS S0.05555555555555555ya  T0.027777777777777776ycという T0.027777777777777776ydイベント T0.027777777777777776ya「 T0.027777777777777776yb検索 T0.027777777777777776ya」 T0.027777777777777776yeセッション T0.027777777777777776yaを T0.027777777777777776yb担当 T0.027777777777777776ybする T0.027777777777777776ybこと T0.027777777777777776yaな T0.027777777777777776>vc295<yb年末 S0.03225806451612903ybから S0.03225806451612903yb年始 S0.03225806451612903yaに S0.06451612903225806ycかけて S0.03225806451612903ya、 S0.06451612903225806ya「 S0.03225806451612903ykコード・シンプリシティ S0.03225806451612903ya」 S0.03225806451612903yaを S0.06451612903225806yd読みまし S0.03225806451612903yaた S0.06451612903225806ya。 S0.03225806451612903ya  S0.06451612903225806yb先日 S0.03225806451612903yaの S0.03225806451612903yb記事 S0.03225806451612903yaも S0.03225806451612903yd書きまし S0.03225806451612903yaが S0.03225806451612903yfKindle S0.03225806451612903yjpaperwhite S0.03225806451612903yb思い S0.03225806451612903ycかけず S0.03225806451612903yb入手 S0.03225806451612903yaで S0.03225806451612903>vc296<yc書こう T0.022727272727272728yaと S0.06818181818181818yb思い T0.022727272727272728yaな T0.022727272727272728yaが T0.022727272727272728yaら T0.022727272727272728ya、 S0.06818181818181818yc気づい T0.022727272727272728ybたら T0.022727272727272728yc大晦日 T0.022727272727272728ya。 S0.06818181818181818ya  S0.06818181818181818ybよく T0.022727272727272728ybない T0.045454545454545456yaで T0.045454545454545456ybすね T0.022727272727272728yd思いつい T0.022727272727272728yaた S0.06818181818181818ya時 T0.022727272727272728yaに T0.022727272727272728yb書か T0.022727272727272728yb昨年 T0.022727272727272728yaも T0.022727272727272728yb書い T0.022727272727272728yaの T0.022727272727272728yd昨年書い T0.022727272727272728yb抱負 T0.022727272727272728ybから T0.022727272727272728yb振り T0.022727272727272728yb返り T0.022727272727272728yaを T0.022727272727272728yeMongo T0.022727272727272728>vc297<yd2012 T0.021739130434782608yiAtlassian T0.021739130434782608ya  S0.10869565217391304yfAdvent T0.021739130434782608yhCalendar T0.021739130434782608yaの S0.06521739130434782yd20日目 T0.021739130434782608ya。 T0.043478260869565216ya（ S0.08695652173913043yd急遽参戦 T0.021739130434782608ya） S0.06521739130434782ya某 T0.021739130434782608ydイケメン T0.021739130434782608yaに T0.043478260869565216ybMT T0.021739130434782608yb改変 T0.021739130434782608yeリツイート T0.021739130434782608yaさ T0.021739130434782608yaれ T0.021739130434782608yaた T0.043478260869565216yaで T0.043478260869565216yb書い T0.021739130434782608yaて T0.021739130434782608ycみまし T0.021739130434782608yb久々 T0.021739130434782608ya、 T0.021739130434782608yc勉強会 T0.021739130434782608yb以外 T0.021739130434782608ydエントリ T0.021739130434782608yaす T0.021739130434782608ybSo T0.021739130434782608>vc298<ydイケメン S0.02631578947368421yaが S0.05263157894736842yb主催 S0.02631578947368421yaし S0.05263157894736842yaた S0.05263157894736842ya「 S0.02631578947368421yc第一回 S0.02631578947368421ya  S0.07894736842105263yiJetBrains S0.02631578947368421yhユーザーグループ S0.02631578947368421ya# S0.02631578947368421yejbugj S0.02631578947368421ya」 S0.02631578947368421yaに S0.05263157894736842yb参加 S0.02631578947368421yaて S0.02631578947368421ycきまし S0.02631578947368421ya。 S0.05263157894736842ycいろん S0.02631578947368421yaな S0.02631578947368421yb製品 S0.02631578947368421ybある S0.02631578947368421yaん S0.02631578947368421yaだ S0.02631578947368421ybなぁ S0.02631578947368421yaと S0.02631578947368421yb入り S0.02631578947368421ya口 S0.02631578947368421yaは S0.02631578947368421yb良い S0.02631578947368421yaイ S0.02631578947368421>vc299<ydヒカリエ T0.023255813953488372yaに T0.046511627906976744yb行っ T0.023255813953488372yaて T0.046511627906976744yaみ T0.023255813953488372ybたい T0.023255813953488372ycという T0.046511627906976744yb不純 T0.023255813953488372yaな S0.06976744186046512yb理由 T0.023255813953488372yaで S0.06976744186046512yb参加 T0.023255813953488372yaし T0.046511627906976744ycきまし T0.023255813953488372yaた T0.046511627906976744ya。 T0.046511627906976744ya  T0.046511627906976744yc新しい T0.023255813953488372ybこと T0.023255813953488372yaも T0.046511627906976744ybあり T0.023255813953488372ya、 T0.023255813953488372ydおしゃれ T0.023255813953488372yb綺麗 T0.023255813953488372ycカフェ T0.023255813953488372yb入り T0.023255813953488372ya口 T0.023255813953488372yaは T0.023255813953488372ycおっき T0.023255813953488372yb人形 T0.023255813953488372yb立っ T0.023255813953488372>vc300<yc第9回e0.025ydSolre0.025yc勉強会e0.025yaにe0.075yb参加e0.025yaしe0.025ybましe0.025yaたd0.05ya。d0.05ya d0.05yc皆勤賞e0.025yaでe0.025yaすe0.025ya！e0.025ydというかe0.025ya、d0.05yc主催者e0.025ybなっe0.025yaてe0.025yeしまいましe0.025ybまだe0.025yc不定期e0.025yaのe0.025yb開催e0.025ybなるe0.025yaとe0.025yd思いますe0.025yaがe0.025ya話e0.025yaをe0.025yaさe0.025yaれe0.025ybたいe0.025yc方などe0.025>vc301<yc初目黒 S0.02631578947368421ya（ S0.02631578947368421ycたぶん S0.02631578947368421ya） S0.02631578947368421yaで S0.05263157894736842ya、 S0.07894736842105263yg初Amazon S0.02631578947368421yaな S0.02631578947368421yb感じ S0.02631578947368421yc流行り S0.02631578947368421yaの S0.07894736842105263ya「 S0.02631578947368421yfビッグデータ S0.02631578947368421ya」 S0.02631578947368421ydセミナー S0.02631578947368421yaに S0.02631578947368421yb参加 S0.02631578947368421yaし S0.02631578947368421yaて S0.05263157894736842ycきまし S0.02631578947368421yaた S0.02631578947368421ya。 S0.02631578947368421ya  S0.02631578947368421ybとり S0.02631578947368421ybあえ S0.02631578947368421yaず S0.02631578947368421ydいつもの S0.02631578947368421yc自分用 S0.02631578947368421ybメモ S0.02631578947368421yaを S0.02631578947368421yb残し S0.02631578947368421yaお S0.02631578947368421>vc302<ya0 S0.08333333333333333ya4 T0.041666666666666664yb## T0.020833333333333332yfLucene T0.041666666666666664ya/ T0.041666666666666664ydSolr T0.041666666666666664ya f0.0625ya. S0.08333333333333333ydリリースf0.0625ybつい T0.020833333333333332yaに T0.020833333333333332ya、 T0.041666666666666664yaが T0.041666666666666664yaさ T0.020833333333333332yaれ T0.020833333333333332ybまし T0.020833333333333332yaたf0.0625ya。 T0.041666666666666664ybML T0.020833333333333332yaで T0.020833333333333332yb流れ T0.020833333333333332yaて T0.020833333333333332ycいまし T0.020833333333333332yc3年越 T0.020833333333333332yaし T0.020833333333333332yaの T0.020833333333333332ybだっ T0.020833333333333332ybよう T0.020833333333333332ybです T0.020833333333333332>vc303<ybこの T0.034482758620689655ydイベント T0.034482758620689655yaに T0.034482758620689655yiウチダスペクトラム T0.034482758620689655yaの S0.06896551724137931ya枠 T0.034482758620689655yaで S0.10344827586206896yfMahout T0.034482758620689655yeコミッター T0.034482758620689655ybある T0.034482758620689655ya、 S0.06896551724137931yeGrant T0.034482758620689655ya  T0.034482758620689655yiIngersoll T0.034482758620689655ybさん T0.034482758620689655yaが S0.06896551724137931yb講演 T0.034482758620689655yaさ T0.034482758620689655ybれる T0.034482758620689655ycという T0.034482758620689655ybこと T0.034482758620689655yb興味 T0.034482758620689655ybあっ T0.034482758620689655yaた T0.034482758620689655>vc304<yd2012 S0.02631578947368421ycPFI S0.02631578947368421yhオープンセミナー S0.02631578947368421yaに S0.05263157894736842yb参加 S0.05263157894736842yaし S0.07894736842105263yaて S0.10526315789473684ycきまし S0.05263157894736842yaた S0.05263157894736842ya。 S0.02631578947368421ya  S0.02631578947368421yb対象 S0.02631578947368421ybから S0.02631578947368421yb微妙 S0.02631578947368421yb外れ S0.02631578947368421ybたり S0.02631578947368421ya、 S0.05263157894736842ya話 S0.02631578947368421yaの S0.02631578947368421yb内容 S0.02631578947368421ycについ S0.02631578947368421ycいける S0.02631578947368421yaか S0.02631578947368421yb自信 S0.02631578947368421yaが S0.05263157894736842yeありません S0.02631578947368421yaで S0.02631578947368421>vc305<yb友人 T0.027777777777777776ybにお T0.027777777777777776yb値打 T0.027777777777777776yb価格 T0.027777777777777776yaで S0.08333333333333333yb購入 T0.027777777777777776yaし S0.08333333333333333yaた S0.05555555555555555ycMac T0.027777777777777776ya  S0.05555555555555555ydmini T0.027777777777777776yaは S0.05555555555555555yhMountain T0.027777777777777776ydLion T0.027777777777777776yaに T0.027777777777777776yfアップデート S0.05555555555555555yaて S0.05555555555555555yaの S0.05555555555555555yaす T0.027777777777777776yaが T0.027777777777777776ya、 T0.027777777777777776yb手元 T0.027777777777777776ycAir T0.027777777777777776ybまだ T0.027777777777777776yaい T0.027777777777777776ycません T0.027777777777777776>vc306<yb興味 T0.047619047619047616yaを T0.047619047619047616ydもちつつ T0.023809523809523808ya、 S0.07142857142857142yb触っ T0.023809523809523808yaて T0.047619047619047616yaい T0.023809523809523808ybない T0.023809523809523808yc軟弱者 T0.023809523809523808yaで T0.047619047619047616yaす T0.023809523809523808yaが T0.047619047619047616ybある T0.023809523809523808yaの T0.047619047619047616yb今回 T0.023809523809523808yaも T0.023809523809523808ya話 T0.023809523809523808yb聞き T0.023809523809523808yaに T0.023809523809523808yb行っ T0.023809523809523808yc来まし T0.023809523809523808yaた T0.023809523809523808ya。 T0.023809523809523808ya  T0.023809523809523808ybまず T0.023809523809523808yaは T0.023809523809523808yb作者 T0.023809523809523808yb古橋 T0.023809523809523808ybさん T0.023809523809523808ycによる T0.023809523809523808ygFluentd T0.023809523809523808yb魅力 T0.023809523809523808yaや T0.023809523809523808yb次期 T0.023809523809523808>vc307<ydまたまた T0.029411764705882353yb飲み T0.029411764705882353yaに T0.029411764705882353yb行っ T0.029411764705882353yaて T0.058823529411764705yb参加 T0.029411764705882353yaし T0.029411764705882353ycきまし T0.029411764705882353yaた T0.029411764705882353ya。 T0.029411764705882353ya  T0.029411764705882353yb今回 T0.029411764705882353yaは T0.029411764705882353ya、 S0.11764705882352941yeRails T0.029411764705882353yciOS T0.029411764705882353yaで T0.029411764705882353yaの S0.11764705882352941ygTwitter T0.029411764705882353yb連携 T0.029411764705882353ya話 T0.029411764705882353ybから T0.029411764705882353ydツイート T0.029411764705882353yb分析 T0.029411764705882353yiクライアントアプリ T0.029411764705882353yb開発 T0.029411764705882353yb苦労 T0.029411764705882353>vc308<ycという T0.023809523809523808ybこと T0.023809523809523808yaで T0.047619047619047616ya、 S0.07142857142857142yeステッカー T0.023809523809523808ya欲 T0.023809523809523808yaし T0.023809523809523808yaさ T0.023809523809523808ya？ T0.023809523809523808yaに S0.07142857142857142yc勉強中 T0.023809523809523808yaの T0.023809523809523808ya話 T0.023809523809523808yaを T0.023809523809523808ye恥ずかしげ T0.023809523809523808yaも T0.023809523809523808ybなく T0.023809523809523808yc偉そう T0.023809523809523808ydしゃべっ T0.023809523809523808yaて T0.047619047619047616ycきまし T0.023809523809523808yaた T0.023809523809523808ya。 T0.023809523809523808ya  T0.023809523809523808ya# T0.023809523809523808yepyfes T0.023809523809523808yaは T0.023809523809523808yb以前 T0.023809523809523808ybから T0.023809523809523808ya気 T0.023809523809523808ybなっ T0.023809523809523808yaい T0.023809523809523808ybたん T0.023809523809523808yaす T0.023809523809523808yaが T0.023809523809523808yaタ T0.023809523809523808>vc309<ya0d0.04ya4d0.04yb今日d0.02yaはd0.04ydSolrd0.06ya d0.16ya.d0.04yeALPHAd0.02yaのd0.04yc興味深d0.02yaいd0.02yb機能d0.02yaがd0.02ybあっd0.02yaたd0.04yaでd0.04yb紹介d0.02yaすd0.02ya。d0.04yc数日前d0.02yaにd0.04ya「d0.02ya:d0.02ygPartiald0.02yidocumentsd0.02yfupdated0.02ya」d0.02ycというd0.02yb記事d0.02yaをd0.02ye見つけましd0.02ya、d0.02>vc310<yfModern T0.028985507246376812ya  R0.2753623188405797ykInformation T0.028985507246376812yiRetrieval T0.028985507246376812ya: T0.014492753623188406ycThe T0.014492753623188406yhConcepts T0.014492753623188406ycand T0.014492753623188406yjTechnology T0.014492753623188406yfbehind T0.014492753623188406yfSearch T0.014492753623188406ya( T0.028985507246376812yc2nd T0.028985507246376812ygEdition T0.028985507246376812ya) T0.028985507246376812ycACM T0.014492753623188406yePress T0.014492753623188406yeBooks T0.014492753623188406ycいやぁ T0.014492753623188406ya、 T0.014492753623188406yb蒸し T0.014492753623188406yb暑く T0.014492753623188406yaて T0.014492753623188406ybなか T0.028985507246376812yb寝れ T0.014492753623188406ybない T0.028985507246376812ya日 T0.014492753623188406yaが T0.014492753623188406yaは T0.014492753623188406yeじまりまし T0.014492753623188406ybたね T0.014492753623188406ya。 T0.057971014492753624ya（ T0.014492753623188406ydあんまり T0.014492753623188406yb関係 T0.014492753623188406yaで T0.014492753623188406ybすね T0.014492753623188406ya） T0.014492753623188406yaを T0.014492753623188406>vc311<ya0 S0.05555555555555555ya3 T0.027777777777777776ya4 T0.027777777777777776ya7 T0.027777777777777776yfLucene T0.027777777777777776ya/ S0.05555555555555555ydSolr T0.027777777777777776yaの S0.08333333333333333ya. S0.05555555555555555ya- S0.05555555555555555yeALPHA T0.027777777777777776yaが T0.027777777777777776yaに S0.05555555555555555ydリリース T0.027777777777777776yaさ T0.027777777777777776yaれ T0.027777777777777776ybまし T0.027777777777777776yaた T0.027777777777777776ya。 T0.027777777777777776ya  T0.027777777777777776ybこれ T0.027777777777777776yb伴い T0.027777777777777776ya、 T0.027777777777777776yflucene T0.027777777777777776ydgoen T0.027777777777777776yb4x T0.027777777777777776ydブランチ T0.027777777777777776ycjar T0.027777777777777776ydファイル T0.027777777777777776>vc312<ydまたまた T0.020833333333333332yb参加 T0.020833333333333332yaし T0.020833333333333332ybまし T0.020833333333333332yaた T0.041666666666666664ya。e0.125ycいまだ T0.020833333333333332yc皆勤賞 T0.020833333333333332yaでe0.125yaすf0.0625ya  S0.08333333333333333yb感想 T0.041666666666666664ybなど T0.020833333333333332yaは T0.041666666666666664yaあ T0.020833333333333332yaと T0.020833333333333332ybとり T0.020833333333333332ycあえず T0.020833333333333332ya、f0.0625ybメモ T0.020833333333333332ybとっ T0.020833333333333332yaの T0.020833333333333332yc第一弾 T0.020833333333333332ycという T0.020833333333333332ybこと T0.020833333333333332ybまず T0.020833333333333332yd参加人数 T0.020833333333333332ya今 T0.020833333333333332>vc313<yfHadoop S0.05714285714285714ybから S0.02857142857142857ydはちょっ S0.02857142857142857yaと S0.02857142857142857yb離れ S0.02857142857142857yaて S0.02857142857142857ybいる S0.02857142857142857yaの S0.05714285714285714yaに S0.02857142857142857ya、 S0.08571428571428572yb面白 S0.02857142857142857ybそう S0.02857142857142857yaな S0.02857142857142857ybネタ S0.02857142857142857ybなの S0.02857142857142857yaで S0.02857142857142857yb参加 S0.02857142857142857yaし S0.02857142857142857ybまし S0.02857142857142857yaた S0.02857142857142857ya。 S0.02857142857142857ya  S0.11428571428571428ydData S0.02857142857142857ygScience S0.02857142857142857yfSummit S0.05714285714285714yhHBaseCon S0.02857142857142857yaイ S0.02857142857142857>vc314<yb32 T0.024390243902439025yeIssue T0.024390243902439025ya  S0.04878048780487805yaで S0.04878048780487805ya上 T0.024390243902439025ybがっ T0.024390243902439025yaて S0.04878048780487805yaき T0.024390243902439025yaた S0.04878048780487805yelucee T0.024390243902439025ya- T0.024390243902439025yegosen T0.024390243902439025yaの R0.0975609756097561yfUniDic S0.04878048780487805yb対応 T0.024390243902439025yb最初 T0.024390243902439025ycパッチ T0.024390243902439025yaを T0.024390243902439025yb書い T0.024390243902439025ya、 T0.024390243902439025ycブログ T0.024390243902439025yaに T0.024390243902439025yb残し T0.024390243902439025ydおきます T0.024390243902439025ya。 T0.024390243902439025ya# S0.07317073170731707yaと T0.024390243902439025yaは T0.024390243902439025ya_ S0.07317073170731707>vc315<ya「 T0.021739130434782608ya鉄 T0.021739130434782608yaは T0.043478260869565216yd熱いうち T0.021739130434782608yaに T0.021739130434782608yb打て T0.021739130434782608ya」 T0.021739130434782608ycという T0.021739130434782608ybこと T0.021739130434782608yaで S0.06521739130434782ya、 T0.043478260869565216yb残り T0.021739130434782608yaも T0.021739130434782608yb勢い T0.021739130434782608ybメモ T0.021739130434782608ya。 S0.08695652173913043ya  T0.043478260869565216ybまだ T0.021739130434782608yb見直 T0.021739130434782608yaし T0.021739130434782608ycとかし T0.021739130434782608yaて T0.021739130434782608ybない T0.021739130434782608yb状態 T0.021739130434782608yaな T0.021739130434782608yaの T0.043478260869565216ydおかしい T0.021739130434782608yaと T0.043478260869565216ybころ T0.021739130434782608yaか T0.021739130434782608ydあります T0.021739130434782608yaが T0.021739130434782608ya図 T0.021739130434782608ybとか T0.021739130434782608yc入れる T0.021739130434782608yaま T0.021739130434782608>vc316<yfZipkin T0.029411764705882353yaの T0.058823529411764705yfGithub T0.029411764705882353yaに T0.029411764705882353ybある T0.029411764705882353yfReadme T0.029411764705882353yaを T0.058823529411764705yb読ん T0.029411764705882353yaで T0.058823529411764705ybます T0.029411764705882353ya。 T0.058823529411764705ya  T0.058823529411764705ydせっかく T0.029411764705882353ydというか T0.029411764705882353ya、 T0.058823529411764705ya頭 T0.029411764705882353yaが T0.029411764705882353yb悪い T0.029411764705882353yb読み T0.029411764705882353ybなが T0.029411764705882353yaら T0.029411764705882353yb内容 T0.029411764705882353ybメモ T0.029411764705882353ybまず T0.029411764705882353yaは T0.029411764705882353ygアーキテクチャ T0.029411764705882353yaと T0.029411764705882353ycトレー T0.029411764705882353>vc317<yb久々 T0.030303030303030304yaに S0.06060606060606061ydSolr T0.030303030303030304yaの S0.12121212121212122ya話 S0.06060606060606061yaで S0.06060606060606061yaす T0.030303030303030304ya。 S0.12121212121212122ya  S0.06060606060606061ydといって T0.030303030303030304yaも T0.030303030303030304ya、 T0.030303030303030304yc結構前 T0.030303030303030304ybから T0.030303030303030304yaし T0.030303030303030304yaて T0.030303030303030304yfschema T0.030303030303030304ya. T0.030303030303030304ycxml T0.030303030303030304yifieldType T0.030303030303030304yb設定 T0.030303030303030304ya「 T0.030303030303030304ynautoGeneratePh T0.030303030303030304>vc318<yaす S0.02631578947368421yaで S0.07894736842105263yaに S0.07894736842105263yc読まれ S0.02631578947368421yaた S0.05263157894736842yd方もいる S0.02631578947368421yaか S0.05263157894736842yaも S0.02631578947368421yb知れ S0.02631578947368421ycません S0.02631578947368421yaが S0.02631578947368421ya、 S0.02631578947368421ya気 S0.02631578947368421ybなっ S0.02631578947368421yaの S0.07894736842105263ybメモ S0.02631578947368421yaを S0.02631578947368421yb書い S0.02631578947368421yaて S0.02631578947368421yaみ S0.02631578947368421ybよう S0.02631578947368421yaと S0.05263157894736842ya。 S0.02631578947368421ya  S0.02631578947368421yb先週 S0.02631578947368421yc木曜日 S0.02631578947368421ygTwitter S0.02631578947368421yhエンジニアブログ S0.02631578947368421yfZipkin S0.02631578947368421>vc319<ya0 S0.02857142857142857ya1 S0.02857142857142857ya2 S0.02857142857142857yflucene S0.02857142857142857ya- S0.02857142857142857yegosen S0.02857142857142857yaの S0.05714285714285714yc最新版 S0.02857142857142857ya（ S0.02857142857142857ya. S0.05714285714285714ya） S0.02857142857142857yaを S0.02857142857142857ydリリース S0.02857142857142857ycしまし S0.02857142857142857yaた S0.02857142857142857ya。 S0.05714285714285714ya  S0.05714285714285714yiプロジェクトページ S0.02857142857142857ybより S0.02857142857142857yfダウンロード S0.02857142857142857yaが S0.02857142857142857yb可能 S0.02857142857142857yaで S0.05714285714285714yaす S0.02857142857142857yb今回 S0.02857142857142857yb修正 S0.02857142857142857yaは S0.02857142857142857ya、 S0.02857142857142857ya@ S0.02857142857142857yeharuy S0.02857142857142857>vc320<yb昨晩 T0.043478260869565216yaに S0.08695652173913043yb引き T0.021739130434782608yb続き T0.021739130434782608ya、 S0.06521739130434782yb情け T0.021739130434782608ybない T0.021739130434782608yb内容 T0.021739130434782608yaの S0.06521739130434782ycブログ T0.021739130434782608ybなっ T0.021739130434782608yaて T0.043478260869565216yeしまいます T0.021739130434782608yaが T0.043478260869565216ya。 S0.06521739130434782ya  T0.021739130434782608yb書い T0.021739130434782608yaた S0.08695652173913043yb記事 T0.021739130434782608yb調査 T0.043478260869565216yaを T0.021739130434782608yaし T0.021739130434782608yaい T0.021739130434782608ya時 T0.021739130434782608yc気づい T0.021739130434782608yb問題 T0.021739130434782608ybなる T0.021739130434782608ycケース T0.021739130434782608ybあっ T0.021739130434782608yaで T0.021739130434782608>vc321<ya3 S0.05263157894736842ya5 S0.02631578947368421ya6 S0.02631578947368421yb久々 S0.02631578947368421yaに S0.07894736842105263yflucene S0.02631578947368421ya- S0.02631578947368421yegosen S0.02631578947368421yaを S0.05263157894736842yb触っ S0.02631578947368421yaて S0.02631578947368421ycいます S0.02631578947368421ya。 S0.02631578947368421ya  S0.02631578947368421yetrunk S0.02631578947368421yaの S0.05263157894736842yclib S0.02631578947368421ybある S0.02631578947368421ya、 S0.05263157894736842ycjar S0.02631578947368421ydファイル S0.02631578947368421yaが S0.02631578947368421ya. S0.05263157894736842ycベース S0.05263157894736842ybだっ S0.02631578947368421yaた S0.02631578947368421yaで S0.02631578947368421ybして S0.02631578947368421ycテスト S0.02631578947368421yaし S0.02631578947368421>vc322<yb録画 S0.02564102564102564yaし S0.02564102564102564yaて S0.07692307692307693yaた S0.05128205128205128ycEテレ S0.02564102564102564yaの S0.05128205128205128ymスーパープレゼンテーション S0.02564102564102564yaを S0.02564102564102564yb見て S0.02564102564102564yaふ S0.02564102564102564yaと S0.02564102564102564yb書き S0.02564102564102564ybたく S0.02564102564102564ybなっ S0.02564102564102564yaで S0.02564102564102564ya、 S0.02564102564102564yb書い S0.02564102564102564ybます S0.02564102564102564ya。 S0.10256410256410256ya  S0.05128205128205128ybあと S0.02564102564102564ybから S0.02564102564102564yb読ん S0.02564102564102564ybだら S0.02564102564102564ye恥ずかしく S0.02564102564102564ybなり S0.02564102564102564ybそう S0.02564102564102564ycだけど S0.02564102564102564ya「 S0.02564102564102564ya& S0.02564102564102564yal S0.02564102564102564>vc323<yd2012 T0.021739130434782608ydJJUG T0.021739130434782608ya  S0.13043478260869565ycCCC T0.021739130434782608yfSpring T0.021739130434782608yaに T0.043478260869565216yb参加 T0.043478260869565216yaし T0.021739130434782608yaて T0.021739130434782608ycきまし T0.021739130434782608yaた T0.021739130434782608ya。 S0.06521739130434782yb昨年 T0.021739130434782608yaの T0.021739130434782608ydFall T0.021739130434782608yb続き T0.021739130434782608ya、 S0.06521739130434782yc2回目 T0.021739130434782608yaで T0.021739130434782608yaす T0.021739130434782608yb概要 T0.021739130434782608yaや T0.021739130434782608ygタイムテーブル T0.021739130434782608yaは T0.043478260869565216ycこちら T0.021739130434782608yaを T0.021739130434782608yb御覧 T0.021739130434782608yaく T0.021739130434782608yaだ T0.021739130434782608ybさい T0.021739130434782608yb今回 T0.021739130434782608yb午後 T0.021739130434782608ya一 T0.021739130434782608ybから T0.021739130434782608>vc324<ya0 S0.02631578947368421ynPlayFramework2 S0.02631578947368421ya. S0.02631578947368421yaを S0.02631578947368421yb触っ S0.02631578947368421yaて S0.07894736842105263yaみ S0.02631578947368421ybます S0.02631578947368421ya。 S0.05263157894736842ya  S0.05263157894736842ycちょっ S0.02631578947368421yaと S0.05263157894736842yfコーディング S0.02631578947368421yaし S0.02631578947368421ybたく S0.02631578947368421ybなっ S0.02631578947368421yaた S0.02631578947368421yaの S0.13157894736842105ya、 S0.05263157894736842yb最近 S0.02631578947368421ycアプリ S0.02631578947368421yb作成 S0.02631578947368421yb調査 S0.02631578947368421yaも S0.02631578947368421yb兼ね S0.02631578947368421ybまぁ S0.02631578947368421ydせっかく S0.02631578947368421yaな S0.02631578947368421>vc325<ya0 T0.027777777777777776ya1 T0.027777777777777776ya2 T0.027777777777777776ya7 T0.027777777777777776yflucene T0.027777777777777776ya- T0.027777777777777776yegosen T0.027777777777777776yaの S0.05555555555555555yc最新版 T0.027777777777777776ya（ T0.027777777777777776ya. S0.05555555555555555ya） T0.027777777777777776yaを T0.027777777777777776ydリリース T0.027777777777777776ycしまし T0.027777777777777776yaた T0.027777777777777776ya。 S0.05555555555555555ya  S0.05555555555555555yiプロジェクトページ T0.027777777777777776ybより T0.027777777777777776yfダウンロード T0.027777777777777776yaが T0.027777777777777776yb可能 T0.027777777777777776yaで S0.08333333333333333yaす T0.027777777777777776yb今回 T0.027777777777777776yb修正 T0.027777777777777776yaは T0.027777777777777776ya、 T0.027777777777777776ydJava T0.027777777777777776>vc326<ybID S0.05405405405405406yaの S0.05405405405405406yb秘密 S0.02702702702702703ya  S0.08108108108108109ya( S0.02702702702702703yb丸善 S0.02702702702702703yfライブラリー S0.02702702702702703ya― S0.02702702702702703yc情報研 S0.02702702702702703ydシリーズ S0.02702702702702703ya) S0.02702702702702703yb非常 S0.02702702702702703yaに S0.08108108108108109yb面白 S0.02702702702702703yaく S0.02702702702702703yd読めまし S0.02702702702702703yaた S0.02702702702702703ya。 S0.02702702702702703yeバーコード S0.02702702702702703ya話 S0.02702702702702703yc始まり S0.02702702702702703ya、 S0.02702702702702703yb最後 S0.02702702702702703yaは S0.02702702702702703ydシステム S0.02702702702702703yaで S0.02702702702702703yb付与 S0.02702702702702703ybする S0.02702702702702703yc関する S0.02702702702702703yc考慮点 S0.02702702702702703ybまで S0.02702702702702703>vc327<ygWebSolr S0.06451612903225806yaの S0.06451612903225806ya話 S0.03225806451612903yaが S0.03225806451612903ybある S0.03225806451612903ycらしい S0.03225806451612903ycという S0.03225806451612903yaを S0.03225806451612903ye嗅ぎつけて S0.03225806451612903ya、 S0.06451612903225806yb初め S0.03225806451612903yaて S0.03225806451612903yfHeroku S0.03225806451612903ya  R0.0967741935483871ybJP S0.03225806451612903yfMeetup S0.03225806451612903yaに S0.03225806451612903yb参加 S0.03225806451612903yaし S0.03225806451612903ybまし S0.03225806451612903yaた S0.03225806451612903ya。 S0.03225806451612903yfheroku S0.03225806451612903yaも S0.06451612903225806yd知りつつ S0.03225806451612903>vc328<ya3 T0.022727272727272728ya6 T0.022727272727272728yb先日 T0.022727272727272728ya、 S0.06818181818181818ydSolr T0.022727272727272728yb入門 T0.022727272727272728yaの S0.09090909090909091ydサンプル T0.022727272727272728yfschema T0.022727272727272728ya. S0.06818181818181818ycxml T0.022727272727272728yb0対 T0.022727272727272728yb応版 T0.022727272727272728yb作成 T0.022727272727272728yaを T0.022727272727272728yaし T0.022727272727272728yaて S0.06818181818181818yaい T0.022727272727272728ya気 T0.022727272727272728yaに T0.022727272727272728ybなっ T0.022727272727272728yaた T0.045454545454545456ybこと T0.022727272727272728yaが T0.022727272727272728ybあっ T0.022727272727272728yaで T0.022727272727272728ya  T0.045454545454545456ybメモ T0.022727272727272728ycとして T0.022727272727272728yb残し T0.022727272727272728ydおきます T0.022727272727272728ya。 T0.022727272727272728yaS T0.022727272727272728>vc329<ya0 T0.023809523809523808ya3 T0.023809523809523808ya6 T0.023809523809523808yb先日 T0.023809523809523808yaの S0.09523809523809523yb続き T0.023809523809523808yaで T0.047619047619047616yaす T0.023809523809523808ya。 T0.047619047619047616ya「 T0.023809523809523808yfApache T0.023809523809523808ya  T0.047619047619047616ydSolr T0.047619047619047616yb入門 T0.023809523809523808ya」 T0.023809523809523808yb2章 T0.023809523809523808ybから T0.023809523809523808yb4章 T0.023809523809523808yb説明 T0.023809523809523808ydについて T0.023809523809523808ya、 T0.023809523809523808ya. T0.047619047619047616yb動作 T0.023809523809523808yaさ T0.023809523809523808ybせる T0.023809523809523808ya時 T0.023809523809523808yc変更点 T0.023809523809523808yaを T0.023809523809523808yb以下 T0.023809523809523808yaに T0.023809523809523808yb書い T0.023809523809523808yaて T0.023809523809523808ydいきます T0.023809523809523808yaな T0.023809523809523808>vc330<ya0 T0.029411764705882353ya3 T0.029411764705882353ya6 T0.029411764705882353yb以前 T0.029411764705882353ybより T0.029411764705882353ya、 S0.08823529411764706yeアナウンス T0.029411764705882353yaし T0.029411764705882353yaて T0.029411764705882353yaい T0.029411764705882353yaた T0.058823529411764705yhKuromoji T0.029411764705882353ycという T0.029411764705882353yh日本語形態素解析 T0.029411764705882353yaが T0.058823529411764705yd含まれる T0.029411764705882353yfLucene T0.029411764705882353ya/ T0.029411764705882353ydSolr T0.029411764705882353ya  T0.058823529411764705ya. T0.058823529411764705ydリリース T0.029411764705882353yaさ T0.029411764705882353yaれ T0.029411764705882353ybまし T0.029411764705882353ya。 T0.029411764705882353yb以下 T0.029411764705882353ya各 T0.029411764705882353>vc331<ygTwitter S0.02702702702702703yaで S0.08108108108108109ybこの S0.02702702702702703ydブログ流 S0.02702702702702703yaれ S0.02702702702702703yaて S0.02702702702702703ybきて S0.02702702702702703ya、 S0.08108108108108109ya気 S0.02702702702702703yaに S0.08108108108108109ybなっ S0.02702702702702703yaた S0.02702702702702703yaの S0.05405405405405406yb流し S0.02702702702702703yd読みして S0.02702702702702703yb簡単 S0.02702702702702703ybメモ S0.02702702702702703ya。 S0.05405405405405406ya  S0.05405405405405406yfAmazon S0.02702702702702703ydサービス S0.05405405405405406ydスケール S0.02702702702702703ybする S0.02702702702702703yb検索 S0.02702702702702703yaみ S0.02702702702702703ybたい S0.02702702702702703ya主 S0.02702702702702703>vc332<ya4 R0.1111111111111111ya5 T0.037037037037037035yd2012 T0.018518518518518517ygJavaOne T0.018518518518518517ya  S0.07407407407407407yeTokyo T0.018518518518518517yaに T0.018518518518518517yb参加 T0.037037037037037035yaし T0.018518518518518517yaて S0.05555555555555555ycきまし T0.018518518518518517yaた S0.05555555555555555ya。 T0.037037037037037035ya/ S0.07407407407407407ya- T0.018518518518518517yaの S0.05555555555555555ye2日間開催 T0.018518518518518517yaさ T0.018518518518518517yaれ T0.018518518518518517yaい T0.018518518518518517yaで T0.018518518518518517yaす T0.018518518518518517yaが T0.037037037037037035ya、 T0.037037037037037035yb子供 T0.018518518518518517yb体調 T0.018518518518518517yaを T0.018518518518518517yb崩し T0.018518518518518517ycしまい T0.018518518518518517ybのみ T0.018518518518518517yaと T0.018518518518518517ydなりまし T0.018518518518518517>vc333<ya0 S0.05405405405405406ya2 S0.02702702702702703ya7 S0.02702702702702703yb先日 S0.02702702702702703ya、 S0.05405405405405406ya. S0.05405405405405406ydリリース S0.02702702702702703yaの S0.02702702702702703yb記事 S0.02702702702702703yaに S0.02702702702702703yaも S0.02702702702702703yb記載 S0.02702702702702703yaし S0.02702702702702703ybまし S0.02702702702702703yaた S0.05405405405405406yaが S0.08108108108108109ydJava S0.02702702702702703yaで S0.02702702702702703yfテストケース S0.02702702702702703yb失敗 S0.02702702702702703ybする S0.02702702702702703yb問題 S0.02702702702702703ydありまし S0.02702702702702703ya。 S0.02702702702702703ya  S0.02702702702702703ya@ S0.05405405405405406yhharuyama S0.02702702702702703ybさん S0.02702702702702703yaと S0.02702702702702703yfhideak S0.02702702702702703>vc334<ya0 S0.05128205128205128ya2 S0.02564102564102564yb先日 S0.02564102564102564ya、 S0.05128205128205128yb宣言 S0.02564102564102564yaし S0.02564102564102564yaた S0.07692307692307693ycとおり S0.02564102564102564yflucene S0.05128205128205128ya- S0.05128205128205128yegosen S0.05128205128205128yaの S0.05128205128205128yeパッケージ S0.02564102564102564ya名 S0.05128205128205128ya＋ S0.02564102564102564ycクラス S0.02564102564102564yb変更 S0.02564102564102564yaを S0.05128205128205128yb行っ S0.02564102564102564ya  S0.05128205128205128ya. S0.05128205128205128ydリリース S0.02564102564102564ycしまし S0.02564102564102564ya。 S0.02564102564102564yfLucene S0.02564102564102564ya/ S0.02564102564102564ydSolr S0.02564102564102564>vc335<ya0 S0.02857142857142857ya2 S0.02857142857142857yflucene S0.05714285714285714ya- S0.05714285714285714yegosen S0.05714285714285714yaを S0.05714285714285714yb利用 S0.02857142857142857yaし S0.02857142857142857yaて S0.02857142857142857yb頂い S0.02857142857142857ybてる S0.02857142857142857yb皆様 S0.02857142857142857yaに S0.02857142857142857yb連絡 S0.02857142857142857yaが S0.02857142857142857ydあります S0.02857142857142857ya。 S0.02857142857142857ya  S0.05714285714285714yd連絡事項 S0.02857142857142857yb次期 S0.02857142857142857yaの S0.02857142857142857ydリリース S0.02857142857142857ya（ S0.02857142857142857ya. S0.05714285714285714yb予定 S0.02857142857142857ya） S0.02857142857142857ybにて S0.02857142857142857ya、 S0.02857142857142857ycorg S0.02857142857142857>vc336<yb子供 S0.02857142857142857yaの S0.02857142857142857yb寝か S0.02857142857142857ydしつけし S0.02857142857142857yaて S0.14285714285714285ybたら S0.02857142857142857ya、 S0.05714285714285714yf寝かしつけさ S0.02857142857142857yaれ S0.02857142857142857ycしまっ S0.02857142857142857yb２時 S0.02857142857142857yaに S0.05714285714285714ya目 S0.02857142857142857yaが S0.02857142857142857yb覚め S0.02857142857142857yeしまいまし S0.02857142857142857yaた S0.02857142857142857ya。 S0.02857142857142857ya  S0.02857142857142857ygTSUTAYA S0.02857142857142857yaで S0.02857142857142857ybCD S0.02857142857142857yb借り S0.02857142857142857ybきて S0.02857142857142857yfウォークマン S0.02857142857142857yb入れ S0.02857142857142857ybよう S0.02857142857142857yaと S0.02857142857142857yb思っ S0.02857142857142857>vc337<ybはい S0.02702702702702703ya。 S0.05405405405405406ydまたまた S0.02702702702702703ya、 S0.02702702702702703ygTwitter S0.02702702702702703ya  S0.05405405405405406ycAPI S0.02702702702702703yc勉強会 S0.02702702702702703yaに S0.02702702702702703yb参加 S0.02702702702702703yaし S0.05405405405405406yaて S0.02702702702702703ycきまし S0.02702702702702703yaた S0.05405405405405406ya（ S0.02702702702702703yb今回 S0.05405405405405406ybから S0.02702702702702703yb開催 S0.02702702702702703yb回数 S0.02702702702702703yaの S0.02702702702702703yb記載 S0.02702702702702703yaが S0.05405405405405406ybなく S0.02702702702702703ybなっ S0.02702702702702703ya？ S0.02702702702702703ya） S0.02702702702702703yaは S0.02702702702702703yb直前 S0.02702702702702703yaで S0.02702702702702703ygタイムテーブル S0.02702702702702703yd変わって S0.02702702702702703>vc338<ybTL S0.02631578947368421yaで S0.07894736842105263yb面白 S0.02631578947368421yaい S0.02631578947368421yaと S0.02631578947368421yd見かけて S0.02631578947368421ya、 S0.05263157894736842yfAmazon S0.05263157894736842yb買っ S0.02631578947368421yaて S0.02631578947368421yeしまいまし S0.02631578947368421yaた S0.05263157894736842ya。 S0.05263157894736842ya  S0.05263157894736842ybSE S0.02631578947368421ybやっ S0.02631578947368421ybてる S0.02631578947368421yaの S0.02631578947368421yaに S0.05263157894736842ybつい S0.02631578947368421yb最近 S0.02631578947368421yaを S0.02631578947368421yb使い S0.02631578947368421yb始め S0.02631578947368421yc軟弱者 S0.02631578947368421yaす S0.02631578947368421ybそれ S0.02631578947368421ybして S0.02631578947368421yaも S0.02631578947368421ydAmaz S0.02631578947368421>vc339<ybえー T0.022222222222222223yaと R0.1111111111111111ya、 S0.06666666666666667ycブログ T0.022222222222222223yb更新 T0.022222222222222223yaし T0.022222222222222223yaて T0.022222222222222223ybない T0.022222222222222223ybなぁ T0.022222222222222223ybとふ T0.022222222222222223yb思っ T0.022222222222222223yaた S0.08888888888888889yaの T0.022222222222222223yaで T0.022222222222222223ya。 R0.1111111111111111ya  S0.06666666666666667yb１年 T0.022222222222222223yd前くらい T0.022222222222222223ybから T0.022222222222222223ybずー T0.022222222222222223yaっ T0.022222222222222223yeつぶやいて T0.022222222222222223ybまし T0.044444444444444446yaが T0.022222222222222223ybやっ T0.022222222222222223yeScala T0.022222222222222223yaを T0.022222222222222223yb始め T0.022222222222222223yc長かっ T0.022222222222222223>vc340<yc森ビル S0.02127659574468085yaに S0.06382978723404255yb行っ S0.02127659574468085yaた S0.06382978723404255ybこと S0.02127659574468085ycなかっ S0.02127659574468085yaの R0.0425531914893617yaで R0.0425531914893617ya、 R0.0851063829787234yb参加 S0.02127659574468085yaし R0.0425531914893617yaて S0.06382978723404255ycみまし S0.02127659574468085ya。 R0.0425531914893617ya  R0.0425531914893617ybあと S0.02127659574468085yb最近 S0.02127659574468085yaま S0.02127659574468085yaと R0.0425531914893617yaも R0.0425531914893617yfコーディング S0.02127659574468085ybない S0.02127659574468085ydそのへん S0.02127659574468085yaを S0.02127659574468085yb矯正 S0.02127659574468085ybする S0.02127659574468085ybため S0.02127659574468085yb思っ S0.02127659574468085ya（ S0.02127659574468085ybまぁ S0.02127659574468085ya遊 S0.02127659574468085>vc341<yeClean S0.08108108108108109ya  S0.16216216216216217yeCoder S0.05405405405405406ynプロフェッショナルプログラマ S0.02702702702702703yaへ S0.02702702702702703yaの S0.02702702702702703ya道 S0.02702702702702703yaを S0.02702702702702703yb読み S0.02702702702702703ybまし S0.02702702702702703yaた S0.05405405405405406ya。 S0.05405405405405406yb理由 S0.02702702702702703yaは S0.02702702702702703ygTwitter S0.02702702702702703yaで S0.02702702702702703ya「 S0.02702702702702703ydCode S0.02702702702702703ya」 S0.02702702702702703ycがいい S0.02702702702702703yb本だ S0.02702702702702703yaと S0.02702702702702703yb流れ S0.02702702702702703yaて S0.02702702702702703yaき S0.02702702702702703ybため S0.02702702702702703ybです S0.02702702702702703>vc342<yb親子e0.025yaでe0.075yd楽しめるe0.025ya e0.075yb絵本e0.025yb英語d0.05yaをd0.05yaはe0.025ycじめるe0.025ya本d0.05ygTwittere0.025ybこのe0.025ydについてe0.025yb書かe0.025yaれe0.025yaたe0.075ycブログe0.025yb記事e0.025yaがe0.025yb流れe0.025yaてe0.025ybきてe0.025ya、d0.05yb購入e0.025yaしe0.025ybましe0.025ya。e0.025yb最近e0.025ye身につけてe0.025ybおいe0.025>vc343<yb今週 T0.021739130434782608yaも T0.021739130434782608yc勉強会 T0.043478260869565216yaに T0.021739130434782608yb参加 T0.021739130434782608yaし S0.06521739130434782ybまし T0.021739130434782608yaた S0.06521739130434782ya。 S0.06521739130434782ya  S0.08695652173913043ya@ T0.021739130434782608ygyusukey T0.021739130434782608ybさん T0.021739130434782608yaが S0.06521739130434782yb開催 T0.021739130434782608ybてる T0.021739130434782608ygTwitter T0.021739130434782608ycAPI T0.021739130434782608yaで S0.06521739130434782yaす T0.021739130434782608yb前回 T0.021739130434782608yaと T0.021739130434782608yaは T0.021739130434782608yb会場 T0.043478260869565216ye異なりまし T0.021739130434782608ya、 T0.021739130434782608yb広く T0.021739130434782608yaて T0.021739130434782608yc大画面 T0.021739130434782608yb良い T0.021739130434782608ya駅 T0.021739130434782608>vc344<yb久々 T0.027777777777777776yaに S0.05555555555555555yflucene S0.05555555555555555ya- S0.05555555555555555yegosen S0.05555555555555555yaの T0.027777777777777776ya話 T0.027777777777777776yaで S0.08333333333333333yaす S0.08333333333333333ya。 S0.05555555555555555ya  S0.05555555555555555ycしかも T0.027777777777777776ya、 S0.05555555555555555ydあんまり T0.027777777777777776yc嬉しく T0.027777777777777776ybない T0.027777777777777776yb話し T0.027777777777777776yeissue T0.027777777777777776yaを T0.027777777777777776ycアップ T0.027777777777777776yaし T0.027777777777777776yaて T0.027777777777777776ycいます T0.027777777777777776yaが T0.027777777777777776yaと T0.027777777777777776>vc345<ybまた T0.022727272727272728ya、 S0.06818181818181818ye勉強会ログ T0.022727272727272728yaで S0.06818181818181818yaす T0.045454545454545456yeすみません T0.022727272727272728ya。 S0.09090909090909091ya  T0.045454545454545456yd直接業務 T0.022727272727272728yaと T0.022727272727272728yaは T0.045454545454545456yb関係 T0.022727272727272728ybない T0.022727272727272728yaの S0.06818181818181818yaが T0.045454545454545456yb今回 T0.022727272727272728yeリクルート T0.022727272727272728yb中野 T0.022727272727272728ybさん T0.022727272727272728yb話し T0.022727272727272728yaを T0.045454545454545456yaさ T0.022727272727272728ybれる T0.022727272727272728ycという T0.022727272727272728ya顔 T0.022727272727272728yb出し T0.022727272727272728yaて T0.022727272727272728ycきまし T0.022727272727272728yaた T0.022727272727272728yaも T0.022727272727272728>vc346<ygFluentd S0.02127659574468085ya  R0.0851063829787234yfmeetup S0.02127659574468085ybin S0.02127659574468085yeJapan S0.02127659574468085yaに S0.06382978723404255yb参加 R0.0425531914893617yaし R0.0425531914893617ybまし S0.02127659574468085yaた R0.0425531914893617ya。 R0.0425531914893617ycいつも S0.02127659574468085yb面白 S0.02127659574468085ybそう S0.02127659574468085yaな R0.0425531914893617ya話 S0.02127659574468085yaを S0.02127659574468085yb聞い S0.02127659574468085yaて R0.0425531914893617ydばっかり S0.02127659574468085yaの S0.02127659574468085yaで S0.02127659574468085ya、 R0.0425531914893617ya役 S0.02127659574468085yb立つ S0.02127659574468085ybため S0.02127659574468085ydスタッフ S0.02127659574468085ycとして S0.02127659574468085yaも S0.02127659574468085ycみまし S0.02127659574468085ybまず S0.02127659574468085yaは S0.02127659574468085yb会場 S0.02127659574468085yaが S0.02127659574468085yb綺麗 S0.02127659574468085>vc347<yc昨年末 T0.021739130434782608yaに S0.06521739130434782yb今年 T0.021739130434782608yaの S0.06521739130434782yb抱負 T0.021739130434782608ydについて T0.021739130434782608yb書い T0.043478260869565216yaた T0.043478260869565216yaで T0.043478260869565216yaす T0.021739130434782608yaが S0.06521739130434782ya、 T0.021739130434782608ya  T0.043478260869565216ya他 T0.021739130434782608yaも T0.021739130434782608yb興味 T0.043478260869565216ybある T0.043478260869565216ybもの T0.043478260869565216yb増え T0.021739130434782608yc備忘録 T0.021739130434782608ya＆ T0.021739130434782608yb公約 T0.021739130434782608ya？ T0.021739130434782608yaを T0.021739130434782608yb兼ね T0.021739130434782608yaて T0.043478260869565216ycブログ T0.021739130434782608ydおきます T0.021739130434782608ya。 T0.021739130434782608ya（ T0.021739130434782608ybあれ T0.021739130434782608yaば T0.021739130434782608>vc348<yb19 T0.015384615384615385yb22 T0.015384615384615385yb26 T0.015384615384615385yd2012 T0.015384615384615385ye23608 T0.015384615384615385ycという T0.015384615384615385ybこと T0.015384615384615385yaで T0.015384615384615385ya、 T0.015384615384615385ydいつもの T0.015384615384615385ybよう T0.015384615384615385yaに S0.03076923076923077yc勉強会 T0.015384615384615385yb参加 T0.015384615384615385yaし T0.015384615384615385yaた T0.015384615384615385ybメモ T0.015384615384615385ybです T0.015384615384615385ya。 T0.015384615384615385ya  S0.15384615384615385ydhttp T0.015384615384615385yb:/ T0.015384615384615385ya/ S0.07692307692307693ydatnd T0.015384615384615385ya. T0.015384615384615385ycorg T0.015384615384615385yfevents T0.015384615384615385yb日時 T0.015384615384615385ya: S0.06153846153846154yb01 T0.015384615384615385yb00 S0.03076923076923077ybto T0.015384615384615385yb会場 T0.015384615384615385yhアカデミーヒルズ T0.015384615384615385ya( T0.015384615384615385yc六本木 T0.015384615384615385ycヒルズ T0.015384615384615385ya内 T0.015384615384615385ya) T0.015384615384615385yc49階 T0.015384615384615385ya（ S0.03076923076923077yfタワーホール T0.015384615384615385yaA T0.015384615384615385ya） T0.015384615384615385yb港区 T0.015384615384615385ya六 T0.015384615384615385>vc349<ya2 T0.019230769230769232yb18 T0.019230769230769232yb19 T0.019230769230769232yb20 T0.019230769230769232yb30 T0.038461538461538464yd2012 T0.019230769230769232yb日時 T0.019230769230769232ya： T0.038461538461538464ya/ T0.038461538461538464yb01 T0.019230769230769232ya  S0.17307692307692307ya: T0.038461538461538464ya- T0.019230769230769232yb場所 T0.019230769230769232yeベルサール T0.019230769230769232yb三田 T0.019230769230769232ydRoom T0.019230769230769232ydシアター T0.019230769230769232yfInside T0.019230769230769232ydMapR T0.019230769230769232ybデモ T0.019230769230769232ya＋ T0.019230769230769232yb内部 T0.019230769230769232yaの T0.057692307692307696yaお T0.019230769230769232ya話 T0.019230769230769232ya。 T0.038461538461538464ya・ T0.019230769230769232yd自己紹介 T0.019230769230769232ygSusheel T0.019230769230769232ygKaushik T0.019230769230769232ya元 T0.019230769230769232yeYahoo T0.019230769230769232yfHadoop T0.019230769230769232ya系 T0.019230769230769232ya人 T0.019230769230769232yb製品 T0.019230769230769232>vc350<yeお久しぶり T0.022727272727272728yaで S0.06818181818181818yaす T0.022727272727272728ya。 S0.06818181818181818ygインフルエンザ T0.022727272727272728yd一家全滅 T0.022727272727272728ycという T0.022727272727272728yb最悪 T0.022727272727272728yaの T0.045454545454545456yb状況 T0.022727272727272728yaに T0.022727272727272728yb陥っ T0.022727272727272728yaて T0.022727272727272728yaい T0.022727272727272728yaた T0.045454545454545456ya我 T0.022727272727272728yaが T0.022727272727272728ya家 T0.022727272727272728yaし T0.045454545454545456ya  T0.045454545454545456yb流行 T0.022727272727272728ybてる T0.022727272727272728yaみ T0.022727272727272728ybたい T0.022727272727272728yaな T0.022727272727272728ybでみ T0.022727272727272728ycなさん T0.022727272727272728yaも T0.022727272727272728ya気 T0.022727272727272728yaを T0.022727272727272728ycつけて T0.022727272727272728yaく T0.022727272727272728yaだ T0.022727272727272728ybさい T0.022727272727272728ybさて T0.022727272727272728ya、 T0.022727272727272728>vc351<ya4 T0.030303030303030304yb先日 T0.030303030303030304yaの S0.09090909090909091ydSolr S0.06060606060606061yc勉強会 T0.030303030303030304yaで T0.030303030303030304yfLucene T0.030303030303030304ya/ T0.030303030303030304ya. T0.030303030303030304yax T0.030303030303030304ya系 T0.030303030303030304yflucene T0.030303030303030304ya- T0.030303030303030304yegosen T0.030303030303030304ydについて T0.030303030303030304yb質問 T0.030303030303030304yaを S0.06060606060606061yb受け T0.030303030303030304yaて T0.030303030303030304yaい T0.030303030303030304yaた S0.06060606060606061yb忘れ T0.030303030303030304ybない T0.030303030303030304ybよう T0.030303030303030304yaに T0.030303030303030304ya（ T0.030303030303030304yb年越 T0.030303030303030304yfしちゃいまし T0.030303030303030304>vc352<ydあけまし S0.02631578947368421yaて S0.05263157894736842ybおめ S0.02631578947368421yaで S0.07894736842105263ygとうございます S0.02631578947368421ya。 S0.10526315789473684ya（ S0.02631578947368421ybもう S0.02631578947368421yb5日 S0.02631578947368421yaす S0.02631578947368421yaが S0.02631578947368421ya） S0.02631578947368421ya  S0.02631578947368421yb今年 S0.02631578947368421yaも S0.02631578947368421yflucene S0.02631578947368421ya- S0.02631578947368421yegosen S0.02631578947368421yaを S0.05263157894736842yb中心 S0.02631578947368421yaに S0.02631578947368421yb色々 S0.02631578947368421yaと S0.02631578947368421yb記事 S0.02631578947368421yb書い S0.02631578947368421ydいきます S0.02631578947368421yaの S0.02631578947368421ya、 S0.05263157894736842ydツッコミ S0.02631578947368421ybコメ S0.02631578947368421>vc353<ya他 T0.021739130434782608yaの S0.10869565217391304ya方 T0.021739130434782608yeたちよりひ T0.021739130434782608yaと T0.043478260869565216ya足 T0.021739130434782608yaは T0.021739130434782608ybやい T0.021739130434782608yaで T0.043478260869565216yaす T0.021739130434782608yaが T0.043478260869565216ya、 T0.043478260869565216yb今年 T0.043478260869565216yb仕事 T0.021739130434782608ye終わりまし T0.021739130434782608yaた T0.043478260869565216ya。 T0.043478260869565216ya  T0.043478260869565216ydせっかく T0.021739130434782608ycブログ T0.021739130434782608yaを T0.021739130434782608yb始め T0.021739130434782608yb振り T0.021739130434782608yb返り T0.021739130434782608yb来年 T0.021739130434782608yb抱負 T0.021739130434782608ybなど T0.021739130434782608yb書い T0.021739130434782608yaて T0.021739130434782608yaみ T0.021739130434782608ybよう T0.021739130434782608yaか T0.021739130434782608ybなと T0.021739130434782608ya振 T0.021739130434782608>vc354<ya@ S0.02631578947368421ygyusukey S0.02631578947368421ybさん S0.02631578947368421yaに S0.05263157894736842ycサイン S0.02631578947368421yaを S0.05263157894736842ycもらう S0.02631578947368421yb目的 S0.02631578947368421yaで S0.05263157894736842yc勉強会 S0.02631578947368421yb参加 S0.02631578947368421yaし S0.02631578947368421yaて S0.05263157894736842ycきまし S0.02631578947368421yaた S0.05263157894736842ya。 S0.02631578947368421yb前回 S0.02631578947368421ycもらい S0.02631578947368421ycそびれ S0.02631578947368421yaの S0.02631578947368421yaｗ S0.02631578947368421ya  S0.05263157894736842yb残念 S0.02631578947368421yaな S0.02631578947368421yaが S0.02631578947368421yaら S0.02631578947368421ya、 S0.02631578947368421ybまだ S0.02631578947368421ygTwitter S0.02631578947368421ycAPI S0.02631578947368421yb触っ S0.02631578947368421ybない S0.02631578947368421>vc355<ya1 S0.05714285714285714ya2 S0.02857142857142857yflucene S0.02857142857142857ya- S0.02857142857142857yegosen S0.02857142857142857yaの S0.05714285714285714yc最新版 S0.02857142857142857ya（ S0.02857142857142857ya. S0.05714285714285714ya） S0.02857142857142857yaを S0.02857142857142857ydリリース S0.02857142857142857ycしまし S0.02857142857142857yaた S0.02857142857142857ya。 S0.05714285714285714ya  S0.05714285714285714yiプロジェクトページ S0.02857142857142857ybより S0.02857142857142857yfダウンロード S0.02857142857142857yaが S0.02857142857142857yb可能 S0.02857142857142857yaで S0.08571428571428572yaす S0.02857142857142857yb今回 S0.02857142857142857yb修正 S0.02857142857142857yaは S0.02857142857142857ya、 S0.02857142857142857ye特定文字列 S0.02857142857142857>vc356<ybいつ T0.023255813953488372ybもの T0.023255813953488372ybよう T0.023255813953488372yaに T0.046511627906976744ydSolr T0.023255813953488372yc勉強会 T0.023255813953488372yb参加 T0.023255813953488372yaし T0.023255813953488372yaて T0.023255813953488372ycきまし T0.023255813953488372yaた T0.023255813953488372ya。 S0.11627906976744186ya  T0.046511627906976744yc皆勤賞 T0.023255813953488372yaを T0.046511627906976744yc継続中 T0.023255813953488372yaで T0.046511627906976744yaす T0.023255813953488372ya（ T0.023255813953488372yb暇人 T0.023255813953488372ycという T0.023255813953488372yaは T0.046511627906976744ybなし T0.023255813953488372yaも T0.023255813953488372ya） T0.023255813953488372yb今回 T0.023255813953488372yb話し T0.023255813953488372yb聞き T0.023255813953488372ybたい T0.023255813953488372ycすねぇ T0.023255813953488372ycといっ T0.023255813953488372ybたら T0.023255813953488372ya、 T0.023255813953488372ybいや T0.023255813953488372>vc357<ycという T0.030303030303030304ybこと T0.030303030303030304yaで S0.06060606060606061ya、 S0.06060606060606061yc懲りず T0.030303030303030304yaに S0.09090909090909091ya# T0.030303030303030304ygDSIRNLP T0.030303030303030304yb参加 T0.030303030303030304yaし S0.06060606060606061yaて T0.030303030303030304ycきまし T0.030303030303030304yaた T0.030303030303030304ya。 T0.030303030303030304ya  T0.030303030303030304yb基礎 T0.030303030303030304ya的 T0.030303030303030304yaな T0.030303030303030304yb部分 T0.030303030303030304yaを T0.030303030303030304ybおろ T0.030303030303030304ybそか T0.030303030303030304ybたく T0.030303030303030304ydないけど T0.030303030303030304yhTokyoNLP T0.030303030303030304ybとか T0.030303030303030304yiWebMining T0.030303030303030304yaは T0.030303030303030304>vc358<ydひさびさ T0.022727272727272728yaに T0.045454545454545456ya、 S0.06818181818181818ycMBA T0.022727272727272728yaの T0.022727272727272728yaお T0.022727272727272728ya話 T0.022727272727272728yaで T0.045454545454545456yaす T0.022727272727272728ya。 S0.06818181818181818ya  S0.06818181818181818yfセットアップ T0.022727272727272728ydといって T0.022727272727272728yaも T0.045454545454545456yb物理 T0.022727272727272728ya的 T0.022727272727272728yaな T0.022727272727272728ya方 T0.022727272727272728ybすね T0.022727272727272728yb以前 T0.022727272727272728ycケース T0.022727272727272728ya（ T0.022727272727272728ycカバー T0.022727272727272728ya） T0.022727272727272728ydについて T0.022727272727272728yb記載 T0.022727272727272728yaし T0.022727272727272728ybまし T0.022727272727272728yaた T0.045454545454545456ybこの T0.022727272727272728yb記事 T0.022727272727272728yb書い T0.022727272727272728yaて T0.022727272727272728ybあっ T0.022727272727272728>vc359<ybどん T0.022727272727272728yaな T0.022727272727272728ya本 S0.06818181818181818yaで S0.06818181818181818yaも T0.022727272727272728yb大量 T0.022727272727272728yaに T0.022727272727272728yc読める T0.022727272727272728ya「 T0.022727272727272728yb速読 T0.022727272727272728ya」 T0.022727272727272728yaの T0.022727272727272728ya  T0.045454545454545456ygTwitter T0.022727272727272728yb知り T0.022727272727272728yb合っ T0.022727272727272728yaた S0.06818181818181818ya方 T0.022727272727272728yaが T0.022727272727272728ybこの T0.022727272727272728ydについて T0.022727272727272728yb書か T0.022727272727272728yaれ T0.022727272727272728yaて T0.022727272727272728yaい T0.022727272727272728ycブログ T0.022727272727272728yb記事 T0.022727272727272728yaを T0.045454545454545456yb読ん T0.022727272727272728yb興味 T0.022727272727272728yb持ち T0.022727272727272728ya、 T0.022727272727272728yd読みまし T0.022727272727272728ya。 T0.022727272727272728yb書籍 T0.022727272727272728ya（ T0.022727272727272728>vc360<yb12e0.025yd2010e0.025yfHadoope0.025ylソースコードリーディングe0.025ya第d0.05yb7回e0.025yaにd0.05yb参加d0.05yaしd0.05ybましe0.025yaたd0.05ya。d0.05ya d0.05ybいつe0.025ybものe0.025yaごe0.025ybとくe0.025ya、e0.025yc自分用e0.025yaのd0.05ybメモe0.025yaをe0.025ybとっe0.025yaてd0.05yaいe0.025yaでe0.025yb6回e0.025ya（e0.025ya/e0.025ya）e0.025yaはe0.025>vc361<yc先週末 S0.02127659574468085ybから S0.02127659574468085yb勤労 S0.02127659574468085yb感謝 S0.02127659574468085yaの R0.0851063829787234yc日まで S0.02127659574468085yb風邪 R0.0425531914893617yaで R0.0851063829787234yc寝こん S0.02127659574468085ybまし S0.02127659574468085yaた R0.0425531914893617ya。 R0.0851063829787234ya  R0.0425531914893617yaみ S0.02127659574468085ycなさん S0.02127659574468085ya、 R0.0425531914893617yb朝晩 S0.02127659574468085yb冷え S0.02127659574468085yb込み S0.02127659574468085yaが S0.02127659574468085yc激しい S0.02127659574468085yaに S0.02127659574468085yaは S0.02127659574468085ya気 S0.02127659574468085yaを S0.02127659574468085ycつけて S0.02127659574468085yaく S0.02127659574468085yaだ S0.02127659574468085ybさい S0.02127659574468085yb季節 S0.02127659574468085yb言葉 S0.02127659574468085yaも S0.02127659574468085yb入れ S0.02127659574468085ya本 S0.02127659574468085>vc362<yb今回 S0.06818181818181818yaは S0.06818181818181818ya、 T0.045454545454545456yc触ろう T0.022727272727272728yaと T0.022727272727272728yb思っ T0.022727272727272728yaて S0.06818181818181818yb触れ T0.022727272727272728yaい T0.022727272727272728ybない T0.022727272727272728ygMongoDB T0.022727272727272728yaの T0.045454545454545456yc勉強会 T0.022727272727272728yaに T0.045454545454545456yb行っ T0.022727272727272728yc来まし T0.022727272727272728yaた T0.045454545454545456ya。 T0.045454545454545456ya  T0.045454545454545456yb2週 T0.022727272727272728yb連続 T0.022727272727272728yb渋谷 T0.022727272727272728yaで T0.045454545454545456ycさすが T0.022727272727272728yb出口 T0.022727272727272728yaを T0.022727272727272728ybすん T0.022727272727272728ybなり T0.022727272727272728yaれ T0.022727272727272728ybまし T0.022727272727272728ya初 T0.022727272727272728>vc363<ydSolr S0.02631578947368421ya本 S0.02631578947368421yaの S0.07894736842105263yb武田 S0.02631578947368421ybさん S0.02631578947368421ybから S0.02631578947368421yb教え S0.02631578947368421yaて S0.07894736842105263yaい S0.02631578947368421yaた S0.07894736842105263ybだい S0.02631578947368421yfSplunk S0.05263157894736842ya  S0.05263157894736842ydイベント S0.02631578947368421yaに S0.05263157894736842yb行っ S0.02631578947368421yc来まし S0.02631578947368421ya。 S0.02631578947368421yaと S0.02631578947368421yaは S0.02631578947368421yb様々 S0.02631578947368421yaな S0.02631578947368421yb機器 S0.02631578947368421ybログ S0.02631578947368421ybなど S0.02631578947368421yaを S0.02631578947368421yc一箇所 S0.02631578947368421yb集め S0.02631578947368421ydリアルタ S0.02631578947368421>vc364<yc最近忘 T0.020833333333333332yaれ T0.020833333333333332yaや T0.020833333333333332ybすい T0.020833333333333332yaの S0.08333333333333333yaでf0.0625ya、 T0.041666666666666664yb記録 T0.020833333333333332yaし T0.020833333333333332yaて T0.020833333333333332ycおこう T0.020833333333333332yaか T0.020833333333333332yaと T0.041666666666666664ya。f0.0625ya f0.0625yb読ん T0.020833333333333332yaだ T0.020833333333333332ydスライドf0.0625yb簡単 T0.020833333333333332yaな T0.020833333333333332yb内容 T0.020833333333333332yb感想 T0.020833333333333332yaすf0.0625yaち T0.020833333333333332ybなみ T0.020833333333333332yaに T0.020833333333333332yb一覧 T0.020833333333333332yaは T0.041666666666666664ycこちら T0.020833333333333332ya※ T0.020833333333333332yaへ T0.020833333333333332ycリンク T0.020833333333333332>vc365<yhBookscan T0.027777777777777776ycという T0.027777777777777776ydサービス S0.05555555555555555yaが T0.027777777777777776ydあります T0.027777777777777776ya。 S0.05555555555555555ya  S0.05555555555555555yb書籍 T0.027777777777777776yaを S0.08333333333333333yc電子化 T0.027777777777777776ya（ T0.027777777777777776ycPDF T0.027777777777777776ya） T0.027777777777777776ybして T0.027777777777777776yb原本 T0.027777777777777776yb破棄 T0.027777777777777776yaし T0.027777777777777776yaて S0.05555555555555555ycくれる T0.027777777777777776yaで T0.027777777777777776yaす T0.027777777777777776yd電子書籍 T0.027777777777777776yaに T0.027777777777777776yaは T0.027777777777777776ybずっ T0.027777777777777776yaと T0.027777777777777776yb興味 T0.027777777777777776yb持っ T0.027777777777777776ycいまし T0.027777777777777776yaた T0.027777777777777776>vc366<ya0 S0.03225806451612903ya1 S0.03225806451612903ya2 S0.03225806451612903yflucene S0.03225806451612903ya- S0.03225806451612903yegosen S0.03225806451612903yaの S0.03225806451612903yc最新版 S0.03225806451612903ya（ S0.03225806451612903ya. S0.06451612903225806ya） S0.03225806451612903yaを S0.03225806451612903ydリリース S0.03225806451612903ycしまし S0.03225806451612903yaた S0.03225806451612903ya。 S0.06451612903225806ya  S0.06451612903225806yiプロジェクトページ S0.03225806451612903ybより S0.03225806451612903yfダウンロード S0.03225806451612903yaが S0.03225806451612903yb可能 S0.03225806451612903yaで S0.03225806451612903yaす S0.03225806451612903yf新規追加機能 S0.03225806451612903ydについて S0.03225806451612903yaは S0.03225806451612903ycこちら S0.03225806451612903>vc367<ya1 S0.02564102564102564yfすぐやります S0.02564102564102564yaと S0.02564102564102564yd言いつつ S0.02564102564102564ya、 S0.05128205128205128ybはや S0.02564102564102564ybヶ月 S0.02564102564102564ya。 R0.2564102564102564ya  S0.10256410256410256ya腰 S0.02564102564102564yaが S0.02564102564102564yb重い S0.02564102564102564ygダメエンジニア S0.02564102564102564yaで S0.05128205128205128ybすね S0.02564102564102564yeすみません S0.02564102564102564yaし S0.02564102564102564yaた S0.05128205128205128ydようやく S0.02564102564102564yetrunk S0.02564102564102564yaに S0.02564102564102564ydコミット S0.02564102564102564ycしまし S0.02564102564102564ybすぐ S0.02564102564102564>vc368<yd2011 T0.023809523809523808ydJJUG T0.023809523809523808ya  S0.09523809523809523ycCCC T0.023809523809523808ydFall T0.023809523809523808yaに T0.047619047619047616yb参加 T0.023809523809523808yaし T0.023809523809523808yaて T0.023809523809523808ycきまし T0.023809523809523808yaた T0.023809523809523808ya。 S0.07142857142857142yc個人的 T0.023809523809523808yaは T0.023809523809523808yaか T0.023809523809523808ybなり T0.023809523809523808yb久々 T0.023809523809523808yaの S0.07142857142857142ydJava T0.047619047619047616ygカンファレンス T0.023809523809523808yaで T0.047619047619047616yaす T0.023809523809523808ya（ T0.023809523809523808ya※ T0.023809523809523808ydあくまで T0.023809523809523808ya「 T0.023809523809523808ya」 T0.023809523809523808ycという T0.023809523809523808ya話 T0.023809523809523808ydSolr T0.023809523809523808yaや T0.023809523809523808ycHad T0.023809523809523808>vc369<yb昨日 S0.02631578947368421ya、 S0.07894736842105263yb文章 S0.02631578947368421ybから S0.02631578947368421yb特定 S0.02631578947368421yaの S0.02631578947368421yb単語 S0.02631578947368421ya（ S0.02631578947368421ycリスト S0.02631578947368421ybあり S0.02631578947368421ya） S0.02631578947368421yaを S0.05263157894736842yb探し S0.02631578947368421ybたい S0.02631578947368421ycという S0.05263157894736842ya話 S0.05263157894736842yb聞き S0.02631578947368421yflucene S0.02631578947368421ya- S0.02631578947368421yegosen S0.02631578947368421yaで S0.02631578947368421yaも S0.02631578947368421ycできる S0.02631578947368421ybねぇ S0.02631578947368421yaに S0.02631578947368421ydなりまし S0.02631578947368421yaた S0.02631578947368421ya。 S0.02631578947368421ya  S0.02631578947368421ybまぁ S0.02631578947368421yb考え S0.02631578947368421yaて S0.02631578947368421ybみれ S0.02631578947368421>vc370<ycちょっ T0.022727272727272728yaと T0.022727272727272728ya間 T0.022727272727272728yaが S0.06818181818181818ycあいて T0.022727272727272728ycしまっ T0.022727272727272728yaた T0.045454545454545456ya、 T0.022727272727272728ydようやく T0.022727272727272728ybIo T0.022727272727272728yaの S0.13636363636363635yc1日目 T0.022727272727272728yaを T0.022727272727272728yb終了 T0.022727272727272728ya。 T0.045454545454545456ya  T0.045454545454545456ybなれ T0.022727272727272728ybない T0.022727272727272728yb感じ T0.022727272727272728yb言語 T0.022727272727272728yaな T0.022727272727272728yaで T0.022727272727272728yb苦労 T0.022727272727272728yaし T0.022727272727272728ybまし T0.022727272727272728yb今回 T0.022727272727272728yaも T0.022727272727272728ygセルフスタディ T0.022727272727272728ya私 T0.022727272727272728yb回答 T0.022727272727272728yb最後 T0.022727272727272728ya方 T0.022727272727272728yaに T0.022727272727272728ya記 T0.022727272727272728>vc371<yb久々e0.025yaにd0.05ya、d0.05ycMBAe0.025yaのe0.075yc備忘録e0.025yaでd0.05yaすe0.025ya。e0.075ya e0.075ybあれe0.025ybからe0.025yc色々入e0.025yaれe0.025ybましe0.025yaたd0.05ybなのe0.025yb入れe0.025ycソフトe0.025yb一覧e0.025yaをd0.05yb追加e0.025ycAIRe0.025ya：e0.025yiTweetDecke0.025yfインストールe0.025ybするe0.025yb必要e0.025yaだe0.025>vc372<yfLucene T0.027777777777777776ya/ T0.027777777777777776ydSolr S0.05555555555555555yaの S0.08333333333333333ybML T0.027777777777777776yaで T0.027777777777777776yb管理 T0.027777777777777776yb画面 T0.027777777777777776yaを T0.027777777777777776yc新しく T0.027777777777777776ybする T0.027777777777777776ycという T0.027777777777777776ydチケット T0.027777777777777776yaが T0.027777777777777776yb流れ T0.027777777777777776yaて S0.05555555555555555yaい T0.027777777777777776yaた S0.08333333333333333ydでちょっ T0.027777777777777776yaと S0.08333333333333333yb触っ S0.05555555555555555yc見まし T0.027777777777777776ya。 T0.027777777777777776ya  T0.027777777777777776ybほん T0.027777777777777776ydにちょっ T0.027777777777777776ybだけ T0.027777777777777776>vc373<yb遅く T0.019230769230769232ydなりまし T0.019230769230769232yaた T0.038461538461538464yaが T0.038461538461538464ya、 T0.057692307692307696yb続き T0.019230769230769232ybです T0.019230769230769232ya。 S0.07692307692307693ya  T0.038461538461538464ybさら T0.019230769230769232yaに T0.038461538461538464yc英語力 T0.019230769230769232yaの T0.057692307692307696ybなさ T0.019230769230769232yaを T0.038461538461538464yb痛感 T0.019230769230769232yaし T0.019230769230769232yaて T0.038461538461538464yb凹ん T0.019230769230769232yaで T0.057692307692307696ybいる T0.019230769230769232yaと T0.057692307692307696ybころ T0.038461538461538464yaす T0.038461538461538464yb何か T0.019230769230769232ya役 T0.019230769230769232yb立て T0.019230769230769232yaば T0.019230769230769232ya恥 T0.019230769230769232yb晒す T0.019230769230769232yb一応 T0.019230769230769232yb訳し T0.019230769230769232yaみ T0.019230769230769232>vc374<ycちょっ T0.022727272727272728yaと T0.022727272727272728yb興味 T0.022727272727272728yaが T0.022727272727272728ybある T0.022727272727272728yaの S0.11363636363636363yaで T0.045454545454545456ya、 T0.045454545454545456yb訳し T0.022727272727272728yaて S0.06818181818181818ycみまし T0.022727272727272728yaた T0.022727272727272728ya。 T0.045454545454545456ya（ T0.045454545454545456ydWiki T0.022727272727272728ycページ T0.045454545454545456yaは T0.022727272727272728ycこちら T0.022727272727272728ya） T0.022727272727272728ya  T0.022727272727272728yb更新 T0.022727272727272728yaさ T0.022727272727272728yaれ T0.022727272727272728ybいる T0.022727272727272728ybよう T0.022727272727272728yaな T0.022727272727272728ybもと T0.022727272727272728yb文章 T0.022727272727272728yaも T0.022727272727272728yb残し T0.022727272727272728ydおきます T0.022727272727272728yb下部 T0.022727272727272728yb続き T0.022727272727272728>vc375<yd2011 T0.018518518518518517yfHadoop T0.018518518518518517ya  S0.09259259259259259yjConference T0.018518518518518517yeJapan T0.018518518518518517ydFall T0.018518518518518517yaに T0.018518518518518517yb行っ T0.018518518518518517yaて T0.037037037037037035ycきまし T0.018518518518518517yaた S0.07407407407407407ya。 T0.037037037037037035ybまず T0.018518518518518517yaは T0.018518518518518517ya、 S0.07407407407407407ycユーザ T0.018518518518518517ya会 T0.018518518518518517yaの T0.037037037037037035yb方々 S0.05555555555555555yb運営 T0.018518518518518517yb発表 T0.018518518518518517yaさ T0.018518518518518517yaれ T0.018518518518518517yaお T0.018518518518518517yb疲れ T0.018518518518518517ya様 T0.018518518518518517yaで T0.018518518518518517yaし T0.037037037037037035ybこん T0.018518518518518517yaな T0.018518518518518517yb機会 T0.018518518518518517yaを T0.018518518518518517yb用意 T0.018518518518518517yaい T0.018518518518518517ybだき T0.018518518518518517ybあり T0.018518518518518517yaが T0.018518518518518517ybとう T0.018518518518518517>vc376<yb台風 T0.021739130434782608yc15号 T0.021739130434782608yaす T0.043478260869565216ycごかっ T0.021739130434782608yaた S0.08695652173913043yaで S0.08695652173913043ybすね T0.021739130434782608ya。 S0.08695652173913043yb幸い T0.021739130434782608yaに S0.06521739130434782yaも T0.021739130434782608ya（ T0.021739130434782608ya？ T0.021739130434782608ya） T0.021739130434782608yb夏休 T0.021739130434782608yaみ T0.021739130434782608ybだっ T0.021739130434782608yaの T0.021739130434782608ya、 T0.021739130434782608yb通勤 T0.021739130434782608ybなど T0.021739130434782608ycひどい T0.021739130434782608ya目 T0.021739130434782608yb合わ T0.021739130434782608yaず T0.021739130434782608ydすみまし T0.021739130434782608ya  T0.021739130434782608yb風雨 T0.021739130434782608yaは T0.021739130434782608ydすごくて T0.021739130434782608ycちょっ T0.021739130434782608yaと T0.021739130434782608yc怖かっ T0.021739130434782608yaが T0.021739130434782608>vc377<ya3 T0.021739130434782608ya4 T0.021739130434782608ydSolr T0.043478260869565216ya/ T0.021739130434782608yfLucene T0.043478260869565216ya  S0.10869565217391304ya. T0.021739130434782608yaが T0.021739130434782608ydリリース S0.06521739130434782yaさ T0.021739130434782608yaれ T0.021739130434782608ybまし T0.021739130434782608yaた T0.021739130434782608ya。 T0.043478260869565216ya（ T0.021739130434782608yb速報 T0.021739130434782608ya） T0.021739130434782608yb以下 T0.021739130434782608ya、 T0.043478260869565216ya各 T0.021739130434782608ycサイト T0.021739130434782608yaへ T0.021739130434782608yaの S0.08695652173913043ycリンク T0.021739130434782608yaで T0.021739130434782608yaす T0.021739130434782608yaお T0.043478260869565216yc知らせ T0.043478260869565216ycちなみ T0.021739130434782608yaに T0.021739130434782608yb先日 T0.021739130434782608>vc378<ycという T0.022727272727272728ybこと T0.022727272727272728yaで T0.022727272727272728ya、 T0.022727272727272728ydRuby T0.022727272727272728yaの S0.11363636363636363yc最終日 T0.022727272727272728yb感想 T0.022727272727272728ya。 S0.06818181818181818ya  T0.045454545454545456yb今回 T0.022727272727272728yaも T0.022727272727272728ygセルフスタディ T0.022727272727272728ya私 T0.022727272727272728yb回答 T0.022727272727272728yaが T0.022727272727272728yb最後 T0.022727272727272728ya方 T0.022727272727272728yaに T0.022727272727272728yb記載 T0.022727272727272728yaさ T0.022727272727272728yaれ T0.022727272727272728yaて T0.022727272727272728ybます T0.022727272727272728ya見 T0.022727272727272728ybたく T0.022727272727272728ybない T0.022727272727272728ya人 T0.022727272727272728yaは T0.022727272727272728ya気 T0.022727272727272728yaを T0.022727272727272728ycつけて T0.022727272727272728yaく T0.022727272727272728yaだ T0.022727272727272728ybさい T0.022727272727272728ydツッコミ T0.022727272727272728ya大 T0.022727272727272728>vc379<ya「 S0.02040816326530612ya第 S0.04081632653061224yb6回 S0.04081632653061224ydSolr S0.02040816326530612yc勉強会 S0.02040816326530612ya」 S0.02040816326530612yaに S0.04081632653061224yb参加 S0.02040816326530612yaし S0.02040816326530612ybまし S0.02040816326530612yaた S0.04081632653061224ya。 T0.061224489795918366ya  T0.061224489795918366ybなん S0.02040816326530612ycだかん S0.02040816326530612yaだ S0.02040816326530612yaと S0.02040816326530612yaで S0.10204081632653061ya、 T0.061224489795918366ya今 S0.02040816326530612yaの S0.04081632653061224ycところ S0.02040816326530612yc皆勤賞 S0.02040816326530612yaす S0.04081632653061224ycという S0.02040816326530612ybこと S0.02040816326530612ya主 S0.02040816326530612yc自分用 S0.02040816326530612yaが S0.02040816326530612ybメモ S0.02040816326530612ybなど S0.02040816326530612ybとっ S0.02040816326530612ya概 S0.02040816326530612>vc380<ycという T0.023255813953488372ybこと T0.023255813953488372yaで T0.046511627906976744ya、 T0.023255813953488372ygRuby2日目 T0.023255813953488372yaの S0.11627906976744186yb感想 T0.023255813953488372ya（ T0.023255813953488372yc2日目 T0.023255813953488372ybだけ T0.023255813953488372yc2日間 T0.023255813953488372yaか T0.023255813953488372ybかっ T0.023255813953488372yaた T0.046511627906976744yaは T0.023255813953488372yb内緒 T0.023255813953488372ya。 S0.09302325581395349ya） T0.023255813953488372ya  T0.023255813953488372yb今回 T0.023255813953488372yaも T0.023255813953488372ygセルフスタディ T0.023255813953488372ya私 T0.023255813953488372yb回答 T0.023255813953488372yaが T0.023255813953488372yb最後 T0.023255813953488372ya方 T0.023255813953488372yaに T0.023255813953488372yb記載 T0.023255813953488372yaさ T0.023255813953488372yaれ T0.023255813953488372yaて T0.023255813953488372ybます T0.023255813953488372ya見 T0.023255813953488372>vc381<ya実 T0.024390243902439025yaに S0.04878048780487805yb3年 T0.024390243902439025yeぶりくらい T0.024390243902439025ydゆっくり T0.024390243902439025ycできる T0.024390243902439025yb日々 T0.024390243902439025yaが T0.024390243902439025yb訪れ T0.024390243902439025yaた S0.04878048780487805yaの R0.0975609756097561yaで T0.024390243902439025ya、 T0.024390243902439025yd積読状態 T0.024390243902439025ya本 T0.024390243902439025yaを S0.04878048780487805yb消化 T0.024390243902439025yaし T0.024390243902439025ybよう T0.024390243902439025yaと T0.024390243902439025ya「 T0.024390243902439025yb7つ S0.04878048780487805yb言語 T0.024390243902439025ya  S0.04878048780487805yb世界 T0.024390243902439025ya」 T0.024390243902439025yb読み T0.024390243902439025yd始めまし T0.024390243902439025ya。 T0.024390243902439025ydせっかく T0.024390243902439025ycブログ T0.024390243902439025yaも T0.024390243902439025yb始め T0.024390243902439025>vc382<yb現在 T0.030303030303030304yaの S0.09090909090909091yb出先 T0.030303030303030304yaで S0.09090909090909091ycMBA S0.06060606060606061yaを S0.06060606060606061yb使え T0.030303030303030304ybない S0.06060606060606061ya、 S0.09090909090909091ybなか S0.06060606060606061yb進ん T0.030303030303030304ybでい T0.030303030303030304yfセットアップ T0.030303030303030304yaす T0.030303030303030304ya。 S0.09090909090909091ya  T0.030303030303030304ybとり T0.030303030303030304ycあえず T0.030303030303030304ygEclipse T0.030303030303030304yhhomebrew T0.030303030303030304yeインストー T0.030303030303030304>vc383<ybすぐ S0.02564102564102564yaに S0.02564102564102564yfテストケース S0.05128205128205128yb追加 S0.02564102564102564yaし S0.05128205128205128ybます S0.02564102564102564yeといいつつ S0.02564102564102564ya、 S0.07692307692307693ybはや S0.02564102564102564yc一週間 S0.02564102564102564ya。 S0.07692307692307693ya  S0.05128205128205128ydようやく S0.02564102564102564yb仕事 S0.02564102564102564yaが S0.02564102564102564yb落ち S0.02564102564102564yb着い S0.02564102564102564yaた S0.05128205128205128yaの S0.05128205128205128yaで S0.05128205128205128yaを S0.02564102564102564yb追記 S0.02564102564102564ybまし S0.02564102564102564ybまだ S0.02564102564102564ycパッチ S0.02564102564102564yb段階 S0.02564102564102564yaす S0.02564102564102564yb一応 S0.02564102564102564ya異 S0.02564102564102564>vc384<yb先日 S0.02702702702702703ya、 S0.05405405405405406yb辞書 S0.02702702702702703yaの S0.08108108108108109ycjar S0.02702702702702703ydファイル S0.02702702702702703ybから S0.02702702702702703yb分離 S0.02702702702702703ydについて S0.02702702702702703ycパッチ S0.05405405405405406yaと S0.02702702702702703yb記事 S0.02702702702702703yaを S0.05405405405405406yd書きまし S0.02702702702702703yaた S0.05405405405405406ya。 S0.02702702702702703ya  S0.02702702702702703yeIssue S0.02702702702702703yaに S0.02702702702702703ybあげ S0.02702702702702703yaて S0.05405405405405406yaい S0.05405405405405406yfRobert S0.02702702702702703ybさん S0.02702702702702703yaが S0.02702702702702703ya見 S0.02702702702702703ydたらしく S0.02702702702702703ya次 S0.02702702702702703yaよ S0.02702702702702703>vc385<ydひさびさg0.03125yaにg0.09375ya、f0.0625yflucenef0.0625ya-f0.0625yegosenf0.0625yaのg0.03125yb話題g0.03125yaでg0.03125yaすg0.03125ya。g0.03125ya g0.03125yaはg0.03125ycjarf0.0625ydファイルf0.0625yb辞書g0.03125yaもg0.03125yb同梱g0.03125yaさg0.03125yaれg0.03125yaてg0.03125ybおりg0.03125yaをg0.03125yeクラスパスg0.03125>vc386<yeすみません S0.02631578947368421ya、 S0.10526315789473684ybまた S0.02631578947368421ycMBA S0.02631578947368421yb関連 S0.02631578947368421yaの S0.07894736842105263yb記事 S0.02631578947368421yaに S0.02631578947368421ybなっ S0.02631578947368421yaて S0.02631578947368421yeしまいまし S0.02631578947368421yaた S0.05263157894736842ya。 S0.05263157894736842ya  S0.05263157894736842ycという S0.02631578947368421ybこと S0.02631578947368421yaで S0.05263157894736842yc備忘録 S0.02631578947368421ybその S0.02631578947368421ya２ S0.02631578947368421ybです S0.02631578947368421yb前回 S0.02631578947368421yfからいくつか S0.02631578947368421yfインストール S0.02631578947368421yaや S0.02631578947368421yb環境 S0.02631578947368421yb設定 S0.02631578947368421yaを S0.02631578947368421yaし S0.02631578947368421>vc387<ycMac S0.02127659574468085ya  R0.1276595744680851ydBook S0.02127659574468085ycAir S0.02127659574468085yaの S0.06382978723404255yfセットアップ S0.02127659574468085yb関連 S0.02127659574468085yc備忘録 R0.0425531914893617ya（ R0.0425531914893617yb今回 S0.02127659574468085yaは S0.02127659574468085yaな S0.02127659574468085yaで S0.02127659574468085ya、 R0.0425531914893617yb文体 S0.02127659574468085yaも R0.0425531914893617yb変か S0.02127659574468085ya） R0.0425531914893617yfインストール S0.02127659574468085yaし R0.0425531914893617yaた R0.0425531914893617ybもの S0.02127659574468085yc順不同 S0.02127659574468085ybだい S0.02127659574468085ybたい S0.02127659574468085ybこの S0.02127659574468085ycサイト S0.02127659574468085yaを S0.02127659574468085yb参考 S0.02127659574468085yaに S0.02127659574468085ya。 S0.02127659574468085yhEvernote S0.02127659574468085ygDropbox S0.02127659574468085>vc388<yc個人用e0.025yaのd0.05ybPCe0.075yaをd0.05yb８年d0.05ybぶりe0.025yaにe0.075yb新調e0.025yaしd0.05ybましe0.025yaたd0.05ya。e0.025ya d0.05yd前回購入e0.025ya家e0.025yfデスクトップe0.025yaがe0.025ybもうe0.025ybものe0.025ydなりつつe0.025ybあるe0.025ycというe0.025ybことe0.025yaでe0.025ya、e0.025ycさすがe0.025yb今年e0.025yaはe0.025yc買おうe0.025yaとe0.025>vc389<ycかなり S0.02631578947368421yb遅く S0.02631578947368421ydなりまし S0.02631578947368421yaた S0.05263157894736842yaが S0.05263157894736842ya、 S0.05263157894736842ya第 S0.02631578947368421yb1回 S0.02631578947368421ya  S0.07894736842105263ycデータ S0.02631578947368421yb構造 S0.02631578947368421yaと S0.05263157894736842yb情報 S0.02631578947368421yb検索 S0.02631578947368421yg言語処理勉強会 S0.02631578947368421ya# S0.02631578947368421ygDSIRNLP S0.02631578947368421yaに S0.02631578947368421yb参加 S0.02631578947368421yaし S0.02631578947368421ybまし S0.02631578947368421ya。 S0.02631578947368421yb帰っ S0.02631578947368421yaて S0.02631578947368421ybから S0.02631578947368421yc２日半 S0.02631578947368421ybほど S0.02631578947368421yb寝込 S0.02631578947368421yaん S0.02631578947368421yaで S0.02631578947368421ycしまい S0.02631578947368421yb更新 S0.02631578947368421>vc390<yb以前 S0.02564102564102564ybから S0.02564102564102564yb春山 S0.02564102564102564ybさん S0.02564102564102564yaの S0.05128205128205128ycブログ S0.02564102564102564ya（ S0.02564102564102564ycリンク S0.02564102564102564ya） S0.02564102564102564yaや S0.02564102564102564yc勉強会 S0.02564102564102564yaで S0.07692307692307693ya耳 S0.02564102564102564yaに S0.05128205128205128yaは S0.05128205128205128yaし S0.05128205128205128yaて S0.02564102564102564yaい S0.02564102564102564yaた S0.05128205128205128yaす S0.02564102564102564yaが S0.02564102564102564ycソース S0.02564102564102564yb読ん S0.02564102564102564yeでいません S0.02564102564102564ya。 S0.02564102564102564ya  S0.02564102564102564yb先日 S0.02564102564102564ya、 S0.02564102564102564yfLucene S0.02564102564102564yjcontribute S0.02564102564102564yaさ S0.02564102564102564yaれ S0.02564102564102564>vc391<yb忘れ T0.022727272727272728yaて S0.06818181818181818ycしまう T0.022727272727272728yaの T0.045454545454545456yaで T0.045454545454545456ya、 S0.06818181818181818yc備忘録 T0.022727272727272728yaを T0.045454545454545456yb残し T0.022727272727272728ydおきます T0.022727272727272728ya。 T0.045454545454545456ya  T0.045454545454545456yb一応 T0.022727272727272728ycソース T0.022727272727272728yaに T0.045454545454545456yaは S0.09090909090909091yd少しずつ T0.022727272727272728ydコメント T0.022727272727272728ybいれ T0.022727272727272728ybいる T0.022727272727272728yaす T0.022727272727272728yaが S0.06818181818181818ya私 T0.022727272727272728yb残念 T0.022727272727272728yaな T0.022727272727272728yaら T0.022727272727272728yf自然言語処理 T0.022727272727272728yc初心者 T0.022727272727272728ya毛 T0.022727272727272728>vc392<ya1 S0.08333333333333333yflucene T0.027777777777777776ya- T0.027777777777777776yegosen T0.027777777777777776ya  S0.08333333333333333ya. S0.05555555555555555yaを S0.08333333333333333ydリリース T0.027777777777777776ycしまし S0.05555555555555555yaた S0.08333333333333333ya。 S0.05555555555555555yb先日 T0.027777777777777776yeお知らせし T0.027777777777777776ybバグ T0.027777777777777776yb修正 T0.027777777777777776yb取り T0.027777777777777776yb込ん T0.027777777777777776yaだ T0.027777777777777776ycjar T0.027777777777777776yb用意 T0.027777777777777776yaい T0.027777777777777776yfダウンロード T0.027777777777777776yaは T0.027777777777777776ycこちら T0.027777777777777776ybから T0.027777777777777776>vc393<ya3 T0.045454545454545456ydSolr T0.045454545454545456ya/ T0.022727272727272728yfLucene T0.045454545454545456ya  S0.11363636363636363ya. T0.022727272727272728yaが T0.022727272727272728ydリリース S0.09090909090909091yaさ T0.022727272727272728yaれ T0.022727272727272728ybまし T0.022727272727272728yaた T0.022727272727272728ya。 T0.045454545454545456ya（ T0.022727272727272728yb速報 T0.022727272727272728ya） T0.022727272727272728yb以下 T0.022727272727272728ya、 T0.022727272727272728ya各 T0.022727272727272728ycサイト T0.022727272727272728yaへ T0.022727272727272728yaの S0.09090909090909091ycリンク T0.022727272727272728yaで T0.022727272727272728yaす T0.022727272727272728yaお T0.045454545454545456yc知らせ T0.045454545454545456ycタイミ T0.022727272727272728>vc394<yc300 T0.029411764705882353ya「 T0.029411764705882353yfHadoop T0.029411764705882353yaを T0.029411764705882353yb中心 T0.029411764705882353yaと T0.029411764705882353yaし T0.058823529411764705yaた T0.058823529411764705yb分散 T0.029411764705882353yb環境 T0.029411764705882353yaで T0.029411764705882353yaの T0.058823529411764705ye開発方法論 T0.029411764705882353ya・ T0.058823529411764705yeモデリング T0.029411764705882353ye設計手法等 T0.029411764705882353ydについて T0.029411764705882353yc座談会 T0.029411764705882353ya( T0.029411764705882353ya第 T0.029411764705882353yb5回 T0.029411764705882353ya） T0.029411764705882353ya」 T0.029411764705882353yaに T0.029411764705882353yb参加 T0.029411764705882353ybまし T0.029411764705882353ya。 T0.029411764705882353ya名 T0.029411764705882353yb入る T0.029411764705882353yfイベントルー T0.029411764705882353>vc395<yb以前 S0.02631578947368421ya、 S0.02631578947368421ycこちら S0.02631578947368421yaで S0.05263157894736842yb話題 S0.02631578947368421yaに S0.05263157894736842yc上がっ S0.02631578947368421yaて S0.05263157894736842yaい S0.02631578947368421yaた S0.07894736842105263ya「 S0.02631578947368421yc未知語 S0.02631578947368421ya」 S0.02631578947368421yc関する S0.02631578947368421ylcompositePOS S0.02631578947368421yaの S0.05263157894736842ycエラー S0.02631578947368421ya件 S0.02631578947368421yaを S0.02631578947368421yb調査 S0.02631578947368421yaし S0.02631578947368421ybまし S0.05263157894736842ya。 S0.05263157894736842ya（ S0.02631578947368421ygTwitter S0.02631578947368421yaも S0.02631578947368421yb流れ S0.02631578947368421ya） S0.02631578947368421ya  S0.02631578947368421ya次 S0.02631578947368421>vc396<yflucened0.04ya-d0.16yegosend0.04yaのd0.08ymtrunkbranchesd0.04ya/d0.04ydimpld0.04yemecabd0.04ycdicd0.04yaにd0.04yeNAISTd0.04ydJDicd0.04ya d0.08ycford0.04yeMeCabd0.04yb辞書d0.04yaをd0.04yb利用d0.04yc出来るd0.04ycPred0.04>vc397<yb前回 T0.029411764705882353ya、 S0.08823529411764706yenaist T0.029411764705882353ya- T0.029411764705882353yfchasen T0.029411764705882353yaで T0.029411764705882353yaは T0.029411764705882353ygアルファベット T0.029411764705882353yaが T0.058823529411764705yb別々 T0.029411764705882353yaの T0.029411764705882353yb単語 T0.029411764705882353ycとして T0.029411764705882353yganalyze T0.029411764705882353yaさ T0.029411764705882353yaれ T0.029411764705882353yaて T0.029411764705882353ycしまう T0.029411764705882353ycという T0.029411764705882353ya話 T0.029411764705882353yaを T0.029411764705882353ycしまし T0.029411764705882353yaた T0.029411764705882353ya。 T0.029411764705882353ya  T0.029411764705882353ybただ T0.029411764705882353ybこれ T0.029411764705882353yaだ T0.029411764705882353yaと T0.029411764705882353yc英単語 T0.029411764705882353yb含ま T0.029411764705882353>vc398<ya0 S0.03225806451612903ya1 S0.06451612903225806yflucene S0.03225806451612903ya- S0.03225806451612903yegosen S0.03225806451612903yaの S0.03225806451612903ya. S0.06451612903225806yaが S0.06451612903225806ydリリース S0.03225806451612903yaさ S0.03225806451612903yaれ S0.03225806451612903ybまし S0.03225806451612903yaた S0.03225806451612903ya。 S0.03225806451612903ya  S0.03225806451612903yb大き S0.03225806451612903yaな S0.03225806451612903yb目玉 S0.03225806451612903yaは S0.03225806451612903y QJapaneseTokenizer S0.03225806451612903yb出力 S0.03225806451612903ybする S0.03225806451612903yc形態素 S0.03225806451612903yaに S0.03225806451612903yc関する S0.03225806451612903ycデータ S0.03225806451612903yaを S0.03225806451612903yb遅延 S0.03225806451612903>vc399<yflucene T0.043478260869565216ya- T0.043478260869565216yegosen T0.043478260869565216yaを S0.08695652173913043ydSolr T0.043478260869565216ya/ T0.043478260869565216yfLucene T0.043478260869565216yaで T0.043478260869565216yb利用 S0.08695652173913043ybする T0.043478260869565216yb場合 T0.043478260869565216ya、 T0.043478260869565216ykTokenFilter T0.043478260869565216yaし S0.08695652173913043yaて T0.043478260869565216yiTokenizer T0.043478260869565216yaが T0.043478260869565216yb出力 T0.043478260869565216yaた T0.043478260869565216yhToken対して T0.043478260869565216>vc400<yb辞書 S0.07894736842105263yaの S0.10526315789473684yb特性 S0.02631578947368421ydについて S0.07894736842105263ya  S0.10526315789473684yb現在 S0.02631578947368421yflucene S0.02631578947368421ya- S0.02631578947368421yegosen S0.02631578947368421yaで S0.05263157894736842yaは S0.02631578947368421yb以下 S0.02631578947368421yb2つ S0.02631578947368421yaが S0.02631578947368421yb利用 S0.02631578947368421yb可能 S0.02631578947368421yaす S0.02631578947368421ya。 S0.05263157894736842yb簡単 S0.02631578947368421yaに S0.02631578947368421yb違い S0.02631578947368421yb説明 S0.02631578947368421yaし S0.02631578947368421ybます S0.02631578947368421yfIPAdic S0.02631578947368421yaバ S0.02631578947368421>vc401<yb今回 T0.030303030303030304yaは S0.06060606060606061ycソース S0.09090909090909091yaの S0.06060606060606061yfダウンロード S0.06060606060606061yaと T0.030303030303030304ycビルド S0.06060606060606061ydについて T0.030303030303030304yaで T0.030303030303030304yaす S0.06060606060606061ya。 T0.030303030303030304ya  T0.030303030303030304yc最新版 T0.030303030303030304yaを S0.09090909090909091yb利用 T0.030303030303030304yaし S0.06060606060606061ybたり T0.030303030303030304ya、 T0.030303030303030304ygJavaDoc T0.030303030303030304yc見たい T0.030303030303030304yb場合 T0.030303030303030304yaて T0.030303030303030304ybから T0.030303030303030304>vc402<yb概要 S0.03333333333333333ya： S0.06666666666666667ya  S0.13333333333333333yfLucene S0.03333333333333333ya/ S0.03333333333333333ydSolr S0.03333333333333333yaの S0.06666666666666667yeコミッター S0.03333333333333333yaで S0.03333333333333333ybある S0.03333333333333333yfRobert S0.03333333333333333ydMuir S0.03333333333333333ybさん S0.03333333333333333yaが S0.03333333333333333yb始め S0.03333333333333333yaた S0.06666666666666667yfプロジェクト S0.03333333333333333yb歴史 S0.03333333333333333yeMeCab S0.03333333333333333ydJava S0.03333333333333333yc移植版 S0.03333333333333333ycとして S0.03333333333333333ydスタート S0.03333333333333333yaし S0.03333333333333333>vc403<yc今さら T0.041666666666666664yaで S0.08333333333333333yaすf0.0625yaがf0.0625ya、 T0.041666666666666664ycブログ T0.020833333333333332yaを T0.041666666666666664ycはじめ T0.020833333333333332yaて T0.020833333333333332yaみ T0.041666666666666664ybよう T0.041666666666666664yaか T0.020833333333333332yaと T0.041666666666666664ya。 T0.041666666666666664ya… T0.020833333333333332ya  T0.041666666666666664ydはじめて T0.020833333333333332yb思っ T0.020833333333333332yaた T0.041666666666666664yb一番 T0.020833333333333332yaの T0.020833333333333332yb理由 T0.020833333333333332yaは T0.020833333333333332yb自分 T0.020833333333333332yb調べ T0.020833333333333332ybこと T0.020833333333333332ybメモ T0.020833333333333332ybわり T0.020833333333333332yaに T0.020833333333333332yb残す T0.020833333333333332ybため T0.020833333333333332ybあと T0.020833333333333332>>vdtags<va11ybgoQva22yb振りc0.5yb返りc0.5va31yfsearchQva41ycbotQva51ymelasticsearchQva61yb画面Qva73ycdev R0.3333333333333333ya  R0.3333333333333333yicontainer R0.3333333333333333va83ycdev R0.3333333333333333ya  R0.3333333333333333yicontainer R0.3333333333333333va91ygwindowsQvb103ycdev R0.3333333333333333ya  R0.3333333333333333yicontainer R0.3333333333333333vb113ycdev R0.3333333333333333ya  R0.3333333333333333yicontainer R0.3333333333333333vb121yfpythonQvb133yebelin R0.3333333333333333ya  R0.3333333333333333yibuzzwords R0.3333333333333333vb142yb振りc0.5yb返りc0.5vb151yemusicQvb161yjopensearchQvb171yfluceneQvb181ymelasticsearchQvb191ydhugoQvb201ymelasticsearchQvb211ymelasticsearchQvb223yfberlin R0.3333333333333333ya  R0.3333333333333333yibuzzwords R0.3333333333333333vb231ydjavaQvb243yeazure R0.3333333333333333ya  R0.3333333333333333yfsearch R0.3333333333333333vb251yepaperQvb262yb振りc0.5yb返りc0.5vb271ydmiscQvb281ydmiscQvb291ydmiscQvb301yepaperQvb311yeMICESQvb323yfberlin R0.3333333333333333ya  R0.3333333333333333yibuzzwords R0.3333333333333333vb333yeazure R0.3333333333333333ya  R0.3333333333333333yfsearch R0.3333333333333333vb341ydmiscQvb351yc勉強会Qvb361yc勉強会Qvb371ymelasticsearchQvb381ydmiscQvb393yeazure R0.3333333333333333ya  R0.3333333333333333yfsearch R0.3333333333333333vb403ya2 R0.3333333333333333ydNand R0.3333333333333333yfTetris R0.3333333333333333vb411ydmiscQvb421ydmiscQvb431ydmiscQvb442yb振りc0.5yb返りc0.5vb451ymelasticsearchQvb461ydmiscQvb471ydmiscQvb481ygwindowsQvb491ygwindowsQvb501ydmiscQvb511ygLinderaQvb521yb検索Qvb531ydmiscQvb541ydRustQvb552yc100c0.5ycnlpc0.5vb562yc100c0.5ycnlpc0.5vb573yeazure R0.3333333333333333ya  R0.3333333333333333yfsearch R0.3333333333333333vb581yb検索Qvb591yb検索Qvb604ydrustc0.2ya-c0.4ycthec0.2ydbookc0.2vb613yfberlin R0.3333333333333333ya  R0.3333333333333333yibuzzwords R0.3333333333333333vb621yfluceneQvb631yfluceneQvb641yhkuromojiQvb654ydrustc0.2ya-c0.4ycthec0.2ydbookc0.2vb664ydrustc0.2ya-c0.4ycthec0.2ydbookc0.2vb672ya.c0.5ycnetc0.5vb683yeazure R0.3333333333333333ya  R0.3333333333333333yfsearch R0.3333333333333333vb693ygelastic R0.3333333333333333ya  R0.3333333333333333yestack R0.3333333333333333vb704ydrustc0.2ya-c0.4ycthec0.2ydbookc0.2vb712yc100c0.5ycnlpc0.5vb722yc100c0.5ycnlpc0.5vb732yc100c0.5ycnlpc0.5vb743yiworkplace R0.3333333333333333ya  R0.3333333333333333yfsearch R0.3333333333333333vb753yiworkplace R0.3333333333333333ya  R0.3333333333333333yfsearch R0.3333333333333333vb761ymelasticsearchQvb771ymelasticsearchQvb784ydrustc0.2ya-c0.4ycthec0.2ydbookc0.2vb792yc100c0.5ycnlpc0.5vb802yc100c0.5ycnlpc0.5vb814ydrustc0.2ya-c0.4ycthec0.2ydbookc0.2vb821ydmiscQvb834ydrustc0.2ya-c0.4ycthec0.2ydbookc0.2vb841ydmiscQvb854ydrustc0.2ya-c0.4ycthec0.2ydbookc0.2vb864yfvisualc0.2ya c0.4yfstudioc0.2ydcodec0.2vb874ydrustc0.2ya-c0.4ycthec0.2ydbookc0.2vb884yfvisualc0.2ya c0.4yfstudioc0.2ydcodec0.2vb891yb読書Qvb901ydmiscQvb911yb読書Qvb922yb買いc0.5ya物c0.5vb931ycブログQvb943yeazure R0.3333333333333333ya  R0.3333333333333333yfsearch R0.3333333333333333vb953yb検索 R0.3333333333333333ydシステム R0.3333333333333333yb探訪 R0.3333333333333333vb961ycゲームQvb971yb読書Qvb981yb転職Qvb991ycブログQvc1001ycブログQvc1011ycブログQvc1021ycブログQvc1031yioctopressQvc1042yb振りc0.5yb返りc0.5vc1051ydmiscQvc1061ydmiscQvc1071ydmiscQvc1081yioctopressQvc1091yb転職Qvc1101yfLuceneQvc1111ymelasticsearchQvc1121yc勉強会Qvc1131yb書籍Qvc1141yc勉強会Qvc1151yc勉強会Qvc1161yb検索Qvc1172yb振りc0.5yb返りc0.5vc1181ymelasticsearchQvc1191ymelasticsearchQvc1201ydmiscQvc1211yc勉強会Qvc1221yc勉強会Qvc1231yfpluginQvc1241yeスポンサーQvc1252yc100c0.5ycnlpc0.5vc1262yc100c0.5ycnlpc0.5vc1272yc100c0.5ycnlpc0.5vc1282yc100c0.5ycnlpc0.5vc1291yfpluginQvc1301yfpluginQvc1312yb振りc0.5yb返りc0.5vc1321ymelasticsearchQvc1331ymelasticsearchQvc1351ya本Qvc1361yc勉強会Qvc1372yb振りc0.5yb返りc0.5vc1381ymelasticsearchQvc1391ymelasticsearchQvc1401yfpluginQvc1411ydmiscQvc1421yc勉強会Qvc1431yc勉強会Qvc1441ya本Qvc1451yc勉強会Qvc1462yb振りc0.5yb返りc0.5vc1471ymelasticsearchQvc1481yhtimelionQvc1491yc勉強会Qvc1501yesenseQvc1511yfmarvelQvc1521ymelasticsearchQvc1531yfkibanaQvc1541yhlogstashQvc1551yhlogstashQvc1561ymelasticsearchQvc1571ymelasticsearchQvc1581ymelasticsearchQvc1591ymelasticsearchQvc1601yc勉強会Qvc1611ymelasticsearchQvc1621ymelasticsearchQvc1631ymelasticsearchQvc1641ymelasticsearchQvc1651ymelasticsearchQvc1663yefound R0.3333333333333333ya. R0.3333333333333333ybno R0.3333333333333333vc1671yc勉強会Qvc1681yc勉強会Qvc1691ymelasticsearchQvc1701yc勉強会Qvc1711ymelasticsearchQvc1731ymelasticsearchQvc1741yc勉強会Qvc1751ymelasticsearchQvc1761yc勉強会Qvc1771ymelasticsearchQvc1781yielasticonQvc1791yfshieldQvc1801ymelasticsearchQvc1812ya4c0.5yfkibanac0.5vc1821ymelasticsearchQvc1831yc勉強会Qvc1841yc勉強会Qvc1851ymelasticsearchQvc1861ymelasticsearchQvc1871ymelasticsearchQvc1882yb振りc0.5yb返りc0.5vc1891ymelasticsearchQvc1901yfmarvelQvc1911ymelasticsearchQvc1921ydjjugQvc1931yfcoffeeQvc1941yhlogstashQvc1951yhlogstashQvc1961ymelasticsearchQvc1971ymelasticsearchQvc1981ymelasticsearchQvc1991ymelasticsearchQvc2001yc勉強会Qvc2011ymelasticsearchQvc2021ymelasticsearchQvc2031yhsonatypeQvc2041ymElasticsearchQvc2051yc勉強会Qvc2061ya本Qvc2071ymElasticsearchQvc2081ya本Qvc2091yfpluginQvc2101ygreleaseQvc2111ygcuratorQvc2121yc勉強会Qvc2131yb転職Qvc2141yb転職Qvc2151ya本Qvc2161yc勉強会Qvc2171ymelasticsearchQvc2181ycAWSQvc2191ygスピリチュアルQvc2201yeオライリーQvc2211ymelasticsearchQvc2221yfpluginQvc2233ya2 R0.3333333333333333yfstream R0.3333333333333333ybes R0.3333333333333333vc2241yc勉強会Qvc2251yfpluginQvc2261yc勉強会Qvc2271yfpluginQvc2281yfpluginQvc2291ymelasticsearchQvc2301yc勉強会Qvc2311yftravelQvc2321yfpluginQvc2331ymelasticsearchQvc2341ymelasticsearchQvc2351yc勉強会Qvc2361yfmarvelQvc2371yc勉強会Qvc2381yfmarvelQvc2393yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc2401ygcuratorQvc2411ymelasticsearchQvc2422yb振りc0.5yb返りc0.5vc2431yhkuromojiQvc2441ydSolrQvc2451ymelasticsearchQvc2461ydSolrQvc2471ydSolrQvc2481yfpluginQvc2491yc勉強会Qvc2501ygNorikraQvc2511yhYokozunaQvc2521yfpluginQvc2531yfpluginQvc2541yjManifoldCFQvc2551yfpluginQvc2561yiwikipediaQvc2571yiwikipediaQvc2581yc勉強会Qvc2591yiwikipediaQvc2601ydSolrQvc2613yfXperia R0.3333333333333333ya  R0.3333333333333333yaZ R0.3333333333333333vc2621ydSolrQvc2631yjManifoldCFQvc2641yeオライリーQvc2651yhYokozunaQvc2661ydSolrQvc2671ydSolrQvc2681ydSolrQvc2691yfkibanaQvc2701ydSolrQvc2711ydSolrQvc2721ygfluentdQvc2731yc勉強会Qvc2741ydSolrQvc2751ycAWSQvc2763yhCloudera R0.3333333333333333ya  R0.3333333333333333yfSearch R0.3333333333333333vc2773yhCloudera R0.3333333333333333ya  R0.3333333333333333yfSearch R0.3333333333333333vc2781ygfluentdQvc2791ydmiscQvc2801ydmiscQvc2813yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc2821yb読書Qvc2831ydsolrQvc2841ydsolrQvc2851yc勉強会Qvc2861yc備忘録Qvc2871yc勉強会Qvc2881yc勉強会Qvc2891ymelasticsearchQvc2901yc勉強会Qvc2911yc備忘録Qvc2921yc勉強会Qvc2931yc勉強会Qvc2941yc勉強会Qvc2951yb読書Qvc2961yc備忘録Qvc2971ydJIRAQvc2981yc勉強会Qvc2991yc勉強会Qvc3001yc勉強会Qvc3011yc勉強会Qvc3023yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3031yc勉強会Qvc3041yc勉強会Qvc3051yc備忘録Qvc3061yc勉強会Qvc3071yc勉強会Qvc3081yc勉強会Qvc3091ydsolrQvc3101yc勉強会Qvc3113yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3121yc勉強会Qvc3143yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3151yfZipkinQvc3161yfZipkinQvc3171ydsolrQvc3181ycOSSQvc3193yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3203yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3213yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3221ydmiscQvc3231yc勉強会Qvc3241yc備忘録Qvc3253yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3261yb読書Qvc3271yc勉強会Qvc3281ydsolrQvc3291ydsolrQvc3301ydsolrQvc3311yc備忘録Qvc3321yc勉強会Qvc3333yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3343yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3353yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3361yc備忘録Qvc3371yc勉強会Qvc3381yb読書Qvc3391yeScalaQvc3401yc勉強会Qvc3411yb読書Qvc3421yb読書Qvc3431yc勉強会Qvc3443yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3451yc勉強会Qvc3461yc勉強会Qvc3471yc備忘録Qvc3481yc勉強会Qvc3491yc勉強会Qvc3501yc勉強会Qvc3513yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3521ydmiscQvc3531ydmiscQvc3541yc勉強会Qvc3553yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3561yc勉強会Qvc3581yc備忘録Qvc3591yb読書Qvc3601yc勉強会Qvc3613yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3621yc勉強会Qvc3631ydmiscQvc3641ydsolrQvc3651ydmiscQvc3663yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3673yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3681yc備忘録Qvc3693yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3711yc備忘録Qvc3721ydsolrQvc3731ydsolrQvc3741ydsolrQvc3751yfhadoopQvc3761yb読書Qvc3771ydsolrQvc3781yb読書Qvc3791yc勉強会Qvc3801yb読書Qvc3811yb読書Qvc3821yc備忘録Qvc3833yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3843yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3853yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3861yc備忘録Qvc3871yc備忘録Qvc3881yc備忘録Qvc3891yc勉強会Qvc3901ye形態素解析Qvc3913yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3923yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3931ydsolrQvc3941yfhadoopQvc3953yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3963yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3973yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3983yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc3993yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc4003yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc4013yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc4023yflucene R0.3333333333333333ya- R0.3333333333333333yegosen R0.3333333333333333vc4031ydmiscQ>v PtokenOccurrences4vbid<ya0Uya1Qya2Kya3Nya4Qya5Lya6Nya7Qya8Pya9Jyb13Qyb15Qyb25Qyb30Qyb32Qyb35Ryb40Qyb42Qyb50Qyb55Ryb57Qyb61Ryb62Qyb63Qyb66Ryb68Qyb79Qyb84Qyb86Qyb92Ryc115Qyc120Qyc121Qyc122Qyc127Ryc130Qyc133Qyc135Qyc140Qyc145Ryc150Qyc152Qyc153Qyc160Qyc177Ryc181Qyc188Qyc198Qyc199Qyc208Qyc219Ryc220Qyc226Qyc227Qyc230Ryc231Qyc232Qyc234Qyc240Ryc242Qyc252Qyc257Qyc258Qyc264Qyc265Ryc289Qyc292Qyc293Qyc298Qyc299Qyc301Qyc302Qyc303Qyc307Qyc309Qyc314Qyc318Qyc321Qyc322Qyc323Qyc333Qyc349Qyc350Qyc351Ryc353Qyc356Qyc362Qyc365Qyc373Qyc386Qyc388Qyc389Ryc399Ryc400Qyc403Qyc405Qyc407Ryc409Qyc410Qyc414Qyc415Ryc417Qyc418Qyc421Qyc423Qyc426Qyc431Qyc432Qyc433Qyc435Qyc443Qyc444Ryc455Qyc459Tyc463Qyc464Qyc465Ryc466Ryc470Qyc475Ryc479Ryc481Qyc482Syc491Qyc493Qyc501Qyc505Ryc508Qyc509Qyc512Qyc517Qyc521Ryc522Qyc531Qyc532Qyc535Qyc536Qyc538Qyc552Qyc561Ryc562Qyc563Qyc565Qyc579Qyc581Qyc582Qyc583Qyc586Ryc590Qyc595Qyc597Qyc601Qyc602Qyc604Ryc605Ryc607Qyc616Qyc617Ryc622Qyc623Ryc625Qyc626Qyc628Qyc634Qyc637Qyc638Qyc641Ryc647Ryc656Qyc657Qyc664Qyc671Qyc687Qyc703Qyc712Qyc715Qyc716Qyc720Qyc721Qyc722Ryc724Qyc730Qyc745Qyc750Qyc754Qyc755Qyc759Qyc760Qyc765Ryc774Qyc779Qyc780Qyc782Qyc785Qyc788Qyc791Qyc794Qyc799Qyc801Ryc804Ryc813Ryc818Qyc822Qyc823Ryc825Qyc827Ryc830Qyc832Qyc835Qyc840Qyc843Qyc844Qyc845Qyc847Qyc857Qyc860Qyc861Qyc865Qyc866Ryc869Qyc875Qyc880Qyc885Qyc886Ryc888Syc889Qyc891Qyc892Qyc895Qyc897Qyc900Qyc906Qyc907Qyc912Qyc913Qyc914Qyc915Qyc916Qyc917Qyc927Qyc931Qyc932Qyc934Qyc935Qyc936Qyc938Qyc939Qyc941Qyc943Qyc945Qyc946Qyc949Qyc950Qyc953Ryc956Ryc962Qyc965Qyc966Qyc970Syc971Qyc979Qyc980Qyc984Qyc986Qyc990Qyc994Qyc997Qyc999Qyd1039Qyd1294Qyd1298Qyd1338Qyd1373Qyd1441Qyd1446Qyd1726Ryd1739Qyd1790Qyd1821Qyd1826Qyd1841Qyd1863Qyd1934Qyd1973Qyd2019Qyd2023Qyd2271Qyd2523Qyd2561Qyd2619Qyd2824Qyd2845Qyd2915Qyd3211Qyd3270Qyd3384Qyd3737Qyd3811Qyd3829Qyd3967Qyd3979Qyd4002Qyd4389Qyd4502Qyd4555Qyd4581Qyd4796Qyd4851Qyd4858Qyd4924Qyd5010Qyd5063Qyd5132Qyd5157Qyd5219Qyd5339Qyd5412Qyd5433Qyd5495Qyd5595Qyd5742Qyd5756Qyd5758Qyd5777Qyd5824Qyd5955Qyd5988Qyd6193Qyd6324Qyd6357Qyd6425Qyd6458Qyd6490Qyd6567Qyd6639Qyd6670Qyd6761Qyd6833Qyd6978Qyd7043Qyd7198Qyd7199Qyd7206Qyd7396Qyd7462Qyd7664Qyd7669Qyd7730Qyd7737Qyd7787Qyd7853Qyd7884Qyd7906Qyd7998Qyd8077Qyd8194Qyd8208Qyd8239Qyd8340Qyd8412Qyd8534Qyd8608Qyd8773Qyd8883Qyd8964Qyd9066Qyd9274Qyd9358Qyd9425Ryd9504Qyd9587Qyd9609Qyd9623Qyd9679Qyd9719Qyd9767Qyd9856Qyd9927Qye18218Qye18500Qye34850Qye37912Qye38128Qye39905Qye74933Qye82391Qye83454Qye90451Qyf552660Qyg3227411Qyh21590549Qyh25492340Qyh45353291Qyh61173291Qyh65124517Qyh85653399Qyh89118022Qyh90061486Qyi431816573Qyec4dbaQyc56fRybdb^ybcdUyc31bSyadzyd92dcQyaeFydd869QybfbYyd48cbQydacbaQyd03dcQym639481524ee80Qyd476eQyc17bQyafMy W854414033d5cec1470774eeQyd516aQybaa]yc07fQycfaaQyab{ye38bebQybcfUyactyb7fQyc78bQyc02cQyg09602baQyk140132d26a2Qyb8fQye58cbeQybce_yc85cQyg22569afQybde[ybf9Qybee]ycbdbSybabZyo5583eeb6eabbd51Qyc62cQyf52779aQybed[yh431877ceQyd11feQycfeeQyc77fQyd26ceQyd086bQybfdYyf77021aQyaay `a12474027c91fad5a861aa9919817d72Qye698cfQyccbdQy W796161d82c9ac438ebab5d2Qy `9335522f4c8dbc7256a42a091e6e00bcQybdfUyc30dQyg810068eQy T4656498e5972c6de7e3dQyc67cQybaeVyd89beQybfa[yd66dbQyc40dQye9693aQye77deeQye5785bQybdcYyg61ccffdQy `73279888a8fe482c836fb19ca23318dcQybecUyc88cQye4976fQybcaZyd20faQyd169eQyd167aQydcebfQyc64aSyg6329ecbQybeaYybbbTyc47dSyc70fRyc94bRyk4510813f36aQyd779eQybbcVyceedQyc97fRyc19cQyc41eQydf56cQy \19442484b3e4f47875b58b3f72b2Qyf5eebdfQyd85fdQy P301194bfeeee4377Qyc7ccRy ]21814165879f72529e91682ece5c6Qy `0645bdb1cdf88ec74288d503eb71839cQyd104bQyc17aQybbfVyl236659680493Qyd218eQyc36dRy W5945ece02fdc55d6cbcbc38Qyef0fdcQy W18514362a4e52376a6fecbaQyc26eQye44dfdQyc16aQye2963dQyc18eRyf99806cQyd26fdQy `35200cbf0b5b45d7f5f0b343cb18868bQyc10aQyd69bdQyc03dQy T2632722300194f01e93dQyc59bQyc60eQycbbfQyf72643dQyd22adQyf43caefQyc41cQyf74826eQyi82088739dQyef4baaQyd43ccQyc83bQyc99aQycdbdQydf41dQycfdeQye94cbdQycbbdRyg28808dcQyc080Rye3190cQyd45acQyc91aQydecedQyc95eQyc83dQyc81dQycfcbSyd0105Qyl247784b9d930Qyd931bQycebdSyebfaebQycdcfQyc61bQye4543eQy R67fccabee27a6e99cdQygd95522cQy Y691013bfe66dd46ded85a98edQyc4adQyc37fSycbcdQyf17abebQyi96106314eQy Y2367372c3199c66a6420faf89Qyba5Qybb2Ryc10dQyh888217abQyceccQybc6SybfcWyd88bdQyc57aSye57ddfQyc22eTybebXycbefQyda46cQyc03aRyd26bcQyd0096QybfeVyc83aQygb16bdddQy Q4136446bebe7ffbc7Qyd188cQy T6752dfce5a0235354070Qyc37dQycfaeQyh011687ebQyc89eRy `c377351433a941a927aab543931f6026Qyf15932aQyeacfacQyl27766eadc9e2Qybc4Tyc96dQyc02dRyn03668caaecbc57Qydd08aQycfdcQyc040QyebbbddQyc81cQyg296318cQye827deQycbcbQye44cafQyh35896c1fQyb3cSyc33eRyc43cQyf03996cQyg1966beeQyg38866ceQyff5effdQydcaecQyc11aRyf61827eQyf80739aQyi6065960ebQyc9daQyf31310bQy R8952efd1be1881e651Qyd208aQyc072Qyd86caQybe5QybcbXyf14984aQyc66dRybffWybda[yc8a1Qyf94cfccQyc82aRy P96813587fe3a6049Qyde74dQy \071363645a588f858b35231128c4Qy `163beeae9620c1a6a46a38aa7ebd9663Qyd36ddQyf94159eQyf60076cQyl6098086e255fQyf21982fQyd43bcQyf22efefQyc22bRyc48cQyg306cecbQy Y32320ead508346ad8fed3394dQyb1eQyd16fdQybbdXyh03865b60Qyg09155bfQyf93847bQybadWye78ccaQydc098Qyi0901979bdQyi345200f90Qyb2cQy Y8797ace2fb37402ea6a09d126Qyd44dbRydfefcQyd97cdQyc28dQyc55dQyb4dSyc71dRyc23cRyd85fbQybafXyc20eQybbeYyd49eaQye5816eQycdaaRyf15357bQye83daaQyf97692cQydf488Qyc62dRy W39194824861a134567cadb8Qyb9aQydbabbQyd51dcQyf75bdaaQyc19dQy ^9580308938069159c5afc55b2f3b96Qye4fbdcQyg37781dcQybddVyc86fQyc61dRyb04Ryd6fbfQye89cecQyh28811a94Qyb8dQy \3760395e8e0eb40e335b22750b68Qyb3fQyd71eeQycdafQyd42bcQye7fdedQyd0345QyceeaRyba7Qyf85fcadQyc18cQyd10deQyc48bQy Z9805919736382ffea5a9554c02Qybc9QycabaQyf54475cQyc20bRyb6fQyd47cbQycadbQybccVyc44fQydd710Qyc073Qyd71cfQyd83aeQyc45eQycedeQybefUye9710cQycecfSycbccQy `c3053579ae25e2fb9b967076a06373afQyb7bQye43fceQyd14deRyc61cRyd819aQyc90fQy ]9355781403b92e844de8568863ae8Qyf7fcfaaQye34dbdQyc19eQyefcfdaQydc61aQycbdaRy V1667498626ae52ad0362e0Qyfd9018fQyc94aQyc91eQyc92bQyc99cSyc80aQye6532eQyc92dQyc07aQyd018bQyd00ddQyc17cRyea65bdQyc31dQycdabQy P41712823a5d6002bQyd77beQycfcdQyc23aRyd35aaQyd09dbQycaeeQyb1aRyd0040Qyf06eacdQyg0526476Qyc80cQycfcaQy Y02ebfecc7a931dad1ec38466eQybf3Ry \819656f68b87a91c53afbd441fecQyd1abcQyc67fSyd05fdQyc60fQyd1bbfQy V096960e13d8578fa544536Qybc2Qydd39fQyd69fcQycefbQyd78daQyc91cSyf82809aQyc97aQyc26dSyc11bQyc28bRyc34dQy Q3606427f835bd3ddfQygd8041aeQy Y308961666b15aa1e57b0f9f35Qydd96fQyc80fQy Y23543850a2ee9fff8cd2cc53fQyd538eQye38fbcQyd78cdQyc61eQyi8141ddcc1Qy `b27bdabd8e1a6b7dc06886867331ceb3Qyb6cQyg1519fbfQyh910197ccQyd62cbQyd0266Qye7027eQybbaUye45dddQy Y3042dad59a12e5937644f7246Qyc3fdQy ]9052870778e14ab4a5acbc8c24af4Qybd3Qyc10eQyg9340deaQyd10aeQyc016Qye19fffQyecfaebQyc47fQyc04dQyecbaacQyc08bRyc15eQyhbffdcb5bQyc8ccQyd19cdQydbeafQye1642fQyc52aRy `d791eaca9375ca1b36a987af22ee71ddQy `e6684944c37dbdd4c08d978af9e47bedQycbbeQyddeecQyc11dSyg348051bQyeabdafQyda673Qyf62477eQye01abcQyk75465416b86Qyc7b6Qyc59aQycabeQyd22daQyc03bQye4afcbQyc20dQye95bcdQycbdeRyb7cQyc21bSyn5153268e0cc1c1QycdfaQyd61ceQyc39fQy ^0486610d8a02cea245c13c85b6de27Qydc20dQyf71627eQyc66aRyc044Qyf21780fQyb4fRyc88fRydeebeQy V44285ded812939553ef94cQyc29bQydadcdQye80cedQyo1612128b3ca95a9Qyc16fSy ]1046144ad9ee7bb96214ba7ae7516Qyd002dQyc74dQyc19bQyd43ffQyl2446665e2fe5Qy `550becdd08d00fb1e7fd00c2adc3d3d6Qyha62186eaQyc087QyddfccQyd167eQyd49ceQyg521991eQyd993eQyc58fQyg132740bQyd06eeQydc56aQyd76efQyd87beQyc32bRye81facQyc3fcQyd83faQy T55885067fee629287e8aQyb4bSyh768585daQy `c54909ecf4fb3e9afeea36200fe95dceQygd819ceaQye5197eQye8673dQyi16659a5eaQyb1bRy ^56132638912a1ca54fcf7cd38b8e23Qyc2eaQyd86aeQyi5093670dfQye82efaQybacYy `5912529cfd6ce14c5ede5c6c83dae7e8Qy `15700442e957951307bbcec5fff8643dQyd018eQyc32aRy Y8010960eb17e368a6fdd5a51bQyde159Qyc35dQyc46eQyf03072aQyi54780edcbQyc64cQygfcdecdbQye3797eQydaaaaQye59adcQyc4ccQyd08caQye51ecfQyg963035fQyc039Rye6194cQyc61fQy W33182579cd3edd0ac6c7c44Qyc0deQydedbfQyg506143cQyc12eQyc94cQy `744554499cb7880086fbd9b1f080e7e1Qyb5aRy U186925e5de978c5f72062Qyc73bQycfceRydcabbQyd01cdQyc21dQyd100cQye69beaQyc02aQyn4540ecaa37d0e3Qyg809925eQy U0456231c374b09cbe4a90Qyh815273cdQy U1948795e26af2f3f8a30fQydf887QydaabfQycbfbRyf39698fQyc9ccQy T1405cddcdeb4487c59feQyc18bQy X871950ebc36c415a53630477QydddabQyf55188aQy V5998989255253e15ccc1f6Qyc75dQyi9268739feQycfebQyc22dQyg1411afbQyg787810dQyl68210e6fad4fQye615dbQyc24fQyc19aQyceafRyc18dQyedceedQyf8d7cafQyc84bQye51ccaQyf27291cQyccfcQy `7249710187cc2d983709e044dbc78d9dQyg563864aQyg949924cQyg505985aQyk168191dcb84Qyg24357feQyf82fdfcQye8134aQyg19ecbaaQyc12fQyeebcffQyh79534a52QyccedQyc13bQyc64dSyd0127Qyd13bbQye4677aQyef2cbeQyd07bfQyc16dQye5860bQydedbcQyceeeRyc49aQyh570599cfQyc55cQyd649fQycdddQyg3884abcQyf043664Qyb5bRye97eadQycbadRyc57bQyc43aQyf89149aQyf997accQyc01bRyc54fRyc77aQye9133fQyd1fedQyc99bRyd50ebQyd92cbQyg1644e8aQye5badfQye61ecbQyecfaddQyg58712faQyd10ccQye9509bQyc59eQyf029775Qy `b36abffbe5d6a0de73a9968604a1a3f9Qy ^9649eca3dfbd356527ffc88f1dcb94Qyd7deaQyf52758bQy Q10cbceb08c81d1760QycbceQyc39aQyc75eQye2713fQyh687271a1Qy `e5390751969ab21df280b7591854b89fQyf05330cQye3703dQye96cfeQyc33fQyb4aRyc42cQyd29dbQy P268010bbebf4f579Qyc1bcQyf36080bQy W2493aab78c26e4f2152542cQyc2deQye67fcaQy T31500621ecd6d3917a07Qyb0aQyg8183cedQyf41286eQyc54eQyd21daQyd68dfQyd937aQyf32cabaQyc88aRyb2aQyc50dQyf07330fQyd0243Qyc79dQydd266Qyc67bQyc20cQyf01055bQye223bcQy ^2709406a9bb19e8d83a78f81e36244Qyf998edaQyd07fdQym251138384a0b9Qyf853cacQyc90bQyhdcdbbfdeQy `4616fbea6a6dbc1074bc3f1016bbc73bQyhf15702aeQye55badQyg42182cfQyf18724dQyc77dRyfafaebdQy T7193badc746d52b4173fQydbdeaQyg64cdfccQyc65eRycfddQyccccQyg74705adQyd98bbQyd60adQyebadafQyb0cQy Y1069578551d0e3c7d9275f16bQybe3Qyh146469edQy U4318eaa2ffbca3510c054Qyc21aQye9330dQyeebadeQyc62bQyf40abeaQyc87aQyd64bdQycfadQyf69458bQyf916bdaQyd59bcQye7621dQyj040572a3c0Qyc5bbQy [8322cdbda7a21e4aecbe04462b7Qyga578acfQyd95feQye7208fQyd706cQyc033Qye4483bQyc062Qye0236aQyd72dfQyf05560dQyn94208817b83468Qyd91feQyc03fQyf85cedeQyc62fRy Z398056eef1cf6caa90786b340aQyg2824befQy Y72110575c78aeb979170212b8Qyge396cbfQyd94eeQyc43dQyf50562bQyg09417cdQye2348aQydaabeQyc76aQye21fdaQydeddbQyf95426bQy `299abcee56b05b312ed5700f686f79b8Qyg670744bQyh945088deQy Q05866864f7d57bee7Qy `c1241374502f200cf9fc49c8d6fb5822Qy `d51032bef3e7117a94336fea18a3fad7Qyi65453a1aeQyh403679bdQyf47398aQyg04205caQycabcQyg61831fdQyc06bQyh402875d2Qye386dcQye3965fQycfbeQyc29cRycdfbQyc9adQyc72cQyg21741bdQycdfcQydf55dQy \33371dcff207fd7d201128df2ea3Qyd229bQy Y784707b1d2c702fbeba080e86Qyfc98cbcQyc95cRye0526eQygc6107ffQyc57eQyc96aQyc019Qyd00adQygf6debedQyc20aQy T308352b7a881add7e356Qyc15fQyg501351dQycffdQyf73985aQyc50fRyc89dQy Z51edead39c0e439073986043fbQyc10cQyd70deQye25ccbQydbbbbQye78cedQydc18bQye12fffQyd24dcQyc87eQyc36eQyc90dQycebbQyba0Qyda00cQy Z23556fcc5dbfb7b7f43fbbb61dQy `d9560caeb797b302191f667b4264da40Qyfa2012aQyccdbQyo69afdbadc1e76b6Qyf13684dQye16fddQyc07dQyd0584Qyf29265aQyd270eQyc66fQyd43abQy P52735bbbe6ba65b0Qyda106Qy U277538367f9c8140e3a75Qyd9dcaQydefedQy Q03fbaddfc0fab7c76Qybb5QycdbfQye4690dQye0302eQy T8604342a925b2dc60737Qyc76eQy Y44931bfefab991be3dd7a08b7Qy `e1870dde155be1a375f155dd1f7ead13Qybd2Qy ]805472f79f0b558f75b90b5e7b4eeQyc79eSyc36aQy R1221897f5837c84affQye5931fQyeacdacQy S724742c4ee0960d8d40Qyi3931327edQy S1568868c5ab8e839148Qyc01eQyh330045feQycaffQy Y582642d9cbe500f018afab341Qydb875Qyc24dQydfddaQyc82bQydbbfbQyc75aQyc59dQy Q76672d3de4dc9a8edQyd60ecQyd46beQye1877fQyg6920edcQyf50557bQyccbaQyd146eQyc40cRyg36eeceaQyj822028dd9eQyda98dQyd42beQyc060Qyf5080ecQy Z80454654d990d9c07d33d35d1cQyc26cQy ]47355cbe966a94826cbe2fbf2b355Qyf33919eQyh866426ceQyc06fQye19bbfQyf78292dQyfeafbdfQyd57ccQydbbbeQyg58646ceQyf93015dQydd12cQyd68beQycfdaQyg5493b4dQy `f45069216cd934b80ce882c9a2f2a08aQyc1feQyc14eQyc02bQydddccQy `e30258aeb8475d4c27f7935945671856Qye90bceQy U5743226af94c1efaaa4a7Qyh494557dbQy X52824555864d1106278cd1f0Qy ]10764f0ccce42d5be8cfeac36b446QyddbccQy W15afefef853a08a0804ba3aQyi4726484beQy T418849e1f4200ade9535Qyf97311cQyf24809fQy R103575d8a7fee19680Qyd286aQy W373398d7d2c93862c5f6661Qyc99fQyf22485dQyd0872Qyl2529599c8440Qyd36ffQye37cedQyc95aRyddaacQyc1caQyc04eQyd12feQyd61fdQyc73dQycefaRyf52675bQyc35aQyd11eeQyd97bcQyh465087cfQycbdcQybf5Qydf28fQyd42adQydcbeaQyd54ffQyc60dQyf82160dQye6093eQydb051Qy Z352847c06e748b345e8ed0738bQy \86812812dab8d39db9aaefe94a78Qy `322264a17ef7182eb1475bd2eaebc2ebQyf20110cQye8304bQyd992aQyc00cQyf30242bQy S6217243f3c387ea18b7Qyb4cQyc67eRyefdeefQyc50bQydfdccQyh32cdcee2Qye30eebQyc083QydacecQy R8460150068ba0c6743Qyd898dQyc25aQyg462405eQyde01eQyc01dQyf18582cQyc69eQyd111aQyb7eQy ^23419e4fc69b5b533815681c9bb1a9Qyc98cQyg640616fQyd34baQye922ccQyd71fdQycdacQy `43501cdf0de25278a208cbb9aad80012Qyf89abaaQyd21cfQye4744eQyg7604edfQy S96120606c8dda06458fQy `775894425f5a7436f56fc5a3b4a2cfaaQyb8aQyc29fQyebebfeQye8008dQyc56bQyc7faQy [0877831b4c924438396760f1841Qyc68aQyc34cQyd42abQyc33cRyc9acQyc94eQyd60dcQyc30aQyc023Qyf027364QycdccQyd24dfQyf32287eQyd89eeQyd8accQyd78beQyc63eQyc27eQyd53ecQyc90cQyb9fQyc09aQym2981057642b69Qyed13aaQyc56eQyd27feQyd71efQyd40ffQyc093QydecdfQye9ccdaQyeebcdfQyfeacbbaQyc69fQyc90aQyn3086543790541cQyd277fQye2177eQyg62680eaQye0158fQyf48516eQyf57684cQyn22adccac34be92Qye216dbQyg319052bQyg68862cbQyccbfQy X8187985725963b8bfc67004dQyd0dcbQy X17794bbca56b6cdb9e20b932QyeffdbdQyc28cQy R63976e9eec38cab0f5Qy ^734259dfb9addebe2b226d96b4f744Qyc78fQyc002QyedfeecQy ]418764dca70aebfc965899a3fa7e5Qyf66950bQyd22ddQycdfeQydc92cQyc12aQyd28faQycaabRyl60865046ff05Qyc12dQyc33aQyebbbcaQyccbcQyfd77cdbQycaeaQyc58eRyd904bQyi07170a0ceQye7491eQyefecceQycbedQycfccQy R23639057435ac8756aQyc56dQy ]5711303378bd333ddb611a53ece94Qyfc7937bQyg96191dcQyd31dbQy `06731164684f90f33ce4017eca9d8ec1Qy `f8327953a0f0b80011b939111807999aQyb8bQyf76101dQy X185700a8efed148d8722d926Qyc16bQy [9445539e9274282a612dea354c2QycaaaQy U429863f89da313fffed97Qyd116cQydbefaQyd51ceQyf96604cQyc95bQycddbQye30fddQycedfQyd10ebRyc05cQyd57ebQyg850036cQyd627aQyd45ddQy V07150343c81d856855590eQye966feQyf86121fQyc95fQyb4eQydfecaQy P486653fea1d0e39cQyf16213dQyf24273dQyg22332cdQyd01ceQyfa2679aQy P2645809ed92ce138Qyd83fbQy Q338132d23b9112805Qyh673436acQye41ebcQyc79aQyf10ebcfQyd88dcQy `a4462529ab493676987d946019a14945Qybf7Qyd85afQye2623dQyecbdddQy ^573488dec311655890a205aad4fb65Qy `7164823f504286e3a762ee612ff0a988Qyc049QyebabcfQyd584bQyh362098fcQyd57deQyfc6696aQy V7498efb66f5ba3a8b35d08Qyd16faQydaefeQyebaefdQyb6eQyd0818Qyd58ffQyc50cQyc037Qyd0ebeQyf78077cQyg48410cfQyfbccdffQy `924727b6f380cf3cdfe5650163e92054Qyc48dQyc68bQyc28fQyfbfebadQyg454658fQyd86ecQy T9790262e14f953bbadcbQyh107510acQyf2412aaQybd9Qye6630aQyc84eQyj5765103d2dQyb7aQyf31685eQyd88daQyd14cfQye75aecQyceadQye7101dQyc94dQyc28aQyc14aQyg294550cQy T9760aec57ba29682a750Qyb5dQye70edbQyc076QyccaeQybb9Qyd73faQy Q66891554b66b2cdedQyf34780fQye0374bQy [82817c0fb24e591b9a89a82f736Qy `09677934e13a5d728f00c6ed7c8870a9Qy `7052598d2355984237d126afea2f6e88Qy `927612b57ba01ca878b2d7edce52a563Qy `97402287d8c6c03f0b63848e17e9d944Qyf31128aQyd54daQyd49efQycfabQyd37cfQyc41bQyg811063bQyc37bQydeaadQyfaacebfQyd48ecQy `73262345214f9b7794f2cc4a612b15e8Qyg9baedcdQy Y033169611a42c3cfd58b3ae03Qyef23caQyc066Qyd65ffQy P73579aaaf5d7ce36Qyh608108beQyc2f1Qy [795216d5bafa33a810af3421942Qyd0aeaQyc06dQyf44878bQycefeQyc090Qybc0Qyd41ccQyc97eQyc7edQyd77ebQyceffQyc86bQyi40721f7caQy R651887aac4eb17f9f0Qy Z9668608a39333fa90cf462657eQydc70bQyd78fdQyedffcdQy P38322355e9c2471eQy `229975f1e84b5088e819cd5f2dc43080QycdadQym92641dadb5de7Qyd49baQyg23148dbQyeeffdcQyf5876eaQyef6dffQy [70097776e24c2a7c9c0f2514f79Qyg991285eQye3295bQycdcdQyc43bQyg61066efQym8656477b226beQydeeefQye60efeQy W889349870426d10edc694beQyc046Qyg0481dbdQye4003dQy `b2621497b3313c97855ed951f0d9b291Qyi42144a7deQydcfeaQyc62aQyd0785Qyc77cQyf74608eQyd85baQycdbbQyf69248bQ>vetitle<ya0oya1wya2dya3Xya4Xya5Zya6Xya7Wya8Sya9Qyb10Qyb11Qyb12Ryb19Qyb32Qyb90Qyd2011Syd2012Wyd2013Zyd2014Qyd2015Tyd2016Qyd2017Qyd2018Qyd2019Qyd2020Zyd2021Ryd2022Qyd2023Qyd4096Qyd4897QyfkagomeQya-QycbotQyaの}yiユーザーサービス化Qyb今年Ryb振り]yb返り]yaとFyb来年]yb抱負]ya（^ya）_yeOramaQycというWyb検索_ydエンジンQyaでlycブログTyaをkyb作っTyaてvyaみRyaたdybGoQyeSlackRycボットQya話Uyd機械学習QycによるQyeランキングQyb改善RycガイドQyd読みましUyfsearchQybUITyiSearchkitQyd検索画面QybVSSya uydCodeUycDevTyiContainerTya(`ydコンテナQya名Qyb指定Sya)`ygブログ記述環境QycとしてRycWSLQykディストリビューションQyd環境移行QyfdockerQygcomposeQya.}ycymlQyb対応Yyb導入SybまだRyb途中RycpreQyfcommitQydvenvQygPyCharmQyb困っRyaなXya？]yaも\yeオンラインUyfBerlinUyiBuzzwordsTyaにQyb参加nyaし_yc仕事中QycBGMQyb環境XymElasticsearchaygアーキテクチャRyiStatelessQya/PyjServerlessQycローマQyc字入力QybゆれQyb読みVy \JapaneseCompletionAnalyzerそのQyd日本語用QyiオートコンプリートRybためSyhAnalyzerSydHugoTyfアップデートRyfQuerqyRyb調査RybそのUya：Qya１Syc新しいSydJavaUyfクライアントRykインデックスエイリアスQyeAzureZyiCognitiveXyfSearchRyc新機能SygExtremeQyeMultiQyelabelQyhLearningQycforUyhSemanticRyhMatchingQybinTygProductQyb論文Ryb読んWyaだSye2021年QybかっQyc良かっQybものRyeIndexRyfSchemaQydJSONRycCSVQya見QybたくQybなるSycDIYXyeキーボードWyjコントローラーラックQyfDomainQyhSpecificQykPretrainingQyhVerticalQya:RydCaseQyeStudyQybonQyjBiomedicalQyjLiteratureQyeMICESQyb出張Sya、]yb試しRygLunakeyQydMiniSyb組みSyb立てSycBLESya+WydLPMESydIO化しRya#IydスライドRyb作成VydMarpQybしてVyd検索技術Qyc関するWyb情報Tyb交換Ryb目的QyaがPydできましQya！ZyfOData式Qyc日本語SyeNGramQydフレーズQyb自宅Syb作業Syb02SyaやSyeサジェストQybみるSya「TyjコンピュータシステムQyb理論Qyb実装Rya」Tyb始めSydNandQyfTetrisQyeSofleQybv2SyeCorneSyeLightRybIOQybPCQycしましVyhTemplateQybV2QyiChocolateQygWindowsRyaへYyb移行Tycお試しQya中RyeDozenQygLinderaQycFSTQyoDoubleArrayTrieQyb変更Syd検索対象QycデータXyfデータソースQydシステムWyb妄想Syb09RygmeteredQydクレートQyb紹介^ye第4章終了Qyd言語処理[yd100本[ycノック[ye第3章終了QyiTerraformQyeクラスターQyb起動Syb構成RybするSycパーツQyb特徴Qyb機能Rydについて]ydRust]yctheYydbookXya第Qyc15章QyjluceneutilRyb性能QycテストRyhkuromojiRyb追加TyeマニアックQycツールRyfセットアップWye日本語向けQyb違いQyc13章Qyc10章QyeリクエストQydロギングQyiMicrosoftQyeBuildQyiCogniriveQyeセッションRyb見たQybメモUygElastic\yeStackVydリリースiyaさSyaれSyb9章Qyc第2章Rybから^ybまでWyc第1章Uyb08QyiWorkplaceRyb触っTyfインストールQyb辞書Wyb更新Syc注意点TyhKuromojiYydカスタムRyfインデックスTyb設定Syb8章Qyb03Ryb06Ryb再びQyb6章QycCLIRydコマンドSyb出力RydラティスQyb5章Qyb4章SygAnalyzeVycAPIVyfVisualRyfStudioRykクライアントプラグインQydBookQyeプラグイン]yfClientQyb実践Syb入門Zyb3章Ryc終わっQygpicocliQygGraalVMQybでるTycところQye2019年Ryb買っQycよかっQygブログ移行日記UyeJugem}yb探訪QybたいQya=Rya>QydやりましQyfボードゲームQyaはZydじめましSyfフリーランスQya仮Ryd検索機能QygAlgoliaQyc微調整QycテーマRyb合わQyaせQyhMarkdownQydファイルRyb変換QyiOctopressSyc移行中QyemacOSQyb標準QyeターミナルQyiウィンドウグループQyb便利QyihomeshickQyczshQyfDockerQydイメージQya化Qyb退職RycしますQyfApacheUyfLucene^yfUniDicRycビルドRycパッチQygBonfireQydDataQya&QygScienceQybましDydNEXTQydSTEPQyd頂きましQyc勉強会^yb受付Qyb自作QycアプリQydHTMLQyi勉強会運営座談会っQybやっUykEngineeringQydTechSydTalkQyg検索技術勉強会Qyb運営QycみましTya。Dyb入っQybくるQycちょっRye2018年Ryd新規導入Qye長期出張用QydアイテムQydいくつかQyd第25回Qy PElasticsearch勉強会Pyb開催UydJJUGUygナイトセミナーRyd話しましQyfKibanaVyb方法Vyb3回QygカンファレンスQyb探しQya方RycCfPQyeスポンサーQyb応募Qyd開催期間QybなどRyb05Qyb04Qyb00Qyb2回Qyb1回Rye2017年QyhSwiftypeQydジョインQyh分析基盤構築入門Qyb一部Qyb執筆Ryf検索座談会っQye2016年Qyf便利機能紹介QygNEologdQyb品詞Qyb単語Qyb抜きQyb出すQyfIngestQyfPluginQyb書いQyoelasticsearchjpRybよくQya物Qyc壊れるQya年Qyd第16回Qyd第15回Qyf自然言語処理Qyb基本Qyb技術Qyd第14回Qye2015年QyhTimelionQyfAdventQyhCalendarQyc1日目Syd第13回RyeSenseRyb歴史QydbetaTyd日本語訳ayfShieldRygWatcherQyfMarvelSybGAQyhLogstashVygReleaseQya,QybweQydhaveQyiunpluggedQydにおけるQyfネットワークQyfDeleteQybbyQyeQueryQyd第11回RycおよびYyb大阪Qyb京都QygMappingQyeすばらしいQyhリファクタリングQyb間近QybさらQyb進化QyeFoundQylJustTechTalkQye形態素解析QybあれQybこれQya@UyhジャストシステムQyfHatenaQyhEngineerQygSeminarQyeTokyoVyjhatenatechQyd第10回Ryb使っRya再QygdiscussQygelasticQybcoQycにぜひQyc第9回Ryc名古屋RymelasticsearchPyielasticonQyc参加中QyfセキュリティQyb向けQydCoreRyfトレーニングQybますTyc第8回QyfGroovyQyeスクリプトQykダイナミックスクリプトQybなしQyb実行Rya　VyeCROSSTycきまし^yecrossRyb0系QyeIssueRyb簡単QyhコーヒーブレイクQyfエコシステムQydBetaRye2014年QylインデックステンプレートQyb利用UyfアクセスログQyeインポートQyc第7回QyhvalidateQyhSonatypeRyeバージョンRyb番号Qyc第6回RyeもうちょっQyegihyoQya_UycefkQygインデキシングQygパフォーマンスQyb検討QycサーバQymインフラエンジニア養成読本QybログQyb収集Qya~Qyd可視化編Qyb手伝RyaいRydプロキシQyfpluginRygCuratorRyc第5回Ryb転職QyfserverQyc2ndQygeditionQymファーストインプレッションQyc可視化Rye現状確認会Qyb最新Qymインフラエンジニア技術勉強QyeよくわかるQyfAmazonRykCloudSearchRyb行っUya外Qyb世界Vyb知るQybことSymアジャイルデータサイエンスQyd届きましQylAggregationsQyeファセットQycよりもQyb柔軟Qyb集計QydkopfTygaliasesQyb画面TyfstreamQybesQyb複数Qyb登録Ryc第4回RyhanalysisRycJVMQyiOperationQyfCasualQyeTalksQyijvmcasualQydrestQyb概要QymElasticSearchSyjServer日本語版Qyc電子版Qyb発売RydGOTOQyeNightQycからおQybようQyeございますQycいつもQyb入れRybいるQyfServerQyb翻訳SyfNestedQyfObjectQyeフィールドQyb奇妙Qyb動作Qyc第3回Qy Pelasticsearch勉強会RyfすずけんさんQya元QygVagrantQy QElasticsearchクラスタQydSolr]yd第一印象QyfluceneTyegosenTyc時系列Qyb管理RyhExtendedQybRCQya＆Ryd20追記Qyb配置QyhextendedTyganalyzeTyeMavenQyc改訂版RycPDFQya版Qyb公開Ryc第2回RyhClouderaTyeWorldQyccwtQydRiakRyfMeetupUyfriakjpRyb改良Qyc開発中Qyd第12回Qyb主催TyfSolrJPUyjinquisitorQyeriverQyiwikipediaQyc疑問点QyiWikipediaRygインデクシングQyc第1回Ry PElasticSearch勉強会QyjMorphlinesRyhloadSolrQybだけQyb調べSyfXperiaRyaZRyb故障Qya『TygプログラミングQydHiveQya』TyfHadoopWyb3版Qyd刊行記念QydセミナーRygoreillyQyd0724QyhYokozunaQya気Sya点RydというかRybなんQyiスキーマレスモードQydSOLRQyc見ましQyeありましてQyeBashoQyeJapanUyb遊びRyd行きましRydsolrQycxmlQyb探索QydロジックQyfapacheQyfloggenQygfluentdRyfkibanaQydログ検索QybデモQycAWSSyfSummitRyc来ましTycDayRyiawssummitRyc妄想版QyeモジュールQybたちRyhSearchってQya出QydたらしいQybとりQycあえずQyb雑感QyffluentQylzoomdata作りましQya＋Tyb悩みQyb事とQyaかQybより|yb移植|ynOctopress始めましたQyb以上Qyb可能QyaすRygポモドーロ回しQy Qポモドーロテクニック入門読みましたQygChangesSyb訳しRybあるRyibackwardsQymcompatibilityQyfpolicyQybなっQyeエンジニアSyfスキルアップRygCompassRyftecompRya―RycVolRyb人気QycWebQydサービスQyb作りQyb方教QyaえQydJIRARybS3QyfバックアップQyfHerokuRylTreasureDataQydWazaQyfReportQyb!!QyhherokujpRycユーザQya＠Qyb竹橋QycスマホQyd時代到来QybこのQyb先生QyaきQybこるQyb？」Qyd買いましQyjConferenceRyfWinterQychcjQyc13wQyiエンジニアサポートQyaおQyeモデレータQydいまさらQyb担当Qykコード・シンプリシティQyfKindleQyjpaperwhiteQyb使いQyb勝手Qyb確認Qyb兼ねQybDBQyfHSQLDBQyjPostgreSQLQydaugjQyc第一回QyiJetBrainsQyhユーザーグループQyejbugjQygDSIRNLPQyb＆「QyeEmacsQyd実践入門Qyg頂いちゃいましQyfビッグデータQyd活用事例QyfjawsugQyc0対応RyeLucidQyeGrantQyiIngersollQybさんQyb講演Qyb聞いQycPFIQyhオープンセミナーQygpfiopenQycメインQycMBAVyhMountainQydLionQydいろいろQyc確認中QygFluentdRyfmeetupQygTwitterVydtwtrTydhackTyfPythonQyjDevelopersQyeFestaQyb07QydしゃべっQyepyfesQygPartialQyfUpdateQyicopyFieldQybバグRya【TyeALPHARyb】(QycMIRQye輪読会始めQyd勉強会第Ryb8回RylソースコードリーディングSyc10回QymhadoopreadingRyfZipkinSyfReadmeRya２Ryb残りQyb周りRy YautoGeneratePhraseQueriesQyeデフォルトQya値Qyb分散RyfトレーシングQyb追跡QydリソースQya壁QyetrunkRyeライブラリQya差Qyb替えQygランダムテストQyb失敗RygオープンソースQyb貢献QycススメQycCCCRyfSpringQymPlayFrameworkQybてるQyc7対応QybIDQyb秘密QybJPQya＃QycCJKQy TSynonymFilterFactoryQydサンプルSyb2章Qya～Qyb1章Rya】Syb出てQybたよQycOneQyiJavaOneJpQyb問題Qyb重要Ryb次期Qyb久々QycMacRyb渋谷Qyb自分Qyb小さQya箱Qyb脱出QyeScalaQyd始めましQyc第0回QydHackQyeCleanQyeCoderQyb親子Qyd楽しめるQyb絵本Qyb英語QycじめるQya本SyiデジタルハリウッドQymSynonymFilterQybときQyd問題点編Qyc今興味QyhモーショノロジーQydMapRQye中身説明会QyeOSSAJQyfミニセミナーQyb話しQydブランチQydあけましQybおめQygとうございますQyb会社Qyb第2Qyb東京Qyb７回Qyb発表Qyb構造Ryg言語処理勉強会Ryc備忘録Vya５Qyh2009lateQyb他くQybだらQybないQybどんQyb大量Qyc読めるQyb速読Qyb7回RygMongoDBQyfSplunkQydLiveQya!QydイベントQygEuroconQyiBarcelonaQyhBookscanQyc外部化Qyc4対応QydFallRyb文章QyeキーワードQyb抽出QyfイレギュラーQyb7つZyb言語UybIoRya４Qyd管理画面QyaxQya系QycNewRyiSolrCloudRyfDesignRyc0日目Qyb速報RydRubySyc3日目Qyc最終日Qyc2日目Qya３Qyd辞書分離QyfテストケースQyd残タスクQyd複数辞書Qyb込みQycjarQyb分離QyeAppleQya教Qyb入信QyeNAISTRydJDicRyeMeCabRylPreprocessorQyb中心Qye開発方法論Qya・RyeモデリングQye設計手法等Qyc座談会Qyb5回QylcompositePOSRy TCompositeTokenFilterQyb修正Qyc対応版Qyc仮実装Qyc利用例QyenaistQyfchasenQyc英単語Qye出力方法例QykTokenFilterQycソースQydじめますQ>vgsummary<ya0Hya1Rya2rya3gya4@ya5Tya6\ya7^ya8Xya9Tyb10Pyb11Ryb12Vyb14Qyb15Qyb16Tyb17Syb18Syb19Syb20Ryb21Qyb22Qyb23Qyb24Qyb25Syb26Syb27Ryb28Ryb29Qyb30Syb32Qyb49Qyb79Qyb84Qyb90Ryb92Qyc201Qyc300Qyc477Qyd2010Qyd2011Ryd2012Vyd2013Xyd2014Qyd2015Qyd2016Qyd2017Ryd2018Ryd2019Syd2020Vyd2021Qyd2022Ryd2023Qyd4897Qye23608Qyf148121Qyb日常QyaでfybよくUya、Mye形態素解析Syaし\ybたくWybなる[ybことyyaがfyfありますよねQya？\ya UycそしてSyeSlackRyaもtyc日常的QyaにYyb立ちRyd上がってQydますよねQycというSyaはWyaの]ycボットQycとして_yb今年kyb振り[yb返りVycブログUyaをIydリビングQyb書いuyaてXycいます^ya（^yeドミノ倒しQycすごいRyaなhya）Nya。yycFMVQyeキーボードVybいる\ycタイポQycつらいQybこのvyb記事Xyd情報検索Sya・Xyd検索技術RyfAdventTyhCalendarSyd15日目Qyaす^yb昨年\yb続きSyc2回目Uyb情報Ryb検索Uyb参戦Qya夏QyePySpaRyjアドベントカレンダーSya/Gyb08RyeエントリーSyb昨日Uyb渋川Qybさん]ygアンラーニングQyb失敗Ryaたnya話aya私Zye続きっぽいQya「nyd機械学習RycによるRyeランキングQyb改善QycガイドQya」fyd読みましTyb著者Qyb鈴木QydさんよりQyb献本QyaいCybだい]yb読みXyc終わっRydレビューQyaとwyeあとおまけQyb紹介Ryb趣味TydエンジンTyc関するYyfプロジェクトVyfPythonSyeプログラムTydベクトルQybなど]yb確認Syb含めQygJupyterQyaNQydいくつかTybある]yb環境WycDevSyiContainerRyb動くQybよう]yb変えQyb最初Tyb導入Rya時Tyc疑問点Qybだっ_ydコンテナQya名Tydについて`yb解消Qybメモ`yb生成RydHugoRyb利用Pygブログ移行日記YybそのeydありますXyb当時QydbrewQyfインストールYycいましYybまたXydWSL2QyfUbuntuQyb入れTyb開発Wyaか`ycこちらeyfDockerQygDesktopQycWSLQyjバックエンドエンジンQyb前回aybVSQydCodeSya＋Wybまし^yc残課題Qyhマルチコンテナ化Qyb話もQycしましSyb今回hyaCQycpreQya-TyfcommitQygPyCharmQygWindowsRyb組みRyc合わせQyb困っRyd書きまし]ybこれUyd知り合いSydチャットQyb最近Yyb書きWyd始めましSycきちんQyb季節TybやっZycきまし]yfBerlinXyiBuzzwordsVyeオンラインUyb出張VyfハイブリッドRyb開催bybして[yaくYyaれ~yb参加tybなんXybとかYybますkye時間大丈夫QyawRyb紅白SydリアタイQya見WyaらTye2021年Ryb抱負SybからJybまず_ya返QyftaichiQycDIYTybなく[ybPCYydまつわるQyc仕事中Qyc本記事Qyc9日目QycだいぶRya間Wyb空いSyeしまいまし_yc日本語WyiオートコンプリートSybですbyd日本語用RybためZyhAnalyzerTydどうやっQyb使うSybのかTyb簡単PybもうZyb少しZycいろんSydパターンQya試Qya風QycうわさQykTokenFilterRyfLucenedye取り込まれQyd聞きましQydLUCEQya.WyfアップデートTybするZya際Qybまで_yaやQyiレイアウトファイルQyb修正Vyc個人的Syb残し_ydおきます\yfQuerqyRymElasticsearchxyeプラグインPybどんXydなつくりQybなっhycちょっPybだけVyb調べWycみましUydSolrryeElastRycクエリQydリライトQya用QydなものかSybとりVycあえずUyb概要VyfドキュメントQyd追いかけQyaみ]yb感じYyb現地Qyb再開Ryd人もいるQyb正式Qydリリースpyaさ~yc新しいTydJavaWyfクライアントQya出Syb使っ\yeAzurePyiCognitive^yfSearch\yb2月Tyb機能Uyb公開SyeIndexQyeAliasQyfインデックスSyb別名Qybまだ]yjパブリックプレビューQyb段階Ryb年末Sya次fyb論文Ryb読んPyaだ\yb軽くSydまとめてRygExtremeQyeMultiQyelabelQyhLearningQycforUyhSemanticSyhMatchingQybinVygProductQyd前回読んQyb理由Xyb一緒Syb録画RybオッQybかけRyb再生Qya気_yfアーティストQybがらQya書Rye2020年SyaまUybあとWyd今年買っRyc良かっRybものpyfリストアップQydおこうかQyd思いますWycといいRybネタRyb書くWyeといいつつRydスキーマRybときVydポータルQyeフィールドQyb一覧Syb見るQydできますQybただTyb実際TycインデQyepyspaSyb投稿Tyb引きVybらみQyfDomainQyhSpecificQykPretrainingQyhVerticalQya:UydCaseQyeStudyQybonQyjBiomedicalQyjLiteratureQyd論文自体QycリンクVyb参照QybさいWyaSRyeMICESRyb共同Qyc別開催Qyc別日程Qye6月14日Qyc17日QygカンファレンスSyc新機能QygセマンティックQye日本語対応Qyb発表RyfPublicQyaPQyeSofleRybv2Ryc長らくQyeコンパクトQygやっぱりいいよQybなぁ[yeKochiRyhKeyboardSygLunakeyQydMiniQyb発売TycなさんSydスライドUyb作成Vya何RydいますかQygKeynoteQyjPowerpointQyfGoogleQyfSlidesQycMacUya作Qyb新型QygコロナウィルスQyb影響Rybあり[yeオフラインQyc集まっQyc勉強会`ybできUyg検索技術勉強会Ryb1年Ryd以上開催QybないhyaスQyeODataRya式Qyb書式Qyb条件Ryc書けるQyb仕組Ryd検索条件Qya$RyffilterQycソートQyforderbQyb自宅SydいろいろQyc変わっRycなかっYyc更新版Tya(xyb09Qya)ryc前々回Ryb03TyaそQygSuggestQylAutocompleteQyc見つけUyb挙動QybログSya公Qyjオライリー・ジャパンQyjコンピュータシステムQyb理論Qyb実装Ryb始めQyb取るRyb原著QyeオライリーQyaじUyaゃRygCorne使っQyb数字QybキーQycとどうQybはりQycなってQycそこにQyavQyfメインマシンQyb下記QygサンワサプライQycUSBQyb接続RycKVMQydスイッチQyb一台QycノートQyeありここにQyeCorneRyfデスクトップRyb自作Syb立てRycパーツSyfアフィリンクRyb貼っQye10月くらQyeブログ書いTycカタンQyb航海Qyb者版Qyb購入Vyb家族Tyb負けQye2019年RygElasticRyestackWyd18日目Qydなりますlyb本日SybLTQydしゃべりQyb足りQybたんUybこっTybそりQyaIRyeじめましてQyc4日目Qyb大谷QycコンビRyb2号QydそろってQycまとめQyhセパレートタイプRyeLightQyeビルドログQybとしRybヒゲRyb不評RycでいつRyb通りQyb長さQyd切りましQycお試しRya中TycソフトRybたりXyb伸びQybきてUyb試しSye伸ばしてるQyb買っVyb今日YyaこSybごろRyb作業Ryb多くQyaきXyb思っ[yd春くらいQycなんかUyb知らQygTwitterPyfタイムラインQyb06Rye00くらいQycマージQya@^yfminoruQya_XyeosukaQyb継いRygLinderaRyhKuromojiXydRustqydクローンQyeリポジトリQyb先日QydシステムVyb構成Uyb大体QycうまくQycヒットQybといQyd自宅環境QybあっYyaおWyc客さんUycおかげQyb相変QycわらずQyaせRycもらっRybてるSyb昨今QygコロナウイルスQyb便利SydクレートQyb自分VyeそもそものQyb問題Wyb処理Zyb言語Zyd100本ZycノックZya第syb4章\yb早めQydやりましQydですしねQyb吾輩Qya猫Qyb3章Uyd空きましQyd正規表現QycすかねQyb負荷Qyb計測Qyb数回QyeクラスターQyb起動Ryb停止QycたりしRyiTerraformQybやるRya楽Qyb特徴QydふんわりQybまぁVya頭TydぼんやりQyb考えSyb文章Tya他Wyd検索周りRyb手伝SyaうQyb仕事XyfフリーランスQyb知れRyaばXyb知るQybほどTyb面白Wyc自分用[ydにくいかXycthebydBookYydbookXyb5章Wyb6章Vyb8章Uyd6月7日Qya週Qya?VydベルリンSycBigQyjluceneutilRyeマニアックQycツールSyfセットアップVyb誰得Qyb興味Yyb場合Tyb飛ばQyeしましょうQyb一応TydREADQycFSTQyb関連TygパフォーマンスRyb自体Qyb以降Ryb直るQyb扱うRyf形態素解析器Ryb使いTybたいRyc2種類Qyb用意SycこれらQyb違いRycなものSycSDKQyhアプリケーションQycに対しQyb送信QyeリクエストQyeパラメータQyiMircosoftQyeBuildQydイベントXyb今週SydありましRybMSQyb方やQyb教えRycそこでSyeセッションVyfMyBuilQyiWorkplaceSyb触っ[yeStackSyb2章Syb残りRyaちTybなみRyd標準入力Qyb受けTyb出力Syb関しRydファイルWyc気づいTybたらWydヶ月サボQyaっSycごめんQycなさいQydじめましSyc確認用QydUnixQybコマQyhリファクタリングRycとっくQyc暗号文QycpubQybfnQyfcipherQydtextQya&UycampSya;UycstrQyb-&QybgtQyb要素Qyb説明SybなおQyc7時点Qya社QyjEnterpriseQyb呼んQybでいSyb製品Syc製品名QydカスタムRyb辞書Zyb方法Tyb設定Vyb記載Vyb更新Vyb要望QycAWSUyeServiQyb7章QyaパQycコードQyb載せQybほうRyb見やQycすいかQyc円周率Ryb2年Qya前WydどちらかQydツイート[yd言語処理Rya版Ryf自然言語処理Syb研究Qyb動向Qyb反映Qyb深層QykニューラルネットワークQya関QydEnumQydmatcQycCLISya方Yyb過去Qyb御覧RydコマンドTygpicocliQygGraalVMQyaGQyc構造体Qyd勝手知っQybたるQybやらQyeすもけさんQyf在宅勤務環境QydおもしろQybそうWya貼QybれるVybなとVyc私自身QycたぶんSydいちばんQyb大事Qyb概念Qya思QyfVisualQyfStudioQyb作っVygAnalyzeRyfClientQydタイミンQyd自転車本Qyc良いかQyb知りSyb合いRya先Rya読Qyb動機Qyc手伝っQyb基本Rya的UybさせQydだきましQydもともとQydJJUGVybナイQyb実践Wyb入門\ybでるRybころZyb終了Rye終わりまでQyb終えQydいきなりQya少Ryc初心者RyeRust製Ryi日本語形態素解析器QybでみRyg日本語形態素解Qyb読書Qya本^yd合わせてQybだくQyb良いUygクイックツアーQyaバRycしまっUyb記録RybこうRyfBRAVIAQybKJQyc55XQye9500GQyfAmazonUya|QycソニーQydSONYQyc手伝いQya=Rya形Qyb入っRybおりSybいくRyc始まるQydまだまだQyb勉強SycたいしQybこんWyd検索シスQyc何種類QyfボードゲームRye楽しみましQyb感想Xyb交えQycようかSyb知人Qya参Qyb去年Vyb7月Qyb積んQyb時間Tya[Qyc言語仕Qyc12月Qyb退職RycしますQyeその後どうQyd一応現在Qyb状況Ryb留めQyeおこううかQyb結論Qyb起因QydいつものUyb5年RycくらいRyiOctopressRyb使用QyeコンテンツQycかかるQybほかQyfプラットフォQyfSasukeQycがついQye2018年Rya元XyeTOEICRyd受けましQybTOQyb普段SyemacOSQyb標準QyeターミナルSyhドットファイル系QyeemacsQyb引っQyb越すQybたびQycコピーRyeいいかげんQyfGitHubQyb管理RygMacbookRycProRyc新しくRybなりTybOSQyhCatalinaQygなっちゃいましQydbashQygprofileQyb上げRyd最近使っQyb手元RycインチQybほっQydたらかしQye最終出社日Qyc退職日Qyd有休消化Qyb思いWyb返せQycヶ月もQydElasYyb日目Qyc1日目Vya質Qyb高いQyb続いQyd一旦休憩Qyb頂くQybヶ月Tyc今年起Syb返っTyb毎年Qyb恒例QybすねWygBonfireQydDataSygScienceSya#Pya枠Ryb日時Syb00Tyb場所RyeYahooRya!UyeJapanUycサイトWyehttpsQyb:/SybyjQyfmeetupRyhconnpassQyccomRyeeventQyfハッシュタグQyiyjbonfireQy PElasticsearch勉強会_yiAcroquestQyjTechnologyRya人UybたちRyb技術Tyb書展Qyb販売Qyb書籍Wyb頂いRyfMeetupTyb切りQyb替えQycたらーQyc受付用QycアプリRycかなくQyfElastiSyaんXycだけどSyb独学QybなーQybみんRybどうRycだろうRybどーSygjohtaniSykEngineeringQydTechQydTalkQyb運営Ryb1回Syb開始Qyc1回目QycよかっQye2017年QybもっQyb英語Uyb継続Rya＆Ryd25日目Ryb最後Vya！^yb来年Syb忘れSybなけQyaずTybすでQycalpQyb遅れQyeちゃいましQybみよQyb転職Tyc前までQyeパスポートQybすらQyb持っRya今Tyb会社Ryb半年Qyb1度Qyb割合Qyb海外UyaへVyb発生Qyb生活Qyb送っQyd毎月開催Qyb日経Qyb会場Vyb借りRydなりましWyeスピーカー[yb募集QydhttpRycbitQyblyQybSpQygナイトセミナーQycAPMQyeAgentQyb補足Qyb久々]yc第2回RyhtemplateQyfディレクトリQydどういうQyb流れWycデータVybやりRyb取りRycについRyhMANABIYAQycブースRyb合間QybここQyb数年QyeスポンサーQyb色々Tyb05SyanRydgramRyb大好Qyb単語Syb文字QydそれぞれQyb別関Qyb04Sye入力文字列QyesplitQyjwhitespaceQyb()Qyb分割Qya鉄Ryd熱いうちRyb打てRyb1章Qyb02RybさてSyb効率QybいいRydかどうかQybどもRyb退化QyehappyQycnewRydyearQycandZyhlanguageQyikatsyoshiQydのめもみQyb触発Qyc第1回QybUIQybごくRyb2回QyfKibanaYya順Qyb追っRydあけましTybおめTygとうございますTybサボQyaりQydがちだっQycとずつQyb復活Qyb1弾Qyc昨年少QyaKQyb見なQyb行っ^ye2016年QycもちろQyeMerryRyiChristmasRyd24日目Qyb以上RyhSwiftypeRyc内検索RygプレスリリースQya：hydサービスUyc最大手Qyb買収Qyc出ましQyfSwiftyQyb執筆SydといってTyb以前Wyc私以外Qyb方々Uyb結構Tybな量Qyb直しQyborQyd新規書きQyc起こしQyb主催UyeプロダクトRyb超えQyb共通Qyb課題Qyb悩みRycRioQyfプレイバックQyaQybながUyb長いRyb一年Rye2015年Qyc最終日Tyb変遷RycみますRyeクエリプロQyd10月末QyeでいくつかQyb久しTybぶりVyfIngestQyiProcessorQybみるQycんじゃQyc3番煎Rya物Ryc壊れるQyb厄年QycからかQyb記念Ryb壊れRybたかRycおこうRyc腕時計QycないかRyd電波腕時Qyd第16回Qydスタッフ[yc皆さんTyd会場提供TylリクルートテクノロジーズYyd第15回QycポストQyd技術書読Qyb監修Qyb見てUyc14回Qya皆Qyc紅白見Qyb早いSye2014年RydエントリSybにちRyb師走Ryb今月Ryc一番忙QybかっTyeたりしますQyaARyd第13回Rya※dyb翻訳dyb原文cycTheTyeStoryQybofQyeSenseSyjAnnouncingQydbetaXyb誕生Qyb同様QycビールQyb飲みRya考QyfShieldSya,XygWatcherRyfMarvelSybGARyhReleasedUycおよびQydMarvQyhreleasedPyeコミッターSya+Ryb💚QydサポートQyhLogstashWyfRelaseQybweQydhaveQyb画像RyaごSyb覧くQycとってQyb大きSyb1日QycベースQyiunpluggedQyjNetworkingQygchangesRydローカルQycマシンQya起QyfDeleteQybbyQyeQueryQycAPIVybIsQycnowQyaaQyfpluginTyd第11回QyaERyb東京Uyb以外Uyb2弾Qyb関西Qyb大阪Qya京QyeGreatQygMappingQykRefactoringQycユーザSyb最もQyb一つQycタイプQyfcomingQydsoonQyb準備QyaヶQyb月前QyeFoundRyfjoinedQycourQydteamQybatQyeアナウンスRyb素晴QybしいRycチームQyb彼らQydによってQybよりWylJustTechTalkQybあれSyhジャストシステムRydJMATQyfKagomeQyfJanomeQydひさびさTye勉強会メモQyfHatenaQyhEngineerQygSeminarQyeTokyoWyb当選QycいつもRyb近寄QydオシャレQya街QydドキドキQyd第10回QyoElsticsearch勉強会Vyd開場提供UygReindexQydWithQyfThanksQyeDavidQyeマッピングQyb変更UyaサQydJoinQylConversationQygDiscussQybCoQyb3つQycOSSQygスケールアップQyiコミュニティサポーQycElaRyc第9回Ryc名古屋Rya初Xyb企画QygsmogamiQyhサンフランシスコQyc弊社初QyjユーザカンファレンスQygelasticRya{QybONQya}QydアメリカQyc出張中QyaユQycyouRydknowQyhsecurityQyfshieldQydgoesQybgaQylElasticsearcQye4月13日Qyc3日間QydCoreQyfトレーニングQyeEarlyQydBirdQyb申しQyc込みすQyfkibanaQyiliterallyQyb現在Tyd文字通りQyc抽象的Qyc概念的Qyc精神的Qyc楽しくQymelasticsearchRyb来るQyd4月4日Qyc土曜日Qyb午後Ryb予定Uyc第8回QygrunningQyfgroovyQygscriptsQygwithoutQygdynamicQyiscriptingQynElasticsearch1QybによQyeCROSSUyd話もしてQyb横浜Ryc大さんQya橋QygあんまりこないQyb乗りRyb換えRydおたしてQydしまいまQyc大晦日SycしかもSyb飲んRyb9流Qye2013年QygCalndarQybにつQycなげるQyb意味QyfmarvelQyb「【Qya】Qyhナイト・セミナーQyh自然言語処理特集Qya水Qyb本当Rya入RycたまにQyb他愛QydコーヒーQyfサムライズムRydオフィスRyd入り浸っQyhexcitingQyhlogstashRyiecosystemQydBetaSyeインストーRycページTyfダウンロードXye始まりましQyhElasticsQyfApacheRyfアクセスログRyeインポートQya説QycCCCSyb7回RybデモRyeどうやってQyc第7回Qyc書こうUycらかけQyhvalidateQyb背景QykElasticsearQyb個人RyhextendedRyganalyzeSyc第6回Qyd9月9日Qya火Qya『QycサーバQymインフラエンジニア養成読本Qyb収集Qya〜Qyd可視化編Qya』Qyd出版記念Ryc執筆者Qyb語るQyb大講Qyb演会QyhelasticsQygインデキシングQyb検討QykperformanceQynconsiderationsQyhindexingQy PElasticsearchユーザQya様Ryc懲りずRydみなさんQycだけるQycとうれQyb本書Qyc共著者Qyc詳しいQycそちらQyeProxyQyb働いQyb方もQya上SydインストQygバグフィックスQycリリーQygCuratorRyb古くQyaFQyc第5回Qyb遅くTyb出てSyb無理Qyb言っQycにしてQycたいんQyb時差QybボケQyb頭痛QyeこのくらいQyc余裕出QycほしいQycリストRyc新天地Qya明QyfserverQyc2ndSygeditionQyeバージョンQyb目次Qyb元にQyaどQydのくらいQyc可視化Rye現状確認会QyjカジュアルウォーターQyb現状QyhMackerelQyhGraphiteQyb目黒QydドリコムQyb最新Qymインフラエンジニア技術勉強Qya～RygFluentdSydChefQyb実例QydどうやらQyb中身QydたらしいQyiプロダクトシリーズQya｜QyeよくわかるQybClQyb酔っQyb払っQygスピリチュアルQyb流しRycだけれQymアジャイルデータサイエンスQyb見本QycだいてQybなのSyc感想文Qyb想像Qyc薄かっQyc物理的QykAggregationQydサンプルRybHiQyeWouldQyfpleaseQydtellQybmeQycwayQybtoRydkopfTyhAnalysisRyb画面Uya３QybあいRyb開いQyb必要Ryd見つけてQydBulkQyb仕様QyaJQyc第4回Qyd遅刻厳禁RydそれほどQyc人もいQyb思うQyb次回Qya２RydメニューRyhanalysisQyb選択RycJVMQyiOperationQyfCasualQyeTalksQydあんまりSyb運用QycかやっQybついSycいけるRyb不安Qyb楽しQyc懇親会RyeないらしいQydRESTQydrestQybだかQydドタバタQyc旅行記QydこちらかQybkoQymElasticSearchTyfServerQyc電子版Ryd出ますよQya発QydGOTOQyeNightQyd海外自体Qyb初だQyeWoogaQycからおQyeございますQyb人生Qyb初めRya来Ryc人生初Qyb一人QybへんRyc入れるRycときっQyb幸せQycなれるQylelasticsearcQyc第3回Qyb触れRyjServer日本語版Qyc今年初Qyb突撃Qya隣QyhWantedlyQyhにおじゃましましQyb写真Qyb撮っQydたまたまRyb日本QyhスペシャルゲストQyb呼べQyc大満足QyaｗRyb通訳QydかちゃんQyfすずけんさんQygVagrantQyipuppet使ってQybVMQydクラスタQyb組んQyd改訂新版Qyf入門出版記念QybいうQyfSolrJPQya新Qye本出版記念Qyf技術評論社様QybプレQyb昨晩SydさっそくQybみてQydバイナリQyc配布待QyfluceneXyegosenXyb1対Qyb応版RyeライブラリQygインタフェースQygcuratorQyeAaronQykMildensteinQyc頑張っQyb所存QycとまぁQydお決まりQyb挨拶QycおいてQyb進歩QybかもQye2012年Qyd昨年書いRyb昨夜Qyb内容Uyb本家QyfreleasQyb質問Tyb言いRyd出しましQyb配置QycURLQyb辛いQycすよねQyaねQyeMavenRyjRepositoryQyb電子Rye技術評論社Qyb可能VycPDFRyb宣伝Qyc改めてQyc改訂版QybみれRyb3年Ryc前なんQyc出来るRyb形にQyj140人くらいくらいQye参加登録者Qyc参加者Syd１００人QybょっQycがいてQydびっくりQycステキQyb提供QyhClouderaVyeWorldQyc午前中QybにくQya雨QybそれRyb人数Qyb基調Qyb講演SydセッショQydまたまたTydRiakTyhYokozunaSyb聞いSyc開発中Ryb改良Ryb以下VybソーQyeお久しぶりRydたらまたQyc今開発Qye不定期開催Ryc12回Qyb過熱Qyc無かっQyc70人QyfいらっしゃっQybMLWyjinquisitorQyjElasticSeaQyeriverQyiwikipediaQydbulkQydsizeQyb登録Ryb件数QybやけQycにきりQye前々回紹介QyiWikipediaQyeアナライザQydインデッQy PElasticSearch勉強会QyepyfesRyfなんちゃってQyb資料Qyb喋っQydたちましQyoElasticSearchネタQye勉強会開催QycたりすQybおきQyb手軽Qyb宿題Qyc周りっQyc調べるSyd今朝起きQyfXperiaSyaZRyb故障Qyb電源QycボタンQyb押しQydスリープRybならQycないんQyb復帰QyjMorphlinesQybさらSyd調べましQyb誤解Ryb認識Qyd話しましQybたみQyc11回Qyc大入りQyf90人くらいQyiがいらっしゃいましQyfHadoopYyb離れSycちゃっQydHiveQyb無いQyfもかかわらずQyb近くQycにいるQycからっQyb内緒Ryb玉川Qya点QydというかSyb観点Qya別RydわけじゃQyb完全Qyb自己Qyb満足QyeBashoRyfにおじゃましQyc聞けるQyf取り込まれるQydチケットVybとくRydSOLRQyb経由Qyb眺めQybみみQycぐらいQyc初記事QyfちょくちょくQyc1週間Qyc以上前Qyb遊びQyc来ましVybRCRydVoteSyc始まっQybコトQyeマルチコアQybファQyc何番煎Qyc？ってQyb書かTybコリQycもせずQydタムタムQyaロQyfSummitUycryuQyikobayashiQycパシリQye仰せつかるQyd忙しかっQyc楽しかQybざっQyiインストールガイドQyeソース眺めQydテキトーQyfユーザガイドQyicocoatomoQyb行きQyb掛けQyc出会っQyfアンデルセンQybTDRybryQyeモジュールRybTLSyc賑わっQyd軽くどんQybだりQyb憧れQyffluentQyhZoomdataQyd最近触っQygfluentdQya流Qyb込むQyhMarkdownRyb慣れQyb書けQycどうしQydようかっQydそのままQyfGithubRyePagesQycらしいRygChangesRybしまQyeアジャイルQye時間管理術QyjポモドーロテクニックRydきっかけQyb何度QyeポモドーロQyd00現在Qyb訳しSyb詳細Qyb最中Qyd00時点Qyc開発者Qyd第2回目Qyb欠けQyb視点Qyb話しTyc寒かっQyeエンジニアQyfスキルアップQycペースQyb落ちRyc危機感QydJIRAQyfバックアップQyfHerokuRycじめるRyeRailsRygプログラミングQygheroku気Qygアカウント作っQyfデータアップQyc軟弱者SybべきQyc10回Qyc発表者Qyb無事QydあつまりQygとうございましQyb盛況QybほぼQyb満員QycツイーQybとてQyfsearchQyb出演QycスマホQyc」ってQyeキーワードQycあまりQycたけどQybいっQycarcQydもうすぐQyb２年Qyc容量不Qyc金曜日RyaよRyjConferenceRyfWinterQyb触るQya金QyiエンジニアサポートQyiセッションオーナーQyeモデレータQyb来まQydいまさらQyc感満載Qyb担当Qyb年始QycかけてQykコード・シンプリシティQyfKindleQyjpaperwhiteQycかけずQyb入手Qyd思いついQyeMongoQyiAtlassianQyd20日目Qyd急遽参戦Qya某QydイケメンRybMTQyb改変QyeリツイートQybSoQyc第一回QyiJetBrainsQyhユーザーグループQyejbugjQyb入りRya口RyaイRydヒカリエQyb不純QydおしゃれQyb綺麗RycカフェQycおっきQyb人形Qyb立っQyc皆勤賞Tyc主催者Qyc不定期Qyc方などQyc初目黒Qyg初AmazonQyc流行りQyfビッグデータQydセミナーQybあえQyb##Qyc3年越QyiウチダスペクトラムQyfMahoutQyeGrantQyiIngersollQycPFIQyhオープンセミナーQyb対象Qyb微妙Qyb外れQyb自信QyeありませんQyb友人QybにおQyb値打Qyb価格QydminiQyhMountainQydLionQycAirRycませんRydもちつつQyb聞きSyb作者Qyb古橋Qyb魅力Qyb次期RyciOSQyb連携Qyb分析QyiクライアントアプリQyb苦労RyeステッカーQya欲Qyc勉強中Qye恥ずかしげQyc偉そうQydしゃべっQyaタQyeALPHARyc興味深Qyc数日前QygPartialQyidocumentsQyfupdateQye見つけましQyfModernRykInformationRyiRetrievalRyhConceptsQyfbehindQygEditionRycACMQyePressQyeBooksQycいやぁQyb蒸しQyb暑くQybなかTyb寝れQya日QyeじまりましQybたねQyb関係Ryb伴いQydgoenQyb4xQydブランチQycjarVycいまだQyaあQybとっSyc第一弾Qyd参加人数QydはちょっQyhHBaseConQyeIssueRybがっQyeluceeQyfUniDicRyb対応QycパッチTyb勢いQyb見直QycとかしQyb状態QydおかしいQya図QyfZipkinRyfReadmeQydせっかくTyb悪いQygアーキテクチャQycトレーQyc結構前QyfschemaRycxmlRyifieldTypeQynautoGeneratePhQyc読まれQyd方もいるQyb先週Qyc木曜日QyhエンジニアブログQyc最新版UyiプロジェクトページTyeharuyQyb情けQyeしまいますQyb調査TycケースRyetrunkRyclibQycテストQycEテレQymスーパープレゼンテーションQyaふQybだらQye恥ずかしくQyalQyfSpringQydFallSygタイムテーブルRya一QynPlayFramework2QyfコーディングRyb兼ねRybIDRyb秘密Qyb丸善QyfライブラリーQya―Qyc情報研QydシリーズQyb非常Qyd読めましQyeバーコードQyc始まりQyb付与Qyc考慮点QygWebSolrRye嗅ぎつけてQybJPQyfherokuQyd知りつつQyb0対Qyb動作QybせるQyc変更点QydいきますRyh日本語形態素解析Qyd含まれるQya各Sydブログ流Qyd読みしてQydスケールQya主RygJavaOneQye2日間開催Qyb子供Ryb体調Qyb崩しQycしまいRybのみQyfテストケースSyhharuyamaQyfhideakQyb宣言QycとおりQyeパッケージQycクラスQyb皆様Qyb連絡Qyd連絡事項QybにてQycorgRyb寝かQydしつけしQyf寝かしつけさQyb２時Qya目Ryb覚めQygTSUTAYAQybCDQyfウォークマンQybはいQyb回数Qyb直前Qyd変わってQyd見かけてQybSEQydAmazQybえーQybとふQyb１年Qyd前くらいQybずーQyeつぶやいてQyeScalaQyc長かっQyc森ビルQydそのへんQyb矯正Qya遊QyeCleanSyeCoderRynプロフェッショナルプログラマQya道QycがいいQyb本だQyb親子Qyd楽しめるQyb絵本Qye身につけてQybおいQygyusukeyRye異なりましQyb広くQyc大画面Qya駅Qyc嬉しくQyeissueQycアップQye勉強会ログQyeすみませんSyd直接業務QyeリクルートQyb中野Qya顔Qyb出しQydばっかりQya役Ryb立つQyc昨年末Qyb増えQyc備忘録Vyb公約QydatndQyfeventsQyb01RyhアカデミーヒルズQyc六本木QycヒルズQya内Qyc49階QyfタワーホールQyb港区Qya六QyeベルサールQyb三田QydRoomQydシアターQyfInsideQydMapRQyb内部Qyd自己紹介QygSusheelQygKaushikQya系RygインフルエンザQyd一家全滅Qyb最悪Qyb陥っQya我Qya家Ryb流行QycつけてSyaxQyb年越QyfしちゃいましQyb5日Qyb中心RydツッコミRybコメQyeたちよりひQya足QybやいQye終わりましQya振QycサインQycもらうQyb目的QycもらいQycそびれQyb残念Rye特定文字列QybいつRyc継続中Qyb暇人QybなしQycすねぇQycといっQybいやQygDSIRNLPRyb基礎Qyb部分QybおろQybそかQydないけどQyhTokyoNLPQyiWebMiningQycMBAUyb物理QycカバーQyb大量Qyc読めるQyb速読Qyb合っQyb持ちQylソースコードリーディングQyb6回Syc先週末Qyb勤労Qyb感謝Qyc日までQyb風邪Ryc寝こんQyb朝晩Qyb冷えQyb込みQyc激しいQyb言葉Qyc触ろうQygMongoDBQyb2週Qyb連続Qyb渋谷QycさすがRyb出口QybすんQyb武田QyfSplunkRyb様々Qyb機器Qyc一箇所Qyb集めQydリアルタQyc最近忘QybすいQyhBookscanQyc電子化Qyb原本Qyb破棄QycくれるQyd電子書籍QybずっQyf新規追加機能QyfすぐやりますQyd言いつつQybはやRya腰Qyb重いQygダメエンジニアQydようやくSydコミットQybすぐRydあくまでQycHadQyb特定Qyb探しQycできるRybねぇQycあいてQybIoQybなれQygセルフスタディSyb回答Sya記Qyc色々入Qyb追加RycAIRQyiTweetDeckQydでちょっQyc見ましQybほんQydにちょっQyc英語力QybなさQyb痛感Qyb凹んQyb何かQya恥Qyb晒すQydWikiQybもとQyb下部Qya会Qyb疲れQyb機会QybだきQybとうQyb台風Qyc15号QycごかっQyb幸いQyb夏休Qyb通勤QycひどいQyb合わQydすみましQyb風雨QydすごくてQyc怖かっQyb速報Ryc知らせTycちなみQydRubyQya大QycだかんQycところQya概QygRuby2日目Qyc2日目Qyc2日間Qya実QyeぶりくらいQydゆっくりQyb日々Qyb訪れQyd積読状態Qyb消化Qyb7つRyb世界Qyb出先Qyb使えQyb進んQygEclipseQyhhomebrewQyc一週間Qyb着いQyb追記Qya異Qyb分離QybあげQyfRobertRydたらしくQyb話題Ryb同梱QyeクラスパスQyfからいくつかQyb文体Qyb変かQyc順不同Qyb参考QyhEvernoteQygDropboxQyc個人用Qyb８年Ryb新調Qyd前回購入QydなりつつQyc買おうQycかなりQyb構造Qyg言語処理勉強会Qyb帰っQyc２日半Qyb寝込Qyb春山Qya耳QycソースUyeでいませんQyjcontributeQycしまうRyd少しずつQydコメントQybいれQya毛Qyeお知らせしQybバグQyb込んQycタイミQyb分散Qye開発方法論QyeモデリングQye設計手法等Qyc座談会Qyb5回Qyb入るQyfイベントルーQyc上がっQyc未知語QylcompositePOSQycエラーQya件QymtrunkbranchesQydimplQyemecabQycdicQyeNAISTQydJDicQyeMeCabRycPreQyenaistQyfchasenQygアルファベットQyb別々Qyc英単語Qyb含まQyb目玉Qy QJapaneseTokenizerQyc形態素Qyb遅延QyiTokenizerQyhToken対してQyb特性Qyb2つQyfIPAdicQycビルドRygJavaDocQyc見たいQydMuirQyb歴史Qyc移植版QydスタートQyc今さらRycはじめQya…QydはじめてQyb一番QybわりQyb残すQ>vdtags<ya2Rya4Qyc100[ybgoQyb振り[yb返り[yeoramaQyfsearchQydmiscbyemusicRycbotQyb読書XymelasticsearchoyisearchkitQya-sybuiQyb画面QycdevTya byicontainerTydhugoTycwslQygwindowsSyfpythonSyjconferenceUyebelinQyibuzzwordsUyjopensearchQyflucenedyfberlinTydjavaQyeazure[yepaperRycDIYWyeキーボードWyeMICESQyc勉強会Jyb輪読QydNandQyfTetrisQydRust]ygLinderaQyb検索Uycnlp[ydrustUyctheYydbookYyhkuromojiSya.RycnetQygelasticTyestackQyiworkplaceRyfvisualRyfstudioRydcodeRyb買いQya物QycブログVydシステムQyb探訪QycゲームQyb転職TyioctopressSyfLuceneRyb書籍QyfKibanaSyfplugin_ygカンファレンスQyeスポンサーQyfkibana[ya本UyhtimelionQyesenseQyfshieldRygwatcherQyfmarvelTyhlogstashWyefoundQybnoQyielasticonQydjjugQyfcoffeeQymElasticsearchSyhsonatypeQygreleaseQygcuratorRykCloudSearchQycAWSSygスピリチュアルQyc感想文QyeオライリーRyfstreamQybesQycJVMQydJavaQyftravelQygvagrantQyfpuppetQydSolrRyegosen`ygfluentdSyhClouderaZyfHadoopUygNorikraQydRiakUyhYokozunaUyjManifoldCFRyiwikipediaSyfSearchVyjMorphlinesRyfXperiaQyaZQydHiveQyeBashoQyhZoomdataQydsolr]yc備忘録_ydJIRAQyfZipkinRycOSSQyeScalaQyfhadoopRye形態素解析Q>vnavgFieldLength4ybid Q9.039702233250633yetitle R12.942928039702224ygsummary Q39.86848635235737ydtags R1.3148386653500177vlfieldLengths4vbid<ya1]ya2Wya3Uya4_ya5Yya6_ya7Yya8[ya9Zyb10_yb11Qyb12Tyb13Qyb14Tyb15]yb16[yb17Qyb18]yb19_yb20Zyb21]yb22Ryb23Uyb24Ryb25Qyb26[yb27Uyb28Tyb29Zyb30Qyb31Vyb32[yb33\yb34^yb35Zyb36Pyb37Ryb38Zyb39Pyb40Xyb41Ryb42Xyb43Tyb44_yb45^yb46]yb47Zyb48Vyb49]yb50Qyb51Xyb52Yyb53Yyb54]yb55Xyb56Yyb57\yb58Wyb59Uyb60]yb61Syb62Tyb63^yb64Zyb65Ryb66Qyb67Xyb68Zyb69Ryb70[yb71Zyb72Zyb73Tyb74_yb75Tyb76^yb77Zyb78Tyb79[yb80Ryb81\yb82^yb83Tyb84]yb85Qyb86Syb87Tyb88]yb89^yb90Ryb91Pyb92Uyb93Qyb94Qyb95\yb96Ryb97]yb98Vyb99_yc100Pyc101\yc102Yyc103Pyc104[yc105\yc106Tyc107Syc108]yc109Uyc110Pyc111\yc112Xyc113Ryc114Syc115Yyc116Qyc117\yc118_yc119Syc120Ryc121[yc122\yc123Yyc124^yc125Qyc126Qyc127Yyc128Wyc129^yc130^yc131\yc132Tyc133Ryc134Zyc135Uyc136Yyc137Ryc138Yyc139Qyc140^yc141\yc142[yc143_yc144Uyc145Ryc146Qyc147Zyc148Ryc149Zyc150Qyc151Qyc152Syc153\yc154Zyc155Zyc156Uyc157]yc158Qyc159Xyc160\yc161Zyc162Tyc163_yc164Zyc165\yc166Zyc167Tyc168\yc169Tyc170Yyc171Uyc172^yc173]yc174Qyc175Tyc176\yc177[yc178Ryc179_yc180_yc181\yc182_yc183]yc184[yc185[yc186]yc187^yc188Qyc189Ryc190Uyc191[yc192Qyc193\yc194Zyc195Syc196Uyc197Pyc198Qyc199Pyc200[yc201\yc202Ryc203Wyc204Pyc205Qyc206Wyc207Tyc208]yc209_yc210]yc211Tyc212Tyc213_yc214[yc215Xyc216Tyc217\yc218^yc219Wyc220Qyc221Uyc222Ryc223]yc224\yc225Zyc226Qyc227Syc228Qyc229Qyc230Vyc231Zyc232Pyc233\yc234Ryc235Tyc236^yc237[yc238]yc239Wyc240[yc241Syc242Zyc243]yc244_yc245Syc246Qyc247Zyc248Zyc249Xyc250Yyc251Vyc252Qyc253Wyc254Tyc255Qyc256Syc257Yyc258Vyc259Tyc260[yc261Vyc262^yc263Xyc264\yc265^yc266Yyc267\yc268Tyc269Ryc270[yc271[yc272^yc273_yc274Qyc275Tyc276Qyc277Uyc278Ryc279Ryc280Tyc281Syc282Tyc283Vyc284Wyc285^yc286[yc287\yc288Qyc289[yc290]yc291Syc292Tyc293Qyc294_yc295Tyc296[yc297Uyc298^yc299Pyc300Ryc301Zyc302^yc303Qyc304Zyc305Vyc306Qyc307_yc308Tyc309Pyc310[yc311^yc312]yc313Zyc314Zyc315]yc316Zyc317]yc318Xyc319Xyc320Tyc321Vyc322Yyc323Ryc324_yc325Syc326Qyc327Xyc328_yc329^yc330Zyc331Xyc332Ryc333]yc334Qyc335Qyc336Syc337Tyc338Uyc339_yc340Pyc341\yc342Uyc343_yc344Xyc345Xyc346Xyc347Vyc348]yc349Qyc350Qyc351_yc352Ryc353Qyc354]yc355^yc356Tyc357]yc358Pyc359Yyc360Qyc361Xyc362Wyc363^yc364\yc365]yc366]yc367Uyc368^yc369Zyc370Pyc371Tyc372Qyc373Qyc374Qyc375Qyc376Pyc377\yc378Xyc379[yc380Qyc381Ryc382Syc383Wyc384Qyc385Syc386\yc387Qyc388Tyc389Tyc390Tyc391Wyc392Qyc393[yc394Yyc395Ryc396]yc397Vyc398Syc399[yc400Qyc401_yc402^yc403[>vetitle<ya1Uya2[ya3\ya4Yya5Yya6Wya7]ya8Vya9Vyb10_yb11]yb12]yb13[yb14[yb15Tyb16Yyb17Zyb18Vyb19Uyb20Yyb21Wyb22[yb23Uyb24[yb25Xyb26[yb27Vyb28Qyb29Vyb30[yb31Yyb32[yb33Pyb34Tyb35Zyb36_yb37[yb38Yyb39\yb40Pyb41Tyb42Pyb43Uyb44[yb45Uyb46[yb47]yb48Xyb49Tyb50Zyb51Zyb52^yb53Yyb54Tyb55Wyb56Wyb57[yb58_yb59Pyb60Zyb61Yyb62\yb63Yyb64[yb65Zyb66Zyb67Yyb68Syb69\yb70Zyb71\yb72\yb73\yb74Tyb75^yb76Vyb77Zyb78Zyb79\yb80Uyb81Zyb82\yb83Zyb84Wyb85Zyb86]yb87Yyb88Uyb89Yyb90Xyb91Yyb92Wyb93]yb94[yb95\yb96Ryb97Vyb98Wyb99^yc100Tyc101\yc102[yc103Yyc104[yc105Xyc106Ryc107Tyc108Vyc109Ryc110[yc111Wyc112_yc113Zyc114Yyc115Xyc116Uyc117[yc118Pyc119Wyc120Yyc121Xyc122Uyc123^yc124_yc125_yc126_yc127_yc128Yyc129^yc130^yc131[yc132Uyc133Wyc134[yc135Zyc136Xyc137[yc138Uyc139Xyc140\yc141Uyc142[yc143[yc144Zyc145[yc146[yc147Syc148_yc149Zyc150Uyc151Qyc152[yc153[yc154[yc155Yyc156^yc157Pyc158^yc159]yc160Zyc161Syc162Syc163^yc164Wyc165_yc166Yyc167Ryc168Uyc169[yc170Zyc171[yc172Yyc173Syc174Zyc175[yc176Pyc177[yc178Uyc179Yyc180Uyc181Vyc182Qyc183Wyc184Zyc185Zyc186Qyc187]yc188[yc189Yyc190[yc191Qyc192Pyc193Qyc194Yyc195^yc196Syc197Qyc198Syc199Yyc200Zyc201Qyc202Uyc203Yyc204\yc205Zyc206Pyc207Wyc208^yc209Xyc210\yc211Zyc212Zyc213Tyc214Tyc215Yyc216\yc217Xyc218^yc219Wyc220Tyc221Yyc222Yyc223Xyc224Zyc225Yyc226_yc227Yyc228Xyc229]yc230Zyc231Uyc232Wyc233Xyc234Yyc235[yc236_yc237Xyc238Wyc239^yc240Zyc241_yc242[yc243Vyc244Xyc245\yc246Xyc247Xyc248Xyc249[yc250Ryc251Pyc252Wyc253Xyc254[yc255Vyc256Wyc257Xyc258[yc259\yc260[yc261_yc262Syc263[yc264Xyc265Yyc266Pyc267]yc268Wyc269Vyc270Xyc271Xyc272Tyc273Tyc274Wyc275Tyc276Vyc277^yc278Zyc279Yyc280Qyc281dyc282\yc283Syc284eyc285kyc286\yc287]yc288Pyc289Pyc290nyc291Zyc292Wyc293Yyc294Vyc295Yyc296Pyc297Qyc298Syc299Yyc300Pyc301Ryc302Wyc303Ryc304Syc305Qyc306Yyc307Tyc308Yyc309Tyc310Yyc311Ryc312Qyc313Qyc314[yc315Pyc316Pyc317Zyc318Syc319Vyc320]yc321Zyc322[yc323Syc324Tyc325Syc326^yc327Uyc328Wyc329Yyc330dyc331_yc332Uyc333Ryc334Ryc335_yc336^yc337Syc338Vyc339Xyc340Vyc341[yc342Pyc343Zyc344Syc345Qyc346Pyc347Yyc348_yc349]yc350^yc351Qyc352_yc353^yc354Wyc355]yc356Tyc357Syc358Xyc359Wyc360_yc361Wyc362Qyc363Qyc364Ryc365[yc366[yc367_yc368Syc369Qyc370Ryc371Zyc372Ryc373Pyc374Pyc375Uyc376Ryc377Pyc378Uyc379^yc380Ryc381Ryc382Zyc383[yc384^yc385\yc386Zyc387Xyc388\yc389Tyc390[yc391Syc392_yc393Pyc394ayc395\yc396Pyc397Ryc398Pyc399[yc400Zyc401[yc402Zyc403X>vgsummary<ya1`ya2fya3iya4dya5fya6aya7fya8gya9ayb10dyb11_yb12\yb13hyb14lyb15dyb16fyb17ayb18Xyb19eyb20^yb21`yb22dyb23eyb24eyb25wyb26lyb27cyb28fyb29hyb30yyb31gyb32byb33byb34_yb35ayb36eyb37byb38lyb39dyb40dyb41fyb42^yb43dyb44jyb45tyb46eyb47cyb48fyb49oyb50`yb51hyb52eyb53fyb54jyb55lyb56nyb57fyb58kyb59hyb60Hyb61dyb62eyb63eyb64eyb65Hyb66Hyb67`yb68byb69cyb70Hyb71kyb72gyb73xyb74_yb75[yb76ayb77Yyb78Dyb79hyb80`yb81zyb82]yb83uyb84hyb85pyb86eyb87oyb88iyb89gyb90\yb91kyb92qyb93byb94iyb95hyb96gyb97nyb98gyb99cyc100cyc101dyc102dyc103eyc104kyc105gyc106eyc107ayc108myc109iyc110qyc111syc112`yc113\yc114eyc115]yc116nyc117myc118pyc119syc120lyc121gyc122eyc123`yc124iyc125pyc126fyc127iyc128pyc129gyc130gyc131pyc132jyc133ryc134Xyc135iyc136gyc137lyc138Byc139ryc140hyc141lyc142Yyc143Yyc144nyc145[yc146qyc147byc148kyc149Yyc150zyc151qyc152pyc153yc154tyc155myc156pyc157iyc158pyc159syc160Yyc161uyc162uyc163`yc164jyc165vyc166kyc167ayc168ryc169myc170Zyc171oyc172lyc173myc174Zyc175myc176dyc177myc178eyc179syc180_yc181pyc182qyc183byc184Zyc185lyc186syc187fyc188lyc189byc190nyc191syc192dyc193kyc194uyc195tyc196byc197syc198_yc199]yc200Zyc201qyc202gyc203`yc204oyc205Zyc206_yc207Wyc208jyc209Yyc210byc211lyc212\yc213jyc214nyc215syc216gyc217[yc218\yc219hyc220jyc221wyc222cyc223cyc224ayc225`yc226pyc227fyc228fyc229cyc230gyc231hyc232Wyc233Xyc234byc235dyc236[yc237byc238_yc239gyc240Yyc241]yc242lyc243eyc244gyc245`yc246jyc247jyc248byc249fyc250tyc251lyc252cyc253cyc254hyc255Tyc256cyc257^yc258[yc259_yc260cyc261gyc262dyc263byc264eyc265eyc266jyc267hyc268kyc269kyc270iyc271oyc272ayc273fyc274^yc275kyc276dyc277fyc278dyc279eyc280dyc281fyc282Zyc283nyc284lyc285jyc286hyc287\yc288jyc289byc290hyc291pyc292myc293_yc294dyc295_yc296lyc297nyc298fyc299kyc300hyc301fyc302pyc303]yc304fyc305dyc306jyc307byc308jyc309ryc310Eyc311dyc312pyc313cyc314iyc315nyc316byc317ayc318fyc319cyc320nyc321fyc322gyc323nyc324fyc325dyc326eyc327_yc328lyc329jyc330byc331eyc332vyc333eyc334gyc335cyc336cyc337eyc338fyc339myc340oyc341eyc342hyc343nyc344dyc345lyc346oyc347nyc348Ayc349tyc350lyc351ayc352fyc353nyc354fyc355cyc356kyc357ayc358lyc359lyc360hyc361oyc362lyc363fyc364pyc365dyc366_yc367gyc368jyc369fyc370lyc371hyc372dyc373tyc374lyc375vyc376nyc377nyc378lyc379qyc380kyc381iyc382ayc383gyc384eyc385`yc386fyc387oyc388hyc389fyc390gyc391lyc392dyc393lyc394byc395fyc396Yyc397byc398_yc399Wyc400fyc401ayc402^yc403p>vdtags<ya1Qya2Rya3Qya4Qya5Qya6Qya7Sya8Sya9Qyb10Syb11Syb12Qyb13Syb14Ryb15Qyb16Qyb17Qyb18Qyb19Qyb20Qyb21Qyb22Syb23Qyb24Syb25Qyb26Ryb27Qyb28Qyb29Qyb30Qyb31Qyb32Syb33Syb34Qyb35Qyb36Qyb37Qyb38Qyb39Syb40Syb41Qyb42Qyb43Qyb44Ryb45Qyb46Qyb47Qyb48Qyb49Qyb50Qyb51Qyb52Qyb53Qyb54Qyb55Ryb56Ryb57Syb58Qyb59Qyb60Uyb61Syb62Qyb63Qyb64Qyb65Uyb66Uyb67Ryb68Syb69Syb70Uyb71Ryb72Ryb73Ryb74Syb75Syb76Qyb77Qyb78Uyb79Ryb80Ryb81Uyb82Qyb83Uyb84Qyb85Uyb86Uyb87Uyb88Uyb89Qyb90Qyb91Qyb92Ryb93Qyb94Syb95Syb96Qyb97Qyb98Qyb99Qyc100Qyc101Qyc102Qyc103Qyc104Ryc105Qyc106Qyc107Qyc108Qyc109Qyc110Qyc111Qyc112Qyc113Qyc114Qyc115Qyc116Qyc117Ryc118Qyc119Qyc120Qyc121Qyc122Qyc123Qyc124Qyc125Ryc126Ryc127Ryc128Ryc129Qyc130Qyc131Ryc132Qyc133Qyc135Qyc136Qyc137Ryc138Qyc139Qyc140Qyc141Qyc142Qyc143Qyc144Qyc145Qyc146Ryc147Qyc148Qyc149Qyc150Qyc151Qyc152Qyc153Qyc154Qyc155Qyc156Qyc157Qyc158Qyc159Qyc160Qyc161Qyc162Qyc163Qyc164Qyc165Qyc166Syc167Qyc168Qyc169Qyc170Qyc171Qyc173Qyc174Qyc175Qyc176Qyc177Qyc178Qyc179Qyc180Qyc181Ryc182Qyc183Qyc184Qyc185Qyc186Qyc187Qyc188Ryc189Qyc190Qyc191Qyc192Qyc193Qyc194Qyc195Qyc196Qyc197Qyc198Qyc199Qyc200Qyc201Qyc202Qyc203Qyc204Qyc205Qyc206Qyc207Qyc208Qyc209Qyc210Qyc211Qyc212Qyc213Qyc214Qyc215Qyc216Qyc217Qyc218Qyc219Qyc220Qyc221Qyc222Qyc223Syc224Qyc225Qyc226Qyc227Qyc228Qyc229Qyc230Qyc231Qyc232Qyc233Qyc234Qyc235Qyc236Qyc237Qyc238Qyc239Syc240Qyc241Qyc242Ryc243Qyc244Qyc245Qyc246Qyc247Qyc248Qyc249Qyc250Qyc251Qyc252Qyc253Qyc254Qyc255Qyc256Qyc257Qyc258Qyc259Qyc260Qyc261Syc262Qyc263Qyc264Qyc265Qyc266Qyc267Qyc268Qyc269Qyc270Qyc271Qyc272Qyc273Qyc274Qyc275Qyc276Syc277Syc278Qyc279Qyc280Qyc281Syc282Qyc283Qyc284Qyc285Qyc286Qyc287Qyc288Qyc289Qyc290Qyc291Qyc292Qyc293Qyc294Qyc295Qyc296Qyc297Qyc298Qyc299Qyc300Qyc301Qyc302Syc303Qyc304Qyc305Qyc306Qyc307Qyc308Qyc309Qyc310Qyc311Syc312Qyc314Syc315Qyc316Qyc317Qyc318Qyc319Syc320Syc321Syc322Qyc323Qyc324Qyc325Syc326Qyc327Qyc328Qyc329Qyc330Qyc331Qyc332Qyc333Syc334Syc335Syc336Qyc337Qyc338Qyc339Qyc340Qyc341Qyc342Qyc343Qyc344Syc345Qyc346Qyc347Qyc348Qyc349Qyc350Qyc351Syc352Qyc353Qyc354Qyc355Syc356Qyc358Qyc359Qyc360Qyc361Syc362Qyc363Qyc364Qyc365Qyc366Syc367Syc368Qyc369Syc371Qyc372Qyc373Qyc374Qyc375Qyc376Qyc377Qyc378Qyc379Qyc380Qyc381Qyc382Qyc383Syc384Syc385Syc386Qyc387Qyc388Qyc389Qyc390Qyc391Syc392Syc393Qyc394Qyc395Syc396Syc397Syc398Syc399Syc400Syc401Syc402Syc403Q>vddocs2vddocs<va1:yddate%,")Mxcdirjpost/2024/xbid `c4dba56f2db4851cd31b561d92dc5e35xdlangbjayglastmod%,")Mxipermalink!Ghttps://blog.johtani.info/blog/2024/01/25/kagome-bot-as-a-user-service/xkpublishdate T2024-01-25T09:30:53Zxgsummary!H日常でよく、形態素解析したくなることがありますよね？ そして、Slackも日常的に立ち上がってますよね？ ということは、Slackのボットとしてwdtags1xpbgoxetitle Tkagome-botのユーザーサービス化va2:yddate%$4Axcdirjpost/2023/xbid `d869fb48cb9acba03dc639481524ee80xdlangbjayglastmod%$4Axipermalink vhttps://blog.johtani.info/blog/2023/12/31/review-2023/xkpublishdate T2023-12-31T07:49:21Zxgsummary!H今年も振り返りブログをリビングで書いています（ドミノ倒しすごいな）。 FMVのキーボードで書いているのでタイポがつらい。。。 振り返り（2022wdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2023）va3:yddate%1!pxcdirjpost/2023/xbid `476e17b6f854414033d5cec1470774eexdlangbjayglastmod%1!pxipermalink!Bhttps://blog.johtani.info/blog/2023/12/15/introduce-orama-to-blog/xkpublishdate Y2023-12-15T00:00:00+09:00xgsummary!Xこの記事は、情報検索・検索技術 Advent Calendar 2023の15日目の記事です。 昨年に続き2回目の情報検索のAdvent Calendar参戦です。 今年は、夏wdtags2xpeoramafsearchxetitle ZOramaという検索エンジンでブログ検索を作ってみたva4:yddate%7pxcdirjpost/2023/xbid `516a7aa07f8faa6b7aa38beb5010cf8cxdlangbjayglastmod%7pxipermalink xhttps://blog.johtani.info/blog/2023/12/08/smarthome-bot/xkpublishdate Y2023-12-08T00:00:00+09:00xgsummary!GPySpaアドベントカレンダーの12/08のエントリーです。昨日は渋川さんのアンラーニングで失敗した話でした。 私は、今年は昨年の続きっぽい話wdtags3xpdmiscemusiccbotxetitle QGoでSlackのボットを作った話va5:yddate%=Hxcdirjpost/2023/xbid `7f78b02c531f09602ba4e140132d26a2xdlangbjayglastmod%=Hxipermalink!Chttps://blog.johtani.info/blog/2023/09/25/read-search-raking-guide/xkpublishdate T2023-09-25T03:32:24Zxgsummary!H「機械学習による検索ランキング改善ガイド」を読みました。 著者の鈴木さんより献本いただいたのを読み終わったのでレビューと、あとおまけです。 紹介wdtags2xpb読書melasticsearchxetitle Y機械学習による検索ランキング改善ガイドを読みましたva6:yddate$9'|xcdirjpost/2023/xbid `8f58cbe5f2ce85c22569af765de3f8d3xdlangbjayglastmod$9'|xipermalink!Bhttps://blog.johtani.info/blog/2023/08/23/search-ui-and-searchkit/xkpublishdate T2023-08-23T05:32:44Zxgsummary!H趣味？（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書いています。 ベクトル検索などの確認なども含めて、Jupyter Nwdtags3xpisearchkitisearch-uib画面xetitle Xsearch-UIとSearchkitと検索画面va7:yddate$0ixcdirjpost/2023/xbid `f9e847ee886bdb9ab5583eeb6eabbd51xdlangbjayglastmod$0ixipermalink!Ihttps://blog.johtani.info/blog/2023/07/27/container-name-in-devcontainer/xkpublishdate T2023-07-27T01:22:49Zxgsummary!Gいくつかある環境をDev Containerで動くように変えていますが、最初に導入した時に疑問点だった「コンテナ名」について解消したのでメモをwdtags1xpmdev containerxetitle _VS CodeとDev Container(コンテナ名の指定)va8:yddate$/$Hxcdirjpost/2023/xbid `7884b62c561b999b9358d52779a18218xdlangbjayglastmod$/$Hxipermalink!Nhttps://blog.johtani.info/blog/2023/07/24/introduce-dev-container-to-hugo-env/xkpublishdate T2023-07-24T09:10:32Zxgsummary!Hこのブログの生成には、Hugoを利用しています。 ブログ移行日記（その1）に書いてありますが、当時はbrewでインストールしていました。 また、wdtags2xpdhugomdev containerxetitle Xブログ記述環境としてのDev Containerva9:yddate$/!(`xcdirjpost/2023/xbid `ed431877ce11fe403fee77f7d26ce637xdlangbjayglastmod$/!(`xipermalink!Lhttps://blog.johtani.info/blog/2023/07/24/move-distribution-to-another-disk/xkpublishdate T2023-07-24T06:28:48Zxgsummary!HWSL2にUbuntuを入れて、開発とかはこちらを利用しています。 また、Docker DesktopもWSL2のバックエンドエンジンを利用してwdtags2xpcwslgwindowsxetitle UWSL2のディストリビューションの環境移行vb10:yddate$..zxcdirjpost/2023/xbid `086b4fd5f77021a0a2aa6b0e90061486xdlangbjayglastmod$..zxipermalink!Nhttps://blog.johtani.info/blog/2023/07/21/multi-containers-with-dev-container/xkpublishdate Y2023-07-21T10:13:30+09:00xgsummary!J前回の記事で、VS Code＋Dev Containerを導入しました。 残課題として「マルチコンテナ化」があるという話もしました。今回はDev Cwdtags2xpfpythonmdev containerxetitle kVS CodeとDev Container（docker-compose.yml対応）vb11:yddate$+?#kxcdirjpost/2023/xbid `a12474027c91fad5a861aa9919817d72xdlangbjayglastmod$+?#kxipermalink!Nhttps://blog.johtani.info/blog/2023/07/13/introduce-vs-code-and-dev-container/xkpublishdate Y2023-07-13T22:15:23+09:00xgsummary!G前回の記事で、pre-commitとPyCharmとWindowsの組み合わせで困っていることを書きました。 これについて、知り合いとチャットwdtags2xpfpythonmdev containerxetitle ^VS CodeとDev Containerの導入（まだ途中）vb12:yddate$*6dxcdirjpost/2023/xbid `698cf3cbd796161d82c9ac438ebab5d2xdlangbjayglastmod$*6dxipermalink!@https://blog.johtani.info/blog/2023/07/10/pre-commit-and-python/xkpublishdate Y2023-07-10T10:55:48+09:00xgsummary!G最近、趣味（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書き始めました。 きちんとPythonのプログラムをプロジェクトwdtags1xpfpythonxetitle ^pre-commitとvenvとPyCharm（困ったな？）vb13:yddate$$uxcdirjpost/2023/xbid `9335522f4c8dbc7256a42a091e6e00bcxdlangbjayglastmod$$uxipermalink!Ghttps://blog.johtani.info/blog/2023/06/21/attend-berlin-buzzwords-2023/xkpublishdate Y2023-06-21T01:30:45+09:00xgsummary!N今年もこの季節がやってきました。 Berlin Buzzwordsにオンラインで出張してました。 今年もハイブリッド開催をしてくれたので、オンラインで参加でwdtags2xpjconferenceobelin buzzwordsxetitle ^今年もオンラインでBerlin Buzzwordsに参加したvb14:yddate#,
<\xcdirjpost/2022/xbid `df30d810068e4656498e5972c6de7e3dxdlangbjayglastmod#,
<\xipermalink vhttps://blog.johtani.info/blog/2022/12/31/review-2022/xkpublishdate Y2022-12-31T20:38:04+09:00xgsummary!H今年もなんとか振り返りブログを書いてます（時間大丈夫かな？w）。紅白をリアタイで見ながら。 振り返り（2021年に書いた抱負から） まずは振り返wdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2022）vb15:yddate#&Vxcdirjpost/2022/xbid `67c2ae6761e89be0fa66db9623b40d30xdlangbjayglastmod#&Vxipermalink!Chttps://blog.johtani.info/blog/2022/12/15/music-server-on-mac-mini/xkpublishdate Y2022-12-15T00:05:58+09:00xgsummary!HPySpaアドベントカレンダーの12/15のエントリーです。昨日はtaichiさんでした。 今年はDIYではなく、PCにまつわる話を。 仕事中はwdtags2xpdmiscemusicxetitlei仕事中のBGM環境vb16:yddate#$ 6]xcdirjpost/2022/xbid `9693a1e77dee5785b1dc61ccffd2e906xdlangbjayglastmod#$ 6]xipermalink!Ahttps://blog.johtani.info/blog/2022/12/09/open-search-serverless/xkpublishdate Y2022-12-09T01:15:25+09:00xgsummary!V本記事は情報検索・検索技術 Advent Calendar 2022の9日目の記事です。 だいぶ間が空いてしまいましたが、日本語のオートコンプリートに関する記事の続きです。wdtags2xpmelasticsearchjopensearchxetitle lElasticsearchのアーキテクチャとStateless / Serverlessvb17:yddate"<13Zxcdirjpost/2022/xbid `73279888a8fe482c836fb19ca23318dcxdlangbjayglastmod"<13Zxipermalink https://blog.johtani.info/blog/2022/08/10/jp-auto-completion-2/xkpublishdate Y2022-08-10T11:50:02+09:00xgsummary!G前回は日本語用オートコンプリートのためのAnalyzerとして、どうやって使うのかを簡単に紹介しました。 今回はもう少し、いろんなパターンを試wdtags2xpmelasticsearchflucenexetitle kローマ字入力のゆれと読み（JapaneseCompletionAnalyzerその2）vb18:yddate"< rxcdirjpost/2022/xbid `6639ec6f88c4976f8ca20fa840f169e3xdlangbjayglastmod"< rxipermalink!Chttps://blog.johtani.info/blog/2022/08/09/japanese-auto-completion/xkpublishdate Y2022-08-09T16:00:02+09:00xgsummary!F風のうわさで、日本語用のオートコンプリートのためのTokenFilterとAnalyzerがLuceneに取り込まれたと聞きました（LUCEwdtags2xpflucenemelasticsearchxetitle Y日本語用オートコンプリートのためのAnalyzervb19:yddate";
/bxcdirjpost/2022/xbid `167a7c9d579ce6f2cebf64a6f6329ecbxdlangbjayglastmod";
/bxipermalink!Dhttps://blog.johtani.info/blog/2022/08/05/upgrade-hugo-accidentally/xkpublishdate Y2022-08-05T17:59:14+09:00xgsummary!FHugoを0.84から0.92にアップデートをする際に、これまでのブログ記事やレイアウトファイルを修正したので個人的にメモを残しておきます。wdtags1xpdhugoxetitlemHugoをアップデートしたvb20:yddate"5:#jxcdirjpost/2022/xbid `3384ea6bb47d70f8ca94b4510813f36axdlangbjayglastmod"5:#jxipermalink ~https://blog.johtani.info/blog/2022/07/20/querqy-architecture/xkpublishdate Y2022-07-20T16:04:10+09:00xgsummary!G今回はQuerqyのElasticsearchのプラグインがどんなつくりになっているか？をちょっとだけ調べてみました。 SolrでもElastwdtags1xpmelasticsearchxetitle VQuerqyの調査（その2：アーキテクチャ）vb21:yddate"567{xcdirjpost/2022/xbid `779e444b4bc720a9eed97f19c41e8773xdlangbjayglastmod"567{xipermalink whttps://blog.johtani.info/blog/2022/07/20/intro-querqy/xkpublishdate Y2022-07-20T11:52:43+09:00xgsummary!FQuerqyというクエリのリライト用のプラグインがあるのでどんなものかを調べてみました。とりあえずは概要をドキュメントから追いかけてみた感じwdtags1xpmelasticsearchxetitlenQuerqyの調査（その１）vb22:yddate"*>_xcdirjpost/2022/xbid `f56c19442484b3e4f47875b58b3f72b2xdlangbjayglastmod"*>_xipermalink!Hhttps://blog.johtani.info/blog/2022/06/15/ttend-berlin-buzzwords-online/xkpublishdate Y2022-06-15T18:00:15+09:00xgsummary!H今年もBerlin Buzzwordsにオンライン出張してました。 今年はハイブリッドな開催だったようで、現地で再開している人もいるようでした。wdtags2xpjconference Pberlin buzzwordsxetitle ^今年もオンラインでBerlin Buzzwordsに参加したvb23:yddate")19Vxcdirjpost/2022/xbid `5eebdf85fd1726db301194bfeeee4377xdlangbjayglastmod")19Vxipermalink!Hhttps://blog.johtani.info/blog/2022/06/13/new-elasticsearch-java-client/xkpublishdate Y2022-06-13T20:24:06+09:00xgsummary!G7.16で正式リリースされましたが、Elasticsearchの新しいJavaのクライアントが出ています。 使ってみたので、ちょっとだけ紹介でwdtags2xpmelasticsearchdjavaxetitle [Elasticsearchの新しいJavaクライアントvb24:yddate"!	 Yxcdirjpost/2022/xbid `7cc21814165879f72529e91682ece5c6xdlangbjayglastmod"!	 Yxipermalink!Phttps://blog.johtani.info/blog/2022/05/18/index-alias-in-azure-cognitive-search/xkpublishdate Y2022-05-18T15:54:17+09:00xgsummary!VAzure Cognitive Searchで2月に新しい機能が公開されました。 「Index Alias」（インデックスの別名）です。まだ、パブリックプレビューの段階ですwdtags1xplazure searchxetitle hインデックスエイリアス - Azure Cognitive Searchの新機能vb25:yddate!7*nxcdirjpost/2022/xbid `0645bdb1cdf88ec74288d503eb71839cxdlangbjayglastmod!7*nxipermalink!Rhttps://blog.johtani.info/blog/2022/01/12/reading-xmc-for-semantic-search-in-prod/xkpublishdate Y2022-01-12T18:41:02+09:00xgsummary"D年末までに知り合いと次の論文を読んだので軽くまとめておきます。 Extreme Multi-label Learning for Semantic Matching in Product Search なんで読んだの？ 前回読んだ理由と一緒ですが、Semanticwdtags2xpfsearchepaperxetitle!MExtreme Multi-label Learning for Semantic Matching in Product Searchという論文を読んだvb26:yddate!30oxcdirjpost/2021/xbid `104b8ee17a8bf1f7043d236659680493xdlangbjayglastmod!30oxipermalink |https://blog.johtani.info/blog/2021/12/31/looking-back-2021/xkpublishdate Y2021-12-31T22:29:19+09:00xgsummary!H今年も振り返りブログです。録画した紅白をオッかけ再生して気になるアーティストだけ見ながら書ています。 振り返り（2020年に書いた抱負から） まwdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2021）vb27:yddate!3	xxcdirjpost/2021/xbid `218e2c36d5945ece02fdc55d6cbcbc38xdlangbjayglastmod!3	xxipermalink xhttps://blog.johtani.info/blog/2021/12/29/best-buy-2021/xkpublishdate Y2021-12-29T22:28:24+09:00xgsummary!G2021年もあと少しですが、今年買って良かったものをリストアップしておこうかと思います。 今年買ったといいながら、昨年このネタを書くといいつつwdtags1xpdmiscxetitlen2021年かって良かったものvb28:yddate!0)
gxcdirjpost/2021/xbid `f0fdc140e18514362a4e52376a6fecbaxdlangbjayglastmod!0)
gxipermalink!Ghttps://blog.johtani.info/blog/2021/12/22/azure-search-schema-json2csv/xkpublishdate Y2021-12-22T11:54:31+09:00xgsummary!UAzure Cognitive Searchのスキーマの確認をするときに、Azureのポータルでは次のようにフィールドの一覧として見ることができます。 ただ、実際のインデwdtags2xplazure searchdmiscxetitle rAzure Cognitive SearchのIndex Schema JSONをCSVで見たくなるvb29:yddate!+7pxcdirjpost/2021/xbid `26e44dfd16a2963d4c18e99806c26fd7xdlangbjayglastmod!+7pxipermalink zhttps://blog.johtani.info/blog/2021/12/08/controller-rack/xkpublishdate Y2021-12-08T00:00:00+09:00xgsummary!W今年もアドベントカレンダーの季節になってしまいました。 今年で2回目となる、pyspa Advent Calendar 2021の投稿です。 昨年に引き続きDIYがらみの投稿wdtags2xphDIYキーボードdmiscxetitle V今年のDIYキーボードとコントローラーラックvb30:yddate!"5&\xcdirjpost/2021/xbid `35200cbf0b5b45d7f5f0b343cb18868bxdlangbjayglastmod!"5&\xipermalink!Mhttps://blog.johtani.info/blog/2021/11/10/reading-ms-biomedical-search-paper/xkpublishdate Y2021-11-10T14:33:16+09:00xgsummary"WDomain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだので軽くメモを残しておきます。論文自体はリンクから参照してください。 読んだ理由 Azure Cognitive Swdtags2xpfsearchepaperxetitle!]Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだvb31:yddate ;/gxcdirjpost/2021/xbid `10a7f69bd03d2632722300194f01e93dxdlangbjayglastmod ;/gxipermalink |https://blog.johtani.info/blog/2021/07/13/attend-mices-2021/xkpublishdate Y2021-07-13T16:08:23+09:00xgsummary!I今年もMICESにも参加してました。 昨年はBerlin Buzzwordsと共同開催でしたが、今年は別開催（別日程）でした。 MICESは201wdtags3xpjconference Pberlin buzzwordseMICESxetitle S今年もMICESにオンライン出張してたvb32:yddate 9?'Excdirjpost/2021/xbid `59b7b60e6bbf4858d72643d22ad90451xdlangbjayglastmod 9?'Exipermalink!Bhttps://blog.johtani.info/blog/2021/07/09/berlin-buzzwords-2021-1/xkpublishdate Y2021-07-09T16:24:53+09:00xgsummary!I今年もBerlin Buzzwordsにオンライン出張してました。 今年の開催は6月14日から17日まででした。 どんなカンファレンスなのかは昨年wdtags2xpjconference Pberlin buzzwordsxetitle ^今年もBerlin Buzzwordsにオンライン出張してたvb33:yddate 7Wxcdirjpost/2021/xbid `43caef5d41c4e74826e4a8d82088739dxdlangbjayglastmod 7Wxipermalink!Thttps://blog.johtani.info/blog/2021/07/01/semantic-search-in-azure-cognitive-search/xkpublishdate Y2021-07-01T18:09:43+09:00xgsummary!WAzure Cognitive Searchで新機能「Semantic Search（セマンティック検索）」という機能の日本語対応が発表されました。 実際にはPublic Pwdtags1xplazure searchxetitle pAzure Cognitive Searchの新機能、Semantic Searchを試してみたvb34:yddate "-Txcdirjpost/2021/xbid `f4baa43cc7ca712d83b99a794c4e2dbdxdlangbjayglastmod "-Txipermalink!Ahttps://blog.johtani.info/blog/2021/04/30/build-lunakey-mini-ble/xkpublishdate Y2021-04-30T00:26:12+09:00xgsummary!MSofle v2を長らく使っていましたが、コンパクトなのもやっぱりいいよなぁというときにKochi KeyboardからLunakey Miniが発売してwdtags2xphDIYキーボードdmiscxetitle mLunakey Miniを組み立てて、BLE+LPME-IO化してみた #DIYキーボードvb35:yddate -0gxcdirjpost/2021/xbid `f41d4fde94cbd7bbd28808dc080a2019xdlangbjayglastmod -0gxipermalink uhttps://blog.johtani.info/blog/2021/04/05/intro-marp/xkpublishdate Y2021-04-05T18:45:11+09:00xgsummary!Iみなさんは、スライドの作成には何を使っていますか？ Keynote？Powerpoint？Google Slides？ 私は、Macでスライドを作wdtags1xpc勉強会xetitle Sスライド作成の環境をMarpにしてみたvb36:yddate ~xcdirjpost/2021/xbid `ce426b7f3190c8a4a47d45ac799e91a4xdlangbjayglastmod ~xipermalink https://blog.johtani.info/blog/2021/03/31/search-tech-jp-slack/xkpublishdate Y2021-03-31T23:28:14+09:00xgsummary!H新型コロナウィルスの影響もあり、オフラインで集まって勉強会も開催できなくなっています。 検索技術勉強会も、もう1年以上開催できていないです。 スwdtags1xpc勉強会xetitle ^検索技術に関する情報交換を目的としたSlackができました！vb37:yddate 3%uxcdirjpost/2021/xbid `eced95e5f301a8340e83d81d3c0d5c0dxdlangbjayglastmod 3%uxipermalink!Chttps://blog.johtani.info/blog/2021/03/03/phrase-query-in-japanese/xkpublishdate Y2021-03-03T16:23:33+09:00xgsummary!UAzure Cognitive SearchにはOData式という書式で条件が書ける仕組みがあります。 ODataは検索条件（$filter）やソート条件（$orderbwdtags2xplazure searchmelasticsearchxetitle [OData式と日本語の検索(NGram)とフレーズ検索vb38:yddate 
7fxcdirjpost/2021/xbid `fcb0105fa6b5777a133f247784b9d930xdlangbjayglastmod 
7fxipermalink!Bhttps://blog.johtani.info/blog/2021/02/25/update-working-facility/xkpublishdate Y2021-02-25T18:43:02+09:00xgsummary!G自宅の環境がいろいろと変わったのですが、書いていなかったので更新版です。 前回のブログ(2020/09)、前々回のブログ(2020/03)はそwdtags1xpdmiscxetitle P自宅の作業環境(2021/02)vb39:yddate pxcdirjpost/2021/xbid `931b2ebd9bfaeb5dcf1973e724a1f8d0xdlangbjayglastmod pxipermalink!Shttps://blog.johtani.info/blog/2021/02/05/autocomplete-and-suggest-on-azure-search/xkpublishdate Y2021-02-05T17:52:00+09:00xgsummary!UAzure Cognitive SearchにSuggestやAutocompleteの機能があるのを見つけたので、どんな挙動なのかを調べてログとして残しておきます。 公wdtags1xplazure searchxetitle kAzure Cognitive Searchでオートコンプリートやサジェストをしてみるvb40:yddate :|xcdirjpost/2021/xbid `aa61b4543e8a7c67fccabee27a6e99cdxdlangbjayglastmod :|xipermalink!Phttps://blog.johtani.info/blog/2021/02/04/reading-elements-of-computing-systems/xkpublishdate Y2021-02-04T16:40:44+09:00xgsummary!Gオライリー・ジャパンから出ている「コンピュータシステムの理論と実装」を読み始めたのでメモを取ることに。 原著はオライリーじゃないのかというのがwdtags2xpb輪読kNand2Tetrisxetitle e「コンピュータシステムの理論と実装」を読み始めた #Nand2Tetrisvb41:yddate ,&Jxcdirjpost/2021/xbid `d95522c691013bfe66dd46ded85a98edxdlangbjayglastmod ,&Jxipermalink }https://blog.johtani.info/blog/2021/02/01/apply-ble-to-sofle/xkpublishdate Y2021-02-01T00:15:22+09:00xgsummary!QCorne使ってましたが、数字キーがあるとどうなのかな？というのがやはり気になって。 そこに、Kochi KeyboardさんからSofle Keyboard vwdtags2xphDIYキーボードdmiscxetitle iSofle v2を組み立てて、BLE+LPME-IO化してみた #DIYキーボードvb42:yddate>;,Wxcdirjpost/2021/xbid `4ad8239a37f641bcd17abeb96106314exdlangbjayglastmod>;,Wxipermalink!Fhttps://blog.johtani.info/blog/2021/01/11/apply-ble-and-lpme-to-corne/xkpublishdate Y2021-01-11T11:42:31+09:00xgsummary!FメインマシンとMacは下記のサンワサプライのUSB接続のKVMスイッチを使っていますが、もう一台ノートPCがありここに接続しているCornewdtags2xphDIYキーボードdmiscxetitle fCorne Light v2のBLE+LPME-IO対応 #DIYキーボードvb43:yddate;~xcdirjpost/2020/xbid `64a421c2367372c3199c66a6420faf89xdlangbjayglastmod;~xipermalink qhttps://blog.johtani.info/blog/2020/12/31/diy-pc/xkpublishdate Y2020-12-31T22:48:46+09:00xgsummary!H振り返りブログにも書きましたが、デスクトップPCを自作(DIY)しました。 組み立てたに使ったパーツのアフィリンクを貼っておきます。 10月くらwdtags1xpdmiscxetitlejPCもDIYしましたvb44:yddate;txcdirjpost/2020/xbid `a5b2ee641e10d3e4db8f888217ab9eccxdlangbjayglastmod;txipermalink |https://blog.johtani.info/blog/2020/12/31/looking-back-2020/xkpublishdate Y2020-12-31T18:13:24+09:00xgsummary!H今年も振り返りブログ書いてます。カタンの航海者版を購入して家族とやってましたが、負けてしまいました。 振り返り（2019年に書いた抱負から） まwdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2020）vb45:yddate67{xcdirjpost/2020/xbid `c6fc88bd57a0e57ddf22e2eb1bef892cxdlangbjayglastmod67{xipermalink |https://blog.johtani.info/blog/2020/12/17/index_template_v2/xkpublishdate Y2020-12-17T23:55:55+09:00xgsummary!~Elastic stack (Elasticsearch) Advent Calendar 2020の18日目の記事になります。 本日の勉強会でLTをしましたが、しゃべり足りなかったんで。 Elasticsearch 7.8でこっそりとリリースされたIwdtags1xpmelasticsearchxetitle QIndex Template V2vb46:yddate2
 Xxcdirjpost/2020/xbid `a46c601d03a3a26bc418d0096fe83a42xdlangbjayglastmod2
-Xxipermalink {https://blog.johtani.info/blog/2020/12/03/build_corne_choc/xkpublishdate Y2020-12-03T23:13:44+09:00xgsummary!Wはじめまして、pyspa。 ということで、pyspa Advent Calendar 2020の4日目(大谷コンビの2号)の投稿になります。 コンビそろってキーボード記事ですwdtags2xphDIYキーボードdmiscxetitle _Corne Chocolateを組み立てた #DIYキーボードvb46:yddate(,gxcdirjpost/2020/xbid `b16bddd1a6d3e5f4136446bebe7ffbc7xdlangbjayglastmod(,gxipermalink https://blog.johtani.info/blog/2020/11/05/build-corne-light-v2/xkpublishdate Y2020-11-05T00:25:27+09:00xgsummary!L前回のブログのまとめに書いたように、セパレートタイプのキーボードであるCorne Light v2を作成したのでそのビルドログです。DIYキーボードとしwdtags2xphDIYキーボードdmiscxetitle ]Corne Light v2を作成した #DIYキーボードvb47:yddate#+Nxcdirjpost/2020/xbid `188c1ee5132a6752dfce5a0235354070xdlangbjayglastmod#+Nxipermalink ~https://blog.johtani.info/blog/2020/10/18/restart-windows-no1/xkpublishdate Y2020-10-18T23:01:50+09:00xgsummary!Gヒゲが不評だったのでいつも通りの長さに切りました。 前回「Windowsをお試し中」と書きましたが、いくつかソフトをインストールしたりしたのでwdtags2xpdmiscgwindowsxetitle PWindowsへの移行（その１）vb48:yddate!:8Rxcdirjpost/2020/xbid `de37d9fae011687eb1eb5a127fcb89e3xdlangbjayglastmod!:8Rxipermalink zhttps://blog.johtani.info/blog/2020/10/15/restart-windows/xkpublishdate Y2020-10-15T11:04:02+09:00xgsummary!Gヒゲが伸びてきて(試しに伸ばしてる)不評を買っている今日このごろです。 自宅で作業することが多くなってきたので、自作PCでもと思っていますが、wdtags2xpdmiscgwindowsxetitlelWindowsをお試し中vb49:yddate 11fxcdirjpost/2020/xbid `c377351433a941a927aab543931f6026xdlangbjayglastmod 11fxipermalink whttps://blog.johtani.info/blog/2020/10/11/build-dozen0/xkpublishdate Y2020-10-11T23:53:26+09:00xgsummary!G今年の春くらいから、セパレートタイプのキーボードが気になっています。 また、なんか知らないですが、Twitterのタイムラインが自作キーボードwdtags2xphDIYキーボードdmiscxetitle UDozen0を作成した #DIYキーボードvb50:yddate(bxcdirjpost/2020/xbid `15932a656f7acfac897d27766eadc9e2xdlangbjayglastmod(bxipermalink zhttps://blog.johtani.info/blog/2020/10/05/switch-fst-2-da/xkpublishdate Y2020-10-05T11:36:18+09:00xgsummary!^2020/10/06 11:00くらいにマージされました。 @minoru_osuka さんが開発を引き継いだLinderaというKuromojiのRustクローンがあります(リポジトリ)wdtags2xpdRustgLinderaxetitle aLinderaのFSTをDoubleArrayTrieに変更した話vb51:yddatefxcdirjpost/2020/xbid `b2c4cf0fb96d02d37f03668caaecbc57xdlangbjayglastmodfxipermalink }https://blog.johtani.info/blog/2020/09/15/improve-search-no3/xkpublishdate Y2020-09-15T11:23:34+09:00xgsummary!G先日は「検索システムを構成するパーツ」ということで検索システムを構成しているパーツについて書いてみました。 大体、検索がうまくヒットしないといwdtags1xpb検索xetitle `検索対象のデータとデータソース(検索システムに関する妄想その3)vb52:yddate.&uxcdirjpost/2020/xbid `d08a3fdc040bbbdd81c9927ce296318cxdlangbjayglastmod.&uxipermalink!Bhttps://blog.johtani.info/blog/2020/09/08/update-working-facility/xkpublishdate Y2020-09-08T11:17:25+09:00xgsummary!G自宅環境に少しアップデートがあったので更新版です。 お客さんのおかげで相変わらず自宅で作業させてもらってるのもあり、昨今のコロナウイルスの影響wdtags1xpdmiscxetitle P自宅の作業環境(2020/09)vb53:yddate#>\xcdirjpost/2020/xbid `827de2d7a9d231f6bcb44caf35896c1fxdlangbjayglastmod#>\xipermalink {https://blog.johtani.info/blog/2020/09/07/intro-metered-rs/xkpublishdate Y2020-09-07T23:11:40+09:00xgsummary!HRustで便利なクレートを見つけたので、紹介がてら、自分のメモのためにブログに残しておきます。 そもそもの問題 Rustで処理を書いていて、なんwdtags1xpdRustxetitlenmeteredクレートの紹介vb54:yddate cxcdirjpost/2020/xbid `3c5d4d351e0fb9e33e0e8b6d1d43c0f2xdlangbjayglastmod cxipermalink }https://blog.johtani.info/blog/2020/09/07/reboot-nlp100-ch04/xkpublishdate Y2020-09-07T11:17:07+09:00xgsummary!KRustで言語処理100本ノックの第4章です。 前回はこちら。 今回は早めに続きをやりました。 「形態素解析」ですしね。 第4章の概要 吾輩は猫であるwdtags2xpdRustfnlp100xetitle V第4章終了(言語処理100本ノック2020)vb55:yddate%
Axcdirjpost/2020/xbid `eb2a5824e03996c1966bee38866ce349xdlangbjayglastmod%
Axipermalink }https://blog.johtani.info/blog/2020/09/04/reboot-nlp100-ch03/xkpublishdate Y2020-09-04T23:46:25+09:00xgsummary!IRustで言語処理100本ノックの第3章です。 前回はこちら。 少し間が空きましたが、再開しました。 間が空いた理由は。。。「正規表現」ですかね。wdtags2xpdRustfnlp100xetitle V第3章終了(言語処理100本ノック2020)vb56:yddate9;Wxcdirjpost/2020/xbid `f5effd616a3f8db6193b482caec37912xdlangbjayglastmod9;Wxipermalink!Fhttps://blog.johtani.info/blog/2020/08/18/azure-search-with-terraform/xkpublishdate Y2020-08-18T18:26:47+09:00xgsummary!Q負荷を計測するために、数回、Azure Cognitive Searchのクラスターを起動したり、停止したりしてました。 これは、Terraformでやると楽できwdtags1xplazure searchxetitle iTerraformでAzure Cognitive Searchのクラスターを起動vb57:yddate93Rxcdirjpost/2020/xbid `11a61827e80739a6065960eb188d5758xdlangbjayglastmod93Rxipermalink }https://blog.johtani.info/blog/2020/07/28/improve-search-no2/xkpublishdate Y2020-07-28T12:34:42+09:00xgsummary!H先日は「システムの特徴と検索機能について」という感じでふんわり書きました。 まぁ、頭の中でぼんやり考えてることを文章にしてみた感じです。 他にもwdtags1xpb検索xetitle _検索システムを構成するパーツ(検索システムに関する妄想その2)vb58:yddate)9Vxcdirjpost/2020/xbid `9da845cd31310b8952efd1be1881e651xdlangbjayglastmod)9Vxipermalink }https://blog.johtani.info/blog/2020/07/27/improve-search-no1/xkpublishdate Y2020-07-27T18:28:54+09:00xgsummary!G今年の頭からシステムの検索周りを手伝う仕事をフリーランスとしてやっています。 検索の仕組みを知れば知るほど面白くなってきたからという理由になるwdtags1xpb検索xetitle aシステムの特徴と検索機能について(検索システムに関する妄想その1)vb59:yddate
.*Jxcdirjpost/2020/xbid `208a8c072ea521c813b86ca7730eb880xdlangbjayglastmod
.*Jxipermalink ~https://blog.johtani.info/blog/2020/07/09/hap15-rust-the-book/xkpublishdate Y2020-07-09T18:59:38+09:00xgsummary"B前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章wdtags3xpdrustb読書mrust-the-bookxetitle TRust the book - 第15章vb60:yddate)lxcdirjpost/2020/xbid `e5cb2e5d501d3db2db5d8f14984a66d4xdlangbjayglastmod)lxipermalink!Bhttps://blog.johtani.info/blog/2020/07/06/attend-berlin-buzzwords/xkpublishdate Y2020-07-06T12:12:44+09:00xgsummary!O6月7日の週に開催されたBerlin Buzzwordsにオンライン出張してました。 Berlin Buzzwordsとは? ベルリンで開催されている、Bigwdtags2xpjconference Pberlin buzzwordsxetitle [Berlin Buzzwordsにオンライン出張してたvb61:yddate=Vxcdirjpost/2020/xbid `bbd2824ff0d5b801bb6f5da3a2a1a888xdlangbjayglastmod=Vxipermalink!Mhttps://blog.johtani.info/blog/2020/06/25/analyzer-perf-test-with-luceneutil/xkpublishdate Y2020-06-25T11:01:58+09:00xgsummary!Sluceneutil - マニアックなツールのセットアップの続きです。 今回も誰得?なブログなので興味ない場合は飛ばしましょう。 一応、luceneutilのREADwdtags1xpflucenexetitle gluceneutil - Analyzer性能テストへのkuromojiの追加vb62:yddate<1uxcdirjpost/2020/xbid `8a1ea5d5cf843bc5955a94cfcc321e92xdlangbjayglastmod<1uxipermalink!@https://blog.johtani.info/blog/2020/06/23/how-to-use-luceneutil/xkpublishdate Y2020-06-23T21:58:29+09:00xgsummary!HLuceneのFSTの修正に関連して、Kuromojiのパフォーマンス問題が出ているようです。 この問題自体はLucene 8.6.0以降で直るwdtags1xpflucenexetitle ]luceneutil - マニアックなツールのセットアップvb63:yddate74/Pxcdirjpost/2020/xbid `82a115ab8d617e4e96813587fe3a6049xdlangbjayglastmod74/Pxipermalink!Ohttps://blog.johtani.info/blog/2020/06/09/difference-analyzers-in-azure-search/xkpublishdate Y2020-06-09T17:44:00+09:00xgsummary!TAzure Cognitive Searchで日本語を扱うときに、形態素解析器を使いたい場合、2種類のAnalyzerが用意されています。今回はこれらの違いがどんなものwdtags2xplazure searchhkuromojixetitle hAzure Cognitive Searchでの日本語向けAnalyzerの違いvb64:yddate6Ixcdirjpost/2020/xbid `e74d071363645a588f858b35231128c4xdlangbjayglastmod6Ixipermalink https://blog.johtani.info/blog/2020/06/04/chap13-rust-the-book/xkpublishdate Y2020-06-04T17:37:29+09:00xgsummary"B前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章wdtags3xpdrustb読書mrust-the-bookxetitle TRust the book - 第13章vb65:yddate37<oxcdirjpost/2020/xbid `163beeae9620c1a6a46a38aa7ebd9663xdlangbjayglastmod37<oxipermalink https://blog.johtani.info/blog/2020/05/28/chap10-rust-the-book/xkpublishdate Y2020-05-28T18:06:55+09:00xgsummary"B前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章wdtags3xpdrustb読書mrust-the-bookxetitle TRust the book - 第10章vb66:yddate3
Wxcdirjpost/2020/xbid `36dd94159e3e60076c0c6098086e255fxdlangbjayglastmod3
Wxipermalink!Ghttps://blog.johtani.info/blog/2020/05/26/logging-azure-search-request/xkpublishdate Y2020-05-26T17:22:47+09:00xgsummary!Z今回はAzure Cognitive SearchのSDKを利用したアプリケーションが、実際にAzure Cognitive Searchに対して送信しているリクエストのパラメータwdtags2xplazure searchd.netxetitle aAzure Cognitive Searchのリクエストのロギングvb67:yddate14
+Xxipermalink {https://blog.johtani.info/blog/2020/12/03/build_corne_choc/xkpublishdate Y2020-12-03T23:13:44+09:00xgsummary!Wはじめまして、pyspa。 ということで、pyspa Advent Calendar 2020の4日目(大谷コンビの2号)の投稿になります。 コンビそろってキーボード記事ですwdtags2xphDIYキーボードdmiscxetitle _Corne Chocolateを組み立てた #DIYキーボードvb47:yddate(,gxcdirjpost/2020/xbid `b16bddd1a6d3e5f4136446bebe7ffbc7xdlangbjayglastmod(,gxipermalink https://blog.johtani.info/blog/2020/11/05/build-corne-light-v2/xkpublishdate Y2020-11-05T00:25:27+09:00xgsummary!L前回のブログのまとめに書いたように、セパレートタイプのキーボードであるCorne Light v2を作成したのでそのビルドログです。DIYキーボードとしwdtags2xphDIYキーボードdmiscxetitle ]Corne Light v2を作成した #DIYキーボードvb48:yddate#+Nxcdirjpost/2020/xbid `188c1ee5132a6752dfce5a0235354070xdlangbjayglastmod#+Nxipermalink ~https://blog.johtani.info/blog/2020/10/18/restart-windows-no1/xkpublishdate Y2020-10-18T23:01:50+09:00xgsummary!Gヒゲが不評だったのでいつも通りの長さに切りました。 前回「Windowsをお試し中」と書きましたが、いくつかソフトをインストールしたりしたのでwdtags2xpdmiscgwindowsxetitle PWindowsへの移行（その１）vb49:yddate!:8Rxcdirjpost/2020/xbid `de37d9fae011687eb1eb5a127fcb89e3xdlangbjayglastmod!:8Rxipermalink zhttps://blog.johtani.info/blog/2020/10/15/restart-windows/xkpublishdate Y2020-10-15T11:04:02+09:00xgsummary!Gヒゲが伸びてきて(試しに伸ばしてる)不評を買っている今日このごろです。 自宅で作業することが多くなってきたので、自作PCでもと思っていますが、wdtags2xpdmiscgwindowsxetitlelWindowsをお試し中vb50:yddate 11fxcdirjpost/2020/xbid `c377351433a941a927aab543931f6026xdlangbjayglastmod 11fxipermalink whttps://blog.johtani.info/blog/2020/10/11/build-dozen0/xkpublishdate Y2020-10-11T23:53:26+09:00xgsummary!G今年の春くらいから、セパレートタイプのキーボードが気になっています。 また、なんか知らないですが、Twitterのタイムラインが自作キーボードwdtags2xphDIYキーボードdmiscxetitle UDozen0を作成した #DIYキーボードvb51:yddate(bxcdirjpost/2020/xbid `15932a656f7acfac897d27766eadc9e2xdlangbjayglastmod(bxipermalink zhttps://blog.johtani.info/blog/2020/10/05/switch-fst-2-da/xkpublishdate Y2020-10-05T11:36:18+09:00xgsummary!^2020/10/06 11:00くらいにマージされました。 @minoru_osuka さんが開発を引き継いだLinderaというKuromojiのRustクローンがあります(リポジトリ)wdtags2xpdRustgLinderaxetitle aLinderaのFSTをDoubleArrayTrieに変更した話vb52:yddatefxcdirjpost/2020/xbid `b2c4cf0fb96d02d37f03668caaecbc57xdlangbjayglastmodfxipermalink }https://blog.johtani.info/blog/2020/09/15/improve-search-no3/xkpublishdate Y2020-09-15T11:23:34+09:00xgsummary!G先日は「検索システムを構成するパーツ」ということで検索システムを構成しているパーツについて書いてみました。 大体、検索がうまくヒットしないといwdtags1xpb検索xetitle `検索対象のデータとデータソース(検索システムに関する妄想その3)vb53:yddate.&uxcdirjpost/2020/xbid `d08a3fdc040bbbdd81c9927ce296318cxdlangbjayglastmod.&uxipermalink!Bhttps://blog.johtani.info/blog/2020/09/08/update-working-facility/xkpublishdate Y2020-09-08T11:17:25+09:00xgsummary!G自宅環境に少しアップデートがあったので更新版です。 お客さんのおかげで相変わらず自宅で作業させてもらってるのもあり、昨今のコロナウイルスの影響wdtags1xpdmiscxetitle P自宅の作業環境(2020/09)vb54:yddate#>\xcdirjpost/2020/xbid `827de2d7a9d231f6bcb44caf35896c1fxdlangbjayglastmod#>\xipermalink {https://blog.johtani.info/blog/2020/09/07/intro-metered-rs/xkpublishdate Y2020-09-07T23:11:40+09:00xgsummary!HRustで便利なクレートを見つけたので、紹介がてら、自分のメモのためにブログに残しておきます。 そもそもの問題 Rustで処理を書いていて、なんwdtags1xpdRustxetitlenmeteredクレートの紹介vb55:yddate cxcdirjpost/2020/xbid `3c5d4d351e0fb9e33e0e8b6d1d43c0f2xdlangbjayglastmod cxipermalink }https://blog.johtani.info/blog/2020/09/07/reboot-nlp100-ch04/xkpublishdate Y2020-09-07T11:17:07+09:00xgsummary!KRustで言語処理100本ノックの第4章です。 前回はこちら。 今回は早めに続きをやりました。 「形態素解析」ですしね。 第4章の概要 吾輩は猫であるwdtags2xpdRustfnlp100xetitle V第4章終了(言語処理100本ノック2020)vb56:yddate%
Axcdirjpost/2020/xbid `eb2a5824e03996c1966bee38866ce349xdlangbjayglastmod%
Axipermalink }https://blog.johtani.info/blog/2020/09/04/reboot-nlp100-ch03/xkpublishdate Y2020-09-04T23:46:25+09:00xgsummary!IRustで言語処理100本ノックの第3章です。 前回はこちら。 少し間が空きましたが、再開しました。 間が空いた理由は。。。「正規表現」ですかね。wdtags2xpdRustfnlp100xetitle V第3章終了(言語処理100本ノック2020)vb57:yddate9;Wxcdirjpost/2020/xbid `f5effd616a3f8db6193b482caec37912xdlangbjayglastmod9;Wxipermalink!Fhttps://blog.johtani.info/blog/2020/08/18/azure-search-with-terraform/xkpublishdate Y2020-08-18T18:26:47+09:00xgsummary!Q負荷を計測するために、数回、Azure Cognitive Searchのクラスターを起動したり、停止したりしてました。 これは、Terraformでやると楽できwdtags1xplazure searchxetitle iTerraformでAzure Cognitive Searchのクラスターを起動vb58:yddate93Rxcdirjpost/2020/xbid `11a61827e80739a6065960eb188d5758xdlangbjayglastmod93Rxipermalink }https://blog.johtani.info/blog/2020/07/28/improve-search-no2/xkpublishdate Y2020-07-28T12:34:42+09:00xgsummary!H先日は「システムの特徴と検索機能について」という感じでふんわり書きました。 まぁ、頭の中でぼんやり考えてることを文章にしてみた感じです。 他にもwdtags1xpb検索xetitle _検索システムを構成するパーツ(検索システムに関する妄想その2)vb59:yddate)9Vxcdirjpost/2020/xbid `9da845cd31310b8952efd1be1881e651xdlangbjayglastmod)9Vxipermalink }https://blog.johtani.info/blog/2020/07/27/improve-search-no1/xkpublishdate Y2020-07-27T18:28:54+09:00xgsummary!G今年の頭からシステムの検索周りを手伝う仕事をフリーランスとしてやっています。 検索の仕組みを知れば知るほど面白くなってきたからという理由になるwdtags1xpb検索xetitle aシステムの特徴と検索機能について(検索システムに関する妄想その1)vb60:yddate
.*Jxcdirjpost/2020/xbid `208a8c072ea521c813b86ca7730eb880xdlangbjayglastmod
.*Jxipermalink ~https://blog.johtani.info/blog/2020/07/09/hap15-rust-the-book/xkpublishdate Y2020-07-09T18:59:38+09:00xgsummary"B前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章wdtags3xpdrustb読書mrust-the-bookxetitle TRust the book - 第15章vb61:yddate)lxcdirjpost/2020/xbid `e5cb2e5d501d3db2db5d8f14984a66d4xdlangbjayglastmod)lxipermalink!Bhttps://blog.johtani.info/blog/2020/07/06/attend-berlin-buzzwords/xkpublishdate Y2020-07-06T12:12:44+09:00xgsummary!O6月7日の週に開催されたBerlin Buzzwordsにオンライン出張してました。 Berlin Buzzwordsとは? ベルリンで開催されている、Bigwdtags2xpjconference Pberlin buzzwordsxetitle [Berlin Buzzwordsにオンライン出張してたvb62:yddate=Vxcdirjpost/2020/xbid `bbd2824ff0d5b801bb6f5da3a2a1a888xdlangbjayglastmod=Vxipermalink!Mhttps://blog.johtani.info/blog/2020/06/25/analyzer-perf-test-with-luceneutil/xkpublishdate Y2020-06-25T11:01:58+09:00xgsummary!Sluceneutil - マニアックなツールのセットアップの続きです。 今回も誰得?なブログなので興味ない場合は飛ばしましょう。 一応、luceneutilのREADwdtags1xpflucenexetitle gluceneutil - Analyzer性能テストへのkuromojiの追加vb63:yddate<1uxcdirjpost/2020/xbid `8a1ea5d5cf843bc5955a94cfcc321e92xdlangbjayglastmod<1uxipermalink!@https://blog.johtani.info/blog/2020/06/23/how-to-use-luceneutil/xkpublishdate Y2020-06-23T21:58:29+09:00xgsummary!HLuceneのFSTの修正に関連して、Kuromojiのパフォーマンス問題が出ているようです。 この問題自体はLucene 8.6.0以降で直るwdtags1xpflucenexetitle ]luceneutil - マニアックなツールのセットアップvb64:yddate74/Pxcdirjpost/2020/xbid `82a115ab8d617e4e96813587fe3a6049xdlangbjayglastmod74/Pxipermalink!Ohttps://blog.johtani.info/blog/2020/06/09/difference-analyzers-in-azure-search/xkpublishdate Y2020-06-09T17:44:00+09:00xgsummary!TAzure Cognitive Searchで日本語を扱うときに、形態素解析器を使いたい場合、2種類のAnalyzerが用意されています。今回はこれらの違いがどんなものwdtags2xplazure searchhkuromojixetitle hAzure Cognitive Searchでの日本語向けAnalyzerの違いvb65:yddate6Ixcdirjpost/2020/xbid `e74d071363645a588f858b35231128c4xdlangbjayglastmod6Ixipermalink https://blog.johtani.info/blog/2020/06/04/chap13-rust-the-book/xkpublishdate Y2020-06-04T17:37:29+09:00xgsummary"B前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章wdtags3xpdrustb読書mrust-the-bookxetitle TRust the book - 第13章vb66:yddate37<oxcdirjpost/2020/xbid `163beeae9620c1a6a46a38aa7ebd9663xdlangbjayglastmod37<oxipermalink https://blog.johtani.info/blog/2020/05/28/chap10-rust-the-book/xkpublishdate Y2020-05-28T18:06:55+09:00xgsummary"B前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章wdtags3xpdrustb読書mrust-the-bookxetitle TRust the book - 第10章vb67:yddate3
Wxcdirjpost/2020/xbid `36dd94159e3e60076c0c6098086e255fxdlangbjayglastmod3
Wxipermalink!Ghttps://blog.johtani.info/blog/2020/05/26/logging-azure-search-request/xkpublishdate Y2020-05-26T17:22:47+09:00xgsummary!Z今回はAzure Cognitive SearchのSDKを利用したアプリケーションが、実際にAzure Cognitive Searchに対して送信しているリクエストのパラメータwdtags2xplazure searchd.netxetitle aAzure Cognitive Searchのリクエストのロギングvb68:yddate14
 qxcdirjpost/2020/xbid `21982f43bc435f22efef22b309a48c66xdlangbjayglastmod14
-qxipermalink!^https://blog.johtani.info/blog/2020/05/22/watching-azure-cognirive-search-session-at-ms-build/xkpublishdate Y2020-05-22T12:10:41+09:00xgsummary!ZMircosoft Buildというイベントが今週ありました(MSの方やお客さんに教えてもらった)。 そこで、Azure Cognitive Searchのセッション(MyBuilwdtags1xplazure searchxetitle yMicrosoft Build(2020)のAzure Cognirive Searchのセッションを見たのでメモvb68:yddate/.mxcdirjpost/2020/xbid `306cecb32320ead508346ad8fed3394dxdlangbjayglastmod/.mxipermalink |https://blog.johtani.info/blog/2020/05/15/elastic-stack-7_7/xkpublishdate Y2020-05-15T11:17:17+09:00xgsummary!HElasticのWorkplace Searchを触ってみています(その1、その2)が、Elastic Stackの7.7.0がリリースされてしwdtags1xpmelastic stackxetitle YElastic Stack 7.7がリリースされたvb69:yddate/
+qxipermalink!^https://blog.johtani.info/blog/2020/05/22/watching-azure-cognirive-search-session-at-ms-build/xkpublishdate Y2020-05-22T12:10:41+09:00xgsummary!ZMircosoft Buildというイベントが今週ありました(MSの方やお客さんに教えてもらった)。 そこで、Azure Cognitive Searchのセッション(MyBuilwdtags1xplazure searchxetitle yMicrosoft Build(2020)のAzure Cognirive Searchのセッションを見たのでメモvb69:yddate/.mxcdirjpost/2020/xbid `306cecb32320ead508346ad8fed3394dxdlangbjayglastmod/.mxipermalink |https://blog.johtani.info/blog/2020/05/15/elastic-stack-7_7/xkpublishdate Y2020-05-15T11:17:17+09:00xgsummary!HElasticのWorkplace Searchを触ってみています(その1、その2)が、Elastic Stackの7.7.0がリリースされてしwdtags1xpmelastic stackxetitle YElastic Stack 7.7がリリースされたvb70:yddate/
 ~xcdirjpost/2020/xbid `1e220a934e16fd941bd804ca03865b60xdlangbjayglastmod/
-~xipermalink ~https://blog.johtani.info/blog/2020/05/14/chap9-rust-the-book/xkpublishdate Y2020-05-14T18:43:26+09:00xgsummary"B前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章wdtags3xpdrustb読書mrust-the-bookxetitle SRust the book - 第9章vb70:yddate.!qxcdirjpost/2020/xbid `09155bf417a93847b538ad607f78cca2xdlangbjayglastmod.!qxipermalink!Dhttps://blog.johtani.info/blog/2020/05/12/reboot-nlp100-ch02-12to19/xkpublishdate Y2020-05-12T12:23:29+09:00xgsummary!IRustで言語処理100本ノックの第2章の残りです。 前回はこちら。 ちなみに、標準入力から受け取る処理は書いてないです。 出力に関してはファイルwdtags2xpdRustfnlp100xetitle ]第2章の12から19まで(言語処理100本ノック2020)vb71:yddate-:`xcdirjpost/2020/xbid `c098c6f0901979bd914ed7a345200f90xdlangbjayglastmod-:`xipermalink!Chttps://blog.johtani.info/blog/2020/05/08/rebootnlp100-ch02-10to11/xkpublishdate Y2020-05-08T23:37:20+09:00xgsummary!I気づいたら1ヶ月サボってました、ごめんなさい。。。 Rustで言語処理100本ノックの第2章をはじめました。 前回はこちら。 確認用のUnixコマwdtags2xpdRustfnlp100xetitle ]第2章の10から11まで(言語処理100本ノック2020)vb72:yddate-4Ixcdirjpost/2020/xbid `2c3270f8797ace2fb37402ea6a09d126xdlangbjayglastmod-4Ixipermalink!Dhttps://blog.johtani.info/blog/2020/05/08/reboot-nlp100-finish-ch01/xkpublishdate Y2020-05-08T16:40:57+09:00xgsummary!kRustで言語処理100本ノックのリファクタリングの続き。 前回はこちら。 とっくに終わってたのに、ブログ書いてなかった。。。 08. 暗号文 pub fn cipher(text: &amp;str) -&gt;wdtags2xpdRustfnlp100xetitle ]第1章の08から09まで(言語処理100本ノック2020)vb73:yddate,7
Rxcdirjpost/2020/xbid `44db1f1fefc97cd28d55d443f2bd2b63xdlangbjayglastmod,7
Rxipermalink!Chttps://blog.johtani.info/blog/2020/05/07/install-workplace-search/xkpublishdate Y2020-05-07T11:32:50+09:00xgsummary!G前回はWorkplace Searchの概要について書きましたが、今回はインストールと構成要素について説明します。なお、2020/5/7時点でwdtags2xpmelasticsearch Pworkplace searchxetitle pElasticのWorkplace Searchを触ってみる - その2 - インストールと起動vb74:yddate*<?@xcdirjpost/2020/xbid `4d71d2a23c85fb7af20e8d1e8b3e0de8xdlangbjayglastmod*<?@xipermalink!Ahttps://blog.johtani.info/blog/2020/05/01/intro-workplace-search/xkpublishdate Y2020-05-01T16:29:04+09:00xgsummary!H2月のElastic社のブログですが、Enterprise Searchとこれまで呼んでいた製品をWorkplace Searchという製品名にwdtags2xpmelasticsearch Pworkplace searchxetitle dElasticのWorkplace Searchを触ってみる - その1vb75:yddate)##oxcdirjpost/2020/xbid `be2c49ea5816e7daa6d3b3ff45353291xdlangbjayglastmod)##oxipermalink!Chttps://blog.johtani.info/blog/2020/04/27/note-updating-dictionary/xkpublishdate Y2020-04-27T10:44:15+09:00xgsummary!G先日、Elasticsearchでのカスタム辞書の利用方法についてブログを書きました。 辞書の設定方法について記載しましたが、今回は辞書の更新wdtags1xpmelasticsearchxetitlem辞書の更新についての注意点vb76:yddate'99Pxcdirjpost/2020/xbid `15357b6978e83daa2d97692c861dc177xdlangbjayglastmod'99Pxipermalink!Fhttps://blog.johtani.info/blog/2020/04/22/custom-dictionary-after-7-4/xkpublishdate Y2020-04-22T10:30:56+09:00xgsummary!HElasticsearchで日本語を扱うときに、カスタム辞書を使いたいという要望がよくあります。 AWSのElasticsearch Serviwdtags1xpmelasticsearchxetitle \Kuromojiのカスタム辞書をインデックスの設定で指定vb77:yddate&
+~xipermalink ~https://blog.johtani.info/blog/2020/05/14/chap9-rust-the-book/xkpublishdate Y2020-05-14T18:43:26+09:00xgsummary"B前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章wdtags3xpdrustb読書mrust-the-bookxetitle SRust the book - 第9章vb71:yddate.!qxcdirjpost/2020/xbid `09155bf417a93847b538ad607f78cca2xdlangbjayglastmod.!qxipermalink!Dhttps://blog.johtani.info/blog/2020/05/12/reboot-nlp100-ch02-12to19/xkpublishdate Y2020-05-12T12:23:29+09:00xgsummary!IRustで言語処理100本ノックの第2章の残りです。 前回はこちら。 ちなみに、標準入力から受け取る処理は書いてないです。 出力に関してはファイルwdtags2xpdRustfnlp100xetitle ]第2章の12から19まで(言語処理100本ノック2020)vb72:yddate-:`xcdirjpost/2020/xbid `c098c6f0901979bd914ed7a345200f90xdlangbjayglastmod-:`xipermalink!Chttps://blog.johtani.info/blog/2020/05/08/rebootnlp100-ch02-10to11/xkpublishdate Y2020-05-08T23:37:20+09:00xgsummary!I気づいたら1ヶ月サボってました、ごめんなさい。。。 Rustで言語処理100本ノックの第2章をはじめました。 前回はこちら。 確認用のUnixコマwdtags2xpdRustfnlp100xetitle ]第2章の10から11まで(言語処理100本ノック2020)vb73:yddate-4Ixcdirjpost/2020/xbid `2c3270f8797ace2fb37402ea6a09d126xdlangbjayglastmod-4Ixipermalink!Dhttps://blog.johtani.info/blog/2020/05/08/reboot-nlp100-finish-ch01/xkpublishdate Y2020-05-08T16:40:57+09:00xgsummary!kRustで言語処理100本ノックのリファクタリングの続き。 前回はこちら。 とっくに終わってたのに、ブログ書いてなかった。。。 08. 暗号文 pub fn cipher(text: &amp;str) -&gt;wdtags2xpdRustfnlp100xetitle ]第1章の08から09まで(言語処理100本ノック2020)vb74:yddate,7
Rxcdirjpost/2020/xbid `44db1f1fefc97cd28d55d443f2bd2b63xdlangbjayglastmod,7
Rxipermalink!Chttps://blog.johtani.info/blog/2020/05/07/install-workplace-search/xkpublishdate Y2020-05-07T11:32:50+09:00xgsummary!G前回はWorkplace Searchの概要について書きましたが、今回はインストールと構成要素について説明します。なお、2020/5/7時点でwdtags2xpmelasticsearch Pworkplace searchxetitle pElasticのWorkplace Searchを触ってみる - その2 - インストールと起動vb75:yddate*<?@xcdirjpost/2020/xbid `4d71d2a23c85fb7af20e8d1e8b3e0de8xdlangbjayglastmod*<?@xipermalink!Ahttps://blog.johtani.info/blog/2020/05/01/intro-workplace-search/xkpublishdate Y2020-05-01T16:29:04+09:00xgsummary!H2月のElastic社のブログですが、Enterprise Searchとこれまで呼んでいた製品をWorkplace Searchという製品名にwdtags2xpmelasticsearch Pworkplace searchxetitle dElasticのWorkplace Searchを触ってみる - その1vb76:yddate)##oxcdirjpost/2020/xbid `be2c49ea5816e7daa6d3b3ff45353291xdlangbjayglastmod)##oxipermalink!Chttps://blog.johtani.info/blog/2020/04/27/note-updating-dictionary/xkpublishdate Y2020-04-27T10:44:15+09:00xgsummary!G先日、Elasticsearchでのカスタム辞書の利用方法についてブログを書きました。 辞書の設定方法について記載しましたが、今回は辞書の更新wdtags1xpmelasticsearchxetitlem辞書の更新についての注意点vb77:yddate'99Pxcdirjpost/2020/xbid `15357b6978e83daa2d97692c861dc177xdlangbjayglastmod'99Pxipermalink!Fhttps://blog.johtani.info/blog/2020/04/22/custom-dictionary-after-7-4/xkpublishdate Y2020-04-22T10:30:56+09:00xgsummary!HElasticsearchで日本語を扱うときに、カスタム辞書を使いたいという要望がよくあります。 AWSのElasticsearch Serviwdtags1xpmelasticsearchxetitle \Kuromojiのカスタム辞書をインデックスの設定で指定vb78:yddate&
 jxcdirjpost/2020/xbid `f488aa62d39194824861a134567cadb8xdlangbjayglastmod&
-jxipermalink ~https://blog.johtani.info/blog/2020/04/16/chap8-rust-the-book/xkpublishdate Y2020-04-16T18:17:30+09:00xgsummary!w前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 第8章 7章はパwdtags3xpdrustb読書mrust-the-bookxetitle SRust the book - 第8章vb78:yddate#.Oxcdirjpost/2020/xbid `9a687babb0f44db51dc389b75bdaa19dxdlangbjayglastmod#.Oxipermalink!Dhttps://blog.johtani.info/blog/2020/04/09/reboot-nlp100-ch01-03to05/xkpublishdate Y2020-04-09T18:14:55+09:00xgsummary!NRustで言語処理100本ノックのリファクタリングの続き。 前回はこちら。 コードも載せたほうが見やすいかなぁ? 03. 円周率 2年前はこちら。 どちらかwdtags2xpdRustfnlp100xetitle ]第1章の03から06まで(言語処理100本ノック2020)vb79:yddate#)yxcdirjpost/2020/xbid `dc9580308938069159c5afc55b2f3b96xdlangbjayglastmod#)yxipermalink!Ahttps://blog.johtani.info/blog/2020/04/08/reboot-nlp10-with-rust/xkpublishdate Y2020-04-08T18:33:45+09:00xgsummary!G今回もツイートから。 言語処理100本ノックの2020年版を公開しました。最近の自然言語処理の研究動向を反映し、深層ニューラルネットワークに関wdtags2xpdRustfnlp100xetitlen言語処理100本ノック、再びvb80:yddate#xcdirjpost/2020/xbid `4fbdc9c57a37781dc5dd86f470c61d04xdlangbjayglastmod#xipermalink ~https://blog.johtani.info/blog/2020/04/07/chap6-rust-the-book/xkpublishdate Y2020-04-07T19:27:11+09:00xgsummary!j前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 第6章 Enumです。matcwdtags3xpdrustb読書mrust-the-bookxetitle SRust the book - 第6章vb81:yddate"*pxcdirjpost/2020/xbid `6fbf7c3d0f4f89e415e89cec28811a94xdlangbjayglastmod"*pxipermalink ~https://blog.johtani.info/blog/2020/04/06/update-kuromoji-cli/xkpublishdate Y2020-04-06T12:26:40+09:00xgsummary!HKuromoji-CLIの使い方などについては過去のブログを御覧ください。 KuromojiのCLIコマンドとpicocliとGraalVM Gwdtags1xpdmiscxetitle aKuromojiのCLIコマンドにJSON出力とラティス出力を追加vb82:yddate!Nxcdirjpost/2020/xbid `8d9c3760395e8e0eb40e335b22750b68xdlangbjayglastmod!Nxipermalink ~https://blog.johtani.info/blog/2020/04/02/chap5-rust-the-book/xkpublishdate Y2020-04-02T15:09:18+09:00xgsummary!]前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 第5章 構造体です。勝手知ったるなんとやら?wdtags3xpdrustb読書mrust-the-bookxetitle SRust the book - 第5章vb83:yddate?gxcdirjpost/2020/xbid `3f431bf71ee866f626daf42bc915fa3fxdlangbjayglastmod?gxipermalink {https://blog.johtani.info/blog/2020/03/26/working-facility/xkpublishdate Y2020-03-26T19:11:51+09:00xgsummary!Gすもけさんが在宅勤務環境をブログに書いてておもしろそうだな(あと、アフィリンク貼れるな)と思ったので自分の環境も書いてみようかなと。 私自身はwdtags1xpdmiscxetitlem自宅の作業環境(2020)vb84:yddate[xcdirjpost/2020/xbid `7fded0345c258eea966c0b5ee1b7c7aaxdlangbjayglastmod[xipermalink ~https://blog.johtani.info/blog/2020/03/26/chap4-rust-the-book/xkpublishdate Y2020-03-26T17:12:11+09:00xgsummary!P前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた 第4章 第4章です。たぶん、これがいちばん大事な概念だと思wdtags3xpdrustb読書mrust-the-bookxetitle SRust the book - 第4章vb85:yddate+5}xcdirjpost/2020/xbid `a7f0e85fcad4f5bc5ae5c18c10de4f9exdlangbjayglastmod+5}xipermalink!@https://blog.johtani.info/blog/2020/03/25/vsc-es-analzye-plugin/xkpublishdate Y2020-03-25T11:10:05+09:00xgsummary!\先日、Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)というブログを書きました。 このプラグインを作ってたタイミンwdtags2xpmelasticsearch Rvisual studio codexetitle xElasticsearchのAnalyze APIのVisual Studio Codeのクライアントプラグインvb86:yddate
Bxcdirjpost/2020/xbid `48b5ab9805919736382ffea5a9554c02xdlangbjayglastmod
Bxipermalink!Fhttps://blog.johtani.info/blog/2020/03/23/start-reading-rust-the-book/xkpublishdate Y2020-03-23T10:57:22+09:00xgsummary!N自転車本を読み始めましたが、その前にRust the bookを読んだほうが良いかも?と知り合いと話をしていてなったので、先にRust the bookを読wdtags3xpdrustb読書mrust-the-bookxetitle SRust the Bookを読み始めたvb87:yddate,?Wxcdirjpost/2020/xbid `c9d257aba54475c20b3737ce7c779e55xdlangbjayglastmod,?Wxipermalink!Fhttps://blog.johtani.info/blog/2020/03/19/azure-search-analyze-plugin/xkpublishdate Y2020-03-19T10:50:15+09:00xgsummary!V動機 Azure Cognitive Searchを検索エンジンに使っているお客さんを手伝っています。 そこで、検索の基本的な話をさせていただきました(もともとJJUGナイwdtags2xplazure search Rvisual studio codexetitle {Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)vb88:yddate?Mxcdirjpost/2020/xbid `6f47cb314fd780c122adb8cc1f44f785xdlangbjayglastmod?Mxipermalink!Dhttps://blog.johtani.info/blog/2020/03/02/finish-bicycle-book-chap3/xkpublishdate Y2020-03-02T18:20:13+09:00xgsummary!Kこれまで 実践Rust入門はじめました 実践Rust入門の3章を読んでるところ 3章終了 3章の終わりまで読み終えた。 いきなり実践的なプログラムで少wdtags2xpdrustb読書xetitle R実践Rust入門の3章を読み終わったvb89:yddate?Cxcdirjpost/2020/xbid `d710a073be2da219a388a150eb7b6b6axdlangbjayglastmod?Cxipermalink whttps://blog.johtani.info/blog/2020/02/28/kuromoji-cli/xkpublishdate Y2020-02-28T11:49:39+09:00xgsummary!RKuromoji-CLI Rust初心者がRust製の日本語形態素解析器の開発を引き継いでみたという記事にありますが、LinderaというRust製の日本語形態素解wdtags1xpdmiscxetitle `KuromojiのCLIコマンドとpicocliとGraalVMvb90:yddate".mxcdirjpost/2020/xbid `71cf83ae0f45e9ede3a3f979b9c74933xdlangbjayglastmod".mxipermalink }https://blog.johtani.info/blog/2020/02/23/bicycle-book-chap3/xkpublishdate Y2020-02-23T16:37:17+09:00xgsummary!Iこれまでのはこちら。読書メモなので、本と合わせて読んでいただくのが良いです。 実践Rust入門はじめました 3章のクイックツアーを読んでます。 バwdtags2xpdrustb読書xetitle S実践Rust入門の3章を読んでるところvb91:yddate8<nxcdirjpost/2020/xbid `daa3fe935b0be9f31b6b362ad9e0d2d6xdlangbjayglastmod8<nxipermalink xhttps://blog.johtani.info/blog/2020/02/21/best-buy-2019/xkpublishdate Y2020-02-21T17:05:02+09:00xgsummary!dもう2020年2月になってしまってますが、2019年に買って便利だったもの良かったものをいくつか記録に残しとこうかなと。 BRAVIA KJ-55X9500G Amazon | ソニー SONY 49wdtags1xpc買い物xetitleo2019年に買ってよかったものvb92:yddate4"`xcdirjpost/2020/xbid `ef8a399c9679ce4e9710c7c6ecf8bcc7xdlangbjayglastmod4"`xipermalink }https://blog.johtani.info/blog/2020/02/21/import-jugem-posts/xkpublishdate Y2020-02-21T12:04:00+09:00xgsummary!Jブログ移行日記(その5)です。前回まではこちら ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4wdtags2xpdhugocブログxetitle [ブログ移行日記(その5) - Jugemのブログを移行vb93:yddate
+jxipermalink ~https://blog.johtani.info/blog/2020/04/16/chap8-rust-the-book/xkpublishdate Y2020-04-16T18:17:30+09:00xgsummary!w前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 第8章 7章はパwdtags3xpdrustb読書mrust-the-bookxetitle SRust the book - 第8章vb79:yddate#.Oxcdirjpost/2020/xbid `9a687babb0f44db51dc389b75bdaa19dxdlangbjayglastmod#.Oxipermalink!Dhttps://blog.johtani.info/blog/2020/04/09/reboot-nlp100-ch01-03to05/xkpublishdate Y2020-04-09T18:14:55+09:00xgsummary!NRustで言語処理100本ノックのリファクタリングの続き。 前回はこちら。 コードも載せたほうが見やすいかなぁ? 03. 円周率 2年前はこちら。 どちらかwdtags2xpdRustfnlp100xetitle ]第1章の03から06まで(言語処理100本ノック2020)vb80:yddate#)yxcdirjpost/2020/xbid `dc9580308938069159c5afc55b2f3b96xdlangbjayglastmod#)yxipermalink!Ahttps://blog.johtani.info/blog/2020/04/08/reboot-nlp10-with-rust/xkpublishdate Y2020-04-08T18:33:45+09:00xgsummary!G今回もツイートから。 言語処理100本ノックの2020年版を公開しました。最近の自然言語処理の研究動向を反映し、深層ニューラルネットワークに関wdtags2xpdRustfnlp100xetitlen言語処理100本ノック、再びvb81:yddate#xcdirjpost/2020/xbid `4fbdc9c57a37781dc5dd86f470c61d04xdlangbjayglastmod#xipermalink ~https://blog.johtani.info/blog/2020/04/07/chap6-rust-the-book/xkpublishdate Y2020-04-07T19:27:11+09:00xgsummary!j前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 第6章 Enumです。matcwdtags3xpdrustb読書mrust-the-bookxetitle SRust the book - 第6章vb82:yddate"*pxcdirjpost/2020/xbid `6fbf7c3d0f4f89e415e89cec28811a94xdlangbjayglastmod"*pxipermalink ~https://blog.johtani.info/blog/2020/04/06/update-kuromoji-cli/xkpublishdate Y2020-04-06T12:26:40+09:00xgsummary!HKuromoji-CLIの使い方などについては過去のブログを御覧ください。 KuromojiのCLIコマンドとpicocliとGraalVM Gwdtags1xpdmiscxetitle aKuromojiのCLIコマンドにJSON出力とラティス出力を追加vb83:yddate!Nxcdirjpost/2020/xbid `8d9c3760395e8e0eb40e335b22750b68xdlangbjayglastmod!Nxipermalink ~https://blog.johtani.info/blog/2020/04/02/chap5-rust-the-book/xkpublishdate Y2020-04-02T15:09:18+09:00xgsummary!]前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 第5章 構造体です。勝手知ったるなんとやら?wdtags3xpdrustb読書mrust-the-bookxetitle SRust the book - 第5章vb84:yddate?gxcdirjpost/2020/xbid `3f431bf71ee866f626daf42bc915fa3fxdlangbjayglastmod?gxipermalink {https://blog.johtani.info/blog/2020/03/26/working-facility/xkpublishdate Y2020-03-26T19:11:51+09:00xgsummary!Gすもけさんが在宅勤務環境をブログに書いてておもしろそうだな(あと、アフィリンク貼れるな)と思ったので自分の環境も書いてみようかなと。 私自身はwdtags1xpdmiscxetitlem自宅の作業環境(2020)vb85:yddate[xcdirjpost/2020/xbid `7fded0345c258eea966c0b5ee1b7c7aaxdlangbjayglastmod[xipermalink ~https://blog.johtani.info/blog/2020/03/26/chap4-rust-the-book/xkpublishdate Y2020-03-26T17:12:11+09:00xgsummary!P前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた 第4章 第4章です。たぶん、これがいちばん大事な概念だと思wdtags3xpdrustb読書mrust-the-bookxetitle SRust the book - 第4章vb86:yddate+5}xcdirjpost/2020/xbid `a7f0e85fcad4f5bc5ae5c18c10de4f9exdlangbjayglastmod+5}xipermalink!@https://blog.johtani.info/blog/2020/03/25/vsc-es-analzye-plugin/xkpublishdate Y2020-03-25T11:10:05+09:00xgsummary!\先日、Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)というブログを書きました。 このプラグインを作ってたタイミンwdtags2xpmelasticsearch Rvisual studio codexetitle xElasticsearchのAnalyze APIのVisual Studio Codeのクライアントプラグインvb87:yddate
Bxcdirjpost/2020/xbid `48b5ab9805919736382ffea5a9554c02xdlangbjayglastmod
Bxipermalink!Fhttps://blog.johtani.info/blog/2020/03/23/start-reading-rust-the-book/xkpublishdate Y2020-03-23T10:57:22+09:00xgsummary!N自転車本を読み始めましたが、その前にRust the bookを読んだほうが良いかも?と知り合いと話をしていてなったので、先にRust the bookを読wdtags3xpdrustb読書mrust-the-bookxetitle SRust the Bookを読み始めたvb88:yddate,?Wxcdirjpost/2020/xbid `c9d257aba54475c20b3737ce7c779e55xdlangbjayglastmod,?Wxipermalink!Fhttps://blog.johtani.info/blog/2020/03/19/azure-search-analyze-plugin/xkpublishdate Y2020-03-19T10:50:15+09:00xgsummary!V動機 Azure Cognitive Searchを検索エンジンに使っているお客さんを手伝っています。 そこで、検索の基本的な話をさせていただきました(もともとJJUGナイwdtags2xplazure search Rvisual studio codexetitle {Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)vb89:yddate?Mxcdirjpost/2020/xbid `6f47cb314fd780c122adb8cc1f44f785xdlangbjayglastmod?Mxipermalink!Dhttps://blog.johtani.info/blog/2020/03/02/finish-bicycle-book-chap3/xkpublishdate Y2020-03-02T18:20:13+09:00xgsummary!Kこれまで 実践Rust入門はじめました 実践Rust入門の3章を読んでるところ 3章終了 3章の終わりまで読み終えた。 いきなり実践的なプログラムで少wdtags2xpdrustb読書xetitle R実践Rust入門の3章を読み終わったvb90:yddate?Cxcdirjpost/2020/xbid `d710a073be2da219a388a150eb7b6b6axdlangbjayglastmod?Cxipermalink whttps://blog.johtani.info/blog/2020/02/28/kuromoji-cli/xkpublishdate Y2020-02-28T11:49:39+09:00xgsummary!RKuromoji-CLI Rust初心者がRust製の日本語形態素解析器の開発を引き継いでみたという記事にありますが、LinderaというRust製の日本語形態素解wdtags1xpdmiscxetitle `KuromojiのCLIコマンドとpicocliとGraalVMvb91:yddate".mxcdirjpost/2020/xbid `71cf83ae0f45e9ede3a3f979b9c74933xdlangbjayglastmod".mxipermalink }https://blog.johtani.info/blog/2020/02/23/bicycle-book-chap3/xkpublishdate Y2020-02-23T16:37:17+09:00xgsummary!Iこれまでのはこちら。読書メモなので、本と合わせて読んでいただくのが良いです。 実践Rust入門はじめました 3章のクイックツアーを読んでます。 バwdtags2xpdrustb読書xetitle S実践Rust入門の3章を読んでるところvb92:yddate8<nxcdirjpost/2020/xbid `daa3fe935b0be9f31b6b362ad9e0d2d6xdlangbjayglastmod8<nxipermalink xhttps://blog.johtani.info/blog/2020/02/21/best-buy-2019/xkpublishdate Y2020-02-21T17:05:02+09:00xgsummary!dもう2020年2月になってしまってますが、2019年に買って便利だったもの良かったものをいくつか記録に残しとこうかなと。 BRAVIA KJ-55X9500G Amazon | ソニー SONY 49wdtags1xpc買い物xetitleo2019年に買ってよかったものvb93:yddate4"`xcdirjpost/2020/xbid `ef8a399c9679ce4e9710c7c6ecf8bcc7xdlangbjayglastmod4"`xipermalink }https://blog.johtani.info/blog/2020/02/21/import-jugem-posts/xkpublishdate Y2020-02-21T12:04:00+09:00xgsummary!Jブログ移行日記(その5)です。前回まではこちら ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4wdtags2xpdhugocブログxetitle [ブログ移行日記(その5) - Jugemのブログを移行vb94:yddate
 axcdirjpost/2020/xbid `c3053579ae25e2fb9b967076a06373afxdlangbjayglastmod
-axipermalink!Jhttps://blog.johtani.info/blog/2020/02/19/research-azure-cognitive-search/xkpublishdate Y2020-02-19T11:48:01+09:00xgsummary!\お手伝いしているお客さんがAzure Cognitive Searchを利用してます。 検索周り=Azure Cognitive Searchに関する手伝いをする形で入っており、 いくwdtags1xplazure searchxetitle cAzure Cognitive Searchでインデックスを作って検索vb94:yddatekxcdirjpost/2020/xbid `7b080dc43fce482af14de61c6ab819a5xdlangbjayglastmodkxipermalink!@https://blog.johtani.info/blog/2020/02/10/explore-search-system/xkpublishdate Y2020-02-10T23:20:27+09:00xgsummary!Hまた、ツイートから始まるお話です。 まだまだ、検索システムってどんなものかを勉強したいしということで、こんなのをツイートしてました。 「検索シスwdtags1xph検索システム探訪xetitle U「検索システム探訪」したいな=>やりましたvb95:yddate
%fxcdirjpost/2020/xbid `90f9355781403b92e844de8568863ae8xdlangbjayglastmod
%fxipermalink {https://blog.johtani.info/blog/2020/02/01/intro-board-game/xkpublishdate Y2020-02-01T21:04:54+09:00xgsummary!H年末、何種類かのボードゲームを家族で楽しみました。 家族の感想を交えて簡単に紹介しようかと思います。 家族や知人でボードゲームを購入するときの参wdtags1xpcゲームxetitlehボードゲーム紹介vb96:yddate
dxcdirjpost/2020/xbid `7fcfaa8dd34dbd508f19e8ca0fcfda0fxdlangbjayglastmod
dxipermalink!Ehttps://blog.johtani.info/blog/2020/01/31/start-reading-bicycle-book/xkpublishdate Y2020-01-31T21:58:12+09:00xgsummary!G実践Rust入門という本を買っていた(去年の7月だ。。。)のですが、積んであったので、時間を作って読み始めようかと。 実践Rust入門[言語仕wdtags2xpdrustb読書xetitlen実践Rust入門はじめましたvb97:yddate

Cxcdirjpost/2020/xbid `c61a5bda3f1667498626ae52ad0362e0xdlangbjayglastmod

Cxipermalink zhttps://blog.johtani.info/blog/2020/01/31/start-freelance/xkpublishdate Y2020-01-31T20:37:39+09:00xgsummary!G12月に退職しますブログを書きましたが、その後どうなったのか?という話をしてないなと思ったので、一応現在の状況を書き留めておこううかと。 結論wdtags1xpb転職xetitleoフリーランスはじめました(仮)vb98:yddate;,dxcdirjpost/2020/xbid `d9018f459d3c94a91e92b459e152f7e7xdlangbjayglastmodTxipermalink |https://blog.johtani.info/blog/2020/01/28/introduce-algolia/xkpublishdate Y2020-01-28T13:40:04+09:00xgsummary!Jブログ移行日記(その4)です。その他の記事はこちら。 ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(wdtags1xpcブログxetitle _ブログ移行日記(その4) - 検索機能(Algolia)の導入vb99:yddate
+axipermalink!Jhttps://blog.johtani.info/blog/2020/02/19/research-azure-cognitive-search/xkpublishdate Y2020-02-19T11:48:01+09:00xgsummary!\お手伝いしているお客さんがAzure Cognitive Searchを利用してます。 検索周り=Azure Cognitive Searchに関する手伝いをする形で入っており、 いくwdtags1xplazure searchxetitle cAzure Cognitive Searchでインデックスを作って検索vb95:yddatekxcdirjpost/2020/xbid `7b080dc43fce482af14de61c6ab819a5xdlangbjayglastmodkxipermalink!@https://blog.johtani.info/blog/2020/02/10/explore-search-system/xkpublishdate Y2020-02-10T23:20:27+09:00xgsummary!Hまた、ツイートから始まるお話です。 まだまだ、検索システムってどんなものかを勉強したいしということで、こんなのをツイートしてました。 「検索シスwdtags1xph検索システム探訪xetitle U「検索システム探訪」したいな=>やりましたvb96:yddate
%fxcdirjpost/2020/xbid `90f9355781403b92e844de8568863ae8xdlangbjayglastmod
%fxipermalink {https://blog.johtani.info/blog/2020/02/01/intro-board-game/xkpublishdate Y2020-02-01T21:04:54+09:00xgsummary!H年末、何種類かのボードゲームを家族で楽しみました。 家族の感想を交えて簡単に紹介しようかと思います。 家族や知人でボードゲームを購入するときの参wdtags1xpcゲームxetitlehボードゲーム紹介vb97:yddate
dxcdirjpost/2020/xbid `7fcfaa8dd34dbd508f19e8ca0fcfda0fxdlangbjayglastmod
dxipermalink!Ehttps://blog.johtani.info/blog/2020/01/31/start-reading-bicycle-book/xkpublishdate Y2020-01-31T21:58:12+09:00xgsummary!G実践Rust入門という本を買っていた(去年の7月だ。。。)のですが、積んであったので、時間を作って読み始めようかと。 実践Rust入門[言語仕wdtags2xpdrustb読書xetitlen実践Rust入門はじめましたvb98:yddate

Cxcdirjpost/2020/xbid `c61a5bda3f1667498626ae52ad0362e0xdlangbjayglastmod

Cxipermalink zhttps://blog.johtani.info/blog/2020/01/31/start-freelance/xkpublishdate Y2020-01-31T20:37:39+09:00xgsummary!G12月に退職しますブログを書きましたが、その後どうなったのか?という話をしてないなと思ったので、一応現在の状況を書き留めておこううかと。 結論wdtags1xpb転職xetitleoフリーランスはじめました(仮)vb99:yddate;,dxcdirjpost/2020/xbid `d9018f459d3c94a91e92b459e152f7e7xdlangbjayglastmodTxipermalink |https://blog.johtani.info/blog/2020/01/28/introduce-algolia/xkpublishdate Y2020-01-28T13:40:04+09:00xgsummary!Jブログ移行日記(その4)です。その他の記事はこちら。 ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(wdtags1xpcブログxetitle _ブログ移行日記(その4) - 検索機能(Algolia)の導入vc100:yddate
 *Yxcdirjpost/2020/xbid `99c9c80a6532e4ea3b535c5a92d07a25xdlangbjayglastmod
-*Yxipermalink whttps://blog.johtani.info/blog/2020/01/24/setting-hugo/xkpublishdate Y2020-01-24T17:04:41+09:00xgsummary!Jブログ移行日記(その3)です。その他の記事はこちら。 ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その4) ブログ移行日記(wdtags1xpcブログxetitle dブログ移行日記(その3) - Hugoの設定と微調整(テーマに合わせた)vc100:yddate
+*Yxipermalink whttps://blog.johtani.info/blog/2020/01/24/setting-hugo/xkpublishdate Y2020-01-24T17:04:41+09:00xgsummary!Jブログ移行日記(その3)です。その他の記事はこちら。 ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その4) ブログ移行日記(wdtags1xpcブログxetitle dブログ移行日記(その3) - Hugoの設定と微調整(テーマに合わせた)vc101:yddate
 Zxcdirjpost/2020/xbid `018b365b00dd3a6ad17c813d21590549xdlangbjayglastmod
-Zxipermalink!Lhttps://blog.johtani.info/blog/2020/01/23/convert-md-from-octopress-to-hugo/xkpublishdate Y2020-01-23T19:31:54+09:00xgsummary!Kその他の記事はこちら ブログ移行日記(その1) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) ブログ移行日記(その2)wdtags1xpcブログxetitle ^ブログ移行日記(その2) - Markdownファイルの変換vc101:yddate	;fxcdirjpost/2020/xbid `a65bd31d4c3dab0a41712823a5d6002bxdlangbjayglastmod	;fxipermalink https://blog.johtani.info/blog/2020/01/22/intro-hugo-and-theme/xkpublishdate Y2020-01-22T11:23:34+09:00xgsummary!Lその他の記事はこちら ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) 起因 いつものツイートからwdtags1xpcブログxetitle Wブログ移行日記(その1) - Hugoとテーマvc102:yddate.Yxcdirjpost/2020/xbid `3c299a4d77be8b4f886ce9fcd23a2561xdlangbjayglastmod.Yxipermalink yhttps://blog.johtani.info/blog/2020/01/16/moving-to-hugo/xkpublishdate Y2020-01-16T18:23:37+09:00xgsummary!G5年くらい、Octopressを使用していましたが、更新されなくなっているのと、コンテンツの生成に時間がかかることもあり、 ほかのプラットフォwdtags3xpdhugocブログioctopressxetitle YOctopressからHugoへ移行中(まだ途中)vc103:yddate,Gxcdirjpost/2019/xbid `35aa9e09db936aee7ec407c431816573xdlangbjayglastmod,Gxipermalink |https://blog.johtani.info/blog/2019/12/31/looking-back-2019/xkpublishdate Y2019-12-31T12:59:03+09:00xgsummary!O今年も振り返りブログ書いてます。Sasukeがついてる。 振り返り（2018年に書いた抱負から） まずは去年の抱負を元に。 TOEIC 受けました。 お。TOwdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2019）vc104:yddate
xcdirjpost/2019/xbid `1a1a8cc0040b356d06eacd22e0526476xdlangbjayglastmod
xipermalink!Ihttps://blog.johtani.info/blog/2019/12/23/whats-window-group-of-terminal/xkpublishdate Y2019-12-23T10:14:39+09:00xgsummary!Hこのブログ書こうと思って、これまでMacのセットアップしてたんだった。。。 普段、macOSの標準ターミナルを使ってます。 で、ターミナルを使うwdtags1xpdmiscxetitle ZmacOS標準のターミナルのウィンドウグループが便利vc105:yddate>Jxcdirjpost/2019/xbid `80c8fca02ebfecc7a931dad1ec38466exdlangbjayglastmod>Jxipermalink ~https://blog.johtani.info/blog/2019/12/18/introduce-homeshick/xkpublishdate Y2019-12-18T08:11:06+09:00xgsummary!Gドットファイル系（.emacsとか）をこれまでは、PCを引っ越すたびにコピーしてたんですが、いいかげん、GitHubとかで管理したいなと。 でwdtags1xpdmiscxetitlekhomeshick導入vc106:yddate>
+Zxipermalink!Lhttps://blog.johtani.info/blog/2020/01/23/convert-md-from-octopress-to-hugo/xkpublishdate Y2020-01-23T19:31:54+09:00xgsummary!Kその他の記事はこちら ブログ移行日記(その1) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) ブログ移行日記(その2)wdtags1xpcブログxetitle ^ブログ移行日記(その2) - Markdownファイルの変換vc102:yddate	;fxcdirjpost/2020/xbid `a65bd31d4c3dab0a41712823a5d6002bxdlangbjayglastmod	;fxipermalink https://blog.johtani.info/blog/2020/01/22/intro-hugo-and-theme/xkpublishdate Y2020-01-22T11:23:34+09:00xgsummary!Lその他の記事はこちら ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) 起因 いつものツイートからwdtags1xpcブログxetitle Wブログ移行日記(その1) - Hugoとテーマvc103:yddate.Yxcdirjpost/2020/xbid `3c299a4d77be8b4f886ce9fcd23a2561xdlangbjayglastmod.Yxipermalink yhttps://blog.johtani.info/blog/2020/01/16/moving-to-hugo/xkpublishdate Y2020-01-16T18:23:37+09:00xgsummary!G5年くらい、Octopressを使用していましたが、更新されなくなっているのと、コンテンツの生成に時間がかかることもあり、 ほかのプラットフォwdtags3xpdhugocブログioctopressxetitle YOctopressからHugoへ移行中(まだ途中)vc104:yddate,Gxcdirjpost/2019/xbid `35aa9e09db936aee7ec407c431816573xdlangbjayglastmod,Gxipermalink |https://blog.johtani.info/blog/2019/12/31/looking-back-2019/xkpublishdate Y2019-12-31T12:59:03+09:00xgsummary!O今年も振り返りブログ書いてます。Sasukeがついてる。 振り返り（2018年に書いた抱負から） まずは去年の抱負を元に。 TOEIC 受けました。 お。TOwdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2019）vc105:yddate
xcdirjpost/2019/xbid `1a1a8cc0040b356d06eacd22e0526476xdlangbjayglastmod
xipermalink!Ihttps://blog.johtani.info/blog/2019/12/23/whats-window-group-of-terminal/xkpublishdate Y2019-12-23T10:14:39+09:00xgsummary!Hこのブログ書こうと思って、これまでMacのセットアップしてたんだった。。。 普段、macOSの標準ターミナルを使ってます。 で、ターミナルを使うwdtags1xpdmiscxetitle ZmacOS標準のターミナルのウィンドウグループが便利vc106:yddate>Jxcdirjpost/2019/xbid `80c8fca02ebfecc7a931dad1ec38466exdlangbjayglastmod>Jxipermalink ~https://blog.johtani.info/blog/2019/12/18/introduce-homeshick/xkpublishdate Y2019-12-18T08:11:06+09:00xgsummary!Gドットファイル系（.emacsとか）をこれまでは、PCを引っ越すたびにコピーしてたんですが、いいかげん、GitHubとかで管理したいなと。 でwdtags1xpdmiscxetitlekhomeshick導入vc107:yddate>
 wxcdirjpost/2019/xbid `f3ef819656f68b87a91c53afbd441fecxdlangbjayglastmod>
-wxipermalink vhttps://blog.johtani.info/blog/2019/12/17/move-to-zsh/xkpublishdate Y2019-12-17T09:35:03+09:00xgsummary!NMacbook Proが新しくなり、OSがCatalinaになっちゃいました。 これまで使ってた、.bash_profileをコピーしてターミナルを立ち上げwdtags1xpdmiscxetitlegzshへの移行vc107:yddate=-Mxcdirjpost/2019/xbid `1abc586d67f0b6c05fd5e60f25492340xdlangbjayglastmod=-Mxipermalink https://blog.johtani.info/blog/2019/12/16/dockernize-octopress/xkpublishdate Y2019-12-16T10:01:01+09:00xgsummary!O最近使っていたPCが手元からなくなったので、16インチ Macbook Proをセットアップしているところです。 で、時間もあるのでこれまでほったらかしてきたwdtags1xpioctopressxetitle WOctopress環境のDockerイメージ化vc108:yddate:)rxcdirjpost/2019/xbid `1bbf2ef67f096960e13d8578fa544536xdlangbjayglastmod:)rxipermalink zhttps://blog.johtani.info/blog/2019/12/06/leaving-elastic/xkpublishdate Y2019-12-06T15:51:30+09:00xgsummary!G本日、Elasticでの最終出社日でした。実際の退職日はまだ先ですが、有休消化という感じです。 思い返せばもう5年と5ヶ月も前ですが、Elaswdtags1xpb転職xetitlee退職しますvc109:yddate9'!pxcdirjpost/2019/xbid `c2d39f2f7fe6cb69fc8efb6c5495c932xdlangbjayglastmod9'!pxipermalink |https://blog.johtani.info/blog/2019/12/04/about-lucene-4056/xkpublishdate Y2019-12-04T00:00:00+09:00xgsummary!\これは、情報検索・検索エンジン Advent Calendar 2019 の 4 日目の記事です。 1日目から、質の高いエントリーが続いていましたが、一旦休憩して頂く感じの記事になってwdtags1xpfLucenexetitle iApache LuceneのKuromojiのUniDicビルド対応パッチについてvc110:yddate8(pxcdirjpost/2019/xbid `78da47d61c91c82809a3c97a791d26d2xdlangbjayglastmod8(pxipermalink!Jhttps://blog.johtani.info/blog/2019/12/01/whats-happen-at-elastic-in-2019/xkpublishdate Y2019-12-01T00:00:00+09:00xgsummary!pElastic stack (Elasticsearch) Advent Calendar 2019の1日目の記事になります。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみようと思います。毎年恒例ですね、wdtags1xpmelasticsearchxetitle [2019年のElastic StackとElasticvc111:yddate,-Bxcdirjpost/2019/xbid `11b3a28b536f34d3606427f835bd3ddfxdlangbjayglastmod,-Bxipermalink vhttps://blog.johtani.info/blog/2019/10/25/bonefire-01/xkpublishdate Y2019-10-25T19:40:02+09:00xgsummary#FBonfire Data &amp; Science #1にブログ枠で参加してきました。 ということで、メモです。 日時 : 2019/10/25 19:00 - 21:30 場所 : Yahoo! Japan サイト : https://yj-meetup.connpass.com/event/148121/ ハッシュタグ: #yjbonfire 概要 Data &amp; Scienceとwdtags1xpc勉強会xetitle `Bonfire Data & Science #1に参加しましたvc112:yddate'-]xcdirjpost/2019/xbid `d8041ae308961666b15aa1e57b0f9f35xdlangbjayglastmod'-]xipermalink!@https://blog.johtani.info/blog/2019/10/10/review-es-next-step-2/xkpublishdate Y2019-10-10T15:56:29+09:00xgsummary!Gこの間のElasticsearch勉強会でAcroquest Technologyの人たちが技術書展7で販売されていた書籍を頂いてしまいましたwdtags1xpb書籍xetitle _Elasticsearch NEXT STEP 2を頂きましたvc113:yddate (dxcdirjpost/2019/xbid `d96f80f23543850a2ee9fff8cd2cc53fxdlangbjayglastmod (dxipermalink!Fhttps://blog.johtani.info/blog/2019/06/19/qr-code-with-meetup-dot-com/xkpublishdate Y2019-06-19T19:10:44+09:00xgsummary!GTwitterで「Meetup.comに切り替えたらー」みたいな話があったので、 受付用アプリとかなくてという話になったので、普段Elastiwdtags1xpc勉強会xetitle U勉強会の受付自作？アプリ？HTMLについてvc114:yddate0/nxcdirjpost/2019/xbid `538e38fbc3f78cd61e1841d8141ddcc1xdlangbjayglastmod0/nxipermalink!Chttps://blog.johtani.info/blog/2019/04/26/meetup-organizer-drinkup/xkpublishdate Y2019-04-26T00:02:06+09:00xgsummary!FElasticsearch勉強会や検索技術勉強会やってるんだけど、独学で勉強会やってるなーと思い、みんなはどうやってるんだろうとツイートしてwdtags1xpc勉強会xetitle Q勉強会運営座談会ってのをやってみたvc115:yddate=Hxcdirjpost/2019/xbid `b27bdabd8e1a6b7dc06886867331ceb3xdlangbjayglastmod=Hxipermalink!Mhttps://blog.johtani.info/blog/2019/02/26/start-search-engineering-tech-talk/xkpublishdate Y2019-02-26T23:38:00+09:00xgsummary!]どーも、johtaniです。 Search Engineering Tech Talkという勉強会に運営として参加して、第1回の勉強会を開始しました。 本日（2/26）は第1回目だったのwdtags2xpc勉強会b検索xetitle wSearch Engineering Tech Talk(検索技術勉強会)の運営として参加して始めてみました。vc116:yddate
+wxipermalink vhttps://blog.johtani.info/blog/2019/12/17/move-to-zsh/xkpublishdate Y2019-12-17T09:35:03+09:00xgsummary!NMacbook Proが新しくなり、OSがCatalinaになっちゃいました。 これまで使ってた、.bash_profileをコピーしてターミナルを立ち上げwdtags1xpdmiscxetitlegzshへの移行vc108:yddate=-Mxcdirjpost/2019/xbid `1abc586d67f0b6c05fd5e60f25492340xdlangbjayglastmod=-Mxipermalink https://blog.johtani.info/blog/2019/12/16/dockernize-octopress/xkpublishdate Y2019-12-16T10:01:01+09:00xgsummary!O最近使っていたPCが手元からなくなったので、16インチ Macbook Proをセットアップしているところです。 で、時間もあるのでこれまでほったらかしてきたwdtags1xpioctopressxetitle WOctopress環境のDockerイメージ化vc109:yddate:)rxcdirjpost/2019/xbid `1bbf2ef67f096960e13d8578fa544536xdlangbjayglastmod:)rxipermalink zhttps://blog.johtani.info/blog/2019/12/06/leaving-elastic/xkpublishdate Y2019-12-06T15:51:30+09:00xgsummary!G本日、Elasticでの最終出社日でした。実際の退職日はまだ先ですが、有休消化という感じです。 思い返せばもう5年と5ヶ月も前ですが、Elaswdtags1xpb転職xetitlee退職しますvc110:yddate9'!pxcdirjpost/2019/xbid `c2d39f2f7fe6cb69fc8efb6c5495c932xdlangbjayglastmod9'!pxipermalink |https://blog.johtani.info/blog/2019/12/04/about-lucene-4056/xkpublishdate Y2019-12-04T00:00:00+09:00xgsummary!\これは、情報検索・検索エンジン Advent Calendar 2019 の 4 日目の記事です。 1日目から、質の高いエントリーが続いていましたが、一旦休憩して頂く感じの記事になってwdtags1xpfLucenexetitle iApache LuceneのKuromojiのUniDicビルド対応パッチについてvc111:yddate8(pxcdirjpost/2019/xbid `78da47d61c91c82809a3c97a791d26d2xdlangbjayglastmod8(pxipermalink!Jhttps://blog.johtani.info/blog/2019/12/01/whats-happen-at-elastic-in-2019/xkpublishdate Y2019-12-01T00:00:00+09:00xgsummary!pElastic stack (Elasticsearch) Advent Calendar 2019の1日目の記事になります。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみようと思います。毎年恒例ですね、wdtags1xpmelasticsearchxetitle [2019年のElastic StackとElasticvc112:yddate,-Bxcdirjpost/2019/xbid `11b3a28b536f34d3606427f835bd3ddfxdlangbjayglastmod,-Bxipermalink vhttps://blog.johtani.info/blog/2019/10/25/bonefire-01/xkpublishdate Y2019-10-25T19:40:02+09:00xgsummary#FBonfire Data &amp; Science #1にブログ枠で参加してきました。 ということで、メモです。 日時 : 2019/10/25 19:00 - 21:30 場所 : Yahoo! Japan サイト : https://yj-meetup.connpass.com/event/148121/ ハッシュタグ: #yjbonfire 概要 Data &amp; Scienceとwdtags1xpc勉強会xetitle `Bonfire Data & Science #1に参加しましたvc113:yddate'-]xcdirjpost/2019/xbid `d8041ae308961666b15aa1e57b0f9f35xdlangbjayglastmod'-]xipermalink!@https://blog.johtani.info/blog/2019/10/10/review-es-next-step-2/xkpublishdate Y2019-10-10T15:56:29+09:00xgsummary!Gこの間のElasticsearch勉強会でAcroquest Technologyの人たちが技術書展7で販売されていた書籍を頂いてしまいましたwdtags1xpb書籍xetitle _Elasticsearch NEXT STEP 2を頂きましたvc114:yddate (dxcdirjpost/2019/xbid `d96f80f23543850a2ee9fff8cd2cc53fxdlangbjayglastmod (dxipermalink!Fhttps://blog.johtani.info/blog/2019/06/19/qr-code-with-meetup-dot-com/xkpublishdate Y2019-06-19T19:10:44+09:00xgsummary!GTwitterで「Meetup.comに切り替えたらー」みたいな話があったので、 受付用アプリとかなくてという話になったので、普段Elastiwdtags1xpc勉強会xetitle U勉強会の受付自作？アプリ？HTMLについてvc115:yddate0/nxcdirjpost/2019/xbid `538e38fbc3f78cd61e1841d8141ddcc1xdlangbjayglastmod0/nxipermalink!Chttps://blog.johtani.info/blog/2019/04/26/meetup-organizer-drinkup/xkpublishdate Y2019-04-26T00:02:06+09:00xgsummary!FElasticsearch勉強会や検索技術勉強会やってるんだけど、独学で勉強会やってるなーと思い、みんなはどうやってるんだろうとツイートしてwdtags1xpc勉強会xetitle Q勉強会運営座談会ってのをやってみたvc116:yddate=Hxcdirjpost/2019/xbid `b27bdabd8e1a6b7dc06886867331ceb3xdlangbjayglastmod=Hxipermalink!Mhttps://blog.johtani.info/blog/2019/02/26/start-search-engineering-tech-talk/xkpublishdate Y2019-02-26T23:38:00+09:00xgsummary!]どーも、johtaniです。 Search Engineering Tech Talkという勉強会に運営として参加して、第1回の勉強会を開始しました。 本日（2/26）は第1回目だったのwdtags2xpc勉強会b検索xetitle wSearch Engineering Tech Talk(検索技術勉強会)の運営として参加して始めてみました。vc117:yddate
 excdirjpost/2018/xbid `6c226ee1519fbf910197cc1d5c5a5756xdlangbjayglastmod
-exipermalink |https://blog.johtani.info/blog/2018/12/31/looking-back-2018/xkpublishdate Y2018-12-31T16:14:45+09:00xgsummary!J今年も振り返りブログをかけてます。よかったw 振り返り（2017年に書いた抱負から） まずは去年の抱負を元に。 もっと英語の継続＆TOEIC まぁ、wdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2018）vc117:yddateqxcdirjpost/2018/xbid `ee62cb0b9a97f990df1ed0266a7027e2xdlangbjayglastmodqxipermalink!Ghttps://blog.johtani.info/blog/2018/12/25/whats-new-in-elastic-stack-7/xkpublishdate Y2018-12-25T00:00:01+09:00xgsummary!rElastic stack (Elasticsearch) Advent Calendar 2018の25日目の記事になります。 今年最後のAdvent Calendarです！来年も忘れてなければやるはず！ 今日は、すでにalpwdtags1xpmelasticsearchxetitle aElastic Stack 7.0で入ってくる新機能をちょっと紹介vc118:yddate!vxcdirjpost/2018/xbid `ba45ddd3042dad59a12e5937644f7246xdlangbjayglastmod!vxipermalink!Jhttps://blog.johtani.info/blog/2018/12/01/whats-happen-at-elastic-in-2018/xkpublishdate Y2018-12-01T10:48:38+09:00xgsummary!qElastic stack (Elasticsearch) Advent Calendar 2018の1日目の記事になります。 ちょっと遅れちゃいました。。。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみよwdtags1xpmelasticsearchxetitle [2018年のElastic StackとElasticvc119:yddate16oxcdirjpost/2018/xbid `3fd9052870778e14ab4a5acbc8c24af4xdlangbjayglastmod16oxipermalink!Fhttps://blog.johtani.info/blog/2018/10/18/items-for-long-businesstrip/xkpublishdate Y2018-10-18T01:34:55+09:00xgsummary!G（転職する少し前までパスポートすら持ってなかったのに）今の会社に転職してから、半年に1度の割合で海外への出張が発生する生活を送っています。 4wdtags1xpdmiscxetitle W新規導入した長期出張用のアイテムをいくつか紹介vc120:yddate1/nxcdirjpost/2018/xbid `d3fa23c9066f943f10e8883de9340deaxdlangbjayglastmod1/nxipermalink!Jhttps://blog.johtani.info/blog/2018/10/17/26th-elasticsearch-tokyo-meetup/xkpublishdate Y2018-10-17T17:33:50+09:00xgsummary!H毎月開催の2回目になります。 今回は日経さんの会場をお借りしての開催となりました。 前回から、スピーカーの募集をhttp://bit.ly/Spwdtags2xpmelasticsearchc勉強会xetitle \第25回Elasticsearch勉強会を開催しました。vc121:yddatezxcdirjpost/2018/xbid `10ae016e19fff6ae9cfaeb8534fa47f9xdlangbjayglastmodzxipermalink {https://blog.johtani.info/blog/2018/07/29/apm-java-at-jjug/xkpublishdate Y2018-07-29T14:45:30+09:00xgsummary!I7/25にJJUGナイトセミナーでElastic Stackの紹介とAPMのJava Agentの紹介をしたので、補足のブログです。 （久々に書くwdtags1xpc勉強会xetitle QJJUGナイトセミナーで話しましたvc122:yddate6#ixcdirjpost/2018/xbid `04d818cbaac08b2915db15e0bffdcb5bxdlangbjayglastmod6#ixipermalink!Lhttps://blog.johtani.info/blog/2018/04/20/directory-layout-and-architecture/xkpublishdate Y2018-04-20T15:30:01+09:00xgsummary!F第2回から少し間が空いてしまいましたが、templateで作成したプラグインのディレクトリ構成とどういう流れでデータがやり取りされるかについwdtags2xpfKibanafpluginxetitle aAnalyze UIとKibanaのプラグインの作成方法（第3回）vc123:yddate-$Dxcdirjpost/2018/xbid `8cc6b19cd410e638f4beaf1642f4f52axdlangbjayglastmod-$Dxipermalink!Bhttps://blog.johtani.info/blog/2018/03/24/how-to-find-conferences/xkpublishdate Y2018-03-24T13:50:12+09:00xgsummary!P#MANABIYA のブースでセッション時間の合間はお客さん少ないので、ブログを書いてみたり。 ここ数年、スポンサーとして色々なカンファレンスに参加してるんですwdtags2xpgカンファレンスeスポンサーxetitle bカンファレンス情報の探し方（CfP、スポンサー応募、開催期間など）？vc124:yddate,?excdirjpost/2018/xbid `d791eaca9375ca1b36a987af22ee71ddxdlangbjayglastmod,?exipermalink }https://blog.johtani.info/blog/2018/03/20/nlp100-ch01-05to06/xkpublishdate Y2018-03-20T21:34:45+09:00xgsummary!QRustで言語処理100本ノックの続きで、05と06です。 05. n-gram 問題はこちら。 みんな大好きn-gramです。単語と文字があるので、それぞれ別関wdtags2xpdRustfnlp100xetitle ^第1章の05から06までやってみた（言語処理100本ノック）vc125:yddate")(Pxcdirjpost/2018/xbid `e6684944c37dbdd4c08d978af9e47bedxdlangbjayglastmod")(Pxipermalink }https://blog.johtani.info/blog/2018/02/19/nlp100-ch01-03to04/xkpublishdate Y2018-02-19T18:34:08+09:00xgsummary!LRustで言語処理100本ノックの続きで、03と04です。 03. 円周率 問題はこちら。 入力文字列を.split_whitespace()で分割してwdtags2xpdRustfnlp100xetitle ^第1章の03から04までやってみた（言語処理100本ノック）vc126:yddate!Uxcdirjpost/2018/xbid `bbe1deec11d459bdb348051b970abdafxdlangbjayglastmod!Uxipermalink }https://blog.johtani.info/blog/2018/02/15/nlp100-ch01-00to02/xkpublishdate Y2018-02-15T21:59:01+09:00xgsummary!G「鉄は熱いうちに打て」ということで、言語処理100本ノックの第1章の00から02を実装してみました。 さて、これが効率がいいのかどうかはさておwdtags2xpdRustfnlp100xetitle ^第1章の00から02までやってみた（言語処理100本ノック）vc127:yddate!
oxcdirjpost/2018/xbid `a673b3829e62477e01abc75465416b86xdlangbjayglastmod!
oxipermalink!Ahttps://blog.johtani.info/blog/2018/02/14/start-nlp100-with-rust/xkpublishdate Y2018-02-14T19:52:31+09:00xgsummary!bども。新しいもの始めないと頭が退化する。。。ということで、こちら（ happy new year and new language - katsyoshiのめもみたいなもの）のブログに触発されて、wdtags2xpdRustfnlp100xetitle W言語処理100本ノックはじめました(Rust)vc128:yddateqxcdirjpost/2018/xbid `7b6cb59a177abe9767fd22da5a03b1e6xdlangbjayglastmodqxipermalink!Qhttps://blog.johtani.info/blog/2018/02/09/getting-started-template-kibana-plugin/xkpublishdate Y2018-02-09T18:17:37+09:00xgsummary!H第1回では、Analyze UIというプラグインの紹介をしました、ごく簡単にですが。 第2回では、Kibanaのプラグインの作成方法を順を追ってwdtags2xpfKibanafpluginxetitle aAnalyze UIとKibanaのプラグインの作成方法（第2回）vc129:yddate~xcdirjpost/2018/xbid `4afcb20d4d95bcd1bde3aa6b7f552660xdlangbjayglastmod~xipermalink!Xhttps://blog.johtani.info/blog/2018/01/19/how-to-make-kibana-plugin-example-analysis-ui/xkpublishdate Y2018-01-19T15:36:46+09:00xgsummary!Gあけましておめでとうございます。今年はサボりがちだったブログをちょっとずつ復活させようかと。 ということで、第1弾として、昨年少し作っていたKwdtags2xpfKibanafpluginxetitle aAnalyze UIとKibanaのプラグインの作成方法（第1回）vc130:yddate
!sxcdirjpost/2017/xbid `7c21b70f9e9c782c1f5153268e0cc1c1xdlangbjayglastmod
!sxipermalink |https://blog.johtani.info/blog/2017/12/31/looking-back-2017/xkpublishdate Y2017-12-31T21:30:43+09:00xgsummary!J今年は紅白を見ながら書いてます。 今年はいろんなところに出張に行ったなぁ。 振り返り（2016年に書いた抱負から） まずは去年の抱負を元に。 もちろwdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2017）vc131:yddate;Hxcdirjpost/2017/xbid `f3a9b931b7f552a4f9dfa61ce4f39f0exdlangbjayglastmod;Hxipermalink whttps://blog.johtani.info/blog/2017/12/24/elastic-2018/xkpublishdate Y2017-12-24T23:10:16+09:00xgsummary!rMerry Christmas! Elastic Stack Advent Calendar 2017の24日目の記事になります。 ちょっとですが、2018年のElasticについて書いてみようかと思います。 イベント いくつかwdtags1xpmelasticsearchxetitleo2018年のElasticは？vc132:yddate
3pxcdirjpost/2017/xbid `fa0486610d8a02cea245c13c85b6de27xdlangbjayglastmod
3pxipermalink!Jhttps://blog.johtani.info/blog/2017/12/01/whats-happen-at-elastic-in-2017/xkpublishdate Y2017-12-01T00:00:00+09:00xgsummary!pElastic stack (Elasticsearch) Advent Calendar 2017の1日目の記事になります。 まだ、1ヶ月を残していますが、簡単に今年起こったことを振り返ってみようかと思います。思った以上にwdtags1xpmelasticsearchxetitle [2017年のElastic StackとElasticvc1339yddate
.Yxcdirjpost/2017/xbid `c20d71627e66a044b21780f56f2f9504xdlangbjayglastmod
.Yxipermalink {https://blog.johtani.info/blog/2017/11/10/welcome-swiftype/xkpublishdate Y2017-11-10T11:14:49+09:00xgsummary!GSwiftypeでサイト内検索？ プレスリリース：Elasticがサイト内検索サービス最大手のSwiftypeを買収が出ましたが、Swiftyxetitle XSwiftypeがジョインしたので触ってみましたvc134:yddate00>fxcdirjpost/2017/xbid `4f88f3eebe44285ded812939553ef94cxdlangbjayglastmod00>fxipermalink!Phttps://blog.johtani.info/blog/2017/09/21/release-intro-logging-analysis-system/xkpublishdate Y2017-09-21T10:02:30+09:00xgsummary!G久々に執筆しました。といっても、以前の書籍の更新版です。 まぁ、更新版といっても、私以外の方々は結構な量を書き直しor新規書き起こしされてますwdtags3xpmelasticsearchfkibanaa本xetitle Vデータ分析基盤構築入門 を一部執筆しました。vc135:yddate	]xcdirjpost/2017/xbid `29b4c2b5adcd80ced1612128b3ca95a9xdlangbjayglastmod	]xipermalink xhttps://blog.johtani.info/blog/2017/05/25/search-meetup/xkpublishdate Y2017-05-25T00:24:13+09:00xgsummary!I久々のブログ。 Elasticsearch勉強会を主催してますが、 プロダクトを超えて、検索で共通してある課題とか、悩みとか、あるかなぁと。 そのwdtags1xpc勉強会xetitlen検索座談会ってのをやってみたvc136:yddate;Fxcdirjpost/2016/xbid `16f1046144ad9ee7bb96214ba7ae7516xdlangbjayglastmod;Fxipermalink |https://blog.johtani.info/blog/2016/12/31/looking-back-2016/xkpublishdate Y2016-12-31T22:22:14+09:00xgsummary!I今年はRioのプレイバック見ながら書いてます。 今年はなんか長い一年だった気が。 振り返り（2015年に書いた抱負から） まずは去年の抱負を元にwdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2016）vc137:yddate(9Vxcdirjpost/2016/xbid `002d980d74d19b43ff4e2446665e2fe5xdlangbjayglastmod(9Vxipermalink!Chttps://blog.johtani.info/blog/2016/12/25/elasticsearch-6-features/xkpublishdate Y2016-12-25T00:03:50+09:00xgsummary"TMerry Christmas! Elastic stack Advent Calendar 2016 最終日の記事になります。 簡単に今年の変遷を振り返ってみます。 Elasticsearch 2.2 (2月) Elasticsearch 2.2.0、2.1.2、1.7.5リリース クエリプロwdtags1xpmelasticsearchxetitle S2016年のElastic Stackvc138:yddate>Vxcdirjpost/2016/xbid `550becdd08d00fb1e7fd00c2adc3d3d6xdlangbjayglastmod>Vxipermalink!Jhttps://blog.johtani.info/blog/2016/12/01/elasticsearch-5-dot-0-highlight/xkpublishdate Y2016-12-01T17:34:30+09:00xgsummary!oElastic stack Advent Calendar 1日目の記事になります。 Elasticsearch 5.0が10月末にリリースされました。 リリースのブログでいくつか紹介されているのですが、そこでは紹介されてwdtags1xpmelasticsearchxetitle YElasticsearch 5.0の便利機能紹介？vc139:yddate$Pxcdirjpost/2016/xbid `a62186ea292d6db03a087bd5dfcc3f1exdlangbjayglastmod$Pxipermalink![https://blog.johtani.info/blog/2016/07/22/making-ingest-processor-plugin-with-cookiecutter/xkpublishdate Y2016-07-22T13:26:56+09:00xgsummary!N久しぶりに、技術的なブログ書いてます。 Ingest Processorのプラグインを作ってみたくなったので、書いてみました。 ただ書いてみるんじゃ3番煎じwdtags2xpmelasticsearchfpluginxetitle!NLucene Kuromoji for NEologdで指定した品詞の単語を抜き出すIngest Pluginを書いてみた #elasticsearchjpvc140:yddate2Rxcdirjpost/2016/xbid `167e2a6833d49ce198cb3b88f521991exdlangbjayglastmod2Rxipermalink!Hhttps://blog.johtani.info/blog/2016/06/30/broken-something-in-this-year/xkpublishdate Y2016-06-30T10:57:38+09:00xgsummary!Iなんか、今年はよく物が壊れる、厄年だからかなぁ？ ということで、記念に何が壊れたかをブログに残しておこうかと。 腕時計（壊れてないかな） 電波腕時wdtags1xpdmiscxetitlehよく物が壊れる年vc141:yddate 
[xcdirjpost/2016/xbid `993e58f132740b464ecf06ee289dc7b2xdlangbjayglastmod 
[xipermalink!Dhttps://blog.johtani.info/blog/2016/06/28/16th-elasticsearch-meetup/xkpublishdate Y2016-06-28T13:55:55+09:00xgsummary!G第16回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズwdtags2xpmelasticsearchc勉強会xetitle m第16回Elasticsearch勉強会を開催しました。 #elasticsearchjpvc142:yddate:"Dxcdirjpost/2016/xbid `c56a76ef8f604a8d87be2a32b1f81facxdlangbjayglastmod:"Dxipermalink!@https://blog.johtani.info/blog/2016/03/17/15th-elasticsearch-jp/xkpublishdate Y2016-03-17T12:43:00+09:00xgsummary!G第15回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズwdtags2xpmelasticsearchc勉強会xetitle m第15回Elasticsearch勉強会を開催しました。 #elasticsearchjpvc143:yddate9+7Txcdirjpost/2016/xbid `3fc7462a83fa55885067fee629287e8axdlangbjayglastmod9+7Txipermalink!Hhttps://blog.johtani.info/blog/2016/03/14/review-basics-and-tech-of-nlp/xkpublishdate Y2016-03-14T22:34:12+09:00xgsummary!H久々のポスト。。。 久々に、技術書読んでます。「自然言語処理の基本と技術」という本です。 監修の方のツイートを見て気になったので、買ってみましたwdtags1xpa本xetitle S「自然言語処理の基本と技術」を読んでるvc144:yddate#2
Pxcdirjpost/2016/xbid `4b0a768585da8f9f8f8db1ca409e7ebdxdlangbjayglastmod#2
Pxipermalink!Ahttps://blog.johtani.info/blog/2016/01/08/14th-elasticcsearch-jp/xkpublishdate Y2016-01-08T11:34:56+09:00xgsummary!Hあけましておめでとうございます、johtaniです。 第14回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆wdtags2xpmelasticsearchc勉強会xetitle m第14回Elasticsearch勉強会を開催しました。 #elasticsearchjpvc145:yddate!
~xcdirjpost/2015/xbid `c54909ecf4fb3e9afeea36200fe95dcexdlangbjayglastmod!
~xipermalink |https://blog.johtani.info/blog/2015/12/31/looking-back-2015/xkpublishdate Y2015-12-31T21:33:02+09:00xgsummary!K今年は紅白見ながら書いてます。 早い一年だったなぁ。 振り返り(2014年に書いた抱負から) まずは去年の抱負を元に振り返りをば。 英語の継続 海外のwdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2015）vc146:yddateBxcdirjpost/2015/xbid `d819cea5197e9b8673d6c0b16659a5eaxdlangbjayglastmodBxipermalink!Fhttps://blog.johtani.info/blog/2015/12/25/about-elasticsearch-in-2015/xkpublishdate Y2015-12-25T13:29:54+09:00xgsummary!X今年最後のAdvent Calendarとなります。 この記事はElasticsearch Advent Calendar 2015の最終日のエントリです。 簡単に今年の変遷をwdtags1xpmelasticsearchxetitle S2015年のElasticsearchvc147:yddate{xcdirjpost/2015/xbid `1b56132638912a1ca54fcf7cd38b8e23xdlangbjayglastmod{xipermalink!@https://blog.johtani.info/blog/2015/12/01/introduction-timelion/xkpublishdate Y2015-12-01T11:28:11+09:00xgsummary!Hこんにちは、@johtaniです。 早いもので、師走です。今年もあと少しとなりました（今月が一番忙しかったりしますが。。。）。 ということで、Awdtags2xpfkibanahtimelionxetitle tTimelionの紹介 - Elasticsearch Advent Calendar 2015 1日目vc148:yddate%bxcdirjpost/2015/xbid `2ea86ae5093670df1d4502ea82efa1acxdlangbjayglastmod%bxipermalink!@https://blog.johtani.info/blog/2015/11/10/13th-elasticsearch-jp/xkpublishdate Y2015-11-10T17:22:58+09:00xgsummary!G第13回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズwdtags2xpmelasticsearchc勉強会xetitle l第13回Elasticsearch勉強会を開催しました。#elasticsearchjpvc149:yddate3
jxcdirjpost/2015/xbid `5912529cfd6ce14c5ede5c6c83dae7e8xdlangbjayglastmod3
jxipermalink https://blog.johtani.info/blog/2015/10/30/sense-2-0-0-beta1-ja/xkpublishdate Y2015-10-30T17:55:06+09:00xgsummary!p※この記事は次のブログを翻訳したものになります。 原文：The Story of Sense - Announcing Sense 2.0.0-beta1 誕生 よくある良いプロジェクト同様、Senseもビールを飲みながら考wdtags2xpmelasticsearchesensexetitle eSenseの歴史 - Sense 2.0.0-beta1の紹介(日本語訳)vc150:yddate1){xcdirjpost/2015/xbid `15700442e957951307bbcec5fff8643dxdlangbjayglastmod1){xipermalink!Whttps://blog.johtani.info/blog/2015/10/30/shield-watcher-and-marvel-2-0-ga-released-ja/xkpublishdate Y2015-10-30T16:21:31+09:00xgsummary!h※この記事は次のブログを翻訳したものになります。 原文：Shield, Watcher, and Marvel 2.0.0 GA Released 本日（10/28）Shield、WatcherおよびMarvwdtags4xpmelasticsearchfshieldgwatcherfmarvelxetitle hShield、Watcher、Marvel 2.0.0 GAリリース（日本語訳）vc151:yddate#Kxcdirjpost/2015/xbid `018e32a8010960eb17e368a6fdd5a51bxdlangbjayglastmod#Kxipermalink!Jhttps://blog.johtani.info/blog/2015/10/29/elasticsearch-2-0-0-released-ja/xkpublishdate Y2015-10-29T16:20:43+09:00xgsummary!e※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0 GA released Elasticsearch 1.0.0のリリース以降、 477のコミッター2,79wdtags1xpmelasticsearchxetitle ]Elasticsearch 2.0.0リリース(日本語訳)vc152:yddate"sxcdirjpost/2015/xbid `e159a35d1b9a46e03072a3d54780edcbxdlangbjayglastmod"sxipermalink zhttps://blog.johtani.info/blog/2015/10/29/kibana-4-2-0-ja/xkpublishdate Y2015-10-29T16:20:19+09:00xgsummary"@※この記事は次のブログを翻訳したものになります。 原文：Kibana 4.2.0 released Elasticsearch 2.0 + Kibana 4.2 = 💚 Elasticsearch 2.0サポートのKibanaの最初のリリースです。 これwdtags2xpgelasticfkibanaxetitle VKibana 4.2.0リリース（日本語訳）vc153:yddate"]xcdirjpost/2015/xbid `cc64c2fcdecdb505b3797e1aaaa59adcxdlangbjayglastmod"]xipermalink!Ehttps://blog.johtani.info/blog/2015/10/29/logstash-2-0-0-released-ja/xkpublishdate Y2015-10-29T16:19:57+09:00xgsummary!^※この記事は次のブログを翻訳したものになります。 原文：Logstash 2.0.0 released Logstash 2.0.0が本日（10/28）リリースされました。 このリリースはwdtags2xpgelastichlogstashxetitle XLogstash 2.0.0リリース（日本語訳）vc154:yddate1Cxcdirjpost/2015/xbid `4cc08ca51ecf0f963035f039de6194c5xdlangbjayglastmod1Cxipermalink }https://blog.johtani.info/blog/2015/10/29/release-we-have-ja/xkpublishdate Y2015-10-29T14:18:59+09:00xgsummary!O※この記事は次のブログを翻訳したものになります。 原文：Relase, we have ※画像に関しては原文をご覧ください。 Elasticにとって大きな1日wdtags3xpmelasticsearchfkibanahlogstashxetitle VRelease, we have（日本語訳）vc155:yddate></mxcdirjpost/2015/xbid `4b227d61f33182579cd3edd0ac6c7c44xdlangbjayglastmod></mxipermalink!Phttps://blog.johtani.info/blog/2015/09/18/elasticsearch-2-0-0-beta2-released-ja/xkpublishdate Y2015-09-18T17:31:41+09:00xgsummary!\※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0-beta2 released 本日（9/17）、Lucene 5.2.1ベースのElaswdtags1xpmelasticsearchxetitle cElasticsearch 2.0.0-beta2リリース（日本語訳）vc156:yddate7<<Jxcdirjpost/2015/xbid `0de0edbf2a506143c1739b12e94c0ef9xdlangbjayglastmod7<<Jxipermalink!Ehttps://blog.johtani.info/blog/2015/08/28/elasticsearch-unplugged-ja/xkpublishdate Y2015-08-28T12:01:30+09:00xgsummary!h※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch unplugged - Networking changes in 2.0 Elasticsearchをローカルのマシンで起wdtags1xpmelasticsearchxetitle pElasticsearch unplugged - 2.0におけるネットワークの変更(日本語訳)vc157:yddate7&hxcdirjpost/2015/xbid `744554499cb7880086fbd9b1f080e7e1xdlangbjayglastmod7&hxipermalink!Phttps://blog.johtani.info/blog/2015/08/27/elasticsearch-2-0-0-beta1-released-ja/xkpublishdate Y2015-08-27T10:29:12+09:00xgsummary!\※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0-beta1 released 本日（8/26）、Lucene 5.2.1ベースのElaswdtags1xpmelasticsearchxetitle cElasticsearch 2.0.0-beta1リリース（日本語訳）vc158:yddate5dxcdirjpost/2015/xbid `5a9e950f4ac186925e5de978c5f72062xdlangbjayglastmod5dxipermalink!Nhttps://blog.johtani.info/blog/2015/08/20/core-delete-by-query-is-a-plugin-ja/xkpublishdate Y2015-08-20T13:24:04+09:00xgsummary!d※この記事は次のブログを翻訳したものになります。 原文：The Delete by Query API Is now a plugin Elasticsearchの2.0.0-beta1では、これまでwdtags1xpmelasticsearchxetitle `Delete by Query APIはプラグインへ（日本語訳）vc159:yddate.0*axcdirjpost/2015/xbid `73b8194ad8fce0cabb01cd21d5e18500xdlangbjayglastmod.0*axipermalink!@https://blog.johtani.info/blog/2015/07/31/11th-elasticsearch-jp/xkpublishdate Y2015-07-31T14:41:53+09:00xgsummary!G第11回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズwdtags2xpmelasticsearchc勉強会xetitle l第11回Elasticsearch勉強会を開催しました。#elasticsearchjpvc160:yddate."ixcdirjpost/2015/xbid `100c0a69bea7f02a0f4540ecaa37d0e3xdlangbjayglastmod."ixipermalink!Thttps://blog.johtani.info/blog/2015/07/29/elasticsearch-1-7-1-and-1-6-2-released-ja/xkpublishdate Y2015-07-29T21:35:53+09:00xgsummary!^※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.1 and 1.6.2 released 本日（7/29）、Lucene 4.10.4ベースのEwdtags1xpmelasticsearchxetitle gElasticsearch 1.7.1 および 1.6.2リリース（日本語訳）vc161:yddate+3%Axcdirjpost/2015/xbid `809925e891b0456231c374b09cbe4a90xdlangbjayglastmod+3%Axipermalink!Thttps://blog.johtani.info/blog/2015/07/22/elasticsearch-1-7-0-and-1-6-1-released-ja/xkpublishdate Y2015-07-22T15:33:37+09:00xgsummary!^※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.0 and 1.6.1 released 本日（7/16）、Lucene 4.10.4ベースのEwdtags1xpmelasticsearchxetitle gElasticsearch 1.7.0 および 1.6.1リリース（日本語訳）vc162:yddate)0.ixcdirjpost/2015/xbid `dd6c32a722dc815273cd9ed8cd6c671bxdlangbjayglastmod)0.ixipermalink!Fhttps://blog.johtani.info/blog/2015/07/16/kansai-1st-elasticsearch-jp/xkpublishdate Y2015-07-16T10:40:57+09:00xgsummary!N東京以外での勉強会の第2弾として、関西で勉強会を開催してきました。 Elasticsearch勉強会 in 大阪 Elasticsearch勉強会 in 京wdtags2xpc勉強会melasticsearchxetitle o大阪と京都でElasticsearch勉強会を開催しました。 #elasticsearchjpvc163:yddate'%Cxcdirjpost/2015/xbid `ee4ff9e4e8a1948795e26af2f3f8a30fxdlangbjayglastmod'%Cxipermalink!Ghttps://blog.johtani.info/blog/2015/07/08/great-mapping-refactoring-ja/xkpublishdate Y2015-07-08T18:11:31+09:00xgsummary!`※この記事は次のブログを翻訳したものになります。 原文：The Great Mapping Refactoring Elasticsearchのユーザの悩みの最も大きなものの一つは、 タイプとwdtags1xpmelasticsearchxetitle [Mappingのすばらしいリファクタリング（日本語訳）vc164:yddate&7|xcdirjpost/2015/xbid `f887e1aabf801e351bfb39698f208af1xdlangbjayglastmod&7|xipermalink![https://blog.johtani.info/blog/2015/07/07/elasticsearch-2-dot-0-0-dot-beta1-coming-soon-ja/xkpublishdate Y2015-07-07T15:25:00+09:00xgsummary!k※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0.beta1 coming soon! Elasticsearch 2.0.0.beta1のリリースの準備をしています。wdtags1xpmelasticsearchxetitle eElasticsearch 2.0.0.beta1リリース間近（日本語訳）vc165:yddate&6>Pxcdirjpost/2015/xbid `9cc2a0b6c8be1405cddcdeb4487c59fexdlangbjayglastmod&6>Pxipermalink!Mhttps://blog.johtani.info/blog/2015/07/07/we-just-made-found-more-awesome-ja/xkpublishdate Y2015-07-07T15:20:00+09:00xgsummary!W4ヶ月前に、Found joined our team at Elasticをアナウンスしました。 Foundの素晴らしいチームと一緒に仕事をしていますが、彼らによって、よりwdtags2xpmelasticsearchhfound.noxetitle Rさらに進化したFound（日本語訳）vc166:yddate&:Mxcdirjpost/2015/xbid `18b7998a871950ebc36c415a53630477xdlangbjayglastmod&:Mxipermalink!Ihttps://blog.johtani.info/blog/2015/07/06/attend-justsystem-techtalk-no2/xkpublishdate Y2015-07-06T10:49:01+09:00xgsummary!WJustTechTalk#02 形態素解析のあれやこれや@ジャストシステム に参加してきました。 ジャストシステムさんの形態素解析器JMATの話とKagome、Janome、wdtags1xpc勉強会xetitle mJustTechTalk#02 形態素解析のあれやこれや@ジャストシステムに参加しました。vc167:yddate ;}xcdirjpost/2015/xbid `ddab6357ff522c0c956ebd7669e83454xdlangbjayglastmod ;}xipermalink!Khttps://blog.johtani.info/blog/2015/06/17/attend-hatena-engineer-seminar-5/xkpublishdate Y2015-06-17T00:21:33+09:00xgsummary!aひさびさに、勉強会メモ。 Hatena Engineer Seminar #5 @ Tokyoに当選したので行ってきました。 いつもは近寄らないオシャレな街をドキドキしながら行ってきました。 とwdtags1xpc勉強会xetitle vHatena Engineer Seminar #5 @ Tokyoに参加しました。 #hatenatechvc168:yddate;6Fxcdirjpost/2015/xbid `55188a318c5998989255253e15ccc1f6xdlangbjayglastmod;6Fxipermalink!Jhttps://blog.johtani.info/blog/2015/06/10/elasticsearch-1-6-0-released-ja/xkpublishdate Y2015-06-10T13:31:02+09:00xgsummary!V※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.6.0 released 本日（6/9）、Lucene 4.10.4ベースのElaswdtags1xpmelasticsearchxetitle ]Elasticsearch 1.6.0リリース（日本語訳）vc169:yddatelxcdirjpost/2015/xbid `75d9268739fe7787ac02d389ac605febxdlangbjayglastmodlxipermalink!@https://blog.johtani.info/blog/2015/06/02/10th-elasticsearch-jp/xkpublishdate Y2015-06-02T15:06:36+09:00xgsummary!G第10回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさwdtags2xpmelasticsearchc勉強会xetitle l第10回Elasticsearch勉強会を開催しました。#elasticsearchjpvc170:yddate
/Zxcdirjpost/2015/xbid `23a22d1411afb787810d68210e6fad4fxdlangbjayglastmod
/Zxipermalink!Qhttps://blog.johtani.info/blog/2015/05/26/reindex-elasticsearch-with-logstash-ja/xkpublishdate Y2015-05-26T16:08:10+09:00xgsummary!m※この記事は次のブログを翻訳したものになります。 原文：Reindex Elasticsearch With Logstash Thanks David! マッピングを変更したり、インデックスの設定を変更したり、あるサwdtags2xphlogstashmelasticsearchxetitle gLogstashを使ったElasticsearchの再インデックス（日本語訳）vc1719yddate,Oxcdirjpost/2015/xbid `615db1a24f36d19a8eaf18d4dceed6b2xdlangbjayglastmod,Oxipermalink!Chttps://blog.johtani.info/blog/2015/05/21/join-the-conversation-ja/xkpublishdate Y2015-05-21T17:45:03+09:00xgsummary!k※この記事は次のブログを翻訳したものになります。 原文：Join the Conversation: Discuss.Elastic.Co 3つのOSSプロジェクトの開発をスケールアップし始め、 コミュニティサポーxetitle Ydiscuss.elastic.co にぜひ参加をvc172:yddate2pxcdirjpost/2015/xbid `8d7caf84b3a51cca27291c1f7cfc2d40xdlangbjayglastmod2pxipermalink!Thttps://blog.johtani.info/blog/2015/04/28/elasticsearch-1-5-2-and-1-4-5-released-ja/xkpublishdate Y2015-04-28T15:14:08+09:00xgsummary!V※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.2 Released 本日（4/27）、Lucene 4.10.4ベースのElawdtags1xpmelasticsearchxetitle gElasticsearch 1.5.2 および 1.4.5リリース（日本語訳）vc173:yddate	4bxcdirjpost/2015/xbid `7249710187cc2d983709e044dbc78d9dxdlangbjayglastmod	4bxipermalink https://blog.johtani.info/blog/2015/04/17/9th-elasticsearch-jp/xkpublishdate Y2015-04-17T14:41:54+09:00xgsummary!G第9回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさんwdtags2xpmelasticsearchc勉強会xetitle k第9回Elasticsearch勉強会を開催しました。#elasticsearchjpvc174:yddate
+exipermalink |https://blog.johtani.info/blog/2018/12/31/looking-back-2018/xkpublishdate Y2018-12-31T16:14:45+09:00xgsummary!J今年も振り返りブログをかけてます。よかったw 振り返り（2017年に書いた抱負から） まずは去年の抱負を元に。 もっと英語の継続＆TOEIC まぁ、wdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2018）vc118:yddateqxcdirjpost/2018/xbid `ee62cb0b9a97f990df1ed0266a7027e2xdlangbjayglastmodqxipermalink!Ghttps://blog.johtani.info/blog/2018/12/25/whats-new-in-elastic-stack-7/xkpublishdate Y2018-12-25T00:00:01+09:00xgsummary!rElastic stack (Elasticsearch) Advent Calendar 2018の25日目の記事になります。 今年最後のAdvent Calendarです！来年も忘れてなければやるはず！ 今日は、すでにalpwdtags1xpmelasticsearchxetitle aElastic Stack 7.0で入ってくる新機能をちょっと紹介vc119:yddate!vxcdirjpost/2018/xbid `ba45ddd3042dad59a12e5937644f7246xdlangbjayglastmod!vxipermalink!Jhttps://blog.johtani.info/blog/2018/12/01/whats-happen-at-elastic-in-2018/xkpublishdate Y2018-12-01T10:48:38+09:00xgsummary!qElastic stack (Elasticsearch) Advent Calendar 2018の1日目の記事になります。 ちょっと遅れちゃいました。。。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみよwdtags1xpmelasticsearchxetitle [2018年のElastic StackとElasticvc120:yddate16oxcdirjpost/2018/xbid `3fd9052870778e14ab4a5acbc8c24af4xdlangbjayglastmod16oxipermalink!Fhttps://blog.johtani.info/blog/2018/10/18/items-for-long-businesstrip/xkpublishdate Y2018-10-18T01:34:55+09:00xgsummary!G（転職する少し前までパスポートすら持ってなかったのに）今の会社に転職してから、半年に1度の割合で海外への出張が発生する生活を送っています。 4wdtags1xpdmiscxetitle W新規導入した長期出張用のアイテムをいくつか紹介vc121:yddate1/nxcdirjpost/2018/xbid `d3fa23c9066f943f10e8883de9340deaxdlangbjayglastmod1/nxipermalink!Jhttps://blog.johtani.info/blog/2018/10/17/26th-elasticsearch-tokyo-meetup/xkpublishdate Y2018-10-17T17:33:50+09:00xgsummary!H毎月開催の2回目になります。 今回は日経さんの会場をお借りしての開催となりました。 前回から、スピーカーの募集をhttp://bit.ly/Spwdtags2xpmelasticsearchc勉強会xetitle \第25回Elasticsearch勉強会を開催しました。vc122:yddatezxcdirjpost/2018/xbid `10ae016e19fff6ae9cfaeb8534fa47f9xdlangbjayglastmodzxipermalink {https://blog.johtani.info/blog/2018/07/29/apm-java-at-jjug/xkpublishdate Y2018-07-29T14:45:30+09:00xgsummary!I7/25にJJUGナイトセミナーでElastic Stackの紹介とAPMのJava Agentの紹介をしたので、補足のブログです。 （久々に書くwdtags1xpc勉強会xetitle QJJUGナイトセミナーで話しましたvc123:yddate6#ixcdirjpost/2018/xbid `04d818cbaac08b2915db15e0bffdcb5bxdlangbjayglastmod6#ixipermalink!Lhttps://blog.johtani.info/blog/2018/04/20/directory-layout-and-architecture/xkpublishdate Y2018-04-20T15:30:01+09:00xgsummary!F第2回から少し間が空いてしまいましたが、templateで作成したプラグインのディレクトリ構成とどういう流れでデータがやり取りされるかについwdtags2xpfKibanafpluginxetitle aAnalyze UIとKibanaのプラグインの作成方法（第3回）vc124:yddate-$Dxcdirjpost/2018/xbid `8cc6b19cd410e638f4beaf1642f4f52axdlangbjayglastmod-$Dxipermalink!Bhttps://blog.johtani.info/blog/2018/03/24/how-to-find-conferences/xkpublishdate Y2018-03-24T13:50:12+09:00xgsummary!P#MANABIYA のブースでセッション時間の合間はお客さん少ないので、ブログを書いてみたり。 ここ数年、スポンサーとして色々なカンファレンスに参加してるんですwdtags2xpgカンファレンスeスポンサーxetitle bカンファレンス情報の探し方（CfP、スポンサー応募、開催期間など）？vc125:yddate,?excdirjpost/2018/xbid `d791eaca9375ca1b36a987af22ee71ddxdlangbjayglastmod,?exipermalink }https://blog.johtani.info/blog/2018/03/20/nlp100-ch01-05to06/xkpublishdate Y2018-03-20T21:34:45+09:00xgsummary!QRustで言語処理100本ノックの続きで、05と06です。 05. n-gram 問題はこちら。 みんな大好きn-gramです。単語と文字があるので、それぞれ別関wdtags2xpdRustfnlp100xetitle ^第1章の05から06までやってみた（言語処理100本ノック）vc126:yddate")(Pxcdirjpost/2018/xbid `e6684944c37dbdd4c08d978af9e47bedxdlangbjayglastmod")(Pxipermalink }https://blog.johtani.info/blog/2018/02/19/nlp100-ch01-03to04/xkpublishdate Y2018-02-19T18:34:08+09:00xgsummary!LRustで言語処理100本ノックの続きで、03と04です。 03. 円周率 問題はこちら。 入力文字列を.split_whitespace()で分割してwdtags2xpdRustfnlp100xetitle ^第1章の03から04までやってみた（言語処理100本ノック）vc127:yddate!Uxcdirjpost/2018/xbid `bbe1deec11d459bdb348051b970abdafxdlangbjayglastmod!Uxipermalink }https://blog.johtani.info/blog/2018/02/15/nlp100-ch01-00to02/xkpublishdate Y2018-02-15T21:59:01+09:00xgsummary!G「鉄は熱いうちに打て」ということで、言語処理100本ノックの第1章の00から02を実装してみました。 さて、これが効率がいいのかどうかはさておwdtags2xpdRustfnlp100xetitle ^第1章の00から02までやってみた（言語処理100本ノック）vc128:yddate!
oxcdirjpost/2018/xbid `a673b3829e62477e01abc75465416b86xdlangbjayglastmod!
oxipermalink!Ahttps://blog.johtani.info/blog/2018/02/14/start-nlp100-with-rust/xkpublishdate Y2018-02-14T19:52:31+09:00xgsummary!bども。新しいもの始めないと頭が退化する。。。ということで、こちら（ happy new year and new language - katsyoshiのめもみたいなもの）のブログに触発されて、wdtags2xpdRustfnlp100xetitle W言語処理100本ノックはじめました(Rust)vc129:yddateqxcdirjpost/2018/xbid `7b6cb59a177abe9767fd22da5a03b1e6xdlangbjayglastmodqxipermalink!Qhttps://blog.johtani.info/blog/2018/02/09/getting-started-template-kibana-plugin/xkpublishdate Y2018-02-09T18:17:37+09:00xgsummary!H第1回では、Analyze UIというプラグインの紹介をしました、ごく簡単にですが。 第2回では、Kibanaのプラグインの作成方法を順を追ってwdtags2xpfKibanafpluginxetitle aAnalyze UIとKibanaのプラグインの作成方法（第2回）vc130:yddate~xcdirjpost/2018/xbid `4afcb20d4d95bcd1bde3aa6b7f552660xdlangbjayglastmod~xipermalink!Xhttps://blog.johtani.info/blog/2018/01/19/how-to-make-kibana-plugin-example-analysis-ui/xkpublishdate Y2018-01-19T15:36:46+09:00xgsummary!Gあけましておめでとうございます。今年はサボりがちだったブログをちょっとずつ復活させようかと。 ということで、第1弾として、昨年少し作っていたKwdtags2xpfKibanafpluginxetitle aAnalyze UIとKibanaのプラグインの作成方法（第1回）vc131:yddate
!sxcdirjpost/2017/xbid `7c21b70f9e9c782c1f5153268e0cc1c1xdlangbjayglastmod
!sxipermalink |https://blog.johtani.info/blog/2017/12/31/looking-back-2017/xkpublishdate Y2017-12-31T21:30:43+09:00xgsummary!J今年は紅白を見ながら書いてます。 今年はいろんなところに出張に行ったなぁ。 振り返り（2016年に書いた抱負から） まずは去年の抱負を元に。 もちろwdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2017）vc132:yddate;Hxcdirjpost/2017/xbid `f3a9b931b7f552a4f9dfa61ce4f39f0exdlangbjayglastmod;Hxipermalink whttps://blog.johtani.info/blog/2017/12/24/elastic-2018/xkpublishdate Y2017-12-24T23:10:16+09:00xgsummary!rMerry Christmas! Elastic Stack Advent Calendar 2017の24日目の記事になります。 ちょっとですが、2018年のElasticについて書いてみようかと思います。 イベント いくつかwdtags1xpmelasticsearchxetitleo2018年のElasticは？vc133:yddate
3pxcdirjpost/2017/xbid `fa0486610d8a02cea245c13c85b6de27xdlangbjayglastmod
3pxipermalink!Jhttps://blog.johtani.info/blog/2017/12/01/whats-happen-at-elastic-in-2017/xkpublishdate Y2017-12-01T00:00:00+09:00xgsummary!pElastic stack (Elasticsearch) Advent Calendar 2017の1日目の記事になります。 まだ、1ヶ月を残していますが、簡単に今年起こったことを振り返ってみようかと思います。思った以上にwdtags1xpmelasticsearchxetitle [2017年のElastic StackとElasticvc1349yddate
.Yxcdirjpost/2017/xbid `c20d71627e66a044b21780f56f2f9504xdlangbjayglastmod
.Yxipermalink {https://blog.johtani.info/blog/2017/11/10/welcome-swiftype/xkpublishdate Y2017-11-10T11:14:49+09:00xgsummary!GSwiftypeでサイト内検索？ プレスリリース：Elasticがサイト内検索サービス最大手のSwiftypeを買収が出ましたが、Swiftyxetitle XSwiftypeがジョインしたので触ってみましたvc135:yddate00>fxcdirjpost/2017/xbid `4f88f3eebe44285ded812939553ef94cxdlangbjayglastmod00>fxipermalink!Phttps://blog.johtani.info/blog/2017/09/21/release-intro-logging-analysis-system/xkpublishdate Y2017-09-21T10:02:30+09:00xgsummary!G久々に執筆しました。といっても、以前の書籍の更新版です。 まぁ、更新版といっても、私以外の方々は結構な量を書き直しor新規書き起こしされてますwdtags3xpmelasticsearchfkibanaa本xetitle Vデータ分析基盤構築入門 を一部執筆しました。vc136:yddate	]xcdirjpost/2017/xbid `29b4c2b5adcd80ced1612128b3ca95a9xdlangbjayglastmod	]xipermalink xhttps://blog.johtani.info/blog/2017/05/25/search-meetup/xkpublishdate Y2017-05-25T00:24:13+09:00xgsummary!I久々のブログ。 Elasticsearch勉強会を主催してますが、 プロダクトを超えて、検索で共通してある課題とか、悩みとか、あるかなぁと。 そのwdtags1xpc勉強会xetitlen検索座談会ってのをやってみたvc137:yddate;Fxcdirjpost/2016/xbid `16f1046144ad9ee7bb96214ba7ae7516xdlangbjayglastmod;Fxipermalink |https://blog.johtani.info/blog/2016/12/31/looking-back-2016/xkpublishdate Y2016-12-31T22:22:14+09:00xgsummary!I今年はRioのプレイバック見ながら書いてます。 今年はなんか長い一年だった気が。 振り返り（2015年に書いた抱負から） まずは去年の抱負を元にwdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2016）vc138:yddate(9Vxcdirjpost/2016/xbid `002d980d74d19b43ff4e2446665e2fe5xdlangbjayglastmod(9Vxipermalink!Chttps://blog.johtani.info/blog/2016/12/25/elasticsearch-6-features/xkpublishdate Y2016-12-25T00:03:50+09:00xgsummary"TMerry Christmas! Elastic stack Advent Calendar 2016 最終日の記事になります。 簡単に今年の変遷を振り返ってみます。 Elasticsearch 2.2 (2月) Elasticsearch 2.2.0、2.1.2、1.7.5リリース クエリプロwdtags1xpmelasticsearchxetitle S2016年のElastic Stackvc139:yddate>Vxcdirjpost/2016/xbid `550becdd08d00fb1e7fd00c2adc3d3d6xdlangbjayglastmod>Vxipermalink!Jhttps://blog.johtani.info/blog/2016/12/01/elasticsearch-5-dot-0-highlight/xkpublishdate Y2016-12-01T17:34:30+09:00xgsummary!oElastic stack Advent Calendar 1日目の記事になります。 Elasticsearch 5.0が10月末にリリースされました。 リリースのブログでいくつか紹介されているのですが、そこでは紹介されてwdtags1xpmelasticsearchxetitle YElasticsearch 5.0の便利機能紹介？vc140:yddate$Pxcdirjpost/2016/xbid `a62186ea292d6db03a087bd5dfcc3f1exdlangbjayglastmod$Pxipermalink![https://blog.johtani.info/blog/2016/07/22/making-ingest-processor-plugin-with-cookiecutter/xkpublishdate Y2016-07-22T13:26:56+09:00xgsummary!N久しぶりに、技術的なブログ書いてます。 Ingest Processorのプラグインを作ってみたくなったので、書いてみました。 ただ書いてみるんじゃ3番煎じwdtags2xpmelasticsearchfpluginxetitle!NLucene Kuromoji for NEologdで指定した品詞の単語を抜き出すIngest Pluginを書いてみた #elasticsearchjpvc141:yddate2Rxcdirjpost/2016/xbid `167e2a6833d49ce198cb3b88f521991exdlangbjayglastmod2Rxipermalink!Hhttps://blog.johtani.info/blog/2016/06/30/broken-something-in-this-year/xkpublishdate Y2016-06-30T10:57:38+09:00xgsummary!Iなんか、今年はよく物が壊れる、厄年だからかなぁ？ ということで、記念に何が壊れたかをブログに残しておこうかと。 腕時計（壊れてないかな） 電波腕時wdtags1xpdmiscxetitlehよく物が壊れる年vc142:yddate 
[xcdirjpost/2016/xbid `993e58f132740b464ecf06ee289dc7b2xdlangbjayglastmod 
[xipermalink!Dhttps://blog.johtani.info/blog/2016/06/28/16th-elasticsearch-meetup/xkpublishdate Y2016-06-28T13:55:55+09:00xgsummary!G第16回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズwdtags2xpmelasticsearchc勉強会xetitle m第16回Elasticsearch勉強会を開催しました。 #elasticsearchjpvc143:yddate:"Dxcdirjpost/2016/xbid `c56a76ef8f604a8d87be2a32b1f81facxdlangbjayglastmod:"Dxipermalink!@https://blog.johtani.info/blog/2016/03/17/15th-elasticsearch-jp/xkpublishdate Y2016-03-17T12:43:00+09:00xgsummary!G第15回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズwdtags2xpmelasticsearchc勉強会xetitle m第15回Elasticsearch勉強会を開催しました。 #elasticsearchjpvc144:yddate9+7Txcdirjpost/2016/xbid `3fc7462a83fa55885067fee629287e8axdlangbjayglastmod9+7Txipermalink!Hhttps://blog.johtani.info/blog/2016/03/14/review-basics-and-tech-of-nlp/xkpublishdate Y2016-03-14T22:34:12+09:00xgsummary!H久々のポスト。。。 久々に、技術書読んでます。「自然言語処理の基本と技術」という本です。 監修の方のツイートを見て気になったので、買ってみましたwdtags1xpa本xetitle S「自然言語処理の基本と技術」を読んでるvc145:yddate#2
Pxcdirjpost/2016/xbid `4b0a768585da8f9f8f8db1ca409e7ebdxdlangbjayglastmod#2
Pxipermalink!Ahttps://blog.johtani.info/blog/2016/01/08/14th-elasticcsearch-jp/xkpublishdate Y2016-01-08T11:34:56+09:00xgsummary!Hあけましておめでとうございます、johtaniです。 第14回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆wdtags2xpmelasticsearchc勉強会xetitle m第14回Elasticsearch勉強会を開催しました。 #elasticsearchjpvc146:yddate!
~xcdirjpost/2015/xbid `c54909ecf4fb3e9afeea36200fe95dcexdlangbjayglastmod!
~xipermalink |https://blog.johtani.info/blog/2015/12/31/looking-back-2015/xkpublishdate Y2015-12-31T21:33:02+09:00xgsummary!K今年は紅白見ながら書いてます。 早い一年だったなぁ。 振り返り(2014年に書いた抱負から) まずは去年の抱負を元に振り返りをば。 英語の継続 海外のwdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2015）vc147:yddateBxcdirjpost/2015/xbid `d819cea5197e9b8673d6c0b16659a5eaxdlangbjayglastmodBxipermalink!Fhttps://blog.johtani.info/blog/2015/12/25/about-elasticsearch-in-2015/xkpublishdate Y2015-12-25T13:29:54+09:00xgsummary!X今年最後のAdvent Calendarとなります。 この記事はElasticsearch Advent Calendar 2015の最終日のエントリです。 簡単に今年の変遷をwdtags1xpmelasticsearchxetitle S2015年のElasticsearchvc148:yddate{xcdirjpost/2015/xbid `1b56132638912a1ca54fcf7cd38b8e23xdlangbjayglastmod{xipermalink!@https://blog.johtani.info/blog/2015/12/01/introduction-timelion/xkpublishdate Y2015-12-01T11:28:11+09:00xgsummary!Hこんにちは、@johtaniです。 早いもので、師走です。今年もあと少しとなりました（今月が一番忙しかったりしますが。。。）。 ということで、Awdtags2xpfkibanahtimelionxetitle tTimelionの紹介 - Elasticsearch Advent Calendar 2015 1日目vc149:yddate%bxcdirjpost/2015/xbid `2ea86ae5093670df1d4502ea82efa1acxdlangbjayglastmod%bxipermalink!@https://blog.johtani.info/blog/2015/11/10/13th-elasticsearch-jp/xkpublishdate Y2015-11-10T17:22:58+09:00xgsummary!G第13回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズwdtags2xpmelasticsearchc勉強会xetitle l第13回Elasticsearch勉強会を開催しました。#elasticsearchjpvc150:yddate3
jxcdirjpost/2015/xbid `5912529cfd6ce14c5ede5c6c83dae7e8xdlangbjayglastmod3
jxipermalink https://blog.johtani.info/blog/2015/10/30/sense-2-0-0-beta1-ja/xkpublishdate Y2015-10-30T17:55:06+09:00xgsummary!p※この記事は次のブログを翻訳したものになります。 原文：The Story of Sense - Announcing Sense 2.0.0-beta1 誕生 よくある良いプロジェクト同様、Senseもビールを飲みながら考wdtags2xpmelasticsearchesensexetitle eSenseの歴史 - Sense 2.0.0-beta1の紹介(日本語訳)vc151:yddate1){xcdirjpost/2015/xbid `15700442e957951307bbcec5fff8643dxdlangbjayglastmod1){xipermalink!Whttps://blog.johtani.info/blog/2015/10/30/shield-watcher-and-marvel-2-0-ga-released-ja/xkpublishdate Y2015-10-30T16:21:31+09:00xgsummary!h※この記事は次のブログを翻訳したものになります。 原文：Shield, Watcher, and Marvel 2.0.0 GA Released 本日（10/28）Shield、WatcherおよびMarvwdtags4xpmelasticsearchfshieldgwatcherfmarvelxetitle hShield、Watcher、Marvel 2.0.0 GAリリース（日本語訳）vc152:yddate#Kxcdirjpost/2015/xbid `018e32a8010960eb17e368a6fdd5a51bxdlangbjayglastmod#Kxipermalink!Jhttps://blog.johtani.info/blog/2015/10/29/elasticsearch-2-0-0-released-ja/xkpublishdate Y2015-10-29T16:20:43+09:00xgsummary!e※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0 GA released Elasticsearch 1.0.0のリリース以降、 477のコミッター2,79wdtags1xpmelasticsearchxetitle ]Elasticsearch 2.0.0リリース(日本語訳)vc153:yddate"sxcdirjpost/2015/xbid `e159a35d1b9a46e03072a3d54780edcbxdlangbjayglastmod"sxipermalink zhttps://blog.johtani.info/blog/2015/10/29/kibana-4-2-0-ja/xkpublishdate Y2015-10-29T16:20:19+09:00xgsummary"@※この記事は次のブログを翻訳したものになります。 原文：Kibana 4.2.0 released Elasticsearch 2.0 + Kibana 4.2 = 💚 Elasticsearch 2.0サポートのKibanaの最初のリリースです。 これwdtags2xpgelasticfkibanaxetitle VKibana 4.2.0リリース（日本語訳）vc154:yddate"]xcdirjpost/2015/xbid `cc64c2fcdecdb505b3797e1aaaa59adcxdlangbjayglastmod"]xipermalink!Ehttps://blog.johtani.info/blog/2015/10/29/logstash-2-0-0-released-ja/xkpublishdate Y2015-10-29T16:19:57+09:00xgsummary!^※この記事は次のブログを翻訳したものになります。 原文：Logstash 2.0.0 released Logstash 2.0.0が本日（10/28）リリースされました。 このリリースはwdtags2xpgelastichlogstashxetitle XLogstash 2.0.0リリース（日本語訳）vc155:yddate1Cxcdirjpost/2015/xbid `4cc08ca51ecf0f963035f039de6194c5xdlangbjayglastmod1Cxipermalink }https://blog.johtani.info/blog/2015/10/29/release-we-have-ja/xkpublishdate Y2015-10-29T14:18:59+09:00xgsummary!O※この記事は次のブログを翻訳したものになります。 原文：Relase, we have ※画像に関しては原文をご覧ください。 Elasticにとって大きな1日wdtags3xpmelasticsearchfkibanahlogstashxetitle VRelease, we have（日本語訳）vc156:yddate></mxcdirjpost/2015/xbid `4b227d61f33182579cd3edd0ac6c7c44xdlangbjayglastmod></mxipermalink!Phttps://blog.johtani.info/blog/2015/09/18/elasticsearch-2-0-0-beta2-released-ja/xkpublishdate Y2015-09-18T17:31:41+09:00xgsummary!\※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0-beta2 released 本日（9/17）、Lucene 5.2.1ベースのElaswdtags1xpmelasticsearchxetitle cElasticsearch 2.0.0-beta2リリース（日本語訳）vc157:yddate7<<Jxcdirjpost/2015/xbid `0de0edbf2a506143c1739b12e94c0ef9xdlangbjayglastmod7<<Jxipermalink!Ehttps://blog.johtani.info/blog/2015/08/28/elasticsearch-unplugged-ja/xkpublishdate Y2015-08-28T12:01:30+09:00xgsummary!h※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch unplugged - Networking changes in 2.0 Elasticsearchをローカルのマシンで起wdtags1xpmelasticsearchxetitle pElasticsearch unplugged - 2.0におけるネットワークの変更(日本語訳)vc158:yddate7&hxcdirjpost/2015/xbid `744554499cb7880086fbd9b1f080e7e1xdlangbjayglastmod7&hxipermalink!Phttps://blog.johtani.info/blog/2015/08/27/elasticsearch-2-0-0-beta1-released-ja/xkpublishdate Y2015-08-27T10:29:12+09:00xgsummary!\※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0-beta1 released 本日（8/26）、Lucene 5.2.1ベースのElaswdtags1xpmelasticsearchxetitle cElasticsearch 2.0.0-beta1リリース（日本語訳）vc159:yddate5dxcdirjpost/2015/xbid `5a9e950f4ac186925e5de978c5f72062xdlangbjayglastmod5dxipermalink!Nhttps://blog.johtani.info/blog/2015/08/20/core-delete-by-query-is-a-plugin-ja/xkpublishdate Y2015-08-20T13:24:04+09:00xgsummary!d※この記事は次のブログを翻訳したものになります。 原文：The Delete by Query API Is now a plugin Elasticsearchの2.0.0-beta1では、これまでwdtags1xpmelasticsearchxetitle `Delete by Query APIはプラグインへ（日本語訳）vc160:yddate.0*axcdirjpost/2015/xbid `73b8194ad8fce0cabb01cd21d5e18500xdlangbjayglastmod.0*axipermalink!@https://blog.johtani.info/blog/2015/07/31/11th-elasticsearch-jp/xkpublishdate Y2015-07-31T14:41:53+09:00xgsummary!G第11回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズwdtags2xpmelasticsearchc勉強会xetitle l第11回Elasticsearch勉強会を開催しました。#elasticsearchjpvc161:yddate."ixcdirjpost/2015/xbid `100c0a69bea7f02a0f4540ecaa37d0e3xdlangbjayglastmod."ixipermalink!Thttps://blog.johtani.info/blog/2015/07/29/elasticsearch-1-7-1-and-1-6-2-released-ja/xkpublishdate Y2015-07-29T21:35:53+09:00xgsummary!^※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.1 and 1.6.2 released 本日（7/29）、Lucene 4.10.4ベースのEwdtags1xpmelasticsearchxetitle gElasticsearch 1.7.1 および 1.6.2リリース（日本語訳）vc162:yddate+3%Axcdirjpost/2015/xbid `809925e891b0456231c374b09cbe4a90xdlangbjayglastmod+3%Axipermalink!Thttps://blog.johtani.info/blog/2015/07/22/elasticsearch-1-7-0-and-1-6-1-released-ja/xkpublishdate Y2015-07-22T15:33:37+09:00xgsummary!^※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.0 and 1.6.1 released 本日（7/16）、Lucene 4.10.4ベースのEwdtags1xpmelasticsearchxetitle gElasticsearch 1.7.0 および 1.6.1リリース（日本語訳）vc163:yddate)0.ixcdirjpost/2015/xbid `dd6c32a722dc815273cd9ed8cd6c671bxdlangbjayglastmod)0.ixipermalink!Fhttps://blog.johtani.info/blog/2015/07/16/kansai-1st-elasticsearch-jp/xkpublishdate Y2015-07-16T10:40:57+09:00xgsummary!N東京以外での勉強会の第2弾として、関西で勉強会を開催してきました。 Elasticsearch勉強会 in 大阪 Elasticsearch勉強会 in 京wdtags2xpc勉強会melasticsearchxetitle o大阪と京都でElasticsearch勉強会を開催しました。 #elasticsearchjpvc164:yddate'%Cxcdirjpost/2015/xbid `ee4ff9e4e8a1948795e26af2f3f8a30fxdlangbjayglastmod'%Cxipermalink!Ghttps://blog.johtani.info/blog/2015/07/08/great-mapping-refactoring-ja/xkpublishdate Y2015-07-08T18:11:31+09:00xgsummary!`※この記事は次のブログを翻訳したものになります。 原文：The Great Mapping Refactoring Elasticsearchのユーザの悩みの最も大きなものの一つは、 タイプとwdtags1xpmelasticsearchxetitle [Mappingのすばらしいリファクタリング（日本語訳）vc165:yddate&7|xcdirjpost/2015/xbid `f887e1aabf801e351bfb39698f208af1xdlangbjayglastmod&7|xipermalink![https://blog.johtani.info/blog/2015/07/07/elasticsearch-2-dot-0-0-dot-beta1-coming-soon-ja/xkpublishdate Y2015-07-07T15:25:00+09:00xgsummary!k※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0.beta1 coming soon! Elasticsearch 2.0.0.beta1のリリースの準備をしています。wdtags1xpmelasticsearchxetitle eElasticsearch 2.0.0.beta1リリース間近（日本語訳）vc166:yddate&6>Pxcdirjpost/2015/xbid `9cc2a0b6c8be1405cddcdeb4487c59fexdlangbjayglastmod&6>Pxipermalink!Mhttps://blog.johtani.info/blog/2015/07/07/we-just-made-found-more-awesome-ja/xkpublishdate Y2015-07-07T15:20:00+09:00xgsummary!W4ヶ月前に、Found joined our team at Elasticをアナウンスしました。 Foundの素晴らしいチームと一緒に仕事をしていますが、彼らによって、よりwdtags2xpmelasticsearchhfound.noxetitle Rさらに進化したFound（日本語訳）vc167:yddate&:Mxcdirjpost/2015/xbid `18b7998a871950ebc36c415a53630477xdlangbjayglastmod&:Mxipermalink!Ihttps://blog.johtani.info/blog/2015/07/06/attend-justsystem-techtalk-no2/xkpublishdate Y2015-07-06T10:49:01+09:00xgsummary!WJustTechTalk#02 形態素解析のあれやこれや@ジャストシステム に参加してきました。 ジャストシステムさんの形態素解析器JMATの話とKagome、Janome、wdtags1xpc勉強会xetitle mJustTechTalk#02 形態素解析のあれやこれや@ジャストシステムに参加しました。vc168:yddate ;}xcdirjpost/2015/xbid `ddab6357ff522c0c956ebd7669e83454xdlangbjayglastmod ;}xipermalink!Khttps://blog.johtani.info/blog/2015/06/17/attend-hatena-engineer-seminar-5/xkpublishdate Y2015-06-17T00:21:33+09:00xgsummary!aひさびさに、勉強会メモ。 Hatena Engineer Seminar #5 @ Tokyoに当選したので行ってきました。 いつもは近寄らないオシャレな街をドキドキしながら行ってきました。 とwdtags1xpc勉強会xetitle vHatena Engineer Seminar #5 @ Tokyoに参加しました。 #hatenatechvc169:yddate;6Fxcdirjpost/2015/xbid `55188a318c5998989255253e15ccc1f6xdlangbjayglastmod;6Fxipermalink!Jhttps://blog.johtani.info/blog/2015/06/10/elasticsearch-1-6-0-released-ja/xkpublishdate Y2015-06-10T13:31:02+09:00xgsummary!V※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.6.0 released 本日（6/9）、Lucene 4.10.4ベースのElaswdtags1xpmelasticsearchxetitle ]Elasticsearch 1.6.0リリース（日本語訳）vc170:yddatelxcdirjpost/2015/xbid `75d9268739fe7787ac02d389ac605febxdlangbjayglastmodlxipermalink!@https://blog.johtani.info/blog/2015/06/02/10th-elasticsearch-jp/xkpublishdate Y2015-06-02T15:06:36+09:00xgsummary!G第10回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさwdtags2xpmelasticsearchc勉強会xetitle l第10回Elasticsearch勉強会を開催しました。#elasticsearchjpvc171:yddate
/Zxcdirjpost/2015/xbid `23a22d1411afb787810d68210e6fad4fxdlangbjayglastmod
/Zxipermalink!Qhttps://blog.johtani.info/blog/2015/05/26/reindex-elasticsearch-with-logstash-ja/xkpublishdate Y2015-05-26T16:08:10+09:00xgsummary!m※この記事は次のブログを翻訳したものになります。 原文：Reindex Elasticsearch With Logstash Thanks David! マッピングを変更したり、インデックスの設定を変更したり、あるサwdtags2xphlogstashmelasticsearchxetitle gLogstashを使ったElasticsearchの再インデックス（日本語訳）vc1729yddate,Oxcdirjpost/2015/xbid `615db1a24f36d19a8eaf18d4dceed6b2xdlangbjayglastmod,Oxipermalink!Chttps://blog.johtani.info/blog/2015/05/21/join-the-conversation-ja/xkpublishdate Y2015-05-21T17:45:03+09:00xgsummary!k※この記事は次のブログを翻訳したものになります。 原文：Join the Conversation: Discuss.Elastic.Co 3つのOSSプロジェクトの開発をスケールアップし始め、 コミュニティサポーxetitle Ydiscuss.elastic.co にぜひ参加をvc173:yddate2pxcdirjpost/2015/xbid `8d7caf84b3a51cca27291c1f7cfc2d40xdlangbjayglastmod2pxipermalink!Thttps://blog.johtani.info/blog/2015/04/28/elasticsearch-1-5-2-and-1-4-5-released-ja/xkpublishdate Y2015-04-28T15:14:08+09:00xgsummary!V※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.2 Released 本日（4/27）、Lucene 4.10.4ベースのElawdtags1xpmelasticsearchxetitle gElasticsearch 1.5.2 および 1.4.5リリース（日本語訳）vc174:yddate	4bxcdirjpost/2015/xbid `7249710187cc2d983709e044dbc78d9dxdlangbjayglastmod	4bxipermalink https://blog.johtani.info/blog/2015/04/17/9th-elasticsearch-jp/xkpublishdate Y2015-04-17T14:41:54+09:00xgsummary!G第9回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさんwdtags2xpmelasticsearchc勉強会xetitle k第9回Elasticsearch勉強会を開催しました。#elasticsearchjpvc175:yddate
 2,wxcdirjpost/2015/xbid `563864a949924c505985a168191dcb84xdlangbjayglastmod
-2,wxipermalink!Jhttps://blog.johtani.info/blog/2015/04/13/elasticsearch-1-5-1-released-ja/xkpublishdate Y2015-04-13T11:34:31+09:00xgsummary!V※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.1 Released 本日（4/9）、Lucene 4.10.4ベースのElaswdtags1xpmelasticsearchxetitle ]Elasticsearch 1.5.1リリース（日本語訳）vc175:yddate3Wxcdirjpost/2015/xbid `24357fe145c869ec82fdfc8134a1a6d1xdlangbjayglastmod3Wxipermalink!Phttps://blog.johtani.info/blog/2015/04/04/elasticsearch-study-session-at-nagoya/xkpublishdate Y2015-04-04T09:47:19+09:00xgsummary!KElasticsearch勉強会 in 名古屋を開催しました。 初の東京以外での勉強会です。 企画、セッションなどお手伝いいただいた@smogamiさwdtags2xpmelasticsearchc勉強会xetitle ~Elasticsearch勉強会 in 名古屋を開催しました。#elasticsearch #elasticsearchjpvc176:yddate6 hxcdirjpost/2015/xbid `19ecbaa5e12f7a9ebcff703c79534a52xdlangbjayglastmod6 hxipermalink!Jhttps://blog.johtani.info/blog/2015/04/01/elasticsearch-1-5-0-released-ja/xkpublishdate Y2015-04-01T12:38:16+09:00xgsummary!V※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.0 Released 本日（3/23）、Lucene 4.10.4ベースのElawdtags1xpmelasticsearchxetitle ]Elasticsearch 1.5.0リリース（日本語訳）vc177:yddate??Wxcdirjpost/2015/xbid `ced9df0d8c8ed14de91c509b31b4c4aexdlangbjayglastmod??Wxipermalink {https://blog.johtani.info/blog/2015/03/11/attend-elasticon/xkpublishdate Y2015-03-11T16:46:31+09:00xgsummary!Iサンフランシスコからこんにちは。 今、私は、弊社初のユーザカンファレンスelastic{ON}に 参加するために、初のアメリカ出張中です。 初のユwdtags2xpgelasticielasticonxetitleo#elasticon に参加中vc178:yddate<7Dxcdirjpost/2015/xbid `cb13b64d0127c13bb466c4d4677a7b8axdlangbjayglastmod<7Dxipermalink!Rhttps://blog.johtani.info/blog/2015/02/27/you-know-for-security-shield-goes-ga-ja/xkpublishdate Y2015-02-27T18:49:56+09:00xgsummary!j※この記事は次のブログを翻訳したものになります。 原文：you know, for security: shield goes ga 1/27にShield 1.0 をリリースしました。 Elasticsearcwdtags2xpmelasticsearchfshieldxetitle ^セキュリティ向けプラグインShieldのリリース（日本語訳）vc179:yddate<uxcdirjpost/2015/xbid `f2cbe07bf2ff16d5a5860b4d6edbc5e8xdlangbjayglastmod<uxipermalink }https://blog.johtani.info/blog/2015/02/27/2nd-tokyo-training/xkpublishdate Y2015-02-27T17:10:29+09:00xgsummary!L4月13日から3日間、ElasticsearchのCoreトレーニングが東京で開催されます。 Early Birdということで、3/14までに申し込みすwdtags1xpmelasticsearchxetitle ZElasticsearch Coreトレーニング開催vc180:yddate9,pxcdirjpost/2015/xbid `eee039f49a5b570599cf459c55c649f3xdlangbjayglastmod9,pxipermalink!@https://blog.johtani.info/blog/2015/02/20/kibana-4-literally-ja/xkpublishdate Y2015-02-20T14:05:52+09:00xgsummary!Z※この記事は次のブログを翻訳したものになります。 原文：kibana 4. literally. Kibana 4は現在、文字通り、抽象的に、概念的に、精神的に、そしてとても楽しくwdtags2xpmelasticsearchgkibana4xetitlenKibana 4（日本語訳）vc181:yddate9,^xcdirjpost/2015/xbid `ddd3e6f6e298d3884abc4d888a043664xdlangbjayglastmod9,^xipermalink!Thttps://blog.johtani.info/blog/2015/02/20/elasticsearch-1-4-4-and-1-3-9-released-ja/xkpublishdate Y2015-02-20T14:05:34+09:00xgsummary!^※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.4 and 1.3.9 released 本日（2/20）、Elasticsearch 1.4.wdtags1xpmelasticsearchxetitle eElasticsearch 1.4.4および1.3.9リリース（日本語訳）vc182:yddate9>}xcdirjpost/2015/xbid `5b97ead91c0dd0bad57b4f43a89149a2xdlangbjayglastmod9>}xipermalink!Shttps://blog.johtani.info/blog/2015/02/18/preparing-elasticsearch-meetup-in-nagoya/xkpublishdate Y2015-02-18T15:22:53+09:00xgsummary!H来る、4月4日の土曜日の午後に名古屋でElasticsearch勉強会を開催予定です。 「初」の東京以外の勉強会です。 Twitterでこのようwdtags2xpmelasticsearchc勉強会xetitle Z名古屋でElasticsearch勉強会を開催しますvc183:yddate8oxcdirjpost/2015/xbid `997acc135d01b54f7de77a432fb9133fxdlangbjayglastmod8oxipermalink https://blog.johtani.info/blog/2015/02/16/8th-elasticsearch-jp/xkpublishdate Y2015-02-16T15:02:23+09:00xgsummary!G第8回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさんwdtags2xpmelasticsearchc勉強会xetitle k第8回Elasticsearch勉強会を開催しました。#elasticsearchjpvc184:yddate7uxcdirjpost/2015/xbid `1fed22e99b0e11a50eb7b92cb1644e8axdlangbjayglastmod7uxipermalink!^https://blog.johtani.info/blog/2015/02/12/running-groovy-scripts-without-dynamic-scripting-ja/xkpublishdate Y2015-02-12T15:13:09+09:00xgsummary!l※この記事は次のブログを翻訳したものになります。 原文：running groovy scripts without dynamic scripting Elasticsearch1.3.8と1.4.3のリリースによwdtags1xpmelasticsearchxetitle bGroovyスクリプトをダイナミックスクリプトなしで実行(日本語訳)vc185:yddate7Ixcdirjpost/2015/xbid `5badf61ecb9cfadd7d6af58712fa5f6fxdlangbjayglastmod7Ixipermalink!Thttps://blog.johtani.info/blog/2015/02/12/elasticsearch-1-4-3-and-1-3-8-released-ja/xkpublishdate Y2015-02-12T12:39:53+09:00xgsummary!^※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElaswdtags1xpmelasticsearchxetitle eElasticsearch　1.4.3および1.3.8リリース（日本語訳）vc186:yddate2Pxcdirjpost/2015/xbid `fe6ba10cc6c9509b4b22e9d59e029775xdlangbjayglastmod2Pxipermalink |https://blog.johtani.info/blog/2015/01/29/talk-at-cross2015/xkpublishdate Y2015-01-29T11:59:28+09:00xgsummary!G今年もCROSS参加しました。そして、話もしてきました。 今年は横浜の大さん橋でした。横浜はあんまりこないので、乗り換えでおたおたしてしまいまwdtags2xpc勉強会melasticsearchxetitle ^CROSS 2015で話をしてきました #cross2015vc187:yddate(>fxcdirjpost/2014/xbid `b36abffbe5d6a0de73a9968604a1a3f9xdlangbjayglastmod(>fxipermalink |https://blog.johtani.info/blog/2014/12/31/looking-back-2014/xkpublishdate Y2014-12-31T20:41:26+09:00xgsummary!I今年は大晦日になってしまいました。しかも、ちょっと飲んでたり。。。 第9流しながら書いてます。 振り返り(2013年に書いた抱負から) まずは昨年wdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2014）vc188:yddate&;Lxcdirjpost/2014/xbid `cb9649eca3dfbd356527ffc88f1dcb94xdlangbjayglastmod&;Lxipermalink!Lhttps://blog.johtani.info/blog/2014/12/25/pickup-elasticsearch-2-0-0-labels/xkpublishdate Y2014-12-25T15:53:00+09:00xgsummary!Uこの記事はElasticsearch Advent Calndar 2014の25日目のエントリです。 あっという間に最終日です。来年につなげるという意味で、Elastiwdtags1xpmelasticsearchxetitle [Elasticsearch 2.0系のIssueの紹介vc189:yddate$(,Xxcdirjpost/2014/xbid `7dea465ad52758b10cbceb08c81d1760xdlangbjayglastmod$(,Xxipermalink!Chttps://blog.johtani.info/blog/2014/12/18/marvel-1-3-0-released-ja/xkpublishdate Y2014-12-18T17:06:48+09:00xgsummary!\※この記事は次のブログを翻訳したものになります。 原文：marvel 1.3.0 released 12/17に、Elasticsearch Marvel 1.3.0をリリースしましたwdtags2xpmelasticsearchfmarvelxetitle VMarvel 1.3.0リリース（日本語訳）vc190:yddate$&vxcdirjpost/2014/xbid `bce2fa6458f39a75e2713f3d687271a1xdlangbjayglastmod$&vxipermalink!Jhttps://blog.johtani.info/blog/2014/12/18/elasticsearch-1-4-2-released-ja/xkpublishdate Y2014-12-18T14:26:14+09:00xgsummary!^※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElaswdtags1xpmelasticsearchxetitle eElasticsearch 1.4.2および1.3.7リリース（日本語訳）vc191:yddate$?bxcdirjpost/2014/xbid `e5390751969ab21df280b7591854b89fxdlangbjayglastmod$?bxipermalink!Fhttps://blog.johtani.info/blog/2014/12/17/jjug-night-seminar-dec-2014/xkpublishdate Y2014-12-17T18:41:54+09:00xgsummary!H「【東京】JJUG ナイト・セミナー「機械学習・自然言語処理特集！」12/17（水）開催」でLuceneの話をしてきました。 本当にごく簡単な入wdtags2xpmelasticsearchdjjugxetitle fJJUG ナイトセミナーでLuceneの簡単な紹介をしてきました。#JJUGvc192:yddate#:Lxcdirjpost/2014/xbid `05330c3703d0e2c96cfe657ab33f130cxdlangbjayglastmod#:Lxipermalink yhttps://blog.johtani.info/blog/2014/12/16/a-coffee-break/xkpublishdate Y2014-12-16T12:01:32+09:00xgsummary!Iたまには、他愛のないブログを。 仕事しながら、コーヒーを飲んでます。 最近は、サムライズムさんのオフィスに入り浸って仕事してます。 オフィスには、wdtags2xpdmiscfcoffeexetitlehコーヒーブレイクvc193:yddate#
+2,wxipermalink!Jhttps://blog.johtani.info/blog/2015/04/13/elasticsearch-1-5-1-released-ja/xkpublishdate Y2015-04-13T11:34:31+09:00xgsummary!V※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.1 Released 本日（4/9）、Lucene 4.10.4ベースのElaswdtags1xpmelasticsearchxetitle ]Elasticsearch 1.5.1リリース（日本語訳）vc176:yddate3Wxcdirjpost/2015/xbid `24357fe145c869ec82fdfc8134a1a6d1xdlangbjayglastmod3Wxipermalink!Phttps://blog.johtani.info/blog/2015/04/04/elasticsearch-study-session-at-nagoya/xkpublishdate Y2015-04-04T09:47:19+09:00xgsummary!KElasticsearch勉強会 in 名古屋を開催しました。 初の東京以外での勉強会です。 企画、セッションなどお手伝いいただいた@smogamiさwdtags2xpmelasticsearchc勉強会xetitle ~Elasticsearch勉強会 in 名古屋を開催しました。#elasticsearch #elasticsearchjpvc177:yddate6 hxcdirjpost/2015/xbid `19ecbaa5e12f7a9ebcff703c79534a52xdlangbjayglastmod6 hxipermalink!Jhttps://blog.johtani.info/blog/2015/04/01/elasticsearch-1-5-0-released-ja/xkpublishdate Y2015-04-01T12:38:16+09:00xgsummary!V※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.0 Released 本日（3/23）、Lucene 4.10.4ベースのElawdtags1xpmelasticsearchxetitle ]Elasticsearch 1.5.0リリース（日本語訳）vc178:yddate??Wxcdirjpost/2015/xbid `ced9df0d8c8ed14de91c509b31b4c4aexdlangbjayglastmod??Wxipermalink {https://blog.johtani.info/blog/2015/03/11/attend-elasticon/xkpublishdate Y2015-03-11T16:46:31+09:00xgsummary!Iサンフランシスコからこんにちは。 今、私は、弊社初のユーザカンファレンスelastic{ON}に 参加するために、初のアメリカ出張中です。 初のユwdtags2xpgelasticielasticonxetitleo#elasticon に参加中vc179:yddate<7Dxcdirjpost/2015/xbid `cb13b64d0127c13bb466c4d4677a7b8axdlangbjayglastmod<7Dxipermalink!Rhttps://blog.johtani.info/blog/2015/02/27/you-know-for-security-shield-goes-ga-ja/xkpublishdate Y2015-02-27T18:49:56+09:00xgsummary!j※この記事は次のブログを翻訳したものになります。 原文：you know, for security: shield goes ga 1/27にShield 1.0 をリリースしました。 Elasticsearcwdtags2xpmelasticsearchfshieldxetitle ^セキュリティ向けプラグインShieldのリリース（日本語訳）vc180:yddate<uxcdirjpost/2015/xbid `f2cbe07bf2ff16d5a5860b4d6edbc5e8xdlangbjayglastmod<uxipermalink }https://blog.johtani.info/blog/2015/02/27/2nd-tokyo-training/xkpublishdate Y2015-02-27T17:10:29+09:00xgsummary!L4月13日から3日間、ElasticsearchのCoreトレーニングが東京で開催されます。 Early Birdということで、3/14までに申し込みすwdtags1xpmelasticsearchxetitle ZElasticsearch Coreトレーニング開催vc181:yddate9,pxcdirjpost/2015/xbid `eee039f49a5b570599cf459c55c649f3xdlangbjayglastmod9,pxipermalink!@https://blog.johtani.info/blog/2015/02/20/kibana-4-literally-ja/xkpublishdate Y2015-02-20T14:05:52+09:00xgsummary!Z※この記事は次のブログを翻訳したものになります。 原文：kibana 4. literally. Kibana 4は現在、文字通り、抽象的に、概念的に、精神的に、そしてとても楽しくwdtags2xpmelasticsearchgkibana4xetitlenKibana 4（日本語訳）vc182:yddate9,^xcdirjpost/2015/xbid `ddd3e6f6e298d3884abc4d888a043664xdlangbjayglastmod9,^xipermalink!Thttps://blog.johtani.info/blog/2015/02/20/elasticsearch-1-4-4-and-1-3-9-released-ja/xkpublishdate Y2015-02-20T14:05:34+09:00xgsummary!^※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.4 and 1.3.9 released 本日（2/20）、Elasticsearch 1.4.wdtags1xpmelasticsearchxetitle eElasticsearch 1.4.4および1.3.9リリース（日本語訳）vc183:yddate9>}xcdirjpost/2015/xbid `5b97ead91c0dd0bad57b4f43a89149a2xdlangbjayglastmod9>}xipermalink!Shttps://blog.johtani.info/blog/2015/02/18/preparing-elasticsearch-meetup-in-nagoya/xkpublishdate Y2015-02-18T15:22:53+09:00xgsummary!H来る、4月4日の土曜日の午後に名古屋でElasticsearch勉強会を開催予定です。 「初」の東京以外の勉強会です。 Twitterでこのようwdtags2xpmelasticsearchc勉強会xetitle Z名古屋でElasticsearch勉強会を開催しますvc184:yddate8oxcdirjpost/2015/xbid `997acc135d01b54f7de77a432fb9133fxdlangbjayglastmod8oxipermalink https://blog.johtani.info/blog/2015/02/16/8th-elasticsearch-jp/xkpublishdate Y2015-02-16T15:02:23+09:00xgsummary!G第8回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさんwdtags2xpmelasticsearchc勉強会xetitle k第8回Elasticsearch勉強会を開催しました。#elasticsearchjpvc185:yddate7uxcdirjpost/2015/xbid `1fed22e99b0e11a50eb7b92cb1644e8axdlangbjayglastmod7uxipermalink!^https://blog.johtani.info/blog/2015/02/12/running-groovy-scripts-without-dynamic-scripting-ja/xkpublishdate Y2015-02-12T15:13:09+09:00xgsummary!l※この記事は次のブログを翻訳したものになります。 原文：running groovy scripts without dynamic scripting Elasticsearch1.3.8と1.4.3のリリースによwdtags1xpmelasticsearchxetitle bGroovyスクリプトをダイナミックスクリプトなしで実行(日本語訳)vc186:yddate7Ixcdirjpost/2015/xbid `5badf61ecb9cfadd7d6af58712fa5f6fxdlangbjayglastmod7Ixipermalink!Thttps://blog.johtani.info/blog/2015/02/12/elasticsearch-1-4-3-and-1-3-8-released-ja/xkpublishdate Y2015-02-12T12:39:53+09:00xgsummary!^※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElaswdtags1xpmelasticsearchxetitle eElasticsearch　1.4.3および1.3.8リリース（日本語訳）vc187:yddate2Pxcdirjpost/2015/xbid `fe6ba10cc6c9509b4b22e9d59e029775xdlangbjayglastmod2Pxipermalink |https://blog.johtani.info/blog/2015/01/29/talk-at-cross2015/xkpublishdate Y2015-01-29T11:59:28+09:00xgsummary!G今年もCROSS参加しました。そして、話もしてきました。 今年は横浜の大さん橋でした。横浜はあんまりこないので、乗り換えでおたおたしてしまいまwdtags2xpc勉強会melasticsearchxetitle ^CROSS 2015で話をしてきました #cross2015vc188:yddate(>fxcdirjpost/2014/xbid `b36abffbe5d6a0de73a9968604a1a3f9xdlangbjayglastmod(>fxipermalink |https://blog.johtani.info/blog/2014/12/31/looking-back-2014/xkpublishdate Y2014-12-31T20:41:26+09:00xgsummary!I今年は大晦日になってしまいました。しかも、ちょっと飲んでたり。。。 第9流しながら書いてます。 振り返り(2013年に書いた抱負から) まずは昨年wdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2014）vc189:yddate&;Lxcdirjpost/2014/xbid `cb9649eca3dfbd356527ffc88f1dcb94xdlangbjayglastmod&;Lxipermalink!Lhttps://blog.johtani.info/blog/2014/12/25/pickup-elasticsearch-2-0-0-labels/xkpublishdate Y2014-12-25T15:53:00+09:00xgsummary!Uこの記事はElasticsearch Advent Calndar 2014の25日目のエントリです。 あっという間に最終日です。来年につなげるという意味で、Elastiwdtags1xpmelasticsearchxetitle [Elasticsearch 2.0系のIssueの紹介vc190:yddate$(,Xxcdirjpost/2014/xbid `7dea465ad52758b10cbceb08c81d1760xdlangbjayglastmod$(,Xxipermalink!Chttps://blog.johtani.info/blog/2014/12/18/marvel-1-3-0-released-ja/xkpublishdate Y2014-12-18T17:06:48+09:00xgsummary!\※この記事は次のブログを翻訳したものになります。 原文：marvel 1.3.0 released 12/17に、Elasticsearch Marvel 1.3.0をリリースしましたwdtags2xpmelasticsearchfmarvelxetitle VMarvel 1.3.0リリース（日本語訳）vc191:yddate$&vxcdirjpost/2014/xbid `bce2fa6458f39a75e2713f3d687271a1xdlangbjayglastmod$&vxipermalink!Jhttps://blog.johtani.info/blog/2014/12/18/elasticsearch-1-4-2-released-ja/xkpublishdate Y2014-12-18T14:26:14+09:00xgsummary!^※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElaswdtags1xpmelasticsearchxetitle eElasticsearch 1.4.2および1.3.7リリース（日本語訳）vc192:yddate$?bxcdirjpost/2014/xbid `e5390751969ab21df280b7591854b89fxdlangbjayglastmod$?bxipermalink!Fhttps://blog.johtani.info/blog/2014/12/17/jjug-night-seminar-dec-2014/xkpublishdate Y2014-12-17T18:41:54+09:00xgsummary!H「【東京】JJUG ナイト・セミナー「機械学習・自然言語処理特集！」12/17（水）開催」でLuceneの話をしてきました。 本当にごく簡単な入wdtags2xpmelasticsearchdjjugxetitle fJJUG ナイトセミナーでLuceneの簡単な紹介をしてきました。#JJUGvc193:yddate#:Lxcdirjpost/2014/xbid `05330c3703d0e2c96cfe657ab33f130cxdlangbjayglastmod#:Lxipermalink yhttps://blog.johtani.info/blog/2014/12/16/a-coffee-break/xkpublishdate Y2014-12-16T12:01:32+09:00xgsummary!Iたまには、他愛のないブログを。 仕事しながら、コーヒーを飲んでます。 最近は、サムライズムさんのオフィスに入り浸って仕事してます。 オフィスには、wdtags2xpdmiscfcoffeexetitlehコーヒーブレイクvc194:yddate#
 hxcdirjpost/2014/xbid `4a3c42c9c5ac29db268010bbebf4f579xdlangbjayglastmod#
-hxipermalink!Chttps://blog.johtani.info/blog/2014/12/14/plugin-ecosystem-changes/xkpublishdate Y2014-12-14T01:00:40+09:00xgsummary!x※この記事は次のブログを翻訳したものになります。 原文：exciting logstash plugin ecosystem changes Logstash 1.5.0 Beta 1(お試しはこちら)のリリースで、 プラグインのインストーwdtags1xphlogstashxetitle ]Logstashプラグインのエコシステムの変更（日本語訳）vc194:yddate"*Vxcdirjpost/2014/xbid `1bc36080b2493aab78c26e4f2152542cxdlangbjayglastmod"*Vxipermalink!Khttps://blog.johtani.info/blog/2014/12/12/logstash-1-5-0-beta1-released-ja/xkpublishdate Y2014-12-12T17:17:26+09:00xgsummary!h※この記事は次のブログを翻訳したものになります。 原文：logstash 1.5.0.beta1 released Logstash 1.5.0 Beta1をリリースしました。こちらのページからダウンロードでwdtags1xphlogstashxetitle ^Logstash 1.5.0 Beta1リリース(日本語訳)vc195:yddate=lxcdirjpost/2014/xbid `2de582c67fca31500621ecd6d3917a07xdlangbjayglastmod=lxipermalink!Fhttps://blog.johtani.info/blog/2014/12/01/about-elasticsearch-in-2014/xkpublishdate Y2014-12-01T18:05:48+09:00xgsummary!H早いもので、師走です。今年もあと少しとなりました。ということで、Advent Calendarの季節が始まりました。 この記事はElasticswdtags1xpmelasticsearchxetitle S2014年のElasticsearchvc196:yddate(?Txcdirjpost/2014/xbid `0a8183ced0e9e3e895b41286e54e8e4dxdlangbjayglastmod(?Txipermalink!Jhttps://blog.johtani.info/blog/2014/11/27/elasticsearch-1-4-1-released-ja/xkpublishdate Y2014-11-27T11:43:32+09:00xgsummary!^※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.1 and 1.3.6 released 本日、Lucene 4.10.2をベースにしたElaswdtags1xpmelasticsearchxetitle eElasticsearch 1.4.1および1.3.6リリース（日本語訳）vc197:yddate;zxcdirjpost/2014/xbid `4d8f5e581eee602c7fd21da8eb68df9axdlangbjayglastmod;zxipermalink!Shttps://blog.johtani.info/blog/2014/11/25/import-apache-accesslog-using-logstash-2/xkpublishdate Y2014-11-25T16:25:46+09:00xgsummary!G前回の「Logstashを利用したApacheアクセスログのインポート」の続きです。 前回の記事では、Logstashの設定ファイルについて説wdtags3xphlogstashfkibanamelasticsearchxetitle UインデックステンプレートとLogstashvc198:yddate/ oxcdirjpost/2014/xbid `937a597a8b399fd32caba88a3c1c7bc4xdlangbjayglastmod/ oxipermalink!Qhttps://blog.johtani.info/blog/2014/11/21/import-apache-accesslog-using-logstash/xkpublishdate Y2014-11-21T17:30:39+09:00xgsummary!KJJUG CCCや第7回Elasticsearch勉強会のKibana4のデモにアクセスログを利用しました。 ただ、セッションでは、どうやってElaswdtags3xphlogstashfkibanamelasticsearchxetitle _Logstashを利用したApacheアクセスログのインポートvc199:yddate?8[xcdirjpost/2014/xbid `2a8412aa50d07330f1298f0243fa79d3xdlangbjayglastmod?8[xipermalink!Ghttps://blog.johtani.info/blog/2014/11/19/hold-on-7th-elasticsearch-jp/xkpublishdate Y2014-11-19T11:19:07+09:00xgsummary!G第7回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさんwdtags2xpmelasticsearchc勉強会xetitle k第7回Elasticsearch勉強会を開催しました。#elasticsearchjpvc200:yddate%ixcdirjpost/2014/xbid `d266a2023c67b7a20c3bd01055b223bcxdlangbjayglastmod%ixipermalink!Ahttps://blog.johtani.info/blog/2014/11/06/elasticsearch-1-4-0-ja/xkpublishdate Y2014-11-06T01:30:33+09:00xgsummary!Y※この記事は次のブログを翻訳したものになります。 原文：elasticsearch-1.4.0 and 1.3.5 released 本日、Lucene 4.10.2をベースにしwdtags1xpmelasticsearchxetitle eElasticsearch 1.4.0および1.3.5リリース（日本語訳）vc201:yddate!Gxcdirjpost/2014/xbid `bc2709406a9bb19e8d83a78f81e36244xdlangbjayglastmod!Gxipermalink!Bhttps://blog.johtani.info/blog/2014/10/27/how-to-use-validate-api/xkpublishdate Y2014-10-27T18:42:31+09:00xgsummary!J久しぶりに翻訳ではないブログを。書こうと思いながらかけてなかったので。。。 今回はvalidate APIの紹介です。 背景 Elasticsearwdtags1xpmelasticsearchxetitleovalidate APIの利用vc202:yddate!@xcdirjpost/2014/xbid `998eda745d07fd8608f251138384a0b9xdlangbjayglastmod!@xipermalink!Ahttps://blog.johtani.info/blog/2014/10/15/versioning-of-sonatype/xkpublishdate Y2014-10-15T15:26:08+09:00xgsummary!TElasticsearch 1.4.0.Beta1がリリースされました。 個人でelasticsearch-extended-analyzeというプラグインを開発してまwdtags3xpmElasticsearchfpluginhsonatypexetitle VSonatypeのバージョン番号で困ったのでvc203:yddatehxcdirjpost/2014/xbid `853cac0f2d1f90b7c986e7d1dcdbbfdexdlangbjayglastmodhxipermalink!Ohttps://blog.johtani.info/blog/2014/10/02/elasticsearch-1-4-0-beta-released-ja/xkpublishdate Y2014-10-02T19:14:00+09:00xgsummary!\※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.0.beta1 released 本日、Lucene 4.10.1をベースにした、Elastwdtags1xpmElasticsearchxetitle ^elasticsearch 1.4.0.Beta1のリリースvc204:yddate1hxcdirjpost/2014/xbid `4616fbea6a6dbc1074bc3f1016bbc73bxdlangbjayglastmod1hxipermalink!Ghttps://blog.johtani.info/blog/2014/09/17/hold-on-6th-elasticsearch-jp/xkpublishdate Y2014-09-17T13:22:00+09:00xgsummary!G第6回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさんwdtags2xpmelasticsearchc勉強会xetitle k第6回Elasticsearch勉強会を開催しました。#elasticsearchjpvc205:yddate;*lxcdirjpost/2014/xbid `f15702ae9e55bad42182cf18724d1863xdlangbjayglastmod;*lxipermalink!Ahttps://blog.johtani.info/blog/2014/09/16/book-publication-event/xkpublishdate Y2014-09-16T13:21:00+09:00xgsummary!I先日2014年9月9日(火)に『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』 出版記念！執筆者が語る大講演会！で、 「elasticswdtags2xpc勉強会a本xetitle lelasticsearch.もうちょっと入門という話をしてきました #gihyo_efkvc206:yddate+Txcdirjpost/2014/xbid `77d965afaebd7193badc746d52b4173fxdlangbjayglastmod+Txipermalink!`https://blog.johtani.info/blog/2014/09/09/performance-considerations-for-elasticsearch-indexing/xkpublishdate Y2014-09-09T17:11:00+09:00xgsummary!nElasticsearchのインデキシングに関するパフォーマンス検討 原文：performance considerations for elasticsearch indexing Elasticsearchユーザは様wdtags1xpmElasticsearchxetitle bElasticsearchのインデキシングに関するパフォーマンス検討vc207:yddate78	hxcdirjpost/2014/xbid `bdea71d64cdfcc405e65e750fe8d9b86xdlangbjayglastmod78	hxipermalink!Thttps://blog.johtani.info/blog/2014/08/04/release-magazine-book-of-log-aggs-and-viz/xkpublishdate Y2014-08-04T21:54:00+09:00xgsummary!H懲りずにまた、執筆してみました。みなさん「買って」から感想をいただけるとうれしいです！ 本書について 共著者の方々のブログが詳しいので、そちらをwdtags3xpmelasticsearchfkibanaa本xetitle cサーバ/インフラエンジニア養成読本 ログ収集~可視化編 を手伝いましたvc208:yddate63
+hxipermalink!Chttps://blog.johtani.info/blog/2014/12/14/plugin-ecosystem-changes/xkpublishdate Y2014-12-14T01:00:40+09:00xgsummary!x※この記事は次のブログを翻訳したものになります。 原文：exciting logstash plugin ecosystem changes Logstash 1.5.0 Beta 1(お試しはこちら)のリリースで、 プラグインのインストーwdtags1xphlogstashxetitle ]Logstashプラグインのエコシステムの変更（日本語訳）vc195:yddate"*Vxcdirjpost/2014/xbid `1bc36080b2493aab78c26e4f2152542cxdlangbjayglastmod"*Vxipermalink!Khttps://blog.johtani.info/blog/2014/12/12/logstash-1-5-0-beta1-released-ja/xkpublishdate Y2014-12-12T17:17:26+09:00xgsummary!h※この記事は次のブログを翻訳したものになります。 原文：logstash 1.5.0.beta1 released Logstash 1.5.0 Beta1をリリースしました。こちらのページからダウンロードでwdtags1xphlogstashxetitle ^Logstash 1.5.0 Beta1リリース(日本語訳)vc196:yddate=lxcdirjpost/2014/xbid `2de582c67fca31500621ecd6d3917a07xdlangbjayglastmod=lxipermalink!Fhttps://blog.johtani.info/blog/2014/12/01/about-elasticsearch-in-2014/xkpublishdate Y2014-12-01T18:05:48+09:00xgsummary!H早いもので、師走です。今年もあと少しとなりました。ということで、Advent Calendarの季節が始まりました。 この記事はElasticswdtags1xpmelasticsearchxetitle S2014年のElasticsearchvc197:yddate(?Txcdirjpost/2014/xbid `0a8183ced0e9e3e895b41286e54e8e4dxdlangbjayglastmod(?Txipermalink!Jhttps://blog.johtani.info/blog/2014/11/27/elasticsearch-1-4-1-released-ja/xkpublishdate Y2014-11-27T11:43:32+09:00xgsummary!^※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.1 and 1.3.6 released 本日、Lucene 4.10.2をベースにしたElaswdtags1xpmelasticsearchxetitle eElasticsearch 1.4.1および1.3.6リリース（日本語訳）vc198:yddate;zxcdirjpost/2014/xbid `4d8f5e581eee602c7fd21da8eb68df9axdlangbjayglastmod;zxipermalink!Shttps://blog.johtani.info/blog/2014/11/25/import-apache-accesslog-using-logstash-2/xkpublishdate Y2014-11-25T16:25:46+09:00xgsummary!G前回の「Logstashを利用したApacheアクセスログのインポート」の続きです。 前回の記事では、Logstashの設定ファイルについて説wdtags3xphlogstashfkibanamelasticsearchxetitle UインデックステンプレートとLogstashvc199:yddate/ oxcdirjpost/2014/xbid `937a597a8b399fd32caba88a3c1c7bc4xdlangbjayglastmod/ oxipermalink!Qhttps://blog.johtani.info/blog/2014/11/21/import-apache-accesslog-using-logstash/xkpublishdate Y2014-11-21T17:30:39+09:00xgsummary!KJJUG CCCや第7回Elasticsearch勉強会のKibana4のデモにアクセスログを利用しました。 ただ、セッションでは、どうやってElaswdtags3xphlogstashfkibanamelasticsearchxetitle _Logstashを利用したApacheアクセスログのインポートvc200:yddate?8[xcdirjpost/2014/xbid `2a8412aa50d07330f1298f0243fa79d3xdlangbjayglastmod?8[xipermalink!Ghttps://blog.johtani.info/blog/2014/11/19/hold-on-7th-elasticsearch-jp/xkpublishdate Y2014-11-19T11:19:07+09:00xgsummary!G第7回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさんwdtags2xpmelasticsearchc勉強会xetitle k第7回Elasticsearch勉強会を開催しました。#elasticsearchjpvc201:yddate%ixcdirjpost/2014/xbid `d266a2023c67b7a20c3bd01055b223bcxdlangbjayglastmod%ixipermalink!Ahttps://blog.johtani.info/blog/2014/11/06/elasticsearch-1-4-0-ja/xkpublishdate Y2014-11-06T01:30:33+09:00xgsummary!Y※この記事は次のブログを翻訳したものになります。 原文：elasticsearch-1.4.0 and 1.3.5 released 本日、Lucene 4.10.2をベースにしwdtags1xpmelasticsearchxetitle eElasticsearch 1.4.0および1.3.5リリース（日本語訳）vc202:yddate!Gxcdirjpost/2014/xbid `bc2709406a9bb19e8d83a78f81e36244xdlangbjayglastmod!Gxipermalink!Bhttps://blog.johtani.info/blog/2014/10/27/how-to-use-validate-api/xkpublishdate Y2014-10-27T18:42:31+09:00xgsummary!J久しぶりに翻訳ではないブログを。書こうと思いながらかけてなかったので。。。 今回はvalidate APIの紹介です。 背景 Elasticsearwdtags1xpmelasticsearchxetitleovalidate APIの利用vc203:yddate!@xcdirjpost/2014/xbid `998eda745d07fd8608f251138384a0b9xdlangbjayglastmod!@xipermalink!Ahttps://blog.johtani.info/blog/2014/10/15/versioning-of-sonatype/xkpublishdate Y2014-10-15T15:26:08+09:00xgsummary!TElasticsearch 1.4.0.Beta1がリリースされました。 個人でelasticsearch-extended-analyzeというプラグインを開発してまwdtags3xpmElasticsearchfpluginhsonatypexetitle VSonatypeのバージョン番号で困ったのでvc204:yddatehxcdirjpost/2014/xbid `853cac0f2d1f90b7c986e7d1dcdbbfdexdlangbjayglastmodhxipermalink!Ohttps://blog.johtani.info/blog/2014/10/02/elasticsearch-1-4-0-beta-released-ja/xkpublishdate Y2014-10-02T19:14:00+09:00xgsummary!\※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.0.beta1 released 本日、Lucene 4.10.1をベースにした、Elastwdtags1xpmElasticsearchxetitle ^elasticsearch 1.4.0.Beta1のリリースvc205:yddate1hxcdirjpost/2014/xbid `4616fbea6a6dbc1074bc3f1016bbc73bxdlangbjayglastmod1hxipermalink!Ghttps://blog.johtani.info/blog/2014/09/17/hold-on-6th-elasticsearch-jp/xkpublishdate Y2014-09-17T13:22:00+09:00xgsummary!G第6回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさんwdtags2xpmelasticsearchc勉強会xetitle k第6回Elasticsearch勉強会を開催しました。#elasticsearchjpvc206:yddate;*lxcdirjpost/2014/xbid `f15702ae9e55bad42182cf18724d1863xdlangbjayglastmod;*lxipermalink!Ahttps://blog.johtani.info/blog/2014/09/16/book-publication-event/xkpublishdate Y2014-09-16T13:21:00+09:00xgsummary!I先日2014年9月9日(火)に『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』 出版記念！執筆者が語る大講演会！で、 「elasticswdtags2xpc勉強会a本xetitle lelasticsearch.もうちょっと入門という話をしてきました #gihyo_efkvc207:yddate+Txcdirjpost/2014/xbid `77d965afaebd7193badc746d52b4173fxdlangbjayglastmod+Txipermalink!`https://blog.johtani.info/blog/2014/09/09/performance-considerations-for-elasticsearch-indexing/xkpublishdate Y2014-09-09T17:11:00+09:00xgsummary!nElasticsearchのインデキシングに関するパフォーマンス検討 原文：performance considerations for elasticsearch indexing Elasticsearchユーザは様wdtags1xpmElasticsearchxetitle bElasticsearchのインデキシングに関するパフォーマンス検討vc208:yddate78	hxcdirjpost/2014/xbid `bdea71d64cdfcc405e65e750fe8d9b86xdlangbjayglastmod78	hxipermalink!Thttps://blog.johtani.info/blog/2014/08/04/release-magazine-book-of-log-aggs-and-viz/xkpublishdate Y2014-08-04T21:54:00+09:00xgsummary!H懲りずにまた、執筆してみました。みなさん「買って」から感想をいただけるとうれしいです！ 本書について 共著者の方々のブログが詳しいので、そちらをwdtags3xpmelasticsearchfkibanaa本xetitle cサーバ/インフラエンジニア養成読本 ログ収集~可視化編 を手伝いましたvc209:yddate63
 @xcdirjpost/2014/xbid `7cc605e721fdd1d2ccc16f5b6490e830xdlangbjayglastmod63
-@xipermalink!Ghttps://blog.johtani.info/blog/2014/08/01/plugin-using-under-proxy-env/xkpublishdate Y2014-08-01T15:24:00+09:00xgsummary!GProxy環境で働いている方も結構いると思います。 Twitter上で、Elasticsearchのpluginコマンドでプラグインがインストwdtags2xpmelasticsearchfpluginxetitle Uプロキシ環境でのpluginコマンドの実行vc209:yddate51
Xxcdirjpost/2014/xbid `fb1da4a6ed74705ad98bb60ad4badaf2xdlangbjayglastmod51
Xxipermalink!Fhttps://blog.johtani.info/blog/2014/07/29/elasticsearch-1-3-1-release/xkpublishdate Y2014-07-29T12:22:00+09:00xgsummary!N原文：Elasticsearch 1.3.1 Releasedを日本語に翻訳したものです。 バグフィックス版のElasticsearch 1.3.1をリリーwdtags2xpmelasticsearchgreleasexetitle ^Elasticsearch 1.3.1 リリース（日本語訳）vc210:yddate55Dxcdirjpost/2014/xbid `0c1821d1069578551d0e3c7d9275f16bxdlangbjayglastmod55Dxipermalink ~https://blog.johtani.info/blog/2014/07/28/curator-2-0-and-1-1/xkpublishdate Y2014-07-28T14:19:00+09:00xgsummary!GCuratorの1.2.0がリリースされました。 前回のCuratorの記事が古くなってしまった（1.1.0からコマンドのI/Fが変更された）wdtags2xpmelasticsearchgcuratorxetitle UCurator 1.2および1.1についてvc211:yddate2&'pxcdirjpost/2014/xbid `e3e146469ed4318eaa2ffbca3510c054xdlangbjayglastmod2&'pxipermalink!Ghttps://blog.johtani.info/blog/2014/07/19/hold-on-5th-elasticsearch-jp/xkpublishdate Y2014-07-19T21:52:00+09:00xgsummary!H第5回Elasticsearch勉強会を開催しました。 遅くなってしまいましたが、まとめてみました。 今回は、Elasticsearchに入ってwdtags2xpmelasticsearchc勉強会xetitle k第5回Elasticsearch勉強会を開催しました。#elasticsearchjpvc212:yddate,!4hxcdirjpost/2014/xbid `21a8e6324e9330d4f8ebade604c62b6exdlangbjayglastmod,!4hxipermalink }https://blog.johtani.info/blog/2014/07/01/join-elasticsearch/xkpublishdate Y2014-07-01T11:30:00+09:00xgsummary!Hということで、転職しました。 どーしてもやりたいことが出てきたので、無理を言って転職することにしてみました。 サムライズムではなく、Elastiwdtags1xpb転職xetitlef転職しましたvc213:yddate,Txcdirjpost/2014/xbid `40abea0a87a64bd832a1fad69458b293xdlangbjayglastmod,Txipermalink vhttps://blog.johtani.info/blog/2014/06/30/resignation/xkpublishdate Y2014-06-30T23:19:00+09:00xgsummary!J退職しました。 色々と書きたいんですが、時差ボケで頭痛いので、このくらいです。 余裕出たら書くかも。 ほしい物リストはこちら 新天地についてはまた明wdtags1xpb転職xetitlef退職しましたvc214:yddate'*<Dxcdirjpost/2014/xbid `916bda59bc7621d5c1790c040572a3c0xdlangbjayglastmod'*<Dxipermalink!\https://blog.johtani.info/blog/2014/06/16/first-impression-elasticsearch-server-2nd-edition/xkpublishdate Y2014-06-16T17:47:00+09:00xgsummary!_Elasticsearch server 2nd editionが発売されています。 私が翻訳したのは前のバージョンですが。。。 まずは、目次を元にどのくらい変わってるかを見てみました。 （wdtags2xpmelasticsearcha本xetitle nElasticsearch server 2nd editionのファーストインプレッションvc215:yddate#07Dxcdirjpost/2014/xbid `5bb6f8322cdbda7a21e4aecbe04462b7xdlangbjayglastmod#07Dxipermalink!Dhttps://blog.johtani.info/blog/2014/06/04/attending-visualize-study/xkpublishdate Y2014-06-04T21:15:00+09:00xgsummary!X可視化ツール現状確認会に参加して、カジュアルウォーターじゃなくて可視化ツールの現状を確認してきました。 ということで、いつものメモです。 Mackerel と Graphitewdtags1xpc勉強会xetitle Y可視化ツール現状確認会に参加してきました。#可視化vc216:yddate2
Xxcdirjpost/2014/xbid `a578acf825a595ce95fe8f804b7208f0xdlangbjayglastmod2
Xxipermalink!Ghttps://blog.johtani.info/blog/2014/05/23/attending-drecom-infra-study/xkpublishdate Y2014-05-23T19:18:00+09:00xgsummary!H今月2回目の目黒で、初のドリコムさんです。 「最新インフラエンジニア技術勉強～Fluentd, Elasticsearch,Chefの実践実例～wdtags2xpc勉強会melasticsearchxetitle W最新インフラエンジニア技術勉強に参加しました。vc217:yddate>xxcdirjpost/2014/xbid `706c033b4483b6d062b66d6e4ea0236axdlangbjayglastmod>xxipermalink!Mhttps://blog.johtani.info/blog/2014/05/15/amazon-cloud-seaarch-study-session/xkpublishdate Y2014-05-15T17:50:00+09:00xgsummary!Hどうやら、中身がSolrベース？Luceneベース？になったらしいということで、 今日は「AWSプロダクトシリーズ｜よくわかるAmazon Clwdtags3xpc勉強会kCloudSearchcAWSxetitle d「よくわかるAmazon #CloudSearch 」に行ってきました！vc218:yddate$/Pxcdirjpost/2014/xbid `72df0bf7853e05560d94208817b83468xdlangbjayglastmod$/Pxipermalink {https://blog.johtani.info/blog/2014/05/14/spiritual-entry1/xkpublishdate Y2014-05-14T01:44:00+09:00xgsummary!G酔っ払ってなんとなく書きたくなったスピリチュアルなブログなので、流していただければと。 最近、勉強会やTwitterで知り合いになって話をするwdtags1xpgスピリチュアルxetitlel外の世界を知るということvc219:yddate:|xcdirjpost/2014/xbid `91fe03f994e8e85cede4e3bd62f4d6b7xdlangbjayglastmod:|xipermalink!Ehttps://blog.johtani.info/blog/2014/05/09/reading-agile-data-science/xkpublishdate Y2014-05-09T00:45:00+09:00xgsummary!I「アジャイルデータサイエンス」の見本をいただいてしまいました。 なので、感想文でも書いてみようかと。 どんな本？ 想像以上に薄かったです、物理的にwdtags2xpc感想文eオライリーxetitle Sアジャイルデータサイエンスが届きましたvc220:yddate 
lxcdirjpost/2014/xbid `ed4f5a398056eef1cf6caa90786b340axdlangbjayglastmod 
lxipermalink ~https://blog.johtani.info/blog/2014/05/07/aggregation-example/xkpublishdate Y2014-05-07T18:57:00+09:00xgsummary!sこんなツイートを見つけたので、Aggregationのサンプルでも書こうかなと。（前から書こうと思ってたんですが。。。） @elasticsearch Hi, Would you please tell me the way towdtags1xpmelasticsearchxetitle \Aggregations - ファセットよりも柔軟な集計vc221:yddate
+@xipermalink!Ghttps://blog.johtani.info/blog/2014/08/01/plugin-using-under-proxy-env/xkpublishdate Y2014-08-01T15:24:00+09:00xgsummary!GProxy環境で働いている方も結構いると思います。 Twitter上で、Elasticsearchのpluginコマンドでプラグインがインストwdtags2xpmelasticsearchfpluginxetitle Uプロキシ環境でのpluginコマンドの実行vc210:yddate51
Xxcdirjpost/2014/xbid `fb1da4a6ed74705ad98bb60ad4badaf2xdlangbjayglastmod51
Xxipermalink!Fhttps://blog.johtani.info/blog/2014/07/29/elasticsearch-1-3-1-release/xkpublishdate Y2014-07-29T12:22:00+09:00xgsummary!N原文：Elasticsearch 1.3.1 Releasedを日本語に翻訳したものです。 バグフィックス版のElasticsearch 1.3.1をリリーwdtags2xpmelasticsearchgreleasexetitle ^Elasticsearch 1.3.1 リリース（日本語訳）vc211:yddate55Dxcdirjpost/2014/xbid `0c1821d1069578551d0e3c7d9275f16bxdlangbjayglastmod55Dxipermalink ~https://blog.johtani.info/blog/2014/07/28/curator-2-0-and-1-1/xkpublishdate Y2014-07-28T14:19:00+09:00xgsummary!GCuratorの1.2.0がリリースされました。 前回のCuratorの記事が古くなってしまった（1.1.0からコマンドのI/Fが変更された）wdtags2xpmelasticsearchgcuratorxetitle UCurator 1.2および1.1についてvc212:yddate2&'pxcdirjpost/2014/xbid `e3e146469ed4318eaa2ffbca3510c054xdlangbjayglastmod2&'pxipermalink!Ghttps://blog.johtani.info/blog/2014/07/19/hold-on-5th-elasticsearch-jp/xkpublishdate Y2014-07-19T21:52:00+09:00xgsummary!H第5回Elasticsearch勉強会を開催しました。 遅くなってしまいましたが、まとめてみました。 今回は、Elasticsearchに入ってwdtags2xpmelasticsearchc勉強会xetitle k第5回Elasticsearch勉強会を開催しました。#elasticsearchjpvc213:yddate,!4hxcdirjpost/2014/xbid `21a8e6324e9330d4f8ebade604c62b6exdlangbjayglastmod,!4hxipermalink }https://blog.johtani.info/blog/2014/07/01/join-elasticsearch/xkpublishdate Y2014-07-01T11:30:00+09:00xgsummary!Hということで、転職しました。 どーしてもやりたいことが出てきたので、無理を言って転職することにしてみました。 サムライズムではなく、Elastiwdtags1xpb転職xetitlef転職しましたvc214:yddate,Txcdirjpost/2014/xbid `40abea0a87a64bd832a1fad69458b293xdlangbjayglastmod,Txipermalink vhttps://blog.johtani.info/blog/2014/06/30/resignation/xkpublishdate Y2014-06-30T23:19:00+09:00xgsummary!J退職しました。 色々と書きたいんですが、時差ボケで頭痛いので、このくらいです。 余裕出たら書くかも。 ほしい物リストはこちら 新天地についてはまた明wdtags1xpb転職xetitlef退職しましたvc215:yddate'*<Dxcdirjpost/2014/xbid `916bda59bc7621d5c1790c040572a3c0xdlangbjayglastmod'*<Dxipermalink!\https://blog.johtani.info/blog/2014/06/16/first-impression-elasticsearch-server-2nd-edition/xkpublishdate Y2014-06-16T17:47:00+09:00xgsummary!_Elasticsearch server 2nd editionが発売されています。 私が翻訳したのは前のバージョンですが。。。 まずは、目次を元にどのくらい変わってるかを見てみました。 （wdtags2xpmelasticsearcha本xetitle nElasticsearch server 2nd editionのファーストインプレッションvc216:yddate#07Dxcdirjpost/2014/xbid `5bb6f8322cdbda7a21e4aecbe04462b7xdlangbjayglastmod#07Dxipermalink!Dhttps://blog.johtani.info/blog/2014/06/04/attending-visualize-study/xkpublishdate Y2014-06-04T21:15:00+09:00xgsummary!X可視化ツール現状確認会に参加して、カジュアルウォーターじゃなくて可視化ツールの現状を確認してきました。 ということで、いつものメモです。 Mackerel と Graphitewdtags1xpc勉強会xetitle Y可視化ツール現状確認会に参加してきました。#可視化vc217:yddate2
Xxcdirjpost/2014/xbid `a578acf825a595ce95fe8f804b7208f0xdlangbjayglastmod2
Xxipermalink!Ghttps://blog.johtani.info/blog/2014/05/23/attending-drecom-infra-study/xkpublishdate Y2014-05-23T19:18:00+09:00xgsummary!H今月2回目の目黒で、初のドリコムさんです。 「最新インフラエンジニア技術勉強～Fluentd, Elasticsearch,Chefの実践実例～wdtags2xpc勉強会melasticsearchxetitle W最新インフラエンジニア技術勉強に参加しました。vc218:yddate>xxcdirjpost/2014/xbid `706c033b4483b6d062b66d6e4ea0236axdlangbjayglastmod>xxipermalink!Mhttps://blog.johtani.info/blog/2014/05/15/amazon-cloud-seaarch-study-session/xkpublishdate Y2014-05-15T17:50:00+09:00xgsummary!Hどうやら、中身がSolrベース？Luceneベース？になったらしいということで、 今日は「AWSプロダクトシリーズ｜よくわかるAmazon Clwdtags3xpc勉強会kCloudSearchcAWSxetitle d「よくわかるAmazon #CloudSearch 」に行ってきました！vc219:yddate$/Pxcdirjpost/2014/xbid `72df0bf7853e05560d94208817b83468xdlangbjayglastmod$/Pxipermalink {https://blog.johtani.info/blog/2014/05/14/spiritual-entry1/xkpublishdate Y2014-05-14T01:44:00+09:00xgsummary!G酔っ払ってなんとなく書きたくなったスピリチュアルなブログなので、流していただければと。 最近、勉強会やTwitterで知り合いになって話をするwdtags1xpgスピリチュアルxetitlel外の世界を知るということvc220:yddate:|xcdirjpost/2014/xbid `91fe03f994e8e85cede4e3bd62f4d6b7xdlangbjayglastmod:|xipermalink!Ehttps://blog.johtani.info/blog/2014/05/09/reading-agile-data-science/xkpublishdate Y2014-05-09T00:45:00+09:00xgsummary!I「アジャイルデータサイエンス」の見本をいただいてしまいました。 なので、感想文でも書いてみようかと。 どんな本？ 想像以上に薄かったです、物理的にwdtags2xpc感想文eオライリーxetitle Sアジャイルデータサイエンスが届きましたvc221:yddate 
lxcdirjpost/2014/xbid `ed4f5a398056eef1cf6caa90786b340axdlangbjayglastmod 
lxipermalink ~https://blog.johtani.info/blog/2014/05/07/aggregation-example/xkpublishdate Y2014-05-07T18:57:00+09:00xgsummary!sこんなツイートを見つけたので、Aggregationのサンプルでも書こうかなと。（前から書こうと思ってたんですが。。。） @elasticsearch Hi, Would you please tell me the way towdtags1xpmelasticsearchxetitle \Aggregations - ファセットよりも柔軟な集計vc222:yddate
 |xcdirjpost/2014/xbid `2824bef72110575c78aeb979170212b8xdlangbjayglastmod
-|xipermalink!Thttps://blog.johtani.info/blog/2014/05/04/intro-elasticsearch-kopf-alias-percolator/xkpublishdate Y2014-05-04T01:01:00+09:00xgsummary!H今日はelasticsearch-kopfのAnalysis画面の紹介です。 （簡単なところから。。。その３） ちょっとあいだが開いてしまいましwdtags2xpmelasticsearchfpluginxetitle `elasticsearch-kopfの紹介（aliases画面）vc222:yddate=Txcdirjpost/2014/xbid `e396cbf9274b590a1d94ee43d823a0bdxdlangbjayglastmod=Txipermalink zhttps://blog.johtani.info/blog/2014/04/24/usage-stream2es/xkpublishdate Y2014-04-24T21:11:00+09:00xgsummary!Hkopfの記事の続きも書く必要があるんだけど、こんなツイートを見つけてしまったので。。。 ElasticsearchのBulk APIの仕様、Jwdtags2xpmelasticsearchistream2esxetitle Rstream2esと複数データの登録vc223:yddatepxcdirjpost/2014/xbid `50562b09417cd8c4a2348a0a5aabe754xdlangbjayglastmodpxipermalink!Ghttps://blog.johtani.info/blog/2014/04/21/hold-on-4th-elasticsearch-jp/xkpublishdate Y2014-04-21T19:44:00+09:00xgsummary!H第4回Elsticsearch勉強会を開催しました。 今回から、遅刻厳禁にしてみました。 それほど困った人もいないと思うので、次回からも遅刻厳禁wdtags2xpmelasticsearchc勉強会xetitle k第4回Elasticsearch勉強会を開催しました。#elasticsearchjpvc224:yddate|xcdirjpost/2014/xbid `76a1fb7f21fda9eddb95426b65124517xdlangbjayglastmod|xipermalink!Lhttps://blog.johtani.info/blog/2014/04/09/intro-elasticsearch-kopf-analysis/xkpublishdate Y2014-04-09T11:41:00+09:00xgsummary!H今日はelasticsearch-kopfのAnalysis画面の紹介です。 （簡単なところから。。。その２） メニューのanalysisを選択wdtags2xpmelasticsearchfpluginxetitle aelasticsearch-kopfの紹介（analysis画面）vc225:yddate'3@xcdirjpost/2014/xbid `299abcee56b05b312ed5700f686f79b8xdlangbjayglastmod'3@xipermalink ~https://blog.johtani.info/blog/2014/04/07/attend-jvm-casual-1/xkpublishdate Y2014-04-07T19:24:00+09:00xgsummary!ZJVM Operation Casual Talksに参加しました。 あんまり、運用とかやってないので、ついていけるか不安ですが、楽しそうだったので。 懇親会は予定されてないらしいwdtags3xpcJVMdJavac勉強会xetitle lJVM Operation Casual Talksに参加しました #jvmcasualvc226:yddate 1@xcdirjpost/2014/xbid `670744b945088de05866864f7d57bee7xdlangbjayglastmod 1@xipermalink!Hhttps://blog.johtani.info/blog/2014/04/07/intro-elasticsearch-kopf-rest/xkpublishdate Y2014-04-07T11:24:00+09:00xgsummary!H今日はelasticsearch-kopfのREST画面の紹介です。 （簡単なところから。。。） メニューのrestを選択すると、次のような画面wdtags2xpmelasticsearchfpluginxetitle ]elasticsearch-kopfの紹介（rest画面）vc227:yddate
Xxcdirjpost/2014/xbid `c1241374502f200cf9fc49c8d6fb5822xdlangbjayglastmod
Xxipermalink!Ehttps://blog.johtani.info/blog/2014/04/05/intro-elasticsearch-kopf-1/xkpublishdate Y2014-04-05T23:18:00+09:00xgsummary!Hなんだか、ドタバタしてて久しぶりの更新です。 ベルリンの旅行記みたいなのも書きたいのですが、まずはこちらかと。 elasticsearch-kowdtags2xpmelasticsearchfpluginxetitle Yelasticsearch-kopfの紹介（概要）vc228:yddate%Txcdirjpost/2014/xbid `d51032bef3e7117a94336fea18a3fad7xdlangbjayglastmod%Txipermalink!Phttps://blog.johtani.info/blog/2014/03/25/release-elasticsearch-server-ja-ebook/xkpublishdate Y2014-03-25T13:43:00+09:00xgsummary!H先日、「ElasticSearch Serverを翻訳しました」という記事を書きました。 この中で電子版も出ますよと書いていましたが、電子版も発wdtags1xpmelasticsearchxetitle fElasticSearch Server日本語版（電子版も）が発売されましたvc229:yddate
+|xipermalink!Thttps://blog.johtani.info/blog/2014/05/04/intro-elasticsearch-kopf-alias-percolator/xkpublishdate Y2014-05-04T01:01:00+09:00xgsummary!H今日はelasticsearch-kopfのAnalysis画面の紹介です。 （簡単なところから。。。その３） ちょっとあいだが開いてしまいましwdtags2xpmelasticsearchfpluginxetitle `elasticsearch-kopfの紹介（aliases画面）vc223:yddate=Txcdirjpost/2014/xbid `e396cbf9274b590a1d94ee43d823a0bdxdlangbjayglastmod=Txipermalink zhttps://blog.johtani.info/blog/2014/04/24/usage-stream2es/xkpublishdate Y2014-04-24T21:11:00+09:00xgsummary!Hkopfの記事の続きも書く必要があるんだけど、こんなツイートを見つけてしまったので。。。 ElasticsearchのBulk APIの仕様、Jwdtags2xpmelasticsearchistream2esxetitle Rstream2esと複数データの登録vc224:yddatepxcdirjpost/2014/xbid `50562b09417cd8c4a2348a0a5aabe754xdlangbjayglastmodpxipermalink!Ghttps://blog.johtani.info/blog/2014/04/21/hold-on-4th-elasticsearch-jp/xkpublishdate Y2014-04-21T19:44:00+09:00xgsummary!H第4回Elsticsearch勉強会を開催しました。 今回から、遅刻厳禁にしてみました。 それほど困った人もいないと思うので、次回からも遅刻厳禁wdtags2xpmelasticsearchc勉強会xetitle k第4回Elasticsearch勉強会を開催しました。#elasticsearchjpvc225:yddate|xcdirjpost/2014/xbid `76a1fb7f21fda9eddb95426b65124517xdlangbjayglastmod|xipermalink!Lhttps://blog.johtani.info/blog/2014/04/09/intro-elasticsearch-kopf-analysis/xkpublishdate Y2014-04-09T11:41:00+09:00xgsummary!H今日はelasticsearch-kopfのAnalysis画面の紹介です。 （簡単なところから。。。その２） メニューのanalysisを選択wdtags2xpmelasticsearchfpluginxetitle aelasticsearch-kopfの紹介（analysis画面）vc226:yddate'3@xcdirjpost/2014/xbid `299abcee56b05b312ed5700f686f79b8xdlangbjayglastmod'3@xipermalink ~https://blog.johtani.info/blog/2014/04/07/attend-jvm-casual-1/xkpublishdate Y2014-04-07T19:24:00+09:00xgsummary!ZJVM Operation Casual Talksに参加しました。 あんまり、運用とかやってないので、ついていけるか不安ですが、楽しそうだったので。 懇親会は予定されてないらしいwdtags3xpcJVMdJavac勉強会xetitle lJVM Operation Casual Talksに参加しました #jvmcasualvc227:yddate 1@xcdirjpost/2014/xbid `670744b945088de05866864f7d57bee7xdlangbjayglastmod 1@xipermalink!Hhttps://blog.johtani.info/blog/2014/04/07/intro-elasticsearch-kopf-rest/xkpublishdate Y2014-04-07T11:24:00+09:00xgsummary!H今日はelasticsearch-kopfのREST画面の紹介です。 （簡単なところから。。。） メニューのrestを選択すると、次のような画面wdtags2xpmelasticsearchfpluginxetitle ]elasticsearch-kopfの紹介（rest画面）vc228:yddate
Xxcdirjpost/2014/xbid `c1241374502f200cf9fc49c8d6fb5822xdlangbjayglastmod
Xxipermalink!Ehttps://blog.johtani.info/blog/2014/04/05/intro-elasticsearch-kopf-1/xkpublishdate Y2014-04-05T23:18:00+09:00xgsummary!Hなんだか、ドタバタしてて久しぶりの更新です。 ベルリンの旅行記みたいなのも書きたいのですが、まずはこちらかと。 elasticsearch-kowdtags2xpmelasticsearchfpluginxetitle Yelasticsearch-kopfの紹介（概要）vc229:yddate%Txcdirjpost/2014/xbid `d51032bef3e7117a94336fea18a3fad7xdlangbjayglastmod%Txipermalink!Phttps://blog.johtani.info/blog/2014/03/25/release-elasticsearch-server-ja-ebook/xkpublishdate Y2014-03-25T13:43:00+09:00xgsummary!H先日、「ElasticSearch Serverを翻訳しました」という記事を書きました。 この中で電子版も出ますよと書いていましたが、電子版も発wdtags1xpmelasticsearchxetitle fElasticSearch Server日本語版（電子版も）が発売されましたvc230:yddate
 txcdirjpost/2014/xbid `65453a1ae403679bd2e47398a04205caxdlangbjayglastmod
-txipermalink!Jhttps://blog.johtani.info/blog/2014/03/18/attend-goto-night-elasticsearch/xkpublishdate Y2014-03-18T23:11:00+09:00xgsummary!QGOTO Night elasticsearchに参加しました。 初の海外の勉強会です（海外自体が初だし）。 ベルリンにあるWoogaという会社で開催された勉強会wdtags2xpmelasticsearchc勉強会xetitle _GOTO Night elasticsearchに参加しましたvc230:yddate	4txcdirjpost/2014/xbid `abc5ca9856a61831fd4ed06b402875d2xdlangbjayglastmod	4txipermalink {https://blog.johtani.info/blog/2014/03/16/post-from-berlin/xkpublishdate Y2014-03-16T05:51:00+09:00xgsummary!HBerlinからおはようございます。 ということで、人生で初めての海外に来ています。 人生初の海外なのに、一人で乗り換えがあるようなBerlinwdtags2xpdmiscftravelxetitle QBerlinからおはようございますvc231:yddate)6txcdirjpost/2014/xbid `386dc9d1b647a9f3965f1fbe29c7dfb9xdlangbjayglastmod)6txipermalink!Hhttps://blog.johtani.info/blog/2014/03/11/es-plugin-installed-to-my-env/xkpublishdate Y2014-03-11T14:23:00+09:00xgsummary!Felasticsearchに、このへん入れるときっと幸せになれるはず・たぶん。&#10;elasticsearch/elasticsearcwdtags2xpmelasticsearchfpluginxetitle [いつも入れているElasticsearchのプラグインvc232:yddate
dxcdirjpost/2014/xbid `9ad72c2a5157f21741bd4581a562dfc7xdlangbjayglastmod
dxipermalink!Xhttps://blog.johtani.info/blog/2014/03/03/release-elasticsearch-server-japanese-edition/xkpublishdate Y2014-03-03T17:55:00+09:00xgsummary!H第3回Elasticsearch勉強会で、軽く触れていましたが、ElasticSearch Server日本語版が発売されます。 ツイートなどもwdtags1xpmelasticsearchxetitle [ElasticSearch Serverを翻訳しましたvc233:yddate0 pxcdirjpost/2014/xbid `f55d33371dcff207fd7d201128df2ea3xdlangbjayglastmod0 pxipermalink!Rhttps://blog.johtani.info/blog/2014/02/24/strange-behavior-of-field-in-nested-obj/xkpublishdate Y2014-02-24T17:52:00+09:00xgsummary!G今年初の「突撃！隣のElasticsearch」ということで、Wantedlyさんにおじゃましました。 ※写真を自分でも撮ったのですが、画像がwdtags1xpmelasticsearchxetitle YNested Objectのフィールドの奇妙な動作vc234:yddate=;Hxcdirjpost/2014/xbid `229b7fc784707b1d2c702fbeba080e86xdlangbjayglastmod=;Hxipermalink!Qhttps://blog.johtani.info/blog/2014/02/08/hold-3rd-elasticsaerch-meetup-in-tokyo/xkpublishdate Y2014-02-08T00:42:00+09:00xgsummary!G今回はたまたま日本にいたElasticsearchの人をスペシャルゲストに呼べたので、大満足ですｗ 英語の通訳とかちゃんと勉強しないとなぁ。。wdtags2xpmelasticsearchc勉強会xetitle l第3回elasticsearch勉強会を開催しました！ #elasticsearchjpvc235:yddate<9|xcdirjpost/2014/xbid `c98cbc333fb7d95c6c9fc4924b0526e1xdlangbjayglastmod<9|xipermalink!Thttps://blog.johtani.info/blog/2014/02/06/es-cluster-start-using-vagrant-and-puppet/xkpublishdate Y2014-02-06T23:09:00+09:00xgsummary!FすずけんさんがVagrant+puppet使って、VM起動してElasticsearchのクラスタを組んでる記事を書いているのを見て、試してwdtags4xpmelasticsearchgvagrantfpuppetfmarvelxetitle lすずけんさんのメモを元にVagrantでElasticsearchクラスタを起動してみたvc236:yddate:7Xxcdirjpost/2014/xbid `c6107ff57e96a1373c019d252c00ad84xdlangbjayglastmod:7Xxipermalink!Dhttps://blog.johtani.info/blog/2014/01/29/hold-to-japan-solr-meetup/xkpublishdate Y2014-01-29T18:46:00+09:00xgsummary!O改訂新版Solr入門出版記念ということで、第13回Solr勉強会 #SolrJP 新Solr本出版記念を開催しました。 出版記念なので、技術評論社様より、プレwdtags2xpdSolrc勉強会xetitle R第13回Solr勉強会を開催しましたvc237:yddate:!Hxcdirjpost/2014/xbid `f6debed350f20a2b3aa4d970e3227411xdlangbjayglastmod:!Hxipermalink!]https://blog.johtani.info/blog/2014/01/29/simple-introduction-and-first-impression-es-marvel/xkpublishdate Y2014-01-29T17:14:00+09:00xgsummary!F昨晩、Elasticsearchから初のプロダクトとなるMarvelがリリースされました。ということで、さっそく触ってみて、簡単な紹介と感想wdtags2xpmelasticsearchfmarvelxetitle \Elasticsearch Marvelの紹介と第一印象vc238:yddate92hxcdirjpost/2014/xbid `c4e7199a586a308352b7a881add7e356xdlangbjayglastmod92hxipermalink!Ihttps://blog.johtani.info/blog/2014/01/28/release-lucene-gosen-4-dot-6-1/xkpublishdate Y2014-01-28T12:34:00+09:00xgsummary!RLucene/Solr 4.6.1がリリースされそう(バイナリ配布待ち)lucene-gosenの4.6.1対応版をリリースしました。 ライブラリのインタフェースなwdtags3xpdSolrfLucenellucene-gosenxetitle ^lucene-gosen 4.6.1のリリースに関する注意点vc239:yddate8:Pxcdirjpost/2014/xbid `15f501351d482ffd73985a50f5c89d1fxdlangbjayglastmod8:Pxipermalink!_https://blog.johtani.info/blog/2014/01/24/curator-tending-your-time-series-indices-in-japanese/xkpublishdate Y2014-01-24T14:48:00+09:00xgsummary!GElasticsearchのcuratorのブログ記事を読んで、日本語でツイートしたところ、Aaron Mildensteinさんから日本語（wdtags2xpmelasticsearchgcuratorxetitle [Curator: 時系列インデックスの管理(日本語訳)vc240:yddate7(<pxcdirjpost/2014/xbid `6425af51edead39c0e439073986043fbxdlangbjayglastmod7(<pxipermalink!Ohttps://blog.johtani.info/blog/2014/01/22/release-extended-plugin-for-1-0-0rc1/xkpublishdate Y2014-01-22T00:16:00+09:00xgsummary!Gあけましておめでとうございます。今年もSolrやElasticsearchについて色々と頑張っていく所存です。 とまぁ、お決まりの挨拶はおいてwdtags1xpmelasticsearchxetitle bExtended-Analyze 1.0.0RC1をリリースしましたvc241:yddate0pxcdirjpost/2013/xbid `10c715f70de25ccb493bbbb532b78cedxdlangbjayglastmod0pxipermalink |https://blog.johtani.info/blog/2013/12/30/looking-back-2013/xkpublishdate Y2013-12-30T21:20:00+09:00xgsummary!I昨年は、大晦日に書いてました。 ちょっと進歩したかも。 振り返り(2012年に書いた抱負から) ということで、まずは昨年書いた抱負からの振り返りでwdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2013）vc242:yddate,?Pxcdirjpost/2013/xbid `c18b12fff24dc87e7f1039bd17c0c6aaxdlangbjayglastmod,?Pxipermalink!Ghttps://blog.johtani.info/blog/2013/12/20/release-elasticsearch-0-90-8/xkpublishdate Y2013-12-20T16:24:00+09:00xgsummary!H昨夜、Elasticsearchの0.90.8がリリースされました。 リリースされた内容などについては、本家のブログ「0.90.8 releaswdtags2xpmelasticsearchhkuromojixetitle pElasticsearch 0.90.8がリリースされました＆注意点（2013/12/20追記）vc243:yddate,,|xcdirjpost/2013/xbid `cb5b6f7ab4d36e90d2619cb907ebb956xdlangbjayglastmod,,|xipermalink https://blog.johtani.info/blog/2013/12/19/add-jar-file-to-solr/xkpublishdate Y2013-12-19T19:09:00+09:00xgsummary!GSolr本が出てから、質問を受けてブログ書くと言いながら書いてなかったことを思い出しました。。。 プラグインの配置方法についてこんな質問を受けwdtags1xpdSolrxetitle TSolrへのプラグインの配置方法についてvc244:yddate+<Dxcdirjpost/2013/xbid `a0a00c23556fcc5dbfb7b7f43fbbb61dxdlangbjayglastmod+<Dxipermalink!chttps://blog.johtani.info/blog/2013/12/17/release-es-extended-analyze-plugin-to-maven-and-sonatype/xkpublishdate Y2013-12-17T12:11:00+09:00xgsummary!Iども。 プラグインのインストールに長いURL入れるの辛いですよね？ね？ ということで、MavenでリリースしてMaven Repositoryからwdtags1xpmelasticsearchxetitle welasticsearch-extended-analyzeプラグインをMavenとSonatypeにリリースvc245:yddate)@xcdirjpost/2013/xbid `d9560caeb797b302191f667b4264da40xdlangbjayglastmod)@xipermalink!Jhttps://blog.johtani.info/blog/2013/12/09/release-introduction-solr-ebook/xkpublishdate Y2013-12-09T11:08:00+09:00xgsummary!I少し遅くなってしまいましたが、12/05に電子書籍も発売されました。 技術評論社の電子書籍サイトから購入可能です。 書籍のページへのリンク PDFwdtags1xpdSolrxetitle Q改訂版Solr入門のPDF版も発売vc246:yddate%
Dxcdirjpost/2013/xbid `a2012a3c9cdb1d6fd69afdbadc1e76b6xdlangbjayglastmod%
Dxipermalink!Khttps://blog.johtani.info/blog/2013/11/26/introduction-to-solr-new-edition/xkpublishdate Y2013-11-26T12:27:00+09:00xgsummary!I勉強会で宣伝もしましたが、改めて。 Solr入門の改訂版を執筆しました。 考えてみれば、もう3年も前なんですね、Solr入門は。 Solr勉強会なwdtags1xpdSolrxetitle P改訂版Solr入門を執筆しましたvc247:yddate!?dxcdirjpost/2013/xbid `13684d16fdd07d5f0584e29265a270e7xdlangbjayglastmod!?dxipermalink!Yhttps://blog.johtani.info/blog/2013/11/14/release-elasticsearch-extended-analyze-0-dot-5/xkpublishdate Y2013-11-14T17:55:00+09:00xgsummary!Gどーも。以前の記事で開発中としていたプラグインですが、とりあえず、pluginコマンドでインストール出来る形にしてみました。 インストールなどwdtags2xpmelasticsearchfpluginxetitle belasticsearch-extended-analyzeを公開？vc248:yddate Pxcdirjpost/2013/xbid `66f43ab4b823d67f52735bbbe6ba65b0xdlangbjayglastmod Pxipermalink!Nhttps://blog.johtani.info/blog/2013/11/12/elasticsearch-japan-user-meetup-no2/xkpublishdate Y2013-11-12T18:16:00+09:00xgsummary!H第2回を開催しました！ すごい、140人くらいくらいの参加登録者（参加者は１００人ちょっと！）がいて、びっくりです。 ステキな会場を提供していたwdtags4xpmelasticsearchfkibanagfluentdc勉強会xetitle l第2回elasticsearch勉強会を開催しました！ #elasticsearchjpvc249:yddate."dxcdirjpost/2013/xbid `a106d7c1b1b277538367f9c8140e3a75xdlangbjayglastmod."dxipermalink!Dhttps://blog.johtani.info/blog/2013/11/07/cloudera-world-tokyo-2013/xkpublishdate Y2013-11-07T10:11:00+09:00xgsummary!ZCloudera World Tokyo 2013に参加してきました。 午前中はあいにくの雨でしたが、それでも結構な人数が最初の基調講演から参加されてました。 私が参加したセッショwdtags3xphClouderafHadoopgNorikraxetitle kCloudera World Tokyo 2013に参加しました！ #cwt2013 vc250:yddate$.\xcdirjpost/2013/xbid `9dca844d353efed03fbaddfc0fab7c76xdlangbjayglastmod$.\xipermalink!@https://blog.johtani.info/blog/2013/11/06/riak-meetup-tokyo-no3/xkpublishdate Y2013-11-06T23:01:00+09:00xgsummary!Sまたまた、Riak Meetup Tokyo #3に参加してきました。Riak2.0のYokozunaの話があると聞いたので。 ということで、いつものように個人メモでwdtags2xpdRiakhYokozunaxetitle _Riak Meetup #3 #riakjp に参加しました。vc251:yddate94`xcdirjpost/2013/xbid `b5c628b0c1dbf857a475c4be5de4690dxdlangbjayglastmod94`xipermalink!Jhttps://blog.johtani.info/blog/2013/11/04/improve-output-extended-analyze/xkpublishdate Y2013-11-04T22:12:00+09:00xgsummary!H開発中ですと書きました、elasticsearch-extended-analyzeですが、改良しました。 改良と変更は以下のとおりです。 ソーwdtags2xpmelasticsearchfpluginxetitle aelasticsearch-extended-analyzeの改良vc252:yddate$
+txipermalink!Jhttps://blog.johtani.info/blog/2014/03/18/attend-goto-night-elasticsearch/xkpublishdate Y2014-03-18T23:11:00+09:00xgsummary!QGOTO Night elasticsearchに参加しました。 初の海外の勉強会です（海外自体が初だし）。 ベルリンにあるWoogaという会社で開催された勉強会wdtags2xpmelasticsearchc勉強会xetitle _GOTO Night elasticsearchに参加しましたvc231:yddate	4txcdirjpost/2014/xbid `abc5ca9856a61831fd4ed06b402875d2xdlangbjayglastmod	4txipermalink {https://blog.johtani.info/blog/2014/03/16/post-from-berlin/xkpublishdate Y2014-03-16T05:51:00+09:00xgsummary!HBerlinからおはようございます。 ということで、人生で初めての海外に来ています。 人生初の海外なのに、一人で乗り換えがあるようなBerlinwdtags2xpdmiscftravelxetitle QBerlinからおはようございますvc232:yddate)6txcdirjpost/2014/xbid `386dc9d1b647a9f3965f1fbe29c7dfb9xdlangbjayglastmod)6txipermalink!Hhttps://blog.johtani.info/blog/2014/03/11/es-plugin-installed-to-my-env/xkpublishdate Y2014-03-11T14:23:00+09:00xgsummary!Felasticsearchに、このへん入れるときっと幸せになれるはず・たぶん。&#10;elasticsearch/elasticsearcwdtags2xpmelasticsearchfpluginxetitle [いつも入れているElasticsearchのプラグインvc233:yddate
dxcdirjpost/2014/xbid `9ad72c2a5157f21741bd4581a562dfc7xdlangbjayglastmod
dxipermalink!Xhttps://blog.johtani.info/blog/2014/03/03/release-elasticsearch-server-japanese-edition/xkpublishdate Y2014-03-03T17:55:00+09:00xgsummary!H第3回Elasticsearch勉強会で、軽く触れていましたが、ElasticSearch Server日本語版が発売されます。 ツイートなどもwdtags1xpmelasticsearchxetitle [ElasticSearch Serverを翻訳しましたvc234:yddate0 pxcdirjpost/2014/xbid `f55d33371dcff207fd7d201128df2ea3xdlangbjayglastmod0 pxipermalink!Rhttps://blog.johtani.info/blog/2014/02/24/strange-behavior-of-field-in-nested-obj/xkpublishdate Y2014-02-24T17:52:00+09:00xgsummary!G今年初の「突撃！隣のElasticsearch」ということで、Wantedlyさんにおじゃましました。 ※写真を自分でも撮ったのですが、画像がwdtags1xpmelasticsearchxetitle YNested Objectのフィールドの奇妙な動作vc235:yddate=;Hxcdirjpost/2014/xbid `229b7fc784707b1d2c702fbeba080e86xdlangbjayglastmod=;Hxipermalink!Qhttps://blog.johtani.info/blog/2014/02/08/hold-3rd-elasticsaerch-meetup-in-tokyo/xkpublishdate Y2014-02-08T00:42:00+09:00xgsummary!G今回はたまたま日本にいたElasticsearchの人をスペシャルゲストに呼べたので、大満足ですｗ 英語の通訳とかちゃんと勉強しないとなぁ。。wdtags2xpmelasticsearchc勉強会xetitle l第3回elasticsearch勉強会を開催しました！ #elasticsearchjpvc236:yddate<9|xcdirjpost/2014/xbid `c98cbc333fb7d95c6c9fc4924b0526e1xdlangbjayglastmod<9|xipermalink!Thttps://blog.johtani.info/blog/2014/02/06/es-cluster-start-using-vagrant-and-puppet/xkpublishdate Y2014-02-06T23:09:00+09:00xgsummary!FすずけんさんがVagrant+puppet使って、VM起動してElasticsearchのクラスタを組んでる記事を書いているのを見て、試してwdtags4xpmelasticsearchgvagrantfpuppetfmarvelxetitle lすずけんさんのメモを元にVagrantでElasticsearchクラスタを起動してみたvc237:yddate:7Xxcdirjpost/2014/xbid `c6107ff57e96a1373c019d252c00ad84xdlangbjayglastmod:7Xxipermalink!Dhttps://blog.johtani.info/blog/2014/01/29/hold-to-japan-solr-meetup/xkpublishdate Y2014-01-29T18:46:00+09:00xgsummary!O改訂新版Solr入門出版記念ということで、第13回Solr勉強会 #SolrJP 新Solr本出版記念を開催しました。 出版記念なので、技術評論社様より、プレwdtags2xpdSolrc勉強会xetitle R第13回Solr勉強会を開催しましたvc238:yddate:!Hxcdirjpost/2014/xbid `f6debed350f20a2b3aa4d970e3227411xdlangbjayglastmod:!Hxipermalink!]https://blog.johtani.info/blog/2014/01/29/simple-introduction-and-first-impression-es-marvel/xkpublishdate Y2014-01-29T17:14:00+09:00xgsummary!F昨晩、Elasticsearchから初のプロダクトとなるMarvelがリリースされました。ということで、さっそく触ってみて、簡単な紹介と感想wdtags2xpmelasticsearchfmarvelxetitle \Elasticsearch Marvelの紹介と第一印象vc239:yddate92hxcdirjpost/2014/xbid `c4e7199a586a308352b7a881add7e356xdlangbjayglastmod92hxipermalink!Ihttps://blog.johtani.info/blog/2014/01/28/release-lucene-gosen-4-dot-6-1/xkpublishdate Y2014-01-28T12:34:00+09:00xgsummary!RLucene/Solr 4.6.1がリリースされそう(バイナリ配布待ち)lucene-gosenの4.6.1対応版をリリースしました。 ライブラリのインタフェースなwdtags3xpdSolrfLucenellucene-gosenxetitle ^lucene-gosen 4.6.1のリリースに関する注意点vc240:yddate8:Pxcdirjpost/2014/xbid `15f501351d482ffd73985a50f5c89d1fxdlangbjayglastmod8:Pxipermalink!_https://blog.johtani.info/blog/2014/01/24/curator-tending-your-time-series-indices-in-japanese/xkpublishdate Y2014-01-24T14:48:00+09:00xgsummary!GElasticsearchのcuratorのブログ記事を読んで、日本語でツイートしたところ、Aaron Mildensteinさんから日本語（wdtags2xpmelasticsearchgcuratorxetitle [Curator: 時系列インデックスの管理(日本語訳)vc241:yddate7(<pxcdirjpost/2014/xbid `6425af51edead39c0e439073986043fbxdlangbjayglastmod7(<pxipermalink!Ohttps://blog.johtani.info/blog/2014/01/22/release-extended-plugin-for-1-0-0rc1/xkpublishdate Y2014-01-22T00:16:00+09:00xgsummary!Gあけましておめでとうございます。今年もSolrやElasticsearchについて色々と頑張っていく所存です。 とまぁ、お決まりの挨拶はおいてwdtags1xpmelasticsearchxetitle bExtended-Analyze 1.0.0RC1をリリースしましたvc242:yddate0pxcdirjpost/2013/xbid `10c715f70de25ccb493bbbb532b78cedxdlangbjayglastmod0pxipermalink |https://blog.johtani.info/blog/2013/12/30/looking-back-2013/xkpublishdate Y2013-12-30T21:20:00+09:00xgsummary!I昨年は、大晦日に書いてました。 ちょっと進歩したかも。 振り返り(2012年に書いた抱負から) ということで、まずは昨年書いた抱負からの振り返りでwdtags1xpd振り返りxetitle S今年の振り返りと来年の抱負（2013）vc243:yddate,?Pxcdirjpost/2013/xbid `c18b12fff24dc87e7f1039bd17c0c6aaxdlangbjayglastmod,?Pxipermalink!Ghttps://blog.johtani.info/blog/2013/12/20/release-elasticsearch-0-90-8/xkpublishdate Y2013-12-20T16:24:00+09:00xgsummary!H昨夜、Elasticsearchの0.90.8がリリースされました。 リリースされた内容などについては、本家のブログ「0.90.8 releaswdtags2xpmelasticsearchhkuromojixetitle pElasticsearch 0.90.8がリリースされました＆注意点（2013/12/20追記）vc244:yddate,,|xcdirjpost/2013/xbid `cb5b6f7ab4d36e90d2619cb907ebb956xdlangbjayglastmod,,|xipermalink https://blog.johtani.info/blog/2013/12/19/add-jar-file-to-solr/xkpublishdate Y2013-12-19T19:09:00+09:00xgsummary!GSolr本が出てから、質問を受けてブログ書くと言いながら書いてなかったことを思い出しました。。。 プラグインの配置方法についてこんな質問を受けwdtags1xpdSolrxetitle TSolrへのプラグインの配置方法についてvc245:yddate+<Dxcdirjpost/2013/xbid `a0a00c23556fcc5dbfb7b7f43fbbb61dxdlangbjayglastmod+<Dxipermalink!chttps://blog.johtani.info/blog/2013/12/17/release-es-extended-analyze-plugin-to-maven-and-sonatype/xkpublishdate Y2013-12-17T12:11:00+09:00xgsummary!Iども。 プラグインのインストールに長いURL入れるの辛いですよね？ね？ ということで、MavenでリリースしてMaven Repositoryからwdtags1xpmelasticsearchxetitle welasticsearch-extended-analyzeプラグインをMavenとSonatypeにリリースvc246:yddate)@xcdirjpost/2013/xbid `d9560caeb797b302191f667b4264da40xdlangbjayglastmod)@xipermalink!Jhttps://blog.johtani.info/blog/2013/12/09/release-introduction-solr-ebook/xkpublishdate Y2013-12-09T11:08:00+09:00xgsummary!I少し遅くなってしまいましたが、12/05に電子書籍も発売されました。 技術評論社の電子書籍サイトから購入可能です。 書籍のページへのリンク PDFwdtags1xpdSolrxetitle Q改訂版Solr入門のPDF版も発売vc247:yddate%
Dxcdirjpost/2013/xbid `a2012a3c9cdb1d6fd69afdbadc1e76b6xdlangbjayglastmod%
Dxipermalink!Khttps://blog.johtani.info/blog/2013/11/26/introduction-to-solr-new-edition/xkpublishdate Y2013-11-26T12:27:00+09:00xgsummary!I勉強会で宣伝もしましたが、改めて。 Solr入門の改訂版を執筆しました。 考えてみれば、もう3年も前なんですね、Solr入門は。 Solr勉強会なwdtags1xpdSolrxetitle P改訂版Solr入門を執筆しましたvc248:yddate!?dxcdirjpost/2013/xbid `13684d16fdd07d5f0584e29265a270e7xdlangbjayglastmod!?dxipermalink!Yhttps://blog.johtani.info/blog/2013/11/14/release-elasticsearch-extended-analyze-0-dot-5/xkpublishdate Y2013-11-14T17:55:00+09:00xgsummary!Gどーも。以前の記事で開発中としていたプラグインですが、とりあえず、pluginコマンドでインストール出来る形にしてみました。 インストールなどwdtags2xpmelasticsearchfpluginxetitle belasticsearch-extended-analyzeを公開？vc249:yddate Pxcdirjpost/2013/xbid `66f43ab4b823d67f52735bbbe6ba65b0xdlangbjayglastmod Pxipermalink!Nhttps://blog.johtani.info/blog/2013/11/12/elasticsearch-japan-user-meetup-no2/xkpublishdate Y2013-11-12T18:16:00+09:00xgsummary!H第2回を開催しました！ すごい、140人くらいくらいの参加登録者（参加者は１００人ちょっと！）がいて、びっくりです。 ステキな会場を提供していたwdtags4xpmelasticsearchfkibanagfluentdc勉強会xetitle l第2回elasticsearch勉強会を開催しました！ #elasticsearchjpvc250:yddate."dxcdirjpost/2013/xbid `a106d7c1b1b277538367f9c8140e3a75xdlangbjayglastmod."dxipermalink!Dhttps://blog.johtani.info/blog/2013/11/07/cloudera-world-tokyo-2013/xkpublishdate Y2013-11-07T10:11:00+09:00xgsummary!ZCloudera World Tokyo 2013に参加してきました。 午前中はあいにくの雨でしたが、それでも結構な人数が最初の基調講演から参加されてました。 私が参加したセッショwdtags3xphClouderafHadoopgNorikraxetitle kCloudera World Tokyo 2013に参加しました！ #cwt2013 vc251:yddate$.\xcdirjpost/2013/xbid `9dca844d353efed03fbaddfc0fab7c76xdlangbjayglastmod$.\xipermalink!@https://blog.johtani.info/blog/2013/11/06/riak-meetup-tokyo-no3/xkpublishdate Y2013-11-06T23:01:00+09:00xgsummary!Sまたまた、Riak Meetup Tokyo #3に参加してきました。Riak2.0のYokozunaの話があると聞いたので。 ということで、いつものように個人メモでwdtags2xpdRiakhYokozunaxetitle _Riak Meetup #3 #riakjp に参加しました。vc252:yddate94`xcdirjpost/2013/xbid `b5c628b0c1dbf857a475c4be5de4690dxdlangbjayglastmod94`xipermalink!Jhttps://blog.johtani.info/blog/2013/11/04/improve-output-extended-analyze/xkpublishdate Y2013-11-04T22:12:00+09:00xgsummary!H開発中ですと書きました、elasticsearch-extended-analyzeですが、改良しました。 改良と変更は以下のとおりです。 ソーwdtags2xpmelasticsearchfpluginxetitle aelasticsearch-extended-analyzeの改良vc253:yddate$
 Hxcdirjpost/2013/xbid `0302e8a57a5e8604342a925b2dc60737xdlangbjayglastmod$
-Hxipermalink!Phttps://blog.johtani.info/blog/2013/10/25/developing-es-extended-analyze-plugin/xkpublishdate Y2013-10-25T19:06:00+09:00xgsummary!Hお久しぶりです。 気づいたらまた、結構ブログを書いてなかったです。。。 今回は、今開発しているElasticsearchのプラグインに関するお話wdtags2xpmelasticsearchfpluginxetitle gelasticsearch-extended-analyzeプラグインを開発中vc253:yddate!	Txcdirjpost/2013/xbid `76e127a44931bfefab991be3dd7a08b7xdlangbjayglastmod!	Txipermalink {https://blog.johtani.info/blog/2013/10/10/solr-meetup-memo/xkpublishdate Y2013-10-10T11:35:00+09:00xgsummary!G不定期開催ですが第12回Solr勉強会を主催しました。 今回は、前回ほどの過熱ぶりでは無かったですが、70人ほどの参加者の方がいらっしゃったかwdtags4xpdSolrdRiakhYokozunajManifoldCFxetitle Z第12回Solr勉強会を主催しました。#SolrJPvc254:yddate;Dxcdirjpost/2013/xbid `e1870dde155be1a375f155dd1f7ead13xdlangbjayglastmod;Dxipermalink!Ihttps://blog.johtani.info/blog/2013/09/23/intro-elasticsearch-inquisitor/xkpublishdate Y2013-09-23T12:27:00+09:00xgsummary!G今日は、ElasticSearchのMLで見つけたelasticsearch-inquisitorプラグインの紹介です。 ElasticSeawdtags2xpmelasticsearchfpluginxetitle `elasticsearch-inquisitorプラグインの紹介vc255:yddate
+Hxipermalink!Phttps://blog.johtani.info/blog/2013/10/25/developing-es-extended-analyze-plugin/xkpublishdate Y2013-10-25T19:06:00+09:00xgsummary!Hお久しぶりです。 気づいたらまた、結構ブログを書いてなかったです。。。 今回は、今開発しているElasticsearchのプラグインに関するお話wdtags2xpmelasticsearchfpluginxetitle gelasticsearch-extended-analyzeプラグインを開発中vc254:yddate!	Txcdirjpost/2013/xbid `76e127a44931bfefab991be3dd7a08b7xdlangbjayglastmod!	Txipermalink {https://blog.johtani.info/blog/2013/10/10/solr-meetup-memo/xkpublishdate Y2013-10-10T11:35:00+09:00xgsummary!G不定期開催ですが第12回Solr勉強会を主催しました。 今回は、前回ほどの過熱ぶりでは無かったですが、70人ほどの参加者の方がいらっしゃったかwdtags4xpdSolrdRiakhYokozunajManifoldCFxetitle Z第12回Solr勉強会を主催しました。#SolrJPvc255:yddate;Dxcdirjpost/2013/xbid `e1870dde155be1a375f155dd1f7ead13xdlangbjayglastmod;Dxipermalink!Ihttps://blog.johtani.info/blog/2013/09/23/intro-elasticsearch-inquisitor/xkpublishdate Y2013-09-23T12:27:00+09:00xgsummary!G今日は、ElasticSearchのMLで見つけたelasticsearch-inquisitorプラグインの紹介です。 ElasticSeawdtags2xpmelasticsearchfpluginxetitle `elasticsearch-inquisitorプラグインの紹介vc256:yddate
 )xxcdirjpost/2013/xbid `d2e805472f79f0b558f75b90b5e7b4eexdlangbjayglastmod
-)xxipermalink!Chttps://blog.johtani.info/blog/2013/09/12/question-river-wikipedia/xkpublishdate Y2013-09-12T02:38:00+09:00xgsummary!Friver-wikipediaの前々回の記事で書きましたが、bulk_sizeに関連して登録件数がやけにきりが良いのが気になると書いていましwdtags2xpmelasticsearchiwikipediaxetitle aelasticsearch-river-wikipediaの疑問点vc256:yddate	&Dxcdirjpost/2013/xbid `79e647a3f8b36a1221897f5837c84affxdlangbjayglastmod	&Dxipermalink!Ehttps://blog.johtani.info/blog/2013/09/03/ja-wikipedia-with-kuromoji/xkpublishdate Y2013-09-03T01:15:00+09:00xgsummary!G前々回紹介した、日本語Wikipediaのデータをインデックス登録する記事の続きです。 今回は、Kuromojiのアナライザを利用してインデッwdtags3xpmelasticsearchhkuromojiiwikipediaxetitle c日本語Wikipediaをインデクシング（Kuromojiバージョン）vc257:yddate8hxcdirjpost/2013/xbid `5931f8e3acdac724742c4ee0960d8d40xdlangbjayglastmod8hxipermalink!Shttps://blog.johtani.info/blog/2013/08/30/hold-first-elasticsearch-meetup-in-japan/xkpublishdate Y2013-08-30T02:42:00+09:00xgsummary!IElasticSearch勉強会 第1回を主催しました。 昨年のpyfesでなんちゃって資料で喋って、1年たちました。 ElasticSearchwdtags2xpmelasticsearchc勉強会xetitle l第1回ElasticSearch勉強会を開催しました！ #elasticsearchjpvc258:yddate-hxcdirjpost/2013/xbid `3931327ed463d1568868c5ab8e839148xdlangbjayglastmod-hxipermalink!Nhttps://blog.johtani.info/blog/2013/08/23/index-wikipedia-ja-to-elasticsearch/xkpublishdate Y2013-08-23T12:02:00+09:00xgsummary!G久々のブログはElasticSearchネタです。勉強会開催する予定だったりすので、もう少し触っておきたいなと。 お手軽に検索するデータとしてwdtags2xpmelasticsearchiwikipediaxetitle kElasticSearchにプラグインで日本語Wikipediaデータを入れてみましたvc259:yddate>7Hxcdirjpost/2013/xbid `33e01e2271be22b5ed330045fe6aff50xdlangbjayglastmod>7Hxipermalink ~https://blog.johtani.info/blog/2013/08/02/morphlines-loadsolr/xkpublishdate Y2013-08-02T18:02:00+09:00xgsummary!H宿題その2？かな。Solr勉強会でCloudera Searchのスキーマ周りってどうなってるの？という質問が出てて、 なんか調べることになってwdtags3xpoCloudera SearchjMorphlinesdSolrxetitle _MorphlinesのloadSolrをちょっとだけ調べてみたvc260:yddate>&xxcdirjpost/2013/xbid `cd9ba1f582642d9cbe500f018afab341xdlangbjayglastmod>&xxipermalink {https://blog.johtani.info/blog/2013/08/01/replace-xperia-z/xkpublishdate Y2013-08-01T22:38:00+09:00xgsummary!H今朝起きたら、Xperia Zが故障してしまいました。 電源ボタンを押してもスリープにならないんです。しかも、スリープからの復帰もできない。。。wdtags1xphXperia Zxetitle WXperia Zが故障したので交換したのでメモvc261:yddate>pxcdirjpost/2013/xbid `b875f24d3d444fdda82b6bbfb75a4c92xdlangbjayglastmod>pxipermalink!Bhttps://blog.johtani.info/blog/2013/07/31/introduction-morphlines/xkpublishdate Y2013-07-31T19:12:00+09:00xgsummary!HMorphlinesについてちょっとだけ、さらに調べました。 誤解 Solr勉強会でなんとなく私の認識を話しましたが、ちょっと誤解してたみたいでwdtags3xpoCloudera SearchjMorphlinesdSolrxetitlemMorphlines入門？vc262:yddate='#dxcdirjpost/2013/xbid `59d1b7206e7664e76672d3de4dc9a8edxdlangbjayglastmod='#dxipermalink xhttps://blog.johtani.info/blog/2013/07/29/study-of-solr/xkpublishdate Y2013-07-29T23:15:00+09:00xgsummary!G不定期開催ですが第11回Solr勉強会を主催しました。 今回も大入り90人くらい？の参加者の皆さんがいらっしゃいました。ありがたいことです！（wdtags3xpdSolroCloudera SearchjManifoldCFxetitle Z第11回Solr勉強会を主催しました。#SolrJPvc263:yddate<*dxcdirjpost/2013/xbid `1b9c5ae60ec46be64a1877f0c6920edcxdlangbjayglastmod<*dxipermalink!Hhttps://blog.johtani.info/blog/2013/07/25/hadoop-hive-publication-party/xkpublishdate Y2013-07-25T02:11:00+09:00xgsummary!HHadoopとか離れちゃってるし、Hive触ったこと無いにもかかわらず参加しました！ （たまたま近くにいるからって理由なのは内緒で） 玉川さんのwdtags4xpfHadoopdHivehClouderaeオライリーxetitle x『プログラミング Hive』 『Hadoop 第3版』刊行記念セミナーに参加しました！ #oreilly0724vc264:yddate7<Txcdirjpost/2013/xbid `50557b455cba1a3ce9b4555fc3fd5433xdlangbjayglastmod7<Txipermalink https://blog.johtani.info/blog/2013/07/11/yokozuna-check-point/xkpublishdate Y2013-07-11T01:43:00+09:00xgsummary!GYokozunaの気になる点というか、自分だったらこのへん調べるだろうなって観点を上げてみます。 別に調べるわけじゃないので、完全に自己満足なwdtags3xpdRiakdSolrhYokozunaxetitle XYokozunaの気になる点というかなんというかvc265:yddate7?lxcdirjpost/2013/xbid `146e8ca40c0d37f36eecea822028dd9exdlangbjayglastmod7?lxipermalink!@https://blog.johtani.info/blog/2013/07/10/riak-meetup-tokyo-no2/xkpublishdate Y2013-07-10T18:57:00+09:00xgsummary!T先日、Bashoさんにおじゃましたのもあり、Riak Meetup Tokyo #2に参加しました。 Yokozunaの話も聞けるということで。 懇親会も参加しました。wdtags3xpdRiakhYokozunadSolrxetitle cRiak Meetup Tokyo #2に参加しました。#riakjpvc266:yddate55Pxcdirjpost/2013/xbid `a98d42be181c01b8077e060b1b5080ecxdlangbjayglastmod55Pxipermalink }https://blog.johtani.info/blog/2013/07/04/schemaless-example/xkpublishdate Y2013-07-04T01:12:00+09:00xgsummary!KSolr 4.4に取り込まれる予定のチケットで、気になるものを見つけたのでいつものごとく調べてみました。 元となるチケットはこちら。SOLR-4897wdtags1xpdSolrxetitle ^スキーマレスモード？（SOLR-4897）を調べて見ました。vc267:yddate2>&@xcdirjpost/2013/xbid `ecf3ac80454654d990d9c07d33d35d1cxdlangbjayglastmod2>&@xipermalink!Ahttps://blog.johtani.info/blog/2013/06/27/upload-docs-solr-admin/xkpublishdate Y2013-06-27T16:28:00+09:00xgsummary!GSolrのチケットをML経由で眺めてるんですが、便利そうなチケットが流れてきたのでブログを書いてみみようかと。 元になってるチケットはこちらでwdtags1xpdSolrxetitleoSolrの管理画面でデータ登録vc268:yddate0
txcdirjpost/2013/xbid `26c47355cbe966a94826cbe2fbf2b355xdlangbjayglastmod0
txipermalink https://blog.johtani.info/blog/2013/06/19/introduction-kibana3/xkpublishdate Y2013-06-19T23:43:00+09:00xgsummary!G前回は3番煎じぐらいでしたが、今回は初記事かな？（だといいな） Kibanaには、前回の記事で書いたものとは別に開発中のKibana3というのwdtags2xpmelasticsearchfkibanaxetitle QKibana3というのもありましてvc269:yddate0
Dxcdirjpost/2013/xbid `33919e866426ce8e7b2ce06f19bbf889xdlangbjayglastmod0
Dxipermalink xhttps://blog.johtani.info/blog/2013/06/19/visited-basho/xkpublishdate Y2013-06-19T10:03:00+09:00xgsummary!Iちょくちょく書こうと言いながら、前の記事が1週間以上前になってる。。。 昨日は、Basho Japanに遊びに行って来ました。 （Riak触ったこwdtags4xpdRiakeBashohYokozunadSolrxetitle TBasho Japanに遊びに行きましたvc270:yddate-/txcdirjpost/2013/xbid `78292d953eafbdf9e57cc4bbbe6e8964xdlangbjayglastmod-/txipermalink whttps://blog.johtani.info/blog/2013/06/11/new-solr-xml/xkpublishdate Y2013-06-11T19:11:00+09:00xgsummary!SLucene/Solr 4.3.1のRCのVoteが始まっていますが、そのMLできになったコトがあり、ちょっと調べたので メモを残しておきます。 マルチコアの設定ファwdtags1xpdSolrxetitle V新しいsolr.xmlとCore探索ロジックvc271:yddate-Xxcdirjpost/2013/xbid `c4d3a917f623f58646ce93015d79e8e0xdlangbjayglastmod-Xxipermalink {https://blog.johtani.info/blog/2013/06/10/fluent-es-kibana/xkpublishdate Y2013-06-10T23:34:00+09:00xgsummary!Gもう何番煎じだ？ってくらい書かれてますが、コリもせず書いてみました。 Elasticsearch＋Kibanaの環境を作って、タムタムさんのロwdtags3xpfkibanamelasticsearchgfluentdxetitle yapache-loggen + fluentd + elasticsearch + kibana = ログ検索デモvc272:yddate,	`xcdirjpost/2013/xbid `d12c1c2a68be4c7fda5a7737d5493b4dxdlangbjayglastmod,	`xipermalink!@https://blog.johtani.info/blog/2013/06/06/aws-summit-tokyo-day2/xkpublishdate Y2013-06-06T23:00:00+09:00xgsummary!S昨日に引き続き、AWS Summit Tokyo 2013に行ってきました。 @ryu_kobayashiさんからパシリを仰せつかるなどあり、忙しかったのですが楽しかwdtags2xpcAWSc勉強会xetitle oAWS Summit Tokyo 2013に行って来ました。(Day2) #awssummitvc273:yddate,Hxcdirjpost/2013/xbid `f45069216cd934b80ce882c9a2f2a08axdlangbjayglastmod,Hxipermalink!@https://blog.johtani.info/blog/2013/06/06/cloudera-search-memo2/xkpublishdate Y2013-06-06T12:26:00+09:00xgsummary!HざっとインストールガイドとかCloudera Searchのソース眺めて、テキトーにメモを書いてみました。 （ユーザガイドはまだ読んでないです。wdtags3xpoCloudera SearchfHadoopdSolrxetitle VCloudera Searchメモ（妄想版）vc274:yddate+0Xxcdirjpost/2013/xbid `1fe14e2e02b6e65e6e6e2ae3d8ddcc9fxdlangbjayglastmod+0Xxipermalink!@https://blog.johtani.info/blog/2013/06/05/aws-summit-tokyo-day1/xkpublishdate Y2013-06-05T18:30:00+09:00xgsummary!VAWS Summit Tokyo 2013に行って来ました。 @cocoatomoさんに行き掛けに出会ったので、アンデルセンの講演を一緒に聞いてました。 TDブースの@rywdtags2xpc勉強会cAWSxetitle oAWS Summit Tokyo 2013に行って来ました。(Day1) #awssummitvc275:yddate+-pxcdirjpost/2013/xbid `e30258aeb8475d4c27f7935945671856xdlangbjayglastmod+-pxipermalink!Bhttps://blog.johtani.info/blog/2013/06/05/cloudera-search-modules/xkpublishdate Y2013-06-05T15:12:00+09:00xgsummary!PCloudera Searchは次のようなモジュールから構成されています。 これはCloudera Searchのモジュールで、さらにこれらがSolrとかを使っwdtags4xphClouderafHadoopdSolroCloudera Searchxetitle WCloudera Searchのモジュールたちvc276:yddate+-Lxcdirjpost/2013/xbid `cd90bce912f5743226af94c1efaaa4a7xdlangbjayglastmod+-Lxipermalink!Bhttps://blog.johtani.info/blog/2013/06/05/what-is-cloudera-search/xkpublishdate Y2013-06-05T15:05:00+09:00xgsummary!KAWS Summitに来ていたのですが、TLでは、Cloudera Searchが賑わってました。 ということで、軽くどんなものか読んだり調べたりしたwdtags4xphClouderafHadoopdSolroCloudera Searchxetitle cCloudera Searchってのが出たらしい（とりあえず、雑感？）vc277:yddate+
;Txcdirjpost/2013/xbid `494557db52824555864d1106278cd1f0xdlangbjayglastmod+
;Txipermalink!Ghttps://blog.johtani.info/blog/2013/06/03/fluent-plugin-zoomdata-0-0-1/xkpublishdate Y2013-06-03T13:43:00+09:00xgsummary!G憧れ？のfluentを使ってみました。 こちらの記事で紹介したZoomdataを最近触っているのですが、お試しにfluentdでデータ流し込むwdtags2xphZoomdatagfluentdxetitle afluent-plugin-zoomdata作りました＋悩み事とかvc278:yddate+Fxcdirjpost/2013/xbid `16f10764f0ccce42d5be8cfeac36b446xdlangbjayglastmod+Fxipermalink!Xhttps://blog.johtani.info/blog/2013/06/03/octopress%E3%82%92%E8%A9%A6%E3%81%97%E4%B8%AD/xkpublishdate Y2013-06-03T11:53:58+09:00xgsummary!G最近、Markdownで文章を書くのに慣れてきました。 ということで、ブログをMarkdownで書けないかなぁと思い、TLの人たちのブログを見wdtags1xpdmiscxetitle XOctopressを試し中(Jugemより移植)vc279:yddate* .|xcdirjpost/2013/xbid `dbcc4002c15afefef853a08a0804ba3axdlangbjayglastmod* .|xipermalink zhttps://blog.johtani.info/blog/2013/06/01/first-octopress/xkpublishdate Y2013-06-01T23:57:00+09:00xgsummary!G昨年から、ブログをどうしようかって話をしていて、そのままになっていたのですが、Octopress＋Github Pagesというのがあるらしいwdtags2xpioctopressdmiscxetitlenOctopress始めましたvc280:yddate!;5Txcdirjpost/2013/xbid `11d4726484be418849e1f4200ade9535xdlangbjayglastmod!;5Txipermalink$@https://blog.johtani.info/blog/2013/05/06/lucene-gosen4-3-0%E3%82%92%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Flucene-solr4-3-0%E4%BB%A5%E4%B8%8A%E3%81%A7%E3%81%AE%E5%88%A9%E7%94%A8%E3%81%8C%E5%8F%AF%E8%83%BD%E3%81%A7%E3%81%99/xkpublishdate Y2013-05-06T23:25:24+09:00xgsummary!RLucene/Solr 4.3.0がリリースされた（LuceneのChanges、SolrのChanges）ので、lucene-gosen 4.3.0をリリースしまwdtags1xpllucene-gosenxetitle!Clucene-gosen4.3.0をリリースしました。（Lucene/Solr4.3.0以上での利用が可能です）(Jugemより移植)vc281:yddate <3Kxcdirjpost/2013/xbid `db97311c24809f103575d8a7fee19680xdlangbjayglastmod <3Kxipermalink$^https://blog.johtani.info/blog/2013/05/03/%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E5%9B%9E%E3%81%97%E3%81%A6%E3%81%BE%E3%81%99%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF%E5%85%A5%E9%96%80%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2013-05-03T23:42:19+09:00xgsummary!Iアジャイルな時間管理術 ポモドーロテクニック入門 ポモドーロテクニック入門という本を読みました。 きっかけは、Twitter上で何度か「ポモドーロwdtags1xpb読書xetitle iポモドーロ回してます。（ポモドーロテクニック入門読みました）(Jugemより移植)vc282:yddate	hxcdirjpost/2013/xbid `286a9a4ee373398d7d2c93862c5f6661xdlangbjayglastmod	hxipermalink!zhttps://blog.johtani.info/blog/2013/04/25/solr4-3-0%E3%81%AEchanges%E3%82%92%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/xkpublishdate Y2013-04-25T11:14:00+09:00xgsummary!Iまだ、Vote公開されていない、Solr 4.3（2013/04/25 11:00現在）ですが、 ひさびさに訳してみた。詳細まで追っていないので、wdtags1xpdsolrxetitle cSolr4.3.0のChangesを訳してみた。(Jugemより移植)vc283:yddate8pxcdirjpost/2013/xbid `99f5219da22485d0872a2529599c8440xdlangbjayglastmod8pxipermalink$@https://blog.johtani.info/blog/2013/04/24/lucene-4-3-0%E3%81%AEchanges%E3%81%AB%E3%81%82%E3%82%8Bchanges-in-backwards-compatibility-policy%E3%81%8C%E6%B0%97%E3%81%AB%E3%81%AA%E3%81%A3%E3%81%9F%E3%81%AE%E3%81%A7%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/xkpublishdate Y2013-04-24T16:00:00+09:00xgsummary!H現在、RC3のVoteをやっている最中（2013/04/24 16:00時点）で、まだリリースされていない、4.3.0についてです。 開発者MLwdtags1xpdsolrxetitle!YLucene 4.3.0のChangesにあるChanges in backwards compatibility policyが気になったので訳してみた。(Jugemより移植)vc284:yddate'fxcdirjpost/2013/xbid `36ff37ced0d3211db95a5ac0daac0c35xdlangbjayglastmod'fxipermalink&ihttps://blog.johtani.info/blog/2013/04/23/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass--tecomp--vol-2-%E4%BA%BA%E6%B0%97web%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9%E6%95%99%E3%81%88%E3%81%BE%E3%81%99%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2013-04-23T20:45:42+09:00xgsummary!J第2回目も参加しました。 とりあえずメモ。 自分には欠けてる視点の話しなので面白かった。 ちょっと寒かったなぁ。 エンジニアのためのスキルアップ勉強wdtags1xpc勉強会xetitle!Xエンジニアのためのスキルアップ勉強会『Tech Compass』 #tecomp ― Vol.2 「人気Webサービスの作り方教えます！」に参加しました。(Jugemより移植)vc285:yddate`xcdirjpost/2013/xbid `1ca04e5339ed1826c12fe61fd984e949xdlangbjayglastmod`xipermalink"]https://blog.johtani.info/blog/2013/04/22/jira%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E3%82%92s3%E3%81%B8%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97/xkpublishdate Y2013-04-22T23:07:28+09:00xgsummary!Gだいぶ、ブログを書くペースが落ちてきてて、危機感を感じている今日このごろです。。。 今回は、個人的に利用しているJIRAのバックアップについてwdtags1xpc備忘録xetitle ]JIRAのデータをS3へバックアップ(Jugemより移植)vc286:yddate#{xcdirjpost/2013/xbid `73d2fce4efa52675b35a11ee97bc2db0xdlangbjayglastmod#{xipermalink"^https://blog.johtani.info/blog/2013/04/05/heroku-meetup--8-treasuredata--waza-report-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/xkpublishdate Y2013-04-05T11:20:43+09:00xgsummary!GHerokuではじめるRailsプログラミング入門 heroku気になってるのに使ってなくて、TDのアカウント作ってデータアップしてない軟弱者wdtags1xpc勉強会xetitle!JHeroku Meetup #8 TreasureData + Waza Report!! に参加しました。#herokujp(Jugemより移植)vc287:yddate@xcdirjpost/2013/xbid `26d0c0d8c465087cf160a3bdc479f2b4xdlangbjayglastmod@xipermalink"dhttps://blog.johtani.info/blog/2013/03/26/%E7%AC%AC10%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/xkpublishdate Y2013-03-26T21:16:00+09:00xgsummary!H記念すべき！？第10回のSolr勉強会です。 発表者が無事あつまり（本当にありがとうございました！）、今回も盛況な感じでほぼ満員でした。 ツイーwdtags1xpc勉強会xetitle e第10回Solr勉強会を主催しました。#SolrJP(Jugemより移植)vc288:yddate"Dxcdirjpost/2013/xbid `f5f28f42ad234b4389af4cbea54ff60dxdlangbjayglastmod"Dxipermalink"mhttps://blog.johtani.info/blog/2013/03/20/elasticsearch-analysis-kuromoji%E3%81%A7%E3%83%A6%E3%83%BC%E3%82%B6%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%88%A9%E7%94%A8%E6%96%B9%E6%B3%95/xkpublishdate Y2013-03-20T16:43:00+09:00xgsummary!Nなんか、とても久しぶりにイベント参加メモ以外の投稿です。 elastic searchのMLを見てたら、KuromojiのAnalyzerを使うときにユーザwdtags1xpmelasticsearchxetitle uelasticsearch-analysis-kuromojiでユーザ辞書の利用方法(Jugemより移植)vc289:yddate/@xcdirjpost/2013/xbid `5412fb82160d0f6093e4b6670f505c13xdlangbjayglastmod/@xipermalink'~https://blog.johtani.info/blog/2013/03/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass%E7%AB%B9%E6%A9%8B--vol1-%E3%82%B9%E3%83%9E%E3%83%9B%E6%99%82%E4%BB%A3%E5%88%B0%E6%9D%A5%E3%81%93%E3%81%AE%E5%85%88%E7%94%9F%E3%81%8D%E3%81%AE%E3%81%93%E3%82%8B%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%A8%E3%81%AF%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-tecomp/xkpublishdate Y2013-03-19T20:28:00+09:00xgsummary!H久々にブログ＋イベント参加です。 知り合いが開催＋出演したので参加してみました。 「スマホ」ってキーワードはあまりなかったけど、面白かったです。wdtags1xpc勉強会xetitle!`エンジニアのためのスキルアップ勉強会『Tech Compass』＠竹橋 ― Vol1 「スマホ時代到来、この先生きのこるエンジニアとは！？」に参加しました。#tecomp(Jugemより移植)vc290:yddate'
lxcdirjpost/2013/xbid `b051fd352847c06e748b345e8ed0738bxdlangbjayglastmod'
lxipermalink!`https://blog.johtani.info/blog/2013/02/13/xperia-z%E8%B2%B7%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2013-02-13T01:53:00+09:00xgsummary!P技術ブログから離れていってますが。。。 Xperia Zを購入しました。 前に使っていたのはXperia arcになります。 もうすぐ２年だったのですが、容量不wdtags1xpc備忘録xetitle XXperia Z買いました(Jugemより移植)vc291:yddate?hxcdirjpost/2013/xbid `bf4f86812812dab8d39db9aaefe94a78xdlangbjayglastmod?hxipermalink"Thttps://blog.johtani.info/blog/2013/01/22/hadoop-conference-japan-2013-winter%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hcj13w/xkpublishdate Y2013-01-22T00:50:00+09:00xgsummary!\金曜日に引き続き、イベントに参加して来ました。（仕事。。。これも仕事だよ。） 「Hadoop Conference Japan 2013 Winter」です。 普段、Hadoopを触るwdtags1xpc勉強会xetitle }Hadoop Conference Japan 2013 Winterに参加しました。#hcj13w(Jugemより移植)vc292:yddate>)+lxcdirjpost/2013/xbid `322264a17ef7182eb1475bd2eaebc2ebxdlangbjayglastmod>)+lxipermalink$ahttps://blog.johtani.info/blog/2013/01/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88cross-2013%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%8A%E6%89%8B%E4%BC%9D%E3%81%84%E3%83%A2%E3%83%87%E3%83%AC%E3%83%BC%E3%82%BF%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--cross2013/xkpublishdate Y2013-01-19T22:09:00+09:00xgsummary!G1/18（金）に開催された、エンジニアサポートCROSS 2013で「検索CROSS」セッションのセッションオーナー（モデレータ）をやって来まwdtags1xpc勉強会xetitle }エンジニアサポートCROSS 2013に参加（＋お手伝い＋モデレータ）しました #cross2013(Jugemより移植)vc293:yddate=Lxcdirjpost/2013/xbid `20110c8f8da8304b6d9d3c2845a38128xdlangbjayglastmod=Lxipermalink$Rhttps://blog.johtani.info/blog/2013/01/16/%E3%81%84%E3%81%BE%E3%81%95%E3%82%89%E3%81%A7%E3%81%99%E3%81%8Ccross-2013%E3%81%A7%E6%A4%9C%E7%B4%A2cross%E3%81%A8%E3%81%84%E3%81%86%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E6%8B%85%E5%BD%93%E3%81%97%E3%81%BE%E3%81%99/xkpublishdate Y2013-01-16T01:29:00+09:00xgsummary!Gいまさら感満載ですが、今週の金曜日(1/18)に開催されるCROSS 2013というイベントで「検索CROSS」のセッションを担当することになwdtags1xpc勉強会xetitle sいまさらですが、CROSS 2013で検索CROSSというセッションを担当します(Jugemより移植)vc294:yddate;,@xcdirjpost/2013/xbid `992a00c30242b6217243f3c387ea18b7xdlangbjayglastmod;,@xipermalink$xhttps://blog.johtani.info/blog/2013/01/09/%E3%82%B3%E3%83%BC%E3%83%89%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AA%E3%82%B7%E3%83%86%E3%82%A3%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9Fkindle-paperwhite%E3%81%AE%E4%BD%BF%E3%81%84%E5%8B%9D%E6%89%8B%E3%81%AE%E7%A2%BA%E8%AA%8D%E3%82%82%E5%85%BC%E3%81%AD%E3%81%A6/xkpublishdate Y2013-01-09T00:28:00+09:00xgsummary!H年末から年始にかけて、「コード・シンプリシティ」を読みました。 先日の記事にも書きましたが、Kindle paperwhiteを思いかけず入手でwdtags1xpb読書xetitle ~「コード・シンプリシティ」を読みました。（Kindle paperwhiteの使い勝手の確認も兼ねて）(Jugemより移植)vc295:yddate8lxcdirjpost/2012/xbid `4c08b67e0c1fdeef50b1fdcc32cdcee2xdlangbjayglastmod8lxipermalink"dhttps://blog.johtani.info/blog/2012/12/31/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A02012/xkpublishdate Y2012-12-31T08:01:00+09:00xgsummary!I書こうと思いながら、気づいたら大晦日。 よくないですね、思いついた時に書かないと。 昨年も書いたので、昨年書いた抱負から振り返りをと。 Mongowdtags1xpc備忘録xetitle ^今年の振り返りと来年の抱負（2012）(Jugemより移植)vc296:yddate4/hxcdirjpost/2012/xbid `4a30eeb083acec8460150068ba0c6743xdlangbjayglastmod4/hxipermalink!|https://blog.johtani.info/blog/2012/12/20/jira%E3%81%AEdb%E7%A7%BB%E8%A1%8Chsqldb%E3%81%8B%E3%82%89postgresql%E3%81%B8-augj/xkpublishdate Y2012-12-20T20:18:00+09:00xgsummary!_Atlassian Advent Calendar 2012の20日目。（急遽参戦） （某イケメンにMT（改変リツイート）されたので書いてみました） 久々に、勉強会以外のエントリです。（Sowdtags1xpdJIRAxetitle nJIRAのDB移行（HSQLDBからPostgreSQLへ）#augj(Jugemより移植)vc297:yddate12hxcdirjpost/2012/xbid `898d25a2ab9c0ba1fa9bad462405e475xdlangbjayglastmod12hxipermalink#qhttps://blog.johtani.info/blog/2012/12/11/%E7%AC%AC%E4%B8%80%E5%9B%9E-jetbrains%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97--jbugj-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-12-11T21:22:00+09:00xgsummary!Iイケメンが主催した「第一回 JetBrainsユーザーグループ #jbugj」に参加してきました。 いろんな製品があるんだなぁと。入り口には良いイwdtags1xpc勉強会xetitle q第一回 JetBrainsユーザーグループ #jbugj に参加してきました(Jugemより移植)vc298:yddate-$Pxcdirjpost/2012/xbid `e01e01d18582c7f69e1b0db7e1b111a0xdlangbjayglastmod-$Pxipermalink#ohttps://blog.johtani.info/blog/2012/11/29/dsirnlp-3-5%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Femacs%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80%E3%82%92%E9%A0%82%E3%81%84%E3%81%A1%E3%82%83%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-11-29T02:00:00+09:00xgsummary!Hヒカリエに行ってみたいという不純な理由で参加してきました。 新しいということもあり、おしゃれで綺麗なカフェでした。 入り口にはおっきな人形も立っwdtags1xpc勉強会xetitle u#DSIRNLP 3.5に参加しました。＆「Emacs実践入門」を頂いちゃいました！(Jugemより移植)vc299:yddate,3'`xcdirjpost/2012/xbid `7e23419e4fc69b5b533815681c9bb1a9xdlangbjayglastmod,3'`xipermalink"chttps://blog.johtani.info/blog/2012/11/26/%E7%AC%AC9%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/xkpublishdate Y2012-11-26T18:44:00+09:00xgsummary!H第9回Solr勉強会に参加しました。 皆勤賞です！というか、主催者になってしまいました。 まだ不定期の開催になると思いますが、話をされたい方などwdtags1xpc勉強会xetitle d第9回Solr勉強会を主催しました。#SolrJP(Jugemより移植)vc300:yddate'(dxcdirjpost/2012/xbid `98c640616f997a323af625e34ba34850xdlangbjayglastmod'(dxipermalink#shttps://blog.johtani.info/blog/2012/11/10/aws-%E3%83%93%E3%83%83%E3%82%B0%E3%83%87%E3%83%BC%E3%82%BF%E6%B4%BB%E7%94%A8%E4%BA%8B%E4%BE%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-jawsug/xkpublishdate Y2012-11-10T01:07:00+09:00xgsummary!G初目黒（たぶん）で、初Amazonな感じで、流行りの「ビッグデータ」のセミナーに参加してきました。 とりあえず、いつもの自分用のメモを残しておwdtags1xpc勉強会xetitle lAWS ビッグデータ活用事例セミナーに参加しました。#jawsug(Jugemより移植)vc301:yddate="Lxcdirjpost/2012/xbid `922cc71fd28b1dac8f407f1d517f5595xdlangbjayglastmod="Lxipermalink"Jhttps://blog.johtani.info/blog/2012/10/12/lucene-solr-4-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9lucene-gosen%E3%81%AE4-0%E5%AF%BE%E5%BF%9C/xkpublishdate Y2012-10-12T17:45:00+09:00xgsummary!U##Lucene/Solr 4.0.0リリース ついに、Lucene/Solr4.0.0がリリースされました。 MLで流れていましたが、3年越しのリリースだったようです。wdtags1xpllucene-gosenxetitle sLucene/Solr 4.0.0リリース＆lucene-gosenの4.0対応(Jugemより移植)vc302:yddate,|xcdirjpost/2012/xbid `43501cdf0de25278a208cbb9aad80012xdlangbjayglastmod,|xipermalink"}https://blog.johtani.info/blog/2012/09/26/lucid%E3%81%AEgrant-ingersoll%E3%81%95%E3%82%93%E3%81%AE%E8%AC%9B%E6%BC%94%E3%82%92%E8%81%9E%E3%81%84%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-09-26T18:08:12+09:00xgsummary!Gこのイベントにウチダスペクトラムの枠でMahoutのコミッターである、Grant Ingersollさんが講演されるということで、興味があったwdtags1xpc勉強会xetitle mLucidのGrant Ingersollさんの講演を聞いてきました(Jugemより移植)vc303:yddate
>lxcdirjpost/2012/xbid `89abaa7f21cf788ce4744e3e61173291xdlangbjayglastmod
>lxipermalink#Xhttps://blog.johtani.info/blog/2012/09/21/pfi%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC2012%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pfiopen2012/xkpublishdate Y2012-09-21T17:05:00+09:00xgsummary!GPFIオープンセミナー2012に参加してきました。 対象から微妙に外れてたり、話の内容についていけるか自信がありませんでしたが、参加してきましwdtags1xpc勉強会xetitle qPFIオープンセミナー2012に参加してきました。 #pfiopen2012(Jugemより移植)vc304:yddateHxcdirjpost/2012/xbid `7604edf307a5e96120606c8dda06458fxdlangbjayglastmodHxipermalink#]https://blog.johtani.info/blog/2012/09/03/%E3%83%A1%E3%82%A4%E3%83%B3mba%E3%82%92mountain-lion%E3%81%AB%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88%E3%81%84%E3%82%8D%E3%81%84%E3%82%8D%E7%A2%BA%E8%AA%8D%E4%B8%AD/xkpublishdate Y2012-09-03T14:34:00+09:00xgsummary!H友人にお値打価格で購入したMac miniはMountain Lionにアップデートしてたのですが、手元のAirはまだアップデートしていませんでwdtags1xpc備忘録xetitle oメインMBAをMountain Lionにアップデート（いろいろ確認中）(Jugemより移植)vc305:yddate
%pxcdirjpost/2012/xbid `775894425f5a7436f56fc5a3b4a2cfaaxdlangbjayglastmod
%pxipermalink"Nhttps://blog.johtani.info/blog/2012/08/23/fluentd-meetup-in-japan--2--fluentd-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-08-23T02:40:00+09:00xgsummary!G興味をもちつつ、触っていない軟弱者ですが、興味があるので今回も話を聞きに行って来ました。 まずは、作者古橋さんによるFluentdの魅力や次期wdtags1xpc勉強会xetitle wFluentd meetup in Japan #2 #fluentd に参加しました。(Jugemより移植)vc306:yddate+Xxcdirjpost/2012/xbid `8a29f62d1bebfe7b8008d7f264b56b4exdlangbjayglastmod+Xxipermalink"Yhttps://blog.johtani.info/blog/2012/08/02/twitter-%E5%8B%89%E5%BC%B7%E4%BC%9A--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-08-02T11:50:00+09:00xgsummary!Gまたまた飲みに行って参加してきました。 今回は、Rails、iOSでのTwitter連携の話から、ツイート分析、クライアントアプリの開発の苦労wdtags1xpc勉強会xetitle jTwitter 勉強会 #twtr_hack に参加しました。(Jugemより移植)vc307:yddate:6Txcdirjpost/2012/xbid `7fa2f0877831b4c924438396760f1841xdlangbjayglastmod:6Txipermalink#Ohttps://blog.johtani.info/blog/2012/07/28/python-developers-festa-2012-07%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%97%E3%82%83%E3%81%B9%E3%81%A3%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pyfes/xkpublishdate Y2012-07-28T18:15:00+09:00xgsummary!Gということで、ステッカー欲しさ？に勉強中の話を恥ずかしげもなく偉そうにしゃべってきました。 #pyfesは以前から、気になっていたんですが、タwdtags1xpc勉強会xetitle Python Developers Festa 2012.07に参加してしゃべってきました #pyfes(Jugemより移植)vc308:yddatehxcdirjpost/2012/xbid `68a8f34c240a42ab521d2f885f7aa33cxdlangbjayglastmodhxipermalink!thttps://blog.johtani.info/blog/2012/07/13/partial-update%E3%81%A8copyfield%E3%81%AE%E3%83%90%E3%82%B0solr-4-0-alpha/xkpublishdate Y2012-07-13T20:02:00+09:00xgsummary!a今日はSolr 4.0 ALPHAの興味深い機能があったので紹介です。 数日前に「Solr 4.0: Partial documents update」という記事を見つけました。 Solrには、wdtags1xpdsolrxetitle vPartial UpdateとcopyFieldのバグ【Solr 4.0 ALPHA】(Jugemより移植)vc309:yddate?/9Bxcdirjpost/2012/xbid `9ac7bb94e60dc30a023ce433de027364xdlangbjayglastmod?/9Bxipermalink!vhttps://blog.johtani.info/blog/2012/07/13/mir%E8%BC%AA%E8%AA%AD%E4%BC%9A%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-07-13T01:41:38+09:00xgsummary"~Modern Information Retrieval: The Concepts and Technology behind Search (2nd Edition) (ACM Press Books) いやぁ、蒸し暑くてなかなか寝れない日がはじまりましたね。（あんまり関係ないですね。。。） Modern Information Retrieval 2nd Editionをwdtags1xpc勉強会xetitle VMIR輪読会始めました(Jugemより移植)vc310:yddate=uxcdirjpost/2012/xbid `dcc2e24df32287e89ee3b0f64d617f57xdlangbjayglastmod=uxipermalink!fhttps://blog.johtani.info/blog/2012/07/05/lucene-gosen%E3%81%AElucene-solr4-0-alpha%E5%AF%BE%E5%BF%9C/xkpublishdate Y2012-07-05T12:11:49+09:00xgsummary!GLucene/Solrの4.0.0-ALPHAが7/3にリリースされました。 これに伴い、lucene-goenの4xブランチのjarファイルwdtags1xpllucene-gosenxetitle nlucene-gosenのLucene/Solr4.0-ALPHA対応(Jugemより移植)vc311:yddate=.Pxcdirjpost/2012/xbid `8acc78be63e27e938ee53ec2c0b90c61xdlangbjayglastmod=.Pxipermalink"dhttps://blog.johtani.info/blog/2012/07/04/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--solrjp/xkpublishdate Y2012-07-04T20:40:00+09:00xgsummary!Jまたまた参加しました。いまだ皆勤賞です。 感想などはあとで。とりあえず、メモとったので第一弾です。 ということで、感想です。 まずは、参加人数。 今wdtags1xpc勉強会xetitle eSolr勉強会第8回に参加しました。 #SolrJP(Jugemより移植)vc3129yddate:	\xcdirjpost/2012/xbid `9f29c6d9719fc6bc09a2981057642b69xdlangbjayglastmod:	\xipermalink#~https://blog.johtani.info/blog/2012/06/26/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC10%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/xkpublishdate Y2012-06-26T01:41:00+09:00xgsummary!SHadoopからはちょっと離れているのに、面白そうなネタなので参加しました。 Data Science Summit、HBaseCon、Hadoop Summitのイxetitle wHadoopソースコードリーディング第10回に参加しました。#hadoopreading(Jugemより移植)vc313:yddate73Txcdirjpost/2012/xbid `d13aa56e27fe71ef40ff153c093ecdf8xdlangbjayglastmod73Txipermalink!Xhttps://blog.johtani.info/blog/2012/06/18/lucene-gosen%E3%81%AEunidic%E5%AF%BE%E5%BF%9C/xkpublishdate Y2012-06-18T23:03:00+09:00xgsummary!LIssue 32で上がってきたlucee-gosenのUniDic対応の最初のパッチを書いたので、ブログに残しておきます。 ###UniDicとは___wdtags1xpllucene-gosenxetitle `lucene-gosenのUniDic対応(Jugemより移植)vc314:yddate649hxcdirjpost/2012/xbid `9ccda414c322ebcdf875eacbba2e4b7exdlangbjayglastmod649hxipermalink"Qhttps://blog.johtani.info/blog/2012/06/16/zipkin%E3%81%AEreadme%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%81%9D%E3%81%AE%EF%BC%92%E6%AE%8B%E3%82%8A/xkpublishdate Y2012-06-16T00:02:00+09:00xgsummary!H「鉄は熱いうちに打て」ということで、残りも勢いでメモ。 まだ、見直しとかしてない状態なのでおかしいところとかありますが。。。 図とか入れるのはまwdtags1xpfZipkinxetitle dZipkinのReadme読んでる（その２、残り）(Jugemより移植)vc315:yddate6(!\xcdirjpost/2012/xbid `69f755dd5b9e90a99c3086543790541cxdlangbjayglastmod6(!\xipermalink#Yhttps://blog.johtani.info/blog/2012/06/15/zipkin%E3%81%AEreadme%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E5%91%A8%E3%82%8A%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/xkpublishdate Y2012-06-15T09:57:00+09:00xgsummary!HZipkinのGithubにあるReadmeを読んでます。 せっかくというか、頭が悪いので読みながら内容をメモ。 まずは、アーキテクチャとトレーwdtags1xpfZipkinxetitle kZipkinのReadmeを読んでる（クライアント周りについて）(Jugemより移植)vc316:yddate6,\xcdirjpost/2012/xbid `277f7f2177e2a265a62680ea0158f9b9xdlangbjayglastmod6,\xipermalink"ghttps://blog.johtani.info/blog/2012/06/14/autogeneratephrasequeries%E3%81%AE%E3%83%87%E3%83%95%E3%82%A9%E3%83%AB%E3%83%88%E5%80%A4%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/xkpublishdate Y2012-06-14T01:09:00+09:00xgsummary!H久々にSolrの話です。 といっても、結構前からの話でして。。。 schema.xmlのfieldTypeの設定に「autoGeneratePhwdtags1xpdsolrxetitle oautoGeneratePhraseQueriesのデフォルト値について(Jugemより移植)vc317:yddate56Pxcdirjpost/2012/xbid `ee48516e57684c5a4c22adccac34be92xdlangbjayglastmod56Pxipermalink#chttps://blog.johtani.info/blog/2012/06/13/twitter%E3%81%8C%E5%85%AC%E9%96%8B%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%B3%E3%82%B0%E8%BF%BD%E8%B7%A1%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0zipkin/xkpublishdate Y2012-06-13T00:40:00+09:00xgsummary!Gすでに読まれた方もいるかも知れませんが、気になったのでメモを書いてみようかと。 先週の木曜日にTwitterのエンジニアブログでZipkinとwdtags1xpcOSSxetitle oTwitterが公開した分散トレーシング（追跡？）システム、Zipkin(Jugemより移植)vc318:yddate40bxcdirjpost/2012/xbid `216db319052b5742fc68862cb2f39905xdlangbjayglastmod40bxipermalink#Dhttps://blog.johtani.info/blog/2012/06/07/lucene-gosen-2-0-2%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E5%91%A8%E3%82%8A%E3%81%AE%E6%94%B9%E5%96%84%E3%81%AA%E3%81%A9/xkpublishdate Y2012-06-07T17:53:54+09:00xgsummary!Hlucene-gosenの最新版（2.0.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、@haruywdtags1xpllucene-gosenxetitle nlucene-gosen 2.0.2リリース（リソース周りの改善など）(Jugemより移植)vc319:yddate3#lxcdirjpost/2012/xbid `cbf9587a8187985725963b8bfc67004dxdlangbjayglastmod3#lxipermalink!lhttps://blog.johtani.info/blog/2012/06/06/issue32%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A64096%E3%81%AE%E5%A3%81/xkpublishdate Y2012-06-06T01:21:00+09:00xgsummary!G昨晩に引き続き、情けない内容のブログになってしまいますが。。。 昨晩、書いた記事の調査をしていた時に気づいた、問題になるケースがあったので調査wdtags1xpllucene-gosenxetitle ^Issue32について（4096の壁）(Jugemより移植)vc320:yddate3	Lxcdirjpost/2012/xbid `0dcb6d0f17794bbca56b6cdb9e20b932xdlangbjayglastmod3	Lxipermalink$ahttps://blog.johtani.info/blog/2012/06/05/trunk%E3%81%AE%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E5%B7%AE%E3%81%97%E6%9B%BF%E3%81%88lucene-solr3-6-0%E3%81%A8%E3%83%A9%E3%83%B3%E3%83%80%E3%83%A0%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E5%A4%B1%E6%95%97%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/xkpublishdate Y2012-06-05T01:29:00+09:00xgsummary!G久々にlucene-gosenを触っています。 trunkのlibにある、jarファイルが3.5ベースだったので、3.6ベースにしてテストをしwdtags1xpllucene-gosenxetitle {trunkのライブラリ差し替え（Lucene/Solr3.6.0）とランダムテストの失敗について(Jugemより移植)vc321:yddate1$Pxcdirjpost/2012/xbid `ffdbd6a7d28c9a63976e9eec38cab0f5xdlangbjayglastmod1$Pxipermalink"rhttps://blog.johtani.info/blog/2012/05/31/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%B8%E3%81%AE%E8%B2%A2%E7%8C%AE%E3%81%AE%E3%82%B9%E3%82%B9%E3%83%A1/xkpublishdate Y2012-05-31T01:12:00+09:00xgsummary!H録画してたEテレのスーパープレゼンテーションを見ててふと書きたくなったので、書いてます。 あとから読んだら恥ずかしくなりそうだけど。。。 「&lwdtags1xpdmiscxetitle Zオープンソースへの貢献のススメ(Jugemより移植)vc322:yddate1 lxcdirjpost/2012/xbid `de734259dfb9addebe2b226d96b4f744xdlangbjayglastmod1 lxipermalink"Phttps://blog.johtani.info/blog/2012/05/29/jjug-ccc-2012-spring%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-05-29T11:45:00+09:00xgsummary!TJJUG CCC 2012 Springに参加してきました。 昨年のFallに続き、2回目です。 概要や、タイムテーブルはこちらを御覧ください。 今回は、午後一から参加wdtags1xpc勉強会xetitle iJJUG CCC 2012 Springに参加してきました。(Jugemより移植)vc323:yddate,4=Rxcdirjpost/2012/xbid `78f002cc3d512ea302c900d1da4dfeecxdlangbjayglastmod,4=Rxipermalink"Shttps://blog.johtani.info/blog/2012/05/16/playframework-2-0-java%E3%81%AE%E6%96%B9-%E3%82%92%E8%A7%A6%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%A6%E3%82%8B/xkpublishdate Y2012-05-16T15:55:14+09:00xgsummary!HPlayFramework2.0を触ってみてます。 ちょっとコーディングしたくなったのと、最近のアプリの作成の調査も兼ねて。 まぁ、せっかくなのwdtags1xpc備忘録xetitle kPlayFramework 2.0(Javaの方)を触ってみてる(Jugemより移植)vc324:yddate*,txcdirjpost/2012/xbid `c4b418764dca70aebfc965899a3fa7e5xdlangbjayglastmod*,txipermalink!xhttps://blog.johtani.info/blog/2012/05/09/lucene-gosen-2-0-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9java7%E5%AF%BE%E5%BF%9C/xkpublishdate Y2012-05-09T01:35:00+09:00xgsummary!Hlucene-gosenの最新版（2.0.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、Java7でwdtags1xpllucene-gosenxetitle jlucene-gosen 2.0.1リリース（Java7対応）(Jugemより移植)vc325:yddate')/Kxcdirjpost/2012/xbid `95c0a5b8a66950b5f22dd82a8dfe0ce5xdlangbjayglastmod')/Kxipermalink!~https://blog.johtani.info/blog/2012/04/30/id%E3%81%AE%E7%A7%98%E5%AF%86%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-04-30T23:03:55+09:00xgsummary!IIDの秘密 (丸善ライブラリー―情報研シリーズ) 非常に面白く読めました。 バーコードの話に始まり、最後はシステムで付与するIDに関する考慮点までwdtags1xpb読書xetitle Y「IDの秘密」を読みました。(Jugemより移植)vc326:yddate$=Txcdirjpost/2012/xbid `c92c12a28fa219ad1aab60865046ff05xdlangbjayglastmod$=Txipermalink"Ehttps://blog.johtani.info/blog/2012/04/21/heroku-jp-meetup-4%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/xkpublishdate Y2012-04-21T00:23:00+09:00xgsummary!JWebSolrの話があるらしいというのを嗅ぎつけて、初めてHeroku JP Meetupに参加しました。 herokuもWebSolrも知りつつ、wdtags1xpc勉強会xetitle oHeroku JP Meetup ＃4に参加しました。#herokujp(Jugemより移植)vc327:yddate#Kxcdirjpost/2012/xbid `12d1e0cf7396dd33a9bbbca8da4cbc68xdlangbjayglastmod#Kxipermalink"ohttps://blog.johtani.info/blog/2012/04/17/solr-3-6-0%E3%81%AEcjk%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%81%A8synonymfilterfactory%E3%81%AE%E6%B0%97%E3%81%AB%E3%81%AA%E3%82%8B%E7%82%B9/xkpublishdate Y2012-04-17T01:16:11+09:00xgsummary!H先日、Solr入門のサンプルschema.xmlの3.6.0対応版の作成をしていて、気になったことがあったので、 メモとして残しておきます。 Swdtags1xpdsolrxetitle wSolr 3.6.0のCJKの設定とSynonymFilterFactoryの気になる点(Jugemより移植)vc328:yddate"$hxcdirjpost/2012/xbid `d77cdb466c5063b99c5aea58e6da4d32xdlangbjayglastmod"$hxipermalink#Ahttps://blog.johtani.info/blog/2012/04/14/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C2%E7%AB%A04%E7%AB%A0/xkpublishdate Y2012-04-14T02:58:00+09:00xgsummary!H先日の続きです。「Apache Solr入門」の2章から4章の説明について、Solr3.6.0で動作させる時の変更点を以下に書いていきます。 なwdtags1xpdsolrxetitle ~「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（2章～4章）(Jugemより移植)vc329:yddate"\xcdirjpost/2012/xbid `904b07170a0ce481b7491e7fecce4f79xdlangbjayglastmod"\xipermalink#ohttps://blog.johtani.info/blog/2012/04/14/lucene-solr-3-6-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9---apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0/xkpublishdate Y2012-04-14T02:45:00+09:00xgsummary!H以前より、アナウンスしていた、Kuromojiという日本語形態素解析が含まれるLucene/Solr 3.6.0がリリースされました。 以下、各wdtags1xpdsolrxetitle!SLucene/Solr 3.6.0リリース / 「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（1章）(Jugemより移植)vc330:yddate!.mxcdirjpost/2012/xbid `bed3b7fcc1294e23639057435ac8756axdlangbjayglastmod!.mxipermalink"Whttps://blog.johtani.info/blog/2012/04/12/%E3%83%A1%E3%83%A2amazon-cloudsearch%E3%81%8C%E5%87%BA%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F%E3%82%88/xkpublishdate Y2012-04-12T23:31:09+09:00xgsummary!HTwitterでこのブログ流れてきて、気になったので、流し読みして簡単にメモ。 Amazonのサービスでスケールする検索サービスみたい。 主に、wdtags1xpc備忘録xetitle i【メモ】Amazon CloudSearchが出てきましたよ(Jugemより移植)vc331:yddate*
dxcdirjpost/2012/xbid `56d5711303378bd333ddb611a53ece94xdlangbjayglastmod*
dxipermalink"Hhttps://blog.johtani.info/blog/2012/04/06/java-one-tokyo-2012-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-javaonejp/xkpublishdate Y2012-04-06T16:51:00+09:00xgsummary!TJavaOne Tokyo 2012に参加してきました。 4/4-4/5の2日間開催されていたのですが、子供が体調を崩してしまい、4/5のみの参加となりました。 4/4wdtags1xpc勉強会xetitle qJava One Tokyo 2012 に参加しました。#JavaOneJp(Jugemより移植)vc332:yddate`xcdirjpost/2012/xbid `c7937b6b4bde2a96191dc31db913e1abxdlangbjayglastmod`xipermalink"qhttps://blog.johtani.info/blog/2012/04/05/lucene-gosen%E3%81%AEjava7%E3%81%A7%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E5%A4%B1%E6%95%97%E5%95%8F%E9%A1%8C%E3%81%AE%E5%AF%BE%E5%BF%9C/xkpublishdate Y2012-04-05T00:20:00+09:00xgsummary!G先日、2.0.0リリースの記事にも記載しましたが、Java7でテストケースが失敗する問題がありました。 @haruyamaさんと@hideakwdtags1xpllucene-gosenxetitle ilucene-gosenのJava7でのテスト失敗問題の対応(Jugemより移植)vc333:yddate7Hxcdirjpost/2012/xbid `06731164684f90f33ce4017eca9d8ec1xdlangbjayglastmod7Hxipermalink!shttps://blog.johtani.info/blog/2012/04/02/%E9%87%8D%E8%A6%81lucene-gosen-2-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/xkpublishdate Y2012-04-02T19:22:00+09:00xgsummary!R先日、宣言したとおり、lucene-gosenのパッケージ名＋クラス名の変更を行ったlucene-gosen 2.0.0をリリースしました。 Lucene/Solrwdtags1xpllucene-gosenxetitle e【重要】lucene-gosen 2.0.0リリース(Jugemより移植)vc334:yddate
+)xxipermalink!Chttps://blog.johtani.info/blog/2013/09/12/question-river-wikipedia/xkpublishdate Y2013-09-12T02:38:00+09:00xgsummary!Friver-wikipediaの前々回の記事で書きましたが、bulk_sizeに関連して登録件数がやけにきりが良いのが気になると書いていましwdtags2xpmelasticsearchiwikipediaxetitle aelasticsearch-river-wikipediaの疑問点vc257:yddate	&Dxcdirjpost/2013/xbid `79e647a3f8b36a1221897f5837c84affxdlangbjayglastmod	&Dxipermalink!Ehttps://blog.johtani.info/blog/2013/09/03/ja-wikipedia-with-kuromoji/xkpublishdate Y2013-09-03T01:15:00+09:00xgsummary!G前々回紹介した、日本語Wikipediaのデータをインデックス登録する記事の続きです。 今回は、Kuromojiのアナライザを利用してインデッwdtags3xpmelasticsearchhkuromojiiwikipediaxetitle c日本語Wikipediaをインデクシング（Kuromojiバージョン）vc258:yddate8hxcdirjpost/2013/xbid `5931f8e3acdac724742c4ee0960d8d40xdlangbjayglastmod8hxipermalink!Shttps://blog.johtani.info/blog/2013/08/30/hold-first-elasticsearch-meetup-in-japan/xkpublishdate Y2013-08-30T02:42:00+09:00xgsummary!IElasticSearch勉強会 第1回を主催しました。 昨年のpyfesでなんちゃって資料で喋って、1年たちました。 ElasticSearchwdtags2xpmelasticsearchc勉強会xetitle l第1回ElasticSearch勉強会を開催しました！ #elasticsearchjpvc259:yddate-hxcdirjpost/2013/xbid `3931327ed463d1568868c5ab8e839148xdlangbjayglastmod-hxipermalink!Nhttps://blog.johtani.info/blog/2013/08/23/index-wikipedia-ja-to-elasticsearch/xkpublishdate Y2013-08-23T12:02:00+09:00xgsummary!G久々のブログはElasticSearchネタです。勉強会開催する予定だったりすので、もう少し触っておきたいなと。 お手軽に検索するデータとしてwdtags2xpmelasticsearchiwikipediaxetitle kElasticSearchにプラグインで日本語Wikipediaデータを入れてみましたvc260:yddate>7Hxcdirjpost/2013/xbid `33e01e2271be22b5ed330045fe6aff50xdlangbjayglastmod>7Hxipermalink ~https://blog.johtani.info/blog/2013/08/02/morphlines-loadsolr/xkpublishdate Y2013-08-02T18:02:00+09:00xgsummary!H宿題その2？かな。Solr勉強会でCloudera Searchのスキーマ周りってどうなってるの？という質問が出てて、 なんか調べることになってwdtags3xpoCloudera SearchjMorphlinesdSolrxetitle _MorphlinesのloadSolrをちょっとだけ調べてみたvc261:yddate>&xxcdirjpost/2013/xbid `cd9ba1f582642d9cbe500f018afab341xdlangbjayglastmod>&xxipermalink {https://blog.johtani.info/blog/2013/08/01/replace-xperia-z/xkpublishdate Y2013-08-01T22:38:00+09:00xgsummary!H今朝起きたら、Xperia Zが故障してしまいました。 電源ボタンを押してもスリープにならないんです。しかも、スリープからの復帰もできない。。。wdtags1xphXperia Zxetitle WXperia Zが故障したので交換したのでメモvc262:yddate>pxcdirjpost/2013/xbid `b875f24d3d444fdda82b6bbfb75a4c92xdlangbjayglastmod>pxipermalink!Bhttps://blog.johtani.info/blog/2013/07/31/introduction-morphlines/xkpublishdate Y2013-07-31T19:12:00+09:00xgsummary!HMorphlinesについてちょっとだけ、さらに調べました。 誤解 Solr勉強会でなんとなく私の認識を話しましたが、ちょっと誤解してたみたいでwdtags3xpoCloudera SearchjMorphlinesdSolrxetitlemMorphlines入門？vc263:yddate='#dxcdirjpost/2013/xbid `59d1b7206e7664e76672d3de4dc9a8edxdlangbjayglastmod='#dxipermalink xhttps://blog.johtani.info/blog/2013/07/29/study-of-solr/xkpublishdate Y2013-07-29T23:15:00+09:00xgsummary!G不定期開催ですが第11回Solr勉強会を主催しました。 今回も大入り90人くらい？の参加者の皆さんがいらっしゃいました。ありがたいことです！（wdtags3xpdSolroCloudera SearchjManifoldCFxetitle Z第11回Solr勉強会を主催しました。#SolrJPvc264:yddate<*dxcdirjpost/2013/xbid `1b9c5ae60ec46be64a1877f0c6920edcxdlangbjayglastmod<*dxipermalink!Hhttps://blog.johtani.info/blog/2013/07/25/hadoop-hive-publication-party/xkpublishdate Y2013-07-25T02:11:00+09:00xgsummary!HHadoopとか離れちゃってるし、Hive触ったこと無いにもかかわらず参加しました！ （たまたま近くにいるからって理由なのは内緒で） 玉川さんのwdtags4xpfHadoopdHivehClouderaeオライリーxetitle x『プログラミング Hive』 『Hadoop 第3版』刊行記念セミナーに参加しました！ #oreilly0724vc265:yddate7<Txcdirjpost/2013/xbid `50557b455cba1a3ce9b4555fc3fd5433xdlangbjayglastmod7<Txipermalink https://blog.johtani.info/blog/2013/07/11/yokozuna-check-point/xkpublishdate Y2013-07-11T01:43:00+09:00xgsummary!GYokozunaの気になる点というか、自分だったらこのへん調べるだろうなって観点を上げてみます。 別に調べるわけじゃないので、完全に自己満足なwdtags3xpdRiakdSolrhYokozunaxetitle XYokozunaの気になる点というかなんというかvc266:yddate7?lxcdirjpost/2013/xbid `146e8ca40c0d37f36eecea822028dd9exdlangbjayglastmod7?lxipermalink!@https://blog.johtani.info/blog/2013/07/10/riak-meetup-tokyo-no2/xkpublishdate Y2013-07-10T18:57:00+09:00xgsummary!T先日、Bashoさんにおじゃましたのもあり、Riak Meetup Tokyo #2に参加しました。 Yokozunaの話も聞けるということで。 懇親会も参加しました。wdtags3xpdRiakhYokozunadSolrxetitle cRiak Meetup Tokyo #2に参加しました。#riakjpvc267:yddate55Pxcdirjpost/2013/xbid `a98d42be181c01b8077e060b1b5080ecxdlangbjayglastmod55Pxipermalink }https://blog.johtani.info/blog/2013/07/04/schemaless-example/xkpublishdate Y2013-07-04T01:12:00+09:00xgsummary!KSolr 4.4に取り込まれる予定のチケットで、気になるものを見つけたのでいつものごとく調べてみました。 元となるチケットはこちら。SOLR-4897wdtags1xpdSolrxetitle ^スキーマレスモード？（SOLR-4897）を調べて見ました。vc268:yddate2>&@xcdirjpost/2013/xbid `ecf3ac80454654d990d9c07d33d35d1cxdlangbjayglastmod2>&@xipermalink!Ahttps://blog.johtani.info/blog/2013/06/27/upload-docs-solr-admin/xkpublishdate Y2013-06-27T16:28:00+09:00xgsummary!GSolrのチケットをML経由で眺めてるんですが、便利そうなチケットが流れてきたのでブログを書いてみみようかと。 元になってるチケットはこちらでwdtags1xpdSolrxetitleoSolrの管理画面でデータ登録vc269:yddate0
txcdirjpost/2013/xbid `26c47355cbe966a94826cbe2fbf2b355xdlangbjayglastmod0
txipermalink https://blog.johtani.info/blog/2013/06/19/introduction-kibana3/xkpublishdate Y2013-06-19T23:43:00+09:00xgsummary!G前回は3番煎じぐらいでしたが、今回は初記事かな？（だといいな） Kibanaには、前回の記事で書いたものとは別に開発中のKibana3というのwdtags2xpmelasticsearchfkibanaxetitle QKibana3というのもありましてvc270:yddate0
Dxcdirjpost/2013/xbid `33919e866426ce8e7b2ce06f19bbf889xdlangbjayglastmod0
Dxipermalink xhttps://blog.johtani.info/blog/2013/06/19/visited-basho/xkpublishdate Y2013-06-19T10:03:00+09:00xgsummary!Iちょくちょく書こうと言いながら、前の記事が1週間以上前になってる。。。 昨日は、Basho Japanに遊びに行って来ました。 （Riak触ったこwdtags4xpdRiakeBashohYokozunadSolrxetitle TBasho Japanに遊びに行きましたvc271:yddate-/txcdirjpost/2013/xbid `78292d953eafbdf9e57cc4bbbe6e8964xdlangbjayglastmod-/txipermalink whttps://blog.johtani.info/blog/2013/06/11/new-solr-xml/xkpublishdate Y2013-06-11T19:11:00+09:00xgsummary!SLucene/Solr 4.3.1のRCのVoteが始まっていますが、そのMLできになったコトがあり、ちょっと調べたので メモを残しておきます。 マルチコアの設定ファwdtags1xpdSolrxetitle V新しいsolr.xmlとCore探索ロジックvc272:yddate-Xxcdirjpost/2013/xbid `c4d3a917f623f58646ce93015d79e8e0xdlangbjayglastmod-Xxipermalink {https://blog.johtani.info/blog/2013/06/10/fluent-es-kibana/xkpublishdate Y2013-06-10T23:34:00+09:00xgsummary!Gもう何番煎じだ？ってくらい書かれてますが、コリもせず書いてみました。 Elasticsearch＋Kibanaの環境を作って、タムタムさんのロwdtags3xpfkibanamelasticsearchgfluentdxetitle yapache-loggen + fluentd + elasticsearch + kibana = ログ検索デモvc273:yddate,	`xcdirjpost/2013/xbid `d12c1c2a68be4c7fda5a7737d5493b4dxdlangbjayglastmod,	`xipermalink!@https://blog.johtani.info/blog/2013/06/06/aws-summit-tokyo-day2/xkpublishdate Y2013-06-06T23:00:00+09:00xgsummary!S昨日に引き続き、AWS Summit Tokyo 2013に行ってきました。 @ryu_kobayashiさんからパシリを仰せつかるなどあり、忙しかったのですが楽しかwdtags2xpcAWSc勉強会xetitle oAWS Summit Tokyo 2013に行って来ました。(Day2) #awssummitvc274:yddate,Hxcdirjpost/2013/xbid `f45069216cd934b80ce882c9a2f2a08axdlangbjayglastmod,Hxipermalink!@https://blog.johtani.info/blog/2013/06/06/cloudera-search-memo2/xkpublishdate Y2013-06-06T12:26:00+09:00xgsummary!HざっとインストールガイドとかCloudera Searchのソース眺めて、テキトーにメモを書いてみました。 （ユーザガイドはまだ読んでないです。wdtags3xpoCloudera SearchfHadoopdSolrxetitle VCloudera Searchメモ（妄想版）vc275:yddate+0Xxcdirjpost/2013/xbid `1fe14e2e02b6e65e6e6e2ae3d8ddcc9fxdlangbjayglastmod+0Xxipermalink!@https://blog.johtani.info/blog/2013/06/05/aws-summit-tokyo-day1/xkpublishdate Y2013-06-05T18:30:00+09:00xgsummary!VAWS Summit Tokyo 2013に行って来ました。 @cocoatomoさんに行き掛けに出会ったので、アンデルセンの講演を一緒に聞いてました。 TDブースの@rywdtags2xpc勉強会cAWSxetitle oAWS Summit Tokyo 2013に行って来ました。(Day1) #awssummitvc276:yddate+-pxcdirjpost/2013/xbid `e30258aeb8475d4c27f7935945671856xdlangbjayglastmod+-pxipermalink!Bhttps://blog.johtani.info/blog/2013/06/05/cloudera-search-modules/xkpublishdate Y2013-06-05T15:12:00+09:00xgsummary!PCloudera Searchは次のようなモジュールから構成されています。 これはCloudera Searchのモジュールで、さらにこれらがSolrとかを使っwdtags4xphClouderafHadoopdSolroCloudera Searchxetitle WCloudera Searchのモジュールたちvc277:yddate+-Lxcdirjpost/2013/xbid `cd90bce912f5743226af94c1efaaa4a7xdlangbjayglastmod+-Lxipermalink!Bhttps://blog.johtani.info/blog/2013/06/05/what-is-cloudera-search/xkpublishdate Y2013-06-05T15:05:00+09:00xgsummary!KAWS Summitに来ていたのですが、TLでは、Cloudera Searchが賑わってました。 ということで、軽くどんなものか読んだり調べたりしたwdtags4xphClouderafHadoopdSolroCloudera Searchxetitle cCloudera Searchってのが出たらしい（とりあえず、雑感？）vc278:yddate+
;Txcdirjpost/2013/xbid `494557db52824555864d1106278cd1f0xdlangbjayglastmod+
;Txipermalink!Ghttps://blog.johtani.info/blog/2013/06/03/fluent-plugin-zoomdata-0-0-1/xkpublishdate Y2013-06-03T13:43:00+09:00xgsummary!G憧れ？のfluentを使ってみました。 こちらの記事で紹介したZoomdataを最近触っているのですが、お試しにfluentdでデータ流し込むwdtags2xphZoomdatagfluentdxetitle afluent-plugin-zoomdata作りました＋悩み事とかvc279:yddate+Fxcdirjpost/2013/xbid `16f10764f0ccce42d5be8cfeac36b446xdlangbjayglastmod+Fxipermalink!Xhttps://blog.johtani.info/blog/2013/06/03/octopress%E3%82%92%E8%A9%A6%E3%81%97%E4%B8%AD/xkpublishdate Y2013-06-03T11:53:58+09:00xgsummary!G最近、Markdownで文章を書くのに慣れてきました。 ということで、ブログをMarkdownで書けないかなぁと思い、TLの人たちのブログを見wdtags1xpdmiscxetitle XOctopressを試し中(Jugemより移植)vc280:yddate* .|xcdirjpost/2013/xbid `dbcc4002c15afefef853a08a0804ba3axdlangbjayglastmod* .|xipermalink zhttps://blog.johtani.info/blog/2013/06/01/first-octopress/xkpublishdate Y2013-06-01T23:57:00+09:00xgsummary!G昨年から、ブログをどうしようかって話をしていて、そのままになっていたのですが、Octopress＋Github Pagesというのがあるらしいwdtags2xpioctopressdmiscxetitlenOctopress始めましたvc281:yddate!;5Txcdirjpost/2013/xbid `11d4726484be418849e1f4200ade9535xdlangbjayglastmod!;5Txipermalink$@https://blog.johtani.info/blog/2013/05/06/lucene-gosen4-3-0%E3%82%92%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Flucene-solr4-3-0%E4%BB%A5%E4%B8%8A%E3%81%A7%E3%81%AE%E5%88%A9%E7%94%A8%E3%81%8C%E5%8F%AF%E8%83%BD%E3%81%A7%E3%81%99/xkpublishdate Y2013-05-06T23:25:24+09:00xgsummary!RLucene/Solr 4.3.0がリリースされた（LuceneのChanges、SolrのChanges）ので、lucene-gosen 4.3.0をリリースしまwdtags1xpllucene-gosenxetitle!Clucene-gosen4.3.0をリリースしました。（Lucene/Solr4.3.0以上での利用が可能です）(Jugemより移植)vc282:yddate <3Kxcdirjpost/2013/xbid `db97311c24809f103575d8a7fee19680xdlangbjayglastmod <3Kxipermalink$^https://blog.johtani.info/blog/2013/05/03/%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E5%9B%9E%E3%81%97%E3%81%A6%E3%81%BE%E3%81%99%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF%E5%85%A5%E9%96%80%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2013-05-03T23:42:19+09:00xgsummary!Iアジャイルな時間管理術 ポモドーロテクニック入門 ポモドーロテクニック入門という本を読みました。 きっかけは、Twitter上で何度か「ポモドーロwdtags1xpb読書xetitle iポモドーロ回してます。（ポモドーロテクニック入門読みました）(Jugemより移植)vc283:yddate	hxcdirjpost/2013/xbid `286a9a4ee373398d7d2c93862c5f6661xdlangbjayglastmod	hxipermalink!zhttps://blog.johtani.info/blog/2013/04/25/solr4-3-0%E3%81%AEchanges%E3%82%92%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/xkpublishdate Y2013-04-25T11:14:00+09:00xgsummary!Iまだ、Vote公開されていない、Solr 4.3（2013/04/25 11:00現在）ですが、 ひさびさに訳してみた。詳細まで追っていないので、wdtags1xpdsolrxetitle cSolr4.3.0のChangesを訳してみた。(Jugemより移植)vc284:yddate8pxcdirjpost/2013/xbid `99f5219da22485d0872a2529599c8440xdlangbjayglastmod8pxipermalink$@https://blog.johtani.info/blog/2013/04/24/lucene-4-3-0%E3%81%AEchanges%E3%81%AB%E3%81%82%E3%82%8Bchanges-in-backwards-compatibility-policy%E3%81%8C%E6%B0%97%E3%81%AB%E3%81%AA%E3%81%A3%E3%81%9F%E3%81%AE%E3%81%A7%E8%A8%B3%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/xkpublishdate Y2013-04-24T16:00:00+09:00xgsummary!H現在、RC3のVoteをやっている最中（2013/04/24 16:00時点）で、まだリリースされていない、4.3.0についてです。 開発者MLwdtags1xpdsolrxetitle!YLucene 4.3.0のChangesにあるChanges in backwards compatibility policyが気になったので訳してみた。(Jugemより移植)vc285:yddate'fxcdirjpost/2013/xbid `36ff37ced0d3211db95a5ac0daac0c35xdlangbjayglastmod'fxipermalink&ihttps://blog.johtani.info/blog/2013/04/23/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass--tecomp--vol-2-%E4%BA%BA%E6%B0%97web%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9%E6%95%99%E3%81%88%E3%81%BE%E3%81%99%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2013-04-23T20:45:42+09:00xgsummary!J第2回目も参加しました。 とりあえずメモ。 自分には欠けてる視点の話しなので面白かった。 ちょっと寒かったなぁ。 エンジニアのためのスキルアップ勉強wdtags1xpc勉強会xetitle!Xエンジニアのためのスキルアップ勉強会『Tech Compass』 #tecomp ― Vol.2 「人気Webサービスの作り方教えます！」に参加しました。(Jugemより移植)vc286:yddate`xcdirjpost/2013/xbid `1ca04e5339ed1826c12fe61fd984e949xdlangbjayglastmod`xipermalink"]https://blog.johtani.info/blog/2013/04/22/jira%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E3%82%92s3%E3%81%B8%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97/xkpublishdate Y2013-04-22T23:07:28+09:00xgsummary!Gだいぶ、ブログを書くペースが落ちてきてて、危機感を感じている今日このごろです。。。 今回は、個人的に利用しているJIRAのバックアップについてwdtags1xpc備忘録xetitle ]JIRAのデータをS3へバックアップ(Jugemより移植)vc287:yddate#{xcdirjpost/2013/xbid `73d2fce4efa52675b35a11ee97bc2db0xdlangbjayglastmod#{xipermalink"^https://blog.johtani.info/blog/2013/04/05/heroku-meetup--8-treasuredata--waza-report-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/xkpublishdate Y2013-04-05T11:20:43+09:00xgsummary!GHerokuではじめるRailsプログラミング入門 heroku気になってるのに使ってなくて、TDのアカウント作ってデータアップしてない軟弱者wdtags1xpc勉強会xetitle!JHeroku Meetup #8 TreasureData + Waza Report!! に参加しました。#herokujp(Jugemより移植)vc288:yddate@xcdirjpost/2013/xbid `26d0c0d8c465087cf160a3bdc479f2b4xdlangbjayglastmod@xipermalink"dhttps://blog.johtani.info/blog/2013/03/26/%E7%AC%AC10%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/xkpublishdate Y2013-03-26T21:16:00+09:00xgsummary!H記念すべき！？第10回のSolr勉強会です。 発表者が無事あつまり（本当にありがとうございました！）、今回も盛況な感じでほぼ満員でした。 ツイーwdtags1xpc勉強会xetitle e第10回Solr勉強会を主催しました。#SolrJP(Jugemより移植)vc289:yddate"Dxcdirjpost/2013/xbid `f5f28f42ad234b4389af4cbea54ff60dxdlangbjayglastmod"Dxipermalink"mhttps://blog.johtani.info/blog/2013/03/20/elasticsearch-analysis-kuromoji%E3%81%A7%E3%83%A6%E3%83%BC%E3%82%B6%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%88%A9%E7%94%A8%E6%96%B9%E6%B3%95/xkpublishdate Y2013-03-20T16:43:00+09:00xgsummary!Nなんか、とても久しぶりにイベント参加メモ以外の投稿です。 elastic searchのMLを見てたら、KuromojiのAnalyzerを使うときにユーザwdtags1xpmelasticsearchxetitle uelasticsearch-analysis-kuromojiでユーザ辞書の利用方法(Jugemより移植)vc290:yddate/@xcdirjpost/2013/xbid `5412fb82160d0f6093e4b6670f505c13xdlangbjayglastmod/@xipermalink'~https://blog.johtani.info/blog/2013/03/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B9%E3%82%AD%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97%E5%8B%89%E5%BC%B7%E4%BC%9Atech-compass%E7%AB%B9%E6%A9%8B--vol1-%E3%82%B9%E3%83%9E%E3%83%9B%E6%99%82%E4%BB%A3%E5%88%B0%E6%9D%A5%E3%81%93%E3%81%AE%E5%85%88%E7%94%9F%E3%81%8D%E3%81%AE%E3%81%93%E3%82%8B%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%A8%E3%81%AF%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-tecomp/xkpublishdate Y2013-03-19T20:28:00+09:00xgsummary!H久々にブログ＋イベント参加です。 知り合いが開催＋出演したので参加してみました。 「スマホ」ってキーワードはあまりなかったけど、面白かったです。wdtags1xpc勉強会xetitle!`エンジニアのためのスキルアップ勉強会『Tech Compass』＠竹橋 ― Vol1 「スマホ時代到来、この先生きのこるエンジニアとは！？」に参加しました。#tecomp(Jugemより移植)vc291:yddate'
lxcdirjpost/2013/xbid `b051fd352847c06e748b345e8ed0738bxdlangbjayglastmod'
lxipermalink!`https://blog.johtani.info/blog/2013/02/13/xperia-z%E8%B2%B7%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2013-02-13T01:53:00+09:00xgsummary!P技術ブログから離れていってますが。。。 Xperia Zを購入しました。 前に使っていたのはXperia arcになります。 もうすぐ２年だったのですが、容量不wdtags1xpc備忘録xetitle XXperia Z買いました(Jugemより移植)vc292:yddate?hxcdirjpost/2013/xbid `bf4f86812812dab8d39db9aaefe94a78xdlangbjayglastmod?hxipermalink"Thttps://blog.johtani.info/blog/2013/01/22/hadoop-conference-japan-2013-winter%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hcj13w/xkpublishdate Y2013-01-22T00:50:00+09:00xgsummary!\金曜日に引き続き、イベントに参加して来ました。（仕事。。。これも仕事だよ。） 「Hadoop Conference Japan 2013 Winter」です。 普段、Hadoopを触るwdtags1xpc勉強会xetitle }Hadoop Conference Japan 2013 Winterに参加しました。#hcj13w(Jugemより移植)vc293:yddate>)+lxcdirjpost/2013/xbid `322264a17ef7182eb1475bd2eaebc2ebxdlangbjayglastmod>)+lxipermalink$ahttps://blog.johtani.info/blog/2013/01/19/%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88cross-2013%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%8A%E6%89%8B%E4%BC%9D%E3%81%84%E3%83%A2%E3%83%87%E3%83%AC%E3%83%BC%E3%82%BF%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--cross2013/xkpublishdate Y2013-01-19T22:09:00+09:00xgsummary!G1/18（金）に開催された、エンジニアサポートCROSS 2013で「検索CROSS」セッションのセッションオーナー（モデレータ）をやって来まwdtags1xpc勉強会xetitle }エンジニアサポートCROSS 2013に参加（＋お手伝い＋モデレータ）しました #cross2013(Jugemより移植)vc294:yddate=Lxcdirjpost/2013/xbid `20110c8f8da8304b6d9d3c2845a38128xdlangbjayglastmod=Lxipermalink$Rhttps://blog.johtani.info/blog/2013/01/16/%E3%81%84%E3%81%BE%E3%81%95%E3%82%89%E3%81%A7%E3%81%99%E3%81%8Ccross-2013%E3%81%A7%E6%A4%9C%E7%B4%A2cross%E3%81%A8%E3%81%84%E3%81%86%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E6%8B%85%E5%BD%93%E3%81%97%E3%81%BE%E3%81%99/xkpublishdate Y2013-01-16T01:29:00+09:00xgsummary!Gいまさら感満載ですが、今週の金曜日(1/18)に開催されるCROSS 2013というイベントで「検索CROSS」のセッションを担当することになwdtags1xpc勉強会xetitle sいまさらですが、CROSS 2013で検索CROSSというセッションを担当します(Jugemより移植)vc295:yddate;,@xcdirjpost/2013/xbid `992a00c30242b6217243f3c387ea18b7xdlangbjayglastmod;,@xipermalink$xhttps://blog.johtani.info/blog/2013/01/09/%E3%82%B3%E3%83%BC%E3%83%89%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AA%E3%82%B7%E3%83%86%E3%82%A3%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9Fkindle-paperwhite%E3%81%AE%E4%BD%BF%E3%81%84%E5%8B%9D%E6%89%8B%E3%81%AE%E7%A2%BA%E8%AA%8D%E3%82%82%E5%85%BC%E3%81%AD%E3%81%A6/xkpublishdate Y2013-01-09T00:28:00+09:00xgsummary!H年末から年始にかけて、「コード・シンプリシティ」を読みました。 先日の記事にも書きましたが、Kindle paperwhiteを思いかけず入手でwdtags1xpb読書xetitle ~「コード・シンプリシティ」を読みました。（Kindle paperwhiteの使い勝手の確認も兼ねて）(Jugemより移植)vc296:yddate8lxcdirjpost/2012/xbid `4c08b67e0c1fdeef50b1fdcc32cdcee2xdlangbjayglastmod8lxipermalink"dhttps://blog.johtani.info/blog/2012/12/31/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A02012/xkpublishdate Y2012-12-31T08:01:00+09:00xgsummary!I書こうと思いながら、気づいたら大晦日。 よくないですね、思いついた時に書かないと。 昨年も書いたので、昨年書いた抱負から振り返りをと。 Mongowdtags1xpc備忘録xetitle ^今年の振り返りと来年の抱負（2012）(Jugemより移植)vc297:yddate4/hxcdirjpost/2012/xbid `4a30eeb083acec8460150068ba0c6743xdlangbjayglastmod4/hxipermalink!|https://blog.johtani.info/blog/2012/12/20/jira%E3%81%AEdb%E7%A7%BB%E8%A1%8Chsqldb%E3%81%8B%E3%82%89postgresql%E3%81%B8-augj/xkpublishdate Y2012-12-20T20:18:00+09:00xgsummary!_Atlassian Advent Calendar 2012の20日目。（急遽参戦） （某イケメンにMT（改変リツイート）されたので書いてみました） 久々に、勉強会以外のエントリです。（Sowdtags1xpdJIRAxetitle nJIRAのDB移行（HSQLDBからPostgreSQLへ）#augj(Jugemより移植)vc298:yddate12hxcdirjpost/2012/xbid `898d25a2ab9c0ba1fa9bad462405e475xdlangbjayglastmod12hxipermalink#qhttps://blog.johtani.info/blog/2012/12/11/%E7%AC%AC%E4%B8%80%E5%9B%9E-jetbrains%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97--jbugj-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-12-11T21:22:00+09:00xgsummary!Iイケメンが主催した「第一回 JetBrainsユーザーグループ #jbugj」に参加してきました。 いろんな製品があるんだなぁと。入り口には良いイwdtags1xpc勉強会xetitle q第一回 JetBrainsユーザーグループ #jbugj に参加してきました(Jugemより移植)vc299:yddate-$Pxcdirjpost/2012/xbid `e01e01d18582c7f69e1b0db7e1b111a0xdlangbjayglastmod-$Pxipermalink#ohttps://blog.johtani.info/blog/2012/11/29/dsirnlp-3-5%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Femacs%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80%E3%82%92%E9%A0%82%E3%81%84%E3%81%A1%E3%82%83%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-11-29T02:00:00+09:00xgsummary!Hヒカリエに行ってみたいという不純な理由で参加してきました。 新しいということもあり、おしゃれで綺麗なカフェでした。 入り口にはおっきな人形も立っwdtags1xpc勉強会xetitle u#DSIRNLP 3.5に参加しました。＆「Emacs実践入門」を頂いちゃいました！(Jugemより移植)vc300:yddate,3'`xcdirjpost/2012/xbid `7e23419e4fc69b5b533815681c9bb1a9xdlangbjayglastmod,3'`xipermalink"chttps://blog.johtani.info/blog/2012/11/26/%E7%AC%AC9%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%82%92%E4%B8%BB%E5%82%AC%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-solrjp/xkpublishdate Y2012-11-26T18:44:00+09:00xgsummary!H第9回Solr勉強会に参加しました。 皆勤賞です！というか、主催者になってしまいました。 まだ不定期の開催になると思いますが、話をされたい方などwdtags1xpc勉強会xetitle d第9回Solr勉強会を主催しました。#SolrJP(Jugemより移植)vc301:yddate'(dxcdirjpost/2012/xbid `98c640616f997a323af625e34ba34850xdlangbjayglastmod'(dxipermalink#shttps://blog.johtani.info/blog/2012/11/10/aws-%E3%83%93%E3%83%83%E3%82%B0%E3%83%87%E3%83%BC%E3%82%BF%E6%B4%BB%E7%94%A8%E4%BA%8B%E4%BE%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-jawsug/xkpublishdate Y2012-11-10T01:07:00+09:00xgsummary!G初目黒（たぶん）で、初Amazonな感じで、流行りの「ビッグデータ」のセミナーに参加してきました。 とりあえず、いつもの自分用のメモを残しておwdtags1xpc勉強会xetitle lAWS ビッグデータ活用事例セミナーに参加しました。#jawsug(Jugemより移植)vc302:yddate="Lxcdirjpost/2012/xbid `922cc71fd28b1dac8f407f1d517f5595xdlangbjayglastmod="Lxipermalink"Jhttps://blog.johtani.info/blog/2012/10/12/lucene-solr-4-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9lucene-gosen%E3%81%AE4-0%E5%AF%BE%E5%BF%9C/xkpublishdate Y2012-10-12T17:45:00+09:00xgsummary!U##Lucene/Solr 4.0.0リリース ついに、Lucene/Solr4.0.0がリリースされました。 MLで流れていましたが、3年越しのリリースだったようです。wdtags1xpllucene-gosenxetitle sLucene/Solr 4.0.0リリース＆lucene-gosenの4.0対応(Jugemより移植)vc303:yddate,|xcdirjpost/2012/xbid `43501cdf0de25278a208cbb9aad80012xdlangbjayglastmod,|xipermalink"}https://blog.johtani.info/blog/2012/09/26/lucid%E3%81%AEgrant-ingersoll%E3%81%95%E3%82%93%E3%81%AE%E8%AC%9B%E6%BC%94%E3%82%92%E8%81%9E%E3%81%84%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-09-26T18:08:12+09:00xgsummary!Gこのイベントにウチダスペクトラムの枠でMahoutのコミッターである、Grant Ingersollさんが講演されるということで、興味があったwdtags1xpc勉強会xetitle mLucidのGrant Ingersollさんの講演を聞いてきました(Jugemより移植)vc304:yddate
>lxcdirjpost/2012/xbid `89abaa7f21cf788ce4744e3e61173291xdlangbjayglastmod
>lxipermalink#Xhttps://blog.johtani.info/blog/2012/09/21/pfi%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC2012%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pfiopen2012/xkpublishdate Y2012-09-21T17:05:00+09:00xgsummary!GPFIオープンセミナー2012に参加してきました。 対象から微妙に外れてたり、話の内容についていけるか自信がありませんでしたが、参加してきましwdtags1xpc勉強会xetitle qPFIオープンセミナー2012に参加してきました。 #pfiopen2012(Jugemより移植)vc305:yddateHxcdirjpost/2012/xbid `7604edf307a5e96120606c8dda06458fxdlangbjayglastmodHxipermalink#]https://blog.johtani.info/blog/2012/09/03/%E3%83%A1%E3%82%A4%E3%83%B3mba%E3%82%92mountain-lion%E3%81%AB%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88%E3%81%84%E3%82%8D%E3%81%84%E3%82%8D%E7%A2%BA%E8%AA%8D%E4%B8%AD/xkpublishdate Y2012-09-03T14:34:00+09:00xgsummary!H友人にお値打価格で購入したMac miniはMountain Lionにアップデートしてたのですが、手元のAirはまだアップデートしていませんでwdtags1xpc備忘録xetitle oメインMBAをMountain Lionにアップデート（いろいろ確認中）(Jugemより移植)vc306:yddate
%pxcdirjpost/2012/xbid `775894425f5a7436f56fc5a3b4a2cfaaxdlangbjayglastmod
%pxipermalink"Nhttps://blog.johtani.info/blog/2012/08/23/fluentd-meetup-in-japan--2--fluentd-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-08-23T02:40:00+09:00xgsummary!G興味をもちつつ、触っていない軟弱者ですが、興味があるので今回も話を聞きに行って来ました。 まずは、作者古橋さんによるFluentdの魅力や次期wdtags1xpc勉強会xetitle wFluentd meetup in Japan #2 #fluentd に参加しました。(Jugemより移植)vc307:yddate+Xxcdirjpost/2012/xbid `8a29f62d1bebfe7b8008d7f264b56b4exdlangbjayglastmod+Xxipermalink"Yhttps://blog.johtani.info/blog/2012/08/02/twitter-%E5%8B%89%E5%BC%B7%E4%BC%9A--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-08-02T11:50:00+09:00xgsummary!Gまたまた飲みに行って参加してきました。 今回は、Rails、iOSでのTwitter連携の話から、ツイート分析、クライアントアプリの開発の苦労wdtags1xpc勉強会xetitle jTwitter 勉強会 #twtr_hack に参加しました。(Jugemより移植)vc308:yddate:6Txcdirjpost/2012/xbid `7fa2f0877831b4c924438396760f1841xdlangbjayglastmod:6Txipermalink#Ohttps://blog.johtani.info/blog/2012/07/28/python-developers-festa-2012-07%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%97%E3%82%83%E3%81%B9%E3%81%A3%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F--pyfes/xkpublishdate Y2012-07-28T18:15:00+09:00xgsummary!Gということで、ステッカー欲しさ？に勉強中の話を恥ずかしげもなく偉そうにしゃべってきました。 #pyfesは以前から、気になっていたんですが、タwdtags1xpc勉強会xetitle Python Developers Festa 2012.07に参加してしゃべってきました #pyfes(Jugemより移植)vc309:yddatehxcdirjpost/2012/xbid `68a8f34c240a42ab521d2f885f7aa33cxdlangbjayglastmodhxipermalink!thttps://blog.johtani.info/blog/2012/07/13/partial-update%E3%81%A8copyfield%E3%81%AE%E3%83%90%E3%82%B0solr-4-0-alpha/xkpublishdate Y2012-07-13T20:02:00+09:00xgsummary!a今日はSolr 4.0 ALPHAの興味深い機能があったので紹介です。 数日前に「Solr 4.0: Partial documents update」という記事を見つけました。 Solrには、wdtags1xpdsolrxetitle vPartial UpdateとcopyFieldのバグ【Solr 4.0 ALPHA】(Jugemより移植)vc310:yddate?/9Bxcdirjpost/2012/xbid `9ac7bb94e60dc30a023ce433de027364xdlangbjayglastmod?/9Bxipermalink!vhttps://blog.johtani.info/blog/2012/07/13/mir%E8%BC%AA%E8%AA%AD%E4%BC%9A%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-07-13T01:41:38+09:00xgsummary"~Modern Information Retrieval: The Concepts and Technology behind Search (2nd Edition) (ACM Press Books) いやぁ、蒸し暑くてなかなか寝れない日がはじまりましたね。（あんまり関係ないですね。。。） Modern Information Retrieval 2nd Editionをwdtags1xpc勉強会xetitle VMIR輪読会始めました(Jugemより移植)vc311:yddate=uxcdirjpost/2012/xbid `dcc2e24df32287e89ee3b0f64d617f57xdlangbjayglastmod=uxipermalink!fhttps://blog.johtani.info/blog/2012/07/05/lucene-gosen%E3%81%AElucene-solr4-0-alpha%E5%AF%BE%E5%BF%9C/xkpublishdate Y2012-07-05T12:11:49+09:00xgsummary!GLucene/Solrの4.0.0-ALPHAが7/3にリリースされました。 これに伴い、lucene-goenの4xブランチのjarファイルwdtags1xpllucene-gosenxetitle nlucene-gosenのLucene/Solr4.0-ALPHA対応(Jugemより移植)vc312:yddate=.Pxcdirjpost/2012/xbid `8acc78be63e27e938ee53ec2c0b90c61xdlangbjayglastmod=.Pxipermalink"dhttps://blog.johtani.info/blog/2012/07/04/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--solrjp/xkpublishdate Y2012-07-04T20:40:00+09:00xgsummary!Jまたまた参加しました。いまだ皆勤賞です。 感想などはあとで。とりあえず、メモとったので第一弾です。 ということで、感想です。 まずは、参加人数。 今wdtags1xpc勉強会xetitle eSolr勉強会第8回に参加しました。 #SolrJP(Jugemより移植)vc3139yddate:	\xcdirjpost/2012/xbid `9f29c6d9719fc6bc09a2981057642b69xdlangbjayglastmod:	\xipermalink#~https://blog.johtani.info/blog/2012/06/26/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC10%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/xkpublishdate Y2012-06-26T01:41:00+09:00xgsummary!SHadoopからはちょっと離れているのに、面白そうなネタなので参加しました。 Data Science Summit、HBaseCon、Hadoop Summitのイxetitle wHadoopソースコードリーディング第10回に参加しました。#hadoopreading(Jugemより移植)vc314:yddate73Txcdirjpost/2012/xbid `d13aa56e27fe71ef40ff153c093ecdf8xdlangbjayglastmod73Txipermalink!Xhttps://blog.johtani.info/blog/2012/06/18/lucene-gosen%E3%81%AEunidic%E5%AF%BE%E5%BF%9C/xkpublishdate Y2012-06-18T23:03:00+09:00xgsummary!LIssue 32で上がってきたlucee-gosenのUniDic対応の最初のパッチを書いたので、ブログに残しておきます。 ###UniDicとは___wdtags1xpllucene-gosenxetitle `lucene-gosenのUniDic対応(Jugemより移植)vc315:yddate649hxcdirjpost/2012/xbid `9ccda414c322ebcdf875eacbba2e4b7exdlangbjayglastmod649hxipermalink"Qhttps://blog.johtani.info/blog/2012/06/16/zipkin%E3%81%AEreadme%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%81%9D%E3%81%AE%EF%BC%92%E6%AE%8B%E3%82%8A/xkpublishdate Y2012-06-16T00:02:00+09:00xgsummary!H「鉄は熱いうちに打て」ということで、残りも勢いでメモ。 まだ、見直しとかしてない状態なのでおかしいところとかありますが。。。 図とか入れるのはまwdtags1xpfZipkinxetitle dZipkinのReadme読んでる（その２、残り）(Jugemより移植)vc316:yddate6(!\xcdirjpost/2012/xbid `69f755dd5b9e90a99c3086543790541cxdlangbjayglastmod6(!\xipermalink#Yhttps://blog.johtani.info/blog/2012/06/15/zipkin%E3%81%AEreadme%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A7%E3%82%8B%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E5%91%A8%E3%82%8A%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/xkpublishdate Y2012-06-15T09:57:00+09:00xgsummary!HZipkinのGithubにあるReadmeを読んでます。 せっかくというか、頭が悪いので読みながら内容をメモ。 まずは、アーキテクチャとトレーwdtags1xpfZipkinxetitle kZipkinのReadmeを読んでる（クライアント周りについて）(Jugemより移植)vc317:yddate6,\xcdirjpost/2012/xbid `277f7f2177e2a265a62680ea0158f9b9xdlangbjayglastmod6,\xipermalink"ghttps://blog.johtani.info/blog/2012/06/14/autogeneratephrasequeries%E3%81%AE%E3%83%87%E3%83%95%E3%82%A9%E3%83%AB%E3%83%88%E5%80%A4%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/xkpublishdate Y2012-06-14T01:09:00+09:00xgsummary!H久々にSolrの話です。 といっても、結構前からの話でして。。。 schema.xmlのfieldTypeの設定に「autoGeneratePhwdtags1xpdsolrxetitle oautoGeneratePhraseQueriesのデフォルト値について(Jugemより移植)vc318:yddate56Pxcdirjpost/2012/xbid `ee48516e57684c5a4c22adccac34be92xdlangbjayglastmod56Pxipermalink#chttps://blog.johtani.info/blog/2012/06/13/twitter%E3%81%8C%E5%85%AC%E9%96%8B%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%B3%E3%82%B0%E8%BF%BD%E8%B7%A1%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0zipkin/xkpublishdate Y2012-06-13T00:40:00+09:00xgsummary!Gすでに読まれた方もいるかも知れませんが、気になったのでメモを書いてみようかと。 先週の木曜日にTwitterのエンジニアブログでZipkinとwdtags1xpcOSSxetitle oTwitterが公開した分散トレーシング（追跡？）システム、Zipkin(Jugemより移植)vc319:yddate40bxcdirjpost/2012/xbid `216db319052b5742fc68862cb2f39905xdlangbjayglastmod40bxipermalink#Dhttps://blog.johtani.info/blog/2012/06/07/lucene-gosen-2-0-2%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E5%91%A8%E3%82%8A%E3%81%AE%E6%94%B9%E5%96%84%E3%81%AA%E3%81%A9/xkpublishdate Y2012-06-07T17:53:54+09:00xgsummary!Hlucene-gosenの最新版（2.0.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、@haruywdtags1xpllucene-gosenxetitle nlucene-gosen 2.0.2リリース（リソース周りの改善など）(Jugemより移植)vc320:yddate3#lxcdirjpost/2012/xbid `cbf9587a8187985725963b8bfc67004dxdlangbjayglastmod3#lxipermalink!lhttps://blog.johtani.info/blog/2012/06/06/issue32%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A64096%E3%81%AE%E5%A3%81/xkpublishdate Y2012-06-06T01:21:00+09:00xgsummary!G昨晩に引き続き、情けない内容のブログになってしまいますが。。。 昨晩、書いた記事の調査をしていた時に気づいた、問題になるケースがあったので調査wdtags1xpllucene-gosenxetitle ^Issue32について（4096の壁）(Jugemより移植)vc321:yddate3	Lxcdirjpost/2012/xbid `0dcb6d0f17794bbca56b6cdb9e20b932xdlangbjayglastmod3	Lxipermalink$ahttps://blog.johtani.info/blog/2012/06/05/trunk%E3%81%AE%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E5%B7%AE%E3%81%97%E6%9B%BF%E3%81%88lucene-solr3-6-0%E3%81%A8%E3%83%A9%E3%83%B3%E3%83%80%E3%83%A0%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E5%A4%B1%E6%95%97%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/xkpublishdate Y2012-06-05T01:29:00+09:00xgsummary!G久々にlucene-gosenを触っています。 trunkのlibにある、jarファイルが3.5ベースだったので、3.6ベースにしてテストをしwdtags1xpllucene-gosenxetitle {trunkのライブラリ差し替え（Lucene/Solr3.6.0）とランダムテストの失敗について(Jugemより移植)vc322:yddate1$Pxcdirjpost/2012/xbid `ffdbd6a7d28c9a63976e9eec38cab0f5xdlangbjayglastmod1$Pxipermalink"rhttps://blog.johtani.info/blog/2012/05/31/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%B8%E3%81%AE%E8%B2%A2%E7%8C%AE%E3%81%AE%E3%82%B9%E3%82%B9%E3%83%A1/xkpublishdate Y2012-05-31T01:12:00+09:00xgsummary!H録画してたEテレのスーパープレゼンテーションを見ててふと書きたくなったので、書いてます。 あとから読んだら恥ずかしくなりそうだけど。。。 「&lwdtags1xpdmiscxetitle Zオープンソースへの貢献のススメ(Jugemより移植)vc323:yddate1 lxcdirjpost/2012/xbid `de734259dfb9addebe2b226d96b4f744xdlangbjayglastmod1 lxipermalink"Phttps://blog.johtani.info/blog/2012/05/29/jjug-ccc-2012-spring%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-05-29T11:45:00+09:00xgsummary!TJJUG CCC 2012 Springに参加してきました。 昨年のFallに続き、2回目です。 概要や、タイムテーブルはこちらを御覧ください。 今回は、午後一から参加wdtags1xpc勉強会xetitle iJJUG CCC 2012 Springに参加してきました。(Jugemより移植)vc324:yddate,4=Rxcdirjpost/2012/xbid `78f002cc3d512ea302c900d1da4dfeecxdlangbjayglastmod,4=Rxipermalink"Shttps://blog.johtani.info/blog/2012/05/16/playframework-2-0-java%E3%81%AE%E6%96%B9-%E3%82%92%E8%A7%A6%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%A6%E3%82%8B/xkpublishdate Y2012-05-16T15:55:14+09:00xgsummary!HPlayFramework2.0を触ってみてます。 ちょっとコーディングしたくなったのと、最近のアプリの作成の調査も兼ねて。 まぁ、せっかくなのwdtags1xpc備忘録xetitle kPlayFramework 2.0(Javaの方)を触ってみてる(Jugemより移植)vc325:yddate*,txcdirjpost/2012/xbid `c4b418764dca70aebfc965899a3fa7e5xdlangbjayglastmod*,txipermalink!xhttps://blog.johtani.info/blog/2012/05/09/lucene-gosen-2-0-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9java7%E5%AF%BE%E5%BF%9C/xkpublishdate Y2012-05-09T01:35:00+09:00xgsummary!Hlucene-gosenの最新版（2.0.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、Java7でwdtags1xpllucene-gosenxetitle jlucene-gosen 2.0.1リリース（Java7対応）(Jugemより移植)vc326:yddate')/Kxcdirjpost/2012/xbid `95c0a5b8a66950b5f22dd82a8dfe0ce5xdlangbjayglastmod')/Kxipermalink!~https://blog.johtani.info/blog/2012/04/30/id%E3%81%AE%E7%A7%98%E5%AF%86%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-04-30T23:03:55+09:00xgsummary!IIDの秘密 (丸善ライブラリー―情報研シリーズ) 非常に面白く読めました。 バーコードの話に始まり、最後はシステムで付与するIDに関する考慮点までwdtags1xpb読書xetitle Y「IDの秘密」を読みました。(Jugemより移植)vc327:yddate$=Txcdirjpost/2012/xbid `c92c12a28fa219ad1aab60865046ff05xdlangbjayglastmod$=Txipermalink"Ehttps://blog.johtani.info/blog/2012/04/21/heroku-jp-meetup-4%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-herokujp/xkpublishdate Y2012-04-21T00:23:00+09:00xgsummary!JWebSolrの話があるらしいというのを嗅ぎつけて、初めてHeroku JP Meetupに参加しました。 herokuもWebSolrも知りつつ、wdtags1xpc勉強会xetitle oHeroku JP Meetup ＃4に参加しました。#herokujp(Jugemより移植)vc328:yddate#Kxcdirjpost/2012/xbid `12d1e0cf7396dd33a9bbbca8da4cbc68xdlangbjayglastmod#Kxipermalink"ohttps://blog.johtani.info/blog/2012/04/17/solr-3-6-0%E3%81%AEcjk%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%81%A8synonymfilterfactory%E3%81%AE%E6%B0%97%E3%81%AB%E3%81%AA%E3%82%8B%E7%82%B9/xkpublishdate Y2012-04-17T01:16:11+09:00xgsummary!H先日、Solr入門のサンプルschema.xmlの3.6.0対応版の作成をしていて、気になったことがあったので、 メモとして残しておきます。 Swdtags1xpdsolrxetitle wSolr 3.6.0のCJKの設定とSynonymFilterFactoryの気になる点(Jugemより移植)vc329:yddate"$hxcdirjpost/2012/xbid `d77cdb466c5063b99c5aea58e6da4d32xdlangbjayglastmod"$hxipermalink#Ahttps://blog.johtani.info/blog/2012/04/14/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C2%E7%AB%A04%E7%AB%A0/xkpublishdate Y2012-04-14T02:58:00+09:00xgsummary!H先日の続きです。「Apache Solr入門」の2章から4章の説明について、Solr3.6.0で動作させる時の変更点を以下に書いていきます。 なwdtags1xpdsolrxetitle ~「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（2章～4章）(Jugemより移植)vc330:yddate"\xcdirjpost/2012/xbid `904b07170a0ce481b7491e7fecce4f79xdlangbjayglastmod"\xipermalink#ohttps://blog.johtani.info/blog/2012/04/14/lucene-solr-3-6-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9---apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AEkuromoji%E3%81%A8lucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0/xkpublishdate Y2012-04-14T02:45:00+09:00xgsummary!H以前より、アナウンスしていた、Kuromojiという日本語形態素解析が含まれるLucene/Solr 3.6.0がリリースされました。 以下、各wdtags1xpdsolrxetitle!SLucene/Solr 3.6.0リリース / 「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（1章）(Jugemより移植)vc331:yddate!.mxcdirjpost/2012/xbid `bed3b7fcc1294e23639057435ac8756axdlangbjayglastmod!.mxipermalink"Whttps://blog.johtani.info/blog/2012/04/12/%E3%83%A1%E3%83%A2amazon-cloudsearch%E3%81%8C%E5%87%BA%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F%E3%82%88/xkpublishdate Y2012-04-12T23:31:09+09:00xgsummary!HTwitterでこのブログ流れてきて、気になったので、流し読みして簡単にメモ。 Amazonのサービスでスケールする検索サービスみたい。 主に、wdtags1xpc備忘録xetitle i【メモ】Amazon CloudSearchが出てきましたよ(Jugemより移植)vc332:yddate*
dxcdirjpost/2012/xbid `56d5711303378bd333ddb611a53ece94xdlangbjayglastmod*
dxipermalink"Hhttps://blog.johtani.info/blog/2012/04/06/java-one-tokyo-2012-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-javaonejp/xkpublishdate Y2012-04-06T16:51:00+09:00xgsummary!TJavaOne Tokyo 2012に参加してきました。 4/4-4/5の2日間開催されていたのですが、子供が体調を崩してしまい、4/5のみの参加となりました。 4/4wdtags1xpc勉強会xetitle qJava One Tokyo 2012 に参加しました。#JavaOneJp(Jugemより移植)vc333:yddate`xcdirjpost/2012/xbid `c7937b6b4bde2a96191dc31db913e1abxdlangbjayglastmod`xipermalink"qhttps://blog.johtani.info/blog/2012/04/05/lucene-gosen%E3%81%AEjava7%E3%81%A7%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E5%A4%B1%E6%95%97%E5%95%8F%E9%A1%8C%E3%81%AE%E5%AF%BE%E5%BF%9C/xkpublishdate Y2012-04-05T00:20:00+09:00xgsummary!G先日、2.0.0リリースの記事にも記載しましたが、Java7でテストケースが失敗する問題がありました。 @haruyamaさんと@hideakwdtags1xpllucene-gosenxetitle ilucene-gosenのJava7でのテスト失敗問題の対応(Jugemより移植)vc334:yddate7Hxcdirjpost/2012/xbid `06731164684f90f33ce4017eca9d8ec1xdlangbjayglastmod7Hxipermalink!shttps://blog.johtani.info/blog/2012/04/02/%E9%87%8D%E8%A6%81lucene-gosen-2-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/xkpublishdate Y2012-04-02T19:22:00+09:00xgsummary!R先日、宣言したとおり、lucene-gosenのパッケージ名＋クラス名の変更を行ったlucene-gosen 2.0.0をリリースしました。 Lucene/Solrwdtags1xpllucene-gosenxetitle e【重要】lucene-gosen 2.0.0リリース(Jugemより移植)vc335:yddate
 &txcdirjpost/2012/xbid `f8327953a0f0b80011b939111807999axdlangbjayglastmod
-&txipermalink"lhttps://blog.johtani.info/blog/2012/03/27/%E9%87%8D%E8%A6%81lucene-gosen%E3%81%AE%E6%AC%A1%E6%9C%9F%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/xkpublishdate Y2012-03-27T02:39:00+09:00xgsummary!Hlucene-gosenを利用して頂いてる皆様に連絡があります。 連絡事項 次期lucene-gosenのリリース（2.0を予定）にて、org.wdtags1xpllucene-gosenxetitle f【重要】lucene-gosenの次期リリースについて(Jugemより移植)vc335:yddate"txcdirjpost/2012/xbid `8b76101d185700a8efed148d8722d926xdlangbjayglastmod"txipermalink!{https://blog.johtani.info/blog/2012/03/25/%E4%B9%85%E3%80%85%E3%81%ABmac-mini%E3%81%AE%E3%81%93%E3%81%A8%E3%81%A7%E3%82%82/xkpublishdate Y2012-03-25T04:47:00+09:00xgsummary!G子供の寝かしつけしてたら、寝かしつけされてしまって、２時に目が覚めてしまいました。 TSUTAYAでCD借りてきてウォークマンに入れようと思っwdtags1xpc備忘録xetitle [久々にMac Miniのことでも(Jugemより移植)vc336:yddate@xcdirjpost/2012/xbid `16b3c9445539e9274282a612dea354c2xdlangbjayglastmod@xipermalink"Dhttps://blog.johtani.info/blog/2012/03/22/%E7%AC%AC5%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%B8%8B%E8%B0%B7--twtr_hack/xkpublishdate Y2012-03-22T00:28:00+09:00xgsummary!Hはい。またまた、Twitter API勉強会に参加してきました。（今回から開催回数の記載がなくなった？） 今回は直前でタイムテーブルが変わってしwdtags1xpc勉強会xetitle l第5回 Twitter API勉強会 @渋谷 #twtr_hack(Jugemより移植)vc337:yddate	`xcdirjpost/2012/xbid `ee623aaa99b429863f89da313fffed97xdlangbjayglastmod	`xipermalink#hhttps://blog.johtani.info/blog/2012/03/20/%E8%87%AA%E5%88%86%E3%81%AE%E5%B0%8F%E3%81%95%E3%81%AA%E7%AE%B1%E3%81%8B%E3%82%89%E8%84%B1%E5%87%BA%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-03-20T23:32:00+09:00xgsummary!HTLで面白いと見かけて、Amazonで買ってしまいました。 SEやってるのに、つい最近Amazonを使い始めた軟弱者です。 それにしてもAmazwdtags1xpb読書xetitle e「自分の小さな「箱」から脱出する方法」を読みました。(Jugemより移植)vc338:yddate6Excdirjpost/2012/xbid `116c9be6d760b4befa6d51ce9e96604cxdlangbjayglastmod6Exipermalink!]https://blog.johtani.info/blog/2012/03/14/scala%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-03-14T00:27:01+09:00xgsummary!Iえーと、ブログ更新してないなぁとふと思ったので。 １年前くらいからずーっと、つぶやいてましたが、やっとScalaを始めました。 長かった。。。 とwdtags1xpeScalaxetitle UScala始めました(Jugemより移植)vc339:yddatexxcdirjpost/2012/xbid `4d6c95b0b3ea2ddb30fdd3edf3b82391xdlangbjayglastmodxxipermalink"hhttps://blog.johtani.info/blog/2012/03/09/%E7%AC%AC0%E5%9B%9E-twitter-hack--twtr_hack-%E3%81%AB%E9%81%8A%E3%81%B3%E3%81%AB%E8%A1%8C%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-03-09T03:10:00+09:00xgsummary!H森ビルに行ったことなかったので、参加してみました。 あと、最近まともにコーディングしてないので、そのへんを矯正するためにもと思って。 （まぁ、遊wdtags1xpc勉強会xetitle q第0回 Twitter Hack #twtr_hack に遊びに行きました。(Jugemより移植)vc340:yddateHxcdirjpost/2012/xbid `10eb415a232ad4be7d05c57eb850036cxdlangbjayglastmodHxipermalink!Zhttps://blog.johtani.info/blog/2012/03/03/clean-coder%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A0/xkpublishdate Y2012-03-03T01:14:00+09:00xgsummary!XClean Coder プロフェッショナルプログラマへの道 Clean Coderを読みました。 理由はTwitterで「Clean Code」がいい本だと流れてきたためです。wdtags1xpb読書xetitle ZClean Coderを読んだ(Jugemより移植)vc341:yddate(pxcdirjpost/2012/xbid `627a0c45dd07150343c81d856855590exdlangbjayglastmod(pxipermalink#Nhttps://blog.johtani.info/blog/2012/02/26/%E8%A6%AA%E5%AD%90%E3%81%A7%E6%A5%BD%E3%81%97%E3%82%81%E3%82%8B-%E7%B5%B5%E6%9C%AC%E3%81%A7%E8%8B%B1%E8%AA%9E%E3%82%92%E3%81%AF%E3%81%98%E3%82%81%E3%82%8B%E6%9C%AC/xkpublishdate Y2012-02-26T01:20:00+09:00xgsummary!I親子で楽しめる 絵本で英語をはじめる本 Twitterでこの本について書かれたブログ記事が流れてきて、購入しました。 最近、英語を身につけておいたwdtags1xpb読書xetitle ^親子で楽しめる 絵本で英語をはじめる本(Jugemより移植)vc342:yddate&8xxcdirjpost/2012/xbid `966fe8d32b86121f8a465a21b95f7e5cxdlangbjayglastmod&8xxipermalink$Chttps://blog.johtani.info/blog/2012/02/24/%E7%AC%AC4%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E3%83%8F%E3%83%AA%E3%82%A6%E3%83%83%E3%83%89--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-02-24T01:50:00+09:00xgsummary!Q今週も勉強会に参加しました。 @yusukey さんが開催してるTwitter API勉強会です。 前回とは会場が異なりましたが、広くて大画面で良い会場でした。駅wdtags1xpc勉強会xetitle |第4回 Twitter API勉強会 @デジタルハリウッド #twtr_hack に参加しました。(Jugemより移植)vc343:yddate'\xcdirjpost/2012/xbid `4e7b945feca199bd486653fea1d0e39cxdlangbjayglastmod'\xipermalink#Thttps://blog.johtani.info/blog/2012/02/21/lucene-gosen%E3%81%A8synonymfilter%E3%82%92%E5%88%A9%E7%94%A8%E3%81%99%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AE%E6%B3%A8%E6%84%8F%E7%82%B9%E5%95%8F%E9%A1%8C%E7%82%B9%E7%B7%A8/xkpublishdate Y2012-02-21T01:41:00+09:00xgsummary!H久々にlucene-gosenの話です。 しかも、あんまり嬉しくない話しです。 すでにissueをアップしていますが、lucene-gosenとwdtags1xpllucene-gosenxetitle vlucene-gosenとSynonymFilterを利用するときの注意点（問題点編）(Jugemより移植)vc344:yddate)2txcdirjpost/2012/xbid `fa16213d24273d386d22332cd01ce774xdlangbjayglastmod)2txipermalink#}https://blog.johtani.info/blog/2012/02/09/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/xkpublishdate Y2012-02-09T01:03:00+09:00xgsummary!Hまた、勉強会ログです、すみません。。。 直接業務とは関係ないのですが、今回はリクルートの中野さんが話しをされるというので顔を出してきました。 もwdtags1xpc勉強会xetitle vHadoopソースコードリーディング第8回に参加しました。#hadoopreading(Jugemより移植)vc345:yddate"dxcdirjpost/2012/xbid `a2679a7d860a0bfb2645809ed92ce138xdlangbjayglastmod"dxipermalink!~https://blog.johtani.info/blog/2012/02/05/fluentd-meetup-japan%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-02-05T00:03:00+09:00xgsummary!VFluentd meetup in Japanに参加しました。いつも面白そうな話を聞いてばっかりなので、役に立つためにスタッフとしても参加してみました。 まずは、会場が綺麗wdtags1xpc勉強会xetitle gFluentd Meetup Japanに参加しました。(Jugemより移植)vc346:yddateaxcdirjpost/2012/xbid `58e83fb33c120db338132d23b9112805xdlangbjayglastmodaxipermalink!shttps://blog.johtani.info/blog/2012/01/27/%E4%BB%8A%E8%88%88%E5%91%B3%E3%81%8C%E3%81%82%E3%82%8B%E3%81%93%E3%81%A8/xkpublishdate Y2012-01-27T01:50:41+09:00xgsummary!H昨年末に今年の抱負について書いたのですが、 他にも興味あるものが増えたので備忘録＆公約？を兼ねてブログに書いておきます。 （興味あるものがあればwdtags1xpc備忘録xetitle S今興味があること(Jugemより移植)vc347:yddateCxcdirjpost/2012/xbid `c6dc6e6567d673436ac41ebc8e79a9ecxdlangbjayglastmodCxipermalink"xhttps://blog.johtani.info/blog/2012/01/27/%E3%83%A2%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%8E%E3%83%AD%E3%82%B8%E3%83%BC2012-1%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-01-27T00:52:35+09:00xgsummary!~ということで、いつものように勉強会に参加したメモです。 http://atnd.org/events/23608 日時 :2012/01/26 19:00 to 22:00 会場 :アカデミーヒルズ(六本木ヒルズ内) 49階（タワーホールA） （港区六wdtags1xpc勉強会xetitle aモーショノロジー2012#1に参加しました。(Jugemより移植)vc348:yddate6Hxcdirjpost/2012/xbid `7198e10ebcf1bb88dc479b5c5b9f2c15xdlangbjayglastmod6Hxipermalink"[https://blog.johtani.info/blog/2012/01/20/mapr%E4%B8%AD%E8%BA%AB%E8%AA%AC%E6%98%8E%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-01-20T00:58:00+09:00xgsummary!m日時：2012/01/19 18:30-20:30 場所：ベルサール三田Room2シアター Inside MapR デモ＋内部のお話。 ・自己紹介 Susheel Kaushik 元YahooのHadoop系の人。製品wdtags1xpc勉強会xetitle \MapR中身説明会に参加しました。(Jugemより移植)vc349:yddate8@xcdirjpost/2012/xbid `a4462529ab493676987d946019a14945xdlangbjayglastmod8@xipermalink#Ihttps://blog.johtani.info/blog/2012/01/19/ossaj%E3%81%AE%E3%83%9F%E3%83%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%A7%E8%A9%B1%E3%81%97%E3%82%92%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-01-19T11:46:24+09:00xgsummary!Hお久しぶりです。インフルエンザで一家全滅という最悪の状況に陥っていた我が家でした。 流行してるみたいなのでみなさんも気をつけてください。 さて、wdtags1xpc勉強会xetitle aOSSAJのミニセミナーで話しをしてきました(Jugemより移植)vc350:yddate+|xcdirjpost/2012/xbid `f7df7b85af230b2623d3a827b0cbddd2xdlangbjayglastmod+|xipermalink"Vhttps://blog.johtani.info/blog/2012/01/08/lucene-gosen%E3%81%AElucene-solr4-0%E5%AF%BE%E5%BF%9C%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%9B%B4%E6%96%B0/xkpublishdate Y2012-01-08T23:41:00+09:00xgsummary!F先日のSolr勉強会でLucene/Solr4.x系のlucene-gosenについて質問を受けていたのを忘れないように（年越しちゃいましたwdtags1xpllucene-gosenxetitle nlucene-gosenのLucene/Solr4.0対応ブランチ更新(Jugemより移植)vc351:yddate
>Ixcdirjpost/2012/xbid `cc573488dec311655890a205aad4fb65xdlangbjayglastmod
>Ixipermalink#zhttps://blog.johtani.info/blog/2012/01/05/%E3%81%82%E3%81%91%E3%81%BE%E3%81%97%E3%81%A6%E3%81%8A%E3%82%81%E3%81%A7%E3%81%A8%E3%81%86%E3%81%94%E3%81%96%E3%81%84%E3%81%BE%E3%81%99%E4%BC%9A%E7%A4%BE%E3%81%AE%E3%83%96%E3%83%AD%E3%82%B0%E6%9B%B4%E6%96%B0/xkpublishdate Y2012-01-05T12:56:57+09:00xgsummary!Gあけましておめでとうございます。（もう5日ですが。。。） 今年もlucene-gosenを中心に色々と記事を書いていきますので、ツッコミ、コメwdtags1xpdmiscxetitle cあけましておめでとうございます＋会社のブログ更新(Jugemより移植)vc352:yddate>4Txcdirjpost/2011/xbid `7164823f504286e3a762ee612ff0a988xdlangbjayglastmod>4Txipermalink"`https://blog.johtani.info/blog/2011/12/28/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A0/xkpublishdate Y2011-12-28T02:15:00+09:00xgsummary!H他の方たちよりひと足はやいですが、今年の仕事が終わりました。 せっかくブログを始めたので、振り返りと来年の抱負など書いてみようかなと。 今年の振wdtags1xpdmiscxetitle Y今年の振り返りと来年の抱負？(Jugemより移植)vc353:yddate< 0\xcdirjpost/2011/xbid `da67e2f049b5b6babcf7906b85653399xdlangbjayglastmod< 0\xipermalink"{https://blog.johtani.info/blog/2011/12/22/%E7%AC%AC2-1%E5%9B%9E-twitter-api-%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%9D%B1%E4%BA%AC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-12-22T01:41:00+09:00xgsummary!H@yusukeyさんにサインをもらう目的で勉強会に参加してきました。前回もらいそびれたのでｗ 残念ながら、まだTwitter APIを触ってないwdtags1xpc勉強会xetitle l第2.1回 Twitter API 勉強会 @東京に参加しました。(Jugemより移植)vc354:yddate<=[xcdirjpost/2011/xbid `584b2b145f362098fc5fc1e634d57de5xdlangbjayglastmod<=[xipermalink!xhttps://blog.johtani.info/blog/2011/12/21/1-2-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-12-21T12:15:39+09:00xgsummary!Hlucene-gosenの最新版（1.2.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、特定文字列でwdtags1xpllucene-gosenxetitle X1.2.1リリースしました(Jugemより移植)vc355:yddate;6lxcdirjpost/2011/xbid `c6696a730f7498efb66f5ba3a8b35d08xdlangbjayglastmod;6lxipermalink#chttps://blog.johtani.info/blog/2011/12/20/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC%EF%BC%97%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F%E7%99%BA%E8%A1%A8%E3%82%82%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-12-20T01:21:00+09:00xgsummary!HいつものようにSolr勉強会に参加してきました。 皆勤賞を継続中です。（暇人というはなしも。。。） 今回は話しを聞きたいですねぇといったら、いやwdtags1xpc勉強会xetitle fSolr勉強会第７回に参加しました。（発表もしました）(Jugemより移植)vc3569yddate87Cxcdirjpost/2011/xbid `16fa0e4aefe18e1446bf6baefd3ba400xdlangbjayglastmod87Cxipermalink$`https://blog.johtani.info/blog/2011/12/11/%E7%AC%AC2%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-12-11T00:04:35+09:00xgsummary!Gということで、懲りずに#DSIRNLPに参加してきました。 基礎的な部分をおろそかにしたくないけど、TokyoNLPとかWebMiningではxetitle h第2回 データ構造と情報検索と言語処理勉強会に参加しました(Jugemより移植)vc357:yddate5%\xcdirjpost/2011/xbid `6e970d0818d58ff2d50c5bf037b1a565xdlangbjayglastmod5%\xipermalink%Chttps://blog.johtani.info/blog/2011/12/01/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%95%E3%81%A8mac-mini2009late%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E3%81%A8%E3%81%9D%E3%81%AE%E4%BB%96%E3%81%8F%E3%81%A0%E3%82%89%E3%81%AA%E3%81%84%E8%A9%B1/xkpublishdate Y2011-12-01T01:00:28+09:00xgsummary!Iひさびさに、MBAのお話です。 セットアップといっても、物理的な方ですね。 以前、ケース（カバー）について記載しました。 この記事にも書いてあったwdtags1xpc備忘録xetitle }MBAセットアップ備忘録その５とMac Mini（2009late）セットアップとその他くだらない話(Jugemより移植)vc358:yddate5\xcdirjpost/2011/xbid `0ebe78077c8b48410cf52a0bccdff866xdlangbjayglastmod5\xipermalink#qhttps://blog.johtani.info/blog/2011/11/29/%E3%81%A9%E3%82%93%E3%81%AA%E6%9C%AC%E3%81%A7%E3%82%82%E5%A4%A7%E9%87%8F%E3%81%AB%E8%AA%AD%E3%82%81%E3%82%8B%E9%80%9F%E8%AA%AD%E3%81%AE%E6%9C%AC%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-11-29T13:57:00+09:00xgsummary!Hどんな本でも大量に読める「速読」の本 Twitterで知り合った方がこの本について書かれていたブログ記事を読んで興味を持ち、読みました。 書籍（wdtags1xpb読書xetitle e「どんな本でも大量に読める「速読」の本」を読みました(Jugemより移植)vc359:yddate4;/txcdirjpost/2011/xbid `924727b6f380cf3cdfe5650163e92054xdlangbjayglastmod4;/txipermalink#ohttps://blog.johtani.info/blog/2011/11/29/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC7%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-11-29T01:51:00+09:00xgsummary!HHadoopソースコードリーディング第7回に参加しました。 いつものごとく、自分用のメモをとっていたので。 第6回（2010/12）には参加してwdtags1xpc勉強会xetitle hHadoopソースコードリーディング第7回に参加しました。(Jugemより移植)vc360:yddate3=`xcdirjpost/2011/xbid `26d48d68b28f927bfebad454658f9425xdlangbjayglastmod3=`xipermalink#Bhttps://blog.johtani.info/blog/2011/11/26/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AElucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0%E3%81%8B%E3%82%894%E7%AB%A0/xkpublishdate Y2011-11-26T03:00:00+09:00xgsummary!H先週末から勤労感謝の日まで風邪で寝こんでました。。。 みなさん、朝晩、冷え込みが激しいので風邪には気をつけてください。 季節の言葉も入れたので本wdtags1xpllucene-gosenxetitle v「Apache Solr入門」のサンプルのlucene-gosen対応（1章から4章）(Jugemより移植)vc361:yddate0)1pxcdirjpost/2011/xbid `bda9a5da86ec9790262e14f953bbadcbxdlangbjayglastmod0)1pxipermalink"hhttps://blog.johtani.info/blog/2011/11/16/mongodb%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC7%E5%9B%9E%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-11-16T02:08:00+09:00xgsummary!H今回は、触ろうと思って触れていないMongoDBの勉強会に行って来ました。 2週連続の渋谷で、さすがに今回は出口をすんなりでれました。 今回は初wdtags1xpc勉強会xetitle cMongoDB勉強会（第7回）に行って来ました。(Jugemより移植)vc362:yddate."pxcdirjpost/2011/xbid `cc1a3b2f107510ac664e491d5f2412aaxdlangbjayglastmod."pxipermalink"khttps://blog.johtani.info/blog/2011/11/09/splunk-live%E3%81%AE%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-11-09T16:00:00+09:00xgsummary!HSolr本の武田さんから教えていただいたSplunkの イベントに行って来ました。 Splunkとは様々な機器のログなどを一箇所に集めてリアルタwdtags1xpdmiscxetitle eSplunk Live!のイベントに行って来ました。(Jugemより移植)vc363:yddate.
+&txipermalink"lhttps://blog.johtani.info/blog/2012/03/27/%E9%87%8D%E8%A6%81lucene-gosen%E3%81%AE%E6%AC%A1%E6%9C%9F%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/xkpublishdate Y2012-03-27T02:39:00+09:00xgsummary!Hlucene-gosenを利用して頂いてる皆様に連絡があります。 連絡事項 次期lucene-gosenのリリース（2.0を予定）にて、org.wdtags1xpllucene-gosenxetitle f【重要】lucene-gosenの次期リリースについて(Jugemより移植)vc336:yddate"txcdirjpost/2012/xbid `8b76101d185700a8efed148d8722d926xdlangbjayglastmod"txipermalink!{https://blog.johtani.info/blog/2012/03/25/%E4%B9%85%E3%80%85%E3%81%ABmac-mini%E3%81%AE%E3%81%93%E3%81%A8%E3%81%A7%E3%82%82/xkpublishdate Y2012-03-25T04:47:00+09:00xgsummary!G子供の寝かしつけしてたら、寝かしつけされてしまって、２時に目が覚めてしまいました。 TSUTAYAでCD借りてきてウォークマンに入れようと思っwdtags1xpc備忘録xetitle [久々にMac Miniのことでも(Jugemより移植)vc337:yddate@xcdirjpost/2012/xbid `16b3c9445539e9274282a612dea354c2xdlangbjayglastmod@xipermalink"Dhttps://blog.johtani.info/blog/2012/03/22/%E7%AC%AC5%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%B8%8B%E8%B0%B7--twtr_hack/xkpublishdate Y2012-03-22T00:28:00+09:00xgsummary!Hはい。またまた、Twitter API勉強会に参加してきました。（今回から開催回数の記載がなくなった？） 今回は直前でタイムテーブルが変わってしwdtags1xpc勉強会xetitle l第5回 Twitter API勉強会 @渋谷 #twtr_hack(Jugemより移植)vc338:yddate	`xcdirjpost/2012/xbid `ee623aaa99b429863f89da313fffed97xdlangbjayglastmod	`xipermalink#hhttps://blog.johtani.info/blog/2012/03/20/%E8%87%AA%E5%88%86%E3%81%AE%E5%B0%8F%E3%81%95%E3%81%AA%E7%AE%B1%E3%81%8B%E3%82%89%E8%84%B1%E5%87%BA%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-03-20T23:32:00+09:00xgsummary!HTLで面白いと見かけて、Amazonで買ってしまいました。 SEやってるのに、つい最近Amazonを使い始めた軟弱者です。 それにしてもAmazwdtags1xpb読書xetitle e「自分の小さな「箱」から脱出する方法」を読みました。(Jugemより移植)vc339:yddate6Excdirjpost/2012/xbid `116c9be6d760b4befa6d51ce9e96604cxdlangbjayglastmod6Exipermalink!]https://blog.johtani.info/blog/2012/03/14/scala%E5%A7%8B%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-03-14T00:27:01+09:00xgsummary!Iえーと、ブログ更新してないなぁとふと思ったので。 １年前くらいからずーっと、つぶやいてましたが、やっとScalaを始めました。 長かった。。。 とwdtags1xpeScalaxetitle UScala始めました(Jugemより移植)vc340:yddatexxcdirjpost/2012/xbid `4d6c95b0b3ea2ddb30fdd3edf3b82391xdlangbjayglastmodxxipermalink"hhttps://blog.johtani.info/blog/2012/03/09/%E7%AC%AC0%E5%9B%9E-twitter-hack--twtr_hack-%E3%81%AB%E9%81%8A%E3%81%B3%E3%81%AB%E8%A1%8C%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-03-09T03:10:00+09:00xgsummary!H森ビルに行ったことなかったので、参加してみました。 あと、最近まともにコーディングしてないので、そのへんを矯正するためにもと思って。 （まぁ、遊wdtags1xpc勉強会xetitle q第0回 Twitter Hack #twtr_hack に遊びに行きました。(Jugemより移植)vc341:yddateHxcdirjpost/2012/xbid `10eb415a232ad4be7d05c57eb850036cxdlangbjayglastmodHxipermalink!Zhttps://blog.johtani.info/blog/2012/03/03/clean-coder%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A0/xkpublishdate Y2012-03-03T01:14:00+09:00xgsummary!XClean Coder プロフェッショナルプログラマへの道 Clean Coderを読みました。 理由はTwitterで「Clean Code」がいい本だと流れてきたためです。wdtags1xpb読書xetitle ZClean Coderを読んだ(Jugemより移植)vc342:yddate(pxcdirjpost/2012/xbid `627a0c45dd07150343c81d856855590exdlangbjayglastmod(pxipermalink#Nhttps://blog.johtani.info/blog/2012/02/26/%E8%A6%AA%E5%AD%90%E3%81%A7%E6%A5%BD%E3%81%97%E3%82%81%E3%82%8B-%E7%B5%B5%E6%9C%AC%E3%81%A7%E8%8B%B1%E8%AA%9E%E3%82%92%E3%81%AF%E3%81%98%E3%82%81%E3%82%8B%E6%9C%AC/xkpublishdate Y2012-02-26T01:20:00+09:00xgsummary!I親子で楽しめる 絵本で英語をはじめる本 Twitterでこの本について書かれたブログ記事が流れてきて、購入しました。 最近、英語を身につけておいたwdtags1xpb読書xetitle ^親子で楽しめる 絵本で英語をはじめる本(Jugemより移植)vc343:yddate&8xxcdirjpost/2012/xbid `966fe8d32b86121f8a465a21b95f7e5cxdlangbjayglastmod&8xxipermalink$Chttps://blog.johtani.info/blog/2012/02/24/%E7%AC%AC4%E5%9B%9E-twitter-api%E5%8B%89%E5%BC%B7%E4%BC%9A--%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E3%83%8F%E3%83%AA%E3%82%A6%E3%83%83%E3%83%89--twtr_hack-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-02-24T01:50:00+09:00xgsummary!Q今週も勉強会に参加しました。 @yusukey さんが開催してるTwitter API勉強会です。 前回とは会場が異なりましたが、広くて大画面で良い会場でした。駅wdtags1xpc勉強会xetitle |第4回 Twitter API勉強会 @デジタルハリウッド #twtr_hack に参加しました。(Jugemより移植)vc344:yddate'\xcdirjpost/2012/xbid `4e7b945feca199bd486653fea1d0e39cxdlangbjayglastmod'\xipermalink#Thttps://blog.johtani.info/blog/2012/02/21/lucene-gosen%E3%81%A8synonymfilter%E3%82%92%E5%88%A9%E7%94%A8%E3%81%99%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AE%E6%B3%A8%E6%84%8F%E7%82%B9%E5%95%8F%E9%A1%8C%E7%82%B9%E7%B7%A8/xkpublishdate Y2012-02-21T01:41:00+09:00xgsummary!H久々にlucene-gosenの話です。 しかも、あんまり嬉しくない話しです。 すでにissueをアップしていますが、lucene-gosenとwdtags1xpllucene-gosenxetitle vlucene-gosenとSynonymFilterを利用するときの注意点（問題点編）(Jugemより移植)vc345:yddate)2txcdirjpost/2012/xbid `fa16213d24273d386d22332cd01ce774xdlangbjayglastmod)2txipermalink#}https://blog.johtani.info/blog/2012/02/09/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hadoopreading/xkpublishdate Y2012-02-09T01:03:00+09:00xgsummary!Hまた、勉強会ログです、すみません。。。 直接業務とは関係ないのですが、今回はリクルートの中野さんが話しをされるというので顔を出してきました。 もwdtags1xpc勉強会xetitle vHadoopソースコードリーディング第8回に参加しました。#hadoopreading(Jugemより移植)vc346:yddate"dxcdirjpost/2012/xbid `a2679a7d860a0bfb2645809ed92ce138xdlangbjayglastmod"dxipermalink!~https://blog.johtani.info/blog/2012/02/05/fluentd-meetup-japan%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-02-05T00:03:00+09:00xgsummary!VFluentd meetup in Japanに参加しました。いつも面白そうな話を聞いてばっかりなので、役に立つためにスタッフとしても参加してみました。 まずは、会場が綺麗wdtags1xpc勉強会xetitle gFluentd Meetup Japanに参加しました。(Jugemより移植)vc347:yddateaxcdirjpost/2012/xbid `58e83fb33c120db338132d23b9112805xdlangbjayglastmodaxipermalink!shttps://blog.johtani.info/blog/2012/01/27/%E4%BB%8A%E8%88%88%E5%91%B3%E3%81%8C%E3%81%82%E3%82%8B%E3%81%93%E3%81%A8/xkpublishdate Y2012-01-27T01:50:41+09:00xgsummary!H昨年末に今年の抱負について書いたのですが、 他にも興味あるものが増えたので備忘録＆公約？を兼ねてブログに書いておきます。 （興味あるものがあればwdtags1xpc備忘録xetitle S今興味があること(Jugemより移植)vc348:yddateCxcdirjpost/2012/xbid `c6dc6e6567d673436ac41ebc8e79a9ecxdlangbjayglastmodCxipermalink"xhttps://blog.johtani.info/blog/2012/01/27/%E3%83%A2%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%8E%E3%83%AD%E3%82%B8%E3%83%BC2012-1%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-01-27T00:52:35+09:00xgsummary!~ということで、いつものように勉強会に参加したメモです。 http://atnd.org/events/23608 日時 :2012/01/26 19:00 to 22:00 会場 :アカデミーヒルズ(六本木ヒルズ内) 49階（タワーホールA） （港区六wdtags1xpc勉強会xetitle aモーショノロジー2012#1に参加しました。(Jugemより移植)vc349:yddate6Hxcdirjpost/2012/xbid `7198e10ebcf1bb88dc479b5c5b9f2c15xdlangbjayglastmod6Hxipermalink"[https://blog.johtani.info/blog/2012/01/20/mapr%E4%B8%AD%E8%BA%AB%E8%AA%AC%E6%98%8E%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-01-20T00:58:00+09:00xgsummary!m日時：2012/01/19 18:30-20:30 場所：ベルサール三田Room2シアター Inside MapR デモ＋内部のお話。 ・自己紹介 Susheel Kaushik 元YahooのHadoop系の人。製品wdtags1xpc勉強会xetitle \MapR中身説明会に参加しました。(Jugemより移植)vc350:yddate8@xcdirjpost/2012/xbid `a4462529ab493676987d946019a14945xdlangbjayglastmod8@xipermalink#Ihttps://blog.johtani.info/blog/2012/01/19/ossaj%E3%81%AE%E3%83%9F%E3%83%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%A7%E8%A9%B1%E3%81%97%E3%82%92%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2012-01-19T11:46:24+09:00xgsummary!Hお久しぶりです。インフルエンザで一家全滅という最悪の状況に陥っていた我が家でした。 流行してるみたいなのでみなさんも気をつけてください。 さて、wdtags1xpc勉強会xetitle aOSSAJのミニセミナーで話しをしてきました(Jugemより移植)vc351:yddate+|xcdirjpost/2012/xbid `f7df7b85af230b2623d3a827b0cbddd2xdlangbjayglastmod+|xipermalink"Vhttps://blog.johtani.info/blog/2012/01/08/lucene-gosen%E3%81%AElucene-solr4-0%E5%AF%BE%E5%BF%9C%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%9B%B4%E6%96%B0/xkpublishdate Y2012-01-08T23:41:00+09:00xgsummary!F先日のSolr勉強会でLucene/Solr4.x系のlucene-gosenについて質問を受けていたのを忘れないように（年越しちゃいましたwdtags1xpllucene-gosenxetitle nlucene-gosenのLucene/Solr4.0対応ブランチ更新(Jugemより移植)vc352:yddate
>Ixcdirjpost/2012/xbid `cc573488dec311655890a205aad4fb65xdlangbjayglastmod
>Ixipermalink#zhttps://blog.johtani.info/blog/2012/01/05/%E3%81%82%E3%81%91%E3%81%BE%E3%81%97%E3%81%A6%E3%81%8A%E3%82%81%E3%81%A7%E3%81%A8%E3%81%86%E3%81%94%E3%81%96%E3%81%84%E3%81%BE%E3%81%99%E4%BC%9A%E7%A4%BE%E3%81%AE%E3%83%96%E3%83%AD%E3%82%B0%E6%9B%B4%E6%96%B0/xkpublishdate Y2012-01-05T12:56:57+09:00xgsummary!Gあけましておめでとうございます。（もう5日ですが。。。） 今年もlucene-gosenを中心に色々と記事を書いていきますので、ツッコミ、コメwdtags1xpdmiscxetitle cあけましておめでとうございます＋会社のブログ更新(Jugemより移植)vc353:yddate>4Txcdirjpost/2011/xbid `7164823f504286e3a762ee612ff0a988xdlangbjayglastmod>4Txipermalink"`https://blog.johtani.info/blog/2011/12/28/%E4%BB%8A%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A%E3%81%A8%E6%9D%A5%E5%B9%B4%E3%81%AE%E6%8A%B1%E8%B2%A0/xkpublishdate Y2011-12-28T02:15:00+09:00xgsummary!H他の方たちよりひと足はやいですが、今年の仕事が終わりました。 せっかくブログを始めたので、振り返りと来年の抱負など書いてみようかなと。 今年の振wdtags1xpdmiscxetitle Y今年の振り返りと来年の抱負？(Jugemより移植)vc354:yddate< 0\xcdirjpost/2011/xbid `da67e2f049b5b6babcf7906b85653399xdlangbjayglastmod< 0\xipermalink"{https://blog.johtani.info/blog/2011/12/22/%E7%AC%AC2-1%E5%9B%9E-twitter-api-%E5%8B%89%E5%BC%B7%E4%BC%9A--%E6%9D%B1%E4%BA%AC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-12-22T01:41:00+09:00xgsummary!H@yusukeyさんにサインをもらう目的で勉強会に参加してきました。前回もらいそびれたのでｗ 残念ながら、まだTwitter APIを触ってないwdtags1xpc勉強会xetitle l第2.1回 Twitter API 勉強会 @東京に参加しました。(Jugemより移植)vc355:yddate<=[xcdirjpost/2011/xbid `584b2b145f362098fc5fc1e634d57de5xdlangbjayglastmod<=[xipermalink!xhttps://blog.johtani.info/blog/2011/12/21/1-2-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-12-21T12:15:39+09:00xgsummary!Hlucene-gosenの最新版（1.2.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、特定文字列でwdtags1xpllucene-gosenxetitle X1.2.1リリースしました(Jugemより移植)vc356:yddate;6lxcdirjpost/2011/xbid `c6696a730f7498efb66f5ba3a8b35d08xdlangbjayglastmod;6lxipermalink#chttps://blog.johtani.info/blog/2011/12/20/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC%EF%BC%97%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F%E7%99%BA%E8%A1%A8%E3%82%82%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-12-20T01:21:00+09:00xgsummary!HいつものようにSolr勉強会に参加してきました。 皆勤賞を継続中です。（暇人というはなしも。。。） 今回は話しを聞きたいですねぇといったら、いやwdtags1xpc勉強会xetitle fSolr勉強会第７回に参加しました。（発表もしました）(Jugemより移植)vc3579yddate87Cxcdirjpost/2011/xbid `16fa0e4aefe18e1446bf6baefd3ba400xdlangbjayglastmod87Cxipermalink$`https://blog.johtani.info/blog/2011/12/11/%E7%AC%AC2%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-12-11T00:04:35+09:00xgsummary!Gということで、懲りずに#DSIRNLPに参加してきました。 基礎的な部分をおろそかにしたくないけど、TokyoNLPとかWebMiningではxetitle h第2回 データ構造と情報検索と言語処理勉強会に参加しました(Jugemより移植)vc358:yddate5%\xcdirjpost/2011/xbid `6e970d0818d58ff2d50c5bf037b1a565xdlangbjayglastmod5%\xipermalink%Chttps://blog.johtani.info/blog/2011/12/01/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%95%E3%81%A8mac-mini2009late%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E3%81%A8%E3%81%9D%E3%81%AE%E4%BB%96%E3%81%8F%E3%81%A0%E3%82%89%E3%81%AA%E3%81%84%E8%A9%B1/xkpublishdate Y2011-12-01T01:00:28+09:00xgsummary!Iひさびさに、MBAのお話です。 セットアップといっても、物理的な方ですね。 以前、ケース（カバー）について記載しました。 この記事にも書いてあったwdtags1xpc備忘録xetitle }MBAセットアップ備忘録その５とMac Mini（2009late）セットアップとその他くだらない話(Jugemより移植)vc359:yddate5\xcdirjpost/2011/xbid `0ebe78077c8b48410cf52a0bccdff866xdlangbjayglastmod5\xipermalink#qhttps://blog.johtani.info/blog/2011/11/29/%E3%81%A9%E3%82%93%E3%81%AA%E6%9C%AC%E3%81%A7%E3%82%82%E5%A4%A7%E9%87%8F%E3%81%AB%E8%AA%AD%E3%82%81%E3%82%8B%E9%80%9F%E8%AA%AD%E3%81%AE%E6%9C%AC%E3%82%92%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-11-29T13:57:00+09:00xgsummary!Hどんな本でも大量に読める「速読」の本 Twitterで知り合った方がこの本について書かれていたブログ記事を読んで興味を持ち、読みました。 書籍（wdtags1xpb読書xetitle e「どんな本でも大量に読める「速読」の本」を読みました(Jugemより移植)vc360:yddate4;/txcdirjpost/2011/xbid `924727b6f380cf3cdfe5650163e92054xdlangbjayglastmod4;/txipermalink#ohttps://blog.johtani.info/blog/2011/11/29/hadoop%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E7%AC%AC7%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-11-29T01:51:00+09:00xgsummary!HHadoopソースコードリーディング第7回に参加しました。 いつものごとく、自分用のメモをとっていたので。 第6回（2010/12）には参加してwdtags1xpc勉強会xetitle hHadoopソースコードリーディング第7回に参加しました。(Jugemより移植)vc361:yddate3=`xcdirjpost/2011/xbid `26d48d68b28f927bfebad454658f9425xdlangbjayglastmod3=`xipermalink#Bhttps://blog.johtani.info/blog/2011/11/26/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AElucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0%E3%81%8B%E3%82%894%E7%AB%A0/xkpublishdate Y2011-11-26T03:00:00+09:00xgsummary!H先週末から勤労感謝の日まで風邪で寝こんでました。。。 みなさん、朝晩、冷え込みが激しいので風邪には気をつけてください。 季節の言葉も入れたので本wdtags1xpllucene-gosenxetitle v「Apache Solr入門」のサンプルのlucene-gosen対応（1章から4章）(Jugemより移植)vc362:yddate0)1pxcdirjpost/2011/xbid `bda9a5da86ec9790262e14f953bbadcbxdlangbjayglastmod0)1pxipermalink"hhttps://blog.johtani.info/blog/2011/11/16/mongodb%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC7%E5%9B%9E%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-11-16T02:08:00+09:00xgsummary!H今回は、触ろうと思って触れていないMongoDBの勉強会に行って来ました。 2週連続の渋谷で、さすがに今回は出口をすんなりでれました。 今回は初wdtags1xpc勉強会xetitle cMongoDB勉強会（第7回）に行って来ました。(Jugemより移植)vc363:yddate."pxcdirjpost/2011/xbid `cc1a3b2f107510ac664e491d5f2412aaxdlangbjayglastmod."pxipermalink"khttps://blog.johtani.info/blog/2011/11/09/splunk-live%E3%81%AE%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-11-09T16:00:00+09:00xgsummary!HSolr本の武田さんから教えていただいたSplunkの イベントに行って来ました。 Splunkとは様々な機器のログなどを一箇所に集めてリアルタwdtags1xpdmiscxetitle eSplunk Live!のイベントに行って来ました。(Jugemより移植)vc364:yddate.
 &xxcdirjpost/2011/xbid `d9c6ab5c6630a4a84e242c5765103d2dxdlangbjayglastmod.
-&xxipermalink"chttps://blog.johtani.info/blog/2011/11/08/lucene-eurocon-2011-barcelona-%E3%81%AE%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%89%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-11-08T13:02:00+09:00xgsummary!I最近忘れやすいので、記録しておこうかと。 読んだスライドの簡単な内容と感想です。 ちなみに、スライドの一覧はこちらです。 ※スライドへのリンクはすwdtags1xpdsolrxetitle sLucene Eurocon 2011 Barcelona のスライド読みました(Jugemより移植)vc364:yddate,$dxcdirjpost/2011/xbid `7a9609a971a8f31685e88da563eea5cexdlangbjayglastmod,$dxipermalink!{https://blog.johtani.info/blog/2011/11/02/bookscan%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-11-02T18:11:00+09:00xgsummary!HBookscanというサービスがあります。 書籍を電子化（PDF）して原本を破棄してくれるサービスです。 電子書籍にはずっと興味を持っていましたwdtags1xpdmiscxetitle [Bookscanを使ってみました(Jugemより移植)vc365:yddate+$hxcdirjpost/2011/xbid `14cf6e75aec1ead888e7101d3d94d28axdlangbjayglastmod+$hxipermalink!Thttps://blog.johtani.info/blog/2011/10/31/1-2-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/xkpublishdate Y2011-10-31T15:46:00+09:00xgsummary!Hlucene-gosenの最新版（1.2.0）をリリースしました。 プロジェクトページよりダウンロードが可能です。 新規追加機能についてはこちらwdtags1xpllucene-gosenxetitle T1.2.0リリース(Jugemより移植)vc366:yddate)-?Pxcdirjpost/2011/xbid `14a6d294550c9760aec57ba29682a750xdlangbjayglastmod)-?Pxipermalink"Jhttps://blog.johtani.info/blog/2011/10/26/%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%A4%96%E9%83%A8%E5%8C%96%E3%81%A8lucene-solr3-4%E5%AF%BE%E5%BF%9C/xkpublishdate Y2011-10-26T01:12:00+09:00xgsummary!Jすぐやりますと言いつつ、はや1ヶ月。。。 腰が重い、ダメエンジニアですね。。。 すみませんでした。。。 ようやくtrunkにコミットしました。 すぐwdtags1xpllucene-gosenxetitle b辞書の外部化とLucene/Solr3.4対応(Jugemより移植)vc367:yddate'#Kxcdirjpost/2011/xbid `5d827a1e8ea70edb11d946b54f076caexdlangbjayglastmod'#Kxipermalink"Nhttps://blog.johtani.info/blog/2011/10/18/jjug-ccc-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-10-18T16:20:43+09:00xgsummary!RJJUG CCC 2011 Fallに参加してきました。 個人的にはかなり久々のJavaのカンファレンスです。（※あくまで「Javaの」という話で。SolrやHadwdtags1xpc備忘録xetitle gJJUG CCC 2011 Fallに参加してきました。(Jugemより移植)vc368:yddate%lxcdirjpost/2011/xbid `b9d4f73fa7ca8ef66891554b66b2cdedxdlangbjayglastmod%lxipermalink#Yhttps://blog.johtani.info/blog/2011/10/12/lucene-gosen%E3%81%A7%E6%96%87%E7%AB%A0%E3%81%8B%E3%82%89%E3%82%AD%E3%83%BC%E3%83%AF%E3%83%BC%E3%83%89%E6%8A%BD%E5%87%BA%E3%82%A4%E3%83%AC%E3%82%AE%E3%83%A5%E3%83%A9%E3%83%BC/xkpublishdate Y2011-10-12T12:17:00+09:00xgsummary!G昨日、文章から特定の単語（リストあり）を探したいという話を聞き、lucene-gosenでもできるねぇという話になりました。 まぁ、考えてみれwdtags1xpllucene-gosenxetitle llucene-gosenで文章からキーワード抽出（イレギュラー？）(Jugemより移植)vc3699yddate#.;hxcdirjpost/2011/xbid `dc962e34780f0374b7eb3d583f6d7eb6xdlangbjayglastmod#.;hxipermalink"Mhttps://blog.johtani.info/blog/2011/10/07/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-1%E6%97%A5%E7%9B%AE/xkpublishdate Y2011-10-07T21:22:00+09:00xgsummary!Hちょっと間があいてしまったが、ようやくIoの1日目を終了。 なれない感じの言語なので苦労しました。 今回もセルフスタディの私の回答が最後の方に記xetitle _「7つの言語　7つの世界」 Io 1日目(Jugemより移植)vc370:yddate#),|xcdirjpost/2011/xbid `de1ab82817c0fb24e591b9a89a82f736xdlangbjayglastmod#),|xipermalink"Zhttps://blog.johtani.info/blog/2011/10/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%94/xkpublishdate Y2011-10-07T15:25:00+09:00xgsummary!I久々に、MBAの備忘録です。 あれから色々入れました。 なので、入れたソフトの一覧を追加。 AIR：TweetDeckをインストールするのに必要だwdtags1xpc備忘録xetitle ZMBAセットアップ備忘録その４(Jugemより移植)vc371:yddate#txcdirjpost/2011/xbid `09677934e13a5d728f00c6ed7c8870a9xdlangbjayglastmod#txipermalink"Mhttps://blog.johtani.info/blog/2011/10/05/solr%E3%81%AE%E6%96%B0%E3%81%97%E3%81%84%E7%AE%A1%E7%90%86%E7%94%BB%E9%9D%A2solr4-x-trunk%E7%B3%BB/xkpublishdate Y2011-10-05T19:43:00+09:00xgsummary!GLucene/SolrのMLでSolrの管理画面を新しくするというチケットが流れていたのでちょっと触って見ました。 ほんとにちょっと触っただけwdtags1xpdsolrxetitle gSolrの新しい管理画面（Solr4.x trunk系）(Jugemより移植)vc372:yddate"-
+&xxipermalink"chttps://blog.johtani.info/blog/2011/11/08/lucene-eurocon-2011-barcelona-%E3%81%AE%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%89%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-11-08T13:02:00+09:00xgsummary!I最近忘れやすいので、記録しておこうかと。 読んだスライドの簡単な内容と感想です。 ちなみに、スライドの一覧はこちらです。 ※スライドへのリンクはすwdtags1xpdsolrxetitle sLucene Eurocon 2011 Barcelona のスライド読みました(Jugemより移植)vc365:yddate,$dxcdirjpost/2011/xbid `7a9609a971a8f31685e88da563eea5cexdlangbjayglastmod,$dxipermalink!{https://blog.johtani.info/blog/2011/11/02/bookscan%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-11-02T18:11:00+09:00xgsummary!HBookscanというサービスがあります。 書籍を電子化（PDF）して原本を破棄してくれるサービスです。 電子書籍にはずっと興味を持っていましたwdtags1xpdmiscxetitle [Bookscanを使ってみました(Jugemより移植)vc366:yddate+$hxcdirjpost/2011/xbid `14cf6e75aec1ead888e7101d3d94d28axdlangbjayglastmod+$hxipermalink!Thttps://blog.johtani.info/blog/2011/10/31/1-2-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/xkpublishdate Y2011-10-31T15:46:00+09:00xgsummary!Hlucene-gosenの最新版（1.2.0）をリリースしました。 プロジェクトページよりダウンロードが可能です。 新規追加機能についてはこちらwdtags1xpllucene-gosenxetitle T1.2.0リリース(Jugemより移植)vc367:yddate)-?Pxcdirjpost/2011/xbid `14a6d294550c9760aec57ba29682a750xdlangbjayglastmod)-?Pxipermalink"Jhttps://blog.johtani.info/blog/2011/10/26/%E8%BE%9E%E6%9B%B8%E3%81%AE%E5%A4%96%E9%83%A8%E5%8C%96%E3%81%A8lucene-solr3-4%E5%AF%BE%E5%BF%9C/xkpublishdate Y2011-10-26T01:12:00+09:00xgsummary!Jすぐやりますと言いつつ、はや1ヶ月。。。 腰が重い、ダメエンジニアですね。。。 すみませんでした。。。 ようやくtrunkにコミットしました。 すぐwdtags1xpllucene-gosenxetitle b辞書の外部化とLucene/Solr3.4対応(Jugemより移植)vc368:yddate'#Kxcdirjpost/2011/xbid `5d827a1e8ea70edb11d946b54f076caexdlangbjayglastmod'#Kxipermalink"Nhttps://blog.johtani.info/blog/2011/10/18/jjug-ccc-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-10-18T16:20:43+09:00xgsummary!RJJUG CCC 2011 Fallに参加してきました。 個人的にはかなり久々のJavaのカンファレンスです。（※あくまで「Javaの」という話で。SolrやHadwdtags1xpc備忘録xetitle gJJUG CCC 2011 Fallに参加してきました。(Jugemより移植)vc369:yddate%lxcdirjpost/2011/xbid `b9d4f73fa7ca8ef66891554b66b2cdedxdlangbjayglastmod%lxipermalink#Yhttps://blog.johtani.info/blog/2011/10/12/lucene-gosen%E3%81%A7%E6%96%87%E7%AB%A0%E3%81%8B%E3%82%89%E3%82%AD%E3%83%BC%E3%83%AF%E3%83%BC%E3%83%89%E6%8A%BD%E5%87%BA%E3%82%A4%E3%83%AC%E3%82%AE%E3%83%A5%E3%83%A9%E3%83%BC/xkpublishdate Y2011-10-12T12:17:00+09:00xgsummary!G昨日、文章から特定の単語（リストあり）を探したいという話を聞き、lucene-gosenでもできるねぇという話になりました。 まぁ、考えてみれwdtags1xpllucene-gosenxetitle llucene-gosenで文章からキーワード抽出（イレギュラー？）(Jugemより移植)vc3709yddate#.;hxcdirjpost/2011/xbid `dc962e34780f0374b7eb3d583f6d7eb6xdlangbjayglastmod#.;hxipermalink"Mhttps://blog.johtani.info/blog/2011/10/07/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-1%E6%97%A5%E7%9B%AE/xkpublishdate Y2011-10-07T21:22:00+09:00xgsummary!Hちょっと間があいてしまったが、ようやくIoの1日目を終了。 なれない感じの言語なので苦労しました。 今回もセルフスタディの私の回答が最後の方に記xetitle _「7つの言語　7つの世界」 Io 1日目(Jugemより移植)vc371:yddate#),|xcdirjpost/2011/xbid `de1ab82817c0fb24e591b9a89a82f736xdlangbjayglastmod#),|xipermalink"Zhttps://blog.johtani.info/blog/2011/10/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%94/xkpublishdate Y2011-10-07T15:25:00+09:00xgsummary!I久々に、MBAの備忘録です。 あれから色々入れました。 なので、入れたソフトの一覧を追加。 AIR：TweetDeckをインストールするのに必要だwdtags1xpc備忘録xetitle ZMBAセットアップ備忘録その４(Jugemより移植)vc372:yddate#txcdirjpost/2011/xbid `09677934e13a5d728f00c6ed7c8870a9xdlangbjayglastmod#txipermalink"Mhttps://blog.johtani.info/blog/2011/10/05/solr%E3%81%AE%E6%96%B0%E3%81%97%E3%81%84%E7%AE%A1%E7%90%86%E7%94%BB%E9%9D%A2solr4-x-trunk%E7%B3%BB/xkpublishdate Y2011-10-05T19:43:00+09:00xgsummary!GLucene/SolrのMLでSolrの管理画面を新しくするというチケットが流れていたのでちょっと触って見ました。 ほんとにちょっと触っただけwdtags1xpdsolrxetitle gSolrの新しい管理画面（Solr4.x trunk系）(Jugemより移植)vc373:yddate"-
 Pxcdirjpost/2011/xbid `7052598d2355984237d126afea2f6e88xdlangbjayglastmod"-
-Pxipermalink!mhttps://blog.johtani.info/blog/2011/10/04/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE2/xkpublishdate Y2011-10-04T18:32:00+09:00xgsummary!H遅くなりましたが、続きです。 さらに英語力のなさを痛感して凹んでいるところですが、何かの役に立てばと恥を晒すところです。。。 一応、訳してみたのwdtags1xpdsolrxetitle gNew SolrCloud Designの翻訳（その2）(Jugemより移植)vc373:yddate 0"|xcdirjpost/2011/xbid `927612b57ba01ca878b2d7edce52a563xdlangbjayglastmod 0"|xipermalink!uhttps://blog.johtani.info/blog/2011/09/28/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE%EF%BC%91/xkpublishdate Y2011-09-28T20:45:00+09:00xgsummary!Gちょっと興味があるので、訳してみました。（Wikiのページはこちら） 更新されているようなので、もとの文章も残しておきます。（ページ下部の続きwdtags1xpdsolrxetitle gNew SolrCloud Designの翻訳（その１）(Jugemより移植)vc374:yddate 9txcdirjpost/2011/xbid `97402287d8c6c03f0b63848e17e9d944xdlangbjayglastmod 9txipermalink"]https://blog.johtani.info/blog/2011/09/27/hadoop-conference-japan-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-09-27T17:51:00+09:00xgsummary!`Hadoop Conference Japan 2011 Fallに行ってきました。 まずは、ユーザ会の方々、運営の方々、発表された方々お疲れ様でした。こんな機会を用意していただき、ありがとうwdtags1xpfhadoopxetitle vHadoop Conference Japan 2011 Fallに参加してきました。(Jugemより移植)vc375:yddate7>Xxcdirjpost/2011/xbid `62f31128a21b0e240bdb7b3d5b121c04xdlangbjayglastmod7>Xxipermalink"Mhttps://blog.johtani.info/blog/2011/09/23/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-0%E6%97%A5%E7%9B%AE/xkpublishdate Y2011-09-23T03:34:00+09:00xgsummary!G台風15号すごかったですね。幸いにも（？）夏休みだったので、通勤などでひどい目に合わずにすみました。 風雨はすごくてちょっと怖かったですが。。wdtags1xpb読書xetitle _「7つの言語　7つの世界」 Io 0日目(Jugemより移植)vc376:yddateDxcdirjpost/2011/xbid `54da1b916f49ef40c822fab61d37cf66xdlangbjayglastmodDxipermalink!phttps://blog.johtani.info/blog/2011/09/15/lucene-solr-3-4%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/xkpublishdate Y2011-09-15T09:31:00+09:00xgsummary!USolr/Lucene 3.4がリリースされました。（速報） 以下、各サイトへのリンクです。 Solrリリースのお知らせ Luceneリリースのお知らせ ちなみに、先日のwdtags1xpdsolrxetitle bLucene/Solr 3.4リリース（速報）(Jugemより移植)vc377:yddate|xcdirjpost/2011/xbid `41b811063b9425de1934e77d89118022xdlangbjayglastmod|xipermalink"jhttps://blog.johtani.info/blog/2011/09/14/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-3%E6%97%A5%E7%9B%AE%E6%9C%80%E7%B5%82%E6%97%A5/xkpublishdate Y2011-09-14T18:21:00+09:00xgsummary!Hということで、Rubyの最終日の感想。 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大wdtags1xpb読書xetitle f「7つの言語　7つの世界」 Ruby 3日目（最終日）(Jugemより移植)vc378:yddate:dxcdirjpost/2011/xbid `37b622eaad1f79e759a722aacebf48ecxdlangbjayglastmod:dxipermalink"\https://blog.johtani.info/blog/2011/09/12/%E7%AC%AC6%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-09-12T16:03:00+09:00xgsummary!I「第6回Solr勉強会」に参加しました。 なんだかんだと第6回で、今のところ皆勤賞です。 ということで、主に自分用ですが、メモなどとったので。 概wdtags1xpc勉強会xetitle ]第6回Solr勉強会に参加しました。(Jugemより移植)vc379:yddate$"dxcdirjpost/2011/xbid `73262345214f9b7794f2cc4a612b15e8xdlangbjayglastmod$"dxipermalink"Ohttps://blog.johtani.info/blog/2011/09/10/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-2%E6%97%A5%E7%9B%AE/xkpublishdate Y2011-09-10T02:11:00+09:00xgsummary!Gということで、Ruby2日目の感想（2日目だけで2日間かかったのは内緒。。。） 今回もセルフスタディの私の回答が最後の方に記載されてます。見たwdtags1xpb読書xetitle a「7つの言語　7つの世界」 Ruby 2日目(Jugemより移植)vc380:yddate`xcdirjpost/2011/xbid `9baedcd033169611a42c3cfd58b3ae03xdlangbjayglastmod`xipermalink"Ohttps://blog.johtani.info/blog/2011/09/09/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-1%E6%97%A5%E7%9B%AE/xkpublishdate Y2011-09-09T14:12:00+09:00xgsummary!H実に3年ぶりくらいにゆっくりできる日々が訪れたので、積読状態の本を消化しようと「7つの言語 7つの世界」を読み始めました。 せっかくブログも始めwdtags1xpb読書xetitle a「7つの言語　7つの世界」 Ruby 1日目(Jugemより移植)vc381:yddate%Hxcdirjpost/2011/xbid `f23ca2aa066b1ee0fa4df1f2f865be4cxdlangbjayglastmod%Hxipermalink"Zhttps://blog.johtani.info/blog/2011/09/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%93/xkpublishdate Y2011-09-07T02:18:00+09:00xgsummary!G現在の出先でMBAを使えないので、なかなか進んでいないMBAのセットアップです。。。 とりあえず、Eclipse、homebrewをインストーwdtags1xpc備忘録xetitle ZMBAセットアップ備忘録その３(Jugemより移植)vc382:yddate%|xcdirjpost/2011/xbid `3c2523e65ff953fd73579aaaf5d7ce36xdlangbjayglastmod%|xipermalink#Mhttps://blog.johtani.info/blog/2011/09/07/%E8%BE%9E%E6%9B%B8%E5%88%86%E9%9B%A2%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E3%82%B1%E3%83%BC%E3%82%B9%E8%BF%BD%E5%8A%A0%E3%81%A8%E6%AE%8B%E3%82%BF%E3%82%B9%E3%82%AF/xkpublishdate Y2011-09-07T01:56:28+09:00xgsummary!Hすぐにテストケース追加しますといいつつ、はや一週間。 ようやく仕事が落ち着いたので、テストケースを追記しました。まだパッチの段階です。 一応、異wdtags1xpllucene-gosenxetitle ]辞書分離のテストケース追加と残タスク(Jugemより移植)vc383:yddate8Hxcdirjpost/2011/xbid `88a8e608108be939da9aab5a9a8af7d1xdlangbjayglastmod8Hxipermalink"ihttps://blog.johtani.info/blog/2011/08/30/%E8%A4%87%E6%95%B0%E8%BE%9E%E6%9B%B8%E3%81%AE%E8%AA%AD%E3%81%BF%E8%BE%BC%E3%81%BF%E6%A9%9F%E8%83%BD%E8%BF%BD%E5%8A%A0%E4%BB%AE/xkpublishdate Y2011-08-30T10:34:00+09:00xgsummary!G先日、辞書のjarファイルからの分離についてパッチと記事を書きました。 IssueにあげていたパッチをRobertさんが見ていたらしく、次のよwdtags1xpllucene-gosenxetitle [複数辞書の読み込み機能追加（仮）(Jugemより移植)vc384:yddate0hxcdirjpost/2011/xbid `2f1ec795216d5bafa33a810af3421942xdlangbjayglastmod0hxipermalink"Zhttps://blog.johtani.info/blog/2011/08/23/%E8%BE%9E%E6%9B%B8%E3%81%AEjar%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%8B%E3%82%89%E3%81%AE%E5%88%86%E9%9B%A2/xkpublishdate Y2011-08-23T10:26:00+09:00xgsummary!Gひさびさに、lucene-gosenの話題です。 lucene-gosenはjarファイルに辞書も同梱されており、jarファイルをクラスパスにwdtags1xpllucene-gosenxetitle Z辞書のjarファイルからの分離(Jugemより移植)vc385:yddate5txcdirjpost/2011/xbid `ce0aea06d44878b4a373efe090a66a62xdlangbjayglastmod5txipermalink"Zhttps://blog.johtani.info/blog/2011/08/15/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%92/xkpublishdate Y2011-08-15T09:51:00+09:00xgsummary!Hすみません、また、MBA関連の記事になってしまいました。 ということで、備忘録その２です。 前回からいくつかインストールや環境の設定をしたので、wdtags1xpc備忘録xetitle ZMBAセットアップ備忘録その２(Jugemより移植)vc386:yddatexxcdirjpost/2011/xbid `c0e423f9ac41cc5b265c95a3e97e3fcbxdlangbjayglastmodxxipermalink!https://blog.johtani.info/blog/2011/08/10/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2/xkpublishdate Y2011-08-10T00:46:00+09:00xgsummary!^Mac Book Airのセットアップ関連の備忘録 （今回は備忘録なので、文体も変かも） インストールしたもの（順不同）だいたい、このサイトを参考にした。 Evernote Dropboxwdtags1xpc備忘録xetitle WMBAセットアップ備忘録(Jugemより移植)vc387:yddate!xxcdirjpost/2011/xbid `7ed1d2efa3e0f0ed6b77eb4eff3d86b3xdlangbjayglastmod!xxipermalink!xhttps://blog.johtani.info/blog/2011/08/04/apple%E6%95%99%E3%81%AB%E5%85%A5%E4%BF%A1%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-08-04T01:34:00+09:00xgsummary!H個人用のPCを８年ぶりに新調しました。 前回購入した家のデスクトップPCがもう８年ものになりつつあるということで、 さすがに今年はPCを買おうとwdtags1xpc備忘録xetitle XApple教に入信しました(Jugemより移植)vc388:yddate8lxcdirjpost/2011/xbid `3811b40721f7ca651887aac4eb17f9f0xdlangbjayglastmod8lxipermalink$`https://blog.johtani.info/blog/2011/07/27/%E7%AC%AC1%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-07-27T12:33:00+09:00xgsummary!Iかなり遅くなりましたが、第1回 データ構造と情報検索と言語処理勉強会 #DSIRNLPに参加しました。 帰ってから２日半ほど寝込んでしまい、更新がwdtags1xpc勉強会xetitle i第1回 データ構造と情報検索と言語処理勉強会に参加しました。(Jugemより移植)vc389:yddate	$-|xcdirjpost/2011/xbid `5a765f9668608a39333fa90cf462657exdlangbjayglastmod	$-|xipermalink!ihttps://blog.johtani.info/blog/2011/07/20/kuromoji%E3%82%92%E8%AA%BF%E3%81%B9%E3%81%A6%E3%81%BF%E3%81%9F/xkpublishdate Y2011-07-20T12:29:00+09:00xgsummary!G以前から春山さんのブログ（リンク）や勉強会で耳にはしていたのですがソースは読んでいませんでした。 先日、Luceneにcontributeされwdtags1xpe形態素解析xetitle YKuromojiを調べてみた(Jugemより移植)vc390:yddate97xxcdirjpost/2011/xbid `c70b78fd0b5dffcd38322355e9c2471exdlangbjayglastmod97xxipermalink"nhttps://blog.johtani.info/blog/2011/07/12/naist-jdic-for-mecab%E3%81%AEpreprocessor%E3%81%AE%E5%AE%9F%E8%A3%85%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E5%82%99%E5%BF%98%E9%8C%B2/xkpublishdate Y2011-07-12T10:06:00+09:00xgsummary!H忘れてしまうので、備忘録を残しておきます。 一応、ソースには少しずつコメントをいれてはいるのですが。 私は残念ながら、自然言語処理は初心者に毛がwdtags1xpllucene-gosenxetitle vNAIST-JDic for MeCabのPreprocessorの実装に関する備忘録(Jugemより移植)vc391:yddate5Xxcdirjpost/2011/xbid `229975f1e84b5088e819cd5f2dc43080xdlangbjayglastmod5Xxipermalink!ahttps://blog.johtani.info/blog/2011/07/04/lucene-gosen-1-1-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/xkpublishdate Y2011-07-04T20:00:40+09:00xgsummary!Hlucene-gosen 1.1.1をリリースしました。 先日お知らせしたバグ修正を取り込んだjarを用意いしました。 ダウンロードはこちらからwdtags1xpllucene-gosenxetitle alucene-gosen 1.1.1リリース(Jugemより移植)vc392:yddate%Sxcdirjpost/2011/xbid `10eb1e7dc64d8ca3dad92641dadb5de7xdlangbjayglastmod%Sxipermalink!phttps://blog.johtani.info/blog/2011/07/01/lucene-solr-3-3%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/xkpublishdate Y2011-07-01T15:29:39+09:00xgsummary!USolr/Lucene 3.3がリリースされました。（速報） 以下、各サイトへのリンクです。 Solrリリースのお知らせ Luceneリリースのお知らせ リリースのタイミwdtags1xpdsolrxetitle bLucene/Solr 3.3リリース（速報）(Jugemより移植)vc393:yddate3xxcdirjpost/2011/xbid `49ba23148db9effdc3979aa0fe5876eaxdlangbjayglastmod3xxipermalink&https://blog.johtani.info/blog/2011/06/29/hadoop%E3%82%92%E4%B8%AD%E5%BF%83%E3%81%A8%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E7%92%B0%E5%A2%83%E3%81%A7%E3%81%AE%E9%96%8B%E7%99%BA%E6%96%B9%E6%B3%95%E8%AB%96%E3%83%A2%E3%83%87%E3%83%AA%E3%83%B3%E3%82%B0%E8%A8%AD%E8%A8%88%E6%89%8B%E6%B3%95%E7%AD%89%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E5%BA%A7%E8%AB%87%E4%BC%9A-%E7%AC%AC5%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-06-29T23:10:00+09:00xgsummary!F「Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）」に参加しました。300名入るイベントルーwdtags1xpfhadoopxetitle!CHadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）に参加しました。(Jugemより移植)vc394:yddate0`xcdirjpost/2011/xbid `f6dff70097776e24c2a7c9c0f2514f79xdlangbjayglastmod0`xipermalink!xhttps://blog.johtani.info/blog/2011/06/28/compositeposcompositetokenfilter%E3%81%AE%E3%83%90%E3%82%B0%E4%BF%AE%E6%AD%A3/xkpublishdate Y2011-06-28T12:36:00+09:00xgsummary!G以前、こちらで話題に上がっていた「未知語」に関するcompositePOSのエラーの件を調査しました。（Twitterでも流れてました。） 次wdtags1xpllucene-gosenxetitle rcompositePOS（CompositeTokenFilter）のバグ修正(Jugemより移植)vc395:yddate
?</Hxcdirjpost/2011/xbid `991285e3967c3295b4ff2dcd835f7c61xdlangbjayglastmod
?</Hxipermalink!uhttps://blog.johtani.info/blog/2011/06/21/naist-jdic-for-mecab%E5%AF%BE%E5%BF%9C%E7%89%88%E4%BB%AE%E5%AE%9F%E8%A3%85/xkpublishdate Y2011-06-21T07:38:00+09:00xgsummary!Jlucene-gosenのtrunkbranches/impl-mecab-dicにNAIST-JDic for MeCabの辞書を利用出来るPrewdtags1xpllucene-gosenxetitle gNAIST-JDic for MeCab対応版（仮実装）(Jugemより移植)vc396:yddate
="pxcdirjpost/2011/xbid `50f43b1726cf61066ef8656477b226bexdlangbjayglastmod
="pxipermalink#Jhttps://blog.johtani.info/blog/2011/06/14/compositepos%E3%81%AE%E5%88%A9%E7%94%A8%E4%BE%8Bnaist-chasen%E3%81%A7%E3%81%AE%E8%8B%B1%E5%8D%98%E8%AA%9E%E3%81%AE%E5%87%BA%E5%8A%9B%E6%96%B9%E6%B3%95%E4%BE%8B/xkpublishdate Y2011-06-14T00:00:00+09:00xgsummary!G前回、naist-chasenではアルファベットが別々の単語としてanalyzeされてしまうという話をしました。 ただ、これだと、英単語が含まwdtags1xpllucene-gosenxetitle tcompositePOSの利用例（naist-chasenでの英単語の出力方法例）(Jugemより移植)vc397:yddate
=<Pxcdirjpost/2011/xbid `eeef60efe889349870426d10edc694bexdlangbjayglastmod
=<Pxipermalink!bhttps://blog.johtani.info/blog/2011/06/13/lucene-gosen-1-1-0-%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/xkpublishdate Y2011-06-13T12:08:00+09:00xgsummary!Glucene-gosenの1.1.0がリリースされました。 大きな目玉はJapaneseTokenizerが出力する形態素に関するデータを遅延wdtags1xpllucene-gosenxetitle blucene-gosen 1.1.0 リリース(Jugemより移植)vc398:yddate
;
Txcdirjpost/2011/xbid `4b046ac6a4796fb1338f0481dbd4003dxdlangbjayglastmod
;
Txipermalink!]https://blog.johtani.info/blog/2011/06/06/lucene-gosen%E3%81%AEtokenfilter%E3%81%9F%E3%81%A1/xkpublishdate Y2011-06-06T16:23:00+09:00xgsummary!Flucene-gosenをSolr/Luceneで利用する場合、TokenFilterを利用してTokenizerが出力したToken対してwdtags1xpllucene-gosenxetitle elucene-gosenのTokenFilterたち(Jugemより移植)vc399:yddate
94@xcdirjpost/2011/xbid `b2621497b3313c97855ed951f0d9b291xdlangbjayglastmod
94@xipermalink"`https://blog.johtani.info/blog/2011/06/02/%E8%BE%9E%E6%9B%B8%E3%81%A8%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E8%BE%9E%E6%9B%B8%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/xkpublishdate Y2011-06-02T17:16:00+09:00xgsummary!J辞書の特性について 現在lucene-gosenでは以下の2つの辞書が利用可能です。 簡単に違いについて説明します。 IPAdicの辞書について バwdtags1xpllucene-gosenxetitle X辞書とカスタム辞書について(Jugemより移植)vc400:yddate
7!
xxcdirjpost/2011/xbid `ff1441a42144a7de9a3eaf9f5e7cfea9xdlangbjayglastmod
7!
xxipermalink"Whttps://blog.johtani.info/blog/2011/05/26/%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%8B%E3%82%89%E3%81%AE%E3%83%93%E3%83%AB%E3%83%89%E3%81%A8%E6%A7%8B%E6%88%90/xkpublishdate Y2011-05-26T17:34:00+09:00xgsummary!G今回はソースのダウンロードとビルドについてです。 最新版のソースを利用したり、JavaDocを見たい場合はソースをダウンロードしてからビルドすwdtags1xpllucene-gosenxetitle Wソースからのビルドと構成(Jugemより移植)vc401:yddate
6`xcdirjpost/2011/xbid `5988b62a0c0785a303b77c74608e8b55xdlangbjayglastmod
6`xipermalink!Ihttps://blog.johtani.info/blog/2011/05/23/lucene-gosen%E3%81%A8%E3%81%AF/xkpublishdate Y2011-05-23T15:00:00+09:00xgsummary!J概要： Lucene/SolrのコミッターであるRobert Muirさんが始めたプロジェクト 歴史： MeCabのJava移植版としてスタートしたwdtags1xpllucene-gosenxetitle Ylucene-gosenとは(Jugemより移植)vc402:yddate
5pxcdirjpost/2011/xbid `94b85ba716dbb7c20b230e69248b8208xdlangbjayglastmod
5pxipermalink!shttps://blog.johtani.info/blog/2011/05/20/%E3%83%96%E3%83%AD%E3%82%B0%E3%81%AF%E3%81%98%E3%82%81%E3%81%BE%E3%81%99/xkpublishdate Y2011-05-20T11:44:00+09:00xgsummary!H今さらですが、ブログをはじめてみようかと。今さらですが… はじめてみようと思った一番の理由は、自分で調べたことをメモがわりに残すためです。 あとwdtags1xpdmiscxetitle Sブログはじめます(Jugemより移植)>yecountRvgsorting6xhlanguagegenglishw RsortableProperties4xpbidetitlegsummaryddatev [sortablePropertiesWithTypes4xbidfstringxetitlefstringxgsummaryfstringxddatefnumbervesorts4vbid3vddocs<ya1Mya2iya3ya4Gya5Zya6Jya7zya8nya9Xyb10}yb11`yb12cyb13`yb14^yb15hyb16nyb17[yb18eyb19Ryb20wyb21Byb22Tyb23Byb24Vyb25Qyb26{yb27wyb28Eyb29Uyb30Ryb31Lyb32fyb33@yb34}yb35yb36lyb37Nyb38byb39Iyb40Oyb41oyb42Yyb43Cyb44oyb45Ayb46Lyb47kyb48^yb49eyb50byb51Oyb52Ayb53Myb54_yb55kyb56Cyb57Xyb58xyb59yyb60hyb61Uyb62Syb63Nyb64jyb65dyb66Wyb67|yb68Pyb69uyb70Yyb71^yb72Lyb73gyb74wyb75[yb76`yb77yb78ryb79Wyb80{yb81eyb82Yyb83`yb84Jyb85Gyb86jyb87tyb88dyb89Hyb90jyb91Tyb92vyb93dyb94yb95\yb96Iyb97lyb98Nyb99pyc100Qyc101Eyc102^yc103Vyc104nyc105Lyc106|yc107oyc108ryc109cyc110{yc111Yyc112Kyc113Qyc114@yc115Nyc116byc117syc118Tyc119byc120Fyc121Syc122Tyc123Wyc124Jyc125iyc126Vyc127Fyc128@yc129pyc130Ayc131{yc132Kyc133byc134zyc135Jyc136hyc137Pyc138Cyc139Dyc140fyc141myc142jyc143ayc144ryc145iyc146Lyc147pyc148Nyc149Iyc150ayc151Ryc152byc153{yc154uyc155syc156^yc157qyc158Oyc159oyc160Pyc161Kyc162Zyc163qyc164Iyc165vyc166lyc167[yc168Dyc169ryc170@yc171Uyc172Xyc173kyc174Eyc175Ayc176myc177@yc178uyc179zyc180tyc181\yc182Pyc183nyc184wyc185Qyc186Oyc187Pyc188wyc189Dyc190Xyc191gyc192Uyc193nyc194syc195Myc196[yc197xyc198dyc199Kyc200Dyc201Wyc202oyc203Oyc204hyc205xyc206xyc207Zyc208Cyc209Myc210\yc211fyc212}yc213cyc214]yc215Ryc216Byc217gyc218lyc219^yc220oyc221Gyc222eyc223}yc224tyc225Iyc226]yc227`yc228Gyc229Zyc230Jyc231[yc232tyc233Ayc234yc235syc236kyc237Eyc238hyc239cyc240Xyc241Tyc242ayc243vyc244{yc245Pyc246~yc247\yc248\yc249|yc250yyc251Qyc252Syc253uyc254cyc255Eyc256}yc257Jyc258\yc259Tyc260}yc261Ryc262Myc263qyc264|yc265]yc266Hyc267myc268Byc269Syc270yyc271gyc272Byc273~yc274vyc275dyc276|yc277kyc278iyc279Vyc280Zyc281Uyc282Hyc283qyc284Xyc285tyc286pyc287Cyc288Dyc289Ayc290Kyc291]yc292Qyc293xyc294lyc295tyc296myc297Qyc298ayc299Eyc300jyc301_yc302eyc303Ryc304syc305vyc306Tyc307Hyc308_yc309syc310Yyc311Uyc312zyc313Cyc314wyc315ayc316Fyc317pyc318zyc319xyc320]yc321Qyc322_yc323|yc324fyc325fyc326ryc327[yc328Iyc329[yc330\yc331Fyc332qyc333Wyc334Hyc335Vyc336gyc337ryc338Wyc339vyc340Vyc341Vyc342gyc343yyc344Lyc345yc346Hyc347nyc348iyc349@yc350Gyc351zyc352hyc353Syc354Gyc355myc356jyc357cyc358_yc359`yc360Dyc361Yyc362yyc363Ryc364~yc365_yc366^yc367Syc368Syc369Xyc370]yc371Zyc372fyc373ayc374iyc375Wyc376Byc377dyc378Yyc379myc380uyc381yyc382]yc383Pyc384Oyc385~yc386_yc387Fyc388Zyc389Nyc390pyc391~yc392Uyc393lyc394Fyc395kyc396~yc397uyc398qyc399Myc400Pyc401Kyc402e>wkorderedDocs<w2ypIAxp `002d980d74d19b43ff4e2446665e2fe52dA `018b365b00dd3a6ad17c813d215905492WA `018e32a8010960eb17e368a6fdd5a51b2|A `0302e8a57a5e8604342a925b2dc607372zA `04d818cbaac08b2915db15e0bffdcb5b2@A `05330c3703d0e2c96cfe657ab33f130c2XA `0645bdb1cdf88ec74288d503eb71839c2MA `06731164684f90f33ce4017eca9d8ec12YA `086b4fd5f77021a0a2aa6b0e900614862FA `09155bf417a93847b538ad607f78cca22sA `09677934e13a5d728f00c6ed7c8870a92DA `0a8183ced0e9e3e895b41286e54e8e4d2RA `0c1821d1069578551d0e3c7d9275f16b2@A `0dcb6d0f17794bbca56b6cdb9e20b9322\A `0de0edbf2a506143c1739b12e94c0ef92fA `0ebe78077c8b48410cf52a0bccdff8662`A `100c0a69bea7f02a0f4540ecaa37d0e32YA `104b8ee17a8bf1f7043d2366596804932^A `10a7f69bd03d2632722300194f01e93d2yA `10ae016e19fff6ae9cfaeb8534fa47f92qA `10c715f70de25ccb493bbbb532b78ced2HA `10eb1e7dc64d8ca3dad92641dadb5de72TA `10eb415a232ad4be7d05c57eb850036c2RA `116c9be6d760b4befa6d51ce9e96604c2yA `11a61827e80739a6065960eb188d57582oA `11b3a28b536f34d3606427f835bd3ddf2XA `11d4726484be418849e1f4200ade95352GA `12d1e0cf7396dd33a9bbbca8da4cbc682wA `13684d16fdd07d5f0584e29265a270e72IA `146e8ca40c0d37f36eecea822028dd9e2nA `14a6d294550c9760aec57ba29682a7502mA `14cf6e75aec1ead888e7101d3d94d28a2LA `15357b6978e83daa2d97692c861dc1772VA `15700442e957951307bbcec5fff8643d2rA `15932a656f7acfac897d27766eadc9e22oA `15f501351d482ffd73985a50f5c89d1f2AA `163beeae9620c1a6a46a38aa7ebd96632RA `167a7c9d579ce6f2cebf64a6f6329ecb2LA `167e2a6833d49ce198cb3b88f521991e2PA `16b3c9445539e9274282a612dea354c22HA `16f1046144ad9ee7bb96214ba7ae75162VA `16f10764f0ccce42d5be8cfeac36b4462dA `16fa0e4aefe18e1446bf6baefd3ba4002oA `188c1ee5132a6752dfce5a02353540702fA `18b7998a871950ebc36c415a536304772pA `19ecbaa5e12f7a9ebcff703c79534a522hA `1a1a8cc0040b356d06eacd22e05264762kA `1abc586d67f0b6c05fd5e60f254923402SA `1b56132638912a1ca54fcf7cd38b8e232GA `1b9c5ae60ec46be64a1877f0c6920edc2lA `1bbf2ef67f096960e13d8578fa5445362BA `1bc36080b2493aab78c26e4f2152542c2]A `1ca04e5339ed1826c12fe61fd984e9492EA `1e220a934e16fd941bd804ca03865b602RA `1fe14e2e02b6e65e6e6e2ae3d8ddcc9f2xA `1fed22e99b0e11a50eb7b92cb1644e8a2eA `20110c8f8da8304b6d9d3c2845a381282{A `208a8c072ea521c813b86ca7730eb8802~A `216db319052b5742fc68862cb2f399052ZA `218e2c36d5945ece02fdc55d6cbcbc382CA `21982f43bc435f22efef22b309a48c662TA `21a8e6324e9330d4f8ebade604c62b6e2GA `229975f1e84b5088e819cd5f2dc430802jA `229b7fc784707b1d2c702fbeba080e862jA `23a22d1411afb787810d68210e6fad4f2oA `24357fe145c869ec82fdfc8134a1a6d12LA `26c47355cbe966a94826cbe2fbf2b3552_A `26d0c0d8c465087cf160a3bdc479f2b42hA `26d48d68b28f927bfebad454658f94252\A `26e44dfd16a2963d4c18e99806c26fd72|A `277f7f2177e2a265a62680ea0158f9b92]A `2824bef72110575c78aeb979170212b82ZA `286a9a4ee373398d7d2c93862c5f66612aA `299abcee56b05b312ed5700f686f79b82GA `29b4c2b5adcd80ced1612128b3ca95a92GA `2a8412aa50d07330f1298f0243fa79d32HA `2c3270f8797ace2fb37402ea6a09d1262CA `2de582c67fca31500621ecd6d3917a072TA `2ea86ae5093670df1d4502ea82efa1ac2@A `2f1ec795216d5bafa33a810af34219422DA `306cecb32320ead508346ad8fed3394d2dA `322264a17ef7182eb1475bd2eaebc2eb2SA `3384ea6bb47d70f8ca94b4510813f36a2MA `33919e866426ce8e7b2ce06f19bbf8892CA `33e01e2271be22b5ed330045fe6aff502]A `35200cbf0b5b45d7f5f0b343cb18868b2gA `35aa9e09db936aee7ec407c4318165732BA `36dd94159e3e60076c0c6098086e255f2\A `36ff37ced0d3211db95a5ac0daac0c352zA `37b622eaad1f79e759a722aacebf48ec2DA `3811b40721f7ca651887aac4eb17f9f02gA `386dc9d1b647a9f3965f1fbe29c7dfb92BA `3931327ed463d1568868c5ab8e8391482~A `3c2523e65ff953fd73579aaaf5d7ce362fA `3c299a4d77be8b4f886ce9fcd23a25612vA `3c5d4d351e0fb9e33e0e8b6d1d43c0f22SA `3f431bf71ee866f626daf42bc915fa3f2OA `3fc7462a83fa55885067fee629287e8a2wA `3fd9052870778e14ab4a5acbc8c24af42UA `40abea0a87a64bd832a1fad69458b2932yA `41b811063b9425de1934e77d891180222nA `43501cdf0de25278a208cbb9aad800122`A `43caef5d41c4e74826e4a8d82088739d2IA `44db1f1fefc97cd28d55d443f2bd2b632LA `4616fbea6a6dbc1074bc3f1016bbc73b2RA `476e17b6f854414033d5cec1470774ee2VA `48b5ab9805919736382ffea5a9554c022UA `494557db52824555864d1106278cd1f02IA `49ba23148db9effdc3979aa0fe5876ea2hA `4a30eeb083acec8460150068ba0c67432AA `4a3c42c9c5ac29db268010bbebf4f5792iA `4ad8239a37f641bcd17abeb96106314e2AA `4afcb20d4d95bcd1bde3aa6b7f5526602NA `4b046ac6a4796fb1338f0481dbd4003d2PA `4b0a768585da8f9f8f8db1ca409e7ebd2[A `4b227d61f33182579cd3edd0ac6c7c442gA `4c08b67e0c1fdeef50b1fdcc32cdcee22ZA `4cc08ca51ecf0f963035f039de6194c52SA `4d6c95b0b3ea2ddb30fdd3edf3b823912JA `4d71d2a23c85fb7af20e8d1e8b3e0de82EA `4d8f5e581eee602c7fd21da8eb68df9a2WA `4e7b945feca199bd486653fea1d0e39c2FA `4f88f3eebe44285ded812939553ef94c2PA `4fbdc9c57a37781dc5dd86f470c61d042HA `50557b455cba1a3ce9b4555fc3fd54332_A `50562b09417cd8c4a2348a0a5aabe7542LA `50f43b1726cf61066ef8656477b226be2SA `516a7aa07f8faa6b7aa38beb5010cf8c2rA `538e38fbc3f78cd61e1841d8141ddcc12aA `5412fb82160d0f6093e4b6670f505c132xA `54da1b916f49ef40c822fab61d37cf662JA `550becdd08d00fb1e7fd00c2adc3d3d62hA `55188a318c5998989255253e15ccc1f62nA `563864a949924c505985a168191dcb842KA `56d5711303378bd333ddb611a53ece942bA `584b2b145f362098fc5fc1e634d57de52ZA `58e83fb33c120db338132d23b91128052UA `5912529cfd6ce14c5ede5c6c83dae7e82AA `5931f8e3acdac724742c4ee0960d8d402QA `5988b62a0c0785a303b77c74608e8b552_A `59b7b60e6bbf4858d72643d22ad904512FA `59d1b7206e7664e76672d3de4dc9a8ed2EA `5a765f9668608a39333fa90cf462657e2^A `5a9e950f4ac186925e5de978c5f720622vA `5b97ead91c0dd0bad57b4f43a89149a22yA `5badf61ecb9cfadd7d6af58712fa5f6f2WA `5bb6f8322cdbda7a21e4aecbe04462b72oA `5d827a1e8ea70edb11d946b54f076cae2VA `5eebdf85fd1726db301194bfeeee43772kA `615db1a24f36d19a8eaf18d4dceed6b22UA `627a0c45dd07150343c81d856855590e2wA `62f31128a21b0e240bdb7b3d5b121c042pA `6425af51edead39c0e439073986043fb2jA `64a421c2367372c3199c66a6420faf892eA `65453a1ae403679bd2e47398a04205ca2QA `6639ec6f88c4976f8ca20fa840f169e32xA `66f43ab4b823d67f52735bbbe6ba65b02bA `670744b945088de05866864f7d57bee72^A `67c2ae6761e89be0fa66db9623b40d302tA `68a8f34c240a42ab521d2f885f7aa33c2[A `698cf3cbd796161d82c9ac438ebab5d22{A `69f755dd5b9e90a99c3086543790541c2tA `6c226ee1519fbf910197cc1d5c5a57562eA `6e970d0818d58ff2d50c5bf037b1a5652XA `6f47cb314fd780c122adb8cc1f44f7852QA `6fbf7c3d0f4f89e415e89cec28811a942tA `7052598d2355984237d126afea2f6e882YA `706c033b4483b6d062b66d6e4ea0236a2`A `7164823f504286e3a762ee612ff0a9882\A `7198e10ebcf1bb88dc479b5c5b9f2c152ZA `71cf83ae0f45e9ede3a3f979b9c749332mA `7249710187cc2d983709e044dbc78d9d2ZA `72df0bf7853e05560d94208817b834682{A `73262345214f9b7794f2cc4a612b15e82PA `73279888a8fe482c836fb19ca23318dc2_A `73b8194ad8fce0cabb01cd21d5e185002^A `73d2fce4efa52675b35a11ee97bc2db02]A `744554499cb7880086fbd9b1f080e7e12iA `75d9268739fe7787ac02d389ac605feb2pA `7604edf307a5e96120606c8dda06458f2`A `76a1fb7f21fda9eddb95426b651245172}A `76e127a44931bfefab991be3dd7a08b72qA `775894425f5a7436f56fc5a3b4a2cfaa2TA `779e444b4bc720a9eed97f19c41e87732NA `77d965afaebd7193badc746d52b4173f2NA `78292d953eafbdf9e57cc4bbbe6e89642WA `7884b62c561b999b9358d52779a182182nA `78da47d61c91c82809a3c97a791d26d22CA `78f002cc3d512ea302c900d1da4dfeec2@A `79e647a3f8b36a1221897f5837c84aff2lA `7a9609a971a8f31685e88da563eea5ce2^A `7b080dc43fce482af14de61c6ab819a52@A `7b6cb59a177abe9767fd22da5a03b1e62BA `7c21b70f9e9c782c1f5153268e0cc1c12WA `7cc21814165879f72529e91682ece5c62PA `7cc605e721fdd1d2ccc16f5b6490e8302}A `7dea465ad52758b10cbceb08c81d17602kA `7e23419e4fc69b5b533815681c9bb1a92CA `7ed1d2efa3e0f0ed6b77eb4eff3d86b32TA `7f78b02c531f09602ba4e140132d26a22sA `7fa2f0877831b4c924438396760f18412`A `7fcfaa8dd34dbd508f19e8ca0fcfda0f2TA `7fded0345c258eea966c0b5ee1b7c7aa2aA `809925e891b0456231c374b09cbe4a902iA `80c8fca02ebfecc7a931dad1ec38466e2uA `827de2d7a9d231f6bcb44caf35896c1f2A `82a115ab8d617e4e96813587fe3a60492KA `853cac0f2d1f90b7c986e7d1dcdbbfde2A `88a8e608108be939da9aab5a9a8af7d12iA `898d25a2ab9c0ba1fa9bad462405e4752oA `89abaa7f21cf788ce4744e3e611732912~A `8a1ea5d5cf843bc5955a94cfcc321e922rA `8a29f62d1bebfe7b8008d7f264b56b4e2wA `8acc78be63e27e938ee53ec2c0b90c612OA `8b76101d185700a8efed148d8722d9262{A `8cc6b19cd410e638f4beaf1642f4f52a2lA `8d7caf84b3a51cca27291c1f7cfc2d402RA `8d9c3760395e8e0eb40e335b22750b682UA `8f58cbe5f2ce85c22569af765de3f8d32IA `904b07170a0ce481b7491e7fecce4f792_A `90f9355781403b92e844de8568863ae82VA `916bda59bc7621d5c1790c040572a3c02[A `91fe03f994e8e85cede4e3bd62f4d6b72mA `922cc71fd28b1dac8f407f1d517f55952gA `924727b6f380cf3cdfe5650163e920542uA `927612b57ba01ca878b2d7edce52a5632fA `931b2ebd9bfaeb5dcf1973e724a1f8d02\A `9335522f4c8dbc7256a42a091e6e00bc2FA `937a597a8b399fd32caba88a3c1c7bc42RA `94b85ba716dbb7c20b230e69248b82082EA `95c0a5b8a66950b5f22dd82a8dfe0ce52VA `966fe8d32b86121f8a465a21b95f7e5c2_A `9693a1e77dee5785b1dc61ccffd2e9062vA `97402287d8c6c03f0b63848e17e9d9442lA `98c640616f997a323af625e34ba348502KA `991285e3967c3295b4ff2dcd835f7c612fA `992a00c30242b6217243f3c387ea18b72MA `993e58f132740b464ecf06ee289dc7b22wA `997acc135d01b54f7de77a432fb9133f2JA `998eda745d07fd8608f251138384a0b92cA `99c9c80a6532e4ea3b535c5a92d07a252[A `99f5219da22485d0872a2529599c84402NA `9a687babb0f44db51dc389b75bdaa19d2uA `9ac7bb94e60dc30a023ce433de0273642hA `9ad72c2a5157f21741bd4581a562dfc72|A `9baedcd033169611a42c3cfd58b3ae032eA `9cc2a0b6c8be1405cddcdeb4487c59fe2zA `9ccda414c322ebcdf875eacbba2e4b7e2zA `9da845cd31310b8952efd1be1881e6512zA `9dca844d353efed03fbaddfc0fab7c762xA `9f29c6d9719fc6bc09a2981057642b692tA `a0a00c23556fcc5dbfb7b7f43fbbb61d2yA `a106d7c1b1b277538367f9c8140e3a752ZA `a12474027c91fad5a861aa9919817d722vA `a2012a3c9cdb1d6fd69afdbadc1e76b62YA `a2679a7d860a0bfb2645809ed92ce1382]A `a4462529ab493676987d946019a149452mA `a46c601d03a3a26bc418d0096fe83a422XA `a578acf825a595ce95fe8f804b7208f02kA `a5b2ee641e10d3e4db8f888217ab9ecc2KA `a62186ea292d6db03a087bd5dfcc3f1e2eA `a65bd31d4c3dab0a41712823a5d6002b2A `a673b3829e62477e01abc75465416b862UA `a7f0e85fcad4f5bc5ae5c18c10de4f9e2JA `a98d42be181c01b8077e060b1b5080ec2gA `aa61b4543e8a7c67fccabee27a6e99cd2fA `abc5ca9856a61831fd4ed06b402875d22bA `b051fd352847c06e748b345e8ed0738b2nA `b16bddd1a6d3e5f4136446bebe7ffbc72OA `b2621497b3313c97855ed951f0d9b2912sA `b27bdabd8e1a6b7dc06886867331ceb32sA `b2c4cf0fb96d02d37f03668caaecbc572{A `b36abffbe5d6a0de73a9968604a1a3f92{A `b5c628b0c1dbf857a475c4be5de4690d2EA `b875f24d3d444fdda82b6bbfb75a4c922pA `b9d4f73fa7ca8ef66891554b66b2cded2vA `ba45ddd3042dad59a12e5937644f72462}A `bbd2824ff0d5b801bb6f5da3a2a1a8882~A `bbe1deec11d459bdb348051b970abdaf2IA `bc2709406a9bb19e8d83a78f81e362442~A `bce2fa6458f39a75e2713f3d687271a12iA `bda9a5da86ec9790262e14f953bbadcb2OA `bdea71d64cdfcc405e65e750fe8d9b862KA `be2c49ea5816e7daa6d3b3ff453532912JA `bed3b7fcc1294e23639057435ac8756a2cA `bf4f86812812dab8d39db9aaefe94a782GA `c098c6f0901979bd914ed7a345200f902BA `c0e423f9ac41cc5b265c95a3e97e3fcb2cA `c1241374502f200cf9fc49c8d6fb58222rA `c18b12fff24dc87e7f1039bd17c0c6aa2EA `c20d71627e66a044b21780f56f2f95042mA `c2d39f2f7fe6cb69fc8efb6c5495c9322]A `c3053579ae25e2fb9b967076a06373af2qA `c377351433a941a927aab543931f60262DA `c4b418764dca70aebfc965899a3fa7e52OA `c4d3a917f623f58646ce93015d79e8e02nA `c4e7199a586a308352b7a881add7e3562QA `c54909ecf4fb3e9afeea36200fe95dce2NA `c56a76ef8f604a8d87be2a32b1f81fac2lA `c6107ff57e96a1373c019d252c00ad842aA `c61a5bda3f1667498626ae52ad0362e02cA `c6696a730f7498efb66f5ba3a8b35d082[A `c6dc6e6567d673436ac41ebc8e79a9ec2lA `c6fc88bd57a0e57ddf22e2eb1bef892c2FA `c70b78fd0b5dffcd38322355e9c2471e2LA `c7937b6b4bde2a96191dc31db913e1ab2FA `c92c12a28fa219ad1aab60865046ff052kA `c98cbc333fb7d95c6c9fc4924b0526e12WA `c9d257aba54475c20b3737ce7c779e552rA `cb13b64d0127c13bb466c4d4677a7b8a2sA `cb5b6f7ab4d36e90d2619cb907ebb9562|A `cb9649eca3dfbd356527ffc88f1dcb942A `cbf9587a8187985725963b8bfc67004d2jA `cc1a3b2f107510ac664e491d5f2412aa2_A `cc573488dec311655890a205aad4fb652YA `cc64c2fcdecdb505b3797e1aaaa59adc2TA `cd90bce912f5743226af94c1efaaa4a72DA `cd9ba1f582642d9cbe500f018afab3412AA `ce0aea06d44878b4a373efe090a66a622cA `ce426b7f3190c8a4a47d45ac799e91a42qA `ced9df0d8c8ed14de91c509b31b4c4ae2tA `d08a3fdc040bbbdd81c9927ce296318c2PA `d12c1c2a68be4c7fda5a7737d5493b4d2yA `d13aa56e27fe71ef40ff153c093ecdf82HA `d266a2023c67b7a20c3bd01055b223bc2A `d2e805472f79f0b558f75b90b5e7b4ee2xA `d3fa23c9066f943f10e8883de9340dea2dA `d51032bef3e7117a94336fea18a3fad72YA `d710a073be2da219a388a150eb7b6b6a2HA `d77cdb466c5063b99c5aea58e6da4d322|A `d791eaca9375ca1b36a987af22ee71dd2pA `d8041ae308961666b15aa1e57b0f9f352RA `d819cea5197e9b8673d6c0b16659a5ea2QA `d869fb48cb9acba03dc639481524ee802bA `d9018f459d3c94a91e92b459e152f7e72hA `d95522c691013bfe66dd46ded85a98ed2uA `d9560caeb797b302191f667b4264da402qA `d96f80f23543850a2ee9fff8cd2cc53f2kA `d9c6ab5c6630a4a84e242c5765103d2d2aA `da67e2f049b5b6babcf7906b856533992[A `daa3fe935b0be9f31b6b362ad9e0d2d62YA `db97311c24809f103575d8a7fee196802WA `dbcc4002c15afefef853a08a0804ba3a2OA `dc9580308938069159c5afc55b2f3b962qA `dc962e34780f0374b7eb3d583f6d7eb62vA `dcc2e24df32287e89ee3b0f64d617f572bA `dd6c32a722dc815273cd9ed8cd6c671b2gA `ddab6357ff522c0c956ebd7669e834542uA `ddd3e6f6e298d3884abc4d888a0436642rA `de1ab82817c0fb24e591b9a89a82f7362pA `de37d9fae011687eb1eb5a127fcb89e32BA `de734259dfb9addebe2b226d96b4f7442]A `df30d810068e4656498e5972c6de7e3d2jA `e01e01d18582c7f69e1b0db7e1b111a02XA `e159a35d1b9a46e03072a3d54780edcb2~A `e1870dde155be1a375f155dd1f7ead132SA `e30258aeb8475d4c27f79359456718562^A `e396cbf9274b590a1d94ee43d823a0bd2SA `e3e146469ed4318eaa2ffbca3510c0542A `e5390751969ab21df280b7591854b89f2|A `e5cb2e5d501d3db2db5d8f14984a66d42}A `e6684944c37dbdd4c08d978af9e47bed2@A `e74d071363645a588f858b35231128c42wA `eb2a5824e03996c1966bee38866ce3492dA `eced95e5f301a8340e83d81d3c0d5c0d2KA `ecf3ac80454654d990d9c07d33d35d1c2XA `ed431877ce11fe403fee77f7d26ce6372\A `ed4f5a398056eef1cf6caa90786b340a2}A `ee48516e57684c5a4c22adccac34be922cA `ee4ff9e4e8a1948795e26af2f3f8a30f2QA `ee623aaa99b429863f89da313fffed972uA `ee62cb0b9a97f990df1ed0266a7027e22tA `eee039f49a5b570599cf459c55c649f32MA `eeef60efe889349870426d10edc694be2\A `ef8a399c9679ce4e9710c7c6ecf8bcc72[A `f0fdc140e18514362a4e52376a6fecba2MA `f15702ae9e55bad42182cf18724d18632}A `f23ca2aa066b1ee0fa4df1f2f865be4c2sA `f2cbe07bf2ff16d5a5860b4d6edbc5e82CA `f3a9b931b7f552a4f9dfa61ce4f39f0e2jA `f3ef819656f68b87a91c53afbd441fec2bA `f41d4fde94cbd7bbd28808dc080a20192QA `f45069216cd934b80ce882c9a2f2a08a2MA `f488aa62d39194824861a134567cadb82aA `f4baa43cc7ca712d83b99a794c4e2dbd2iA `f55d33371dcff207fd7d201128df2ea32UA `f56c19442484b3e4f47875b58b3f72b22xA `f5effd616a3f8db6193b482caec379122`A `f5f28f42ad234b4389af4cbea54ff60d2mA `f6debed350f20a2b3aa4d970e32274112JA `f6dff70097776e24c2a7c9c0f2514f792^A `f7df7b85af230b2623d3a827b0cbddd22NA `f8327953a0f0b80011b939111807999a2dA `f887e1aabf801e351bfb39698f208af12VA `f9e847ee886bdb9ab5583eeb6eabbd512DA `fa0486610d8a02cea245c13c85b6de272XA `fa16213d24273d386d22332cd01ce7742QA `fb1da4a6ed74705ad98bb60ad4badaf22eA `fcb0105fa6b5777a133f247784b9d9302zA `fe6ba10cc6c9509b4b22e9d59e0297752PA `ff1441a42144a7de9a3eaf9f5e7cfea92AA `ffdbd6a7d28c9a63976e9eec38cab0f5>xdtypefstringvetitle3vddocs<ya1Aya2Uya3~ya4\ya5mya6Dya7lya8Hya9Cyb10Eyb11[yb12Dyb13@yb14Gyb15ryb16ryb17Wyb18Jyb19^yb20]yb21Eyb22tyb23Syb24yyb25yb26_yb27nyb28tyb29Eyb30Cyb31Byb32pyb33{yb34`yb35[yb36Tyb37Eyb38lyb39Yyb40pyb41~yb42Xyb43~yb44Kyb45}yb46yb47Fyb48Gyb49Fyb50]yb51Yyb52Dyb53Eyb54yyb55vyb56|yb57Xyb58]yb59dyb60ryb61xyb62yyb63myb64cyb65byb66oyb67Fyb68Hyb69iyb70tyb71syb72nyb73wyb74vyb75Nyb76[yb77hyb78lyb79Hyb80gyb81Zyb82fyb83Cyb84eyb85qyb86jyb87Byb88Oyb89Yyb90Pyb91]yb92kyb93kyb94\yb95myb96Qyb97dyb98jyb99iyc100hyc101gyc102Pyc103}yc104|yc105Iyc106Nyc107Syc108Qyc109dyc110^yc111tyc112_yc113Iyc114Jyc115lyc116|yc117Gyc118[yc119Uyc120pyc121Syc122cyc123Yyc124myc125kyc126jyc127Iyc128byc129ayc130{yc131\yc132Zyc133{yc134cyc135Zyc136zyc137Yyc138\yc139eyc140qyc141gyc142fyc143^yc144eyc145yyc146Xyc147}yc148cyc149nyc150oyc151Zyc152Vyc153_yc154_yc155Xyc156cyc157Wyc158Cyc159`yc160Vyc161Uyc162Nyc163}yc164Yyc165\yc166Tyc167Fyc168Tyc169^yc170ayc171Dyc172Syc173@yc174Ryc175uyc176Qyc177Tyc178ayc179]yc180Wyc181Pyc182Lyc183yc184yc185Oyc186@yc187xyc188[yc189yc190Nyc191Ryc192Zyc193`yc194^yc195Wyc196Myc197Tyc198byc199~yc200Lyc201Ayc202xyc203Kyc204|yc205oyc206syc207[yc208eyc209Jyc210Ayc211{yc212Jyc213Pyc214`yc215Kyc216Hyc217[yc218Myc219Pyc220`yc221jyc222zyc223xyc224kyc225Uyc226lyc227myc228byc229}yc230syc231Qyc232ayc233Myc234uyc235_yc236dyc237^yc238jyc239Byc240xyc241wyc242Iyc243uyc244fyc245Ryc246Syc247hyc248ryc249zyc250`yc251eyc252gyc253byc254iyc255nyc256Vyc257iyc258pyc259Iyc260Iyc261Jyc262ayc263_yc264Kyc265ayc266^yc267tyc268Xyc269qyc270Tyc271eyc272iyc273yyc274hyc275xyc276wyc277zyc278Qyc279Ryc280kyc281nyc282ryc283cyc284Vyc285Oyc286Hyc287_yc288dyc289Wyc290Jyc291Ayc292Uyc293Ryc294Xyc295vyc296Nyc297Byc298Syc299Ayc300jyc301wyc302zyc303Yyc304oyc305{yc306yc307\yc308Wyc309Gyc310pyc311wyc312Byc313syc314Myc315Lyc316gyc317@yc318iyc319Lyc320~yc321Xyc322Qyc323Zyc324hyc325Wyc326Gyc327qyc328Uyc329vyc330Pyc331Myc332oyc333Qyc334Ryc335syc336zyc337]yc338kyc339]yc340vyc341Gyc342wyc343myc344Dyc345|yc346Fyc347pyc348~yc349Vyc350qyc351Oyc352uyc353oyc354Vyc355vyc356qyc357Dyc358Zyc359Cyc360Vyc361Hyc362yyc363dyc364uyc365Uyc366Myc367Pyc368lyc369Qyc370Cyc371syc372Oyc373Nyc374@yc375Pyc376uyc377Tyc378}yc379Syc380Ryc381Byc382Oyc383Fyc384Lyc385Ayc386@yc387fyc388hyc389\yc390Kyc391gyc392tyc393Eyc394{yc395Lyc396|yc397fyc398ryc399Kyc400byc401nyc402f>wkorderedDocs<w2ypwAxp _「7つの言語　7つの世界」 Io 0日目(Jugemより移植)2qA _「7つの言語　7つの世界」 Io 1日目(Jugemより移植)2|A a「7つの言語　7つの世界」 Ruby 1日目(Jugemより移植)2{A a「7つの言語　7つの世界」 Ruby 2日目(Jugemより移植)2yA f「7つの言語　7つの世界」 Ruby 3日目（最終日）(Jugemより移植)2HA ~「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（2章～4章）(Jugemより移植)2hA v「Apache Solr入門」のサンプルのlucene-gosen対応（1章から4章）(Jugemより移植)2EA Y「IDの秘密」を読みました。(Jugemより移植)2fA ~「コード・シンプリシティ」を読みました。（Kindle paperwhiteの使い勝手の確認も兼ねて）(Jugemより移植)2gA e「コンピュータシステムの理論と実装」を読み始めた #Nand2Tetris2fA e「どんな本でも大量に読める「速読」の本」を読みました(Jugemより移植)2YA d「よくわかるAmazon #CloudSearch 」に行ってきました！2^A U「検索システム探訪」したいな=>やりました2QA e「自分の小さな「箱」から脱出する方法」を読みました。(Jugemより移植)2OA S「自然言語処理の基本と技術」を読んでる2GA x『プログラミング Hive』 『Hadoop 第3版』刊行記念セミナーに参加しました！ #oreilly07242JA i【メモ】Amazon CloudSearchが出てきましたよ(Jugemより移植)2MA e【重要】lucene-gosen 2.0.0リリース(Jugemより移植)2NA f【重要】lucene-gosenの次期リリースについて(Jugemより移植)2jA u#DSIRNLP 3.5に参加しました。＆「Emacs実践入門」を頂いちゃいました！(Jugemより移植)2qAo#elasticon に参加中2mA T1.2.0リリース(Jugemより移植)2bA X1.2.1リリースしました(Jugemより移植)2CA S2014年のElasticsearch2RA S2015年のElasticsearch2IA S2016年のElastic Stack2DA [2017年のElastic StackとElastic2vA [2018年のElastic StackとElastic2CAo2018年のElasticは？2[Ao2019年に買ってよかったもの2nA [2019年のElastic StackとElastic2ZAn2021年かって良かったもの2\A \Aggregations - ファセットよりも柔軟な集計2AA aAnalyze UIとKibanaのプラグインの作成方法（第1回）2@A aAnalyze UIとKibanaのプラグインの作成方法（第2回）2zA aAnalyze UIとKibanaのプラグインの作成方法（第3回）2mA iApache LuceneのKuromojiのUniDicビルド対応パッチについて2OA yapache-loggen + fluentd + elasticsearch + kibana = ログ検索デモ2CA XApple教に入信しました(Jugemより移植)2|A oautoGeneratePhraseQueriesのデフォルト値について(Jugemより移植)2RA oAWS Summit Tokyo 2013に行って来ました。(Day1) #awssummit2PA oAWS Summit Tokyo 2013に行って来ました。(Day2) #awssummit2lA lAWS ビッグデータ活用事例セミナーに参加しました。#jawsug(Jugemより移植)2]A cAzure Cognitive Searchでインデックスを作って検索2fA kAzure Cognitive Searchでオートコンプリートやサジェストをしてみる2A hAzure Cognitive Searchでの日本語向けAnalyzerの違い2[A rAzure Cognitive SearchのIndex Schema JSONをCSVで見たくなる2BA aAzure Cognitive Searchのリクエストのロギング2`A pAzure Cognitive Searchの新機能、Semantic Searchを試してみた2MA TBasho Japanに遊びに行きました2|A [Berlin Buzzwordsにオンライン出張してた2fA QBerlinからおはようございます2oA `Bonfire Data & Science #1に参加しました2lA [Bookscanを使ってみました(Jugemより移植)2TA ZClean Coderを読んだ(Jugemより移植)2TA cCloudera Searchってのが出たらしい（とりあえず、雑感？）2SA WCloudera Searchのモジュールたち2QA VCloudera Searchメモ（妄想版）2yA kCloudera World Tokyo 2013に参加しました！ #cwt2013 2JA rcompositePOS（CompositeTokenFilter）のバグ修正(Jugemより移植)2LA tcompositePOSの利用例（naist-chasenでの英単語の出力方法例）(Jugemより移植)2mA _Corne Chocolateを組み立てた #DIYキーボード2iA fCorne Light v2のBLE+LPME-IO対応 #DIYキーボード2nA ]Corne Light v2を作成した #DIYキーボード2zA ^CROSS 2015で話をしてきました #cross20152RA UCurator 1.2および1.1について2oA [Curator: 時系列インデックスの管理(日本語訳)2^A `Delete by Query APIはプラグインへ（日本語訳）2kA Ydiscuss.elastic.co にぜひ参加を2]A!]Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだ2qA UDozen0を作成した #DIYキーボード2uA aElastic Stack 7.0で入ってくる新機能をちょっと紹介2DA YElastic Stack 7.7がリリースされた2rA pElasticsearch 0.90.8がリリースされました＆注意点（2013/12/20追記）2QA ^Elasticsearch 1.3.1 リリース（日本語訳）2KA ^elasticsearch 1.4.0.Beta1のリリース2HA eElasticsearch 1.4.0および1.3.5リリース（日本語訳）2DA eElasticsearch 1.4.1および1.3.6リリース（日本語訳）2~A eElasticsearch 1.4.2および1.3.7リリース（日本語訳）2yA eElasticsearch　1.4.3および1.3.8リリース（日本語訳）2uA eElasticsearch 1.4.4および1.3.9リリース（日本語訳）2pA ]Elasticsearch 1.5.0リリース（日本語訳）2nA ]Elasticsearch 1.5.1リリース（日本語訳）2lA gElasticsearch 1.5.2 および 1.4.5リリース（日本語訳）2hA ]Elasticsearch 1.6.0リリース（日本語訳）2aA gElasticsearch 1.7.0 および 1.6.1リリース（日本語訳）2`A gElasticsearch 1.7.1 および 1.6.2リリース（日本語訳）2]A cElasticsearch 2.0.0-beta1リリース（日本語訳）2[A cElasticsearch 2.0.0-beta2リリース（日本語訳）2dA eElasticsearch 2.0.0.beta1リリース間近（日本語訳）2WA ]Elasticsearch 2.0.0リリース(日本語訳)2|A [Elasticsearch 2.0系のIssueの紹介2JA YElasticsearch 5.0の便利機能紹介？2sA ZElasticsearch Coreトレーニング開催2mA \Elasticsearch Marvelの紹介と第一印象2pA _Elasticsearch NEXT STEP 2を頂きました2VA nElasticsearch server 2nd editionのファーストインプレッション2hA [ElasticSearch Serverを翻訳しました2dA fElasticSearch Server日本語版（電子版も）が発売されました2\A pElasticsearch unplugged - 2.0におけるネットワークの変更(日本語訳)2`A uelasticsearch-analysis-kuromojiでユーザ辞書の利用方法(Jugemより移植)2{A aelasticsearch-extended-analyzeの改良2tA welasticsearch-extended-analyzeプラグインをMavenとSonatypeにリリース2|A gelasticsearch-extended-analyzeプラグインを開発中2wA belasticsearch-extended-analyzeを公開？2~A `elasticsearch-inquisitorプラグインの紹介2]A `elasticsearch-kopfの紹介（aliases画面）2`A aelasticsearch-kopfの紹介（analysis画面）2bA ]elasticsearch-kopfの紹介（rest画面）2cA Yelasticsearch-kopfの紹介（概要）2A aelasticsearch-river-wikipediaの疑問点2MA lelasticsearch.もうちょっと入門という話をしてきました #gihyo_efk2BA kElasticSearchにプラグインで日本語Wikipediaデータを入れてみました2UA xElasticsearchのAnalyze APIのVisual Studio Codeのクライアントプラグイン2_A lElasticsearchのアーキテクチャとStateless / Serverless2NA bElasticsearchのインデキシングに関するパフォーマンス検討2VA [Elasticsearchの新しいJavaクライアント2oA ~Elasticsearch勉強会 in 名古屋を開催しました。#elasticsearch #elasticsearchjp2JA dElasticのWorkplace Searchを触ってみる - その12IA pElasticのWorkplace Searchを触ってみる - その2 - インストールと起動2pA bExtended-Analyze 1.0.0RC1をリリースしました2XA!MExtreme Multi-label Learning for Semantic Matching in Product Searchという論文を読んだ2UA afluent-plugin-zoomdata作りました＋悩み事とか2qA wFluentd meetup in Japan #2 #fluentd に参加しました。(Jugemより移植)2YA gFluentd Meetup Japanに参加しました。(Jugemより移植)2eA _GOTO Night elasticsearchに参加しました2SA QGoでSlackのボットを作った話2xA bGroovyスクリプトをダイナミックスクリプトなしで実行(日本語訳)2vA vHadoop Conference Japan 2011 Fallに参加してきました。(Jugemより移植)2cA }Hadoop Conference Japan 2013 Winterに参加しました。#hcj13w(Jugemより移植)2xA wHadoopソースコードリーディング第10回に参加しました。#hadoopreading(Jugemより移植)2gA hHadoopソースコードリーディング第7回に参加しました。(Jugemより移植)2XA vHadoopソースコードリーディング第8回に参加しました。#hadoopreading(Jugemより移植)2IA!CHadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）に参加しました。(Jugemより移植)2gA vHatena Engineer Seminar #5 @ Tokyoに参加しました。 #hatenatech2FA oHeroku JP Meetup ＃4に参加しました。#herokujp(Jugemより移植)2^A!JHeroku Meetup #8 TreasureData + Waza Report!! に参加しました。#herokujp(Jugemより移植)2iAkhomeshick導入2RAmHugoをアップデートした2lA QIndex Template V22A ^Issue32について（4096の壁）(Jugemより移植)2KA qJava One Tokyo 2012 に参加しました。#JavaOneJp(Jugemより移植)2hA nJIRAのDB移行（HSQLDBからPostgreSQLへ）#augj(Jugemより移植)2]A ]JIRAのデータをS3へバックアップ(Jugemより移植)2oA gJJUG CCC 2011 Fallに参加してきました。(Jugemより移植)2BA iJJUG CCC 2012 Springに参加してきました。(Jugemより移植)2A fJJUG ナイトセミナーでLuceneの簡単な紹介をしてきました。#JJUG2yA QJJUGナイトセミナーで話しました2fA mJustTechTalk#02 形態素解析のあれやこれや@ジャストシステムに参加しました。2aA lJVM Operation Casual Talksに参加しました #jvmcasual2XA VKibana 4.2.0リリース（日本語訳）2tAnKibana 4（日本語訳）2LA QKibana3というのもありまして2YA `KuromojiのCLIコマンドとpicocliとGraalVM2QA aKuromojiのCLIコマンドにJSON出力とラティス出力を追加2LA \Kuromojiのカスタム辞書をインデックスの設定で指定2EA YKuromojiを調べてみた(Jugemより移植)2rA aLinderaのFSTをDoubleArrayTrieに変更した話2BA ^Logstash 1.5.0 Beta1リリース(日本語訳)2YA XLogstash 2.0.0リリース（日本語訳）2AA ]Logstashプラグインのエコシステムの変更（日本語訳）2jA gLogstashを使ったElasticsearchの再インデックス（日本語訳）2FA _Logstashを利用したApacheアクセスログのインポート2[A!YLucene 4.3.0のChangesにあるChanges in backwards compatibility policyが気になったので訳してみた。(Jugemより移植)2kA sLucene Eurocon 2011 Barcelona のスライド読みました(Jugemより移植)2KA!NLucene Kuromoji for NEologdで指定した品詞の単語を抜き出すIngest Pluginを書いてみた #elasticsearchjp2MA blucene-gosen 1.1.0 リリース(Jugemより移植)2GA alucene-gosen 1.1.1リリース(Jugemより移植)2DA jlucene-gosen 2.0.1リリース（Java7対応）(Jugemより移植)2~A nlucene-gosen 2.0.2リリース（リソース周りの改善など）(Jugemより移植)2nA ^lucene-gosen 4.6.1のリリースに関する注意点2XA!Clucene-gosen4.3.0をリリースしました。（Lucene/Solr4.3.0以上での利用が可能です）(Jugemより移植)2pA llucene-gosenで文章からキーワード抽出（イレギュラー？）(Jugemより移植)2WA vlucene-gosenとSynonymFilterを利用するときの注意点（問題点編）(Jugemより移植)2QA Ylucene-gosenとは(Jugemより移植)2LA ilucene-gosenのJava7でのテスト失敗問題の対応(Jugemより移植)2vA nlucene-gosenのLucene/Solr4.0-ALPHA対応(Jugemより移植)2^A nlucene-gosenのLucene/Solr4.0対応ブランチ更新(Jugemより移植)2NA elucene-gosenのTokenFilterたち(Jugemより移植)2yA `lucene-gosenのUniDic対応(Jugemより移植)2HA bLucene/Solr 3.3リリース（速報）(Jugemより移植)2xA bLucene/Solr 3.4リリース（速報）(Jugemより移植)2IA!SLucene/Solr 3.6.0リリース / 「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（1章）(Jugemより移植)2mA sLucene/Solr 4.0.0リリース＆lucene-gosenの4.0対応(Jugemより移植)2}A gluceneutil - Analyzer性能テストへのkuromojiの追加2~A ]luceneutil - マニアックなツールのセットアップ2nA mLucidのGrant Ingersollさんの講演を聞いてきました(Jugemより移植)2aA mLunakey Miniを組み立てて、BLE+LPME-IO化してみた #DIYキーボード2hA ZmacOS標準のターミナルのウィンドウグループが便利2cA [Mappingのすばらしいリファクタリング（日本語訳）2\A \MapR中身説明会に参加しました。(Jugemより移植)2}A VMarvel 1.3.0リリース（日本語訳）2BA WMBAセットアップ備忘録(Jugemより移植)2AA ZMBAセットアップ備忘録その２(Jugemより移植)2}A ZMBAセットアップ備忘録その３(Jugemより移植)2rA ZMBAセットアップ備忘録その４(Jugemより移植)2eA }MBAセットアップ備忘録その５とMac Mini（2009late）セットアップとその他くだらない話(Jugemより移植)2uAnmeteredクレートの紹介2CA yMicrosoft Build(2020)のAzure Cognirive Searchのセッションを見たのでメモ2uA VMIR輪読会始めました(Jugemより移植)2iA cMongoDB勉強会（第7回）に行って来ました。(Jugemより移植)2CA _MorphlinesのloadSolrをちょっとだけ調べてみた2EAmMorphlines入門？2FA vNAIST-JDic for MeCabのPreprocessorの実装に関する備忘録(Jugemより移植)2KA gNAIST-JDic for MeCab対応版（仮実装）(Jugemより移植)2iA YNested Objectのフィールドの奇妙な動作2uA gNew SolrCloud Designの翻訳（その１）(Jugemより移植)2tA gNew SolrCloud Designの翻訳（その2）(Jugemより移植)2fA YOctopressからHugoへ移行中(まだ途中)2VA XOctopressを試し中(Jugemより移植)2WAnOctopress始めました2kA WOctopress環境のDockerイメージ化2dA [OData式と日本語の検索(NGram)とフレーズ検索2RA ZOramaという検索エンジンでブログ検索を作ってみた2]A aOSSAJのミニセミナーで話しをしてきました(Jugemより移植)2tA vPartial UpdateとcopyFieldのバグ【Solr 4.0 ALPHA】(Jugemより移植)2jAjPCもDIYしました2oA qPFIオープンセミナー2012に参加してきました。 #pfiopen2012(Jugemより移植)2CA kPlayFramework 2.0(Javaの方)を触ってみてる(Jugemより移植)2[A ^pre-commitとvenvとPyCharm（困ったな？）2sA Python Developers Festa 2012.07に参加してしゃべってきました #pyfes(Jugemより移植)2TAnQuerqyの調査（その１）2SA VQuerqyの調査（その2：アーキテクチャ）2ZA VRelease, we have（日本語訳）2zA _Riak Meetup #3 #riakjp に参加しました。2IA cRiak Meetup Tokyo #2に参加しました。#riakjp2AA TRust the book - 第10章2@A TRust the book - 第13章2{A TRust the book - 第15章2TA SRust the book - 第4章2RA SRust the book - 第5章2PA SRust the book - 第6章2MA SRust the book - 第8章2EA SRust the book - 第9章2VA SRust the Bookを読み始めた2RA UScala始めました(Jugemより移植)2sA wSearch Engineering Tech Talk(検索技術勉強会)の運営として参加して始めてみました。2UA Xsearch-UIとSearchkitと検索画面2UA eSenseの歴史 - Sense 2.0.0-beta1の紹介(日本語訳)2VA hShield、Watcher、Marvel 2.0.0 GAリリース（日本語訳）2hA iSofle v2を組み立てて、BLE+LPME-IO化してみた #DIYキーボード2GA wSolr 3.6.0のCJKの設定とSynonymFilterFactoryの気になる点(Jugemより移植)2ZA cSolr4.3.0のChangesを訳してみた。(Jugemより移植)2sA gSolrの新しい管理画面（Solr4.x trunk系）(Jugemより移植)2KAoSolrの管理画面でデータ登録2sA TSolrへのプラグインの配置方法について2cA fSolr勉強会第７回に参加しました。（発表もしました）(Jugemより移植)2wA eSolr勉強会第8回に参加しました。 #SolrJP(Jugemより移植)2JA VSonatypeのバージョン番号で困ったので2jA eSplunk Live!のイベントに行って来ました。(Jugemより移植)2^A Rstream2esと複数データの登録2EA XSwiftypeがジョインしたので触ってみました2xA iTerraformでAzure Cognitive Searchのクラスターを起動2SA tTimelionの紹介 - Elasticsearch Advent Calendar 2015 1日目2@A {trunkのライブラリ差し替え（Lucene/Solr3.6.0）とランダムテストの失敗について(Jugemより移植)2rA jTwitter 勉強会 #twtr_hack に参加しました。(Jugemより移植)2}A oTwitterが公開した分散トレーシング（追跡？）システム、Zipkin(Jugemより移植)2IAovalidate APIの利用2WA {Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)2YA kVS CodeとDev Container（docker-compose.yml対応）2VA _VS CodeとDev Container(コンテナ名の指定)2ZA ^VS CodeとDev Containerの導入（まだ途中）2oA PWindowsへの移行（その１）2pAlWindowsをお試し中2XA UWSL2のディストリビューションの環境移行2DA WXperia Zが故障したので交換したのでメモ2bA XXperia Z買いました(Jugemより移植)2HA XYokozunaの気になる点というかなんというか2{A kZipkinのReadmeを読んでる（クライアント周りについて）(Jugemより移植)2zA dZipkinのReadme読んでる（その２、残り）(Jugemより移植)2jAgzshへの移行2_A cあけましておめでとうございます＋会社のブログ更新(Jugemより移植)2[A Sアジャイルデータサイエンスが届きました2gA [いつも入れているElasticsearchのプラグイン2eA sいまさらですが、CROSS 2013で検索CROSSというセッションを担当します(Jugemより移植)2WA hインデックスエイリアス - Azure Cognitive Searchの新機能2EA UインデックステンプレートとLogstash2dA }エンジニアサポートCROSS 2013に参加（＋お手伝い＋モデレータ）しました #cross2013(Jugemより移植)2\A!Xエンジニアのためのスキルアップ勉強会『Tech Compass』 #tecomp ― Vol.2 「人気Webサービスの作り方教えます！」に参加しました。(Jugemより移植)2aA!`エンジニアのためのスキルアップ勉強会『Tech Compass』＠竹橋 ― Vol1 「スマホ時代到来、この先生きのこるエンジニアとは！？」に参加しました。#tecomp(Jugemより移植)2AA Zオープンソースへの貢献のススメ(Jugemより移植)2{A bカンファレンス情報の探し方（CfP、スポンサー応募、開催期間など）？2@Ahコーヒーブレイク2OA cサーバ/インフラエンジニア養成読本 ログ収集~可視化編 を手伝いました2eA Rさらに進化したFound（日本語訳）2zA aシステムの特徴と検索機能について(検索システムに関する妄想その1)2JA ^スキーマレスモード？（SOLR-4897）を調べて見ました。2kA lすずけんさんのメモを元にVagrantでElasticsearchクラスタを起動してみた2bA Sスライド作成の環境をMarpにしてみた2rA ^セキュリティ向けプラグインShieldのリリース（日本語訳）2PA Wソースからのビルドと構成(Jugemより移植)2FA Vデータ分析基盤構築入門 を一部執筆しました。2aAoフリーランスはじめました(仮)2PA Uプロキシ環境でのpluginコマンドの実行2RA Sブログはじめます(Jugemより移植)2eA Wブログ移行日記(その1) - Hugoとテーマ2dA ^ブログ移行日記(その2) - Markdownファイルの変換2cA dブログ移行日記(その3) - Hugoの設定と微調整(テーマに合わせた)2bA _ブログ移行日記(その4) - 検索機能(Algolia)の導入2\A [ブログ移行日記(その5) - Jugemのブログを移行2WA Xブログ記述環境としてのDev Container2_Ahボードゲーム紹介2YA iポモドーロ回してます。（ポモドーロテクニック入門読みました）(Jugemより移植)2pA oメインMBAをMountain Lionにアップデート（いろいろ確認中）(Jugemより移植)2[A aモーショノロジー2012#1に参加しました。(Jugemより移植)2LAhよく物が壊れる年2PA kローマ字入力のゆれと読み（JapaneseCompletionAnalyzerその2）2OA [久々にMac Miniのことでも(Jugemより移植)2\A V今年のDIYキーボードとコントローラーラック2`A Y今年の振り返りと来年の抱負？(Jugemより移植)2gA ^今年の振り返りと来年の抱負（2012）(Jugemより移植)2qA S今年の振り返りと来年の抱負（2013）2{A S今年の振り返りと来年の抱負（2014）2QA S今年の振り返りと来年の抱負（2015）2HA S今年の振り返りと来年の抱負（2016）2BA S今年の振り返りと来年の抱負（2017）2tA S今年の振り返りと来年の抱負（2018）2gA S今年の振り返りと来年の抱負（2019）2kA S今年の振り返りと来年の抱負（2020）2YA S今年の振り返りと来年の抱負（2021）2]A S今年の振り返りと来年の抱負（2022）2QA S今年の振り返りと来年の抱負（2023）2_A ^今年もBerlin Buzzwordsにオンライン出張してた2^A S今年もMICESにオンライン出張してた2\A ^今年もオンラインでBerlin Buzzwordsに参加した2UA ^今年もオンラインでBerlin Buzzwordsに参加した2ZA S今興味があること(Jugemより移植)2^Ai仕事中のBGM環境2XA W最新インフラエンジニア技術勉強に参加しました。2qA U勉強会の受付自作？アプリ？HTMLについて2rA Q勉強会運営座談会ってのをやってみた2WA Y可視化ツール現状確認会に参加してきました。#可視化2vA Z名古屋でElasticsearch勉強会を開催します2ZAl外の世界を知るということ2bA o大阪と京都でElasticsearch勉強会を開催しました。 #elasticsearchjp2XA R実践Rust入門の3章を読み終わった2ZA S実践Rust入門の3章を読んでるところ2`An実践Rust入門はじめました2uA Q改訂版Solr入門のPDF版も発売2vA P改訂版Solr入門を執筆しました2NA V新しいsolr.xmlとCore探索ロジック2wA W新規導入した長期出張用のアイテムをいくつか紹介2@A c日本語Wikipediaをインデクシング（Kuromojiバージョン）2QA Y日本語用オートコンプリートのためのAnalyzer2yA _検索システムを構成するパーツ(検索システムに関する妄想その2)2sA `検索対象のデータとデータソース(検索システムに関する妄想その3)2GAn検索座談会ってのをやってみた2cA ^検索技術に関する情報交換を目的としたSlackができました！2TA Y機械学習による検索ランキング改善ガイドを読みました2SA q第0回 Twitter Hack #twtr_hack に遊びに行きました。(Jugemより移植)2iA l第10回Elasticsearch勉強会を開催しました。#elasticsearchjp2_A e第10回Solr勉強会を主催しました。#SolrJP(Jugemより移植)2_A l第11回Elasticsearch勉強会を開催しました。#elasticsearchjp2FA Z第11回Solr勉強会を主催しました。#SolrJP2}A Z第12回Solr勉強会を主催しました。#SolrJP2TA l第13回Elasticsearch勉強会を開催しました。#elasticsearchjp2lA R第13回Solr勉強会を開催しました2PA m第14回Elasticsearch勉強会を開催しました。 #elasticsearchjp2NA m第15回Elasticsearch勉強会を開催しました。 #elasticsearchjp2MA m第16回Elasticsearch勉強会を開催しました。 #elasticsearchjp2DA i第1回 データ構造と情報検索と言語処理勉強会に参加しました。(Jugemより移植)2AA l第1回ElasticSearch勉強会を開催しました！ #elasticsearchjp2~A ^第1章の00から02までやってみた（言語処理100本ノック）2}A ^第1章の03から04までやってみた（言語処理100本ノック）2NA ]第1章の03から06まで(言語処理100本ノック2020)2|A ^第1章の05から06までやってみた（言語処理100本ノック）2HA ]第1章の08から09まで(言語処理100本ノック2020)2aA l第2.1回 Twitter API 勉強会 @東京に参加しました。(Jugemより移植)2xA \第25回Elasticsearch勉強会を開催しました。2dA h第2回 データ構造と情報検索と言語処理勉強会に参加しました(Jugemより移植)2xA l第2回elasticsearch勉強会を開催しました！ #elasticsearchjp2GA ]第2章の10から11まで(言語処理100本ノック2020)2FA ]第2章の12から19まで(言語処理100本ノック2020)2jA l第3回elasticsearch勉強会を開催しました！ #elasticsearchjp2wA V第3章終了(言語処理100本ノック2020)2VA |第4回 Twitter API勉強会 @デジタルハリウッド #twtr_hack に参加しました。(Jugemより移植)2_A k第4回Elasticsearch勉強会を開催しました。#elasticsearchjp2vA V第4章終了(言語処理100本ノック2020)2PA l第5回 Twitter API勉強会 @渋谷 #twtr_hack(Jugemより移植)2SA k第5回Elasticsearch勉強会を開催しました。#elasticsearchjp2LA k第6回Elasticsearch勉強会を開催しました。#elasticsearchjp2zA ]第6回Solr勉強会に参加しました。(Jugemより移植)2GA k第7回Elasticsearch勉強会を開催しました。#elasticsearchjp2wA k第8回Elasticsearch勉強会を開催しました。#elasticsearchjp2mA k第9回Elasticsearch勉強会を開催しました。#elasticsearchjp2kA d第9回Solr勉強会を主催しました。#SolrJP(Jugemより移植)2iA q第一回 JetBrainsユーザーグループ #jbugj に参加してきました(Jugemより移植)2SAm自宅の作業環境(2020)2tA P自宅の作業環境(2020/09)2eA P自宅の作業環境(2021/02)2A [複数辞書の読み込み機能追加（仮）(Jugemより移植)2UA ^親子で楽しめる 絵本で英語をはじめる本(Jugemより移植)2OAn言語処理100本ノック、再び2A W言語処理100本ノックはじめました(Rust)2TAf転職しました2OA X辞書とカスタム辞書について(Jugemより移植)2@A Z辞書のjarファイルからの分離(Jugemより移植)2nA b辞書の外部化とLucene/Solr3.4対応(Jugemより移植)2KAm辞書の更新についての注意点2~A ]辞書分離のテストケース追加と残タスク(Jugemより移植)2UAf退職しました2lAe退職します>xdtypefstringvgsummary3vddocs<ya1Qya2rya3Eya4Tya5Iya6eya7pya8]ya9{yb10zyb11ryb12Myb13Nyb14Fyb15hyb16Fyb17Qyb18_yb19~yb20Gyb21Iyb22tyb23yyb24Tyb25Oyb26nyb27~yb28Lyb29Gyb30Kyb31Hyb32zyb33Qyb34jyb35[yb36}yb37Byb38|yb39jyb40Eyb41kyb42Yyb43Syb44Lyb45Zyb46yyb47\yb48]yb49Byb50myb51oyb52Cyb53Iyb54Nyb55Myb56Hyb57nyb58Cyb59|yb60syb61yyb62zyb63{yb64}yb65~yb66}yb67yb68Wyb69yb70Lyb71nyb72Kyb73Eyb74oyb75fyb76Pyb77@yb78Jyb79Ayb80Ayb81jyb82Byb83Ayb84Cyb85hyb86Dyb87Hyb88vyb89iyb90wyb91lyb92cyb93myb94eyb95Ryb96Oyb97lyb98byb99ayc100Byc101Cyc102ryc103Ryc104qyc105Ryc106|yc107syc108gyc109uyc110Kyc111@yc112tyc113Zyc114Vyc115Iyc116Pyc117Jyc118Iyc119Pyc120myc121uyc122wyc123Zyc124Pyc125Oyc126Wyc127Tyc128vyc129byc130Fyc131~yc132Hyc133Xyc134uyc135vyc136Dyc137}yc138Myc139yyc140Wyc141uyc142tyc143xyc144`yc145Gyc146Tyc147yyc148syc149iyc150fyc151Vyc152_yc153ayc154dyc155Xyc156Zyc157Wyc158gyc159ryc160Uyc161Tyc162jyc163hyc164Yyc165pyc166fyc167`yc168Syc169qyc170cyc171]yc172Ryc173@yc174Qyc175Tyc176Pyc177{yc178jyc179qyc180^yc181_yc182iyc183yc184eyc185]yc186Jyc187Eyc188syc189byc190^yc191Qyc192Eyc193\yc194`yc195]yc196\yc197xyc198eyc199~yc200[yc201zyc202Nyc203[yc204}yc205kyc206Syc207Wyc208Dyc209Iyc210Fyc211|yc212Pyc213Kyc214Oyc215Kyc216[yc217Qyc218Myc219Syc220xyc221Xyc222hyc223{yc224Wyc225gyc226Yyc227Xyc228cyc229Yyc230yc231Qyc232zyc233Uyc234@yc235~yc236Zyc237dyc238vyc239Ryc240cyc241`yc242^yc243Vyc244Syc245Qyc246Gyc247Jyc248xyc249Dyc250gyc251Pyc252kyc253oyc254Vyc255Hyc256vyc257Uyc258wyc259Pyc260\yc261Ayc262nyc263]yc264^yc265eyc266Ryc267Uyc268Dyc269Fyc270uyc271myc272cyc273zyc274wyc275Cyc276xyc277Vyc278qyc279_yc280tyc281dyc282dyc283oyc284yyc285Dyc286^yc287Gyc288Vyc289tyc290Xyc291Nyc292kyc293hyc294Syc295fyc296vyc297fyc298[yc299Ayc300uyc301Yyc302oyc303Byc304Jyc305Eyc306iyc307Nyc308Zyc309@yc310wyc311hyc312[yc313ayc314Vyc315_yc316syc317yc318pyc319eyc320ryc321Oyc322dyc323Cyc324qyc325`yc326\yc327gyc328myc329ayc330[yc331byc332dyc333iyc334syc335Myc336Yyc337Yyc338iyc339kyc340Byc341Fyc342]yc343qyc344fyc345Xyc346ayc347Myc348\yc349lyc350lyc351ayc352^yc353Xyc354oyc355gyc356Oyc357_yc358Uyc359\yc360pyc361|yc362Wyc363tyc364Ayc365nyc366}yc367cyc368byc369Hyc370pyc371xyc372Lyc373Gyc374Zyc375Lyc376Tyc377Lyc378Uyc379Kyc380Nyc381pyc382|yc383jyc384^yc385@yc386{yc387byc388nyc389`yc390Uyc391kyc392Syc393Ryc394_yc395myc396wyc397lyc398ryc399Jyc400yc401lyc402{>wkorderedDocs<w2ypwAxp!G（転職する少し前までパスポートすら持ってなかったのに）今の会社に転職してから、半年に1度の割合で海外への出張が発生する生活を送っています。 42A!H「【東京】JJUG ナイト・セミナー「機械学習・自然言語処理特集！」12/17（水）開催」でLuceneの話をしてきました。 本当にごく簡単な入2IA!F「Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）」に参加しました。300名入るイベントルー2[A!I「アジャイルデータサイエンス」の見本をいただいてしまいました。 なので、感想文でも書いてみようかと。 どんな本？ 想像以上に薄かったです、物理的に2TA!H「機械学習による検索ランキング改善ガイド」を読みました。 著者の鈴木さんより献本いただいたのを読み終わったのでレビューと、あとおまけです。 紹介2zA!I「第6回Solr勉強会」に参加しました。 なんだかんだと第6回で、今のところ皆勤賞です。 ということで、主に自分用ですが、メモなどとったので。 概2zA!H「鉄は熱いうちに打て」ということで、残りも勢いでメモ。 まだ、見直しとかしてない状態なのでおかしいところとかありますが。。。 図とか入れるのはま2~A!G「鉄は熱いうちに打て」ということで、言語処理100本ノックの第1章の00から02を実装してみました。 さて、これが効率がいいのかどうかはさてお2aA!H@yusukeyさんにサインをもらう目的で勉強会に参加してきました。前回もらいそびれたのでｗ 残念ながら、まだTwitter APIを触ってない2mA!U##Lucene/Solr 4.0.0リリース ついに、Lucene/Solr4.0.0がリリースされました。 MLで流れていましたが、3年越しのリリースだったようです。2{A!P#MANABIYA のブースでセッション時間の合間はお客さん少ないので、ブログを書いてみたり。 ここ数年、スポンサーとして色々なカンファレンスに参加してるんです2KA!\※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.0.beta1 released 本日、Lucene 4.10.1をベースにした、Elast2DA!^※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.1 and 1.3.6 released 本日、Lucene 4.10.2をベースにしたElas2yA!^※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElas2~A!^※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElas2uA!^※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.4 and 1.3.9 released 本日（2/20）、Elasticsearch 1.4.2pA!V※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.0 Released 本日（3/23）、Lucene 4.10.4ベースのEla2nA!V※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.1 Released 本日（4/9）、Lucene 4.10.4ベースのElas2lA!V※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.2 Released 本日（4/27）、Lucene 4.10.4ベースのEla2hA!V※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.6.0 released 本日（6/9）、Lucene 4.10.4ベースのElas2aA!^※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.0 and 1.6.1 released 本日（7/16）、Lucene 4.10.4ベースのE2`A!^※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.1 and 1.6.2 released 本日（7/29）、Lucene 4.10.4ベースのE2WA!e※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0 GA released Elasticsearch 1.0.0のリリース以降、 477のコミッター2,792]A!\※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0-beta1 released 本日（8/26）、Lucene 5.2.1ベースのElas2[A!\※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0-beta2 released 本日（9/17）、Lucene 5.2.1ベースのElas2dA!k※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0.beta1 coming soon! Elasticsearch 2.0.0.beta1のリリースの準備をしています。2\A!h※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch unplugged - Networking changes in 2.0 Elasticsearchをローカルのマシンで起2HA!Y※この記事は次のブログを翻訳したものになります。 原文：elasticsearch-1.4.0 and 1.3.5 released 本日、Lucene 4.10.2をベースにし2AA!x※この記事は次のブログを翻訳したものになります。 原文：exciting logstash plugin ecosystem changes Logstash 1.5.0 Beta 1(お試しはこちら)のリリースで、 プラグインのインストー2kA!k※この記事は次のブログを翻訳したものになります。 原文：Join the Conversation: Discuss.Elastic.Co 3つのOSSプロジェクトの開発をスケールアップし始め、 コミュニティサポー2tA!Z※この記事は次のブログを翻訳したものになります。 原文：kibana 4. literally. Kibana 4は現在、文字通り、抽象的に、概念的に、精神的に、そしてとても楽しく2XA"@※この記事は次のブログを翻訳したものになります。 原文：Kibana 4.2.0 released Elasticsearch 2.0 + Kibana 4.2 = 💚 Elasticsearch 2.0サポートのKibanaの最初のリリースです。 これ2BA!h※この記事は次のブログを翻訳したものになります。 原文：logstash 1.5.0.beta1 released Logstash 1.5.0 Beta1をリリースしました。こちらのページからダウンロードで2YA!^※この記事は次のブログを翻訳したものになります。 原文：Logstash 2.0.0 released Logstash 2.0.0が本日（10/28）リリースされました。 このリリースは2}A!\※この記事は次のブログを翻訳したものになります。 原文：marvel 1.3.0 released 12/17に、Elasticsearch Marvel 1.3.0をリリースしました2jA!m※この記事は次のブログを翻訳したものになります。 原文：Reindex Elasticsearch With Logstash Thanks David! マッピングを変更したり、インデックスの設定を変更したり、あるサ2ZA!O※この記事は次のブログを翻訳したものになります。 原文：Relase, we have ※画像に関しては原文をご覧ください。 Elasticにとって大きな1日2xA!l※この記事は次のブログを翻訳したものになります。 原文：running groovy scripts without dynamic scripting Elasticsearch1.3.8と1.4.3のリリースによ2VA!h※この記事は次のブログを翻訳したものになります。 原文：Shield, Watcher, and Marvel 2.0.0 GA Released 本日（10/28）Shield、WatcherおよびMarv2^A!d※この記事は次のブログを翻訳したものになります。 原文：The Delete by Query API Is now a plugin Elasticsearchの2.0.0-beta1では、これまで2cA!`※この記事は次のブログを翻訳したものになります。 原文：The Great Mapping Refactoring Elasticsearchのユーザの悩みの最も大きなものの一つは、 タイプと2UA!p※この記事は次のブログを翻訳したものになります。 原文：The Story of Sense - Announcing Sense 2.0.0-beta1 誕生 よくある良いプロジェクト同様、Senseもビールを飲みながら考2rA!j※この記事は次のブログを翻訳したものになります。 原文：you know, for security: shield goes ga 1/27にShield 1.0 をリリースしました。 Elasticsearc2dA!G1/18（金）に開催された、エンジニアサポートCROSS 2013で「検索CROSS」セッションのセッションオーナー（モデレータ）をやって来ま2aA!G12月に退職しますブログを書きましたが、その後どうなったのか?という話をしてないなと思ったので、一応現在の状況を書き留めておこううかと。 結論2rA!^2020/10/06 11:00くらいにマージされました。 @minoru_osuka さんが開発を引き継いだLinderaというKuromojiのRustクローンがあります(リポジトリ)2ZA!G2021年もあと少しですが、今年買って良かったものをリストアップしておこうかと思います。 今年買ったといいながら、昨年このネタを書くといいつつ2JA!H2月のElastic社のブログですが、Enterprise Searchとこれまで呼んでいた製品をWorkplace Searchという製品名に2eA!W4ヶ月前に、Found joined our team at Elasticをアナウンスしました。 Foundの素晴らしいチームと一緒に仕事をしていますが、彼らによって、より2sA!L4月13日から3日間、ElasticsearchのCoreトレーニングが東京で開催されます。 Early Birdということで、3/14までに申し込みす2fA!G5年くらい、Octopressを使用していましたが、更新されなくなっているのと、コンテンツの生成に時間がかかることもあり、 ほかのプラットフォ2|A!O6月7日の週に開催されたBerlin Buzzwordsにオンライン出張してました。 Berlin Buzzwordsとは? ベルリンで開催されている、Big2VA!G7.16で正式リリースされましたが、Elasticsearchの新しいJavaのクライアントが出ています。 使ってみたので、ちょっとだけ紹介で2yA!I7/25にJJUGナイトセミナーでElastic Stackの紹介とAPMのJava Agentの紹介をしたので、補足のブログです。 （久々に書く2hA!_Atlassian Advent Calendar 2012の20日目。（急遽参戦） （某イケメンにMT（改変リツイート）されたので書いてみました） 久々に、勉強会以外のエントリです。（So2RA!VAWS Summit Tokyo 2013に行って来ました。 @cocoatomoさんに行き掛けに出会ったので、アンデルセンの講演を一緒に聞いてました。 TDブースの@ry2TA!KAWS Summitに来ていたのですが、TLでは、Cloudera Searchが賑わってました。 ということで、軽くどんなものか読んだり調べたりした2WA!VAzure Cognitive Searchで2月に新しい機能が公開されました。 「Index Alias」（インデックスの別名）です。まだ、パブリックプレビューの段階です2`A!WAzure Cognitive Searchで新機能「Semantic Search（セマンティック検索）」という機能の日本語対応が発表されました。 実際にはPublic P2A!TAzure Cognitive Searchで日本語を扱うときに、形態素解析器を使いたい場合、2種類のAnalyzerが用意されています。今回はこれらの違いがどんなもの2fA!UAzure Cognitive SearchにSuggestやAutocompleteの機能があるのを見つけたので、どんな挙動なのかを調べてログとして残しておきます。 公2dA!UAzure Cognitive SearchにはOData式という書式で条件が書ける仕組みがあります。 ODataは検索条件（$filter）やソート条件（$orderb2[A!UAzure Cognitive Searchのスキーマの確認をするときに、Azureのポータルでは次のようにフィールドの一覧として見ることができます。 ただ、実際のインデ2fA!HBerlinからおはようございます。 ということで、人生で初めての海外に来ています。 人生初の海外なのに、一人で乗り換えがあるようなBerlin2oA#FBonfire Data &amp; Science #1にブログ枠で参加してきました。 ということで、メモです。 日時 : 2019/10/25 19:00 - 21:30 場所 : Yahoo! Japan サイト : https://yj-meetup.connpass.com/event/148121/ ハッシュタグ: #yjbonfire 概要 Data &amp; Scienceと2lA!HBookscanというサービスがあります。 書籍を電子化（PDF）して原本を破棄してくれるサービスです。 電子書籍にはずっと興味を持っていました2TA!XClean Coder プロフェッショナルプログラマへの道 Clean Coderを読みました。 理由はTwitterで「Clean Code」がいい本だと流れてきたためです。2SA!PCloudera Searchは次のようなモジュールから構成されています。 これはCloudera Searchのモジュールで、さらにこれらがSolrとかを使っ2yA!ZCloudera World Tokyo 2013に参加してきました。 午前中はあいにくの雨でしたが、それでも結構な人数が最初の基調講演から参加されてました。 私が参加したセッショ2hA!QCorne使ってましたが、数字キーがあるとどうなのかな？というのがやはり気になって。 そこに、Kochi KeyboardさんからSofle Keyboard v2RA!GCuratorの1.2.0がリリースされました。 前回のCuratorの記事が古くなってしまった（1.1.0からコマンドのI/Fが変更された）2]A"WDomain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだので軽くメモを残しておきます。論文自体はリンクから参照してください。 読んだ理由 Azure Cognitive S2DA!pElastic stack (Elasticsearch) Advent Calendar 2017の1日目の記事になります。 まだ、1ヶ月を残していますが、簡単に今年起こったことを振り返ってみようかと思います。思った以上に2vA!qElastic stack (Elasticsearch) Advent Calendar 2018の1日目の記事になります。 ちょっと遅れちゃいました。。。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみよ2uA!rElastic stack (Elasticsearch) Advent Calendar 2018の25日目の記事になります。 今年最後のAdvent Calendarです！来年も忘れてなければやるはず！ 今日は、すでにalp2nA!pElastic stack (Elasticsearch) Advent Calendar 2019の1日目の記事になります。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみようと思います。毎年恒例ですね、2lA!~Elastic stack (Elasticsearch) Advent Calendar 2020の18日目の記事になります。 本日の勉強会でLTをしましたが、しゃべり足りなかったんで。 Elasticsearch 7.8でこっそりとリリースされたI2JA!oElastic stack Advent Calendar 1日目の記事になります。 Elasticsearch 5.0が10月末にリリースされました。 リリースのブログでいくつか紹介されているのですが、そこでは紹介されて2JA!TElasticsearch 1.4.0.Beta1がリリースされました。 個人でelasticsearch-extended-analyzeというプラグインを開発してま2VA!_Elasticsearch server 2nd editionが発売されています。 私が翻訳したのは前のバージョンですが。。。 まずは、目次を元にどのくらい変わってるかを見てみました。 （2LA!HElasticsearchで日本語を扱うときに、カスタム辞書を使いたいという要望がよくあります。 AWSのElasticsearch Servi2gA!Felasticsearchに、このへん入れるときっと幸せになれるはず・たぶん。&#10;elasticsearch/elasticsearc2oA!GElasticsearchのcuratorのブログ記事を読んで、日本語でツイートしたところ、Aaron Mildensteinさんから日本語（2NA!nElasticsearchのインデキシングに関するパフォーマンス検討 原文：performance considerations for elasticsearch indexing Elasticsearchユーザは様2oA!KElasticsearch勉強会 in 名古屋を開催しました。 初の東京以外での勉強会です。 企画、セッションなどお手伝いいただいた@smogamiさ2AA!IElasticSearch勉強会 第1回を主催しました。 昨年のpyfesでなんちゃって資料で喋って、1年たちました。 ElasticSearch2rA!FElasticsearch勉強会や検索技術勉強会やってるんだけど、独学で勉強会やってるなーと思い、みんなはどうやってるんだろうとツイートして2DA!HElasticのWorkplace Searchを触ってみています(その1、その2)が、Elastic Stackの7.7.0がリリースされてし2YA!VFluentd meetup in Japanに参加しました。いつも面白そうな話を聞いてばっかりなので、役に立つためにスタッフとしても参加してみました。 まずは、会場が綺麗2eA!QGOTO Night elasticsearchに参加しました。 初の海外の勉強会です（海外自体が初だし）。 ベルリンにあるWoogaという会社で開催された勉強会2vA!`Hadoop Conference Japan 2011 Fallに行ってきました。 まずは、ユーザ会の方々、運営の方々、発表された方々お疲れ様でした。こんな機会を用意していただき、ありがとう2xA!SHadoopからはちょっと離れているのに、面白そうなネタなので参加しました。 Data Science Summit、HBaseCon、Hadoop Summitのイ2gA!HHadoopソースコードリーディング第7回に参加しました。 いつものごとく、自分用のメモをとっていたので。 第6回（2010/12）には参加して2GA!HHadoopとか離れちゃってるし、Hive触ったこと無いにもかかわらず参加しました！ （たまたま近くにいるからって理由なのは内緒で） 玉川さんの2^A!GHerokuではじめるRailsプログラミング入門 heroku気になってるのに使ってなくて、TDのアカウント作ってデータアップしてない軟弱者2RA!FHugoを0.84から0.92にアップデートをする際に、これまでのブログ記事やレイアウトファイルを修正したので個人的にメモを残しておきます。2EA!IIDの秘密 (丸善ライブラリー―情報研シリーズ) 非常に面白く読めました。 バーコードの話に始まり、最後はシステムで付与するIDに関する考慮点まで2yA!LIssue 32で上がってきたlucee-gosenのUniDic対応の最初のパッチを書いたので、ブログに残しておきます。 ###UniDicとは___2KA!TJavaOne Tokyo 2012に参加してきました。 4/4-4/5の2日間開催されていたのですが、子供が体調を崩してしまい、4/5のみの参加となりました。 4/42oA!RJJUG CCC 2011 Fallに参加してきました。 個人的にはかなり久々のJavaのカンファレンスです。（※あくまで「Javaの」という話で。SolrやHad2BA!TJJUG CCC 2012 Springに参加してきました。 昨年のFallに続き、2回目です。 概要や、タイムテーブルはこちらを御覧ください。 今回は、午後一から参加2FA!KJJUG CCCや第7回Elasticsearch勉強会のKibana4のデモにアクセスログを利用しました。 ただ、セッションでは、どうやってElas2fA!WJustTechTalk#02 形態素解析のあれやこれや@ジャストシステム に参加してきました。 ジャストシステムさんの形態素解析器JMATの話とKagome、Janome、2aA!ZJVM Operation Casual Talksに参加しました。 あんまり、運用とかやってないので、ついていけるか不安ですが、楽しそうだったので。 懇親会は予定されてないらしい2^A!Hkopfの記事の続きも書く必要があるんだけど、こんなツイートを見つけてしまったので。。。 ElasticsearchのBulk APIの仕様、J2YA!RKuromoji-CLI Rust初心者がRust製の日本語形態素解析器の開発を引き継いでみたという記事にありますが、LinderaというRust製の日本語形態素解2QA!HKuromoji-CLIの使い方などについては過去のブログを御覧ください。 KuromojiのCLIコマンドとpicocliとGraalVM G2GA!Hlucene-gosen 1.1.1をリリースしました。 先日お知らせしたバグ修正を取り込んだjarを用意いしました。 ダウンロードはこちらから2MA!Glucene-gosenの1.1.0がリリースされました。 大きな目玉はJapaneseTokenizerが出力する形態素に関するデータを遅延2KA!Jlucene-gosenのtrunkbranches/impl-mecab-dicにNAIST-JDic for MeCabの辞書を利用出来るPre2mA!Hlucene-gosenの最新版（1.2.0）をリリースしました。 プロジェクトページよりダウンロードが可能です。 新規追加機能についてはこちら2bA!Hlucene-gosenの最新版（1.2.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、特定文字列で2~A!Hlucene-gosenの最新版（2.0.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、@haruy2DA!Hlucene-gosenの最新版（2.0.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、Java7で2NA!Flucene-gosenをSolr/Luceneで利用する場合、TokenFilterを利用してTokenizerが出力したToken対して2NA!Hlucene-gosenを利用して頂いてる皆様に連絡があります。 連絡事項 次期lucene-gosenのリリース（2.0を予定）にて、org.2XA!RLucene/Solr 4.3.0がリリースされた（LuceneのChanges、SolrのChanges）ので、lucene-gosen 4.3.0をリリースしま2NA!SLucene/Solr 4.3.1のRCのVoteが始まっていますが、そのMLできになったコトがあり、ちょっと調べたので メモを残しておきます。 マルチコアの設定ファ2nA!RLucene/Solr 4.6.1がリリースされそう(バイナリ配布待ち)lucene-gosenの4.6.1対応版をリリースしました。 ライブラリのインタフェースな2vA!GLucene/Solrの4.0.0-ALPHAが7/3にリリースされました。 これに伴い、lucene-goenの4xブランチのjarファイル2sA!GLucene/SolrのMLでSolrの管理画面を新しくするというチケットが流れていたのでちょっと触って見ました。 ほんとにちょっと触っただけ2}A!Sluceneutil - マニアックなツールのセットアップの続きです。 今回も誰得?なブログなので興味ない場合は飛ばしましょう。 一応、luceneutilのREAD2~A!HLuceneのFSTの修正に関連して、Kuromojiのパフォーマンス問題が出ているようです。 この問題自体はLucene 8.6.0以降で直る2BA!^Mac Book Airのセットアップ関連の備忘録 （今回は備忘録なので、文体も変かも） インストールしたもの（順不同）だいたい、このサイトを参考にした。 Evernote Dropbox2jA!NMacbook Proが新しくなり、OSがCatalinaになっちゃいました。 これまで使ってた、.bash_profileをコピーしてターミナルを立ち上げ2IA"TMerry Christmas! Elastic stack Advent Calendar 2016 最終日の記事になります。 簡単に今年の変遷を振り返ってみます。 Elasticsearch 2.2 (2月) Elasticsearch 2.2.0、2.1.2、1.7.5リリース クエリプロ2CA!rMerry Christmas! Elastic Stack Advent Calendar 2017の24日目の記事になります。 ちょっとですが、2018年のElasticについて書いてみようかと思います。 イベント いくつか2CA!ZMircosoft Buildというイベントが今週ありました(MSの方やお客さんに教えてもらった)。 そこで、Azure Cognitive Searchのセッション(MyBuil2uA"~Modern Information Retrieval: The Concepts and Technology behind Search (2nd Edition) (ACM Press Books) いやぁ、蒸し暑くてなかなか寝れない日がはじまりましたね。（あんまり関係ないですね。。。） Modern Information Retrieval 2nd Editionを2EA!HMorphlinesについてちょっとだけ、さらに調べました。 誤解 Solr勉強会でなんとなく私の認識を話しましたが、ちょっと誤解してたみたいで2oA!GPFIオープンセミナー2012に参加してきました。 対象から微妙に外れてたり、話の内容についていけるか自信がありませんでしたが、参加してきまし2CA!HPlayFramework2.0を触ってみてます。 ちょっとコーディングしたくなったのと、最近のアプリの作成の調査も兼ねて。 まぁ、せっかくなの2PA!GProxy環境で働いている方も結構いると思います。 Twitter上で、Elasticsearchのpluginコマンドでプラグインがインスト2SA!GPySpaアドベントカレンダーの12/08のエントリーです。昨日は渋川さんのアンラーニングで失敗した話でした。 私は、今年は昨年の続きっぽい話2^A!HPySpaアドベントカレンダーの12/15のエントリーです。昨日はtaichiさんでした。 今年はDIYではなく、PCにまつわる話を。 仕事中は2TA!FQuerqyというクエリのリライト用のプラグインがあるのでどんなものかを調べてみました。とりあえずは概要をドキュメントから追いかけてみた感じ2A!Friver-wikipediaの前々回の記事で書きましたが、bulk_sizeに関連して登録件数がやけにきりが良いのが気になると書いていまし2uA!HRustで便利なクレートを見つけたので、紹介がてら、自分のメモのためにブログに残しておきます。 そもそもの問題 Rustで処理を書いていて、なん2NA!NRustで言語処理100本ノックのリファクタリングの続き。 前回はこちら。 コードも載せたほうが見やすいかなぁ? 03. 円周率 2年前はこちら。 どちらか2HA!kRustで言語処理100本ノックのリファクタリングの続き。 前回はこちら。 とっくに終わってたのに、ブログ書いてなかった。。。 08. 暗号文 pub fn cipher(text: &amp;str) -&gt;2FA!IRustで言語処理100本ノックの第2章の残りです。 前回はこちら。 ちなみに、標準入力から受け取る処理は書いてないです。 出力に関してはファイル2wA!IRustで言語処理100本ノックの第3章です。 前回はこちら。 少し間が空きましたが、再開しました。 間が空いた理由は。。。「正規表現」ですかね。2vA!KRustで言語処理100本ノックの第4章です。 前回はこちら。 今回は早めに続きをやりました。 「形態素解析」ですしね。 第4章の概要 吾輩は猫である2}A!LRustで言語処理100本ノックの続きで、03と04です。 03. 円周率 問題はこちら。 入力文字列を.split_whitespace()で分割して2|A!QRustで言語処理100本ノックの続きで、05と06です。 05. n-gram 問題はこちら。 みんな大好きn-gramです。単語と文字があるので、それぞれ別関2aA!MSofle v2を長らく使っていましたが、コンパクトなのもやっぱりいいよなぁというときにKochi KeyboardからLunakey Miniが発売して2JA!KSolr 4.4に取り込まれる予定のチケットで、気になるものを見つけたのでいつものごとく調べてみました。 元となるチケットはこちら。SOLR-48972HA!USolr/Lucene 3.3がリリースされました。（速報） 以下、各サイトへのリンクです。 Solrリリースのお知らせ Luceneリリースのお知らせ リリースのタイミ2xA!USolr/Lucene 3.4がリリースされました。（速報） 以下、各サイトへのリンクです。 Solrリリースのお知らせ Luceneリリースのお知らせ ちなみに、先日の2KA!GSolrのチケットをML経由で眺めてるんですが、便利そうなチケットが流れてきたのでブログを書いてみみようかと。 元になってるチケットはこちらで2sA!GSolr本が出てから、質問を受けてブログ書くと言いながら書いてなかったことを思い出しました。。。 プラグインの配置方法についてこんな質問を受け2jA!HSolr本の武田さんから教えていただいたSplunkの イベントに行って来ました。 Splunkとは様々な機器のログなどを一箇所に集めてリアルタ2EA!GSwiftypeでサイト内検索？ プレスリリース：Elasticがサイト内検索サービス最大手のSwiftypeを買収が出ましたが、Swifty2QA!HTLで面白いと見かけて、Amazonで買ってしまいました。 SEやってるのに、つい最近Amazonを使い始めた軟弱者です。 それにしてもAmaz2qA!GTwitterで「Meetup.comに切り替えたらー」みたいな話があったので、 受付用アプリとかなくてという話になったので、普段Elasti2JA!HTwitterでこのブログ流れてきて、気になったので、流し読みして簡単にメモ。 Amazonのサービスでスケールする検索サービスみたい。 主に、2FA!JWebSolrの話があるらしいというのを嗅ぎつけて、初めてHeroku JP Meetupに参加しました。 herokuもWebSolrも知りつつ、2XA!HWSL2にUbuntuを入れて、開発とかはこちらを利用しています。 また、Docker DesktopもWSL2のバックエンドエンジンを利用して2HA!GYokozunaの気になる点というか、自分だったらこのへん調べるだろうなって観点を上げてみます。 別に調べるわけじゃないので、完全に自己満足な2{A!HZipkinのGithubにあるReadmeを読んでます。 せっかくというか、頭が悪いので読みながら内容をメモ。 まずは、アーキテクチャとトレー2PA!Hあけましておめでとうございます、johtaniです。 第14回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆2_A!Gあけましておめでとうございます。（もう5日ですが。。。） 今年もlucene-gosenを中心に色々と記事を書いていきますので、ツッコミ、コメ2AA!Gあけましておめでとうございます。今年はサボりがちだったブログをちょっとずつ復活させようかと。 ということで、第1弾として、昨年少し作っていたK2pA!Gあけましておめでとうございます。今年もSolrやElasticsearchについて色々と頑張っていく所存です。 とまぁ、お決まりの挨拶はおいて2YA!Iアジャイルな時間管理術 ポモドーロテクニック入門 ポモドーロテクニック入門という本を読みました。 きっかけは、Twitter上で何度か「ポモドーロ2VA!Gいくつかある環境をDev Containerで動くように変えていますが、最初に導入した時に疑問点だった「コンテナ名」について解消したのでメモを2iA!Iイケメンが主催した「第一回 JetBrainsユーザーグループ #jbugj」に参加してきました。 いろんな製品があるんだなぁと。入り口には良いイ2cA!HいつものようにSolr勉強会に参加してきました。 皆勤賞を継続中です。（暇人というはなしも。。。） 今回は話しを聞きたいですねぇといったら、いや2eA!Gいまさら感満載ですが、今週の金曜日(1/18)に開催されるCROSS 2013というイベントで「検索CROSS」のセッションを担当することにな2RA!Iえーと、ブログ更新してないなぁとふと思ったので。 １年前くらいからずーっと、つぶやいてましたが、やっとScalaを始めました。 長かった。。。 と2gA!Gオライリー・ジャパンから出ている「コンピュータシステムの理論と実装」を読み始めたのでメモを取ることに。 原著はオライリーじゃないのかというのが2|A!Hお久しぶりです。 気づいたらまた、結構ブログを書いてなかったです。。。 今回は、今開発しているElasticsearchのプラグインに関するお話2]A!Hお久しぶりです。インフルエンザで一家全滅という最悪の状況に陥っていた我が家でした。 流行してるみたいなのでみなさんも気をつけてください。 さて、2]A!\お手伝いしているお客さんがAzure Cognitive Searchを利用してます。 検索周り=Azure Cognitive Searchに関する手伝いをする形で入っており、 いく2DA!Iかなり遅くなりましたが、第1回 データ構造と情報検索と言語処理勉強会 #DSIRNLPに参加しました。 帰ってから２日半ほど寝込んでしまい、更新が2nA!Gこのイベントにウチダスペクトラムの枠でMahoutのコミッターである、Grant Ingersollさんが講演されるということで、興味があった2WA!Hこのブログの生成には、Hugoを利用しています。 ブログ移行日記（その1）に書いてありますが、当時はbrewでインストールしていました。 また、2hA!Hこのブログ書こうと思って、これまでMacのセットアップしてたんだった。。。 普段、macOSの標準ターミナルを使ってます。 で、ターミナルを使う2RA!Xこの記事は、情報検索・検索技術 Advent Calendar 2023の15日目の記事です。 昨年に続き2回目の情報検索のAdvent Calendar参戦です。 今年は、夏2|A!Uこの記事はElasticsearch Advent Calndar 2014の25日目のエントリです。 あっという間に最終日です。来年につなげるという意味で、Elasti2pA!Gこの間のElasticsearch勉強会でAcroquest Technologyの人たちが技術書展7で販売されていた書籍を頂いてしまいました2mA!\これは、情報検索・検索エンジン Advent Calendar 2019 の 4 日目の記事です。 1日目から、質の高いエントリーが続いていましたが、一旦休憩して頂く感じの記事になって2XA!Kこれまで 実践Rust入門はじめました 実践Rust入門の3章を読んでるところ 3章終了 3章の終わりまで読み終えた。 いきなり実践的なプログラムで少2ZA!Iこれまでのはこちら。読書メモなので、本と合わせて読んでいただくのが良いです。 実践Rust入門はじめました 3章のクイックツアーを読んでます。 バ2\A!sこんなツイートを見つけたので、Aggregationのサンプルでも書こうかなと。（前から書こうと思ってたんですが。。。） @elasticsearch Hi, Would you please tell me the way to2SA!Hこんにちは、@johtaniです。 早いもので、師走です。今年もあと少しとなりました（今月が一番忙しかったりしますが。。。）。 ということで、A2QA!HざっとインストールガイドとかCloudera Searchのソース眺めて、テキトーにメモを書いてみました。 （ユーザガイドはまだ読んでないです。2qA!Iサンフランシスコからこんにちは。 今、私は、弊社初のユーザカンファレンスelastic{ON}に 参加するために、初のアメリカ出張中です。 初のユ2~A!Hすぐにテストケース追加しますといいつつ、はや一週間。 ようやく仕事が落ち着いたので、テストケースを追記しました。まだパッチの段階です。 一応、異2nA!Jすぐやりますと言いつつ、はや1ヶ月。。。 腰が重い、ダメエンジニアですね。。。 すみませんでした。。。 ようやくtrunkにコミットしました。 すぐ2kA!FすずけんさんがVagrant+puppet使って、VM起動してElasticsearchのクラスタを組んでる記事を書いているのを見て、試して2}A!Gすでに読まれた方もいるかも知れませんが、気になったのでメモを書いてみようかと。 先週の木曜日にTwitterのエンジニアブログでZipkinと2AA!Hすみません、また、MBA関連の記事になってしまいました。 ということで、備忘録その２です。 前回からいくつかインストールや環境の設定をしたので、2SA!Gすもけさんが在宅勤務環境をブログに書いてておもしろそうだな(あと、アフィリンク貼れるな)と思ったので自分の環境も書いてみようかなと。 私自身は2dA!Kその他の記事はこちら ブログ移行日記(その1) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) ブログ移行日記(その2)2eA!Lその他の記事はこちら ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) 起因 いつものツイートから2]A!Gだいぶ、ブログを書くペースが落ちてきてて、危機感を感じている今日このごろです。。。 今回は、個人的に利用しているJIRAのバックアップについて2@A!Iたまには、他愛のないブログを。 仕事しながら、コーヒーを飲んでます。 最近は、サムライズムさんのオフィスに入り浸って仕事してます。 オフィスには、2MA!Iちょくちょく書こうと言いながら、前の記事が1週間以上前になってる。。。 昨日は、Basho Japanに遊びに行って来ました。 （Riak触ったこ2uA!Gちょっと興味があるので、訳してみました。（Wikiのページはこちら） 更新されているようなので、もとの文章も残しておきます。（ページ下部の続き2qA!Hちょっと間があいてしまったが、ようやくIoの1日目を終了。 なれない感じの言語なので苦労しました。 今回もセルフスタディの私の回答が最後の方に記2sA!]どーも、johtaniです。 Search Engineering Tech Talkという勉強会に運営として参加して、第1回の勉強会を開始しました。 本日（2/26）は第1回目だったの2wA!Gどーも。以前の記事で開発中としていたプラグインですが、とりあえず、pluginコマンドでインストール出来る形にしてみました。 インストールなど2{A!Gということで、Ruby2日目の感想（2日目だけで2日間かかったのは内緒。。。） 今回もセルフスタディの私の回答が最後の方に記載されてます。見た2yA!Hということで、Rubyの最終日の感想。 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大2[A!~ということで、いつものように勉強会に参加したメモです。 http://atnd.org/events/23608 日時 :2012/01/26 19:00 to 22:00 会場 :アカデミーヒルズ(六本木ヒルズ内) 49階（タワーホールA） （港区六2sA!Gということで、ステッカー欲しさ？に勉強中の話を恥ずかしげもなく偉そうにしゃべってきました。 #pyfesは以前から、気になっていたんですが、タ2dA!Gということで、懲りずに#DSIRNLPに参加してきました。 基礎的な部分をおろそかにしたくないけど、TokyoNLPとかWebMiningでは2TA!Hということで、転職しました。 どーしてもやりたいことが出てきたので、無理を言って転職することにしてみました。 サムライズムではなく、Elasti2YA!Hどうやら、中身がSolrベース？Luceneベース？になったらしいということで、 今日は「AWSプロダクトシリーズ｜よくわかるAmazon Cl2iA!Gドットファイル系（.emacsとか）をこれまでは、PCを引っ越すたびにコピーしてたんですが、いいかげん、GitHubとかで管理したいなと。 で2tA!Iども。 プラグインのインストールに長いURL入れるの辛いですよね？ね？ ということで、MavenでリリースしてMaven Repositoryから2A!bども。新しいもの始めないと頭が退化する。。。ということで、こちら（ happy new year and new language - katsyoshiのめもみたいなもの）のブログに触発されて、2fA!Hどんな本でも大量に読める「速読」の本 Twitterで知り合った方がこの本について書かれていたブログ記事を読んで興味を持ち、読みました。 書籍（2`A!Nなんか、とても久しぶりにイベント参加メモ以外の投稿です。 elastic searchのMLを見てたら、KuromojiのAnalyzerを使うときにユーザ2LA!Iなんか、今年はよく物が壊れる、厄年だからかなぁ？ ということで、記念に何が壊れたかをブログに残しておこうかと。 腕時計（壊れてないかな） 電波腕時2cA!Hなんだか、ドタバタしてて久しぶりの更新です。 ベルリンの旅行記みたいなのも書きたいのですが、まずはこちらかと。 elasticsearch-ko2PA!Hはい。またまた、Twitter API勉強会に参加してきました。（今回から開催回数の記載がなくなった？） 今回は直前でタイムテーブルが変わってし2mA!Wはじめまして、pyspa。 ということで、pyspa Advent Calendar 2020の4日目(大谷コンビの2号)の投稿になります。 コンビそろってキーボード記事です2jA!Hヒカリエに行ってみたいという不純な理由で参加してきました。 新しいということもあり、おしゃれで綺麗なカフェでした。 入り口にはおっきな人形も立っ2oA!Gヒゲが不評だったのでいつも通りの長さに切りました。 前回「Windowsをお試し中」と書きましたが、いくつかソフトをインストールしたりしたので2pA!Gヒゲが伸びてきて(試しに伸ばしてる)不評を買っている今日このごろです。 自宅で作業することが多くなってきたので、自作PCでもと思っていますが、2@A!Gひさびさに、lucene-gosenの話題です。 lucene-gosenはjarファイルに辞書も同梱されており、jarファイルをクラスパスに2eA!Iひさびさに、MBAのお話です。 セットアップといっても、物理的な方ですね。 以前、ケース（カバー）について記載しました。 この記事にも書いてあった2gA!aひさびさに、勉強会メモ。 Hatena Engineer Seminar #5 @ Tokyoに当選したので行ってきました。 いつもは近寄らないオシャレな街をドキドキしながら行ってきました。 と2cA!Jブログ移行日記(その3)です。その他の記事はこちら。 ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その4) ブログ移行日記(2bA!Jブログ移行日記(その4)です。その他の記事はこちら。 ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(2\A!Jブログ移行日記(その5)です。前回まではこちら ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その42ZA!Iまだ、Vote公開されていない、Solr 4.3（2013/04/25 11:00現在）ですが、 ひさびさに訳してみた。詳細まで追っていないので、2^A!Hまた、ツイートから始まるお話です。 まだまだ、検索システムってどんなものかを勉強したいしということで、こんなのをツイートしてました。 「検索シス2XA!Hまた、勉強会ログです、すみません。。。 直接業務とは関係ないのですが、今回はリクルートの中野さんが話しをされるというので顔を出してきました。 も2zA!Sまたまた、Riak Meetup Tokyo #3に参加してきました。Riak2.0のYokozunaの話があると聞いたので。 ということで、いつものように個人メモで2wA!Jまたまた参加しました。いまだ皆勤賞です。 感想などはあとで。とりあえず、メモとったので第一弾です。 ということで、感想です。 まずは、参加人数。 今2rA!Gまたまた飲みに行って参加してきました。 今回は、Rails、iOSでのTwitter連携の話から、ツイート分析、クライアントアプリの開発の苦労2bA!Iみなさんは、スライドの作成には何を使っていますか？ Keynote？Powerpoint？Google Slides？ 私は、Macでスライドを作2iA!FメインマシンとMacは下記のサンワサプライのUSB接続のKVMスイッチを使っていますが、もう一台ノートPCがありここに接続しているCorne2[A!dもう2020年2月になってしまってますが、2019年に買って便利だったもの良かったものをいくつか記録に残しとこうかなと。 BRAVIA KJ-55X9500G Amazon | ソニー SONY 492OA!Gもう何番煎じだ？ってくらい書かれてますが、コリもせず書いてみました。 Elasticsearch＋Kibanaの環境を作って、タムタムさんのロ2FA!G不定期開催ですが第11回Solr勉強会を主催しました。 今回も大入り90人くらい？の参加者の皆さんがいらっしゃいました。ありがたいことです！（2}A!G不定期開催ですが第12回Solr勉強会を主催しました。 今回は、前回ほどの過熱ぶりでは無かったですが、70人ほどの参加者の方がいらっしゃったか2rA!I久々に、MBAの備忘録です。 あれから色々入れました。 なので、入れたソフトの一覧を追加。 AIR：TweetDeckをインストールするのに必要だ2WA!H久々にlucene-gosenの話です。 しかも、あんまり嬉しくない話しです。 すでにissueをアップしていますが、lucene-gosenと2@A!G久々にlucene-gosenを触っています。 trunkのlibにある、jarファイルが3.5ベースだったので、3.6ベースにしてテストをし2|A!H久々にSolrの話です。 といっても、結構前からの話でして。。。 schema.xmlのfieldTypeの設定に「autoGeneratePh2aA!H久々にブログ＋イベント参加です。 知り合いが開催＋出演したので参加してみました。 「スマホ」ってキーワードはあまりなかったけど、面白かったです。2FA!G久々に執筆しました。といっても、以前の書籍の更新版です。 まぁ、更新版といっても、私以外の方々は結構な量を書き直しor新規書き起こしされてます2GA!I久々のブログ。 Elasticsearch勉強会を主催してますが、 プロダクトを超えて、検索で共通してある課題とか、悩みとか、あるかなぁと。 その2BA!G久々のブログはElasticSearchネタです。勉強会開催する予定だったりすので、もう少し触っておきたいなと。 お手軽に検索するデータとして2OA!H久々のポスト。。。 久々に、技術書読んでます。「自然言語処理の基本と技術」という本です。 監修の方のツイートを見て気になったので、買ってみました2KA!N久しぶりに、技術的なブログ書いてます。 Ingest Processorのプラグインを作ってみたくなったので、書いてみました。 ただ書いてみるんじゃ3番煎じ2IA!J久しぶりに翻訳ではないブログを。書こうと思いながらかけてなかったので。。。 今回はvalidate APIの紹介です。 背景 Elasticsear2RA!H今さらですが、ブログをはじめてみようかと。今さらですが… はじめてみようと思った一番の理由は、自分で調べたことをメモがわりに残すためです。 あと2iA!H今回は、触ろうと思って触れていないMongoDBの勉強会に行って来ました。 2週連続の渋谷で、さすがに今回は出口をすんなりでれました。 今回は初2BA!Z今回はAzure Cognitive SearchのSDKを利用したアプリケーションが、実際にAzure Cognitive Searchに対して送信しているリクエストのパラメータ2SA!G今回はQuerqyのElasticsearchのプラグインがどんなつくりになっているか？をちょっとだけ調べてみました。 SolrでもElast2PA!G今回はソースのダウンロードとビルドについてです。 最新版のソースを利用したり、JavaDocを見たい場合はソースをダウンロードしてからビルドす2jA!G今回はたまたま日本にいたElasticsearchの人をスペシャルゲストに呼べたので、大満足ですｗ 英語の通訳とかちゃんと勉強しないとなぁ。。2OA!G今回もツイートから。 言語処理100本ノックの2020年版を公開しました。最近の自然言語処理の研究動向を反映し、深層ニューラルネットワークに関2qA!G今年の春くらいから、セパレートタイプのキーボードが気になっています。 また、なんか知らないですが、Twitterのタイムラインが自作キーボード2zA!G今年の頭からシステムの検索周りを手伝う仕事をフリーランスとしてやっています。 検索の仕組みを知れば知るほど面白くなってきたからという理由になる2HA!I今年はRioのプレイバック見ながら書いてます。 今年はなんか長い一年だった気が。 振り返り（2015年に書いた抱負から） まずは去年の抱負を元に2{A!I今年は大晦日になってしまいました。しかも、ちょっと飲んでたり。。。 第9流しながら書いてます。 振り返り(2013年に書いた抱負から) まずは昨年2BA!J今年は紅白を見ながら書いてます。 今年はいろんなところに出張に行ったなぁ。 振り返り（2016年に書いた抱負から） まずは去年の抱負を元に。 もちろ2QA!K今年は紅白見ながら書いてます。 早い一年だったなぁ。 振り返り(2014年に書いた抱負から) まずは去年の抱負を元に振り返りをば。 英語の継続 海外の2_A!I今年もBerlin Buzzwordsにオンライン出張してました。 今年の開催は6月14日から17日まででした。 どんなカンファレンスなのかは昨年2UA!H今年もBerlin Buzzwordsにオンライン出張してました。 今年はハイブリッドな開催だったようで、現地で再開している人もいるようでした。2zA!G今年もCROSS参加しました。そして、話もしてきました。 今年は横浜の大さん橋でした。横浜はあんまりこないので、乗り換えでおたおたしてしまいま2^A!I今年もMICESにも参加してました。 昨年はBerlin Buzzwordsと共同開催でしたが、今年は別開催（別日程）でした。 MICESは2012\A!W今年もアドベントカレンダーの季節になってしまいました。 今年で2回目となる、pyspa Advent Calendar 2021の投稿です。 昨年に引き続きDIYがらみの投稿2\A!N今年もこの季節がやってきました。 Berlin Buzzwordsにオンラインで出張してました。 今年もハイブリッド開催をしてくれたので、オンラインで参加で2]A!H今年もなんとか振り返りブログを書いてます（時間大丈夫かな？w）。紅白をリアタイで見ながら。 振り返り（2021年に書いた抱負から） まずは振り返2YA!H今年も振り返りブログです。録画した紅白をオッかけ再生して気になるアーティストだけ見ながら書ています。 振り返り（2020年に書いた抱負から） ま2tA!J今年も振り返りブログをかけてます。よかったw 振り返り（2017年に書いた抱負から） まずは去年の抱負を元に。 もっと英語の継続＆TOEIC まぁ、2QA!H今年も振り返りブログをリビングで書いています（ドミノ倒しすごいな）。 FMVのキーボードで書いているのでタイポがつらい。。。 振り返り（20222gA!O今年も振り返りブログ書いてます。Sasukeがついてる。 振り返り（2018年に書いた抱負から） まずは去年の抱負を元に。 TOEIC 受けました。 お。TO2kA!H今年も振り返りブログ書いてます。カタンの航海者版を購入して家族とやってましたが、負けてしまいました。 振り返り（2019年に書いた抱負から） ま2RA!X今年最後のAdvent Calendarとなります。 この記事はElasticsearch Advent Calendar 2015の最終日のエントリです。 簡単に今年の変遷を2iA!G今年初の「突撃！隣のElasticsearch」ということで、Wantedlyさんにおじゃましました。 ※写真を自分でも撮ったのですが、画像が2~A!G今日は、ElasticSearchのMLで見つけたelasticsearch-inquisitorプラグインの紹介です。 ElasticSea2`A!H今日はelasticsearch-kopfのAnalysis画面の紹介です。 （簡単なところから。。。その２） メニューのanalysisを選択2]A!H今日はelasticsearch-kopfのAnalysis画面の紹介です。 （簡単なところから。。。その３） ちょっとあいだが開いてしまいまし2bA!H今日はelasticsearch-kopfのREST画面の紹介です。 （簡単なところから。。。） メニューのrestを選択すると、次のような画面2tA!a今日はSolr 4.0 ALPHAの興味深い機能があったので紹介です。 数日前に「Solr 4.0: Partial documents update」という記事を見つけました。 Solrには、2XA!H今月2回目の目黒で、初のドリコムさんです。 「最新インフラエンジニア技術勉強～Fluentd, Elasticsearch,Chefの実践実例～2DA!H今朝起きたら、Xperia Zが故障してしまいました。 電源ボタンを押してもスリープにならないんです。しかも、スリープからの復帰もできない。。。2VA!Q今週も勉強会に参加しました。 @yusukey さんが開催してるTwitter API勉強会です。 前回とは会場が異なりましたが、広くて大画面で良い会場でした。駅2`A!H他の方たちよりひと足はやいですが、今年の仕事が終わりました。 せっかくブログを始めたので、振り返りと来年の抱負など書いてみようかなと。 今年の振2JA!G以前、こちらで話題に上がっていた「未知語」に関するcompositePOSのエラーの件を調査しました。（Twitterでも流れてました。） 次2EA!G以前から春山さんのブログ（リンク）や勉強会で耳にはしていたのですがソースは読んでいませんでした。 先日、Luceneにcontributeされ2IA!H以前より、アナウンスしていた、Kuromojiという日本語形態素解析が含まれるLucene/Solr 3.6.0がリリースされました。 以下、各2CA!H個人用のPCを８年ぶりに新調しました。 前回購入した家のデスクトップPCがもう８年ものになりつつあるということで、 さすがに今年はPCを買おうと2dA!H先日、「ElasticSearch Serverを翻訳しました」という記事を書きました。 この中で電子版も出ますよと書いていましたが、電子版も発2LA!G先日、2.0.0リリースの記事にも記載しましたが、Java7でテストケースが失敗する問題がありました。 @haruyamaさんと@hideak2IA!T先日、Bashoさんにおじゃましたのもあり、Riak Meetup Tokyo #2に参加しました。 Yokozunaの話も聞けるということで。 懇親会も参加しました。2KA!G先日、Elasticsearchでのカスタム辞書の利用方法についてブログを書きました。 辞書の設定方法について記載しましたが、今回は辞書の更新2GA!H先日、Solr入門のサンプルschema.xmlの3.6.0対応版の作成をしていて、気になったことがあったので、 メモとして残しておきます。 S2UA!\先日、Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)というブログを書きました。 このプラグインを作ってたタイミン2MA!R先日、宣言したとおり、lucene-gosenのパッケージ名＋クラス名の変更を行ったlucene-gosen 2.0.0をリリースしました。 Lucene/Solr2A!G先日、辞書のjarファイルからの分離についてパッチと記事を書きました。 IssueにあげていたパッチをRobertさんが見ていたらしく、次のよ2MA!I先日2014年9月9日(火)に『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』 出版記念！執筆者が語る大講演会！で、 「elastics2^A!F先日のSolr勉強会でLucene/Solr4.x系のlucene-gosenについて質問を受けていたのを忘れないように（年越しちゃいました2HA!H先日の続きです。「Apache Solr入門」の2章から4章の説明について、Solr3.6.0で動作させる時の変更点を以下に書いていきます。 な2yA!H先日は「システムの特徴と検索機能について」という感じでふんわり書きました。 まぁ、頭の中でぼんやり考えてることを文章にしてみた感じです。 他にも2sA!G先日は「検索システムを構成するパーツ」ということで検索システムを構成しているパーツについて書いてみました。 大体、検索がうまくヒットしないとい2hA!H先週末から勤労感謝の日まで風邪で寝こんでました。。。 みなさん、朝晩、冷え込みが激しいので風邪には気をつけてください。 季節の言葉も入れたので本2VA!G最近、Markdownで文章を書くのに慣れてきました。 ということで、ブログをMarkdownで書けないかなぁと思い、TLの人たちのブログを見2[A!G最近、趣味（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書き始めました。 きちんとPythonのプログラムをプロジェクト2kA!O最近使っていたPCが手元からなくなったので、16インチ Macbook Proをセットアップしているところです。 で、時間もあるのでこれまでほったらかしてきた2kA!I最近忘れやすいので、記録しておこうかと。 読んだスライドの簡単な内容と感想です。 ちなみに、スライドの一覧はこちらです。 ※スライドへのリンクはす2lA!G初目黒（たぶん）で、初Amazonな感じで、流行りの「ビッグデータ」のセミナーに参加してきました。 とりあえず、いつもの自分用のメモを残してお2@A!G前々回紹介した、日本語Wikipediaのデータをインデックス登録する記事の続きです。 今回は、Kuromojiのアナライザを利用してインデッ2LA!G前回、naist-chasenではアルファベットが別々の単語としてanalyzeされてしまうという話をしました。 ただ、これだと、英単語が含ま2EA!G前回の「Logstashを利用したApacheアクセスログのインポート」の続きです。 前回の記事では、Logstashの設定ファイルについて説2nA!L前回のブログのまとめに書いたように、セパレートタイプのキーボードであるCorne Light v2を作成したのでそのビルドログです。DIYキーボードとし2ZA!G前回の記事で、pre-commitとPyCharmとWindowsの組み合わせで困っていることを書きました。 これについて、知り合いとチャット2YA!J前回の記事で、VS Code＋Dev Containerを導入しました。 残課題として「マルチコンテナ化」があるという話もしました。今回はDev C2{A"B前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章2@A"B前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章2AA"B前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章2EA"B前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章2MA!w前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 第8章 7章はパ2PA!j前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 第6章 Enumです。matc2RA!]前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 第5章 構造体です。勝手知ったるなんとやら?2TA!P前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた 第4章 第4章です。たぶん、これがいちばん大事な概念だと思2LA!G前回は3番煎じぐらいでしたが、今回は初記事かな？（だといいな） Kibanaには、前回の記事で書いたものとは別に開発中のKibana3というの2IA!G前回はWorkplace Searchの概要について書きましたが、今回はインストールと構成要素について説明します。なお、2020/5/7時点で2PA!G前回は日本語用オートコンプリートのためのAnalyzerとして、どうやって使うのかを簡単に紹介しました。 今回はもう少し、いろんなパターンを試2vA!I勉強会で宣伝もしましたが、改めて。 Solr入門の改訂版を執筆しました。 考えてみれば、もう3年も前なんですね、Solr入門は。 Solr勉強会な2WA!V動機 Azure Cognitive Searchを検索エンジンに使っているお客さんを手伝っています。 そこで、検索の基本的な話をさせていただきました(もともとJJUGナイ2QA!N原文：Elasticsearch 1.3.1 Releasedを日本語に翻訳したものです。 バグフィックス版のElasticsearch 1.3.1をリリー2pA!H友人にお値打価格で購入したMac miniはMountain Lionにアップデートしてたのですが、手元のAirはまだアップデートしていませんで2WA!X可視化ツール現状確認会に参加して、カジュアルウォーターじゃなくて可視化ツールの現状を確認してきました。 ということで、いつものメモです。 Mackerel と Graphite2wA!G台風15号すごかったですね。幸いにも（？）夏休みだったので、通勤などでひどい目に合わずにすみました。 風雨はすごくてちょっと怖かったですが。。2OA!G子供の寝かしつけしてたら、寝かしつけされてしまって、２時に目が覚めてしまいました。 TSUTAYAでCD借りてきてウォークマンに入れようと思っ2|A!H実に3年ぶりくらいにゆっくりできる日々が訪れたので、積読状態の本を消化しようと「7つの言語 7つの世界」を読み始めました。 せっかくブログも始め2`A!G実践Rust入門という本を買っていた(去年の7月だ。。。)のですが、積んであったので、時間を作って読み始めようかと。 実践Rust入門[言語仕2CA!H宿題その2？かな。Solr勉強会でCloudera Searchのスキーマ周りってどうなってるの？という質問が出てて、 なんか調べることになって2uA!I少し遅くなってしまいましたが、12/05に電子書籍も発売されました。 技術評論社の電子書籍サイトから購入可能です。 書籍のページへのリンク PDF2_A!H年末、何種類かのボードゲームを家族で楽しみました。 家族の感想を交えて簡単に紹介しようかと思います。 家族や知人でボードゲームを購入するときの参2fA!H年末から年始にかけて、「コード・シンプリシティ」を読みました。 先日の記事にも書きましたが、Kindle paperwhiteを思いかけず入手で2XA"D年末までに知り合いと次の論文を読んだので軽くまとめておきます。 Extreme Multi-label Learning for Semantic Matching in Product Search なんで読んだの？ 前回読んだ理由と一緒ですが、Semantic2FA!H忘れてしまうので、備忘録を残しておきます。 一応、ソースには少しずつコメントをいれてはいるのですが。 私は残念ながら、自然言語処理は初心者に毛が2UA!G憧れ？のfluentを使ってみました。 こちらの記事で紹介したZoomdataを最近触っているのですが、お試しにfluentdでデータ流し込む2OA!H懲りずにまた、執筆してみました。みなさん「買って」から感想をいただけるとうれしいです！ 本書について 共著者の方々のブログが詳しいので、そちらを2bA!P技術ブログから離れていってますが。。。 Xperia Zを購入しました。 前に使っていたのはXperia arcになります。 もうすぐ２年だったのですが、容量不2jA!H振り返りブログにも書きましたが、デスクトップPCを自作(DIY)しました。 組み立てたに使ったパーツのアフィリンクを貼っておきます。 10月くら2lA!O改訂新版Solr入門出版記念ということで、第13回Solr勉強会 #SolrJP 新Solr本出版記念を開催しました。 出版記念なので、技術評論社様より、プレ2cA!H新型コロナウィルスの影響もあり、オフラインで集まって勉強会も開催できなくなっています。 検索技術勉強会も、もう1年以上開催できていないです。 ス2\A!m日時：2012/01/19 18:30-20:30 場所：ベルサール三田Room2シアター Inside MapR デモ＋内部のお話。 ・自己紹介 Susheel Kaushik 元YahooのHadoop系の人。製品2CA!H早いもので、師走です。今年もあと少しとなりました。ということで、Advent Calendarの季節が始まりました。 この記事はElastics2rA!H昨夜、Elasticsearchの0.90.8がリリースされました。 リリースされた内容などについては、本家のブログ「0.90.8 releas2WA!G昨年から、ブログをどうしようかって話をしていて、そのままになっていたのですが、Octopress＋Github Pagesというのがあるらしい2qA!I昨年は、大晦日に書いてました。 ちょっと進歩したかも。 振り返り(2012年に書いた抱負から) ということで、まずは昨年書いた抱負からの振り返りで2ZA!H昨年末に今年の抱負について書いたのですが、 他にも興味あるものが増えたので備忘録＆公約？を兼ねてブログに書いておきます。 （興味あるものがあれば2pA!G昨日、文章から特定の単語（リストあり）を探したいという話を聞き、lucene-gosenでもできるねぇという話になりました。 まぁ、考えてみれ2PA!S昨日に引き続き、AWS Summit Tokyo 2013に行ってきました。 @ryu_kobayashiさんからパシリを仰せつかるなどあり、忙しかったのですが楽しか2mA!F昨晩、Elasticsearchから初のプロダクトとなるMarvelがリリースされました。ということで、さっそく触ってみて、簡単な紹介と感想2A!G昨晩に引き続き、情けない内容のブログになってしまいますが。。。 昨晩、書いた記事の調査をしていた時に気づいた、問題になるケースがあったので調査2gA!I書こうと思いながら、気づいたら大晦日。 よくないですね、思いついた時に書かないと。 昨年も書いたので、昨年書いた抱負から振り返りをと。 Mongo2lA!G本日、Elasticでの最終出社日でした。実際の退職日はまだ先ですが、有休消化という感じです。 思い返せばもう5年と5ヶ月も前ですが、Elas2_A!V本記事は情報検索・検索技術 Advent Calendar 2022の9日目の記事です。 だいぶ間が空いてしまいましたが、日本語のオートコンプリートに関する記事の続きです。2vA!H来る、4月4日の土曜日の午後に名古屋でElasticsearch勉強会を開催予定です。 「初」の東京以外の勉強会です。 Twitterでこのよう2bA!N東京以外での勉強会の第2弾として、関西で勉強会を開催してきました。 Elasticsearch勉強会 in 大阪 Elasticsearch勉強会 in 京2SA!H森ビルに行ったことなかったので、参加してみました。 あと、最近まともにコーディングしてないので、そのへんを矯正するためにもと思って。 （まぁ、遊2QA!J概要： Lucene/SolrのコミッターであるRobert Muirさんが始めたプロジェクト 歴史： MeCabのJava移植版としてスタートした2xA!H毎月開催の2回目になります。 今回は日経さんの会場をお借りしての開催となりました。 前回から、スピーカーの募集をhttp://bit.ly/Sp2GA!I気づいたら1ヶ月サボってました、ごめんなさい。。。 Rustで言語処理100本ノックの第2章をはじめました。 前回はこちら。 確認用のUnixコマ2[A!H現在、RC3のVoteをやっている最中（2013/04/24 16:00時点）で、まだリリースされていない、4.3.0についてです。 開発者ML2}A!G現在の出先でMBAを使えないので、なかなか進んでいないMBAのセットアップです。。。 とりあえず、Eclipse、homebrewをインストー2iA!G第10回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさ2_A!G第11回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ2TA!G第13回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ2NA!G第15回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ2MA!G第16回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ2@A!H第1回では、Analyze UIというプラグインの紹介をしました、ごく簡単にですが。 第2回では、Kibanaのプラグインの作成方法を順を追って2zA!F第2回から少し間が空いてしまいましたが、templateで作成したプラグインのディレクトリ構成とどういう流れでデータがやり取りされるかについ2xA!H第2回を開催しました！ すごい、140人くらいくらいの参加登録者（参加者は１００人ちょっと！）がいて、びっくりです。 ステキな会場を提供していた2\A!J第2回目も参加しました。 とりあえずメモ。 自分には欠けてる視点の話しなので面白かった。 ちょっと寒かったなぁ。 エンジニアのためのスキルアップ勉強2hA!H第3回Elasticsearch勉強会で、軽く触れていましたが、ElasticSearch Server日本語版が発売されます。 ツイートなども2_A!H第4回Elsticsearch勉強会を開催しました。 今回から、遅刻厳禁にしてみました。 それほど困った人もいないと思うので、次回からも遅刻厳禁2SA!H第5回Elasticsearch勉強会を開催しました。 遅くなってしまいましたが、まとめてみました。 今回は、Elasticsearchに入って2LA!G第6回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん2GA!G第7回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん2wA!G第8回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん2mA!G第9回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん2kA!H第9回Solr勉強会に参加しました。 皆勤賞です！というか、主催者になってしまいました。 まだ不定期の開催になると思いますが、話をされたい方など2eA!G自宅の環境がいろいろと変わったのですが、書いていなかったので更新版です。 前回のブログ(2020/09)、前々回のブログ(2020/03)はそ2tA!G自宅環境に少しアップデートがあったので更新版です。 お客さんのおかげで相変わらず自宅で作業させてもらってるのもあり、昨今のコロナウイルスの影響2VA!N自転車本を読み始めましたが、その前にRust the bookを読んだほうが良いかも?と知り合いと話をしていてなったので、先にRust the bookを読2qA!G興味をもちつつ、触っていない軟弱者ですが、興味があるので今回も話を聞きに行って来ました。 まずは、作者古橋さんによるFluentdの魅力や次期2UA!I親子で楽しめる 絵本で英語をはじめる本 Twitterでこの本について書かれたブログ記事が流れてきて、購入しました。 最近、英語を身につけておいた2_A!H記念すべき！？第10回のSolr勉強会です。 発表者が無事あつまり（本当にありがとうございました！）、今回も盛況な感じでほぼ満員でした。 ツイー2xA!Q負荷を計測するために、数回、Azure Cognitive Searchのクラスターを起動したり、停止したりしてました。 これは、Terraformでやると楽でき2UA!H趣味？（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書いています。 ベクトル検索などの確認なども含めて、Jupyter N2OA!J辞書の特性について 現在lucene-gosenでは以下の2つの辞書が利用可能です。 簡単に違いについて説明します。 IPAdicの辞書について バ2UA!J退職しました。 色々と書きたいんですが、時差ボケで頭痛いので、このくらいです。 余裕出たら書くかも。 ほしい物リストはこちら 新天地についてはまた明2tA!H遅くなりましたが、続きです。 さらに英語力のなさを痛感して凹んでいるところですが、何かの役に立てばと恥を晒すところです。。。 一応、訳してみたの2ZA!G酔っ払ってなんとなく書きたくなったスピリチュアルなブログなので、流していただければと。 最近、勉強会やTwitterで知り合いになって話をする2cA!\金曜日に引き続き、イベントに参加して来ました。（仕事。。。これも仕事だよ。） 「Hadoop Conference Japan 2013 Winter」です。 普段、Hadoopを触る2AA!H録画してたEテレのスーパープレゼンテーションを見ててふと書きたくなったので、書いてます。 あとから読んだら恥ずかしくなりそうだけど。。。 「&l2{A!H開発中ですと書きました、elasticsearch-extended-analyzeですが、改良しました。 改良と変更は以下のとおりです。 ソー2QA!F風のうわさで、日本語用のオートコンプリートのためのTokenFilterとAnalyzerがLuceneに取り込まれたと聞きました（LUCE>xdtypefstringvddate3vddocs<ya1Qya2Pya3Oya4Nya5Mya6Lya7Kya8Jya9Iyb10Hyb11Gyb12Fyb13Eyb14Dyb15Cyb16Byb17Ayb18@yb19yb20~yb21}yb22|yb23{yb24zyb25yyb26xyb27wyb28vyb29uyb30tyb31syb32ryb33qyb34pyb35oyb36nyb37myb38lyb39kyb40jyb41iyb42hyb43gyb44fyb45eyb46dyb47cyb48byb49ayb50`yb51_yb52^yb53]yb54\yb55[yb56Zyb57Yyb58Xyb59Wyb60Vyb61Uyb62Tyb63Syb64Ryb65Qyb66Pyb67Oyb68Nyb69Myb70Lyb71Kyb72Jyb73Iyb74Hyb75Gyb76Fyb77Eyb78Dyb79Cyb80Byb81Ayb82@yb83yb84~yb85}yb86|yb87{yb88zyb89yyb90xyb91wyb92vyb93uyb94tyb95syb96ryb97qyb98pyb99oyc100nyc101myc102lyc103kyc104jyc105iyc106hyc107gyc108fyc109eyc110dyc111cyc112byc113ayc114`yc115_yc116^yc117]yc118\yc119[yc120Zyc121Yyc122Xyc123Wyc124Vyc125Uyc126Tyc127Syc128Ryc129Qyc130Pyc131Oyc132Nyc133Myc134Lyc135Kyc136Jyc137Iyc138Hyc139Gyc140Fyc141Eyc142Dyc143Cyc144Byc145Ayc146@yc147yc148~yc149}yc150|yc151{yc152zyc153yyc154xyc155wyc156vyc157uyc158tyc159syc160ryc161qyc162pyc163oyc164nyc165myc166lyc167kyc168jyc169iyc170hyc171gyc172fyc173eyc174dyc175cyc176byc177ayc178`yc179_yc180^yc181]yc182\yc183[yc184Zyc185Yyc186Xyc187Wyc188Vyc189Uyc190Tyc191Syc192Ryc193Qyc194Pyc195Oyc196Nyc197Myc198Lyc199Kyc200Jyc201Iyc202Hyc203Gyc204Fyc205Eyc206Dyc207Cyc208Byc209Ayc210@yc211yc212~yc213}yc214|yc215{yc216zyc217yyc218xyc219wyc220vyc221uyc222tyc223syc224ryc225qyc226pyc227oyc228nyc229myc230lyc231kyc232jyc233iyc234hyc235gyc236fyc237eyc238dyc239cyc240byc241ayc242`yc243_yc244^yc245]yc246\yc247[yc248Zyc249Yyc250Xyc251Wyc252Vyc253Uyc254Tyc255Syc256Ryc257Qyc258Pyc259Oyc260Nyc261Myc262Lyc263Kyc264Jyc265Iyc266Hyc267Gyc268Fyc269Eyc270Dyc271Cyc272Byc273Ayc274@yc275yc276~yc277}yc278|yc279{yc280zyc281yyc282xyc283wyc284vyc285uyc286tyc287syc288ryc289qyc290pyc291oyc292nyc293myc294lyc295kyc296jyc297iyc298hyc299gyc300fyc301eyc302dyc303cyc304byc305ayc306`yc307_yc308^yc309]yc310\yc311[yc312Zyc313Yyc314Xyc315Wyc316Vyc317Uyc318Tyc319Syc320Ryc321Qyc322Pyc323Oyc324Nyc325Myc326Lyc327Kyc328Jyc329Iyc330Hyc331Gyc332Fyc333Eyc334Dyc335Cyc336Byc337Ayc338@yc339yc340~yc341}yc342|yc343{yc344zyc345yyc346xyc347wyc348vyc349uyc350tyc351syc352ryc353qyc354pyc355oyc356nyc357myc358lyc359kyc360jyc361iyc362hyc363gyc364fyc365eyc366dyc367cyc368byc369ayc370`yc371_yc372^yc373]yc374\yc375[yc376Zyc377Yyc378Xyc379Wyc380Vyc381Uyc382Tyc383Syc384Ryc385Qyc386Pyc387_yc388^yc389]yc390\yc391[yc392Zyc393Yyc394Xyc395Wyc396Vyc397Uyc398Tyc399Syc400Ryc401Qyc402P>wkorderedDocs<w2ypR
5p2Q
6`2P
7!
x2O
94@2N
;
T2M
=<P2L
="p2K
?</H2J0`2I3x2H%S2G5X2F97x2E	$-|2D8l2C!x2Bx2A5t2@0h28H2~%|2}%H2|`2{$"d2z:d2y|2xD2w7>X2v 9t2u 0"|2t"-
-P2s#t2r#),|2q#.;h2p%l2o'#K2n)-?P2m+$h2l,$d2k.
-&x2j."p2i0)1p2h3=`2g4;/t2f5\2e5%\2d87C2c;6l2b<=[2a< 0\2`>4T2_
>I2^+|2]8@2\6H2[C2Za2Y"d2X)2t2W'\2V&8x2U(p2TH2Sx2R6E2Q	`2P@2O"t2N
-&t2M7H2L`2K*
d2J!.m2I"\2H"$h2G#K2F$=T2E')/K2D*,t2C,4=R2B1 l2A1$P2@3	L23#l2~40b2}56P2|6,\2{6(!\2z649h2y73T2x:	\2w=.P2v=u2u?/9B2th2s:6T2r+X2q
%p2pH2o
>l2n,|2m="L2l'(d2k,3'`2j-$P2i12h2h4/h2g8l2f;,@2e=L2d>)+l2c?h2b'
l2a/@2`"D2_@2^#{2]`2\'f2[8p2Z	h2Y <3K2X!;5T2W* .|2V+F2U+
;T2T+-L2S+-p2R+0X2Q,H2P,	`2O-X2N-/t2M0
D2L0
t2K2>&@2J55P2I7?l2H7<T2G<*d2F='#d2E>p2D>&x2C>7H2B-h2A8h2@	&D2
-)x2~;D2}!	T2|$
-H2{94`2z$.\2y."d2x P2w!?d2v%
D2u)@2t+<D2s,,|2r,?P2q0p2p7(<p2o8:P2n92h2m:!H2l:7X2k<9|2j=;H2i0 p2h
d2g)6t2f	4t2e
-t2d%T2c
X2b 1@2a'3@2`|2_p2^=T2]
-|2\ 
l2[:|2Z$/P2Y>x2X2
X2W#07D2V'*<D2U,T2T,!4h2S2&'p2R55D2Q51
X2P63
-@2O78	h2N+T2M;*l2L1h2Kh2J!@2I!G2H%i2G?8[2F/ o2E;z2D(?T2C=l2B"*V2A#
-h2@#:L2$?b2~$&v2}$(,X2|&;L2{(>f2z2P2y7I2x7u2w8o2v9>}2u9,^2t9,p2s<u2r<7D2q??W2p6 h2o3W2n
-2,w2m	4b2l2p2k,O2j
/Z2il2h;6F2g ;}2f&:M2e&6>P2d&7|2c'%C2b)0.i2a+3%A2`."i2_.0*a2^5d2]7&h2\7<<J2[></m2Z1C2Y"]2X"s2W#K2V1){2U3
j2T%b2S{2RB2Q!
~2P#2
P2O9+7T2N:"D2M 
[2L2R2K$P2J>V2I(9V2H;F2G	]2F00>f2E
.Y2D
3p2C;H2B
!s2A~2@q2!
o2~!U2}")(P2|,?e2{-$D2z6#i2yz2x1/n2w16o2v!v2uq2t
-e2s=H2r0/n2q (d2p'-]2o,-B2n8(p2m9'!p2l:)r2k=-M2j>
-w2i>J2h
2g,G2f.Y2e	;f2d
-Z2c
-*Y2b;,d2a

C2`
d2_
%f2^k2]
-a2\4"`2[8<n2Z".m2Y?C2X?M2W,?W2V
B2U+5}2T[2S?g2R!N2Q"*p2P#2O#)y2N#.O2M&
-j2L'99P2K)##o2J*<?@2I,7
R2H-4I2G-:`2F.!q2E/
-~2D/.m2C14
-q2B3
W2A37<o2@6I274/P2~<1u2}=V2|)l2{
.*J2z)9V2y93R2x9;W2w%
A2v c2u#>\2t.&u2sf2r(b2q 11f2p!:8R2o#+N2n(,g2m2
-X2l67{2k;t2j;~2i>;,W2h ,&J2g :|2f p2e 
7f2d 3%u2c ~2b -0g2a "-T2` 7W2_ 9?'E2^ ;/g2]!"5&\2\!+7p2[!0)
g2Z!3	x2Y!30o2X!7*n2W"!	 Y2V")19V2U"*>_2T"567{2S"5:#j2R";
/b2Q"< r2P"<13Z2_#$ 6]2^#&V2]#,
<\2\$$u2[$*6d2Z$+?#k2Y$..z2X$/!(`2W$/$H2V$0i2U$9'|2T%=H2S%7p2R%1!p2Q%$4A>xdtypefnumbervgenabledtvhisSortedtxhlanguagegenglish
\ No newline at end of file
+Pxipermalink!mhttps://blog.johtani.info/blog/2011/10/04/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE2/xkpublishdate Y2011-10-04T18:32:00+09:00xgsummary!H遅くなりましたが、続きです。 さらに英語力のなさを痛感して凹んでいるところですが、何かの役に立てばと恥を晒すところです。。。 一応、訳してみたのwdtags1xpdsolrxetitle gNew SolrCloud Designの翻訳（その2）(Jugemより移植)vc374:yddate 0"|xcdirjpost/2011/xbid `927612b57ba01ca878b2d7edce52a563xdlangbjayglastmod 0"|xipermalink!uhttps://blog.johtani.info/blog/2011/09/28/new-solrcloud-design%E3%81%AE%E7%BF%BB%E8%A8%B3%E3%81%9D%E3%81%AE%EF%BC%91/xkpublishdate Y2011-09-28T20:45:00+09:00xgsummary!Gちょっと興味があるので、訳してみました。（Wikiのページはこちら） 更新されているようなので、もとの文章も残しておきます。（ページ下部の続きwdtags1xpdsolrxetitle gNew SolrCloud Designの翻訳（その１）(Jugemより移植)vc375:yddate 9txcdirjpost/2011/xbid `97402287d8c6c03f0b63848e17e9d944xdlangbjayglastmod 9txipermalink"]https://blog.johtani.info/blog/2011/09/27/hadoop-conference-japan-2011-fall%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-09-27T17:51:00+09:00xgsummary!`Hadoop Conference Japan 2011 Fallに行ってきました。 まずは、ユーザ会の方々、運営の方々、発表された方々お疲れ様でした。こんな機会を用意していただき、ありがとうwdtags1xpfhadoopxetitle vHadoop Conference Japan 2011 Fallに参加してきました。(Jugemより移植)vc376:yddate7>Xxcdirjpost/2011/xbid `62f31128a21b0e240bdb7b3d5b121c04xdlangbjayglastmod7>Xxipermalink"Mhttps://blog.johtani.info/blog/2011/09/23/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-io-0%E6%97%A5%E7%9B%AE/xkpublishdate Y2011-09-23T03:34:00+09:00xgsummary!G台風15号すごかったですね。幸いにも（？）夏休みだったので、通勤などでひどい目に合わずにすみました。 風雨はすごくてちょっと怖かったですが。。wdtags1xpb読書xetitle _「7つの言語　7つの世界」 Io 0日目(Jugemより移植)vc377:yddateDxcdirjpost/2011/xbid `54da1b916f49ef40c822fab61d37cf66xdlangbjayglastmodDxipermalink!phttps://blog.johtani.info/blog/2011/09/15/lucene-solr-3-4%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/xkpublishdate Y2011-09-15T09:31:00+09:00xgsummary!USolr/Lucene 3.4がリリースされました。（速報） 以下、各サイトへのリンクです。 Solrリリースのお知らせ Luceneリリースのお知らせ ちなみに、先日のwdtags1xpdsolrxetitle bLucene/Solr 3.4リリース（速報）(Jugemより移植)vc378:yddate|xcdirjpost/2011/xbid `41b811063b9425de1934e77d89118022xdlangbjayglastmod|xipermalink"jhttps://blog.johtani.info/blog/2011/09/14/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-3%E6%97%A5%E7%9B%AE%E6%9C%80%E7%B5%82%E6%97%A5/xkpublishdate Y2011-09-14T18:21:00+09:00xgsummary!Hということで、Rubyの最終日の感想。 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大wdtags1xpb読書xetitle f「7つの言語　7つの世界」 Ruby 3日目（最終日）(Jugemより移植)vc379:yddate:dxcdirjpost/2011/xbid `37b622eaad1f79e759a722aacebf48ecxdlangbjayglastmod:dxipermalink"\https://blog.johtani.info/blog/2011/09/12/%E7%AC%AC6%E5%9B%9Esolr%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-09-12T16:03:00+09:00xgsummary!I「第6回Solr勉強会」に参加しました。 なんだかんだと第6回で、今のところ皆勤賞です。 ということで、主に自分用ですが、メモなどとったので。 概wdtags1xpc勉強会xetitle ]第6回Solr勉強会に参加しました。(Jugemより移植)vc380:yddate$"dxcdirjpost/2011/xbid `73262345214f9b7794f2cc4a612b15e8xdlangbjayglastmod$"dxipermalink"Ohttps://blog.johtani.info/blog/2011/09/10/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-2%E6%97%A5%E7%9B%AE/xkpublishdate Y2011-09-10T02:11:00+09:00xgsummary!Gということで、Ruby2日目の感想（2日目だけで2日間かかったのは内緒。。。） 今回もセルフスタディの私の回答が最後の方に記載されてます。見たwdtags1xpb読書xetitle a「7つの言語　7つの世界」 Ruby 2日目(Jugemより移植)vc381:yddate`xcdirjpost/2011/xbid `9baedcd033169611a42c3cfd58b3ae03xdlangbjayglastmod`xipermalink"Ohttps://blog.johtani.info/blog/2011/09/09/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-1%E6%97%A5%E7%9B%AE/xkpublishdate Y2011-09-09T14:12:00+09:00xgsummary!H実に3年ぶりくらいにゆっくりできる日々が訪れたので、積読状態の本を消化しようと「7つの言語 7つの世界」を読み始めました。 せっかくブログも始めwdtags1xpb読書xetitle a「7つの言語　7つの世界」 Ruby 1日目(Jugemより移植)vc382:yddate%Hxcdirjpost/2011/xbid `f23ca2aa066b1ee0fa4df1f2f865be4cxdlangbjayglastmod%Hxipermalink"Zhttps://blog.johtani.info/blog/2011/09/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%93/xkpublishdate Y2011-09-07T02:18:00+09:00xgsummary!G現在の出先でMBAを使えないので、なかなか進んでいないMBAのセットアップです。。。 とりあえず、Eclipse、homebrewをインストーwdtags1xpc備忘録xetitle ZMBAセットアップ備忘録その３(Jugemより移植)vc383:yddate%|xcdirjpost/2011/xbid `3c2523e65ff953fd73579aaaf5d7ce36xdlangbjayglastmod%|xipermalink#Mhttps://blog.johtani.info/blog/2011/09/07/%E8%BE%9E%E6%9B%B8%E5%88%86%E9%9B%A2%E3%81%AE%E3%83%86%E3%82%B9%E3%83%88%E3%82%B1%E3%83%BC%E3%82%B9%E8%BF%BD%E5%8A%A0%E3%81%A8%E6%AE%8B%E3%82%BF%E3%82%B9%E3%82%AF/xkpublishdate Y2011-09-07T01:56:28+09:00xgsummary!Hすぐにテストケース追加しますといいつつ、はや一週間。 ようやく仕事が落ち着いたので、テストケースを追記しました。まだパッチの段階です。 一応、異wdtags1xpllucene-gosenxetitle ]辞書分離のテストケース追加と残タスク(Jugemより移植)vc384:yddate8Hxcdirjpost/2011/xbid `88a8e608108be939da9aab5a9a8af7d1xdlangbjayglastmod8Hxipermalink"ihttps://blog.johtani.info/blog/2011/08/30/%E8%A4%87%E6%95%B0%E8%BE%9E%E6%9B%B8%E3%81%AE%E8%AA%AD%E3%81%BF%E8%BE%BC%E3%81%BF%E6%A9%9F%E8%83%BD%E8%BF%BD%E5%8A%A0%E4%BB%AE/xkpublishdate Y2011-08-30T10:34:00+09:00xgsummary!G先日、辞書のjarファイルからの分離についてパッチと記事を書きました。 IssueにあげていたパッチをRobertさんが見ていたらしく、次のよwdtags1xpllucene-gosenxetitle [複数辞書の読み込み機能追加（仮）(Jugemより移植)vc385:yddate0hxcdirjpost/2011/xbid `2f1ec795216d5bafa33a810af3421942xdlangbjayglastmod0hxipermalink"Zhttps://blog.johtani.info/blog/2011/08/23/%E8%BE%9E%E6%9B%B8%E3%81%AEjar%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%8B%E3%82%89%E3%81%AE%E5%88%86%E9%9B%A2/xkpublishdate Y2011-08-23T10:26:00+09:00xgsummary!Gひさびさに、lucene-gosenの話題です。 lucene-gosenはjarファイルに辞書も同梱されており、jarファイルをクラスパスにwdtags1xpllucene-gosenxetitle Z辞書のjarファイルからの分離(Jugemより移植)vc386:yddate5txcdirjpost/2011/xbid `ce0aea06d44878b4a373efe090a66a62xdlangbjayglastmod5txipermalink"Zhttps://blog.johtani.info/blog/2011/08/15/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%92/xkpublishdate Y2011-08-15T09:51:00+09:00xgsummary!Hすみません、また、MBA関連の記事になってしまいました。 ということで、備忘録その２です。 前回からいくつかインストールや環境の設定をしたので、wdtags1xpc備忘録xetitle ZMBAセットアップ備忘録その２(Jugemより移植)vc387:yddatexxcdirjpost/2011/xbid `c0e423f9ac41cc5b265c95a3e97e3fcbxdlangbjayglastmodxxipermalink!https://blog.johtani.info/blog/2011/08/10/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2/xkpublishdate Y2011-08-10T00:46:00+09:00xgsummary!^Mac Book Airのセットアップ関連の備忘録 （今回は備忘録なので、文体も変かも） インストールしたもの（順不同）だいたい、このサイトを参考にした。 Evernote Dropboxwdtags1xpc備忘録xetitle WMBAセットアップ備忘録(Jugemより移植)vc388:yddate!xxcdirjpost/2011/xbid `7ed1d2efa3e0f0ed6b77eb4eff3d86b3xdlangbjayglastmod!xxipermalink!xhttps://blog.johtani.info/blog/2011/08/04/apple%E6%95%99%E3%81%AB%E5%85%A5%E4%BF%A1%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-08-04T01:34:00+09:00xgsummary!H個人用のPCを８年ぶりに新調しました。 前回購入した家のデスクトップPCがもう８年ものになりつつあるということで、 さすがに今年はPCを買おうとwdtags1xpc備忘録xetitle XApple教に入信しました(Jugemより移植)vc389:yddate8lxcdirjpost/2011/xbid `3811b40721f7ca651887aac4eb17f9f0xdlangbjayglastmod8lxipermalink$`https://blog.johtani.info/blog/2011/07/27/%E7%AC%AC1%E5%9B%9E-%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E6%83%85%E5%A0%B1%E6%A4%9C%E7%B4%A2%E3%81%A8%E8%A8%80%E8%AA%9E%E5%87%A6%E7%90%86%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-07-27T12:33:00+09:00xgsummary!Iかなり遅くなりましたが、第1回 データ構造と情報検索と言語処理勉強会 #DSIRNLPに参加しました。 帰ってから２日半ほど寝込んでしまい、更新がwdtags1xpc勉強会xetitle i第1回 データ構造と情報検索と言語処理勉強会に参加しました。(Jugemより移植)vc390:yddate	$-|xcdirjpost/2011/xbid `5a765f9668608a39333fa90cf462657exdlangbjayglastmod	$-|xipermalink!ihttps://blog.johtani.info/blog/2011/07/20/kuromoji%E3%82%92%E8%AA%BF%E3%81%B9%E3%81%A6%E3%81%BF%E3%81%9F/xkpublishdate Y2011-07-20T12:29:00+09:00xgsummary!G以前から春山さんのブログ（リンク）や勉強会で耳にはしていたのですがソースは読んでいませんでした。 先日、Luceneにcontributeされwdtags1xpe形態素解析xetitle YKuromojiを調べてみた(Jugemより移植)vc391:yddate97xxcdirjpost/2011/xbid `c70b78fd0b5dffcd38322355e9c2471exdlangbjayglastmod97xxipermalink"nhttps://blog.johtani.info/blog/2011/07/12/naist-jdic-for-mecab%E3%81%AEpreprocessor%E3%81%AE%E5%AE%9F%E8%A3%85%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E5%82%99%E5%BF%98%E9%8C%B2/xkpublishdate Y2011-07-12T10:06:00+09:00xgsummary!H忘れてしまうので、備忘録を残しておきます。 一応、ソースには少しずつコメントをいれてはいるのですが。 私は残念ながら、自然言語処理は初心者に毛がwdtags1xpllucene-gosenxetitle vNAIST-JDic for MeCabのPreprocessorの実装に関する備忘録(Jugemより移植)vc392:yddate5Xxcdirjpost/2011/xbid `229975f1e84b5088e819cd5f2dc43080xdlangbjayglastmod5Xxipermalink!ahttps://blog.johtani.info/blog/2011/07/04/lucene-gosen-1-1-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/xkpublishdate Y2011-07-04T20:00:40+09:00xgsummary!Hlucene-gosen 1.1.1をリリースしました。 先日お知らせしたバグ修正を取り込んだjarを用意いしました。 ダウンロードはこちらからwdtags1xpllucene-gosenxetitle alucene-gosen 1.1.1リリース(Jugemより移植)vc393:yddate%Sxcdirjpost/2011/xbid `10eb1e7dc64d8ca3dad92641dadb5de7xdlangbjayglastmod%Sxipermalink!phttps://blog.johtani.info/blog/2011/07/01/lucene-solr-3-3%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E9%80%9F%E5%A0%B1/xkpublishdate Y2011-07-01T15:29:39+09:00xgsummary!USolr/Lucene 3.3がリリースされました。（速報） 以下、各サイトへのリンクです。 Solrリリースのお知らせ Luceneリリースのお知らせ リリースのタイミwdtags1xpdsolrxetitle bLucene/Solr 3.3リリース（速報）(Jugemより移植)vc394:yddate3xxcdirjpost/2011/xbid `49ba23148db9effdc3979aa0fe5876eaxdlangbjayglastmod3xxipermalink&https://blog.johtani.info/blog/2011/06/29/hadoop%E3%82%92%E4%B8%AD%E5%BF%83%E3%81%A8%E3%81%97%E3%81%9F%E5%88%86%E6%95%A3%E7%92%B0%E5%A2%83%E3%81%A7%E3%81%AE%E9%96%8B%E7%99%BA%E6%96%B9%E6%B3%95%E8%AB%96%E3%83%A2%E3%83%87%E3%83%AA%E3%83%B3%E3%82%B0%E8%A8%AD%E8%A8%88%E6%89%8B%E6%B3%95%E7%AD%89%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E5%BA%A7%E8%AB%87%E4%BC%9A-%E7%AC%AC5%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/xkpublishdate Y2011-06-29T23:10:00+09:00xgsummary!F「Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）」に参加しました。300名入るイベントルーwdtags1xpfhadoopxetitle!CHadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）に参加しました。(Jugemより移植)vc395:yddate0`xcdirjpost/2011/xbid `f6dff70097776e24c2a7c9c0f2514f79xdlangbjayglastmod0`xipermalink!xhttps://blog.johtani.info/blog/2011/06/28/compositeposcompositetokenfilter%E3%81%AE%E3%83%90%E3%82%B0%E4%BF%AE%E6%AD%A3/xkpublishdate Y2011-06-28T12:36:00+09:00xgsummary!G以前、こちらで話題に上がっていた「未知語」に関するcompositePOSのエラーの件を調査しました。（Twitterでも流れてました。） 次wdtags1xpllucene-gosenxetitle rcompositePOS（CompositeTokenFilter）のバグ修正(Jugemより移植)vc396:yddate
?</Hxcdirjpost/2011/xbid `991285e3967c3295b4ff2dcd835f7c61xdlangbjayglastmod
?</Hxipermalink!uhttps://blog.johtani.info/blog/2011/06/21/naist-jdic-for-mecab%E5%AF%BE%E5%BF%9C%E7%89%88%E4%BB%AE%E5%AE%9F%E8%A3%85/xkpublishdate Y2011-06-21T07:38:00+09:00xgsummary!Jlucene-gosenのtrunkbranches/impl-mecab-dicにNAIST-JDic for MeCabの辞書を利用出来るPrewdtags1xpllucene-gosenxetitle gNAIST-JDic for MeCab対応版（仮実装）(Jugemより移植)vc397:yddate
="pxcdirjpost/2011/xbid `50f43b1726cf61066ef8656477b226bexdlangbjayglastmod
="pxipermalink#Jhttps://blog.johtani.info/blog/2011/06/14/compositepos%E3%81%AE%E5%88%A9%E7%94%A8%E4%BE%8Bnaist-chasen%E3%81%A7%E3%81%AE%E8%8B%B1%E5%8D%98%E8%AA%9E%E3%81%AE%E5%87%BA%E5%8A%9B%E6%96%B9%E6%B3%95%E4%BE%8B/xkpublishdate Y2011-06-14T00:00:00+09:00xgsummary!G前回、naist-chasenではアルファベットが別々の単語としてanalyzeされてしまうという話をしました。 ただ、これだと、英単語が含まwdtags1xpllucene-gosenxetitle tcompositePOSの利用例（naist-chasenでの英単語の出力方法例）(Jugemより移植)vc398:yddate
=<Pxcdirjpost/2011/xbid `eeef60efe889349870426d10edc694bexdlangbjayglastmod
=<Pxipermalink!bhttps://blog.johtani.info/blog/2011/06/13/lucene-gosen-1-1-0-%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/xkpublishdate Y2011-06-13T12:08:00+09:00xgsummary!Glucene-gosenの1.1.0がリリースされました。 大きな目玉はJapaneseTokenizerが出力する形態素に関するデータを遅延wdtags1xpllucene-gosenxetitle blucene-gosen 1.1.0 リリース(Jugemより移植)vc399:yddate
;
Txcdirjpost/2011/xbid `4b046ac6a4796fb1338f0481dbd4003dxdlangbjayglastmod
;
Txipermalink!]https://blog.johtani.info/blog/2011/06/06/lucene-gosen%E3%81%AEtokenfilter%E3%81%9F%E3%81%A1/xkpublishdate Y2011-06-06T16:23:00+09:00xgsummary!Flucene-gosenをSolr/Luceneで利用する場合、TokenFilterを利用してTokenizerが出力したToken対してwdtags1xpllucene-gosenxetitle elucene-gosenのTokenFilterたち(Jugemより移植)vc400:yddate
94@xcdirjpost/2011/xbid `b2621497b3313c97855ed951f0d9b291xdlangbjayglastmod
94@xipermalink"`https://blog.johtani.info/blog/2011/06/02/%E8%BE%9E%E6%9B%B8%E3%81%A8%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E8%BE%9E%E6%9B%B8%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/xkpublishdate Y2011-06-02T17:16:00+09:00xgsummary!J辞書の特性について 現在lucene-gosenでは以下の2つの辞書が利用可能です。 簡単に違いについて説明します。 IPAdicの辞書について バwdtags1xpllucene-gosenxetitle X辞書とカスタム辞書について(Jugemより移植)vc401:yddate
7!
xxcdirjpost/2011/xbid `ff1441a42144a7de9a3eaf9f5e7cfea9xdlangbjayglastmod
7!
xxipermalink"Whttps://blog.johtani.info/blog/2011/05/26/%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%8B%E3%82%89%E3%81%AE%E3%83%93%E3%83%AB%E3%83%89%E3%81%A8%E6%A7%8B%E6%88%90/xkpublishdate Y2011-05-26T17:34:00+09:00xgsummary!G今回はソースのダウンロードとビルドについてです。 最新版のソースを利用したり、JavaDocを見たい場合はソースをダウンロードしてからビルドすwdtags1xpllucene-gosenxetitle Wソースからのビルドと構成(Jugemより移植)vc402:yddate
6`xcdirjpost/2011/xbid `5988b62a0c0785a303b77c74608e8b55xdlangbjayglastmod
6`xipermalink!Ihttps://blog.johtani.info/blog/2011/05/23/lucene-gosen%E3%81%A8%E3%81%AF/xkpublishdate Y2011-05-23T15:00:00+09:00xgsummary!J概要： Lucene/SolrのコミッターであるRobert Muirさんが始めたプロジェクト 歴史： MeCabのJava移植版としてスタートしたwdtags1xpllucene-gosenxetitle Ylucene-gosenとは(Jugemより移植)vc403:yddate
5pxcdirjpost/2011/xbid `94b85ba716dbb7c20b230e69248b8208xdlangbjayglastmod
5pxipermalink!shttps://blog.johtani.info/blog/2011/05/20/%E3%83%96%E3%83%AD%E3%82%B0%E3%81%AF%E3%81%98%E3%82%81%E3%81%BE%E3%81%99/xkpublishdate Y2011-05-20T11:44:00+09:00xgsummary!H今さらですが、ブログをはじめてみようかと。今さらですが… はじめてみようと思った一番の理由は、自分で調べたことをメモがわりに残すためです。 あとwdtags1xpdmiscxetitle Sブログはじめます(Jugemより移植)>yecountSvgsorting6xhlanguagegenglishw RsortableProperties4xpbidetitlegsummaryddatev [sortablePropertiesWithTypes4xbidfstringxetitlefstringxgsummaryfstringxddatefnumbervesorts4vbid3vddocs<ya1hya2Nya3iya4ya5Gya6Zya7Kya8zya9oyb10Xyb11}yb12`yb13cyb14ayb15^yb16hyb17nyb18[yb19eyb20Ryb21wyb22Cyb23Tyb24Byb25Vyb26Qyb27{yb28xyb29Eyb30Uyb31Ryb32Lyb33fyb34Ayb35~yb36@yb37myb38Oyb39byb40Iyb41Pyb42oyb43Yyb44Cyb45pyb46Ayb47Lyb48kyb49_yb50eyb51byb52Oyb53Byb54Myb55_yb56lyb57Dyb58Xyb59xyb60yyb61iyb62Uyb63Syb64Nyb65kyb66dyb67Wyb68|yb69Pyb70uyb71Yyb72^yb73Lyb74gyb75wyb76[yb77`yb78@yb79ryb80Xyb81{yb82eyb83Yyb84`yb85Jyb86Gyb87jyb88uyb89dyb90Iyb91jyb92Uyb93wyb94dyb95yb96\yb97Iyb98myb99Oyc100pyc101Qyc102Eyc103^yc104Vyc105nyc106Lyc107}yc108oyc109ryc110cyc111{yc112Yyc113Lyc114Ryc115@yc116Nyc117byc118tyc119Tyc120byc121Gyc122Syc123Tyc124Wyc125Kyc126jyc127Vyc128Fyc129@yc130pyc131Ayc132|yc133Lyc134byc135zyc136Jyc137hyc138Pyc139Cyc140Dyc141fyc142myc143kyc144ayc145ryc146jyc147Myc148pyc149Nyc150Iyc151ayc152Ryc153cyc154|yc155uyc156syc157^yc158qyc159Oyc160oyc161Pyc162Kyc163[yc164ryc165Jyc166vyc167lyc168\yc169Dyc170ryc171@yc172Uyc173Xyc174kyc175Eyc176Ayc177myc178Ayc179vyc180{yc181uyc182]yc183Pyc184nyc185wyc186Qyc187Pyc188Pyc189xyc190Dyc191Xyc192hyc193Uyc194nyc195syc196Myc197[yc198xyc199dyc200Kyc201Eyc202Wyc203oyc204Oyc205hyc206yyc207xyc208Zyc209Cyc210Nyc211\yc212gyc213}yc214cyc215]yc216Ryc217Byc218gyc219lyc220^yc221pyc222Gyc223fyc224}yc225tyc226Iyc227]yc228`yc229Hyc230Zyc231Jyc232[yc233tyc234Byc235yc236tyc237lyc238Fyc239iyc240cyc241Xyc242Tyc243ayc244wyc245{yc246Qyc247~yc248\yc249\yc250|yc251yyc252Qyc253Syc254uyc255dyc256Fyc257}yc258Jyc259\yc260Tyc261~yc262Ryc263Myc264qyc265|yc266]yc267Hyc268nyc269Byc270Syc271yyc272gyc273Cyc274yc275vyc276eyc277}yc278kyc279iyc280Wyc281Zyc282Vyc283Hyc284qyc285Xyc286tyc287pyc288Cyc289Eyc290Ayc291Kyc292]yc293Qyc294xyc295lyc296tyc297myc298Qyc299byc300Eyc301jyc302_yc303eyc304Ryc305syc306vyc307Tyc308Hyc309_yc310syc311Zyc312Uyc313zyc314Dyc315wyc316ayc317Fyc318qyc319zyc320yyc321]yc322Ryc323`yc324|yc325fyc326fyc327syc328[yc329Jyc330[yc331\yc332Fyc333ryc334Wyc335Iyc336Vyc337gyc338syc339Wyc340vyc341Vyc342Vyc343gyc344yyc345Myc346yc347Hyc348oyc349iyc350@yc351Hyc352{yc353hyc354Tyc355Gyc356nyc357jyc358cyc359_yc360`yc361Dyc362Yyc363zyc364Syc365~yc366_yc367^yc368Syc369Syc370Yyc371^yc372Zyc373fyc374ayc375iyc376Wyc377Byc378dyc379Yyc380myc381uyc382zyc383]yc384Pyc385Oyc386yc387_yc388Fyc389Zyc390Nyc391qyc392~yc393Uyc394lyc395Gyc396kyc397~yc398vyc399qyc400Myc401Qyc402Kyc403e>wkorderedDocs<w2ypJAxp `002d980d74d19b43ff4e2446665e2fe52eA `018b365b00dd3a6ad17c813d215905492XA `018e32a8010960eb17e368a6fdd5a51b2}A `0302e8a57a5e8604342a925b2dc607372{A `04d818cbaac08b2915db15e0bffdcb5b2AA `05330c3703d0e2c96cfe657ab33f130c2YA `0645bdb1cdf88ec74288d503eb71839c2NA `06731164684f90f33ce4017eca9d8ec12ZA `086b4fd5f77021a0a2aa6b0e900614862GA `09155bf417a93847b538ad607f78cca22tA `09677934e13a5d728f00c6ed7c8870a92EA `0a8183ced0e9e3e895b41286e54e8e4d2SA `0c1821d1069578551d0e3c7d9275f16b2AA `0dcb6d0f17794bbca56b6cdb9e20b9322]A `0de0edbf2a506143c1739b12e94c0ef92gA `0ebe78077c8b48410cf52a0bccdff8662aA `100c0a69bea7f02a0f4540ecaa37d0e32ZA `104b8ee17a8bf1f7043d2366596804932_A `10a7f69bd03d2632722300194f01e93d2zA `10ae016e19fff6ae9cfaeb8534fa47f92rA `10c715f70de25ccb493bbbb532b78ced2IA `10eb1e7dc64d8ca3dad92641dadb5de72UA `10eb415a232ad4be7d05c57eb850036c2SA `116c9be6d760b4befa6d51ce9e96604c2zA `11a61827e80739a6065960eb188d57582pA `11b3a28b536f34d3606427f835bd3ddf2YA `11d4726484be418849e1f4200ade95352HA `12d1e0cf7396dd33a9bbbca8da4cbc682xA `13684d16fdd07d5f0584e29265a270e72JA `146e8ca40c0d37f36eecea822028dd9e2oA `14a6d294550c9760aec57ba29682a7502nA `14cf6e75aec1ead888e7101d3d94d28a2MA `15357b6978e83daa2d97692c861dc1772WA `15700442e957951307bbcec5fff8643d2sA `15932a656f7acfac897d27766eadc9e22pA `15f501351d482ffd73985a50f5c89d1f2BA `163beeae9620c1a6a46a38aa7ebd96632SA `167a7c9d579ce6f2cebf64a6f6329ecb2MA `167e2a6833d49ce198cb3b88f521991e2QA `16b3c9445539e9274282a612dea354c22IA `16f1046144ad9ee7bb96214ba7ae75162WA `16f10764f0ccce42d5be8cfeac36b4462eA `16fa0e4aefe18e1446bf6baefd3ba4002pA `188c1ee5132a6752dfce5a02353540702gA `18b7998a871950ebc36c415a536304772qA `19ecbaa5e12f7a9ebcff703c79534a522iA `1a1a8cc0040b356d06eacd22e05264762lA `1abc586d67f0b6c05fd5e60f254923402TA `1b56132638912a1ca54fcf7cd38b8e232HA `1b9c5ae60ec46be64a1877f0c6920edc2mA `1bbf2ef67f096960e13d8578fa5445362CA `1bc36080b2493aab78c26e4f2152542c2^A `1ca04e5339ed1826c12fe61fd984e9492FA `1e220a934e16fd941bd804ca03865b602SA `1fe14e2e02b6e65e6e6e2ae3d8ddcc9f2yA `1fed22e99b0e11a50eb7b92cb1644e8a2fA `20110c8f8da8304b6d9d3c2845a381282|A `208a8c072ea521c813b86ca7730eb8802A `216db319052b5742fc68862cb2f399052[A `218e2c36d5945ece02fdc55d6cbcbc382DA `21982f43bc435f22efef22b309a48c662UA `21a8e6324e9330d4f8ebade604c62b6e2HA `229975f1e84b5088e819cd5f2dc430802kA `229b7fc784707b1d2c702fbeba080e862kA `23a22d1411afb787810d68210e6fad4f2pA `24357fe145c869ec82fdfc8134a1a6d12MA `26c47355cbe966a94826cbe2fbf2b3552`A `26d0c0d8c465087cf160a3bdc479f2b42iA `26d48d68b28f927bfebad454658f94252]A `26e44dfd16a2963d4c18e99806c26fd72}A `277f7f2177e2a265a62680ea0158f9b92^A `2824bef72110575c78aeb979170212b82[A `286a9a4ee373398d7d2c93862c5f66612bA `299abcee56b05b312ed5700f686f79b82HA `29b4c2b5adcd80ced1612128b3ca95a92HA `2a8412aa50d07330f1298f0243fa79d32IA `2c3270f8797ace2fb37402ea6a09d1262DA `2de582c67fca31500621ecd6d3917a072UA `2ea86ae5093670df1d4502ea82efa1ac2AA `2f1ec795216d5bafa33a810af34219422EA `306cecb32320ead508346ad8fed3394d2eA `322264a17ef7182eb1475bd2eaebc2eb2TA `3384ea6bb47d70f8ca94b4510813f36a2NA `33919e866426ce8e7b2ce06f19bbf8892DA `33e01e2271be22b5ed330045fe6aff502^A `35200cbf0b5b45d7f5f0b343cb18868b2hA `35aa9e09db936aee7ec407c4318165732CA `36dd94159e3e60076c0c6098086e255f2]A `36ff37ced0d3211db95a5ac0daac0c352{A `37b622eaad1f79e759a722aacebf48ec2EA `3811b40721f7ca651887aac4eb17f9f02hA `386dc9d1b647a9f3965f1fbe29c7dfb92CA `3931327ed463d1568868c5ab8e8391482A `3c2523e65ff953fd73579aaaf5d7ce362gA `3c299a4d77be8b4f886ce9fcd23a25612wA `3c5d4d351e0fb9e33e0e8b6d1d43c0f22TA `3f431bf71ee866f626daf42bc915fa3f2PA `3fc7462a83fa55885067fee629287e8a2xA `3fd9052870778e14ab4a5acbc8c24af42VA `40abea0a87a64bd832a1fad69458b2932zA `41b811063b9425de1934e77d891180222oA `43501cdf0de25278a208cbb9aad800122aA `43caef5d41c4e74826e4a8d82088739d2JA `44db1f1fefc97cd28d55d443f2bd2b632MA `4616fbea6a6dbc1074bc3f1016bbc73b2SA `476e17b6f854414033d5cec1470774ee2WA `48b5ab9805919736382ffea5a9554c022VA `494557db52824555864d1106278cd1f02JA `49ba23148db9effdc3979aa0fe5876ea2iA `4a30eeb083acec8460150068ba0c67432BA `4a3c42c9c5ac29db268010bbebf4f5792jA `4ad8239a37f641bcd17abeb96106314e2BA `4afcb20d4d95bcd1bde3aa6b7f5526602OA `4b046ac6a4796fb1338f0481dbd4003d2QA `4b0a768585da8f9f8f8db1ca409e7ebd2\A `4b227d61f33182579cd3edd0ac6c7c442hA `4c08b67e0c1fdeef50b1fdcc32cdcee22[A `4cc08ca51ecf0f963035f039de6194c52TA `4d6c95b0b3ea2ddb30fdd3edf3b823912KA `4d71d2a23c85fb7af20e8d1e8b3e0de82FA `4d8f5e581eee602c7fd21da8eb68df9a2XA `4e7b945feca199bd486653fea1d0e39c2GA `4f88f3eebe44285ded812939553ef94c2QA `4fbdc9c57a37781dc5dd86f470c61d042IA `50557b455cba1a3ce9b4555fc3fd54332`A `50562b09417cd8c4a2348a0a5aabe7542MA `50f43b1726cf61066ef8656477b226be2TA `516a7aa07f8faa6b7aa38beb5010cf8c2sA `538e38fbc3f78cd61e1841d8141ddcc12bA `5412fb82160d0f6093e4b6670f505c132yA `54da1b916f49ef40c822fab61d37cf662KA `550becdd08d00fb1e7fd00c2adc3d3d62iA `55188a318c5998989255253e15ccc1f62oA `563864a949924c505985a168191dcb842LA `56d5711303378bd333ddb611a53ece942cA `584b2b145f362098fc5fc1e634d57de52[A `58e83fb33c120db338132d23b91128052VA `5912529cfd6ce14c5ede5c6c83dae7e82BA `5931f8e3acdac724742c4ee0960d8d402RA `5988b62a0c0785a303b77c74608e8b552`A `59b7b60e6bbf4858d72643d22ad904512GA `59d1b7206e7664e76672d3de4dc9a8ed2FA `5a765f9668608a39333fa90cf462657e2_A `5a9e950f4ac186925e5de978c5f720622wA `5b97ead91c0dd0bad57b4f43a89149a22zA `5badf61ecb9cfadd7d6af58712fa5f6f2XA `5bb6f8322cdbda7a21e4aecbe04462b72pA `5d827a1e8ea70edb11d946b54f076cae2WA `5eebdf85fd1726db301194bfeeee43772lA `615db1a24f36d19a8eaf18d4dceed6b22VA `627a0c45dd07150343c81d856855590e2xA `62f31128a21b0e240bdb7b3d5b121c042qA `6425af51edead39c0e439073986043fb2kA `64a421c2367372c3199c66a6420faf892fA `65453a1ae403679bd2e47398a04205ca2RA `6639ec6f88c4976f8ca20fa840f169e32yA `66f43ab4b823d67f52735bbbe6ba65b02cA `670744b945088de05866864f7d57bee72_A `67c2ae6761e89be0fa66db9623b40d302uA `68a8f34c240a42ab521d2f885f7aa33c2\A `698cf3cbd796161d82c9ac438ebab5d22|A `69f755dd5b9e90a99c3086543790541c2uA `6c226ee1519fbf910197cc1d5c5a57562fA `6e970d0818d58ff2d50c5bf037b1a5652YA `6f47cb314fd780c122adb8cc1f44f7852RA `6fbf7c3d0f4f89e415e89cec28811a942uA `7052598d2355984237d126afea2f6e882ZA `706c033b4483b6d062b66d6e4ea0236a2aA `7164823f504286e3a762ee612ff0a9882]A `7198e10ebcf1bb88dc479b5c5b9f2c152[A `71cf83ae0f45e9ede3a3f979b9c749332nA `7249710187cc2d983709e044dbc78d9d2[A `72df0bf7853e05560d94208817b834682|A `73262345214f9b7794f2cc4a612b15e82QA `73279888a8fe482c836fb19ca23318dc2`A `73b8194ad8fce0cabb01cd21d5e185002_A `73d2fce4efa52675b35a11ee97bc2db02^A `744554499cb7880086fbd9b1f080e7e12jA `75d9268739fe7787ac02d389ac605feb2qA `7604edf307a5e96120606c8dda06458f2aA `76a1fb7f21fda9eddb95426b651245172~A `76e127a44931bfefab991be3dd7a08b72rA `775894425f5a7436f56fc5a3b4a2cfaa2UA `779e444b4bc720a9eed97f19c41e87732OA `77d965afaebd7193badc746d52b4173f2OA `78292d953eafbdf9e57cc4bbbe6e89642XA `7884b62c561b999b9358d52779a182182oA `78da47d61c91c82809a3c97a791d26d22DA `78f002cc3d512ea302c900d1da4dfeec2AA `79e647a3f8b36a1221897f5837c84aff2mA `7a9609a971a8f31685e88da563eea5ce2_A `7b080dc43fce482af14de61c6ab819a52AA `7b6cb59a177abe9767fd22da5a03b1e62CA `7c21b70f9e9c782c1f5153268e0cc1c12XA `7cc21814165879f72529e91682ece5c62QA `7cc605e721fdd1d2ccc16f5b6490e8302~A `7dea465ad52758b10cbceb08c81d17602lA `7e23419e4fc69b5b533815681c9bb1a92DA `7ed1d2efa3e0f0ed6b77eb4eff3d86b32UA `7f78b02c531f09602ba4e140132d26a22tA `7fa2f0877831b4c924438396760f18412aA `7fcfaa8dd34dbd508f19e8ca0fcfda0f2UA `7fded0345c258eea966c0b5ee1b7c7aa2bA `809925e891b0456231c374b09cbe4a902jA `80c8fca02ebfecc7a931dad1ec38466e2vA `827de2d7a9d231f6bcb44caf35896c1f2@A `82a115ab8d617e4e96813587fe3a60492LA `853cac0f2d1f90b7c986e7d1dcdbbfde2@A `88a8e608108be939da9aab5a9a8af7d12jA `898d25a2ab9c0ba1fa9bad462405e4752pA `89abaa7f21cf788ce4744e3e611732912A `8a1ea5d5cf843bc5955a94cfcc321e922sA `8a29f62d1bebfe7b8008d7f264b56b4e2xA `8acc78be63e27e938ee53ec2c0b90c612PA `8b76101d185700a8efed148d8722d9262|A `8cc6b19cd410e638f4beaf1642f4f52a2mA `8d7caf84b3a51cca27291c1f7cfc2d402SA `8d9c3760395e8e0eb40e335b22750b682VA `8f58cbe5f2ce85c22569af765de3f8d32JA `904b07170a0ce481b7491e7fecce4f792`A `90f9355781403b92e844de8568863ae82WA `916bda59bc7621d5c1790c040572a3c02\A `91fe03f994e8e85cede4e3bd62f4d6b72nA `922cc71fd28b1dac8f407f1d517f55952hA `924727b6f380cf3cdfe5650163e920542vA `927612b57ba01ca878b2d7edce52a5632gA `931b2ebd9bfaeb5dcf1973e724a1f8d02]A `9335522f4c8dbc7256a42a091e6e00bc2GA `937a597a8b399fd32caba88a3c1c7bc42SA `94b85ba716dbb7c20b230e69248b82082FA `95c0a5b8a66950b5f22dd82a8dfe0ce52WA `966fe8d32b86121f8a465a21b95f7e5c2PA `9693a1e77dee5785b1dc61ccffd2e9062wA `97402287d8c6c03f0b63848e17e9d9442mA `98c640616f997a323af625e34ba348502LA `991285e3967c3295b4ff2dcd835f7c612gA `992a00c30242b6217243f3c387ea18b72NA `993e58f132740b464ecf06ee289dc7b22xA `997acc135d01b54f7de77a432fb9133f2KA `998eda745d07fd8608f251138384a0b92dA `99c9c80a6532e4ea3b535c5a92d07a252\A `99f5219da22485d0872a2529599c84402OA `9a687babb0f44db51dc389b75bdaa19d2vA `9ac7bb94e60dc30a023ce433de0273642iA `9ad72c2a5157f21741bd4581a562dfc72}A `9baedcd033169611a42c3cfd58b3ae032fA `9cc2a0b6c8be1405cddcdeb4487c59fe2{A `9ccda414c322ebcdf875eacbba2e4b7e2{A `9da845cd31310b8952efd1be1881e6512{A `9dca844d353efed03fbaddfc0fab7c762yA `9f29c6d9719fc6bc09a2981057642b692uA `a0a00c23556fcc5dbfb7b7f43fbbb61d2zA `a106d7c1b1b277538367f9c8140e3a752[A `a12474027c91fad5a861aa9919817d722wA `a2012a3c9cdb1d6fd69afdbadc1e76b62ZA `a2679a7d860a0bfb2645809ed92ce1382^A `a4462529ab493676987d946019a149452nA `a46c601d03a3a26bc418d0096fe83a422YA `a578acf825a595ce95fe8f804b7208f02lA `a5b2ee641e10d3e4db8f888217ab9ecc2LA `a62186ea292d6db03a087bd5dfcc3f1e2fA `a65bd31d4c3dab0a41712823a5d6002b2@A `a673b3829e62477e01abc75465416b862VA `a7f0e85fcad4f5bc5ae5c18c10de4f9e2KA `a98d42be181c01b8077e060b1b5080ec2hA `aa61b4543e8a7c67fccabee27a6e99cd2gA `abc5ca9856a61831fd4ed06b402875d22cA `b051fd352847c06e748b345e8ed0738b2oA `b16bddd1a6d3e5f4136446bebe7ffbc72PA `b2621497b3313c97855ed951f0d9b2912tA `b27bdabd8e1a6b7dc06886867331ceb32tA `b2c4cf0fb96d02d37f03668caaecbc572|A `b36abffbe5d6a0de73a9968604a1a3f92|A `b5c628b0c1dbf857a475c4be5de4690d2FA `b875f24d3d444fdda82b6bbfb75a4c922qA `b9d4f73fa7ca8ef66891554b66b2cded2wA `ba45ddd3042dad59a12e5937644f72462~A `bbd2824ff0d5b801bb6f5da3a2a1a8882A `bbe1deec11d459bdb348051b970abdaf2JA `bc2709406a9bb19e8d83a78f81e362442A `bce2fa6458f39a75e2713f3d687271a12jA `bda9a5da86ec9790262e14f953bbadcb2PA `bdea71d64cdfcc405e65e750fe8d9b862LA `be2c49ea5816e7daa6d3b3ff453532912KA `bed3b7fcc1294e23639057435ac8756a2dA `bf4f86812812dab8d39db9aaefe94a782HA `c098c6f0901979bd914ed7a345200f902CA `c0e423f9ac41cc5b265c95a3e97e3fcb2dA `c1241374502f200cf9fc49c8d6fb58222sA `c18b12fff24dc87e7f1039bd17c0c6aa2FA `c20d71627e66a044b21780f56f2f95042nA `c2d39f2f7fe6cb69fc8efb6c5495c9322^A `c3053579ae25e2fb9b967076a06373af2rA `c377351433a941a927aab543931f60262EA `c4b418764dca70aebfc965899a3fa7e52PA `c4d3a917f623f58646ce93015d79e8e02QA `c4dba56f2db4851cd31b561d92dc5e352oA `c4e7199a586a308352b7a881add7e3562RA `c54909ecf4fb3e9afeea36200fe95dce2OA `c56a76ef8f604a8d87be2a32b1f81fac2mA `c6107ff57e96a1373c019d252c00ad842bA `c61a5bda3f1667498626ae52ad0362e02dA `c6696a730f7498efb66f5ba3a8b35d082\A `c6dc6e6567d673436ac41ebc8e79a9ec2mA `c6fc88bd57a0e57ddf22e2eb1bef892c2GA `c70b78fd0b5dffcd38322355e9c2471e2MA `c7937b6b4bde2a96191dc31db913e1ab2GA `c92c12a28fa219ad1aab60865046ff052lA `c98cbc333fb7d95c6c9fc4924b0526e12XA `c9d257aba54475c20b3737ce7c779e552sA `cb13b64d0127c13bb466c4d4677a7b8a2tA `cb5b6f7ab4d36e90d2619cb907ebb9562}A `cb9649eca3dfbd356527ffc88f1dcb942@A `cbf9587a8187985725963b8bfc67004d2kA `cc1a3b2f107510ac664e491d5f2412aa2`A `cc573488dec311655890a205aad4fb652ZA `cc64c2fcdecdb505b3797e1aaaa59adc2UA `cd90bce912f5743226af94c1efaaa4a72EA `cd9ba1f582642d9cbe500f018afab3412BA `ce0aea06d44878b4a373efe090a66a622dA `ce426b7f3190c8a4a47d45ac799e91a42rA `ced9df0d8c8ed14de91c509b31b4c4ae2uA `d08a3fdc040bbbdd81c9927ce296318c2QA `d12c1c2a68be4c7fda5a7737d5493b4d2zA `d13aa56e27fe71ef40ff153c093ecdf82IA `d266a2023c67b7a20c3bd01055b223bc2@A `d2e805472f79f0b558f75b90b5e7b4ee2yA `d3fa23c9066f943f10e8883de9340dea2eA `d51032bef3e7117a94336fea18a3fad72ZA `d710a073be2da219a388a150eb7b6b6a2IA `d77cdb466c5063b99c5aea58e6da4d322}A `d791eaca9375ca1b36a987af22ee71dd2qA `d8041ae308961666b15aa1e57b0f9f352SA `d819cea5197e9b8673d6c0b16659a5ea2RA `d869fb48cb9acba03dc639481524ee802cA `d9018f459d3c94a91e92b459e152f7e72iA `d95522c691013bfe66dd46ded85a98ed2vA `d9560caeb797b302191f667b4264da402rA `d96f80f23543850a2ee9fff8cd2cc53f2lA `d9c6ab5c6630a4a84e242c5765103d2d2bA `da67e2f049b5b6babcf7906b856533992\A `daa3fe935b0be9f31b6b362ad9e0d2d62ZA `db97311c24809f103575d8a7fee196802XA `dbcc4002c15afefef853a08a0804ba3a2PA `dc9580308938069159c5afc55b2f3b962rA `dc962e34780f0374b7eb3d583f6d7eb62wA `dcc2e24df32287e89ee3b0f64d617f572cA `dd6c32a722dc815273cd9ed8cd6c671b2hA `ddab6357ff522c0c956ebd7669e834542vA `ddd3e6f6e298d3884abc4d888a0436642sA `de1ab82817c0fb24e591b9a89a82f7362qA `de37d9fae011687eb1eb5a127fcb89e32CA `de734259dfb9addebe2b226d96b4f7442^A `df30d810068e4656498e5972c6de7e3d2kA `e01e01d18582c7f69e1b0db7e1b111a02YA `e159a35d1b9a46e03072a3d54780edcb2A `e1870dde155be1a375f155dd1f7ead132TA `e30258aeb8475d4c27f79359456718562_A `e396cbf9274b590a1d94ee43d823a0bd2TA `e3e146469ed4318eaa2ffbca3510c0542@A `e5390751969ab21df280b7591854b89f2}A `e5cb2e5d501d3db2db5d8f14984a66d42~A `e6684944c37dbdd4c08d978af9e47bed2AA `e74d071363645a588f858b35231128c42xA `eb2a5824e03996c1966bee38866ce3492eA `eced95e5f301a8340e83d81d3c0d5c0d2LA `ecf3ac80454654d990d9c07d33d35d1c2YA `ed431877ce11fe403fee77f7d26ce6372]A `ed4f5a398056eef1cf6caa90786b340a2~A `ee48516e57684c5a4c22adccac34be922dA `ee4ff9e4e8a1948795e26af2f3f8a30f2RA `ee623aaa99b429863f89da313fffed972vA `ee62cb0b9a97f990df1ed0266a7027e22uA `eee039f49a5b570599cf459c55c649f32NA `eeef60efe889349870426d10edc694be2]A `ef8a399c9679ce4e9710c7c6ecf8bcc72\A `f0fdc140e18514362a4e52376a6fecba2NA `f15702ae9e55bad42182cf18724d18632~A `f23ca2aa066b1ee0fa4df1f2f865be4c2tA `f2cbe07bf2ff16d5a5860b4d6edbc5e82DA `f3a9b931b7f552a4f9dfa61ce4f39f0e2kA `f3ef819656f68b87a91c53afbd441fec2cA `f41d4fde94cbd7bbd28808dc080a20192RA `f45069216cd934b80ce882c9a2f2a08a2NA `f488aa62d39194824861a134567cadb82bA `f4baa43cc7ca712d83b99a794c4e2dbd2jA `f55d33371dcff207fd7d201128df2ea32VA `f56c19442484b3e4f47875b58b3f72b22yA `f5effd616a3f8db6193b482caec379122aA `f5f28f42ad234b4389af4cbea54ff60d2nA `f6debed350f20a2b3aa4d970e32274112KA `f6dff70097776e24c2a7c9c0f2514f792_A `f7df7b85af230b2623d3a827b0cbddd22OA `f8327953a0f0b80011b939111807999a2eA `f887e1aabf801e351bfb39698f208af12WA `f9e847ee886bdb9ab5583eeb6eabbd512EA `fa0486610d8a02cea245c13c85b6de272YA `fa16213d24273d386d22332cd01ce7742RA `fb1da4a6ed74705ad98bb60ad4badaf22fA `fcb0105fa6b5777a133f247784b9d9302{A `fe6ba10cc6c9509b4b22e9d59e0297752QA `ff1441a42144a7de9a3eaf9f5e7cfea92BA `ffdbd6a7d28c9a63976e9eec38cab0f5>xdtypefstringvetitle3vddocs<ya1Vya2Bya3Vya4~ya5]ya6nya7Eya8mya9Iyb10Dyb11Fyb12\yb13Eyb14Ayb15Hyb16ryb17syb18Xyb19Jyb20_yb21^yb22Fyb23tyb24Tyb25yyb26@yb27_yb28nyb29uyb30Eyb31Dyb32Cyb33pyb34|yb35ayb36\yb37Uyb38Fyb39lyb40Yyb41qyb42~yb43Yyb44yb45Kyb46}yb47yb48Gyb49Hyb50Fyb51^yb52Zyb53Eyb54Fyb55zyb56wyb57}yb58Yyb59^yb60eyb61ryb62yyb63zyb64myb65dyb66cyb67oyb68Gyb69Hyb70jyb71uyb72tyb73oyb74wyb75vyb76Oyb77\yb78iyb79myb80Iyb81hyb82[yb83gyb84Dyb85fyb86qyb87kyb88Cyb89Pyb90Zyb91Qyb92]yb93lyb94kyb95\yb96nyb97Ryb98eyb99kyc100jyc101iyc102hyc103Qyc104~yc105}yc106Iyc107Oyc108Tyc109Ryc110dyc111^yc112tyc113_yc114Jyc115Kyc116myc117}yc118Gyc119[yc120Vyc121qyc122Syc123cyc124Zyc125nyc126lyc127kyc128Jyc129byc130ayc131|yc132\yc133Zyc134|yc135dyc136[yc137{yc138Yyc139\yc140fyc141ryc142hyc143gyc144^yc145fyc146zyc147Xyc148~yc149dyc150oyc151pyc152Zyc153Wyc154`yc155`yc156Xyc157cyc158Wyc159Cyc160ayc161Vyc162Uyc163Oyc164~yc165Yyc166]yc167Tyc168Fyc169Tyc170_yc171byc172Dyc173Syc174Ayc175Ryc176uyc177Qyc178Tyc179byc180]yc181Xyc182Pyc183Myc184@yc185yc186Oyc187@yc188yyc189[yc190@yc191Nyc192Ryc193[yc194ayc195_yc196Wyc197Myc198Uyc199cyc200yc201Lyc202Byc203yyc204Kyc205}yc206oyc207syc208\yc209fyc210Jyc211Ayc212|yc213Kyc214Qyc215`yc216Lyc217Iyc218[yc219Nyc220Qyc221`yc222jyc223{yc224yyc225kyc226Uyc227lyc228myc229byc230}yc231syc232Ryc233ayc234Nyc235vyc236`yc237eyc238^yc239kyc240Byc241xyc242xyc243Iyc244vyc245fyc246Syc247Tyc248hyc249syc250zyc251ayc252eyc253gyc254cyc255iyc256nyc257Wyc258jyc259pyc260Jyc261Jyc262Kyc263byc264_yc265Lyc266byc267_yc268uyc269Yyc270qyc271Uyc272eyc273iyc274yyc275hyc276xyc277wyc278zyc279Ryc280Syc281lyc282oyc283syc284dyc285Wyc286Oyc287Hyc288`yc289dyc290Xyc291Kyc292Ayc293Vyc294Syc295Xyc296wyc297Nyc298Cyc299Syc300Byc301jyc302xyc303{yc304Zyc305pyc306{yc307@yc308]yc309Xyc310Hyc311qyc312xyc313Byc314tyc315Nyc316Myc317gyc318Ayc319jyc320Lyc321yc322Yyc323Qyc324[yc325iyc326Wyc327Gyc328ryc329Uyc330wyc331Pyc332Myc333pyc334Qyc335Ryc336tyc337{yc338]yc339lyc340^yc341vyc342Hyc343xyc344nyc345Dyc346|yc347Gyc348qyc349yc350Wyc351ryc352Pyc353vyc354pyc355Vyc356wyc357ryc358Eyc359Zyc360Cyc361Vyc362Iyc363zyc364eyc365uyc366Uyc367Nyc368Pyc369myc370Qyc371Dyc372tyc373Pyc374Oyc375@yc376Pyc377vyc378Tyc379~yc380Syc381Ryc382Cyc383Pyc384Gyc385Myc386Byc387Ayc388fyc389iyc390]yc391Lyc392hyc393uyc394Eyc395{yc396Myc397|yc398gyc399syc400Lyc401cyc402oyc403g>wkorderedDocs<w2ypxAxp _「7つの言語　7つの世界」 Io 0日目(Jugemより移植)2rA _「7つの言語　7つの世界」 Io 1日目(Jugemより移植)2}A a「7つの言語　7つの世界」 Ruby 1日目(Jugemより移植)2|A a「7つの言語　7つの世界」 Ruby 2日目(Jugemより移植)2zA f「7つの言語　7つの世界」 Ruby 3日目（最終日）(Jugemより移植)2IA ~「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（2章～4章）(Jugemより移植)2iA v「Apache Solr入門」のサンプルのlucene-gosen対応（1章から4章）(Jugemより移植)2FA Y「IDの秘密」を読みました。(Jugemより移植)2gA ~「コード・シンプリシティ」を読みました。（Kindle paperwhiteの使い勝手の確認も兼ねて）(Jugemより移植)2hA e「コンピュータシステムの理論と実装」を読み始めた #Nand2Tetris2gA e「どんな本でも大量に読める「速読」の本」を読みました(Jugemより移植)2ZA d「よくわかるAmazon #CloudSearch 」に行ってきました！2_A U「検索システム探訪」したいな=>やりました2RA e「自分の小さな「箱」から脱出する方法」を読みました。(Jugemより移植)2PA S「自然言語処理の基本と技術」を読んでる2HA x『プログラミング Hive』 『Hadoop 第3版』刊行記念セミナーに参加しました！ #oreilly07242KA i【メモ】Amazon CloudSearchが出てきましたよ(Jugemより移植)2NA e【重要】lucene-gosen 2.0.0リリース(Jugemより移植)2OA f【重要】lucene-gosenの次期リリースについて(Jugemより移植)2kA u#DSIRNLP 3.5に参加しました。＆「Emacs実践入門」を頂いちゃいました！(Jugemより移植)2rAo#elasticon に参加中2nA T1.2.0リリース(Jugemより移植)2cA X1.2.1リリースしました(Jugemより移植)2DA S2014年のElasticsearch2SA S2015年のElasticsearch2JA S2016年のElastic Stack2EA [2017年のElastic StackとElastic2wA [2018年のElastic StackとElastic2DAo2018年のElasticは？2\Ao2019年に買ってよかったもの2oA [2019年のElastic StackとElastic2[An2021年かって良かったもの2]A \Aggregations - ファセットよりも柔軟な集計2BA aAnalyze UIとKibanaのプラグインの作成方法（第1回）2AA aAnalyze UIとKibanaのプラグインの作成方法（第2回）2{A aAnalyze UIとKibanaのプラグインの作成方法（第3回）2nA iApache LuceneのKuromojiのUniDicビルド対応パッチについて2PA yapache-loggen + fluentd + elasticsearch + kibana = ログ検索デモ2DA XApple教に入信しました(Jugemより移植)2}A oautoGeneratePhraseQueriesのデフォルト値について(Jugemより移植)2SA oAWS Summit Tokyo 2013に行って来ました。(Day1) #awssummit2QA oAWS Summit Tokyo 2013に行って来ました。(Day2) #awssummit2mA lAWS ビッグデータ活用事例セミナーに参加しました。#jawsug(Jugemより移植)2^A cAzure Cognitive Searchでインデックスを作って検索2gA kAzure Cognitive Searchでオートコンプリートやサジェストをしてみる2@A hAzure Cognitive Searchでの日本語向けAnalyzerの違い2\A rAzure Cognitive SearchのIndex Schema JSONをCSVで見たくなる2CA aAzure Cognitive Searchのリクエストのロギング2aA pAzure Cognitive Searchの新機能、Semantic Searchを試してみた2NA TBasho Japanに遊びに行きました2}A [Berlin Buzzwordsにオンライン出張してた2gA QBerlinからおはようございます2pA `Bonfire Data & Science #1に参加しました2mA [Bookscanを使ってみました(Jugemより移植)2UA ZClean Coderを読んだ(Jugemより移植)2UA cCloudera Searchってのが出たらしい（とりあえず、雑感？）2TA WCloudera Searchのモジュールたち2RA VCloudera Searchメモ（妄想版）2zA kCloudera World Tokyo 2013に参加しました！ #cwt2013 2KA rcompositePOS（CompositeTokenFilter）のバグ修正(Jugemより移植)2MA tcompositePOSの利用例（naist-chasenでの英単語の出力方法例）(Jugemより移植)2nA _Corne Chocolateを組み立てた #DIYキーボード2jA fCorne Light v2のBLE+LPME-IO対応 #DIYキーボード2oA ]Corne Light v2を作成した #DIYキーボード2{A ^CROSS 2015で話をしてきました #cross20152SA UCurator 1.2および1.1について2pA [Curator: 時系列インデックスの管理(日本語訳)2_A `Delete by Query APIはプラグインへ（日本語訳）2lA Ydiscuss.elastic.co にぜひ参加を2^A!]Domain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだ2rA UDozen0を作成した #DIYキーボード2vA aElastic Stack 7.0で入ってくる新機能をちょっと紹介2EA YElastic Stack 7.7がリリースされた2sA pElasticsearch 0.90.8がリリースされました＆注意点（2013/12/20追記）2RA ^Elasticsearch 1.3.1 リリース（日本語訳）2LA ^elasticsearch 1.4.0.Beta1のリリース2IA eElasticsearch 1.4.0および1.3.5リリース（日本語訳）2EA eElasticsearch 1.4.1および1.3.6リリース（日本語訳）2A eElasticsearch 1.4.2および1.3.7リリース（日本語訳）2zA eElasticsearch　1.4.3および1.3.8リリース（日本語訳）2vA eElasticsearch 1.4.4および1.3.9リリース（日本語訳）2qA ]Elasticsearch 1.5.0リリース（日本語訳）2oA ]Elasticsearch 1.5.1リリース（日本語訳）2mA gElasticsearch 1.5.2 および 1.4.5リリース（日本語訳）2iA ]Elasticsearch 1.6.0リリース（日本語訳）2bA gElasticsearch 1.7.0 および 1.6.1リリース（日本語訳）2aA gElasticsearch 1.7.1 および 1.6.2リリース（日本語訳）2^A cElasticsearch 2.0.0-beta1リリース（日本語訳）2\A cElasticsearch 2.0.0-beta2リリース（日本語訳）2eA eElasticsearch 2.0.0.beta1リリース間近（日本語訳）2XA ]Elasticsearch 2.0.0リリース(日本語訳)2}A [Elasticsearch 2.0系のIssueの紹介2KA YElasticsearch 5.0の便利機能紹介？2tA ZElasticsearch Coreトレーニング開催2nA \Elasticsearch Marvelの紹介と第一印象2qA _Elasticsearch NEXT STEP 2を頂きました2WA nElasticsearch server 2nd editionのファーストインプレッション2iA [ElasticSearch Serverを翻訳しました2eA fElasticSearch Server日本語版（電子版も）が発売されました2]A pElasticsearch unplugged - 2.0におけるネットワークの変更(日本語訳)2aA uelasticsearch-analysis-kuromojiでユーザ辞書の利用方法(Jugemより移植)2|A aelasticsearch-extended-analyzeの改良2uA welasticsearch-extended-analyzeプラグインをMavenとSonatypeにリリース2}A gelasticsearch-extended-analyzeプラグインを開発中2xA belasticsearch-extended-analyzeを公開？2A `elasticsearch-inquisitorプラグインの紹介2^A `elasticsearch-kopfの紹介（aliases画面）2aA aelasticsearch-kopfの紹介（analysis画面）2cA ]elasticsearch-kopfの紹介（rest画面）2dA Yelasticsearch-kopfの紹介（概要）2@A aelasticsearch-river-wikipediaの疑問点2NA lelasticsearch.もうちょっと入門という話をしてきました #gihyo_efk2CA kElasticSearchにプラグインで日本語Wikipediaデータを入れてみました2VA xElasticsearchのAnalyze APIのVisual Studio Codeのクライアントプラグイン2PA lElasticsearchのアーキテクチャとStateless / Serverless2OA bElasticsearchのインデキシングに関するパフォーマンス検討2WA [Elasticsearchの新しいJavaクライアント2pA ~Elasticsearch勉強会 in 名古屋を開催しました。#elasticsearch #elasticsearchjp2KA dElasticのWorkplace Searchを触ってみる - その12JA pElasticのWorkplace Searchを触ってみる - その2 - インストールと起動2qA bExtended-Analyze 1.0.0RC1をリリースしました2YA!MExtreme Multi-label Learning for Semantic Matching in Product Searchという論文を読んだ2VA afluent-plugin-zoomdata作りました＋悩み事とか2rA wFluentd meetup in Japan #2 #fluentd に参加しました。(Jugemより移植)2ZA gFluentd Meetup Japanに参加しました。(Jugemより移植)2fA _GOTO Night elasticsearchに参加しました2TA QGoでSlackのボットを作った話2yA bGroovyスクリプトをダイナミックスクリプトなしで実行(日本語訳)2wA vHadoop Conference Japan 2011 Fallに参加してきました。(Jugemより移植)2dA }Hadoop Conference Japan 2013 Winterに参加しました。#hcj13w(Jugemより移植)2yA wHadoopソースコードリーディング第10回に参加しました。#hadoopreading(Jugemより移植)2hA hHadoopソースコードリーディング第7回に参加しました。(Jugemより移植)2YA vHadoopソースコードリーディング第8回に参加しました。#hadoopreading(Jugemより移植)2JA!CHadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）に参加しました。(Jugemより移植)2hA vHatena Engineer Seminar #5 @ Tokyoに参加しました。 #hatenatech2GA oHeroku JP Meetup ＃4に参加しました。#herokujp(Jugemより移植)2_A!JHeroku Meetup #8 TreasureData + Waza Report!! に参加しました。#herokujp(Jugemより移植)2jAkhomeshick導入2SAmHugoをアップデートした2mA QIndex Template V22@A ^Issue32について（4096の壁）(Jugemより移植)2LA qJava One Tokyo 2012 に参加しました。#JavaOneJp(Jugemより移植)2iA nJIRAのDB移行（HSQLDBからPostgreSQLへ）#augj(Jugemより移植)2^A ]JIRAのデータをS3へバックアップ(Jugemより移植)2pA gJJUG CCC 2011 Fallに参加してきました。(Jugemより移植)2CA iJJUG CCC 2012 Springに参加してきました。(Jugemより移植)2@A fJJUG ナイトセミナーでLuceneの簡単な紹介をしてきました。#JJUG2zA QJJUGナイトセミナーで話しました2gA mJustTechTalk#02 形態素解析のあれやこれや@ジャストシステムに参加しました。2bA lJVM Operation Casual Talksに参加しました #jvmcasual2QA Tkagome-botのユーザーサービス化2YA VKibana 4.2.0リリース（日本語訳）2uAnKibana 4（日本語訳）2MA QKibana3というのもありまして2ZA `KuromojiのCLIコマンドとpicocliとGraalVM2RA aKuromojiのCLIコマンドにJSON出力とラティス出力を追加2MA \Kuromojiのカスタム辞書をインデックスの設定で指定2FA YKuromojiを調べてみた(Jugemより移植)2sA aLinderaのFSTをDoubleArrayTrieに変更した話2CA ^Logstash 1.5.0 Beta1リリース(日本語訳)2ZA XLogstash 2.0.0リリース（日本語訳）2BA ]Logstashプラグインのエコシステムの変更（日本語訳）2kA gLogstashを使ったElasticsearchの再インデックス（日本語訳）2GA _Logstashを利用したApacheアクセスログのインポート2\A!YLucene 4.3.0のChangesにあるChanges in backwards compatibility policyが気になったので訳してみた。(Jugemより移植)2lA sLucene Eurocon 2011 Barcelona のスライド読みました(Jugemより移植)2LA!NLucene Kuromoji for NEologdで指定した品詞の単語を抜き出すIngest Pluginを書いてみた #elasticsearchjp2NA blucene-gosen 1.1.0 リリース(Jugemより移植)2HA alucene-gosen 1.1.1リリース(Jugemより移植)2EA jlucene-gosen 2.0.1リリース（Java7対応）(Jugemより移植)2A nlucene-gosen 2.0.2リリース（リソース周りの改善など）(Jugemより移植)2oA ^lucene-gosen 4.6.1のリリースに関する注意点2YA!Clucene-gosen4.3.0をリリースしました。（Lucene/Solr4.3.0以上での利用が可能です）(Jugemより移植)2qA llucene-gosenで文章からキーワード抽出（イレギュラー？）(Jugemより移植)2XA vlucene-gosenとSynonymFilterを利用するときの注意点（問題点編）(Jugemより移植)2RA Ylucene-gosenとは(Jugemより移植)2MA ilucene-gosenのJava7でのテスト失敗問題の対応(Jugemより移植)2wA nlucene-gosenのLucene/Solr4.0-ALPHA対応(Jugemより移植)2_A nlucene-gosenのLucene/Solr4.0対応ブランチ更新(Jugemより移植)2OA elucene-gosenのTokenFilterたち(Jugemより移植)2zA `lucene-gosenのUniDic対応(Jugemより移植)2IA bLucene/Solr 3.3リリース（速報）(Jugemより移植)2yA bLucene/Solr 3.4リリース（速報）(Jugemより移植)2JA!SLucene/Solr 3.6.0リリース / 「Apache Solr入門」のサンプルのKuromojiとlucene-gosen対応（1章）(Jugemより移植)2nA sLucene/Solr 4.0.0リリース＆lucene-gosenの4.0対応(Jugemより移植)2~A gluceneutil - Analyzer性能テストへのkuromojiの追加2A ]luceneutil - マニアックなツールのセットアップ2oA mLucidのGrant Ingersollさんの講演を聞いてきました(Jugemより移植)2bA mLunakey Miniを組み立てて、BLE+LPME-IO化してみた #DIYキーボード2iA ZmacOS標準のターミナルのウィンドウグループが便利2dA [Mappingのすばらしいリファクタリング（日本語訳）2]A \MapR中身説明会に参加しました。(Jugemより移植)2~A VMarvel 1.3.0リリース（日本語訳）2CA WMBAセットアップ備忘録(Jugemより移植)2BA ZMBAセットアップ備忘録その２(Jugemより移植)2~A ZMBAセットアップ備忘録その３(Jugemより移植)2sA ZMBAセットアップ備忘録その４(Jugemより移植)2fA }MBAセットアップ備忘録その５とMac Mini（2009late）セットアップとその他くだらない話(Jugemより移植)2vAnmeteredクレートの紹介2DA yMicrosoft Build(2020)のAzure Cognirive Searchのセッションを見たのでメモ2vA VMIR輪読会始めました(Jugemより移植)2jA cMongoDB勉強会（第7回）に行って来ました。(Jugemより移植)2DA _MorphlinesのloadSolrをちょっとだけ調べてみた2FAmMorphlines入門？2GA vNAIST-JDic for MeCabのPreprocessorの実装に関する備忘録(Jugemより移植)2LA gNAIST-JDic for MeCab対応版（仮実装）(Jugemより移植)2jA YNested Objectのフィールドの奇妙な動作2vA gNew SolrCloud Designの翻訳（その１）(Jugemより移植)2uA gNew SolrCloud Designの翻訳（その2）(Jugemより移植)2gA YOctopressからHugoへ移行中(まだ途中)2WA XOctopressを試し中(Jugemより移植)2XAnOctopress始めました2lA WOctopress環境のDockerイメージ化2eA [OData式と日本語の検索(NGram)とフレーズ検索2SA ZOramaという検索エンジンでブログ検索を作ってみた2^A aOSSAJのミニセミナーで話しをしてきました(Jugemより移植)2uA vPartial UpdateとcopyFieldのバグ【Solr 4.0 ALPHA】(Jugemより移植)2kAjPCもDIYしました2pA qPFIオープンセミナー2012に参加してきました。 #pfiopen2012(Jugemより移植)2DA kPlayFramework 2.0(Javaの方)を触ってみてる(Jugemより移植)2\A ^pre-commitとvenvとPyCharm（困ったな？）2tA Python Developers Festa 2012.07に参加してしゃべってきました #pyfes(Jugemより移植)2UAnQuerqyの調査（その１）2TA VQuerqyの調査（その2：アーキテクチャ）2[A VRelease, we have（日本語訳）2{A _Riak Meetup #3 #riakjp に参加しました。2JA cRiak Meetup Tokyo #2に参加しました。#riakjp2BA TRust the book - 第10章2AA TRust the book - 第13章2|A TRust the book - 第15章2UA SRust the book - 第4章2SA SRust the book - 第5章2QA SRust the book - 第6章2NA SRust the book - 第8章2FA SRust the book - 第9章2WA SRust the Bookを読み始めた2SA UScala始めました(Jugemより移植)2tA wSearch Engineering Tech Talk(検索技術勉強会)の運営として参加して始めてみました。2VA Xsearch-UIとSearchkitと検索画面2VA eSenseの歴史 - Sense 2.0.0-beta1の紹介(日本語訳)2WA hShield、Watcher、Marvel 2.0.0 GAリリース（日本語訳）2iA iSofle v2を組み立てて、BLE+LPME-IO化してみた #DIYキーボード2HA wSolr 3.6.0のCJKの設定とSynonymFilterFactoryの気になる点(Jugemより移植)2[A cSolr4.3.0のChangesを訳してみた。(Jugemより移植)2tA gSolrの新しい管理画面（Solr4.x trunk系）(Jugemより移植)2LAoSolrの管理画面でデータ登録2tA TSolrへのプラグインの配置方法について2dA fSolr勉強会第７回に参加しました。（発表もしました）(Jugemより移植)2xA eSolr勉強会第8回に参加しました。 #SolrJP(Jugemより移植)2KA VSonatypeのバージョン番号で困ったので2kA eSplunk Live!のイベントに行って来ました。(Jugemより移植)2_A Rstream2esと複数データの登録2FA XSwiftypeがジョインしたので触ってみました2yA iTerraformでAzure Cognitive Searchのクラスターを起動2TA tTimelionの紹介 - Elasticsearch Advent Calendar 2015 1日目2AA {trunkのライブラリ差し替え（Lucene/Solr3.6.0）とランダムテストの失敗について(Jugemより移植)2sA jTwitter 勉強会 #twtr_hack に参加しました。(Jugemより移植)2~A oTwitterが公開した分散トレーシング（追跡？）システム、Zipkin(Jugemより移植)2JAovalidate APIの利用2XA {Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)2ZA kVS CodeとDev Container（docker-compose.yml対応）2WA _VS CodeとDev Container(コンテナ名の指定)2[A ^VS CodeとDev Containerの導入（まだ途中）2pA PWindowsへの移行（その１）2qAlWindowsをお試し中2YA UWSL2のディストリビューションの環境移行2EA WXperia Zが故障したので交換したのでメモ2cA XXperia Z買いました(Jugemより移植)2IA XYokozunaの気になる点というかなんというか2|A kZipkinのReadmeを読んでる（クライアント周りについて）(Jugemより移植)2{A dZipkinのReadme読んでる（その２、残り）(Jugemより移植)2kAgzshへの移行2`A cあけましておめでとうございます＋会社のブログ更新(Jugemより移植)2\A Sアジャイルデータサイエンスが届きました2hA [いつも入れているElasticsearchのプラグイン2fA sいまさらですが、CROSS 2013で検索CROSSというセッションを担当します(Jugemより移植)2XA hインデックスエイリアス - Azure Cognitive Searchの新機能2FA UインデックステンプレートとLogstash2eA }エンジニアサポートCROSS 2013に参加（＋お手伝い＋モデレータ）しました #cross2013(Jugemより移植)2]A!Xエンジニアのためのスキルアップ勉強会『Tech Compass』 #tecomp ― Vol.2 「人気Webサービスの作り方教えます！」に参加しました。(Jugemより移植)2bA!`エンジニアのためのスキルアップ勉強会『Tech Compass』＠竹橋 ― Vol1 「スマホ時代到来、この先生きのこるエンジニアとは！？」に参加しました。#tecomp(Jugemより移植)2BA Zオープンソースへの貢献のススメ(Jugemより移植)2|A bカンファレンス情報の探し方（CfP、スポンサー応募、開催期間など）？2AAhコーヒーブレイク2PA cサーバ/インフラエンジニア養成読本 ログ収集~可視化編 を手伝いました2fA Rさらに進化したFound（日本語訳）2{A aシステムの特徴と検索機能について(検索システムに関する妄想その1)2KA ^スキーマレスモード？（SOLR-4897）を調べて見ました。2lA lすずけんさんのメモを元にVagrantでElasticsearchクラスタを起動してみた2cA Sスライド作成の環境をMarpにしてみた2sA ^セキュリティ向けプラグインShieldのリリース（日本語訳）2QA Wソースからのビルドと構成(Jugemより移植)2GA Vデータ分析基盤構築入門 を一部執筆しました。2bAoフリーランスはじめました(仮)2QA Uプロキシ環境でのpluginコマンドの実行2SA Sブログはじめます(Jugemより移植)2fA Wブログ移行日記(その1) - Hugoとテーマ2eA ^ブログ移行日記(その2) - Markdownファイルの変換2dA dブログ移行日記(その3) - Hugoの設定と微調整(テーマに合わせた)2cA _ブログ移行日記(その4) - 検索機能(Algolia)の導入2]A [ブログ移行日記(その5) - Jugemのブログを移行2XA Xブログ記述環境としてのDev Container2`Ahボードゲーム紹介2ZA iポモドーロ回してます。（ポモドーロテクニック入門読みました）(Jugemより移植)2qA oメインMBAをMountain Lionにアップデート（いろいろ確認中）(Jugemより移植)2\A aモーショノロジー2012#1に参加しました。(Jugemより移植)2MAhよく物が壊れる年2QA kローマ字入力のゆれと読み（JapaneseCompletionAnalyzerその2）2PA [久々にMac Miniのことでも(Jugemより移植)2]A V今年のDIYキーボードとコントローラーラック2aA Y今年の振り返りと来年の抱負？(Jugemより移植)2hA ^今年の振り返りと来年の抱負（2012）(Jugemより移植)2rA S今年の振り返りと来年の抱負（2013）2|A S今年の振り返りと来年の抱負（2014）2RA S今年の振り返りと来年の抱負（2015）2IA S今年の振り返りと来年の抱負（2016）2CA S今年の振り返りと来年の抱負（2017）2uA S今年の振り返りと来年の抱負（2018）2hA S今年の振り返りと来年の抱負（2019）2lA S今年の振り返りと来年の抱負（2020）2ZA S今年の振り返りと来年の抱負（2021）2^A S今年の振り返りと来年の抱負（2022）2RA S今年の振り返りと来年の抱負（2023）2`A ^今年もBerlin Buzzwordsにオンライン出張してた2_A S今年もMICESにオンライン出張してた2]A ^今年もオンラインでBerlin Buzzwordsに参加した2VA ^今年もオンラインでBerlin Buzzwordsに参加した2[A S今興味があること(Jugemより移植)2_Ai仕事中のBGM環境2YA W最新インフラエンジニア技術勉強に参加しました。2rA U勉強会の受付自作？アプリ？HTMLについて2sA Q勉強会運営座談会ってのをやってみた2XA Y可視化ツール現状確認会に参加してきました。#可視化2wA Z名古屋でElasticsearch勉強会を開催します2[Al外の世界を知るということ2cA o大阪と京都でElasticsearch勉強会を開催しました。 #elasticsearchjp2YA R実践Rust入門の3章を読み終わった2[A S実践Rust入門の3章を読んでるところ2aAn実践Rust入門はじめました2vA Q改訂版Solr入門のPDF版も発売2wA P改訂版Solr入門を執筆しました2OA V新しいsolr.xmlとCore探索ロジック2xA W新規導入した長期出張用のアイテムをいくつか紹介2AA c日本語Wikipediaをインデクシング（Kuromojiバージョン）2RA Y日本語用オートコンプリートのためのAnalyzer2zA _検索システムを構成するパーツ(検索システムに関する妄想その2)2tA `検索対象のデータとデータソース(検索システムに関する妄想その3)2HAn検索座談会ってのをやってみた2dA ^検索技術に関する情報交換を目的としたSlackができました！2UA Y機械学習による検索ランキング改善ガイドを読みました2TA q第0回 Twitter Hack #twtr_hack に遊びに行きました。(Jugemより移植)2jA l第10回Elasticsearch勉強会を開催しました。#elasticsearchjp2`A e第10回Solr勉強会を主催しました。#SolrJP(Jugemより移植)2`A l第11回Elasticsearch勉強会を開催しました。#elasticsearchjp2GA Z第11回Solr勉強会を主催しました。#SolrJP2~A Z第12回Solr勉強会を主催しました。#SolrJP2UA l第13回Elasticsearch勉強会を開催しました。#elasticsearchjp2mA R第13回Solr勉強会を開催しました2QA m第14回Elasticsearch勉強会を開催しました。 #elasticsearchjp2OA m第15回Elasticsearch勉強会を開催しました。 #elasticsearchjp2NA m第16回Elasticsearch勉強会を開催しました。 #elasticsearchjp2EA i第1回 データ構造と情報検索と言語処理勉強会に参加しました。(Jugemより移植)2BA l第1回ElasticSearch勉強会を開催しました！ #elasticsearchjp2A ^第1章の00から02までやってみた（言語処理100本ノック）2~A ^第1章の03から04までやってみた（言語処理100本ノック）2OA ]第1章の03から06まで(言語処理100本ノック2020)2}A ^第1章の05から06までやってみた（言語処理100本ノック）2IA ]第1章の08から09まで(言語処理100本ノック2020)2bA l第2.1回 Twitter API 勉強会 @東京に参加しました。(Jugemより移植)2yA \第25回Elasticsearch勉強会を開催しました。2eA h第2回 データ構造と情報検索と言語処理勉強会に参加しました(Jugemより移植)2yA l第2回elasticsearch勉強会を開催しました！ #elasticsearchjp2HA ]第2章の10から11まで(言語処理100本ノック2020)2GA ]第2章の12から19まで(言語処理100本ノック2020)2kA l第3回elasticsearch勉強会を開催しました！ #elasticsearchjp2xA V第3章終了(言語処理100本ノック2020)2WA |第4回 Twitter API勉強会 @デジタルハリウッド #twtr_hack に参加しました。(Jugemより移植)2`A k第4回Elasticsearch勉強会を開催しました。#elasticsearchjp2wA V第4章終了(言語処理100本ノック2020)2QA l第5回 Twitter API勉強会 @渋谷 #twtr_hack(Jugemより移植)2TA k第5回Elasticsearch勉強会を開催しました。#elasticsearchjp2MA k第6回Elasticsearch勉強会を開催しました。#elasticsearchjp2{A ]第6回Solr勉強会に参加しました。(Jugemより移植)2HA k第7回Elasticsearch勉強会を開催しました。#elasticsearchjp2xA k第8回Elasticsearch勉強会を開催しました。#elasticsearchjp2nA k第9回Elasticsearch勉強会を開催しました。#elasticsearchjp2lA d第9回Solr勉強会を主催しました。#SolrJP(Jugemより移植)2jA q第一回 JetBrainsユーザーグループ #jbugj に参加してきました(Jugemより移植)2TAm自宅の作業環境(2020)2uA P自宅の作業環境(2020/09)2fA P自宅の作業環境(2021/02)2@A [複数辞書の読み込み機能追加（仮）(Jugemより移植)2VA ^親子で楽しめる 絵本で英語をはじめる本(Jugemより移植)2PAn言語処理100本ノック、再び2@A W言語処理100本ノックはじめました(Rust)2UAf転職しました2PA X辞書とカスタム辞書について(Jugemより移植)2AA Z辞書のjarファイルからの分離(Jugemより移植)2oA b辞書の外部化とLucene/Solr3.4対応(Jugemより移植)2LAm辞書の更新についての注意点2A ]辞書分離のテストケース追加と残タスク(Jugemより移植)2VAf退職しました2mAe退職します>xdtypefstringvgsummary3vddocs<ya1\ya2Qya3rya4Eya5Tya6Jya7eya8pya9]yb10{yb11zyb12ryb13Myb14Nyb15Fyb16iyb17Fyb18Ryb19_yb20~yb21Gyb22Iyb23tyb24yyb25Tyb26Oyb27nyb28~yb29Lyb30Gyb31Kyb32Hyb33zyb34Qyb35jyb36[yb37}yb38Cyb39|yb40jyb41Eyb42kyb43Yyb44Syb45Lyb46Zyb47yyb48\yb49]yb50Byb51myb52oyb53Dyb54Iyb55Nyb56Myb57Iyb58nyb59Cyb60|yb61syb62yyb63zyb64{yb65}yb66~yb67}yb68yb69Wyb70yb71Lyb72oyb73Kyb74Eyb75oyb76fyb77Pyb78@yb79Jyb80Ayb81Ayb82jyb83Byb84Ayb85Cyb86hyb87Eyb88Hyb89vyb90iyb91wyb92lyb93cyb94myb95eyb96Ryb97Oyb98lyb99byc100ayc101Byc102Cyc103ryc104Ryc105qyc106Ryc107|yc108syc109hyc110uyc111Kyc112@yc113tyc114Zyc115Vyc116Iyc117Pyc118Jyc119Iyc120Pyc121nyc122uyc123xyc124Zyc125Pyc126Oyc127Wyc128Tyc129wyc130byc131Fyc132~yc133Hyc134Xyc135uyc136vyc137Dyc138}yc139Myc140yyc141Wyc142vyc143uyc144xyc145`yc146Gyc147Tyc148yyc149tyc150iyc151fyc152Vyc153_yc154ayc155dyc156Xyc157Zyc158Wyc159gyc160syc161Uyc162Tyc163kyc164hyc165Yyc166pyc167fyc168`yc169Syc170ryc171cyc172]yc173Ryc174Ayc175Qyc176Tyc177Pyc178{yc179jyc180qyc181^yc182_yc183jyc184@yc185eyc186]yc187Jyc188Eyc189syc190byc191^yc192Qyc193Eyc194\yc195`yc196^yc197\yc198xyc199eyc200yc201[yc202zyc203Nyc204[yc205~yc206kyc207Syc208Wyc209Dyc210Iyc211Fyc212}yc213Pyc214Lyc215Oyc216Kyc217[yc218Qyc219Nyc220Syc221xyc222Xyc223hyc224|yc225Wyc226gyc227Yyc228Xyc229cyc230Yyc231yc232Qyc233{yc234Uyc235@yc236~yc237Zyc238eyc239vyc240Ryc241cyc242ayc243_yc244Vyc245Syc246Qyc247Gyc248Jyc249yyc250Dyc251gyc252Qyc253kyc254oyc255Vyc256Hyc257vyc258Uyc259wyc260Pyc261\yc262Ayc263nyc264]yc265^yc266eyc267Ryc268Uyc269Dyc270Fyc271uyc272myc273dyc274zyc275wyc276Cyc277xyc278Vyc279qyc280`yc281tyc282dyc283dyc284pyc285zyc286Dyc287^yc288Hyc289Vyc290tyc291Xyc292Oyc293kyc294hyc295Syc296gyc297vyc298fyc299[yc300Byc301uyc302Yyc303oyc304Byc305Jyc306Fyc307iyc308Nyc309Zyc310@yc311wyc312hyc313[yc314ayc315Vyc316_yc317syc318yc319pyc320fyc321ryc322Pyc323dyc324Cyc325qyc326`yc327\yc328gyc329myc330ayc331[yc332byc333dyc334iyc335syc336Myc337Yyc338Yyc339iyc340lyc341Byc342Gyc343]yc344qyc345fyc346Xyc347byc348Myc349]yc350lyc351lyc352ayc353^yc354Xyc355oyc356gyc357Oyc358_yc359Uyc360\yc361pyc362|yc363Wyc364tyc365Ayc366nyc367}yc368cyc369cyc370Hyc371pyc372xyc373Myc374Gyc375Zyc376Lyc377Tyc378Lyc379Uyc380Kyc381Nyc382qyc383|yc384jyc385^yc386@yc387{yc388byc389nyc390`yc391Uyc392kyc393Syc394Ryc395_yc396myc397wyc398lyc399ryc400Kyc401yc402myc403{>wkorderedDocs<w2ypxAxp!G（転職する少し前までパスポートすら持ってなかったのに）今の会社に転職してから、半年に1度の割合で海外への出張が発生する生活を送っています。 42@A!H「【東京】JJUG ナイト・セミナー「機械学習・自然言語処理特集！」12/17（水）開催」でLuceneの話をしてきました。 本当にごく簡単な入2JA!F「Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会(第5回）」に参加しました。300名入るイベントルー2\A!I「アジャイルデータサイエンス」の見本をいただいてしまいました。 なので、感想文でも書いてみようかと。 どんな本？ 想像以上に薄かったです、物理的に2UA!H「機械学習による検索ランキング改善ガイド」を読みました。 著者の鈴木さんより献本いただいたのを読み終わったのでレビューと、あとおまけです。 紹介2{A!I「第6回Solr勉強会」に参加しました。 なんだかんだと第6回で、今のところ皆勤賞です。 ということで、主に自分用ですが、メモなどとったので。 概2{A!H「鉄は熱いうちに打て」ということで、残りも勢いでメモ。 まだ、見直しとかしてない状態なのでおかしいところとかありますが。。。 図とか入れるのはま2A!G「鉄は熱いうちに打て」ということで、言語処理100本ノックの第1章の00から02を実装してみました。 さて、これが効率がいいのかどうかはさてお2bA!H@yusukeyさんにサインをもらう目的で勉強会に参加してきました。前回もらいそびれたのでｗ 残念ながら、まだTwitter APIを触ってない2nA!U##Lucene/Solr 4.0.0リリース ついに、Lucene/Solr4.0.0がリリースされました。 MLで流れていましたが、3年越しのリリースだったようです。2|A!P#MANABIYA のブースでセッション時間の合間はお客さん少ないので、ブログを書いてみたり。 ここ数年、スポンサーとして色々なカンファレンスに参加してるんです2LA!\※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.0.beta1 released 本日、Lucene 4.10.1をベースにした、Elast2EA!^※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.1 and 1.3.6 released 本日、Lucene 4.10.2をベースにしたElas2zA!^※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElas2A!^※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElas2vA!^※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.4 and 1.3.9 released 本日（2/20）、Elasticsearch 1.4.2qA!V※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.0 Released 本日（3/23）、Lucene 4.10.4ベースのEla2oA!V※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.1 Released 本日（4/9）、Lucene 4.10.4ベースのElas2mA!V※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.5.2 Released 本日（4/27）、Lucene 4.10.4ベースのEla2iA!V※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.6.0 released 本日（6/9）、Lucene 4.10.4ベースのElas2bA!^※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.0 and 1.6.1 released 本日（7/16）、Lucene 4.10.4ベースのE2aA!^※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.1 and 1.6.2 released 本日（7/29）、Lucene 4.10.4ベースのE2XA!e※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0 GA released Elasticsearch 1.0.0のリリース以降、 477のコミッター2,792^A!\※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0-beta1 released 本日（8/26）、Lucene 5.2.1ベースのElas2\A!\※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0-beta2 released 本日（9/17）、Lucene 5.2.1ベースのElas2eA!k※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 2.0.0.beta1 coming soon! Elasticsearch 2.0.0.beta1のリリースの準備をしています。2]A!h※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch unplugged - Networking changes in 2.0 Elasticsearchをローカルのマシンで起2IA!Y※この記事は次のブログを翻訳したものになります。 原文：elasticsearch-1.4.0 and 1.3.5 released 本日、Lucene 4.10.2をベースにし2BA!x※この記事は次のブログを翻訳したものになります。 原文：exciting logstash plugin ecosystem changes Logstash 1.5.0 Beta 1(お試しはこちら)のリリースで、 プラグインのインストー2lA!k※この記事は次のブログを翻訳したものになります。 原文：Join the Conversation: Discuss.Elastic.Co 3つのOSSプロジェクトの開発をスケールアップし始め、 コミュニティサポー2uA!Z※この記事は次のブログを翻訳したものになります。 原文：kibana 4. literally. Kibana 4は現在、文字通り、抽象的に、概念的に、精神的に、そしてとても楽しく2YA"@※この記事は次のブログを翻訳したものになります。 原文：Kibana 4.2.0 released Elasticsearch 2.0 + Kibana 4.2 = 💚 Elasticsearch 2.0サポートのKibanaの最初のリリースです。 これ2CA!h※この記事は次のブログを翻訳したものになります。 原文：logstash 1.5.0.beta1 released Logstash 1.5.0 Beta1をリリースしました。こちらのページからダウンロードで2ZA!^※この記事は次のブログを翻訳したものになります。 原文：Logstash 2.0.0 released Logstash 2.0.0が本日（10/28）リリースされました。 このリリースは2~A!\※この記事は次のブログを翻訳したものになります。 原文：marvel 1.3.0 released 12/17に、Elasticsearch Marvel 1.3.0をリリースしました2kA!m※この記事は次のブログを翻訳したものになります。 原文：Reindex Elasticsearch With Logstash Thanks David! マッピングを変更したり、インデックスの設定を変更したり、あるサ2[A!O※この記事は次のブログを翻訳したものになります。 原文：Relase, we have ※画像に関しては原文をご覧ください。 Elasticにとって大きな1日2yA!l※この記事は次のブログを翻訳したものになります。 原文：running groovy scripts without dynamic scripting Elasticsearch1.3.8と1.4.3のリリースによ2WA!h※この記事は次のブログを翻訳したものになります。 原文：Shield, Watcher, and Marvel 2.0.0 GA Released 本日（10/28）Shield、WatcherおよびMarv2_A!d※この記事は次のブログを翻訳したものになります。 原文：The Delete by Query API Is now a plugin Elasticsearchの2.0.0-beta1では、これまで2dA!`※この記事は次のブログを翻訳したものになります。 原文：The Great Mapping Refactoring Elasticsearchのユーザの悩みの最も大きなものの一つは、 タイプと2VA!p※この記事は次のブログを翻訳したものになります。 原文：The Story of Sense - Announcing Sense 2.0.0-beta1 誕生 よくある良いプロジェクト同様、Senseもビールを飲みながら考2sA!j※この記事は次のブログを翻訳したものになります。 原文：you know, for security: shield goes ga 1/27にShield 1.0 をリリースしました。 Elasticsearc2eA!G1/18（金）に開催された、エンジニアサポートCROSS 2013で「検索CROSS」セッションのセッションオーナー（モデレータ）をやって来ま2bA!G12月に退職しますブログを書きましたが、その後どうなったのか?という話をしてないなと思ったので、一応現在の状況を書き留めておこううかと。 結論2sA!^2020/10/06 11:00くらいにマージされました。 @minoru_osuka さんが開発を引き継いだLinderaというKuromojiのRustクローンがあります(リポジトリ)2[A!G2021年もあと少しですが、今年買って良かったものをリストアップしておこうかと思います。 今年買ったといいながら、昨年このネタを書くといいつつ2KA!H2月のElastic社のブログですが、Enterprise Searchとこれまで呼んでいた製品をWorkplace Searchという製品名に2fA!W4ヶ月前に、Found joined our team at Elasticをアナウンスしました。 Foundの素晴らしいチームと一緒に仕事をしていますが、彼らによって、より2tA!L4月13日から3日間、ElasticsearchのCoreトレーニングが東京で開催されます。 Early Birdということで、3/14までに申し込みす2gA!G5年くらい、Octopressを使用していましたが、更新されなくなっているのと、コンテンツの生成に時間がかかることもあり、 ほかのプラットフォ2}A!O6月7日の週に開催されたBerlin Buzzwordsにオンライン出張してました。 Berlin Buzzwordsとは? ベルリンで開催されている、Big2WA!G7.16で正式リリースされましたが、Elasticsearchの新しいJavaのクライアントが出ています。 使ってみたので、ちょっとだけ紹介で2zA!I7/25にJJUGナイトセミナーでElastic Stackの紹介とAPMのJava Agentの紹介をしたので、補足のブログです。 （久々に書く2iA!_Atlassian Advent Calendar 2012の20日目。（急遽参戦） （某イケメンにMT（改変リツイート）されたので書いてみました） 久々に、勉強会以外のエントリです。（So2SA!VAWS Summit Tokyo 2013に行って来ました。 @cocoatomoさんに行き掛けに出会ったので、アンデルセンの講演を一緒に聞いてました。 TDブースの@ry2UA!KAWS Summitに来ていたのですが、TLでは、Cloudera Searchが賑わってました。 ということで、軽くどんなものか読んだり調べたりした2XA!VAzure Cognitive Searchで2月に新しい機能が公開されました。 「Index Alias」（インデックスの別名）です。まだ、パブリックプレビューの段階です2aA!WAzure Cognitive Searchで新機能「Semantic Search（セマンティック検索）」という機能の日本語対応が発表されました。 実際にはPublic P2@A!TAzure Cognitive Searchで日本語を扱うときに、形態素解析器を使いたい場合、2種類のAnalyzerが用意されています。今回はこれらの違いがどんなもの2gA!UAzure Cognitive SearchにSuggestやAutocompleteの機能があるのを見つけたので、どんな挙動なのかを調べてログとして残しておきます。 公2eA!UAzure Cognitive SearchにはOData式という書式で条件が書ける仕組みがあります。 ODataは検索条件（$filter）やソート条件（$orderb2\A!UAzure Cognitive Searchのスキーマの確認をするときに、Azureのポータルでは次のようにフィールドの一覧として見ることができます。 ただ、実際のインデ2gA!HBerlinからおはようございます。 ということで、人生で初めての海外に来ています。 人生初の海外なのに、一人で乗り換えがあるようなBerlin2pA#FBonfire Data &amp; Science #1にブログ枠で参加してきました。 ということで、メモです。 日時 : 2019/10/25 19:00 - 21:30 場所 : Yahoo! Japan サイト : https://yj-meetup.connpass.com/event/148121/ ハッシュタグ: #yjbonfire 概要 Data &amp; Scienceと2mA!HBookscanというサービスがあります。 書籍を電子化（PDF）して原本を破棄してくれるサービスです。 電子書籍にはずっと興味を持っていました2UA!XClean Coder プロフェッショナルプログラマへの道 Clean Coderを読みました。 理由はTwitterで「Clean Code」がいい本だと流れてきたためです。2TA!PCloudera Searchは次のようなモジュールから構成されています。 これはCloudera Searchのモジュールで、さらにこれらがSolrとかを使っ2zA!ZCloudera World Tokyo 2013に参加してきました。 午前中はあいにくの雨でしたが、それでも結構な人数が最初の基調講演から参加されてました。 私が参加したセッショ2iA!QCorne使ってましたが、数字キーがあるとどうなのかな？というのがやはり気になって。 そこに、Kochi KeyboardさんからSofle Keyboard v2SA!GCuratorの1.2.0がリリースされました。 前回のCuratorの記事が古くなってしまった（1.1.0からコマンドのI/Fが変更された）2^A"WDomain-Specific Pretraining for Vertical Search: Case Study on Biomedical Literatureという論文を読んだので軽くメモを残しておきます。論文自体はリンクから参照してください。 読んだ理由 Azure Cognitive S2EA!pElastic stack (Elasticsearch) Advent Calendar 2017の1日目の記事になります。 まだ、1ヶ月を残していますが、簡単に今年起こったことを振り返ってみようかと思います。思った以上に2wA!qElastic stack (Elasticsearch) Advent Calendar 2018の1日目の記事になります。 ちょっと遅れちゃいました。。。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみよ2vA!rElastic stack (Elasticsearch) Advent Calendar 2018の25日目の記事になります。 今年最後のAdvent Calendarです！来年も忘れてなければやるはず！ 今日は、すでにalp2oA!pElastic stack (Elasticsearch) Advent Calendar 2019の1日目の記事になります。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみようと思います。毎年恒例ですね、2mA!~Elastic stack (Elasticsearch) Advent Calendar 2020の18日目の記事になります。 本日の勉強会でLTをしましたが、しゃべり足りなかったんで。 Elasticsearch 7.8でこっそりとリリースされたI2KA!oElastic stack Advent Calendar 1日目の記事になります。 Elasticsearch 5.0が10月末にリリースされました。 リリースのブログでいくつか紹介されているのですが、そこでは紹介されて2KA!TElasticsearch 1.4.0.Beta1がリリースされました。 個人でelasticsearch-extended-analyzeというプラグインを開発してま2WA!_Elasticsearch server 2nd editionが発売されています。 私が翻訳したのは前のバージョンですが。。。 まずは、目次を元にどのくらい変わってるかを見てみました。 （2MA!HElasticsearchで日本語を扱うときに、カスタム辞書を使いたいという要望がよくあります。 AWSのElasticsearch Servi2hA!Felasticsearchに、このへん入れるときっと幸せになれるはず・たぶん。&#10;elasticsearch/elasticsearc2pA!GElasticsearchのcuratorのブログ記事を読んで、日本語でツイートしたところ、Aaron Mildensteinさんから日本語（2OA!nElasticsearchのインデキシングに関するパフォーマンス検討 原文：performance considerations for elasticsearch indexing Elasticsearchユーザは様2pA!KElasticsearch勉強会 in 名古屋を開催しました。 初の東京以外での勉強会です。 企画、セッションなどお手伝いいただいた@smogamiさ2BA!IElasticSearch勉強会 第1回を主催しました。 昨年のpyfesでなんちゃって資料で喋って、1年たちました。 ElasticSearch2sA!FElasticsearch勉強会や検索技術勉強会やってるんだけど、独学で勉強会やってるなーと思い、みんなはどうやってるんだろうとツイートして2EA!HElasticのWorkplace Searchを触ってみています(その1、その2)が、Elastic Stackの7.7.0がリリースされてし2ZA!VFluentd meetup in Japanに参加しました。いつも面白そうな話を聞いてばっかりなので、役に立つためにスタッフとしても参加してみました。 まずは、会場が綺麗2fA!QGOTO Night elasticsearchに参加しました。 初の海外の勉強会です（海外自体が初だし）。 ベルリンにあるWoogaという会社で開催された勉強会2wA!`Hadoop Conference Japan 2011 Fallに行ってきました。 まずは、ユーザ会の方々、運営の方々、発表された方々お疲れ様でした。こんな機会を用意していただき、ありがとう2yA!SHadoopからはちょっと離れているのに、面白そうなネタなので参加しました。 Data Science Summit、HBaseCon、Hadoop Summitのイ2hA!HHadoopソースコードリーディング第7回に参加しました。 いつものごとく、自分用のメモをとっていたので。 第6回（2010/12）には参加して2HA!HHadoopとか離れちゃってるし、Hive触ったこと無いにもかかわらず参加しました！ （たまたま近くにいるからって理由なのは内緒で） 玉川さんの2_A!GHerokuではじめるRailsプログラミング入門 heroku気になってるのに使ってなくて、TDのアカウント作ってデータアップしてない軟弱者2SA!FHugoを0.84から0.92にアップデートをする際に、これまでのブログ記事やレイアウトファイルを修正したので個人的にメモを残しておきます。2FA!IIDの秘密 (丸善ライブラリー―情報研シリーズ) 非常に面白く読めました。 バーコードの話に始まり、最後はシステムで付与するIDに関する考慮点まで2zA!LIssue 32で上がってきたlucee-gosenのUniDic対応の最初のパッチを書いたので、ブログに残しておきます。 ###UniDicとは___2LA!TJavaOne Tokyo 2012に参加してきました。 4/4-4/5の2日間開催されていたのですが、子供が体調を崩してしまい、4/5のみの参加となりました。 4/42pA!RJJUG CCC 2011 Fallに参加してきました。 個人的にはかなり久々のJavaのカンファレンスです。（※あくまで「Javaの」という話で。SolrやHad2CA!TJJUG CCC 2012 Springに参加してきました。 昨年のFallに続き、2回目です。 概要や、タイムテーブルはこちらを御覧ください。 今回は、午後一から参加2GA!KJJUG CCCや第7回Elasticsearch勉強会のKibana4のデモにアクセスログを利用しました。 ただ、セッションでは、どうやってElas2gA!WJustTechTalk#02 形態素解析のあれやこれや@ジャストシステム に参加してきました。 ジャストシステムさんの形態素解析器JMATの話とKagome、Janome、2bA!ZJVM Operation Casual Talksに参加しました。 あんまり、運用とかやってないので、ついていけるか不安ですが、楽しそうだったので。 懇親会は予定されてないらしい2_A!Hkopfの記事の続きも書く必要があるんだけど、こんなツイートを見つけてしまったので。。。 ElasticsearchのBulk APIの仕様、J2ZA!RKuromoji-CLI Rust初心者がRust製の日本語形態素解析器の開発を引き継いでみたという記事にありますが、LinderaというRust製の日本語形態素解2RA!HKuromoji-CLIの使い方などについては過去のブログを御覧ください。 KuromojiのCLIコマンドとpicocliとGraalVM G2HA!Hlucene-gosen 1.1.1をリリースしました。 先日お知らせしたバグ修正を取り込んだjarを用意いしました。 ダウンロードはこちらから2NA!Glucene-gosenの1.1.0がリリースされました。 大きな目玉はJapaneseTokenizerが出力する形態素に関するデータを遅延2LA!Jlucene-gosenのtrunkbranches/impl-mecab-dicにNAIST-JDic for MeCabの辞書を利用出来るPre2nA!Hlucene-gosenの最新版（1.2.0）をリリースしました。 プロジェクトページよりダウンロードが可能です。 新規追加機能についてはこちら2cA!Hlucene-gosenの最新版（1.2.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、特定文字列で2A!Hlucene-gosenの最新版（2.0.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、@haruy2EA!Hlucene-gosenの最新版（2.0.1）をリリースしました。 プロジェクトページよりダウンロードが可能です。 今回の修正では、Java7で2OA!Flucene-gosenをSolr/Luceneで利用する場合、TokenFilterを利用してTokenizerが出力したToken対して2OA!Hlucene-gosenを利用して頂いてる皆様に連絡があります。 連絡事項 次期lucene-gosenのリリース（2.0を予定）にて、org.2YA!RLucene/Solr 4.3.0がリリースされた（LuceneのChanges、SolrのChanges）ので、lucene-gosen 4.3.0をリリースしま2OA!SLucene/Solr 4.3.1のRCのVoteが始まっていますが、そのMLできになったコトがあり、ちょっと調べたので メモを残しておきます。 マルチコアの設定ファ2oA!RLucene/Solr 4.6.1がリリースされそう(バイナリ配布待ち)lucene-gosenの4.6.1対応版をリリースしました。 ライブラリのインタフェースな2wA!GLucene/Solrの4.0.0-ALPHAが7/3にリリースされました。 これに伴い、lucene-goenの4xブランチのjarファイル2tA!GLucene/SolrのMLでSolrの管理画面を新しくするというチケットが流れていたのでちょっと触って見ました。 ほんとにちょっと触っただけ2~A!Sluceneutil - マニアックなツールのセットアップの続きです。 今回も誰得?なブログなので興味ない場合は飛ばしましょう。 一応、luceneutilのREAD2A!HLuceneのFSTの修正に関連して、Kuromojiのパフォーマンス問題が出ているようです。 この問題自体はLucene 8.6.0以降で直る2CA!^Mac Book Airのセットアップ関連の備忘録 （今回は備忘録なので、文体も変かも） インストールしたもの（順不同）だいたい、このサイトを参考にした。 Evernote Dropbox2kA!NMacbook Proが新しくなり、OSがCatalinaになっちゃいました。 これまで使ってた、.bash_profileをコピーしてターミナルを立ち上げ2JA"TMerry Christmas! Elastic stack Advent Calendar 2016 最終日の記事になります。 簡単に今年の変遷を振り返ってみます。 Elasticsearch 2.2 (2月) Elasticsearch 2.2.0、2.1.2、1.7.5リリース クエリプロ2DA!rMerry Christmas! Elastic Stack Advent Calendar 2017の24日目の記事になります。 ちょっとですが、2018年のElasticについて書いてみようかと思います。 イベント いくつか2DA!ZMircosoft Buildというイベントが今週ありました(MSの方やお客さんに教えてもらった)。 そこで、Azure Cognitive Searchのセッション(MyBuil2vA"~Modern Information Retrieval: The Concepts and Technology behind Search (2nd Edition) (ACM Press Books) いやぁ、蒸し暑くてなかなか寝れない日がはじまりましたね。（あんまり関係ないですね。。。） Modern Information Retrieval 2nd Editionを2FA!HMorphlinesについてちょっとだけ、さらに調べました。 誤解 Solr勉強会でなんとなく私の認識を話しましたが、ちょっと誤解してたみたいで2pA!GPFIオープンセミナー2012に参加してきました。 対象から微妙に外れてたり、話の内容についていけるか自信がありませんでしたが、参加してきまし2DA!HPlayFramework2.0を触ってみてます。 ちょっとコーディングしたくなったのと、最近のアプリの作成の調査も兼ねて。 まぁ、せっかくなの2QA!GProxy環境で働いている方も結構いると思います。 Twitter上で、Elasticsearchのpluginコマンドでプラグインがインスト2TA!GPySpaアドベントカレンダーの12/08のエントリーです。昨日は渋川さんのアンラーニングで失敗した話でした。 私は、今年は昨年の続きっぽい話2_A!HPySpaアドベントカレンダーの12/15のエントリーです。昨日はtaichiさんでした。 今年はDIYではなく、PCにまつわる話を。 仕事中は2UA!FQuerqyというクエリのリライト用のプラグインがあるのでどんなものかを調べてみました。とりあえずは概要をドキュメントから追いかけてみた感じ2@A!Friver-wikipediaの前々回の記事で書きましたが、bulk_sizeに関連して登録件数がやけにきりが良いのが気になると書いていまし2vA!HRustで便利なクレートを見つけたので、紹介がてら、自分のメモのためにブログに残しておきます。 そもそもの問題 Rustで処理を書いていて、なん2OA!NRustで言語処理100本ノックのリファクタリングの続き。 前回はこちら。 コードも載せたほうが見やすいかなぁ? 03. 円周率 2年前はこちら。 どちらか2IA!kRustで言語処理100本ノックのリファクタリングの続き。 前回はこちら。 とっくに終わってたのに、ブログ書いてなかった。。。 08. 暗号文 pub fn cipher(text: &amp;str) -&gt;2GA!IRustで言語処理100本ノックの第2章の残りです。 前回はこちら。 ちなみに、標準入力から受け取る処理は書いてないです。 出力に関してはファイル2xA!IRustで言語処理100本ノックの第3章です。 前回はこちら。 少し間が空きましたが、再開しました。 間が空いた理由は。。。「正規表現」ですかね。2wA!KRustで言語処理100本ノックの第4章です。 前回はこちら。 今回は早めに続きをやりました。 「形態素解析」ですしね。 第4章の概要 吾輩は猫である2~A!LRustで言語処理100本ノックの続きで、03と04です。 03. 円周率 問題はこちら。 入力文字列を.split_whitespace()で分割して2}A!QRustで言語処理100本ノックの続きで、05と06です。 05. n-gram 問題はこちら。 みんな大好きn-gramです。単語と文字があるので、それぞれ別関2bA!MSofle v2を長らく使っていましたが、コンパクトなのもやっぱりいいよなぁというときにKochi KeyboardからLunakey Miniが発売して2KA!KSolr 4.4に取り込まれる予定のチケットで、気になるものを見つけたのでいつものごとく調べてみました。 元となるチケットはこちら。SOLR-48972IA!USolr/Lucene 3.3がリリースされました。（速報） 以下、各サイトへのリンクです。 Solrリリースのお知らせ Luceneリリースのお知らせ リリースのタイミ2yA!USolr/Lucene 3.4がリリースされました。（速報） 以下、各サイトへのリンクです。 Solrリリースのお知らせ Luceneリリースのお知らせ ちなみに、先日の2LA!GSolrのチケットをML経由で眺めてるんですが、便利そうなチケットが流れてきたのでブログを書いてみみようかと。 元になってるチケットはこちらで2tA!GSolr本が出てから、質問を受けてブログ書くと言いながら書いてなかったことを思い出しました。。。 プラグインの配置方法についてこんな質問を受け2kA!HSolr本の武田さんから教えていただいたSplunkの イベントに行って来ました。 Splunkとは様々な機器のログなどを一箇所に集めてリアルタ2FA!GSwiftypeでサイト内検索？ プレスリリース：Elasticがサイト内検索サービス最大手のSwiftypeを買収が出ましたが、Swifty2RA!HTLで面白いと見かけて、Amazonで買ってしまいました。 SEやってるのに、つい最近Amazonを使い始めた軟弱者です。 それにしてもAmaz2rA!GTwitterで「Meetup.comに切り替えたらー」みたいな話があったので、 受付用アプリとかなくてという話になったので、普段Elasti2KA!HTwitterでこのブログ流れてきて、気になったので、流し読みして簡単にメモ。 Amazonのサービスでスケールする検索サービスみたい。 主に、2GA!JWebSolrの話があるらしいというのを嗅ぎつけて、初めてHeroku JP Meetupに参加しました。 herokuもWebSolrも知りつつ、2YA!HWSL2にUbuntuを入れて、開発とかはこちらを利用しています。 また、Docker DesktopもWSL2のバックエンドエンジンを利用して2IA!GYokozunaの気になる点というか、自分だったらこのへん調べるだろうなって観点を上げてみます。 別に調べるわけじゃないので、完全に自己満足な2|A!HZipkinのGithubにあるReadmeを読んでます。 せっかくというか、頭が悪いので読みながら内容をメモ。 まずは、アーキテクチャとトレー2QA!Hあけましておめでとうございます、johtaniです。 第14回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆2`A!Gあけましておめでとうございます。（もう5日ですが。。。） 今年もlucene-gosenを中心に色々と記事を書いていきますので、ツッコミ、コメ2BA!Gあけましておめでとうございます。今年はサボりがちだったブログをちょっとずつ復活させようかと。 ということで、第1弾として、昨年少し作っていたK2qA!Gあけましておめでとうございます。今年もSolrやElasticsearchについて色々と頑張っていく所存です。 とまぁ、お決まりの挨拶はおいて2ZA!Iアジャイルな時間管理術 ポモドーロテクニック入門 ポモドーロテクニック入門という本を読みました。 きっかけは、Twitter上で何度か「ポモドーロ2WA!Gいくつかある環境をDev Containerで動くように変えていますが、最初に導入した時に疑問点だった「コンテナ名」について解消したのでメモを2jA!Iイケメンが主催した「第一回 JetBrainsユーザーグループ #jbugj」に参加してきました。 いろんな製品があるんだなぁと。入り口には良いイ2dA!HいつものようにSolr勉強会に参加してきました。 皆勤賞を継続中です。（暇人というはなしも。。。） 今回は話しを聞きたいですねぇといったら、いや2fA!Gいまさら感満載ですが、今週の金曜日(1/18)に開催されるCROSS 2013というイベントで「検索CROSS」のセッションを担当することにな2SA!Iえーと、ブログ更新してないなぁとふと思ったので。 １年前くらいからずーっと、つぶやいてましたが、やっとScalaを始めました。 長かった。。。 と2hA!Gオライリー・ジャパンから出ている「コンピュータシステムの理論と実装」を読み始めたのでメモを取ることに。 原著はオライリーじゃないのかというのが2}A!Hお久しぶりです。 気づいたらまた、結構ブログを書いてなかったです。。。 今回は、今開発しているElasticsearchのプラグインに関するお話2^A!Hお久しぶりです。インフルエンザで一家全滅という最悪の状況に陥っていた我が家でした。 流行してるみたいなのでみなさんも気をつけてください。 さて、2^A!\お手伝いしているお客さんがAzure Cognitive Searchを利用してます。 検索周り=Azure Cognitive Searchに関する手伝いをする形で入っており、 いく2EA!Iかなり遅くなりましたが、第1回 データ構造と情報検索と言語処理勉強会 #DSIRNLPに参加しました。 帰ってから２日半ほど寝込んでしまい、更新が2oA!Gこのイベントにウチダスペクトラムの枠でMahoutのコミッターである、Grant Ingersollさんが講演されるということで、興味があった2XA!Hこのブログの生成には、Hugoを利用しています。 ブログ移行日記（その1）に書いてありますが、当時はbrewでインストールしていました。 また、2iA!Hこのブログ書こうと思って、これまでMacのセットアップしてたんだった。。。 普段、macOSの標準ターミナルを使ってます。 で、ターミナルを使う2SA!Xこの記事は、情報検索・検索技術 Advent Calendar 2023の15日目の記事です。 昨年に続き2回目の情報検索のAdvent Calendar参戦です。 今年は、夏2}A!Uこの記事はElasticsearch Advent Calndar 2014の25日目のエントリです。 あっという間に最終日です。来年につなげるという意味で、Elasti2qA!Gこの間のElasticsearch勉強会でAcroquest Technologyの人たちが技術書展7で販売されていた書籍を頂いてしまいました2nA!\これは、情報検索・検索エンジン Advent Calendar 2019 の 4 日目の記事です。 1日目から、質の高いエントリーが続いていましたが、一旦休憩して頂く感じの記事になって2YA!Kこれまで 実践Rust入門はじめました 実践Rust入門の3章を読んでるところ 3章終了 3章の終わりまで読み終えた。 いきなり実践的なプログラムで少2[A!Iこれまでのはこちら。読書メモなので、本と合わせて読んでいただくのが良いです。 実践Rust入門はじめました 3章のクイックツアーを読んでます。 バ2]A!sこんなツイートを見つけたので、Aggregationのサンプルでも書こうかなと。（前から書こうと思ってたんですが。。。） @elasticsearch Hi, Would you please tell me the way to2TA!Hこんにちは、@johtaniです。 早いもので、師走です。今年もあと少しとなりました（今月が一番忙しかったりしますが。。。）。 ということで、A2RA!HざっとインストールガイドとかCloudera Searchのソース眺めて、テキトーにメモを書いてみました。 （ユーザガイドはまだ読んでないです。2rA!Iサンフランシスコからこんにちは。 今、私は、弊社初のユーザカンファレンスelastic{ON}に 参加するために、初のアメリカ出張中です。 初のユ2A!Hすぐにテストケース追加しますといいつつ、はや一週間。 ようやく仕事が落ち着いたので、テストケースを追記しました。まだパッチの段階です。 一応、異2oA!Jすぐやりますと言いつつ、はや1ヶ月。。。 腰が重い、ダメエンジニアですね。。。 すみませんでした。。。 ようやくtrunkにコミットしました。 すぐ2lA!FすずけんさんがVagrant+puppet使って、VM起動してElasticsearchのクラスタを組んでる記事を書いているのを見て、試して2~A!Gすでに読まれた方もいるかも知れませんが、気になったのでメモを書いてみようかと。 先週の木曜日にTwitterのエンジニアブログでZipkinと2BA!Hすみません、また、MBA関連の記事になってしまいました。 ということで、備忘録その２です。 前回からいくつかインストールや環境の設定をしたので、2TA!Gすもけさんが在宅勤務環境をブログに書いてておもしろそうだな(あと、アフィリンク貼れるな)と思ったので自分の環境も書いてみようかなと。 私自身は2eA!Kその他の記事はこちら ブログ移行日記(その1) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) ブログ移行日記(その2)2fA!Lその他の記事はこちら ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) 起因 いつものツイートから2^A!Gだいぶ、ブログを書くペースが落ちてきてて、危機感を感じている今日このごろです。。。 今回は、個人的に利用しているJIRAのバックアップについて2AA!Iたまには、他愛のないブログを。 仕事しながら、コーヒーを飲んでます。 最近は、サムライズムさんのオフィスに入り浸って仕事してます。 オフィスには、2NA!Iちょくちょく書こうと言いながら、前の記事が1週間以上前になってる。。。 昨日は、Basho Japanに遊びに行って来ました。 （Riak触ったこ2vA!Gちょっと興味があるので、訳してみました。（Wikiのページはこちら） 更新されているようなので、もとの文章も残しておきます。（ページ下部の続き2rA!Hちょっと間があいてしまったが、ようやくIoの1日目を終了。 なれない感じの言語なので苦労しました。 今回もセルフスタディの私の回答が最後の方に記2tA!]どーも、johtaniです。 Search Engineering Tech Talkという勉強会に運営として参加して、第1回の勉強会を開始しました。 本日（2/26）は第1回目だったの2xA!Gどーも。以前の記事で開発中としていたプラグインですが、とりあえず、pluginコマンドでインストール出来る形にしてみました。 インストールなど2|A!Gということで、Ruby2日目の感想（2日目だけで2日間かかったのは内緒。。。） 今回もセルフスタディの私の回答が最後の方に記載されてます。見た2zA!Hということで、Rubyの最終日の感想。 今回もセルフスタディの私の回答が最後の方に記載されてます。見たくない人は気をつけてください。 ツッコミ大2\A!~ということで、いつものように勉強会に参加したメモです。 http://atnd.org/events/23608 日時 :2012/01/26 19:00 to 22:00 会場 :アカデミーヒルズ(六本木ヒルズ内) 49階（タワーホールA） （港区六2tA!Gということで、ステッカー欲しさ？に勉強中の話を恥ずかしげもなく偉そうにしゃべってきました。 #pyfesは以前から、気になっていたんですが、タ2eA!Gということで、懲りずに#DSIRNLPに参加してきました。 基礎的な部分をおろそかにしたくないけど、TokyoNLPとかWebMiningでは2UA!Hということで、転職しました。 どーしてもやりたいことが出てきたので、無理を言って転職することにしてみました。 サムライズムではなく、Elasti2ZA!Hどうやら、中身がSolrベース？Luceneベース？になったらしいということで、 今日は「AWSプロダクトシリーズ｜よくわかるAmazon Cl2jA!Gドットファイル系（.emacsとか）をこれまでは、PCを引っ越すたびにコピーしてたんですが、いいかげん、GitHubとかで管理したいなと。 で2uA!Iども。 プラグインのインストールに長いURL入れるの辛いですよね？ね？ ということで、MavenでリリースしてMaven Repositoryから2@A!bども。新しいもの始めないと頭が退化する。。。ということで、こちら（ happy new year and new language - katsyoshiのめもみたいなもの）のブログに触発されて、2gA!Hどんな本でも大量に読める「速読」の本 Twitterで知り合った方がこの本について書かれていたブログ記事を読んで興味を持ち、読みました。 書籍（2aA!Nなんか、とても久しぶりにイベント参加メモ以外の投稿です。 elastic searchのMLを見てたら、KuromojiのAnalyzerを使うときにユーザ2MA!Iなんか、今年はよく物が壊れる、厄年だからかなぁ？ ということで、記念に何が壊れたかをブログに残しておこうかと。 腕時計（壊れてないかな） 電波腕時2dA!Hなんだか、ドタバタしてて久しぶりの更新です。 ベルリンの旅行記みたいなのも書きたいのですが、まずはこちらかと。 elasticsearch-ko2QA!Hはい。またまた、Twitter API勉強会に参加してきました。（今回から開催回数の記載がなくなった？） 今回は直前でタイムテーブルが変わってし2nA!Wはじめまして、pyspa。 ということで、pyspa Advent Calendar 2020の4日目(大谷コンビの2号)の投稿になります。 コンビそろってキーボード記事です2kA!Hヒカリエに行ってみたいという不純な理由で参加してきました。 新しいということもあり、おしゃれで綺麗なカフェでした。 入り口にはおっきな人形も立っ2pA!Gヒゲが不評だったのでいつも通りの長さに切りました。 前回「Windowsをお試し中」と書きましたが、いくつかソフトをインストールしたりしたので2qA!Gヒゲが伸びてきて(試しに伸ばしてる)不評を買っている今日このごろです。 自宅で作業することが多くなってきたので、自作PCでもと思っていますが、2AA!Gひさびさに、lucene-gosenの話題です。 lucene-gosenはjarファイルに辞書も同梱されており、jarファイルをクラスパスに2fA!Iひさびさに、MBAのお話です。 セットアップといっても、物理的な方ですね。 以前、ケース（カバー）について記載しました。 この記事にも書いてあった2hA!aひさびさに、勉強会メモ。 Hatena Engineer Seminar #5 @ Tokyoに当選したので行ってきました。 いつもは近寄らないオシャレな街をドキドキしながら行ってきました。 と2dA!Jブログ移行日記(その3)です。その他の記事はこちら。 ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その4) ブログ移行日記(2cA!Jブログ移行日記(その4)です。その他の記事はこちら。 ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(2]A!Jブログ移行日記(その5)です。前回まではこちら ブログ移行日記(その1) ブログ移行日記(その2) ブログ移行日記(その3) ブログ移行日記(その42[A!Iまだ、Vote公開されていない、Solr 4.3（2013/04/25 11:00現在）ですが、 ひさびさに訳してみた。詳細まで追っていないので、2_A!Hまた、ツイートから始まるお話です。 まだまだ、検索システムってどんなものかを勉強したいしということで、こんなのをツイートしてました。 「検索シス2YA!Hまた、勉強会ログです、すみません。。。 直接業務とは関係ないのですが、今回はリクルートの中野さんが話しをされるというので顔を出してきました。 も2{A!Sまたまた、Riak Meetup Tokyo #3に参加してきました。Riak2.0のYokozunaの話があると聞いたので。 ということで、いつものように個人メモで2xA!Jまたまた参加しました。いまだ皆勤賞です。 感想などはあとで。とりあえず、メモとったので第一弾です。 ということで、感想です。 まずは、参加人数。 今2sA!Gまたまた飲みに行って参加してきました。 今回は、Rails、iOSでのTwitter連携の話から、ツイート分析、クライアントアプリの開発の苦労2cA!Iみなさんは、スライドの作成には何を使っていますか？ Keynote？Powerpoint？Google Slides？ 私は、Macでスライドを作2jA!FメインマシンとMacは下記のサンワサプライのUSB接続のKVMスイッチを使っていますが、もう一台ノートPCがありここに接続しているCorne2\A!dもう2020年2月になってしまってますが、2019年に買って便利だったもの良かったものをいくつか記録に残しとこうかなと。 BRAVIA KJ-55X9500G Amazon | ソニー SONY 492PA!Gもう何番煎じだ？ってくらい書かれてますが、コリもせず書いてみました。 Elasticsearch＋Kibanaの環境を作って、タムタムさんのロ2GA!G不定期開催ですが第11回Solr勉強会を主催しました。 今回も大入り90人くらい？の参加者の皆さんがいらっしゃいました。ありがたいことです！（2~A!G不定期開催ですが第12回Solr勉強会を主催しました。 今回は、前回ほどの過熱ぶりでは無かったですが、70人ほどの参加者の方がいらっしゃったか2sA!I久々に、MBAの備忘録です。 あれから色々入れました。 なので、入れたソフトの一覧を追加。 AIR：TweetDeckをインストールするのに必要だ2XA!H久々にlucene-gosenの話です。 しかも、あんまり嬉しくない話しです。 すでにissueをアップしていますが、lucene-gosenと2AA!G久々にlucene-gosenを触っています。 trunkのlibにある、jarファイルが3.5ベースだったので、3.6ベースにしてテストをし2}A!H久々にSolrの話です。 といっても、結構前からの話でして。。。 schema.xmlのfieldTypeの設定に「autoGeneratePh2bA!H久々にブログ＋イベント参加です。 知り合いが開催＋出演したので参加してみました。 「スマホ」ってキーワードはあまりなかったけど、面白かったです。2GA!G久々に執筆しました。といっても、以前の書籍の更新版です。 まぁ、更新版といっても、私以外の方々は結構な量を書き直しor新規書き起こしされてます2HA!I久々のブログ。 Elasticsearch勉強会を主催してますが、 プロダクトを超えて、検索で共通してある課題とか、悩みとか、あるかなぁと。 その2CA!G久々のブログはElasticSearchネタです。勉強会開催する予定だったりすので、もう少し触っておきたいなと。 お手軽に検索するデータとして2PA!H久々のポスト。。。 久々に、技術書読んでます。「自然言語処理の基本と技術」という本です。 監修の方のツイートを見て気になったので、買ってみました2LA!N久しぶりに、技術的なブログ書いてます。 Ingest Processorのプラグインを作ってみたくなったので、書いてみました。 ただ書いてみるんじゃ3番煎じ2JA!J久しぶりに翻訳ではないブログを。書こうと思いながらかけてなかったので。。。 今回はvalidate APIの紹介です。 背景 Elasticsear2SA!H今さらですが、ブログをはじめてみようかと。今さらですが… はじめてみようと思った一番の理由は、自分で調べたことをメモがわりに残すためです。 あと2jA!H今回は、触ろうと思って触れていないMongoDBの勉強会に行って来ました。 2週連続の渋谷で、さすがに今回は出口をすんなりでれました。 今回は初2CA!Z今回はAzure Cognitive SearchのSDKを利用したアプリケーションが、実際にAzure Cognitive Searchに対して送信しているリクエストのパラメータ2TA!G今回はQuerqyのElasticsearchのプラグインがどんなつくりになっているか？をちょっとだけ調べてみました。 SolrでもElast2QA!G今回はソースのダウンロードとビルドについてです。 最新版のソースを利用したり、JavaDocを見たい場合はソースをダウンロードしてからビルドす2kA!G今回はたまたま日本にいたElasticsearchの人をスペシャルゲストに呼べたので、大満足ですｗ 英語の通訳とかちゃんと勉強しないとなぁ。。2PA!G今回もツイートから。 言語処理100本ノックの2020年版を公開しました。最近の自然言語処理の研究動向を反映し、深層ニューラルネットワークに関2rA!G今年の春くらいから、セパレートタイプのキーボードが気になっています。 また、なんか知らないですが、Twitterのタイムラインが自作キーボード2{A!G今年の頭からシステムの検索周りを手伝う仕事をフリーランスとしてやっています。 検索の仕組みを知れば知るほど面白くなってきたからという理由になる2IA!I今年はRioのプレイバック見ながら書いてます。 今年はなんか長い一年だった気が。 振り返り（2015年に書いた抱負から） まずは去年の抱負を元に2|A!I今年は大晦日になってしまいました。しかも、ちょっと飲んでたり。。。 第9流しながら書いてます。 振り返り(2013年に書いた抱負から) まずは昨年2CA!J今年は紅白を見ながら書いてます。 今年はいろんなところに出張に行ったなぁ。 振り返り（2016年に書いた抱負から） まずは去年の抱負を元に。 もちろ2RA!K今年は紅白見ながら書いてます。 早い一年だったなぁ。 振り返り(2014年に書いた抱負から) まずは去年の抱負を元に振り返りをば。 英語の継続 海外の2`A!I今年もBerlin Buzzwordsにオンライン出張してました。 今年の開催は6月14日から17日まででした。 どんなカンファレンスなのかは昨年2VA!H今年もBerlin Buzzwordsにオンライン出張してました。 今年はハイブリッドな開催だったようで、現地で再開している人もいるようでした。2{A!G今年もCROSS参加しました。そして、話もしてきました。 今年は横浜の大さん橋でした。横浜はあんまりこないので、乗り換えでおたおたしてしまいま2_A!I今年もMICESにも参加してました。 昨年はBerlin Buzzwordsと共同開催でしたが、今年は別開催（別日程）でした。 MICESは2012]A!W今年もアドベントカレンダーの季節になってしまいました。 今年で2回目となる、pyspa Advent Calendar 2021の投稿です。 昨年に引き続きDIYがらみの投稿2]A!N今年もこの季節がやってきました。 Berlin Buzzwordsにオンラインで出張してました。 今年もハイブリッド開催をしてくれたので、オンラインで参加で2^A!H今年もなんとか振り返りブログを書いてます（時間大丈夫かな？w）。紅白をリアタイで見ながら。 振り返り（2021年に書いた抱負から） まずは振り返2ZA!H今年も振り返りブログです。録画した紅白をオッかけ再生して気になるアーティストだけ見ながら書ています。 振り返り（2020年に書いた抱負から） ま2uA!J今年も振り返りブログをかけてます。よかったw 振り返り（2017年に書いた抱負から） まずは去年の抱負を元に。 もっと英語の継続＆TOEIC まぁ、2RA!H今年も振り返りブログをリビングで書いています（ドミノ倒しすごいな）。 FMVのキーボードで書いているのでタイポがつらい。。。 振り返り（20222hA!O今年も振り返りブログ書いてます。Sasukeがついてる。 振り返り（2018年に書いた抱負から） まずは去年の抱負を元に。 TOEIC 受けました。 お。TO2lA!H今年も振り返りブログ書いてます。カタンの航海者版を購入して家族とやってましたが、負けてしまいました。 振り返り（2019年に書いた抱負から） ま2SA!X今年最後のAdvent Calendarとなります。 この記事はElasticsearch Advent Calendar 2015の最終日のエントリです。 簡単に今年の変遷を2jA!G今年初の「突撃！隣のElasticsearch」ということで、Wantedlyさんにおじゃましました。 ※写真を自分でも撮ったのですが、画像が2A!G今日は、ElasticSearchのMLで見つけたelasticsearch-inquisitorプラグインの紹介です。 ElasticSea2aA!H今日はelasticsearch-kopfのAnalysis画面の紹介です。 （簡単なところから。。。その２） メニューのanalysisを選択2^A!H今日はelasticsearch-kopfのAnalysis画面の紹介です。 （簡単なところから。。。その３） ちょっとあいだが開いてしまいまし2cA!H今日はelasticsearch-kopfのREST画面の紹介です。 （簡単なところから。。。） メニューのrestを選択すると、次のような画面2uA!a今日はSolr 4.0 ALPHAの興味深い機能があったので紹介です。 数日前に「Solr 4.0: Partial documents update」という記事を見つけました。 Solrには、2YA!H今月2回目の目黒で、初のドリコムさんです。 「最新インフラエンジニア技術勉強～Fluentd, Elasticsearch,Chefの実践実例～2EA!H今朝起きたら、Xperia Zが故障してしまいました。 電源ボタンを押してもスリープにならないんです。しかも、スリープからの復帰もできない。。。2WA!Q今週も勉強会に参加しました。 @yusukey さんが開催してるTwitter API勉強会です。 前回とは会場が異なりましたが、広くて大画面で良い会場でした。駅2aA!H他の方たちよりひと足はやいですが、今年の仕事が終わりました。 せっかくブログを始めたので、振り返りと来年の抱負など書いてみようかなと。 今年の振2KA!G以前、こちらで話題に上がっていた「未知語」に関するcompositePOSのエラーの件を調査しました。（Twitterでも流れてました。） 次2FA!G以前から春山さんのブログ（リンク）や勉強会で耳にはしていたのですがソースは読んでいませんでした。 先日、Luceneにcontributeされ2JA!H以前より、アナウンスしていた、Kuromojiという日本語形態素解析が含まれるLucene/Solr 3.6.0がリリースされました。 以下、各2DA!H個人用のPCを８年ぶりに新調しました。 前回購入した家のデスクトップPCがもう８年ものになりつつあるということで、 さすがに今年はPCを買おうと2eA!H先日、「ElasticSearch Serverを翻訳しました」という記事を書きました。 この中で電子版も出ますよと書いていましたが、電子版も発2MA!G先日、2.0.0リリースの記事にも記載しましたが、Java7でテストケースが失敗する問題がありました。 @haruyamaさんと@hideak2JA!T先日、Bashoさんにおじゃましたのもあり、Riak Meetup Tokyo #2に参加しました。 Yokozunaの話も聞けるということで。 懇親会も参加しました。2LA!G先日、Elasticsearchでのカスタム辞書の利用方法についてブログを書きました。 辞書の設定方法について記載しましたが、今回は辞書の更新2HA!H先日、Solr入門のサンプルschema.xmlの3.6.0対応版の作成をしていて、気になったことがあったので、 メモとして残しておきます。 S2VA!\先日、Visual Studio Codeのプラグインを作ってみた(Azure Search Analyze Client)というブログを書きました。 このプラグインを作ってたタイミン2NA!R先日、宣言したとおり、lucene-gosenのパッケージ名＋クラス名の変更を行ったlucene-gosen 2.0.0をリリースしました。 Lucene/Solr2@A!G先日、辞書のjarファイルからの分離についてパッチと記事を書きました。 IssueにあげていたパッチをRobertさんが見ていたらしく、次のよ2NA!I先日2014年9月9日(火)に『サーバ/インフラエンジニア養成読本 ログ収集〜可視化編』 出版記念！執筆者が語る大講演会！で、 「elastics2_A!F先日のSolr勉強会でLucene/Solr4.x系のlucene-gosenについて質問を受けていたのを忘れないように（年越しちゃいました2IA!H先日の続きです。「Apache Solr入門」の2章から4章の説明について、Solr3.6.0で動作させる時の変更点を以下に書いていきます。 な2zA!H先日は「システムの特徴と検索機能について」という感じでふんわり書きました。 まぁ、頭の中でぼんやり考えてることを文章にしてみた感じです。 他にも2tA!G先日は「検索システムを構成するパーツ」ということで検索システムを構成しているパーツについて書いてみました。 大体、検索がうまくヒットしないとい2iA!H先週末から勤労感謝の日まで風邪で寝こんでました。。。 みなさん、朝晩、冷え込みが激しいので風邪には気をつけてください。 季節の言葉も入れたので本2WA!G最近、Markdownで文章を書くのに慣れてきました。 ということで、ブログをMarkdownで書けないかなぁと思い、TLの人たちのブログを見2\A!G最近、趣味（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書き始めました。 きちんとPythonのプログラムをプロジェクト2lA!O最近使っていたPCが手元からなくなったので、16インチ Macbook Proをセットアップしているところです。 で、時間もあるのでこれまでほったらかしてきた2lA!I最近忘れやすいので、記録しておこうかと。 読んだスライドの簡単な内容と感想です。 ちなみに、スライドの一覧はこちらです。 ※スライドへのリンクはす2mA!G初目黒（たぶん）で、初Amazonな感じで、流行りの「ビッグデータ」のセミナーに参加してきました。 とりあえず、いつもの自分用のメモを残してお2AA!G前々回紹介した、日本語Wikipediaのデータをインデックス登録する記事の続きです。 今回は、Kuromojiのアナライザを利用してインデッ2MA!G前回、naist-chasenではアルファベットが別々の単語としてanalyzeされてしまうという話をしました。 ただ、これだと、英単語が含ま2FA!G前回の「Logstashを利用したApacheアクセスログのインポート」の続きです。 前回の記事では、Logstashの設定ファイルについて説2oA!L前回のブログのまとめに書いたように、セパレートタイプのキーボードであるCorne Light v2を作成したのでそのビルドログです。DIYキーボードとし2[A!G前回の記事で、pre-commitとPyCharmとWindowsの組み合わせで困っていることを書きました。 これについて、知り合いとチャット2ZA!J前回の記事で、VS Code＋Dev Containerを導入しました。 残課題として「マルチコンテナ化」があるという話もしました。今回はDev C2|A"B前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章2AA"B前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章2BA"B前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章2FA"B前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 Rust the book - 第8章2NA!w前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 Rust the book - 第6章 第8章 7章はパ2QA!j前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 第6章 Enumです。matc2SA!]前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 第5章 構造体です。勝手知ったるなんとやら?2UA!P前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた 第4章 第4章です。たぶん、これがいちばん大事な概念だと思2MA!G前回は3番煎じぐらいでしたが、今回は初記事かな？（だといいな） Kibanaには、前回の記事で書いたものとは別に開発中のKibana3というの2JA!G前回はWorkplace Searchの概要について書きましたが、今回はインストールと構成要素について説明します。なお、2020/5/7時点で2QA!G前回は日本語用オートコンプリートのためのAnalyzerとして、どうやって使うのかを簡単に紹介しました。 今回はもう少し、いろんなパターンを試2wA!I勉強会で宣伝もしましたが、改めて。 Solr入門の改訂版を執筆しました。 考えてみれば、もう3年も前なんですね、Solr入門は。 Solr勉強会な2XA!V動機 Azure Cognitive Searchを検索エンジンに使っているお客さんを手伝っています。 そこで、検索の基本的な話をさせていただきました(もともとJJUGナイ2RA!N原文：Elasticsearch 1.3.1 Releasedを日本語に翻訳したものです。 バグフィックス版のElasticsearch 1.3.1をリリー2qA!H友人にお値打価格で購入したMac miniはMountain Lionにアップデートしてたのですが、手元のAirはまだアップデートしていませんで2XA!X可視化ツール現状確認会に参加して、カジュアルウォーターじゃなくて可視化ツールの現状を確認してきました。 ということで、いつものメモです。 Mackerel と Graphite2xA!G台風15号すごかったですね。幸いにも（？）夏休みだったので、通勤などでひどい目に合わずにすみました。 風雨はすごくてちょっと怖かったですが。。2PA!G子供の寝かしつけしてたら、寝かしつけされてしまって、２時に目が覚めてしまいました。 TSUTAYAでCD借りてきてウォークマンに入れようと思っ2}A!H実に3年ぶりくらいにゆっくりできる日々が訪れたので、積読状態の本を消化しようと「7つの言語 7つの世界」を読み始めました。 せっかくブログも始め2aA!G実践Rust入門という本を買っていた(去年の7月だ。。。)のですが、積んであったので、時間を作って読み始めようかと。 実践Rust入門[言語仕2DA!H宿題その2？かな。Solr勉強会でCloudera Searchのスキーマ周りってどうなってるの？という質問が出てて、 なんか調べることになって2vA!I少し遅くなってしまいましたが、12/05に電子書籍も発売されました。 技術評論社の電子書籍サイトから購入可能です。 書籍のページへのリンク PDF2`A!H年末、何種類かのボードゲームを家族で楽しみました。 家族の感想を交えて簡単に紹介しようかと思います。 家族や知人でボードゲームを購入するときの参2gA!H年末から年始にかけて、「コード・シンプリシティ」を読みました。 先日の記事にも書きましたが、Kindle paperwhiteを思いかけず入手で2YA"D年末までに知り合いと次の論文を読んだので軽くまとめておきます。 Extreme Multi-label Learning for Semantic Matching in Product Search なんで読んだの？ 前回読んだ理由と一緒ですが、Semantic2GA!H忘れてしまうので、備忘録を残しておきます。 一応、ソースには少しずつコメントをいれてはいるのですが。 私は残念ながら、自然言語処理は初心者に毛が2VA!G憧れ？のfluentを使ってみました。 こちらの記事で紹介したZoomdataを最近触っているのですが、お試しにfluentdでデータ流し込む2PA!H懲りずにまた、執筆してみました。みなさん「買って」から感想をいただけるとうれしいです！ 本書について 共著者の方々のブログが詳しいので、そちらを2cA!P技術ブログから離れていってますが。。。 Xperia Zを購入しました。 前に使っていたのはXperia arcになります。 もうすぐ２年だったのですが、容量不2kA!H振り返りブログにも書きましたが、デスクトップPCを自作(DIY)しました。 組み立てたに使ったパーツのアフィリンクを貼っておきます。 10月くら2mA!O改訂新版Solr入門出版記念ということで、第13回Solr勉強会 #SolrJP 新Solr本出版記念を開催しました。 出版記念なので、技術評論社様より、プレ2dA!H新型コロナウィルスの影響もあり、オフラインで集まって勉強会も開催できなくなっています。 検索技術勉強会も、もう1年以上開催できていないです。 ス2QA!H日常でよく、形態素解析したくなることがありますよね？ そして、Slackも日常的に立ち上がってますよね？ ということは、Slackのボットとして2]A!m日時：2012/01/19 18:30-20:30 場所：ベルサール三田Room2シアター Inside MapR デモ＋内部のお話。 ・自己紹介 Susheel Kaushik 元YahooのHadoop系の人。製品2DA!H早いもので、師走です。今年もあと少しとなりました。ということで、Advent Calendarの季節が始まりました。 この記事はElastics2sA!H昨夜、Elasticsearchの0.90.8がリリースされました。 リリースされた内容などについては、本家のブログ「0.90.8 releas2XA!G昨年から、ブログをどうしようかって話をしていて、そのままになっていたのですが、Octopress＋Github Pagesというのがあるらしい2rA!I昨年は、大晦日に書いてました。 ちょっと進歩したかも。 振り返り(2012年に書いた抱負から) ということで、まずは昨年書いた抱負からの振り返りで2[A!H昨年末に今年の抱負について書いたのですが、 他にも興味あるものが増えたので備忘録＆公約？を兼ねてブログに書いておきます。 （興味あるものがあれば2qA!G昨日、文章から特定の単語（リストあり）を探したいという話を聞き、lucene-gosenでもできるねぇという話になりました。 まぁ、考えてみれ2QA!S昨日に引き続き、AWS Summit Tokyo 2013に行ってきました。 @ryu_kobayashiさんからパシリを仰せつかるなどあり、忙しかったのですが楽しか2nA!F昨晩、Elasticsearchから初のプロダクトとなるMarvelがリリースされました。ということで、さっそく触ってみて、簡単な紹介と感想2@A!G昨晩に引き続き、情けない内容のブログになってしまいますが。。。 昨晩、書いた記事の調査をしていた時に気づいた、問題になるケースがあったので調査2hA!I書こうと思いながら、気づいたら大晦日。 よくないですね、思いついた時に書かないと。 昨年も書いたので、昨年書いた抱負から振り返りをと。 Mongo2mA!G本日、Elasticでの最終出社日でした。実際の退職日はまだ先ですが、有休消化という感じです。 思い返せばもう5年と5ヶ月も前ですが、Elas2PA!V本記事は情報検索・検索技術 Advent Calendar 2022の9日目の記事です。 だいぶ間が空いてしまいましたが、日本語のオートコンプリートに関する記事の続きです。2wA!H来る、4月4日の土曜日の午後に名古屋でElasticsearch勉強会を開催予定です。 「初」の東京以外の勉強会です。 Twitterでこのよう2cA!N東京以外での勉強会の第2弾として、関西で勉強会を開催してきました。 Elasticsearch勉強会 in 大阪 Elasticsearch勉強会 in 京2TA!H森ビルに行ったことなかったので、参加してみました。 あと、最近まともにコーディングしてないので、そのへんを矯正するためにもと思って。 （まぁ、遊2RA!J概要： Lucene/SolrのコミッターであるRobert Muirさんが始めたプロジェクト 歴史： MeCabのJava移植版としてスタートした2yA!H毎月開催の2回目になります。 今回は日経さんの会場をお借りしての開催となりました。 前回から、スピーカーの募集をhttp://bit.ly/Sp2HA!I気づいたら1ヶ月サボってました、ごめんなさい。。。 Rustで言語処理100本ノックの第2章をはじめました。 前回はこちら。 確認用のUnixコマ2\A!H現在、RC3のVoteをやっている最中（2013/04/24 16:00時点）で、まだリリースされていない、4.3.0についてです。 開発者ML2~A!G現在の出先でMBAを使えないので、なかなか進んでいないMBAのセットアップです。。。 とりあえず、Eclipse、homebrewをインストー2jA!G第10回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさ2`A!G第11回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ2UA!G第13回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ2OA!G第15回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ2NA!G第16回Elasticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、会場提供していただいたリクルートテクノロジーズ2AA!H第1回では、Analyze UIというプラグインの紹介をしました、ごく簡単にですが。 第2回では、Kibanaのプラグインの作成方法を順を追って2{A!F第2回から少し間が空いてしまいましたが、templateで作成したプラグインのディレクトリ構成とどういう流れでデータがやり取りされるかについ2yA!H第2回を開催しました！ すごい、140人くらいくらいの参加登録者（参加者は１００人ちょっと！）がいて、びっくりです。 ステキな会場を提供していた2]A!J第2回目も参加しました。 とりあえずメモ。 自分には欠けてる視点の話しなので面白かった。 ちょっと寒かったなぁ。 エンジニアのためのスキルアップ勉強2iA!H第3回Elasticsearch勉強会で、軽く触れていましたが、ElasticSearch Server日本語版が発売されます。 ツイートなども2`A!H第4回Elsticsearch勉強会を開催しました。 今回から、遅刻厳禁にしてみました。 それほど困った人もいないと思うので、次回からも遅刻厳禁2TA!H第5回Elasticsearch勉強会を開催しました。 遅くなってしまいましたが、まとめてみました。 今回は、Elasticsearchに入って2MA!G第6回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん2HA!G第7回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん2xA!G第8回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん2nA!G第9回Elsticsearch勉強会を開催しました。 スタッフの皆さん、スピーカーの皆さん、開場提供していただいたリクルートテクノロジーズさん2lA!H第9回Solr勉強会に参加しました。 皆勤賞です！というか、主催者になってしまいました。 まだ不定期の開催になると思いますが、話をされたい方など2fA!G自宅の環境がいろいろと変わったのですが、書いていなかったので更新版です。 前回のブログ(2020/09)、前々回のブログ(2020/03)はそ2uA!G自宅環境に少しアップデートがあったので更新版です。 お客さんのおかげで相変わらず自宅で作業させてもらってるのもあり、昨今のコロナウイルスの影響2WA!N自転車本を読み始めましたが、その前にRust the bookを読んだほうが良いかも?と知り合いと話をしていてなったので、先にRust the bookを読2rA!G興味をもちつつ、触っていない軟弱者ですが、興味があるので今回も話を聞きに行って来ました。 まずは、作者古橋さんによるFluentdの魅力や次期2VA!I親子で楽しめる 絵本で英語をはじめる本 Twitterでこの本について書かれたブログ記事が流れてきて、購入しました。 最近、英語を身につけておいた2`A!H記念すべき！？第10回のSolr勉強会です。 発表者が無事あつまり（本当にありがとうございました！）、今回も盛況な感じでほぼ満員でした。 ツイー2yA!Q負荷を計測するために、数回、Azure Cognitive Searchのクラスターを起動したり、停止したりしてました。 これは、Terraformでやると楽でき2VA!H趣味？（検索エンジンに関する趣味プロジェクト）でPythonのプログラムを書いています。 ベクトル検索などの確認なども含めて、Jupyter N2PA!J辞書の特性について 現在lucene-gosenでは以下の2つの辞書が利用可能です。 簡単に違いについて説明します。 IPAdicの辞書について バ2VA!J退職しました。 色々と書きたいんですが、時差ボケで頭痛いので、このくらいです。 余裕出たら書くかも。 ほしい物リストはこちら 新天地についてはまた明2uA!H遅くなりましたが、続きです。 さらに英語力のなさを痛感して凹んでいるところですが、何かの役に立てばと恥を晒すところです。。。 一応、訳してみたの2[A!G酔っ払ってなんとなく書きたくなったスピリチュアルなブログなので、流していただければと。 最近、勉強会やTwitterで知り合いになって話をする2dA!\金曜日に引き続き、イベントに参加して来ました。（仕事。。。これも仕事だよ。） 「Hadoop Conference Japan 2013 Winter」です。 普段、Hadoopを触る2BA!H録画してたEテレのスーパープレゼンテーションを見ててふと書きたくなったので、書いてます。 あとから読んだら恥ずかしくなりそうだけど。。。 「&l2|A!H開発中ですと書きました、elasticsearch-extended-analyzeですが、改良しました。 改良と変更は以下のとおりです。 ソー2RA!F風のうわさで、日本語用のオートコンプリートのためのTokenFilterとAnalyzerがLuceneに取り込まれたと聞きました（LUCE>xdtypefstringvddate3vddocs<ya1Rya2Qya3Pya4Oya5Nya6Mya7Lya8Kya9Jyb10Iyb11Hyb12Gyb13Fyb14Eyb15Dyb16Cyb17Byb18Ayb19@yb20yb21~yb22}yb23|yb24{yb25zyb26yyb27xyb28wyb29vyb30uyb31tyb32syb33ryb34qyb35pyb36oyb37nyb38myb39lyb40kyb41jyb42iyb43hyb44gyb45fyb46eyb47dyb48cyb49byb50ayb51`yb52_yb53^yb54]yb55\yb56[yb57Zyb58Yyb59Xyb60Wyb61Vyb62Uyb63Tyb64Syb65Ryb66Qyb67Pyb68Oyb69Nyb70Myb71Lyb72Kyb73Jyb74Iyb75Hyb76Gyb77Fyb78Eyb79Dyb80Cyb81Byb82Ayb83@yb84yb85~yb86}yb87|yb88{yb89zyb90yyb91xyb92wyb93vyb94uyb95tyb96syb97ryb98qyb99pyc100oyc101nyc102myc103lyc104kyc105jyc106iyc107hyc108gyc109fyc110eyc111dyc112cyc113byc114ayc115`yc116_yc117^yc118]yc119\yc120[yc121Zyc122Yyc123Xyc124Wyc125Vyc126Uyc127Tyc128Syc129Ryc130Qyc131Pyc132Oyc133Nyc134Myc135Lyc136Kyc137Jyc138Iyc139Hyc140Gyc141Fyc142Eyc143Dyc144Cyc145Byc146Ayc147@yc148yc149~yc150}yc151|yc152{yc153zyc154yyc155xyc156wyc157vyc158uyc159tyc160syc161ryc162qyc163pyc164oyc165nyc166myc167lyc168kyc169jyc170iyc171hyc172gyc173fyc174eyc175dyc176cyc177byc178ayc179`yc180_yc181^yc182]yc183\yc184[yc185Zyc186Yyc187Xyc188Wyc189Vyc190Uyc191Tyc192Syc193Ryc194Qyc195Pyc196Oyc197Nyc198Myc199Lyc200Kyc201Jyc202Iyc203Hyc204Gyc205Fyc206Eyc207Dyc208Cyc209Byc210Ayc211@yc212yc213~yc214}yc215|yc216{yc217zyc218yyc219xyc220wyc221vyc222uyc223tyc224syc225ryc226qyc227pyc228oyc229nyc230myc231lyc232kyc233jyc234iyc235hyc236gyc237fyc238eyc239dyc240cyc241byc242ayc243`yc244_yc245^yc246]yc247\yc248[yc249Zyc250Yyc251Xyc252Wyc253Vyc254Uyc255Tyc256Syc257Ryc258Qyc259Pyc260Oyc261Nyc262Myc263Lyc264Kyc265Jyc266Iyc267Hyc268Gyc269Fyc270Eyc271Dyc272Cyc273Byc274Ayc275@yc276yc277~yc278}yc279|yc280{yc281zyc282yyc283xyc284wyc285vyc286uyc287tyc288syc289ryc290qyc291pyc292oyc293nyc294myc295lyc296kyc297jyc298iyc299hyc300gyc301fyc302eyc303dyc304cyc305byc306ayc307`yc308_yc309^yc310]yc311\yc312[yc313Zyc314Yyc315Xyc316Wyc317Vyc318Uyc319Tyc320Syc321Ryc322Qyc323Pyc324Oyc325Nyc326Myc327Lyc328Kyc329Jyc330Iyc331Hyc332Gyc333Fyc334Eyc335Dyc336Cyc337Byc338Ayc339@yc340yc341~yc342}yc343|yc344{yc345zyc346yyc347xyc348wyc349vyc350uyc351tyc352syc353ryc354qyc355pyc356oyc357nyc358myc359lyc360kyc361jyc362iyc363hyc364gyc365fyc366eyc367dyc368cyc369byc370ayc371`yc372_yc373^yc374]yc375\yc376[yc377Zyc378Yyc379Xyc380Wyc381Vyc382Uyc383Tyc384Syc385Ryc386Qyc387Pyc388_yc389^yc390]yc391\yc392[yc393Zyc394Yyc395Xyc396Wyc397Vyc398Uyc399Tyc400Syc401Ryc402Qyc403P>wkorderedDocs<w2ypS
5p2R
6`2Q
7!
x2P
94@2O
;
T2N
=<P2M
="p2L
?</H2K0`2J3x2I%S2H5X2G97x2F	$-|2E8l2D!x2Cx2B5t2A0h2@8H2%|2~%H2}`2|$"d2{:d2z|2yD2x7>X2w 9t2v 0"|2u"-
+P2t#t2s#),|2r#.;h2q%l2p'#K2o)-?P2n+$h2m,$d2l.
+&x2k."p2j0)1p2i3=`2h4;/t2g5\2f5%\2e87C2d;6l2c<=[2b< 0\2a>4T2`
>I2_+|2^8@2]6H2\C2[a2Z"d2Y)2t2X'\2W&8x2V(p2UH2Tx2S6E2R	`2Q@2P"t2O
+&t2N7H2M`2L*
d2K!.m2J"\2I"$h2H#K2G$=T2F')/K2E*,t2D,4=R2C1 l2B1$P2A3	L2@3#l240b2~56P2}6,\2|6(!\2{649h2z73T2y:	\2x=.P2w=u2v?/9B2uh2t:6T2s+X2r
%p2qH2p
>l2o,|2n="L2m'(d2l,3'`2k-$P2j12h2i4/h2h8l2g;,@2f=L2e>)+l2d?h2c'
l2b/@2a"D2`@2_#{2^`2]'f2\8p2[	h2Z <3K2Y!;5T2X* .|2W+F2V+
;T2U+-L2T+-p2S+0X2R,H2Q,	`2P-X2O-/t2N0
D2M0
t2L2>&@2K55P2J7?l2I7<T2H<*d2G='#d2F>p2E>&x2D>7H2C-h2B8h2A	&D2@
+)x2;D2~!	T2}$
+H2|94`2{$.\2z."d2y P2x!?d2w%
D2v)@2u+<D2t,,|2s,?P2r0p2q7(<p2p8:P2o92h2n:!H2m:7X2l<9|2k=;H2j0 p2i
d2h)6t2g	4t2f
+t2e%T2d
X2c 1@2b'3@2a|2`p2_=T2^
+|2] 
l2\:|2[$/P2Z>x2Y2
X2X#07D2W'*<D2V,T2U,!4h2T2&'p2S55D2R51
X2Q63
+@2P78	h2O+T2N;*l2M1h2Lh2K!@2J!G2I%i2H?8[2G/ o2F;z2E(?T2D=l2C"*V2B#
+h2A#:L2@$?b2$&v2~$(,X2}&;L2|(>f2{2P2z7I2y7u2x8o2w9>}2v9,^2u9,p2t<u2s<7D2r??W2q6 h2p3W2o
+2,w2n	4b2m2p2l,O2k
/Z2jl2i;6F2h ;}2g&:M2f&6>P2e&7|2d'%C2c)0.i2b+3%A2a."i2`.0*a2_5d2^7&h2]7<<J2\></m2[1C2Z"]2Y"s2X#K2W1){2V3
j2U%b2T{2SB2R!
~2Q#2
P2P9+7T2O:"D2N 
[2M2R2L$P2K>V2J(9V2I;F2H	]2G00>f2F
.Y2E
3p2D;H2C
!s2B~2Aq2@!
o2!U2~")(P2},?e2|-$D2{6#i2zz2y1/n2x16o2w!v2vq2u
+e2t=H2s0/n2r (d2q'-]2p,-B2o8(p2n9'!p2m:)r2l=-M2k>
+w2j>J2i
2h,G2g.Y2f	;f2e
+Z2d
+*Y2c;,d2b

C2a
d2`
%f2_k2^
+a2]4"`2\8<n2[".m2Z?C2Y?M2X,?W2W
B2V+5}2U[2T?g2S!N2R"*p2Q#2P#)y2O#.O2N&
+j2M'99P2L)##o2K*<?@2J,7
R2I-4I2H-:`2G.!q2F/
+~2E/.m2D14
+q2C3
W2B37<o2A6I2@74/P2<1u2~=V2})l2|
.*J2{)9V2z93R2y9;W2x%
A2w c2v#>\2u.&u2tf2s(b2r 11f2q!:8R2p#+N2o(,g2n2
+X2m67{2l;t2k;~2j>;,W2i ,&J2h :|2g p2f 
7f2e 3%u2d ~2c -0g2b "-T2a 7W2` 9?'E2_ ;/g2^!"5&\2]!+7p2\!0)
g2[!3	x2Z!30o2Y!7*n2X"!	 Y2W")19V2V"*>_2U"567{2T"5:#j2S";
/b2R"< r2Q"<13Z2P#$ 6]2_#&V2^#,
<\2]$$u2\$*6d2[$+?#k2Z$..z2Y$/!(`2X$/$H2W$0i2V$9'|2U%=H2T%7p2S%1!p2R%$4A2Q%,")M>xdtypefnumbervgenabledtvhisSortedtxhlanguagegenglish
\ No newline at end of file
diff --git a/page/10/index.html b/page/10/index.html
index b053f9d58b..7356725288 100644
--- a/page/10/index.html
+++ b/page/10/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2020/02/23/bicycle-book-chap3/">
+        <h2 class="post-title">
+            実践Rust入門の3章を読んでるところ
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            これまでのはこちら。読書メモなので、本と合わせて読んでいただくのが良いです。 実践Rust入門はじめました 3章のクイックツアーを読んでます。 バ
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2020-02-23  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2020/02/21/best-buy-2019/">
         <h2 class="post-title">
@@ -384,27 +405,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2020/01/23/convert-md-from-octopress-to-hugo/">
-        <h2 class="post-title">
-            ブログ移行日記(その2) - Markdownファイルの変換
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            その他の記事はこちら ブログ移行日記(その1) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) ブログ移行日記(その2)
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2020-01-23  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -598,6 +598,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -989,7 +991,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/11/index.html b/page/11/index.html
index 7aed490729..a989214e3c 100644
--- a/page/11/index.html
+++ b/page/11/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2020/01/23/convert-md-from-octopress-to-hugo/">
+        <h2 class="post-title">
+            ブログ移行日記(その2) - Markdownファイルの変換
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            その他の記事はこちら ブログ移行日記(その1) ブログ移行日記(その3) ブログ移行日記(その4) ブログ移行日記(その5) ブログ移行日記(その2)
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2020-01-23  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2020/01/22/intro-hugo-and-theme/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2019/12/01/whats-happen-at-elastic-in-2019/">
-        <h2 class="post-title">
-            2019年のElastic StackとElastic
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            Elastic stack (Elasticsearch) Advent Calendar 2019の1日目の記事になります。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみようと思います。毎年恒例ですね、
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2019-12-01  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/12/index.html b/page/12/index.html
index f46de7e4db..1e3dc4938a 100644
--- a/page/12/index.html
+++ b/page/12/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2019/12/01/whats-happen-at-elastic-in-2019/">
+        <h2 class="post-title">
+            2019年のElastic StackとElastic
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            Elastic stack (Elasticsearch) Advent Calendar 2019の1日目の記事になります。 まだ、1ヶ月を残してますが、簡単に今年起こったことを振り返ってみようと思います。毎年恒例ですね、
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2019-12-01  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2019/10/25/bonefire-01/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2018/10/17/26th-elasticsearch-tokyo-meetup/">
-        <h2 class="post-title">
-            第25回Elasticsearch勉強会を開催しました。
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            毎月開催の2回目になります。 今回は日経さんの会場をお借りしての開催となりました。 前回から、スピーカーの募集をhttp://bit.ly/Sp
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2018-10-17  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/13/index.html b/page/13/index.html
index e15fd09e72..72a3dae6d2 100644
--- a/page/13/index.html
+++ b/page/13/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2018/10/17/26th-elasticsearch-tokyo-meetup/">
+        <h2 class="post-title">
+            第25回Elasticsearch勉強会を開催しました。
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            毎月開催の2回目になります。 今回は日経さんの会場をお借りしての開催となりました。 前回から、スピーカーの募集をhttp://bit.ly/Sp
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2018-10-17  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2018/07/29/apm-java-at-jjug/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2017/12/31/looking-back-2017/">
-        <h2 class="post-title">
-            今年の振り返りと来年の抱負（2017）
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            今年は紅白を見ながら書いてます。 今年はいろんなところに出張に行ったなぁ。 振り返り（2016年に書いた抱負から） まずは去年の抱負を元に。 もちろ
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2017-12-31  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/14/index.html b/page/14/index.html
index 19e3c312ff..cd9130e6c0 100644
--- a/page/14/index.html
+++ b/page/14/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2017/12/31/looking-back-2017/">
+        <h2 class="post-title">
+            今年の振り返りと来年の抱負（2017）
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            今年は紅白を見ながら書いてます。 今年はいろんなところに出張に行ったなぁ。 振り返り（2016年に書いた抱負から） まずは去年の抱負を元に。 もちろ
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2017-12-31  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2017/12/24/elastic-2018/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2016/06/30/broken-something-in-this-year/">
-        <h2 class="post-title">
-            よく物が壊れる年
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            なんか、今年はよく物が壊れる、厄年だからかなぁ？ ということで、記念に何が壊れたかをブログに残しておこうかと。 腕時計（壊れてないかな） 電波腕時
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2016-06-30  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/15/index.html b/page/15/index.html
index 50f6c76ea7..5e2f18426a 100644
--- a/page/15/index.html
+++ b/page/15/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2016/06/30/broken-something-in-this-year/">
+        <h2 class="post-title">
+            よく物が壊れる年
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            なんか、今年はよく物が壊れる、厄年だからかなぁ？ ということで、記念に何が壊れたかをブログに残しておこうかと。 腕時計（壊れてないかな） 電波腕時
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2016-06-30  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2016/06/28/16th-elasticsearch-meetup/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2015/10/30/shield-watcher-and-marvel-2-0-ga-released-ja/">
-        <h2 class="post-title">
-            Shield、Watcher、Marvel 2.0.0 GAリリース（日本語訳）
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            ※この記事は次のブログを翻訳したものになります。 原文：Shield, Watcher, and Marvel 2.0.0 GA Released 本日（10/28）Shield、WatcherおよびMarv
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2015-10-30  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/16/index.html b/page/16/index.html
index 40c86ed65e..0b8402b027 100644
--- a/page/16/index.html
+++ b/page/16/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2015/10/30/shield-watcher-and-marvel-2-0-ga-released-ja/">
+        <h2 class="post-title">
+            Shield、Watcher、Marvel 2.0.0 GAリリース（日本語訳）
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            ※この記事は次のブログを翻訳したものになります。 原文：Shield, Watcher, and Marvel 2.0.0 GA Released 本日（10/28）Shield、WatcherおよびMarv
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2015-10-30  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2015/10/29/elasticsearch-2-0-0-released-ja/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2015/07/29/elasticsearch-1-7-1-and-1-6-2-released-ja/">
-        <h2 class="post-title">
-            Elasticsearch 1.7.1 および 1.6.2リリース（日本語訳）
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            ※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.1 and 1.6.2 released 本日（7/29）、Lucene 4.10.4ベースのE
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2015-07-29  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/17/index.html b/page/17/index.html
index 4dac159f55..349261fb0d 100644
--- a/page/17/index.html
+++ b/page/17/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2015/07/29/elasticsearch-1-7-1-and-1-6-2-released-ja/">
+        <h2 class="post-title">
+            Elasticsearch 1.7.1 および 1.6.2リリース（日本語訳）
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            ※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.1 and 1.6.2 released 本日（7/29）、Lucene 4.10.4ベースのE
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2015-07-29  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2015/07/22/elasticsearch-1-7-0-and-1-6-1-released-ja/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2015/05/26/reindex-elasticsearch-with-logstash-ja/">
-        <h2 class="post-title">
-            Logstashを使ったElasticsearchの再インデックス（日本語訳）
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            ※この記事は次のブログを翻訳したものになります。 原文：Reindex Elasticsearch With Logstash Thanks David! マッピングを変更したり、インデックスの設定を変更したり、あるサ
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2015-05-26  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/18/index.html b/page/18/index.html
index e7089d6144..8d87c765c4 100644
--- a/page/18/index.html
+++ b/page/18/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2015/05/26/reindex-elasticsearch-with-logstash-ja/">
+        <h2 class="post-title">
+            Logstashを使ったElasticsearchの再インデックス（日本語訳）
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            ※この記事は次のブログを翻訳したものになります。 原文：Reindex Elasticsearch With Logstash Thanks David! マッピングを変更したり、インデックスの設定を変更したり、あるサ
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2015-05-26  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2015/05/21/join-the-conversation-ja/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2015/02/20/kibana-4-literally-ja/">
-        <h2 class="post-title">
-            Kibana 4（日本語訳）
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            ※この記事は次のブログを翻訳したものになります。 原文：kibana 4. literally. Kibana 4は現在、文字通り、抽象的に、概念的に、精神的に、そしてとても楽しく
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2015-02-20  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/19/index.html b/page/19/index.html
index fec1870b2d..0fb834dc34 100644
--- a/page/19/index.html
+++ b/page/19/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2015/02/20/kibana-4-literally-ja/">
+        <h2 class="post-title">
+            Kibana 4（日本語訳）
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            ※この記事は次のブログを翻訳したものになります。 原文：kibana 4. literally. Kibana 4は現在、文字通り、抽象的に、概念的に、精神的に、そしてとても楽しく
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2015-02-20  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2015/02/20/elasticsearch-1-4-4-and-1-3-9-released-ja/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2014/12/18/elasticsearch-1-4-2-released-ja/">
-        <h2 class="post-title">
-            Elasticsearch 1.4.2および1.3.7リリース（日本語訳）
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            ※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElas
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2014-12-18  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/2/index.html b/page/2/index.html
index 01accfa036..147d145286 100644
--- a/page/2/index.html
+++ b/page/2/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2023/07/13/introduce-vs-code-and-dev-container/">
+        <h2 class="post-title">
+            VS CodeとDev Containerの導入（まだ途中）
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            前回の記事で、pre-commitとPyCharmとWindowsの組み合わせで困っていることを書きました。 これについて、知り合いとチャット
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2023-07-13  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2023/07/10/pre-commit-and-python/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2022/07/20/intro-querqy/">
-        <h2 class="post-title">
-            Querqyの調査（その１）
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            Querqyというクエリのリライト用のプラグインがあるのでどんなものかを調べてみました。とりあえずは概要をドキュメントから追いかけてみた感じ
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2022-07-20  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/20/index.html b/page/20/index.html
index ce6774cdc2..c2494fa827 100644
--- a/page/20/index.html
+++ b/page/20/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2014/12/18/elasticsearch-1-4-2-released-ja/">
+        <h2 class="post-title">
+            Elasticsearch 1.4.2および1.3.7リリース（日本語訳）
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            ※この記事は次のブログを翻訳したものになります。 原文：elasticsearch 1.4.3 and 1.3.8 released 本日、Lucene 4.10.3をベースにしたElas
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2014-12-18  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2014/12/17/jjug-night-seminar-dec-2014/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2014/11/06/elasticsearch-1-4-0-ja/">
-        <h2 class="post-title">
-            Elasticsearch 1.4.0および1.3.5リリース（日本語訳）
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            ※この記事は次のブログを翻訳したものになります。 原文：elasticsearch-1.4.0 and 1.3.5 released 本日、Lucene 4.10.2をベースにし
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2014-11-06  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/21/index.html b/page/21/index.html
index 77d5d70c9c..e720b24931 100644
--- a/page/21/index.html
+++ b/page/21/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2014/11/06/elasticsearch-1-4-0-ja/">
+        <h2 class="post-title">
+            Elasticsearch 1.4.0および1.3.5リリース（日本語訳）
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            ※この記事は次のブログを翻訳したものになります。 原文：elasticsearch-1.4.0 and 1.3.5 released 本日、Lucene 4.10.2をベースにし
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2014-11-06  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2014/10/27/how-to-use-validate-api/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2014/07/28/curator-2-0-and-1-1/">
-        <h2 class="post-title">
-            Curator 1.2および1.1について
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            Curatorの1.2.0がリリースされました。 前回のCuratorの記事が古くなってしまった（1.1.0からコマンドのI/Fが変更された）
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2014-07-28  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/22/index.html b/page/22/index.html
index 7d4f62f590..c95e8a7bd8 100644
--- a/page/22/index.html
+++ b/page/22/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2014/07/28/curator-2-0-and-1-1/">
+        <h2 class="post-title">
+            Curator 1.2および1.1について
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            Curatorの1.2.0がリリースされました。 前回のCuratorの記事が古くなってしまった（1.1.0からコマンドのI/Fが変更された）
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2014-07-28  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2014/07/19/hold-on-5th-elasticsearch-jp/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2014/05/07/aggregation-example/">
-        <h2 class="post-title">
-            Aggregations - ファセットよりも柔軟な集計
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            こんなツイートを見つけたので、Aggregationのサンプルでも書こうかなと。（前から書こうと思ってたんですが。。。） @elasticsearch Hi, Would you please tell me the way to
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2014-05-07  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/23/index.html b/page/23/index.html
index 5664c4ad8b..e4a3ca7975 100644
--- a/page/23/index.html
+++ b/page/23/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2014/05/07/aggregation-example/">
+        <h2 class="post-title">
+            Aggregations - ファセットよりも柔軟な集計
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            こんなツイートを見つけたので、Aggregationのサンプルでも書こうかなと。（前から書こうと思ってたんですが。。。） @elasticsearch Hi, Would you please tell me the way to
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2014-05-07  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2014/05/04/intro-elasticsearch-kopf-alias-percolator/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2014/03/16/post-from-berlin/">
-        <h2 class="post-title">
-            Berlinからおはようございます
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            Berlinからおはようございます。 ということで、人生で初めての海外に来ています。 人生初の海外なのに、一人で乗り換えがあるようなBerlin
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2014-03-16  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/24/index.html b/page/24/index.html
index 37f357a97b..d6b3e87a4f 100644
--- a/page/24/index.html
+++ b/page/24/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2014/03/16/post-from-berlin/">
+        <h2 class="post-title">
+            Berlinからおはようございます
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            Berlinからおはようございます。 ということで、人生で初めての海外に来ています。 人生初の海外なのに、一人で乗り換えがあるようなBerlin
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2014-03-16  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2014/03/11/es-plugin-installed-to-my-env/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2014/01/22/release-extended-plugin-for-1-0-0rc1/">
-        <h2 class="post-title">
-            Extended-Analyze 1.0.0RC1をリリースしました
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            あけましておめでとうございます。今年もSolrやElasticsearchについて色々と頑張っていく所存です。 とまぁ、お決まりの挨拶はおいて
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2014-01-22  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/25/index.html b/page/25/index.html
index 9c577fa6f7..161d5e1a32 100644
--- a/page/25/index.html
+++ b/page/25/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2014/01/22/release-extended-plugin-for-1-0-0rc1/">
+        <h2 class="post-title">
+            Extended-Analyze 1.0.0RC1をリリースしました
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            あけましておめでとうございます。今年もSolrやElasticsearchについて色々と頑張っていく所存です。 とまぁ、お決まりの挨拶はおいて
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2014-01-22  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2013/12/30/looking-back-2013/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2013/11/06/riak-meetup-tokyo-no3/">
-        <h2 class="post-title">
-            Riak Meetup #3 #riakjp に参加しました。
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            またまた、Riak Meetup Tokyo #3に参加してきました。Riak2.0のYokozunaの話があると聞いたので。 ということで、いつものように個人メモで
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2013-11-06  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/26/index.html b/page/26/index.html
index a8e4ba048f..0e1281adbd 100644
--- a/page/26/index.html
+++ b/page/26/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2013/11/06/riak-meetup-tokyo-no3/">
+        <h2 class="post-title">
+            Riak Meetup #3 #riakjp に参加しました。
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            またまた、Riak Meetup Tokyo #3に参加してきました。Riak2.0のYokozunaの話があると聞いたので。 ということで、いつものように個人メモで
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2013-11-06  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2013/11/04/improve-output-extended-analyze/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2013/08/01/replace-xperia-z/">
-        <h2 class="post-title">
-            Xperia Zが故障したので交換したのでメモ
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            今朝起きたら、Xperia Zが故障してしまいました。 電源ボタンを押してもスリープにならないんです。しかも、スリープからの復帰もできない。。。
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2013-08-01  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/27/index.html b/page/27/index.html
index 939f332e97..b3de8bbaae 100644
--- a/page/27/index.html
+++ b/page/27/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2013/08/01/replace-xperia-z/">
+        <h2 class="post-title">
+            Xperia Zが故障したので交換したのでメモ
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            今朝起きたら、Xperia Zが故障してしまいました。 電源ボタンを押してもスリープにならないんです。しかも、スリープからの復帰もできない。。。
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2013-08-01  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2013/07/31/introduction-morphlines/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2013/06/11/new-solr-xml/">
-        <h2 class="post-title">
-            新しいsolr.xmlとCore探索ロジック
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            Lucene/Solr 4.3.1のRCのVoteが始まっていますが、そのMLできになったコトがあり、ちょっと調べたので メモを残しておきます。 マルチコアの設定ファ
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2013-06-11  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/28/index.html b/page/28/index.html
index 9f1120f3c1..fdd56b91fa 100644
--- a/page/28/index.html
+++ b/page/28/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2013/06/11/new-solr-xml/">
+        <h2 class="post-title">
+            新しいsolr.xmlとCore探索ロジック
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            Lucene/Solr 4.3.1のRCのVoteが始まっていますが、そのMLできになったコトがあり、ちょっと調べたので メモを残しておきます。 マルチコアの設定ファ
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2013-06-11  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2013/06/10/fluent-es-kibana/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2013/05/06/lucene-gosen4-3-0%E3%82%92%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Flucene-solr4-3-0%E4%BB%A5%E4%B8%8A%E3%81%A7%E3%81%AE%E5%88%A9%E7%94%A8%E3%81%8C%E5%8F%AF%E8%83%BD%E3%81%A7%E3%81%99/">
-        <h2 class="post-title">
-            lucene-gosen4.3.0をリリースしました。（Lucene/Solr4.3.0以上での利用が可能です）(Jugemより移植)
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            Lucene/Solr 4.3.0がリリースされた（LuceneのChanges、SolrのChanges）ので、lucene-gosen 4.3.0をリリースしま
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2013-05-06  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/29/index.html b/page/29/index.html
index f6e2d18bb7..1b7bf13e25 100644
--- a/page/29/index.html
+++ b/page/29/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2013/05/06/lucene-gosen4-3-0%E3%82%92%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%81%97%E3%81%BE%E3%81%97%E3%81%9Flucene-solr4-3-0%E4%BB%A5%E4%B8%8A%E3%81%A7%E3%81%AE%E5%88%A9%E7%94%A8%E3%81%8C%E5%8F%AF%E8%83%BD%E3%81%A7%E3%81%99/">
+        <h2 class="post-title">
+            lucene-gosen4.3.0をリリースしました。（Lucene/Solr4.3.0以上での利用が可能です）(Jugemより移植)
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            Lucene/Solr 4.3.0がリリースされた（LuceneのChanges、SolrのChanges）ので、lucene-gosen 4.3.0をリリースしま
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2013-05-06  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2013/05/03/%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E5%9B%9E%E3%81%97%E3%81%A6%E3%81%BE%E3%81%99%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF%E5%85%A5%E9%96%80%E8%AA%AD%E3%81%BF%E3%81%BE%E3%81%97%E3%81%9F/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2013/02/13/xperia-z%E8%B2%B7%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/">
-        <h2 class="post-title">
-            Xperia Z買いました(Jugemより移植)
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            技術ブログから離れていってますが。。。 Xperia Zを購入しました。 前に使っていたのはXperia arcになります。 もうすぐ２年だったのですが、容量不
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2013-02-13  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/3/index.html b/page/3/index.html
index 3fcb08c156..61f72d9ed2 100644
--- a/page/3/index.html
+++ b/page/3/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2022/07/20/intro-querqy/">
+        <h2 class="post-title">
+            Querqyの調査（その１）
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            Querqyというクエリのリライト用のプラグインがあるのでどんなものかを調べてみました。とりあえずは概要をドキュメントから追いかけてみた感じ
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2022-07-20  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2022/06/15/ttend-berlin-buzzwords-online/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2021/07/13/attend-mices-2021/">
-        <h2 class="post-title">
-            今年もMICESにオンライン出張してた
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            今年もMICESにも参加してました。 昨年はBerlin Buzzwordsと共同開催でしたが、今年は別開催（別日程）でした。 MICESは201
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2021-07-13  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/30/index.html b/page/30/index.html
index 75f37707d0..17755b6448 100644
--- a/page/30/index.html
+++ b/page/30/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2013/02/13/xperia-z%E8%B2%B7%E3%81%84%E3%81%BE%E3%81%97%E3%81%9F/">
+        <h2 class="post-title">
+            Xperia Z買いました(Jugemより移植)
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            技術ブログから離れていってますが。。。 Xperia Zを購入しました。 前に使っていたのはXperia arcになります。 もうすぐ２年だったのですが、容量不
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2013-02-13  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2013/01/22/hadoop-conference-japan-2013-winter%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-hcj13w/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2012/11/10/aws-%E3%83%93%E3%83%83%E3%82%B0%E3%83%87%E3%83%BC%E3%82%BF%E6%B4%BB%E7%94%A8%E4%BA%8B%E4%BE%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-jawsug/">
-        <h2 class="post-title">
-            AWS ビッグデータ活用事例セミナーに参加しました。#jawsug(Jugemより移植)
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            初目黒（たぶん）で、初Amazonな感じで、流行りの「ビッグデータ」のセミナーに参加してきました。 とりあえず、いつもの自分用のメモを残してお
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2012-11-10  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/31/index.html b/page/31/index.html
index ae5ff8f019..83d57e7ad5 100644
--- a/page/31/index.html
+++ b/page/31/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2012/11/10/aws-%E3%83%93%E3%83%83%E3%82%B0%E3%83%87%E3%83%BC%E3%82%BF%E6%B4%BB%E7%94%A8%E4%BA%8B%E4%BE%8B%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-jawsug/">
+        <h2 class="post-title">
+            AWS ビッグデータ活用事例セミナーに参加しました。#jawsug(Jugemより移植)
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            初目黒（たぶん）で、初Amazonな感じで、流行りの「ビッグデータ」のセミナーに参加してきました。 とりあえず、いつもの自分用のメモを残してお
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2012-11-10  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2012/10/12/lucene-solr-4-0-0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9lucene-gosen%E3%81%AE4-0%E5%AF%BE%E5%BF%9C/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2012/07/05/lucene-gosen%E3%81%AElucene-solr4-0-alpha%E5%AF%BE%E5%BF%9C/">
-        <h2 class="post-title">
-            lucene-gosenのLucene/Solr4.0-ALPHA対応(Jugemより移植)
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            Lucene/Solrの4.0.0-ALPHAが7/3にリリースされました。 これに伴い、lucene-goenの4xブランチのjarファイル
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2012-07-05  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/32/index.html b/page/32/index.html
index a826852be3..bf0a4e9df2 100644
--- a/page/32/index.html
+++ b/page/32/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2012/07/05/lucene-gosen%E3%81%AElucene-solr4-0-alpha%E5%AF%BE%E5%BF%9C/">
+        <h2 class="post-title">
+            lucene-gosenのLucene/Solr4.0-ALPHA対応(Jugemより移植)
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            Lucene/Solrの4.0.0-ALPHAが7/3にリリースされました。 これに伴い、lucene-goenの4xブランチのjarファイル
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2012-07-05  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2012/07/04/solr%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC8%E5%9B%9E%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F--solrjp/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2012/06/05/trunk%E3%81%AE%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E5%B7%AE%E3%81%97%E6%9B%BF%E3%81%88lucene-solr3-6-0%E3%81%A8%E3%83%A9%E3%83%B3%E3%83%80%E3%83%A0%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E5%A4%B1%E6%95%97%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/">
-        <h2 class="post-title">
-            trunkのライブラリ差し替え（Lucene/Solr3.6.0）とランダムテストの失敗について(Jugemより移植)
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            久々にlucene-gosenを触っています。 trunkのlibにある、jarファイルが3.5ベースだったので、3.6ベースにしてテストをし
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2012-06-05  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/33/index.html b/page/33/index.html
index 4911bd50d4..1530107cdd 100644
--- a/page/33/index.html
+++ b/page/33/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2012/06/05/trunk%E3%81%AE%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E5%B7%AE%E3%81%97%E6%9B%BF%E3%81%88lucene-solr3-6-0%E3%81%A8%E3%83%A9%E3%83%B3%E3%83%80%E3%83%A0%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E5%A4%B1%E6%95%97%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/">
+        <h2 class="post-title">
+            trunkのライブラリ差し替え（Lucene/Solr3.6.0）とランダムテストの失敗について(Jugemより移植)
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            久々にlucene-gosenを触っています。 trunkのlibにある、jarファイルが3.5ベースだったので、3.6ベースにしてテストをし
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2012-06-05  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2012/05/31/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%B8%E3%81%AE%E8%B2%A2%E7%8C%AE%E3%81%AE%E3%82%B9%E3%82%B9%E3%83%A1/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2012/04/12/%E3%83%A1%E3%83%A2amazon-cloudsearch%E3%81%8C%E5%87%BA%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F%E3%82%88/">
-        <h2 class="post-title">
-            【メモ】Amazon CloudSearchが出てきましたよ(Jugemより移植)
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            Twitterでこのブログ流れてきて、気になったので、流し読みして簡単にメモ。 Amazonのサービスでスケールする検索サービスみたい。 主に、
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2012-04-12  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/34/index.html b/page/34/index.html
index 7aeb159c55..611d23eb5d 100644
--- a/page/34/index.html
+++ b/page/34/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2012/04/12/%E3%83%A1%E3%83%A2amazon-cloudsearch%E3%81%8C%E5%87%BA%E3%81%A6%E3%81%8D%E3%81%BE%E3%81%97%E3%81%9F%E3%82%88/">
+        <h2 class="post-title">
+            【メモ】Amazon CloudSearchが出てきましたよ(Jugemより移植)
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            Twitterでこのブログ流れてきて、気になったので、流し読みして簡単にメモ。 Amazonのサービスでスケールする検索サービスみたい。 主に、
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2012-04-12  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2012/04/06/java-one-tokyo-2012-%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F-javaonejp/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2012/03/03/clean-coder%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A0/">
-        <h2 class="post-title">
-            Clean Coderを読んだ(Jugemより移植)
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            Clean Coder プロフェッショナルプログラマへの道 Clean Coderを読みました。 理由はTwitterで「Clean Code」がいい本だと流れてきたためです。
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2012-03-03  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/35/index.html b/page/35/index.html
index b5526dd56b..c05ef4221f 100644
--- a/page/35/index.html
+++ b/page/35/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2012/03/03/clean-coder%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A0/">
+        <h2 class="post-title">
+            Clean Coderを読んだ(Jugemより移植)
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            Clean Coder プロフェッショナルプログラマへの道 Clean Coderを読みました。 理由はTwitterで「Clean Code」がいい本だと流れてきたためです。
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2012-03-03  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2012/02/26/%E8%A6%AA%E5%AD%90%E3%81%A7%E6%A5%BD%E3%81%97%E3%82%81%E3%82%8B-%E7%B5%B5%E6%9C%AC%E3%81%A7%E8%8B%B1%E8%AA%9E%E3%82%92%E3%81%AF%E3%81%98%E3%82%81%E3%82%8B%E6%9C%AC/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2012/01/08/lucene-gosen%E3%81%AElucene-solr4-0%E5%AF%BE%E5%BF%9C%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%9B%B4%E6%96%B0/">
-        <h2 class="post-title">
-            lucene-gosenのLucene/Solr4.0対応ブランチ更新(Jugemより移植)
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            先日のSolr勉強会でLucene/Solr4.x系のlucene-gosenについて質問を受けていたのを忘れないように（年越しちゃいました
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2012-01-08  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/36/index.html b/page/36/index.html
index 749d54dfaa..e852b47276 100644
--- a/page/36/index.html
+++ b/page/36/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2012/01/08/lucene-gosen%E3%81%AElucene-solr4-0%E5%AF%BE%E5%BF%9C%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%9B%B4%E6%96%B0/">
+        <h2 class="post-title">
+            lucene-gosenのLucene/Solr4.0対応ブランチ更新(Jugemより移植)
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            先日のSolr勉強会でLucene/Solr4.x系のlucene-gosenについて質問を受けていたのを忘れないように（年越しちゃいました
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2012-01-08  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2012/01/05/%E3%81%82%E3%81%91%E3%81%BE%E3%81%97%E3%81%A6%E3%81%8A%E3%82%81%E3%81%A7%E3%81%A8%E3%81%86%E3%81%94%E3%81%96%E3%81%84%E3%81%BE%E3%81%99%E4%BC%9A%E7%A4%BE%E3%81%AE%E3%83%96%E3%83%AD%E3%82%B0%E6%9B%B4%E6%96%B0/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2011/11/26/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AElucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0%E3%81%8B%E3%82%894%E7%AB%A0/">
-        <h2 class="post-title">
-            「Apache Solr入門」のサンプルのlucene-gosen対応（1章から4章）(Jugemより移植)
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            先週末から勤労感謝の日まで風邪で寝こんでました。。。 みなさん、朝晩、冷え込みが激しいので風邪には気をつけてください。 季節の言葉も入れたので本
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2011-11-26  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/37/index.html b/page/37/index.html
index 761de6c832..a295111d38 100644
--- a/page/37/index.html
+++ b/page/37/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2011/11/26/apache-solr%E5%85%A5%E9%96%80%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AElucene-gosen%E5%AF%BE%E5%BF%9C1%E7%AB%A0%E3%81%8B%E3%82%894%E7%AB%A0/">
+        <h2 class="post-title">
+            「Apache Solr入門」のサンプルのlucene-gosen対応（1章から4章）(Jugemより移植)
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            先週末から勤労感謝の日まで風邪で寝こんでました。。。 みなさん、朝晩、冷え込みが激しいので風邪には気をつけてください。 季節の言葉も入れたので本
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2011-11-26  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2011/11/16/mongodb%E5%8B%89%E5%BC%B7%E4%BC%9A%E7%AC%AC7%E5%9B%9E%E3%81%AB%E8%A1%8C%E3%81%A3%E3%81%A6%E6%9D%A5%E3%81%BE%E3%81%97%E3%81%9F/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2011/10/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%94/">
-        <h2 class="post-title">
-            MBAセットアップ備忘録その４(Jugemより移植)
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            久々に、MBAの備忘録です。 あれから色々入れました。 なので、入れたソフトの一覧を追加。 AIR：TweetDeckをインストールするのに必要だ
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2011-10-07  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/38/index.html b/page/38/index.html
index 1e24c50dbc..d227efc3ca 100644
--- a/page/38/index.html
+++ b/page/38/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2011/10/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%94/">
+        <h2 class="post-title">
+            MBAセットアップ備忘録その４(Jugemより移植)
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            久々に、MBAの備忘録です。 あれから色々入れました。 なので、入れたソフトの一覧を追加。 AIR：TweetDeckをインストールするのに必要だ
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2011-10-07  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2011/10/05/solr%E3%81%AE%E6%96%B0%E3%81%97%E3%81%84%E7%AE%A1%E7%90%86%E7%94%BB%E9%9D%A2solr4-x-trunk%E7%B3%BB/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2011/09/09/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-1%E6%97%A5%E7%9B%AE/">
-        <h2 class="post-title">
-            「7つの言語　7つの世界」 Ruby 1日目(Jugemより移植)
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            実に3年ぶりくらいにゆっくりできる日々が訪れたので、積読状態の本を消化しようと「7つの言語 7つの世界」を読み始めました。 せっかくブログも始め
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2011-09-09  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/39/index.html b/page/39/index.html
index b8168f0f45..6ec3a3c705 100644
--- a/page/39/index.html
+++ b/page/39/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2011/09/09/7%E3%81%A4%E3%81%AE%E8%A8%80%E8%AA%9E-7%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C-ruby-1%E6%97%A5%E7%9B%AE/">
+        <h2 class="post-title">
+            「7つの言語　7つの世界」 Ruby 1日目(Jugemより移植)
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            実に3年ぶりくらいにゆっくりできる日々が訪れたので、積読状態の本を消化しようと「7つの言語 7つの世界」を読み始めました。 せっかくブログも始め
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2011-09-09  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2011/09/07/mba%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E5%82%99%E5%BF%98%E9%8C%B2%E3%81%9D%E3%81%AE%EF%BC%93/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2011/07/12/naist-jdic-for-mecab%E3%81%AEpreprocessor%E3%81%AE%E5%AE%9F%E8%A3%85%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E5%82%99%E5%BF%98%E9%8C%B2/">
-        <h2 class="post-title">
-            NAIST-JDic for MeCabのPreprocessorの実装に関する備忘録(Jugemより移植)
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            忘れてしまうので、備忘録を残しておきます。 一応、ソースには少しずつコメントをいれてはいるのですが。 私は残念ながら、自然言語処理は初心者に毛が
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2011-07-12  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/4/index.html b/page/4/index.html
index 2db2054c79..9ddf37948d 100644
--- a/page/4/index.html
+++ b/page/4/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2021/07/13/attend-mices-2021/">
+        <h2 class="post-title">
+            今年もMICESにオンライン出張してた
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            今年もMICESにも参加してました。 昨年はBerlin Buzzwordsと共同開催でしたが、今年は別開催（別日程）でした。 MICESは201
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2021-07-13  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2021/07/09/berlin-buzzwords-2021-1/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2021/02/01/apply-ble-to-sofle/">
-        <h2 class="post-title">
-            Sofle v2を組み立てて、BLE&#43;LPME-IO化してみた #DIYキーボード
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            Corne使ってましたが、数字キーがあるとどうなのかな？というのがやはり気になって。 そこに、Kochi KeyboardさんからSofle Keyboard v
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2021-02-01  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/40/index.html b/page/40/index.html
index 838bddf794..0b76c7cf3a 100644
--- a/page/40/index.html
+++ b/page/40/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2011/07/12/naist-jdic-for-mecab%E3%81%AEpreprocessor%E3%81%AE%E5%AE%9F%E8%A3%85%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E5%82%99%E5%BF%98%E9%8C%B2/">
+        <h2 class="post-title">
+            NAIST-JDic for MeCabのPreprocessorの実装に関する備忘録(Jugemより移植)
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            忘れてしまうので、備忘録を残しておきます。 一応、ソースには少しずつコメントをいれてはいるのですが。 私は残念ながら、自然言語処理は初心者に毛が
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2011-07-12  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2011/07/04/lucene-gosen-1-1-1%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2011/05/26/%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%8B%E3%82%89%E3%81%AE%E3%83%93%E3%83%AB%E3%83%89%E3%81%A8%E6%A7%8B%E6%88%90/">
-        <h2 class="post-title">
-            ソースからのビルドと構成(Jugemより移植)
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            今回はソースのダウンロードとビルドについてです。 最新版のソースを利用したり、JavaDocを見たい場合はソースをダウンロードしてからビルドす
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2011-05-26  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/41/index.html b/page/41/index.html
index 11dd0448ca..a710fbce82 100644
--- a/page/41/index.html
+++ b/page/41/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2011/05/26/%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%8B%E3%82%89%E3%81%AE%E3%83%93%E3%83%AB%E3%83%89%E3%81%A8%E6%A7%8B%E6%88%90/">
+        <h2 class="post-title">
+            ソースからのビルドと構成(Jugemより移植)
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            今回はソースのダウンロードとビルドについてです。 最新版のソースを利用したり、JavaDocを見たい場合はソースをダウンロードしてからビルドす
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2011-05-26  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2011/05/23/lucene-gosen%E3%81%A8%E3%81%AF/">
         <h2 class="post-title">
@@ -424,6 +445,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -815,7 +838,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/5/index.html b/page/5/index.html
index 29a558b79a..3ed6cee24c 100644
--- a/page/5/index.html
+++ b/page/5/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2021/02/01/apply-ble-to-sofle/">
+        <h2 class="post-title">
+            Sofle v2を組み立てて、BLE&#43;LPME-IO化してみた #DIYキーボード
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            Corne使ってましたが、数字キーがあるとどうなのかな？というのがやはり気になって。 そこに、Kochi KeyboardさんからSofle Keyboard v
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2021-02-01  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2021/01/11/apply-ble-and-lpme-to-corne/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2020/10/05/switch-fst-2-da/">
-        <h2 class="post-title">
-            LinderaのFSTをDoubleArrayTrieに変更した話
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            2020/10/06 11:00くらいにマージされました。 @minoru_osuka さんが開発を引き継いだLinderaというKuromojiのRustクローンがあります(リポジトリ)
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2020-10-05  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/6/index.html b/page/6/index.html
index 86e24fabc6..82c67b948d 100644
--- a/page/6/index.html
+++ b/page/6/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2020/10/05/switch-fst-2-da/">
+        <h2 class="post-title">
+            LinderaのFSTをDoubleArrayTrieに変更した話
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            2020/10/06 11:00くらいにマージされました。 @minoru_osuka さんが開発を引き継いだLinderaというKuromojiのRustクローンがあります(リポジトリ)
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2020-10-05  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2020/09/15/improve-search-no3/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2020/07/06/attend-berlin-buzzwords/">
-        <h2 class="post-title">
-            Berlin Buzzwordsにオンライン出張してた
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            6月7日の週に開催されたBerlin Buzzwordsにオンライン出張してました。 Berlin Buzzwordsとは? ベルリンで開催されている、Big
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2020-07-06  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/7/index.html b/page/7/index.html
index 3916953eca..3575123f4f 100644
--- a/page/7/index.html
+++ b/page/7/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2020/07/06/attend-berlin-buzzwords/">
+        <h2 class="post-title">
+            Berlin Buzzwordsにオンライン出張してた
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            6月7日の週に開催されたBerlin Buzzwordsにオンライン出張してました。 Berlin Buzzwordsとは? ベルリンで開催されている、Big
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2020-07-06  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2020/06/25/analyzer-perf-test-with-luceneutil/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2020/05/12/reboot-nlp100-ch02-12to19/">
-        <h2 class="post-title">
-            第2章の12から19まで(言語処理100本ノック2020)
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            Rustで言語処理100本ノックの第2章の残りです。 前回はこちら。 ちなみに、標準入力から受け取る処理は書いてないです。 出力に関してはファイル
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2020-05-12  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/8/index.html b/page/8/index.html
index 8012d7ae35..4b68516987 100644
--- a/page/8/index.html
+++ b/page/8/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2020/05/12/reboot-nlp100-ch02-12to19/">
+        <h2 class="post-title">
+            第2章の12から19まで(言語処理100本ノック2020)
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            Rustで言語処理100本ノックの第2章の残りです。 前回はこちら。 ちなみに、標準入力から受け取る処理は書いてないです。 出力に関してはファイル
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2020-05-12  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2020/05/08/rebootnlp100-ch02-10to11/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2020/04/07/chap6-rust-the-book/">
-        <h2 class="post-title">
-            Rust the book - 第6章
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 第6章 Enumです。matc
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2020-04-07  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/page/9/index.html b/page/9/index.html
index 87bf428a1d..75357d5877 100644
--- a/page/9/index.html
+++ b/page/9/index.html
@@ -193,6 +193,27 @@ <h1>@johtaniの日記 3rd </h1>
         ">
             
 
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2020/04/07/chap6-rust-the-book/">
+        <h2 class="post-title">
+            Rust the book - 第6章
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            前回の記事はこちら。自分用のメモなので、読みにくいかもです。 Rust the Bookを読み始めた Rust the book - 第4章 Rust the book - 第5章 第6章 Enumです。matc
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2020-04-07  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
 <div class="post-preview">
     <a href="https://blog.johtani.info/blog/2020/04/06/update-kuromoji-cli/">
         <h2 class="post-title">
@@ -382,27 +403,6 @@ <h2 class="post-title">
 </div>
 <hr>
 
-<div class="post-preview">
-    <a href="https://blog.johtani.info/blog/2020/02/23/bicycle-book-chap3/">
-        <h2 class="post-title">
-            実践Rust入門の3章を読んでるところ
-        </h2>
-	
-        <div class="post-content-preview">
-	
-            これまでのはこちら。読書メモなので、本と合わせて読んでいただくのが良いです。 実践Rust入門はじめました 3章のクイックツアーを読んでます。 バ
-       
-        </div>
-    </a>
-    <p class="post-meta">
-    2020-02-23  by johtani
-    
-    
-    </p>
-
-</div>
-<hr>
-
 
             
 
@@ -596,6 +596,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -987,7 +989,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/post/index.html b/post/index.html
index d499932a46..5471b01c4e 100644
--- a/post/index.html
+++ b/post/index.html
@@ -323,6 +323,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                         hadoop
                         </a>
@@ -712,7 +714,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/post/index.xml b/post/index.xml
index bfd0721a53..cda2c9f9f4 100644
--- a/post/index.xml
+++ b/post/index.xml
@@ -7,7 +7,61 @@
     <description>Recent content in Posts on @johtaniの日記 3rd</description>
     <generator>Hugo -- gohugo.io</generator>
     <language>ja</language>
-    <lastBuildDate>Sun, 31 Dec 2023 07:49:21 +0000</lastBuildDate><atom:link href="https://blog.johtani.info/post/index.xml" rel="self" type="application/rss+xml" />
+    <lastBuildDate>Thu, 25 Jan 2024 09:30:53 +0000</lastBuildDate><atom:link href="https://blog.johtani.info/post/index.xml" rel="self" type="application/rss+xml" />
+    <item>
+      <title>kagome-botのユーザーサービス化</title>
+      <link>https://blog.johtani.info/blog/2024/01/25/kagome-bot-as-a-user-service/</link>
+      <pubDate>Thu, 25 Jan 2024 09:30:53 +0000</pubDate>
+      
+      <guid>https://blog.johtani.info/blog/2024/01/25/kagome-bot-as-a-user-service/</guid>
+      <description>日常でよく、形態素解析したくなることがありますよね？ そして、Slackも日常的に立ち上がってますよね？ ということは、Slackのボットとして</description>
+      <content:encoded>&lt;p&gt;日常でよく、形態素解析したくなることがありますよね？
+そして、Slackも日常的に立ち上がってますよね？
+ということは、Slackのボットとして常駐してもらえばできるのでは？&lt;/p&gt;
+&lt;h2 id=&#34;kagome-bot&#34;&gt;kagome-bot&lt;/h2&gt;
+&lt;p&gt;知り合いが&lt;a href=&#34;https://github.com/ikawaha/kagome&#34;&gt;kagome&lt;/a&gt;という形態素解析ライブラリを開発しています。
+その知り合いが、ボットにもしてくれています（複数辞書対応してみたかったので、PR作って取り込んでもらいました）。&lt;/p&gt;
+&lt;ul&gt;
+&lt;li&gt;&lt;a href=&#34;https://github.com/ikawaha/kagome-bot&#34;&gt;https://github.com/ikawaha/kagome-bot&lt;/a&gt;&lt;/li&gt;
+&lt;/ul&gt;
+&lt;p&gt;ただ、デプロイはしてなかったので、我が家にあるUbuntuのサーバーにデプロイして動かすことにしました。
+ボットについては、上記のリポジトリを見てもらえればいいかなと。&lt;/p&gt;
+&lt;p&gt;とりあえず動けばいいや、ということで、適当なshell scriptに&lt;code&gt;nohup&lt;/code&gt;で起動していたのですが、Ubuntuの更新後の再起動で毎回ログインしてスクリプトの実行はめんどくさいな？ということでググって調べてみました。&lt;/p&gt;
+&lt;h2 id=&#34;systemdでユーザーのサービスとして登録&#34;&gt;systemdでユーザーのサービスとして登録&lt;/h2&gt;
+&lt;p&gt;参考ブログにある手順ほぼそのままでした。知見ありがたいです。&lt;/p&gt;
+&lt;p&gt;サービスの登録自体は、指定のディレクトリにファイルを作るのではなく、systemdコマンドをしようしました。&lt;/p&gt;
+&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;$ systemctl --user --force --full edit kagome
+&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;これで、参考ブログにあるように&lt;code&gt;kagome.service&lt;/code&gt;というファイルが&lt;code&gt;~/.config/systemd/user/&lt;/code&gt;ディレクトリに作られます。
+ファイルの内容などはほぼ参考ブログにある通りです。こんなかんじ。&lt;/p&gt;
+&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;[Unit]
+Description=kagome bot
+
+[Service]
+ExecStart=/home/johtani/kagome-bot/start_kagomebot_service.sh
+ExecStop=/bin/kill ${MAINPID}
+Restart=always
+
+[Install]
+WantedBy=default.target
+&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;&lt;code&gt;start_kagomebot_service.sh&lt;/code&gt;の中で、kagome-botコマンドを実行しますが、こちらは絶対パスで記述しておきました。
+サービス起動時のパスは&lt;code&gt;~/&lt;/code&gt;のようなのですが、念のために。&lt;/p&gt;
+&lt;p&gt;あとは、次の手順でサービスを登録して開始します。&lt;/p&gt;
+&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;$ systemctl --user enable kagome
+$ systemctl --user start kagome
+&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;ログを見るのは&lt;code&gt;journalctl&lt;/code&gt;コマンドです。&lt;/p&gt;
+&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;$ journalctl --user -u kagome
+&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;あとは、以下のコマンドを実行しないと、マシン再起動後にログインするまでサービスが起動しないので忘れないようにしましょう。
+（忘れてログインしてみて起動してるじゃん？というコントみたいなことをしてしまいました）。&lt;/p&gt;
+&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;$ sudo loginctl enable-linger username
+&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;参考ブログ本当にありがたいですね。
+備忘録のついでにブログにしておきます。&lt;/p&gt;
+&lt;h2 id=&#34;参考ブログ&#34;&gt;参考ブログ&lt;/h2&gt;
+&lt;ul&gt;
+&lt;li&gt;&lt;a href=&#34;https://pyopyopyo.hatenablog.com/entry/2021/04/30/233755&#34;&gt;ユーザー権限で systemd のサービスを稼働させる方法 - pyopyopyo - Linuxとかプログラミングの覚え書き -&lt;/a&gt;&lt;/li&gt;
+&lt;/ul&gt;
+</content:encoded>
+    </item>
+    
     <item>
       <title>今年の振り返りと来年の抱負（2023）</title>
       <link>https://blog.johtani.info/blog/2023/12/31/review-2023/</link>
diff --git a/search/index.html b/search/index.html
index b88178950e..be96af29dc 100644
--- a/search/index.html
+++ b/search/index.html
@@ -473,7 +473,7 @@ <h3><a class="post-link" href="${url}">${title}</a></h3>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/search/placeholder/index.html b/search/placeholder/index.html
index 811fe4820f..2832f541ab 100644
--- a/search/placeholder/index.html
+++ b/search/placeholder/index.html
@@ -362,6 +362,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -751,7 +753,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/searchkit/index.html b/searchkit/index.html
index 08e22b2d79..c8d1cf01b9 100644
--- a/searchkit/index.html
+++ b/searchkit/index.html
@@ -495,7 +495,7 @@ <h3><a class="post-link" href="${url}">${title}</a></h3>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/searchkit/placeholder/index.html b/searchkit/placeholder/index.html
index 8c1e247165..08f16b8f7d 100644
--- a/searchkit/placeholder/index.html
+++ b/searchkit/placeholder/index.html
@@ -362,6 +362,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -751,7 +753,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/sitemap.xml b/sitemap.xml
index 527f0d697c..5f7003f474 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -3,13 +3,19 @@
   xmlns:xhtml="http://www.w3.org/1999/xhtml">
   <url>
     <loc>https://blog.johtani.info/</loc>
-    <lastmod>2023-12-31T07:49:21+00:00</lastmod>
+    <lastmod>2024-01-25T09:30:53+00:00</lastmod>
+  </url><url>
+    <loc>https://blog.johtani.info/tags/go/</loc>
+    <lastmod>2024-01-25T09:30:53+00:00</lastmod>
+  </url><url>
+    <loc>https://blog.johtani.info/blog/2024/01/25/kagome-bot-as-a-user-service/</loc>
+    <lastmod>2024-01-25T09:30:53+00:00</lastmod>
   </url><url>
     <loc>https://blog.johtani.info/post/</loc>
-    <lastmod>2023-12-31T07:49:21+00:00</lastmod>
+    <lastmod>2024-01-25T09:30:53+00:00</lastmod>
   </url><url>
     <loc>https://blog.johtani.info/tags/</loc>
-    <lastmod>2023-12-31T07:49:21+00:00</lastmod>
+    <lastmod>2024-01-25T09:30:53+00:00</lastmod>
   </url><url>
     <loc>https://blog.johtani.info/blog/2023/12/31/review-2023/</loc>
     <lastmod>2023-12-31T07:49:21+00:00</lastmod>
diff --git a/tags/.net/index.html b/tags/.net/index.html
index cbde5572cb..620e0a19c3 100644
--- a/tags/.net/index.html
+++ b/tags/.net/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/aws/index.html b/tags/aws/index.html
index 10bd38f69e..f54d889e16 100644
--- a/tags/aws/index.html
+++ b/tags/aws/index.html
@@ -435,6 +435,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -826,7 +828,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/azure-search/index.html b/tags/azure-search/index.html
index 511ee9478f..311e3f8249 100644
--- a/tags/azure-search/index.html
+++ b/tags/azure-search/index.html
@@ -591,6 +591,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -982,7 +984,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/azure-search/page/2/index.html b/tags/azure-search/page/2/index.html
index 4ce4209dde..419e786961 100644
--- a/tags/azure-search/page/2/index.html
+++ b/tags/azure-search/page/2/index.html
@@ -402,6 +402,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -793,7 +795,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/basho/index.html b/tags/basho/index.html
index a2d73dbdb7..26cca0e589 100644
--- a/tags/basho/index.html
+++ b/tags/basho/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/belin-buzzwords/index.html b/tags/belin-buzzwords/index.html
index cbe013f753..3296a95a72 100644
--- a/tags/belin-buzzwords/index.html
+++ b/tags/belin-buzzwords/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/berlin-buzzwords/index.html b/tags/berlin-buzzwords/index.html
index ede16fca50..f22ff7b529 100644
--- a/tags/berlin-buzzwords/index.html
+++ b/tags/berlin-buzzwords/index.html
@@ -456,6 +456,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -847,7 +849,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/bot/index.html b/tags/bot/index.html
index 66486158bc..3f5074a1de 100644
--- a/tags/bot/index.html
+++ b/tags/bot/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/cloudera-search/index.html b/tags/cloudera-search/index.html
index 38f9c9d5fe..2143629206 100644
--- a/tags/cloudera-search/index.html
+++ b/tags/cloudera-search/index.html
@@ -498,6 +498,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -889,7 +891,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/cloudera/index.html b/tags/cloudera/index.html
index 4d4ecc1b9e..923617e95c 100644
--- a/tags/cloudera/index.html
+++ b/tags/cloudera/index.html
@@ -456,6 +456,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -847,7 +849,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/cloudsearch/index.html b/tags/cloudsearch/index.html
index ef306f5d23..f098c289a7 100644
--- a/tags/cloudsearch/index.html
+++ b/tags/cloudsearch/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/coffee/index.html b/tags/coffee/index.html
index d7f5b88705..ff9a854632 100644
--- a/tags/coffee/index.html
+++ b/tags/coffee/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/conference/index.html b/tags/conference/index.html
index 7868b1ef48..c0c51bc6ac 100644
--- a/tags/conference/index.html
+++ b/tags/conference/index.html
@@ -477,6 +477,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -868,7 +870,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/curator/index.html b/tags/curator/index.html
index 96f1d67384..de2d763f14 100644
--- a/tags/curator/index.html
+++ b/tags/curator/index.html
@@ -414,6 +414,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -805,7 +807,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/dev-container/index.html b/tags/dev-container/index.html
index 08740cfbea..b76d307f9e 100644
--- a/tags/dev-container/index.html
+++ b/tags/dev-container/index.html
@@ -456,6 +456,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -847,7 +849,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/diy\343\202\255\343\203\274\343\203\234\343\203\274\343\203\211/index.html" "b/tags/diy\343\202\255\343\203\274\343\203\234\343\203\274\343\203\211/index.html"
index ddae5e7f03..b7dee1a066 100644
--- "a/tags/diy\343\202\255\343\203\274\343\203\234\343\203\274\343\203\211/index.html"
+++ "b/tags/diy\343\202\255\343\203\274\343\203\234\343\203\274\343\203\211/index.html"
@@ -519,6 +519,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -910,7 +912,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/elastic-stack/index.html b/tags/elastic-stack/index.html
index c6d7fa40da..f35e920f05 100644
--- a/tags/elastic-stack/index.html
+++ b/tags/elastic-stack/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/elastic/index.html b/tags/elastic/index.html
index 382308e481..68a448da20 100644
--- a/tags/elastic/index.html
+++ b/tags/elastic/index.html
@@ -435,6 +435,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -826,7 +828,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/elasticon/index.html b/tags/elasticon/index.html
index b9fc4f553d..de03b604b0 100644
--- a/tags/elasticon/index.html
+++ b/tags/elasticon/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/elasticsearch/index.html b/tags/elasticsearch/index.html
index 12100a5fb3..2fd5082f61 100644
--- a/tags/elasticsearch/index.html
+++ b/tags/elasticsearch/index.html
@@ -591,6 +591,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -982,7 +984,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/elasticsearch/page/10/index.html b/tags/elasticsearch/page/10/index.html
index 2928e17cbf..05b843af1a 100644
--- a/tags/elasticsearch/page/10/index.html
+++ b/tags/elasticsearch/page/10/index.html
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/elasticsearch/page/11/index.html b/tags/elasticsearch/page/11/index.html
index 2b898b072f..4ba96da11a 100644
--- a/tags/elasticsearch/page/11/index.html
+++ b/tags/elasticsearch/page/11/index.html
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/elasticsearch/page/12/index.html b/tags/elasticsearch/page/12/index.html
index 3aec2a2c48..f67845d586 100644
--- a/tags/elasticsearch/page/12/index.html
+++ b/tags/elasticsearch/page/12/index.html
@@ -465,6 +465,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -856,7 +858,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/elasticsearch/page/2/index.html b/tags/elasticsearch/page/2/index.html
index 001e91b7c6..45012304b6 100644
--- a/tags/elasticsearch/page/2/index.html
+++ b/tags/elasticsearch/page/2/index.html
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/elasticsearch/page/3/index.html b/tags/elasticsearch/page/3/index.html
index a005ca8ad5..8a7b14a8da 100644
--- a/tags/elasticsearch/page/3/index.html
+++ b/tags/elasticsearch/page/3/index.html
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/elasticsearch/page/4/index.html b/tags/elasticsearch/page/4/index.html
index eba1369740..c73c988d73 100644
--- a/tags/elasticsearch/page/4/index.html
+++ b/tags/elasticsearch/page/4/index.html
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/elasticsearch/page/5/index.html b/tags/elasticsearch/page/5/index.html
index 1369079de7..8b5c4b95a5 100644
--- a/tags/elasticsearch/page/5/index.html
+++ b/tags/elasticsearch/page/5/index.html
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/elasticsearch/page/6/index.html b/tags/elasticsearch/page/6/index.html
index 5835e8a28d..59d2ec91ae 100644
--- a/tags/elasticsearch/page/6/index.html
+++ b/tags/elasticsearch/page/6/index.html
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/elasticsearch/page/7/index.html b/tags/elasticsearch/page/7/index.html
index 07e112e762..138f23d3d1 100644
--- a/tags/elasticsearch/page/7/index.html
+++ b/tags/elasticsearch/page/7/index.html
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/elasticsearch/page/8/index.html b/tags/elasticsearch/page/8/index.html
index 8632a42fc4..897db1c039 100644
--- a/tags/elasticsearch/page/8/index.html
+++ b/tags/elasticsearch/page/8/index.html
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/elasticsearch/page/9/index.html b/tags/elasticsearch/page/9/index.html
index 68f617b946..ff9c295a35 100644
--- a/tags/elasticsearch/page/9/index.html
+++ b/tags/elasticsearch/page/9/index.html
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/fluentd/index.html b/tags/fluentd/index.html
index bd322dc50a..34fe939d26 100644
--- a/tags/fluentd/index.html
+++ b/tags/fluentd/index.html
@@ -435,6 +435,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -826,7 +828,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/found.no/index.html b/tags/found.no/index.html
index 9fb5306205..2709dd900f 100644
--- a/tags/found.no/index.html
+++ b/tags/found.no/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/go/index.html b/tags/go/index.html
new file mode 100644
index 0000000000..773fb46624
--- /dev/null
+++ b/tags/go/index.html
@@ -0,0 +1,862 @@
+<!DOCTYPE html>
+<html lang="ja">
+<head>
+    <meta charset="utf-8">
+    <meta http-equiv="X-UA-Compatible" content="IE=edge">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+
+    
+    <meta property="og:site_name" content="@johtaniの日記 3rd">
+    <meta property="og:type" content="article">
+
+    
+    <meta property="og:image" content="https://blog.johtani.info/images/header3.jpg">
+    <meta property="twitter:image" content="https://blog.johtani.info/images/header3.jpg" />
+    
+
+    
+    <meta name="title" content="go" />
+    <meta property="og:title" content="go" />
+    <meta property="twitter:title" content="go" />
+    
+
+    
+    <meta name="description" content="johtaniの日記です。技術とか、他愛のないことを書き連ねていくブログです。 | johtani&#39;s blog site that includes topics, e.g. technical, life, hobby, etc.">
+    <meta property="og:description" content="johtaniの日記です。技術とか、他愛のないことを書き連ねていくブログです。 | johtani&#39;s blog site that includes topics, e.g. technical, life, hobby, etc." />
+    <meta property="twitter:description" content="johtaniの日記です。技術とか、他愛のないことを書き連ねていくブログです。 | johtani&#39;s blog site that includes topics, e.g. technical, life, hobby, etc." />
+    
+
+    
+    <meta property="twitter:card" content="summary" />
+    
+    
+
+    <meta name="keyword"  content="johtani elasticsearch kibana search 検索 ">
+    <link rel="shortcut icon" href="/img/favicon.ico">
+
+    <title>go | @johtaniの日記 3rd | @johtani&#39;s blog 3rd edition </title>
+
+    <link rel="canonical" href="/tags/go/">
+
+    
+    
+    
+    <link rel="stylesheet" href="/css/bootstrap.min.css">
+
+    
+    <link rel="stylesheet" href="/css/hugo-theme-cleanwhite.min.css">
+
+    
+    <link rel="stylesheet" href="/css/zanshang.css">
+
+    
+    <link rel="stylesheet" href="/css/font-awesome.all.min.css">
+
+    
+    <link rel="stylesheet" href="https://blog.johtani.info/css/custom-font.css"><link rel="stylesheet" href="https://blog.johtani.info/css/amazon.css">
+
+    
+    <script src="/js/jquery.min.js"></script>
+
+    
+    <script src="/js/bootstrap.min.js"></script>
+
+    
+    <script src="/js/hux-blog.min.js"></script>
+
+    
+    <script src="/js/lazysizes.min.js"></script>
+
+    
+    
+
+</head>
+
+
+
+<script async src="https://www.googletagmanager.com/gtag/js?id=G-ZCZYDMJX3V"></script>
+<script>
+var doNotTrack = false;
+if (!doNotTrack) {
+	window.dataLayer = window.dataLayer || [];
+	function gtag(){dataLayer.push(arguments);}
+	gtag('js', new Date());
+	gtag('config', 'G-ZCZYDMJX3V', { 'anonymize_ip': false });
+}
+</script>
+
+
+
+
+
+
+<nav class="navbar navbar-default navbar-custom navbar-fixed-top">
+
+    <div class="container-fluid">
+        
+        <div class="navbar-header page-scroll">
+            <button type="button" class="navbar-toggle">
+                <span class="sr-only">Toggle navigation</span>
+                <span class="icon-bar"></span>
+                <span class="icon-bar"></span>
+                <span class="icon-bar"></span>
+            </button>
+            <a class="navbar-brand" href="/">@johtaniの日記 3rd</a>
+        </div>
+
+        
+        
+        <div id="huxblog_navbar">
+            <div class="navbar-collapse">
+                <ul class="nav navbar-nav navbar-right">
+                    <li>
+                        <a href="/">All Posts</a>
+                    </li>
+                    
+                        
+                    
+		            
+                    <li><a href="/top/about//">ABOUT</a></li>
+                    
+                    <li><a href="/orama/">Orama Search</a></li>
+                    
+                    
+		            <li>
+                        <a href="/search"><i class="fa fa-search"></i></a>
+		           </li>
+                </ul>
+            </div>
+        </div>
+        
+    </div>
+    
+</nav>
+<script>
+    
+    
+    
+    var $body   = document.body;
+    var $toggle = document.querySelector('.navbar-toggle');
+    var $navbar = document.querySelector('#huxblog_navbar');
+    var $collapse = document.querySelector('.navbar-collapse');
+
+    $toggle.addEventListener('click', handleMagic)
+    function handleMagic(e){
+        if ($navbar.className.indexOf('in') > 0) {
+        
+            $navbar.className = " ";
+            
+            setTimeout(function(){
+                
+                if($navbar.className.indexOf('in') < 0) {
+                    $collapse.style.height = "0px"
+                }
+            },400)
+        }else{
+        
+            $collapse.style.height = "auto"
+            $navbar.className += " in";
+        }
+    }
+</script>
+
+
+
+<header class="intro-header" style="background-image: url('/images/header3.jpg')">
+    <div class="container">
+        <div class="row">
+            <div class="col-lg-8 col-lg-offset-2 col-md-10 col-md-offset-1 ">
+                <div class="site-heading">
+                    <h1>@johtaniの日記 3rd </h1>
+                    
+		    <span class="subheading">@johtani&#39;s blog 3rd edition</span>
+                </div>
+            </div>
+        </div>
+    </div>
+</header>
+
+
+
+  
+<div data-pagefind-ignore="all" class="container">
+    <div class="row">
+        
+        
+   	    <div class="
+            col-lg-8 col-lg-offset-1
+            col-md-8 col-md-offset-1
+            col-sm-12
+            col-xs-12
+            post-container
+        ">
+            
+
+<div class="post-preview">
+    <a href="https://blog.johtani.info/blog/2024/01/25/kagome-bot-as-a-user-service/">
+        <h2 class="post-title">
+            kagome-botのユーザーサービス化
+        </h2>
+	
+        <div class="post-content-preview">
+	
+            日常でよく、形態素解析したくなることがありますよね？ そして、Slackも日常的に立ち上がってますよね？ ということは、Slackのボットとして
+       
+        </div>
+    </a>
+    <p class="post-meta">
+    2024-01-25  by johtani
+    
+    
+    </p>
+
+</div>
+<hr>
+
+
+            
+
+
+
+       	</div>
+        
+
+<div class="
+    col-lg-3 col-lg-offset-0
+    col-md-3 col-md-offset-0
+    col-sm-12
+    col-xs-12
+    sidebar-container
+">
+    
+	
+    <section class="visible-md visible-lg">
+	
+        <div class="short-about">
+            
+            <a href="/about">
+               <img src="/images/about_me2.jpg" alt="avatar" style="cursor: pointer" />
+            </a>
+            
+            
+                <p>コワモテの検索好きエンジニアです。検索技術勉強会の運営などをやっています。Elasticsearchなど検索エンジンや検索のサービスなどに興味があります。lucene-gosenのコミッターもやっています。</p>
+            
+           
+           <ul class="list-inline">
+               
+               
+               <li>
+                   <a href="https://twitter.com/johtani">
+                       <span class="fa-stack fa-lg">
+                           <i class="fas fa-circle fa-stack-2x"></i>
+                           <i class="fab fa-twitter fa-stack-1x fa-inverse"></i>
+                       </span>
+                   </a>
+               </li>
+               
+               
+               
+               
+               
+               
+               <li>
+                   <a target="_blank" href="https://github.com/johtani">
+                       <span class="fa-stack fa-lg">
+                           <i class="fas fa-circle fa-stack-2x"></i>
+                           <i class="fab fa-github fa-stack-1x fa-inverse"></i>
+                       </span>
+                   </a>
+               </li>
+               
+               
+               
+               
+               <li>
+                   <a target="_blank" href="https://www.linkedin.com/in//jun-ohtani-254a634a">
+                       <span class="fa-stack fa-lg">
+                           <i class="fas fa-circle fa-stack-2x"></i>
+                           <i class="fab fa-linkedin fa-stack-1x fa-inverse"></i>
+                       </span>
+                   </a>
+               </li>
+               
+               
+               
+            
+            
+               
+               
+               
+               
+                </ul>
+            </div>
+    </section>
+	
+    
+    
+    
+    
+    <section>
+        <hr class="hidden-sm hidden-xs">
+        <h5>FEATURED TAGS</h5>
+        <div class="tags">
+            
+            
+               
+            
+               
+                    <a href="/tags/aws" title="aws">
+                        aws
+                    </a>
+               
+            
+               
+                    <a href="/tags/azure-search" title="azure-search">
+                        azure-search
+                    </a>
+               
+            
+               
+            
+               
+            
+               
+                    <a href="/tags/berlin-buzzwords" title="berlin-buzzwords">
+                        berlin-buzzwords
+                    </a>
+               
+            
+               
+            
+               
+                    <a href="/tags/cloudera" title="cloudera">
+                        cloudera
+                    </a>
+               
+            
+               
+                    <a href="/tags/cloudera-search" title="cloudera-search">
+                        cloudera-search
+                    </a>
+               
+            
+               
+            
+               
+            
+               
+                    <a href="/tags/conference" title="conference">
+                        conference
+                    </a>
+               
+            
+               
+                    <a href="/tags/curator" title="curator">
+                        curator
+                    </a>
+               
+            
+               
+                    <a href="/tags/dev-container" title="dev-container">
+                        dev-container
+                    </a>
+               
+            
+               
+                    <a href="/tags/diy%E3%82%AD%E3%83%BC%E3%83%9C%E3%83%BC%E3%83%89" title="diyキーボード">
+                        diyキーボード
+                    </a>
+               
+            
+               
+                    <a href="/tags/elastic" title="elastic">
+                        elastic
+                    </a>
+               
+            
+               
+            
+               
+            
+               
+                    <a href="/tags/elasticsearch" title="elasticsearch">
+                        elasticsearch
+                    </a>
+               
+            
+               
+                    <a href="/tags/fluentd" title="fluentd">
+                        fluentd
+                    </a>
+               
+            
+               
+            
+               
+            
+               
+                    <a href="/tags/hadoop" title="hadoop">
+                        hadoop
+                    </a>
+               
+            
+               
+            
+               
+                    <a href="/tags/hugo" title="hugo">
+                        hugo
+                    </a>
+               
+            
+               
+                    <a href="/tags/java" title="java">
+                        java
+                    </a>
+               
+            
+               
+            
+               
+            
+               
+            
+               
+                    <a href="/tags/kibana" title="kibana">
+                        kibana
+                    </a>
+               
+            
+               
+            
+               
+                    <a href="/tags/kuromoji" title="kuromoji">
+                        kuromoji
+                    </a>
+               
+            
+               
+            
+               
+                    <a href="/tags/logstash" title="logstash">
+                        logstash
+                    </a>
+               
+            
+               
+                    <a href="/tags/lucene" title="lucene">
+                        lucene
+                    </a>
+               
+            
+               
+                    <a href="/tags/lucene-gosen" title="lucene-gosen">
+                        lucene-gosen
+                    </a>
+               
+            
+               
+                    <a href="/tags/manifoldcf" title="manifoldcf">
+                        manifoldcf
+                    </a>
+               
+            
+               
+                    <a href="/tags/marvel" title="marvel">
+                        marvel
+                    </a>
+               
+            
+               
+            
+               
+                    <a href="/tags/misc" title="misc">
+                        misc
+                    </a>
+               
+            
+               
+                    <a href="/tags/morphlines" title="morphlines">
+                        morphlines
+                    </a>
+               
+            
+               
+                    <a href="/tags/music" title="music">
+                        music
+                    </a>
+               
+            
+               
+            
+               
+                    <a href="/tags/nlp100" title="nlp100">
+                        nlp100
+                    </a>
+               
+            
+               
+            
+               
+                    <a href="/tags/octopress" title="octopress">
+                        octopress
+                    </a>
+               
+            
+               
+            
+               
+            
+               
+            
+               
+                    <a href="/tags/paper" title="paper">
+                        paper
+                    </a>
+               
+            
+               
+                    <a href="/tags/plugin" title="plugin">
+                        plugin
+                    </a>
+               
+            
+               
+            
+               
+                    <a href="/tags/python" title="python">
+                        python
+                    </a>
+               
+            
+               
+            
+               
+                    <a href="/tags/riak" title="riak">
+                        riak
+                    </a>
+               
+            
+               
+                    <a href="/tags/rust" title="rust">
+                        rust
+                    </a>
+               
+            
+               
+                    <a href="/tags/rust-the-book" title="rust-the-book">
+                        rust-the-book
+                    </a>
+               
+            
+               
+            
+               
+                    <a href="/tags/search" title="search">
+                        search
+                    </a>
+               
+            
+               
+            
+               
+            
+               
+            
+               
+                    <a href="/tags/shield" title="shield">
+                        shield
+                    </a>
+               
+            
+               
+                    <a href="/tags/solr" title="solr">
+                        solr
+                    </a>
+               
+            
+               
+            
+               
+            
+               
+            
+               
+            
+               
+            
+               
+                    <a href="/tags/visual-studio-code" title="visual-studio-code">
+                        visual-studio-code
+                    </a>
+               
+            
+               
+            
+               
+                    <a href="/tags/wikipedia" title="wikipedia">
+                        wikipedia
+                    </a>
+               
+            
+               
+                    <a href="/tags/windows" title="windows">
+                        windows
+                    </a>
+               
+            
+               
+                    <a href="/tags/workplace-search" title="workplace-search">
+                        workplace-search
+                    </a>
+               
+            
+               
+            
+               
+            
+               
+                    <a href="/tags/yokozuna" title="yokozuna">
+                        yokozuna
+                    </a>
+               
+            
+               
+                    <a href="/tags/zipkin" title="zipkin">
+                        zipkin
+                    </a>
+               
+            
+               
+            
+               
+                    <a href="/tags/%E3%82%AA%E3%83%A9%E3%82%A4%E3%83%AA%E3%83%BC" title="オライリー">
+                        オライリー
+                    </a>
+               
+            
+               
+            
+               
+            
+               
+            
+               
+            
+               
+                    <a href="/tags/%E3%83%96%E3%83%AD%E3%82%B0" title="ブログ">
+                        ブログ
+                    </a>
+               
+            
+               
+                    <a href="/tags/%E5%82%99%E5%BF%98%E9%8C%B2" title="備忘録">
+                        備忘録
+                    </a>
+               
+            
+               
+                    <a href="/tags/%E5%8B%89%E5%BC%B7%E4%BC%9A" title="勉強会">
+                        勉強会
+                    </a>
+               
+            
+               
+            
+               
+            
+               
+                    <a href="/tags/%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A" title="振り返り">
+                        振り返り
+                    </a>
+               
+            
+               
+            
+               
+                    <a href="/tags/%E6%9C%AC" title="本">
+                        本
+                    </a>
+               
+            
+               
+                    <a href="/tags/%E6%A4%9C%E7%B4%A2" title="検索">
+                        検索
+                    </a>
+               
+            
+               
+            
+               
+            
+               
+                    <a href="/tags/%E8%AA%AD%E6%9B%B8" title="読書">
+                        読書
+                    </a>
+               
+            
+               
+            
+               
+                    <a href="/tags/%E8%BB%A2%E8%81%B7" title="転職">
+                        転職
+                    </a>
+               
+            
+               
+            
+        </div>
+    </section>
+    
+
+    
+    
+    
+</div>
+
+	</div>
+</div>
+
+
+
+
+
+<footer>
+    <div class="container">
+        <div class="row">
+            <div class="col-lg-8 col-lg-offset-2 col-md-10 col-md-offset-1">
+                <ul class="list-inline text-center">
+                   
+                   <li>
+                       <a href='/tags/go/index.xml' rel="alternate" type="application/rss+xml" title="@johtaniの日記 3rd" >
+                           <span class="fa-stack fa-lg">
+                               <i class="fas fa-circle fa-stack-2x"></i>
+                               <i class="fas fa-rss fa-stack-1x fa-inverse"></i>
+                           </span>
+                       </a>
+                   </li>
+                   
+                    
+
+                    
+                    <li>
+                        <a href="https://twitter.com/johtani">
+                            <span class="fa-stack fa-lg">
+                                <i class="fas fa-circle fa-stack-2x"></i>
+                                <i class="fab fa-twitter fa-stack-1x fa-inverse"></i>
+                            </span>
+                        </a>
+                    </li>
+                    
+                    
+                    
+
+                    
+
+		    
+                    
+                    
+                    <li>
+                        <a target="_blank" href="https://github.com/johtani">
+                            <span class="fa-stack fa-lg">
+                                <i class="fas fa-circle fa-stack-2x"></i>
+                                <i class="fab fa-github fa-stack-1x fa-inverse"></i>
+                            </span>
+                        </a>
+                    </li>
+		    
+                    
+                    
+                    
+                    <li>
+                        <a target="_blank" href="https://www.linkedin.com/in//jun-ohtani-254a634a">
+                            <span class="fa-stack fa-lg">
+                                <i class="fas fa-circle fa-stack-2x"></i>
+                                <i class="fab fa-linkedin fa-stack-1x fa-inverse"></i>
+                            </span>
+                        </a>
+                    </li>
+		    
+                    
+                    
+                    
+                    
+                    
+            
+            
+            
+                </ul>
+		<p class="copyright text-muted">
+                    Copyright &copy; @johtaniの日記 3rd 2024
+                    <br>
+                    <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
+                    <iframe
+                        style="margin-left: 2px; margin-bottom:-5px;"
+                        frameborder="0" scrolling="0" width="100px" height="20px"
+                        src="https://ghbtns.com/github-btn.html?user=zhaohuabing&repo=hugo-theme-cleanwhite&type=star&count=true" >
+                    </iframe>
+                </p>
+            </div>
+        </div>
+    </div>
+</footer>
+
+
+
+
+<script>
+    function async(u, c) {
+      var d = document, t = 'script',
+          o = d.createElement(t),
+          s = d.getElementsByTagName(t)[0];
+      o.src = u;
+      if (c) { o.addEventListener('load', function (e) { c(null, e); }, false); }
+      s.parentNode.insertBefore(o, s);
+    }
+</script>
+
+
+
+
+
+
+<script>
+    
+    if($('#tag_cloud').length !== 0){
+        async("/js/jquery.tagcloud.js",function(){
+            $.fn.tagcloud.defaults = {
+                
+                color: {start: '#bbbbee', end: '#0085a1'},
+            };
+            $('#tag_cloud a').tagcloud();
+        })
+    }
+</script>
+
+
+<script>
+    async("https://cdnjs.cloudflare.com/ajax/libs/fastclick/1.0.6/fastclick.js", function(){
+        var $nav = document.querySelector("nav");
+        if($nav) FastClick.attach($nav);
+    })
+</script>
+
+
+
+
+
+
+<script async src="https://www.googletagmanager.com/gtag/js?id=G-ZCZYDMJX3V"></script>
+<script>
+var doNotTrack = false;
+if (!doNotTrack) {
+	window.dataLayer = window.dataLayer || [];
+	function gtag(){dataLayer.push(arguments);}
+	gtag('js', new Date());
+	gtag('config', 'G-ZCZYDMJX3V', { 'anonymize_ip': false });
+}
+</script>
+
+
+
+</body>
+</html>
diff --git a/tags/go/index.xml b/tags/go/index.xml
new file mode 100644
index 0000000000..95b4246a1e
--- /dev/null
+++ b/tags/go/index.xml
@@ -0,0 +1,66 @@
+<?xml version="1.0" encoding="utf-8" standalone="yes"?>
+<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
+
+  <channel>
+    <title>go on @johtaniの日記 3rd</title>
+    <link>https://blog.johtani.info/tags/go/</link>
+    <description>Recent content in go on @johtaniの日記 3rd</description>
+    <generator>Hugo -- gohugo.io</generator>
+    <language>ja</language>
+    <lastBuildDate>Thu, 25 Jan 2024 09:30:53 +0000</lastBuildDate><atom:link href="https://blog.johtani.info/tags/go/index.xml" rel="self" type="application/rss+xml" />
+    <item>
+      <title>kagome-botのユーザーサービス化</title>
+      <link>https://blog.johtani.info/blog/2024/01/25/kagome-bot-as-a-user-service/</link>
+      <pubDate>Thu, 25 Jan 2024 09:30:53 +0000</pubDate>
+      
+      <guid>https://blog.johtani.info/blog/2024/01/25/kagome-bot-as-a-user-service/</guid>
+      <description>日常でよく、形態素解析したくなることがありますよね？ そして、Slackも日常的に立ち上がってますよね？ ということは、Slackのボットとして</description>
+      <content:encoded>&lt;p&gt;日常でよく、形態素解析したくなることがありますよね？
+そして、Slackも日常的に立ち上がってますよね？
+ということは、Slackのボットとして常駐してもらえばできるのでは？&lt;/p&gt;
+&lt;h2 id=&#34;kagome-bot&#34;&gt;kagome-bot&lt;/h2&gt;
+&lt;p&gt;知り合いが&lt;a href=&#34;https://github.com/ikawaha/kagome&#34;&gt;kagome&lt;/a&gt;という形態素解析ライブラリを開発しています。
+その知り合いが、ボットにもしてくれています（複数辞書対応してみたかったので、PR作って取り込んでもらいました）。&lt;/p&gt;
+&lt;ul&gt;
+&lt;li&gt;&lt;a href=&#34;https://github.com/ikawaha/kagome-bot&#34;&gt;https://github.com/ikawaha/kagome-bot&lt;/a&gt;&lt;/li&gt;
+&lt;/ul&gt;
+&lt;p&gt;ただ、デプロイはしてなかったので、我が家にあるUbuntuのサーバーにデプロイして動かすことにしました。
+ボットについては、上記のリポジトリを見てもらえればいいかなと。&lt;/p&gt;
+&lt;p&gt;とりあえず動けばいいや、ということで、適当なshell scriptに&lt;code&gt;nohup&lt;/code&gt;で起動していたのですが、Ubuntuの更新後の再起動で毎回ログインしてスクリプトの実行はめんどくさいな？ということでググって調べてみました。&lt;/p&gt;
+&lt;h2 id=&#34;systemdでユーザーのサービスとして登録&#34;&gt;systemdでユーザーのサービスとして登録&lt;/h2&gt;
+&lt;p&gt;参考ブログにある手順ほぼそのままでした。知見ありがたいです。&lt;/p&gt;
+&lt;p&gt;サービスの登録自体は、指定のディレクトリにファイルを作るのではなく、systemdコマンドをしようしました。&lt;/p&gt;
+&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;$ systemctl --user --force --full edit kagome
+&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;これで、参考ブログにあるように&lt;code&gt;kagome.service&lt;/code&gt;というファイルが&lt;code&gt;~/.config/systemd/user/&lt;/code&gt;ディレクトリに作られます。
+ファイルの内容などはほぼ参考ブログにある通りです。こんなかんじ。&lt;/p&gt;
+&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;[Unit]
+Description=kagome bot
+
+[Service]
+ExecStart=/home/johtani/kagome-bot/start_kagomebot_service.sh
+ExecStop=/bin/kill ${MAINPID}
+Restart=always
+
+[Install]
+WantedBy=default.target
+&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;&lt;code&gt;start_kagomebot_service.sh&lt;/code&gt;の中で、kagome-botコマンドを実行しますが、こちらは絶対パスで記述しておきました。
+サービス起動時のパスは&lt;code&gt;~/&lt;/code&gt;のようなのですが、念のために。&lt;/p&gt;
+&lt;p&gt;あとは、次の手順でサービスを登録して開始します。&lt;/p&gt;
+&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;$ systemctl --user enable kagome
+$ systemctl --user start kagome
+&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;ログを見るのは&lt;code&gt;journalctl&lt;/code&gt;コマンドです。&lt;/p&gt;
+&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;$ journalctl --user -u kagome
+&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;あとは、以下のコマンドを実行しないと、マシン再起動後にログインするまでサービスが起動しないので忘れないようにしましょう。
+（忘れてログインしてみて起動してるじゃん？というコントみたいなことをしてしまいました）。&lt;/p&gt;
+&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;$ sudo loginctl enable-linger username
+&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;参考ブログ本当にありがたいですね。
+備忘録のついでにブログにしておきます。&lt;/p&gt;
+&lt;h2 id=&#34;参考ブログ&#34;&gt;参考ブログ&lt;/h2&gt;
+&lt;ul&gt;
+&lt;li&gt;&lt;a href=&#34;https://pyopyopyo.hatenablog.com/entry/2021/04/30/233755&#34;&gt;ユーザー権限で systemd のサービスを稼働させる方法 - pyopyopyo - Linuxとかプログラミングの覚え書き -&lt;/a&gt;&lt;/li&gt;
+&lt;/ul&gt;
+</content:encoded>
+    </item>
+    
+  </channel>
+</rss>
diff --git a/tags/go/page/1/index.html b/tags/go/page/1/index.html
new file mode 100644
index 0000000000..ce72a6f325
--- /dev/null
+++ b/tags/go/page/1/index.html
@@ -0,0 +1,10 @@
+<!DOCTYPE html>
+<html lang="ja">
+  <head>
+    <title>https://blog.johtani.info/tags/go/</title>
+    <link rel="canonical" href="https://blog.johtani.info/tags/go/">
+    <meta name="robots" content="noindex">
+    <meta charset="utf-8">
+    <meta http-equiv="refresh" content="0; url=https://blog.johtani.info/tags/go/">
+  </head>
+</html>
diff --git a/tags/hadoop/index.html b/tags/hadoop/index.html
index a446d7fde8..be234e7cba 100644
--- a/tags/hadoop/index.html
+++ b/tags/hadoop/index.html
@@ -519,6 +519,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -910,7 +912,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/hive/index.html b/tags/hive/index.html
index 45f4664067..96b1d3066d 100644
--- a/tags/hive/index.html
+++ b/tags/hive/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/hugo/index.html b/tags/hugo/index.html
index 382346e6da..7956beac73 100644
--- a/tags/hugo/index.html
+++ b/tags/hugo/index.html
@@ -456,6 +456,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -847,7 +849,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/index.html b/tags/index.html
index 5f18e08d5f..cdf5bfa798 100644
--- a/tags/index.html
+++ b/tags/index.html
@@ -323,6 +323,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                         hadoop
                         </a>
@@ -712,7 +714,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/index.xml b/tags/index.xml
index 22bd1f9b6a..a98d74dfe4 100644
--- a/tags/index.xml
+++ b/tags/index.xml
@@ -7,7 +7,17 @@
     <description>Recent content in Tags on @johtaniの日記 3rd</description>
     <generator>Hugo -- gohugo.io</generator>
     <language>ja</language>
-    <lastBuildDate>Sun, 31 Dec 2023 07:49:21 +0000</lastBuildDate><atom:link href="https://blog.johtani.info/tags/index.xml" rel="self" type="application/rss+xml" />
+    <lastBuildDate>Thu, 25 Jan 2024 09:30:53 +0000</lastBuildDate><atom:link href="https://blog.johtani.info/tags/index.xml" rel="self" type="application/rss+xml" />
+    <item>
+      <title>go</title>
+      <link>https://blog.johtani.info/tags/go/</link>
+      <pubDate>Thu, 25 Jan 2024 09:30:53 +0000</pubDate>
+      
+      <guid>https://blog.johtani.info/tags/go/</guid>
+      <description></description>
+      <content:encoded></content:encoded>
+    </item>
+    
     <item>
       <title>振り返り</title>
       <link>https://blog.johtani.info/tags/%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A/</link>
diff --git a/tags/java/index.html b/tags/java/index.html
index dba9d1e261..e26c8e22e5 100644
--- a/tags/java/index.html
+++ b/tags/java/index.html
@@ -414,6 +414,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -805,7 +807,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/jira/index.html b/tags/jira/index.html
index 50f497a897..aec5ff9c00 100644
--- a/tags/jira/index.html
+++ b/tags/jira/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/jjug/index.html b/tags/jjug/index.html
index d4f458609a..dbeabda4ed 100644
--- a/tags/jjug/index.html
+++ b/tags/jjug/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/jvm/index.html b/tags/jvm/index.html
index c739f41f1c..2ef1e63e33 100644
--- a/tags/jvm/index.html
+++ b/tags/jvm/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/kibana/index.html b/tags/kibana/index.html
index 4c83be7bd9..0aa10f60c6 100644
--- a/tags/kibana/index.html
+++ b/tags/kibana/index.html
@@ -591,6 +591,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -982,7 +984,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/kibana/page/2/index.html b/tags/kibana/page/2/index.html
index 5a69ef6cd9..ea081ba7b7 100644
--- a/tags/kibana/page/2/index.html
+++ b/tags/kibana/page/2/index.html
@@ -444,6 +444,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -835,7 +837,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/kibana4/index.html b/tags/kibana4/index.html
index 89d7aaa5be..8b869fe81c 100644
--- a/tags/kibana4/index.html
+++ b/tags/kibana4/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/kuromoji/index.html b/tags/kuromoji/index.html
index 23152fc13f..f3b803f3f0 100644
--- a/tags/kuromoji/index.html
+++ b/tags/kuromoji/index.html
@@ -435,6 +435,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -826,7 +828,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/lindera/index.html b/tags/lindera/index.html
index a8db802dd8..c457b35359 100644
--- a/tags/lindera/index.html
+++ b/tags/lindera/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/logstash/index.html b/tags/logstash/index.html
index 2d81be0150..1ecc34d2d7 100644
--- a/tags/logstash/index.html
+++ b/tags/logstash/index.html
@@ -519,6 +519,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -910,7 +912,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/lucene-gosen/index.html b/tags/lucene-gosen/index.html
index e184b2575a..0c49dfe3c3 100644
--- a/tags/lucene-gosen/index.html
+++ b/tags/lucene-gosen/index.html
@@ -591,6 +591,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -982,7 +984,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/lucene-gosen/page/2/index.html b/tags/lucene-gosen/page/2/index.html
index 4b9918e4c1..541584425e 100644
--- a/tags/lucene-gosen/page/2/index.html
+++ b/tags/lucene-gosen/page/2/index.html
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/lucene-gosen/page/3/index.html b/tags/lucene-gosen/page/3/index.html
index 9e81f78ab2..396bea734c 100644
--- a/tags/lucene-gosen/page/3/index.html
+++ b/tags/lucene-gosen/page/3/index.html
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/lucene-gosen/page/4/index.html b/tags/lucene-gosen/page/4/index.html
index 1a8c459e0c..dd0ee681b0 100644
--- a/tags/lucene-gosen/page/4/index.html
+++ b/tags/lucene-gosen/page/4/index.html
@@ -423,6 +423,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -814,7 +816,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/lucene/index.html b/tags/lucene/index.html
index 759ed5eb79..2028906186 100644
--- a/tags/lucene/index.html
+++ b/tags/lucene/index.html
@@ -498,6 +498,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -889,7 +891,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/manifoldcf/index.html b/tags/manifoldcf/index.html
index 41db6dd86c..a35bb6d59f 100644
--- a/tags/manifoldcf/index.html
+++ b/tags/manifoldcf/index.html
@@ -414,6 +414,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -805,7 +807,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/marvel/index.html b/tags/marvel/index.html
index 5bca3449b9..1e3cff71a3 100644
--- a/tags/marvel/index.html
+++ b/tags/marvel/index.html
@@ -456,6 +456,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -847,7 +849,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/mices/index.html b/tags/mices/index.html
index d1e3194768..1fe3f43d64 100644
--- a/tags/mices/index.html
+++ b/tags/mices/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/misc/index.html b/tags/misc/index.html
index 5477bf5e03..3e38453c45 100644
--- a/tags/misc/index.html
+++ b/tags/misc/index.html
@@ -591,6 +591,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -982,7 +984,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/misc/page/2/index.html b/tags/misc/page/2/index.html
index a6faa7edee..1e1f5e1c49 100644
--- a/tags/misc/page/2/index.html
+++ b/tags/misc/page/2/index.html
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/misc/page/3/index.html b/tags/misc/page/3/index.html
index 95811e50fd..f4c74fc9d4 100644
--- a/tags/misc/page/3/index.html
+++ b/tags/misc/page/3/index.html
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/misc/page/4/index.html b/tags/misc/page/4/index.html
index c1536248fa..7142ec8199 100644
--- a/tags/misc/page/4/index.html
+++ b/tags/misc/page/4/index.html
@@ -465,6 +465,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -856,7 +858,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/morphlines/index.html b/tags/morphlines/index.html
index 920973b926..1de3de1e0d 100644
--- a/tags/morphlines/index.html
+++ b/tags/morphlines/index.html
@@ -414,6 +414,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -805,7 +807,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/music/index.html b/tags/music/index.html
index 4dce93220a..94a9ba38ff 100644
--- a/tags/music/index.html
+++ b/tags/music/index.html
@@ -414,6 +414,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -805,7 +807,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/nand2tetris/index.html b/tags/nand2tetris/index.html
index e741ccfbe5..7a020b0dec 100644
--- a/tags/nand2tetris/index.html
+++ b/tags/nand2tetris/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/nlp100/index.html b/tags/nlp100/index.html
index 57c12ccf8c..f8c6add6ae 100644
--- a/tags/nlp100/index.html
+++ b/tags/nlp100/index.html
@@ -591,6 +591,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -982,7 +984,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/nlp100/page/2/index.html b/tags/nlp100/page/2/index.html
index b0992e9675..ffa03c587d 100644
--- a/tags/nlp100/page/2/index.html
+++ b/tags/nlp100/page/2/index.html
@@ -402,6 +402,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -793,7 +795,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/norikra/index.html b/tags/norikra/index.html
index b3516baeea..c589ee26ff 100644
--- a/tags/norikra/index.html
+++ b/tags/norikra/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/octopress/index.html b/tags/octopress/index.html
index bf999acfb8..e318bffda1 100644
--- a/tags/octopress/index.html
+++ b/tags/octopress/index.html
@@ -435,6 +435,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -826,7 +828,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/opensearch/index.html b/tags/opensearch/index.html
index 4db2a2bdd1..afe2f9db08 100644
--- a/tags/opensearch/index.html
+++ b/tags/opensearch/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/orama/index.html b/tags/orama/index.html
index 14407145a0..176aa27300 100644
--- a/tags/orama/index.html
+++ b/tags/orama/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/oss/index.html b/tags/oss/index.html
index 93fcb56de0..a5e803a889 100644
--- a/tags/oss/index.html
+++ b/tags/oss/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/paper/index.html b/tags/paper/index.html
index 811ad17a99..f2b662291b 100644
--- a/tags/paper/index.html
+++ b/tags/paper/index.html
@@ -414,6 +414,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -805,7 +807,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/plugin/index.html b/tags/plugin/index.html
index 44673a308c..5c1c1302ba 100644
--- a/tags/plugin/index.html
+++ b/tags/plugin/index.html
@@ -591,6 +591,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -982,7 +984,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/plugin/page/2/index.html b/tags/plugin/page/2/index.html
index 55f432d2d7..9f46cf83bd 100644
--- a/tags/plugin/page/2/index.html
+++ b/tags/plugin/page/2/index.html
@@ -486,6 +486,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -877,7 +879,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/puppet/index.html b/tags/puppet/index.html
index e3155f8e1e..1ed122c60a 100644
--- a/tags/puppet/index.html
+++ b/tags/puppet/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/python/index.html b/tags/python/index.html
index 1bafe6d553..c66aff26ef 100644
--- a/tags/python/index.html
+++ b/tags/python/index.html
@@ -435,6 +435,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -826,7 +828,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/release/index.html b/tags/release/index.html
index 29382fb75e..b913037d92 100644
--- a/tags/release/index.html
+++ b/tags/release/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/riak/index.html b/tags/riak/index.html
index 078abf86a9..b9dd4bc2fb 100644
--- a/tags/riak/index.html
+++ b/tags/riak/index.html
@@ -477,6 +477,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -868,7 +870,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/rust-the-book/index.html b/tags/rust-the-book/index.html
index fb3b81253c..4122451775 100644
--- a/tags/rust-the-book/index.html
+++ b/tags/rust-the-book/index.html
@@ -561,6 +561,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -952,7 +954,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/rust/index.html b/tags/rust/index.html
index 20567f2438..b69e4682d6 100644
--- a/tags/rust/index.html
+++ b/tags/rust/index.html
@@ -591,6 +591,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -982,7 +984,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/rust/page/2/index.html b/tags/rust/page/2/index.html
index 9f313db221..4bbf7cb530 100644
--- a/tags/rust/page/2/index.html
+++ b/tags/rust/page/2/index.html
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/rust/page/3/index.html b/tags/rust/page/3/index.html
index 00e755143a..6d7b2a894e 100644
--- a/tags/rust/page/3/index.html
+++ b/tags/rust/page/3/index.html
@@ -486,6 +486,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -877,7 +879,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/scala/index.html b/tags/scala/index.html
index d9c181f2a8..1b7e028968 100644
--- a/tags/scala/index.html
+++ b/tags/scala/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/search-ui/index.html b/tags/search-ui/index.html
index 1508c8d251..004b7191d7 100644
--- a/tags/search-ui/index.html
+++ b/tags/search-ui/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/search/index.html b/tags/search/index.html
index 3ad9559f29..92c01ccbc9 100644
--- a/tags/search/index.html
+++ b/tags/search/index.html
@@ -435,6 +435,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -826,7 +828,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/searchkit/index.html b/tags/searchkit/index.html
index d78006e04f..1f95999acd 100644
--- a/tags/searchkit/index.html
+++ b/tags/searchkit/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/sense/index.html b/tags/sense/index.html
index 7f83299ea6..2d43c5ea6f 100644
--- a/tags/sense/index.html
+++ b/tags/sense/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/shield/index.html b/tags/shield/index.html
index 3fff782366..a7da0209af 100644
--- a/tags/shield/index.html
+++ b/tags/shield/index.html
@@ -414,6 +414,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -805,7 +807,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/solr/index.html b/tags/solr/index.html
index dd06bceebf..cd9d8cd93d 100644
--- a/tags/solr/index.html
+++ b/tags/solr/index.html
@@ -591,6 +591,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -982,7 +984,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/solr/page/2/index.html b/tags/solr/page/2/index.html
index 2c744fb8b7..dd5f57c8bd 100644
--- a/tags/solr/page/2/index.html
+++ b/tags/solr/page/2/index.html
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/solr/page/3/index.html b/tags/solr/page/3/index.html
index d0f4682015..a5e72cd853 100644
--- a/tags/solr/page/3/index.html
+++ b/tags/solr/page/3/index.html
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/solr/page/4/index.html b/tags/solr/page/4/index.html
index 8a2a5ee159..5449170784 100644
--- a/tags/solr/page/4/index.html
+++ b/tags/solr/page/4/index.html
@@ -402,6 +402,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -793,7 +795,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/sonatype/index.html b/tags/sonatype/index.html
index 3219b82159..dbe85103db 100644
--- a/tags/sonatype/index.html
+++ b/tags/sonatype/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/stream2es/index.html b/tags/stream2es/index.html
index 33ff740274..a1e600751e 100644
--- a/tags/stream2es/index.html
+++ b/tags/stream2es/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/timelion/index.html b/tags/timelion/index.html
index 9771208288..b88bb21d50 100644
--- a/tags/timelion/index.html
+++ b/tags/timelion/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/travel/index.html b/tags/travel/index.html
index 516a366521..cc1ef76f42 100644
--- a/tags/travel/index.html
+++ b/tags/travel/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/vagrant/index.html b/tags/vagrant/index.html
index a028e381f4..38e0464fea 100644
--- a/tags/vagrant/index.html
+++ b/tags/vagrant/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/visual-studio-code/index.html b/tags/visual-studio-code/index.html
index 07b0534357..319c8b22f0 100644
--- a/tags/visual-studio-code/index.html
+++ b/tags/visual-studio-code/index.html
@@ -414,6 +414,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -805,7 +807,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/watcher/index.html b/tags/watcher/index.html
index eedf1f086d..48e4a59f58 100644
--- a/tags/watcher/index.html
+++ b/tags/watcher/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/wikipedia/index.html b/tags/wikipedia/index.html
index c7bbe1a757..e547522d17 100644
--- a/tags/wikipedia/index.html
+++ b/tags/wikipedia/index.html
@@ -435,6 +435,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -826,7 +828,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/windows/index.html b/tags/windows/index.html
index 07728e4f29..3287f028b0 100644
--- a/tags/windows/index.html
+++ b/tags/windows/index.html
@@ -435,6 +435,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -826,7 +828,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/workplace-search/index.html b/tags/workplace-search/index.html
index 99ea3087b6..cc8c6050f5 100644
--- a/tags/workplace-search/index.html
+++ b/tags/workplace-search/index.html
@@ -414,6 +414,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -805,7 +807,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/wsl/index.html b/tags/wsl/index.html
index 4d6d574ab1..b4d645975a 100644
--- a/tags/wsl/index.html
+++ b/tags/wsl/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/xperia-z/index.html b/tags/xperia-z/index.html
index 0a4e3a6a9c..96bb63aa5f 100644
--- a/tags/xperia-z/index.html
+++ b/tags/xperia-z/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/yokozuna/index.html b/tags/yokozuna/index.html
index 443a907efa..05516f1cbe 100644
--- a/tags/yokozuna/index.html
+++ b/tags/yokozuna/index.html
@@ -477,6 +477,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -868,7 +870,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/zipkin/index.html b/tags/zipkin/index.html
index 4f7c67129f..e6eceb6503 100644
--- a/tags/zipkin/index.html
+++ b/tags/zipkin/index.html
@@ -414,6 +414,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -805,7 +807,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/tags/zoomdata/index.html b/tags/zoomdata/index.html
index 90d234f31d..7c4a343fc5 100644
--- a/tags/zoomdata/index.html
+++ b/tags/zoomdata/index.html
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\343\202\252\343\203\251\343\202\244\343\203\252\343\203\274/index.html" "b/tags/\343\202\252\343\203\251\343\202\244\343\203\252\343\203\274/index.html"
index a12c5ab6cd..6d1c1d3aac 100644
--- "a/tags/\343\202\252\343\203\251\343\202\244\343\203\252\343\203\274/index.html"
+++ "b/tags/\343\202\252\343\203\251\343\202\244\343\203\252\343\203\274/index.html"
@@ -414,6 +414,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -805,7 +807,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\343\202\253\343\203\263\343\203\225\343\202\241\343\203\254\343\203\263\343\202\271/index.html" "b/tags/\343\202\253\343\203\263\343\203\225\343\202\241\343\203\254\343\203\263\343\202\271/index.html"
index 2d4c0124ea..8cb040ae3d 100644
--- "a/tags/\343\202\253\343\203\263\343\203\225\343\202\241\343\203\254\343\203\263\343\202\271/index.html"
+++ "b/tags/\343\202\253\343\203\263\343\203\225\343\202\241\343\203\254\343\203\263\343\202\271/index.html"
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\343\202\262\343\203\274\343\203\240/index.html" "b/tags/\343\202\262\343\203\274\343\203\240/index.html"
index aed385eac2..8b462676cd 100644
--- "a/tags/\343\202\262\343\203\274\343\203\240/index.html"
+++ "b/tags/\343\202\262\343\203\274\343\203\240/index.html"
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\343\202\271\343\203\224\343\203\252\343\203\201\343\203\245\343\202\242\343\203\253/index.html" "b/tags/\343\202\271\343\203\224\343\203\252\343\203\201\343\203\245\343\202\242\343\203\253/index.html"
index 7615ac49fb..4a135cceaa 100644
--- "a/tags/\343\202\271\343\203\224\343\203\252\343\203\201\343\203\245\343\202\242\343\203\253/index.html"
+++ "b/tags/\343\202\271\343\203\224\343\203\252\343\203\201\343\203\245\343\202\242\343\203\253/index.html"
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\343\202\271\343\203\235\343\203\263\343\202\265\343\203\274/index.html" "b/tags/\343\202\271\343\203\235\343\203\263\343\202\265\343\203\274/index.html"
index f227326b44..ad905e877a 100644
--- "a/tags/\343\202\271\343\203\235\343\203\263\343\202\265\343\203\274/index.html"
+++ "b/tags/\343\202\271\343\203\235\343\203\263\343\202\265\343\203\274/index.html"
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\343\203\226\343\203\255\343\202\260/index.html" "b/tags/\343\203\226\343\203\255\343\202\260/index.html"
index 6c11868c51..9319c83c46 100644
--- "a/tags/\343\203\226\343\203\255\343\202\260/index.html"
+++ "b/tags/\343\203\226\343\203\255\343\202\260/index.html"
@@ -500,6 +500,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -891,7 +893,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\345\202\231\345\277\230\351\214\262/index.html" "b/tags/\345\202\231\345\277\230\351\214\262/index.html"
index ae36002f68..464b3781d2 100644
--- "a/tags/\345\202\231\345\277\230\351\214\262/index.html"
+++ "b/tags/\345\202\231\345\277\230\351\214\262/index.html"
@@ -591,6 +591,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -982,7 +984,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\345\202\231\345\277\230\351\214\262/page/2/index.html" "b/tags/\345\202\231\345\277\230\351\214\262/page/2/index.html"
index 374dd7afc9..79ff50f6e2 100644
--- "a/tags/\345\202\231\345\277\230\351\214\262/page/2/index.html"
+++ "b/tags/\345\202\231\345\277\230\351\214\262/page/2/index.html"
@@ -486,6 +486,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -877,7 +879,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\345\213\211\345\274\267\344\274\232/index.html" "b/tags/\345\213\211\345\274\267\344\274\232/index.html"
index e3e4b2d7ad..41433c99be 100644
--- "a/tags/\345\213\211\345\274\267\344\274\232/index.html"
+++ "b/tags/\345\213\211\345\274\267\344\274\232/index.html"
@@ -591,6 +591,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -982,7 +984,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\345\213\211\345\274\267\344\274\232/page/2/index.html" "b/tags/\345\213\211\345\274\267\344\274\232/page/2/index.html"
index 83728f555f..0395ae5f28 100644
--- "a/tags/\345\213\211\345\274\267\344\274\232/page/2/index.html"
+++ "b/tags/\345\213\211\345\274\267\344\274\232/page/2/index.html"
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\345\213\211\345\274\267\344\274\232/page/3/index.html" "b/tags/\345\213\211\345\274\267\344\274\232/page/3/index.html"
index f92deba26b..d56f822018 100644
--- "a/tags/\345\213\211\345\274\267\344\274\232/page/3/index.html"
+++ "b/tags/\345\213\211\345\274\267\344\274\232/page/3/index.html"
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\345\213\211\345\274\267\344\274\232/page/4/index.html" "b/tags/\345\213\211\345\274\267\344\274\232/page/4/index.html"
index c280fcec11..7e5bc95118 100644
--- "a/tags/\345\213\211\345\274\267\344\274\232/page/4/index.html"
+++ "b/tags/\345\213\211\345\274\267\344\274\232/page/4/index.html"
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\345\213\211\345\274\267\344\274\232/page/5/index.html" "b/tags/\345\213\211\345\274\267\344\274\232/page/5/index.html"
index 3f36f1067d..9212edb1fb 100644
--- "a/tags/\345\213\211\345\274\267\344\274\232/page/5/index.html"
+++ "b/tags/\345\213\211\345\274\267\344\274\232/page/5/index.html"
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\345\213\211\345\274\267\344\274\232/page/6/index.html" "b/tags/\345\213\211\345\274\267\344\274\232/page/6/index.html"
index 3c51ff7acf..60d7863b60 100644
--- "a/tags/\345\213\211\345\274\267\344\274\232/page/6/index.html"
+++ "b/tags/\345\213\211\345\274\267\344\274\232/page/6/index.html"
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\345\213\211\345\274\267\344\274\232/page/7/index.html" "b/tags/\345\213\211\345\274\267\344\274\232/page/7/index.html"
index 9bccf226c1..9567d14787 100644
--- "a/tags/\345\213\211\345\274\267\344\274\232/page/7/index.html"
+++ "b/tags/\345\213\211\345\274\267\344\274\232/page/7/index.html"
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\345\213\211\345\274\267\344\274\232/page/8/index.html" "b/tags/\345\213\211\345\274\267\344\274\232/page/8/index.html"
index 9cc22f3c66..2188095d16 100644
--- "a/tags/\345\213\211\345\274\267\344\274\232/page/8/index.html"
+++ "b/tags/\345\213\211\345\274\267\344\274\232/page/8/index.html"
@@ -465,6 +465,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -856,7 +858,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\345\275\242\346\205\213\347\264\240\350\247\243\346\236\220/index.html" "b/tags/\345\275\242\346\205\213\347\264\240\350\247\243\346\236\220/index.html"
index e5159dbdca..e12b3366b1 100644
--- "a/tags/\345\275\242\346\205\213\347\264\240\350\247\243\346\236\220/index.html"
+++ "b/tags/\345\275\242\346\205\213\347\264\240\350\247\243\346\236\220/index.html"
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\346\204\237\346\203\263\346\226\207/index.html" "b/tags/\346\204\237\346\203\263\346\226\207/index.html"
index f9492400ed..b1a46b3b64 100644
--- "a/tags/\346\204\237\346\203\263\346\226\207/index.html"
+++ "b/tags/\346\204\237\346\203\263\346\226\207/index.html"
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\346\214\257\343\202\212\350\277\224\343\202\212/index.html" "b/tags/\346\214\257\343\202\212\350\277\224\343\202\212/index.html"
index 5dd8d8c295..0fb7df8f20 100644
--- "a/tags/\346\214\257\343\202\212\350\277\224\343\202\212/index.html"
+++ "b/tags/\346\214\257\343\202\212\350\277\224\343\202\212/index.html"
@@ -591,6 +591,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -982,7 +984,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\346\214\257\343\202\212\350\277\224\343\202\212/page/2/index.html" "b/tags/\346\214\257\343\202\212\350\277\224\343\202\212/page/2/index.html"
index c05f6bd0f8..ceb2261b6f 100644
--- "a/tags/\346\214\257\343\202\212\350\277\224\343\202\212/page/2/index.html"
+++ "b/tags/\346\214\257\343\202\212\350\277\224\343\202\212/page/2/index.html"
@@ -402,6 +402,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -793,7 +795,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\346\233\270\347\261\215/index.html" "b/tags/\346\233\270\347\261\215/index.html"
index c90ee81b73..ee619a2902 100644
--- "a/tags/\346\233\270\347\261\215/index.html"
+++ "b/tags/\346\233\270\347\261\215/index.html"
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\346\234\254/index.html" "b/tags/\346\234\254/index.html"
index bcaad3bf4d..b01b6035bd 100644
--- "a/tags/\346\234\254/index.html"
+++ "b/tags/\346\234\254/index.html"
@@ -477,6 +477,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -868,7 +870,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\346\244\234\347\264\242/index.html" "b/tags/\346\244\234\347\264\242/index.html"
index 21068f9cf8..2203681d49 100644
--- "a/tags/\346\244\234\347\264\242/index.html"
+++ "b/tags/\346\244\234\347\264\242/index.html"
@@ -456,6 +456,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -847,7 +849,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\346\244\234\347\264\242\343\202\267\343\202\271\343\203\206\343\203\240\346\216\242\350\250\252/index.html" "b/tags/\346\244\234\347\264\242\343\202\267\343\202\271\343\203\206\343\203\240\346\216\242\350\250\252/index.html"
index 77f0ab83c7..35b8a72831 100644
--- "a/tags/\346\244\234\347\264\242\343\202\267\343\202\271\343\203\206\343\203\240\346\216\242\350\250\252/index.html"
+++ "b/tags/\346\244\234\347\264\242\343\202\267\343\202\271\343\203\206\343\203\240\346\216\242\350\250\252/index.html"
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\347\224\273\351\235\242/index.html" "b/tags/\347\224\273\351\235\242/index.html"
index 3c7356ffd0..da57104b0b 100644
--- "a/tags/\347\224\273\351\235\242/index.html"
+++ "b/tags/\347\224\273\351\235\242/index.html"
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\350\252\255\346\233\270/index.html" "b/tags/\350\252\255\346\233\270/index.html"
index aee1321e1c..ca05786147 100644
--- "a/tags/\350\252\255\346\233\270/index.html"
+++ "b/tags/\350\252\255\346\233\270/index.html"
@@ -591,6 +591,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -982,7 +984,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\350\252\255\346\233\270/page/2/index.html" "b/tags/\350\252\255\346\233\270/page/2/index.html"
index dc80ea9659..1b5339a986 100644
--- "a/tags/\350\252\255\346\233\270/page/2/index.html"
+++ "b/tags/\350\252\255\346\233\270/page/2/index.html"
@@ -595,6 +595,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -986,7 +988,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\350\252\255\346\233\270/page/3/index.html" "b/tags/\350\252\255\346\233\270/page/3/index.html"
index 8b888a358d..f71ece8559 100644
--- "a/tags/\350\252\255\346\233\270/page/3/index.html"
+++ "b/tags/\350\252\255\346\233\270/page/3/index.html"
@@ -465,6 +465,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -856,7 +858,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\350\262\267\343\201\204\347\211\251/index.html" "b/tags/\350\262\267\343\201\204\347\211\251/index.html"
index edb7973eec..365daa159f 100644
--- "a/tags/\350\262\267\343\201\204\347\211\251/index.html"
+++ "b/tags/\350\262\267\343\201\204\347\211\251/index.html"
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\350\273\242\350\201\267/index.html" "b/tags/\350\273\242\350\201\267/index.html"
index a64a2400c2..e325feb2aa 100644
--- "a/tags/\350\273\242\350\201\267/index.html"
+++ "b/tags/\350\273\242\350\201\267/index.html"
@@ -456,6 +456,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -847,7 +849,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git "a/tags/\350\274\252\350\252\255/index.html" "b/tags/\350\274\252\350\252\255/index.html"
index 4ea03fa1ff..664d560f07 100644
--- "a/tags/\350\274\252\350\252\255/index.html"
+++ "b/tags/\350\274\252\350\252\255/index.html"
@@ -393,6 +393,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -784,7 +786,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/top/about/index.html b/top/about/index.html
index 9b2ba498a2..5fdb617e16 100644
--- a/top/about/index.html
+++ b/top/about/index.html
@@ -414,6 +414,8 @@ <h5>FEATURED TAGS</h5>
                
             
                
+            
+               
                     <a href="/tags/hadoop" title="hadoop">
                         hadoop
                     </a>
@@ -805,7 +807,7 @@ <h5>FEATURED TAGS</h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe
diff --git a/top/index.html b/top/index.html
index 22ea01fa6e..d08c11cd22 100644
--- a/top/index.html
+++ b/top/index.html
@@ -347,6 +347,8 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
                         
                         
                         
+                        
+                        
                         <a href="/tags/hadoop" title="hadoop">
                             hadoop
                         </a>
@@ -736,7 +738,7 @@ <h5><a href="/tags/">FEATURED TAGS</a></h5>
             
                 </ul>
 		<p class="copyright text-muted">
-                    Copyright &copy; @johtaniの日記 3rd 2023
+                    Copyright &copy; @johtaniの日記 3rd 2024
                     <br>
                     <a href="https://themes.gohugo.io/hugo-theme-cleanwhite">CleanWhite Hugo Theme</a> by <a href="https://zhaohuabing.com">Huabing</a> |
                     <iframe