クリエイティブWeb - Web アプリ

.NET Core で PostgreSQL を使ってみたら結構いけていたという話

2016-12-15T10:00:00+09:00

これは PostgreSQL Advent Calendar 2016の15日目の記事です。

この Web サイトは、今年の4月から ASP.NET を Core の方に更新して Ubuntu サーバーで運用しています。実際に運用してみて、IIS よりも Nginx を使う方が便利だと思うようになってきたので、サーバーはすべて Linux サーバーにする予定です。

その際の問題は、データベースをどうするかということです。ASP.NET とはなんといっても SQL Server を使うのが定番です。それで、自分も SQL Server Express を使ってアプリを作っていました。しかし、残念なことに SQL Server が Linux に対応するのは来年の半ばということです。

最近、PostGIS を使いたいという思惑もあって、PostgreSQL を使ってみたら、結構いけていると感じたので、この記事を書くことにしました。まだ、使い始めて1ヶ月なので、今後問題が見つかるかもしれないので最終的どうなるかはわかりませんが、PostgreSQL を使っていこうと思っています。

Entity Framework Core で使う

.NET Core や .NET Framework から、PostgreSQL を使う場合は、Npgsql というデータプロバイダーを使用します。Npgsql には、Entity Framework Core（EF Core）用のプロバイダーもあるので、EF Core で使っている範囲では、SQL Server を使うのと違いは殆どありません。

参考 Npgsql の EF Core 用のドキュメント

例として、Visual Studio の ASP.NET Core の Web アプリケーションのテンプレートで認証を「個別のユーザーアカウント」にした場合に、EF Core が使用されているので、それを PostgreSQL を使うように修正してみます。

Nuget パッケージの追加 Npgsql.EntityFrameworkCore.PostgreSQL を追加します。
Startup.cs の修正以下のように、options.UseSqlServer と SQL Server を使う設定になっているので、

public void ConfigureServices(IServiceCollection services)
{
    // Add framework services.
    services.AddDbContext<ApplicationDbContext>(options =>
                options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
    services.AddIdentity<ApplicationUser, IdentityRole>()
       .AddEntityFrameworkStores<ApplicationDbContext>()
       .AddDefaultTokenProviders();
    ------ 以下省略
}

options.UseNpgsql に変更して、Npgsql を使うようにします。

public void ConfigureServices(IServiceCollection services)
{
    // Add framework services.
    services.AddDbContext<ApplicationDbContext>(options =>
                options.UseNpgsql(Configuration.GetConnectionString("DefaultConnection")));
    services.AddIdentity<ApplicationUser, IdentityRole>()
       .AddEntityFrameworkStores<ApplicationDbContext>()
       .AddDefaultTokenProviders();
    ------ 以下省略
}

appsettings.json に記載してある接続文字列を修正します。

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=localhost;Database=test;Username=postgres;Password=password"
  },
------ 以下省略
}

SQL Server から PostgreSQL を使うように変更するのはそれだけです。

接続文字列に設定したユーザーが、データベースを作成できる権限を持っているユーザーであれば、これでデータベースも勝手に作ります。もし、そうでなければ事前にデータベースを作っておきます。

ただし、それで Run して、ユーザーの登録をしようとするとエラーになります。Data ディレクトリに Migration フォルダーが作成されていて、SQL Server 用のものが事前に作られているためです。それで、それらのファイルを削除してからするとちゃんとしたエラーメッセーが出ます。メーセージの通りにマイグレーションをしてやると正常に動くようになります。

A database operation failed while processing the request.
NpgsqlException: Exception while reading from stream 
IOException: Unable to read data from the transport connection: 既存の接続はリモート ホストに強制的に切断されました。. 
SocketException: 既存の接続はリモート ホストに強制的に切断されました。 
Use migrations to create the database for ApplicationDbContext
In Visual Studio, use the Package Manager Console to scaffold a new migration and apply it to the database:
PM> Add-Migration [migration name] 
PM> Update-Database
Alternatively, you can scaffold a new migration and apply it from a command prompt at your project directory:
> dotnet ef migrations add [migration name] 
> dotnet ef database update

コードファーストで開発する場合は、SQL Server なのか PostgreSQL なのかを気にしなくても開発できると思います。

細かい点でいうと作成されたテーブルをみると下の図のようにカラム名が Pascal ケースになっています。

SQL Server では、カラム名の大文字小文字を区別しないのでPascalケースは便利なのですが、PostgreSQL では、列名の大文字小文字を区別し、SQL文の中の列名は小文字に変換されます。それで、カラム名が「AspNetUsers」だと SQL 文の中では、常に二重引用符でくくって "AspNetUsers" としないといけなくなって結構手間になります。そのまま Pascal ケースで使うのか、それとも fluent API か attributes を使ってスネークケースに変換して使うのか悩ましいところです。自分は EF Core で使うのが主で、生の SQL をあまり使わないので、Pascal ケースのままでもいいのではないかと思っています。

データベースファーストの場合も、SQL Server を使うのと殆ど違いはなく、Microsoft.EntityFrameworkCore.SqlServer.Design の代わりに Npgsql.EntityFrameworkCore.PostgreSQL.Design を追加し、

dotnet cli の場合は、

dotnet ef dbcontext scaffold "Host=localhost;Database=mydatabase;Username=myuser;Password=mypassword" Npgsql.EntityFrameworkCore.PostgreSQL

Powershell の場合は、

Scaffold-DbContext "Host=localhost;Database=mydatabase;Username=myuser;Password=mypassword" Npgsql.EntityFrameworkCore.PostgreSQL

というように、Microsoft.EntityFrameworkCore.SqlServer を Npgsql.EntityFrameworkCore.PostgreSQL に置き換えてやれば、EF model を作成できます。

なお、DbContext のプロパティ名はカラム名を Pascal ケースに変換したものになります。

以上のように EF Core で使う限りにおいては、SQL Server を使うのと差はなく、実際に使っても今のところ大きな問題はでていません。

PostgreSQL を使うメリット、デメリット

SQL Server よりも便利な点としては、where 句で下のように正規表現を使うとサーバー側で処理をしてくれるという点です。( 参照ドキュメント)

var customersStartingWithA = context.Customers.Where(c => Regex.IsMatch(c.CompanyName, "^A"));

まだ使っていませんが、circle 等の幾何データ型、配列型、JSONB型のマッピングは可能なようなので、EF Core でも、これらのデータの取得と更新は可能なようです。

ただし、PostgreSQL の独自の機能を本格的に使うためには、EF Core ではなくて、Npgsql を直接使う必要があり少し手間がかかります。

でも、少し調べてみると、.NET で PostgreSQL を Document Db として使うためのソフトとして Marten というソフトが開発されています。まだ使い始めたばかりですが、結構使いやすい感じです。

PostgreSQL のデメリットといえば、慣れの問題かも分かりませんが pgAdmin よりは、Visual Studio Management Studio の方が使いやすいという点です。

PostgreSQL にするか MySQL にするか

Linux で動作するオープンソースの RDB といえば、PostgreSQL よりも MySQL の方が有名です。

まず、.NET Core 対応という点で比較すると、PostgreSQL の方は、Npgsql の .NET Core 対応はアルファ版が出てもう1年以上になります。その後も開発が進められてきており、かなり安定してきていると思います。一方、MySQL の方は .NET Core に Connector/Net 7 で対応予定で現在開発版が公開されています。

最近の状況では、ZDNet Japan の「PostgreSQL」がスタートアップ企業に選ばれる理由という記事が参考になると思います。以下に最近のデータを載せておきます。

Hacker News Hiring Trends 2016年11月

indeed Job Trends

ASP.NET Core を格安 VPS で使う

2016-10-01T14:41:00+09:00

この Web サイトを Ubuntu サーバーで運用を始めて6ヶ月になりました。その間に特に問題はありませんでした。むしろ、Linux サーバーに慣れてきて、テキストベースの設定が結構便利だと思うようになりました。

