クリエイティブWeb - プログラミング

Python をメインに使うようになりました

2019-02-13T09:38:00+09:00

久しぶりにブログを書きます。2年近く更新ができていませんでしたが、Web サイトをどうするかで迷っていました。Windows系を中心に書いてきたのですが、現在は、Python、PostgrSQL を中心に使うようになっています。それで、記事の内容と現在の自分のしていることがずれてしまってしまいました。もうこの Web サイトを止めようと思うこともしばしばでしたが、個人ブログなので、メモ帳代わりに気軽に書いた方がいいのではないかと思って再開することにします。本体の記事の方も修正していきたいと思っていますがぼちぼちとした修正になると思います。

最近、5374 の Python 版を作りました。徳島市では、今月から一部の地域で家庭ごみの収集日等が変わることになったので、止めようかと思ったのですが、Python で書くと結構簡単に作れると思ったので作ってみました。ソースコードの方は、GitHub の方に公開されているので、興味があればみてください。

py5374

また、Qiita の方には、昨年末に「ExcelにPythonが搭載？その後 - xlwings を使おう」という記事を書きました。もう既に Python 製の OSS のライブラリー xlwings だと問題なく Excel の操作ができるので便利です。マイクロソフトは、Office を事務職のためのツールとして位置づけていると思うので、マイクロソフトには期待せずに OSS を応援したほうがいいように思います。

こういうことを本体の記事にも少しずつ反映していこうと思います。小さな努力ですが、続けていくことが重要だと思っています。

.NET Core Tools 1.0 が公開されて思うこと

2017-03-10T09:46:00+09:00

3月7日に Visual Studio 2017 が正式リリースされましたが、それと一緒に、やっと .NET Core Tools 1.0 が正式リリースされました。.NET Core RC1 が公開されたのは、2015年11月18日でした。その当時は、ASP.NET 5 のためのフレームワークという色彩が強かったのですが、その後にいろんな経緯があって Tools の部分は1年4ヶ月もかかって正式リリースされました。いろいろあったようですが結果的には良かったよぅな気がします。

ところで、Visual Studio は今年 20 周年を迎えたそうです。自分が始めて Visual Studio を使ったのは、Visual Web Developer 2005 Express Edition でした。ASP.NET Web Form のアプリが作れるのですが、Web Form は、Web アプリを作るツールであるのもかかわらず、HTML、CSS が使いづらく、Microsoft のコンポーネントを使わないといけないという全く不便なツールでした。

それで、もう使うのを止めようと思ったのですが、Express Edition を使っていても Standard Edition のアプウグレード版を購入できるというキャンペーンがあったので、Standard Edition を購入して、ASP.NET Web Form を使わずに Web サイトを作りました。それが、徳島の交通状況 Google Maps API 版で、ソースは GitHub の TKGMapに公開しています。

その後も Web Form には馴染めなかったので、Python を勉強し始めました。その時に丁度 ASP.NET MVC がアナウンスされたので、それを使って見たら結構使いやすかったのでそれをメインに使うようになりました。ASP.NET Core は RC の時から使っていますが、ASP.NET MVC の時も CTP から使っていました。

.NET Core 及び ASP.NET Core については、いろいろな評価がありますが、既存のユーザーをスムーズに移行させられるかということと新しいユーザーを獲得できるかということが重要だと思います。

既存ユーザーの件については、ライブラリーの .NET Core 対応が余り進んでいないという点からみると成功していないように思います。RC から RTM になるまで 1年4ヶ月もかかってしまった原因の一つになっていると思いますが、.NET Core 2.0 に期待したいと思います。.NET Core 2.0 では、.NET Statndard 2.0 対応となり、APIが現在の2倍以上にして.NET Framework や Xamarin との互換性がよくなるということです。過去のバージョンとの互換性はやはり必要だと思います。

新規ユーザーは従来より増えているというのは確かですが、どの程度伸びるかは今後に期待したいと思います。Web Form に馴染めなかった自分に取っては、ASP.NET Core は、以前の ASP.NET MVC よりもわかりやすくなって随分よくなったと感じています。特に、Web Form の影響が大きい System.Web が無くなったのはすっきりしたと思います。

市区町村コード表（履歴付）を作成する .NET Core アプリを公開しました

2017-02-20T12:17:00+09:00

国勢調査等の市区町村別の統計データを過去から集計して比較しようとすると、平成の大合併により過去のデータは合併前の市町村のデータを集計する必要があり、普通に手作業ですると非常に手間のかかる作業になります。

政府統計の総合窓口（e-stat）の統計LODで、1970年以降の標標準地域コードのデータが公開されているので、それを利用して、任意の時点での市区町村コード表の作成や対応表が作成できるデータベースを作成するコンソールアプリケーションを作成しました。

.NET Core で作成したので、Windows だけでなく、Mac や Linux でも動作するし、.NET Core はインストールも手軽で簡単に動作させられるようになったので GitHub で公開してみました。URL は、以下のとおりです。

NAreaCode

このアプリを作っていて気がついた点を2点メモしておきます。

コマンドラインの解析

コマンドラインの解析には、Microsoft.Extensions.CommandLineUtils を使いました。CommandLineUtils は、.NET Core になってやっと組み込まれた機能です。

以前の Microsoft はエンタープライズ向けのことには熱心なのですがシンプルに処理をするということにはあまり力が入っていなかったように思っていましたが、.NET Core、ASP.NET Core になって、シンプルに作りたい場合にも使いやすくなったと思います。コマンドラインの解析は、簡単そうですが実際に自分で作るとなると結構手間がかかるので、.NET Core になって改善された典型的な例だと思います。

コード表の処理速度

作成した市区町村コードのデータは、json形式にしています。例えば、期間付き市区町村コードは以下のような形式になっていて、4588件のレコードがあります。

public class StandardAreaCode
{
    [JsonProperty("id")]
    public int Id { get; set; }
    public string 名称 { get; set; }
    public string ふりがな { get; set; }
    public string 英語名 { get; set; }
    public 自治体種別 種別 { get; set;}
    //北海道、東京都島嶼部、長崎県対馬（旧）は支庁・振興局、その他の町村は郡、区は政令指定都市のコード
    public int 所属 { get; set; }
    //北海道及び旧長崎県対馬支庁の町村のみ
    public string 郡名称 { get; set; }
    public string 郡ふりがな { get; set; }
    public DateTime 施行年月日 { get; set; }
    public DateTime 廃止年月日 { get; set; }
    public List<int> 施行データ { get; set; }
    public List<int> 廃止データ { get; set; }
}

これらのデータを Web アプリケーションの中で使う時に、RDB にインポートするのは面倒なので、メモリーベースで処理をするということで、処理時間を計測してみました。都道府県毎に市区町村コードの一覧を計算する処理で、画面の例は「北海道の市区町村コード一覧」です。また、一覧を計算するコードのメインは以下のようになっていて、LINQ を使うのであれば、リストや配列の場合でも SQL Server を使うのとほぼ同じコードで書くことができます。

public IEnumerable<(int id, string 名称, string ふりがな)> GetAreaCode(int pref, DateTime date) =>
    AreaCodeList
    .Where(x => x.Id / 1000 == pref && x.施行年月日 <= date && x.廃止年月日 > date && x.所属 != 99)
    .Select(x => (id: x.Id, 名称: x.名称, ふりがな: x.ふりがな))
    .OrderBy(x => x.id);

