Fluentdとはどのようなソフトウェア「ではない」のか - tomykaira makes love with codes
2013-12-04 Fluentdとはどのようなソフトウェア「ではない」のか Fluentdとはどのようなソフトウェアなのか - たごもりすメモに触発されて。 設定が簡単なのに惹かれて Fluentd を利用したら、ひどい目にあった。 でもそれは我々のソフトウェアへの理解が不十分だったから。 最初の段階で気が付いていたんだけど、 quick fix で動きそうだからそのまま突き通してしまい、結局ダメになった。 自分でつかってみた人は、だれもそんな使い方しねえだろって思うだろうけど、噂しか聞いていない人はおなじ間違いすると思う。 Fluentdとはどのようなソフトウェア「ではない」のか Fluentd は「リアルタイム転送のためのツールではない」。 リアルタイム処理のためにつかったら破綻する。 なぜ使えないか そもそもの転送速度が低速 (MQ 系や memcached のプロトコルと比較し
レビューフレンドリーな開発のしかた - tomykaira makes love with codes
2013-09-02 レビューフレンドリーな開発のしかた git dev 最近は多くのチームでレビューの習慣が定着してきました。おもにレビュアーとしての仕事を依頼されることもあります。 コミット・ブランチの作りかた一つでこのレビューのしやすさが格段に違ってきます。 自分が普段の開発でこころがけていることをまとめてみます。 前提 レビュイーとレビュアーの間に上下関係があるわけではないですが、レビュイーは多少手数が増えても、レビュアーのことを最大限配慮すべきです。 なぜなら、レビュイーはその機能の開発に集中して取り組んでいますが、レビュアーはすこし見るだけです。 なにかするとしたら、レビュイーがやったほうが時間も手間も少なくなります。 レビュアーはレビュイーよりも、変更について詳しくありません。 レビュイーは開発にいろんな部分を見てまわり、他のモジュールとの関連性や実装のこまかな意図を把握して
Rails の validation 論争批判 - tomykaira makes love with codes
2013-07-10 Rails の validation 論争批判 Rails 容赦なく批判するので、気分悪く思う方は読まないでください（後半だけよむといいかも）。 twitter での議論は、徳丸さんがまとめられている分はみましたが、それ以外は見落としがあるかもしれません。 TL; DR: これまでの議論は教条的であり、技術を誤解したうえで過信している。 バリデーションは広い意味をもつが、重要なドメインについての観点が見落とされている。 技術者として、なにが必要で、どう実装すべきか自分の頭で考えよう。 validation (バリデーション) とは バリデーションとは 【validation】 〔バリデート〕 - 意味/解説/説明/定義 ： IT用語辞典 検証(する)、実証(する)、認可(する)、妥当性確認、などの意味を持つ英単語。ITの分野では、対象がその仕様や文法などに照らして適切
Rails のモデルはどうあるべきか - tomykaira makes love with codes
2013-07-05 Rails のモデルはどうあるべきか rails TL;DR: Rails の model が太りやすいのは、生まれつき責務過剰だから。開発者が設計段階で責務を絞り、食べる量を減らしてあげよう。 Rails の model というのは、概念も実装も、とても奇妙な使われ方をしている。 いささか不気味だし、実害もある。 fat model はずっと Rails 界で話題になりつづけている。 すでに Rails のプロフェッショナルは抜け出せているのかもしれないが、まだ議論の余地のある話題ではあるようだ。 なぜ model が太るかというと、なんでもかんでも model に食べさせるからである。 一日中食べてれば元々どんなにスレンダーでも太るに決まってる。 コードのダイエットは食べる量を減らすか、外に出すしかない。 太ってから外に出すのがリファクタリングである。 後知恵的に
RSpec を効率的に記述するために yasnippet 紹介 - tomykaira makes love with codes
2013-06-18 RSpec を効率的に記述するために yasnippet 紹介 ruby rspec rspec は testing framework のなかでは簡潔な記述ですが、それでもテストを書いていると繰り返しが多くなる。 とくに its の連続などはなかなか手でやっていると大変。 私は基本的に emacs で補完をつかって書いている。 hippie-expand と yasnippet を併用しているが、 yasnippet のスニペットは rspec 環境で悩んでいる人に役立ちそうなので公開する。 https://github.com/tomykaira/rspec_yasnippets タイトルが key で展開先が code block という形でいくつか紹介してみる。 一行展開系 it や describe before などの非常に頻繁に使うメソッドを展開する。
Rails、あんたなんか嫌いよ - Rails での OO 設計について - tomykaira makes love with codes
2013-06-25 Rails、あんたなんか嫌いよ - Rails での OO 設計について ruby rails 最近はずっと Rails 書いてるんですが、書けば書くほど嫌いになってくるんです。 倦怠期的なやつなんですが、 Rails さんの悪いところばっかり見えてきて、もう一緒にいたくないんです。 でも別れるほどじゃないし… という愚痴にみせかけた Rails での設計についての議論です。 長いけどコードは一切出てこないので通勤中にでもよんでください。 注意 一部にはげしい言葉遣いがでてくるので、読んで不快になるかもしれません。 不快になったとしても責任は負いかねます。 次のような方の期待に沿う結論はでません。残念でした。 Sinatra, Padrino の人 関数型の人 静的型付けの人 C の人 TL;DR Rails にだまされない。 自分の道を見定める。 欺瞞にみちた Ra
RSpec で parameterized test を簡単に書ける、rspec-parameterized を作成しました - tomykaira makes love with codes
rspec-parameterized | RubyGems.org | your community gem host tomykaira/rspec-parameterized次のような spec が書けます。 describe "plus" do where(:a, :b, :answer) do [ [1 , 2 , 3], [5 , 8 , 13], [0 , 0 , 0] ] end with_them do it "should do additions" do (a + b).should == answer end end with_them :pending do it "should do additions" do (a + b).should == answer end end end -fd をつけて実行すると次のような感じで出力されます。 RSpec::Pa
camelize.el をバージョンアップしました - tomykaira makes love with codes
-emacs- CamelCase なんてもういらない - tomykaira makes love with codes でご紹介した camelize.el をバージョンアップしました。単体でのファイルの見栄えがよくなったのと、先頭の文字のケースを保存するようにしました。 いままで: method_name_should_be_camel_case() → MethodNameShouldBeCamelCase() 変更後: method_name_should_be_camel_case() → methodNameShouldBeCamelCase() Class_name_should_start_with_caps() → ClassNameShouldStartWithCaps() これで、先頭の大文字/小文字が直観的に使い分けられます。 大文字ではじめて snake_c
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[emacs] CamelCase なんてもういらない - tomykaira makes love with codes