それで、格安 VPS を使って、ASP.NET Core アプリを動かしてみました。使ったのは、「さくらの VPS」1G 月額972円で、Webサイトは pp22.net です。サイトの中身は、まだ、このサイトのコピーです。

さくらの VPS の設定及び ASP.NET Core アプリを Linux で公開する手順については以下のページにメモをしています。

pp22.net の Web サイトが動作し始めたので、WebPagetest を使ってスピードテストをしてみました。結果は殆ど差がなく、格安 VPS でも、Web アプリの作り方次第では十分使えることが分かりました。

creativeweb.jp

pp22.net

なお、pp22.net の方がロード時間が短いのは、下部に Google アドセンスの「関連コンテンツユニット」が付いていないことが影響していると思います。

格安 VPS を実際に使ってみて、ASP.NET Core を使う上での課題は、データベースをどうするかということです。このサイトは、ファイルベースなので問題なくインストールできたのですが、通常の Web アプリではデータベースが必須になる場合が多いと思います。

ASP.NET Core と親和性が高いのは SQL Sever Express ですが、Linux 版が出るのは来年の中頃です。Linux サーバー以外に Windows サーバーを立てて、そこに SQL Sever Express をインストールすれば動作に問題はないのですが、格安 VPS を使うという趣旨ではどうかと思います。

Linux で一番使われている RDB である MySQL の場合は、公式ドライバー MySQL Connector/NET がまだ開発中で安定性に問題があります。

そういうことで、現時点で格安にしようとすれば PostgreSQL ということになると思って現在テスト中です。PostgreSQL は、.NET Core への対応を積極的に行ってきたこと、また、JSONサポートも積極的に進めているのでスタートアップ向けにはいいのではないかと思っています。

RDB でなくててもいいのであれば、次のようなドライバーが .NET Core に対応しています。ただし、ServiceStack.Redis の方は、.NET Core 対応についてはアルファ版です。

また、クラウドのストレージを利用する場合は、次のようなツールが .NET Core に対応しているので、主なものは使えるようになっています。

ドメイン名を変更して、「マンガでなれる？WEBデザイナー講座」を始めました

2015-06-22T21:16:00+09:00

ドメイン名を awoni.net から creativeweb.jp に変更しました。変更した大きな理由はなく、今後も web 関係のことを書いていくのだったら web が入っているドメイン名にした方がわかりやすいのではないかと思っただけです。最近は、このサイトの更新があまりできていないので、これを機会にもう少し更新の頻度をあげていきたいと思っています。

また、「マンガでなれる？WEBデザイナー講座」を始めました。最近、PCの他にスマートフォン、タブレット等色々なデバイスが増えて、Web デザインの方法が大きく変わってきたので、自分でも勉強しようと思っていたところ、フリーWEBデザイナーのミカ（栗本美香）さんが、マンガが得意なのを思い出して依頼したものです。

自分は、作りたいものがあるから Webアプリを作るというタイプで、基本的に一人で Web アプリを作っています。一人で全部していると、きれいなプログラムを書くことも優れたデザインのサイトを作ることも無理ですが、少しでもいいものは作りたいと思っています。

一人で作ることのメリットは効率がいいことで、今回のマンガも2週間ほどで公開できました。やり残してることも多いのですが、運用しながら修正していけるというのも Web のいいところだと思っています。

5374 徳島市版を作成してみました

2015-05-17T10:51:00+09:00

Windows 10 Insider Preview と Visual Studio 2015 RC のテストを兼ねて、Code for Kanazawa が作った「いつ、どのゴミが収集されているのか」をわかるWebアプリ 5374.jp の徳島市版を作ってみました。

Windows 10 も VS 2015 も自分の使った限りでは、エラーが発生することなく使えています。今年の夏に発売予定ですが、準備の方は順調に進んでいるようです。VS 2015 で、ASP.NET 5 については、あまり使っていませんが、ASP.NET 4.6 では製品版といってもいい状況で、実際の運用環境で使ってもいいという "Go-Live" ライセンスになっているというのもうなづけます。

5374.jp については、徳島市の場合は隔週及び4週毎のごみの収集があるのに、それに対応していないため、カスタマイズをしてみました。詳しくは、GitHub の方に記載しています。

徳島市版を作成した理由の一つには、JavaScript をどこまで使うのがいいのかということに対するテストという意味合いもあります。結局は、JavaScriptにどれぐらい慣れているのかということが一番大きな要素になると思いますが、自分の場合はロジックについてはC#で書いた方が楽です。JavaScript は一般的には手軽なのですが、Date を使うのは結構ややこしいです。自分の場合は、メンテナンスまで考えると今までどおり JavaScript は、UI 部分だけで使った方がいいと思いました。

5374.jp の場合、収集日を通知してくれる機能が欲しいと思うので、Cordova で作るのがいいのか、Xamarin で作るのがいいのか試してみたいと思っています。1月にアプリを作りかけたときは、表示の項目数が多かったので、Xamarin.Forms ではレイアウトの処理に時間が掛かりすぎました。5374.jp の場合は、それと比較するとかなり簡素なので Xamarin.Forms でも余り問題がないと思うので、比較するのには丁度いいと思っています。

Bootstrap を使ってレスポンシブ Web でモバイル対応しています

2015-02-14T18:07:00+09:00

最近は、「統計メモ帳」のサイトのモバイル対応をしています。当初は、ユーザーエージェントによる振り分けで対応しようと思っていたのですが、作業中にレスポンシブ Web でもできるのではないかと言うことに気づいて、テストしたら問題がないようなので、Bootstrap を使って、レスポンシブ Web でモバイル対応を進めています。

統計メモ帳だけで、テンプレートが60ページあるので、もし振り分けにしていたら、テンプレートが120ページになったということで、後の管理を考えると、できるだけレスポンシブ Web で対応した方がいいと思っています。

自分が管理で一番大変だと思っているのは、テンプレートの修正や CSS の管理です。今回もまだ50ページ以上のテンプレートの修正作業が残っていて、かなり大変な作業です。プログラムの部分は、Visual Studio が結構優秀なのと、ソースは Git に入れてあるので意外とスムーズにいっています。

CSS には、デザイン能力も必要ないし、変数も関数もないのでプログラムの能力も必要ないしで、3ヶ月も勉強すれば誰でもできると思われていて、webコーダーは最底辺の職種になっています。そのためかどうかは分かりませんが、CSS の管理はあまり考えられていなかったと思います。しかし、CSS には、名前空間がないので、そのクラスがどこで使われているかを調べるのに手間がかかります。だから本当は命名規則をきちんとしておくことが非常に重要です。

Bootstrap を実際に使ってみて感じたことは、普段に使うコンポーネントを一通り作ってくれて、そのコンポーネントに名前をつけてくれたということが偉大だと思います。CSS のクラスの名前にデファクトスタンダードを作ったということは大いに評価すべきで、以後の管理は少しは楽になると思います。

Bootstrapは、所詮はコンポーネントの集まりで、利用する人の能力によってどうにでもなります。Bootstrap は、カスタマイズをするのが難しく Bootstrap 臭がするからダメだという人は、CSS をカスタマイズする能力がない人です。自分のようにデザイン能力がない人間が使えばしょぼいデザインのものしかできません。

レスポンシブ Web では、以前は Google アドセンスを入れるのが難しかったのですが、レスポンシブ広告ユニットが使用できるようになっているので、それほど問題なく導入することができました。

Visual Studio で Sass 版 Bootstrap を使う

2014-12-22T17:44:00+09:00

以前にもBootstrapを使おうと思って調べてことがあったのですが、Moongiftの記事には、欠点として、Bootstrap臭があるとして以下のようなことが書いてありました。

