読者です 読者をやめる 読者になる 読者になる

せてぃーずノート

Javaのイベント参加レポートとかを書いたりします。

JJUG CCC 2016 FALLに行ってきた

秋・・・というツッコミはさておき、2年ぶりにJJUG CCCに行ってきました。 感想は順不同で印象に残ったものから。

懇親会は出たかったけど、風邪がヤバイことになっていたのでパス・・・。

リンク

エンジニアの生き方的セッション感想

日本でも出来る!最先端のDevOpsを導入する方法

DevOpsというコール・アンド・レスポンスから始まったセッション。 DevOpsについての非常に熱くそして濃密なセッションでした。

  • 人・プロセス・プロダクトのどれかが欠けてもダメ。
    ものすごいオートメーションを実現しても、リリースに誰かの承認が必要という人の面が欠ければ1日10回デプロイは絶対無理。

  • 頑張って時間をかけて準備しても、本番にデプロイしたら誰も使ってくれないことだってある。
    本番はフィードバックを貰う場所。
    未来は予見できないから、フィードバックから学ぶ。

  • マイクロサービスに入社して上司に指示を受けたことがない。ただ「ハッピーか?」と聞かれるだけ。
    ハッピーでないのであれば、その問題を一緒に解決してくれる。
    上にお伺いを立てないからスピートが上がる。

  • 日本は106カ国で一番アジャイル導入が難しい国。
    でも、アジャイルの土台にはトヨタ方式や守破離という日本文化がある。
    その隙間を埋めているのは西洋文化。
    彼らの思考パターンを理解することが重要。

  • 日本の生産性が低いのはUSが優秀なわけじゃない。
    USは予定されたタスクのうち、大事なことしかやらない。
    タスクのうち、無駄なものは計画的に捨てる。 日本は全部やろうとする。
    差し迫ったものから、重要かどうかに関わらずをやる。
    結果として何もかも中途半端になりやすい。

  • 準備に対する考え方。
    知らなくてもやってみる。やってから考える。
    ソフトウェアの世界で、やってみる前にすべてに備えておくのは難しい。 とりあえずやってみて、やっている間にバリューを見つけ出す。

別に海外がみんなこうだとは思わないし、日本にだってすごいチームはある。
でも、ツールや外側だけを一生懸命取り込もうとしたり、自分たちの組織を変えずにアレンジとかいう体のいい言葉で逃げるのは意味が無い。 考え方を変えないといけないときに来ていると実感。

自分の場合、「とりあえずやってみて、やってる間にバリューを見つける」は欠けてると思う。
色々勉強してきたことからから来る変な思い込みというか見切り。
「やらなくても何となくわかった気になってしまう」というのは悪い癖だと思うので変えていかないと・・・。

JAX-RS REST Client で Cognitive Service や Excel を操作しよう

セッション最初に流れた、ITが目の見えない人をサポートしているビデオ。
ビデオが終わった後、寺田さんが言った「ITサービスが人の役に立つと本当に実感出来るようになった」
これが全てだと思う。

Be a great engineer!〜 フォローすべきトレンド、スルーすべきトレンドをどう見抜くのか

起こっていることを本当に理解しているか?
どのトレンドをフォローし、スルーすべきか。

午後のDevOpsのセッションと組み合わせて考えるとより素晴らしいかも。
いくら「とりあえずやってみる」でも時間は有限。
全部の技術を試すわけには行かない。

技術的なセッション

詳細はスライドにあるので感想をば・・・。

Selenideを試行錯誤しながら実践するブラウザ自動テスト

WebDriverを使いやすくラップしたフレームワーク
Codeboneというエストニアの会社が開発。

Jqueryの$ファンクションでエレメントを指定できたり、Ajaxアサーションを楽に書けたりと、テストが非常に書きやすくなっている。
テスト失敗時に自動でスクリーンショットとHTMLを保存してくれるのはいいと思う。

Payara Micro の設計と実装

Payara Microの仕組みに特化したセッション。 以前、一度試したことがあったのでスムーズに聞けた。

Java EEのマイクロプロファイルがどういう形式になるか分からないけど、Payara MicroはGlassfish使った事ある身としては入りやすい。

Java EE - What's Next?

Java EEの方向性の話。
今までのJava EEがやってきたように、マイクロサービスにおける標準規格を作っていきたい。

「そんなこと実現出来るのかー?」と言うのが今のところの感想。
Java EEと同じやり方であれば、規格に合わせて各ベンダーがミドルウェア出すわけだけど、マイクロサービスまで含めたミドルウェアなんて製品に出来るのか・・・?
クラウドベンダーの依存も何らか発生しそうだし。

