SpringMT @spring-mt - Tumblr Blog

羽生くんにサインを送る荒川静香姉さんがカッコよすぎるｗｗｗｗｗｗ : 無題のドキュメント

前回の続き。

前回の時点では「git blameが密になっているところはきっと活発に編集されていたに違いない」という仮説があったわけですが、これは本当のところは、よくわからない。なぜかというと、blameというのは地層のように降り積もったコミットの表面に露頭してるところしか見せてくれないわけです。本当に活発に更新されていたかを知るには、ようするに地質平面図じゃなくて地質断面図が必要なわけ。分かりますよね。

で、それはどうやって作ればいいかというと、gitには便利なgit log -pという、こういうとき便利だけど普段は使い道のなさそーなコマンドがあって、これは生のdiffをすべてだらだらと表示してくれるわけですよ。で、diffからblameを再構成するにはdiffの+行をひたすら集めてくればいいわけだけど、その時-行も一緒に覚えておいて、あるコミットでどのコミットが上書きされたかを覚えておくことができる。そのようにすると、blameっぽいけど地層の底の方を見通すことができるコマンドというものが作成できる。

たとえばこういう出力が得られます:

いかにも更新頻度の高そうな行がどのへんかがちゃんと可視化されているのが分かりますね。

で、これだけでも結構興味深くて、たとえばeval.cで結局どこが一番ホットな箇所だったかといえばすばりここということがわかって、これはとても納得感が高い。つまり、作ってる我々からしてみても「ここは大変だった」と思える箇所なわけで、けっこうな妥当性があるんじゃないかと思いますね。なのでこれはこれで便利に使えるツールに仕上がるのではないかという気がする。

ただまあ、やっぱ図にしてみたいですよね。前回同様に。で、やってみるとこうなる。明るいほど高頻度の編集です

これ、ぱっと見で画像が暗いと感じると思うのですが、ヒストグラムがひじょうに興味深くて、全体の50パーセンタイルが一回しか更新されてないのですよ。二回以下だと76パーセンタイル。まあこれだけで絵づらは決まったようなもんです。

なので実はrubyの実装においては実は、だいたい半分はいっぱつ書きで動いてるといえる。もちろん、コメントとかも含んでるから、実際はもう少し精査しないといけないだろうけれど、それでもかなり予想より多いですね。びっくりです。

逆に言うと、八回以上も編集してる箇所が1パーセンタイル弱くらいあるわけですけども、これはあやしいー。明らかに他と傾向が違うので、こういった部分では何かまずいことが起きていたのではないか? ということが推察されるわけです。たとえば上でも例にあげたeval.cの一番熱かった部分などは、これは二転三転した部分でとても困難だった。他にもそういう所があったのではないか? と思われるわけです。これを利用することで、更新頻度からのバグ探しといったことも可能ではないかと思わせますね。

TDDBC Fukuoka 2013を開催しました！

2013/6/15 〜 2013/6/16でTDDBC Fukuoka 2013を開催しました。

TDD Boot Camp Fukuoka 2013

23人参加のうち5人が学生という、自分が開催した勉強会では珍しい会となりました！

まとめ

TDDBC Fukuoka 2013 1日目のつぶやきのまとめ

TDDBC Fukuoka 2日目のつぶやきのまとめ

TDD Boot Camp Fukuoka 2013/1日目KPT

TDD Boot Camp Fukuoka 2013/2日目KPT

TDDBC FukuokaのFBグループ

今回は主催者ということで、コード殆ど書いてないですが振り返りを。

主催者としての振り返り

KPTで出てきた部分は除いており、個人的な振り返りです。

立地、電源やネット環境等も鑑みると、会場は大分いいところを用意できたかなと思ってます。

色々なところで和田さんに頼りすぎてしまった感はあります。

受付、会場設営とか手順をあまり決めずになんとかなるで進めてしまって当日バタバタしてしまった。

デモのときはマイクを用意する。(声が聞こえないとのご指摘がありました)

デモのとき、見えにくいと突っ込まれてテンパリ過ぎた。(予めチェックするべきでした)