Bootstrapのデザインは我が強く、Bootstrapを使っているなとすぐに感じられてしまいます。これを嫌うデザイナーはとても多いです。個人的にもそれは致し方ないと思っていたのですが、最近【難しく考えすぎ！？】bootstrap臭のしないお洒落なレスポンシブWEBデザインの作り方 | WEBデザイナーの憂鬱という記事を読み、グリッドだけ採用するというのはやはりありなのだと気付かされました。

他のブログを見ても同じようなことを書いていたし、自分の場合はグリッドを使う機会はあまりないので、それじゃ使うのやめとこうかということになっていました。

しかし、最近、jQuery UI を使ったり素材をいろいろなところから取ってきていると、バランスの取れないデザインになってきていたので、もう一度 Bootstrap はどうなのかを調べ直してみました。そうしたら、bootstrap.css を単に使うのではなく、Sass 版の Bootstrap である、bootstrap-sass を使うことでカスタマイズがすごくやりやすくなるのがわかりました。それで、bootstrap-sass の使い方を少しメモしておきます。

Bootstrap 自体が、Less で開発されているのだから、それを機械でコンパイルして作った bootstrap.css を修正しようと思ったら無理があるのは当然ですよね。それから、Bootstrap は Less で開発されているのですが、Sass の方が下の方でも少し触れるのですが、機能が少し多くて少し便利なので、初めて使うのだったら Sass を使った方がいいと思います。

Visual Studio は、2013 update 2 以降でSass に標準対応しており、インストールの手順は、stackoverflowの「How To Use SASS in Visual Studio 2013」を参考にしました。

1. メニューの「ツール」→「機能拡張と更新プログラム」を使って、VS2013 に Web Essentials 2013 をインストールします。Web Essentials 2013 には、Sass のコンパイラも含まれているので、これだけの作業で Sass が使えるようになります。

2. SASS の設定は、メニューの「ツール」→「オプション」でできますが、インストール時の設定が下の図のようになっているので、特に設定をしなくても、.scss ファイルを保存した時に自動的にコンパイルされます。

3. プロジェクトに Bootostrap-sass をインストールするには、NuGet を使うと便利です。

4. Bootostrap-sass をインストールすると下の図のようにファイル構成になります。

4. そこで、_bootstrap.scss をコピーして、例えば、bootstrap-custom.scss という名前を付けて保存します。_bootstrap.scss の内容は、下の図のようなものです。例えば、不要なコンポーネントがあれば、ダブルスラッシュでコメントアウトして保存すれば除外できます。

5. bootstrap-custom.scss を保存すると、自動的にコンパイルされて下の図のように bootstrap-custom.css が作成されます。

Visual Studio で、2013 update 2 が公開されたのが今年(2014年)の5月なので結構最近のことですが、それ以降は本当に簡単に Sass が使えるようになっています。

次に、Web デザイナーがよく使っている Dreamweaver の場合はどうかというと、Adobe の連載記事「SassをDreamweaver＆Edge Codeではじめよう」に説明があります。この記事の第１回は、Sass のいい説明になっていると思います。ただ、Dreamweaver 自体は Sass に対応していないので、Compass を直接使った方がはるかに便利だし、Windows PC の場合だと Visual Studio を使った方がずっと効率的だとは思うのですが、慣れたツールを使いたいという人は多いのでこういう使い方になるのかなと思いました。

Bootstrap のカスタマイズについては、オンラインツールとして本家のCustomize and downloadやライブでカスタマイズができる Bootstrap Live Customizer がありますが、それと同じカスタマイズを、Sass では、bootstrapフォルダーにある_variables.css を編集することで行うことができます。当然のことですが、下の図を見るとオンラインツールと同じ順番に変数が並んでいるのが分かると思います。だから、Sass を使って変数を修正するのに難しいことは全然ありません。

Sass のいいところは、上の図をみたら変数に !default が付いているところです。その場合、直接 _variables.css を編集する必要がなくて、先ほど作成した bootstrap-custom.scss で、bootstrap/variables を読み込む前に、変数を定義しておいてやると、その場合には default が定義されていると定義された変数の方が優先されます。だから、bootstrap-custom.scss を編集するだけでカスタマイズをすることが可能です。例えば文字の色を brand-danger と同じ色のしたいのであれば下の図のように @import “bootstrap/variables” の前に $text-color を定義してやればOKです。

こういうやり方だとカスタマイズした所がよく分かります。また、Bootstrap は、よくバージョンアップをしますが、Bootrap-sass のファイルを全く触らずにカスタマイズしているので、スムーズにバージョンアップをすることができます。

変数のカスタマイズ以上のことをしようとすれば、Sass のことを勉強する必要が出てきますが、基本は CSS ファイルと同じなので慣れるのは早いと思うし、Sass のページには、英語ですがきちんとしたドキュメントもあります。自分も、もう少しカスタマイズをしたいところがあるので Sass のことをもう少し勉強しようと思っています。

最後に、Visual Studio のことについてですが、Web デザインの関係では、自分が使い始めた数年前は本当にひどかったですが、現在では非常に優秀になっています。下の図のように、コードの変更をすぐに Page Inspector を使って見ることができるし、エディターは入力の補完機能が強力だし、カラーピッカーも備えています。自分のようにデザインなんかしたことがない人間でも、こういうWebデザインをする（させられる）時代になってきたので、Microsoft としては今後も力を入れていくと思います。その機能を Visual Studio Community 2013 か Express 2013 for Web であれば無償で利用できるので、WebデザインはAdobeのツールがいいとかいっていないで、どんどん使ってみたらいいと思います。

Web アプリをスマフォのホーム画面に登録してもらうためのメモ 1

2014-02-06T09:15:00+09:00

Web アプリでもネイティブアプリのように iPhone や Android のホーム画面に登録できるし、オフラインで動作させることもできるということなので、実際にやってみて、まとめてみました。

まず、一番最初に準備するのがホーム画面に登録するためのアイコンで、そのサイズは以下のとおりです。

iPhone (iOS7) 120px × 120px
iPhone（iPhone 4以降でiOS6まで）114px × 114px
iPhone（iPhone 3 まで）57px × 57px
iPad （iOS7）152px × 152px
iPad （iOS6までのRetina）144px × 144px
iPad （iOS6までの普通）72px × 72px
Android 48dp × 48dp

Android の場合は、Developers の Iconography をみると1x、1.5x、2x、3x、4x の機種があるので、48px, 72px, 96px, 144px, 192px のものになりますが、4x の XXXHDPi の機種は現実にはまだ殆ど存在しないはずで、3x と 2x が主流です。

これだけたくさんの解像度のアイコンを作るのは大変なので、取りあえずは152pxのアイコンを作っておけば、スマートフォン側で自動的に縮小、拡大してくれるので、それで対応することにしました。

作成したアイコンを表示させるためには、iPhone の場合は、それをPNG画像にして apple-touch-icon.png というファイル名でサイトのルートディレクトリに置いておけばいいだけです。apple-touch-icon-precomposed.png という名前で保存してもいいのですが、この場合は iPhone が自動でハイライト/シャドウを付けなくなります。iOS7からはフラットデザインになってiOS6以前のようなハイライト/シャドウはなくなったので、apple-touch-icon-precomposed.png を使う意味はあまりないと思います。

サイズを複数設置する場合は以下のようにアイコンのサイズを指定して設置すると、iPhone側で自動的に適当なサイズのものを選択してくれます。

apple-touch-icon-120x120.png

Android の場合は、ファイルを設置しただけでは認識してくれないので、以下のように link ダグで指定してやります。この指定の方法は、iOSの場合と同じです。

アイコンのサイズを指定したい場合は、以下のように sizes プロパティで指定することができます。この指定の方法も、iOSの場合と同じです。

以上で、スマートフォンのホーム画面にアイコンを貼り付けることができるようになります。スマートフォン側でホーム画面にアイコンを貼り付ける操作をどうするかについては省略します。

Safari のスタンドアローンモード（フルスクリーンモード）について

