Enterprise × HTML5 Web Application Conference 2014に行ってきた

2月28日は、会社に許可をもらって、終日Enterprise × HTML5 Web Application Conference 2014明星大学 日野キャンパス)に参加してきました。

明星大学は初めて来たのですが、のどかで落ち着く所だなと思いました。気温も寒くなく、普段のように窮屈なスーツである必要もなかったので、リラックスして聴けました。

セッションの内容をレポートしてみたいと思います。例のごとく、ほとんどはスライドが公開されると思いますが…。

パネルディスカッション「HTML5エンタープライズITの向かう先」

開会宣言(エンタープライズにおけるHTML5 3つのニーズ)
パネルディスカッション(過去と現在を振り返る)

パネリスト3人(白石さん、春日井さん、川田さん)の発言が混ざっていて分かりにくいですが、ご了承ください。

HTML5はなぜウケたか

  • canvas, videoなどによる表現力
  • WebSocketなどのAPIが充実してきた
  • Webは心理的に受け入れやすい(⇔Adobe)。Web画面をリッチにしたいというニーズに標準が追いついた

現状

  • 東証一部上場している約2,000社のうち、HTML5マークアップされているサイトは約9.4%
  • 同、スマートフォン対応(レスポンシブ、専用サイト)しているのは14.9%
  • 普及しているのが少ない理由
    • 費用対効果が見えにくい?
    • 技術的なハードルが高い?

これからどう変わっていくか(設計・開発・運用)

  • HTML5はオープン系の技術。ベンダ系からオープン系へのシフト
    • ベンダ系とオープン系での「ツール」に対するアプローチの違い
      • ベンダ系ツールでは細かいカスタマイズがしにくい(画面上での繰り返しや条件分岐など)
      • ベンダ系の場合、全部ベンダのせいにすることができる
      • オープン系の場合、責任はすべて自分(全部Red Hatのせいだ、とも言えたりするが…)
      • W3Cに加盟して意見を言う、なども必要
      • オープンな技術を使っているのにツールがベンダのものに囚われている感覚への抵抗
      • オープン系かベンダ系かは宗教論争みたいな側面もある
    • Web Component(コンポーネントUIの技術)ができつつある
    • Microsoftでは、HTML5 Labsがある。どういう形でVisual Studioに取り組むかなどを検討している。
    • WebGL
      • Adobe Atmosphereなどがすでに10年前に存在し、ポシャった歴史
  • 運用
    • ブラウザのアップデートが早い(Chromeは6週間に1回、アップデートが一番遅いIEでも2年に1回)
      • サポートするかしないか、検証するかしないかのラインを決めないと追いつかない
      • セキュリティアップデートはよいが、機能改善がネック
      • Microsoftブラウザのサービスパックの仕組みが変わった。
        • XPまでは、ELの10年間はIE6のサポートを保証していた。
        • 8では、Service Packが上がると強制的にアップデートされる。
        • 一応ブロッカーツール、IEAK(Administration Kit)というのがあり、強制アップデートをブロックすることは可能。

質疑応答

  • Q1) HTML5が普及していないのは、メジャーなブラウザがIE8だからな気がする(IE8はHTML5非対応)。Webシステムの開発者として、サポートブラウザについてはどのようにアプローチしていけばよいか?
    • 関わっていたプロジェクトでは案件ごとにサポートするIEのバージョンがバラバラだった。
    • IE8以下はIE依存が強い
    • ドキュメントモードが有効であるがゆえに、かろうじて動いているサイトも多い
    • IE11はGood Jobなブラウザ
      • 過去のIEの互換を保ちつつも、今後を見据えた戦略的なバージョン
      • ドキュメントモードを非推奨とすることで、意図して部分的に動かないようにしている
    • 2020年 Windows7がEOLの時、確実にドキュメントモードはなくなっているだろう。
  • Q2) HTML5で基幹システムを作りたいが、ユーザ企業の中で日本で1番先進的な企業はどこか教えて欲しい?
    • 立場上オープンには言えない(Microsoftの春日井さん)

