sgykfjsm.github.com

業務システムエンジニアのためのHTML5勉強会#04に参加した

業務システムエンジニアのためのHTML5勉強会#04 Web✕Java - HTML5で進化したWeb標準を、Java技術でどう扱うのか? -という勉強会に参加した。これはそのメモ。メモを取ったのは一部のみ。

今のWeb標準とStruts/Javaの問題(仮)

発表者は小川充さん。

NOTE 2013/09/12 08:10:33 スライドを追加

実際のタイトルはメモっていない…。atnndからコピペしてるのでもしかしたら違うのかも。今回のテーマのオープニングテーマにふさわしく、現場でのJava開発のしんどいところを端的に問題提起していて、次世代のWebやJavaに期待を寄せていることが伝わった。以下、メモ。

  • 業務系Webアプリにはしっかりとしたバックエンドが必要。
    • Struts系がよく使われているが、1.x系はEOLを迎えた。
    • J2EE+Struts1.xは過去のテクノロジー
    • 現在のWeb技術要素を取り込んでいない
    • 業務系Webアプリのガラパゴス化
  • J2EE + Struts1.x系が必要な要件を満たしていない
    • 独自フレームワークを構築
    • ベンダーロックイン
    • 属人化、ガラパゴス化
  • ガラパゴスからの脱出を目指す
    • 標準化
    • Java EEやScalaなどのあたらしいテクノロジーをどのように吸収していくか

Java EE の概要と HTML 5 の取り組み

発表者は寺田佳央さん。

総括としては、レガシーなJavaは捨ててJava EEに移行すべきということ。あと、なんとなくポジショントーク気味というかJava EE推し気味なのが気になった。以下はメモ。

  • Java EEは軽量なフレームワーク
  • 非常に多く採用されている
  • 標準の技術なので、他のアプリサーバにも移行しやすい
    • ポータビリティが考慮されている。
  • StrutsとTomcatはもうやめたほうが良いらしい
    • 10年前のデファクト・スタンダードが今もそうとは限らない
    • Struts1.x系はEOL。新たなバグは自分で対応していくしか無い。
    • Eclipse SurveyによるとStruts系のフレームワークをもう使わないという回答
    • レガシーな構成でアプリケーションを構築すると、メンテナンス・コストが増大する。
    • エンドユーザ(発注主)は基盤となるフレームワークやミドルウェア類には関心を払わない→脆弱性が放置されて信用問題につながる。
    • Java EEはオールインワンで非常に多くの試験をクリアしているので安心して使えるよ
    • Java EE準拠のアプリサーバはJava EE6全機能を使うことができる。依存関係に悩まなくて済むらしい。
    • 独自技術から標準の技術へ
  • Java EE7が2013-06に登場
    • 「HTML5、モバイル・アプリ開発の究極のプラットフォーム」
    • Java EE6は国内でも非常に多くの企業が採用しており、1ヶ月で数十万件のダウンロード
    • Java EE7はWebSocketに最も興味が持たれている。
    • Developer producutivity, html5, enterprise daemonds
    • html5…従来型のWebアプリケーションにも対応し、次世代型のWebアプリにも対応している。
      • WebSocket(HTTPとは違う。HTTPヘッダーなどがないので、送信データがより少なくなる。), JSON1.0, JAX-RS2.0(HTTP)
      • WebSocket, JAX-RS2のどちらが良いかは、つくるアプリケーションの種類しだい。
    • JavaServer Faces 2.2
    • 開発生産性の向上
      • Java EE6からEE7でコード量を60%ほど削減できる場合がある。
    • エンタープライズニーズへの対応
      • バッチとか
  • Java EE7はEE6の進化版
    • Java EE7を使うならJava EE6を押さえた上で、その差分としてEE7を使うようにすると良い。

JavaプログラマのためのScalaプログラミング

発表者は石黒尚久さん。内容はJavaとの対比を示しながらのScala入門。本当に入門的な内容で若干眠くなった。

  • JavaとScalaの文法的な違いを説明
  • JavaとScalaは相互利用できるとされている
  • ScalaはJavaの冗長な書き方を改善しようとしている
  • 簡潔な表記が特徴的。

JavaからScalaへ ~ScalaでWeb開発はこう変わる~

発表者は竹添直樹さん。

NOTE 2013/09/10 08:35:05 スライドを追加した。

なぜScalaを使うようになったのか、ということからScalaの主要なフレームワークの紹介、その使い所を提示していた。個人的には今回一番期待していた内容で、期待通りの内容だった。

  • Scala + アジャイルを実践している。
  • 小中規模のアプリケーションを効率よくつくることを追求
    • Javaでは無理、Scalaに可能性を求めた。
  • Web言語としてのScala
    • ステートレス
      • HTTPもステートレス
      • 関数型言語のステートレスな性質と相性が良い
    • コレクション操作
      • DBからデータを取り出して加工する処理と相性が良い。Webアプリケーションはたいていこの処理。
    • フレームワーク
  • Scalaの良さはFlexibility and Simplicity(?スライド見逃した)
  • Play2
    • 1台で処理できるリクエスト数を上げる
    • 非同期処理を簡単に書ける
    • が、ボトルネックであるDBアクセスがブロックしてしまう
    • postgresql-async(mysql版もあるらしい)というノンブロッキングなPostgresqlアクセス用のドライバがある。
    • これを使えばJVM上では完全にノンブロッキングになる(が、実戦で使うにはまだ早い?)
  • タイプセーフ
    • テンプレートもタイプセーフ
    • ルーティングもタイプセーフ
  • WebSocketも簡単に使える
  • ステートレス
    • サーバサイトに状態を持たない
  • Nettyの上で動くのでServletコンテナでは動作しない
    • warにするプラグインが存在するが、イバラの道なのでやめたほうが良い
  • Scalatra
    • Sinatra由来
    • Scalaのコードの中にHTMLを書くことができる
    • もちろんバリデーションやテンプレートもあって、テンプレートはPlay2と同じものを使うことができる。
    • ルーティングをタイプセーフにすることは出来ない
    • Servlet3.0対応
      • 既存のJava資産の移行ならScalatraが向いているかも
  • PlayとScalatraの使い分け
    • スマホのバックエンドなど、スケールさせる必要がある場合はPlay2
    • 業務システムなど規模が固定できるような場合はScalatra

全体的な所感として、HTML5はどっか行ったということ。