Google Compute Engine の n1-standard-2 （AWS の m4.large とほぼ同性能）を使って処理時間を計測すると以下のようになりました。

ファイルサイズ 1126KB
データの読み込み時間 45ms
計算時間 0.4～0.008ms

結果としては、SQL Server Express を使うよりも遙かに早いです。計算時間の 0.4ミリ秒は初回の計算の時で計算ルーティンやデータが CPU のキャッシュメモリーに入っていない場合の処理時間です。計算の必要なコードとデータが CPU のキャッシュメモリにキャッシュされてしまえば 0.008ms という圧倒的な速さで処理がなされます。こういう処理ではデータのやりとりにばっかり時間を食っていて、本当の計算時間なんてごく僅かのものだなと感じます。

そういうことで、データー量がそれほど大きくないコード関係は RDB を使うのをやめてメモリーに乗せていこうと思っています。管理も、RDB で管理するよりも、テキストベースにして git で管理した方が遙かに管理しやすいし、入力もデータベース用の入力画面を使うよりも、テキストエディターや Excel で編集できた方が楽です。RDB をやめることの欠点ってといえば、コードを修正する毎にアプリをデプロイしなければいけないので、その手間が増えるのですが、昔と違って今はデプロイが楽になっているのでデータの更新の頻度ににもよりますがそれほどの負担にはならないと思います。

Visual Studio 2017 RC を使ってみた

2017-02-02T22:46:00+09:00

Visual Studio 2017 RC のアップデートがあり、「.NET CoreおよびASP.NET Core のワークロードは、もはやプレビュー版ではない。.NET Core およびASP.NET Core の Toolのいくらかのバグを修正し、使いやすさを改善した」ということなので使ってみました。

.NET Core SDK の preview2 までは、プロジェクトファイルが project.json でしたが、Visual Studio 2017 では、MSBuild の .csproj 形式に変更になりました。それがどうなっているか知りたかったためです。

Visual Studio 2017 で project.json 形式のプロジェクトを開こうとすると、以下のように一方向のアップグレードというメッセージがでます。

ここで、「OK」をクリックすると、.csproj 形式に変更されます。それでアップグレードは完了で、動作します。

ただし、このアップグレードは、完全ではないようなので、Project.json と MSBuild の .csproj 形式の対応を調べたい場合は、Hanselman 氏のブログにあったのですが、次の記事が参考になりました。

Project.json to MSBuild conversion guide

Project.json と .csproj のどちらがいいのかという議論はあると思うのですが、.csproj の方もかなり簡単になっているので、.csproj でいいのかなと思います。自分の場合は、今回の変更については問題はなかったです。

このサイトも、アップグレードして Visual Studio 2017 用にしました。Visual Studio 2017 の方は、バグらしきものはまだ残っていますが、Visual Studio 2015 と同じレベルで使えています。

「ASP.NET Core アプリを Linux サーバーで公開」のページの方も.csproj 形式の方に更新しました。

Python を始めました

2017-01-14T22:20:00+09:00

最近 Python を使い始めました。そうはいっても ASP.NET Core の代わりに Python を使うわけではありません。ASP.NET Core は、いいソフトだと思っているので、Web アプリの関係では、これからも使うつもりです。。

自分が .NET Framework ではなくて .NET Core を使う場合に困ることは、System.Drawing がないこと、Excelファイルを読み書きする NPI 等のライブラリーや数値計算用のライブラリーが .NET Core には対応していないことです。

これをどうするか考えていくと、こういう処理は C# ではなくて Python の方が得意なので、C# でライブラリーを探したり自分で作ったりするよりは、Python を使った方がベターだと思ったためです。

ところで、Python の方も Python 3 が出たのは、2008年だからもう8年も経っています。それでも Python 2 系使っているところが多いようです。確かに互換性がないとプログラムの修正は大変です。.NET Core の場合でもサードパーティのライブラリーの対応はなかなか進んでいません。.NET Core の場合は、.NET Core 2 で .NET Standard 2.0 に対応して、従来の .NET Framework と互換性がかなり良くなるようなので、どうなるのか楽しみですが、対応には時間がかかるというのが現実だと思います。

Python 2 と Python 3 のどちらを使うのかという点ですが、やっと殆どのライブラリーが Python 3 に対応したそうで、それに自分の場合は過去のしがらみがないので Python 3 にしました。

Python の環境構築には、miniconda を使いました。Python の環境構築の方法は何種類かありますが、科学計算ライブラリを使う場合は anaconda を使うと管理が楽で、デファクトになっているようです。

Python の IDE は、Visual Studio に Python Tools for Visual Studio をインストールしたものと Jetbrains 社の PyCharm の Commnity Edition を使っていて、どちらが使いやすいかテスト中です。PyCharm は、Web アプリを作らないのであれば、特にPro版を買わなくてもすみそうです。

Excel のファイルを操作するライブラリーには、openpyxl、xlsxwriter、xlrd、xlwt があって、一応 xls と xlsx の両方のファイルを読み書きできるようです。自分が必要なのは取りあえず、xls ファイルのデータを読み込む xlrd なので、それを試してみたら日本語も読むことができました。

現在は、「入門 Python 3」で勉強中です。他の言語が使えるのであれば、Python は1週間あればそれなりには使えるようになります。プログラム言語を複数使うのは、頭がこんがらがってくるので、したくはないのですが、C# はビジネス向けが強くて、科学計算に使っている人はそれほど多くないと思います。プログラム言語が沢山あるということは、その数だけ用途があるということだと思うので、用途によってその分野に強いプログラム言語を使うというのは仕方がないことのように思います。

ASP.NET Core でボットネット対策（その１ middlewareを使う）

2016-12-20T15:10:00+09:00

DDoS 攻撃への対応

この記事は「ASP.NET Advent Calendar 2016 - Qiita」の20日目になります。

昨日のブログでは、ボットネットからアクセスがあることを書きましたが、その中で Google Cloud Datastore は自動スケールするので役に立ちそうだということを書きました。自動スケールされると破産するのではと心配する人もいると思いますが、Google Cloud では費用制限を設定するので破産することはないし、1秒間に1万回の読み込みをしても、1時間だと $21.6 とそれほど大したことはありません。

ただし、攻撃を放置しておくと結構な料金になってしまうので、攻撃を止める方法を考えてみました。

まず、DDoS 攻撃の現状がどうなっているかについては、Googleのシンクタンク部門である Google Ideas とセキュリティ企業の Arbor Networks と協力して、DDoS攻撃の状況をリアルタイムで表示するDigital Attack Mapを公開しています。そのサイトの Understanding DDoS によると、1週間小さな組織のシステムをダウンさせる能力があるボットネットを $150 で借りられるそうです。自分の場合は、最初はこの程度でできる攻撃への対応を考えてみようと思っています。

DDoS 攻撃への対応

攻撃を止める基本は、ボットのIPアドレスを特定して、そこからのアクセスを拒否することです。IPアドレスが特定できれば、アクセスの拒否については、ファイアーウォール、リバースプロキシーでも簡単にできます。そのため、DoS攻撃の場合は、比較的簡単に防御できます。

しかし、DDoS 攻撃の場合は、大量のボットから攻撃があるので、そもそも正常なアクセスなのか攻撃なのかを区別するのが容易でないし、攻撃元を特定して遮断していく作業は容易でありません。もし、攻撃元がボットをどんどん変更して攻撃してくれば、対応は本当に困難になります。