業務系Webアプリケーションに求められるUIとUX

  • UXの根本=体験
    • 会社、サービスがもたらすエンドユーザのあらゆる部分を包含するインタラクション(Webアプリケーションならば、ブラウザを開いてから閉じるまで全てが対象)
  • UXにおける中心の概念は「価値」
  • 真のニーズを拾うことが重要
  • 本格的に取り組むのは難しい
    • 意識から変えていく
      • 常になにか一つ改善しようという意識
    • 一人ではできない。そこから文化にしていく
  • (公共系を除き)実現性+金額だけでは競争に勝てない
  • お客のことを考えた根拠のある「思い込み」
  • 「技術的な仕様です」ではなく、そこから解決策・妥協案を示す
  • 仕様通り動けばよいというわけではない。どのような操作が行われるか(利用シーン)を考慮する
  • プロセス(※ 例として出したのはペルソナ・シナリオ法)は道具であり、盲信しないこと
まとめ
  • 価値に基づいた優先順位の判断
  • メンバー間での意識共有
  • メソッド化
  • 人に合わせるシステムを
  • 属人的な開発をやめる

リッチアプリケーション開発を助けるOSSのJSフレームワーク「AngularJS」の魅力

概要
  • 今もっとも伸びているJavaScriptフレームワークの一つ
  • API
    • Directive, Filter, Provider, Service, ...
  • DI
    • minifyした時に動かなくならないように、文字列で名前付けしておく
Enterprise × AugularJS
  • Yeomanのangular-generatorを使ったデモ
    • インターネット接続が必要なため、見れず(残念)
    • うまくいく場合、yeoman angularでscaffoldingし、雛形が作られる
  • Angularを使ったアプリのデモ
    • 入力値との双方向バインディングによるテキスト表示
    • フィルタ
    • バリデーション
      • キー入力ごとにバリデーションをして、余計なリクエストが飛ぶのを避ける(バリデーションOKでなければサブミットできない)
  • grunt serverでLive Reload
  • テスト環境
    • AngularJSチームが作ったKarmaというのがある
    • ファイルを保存した瞬間にテストを走らせる
  • Yeomanは無理に使わなくてもよい(特にエンタープライズでは)
  • エンタープライズにおいて、品質はどう担保するかが課題
  • AngularJS, Knockout.js, Ember.jsの比較
    • AngularJS → フルスタック、学習コスト高、自由度低
    • Knockout.js → シンプル、学習コスト低、自由度高
    • Backbone.js → シンプル、学習コスト高、自由度高
    • 自由度が低いことは、エンタープライズの分野ではむしろ品質管理の面で有効
    • AngularJSを使うとJavaScriptを書く量が少なくて済む

Webアプリ開発者のためのHTML5セキュリティ入門

公開されているスライドを見るのが最善だと思います。

サーバ側、クライアント側の両方に言及されており、Webアプリケーション開発者にとっては必見の内容だと思いました。

発表練習したら1時間30分になってしまったとのことで、時間の都合でCSP (Content Security Policy)の話は割愛されましたが、個人的には1時間30分でも聴きたいくらいの内容の濃いセッションでした。

オープンソースで始めるオフラインアプリケーション開発入門

注)スライドの中で、html5expertsをはじめ様々な役に立つサイトを紹介されていたので、そちらも併せて見たほうがよいと思います。

背景
  • 客先で自社製のアプリケーションを見せる必要がある。
    • リッチクライアントが必要
      • 下手が画面を見せるのも営業的にNGなため
    • インターネットにつながっていないと見られないのは論外
Single Page Application
  • メリット
    • JavaScriptのグローバル環境が維持される
    • WebSocketとの相性
  • デメリット
    • フルOSS
    • 技術要素が多い(JavaScriptフレームワーク、altJS、CSS Processor、開発環境、バックエンドとの通信、バックエンドの実装)
    • 面倒ならSenchaという手も
  • JavaScriptフレームワーク
    • 効率と保守性の観点で有効(ロジックを整理することができる)
    • Yeomanは好き
    • CSS Processor
    • モック開発
      • easymock or Stubbyを使い、フロントエンドだけをどんどん開発していくことができる
オフラインWebアプリケーション
  • 実行させるリソースをブラウザに保持する
    • 高速性やサーバ負荷の軽減のメリットもあるが、エンドユーザにとって、オフラインブラウジングが一番重要
  • キャッシュクリアは意外と簡単にできる
  • データの同期はWeb Workersでスレッド化

OSSのブラウザ自動テストツール「Selenium」を使った、開発・テストの効率化