rm ~/.vimrc にどよめく会場 (ペアプロデモコードの見やすさのため) #tddbc

— Takuto Wada (@t_wada) June 15, 2013

LT用意しておけばよかった。。。

学生の参加者がそれなりにいてよかった。どういう経緯で参加したかちゃんとヒアリングしておけばよかったな、、、

会としては概ね良かった気がしています

自分の中のファインプレーは、懇親会の会費を3000円/人に抑えられたことですね。(参加費も頂いた上での懇親会の会費もかかってなんか申し訳なかったです。。。)

今後

今回のTDDBCで書いたコードを復習する会は希望者がいればやってみようかと考えてます。

今回のTDDBCでは結構な数のペアがgithubを使っていて、それがレビューするときに便利なのは改めて感じました。まだgithubに使い慣れていなかった人もいたので、福岡でgithubのハンズオンはまた開催しようかなと思ってます。やりたい人は声かけてください。

あと、自動化についても今のプロジェクトでJenkins使って色々やっているお話とかは出来るので、これもやりたい方いればご連絡ください。

そして

次は参加者としてTDDBCに参加する

これは絶対だな。。。

最後に

@t_wadaさん基調講演有難うございました！またTDDBC Fukuokaが開催される時はどうぞ宜しくお願いします。

@sue445さん、@a_suenamiさん TAとして福岡まで来てくださり本当に有難うございました！

@kisさんお忙しい中、TAでお手伝い頂き本当に有難うございました！あのLTはホント面白かったです。これからもよろしくお願いします。

@kuronekomichaelさん、@koichi222さんスタッフとしてお手伝い頂き本当に有り難うございます！

AIPさん、@murajunnさん AIPさんのご協力で準備等がスムーズにできました！！本当に有り難うございました！

参加者の皆様ご参加頂き本当に有難うございました！今回のTDDBCで質問等あれば、Twitterで#tddbcのハッシュタグをつけてつぶやくもしくは、FBのTDDBC Fukuokaのグループ(TAの方も入れちゃいました)で質問して頂ければと思います！

色々な人と話ができて、やっぱりまだまだ自分の勉強不足を痛感しました。。。 @kisに鍛えてもらおう

リンク

参加者のblog(順不同)

html5で作るスマートフォンのアプリ開発日記 TDD Boot Camp Fukuoka 2013に参加しました！

くりにっき TDDBC福岡にTAとして参加してきました

Log for Backup - Naoki_Rinの学習 TDD Boot Camp Fukuoka 2013に参加してきました

takato.log TDDBC Fukuoka ~１日目~

takato.log TDDBC Fukuoka ～二日目～

参加者のrepos(順不同)

itokami1123dev / wiki_tdd_study_20130616

kuronekomichael / javascript_qunit

kuronekomichael / samplewiki

yste / java_junit

yste / ruby_rspec

umakoz / ruby_rspec

sue445 / wikiengine-spock

TDDBC Fukuoka 2013で紹介されたページ等々(順不同)

JenkinsとGitとSpockで独り継続的インテグレーション

テストツールまるわかりガイド(入門編) PDFです

GithubにあるリポジトリをTravis CI連携する手順 #junitbook

技術書の「写経」の方法

XUnit Test Patterns

テスト駆動開発（TDD）の事例 - IBMとMS 計4プロジェクトを紹介した論文 -

随時追加していきますが、もれがあれば@Spring_MTまでご連絡ください

#tddbc

yuroyoro-blog

　「人間不信に陥るよ」。それまで不平不満も言わず、まじめに働いていたエンジニアがある時、急に態度を変える。IT業界における労使トラブルでよく耳にする話だ。決して労働環境が整備されているとはいえない業界にあって、こうしたトラブルはいま、現場で頻繁に起きている。今回、当事者となってしまった東京都内の事業者も、「話に聞いていたが、まさか自分がという思いだ」と打ち明ける。

...

リモートブランチ消すリスト