あと、Java EE 9の参照実装についてGlassfishってハッキリ言わなかったのも気になる。 それでもマイクロプロファイルは期待。

Kotlin/Go言語デベロッパーミーティング「ライトウェイト言語で行こう!」に行ってきた


kokucheese.com

大井町きゅりあん大ホール(1000人収容!!)という会場で開催されたイベント行ってきました。
平日午後ということもあり、人はそこそこ。

KotlinとGo言語の本をそれぞれ3000円で買えるという特典付きでした。
値下げした分、無駄なもの省いているのか分厚い本2冊を手渡し。
手提げ紙袋(最悪ビニールでも・・・)が欲しかった・・・。

Androidが生み出す開発言語の多様性

発表資料

ownCloud

概要

Androidの生まれるまでの歴史。
技術的要因で発生していた既得権をオープンにするのがイノベーション
2010年付近でのWebの進化の速度に比べ、進歩が停滞していたところにAndroidをリリース。
それによって、キャリア等の既得権だったモバイルがオープンになった。
副産物で訴訟問題とか起きたけど。

Android開発者はGoogle好き。
Googleが何かやると喜んで受け入れられる。
レガシーのものでもGoogleが取り上げると受け入れられる。(本当かいな・・・)

LLVMについてはまだこれから。
将来的にはAndroidを開発できる言語の選択肢が増えるかも。

感想

JJUGナイトセミナーとかでJava側での事情を聞いたけど、Googleのやり方は仕方なかった面もあるかなと。
JCPスマホもサポートするJava SE提案しても、通らなさそうだし。
通ったとしてもリリースまで時間もかかりそうだし。(2011年7月のJava7にはきっと間に合わない)
かといって、新しく言語作るほど時間もなし。

Googleのやり方である、先にリリースしてそこから標準にしましょう的なところは現実的だとは思う。
仕様をみんなで決めてからというJCPのやり方は、Googleにすれば遅すぎて我慢できないのかもしれない。
Androidオープンにしたせいで亜種が乱立して統制取れなくなったのは間抜けだけど。。。

JavaからKotlinに乗り換えるはじめの一歩

発表資料

ownCloud

概要

JetBrainがリリースしたKotlinの紹介。
KotlinはJavaの欠点である冗長さやNull問題を解決してくれる。
Javaで何十行も書かなければいけなかったコードが、わずか3行で書けたりもする。
Android対応も公式が強烈にプッシュしているので使えるようになっておいても損はない。

感想

ことりん可愛いよ、ことりん。

Lombokとかで解決されてきているとはいえ、Javaのダメなところを見事に救済している感じ。
KotlinからJavaの呼び出しも可能なので、過去の資産やJavaの便利なライブラリを使うことも可能。
逆にJavaからKotlinの呼出しはハマリポイントが多いらしいので、フレームワークから使うのはコツがいるかも。

気になったのはJava6のバイトコードが生成されるということ。
Android向けだからだと思うけど、Indyとか使えたらもう少し効率あがりそうなので残念。

あ、ビルド含めるとKotlin・Java・Groovyと3つの言語が必要っていうのはなんか面白い。

Googleが作ったGo言語の力量を見極める!

発表資料

ownCloud

概要


Google謹製のGo言語。
あのDockerでも採用されている。
JVMのような実行環境を持たず、動作する環境を設定してからのクロスコンパイルでバイトコードを生成する。
gRPCのような最新のRPCに対応していたり、RaspberryPiのGPIOのコードも書けたりと使える範囲は広い。

あとはHTTP/2、gRPC、QUICという新しいプロトコルの紹介。

感想

Javaに比べればCに近い印象。(まぁ、開発者にCを作った人いますし)
JVMのようなオーバーヘッドがない分、軽量かつ高速に動きそう。
どちらかというと、Javaよりも低レベルな処理を書くのに向いているように思えた。
低レベルな処理が多めで速度欲しいけど、クラウドでCやC++はちょっとっていうところに使うといいのかな。

プロトコルいついてはQUICは初めて聞いた。
gRPCは使っては見たいけど、Goが前提っぽいのとメッセージがバイナリなのが気になるところ。

残念ながらゴーファーくんはあまり出てこなかった。

Java Day Tokyo2016の不満点まとめ

ちょっと書かざるをえない