Safari では、スタンドアローンモード（フルスクリーンモード、Webアプリモード）と呼ばれているモードがあります。このモードに設定して、ホーム画面から起動するとURLバーが無くなってネイティブアプリに近くなります。

設定は、metaタグを使って以下のようにします。

また、以下の設定をすると下側にある Safari のステイタスバーの色を自分のアプリの色に合わせて変更することができます。

しかし、このモードを実際に使ってみて、注意が必要だと思われる点がありました。具体的には以下のとおりです。

1. localStorage が mobile Safari とは別になってしまう。

mobile Safari で設定した内容が使えなくなるので、結構不便だと思いました。

2. 普通のリンクだと mobile Safari が起動してしまう

普通にリンクすると mobile Safari が起動して、mobile Safari の該当のページが表示されます。だから、最早スタンドアローンモードはなくなってしまって、簡単に戻ることもできなくなります。これを防ぐためには、リンクをページ内リンクにするか、JavaScript での移動にします。

下の参考に記載した stackoverflow の Q&A によると下のようなスクリプトを書いてやればいいようです。

var a=document.getElementsByTagName("a");
for(var i=0;i<a.length;i++)
{
  a[i].onclick=function()
  {
    window.location='this.getAttribute("href");
    return false
  }
}

http://d.hatena.ne.jp/izit_kosuke/20110219/1298073430

http://stackoverflow.com/questions/2898740/iphone-safari-web-app-opens-links-in-new-window

3. 処理速度が遅くなる

スタンドアローンモードにすると、どうも起動時間が遅くなるように感じます。stackoverflow の Q&A にもあって、セキュリティの関係で Nitro という高速のJavaScriptエンジンが使えなくなるためのようです。

http://stackoverflow.com/questions/13413984/slow-initial-loadingscreen-ios-web-app

Android の場合にどうなるかを Nexus 5 で試してみました。Nexus 5 の場合は、localStorage は同じものを使います。普通のリンクにしておいてもモードが変わることはありません。その代わり、普通のリンクでは外部リンクであっても全画面表示のままになってしまいます。そして、ホーム画面のアイコンから立ち上げた場合、登録したページが表示されるのではなく、直近に表示されていたページがそのまま表示されます。

スタンドアローンモードを使うと見かけはアプリらしくなるのですが、採用するのがいいのかどうかは結構微妙です。localStorage が mobile Safari とは別になってしまうというのは、利用者にとっては結構戸惑うと思います。自分の場合は、アプリとしての完成度が低いので、当面はスタンドアローンモードを使わないことにしました。

次回は、Web アプリをオフラインで動作させることに挑戦したいと思っています。

徳島の交通状況 Google Maps API 版をオープンソースで公開しました

2013-11-17T21:49:00+09:00

徳島県の県土防災情報システムの中で「徳島県道路通行規制情報 Google Maps API 版」として7年間稼働していたものをベースとして、オープンソースとして GitHub で公開するとともに以下のURLでホームページを公開しました。

ホームページ：徳島の交通状況 Google Maps API 版 http://tk.ecitizen.jp/
ソースコード：TKGMap https://github.com/awoni/TKGMap

Google Maps API の関係でテストしておきたいことがあったこと、Google が提供している交通状況と規制情報を併せて表示させると結構便利なことから、問題はないわけではないが、オープンデータを作るのは結構簡単だよということも言いたかったので公開することにしました。

徳島の交通状況のホームページのサーバーは、Amazon S3 を使っている。Amazon S3 はこのようなシステムであれば保管料が1Gあたり0.1$、データ転送量が1Gあたり0.2$なので月10円のレベルで運用でき、それでいて大量のアクセスがあっても問題なく動作する。もちろんその分の転送量は必要になるだけど、一時的に大量のアクセスが予想されるシステムでは非常に便利だ。

最近、オープンデータという言葉が流行していて、公共データの公開が進められているられているが、あまりにSIer主導になっているのではないかと思う。データを公開するシステムを作るより先に、アメリカがしているように国が公開している情報は自由に使えるといってくれた方が遙かに開発しやすくなると思う。政府が提供したいデータと開発者が利用したいデータでは一致しないことも多いが、日本の場合はどこまでなら適法なのか訳がわからないところが多い。

これ以降は、最近あったGoogleマップ禁止令の件で調べたことをメモしておます。Googleマップ禁止令というのは、政府方針と反する外国語名で表記されているものがあるとして、政府が全国の自治体や国立大などに対し、それをホームページで利用しないよう通知していたという件である。名指しはしていないが、実質的には、Googleマップを使うなという通知となっている。

このGoogleマップの禁止令の経緯に関しては、片山さつき議員のブログ「NHK「みちしる」の国境離島誤表記でわかった、Googleマップにおける日本海、竹島、国後島、魚釣島表記問題、、官邸に即上申→世耕副長官より政府関係機関は全てチェック迅速対応」が参考になる。そこでは、以下のように述べている。

グーグル地図の世界版が日本の主張をいれた表記になっていないことは、再三国会でも取り上げ、外務省から抗議をさせていますが、グーグルの日本版region=jpに切り替えれば日本国としての正しい表記にはなる、ということで仕方ないと使ってきたわけですよね。
しかし、今回、国後島だけは、日本版にしても、国後島の上に表記されたキリル文字が消えないので、「これはないでしょう!ということで、グーグル日本本社に、私からも少なくとも日本版は全て日本政府の公式見解にあわせ、国後島、と単独表記するように強く要請したところです。前向きにご検討いだたいております。

この記事が書かれたのは今年の4月11日のことでで、NHK がGoogleの世界版を使っていたので日本海が東海と併記になっていたということで問題になったが、それ以外に、国後島が日本語版でもキリル文字で併記されているという問題があったようだ。その場は、グーグルの世界版を使わず日本版（region=JP)に切り替えるということと、国後島についてはグーグルに要請するということで収まったようだ。しかし、グーグルは、その後も国後島の併記はやめなかったので、とうとう8月に国土地理院が禁止令を出したようだ。なお、現時点では、国後島は日本語版では日本語のみの表記になっているので公的機関が使っても通知には違反しないようになっているようだ。

国土地理院が正確に表示されていると勧めている自分のところの地理院レイヤーも試してみて、以下のアドレスにそのサンプルを設置しているので参考にして欲しい。

http://tk.ecitizen.jp/gsi.html

サンプルを見ればよくわかるが、地図としての優劣は別にして、背景地図として使う場合にはゼンリンが作ったGoogleの地図とはデザイン的に全く勝負になっていないと思う。まあ、国が税金を使って Google マップに負けない背景地図を作るというのもどうかなと思うのでやむを得ないところだろう。

地理院の地図に関していえば、以前から電子国土という独自システムを作っていたが、googleマップに圧倒されて利用者が少なく、今年度末で地理院レイヤーという地図だけになって電子国土のシステムは廃止され OpenLayers というOSSを使用することになっている。OpenLayers対応の地図レイヤーは、上のサンプルようにGoogle Maps APIでも利用できるので、地理院の地図を使うのに一番便利なのが、Google Maps API というのも皮肉だ。

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

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

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

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

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

「長時間労働大国」と「テクノロジーが人間から仕事を奪う国」

2013-08-21T21:43:00+09:00

日本は長時間労働大国で残業ありきの国だ。一方で、Gigazine の8月9日の記事「急速に進化し続けるテクノロジーは人間から仕事を奪ってしまうのか」では、マサチューセッツ工科大学スローンマネジメントスクールのErik Brynjolfsson教授および彼の共同執筆者であるAndrew McAfee氏の「How Technology is Destoroying Jobs」という記事を紹介しているが、日本の現状と対比してみると面白い。

近年全世界で問題になりつつある就業率低下の背景に、産業ロボット工学から自動翻訳サービスまで幅広い分野において進歩し続けるコンピューター技術があると主張しています。次々と新しくなるテクノロジーを受け入れる産業は、製造・小売り・事務業だけにとどまらず、金融・法律に関する業種や医療・教育などのサービスにおいても最新技術を積極的に採用しています。

