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
Elasticsearchで日本語全文検索をするために、最近見てるもの使ってるもの
最近仕事でElasticsearchと戯れています。
Kibanaでログ解析とかする人が多いとおもうのですが、
コンテンツの日本語全文検索用だったりします。
ログ解析の資料は多い（と思う）んですが、
日本語全文検索の文献がすくない＞＜
analyzerチェックのために使うpluginって、inquisitorが王道な感じがするのですが、
個人的にはkopfが神でした。github.com
blog.johtani.info
機能が多くてリッチなのもよいのですが、
analyzeAPIを叩いて単語が分割された結果が見れるというのがとてもよい。
(kuromojiをつかっているなら、kuromoji demo - japanese morphological analyzer
に入力すれば品詞がわかるので、stoptagsの選定をしたりしました）
あとは、参考にさせていただきまくってるブログなど。
つかってみた系はあえて除いて、実践編でブックマークしているものから。
日本語全文検索関連
medium.com
Elasticsearch 日本語で全文検索 その２ — Hello! Elasticsearch. — Medium
Elasticsearch 日本語で全文検索 その３ — 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上で完結できるように資料を作成しておけばよかったなぁと。
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を直接発行して削除している。
なので、
みたい。
※Rails3
【参考】
