JJUG CCC 2013 Fall に参加しました

ざっくりとしたまとめと感想。

テーブルに電源が備え付けられて無いのは辛かった。macbook air買ったほうがいいのかな。Pro重いし。

基調講演-1

http://www.slideshare.net/yusuke/jjug-ccc-2013fallkeynoteshare

  • IoT (Internet of Things)
  • デバイス数はどんどん増え、一人あたりのデバイス数も増える
  • 開発者が開発し、サーバにデプロイし、それをユーザが利用する、という明確な区分がある
  • →ユーザの現実世界での行動によって、サービスが提供される、それを開発者が制御する、という流れに変わるかも
  • 　エンジニアに必要なスキルが変わっていく可能性がある

らしい。ちょっとした恐怖ですね。

基調講演-2 2013 エンタープライズ Java 最前線

  • 急にTシャツ投げが始まる
  • Glass Fish 4からは商用サポートを行わない（Glass Fishが消えるわけではない）
  • 代わりにWebLogicを使えばいい
  • Java EE 7
  • Project Avatar
    • [ここ]をみれば試せる
    • サーバ側をJavaScriptで実装出来る
    • Nashorn（なずほん）上で動作する
    • Javaを使わず、JavaScriptで全てを実装しろ、という訳ではなく、選択肢として提供したという形
  • J2EE時代からは随分変わっているので、やってみて下さい

Project Avatarを仕事で使う日が来るのかなぁ。。。

H-1 ジェネリクスの基礎とクラス設計への応用

テーマ： Generics Hell（4,5回言ってた）

  • Java1.4まではダウンキャストが必要だった（型安全じゃない）
  • Java1.5からはジェネリクスによって、コンパイラ時点で間違いに気づける
  • ジェネリクスとは、inとoutの型の関係性を表すもの
  • 3種類ある
    • 型変数の宣言
    • 型変数のバインド
    • パラメータ化された型
  • Map<String, Map<... とかやらずに、適度なレベルで型を宣言しよう
  • 型変数の境界
    • class Hoge <T extends B>
    • class Hoge <T extends B & Serializable> でインターフェースを境界に加える事が出来る
  • 再帰ジェネリクス
    • abstract class Hoge<T extends Hoge<T>>
    • new でバインド出来ないので、継承で使う
    • 自分自身のクラスを返す・引数にするメソッドを宣言できる
  • 内部クラスのジェネリクス
    • 内部クラスは外部クラスの型変数を利用できる
  • リフレクション
    • java.lang.reflect.Type を返すメソッドから、ダウンキャストして使う
  • 困ったら @nagise さんへ
  • Generics Hell本を書いています

意外と知らないこと・明確にわかってなかったことが多かった。

R2-2 テンプレートエンジンを利用して、プログラマーとWebデザイナーが共同作業をする上で大切なこと

1年半ぐらい自分が悩み続けてたり、現在進行形で同僚が直面している問題の一部だったりする問題。

プログラマ目線

  • 従来：デザイナがHTMLを作成 → プログラマがJSPに移植
    • 工数がかかる、開発スピードが遅い、つまらない作業
  • デザイナが直接テンプレートを書ければよい
  • Mayaa を使ってます
  • 使う上で工夫した点
    • m:idの命名規則が重要
      • IF_xxxx
      • LOOP_xxxx
      • xxx_HERE
      • xxxx_TAG
    • 共通部品：サーバサイドincludeの再現
      • iframeを使って擬似的に再現（javascriptで高さ調整、chromeでは表示できない、firefoxとかで）
    • m:id一覧表を自動生成
      • MayaaのXMLファイル→SAXでパース→Mayaaを使ってHTMLに変換
    • 相対パス自動調整機能を徹底活用
    • 属性をパラメータとして使用する→m:idが多くなりすぎることを防ぐ
      • 標準では実装されていない
    • Mayaa ファイルを毎回コピペしなくて済むようにする
      • 差分を書き、それを読み込む

デザイナ目線

  • デザイナが読み取れるのは、命名規則とドキュメントのみ（実装などは見てもわからない）
  • 機能が増え、時間が足りなくなると、混沌としてくる
  • ドキュメントはきちんと書き、情報を探せるようにする
    • WordPressがデザイナに人気なのは、そこら辺がしっかりしているから

