というわけで、まだ一週間経ってないし、せっかくなので今更感漂いつつも。

去る 2/21 に @honiho さんの主催で IT 勉強会 (っていうかほにったー勉強会？) に行ってきたわけです。

今回が初めての開催ってことらしいですが、スピーカーの面々も面白そうだし、それに何やら一回目って希少価値じゃないですか。ここに加わらない理由はない！ということで参加してみた次第。

てなわけで簡単に総括。

@siritori 氏のセッション

なんちゃって高校生プログラマえりっくがぼやくJinterface　 ～Java×Erlang　最強コンビの作り方～
http://www.slideshare.net/siritori/jinterfacejavaerlang

JinterfaceーErlang の Java バインディングらしいーに関する発表。ものすごいペースで進んでいったけど、とりあえず Erlang という言語の面白さの一端に触れられただけでも大収穫。

自身の消滅を通知したり、外部から監視したり、ってのがとっても簡単にできるらしい。というか、どうやら Smalltalk みたいななんちゃってメッセージパッシングじゃなくて、普通にマシン境界も越えられて、どうやら無垢な実装をしてるっぽい？って話を聞き、自分の中での Erlang 株が急上昇。

.NET バインディング探してみて、無かったら制作に挑戦してみようかしら…などと思ってみたりして。でも、こういう言語は (当人もこの言語自身じゃ大したこと出来ないって言ってた気がするし) 他の言語のグルーになることに価値があるので、こういうバインディングの存在は言語の方向性として正しい道で、もっと評価されてもいいと思う。

時間も圧してて全部触れられなかったので、資料を見てみるけど、ページ辺りの情報密度が希薄でちょっと読みづらいかなー、とは思うけど、まあそれはそれで。

@chokudai 氏のセッション

http://www.chokudai.net/files/honihoni.ppt

アルゴリズムのお話。

自分はこういうのが　滅　法　苦手なので理解できないかなーっと思ってたけど、展開の仕方が丁寧な感じで、純粋に楽しめた。まずはワーストケースでも良いから手を動かして、少しずつ進めていこう、という主張は完璧主義の節がある自分にとっては一種の意識革命だった。

で、TopCoder やってみよう！と〆。自分はちょっと前に登録して参加してみて、色々と絶望したわけだけども…、やっぱり頭使わなきゃなー、という思いは確かにある。そういう点で、このセッションはその頭を使うということの実例を見ることが出来、有意義だった。ではあるけれども、氏も「プログラミングしてて作りたいものが見つけられない人にこそ」と言われていた通り、少なくとも自分は今のところ明確な制作物を抱えている以上、そういう人に対する訴求はどうだろうかなー、と思う。こういう事するのもとっても大事なのは十分理解してるけれども。

あと、最後にプログラマの頭を微妙に骨抜きにする C# を薦めてた！ @chokudai さんは C# 布教活動の強力な賛同者…とﾒﾓﾒﾓ。

今回初めて開催されるということで、簡単に言ってしまえば何があっても驚かないぞ、っていうような心持ちで参加してみたわけで、やっぱりいくつかあれっ、と思う点もあった。やっぱり勉強会自体の時間が短かったと思うのが大きい。スピーカーのお二方が熱の入ったセッションをしてくれたのもあるだろうし、さらに無料で参加させて頂いているわけだけれども、この内容だったら幾らかお金を出させて頂いてでももう少し長い時間ゆっくり、じっくりと参加したかった。とはいえ初回なわけだし、次回もある！とのことなので、次回に期待。

懇親会 & 二次会

本番ですね。とりあえず何か色々喋ってたのは覚えてるｗ

部屋に入ったときからどうしてもいくつかの塊ができてしまうので、ちょっとした自己紹介タイムがあってもよかったかなーと思う。あまり話できなかった人も居るし…主催者様とか…ここら辺はむしろ自分の問題といえばそうなんだが。

で、二次会では Android とか zsh とか Gentoo とか C# とか、謎なくらい布教活動に勤しんでました。ちなみに懇親会でノート PC 広げるのなんてたぶん初めてだと思うけど。

C# のことを Java と大して変わらない言語と思ってらっしゃる方々向けに楽しいコードを書いて啓蒙しましたとさ。でも素数吐かせるワンライナがちゃちゃっと書けなくて、なんというか押しに弱いというか頭が弱いというか、TopCoder みたいなので頭の体操しなきゃなー、みたいなことが過ぎってしまった。

で、MetaTweet もちょっと紹介してみたり。奇跡的にすんなり動いてびっくらこいた。

まとめ

…と、そんなわけで、とっても楽しい一日だったので、次回も是非参加させて頂きたいところ。あわよくば自分も何か発信させて頂きたいかもですね。

参照

俺がぼけーっと読んで自分の感想を書き忘れるに至った、(観測範囲内での) 他の参加者の皆様の記事。

ほにったー:勉強会を終えて

IT勉強会まとめ – chokudai’s Labo blog

ほにったー勉強会に行ってきました – 銀天随筆集

弾丸のような週末 – 高見知英のかいはつにっし

都合上コードを色々参照してるけど、全て 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 で初めてのプログラミングネタかと思われます。頑張ってこれからもネタ増やしていくので生暖かくこのジログを見守って頂ければこれ幸い。