..rvmrc っていう、そのファイルの置いてあるディレクトリに cd した瞬間にそこで指定された ruby がデフォルトで実行されるバージョンになるっていう超絶便利な機能があります。
分かりにくいですね。例えば
rvm use 1.9.2 --default
して普段は 1.9.2 を使っているんだけど、あるプロジェクトの開発をするために
cd ~/Sites/project
すると自動的に ruby -v が REE になる機能です。便利でしょ。
で、これ、勝手に有効になってる時期があったんですけど、いつからか「この .rvmrc 信用して ruby の version 変更していい?」って聞かれるようになりました。なったのはいいんですけど、不用意に「あとで」って N で答えると二度と有効にならない、という状態になってしまいました。
こりゃ困ったなと思って help を読んでいて見つけたのが
rvm rvmrc
です。
rvm rvmrc {trust,untrust,trusted,load,reset} [optional-path]
こういう風に使うそうです。例えば今いるディレクトリの .rvmrc をすぐ有効にしたい場合は
rvm rvmrc load
で、今後ずっと有効にしたい場合は
rvm rvmrc trust
というわけですね。
rvm rvmrc trust && source ~/.zshrc
みたいな方法でもいいかもしれませんというか、自分はそうしました。単に load を知らなかったからですが。
※ 例によって 2ヶ月前の日記を書いています。
- ライブドア、livedoor Blogとlivedoor Readerを「PubSubHubbub」対応に - builder by ZDNet Japan
- pubsubhubbub - Project Hosting on Google Code
ブックマークだけしてあってよく分からない記事があったのでリアルタイム人力検索(Twitter)に投げてみた。返事が返ってこないことが多いが、今回はかなり正確に検索できた。
10:56:49 >wtnabe< 【急募】PubSubHubbubを140文字以内で説明してくれる人
11:10:31 <rytich> @wtnabe Publisher(公開者)がSubscripter(購読者)に対し
てプッシュで更新を通知するためのhubだバブー (Pubはwebhookでhubに更新を
通知するようです)
11:13:10 >wtnabe< .@rytich あーえーと Web サービス型の RSS リーダの更新
が早くなるよってことですか。なんかそんな気がする。
11:16:05 >wtnabe< Subscriber に POST するってことは少なくとも
Subscriber は常にそれを受け取る準備してなきゃいけないわけで。
11:16:36 <rytich> @wtnabe たぶんそうだと思います! あとRSSリーダは 定期
的に見に行ったりしなくてよくなるので 楽になりそうです
11:20:13 >wtnabe< 乱暴に言うと update ping を集積してクロールの無駄を省
いてくれる hub かな? Publisher はやっぱ hub を認識できてないと早くなら
ないよね。
11:23:06 >wtnabe< えーとそれが livedoor Blog が対応しましたって話か。
blog と reader 両方を持ってるところはそら対応するに決まってますがな、っ
てわけか。
えーと確認のために PubSubHubbub の登場人物を整理すると
- Publisher は要はブログ(だけじゃないけど)
- Subscriber はフィードリーダ
- これの間を取り持つ Hub
で、PubSubHubbub とはこの Hub を定義するプロトコル(?)のことで、Publisher と Subscriber の両方が Hub に「対応」することでかなりリアルタイムに近い通知が可能になるというものらしい。
update ping という言葉はたぶん古くなっちゃってて最近は webhook という言葉に集約されつつあるのかな? いろんなサービスに機能が増えてきているみたい。
ブログとフィードリーダという言葉は分かりやすさのために使っているだけで、こういう形態のサービスに限らずに使えそうな気がする。今後 Publisher の対応は進んでいくだろうから、例えば定期的に scrape して情報を更新する泥臭い作業も Hub -> Subscriber の POST を受け付ける URI があれば無駄がなくなるし速くなるし一石二鳥。1
ということで、いろいろ調べているうちに今回の1つの新しい知識と一緒に2つの疑問が増えた。
- webhooks
- reversehttp
今後の課題ということで。ぼんやーりとは想像つくんだけど。
_whyたん
ちなみにこの頃、_why ショックが駆け巡っていた。
11:29:43 >wtnabe< えっ。_why たん。
RSSCloud
[追記]
RSSCloud というものもあって、これと対比させるとより分かりやすいみたい。
- 秋元@サイボウズラボ・プログラマー・ブログ : WordPress.comが採用を発表したRSSCloudを試しました
- RSSCloudとPubSubHubbub, どっちがいい?: fat pingが勝つのはどうして?
個人的には RSSCloud は RSS 2.0 の中に収まっちゃってるのが嬉しくない。RSS 1.0 や Atom にも対応できるのかなぁ?
scrape の必要な情報源が Publisher として Hub に対応してるの?という疑問は当然あるけど、feedに含まれる情報で満足できない場合には重宝すると思う。いっとき feed へのアクセスはちゃんと考えてやれよ(304に対応しろ)という話題もあったしね。 ↩
whois が止められているネットワークからどうにか tunnel 越しに whois 引けないかなぁと思っていたんだけど、そもそも whois コマンドが普段どのサーバに繋ぎに行ってるのかよく分からないというひどい状態であることが分かってきた。要するに、
tunnel の掘り方は分かるけど、どこに向かって掘ったらいいか分からない
わけだ。
調べると、Directory of Internet Whois Servers なんてのが見つかった。おーとりあえずこれでよさそう。あ、いや古いな。
whois -h whois.nic.ad.jp
すると
whois.jprs.jp
を使えと返ってくる。なるほど、じゃそれだけ直して、alias で whois は rs.internic.net を、jwhois は jprs.nic.ad.jp を見に行くように設定してみた。うん、快適快適。
web gateway でいいじゃん? いやーそれが面倒なの。
それにしてもコレ、どこかで最新の情報を管理、公開してくれてないんだろか。あー
*.whois-severs.net
(* は country code)で指定できるのか。これ使えばいいのかなぁ。
NHK の小さな旅は映像美と少し物悲しいあの音楽が切なくて大好きな番組なのだけれど、今日その音楽を耳にした瞬間にカリオストロの城を思い出し、なんだろうと思ったら、
音楽はどっちも大野雄二
だった。やっぱり。
しかもなぜか宮崎アニメを見たくなる特典付き。音楽ってすげーな。
面白かった。全体的にさらさら読める学術書であり、各章で角度が違うので、興味のある部分だけを読み込むっていう読み方でもよいと思う。
個人的にはたださんも触れていた第2章の歴史が面白かった。テキストサイトやアンテナなどの言葉が実は苦手だったのだけれど、分かりやすく書かれていた。コミュニティの当事者の定義付け議論がやかましかった時期を通り過ぎ、これからが面白い時代なんだな、という思いを強くした。
しかし最近 blog や Web 上に何か書くということに足を踏み入れた人にとっては面白いのかな。年寄りがまたなんか言ってる的な感じに受け取られてしまうんだろうか。まーでも知っておいて損はないと思う。「人間て進歩ねーな」って気持ちになるだけで、恐らく今抱えているコミュニケーション上の悩みや flame による疲れが少しは和らぐ。ような気がする。
またこの辺を読んでいて、人間てのはいつもコミュニケーションツールに飢えていて、新しい物はぶわっと火がついてブームになり、そしてテクノロジーの進化や規制などによって世代交代がくり返されているんだなぁ、なんてところに勝手に考えが飛躍してしまった。例えば昔は留守電のメッセージが残っているかどうかに一喜一憂してたし、応答メッセージにやたら凝ってみたりした。自分は伝言ダイヤルとかポケベルとかはすっ飛ばしてしまっているけど、携帯電話、そして携帯のメールと、依存性の高いコミュニケーションツールは相変わらず話題の中心である。
ただこれらは誰か自分以外の相手とコミュニケートするためのツールであるところが、この本の言うウェブログとは違う。ウェブログの持続性はそれが自分に対しても発せられ、振り返ることを可能にしている点にあるってことはまぁ、読めば詳しく書いてあるのでその辺は各自ご自由に。個人的には図が見にくくてしんどかったけど。
ツッコミを RSS に入れるか入れないか選べると嬉しいのかも。
で、この間の件だけど、ツッコミに spam や荒らし系のものが入った場合に気づきやすいという点ではツッコミを RSS に反映するのはよい方法だと思う。この場合はツッコミの編集が RSS に反映されないといつまでも荒らしの結果が RSS に残ってしまうので、編集も RSS に反映される形がいちばん妥当な気がする。(ツッコミの追加が反映されちゃう時点で、編集結果も例えそれが上にこないようにする形でも反映させないといけない。)
過去のデータのインポートに関しては、インポートの間だけプラグインを無効にしておけばいいと思う。まーその間はツッコミも RSS に反映させられないけど、それはしょうがないってことで。
※ うーん、過去記事に TrackBack って、うまい方法だなぁ。aaacafe ではできないけど。
http://slashdot.jp/article.pl?sid=03/08/20/004258
本題はどうでもよくて、この「キャメルケース」という言葉。へーと思ったら有名なようですね。不勉強でした。
ちなみに私は LowerCase with underscores をよく使っています。いわゆる GNU スタイルです。(インデントは K&R スタイル。)ところでハンガリアン記法は UpperCamelCase ということになるんでしょうか?