ページ

2015年3月31日火曜日

[Azure] クレジットカードじゃなくて請求書払いにしてみた

Azure を普通に使いはじめるとクレジットカードで支払いをすることになります。けど、法人だとクレジットカード払いじゃなくて請求書払い(銀行振込)にしたいということがよくあるんじゃないかと思います。手続きすれば Azure もちゃんと請求書払いにできるそうです。
手順は Azure の請求処理 にあるとおりにすれば OK です。

と言っても、私は請求書払いの手続きをしたことはありません。知り合いの会社さんがやってみたとのことで、その話を聞いただけです。(自分の覚え書きも兼ねてブログっとこうと思った次第)

先に Azure のアカウントとサブスクリプションを作った状態(まだ何も使っていない無料評価版状態)で Azure の請求処理 に書いてあるサポートに連絡したら、その後の手順を詳細に書いたメールがきてその通りに手続きするだけだったとのことでした。かなり丁寧に作業手順を書いてくれていたそうで、特に難しいことも無く、書かれたとおりに進めていくだけだったそうです。ただ、請求書払いにするには与信が必要になるので必要書類を送ったりなど時間的にはちょっとかかると言っていました(それでもそんなにかかるわけではないそうですが。確か 1週間程度で手続きが済んだと言ってたような)。ちなみに、書類のやりとりも Fax や郵送ではなくセキュアなファイル転送ツール?でファイルをやりとりするだけだったとのこと。(具体的にどういうツールを使ったのかはわかりません)
という感じで、クレカ払いのようにネットでポチポチするだけというわけでは無いですが、そんなに手間はかからず変更できるようでした。

Azure サポートのブログにも「Microsoft Azure 請求書について」という記事がありました。

2015年3月25日水曜日

[Azure] SQL Database で identity を使うと値が飛ぶ?

Azure の SQL Database で identity を使ってるですが、たまに値が飛びます。
普段は 1、2、3、、、と普通に連続した数値になってますが、何かの拍子に 12501、12502、12503、22169、、、と突然値が飛びます。これが発生するのはしばらく DB アクセスが無かったときのあととかに多いように思います(が、きちんと調べたわけではありません)。
確かにドキュメントには連続した値が保証されるわけではないというようなことが書いてありますし、まぁ、重複した値が生成されることが無ければいいと言えばいいのですが。。。けど、実際に 1万近く飛んだりするのであまりハデに飛ばれると最大値に予定より早く達してしまうんじゃないかとか、ちょっと不安があります(bigint にしとけばそうそう最大値になることは無いでしょうが)。

検索してみると
http://stackoverflow.com/questions/20797672/azure-sql-server-identity-key-values-jumping-up-by-1-000
こんな感じで同様の報告はいくつもあるんですが、どうも仕様と考えた方がいい感じ。どうしてもイヤなら自分で採番するとかないんでしょうね。

2015年3月20日金曜日

[Xamarin] おぉ!Xamarin は Objective-C や Java より高速だったのか!

(タイトルは釣り用の誇張表現w)

@atsushieno さんのツイートより。

ほう、これは興味深い。
Mobile App Performance Redux」にて iPad Air 2(iOS 8.2)と Moto X(Android 5.0)で同じ意味のコードの速さ比べをやってみたという結果が紹介されています。
速度比べしているのは 600点の GPS 座標のデータ(これ自体は事前に準備)をごにょごにょと計算しながら SessionManager という独自のクラスに格納していくという内容みたいです。これを 1,000回繰り返した時間の 10回の平均なようです。

へ~ぇ、iOS では Swift > Xamarin > Objective-C だったとのこと(Swift が一番高速で次が Xamarin)。Swift と Objective-C ってこんなに速度違うってことにびっくり。そしてなにより Xamarin が Objective-C より速いとは。
ちなみに Xamarin.iOS ではビルド時にネイティブコードにコンパイルします。本家 .NET のようにコンパイル時に中間言語(IL)を作って実行時にそれをアセンブルして動くっていう形ではありません。iOS では実行時にマシンコードを生成するという方法は禁止されている(アプリの審査が通らない)のでこういった方式にはできません。なので、コンパイル時にネイティブコードが生成されます。
※ このあたりが知りたい方は @atsushieno さんの「Xamarin.iOSの仕組みとアプリケーションの構成」とかを読むといいんじゃないかと思います。
というような仕組みなので、ライブラリがきちんと最適化されていてコンパイラが賢ければそれだけ速くなってもまったくおかしくありません。というか、Xcode の Objective-C コンパイラってろくに最適化とかしてないってことなんですかね?