HTTP リクエストの場合、接続する URL 以外に IPアドレス、Referer、User-Agent の情報が送られてきます。低価格で借りたボットネットであれば、これらの情報に片寄りが生じるはずなので情報をうまく解析すれば、ボットのIPアドレスは特定できるはずです。

また、Pokémon GO で有名になったコイル警備員、すなわち Google の reCAPTCHA を使うことも有効です。アクセス拒否は、もし間違って拒否をするとそのユーザーを失うことになるので、疑わしいという状況では使いたくありません。でも、コイル警備員だとユーザー側の負担は遙かに軽いので、疑わしIPアドレスに対して使う事ができます。

Middleware を作成して特定のIPアドレスからのアクセスを拒否する

まず最初に、ASP.NET Core アプリケーションで、特定のIPアドレスからのアクセスを拒否するケースを考えてみます。

この場合には、HTTP Request があって、そのリクエストが MVC の処理に入るまでに処理をする必要があるため、Middleware を作成して処理する必要があります。ASP.NET Core の Middleware の Document に、middleware pipelineの図（下図）がありますが、

その図をみれば、どう処理をしたらいいかをイメージできると思います。標準の MVC Middleware コンポーネントの前にカスタム Middleware コンポーネントを作成して処理をすることになります。

Middleware の作成に Visual Studio を使う場合は、「ミドルウェアクラス」のテンプレートがあるのでそれを使うと便利です。それを少し変更して非同期にすると下のようなコードになります。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Http;
namespace MyApp
{
    // You may need to install the Microsoft.AspNetCore.Http.Abstractions package into your project
    public class MyMiddleware
    {
        private readonly RequestDelegate _next;
        public MyMiddleware(RequestDelegate next)
        {
            _next = next;
        }
        public async Task Invoke(HttpContext httpContext)
        {
            await _next(httpContext);
        }
    }
    // Extension method used to add the middleware to the HTTP request pipeline.
    public static class MyMiddlewareExtensions
    {
        public static IApplicationBuilder UseMyMiddleware(this IApplicationBuilder builder)
        {
            return builder.UseMiddleware<MyMiddleware>();
        }
    }
}

このコードと middleware pipeline の図を眺めていると大まかな使い方は理解できました。Invoke メソッドの、await _next(httpContext) が次のパイプラインを呼び出す処理で、その前後にコードを書くことで独自の処理を行わせることができます。

以下は、上のコードを修正して、特定のIPアドレスからのアクセスを拒否するようにしたサンプルです。

    public class AntiBotMiddleware
    {
        private readonly RequestDelegate _next;
        //拒否するアドレスの指定
        private readonly List<string> _blackIpAddress = new List<string> {"192.168.0.1", "192.168.0.2"};
        public AntiBotMiddleware(RequestDelegate next)
        {
            _next = next;
        }
        public async Task Invoke(HttpContext httpContext)
        {
            //IPアドレスの取得
            string remoteIpAddress = httpContext.Connection.RemoteIpAddress.ToString();
            if (_blackIpAddress.Contains(remoteIpAddress))
            {
                //403 を返す                
                httpContext.Response.StatusCode = 403;
                return;
            }
            await _next(httpContext);
        }
    }

_next を呼ばなければ、次のパイプラインに行かずに返ります。それで、ブラウザーでは「サーバーエラー 403アクセスが拒否されました」と表示されるようになります。

この middleware を実行させるためには、Startup.cs の Configure メソッドに登録する必要があります。

        public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
        {
            loggerFactory.AddConsole(Configuration.GetSection("Logging"));
            loggerFactory.AddDebug();
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
                app.UseBrowserLink();
            }
            else
            {
                app.UseExceptionHandler("/Home/Error");
            }
            app.UseStaticFiles();
            app.UseAntiBotMiddleware();
            app.UseMvc(routes =>
            {
                routes.MapRoute(
                    name: "default",
                    template: "{controller=Home}/{action=Index}/{id?}");
            });
        }

ここで、注意すべきことは、登録の順番が重要になってくるということです。今回の middleware は、その性格からいって UseMVC より前に置く必要があります。そして、UseStaticFiles の前におけば、静的ファイルもアクセス拒否の対象になり、後ろに置けば静的ファイルを除いたものがアクセス拒否の対象になります。

このサンプルは、プロキシーサーバーを使っている場合はうまく動作しません。httpContext.Connection.RemoteIpAddress が、プロキシーサーバーのアドレスになるためです。以下は、Nginx をプロキシーサーバーに使っている場合のサンプルです。

        public async Task Invoke(HttpContext httpContext)
        {
            //IPアドレスの取得
            string remoteIpAddress = GetRequestIP(httpContext);
            if (_blackIpAddress.Contains(remoteIpAddress))
            {
                //403 を返す                
                httpContext.Response.StatusCode = 403;
                return;
            }
            await _next(httpContext);
        }
        private static string GetRequestIP(HttpContext httpContext)
        {
            string ip = GetHeaderValueAs("X-Forwarded-For", httpContext);
            if (string.IsNullOrWhiteSpace(ip))
                return  httpContext.Connection.RemoteIpAddress.ToString();
            return ip;
        }
        private static string GetHeaderValueAs(string headerName, HttpContext httpContext)
        {
            StringValues values;
            if (httpContext?.Request?.Headers?.TryGetValue(headerName, out values) ?? false)
            {
                return values[0];
            }
            return null;
        }

なお、このサンプルが動作するためには、Nginx側で、X-Forwarded-For の設定をしておく必要があります。

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Dependency Injection を使う

上のサンプルで不便なのは、拒否するアドレスの指定を初期化で行っているところです。拒否するアドレスは画面で検索できたり変更できた方がいいですね。その場合には、Dependency Injection（DI）を使うのが自然です。DI という名前を聞くと難しそうに思うのし、解説を読んでも難しいのですが、以下のように簡単に作って試してみたら動作しました。

まず、普通に Class を作ります。（正式には、最初に Interface を作るようです）

public class AntiBotServise
{
    public List<string> BlackIpAddress { get; set; }
    public AntiBotServise()
    {
        BlackIpAddress = new List<string> {"192.168.0.1", "192.168.0.2"};
    }
}

すべてのリクエストで共通に使用するので、Startup.cs の ConfigureServices で AddSingleton を使って DIサービスコンテナに登録します。

public void ConfigureServices(IServiceCollection services)
{
   services.AddSingleton<AntiBotServise>();
   // Add framework services.
   services.AddMvc();
}

Middleware の方で、次のように Injection します。

public class AntiBotMiddleware
{
    private readonly RequestDelegate _next;
    private readonly AntiBotServise _antiBotServise;
    public AntiBotMiddleware(RequestDelegate next, AntiBotServise antiBotServise)
    {
        _next = next;
        _antiBotServise = antiBotServise;
    }
    public async Task Invoke(HttpContext httpContext)
    {
        //IPアドレスの取得
        string remoteIpAddress = GetRequestIP(httpContext);
        if (_antiBotServise.BlackIpAddress.Contains(remoteIpAddress))
        {
            //403 を返す
            httpContext.Response.StatusCode = 403;
            return;
        }
        await _next(httpContext);
    }
}

Controller や View でも、同様に Injection できるので、画面で検索できたり変更したりできるようになります。

補足

長くなってきたので、middleware で eCAPTCHA を使う話は次回にします。

ASP.NET Advent Calendar では、Azure の話が多いようです。確かにエンタープライズ向けのクラウドでは Azure がベストだと思います。