アメリカでは、確かに2000年初頭から生産性は上昇し続けているものの、雇用の方は成長をやめて低下し始めているという状態になっている。ただし、テクノロジーの進化が雇用の低下の原因になっていることについては、否定的な意見も多いようで、機械によって労働者が仕事を失っているという証拠を見つけるのはとても困難だそうだ。

2012年にAmazonに買収されたスタートアップ企業のKiva Systems はロボットの開発をする会社で、そのロボットを使えば通常の工場の4倍の量の注文を処理可能になるそうだ。そのKivaではロボットの販売好調に伴い、人員を増加させているが、そのほとんどがロボットのアルゴリズムを担当するソフトウェア・エンジニアだそうだ。

このような結果、アメリカでは左の図のように2000年から2010年で最も大きく伸びた職業はソフトウェアエンジニアだった。そして、以前の記事で紹介したようにソフトウェアエンジニアは、2010年から2020年にかけても大きく成長する職業だといわれている。

一方、日本では、今でもプロジェクトマネージャー > システムエンジニア > プログラマーという身分制度があって、プログラミングは下賤な作業と思われている。そういうことで、設計もプログラムもするソフトウェアエンジニアという言葉自体が普及していない。そして、さらにはIT技術者は3Kの職業で将来絶滅するとまでいわれている。

結局、アメリカが、コンピュータ技術を取り入れることで生産性をあげたが、そういう欧米の企業に対して日本の企業では長時間労働をさせることによって競争力を維持しようとしているようだ。欧米では失業が問題になり、日本では長時間労働や過労死が問題になっているのは、そういう理由だろう。世界中どこでも労働者には厳しい時代だ。

ただし、特殊合計出生率が、アメリカ2.1、イギリス1.94に対して日本は1.39で、長期的にみると日本は子供を育てられなくなっている社会だからこのまままだと敗戦は確実だ。コンピュータ技術に対して長時間労働という禁じ手の武器で対抗しようとするのは、第2次世界大戦での戦いを思い出させる。

「SEにとって百年に一度のチャンスが来た」と「なれる ! SE」

2013-08-18T18:21:00+09:00

「SEにとって百年に一度のチャンスが来た」は、ITpro の6月21日の情報サービス産業協会（JISA）副会長横塚裕志氏へのインタービュー記事のタイトルだ。情報サービス産業協会（JISA）の副会長でSE一筋40年の人だけあって、SEに対する思い入れが強い。次のようにSEに檄を飛ばしている。

「日頃からシステムの開発に取り組んできたSEは論理的な思考力が鍛えられている。しかも、SEは研究、製造、営業、経理、人事といった様々な組織のシステムを開発し、運用してきたから、組織間の関連や全社の業務の流れを俯瞰できる」。

自分は、どちらかというとSE不要論の方なので、それとは全く正反対のこのを書いてあった記事なので頭の片隅に残っていた。

お盆休みに、「なれる ! SE」というライトノベルが結構人気になっているということで「なれる!SE (8) 案件防衛?ハンドブック」を読んでみた。作者の夏海公司氏は元SEということで、日本のIT業界の実情がかなりリアルに描かれている。今回読んだ巻のテーマは既存顧客案件の攻防というよくある案件でスリリングなこともあるので面白く読むことができた。

このライトノベルを読んでいて、頭をかすめたのが横塚氏の記事である。確かに日本のIT産業を牽引してきたのはSEだったということは間違いない。大手SIerを中心にITゼネコンと呼ばれる世界、すなわち、SEというプロジェクト管理能力、顧客折衝能力がある人間を中心にして、下請けのSEやPGを使ってシステムを作っていくという構造を作った功績は大きい。

一方世界では、こういう日本のIT企業とは全く別世界にあるIT企業も多い。例えば、37シグナルの創始者の２人が書いた「小さなチーム、大きな仕事 - 37シグナルズ成功の法則」では、小さなソフトウェア会社が成功するための一つの手法が書かれているが、全くビジネスモデルが違う。

僕たちはまだみずからに制約を課している。一度にサービスに携わる人間は、一人もしくは二人だけにしているのだ。そして、つねにサービスの機能は最小限にとどめている。このように自身に制約を課すことで、あいまいな形のサービスを生み出さないようにしているのだ。

あれがない、これがないと嘆く前に、今自分ができることは何なのかを考えてみよう。

こういうやり方ってシンプルだけど余分なものがないから非常に効率がいい。確かに大規模なシステム構築の案件ではSEは必要だと思う。でも、それ以外の場合に本当にSEという調整役の人間が必要なのかはもう少し考えた方がいいと思う。自分もWebサービスを作ったり運営したりしているけど、今はクラウドサービスや OSS のソフトウェアがあるから、一人で数百万ページビューぐらいのWebサービスを作成して運営するのは可能だと思っている。

日本は会社人間が多い国だと思っている人が多いが、実は下のグラフのように、もともとは自営業の多い国だったということだ。1980年代に日本が成功した裏には、多様な技術を持った自営業者がいたということを本当は忘れてはいけないことなのだ。

平成23年度年次経済財政報告

日本は、高度成長気に労働集約サービスを有効に活用して世界のナンバー２になった。その成功体験から、会社という組織で普通に優秀といわれている人を中心にして、コミュニケーション能力や協調性のある人間を多く集めて仕事をするのがベストだという意識が身についてしまったようだ。

でも、1人や2人でも Webサービスが作れる時代だし、他方では、中国やインドには日本のエンジニアの半分以下の給料で働くエンジニアがいるという時代だ。大きな組織をつくれば身軽さや柔軟さを失ってしまう。5人で2人分の仕事しかできなければ、会社としては長時間のサービス残業をさせるしか生き残る道はない。それが日本の多くのIT企業やWeb制作会社の実態だろう。高度成長期の成功体験を忘れて、どうしたらいいか自分の頭で考えてみることが必要なのではないかと思う。

日本からやっとシステム・エンジニア、プログラマーという職業がなくなった！

2013-08-03T14:08:00+09:00

日本標準職業分類での話ですが、システム・エンジニア、プログラマーという職業がなくなっています。平成21年12月に改訂される以前の日本標準職業分類（平成12年12月改定）では、情報処理技術者は、061 システム・エンジニア、062 プログラマーの二つに分類されていました。その職業の説明は次のようになっていました。

システム・エンジニア

電子計算機による情報の整理・加工・蓄積・検索等に関する機械化された業務システムの分析・設計及びプログラムの設計についての技術的な仕事に従事するものをいう。

プログラマー

システム設計書に基づいて、各種プログラム及びコンピュータ処理に必要な操作手引書等を作成するものをいう。

この分類は、IBMが主導していたメインフレームの時代の産物です。日本では今でもシステム・エンジニア、プログラマーという職種に分けて仕事をいる会社も多いようですが、世界的にみれば一人で設計もプログラムもするのが常識です。

やっと平成21年12月に改訂されていて、情報処理・通信技術者は、以下のように分類されるようになっています（詳細は総務省政策統括官（統計基準担当）日本標準職業分類（平成21年12月統計基準設定））。

101システムコンサルタント

102 システム設計者

103 情報処理プロジェクトマネージャ

104 ソフトウェア作成者

105 システム運用管理

106 通信ネットワーク技術者

109 その他の情報処理・通信技術者

そのうちシステム設計者とソフトウェア作成者について、説明と内容例示を抜粋すると以下のようになる。

システム設計者

顧客又は自己の問題の解決のため、ハードウェア、ソフトウェア双方を含め、主として必要なシステム全体の構成を企画する仕事に従事するものをいう。パッケージソフトウェアの開発企画、企業等でシステムの導入に関する企画や導入時の監督の仕事に従事するものも含まれる。ただし、個々のソフトウェアの開発の仕事に従事するものは小分類〔103〕に分類される。
○システムアーキテクト；システムアナリスト；情報処理アーキテクト；ＩＳアーキテクト
×情報処理プロジェクトマネージャ〔103〕；プログラマー〔104〕

