駅から迷ってかなり危なっかしかったけど何とか食いっぱぐれることなく到着。交通費も馬鹿にならないからね…

店内はやや広めで綺麗。やっぱり新しい店舗は清潔。厨房は三人体制。あと二郎神のでかさに感動した！店内の緊張感がなんか二郎行き始めの頃の初心な気持ちを思い出させてくれました。

相模大野二郎 大豚 ヤサイニンニクアブラ

そんなわけでこちらが大豚ヤサイニンニクアブラでございます。テーブルにカネシ差し置いてあるしカラメはコールしなかった。

塗り箸と、若干の割り箸、あとレンゲ置いてある。

程良い乳化スープ。たっぷり盛られている野菜と相性が良い。んだけど、食べ進めるうちに特に顕著になるんだけど、塩辛いというか味が濃い。これで後半は相当苦労した。カネシは後から入れるかな、と思っていたがそんな必要は無かった。カラメは少なくとも今回はコールしなくて正解だった。

豚…は写真じゃあまり見えないのはご愛嬌。やや小ぶり (※仙川ホームから見てｗ) だがまあ量は豚って程度に相応。脂の乗りもさることながら肉質がとても柔らかく、味も大変染みていて素晴らしい。実に素晴らしい。

麺。やや平太麺であるけど、前評判で見るように結構短い。だからスープがちょっと飛び散りやすくて少し食べにくかったか。それでも普通に二郎麺してて美味かった。若干柔らかめ、つまり二郎標準な固さか。いずれにせよ塗り箸は喰いにくいね。

ニンニク。粒程度の大きさのニンニクなんだけど、結構量が多くてスープの味わいをかなり左右するくらい。すごくパワフルな味わいになったのだけどもう少し弱くてもいいかなー、などと考えてしまった。とはいえこれはかなり味を引き立たせる重要なファクター。有ると無いとでは、溶かす前と後では味が大違いであった。

アブラは臭みの抜けたピュアな味わいだけど、どちらかというと液体油の強さの方が目につく感じか。だから相対的にそんなにアブラすごいって感じは感じなかった。

で、オプションメニューとして半熟玉子買ったんだけど、カネシの味がしっかり付いた濃厚半熟玉子はすごく美味くて、二郎の口休めに大変役立った。これ無かったらたぶん完食も危うかったかもしれないｗ

まとめ。味も濃く、量も多い。スタミナの付く強烈な味わい。まさに二郎。というか動けなくなるほどではないにせよ食後はかなりきつかった…ｗ

ごちそうさまでした！

前回の二郎レポはさらりとなかったことになってるわけだが、まあ…お察しいただければ、なブレ方だったわけだが、今回ばかりは背に腹は代えられず、捨て身の突撃と相成りました。

仙川二郎 大Ｗ 全部?

9 時前に到着、待ち無しで次のロットで喰えたわけだが、不覚にもコールをスルーしてしまった。というわけで左のは推定全部。

まず麺はちょっと (仙川にしては) 柔らかめ。まあこれに関しては純粋にその瞬間の運が悪かったということだろうから別に構わない。仙川麺なのは確かであってそれなりにうまい。

豚。前回はもう語るに堪えないガチパサ豚だったわけですが…今回はパサも混ざりつつ、結構脂が乗ったそこそこ上質な豚。悪くない。むしろ良い方。

アブラ。なんですかこの量はちょっとすごくないですかレベル。ちょっと調子良くなかったとはいえ俺が胃もたれを起こしたレベル。やばすぎ。

貧弱一般人は…ってレベルではない。油飲みに来てるんじゃなきゃアブラコールは止したほうがいいかと思われます。

恐らくカネシの効きというかスープの出が悪いのをアブラで補おうとしてる、とかそういうことなのかなー、とか邪推。

その他構成要素に関しては特にコメントは無しでございます。

底は脱したかと思われるけど平均線を飛び越えるにはまだまだ時を待つしかなさそう。とはいえ二郎、仙川二郎なのは確か。言いようのない深い悲しみに荒んだ心を癒してくれました。

ごちそうさまでした。

仙川二郎 大Ｗ 全部

まだ慣れないけどやっぱり現行世代カメラの力は絶大でした。すごい。ちょっと赤みがかってしまったが…