しかし、DDoS の件を調べていると Google の名前がたびたび出てきます。Google は、公開用 Web サーバーが有力な収益源の一つなので、その関係のサービスは、Google の方がはるかに充実しています。また、.NET Foundation に加盟したことでもわかるように、Google Cloud Platform での .NET サポートはかなり進んできているという印象です。

サイトを ASP.NET Core + .NET Core で作り直しました

2016-02-23T15:42:00+09:00

この Webサイトは、Umbracoで作っていましたが、ASP.NET Core（ASP.NET 5）+ .NET Core で作成し直してみました。Umbracoも拡張性が高くて悪くはないのですが、自分でプログラムを書きたい場合には自由度が小さくなるのとデバックの時には重くなるのが欠点でした。それで思い切って、作り直すことにしました。選択肢としては、ASP.NET MVC 5、ASP.NET Core + .NET Framework 4.6、ASP.NET Core + .NET Core の三つでしたが、思い切って NET Core + .NET Core にしてみました。

ASP.NET 5 については、スケジュールが変更され、名称も ASP.NET Core に変更になるということで、RC2 が出る直前になってドタバタしているようですが、実際使っていると問題点があることはわかります。でも、基本的なところはそれほど変わっていないし安定しているので使えないことはないです。

運用を始めたばかりで、切り替えの時に少し失敗してサーバーを止めてしまったこともありましたが、取りあえずは普通に動いています。Ubuntuサーバーの方でもテストしていますが、そちらも大きな問題はなく動作しています。

ASP.NET Core、.NET Core については、最近マイクロソフトから以下のブログが出て、方向性がよくわかるようになったと思います。

ASP.NET 5 is dead - Introducing ASP.NET Core 1.0 and .NET Core 1.0

An Update on ASP.NET Core and .NET Core

Porting to .NET Core

ASP.NET Community Standup – February 16, 2016

Porting MSBuild to .NET Core

コンパイラーが DNX から CLI に変更になるというのは賛成です。このサイトの発行時のファイルサイズは、約300MBぐらいで、その内runtimesが106MB、packagesが190MBです。runtimesの分は、ホストのOSにインストールされたランタイムを使う必要がなくなった代わりに必要になるもので、どんな小さなアプリにでも必要になります。packagesの分が大きくなっているのは、.NET Core だけでなく下の図のように Windows Phone 8 や Xamarin のものまで含まれているためです。Webサーバに関していえば、これぐらいのファイルサイズでも我慢できなくはないのですが、コンソールアプリケーションで 100MBというのはちょっと大きすぎだと思います。AOT（事前コンパイラ）をしてファイルサイズも減らして欲しいし、最初の起動時間も短縮して欲しいと思うし、コンソールアプリケーションだと、ネイティブコードにコンパイルして欲しいところです。

.NET Core を使う上での支障は、ライブラリーの対応があまり進んでいないことです。「Porting to .NET Core」に書いてあるように、.NET Core でも System.Data、System.DirectoryServices、System.Drawing、System.Transactions、System.Xml.Xsl、System.Xml.Schema、System.Net.Mail、System.IO.Ports、System.Workflow、System.Xaml で、時間がなくて移行があまりできていないそうです。そういう状況なので、サードパーティ製のライブラリーの対応状況は悪いです。

現状では、ASP.NET だと、ASP.NET Core + .NET Framework 4.6 という選択肢が現実的だし、UWP の方も windows 10 mobile が殆ど普及していないことや、デスクトップPCでも依然として主力は Windows 7 であることを考えれば、.NET Core を急ぐ必要はないと思います。

しかし、5年後を考えると .NET Core が必要というのは間違いないと思います。また、下の図は、Azure の VM の Linux と Windows の価格です。個人だとこれだけ価格に差が出てくると Linux の方を使いたいと思ってしまいます。それで、これからは、 Linux のことも書いていきたいと思っています。

Web をするなら PHP だけでなく JavaScript を使ってみよう

2016-02-05T15:54:23+09:00

JavaScript は、Webデザイナーのための簡易言語だと言われたり、まつもとゆきひろ氏には「人類のためにJavaScriptは何とかしたほうがいい（出典：エンジニアライフ）」と言われたりしたプログラム言語ですが、ECMAScript 2015 が承認されたことでモダンな言語に変身しつつあります。

2ヶ月ほど前の話ですが、PHP Advent Calendar 2015 の「PHPを使いもせずDISってる君達へ」という記事をみて、JavaScript は、PHP より遙かにモダンな言語になると思ったのでメモしておきます。

その記事では例を、Ruby で書いてありますが、JavaScript の場合はどうなるかというと、ECMAScript 5.1（ES5）では以下のように記述できます。IE8 は対応していませんが、それ以外の普通に使っているブラウザーは対応しています。

var a = [2,4,6,8,10]
    .filter(function(num){return num <= 8})
    .map(function(num){return num * num})
    .filter(function(num){return num >= 20})  
    .reduce(function(previous, current, index, array){return previous * current});

また、ECMAScript 2015（ES6）では、アロー関数式が使えるので、Ruby と同様に以下のように簡潔に記述できます。

var a = [2,4,6,8,10]
    .filter((num) => num <= 8)    
    .map((num) => num * num)    
    .filter((num) => num >= 20)    
    .reduce((previous, current) => previous * current);

やはり、PHP の配列処理はやはり不便です。PHP も配列などのコレクションの処理をするときには、高階関数を使って処理できるようになってほしいと思います。

JavaScript の ECMAScript 2015 への対応状況ですが、ECMAScript Compatibility Tableというサイトで調べると、Edge13 83%、Firefox45 85%、Chrome49 91%、Safari9 54% という状況で対応が進んできていますす。

ブラウザーではIE11が全く対応していないので、直接使うことは厳しい状況ですが、TypeScript を使えば、ソースコードとして使えるし、Node.jsだと、近いうちに直接書くことができるようになると思います。

JavaScript は Node.js を使えばサーバー側でも動くし、PHP では動かないブラウザー上でも動作します。これからは、Webをしたいのであれば、PHP だけでなく JavaScript を使った方がいいと思っています。

参考までに、C#の場合は、LINQを使って以下のように書けます。C#は、以前は Ruby の方が効率的にプログラムが書けると思っていましたが、C# 3.0 で LINQが使えるようになり、C# 5.0では async/await で非同期処理ができるようになって Ruby に追いついたと思います。配列処理のことについては、C# やるなら LINQ を使おうに詳しい解説があるので、ここでは説明を省略します。

var a = new int[] { 2, 4, 6, 8, 10 }
    .Where((num) => num <= 8)    
    .Select((num) => num * num)    
    .Where((num) => num >= 20)    
    .Aggregate((previous, current) => previous * current);

ASP.NET 5 Preview を使ってみた

2015-03-02T12:46:00+09:00

Visual Studio 2015 CTP 6 が公開されるとともに、スコット・ガスリー氏が「Introducing ASP.NET 5」とういうブログを公開しました。その記事を読んで、今回の ASP.NET 5 は、なかなか面白そうだと思って、Visual Studio 2015 CTP 6 をインストールして、ASP.NET 5 を使ってみました。ASP.NET 関係で使ってみたいなと思ったのは本当に久しぶりのことです。余談ですが、Visual Studio 2015 CTP 6 は、容量が多くてインストールが大変でした。コントロールパネルをみると容量が実に11.5GBになっていてマンモスです。