Seleniumとは?
Selenium WebDriver
  • プログラミング言語での実行
    • 使い慣れた言語で
    • if, for, 変数が使える
    • 共通化によるメンテナンスコストの削減
  • JUnitでのデモ
  • その他
Selenium IDE
テストマネジメントにおける3つの誤解
  • 自動化でテストコストがかからなくなる
    • メンテナンスコストは発生し続けると認識すべき
  • 全てのテストをSeleniumで実行すればよい
  • 誰でもテストスクリプトが作ることができる
    • 安定したテストスクリプトを作るためには、スキルが必要であることを認識すべき
関連トピック
  • モバイルテスト
    • 公式(iPhone Driver, Android Driver)
    • サードパーティ製(Appium, ios-driver, Selenroid)
      • Appium
        • ネイティブなことが強み
      • サードパーティ製の方が使い勝手がよいので、公式にこちらが推奨になった
      • これらの3つを統合して標準化を進めている(Selenium3)
  • HTML5対応
  • 一緒につかわれることの多いツール類
    • DBUnit
    • Jenkins
    • Selenium WebDriverの大体としてのライブラリ
      • Capybara(Ruby)
      • Geb(Groovy)
    • Phantom
    • クラウドでの実行サービス
      • Sauce Labs
      • TestingBot
      • Scirocco Cloud

JavaエンタープライズアーキテクチャにおけるHTML5

アーキテクチャ
  • 4つの要素
    • プロセス
    • 構造/構成
    • 提供機能
    • 利用価値
  • バランスが大事
    • プロセス改善だけとか、今どきのフレームワークを導入するだけではダメ
    • 環境(制約)の中で利害関係者の感心事をどのように整合させるか
  • ユーザとITの関係
    • モノ的な利用(クライアントとサーバ)からサービスとしての利用(デバイスとサービス)へ
  • 統合と分散
  • 疎結合
HTML5の可能性
  • SPAには期待できる
  • 注意点
    • ただしイケメンに限る」問題
    • 「方法論」の誤解
    • ガチのアプリケーション開発になるため、生産性は低くなる
      • 似ているからといって同一視しない
    • 既存の手法とのミスマッチ
  • 今は混乱期
  • エンタープライズでの適用
    • 「技術に無理はさせない」こと
      • 「それ○○でもできるよ」は危険なサイン
    • 非推奨な領域
      • 複雑な業務アプリ
      • ネイティブ連携
        • ローカルファイルやデバイス間通信は不得意
    • 推奨領域
      • サブシステム的な扱い
まとめ
  • アーキテクトの始点からHTML5を捉えるべき
    • テクノロジー単体ではなく、よいITサービスのためにどのように適用できるか
質疑応答
  • Q1) タイトル的にJava8の話だと思っていた
    • Java CCC 2014(5/18)で寺田さんの話を聴いてください(笑)
  • Q2) 今ある業務アプリをそのまま適用できないとのことだが、デザインプロセスは今後改善されていくのか?
    • 今後できてくるだろうと思う
    • 新しいデザインの仕方を(UI/UX含めて)模索の最中
    • デザイナはデータの流出には興味があるが加工には興味が無い、一方で開発者はその逆、など思惑の違いなども要考慮

世界のビールが楽しめる、情報交換会!!

普段こういう懇親会には参加せずにすぐに帰ってしまうのですが、今回は参加しました。それだけ今日のセッションが充実してテンションが上がっていたのかもしれません。別にドイツビールと食事が目当てなわけではありません、多分…。

感想

ベンダ系、オープン系と分かれていましたが、上記の通り、終始オープン系のセッションを聴いていました。
今後どのようなことを頭に入れてHTML5に取り組んでいくかといったビジネス的な側面から、具体的な実現技術に至るまで、色々と濃い話を聞けたと思います。IEサポートへの取り組み、西村さんのセキュリティの話などは、HTML5云々に関わらず、有益なものが得られたと思いました。

まずは、フロントエンジニアとしての力を、チームメンバー含めて底上げしていく必要があるなぁと感じました。

オープンソースカンファレンスは明日(日付変わって今日)も続きますが、充実した1日になったことをここでお礼申し上げておきたいと思います。

スタッフの皆さま、発表者の皆さま、ありがとうございました。また、参加された皆さま、おつかれさまでした。