$ git branch -a --merged | grep -v master | grep remotes/origin| sed -e 's% *remotes/origin/%%'

unicorn_process_managerってのをGitHubに公開しました

社内で使ってるunicornのプロセス管理するスクリプトを公開してみました。 testとかほとんどないんでrubygemsには登録してないです。

SpringMT / unicorn_process_manager Github

restartしたときはこんな感じになります。

依存関係がないんで、どこでも使えるはずです(多分)。。。こういうプロセス管理のモジュールってどうやってテスト書けばいいのかなあ。

仕事中に書いたスクリプトはGitHubで公開するのをためらう文化というのがあるのを今知った。

2013年4月5日

うちの会社は大丈夫だよね。。。

#ruby #unicorn

fluent-plugin-ses書きました

fluentdからアラートメールを送りたかったのですが、メールサーバー立てるのが面倒だったので、AWS SESのoutput pluginを作ってそれから送るようにしました。

SpringMT / fluent-plugin-ses Github

fluent-plugin-ses RubyGems.org

使い方

confの書き方

conf 説明 aws_key_id Access Key Id aws_sec_key Secret Access Key from fromアドレス(SESでverifiedされているアドレス) to 送信先(少なくとも一つは指定、カンマ区切りで複数指定できます) cc ccのアドレス(オプションカンマ区切りで複数指定できます) bcc bccのアドレス(オプションカンマ区切りで複数指定できます) reply_to_addresses 返信先のアドレス(オプションカンマ区切りで複数指定できます) subject メールのタイトル

メールの本文は、plaintextformatterで整形されたログがそのまま貼り付けてあります。

その他

AWSのモック欲しい。。。。テスト書く時いつも悩ましい。

#fluentd #ruby #aws #ses

とある大学生の話を聞いて

テクニカルなネタをここには書いてきたけど、今回は違う感じで。

とある大学生と話してたら、"頭下げてまで日本の企業に就職したくない"と言ったので(ちょっと誇張したかな。。。)大分イラっとした。

日本ナメんなよ

海外の企業でちゃんと利益を出している企業がどれだけあるのだろうか。 (もちろんAmazonとかGoogleとかあるけれど、総体としてってことで) まあ、まだ就活前の人だしあんまり深くは突っ込まなかったけど、何でこんなに日本の企業を低く見てしまうのか。。。

あと、"海外に行ってみたい"って言ってた。海外に行って何が得られるのだろう。。。少なくとも日本の大学で"学ぶ"ということをするべきではないのだろうか。 (良い成績を取るってことではなく) 英語を勉強したいってのはわかるけど、大学生活を費やしてまでやることなのかな。。。大学ではもっと自分から学ぶことを学ぶのが必要なのではないか。 (自分が卒業した大学は少なくともそういうことを教えてくれた。)

折角、義務教育から開放され、自分の学びたいことを学びに行っているのになぜそれをしないのか。

まあ、日本の大学の限界って言われればそれまでなんだけど。。。

海外ってそんなにいいとこなんですかね？

勢いにまかせて書いたけど、まあちょっと気になったので。

bulknews-podcast

収録時間 41:20 | Download MP3 (23.5MB)

第６回は伊藤直也さん (@naoya_ito) をゲストに迎えて、Kindle 出版、GitHub、Google Reader などについて話しました。

bulknews

第１回に続き、naoyaさんに出てもらいました。

「非公式なAPI」

後半で出てくる Google Reader APIの話で、「野良API」って言葉を使ってますが、紛らわしい表現だったかもなので、ちょっと補足。

「野良API」というと第三者が無断でつくったAPI、のように聞こえるかもですが、そうではなく、「非公式なプライベートAPI」という方が正しいかも。

ここでいう非公式なAPI、というのは、Google Reader のウェブサイトが Ajax で使っているエンドポイントや、Google公式の Reader アプリが使っているプライベートAPIをリバースエンジニアリングしたAPI、という意味で使っています。仕様についても Google は一度も公開したことはなく、有志がリバースエンジニアリングした仕様をGoogle Code上で公開してるもので、これを feedly などは使っていた、という話です。

