Hatena::ブログ(Diary)

猫とC#について書くmatarilloの雑記 Twitter

2014年04月22日

YコンビネータっていうかZコンビネータでラムダ式が再帰関数に変わるからフィボナッチ数も計算できる、Java8版

| YコンビネータっていうかZコンビネータでラムダ式が再帰関数に変わるからフィボナッチ数も計算できる、Java8版を含むブックマーク YコンビネータっていうかZコンビネータでラムダ式が再帰関数に変わるからフィボナッチ数も計算できる、Java8版のブックマークコメント

Java8も出たことだし、ラムダ式で頑張ってみました。

たぶんこういうことだと思いますが、詳しくはきしださんに聞いた方がいいのでしょう。

おとうさん、ぼくにもYコンビネータがわかりましたよ! - きしだのはてな

下のコードQiitaにも置きました

package example;

import java.util.function.*;

public class Program {
  public static void main(String[] args) {
    Function<Integer, Integer> fib
      = Y(f -> n -> n > 1 ? f.apply(n - 1) + f.apply(n - 2) : n);
    System.out.println(fib.apply(8));
  }

  static <A, R> Function<A, R> Y(Function<Function<A, R>, Function<A, R>> f) {
    Recursive<A, R> rec = r -> a -> f.apply(r.applyRec(r)).apply(a);
    return rec.applyRec(rec);
  }
}

@FunctionalInterface
interface Recursive<A, R> {
  public Function<A, R> applyRec(Recursive<A, R> f);
}
トラックバック - http://d.hatena.ne.jp/matarillo/20140422

2014年04月18日

オープンソースは報われない仕事。でもやるんだよ。

| オープンソースは報われない仕事。でもやるんだよ。を含むブックマーク オープンソースは報われない仕事。でもやるんだよ。のブックマークコメント

Microsoftの中の人で、OSSとWeb技術を推進するScott Hanselmanが書いたブログ記事 "Open Source is a thankless job. We do it anyway." を勝手翻訳

オープンソースは報われない仕事。でもやるんだよ。

オープンソースは難しい。

セキュリティは難しい

OpenSSLの最近の "Heartbleed" バグに関する記事がたくさん出回っている。技術的な分析をすべて読んだら丸一日つぶれてしまうだろうが、 その中にこれはと思う見出しがあった。『OpenSSLはオープンソースの大きな問題を示している。資金不足、人員不足』だ。インターネットを織りなす基本の部分は、ほとんどの場合、たった一人と多くのボランティアによるものだ。

猝ノ賄だが気が遠くなるような事実とは、ネットワークインフラストラクチャにおけるこの重要部品こそが、インターネットの大部分で実際に動いているものなのだが、基本的にはフルタイムで作業しているのはたった一人しかいないということだ。

さらに、あるソフトウェアが動作している間は、私たちは貢献者たちの努力成功を褒め称えたりはしない。その代わり、たった一行(重要な行の一つではあったが)が期待に応えなくなるのを待っている。このいまいましい無料の、おおむね動作する、世界規模で接続されたネットワークを動かしているソフトウェアめ。使えねーな。

オープンソースとは、おおむね報われない仕事だ。Microsoft .NETコミュニティの場合、時々むなしくなったりもする。ボランティアが全然見つからないことがあるのだ。多くの人々が、デフォルトのものやVisual Studioに同梱されているものを使う。RailsとかNodeの場合は、企業支援もあるが、プロジェクトはコミュニティが駆動しているという認識がある。現実は中間なのだが、Microsoftのスタック上に構築されたオープンソースプロジェクトでは、ボランティアが「我々は、出荷されたものをただ使うのみだ」なんて言うことがある。

マイクロソフトの過去の行動に対しては「怒り」が存在するけれども、前にも言ったように彼らは「長い」道のりを越えてきた。私はこれからもMicrosoftでオープンソースを推進していく。もう押すのは終わりだ、これ以上押せない、と思うまでは。内部では地殻変動が進んでいる。ミスはあったが正しい方向に進んでいる。誰もが学びの途中だ。

注目されるのは難しい

Jeremy Millerのチームは”FubuMVC”という.NETのオープンソースフレームワークのアクティブな開発を最近停止した。彼の最終的なブログ記事には、NETオープンソースの存続可能性に関する問題が書かれていた。

犲造リアルな疑問、つまり.NETのOSSとは見込みがある計画なのかという疑問を置いておくとしても(答えはおおむね否だ、いくらScott Hanselmanが声を枯らしてそんなことはないと言おうともね)、FubuMVCは失敗した。なぜなら我々は――多分ほとんどは私のせいなのだ、なぜならこれまでのところ最も目立っていたのは私だからだ――自分自身を売り込み、ブログ記事やドキュメントカンファレンスでの発表を通じてコミュニティを構築する努力が足りなかったからだ。

これはまさに真実をついている。多くのオープンソースプロジェクトにとっては、広い意味での可視性が存続可能性の元となっているのだ。Jeremyのふりかえりは素晴らしいのでぜひ読んでみてほしい。

大規模なフレームワークが既に存在しているところに、代替手段となるような大規模フレームワークのプロジェクトを立ち上げるのは難しいことだと思う。多くの人にとってはデフォルトを使用する方が簡単だからだ。FubuMVC、OpenRasta、ServiceStack、Nancyなどのようなフレームワークはすべて「新たにデフォルトを考え直した」ものだ。それらは(いい意味で)独断を行った大規模フレームワークなのであり、現状に甘んじないものたちだ。しかし、大規模フレームワークが支持者を育てるのは、HumanizerJSON.NET のような小さなライブラリよりもはるかに難しいことだ。

