Iwazer Report

Helperをhelperメソッドで定義するのとincludeするのと

RailsのHelperはController内で

と書くのと、

と書く方法があります。

恥ずかしながらこの違いがよく分らなかったのだが、いろいろ実験してみた結果、やっと分った気がしてきた。

まず前者はRubyの文法のinclude ModuleNameなので、Mixinしているのはすぐ分かる。

つまりHogeModule内に定義されているメソッドはHogeContorollerに定義されているのと同じ意味だ。

従って、views/hoge/*.rhtml内でも使えるし、もちろんHogeController内でも自由に使える。

私は後者について悩んでいたのだが、どうやらView側でだけ使用可能な状態にしてくれるらしい。つまりviews/hoge/hehe.rhtmlでは使用可能だが、HogeController内では未定義な状態。

はたして存在意義は？もちろんセキュリティーのためだと思われる。Controller内のpublicメソッドはアクションとして実行可能なので、Controllerは結構注意して書かなければいけない。

お気楽にHelper内に書かれたメソッドがControllerのアクションとして実行されると、まずい状況になりそうなことが容易に想像できる。逆に言えばHelperに書いたユーティリティーメソッドを気軽にViewだけで使用可能にしてくれるhelperメソッドによる定義は便利なのだろう。

作成中のサービスも、よれよれ動くようになってきたので、そんな事もふまえて危ないことをやっていないか、もう一度見直してみる必要はありそうだ。

Radiant

昨日書いたRadiantですが、私、相当出遅れているようだ（汗）

英語のドキュメントを読むのが面倒だなと思ってたら、すぐに Radiant japan があるのを見つけた。

Radiant Handbook もちゃんと翻訳されています。感謝。

Radiant

以前から、このブログのツールを変更したいというエントリーを何回か書いてきたが、やはり使ってるツールを変更するのは面倒だということもあり、なかなか作業を開始しない私。

最近の私は、もう少ししたらオープン予定のサービス（これも作り始めてからかなりの時間が経っているが続いている）でRuby on Railsを使っているので、公式サイト「オブジェクト指向スクリプト言語 Ruby」を参照することが良くあるのだが、このサイト、RadiantというRuby on Railsで作られたCMSを使っていることを知った。

これは試してみないわけにはいかない。まずはRadiant Handbookを見ながらインストールしてみる。試しということで、サーバではなく開発環境としているInstant Rails上の環境で行う。

次のステップではDBへの接続情報が必要となるので環境を作る。

InstantRailsではMySQLの設定ツールとして、phpMyAdminがセットアップされている状態なのでそれを使い、radiant_devというユーザ（特権）を追加する際に「同名のデータベースを作成してすべての特権を与える」オプションを選択すれば、radiant_dev DBも作られ非常に簡単である。

ユーザ（特権）とDBが作成できたら、radiant_cms/config/database.ymlを編集する。

続いてCMSの初期設定を行う。下記を実行するとCMSの管理ユーザやパスワードなどを聞かれるので適切に入力する。DBのテンプレートを何にするかという問いは少し迷ったが、試しインストールなので、とりあえず最初からそれなりに使えそうな「3. Styled Blog」を選んでみた。

もう、これだけで Mongrel や WEBrick を立ち上げれば使えるらしい。

すんなり起動。

アクセスしてみる。

動かすのは、本当に簡単だった。あとは使い勝手と機能を調べなければ。

首がイタタ

すでに恒例になるつつある、首の筋を違えるイベント発生中です。

まぁ、こんかいはそれほどひどくはないのですが、最も注意しなければいけないのは寝起き。

起きた直後は、首を痛めていることを忘れていがちなため、いつもと同様にスっと起き上がろうとして大ダメージをくらいます。

そのため、寝る前から起きるときの心構えを頭に叩き込んでおく必要があります。

今まで何度も大ダメージを食らっているため、今朝はうまくいきました(・∀・)

memcachedb

現在仕事で運営しているサイトはPHPで、複数のWEBサーバで稼働しているが、セッション情報を各WEBサーバのローカルファイルに保存している（PHPのデフォルト）ため、ユーザがサーバ間で移動するとセッション維持できない。

なので同じ接続元からは暫く同じWEBサーバに振り続けるような設定をロードバランサにしている。

ただ、これでは本当に負荷分散出来ていないわけだし、SSL用のサーバがより限定された台数しかないため、何も手を打たないとSSLアクセスした結果サーバが切り替わってセッション切れと、かっこ悪い事態になってしまうわけなのだ。

常々どうしようかと頭を悩ませていたわけなのだが一般的には次のどちらかで実現しているのだと思う。

・DBに覚える
・memcachedに覚える

DBに覚える方法は、ただでさえ負荷が高くなりがちなDBサーバに毎回、参照・更新する事になりちょっと怖いなと。

memcachedに覚える方法は、非常に魅力的なのであるが、daemonを終了すると全て忘れてしまうという、重大な不都合がある。

他にもRuby on RailsであればDRbを使う方法などあるんだが、残念PHP！
などとりとめもなく考えながらRSSを消化していると、こんな物を発見。

memcachedb

恐らくmemcachedのBerkeley DB版といった感じだ。おれの心眼が使えると言っている。

ただPHPのバージョンが古いので、まずはそこからというオチなのだが。

use lib みたいなの

覚書として。

Rubyでrequireするプログラムのパスを指定する方法を調べたが、Perl の use lib ... みたいなのはなさそうか。

RUBYLIB環境変数にパスを指定しておけば、まぁいけるらしい。