WAF の設計方法 – 冬通りに消え行く制服ガールは、夢物語にリアルを求めない。 – subtech

Web + App は大人気 Sinatora もそういう考えっぽいですが (誤解しているかもしれません)、Web というのが App へのインターフェイスの一つにすぎず、例えば CLI + App という組み合せもあるし、Desktop GUI + App という組み合せも考慮されています。ロジックのテストはしやすそうでいいですね。でも、もっと富豪的でもおこられないんじゃないかなぁとも思うのです。

WebApp の場合、Web (というよりHTTP) を唯一のインターフェイスとして提供し、例えばCLIだろうがGUIだろうが、HTTP を仲介するようにします。HTTP + App, CLI→ HTTP + App, GUI→ HTTP + App。これは例えばGAEだと、そもそもこういう方法をとることしかできません。Cron もHTTPで特定のURLが叩かれるだけです。ユーザ向けAPIみたいなのがだいたいのサービスでありますが、それをアプリケーションのオーナーまで権限を拡張しているような感じです。

読んでいてすごく面白かったです。

僕も先日、CLIアプリのWebインターフェースを作っている途中で、「ん?」と引っかかっていた部分があったんですが、id:cho45さんのエントリーを見て氷解しました。

require 'sinatra/base'

# Fooがアプリ名だと思ってください
class Foo::Web < Sinatra::Base
  get '/run' do
    # code... 
  end
end

rack(map)もsinatraもこう書くのでrouterとAppの結合が強く、Appを別クラスにして委譲したくなる。

require 'sinatra/base'

# Fooがアプリ名だと思ってください
class Foo::Web < Sinatra::Base
  get '/run' do
    Foo::App.run
  end
end

class Foo:App
  def self.run
    # code...
  end
end

こうすればCLIも同じ様に書けて便利だ!

require 'sinatra/base'

# Fooがアプリ名だと思ってください
class Foo::Web < Sinatra::Base
  get '/run' do
    Foo::App.run
  end
end

class Foo::CLI
  def run
    Foo::App.run
  end
end

class Foo::App
  def self.run
    # code...
  end
end

うんうん。で、gemでのfoo/bin/foo(コマンド)を作ろうとして、「ん?」となった。

foo/bin/foo:

#!/usr/bin/env ruby
$:.unshift File.join(File.dirname(__FILE__), '..', 'lib')
require 'foo'

Foo::......

あれ?

httpdを立ち上げるコマンドにすればいいのか、CLIを呼び出すコマンドにすればいいのかどっちだろう・・・?

food(foo daemon)とfooの両方をbinに用意する?

んーなんだかなー・・・。

となっていたのです。

「Webだけでいいじゃん」

というのは目から鱗。Webからのテストを充実させれば問題無し!

ただ、「微妙なところ」として上げられている中でも「テストが遅くなりがち」というところは凄く気になっています。

mockもやりすぎると品質が落ちるし、かといって、継続的インテグレーションサーバーを使ってテストしてもらうのは面倒だし、品質の高いままサクサクできる方法がないかと悩んでいます。

Comments


Option