それでも、こういったプロジェクトがなければ我々はみんなデフォルトを使用したままだっただろうし、コミュニティとして新しいアイデアを探求したり限界ギリギリを攻めたりすることはなかっただろう。F#のFAKEビルドシステムや、Chocolateyや、Boxstarterみたいには。

MicrosoftはOSSプロジェクトを今よりよい方法でサポートできる。単にライセンスお金だけではなく、可視性においても。Microsoftの全カンファレンスで、オープンソースにトラック提供するよう提案したい。オープンソースコミュニティのメンバーがしゃべる枠を作るのだ。DotNetConfが手始めだが、拡大していけるはずだ。

組織化は難しい

OWINが良い例だ。. NETの世界に影響を与えている、小さいけれどとても重要なプロジェクトだが、組織化に苦労している。それをうまくやることは将来のために重要になってきている。コミュニティの中に小さいけれども影響力を持っているグループがあり、彼らは妥協点を見つけて技術的な問題にまつわるコンセンサスを構築しようとする努力を数か月間続けてきている。

ASP.NET Web APIとSignalRはどちらもOWIN (Open Web Interface in .NET) というオープンソースプロジェクトの上に構築されている。OWINはサーバ、フレームワーク、およびミドルウェアの密結合を分離することが目的だ。

GitHub上に開かれたままのissueがある。その問題は曖昧だがOWINに関して重要な点をついているように思われる。OWINの仕様にはIAppBuilderというインタフェースは含まれていないが、Microsoftのサンプルコードのほとんどにおいて、IAppBuilderはデフォルトで使用されている。根底を支えるOWINフレームワークは中立を保つことができるのか?このissueは長く、何度か横道に脱線している。複雑な問題であり、完全に理解しているのはおそらく20人ぐらいだろう。

Scott KoonはOWINのガバナンスドキュメントに関して頑張っていたが、建設的な動きを目にすることはなかった。彼は不満をTwitterで漏らした。当然のことではある。よく使われる「怠惰なコンセンサス」の技では、人々が沈黙しているか72時間以内に返信しなかった時は、事実上同意したものと見なし、プロジェクトの方向性を変更することができる。積極的な関与こそが重要なのだ。

オープンソースの華はプルリクエストコーディングだけれども、コードを作る前に合意を形成する必要がある。このプロセスの中で最も論争を生む部分は所有権だ。所有権とはコントロールのことだ。方向をコントロールすること。所有権の問題を通じて落としどころを見つけて作業するための鍵は、全員の異なる目標を徹底的に理解して共通のビジョンを見つけることだ。共通のビジョンによって、コミュニティが結集し前進できる。

このソーセージ製造工程は退屈な汚れ仕事だが、必要なのだ。OSSにおいてはコードが占めるよりも多くの部分をこれらの議論が占めている。押しと引きは同程度が必要だ。

関わることは難しい

私は毎週、何十通もの電子メールを受け取る。それらはすべて「オープンソースに関わるにはどうすればいいのでしょうか?」と尋ねるものだ。どうやら誰もが、私の回答は「コードを書け」とか「プルリクエストを送れ」とか、場合によっては「ドキュメント書きを手伝え」だろうと予想しているようなのだ。

実際には、やれることはそれがすべてではない。みんながやるべきことは、読むこと。吸収すること。理解すること。歓迎し、受け入れ、親切にすること。思慮深い分析を提供し、質問をすること。誇張や炎上を招くような言葉を避けること。issueにコメントする際はコード例を示すこと。人の手助けをすること。

ブログ記事はコミュニティを動かすエンジンなのである。オープンソースのコミットも、ドキュメント書きも、プロモーションも、サンプルも、講演も、コード片も、確かに重要なことだ。しかし、オープンソースに関わるということは、「プロジェクトをフォークして、あなたの世界観を反映する巨大なプルリクエストを送信する」ことを必ずしも意味しない。地味な作業が重要なことも時にはある。ガバナンスドキュメントを書いたり電話会議をまとめたり、GitHubの巨大なissueのスレッドで質問をする前に徹底的に読んだりすることが。

なぜこんなことをするのか?モテるためでも金のためでもない。我々が構築者だからだ。誰でもぜひ参加してほしい。やるべきことはたくさんある。

2014年03月21日

朝飯をねだるウナ

| 朝飯をねだるウナを含むブックマーク 朝飯をねだるウナのブックマークコメント

気づくと枕元にいる。そして噛む。噛むなよ。

photo

2014年01月26日

猫の首輪

| 猫の首輪を含むブックマーク 猫の首輪のブックマークコメント

ちょっとわかりにくいですが、チュッパチャップスの首輪にしました。

鈴は取り外してあります。

http://flic.kr/p/jvJxZ4

トラックバック - http://d.hatena.ne.jp/matarillo/20140126

2013年12月17日

Java8とC#

| Java8とC#を含むブックマーク Java8とC#のブックマークコメント

このエントリーは「C# Advent Calendar 2013」の17日目のエントリーです。

前日は id:ksasao さんの「GDI+ で描画&保存あれこれ - まちみのな@はてな」でした。


Java 8は2014年3月リリースされる予定です。

どういう変更が含まれているのかは、Java 8のすべてにまとめられています。

また、きしださん(id:nowokay)のように、Java8に関する記事をたくさん書いている人もちらほらいます。

この記事では、InfoQの記事(および参照元の英語ブログ)を参考に、Java8の新機能をC#と比べてみたいと思います。