運営的なもの

  • 会場が色々な意味で狭い
    • 部屋のキャパシティが小さい?
    • 座席が狭い
    • 展示ブースが狭すぎ。せめて、机と椅子くらい用意してあげようよ・・・。スポンサーの富士通NECさんの扱いが酷すぎない?
    • トイレが少ない
  • 展示をもう少し充実させて欲しい
    • スポンサーや企業のデモを見るのも楽しいのに。。。
    • Dukeくんと記念撮影もなかったし
    • そのくせ物販だけは例年通りやってるし
  • 寒かった
  • セッション資料の公開はアナウンスして欲しい
    • スライド切り替わる度にシャッター音がウザい!!
  • 机がないのはまぁいいとしても椅子が辛い・・・。
    • 2時間で終わるナイトセミナーとかならともかく、1日座って聴くのには辛い
    • 品川プリンスの椅子は良かったw
  • ストリーミングが気がついたら終わってた?
    • 終わったならアナウンスだそうよー

まぁ、一昨年去年に比べて、予算を大幅に削られてるなぁとは思いました。
スタッフも少なめな気もしました。
来年もちょっと不安・・・。

良かった点

  • セッション入場前にバーコード読み取りなくなったので、スムーズに入れて良かったかも
    • その代わり予約が全く機能してなかった気もする
    • 単純に参加者ごとにカード作る手間にお金を使えなかっただけかもしれないけど:P

JAVAのおじさん

業務サボるために来てるとしか思えないオジさんはどうにかできないものかね。。。

  • セッション中寝てる
    • 専門的な話は難しい、仕方ないよね
  • セッション中にツムツムしてる
    • お仕事の話よりゲームのほうが面白い、仕方ないね

Java Day Tokyo2016に行ってきたよ

都合のため、キーノートとナイトセッションは参加できず。
午後の5セッションの感想です。
スライドがアップされたら更新するかも

Introduction to MVC 1.0

Java EE 8に含まれるMVC1.0の概要の説明。
深く突っ込んだ内容はなし。
MVCとは?」の説明からなので、基本的なところから学べた。

そうは言いつつも、さりげなくViewでFreeMaker使ってるサンプルがスライドに入ってたり。

実装はOzark。
仕様はそれほど難しくなく、JAX-RSを使いこなせてる人ならそのまま使えそうな感じ。
SpringMVC慣れてる人も大丈夫そう。
感想としては、Viewの指定方法が沢山あるのは使う時に迷いそうなのが微妙。

まとめにもあったけど、Java EEMVCという選択肢が増えるのは良いことであるのは間違いない。
ただ・・・遅すぎない?
EE7に入っていればよかったのに・・・。

Java EE 7 アプリケーションとWebセキュリティ

スーツ姿の裏紙さんセッション。
IPAが公開している、安全なWebサイトの作り方をJava EEでどう実現するかの話。

重要なこと

  • 最初からセキュアなコードを書くこと。セキュアじゃないコードをセキュアにするのはコストが高い
  • 対策も必要だけど、脆弱なコードをチェックする仕組みも必要
  • それぞれの対策は簡単だけど、攻撃がどういう仕組みでどういう理由で対策できるのかを知らないと対策しても不安が残る
  • セキュリティに関する資料は一般的に多く出回っているので、普段から勉強しておくのが大事
  • ビジネスロジック(モデル)で対応するのは、可読性や保守性に悪影響。なるべくViewやControllerで対応する

各攻撃に対する対策

JSPや低レベルな処理の話もあったけど、面倒なので割愛。JSFを使おう。

XSS

Faceletならデフォルトで対策済。

CSRF

JSFなら対策不要。
ただしViewをステートレスにすると対策が必要になる。
ステートレスとステートフルを使い分けるといい。

SQLインジェクション

JPAの@NamedQueryアノテーションを使う。
em.createQueryはクエリ文字列を受け取るため、SQLインジェクション脆弱性があるクエリを指定される可能性がある。
CriteriaAPIを使う手もあるが、学習コストが高いのでオススメはしない。

パスのパラメーターチェック

JavaのFileAPIをそのまま使うのではなく、パラメータチェックを行うラップAPIを作成して利用する。
こうすることで、FileAPIで検索して脆弱なところを検出できる。

クリックジャッキング

レスポンスヘッダーに、X-Frame-Optionsをつけることでiframe、frameを禁止できる。
ただし、Ajaxで行うファイルアップロードも潰してしまう可能性があるので、すべて禁止するのではなくSameOrigin指定を推奨する。

OSコマンドインジェクション、バッファーオーバーフロー

割愛。
どちらも普通に作っていれば起こらない。

その他

レスポンスヘッダーに以下の二つをつけるといい。

  • X-Content-Type-Options:nosniff
    IEはコンテントタイプが指定されていないものを自動で判断する。
    そのため、悪意のあるコンテンツを解析した際にスクリプトを実行される可能性がある。
    このヘッダーをつければ自動解析を無効にできる。

  • Content-Sequrity-Policy 最強のCSRF対策だけど、CSSやイメージを妨げる可能性あり。
    すべて禁止ではなく、許容するリソースを指定する。

