Re: CodeIgniterが急激によくなってきた

Published: 2009-10-22 | By merikonjatta |

僕が以前に書いたCodeIgniterに関する記事に対して、CodeIgniterが急激によくなってきた – なんたらノート 第二期というトラックバックをいただきました。

申し訳ないけど、このブログエントリの著者が学生さんだと知りつつ、きつく批判します。

「なんたらノート」さんは、僕の狭い視点と一方的にCodeIgniterを酷評するスタンスをよくないと批判してくださっています。

僕の表現が至らないところがあって、大いに誤解を招くような記事を書いた事については反省しています。今更ながら元記事について補足しておきますが、僕はCodeIgniterに対してネガキャンを張りたかったわけではありません。あくまで自分の利用目的に合わない部分を書いただけです。

トラックバック元で指摘された各項目について反論を書こうかと思いましたが、おおむね好みや状況によるものなのでやめておきます。僕が指摘した点、向こうで指摘されている点は立場によっては両方正しかったり、どちらかが正しかったりするものだと思います。PHPを使うのもCodeIgniterを使うのも様々な目的とバックグラウンドがあってのことですから、僕が「使いにくい」と感じた点について「それは間違ってる」と指摘されても仕方がありません。

ですので、「きつく批判」される筋合いはないと今も感じてます。

最後に一言だけ。

CIに限らず、他人の方法に自分が違和感を覚えるとき、単に「おかしい」とだけ考えて切り捨てていると真実を見逃す。おかしな仕様だと思えば思うほど、「なぜそうなったか」を考えることは重要。

確かにその通りですね。批判したいと思ったらもう一歩、なぜそうなっているかを考えてみることは重要ですね。ただ、それだけだと例えばWindowsの使いにくさを批判することなど至難の業となってしまいますから、「自分ならこう作るのに！」という視点とは別に「自分にとっては使いにくい」という視点もありなんだろうとは思っています。

Categories: Whatnot |Tagged , | 1 Comment

Railsでメール受信に反応してコントローラを起動する

Published: 2009-10-21 | By merikonjatta |

PostfixとRailsで、メール受信に反応してコントローラを起動させるにはどうすればいいか。

基本方針

基本的には、特定のユーザに届いたメールをプログラムへパイプするようPostfixを設定することになる。では何にパイプするか？

本家Rails Guidesではscript/runnerでUserMailer.receive(STDIN.read)を実行するという方法が紹介されているが、

  • メール受信のたびにRailsアプリが起動されるので重い
  • SMTPサーバとRailsのサーバが同一でないといけない

などの欠点があるので、受信メールをRailsのコントーラに受け渡すスクリプト – taslamの日記で紹介されている方法を採用することにした。

スクリプトを軽く書き換え

上記のスクリプトはすごく便利だが、実際にコントローラでparamsを見てみるとメールがバラバラ死体になっているので、予めURLエンコードするように書き換える。

    require 'cgi'

    def proxy(str, options = {})
      start(str, options) do |server, mail|
        data = 'mail='+CGI.escape(mail)
        server.post(data)
      end
    end

Postfixの設定

/etc/aliasesに追記：

username: "| ruby /path/to/script.rb"

編集後に実行（/etc/aliasesの設定を反映させる）：

# sudo newaliases

コントローラにて

外部から無理やりPOSTしているため、そのままだとActionController::InvalidAuthenticityTokenが発生する。以下を追記してそれを抑制する。

skip_before_filter :verify_authenticity_token

これでparams[:mail]に生のメールが入っている状態になる。自力でパースするのは面倒だな…と思っていたらTMailという素晴らしいライブラリがあったのでそれを使う。

mail = TMail::Mail.parse(params[:mail])
mail.base64_decode!

Mail.parseから返ってくるのはTMail::Mailオブジェクトなので、あとはTMailのRDocに従ってメールとおしゃべりしよう。基本的には

  • 送信元アドレス：mail['from'].addrs.first.address
  • 宛先アドレス：mail['to'].addrs.first.address
  • 宛先アドレスの@以前：mail['to'].addrs.first.local
  • 件名：mail.subject
  • 本文：mail.body

ぐらいがあれば十分でなかろうか。

余談

Rails Guidesに載っているほうのやり方は、Mailerモデルに処理をやらせるという点がどうも気持ち悪い。リクエストに反応して処理をするのがMVCのうちコントローラの役割なのは明らか。HTTPで来たリクエストはコントローラ、メールで来たリクエストはモデルが引き受けるのは不自然だ。

Categories: HowTo's, Tips and Tricks |Tagged , , | Leave a comment

HostingRails.comに移転した

Published: 2009-05-23 | By merikonjatta |

Dreamhostの契約が間もなく切れるので、少し前に契約したhostingrails.comのアカウントへ移動しました。ついでにWordpressもアップグレード。UIがかなり変わって使いやすくなったように思います。

もう一年くらいブログを書いていなかったのですが、今はプライベートな日記をつけているので、時間があればそこからピックアップして記事にしていくつもりです。

それと、CodeIgniterが急激に嫌になってきたという記事についてかなり真剣なコメントをもらっているのですが、今まで対処できずにいました。これからトラックバック元をしっかり読んで対応したいと思います。

Categories: Whatnot |Tagged | Leave a comment

普通の壁とプロジェクターがマルチタッチスクリーンになるMicrosoft TouchWall

Published: 2008-05-15 | By merikonjatta |

マイクロソフトのマルチタッチスクリーンといえばMicrosoft Surfaceだが、このたび新しくTouchWallなるものを発表するようだ。ソースはCrunchGear。

このTouchWall、普通の壁と普通のプロジェクタを使ってマルチタッチスクリーンが実現できるという点が新しい。画面の周辺に三つの赤外線レーザーとカメラを配置し、それらが画面に触れている指や手の位置を認識するという仕組みだ。