インターフェースの改善

インターフェースでstaticメソッド定義できるようになった

もともと、JavaのインターフェースはC#のインターフェースと違って、static finalなフィールドを持つことができました。

static finalなフィールドというのは、C#で言うと、constで修飾された定数と、static readonlyで修飾された読み取り専用フィールドの両方に対応します。

Java 8では、static finalなフィールドに加えて、staticなメソッドの実装も含むことができるようになっています。

C#のインターフェースは、メソッド、プロパティ、イベント、インデクサの宣言しかできません。フィールドとかメソッド実装とかは、インターフェースとは別のクラス(たとえばstaticクラス)に定義するしか方法がありません。まあ、それでも用は足りるでしょうが、別のクラスを定義するのが面倒な人もいるでしょうね。

デフォルトメソッドの定義が可能になった

こっちは、staticなメソッドではなく、インスタンスメソッドです。宣言だけではなくてデフォルト実装を定義できるようになります。デフォルト実装があるメソッドは、実装クラス(implementsするクラス)に実装を定義しなくても、そのメソッドがインスタンスメンバーとして定義されているかのように動きます。

なぜデフォルトメソッドか?というと、interfaceに新しいメソッドを追加したいんだけれども、ただ追加すると既存の実装クラスが全部コンパイルできなくなってしまうからできない、そこでメソッドのデフォルト実装が提供できれば、既存の実装クラスに影響を与えずに新しいメソッドを追加できる、と、こういう理屈です。

C#の場合は、後からメソッドを追加したいという要求には、拡張メソッドという解決法が提供されています。LINQの標準クエリ演算子がその代表例ですね。拡張メソッドの場合は、「元の型の実装を全く変えずに、第3者が拡張メソッドを提供できる」という特徴があります。Java 8ではそのようなことはできません(デフォルトメソッドを定義できるのはインターフェース提供者のみ)が、そのかわり、「メソッド実装の多重継承ができる」「デフォルト実装をオーバーライドすることで、より適した実装に差し替えることができる」という特徴があります。

public interface Foo {
    // 定数
    public const int INT_CONST = 10;
    // 読み取り専用静的フィールド
    public static List<String> LIST_FIELD = new ArrayList<String>();  
    // 【Java8】staticメソッドの実装
    public static int getSize() {
        return LIST_FIELD.size();
    }
    // 抽象メソッド
    public String bar();
    // 【Java8】メソッドのデフォルト実装
    public default int baz() {
        return 42;
    }
}

C#だとこんな感じですが、定数、静的フィールド、staticメソッドがIFooと無関係になってしまいますね。

public interface IFoo
{
    string Bar();
}

public static class Foo
{
    // 定数
    public const int IntConst = 10;
    // 読み取り専用静的フィールド
    public static readonly List<string> ListField = new List<string>();  
    // staticメソッドの実装
    public static int GetSize()
    {
        return ListField.Count;
    }
    // 拡張メソッド
    public static int Baz(this IFoo @this)
    {
        return 42;
    }
}

関数型インターフェース

C# で言うところのデリゲート(delegate)に相当する型は、Java 8では「関数型インターフェース」という名前のインターフェースです。

関数型インターフェースは、toString()以外の抽象メソッドを1つだけ持つインターフェースのことです。

@FunctionalInterfaceというアノテーションをインターフェースにつけておくと、そのインターフェースが関数型インターフェースでないとコンパイルエラーになります。

ただし、@FunctionalInterfaceがなくてもコンパイルは通りますし、後述するラムダ式やメソッド参照も使うことができます。まあなんというか、設計意図コードに埋め込むためだけのものですね。

C# で言うところのデリゲート相当とは言いましたが、C#みたいに+演算子や-演算子を適用して結合したり削除したりすることはできませんし、BeginInvokeEndInvokeによる別スレッド呼び出しなんかもできません。まあC#でもこのあたりの機能は黒歴史というか、なくてもいいので……

@FunctionalInterface
public interface Foo {
    // さっきのFooインターフェースと同じように、
    // 定数やフィールドや静的メソッドやデフォルトメソッドを
    // 定義していたとしても、
    // 抽象メソッドが1つだけであればOK
    public String bar();
}
public delegate string Foo();

ラムダ

C# のラムダによく似た記法のラムダ式が入りました。

goes toの記号が違うだけで、後はほぼ同じです。

Javaとしては、ラムダがなくても匿名内部クラスがあればほぼ同等のことは実現できるのですが、やはり記述が面倒くさいということで、より簡潔に書ける記法としてラムダが導入されています。

ただし、ラムダで書いたときと匿名内部クラスで書いたときは、コンパイル結果が異なります(ただのシンタクティックシュガーではないです)。ここも掘ると面白いのですが、C#とは関係ない世界なのでやめておきましょうか。

(int x, int y) -> { return x + y; }
(x, y) -> x + y
x -> x * x
() -> x
x -> { System.out.println(x); }

C#の場合はdelegateキーワードを使った匿名メソッドによる記法も有効です。でもまあラムダでいいでしょう。

(int x, int y) => { return x + y; }
(x, y) => x + y
x => x * x
() => x
x => { Console.WriteLine(x); }

// 匿名メソッド
delegate(int x, int y) { return x + y; }
// 引数を使わない場合は省略できる謎仕様
Func<int, bool> pred = delegate { return true; };

メソッド参照

C#のデリゲートが名前付きメソッドに関連付けることができるのとほぼ同じです。

