chartkickでHigh Chartsを使おうとした時に引っかかった話
chartkickといういい感じにグラフを表示してくれるgemがあります。
JavaScriptのライブラリを読み込む時に、GooglechartsかHigh Chartsを利用できて、High Chartsを使おうとした時に、
If you prefer Highcharts, use:<%= javascript_include_tag "path/to/highcharts.js", "chartkick" %>
とREADMEに書いてあったので、
app/assets/javascripts以下にhighcharts.jsを置いて、
app/views/layouts/application.html.erbに
<%= javascript_include_tag "highcharts", "chartkick" %>
と書くと、app/assets/javascrips/applications.jsに書いてないものはprecompileされないから、そんなものねーといわれる
なので、
app/assets/javascrips/applications.jsに
//= require highcharts
を追加したら、
Highcharts already defined in the pageといわれる。どうやら2重で読み込まれてしまったらしい。
結局、
- app/views/layouts/application.html.erbから
<%= javascript_include_tag "highcharts", "chartkick" %>
の表記を削除
- app/assets/javascrips/applications.jsに
//= require highcharts
//= require chartkick
を記述
することでうまくいった。
Elasticsearchのslowlogの設定をした話
最近、日本語全文検索サーバーとしてElasticsearchを使っていて、
たまにクエリのキューが沢山たまってしまうことがあり、
原因になってるクエリを調べたくなりました。
slowlogがあるのは知っていたので見に行ったら空!設定されてなかったorz
今回はそんなslowlogを設定した話です。
Elasticsearchのバージョンは1.7.2です。
elasticsarch.ymlの下の方に
index.search.slowlog.threshold.query.warn: 10s
index.search.slowlog.threshold.query.info: 5s
index.search.slowlog.threshold.query.debug: 2s
index.search.slowlog.threshold.query.trace: 500msindex.search.slowlog.threshold.fetch.warn: 1s
index.search.slowlog.threshold.fetch.info: 800ms
index.search.slowlog.threshold.fetch.debug: 500ms
index.search.slowlog.threshold.fetch.trace: 200ms
こんな項目が!!コメントアウトされてる\(^o^)/
コメントをはずした。
traceとかdebugとかはどこで設定するんだろう?とおもって公式のドキュメントをみていたら、
公式documentにlogging.ymlにloggingの出力形式等の設定ができるっぽいので見に行ってみると、ありました。
中略
index.search.slowlog: TRACE, index_search_slow_log_file
index.indexing.slowlog: TRACE, index_indexing_slow_log_fileadditivity:
index.search.slowlog: false
index.indexing.slowlog: false
traceのままでよかったので、search.slowlogとindexing.slowlogをtrueにして無事slowlogが吐かれるようになりました。
ログの形式をきめれたりもするので、いい感じに設定するとはかどりそうです。
設定できた感動でログの形式はデフォルトのまま+ログ集積してゴニョりたかったけど、とりあえず各サーバーのログを集めてチェックしたい!!
となったので、
デフォルトの設定で吐かれたログをパースしてcsvに吐く超適当プログラムをrubyで書いた。
require 'csv' CSV.open('slow_logs.csv', 'wb') do |csv| csv << ['date', 'kind', 'node_name', 'index_name', 'shard_number', 'took', 'took_millis', 'source'] File.open('search_slowlog') do |file| file.each_line do |line| md = line.match(/\[(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2},\d{3})\]\[TRACE\]\[(.*)\] \[(.*)\] \[(.*)\]\[(.*)\] took\[(.*)\], took_millis\[(.*)\], types\[\], stats\[\], search_type\[QUERY_THEN_FETCH\], total_shards\[12\], source\[(.*)\], extra_source\[\]/) csv << [ md[1], # date md[2], # kind md[3], # node_name md[4], # index_name md[5], # shard_number md[6], # took md[7], # took millis md[8] # source ] end end end end
これをノードの台数分さまるプログラムをかいて(上記のプログラムに入れた)、スプレッドシートに貼ってソートしてチェック。
ほんとうはfluendとかでいい感じにあつめてkibanaとかでいい感じに見たかった(今後の課題)
whenever で毎時45分とかをwhenever っぽく書く
Rubyのコードでcrontabを管理できるwheneverというgemを使っていて、
毎時45分ってcronっぽい書き方じゃなくかくにはどうしたらいいか案外のってなかったのでかく。
毎時45分とかは、
every 1.hours, at: 45 do
rake 'rake:task'
end
みたいに書けば良かった。
mysqlなどで集計をやってるときによくやる作業の無駄を省く
運用をするエンジニアあるあるかなと思うのですが、
集計用SQLで、
(DBが超ハイスペックだったらいいが、そうでもない場合)
テーブルをjoinするとかなり重い時とか条件が複雑で時間がかかったりする時に、
条件が複雑すぎて一旦途中までidを出してその中からさらに絞るーみたいなことがあって、
いつもだいたいsequel proというGUIツールで叩くのですが、
まあid群をだして、結果がこういう風に出るわけですが、
1111
2222
3333
4444
これを
select * from items where id in (1111,2222,3333,4444)
みたいにするために、
1111,2222,3333,4444
に変換するみたいなことがよくあったりします。(わたしだけ?)
いつもは、
改行されてるid群をコピー
↓
vimにはりつける
↓
%s/$/,/g
↓
全選択してJ
↓
閉じてcatしてコピー
みたいなことをやってたんですが、
今日いきなり、これって、めっちゃ無駄じゃないか?とおもって考えたら
shellでできた
改行されてるid群をコピー
↓
pbpaste | sed -e "s/$/,/g" | tr -d '\n' | sed -e "s/,$//g"| pbcopy
するとなんとクリップボードの保存されてて、あとペーストすれば使えた...
pbpasteはクリップボードからデータを取得
sedで文字列置換
trで改行削除
最後の,を削除
pbcopyでクリップボードにデータを貼り付ける
最近自覚した話。
ポエムと言うか、なんというか。
どうやら私には結論からしゃべる力が低いということをやっと自覚したw
結論から喋れるようになりたいという話を書く。
数年前から、たまに何言ってるか分からないって言われることが多く、
その自覚は一応あった(よく言われるから)。
具体的な話は結構大丈夫だけど、抽象的な話をしている時に意味がわからないと言われることが多い。
原因は、
抽象的な話を喋りながら考えてる時に自分が結論にたどり着いてないからっぽい。
最後に私は何が言いたかったんだっていうか、
そもそも何の話をするか先に言うまでしゃべるのをやめた方が良さそう。
最近は喋ってる途中に、やべっ、またたどり着いてないと思うぐらい自覚するようになったw
いまさらかよ?って周り人は思ってるかもしれないけど、
やっと自覚したので頑張って改善してゆきます….w
Elasticsearchで日本語全文検索をするために、最近見てるもの使ってるもの
最近仕事でElasticsearchと戯れています。
Kibanaでログ解析とかする人が多いとおもうのですが、
コンテンツの日本語全文検索用だったりします。
ログ解析の資料は多い(と思う)んですが、
日本語全文検索の文献がすくない><
analyzerチェックのために使うpluginって、inquisitorが王道な感じがするのですが、
個人的にはkopfが神でした。github.com
blog.johtani.info
機能が多くてリッチなのもよいのですが、
analyzeAPIを叩いて単語が分割された結果が見れるというのがとてもよい。
(kuromojiをつかっているなら、kuromoji demo - japanese morphological analyzer
に入力すれば品詞がわかるので、stoptagsの選定をしたりしました)
あとは、参考にさせていただきまくってるブログなど。
つかってみた系はあえて除いて、実践編でブックマークしているものから。
日本語全文検索関連
medium.com
Elasticsearch 日本語で全文検索 その2 — Hello! Elasticsearch. — Medium
Elasticsearch 日本語で全文検索 その3 — Hello! Elasticsearch. — Medium
blog.inouetakuya.info
speakerdeck.com
sssslide.com
http://sssslide.com/speakerdeck.com/kunihikokido/elasticsearch-rihttps://medium.com/hello-elasticsearch/elasticsearch-c98fd9ce6a18-ben-yu-sukimaresuhuan-jing-gou-zhu-to-tuideniduo-yan-yu-dui-yingsssslide.com
medium.com
speakerdeck.com
index構築関連
elaticsearchの公式ドキュメントが本当に読めばかいてあるのでよく読みます...
Performance Considerations for Elasticsearch Indexing | Elastic
kakakazuma.hatenablog.com
設定関連
kakakazuma.hatenablog.com
speakerdeck.com
elasticsearch勉強会
elasticsearch勉強会 | Doorkeeper
blog.johtani.info
やったこととか、多分今後やってくこととかはまとめてブログとかにあげていきたい。。。
Git for Beginnersで話をしてきました
こんにちは、5月がおわりますね、しなもんです。
五月病って何?ってぐらいあっとゆう間な5月でした。
先週の話になるのですが、
Java女子部とPyLadies Tokyoの共催のGit for Beginnersが行われて、
35名ぐらいの方が集まる中で、登壇してきました。pyladies-tokyo.connpass.com
javajo.doorkeeper.jp
すごく素敵なイベントレポートへのリンク
当日の様子 togetter
感想とか
見渡す限り女性なのですが、当たり前なのに驚く人の山(当たり前なのに謎の違和感を感じるw)で、
かくいう私も女性オンリーの勉強会に来るとそういう気持ちになりますw
最初に自己紹介タイムがあったので、どういう方が来てるかをだいたい把握できて、
層は結構バラバラで、最近プログラミングを始めた方から熟練者まで様々でした...!
他の登壇者の方の発表はとっても分かりやすい内容でした...!
www.slideshare.net@ihcomegaさんによる2ヶ月前にGitを始めた私からこれから始める皆さんへ!
一枚絵がかわいらしくて分かりやすい...!
www.slideshare.net
@YuryuさんによるGitHubつかってみようハンズオン!
Githubで完結するハンズオンで、隣の人とPR体験も。とんかつがたべたくなるハンズオンでした!w
github.com
@_zooさんによる、DevOps分野でのGit活用事例
branchで特定の命名でpushすると、自動でVirtualHost環境ができるの便利そうだった!!
自分の発表した内容に関して(ほぼ反省)
普段複数人開発で感じているGit, GitHubのうまみというタイトルで話をしました。
資料(いちおう)
反省ポイント
⭐️ バージョン管理自体のうまみとGit,GitHubのうまみがまじってた
もっと分けて書いてよかったなと反省。
svnを1年ぐらいつかったことがありますが、
ローカルでgit-svnを使っていたのでほぼgitをつかっている状態だったため、
あまりsvnの知識はありませんでしたorz
つらいなぁと思ったのは、commitがすごく重たくて気軽にcommitできないのと、
commitしてあるファイルが全部リリースしていい状態じゃなかったりしたので、
ファイル指定してsvn upしたりして事故が起きやすかったと記憶しています。
(これらは運用にもよるかもしれないですね)
⭐️自分が慣れてるのでCUIで説明してしまった
普段統合開発環境を使ってる方が多かったようで、コマンドラインで説明しちゃったところがわからないという声が上がっていたのに終了してから気づきましたorz この辺り難しいですね。。。
Github上でハンズオンをやったので、Github上で完結できるように資料を作成しておけばよかったなぁと。