投稿者 okkez
最近、Rails2.3.8 に上げたり上げなかったりしたら以下のようなエラーが大量に出るようになった。
NoMethodError in 'BatchController POST create by login user when posted data was valid should create valid subject (end_date)' undefined method `clear' for I18n::Locale:Module
ちょっと調べてみたら、locale_rails/lib/locale_rails/i18n.rb の中で Locale モジュールを参照している部分でエラーになっていた。 そこを ::Locale とトップレベルから参照するようにしたら動くようになった。
http://github.com/mutoh/locale_rails も調べてみたら、リポジトリ上では既に直っていた。
投稿者 okkez
「プログラマーのためのソースコードを読む技術」という本をジュンク堂で見かけたので、買って読んでみた。
わかっている人にとってはものすごく普通の内容でした。 それでも、後半のコードリーディング実践の部分は実際に使われているソースコードを全文掲載していて、 移動中でも読めそうな感じだったのは良いと思いました。実際に、自分も移動中に読んでいました。
個人的にはあまり合わなかったけど、これからプログラマや SE として働く人や、新人教育担当になる予定の人や 来年から後輩ができる人なんかは読んでみると参考になると思います。
投稿者 okkez
日曜日に「リファクタリング Ruby エディション」読書会の第二回に行ってきた。 二章から六章の途中まで読んだ。
二章から五障まではオリジナルのリファクタリングとあまり違いが無かった。 六章からリファクタリングのカタログが始まる。まだいくつかの節しか読んでいないが、参考になることも多いけど、 知っていることの方が多い。
でも、間違ったことも色々と書いてあるので、読みこなすには中級以上の知識が必要だと思った。
投稿者 okkez
読んだ。
ワインバーグの最新作なのかな。ジュンク堂で偶然見かけて、購入。
ソフトウェアのテストにまつわる誤解、誤謬、詐欺に関する本。 具体的なソフトウェアテストの技術や知見を知りたい人は別の本を読めばいいと思う。 例えばこの辺。(もちろん本書にも参考文献はいくつもあげられている。)
本文で紹介されている人々の会話も面白いし、実際にありそうな感じだった。いくつかは、自分自身も経験がある内容だった。
で、どういう人がこの本を読むべきかと言うと、ソフトウェア開発に直接、間接に関わるすべての人々が読むべきだと思った。 開発者は、自分の行動やテストに対する考え方や振る舞いを振り返りながら。 テストエンジニアは、開発者から本書にあるような扱いを受けたことがないか振り返りながら。 マネージャは、自分のチームの開発者とテストエンジニアが上手くいっているか気にしながら。あるいは、部下の報告を無視したり、 曲解したり、勘違いしていないか振り返りながら。 その他の人々は、いつか自分が当事者になるかもしれないのだから、当事者になったときのために。
投稿者 okkez
「レガシーコード改善ガイド」の読書会に行ってきた。今回で最終回だった。 全体的に著者の経験に基づいた実用的なテクニックが多かった。
著者の「テストコードが無いコード」== 「レガシーコード」という考え方には同意できる。 本書では、そういったレガシーコードに対するシチュエーション別の考え方が多数紹介されている。 難を言えば、サンプルコードに C++ と Java が節ごとに切り替わって、少し戸惑うことがあった。 「レガシーコード」 == 「テストコードが無いコード」に悩んでいる人は読んでみるといいと思う。
投稿者 okkez
リファクタリングRubyエディションの読書会に行ってきた。
まだ第一章しか読んでいないけど、一章は間違いが多すぎる。 まず、サンプルで紹介されているコードが徹頭徹尾動かない。一回も実行していないレベル。
動かない部分を直して、GitHub にアップしました。 他の勉強用のコードも混じってるけど、本の流れに沿ってリファクタリングして最低限動くようにした。
ログメッセージが全部 refactor になってるのはご愛嬌です。
第一章は残念な感じでしたが、二章以降に期待したいところです。
投稿者 okkez
HikiDoc - FrontPage.ja でプラグインを使いたかったので、プラグインを作る方法を調べてみた。
ソースを読めばプラグインを作る方法はわかる。 しかし、HikiDoc を使った上でプラグインも使っている例はあまりないようだった。
class CustomOutput < HikiDoc::HTMLOutput
def initialize(suffix = " />", options = {})
super suffix
@options = options
end
def inline_plugin(src)
# あんまり使わないので未実装
end
def block_plugin(src)
name, *args = parse_plugin(src)
klass = Plugins.const_get(name.classify)
@f.puts klass.new(@options).call(args)
rescue NameError => ex
@f.puts ex.message
end
private
def parse_plugin(src)
result = []
if /([a-z0-9_]+)\((.+)\)/m =~ src
result.push $1
result.push *$2.split(',').map(&:strip) if $2
end
result
end
endこんな感じで HikiDoc::HTMLOutput を継承して inline_plugin と block_plugin を定義すれば良い。 今回の実装方法でプラグインを定義するには以下のようにする。 Rails で使用するのでヘルパーを使えるようにしておく。
module Plugins
end
class Plugins::Base
include ActionView::Helpers, ::ERB::Util
def initialize(options = {})
@options = options
end
def call(args)
raise 'must implement in subclass'
end
end
class Plugins::Echo < Plugin::Base
def call(args)
%Q!<pre>#{args.inspect}</pre>!
end
endクラスを使わずに実装する方法もあるが、今回は Rails なので Rails っぽくなるようにクラスを使ってみた。 クラスを使わない場合は、プラグインの名前をキーにしたハッシュに処理を登録する方法が使えると思う。
Hiki では HikiDoc のプラグイン機構は使っていないように見えたけど気のせい？また今度調べてみる。
投稿者 okkez
ryanb’s cancan at master - GitHub を使ってみた。
元々 be9’s acl9 at master - GitHub を使っていたのだけど、 ちょっと手の込んだことをやろうとすると、やり方がわからなくなったので cancan を使うことにした。 Rails Authorization in The Ruby Toolbox でも人気だったし @kakutani にも紹介してもらったし。
ほとんどのことは Home - cancan - GitHub の Wiki を見ればわかる。これで分からない場合は rdoc.info :: cancan を見ればいいはず。
acl9 に比べていいところは
良くないところは、権限のコードが長くなってしまうことくらい。 これはテストを書けば、特に問題にはならないかもしれない。 あるいは DB に権限データを登録するようにしてしまえば、シンプルになるだろう。
投稿者 okkez
thoughtbot’s paperclip at master - GitHub を使ってみた。
あるモデルにカラムを追加して使う方法の場合は Home - paperclip - GitHub をよく読んで使えば問題なさそうだった。
一つのレコードに複数の添付ファイルを持たせる場合に少しハマったので書いておく。
class Issue < ActiveRecord::Base
has_many :attachments, :class_name => "::Attachment", :dependent => :destroy
endclass Attachment < ActiveRecord::Base
belongs_to :issue
has_attached_file :attachment
endこのようなクラス構成の場合、Attachment というモデルは paperclip で定義している Paperclip::Attachment と名前が 被るので Issue の定義で注意する必要がある。 上で書いているように、:class_name オプションに「フルパス」でモデルのクラス名を書いておけば良い。
あと paperclip では xxx_{file_name,content_type,file_size,updated_at} というカラムを用意すると、 モデルに xxx という名前のメソッドが定義されるので xxx の部分を長くしすぎるとちょっとコードが読みづらくなる。
実際に Attachment モデルに attachment_* という名前でカラムを用意したので以下のようなコードが頻出して気持ち悪くなったことがある。
link_to @attachment.attachment_file_name, @attachment.attachment.url
Attachment クラスでエイリアスを定義しておけば多少はマシになるかと思う。
投稿者 okkez
Ruby reference manual (beta) の BitClust 版にコメント機能が付きました。
デザインとかちゃんと出来てないけど、動くようになっているので「一言、言いたいけどチケットを起票するのはちょっと。。。」という人はコメントしてみてください。