細かい属性などについてはこちらをご確認下さい。

以下のように各端末で読み込まれる動画を上から並べていきます。

<video id="video" width="300" height="200" controls="controls" onclick="this.play()" preload="metadata">         
<source src="test.webm" type="video/webm">     
<!-- OGG/WebM 陣営向けの動画 -->         
<source src="test.ogv" type="video/ogg" media="all">         
<!-- MPEG-4 陣営向けの動画 -->         
<source src="test.mp4" type="video/mp4" media="all">      
</video>

以下の指定で動画が再生されるはずが、落とし穴が二つ！
まず、GALAXYS で再生が出来ない！
GALAXYSは＜video＞タグを設置するだけでは再生できないようです。

Javascriptで以下を指定し再生する必要があります。

// JavaScript Document
$(function(){
	var video = document.getElementById('video');
	video.addEventListener('click',function(){
		  video.play();
	},false);
});

その2！
まさかのandroid 4.0 以降はストリーミング再生が不安定。

android 2.0.× ～ 2.3.× などのバージョンは端末の動画プレイヤーを立ち上げるので
読み込む時間が多少掛りますがみる事が出来ます。

android 4.0 以上はストリーミング再生で重い動画だと
音声だけが再生されたり、固まったり不安定です。
 

1MB以下の短い15秒位の動画でやっと再生出来ました。
再生したいのは約1.5MBの1分程の動画です。

検証端末は
・GALAXYS android 2.3.6
・GALAXYS3 android 4.0
・iPhone4S、5
・他android端末
です。

まだまだ動画系はvideo タグでOK！というわけにはいかないようです・・・。

もしかしたらjsの制御で改善出来るかもしれませんが調べた限りでは無さそうでした。

android 4.0 も端末の動画プレイヤーで再生出来れば
まだストレスを感じずに再生出来るのではないかと思います。

なんとかならないかな― android

Share on Tumblr

Tweet

既知の情報だと思いますが、念のため。
RedisはインメモリベースのKVSです。
KVSはRDB(リレーショナルデータベース)のJOINのように複雑、且つ高負荷なSQLは発行せず、高速化／拡張性に趣をおいたNoSQLのデータベース管理システムとなります。
いわゆる分散型データ保管技術の1つです。
同様のデータベースにはGoogle検索で採用されているBigtable(ビッグテーブル)、Amazonで採用されているDynamo(ダイナモ)、有名どころだとmemcachedなど様々な種類があります。
また、RDBのような複雑なシステムではないため、サービス(mixi、Amazonなど)や大学の研究で独自のKVSが開発／採用されているケースも多々あります。

そんなKVSですが、KVSごとの特徴は？ということで、今回選定したRedisの特徴をいくつか記載します。
1. 永続化機構
通常メモリ上でデータを管理しているため、memcachedのように障害時、再起動時にはデータを喪失してしまいますが、Redisは定期的にデータのスナップショットをダンプファイルにし、再起動時にこのファイルをメモリに読み込むことでデータを復元する仕組みを備えています。
定期的という事で不安を抱く方も多いと思いますが、”Append Only File”という仕組みを利用することで全ての更新コマンドを管理しておき、再起動時にこのコマンドを読み込むという方法もあります。これであればデータの喪失は最小限に食い止めれます。
注意すべきなのは、永続化機構といってもあくまでもインメモリベースのため、最大容量はRAMに依存します。
RAM容量より多くのデータを保存したい場合はスワップファイルを利用し、一部のデータをHDDに退避させる必要があります。(RedisVM)

2. 豊富なデータ型とコマンド
Redisはハッシュ(HASH)以外の型もサポートしており、リスト型(LIST)、集合型(SET)、順序付き集合型(SORTED SET)などのデータ構造が扱えます。
また、コマンドが非常に豊富、且つアトミックに操作が可能なため、CAS操作などトランザクションを考慮した処理が不要です。
ただし注意すべき点として、アトミック実行(MULTI／EXEC)は一般的なトランザクションとして実行されている訳ではないため、実行中にエラーが発生した場合にROOLLBACKはされません。残りの処理も実行されます…ここは要注意です！
(値を設定＆取得くらいのアトミック操作であれば”GETSET”という1つのコマンドで対応可能)
KVSの利用用途としてはデータの整合性よりもスピード重視の利用用途が多いと思いますので、トランザクションを考慮する機会は少ないと思いますが、アトミックに操作が可能な事でデータ管理方法の幅が広がります。

3. レプリケーション
Redisはマスター／スレーブのレプリケーションが設定ができ、スケールアウトが非常に容易です。
設定は簡単で、スレーブ側の設定ファイルに以下項目を追加するだけです。

