■ [Misc] GUIは継承使わない！？(2)

バカが征くより。

原則的に、メソッドをオーバーライドする必要がなければサブクラスを作る必要はありません。機能の追加だけならば合成でも可能です。

頭の中を整理するためには必ずしもクラスはいりません。名前があればいいのですから、それは変数名やメソッド名であってもいいわけです。

Javaで恐縮ですが、下のコードでは、ボタンを並べるためにPanelというコンテナを使っています。ここでは、Panelが本来持っている機能の他には必要なものはありません。ですから、ButtonPanelというサブクラスを作るのではなく、単にgetButtonPanel()というメソッドを用意しました。

ButtonPanelというクラスを用意するのとgetButtonPanelというメソッドを用意するのとで、頭の中の整理の度合が変わるとは思えません。

■ 実はサンプルとしてあげていただいた例では私もButtonPanelをPanelのサブクラスとして定義することはないと思います。ただ、それはどちらかというと粒度の問題じゃないかと思っていて、Testクラス自体（が結構複雑）であればそれをFrameのサブクラスにすると思います。

理由は、前回も触れましたが「GUIの部品をいくつも集めたモノを新たに１つの部品として定義する」ということです。従って、getFrame()というメソッドを用意してFrameのインスタンスを返すよりもnew Test()とだけして、後はFrameの機能＋αを持ったTestというGUI部品を使う、と考えた方が私的にはすっきりするんですよね。

具体的には、JFileChooserみたいなものを作るときに、それをJComponentクラスを継承させずに、GUIとは関係ないクラスを作ってそれのgetFileChooser()というメソッドを作るかというと、やっぱりJComponentクラスを継承させた方が良いんじゃないのかなと。

■ どちらかというと「確かに継承は使わずにも済む」ということより「積極的に継承を使わない理由」が実は一番知りたかったりするのですが...。

＃「滅多にいらない」という前回の文脈から、「使わない方がよい」と受け取りました。ここが誤解だったら申し訳ないです。

■ [Ruby-GNOME2] Rabbit-0.0.2

うおぉ、なんかすごく良い感じになってきてません？

全画面表示とか画像保存機能とか(って前からありましたっけ？)

テーマも良い感じになってますし。

sample/rabbit.rd, rabbit_en.rdを試すのにmimetex.cgiというのが必要っぽいのが初挑戦者にはちょっとハードルが高い気もするけど、そんなときはrdファイルからmimetexを使いそうなページを削除してやってみるとすぐに試せるのでやってみて。

＃ってかオレもmimetex.cgiをインストールできずに挫折(つまりオレのことか(-o-;))。

■ [Ruby-GNOME2] Ruby-GNOME2 in GnomeFiles

アップデートされました。10でvoteプリーズ！！

■ [Ruby-GNOME2] pkg-config viewer-1.0

Ruby/GTK, Ruby/Libglade2, Ruby-GetText-Packageを使った完全な形のサンプルアプリケーションを作ってみました。Ruby-GNOME2-0.13.0が必要です。

ディレクトリ構成・配布形態も含め、このサンプルを参考にすれば簡単にL10n化可能なGUIアプリケーションを構築することができます。

■ サンプルの説明

このツールはpkg-configというコマンドのGUIラッパです。pkg-configを使う方でパッケージ名をよく忘れてしまったり、各オプションの内容を色々と調べたい方向けのツールです。あー、ニッチだ（苦笑）。

■ プログラムの説明

ポイントとしては、ほとんどbin/pkgconfigviewerの中身しかコードを手で記述していない、という点です。lib/pkgconfigviewer/pkgconfigviewerglade.rbはruby-glade-create-packageが自動生成したファイルそのままです。

また、bin/pkgconfigviewer自体もpkgconfigviewerglade.rbをコピってその上で編集しています。

L10n化した部分の手間とかが多少ありますが、純粋に自分でコーディングしたのは、たかだか100ステップ程度です。すごいでしょ。

＃といっても、pkg-config.rbというRuby/GLib2に含まれるライブラリがロジックの本体でそこは100ステップには含まれていないのですが(^^;)。

■ [Ruby] New Ruby Culture T-Shirts!

あははは。思わず笑ってしまった。

赤が狐で緑は狸、だなんて・・・。なかださんおもしろすぎる。

＃ってか、実際狸を緑で書く人はあまりいないような気も・・・。

