2013年2月16日土曜日

デブサミ2013 覚書


デベロッパーズサミット2013に参加してきたので、会場で書いた走り書き。


「モバイルHTML5による世界への挑戦」
※ゲーム系は高速化技術の宝庫

世界の状況と日本の状況、そしてこれから

「インストールという行為が嫌いなんです」

・1995年ごろ
　Winows95の発売。(インターネットへのアクセスする機能がOSに組み込まれていたことが衝撃だった)
　NTTのテレホーダイとか。

　開発環境 VisualStudio4 -> VisualStudio6

・1996年ごろ
　インターネットを使ったサービス、ICQがサービスイン。また、国内では東風荘(ネットワーク麻雀)など。
　回線はISDN。

・2001年ごろ
　ADSL登場。ブラウザ開発ラッシュに突入。
　Java,PHPなどインターネット系(サーバ側)の言語が登場。
　ADSLの登場に伴い、常時接続が主流になってくる。

・2004年ごろ
　AJAXアプリの台頭(Gmail,Google Map,youtubeなど)。
　常時接続の回線品質向上。

　(AJAXの台頭を踏まえて)Javascriptへ注目が集まる。
　　・prototype.js、GWT(Google Web Toolkit)、jQuery

・2008年
　iPhone,AppStore、Androidもストア(現GooglePlay)スタート

　↓

・2010年
　HTML5 対応

ここまでが、「これまでのお話」。

ここからが、「現在のお話」。

　FlashPlayerという存在について
　　-> SteveJobs曰く「HTML5があればFlashは不要になる」
　　　他にも、標準化された技術ではない、プラットフォームを脅かす存在になりえるなどの懸念があった。

　しかし、海外では主流ではないFlashだが、日本のコンテンツの多くはFlashLiteベースだった。
　　-> いわゆる各種キャリアのガラケーの多くが対応していたため

　問題となったのは、スマートフォンがシェアをとり始めてから。
　前述のとおりSteveJobsの意向のもと、iPhone系はFlashに対応せず、AndroidOSもFlashには対応しないスタンスをとった。

　そこでExGameというアプリを作った。
　　-> FlashLiteがスマートフォンで動くようになるアプリ。このアプリが評価され、発表者はDeNAへ入社することになる。

　HTML5は順調かと思われたが、昨年に衝撃的な事件が...
　　-> Facebookによる「脱HTML5」宣言。サッカーバーグ「HTML5に賭けすぎたことは、大きな失敗だ」。
　　　 速度、音楽、3Dなどの面で問題が残っている。
　　　 互換性にも問題が...

　互換性といえば、Android端末における互換性は絶望的である、という話題。
　　CSS3は使い物にならないし、Canvas系にも問題が多数発生する。
　　　-> IE6に対応するほうがまだマシに思える、とのこと。

　市場は非常に大きくなっている。特にソーシャル系。


ここまでが、「現在のお話」。

ここからが、「これからのお話」。
　あくまでも「個人的予想ですが」という前置き。

　モバイルWebにおけるリッチアプリは、「2001年から2004年へ」というくらいに変化するだろう。
　「アプリと変わらないUIをもつWebアプリ」が登場するのもそう遠くない。

　...とは言え、どれだけがんばってもWebアプリである以上、インストールアプリには(描画などの)速度面では勝てない。


　それではなぜWebアプリが普及するのか？
　　-> インストールが不要あること、(ユーザから見た)端末間のデータ移動が非常に楽であること、などがあげられる。

　アプリと同じことをしようとするのではなく、Webでしかできないことを実現していくべきだ。


・いろいろと言ったけど本当に言いたいこと
　・モバイル端末におけるWebアプリはアメリカよりも日本のほうがわずかに先んじていると思う
　・想像力を駆使して未来を作る
　・次世代Webアプリを世界に普及していきたい



「OSSで作るクラウドサービス開発戦記 -Cloudn PaaSの挑戦-」

※Cloud-n(クラウド・エヌ)が、省略されてCloudnとなり読みも(クラウドン)となったらしい。
　で、クラウドン -> クラうどん じゃね？ ということで会場ではうどん(赤いきつね)が配られた。

OSSでPaaSを作った際の試行錯誤とその効果について

PaaSとは
　-> PlatForms as a Service。アプリケーションの実行環境を整備したサービス。

Cloudnは、VMWareが推めているCloudFoundryを使用している。

その１ PaaSをはじめる
　・CloudFoundryの構築をしてみる
　　　-> クラウドサービスのくせに複数ホストで動かすには手動で設定を変えなければならないなど癖が強かった
　　　　 デプロイツールを導入し、解決を図る(ほぼ解決した)。
　・チームの立ち上げ
　　　-> 開発スタイルとして、アジャイルやScrumを導入。
　　　　 アナログタスクボードを導入したり、フリーアドレス(デスクトップPC廃止)制にしたり。
　　　　 ・アナログボードの導入：全員のタスクを付箋にして１箇所のボードで集中管理することでタスクの可視化を行う
　　　　 ・フリーアドレス：メンバー同士でペアレビューを行ったりする際に動的に席を変えられるようにした。さらにペアプログラミングようには別途ディスプレイも導入。
　　　　 他に使ったツール
　　　　　・Redmaine、Jenkins、IRC、Github

　・クローズβ版作成