ゲストの人選

naoyaさんが２回めということもあって、「もう２周目」？とかTwitter で意見をもらったりしてます。

もともと、ゲストを週替りにしてインタビューする、という発想ではなくて、その時話したい「ネタ」があって、それに最適な人をキャスティングする、という発想をベースにしていました。MessagePack のissueの話、Ruby 2.0 のリリースの話、その開発者に聞くのが一番いいですよね :)

とはいえ、ネタにとらわれずに「いいとも」あるいは「徹子の部屋」的に人にフォーカスした回もあってもいいかなと思っていますし、ep4の高林さんの回なんかはそういう感じですね。

その辺もいろいろバランスをとってやって行きたいと思いますが、まだまだいろいろ試行錯誤ですので、フィードバックもらえるとうれしいです！

TDDBC Tokyoに参加して来ました

2013/03/16に開催されたTDDBC Tokyoに参加してきました。

主催の@katzchangさん、会場を提供してくださったVOYAGE GROUPさん本当にありがとうございました！

作業

お題はこちら

tddbc_tokyo_20130316

当日自分が書いたソースはgithubにあげてあります。

tddbc_tokyo_20130316

ruby2.0+rspecで書いています。一応travisにも対応しています。

振り返り

今回の課題はLtsvを扱うモジュールの実装でした。

この課題では"テストが、実装するメソッドに依存してもいいのか"ということに悩みました。メソッドAのテストを書くためにはメソッドBを使うと簡単に書ける、逆も同様。自分はテストは実装する他のメソッドに依存しないようにテストを書くようにしているのですが、今回はペアプロしていてそこを突っ込まれてどうしたものか悩みました。。。

今回は、テストするメソッドがインスタンス変数へアクセスするメソッドだったので、インスタンス変数を直接確認する方法を取りました(instance_variable_getとinstance_variable_setを使いました) でも、結局はっきりとこうしたほうがいいって自信がないまま終了してしまったので、後で相談したところ、

テストが実装する他のメソッドに依存するのは大丈夫

テストのために一時的にメソッドはやしたり、アクセッサを定義する方法もある(あとでちゃんと消すのが前提)

と教わったので、今回であれば実装順はこうしてもよかったなあと反省しています。

インスタンス変数のアクセッサーを作っちゃう

get(or set)のテストを記述

getが実装完了したらset書く

setのテストはgetに依存してもOK

setのテストが完了したらアクセサ消す

getのテストが落ちるのでgetのテストを書きなおし

まあでも、なるべく依存したくはないですね。

その他

TODOを作る時間に前半の時間のほとんどを割いてしまった。。。適度に考えて適度に手を動かすことが重要ですね！

あと色々な人のテストの経過が見えるのは良かったです。大抵ライブラリとかみても綺麗な状態になって出てくるので、TDDBCではテストを書く経過が色々見れて参考になりました。

普段テストは書いているのですが、もっとテストを効率よく書くためにテストについてもうちょっと勉強しないとなあって痛感しました。(テスト駆動開発入門とかリファクタリングとか読まないと。。。)

TDDBC Fukuoka

TDDBC Fukuokaを6月中旬頃に開催する予定です。まだ、詳細を詰めている段階ですが、2日間でガッツリ行う予定です。詳細が決まりお知らせします。

あと、TDDBC Fukuokaを開催する前に、github workshopをする予定です。 TDDBCではペアプロをするのですが、その際一台のマシンを使ってるとキーバインドやエディターの違いでペアプロしにくいだけでなく戦争が起こる可能性があるので、githubでソースを共有して自分のマシンでソースが書けると効率が上がりそうだからです。特にIDEがそこまで浸透していない言語(rubyとか)でよく起こるのでTDDBCに参加する前に一度githubの使い方workshopを開催してgithubを使ったコードのシェアに慣れてもらおうと思います。 (もちろんTDDBC参加しない人でも参加できるようにします！)

TDDBC Fukuokaの情報は下記FBグループにも流します。興味が有る方は是非ご参加ください(公開グループなので参加しなくても閲覧できます)。