まず、既存のWEbアプリの移行にどれぐらい手間がかかるかを、ASP.NET MVC 4 で作成した weather.ecitizen.jp を使って試して見ました。Visual Studio 2015 CTP で ASP.NET 5 の」プロジェクトを作ると左の図のように、ファイルが wwwroot の静的部分とASP.NET部分に別れるのが大きな特徴です。現時点では移行ツールはないのですが、Models、Views、Controllers といったメインの部分は、コピーして少し修正してやれば動作するので、移行に少し手間はかかるけどそれほど難しくはないと感じました。

クライアント関係のライブラリーの管理については大きく変更されています。ASP.NET のサイトに「Manage Client-Side Web Development in Visual Studio 2015, Using Grunt and Bower」という解説がでているので、それを見て設定してみました。ライブラリーの管理は、NuGetではなく Bower で行い、その後の設定を Grunt でするようになっています。Bower、Grunt も実際に使ってみるとかなり使いやすいツールです。Visual Studio 2013 では、そういう作業には NuGet と Web Essentials 2013 を使っていましたが、Web Essentials にはまだバグらしきものがあるので、何でも独自に作成するよりは実績のあるツールを使った方が確かにベターだと思います。Web Essentials 2015 CTP 6 も公開されていますが、以前よりもずっとシンプルになっています。また、LESS、Sass、CoffeeScript 等のコンパイル機能は、Grunt 等のツールを使えということで、対応しないそうです。

Visual Studio 2015 では、従来の ASP.NET MVC 5 と互換のある ASP.NET MVC 5.2 の Webアプリケーションも開発できますが、HTML 5 を使うような Webアプリの開発だと Bower、Grunt を使わないと不便になるという気がします。自分のような場合だと、Visual Studio 2015 に移行するときには、できるだけ早く ASP.NET 5 に移行した方がベターなように感じました。

最後に、現在の weather.ecitizen.jp と ASP.NET 5 に移行したもののスピードを「WebPagetest」を使って比較してみました。ASP.NET 5 アプリは、.NET Core CLR か従来からの .NET CLR でも発行できます。.NET CLR で発行すると容量は約100MB、.NET Core CLR だと約70MBあります。それを Windows 2012 R2 サーバーにインストールしました。結果は以下のとおりで、上が ASP.NET 5 アプリで、下が従来のものです。DNS Lookup は、ASP.NET 5 アプリの方が時間が掛かっていますが、それ以外ではレスポンスの時間には特に差はありませんでした。DNS Lookup については、サブドメインを新たに作成したばかりなので伝播があまりできていなかった影響がでているかもわかりません。ASP.NET 5 はまだ CTP の段階なので、リリース版までにはチューンナップがされると思うので処理速度の面でも期待したいと思いす。

Xamarin.Forms をテストしたら Label より WebView の方が早かった

2015-01-30T17:29:00+09:00

Xamarin.Forms は、iPhone と Android の両方のアプリが一つのソースで作れるという魅力的な開発ツールです。それで、アプリを作ろうと思って試してみました。

自分にとっての一番の問題点は、Xamarin.Forms の画面表示が意外と遅いことです。Grid と Label を使って、カレンダー1年分の表示をする下の図のようなプログラムを作って、Nexus 5 で表示させてみたら、ボタンを押してから表示されるまでに3秒以上かかりました。iPhone 5s だとそれよりはかなり早くなりますが、それでも1秒以上かかっている感じです。

今回のカレンダーだと日付だけですが、実際のアプリにするためには、さらに色を変えたりアイコンを追加したりする処理が必要なので、日付だけでこれだけ時間が掛かってしまうと厳しいと思います。

ところが、WebView を使って HTML の Table でカレンダーを作ってみると、今度はほとんど遅延せずに動作します。Grid+Label より WebView の方が遙かに早いようで、Android では特にその傾向が強いように見えます。

なお、プログラムは、GitHub の方に SpeedTest として公開していますので、興味のある方は実際に試して見てください。

Xamarin.Forms の Grid+Label を使った画面表示が遅い原因を調べてみると、stackoverflowに Why is Xamarin.Forms so slow when displaying a few labels (especially on Android)? という質問があって、どうも Label の表示が遅いようです。

stackoverflow 方では、40個のLabelで、表示に 100ms 以上かかり、Android の場合は約300ms かかるとなっています。今回のカレンダーの場合は、約460個のLabelをつかっていて stackoverflow の約10倍なので話としては一致しています。

stackoverflow には、改善策も書いてあます。Xamarin.Forms で処理を速くする方法としては、UI にはできるだけネイティブを使えばいいようです。

自分の場合は、Web の方を主力にしたいので、UI にネイティブを使うのは時間的にはかなり厳しいです。それで、当面は WebView を使ったハイブリッドアプリを検討していこうと思っています。そして、Xamarin.Forms の処理が早くなることに期待したいと思います。

Cordova vs Xamarin vs Swift

2015-01-07T17:22:00+09:00

今年初めてのブログなので、今年の抱負とかを書こうと思ったのですが、昨年の後半はスマートフォン・アプリを作ろうと思っていろいろ検討してきたので、そのメモをしておきます。

Cordova

PhoneGap といった方が有名ですが、HTML+Javascriptの技術を使って、iPhone/Androidのネイティブアプリケーションの開発が可能になります。以前に使ってみたときには、デバッグがしづらいと思っていたのですが、Microsoft から Visual Studio Tools for Apache Cordova が公開されて、開発がすごく楽になっています。Webアプリにプッシュ通知だけをつけたい場合のように、少しだけネイティブの機能を追加したい場合には適していると思います。

Visual Studio Tools for Apache Cordova は、VS の　Express ではインストールできません。しかし、昨年の11月に個人や5人以下の企業向けに Visual Studio Community 2013 が公開され無料で利用できるので一度試して見るといいと思います。

Xamarin

Xamarin は、C#やF#といった.NET系の技術を用いてiPhone/Android のアプリ開発を可能にするクロスプラットフォームツールです。Xamarin 自体は、各プラットフォームの API の薄いラッパーで、アプリのUIを作る場合には各プラットフォームのことを知っていないと作れないのでかなり苦労しています。Model の部分は共通で使えるので、アプリ側で多くのロジックが必要な場合には適していると思います。

昨年の5月に公開された Xamarin.Forms は、UI 部分も共通化しようというもので魅力のある製品ですが、実際に使ってみるとまだまだベータ状況という感じがしています。製品として早く成熟して欲しいと思っています。

Swift

iOS のソフトらしいヌルヌル動作するアプリを作りたければ、Apple 純正の Swift を使うのがいいようです。C# を知っていれば Objective-C よりはモダンになっているのでかなり取っつきやすいと思います。Apple が Swift を公開したことに対して、また独自の言語を開発してという非難をする人がいますが、iOS の特徴を生かすための言語が必要というのはやむを得ないことだと思います。

ベストな開発環境を確認するのはその環境を熟知していないと無理なので、結局は自分の能力や作りたいアプリの特徴に応じてだいたいのところで選択するしかないというのが実態のようです。今年は、Webアプリのスマートフォンアプリ版を作りたいと思っていますが、最初は、Xamarin から始めようと思っています。最終的にはどうなるかはわかりませんが、ぜひ公開できるようにしたいと思っています。

Xamarin から始めようと思っているのは、現在は ASP.NET MVC で Web サイトを作っているためです。Cordova を使うためには、Razor が使えなくなって、HTML + CSS + JavaScript だけで画面を作る必要があります。そういう制作方法に変更してもいいとは思うのですが、Xamarin であれば、WebView で Razor も使えるので Web アプリと iOS/Android アプリの共通部分を増やせるのではないかと思っています。