で、今回の仙川。ちなみにアブラは珍しく後乗せじゃなかったです。

豚がどしんと鎮座してますが、残念ながら今回はパサ豚、どちらかというと大外れだったかな、といった感じ。もう少し味染みるか柔らかな出来だったら良かったんだが。

とまあ豚は残念だったんだが、今回は麺が素晴らしかった！麺が！もう俺好みでどんなに豚が残念でもこれでもうなんでもよくなった。

なんとも固めな茹で上がり。ポキポキ、というよりはもっちりずっしり、といった趣か。素晴らしい食い応え。素晴らしい。素晴らしすぎる。仙川のこの麺、好みとか色々あるだろうが俺はこれがたまらない。初めて仙川に来たときのことが思い出される…(遠い目

で、スープもそこまで甘くなく、カネシが結構強く効いてて美味しい麺と美味しいスープ、抜群の相乗効果。光と闇があわさって最強にみえた。

ニンニクもいつになく結構大量に入ってて、実に満たされる (ヤク的な意味で)。ちょっと辛めだったけどまあどうでもいい。

アブラは結構美味しかったんだけど来たのが比較的遅かったからか量は少なめでちょっと残念だが自業自得と言わざるを得ない。野菜はいつも通りなんでノーコメント。

一言でまとめると…豚がよければ最高の一杯でした。とまあそんな感じだったが普通に美味かった。ごちそうさまでした！

都合上コードを色々参照してるけど、全て MIT License が適用されてます。まあ見られるくらいどうでもいいけれど。

前説

アプリケーションドメインをラップするコードを書いていたわけだが、AppDomainSetup.ConfigurationFile を設定する必要に駆られた。

順当にやるならばコンストラクタ (このコンストラクタは最終的に AppDomainSetup を作って低レベルのコンストラクタに引き渡している) に引数を追加してやればいいわけだが、そんなことをやってはきりがないのは確定的に明らか。そもそも「次」の引数候補がいつ出るか分からない。抜本的な思考の転換が必要とされていたわけ。

そこでふと思い出したのが、自分がかつて書いた HttpWebRequest をラップするコード。要は Get とかする度にうまいこと HttpWebRequest を裏で作ってくれるわけだけど、この HttpWebRequest をジェネレートする部分を

public Action< HttpWebResponse > ResponseHandler { get; set; }

として公開しているわけ。これを応用しようと思いついた。以上。

Action<T> in constructors

とりあえず最初にコードを出してみる。…と思ったけど例のコードは色々サンプルにならない部分があるので新しく書き起こそうと思う。

例として ProcessStartInfo を挙げた。後は自分の例として HttpWebRequest、AppDomainSetup、の他に CompilerParameters とかでも適用可能だと思う。
変態なクラスしか頭に浮かばないけどご愛敬。まだまだあるはず。ランタイム外でも。

public class SampleClass
{
    public SampleClass(ProcessStartInfo info)
    {
        // ...
    }

    public SampleClass(
        String name,
        params Action< ProcessStartInfo >[] infoInitializers
    )
        : this(_Apply(new ProcessStartInfo(name), infoInitializers))
    {
    }

    private static T _Apply< T >(T obj, IEnumerable< Action< T >> initializers)
    {
        foreach (var f in initializers) f(obj);
        return obj;
    }
}

変なヘルパメソッド作らなきゃいけないのが癪。自分のコードでは怪しげな自前拡張メソッドで済ませているけど。let 欲しい。

つかいかた。

new SampleClass("foo.exe", info => info.Arguments = "123");
new SampleClass("foo.exe",
    info => info.Arguments = "123",
    info => info.UserName = "User"
);
new SampleClass("foo.exe", info =>
{
    info.Arguments = "123";
    info.UserName = "User";
});

おまけ

params Action< T >[] だけでなく、IEnumerable< Action< T >> なオーバーロードもお好みで。LINQ との親和性の問題。params IEnumerable< T > 欲しい。

解説

これは簡単に言ってしまえばオブジェクト初期化子的な柔軟性を与えるわけだけれども、この設計のポイント的な部分を数点。

なぜオブジェクト初期化子ではないのか？

なぜ

new SampleClass(new ProcessStartInfo("foo.exe")
{
    Arguments = "123",
    UserName = "User"
});

ではなく

new SampleClass("foo.exe",
    info => info.Arguments = "123",
    info => info.UserName = "User",
);

なのか。詰まるところ、オブジェクト初期化子は累積的な設定が不可能。つまり、引数とユーザ名のみを独立した引数としたコンストラクタを用意したとき (ここで最後に params Action<ProcessStartInfo>[] を用意するのがミソ)、つまり:

public SampleClass(
    String name,
    String args,
    String user,
    params Action< ProcessStartInfo >[] infoInitializers
)
    : this(name, info =>
      {
          info.Arguments = args;
          info.UserName = user;
      })
{
}

というコンストラクタを置いたときに、さらにパスワードまで設定したい時に、この設計なら

public SampleClass(String name, String args, String user, SecureString pass)
    : this(name, info, info => info.Password = password)
{
}

とできる。オブジェクト初期化子を使った設計の場合は、

new SampleClass(new ProcessStartInfo("foo.exe")
{
    Arguments = args,
    UserName = user,
    Password = pass,
});

といちいち同じ事を書かねばならない。新しいコンストラクタのオーバーロードを作って引数の少ない方から多い方へ流してやればいいというのは問題ではなくて、ここでの問題は、この設計によって、どんな設定であってもオーバーロードを必ずしも作ることなく対応することができ、また作ったとしても更なる設定でも対応可能だということである。副次的に、メソッドの呼び出し (Set～(obj) 等) も可能となる。

params であるということ

上で

public SampleClass(
    String name,
    String args,
    String user,
    params Action< ProcessStartInfo >[] infoInitializers)

というシグネチャを示したが、ここで、このオーバーロードは

new SampleClass("name", "args", "user")

という呼び出しでも当てはまる。params は空の引数を受け入れる。よってユーザはこの追加のイニシャライザ引数を (オーバーロードを別途用意することなく) 意識することなく使用できる。地味に見えて結構大きいポイント。

他には？

あとは…

• 単純な関数オブジェクトのシーケンスなので、どこかの static フィールドに設定を用意しておいて、それを連結したり、あるいは、設定の記述である IEnumerable<Action<T>> を生成する関数を用意したり、と、LINQ とかメタ的なプログラミングの手段も大いに援用できる。
• 順序を伴った動作のカプセル化なので、(特に継承元のクラスのコンストラクタを呼ぶ場合) 既に設定された値を上書きするといったことも可能。

まとめ

オブジェクト初期化子も便利だけど、設定項目が多く、また何が設定される可能性があるか予測が困難であるオブジェクトの初期化はこのパターンを適用するのも面白いんじゃないの？

本稿ではコンストラクタに適用する例を挙げたけど、普通のメソッド設計でも十分有用に思う。

仙川二郎 大Ｗ 全部

ロットの乱れが心配されたがなんとか普通に食えた。なんか書く気がﾏｯﾊなので要点だけ押さえようと思う。

美味かった。

豚があまり見えないのが残念なところではあるのだけど、ほとんどの塊がふわとろ状態で、脂もかなり乗ってて、とても食べやすかった。味も最高。確実に上位レベルの豚。

麺はまさに俺の好きな具合で、ホゴホゴと素晴らしい食い応え。最高一歩手前ってくらい。

アブラもうまい。ヤサイもうまい。ニンニクはちょっと少なかった気もするけど普通にうまい。ただスープはちょっと油がきつかった。悪くはないが。

自分の調子がよろしくなかったのか、美味しい一杯だったが久々に苦戦。もう少しすいすい食べたかったところではある。

全体的に完成度が高かっただけに残念。普通に調子が良ければきっとこのスープももっと楽しめたんじゃないかなと思う。

まあそんなかんじです。今回は自分が二郎に少し負けてしまった感じ。

ごちそうさまでした！

typeof(A<>) みたいな感じで開いたジェネリック型のオブジェクトが取れるというのは面白いネタだけど一般的ではないようなのでたまーに宣伝したりしてます。

結局、次善策は b.BaseType.GetGenericTypeDefinition() == a となると思われる。これだと 1 つ上の親クラスしか見れないし、なんだかなあ、といった感じ。

ちなみに、恐らくこの記事がこの blog で初めてのプログラミングネタかと思われます。頑張ってこれからもネタ増やしていくので生暖かくこのジログを見守って頂ければこれ幸い。

仙川二郎 大Ｗ 全部

で、これが今年の初二郎。

…まず背景説明からしなければならない。簡単なことで、つまりこの右に見える二郎はロット内で一番最初に麺上げされ、一番最後にコールを聞かれたのだ… @zuzucchi 氏に麺が柔らかいという reply を頂いたが、ちょっとこれは別問題か…というわけでスープは幾分か冷めてしまって、麺は柔らかめ (因果関係不明)。良く言えば大変食べやすく、悪く言えば食い応えに欠ける。…まぁ、こればっかりは運が悪かったとしか言いようがない。仕方ないね。

とはいえ、二郎としては悪くない仕上がりであった。麺は確かに柔らかいがいつもの仙川の麺で香り高く、二郎欲を十分に満たしてくれる。二郎の麺の美味しさとは何か？という問いに対する答えをきちんと押さえている。確かに柔らかめなのは残念ではあるが (でも麺固は失敗体験からコールできないでいるｗ) 肝心のポイントはきちんとしているのだ。豚はぱっと見ではガチ豚かと思ったが、写真見ても結構ほろほろしてるのが分かるだろうし、脂のたっぷり乗った端の部分などもしっかり入っており、それなりにいける。中～中の上ってところかと。スープはカネシが結構聞いているが基本的には所謂甘めの状態。これも大好きだけどたまには生姜のがつんと聞いた頭がクラクラしそうなスープも頂きたいところではある。アブラは固体・液体ともにそんなに絶対量は多くなかったが、臭みが無くて個人的には変に量が多くて臭みが残るのより大満足であった。ヤサイはいつも通りであってコメントする要素なし。キャベツの量は元に戻ったｗ ニンニクはちょっと辛めだったけどそもそも絶対量がもっと欲しかったところ。俺が見逃した可能性もあるのかもしれないが…

そんなこんなで、ごちそうさまでした。

俺の 2010 年が始まりました！

で。

Gentoo のリポジトリには Linux DHCPv6 と Dibbler DHCPv6 しかない。で、これらはどうもうまく動いてくれない。WIDE-DHCPv6 でないと動かないという話も聞く。

しかし、バージョン 20080615 をインストールしようとすると make で

In file included from dhcp6c.c:73:
./common.h:158: error: conflicting types for 'dprintf'/usr/include/stdio.h:397: note: previous declaration of 'dprintf' was heremake: *** [dhcp6c.o] Error 1
In file included from dhcp6c.c:73:
./common.h:158: error: conflicting types for 'dprintf'
/usr/include/stdio.h:397: note: previous declaration of 'dprintf' was here
make: *** [dhcp6c.o] Error 1

と怒られて死亡。原因はどうやら glibc の version mismatch だそうで。どうにもならない状況だったがついに解決。以下解決までの軌跡。ちなみに自分の環境は glibc-2.11-r1。

こんな感じ。

今後の目標: ebuild 書いて公開。

今年はなんとか MetaTweet なんとかしたいといういつも通りの言葉をもって目標とします。

…去年も同じだったという突っ込みはパスで

NETのクラスライブラリ設計 開発チーム直伝の設計原則、コーディング標準、パターン

アフィリエイトとかめんどいので (今は？ｗ) つけてない。

さて、ぱらぱらと軽く目を通してみたのだが、これは .NET のクラスライブラリを設計する際のガイドライン集という理解で基本的には問題ないわけだが、そのガイドラインの根拠となる考察、そして多くの識者によるコメントがなされており、またそれが根拠と対立することもあり、そういった内容がこの本を単なるガイドライン本ではなく、クラスライブラリ設計における良質な POV を提供してくれるものとなっている。

これをすべて考慮して設計を行うのはかなりの困難ではあるのは間違いないのだが、しかしながら、各内容に対する考察および反論に関して検討を行うことで、設計を実際に行う際の考慮するための引き出しが増えることだけは、きっと間違いないかと思う。

とりあえずまだきちんと読んでないのでここまで。