それらを踏まえて

  • 相互理解が大事
  • プログラマはHTML/CSSの問題を切り分け、デザイン修正の手伝いが出来るように
  • デザイナは最終的にプロダクトを制作しているという責任感を持つ
  • デザイナのPCにサーバ開発環境をインストールさせない
    • 何か問題が起こったら、毎回フォローしないといけない
    • 容易に試験できる環境を用意する
  • 勝手なことをしない

マークアップをお願いするプロジェクトをやるときは、Mayaaを使ってみたいと思った。
（JAX-RS + backbone.jsなら、そもそも不要？）
ただし、事前に規約などは取り決めておく必要があることがわかった。
デザイナのPCに開発環境をインストールさせないというのは微妙かもしれない。デザイナさんのスキル次第かと。

H-3 ユニットテスト改善ガイド

  • ユニットテストにまつわる10の勘違い
  • 本：JUnit実践入門がおすすめ
    JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

    JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

  • ユニットテストは簡単なものではない→ちゃんと学ぼう
    • 学習は、プロジェクト外のコストとする
    • 可能な限り業務時間内で
  • まずはユーティリティクラスのテストを書こう
    • 入力に対して出力が一定のメソッドはテストしやすい（副作用がある・状態に依存するものは難しい）
  • テスト対象がテストしづらい場合は、テスト対象を修正する
  • CIを導入する前に、テスト文化を作りましょう
    • CIはローカルでとりあえずやっておくのもOK
  • テストコードもリファクタリングしましょう
    • 継続して使うことに意味があるので、単発プロジェクトではペイできないかも
    • フィクスチャの外部化、RuleやカスタムMatcherの作成、フレームワークを拡張などでリファクタリング
  • デバッガを使う代わりに、テストコード
    • テストコードを書くことを強制し、メンバーの手間を増やすことになると、うまくいかない
  • 上司を説得する材料として、品質向上はNG、教育（スキル向上）のためと説明しよう
    • リグレッション防止を押し出すのもあり
  • 失敗のままのテストは直ぐに修正する、出来ないのならば捨てる
  • 納品物としてテスト仕様書が求められるのであれば、可能な限り省エネで作りましょう
    • JavaDocを印刷とか、カバレッジレポートとか（数字の意味は事前にする）
    • どうしても重荷になるのであれば、いろいろ諦める
  • テスト対象のコードを変更できない環境なら、諦めましょう
    • テストのしにくいコードとはどういうものかを学べる
  • レガシーコードのテストを書こうとしない
    • テストできないからレガシーコード
  • リソースが足りない場合、導入してはいけない
    • プロジェクトが失敗した場合、導入したせいにされ、次からやりづらくなる

テストコードは全てを対象に出来るわけではないと、理解していたつもりだったが、プロジェクトの状態などによって、適用できない範囲は結構多いことがわかった。
基本的に余裕のないプロジェクトばかりなので、ユーティリティクラス・メソッドのデバッグの代わりから初めてみようと思います。
その前に、途中になってるJUnit実践入門を読む（写経する）のが先だけど。。。

R2-4 Javaアプリケーションサーバ構築・運用の勘所

http://www.slideshare.net/TakahiroYamada3/essence-of-javaapplicationserver

※初心者向けのセッションです。※

が嘘だと思ったのは私だけ？（私がこのへんを知らなすぎるだけ？）

R1-5 Javaで作るリッチなWebシステム開発の今

http://www.slideshare.net/kawada_hiroshi/html5webjava3