C#で経済指標巡回プログラムを作成しました

2014-12-30T19:35:00+09:00

「Rubyで経済指標自動巡回プログラム作成しました。 - 人生、徒然なるままに。」というブログをみて、このブログの筆者は、.Net や Java を使えるのに、なぜ、新たに勉強してまで Ruby を使ったのかということに興味があったので、同じようなものを C# で作り、GitHubで公開(https://github.com/awoni/GetMarketCalendar)してみました。

今回のプログラムでは、データの取得には HTTPClient を使って直接 Url をたたいて該当ページのHTMLを取得しています。一方で、Ruby の方では、「フレームワークとしてCapybara、レンダリングドライバー・javascriptドライバーとして poltergeist, PhantomJS」を選択しているそうで、プログラムでボタンをクリックして取得したデータをもとに解析しています。今回のデータの場合は、HTML のみで必要なデータが取得できましたが、JavaScriptを使ったインターラクティブな Webページが増加しているので、Javascriptが動作する環境でブラウジングしてデータを取得する必要がある場合も多くなってくると思います。

Html のパースには、Html Agility Pack を使っています。LINQ を使って記述していますが、意外と簡単にパースすることができます。

データの保存については、データベースではなくて、そのままで API として使いやすい Json で保存するようにしてみました。 Newtonsoft の Json.NET でシリアライズしています。設定ファイルについても、Json にしてみました。

その他に NuGetのパッケージとしては、NLog を使っています。Html のパースルーティンでは、どの程度までエラー処理をすべきかが問題になりますが、画面の変更に対応しようと思うとプログラムがどんどん複雑になってくるので、自分としては、プログラムは余り複雑にせずに、画面の変更によるエラーに早く気づくようにした方がいいのではないかと思っています。NLog をログのメール送信にも対応しているので、こういう点に関しては便利だと思います。ただ、今回公開しているプログラムでは、時間の関係でとりあえずの状況なのですが、実際にアプリケーションを作る場合は、ログをどうとるかは結構重要だと思っています。

C#で実際に同じようなプログラムを書いてみて、実務的にいえば C# は十分優秀だと思います。LINQ や今回は使っていませんが await async による非同期処理は便利です。ではどこが Ruby より劣るのかということを考えてみると、ブログの筆者のいう「rubyは面白いらしい」ということに尽きるのではないかと思います。それに、日本では情報量の差も大きいと思っています。

C#がどうすれば面白くなるかはよくわかりませんが、ブログの作者が巡回プログラムを作る動機になった「Rubyによるクローラー開発技法巡回・解析機能の実装と21の運用例」という本は、amazon.co.jp の「ソフトウェア・開発言語」で7位にランクされています。クローラーは意外と興味がある人が多いようなので、自分もクローラーであれば結構ネタはあるので、時々ブログに書いてみようと思っています。

モバイル開発ツールを Google トレンドでみてみた

2014-11-22T12:39:00+09:00

モバイル開発ツールの動向を Google トレンドで少し調べてみました。まず、主要な開発ツールの Xcode、Android SDK、Adobe AIR、PhoneGap、Xamarin を比較してみました。やはり純正の Xcode、Android SDK は強いです。そして、Adobe のツールの人気度が低下し、Xamarinの人気度が上昇中です。

日本で見てみると、iPhone 人気のためか Android SDK の人気度が低くなっています。

次にマルチプラットフォーム開発ツールだけにしてみると、Xamarin の人気度が急上昇しているのがよくわかります。

日本では、Xamarin の人気度はまだまだのようです。

開発ツールに関しては、基本としては自分の好きなものを選択すればいいのだけど、開発中止になると痛いので動向を簡単には抑えておいたほうがいいと思います。

JavaScript は PHP より10倍速い!

2014-06-25T00:09:00+09:00

JavaScript の処理速度が予想以上に速くなってきている。最近、スマートフォン用のアプリケーションをどうするか試行錯誤していたがその際の正直な実感だ。熾烈なブラウザー競争の結果 JavaScript の JIT コンパイラーが優秀になってきているのが原因だろう。

「俺の言語がこんなに遅いわけがない！？〜C, Java, PHP, Python, Rubyによるプログラミング言語速度比較〜」というブログの記事の結果に、C# と JavaScript の処理時間を追加すると以下のようなグラフになる。プログラム言語の処理速度は、C < C# ≒ Java < JavaScript << PHP のようだ。

JavaScript に数値を入れていないのは、同じ計測方法がとれなかったためで、概略で図を描いたもので詳しくは下で説明している。この結果は、プログラミング言語についての計算速度を測定するサイトである Computer Language Benchmarks Game の JavaScript と PHP を比較したデータを一番下に示しているが、処理速度に大きな差があるので概略値としては間違っていないと思っている。

普通の Web サイトでは、数値計算を大量にすることは殆どなくて、データベースとのやり取りや文字列処理が中心なので、PHP 等のスクリプト言語でも十分に実用的である。しかし、ユーザーインターフェースを本当によくしようと思えば、計算量が飛躍的に増大するので、プログラム言語の選択は重要になってきている。

巷では PHP が人気のようだが、これから新しくプログラム言語を覚えるのであれば JavaScript の方がお勧めだと思うのだがどうだろうか。JavaScript の方が速度的にも遙かに優位だし、PHPだけではリッチなクライアントのプログラムをすることは不可能で、結局は JavaScript を使わないといけなくなる。一方、JavaScript だとクライアントでの親和性は抜群だし、サーバー側でも node.js を使えるので、JavaScript だけを覚えればサーバー側もクライアント側もそれだけで処理ができてしまう。

そういえば、PHP も JIT を実装する方向で動いているようだ。やはり処理速度は重要だということだろう。

マイナビニュース: PHP、"次世代PHP"の開発を開始 - JIT実装に向けコアAPIも変更
PHP.net: PHP Next Generation

最後に処理時間の計測方法についてメモしておく。C#については、「俺の言語がこんなに遅いわけがない！？〜C, Java, PHP, Python, Rubyによるプログラミング言語速度比較〜」の例にならって、以下のコンソールアプリケーションのプログラムを書いた。

class Program
{
    private const int N = 10000;
    static void Main(string[] args)
    {
        Console.WriteLine("C# start.");
        var sw = new Stopwatch();
        sw.Start();
        var result = new int[N];
        for (int count = 1; count <= N; count++)
            result[count - 1] = SumUp(count);
        sw.Stop();
        Console.WriteLine(sw.ElapsedMilliseconds + "ミリ秒");
        Console.WriteLine("C# end.");
    }

    static int SumUp(int n)
    {
        int sum = 0;
        for (int i = 1; i <= n; i++)
            sum += i;
        return sum;
    }
}

C#は、マイクロソフトが開発したプログラム言語で、Java や Delphi の影響を受けているといわれており 2000年に登場した比較的新しい言語である。マイクロソフトの言語と思われているが、ISO で標準化されており、最近では、Mono や Xamarin によって、Linux、Mac、iPhone、Android 等でも動作する。

テスト環境は、例と同じくアマゾン・ウェブサービス(AWS)の t1.micro インスタンスを使ったが、Linux ではなくて、Windows Sever 2008 の 32ビット版を使用した。Linux のように単純に time コマンドで時間を計測はできないので、PowerShell のスクリプトを次のように作成して起動させて時間を計測した。