設定できているか否かの確認はinfoコマンドを実行するか、実際に値を設定して確認します。
infoコマンドの場合、実行後に「role」を確認してください。

役割がマスターになっていますね。次にスレーブに接続します。

役割がスレーブになっていますね。無事設定できているようです。

最後に、実際にレプリケーションできているかを確認するため、マスターにデータを登録し、その後スレーブでデータを取得してみます。

問題なさそうです。

4. Publish/Subscribe型(Pub/Sub型)の通信をサポート
今回DBにRedisを採用したのはこの「Pub/Sub型通信」をRedisがサポートしているためです。
送信側と受信側がトピックを介して”多対多”で通信できるモデルのため、Redisを中継サーバとしてWebSocketサーバを冗長化する事ができます。
Node.jsについて説明できていないため順番が前後しますが、Nodeを利用してPub/Sub通信の動きを確認してみます。

nodeのコンソールを起動し、以下スクリプトを実行します。

6379番ポートのredisの「I am subscriber」というトピックに対して配信を申し込み(subscribe)、配信があればコンソール上に受信内容を出力するようにします。
その後、6379番ポートのredisの「I am subscriber」というトピックに対して”I am publisher”というメッセージを配信します。

上記スクリプトを実行すると、以下メッセージが表示されます。

Pub/Sub通信のイメージ湧きましたでしょうか？
分かり辛いですね…なんというか…自作自演ってな感じですね。

という事で、上記コンソールはそのままにしておき、別コンソールを起動して以下コマンドを実行してみます。

するとnodeコンソール上に先ほどと同様に以下メッセージが表示されます。

これこそがPub/Sub型の配信モデルです。
node側ではトピック「I am subscriber」を購読(subscribe)状態のため、
別イベントで「I am subscriber」にメッセージが登録されたと同時にメッセージをお知らせしてもらっています。

今回は受信／購読者(Subscriber)、発行／公表者(Publisher)共に単一で確認しましたが、前述したように多対多の通信モデルのため、複数のSubscriber、またはPublisherでも上記通信が可能となります。
WebSocketサーバーを冗長化した際に各々のサーバーでsubscribeしておき、連携したいデータをpublishすればサーバー間連系はこの中継サーバーに委ねられます。
単一であればWebSocketでブロードキャストすればいいだけですが、冗長化を考えるとPub/Sub型を利用できるredisは非常に便利です。
エンドポイントはWebSocketで管理しているため、サーバー間はPub/Sub型じゃなくてTriggerでもいいんじゃない？という方も居ると思いますが、サービス独自の特殊な通信制御が必要でない限りはPub/Sub型通信モデルの方が便利だと思います。

Redisの準備は一旦ここまでとし、次はNodeの準備を進めます。
少し長くなってしまったため、Nodeと各種ライブラリ(Socket.IOやExpressなど)のインストールについては
次回ブログで投稿させていただきます。

Share on Tumblr

Tweet

そんな中、先日、ちょっと「おやっ？」と思う蛇口に出会いました。
皆さんは蛇口は「ひねる（まわす）もの」という感覚が強いですよね？
もちろん他にも上下に上げ下げするものや、自動で出るものなどもありますが、多くの人が蛇口と言えば「ひねる（まわす）」と思うのではないでしょうか。
ではそんな決め付けの文章を書いた後ですが、皆さんはこんな水道を見たらどうしますか？
自分だったら上にあげます。
こんな水道だったらどうでしょう？もう「ひねる（まわす）」と思う人は少ないと思います。
では、この白い部分が蛇口の両サイドに付いていたらどうでしょうか？
（今、写真を撮ってこなかったを猛烈に後悔しています）
いかにも「上にあげる」と思われる形のものが蛇口の両サイドにある場合、人は慣習的に「ひねる」のか「あげる」のか？

ちなみにその蛇口は「ひねる」のが正解でした。
何度かその洗面台を使ったのですが、自分は無意識に「あげる」操作をしようとしていて少しイラついたのを覚えています。

蛇口だとそれほど違和感のあるものへの遭遇機会は少ないと思いますが、ドアの取っ手（ドアノブ）などであれば遭遇機会はそこそこあるのではないかと思います。
「まわす」のか「下におろす」のか、「押す」のか「引く」のか「横にスライドさせる」のかなどなど。
横へスライドして開けるドアにまるいドアノブが付いている所を想像してもらえればかなりの違和感を想像できるのではないでしょうか。
上の蛇口については全然伝わらなかったと思いますが、このドアの例と同じくらいの違和感でした。

実生活での体感も、画面の中での体感もそれほど大きくは変わらないはずですので、ユーザに不便や違和感や気持ち悪さを感じさせないものづくりをして行けたらなと思いました。

Share on Tumblr

Tweet