DBIx::Classでスレーブに接続する - libnitsuji.so
レプリケーション環境で、更新系クエリはマスター、参照系クエリはスレーブに振り分けるというのはよくあることだと思います。 PerlのO/RマッパーであるDBIx::ClassにはDBIx::Class::Storage::DBI::Replicationというのがあって、これを使うと利用側で接続先を意識することなくクエリを振り分けることができそうです。しかし、どうやら参照系は必ずスレーブへ振り分けてしまうようなので、トランザクションの中ではマスターを参照したいといった場合に対応できないんじゃないかと思いました。 そこで、明示的にスレーブの接続を取得する方法がないかなーと思ったんですが見当たらなかったので書いてみました。 実装するにあたり以下のClass::DBI用に書かれたコードを参考にしてみました。 http://d.hatena.ne.jp/tokuhirom/20060713/1152
More about Shipwright - libnitsuji.so
前回はてきとーなモジュールをShipwrightに突っ込んでインストールしてみる、というところまでやってみたけど実用的なことは何一つやってませんでした。というわけでCatalystおよびcatalyst.pl MyAppしてできたスケルトンをパッケージングしてテストサーバーを起動するとこまでやってみたよ。 パッケージはここにあります。 http://svn.onot.in/public/shipwright/catalyst-myapp/ インストール Shipwrightパッケージはデフォルトでは/tmpの下にインストールされますが、これを/opt以下に変更します（よくわかってないけど気持ちの問題？）。Shipwrightのパッケージは/usrとか/usr/localとかの下にインストールするようなものではなく、このパッケージだけが存在するような状態にインストールするのが正しいようです。
Shipwrightを学んだのでまとめとか - libnitsuji.so
ShipwrightはPerlのモジュールです。CPANで公開されています。 Shipwright - Best Practical Builder - metacpan.org Shipwrightはアプリケーションのためのパッケージングツールです。依存しているソフトウェアおよびバージョンをリポジトリで管理します。たいていのPerlで書かれたアプリケーションはCPANモジュールに依存しているので、何らかの方法でそれをインストールする必要があります。思いつく方法としては以下のような方法があります。 CPANコマンドで地道にインストール アプリケーションのMakefile.PLでModule::Installを使って依存モジュールを自動インストールする rpmなどで自力でパッケージングする（やりかたしらないけど） 専用のPerlパッケージ（perl本体含んだ）を作成する この中でお手軽なのは
nitsujiの日記 - Catalyst::Plugin::I18Nを使ってメッセージ類をControllerに直接書かないようにする
例えばカテゴリを削除するアクションを実行した結果を表示したい。 flashを使って例えばこんな感じにする。 if ($c->form_submitted) { if (my $name = $c->forward('do_delete')) { $c->flash->{notice} = sprintf('カテゴリ「%s」を削除しました', $name); $c->res->redirect($c->uri_for('/admin/category/list')); } else { $c->flash->{notice} = 'カテゴリを削除できませんでした'; $c->res->redirect($c->uri_for('/admin/category/list')); } } でもこういうメッセージ類がコントローラの中にあるとあとでなにかと面倒です。 そこでCatalyst::Plu
nitsujiの日記 - Catalyst::Manual::Cookbook
Catalyst::Manual::Cookbook - Cooking with Catalyst - metacpan.org Basics Catalystを使う人が知っておいた方がいいこと。 Delivering a Custom Error Page アプリケーションでエラーが発生したときはCatalystは独自のエラーページを表示する。-Debugモードのときはエラーメッセージとコンテキストオブジェクト($c)のData::Dumpの出力を表示する。-Debugモードじゃないときは"Please come back later"が表示される。 エラーページを変更するにはendメソッドにエラー処理を書けばいい。例を示す。 sub end : Private { my ( $self, $c ) = @_; if ( scalar @{ $c->error } ) { $c->st
Catalyst::Manual::Cookbook::Test - libnitsuji.so
さらに分割。 テストについては外部からリクエストを送って、みたいな方法しかない？ようなので、内部のモジュール、特にモデル部分のテストをどうやってやるかが問題。 そこは普通のPerlモジュールと同じ方法でできるのかね。 http://search.cpan.org/~jrockway/Catalyst-Manual-5.700701/lib/Catalyst/Manual/Cookbook.pod#Testing テストはWebアプリケーションの開発プロセスに不可欠な要素だ。テストは複数人での開発とコードの変更を容易にする。 Testing Catalystは開発中のテストと本番環境にデプロイする前のテストをやりやすくする。 Catalyst::Testは同じテストをローカル（外部のデーモンを除く）とリモートのHTTPサーバに対して行えるようにする。 Tests スケルトンアプリケーションの
Catalyst::Manual::Cookbook::Deployment - libnitsuji.so
Cookbook長いので分割。 デプロイについてのレシピ。Webサーバーエンジンとアプリケーションの効率化も含む。 http://search.cpan.org/~jrockway/Catalyst-Manual-5.700701/lib/Catalyst/Manual/Cookbook.pod#Deployment mod_perl Deployment mod_perlは多くのアプリケーションに対しての最適解だけど利点と欠点を述べる。他の方法としてはFastCGIがある。 Pros Speed mod_perlはとても高速で、それぞれのApacheプロセスのメモリにアプリケーションをロードすることによって恩恵を受けられる。 Shared memory for multiple apps 同じサーバーで複数のCatalystアプリケーションをする必要がある場合、mo_perlは共通のモジ
nitsujiの日記 - vimのplugin
vimのsnippetsEmuがすばらしい - otsune's SnakeOil - subtech を見て入れてみようと思ったんだけどプラグインなんて使ったことなくて30分くらい苦戦したのでメモ。 Linuxでvim7使ってます。 $ mkdir -p ~/.vim/after/ftplugin $ cd ~/temp $ wget http://www.vim.org/scripts/download_script.php?src_id=6951 $ vim snippetsemu1_1.vba :UseVimballそうすると~/.vimの下にいろいろとファイルができる。 プラグインにはグローバルプラグインとファイルタイププラグインの2種類があって、snippetsEmuは後者らしいので、 :filetype plugin onってやらないと有効にならないっぽい。~/.vimrcに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