続いて Android。こちらも数値的には Xamarin の方が Java より速いです。が、まぁ、これはほぼ同じと言っていい感じですね。
ちなみに、Xamarin.Android は本家 .NET と同じ仕組みです。コンパイル時には IL が生成されて実行時に mono ランタイムによって解釈されて動きます。また、mono ランタイムは Java ランタイムの上に乗っているのではなく Android OS の上に乗っています。Java ランタイムと横並びになってるわけです。この辺りの話は「Xamarin.Androidの仕組みと、ソフトウェア構成」とかを読むといいんじゃないかと。

ちょっと気になったところ
コメント的に書いてあるところですが、Swift 版で最初は class Point を作って class Gate: Point と Point を継承するって形にしていましたがこれはパフォーマンス的にまずいので、struct Point にして Gate は Point を継承しない形にしたそうです。(Swift はまったく詳しくないのでわかってませんが、.NET の値型・参照型と同じ話なのかな?) たぶん これ とか これ の話じゃないかと思います。
Xamarin 版では、ループの中で DateTime.UtcNow を使ってたのはパフォーマンス上の制限になるので外に追い出したそうです。修正した結果は これ かな?元ネタを探してみたら このやりとり のようです。どうも DateTime.UtcNow はまずローカルタイムを取得してからそれを UTC に変換するので意外と処理量が多いってことなようです。まじですか。びっくりです。

パフォーマンスなんてどんな処理内容かによってガラッと変わったりしますからすべてがこうなるなんてまったく言えないと思いますが、それでもこの記事の内容は、たまに聞く「Xamarin って余計な層が噛んでるからネイティブに比べたら遅いんじゃないの?」というほとんど誤解といっていい指摘には十分な反証となりそうです。

2015年3月17日火曜日