String::valueOf  // x -> String.valueOf(x)
Object::toString // x -> x.toString()
x::toString      // () -> x.toString()
ArrayList::new   // () -> new ArrayList<>()

C#の場合は::じゃなくて.ですね。

ただし、C#の場合はコンストラクタをデリゲートに入れる方法がありません。

Convert.ToString // x -> Convert.ToString(x)
x.ToString       // () -> x.ToString()

ラムダとキャプチャ

Javaの場合は、匿名内部クラスと同じように、finalまたは実質的finalである変数しかキャプチャできません。

つまり、読み取り専用変数を読み取ることしかできないということなので、いわゆるクロージャとは若干異なります。

C#ではそういう制限はありません。メンバー変数やローカル変数を書き換えることが可能です。

java.util.function

Java 8には、Function<T, R>Predicate<T>Consumer<T>Supplier<T>BinaryOperator<T>といった関数型インターフェースが標準ライブラリに入りました。

C#のデリゲートとの対応を書いてみましょうか。

Java 8 関数型インターフェースC# デリゲート
Function<T, R>Func<T, TResult>
Predicate<T>Func<T, bool>またはPredicate<T>
Consumer<T>Action<T>
Supplier<T>Func<T>
BinaryOperator<T>Func<T, T, T>

C#のLINQの場合は、Func<T>およびAction<T>の汎用デリゲートに寄せていますが、Java 8では使われ方を表すインターフェースが用意されているようです。

個人的には、C#の汎用デリゲートは「静的型付け言語では型がドキュメントになる」とは言えないので、そんなに好きじゃないです。

java.util.stream

要素のシーケンスで、その要素は必要になって初めて取り出されます。C# で言うところのIEnumerable<T>と、それに対する拡張メソッド群、すなわちLINQに相当します。

APIドキュメントの非公式翻訳java.util.stream (java.util.stream API仕様 b128 非公式翻訳)にあります。

この、ネームスペース解説文が網羅的で良いと思います。

高階関数処理と列挙

C# では、IEnumerable<T>に対して列挙もできるし、LINQ、つまり高階関数による処理もできるのですが、Javaの場合は、列挙用のインターフェース Iterable<T> と 高階関数処理用のインターフェース Stream<T> が分かれています。

これはどうしてでしょうか?

理由のひとつは、ジェネリクスの実装方式が違うためです。

C#では、すべてのジェネリックコレクションと配列がIEnumerable<T>を実装しますが、Javaの場合は、配列はIterable<T>インターフェースを実装しません*1。なので、もしIterable<T>を高階関数処理の対象とすると、配列をIterable<T>に変換する必要が出てきます。

ところがところが、Javaのジェネリクスはプリミティブ型(値型)に対応していないという制約があります。なので、たとえばint[]を変換するとしたら、intのラッパークラスであるIntegerを列挙するIterable<Integer>に変換することはできるかもしれませんが、そうするとボックス化/ボックス化解除が発生するのでパフォーマンスは落ちます。

ボックス化/ボックス化解除を無くしたい場合は、Iterable<T>とは別の型、たとえばIntIterableみたいなプリミティブ型に特化した型*2を新たに作って、そこに変換するしかありません。でもこの型、列挙のためではなくって、高階関数処理のために作ったんだよね……

というわけで、どうせプリミティブ型向けの高階関数処理インターフェースは新たに作らなければならないのだから、いっそのこと全部新しいインターフェースでいいじゃないか、というわけで、オブジェクト用にはStream<T>を、プリミティブ型にはIntStreamLongStreamDoubleStreamを用意したというわけです。

理由のもう一つは、こちらの方が重要なのですが、要素へのアクセス方法と高階関数処理を明確に分離することで、データ構造に適した形で高階関数処理の実装を提供するためです。

C#では、たとえ元のコレクションが木構造だったとしても、Select()などのLINQを適用するとIEnumerable<T>を経由することになってしまい、構造が壊れます。

Java 8では、高階関数処理メソッドは抽象メソッドで、デフォルト実装もありません。木構造用のStream<T>実装を用意すれば、構造を壊さずにmap()などのメソッドを呼び出すことができるでしょう。

LINQの標準クエリ演算子との対応

進捗ダメです。後で書きます。

reduceとcollect

進捗ダメです。後で書きます。

ジェネリック型インターフェースの改善

InfoQの記事によれば、推論が賢くなったみたいです。

C#はまだ貧弱ですね。

class Program
{
    static void Main(string[] args)
    {
        // Java 8みたいに Foo(Utility.Bar()); とは書けない
        Foo(Utility.Bar<FooBar>());

        // Java 8みたいに Utility.Foo().Bar(); とは書けない
        Utility.Foo<FooBar>().Bar();
    }

    static void Foo(FooBar fb)
    {
        Console.WriteLine(fb.Baz);
    }
}

class FooBar
{
    public string Baz = "Baz";

    public void Bar()
    {
        Console.WriteLine("Bar");
    }
}

static class Utility
{
    public static T Foo<T>() where T : class, new()
    {
        return new T();
    }

    public static T Bar<T>() where T : class, new()
    {
        return new T();
    }
}

java.time

きしださんによれば、「めんどくささが増しつつ非常に高機能になりました。」とのことです

C#だと、ローカル時間UTC区別だけできるDateTime構造体、時差を含められるDateTimeOffset構造体、時刻または時間範囲を表すTimeSpan構造体、