TDDBC Fukuoka

最期に

2013/5/13にTDDBC 長岡が開催されます！詳細はこちらから

TDDBC長岡1.0

リンク

TDDBC

ペアプログラミング練習しよう

The Pragmatics of TDD

TDDしないケースについてのUncle Bobの考え

tddbc20030316

rspec-parameterized

2013/03/16 TDD Boot Camp Tokyo 2013-03 #tddbc

TDDBC Tokyo 2013-03 の参加レポートたち　#tddbc

#tddbc #rspec

Fluentd meetup in Fukuokaに参加 & 発表してきました

先日福岡で行われたFluentd meetup in Fukuokaに参加してきました！ (エントリが大分遅くなってしまった。。。) @tagomorisさんや@repeatedlyさんなど東京からモヒカン達が福岡に来襲して大分盛り上がりました!

Fluentd in Co-Work

Fluentd in Co-Workというお題で発表させて頂きました。スライドはこちら

Fluentd in Co-Work from Makoto Haruyama

ちょっと頑張って英語で書いてみました(誤植が大分あると思います。。。) 最近、Co-Workというサービスをリリースしたのですが、その中でFluetndをどのように使っているかを紹介しました。 Co-Workでは、ログ収集だけではなく、Queueingで使っているのですが、バッファリングがしっかりしているFluentdはログ収集だけではもったいないのでQueueing以外にも活用出来る部分があればどんどん活用して行きたいですね。

あと、自分が作ったfluentd-resque_statはこちらにあります。

SpringMT / fluent-plugin-resque_stat Github

fluent-plugin-resque_stat RubyGems.org

ダウンロード数はkanicounterを超えていて少し安心しましたwwww

他の発表

他の方のスライドは下記リンクにまとまってます。

Fluentd meetup in Fukuokaを開催しました @matsumana

Fluentd meetup in Fukuokaにいってきた＆しゃべってきた @tagomoris

@tagomorisさんのプラグインの類別は参考になりました。今後pluginを作る上で意識したいです。

最期に

東京から来ていただいた方たちには大層福岡を気に入って頂けたので、今後も福岡で色々勉強会が開催されると思います。

福岡まとめ

#fluentd

ruby 2.0とそれ以前でのconst_getの挙動の違い

ちょっとハマったのでメモ。

ruby 1.9.3 p327

ruby 2.0

ruby 2.0から const_get A::B みたいなことが可能になっている。

object.c L 1872付近にコードconst_getのコードがある。

MySQL Casual Talks in Fukuoka Vol.3を開催しました！

大分エントリー書くのが遅くなりました。。。 2013/02/24にMySQL Casual Talks in Fukuoka Vol.3を開催しました。今回は東京からMySQL Casual Talksの元締めである、@myfinderさんが参加してくださいました！今回もMySQL5.6の話題が満載でした。

「MySQL Casual Talks in Fukuoka vol. まとめ」をトゥギャりました。

@Spring_MTの前座

現在、co-workというサービスを運営しているのですが、このサービスのインフラ構築で取り組んだ自働化のお話を少しさせていただきました。スライドを作っていないので概要だけ。

AWS EC2の最初のサーバー立ち上げスクリプトの紹介

chef-solo & capistranoを使ったMySQLの構築

chef-solo & capistranoのツールは@fujiwaraさんのchef-solo + capistrano で複数ホストを管理するで紹介されていたツールをcockbookが指定できるように改造して使っています。

Casualムーブメントの話とMySQL Casualの話とMySQL 5.6の話(@myfinder)

前半はriakやRTB(Real Time Bidding)のお話。最近も色々Twitter上で盛り上がってるriakですが、大分筋よさそうですね。後半は今勉強会で盛んなcasualブームのきっかけと、東京でのMySQL Casual Talksの歴史を振り返り。

MySQL Casual Talks vol.2でぼっちだった自分が今やMySQL Casual Talks in Fukuokaを開催しているのが少し感慨深かったですね。こういうイベント他の地方でも開催するといいですよね！

