変更点

• (1) Rails2 の dirty column に対応
• (2) 一括設定機能を追加

   1  class User < ActiveRecord::Base
   2    acts_as_bits :flags, %w( admin create read update delete )
   3  end
   4  
   5  user = User.new
   6  user.admin = true  # (1)
   7  user.changed?      # => true
   8  
   9  user.flags = true  # (2)
  10  user.flags         # => "11111"

インストール

   1  % gem install maiha-acts_as_bits --source=http://gems.github.com

UIImageで取得できる画像とUIImage.CGImageで取得できる画像が上下逆転してしまいます。原因はUIKitとCoreGraphicsで、座標系のY軸が反転しているからだそうです(takiuchiさん談)。

下記を参考にしました：
http://blog.logichigh.com/2008/06/05/uiimage-fix/

UIImage.CGImageをrorateする

   1    UIImage *sampleImage = [UIImage imageNamed:@"image.png"];	
   2    CGRect rect = CGRectMake(0,0, sampleImage.size.width, sampleImage.size.height);
   3   
   4   //create the context
   5    UIGraphicsBeginImageContext(rect.size);
   6    CGContextRef i_context = UIGraphicsGetCurrentContext();
   7  	
   8    CGContextDrawImage(i_context, rect, sampleImage.CGImage);
   9    CGAffineTransform transform = CGAffineTransformRotate(transform, M_PI);
  10    CGContextConcatCTM(i_context, transform);
  11    UIImage *rotatedImage = UIGraphicsGetImageFromCurrentImageContext();
  12    CGImageRef sampleImageRef = [rotatedImage CGImage];
  13  
  14    //release the context
  15    UIGraphicsEndImageContext();
  16    CGContextRelease(i_context);

ちなみに、Quartz 2Dなどは昔の名前らしく、今は、CoreGraphicsと呼ばれています。最近はCoreImage, CoreGraphics, CoreAnimationのようにCoreシリーズで統一しているようです。

まずはネストという言葉に関する定義の問題ですが、 諸橋さんが書いているように 、PostsコントローラはComments コントローラを集約(aggregates)しますが、 内包(compose)する訳ではありません。

たとえば、管理画面に対応するAdminコントローラから、 Commentの削除や修正を行う場合に、AdminコントローラからCommentsコントローラを集約する事を考えると、その必要性が分かりやすいと思います。

PostsコントローラにCommentsを制御するコードを書いてしまう（内包してしまう）と、 Adminコントローラで同じ事をする必要が出来た場合に、 同じようなコードを書く必要が出てきます。

Don't Repeat Yourself!

結果として、メンテナンス性の悪いコードが出来上がります。 この事が、Postsコントローラの中でCommentsリソースを制御する コードを書く事の問題の本質だと思います。 もちろん、あらかじめCommentsを集約する存在が Postsしか無いと分かっている場合には問題ありません。

という事で、 続いて検索やCRUD以外の操作はどうするのかという問題について。

この問題を考えるための重要な視点として、最近のRailsやMerbでは、 リソースを制御するためのリソースコントローラと、 それ以外の制御をするための汎用コントローラの役割が分けて考えられるようになってきているという事があります。

上述の話の中で登場するコントローラを当てはめてみると、 以下のようになります。

コントローラの分類

リソースコントローラ	汎用コントローラ
Posts	Admin
Comments	Dashboard

リソースコントローラとは、特定のモデルに対してCRUD（create, read, update, delete）操作を行う事に特化したコントローラです。

そう考えると、検索やCRUD以外の操作は、 汎用コントローラが行うのが自然な気がします。 例えば、ブログの記事(Posts)やコメント(Comments) の検索を行う場合であれば、 SearchコントローラがPostsコントローラやCommentsコントローラ を集約すればOK. 疑似コード的に表現すると、以下のような感じになります。

   1  Search#posts with_scope(query){ Posts#index }
   2  Search#comments with_scope(query){ Comments#index }

この構造は２年ぐらい前にRailsで使ってみたのですが、 Railsのコントローラの実装がネストに向いていないので、 パフォーマンス上の問題に苦しみました。 Railsのコントローラは、フィルタの実行、アクションの実行だけでなく、レスポンスの作成を担っているので、ネストさせた場合に、 いったん作成したレスポンスを破棄する必要があるなど、無駄が大きいのです（Railsではお馴染みのDoubleRenderErrorが発生するのもこのせいです）