タイムゾーンを表現するTimeZoneクラスとTimeZoneInfoクラス、夏時間の期間を表現するDaylightTimeクラス、1つ以上の時代(年号)をもつ暦を表現するCalendarとその派生クラスで和暦を表現するJapaneseCalendar、とこんなところですかね。

C#でもJavaでも、このあたりは非常にややこしいです。C#の場合はDateTime構造体からDateTimeOffset構造体へは暗黙の型変換がありますが、TimeZoneクラスとTimeZoneInfoクラスには互換性はないですね。

Collections APIの拡張

IterableCollectionListMapといったコレクションインターフェースにいくつかデフォルトメソッドが追加されました。重要なのはストリームに変換するstream()メソッドや並列ストリームに変換するparallelStream()メソッドですが、他にも関数型インターフェースを引数にとるforEach()なんかも追加されています。

C#の場合は、すべてのジェネリックコレクションと配列はIEnumerable<T>を実装しているので、「ストリームに変換」する必要はありません。ただし、PLINQで並列処理したい場合は、ParallelEnumerable静的クラスに定義されたAsParallel()拡張メソッドを呼び出す必要があります。

それと、IEnumerable<T>にはForEach()拡張メソッドは用意されていません(LINQに副作用を持ち込みたくないということらしいです)。ForEach()したいときはList<T>クラスを使うか、自分で拡張メソッドを書くか、どちらかですね。

Concurrency APIの拡張

並行プログラミングAPIが拡充されてます。上で書いた並列ストリームに関係する機能もいくつか入っているようです。

C# (というか .NET Framework) の場合はおおむねTPLに対応するという認識です。

Concurrent=並行 と Parallel=並列 の意味の違いは……やめましょうこの話は。

リフレクションとアノテーションの変更

アノテーションというのはC#で言うところのカスタム属性に相当します。

Java8では、型アノテーションと言って、型を利用するところにはどこでもアノテーションをつけられるそうです。

new @Interneed MyObject();
new @NonEmpty @ReadOnly List<String>(myNonEmptyStringSet);
class UnmodifiableList<T> implements @Readonly List<@Readonly T> { ... }
void monitorTemperature() throws @Critical TemperatureException { ... }
myString = (@NonNull String) myObject;
boolean isNonNull = myString instanceof @NonNull String;
class Folder<F extends @Existing File>{ ... }
Doc @Readonly [][] d2 = new Doc @Readonly [2][12]; // Doc の配列の "read-only な配列"