すごい勢いで喋ってた

  • 従来型：サーバでページを生成する

  • 次世代型：サーバはRESTインターフェースを提供し、JSでページを生成する

  • tools

    • とにかくたくさんある
    • Visual Studio, SenchaSDK は整合性が非常に高い
    • Eclipseとか使うとばらばらだが、新しいものを組み合わせられる
    • サーバの開発ツールはIDEのプラグイン拡張だけど、フロントの開発ツールは黒い画面を結構使う
    • デファクトはGrunt
    • サーバとフロントが、それぞれ独自の道に走っている
  • architecture
    • 5年前の主題はいかに繋げるか、だったが、ここ数年でレイヤーが上がった
    • Java(JAX-RS) + Backbone.js(sync) が鉄板っぽい
    • Project Avator がいい感じになってくれるのではないか
    • jQueryの恐怖
  • formats
  • エンタープライズ分野では、Web技術は敬遠されている
    • しかし、Javaも昔はそうだった
    • JavaScriptの性能も上がっている

スピーカー交代

  • 従来型と次世代型を混ぜると危険
  • JAX-RS + フロントMV*なら、デザインを自由に出来る
    • フロント側の実装量は増える
    • 初期表示までのコストは高い
  • JSFは、デザイン・動きを制限される
    • フロントの実装量は減る（減らして問題ないアプリケーション以外では適用しづらい）

Gruntを知らないっていう人が結構多かったのは意外だった。
エンタープライズJavaでは使わないか。
JAX-RS + Backbone.js をどこかのプロジェクトで使ってみたい。

R2-6 [BOF] JVM言語パネルディスカッション

  • Scala
    • オブジェクト指向＋関数型のマルチパラダイム
    • pimp my library で継承出来ないものを拡張出来る
    • IDE, Web Application Framework などが充実
    • Javaと相互に呼び合える（一部、記号などは呼べない）
    • コンパイルが遅い（TDDのリズムが崩れる）
    • Twitterで使われている
    • Effective Scala
    • pimp my libraryを下手な人が書くと...
    • ドメインモデルから書き起こしやすい
    • 既に、事例での説得はしやすい
    • ゲリラ作戦でツールを作ってしまったり
  • Clojure
    • 型なし
    • Lisp方言
    • 試してみたいのなら、Leiningen がおすすめ
    • マクロが使える、文法を作れる
    • Javaと相互に呼び合える
    • Emacsで書く人が多いが、Light Tableも良さそう
    • ニャンパスで使っており、AdThrottle、baasday などで実績あり
    • Herokuで動く
    • 日本語情報が少ない
    • JVMで動くLisp
  • Kotlin
    • 静的型付け言語
    • 簡潔、安全に書ける
    • Androidで動く、JavaScriptに出来る
    • 型安全、Null安全
    • 安定版はまだない
    • Javaと相互に呼び合える
    • IntelliJのプラグインで、Java変換後のコードをプレビューしながら書ける
    • 日本語情報が少ない
    • もっと関数型っぽく書けてもいいんじゃないかと
    • Scalaと違って、とっつきやすい
    • Javaからの移行も楽
    • ビルドは速い
    • Null-Safety
      • NotNull, Nullableを言語でサポートされている
      • val name: String; にnullを代入しようとすると、コンパイルエラー
      • val name: String?; にはnullを代入出来る、nullチェックせずに関数呼び出しを行うとコンパイルエラー
      • name?.toUpperCase() を使えば、メソッドチェーンがしやすい
  • Kink
    • プロトタイプベース
    • オレオレ言語（ http://www.slideshare.net/miyakawataku/kink-jvm ）
    • 言語仕様が小さい（代入も関数呼び出し、トレイとも言語仕様じゃないけどできる）
    • Kink→Javaは可能（逆は無理）
    • 実行速度は遅い
    • 静的解析は言語仕様的に難しい
  • Groovy
    • Javaベースの構文（Javaで書いて、拡張子を変えるだけで、Groovyのファイルに）
    • 動的、MOP（Meta Object Protocol）、AST変換
    • Javaと共存しやすい：テストコードだけ使う、変更の多いViewに近いところだけ使う
    • 最近は静的な部分が充実→高速化
    • Javaと相互に呼び合える（動的な部分は無理）
    • アクセス修飾子は飾り（Javaのprivateメソッドも呼べる：テストできる）
    • Invoke Dynamicを有効にもできるが、遅くなるかも
    • Power Assets
    • 日本語情報が少ない
    • Grails
    • 開発に便利なものはじゃんじゃん入れている
    • 知名度の向上、実績を作ることが必要