しかし今であれば、Merbを使う事によってこの問題は解決します。 Merbのコントローラはレスポンスの作成をする必要が無く、非常にシンプルなので、ネストさせてもパフォーマンスの問題はほとんどありません。

ということで、Merbを使えばみんなHappyになるよという話でした。

前回の記事の追補

前回の記事では、Aggregatorの#showで、POST, PUT, DELETEを Aggregatedに委譲するという話を書きましたが、 例えばPostsコントローラがCommentsとTrackbacksの ２つのリソースを集約している場合に、 どちらのリソースに対する操作なのかを判別する方法を用意する必要があるので、どうやって実現するか書いておきます。

   1  posts/1            -> Posts#show
   2  posts/1/comments   -> Posts#show -> Comments
   3  posts/1/trackbacks -> Posts#show -> Trackbacks

こんな感じに、posts/1/:resource に対するPOST, PUT, DELETEを、 :resourceに対応するリソースコントローラに委譲する感じですね。

所属している研究室が絡んでいる国際会議があって、そこの準備をしてきました。

任された仕事は、良く分からない音響・照明機材の操作や会場の準備などさまざまあったのですが、ここでは汎用性の高い無線ルータの設置術を書きたいと思います。

これから書くことは、僕が考えた理想的なスケジュールとなっています。

たぶん、スケジュール通りに進むことはないと思うので、あしからず・・・。

学会1週間前

無線ルータを調達し、設定をしておきます。

設定は、会場を使うには会場費を支払わないといけない場合があるため、自分の机などで行います。

主な設定内容は、

• SSID
• キー
• DHCP接続数 です。

SSID＆キーは学会の名前、場所にちなんだものをつけておくと良いのではないでしょうか。

今までに参加した学会も、だいたい学会の名前だったりしました。

例)

• SSID: xxgakkai-2009
• キー: XXkyoto2009

これらSSID＆キーは何らかの方法を使って、参加者にアナウンスします。 （僕の場合は、研究室の秘書さんを通じて、参加者にアナウンスしていただきました。）

そして、DHCPでの接続数は参加人数に合わせて変更しておきます。1週間前になると、だいたいの参加人数の見込みがわかると思うので。

小さい教室を複数使って行う学会では、教室のキャパシティによってDHCPの接続数を変更すると良いと思います。

最後に、ルータの設定をいじられないように、管理者パスワードはランダムにつけておくのが良いと思います。

ランダムなパスワードをつけるには、n文字の半角英数文字列を生成する を使ってみてください。

簡単に設定しましたが、セキュリティがザルなのが残念なところ・・・。

あまり意味ないですが、any接続拒否とかにしておくと良いかもしれないですね・・・。

気休めですが・・・。

学会前日

看板の設置などにまぎれて、設定内容の確認をさせてもらいます。

僕の場合は、1時間だけ会場をお借りして作業を行いました。

ここでの確認内容は、

• ネットへの接続
• チャンネルの設定

ネットへの接続は必須です。つながらないと話になりません。

チャンネルは、他に無線ルータが設置されていると迷惑をかけることになるかもしれないので、バッティングしないように設定しておきましょう。

確認が済んだら、撤収しましょう。

置いたままにしてると、なくなるかもしれないので・・・。

学会当日

朝早くから出むいて、設置します。

そして、最後の確認を行いましょう。

あとは、クレームが出てこないように祈っていましょう。 （国際会議だと、英語で捲し立てられて怖いです。）

実際に学会の準備をしてみて・・・

上に書いたようにスケジュールが進むことはないですね・・・このように進めば、理想的なのですが・・・。

僕の場合、会場のLANを使うには申請がいったのですが、事務処理をしてくれるところで手違いがあって、ネットワークの制御をしている大元のところで設定を失敗してたらしく、どうしようもない状況になってしまいました。

（おかげで、僕は英語で捲し立てられました・・・。）

それと、やっぱりセキュリティがザルなのが気になりました。

最近はUSBメモリとかが激安なので、その中にSSIDとキーをテキストで保存しておいて、学会のお土産として配布するのがいいかもしれません。

WPA-AESで16進数の64桁の文字列をキーに使っていても、コピー&ペーストで済みますし、参加者に連絡する手間も省けると思うので。

学会によっては、名札の裏に個人のアカウントを発行して、それを使ってインターネット接続するような場合もあるそうです。

今度準備に関わるときは、いろいろと提案してみよう。

以上、学会での無線ルータの設置でした。