Fluentdとはどのようなソフトウェア「ではない」のか - tomykaira makes love with codes
2013-12-04 Fluentdとはどのようなソフトウェア「ではない」のか Fluentdとはどのようなソフトウェアなのか - たごもりすメモに触発されて。 設定が簡単なのに惹かれて Fluentd を利用したら、ひどい目にあった。 でもそれは我々のソフトウェアへの理解が不十分だったから。 最初の段階で気が付いていたんだけど、 quick fix で動きそうだからそのまま突き通してしまい、結局ダメになった。 自分でつかってみた人は、だれもそんな使い方しねえだろって思うだろうけど、噂しか聞いていない人はおなじ間違いすると思う。 Fluentdとはどのようなソフトウェア「ではない」のか Fluentd は「リアルタイム転送のためのツールではない」。 リアルタイム処理のためにつかったら破綻する。 なぜ使えないか そもそもの転送速度が低速 (MQ 系や memcached のプロトコルと比較し
Pry が入っていない bundler 環境でも pry を使う - tomykaira makes love with codes
2013-08-02 Pry が入っていない bundler 環境でも pry を使う pry irb Gemfile をつかってライブラリを管理しているプロジェクトで、 pry が Gemfile に書かれていないと、当然 Pry は使えない。 OSS のプロジェクトでは勝手に Pry を入れることはできない。 そもそも、 Pry を Gemfile に書いて強制するのは、開発者に zsh を使うことを強制するようなもので、態度として良くないと思う。 各自が使いたいツールを使うことができ、必要最低限のものだけをインストールするようにしたい。 bundle exec irb で irb を起動したときでも、もしローカルに Pry が入っていれば、そっちを使うように設定した。 Pry Everywhere に掲載されていたスクリプトが rbenv 環境では動作しないようだったので、より一般的
Ruby (とか直和型がない言語)でも case の網羅性をテストしたい - tomykaira makes love with codes
2013-07-17 Ruby (とか直和型がない言語)でも case の網羅性をテストしたい test 状態コードがあって、もとは waiting, running, exited だったところに、新しい状態 failed を追加するような場合を考える。 直和型がある言語 (Haskell, OCaml, Scala など。strictly typed functional language に分類される言語が中心) なら、 直和型に要素を追加したとき、ワイルドカードを書いていないすべての case 文で警告が出る。 C や Java では生の数値や enum で状態コードを扱い、 ruby ではシンボルや文字列で扱うのが一般的である。 これらの言語では網羅性をコンパイラがチェックするようなサポートは提供されない。 Ruby に至ってはコンパイルが実行直前まで行なわれない! Ruby の
continuous commit のお供、git rebase を決定的に刷新する最強ツール Uchronie をリリースしました - tomykaira makes love with codes
2013-07-13 continuous commit のお供、git rebase を決定的に刷新する最強ツール Uchronie をリリースしました Scala Git いままで git rebase -i に何度泣かされたことでしょう。 git は最高のツールですが(他の SCM に勝るという意味ではありません)、あれは非常に出来がわるい。 テストを回すたびに自動コミットする continuous commit のプラクティスを採用している私達にとって、 interactive rebase は頭痛の種でした。 (continuous commit については Continuous Commit (kyon_mm さんの発表資料)、最近の git の使い方について - tomykaira makes love with codes など)。 git-rebase--interact
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 に食べさせるからである。 一日中食べてれば元々どんなにスレンダーでも太るに決まってる。 コードのダイエットは食べる量を減らすか、外に出すしかない。 太ってから外に出すのがリファクタリングである。 後知恵的に
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 を効率的に記述するために 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 などの非常に頻繁に使うメソッドを展開する。
Response to "7 Patterns to Refactor Fat ActiveRecord Models" - tomykaira makes love with codes
2013-06-02 Response to "7 Patterns to Refactor Fat ActiveRecord Models" rails This is the English version. The Japanese version with the same content is at the bottom of this article. Original article: 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog The video of presentation recorded in RubyKaigi 2013, 2nd day The problem -- Where they should be? "7 Patterns to Refactor Fat Acti
複数の例外を別の例外にして送出し直す速度比較 - tomykaira makes love with codes
2013-06-05 複数の例外を別の例外にして送出し直す速度比較 ruby あるメソッドが複数種類のエラーを上げてくるので、それをまとめて別の種類のエラーに読みなおすという場面がある。 たとえば Rails で ActiveRecord が上げてきたエラーをコントローラで扱いレスポンスを操作するためのエラーに読み替えるとか、 通信ライブラリのエラーをアプリケーション内の対応するエラーに読み替えるとか。 この書き方がふたつあって、どちらが速いか。 私は rescue 文の連続より case のほうがコストが低いので、 B のほうが速いと予想した。事実そのとおりだった。 (この例ではまとめて捉えてしまって StandardError(ex.message) ひとつで済むわけだが、当然、中身の処理がちがう場合を想定している)。 A begin err = [AError, BError, CE
テストを parallel_tests の2倍以上高速にする Qspec - tomykaira makes love with codes
2013-06-02 テストを parallel_tests の2倍以上高速にする Qspec ruby rails qspec テストが遅いので parallel_tests で高速化しようとしたが、効率わるすぎて腹がたってきたのでより効率的な Qspec をつくった。 いくつかの rails プロジェクトでベンチマークしたところ、2倍以上の高速化効果が得られた。 高速化に貢献しているのは次の要素。 テストファイルのふりわけを Redis 上の Queue をつかって動的におこなう。 Spork ですべてのテスト実行プロセスを事前に起動する GC を切る(ファイルごとに有効にして明示的にGCするので、十分なメモリがあればたいてい問題なく動作する。capybara 系をつかうとあぶない) ダウンロード & インストール: tomykaira/qspec · GitHub くわしくは #ru
git + percol(anything on terminal) が便利 - tomykaira makes love with codes
2013-05-12 git + percol(anything on terminal) が便利 git percol git ではよく sha-1 を入力させられる場面がある。 branch や tag がついている場合はそちらを使えばいいが、たとえば「さっきのコミットでなにを変更したかみたい」というような場合、 一度 git log を起動し、commit id を確認するなり、 HEAD からの距離を確認して、 git show を再度実行するということになる。 HEAD からの距離がとおいと sha-1 指定することになり、わざわざマウスに手をのばしてコピー&ペーストしなきゃいけないかもしれない。 はじめから HEAD^^ みたいに指定できればそれでもいいが、2つ以上前になると、大体いくつ前だかわからないし、まちがって何度も再実行するのもイライラする。 見るだけなら gitk な
使う rbenv-gemset をスクリプト内で指定する - tomykaira makes love with codes
2013-04-09 使う rbenv-gemset をスクリプト内で指定する ruby rbenv rbenv-gemset rbenv の gemset をつかうと、ちょっと試したい gem をグローバルの gem list を汚さずに利用できる。 rvm の gemset とほぼ同等の機能を提供するが、使い勝手がすこしちがい、 rbenv のほうがスクリプトをもちいた拡張に向いている。 複数の gem に依存する大きなプロジェクトやスクリプトを配布する場合は、 gem するか、bundler を使えばよい。 しかし、すこし試したい場合や普段づかいの書く場合にいちいち gem するのは面倒である。 かといって、グローバルの gem list にいろいろ入れると、散らかっているようで気分がわるいし、再セットアップのときになにを入れたらいいのか分からなくなりうる。 そこで、 rbenv-g
factory_girl と database_cleaner を使って Unit Test を独立させる - tomykaira makes love with codes
thoughtbot/factory_girl : 人気の fixture replacement library。fixture だと毎回リセットするのに手間がかかったりするところを、そのテストで必要なデータだけを生成できる。データも DSL で書ける。 bmabey/database_cleaner : テスト終了時にデータベースを綺麗にしてくれるもの。いろんな ORM に対応。 Usage · thoughtbot/factory_girl Wiki 使い方 - factory_girl Gemfile に gem 'factory_girl' を追加(test group のなか) spec/factories.rb を作成 FactoryGirl.define do factory :user do created_at Time.now updated_at Time.now
完了の定義 - tomykaira makes love with codes
完了の定義 ソフトウェア開発プラクティス的な本を読んでいると、よく「完了」が問題になる。気になったら手近な本の索引を引いてみてほしい。かならず「完了」が含まれているはずだ(『実践テスト駆動開発』には完了の説明はあったが、索引にはなかった)。 「完了」について一緒に働いている人に理解してもらう必要があったので、手近にあった書籍から「完了」をとりだしてきた。 継続的デリバリー 継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化作者: David Farley,Jez Humble,和智右桂,高木正弘出版社/メーカー: アスキー・メディアワークス発売日: 2012/03/14メディア: 大型本購入: 22人 クリック: 456回この商品を含むブログ (32件) を見る pp.65-66 実は、フィーチャが完了したと言えるのは、価値をユーザーに届けた時だ
CPU 実験完動報告 - tomykaira makes love with codes
contest.sld の FPGA を使った描画に成功し、自前のシミュレータの出力とバイトレベルで一致したので CPU 実験が始まる前に終了しました。全てを一人で作りました（実質的にコンパイラとライブラリは作っていない）。CPU 実験はオワコンです。 作業期間 8月のどこかの段階で『ディジタル回路設計とコンピュータアーキテクチャ』にのっていたシングルクロックコアを改造したもので再帰 fib が動作していた。試験終了直後の 9/7 に語る会でいろいろなヒントを得て、 9/8 から ISA をレイトレーサに十分なものに変更し、CPU をほぼ全面的に書き直した。9/18 にひろってきた cserver-linux とひろってきた min-rt.ml に 0xaa を送信するコードを足したもので実機動作。作業期間およそ10日。 やったこと CPU コアの実装 FPU のハードウェア実装(fad
describe に書いた内容から自動的に subject を定義してテストコードのノイズを減らす - tomykaira makes love with codes
RSpec でよく describe に書いたことと、 subject に書くことが被ることがあって、DRY じゃないし、その冗長性にはなんの意味もなく、変更コストや打ち間違いのリスクが上昇するだけで困っていた。 なんとかする方法を発見したのでメモ。他の人が困っていないわけないと思うのだが、いまだかつてこの技法を使ったテストコードは見たことがない(id:t-wada さんは describe 入れ子が好きだそうだが、ご存知だろうか)。 example.metadata[:example_group][:description] で expectation が記述されている箇所の直上の describe / context 定義の description が取得できるので、これをつっこむだけ。 結構魔術的だが、いわゆる「黒魔術」(リフレクション的な手法)は使用していない。 注意しなければいけ
twitter bootstarp のテストコードですごいもの見つけた - tomykaira makes love with codes
https://github.com/twitter/bootstrap/blob/master/js/tests/unit/bootstrap-popover.js equals($('.popover .popover-content').text(), 'loves writing tests （╯°□°）╯︵ ┻━┻', 'content correctly inserted') : : var popover = $('<a href="#" title="@mdo" data-content="loves data attributes (づ｡◕‿‿◕｡)づ ︵ ┻━┻" >@mdo</a>') :unicode のテストということにしておこう。
Cucumber 再考 - tomykaira makes love with codes
#tddact の LT のなかで cucumber を批判したが(資料: tomykaira/specs-dis)、いろいろ考えて反省したので意見表明する。用語には気をつけているつもりだが、間違って覚えているものがあるかもしれないので、気になる点はぜひ指摘していただきたい。まず、私は cucumber を rails 上の end-to-end な developer test としてしか使ったことがなかった。ようするに開発者が開発を駆動するために書くテストだ。 そうすると、 cucumber にプリセットされている step 定義にのっとり cucumber 語(日本語でもプログラムでもないよみにくいもの)で適当に確認したい動作を書いて、これを実現するようにプログラムを書くということをしていた。 もちろん全部をデフォルトの step 定義で書くことはできないので自分でも拡張しなきゃ
JSX を二日間ぐらい使ってみて、あんまりよくないことがわかった - tomykaira makes love with codes
恒例の言語 dis 記事。無知をさらけだしているのでぜひともつっこみをください。 2日間ぐらい JSX でちょっとしたプログラム(真理値表をいじったり、QM法をおこなったりするもの)を書いてみて、JSX が残念なことがよくわかったのでまとめた。今回やったのはわりとロジックっぽい部分で、表示したりライブラリつかったり外部と連携したりといったことはなかった。 JavaScript / JSX の用途としてはかなり特異なものだとおもうので、そういうのに適当じゃなかった、というのはあるかもしれない。 しかし JSX の場合はべつにウェブ系に強い印象もないので(ライブラリとか)、今回指摘する問題点の一部は、やはり看過できないと思っている。 環境編 エラーが出たときに、どこで出ているのかわかりにくい 変換したスクリプトを node.js で実行しているため、通常の実行時エラーは変換後の js フ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