Scalaって、やっぱりコンパイルに時間がかかるよね。
テストコードにGroovyを使うのはありかもしれない。private呼べるし。それがいいことなのかは微妙だけど。
Clojureも良さそうだけど、まだLispをやる気にはなれてない。
プロダクションコードに使える（いろんな意味で使いやすい）ものは、Scalaぐらい？Groovyもいけるか？

見てなかったけど発見したスライド

出てないけど発見したLTのスライド

その他雑多なメモ

・キーノート
緑のあんちくしょう
JavaMEはSEと統合されていく方向
IoT（Internet of things）
開発してデプロイ→人間の行動によって、サービスを提供する


・エンタープライズJava最前線
Tシャツ投げ
伝説の謝罪会見？
GlassFishについて
今週の月曜日にロードマップが公開された
GlassFish4からは商用サポートを行わない
GlassFishは参照実装として、残り続ける
商用サポートが必要なら、weblogicなどを利用してください

Java EE 7
JSF2.2, JAX-RS, EL, JMS は大幅な更新
Concurrency, Batch, JSON, WebSocket は新規追加
JavaEE6を学習し、そこから差分を追いかければよいかと
JavaEE7に対応したアプリケーションサーバは現在２つぐらい（JavaEE6は18社）
WebSocketはPOJOベースで簡単に実装できる

CDI, JTAで、いままでのEJBを置き換えられる
Bean Validationが様々なところで使えるようになった

JavaEE7
Web Profile（軽量版） or Full
JAX-RSがWeb Profileに含まれるようになった
WebSocketのクラスタ構成も簡単にできる

Project Avatar
Downloadすると、Avatar込みのGlassFishが落とせる
HTML5アプリ構築フレームワーク
（
JavaSE8ではJavaScriptのエンジンが提供される（ぷろじぇくとなずほん）
ぷろじぇくとらいの で前から動かせていた
　パフォーマンスが20倍ぐらいになる
　Infork dynamic を使って再実装
）
サーバサイドJSとJavaEEアプリの融合
Thin-Server アーキテクチャ（TSA）
今まではViewとModelをサーバ側でマージしていた
ViewとServiceをサーバ側で提供し、クライアント側でViewとModelをマージ
　ModelとServiceをJSONで通信する
View(UI Node)
Avatar(Controller)
Model
がブラウザ上で動作する
Modelに対応するService
Avatar
Dataプロバイダ
がNashornで実装

1. Avatarアプリの作成
avatar new [project-name]
デフォルトでViewが生成される
2. ViewとServiceを実装
service にjs（サーバサイドで実行される）
view にhtml
avatar.registerPushService でurl と実装を指定
scriptタグのdata-model属性などで
outputタグにEL式でデータを与える
3. ViewとServiceをコンパイル
avatar compile [project-name] でコンパイル
service, view以下にbinが出来る
asadmin deploy [project-name] でデプロイできる
4. ViewServiceの「複数ページの一括」ダウンロード（プラグインは不要）
5. WebSocket/Server-Sent Event/RESTfulでDataServiceを利用
6. サーバ側はJavaEEのServiceも利用可能
7. JPA, JMS, NoSQL等のサーバリソースも利用可能
avatarからJavaEEのサービス・アプリケーションを呼び合える
8.クライアント側はHTML5,DOM,ローカルストレージなどを利用可能

JDK8が必須。その後にavatarをダウンロード
yoshio3.com 初めてのProject Avatar

JavaEE8とその将来
JSON-B

J2EE時代からはだいぶ簡単になってるので、やってみて下さい

avatarについて、JavaをやめてJavaScriptで実装するのはどうなんだ
→提供側としては、様々な選択肢を選べる状態にしていきたい
　JavaScriptで全てを置き換えるのは不安だろうだし、工数もかかると思うので、信頼性のあるJavaを使ったり適材適所で使い分けられるように




・ジェネリクスの基礎とクラス設計への応用

導入編
Java1.4まではArrayListから取得するときに、ダウンキャストが必要だった
　動かしてみないと間違いに気づかない（ClassCastException）
　ドキュメントなどで型を明示
Java1.5からはジェネリクスを使えるようになった
　ダウンキャストが不要
　コンパイル時点で型の間違いに気づく
　必修事項が増えました

