読者です 読者をやめる 読者になる 読者になる

mosowave

sinamon129による(主に)技術ブログ。Ruby,Ruby on Rails,Elasticsearchやその他について書きます。

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

www.slideshare.net


設定関連
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

登壇のきっかけ

f:id:sinamon129:20150531222732p:plain

いつものごとく@amacbee氏からの盛大なる無茶振りでしたが、
発表とか苦手すぎて避けている節があるので、普段つかっているツールではあるので
おっけ〜と返事させてもらいましたw

すごく素敵なイベントレポートへのリンク

当日の様子 togetter

togetter.com

レポートブログ

sh1k1ya.hatenablog.com
ihcomega.hatenadiary.com
2015年5月23日 Git for Beginners開催しましたhotchpotchj37.wordpress.com
A Days of Wine and Geeks: Git For Beginers(#javajo #PyLadiesTokyo)参加してきた


感想とか

見渡す限り女性なのですが、当たり前なのに驚く人の山(当たり前なのに謎の違和感を感じる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上で完結できるように資料を作成しておけばよかったなぁと。

その他

個人的にはLGTMの話ができたので満足だったりはします...w



次は5分のLTとかで発表してみたいですね〜

          • -

久々に長いブログをかいた...。登壇とかなかなかする機会ないので積極的にやりたい。
得意じゃないので、場数を踏んで徐々に慣れていければと。
最近仕事で使ってるruby, rails, elastic search界隈の勉強会とかにも行きたいなぁと。
ぼちぼちやっていこうと思います〜。

rails で transaction内でnextしたらtransactionブロックを抜けただけだった話

タイトルが結論なんですが、つんだ話。

Railsで、

[1,2,3].each do |i|

  Hoge.transaction do
   何らかの処理
   next if Hoge.huga
  end
  
  p i
end

みたいなのを書いたとして、
例が適当すぎるけど、要はfor文の中に、transactionを書いて、
transaction内の処理の内容によっては、その後の処理をskipして次に行きたい場合ってのがあったんだけども、その場合にnextが効かないことに気づいた。

transactionはブロックなので、ここでかくnextはブロックを抜けてしまうっぽい。
nextで飛ばされるはずの、transactionブロック後のp i が実行されて、あれ?ってなって気づいた。


ブロックとクロージャーについて詳しく書いてある記事にお世話になった
Rubyの動かないコード (初級編) ブロックとクロージャの性質 - 主に言語とシステム開発に関して

has_manyのdependentパラメータの値がdestroyとdelete_allの時の違い[Rails]

Railsで、親のレコードと一緒に、関連する子のレコードも消したい時に、
has_manyのdependentパラメータにdestroyを選ぶべきか、delete_allを選ぶべきか迷った
(というか、何も考えずにdestroyをかいたら、delete_allでいいんじゃない?って言われて、違いをしらべた)
ので、メモ。

destroyの場合は、

class Parent < ActiveRecord::Base
  has_many :children, dependent: :destroy
end

Childrenクラスのインスタンスを生成して、destroyを実行していている。

delete_allの場合は、

class Parent < ActiveRecord::Base
  has_many :children, dependent: :delete_all
end

Childrenクラスのインスタンスを生成せずに、親のidを元にSQLを直接発行して削除している。

なので、

  • delete_allのほうが効率がよい(インスタンス生成が起こらないので)
  • destroyを使うときは、インスタンス生成することで追加で何か処理を行わないといけない時(deleteする前後に〜とか)

みたい。

※Rails3



【参考】

今年のTRYの進捗

もう3月になりました。あっという間ですね。

せっかくなので軽く振り返り記事。

★日常生活編
1. 体力をつける
→朝ヨガに行き始めた。が、体調崩したりして、まだ2回しかいってない。
 TRY:今週からは行く。

2. 週2回以上は自炊する
→なんやかんやでできてる。頑張る。

3. 早起きをする
→できてない。ギリギリでおきてる。
 TRY:朝ごはんを食べれる時間に起きるようにする。最低8時。

4. 一日一箇所何か片付ける
→全然できてなくて、部屋が荒れたので今日頑張って片付けた。
 物が多いのが問題なので、いらないものは売るか捨てるかするようにしてものを減らす。
 TRY:一年以上手をつけてないものは捨てる

★仕事編
1. 効率アップするアレコレを覚えたり時間やお金を投資したりする
→心がけ始めた。Dashにsnippetを追加したりして、ちょっと効率化した。
 vimrcとかzshrcを整備しなおしたりした。

2. 人に聞くと決めたら早く聞く
→案外大丈夫になってきた気がする。この調子。

★その他
1. 本を読む
→あまりできてない。
 TRY:デザインパターン関係の本(先輩に貸してもらった)2冊読む
    あと、Effective RubyとパーフェクトRuby on Rails読む

2. ブログを書く
→全然できてない、リレーブログすっ飛ばした
 TRY:最低でもリレーブログは書く

3. もうちょっと外にでる
→服を買いに行くとかしかしてない気がする…
 歯医者に行く習慣はついたけど…。
 TRY:一人で行く気が起きないなら誰かとの予定をいれる、土日どちらか一回以上。

    • -

またこのTRYの進捗を書く。