MySQL 5.6 GAについて (@RKajiyama)

もうおなじみになってきた@RKajiyamaさんによるMySQL 5.6の紹介！ちょっと気になってたパフォーマンス問題ですが、下記リンク等でそんなことはないよって紹介されているとのことです。

Is MySQL 5.6 Slower Than MySQL 5.5? No, It's Faster

あと、paypalのMySQL Clusterの運用例はこちら

PayPal Big Data and MySQL Cluster from Mat Keep

DB技術[実践]入門を読んだ (@saisa6153)

現役大学生によるLT！！

DB技術[実践]入門を読んだ from Yuuki Tan-nai

まさにCasualって感じの発表でよかったです！今後は大学生とかもこんな感じで発表して欲しいです。

福岡のPerl WorkshopとMySQL Casualに行った

MySQL Casual Talks in Fukuoka vol.3 LT (@komiya kosuke)

201302 mysql casual_talk_v3 from Kosuke Komiya

MySQLをなぜ採用したかをまとめた発表でした。こういう、思考の過程を発表してもらえるとこれからMySQL使いたい人の背中を押してあげられてすごく良かったと思います。

Amazon RDSの注意所 (@ ayakomuro)

MySQL カジュアル福岡 03 from Aya Komuro

いろいろ話題になるRDS。 RDS使うか、EC2上に構築するか結構迷う人は多いと思いますが、RDSの使用上の注意がサクッとまとまってるお話です。

最期に

@myfinderさんの来福を支援していただいたJPA様本当に有難うございます！！ vol.1からmyfinderさんをお呼びしたいと思っていたので、本当に感謝です。

また、東京から来ていただいた、@RKajiyamaさん、会場をご提供していただいた日本オラクル株式会社様、本当に有難うございました。

お知らせ

今年もYAPCが開催されます！！開催地は慶應大学の日吉キャンパスです(会場のすぐ下にはhubがある充実っぷり)。講堂内は電源完備だそうです。詳細は下記リンクからどうぞ！

YAPC::Asia Tokyo 2013

#yapc #mysql

ruby2.0.0-p0をビルドしてみた

Ruby、20周年おめでとうございます！

そしてRuby 2.0.0-p0がリリースされました！

Ruby 2.0.0-p0 リリース

関係者の皆様本当にお疲れ様でした！

なので早速ビルドしてみました。

ruby2.0.0-p0をMac OSX でビルド(rbenv使ってます)

過去のビルドの失敗を踏まえてビルド

opensslのバージョンが古くて、ruby 2.0.0-preview1でbundle installがコケる

ruby 2.0 preview2 でbundlerいれてbundle installするとエラーな件

clang使えばビルドできました。

ruby-build + ccだとコケるっぽい?

Default CC=cc for broken Ruby 2.0 gcc detection on OS X

ビルドはこれで成功

gem install bundler

bundlerをインストールする

でエラーがでる。

Gem::ConfigFile にcheck_credentials_permissionsていう関数ができていて、ここで.gem/credentialsのファイルパーミッションcheckするようになっています。

ruby 2.0.0-rc1にはこの関数は無かったです(rc2は未確認)

なので、

chmod 600 .gem/credentials

すればgem installできるようになります。

bundle install

次はbundle install

bundle installするとSSLエラーがでる。

困ってたら@ryopekoさんが助けてくれました！

@spring_mt これですかね qiita.com/items/12457815…

2013年2月24日

homebrew で入れた openssl を使って Ruby をコンパイルすると SSL 利用時に証明書エラーが発生する場合の対応

この通りにやれば上手くいきました。

EC2(Amazon Linux)ではこの問題が起きないことは確認できました。

RUBYOPTとかで解消できないのかな、、

DEFAULT_CERT_STOREとかでなんかできそうな気がしてるけど時間がある時に試してみよ。。。。

bundle install完了して自分のアプリ(rails 3.2.12)に対してrspecを走らせたら全部テスト通りました！

まずは開発環境 + staging環境にぶっこんで様子見るかな