Java Concurrency A(nother) Peek the Hood

Javaの並行処理に関する話。
わかりやすかったけど、技術的にはかなり深い所。

概要

  • Webアプリケーション、GUIはマルチスレッドが普通
  • ライブラリを公開する場合も、マルチスレッドで使われることを考慮しよう
  • というより、シングルスレッドが許されるのは学校の宿題まで

  • ConcurrentAPIとか使い方を暗記していても仕組みを理解してないのは危険

  • メモリモデルを正しく理解しよう

  • 予期しない動きをする犯人は、JITコンパイラとメモリオーダリング

    • コンパイラの最適化は、開発者がわからない
    • 同じコードでも、JREがServerとClientで動きが異なるケースがある
    • メモリオーダリングはCPUによって仕様が異なる。Intel、Sparkは厳密。ARMは少しゆるい。
  • マルチスレッドの場合、各スレッドによって実行順の基準が異なる

  • Javaの場合はHappened-before

  • Java SE 5まではfinalがイミュータブルではなかった

  • 並列処理ライブラリを利用するときは、なるべく抽象化されているものを使う。具体的な処理を利用すると実行効率が良さそうに思えるが、とても難しく問題も出やすい。

  • 本番と同じ環境でテストすることが大事

  • 本を読むならJava Concurrency in Practiceがおすすめ

実践してわかったJavaマイクロサービス開発

モノリシックなWebアプリケーションをマイクロサービスに変えていった経験の話。
マイクロサービスは技術的な話は多いけど、実践例は少なかったので参考になった。
スライドが丁寧だったので、内容の詳細は省略。

参考になった点

  • サービスディスカバリーは必須
  • クライアントとサービスを共通のインターフェースにすることで、IF仕様書を作らなくて良くなる
  • 多言語化はEurekaとの関係もあり難しい
  • サーキットブレーカーは障害が起きたらどうすればいいかまだわからない
  • HTTPは同期処理。AMQPは戻り値なしの非同期
  • 画面を中心にAPIを考えると、巨大なものになりやすい
  • ドメイン分割は大事。ドメインごとにサービスを作るくらいがちょうどいい

Javaエンジニアのためのクラウド時代の過ごし方

これもスライドがとてもいい感じなのでポイントだけ。
決してお酒が回って面倒なわけではない。

考えさせられた点

  • 今までは作ることが大変だった。しかし今は作るところは簡単になり、運用面の問題に向かい合えるようになった。
  • 良いコードを書くことは大事だけどそれだけじゃダメ
  • アジャイルクラウド、DevOPS、マイクロサービスは、それぞれの組織が取り組んできた結果
  • クラウドによって、ハードウェアがソフトウェアとして定義できる
    • 自動化、コピーができる
    • 非機能要件のテストが書ける
  • PaaSは稼働しているミドルウェアを借りるイメージ
    • 制約はあるが、使うことで便利になる
    • 個々の問題に対するミドルウェアを簡単に調達できる
    • オンプレで作ったものをIaaSに移行するのは非効率でクラウドの利点を生かせない
  • インフラのテストは本番環境でしかできない。そのテストをするのがNetflixのカオスモンキー
    • カオスモンキーはランダムにサービスをダウンさせる
    • カオスゴリラはAZを丸ごとダウンさせる
    • カオスキングコングはリージョン丸ごとダウン
  • ダウンの目的は自動で復旧するかの確認。手順書ではなくコード。運用を不要にする。

これからのエンジニア

2つのどちらかにならないといけない

  • 専門家
  • ゼネラリスト
    • テクノロジー以外の分野とのバランス
    • 最低でも技術と業務を両方見れる

JSUG勉強会 2016年その3.5に行ってきました

イベントページはこちら

JSUG勉強会 2016年その3.5 - Kenny Bastani来日特別講演 - 日本Springユーザ会 | Doorkeeper

SpringBootを中心とした、マイクロサービスについてのセッション。
テーマ自体が難しいことに加えて、QAを含めて通訳なし100%英語というハードコアなセッションでしたが、ためになるお話でした。

最大の敵は開始前のピザとビール・・

