C#、ASP.NET、TypeScript、AngularJS を中心にプログラミングに関した話題を諸々。
by @jsakamoto
検索
リンク
北海道のITコミュニティ - CLR/H 無聊を託つ
タグ
カテゴリ
最新の記事
[解決] スリープからの復帰..
at 2018-08-28 18:37
空のフォルダをコンテンツに含..
at 2018-07-23 22:33
ASP.NET Core 2..
at 2018-06-29 19:02
気が付いたら Visual ..
at 2018-05-23 22:34
Azure AD のユーザー..
at 2018-04-29 22:33
最新のコメント
すみません、記事書きかけ..
by developer-adjust at 22:36
続きはないんですか?
by hanamo at 13:03
助かりました。ありがとう..
by あああ at 21:32
いえす、F#! F#! :)
by developer-adjust at 21:46
F#はAzure Not..
by 幻のK泉さん at 18:37
> 今、Setcronj..
by developer-adjust at 08:25
今、Setcronjob..
by Kibe at 03:23
Jichym 改め yi..
by yi at 23:00
バッチファイル(.bat..
by Jichym at 01:26
なるほど、そこにテコ入れ..
by developer-adjust at 21:25
記事ランキング
最新のトラックバック
Web API における..
from 松崎 剛 Blog
[Other]Code2..
from KatsuYuzuの日記
Developer @ ..
from .NET Clips
asp.netでrail..
from 4丁目より
F#でASP.NET M..
from ナオキにASP.NET(仮)
[B!] これはいい h..
from Twitter Mirror
[報告] Microso..
from .NET Clips
Developer @ ..
from .NET Clips
[F#]F# でブログア..
from 予定は未定Blog版
ASP.NET MVC ..
from ナオキにASP.NET(仮)
以前の記事
2018年 08月
2018年 07月
2018年 06月
2018年 05月
2018年 04月
2018年 03月
2018年 02月
2018年 01月
2017年 12月
2017年 11月
2017年 10月
2017年 09月
2017年 08月
2017年 07月
2017年 06月
2017年 05月
2017年 04月
2017年 02月
2017年 01月
2016年 12月
2016年 11月
2016年 10月
2016年 09月
2016年 08月
2016年 07月
2016年 06月
2016年 05月
2016年 04月
2016年 03月
2016年 02月
2016年 01月
2015年 12月
2015年 11月
2015年 10月
2015年 09月
2015年 08月
2015年 07月
2015年 05月
2015年 04月
2015年 03月
2015年 02月
2015年 01月
2014年 12月
2014年 11月
2014年 10月
2014年 09月
2014年 08月
2014年 06月
2014年 04月
2014年 03月
2014年 02月
2014年 01月
2013年 12月
2013年 10月
2013年 09月
2013年 08月
2013年 07月
2013年 06月
2013年 05月
2013年 04月
2013年 03月
2013年 02月
2013年 01月
2012年 12月
2012年 11月
2012年 10月
2012年 09月
2012年 08月
2012年 07月
2012年 06月
2012年 05月
2012年 04月
2012年 03月
2012年 02月
2012年 01月
2011年 12月
2011年 11月
2011年 10月
2011年 09月
2011年 08月
2011年 07月
2011年 06月
2011年 05月
2011年 04月
2011年 03月
2011年 02月
2011年 01月
2010年 12月
2010年 11月
2010年 10月
2010年 09月
2010年 08月
2010年 07月
2010年 06月
2010年 05月
2010年 04月
2010年 03月
2010年 02月
2010年 01月
2009年 12月
2009年 10月
2009年 09月
2009年 07月
2009年 06月
2009年 05月
2009年 04月
2009年 03月
2009年 02月
2009年 01月
2008年 12月
2008年 11月
2008年 10月
2008年 09月
2008年 08月
2008年 07月
2008年 06月
2008年 05月
2008年 04月
2008年 03月
2008年 02月
2008年 01月
2007年 12月
2007年 11月
2007年 04月
2007年 03月
2007年 02月
2007年 01月
2006年 11月
2006年 10月
2006年 09月
2006年 08月
2006年 07月
ファン
ブログジャンル
画像一覧
2017年 10月 30日

ASP.NET Core SignalR v.1.0 Preview2 Final で Web API のアクションメソッド内など任意の箇所からクライアントにプッシュ送信する方法

ASP.NET Core SignalR とは

C# などの .NET 言語で実装する Web アプリのフレームワークである ASP.NET。
その ASP.NET フレームワーク上で、ブラウザ~サーバー間のリアルタイム双方向通信を実現するライブラリが SignalR である。

Node.js でいうところの Socket.IO に相当する、といえば話のとおりが良いだろうか。
(※もっとも、両者はそれぞれの思想や特性があるのであまり似てはいないとのこと。サーバー側からブラウザ側へ "プッシュ" する機能をカバーするという点で類似のライブラリとして話題にされるようだ。)

その SignalR だが、ASP.NET の新世代である ASP.NET Core 版もちゃんと存在する。

ただ、この記事を書いている時点では、ver.1.0.0 Alpha2 リリース最終版というバージョンが、プレリリース版として公開されているのみ。
まだ正式の初版リリースには至っていない。

Alpha1 から Alpha2 に更新されたときも、若干の破壊的変更があったようで、いかにもまだ Alpha 段階という感じ。

そんな αバージョン時点での、ASP.NET Core SignalR のお話。

ASP.NET Web API から SignalR への連携

SignalR を使った Web アプリを実装しているときに、サーバー側とクライアント側との間の通信技術が SignalR 一択である場合は、とくに困ることなく教科書どおりに実装すればよい。

しかし時折、その同一 Web アプリ上で、任意の HTTP クライアントに対する公開 Web API を搭載したい、なんてことがある。

で、えてして、その Web API で何やらが POST されたら、SignalR 経由で他のクライアントにプッシュ通知したい、なんて話になったりする。

さて、ASP.NET (ASP.NET Core じゃないほう) 時代、Web API の実装にあたっては、ASP.NET WebAPI が提供する ApiController クラスの派生クラスで API コントローラクラスを実装する。
Web API の要求は、この API コントローラクラスのメソッドに紐づけられる寸法だ。

ということで、Web API への POST を、SingalR によるプッシュ通信につなげるには、(POSTを受け付ける) API コントローラクラスのメソッド内で、SignalR における Hub クラスのコンテキストを手に入れる必要がある。


これを実現するには、下記のように書けば OK だ。
using Microsoft.AspNet.SignalR;
// FooHub という SignalR Hub クラスが定義済みだとして:
...
public IActionResult Post(...) {
...
var connectionManager = GlobalHost.ConnectionManager;
var hubContext = connectionManager.GetHubContext<FooHub>();
// ここで hubContext.Clients.All.hoge(...) とかできる
..
すなわち、ASP.NET SignalR が提供する GlobalHost クラスの ConnectionManager という静的プロパティを経由して、Hub コンテキストを入手可能という仕組みだ。

静的プロパティは、少なくともスコープの観点では事実上のグローバル変数のようなものだろう。
それでどんなシチュエーションからでも参照・入手可能ということになる。

ちなみに他にも、"HubController<T> を使う" という技法もあるらしい (2013年の記事だが、下記参照)。

ASP.NET Core SignalR からは GlobalHost クラスは廃止

...と、まぁ、ここまでは ASP.NET Core じゃない、元祖(?) ASP.NET における話。

実は ASP.NET Core 上の SignalR では、GlobalHost クラスは廃止された模様だ。

では ASP.NET Core の SignalR において、"API コントローラクラスのメソッド内から SignalR でのサーバー側からのプッシュ送信" を行うにはどうしたらよいか?


ASP.NET Core では、単純に、コントローラクラスのコンストラクタ引数に必要とするサービスインスタンスを渡してくれる、"DI (Dependency Injection, 依存性注入)" の仕組みで、任意の Hub のコンテキストが手に入る。

すなわち、コントローラクラスのコンストラクタの引数に、使用したい Hub コンテキスト型の引数を設けておけば、それだけで、ASP.NET Core MVC がそのコントローラクラスをインスタンス化するときに、その Hub コンテキストをコンストラクタ引数に入れてくれるのだ。

あとはコンストラクタに引数として渡された Hub コンテキストを、コントローラ自身のプロパティにキャッシュしておいて、アクションメソッド内から利用すれば OK だ。

具体的には下記コードとなる。
public class BarController : Controller {

private IHubContext<FooHub> FooHubContext { get; }

public BarController(IHubContext<FooHub> fooHub) {
this.FooHubContext = fooHub;
}

public IActionResult Post(...){
// ここで this.FooHubContext.Clients.All.hoge(...) とかできる
}
}
SignalR の Hub コンテキストだけ特別扱いということなく、他の各種サービスインスタンスと同じように、DI の仕組みで参照が手に入るのは、すっきりしていて覚えやすい。

また、かつての ASP.NET SignalR における GlobalHost.ConnectionManager のような static プロパティ = 実質のグローバル変数を参照することがなくなったので、単体テストもより書きやすくなる。

Web API コントローラクラス"以外"からの SignalR 連携

さてところで、Web API のコントローラクラスではなく、もっとほかのトリガーをもとに SignalR のサーバー側からクライアント側へのプッシュ送信を行うにはどうしたらよいだろう?

例えば ASP.NET Core をセルフホスティングしたプロセス上で、GPIO ピンに対する入力を監視し、入力に変化があったら SignalR でクライアントに通知する、などの実装である。

先述のとおり、(ASP.NET Core じゃない) ASP.NET SignalR では、事実上のグローバル変数 = GlobalHost.ConnectionManager をどこからでも参照できてた。
それで上記例のような案件でも GlobalHost.ConnectionManager 経由でクライアントへのプッシュ送信が記述できた。

しかし ASP.NET Core の SignalR では、既に説明したとおり、GlobalHost.ConnectionManager のような実質のグローバル変数は、もう存在しない。

ではどうするか?


私が思いついたのは、ASP.NET Core の DI の仕組みで任意の Hub クラスのコンテキストが手に入るのだから、きっと ASP.NET Core の DI の仕組みに乗っかればいいはず、というアイディアだ。


ただ残念なことに、現時点の私の知識・技量では ASP.NET Core における DI の仕組みに疎い。
ASP.NET Core MVC がコントローラクラスのインスタンス生成をどうやってるか、同じことを自分のコードで真似するにはどうしたらよいか (先の例でいうと、GPIO の監視をつかさどるクラスを new するときに、どうやって依存性の注入を行うのか) がわかってないのだ。

それでも自分がわかっている範囲で、そこそこの解決策はある。

ASP.NET Core におけるエントリポイント、Startup クラスにおいて、アプリ起動時に呼び出される Configure() メソッドの引数に渡される IApplicationBuilder オブジェクトを参照すれば、DI の仕組みで注入可能なサービスインスタンスを入手可能である。

ということで、Startup クラスの Configure() メソッド内で下記のとおり実装すれば、任意の Hub コンテキストの参照を入手可能だ。
using Microsoft.AspNetCore.SignalR;
// FooHub という SignalR Hub クラスが定義済みだとして:
...

public void Configure(IApplicationBuilder app) {
...
var hubContext = app
.ApplicationServices
.GetService<IHubContext<FooHub>>();

こうして入手した Hub コンテキストを、目的のオブジェクトに何らかの手段で引き渡せば OK だ。
(先の例でいえば、この Configure メソッド内で GPIO 監視クラスを new し、そのコンストラクタに Hub コンテキストを引き渡す設計にする、などの実装が考えられる)

まとめ

ASP.NET Core 時代の SignalR では、"DI (Dependency Injection, 依存性注入)" の仕組みで、Hub コンテキストを入手可能だ。

特に ASP.NET Core MVC/Web API コントローラクラスであれば、そのコンストラクタに IHubContext<T> 型の引数を用意すれば、そのコントローラクラスがインスタンス化 (new) されるときに、このコンストラクタ引数に T 型の Hub のコンテキストが渡される。

ASP.NET Core の DI の仕組みに乗っかれない場合でも、最悪、Startup の Configure() メソッドのタイミングで、IApplicationBuilder オブジェクト経由で、任意の Hub コンテキストを入手可能だ。
 

by developer-adjust | 2017-10-30 22:29 | .NET | Comments(0)
2016年 04月 18日

ASP.NET SignalR を使った Web アプリに ngrok 経由でアクセスすると、サーバー側呼び出しが動作していない

ASP.NET SignalR を使ったリアルタイム Web サイト/アプリを開発中の話。

※ちなみに「SignalR」とは、「Node.js でいうところの Socket.io」に相当する、WebSocket などを活用した双方向リアルタイム通信を実現するための ASP.NET 用のライブラリ。

ngrok + SignalR が不調...

前回の投稿で取り上げた、ローカル開発 Web サーバーを "中継" して、インターネット上からアクセス可能にするサービス「ngrok」。

この ngrok、公式サイトの説明によれば「Websocket にも対応してるはずだよ」とのこと。

なので、SignalR を使った Web アプリ開発においても、その動作確認などの目的で ngrok を経由してインターネット上からアクセスするようにしても動作するだろうと予想された。

しかし残念ながらそうはいかず、期待どおりに動作しないケースがあった。

ブラウザ側の SiganlR クライアントコードから、サーバー側の Hub メソッドの呼び出しが、なぜかサーバー側に到達しないのだ。

サーバー側 C# コードが以下のように、常に文字列 "Boo" を返す Foo メソッドを持つ SignalR Hub 実装だったとして、
using Microsoft.AspNet.SignalR;
...
public class FooBarHub : Hub {
public string Foo() {
return "Bar";
}
}
ブラウザ側 JavaScript コードから以下のように上記 Hub の Foo メソッドを呼び出し、その戻り値を表示するとする。
let conn = $.hubConnection();
let hub = conn.createHubProxy("FooBarHub");
conn.start();
...
// 何かの DOM イベントのハンドラにて、下記を実行
hub.invoke('Foo')
.then(res => console.log(res);
これらコードを、ローカル開発環境で実行したり、Azure Web Apps に配置してインターネット上からアクセスするぶんには、当たり前ではあるが、ちゃんとブラウザの開発コンソールに (Foo メソッドの戻り値である)「Bar」と表示される。


ところが、である。


このローカル開発環境では普通に動作するこのコードが、ngrok コマンドを起動してのインターネット上からのアクセスで試すと、どういうわけか Foo メソッド呼び出し結果のコールバックが呼び出されないのだ。

Visual Studio にてサーバー側の Foo メソッドにブレークポイントを設定して待ち構えても、もちろんローカル開発環境ではちゃんとブレークするが、ngrok 経由ではまったくもってブレークしない。

サーバー側からの push 通知だけは動作

ちなみに、「conn.start()」メソッドの戻り値である jQuery の Promise オブジェクトについてコールバック関数を実装して様子を見てみると、ngrok 経由でもちゃんと接続成功のコールバックが発生している模様。

しかも、別の要因で発火させたサーバー側からの push 送信を購読していた場合、その push 送信ハンドラは、ngrok 経由の場合でも、正しく呼び出されるのだ。

ちょっと不思議な挙動である。

回避策

それはさておき、予想としては、ngrok の WebSocket 対応と、IIS Express や ASP.NET SignalR における実装との関連で、なにか相性問題のようなことが起きているのかもしれない。
※ちなみに、ローカル開発環境および ngrok 経由の各々で、トランスポート層は WebSocket が使用されていることを確認済み。


そこで回避策として、ブラウザ側にて SignalR のサーバー側への接続を開くにあたり、使用するプロトコルを自動で決めさせずに、もっとも古典的であろうロングポーリングで接続するよう明示的に指定するようにしてみた。

コードとしては以下のとおり。
SignalR 接続オブジェクトの start メソッドを呼び出す際に、トランスポート層をロングポーリングに限定指定した設定を渡すようにする。
let conn = $.hubConnection();
let hub = conn.createHubProxy("FooBarHub");
conn.start({
transport: 'longPolling'
}
);
こうすると、ngrok 経由でのインターネット上からのアクセスでも正常に動作するようになった。

ちなみに SignalR 接続オブジェクトの start メソッドにて、トランスポート層指定にどんな選択肢があるかについては以下が参考になる。

http://www.asp.net/signalr/overview/guide-to-the-api/hubs-api-guide-javascript-client#transport

補足

なお、この回避策は、あくまでも ngrok を利用してローカル開発中の Web アプリの動作確認が目的である。
よって上記のようにロングポーリングが指定されたコードがそのままリリースされてしまうのは "事故" であり、そのような事態は避けておきたい。

そこで自分のコードでは、現在のページの URL を見て、そのホスト名が ".ngrok.io" で終わっているかどうかを正規表現で判定して、もしそうである場合に限り、トランスポート層のロングポーリング限定指定を行う実装とした。
 
by developer-adjust | 2016-04-18 22:41 | .NET | Comments(0)
2014年 12月 08日

Raspberry Pi meets ASP.NET SignalR!

※本記事は、ASP.NET Advent Calendar 2014 への寄稿記事です。

Linux 上で動く .NET アプリ - Mono ランタイム

先日、Microsoft が .NET をオープンソース化する、及び、MacOS や Linux 上での動作をサポートする、ということが大きなニュースになっていた。

このニュースには大きな意味がある。

が、それはそれとして、もちろん、これまでも・今でも、Mono という .NET のオープンソース実装を使うことで、Linux や MacOS 上で .NET アプリを動かすことができる。

...ところで、Raspberry Pi。

と、ここでいきなり、Raspberry Pi の話。
Raspberry Pi はいわゆる「ボードコンピュータ」っていうやつ。
小さなむき出しの基板一枚に必要なチップやコネクタを搭載していつつ、Linux OS がしっかり動いてしまうという面白いハードウェアだ。
d0079457_21491037.png

さらに基板上には "GPIO" と呼ばれるデジタル入出力が可能なピンが用意されておりこのピンに電気装置をつないでやり取りできる。
LED(発光ダイオード)をチカチカ点滅させたり(いわゆる "Lチカ")、気温や湿度をセンサー経由で取得したり、アイディア次第で色々だ。

Raspberry Pi で C#製アプリを実行する

さて、先に書いたとおり、.NET アプリは Linux 上の Mono の上で実行できる。
なので、例えば C# や F# 等で書かれた .exe ファイルを、Linux が走っている Raspberry Pi 上で実行することも可能だ。

例えば Raspberry Pi に OS "Raspbian" をインストールし、インターネット接続環境を整えた状態で、この Raspberry Pi 上の Raspbian にて下記の3つのコマンド実行すると、.NET アプリを実行するための環境ができあがる。
# ローカルにキャッシュされているパッケージ情報の更新を、管理者権限で実行
sudo apt-get update
# インストール済みのパッケージの最新版への更新を、管理者権限で実行
sudo apt-get upgrade
# Mono 一式のインストールを、管理者権限で実行
sudo apt-get install mono-complete
そして、手元の x64 な Windows PC 上で Visual Studio で開発した .exe ファイルを、scp コマンド等で Raspberry Pi 上に送り込めば、ARM CPU である Raspberry Pi 上で実行できてしまう。

具体的には、mono コマンドの引数に、実行したい .exe ファイルのパスを指定すればよい。
mono myapp.exe
※話が逸れるが、C# のコマンドラインコンパイラ csc.exe は、.NET Framwork がインストール済みの Windows なら同梱されているため、メモ帳で C# のソースコード書いて csc.exe でコマンドライン上でコンパイルすれば、Visual Studio 無くたって、.NET アプリは作れる。メモ帳は言い過ぎだとしても、SublimeText などの軽量・高機能なテキストエディタとその拡張で簡易だが俊敏な開発環境を作ることも可能だ。

ということで、実際、Raspberry Pi 上で実行する C# 等による .NET アプリ用に、GPIO にアクセスするためのライブラリが公開されていたりする。

RaspberryPi.NET
https://github.com/cypherkey/RaspberryPi.Net/
WiringPi.Net
https://github.com/danriches/WiringPi.Net

...と、まぁ、ここまではよくある(?)話。

Internet 上で「Raspberry Pi C#」とかで検索するといろいろ事例が見つかる。

「Raspberry Pi + Mono で、C# から Lチカできたぜ!」というのがまずは初めの一歩なのだが、ここでさらに一歩踏み込んで、
「Raspberry Pi + Mono 上で ASP.NET SignalR 動かすぜ!」
ということをやってみた(やっと本題)。

OWIN Self Hosting と SignalR

実は最近の ASP.NET、OWIN と呼ばれる新しいWebスタックの仕様およびその実装によって、
「コンソールアプリなんだけど、ASP.NET が走っている HTTP サーバーです」
というプログラムを容易に作成できるようになった。

このような形態で ASP.NET アプリを提供する方式を、"Self Hosting" と呼ぶらしい。
アプリそれ自身(Self)が、ASP.ENT をホストするからだろう。

そしてもちろん、このオレオレ ASP.NET サーバーには、リアルタイム双方向通信ライブラリである SignalR も搭載することができる。

そうすると、ASP.NET + SignalR による Web アプリをホスト・提供しつつ、GPIO に読み書きを行うコンソールアプリが、Raspberry Pi 上で動作するのだ。

すなわち。

このアプリが提供している ASP.NET Web アプリに、ネットワーク越しに何かデバイスのブラウザでアクセスすることで、
  • そこに表示された UI をタップすると、Raspberry Pi の GPIO につながっているLEDを点灯・消灯したり、
  • 同じく GPIO につながったセンサーからの入力が刻一刻と準リアルタイムで UI 側に表示されたり、
という機能が実現できるのだ。







... 伝わっただろうか?

なんか、文章だと
ぜんぜん伝わんない
気がする。


なので、動画に撮りました!



上記デモンストレーションで使用した回路や、アプリのソースコードについては、GitHub 上で公開している。

Sample code of ASP.NET SignalR OWIN Self Hosting console app which can run on Raspberry Pi!
http://sample-by-jsakamoto.github.io/SignalR-on-RaspberryPi/

なお、SignalR を RaspberryPi + Mono 上で動かす例としてはほかにも面白いものがあって、例えば下記の動画など、LEGO(?) で大層なおもちゃを作って幼い息子さんに遊ばせてたりする。


ここまでの話を振り返って

ここまでの内容をおさらいしておこう。

1. インストールステップが簡単

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install mono-complete
のコマンドをいちど実行して Mono による .NET アプリの実行環境を整備しておけば、あとは自作した .exe ファイルと周辺の .dll ファイルを送り込むだけだ。

そしてこの.exe を実行すれば、Raspberry Pi 上の GPIO と相互作用する、SignalR で実現したリアルタイム Web アプリが提供される。
Apache だのなんだののインストールと設定が不要
なのだ。

2. インターネット接続不要

そして面白いことに、この技法は、インターネット接続を必要としない。

インターネットにつながっていない閉鎖網のLAN内であっても、Raspberry Pi が Web アプリサーバーなので、この LAN に Raspberry Pi につながればよいのだ。

同じ IoT でも、Internet Of Thing ではなく、Intranet Of Thing である。

3. マルチデバイス

さらに、Web標準の技術なので、ブラウザが動作すれば、デバイスを問わない。
もちろん、ネイティブアプリのような使い勝手はないかもしれない。
しかし代わりに、各デバイスネイティブなアプリを作ったり配布したりする手間なく、各種PC上のブラウザはもちろん、iOS や、Android などでもアクセスできる。

まとめ

ということで、C# + ASP.NET - OWIN Self Hosting + SignalR - の知識・技量があれば、あともう一息、Raspberry Pi の GPIO 操作を習得することで、このような形で外界と相互作用しつつ、マルチデバイスで動作する、クラウド不要なネットワークアプリを作ることができる。

繰り返しになるが、面倒な環境設定も要らない。

C# + ASP.NET のスキルだけであっても、アイディア次第でさらに広い世界に応用できるのではないか、そう期待が膨らむ次第である。

Enjoy your Raspberry Pi and ASP.NET life!
 
by developer-adjust | 2014-12-08 23:37 | .NET | Comments(0)
2013年 09月 17日

ASP.NET SignalR によるクイズWebアプリ「みんなで同時プレイするWebアプリでCodeQuizに挑戦!」

先日 9/14(土) に開催されたオープンソースカンファレンス 2013 Hokkaido、自分は CLR/H 枠で発表させていただいた。

発表内容は、この夏開催されたプログラマ向け宿泊イベント「Code 2013 in 定山渓」の催物のひとつ、「コードクイズ大会」で使用した、司会者の進行のもとで大勢で同時参加するクイズWebアプリの実装の紹介。

その中でも、司会者による操作が即時に回答参加者のブラウザに伝播・反映されるという "リアルタイムWeb" 部分を支えるオープンソースライブラリ
ASP.NET SingalR
https://github.com/SignalR/SignalR
に焦点を当てた内容とした。


以下はその記録。

スライド & プレイ中の動画

発表に使用したスライドはこちら。
http://www.slideshare.net/jsakamoto/osc13-do

実際にプレイしている様子の動画はこちら。


司会者の操作が即時に回答者のブラウザに伝わって画面が切り替わったり、回答者が回答を選んだらダッシュボードに即時に反映されたり、
"リアルタイム" な様子
がわかるだろか。

セッション中の Twitter の様子は、早速に @KatsuYuzu さんに Togetter にまとめて頂いた。

CLR/H #clrh84 in オープンソースカンファレンス2013 Hokkaido #osc13do
http://togetter.com/li/563894

ソースはオープンソースで公開。
サイト立てるだけなら Visual Studio も Windows OS も不要

このクイズWebアプリのソースコード一式は GitHub に GPL v2 で公開中。

https://github.com/jsakamoto/quiz-webapp

これを git clone して、お好みの ASP.NET 用 PaaS ( Windows Azure Websites や AppHarbor ) に git push し、SQL Server データベースも同じく PaaS 上で調達して、データベース接続のための設定まで行えば、「オレオレクイズサイト」があっというまにできあがる。

こうして「オレオレクイズサイト」を立ち上げるだけなら、
Visual Studio はおろか、Windows OS だって不要
だ。
PaaS のアカウントを持っていて、git が使える OS があれば MacOS でも Linux でもかまわない。
さらに PaaS の GitHub 連携使えば git さえ要らない。
Webブラウザだけで「オレオレクイズサイト」を構築できてしまう。

おまけにこの程度のアプリなら、各種 PaaS に用意されている「無償プラン」内で済んでしまう。
フリーミアム戦略とはいえ、凄い時代になったものだ。

ちなみに ASP.NET 用の PaaS としては、Windows Azure Websites もキビキビ動いてかなりお勧めだが、たとえ請求は発生しなくても、アカウントの開設にあたりクレジットカードが必要。

これとは別の PaaS、「AppHarbor」は、無償枠だと Windows Azure Websites 程の機敏さがないものの、メールアドレスだけあれば 2分でアカウント開設できてしまうのが魅力だ。




まとめ

今日び、"双方向" "リアルタイム" な Web は珍しいものではないと思う。
facebook に搭載されているチャットメッセージなどもそうだ。

しかしそういったアプリを開発する側となると、SignalR のようなライブラリの支援がないと相当大変である。
ましてや "底辺にあわせて Long Polling で" と実装を割り切るならまだしも、SignalR のように実行環境に応じて Web sokect まで駆使するように自作するのは、もう現実的ではないだろう。

とにかく、SignalR のようなライブラリの出現によって、"双方向" で "リアルタイム" な Web アプリの実装の壁が格段に低くなったことは確かだ。

あとはこういった恵まれた環境の上で、どんなアイディアを浮かべるか次第である。

そして付け加えるならば、こうして構築したアプリを 0円スタートでインターネットに公開するサービスが存在することだ。

アイディア次第、アイディアを形にし、世界に公開できる敷居がどんどん下がり続けている時代。

今回のオープンソースカンファレンスでの発表を通して、SignalR というライブラリの存在を知っていただき、なにか素敵なアイディアを形にするのに役立てていただけたら、発表者冥利に尽きる。

"Learn, Practice, Share |> Fork, Commit, Pull Request."

by developer-adjust | 2013-09-17 20:24 | .NET | Comments(0)