#ruby

mirakui-diary

レガシーコードを糾弾する人は、そのコードがもたらす不利益ばかりに目を向けがちだけど、そのコードがどれだけ価値を生み出してきたのかに敬意を払うべき。最新の技術と価値観で、古きものを貶めるのは簡単だけど、古くて、汚くて、でも沢山稼いだコードは、すごく尊いものだと思う。何で古くなってしまったのか、なんで汚くなってしまったのかを考えるべき。経済的な価値を生む事が工学の本質だし、美しくあり続ける事を目的にするのはアートであってもエンジニアリングではない。

Fluentd Casual Talk #2でLTしてきました

2013/02/15に開催されたFluentd Casual Talk #2で"fluent-plugin-resque_statを作ってみた"というお題で発表してきました。

fluent-plugin-resque_stat from Makoto Haruyama

fluent-plugin-resque_statの話はほとんどないですwwww トークの流れ的にtagomorisさんをdisった感じになってしまった。。。(まあウケたしいいか) 内容は、out_execとかで外部のスクリプト呼び出す位なら、プラグインにしてテスト書こうよ！ってお話です。 ## その他 @sonotsさんのお話でmina使ってて、結構簡単に扱えるとのことなので、ちょっと試してみようかなと思ってます。 haikanko githubに出して欲しいっす！ @angostura11さんの話は復習したいので、スライドあがらないかな。正直esperあんまりよくわかってない。。。あと、fluentdと全く関係ないですが、隣に座ってた@ijinさんから[sidekiq](https://github.com/mperham/sidekiq)っていうのを教えてもらいました！ Sidekiqはシングルプロセスでマルチスレッドで動きます。(Resqueはマルチプロセス)

#fluentd

fluent-plugin-resque_statってのを書いてみました

[resque](https://github.com/defunkt/resque)を使ってるのですが、resqueの残ってるキュー数をfluentdで取得して、growthforecastでグラフにしたかったので、fluent-plugin-resque_statっていう、fluentdのinputプラグインを書きました。 * [SpringMT / fluent-plugin-resque_stat Github](https://github.com/SpringMT/fluent-plugin-resque_stat) * [fluent-plugin-resque_stat RubyGems.org](https://rubygems.org/gems/fluent-plugin-resque_stat) 最初はexec_filterでスクリプトを叩いて取得しようかと思ったのですが、スクリプトがかなり短くなるし、resqueの情報はrubyで簡単に書けるので、もういっそのことpluginにしちゃえって思って作りました。プラグインは[in_exec.rb](https://github.com/fluent/fluentd/blob/master/lib/fluent/plugin/in_exec.rb)や[fluent-plugin-dstat](https://github.com/shun0102/fluent-plugin-dstat)を参考にして書きました。 ## 使い方こんな感じでconfに設定書きます。 conf | 説明 | default | ---|---|---| host | resqueが動いてるredisのhost | 127.0.0.1 | port | resqueが動いてるredisのport | 6379 | run_interval | 情報を取得する間隔 | 60 | ### 取得できる値 fluent-plugin-resque_statで取得できる値はResque.infoで取れる値と同じです。取得可能な値とその説明は下記の通り。 key | 説明 | ----|----| pending | キューの残数 | processed | 取り出したキューの総数 | queues | 登録されてるキューの名前の総数 | workers | キューを取り出すworkerの数 | working | キューを処理中のworker数 | failed | 失敗したキュー数 | servers | resqueが動いてるサーバーのhostやportの情報 | environment | fluent-plugin-resque_statが動いているサーバーの RAILS_ENV or RACK_ENV(なければdevelopmentが入る) | #### 参考 * [Resque で学ぶジョブキューイング](http://perl-users.jp/articles/advent-calendar/2012/casual/12) 今はまだグラフに出してなくて、ikachan pluginでircに流しているだけです。 ## その他テストはrspec使って書いてみました。 @repeatedly さんpull req有難うございました！

#fluentd #resque

Trending Blogs

Recently Viewed Blogs

SpringMT