Hatena::Groupcatalyst

dann@catalyst このページをアンテナに追加 RSSフィード

2008-04-05

Capistrano + git

03:23 |  Capistrano + git - dann@catalyst を含むブックマーク はてなブックマーク -  Capistrano + git - dann@catalyst  Capistrano + git - dann@catalyst のブックマークコメント

gitへの移行に伴って、Catalystのdeploymentスクリプトもgit使うように変更した。repository, scmの設定を変えるのがポイント。全体は長いので、一部だけ。

# SSH OPTIONS
ssh_options[:keys] = %w(~/.ssh/id_rsa)
ssh_options[:forward_agent] = true

# git config
set :repository, "dann@192.168.0.30:/var/git/repos/#{application}"
set :scm, :git
set :scm_username,  ENV['USER'] || Proc.new { Capistrano::CLI.password_prompt('SCM User: ') }
set :scm_password, Proc.new { Capistrano::CLI.password_prompt('SCM Password: ') }

catalystアプリをgitで管理

02:36 |  catalystアプリをgitで管理 - dann@catalyst を含むブックマーク はてなブックマーク -  catalystアプリをgitで管理 - dann@catalyst  catalystアプリをgitで管理 - dann@catalyst のブックマークコメント

今日はgitに入門してみました。ということでCatalystアプリもgitで管理すべく、スクリプトをgitに移行。

#!/bin/bash
CATALYST_CMD='/home/dann/devbin/catsetup.pl'
APP_NAME=$1
APP_PREFIX=`echo $APP_NAME | tr "[A-Z]" "[a-z]"`
GIT_REPOS=dann@192.168.0.30:/var/git/repos

if [ -z $1 ]; then
    echo "You need to give a catalyst project name."
    return 1
fi

if [ -f $1 -o -d $1 ]; then
    echo "$1 exist in current directry.\nYou should change directry."
    return 1
fi

$CATALYST_CMD $APP_NAME
cd $APP_NAME
git init-db
git add .
git commit -a -m "initial commit"
cd ..
echo "after commit"
git clone --bare $APP_NAME/.git $APP_PREFIX.git
echo "after clone"
scp -r $APP_PREFIX.git $GIT_REPOS
rm -rf $APP_PREFIX.git
cd $APP_NAME
git remote add origin $GIT_REPOS/$APP_PREFIX.git
git fetch origin

モデルをCatalystから切り離す方法

16:55 |  モデルをCatalystから切り離す方法 - dann@catalyst を含むブックマーク はてなブックマーク -  モデルをCatalystから切り離す方法 - dann@catalyst  モデルをCatalystから切り離す方法 - dann@catalyst のブックマークコメント

id:nitusjiさんのブクマコメントで、DIコンテナを使って依存関係を切り離すのは、「Model::Adaptorと比べて何がいいんだろう」というコメントが書いてあったので、今回は、Catalyst::Model::Adaptorで依存を切り離すことがあまり嬉しくない理由についてだけ書きます。あまり書いてしまうと、CatalystConで話すことがなくなってしまうで (^^;

まずはじめに、モデルをCatalystから切り離す方法についてですが、大体以下の4つがあります。

  • Catalyst::Model::Adaptor + POPO
  • POPO + Factory
  • POPO + ServiceLocator
  • POPO + DIコンテナ

Catalyst::Model::Adaptor + POPOで切り離すことのデメリット

このうち、Catalyst::Model::Adaptor + POPOを用いることがあまり嬉しくない理由の一つは、miyagawaさんが書いていることです。

http://subtech.g.hatena.ne.jp/miyagawa/20080306/1204761778

%opt は設定ファイルに書く、っていう、ただそれだけなんですね。これじゃ全然つかいものにならないし、Model::Adaptor のラッパーで使いたければそれでもいいかもしれないけど、単にオブジェクト生成するところやメソッド通すときにラッパー一段増えるだけで別になにもうれしくない。

暗にmiyagawaさんも書いていますが、「POPOのモデルを作るたびに、CatalystのAdaptorを作らないといけなくなる」、というのは大きなデメリットです。

Catalyst::Model::Adaptorを使うことのメリット

デメリットの裏返しではありますが、メリットは、Catalystで読んだConfigが参照できるところだと思います。デメリットを超えたメリットがあるかというと、今のところは殆どないのかなという印象です。

ただ、Catalyst::Model::Adaptorを使わずに、Catalystからモデルの依存を切り離すためには、自前でConfigLoaderを用意する必要があります。ですから、デメリットはあるものの、お手軽に依存関係を切るための方法として、Catalyst::Model::Adaptorを使うというのはありなんじゃないかと思います。

ModelをPOPOだけで構築することについて

POPOだけで構築すれば、Catalystからの依存は切れるわけで、以下の3つの方法はどれを使ってもCatalystへの依存関係を切り離すことはできます。

  • POPO + Factory
  • POPO + ServiceLocator
  • POPO + DIコンテナ

上記にどのような違いがあるかについては、CatalystConの時間内に収まればしてみようかなと思っています。ただ、Catalyst(or WAF)の話とは関係なくて、アプリケーションを作るときにDIコンテナを使うことのメリット・デメリットという話になってしまうので、CatalystConで話す内容かな?という気は少しします。

トラックバック - http://catalyst.g.hatena.ne.jp/dann/20080405