psの操作に慣れる - nitsujiの日記
Linuxなどで実行中のプロセスを表示させるコマンドにpsというのがあります。 これまでこのコマンドをかなり適当に使ってきていて、オプションとかよくわかってなかったのでmanをちゃんと読んでいろいろやってみました。 psコマンドはprocpsというパッケージに含まれるコマンドです。 procpsには他にtop, vmstat, w, kill, free, slabtop, skillといったコマンドが含まれているようです。 ここではFedora Core 6で以下のバージョンを使っています。 $ ps --version procps version 3.2.7 オプションの指定方法 オプションの指定方法にいくつかの方法があるので把握しておきます。 UNIX オプション。まとめることが可能で、前にはダッシュを置かなければならない。 BSD オプション。まとめることが可能で、ダッシュを使っ
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, Sledge, Maypole - libnitsuji.so
どれもPerlのフレームワークです。 Maypoleのソースを読んで、少し模写して、なんとなく流れがわかってきたところで、他のフレームワークがどうなってるのか気になってきました。で、すぐに思いつくところとしてCatalystとSledgeのソースを読んでみました。といっても、（これにはすごく驚いたのだけれど）Catalystは巨大すぎてとてもソースを読んでいられなかったので、ほぼすべてマニュアルから知識を仕入れました。どれもちゃんと使ったことはないので、とんちんかんな理解かもしれないけれど、とりあえずメモっておこう。 Maypole 3つの中では一番お固いフレームワーク。固いってのは、フレームワーク側が処理フローの多くを決めてしまうのでアプリケーション側でやること（できること）が少ないってことです。そのぶん、うまくいけば簡単にアプリケーションを作れます（たぶん）。MaypoleのキホンはU
NEXTを試してたら頭が混乱してきた - libnitsuji.so
PerlのコアモジュールにNEXTというのがあります。 NEXT - perldoc.perl.org NEXT - Provide a pseudo-class NEXT (et al) that allows method redispatch - metacpan.org とりあえずSYNOPSISのコードを実行してみたのがことの始まりでした。 環境はPowerBook G4にPerl 5.8.8で。 #!/usr/local/bin/perl use strict; use warnings; use NEXT; package A; sub A::method { print "$_[0]: A method?n"; $_[0]->NEXT::method() } sub A::DESTROY { print "$_[0]: A dtor?n"; $_[0]->NEXT::DES
perlは記号だらけでよくわからんという件 - libnitsuji.so
最近「Perlは記号だらけでよくわからん」という話をよく聞くなーと思っていたのでちょっと考えてみた。 まずはよく見かけそうな記号変数（正式な呼称なんだっけ？）を思いつくかぎり列挙してみる。 $_ $! $@ $? @_ <>（これは変数じゃないか） このくらいかな。 で、「記号だからググれない」ということも聞きますが、これは直接Perlのドキュメント（perldoc）を参照するのが手っ取り早いです。 これはperlvarというドキュメントに載ってるので「perldoc perlvar」でググります。そうすると http://perldoc.perl.org/perlvar.html http://perldoc.jp/docs/perl/5.6.1/perlvar.pod とかが出てくるので、あとはブラウザ上で検索すればおkではないかと思います。 また、ブラウザよりもシェルが身近にある人は
DBIx::Class::Validation - libnitsuji.so
DBIx::Class::Validation - Validate all data before submitting to your database. - metacpan.org モデル層でValidationするモジュールなんだけど、単純にCatalystで使ってみたらイマイチだったのでメモ。 イマイチというのはコントローラが思いのほか汚くなってしまうということと、確認画面があるようなフォームだとモデル層に行く前（insert/updateする前、確認用アクション）でValidationすることになるので単純に使えないということです。また、特にtxn_doとか使うとevalばっかになって嫌な感じです。 sub create_save : Path('create/save') { my ($self, $c) = @_; if ($c->session->{entry}) {
FC6のperlをアップデートした - libnitsuji.so
redhat系のperl5.8.8にあてられているパッチのせいで動作が遅いという件に対応したのでメモ。 ずっとスルーしてたんだけどDBIx::Class::Cursor::Cachedを入れたら新しいDBIx::ClassがインストールされてしまいCatalystのテストサーバーを起動するたびに警告メッセージが出るようになったのでこの機会に対応することにしたという経緯。 でも実はrpmコマンドとかもよくわからず、「なんかrpmをインストールしたり、インストール済みのrpmを調べたりできるらしい」くらいしか知らなかった。そんな具合なので「該当のpatchをコメントアウトしてrpmをbuildする」と言われても具体的なやり方がわからないのでこの機会にrpmのキホンも学んだ。ついでにcpioというコマンドも学んだ。 で、いろいろとググったページを参考にしながら以下のようにしました。 $ sudo
DBIx::Class::Manual::Intro - libnitsuji.so
テキトーに訳す。 DBIx::Class::Manual::Intro - Introduction to DBIx::Class - metacpan.org INTRODUCTION SQLを書くのに飽きてPerlネイティブのDB I/Fが欲しい人。 Class::DBIより優れた方法を探してる人。 そういう人向け。 THE DBIx::Class WAY DBIx::Classのやり方を身につけるのに役立つことを紹介。 Tables become ResultSources DBIx::Classはテーブル構造を知る必要がある。 それはDBIx::Class::ResultSourceを定義することで可能になる。 それぞれのテーブルはカラムや関連を定義したResultSourceを1つ持つ。 大事なこと。 A ResultSource == Table （たいていの場合） It's
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
