out_exec_filter 入出力フォーマットの変更による負荷の変化 - たごもりすメモ
まず前置きですが、みんな大好きFluentdがなぜ*1実用上充分なくらい高速に動作するかというとそれは内部のシリアライズ/デシリアライズフォーマットとして使われているMessagePackのおかげによるところが大きいわけですね。 ところで Fluentd の組込みプラグインのひとつに out_exec_filter というのがありまして、これは任意のプログラムを子プロセスとして実行し、そのSTDIN/STDOUTにFluentdのメッセージを通すことでどんな処理でも記述可能なフィルタとして使いましょう、というやつ。 これは当初はTSVしかサポートしてなかった*2んだが、対応フォーマットがいくつか増えていまではjsonとかmsgpackでも入出力可能になっている。もちろん外部プログラムの側でもjsonやmsgpackを読み書きするように書かれてないといけない。 さてお仕事でこの exec_f
BPStudy 40 に行ってきたよ＆しゃべってきたよ - たごもりすメモ
最近勉強会だのハッカソンだのにいくつか行ったけど、書いてないなあ。反省。あちこちですごく面白い話を聞きまくってます。社内のTechMeetingでも一度しゃべったけど、それはプロダクトを公開できる状況になったらスライドもいっしょに公開できる……はず。 で、表題の通りBPStudy#40 : ATNDに参加して、しかもふたつめのセッションではしゃべりました。なんと毎月開催し続けて40回！というタイミングで声をかけていただいて、ありがたく時間をいただきました。楽しかった。 なお、自分のTwitter/blogプロフィールのアイコンは素顔がほとんどわからず、他に特徴的な外見もないもんで、初対面の人にほとんどわかってもらえないという悔しさを最近抱えてた。ので今回はネタに走り、写真そのままのヘルメットとサングラスを装着して会場入りするという暴挙を実行に移しました。 受付の背後あたりにいたので、来る人
MessagePackのIETFへの提案に関する困惑 - たごもりすメモ
MessagePackというオープンソースプロジェクトの現状と IETF による標準化について、それが果たして正しいのか、と困惑せざるをえない事態が起きているので、それについて簡単に書く。何が起きているのか知らない人々に少しでも知ってもらえたら嬉しい。 なお、自分はMessagePackのユーザであって開発者ではない。MessagePackを使ったコードを書いて動かしているが、MessagePackそのもののデータフォーマットについて詳細まで知っているわけではないし、MessagePackの改善については特にいいアイデアを出せる気もしない。 現バージョンのMessagePackについてとりたてて不満はなかったが、最近文字列型を加えよう、あるいはもっと楽に文字列を扱えるようにしよう、という話が出てきた。JSON的に楽に扱えて更にバイナリデータを投入できるフォーマットの需要そのものは理解できる
fluent-plugin-esper構想概略 - たごもりすメモ
Fluentd Casual Talks #2 で聞いた fluentd + esper によるCEP実現の話が非常に素敵な感じで、自分の手元でもああいう感じで書きやすく投入しやすいストリームクエリがやりたくてしょうがないお年頃なので、以下のようなものを作ろうかと考えている。勢いあまって(まだ1バイトも書いてないのに) the RubyKaigi 2013 のCFPにsubmitしてしまった。通ったら何がなんでも2ヶ月くらいで書いて動かさないといけない。 ということで以下のようなものを作ろうかと考えている。この内容は Fluentd Casual Talks #2 の懇親会でFluentdコミッタ陣と @angostura11 さんとで頭をつきあわせてゴニョゴニョ話していた内容で、100%自分で考えたものでないことは最初に記しておく。だいたいそもそものアイデアは @angostura11
第2回NHNテクノロジーカンファレンスでしゃべってきた - たごもりすメモ
勤務先が主催でNHNテクノロジーカンファレンスという技術者向けイベントをやってるんだけど、その登壇者として社外の誰かから推薦されたらしいので(何故……)、ひとセッションしゃべってきた。なお「HBase at LINE」の発表は「HBaseについて誰かいない？」と主催の伊勢さんに聞かれたのに自分が推薦しました。みんなありがたがるといいよ。 他の人の話も、懇親会でのあれやこれやも大変楽しかった。HBaseなー、火山かー、みたいな。そのうち techblog にまとめエントリが上がるんじゃないでしょうか。それまでこっちでも見ると当日の状況が多少なりわかるかもしれません。 第2回NHNテクノロジーカンファレンス #nhntech まとめ - Togetterまとめ で、自分がしゃべったときのスライドはこちら。(slideshareのembed用タグを埋めてもはてなダイアリーに弾かれてしまう…… 対
尊重されたいすべてのソフトウェアエンジニアへ - たごもりすメモ
自分はソフトウェアエンジニアとして毎日の糧を得ている。今のところはサラリーマンエンジニア以外の存在になる予定はない、が、とはいえ唯々諾々とつまんない仕事ばっかりやる毎日はできればごめんだと思っている。コードを書くのは楽しいからコードを書ける仕事をしたいし、特に面白い問題やまだ誰も手をつけてなさそうな問題を解決する仕事ができれば最高だ。 つまり、そう、尊重されたい。自分のやれること、やりたいことを尊重されるようになりたい。自分がやった仕事には価値があると思われるのは嬉しいし、そのように(勤務先以外の)他人から認められれば面白い話も聞けるようになるかもしれない。尊重されるソフトウェアエンジニアになれれば楽しそうだ。 尊重されるソフトウェアエンジニアであれば、もしかしたら自分の仕事についてある程度の自由が効くかもしれない。突然わけのわからない政治でがんじがらめの炎上プロジェクトのPMをやってこい
Fluentd Casual Talks 開催してきた＆しゃべってきた - たごもりすメモ
なんとなく思い付いたら各所の協力を得られましたので、そのまま開催してしまいました。 勉強会を主催するのは初めて*1だったのですが、会場をお貸しいただいた株式会社ディー・エヌ・エー様、ならびに当日運営をまるっとお手伝いいただいた @riywo さんをはじめDeNA社員の皆様のおかげで全く問題なく、すばらしいイベントになりました。本当にありがとうございました。 またUstream中継については @ixixi さんにご協力をいただきました。たいへんな作業だと思いますが、本当にありがとうございました。 Fluentd Casual Talks : ATND 金曜夜に100人を超える参加者が見事に集まりまして*2、Fluentdを実際に使ってみた系の人々が大いにしゃべってました。個人的にはあれやこれやと面白い話がたくさん聞けたので、それだけでもう満足。SDのFluentd特集との内容のカブりについて
続 #fluentd の性能・リソースに関する最近のいくつかの傾向の話 - たごもりすメモ
前回の話から、メモリについては西海岸方面の協力を得てあれこれ試していた。 #fluentd の性能・リソースに関する最近のいくつかの傾向の話 - tagomorisのメモ置き場 最終的には ruby 1.9.3-p125 + jemalloc + fluentd v0.10.16 でメモリ使用量が安定した。 jemallocについてはこのあたりを読むといいんじゃないでしょうか(自分で説明するのはめんどくさいｗ) jemallocとかLD_PRELOADについて調べてみた - As a Futurist... 結果、ピーク時間帯になっても used 6GB に行かないくらい。ワーイヤッタヨー。 ということでjemallocは社内用rpm*1を用意し fluentd 起動用のshファイル(supervisordからこれを指定して起動している)を以下のようにした。LD_PRELOADを加えただけ
#fluentd な今だからこそふりかえる scribed のすべて - たごもりすメモ
最近 fluentd というツールのことがたいへんよく話題に上がっており、かく言う自分もささやかながら使用している身なのだが、それはそれとして比較対象に上がってくるツールに scribed というものがある。これがどういうものなのか、話には聞いていてもよくは知らないという人が多いようなので、これもささやかながら触ってみている自分としてはここらで一度まとめておかねばなるまい、と思った次第である。 日本全国に10人くらいはいるかもしれない scribed のヘビーユーザ各位に捧げる。 なお記憶と経験だけを頼りに書き殴るので、意思決定の重要な局面とかで「これこれこういうブログにたごもりすなる者がこのようなことを書き残しており」などと引用するのはくれぐれも避けていただきたい。 また途中から思いっきりビール飲みながら書いたので文章自体の品質にも問題のある可能性がある。 そも scribed とは何か
UserAgent判定器 Project Woothee はじめました - たごもりすメモ
UserAgent判定ライブラリはCPANに数多くあるし他の言語でも似たようなものだと思うが、ライブラリや言語をまたがって一致した結果を返してくれるようなものは存在しない(と思う)。が、特にHadoopを使うようになってJavaの事情をある程度無視できなくなってくると、これがたいへん問題に思えてきた。Javaで書かれたUserAgent判定ロジックが欲しいが、普段書くコードはJavaではない*1ので、他の言語でも全く同じように判定してくれるライブラリが欲しい。結果が食い違っていたり、新しいUserAgentを判定したいときに片方だけ対応されて片方は置き去りになったりすると大変困る。 ということで、作った。v0.1.0。現状ではJavaとPerlの実装がある*2。 https://github.com/tagomoris/woothee https://github.com/tagomori
いっしょに仕事をしたいプログラマ 5つの特徴 - たごもりすメモ
ちょっとこんなことを考えるきっかけがあったので、ざっと書き出してみた。Webに公開されている情報からあるプログラマについて見てみたとき、どういう人ならいっしょに働いてもいいかについて。 ここに書く内容はソースコードの品質以前の問題についてのみにしてある。だからこの特徴を満たしていればどうということに直接なるわけではない。ただ、欠けているところがあれば、少なくとも自分はその人といっしょに仕事をしたいとは思わないだろう。 なお自分は現勤務先の採用活動にはかかわっておらず、このエントリの内容は勤務先の採用基準とは全く無関係です。 学生さんなどの場合にはまた話が違うと思います。 あと割と自分のことは棚に上げてます。「お前これできてねえじゃん」という部分については都度ご指摘をいただけますと大変ありがたく思います……。 1. その人が書いたソースコードが公開されている 日本語で何を言われてもぶっちゃけ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
