development環境
WEBRick ( rails server )での development はほぼ悩むことない
production環境
とりあえず Apache を基本にメモ。nginx だと当然記法は異なる。チュートリアルビデオが分かりやすい。
- production 用に rake を実行するには rake COMMAND RAILS_ENV=production
- /rails/info/properties は production 環境では localhost 以外からは参照できない
Passenger
Overview — Phusion Passenger (a.k.a. mod_rails / mod_rack)
※ mod_rails だけど、今は mod_rack でもある。しかも nginx でも動く。
以下、メモ。
- RackEnv production を設定( <= Rails 2 の場合は RailsEnv )
- SELinux に引っかかって gem の奥深くに入ってる passenger は読み込めなかった
- SELinux 以外は VirtualHost 丸ごと passenger 化するのは難しくない
- production 環境として実行するためには httpd.conf に RackEnv production ( Rails 3 以降の場合) が必要1
Passenger + サブディレクトリ
一つのホストの中で複数の Rails アプリを動かす。
- RackBaseURI を使う ( <= Rails 2 の場合は RailsBaseURI )
- RackBaseURI /app の形式で指定する
- このパスに実際の Rails.root/public が来るように symlink を作る
※ ただし、アクセスが http://example.com/app のものは http://example.com/app/ に正規化してあげないとWebサーバとの間でパスの解釈に食い違いが出てしまう
fastcgi
dre3k's rails3_fcgi at master - GitHub
これでやってみる。
注意!!
- mod_fcgid では AddHandler fcgid-script .fcgi
- mod_fastcgi では AddHandler fastcgi-script .fcgi
DocumentRoot がアプリの public/ になる方法は設定できた。ただし rvm で入れた ruby は今のところ使い方が分からない。もしかしたら rvm wrapper とか使えばイケるのか?
ということで、複数の別バージョンの Ruby を動かすのは今のところ難しそう。Passenger によって mod_php 並みに快適にはなるが、mod_php を越えるわけではなさげ。結構期待していたのに。
ところで rack で扱うなら fastcgi 関係の gem って要らないんすよね?
rvm の Ruby を使う
Passenger
- rvm で入れた Ruby を rvm use で指定してから gem install rails passenger
- この passenger を利用する設定にすれば普通に動く
fastcgi
なぜかは分からないけどうまく動かすことができなかった。
まとめ
まとめはない
Rails 2 以下の場合は RailsEnv を設定する ↩
去年 tiarra を動かし始めてから初めてのアップデート。
tiarra は機能的にはきらいじゃないんだけど、conf の中身がコメントだらけで設定しにくいのが難点。もちろんコメントないよりあった方がいいんだけど、アップデートしたらますますコメントが増えて全体像がつかみにくい><
使いたかったのは
general {
nick-fix-mode: 0
}
これを 2 にしてみた。なんでこれが必要かというと、特に freenode と tiarra と limechat を組み合わせときの現象だと思う1んだけど、irc client がすでに nick が使われているから代わりの nick に付け替えなきゃと思って nick の変更を試みて、その変更の反映のタイミングかなんかで意図せずループしてしまうことがある。
この nick 変更の際、末尾に _ を付加したりすることが多く2、limechat と組み合わせるとやたらと _ が増えて最後は _ だらけになって 0 になるとかいう事態に陥る。
そこでこれを回避するために使えるのが nick-fix-mode
これでいつ繋いでも nick 変更の嵐に見舞われることがなくなった。
localhost のファイル、レコーダの中身、アップデートしてないパッケージをずんずん整理する。
最近どうも調子が上がらない。こういう単純作業をやると小さな達成感が味わえて嬉しい。まぁ普段から整理する方がいいんだけど。
なんか自分的にはちょっと微妙。
まず DOM の操作をしようと思っても日本語の文字列が unicode escape sequence で渡ってくるので terminal で表示できない。1サンプルにあるように title って入れていきなり訳が分からなくなるのは結構悲しい。また、Firebug だと HTML collection なんかは配列っぽく自動的に表示してくれるがそういうこともない。まぁそんな感じで DOM いじりが便利ってわけでもない。
じゃあ Firebug より使いやすいコンソールなのかというと、rlwrap なんかで readline の恩恵にあずかることはできるが、Rhino のように長いコードがその場で書けるわけではない。Rhino なら例えば for 文の途中で改行してもそのまま書き続けられるが、MozRepl はその場で評価されてしまうのでやっぱり長いワンライナーにせざるを得ない2。
今のところいいなと思ったのは inspect() で、これがあればこのオブジェクトにはどんなプロパティあったっけー?と思ったときに放り込むだけでだいたいのことが分かる。
しかし Firefox で気軽にこれをやるととんでもない量のプロパティが列挙されることがよくあるので、more() とか grep() とかあったら便利かもしれないなと思った。screen 上でやってればスクロールバックさせることはできるけど、この操作ってなんだかトロくさくてやなんだよな。
まー遠隔の自動操縦が本来の狙いで、日本語の文字列を避けてできる範囲で使えばすごい便利なんだろうけどなぁ。細かいチェックを Firebug を併用して行って、自動化を MozRepl で行う。そんな感じか。
※ ちょっとずつ慣れてきた。Firebug と違って「タブを区別せずに現在の content の状態に対してアクセスできる」のは便利かもしんない。やっぱ grep() とかほしいな。
[2006-11-11 追記]
repl.search( /RE/, context )
でイケるっぽい。例えば
repl> repl.search( /f/, document )
defaultView
lookupPrefix
isDefaultNamespace
firstChild
insertBefore
prefix
createEntityReference
lastModified
referrer
preferredStylesheetSet
domConfig
こんな感じ。
repl.search( string, context )
だと完全一致になる。
repl> repl.search( 'first', document )
repl> repl.search( /first/, document )
firstChild
ふむふむ。
面白かったけど、せめて terminal は 2枚開いてエディタでも色分けさせておけばもう少し「よーし俺も」と思う人いるかも。作業スペースが一つしかなくてエディタを毎回起動して終了して、って流れはさすがに使いにくそうに見えるので、これを見ても Windows べったりの人は「うわーやっぱ Unix なんか使えねー」って思うだろなぁ。
なんてことを OS X で terminal 2枚開いてそれぞれで screen を使いながら Emacs を使ってるオレが思いましたよ。
※ ほとんどリモートで作業してるんだけど
あとで気づいたけどこれ、screen 使ってるじゃん。まーでも screen で window 切り替えなんてやったら、使ってない人には何が起きているのかそれこそ理解不能だな。
早めに決断すること
- 普通に perl を ports から入れる
- /usr/local/bin/use.perl port と打つと ports で入れた Perl を /usr/bin/perl に切り替えることができる
perl 自体はこれで置き換わる。しかし
- 「自分で入れた様々なライブラリはライブラリをインストールした時点でデフォルトになっていた Perl のバージョンに依存している」ので、改めて 5.8.x 用のものをインストールする必要がある
- すでに同名のパッケージが入っているのでそのままではインストールできない
ということで
- PKG_FORCE_REGIST をつけるか make deinstall & make install をくり返す
ことになる。だからシステムをインストールしたらできるだけ早い段階で決断すること。
ちなみに use.perl はこんなことを教えてくれます。
> use.perl
Usage:
/usr/local/bin/use.perl port -> /usr/bin/perl is the perl5 port
/usr/local/bin/use.perl system -> /usr/bin/perl is the system perl
from ITmedia
しみました。この人の文章は豊かな経験が生きていて実によい。
岐阜大の先生。
事実が語られているのでよいと思います。マスコミでは教育問題は必要以上に煽動的か、本当の問題はえぐれないことが多い(ように見える)ので。日本は知財で勝負するような話のような気がしますが、現実にはまったくポストがないっつーことですな。
あと。これは田舎特有かもしれないけど、「生まれの土地に縛られる」場合もある。なんつーか日本的な”家”な発想とでも言いますか。それでも研究職ではなく教員でいいというだけならまだポストはあるかもしんない。そんな感じ。
個人的にはタイトルにもうちょっと工夫がほしかった。
なんだかすごいことに。
Classic Mac でも動く名作の誉れ高い PIM ソフト。やっと思い出した。Mac の PIM についてもどっかにメモ書いたと思うんだけど、どこやったかなぁ。
発見。よさげ。しかし、このモジュールを使うってことは今のログ解析処理はほぼ全面書き直しになる。だったら Perl でやる必要ないんじゃないかとか思うのは悪いクセか。どうしよっかなー。
from slashdot.jp
FreeBSD が Linux ほど普及しないのは、やっぱユーザーが FreeBSD の普及をそれほど熱心に志向していないから、というのが大きいように思う。過去に普及しなかった要因としては裁判でペースが落ちたとか、ドライバ周りでどうしても Linux に遅れを取ってしまうとか、自分の書いた超有名人が居ないとか、そういう理由もあると思う。でも本当に自分を振り返ってみて、現在進行形で普及が進むか進まないかを考えたときに、どう考えても「FreeBSD を有名にしたい!」「FreeBSD がメジャーでなきゃやだ!」という欲求が沸いてこない。これに尽きる気がやっぱするのよね。
FreeBSD は優れた道具であると信じているし、好きだけど、手や資金が足りなくて FreeBSD としての維持が難しいですとか、そういう切迫した事態がこない限りこのスタンスは変わらないような気がする。これが売り物なら、あまりにシェアが小さいと生産打ち切りの憂き目にあって悲しい思いをするのでもっと頑張って応援するかもしれないが、幸いにして FreeBSD はそういうシロモノじゃないし。
なんていうか、だって人の価値観を変えるのなんて恐ろしいパワーが要るし、それが自分の生きる道ではなさげだし。自分は優れた道具を使って楽をしたいだけであって布教には興味ないのだ。ただ、自分の影響力を自由に発揮していい場では FreeBSD を推します(笑) 後任とか面倒なことを考える必要がある場合には素直に Linux にしておきます(コラ) 多少の設定を除けばできることは大差ないんだし、そんなスタンスがいちばん幸せに暮らせそうだもの。
てなことを。
Python と Ruby だったらやっぱ Ruby を使うのが気持ちよさそうだなぁと感じたついでに書いておく。どうも自分の嗜好がこの辺にはっきり出ている気がするのだ。ライブラリの充実度から言ってほんとに楽できるのは Python に決まってるじゃん、と思う一方で気持ちよさを取る辺りが。