unknownplace.org

今日はあるエントリに心を奪われた。

新人プログラマーがプロのプログラマーとして独り立ちするための7つの条件 - ハックルベリーに会いに行く

「無理を通して道理を引っ込ませてこそプロのプログラマー」ということだった。

カッコイイ！

しかし、ん？どっかで聞いたことある台詞だなと思ったら

「そんな道理、私の無理でこじ開ける！」 グラハム・エーカー

同じこと言ってる！

Tさんは現代のグラハム・エーカーと言えよう。会ってみたいなー。

今日 Mouse を最新版にしたら書いていたコードが動かなくなった。

subtype していたところで、

The type constraint 'Ark::Request' has already been created in Mouse::Util::TypeConstraints and cannot be created again in Ark::Context

というエラーになってしまう。これは Mouse の subtype のところのコードを読めばすぐわかるが、違う場所で重複定義しようとしたときに出るエラーだ。

subtype 一回しか書いてないのに重複定義とは何事か、と思ったが、今の Mouse では Mouse でクラスを作るとそのクラスに class_type が設定されるようになってるみたい。

つまりこの場合は Ark::Request は Mouse なクラスなのですでに class_type されているのだが、それをさらに subtype で定義しようとしてエラーになってたというわけ。

こちらの挙動が Moose と同じで、いままでの Mouse のほうがちょっと互換性がなかったということみたい。

というようなことを Mouse メンテナーであるところの tokuhirom 氏や、MouseX ファウンダーであるところの ikasam_a 氏に教えてもらった。ありがとうございます！

あわせて読みたい：

Mouse の subtype に関する非互換 - TokuLog 改めB日記

もう4回目か。。

qudo x skinny (id:nekokak)

qudo はクドーと読む。キュードーだと思ってた！(& キュードーのが良いなぁ)

Skinny は前回(?)も発表したORM。SQL::Parser がしょぼい＆遅いので捨て、ルールベースにしたとのこと。

それはいいんだけど、DSL まくっててちょっと個人的にはやだなぁ。DSL は覚えるのが大変。DSLは ::Declare とかで別途やって欲しい感じ。どちらでも使えるのがいいと思います！

現状は一部足りないところもあるけど、だいたいのところ(id:nekokakさんが普段使う領域)はうごくレベルらしい。

Qudo は TheSchwartz みたいなジョブキュー。TheSchwartz の不満なところを直して、欲しかった物をつけた感じの物。

• ORM に依存しない
• DB 以外にも memcached とかキャッシュサーバーをバックエンドにも使える(予定)
• 適度なHookポイントをつけてプラッガブル！
• エラー処理管理しやすく (イイネ)
• 管理系コマンドも充実 (イイネ)
• テストモジュールも用意 (イイネ)

というかなり良い感じの物になってるので、TheSchwartz つかってる僕としては触ってみたいなと思った。ORM 対応とかは正直 DBI にさえ対応してくれればいいんだけど。。

ZIGOROu さんがMacBookになってる！！

DI x Perl! (id:lestrrat)

DIよくわかってない。

オブジェクトの自動組み立てのことをいうらしい = 依存関係を満たしつつ初期化。

。。。というと？

自分で依存関係を考慮してコーディングしなくていい。なるほど。

どうやるか？ 普段どおりのクラス定義 + 依存性定義ファイル + アセンブラ(なんだろこれ、前二つを結びつけて組み立てる物)

Bread::Board の実際のコード例。見てもよくわからん。

lestrrat化後はどうなるか （今後取り込まれる予定のもの)

クラス構造使いやすく。（こっちの例はいい感じ）

• Bread::Board (coreモジュール、いままでのようにDSLではない)
• Bread::Board::Declare (いままでのようなDSLインタフェース)
• MooseX::Bread::Board もつくったよ

lestrrat化したあとのものは僕にとってもわかりやすく、一度試してみたい。依存性を全く考慮することなくコーディングできるなら確かに楽なのかもしれないなぁ。

やってみないとわからないので、これは取り込まれたら使ってみる。

WAF のつくりかた (id:dann)

おなかすいた。

いろんな言語のWAFの特徴。最近Djangoってる僕としてはPythonのWAFについてまったく調べてないんじゃないの！！ と思ってしまったｗ Django 面白い機能いっぱいありますよ。

で、それらをいいとこ取りしたのが Angelos!

