こうやって何でもかんでも日本語の文章に起こしていると、
翻訳センスというか、意訳センスみたいなのが身につきつつある今日このごろ・・・。
(※それでもなお、翻訳技術を学ぶ気がないという・・・）
さて、久々にWeb技術関連のニュースまとめです。
国内最大規模のWeb技術者コミュニティ「html5j」がビギナー部、TVアプリ部を発足
ビギナー部はもう早速、今週末開催のイベントhtmldayで勉強会を開くようです。素晴らしい！私もビギナーにHTML5を教えるという機会が結構多かったりするのですが、「HTML5とは何か」を完璧と自信を持って説明できたことがありません！
ある時はアプリケーションプラットフォームの仕様だったり、ある時はデータベースのデータフォーマットの仕様だったり、聞いたこともないWGや標準がそこら辺に大量に転がってて、重箱の隅をつつかれようものならあっけなく崩れ落ちかねないわけで・・・。そうなるともう、聞く側の関心に合わせて説明するしか無いんですよね。今後協力していこうと思っています。頑張って欲しいです！
TVアプリ部も、、、うーん、仕事柄、様子を見ておかないといけない！！ただ、放送という分野は、第三者によるコンテンツ加工を嫌う分野と聞いていますので、職業として関わらないエンジニアにとっては、遠い存在に感じられるかもですね。ただ、放送と通信の融合は避けられないわけで、何かしらの想いがあるはず・・・と、
タイムリーなネタとしてこんなものものが↓
TVサービスにアクセスするためのHTML5プロファイルが公開
http://www.realwire.com/releases/Open-IPTV-Forum-publishes-HTML5-profile-for-Connected-TVs
2013年6月4日、Open IPTVフォーラムにて、TVにアクセスするためのHTML5プロファイルが公開されたという記事が。内容を少し意訳。
==
Open IPTV Forum(OIPF)は、HTML5、CSS、DOM3、またそれに関連したWeb技術のプロファイルを公開した。このプロファイルは、TVサービスやデバイスにアクセスするためのもので、ブラウザベースアプリケーション環境を想定している。OIPSは、共通のプロファイルと、W3Cにより定義された安定版であるWeb技術について説明した。それらは、接続先となるTVメーカーによってインプリメントされると予想され、アプリケーション開発者、コンテンツ＆サービスプロバイダがHTML5によるリッチなアプリケーションを開発するために活用される。
このプロファイルは、基本的にはW3Cにより参照されるあらゆる拡張や修正を含めず、安定度が高いと判断できるものだけが部分的に集められ、定義として含まれる。またその選定は、エンターテイメントサービスとTV間の相互接続性のサポートという、明確なターゲットを持つ。
==
なるほど、、私の訳がミスってるかもですが、エンターテイメントサービスの区分けがどうなっているかが気になりますね。ネット上でエンターテイメントコンテンツを発信している企業がターゲットということでしょうか？いや、著作権関連技術が解決されていないので、インターネット経由とも思えないし、もっとクローズドな環境下のものでしょう。
ちなみに標準ドキュメントはW3Cでなく、OIPF独自ドメイン下に置かれています。
他の標準とは若干、毛色が違う感じですね。
WebSocketが動作可能なAPミドルウェアの比較
http://www.atmarkit.co.jp/ait/articles/1306/04/news021.html
さっき投稿した記事と若干内容がかぶってますが、観点が違ってて面白いですね。記者はNTTソフトウェアの高橋さんか、、うーん、どこかで会ったことある？
Javaという区分けでなく、WebSocket対応APミドルという区分けで比較しています。Tomcat、、やはりWebSocketに対応していたのか！先ほどの記事にJettyはJava EE 7に従っていないと書いたのですが、それはもう古いネタのようです。最新版であるJetty 9はJava EE 7、準拠済みのようです！
あと、Java側でのWebSocketAPI標準を「JSR356」という名称で呼ぶみたいで、Java EE 7対応という呼び方はダサい感じがしますので、これからはやめようと思います！！しかし、365とかにしてくれたらいいのに、356って、ゴロ合わせもしにくいしどうやって覚えれば！！
常時接続で問題になるのは、スレッドの問題だと思ってて、APについては割りとこの問題が解決しているようですね。TomcatはmaxThreadsより多い接続が受け付けられるよう、データのやりとりが無い時はスレッドを離してくれるみたいです。まぁ、ロードバランサーやらApacheのmaxThreadsはどうするよ？？って問題は消えないわけですが。
ヒープメモリのバッファ問題については、APミドルだと結構定番なのかな？っと思ったりもしました。メモリリークという訳ではないですが、私の今までの経験だと、APミドルのメモリがガツガツ食う時って、大抵このあたりから問題が出てくるんですよね。8Kbyteというバッファのサイズで思い出すのが、OSS系ブラウザ側のエンジンが読み込むデータサイズが確か8Kbyteだったような気がするので、通信パフォーマンスと処理タイミングの最適化とか云々で考えると、ここが妥当と判断されたのかなぁ？？と妄想します。EathernetとかIPパケットサイズとかはなんか全然関係なさそうな大きさだし、CPUのL2データキャッシュのブロックサイズも超小さいし、うーん、何に合わせたのだろう。サイズを変えるのもいいのでしょうが、何故8Kbyteがデフォルト値になっているのか、そこに理由がありそうな気がします。些細な事かな！？！？って、最後のページでもろにその影響が出てますね。内部のどういった動きと相関性があるのかが気になります。
高橋さん、素晴らしい記事でした！ありがとうございます。
PhoneGap 2.7がリリースされたようです
Mozillaのスマートフォンは、新興市場向け
http://online.wsj.com/article/SB10001424127887323469804578522970435729366.html
以前から、Mozillaのスマホのコストメリットについては騒がれてましたね。HTML5で動かす分、性能を落として安価にしたとかどうとか。安いからあまり機能を必要としない人とか、新興国市場に受け入れられるとかどうとか。
で、この記事にもそれっぽいことが書かれていました。
"Our Web-based mobile software is lighter and consumes less power and memory compared to Google's Android and Apple's iOS. It offers the same performance at a lower cost of hardware,"（我々のWebベースなモバイルソフトウェアは、GoogleのAndroidやAppleのiOSよりも、軽量で電気消費も小さくメモリも小さい。だから、安いハードでも同じパフォーマンスを発揮できるッ！！）
で、
"Another advantage is that Mozilla is a truly open mobile ecosystem. Our Web-based applications can run on any mobile devices, including iPhones and Android phones."（他に強みがあるとすれば、間違いなくオープンなエコシステム。我々のWebベースなアプリケーションは、どんなスマートデバイスでも動く！！！当然ッ、iPhone、Androidもだッ！！！！）
っと。
整理すると
・他のスマホよりもローコストという強み
・アプリケーションの動作プラットフォームが広いという強み
これを武器に、「成長のポテンシャルを秘めた、ローコストセグメントを攻める！」っと。
なるほど。・・はいはい、うん。決めた！
流行るかどうか確かめるために、端末見るぞ！！
来週からはじまるInterrop見に行けるよう、
課長に全力土下座する練習をしておかねばいかん。
振興国では、スマホでなく電子書籍ハードがコンピュータの代わりとして広がっているとか聞いたことがありますので、そっちもライバルになるのかな？
Content Security Policy1.1がドラフト化
http://www.w3.org/TR/2013/WD-CSP11-20130604/
WebアプリケーションセキュリティWGにより、Content Security Policy1.1がドラフト化されました。HTML5により問題視されたセキュリティ問題も一歩前進なのでしょうか？イタチごっこな分野なので、継続的に続きそうな取り組みで、ずっとウォッチしないといけないとですね。
↓このWGの活動概要については、ここに書いていました。
http://www.w3.org/Security/
少し意訳してみると・・・
==
我々の主たる活動領域は、HTML5などのモダンなWebアプリケーションへのセキュリティ要求です。WebアプリケーションセキュリティWGでは、コンテンツセキュリティポリシの標準化やクロスオリジンリソースシェアリングの標準化や勧告を行なっています。そして最終的な目標は、セキュアなマッシュアップの実現、HTML5のビルドインポリシと整合しかつ堅牢なWebセキュリティ環境を簡単なポリシー記述で行えることです。あと、クリック・ジャッキング問題もみてますよー。
==
・・・っと、なるほど。
なんとなく聞いたことはあったのですが、改めて読むと面白い。
我々開発者に結構インパクトある仕事してますもんね。
「 URLs in Data Primer」がワーキングドラフト化
http://www.w3.org/TR/2013/WD-urls-in-data-20130604/
アプリケーション中に埋め込まれたURLが、そのコンテンツの情報を（恐らくクリックとかしない状態で）ユーザ側に開示したい場合に、一体どんな情報を見せれば良いのか指定するための標準っぽいです。ほほう、そんなところまで標準化しようと言うのか！！
「HTML5.1」がアップデート。
http://www.w3.org/News/2013.html#entry-9853
- ワーキングドラフトであるHTML Canvas 2D Context, Level2がアップデート
- main要素を標準化
他、色々。
