Hatena::ブログ(Diary)

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

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

2013年06月17日

C#におけるDateTime型/TimeStamp型の変換方法

| C#におけるDateTime型/TimeStamp型の変換方法を含むブックマーク C#におけるDateTime型/TimeStamp型の変換方法のブックマークコメント

元記事: id:yutakikuchi:20130617:1371425713

Web系言語にJavaが入るんだったらC#だって入るんじゃないかな。どうかな。

(追記)あ、C++が入ってるんだ。Web系言語なんだ。

https://gist.github.com/matarillo/5794336

なんか埋め込みが上手くいかない。はてダじゃだめか。

<script src="https://gist.github.com/matarillo/5794336.js"></script>

using System;

class Program
{
    static void Main()
    {
        // 1: 文字列のローカル日付を取得
        var localDate1 = DateTime.Now;
        Console.WriteLine(localDate1.ToString("yyyy-MM-dd HH:mm:ss"));

        // 2: Unix Timestamp 取得
        // .NETのDateTimeは0001/1/1基点なので、変換が必要。
        var timespan2 = DateTime.UtcNow - new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);
        Console.WriteLine((uint)timespan2.TotalSeconds);

        // 3: 文字列のローカル日付をUnix Timestampに変換
        // Parseメソッドはお任せ動作。フォーマットを指定しなくていい。
        var localDate3 = "2013-06-15 12:00:00";
        var timespan3 = DateTime.Parse(localDate3).ToUniversalTime() - new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);
        Console.WriteLine((uint)timespan3.TotalSeconds);

        // 4: Unix Timestampをローカル日付に変換
        var timestamp4 = 1371265200u;
        var localDate4 = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc).AddSeconds(timestamp4).ToLocalTime();
        Console.WriteLine(localDate4.ToString("yyyy-MM-dd HH:mm:ss"));
    }
}

タイムゾーンをちゃんと扱いたいときはDateTimeOffsetを使うとかもあるけど、今回は省略。