サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
tsucchi.github.com/perl
こんばんはこんばんは。皆様いかがお過ごしでしょうか? ちょっと前のことではありますが、なんかここ最近立て続けに Perl が dis られたり FUD かまされたりしてて、ついイライラしちゃってマジレスしちゃったダメな大人がこちらになります。 さてさて。なんでそんなにイライラしちゃったんだろーなー、とか結構真面目に考えたら、だいたい分かったので書いてみよう、と思ったのだけど、あいにく今はいい感じで酔っ払っているので、話半分くらいにご笑読いただければ幸いであります。 まあぶっちゃけ言語なんて、何でもいいと思うんですよ。 もちろん、文字列処理にアセンブラ使わされたら僕だってキレますし、逆に CPU のキャッシュメモリとか意識しなきゃいけない処理に LL 使わされてももちろんキレますけど、普通に生きていればそういうのってあんま無いはずなんですよね。(どうしても高速に処理したくて泣く泣く C で文
きっかけはこの記事。DBIのプレースホルダーで起こった謎な挙動 - $shibayu36->blog; 「うーん、どう見てもバグっぽいな」と思い、また、自分がメンテしてるDBD::mysqlPPで悩みつつ LIMIT のプレースホルダーを実装したことがあったので、「参考になるかなー」と思って、本家の方のソース読んでみた。 本家だから、かっちょいいパーサとか組んで SQL ステートメント読んでるものとばかり思っていたのだけど、根性でパースしてる感じのソースで、「これは大変だなー」って思った。で、問題っぽいのがこれ。 dbdimp.c 602行目あたり。 /* it would be good to be able to handle any number of cases and orders */ if ((*statement_ptr == 'l' || *statement_ptr =
僕はもうちょっと Module::Install を使った方が良いのではないかと考えている、というお話 最近ちょっと話題だった、CPANモジュールのパッケージングの歴史 とか、あと twitter とか blog とか色々見てて思ったこと。 「Module::Install って、Plugin があるのがいいとこなんだけど、どのプラグインでどの関数が使えるのか分かんなくてハマるよね」、とか、「他にも罠多いし、その辺考えると、最近だと Module::Build 使った方が良くね?」ってのは、多分正論なんだけど、僕はちょっと違うんでないかな、と思っているという話。 Module::Install の長所は、「プラグイン」と「DSL」と言われることが多いのですが、僕は一番の利点は、「M::I 本体をインストールしなくても対象のモジュールをインストールできること」だと思います。この長所はコアモジ
ちょっと前の話なのですが、Test::Mock::ExternalCommandというモジュールを CPAN に ship しました。 外部コマンドを置き換えるモジュールです。記事は前にも書いてたな。 Test::Mock::ExternalCommand というモジュールを書いてみた このモジュール、まあまあ便利に使ってたのですが、最近は Nagios プラグイン書いていなかったのと、バッククォート文字列で変数展開するために、Variable::Expand::AnyLevel というモジュールを書いて、それを使ってるのですが、こいつがだいぶマジカルで(単なる PadWalker のラッパーといえばそれまでなんだけど)、「これ CPAN に上げるの微妙だなー」と思って放置していました。 そしたら、ちょい前に @y_uuki_ さんから、 @tsucchi こんにちはこんにちは。突然で失礼
このページを最初にブックマークしてみませんか?
『tsucchi.github.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く