セッション概要

  • 開始前の会場アンケート。 SpringBoot使ってる人はたくさん挙手があった。
    逆にSpringCloudを使ってる人はほぼいなかった。

  • ApacheTomcatMySQLで構成されるモノリシックなアプリケーションから、SOAを経てマイクロサービスになる。
    マイクロサービスは、各サービスで共有するShered Cacheとそれぞれのサービスの特性に応じたDBMS等のリソース。
    サービスごとにリソースを分けることで、1つのサービスがダウンしても全体はダウンしない。

  • インフラストラクチャもスケールアウトが難しいモノリスな構成から、スケールアウトが容易なコンテナへ。
    マイクロサービスはコンテナ単位で依存関係を持つ。 依存関係の解決はServiceDiscoveryがおこなう。

  • SpringBootのMavenダウンロード数は、2015年12月に225万を突破

  • SpringBootは「フレームワークのためのフレームワーク
    SpringFrameworkがケーキの材料だとしたら、SpringBootは完成したケーキ。 ケーキを作成するキッチンがSpringInitializr。 SpringBootがケーキだとしたら、SpringCloudはケーキが並んだショーケース。

デモ

マイクロサービスで構築したショッピングサイト。
ソースは↓。

github.com

  • 何がすごいって、モノリシックな普通のWebアプリケーションにしか見えないくらいサクサク動く
    しかも動いているだけじゃなく、メトリクスもキチンと取っている。
    「WebAPIを使いまくると遅い」と決めつけるのは間違いだった。

  • ソースはまだあまり見てないけど、サービスの単位は思っていたよりも小さい

  • ただ、メモリは全体で8.5GBくらい使っているっぽい
    モノリシックに比べれば、大きくなりそう

Q&A

QAもほとんど英語。
あまり聞き取れなかった。。。

質問の傾向としては、マイクロサービス構築時のベストプラクティスやガイドラインについて聞いているのが印象に残った。
回答としては、ケース・バイ・ケースと言った感じ?

反省点

  • やっぱり終わる前にお酒を飲んではいけない。
    後半はマッタリしてしまった・・・。

  • 英語で質問出来るようにならないとまずいなぁ・・・。

  • 他の人の質問を聞いてて思ったことは、最初に質問内容をバーンと言ってから、細かい事情や背景を説明したほうが良さそう。
    詳細を先に話し始めると、説明が難しくてそこで詰まってしまう。
    聞いてる方もどこから質問なのか判別が難しくなりそう。

  • 今年度(not 今年)は勉強会に行ったらブログを書く。

いじょ!

データのマスキングが気になったので調べてみた

セキュリティの要件を検討中、データのマスキングについて気になったので調べてみた。
具体的なシチュエーションとしてはこんな感じ。

  • システム導入先のユーザーと、そのシステムを構築・保守するSIer
  • SIerはテストや障害調査等でユーザーの個人情報含むデータ(顧客テーブルとか)が必要
  • 従来通りの氏名とか住所をマスキングすることは、個人情報保護法的にOKなのか

法律の解釈についてはあまり詳しくないので、間違っている箇所もあるかもしれないのでご容赦を。

匿名加工情報

個人情報保護法には「匿名加工情報」という言葉の定義があり、以下のように説明されていた。

・特定の個人を識別することができないように個人情報を加工して得られる個人に関する情報であって、当該個人情報を復元することができないようにしたものをいう。
・当該個人情報に含まれる記述等の一部を削除すること(当該一部の記述等を復元することのできる規則性を有しない方法により他の記述等に置き換えることを含む。)。
・当該個人情報に含まれる個人識別符号の全部を削除すること(当該個人識別符号を復元することのできる規則性を有しない方法により他の記述等に置き換えることを含む。)。

「個人識別符号」も定義されている。

・特定の個人の身体の一部の特徴を電子計算機の用に供するために変換した文字、番号、記号その他の符号であって、当該特定の個人を識別することができるもの
・個人に提供される役務の利用若しくは個人に販売される商品の購入に関し割り当てられ、又は個人に発行されるカードその他の書類に記載され、若しくは電磁的方式により記録された文字、番号、記号その他の符号であって、その利用者若しくは購入者又は発行を受ける者ごとに異なるものとなるように割り当てられ、又は記載され、若しくは記録されることにより、特定の利用者若しくは購入者又は発行を受ける者を識別することができるもの

特定の個人の身体の一部の特徴の例としては、顔写真とかが考えられる。
病院のカルテとかなら、病状や治療歴も含まれそう。
2つ目はクレジットカードや銀行口座の番号が該当する。
伝票番号とかは、他のデータと突き合わせれば購入した人がわかる可能性があるけど、この文には「他の情報と照合」という言葉が入っていないので許されるかもしれない。

ここまでのまとめ
  • マスキングして個人を特定できなくなったデータは個人情報保護法における「匿名加工情報」になる
  • 氏名や顔写真等は当然として、IDも削除しないといけない対象になる可能性がある

