タグ

ブックマーク / blog.yugui.jp (9)

  • passengerとmod_autoindex - 世界線航跡蔵

    Passenger を使っていて、ディレクトリのautoindexが効かなくて困った。 Passengerもいくらか枯れてきている感じなので先日試したところ、確かに管理が楽なので最近気に入っている。ちょっと前まではRailsアプリケーションのデプロイと言えばmongrel+mod_proxy_blancerだったのだけれども、最近はpassengerの人気が上がっている。 passenger人気の理由はいくつかある。 Rack という汎用の仕組みをサポートしていること。だから、passengerがあればrailsだけでなくmerbもsinatraも動く。 デプロイが楽なこと。SSHでサーバーに入ってアプリケーションサーバーを再起動、とかやらなくて良い。まーこれはcapistranoやvladでデプロイしている私にはあまり関係ないけど、PHPアプリケーションやJava EE warの「ディレ

    passengerとmod_autoindex - 世界線航跡蔵
  • 続・Railsの画面生成を10倍高速化する方法: フィルタ編 - 世界線航跡蔵

    さて、昨日は SSIとの組み合わせでPageキャッシュの適用範囲を広げる話 をした。 なぜSSIかというと、これは組込みの手軽なフィルタ機構だからだ。Apache 1系統ではSSIはハンドラとして実装されているけれども、2系統では新たにフィルタ機構が加わって、SSIはこちらで再実装されている。 フィルタ機構ならmongrelからの出力にも加工できる。Pageキャッシュとキャッシュでないものを透過的に扱えてうれしい訳だ。 ただ、確かにちょっとDRYさに欠ける。どうせならRailsのレイアウトファイルにPHPコード片を直接書きたいではないか。で、これを出力するとPHPとして処理してその結果がクライアントに伝わる、と。 id:yamazさんが「 rhtmlで直接phpを吐き出して処理する方法を模索したいのです。 」と言ってるのはたぶんそういうことだ。私もそれが理想だと思う。今日はそれに挑戦してみ

    続・Railsの画面生成を10倍高速化する方法: フィルタ編 - 世界線航跡蔵
  • Rails勉強会@東京 第22回 - 世界線航跡蔵

    Rails勉強会 に行ってきた。しばらく抑うつ症状やらパニック症状やらの状態が悪かったので、久しぶりの参加だ。でも、最初から最後までどうも頭が働いてなかった。処理が追いつかなくて、切り返しが鈍かったり反応を返せなかったりした人にはごめんなさい。医師には「もう暫くゆっくりしなさい」 と言われてしまったけど、なるほどまだ調子じゃないね。 うむ。気がつけばこの勉強会も回数を重ねて、もうすぐ2周年。 いつもの通りの形式 である。 前半セッション 3つのセッションに分かれた。 初心者セッション(acts_as_authenticated) Rails悩み事相談Ruby Hoedown 2007 の動画を見る 私は初心者セッションに出た。オーナーは諸橋さん。とはいえ、私も我が物顔で口を挟ませてもらった。 acts_as_authenticatedとは acts_as_authenticatedと

    Rails勉強会@東京 第22回 - 世界線航跡蔵
  • Exception Notifier Pluginを導入して分かったこと - 世界線航跡蔵

    運用環境でRailsの Exception Notifier を使ってる。 で、アプリケーションでUnhandledな例外が発生するとメールが飛んでくる訳だ。分かったのは、運用段階まで残るエラーは結局nilに対するNoMethodError、つまりは所謂「ぬるぽ」が多いということ。だから、これからはモデルがnilを返した場合、Viewにnilが渡った場合の挙動についてもっと重点的にSpec記述すべきということだ。 もう1つ言えるのは、今の開発体制においては言語の柔らかさは障害になってないということだ。動的型付けのメリットが活きていて、デメリットはちゃんとRSpecを記述することでカバーできている。「ぬるぽ」はどうせJavaやC#程度では、「言語の固さでカバー」という訳にはいかないものね。型システムの固さでカバーしようとするなら必要なのはJava/C#程度じゃなくてMaybeモナドとかそうい

    Exception Notifier Pluginを導入して分かったこと - 世界線航跡蔵
  • 情報システム部から見た経理の仕事ぶり - 世界線航跡蔵

    私のキャリアはほとんどがちっこい会社だったから、開発者が社内情報システム部みたいな業務もやるわけだ。これはもう完全に間接部門で、他の部署の仕事を下から支えるための仕事だ。 その立場から見ると、世の中で見聞きする経理とか総務とかのお役所的お仕事の様子はお気楽極楽だなぁと思うことがある。つまり、他部署に負荷を掛けないという視点が欠如しているように見える。管理上必要なことを管理するというのはもう当たり前の話だ。それは言い訳にならない。社全体のインフラたるならば、為すべきことは為した上でどのように全体の負荷を減らすかということを考えなければならないんでないのか? ま、今の会社は、特に総務はそのへん融通が利くから良いんだけれども、でも世の中でしばしば耳にする経理上の手続きというのは当に面倒だ。それが小さな会社であっても。現行の業務プロセスにおいてはその種の手続きを他部署が踏んでくれないと経理サイド

    情報システム部から見た経理の仕事ぶり - 世界線航跡蔵
  • Rubyの呼び出し可能オブジェクトの比較 (3) - なんかklassの話

    前回 はコンテキストの概念を眺めて、klassを理解することが必要だという話になったのであった。 klass class文の中では構築しようとしているクラスに対応するClassオブジェクトがselfとなっている。それに、class文の中でのクラスメソッド定義をみると、なんとなく、「デフォルトではselfに、指定すればそのオブジェクトに」というメソッド呼び出しにおけるレシーバー解決に似ている。 class Foo def self.class_method_hoge p :hoge end end class Bar def Foo.class_method_huga p :huga end def self.class_method_huga_of_bar p :huga end end このことを考えるとRubyでは、メソッドはselfに定義されると考えたくなるが、そうではない。実はこれ

    Rubyの呼び出し可能オブジェクトの比較 (3) - なんかklassの話
  • Rubyの呼び出し可能オブジェクトの比較 (2) - というよりコンテキストの話 - 世界線航跡蔵

    前回 は各オブジェクトの基的な特徴を見ただけで終わってしまった。今回はこれらをコンテキストという観点から見てみたい。 前回のまとめ 呼び出し外側のscopeblock中身戻り値 __send____send__不可能(そもそもコンテキストを保存していない)可能保持しないメソッドの戻り値 Method[],call参照不可能可能メソッド体とselfメソッドの戻り値 UnboundMethod不能参照不可能-体メソッドの戻り値 Proc[],call,yield参照可能不可能closureProcの最後の値 Continuation[],call-不可能「続き」戻らない Proc#callにおいてブロック付きの呼び出しが不可能であることは前回は記述しなかった。 sshiさんにご指摘いただいた 。 Procを作成するときに指定するブロック仮引数の記述は、メソッド定義の際の仮引数の記述にとて

    Rubyの呼び出し可能オブジェクトの比較 (2) - というよりコンテキストの話 - 世界線航跡蔵
  • Rubyの呼び出し可能オブジェクトの比較(1) - 世界線航跡蔵

    Rubyにはコード片を表すオブジェクトが複数ある。 Method , UnboundMethod , Proc である。 Continuation は少し違うけど、実行コンテキストを記憶しているオブジェクトという意味では近いものがあるか。『 Ruby Way 』にはこういういろいろがあることについて「驚くほどのことではありません」と書いてあるけれども私は驚いた。で、これらが微妙に違うのだ。困ったもんだ。いや、便利なのかもしれないが。 それで今回はこれらの概要を眺めてみたいと思う。 普通のメソッド defでメソッドを定義するのが一番普通だやな。 class C def greeting(arg) puts "C#greeting reveived #{arg}" end def iterator yield 'iterator 1st' yield 'iterator 2nd' yield

    Rubyの呼び出し可能オブジェクトの比較(1) - 世界線航跡蔵
  • Rails勉強会@東京 第7回 - 世界線航跡蔵

    Rails勉強会@東京 第7回 に行ってきた。今回はドリコム恵比寿オフィスにて。 小雨の降る中、参加者がぞろぞろと集まってくる。残りの人を待っている間、話題になるのは 昨日のはぶにっき のこと。はぶさんから提示された「RailsのやりかたはDOAへの退化ではないか」という疑問と、いくつかの質問。そしてそれへのid:takahashimこと高橋会長のコメント。これは懇親会の話題にも続いた。 ドリコムのオフィスはビリヤード台が設置された素敵な感じ。 前半セッション 4つのセッションに分かれた。 DHHの講演の録音を聴く 「ARを詳しく」をあとで読む Railsのパフォーマンス問題の英語のテキストを読む AWDwRの付録Aを読む。 私は「Railsのパフォーマンス問題」に出た。ネタにしたのは A Look at Common Performance Problems in Rails 。よしみさ

    Rails勉強会@東京 第7回 - 世界線航跡蔵
  • 1