(http://www.slideshare.net/kimuchi583/r5-3-type-annotationより)

C#では今のところできませんが、Java 8でも「こう言うコードが書ける」だけらしいので、まああまり気にしなくてもいいかも。

IO/NIO APIの拡張

Nashorn JavaScript エンジン

java.lang, java.uti, その他の拡張

このあたりは、C#と比べて語るようなことは特にないので省略します。

*1:じゃあ配列を拡張for文で列挙したいときはどうするの?というと、コンパイラが特別扱いします

*2:apache.commonsライブラリにはこういうインターフェースがあります

2013年12月12日

ハイパフォーマンスASP.NETの夢

| ハイパフォーマンスASP.NETの夢を含むブックマーク ハイパフォーマンスASP.NETの夢のブックマークコメント

One ASP.NET Advent Calendarに乗っけるようなネタにはなってないので、とりあえずこっそり書き散らす。

いろんな実行環境、いろんなWebフレームワークマイクロベンチマークをとってる「TechEmpower Framework Benchmarks」というのがあって、しばらく前からちょっと話題になってたみたいです。

測定用アプリはGitHubで公開してて、プルリクエストも受け付けてます。だもんで、「XXフレームワークがないぞ」とか「YYフレームワークの実力はこんなもんじゃねえ」とかいった人たちがどんどんコードを投げ込んでて、TechEmpowerの方でもときどきベンチマークを再測定しているのです。現在の最新は2013/10/31に測定された、Round 7です。

で、ASP.NET。まあ健闘してはいます。全体的に見ればそんなに悪くない。ただ、「シンプルなオブジェクトをJSONにシリアライズして返す」というベンチの結果を見ると、Javaのサーブレットが圧倒的。Responses/Secondのピーク値が、「aspnet」(これ、ASP.NET MVCをIIS上で動かしてるやつです)のざっと7.6倍。で、もっと軽く速くしようっていうので、各種HTTPモジュールを外して、シンプルなHTTPハンドラ(ashxですらない、つまり、SimpleHandlerFactoryも通さない)で実装したのが「aspnet-stripped」。こうすることで「aspnet」の2.1倍にはなったものの、まだまだ*1

http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=json&f=1kw-13ydj4-q2w

Javaのサーブレットはなんでそんなに高性能なんだろうと思ったんですが、最近のJavaアプリケーションサーバーのWebサーバー部分は高性能なんですね。GlassFishのコアであるGrizzlyや、もとJBoss AS、現WildFlyのコアであるUndertowは、非同期I/Oを使って実装されてるようです。どうも、そのあたりがJSONベンチにはうまくハマってて、すごい性能をたたき出しているみたいです。

で、ぼくらの(?) ASP.NET はどうすべえという話です(別に何も気にしなくていい、という意見もあろうかと思いますが、こんなに差がついてたら悔しいじゃん?)

試したいのは、非同期I/Oによるサーバでしょうかね。.NETにはFireflyというサーバ実装があります。KayakやManosはもうメンテされていないっぽいので、こっちのほうがいいのかなと思ったけど、こっちも最新コミットは9か月前ですね……

うーむ。これでがんばるのはしんどいのかな?

しばやんも記事を書いていましたが、Heliosを使って旧来のASP.NETスタックを使わなかったら、ちょう速かったよ、ただしセルフホスト、テメーはダメだなんてなベンチも出てることですし、IISを凌ぐ非同期I/OなWebサーバは難しいのかな?Edge.jsのほうがよかったりする?

……と、そこまで書いておきながら、まだ試してないんです。すみませんすみません。

(追記)

あ、ほんとだ……

http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=json&f=1kw-13ydj4-ux4

http-listener」(HTTP.sysのラッパーであるHttpListsnerクラスをシンプルに使うやつ、OWINですらない)がさすがに速いですね。でもこれもJSONシリアライザを変えたらもちょっと速くなりそうな気もする。

*1:JSONシリアライザをJSON.NETに変えることでも速くなると思います

トラックバック - http://d.hatena.ne.jp/matarillo/20131212

2013年11月26日

ローマ猫

| ローマ猫を含むブックマーク ローマ猫のブックマークコメント

最近、猫成分が足りてなかったようなので。

ローマで撮った「おれ、ねこ」

2011-05-26 182341

トラックバック - http://d.hatena.ne.jp/matarillo/20131126

2013年09月24日

擬似乱数

| 擬似乱数を含むブックマーク 擬似乱数のブックマークコメント

メルセンヌ・ツイスターが(日本人が考案したこともあってか)有名だけど、もちろん他にもいろいろある。

WELL Random number generator(WELLRNG)
メルセンヌ・ツイスターと同様の長周期ジェネレータで、MTより(各種性質が)よいとされる。MTの松本教授もかかわってる。http://www.iro.umontreal.ca/~panneton/WELLRNG.html
ラグ付フィボナッチ法
加算だとALFG、乗算だとMLFG。 http://ja.wikipedia.org/wiki/Lagged_Fibonacci_%E6%B3%95
KISS generator(KISS99)
マーサグリアの手法。KISSはKeep It Simple Stupidのこと。後述するJKISSのように派生アルゴリズムもいろいろある。
Xorshift
同じくマーサグリアの手法。MTやWELLほど周期は長くないが高速。http://ja.wikipedia.org/wiki/Xorshift

なんで突然擬似乱数なのかというと、MonoのRandomクラスの実装が変わったという話を見たから。http://spouliot.wordpress.com/2013/09/23/random-changes/

そこで「JKISS」としてリンクされていたこのPDFがおもしろかった。http://www0.cs.ucl.ac.uk/staff/d.jones/GoodPracticeRNG.pdf つまるところMonoの新しいRandomクラスは、Jones氏による改良版KISSアルゴリズムを使っているということらしい。

トラックバック - http://d.hatena.ne.jp/matarillo/20130924

2013年09月19日

クッキーを焼きたい人は

| クッキーを焼きたい人はを含むブックマーク クッキーを焼きたい人はのブックマークコメント

はてなスターの画像を変更しておいたので、存分にクリックしてください。

トラックバック - http://d.hatena.ne.jp/matarillo/20130919

2013年09月18日

2003年、LongHornは未来だった

| 2003年、LongHornは未来だったを含むブックマーク 2003年、LongHornは未来だったのブックマークコメント

Infragisitics社のIndigo Studioを見て、なんだかWCFのことをIndigoって言ってたころが懐かしくなったので、そのころのMSの様子をWayBackMachineから取り出してみた

Chris Anderson (UI技術のえらいひと、エッセンシャルWPFの著者)と Don Box (COMとSOAPのえらいひと、いまはXBOXチームにいるんだっけ?)が2003年のクリスマス休暇目前にいろいろしゃべってる動画。動画の終わりの方にはクリスマスソングの替え歌なんかも……

Avalon (『シルバー・ベルズ』の替え歌)
Shiny icons, busy icons,
Rendered alpha blend style
On the screen there's a feeling of Longhorn
Children laughing, pixels dancing
Using tile after tile
And on every new desktop you'll see

Avalon, Avalon
It's Longhorn time in the city
Twinkling, rendering
Soon it will be Longhorn day

Strings of vectors, even sectors, 
Blink a bright red and green
As the coders release each new treasure
Shaders code crunch
Quartz is our lunch
This is Bill G's big scene
And behind all this XAML you'll see

Avalon, Avalon
It's Longhorn time on the desktop
Rendering, new bling-bling
Soon it will be Longhorn day
輝くアイコン、時計アイコン
アルファブレンドで描画される
画面はほら、Longhorn気分
子供らが笑う、ドットらは躍る
タイルを次々使用して
新しいデスクトップはすべてそうなるんだ

Avalon、Avalon
街にLonghornがやって来た
きらめいて、描画して
もうすぐLonghornがリリースされるぞ

ベクタグラフィクスの文字列、小さな領域でさえも
赤と緑に明るく点滅
プログラマーが新しい宝物をリリースするたび
ピクセルシェーダのソースコード塊
Quartzが僕らの昼ごはん
ビル・ゲイツの見せ場だぞ
全ての裏にはXAMLがあるんだ

Avalon、Avalon
デスクトップにLonghornがやって来た
描画して、新しい派手さで
もうすぐLonghornがリリースされるぞ
WinFS (『きよしこの夜』の替え歌)
WinFS bound, WinFS bound,
None are lost, all are found
Structured storage out in the wild
Metadata so rich when it's filed
Seen by O'Path's new line
Seen by O'Path's new line

WinFS bound, WinFS bound
Index all works, sights and sounds
Queries reach to the heavens afar
Schemas describe the sands and the stars
Now that Cairo is born
Now that Cairo's reborn
WinFSが固まった WinFSは結びつけた
欠けたものはなく 全てが見つかる
構造化ストレージは野に放たれ
ファイル化されたらメタデータは潤沢
OPathの新しい製品ラインとして
OPathの新しい製品ラインとして

WinFSが固まった WinFSは結びつけた
全てにインデックスをはれ 視覚聴覚
クエリは天国の遠みに達し
スキーマは砂や星を表す
さあ、カイロが生まれたのだ
カイロの復活だ
Indigo (『ジングル・ベル』の替え歌)
XML once was a simple little hack
Now with XSD
There is no turning back
SOAP can make it clean
Simplicity is near
At least until the working groups
let query out next year, oh!

Indigo, Indigo, Indy all the way
Oh, what fun it is to send a message on its way, hey!
Indigo, Indigo, Indy all the way
Oh, what fun it is to keep it HTTP at bay, hey!

Schemas come and go, WSDL is okay
UDDI will not go away
Wire formats bring many standards fights
How do we ship before the day
the profile gets it right, oh!

Indigo, Indigo, Indy all the way
Oh, what fun it is to send a message on its way, hey!
Indigo, Indigo, Indy all the way
Oh, what fun it is to blow J2EE away
XMLはかつて、ちょっとした単純なハックだった
今はXSDがあって
もうあのころには戻れない
SOAPなら物事をきれいにできる
単純性はすぐそこだ
少なくともワーキンググループの連中が
XML-Queryを来年出荷するまではね!

Indigo、Indigo、どこまでも
Indigo流のメッセージ送信、なんて楽しいんだ!
Indigo、Indigo、どこまでも
HTTPを寄せつけない、なんて楽しいんだ!

スキーマが行ったり来たり、WSDLはまあ良し
UDDIはどこにも行かないよ
接続フォーマットは多くの標準化戦争をもたらす
Webサービスプロファイルが決着つけてくれないと
製品の出荷なんてできないよ!

Indigo、Indigo、どこまでも
Indigo流のメッセージ送信、なんて楽しいんだ!
Indigo、Indigo、どこまでも
J2EEを吹っ飛ばす、なんて楽しいんだ!

そんな時代もあったねと。

トラックバック - http://d.hatena.ne.jp/matarillo/20130918

2013年07月25日

IE11入れてみた(1)

| IE11入れてみた(1)を含むブックマーク IE11入れてみた(1)のブックマークコメント

css3test.com は61%。chrome28が68%だから、IE11も健闘してるのでは。

f:id:matarillo:20130726015146p:image

IE11入れてみた(2)

| IE11入れてみた(2)を含むブックマーク IE11入れてみた(2)のブックマークコメント

html5test.comは350+6点。だいたいFirefox15と同レベル。

f:id:matarillo:20130726015647p:image

IE11入れてみた(3)

| IE11入れてみた(3)を含むブックマーク IE11入れてみた(3)のブックマークコメント

F12開発者ツールが結構変わってる。

DOMエクスプローラ。

f:id:matarillo:20130726021849p:image

JavaScriptコンソール

f:id:matarillo:20130726021850p:image

デバッガー。

f:id:matarillo:20130726021851p:image

ネットワーク

f:id:matarillo:20130726021852p:image

UIの応答……はこのページではエラーになった。

f:id:matarillo:20130726021853p:image

プロファイラー。

f:id:matarillo:20130726021854p:image

メモリ。

f:id:matarillo:20130726021855p:image

エミュレーション。プレビュー版だからだろうけど、モードはエッジ(最新)しか選べませんでした。

f:id:matarillo:20130726021856p:image

IE11入れてみた(4)

| IE11入れてみた(4)を含むブックマーク IE11入れてみた(4)のブックマークコメント

そしてこちらが、こないだ話題になったUserAgent文字列。

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; rv:11.0) like Gecko