今日のキーワード：Generics Hell

入門編
スコープ
　・メソッドの中でのみ有効なジェネリクス
　・インスタンスの中でのみ有効なジェネリクス
ジェネリクスメソッド
　・メソッドのin outの型の関係性を表す
　・java.util.Collections.shuffle(List list)はジェネリックメソッドではない（戻り値が無いから型の関係性が無い）
ジェネリックメソッドの呼び出し方
　Collections.replaceAll(list, “hoge”, “piyo”);
　普通は書かなくても、型推論してくれる
ジェネリックインスタンス
　・複数のメソッド間のin outの型の関係性を表す
３種類の＜＞
　・型変数の宣言
　・型変数のバインド
　・パラメータ化された型
型のバインド
　・仮型引数と実型引数は、メソッドの仮引数と実引数の関係性と同じ
ダイヤモンド演算子
推論器
　Java7では推論が弱いが、Java8ではラムダのために強化された
　戻り値がある型だから、引数はこの型だろう、というのはJava7では推論出来なかった
継承によるバインド
　public class StringList extends ArrayList { … }
　Map>> とかやらずに、適度なレベルで継承したクラスを作ったほうがわかりやすくなる
　クラスを作るのをサボらない
パラメータ化された型の代入互換性
　配列でやると、ArrayStoreException が発生
　　B arrayB = new B[1];
　　A arrayA = arrayB;
　　arrayA[0] = new B();
　ジェネリクスでやると、コンパイルエラー
　Bの集合はAの集合の代理をできない（集合論的に）
　ワイルドカードの使用
　　ArrayList とか、ArrayListとか
　　ArrayList は add()ができない
　　ArrayList は getの戻り値がObjectになる
まとめ
　まずはきれいなオブジェクト指向の設計を
　３種類の＜＞を意識する
　代入互換性は訓練あるのみ

困ったら @Nagise さんへ。

