Archive for October 2008
このときRoleを設定するにはTeamからMemberとBlogのidを使ってTeamオブジェクトを調べて，そこにRoleを設定するといった手順が必要になるようです。
気持ちとしてはMemberとBlogのオブジェクトから簡単にTeamを取ってきたい，例えば member.team(blog) みたいな書き方で済ますことができるといいのですが，どうやらそういう方法はなさそう。Teamにnamed_scopeを設定すれば比較的簡単にできそうではありますが，Teamオブジェクトが表に出ないような書き方がほしいです。
とりあえず，目標としては年内にパブリックアルファ版を出します。パブリックアルファ版では，Foodynだけでブログ作成やアイテム作成/編集，カテゴリー作成/編集，スキン作成/編集，プラグイン管理といったことができる状態を指します。お試しではなく使える状態にするということ。ただし，ユーザー・インタフェースは最終版とは大きく変わる可能性があり，機能の一部は未実装になります。
がんばれ＞俺
Googleグループのスレッドで，ヘルパーからform_remote_tagを呼んだらエラーになったということが載っており，それと全く同じです。フォーム内容の生成に使っている_erboutという変数がビューファイルでしか使えないのが原因。解決策はRails 2.2を待てということのようです。
といっても何もしないで待っているわけにもいかないので，ブロックを渡すのではなく，フォーム内のタグを，それこそ文字列でつないで返すようにしようと思います。ただ，end_form_tagが使えなくなってしまったので，フォームを閉じるところは</form>と直接入れざるを得ないようです。かっこわるいけど仕方ない。
Ajaxで更新しようと思っていたのに…
ついでにメンバー追加もここから呼び出せるようにしたいところ。
疲れているのだろうか？
問題点の一つはコントローラでlink_toをしているところ。実はコントローラではlink_toはサポートされておらず，ビューにしかこのメソッドはありません。で，自分でも忘れていたのですが，これを「self.class.helpers」にdelegateで渡すといった記述をしていました。ところが，これだとビューはビューでも新しいビューを作ってそれに渡すことになり，そこでコントローラとの連携が切れてしまっていたのでした。デバッグ中に調べていくとコントローラの@templateというインスタンス変数がビューを格納していたので，それに渡すように変更しました。
次に，それでも途中で，CSRF対策機能を使うかどうかをチェックするprotect_against_forgery?というメソッドが何も実行しないで返ってきてしまう。これにすごく悩んだのですが，実はこれも自分のせいであることが判明。ヘルパーになぜかこの名前のメソッドを作っており，中身が空っぽだったのです。きっと，自分で代わりになる機能を入れようとか考えていたのだろうと思うのですが全く記憶にありませんでした。中身が空のメソッドはデバッガが飛ばしてしまうため，そこに行っていることに気付きませんでした。プロジェクト内に検索をかけてようやく発見。
これだけでおおよそ4時間。疲れました。しかも全部自分のせいだし…
これでほかのところも動いてくれるといいのですが。
【追記】
これでほかのフォームにもCSRF対策用のフィールドが自然に入るようになりました。こりゃ確かに検索しても原因が分からないのは当然です。今後の作業は大分スムーズになるのではないかと思います。
GoogleのAdSenseなど，内容で広告を動的に変えるものはありますが，全部が自動的に最適になってくれるわけではないし，NP_Relatedみたいなブログ内の関連記事を自動的に探すのもちょっと限界があります。そこでアイテム単位でスキンを変えられると，もっと柔軟な対応ができるかなと思ったわけです。
Twitterでつぶやいてみたところ，カテゴリーもほしいという声も。確かにスキン中のifで制御できるとはいえ，大きく変えたい場合は別スキンに書けるとすっきりしそうです。
実装は二つ考えられます。一つはアイテムやカテゴリーにスキンIDのフィールドを作ること。モデル実装上はこれがきれいで，Nucleus互換エンジン以外にも対応できますが，アイテムごとにまるまる新しいスキンを置くのはかなりおおげさな感じがします。メインと同じスキンの上でできた方が作りやすい。
そこで考えたもう一つの実装はスペシャルスキンパーツを使うもの。例えばitem_333というスペシャルスキンパーツがあったら333というアイテムの表示のときにそれを使います。使い回しはちょっとやりにくくなりますが，それほど多用するものでなければ，これがよさそう。同様にcategory_17などとするとID17のカテゴリー表示にそれを使います。タグも同じようにできると思います。この実装はNucleus互換エンジンだけの機能になってしまいますが，今はこれで実装するつもりです。
デバッガーで追いかけて，ちゃんとCSRF対策用トークンを入れてくれるときと何が違うのか調べようとしているのですが，なかなか分かりません。
現象が分かったとしても解決策まで分かるかどうかも問題だし。
検索しても同じような問題にあっている人がいなさそう。よほど特殊なことをしているんでしょうか？
このところの生産性の低さに嫌になります。
プログラムのレベルでも同じで，プラグイン作者などに気持ちよく使ってもらえるためにはどうしたらいいかを結構一生懸命考えています。プラグイン用のマイグレーションは，その成果の一つですし，このところクロージャ周りでいろいろやっているのも関連しています。
で，表題の「プログラマ向けの性格」という話ですが，つまるところは「後で楽をするために，先に苦労することを自然にできるか」ということになるような気がしています。Railsの思想でいえばDRY（Don't Repeat Yourself）が自然に考えられるか，ということです。
例えば同じことを何回も繰り返さなければいけない単純作業があったときに，「とにかくやろう」とその単純作業にひたすら取り組む人はあまりプログラマ向きではありません。どうやったらその単純作業が効率よくできるか，最初にいろいろ調べたりテストしたりして考える人はプログラマ向きです。
実世界では，多くの場合プログラマ向きじゃない方法，つまり単純作業に脇目もふらずに取り組む方が，効率を考える人よりも早く作業が終了してしまいます。そうすると，最初になんだかんだやっている人は「あいつはくだらないところにエネルギーを使って」と低く評価されてしまいます。特に日本の社会ではそういう面が強いような気がします。
結局は，どっちがいいかの見極めが上手だと，世渡りもうまくいくのかもしれませんが，そのあたりのバランスは難しいですね。
（Twitterで似たような話題が出ていたので，ちょっとまとまってませんがアップしてしまいます）
中間テーブルの処理に悩む
Railsの :has_many :through を使って関連を付けているときの中間テーブルの処理がもっと簡単にならないものかと考えています。具体的にいうと，MemberクラスはTeamを中間モデルとして，Blogと連関していて，MemberのRoleはTeamに設定することになります。このときRoleを設定するにはTeamからMemberとBlogのidを使ってTeamオブジェクトを調べて，そこにRoleを設定するといった手順が必要になるようです。
気持ちとしてはMemberとBlogのオブジェクトから簡単にTeamを取ってきたい，例えば member.team(blog) みたいな書き方で済ますことができるといいのですが，どうやらそういう方法はなさそう。Teamにnamed_scopeを設定すれば比較的簡単にできそうではありますが，Teamオブジェクトが表に出ないような書き方がほしいです。
決意表明
最近作業が進んでいないのは技術的な要因というよりも体力的なものによるのですが（年のせいというわけではないと思いたい），このペースでやっているわけにもいかないので，自分で足かせをはめたいと思います。とりあえず，目標としては年内にパブリックアルファ版を出します。パブリックアルファ版では，Foodynだけでブログ作成やアイテム作成/編集，カテゴリー作成/編集，スキン作成/編集，プラグイン管理といったことができる状態を指します。お試しではなく使える状態にするということ。ただし，ユーザー・インタフェースは最終版とは大きく変わる可能性があり，機能の一部は未実装になります。
がんばれ＞俺
原因は判明
表の中にフォームを埋め込もうとしてうまくいかなかった理由が分かりました。Googleグループのスレッドで，ヘルパーからform_remote_tagを呼んだらエラーになったということが載っており，それと全く同じです。フォーム内容の生成に使っている_erboutという変数がビューファイルでしか使えないのが原因。解決策はRails 2.2を待てということのようです。
といっても何もしないで待っているわけにもいかないので，ブロックを渡すのではなく，フォーム内のタグを，それこそ文字列でつないで返すようにしようと思います。ただ，end_form_tagが使えなくなってしまったので，フォームを閉じるところは</form>と直接入れざるを得ないようです。かっこわるいけど仕方ない。
苦戦中
管理画面でユーザー管理周りのところを作ろうとして苦戦しています。一覧を表示するくらいだったら簡単なのですが，せっかくなのでそこでロールを変えられるようにしようとしたところで現在はまり中。formの出力のところで「_erbout」がないといって怒られます。Ajaxで更新しようと思っていたのに…
ついでにメンバー追加もここから呼び出せるようにしたいところ。
それにしても
最近，夜全然起きていられません。30分も作業すると限界。どうしてかなあ…疲れているのだろうか？
Migrationを整理
データベースのテーブルにフィールドを追加するなど，データベース関係の修正がいくつか溜まったので，この際一気にきれいにしようと，Migrationの中を全面的に修正しました。既にFoodynをNucleusのデータをベースにインストールしている場合，最初から作業しなおす必要があります。原因究明＞泣きたくなった【追記あり】
InvalidAuthenticationToken問題の解決がやっと見えてきました。簡単なサンプルプログラムを作って，そこでの動作といちいち比較するというかなりしんどいデバッグでした。問題点の一つはコントローラでlink_toをしているところ。実はコントローラではlink_toはサポートされておらず，ビューにしかこのメソッドはありません。で，自分でも忘れていたのですが，これを「self.class.helpers」にdelegateで渡すといった記述をしていました。ところが，これだとビューはビューでも新しいビューを作ってそれに渡すことになり，そこでコントローラとの連携が切れてしまっていたのでした。デバッグ中に調べていくとコントローラの@templateというインスタンス変数がビューを格納していたので，それに渡すように変更しました。
次に，それでも途中で，CSRF対策機能を使うかどうかをチェックするprotect_against_forgery?というメソッドが何も実行しないで返ってきてしまう。これにすごく悩んだのですが，実はこれも自分のせいであることが判明。ヘルパーになぜかこの名前のメソッドを作っており，中身が空っぽだったのです。きっと，自分で代わりになる機能を入れようとか考えていたのだろうと思うのですが全く記憶にありませんでした。中身が空のメソッドはデバッガが飛ばしてしまうため，そこに行っていることに気付きませんでした。プロジェクト内に検索をかけてようやく発見。
これだけでおおよそ4時間。疲れました。しかも全部自分のせいだし…
これでほかのところも動いてくれるといいのですが。
【追記】
これでほかのフォームにもCSRF対策用のフィールドが自然に入るようになりました。こりゃ確かに検索しても原因が分からないのは当然です。今後の作業は大分スムーズになるのではないかと思います。
思いつきメモ（アイテムやカテゴリーとスキンの紐付け）
アイテム単位でスキンを指定できるとちょっとうれしいかなと思いました。きっかけは卑近なところですが，メインのブログの方で毎月のトップアクセスの記事をまとめているときのことでした。毎月上位に来る記事というのは割と決まっているので，そこが一種のポータル的な役割になるようにページを変えられないかと思ったのです。GoogleのAdSenseなど，内容で広告を動的に変えるものはありますが，全部が自動的に最適になってくれるわけではないし，NP_Relatedみたいなブログ内の関連記事を自動的に探すのもちょっと限界があります。そこでアイテム単位でスキンを変えられると，もっと柔軟な対応ができるかなと思ったわけです。
Twitterでつぶやいてみたところ，カテゴリーもほしいという声も。確かにスキン中のifで制御できるとはいえ，大きく変えたい場合は別スキンに書けるとすっきりしそうです。
実装は二つ考えられます。一つはアイテムやカテゴリーにスキンIDのフィールドを作ること。モデル実装上はこれがきれいで，Nucleus互換エンジン以外にも対応できますが，アイテムごとにまるまる新しいスキンを置くのはかなりおおげさな感じがします。メインと同じスキンの上でできた方が作りやすい。
そこで考えたもう一つの実装はスペシャルスキンパーツを使うもの。例えばitem_333というスペシャルスキンパーツがあったら333というアイテムの表示のときにそれを使います。使い回しはちょっとやりにくくなりますが，それほど多用するものでなければ，これがよさそう。同様にcategory_17などとするとID17のカテゴリー表示にそれを使います。タグも同じようにできると思います。この実装はNucleus互換エンジンだけの機能になってしまいますが，今はこれで実装するつもりです。
鬼門に遭遇
前から問題になっているInvalidAuthenticityTokenのエラーにまた遭ってしまいました。デバッガーで追いかけて，ちゃんとCSRF対策用トークンを入れてくれるときと何が違うのか調べようとしているのですが，なかなか分かりません。
現象が分かったとしても解決策まで分かるかどうかも問題だし。
検索しても同じような問題にあっている人がいなさそう。よほど特殊なことをしているんでしょうか？
このところの生産性の低さに嫌になります。
プログラマ向けの性格
Foodyn CMSの設計を考えるときの方針としては「どういう使い方をしたいか」「どうしたら使いやすいか」をなるべく先に考え，それを実現するために，データ構造やプログラム構造を考えていくようにしています。プログラムのレベルでも同じで，プラグイン作者などに気持ちよく使ってもらえるためにはどうしたらいいかを結構一生懸命考えています。プラグイン用のマイグレーションは，その成果の一つですし，このところクロージャ周りでいろいろやっているのも関連しています。
で，表題の「プログラマ向けの性格」という話ですが，つまるところは「後で楽をするために，先に苦労することを自然にできるか」ということになるような気がしています。Railsの思想でいえばDRY（Don't Repeat Yourself）が自然に考えられるか，ということです。
例えば同じことを何回も繰り返さなければいけない単純作業があったときに，「とにかくやろう」とその単純作業にひたすら取り組む人はあまりプログラマ向きではありません。どうやったらその単純作業が効率よくできるか，最初にいろいろ調べたりテストしたりして考える人はプログラマ向きです。
実世界では，多くの場合プログラマ向きじゃない方法，つまり単純作業に脇目もふらずに取り組む方が，効率を考える人よりも早く作業が終了してしまいます。そうすると，最初になんだかんだやっている人は「あいつはくだらないところにエネルギーを使って」と低く評価されてしまいます。特に日本の社会ではそういう面が強いような気がします。
結局は，どっちがいいかの見極めが上手だと，世渡りもうまくいくのかもしれませんが，そのあたりのバランスは難しいですね。
（Twitterで似たような話題が出ていたので，ちょっとまとまってませんがアップしてしまいます）