ん?WoW64だ。x64用をダウンロードしてインストールしたんだけど。そういうものなのかな?

f:id:matarillo:20130726023046p:image

IE11入れてみた(5)

| IE11入れてみた(5)を含むブックマーク IE11入れてみた(5)のブックマークコメント

WebGLサポート。

MSが公開しているテストドライブ( http://ie.microsoft.com/testdrive/ )のデモはそりゃ動くだろうけど、MozillaのデモやChromeのデモだと動いたり動かなかったりって感じ。

https://developer.mozilla.org/ja/demos/detail/zlatnaspirala は動いた。

f:id:matarillo:20130726030111p:image

http://www.chromeexperiments.com/detail/realistic-camera-demo-with-delight/エラーメッセージが出た。

f:id:matarillo:20130726030112p:image

http://www.chromeexperiments.com/detail/flat-surface-shader/ はWebGLを選ぶと真っ黒に。

f:id:matarillo:20130726030113p:image

kkamegawakkamegawa 2013/07/26 08:47 オプションの拡張保護にチェック付いてます?

matarillomatarillo 2013/07/26 08:59 「拡張保護モードを有効にする*」のチェックは外れてます。

kkamegawakkamegawa 2013/07/26 23:02 チェック入れて再起動するとレンダリングプロセスも64bitで動きますよ。
http://blogs.msdn.com/b/ie_ja/archive/2012/03/21/enhanced-protected-mode.aspx

matarillomatarillo 2013/07/27 00:36 おお、IE10のときからこうだったんですね。

2013年07月04日

IEフォビア

| IEフォビアを含むブックマーク IEフォビアのブックマークコメント

IE9べぇ「やれやれ、招かれざる客ってわけかい? 君も僕のことを恨んでいるのかな?」

http://25.media.tumblr.com/tumblr_lhtf40pr5Z1qz5n7eo1_1280.png

W3C標準にあっていない挙動を変えなきゃ変えないでさんざけなされ、W3C標準に合わせる方向に舵を取ったらとったで互換性ないと叩かれ(あるわけないのにね)。身から出た錆とはいちょっとかわいそうになるね、最近MS

MSも、もう少しうまくやれないのかとは思うけど ;-)

