#fluentd のためのプラグインをイチから書く手順(bundler版) - tagomorisのメモ置き場
前に自分で書いた fluentdのためのプラグインをイチから書く手順 - tagomorisのメモ置き場 はたいへん重宝していたのだが、書いたすこし後になって実は現在すでに bundle gem コマンドを使うやりかたが良さそうだということがわかってしまったがばたばたしてて移行してなかった。 で、またひとつプラグインを書くことにしたのでついでに bundle を使った手順をざっくりまとめておく。以下のエントリをたいへん参考にさせてもらった。 T-POINTを取得するスクリプトをGistから移動, Bundlerを使ったGem作成メモ (自分用) - ただのにっき(2012-02-18) 準備とディレクトリツリーの作成 bundler は必要なので、なにはなくとも入れておこう。 gem install bundler そしてプラグイン用ディレクトリツリーを作成する。今回は DataCount
尊重されたいすべてのソフトウェアエンジニアへ - たごもりすメモ
自分はソフトウェアエンジニアとして毎日の糧を得ている。今のところはサラリーマンエンジニア以外の存在になる予定はない、が、とはいえ唯々諾々とつまんない仕事ばっかりやる毎日はできればごめんだと思っている。コードを書くのは楽しいからコードを書ける仕事をしたいし、特に面白い問題やまだ誰も手をつけてなさそうな問題を解決する仕事ができれば最高だ。 つまり、そう、尊重されたい。自分のやれること、やりたいことを尊重されるようになりたい。自分がやった仕事には価値があると思われるのは嬉しいし、そのように(勤務先以外の)他人から認められれば面白い話も聞けるようになるかもしれない。尊重されるソフトウェアエンジニアになれれば楽しそうだ。 尊重されるソフトウェアエンジニアであれば、もしかしたら自分の仕事についてある程度の自由が効くかもしれない。突然わけのわからない政治でがんじがらめの炎上プロジェクトのPMをやってこい
#fluentd 用ログ収集専用のエージェント fluent-agent-lite 書いた - たごもりすメモ
みんな大好きfluentdはたいへん便利ですが、ログの収集＆集約だけをしたい、というときにちょっとオーバースペック気味のところがあります。特に in_tail はログの読み込みと同時に parse をする仕組みになっており、まあログが書かれた場所ならparseのルールもわかってるでしょ、というところは合理的なものでもあるのですが、loadavgが高いサーバでそういうことをするのは正直にいってなかなか厳しいです。 そういうわけで以前に scribeline というエージェントツールを作ったのでこれを fluentd 以降後も使い続けていたのですが、ログをいったん集約するところの fluentd がCPU使用率的にいっぱいいっぱいになって厳しいものがありました。「scribe(Thrift)じゃなくてMessagePackにすれば倍くらいさばけるよ」ということを某開発者が言っていたような気もす
fluent-plugin-flowcounter および fluent-plugin-growthforecast released! #fluentd - たごもりすメモ
Fluentd自体の動作状況を数値化するための fluent-plugin-flowcounter およびメトリクスを手間なくグラフに描かせて可視化するための fluent-plugin-growthforecast をリリースした。 fluent-plugin-flowcounter rubygems.org github fluent-plugin-growthforecast rubygems.orgy github このふたつを組合せると、こないだの Fluentd meetup で自分が出したこんなグラフやこんなグラフが誰でもじつに簡単に描けるようになり、自分のFluentd使用状況が明確に把握できるようになるというわけですね。超おススメです。 なおGrowthForecastについては kazeburo さんのこのエントリを読むのがよいと思います。じつに良いツールです。 Gro
#fluentd meetup in Japan に行ってきた＆しゃべってきた - たごもりすメモ
Fluentd meetup in Japanなるイベントをやるけどしゃべらない？ というお誘いがあったのでありがたくお受けして参加し、1セッションしゃべってきた。 まだ世に出て半年足らずのミドルウェアのイベントなのに集いも集ったり120人*1、まるまる半日間ひたすら高濃度な時間だった。話してみると、みんなfluentdがフォーカスしてるあたりにやっぱり問題意識をもっていて、ああやっぱりこれは出るべくして出たのだな、という印象だった。 あとからtogetterのまとめページも見たけど異様に長い。どんだけ盛況だったかがわかる。開催時間中、Twitterの日本のトレンドに #fluentd が出てたしな。 会場がほんとにすばらしく、運営もUstreamや無線LAN解放、電源の確保から飲み物提供まで極めて良い状態だった。主催や運営協力の方々およびフューチャーアーキテクト様、ほんとうにありがとうご
2011年を振り返ってみる - たごもりすメモ
思えば、年頭から年末までずっとプログラマとして生活してた。世間的にいろいろあったし自分が受けた影響も決して小さくはなかったけど、プログラマとしてのみ見ればだいぶ充実した年だった。 2010あとしまつ期、ログ収集・解析初期 1月 2月 3月 あるいはscribed/hadoop/hive導入期。この頃、次の仕事はログ収集だー、ということであれこれ始める。実は当初は解析まわりを自分でやることになるとは思ってもみなかったのだが、あれこれあってHadoopを触りはじめて今に至っている。 ホスト管理アプリケーション yabitz (ヤビツ)のコードを公開した - tagomorisのメモ置き場 社内で使うために書いて、いまも元気に動いているツール。ちょこちょこメンテナンスや機能追加などしてたりする。最初はあまり大きなツールにならないだろうと思ってsinatraで書きはじめたんだけど、これは明らかに失
simpleoauth-gae直しながらTwitter APIと戯れる - たごもりすメモ
simpleoauth-gaeを前の記事の時点以降で実用するのにちょっとずつ直してるんだけど、あれこれあったのでメモ程度に書いておく。要約するとTwitter APIに対するapi.twitter.comの挙動ヒドいっす。ゆるふわAPIとか言い得て妙すぎる。 23日前後の状況 前に書いて放り込んだときには、RequestTokenおよびAccessTokenの取得時に以下のようになってた。リクエストのパラメータに入れるのか署名に使うのか、あたりの細かい話は省略。 RequestToken取得時 oauth_callback_urlは指定しない api.twitter.comへのリクエストには以下を使用 Consumer Token および Consumer Secret AccessToken取得時 ユーザがTwitter.comで認証を済ませたあと戻ってくるときのパラメータに oauth
テストケースのベースクラス GAETestBase を作った - たごもりすメモ
前に書いた記事からはやくも半月たってしまったが、やっと出してもいいかなという状態になったので公開します。ファイルそのものはこちら。 GAETestBaseはPython標準のunittest.TestCase継承クラスとなってます。ユニットテストを書く際に、通常のTestCaseのかわりにGAETestBaseを継承してユニットテスト用のクラスを作り、あとは普通にテストコードが記述できます。 PythonおよびAppEngine SDK以外への依存がゼロで環境を選ばない、はず、なのが売りかな？ ところで出来上がったあと公開用の準備をやってたら、GAE/J側ではslim3がkotoriを組み込んだという話が。おおお。 できること CLIでのテスト実行 開発中のテスト実行が、Python標準のunittestと全く同じようにCLIから実行できます テストケース側で指定があれば各サービスはrem
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