ID系についてはこんな感じ。

  • ICカードや領収証に記載されている人の目に触れる番号はマスキングが必須
  • システム内部でのみ使用しているサロゲートキーは許される(というか許されてほしい)

匿名加工情報の作成

これも法律に書いてあった。

個人情報取扱事業者は、匿名加工情報(匿名加工情報データベース等を構成するものに限る。以下同じ。)を作成するときは、特定の個人を識別すること及びその作成に用いる個人情報を復元することができないようにするために必要なものとして個人情報保護委員会規則で定める基準に従い、当該個人情報を加工しなければならない。
個人情報取扱事業者は、匿名加工情報を作成したときは、その作成に用いた個人情報から削除した記述等及び個人識別符号並びに前項の規定により行った加工の方法に関する情報の漏えいを防止するために必要なものとして個人情報保護委員会規則で定める基準に従い、これらの情報の安全管理のための措置を講じなければならない。
個人情報取扱事業者は、匿名加工情報を作成して当該匿名加工情報を第三者に提供するときは、個人情報保護委員会規則で定めるところにより、あらかじめ、第三者に提供される匿名加工情報に含まれる個人に関する情報の項目及びその提供の方法について公表するとともに、当該第三者に対して、当該提供に係る情報が匿名加工情報である旨を明示しなければならない。
個人情報取扱事業者は、匿名加工情報を作成したときは、個人情報保護委員会規則で定めるところにより、当該匿名加工情報に含まれる個人に関する情報の項目を公表しなければならない。 ・個人情報取扱事業者は、匿名加工情報を作成して自ら当該匿名加工情報を取り扱うに当たっては、当該匿名加工情報の作成に用いられた個人情報に係る本人を識別するために、当該匿名加工情報を他の情報と照合してはならない。
個人情報取扱事業者は、匿名加工情報を作成したときは、当該匿名加工情報の安全管理のために必要かつ適切な措置、当該匿名加工情報の作成その他の取扱いに関する苦情の処理その他の当該匿名加工情報の適正な取扱いを確保するために必要な措置を自ら講じ、かつ、当該措置の内容を公表するよう努めなければならない。

公表・・・?
えー、まとめると・・・

  • データをマスキングする時は、個人情報保護委員会規則で定める基準も考慮しないといけない
  • 加工の方法はバラしちゃだめ
  • 第三者に提供するときは公表しないといけない(!?)
    『みなさんこんにちわ、○○商社です。今回、わが社の顧客情報管理システムでトラブルが発生しました。つきましてはお客様のデータのうち氏名、住所を秘密にした顧客情報を、委託している××システムに提供します』とかプレスリリースとかに乗せろということ・・・なのか?
  • そもそも匿名加工情報を作った自体、公表しないといけない(!?)

なんかすごく面倒・・・。
少なくともシステムを開発・運用するSIerとの関係だと、法律通りの運用はされないのでは・・・。

JJUG CCC 2014 Fallに行ってきました

予定があって夕方に切り上げましたけど、今回は非常に内容が濃かったと思います。
とりあえず、参加したセッションの概要のまとめ。

K-1 基調講演1 : これからのJavaエンジニアの生きる道

技術の変化のための技術

クラウド

  • コンテナ型の仮想化ソフトDockerにより、クラウドプラットフォーム間の移動が簡単にできるようになると思われる。 ** より安く、サービスが充実した環境へ簡単に変えられる
  • Dockerで移動出来るようになったらクラウド事業者はどうなるか データロックインの方向に進むのではないか * データロックイン=データ活用のためのツールミドルウェア、ライブラリを充実。利用者が簡単に移動しないようにする。
  • 蓄積したデータを人工知能に利用する

時代はDockerっぽい。
データロックインという考え方は面白いかも。

人工知能

  • 人工知能に必要なものは認識、意思決定、行動
  • IBMのWatson。想定するユースケースはコールセンターで想定問答集や回答をサポートなど ** 「ロボットは東大に入れるか」という本が面白そう

  • 今、何故人工知能の話題が多いのか?
    ** データ、マシンパワーの増大により、認識やデータ解析の制度が向上。意思決定に使えるようになった。

  • 人工知能はデータが貯まるほど補正される関数
    ** 統計で問題をとくことは、理詰めでは説明できない。でも、なんとなくよく当たる。

  • Watsonは、音声認識→質問解析→検索→回答評価のプロセスで回答を導き出す。

  • 質問解析
    ** 問題からキーワードを抽出する。

  • 検索 ** キーワードをWebで検索し、回答の候補となる単語を抽出
  • 回答評価 ** 回答の候補を更に検索し、質問とマッチしているかを検索