IE9とヘルベチカ

| IE9とヘルベチカを含むブックマーク IE9とヘルベチカのブックマークコメント

IE9, IE10が抱えるHelvetica問題について初めて知った件 | IDEA*IDEA

この記事はカス記事。情報が雑すぎ。

IE9がヘルベチカを扱えないという意味不なバグじゃなくて、Vista以降の新しい文字描画APIがType1フォントをサポートしてないという問題ですから。

TrueTypeまたはOpenTypeのヘルベチカをインストールしている人には何の影響もないですから。

百式管理人は、この↓記事を見つける程度の能力がないのか、その手間を惜しんでるのかのどちらか。ソースのあいまいな情報をtwitterで拡散する人たちと一緒。情弱のそしりを免れないよ。

Internet Explorer 9 Type 1 Font Bug, Helvetica IE9 Bug

で、あるべき論から言えば、IE9がType1フォントをサポートしてないのであれば別のフォントにフォールバックするべきであり、画面が真っ白になるのはおかしい、というのはその通りだと思うよ。直せるものなら直してほしい。

でもね。

WindowsにはもともとType1フォントなんて入ってないわけ。Type1フォントは「あえて」インストールしないと入らないわけ。もっと言うとヘルベチカを含むType1フォントはほとんど有償フォントだから、「あえて」「金払ってフォントを買って」インストールした人だけ影響を受けるわけ。そう、あなたみたいにAdobeにたくさんお布施を払っている人とか。

そんな人たちがちょっと困るというバグは、どこまで優先度が高いもんなんだろうね?

もっと言おうか?

利用者のマシンのフォントなんて何が入ってるかわからないわけ。そりゃCSSにはフォールバック機構が定められているけど、だからといって利用者がどんなフォントでWebブラウジングしようが、それは利用者の勝手なわけ。それがWebで、それがハイパーテキストなわけ。(だいたいPDFですら、埋め込みフォントを使わない限り、フォントの指定なんて厳密にはできないわけ。)それでもWindowsマシンであれば、Arialは標準で入っている。

そんなWebで、ArialじゃなくてヘルベチカでWebブラウジングさせたい、というのは、単なるデザイナーエゴでは?

(追記)ふむ、Macには最初からArialとHelveticaが両方入っているのか。で、Helveticaを優先したいと。まあその気持ちは分かる。デザイナーのエゴというのは言い過ぎたかもしれない。いずれにせよ、WindowsユーザーでType1フォントを入れている人でもちゃんと見れることを優先するか、Helvetica指定を優先するか、適切に選べばいい。

IE11のUserAgentからMSIEが消える

| IE11のUserAgentからMSIEが消えるを含むブックマーク IE11のUserAgentからMSIEが消えるのブックマークコメント

Internet Explorer 11: “Don’t call me IE” | NCZOnline

IE11 でユーザエージェント文字列から 「MSIE」 が消えた件 | WWW WATCH

これ「改修工数が…」「影響でかい」「困った」「自分勝手だ」とか騒がれてるけど、IE11のUAがMSIEじゃなくなると実際何が困るのか、騒いでる人はわかっているのかな?

既存の(ダメダメといわれた)IEたちはこれまでと同じUAなわけで、そっちの挙動は何も変わらないんですけど。

IE11は(Acid3が100点なのはいまさら言うまでもなく)いわゆるHTML5対応も進んできて、他のブラウザよりは遅れてるとはいえ、http://html5test.com/のスコアはFirefox15 (2012/9リリース) に追いつくぐらいにはなってるんですけど。あ、http://css3test.com/の方はまだ確認できてないスマヌ。こっちも重要だね。

  • 今まで「IEはモダンブラウザじゃないからサポートしません」と言ってたんだけどサポートせざるを得なくなるから嫌だ、虫唾が走る
  • 今まで -moz--webkit- などにべったべたに依存してたので、Gecko/WebKit/Blink以外だとうちのサイトは表示が崩れます
  • 同じく、Gecko/WebKit/Blinkだけに実装されているJavaScriptの機能をチェックせず呼び出してるので、IE11がその機能を実装してなければスクリプトエラーになってしまう

まあ、こういうことだよね。これまで「Web標準」「モダンブラウザ」「HTML5」とか言ってドヤァしてた人は自業自得ちゃう

空気を読まないMS。そこにシビれるあこがれる、いいぞもっとやれwwって感じ。

で、このサイトはどれに当てはまるんだろうね。

2013年07月02日

Microsoft MVP for Visual C#

| Microsoft MVP for Visual C#を含むブックマーク Microsoft MVP for Visual C#のブックマークコメント

再受賞しました。

なんだかTwitterのタイムライン上は「MSMVP率」なる数値(MSMVP/社員数)が話題です。

いまいる会社は社員数だけは多いので、おもんないですね。

小さいところに行った方が……?いや逆に0.05%とか0.5‰とか500ppmとかい数字の方がおもろいか。

トラックバック - http://d.hatena.ne.jp/matarillo/20130702