第4回elasticsearch勉強会

第4回elasticsearch勉強会 - elasticsearch勉強会 | Doorkeeperのログ
発表スライドは第4回Elasticsearch勉強会を開催しました。#elasticsearchjp - @johtaniの日記 2ndにまとまってる。超助かる。

株式会社シーマーク 大谷 純 @johtani タイトル:「アナライズ処理の仕組みとクエリDSL

  • elasticsearchのcharFilter, tokenizer, tokenFilterの適応順番
  • そもそもanalyzeされるクエリとそうじゃないクエリがある。どれが適応されるクエリか
  • apache solrのanalyze画面のように、analyzeの仮定を表示するプラグインの紹介

株式会社マーズフラッグ R&D部 やまかつ さん @yamakatu タイトル:「elasticsearch-hadoopを使ってごにょごにょしてみる」

  • 本質的にはhadoopのストレージとしてelasitcsearch上のデータを扱えるようになる
    • hadoop上のデータを検索できるようになる、ではない。注意
    • hadoop上のデータをelasticsearchにwriteするだけっていうのもできる

株式会社アットウェア 佐竹雅央さん @madgaoh 河村康爾さん @ijokarumawak タイトル: 「CouchbaseとElasticsearchが手を結んだら」

  • couchbase - couchdbではない
    • メモリ+ストレージのハイブリッド・キーバリューストア
    • スケールアウトなども考慮されてる
    • ただし、現状データ横断的な処理は苦手
  • couchbaseのcross data center rsync...? の機能を使って、elasticsearchをcouchbaseに見せかけるプラグインを使用して、elasticsearchをさもcouchbaseの1クラスタのように見せる
    • ただ、RDB, couchbase, elasticsearchの3構成でcouchbaseはDB
  • ちなみに、以下のように統一していく流れ
    • 外部からElasticSearchへ流し込むプラグイン → River Plugin
    • Elasticsearchから外部へ転送するプラグイン → Transport Plugin

Wantedly, Inc 内田誠悟さん @spesnova タイトル:未定

  • 詳細忘れた。この会社の知名度がすごく高くて驚いた

LTその1 スクリプト使ってみた

  • dinamyc script - 開発向け
  • server side script? - 運用向け
  • native? script(java)

LTその2 basistechさんのプラグイン宣伝

git-trash-branchを作ってみました

gitでブランチを操作しながら開発してるとき、よくブランチを完全削除ではなく一旦ゴミ箱的な場所に移したいと思うケースがありました。
gitのブランチ削除は復元する方法がないため、もし削除してしまったブランチをもとに戻す場合は泣きながらreflogでハッシュ番号を漁る必要があります。しかし、それを恐れて無駄なブランチを削除しないと使わないブランチがどんどん増えて、どれが今開発してる(生きている)ブランチなのかわからなくなってきます。
現状ではそういった「たぶんいらないブランチ」はgit branch -mオプションを利用してtrash/というプレフィックスをつけていました。これにより今使ってるブランチといらないブランチをはっきりと区別することができます。ただ、branchAをtrashへ移動させたい場合、

$ git branch -m branchA trash/branchA

とbranchAという文字列を2度打つ必要があり面倒でした。加えて、全体的にコマンドが長いです。
そこで、gitのサブコマンドを自作して以下のように打てるようにしました。

$ git trash-branch branchA

ソースコード、インストール方法、使い方はbigwheel/git-trash-branchを参照してください。

今回はシェルスクリプトのコードに対してrspec単体テストを書くという自分では初めての挑戦をしています。これ、やってみるとかなり良かったです。ruby自体がかなりコマンド実行と親和性が高いため、両方書ける人ならかなり直感的に書くことができます。

あとやり残したこととしてはインストールをchefで書いて、chef-applyからコマンド一発でできるようにすることぐらい。

gitサブコマンドの書き方備忘録

gitのサブコマンドを書こうとしてもはや何度目かわからないshell scriptの書き方再勉強をしていた。不毛なので、ここに関連URLを残しておく。

自炊で自宅の本を一掃した話(使用した道具編)

正月、自炊作業をしていました。

概要

作業期間 12/31〜01/02の丸3日
使用したスキャナ FUJITSU ScanSnap iX500 FI-IX500
使用した裁断機 ディスクカッター DC-210N 3冊で諦めて → ダーレー Durodex 自炊裁断機 200DXへ移行
スキャンした本の数 211冊
本の種類 ライトノベル、技術書など
かかったコスト合計 \39,000(ScanSnap) + \9,500(DC-210N) + \37,800(200DX) = \86,300

話をまとめず箇条書きでつらつらと気づいた点を列挙

  • ScanSnapすごい
    • 両面のスキャンを一度にしてくれることがこんなに楽だと思わなかった
    • 一度に約40枚の紙を一気にスキャンしてくれる。複合機で1枚ずつ表裏を手作業でスキャンしてたのが馬鹿らしくなる便利さ
    • 紙の重なりを今のところ100%検出してくれているため、スキャン後のデータチェックへそれほど神経を払わなくてもいい。超音波センサーらしいが素晴らしい精度
    • スキャンした画像に白い筋が入ってしまう現象があったが、これはスキャナ内部にへばりついたホコリが原因だった。古い本を大量にスキャンしたためホコリが蓄積されてスキャナへ付着してしまった結果だが、どうやらよくあることのようなので今後もスキャン後の画像へ筋が入ってないか気を払う必要はある
    • 全然場所を取らない。複合機の半分ぐらいの専有容積。まったく重くなく、女性でも楽に運べる大きさ
    • ScanSnapを接続するとOSの音量が半分になるよくわからないバグが有る。解決法はまだ見つけてない
  • 裁断機には金を出し惜しまないほうがいい
    • 最初DC-210Nを購入して本を裁断しようとしたが、小説を百冊単位で処分しようとしていた自分では機能不足だった
      • DC-210Nは実売1万円、200DXは実売4万円とたしかに大きな違いがあるが、それぞれが一度に裁断できる紙の枚数も40枚vs200枚と大きく異る。本を裁断することに比べて本を分割することはかなり手間だ*1
      • DC-210Nは非常に辛い。まず最初にカッターで本を分割するのが酷く手間な上、歯がローリングカッター式なのでテコの原理などを使えず、体重をかける必要がある
    • 200DXは高い。高いが30冊以上の本を裁断したいなら200DXかPK-513LN-Aのどちらかは絶対必要になる
      • 自分が513LN-Aより約1万円高い200DXをあえて選んだ理由は1.未使用時の収納しやすさ 2.最大裁断枚数の多さ(15mm→18mm) の2点
      • 200DXは重い。たぶん513LN-Aも同じぐらい重い。210Nはこれらに比べるとかなり軽いが、専有容積はほとんど変わらない

身の回りの書籍を電子化する、ということが自分の生活へどのような影響を及ぼしたのか、についてはまた日を改めてまとめる。たぶん。

*1:自分はその手間をなくすために追加で3万円払うことは十分その価値が有ると思ったため、DC-210Nから200DXへ移った