でも、きっとこうやって間違えた（？）日本観が広まっていくんだろうなぁ。いや、そういうの嫌いじゃないですよ。むしろ好きです（笑）。

■ にしても、狐、狸のどちらかがRubyのマスコットになってオライリー本の表紙を飾るとしたらちょっと微妙な気分ですね。なんだかだまされてるみたいで（笑）。それ以上に、旅館の前に置いてある例のキ○タマのでかい狸がオライリー本の表紙になってしまったらオレも恥ずかしくて買えないかもしれない。

■ [Rails] NorfelloCMMS

CMSかな？ RailsベースのWebアプリケーションみたいです。Ruby-GetTextを使っていただいています。

■ [Ruby] Ruby-GetText-Package-1.92.0リリース！

1.90.0から続いていたメモリリークですがようやく一段落打てたのではないかと思います。1.91.0では使い方によってメモリリークが起きてました。今回、レポートいただいたものは全部フィックスできたと思うので、もしメモリリークに悩まされている方はぜひ1.92.0を試してみてください（もしRuby-GetTextが原因でまだ直っていないと言う場合はご一報を）。

さて、メモリリーク修正以外の今回の主な改善点ですが、機能的にはGNU gettextのmsgctxtと同等の機能を実装したことです。pgettext(msgctxt, msgstr), p_(msgctxt, msgstr)の形式で使います。詳しくはこちらを参照してください。

Rails方面ですが、今回は2.1.0に対応しました。テスト自体も主に2.1.0ベースで行っています。Railsの内部実装が結構変わってたりするので、もしかしたら2.0.0系で動かなくなっているところもあるかもしれませんが、そのような場合はレポートしてください。

他にはActiveRecordで追加されたvalidates_numericality_ofの属性追加に対応してます(:greater_than, :greater_than_or_equal_to, :equal_to, :less_than, :less_than_or_equal_to,:odd, :even)。

それから、validates_(format|inclusion|exclusion)_ofで、%{val}という値を取れるようになってます。validates_length_ofでいうところの%dみたいな感じです（%dもこれに統一しようかな・・・）。

validates_inclusion_of :name, :in => %w(a, b), :message => N_("%{fn} can't be %{val}")

あ、あと、これはRuby-GetTextというよりもRails-2.1.0側の話ではあるのですが、Rails-2.1.0では、require 'gettext/rails'を直接呼び出すとエラーになる場合があります。その場合はconfig.gemを使います。

config/environment.rb:
Rails::Initializer.run do |config|
  :
  :
  config.gem "gettext", :lib => "gettext/rails" 
end

render_partialもローカライズできます（これ、前からできたっけ？（汗））。例えば、render :partial => "foo"で、_foo.html.erb, _foo_ja.html.erbとすると、日本語の場合のみ_foo_ja.html.erbが呼び出されます。

■ [Rails] Rails-2.2系(edge rails)への対応

さっそくレポートもらったんだけど、Rails-2.2系にはまだ対応してません。Rails-2.2系からRails i18nというプロジェクトの成果が取り込まれ始めていて内部的な後方互換性はめちゃくちゃです。ある程度はしょうがないと思いますが、Ruby-GetTextをはじめ、あらゆるローカライズプラグインが影響受けてしまうでしょう。かなり大掛かりな変更なのでRuby-GetTextで2.1/2.2の両方を同時にサポートするのきついかもしれませんね。

ちなみに、Rails i18nの人から参加してくれ、と言われたのですが、言われたときにはすでに最初のバージョン(0.1.0)がgithub上にあって、それが、自分の目指すものと違いすぎたので丁重にお断りしました。gettextよくわからないんだよね、と言っていましたが、RailsのCoreに入れるくらいなら、とりあえず一通りのプラグインの実装を研究してみるくらいの意気込みがあっても良いと思うのですが・・・。元々、Globalizeの人らしくそれと似たようなアプローチを取っている模様です。言語毎のファイルはymlベースでメンテナンス性良くないし・・・String#tって・・・（まぁ、これは好みの問題か（苦笑））。

私としては、Ruby-GetTextの本分であるメッセージカタログ以外のところはうまいことRails i18nで実装されるとうれしいのですが、しばらくは茨の道が続きそうですね。誰か、今のRails i18nに殴りこんで全部GetTextベースで置き換えていただけませんか？（冗談です）