$wmi = Get-WmiObject -Class Win32_OperatingSystem
echo $wmi.LocalDateTime
.\ProgramTest.exe
$wmi = Get-WmiObject -Class Win32_OperatingSystem
echo $wmi.LocalDateTime

測定結果は、実行時間が161ミリ秒で、計算部分だけだと53ミリ秒だった。例のJavaの場合、集計に long を使っているので、C# でも sum を int から long に変更すると、実行時間が187ミリ秒になり、Java より少し遅いという結果になった。C# と Java は処理方法が似ているので実行時間もほぼ同じということになると思われる。

次に、JavaScript の実行時間の計測だが、例の方法に準じてテストをするには node.js をインストールしてテストするのがいいと思ったが、今興味があるのはブラウザーでの処理なので、計算部分の処理時間だけで C# と比較することにした。

JavaScript に関しては、以下のページに公開しているので、ソースはそちらを見てください。また、実際にテストもできます。

http://www.awoni.net/utils/Home/JavaScriptTest

自分のPCだと計算時間は、C#の場合で13ミリ秒、Chrome、IE11はともに 42ミリ秒～100ミリ秒で計算時間は安定していない。iPhone の場合は、C#73ミリ秒、Safari は約282ミリ秒だった。計算部分の処理時間については、概ねC#の4倍といったところだと思う。JavaScriptの場合は、計算部分の前後の処理については、下にPCの場合のタイムラインを表示しておくけどそれほど時間は要さないと考えられる。

なお、例の方のグラフでは、C の実行時間は255ミリ秒となっているが、Cで最適化オプションをつけてコンパイルすると58ミリ秒になったという記載があるのでそちらを採用している。

Computer Language Benchmarks Game での JavaScript と PHP の処理時間の比較

Apple Swift の人気が凄い

2014-06-09T16:28:00+09:00

6月1日に「Google トレンドでみるモバイルアプリ開発ツールの動向」という記事を書いたのですが、翌日のWWDC2014で新言語 Swift が発表されて話題になっています。Google トレンドでみても下の図のように凄い人気度です。

Swift の公開で iPhone アプリの作成もかなりやりやすくなるようなので、今後 Web アプリとネイティブアプリとの競争が一段と激しくなるように思っています。

Googleトレンドでみるモバイルアプリ開発ツールの動向

2014-06-01T12:40:00+09:00

最近、モバイルアプリを作ろうと思って Xamarin を使い始めている。それで、Google トレンドで、モバイル開発ツールの動向をみてみた。

モバイル開発ツールで最も人気度の高いと思われるのは、世界的にみても日本でも、アップルの iOS 開発ツールである Xcodeである。

Android開発ツールの動向は、世界と日本ではかなり異なっている。世界的に見ると Android SDK は、2011年以降安定した人気度を持っているし、2013年5月に発表された Google の統合開発環境である Andoroid Studio もかなりの人気度を持っている。両者を併せると Xcode を上回る人気度になっており、Xcode がモバイルではない Mac の開発ツールでもあるということを考慮するとモバイル開発環境の人気度ナンバーワンといえるだろう。世界的に見ると Android 端末のシェアが拡大しているということも関係していると思われる。

一方で、日本の人気動向をみると、2010年から2011年にかけて、Android SDK の人気度が急上昇している。世の中がスマートフォンブームということで Android 端末が普及してきた時期であり、そのブームに乗ろうと思って Android 開発者が急増した時期である。その後、結局日本では iPhone の方が売れて Android の人気は上がらなかったので、Android SDK の人気度は急降下している。このあたりも、横並び志向の強い日本の特徴がでている。製造業では、横並びでするというのは案外効率のいいことだと思うが、IT関係は二番が存在しづらい一人勝ちの世界なので、横並びをしていたのでは収益あがらないと思うのだがどうだろうか。

Xamarin は、世界的にはかなり人気度は上がっている。しかし、日本では、日本語のサポートが弱いということと、開発が受託中心でそれをチームで開発しているので、相当な力がかからない限り Xcode での開発を変更しようということにならないので、Xamarin の人気度があがる可能性はあまりないと思っている。

都道府県ランキングに D3.js でチャートを入れました

2013-10-09T21:49:00+09:00

6月から作成していた統計データ API エクスプローラにやっとチャートを入れることができました。まだ、都道府県ランキングの指標の分だけだし、それも改善しようと思っている点が数多くあって、最初の一歩というところです。

D3.js を使ったことで、最初の一歩には時間がかかりましたが、今後インターラクティブな画面を作っていくということでは大きな進歩だと思っています。チャートを描くだけであれば、Google Visualization API を利用した方が簡単です。でも、内部がブラックボックスだけにそのチャートを自分で思ったように動かすことは相当難しくなります。D3.js の場合は、最初は難しいけどプログラムで完全にコントロールができることがメリットです。そうはいっても、まだチャートが一つできただけで、コントロールをするためには学ぶことが多く残っています。

ユーザーにデータをインターラクティブに可視化して提供できるということは、ユーザーエクスペリエンス（UX）を向上させる有力な手段の一つです。これから自分の思い通りに図を動作させることができるように頑張ろうと思っています。

ロギングライブラリ NLog を使ってみる

2013-06-08T21:23:00+09:00

プログラムの実行状態をログで記録したいという場合には、ログの数が少ないうちは StreamWriter を使って自作してもそれほど手間はかからないのですが、Web サイトでアクセス数が多くなってくると、少なくとも次の２点を考慮する必要がでてきます。

ファイルが大きくなり過ぎないように、ログファイルのローテートをする。
同時アクセスがあった場合の対応が必要である。

それではということで、ロギングライブラリーを探してみたら、C#用には、NLog と Log4Net というライブラリーがありました。比較すると NLog の方が活動が活発で使い方も簡単そうだったので、NLog を使うことにしました。

ソースコードとマニュアルは、GitHub にホストされています。マニュアルによると、ログの出力先にはファイルだけでなく、データベースやメールやWebサービスが選択できます。重大な障害が発生したときには、メールで通知できるのは便利ですね。

Visual Studio へのインストールには NuGet が利用できます。NuGet パッケージの管理で NLog で検索すると以下のようなパッケージが表示されます。NLog には多くの拡張パッケージがあって多くのところで利用されているのがわかります。NuGet では NLog だけでなく、NLog Configuration もインストールします。

インストールが完了すると、NLog.config という設定ファイルのひな形が以下のように作成されています。ひな形をみれば、NLog.config では、ターゲット（targets）とルール（rules）を設定をしたらいいということのようです。

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<!–
See http://nlog-project.org/wiki/Configuration_file
for information on customizing logging rules and outputs.
   –>
<targets>
    <!– add your targets here –>

    <!–
    <target xsi:type="File" name="f" fileName="${basedir}/logs/${shortdate}.log"
            layout="${longdate} ${uppercase:${level}} ${message}" />
    –>
</targets>

通常のログファイルだったらひな形がそのまま使えます。ターゲットが複数利用できるので、メール用のターゲットとルールを以下のように追加すると致命的エラーの時にメールを送るようにすることができます。

ターゲットの追加

ルールの追加

ログを出力するコードを書くのは比較的簡単で、ASP.NET MVC の場合であれば、モデルに次のようなルーチンを作っておけば、他のモデルやコントローラーから呼び出して使えます。

using NLog;

public class LoggerClass
{
private static Logger Logger = LogManager.GetCurrentClassLogger();

