タグ

2007年12月26日のブックマーク (9件)

  • Subversion/branching guide/ja - MediaWiki

    Subversionでのブランチは単独で編集できる"単なる"既存のディレクトリツリーのコピーです。このことによってCVSより柔軟性を持つ一方で正しくソートするためには時に少し訓練しなければなりません。 四半期のリリースのために、brachディレクトリを作成して現在のtrunkから離れてMediaWikiの"phase3"ディレクトリをコピーします: svn mkdir svn+ssh://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_8 svn copy \ svn+ssh://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3 \ svn+ssh://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_8/phase3 svn copy \

  • Dia draws your structured diagrams: Free Windows, Mac OS X and Linux version of the popular open source program

    Screenshot More screenshots. Requirements The current Dia release has been tested successfully on Windows 8.1, 8, 7, Windows Vista and Windows XP, Linux and Mac OS X. The download page provides download packages for Mac OS X and Linux as well as information about Dia on older Windows versions. Troubleshooting If you encounter any problems with dia, please read through the FAQ first. You should als

  • YappoLogs: Class::Componentから見たNEXT問題

    Class::Componentから見たNEXT問題 ちまたで大ブームなNEXTキメェwwwwww問題ですが、Class::Componentを半年作って来て感じた事を Class::ComponentにもClass::C3っぽい挙動をするNEXTメソッドを内蔵しています。 違和感ありますよね?NEXT.pmとかClass::C3とかを使ってるんじゃなくて、内蔵ですからね。 何でかって言うとClass::Componentは、利用する側に対して必要最小限の干渉しかしないというポリシーで書いてあるので、Class::C3とかを使ってないのです。 ソース見ればわかりますが、Class::C3を使うとnextという名前空間をこっそりと追加してたりするので、それを避けたかったのです。 Class::Componentのソースを見ればわかる通り、徹底的に不要な物を隠そうとしてる為ごちゃごちゃしたコー

  • CatalystやDBICのプラグイン/コンポーネントの継承の話 - Charsbar::Note

    NEXTやClass::C3に気持ち悪い一面があるのは事実だけれど、いくらフックポイントを用意しても、空気を読まずにフックポイントの用途を意図的/非意図的に誤解して想定外のことをすれば気持ち悪いことになってしまうのは変わらない。その辺はたとえばフックポイントが豊富に用意されているPlaggerでSmartFeed系のプラグインを使ったあとにソート/フィルタ系の野良プラグインを使おうとしてハマるのといっしょ。 それでもPlaggerの場合はmiyagawaさんがOKしたもの以外はtrunkに入れず、野良の開発陣まで含めてみんな勝手にプラグインをCPANにアップしたりしないという統制がきいていたからCPAN経由での問題はあまり起こらなかったし、ときおり野良プラグインで問題が起こっても「野良だからしょうがないよね」という諦めがあったけれど、Catalystの場合はみんなが玉も石もとりあえずCPA

    CatalystやDBICのプラグイン/コンポーネントの継承の話 - Charsbar::Note
  • つながる若さ― 1981sにかるくシット (mark-wada blog)

    前にも書いたが、1981sの第一回忘年オフ会というのが21日渋谷で開かれた。うちのyusukebe社長が言い出しっぺみたいで、1981年生まれ集まれ見たいなノリの忘年会だっのですが、何と延べ100人くらいが参加したという。社長は3次会までいて翌日の朝帰ってきていた。翌日ああ面白かったと言って、満足感あふれる顔をしていた。 どうも、1981年だけではなく、そのまわりの年代のひとも多く来ていたらしい。あの小飼弾さんも家族連れできていたようだ。またはるばる兵庫県から来た夫もいたとのこと、すごい盛り上がりですね。でも、ぼくらがやっているBPMのオフ会だって、仙台から来てくれた人もいるんですよ。まあいっか。 それで、そのことに関して参加した人がブログに書いたりしているのを少し読んでみて感じたのは、みんな素朴に感動しているんですね。そして、誰もが知らない人なのにすぐに会話ができたとか、ブログだとちょ

    hide-K
    hide-K 2007/12/26
  • hide-k.net#blog: Re: Re: CatalystのNEXTが気持ち悪い説

    Re: CatalystのNEXTが気持ち悪い説 - D-6 [相変わらず根無し] そもそもメソッドの中で親クラスのメソッドを呼ぶタイミングがその他のロジックの前か後かはこのエントリに書いてある継承順云々とはまた違う気がする。書いてあるコードを見ても、それは普通のOOってそういうもんなんじゃないの、としか言いようがないんだが。 ちとうまく伝えることができなかったので、補足。 そもそも表題がまずかったですね。正しくは 「CatalystがPluginにNEXTを使うのが気持ち悪い説」 ですね。ごめんなさい。 で、言いたかったのはOOにおける多重継承の同一メソッド名の呼び出し順序解決としてのNEXTやClass::C3に気持ち悪さを感じているのではなくPluginにおけるメソッド拡張手段としては気持ち悪いということです。 http://b.hatena.ne.jp/miyagawa/#bo

  • hide-k.net#blog: CatalystのNEXTが気持ち悪い説

    Soozy Conference #4あたりからtokuhiromさんが声を大にして言っているCatalystのNEXT気持ち悪い説。 酒の席でこの話になるたびに奥の座敷から大声で呼び出されるCatalystのNEXT気持ち悪い説。 気を抜いてDBICを褒めるとClass::C3も同じじゃねーかとDisられるCatalystのNEXT気持ち悪い説。 僕も激しく同意。なのでちょっとまとめておく。 NEXTを使う場合、こんな感じかと。 use strict; use warnings; use NEXT; package PluginA; sub foo { print "A"; shift->NEXT::foo; } package PluginB; sub foo { print "B"; shift->NEXT::foo; } package Object; use base qw/

  • tokuhirom blog

    Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at

  • Re: CatalystのNEXTが気持ち悪い説 - D-6 [相変わらず根無し]

    Re: CatalystのNEXTが気持ち悪い説 ほえ?なんで? http://blog.hide-k.net/archives/2007/12/catalystnext.php 使う側としては継承順に呼ばれることを期待しているのに、思ったとおりに動かない。 つまり、使う側がプラグインの中身の挙動まで気を使わなければいけない。 これはClass::C3になっても同じ。 「正しい」継承順にメソッド呼ぶのはClass::C3の特徴だからメソッドの呼び出し順に変化はないでしょう。NEXTの場合は親クラスが小クラスより先に呼ばれる事もあるから気持ち悪いけど。 そもそもメソッドの中で親クラスのメソッドを呼ぶタイミングがその他のロジックの前か後かはこのエントリに書いてある継承順云々とはまた違う気がする。書いてあるコードを見ても、それは普通のOOってそういうもんなんじゃないの、としか言いようがないん