デモの映像があるのでどうぞ。

できることは今あるマルチタッチと同じようなもので、この動画では広範囲のスクロールやズームをスムーズにやってみせている。

プレゼンテーションで複雑な図を用いる必要がある場合などに便利そうだ。壁全体をホワイトボードにしてしまうこともできる。

だがTouchWallの一番のメリットはなんといっても値段だろう。専用のマルチタッチスクリーンと比べて物理的なパーツが少ないため価格が圧倒的に安いらしい。たとえばSurfaceは一機で100万円ほどするそうだが、TouchWallならなんと数万円ほど。しかも当然ながら画面がいくら広くなろうとも値段が高くならないというのが素晴らしい。

なんともわくわくする技術だ。

ただ、映像を見る限りではiPhoneやSurfaceなどと比べるとやや操作がもっさりしている気がする。たぶんうまくソフトウェアをチューニングすれば大した問題にはならないと思うのだが、どうなんだろうか。ちなみにこのデモではVista上で動くPlexというソフトウェアを使っているらしい。

今のところMicrosoftとしてはこれを製品化する予定はないとのこと。早く製品化してくれないかな。数万円ならプロジェクトルームや研究室の予算でぜひとも買わせたい。

これは余談だが、ホワイトボードとして使うならプロジェクタの消費電力が気になるところだ。普通のホワイトボードはいつ見ても同じものが必ず見えるというのが大きな特長だ。今のプロジェクタは常につけっぱなしにしておく訳にはいかない。TouchWallのような技術でホワイトボードを代用するのならその方面での技術的な躍進も欠かせないと思う。

Categories: Ideas and Products |Tagged , , , | Leave a comment

月例発表会向けのカブロボ考察 途中経過

Published: 2008-05-10 | By merikonjatta |

月例発表会向けレジュメとスライドの第一版ができた。最近研究関連の事を書いてなかったので、ラフにではあるがいまのところのアウトラインをまとめておく。

タイトル：「カブロボグリッド実現方法の検討」

カブロボグリッドとは

カブロボは、自動株取引きプログラム。選択した売買アルゴリズムによって儲かったり儲からなかったりするため、良いアルゴリズムを発見することが大きな課題になる。

カブロボのアルゴリズムは売買ルールとパラメータで表現されるが、ルール同士を組み合わせることも可能なため、その数は膨大。グリッドの力でこれを片っ端から探索しようというのがカブロボグリッドだ。

だが、本当に片っ端からやるだけでは効率が良くない。そこで、より良いアルゴリズムをより短時間で見つけるために、行う仕事の選択と、クライアントへの仕事の割り振り方に関していくつかの方策を提案する。

仕事の選択

片っ端から試すより、良いアルゴリズムの周辺を重点的に試行するほうがおそらく効率が良い。さらに、たとえばユーザが希望した部分を優先的に試行するような仕組みが欲しい。

そこで、仕事の生成をオーディションラインとトレーニングラインの二つに分ける。

オーディションラインは、基本的にはユーザが指定した部分の仕事を生成する。

トレーニングラインは、オーディション出身で比較的性能が良かったアルゴリズムの周辺へ手を伸ばしていく。

加えて、トレーニングラインから確率的にジャンプを起こし、少しだけ離れた部分のアルゴリズムをオーディションさせる。これは焼きなまし法に似ている。

仕事の割り振り方

ま ず前提として、カブロボグリッドではエラー耐性のために同じ仕事を複数のクライアントに割り当てる。同じ仕事を4つのクライアントに振る、というのは「冗 長性」として自由に設定可能だ。また、このうち最低3つの結果が一致していればそれを正しい結果とみなす、というような設定が可能で、この値を「クオラ ム」と呼ぶ。

さて、いまのカブロボグリッドでは冗長性を一律で設定できるが、仕事ごとに設定できない。だが冗長性をその時々のクライアントたちの能力によって動的に変更することで無駄が減らせるはずだ。

そ こで、何通りか考えられる冗長性rに対して、期待値Erを定義する。これはEr = 1/(jr * lr) で表される。jrは冗長性rのときに一回でコンセンサスが得られない確率。lrはそのときに失われる時間。これらは仕事を受け取るクライアントの能力に よって決まる。常にこのErが最大になるようなrをその仕事の冗長性として設定することで、常にもっとも効率が良いと見込める冗長性設定が可能になる。

次 に、最低限必要でない仕事をどのクライアントに割り振るべきかを考える。これは、たとえば冗長性4、クオラム3の場合の4つ目の仕事だ。前の3つが同じ結 果で返って来たときにこの4つ目の仕事は無駄になるわけで、それを例えばものすごく能力の高いクライアントに渡してしまうのはもったいない。そのクライア ントは無駄にならない別の仕事をすべきだ。

そこで、ある仕事wuを受け取れるそれぞれのクライアントiについて、もったいなさMiを定義す る。これはMi = w/(j * ei) で表される。wは仕事wuの計算量、jは自分と同じ仕事をしているほかのクライアントたちがエラーを起こす確率、eiは自分自身がエラーを起こす確率。こ れらの値は同じ仕事をしているクライアントたちと、手の空いているクライアントたちの能力によって決まる。常にこのMiが最小になるようなクライアントi に仕事を振ることで、もっとも無駄のない割り振りが可能になる。

これから考えるべきこと

  • 「期待値」という言葉は厳密にはふさわしくないので、他の分かりやすい言葉を考える。
  • もったいなさの式にjが含まれていていいのか怪しい気がしてきたので、もう一度よく考える。
  • 先着順でないということはクライアントを待たせるということ。これの意味と影響を考える。
Categories: Whatnot |Tagged , | Leave a comment