    public static void NLogInfo(string message)
    {
        Logger.Info(message);
    }

    public static void NLogFatal(string message)
    {
        Logger.Fatal(message);
    }
}

NLogを使うことで簡単にログを出力できるようになるので、現状のログに不満がある人は試してみてください。

Google Page Speed を使ってみた

2011-07-16T17:30:00+09:00

以前から、この Web サイトのレスポンスはあまり良くないと思っていましたが、Google ウェブマスターツールの「サイトのパフォーマンス」で読み込み時間が4秒を超えるようになったので、これではいけないと思って Google Page Speed を使ってみました。Google Page Speed は、Web ページのパフォーマンスを評価して、ウェブページの読み込み時間を短縮するためのヒントを与えてくれるツールです。Page Speed には、FireFox 版と Chrome 版があります。今回は、FireFox 版を使いました。FireFox 版は、FireFox のアドインなので、インストールは簡単にできます。まず、Firebug 上で動作するので、Firebug アドインをインストールしていなければインストールしておきます。また、オンライン版の Page Speed である Page Speed Online もあるので、アドインをインストールしたくない場合は Page Speed Online を利用することもでき、Web ページの URL を入力するだけで、パフォーマンスの解析をしてくれます。

Page Speed をインストールして、Firebug を起動させると、下の図のように Firebug のツールバーに Page Speed のメニューが追加で表示されるようになります。

Page Speed を実行すると、下の図のように、改善の提案が表示され、「赤丸」が少ない努力で大きく改善できる可能性がある項目を、「黄色の三角」が作業量が多いか大きな効果が得られない項目を、「緑色のチェック」が大きな効果が得られない項目であることを表します。

この Web サイトを Page Speed でチェックしたら、多くのページで「赤丸」に該当した項目は、以下の2項目だったので、この項目を提案のように変更することにしました。

・ブラウザーのキャッシュを有効にする

キャッシュの有効期間を設定する必要がありますが、IIS 7.x では、IIS マネージャーで設定をすることができます。IIS の「HTTP 応答ヘッダー」で、「共通ヘッダーの設定」をクリックすると以下のような設定画面が表示されるので、失効までの期間を Google のアドバイスに合わせて 10 日以上にしてやります。この設定で注意しないといけないのは、このサイトでは Umbraco CMS を使っていますが、Web サイトに有効期限を設定することはできるのですが、画像を保存してあるフォルダーに有効期限を設定するとエラーが発生してしまいます。原因については、よくわからないので時間ができたら調べようと思っています。

・圧縮を有効にする

IIS 7.x では、「動的なコンテンツの圧縮モジュール」は、既定ではインストールされていません。IIS には、「動的圧縮を使用すると、プロセッサーの使用が増加しサーバーの全体的なパフォーマンスが低下する可能性があります。」という警告があるので、有効にするかどうか一瞬迷うのですが、タスクマネージャーや EC2 の Monitoring でみるとコンピュータの使用率はそれほど高くないので有効にすることにしました。負荷が高くなっている場合を除いて大抵の場合は有効にした方がいいように思います。EC2 の場合は、帯域幅に課金がされるので、利用料を削減する効果もあります。「動的なコンテンツの圧縮モジュール」をインストールするには、コントロールパネルの「Windows の機能の有効化または無効化」で、下の図のように「動的コンテンツの圧縮」の機能を有効にしてやります。モジュールがインストールには、かなり時間がかかりますが、インストールが完了すれば、IIS マネージャで、設定をしたい web サイトを選択して、センターパネルで IIS の「圧縮」を選択して、「動的なコンテンツの圧縮を有効にする」にチェックをいれれば設定が完了です。

この設定した効果は、以下の図のようになりました。ページの読み込み時間は 2.2 秒になり、以前より約 2 秒短縮することができました。実は、この設定と併せて、サーバーを Amazon EC2 の東京リージョンに移動させたので、それによる効果が半分ぐらい入っています。しかし、階段状になっている 3 段のうち最初の2つはこの設定の効果だと思われるので、設定の方もかなりの効果があったと思っています。

WebMatrix等のWeb開発関連ツールの一斉公開とUmbraco

2011-01-28T00:42:00+09:00

WebMatrix、ASP.NET MVC 3.0、Orchard 1.0、Web Platform Installer 3.0 と Microsoft の Web 開発関連ツールが一斉に公開されたのが、1月11日でした。GoogleでWebMatrixを検索してみるとWebMatrixは盛り上がっているようです。このサイトのアクセス数も、公開後は1割ぐらいは増加したように思います。ただ、アプリケーションでいうと盛り上がっているのはWordPressで、Umbraco、DotNetNuke 、Orchardo等のASP.NETのアプリケーションは寂しい状態です。

ASP.NETのアプリケーションがなぜ寂しいのかを考えると、ASP.NET を使っている技術者は、このサイトでも1日に数百人がアクセスしてくるので、日本中では相当な数いるはずですが、企業のソフトウェア技術者の多くは仕事に追われているのでそんなものを試してみようとする人はかなりの少数だと思います。一方、個人で、ASP.NETを使っている人は、ActiveWeb と ExpressWeb で、ネームサーバーへのドメインの登録数からみて最大で2000人ぐらいで、他のWindowsレンタルサーバーを使っている人はもっと少ないし、それにWindowsレンタルサーバーを借りていても実際はPHPしか使っていないというような人も多いので、個人のASP.NETユーザーというのは、日本ではかなりマイナーな存在だと思われます。このことがASP.NETのアプリケーションの盛り上がらない大きな理由だと思っています。

そもそも、日本でUmbracoを使っている人がどの程度いるのかをGoogle の検索で調べて見ると、Umbracoを使っているという記事があるページは、片手もない状況で、Orchard CMS に既に負けてしまっているようです。使ってみようかと思う人が少ない上に、実際に動作させるまでのハードルがかなり高いようで、日本でUmbracoを使ったことがある人はごく少数というのは間違いない状況です。

最近、wonderrabbitproject.netの兎氏がTwitterでUmbracoのことをツイートしていますが、プログラマビリティの良さについては認めていますが、UIに関しては低い評価をされています。この評価については、ある意味においては同感です。このことが、日本では全く使われていないし、世界的にも普及している地域が偏在している大きな理由だと思っています。また、UmbracoがUmbraco.tvでビデオによるチュートリアルを有料で公開しているというのもこのためだと思っています。

しかし、実際のところはUmbraoのUIはどのようにでもできるし、操作も難しいわけではありません。ただ、それを理解したり理解させたりするのが結構難しいのです。なぜかというと、普通のCMSの場合、管理画面には設定項目の一覧が並んでいて、デフォルトのままでも問題なく動くし、何かを変更したいときは項目の一覧をみてどの項目を設定したらいいのかがわかるので、システムに慣れた人であれば、すぐに理解できるようになっているし、初心者ならこういう場合にどうするのかを人に教えてもらうのも比較的簡単です。しかし、Umbracoは、プログラマビリティを優先しているので、管理画面に設定項目が並んでいない等他のCMSとは異なっている面が多くあります。それで、慣れた技術者であってもUmbacoの基本的なことを少し時間をかけて理解をする必要があります。でも、慣れれば生産性は高いと思います。世界的にはコミュニティの活動が活発なという理由もこのあたりにあるのでしょう。

静的なホームページを持っていて、それをCMS化したいというような場合には、HTMLの知識が少しあればできます。でも、それをマニュアルにするのには苦労しています。