Perlに関する質問です。 Class::Data::InheritableとClass::Data::Accessorの使い分けがわかりません。どのような場合にはどちらを使うべきなの説明をお願いします。
perlhttp://perldoc.jp/docs/modules/Class-Data-Inheritable-0.02/Inheritable.podhttp://anond.hatelabo.jp/20071101181442anondの説明は文体が寒かったのでコードにメモしとく(役に立ちました。ありがとうございます)。 package Class::Data::Inheritable; use strict qw(vars subs); # -- refs使う use vars qw($VERSION); # -- 5.005以下に配慮 $VERSION = '0.08'; sub mk_classdata { my ($declaredclass, $attribute, $data) = @_; # -- クラスメソッドとして呼ばれなかったらcroak if( ref $de
唐突にClass::Data::Inheritableのソースコードについて説明してやんよ。 使い方とかの説明はこの辺でも読んでから出直して来い、ごるぁ! まぁとりあえずソース見てみろ、下記にはっつけてやっからよぉ! 1: package Class::Data::Inheritable; 2: 3: use strict qw(vars subs); 4: use vars qw($VERSION); 6: $VERSION = '0.06'; 7: 8: sub mk_classdata { 9: my ($declaredclass, $attribute, $data) = @_; 10: 11: if( ref $declaredclass ) { 12: require Carp; 13: Carp::croak("mk_classdata() is a class metho
目的 フロントがHTTPリクエストを受けて、バックエンドのアプリケーションサーバにreverse proxyするような構成において、指定秒数以内に何かしらのレスポンスを返したい。 200が返せない場合は、処理を打ち切って500を返したい。 背景 フロントでApacheやNginxをreverse proxyとして使っている場合、バックエンドが無応答になってしまうと、クライアントにレスポンスが返るのはデフォルトで数十〜数百秒後(ApacheのTimeoutのデフォルトは300秒、Nginxのproxy_read_timeoutのデフォルトは60秒)になってしまいます。 通常のWebサービスではこのオーダーのタイムアウトでもいいのかもしれませんが、数秒以内に(エラーでもいいので)レスポンスを返すことが求められる環境も存在します。(最近、特に多いのではないでしょうか:P) もちろんバックエンドが
cpanminus (cpanm) is an awesome and lightweight CPAN installer with zero dependencies. It requires less than 10MB of RAM, has no interactive shell, uses sane defaults with quiet output, and can be easily upgraded via a single command. The document recommends starting to use cpanm and provides tips on commands like --prompt, --notest, and using it with PERL_CPANM_OPT and perlbrew.Read less
いつまでモデル分離やってんだよって感じですが。 色々問題も解決していい感じに落ち着いた。 APIがDBICのCRUDなメソッドが呼べなかった件 流れ モデルを分離するためにAPIを作ろう $c->model('API::User')でAPIが呼ばれるようにしよう モデルを呼ぶのにwebのコンテキストから切り離せた! でも当然DBICのsearchとかのメソッドはAPIから呼べないよね searchとかしたい場合はresultsetオブジェクト用意してね 毎回用意するの面倒です 解決策 DBICのCRUDなメソッドが使えるクラスを用意して、全APIがそれ継承すればいい この考え自体は思いついてたし、pixisでもそうやってたから間違っては無いはず。 が、自分で実装ができなかったのと、pixis丸パクりは自分のためにならないのでやらなかったので、実現できなかった。 pixisのソースちゃんと読
CatalystでMVCの勉強をだらだらとのろのろとやっていっているけれど、いろいろ調べているうちに、どうもModelディレクトリにモデルを入れるのは、最近の手法ではないのかなという感じ。 参考: catalystでモデル分離が落ち着いた。その上でUser->find_by(id => 2)とかしてみた - だるろぐ跡地最近のCatalystアプリケーションの構成 - (゚∀゚)o彡 sasata299's blog 確かに$c->model('モデル名')って取り出しやすいけれど、それがMとCの結合度を高めてしまっている、という理由ぽい。 で。 今日はCatalyst::Model::Adaptorを使って、API経由でロジックを記述するやり方を覚えた。 参考: Catalyst::Model::Adaptorを使ってみた - hide-k.net#blogCatalyst:
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く