フックポイントは大文字！ きもい！

デフォルトセットの概念は良い。 Module::Setup のフレーバーで定義。いいね。

amazon の MapReduce エラスティックなんちゃら (id:lopnor)

mapper or reducer スクリプトから CPAN モジュールを使用するための方法。

local::lib して jar でかためて云々すれば普通に使えるらしい。

Simo (id:perlcodesample)

Moose とかみたいなやつ。Mouse が存在しなかったら触ってみたかも。

Moose/Mouse との比較があるとよかったかもなぁ。機能比較はもちろんだけど、速度比較とかも。

機能としては MOP 的なものが全くなさそう(?) なので、Moose/Mouse からの移行はなかなか難しそう。

CAPとBASEとEventually Consistent (id:yohei)

職業にふいたｗ

赤ラクダ本とかしらない＞＜ MogileFS とか Perlbal とかの brad プロダクトを使ってるらしい。 MogileFS の運用話は聞いてみたかったけど懇親会で話す機会なかったなぁ。

CAP定理！ どれもとりたいジレンマ。どれかを妥協せざるを得ない。

Webアプリだとたいていの場合 C (Consistency) を妥協。

その C の中の Eventually Consistent というのについての話。これについては「結果整合性」でググれば一番良いページがいちばんうえにくる！ ここ？

BASE とか CAP とか全く知らなかったけど、Eventually Consistent 的な手法というのは Web 開発においてはよくつかわれていて、全然わかる話ではあった。

自分の身近では実際の方法論などばかり話されるばかりで、あういう概念的な話は全く出ないので面白かった。もう少し知りたい。

あわせて読みたい：

• yohei-y:weblog: CAP と BASE について調べたこと
• yohei-y:weblog: CAPのCとACIDのC

LT

MacBookのバッテリー切れてメモがない。

id:IMAKADO の perl-completion.el の説明。早口で perl-completion ユーザーの僕としても難しかった。非ユーザーは理解できなかったかも。

ジョブキューは Qudo で良いよって言う結論。(うろ覚え)

AAFind おもろいｗ やる男がやるプレゼンは新しい。

まとめ

Django本にサインもらった。うれしい

このメモは clmemo.el で書いてるわけだけど、もっと個人的なメモとるように、MacBookにもインストールしてみた。

で、僕のつかってる clmemo のフォーマットは、タイトル行に書いた時間をいれる、本文は Markdown というような物になっていて、この時間を入れるためにこんなパッチを当てていた。

けど今見てみたらそんなパッチ当てる必要もないことがわかった。

こんな感じ、