中級編
型変数の境界
　class Hoge
　境界を定義できる
　&でインターフェースを境界に加えることが出来る（Object & Serializable）
再帰ジェネリクス
　abstract class Hoge> {
　newでバインド出来ない
　継承で扱う class Piyo extends Hoge
　自分自身のクラスを返す・引数にするメソッドを宣言できる
　java.lang.Enum の compareTo とかで使われている
内部クラスのジェネリクス
　内部クラスは外部クラスの型変数を利用できる
　Outer outer = new Outer();
　Outer.Inner inner = outer.new Inner();
　Iterator とかで利用している
リフレクション
　イレイジャ方式
　パラメタライズド・タイプの型情報は欠落しない
　java.lang.reflect.Type（マーカinterface）を返すメソッドから、ダウンキャストして使う

上級編
コンストラクタの引数の形は継承で制約できません→Factoryで実装
継承によるバインドであれば、型情報から型変数に何がバインドされたかを知ることが出来る getGenericSuperclass
template methodパターン
まとめ
　new T()したくなるシチュエーションには継承によるバインド＋リフレクションを使えないか検討する

ネタ
　型変数の相互利用
　型変数の部分適用（高階型変数）




・テンプレートエンジンと。。。
テンプレートエンジン導入前の現場
　デザイナーが作っていたHTMLをプログラマがJSPに移植していた
　工数が高い、開発スピードが遅い・つまらない作業
→デザイナーが直接テンプレートを書ければ良い
Mayaa
　単体で利用可能（）
　採用した理由
　　JSPをそのまま置き換えられる
　　日本人が作っているので日本語ドキュメントが充実
　　2005年ぐらいからあるので実績がある
　工夫したこと
　　m:idの命名規則が重要
　　　4種類
　　　　IF_xxxx
　　　　LOOP_xxxx
　　　　xxxx_HERE
　　　　xxxx_TAG
　　共通部品：サーバサイドincludeの再現
　　　サーバ側でincludeすると、ヘッダ・フッタなどの全体を見ながらできない
　　　iframeを使って擬似的に再現
　　　　javascriptを使って高さなどを調整
　　　　chromeのセキュリティポリシーに引っかかる。Firefoxを使えば動く
　　m:id一覧表を自動作成
　　　MayaaファイルはXML形式→SAXでパース→Mayaaを使ってHTMLに変換
　　　JavaDoc風に各
　　相対パス自動調整機能を徹底活用
　　　PathAdjusterを活用
　　　相対パスを絶対パスに変換だけでなく、https・パスの追加・クエリ文字の追加など
　　属性をパラメータとして使用する→m:idが多くなりすぎることを防ぐ
　　　標準では実装されていない
　　Mayaaファイルを毎回コピペしないで済むようにする
　　　mayaaファイルを少しだけ追加したい
　　　ProviderUtil.getParentSpecificationResolver().getParentSpecification(spec)を書き換える

デザイナー目線
　とにかく命名規則とドキュメントが命！！
　機能が多くなればなるほど名称や動きは複雑に！
　WordPressがデザイナーに人気なのは、ドキュメントが豊富であったり、検索で出てくるから
　　→ドキュメントはちゃんと書きましょう

よくある事例
　プログラマ・デザイナの得意分野は違うので、それを理解することが大事
　プログラマに必要なスキル
　　問題を切り分ける能力
　　HTML/CSSとかは当然使えなければいけないスキル
　デザイナに必要なスキル
　　最終的にプロダクトを制作しているという責任感
　　　プログラマの判断をアテにしない（ぐらいの勢い）
　行ったほうが良い取り組み
　　デザイナのPCに開発環境をインストールさせない
　　問題が起こったら毎回フォローしなければいけない
　　試験環境を用意する
　勝手なことをしない
　お互いの分野を理解する


・ユニットテスト改善ガイド
ユニットテストにまつわる10のかんちがい
本：実践アジャイルテスト

ユニットテストの書き方がわかりません
　→テスティングフレームワークやテスト手法を学ぶ
　ユニットテストは簡単ではない
　ヒント
　　学ぶ機会を作ろう
　　トレーニングを行う
　　　プロジェクトのコストとして扱わない
　　　可能な限り、業務時間で行う
　　ティーチング可能な経験者を探そう
　　JUnit実践入門がおすすめ
どこからユニットテストを始めたらよいかわかりません
　→まずはユーティリティクラス・メソッドから始める
　簡単なところから始める
　テストしやすいクラス
　　入力に対して出力が一定である
　　状態を持たない
　複雑な条件式は抽出したら、テスト可能
ヒント
　経験を積み重ね、範囲を広くしていく

対象のコードがテストしにくいです
　→テストしやすく修正するチャンスです
　テスト対象は修正しても良い
　ヒント
　　可読性の高いAPIはテストしやすい
　　　リファクタリングを学ぶ
　　テストファーストを学ぶ
　　　プロジェクトで矯正する必要はない
　　　状況によって使い分ける

CIを導入したいです。
　→効果的ですが、先にテスト文化を作るほうが大切です
　CIだけあってもテストがダメでは効果が薄い
　自分の時間を使い習得し導入するしかない
　ヒント
　　はじめにテストする文化を作ること
　　何時でも使えるようにCIを学んでおく
　　　ローカルでとりあえずやってみるのもOK
　　　AWSに構築するのもOK
　　　古いマシンでもOK

テストコードのメンテナンスが大変です。
　→テストコードを定期的にリファクタリングしてください
　ユニットテストはプロセス
　　継続して行うことで効果が高くなる
　　単発プロジェクトには適さない（ペイ出来ない可能性が高い）
　テストコードのメンテナンス
　　プロダクションコード以上に冗長化する
　　最初から不リファクタリングしながらテストコードを書いていく
　開発時のコスト
　　プロダクションコードのプログラミング＋テストコードのプログラミング＋テストコードのリファクタリング
　ヒント
　　フィクスチャの外部化
　　RuleやカスタムMatcherの作成
　　共通処理の抽出
　　フレームワークの独自拡張

他のメンバーがユニットテストに興味がありません
　→便利なデバッグツールとして広めていきましょう
　ユニットテストは矯正してはいけない
　効果や目的を説明する
　自発的にやってもらう
　printfデバッグ→テストコード に置き換える
　単体テスト（Excelなど）の置き換えとして導入する
　ヒント
　　メンバーの手間を増やさないこと
　　必ず、導入する目的を説明する
　　仲間を増やす（日本人は周りに流されやすい。少人数なら一人でも作れば周りが流れてくれる）
　　既存の作業を置き換える形で導入する

上司を説得できません
　→品質向上はNG、教育（スキル向上）のため
　テストの分類
　　・製品を批評するテスト
　　・チームを支援するテスト
　ヒント
　　導入の目的は教育的効果
　　リグレッション防止もOK

随分前から失敗のままのテストコードが残っています
　→直ぐに修正します。出来そうにないならば捨てましょう。
　テストコードをリファクタリングしましょう
　整理し過ぎるとテストとしての可読性低下
　難しいが工夫が必要で楽しいところ
　ヒント
　　保守コストにテストコードの保守も含める

納品物としてテスト仕様書などが求められています
　→可能な限り省エネで作りましょう
　納得されなそうな場合は最終結果のみ報告
　レポートでページ数を稼ぐ
　　JavaDocの印刷
　　カバレッジツールのレポート機能（％の説明が必須）
　成果物作成が重荷になる場合
　　なんとか説得
　　併用
　　ユニットテストを諦める
　　いろいろ諦める
　ヒント
　　指標として、テスト件数やカバレッジは有効

テスト対象のコードを変更できない
　→次に期待しましょう
　個人では買えられない壁は存在する
　　見方を多くつくる
　　変化を促進できるポジションにつく
　ヒント
　　頑張らない
　　常に「どうすればテストしやすいか？」を考え、次のプロジェクトに生かす

レガシーコードが相手です
　→勝ち目がないテストはやめましょう
　ヒント
　　テストできないからレガシーコード

リソースが足りません
　→導入してはいけません
　導入して失敗すると、そのせいにされ、以降の導入が難しくなる
　ヒント
　　余裕があるときにやる






アプリケーションサーバの特性
　・長時間の実行
　・複数ユーザからの同時アクセス
　・アプリとインフラの中間
ログ管理
　トラブルシューティングの基本
　GCログ
　　GCチューニング、メモリリークやOutOfMemoryError分析に必要
　　-verbose:gc：基本
　　printgcdatestamps
　　printgcdetails
　　ログローテーション
　　GCViewer
　　上書きに注意
　　　再起動前に堆肥 or -Xloggc:gc-`date …`.log
　　OSコマンドでの矯正ローテーションは大抵正常動作しない
　　GC統計
　　　jstatは統計情報としては役に立つが、障害解析にはあまり役に立たない
　　ヒープの詳細な解析
　　　ヒープダンプは最低2回取得して、差分を解析
　　　OOME発生時にダンプする設定をしておく
　　　　OOME発生後はJVMとしての動作が保証されていないので、必ず再起動
　標準出力・エラー出力ログ
　　sysout, syserrはダメ
　スレッドダンプの解析：ThreadLogic
　ログのローテーション
　　Apache付属のrotatelogsなどの利用
　　　java 〜 2>&1 | rotatelogs -l console.log.%Y%m%d 86400
　　　ログの削除も別途見当
　　> /dev/null はダメ
　アクセスログ
　　とりあえず有効化
　　Webサーバ・アプリケーションサーバどちら側の問題かを判断
　　レスポンス時間も取得
　　セキュリティ・監査目的でも
　サーバログ
　　通常INFO以上にすべき
監視・統計
　OS関連
　　CPU：使用率、キュー長
　　メモリ：使用料、ページング
　　ネットワーク：ソケット状況、I/O発生量
　　vmstatを利用
　　スレッドごとのCPU使用率が重要
　ログ
　　ERRORレベル以上を基本的には監視
　　GCログやアクセスログから統計
　死活監視、リソース監視
　　死活監視
　　　実際にリクエストを投げて応答を確認
　　　Full GCを考慮してタイムアウトやリトライを実装
　　MBeanによるリソース監視・統計：Java Mission Controll
チューニング
　アプリケーション/アプリケーションサーバ/JVM/OS/HardWare
　サーバ分割・分散配置
　　計画的に再起動することで、リーク解消にもなる
　OS環境設定
　　ファイルディスクリプタ（目安：8192、ただしWebSocketの場合は足りないかも）
　　コアファイルサイズ
　ネットワーク関連設定
　　TCP
　　　connectのタイムアウト、KeepAlive、TIME_WAITのタイムアウト
　　接続バックログ
　　IPv4を有線
　JVMメモリ・GCのチューニング
　　ヒープサイズ
　　　Xms = XmXにしましょう
　　　大きい場合、GC回数は減るが、GC時間が上がる
　　GC方式
　　　レスポンス重視
　　　スループット重視
　スレッドのチューニング
　　スレッド数はTPS * レスポンス時間
　　リクエストキュー長も制限
　コネクションプールのチューニング
　　基本は、初期容量=最大容量、スレッド数 >= 容量
　タイムアウトのチューニング
　　実行タイムアウトを直接的に指定できない
まとめ
　古いバージョンを利用している方は、アプリケーションサーバだけでもバージョンアップを
　アプリケーションサーバの特性をしる
　　



従来型
　Server side scripting
次世代型
　single page application
がサーバ屋視点

フロント屋視点で
1. Tools
2. Architecture
3.Formats

tool
　とにかくたくさんある
　フロントエンド開発ツールの組み合わせ
　　ASP.NET+OOS Visual Studio
　　SenchaSDK
　　ベンダ系のツールの整合性が非常に高い
　　オープン系（Eclipse）はばらばら（つらいが、新しいものを組み合わせられる）
　サーバの開発ツール
　　IDEのプラグイン拡張で
　フロントエンドの開発ツール
　　エディタは別で、ツールは黒い画面で
　　プラグインを通さない
　バックグラウンド処理のデファクトはGrunt
　　（Grunt知らない人もけっこういる）
　サーバとフロントが独自の道に走っている
architecture
　5年前の主な議論はいかにつなげるか、だった
　ここ数年でレイヤーが上がった
　つなぐことはあたりまえ
　いかにしてモジュール間通信を行うか
　　ASP.NET(SignalR
　　　RPC
　　Sencha(CommonJS) + NodeJS
　　Java(JAX-RS) + Backbone.js(sync) が鉄板っぽい
　　　RESTの思想でインターフェース設計
　　　クライアント・サーバ間でリソース同期
　Project Avator
　jQueryの恐怖
　　WebデザイナのjQuery=CSSの延長
　　業務やサンのjQuery=業務ロジック
　　　フレームワーク無しで業務コードを書き始める
　　実は結構、揺れている時期なのかもしれない
formats
　SPAの理想的な協業
　pjax
　　欠点：クロスブラウザ対応できない
　　　検索に弱かったりする
　　欠点：初期表示に時間が掛かる
　デザイナ<=>プログラマのジレンマは続く
エンタープライズ分野ではWeb技術は敬遠されている
　Javaも昔はそうだった
　Javascriptの性能も上がった


メンテナンス性の良いWebシステムを構築するために

最近、フロントの実装料が増えてきた
サーバ・JSで同じものを実装することになってきた

1. 画面構築方式
　Ajax登場以来、画面構築方式が複雑化
　従来：サーバでHTMLを生成
　新方式：フロント側でもMV*系のフレームワークを導入
　　サーバはRESTのインターフェース
　混ぜると危険
　DOM操作・Ajaxに加え、テンプレート・リソース同期・JSの構造化
　　JAX-RSなら大丈夫
　JSFが多くをやりすぎる（役割分担が難しい）
3.
　JAX-RS
　　サーバはRESTインターフェースのみ
　　画面はフロント側で生成
　　Backbone.js, Anguler.js と組み合わせやすい
　　注意点
　　　フロント側の実装料は増える
　　　テンプレートエンジンが必要
　　　初期表示時に余計なリクエストが飛ぶ
　JSF
　　画面はサーバが作る
　　Ajax通信時もサーバ側で画面を作る
　　Ajaxでの画面部分構築はを利用する
　　JSFのAjaxはXML形式で独自色が強い