Perlでシグナル処理（DBIを黙らせる編） - D-6 [相変わらず根無し]
Perlでシグナル処理（DBIを黙らせる編） 2011年4月27日 01:42 D | ブログ記事のURL | コメント(0) | トラックバック(0) なんかふと気づいたら最近以前書いたPerlでシグナル処理の記事にブクマがついていたので続き的な感じで書いてみた。 例えば 以下のように、ワーカーとかでずーーーーっとDBにクエリを投げてその結果を使って処理をする、というような処理を書くとする while ( $loop ) { my $sth = $dbh->prepare( .... ); $sth->execute(); while ( $sth->fetchrow_arrayref ) { .... } } 以前書いた%SIGを用いたPerlの普通のシグナル処理では、もしexecute()でブロックしていた場合など（例：Q4Mでqueue_waitしてる）ではいくらSIGINTとかを
Text::Xslateが素敵すぎる（Markdown編） - D-6 [相変わらず根無し]
Text::Xslateが素敵すぎる（Markdown編） 2011年2月17日 10:13 D | ブログ記事のURL | コメント(0) | トラックバック(0) おいおい、Text::Xslate素敵すぎるだろ。 今日Markdownを使いたいと思ってちょっと考えたら、これだけで終了した： use strict; use Text::Xslate; my $xslate = Text::Xslate->new( .... module => [ 'Text::Markdown' => [ 'markdown' ] ] ); print $xslate->render_string( <<EOT, { text => $some_markdown_text ); [% text | markdown | mark_raw %] EOT 素敵！gfx 先生になら抱かれてもいい。 俺もXS
オブジェクト指向とClass::Data::Inheritableは一緒に扱わないほうがいい。 - D-6 [相変わらず根無し]
オブジェクト指向とClass::Data::Inheritableは一緒に扱わないほうがいい。 「オブジェクト指向なパラダイムでプログラムを書くとき」にClass::Data::Inheritableは排除すべきモジュールである。今回激しくそれを痛感しているので、だらだら書いてみたい。 まず、Perlはマルチパラダイムが可能な言語なので、Class::Data::Inheritable自体は否定されるべきものでもないし、あと必ず例外ケースはでてくるのでその際には躊躇なく使えばいいと思う。以下は最初の一文の通り、Perlでオブジェクト指向を使う場合はClass::Data::Inheritableは基本的に使わず、あくまで例外ケースに留めるべきだ、という事を伝えたい。 まずその１： クラスアトリビュートはグローバル変数 クラスアトリビュートはグローバル変数です。異論は認めません。 Singl
M::I::ExtendsMakeTestなかなかいいです＋お願いというかおねだり - D-6 [相変わらず根無し]
M::I::ExtendsMakeTestなかなかいいです＋お願いというかおねだり xaicronさんのModule::Install::ExtendsMakeTestがなかなかいい感じです。以前書いたTest::mysqldのブログ記事を実現するのにもそうですが、任意の環境変数を設定できたり、スクリプトを実行できたりするのがとてもいい感じ。なので、以前の記事に書いていた内容は今は以下のように実装しています replace_default_make_test includes => [ "modules/common/lib" ], env => { MYAPP_CONFIG => 't/config.pl' }, before_run_scripts => [ 't/start_daemons.pl', 't/load_fixtures.pl' ], ; 自分は今プロジェクトの共通モジュ
Plack/Starman Daemontools Run File With Complete Deploy Bundle - D-6 [相変わらず根無し]
Plack/Starman Daemontools Run File With Complete Deploy Bundle 注１：まだ本番にはデプロイしてませんが、テストでは使いました。 注２：以下スクリプトは開発者の労力を減らすためのスクリプトで、万全なデプロイ方法だとか言うわけではありません。 注３：正直シェルスクリプトは素人です。 ここ最近のアプリケーションのバンドル・デプロイについてちょっと固まりつつあるので、書いてみる まず アプリケーションと、その依存関係。デプロイ側のサーバーにはlocal::libと必要なModule::Install系のモジュール、それにModule::Install::Bundle::LocalLibがインストールされている前提です。アプリケーションの依存関係は全部Makefile.PLに書きます。 use inc::Module::Install;
make bundle_local_lib - D-6 [相変わらず根無し]
make bundle_local_lib 最近、miyagawaさんが書いたこちらののツールを多少改変したものを使ってlocal::lib環境にCatalystアプリの全依存関係を突っ込んでからデプロイ、ということをしていました。 が、このツール自体をコピペするのに疲れました。なのでApp::BundleDepsとModule::Install::Bundle::LocalLibというものを作りましたよ！M::I::Bundle::LocalLibのほうはMakefile.PLに1行だけ記述を入れておくとmake bundle_local_libと書くだけで./extlibにlocal::lib環境を作ってくれるというものです。 俺的には超便利！ 想定している使い方はApp::BundleDepsのPOD(cpan github)を見てもらうのが一番よいかもしれません。 これを使うとCa
Test::mysqldとかでテスト走らせる時に際行ったいろんな事。 - D-6 [相変わらず根無し]
Test::mysqldとかでテスト走らせる時に際行ったいろんな事。 Test::mysqldを使うとクールにMySQLを起動させられるので、それを使おうとしたんだ。でもおいらのローカルにあるmysqlをMacPortsのmysqlで、ファイルレイアウトがメタメタなんだ。だからまずこんな感じで、Test::mysqldを継承するMyApp::Test::mysqldを書いたわけさ！ 必要とあればMacPortsとかの環境じゃなくてもMYSQL_INSTALL_DBとMYSQLDを設定すればテスト時にTest::mysqldが見るバイナリを変更できるのがミソだね！ さて、これを使っても、何個もテストスクリプトがある時に一回一回mysqlを立ち上げ直してちゃ意味がない。遅いし、毎回DBの設定をしなくちゃいけないじゃないか！ だもんで、まずmake testが走るときに前もってTest::mys
CatalystはすでにPluginからRoleへ移行するための機能を用意していた - D-6 [相変わらず根無し]
CatalystはすでにPluginからRoleへ移行するための機能を用意していた Pixisががらっと変わろうとしている。最初は単純に継承ではなくRoleでその機能を提供しようと思ってあれこれ考えてたんだけど、その際にCatalyst.pmの中身を見たらsetup_plugins()が・・・ sub setup_plugins { my ( $class, $plugins ) = @_; $class->_plugins( {} ) unless $class->_plugins; $plugins ||= []; my @plugins = Catalyst::Utils::resolve_namespace($class . '::Plugin', 'Catalyst::Plugin', @$plugins); for my $plugin ( reverse @plugins )
Perl App EngineをMac OS Xで動かすまで。 - D-6 [相変わらず根無し]
Perl App EngineをMac OS Xで動かすまで。 先週末、僕が相方とのんびりとしているとメールが入ってきた。「アイデアがあるんだけど」とメール始まるが、僕はピンと来た。これは「やってくれ」という催促だ。僕は身を固くして続きを読み始めた。 JPAのターゲットのひとつにクラウドコンピューティング サポートってのが入っていて，ec2とかで使うことを考えて ました．が，よく考えるとperl-appengineってのがありますね． ああ、ありますね。そうですね。 誰かYAPCでしゃべってくれるといいんですが〜 うは！くっ。僕は肩書きこそ「長」がつくけど、そんなに偉くないので年上＆目上のこの人に「君がやりたまえよぉ」とは言えないので「隙を見つけてやってみよう」と思った。 月曜、きっとやらないとなんか言われるだろうなぁ、と思いつつも忙しくてなにもできなかった。そして今日。メールを山のように
Catalystアプリを継承する - D-6 [相変わらず根無し]
Catalystアプリを継承する Catalystはたいへんすばらしいフレームワークですが、新しいプロジェクトを始める、という時にcatalyst.plでスケルトンから作り直していつものプラグインを設定して・・・みたいな面倒な手間がいろいろあります。 Pixisはなるたけ簡単に新しいアプリを作れるようにしたかったので最初からプラグイン機構を念頭に置いて書き始めましたが、それはあくまで機能の追加にしか使えず、JPAサイトのようにPixisというフレームワークを使って、JPAというサイトがPixis機能を乗っ取るというような場合はそれだけではうまく設計ができませんでした。 これについては悶々と考えていたのですがCatalyst 5.8になり、Mooseベースのオブジェクト指向ができるようになったことでひとつひらめきました。たとえばJPA::Webというアプリを作るとして、基本的にPixisがす
Moosification: Catalyst 5.8に移行した際にちょっと気づいた事。 - D-6 [相変わらず根無し]
Moosification: Catalyst 5.8に移行した際にちょっと気づいた事。 最初からMooseベースでアプリケーションを作るというのは、実務ではなかなか難しいのはわかります。一般論は JPA #02で話すのでおいておきますが（参加申し込みは今日5/12までですよ！）、5.8 からMoose化したCatalystであった問題・注意点をちょっと書き出してみます。 1. use Catalyst Catalyst::Upgradingを読んでいると package MyApp; use Moose; extends 'Catalyst'; __PACKAGE__->setup(qw/ ConfigLoader /); という表記が見られるが、これは気をつけないと駄目。 自分が直面した問題は、path_to()等を使った時に起こった。path_to() は現アプリのルートディレクトリ
Japan Perl Association記者発表してまいりました - D-6 [相変わらず根無し]
Japan Perl Association記者発表してまいりました タイミングの悪い事に本日より数日間ネットにあんまり接続する時間がなさそうなのですが、取り急ぎ： http://codezine.jp/article/detail/3826http://www.atmarkit.co.jp/news/200904/08/jpa.htmlhttp://itpro.nikkeibp.co.jp/article/NEWS/20090408/328083/?SS=imgview&FD=-692367570&ST=lin-serverhttp://journal.mycom.co.jp/news/2009/04/09/010/index.html皆様ありがとうございました！がんばります！ カテゴリ 日常 タグ JPA perl 2009年4月 9日 10:35 D | ブログ記事のURL | コ
JPAの活動内容 - D-6 [相変わらず根無し]
JPAの活動内容 コメントリストを見ていたら未承認のコメントがあったので先ほど承認しておいた。 地方在住の方に関してはJapan Perl Associationは最初から地方での活動を視野に入れて団体を作った、というのは断言しておきます。ちゃんとこれから東京以外の地域でも活動はしていく予定です。 ちなみにまだ未確定ですが第一回セミナーと同時期に関西地区でのセミナーも視野に入れて調整中です。その後も、ニーズに合わせて少しずつ活動を広げていくつもりです。とりあえず考えているのは広島、仙台、北海道あたり。それ以外は行かない、というより、個人的になんの予備知識もないため、これから調査をする必要があります。情報及びヘルプは随時募集いたしますので是非ご連絡ください。ただ、もうしばらくは地盤固めのほうが先に来てしまいがちになるのはどうか理解いただきたい。 なお録画に関しては正直他のことにかまけていて忘
JPA Semniar #1 （第一回旗揚げセミナー！） - D-6 [相変わらず根無し]
JPA Semniar #1 （第一回旗揚げセミナー！） Japan Perl Associationセミナー#1 を開催します。 記念すべき第一回旗揚げセミナーです！ 秋葉原UDXでCatalystを使い倒す話とMoose等の最新ベストプラクティスに関しての話になる予定で、講師はJay Shirley氏です。日本ではまだあまり名前が売れてないかもしれないですが、トップレベルの技術者で、CatalystやDBIx::Classなどを現場でどう生かすのかというノウハウについては絶大なるものを持っています。また、最近ではMatt Trout氏らとEnlightened Perl Origanisation (EPO)という、エンタープライズ分野でPerlを使うためのノウハウやサポートの提供を行う団体を立ち上げています（EPOはThe Perl FoundationなどよりもJPAにかぶるかもし
Data::Localize & Catalyst::Model::Data::Localize - D-6 [相変わらず根無し]
Data::Localize & Catalyst::Model::Data::Localize Data::Localize 0.00001をリリースした。やってることはLocale::Maketextと一緒。主な違い： オブジェクトベース。Locale::Maketextは名前空間をいじってどうのこうのするんですが、これはしない。基本的には登録されているハンドラを全て試す、っていうだけ。デバッグ用のメッセージを一杯仕込んだので、なぜか国際化がされない場合は多分Locale::Maketextより問題箇所の判断が大分楽Locale::Maketextより速い速さに関しては、以下の通り： daisuke@beefcake-7 Data-Localize$ perl -Mblib tools/benchmark/benchmark.pl Rate locale_maketext data_
FUDを広げるのは誰の特にもならないと思うんだ。 - D-6 [相変わらず根無し]
FUDを広げるのは誰の特にもならないと思うんだ。 以下、まぁ書き散らかしです。あんまり推敲してません。すまそ。ちなみに、下記記事に対するブクマはDISも多いけど、素直な反応もちらほらあるようで興味深い。 僕にとってのJavaは2001年に終わってますが・・・。同じ事何回も書かなくちゃいけない言語なんて死んだも同然ですよ。ライブラリもちらばってて何がどこにあるのかわかんないし。 って、書くのは簡単です。多分元記事をテンプレ化してほぼ同じ事をどの言語に対しても僕は書けます。 ただ、エンジニアという職種の人がそんなことしてるのはどうかなぁ、と。エンジニアの使命を問題を解くことです。何でつまづいたかとか、なにがむずかしかったとか、何ができなかったとかそういう事をちゃんと書いて欲しいなと思う。CPANのアップロードとかも状況に対しての認識もなく、「回数」という一面だけで判断をばっさりしてていいのでし
納品するextlibに依存関係を全部つっこんじゃうというのはどうか - D-6 [相変わらず根無し]
納品するextlibに依存関係を全部つっこんじゃうというのはどうか MENTAやNanoAでもextlibにつっこむ云々の話はあったが、とりあえずインストール先のサーバーにアクセス権があるという前提のもと、アプリケーションの依存関係を全部extlibに自動的につっこむスクリプトを書いてみた。 use strict; use CPAN; use Module::CoreList; use Module::ScanDeps; use File::Find::Rule; use File::Spec; use File::Temp qw(tempdir); if (scalar @ARGV != 2) { print <<EOM; Usage: deps2extlib.pl target [extlib] target - the directory or script that you wa
国際化はすげぇつらかった - D-6 [相変わらず根無し]
国際化はすげぇつらかった MojoMojoを使ってみて国際化についてちょっと研究してみた。CPANにはLocale::Maketext, Locale::Maketext::Lexicon, Locale::Maketext::Simple等々色々あって正直よくわからんかったのだが、今回調べてみてようやく把握した。 まず先に行っておくけど、Locale::Maketext::* 系のモジュールのコードは正直クレイジーなので、暇じゃなきゃあんまりソースコードを漁るのはお勧めしない。 国際化の大まかな流れは、文字列IDがあって、それに対応する言語の「翻訳」が存在する、という感じ。Catalystを使っているなら、Catalyst::Plugin::I18Nを使用して、MyApp::I18N名前空間以下に.poや.moファイルなどをおくのが主流。 問題はHTML::FormFuなど、他の国際化さ
「モダンPerl入門」書きました。 - D-6 [相変わらず根無し]
「モダンPerl入門」書きました。 モダンPerl入門 今みたらAmazonでも表紙が入稿されたらしいので宣伝させていただきます。えー、モダンPerl入門という本を翔泳社さんから出版させていただくことになりました。でも最初に断っておきます。誤字脱字はある気がします。ごめんなさいごめんなさい。日本語不得手なんです（こういう時だけ帰国子女カードを使わせていただきます）。 ともあれ、内容的には自分が普段Perlを使っていて、同僚とかに知っておいてほしいな、って思っている実践的な内容ばかり書きました。この本はたとえPerlがメインの言語ではなくともPerlを仕事で使っていて、なおかつ初級〜中級のあたりでうろうろしてしまっている人たち向けに書いています。初級者向けの構文説明はほとんどありません。上級者向けのわけわかんないところはXS以外ありません（はい、XSの入門あります）。ほとんどは、Perlで業
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