Javaの今後

  • JVMは安定した大規模なWebサービスを運用可能 ** 今後は安定しているJVM上でJava言語以外の言語が動く流れが進むのでは

社会の変化

  • 価値にお金を払わない 例えばKickStarter。まだ製品化されていないのにお金を払う。 クオリティーじゃなく心に響く何かにお金を払っている

まとめ

  • 企業が人の成長を見られない状況。だからこそコミュニティは重要。

本当に人のつながりは大事だと思う。。。 というより、企業が人のつながりを軽視し過ぎで、コミュニティが特別じゃないというのが正直な思いかも。

私がTDDできないのはどう考えてもお前らが悪い!~エンタープライズJava開発でのTDD適用の勘所~

どうTDDするかについて?

チームの概要

  • BackBone.js+Spring MVC+Spring Batch+JPA
    テストケース3800ケース クライアント開発部隊とインテグレーター2社で1チーム *** 初めて顔を合わせるメンバーが多い。手探り。
  • ペア組んでユニットテストコーチング。

進め方

  • インテグレーションの中で実装とテストが完結していればOK。
    ** テストがあることのメリットを感じてもらう
  • フェイルファストしてないユニットテストは、フェイルファストしているテストと比べて信頼性を欠く。
  • 自動でないテストを重視する
    ** ユニットテストから漏れるバグが有ることを知っておく
  • コントローラーとサービスを優先的にテスト テストで100%を目指さない。
    再現性がある、独立しているが重要。
    *** それがないとCIに乗せられない

  • 技術的負債は改善サイクルに含める ** Tryをちゃんとタスク化する

  • 今のチームは問題を指摘したら次のスプリントに乗せてくれる。
    ** チームの信頼感重要

スローテスト

  • スローテストによる開発リズムの悪化はプロジェクトの死因
  • データベースを使うテストは遅い問題 データベースを使うことが遅いなら、データベースはプロダクトに使えない テスト実行時間より、テストデータのメンテナンスがスローテストの原因 *** エクセルでデータ管理の限界
  • データベースのアサートはテーブル全体に行う ** 差分をとってアサート出来るようにDBユニットをカスタマイズ
  • データベースマイグレーションはTDDを実施するのに必須

コントローラー層のテスト

  • End to Endに近い条件で。
  • DIしたオブジェクトをモックにすると、コンテナ内のオブジェクトが汚染される。
    ** @Afterでモックオブジェクトを取り除く

リグレッションテスト

デプロイの自動化

  • ServerSpecでデプロイスプリクトのコードを検証

なぜTDDするのか

  • 「もううんざりです。何も改善できません。」問題
  • TDDを導入するために必要なのはチームを作ること スキルの有無、キャリアの長短を人を測る尺度にしない
    「新人だから知らないと思うけど」という考え方は間違い ** IT技術者各人の背景を尊重すること重要

Spring Boot + Doma + AngularJSで作るERP(統合基幹業務システム)

プロダクトの歴史

2007年 seasar2、IE6と7をサポート。

  • IE8で動かない問題
  • 時代遅れ感の出てきたUI
  • リッチなWebサイトが増えて顧客の目が肥えてきた
  • 他のRESTAPIとの連携
  • 改修より作りなおすことを選択

Java EE 6 作成

  • PrimeFaces、JPAを利用 ** Seasar2時代もJSFを利用していたため
  • どうもしっくりこない。2サブシステムで終了

SpringMVC

  • 開発をリナックスで行う 文字コード、改行コード、パス区切り文字、レイアウト崩れ
    開発環境はVagrantで配布

  • Doma2 S2DAOを利用していたので、移行が楽だった SQLをごりごり書きたい派にはおすすめ。
    ** 依存ライブラリがない点もいい

  • Angular.js bootstrapのみを使用。ライブラリは自分で作成。
    JSFより軽快(当社比) ** バージョンアップで後方互換性が保たれない。

  • Spring開発にTerasolnaのガイドラインが役にたった

  • Angularは業務で使っても大丈夫 動かなくなったらフロントだけ作りなおせばいいという割り切り 当然コストがかかる
    一般的なシステムの償却期間は5年 フロントFrameworkの追従の予算が取れるかどうか。
    ** とれないならJSFのように一度作れば動き続けるものがよいのでは

  • 標準だから、流行ってるからじゃなく、きちんと検証して自分たちに合うものを選ぶ

QA

  • 3つのアーキテクチャの連携は? ** 認証はそれぞれ独立。連携する部分は少ない。