ソフトウェア作成者

ソフトウェア作成（基本ソフトウェア及びアプリケーションソフトウェア双方の開発を含む。）のための仕様決定、設計及びプログラミングの仕事に従事するものをいう。ただし、主としてシステム全体の構成を企画する仕事に従事するものは小分類〔102〕に分類される。
○テクニカルスペシャリスト;プログラマー；ゲームプログラマー；ＣＧプログラマー；社内システムエンジニア；クリエータ（情報通信産業に関するもの）
×システムアーキテクト〔102〕；情報処理プロジェクトマネージャ〔103〕

かなり国際標準に近くなっています。システム・エンジニアに配慮してか、システムアナリストという職種が確立できていないためかはわかりませんが、本来はシステムアナリストとすべきところをシステム設計者としている点はありますが、以前と比較すればかなり進歩しています。

厚生労働省編の職業分類の方も平成23年に改正されています。総務省と微妙に違っていて、ソフトウェア作成者をソフトウェア開発者を呼んでいます。（詳細はハローワークの労働省編職業分類）

職業分類は改正されたものの、ハローワークインターネットサービスの求人をみても、こちらの職種名だと依然としてシステムエンジニア、プログラマーという名前が使われているし、平成24年賃金構造基本統計調査の結果もシステムエンジニア、プログラマーの分類で公表されています。参考までに、平成24年賃金構造基本統計調査の結果をメモしておきます。

システムエンジニア 281,250人年収5,376,200円

プログラマー 110,450人年収4,192,600円

なぜ、日本の職業分類がこのように変更されたかというと、国際標準職業分類（ISCO 参考）が2008年に改訂されたためということのようです。参考までにISCO-08での情報処理・通信技術者の分類は以下にメモしておきます。

25 Information and communications technology professionals（情報通信技術専門職）

251 Software and applications developers and analysts（ソフトウェア・アプリケーション開発者、アナリスト）

2511 Systems analysts（システムアナリスト）

2512 Software developers（ソフトウェア開発者）

2513 Web and multimedia developers（ウェブ・マルチメディア開発者）

2514 Applications programmers（アプリケーションプログラマー）

2519 Software and applications developers and analysts not elsewhere classified（他に分類されないソフトウェア・アプリケーション開発者、アナリスト）

252 Database and network professionals（データベース・ネットワークの専門職）

以下略

ISCO-08の前のバージョンである ISCO-88 では、2131 COMPUTER SYSTEMS DESIGNERS AND ANALYSTS 、2132 COMPUTER PROGRAMMERS に分類されていて基本的には日本のシステム・エンジニアとプログラマーの分類と同じです。確かに 1988年当時は、コンピュータのコストが無茶苦茶高い時代でした。設計やプログラミングをコンピューターにアシストさせるということができなかったので、プログラム部分に人を大量に動員する必要があったので、設計とプログラムを分けるのは合理的な方法だったように思います。

ISCO-08 と日本標準職業分類との違いを見てみると、日本では情報処理プロジェクトマネージャが入っていることです。ISCO-08では管理的職業従事者の 1330Information and communications technology service managers が該当すると思われます。

ソフトウェア・デｨベロッパーはアメリカではベスト10に入る人気職種なのに、日本では「なくなる仕事」といわれる

2013-07-25T23:29:00+09:00

CNNMoney の BEST JOBS IN AMERICA を見ていると、ソフトウェア・ディベロッパーが 9位に入っていることに気がついた。日本では、プログラマーやSEといえば、給料は安く、残業や休日出勤が当たり前の体力勝負の3K職場なので IT土方といわれているが、アメリカでは人気職種なのである。

最近の現代ビジネスの2020年「なくなる仕事」という記事では、プログラマーは「なくなる仕事」の3番目にあげられていて、次のように書かれている。

欧米では海外へのアウトソーシングが進んでいる。「システム開発の仕組みさえ構築されていれば、個々のプログラマーが日本にいる必要もなくなってくる」、「プログラミングそのものが機械化される」可能性も

こんなことを書く人たちが、生き残る会社はトヨタ自動車だといっている。トヨタ自動車が生き残るのであれば、実はプログラマーだって生き残れる。車はどんどん「プログラムの塊」になってきているからだ。自動車1台に搭載する電子制御ユニットの数が、100個以上にのぼる車両もあるそうだ。