(require 'clmemo)

(setq clmemo-file-name "~/clmemo.txt")
(setq clmemo-time-string-with-weekday t)

(setq clmemo-subtitle-char "[")
(setq clmemo-subtitle-punctuation-char '(" [" . "]"))

(defadvice clmemo-get-title (after clmemo-get-title-with-time () activate)
  (setq ad-return-value (concat (format-time-string "%H:%M ") ad-return-value)))

でやればこのメモのフォーマットになる。いいね！

clmemo.el のソースも昔は意味不明だったけど今はだいたいわかるし。やっぱり emacs つかうなら elisp 理解できないと損というか、もったいないなぁ。ということがわかった。

昨日のやつに言及いただいた。

midnight.el で毎日 0 時に古いバッファを削除する - (rubikitch loves (Emacs Ruby CUI))

標準添付の midnight.el とかどうだろうか。

まさにこれがやりたかった。ありがとうございます！

で、設定ファイル書かなくても全部 customize だけでできるみたい。

customize-group midnight して midnight-mode を on にすれば OK。ノーマルバッファの削除間隔はデフォルトだと3日だが、ちょっと短いのでそこも 7 とかに変更した。

あとはまぁデフォルトで良いかな。

気がつくとemacsのバッファがすごい数になっていて補完などが重くなるのである程度たまったら自動で古い物(しばらくvisitしてない物)を自動的に削除するようなものが欲しい。

とりあえずぼくのelisp力ではあんまり難しいことはできないので

(defun kill-old-buffers ()
  (interactive)
  (let ((count 0))
    (dolist (b (buffer-list))
      (incf count)
      (if (> count 100)
          (or (buffer-modified-p b)
              (kill-buffer b))))))

とかいうのを書いてとりあえずはしのぐことにした。これは最後に使ったバッファ100個のこし、それ以前のバッファで修正フラグがたってないものを全部殺すというもの。

(buffer-list) でとれるリストは anything などのように故意に最後に自分を突っ込んでる物以外はだいたい最後に訪問した順にくるようになってると思うのでまぁだいたいこれでやりたいことはできている感じ。

100個より古いバッファとかもうほとんど参照しないよね。必要になったら開き直せば全然かまわない。

package FCGI::ProcManager::Debug; use strict; use warnings; use base qw/FCGI::ProcManager/;

sub pm_manage {
    my $res = shift->SUPER::pm_manage(@_);

    # manager does not return pm_manage, so below code should run in server only
    $0 = 'perl-fcgi (waiting)';
    $res;
}

sub pm_pre_dispatch {
    $0 = sprintf('perl-fcgi (started %s)', scalar localtime);
    shift->SUPER::pm_pre_dispatch(@_);
}

sub pm_post_dispatch {
    $0 = 'perl-fcgi (waiting)';
    shift->SUPER::pm_pre_dispatch(@_);
}

1;

こんな感じの ProcManager のサブクラスを作り、これを代わりに使用すると、psコマンドでperlプロセスが詰まってないか確認することができるようになる。

プロセスが待機中の時は

perl-fcgi (waiting)

実行中の場合は

perl-fcgi (started Fri Apr  3 14:39:25 2009)

とスクリプト実行開始時間がでるので、それを元に探せばいい。$ENV{PATH_INFO} 等も表示させるともっと親切かも。

Catalyst のアプリの場合、

./script/myapp_fastcgi.pl -manager FCGI::ProcManager::Debug

等とすると使用するmanagerクラスを変更できるようになってるから、コードを変更せずすぐに導入できる点もグッド。

YappoLogs: danさんのllevalをもっと便利にするラッパー作った

一時はcodepadの1/100くらいの利便性まで下がってしまって心配しましたが、80倍便利になってぼくたちのDan the APIが帰って来ました。

ということで、emacs からたたけるようにしてみました。

lleval.el

先日作成した codepad.el と同じようなインターフェースになっていて、M-x lleval-buffer でバッファをllevalする、M-x lleval-region で選択したリージョンを lleval する、となっています。

言語はメジャーモードから自動判別されます。

codepad よりレスポンスがはやくて快適ですね！

Enjoy!

こういうようなFastCGI用の設定のCGIバージョン。

こんな感じかなー。

server.document-root = "/Users/typester/dev/scratch/myapp/root"

$HTTP["url"] !~ "^/(css/|images?/|js/|static/|tmp/|[^/]+\.[^/]+$)" {
    cgi.assign = ( "" => "" )
    alias.url = (
        "" => "/Users/typester/dev/scratch/myapp/script/myapp.cgi",
    )
}

おもむろに Xcode のドキュメントを検索すると CGGetOnlineDisplayList とかいう関数が見つかったので

#include <CoreFoundation/CoreFoundation.h>
#include <ApplicationServices/ApplicationServices.h>

int main (int argc, const char * argv[]) {
    CGDisplayCount    displayCount;
    CGDirectDisplayID displays[4];
    int               i;

    CGGetOnlineDisplayList(4, displays, &displayCount);

    for (i = 0; i < displayCount; ++i) {
        CGRect rect = CGDisplayBounds(displays[i]);
        printf("%d: %.0fx%.0f ( ", i, rect.size.width, rect.size.height);

        if (CGDisplayIsActive(displays[i]))
            printf("active ");

        if (CGDisplayIsAsleep(displays[i]))
            printf("sleep ");

        if (CGDisplayIsBuiltin(displays[i]))
            printf("builtin ");

        if (CGDisplayIsMain(displays[i]))
            printf("main ");

        if (CGDisplayIsOnline(displays[i]))
            printf("online ");

        printf(")\n");
    }

    return 0;
}

とかいうのを書いてみた。これで、

$ ./dispinfo
0: 1280x800 ( active builtin main online )
1: 1024x768 ( active online )

とかいう出力が得られる。

のだけど、ディスプレイの電源（上記の1）を切ってもこのプログラムの出力は全く変わらない。ケーブルを抜くと出力から消える。

ここではケーブルは指したままで、ディスプレイの電源が落ちたことを検知したいという状況なので全然使えない。。

どーしたらいいんだろ？