Java EE の新たな旅立ち : Java EE 8 へ向かって

Java EE8の具体的な内容について
現時点でのSnapshotのため、コードは変わる可能性あり

Java EE 8について

  • 業界のトレンドを観察
  • HTML5クラウド対応、簡単開発がテーマ

JSONB

  • JAXBとおなじ感覚で使える

JSONP

  • JSONPointer、JSONPatch、クエリに対するラムダ式を追加予定 JSONPointerは特定の値を参照するための標準(RFC)の構文 JSONPatchもRFCに定義されている
    JSONで記述したパッチを利用して更新 ラムダ式用にJSONCollectorクラスを提供
    ** toJsonArrayのような終端処理が出来る

SSE(サーバセンドイベント)

  • HTTP標準。実装をどこでやるかはまだ未定。 ** JAX-RSで対応するのが今のところ有望

ActionベースMVC

  • コントローラーの部分が未定。
    ** JAX-RSでやるのか、新しく追加するのか

  • Viewの部分はJSPかFaceletを選択できる ** Faceletの場合、Formにアクションを追加。

http2.0対応

  • Request/Responseの多重化、Streamの優先順位付け、ServerPush ** 今のServletAPIでは、Request/Responseの多重化に対応できない

CDIの適用範囲拡大

  • JSRは365
  • JavaEE以外でも使用できるようになる

これはちょっと嬉しい。

CDIのモジュール化

  • 多くの機能が追加されることによる肥大化の回避。
    ** DIのみ、CDIイベントのみ、フルセットから選択

EJBの教訓かな。

他機能との連携強化

  • JMSとの連携 ** MDBの実装が不要に

セキュリティインターセプタ

サンプルコード見た限り、ごちゃごちゃしすぎて使いづらそう。

仕様削減(pruning)

  • EJB2.Xのクライアント

まぁ、これはなくなっていいと思う。

JMX

  • JSR77にRESTインターフェースを追加
    ** JMXがサーバ実装に非依存

RESTでアクセスできるのはいいと思うけど、各サーバは独自実装捨てないといけなくなるから対応が大変そう。

セキュリティ

Javaエンジニアのためのアーキテクト講座

システム開発の現状

  • 「アプリケーションをいかによく作るか」から、「ITサービスをいかに良く運営するか 」への変化
  • 静的な仕様から作る→開発
  • 動的なフィードバックに基づく活動→運営 ** Web業界が先駆者
  • デジタル化 ** テクノロジーが社会に関わる
  • 仕様書に従って安全なコードを書けばいい時代は終わる

アーキテクチャの役割

  • 価値は利用者の体験によって定義される
    ** 一度リリースされたら終わりではない
  • フィードバックに対する持続的な成長
  • これら全体をデザインするアーキテクチャが必要 ** 家を建てる例

    家族がそれぞれ家のパーツを考える。それを形にしてもきちんと整合性が取れたものにならない。
    整合性をとり、かつ地震が来ても大丈夫なシステム。
    フィードバックを受け続け、継続的に保証する。

  • 利用者の動線、時期と作業、それに対応するだけの並行処理、トランザクション増加、負荷を分散させるためのclass分割、作るための要因と手法、KPIとしての評価

必要とされるスキル

  • TOGAFの全部が必要
    ** だけど、全部をやる必要ない。
  • 品質モデルとかは知ってないとダメ。
  • フレームワークの構成とかを考えるだけなのはアーキテクトじゃない。

設計の進め方

  • マイクロサービスアーキテクチャ ** 個々のサービス→データ、ガバナンス、手法も独立
  • 個々のサービスは個々のチームによって開発、運用 ** 責任も各チーム

  • マイクロサービスアーキテクチャの考え方はある ECサイト
    商品登録 カート 決済 ** 配送

異なるドメインとして定義

  • ユーザによって役割が異なる
    ユーザによって利用されるサイクルが違う
    * 変化の境界線
  • それぞれのサービスごとに利用者とサイクルが異なる。
  • ドメインを分割しつつも非機能も考えないといけない。
    ** ECサイトの例。決済のASPダウンしてるから買わせないはダメ

QA

  • Q:アーキテクトが役割を理解してもらうためには? ** A:正しいと思う行動をする。それでもダメなら・・・。
  • Q:プロマネとかぶる? ** A:計画をたてる人がアーキテクト、プロマネは計画を進める。
    IBMはアーキテクトが仕事をした後じゃないとプロマネは仕事ができていないと言われている。

  • Q:経営者は含まれないのか? ** A:経営者はざっくりしか言わないし、言うことも変わる。適当に受け流す。