欧米では海外へのアウトソーシングが進んでいるというが、アメリカで IT技術者がどうなっているかを、アメリカ労働局が作成している O*NET OnLine で調べてみた。要約すると以下のようになっている (http://www.onetonline.org/find/family?f=15&g=Go)。

15-1121.00 - Computer Systems Analysts (544,000人、$79,680、20% to 28%)

15-1122.00 - Information Security Analysts (302,000人、$86,170、20% to 28%)

15-1131.00 - Computer Programmers (363,000人、$74,280、10% to 19%)

15-1132.00 - Software Developers, Applications (521,000人、$90,060、20% to 28%)

15-1133.00 - Software Developers, Systems Software (392,000人、$99,000、29% or higher)

15-1134.00 - Web Developers (302,000人、$62,500、20% to 28%)

15-1141.00 - Database Administrators (111,000人、$77,080、29% or higher)

15-1142.00 - Network and Computer Systems Administrators (347,000人、$72,560、20% to 28%)

15-1143.00 - Computer Network Architects (302,000人、$91,000、20% to 28%)

15-1151.00 - Computer User Support Specialists (607,000、$46,420、10% to 19%)

15-1199.00 - Computer Occupations, All Othe (210,000人、$81,140、3% to 9%)

括弧内の数字は、従業者数、年収、2010年から2020年への伸び率である。

このデータをみればわかるようにアメリカでは、コンピュータ・プログラマーでさえも、2010年から2020年に全職種の平均的な伸び率である10%から19%の伸びが期待されている。決してなくなる仕事ではないのである。

ソフトウェア・ディベロッパーは、プログラミングを中心に設計等ソフトウェア開発全般を行う職種であるが、年収は9万ドルを超えていて、人気職種であることがよくわかる。こちらの方は、今後就業者が高率で増加する職種となっている。

結局、アウトソーシングが進んでも、すべてをアウトソーシングできるわけではないのである。ましてプログラミングというのは技術の中核的な存在になってきているからプログラマーという職種は消えることはありえない。

それでは現代ビジネスの記事が全くの嘘かというと、日本がこれまで大量に育ててきたプログラマーの一部（一部といっても結構大量かも）が不要になってきているというのは事実である。そういう一部のプラグラマーのことで、すべてのプログラマーが不要だと読めるような記事にするのはどうかなと思う。

HTMLのテーブルに機能を追加する JavaScript Grid ライブラリーを調べてみた

2013-07-21T14:42:00+09:00

Webサービスを開発していると、アプリケーションの中にはテーブルを多用する場合があります。現在作成中の「統計データ API エクスプローラ」は、その典型的な例です。それで、大量のデータを Excel のように便利に表示してくれる JavaScript ライブラリーを探してみました。

DataTables

この分野のライブラリーで、最も有名で、最も活発に活動しているのが、DataTables です。jQuery のプラグインで、HTML のテーブルにソート、スクロール、ヘッダー、フッター、編集等の機能を簡単に追加できるので便利なソフトです。使い易く機能が豊富なので、一般的な使い方では最もおすすめのライブラリーです。欠点といえばデータ量が多くなると重いことです。

jqGrid

DataTables についで有名なのが、jqGrid です。こちらも、jQueryのプラグインです。jqGrid は、DataTables ほどは親切ではありませんが、機能は豊富です。現在では、HTML Table も利用できるようになったり、サンプルも詳しくなっていますが、DataTables の方が使い易いのでどちらかというと開発者向けのライブラリーです。

SlickGrid

今回採用しようと思っているのは SlickGrid というライブラリです。機能は少ないし、データも JSON にする必要があるので、プログラマー向けのライブラリーです。しかし、大量のデータを処理できるライブラリーで、100万行のデータにも対応でき、APIも使えるということなので、今回のケースには最適だと思いました。現在テスト中ですがある程度使える目処がたちました。ライブラリーはいろいろありますが、有名なものを使うというだけでなく目的や用途に合わせて最適なものを選択することも必要だと思います。

少し話はそれますが、SlickGrid の作者である Michael Leibman 氏は、現在は Google 社のシニア・ソフトウェア・エンジニアです。Linkedin で調べると、SlickGrid は、Google 社に入社する前から作っていたそうです。欧米系IT企業では、有名なフリーソフトの作者は入社試験で圧倒的に有利だそうです。エンジニアtypeの記事「Twitterで働く日本人「開発現場はリアルなタイムラインのよう」」でも、twitterの非公式ライブラリを作っていて Twitter社に採用されたという日本人エンジニアが紹介されています。少し前に紹介した NLog の作者である Jaroslaw Kowalski 氏はMicrosoftのエンジニアです。このように就職に有利になるということも、世界的にはOSSのソフトウェアが盛んに作られている理由の一つだと思います。一方で日本のIT企業ではそういう話は全く聞かず、過酷な労働環境で「IT土方」になってしまっているのは非常に残念です。

エンジニアも休みを取ろう - Winny開発者・金子勇さんが死去

2013-07-08T14:41:00+09:00

P2Pファイル共有ソフトWinnyを開発したことで有名な金子勇さんが7月6日急性心筋梗塞で死去したという報道がされている。金子さんは1970年7月生まれで42歳だった。心筋梗塞はかなりの割合で予防できる病気であるだけに残念なことだ。

年齢と死因をみて、気になったのは過労のことである。40歳頃から体力が低下するので、無理な生活をしているとこういう病気になることがよくある。

金子さんが創立した株式会社SKEEDのWebページのリーダー紹介では、金子さんについて以下のような紹介があった。

趣味は暇プロ。何かアイデアを思いつくと、プログラムという形で表現し、検証してきた。小さいころからプログラミングを趣味とし、数々のプログラムを作成して現在に至る。日常ではトラックボールを愛用し、キーボードを抱えたまま就寝、起きてまたキーボードに向かう。そのため電動式の起き上がりベッドを常用しているが、これは東急ハンズで買ったものであり、よく噂されているような介護用ベッドではない。

この記述をみると、金子さんの場合は、自らの意思で長時間プログラミングをしていたようだ。自分の意思でということで一般的な過労死とは違いがあるものの、長時間労働はやはり健康によくないと思う。エンジニアも休みを取って遊びに行くべきだろう。

自分も少しは余裕を持つのがいいだろうということで、今回は花の写真を添付しておく。

政府統計データ API で公開されている統計表のリストを作ってみた

2013-06-28T10:10:00+09:00

総務省統計局と統計センターによって、次世代統計利用システム（API機能）の試行運用が6月10日から開始されました。自分も統計データAPIを使ってアプリケーションを作ろうと思っています。

ところで、統計APIの関係では「統計くん」というWebサービスがメディアに取り上げられています。例えばITmedia ニュースによると「個人開発者の矢野さとるさんは6月12日、10日に公開された「次世代統計利用システム」のAPIを活用し、国勢調査などの政府が持つ統計データをCSV形式でダウンロードできるWebサービス「統計くん」を公開した。」というような記事が掲載されています。

その「統計くん」を使ってみると、データの一覧には自分の欲しいデータがありませんでした。そのため今回のAPIの公開がかなり暫定的なものなのかと思ってしまいました。でも実際に調べていくと「統計くん」では統計APIで公開されている統計表のごく一部しか扱っていないことがわかりました。

自分で使うためにも、どういう統計データが公開されているかを知りたかったので、APIで公開されている統計表の一覧表を作成してみました。まだまだ未完成ですが、統計APIを使ってみようと思っている人には役に立つと思うので ecitizen.jp の方に「政府統計データAPI エクスプローラ」として公開してみました。

日本型SEOの終焉

2013-05-26T12:49:00+09:00

昨日「アフィリエイトで勘違い」の元増田氏のことを書いたので、それに関連してSEOのことについて書いてみました。その元増田氏がホームページを作り始めた2007年というのは、日本型SEOの最盛期の時期であり、また実際に「日本型SEO」が有効な時代でもありました。なお、SEO とは、日本語では検索エンジン最適化といい、特定の検索エンジンを対象として検索結果でより上位に現れるようにする技術のことです。

Google トレンドを使って、SEO の人気度を表示したのが下の図です。少し前に「CakePHPに飛びついた日本のITエンジニア」というブログを書いたけど、CakePHP とよく似た動きをしています。日本では、当時はSEO といって騒いでいましたが、2010年にYahoo Japan がGoogleの検索エンジンの採用し、2011年にはGoogleがパンダアップデートやペンギンアップデートと呼ばれる検索エンジンのアップデートをおこなったので、SEO対策だけで価値のないサイトは大きく検索順位を下げることになりました。それとともにSEOの人気度も急降下しています。

すべての国

日本

Google トレンドの図では、SEOの人気度の相対的な位置がよくわかるように、CMSとして最も有名なWordPress と Web アプリケーションフレームワークの Struts, Ruby on Rails, ASP.NET MVC, CakePHP, Grails, CodeIgniter, Laravel を合計したしたものを表示しています。日本の場合、Webページを作るためのツールであるWordPressよりSEOの方が人気があったというのはどう考えても過熱しすぎですよね。グラフを見るとSEOの人気度が急落して、日本も世界と同じような位置になったようにも見えます。

すべての国でみると、SEO は安定した動きをしているキーワードです。Web アプリケーションフレームワークも、個々のツールに関しては人気度が大きく動いていますが、それらを合計すれば安定した動きをしています。Web サイトに機能を追加しようと思えば、Web アプリケーションフレームワークを使った方が効率がいいから、根強い人気があるし、将来的にも Web 自体は重要な位置を占め続けると思うので、どのツールが人気を集めるかは別にして、根強い人気を持ち続けると思います。

SEO も Web アプリケーションフレームワークと同じようなものです。Web の世界では検索エンジンに拾ってもらわなければ、誰にも知られない存在です。だから、検索エンジンを理解して、検索結果をより上位に現れるように努力することは Web に携わるエンジニアであれば当然のことです。Google 自身がウェブマスターツールを作成し、SEO の解説をしていることからもわかるでしょう。最後に、SEO の未来について、「「SEOは終わった」のではなく、進化した」という記事を紹介しておきます。

http://www.seojapan.com/blog/future-of-seo

アフィリエイトで勘違い

2013-05-25T22:38:00+09:00

はてな匿名ダイアリーにあった「アフィリエイトで勘違いした大学生の末路」の記事を読んだときに気になったのですが、イケダハヤト氏も「「ブログで稼ぐ」「アフィリエイトで稼ぐ」なんて夢は見ない方がいいですよ」という記事を書いていたので少し自分の感じたことを書いてみた。

元増田氏は、趣味で作成したホームページが、多い時で1日12万PVもあるサイトになり多いときで月80万円も収入があった。しかし、べた書きで作っていて、MVC は理解できなかったから、できることに限界があった。昨年の11月にグーグルのアルゴリズムが代わり検索順位が大きく下がった。多い時で80万円あった収入は20万円台にまで落ちた。

それで元増田氏は、「ゲームオーバー」したとして、「僕は公務員を目指すことを考え始めた。」そうだ。そして次のようにいっている。

勉強したあげく面接に落ちたらどうなるだろう。
27歳にもなるのに職歴がなく、独学でphpとSQLを囓った程度ではWEB制作会社は雇ってはくれないだろう。
詰んだかな、これ。
もっと外に出て、みんなと同じ大学生活を送って、みんなと同じ就職活動をして、みんなと同じように働いていれば。

イケダハヤト氏は、ブログの中で「コンテンツ制作のスキルはかなりありそうなので、公務員よりふさわしいキャリアはありそうな気もしますが…。」と言っているし、トラックバックでもスキルあるからと同情的なものが多い。でも、自分は元増田氏にスキルがあるとは思っていない。

なぜかというと、昨年の11月に検索の順位が大きく下がったということは、Google のいわゆるパンダアップデート呼ばれる検索アルゴリズムの変更によるものだと思われる。パンダアップデートは、質が低いとみなされるサイト、例えばコピーサイトや重複サイトのようにユーザにとって価値のないサイトの順位を下げてGoogle 検索の品質を高めようとするものだ。要するに元増田氏が作っていたサイトというのは、価値のないサイトだった可能性が大だ。そら技術力ないから、「ゲームオーバー」するしかなかったのだと思う。

多分元増田氏は要領がいい人間だったのだと思う。それで一時的には相当な儲けができた。でも理念のない人間だったので価値のないサイトを作ってしまった。最近、そういう要領はいいけど理念のない人間が幅をきかせているような気がする。彼らは口ではうまいことを言うが、創造性はないからどんどん内向きになって仕事をつまらなくしてしまう。

元増田氏が「みんなと同じように働いていれば」というのは過去の成功体験だろう。日本の高度成長期には真面目に働く労働者がいるのは日本だけだったので、真面目に働けばそれだけで成功した時代だった。しかし、現在では真面目に働く労働者は、中国にもインドにも東南アジアにも日本の数倍の労働者がいる。そして、彼らの給料は日本人の1割や2割である。だから、みんなと同じように働くだけでは、給料に下降圧力がかかるのは無理がないことである。だから最後の結論が「みんなと同じように働いていれば」というのは本当に寂しい。

イケダハヤト氏は、自分がブロガーであることについて次のように書いている。

でも、ぼくはプロブロガーを辞めることは当面ありません。限界までこの仕事で稼ぎつづけるつもりです。
なぜか？それはぼくが「書くことが大好き」だからです。もう、これ以上の理由はありませんね。どれだけ厳しくても、稼げなくても、この道は諦めたくないのです。

プロとして生きるというのはそういうことだよね。自分も価値のあるWebサービスを作りたいと思う。

最後に Google の理念ということで、Google が掲げる10の事実のタイトルのみだけど記載しておく。

ユーザーに焦点を絞れば、他のものはみな後からついてくる。
1 つのことをとことん極めてうまくやるのが一番。
遅いより速いほうがいい。
ウェブでも民主主義は機能する。
情報を探したくなるのはパソコンの前にいるときだけではない。
悪事を働かなくてもお金は稼げる。
世の中にはまだまだ情報があふれている。
情報のニーズはすべての国境を越える。
スーツがなくても真剣に仕事はできる。
「すばらしい」では足りない。

CSS フレームワークを使う

2013-05-20T09:23:00+09:00

今まで CSS については、必要な時になって必要な部分だけ追加していたけど、それだとレイアウトの統一性がなくなるし、CSSがどんどん複雑になっていくのでなんとかしないといけないと思っていた。それで、CSS フレームワークについて調べてみた。

CSS フレームワークの一覧については、CSS Frontend Frameworks が結構綺麗にまとめている。CSS フレームワークは結構たくさんあるので、代表的なものを列挙してみた。

どれを使うべきなのかというと、本来は実際に使ってみて比較すべきなのだが、Twitter Bootstrap が一番人気で Twitter Bootstrapを利用すると、簡単にTwitter 的なデザインのWebサイトを作成できそうだし、Umbraco でも既に uBootstrap というスターターキットもあって結構ダウンロードもされているので、とりあえずは、Twitter Bootstrap を使ってみようと思っている。

CakePHPに飛びついた日本のITエンジニア

2013-05-19T00:33:00+09:00

Google トレンドで Web アプリケーションフレームワークの人気度を調べていたら、日本だけが世界と違う動きをしていることに気がついた。そのグラフが下の図で、赤が Ruby On Rails、黄色が CakePHP、青が ASP.NET MVC、緑が Grails。グラフを見ると、日本では、2006年～2009年にかけて CakePHP の人気度が急激に伸びていて、飛びついたという感じになっている。2010年以降は、すべての国だと、CakePHP も Ruby on Rails も人気度が横ばいとなっているし、アメリカも横ばいで推移しているし、イギリスやドイツ等も見てみたが横ばいだった。しかし、日本では人気度が下がり続けていて、Web アプリケーションフレームワークなんて終わったといっているような感じのグラフになっている。

現在、企業が収益を上げるためにはIT投資は重要だし、IT投資の中でWeb アプリケーションフレームワークの役割は大きいと思う。現に他の国ではWeb アプリケーションフレームワークへの関心度が減少していないことを考えると、日本のIT企業は何をしているのかと思ってしまう。日本のIT企業は受託が多いいため、委託元が近年の不況によって投資の削減をしているからどうしてもその影響を大きく受けてしまうのかもしれない。

すべての国

日本

アメリカ

Amazon.co.jp で本のベストセラーで調べてみると、Web アプリケーションフレームワーク関係の本では、「コンピュータ・IT」の「プログラミング」の「その他」で「CakePHP2 実践入門」が92位で一番上位で、日本では CakePHP が一番人気だということと合致している。次が、「Ruby on Rails 3 ポケットリファレンス」で238位となっていて、日本ではWeb アプリケーションフレームワークの本はあまり売れていない。なお、Amazon のベストセラーの順位はすぐに大きく変わるからあくまで概数値だと思ってほしい。

&amp;amp;lt;/iframe

一方、Amazon.com で見てみると、コンピュータ・IT」の「プログラミング」全体で、「Pro ASP.NET MVC 4」が9位、「Ruby on Rails Tutorial: Learn Web Development with Rails (2nd Edition)」が70位と日本と比較にならないぐらい売れている。

この結果をみていると、世界のエンジニアが Web アプリケーションフレームワークに関心を持ってきちんと学んでいるのに対して、日本のITエンジニアは無関心になってきて大丈夫なのといいたくなってくる。

それから、ASP.NET MVC の将来に関して言えば、Amazon.comで本が売れているのは結構大きいと思う。日本ではASP.NET MVC はあまり使われていないようだけど、世界的には結構普及するように思う。

最後に、Java の Web アプリケーションフレームワークについて少し補足しておくと、かっては Struts が大成功をおさめて2000年前半には事実上のスタンダードになっていた。それで、現在でもまだ多くのシステムで利用されていて、Google トレンドの人気度でもまだ一番だ。しかし、急激に人気度が落ち込んでいるのでグラフが見づらくなること、すでにセキュリティパッチやバグ修正は提供されない状態になっていることを考えて除外した。後継としては Struts 2, Spring Web MVC, Grails, Stripes 等があり、かなり混沌としているようなので、比較的人気度の高い Grails を選択した。これらを併せると現在でも Java 系のフレームワークが圧倒的に多く使われているということは事実だ。でも、かってのような圧倒的な強さはなくなっている。

（追加 2013年5月25日）

PHP のWeb アプリケーションフレームワークに関しては、最近はCakePHP よりも CodeIgniter や Laravel の方が人気があるようだ。Google トレンドのすべての国と日本での人気度のグラフを下に載せておきますが、日本ではやっぱりWeb アプリケーションフレームワークの人気ないよね。

すべての国

日本

/img/w/2013/05/image_thumb7.png" alt="image" border="0" style="background-image: none; padding-top: 0px; padding-left: 0px; display: inline; padding-right: 0px; border: 0px;"/>