その２ 開発と導入サポート
　・upstreamの追随。OSSであるCloudFoundryは、自分たちが何もしなくても自動的にソースコードが更新されていく。
　　-> 定期的にPaaSのコードを最新化する必要がある。
　　　【トラブル】
　　　あるとき、ソースを取り込んだらmysqlのインスタンスが作成後しばらくして消える、というバグが発生するようになった。
　　　mysqlの常駐プロセス(数時間毎に起動する)にバグがあった。
　　　【対策】
　　　・Staging環境でしばらく様子を見ること
　　　・ちゃんとソースコードを読むこと
　　　・問題が起きたら、テストを追加して、同じ問題に２度当たらないようにすること(回帰テストの自動化)

　・顧客へのPaaS導入サポート
　　そのままではPaaSでは動かない...こともある
　　・Platformで対策する(=OSSとして対策する)？アプリ側で対策する？

　・開発がわかってくる
　　・CoreCompatibleでありつつ、顧客の個別の要望にも応えられること。
　　・OSS化はやる気次第でできる

　　問題点もでてくる
　　　・テストが遅い(項目が増えた)。 -> シングルのjenkinsを使っていたが、Slave化してテストを並列実行させるようにした。
　　　・属人化してきた -> 必ず二人で行う時間を設ける。コードレビューの強化。
　　　・マンネリ化してきた -> 振り返りに刺激を。

その３ (プロジェクトの進め方を)組織に広げます
　・やっていること
　　・隣のプロジェクトに火をつける×
　　・隣のプロジェクトと連携する
　　・隣の人に火をつける

　・あまりうまくいっていない
　　-> 前提条件が違い、今のプロジェクトと同じようには行かない

※OSSを使ったサービスを構築しているだけあって、プロジェクト管理周りのツールもOSS系のものが中心。


「増加するセキュリティ脆弱性の解決策」

※静的コード解析ツールだが、データの入口と出口を押さえることで危険なデータが入力された際の挙動をシミュレートできるツールの紹介。
　おそらくJAVA専用。

典型的なテストとは？
　-> 仕様通りに動くことを確認する。

これまでは脆弱性に対し、コードの品質向上という考え方で攻めてきた
　-> 静的解析ツールによるソリューション
　-> 約6割ほどの脆弱性は防ぐことができていた

また、実装においては
・JAVAセキュアコーディングガイド
・C言語全般セキュアコーディングガイド
・Andoridセキュアコーディングガイド
・PCI,DSSなど

まだまだ足りない！
　-> 「脆弱性への対応」とは、普通顧客の要求に含まれないし、漠然としすぎていて具体的なテスト項目も挙げられない。

Webアプリでは、セキュリティ問題に対してコストがかけられている。
具体的な問題は...
　・デフォルトアカウントのパスワード設定ミス
　・運用環境のコンフィギュレーションミス
　・SQLインジェクション

　　-> 実装というよりも、データに問題がある場合が多い。
　　　 だが、静的解析ツールではデータの中身までは調べることができない。

開発プロジェクト自体にもセキュリティ対処を遅らせる問題が存在する。
　・セキュリティ不具合のテストは開発の後工程で行われることが多い。
　　たいてい後工程では時間が少なく、省略されたり、対応がとれなかったりする。

開発プロジェクト中に継続的セキュリティテストを！
　-> 製品のアピール

　・悪意あるデータの入り口を特定する。
　・悪意あるデータがコード内でチェックされているか？を確認する。
　・脆弱性の解決策を提示する。


・セキュリティに関するインシデントがあるか？
・セキュアコーディングガイドがあるか？
・ペネトレーションテストが実施されているか？
・発見された発見された脆弱性を修正する情報があるか？


「Kinectから始まったスタートアップ」

・OUTPUT！

・(Kincetを含めた)Depthセンサーの動向
 センサーの得意・不得意を知る
 Kinectについて 商用利用可能
　事例 アミューズメント(ゆうえんち)
　　　 原宿の仮想試着
       空中ディスプレイ(これか？ http://www.itmedia.co.jp/news/articles/1301/10/news110.html)
　　　 現実空間とのインタラクション -> プロジェクションマッピングとの併用

 ・注目のセンサー
　Kinect そろそろSDKがupdateされると思われる
  PrimeSense社のセンサー Kinectのセンサーと同じものを使用している。OpenNIというOSSで作られたSDKで動作する(ライセンスはフリー)。Version2になり、使いやすくなった。
  SoftKinectic社のセンサー Kinectほど遠距離に対応していないものの、近距離では精度が高く、手の指まできれいに認識できる。
  Intel社のセンサー 現時点ではまだ発売されていない。モノとしてはSoftKinectic社のものと同じもの。SDKはIntel製になる見込み。

今年の目玉。
　PrimeSense Cpari -> モーションセンサーとしては非常に小さい(板ガム程度)。ノートPCへの組み込みなど用途が広がる。

センサー系のメリットとデメリット
　メリット
　　・触らないで操作できる。
　　・触れるものに触らないでよくなる。
　　・触れないものに触れるようになる。

　デメリット
　　・垂直UI(手を突き出す)は疲れる。

　今後、いろいろとセンサーが増えてくるが
　基本的には認識距離で住み分けていくと良いだろう。


・OUTPUTとINPUTの好サイクルを！
投稿者 時刻:
ラベル: , , , , ,

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)