[C#] Xamarin 始めました(始めてます)

始めましたと言っても最初に始めたのは「[勉強会] 第2回 Japan Xamarin User Group Conference 西日本編に参加しました」この記事を書いたちょっと前のことなので、すでに3ヶ月以上が経過しているんですけど。
個人的には Xamarin かなり気に入ってます。まぁ、Visual Studio が使えて C# で書けるって時点で気に入らないわけがないんですが(笑)

ところで、たまに「Xamarin を使うと C# で作ったものが iPhone でも Android でも動くようになるらしい」と誤解している人がいますので一応書いておくと、、、
Xamarin は『プログラミング言語として C# が使えるようになるだけ』です。
たとえば、iOS の加速度センサーからデータを取得するコードを Objective-C で書くとこんな感じです。

// iOS(Objective-C)でのコード
CMMotionManager *manager = [[CMMotionManager alloc] init];
if (manager.accelerometerAvailable) {
    manager.accelerometerUpdateInterval = 0.1;
    [manager startAccelerometerUpdatesToQueue:[NSOperationQueue currentQueue] withHandler:^(CMAccelerometerData *data, NSError *error) {
        // data.acceleration に加速度の値が入っている
    }];
}

これを Xamarin を使って C# で書くとこうなります。

// iOS(C#)でのコード
var manager = new CMMotionManager();
if (manager.DeviceMotionAvailable)
{
    manager.DeviceMotionUpdateInterval = 0.1;
    manager.StartDeviceMotionUpdates(NSOperationQueue.CurrentQueue, (data, error) =>
    {
        // data.Acceleration に加速度の値が入っている
    });
}

見比べればわかるように使っている言語が Objective-C から C# に変わっただけで、使っている API とかはほぼ同じです。
今度は Android で同じく加速度センサーからデータを取得するコードを Java で書くとこんな感じになります。

// Android(Java)でのコード
private SensorManager sensorManager;

@Override
protected void onCreate(Bundle savedInstanceState) {
    sensorManager = (SensorManager)getSystemService(Context.SENSOR_SERVICE);
    List<sensor> sensors = sensorManager.getSensorList(Sensor.TYPE_ACCELEROMETER);
    sensorManager.registerListener(this, sensors.get(0), SensorManager.SENSOR_DELAY_UI);
}

@Override
public void onSensorChanged(SensorEvent event) {
    // event.values に加速度の値が入っている
}

これを Xamarin を使って C# で書くとこうなります。

// Android(C#)でのコード
private SensorManager sensorManager;

protected override void OnCreate(Bundle savedInstanceState) {
    this.sensorManager = (SensorManager)ApplicationContext.GetSystemService(Context.SensorService);
    var sensors = this.sensorManager.GetSensorList(Android.Hardware.SensorType.Accelerometer);
    this.sensorManager.RegisterListener(this, sensors[0], SensorDelay.Ui);
}

public void OnSensorChanged(SensorEvent event) {
    // event.values に加速度の値が入っている
}

こちらも見比べればわかるように使っている言語が Java から C# に変わっただけで、使っている API とかはほぼ同じです。

こんな風に、Xamarin は抽象化レイヤーを持ってるわけでもなくでも無く、プラットフォームが持つ固有の機能をほぼそのままラップして C# で使えるようにしている、と思えばいいんじゃないかと思います。API 自体は iOS や Android のものをそのままクラスライブラリにしてあるだけという感じです。(メソッドの一文字目が大文字になっているとか、CMMotionManager.StartDeviceMotionUpdates メソッドのように引数の型によって判断がつく場合はオーバーロードで済ませるようになっているとか、C# で使って不自然にならないように変更されている部分はあります)
また、Xamarin.iOS と Xamarin.Android はクラスライブラリも含めて基本的に別物です。CMMotionManager クラスは Xamarin.iOS にしかありませんし、SensorManager クラスは Xamarin.Android にしかありません。ですから CMMotionManager クラスを使ったコードは Android では動かないどころかそもそも Xamarin.Android でコンパイルすることができません。こういったプラットフォームによって異なる部分はそもそもソースコードを兼用したりといったことはできないわけですね。もちろん、ラットフォームに依存しない部分、たとえばデータを処理する部分とかは共通化できます。Portable Class Library(PCL)や Shared Project といったそれを支援する機能もあります。MVC や MVVM などでビューとコントローラー、ビューとビューモデルをデータバインディングやメッセージングを使ってきちんと疎結合にしてあげればプラットフォームに依存するビュー部分は iOS や Android ごとに作り、依存しない部分は PCL で共通に、といった感じにできるわけです。(WPF や Windows ストアーアプリと共通化するってことだってできます)

※ Xamarin.Forms というビュー部分を抽象化して iOS、Android、Windows Phone の各プラットフォームのビューを「一度書けばすべてで動く」ようにしてくれる機能もあります。Xamarin.Forms はまだまだ進化の途中という感じですが、これはこれでちょっとしたものを作るときには便利なので応援してます。

今やっているプロジェクトでは iOS、Android の両方に対応する必要があるんですが、ビュー部分だけプラットフォームごとに作ってそれ以外は PCL でまとめています(MVVMCross を使っています)。さらにスマホに閉じたアプリではなくサーバーと通信しあうタイプのアプリなんですが、サーバー側は ASP.NET Web API や SignalR なんかを使ってます。もちろん C# です。さらにサーバーにあるデータを表示したりする Windows アプリも必要なんですがこれは WPF + C# です。とすべて C# で統一できてとても楽になりました。もしこれがスマホが Objective-C と Java で、サーバーが PHP で、Windows アプリが WPF C# で、なんてことになっていたら開発効率的に大変なことになっていたと思います。あと、このアプリはデータを処理・解析する必要があって、それがスマホやサーバー、Windows クライアントのいずれでも動かす必要があるんですが、これももちろん PCL でまとめてあります。なので、同じデータ処理 DLL が iOS、Android、ASP.NET、WPF の中で動いています。最初の頃は mono を使って CentOS 上でも動いてました(諸事情で今は CentOS は使ってませんが)。もしこれがプラットフォームごとに別々に実装しなくてはいけなくなったりしたら気が遠くなります。C/C++ なんかを使えばある程度共用はできると思いますが今ほど簡単にはいかないでしょうし。

と、こんなプロジェクトをやっているんですが正直ちょっと(いや、だいぶ)人手不足です。そのためリアルに求人してるんですが、興味があるっていう人どっかにいないかなぁ(Xamarin 知らなくても C# 好きなら OK)