raise NoMethodError from locale_rails

投稿者 okkez 2010-07-15 15:44:00 GMT

最近、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 も調べてみたら、リポジトリ上では既に直っていた。

コメントなし | トラックバックなし

Read "Source code reading technic for programmers"

投稿者 okkez 2010-07-15 15:33:00 GMT

「プログラマーのためのソースコードを読む技術」という本をジュンク堂で見かけたので、買って読んでみた。

わかっている人にとってはものすごく普通の内容でした。 それでも、後半のコードリーディング実践の部分は実際に使われているソースコードを全文掲載していて、 移動中でも読めそうな感じだったのは良いと思いました。実際に、自分も移動中に読んでいました。

個人的にはあまり合わなかったけど、これからプログラマや SE として働く人や、新人教育担当になる予定の人や 来年から後輩ができる人なんかは読んでみると参考になると思います。

カテゴリ  | タグ  | コメントなし | トラックバックなし

Reading "Refactoring Ruby Edition" #2

投稿者 okkez 2010-07-12 12:43:00 GMT

日曜日に「リファクタリング Ruby エディション」読書会の第二回に行ってきた。 二章から六章の途中まで読んだ。

二章から五障まではオリジナルのリファクタリングとあまり違いが無かった。 六章からリファクタリングのカタログが始まる。まだいくつかの節しか読んでいないが、参考になることも多いけど、 知っていることの方が多い。

でも、間違ったことも色々と書いてあるので、読みこなすには中級以上の知識が必要だと思った。

カテゴリ  | タグ  | コメントなし | トラックバックなし

Read Perfect Software

投稿者 okkez 2010-06-25 15:06:00 GMT

読んだ。

ワインバーグの最新作なのかな。ジュンク堂で偶然見かけて、購入。

ソフトウェアのテストにまつわる誤解、誤謬、詐欺に関する本。 具体的なソフトウェアテストの技術や知見を知りたい人は別の本を読めばいいと思う。 例えばこの辺。(もちろん本書にも参考文献はいくつもあげられている。)

本文で紹介されている人々の会話も面白いし、実際にありそうな感じだった。いくつかは、自分自身も経験がある内容だった。

で、どういう人がこの本を読むべきかと言うと、ソフトウェア開発に直接、間接に関わるすべての人々が読むべきだと思った。 開発者は、自分の行動やテストに対する考え方や振る舞いを振り返りながら。 テストエンジニアは、開発者から本書にあるような扱いを受けたことがないか振り返りながら。 マネージャは、自分のチームの開発者とテストエンジニアが上手くいっているか気にしながら。あるいは、部下の報告を無視したり、 曲解したり、勘違いしていないか振り返りながら。 その他の人々は、いつか自分が当事者になるかもしれないのだから、当事者になったときのために。

カテゴリ ,  | コメントなし | トラックバックなし

Working Effectively with Legacy Code

投稿者 okkez 2010-06-13 13:39:00 GMT

「レガシーコード改善ガイド」の読書会に行ってきた。今回で最終回だった。 全体的に著者の経験に基づいた実用的なテクニックが多かった。

著者の「テストコードが無いコード」== 「レガシーコード」という考え方には同意できる。 本書では、そういったレガシーコードに対するシチュエーション別の考え方が多数紹介されている。 難を言えば、サンプルコードに C++ と Java が節ごとに切り替わって、少し戸惑うことがあった。 「レガシーコード」 == 「テストコードが無いコード」に悩んでいる人は読んでみるといいと思う。

合わせて読みたい

カテゴリ ,  | コメントなし | トラックバックなし

Reading "Refactoring Ruby Edition"

投稿者 okkez 2010-05-31 14:40:00 GMT

リファクタリングRubyエディションの読書会に行ってきた。

まだ第一章しか読んでいないけど、一章は間違いが多すぎる。 まず、サンプルで紹介されているコードが徹頭徹尾動かない。一回も実行していないレベル。

動かない部分を直して、GitHub にアップしました。 他の勉強用のコードも混じってるけど、本の流れに沿ってリファクタリングして最低限動くようにした。

ログメッセージが全部 refactor になってるのはご愛嬌です。

第一章は残念な感じでしたが、二章以降に期待したいところです。

カテゴリ  | タグ  | コメントなし | トラックバックなし

HikiDoc plugin

投稿者 okkez 2010-05-25 13:53:00 GMT

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 のプラグイン機構は使っていないように見えたけど気のせい?また今度調べてみる。

カテゴリ  | タグ ,  | コメントなし | トラックバックなし

using cancan

投稿者 okkez 2010-05-25 13:17:00 GMT

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 に権限情報を書いてそれを読み込むように書いても使えるところ

良くないところは、権限のコードが長くなってしまうことくらい。 これはテストを書けば、特に問題にはならないかもしれない。 あるいは DB に権限データを登録するようにしてしまえば、シンプルになるだろう。

カテゴリ  | タグ ,  | コメントなし | トラックバックなし

using paperclip

投稿者 okkez 2010-05-25 13:00:00 GMT

thoughtbot’s paperclip at master - GitHub を使ってみた。

あるモデルにカラムを追加して使う方法の場合は Home - paperclip - GitHub をよく読んで使えば問題なさそうだった。

一つのレコードに複数の添付ファイルを持たせる場合に少しハマったので書いておく。

class Issue < ActiveRecord::Base
  has_many :attachments, :class_name => "::Attachment", :dependent => :destroy
end
class 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 クラスでエイリアスを定義しておけば多少はマシになるかと思う。

カテゴリ  | タグ ,  | コメントなし | トラックバックなし

now can add your comment to doc.okkez.net

投稿者 okkez 2010-04-10 02:27:00 GMT

Ruby reference manual (beta) の BitClust 版にコメント機能が付きました。

デザインとかちゃんと出来てないけど、動くようになっているので「一言、言いたいけどチケットを起票するのはちょっと。。。」という人はコメントしてみてください。

カテゴリ ,  | タグ  | コメントなし | トラックバックなし